JP2012169764A - 通信システム、送信制御装置及び送信制御方法 - Google Patents

通信システム、送信制御装置及び送信制御方法 Download PDF

Info

Publication number
JP2012169764A
JP2012169764A JP2011027426A JP2011027426A JP2012169764A JP 2012169764 A JP2012169764 A JP 2012169764A JP 2011027426 A JP2011027426 A JP 2011027426A JP 2011027426 A JP2011027426 A JP 2011027426A JP 2012169764 A JP2012169764 A JP 2012169764A
Authority
JP
Japan
Prior art keywords
entity
header
header decompression
transmission
rohc
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.)
Withdrawn
Application number
JP2011027426A
Other languages
English (en)
Inventor
Narimoto Yamaguchi
成基 山口
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Original Assignee
Panasonic Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Panasonic Corp filed Critical Panasonic Corp
Priority to JP2011027426A priority Critical patent/JP2012169764A/ja
Priority to PCT/JP2012/000911 priority patent/WO2012108215A1/ja
Publication of JP2012169764A publication Critical patent/JP2012169764A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

【課題】RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理を効率化することができる通信システム、送信制御装置及び送信制御方法を提供すること。
【解決手段】通信システムは、LTE PDCPレイヤ120においてRoHCによるヘッダ圧縮を実施するRoHCヘッダ圧縮エンティティ121を有する機器100と、機器100に無線伝搬環境300を通して接続され、RoHCによるヘッダ解凍を実施するRoHCヘッダ解凍エンティティ221を有する機器200とを備える。RoHCヘッダ解凍エンティティ221は、ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、RoHCフィードバックパケットを生成し、保管する。無線伝搬環境300が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、保管された複数のRoHCフィードバックパケットのうち、最新の1つのみをRoHCヘッダ圧縮エンティティ121に送信する。
【選択図】図9

Description

本発明は、携帯端末装置等のユーザ通信装置と基地局装置等のオペレータ通信装置との間においてパケットを通信する通信システム、送信制御装置及び送信制御方法に関する。
現在、3rd Generation Partnership Project(以下、3GPPという)のTechnical Specification Group Radio Access Network(TSG RAN)において、次世代移動通信システムであるLong Term Evolution(以下、LTEという)の検討が進められている。3GPP LTEでは、携帯端末装置(以下、UE:User Equipmentという)は、複数の基地局装置(以下、eNodeB:Evolved Node Bという)から構成されるE-UTRAN(Enhanced Universal Terrestrial Radio Access Network)に接続して、ユーザデータの送受信を行う。
図1は、LTE通信方式で使用されるネットワークアーキテクチャ(network architecture)を示す図である。
図1に示すように、UEは、複数の基地局(eNodeB)から構成されるE-UTRANに接続し、ユーザデータの送受信を行う。
ここで、UEとeNodeBとの間のユーザデータは、3GPP LTEで使用される通信プロトコルのレイヤ1(物理レイヤ)及びレイヤ2(データリンクレイヤ)で制御される。また、レイヤ2は、無線リソースの割当制御等を行うMAC(Medium Access Control)レイヤと、無線リンクの制御を行うRLC(Radio Link Control)レイヤと、データの暗号化・復号化、ハンドオーバ時のパケット順序制御等を行うPDCP(Packet Data Convergence Protocol)レイヤとに分けられる。
また、UE及びeNodeBの各PDCPレイヤには、通信経路(以下、無線ベアラ(Radio Bearer)という)が通信開始時に設定される。無線ベアラは、複数設定可能であり、1つの無線ベアラ毎にUE及びeNodeBそれぞれに対応するPDCPエンティティ(PDCP entity)が生成される。各PDCPエンティティは、無線ベアラを用いて送受信されるユーザデータに対する制御情報を保持する。
図2は、ユーザデータ制御系プロトコルスタックの配置を示す図である。
図2に示すように、UEとeNodeB間のユーザデータは、LTE通信プロトコルレイヤ1、レイヤ2(MAC/RLC/PDCP)により制御される。UE、eNodeBそれぞれのRLC/PDCPレイヤには、通信開始時に無線ベアラ(Radio Bearer)が設定される。無線ベアラは、複数起動可能である。無線ベアラ1本につきUE、eNodeBそれぞれに対応するRLC/PDCP entityが生成され、無線ベアラを通る送受信データに対する制御情報が保持される。
無線ベアラには大きく3つ、レイヤ3(RRC/NAS)の通信制御メッセージを送受信するSignalling Radio Bearer(SRB)、ユーザデータのうちRLCレイヤにて送達確認が取れるまで再送するData Radio Bearer - Acknowledged Mode (DRB-AM)、ユーザデータのうちRLCレイヤにて送達確認を行わないData Radio Bearer - Unacknowledged Mode (DRB-UM)に分類される。以下、DRB-AMとDRB-UMを合わせてDRBと呼ぶ。
図3は、PDCPレイヤ機能構成を示す図である。
3GPP LTE規格において、PDCPレイヤにてIPヘッダ圧縮(RoHC)を適用可能であることが規定されている。RoHC適用対象となるデータはDRB上を流れるユーザデータとなる。RoHCにより圧縮可能なヘッダとして、RTP、UDP、TCP、IPのヘッダがあり、それぞれのヘッダ圧縮方法がプロファイルとして規定されている。
PDCPレイヤ 送信エンティティには、RoHCヘッダ圧縮エンティティが存在し、ciphering実施前にRoHCによるヘッダ圧縮を実施する。PDCPレイヤ受信エンティティには、RoHCヘッダ解凍エンティティが存在し、deciphering実施後にRoHCによるヘッダ解凍を実施する(図3参照)。
RoHCによるヘッダ圧縮が実施されているとき、RoHCヘッダ解凍エンティティは、RoHCヘッダ圧縮エンティティ宛にRoHCフィードバックパケットを送信できる。RoHCフィードバックパケットは、PDCP control pduによりPDCPレイヤ受信エンティティ(RoHCヘッダ解凍エンティティ)からPDCPレイヤ送信エンティティ(RoHCヘッダ圧縮エンティティ)へと一方向に送信される。RoHCフィードバックパケットを含むPDCP control pduは、RoHCフィードバックパケット以外のデータ(ユーザデータ、PDCPステータスレポート)を含まず、RoHCフィードバックパケット1つだけ含めることができる。
RoHCフィードバックパケットには、RoHCヘッダ解凍エンティティにおけるヘッダ解凍成功、失敗情報、その他RoHC圧縮プロファイルに応じてオプションフィールドが含まれる。RoHCフィードバックパケットを使用し、RoHC圧縮、解凍エンティティの圧縮状態の同期を取ることや、各圧縮状態での動作、圧縮状態の遷移を制御する制御モード切替などを行う。
図4は、RoHCヘッダ圧縮エンティティ状態を説明する図である。
図4に示すように、RoHCヘッダ圧縮エンティティにはIR(Initialization and Refresh)状態、FO(First Order)状態、SO(Second Order)状態の3つの圧縮状態が存在する。
IR状態では、RoHCヘッダ圧縮エンティティは圧縮対象となるヘッダ情報を圧縮せず、すべてのヘッダ情報をRoHCヘッダ解凍エンティティへ送信する。
FO状態では、RoHC圧縮対象ヘッダ情報のうち、静的フィールド(パケット単位でほとんど変動しないパラメータ)のほとんどを圧縮する。一部の静的フィールドと動的フィールド(パケット単位で変動するパラメータ)は圧縮せずにRoHCヘッダ解凍エンティティへと送信される。
SO状態では、ヘッダの圧縮率が最高となる。RoHCヘッダ圧縮エンティティからはRTPシーケンス番号のみを送信することで、RoHCヘッダ解凍エンティティで対象ヘッダの復元が可能となる。
図5は、RoHCヘッダ解凍エンティティ状態を説明する図である。
図5に示すように、RoHCヘッダ解凍エンティティには、NC(No Context)状態、SC(Static Context)状態、FC(Full Context)状態の3つの状態が存在する。RoHCヘッダ解凍エンティティの初期状態はNC状態であり、ヘッダ解凍に必要な情報(ヘッダ解凍コンテキスト)がなく解凍処理を正しく実施できない状態となる。RoHCヘッダ解凍エンティティは、ヘッダ解凍コンテキストを受信するとFC状態へと遷移する。以降は連続的なヘッダ解凍失敗を契機にSC状態、NC状態へと遷移することになる。
図6は、RoHCヘッダ圧縮エンティティ制御モードを説明する図である。
RoHCヘッダ圧縮エンティティにおいては、各ヘッダ圧縮状態における動作、ヘッダ圧縮状態遷移を決める制御モードが存在する。
図6に示すように、制御モードには、U-mode(Unidirectional mode:単方向モード)、O-mode(Bidirectional Optimistic mode:双方向楽観モード)、R-mode(Bidirectional Reliable mode:双方向信頼性モード)の3つのモードが存在する。最適なモードは、RoHCが使用される環境(フィードバッグ応答時間、伝送路のエラー率、ヘッダサイズのバリエーションなど)に依存する。
U-modeでは、RoHCフィードバックパケットを使用しない。高圧縮状態への遷移(IR→FO→SO)は、一定数のパケットを送信することで実施する。低圧縮状態への遷移(SO→FO、SO→IR、FO→IR)は一定周期毎に実施し、ヘッダ解凍に必要な情報をRoHCヘッダ解凍エンティティへ送信する。
O-modeでは、RoHCフィードバックパケットを使用し、RoHCヘッダ解凍エンティティからRoHCヘッダ圧縮エンティティへ異常復旧要求(ヘッダ解凍コンテキスト更新要求)を行う。またRoHCフィードバックパケットにより重要なヘッダ解凍コンテキストを受信した場合の応答を実施することもできる(オプション機能)。
R-modeでは、より積極的にRoHCフィードバックパケットを使用する。RoHCヘッダ圧縮エンティティは、RoHCフィードバックパケットによるヘッダ解凍成功通知(ACK)を受信することで高圧縮状態へ遷移し、RoHCフィードバックパケットによるヘッダ解凍コンテキスト更新要求(NACK、STATIC NACK)を受信することで低圧縮状態へ遷移する。
RoHCヘッダ圧縮エンティティにおける制御モード(U-mode、O-mode、R-mode)の遷移は、RoHCヘッダ解凍エンティティが決定する。RoHCヘッダ解凍エンティティはRoHCフィードバックパケットに制御モードパラメータを付与し、RoHCヘッダ圧縮エンティティはRoHCフィードバックパケット受信時に制御モードパラメータを確認して制御モード遷移の要否を確認する。
ヘッダ解凍コンテキストは、RoHCヘッダ解凍エンティティ内に複数生成されることがある。RoHCヘッダ圧縮エンティティ内にもまた、ヘッダ解凍コンテキストに対応した圧縮状態、制御モードを複数管理することになる。対応するヘッダ解凍コンテキスト、RoHCヘッダ圧縮エンティティ内の圧縮状態、制御モードをRoHCコンテキストと呼び、コンテキスト識別子(CID)で区別している。
以上は、例えば非特許文献1、2及び3に記載されている。
3GPP TS36.323 Evolved Universal Terrestrial Radio Access (E-UTRA);Packet Data Convergence Protocol (PDCP) specification(Release 8) IETF RFC 3095: "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed". IETF RFC 4815: "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095".
しかしながら、上述したRoHCフィードバックパケット送信制御にあっては、無線環境劣化に伴い送信不可となった状況において、解凍エンティティより送信するRoHCフィードバックパケットが複数蓄積されると、無駄になる可能性がある。以下、具体的に説明する。
図7は、蓄積したRoHCフィードバックパケットが無駄になる例を示す図である。
図7(a)に示すように、無線環境劣化に伴いRoHCヘッダ解凍エンティティ(UE or eNodeB)からデータ送信不可となった場合、RoHCヘッダ解凍エンティティより送信するRoHCフィードバックパケットが複数生成され蓄積することがある。図7(b)に示すように、無線環境が改善し、UEからのデータ送信が再開した際、蓄積されたRoHCフィードバックパケットがRoHCヘッダ圧縮エンティティへと配送されることになるが、古いRoHCフィードバックパケットを受けることによりRoHCヘッダ圧縮エンティティが不用な状態遷移をすることがある。
RoHCヘッダ圧縮エンティティは、RoHCフィードバックパケットによりヘッダ解凍成功通知(ACK)を受信することで高圧縮状態へ遷移し、RoHCフィードバックパケットによるヘッダ解凍コンテキスト更新要求(NACK、STATIC NACK)を受信することで低圧縮状態へ遷移する。ヘッダ解凍成功通知(ACK)が複数蓄積された後に、ヘッダ解凍コンテキスト更新要求(NACK、STATIC NACK)が生成されて送信保留されていた場合、ヘッダ解凍成功通知(ACK)を受取ったRoHCヘッダ圧縮エンティティは高圧縮状態へ遷移してしまう。しかし、ヘッダ解凍コンテキスト更新要求(NACK、STATIC NACK)を受けた時点で再び低圧縮状態へ遷移する必要があるため、高圧縮状態へ遷移させるだけ無駄となってしまう。
高圧縮状態へ遷移した際にRoHCヘッダ圧縮エンティティがユーザデータのヘッダ圧縮処理を実施してRoHCヘッダ解凍エンティティへと送信した場合、RoHCヘッダ解凍エンティティは、すでにヘッダ解凍コンテキスト更新が必要な状態となっており、ヘッダ解凍に失敗して破棄となる可能性が高い。
また、RoHCヘッダ圧縮エンティティの制御モード遷移もまたRoHCフィードバックパケットにより行われるが、RoHCヘッダ解凍エンティティは、RoHCヘッダ圧縮エンティティから期待する応答パケットを受信しない限り、同じモード遷移を意図したRoHCフィードバックパケットを再送する。同じモード遷移を意図したRoHCフィードバックパケットは、制御モード遷移時に1つ受信できれば十分であることから、無線環境劣化が理由で蓄積したモード遷移用のフィードバックパケットをすべて送信する必要はない。
本発明の目的は、RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理を効率化することができる通信システム、送信制御装置及び送信制御方法を提供することである。
本発明の通信システムは、ヘッダ圧縮を実施するヘッダ圧縮エンティティを有する第1機器と、前記第1機器に無線伝搬環境を通して接続され、ヘッダ解凍を実施するヘッダ解凍エンティティを有する第2機器と、を備える通信システムであって、前記ヘッダ解凍エンティティは、ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、フィードバックパケットを生成する生成手段と、生成したフィードバックパケットを保管する保管手段と、前記無線伝搬環境が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、前記保管手段により保管された複数の前記フィードバックパケットのうち、最新のN(Nは任意の自然数)個を前記ヘッダ圧縮エンティティに送信する送信手段と、を備え、前記ヘッダ圧縮エンティティは、前記ヘッダ解凍エンティティから送信された前記フィードバックパケットを用いて、圧縮状態の変更、前記ヘッダ解凍エンティティで必要とするヘッダ解凍コンテキスト情報の送信、又は圧縮状態の遷移を制御する制御モード切替を行う構成を採る。
本発明の送信制御装置は、ヘッダ圧縮を実施するヘッダ圧縮エンティティを有する第1機器と、前記第1機器に無線伝搬環境を通して接続され、前記ヘッダ解凍を実施するヘッダ解凍エンティティを有する第2機器と、を備え、前記ヘッダ解凍エンティティは、ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、フィードバックパケットを生成する生成手段と、生成したフィードバックパケットを保管する保管手段と、前記無線伝搬環境が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、前記保管手段により保管された複数の前記フィードバックパケットのうち、最新のN(Nは任意の自然数)個を前記ヘッダ圧縮エンティティに送信する送信手段と、を備える構成を採る。
本発明の送信制御方法は、ヘッダ圧縮を実施するヘッダ圧縮エンティティを有する第1機器と、前記第1機器に無線伝搬環境を通して接続され、ヘッダ解凍を実施するヘッダ解凍エンティティを有する第2機器と、を備える通信システムの送信制御方法であって、前記ヘッダ解凍エンティティでは、ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、フィードバックパケットを生成するステップと、生成したフィードバックパケットを保管するステップと、前記無線伝搬環境が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、保管された複数の前記フィードバックパケットのうち、最新のN(Nは任意の自然数)個を前記ヘッダ圧縮エンティティに送信するステップと、を有する。
本発明によれば、LTE PDCPレイヤにてIPヘッダ圧縮(RoHC)を実施している際に発生するRoHCフィードバックパケット送信を、特定条件下では送信しないようにすることにより、RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理を効率化することができる。
その結果、RoHCフィードバックパケットが無駄に送信されるのを抑制することで、無線リソース、メモリリソースをユーザデータ送信に有効に活用することができる。また、RoHCフィードバックパケットによるRoHCヘッダ圧縮エンティティの冗長な状態遷移を抑制することができる。
LTE通信方式で使用されるネットワークアーキテクチャを示す図 ユーザデータ制御系プロトコルスタックの配置を示す図 PDCPレイヤ機能構成を示す図 RoHCヘッダ圧縮エンティティ状態を説明する図 RoHCヘッダ解凍エンティティ状態を説明する図 RoHCヘッダ圧縮エンティティ制御モードを説明する図 蓄積したRoHCフィードバックパケットが無駄になる例を示す図 本発明を実施した場合のRoHCフィードバックパケット(ACK,NACK)欠損の影響について説明する図 本発明の実施の形態に係る通信システムの構成を示す機能ブロック図
以下、本発明の実施の形態について図面を参照して詳細に説明する。
(原理説明)
まず、本発明の基本的な考え方について説明する。
従来、無線環境劣化に伴い送信不可となった状況において、RoHCヘッダ解凍エンティティより送信するRoHCフィードバックパケットが複数蓄積されると、無駄になる可能性がある。
(1)mode遷移ケース
D_TRANS=Iの間、RoHCヘッダ解凍エンティティは、RoHCフィードバックパケットをパケット受信毎に送信となっているが、RoHCヘッダ圧縮エンティティ側には1つでも届けばよい。
D_TRANS=Pの間、RoHCヘッダ解凍エンティティは、RoHCフィードバックパケットをパケット受信毎、もしくは一定期間毎に送信とすることが可能であるが、RoHCヘッダ圧縮エンティティ側には1つでも届けばよい。
すなわち、送信停止中に蓄積されたRoHCフィードバックパケットをすべて送る必要はない。
(2)状態遷移ケース
ACKで高圧縮状態へ、NACKで低圧縮状態への遷移を行う可能性がある。
NACK送信時は、RoHCヘッダ圧縮エンティティとRoHCヘッダ解凍エンティティ間で同期が外れた可能性があり、早急にRoHCヘッダ圧縮エンティティを低圧縮状態に戻す必要がある。送信停止中にACK数個の後にNACK1つが生成された場合、最後のNACK1つを送信して再同期をトリガできればよい。
すなわち、送信停止中に蓄積されたRoHCフィードバックパケットをすべて送る必要はない。
そこで、本発明は、無線環境劣化に伴い送信停止した状況において、RoHCフィードバックパケットが複数蓄積されても最新のN(Nは任意の自然数)個を送信バッファに保管して古いものは削除する。上記最新のN個は、特に最新の1個のみであることが好ましい。
例えば、無線環境劣化に伴い送信停止した状況において、RoHCフィードバックパケットが複数蓄積されても、RoHCコンテキスト毎に最新の1個を保管する。具体的には、PDCPレイヤが下位レイヤ(RLC/MAC/etc)より送信停止通知を受けた際、RoHCフィードバックパケットを最新の1個のみ送信バッファに保管する。この場合、PDCPレイヤより下位レイヤ(RLC/MAC/etc)に対してRoHCフィードバックパケットの送信要求実施後に送信停止となった場合、RoHCフィードバックパケット破棄要求をPDCPレイヤから下位レイヤ(RLC/MAC/etc)に対して実施してもよい。
これにより、RoHCフィードバックパケット送信のための無線リソース、メモリリソースを節約できる。
以下、本発明を実施した場合のRoHCフィードバックパケット(ACK,NACK)欠損の影響について検討する。
図8は、RoHCフィードバックパケット(ACK,NACK)欠損の影響について説明する図である。
図8(a)に示すように、解凍エンティティ状態では、No Context⇔Static Context⇔Full Contextを遷移する。
復元側状態では、はじめは、No Contextから始まる。No Contextでは、復元側は、まだパケットを正しく復元できない状態である。復元に必要な情報(各パラメータが動的であるか、静的であるかの情報を含むパケット)を取得した場合、Full Contextへ遷移する。そして、復元NGが連続する場合には、下位の状態へ遷移していく。最初は、Full ContextからStatic Contextに遷移する。復元側が、Static Context状態のときに、圧縮側がFO状態で送信したパケットを、受信できた場合には、再びFull Contextに遷移する。圧縮側がFO状態で送信したパケットの受信に失敗した場合には、No Contextに戻る。
図8(b)に示すように、圧縮エンティティ状態では、IR⇔FO⇔SO(SOが上位状態)を遷移する。
(1)ACK 2つを連続して送信予定であったが、1つ(先に送信する方)が欠損した場合
この場合、圧縮エンティティの2回の上位状態への遷移(IR→FO→SO)が、1回の上位状態への遷移(IR→FO)となる可能性がある。SO状態への遷移が遅れ、冗長なヘッダフィールドを数回送信する可能性がある。しかし、解凍失敗とはならず、冗長なヘッダフィールドを数回送信するという軽微な影響にとどまる。
(2)NACK 2つを連続して送信予定であったが、1つ(先に送信する方)が欠損した場合
NACKでは、RoHCヘッダ解凍エンティティで更新が必要な情報も通知する。更新必要情報の内容次第でRoHCヘッダ圧縮エンティティは、FO or IR状態へ遷移するので、先に送信予定であったNACKが欠損することによる影響はない。すなわち、本発明を実施した場合のRoHCフィードバックパケット(ACK,NACK)欠損の影響はない。
(3)ACK→NACKと送信予定であったが、先に送信するACKが欠損した場合
圧縮エンティティの1回の上位状態への遷移がなくなる可能性がある。但し、その後のNACK受信によるRoHCヘッダ圧縮エンティティの下位状態への遷移は、更新必要情報次第で一意に決まるので、RoHCヘッダ解凍エンティティの更新は遅れない。すなわち、本発明を実施した場合のRoHCフィードバックパケット(ACK,NACK)欠損の影響はない。
(4)NACK→ACKと送信予定であったが、先に送信するNACKが欠損した場合
一度解凍失敗した後に、情報更新無しで解凍成功するケースはまず考えられない。
本ケースはこれ以前にもNACKを送信していて、更新情報が送信されて来ていたために解凍成功したと考えられる。NACKを送ることで無用に更新情報を要求することになるため、送らない方が状態同期上は都合がよいメリットがある。
(5)Mode Transition時
RoHCフィードバックパケットが1つ届けば遷移シーケンスが進むので欠損しても影響はない。
(実施の形態)
図9は、上記基本的な考え方に基づく本発明の実施の形態に係る通信システムの構成を示す機能ブロック図である。本実施の形態は、LTE通信プロトコル PDCPレイヤ上で動作するRoHC制御における、RoHCフィードバックパケット送信制御について適用した例である。図9においては、RoHCフィードバックパケット送信制御に直接関係しない機能ブロックの記載は省略されている。
図9に示すように、通信システムは、RoHCヘッダ圧縮エンティティ121を起動している機器100と、RoHCヘッダ解凍エンティティ221を起動している機器200と、無線伝搬環境300とを含む。
RoHCヘッダ圧縮エンティティ121を起動している機器100は、例えばUE(携帯端末装置)であり、RoHCヘッダ解凍エンティティ221を起動している機器200は、例えばeNodeBである。
RoHCヘッダ圧縮エンティティ121及びRoHCヘッダ解凍エンティティ221は、実際にはUEとeNodeBの、それぞれに両方共が存在していることから、機器100をeNodeB、機器200をUEとして見ることも可能である。なお、RoHCヘッダ圧縮処理及びCipher処理が、機器100及び機器200において起動済みであるという前提で以降を説明する。
機器100内の上位レイヤ110(ユーザデータ系)からPDCPレイヤ120に対してPDCP SDUが送信される。PDCPレイヤ120では、まずRoHCヘッダ圧縮エンティティ121において対象ヘッダの圧縮処理を実施する。その後、Cipher処理部122にて暗号化を行い、PDCP PDU生成部123にてPDCPヘッダを付与する。PDCP PDUは、下位レイヤ130(RLC/MAC/PHY)へと送信され、無線伝搬環境300を通して機器200へと転送される。
機器200では、下位レイヤ230(RLC/MAC/PHY)により無線伝搬環境300からデータを受信し、PDCP PDUが受信された場合にはPDCPレイヤ220へと送信される。PDCP PDUはPDCPレイヤ220内のPDCP PDU解析部223は、PDCP CONTROL PDUかPDCP DATA PDU(ユーザデータ)かを判定し、PDCP DATA PDU(ユーザデータ)についてはDecipher処理部222へと送信する。PDCP DATA PDU(ユーザデータ)は、Decipher処理部222で暗号化解除処理を実施し、RoHCヘッダ解凍エンティティ221にて対象ヘッダの解凍処理を実施した上で上位レイヤ215(ユーザデータ系)へと送信される。
RoHCヘッダ解凍エンティティ221では、制御モードに応じてRoHCフィードバックパケットを生成することがある。例として、RoHCヘッダ解凍処理が正常に実施できた場合にヘッダ解凍成功通知(ACK)、RoHCヘッダ解凍処理が一定回数失敗した場合にヘッダ解凍コンテキスト更新要求(NACK、STATIC NACK)を設定したRoHCフィードバックパケットを生成する。RoHCフィードバックパケットが欠損することを考慮し、RoHCヘッダ解凍実施毎にRoHCフィードバックパケットを生成することもあれば、一定時間毎に同じRoHCフィードバックパケットを再送するような動作もありうる。
RoHCヘッダ解凍エンティティ221で生成されたRoHCフィードバックパケットは、RoHCフィードバックパケット保管部225に一度格納され、PDCP PDU生成部224にてPDCP CONTROL PDU内に格納して下位レイヤ230(RLC/MAC/PHY)へ送信される。
無線伝搬環境300を通して機器100の下位レイヤ130(RLC/MAC/PHY)で受信されたPDCP CONTROL PDUは、PDCPレイヤ120へと送信される。PDCPレイヤ120内では、PDCP PDU解析部124にてPDCP CONTROL PDUを確認し、RoHCフィードバックパケットであればRoHCヘッダ圧縮エンティティ121へと送信する。RoHCヘッダ圧縮エンティティ121では、RoHCフィードバックパケットの内容を確認し、圧縮状態の変更、RoHCヘッダ解凍エンティティ221で必要としているRoHCヘッダ解凍コンテキスト情報の送信、制御モードの変更などを実施する。
[無線伝搬環境300が劣化した場合]
無線伝搬環境300が良好である場合は、上記動作を繰り返すのみである。しかし、無線伝搬環境300が劣化して伝送エラー率が高くなる、もしくはまったく送信できなくなるといった状況も発生する。このような状況において、機器200から機器100への送信を継続していると、送信しきれないデータが下位レイヤ230(RLC/MAC/PHY)に蓄積することで送信データ用リソースが枯渇してしまう。送信データ用リソース管理部231は、送信データ用リソース枯渇を確認すると、データ流入を一時的に止めるためにPDCPレイヤ220へ送信停止要求を行う。PDCP PDU生成部224は、送信停止要求を受けて、PDCP DATA PDU、PDCP CONTROL PDUの生成を停止する。
PDCP PDU生成部224でのPDCP PDU生成処理が停止した状況(PDCP送信停止状況)においても、PDCP PDU解析部223、Decipher処理部222、RoHCヘッダ解凍エンティティ221といったユーザデータ処理は停止せずに動作を継続可能である。PDCP送信停止状況において、RoHCヘッダ解凍エンティティ221で生成されたRoHCフィードバックパケットは、RoHCフィードバックパケット保管部225に格納し、それ以前に生成されてRoHCフィードバックパケット保管部225に格納されていたRoHCフィードバックパケットは、破棄する。RoHCフィードバックパケットを破棄する際には、CIDを確認して同じCIDのものだけを破棄する動作としてもよい。
[無線伝搬環境300が良好になった場合]
無線伝搬環境300が良好になり、下位レイヤ230(RLC/MAC/PHY)に蓄積していた送信用データが送信再開すると、送信データ用リソース枯渇も解消する。送信データ用リソース管理部231は、送信データ用リソース枯渇の解消を確認し、PDCPレイヤ220へ送信再開要求を送信する。送信再開要求を受信したPDCP PDU生成部224は、RoHCフィードバックパケット保管部225に格納されたRoHCフィードバックパケットをPDCP CONTROL PDUに入れて下位レイヤ(RLC/MAC/PHY)230へ送信する。RoHCフィードバックパケットは、下位レイヤ(RLC/MAC/PHY)230から無線伝搬環境300を経由して機器100の下位レイヤ(RLC/MAC/PHY)130で受信される。受信データがPDCP PDUの場合、PDCPレイヤ120におけるPDCP PDU解析部124に送信される。PDCP PDU解析部124では、PDCP PDUのヘッダ部分を解析し、RoHCフィードバックパケットであればPoHCヘッダ圧縮エンティティ121へ送信する。
以下、本実施の形態の通信システムのRoHCフィードバックパケット送信制御の具体的動作について説明する。
[ケース1]
伝搬環境劣化中にRoHCフィードバックパケット ヘッダ解凍成功通知(ACK)が2つ生成された場合、RoHCヘッダ解凍エンティティ221は、先に生成されたRoHCフィードバックパケット ACKを破棄し、RoHCフィードバックパケット ACKを1つ送信バッファに保管する。その後、伝搬環境が良化するとRoHCフィードバックパケットの送信も可能となる。
RoHCフィードバックパケットACKが一つ欠損することで、RoHCヘッダ圧縮エンティティ121の状態遷移(高圧縮側への遷移)ができず、次のフィードバックパケット ACKを待つことになる可能性がある。次のフィードバックパケット ACKが受信されるまでの間、RoHCヘッダ圧縮エンティティ121は、低い圧縮率で対象ヘッダを圧縮処理することになり、ヘッダ解凍コンテキスト情報を冗長に送信するなどの影響が考えられる。但し、RoHCヘッダ解凍エンティティ221でのヘッダ解凍失敗には繋がらず、影響としては軽微であると判断できる。
[ケース2]
伝搬環境劣化中にRoHCフィードバックパケット ヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)が2つ生成された場合、RoHCヘッダ解凍エンティティ221は、先に生成されたRoHCフィードバックパケット NACK or STATIC NACKを破棄し、RoHCフィードバックパケット NACK or STATIC NACKを1つ送信バッファに保管する。その後、伝搬環境が良化すると、RoHCフィードバックパケット NACK or STATIC NACKがRoHCヘッダ圧縮エンティティ121に送信される。この場合、RoHCフィードバックパケット NACK or STATIC NACKが一つ欠損することによる影響は無い。RoHCフィードバックパケット NACK or STATIC NACKは、NACKならIR、STATIC NACKならFOといったように状態の遷移先が一意に決まっているため、破棄した方が無駄に状態遷移することがなく有利であると言える。
[ケース3]
伝搬環境劣化中にRoHCフィードバックパケット ACKが生成され、後からRoHCフィードバックパケット NACK or STATIC NACKが生成された場合、RoHCヘッダ解凍エンティティ221は、先に生成されたRoHCフィードバックパケット ACKを破棄する。伝搬環境が良化すると、RoHCフィードバックパケット NACK or STATIC NACKがRoHCヘッダ圧縮エンティティ121に送信される。この場合、RoHCフィードバックパケット ACKが欠損することによる影響は無い。ケース2で記載したように、RoHCフィードバックパケット NACK or STATIC NACKは状態遷移先が一意に決まっているため、RoHCフィードバックパケット ACKによる無駄な高圧縮状態への遷移が発生しない分有利であると言える。
[ケース4]
伝搬環境劣化中にRoHCフィードバックパケット NACK or STATIC NACKが生成され、後からRoHCフィードバックパケット ACKが生成された場合、RoHCヘッダ解凍エンティティ221は、先に生成されたRoHCフィードバックパケットNACK or STATIC NACKを破棄する。伝搬環境が良化すると、RoHCフィードバックパケット ACKがRoHCヘッダ圧縮エンティティ121に送信される。ヘッダ解凍コンテキスト更新要求を送信した後にヘッダ解凍成功通知が生成された例である。
伝搬環境劣化以前にヘッダ解凍コンテキスト更新要求がRoHCヘッダ圧縮エンティティ121へ送信されていて、RoHCヘッダ圧縮エンティティ121がヘッダ解凍コンテキスト情報をRoHCヘッダ解凍エンティティ221へ送信した後に伝搬環境が劣化した場合などである。ヘッダ解凍コンテキスト情報を受信できたRoHCヘッダ解凍エンティティ221が時正常にヘッダ解凍できるようになったためにRoHCフィードバックパケット NACK or STATIC NACKの後にRoHCフィードバックパケット ACKが生成されたと考えられる。
ケース4については、RoHCフィードバックパケット NACK or STATIC NACKを送信してしまうことで、RoHCヘッダ圧縮エンティティ121の状態が低圧縮状態に遷移し、ヘッダ解凍コンテキスト情報を冗長に送信してしまうことから、破棄したほうが有利であると言える。
上述したように、RoHCフィードバックパケットが無駄に送信されるのを抑制することで、無線リソース、メモリリソースをユーザデータ送信に有効に活用することができる。また、RoHCフィードバックパケットによるRoHCヘッダ圧縮エンティティ121の冗長な状態遷移を抑制することができる。
以上詳細に説明したように、本実施の形態によれば、通信システムは、LTE PDCPレイヤ120においてRoHCによるヘッダ圧縮を実施するRoHCヘッダ圧縮エンティティ121を有する機器100と、機器100に無線伝搬環境300を通して接続され、RoHCによるヘッダ解凍を実施するRoHCヘッダ解凍エンティティ221を有する機器200とを備える。RoHCヘッダ解凍エンティティ221は、ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、RoHCフィードバックパケットを生成し、生成したRoHCフィードバックパケットを保管する。そして、無線伝搬環境300が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、保管された複数のRoHCフィードバックパケットのうち、最新の1つのみをRoHCヘッダ圧縮エンティティ121に送信する。
すなわち、RoHCヘッダ解凍エンティティ221は、無線環境劣化に伴い送信停止した状況においてRoHCフィードバックパケットが生成された場合、複数蓄積せずに最新の1個のみ送信バッファに保管して以前に生成したRoHCフィードバックパケットは削除する。RoHCフィードバックパケットが無駄に送信されるのを抑制することで、無線リソース、メモリリソースをユーザデータ送信に有効に活用することができる。また、RoHCフィードバックパケットによるRoHCヘッダ圧縮エンティティ121の冗長な状態遷移を抑制することができる。
また、状態管理が異なることからRoHCコンテキスト毎に最新のRoHCフィードバックパケットを一つ保管することが望ましいが、処理を簡略化するためにRoHCヘッダ解凍エンティティ221 1つにつき最新のRoHCフィードバックパケットを1つ保管するという動作としてもよい。
また、RoHCヘッダ解凍エンティティ221が存在するPDCPレイヤ220より下位のレイヤ(RLC/MAC/PHY)230に対してRoHCフィードバックパケットを送信要求してしまっており、送信完了通知を受けないうちに伝搬環境劣化が発生した場合、最新のRoHCフィードバックパケットが生成されたタイミングでPDCPレイヤ220より下位のレイヤ(RLC/MAC/PHY)230に対してRoHCフィードバックパケット破棄要求を実施してもよい。
ところで、PDCP PDU生成部224がPDCP DATA PDU、PDCP CONTROL PDUの生成を停止するケースとして、上位レイヤ(RRC)210からのRB suspend要求を実施されることによる生成停止のケースもある。
上位レイヤ(RRC)210は、ハンドオーバ、再接続(RRC Connection Re-establishment)処理を実施する際にはPDCPレイヤ220に対してRB suspend要求を送信する。ハンドオーバ、再接続処理が完了次第、上位レイヤ(RRC)210からPDCPレイヤ220に対してRB resume要求を送信し、この要求を受けてPDCP PDU生成部224のPDCP PDU生成処理を再開する。RB suspendによるPDCP PDU生成処理停止中もまた、PDCP PDU解析部223、Decipher処理部222、RoHCヘッダ解凍エンティティ221といったユーザデータ処理は停止せずに動作を継続可能であり、RoHCヘッダ解凍エンティティ221からはRoHCフィードバックパケットが複数生成される可能性がある。ただ、ハンドオーバ、再接続処理が完了した後には、RoHCコンテキスト(RoHCヘッダ圧縮エンティティ121における圧縮状態、RoHCヘッダ解凍エンティティ221におけるRoHCヘッダ解凍コンテキスト)がリセットされる。つまり、ハンドオーバ、再接続前のRoHCヘッダ解凍コンテキストにおいて生成されたRoHCフィードバックパケットは、ハンドオーバ、再接続後に送信せずに破棄する必要がある。
本実施の形態では、RB suspend中においてもRoHCフィードバックパケット保管部225に最新のRoHCフィードバックパケットを1つだけ保持する動作となることから、破棄予定となるRoHCフィードバックパケットのために必要以上のメモリリソースを使用することはなく、またRB resume要求受信時にRoHCフィードバックパケット保管部225のデータをクリアするだけで、ハンドオーバ、再接続前のRoHCフィードバックパケットをハンドオーバ、再接続後に送信しないという動作を容易に実現できるというメリットも存在する。
以上の説明は本発明の好適な実施の形態の例証であり、本発明の範囲はこれに限定されることはない。
本実施の形態では、適用例として3GPP LTE通信プロトコルスタックを基に記載しているが、本発明の範囲はこれに限定するものではない。RoHCを適用可能なシステムであり、RoHCヘッダ解凍エンティティが存在する機器、端末にRoHCフィードバックパケットが蓄積するような状況が生じる場合、本発明を適用して最新のRoHCフィードバックパケットを1つ保管するという効率化が可能である。
上記実施の形態では、通信システム、送信制御装置及び送信制御方法という名称を用いたが、これは説明の便宜上であり、装置は無線通信端末、LTE端末、移動通信システム、方法は通信制御方法等であってもよい。
さらに、上記通信システムを構成する各構成部、例えば機器の種類、無線伝搬環境などは前述した実施の形態に限られない。
また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部又は全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用等が可能である。
本発明の通信システム、送信制御装置及び送信制御方法は、携帯端末装置等のユーザ通信装置と基地局装置等のオペレータ通信装置との間においてパケットを通信するパケット通信システム等に有用である。
100,200 機器
110,215 上位レイヤ(ユーザデータ系)
120 PDCPレイヤ
121 RoHCヘッダ圧縮エンティティ
122 Cipher処理部
123 PDCP PDU生成部
124 PDCP PDU解析部
210 上位レイヤ(RRC)
220 PDCPレイヤ
221 RoHCヘッダ解凍エンティティ
222 Decipher処理部
223 PDCP PDU解析部
224 PDCP PDU生成部
225 RoHCフィードバックパケット保管部
230 下位レイヤ(RLC/MAC/PHY)
300 無線伝搬環境

Claims (15)

  1. ヘッダ圧縮を実施するヘッダ圧縮エンティティを有する第1機器と、
    前記第1機器に無線伝搬環境を通して接続され、ヘッダ解凍を実施するヘッダ解凍エンティティを有する第2機器と、を備える通信システムであって、
    前記ヘッダ解凍エンティティは、
    ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、フィードバックパケットを生成する生成手段と、
    生成したフィードバックパケットを保管する保管手段と、
    前記無線伝搬環境が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、前記保管手段により保管された複数の前記フィードバックパケットのうち、最新のN(Nは任意の自然数)個を前記ヘッダ圧縮エンティティに送信する送信手段と、を備え、
    前記ヘッダ圧縮エンティティは、
    前記ヘッダ解凍エンティティから送信された前記フィードバックパケットを用いて、圧縮状態の変更、前記ヘッダ解凍エンティティで必要とするヘッダ解凍コンテキスト情報の送信、又は圧縮状態の遷移を制御する制御モード切替を行う通信システム。
  2. ヘッダ圧縮を実施するヘッダ圧縮エンティティを有する第1機器と、
    前記第1機器に無線伝搬環境を通して接続され、前記ヘッダ解凍を実施するヘッダ解凍エンティティを有する第2機器と、を備え、
    前記ヘッダ解凍エンティティは、
    ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、フィードバックパケットを生成する生成手段と、
    生成したフィードバックパケットを保管する保管手段と、
    前記無線伝搬環境が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、前記保管手段により保管された複数の前記フィードバックパケットのうち、最新のN(Nは任意の自然数)個を前記ヘッダ圧縮エンティティに送信する送信手段と、
    を備える送信制御装置。
  3. 前記送信手段は、前記保管手段が保管する、送信したフィードバックパケット以外のフィードバックパケットを削除する、請求項2記載の送信制御装置。
  4. 前記送信手段は、前記送信停止中に、前記フィードバックパケットとして、ヘッダ解凍成功通知(ACK)が複数生成された場合、先に生成された前記ヘッダ解凍成功通知(ACK)を破棄し、最後の前記ヘッダ解凍成功通知(ACK)を送信する、請求項2記載の送信制御装置。
  5. 前記送信手段は、前記送信停止中に、前記フィードバックパケットとして、ヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)が複数生成された場合、先に生成された前記ヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)を破棄し、最後の前記ヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)を送信する、請求項2記載の送信制御装置。
  6. 前記送信手段は、前記送信停止中に、前記フィードバックパケットとして、先にヘッダ解凍成功通知(ACK)が生成され、後からヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)が生成された場合、先に生成された前記ヘッダ解凍成功通知(ACK)を破棄し、後の前記ヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)を送信する、請求項2記載の送信制御装置。
  7. 前記送信手段は、前記送信停止中に、前記フィードバックパケットとして、先に前記ヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)が生成され、後からヘッダ解凍成功通知(ACK)が生成された場合、先に生成された前記ヘッダ解凍コンテキスト更新要求(NACK or STATIC NACK)を破棄し、後の前記ヘッダ解凍成功通知(ACK)を送信する、請求項2記載の送信制御装置。
  8. 前記送信手段は、前記フィードバックパケットを破棄する場合、コンテキスト識別子を確認し、同じコンテキスト識別子のものだけを破棄する、請求項2記載の送信制御装置。
  9. 前記送信手段は、前記コンテキスト識別子毎に最新のN個を送信する、請求項8記載の送信制御装置。
  10. 前記送信手段は、同一無線ベアラに複数のコンテキスト識別子が生成されない状況にある場合、前記コンテキスト識別子を確認せずに前記無線ベアラ1つにつき最新のN個を送信する、請求項8記載の送信制御装置。
  11. 前記ヘッダ圧縮エンティティは、前記ヘッダ解凍エンティティから送信された前記フィードバックパケットを用いて、圧縮状態の変更、前記ヘッダ解凍エンティティで必要とするヘッダ解凍コンテキスト情報の送信、又は圧縮状態の遷移を制御する制御モード切替を行う、請求項2記載の送信制御装置。
  12. 前記送信手段は、前記ヘッダ圧縮エンティティから送信されたヘッダ解凍コンテキスト情報を基に、前記保管された複数の前記フィードバックパケットのうち、最新の1つのみを前記ヘッダ圧縮エンティティに送信する、請求項2記載の送信制御装置。
  13. 前記ヘッダ解凍エンティティは、自己のレイヤより下位のレイヤに対して前記フィードバックパケットを送信要求し、その後、送信完了通知を受けないうちに伝搬環境劣化が発生した場合、最新のフィードバックパケットが生成されたタイミングで前記下位のレイヤに対して、当該フィードバックパケット破棄要求を実施する、請求項2記載の送信制御装置。
  14. 前記第1機器は、前記ヘッダ解凍エンティティを有し、
    前記第2機器は、前記ヘッダ圧縮エンティティを有する、請求項2記載の送信制御装置。
  15. ヘッダ圧縮を実施するヘッダ圧縮エンティティを有する第1機器と、前記第1機器に無線伝搬環境を通して接続され、ヘッダ解凍を実施するヘッダ解凍エンティティを有する第2機器と、を備える通信システムの送信制御方法であって、
    前記ヘッダ解凍エンティティでは、ヘッダ解凍成功、失敗情報、及びオプションフィールドを含む、フィードバックパケットを生成するステップと、
    生成したフィードバックパケットを保管するステップと、
    前記無線伝搬環境が改善しデータ送信が再開した際、無線伝搬環境劣化で送信停止中に、保管された複数の前記フィードバックパケットのうち、最新のN(Nは任意の自然数)個を前記ヘッダ圧縮エンティティに送信するステップと、
    を有する送信制御方法。
JP2011027426A 2011-02-10 2011-02-10 通信システム、送信制御装置及び送信制御方法 Withdrawn JP2012169764A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011027426A JP2012169764A (ja) 2011-02-10 2011-02-10 通信システム、送信制御装置及び送信制御方法
PCT/JP2012/000911 WO2012108215A1 (ja) 2011-02-10 2012-02-10 通信システム、送信制御装置及び送信制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011027426A JP2012169764A (ja) 2011-02-10 2011-02-10 通信システム、送信制御装置及び送信制御方法

Publications (1)

Publication Number Publication Date
JP2012169764A true JP2012169764A (ja) 2012-09-06

Family

ID=46638435

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011027426A Withdrawn JP2012169764A (ja) 2011-02-10 2011-02-10 通信システム、送信制御装置及び送信制御方法

Country Status (2)

Country Link
JP (1) JP2012169764A (ja)
WO (1) WO2012108215A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017503449A (ja) * 2013-12-09 2017-01-26 ゼットティーイー コーポレーションZte Corporation 切り替え方法、ソース基地局、ターゲット基地局、システム、記憶媒体
WO2017141853A1 (ja) * 2016-02-15 2017-08-24 日本電気株式会社 無線基地局、端末装置、および通信システム
JP2022501945A (ja) * 2018-09-27 2022-01-06 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 通信方法及びデバイス
JP2022515628A (ja) * 2019-04-30 2022-02-21 オッポ広東移動通信有限公司 無線通信方法及び装置
JP2022519554A (ja) * 2019-01-30 2022-03-24 維沃移動通信有限公司 処理方法及び通信機器
WO2022111365A1 (zh) * 2020-11-26 2022-06-02 展讯通信(上海)有限公司 数据传输方法、装置、设备、存储介质及程序产品

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110062420B (zh) * 2019-04-26 2021-01-08 维沃移动通信有限公司 鲁棒头压缩协议rohc状态的控制方法、终端设备和网络设备
CN111800826B (zh) * 2019-08-01 2023-06-02 维沃移动通信有限公司 一种rohc反馈处理方法及用户设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4864100B2 (ja) * 2007-01-31 2012-01-25 富士通株式会社 無線通信制御方法並びに無線基地局及び無線端末
KR100917205B1 (ko) * 2007-05-02 2009-09-15 엘지전자 주식회사 무선 통신 시스템에서의 데이터 블록 구성 방법
KR100907978B1 (ko) * 2007-09-11 2009-07-15 엘지전자 주식회사 이동통신 시스템에서 pdcp 계층의 상태보고 전송 방법 및 수신장치

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017503449A (ja) * 2013-12-09 2017-01-26 ゼットティーイー コーポレーションZte Corporation 切り替え方法、ソース基地局、ターゲット基地局、システム、記憶媒体
WO2017141853A1 (ja) * 2016-02-15 2017-08-24 日本電気株式会社 無線基地局、端末装置、および通信システム
JPWO2017141853A1 (ja) * 2016-02-15 2018-11-29 日本電気株式会社 無線基地局、端末装置、および通信システム
JP2022501945A (ja) * 2018-09-27 2022-01-06 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 通信方法及びデバイス
JP7327831B2 (ja) 2018-09-27 2023-08-16 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 通信方法及びデバイス
US11956667B2 (en) 2018-09-27 2024-04-09 Huawei Technologies Co., Ltd. Communication method and device
JP2022519554A (ja) * 2019-01-30 2022-03-24 維沃移動通信有限公司 処理方法及び通信機器
JP2022515628A (ja) * 2019-04-30 2022-02-21 オッポ広東移動通信有限公司 無線通信方法及び装置
US11477306B2 (en) 2019-04-30 2022-10-18 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Wireless communication methods and devices
WO2022111365A1 (zh) * 2020-11-26 2022-06-02 展讯通信(上海)有限公司 数据传输方法、装置、设备、存储介质及程序产品

Also Published As

Publication number Publication date
WO2012108215A1 (ja) 2012-08-16

Similar Documents

Publication Publication Date Title
JP7138738B2 (ja) ベアラを再構成する方法及び装置
US8964699B2 (en) Method for synchronizing PDCP operations after RRC connection re-establishment in a wireless communication system and related apparatus thereof
WO2012108215A1 (ja) 通信システム、送信制御装置及び送信制御方法
KR101387537B1 (ko) 성공적으로 수신했으나 헤더 압축 복원에 실패한 패킷의 처리 방법
JP5244260B2 (ja) Pdcp層の再確立方法及び装置
WO2016072501A1 (ja) ユーザ装置、及び重複パケット処理方法
US20100195617A1 (en) method for handling correctly received but header compression failed packets
WO2012065473A1 (zh) 一种分组数据汇聚协议层处理数据的方法及系统
US20110164694A1 (en) Communication system, communication device and communication method
WO2013001838A1 (ja) 受信装置、送信装置及びフィードバック方法
JP2011061364A (ja) 送信装置および送信方法
CN112970235A (zh) 减少下一代移动通信系统中以太网帧开销的方法和装置
CN115022922A (zh) 用于lte系统中的呼叫处理方法和装置
WO2022131342A1 (ja) 端末装置、基地局装置、および、方法
JP2017041814A (ja) 送信機及び通信システム
WO2010016150A1 (ja) 無線装置、通信方法および通信プログラム
KR20080044148A (ko) 이동통신 시스템에서 암호화된 패킷을 송수신하는 장치 및방법
JP2014216847A (ja) 基地局及び方法

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20140513