JP5195762B2 - パケット通信装置及びパケット通信方法 - Google Patents

パケット通信装置及びパケット通信方法 Download PDF

Info

Publication number
JP5195762B2
JP5195762B2 JP2009544510A JP2009544510A JP5195762B2 JP 5195762 B2 JP5195762 B2 JP 5195762B2 JP 2009544510 A JP2009544510 A JP 2009544510A JP 2009544510 A JP2009544510 A JP 2009544510A JP 5195762 B2 JP5195762 B2 JP 5195762B2
Authority
JP
Japan
Prior art keywords
state
header
transition
packet
processing
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.)
Expired - Fee Related
Application number
JP2009544510A
Other languages
English (en)
Other versions
JPWO2009072175A1 (ja
Inventor
直聡 渡辺
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2009072175A1 publication Critical patent/JPWO2009072175A1/ja
Application granted granted Critical
Publication of JP5195762B2 publication Critical patent/JP5195762B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、パケット通信装置及びパケット通信方法に関する。本発明は、例えば、3GPP(3rd Generation Partnership Project)の通信システム等において、パケットヘッダを圧縮、復元する技術に用いると好適である。
3GPPの移動体通信システムでのパケット通信に適用可能な技術の1つとして、例えば、ロバストヘッダ圧縮(RoHC:Robust Header Compression)技術がある(下記非特許文献1参照)。RoHCでは、パケット受信側でのヘッダ伸張(復元)処理の結果に応じて、パケット送信側でのヘッダ圧縮効率を適応的に変更(制御)する。
このRoHCに関する既存の技術として、例えば、下記特許文献1には、パケット受信側において、受信パケットのヘッダに誤りがあることを検出した場合に、参照情報の更新要求をパケット送信側に対して送信し、パケット送信側において、所定の時間内に複数の更新要求が受信された場合に、パケット受信側で参照情報が参照されずに復元された後、前記参照情報の更新に使用されるヘッダを有するパケットをパケット受信側に対して送信する方法が記載されている。
また、下記特許文献2及び特許文献3には、例えば、復元されたヘッダを含むパケットのエラーを検出し、エラーが有るパケットの数とエラーが無いパケットの数との関係に基づいて、格納されている参照情報を更新する必要があると判定したときには、参照情報を更新するための更新情報を要求する方法が記載されている。
さらに、下記特許文献4には、例えば、単位時間Xあたりに受信したACKパケットまたはNACKパケットの個数を求め、パケットのヘッダ圧縮に関する動作モードが圧縮効率優先モードであるときに、求めたNACKパケットの個数が所定の値Yを超えた場合には、前記動作モードを信頼性優先モードに切り替え、前記動作モードが信頼性優先モードであるときに、単位時間Xあたりに受信したACKパケットの個数が所定の値Zを超えた場合には、前記動作モードを圧縮効率優先モードに切り替える方法が記載されている。
また、下記特許文献5には、例えば、周期的な間隔で圧縮器の動作を変更する方法や、解凍器からのフィードバックに応じて、圧縮器の動作を変更する方法が記載されている。
3GPP TS36.300 V8.1.0 (2007-06)、4.3.1, Figure 6-1, Figure6-2, 6.3.1、[online]、3rd Generation Partnership Project、[平成19年12月3日検索]、インターネット〈http://www.3gpp.org/ftp/Specs/html-info/36300.htm〉 特開2002−94554号公報 特開2004−229318号公報 特開2004−215307号公報 特開2002−135362号公報 特表2007−502073号公報
しかし、上述した従来の技術では、同じベアラ(論理的なコネクション)に属する複数のパケットフローに関して、RoHCの状態遷移はフロー間で独立して制御されるに過ぎない。
本発明の目的の一つは、ヘッダ伸張処理の失敗によるパケットデータの損失を低減することにある。
また、通信システムのスループットを向上させることも本発明の他の目的の一つである。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の一つとして位置付けることができる。
上記の目的を達成するために、本発明では、以下のパケット通信装置及びパケット通信方法を用いる。
(1)即ち、本発明のパケット通信装置は、論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信装置であって、前記コネクションにおける第1のパケットフローに関する第1のヘッダ処理状態の状態マシンと、前記コネクションにおける第2のパケットフローに関する第2のヘッダ処理状態の状態マシンとを管理する状態マシン管理手段と、前記の各状態マシンのいずれか一方における状態遷移が実施された場合において、所定の状態遷移条件が成立したときに他方における状態遷移を実施し、一方、該状態遷移条件が成立しないときに該他方における状態遷移を実施しない制御手段と、をそなえる。
(2)ここで、前記第1のパケットフローは送信パケットフローであり、前記第1のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、前記第2のパケットフローは受信パケットフローであり、前記第2のヘッダ処理状態はヘッダ伸長処理状態であってもよい。
(3)また、前記の各パケットフローはそれぞれ受信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ伸長処理状態であってもよい。
(4)さらに、前記の各パケットフローはそれぞれ送信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ圧縮処理状態であってもよい。
(5)そして、前記制御手段は、前記一方の状態マシンが2以上存在する場合に、特定の状態遷移の生じた前記一方の状態マシンの数が所定数を超えると、前記制御の可否を判定し、可能であれば、前記他方の状態マシンにおける状態遷移を実施するようにしてもよい。
(6)また、前記制御手段は、前記他方の状態マシンが2以上存在する場合に、前記他方の状態マシンのいずれかを選択的に前記判定の対象とすることとしてもよい。
(7)さらに、前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記一方の状態マシンにおけるヘッダ処理状態の状態遷移種別と、前記他方の状態マシンにおけるヘッダ処理状態の状態種別とを含むようにしてもよい。
(8)また、前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記ヘッダ処理のプロトコルで規定された遷移判定パラメータ値を含むようにしてもよい。
(9)さらに、前記ヘッダ処理は、RoHC(Robust Header Compression)処理であることとしてもよい。
(10)また、本発明のパケット通信方法は、論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信方法であって、前記コネクションにおける第1のパケットフローに関する第1のヘッダ処理状態の状態マシンと、前記コネクションにおける第2のパケットフローに関する第2のヘッダ処理状態の状態マシンとを管理し、前記の各状態マシンのいずれか一方における状態遷移が実施された場合において、所定の状態遷移条件が成立したときに他方における状態遷移を実施し、一方、該状態遷移条件が成立しないときに該他方における状態遷移を実施しない
(11)ここで、前記第1のパケットフローは送信パケットフローであり、前記第1のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、前記第2のパケットフローは受信パケットフローであり、前記第2のヘッダ処理状態はヘッダ伸長処理状態であってもよい。
上記本発明によれば、ヘッダ圧縮処理されたパケットデータを正常に復元できない期間を削減して、パケットデータの損失を抑制することができる。そして、通信システムのスループットを向上させることが可能となる。
本発明の概要を説明する図である。 一実施形態に係る通信システムの構成を示すブロック図である。 一実施形態に係るUE及びeNBの構成を示すブロック図である。 状態マシン対応データ・連動遷移条件データの一例を示す図である。 (A)は一実施形態に係る圧縮器の状態マシン図であり、(B)は一実施形態に係る伸張器の状態マシン図である。 図2に示す通信システムの動作例を説明するフロー図である。 (A)は本発明の第1変形例に係る圧縮器の状態マシン図であり、(B)は本発明の第1変形例に係る伸張器の状態マシン図である。 第1変形例に係る通信システムの動作例を説明するフロー図である。 第3変形例における状態マシン対応データ・連動遷移条件データの一例を示す図である。 (A)は第3変形例に係る圧縮器の状態マシン図であり、(B)は第3変形例に係る伸張器の状態マシン図である。 第3変形例に係る通信システムの動作例を説明するフロー図である。 第4変形例における状態遷移制御方法を説明するフロー図である。 3GPPの移動体通信システムの構成例を示すブロック図である。 ROHC O−modeにおける圧縮器の状態遷移を説明する図である。 ROHC R−modeにおける圧縮器の状態遷移を説明する図である。 伸張器の状態遷移を説明する図である。 既存の通信システムの動作例を説明する図である。
符号の説明
1 UE
2 eNB
1−A,2−A 圧縮器
1−B,2−B 伸張器
3 メモリ
4 バス
5 プロセッサ
6 パケット処理エンジン
7 ネットワークインタフェース
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、以下に示す実施形態で明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形(各実施形態を組み合わせる等)して実施することができる。
〔1〕適用システム例
以下に説明する実施形態では、通信システムの一例として、3GPP(3rd Generation Partnership Project)の移動体通信システムを想定する。
図13に、3GPPの移動体通信システムの構成例を示す。
この図13において、UE(User Equipment)1は、無線網管理ノード(evolved Node-B、略してeNB)2と無線通信を行なう機能を具備しており、eNB2を介して他のUE1や外部パケット網(インターネット、企業網など)4などと通信するものである。
eNB2は、LTE/SAE(Long Term Evolution/System Architecture Evolution)よりも前の世代の無線基地局(Node-B)の機能と無線基地局制御装置(RNC:Radio Network Controller)の機能とを兼ね備えている。
また、aGW(E-UTRAN Access Gateway)などの無線アクセス網管理ノード3は、複数のeNB2を管理、制御し、UE1と外部パケット網4との間のメッセージの送受信を行なう。
上記システムでのパケット通信に用いられるパケットヘッダは、特に音声データを転送する場合、パケットデータに対してオーバヘッドが大きいため、そのままヘッダを付与して通信した場合には効率が悪い場合がある。また、無線区間の通信は有線区間の通信に比べて品質が劣りやすい傾向にあり、かつ、帯域幅等の通信リソースに限りがあるため、有線区間以上に通信効率の向上が求められる。
このため、eNB2とUE1との間のパケット通信に関して、ヘッダ圧縮(RoHC:Robust Header Compression)が行なわれる場合がある(例えば、前記非特許文献1参照)。
ここで、前記非特許文献1によれば、パケット送信側の圧縮器におけるRoHCのヘッダ圧縮処理状態には、圧縮せずに全てのヘッダ情報を送信するIR(Initialization and Refresh)状態,ヘッダ情報のうち動的に変化する部分(シーケンス番号など)を送信するFO(First Order)状態,ヘッダ情報のうち動的に変化する部分をエンコードし最小フィールドのみを送信するSO(Second Order)状態がある。さらに、RoHCには3つの転送モードとして、U(Unidirectional)モード,O(Optimistic)モード,R(Reliable)モードが定義されており、通信中にそれぞれのモードへの遷移が可能である。
一方、対向するパケット受信側の伸張器におけるRoHCのヘッダ伸張処理状態には、デコードするためのヘッダ情報が全く無いNC(No Context)状態,静的なヘッダ情報(アドレスやポート番号など)を有する(つまり、動的なフィールドの受信、更新が必要である)SC(Static Context)状態,動的に変化するヘッダ値の差分情報をデコード可能(つまり、フィールド情報を正しく復号可能)なFC(Full Context)状態がある。
RoHCでは、前記Oモード、あるいは、Rモードのパケット送信側の圧縮器において、対向局(受信側)からのフィードバック情報に応じて、ヘッダ圧縮処理状態が制御されるとともに、パケット受信側の受信器において、対向局(送信側)からのパケットデータのヘッダ伸張処理結果(エラーチェック結果)に基づき、ヘッダ伸張処理状態が制御される(例えば、前記特許文献1〜5参照)。
ここで、図14〜図16に、上述のヘッダ圧縮処理状態及びヘッダ伸張処理状態に係る状態マシン(状態遷移図)を示す。図14は圧縮器におけるOモードの状態マシンを示し、図15は圧縮器におけるRモードの状態マシンを示す。また、図16は伸張器における状態マシンを示す。
図14に示すように、Oモードにおいては、圧縮器は、IR状態から動作を開始し、対向局宛に、パケットヘッダ伸張処理のための完全な参照情報(コンテクスト情報)を含むパケットヘッダを送出する。
そして、対向局側の伸張器がより上位のヘッダ圧縮処理状態(FO状態あるいはSO状態)に従って正常にパケットデータを伸張(復元)できると推測した場合(Optimistic)や、対向局側の伸張器からフィードバック情報として正常応答(ACK)を受信した場合、ヘッダ圧縮処理状態は、より上位のFO状態あるいはSO状態に遷移する。
ヘッダ圧縮処理状態がFO状態へ遷移すると、対向局側の伸張器がより上位のヘッダ圧縮処理状態(SO状態)に従って正常にパケットデータを伸張できると推測した場合(Optimistic)や、対向局側の伸張器からフィードバック情報として正常応答(ACK)を受信した場合に、ヘッダ圧縮処理状態は、より上位のSO状態へ遷移する。
一方、SO状態で対向局側の伸張器からフィードバック情報として静的否定応答(STATIC_NACK)を受信した場合、ヘッダ圧縮処理状態は下位のIR状態へ遷移する。
そして、ヘッダ圧縮処理状態がSO状態へ遷移した場合は、対向局側の伸張器からフィードバック情報として正常応答(ACK)を受信すると、ヘッダ圧縮処理状態は、現状のSO状態に留まる。
一方、対向局側の伸張器からフィードバック情報として否定応答(NACK)を受信した場合や、コンテクスト情報の更新要求(update)を受信した場合、ヘッダ圧縮処理状態は、より下位のFO状態へ遷移する。また、対向局側の伸張器からフィードバック情報として静的否定応答(STATIC_NACK)を受信した場合、ヘッダ圧縮処理状態は、より下位のIR状態へ遷移する。
また、図15に示すように、Rモードでは、上記のOモードとは異なり、推測による状態遷移(制御)は行なわれない。例えば、対向局側の伸張器からのACK応答により、ヘッダ圧縮処理状態が、より上位(IR状態からFO状態あるいはSO状態、またはFO状態からSO状態)へ遷移する。
一方、図16に示すように、対向局側の伸張器は、NC状態から動作を開始し、対向局側の圧縮器から受信したパケット(IRパケット)データに対して、上記完全なコンテクスト情報を基にヘッダ伸張処理を行なう。このヘッダ伸張処理が成功すると、伸張器のヘッダ伸張処理状態は、FC状態へ遷移する。
FC状態において、対向局側の圧縮器から受信したパケットデータについてのヘッダ伸張処理が成功した場合、ヘッダ伸張処理状態は、現状のSO状態に留まる。しかし、ヘッダ伸張処理が失敗した場合は、ヘッダ伸張処理状態は、より下位のSC状態へ遷移する。図16に示す例では、FC状態において、所定のエラーレートを超える場合、例えば、対向局から受信したn1個のパケットデータのうちk1個のパケットデータがヘッダ伸張処理に失敗した場合に、ヘッダ伸張処理状態は、より下位のSC状態へ遷移する。
また、SC状態においては、対向局側の圧縮器から受信したパケットデータについてのヘッダ伸張処理が成功した場合、ヘッダ伸張処理状態は、FC状態へ遷移する。一方、ヘッダ伸張処理が失敗した場合は、ヘッダ伸張処理状態は、より下位のNC状態へ遷移する。
図16に示す例では、SC状態において、所定のエラーレートを超える場合、例えば、対向局から受信したn2個のパケットデータのうちk2個のパケットデータがヘッダ伸張処理に失敗した場合、ヘッダ伸張処理状態は、より下位のNC状態へ遷移する。また、SC状態において、動的なコンテクスト情報が必要である場合(No#Dynamic)は、SC状態に留まる。
さらに、NC状態においては、対向局側の圧縮器から受信したパケットデータについてのヘッダ伸張処理が成功した場合、ヘッダ伸張処理状態は、FC状態へ遷移する。一方、NC状態において、静的なコンテクスト情報が必要である場合(No#Static)、NC状態に留まる。
上述の状態遷移(制御)を行なうシステムの動作について図17を用いて説明する。
例えば、圧縮器1−A及び伸張器1−BをそなえたUE1と、伸張器2−B及び圧縮器2−AをそなえたeNB2とが、RoHCによるパケット通信を行なう場合、UE1からeNB2への上り通信方向(以下、ULという)では、圧縮器1−Aにおいて現状のヘッダ圧縮処理状態に応じたヘッダ圧縮が施されたパケットデータが、伸張器2−Bへ送信される。
圧縮器1−Aからのヘッダ圧縮処理済みパケットデータを受信した伸張器2−Bは、以前に受信したヘッダ情報(コンテクスト情報)を用いて当該パケットデータを伸張(デコード)する。このとき、伸張器では、パケットデータに関するエラーチェックが行なわれ、そのエラーチェック結果が、圧縮器1−Aへとフィードバック情報として返信される。
つまり、前記デコード処理が成功した場合は、フィードバック情報としてACKが圧縮器1−Aに返されるが、失敗した場合は、コンテクスト情報の欠落などにより伸張されなかったパケットデータに関する情報が圧縮器1−Aにフィードバック情報(例えば、NACKなど、SO状態からFO状態への状態遷移を誘起する情報)として送信される。
伸張器2−Bでは、前記エラーチェック結果に応じて、上述のようにNC,SC,FCのいずれかへの状態遷移が行なわれる一方、圧縮器1−Aでは、前記フィードバック情報に応じて、上述のようにIR,FO,SOのいずれかへの状態遷移が行なわれる。
一方、eNB2からUE1への下り通信方向(以下、DLという)でも、ULと同様の状態遷移制御が行なわれる。
このようにして、伸長器2−B(1−B)は、デコードを行なうためのコンテクスト情報が古くなった場合や、コンテクスト情報を適切に更新できなくなった場合などに、圧縮器1−A(2−A)側へフィードバック情報を通知して、ヘッダ圧縮処理状態をIR状態やFO状態などのより上位の状態へ遷移させることで前記コンテクスト情報を更新する。
〔2〕概要
図1に示す例を用いて本例の概要を説明する。
この図1に示すように、例えば、UE1(eNB2)側の圧縮器から対向局{eNB2(UE1)}側の伸張器宛にヘッダ圧縮処理済みのパケットデータが送信される場合、ヘッダ圧縮処理状態がSO状態であり、かつ、ヘッダ伸張処理状態がFC状態であれば、パケットデータは正常にデコードされる((1)伸張OK)。
ところが、UE1とeNB2との間の通信環境の変化などにより、対向局側の伸張器2−B(1−B)において、複数回のパケットエラーが検出されると((2)複数回のパケットエラー)、上述のように、ヘッダ伸張処理状態はFC状態から下位のSC状態へ遷移する。なお、以下、上述した既存の状態遷移を本例での状態遷移と区別する意味で通常遷移ということがある。
このとき、圧縮器1−A(2−A)は、フィードバック情報を受信するまでは対向局側の伸張器2−B(1−B)のヘッダ伸張処理状態が遷移したことを知らないので、それまでどおり、SO状態でのヘッダ圧縮処理を施されたパケットデータ(エンコードした動的ヘッダ情報を含むパケットデータ)を上記対向局側の伸張器宛に送信する。
しかしながら、対向局側の伸張器2−B(1−B)は静的なヘッダ情報しかもたないSC状態にあり、前記パケットデータを正常にデコードすることができないので、当該パケットデータは破棄される((3)伸張NG)。
対向局側の伸張器2−B(1−B)は、自身のヘッダ伸張処理状態の通常遷移に応じて、上記圧縮器1−A(2−A)宛に、SO状態からFO状態への遷移を誘起するフィードバック情報を送出する((4)フィードバック情報)。
その結果、上記圧縮器1−A(2−A)のヘッダ圧縮処理状態はSO状態からFO状態へ通常遷移し、コンテクスト情報が更新されて、対向局側の伸張器2−B(1−B)は正常なデコード処理を行なうことが可能となる((5)伸張OK/参照情報の更新)。
ところで、UE1とeNB2との間でVoIP(Voice over IP)通信を行なうことがある。VoIP通信では、ペイロードデータ(パケットデータ)に対し、ヘッダ(パケットヘッダ)のオーバヘッドが大きいため、RoHCを適用するのが好ましい。また、VoIP通信は、通信遅延に敏感であるため、優先度の高い(QoSの高い)通信路サービス(ベアラ)で取り扱うことが好ましい。
ここで、UE1とeNB2との間で優先度の高いベアラによるサービスを提供することとしても、上述のような、複数回のパケットエラーによるヘッダ伸張処理状態の遷移(例えば、FC状態からSC状態への遷移)が発生する場合がある。これは、UE1が無線通信の好ましくない位置(トンネルの中、屋内、ビルの陰など)に存在しているような場合である。
このような場合、上述のように対向局側の伸張器2−B(1−B)のヘッダ伸張処理状態が複数回のパケットエラーによる遷移が生じたとしても、そのことを上記圧縮器1−A(2−A)に通知するためのフィードバック情報が到達しないことがある。
その結果、対向局側の伸張器2−B(1−B)のヘッダ伸張処理状態が遷移しても、圧縮器のヘッダ圧縮処理状態は遷移されず、状態遷移後の対向局側の伸張器2−B(1−B)では正常なデコード処理を行なうことができないようなヘッダ圧縮処理済みのパケットデータが送信されることになる。この場合、そのようなパケットデータは、対向局側の伸張器2−B(1−B)で破棄されることになる。
また、UE1とeNB2との間の通信環境の変化によりフィードバック情報の到達が遅延することもある。そのような場合、フィードバック情報の遅延期間に比例して状態遷移後の対向局側の伸張器2−B(1−B)では正常なデコード処理を行なうことができないようなヘッダ圧縮処理済みのパケットデータが送信されることになるので、やはり多くのパケットデータが破棄される。
そこで、以下に説明する限定的でない例では、圧縮器1−A(2−A)及び伸張器2−B(1−B)をそなえたパケット通信装置において、第1のヘッダ処理状態の状態マシンと、第2のヘッダ処理状態の状態マシンとのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する(以下、かかる状態遷移を前記通常遷移と区別する意味で連動遷移ということがある)。
例えば、自局の伸張器1−B(2−B)のヘッダ伸張処理状態が、現状よりも下位(例えば、FC状態からSC状態)へ通常遷移したことを検出すると、これに連動して、自局の圧縮器1−A(2−A)のヘッダ圧縮処理状態を現状よりも下位(例えば、SO状態からFO状態)へ連動遷移させる。
これにより、対向局側の伸張器2−B(1−B)からのフィードバック情報によらず、自局の圧縮器1−A(2−A)のヘッダ圧縮処理状態を遷移させることができる。つまり、上述のように、フィードバック情報の未達や遅延が発生した場合においても、自局の伸張器1−B(2−B)のヘッダ伸張処理状態の遷移に応じて、自局の圧縮器1−A(2−A)のヘッダ圧縮処理状態を連動遷移させることが可能となる。その結果、自局の圧縮器1−A(2−A)のヘッダ圧縮処理状態を、対向局側でデコードが成功する可能性の高いヘッダ圧縮処理状態へ確実且つ迅速に遷移させることができる。
即ち、自局の圧縮器1−A(2−A)のヘッダ圧縮処理状態を、対向局側の伸張器2−B(1−B)のヘッダ伸張処理状態と迅速に整合(適合)させることができ、パケットデータの損失発生期間を削減して、通信システムのスループットを向上させることが可能となる。
〔3〕一実施形態
(3.1)システム構成
図2は一実施形態に係る通信システムの構成を示すブロック図である。この図2に示すシステムは、例えば、aGWや外部パケット網などに相当する上位ネットワーク(図示省略)と、UE1と、eNB2とをそなえる。
即ち、図2に示す通信システムは、論理的なコネクション(例えば、ベアラ)を介してeNB2(またはUE1)とパケットヘッダを圧縮又は伸張するヘッダ処理を行なってパケット通信するパケット送信装置としてのUE1(またはeNB2)と、前記パケット送信装置からのヘッダ圧縮処理済みのパケットデータを、受信済みの参照情報(コンテクスト情報)を基に伸張(復元)するパケット受信装置としてのeNB2(またはUE1)とをそなえる。
また、UE1及びeNB2の要部に着目すると、UE1は、圧縮器1−Aと、伸張器1−Bとをそなえ、eNB2は、伸張器2−Bと、圧縮器2−Aとをそなえる。
ここで、圧縮器1−A(2−A)は、対向局宛に送信すべきパケットデータ(のパケットヘッダ)について、現状のヘッダ圧縮処理状態(IR,FO,SOのいずれかの状態)に従って、RoHC処理(圧縮処理)を施し、ヘッダ圧縮処理済みのパケットデータを送信する機能を具備する。
対向局側の伸張器2−B(1−B)は、現状のヘッダ伸張処理状態(NC,SC,FCのいずれかの状態)に従って、上記圧縮器1−A(2−A)からのパケットデータのヘッダ情報(コンテクスト情報)を抽出するとともに、前記コンテクスト情報を用いてヘッダ圧縮処理済みのパケットデータの伸張(復元)を行なうものである。また、前記伸張処理の際にエラーチェックを行ない、そのエラーチェック結果をフィードバック情報(例えば、SO状態からFO状態への遷移を誘起する情報)として圧縮器1−A(2−A)宛に返信する機能を具備する。
なお、コンテクスト情報の欠落などにより正常に伸張できないパケットデータは伸張器2−B(1−B)で破棄され、正常に伸張されたパケットデータは、上位ネットワーク側のaGW(図示省略)へ送信される。
本実施形態における伸張器1−B(2−B)は、上述した機能に加えて、自身のヘッダ伸張処理状態の遷移に関する情報を同一局内の圧縮器1−A(2−A)へ通知する機能を具備する。そして、伸張器1−B(2−B)からのヘッダ伸張処理状態の遷移に関する情報を受けた圧縮器1−A(2−A)では、当該情報に応じてヘッダ圧縮処理状態が連動遷移される。
一方、本実施形態における圧縮器1−A(2−A)も上述の機能に加えて、ヘッダ圧縮処理状態の遷移に関する情報を同一局内の伸張器1−B(2−B)へ通知する機能を具備する。そして、圧縮器1−A(2−A)からのヘッダ圧縮処理状態の遷移に関する情報を受けた伸張器1−B(2−B)でも同様に、当該情報に応じてヘッダ伸張処理状態が連動遷移される。
これにより、UE1とeNB2との間の通信環境の変化などにより、対向局側の伸張器2−B(1−B)からのフィードバック情報が到達しなかったり遅延したりしても、ヘッダ圧縮処理状態を当該通信環境に適した状態に迅速に連動遷移させることができる。
その結果、ヘッダ圧縮処理済みのパケットデータを正常に復元できない期間を削減できるので、パケットデータの損失を抑制して、通信システムのスループットを向上させることが可能となる。
また、上述の状態遷移制御方法を従来の状態遷移制御方法と併用すれば、状態遷移のフィードバック経路が単純に二倍となり、エラー耐性を強化することが可能となる。
(3.2)UE1(eNB2)について
図3は一実施形態に係るUE1及びeNB2の構成を示すブロック図である。
この図3に示すように、UE1(eNB2)は、例えば、メモリ3と、バス4と、プロセッサ5と、パケット処理エンジン6と、ネットワークインタフェース7とをそなえ、パケット処理エンジン6は、圧縮器1−A(2−A)と、伸張器1−B(2−B)とをそなえる。
メモリ3は、プロセッサ5及びパケット処理エンジン6による各種制御用データを格納する機能を具備するものである。本メモリ3には、例えば、通信ベアラ管理データ,伸張器制御データ,圧縮器制御データ及び状態マシン対応データ・連動遷移条件データなどが格納される。
通信ベアラ管理データは、UE1とeNBとの間の通信路(ベアラ)を管理するための情報である。また、伸張器制御データは、伸張器1−B(2−B)のヘッダ伸張処理状態を管理(制御)するための情報で、例えば、伸張器1−B(2−B)の状態マシンや、ヘッダ伸張処理状態及びその遷移状況に関する情報を含む。
さらに、圧縮器制御データは、圧縮器1−A(2−A)のヘッダ圧縮処理状態を管理(制御)するための情報で、例えば、圧縮器1−A(2−A)の状態マシンや、ヘッダ圧縮処理状態及びその遷移状況に関する情報を含むものである。
また、状態マシン対応データ・連動遷移条件データは、同一ベアラに属する状態マシン(ヘッダ圧縮処理状態及びヘッダ伸張処理状態)の対応関係に関する情報で、例えば、後述するように、図4に示すようなデータ構成をとる。この状態マシン対応データ・連動遷移条件データは、プロセッサ5によりベアラが確立され、また、パケット処理エンジン6によりRoHCによる送受信パケットフローが開始され、さらに、前記圧縮器制御データ及び伸張器制御データ上に各状態マシンが生成された場合に、プロセッサ5及びパケット処理エンジン6が、通信ベアラ管理データを用いて、各状態マシンの対応付けを行なうことにより作成される。
バス4は、各種データを送受するための通信路であり、プロセッサ5は、UE1(eNB2)における各種制御を行なうもので、例えば、メモリ3に格納される上記通信ベアラ管理データを用いて、ベアラの確立などの通信制御を行なう機能を具備する。
また、パケット処理エンジン6は、圧縮器1−A(2−A)及び伸張器1−B(2−B)の各種制御を行なうもので、例えば、メモリ3に格納される伸張器制御データ,圧縮器制御データ及び状態マシン対応データ・連動遷移条件データを用いて、圧縮器1−A(2−A)のヘッダ圧縮処理状態の遷移制御、及び、伸張器1−B(2−B)のヘッダ伸張処理状態の遷移制御などを行なう機能を具備する。なお、圧縮器1−A(2−A)及び伸張器1−B(2−B)は、(3.1)にて上述したものと同様の機能を具備する。
即ち、メモリ3及びパケット処理エンジン6は、前記ベアラにおける送信パケットフローあるいは受信パケットフロー(第1のパケットフロー)に関するヘッダ圧縮処理状態あるいはヘッダ伸張処理状態(第1のヘッダ処理状態の状態マシン)と、前記ベアラにおける送信パケットフローあるいは受信パケットフロー(第2のパケットフロー)に関するヘッダ圧縮処理状態あるいはヘッダ伸張処理状態(第2のヘッダ処理状態の状態マシン)とを管理する状態マシン管理手段として機能する。
また、パケット処理エンジン6は、前記の各状態マシンのいずれか一方における状態遷移に応じて、他方における状態遷移を制御する制御手段として機能する。
ネットワークインタフェース7は、UE1(eNB2)と外部ネットワーク(eNB2の場合は、無線ネットワーク)とのインタフェース機能を具備するもので、例えば、圧縮器1−A(2−A)からのヘッダ圧縮処理済みのパケットデータについて所定の送信処理を施し、外部ネットワークへ送出する一方、外部ネットワークからのパケットデータについて所定の受信処理を施し、バス4を介して伸張器1−B(2−B)へ送出する機能を具備する。なお、UE1側のネットワークインタフェース7は、上位プロトコル層(アプリケーション)とのデータ送受を行なう機能も具備する。また、eNB2におけるネットワークインターフェース7は、UE1とのデータ送受の他、外部ネットワークとのデータ送受を行なう機能も具備する。
ここで、図4を用いて状態マシン対応データ・連動遷移条件データについて説明する。図4は状態マシン対応データ・連動遷移条件データの一例を示す図である。
図4に示すように、状態マシン対応データ・連動遷移条件データは、例えば、UE1とeNB2との間に設定される複数のベアラにおいて、複数のRoHCフロー(送受信パケットフロー)毎に、発生した状態遷移イベントを表す状態遷移内容と、その状態遷移内容に連動して実施される状態遷移対象を示す連動遷移対象とが対応付けられて設定される。
具体的には、例えば、あるベアラaにおいて、上記状態遷移内容として受信パケットフロー「#k」に関するヘッダ伸張処理状態のFC状態からSC状態への遷移が設定されており、また、当該状態遷移内容に対応付けられた上記連動遷移対象として、送信パケットフロー「#i」に関するヘッダ圧縮処理状態のSO状態からFO状態への遷移が設定されている場合、パケット処理エンジン6により、受信パケットフロー「#k」に関するヘッダ伸張処理状態のFC状態からSC状態への遷移が検出されると(状態遷移イベントの発生)、上記状態マシン対応データ・連動遷移条件データが参照される。
このとき、上記状態マシン対応データ・連動遷移条件データには、受信パケットフロー「#k」に関するヘッダ伸張処理状態のFC状態からSC状態への遷移に対して、送信パケットフロー「#i」に関するヘッダ圧縮処理状態のSO状態からFO状態への遷移が連動遷移対象として設定されているので、当該状態遷移イベントに連動して、送信パケットフロー「#i」に関するヘッダ圧縮処理状態のSO状態からFO状態への遷移制御が実施されるのである。なお、もちろん、同様にして、送信パケットフロー「#i」に関するヘッダ圧縮処理状態の遷移イベント発生に応じて、受信パケットフロー「#k」に関するヘッダ伸張処理状態の遷移を行なうこともできる。
図5(A)及び図5(B)を用いて上記の状態遷移制御方法の一例を説明する。図5(A)は本圧縮器1−A(2−A)の状態マシン図であり、図5(B)は本伸張器1−B(2−B)の状態マシン図である。
図5(A)に示すように、送信パケットフロー「#i」に関するヘッダ圧縮処理状態がSO状態(SO_i)である場合においては、対向局側の伸張器2−B(1−B)からフィードバック情報として否定応答(NACK)を受信した場合やコンテクスト情報の更新要求(update)を受信した場合に通常遷移されるのに加えて、受信パケットフロー「#k」に関するヘッダ伸張処理状態がFC状態(FC_k)からSC状態(SC_k)へ通常遷移した場合や受信パケットフロー「#k」に関するヘッダ伸張処理状態がSC状態(SC_k)からNC状態(NC_k)へ通常遷移した場合に、ヘッダ圧縮処理状態は、より下位のFO状態(FO_i)へ連動遷移される。
また、送信パケットフロー「#i」に関するヘッダ圧縮処理状態がFO状態(FO_i)である場合においては、対向局側の伸張器2−B(1−B)からフィードバック情報として静的否定応答(STATIC_NACK)を受信した場合に通常遷移されるのに加えて、受信パケットフロー「#k」に関するヘッダ伸張処理状態がFC状態(FC_k)からSC状態(SC_k)へ通常遷移した場合や受信パケットフロー「#k」に関するヘッダ伸張処理状態がSC状態(SC_k)からNC状態(NC_k)へ通常遷移した場合に、ヘッダ圧縮処理状態は、より下位のIR状態(IR_i)へ連動遷移される。
一方、図5(B)に示すように、受信パケットフロー「#k」に関するヘッダ伸張処理状態がFC状態(FC_k)である場合においては、例えば、対向局から受信したn1個のパケットデータのうちk1個のパケットデータがヘッダ伸張処理に失敗した(所定のエラーレートを超えた)場合に通常遷移されるのに加えて、送信パケットフロー「#i」に関するヘッダ圧縮処理状態が、フィードバック情報(NACKまたはupdate)に起因してSO状態(SO_i)からFO状態(FO_i)へ通常遷移した場合や送信パケットフロー「#i」に関するヘッダ伸張処理状態がSO状態(SO_i)からIR状態(IR_i)へ遷移した場合、あるいは、フィードバック情報(STATIC_NACK)に起因してFO状態(FO_i)からIR状態(IR_i)へ通常遷移した場合に、ヘッダ伸張処理状態は、より下位のSC状態(SC_k)へ連動遷移される。
また、受信パケットフロー「#k」に関するヘッダ伸張処理状態がSC状態(SC_k)である場合においては、例えば、対向局から受信したn2個のパケットデータのうちk2個のパケットデータがヘッダ伸張処理に失敗した(所定のエラーレートを超えた)場合に通常遷移されるのに加えて、送信パケットフロー「#i」に関するヘッダ圧縮処理状態が、フィードバック情報(NACKまたはupdate)に起因してSO状態(SO_i)からFO状態(FO_i)へ通常遷移した場合や送信パケットフロー「#i」に関するヘッダ伸張処理状態がSO状態(SO_i)からIR状態(IR_i)へ遷移した場合、あるいは、フィードバック情報(STATIC_NACK)に起因してFO状態(FO_i)からIR状態(IR_i)へ通常遷移した場合に、ヘッダ伸張処理状態は、より下位のNC状態(NC_k)へ連動遷移される。
このように、本実施形態では、自局(UE1あるいはeNB2)のヘッダ圧縮処理状態(あるいはヘッダ伸張処理状態)の下位状態への遷移が発生すると、それに連動して、ヘッダ伸張処理状態(あるいはヘッダ圧縮処理状態)の下位状態への遷移を行なうのである。
なお、上記状態マシン対応データ・連動遷移条件データの設定は、あくまでもその一例に過ぎず、適宜変更することもできる。
例えば、ヘッダ圧縮処理状態がSO状態(SO_i)からIR状態(IR_i)へ連動遷移する条件として、受信パケットフロー「#k」に関するヘッダ伸張処理状態がFC状態(FC_k)からSC状態(SC_k)へ通常遷移した場合や受信パケットフロー「#k」に関するヘッダ伸張処理状態がSC状態(SC_k)からNC状態(NC_k)へ通常遷移した場合を追加しても、本実施形態を同様に実施することができる。
(3.3)本例の通信システムの動作について
次に、本例の通信システムの動作例について図6を用いて説明する。
この図6に示すように、まず、パケット処理エンジン6が、圧縮器1−A(2−A)あるいは伸張器1−B(2−B)における或る状態Aの下位状態遷移イベントの発生を検知する(ステップS1参照)。ここで、或る状態Aの下位状態遷移イベントとは、例えば、図5(B)に示すような、ヘッダ伸張処理状態のFC状態からSC状態への通常遷移などを指す。
すると、パケット処理エンジン6によりメモリ3に格納される各種データが参照され、ステップS1の状態遷移イベントを遷移条件にもつ状態マシンがあるかどうかが判定される(ステップS2)。つまり、状態マシン対応データ・連動遷移条件データに、状態Aの下位状態遷移イベントの発生を示す状態遷移内容が設定されているかどうかを判定し、設定されていると判定した場合は(ステップS2のYESルート参照)、連動遷移対象に設定されている遷移対象を抽出する一方、設定されていないと判定した場合は(ステップS2のNOルート参照)、状態Aの下位状態遷移イベントを実行する(ステップS4参照)。
例えば、状態Aの下位状態遷移イベントが図5(B)に示すような、ヘッダ伸張処理状態のFC状態からSC状態への通常遷移であるとすれば、図5(A)に示すような、ヘッダ圧縮処理状態のSO状態からFO状態への連動遷移や、FO状態からIR状態への連動遷移がパケット処理エンジン6により連動遷移対象として抽出される。
パケット処理エンジン6は、上記連動遷移対象に該当する状態マシンにおいて、現状態が最下位状態(IR状態あるいはNC状態)でないかどうかを判定し、最下位状態でないと判定した場合に、当該連動遷移対象に設定されている遷移対象について下位状態への遷移を実施する(ステップS3参照)。最下位状態である場合は、遷移の必要がないので連動遷移は実施しない。
例えば、ヘッダ圧縮処理状態の現状態がSO状態であるとすれば、SO状態からFO状態への連動遷移が実施される。
次いで、パケット処理エンジン6は、状態Aの下位状態遷移イベントを実行する(ステップS4参照)。ここで、例えば、上記状態Aの下位状態遷移イベントが、伸張器1−B(1−A)のヘッダ伸張処理状態の下位状態遷移である場合は、当該下位状態遷移イベントの実行とともに、対向局側の圧縮器2−A(1−A)宛に上述のフィードバック情報が送信され、圧縮器2−A(1−A)においても下位状態への遷移イベントが誘発される。
本通信システムが上述のように動作することにより、UE1及びeNB2は、圧縮器1−A(2−A)のヘッダ圧縮処理状態が下位の状態へ遷移(例えば、SO状態からFO状態へ遷移)するためのフィードバック情報が対向局側の伸張器2−B(1−B)から到達しない場合においても、自局の伸張器1−B(2−B)のヘッダ伸張処理状態の状態遷移に連動して、前記ヘッダ圧縮処理状態を対向局側でデコード処理が成功する可能性の高いヘッダ圧縮処理状態へ遷移させることができる。
同様に、UE1及びeNB2は、圧縮器1−A(2−A)ヘッダ圧縮処理状態の状態遷移に連動して、自局の伸張器1−B(2−B)のヘッダ伸張処理状態を遷移させることができる。なお、このヘッダ伸張処理状態の連動遷移に応じて、伸張器1−B(2−B)が、対向局側の圧縮器2−A(1−A)宛に状態遷移を誘起するフィードバック情報を送信すれば、上記所定のエラーレートを超えるのを待たずに、対向局側の圧縮器2−A(1−A)のヘッダ圧縮処理状態を適切な状態に遷移させることができる。
つまり、本通信システムは、UE1及びeNB2にそなえられた圧縮器1−A,2−A及び伸張器1−B,2−Bの各状態マシンのいずれかにおいて下位状態への遷移が発生すると、これに連動して、自局及び対向局の他の状態マシンの遷移を迅速に実施することができるのである。その結果、エラー耐性、対応の迅速さを向上させることができる。
このように、本通信システムによれば、ヘッダ圧縮処理済みのパケットデータを正常に復元できない期間を削減して、パケットデータの損失を抑制することができ、通信システムのスループットを向上させることが可能となる。
〔4〕第1変形例
上述した例では、圧縮器1−A(2−A)及び伸張器1−B(2−B)のいずれか一方の状態マシンにおいて下位状態への遷移が発生すると、それに連動して、自局(UE1あるいはeNB2)の他方の状態マシンにおいて下位状態への遷移を実施したが、前記他方の状態マシンにおけるヘッダ処理状態の連動遷移の条件として、前記一方の状態マシンにおける前記遷移内容と、前記他方の状態マシンにおける前記遷移前の状態とに基づき、連動遷移を実施するようにしてもよい。つまり、上記状態遷移内容及び連動遷移対象がある特定の条件を満たす場合に、連動遷移を実施するようにしてもよい。
図7(A)及び図7(B)を用いて本変形例における状態遷移制御方法の一例を説明する。図7(A)は本変形例に係る圧縮器の状態マシン図であり、図7(B)は本変形例に係る伸張器の状態マシン図である。
図7(A)に示すように、本変形例の通信システムでは、例えば、圧縮器1−A(2−A)の送信パケットフロー「#i」に関するヘッダ圧縮処理状態がSO状態(SO_i)であって、対向局側の伸張器からフィードバック情報として静的否定応答(STATIC_NACK)を受信した場合に通常遷移するのに加えて、伸張器1−B(2−B)の受信パケットフロー「#k」に関するヘッダ伸張処理状態がFC状態(FC_k)からSC状態(SC_k)へ通常遷移した場合に、ヘッダ圧縮処理状態をより下位のFO状態(FO_i)へ連動遷移する。それ以外の場合は、上記連動遷移は実施されない。
即ち、上述した実施形態では、圧縮器1−A(2−A)の送信パケットフロー「#i」に関するヘッダ圧縮処理状態の遷移前の状態及び伸張器1−B(2−B)の受信パケットフロー「#k」に関するヘッダ伸張処理状態の状態遷移内容に関らず連動遷移を実施したが、本変形例では、圧縮器1−A(2−A)の送信パケットフロー「#i」に関するヘッダ圧縮処理状態の遷移前の状態及び伸張器1−B(2−B)の受信パケットフロー「#k」に関するヘッダ伸張処理状態の状態遷移内容が所定の条件を満たす場合にのみ、連動遷移を実施する。
同様にして、図7(B)に示すように、例えば、受信パケットフロー「#k」に関するヘッダ伸張処理状態がSC状態(SC_k)であって、対向局から受信したn2個のパケットデータのうちk2個のパケットデータがヘッダ伸張処理に失敗した(所定のエラーレートを超えた)場合に通常遷移するのに加えて、送信パケットフロー「#i」に関するヘッダ圧縮処理状態が、フィードバック情報(NACKまたはupdate)に起因してSO状態(SO_i)からFO状態(FO_i)へ通常遷移した場合に、ヘッダ伸張処理状態をより下位のSC状態(SC_k)へ連動遷移する。それ以外の場合は、上記連動遷移は実施されない。
本変形例における通信システムの動作例について図8を用いて説明する。
この図8に示すように、まず、パケット処理エンジン6が、圧縮器1−A(2−A)あるいは伸張器1−B(2−B)における或る状態Aの下位状態遷移イベントの発生を検知する(ステップS10参照)。ここで、或る状態Aの下位状態遷移イベントとは、例えば、図7(B)に示すような、ヘッダ伸張処理状態のFC状態からSC状態への通常遷移などを指す。
すると、パケット処理エンジン6によりメモリ3に格納される各種データが参照され、ステップS10の状態遷移イベントを遷移条件にもつ状態マシンがあるかどうかが判定される(ステップS20)。つまり、状態マシン対応データ・連動遷移条件データに、状態Aの下位状態遷移イベントの発生を示す状態遷移内容が設定されているかどうかを判定し、設定されている場合は(ステップS20のYESルート参照)、連動遷移対象に設定されている遷移対象を抽出する一方、設定されていない場合は(ステップS20のNOルート参照)、連動遷移は行なわずに、状態Aの下位状態遷移イベントを実行する(ステップS40参照)。
例えば、状態Aの下位状態遷移イベントが図7(B)に示すような、ヘッダ伸張処理状態のFC状態からSC状態への通常遷移であるとすれば、図7(A)に示すような、ヘッダ圧縮処理状態のSO状態からIR状態への連動遷移がパケット処理エンジン6により連動遷移対象として抽出される。
パケット処理エンジン6は、上記連動遷移対象に該当する状態マシンにおいて、現状態に関係のある連動遷移対象があるかどうかを判定し(ステップS25参照)、ないと判定した場合(ステップS25のNOルート参照)、状態Aの下位状態遷移イベントを実行する(ステップS40参照)一方、あると判定した場合(ステップS25のYESルート参照)、当該連動遷移対象に設定されている遷移対象について下位状態への遷移を実施する(ステップS30参照)。
例えば、ヘッダ圧縮処理状態の現状態がSO状態であるとすれば、図7(A)に示すように、SO状態からIR状態への連動遷移が実施される。
そして、パケット処理エンジン6は、状態Aの下位状態遷移イベントを実行する(ステップS40参照)。ここで、例えば、上記状態Aの下位状態遷移イベントが、伸張器1−B(1−A)のヘッダ伸張処理状態の下位状態遷移である場合は、当該下位状態遷移イベントの実行とともに、対向局側の圧縮器2−A(1−A)宛に上述のフィードバック情報が送信され、圧縮器2−A(1−A)においても下位状態への遷移イベントが誘発される。
本変形例における通信システムは上述のように動作することにより、ベアラが提供する品質や圧縮方式の特性に応じて、上記状態遷移内容及び連動遷移対象を適宜変更することで、より詳細に連動遷移を実施できる。
その結果、本変形例では、上述した実施形態と同様の効果が得られるほか、上記連動遷移の実施割合を調整して、圧縮器1−A(2−A)でのヘッダ圧縮効率の必要以上の低下を回避することが可能となる。
〔5〕第2変形例
上述した例では、圧縮器1−A(2−A)あるいは伸張器1−B(2−B)の状態マシンにおける状態遷移(通常遷移)に応じて、伸張器1−B(2−B)あるいは圧縮器1−A(2−A)の状態マシンにおいて連動遷移を実施したが、UE1とeNB2との間のベアラにおいて複数のパケットフロー(送信パケットフローまたは受信パケットフロー)が多重されている場合、圧縮器1−A(2−A)の一方の送信パケットフローに関するヘッダ圧縮処理状態の通常遷移に応じて、圧縮器1−A(2−A)の他方の送信パケットフローに関するヘッダ圧縮処理状態の連動遷移を行なうようにしてもよい。
また、同様に、伸張器1−B(2−B)の一方の受信パケットフローに関するヘッダ伸張処理状態の通常遷移に応じて、伸張器1−B(2−B)の他方の受信パケットフローに関するヘッダ伸張処理状態の連動遷移を行なうようにしてもよい。
具体的には、例えば、上記状態マシン対応データ・連動遷移条件データにおいて、パケットフロー「#i」及びパケットフロー「#k」をそれぞれ送信パケットフローとしたり、または、受信パケットフローとしたりすることで実現される。
第2変形例における通信システムはこのように動作することにより、ベアラに多重された複数のパケットフローに関する2つのヘッダ圧縮処理状態間及び2つのヘッダ伸張処理状態間においても、上述した実施形態と同様の効果を得ることができる。
〔6〕第3変形例
上述した例では、ある1つの状態マシンでの通常遷移に応じて、別の状態マシンにおいて連動遷移を実施したが、圧縮器1−A(2−A)あるいは伸張器1−B(2−B)の状態マシンが2以上存在する場合、これらの複数の状態マシンにおいて発生した状態遷移の数に応じて、連動遷移を実施するようにしてもよい。
例えば、UE1とeNB2との間のベアラにおいて複数のパケットフロー(送信パケットフローまたは受信パケットフロー)が多重されている場合は、圧縮器1−A(2−A)あるいは伸張器1−B(2−B)の状態マシンが2以上存在することとなる。
このとき、上記複数の状態マシンにおいて所定の時間あたりに発生する下位状態への遷移イベント数[Nt(Ntは自然数)]が所定の閾値{Nc(Ncは自然数)}を超えた場合に、UE1とeNB2との間の通信環境が悪化したと判断し、他の状態マシンにおいて連動遷移を実行する。
図9,図10(A)及び図10(B)を用いて第3変形例における状態遷移制御方法の一例を説明する。図9は第3変形例における状態マシン対応データ・連動遷移条件データの一例を示す図である。また、図10(A)は本変形例に係る圧縮器の状態マシン図であり、図10(B)は本変形例に係る伸張器の状態マシン図である。
この図9に示すように、第3変形例における状態マシン対応データ・連動遷移条件データには、例えば、図4に示す各種データに加えて、Nt値、閾値Nc、単位時間設定、エラーパケット数閾値m、遷移発生フロー記録データ及び遷移対象(Fa条件設定状態遷移リスト)が設けられる。
そして、本変形例では、図10(A)に示すように、例えば、送信パケットフロー「#i」に関するヘッダ圧縮処理状態がSO状態(SO_i)である場合において、対向局側の伸張器からフィードバック情報として否定応答(NACK)を受信した場合やコンテクスト情報の更新要求(update)を受信した場合に通常遷移されるのに加えて、フラグ{Fa(i,Nt)}=1を満たす場合に、ヘッダ圧縮処理状態は、より下位のFO状態(FO_i)へ連動遷移される。
このFa(i,Nt)は、ベアラaにおける送信パケットフロー「#i」に関するヘッダ圧縮処理状態の遷移条件(フラグ)である。Fa(i,Nt)は、例えば、状態マシン対応データ・連動遷移条件データに格納されているNt値(ここでNt値は、自然数)が閾値Nc(ここでNcは、自然数)を超えた場合に「1」となる一方、それ以外の場合は「0」となるようにパケット処理エンジン6により管理・更新される。
ここで、Nt値は、あるベアラaにおける複数の状態マシンで、単位時間設定データにより設定される所定の時間あたりに発生する下位状態への遷移イベント数を示すものであり、例えば、パケット処理エンジン6により管理・更新される。
つまり、本変形例では、例えば、同一ベアラ内の複数の状態マシンにおいて上記所定の時間内に発生する通常遷移イベントの発生数Ntが閾値Ncを超えた場合に、フラグを「1」とし、このフラグが遷移の条件に設定されている状態マシンの状態に対して連動遷移を実施するのである。
同様に、送信パケットフロー「#i」に関するヘッダ圧縮処理状態がFO状態(FO_i)である場合においては、対向局側の伸張器からフィードバック情報として静的否定応答(STATIC_NACK)を受信した場合に通常遷移されるのに加えて、Fa(i,Nt)=1を満たす場合に、ヘッダ圧縮処理状態は、より下位のIR状態(IR_i)へ連動遷移される。
一方、図10(B)に示すように、受信パケットフロー「#k」に関するヘッダ伸張処理状態がFC状態(FC_k)である場合においては、例えば、対向局から受信したn1個のパケットデータのうちk1個のパケットデータがヘッダ伸張処理に失敗した(所定のエラーレートを超えた)場合に通常遷移されるのに加えて、Fa(k,Nt)=1を満たす場合に、ヘッダ伸張処理状態は、より下位のSC状態(SC_k)へ連動遷移される。
また、同様に、受信パケットフロー「#k」に関するヘッダ伸張処理状態がSC状態(SC_k)である場合においては、例えば、対向局から受信したn2個のパケットデータのうちk2個のパケットデータがヘッダ伸張処理に失敗した(所定のエラーレートを超えた)場合に通常遷移されるのに加えて、Fa(k,Nt)=1を満たす場合に、ヘッダ伸張処理状態は、より下位のNC状態(NC_k)へ連動遷移される。
具体的には、例えば、閾値Ncが「3」であり、既に、送信パケットフロー「#1」,「#3」,「#0」の3フローにおいて、下位状態への遷移が発生しているとき、送信パケットフロー「#2」においてSO状態からFO状態への通常遷移が発生したとする。
このとき、Nt>Ncとなり、フラグに「1」が設定される。そして、同一ベアラ内の上記送信パケットフロー「#1」,「#3」,「#0」,「#2」以外のパケットフローであり、且つ、上記フラグが連動遷移条件に設定されているパケットフローを検索する。本例では、受信パケットフロー「#k」が選択され、例えば、FC状態からSC状態へ連動遷移される。なお、この具体例では、複数の送信パケットフローにおいて発生した状態遷移数に応じて、受信パケットフローを連動遷移させる例について説明したが、もちろん、複数の送信パケットフローにおいて発生した状態遷移数に応じて、別の送信パケットフローを連動遷移させてもよいし、また、複数の受信パケットフローにおいて発生した状態遷移数に応じて、送信パケットフローあるいは別の受信パケットフローを連動遷移させるようにしてもよい。
本変形例におけるシステムの動作例について図11を用いて説明する。
この図11に示すように、まず、例えば、パケット処理エンジン6が、圧縮器1−A(2−A)あるいは伸張器1−B(2−B)における或る状態Aの下位状態遷移イベントの発生を検知する(ステップS100参照)。ここでは、例えば、或る状態Aの下位状態遷移イベントが、図10(A)に示す別フローの状態マシンにおける下位状態への通常遷移であるとする。
パケット処理エンジン6は、後述する状態遷移イベント発生数Ntの観測時間として用いる、状態マシン対応データ・連動遷移条件データの単位時間設定を参照することで、所定の時間が経過したかどうかを判定する(ステップS102参照)。ここで、所定の観測時間が経過したと判定した場合は(ステップS102のYESルート参照)、パケット処理エンジン6は、後述する遷移発生フロー記録データの記録を消去するとともに、Nt値に「0」を代入する(ステップS104参照)。これにより、所定の時間毎に上記連動遷移条件(Nt値と閾値Ncとの関係)を初期化して、上記連動遷移の実施割合を調整することができる。その結果、圧縮器1−A(2−A)でのヘッダ圧縮の圧縮効率が必要以上に低下することを回避できる。
一方、所定の時間が経過していないと判定した場合は(ステップS102のNOルート参照)、パケット処理エンジン6により、ステップS110以降の処理を行なう。
パケット処理エンジン6は、メモリ3に格納される各種データを参照して、単位時間設定に基づく単位時間あたりの下位状態への通常遷移イベント発生数Ntが閾値Ncを超えるかどうかを判定する(ステップS110参照)。ここで、Nt>Ncでないと判定した場合は(ステップS110のNOルート参照)、フラグFa(i,Nt)に「0」を設定するとともに、状態Aの下位状態遷移イベントを実行する(ステップS150参照)。
Nt>Ncであると判定した場合は(ステップS110のYESルート参照)、パケット処理エンジン6により、フラグFa(i,Nt)に「1」が設定される。そして、Fa条件設定状態遷移リストに予め設定されている、フラグFa(i,Nt)を連動遷移条件にもち、且つ、当該単位時間において状態遷移が行われていない状態マシンが選択される。さらに、フラグFa(i,Nt)を連動遷移条件にもつ状態マシンから、例えば、ラウンドロビンなどの方式により、連動遷移対象が選択される(ステップS120参照)。
例えば、図10(A)に示すように、送信パケットフロー「#i」の状態マシンが選択される。
そして、パケット処理エンジン6は、ステップS120にて選択した状態マシンにおいて、現在の状態を下位状態へ連動遷移させる(ステップS130参照)。
例えば、図10(A)に示すように、連動遷移条件{Fa(i,Nt)}に基づき、SO状態からFO状態への連動遷移、あるいは、FO状態からIR状態への連動遷移が実施される。
パケット処理エンジン6は、上記ステップS130にて連動遷移させた後の状態及び状態Aがより下位状態へ遷移することを遷移発生フロー記録データに記録し、ステップS100のイベント発生をカウントするため、Nt値を1インクリメントする(ステップS140参照)。
そして、パケット処理エンジン6は、状態Aの下位状態遷移イベントを実行する(ステップS150参照)。
本変形例における通信システムは上述のように動作することにより、圧縮器1−A(2−A)あるいは伸張器1−B(2−B)の状態マシンが2以上存在する場合においても、上記実施形態及び各変形例と同様の効果を得ることができる。
〔7〕第4変形例
また、上述した例の連動遷移条件に加えて、RoHCプロトコルで規定された遷移判定パラメータ値(エラーパケット数)を併用するようにしてもよい。
例えば、上記第3変形例で説明した方法で選択された連動遷移対象について、伸張器1−B(2−B)で検出されるエラーパケット数k1(k2)が、エラーパケット数閾値m(mは自然数)以上である場合に当該連動遷移を実施する一方、そうでない場合は当該連動遷移を実施しないようにすることもできる。
本変形例におけるシステムの動作例について図12を用いて説明する。
この図12に示すように、ステップS200,S202,S204,S210,S220及びステップS240〜ステップS260については、前述したステップS100,S102,S104,S110,S120及びステップS130〜ステップS150と同様である。
本変形例では、ステップS220において選択された状態マシンについて、パケット処理エンジン6により、エラーパケット数k1(k2)が、状態マシン対応データ・連動遷移条件データに設定されているエラーパケット数閾値m以上であるかどうかが判定される(ステップS230参照)。
そして、エラーパケット数k1(k2)が閾値m以上であると判定された場合(ステップS230のYESルート参照)、ステップS240にて当該状態マシンにおいて連動遷移を実施する一方、エラーパケット数k1(k2)が閾値m以上でないと判定された場合は(ステップS230のNOルート参照)、ステップS220で選択された状態マシンにおいて連動遷移を実施せずに、再び、ステップS220を実施し、当該単位時間に未遷移で、「Nt>Nc」を遷移条件にもち、エラーパケット数がステップS230の条件を満たす状態マシンを検索する。
なお、ここでは、具体例として、上記第3変形例で説明した方法に対して、本変形例に係るエラーパケット数に応じた連動遷移制御を適用した場合を説明したが、もちろん、上述した実施形態及び各変形例についても同様に本変形例に係る連動遷移制御を適用して実施するようにしてもよい。
例えば、いずれの実施形態及び変形例においても、連動遷移対象として選択されたパケットフローについて、上記エラーパケット数に応じた連動制御可否の判断を行なうことができる。
本変形例における通信システムは上述のように動作することにより、上述した実施形態及び各変形例と同様の効果が得られるほか、連動遷移の実施割合についてさらに詳細に調整することができる。その結果、圧縮器1−A(2−A)でのヘッダ圧縮効率の必要以上の低下を回避することが可能となる。
〔8〕その他
上述した例では、主に、下位状態への遷移について説明したが、もちろん上位状態への遷移についても同様に連動遷移制御を実施することができる。
また、上述した例では、ヘッダ圧縮処理及びヘッダ伸張処理の一例としてRoHCを適用した場合を説明したが、本発明は、これに限らず一般的なヘッダ圧縮伸張技術についても適用することができる。
さらに、上述した例では、対向局側からのフィードバック情報に応じた遷移制御を本発明と併用する場合を説明したが、本発明は、前記フィードバック情報に応じた遷移制御を行なわずに実施することもできる。
また、上述した例では、例えば3GPPの移動通信システムの構成要素(エンティティ)であるUE1及びeNB2にて連動遷移制御を実施する場合について説明したが、パケットヘッダ圧縮復元を行なう、その他のエンティティにて連動遷移制御を実施することも可能である。

Claims (11)

  1. 論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信装置であって、
    前記コネクションにおける第1のパケットフローに関する第1のヘッダ処理状態の状態マシンと、前記コネクションにおける第2のパケットフローに関する第2のヘッダ処理状態の状態マシンとを管理する状態マシン管理手段と、
    前記の各状態マシンのいずれか一方における状態遷移が実施された場合において、所定の状態遷移条件が成立したときに他方における状態遷移を実施し、一方、該状態遷移条件が成立しないときに該他方における状態遷移を実施しない制御手段と、
    をそなえたことを特徴とする、パケット通信装置。
  2. 前記第1のパケットフローは送信パケットフローであり、前記第1のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、
    前記第2のパケットフローは受信パケットフローであり、前記第2のヘッダ処理状態はヘッダ伸長処理状態である、
    ことを特徴とする、請求項1記載のパケット通信装置。
  3. 前記の各パケットフローはそれぞれ受信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ伸長処理状態である、
    ことを特徴とする、請求項1記載のパケット通信装置。
  4. 前記の各パケットフローはそれぞれ送信パケットフローであり、前記の各ヘッダ処理状態はそれぞれヘッダ圧縮処理状態である、
    ことを特徴とする、請求項1記載のパケット通信装置。
  5. 前記制御手段は、
    前記一方の状態マシンが2以上存在する場合に、特定の状態遷移の生じた前記一方の状態マシンの数が所定数を超えると、前記制御の可否を判定し、可能であれば、前記他方の状態マシンにおける状態遷移を実施する、ことを特徴とする、請求項1記載のパケット通信装置。
  6. 前記制御手段は、
    前記他方の状態マシンが2以上存在する場合に、前記他方の状態マシンのいずれかを選択的に前記判定の対象とする、ことを特徴とする、請求項5記載のパケット通信装置。
  7. 前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記一方の状態マシンにおけるヘッダ処理状態の状態遷移種別と、前記他方の状態マシンにおけるヘッダ処理状態の状態種別とを含む、ことを特徴とする請求項1〜6のいずれか1項に記載のパケット通信装置。
  8. 前記他方の状態マシンにおけるヘッダ処理状態の状態遷移条件に、前記ヘッダ処理のプロトコルで規定された遷移判定パラメータ値を含む、ことを特徴とする、請求項1〜7のいずれか1項に記載のパケット通信装置。
  9. 前記ヘッダ処理は、RoHC(Robust Header Compression)処理である、ことを特徴とする、請求項1〜8のいずれか1項に記載のパケット通信装置。
  10. 論理的なコネクションを介して他のパケット通信装置とパケットヘッダを圧縮又は伸長するヘッダ処理を行なってパケット通信するパケット通信方法であって、
    前記コネクションにおける第1のパケットフローに関する第1のヘッダ処理状態の状態マシンと、前記コネクションにおける第2のパケットフローに関する第2のヘッダ処理状態の状態マシンとを管理し、
    前記の各状態マシンのいずれか一方における状態遷移が実施された場合において、所定の状態遷移条件が成立したときに他方における状態遷移を実施し、一方、該状態遷移条件が成立しないときに該他方における状態遷移を実施しない
    ことを特徴とする、パケット通信方法。
  11. 前記第1のパケットフローは送信パケットフローであり、前記第1のヘッダ処理状態はヘッダ圧縮処理状態であるとともに、
    前記第2のパケットフローは受信パケットフローであり、前記第2のヘッダ処理状態はヘッダ伸長処理状態である、
    ことを特徴とする、請求項10記載のパケット通信方法。
JP2009544510A 2007-12-03 2007-12-03 パケット通信装置及びパケット通信方法 Expired - Fee Related JP5195762B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2007/073327 WO2009072175A1 (ja) 2007-12-03 2007-12-03 パケット通信装置及びパケット通信方法

Publications (2)

Publication Number Publication Date
JPWO2009072175A1 JPWO2009072175A1 (ja) 2011-04-21
JP5195762B2 true JP5195762B2 (ja) 2013-05-15

Family

ID=40717361

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009544510A Expired - Fee Related JP5195762B2 (ja) 2007-12-03 2007-12-03 パケット通信装置及びパケット通信方法

Country Status (3)

Country Link
US (1) US8548004B2 (ja)
JP (1) JP5195762B2 (ja)
WO (1) WO2009072175A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102291774B (zh) * 2011-07-27 2017-09-26 中兴通讯股份有限公司 鲁棒性头压缩处理方法、压缩器及系统
KR102192165B1 (ko) * 2013-11-25 2020-12-16 삼성전자주식회사 전자 장치에서 헤더 압축된 패킷을 처리하기 위한 장치 및 방법
US20150195326A1 (en) * 2014-01-03 2015-07-09 Qualcomm Incorporated Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream
US9923695B2 (en) * 2014-09-24 2018-03-20 Samsung Electronics Co., Ltd. Call processing method and apparatus for use in LTE system
KR102273873B1 (ko) * 2014-09-24 2021-07-06 삼성전자 주식회사 Lte 시스템을 이용한 호 수행 방법 및 장치
WO2017141853A1 (ja) * 2016-02-15 2017-08-24 日本電気株式会社 無線基地局、端末装置、および通信システム
US9924000B2 (en) 2016-03-14 2018-03-20 Sprint Communications Company L.P. Communication packet header data compression

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004514341A (ja) * 2000-11-16 2004-05-13 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 通信システム及び共用されたコンテキスト圧縮方法
JP2004533792A (ja) * 2001-06-27 2004-11-04 ノキア コーポレイション データパケット接続におけるヘッダ圧縮識別子の伝送
JP2006287284A (ja) * 2005-03-31 2006-10-19 Nec Corp 無線通信システム及びそのヘッダ圧縮制御方法
JP2007194693A (ja) * 2006-01-17 2007-08-02 Kddi Corp ヘッダ圧縮機能を有するrtp通信用端末、プログラム及びネットワーク制御装置
JP2008547308A (ja) * 2005-06-21 2008-12-25 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 動的で耐性のあるヘッダ圧縮

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7014000B2 (en) * 2000-05-11 2006-03-21 Hill-Rom Services, Inc. Braking apparatus for a patient support
JP4520032B2 (ja) 2000-08-17 2010-08-04 パナソニック株式会社 ヘッダ圧縮装置およびヘッダ圧縮方法
JP4592935B2 (ja) * 2000-09-11 2010-12-08 パナソニック株式会社 ヘッダ復元装置およびヘッダ復元方法
JP3638939B2 (ja) 2000-09-11 2005-04-13 松下電器産業株式会社 ヘッダ復元装置およびヘッダ復元方法
JP3638940B2 (ja) 2000-09-11 2005-04-13 松下電器産業株式会社 ヘッダ復元装置およびヘッダ復元方法
JP3323484B2 (ja) 2000-09-12 2002-09-09 松下電器産業株式会社 パケット送信装置、パケット受信装置およびパケット伝送方法
US20040136380A1 (en) * 2000-09-12 2004-07-15 Daiji Ido Packet transmitter, packet receiver and packet transmission method
KR100896484B1 (ko) * 2002-04-08 2009-05-08 엘지전자 주식회사 이동통신시스템에서 데이터 전송 무선통신방법 및 무선통신장치
US7822067B2 (en) * 2003-08-08 2010-10-26 Qualcomm Incorporated Header compression enhancement for broadcast/multicast services
US7924731B2 (en) * 2004-11-15 2011-04-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handling out-of-sequence packets in header decompression
US7817628B2 (en) * 2004-11-15 2010-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for header compression with transmission of context information dependent upon media characteristic
EP1808995A1 (en) * 2006-01-13 2007-07-18 Thomson Licensing S.A. Method for the exchange of data packets in a network of distributed stations, device for compression of data packets and device for decompression of data packets
US8406212B2 (en) * 2006-02-22 2013-03-26 Apple Inc. Service flow with robust header compression (ROHC) in a WiMAX wireless network
TW200816719A (en) * 2006-08-23 2008-04-01 Matsushita Electric Ind Co Ltd Communication equipment
WO2009072247A1 (ja) * 2007-12-07 2009-06-11 Panasonic Corporation 通信装置
US8400530B2 (en) * 2007-12-28 2013-03-19 Panasonic Corporation Communication device, communication system, image presentation method, and program
EP2262181A1 (en) * 2008-03-31 2010-12-15 Panasonic Corporation Communication terminal device and communication control method
CN101689887A (zh) * 2008-04-25 2010-03-31 松下电器产业株式会社 通信终端装置及通信方法
JP5298123B2 (ja) * 2008-04-25 2013-09-25 パナソニック株式会社 通信装置及び通信方法
US8427957B2 (en) * 2008-10-15 2013-04-23 Panasonic Corporation Communication terminal and communication method
CN101897160B (zh) * 2008-10-15 2014-05-28 松下电器产业株式会社 通信装置及通信方法
US8627075B2 (en) * 2008-12-26 2014-01-07 Panasonic Corporation Communication device that receives external device information from an external device using near field communication
CN102356506B (zh) * 2009-04-28 2015-08-26 株式会社日立制作所 蓄电模块和具备它的蓄电装置
WO2010125761A1 (ja) * 2009-05-01 2010-11-04 パナソニック株式会社 通信帯域制御装置及び通信帯域制御方法
JP5329663B2 (ja) * 2009-06-26 2013-10-30 パナソニック株式会社 中継装置及びその方法
US20110156879A1 (en) * 2009-06-26 2011-06-30 Yosuke Matsushita Communication device
JP5683485B2 (ja) * 2009-11-30 2015-03-11 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカPanasonic Intellectual Property Corporation of America 通信装置
WO2011065007A1 (ja) * 2009-11-30 2011-06-03 パナソニック株式会社 携帯型通信装置、通信方法、集積回路、プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004514341A (ja) * 2000-11-16 2004-05-13 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 通信システム及び共用されたコンテキスト圧縮方法
JP2004533792A (ja) * 2001-06-27 2004-11-04 ノキア コーポレイション データパケット接続におけるヘッダ圧縮識別子の伝送
JP2006287284A (ja) * 2005-03-31 2006-10-19 Nec Corp 無線通信システム及びそのヘッダ圧縮制御方法
JP2008547308A (ja) * 2005-06-21 2008-12-25 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 動的で耐性のあるヘッダ圧縮
JP2007194693A (ja) * 2006-01-17 2007-08-02 Kddi Corp ヘッダ圧縮機能を有するrtp通信用端末、プログラム及びネットワーク制御装置

Also Published As

Publication number Publication date
US8548004B2 (en) 2013-10-01
US20100232455A1 (en) 2010-09-16
JPWO2009072175A1 (ja) 2011-04-21
WO2009072175A1 (ja) 2009-06-11

Similar Documents

Publication Publication Date Title
JP6925696B2 (ja) ベアラを再構成する方法及び装置
JP5195762B2 (ja) パケット通信装置及びパケット通信方法
JP3857688B2 (ja) データパケット接続におけるヘッダ圧縮識別子の伝送
WO2019101104A1 (en) Method and system for multicast and broadcast services
EP3031281B1 (en) Use of packet status report from secondary base station to master base station in wireless network
JP5281700B2 (ja) 無線装置とネットワーク間のデータユニットのシーケンスの送信のための無線通信方法
JP4619389B2 (ja) サービス側高速ダウンリンクの共用チャネルセル変更の後に、ノードbにバッファされたデータを効率的に回復するシステム
KR101190525B1 (ko) 통합형 기지국들, 및 이동 디바이스들을 위한 통신 시스템에서 데이터 유닛들을 전송하는 방법
US20160219481A1 (en) Method for coordinated multi-stream transmission of data, and enb
US20210314815A1 (en) Device And Method For Flexible Frame Compression
EP3014944A1 (en) Master base station-controlled response to detected failure of radio link between secondary base station and mobile station in dual connectivity wireless networks
KR20050101482A (ko) 무선링크 제어계층에서의 데이터 처리방법
JP2004517580A (ja) ヘッダ圧縮におけるコンテキスト情報の再配置
JPWO2007052764A1 (ja) セッション中継装置およびセッション中継方法
JP5341108B2 (ja) 目標ノードからの予測情報に基づくハンドオーバ
WO2016167212A1 (ja) 基地局及び通信制御方法
WO2012108215A1 (ja) 通信システム、送信制御装置及び送信制御方法
US20070133470A1 (en) Method for recovering ARQ data in wireless portable internet system
GB2525944A (en) Bearer reconfiguration
WO2019102965A1 (ja) 通信方法、無線通信装置、及びプロセッサ
WO2013001838A1 (ja) 受信装置、送信装置及びフィードバック方法
JP2017535117A (ja) Lteシステムを用いた呼の実行方法及び装置
TW201828679A (zh) 用於動態改變的擴展位元的穩健標頭壓縮(rohc)技術
WO2018192655A1 (en) Sctp offloading
WO2022030517A1 (ja) 通信制御方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120605

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120821

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121114

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20121122

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130108

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130121

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160215

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees