JP2011061364A - 送信装置および送信方法 - Google Patents
送信装置および送信方法 Download PDFInfo
- Publication number
- JP2011061364A JP2011061364A JP2009207155A JP2009207155A JP2011061364A JP 2011061364 A JP2011061364 A JP 2011061364A JP 2009207155 A JP2009207155 A JP 2009207155A JP 2009207155 A JP2009207155 A JP 2009207155A JP 2011061364 A JP2011061364 A JP 2011061364A
- Authority
- JP
- Japan
- Prior art keywords
- data
- pdcp
- transmission
- sequence number
- handover
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】ハンドオーバ後に送信されるPDCP status reportを用いて、再送対象とすべきPDCP SDUおよび破棄対象とすべきPDCP SDUを正確に特定し、ユーザデータを常に正常に伝送すること。
【解決手段】判定部108は、ハンドオーバ時に受信装置で未受信であるデータのうちの先頭データのシーケンス番号を示す制御情報を受信し、制御情報を受信した場合、送達確認が未完了のデータのうちの先頭データから、ハンドオーバ前に送信が完了したデータのうちの最後尾データまでの間で、制御情報に示されるシーケンス番号に対応するデータを判定し、送信指示部107は、送達確認が未完了のデータのうちの先頭データから、シーケンス番号1周分に相当するデータまでの送信を指示し、送達確認が未完了のデータのうちの先頭データから前記シーケンス番号1周分に相当するデータより後のデータの送信を指示しない。
【選択図】図4
【解決手段】判定部108は、ハンドオーバ時に受信装置で未受信であるデータのうちの先頭データのシーケンス番号を示す制御情報を受信し、制御情報を受信した場合、送達確認が未完了のデータのうちの先頭データから、ハンドオーバ前に送信が完了したデータのうちの最後尾データまでの間で、制御情報に示されるシーケンス番号に対応するデータを判定し、送信指示部107は、送達確認が未完了のデータのうちの先頭データから、シーケンス番号1周分に相当するデータまでの送信を指示し、送達確認が未完了のデータのうちの先頭データから前記シーケンス番号1周分に相当するデータより後のデータの送信を指示しない。
【選択図】図4
Description
本発明は、送信装置および送信方法に関するものである。
現在、3rd Generation Partnership Project (以下、3GPPという)のTechnical Specification Group Radio Access Network(TSG RAN)において、次世代移動通信システムであるLong Term Evolution(以下、LTEという)の検討が進められている。3GPP LTEでは、携帯端末装置(以下、UE:User Equipmentという)は、複数の基地局装置(以下、eNB:Evolved Node Bという)から構成されるE-UTRAN(Enhanced Universal Terrestrial Radio Access Network)に接続して、ユーザデータの送受信を行う。ここで、UEとeNBとの間のユーザデータは、3GPP LTEで使用される通信プロトコルのレイヤ1(物理レイヤ)およびレイヤ2(データリンクレイヤ)で制御される。また、レイヤ2は、無線リソースの割当制御等を行うMAC(Medium Access Control)レイヤと、無線リンクの制御を行うRLC(Radio Link Control)レイヤと、データの暗号化・復号化、ハンドオーバ時のパケット順序制御等を行うPDCP(Packet Data Convergence Protocol)レイヤとに分けられる。
また、UEおよびeNBの各PDCPレイヤには、通信経路(以下、無線ベアラ(Radio Bearer)という)が通信開始時に設定される。無線ベアラは、複数設定可能であり、1つの無線ベアラ毎にUEおよびeNBそれぞれに対応するPDCPエンティティ(PDCP entity)が生成される。各PDCPエンティティは、無線ベアラを用いて送受信されるユーザデータに対する制御情報を保持する。
また、無線ベアラは3つに分類される。具体的には、無線ベアラは、レイヤ3(RRC/NAS)の通信制御メッセージを送受信するシグナリング無線ベアラ(SRB(Signaling Radio Bearer))と、ユーザデータの送達確認が取れるまでRLCレイヤにおいてユーザデータを再送するモード(RLC-AM(RLC - Acknowledge Mode))のデータ無線ベアラ(DRB:Data Radio Bearer)と、RLCレイヤにおいてユーザデータの送達確認を行わないモード(RLC-UM(RLC - Unacknowledge Mode))のデータ無線ベアラ(DRB)とに分類される。
また、UEは、自装置の移動に応じて、接続先のeNBを切り替えるハンドオーバを行う。上述したRLC-AMでは、UEおよびeNBでは、ハンドオーバ前後でも、ユーザデータが欠損しないように制御する必要がある。しかし、ユーザデータの再送制御を行うRLCレイヤでは、ハンドオーバ前後で通信状態がリセットされてしまう。そのため、ハンドオーバ前後の状態保持、および、ハンドオーバ後のデータ再送は、RLCレイヤの上位レイヤであるPDCPレイヤで行われる(例えば、非特許文献1参照)。
具体的には、PDCPエンティティは、ハンドオーバ前にRLCレイヤで送達確認が取れていない(送達確認が未完了である)ユーザデータ(以下、PDCP SDU(Service Data Unit)という)の再送をハンドオーバ後に行う。また、ハンドオーバ後には、UEおよびeNBそれぞれに配置されるPDCPエンティティ間で、制御PDU(Protocol Data Unit)(以下、PDCP status reportという)が送信される。これにより、ハンドオーバ前に送達確認済みであるPDCP SDUを対向のPDCPエンティティに通知することが可能となる。そして、PDCP status reportを受信したPDCPエンティティは、PDCP status reportに示された、送達確認済みのPDCP SDUを破棄し、そのPDCP SDUを送信しない。すなわち、PDCP status reportの通知により、ハンドオーバ前に受信側のPDCPエンティティで受信されているが、送信側のPDCPエンティティで送達確認が未完了であるPDCP SDUの再送、つまり、再送不要であるデータの無駄な再送を低減することができる。
図1にPDCP status reportのフォーマットを示す。図1に示すように、PDCP status reportには、受信側のPDCPエンティティで未受信であるPDCP SDUのうちの先頭のPDCP SDUのシーケンス番号(SN:Sequence Number)を示すFMS(First Missing PDCP SN、12ビット)、および、受信側のPDCPエンティティでFMS以降のPDCP SDUが受信済みであるか否かを示すBitmap(8ビット(1オクテット)の倍数で可変長)が含まれる。例えば、受信側のPDCPエンティティでPDCP SDUが受信済みの場合のBitmapを‘1’とし、PDCP SDUが未受信の場合のBitmapを‘0’とする。
また、図2にCOUNTのフォーマットを示す。COUNTは、図2に示すように、PDCP SDU毎に割り当てられるシーケンス番号を示すPDCP SNと、そのPDCP SNが何周目であるかを示すHFN(Hyper Frame Number)とから構成される値である。PDCPエンティティは、SDUを1つ送信するとPDCP SNをインクリメントする。また、PDCP SNは有限な値(例えば、PDCP SN=0〜4095の4096個)であり、最大値に達すると次は0になる。このとき、HFNがインクリメントされる。また、COUNTは、送受信側のPDCPエンティティにおける暗号化処理および復号処理の際の入力パラメータとして用いられる。
送信側のPDCPエンティティは、受信側のPDCPエンティティからのPDCP status reportを受信すると、PDCP status reportに含まれるFMSよりもCOUNTの値が小さいPDCP SDU、および、PDCP status reportに含まれるBitmapが‘1’であるPDCP SDU、すなわち、受信側のPDCPエンティティで受信済みのPDCP SDUを破棄し送信しない。
また、ハンドオーバ後、送信側のPDCPエンティティは、PDCP status reportの通知を待たずに、ハンドオーバ前にRLCレイヤで送達確認が未完了であるPDCP SDUのうちの先頭のPDCP SDU(以下、このPDCP SDUのPDCP SNをFirst No Ack SNという)から順に再送する。一方、ハンドオーバ後、受信側のPDCPエンティティは、FMSから2048SDU分のPDCP SDU
を、再送待ち受信ウインドウ(Reordering window)として受信可能とする。
を、再送待ち受信ウインドウ(Reordering window)として受信可能とする。
3GPP TS 36.323 V8.5.0, "Packet Data Convergence Protocol (PDCP) specification (Release 8),"March 2009
しかしながら、上述したPDCP status report(図1)には、受信側のPDCPエンティティで未受信であるPDCP SDUのうちの先頭のPDCP SNを示すFMSは含まれているものの、そのFMSに対応するHFNの情報は含まれていない。そのため、FMSに対応するHFNについては、PDCP status reportを受信した送信側のPDCPエンティティが判定する必要がある。
以下、図3を用いて具体的に説明する。以下の説明では、図3に示すように、PDCP SDUのシーケンス番号(PDCP SN)を0〜4095(つまり、4096SDU分)とする。また、Reordering windowを、シーケンス番号1周分(すなわち、取りうるすべてのシーケンス番号分)に相当する4096SDUの半分、つまり、2048SDU分とする。また、図3では、送信側のPDCPエンティティにおける、First No Ack SNをHFN=1、SN=4092とし、ハンドオーバ前に送信が完了しているPDCP SDUのうちの最後尾のPDCPのシーケンス番号(以下、Last Send SN)をHFN=2、SN=4094とする。また、受信側のPDCPエンティティからのPDCP status reportに含まれるFMSを4093とする。
そこで、送信側のPDCPエンティティは、First No Ack SN(図3ではHFN=1、SN=4092)からLast Send SN(図3ではHFN=2、SN=4094)までの間にFMS(図3では4093)が存在すると判断し、FMSに対応するHFNの判定を行う。
しかしながら、ハンドオーバ前に、First No Ack SNとLast Send SNとの間の間隔が、PDCP SN1周分に相当する値、つまり、PDCP SNが取りうる値(図3では0〜4095)の1周分(図3では4096SDU分)以上の場合には、FMSと一致するSNが複数存在する可能性がある。例えば、図3では、First No Ack SNとLast Send SNとの間の間隔が4099SDU分(>4096SDU)離れており、FMS(4093)と一致するSNとして、HFN=1のSN=4093、および、HFN=2のSN=4093の2つのFMS候補が存在する。そのため、送信側のPDCPエンティティは、FMSに対応するHFNの判定を一意に行うことができなくなる。
例えば、図3において、受信側のPDCPエンティティで未受信のPDCP SDUのうちの先頭のPDCP SDUがHFN=1、SN=4093の場合について説明する。この場合、送信側のPDCPエンティティがFMS(4093)に対応するHFNを2と誤って判定してしまうと、送信側のPDCPエンティティは、HFN=2、SN=4093のPDCP SDUよりも前のPDCP SDU(HFN=2、SN=4092以前のPDCP SDU)の再送を不要と判断する。よって、送信側のPDCPエンティティは、図3に示すHFN=1、SN=4093のPDCP SDUからHFN=2、SN=4092のPDCP SDUまでの4096個のPDCP SDU(再送が必要なPDCP SDU)を、PDCP status report受信後に破棄してしまう。
また、送信側のPDCPエンティティが図3に示すHFN=2、SN=4093のPDCP SDUから順に再送するのに対し、受信側のPDCPエンティティは、図3に示すHFN=1、SN=4093のPDCP SDUを先頭にした2048SDU分をReordering windowとして受信可能とする。そのため、受信側のPDCPエンティティでは、HFN=2、SN=4093以降のPDCP SDUが、HFN=1、SN=4093以降のPDCP SDUとして誤って受信されてしまう。この場合、送受信側のPDCPエンティティ間でのHFNの不一致が発生し、かつ、HFNの不一致が以降継続する。よって、暗号化処理および復号処理のパラメータとしてHFNを含むCOUNTを用いても送受信間でのHFNの不一致によりPDCP SDUを正常に伝送することができなくなる。
次に、例えば、図3において、受信側のPDCPエンティティで未受信のPDCP SDUのうちの先頭のPDCP SDUがHFN=2、SN=4093の場合について説明する。この場合、送信側のPDCPエンティティがFMS(4093)に対応するHFNを1と誤って判定してしまうと、送信側のPDCPエンティティは、HFN=1、SN=4093のPDCP SDU以降のPDCP SDUの再送が必要であると判断する。よって、送信側のPDCPエンティティは、図3に示すHFN=1、SN=4093のPDCP SDUからHFN=2、SN=4092のPDCP SDUまでの4096個のPDCP SDU(再送不要なPDCP SDU)を、PDCP status report受信後に再送してしまう。つまり、送信側のPDCPエンティティは、再送不要なPDCP SDUを無駄に送信してしまう。
また、送信側のPDCPエンティティが図3に示すHFN=1、SN=4093のPDCP SDUから順に再送するのに対し、受信側のPDCPエンティティは、図3に示すHFN=2、SN=4093のPDCP SDUを先頭にした2048SDU分(図示せず)をReordering windowとして受信可能とする。そのため、受信側のPDCPエンティティでは、HFN=1、SN=4093以降のPDCP SDUが、HFN=2、SN=4093以降のPDCP SDUとして誤って受信されてしまう。この場合にも、上述したように、送受信側のPDCPエンティティ間でのHFNの不一致が発生し、かつ、HFNの不一致が以降継続する。よって、暗号化処理および復号処理のパラメータとしてHFNを含むCOUNTを用いても送受信間でのHFNの不一致によりPDCP SDUを正常に伝送することができなくなる。
このように、PDCPエンティティでは、ハンドオーバ後のPDCP status report受信時に再送対象とすべきPDCP SDUおよび破棄対象とすべきPDCP SDUを正確に特定できない場合があるため、ユーザデータを正常に伝送することができない可能性がある。
本発明の目的は、ハンドオーバ後に送信されるPDCP status reportを用いて、再送対象とすべきPDCP SDUおよび破棄対象とすべきPDCP SDUを正確に特定し、ユーザデータを常に正常に伝送することができる送信装置および送信方法を提供することである。
本発明の送信装置は、データに対して有限のシーケンス番号を周回的に割り当て、前記シーケンス番号と前記シーケンス番号が何周目であるかを示す番号がそれぞれ割り当てられた前記データを送信し、かつ、ハンドオーバ前に第1のレイヤで送達確認が未完了のデータを、ハンドオーバ後に、前記第1のレイヤよりも上位レイヤである第2のレイヤで再送する送信装置であって、前記第1のレイヤでのデータの送信を指示するとともに、ハンドオーバ後における前記第2のレイヤでのデータの再送を指示する送信指示手段と、ハンドオーバ時に受信装置で未受信であるデータのうちの先頭データの前記シーケンス番号を示す制御情報を受信する受信手段と、前記制御情報を受信した場合、前記送達確認が未完了のデータのうちの先頭データから、ハンドオーバ前に送信が完了したデータのうちの最後尾データまでの間で、前記制御情報に示されるシーケンス番号に対応するデータを特定する特定手段と、を具備し、前記送信指示手段は、前記送達確認が未完了のデータのうちの先頭データから、シーケンス番号1周分に相当するデータまでの送信を指示し、前記送達確認が未完了のデータのうちの先頭データから前記シーケンス番号1周分に相当するデータより後のデータの送信を指示しない構成を採る。
本発明の送信方法は、データに対して有限のシーケンス番号を周回的に割り当て、前記シーケンス番号と前記シーケンス番号が何周目であるかを示す番号がそれぞれ割り当てられた前記データを送信し、かつ、ハンドオーバ前に第1のレイヤで送達確認が未完了のデータを、ハンドオーバ後に、前記第1のレイヤよりも上位レイヤである第2のレイヤで再送する送信装置における送信方法であって、前記第1のレイヤでのデータの送信を指示するとともに、ハンドオーバ後における前記第2のレイヤでのデータの再送を指示する送信指示ステップと、ハンドオーバ時に受信装置で未受信であるデータのうちの先頭データの前記シーケンス番号を示す制御情報を受信する受信ステップと、前記制御情報を受信した場合、前記送達確認が未完了のデータのうちの先頭データから、ハンドオーバ前に送信が完了したデータのうちの最後尾データまでの間で、前記制御情報に示されるシーケンス番号に対応するデータを特定する特定ステップと、を具備し、前記送信指示ステップは、前記送達確認が未完了のデータのうちの先頭データから、シーケンス番号1周分に相当するデータまでの送信を指示し、前記送達確認が未完了のデータのうちの先頭データから前記シーケンス番号1周分に相当するデータより後のデータの送信を指示しないようにする。
本発明によれば、ハンドオーバ後に送信されるPDCP status reportを用いて、再送対象とすべきPDCP SDUおよび破棄対象とすべきPDCP SDUを正確に特定し、ユーザデータを常に正常に伝送することができる。
以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。
(実施の形態1)
本実施の形態に係る送信装置の構成を図4に示す。なお、図4に示す送信装置100は、PDCPレイヤに配置されるPDCPエンティティ(つまり、送信側のPDCPエンティティ)の構成を示す。図4に示す送信装置100は、例えば、UE(携帯端末装置)である。
本実施の形態に係る送信装置の構成を図4に示す。なお、図4に示す送信装置100は、PDCPレイヤに配置されるPDCPエンティティ(つまり、送信側のPDCPエンティティ)の構成を示す。図4に示す送信装置100は、例えば、UE(携帯端末装置)である。
また、以下の説明では、データに対して有限のシーケンス番号(PDCP SN)が周回的に割り当てられる。また、送信装置100が送信するデータには、シーケンス番号(PDCP SN)と、そのシーケンス番号が何周目であるかを示すHFNとから構成されるCOUNTがそれぞれ割り当てられている。また、送信装置100は、ハンドオーバ前にRLCレイヤで送達確認が未完了のデータを、ハンドオーバ後に、RLCレイヤよりも上位レイヤであるPDCPレイヤで再送する。
図4に示す送信装置100において、送達確認管理部101は、ハンドオーバ後に下位レイヤ(例えば、RLCレイヤ)から入力される送達確認済みのPDCP PDUを示す情報に基づいて、ハンドオーバ前にRLCレイヤで送達確認が未完了のデータに対応するPDCP PDUのうちの先頭のPDCP PDUを特定する。そして、送達確認管理部101は、特定したPDCP PDUのシーケンス番号であるFirst No Ack SNを管理する。そして、送達確認管理部101は、First No Ack SNを、再送管理部102、送信指示部107および判定部108に出力する。
再送管理部102は、ハンドオーバ後のユーザデータ(PDCP SDU)の再送を管理する。具体的には、再送管理部102は、判定部108から何も入力されない場合(つまり、自装置がPDPC status reportを受信していない場合)、送達確認管理部101から入力されるFirst No Ack SNに対応するPDCP SDUを再送開始位置とする。一方、再送管理部102は、判定部108からFMSおよびFMSに対応するHFNが入力される場合、そのFMSおよびHFNに対応するPDCP SDUを再送開始位置とする。そして、再送管理部102は、設定したSN(First No Ack SNまたはFMS)、および、そのSNに対応するHFNをSN・HFN管理部103に出力する。
SN・HFN管理部103は、上位レイヤから暗号化前データバッファ104に入力される送信データ(PDCP SDU)およびその送信データ(PDCP SDU)に対応するSNおよびHFNを管理する。つまり、SN・HFN管理部103は、上位レイヤから入力されるPDCP SDUにSNおよびHFNの割当を行い、暗号化処理部105に対して暗号化前データバッファ104内のPDCP SDUに対応するSNおよびHFNから生成したCOUNT(図2)を用いて暗号化するよう指示する。また、SN・HFN管理部103は、再送管理部102からハンドオーバが発生した場合に再送を開始するSNおよびHFNの情報を入力し、暗号化処理部105へ暗号化処理の指示を行う。
暗号化前データバッファ104は、上位レイヤから入力される送信データ(PDCP SDU)を格納するとともに、暗号化処理部105に出力する。また、暗号化前データバッファ104は、データ破棄処理部110から入力されるデータ破棄要求に示される送信データを破棄する。
暗号化処理部105は、SN・HFN管理部103から順次入力されるCOUNT(SNおよびHFN)を用いて、暗号化前データバッファ104から入力される送信データに対して暗号化処理を行う。そして、暗号化処理部105は、暗号化後の送信データを暗号化後データバッファ106に出力する。
暗号化後データバッファ106は、暗号化処理部105から入力される送信データを格納するとともに、送信指示部107に出力する。また、暗号化後データバッファ106は、データ破棄処理部110から入力されるデータ破棄要求に示される送信データデータを破棄する。
送信指示部107は、送信データにPDCP PDU headerを付けてRLCレイヤへ送信指示を行うとともに、RLCレイヤへ送信を指示した最後のSN/HFNを管理する。具体的には、送信指示部107は、ハンドオーバ前には、送達確認管理部101から入力されるFirst No Ack SNから、シーケンス番号1周分に相当するデータの送信を指示する。つまり、送信指示部107は、First No Ack SNから、シーケンス番号1周分に相当するデータより後のPDCP SDUの送信指示をしない。すなわち、送信指示部107は、First No Ack SNと、送信が完了した送信データのうち最後尾の送信データに対応するシーケンス番号であるLast Send SNとの間の間隔を、シーケンス番号(PDCP SN)として取りうる値の1周分以内となるように、PDCP SDUの送信を指示する。例えば、シーケンス番号(PDCP SN)として取りうる値が0〜4095の場合には、送信指示部107は、First No Ack SNとLast Send SNとの間の間隔を、4096SDU以内となるように、PDCP SDUの送信を指示する。また、送信指示部107は、ハンドオーバ後、自装置がPDCP status reportを受信した場合には、FMSに示されるシーケンス番号以前のPDCP SDU/PDCP PDUと、Bitmapで送達確認の取れたPDCP SDU/PDCP PDUを破棄し、以降の送信指示をしない。一方、送信指示部107は、ハンドオーバ後、自装置がPDCP status reportを受信していない場合には、送達確認が未完了のデータのうちの先頭データ(First No Ack SN)以降のデータをPDCPレイヤで再送するように制御する。そして、送信指示部107は、送信データ(PDCP PDU)をRLCレイヤに出力する。また、送信指示部107は、RLCレイヤに出力した送信データ、つまり、送信済みの送信データに対応するSNおよびHFNを管理する。また、送信指示部107は、RLCレイヤに出力した送信データのうちの最後尾の送信データに対応するシーケンス番号(Last Send SN)を判定部108に出力する。なお、送信指示部107におけるPDCP SDUの送信制御処理の詳細については後述する。
判定部108は、ハンドオーバ時に受信装置で未受信であるPDCP SDUのうちの先頭のPDCP SDUのシーケンス番号を示すFMSを含むPDCP status reportを、受信装置(つまり、受信側のPDCPエンティティ)から受信する。そして、判定部108は、送達確認管理部101から入力されるFirst No Ack SNおよび送信指示部107から入力されるLast Send SNに基づいて、PDCP status reportに含まれるFMSに対応するHFNを判定する。具体的には、判定部108は、First No Ack SNからLast Send SNまでの間で、FMSに示されるシーケンス番号に対応するデータを特定する。そして、判定部108は、特定したデータのHFNをFMSに対応するHFNとして判定する。そして、判定部108は、判定したHFNおよびFMSに対応するPDCP SDU未満のPDCP SDUを、送達確認が完了しているPDCP SDUとする。また、判定部108は、FMSおよびFMSに対応するHFNを再送管理部102に出力する。一方、判定部108は、ハンドオーバ後にPDCP status reportを受信していない場合には、First No Ack SNに対応するPDCP SDU未満のPDCP SDUを、送達確認が完了しているPDCP SDUとする。そして、判定部108は、送達確認が完了しているPDCP SDUを示す情報をデータ破棄処理部110に出力する。
タイマ制御部109は、各PDCP SDUがPDCPレイヤに入力されてからの経過時間を計時する。つまり、タイマ制御部109では、各PDCP SDUに対して、PDCP SDU discard timerが動作する。そして、タイマ制御部109は、計時している経過時間が予め設定された時間だけ経過した場合、そのPDCP SDUを破棄して送信対象から外すように制御する。つまり、PDCPレイヤに入力されてから予め設定された経過時間が満了したPDCP SDUは再送されない。そして、タイマ制御部109は、経過時間が満了したPDCP SDUを示す情報をデータ破棄処理部110に出力する。
データ破棄処理部110は、SN・HFN管理部103が管理するPDCP SDUおよびそのPDCP SDUに対応するSNとHFNの情報に基づき、判定部108から入力される情報に示されるPDCP SDU(つまり、送達確認が完了したPDCP SDU)およびタイマ制御部109から入力される情報に示されるPDCP SDU(つまり、経過時間が満了したPDCP SDU)の破棄を要求するデータ破棄要求を、暗号化前データバッファ104および暗号化後データバッファ106に出力する。
次に、本実施の形態に係る受信装置の構成を図5に示す。なお、図5に示す受信装置200は、PDCPレイヤに配置されるPDCPエンティティ(つまり、受信側のPDCPエンティティ)の構成を示す。図5に示す受信装置200は、例えば、eNB(基地局装置)である。
図5に示す受信装置200において、判定部201は、RLCレイヤから受け取ったPDUがデータPDUであるのか、それとも制御PDUであるのかを判定する。具体的には、判定部201は、受け取ったPDUが制御PDUである場合、対向する送信装置100のPDCPエンティティから送信されてきたPDCP status reportを受け取ったと判定し、PDCP status reportを送信装置100のPDCPエンティティへ送信する。そして、判定部201は、ハンドオーバ後に、送達確認済みのPDCP PDUを示す情報を、送信装置100(つまり、送信側のPDCPエンティティ)に出力する。
復号前データバッファ202は、判定部201から入力される受信データ(PDCP PDU)を格納するとともに、受信データのうち、PDUヘッダ部分をSN・HFN管理部203に出力し、ペイロード部分(PDCP SDU)を復号処理部204に出力する。例えば、PDUヘッダ部分には、その受信データのPDCP SNを示す情報等が含まれる。
SN・HFN管理部203は、これまでに受信したPDCP PDUに対応するSNおよびHFNを管理する。具体的には、SN・HFN管理部203は、これまでに受信したPDCP PDUに対応するSNとHFNの情報を管理していて、その情報に基づいて次に受信を期待するSN/HFNの情報と復号前データバッファ202から入力されるPDUヘッダに含まれるSNとに基づいて、HFNを特定する。SN・HFN管理部203は、SN/HFNからCOUNT値を生成し、復号処理部204に対してCOUNT値を渡し、復号前データバッファ202内の対応するPDCP PDUの復号を要求する。そして、SN・HFN管理部203は、SNおよびHFNから構成されるCOUNTを管理する。そして、SN・HFN管理部203は、管理しているCOUNTを復号処理部204に順次出力する。
復号処理部204は、SN・HFN管理部203から入力されるCOUNTを用いて、復号前データバッファ202から入力される受信データ(PDCP SDU)に対して復号処理を行う。そして、復号処理部204は、復号後の受信データを復号後データバッファ205に出力する。
復号後データバッファ205は、復号処理部204から入力される受信データを格納するとともに、SN/HFNの情報をReordering window管理部206に出力する。
Reordering window管理部206は、前回までの受信データの受信時に未受信である受信データ(PDCP SDU)のうち先頭データ(すなわち、FMSに対応するPDCP SDU)から予め設定されたSDU分を、再送待ち受信ウインドウであるReordering windowとして管理する。そして、Reordering window管理部206は、復号後データバッファ205から入力される受信データを、Reordering window内の受信データとして上位レイヤに出力する。このとき、Reordering window管理部206は、受信データがReordering windowの範囲外のデータである場合には、その範囲外データを廃棄する。また、Reordering window管理部206は、ハンドオーバが発生した場合に、受信データのシーケンス番号が不連続な場合には、その受信データを上位レイヤに出力せずに、復号後データバッファ205に格納する。また、Reordering window管理部206は、受信データの受信後に、未だに受信していない受信データのうちの先頭データのシーケンス番号を新たなFMSとして設定する。そして、Reordering window管理部206は、FMS、および、FMS以降のPDCP SDUのうち受信済みであるPDCP SDUのシーケンス番号を、生成部207に出力する。また、Reordering window管理部206は、ハンドオーバが発生した場合に、ハンドオーバ前のデータをすべて受信した時点での復号後データバッファ205内に格納された受信データに基づいてFMSとシーケンス番号を設定し、生成部207に出力する。
生成部207は、Reordering window管理部206から入力されるFMS、および、FMS以降の受信済みであるPDCP SDUのシーケンス番号に基づいて、PDCP status reportを生成する。具体的には、生成部207は、図1に示すように、FMS以降の受信済みであるPDCP SDUのシーケンス番号に基づいてBitmapを生成する。そして、生成部207は、FMSおよびBitmapを含むPDCP status reportを生成して、生成したPDCP status reportを送信装置100(図4)に出力する。
次に、本実施の形態に係る送信装置100の送信指示部107におけるPDCP SDUの送信制御処理の詳細について説明する。
以下の説明では、図6に示すように、図3と同様、PDCP SDUのシーケンス番号(PDCP SN)を0〜4095(つまり、4096SDU分)とする。また、Reordering windowを2048SDU分(4096SDUの半分)とする。また、図6では、送信装置100(送信側のPDCPエンティティ)における、First No Ack SNをHFN=1、SN=4092とする。また、受信装置200(受信側のPDCPエンティティ)で未受信のPDCP SDUのうちの先頭のPDCP SDUをHFN=1、SN=4093とする。よって、受信装置200からのPDCP status reportに含まれるFMSは4093を示す。
そこで、送信装置100の送信指示部107は、ハンドオーバ前には、First No Ack SN(HFN=1、SN=4092)から4096SDU分(つまり、シーケンス番号1周分に相当するSDU)より後のPDCP SDUを送信しないように制御する。つまり、図6に示すように、First No Ack SNがHFN=1、SN=4092の場合には、送信指示部107は、First No Ack SN(HFN=1、SN=4092)から4096SDUだけ離れたHFN=2、SN=4091までのPDCP SDUを送信可能とする。換言すると、送信指示部107は、First No Ack SN(HFN=1、SN=4092)から4096SDUよりも多く離れたHFN=2、SN=4092以降のPDCP SDUを送信しない。なお、上記処理による効果は、SN・HFN管理部103が、暗号化処理部105に対して暗号化処理の指示を行わないことによっても達成できる。
これにより、図6に示すように、First No Ack SNとLast Send SNとの間の間隔は、最大で4096SDU分(≦4096SDU)となる。この場合、First No Ack SNとLast Send SNとの間には、同一のシーケンス番号(PDCP SN)を有するPDCP SDUは存在しない。
よって、First No Ack SNとLast Send SNとの間で、ハンドオーバ後に受信装置200から送信されるPDCP status reportに含まれるFMSと一致するシーケンス番号(PDCP SN)
は1つのみとなる。例えば、図6では、送信装置100の判定部108は、First No Ack SN(HFN=1、SN=4092)と取りうる最大のLast Send SN(HFN=2、SN=4091)との間において、FMS(4093)と一致するシーケンス番号(PDCP SN)としてHFN=1のSN=4093を判定する。すなわち、判定部108は、FMSと一致するシーケンス番号(PDCP SN)に対応するHFNを一意に判定することができる。
は1つのみとなる。例えば、図6では、送信装置100の判定部108は、First No Ack SN(HFN=1、SN=4092)と取りうる最大のLast Send SN(HFN=2、SN=4091)との間において、FMS(4093)と一致するシーケンス番号(PDCP SN)としてHFN=1のSN=4093を判定する。すなわち、判定部108は、FMSと一致するシーケンス番号(PDCP SN)に対応するHFNを一意に判定することができる。
そして、送信装置100のデータ破棄処理部110は、受信装置200において未受信であるPDCP SDUよりも前のPDCP SDU(図6では、HFN=1、SN=4093(FMS)未満のPDCP SDU)を破棄対象とする。なお、データ破棄処理部110は、さらに、受信装置200からのPDCP status reportに含まれるBitmapが‘1(受信済み)’に対応するPDCP SDU、および、タイマ制御部109から指示されるPDCP SDU(経過時間満了のPDCP SDU)も破棄対象とする。
これにより、送信装置100は、ハンドオーバ後には、受信装置200において未受信であるPDCP SDU(すなわち、HFN=1、SN(FMS)=4093に対応するPDCP SDU)から順にPDCP SDUを再送する。
このように、本実施の形態では、送信装置は、ハンドオーバ前には、送達確認が未完了のPDCP SDUのうちの先頭のPDCP SDUから、シーケンス番号1周分に相当するPDCP SDUよりも後のPDCP SDUを送信しないように、PDCP SDUの送信を制御する。これにより、送信装置は、ハンドオーバ後に受信装置から送信されるPDCP status reportに含まれるFMSに対応するHFNを確実に判定することができる。すなわち、送信装置は、ハンドオーバ後に再送すべきPDCP SDU、および、再送不要のため破棄すべきPDCP SDUを確実に特定することができる。また、送信装置は、FMSに対応するHFNを確実に判定することができるため、送受信間で用いるHFNが一致する。よって、本実施の形態によれば、送受信間で同一のHFNを用いてPDCP SDUの暗号化処理および復号処理が行われるため、PDCP SDUを正常に伝送することができる。よって、本実施の形態によれば、ハンドオーバ後に送信されるPDCP status reportを用いて、再送対象とすべきPDCP SDUおよび破棄対象とすべきPDCP SDUを正確に特定し、ユーザデータを常に正常に伝送することができる。
(実施の形態2)
上述したように、ハンドオーバ後、送信側のPDCPエンティティは、PDCP status reportの通知を待たずに、First No Ack SNのPDCP SDUから順に再送を開始する。このとき、受信側のPDCPエンティティでは、送信側のPDCPエンティティから再送されるPDCP SDUに対応するHFNを誤って認識してしまうことがある。
上述したように、ハンドオーバ後、送信側のPDCPエンティティは、PDCP status reportの通知を待たずに、First No Ack SNのPDCP SDUから順に再送を開始する。このとき、受信側のPDCPエンティティでは、送信側のPDCPエンティティから再送されるPDCP SDUに対応するHFNを誤って認識してしまうことがある。
以下、図7を用いて具体的に説明する。以下の説明では、図3と同様、PDCP SDUのシーケンス番号(PDCP SN)を0〜4095(つまり、4096SDU分)とする。また、Reordering windowを2048SDU分(シーケンス番号1周分に相当する4096SDUの半分)とする。また、図7では、送信側のPDCPエンティティにおける、First No Ack SNをHFN=1、SN=10とする。また、受信側のPDCPエンティティで未受信のPDCP SDUのうちの先頭のPDCP SDUをHFN=1、SN=2059とする。よって、PDCP status reportに含まれるFMSは2059を示す。
図7では、First No Ack SN(送信側のPDCPエンティティが再送を開始するPDCP SDUの先頭)とFMS(受信側のPDCPエンティティが受信可能なPDCP SDUの先頭)との差が2049SDUとなる。
この場合、ハンドオーバ後の再送時には、送信側のPDCPエンティティは、図7に示すHFN=1、First No Ack SN=10のPDCP SDUから順に再送を開始する。一方、ハンドオーバ後、受信側のPDCPエンティティは、FMSから2048SDU分を、再送待ち受信ウインドウ(Reordering window)とする。このとき、再送されるPDCP SDUには、HFNに関する情報が付加されていない。そのため、受信側のPDCPエンティティは、Reordering window内のHFNに基づいて、再送されるPDCP SDUに対応するHFNを判定する。そのため、受信側のPDCPエンティティは、送信側のPDCPエンティティが送信したHFN=1、SN=10のPDCP SDUを、Reordering window内のHFN=2、SN=10のPDCP SDUとして誤って受信してしまう。よって、受信側のPDCPエンティティは、図7に示すHFN=2、SN=10から2048分(Reordering windowの範囲)のPDCP SDUを受信できるようにReordering windowを移動する。
このように、ハンドオーバ後、送信側のPDCPエンティティは、PDCP status reportの通知を待たずに、First No Ack SNのPDCP SDUから順に再送すると、受信側のPDCPエンティティは、送信側のPDCPエンティティが再送するPDCP SDUを、誤って受信してしまうことがある。具体的には、送信側のPDCPエンティティにおけるFirst No Ack SNと、受信側のPDCPエンティティにおけるFMSとの差(図7では2049SDU)が、シーケンス番号1周分に相当するSDU(4096SDU)とReordering window(図7では2048SDU)との差(ここでは、2048SDU)よりも大きくなった場合、受信側のPDCPエンティティは、送信側のPDCPエンティティが再送するPDCP SDUを、誤って受信してしまうことがある。この場合、送受信側のPDCPエンティティ間でのHFNの不一致が発生し、かつ、HFNの不一致が以降継続する。よって、暗号化処理および復号処理のパラメータとしてHFNを含むCOUNTを用いても送受信間でのHFNの不一致によりPDCP SDUを正常に伝送することができなくなる。
そこで、本実施の形態に係る送信装置は、ハンドオーバ後、受信装置からのPDCP status reportを受信するまでは、PDCP SDUの再送を行わない。すなわち、送信装置は、ハンドオーバ後に、受信装置からのPDCP status reportを受信した場合、PDCP SDUを再送する。
以下、本実施の形態について具体的に説明する。
本実施の形態に係る送信装置100の送信指示部107(図4)は、ハンドオーバ後、自装置が受信装置200から送信されるPDCP status reportを受信するまでは送信データの再送を行わない。そして、送信指示部107は、ハンドオーバ後に自装置が受信装置200(図5)から送信されるPDCP status reportを受信した場合、そのPDCP status reportに含まれるFMSに示されるシーケンス番号に対応する送信データから順に送信データを再送する。
次に、本実施の形態に係る送信装置100の送信指示部107におけるPDCP SDUの送信制御処理の詳細について説明する。
以下の説明では、図8に示すように、図7と同様、PDCP SDUのシーケンス番号(PDCP SN)を0〜4059(つまり、4096SDU分)とする。また、Reordering windowを2048SDU分(シーケンス番号1周分に相当する4096SDUの半分)とする。また、図8では、図7と同様、送信装置100(送信側のPDCPエンティティ)における、First No Ack SNをHFN=1、SN=10とする。また、受信装置200(受信側のPDCPエンティティ)で未受信のPDCP SDUのうちの先頭のPDCP SDUをHFN=2、SN=2059とする。よって、PDCP status reportに含まれるFMSは2059を示す。
送信装置100の送信指示部107は、ハンドオーバ後、自装置が受信装置200からのPDCP status reportを受信した場合、PDCP SDUの再送を行うように制御する。つまり、送信指示部107は、ハンドオーバ後、自装置が受信装置200からのPDCP status reportを受信するまではPDCP SDUの再送を行わない。
ここで、受信装置200からのPDCP status reportを受信した場合には、図8に示すように、送信装置100の判定部108は、FMS(2059)に基づいて、HFN=1、SN=2059未満のPDCP SDU(HFN=2、SN=2058以前のPDCP SDU)が送達確認完了であると判断する。よって、データ破棄処理部110は、HFN=2、SN=2058以前のPDCP SDUを破棄するように、暗号化前データバッファ104および暗号化後データバッファ106に指示する。
これにより、図8に示すように、送信指示部107は、HFN=2、SN=2059のPDCP SDU(つまり、FMSが示すPDCP SDU)から順に、PDCP SDUの再送を開始する。
一方、受信装置200は、図8に示すHFN=2、SN=2059のPDCP SDU(つまり、FMSが示すPDCP SDU)を先頭として2048SDU分のPDCP SDU(つまり、HFN=1、SN=2059〜HFN=2、SN=10)を受信可能とする。よって、受信装置200は、送信装置100が送信したHFN=1、SN=2059のPDCP SDUを、Reordering window内のHFN=1、SN=2059のPDCP SDUとして正常に受信する。
このように、送信装置100は、ハンドオーバ後、受信装置200からのPDCP status reportを受信するまでは、ユーザデータ(PDCP SDU)の再送を行わない。これにより、送信装置100は、ハンドオーバ後には、再送対象の先頭(First No Ack SN)からFMS未満のPDCP SDUまでのPDCP SDUを必ず破棄する。換言すると、送信装置100は、ハンドオーバ後には、FMS以降のPDCP SDUを再送する。よって、送信装置100は、受信装置200が受信可能なPDCP SDU、つまり、Reordering window内のPDCP SDUから順に、PDCP SDUを再送する。なお、送信データの再送を行わない処理の代わりに、SN・HFN管理部103が暗号化処理部105に対して暗号化処理の指示を行わないことによっても、同様の効果を達成できる。
これにより、送信装置100が再送を開始するPDCP SDUと、受信装置200が再送を待ち受ける先頭のPDCP SDUとが一致する。すなわち、受信装置200は、送信装置100が再送するPDCP SDUに対応するHFNを、自装置が設定したReordering window内のHFNとして正常に特定することができる。そのため、図8に示すように、図7と同様、送信装置100におけるFirst No Ack SNと、受信装置200におけるFMSとの差(図8では2049SDU)が、シーケンス番号1周分に相当するSDU(4096SDU)とReordering window(図8では2048SDU)との差(ここでは、2048SDU)よりも大きくなった場合でも、受信装置200では、送信装置100が再送するPDCP SDUを、誤って受信することが無くなる。よって、送受信間で同一のHFNを用いてPDCP SDUの暗号化処理および復号処理が行われるため、PDCP SDUを正常に伝送することができる。
このようにして、本実施の形態によれば、送信装置は、PDCP status reportを受信後にPDCP SDUを再送することにより、受信装置でのPDCP SDUの受信状況を正確に把握することができる。再送が必要なPDCP SDUを正確に再送することができる。これにより、受信装置は、送信装置から再送されたPDCP SDUを、自装置が設定したReordering window内で誤りなく受信することができる。よって、本実施の形態によれば、実施の形態1と同様にして、ハンドオーバ後に送信されるPDCP status reportを用いて、再送対象とすべきPDCP SDUおよび破棄対象とすべきPDCP SDUを正確に特定し、ユーザデータを常に正常に伝送することができる。
以上、本発明の各実施の形態について説明した。
なお、本発明では、実施の形態1および実施の形態2を組み合わせて実施してもよい。具体的には、本発明に係る送信装置100(図4)は、ハンドオーバ前には、送達確認が未完了のPDCP SDUのうちの先頭のPDCP SDU(First No Ack SN)から、シーケンス番号1周分に相当するPDCP SDUより後のPDCP SDUを送信しないようにし、かつ、ハンドオーバ後には、自装置が受信装置からのPDCP status reportを受信するまではPDCP SDUの再送を行わないようにする。これにより、送信装置では、実施の形態1と同様にして、受信したPDCP status reportに含まれるFMSに対応するHFNの判定を確実に行うことができる。また、受信装置では、実施の形態2と同様にして、送信装置から再送されるPDCP SDUに対応するHFNを誤って特定することを防ぐことができる。
本発明は、携帯端末装置等のユーザ通信装置と基地局装置等のオペレータ通信装置との間においてパケットを通信するパケット通信システム等に有用である。
100 送信装置
200 受信装置
101 送達確認管理部
102 再送管理部
103,203 SN・HFN管理部
104 暗号化前データバッファ
105 暗号化処理部
106 暗号化後データバッファ
107 送信指示部
108,201 判定部
109 タイマ制御部
110 データ破棄処理部
202 復号前データバッファ
204 復号処理部
205 復号後データバッファ
206 Reordering window管理部
207 生成部
200 受信装置
101 送達確認管理部
102 再送管理部
103,203 SN・HFN管理部
104 暗号化前データバッファ
105 暗号化処理部
106 暗号化後データバッファ
107 送信指示部
108,201 判定部
109 タイマ制御部
110 データ破棄処理部
202 復号前データバッファ
204 復号処理部
205 復号後データバッファ
206 Reordering window管理部
207 生成部
Claims (3)
- データに対して有限のシーケンス番号を周回的に割り当て、前記シーケンス番号と前記シーケンス番号が何周目であるかを示す番号がそれぞれ割り当てられた前記データを送信し、かつ、ハンドオーバ前に第1のレイヤで送達確認が未完了のデータを、ハンドオーバ後に、前記第1のレイヤよりも上位レイヤである第2のレイヤで再送する送信装置であって、
前記第1のレイヤでのデータの送信を指示するとともに、ハンドオーバ後における前記第2のレイヤでのデータの再送を指示する送信指示手段と、
ハンドオーバ時に受信装置で未受信であるデータのうちの先頭データの前記シーケンス番号を示す制御情報を受信する受信手段と、
前記制御情報を受信した場合、前記送達確認が未完了のデータのうちの先頭データから、ハンドオーバ前に送信が完了したデータのうちの最後尾データまでの間で、前記制御情報に示されるシーケンス番号に対応するデータを特定する特定手段と、を具備し、
前記送信指示手段は、前記送達確認が未完了のデータのうちの先頭データから、シーケンス番号1周分に相当するデータまでの送信を指示し、前記送達確認が未完了のデータのうちの先頭データから前記シーケンス番号1周分に相当するデータより後のデータの送信を指示しない、
を具備する送信装置。 - 前記送信指示手段は、ハンドオーバ後、前記制御情報を受信するまではデータの再送を指示せず、ハンドオーバ後に前記制御情報を受信した場合、前記制御情報に示されるシーケンス番号に対応するデータから順にデータの再送を指示する、
請求項1記載の送信装置。 - データに対して有限のシーケンス番号を周回的に割り当て、前記シーケンス番号と前記シーケンス番号が何周目であるかを示す番号がそれぞれ割り当てられた前記データを送信し、かつ、ハンドオーバ前に第1のレイヤで送達確認が未完了のデータを、ハンドオーバ後に、前記第1のレイヤよりも上位レイヤである第2のレイヤで再送する送信装置における送信方法であって、
前記第1のレイヤでのデータの送信を指示するとともに、ハンドオーバ後における前記第2のレイヤでのデータの再送を指示する送信指示ステップと、
ハンドオーバ時に受信装置で未受信であるデータのうちの先頭データの前記シーケンス番号を示す制御情報を受信する受信ステップと、
前記制御情報を受信した場合、前記送達確認が未完了のデータのうちの先頭データから、ハンドオーバ前に送信が完了したデータのうちの最後尾データまでの間で、前記制御情報に示されるシーケンス番号に対応するデータを特定する特定ステップと、を具備し、
前記送信指示ステップは、前記送達確認が未完了のデータのうちの先頭データから、シーケンス番号1周分に相当するデータまでの送信を指示し、前記送達確認が未完了のデータのうちの先頭データから前記シーケンス番号1周分に相当するデータより後のデータの送信を指示しない、
送信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009207155A JP2011061364A (ja) | 2009-09-08 | 2009-09-08 | 送信装置および送信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009207155A JP2011061364A (ja) | 2009-09-08 | 2009-09-08 | 送信装置および送信方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2011061364A true JP2011061364A (ja) | 2011-03-24 |
Family
ID=43948521
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009207155A Pending JP2011061364A (ja) | 2009-09-08 | 2009-09-08 | 送信装置および送信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2011061364A (ja) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102769907A (zh) * | 2012-07-03 | 2012-11-07 | 中兴通讯股份有限公司 | 一种超帧号同步的方法、装置及系统 |
| WO2013137303A1 (ja) * | 2012-03-13 | 2013-09-19 | 株式会社エヌ・ティ・ティ・ドコモ | 移動局及び無線基地局 |
| CN103391612A (zh) * | 2012-05-09 | 2013-11-13 | 中兴通讯股份有限公司 | 重定位过程中的完整性保护技术器同步方法、系统及装置 |
| WO2014003121A1 (ja) * | 2012-06-29 | 2014-01-03 | 株式会社エヌ・ティ・ティ・ドコモ | 移動局及び無線基地局 |
| WO2014017223A1 (ja) * | 2012-07-25 | 2014-01-30 | 株式会社 エヌ・ティ・ティ・ドコモ | 移動通信システムにおける基地局及び通信方法 |
| JP2017153143A (ja) * | 2017-05-08 | 2017-08-31 | 株式会社Nttドコモ | 移動局及び無線基地局 |
| JP2018042276A (ja) * | 2014-05-08 | 2018-03-15 | 京セラ株式会社 | 通信システム、ユーザ端末、プロセッサ、及びセルラ基地局 |
| CN111345009A (zh) * | 2017-11-17 | 2020-06-26 | 株式会社Ntt都科摩 | 通信装置以及通信方法 |
-
2009
- 2009-09-08 JP JP2009207155A patent/JP2011061364A/ja active Pending
Cited By (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2827626A4 (en) * | 2012-03-13 | 2015-10-28 | Ntt Docomo Inc | MOBILE STATION AND WIRELESS BASE STATION |
| WO2013137303A1 (ja) * | 2012-03-13 | 2013-09-19 | 株式会社エヌ・ティ・ティ・ドコモ | 移動局及び無線基地局 |
| JP2013191972A (ja) * | 2012-03-13 | 2013-09-26 | Ntt Docomo Inc | 移動局及び無線基地局 |
| EP3544328A1 (en) * | 2012-03-13 | 2019-09-25 | NTT DoCoMo, Inc. | Mobile station and radio base station |
| US9485005B2 (en) | 2012-03-13 | 2016-11-01 | Ntt Docomo, Inc. | Mobile station and radio base station |
| CN103391612A (zh) * | 2012-05-09 | 2013-11-13 | 中兴通讯股份有限公司 | 重定位过程中的完整性保护技术器同步方法、系统及装置 |
| CN103391612B (zh) * | 2012-05-09 | 2018-01-09 | 中兴通讯股份有限公司 | 重定位过程中的完整性保护计数器同步方法、系统及装置 |
| WO2014003121A1 (ja) * | 2012-06-29 | 2014-01-03 | 株式会社エヌ・ティ・ティ・ドコモ | 移動局及び無線基地局 |
| JP2014011649A (ja) * | 2012-06-29 | 2014-01-20 | Ntt Docomo Inc | 移動局及び無線基地局 |
| CN102769907A (zh) * | 2012-07-03 | 2012-11-07 | 中兴通讯股份有限公司 | 一种超帧号同步的方法、装置及系统 |
| JP2014027387A (ja) * | 2012-07-25 | 2014-02-06 | Ntt Docomo Inc | 移動通信システムにおける基地局及び通信方法 |
| WO2014017223A1 (ja) * | 2012-07-25 | 2014-01-30 | 株式会社 エヌ・ティ・ティ・ドコモ | 移動通信システムにおける基地局及び通信方法 |
| JP2018042276A (ja) * | 2014-05-08 | 2018-03-15 | 京セラ株式会社 | 通信システム、ユーザ端末、プロセッサ、及びセルラ基地局 |
| US10154433B2 (en) | 2014-05-08 | 2018-12-11 | Kyocera Corporation | Communication control method |
| US10708815B2 (en) | 2014-05-08 | 2020-07-07 | Kyocera Corporation | Communication control method |
| JP2017153143A (ja) * | 2017-05-08 | 2017-08-31 | 株式会社Nttドコモ | 移動局及び無線基地局 |
| CN111345009A (zh) * | 2017-11-17 | 2020-06-26 | 株式会社Ntt都科摩 | 通信装置以及通信方法 |
| CN111345009B (zh) * | 2017-11-17 | 2023-10-31 | 株式会社Ntt都科摩 | 通信装置以及通信方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2906704T3 (es) | Procedimiento y aparato para el procesamiento de un paquete en un sistema de comunicación inalámbrica | |
| JP5281700B2 (ja) | 無線装置とネットワーク間のデータユニットのシーケンスの送信のための無線通信方法 | |
| CN107113291B (zh) | 演进的数据压缩方案信令 | |
| KR101577451B1 (ko) | Rlc 무한 재전송 오류를 검출하고 처리하는 방법 | |
| CN101965705B (zh) | 用于pdcp丢弃的方法和装置 | |
| CN101766003B (zh) | 在移动通信系统中发送pdcp层的状态报告的方法及移动通信接收机 | |
| CN106717096B (zh) | 用于处理用户平面数据的方法及装置 | |
| EP2136501B1 (en) | Method of delivering a PDCP data unit to an upper layer | |
| US8379855B2 (en) | Ciphering in a packet-switched telecommunications system | |
| KR101563008B1 (ko) | 무선통신 시스템에서 무선 베어러 해제 방법 및 수신기 | |
| EP2139292A2 (en) | Methods for synchronizing PDCP operations after RRC connection re-establishment in a wireless communication system and related apparatuses thereof | |
| EP3065456A1 (en) | User equipment and method | |
| KR20100053625A (ko) | 무선 통신 시스템에서의 핸드오버 동안 데이터의 계층 2 터널링 | |
| CN110739993A (zh) | 使用多个载波来发送和接收数据的方法和设备 | |
| JP2011504675A (ja) | サービス・データ・ユニット破棄タイマ | |
| JP2011061364A (ja) | 送信装置および送信方法 | |
| US8300583B2 (en) | Method for transmitting control information in a mobile communication system | |
| CN111133791A (zh) | 用于在无线通信系统中处理分组的方法和装置 | |
| KR20090084756A (ko) | 이동통신 시스템 및 그의 상태보고 전송 방법 | |
| JP2012529799A (ja) | Pdcp層の再確立方法及び装置 | |
| CN108282292B (zh) | 用于处理数据的方法、发送端和接收端 | |
| KR20100049759A (ko) | 재전송 요청을 위한 제어 메시지를 처리하는 방법 및 장치 | |
| CN104518851A (zh) | 一种数据处理方法及装置 | |
| GB2462699A (en) | Delivering PDCP SDUs to an upper layer within a receiving side entity of an E-UMTS | |
| JP6654828B2 (ja) | 送信機 |