(57)【要約】【課題】ＶｏＬＴＥ呼の場合、ＲＦＣ３０９５規格を用いてパケットのＲＯＨＣ(Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ)及び圧縮解除動作を行う。【解決手段】音声通話動作において、ＲＯＨＣ動作を行うために基地局は端末が送信するＩＲパケットを受信し、受信されたＩＲパケットの情報に基づいて以後に受信される圧縮されたヘッダーを有する音声パケットに対してＲＯＨＣ圧縮解除動作を行う。もし、ＩＲパケットが損失される場合、基地局は音声パケットに対するコンテクスト(ｃｏｎｔｅｘｔ)を形成することができないからＲＯＨＣ動作が失敗するようになり、発生した呼が解除されるようになる。従って、音声呼を維持するために基地局は音声パケットが受信されたときにコンテクストが存在しなければ端末へＳＮＡＣＫを送信する。【選択図】図６
2020171015.tif 000002
【特許請求の範囲】
【請求項１】
端末がＬＴＥ（Ｌｏｎｇ−Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムを用いた音声通話を行う方法であって、
基地局から音声通話のためのパケットを受信する過程と、
前記音声通話のためのパケットがＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ）パケットであるかを確認する過程と、
前記音声通話のためのパケットが前記ＩＲパケットではなければ、ＲＯＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）圧縮解除のためのコンテクスト（ｃｏｎｔｅｘｔ）が保存されているかを確認する過程と、
前記コンテクストが保存されていなければ、前記基地局と前記音声通話の接続を維持した状態で、前記基地局に否定確認応答（Ｎｅｇａｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＮＡＣＫ）を送信する過程と、を含む
ことを特徴とする音声通話実行方法。
【請求項２】
前記基地局から前記ＩＲパケットを受信する過程と、
前記受信したＩＲパケットを用いて前記コンテクストを生成する過程と、をさらに含む
ことを特徴とする、請求項１に記載の音声通話実行方法。
【請求項３】
前記基地局から圧縮されたヘッダーを含む音声パケットが受信されると、前記生成されたコンテクストに基づいて前記圧縮されたヘッダーを圧縮解除する段階をさらに含む
ことを特徴とする、請求項２に記載の音声通話実行方法。
【請求項４】
前記コンテクストが保存されていれば、受信されたパケットの圧縮されたヘッダーを圧縮解除するためにＲＯＨＣ圧縮解除を行う過程をさらに含む
ことを特徴とする、請求項１に記載の音声通話実行方法。
【請求項５】
前記ＮＡＣＫは、スタティックＮＡＣＫ（Ｓｔａｔｉｃ  ＮＡＣＫ）である
ことを特徴とする、請求項１に記載の音声通話実行方法。
【請求項６】
ＬＴＥ（Ｌｏｎｇ−Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムを用いた音声通話を行う端末であって、
信号を送受信する送受信部と、
基地局から音声通話のためのパケットを受信し、前記音声通話のためのパケットがＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ）パケットであるかを確認し、前記音声通話のためのパケットが前記ＩＲパケットではなければ、ＲＯＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）圧縮解除のためのコンテクスト（ｃｏｎｔｅｘｔ）が保存されているかを確認し、前記コンテクストが保存されていなければ、前記基地局に否定確認応答（Ｎｅｇａｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＮＡＣＫ）を送信するように制御する制御部と、を含む
ことを特徴とする端末。
【請求項７】
前記制御部は、
前記基地局から前記ＩＲパケットを受信し、前記受信したＩＲパケットを用いて前記コンテクストを生成するようにさらに制御する
ことを特徴とする、請求項６に記載の端末。
【請求項８】
前記制御部は、
前記基地局から圧縮されたヘッダーを含む音声パケットが受信されると、前記生成されたコンテクストに基づいて前記圧縮されたヘッダーを圧縮解除するようにさらに制御する
ことを特徴とする、請求項７に記載の端末。
【請求項９】
前記制御部は、
前記コンテクストが保存されていれば、受信されたパケットの圧縮されたヘッダーを圧縮解除するためにＲＯＨＣ圧縮解除を行うようにさらに制御する
ことを特徴とする、請求項６に記載の端末。
【請求項１０】
前記ＮＡＣＫは、スタティックＮＡＣＫ（Ｓｔａｔｉｃ  ＮＡＣＫ）である
ことを特徴とする、請求項６に記載の端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｖｏｉｃｅ ｏｖｅｒ ＬＴＥ(以下、ＶｏＬＴＥとする)に関し、より具体的にＬＴＥシステムを用いて音声通話時に呼を維持する方法及び装置に関する。
【背景技術】
【０００２】
ＶｏＬＴＥは、３ＧＰＰ(３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)ＬＴＥ(Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)及びＬＴＥ−Ａ(ＬＴＥ Ａｄｖａｎｃｅｄ)ネットワークでパケットを用いた音声通話を可能にする技術を統合的に呼ぶ用語である。ＶｏＬＴＥを用いる場合、既存のサーキット通話方式に対して接続速度が早く、通話品質を向上させることができるという特徴があり、近年、ＶｏＬＴＥ技術は商用化段階に入っている。
【０００３】
３ＧＰＰ規格に応じてＶｏＬＴＥ呼の場合、ＰＤＣＰ(Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ)階層(ｌａｙｅｒ)がＲＦＣ(Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ)３０９５規格を用いたパケットのＲＯＨＣ(Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ)及び圧縮解除動作を行う。音声通話動作において、ＲＯＨＣ動作を行うために基地局は端末が送信するＩＲ(Ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ)パケットを受信し、受信されたＩＲパケットの情報に基づいて以後に受信される圧縮されたヘッダーを有する音声パケットに対してＲＯＨＣ圧縮解除動作を行う。
【０００４】
上述した情報は、ただ本明細書の理解を助けるための背景技術情報で存在する。上述したものなかのいずれも本明細書の開示と関連して先行技術として適用されることができるかに関してはどんな決定も下ろされないか、又はどんな主張も申し立てられない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２０１３／０５２１３６号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、ＲＯＨＣ規格はパケット損失に対する復旧メカニズムを定義しているが、ＩＲパケットに対する復旧メカニズムは明示的に定義されなかった。よって、ＩＲパケットが損失される場合、基地局は音声パケットに対するコンテクスト(Ｃｏｎｔｅｘｔ)を形成することができないからＲＯＨＣ動作が失敗するようになり、発生した呼が解除されるようになる。そこで音声呼を維持するための方法が必要である。
【課題を解決するための手段】
【０００７】
本発明は、少なくとも前述した問題点及び／又は欠点を解消し、後述する利点を提供するものである。そこで、本発明の一側面は、ＬＴＥ(Ｌｏｎｇ-Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ) システムにおいて音声呼を処理する方法及び装置を提供することである。
【０００８】
本発明の一側面によれば、基地局がＬＴＥ(Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)システムを用いた音声通話を行う方法であって、端末から音声通話のためのパケットを受信する過程と、前記音声通話のためのパケットがＩＲ(Ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ)パケットであるかを判断する過程と、前記音声通話のためのパケットが前記ＩＲパケットではなければ、前記基地局にＲＯＨＣ圧縮解除のためのコンテクスト(ｃｏｎｔｅｘｔ) が生成されているかを決定する過程と、前記コンテクストが生成されていないと、前記端末へ否定確認応答(Ｎｅｇａｔｉｖｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＮＡＣＫ)を送信する過程と、及び前記端末から前記ＩＲパケットを受信する過程と、をさらに含むことを特徴とする。
【０００９】
本発明の他の側面によれば、ＬＴＥ(Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)システムを用いた音声通話を行う基地局であって、信号を送受信する送受信部と、及び端末から音声通話のためのパケットを受信し、前記音声通話のためのパケットがＩＲ(Ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ) パケットであるかを判断し、前記音声通話のためのパケットが前記ＩＲパケットではなければ、前記基地局にＲＯＨＣ圧縮解除のためのコンテクスト(ｃｏｎｔｅｘｔ) が生成されているかを決定し、前記コンテクストが生成されていないと、前記端末へ否定確認応答(Ｎｅｇａｔｉｖｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＮＡＣＫ)を送信し、前記端末から前記ＩＲパケットを受信するように制御することを特徴とする制御部と、を含むことを特徴とする。
【００１０】
本開示の他の態様、利点、および顕著な特徴は添付の図面に係る以下の詳細な説明から当業者には明らかであり、これは本開示の様々な実施形態を開示する。
【発明の効果】
【００１１】
本発明の実施形態による音声通話を維持する方法によれば、端末が基地局へ送信したＩＲパケットが損失されても音声呼を維持することができる。
【図面の簡単な説明】
【００１２】
【図１】ＰＤＣＰ階層の構造を示す図面である。
【図２】ＰＤＣＰ階層が行う機能を示す図面である。
【図３】ＲＯＨＣの動作を行うモードを示す図面である。
【図４】ＲＬＣ ＵＭでのデータ流れを示す図面である。
【図５】ＩＲパケット損失により呼が解除される問題を示す図面である。
【図６】従来のＶｏＬＴＥパケット受信方法を示すフローチャートである。
【図７】改善したＶｏＬＴＥパケット受信方法を示すフローチャートである。
【図８】本発明の実施形態を行うことができる装置のブロック図である。
【発明を実施するための形態】
【００１３】
添付された図面を参照する次の説明は請求範囲及びこの等価物によって定義されるような本発明の多様な実施形態の包括的な理解を助けるために提供される。それはこのような理解を助けるために多様な特定詳細事項を含むが、これらはただ例示的なことで見なされなければならない。したがって、本技術分野の通常の技術者は本明細書に説明された多様な実施形態の多様な変更及び修正が本発明の範囲及び思想から逸脱せず成ることができるということを認識するだろう。さらに、公知された機能及び構成に対する説明は明確性及び簡潔性のために省略されることができる。
【００１４】
次の説明及び請求範囲で用いられた用語及び単語は書誌意味に限定されず、ただ発明者によって本発明の明確で一貫性ある理解ができるようにするために用いられる。したがって、本発明の多様な実施形態に対する次の説明は添付された請求範囲及びこの等価物によって定義されるように本発明を制限するためではなく、ただ例示のために提供されるということは本技術分野の技術者には明白であろう。
【００１５】
単数形態“ａ”、“ａｎ”及び“ｔｈｅ”は文脈がはっきり異なり指示しなければ複数の指示ターゲットを含むことに理解されなければならない。したがって、例えば、“構成要素表面(ｃｏｍｐｏｎｅｎｔ ｓｕｒｆａｃｅ)”に対する参照物はこのような表面中の１つ以上に対する参照物を含む。
【００１６】
また、本発明の実施形態を具体的に説明するにあたり、直交周波数分割多重方式(Ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ−ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ、ＯＦＤＭ)に基づく無線通信システム、特に３ＧＰＰＬＴＥ標準を主な対象とするが、本発明の主な要旨は類似の技術的背景及びチャンネル形態を有するそのほかの通信システムにも本発明の範囲を大きく逸脱せず範囲で僅かの変形で適用可能であり、これは本発明の技術分野で熟練された技術的知識を有する者の判断で可能であろう。
【００１７】
この時、処理フローチャートの各ブロックとフローチャートの図面の組合は、コンピュータープログラムインストラクションによって行われることができることを理解することができるだろう。これらコンピュータープログラムインストラクションは、汎用コンピューター、特殊用コンピューター又はその他プログラム可能なデータプロセッシング装備のプロセッサに搭載されることができるので、コンピューター又はその他プログラム可能なデータプロセッシング装備のプロセッサを介して行われるそのインストラクションが、フローチャートブロックで説明された機能を行う手段を生成するようになる。これらコンピュータープログラムインストラクションは、特定方式で機能を具現するためにコンピューター又はその他プログラム可能なデータプロセッシング装備を志向することができるコンピューター利用可能、又はコンピューター判読可能メモリーに保存されることも可能であるので、そのコンピューター利用可能又はコンピューター判読可能メモリーに保存されたインストラクションは、フローチャートブロックで説明された機能を行うインストラクション手段を内包する製造品目を生産することも可能である。コンピュータープログラムインストラクションは、コンピューター又はその他プログラム可能なデータプロセッシング装備上に搭載されることも可能であるので、コンピューター又はその他プログラム可能なデータプロセッシング装備上で一連の動作段階が行われ、コンピューターで実行されるプロセスを生成してコンピューター又はその他プログラム可能なデータプロセッシング装備を行うインストラクションはフローチャートブロックで説明された機能を行うための段階を提供することも可能である。
【００１８】
また、各ブロックは、特定された論理的機能を行うための１つ以上の実行可能なインストラクションを含むモジュール、セグメント又はコードの一部を示すことができる。また、幾つか代替実行例ではブロックで言及された機能が手順を外れて発生することも可能であることを注目しなければならない。例えば、接して示されている２つのブロックは、実は実質的に同時に行われることも可能で、又はそのブロックが時々該当する機能によって逆順に行われることも可能である。
【００１９】
この時、本実施形態に用いられる‘〜部’という用語は、ソフトウェア又はＦＰＧＡ、並びにＡＳＩＣのようなハードウェア構成要素を意味し、‘〜部’はどんな役目を行う。しかし、‘〜部’は、ソフトウェア又はハードウェアで限定される意味ではない。‘〜部’はアドレシングすることができる保存媒体にあるように構成されることもでき、１つ又はその以上のプロセッサを再生させるように構成されることもできる。したがって、一例として‘〜部’はソフトウェア構成要素、客体志向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーティン、プログラムコードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素と‘〜部’のうちで提供される機能はより小さい数の構成要素及び‘〜部’に結合されたり追加的な構成要素と‘〜部’でさらに分離することができる。だけでなく、構成要素及び‘〜部’はデバイス又は保安マルチメディアカード内の１つ又はその以上のＣＰＵを再生させるように具現されることもできる。
【００２０】
図１は、ＰＤＣＰ階層の構造を示す図面である。
【００２１】
図１によれば、ＰＤＣＰ階層は無線網プロトコルを構成する階層のうちの一つとして、ユーザ平面(ｕｓｅｒ  ｐｌａｎｅ)及び制御平面(ｃｏｎｔｒｏｌ  ｐｌａｎｅ)に共通的に含まれる。ＰＤＣＰはＲＬＣ(Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ)階層上に存在してベアラー別でそれぞれのＰＤＣＰエンティティー１００、１１０が存在する。
【００２２】
図２は、ＰＤＣＰ階層が行う機能を示す図面である。
【００２３】
図２によれば、ＰＤＣＰエンティティーは送信部のＰＤＣＰ階層２００から送信されて
ラジオインターフェース２２０を経て受信部のＰＤＣＰ階層２１０で受信される。この時、ＰＤＣＰ階層は端末やＥ−ＵＴＲＡＮ(ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ ＲａｄｉｏＡｃｃｅｓｓ Ｎｅｔｗｏｒｋ)に存在することができる。
【００２４】
送信部のＰＤＣＰ階層はパケットにシーケンスナンバー(ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ)を付し(２０１)、パケットのヘッダーを圧縮する(ユーザ平面の場合、２０２)。ＰＤＣＰ ＳＤＵ(Ｓｅｒｖｉｃｅｄａｔａｕｎｉｔ)に関連されるパケットの場合、無欠性(ｉｎｔｅｇｒｉｔｙ)保護(制御平面の場合、２０３)と暗号化(２０４)過程を経て、ＰＤＣＰ ＳＤＵに関連されないパケットは無欠性保護と暗号化過程を経ない。前記過程を通過したパケットはＰＤＣＰヘッダーが付加されて受信部のＰＤＣＰ階層へ送信される。
【００２５】
受信部のＰＤＣＰ階層は受信されたパケットのＰＤＣＰヘッダーを除去し(２１５)、ＰＤＣ Ｐ ＳＤＵに関連されるパケットの場合、暗号を解読し(２１４)、無欠性を検査(制御平面の場合、２１３)する。ＰＤＣＰ ＳＤＵに関連されないパケットの場合、無欠性検査と暗号解読過程を経ない。ＰＤＣＰ階層は、パケットヘッダーの圧縮を解除し(ユーザ平面の場合、２１２)、適切な送信であるか、及び重複されたパケットであるかを判断して(ユーザ平面の場合、２１１)パケットを伝達する。
【００２６】
ＰＤＣＰ階層のヘッダー圧縮は、ＲＯＨＣというインターネットパケットのＩＰ(ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ)、ＵＤＰ(Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ)、ＲＴＰ(Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ)及びＴＣＰ(Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ)などのヘッダーを圧縮する標準化された方法を用いる。ＲＯＨＣ方法は３ＧＰＰ ＬＴＥ規格に定義されておらず、ＲＦＣ３０９５規格に定義されている。ＩＰ、ＵＤＰ、ＲＴＰパケットのオーバーヘッドはＩＰｖ４の場合、４０バイト(ｂｙｔｅ)であり、ＩＰｖ６の場合、６０バイトであり、特にＶｏＩＰ(Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ)の場合、このようなオーバーヘッドは帯域幅が限定された無線通信システムで通信の効率を大きく落すことができる。
【００２７】
ＲＦＣ３０９５によれば、パケットはコンプレッサ(ｃｏｍｐｒｅｓｓｏｒ)からデコンプレッサ(ｄｅｃｏｍｐｒｅｓｓｏｒ)に送信される。ＲＦＣ３０９５を用いたＲＯＨＣ方法は、ヘッダーを構成するフィールドを一つのパケットストリーム(ｐａｃｋｅｔ ｓｔｒｅａｍ) に対して静的なフィールドと動的なフィールドから構成し、全体フィールドをコンプレッサからデコンプレッサに送信した後、静的なフィールドの内容をコンプレッサとデコンプレッサに保存し、動的なフィールドの変化内容だけをコンプレッサからデコンプレッサに送信して実際送信するヘッダーの大きさを減らすことである。例えば、ＩＰｖ６ヘッダーでバージョン(ｖｅｒｓｉｏｎ)、フローレベル(ｆｌｏｗ ｌｅｖｅｌ)、次のヘッダー(ｎｅｘｔ ｈｅａｄｅｒ)、ソース住所(ｓｏｕｒｃｅ ａｄｄｒｅｓｓ) 及び目的地住所(ｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓ)などは静的なフィールドに該当し、トラフィッククラス(ｔｒａｆｆｉｃ ｃｌａｓｓ)及びｈｏｐ ｌｉｍｉｔなどは動的なフィールドに該当する。デコンプレッサは動的なヘッダーの変化内容を受信して保存されていたコンテクストに基づいて圧縮を解除して元ヘッダーの内容を修復する。
【００２８】
コンテクスト(ｃｏｎｔｅｘｔ)とは、コンプレッサとデコンプレッサがヘッダーを圧縮して圧縮を解除するための情報である。コンテクストはパケット流れ中で前ヘッダーで抽出された静的なフィールド、圧縮と圧縮解除の基準情報を含む関連情報及びフィールドの変動に係る情報などを含む。
【００２９】
ＲＯＨＣコンプレッサは３つの状態のうちのいずれか１つに置かれるようになる。コンプレッサは最も低い圧縮状態であるＩＲ(Ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆ
ｒｅｓｈ)状態から起動して段階的にＦＯ(Ｆｉｒｓｔ Ｏｒｄｅｒ)状態からＳＯ(Ｓｅｃｏｎｄ Ｏｒｄｅｒ)状態に高い圧縮状態で変化するようになる。
【００３０】
ＩＲ状態は、コンプレッサが生成されたり再設定された状態でコンテクスト(ｃｏｎｔｅｘｔ) の静的な部分を再起動する目的を有する。コンプレッサは完全なヘッダー情報(ｃｏｍｐｌｅｔｅ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ)を送信し、完全なヘッダー情報は圧縮されない形態の静的なフィールドと動的なフィールドと付加情報を含む。この時、送信するパケットをＩＲパケットと言う。
【００３１】
ＦＯ状態ではコンプレッサが接続の両末端間のＩＰ住所、ポート番号のような静的なフィールドを認識して保存した状態で、この状態でコンプレッサは動的なフィールドの差を送信する。すなわち、ＦＯ状態は静的フィールドを圧縮しながら部分的に動的フィールドも圧縮された状態である。
【００３２】
ＳＯ状態でコンプレッサはＲＴＰシーケンスナンバーのようなすべての動的フィールドを圧縮し、ただ論理的なシーケンスナンバーと次のパケットを検証するための一部チェックサム(ｃｈｅｃｋｓｕｍ)だけを送信する。一般的に、ＦＯ状態ではすべての静的フィールドと大部分の動的フィールドが圧縮され、ＳＯ状態ではシーケンスナンバーとチェックサムを用いてすべての動的フィールドを圧縮する。
【００３３】
デコンプレッサも３つ状態のうちのいずれか１つに置かれるようになる。デコンプレッサは最も低い圧縮状態であるコンテクスト無し(Ｎｏ Ｃｏｎｔｅｘｔ)状態から静的なコンテクスト(Ｓｔａｔｉｃ Ｃｏｎｔｅｘｔ)、完全なコンテクスト(Ｆｕｌｌ Ｃｏｎｔｅｘｔ)状態に変化するようになる。
【００３４】
図３は、ＲＯＨＣの動作を行うモードを示す図面である。
【００３５】
図３によれば、ＲＯＨＣは一方向(Ｕｎｉｄｉｒｅｔｉｏｎａｌ)モード(３００、Ｕ−Ｍｏｄｅ)、両方向オプチミスティック(Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｏｐｔｉｍｉｓｔｉｃ)モード(３１０、Ｏ−Ｍｏｄｅ)、及び信頼できる両方向(Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｒｅｌｉａｂｌｅ)モード(３２０、Ｒ−Ｍｏｄｅ)の３つ動作方式を行う。各モード内でコンプレッサはＩＲ状態、ＦＯ状態及びＳＯ状態に該当することができる。
【００３６】
Ｕ−Ｍｏｄｅでパケットはコンプレッサからデコンプレッサに一方向に送信され、このモードはデコンプレッサからコンプレッサへの経路がないか、使用することができない場合、使用される。ＲＯＨＣの圧縮は必ずＵ−Ｍｏｄｅで起動すべきであり、両方向モードへの変更はパケットがデコンプレッサにより受信された後、モードの変更を望むと指示するフィードバックパケットによって成る。
【００３７】
Ｏ−Ｍｏｄｅは、Ｕ−Ｍｏｄｅと類似であるがエラー復旧リクエストメッセージ(ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ ｒｅｑｕｅｓｔ)と重要コンテクストアップデートに対する受信確認メッセージがデコンプレッサからコンプレッサに送信されることに使用されるフィードバックチャンネルがあるという差がある。Ｏ−Ｍｏｄｅは圧縮効率を極大化させながら間歇的にフィードバックチャンネルを用いる特徴を有する。
【００３８】
Ｒ−ｍｏｄｅは、多くの側面において前記２つのモードと差がある。重要な差異点としてはフィードバックチャンネルの集中的な使用とコンプレッサとデコンプレッサ間のコンテクスト同期化(ｃｏｎｔｅｘｔ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ)の損失を阻むための厳格なロジッグ(ｌｏｇｉｃ)の適用を挙げることができる。Ｒ−ｍｏｄｅではすべてのコンテクストアップデートに対してフィードバックが提供される。
【００３９】
ＶｏＬＴＥは３ＧＰＰ規格によりＲＬＣ ＵＭ(Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ)及びＰＤＣＰシーケンスナンバーが７ビットの大きさで操作される。ＲＬＣ ＵＭはヘッダーが付加するが接続の相手から受信に対する応答が必要ではないモードを意味する。
【００４０】
図４は、ＲＬＣ ＵＭにおけるデータ流れを示す図面である。
【００４１】
図４によれば、ＲＬＣ ＵＭエンティティーは送信部のＲＬＣ階層４００から送信されてラジオインターフェースを経て４２０受信部のＲＬＣ階層４１０で受信される。この時、ＲＬＣ階層は端末や基地局に存在することができる。
【００４２】
送信部のＲＬＣ階層では上位階層(ＰＤＣＰ又はＲＲＣ(Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ)階層)でデータ(ＳＤＵ)を受信してＳＤＵを送信バッファーに入れる(４０１)。ＳＤＵを分割したり連接してＲＬＣ ＰＤＵ(Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ)を生成する(４０２)。ＲＬＣ ＰＤＵにＲＬＣヘッダーを付加する(４０３)。このような方法で生成したＲＬＣ ＰＤＵを次の階層へ送信し、このように送信されたデータは受信団のＲＬＣ階層へ伝達する。
【００４３】
受信部のＲＬＣ階層では下位階層でＲＬＣ ＰＤＵを受信して受信バッファーに入れてＨＡＲＱ再配置を経る(４１３)。ＲＬＣ ＰＤＵでＲＬＣヘッダーを除去して(４１２)ＰＤＵを上位階層のＳＤＵに再組み立てる(４１１)。このような方法で生成したＳＤＵを上位階層(ＰＤＣＰ又はＲＲＣ階層)へ送信する。
【００４４】
このようなＲＬＣ ＵＭは受信確認メッセージ(ＡＣＫ／ＮＡＣＫ)を要求しないから受信確認メッセージによりパケットが再送信される無線通信環境が良くない場合、送信された音声パケットがアップリンクで損失されることができる。特に、ＲＯＨＣ動作のためにデコンプレッサはコンテクストを生成するためにＩＲパケットを受信すべきであり、受信されたＩＲパケットの情報に基づいて以後に受信される音声パケットに対してＲＯＨＣ圧縮解除動作が行われる。
【００４５】
ＲＯＨＣは接続が生成された直後にはＲＦＣ３０９５によるＵ−Ｍｏｄｅで動作する。ところで、Ｕ−Ｍｏｄｅはフィードバックチャンネルが用いることができない状況に基づいたモードであるので、フィードバックチャンネルが使用可能であっても肯定確認応答(Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＡＣＫ)だけがフィードバックされる。そこでＩＲパケットがアップリンク送信中で損失されても否定確認応答(Ｎｅｇａｔｉｖｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＮＡＣＫ)を受けることができなく、端末はＩＲパケットの損失が分かることができないからＩＲパケットを再送信しない。ＩＲパケットが損失されると、基地局のデコンプレッサは音声パケットに対するコンテクストを生成することができないのでＲＯＨＣ動作が行うことができなく、発生した呼が解除されるようになる。
【００４６】
図５は、ＩＲパケット損失によって呼が解除される問題を示す図面である。
【００４７】
図５によれば、端末５００は基地局５１０へＩＲパケットと音声パケットを送信する。端末は基地局へＩＲパケットを送信し(ｓ５０１)、基地局はＩＲパケットを受信してコンテクストを生成する(ｓ５０２)。基地局はヘッダーが圧縮された音声パケットを端末から受信して(ｓ５０３)生成されたコンテクストに基づいてヘッダーの圧縮解除を行う。
【００４８】
もし、端末が送信したＩＲパケットが損失されて送信が失敗すると(ｓ５０５)、基地局はコンテクストを生成することができず、その結果、端末が音声パケットを送信しても(ｓ５０６)基地局がコンテクストに基づいて圧縮されたヘッダーを圧縮解除することがで
きないので呼が解除されるようになる。
【００４９】
このようなＶｏＬＴＥでの呼動作時、IＲパケット損失によって呼が解除される問題を防止するためにＩＲパケットの損失を検出して連続的な通話を維持する方法を提案する。
【００５０】
図６は、従来のＶｏＬＴＥパケット受信方法を示すフローチャートである。
【００５１】
図６によれば、基地局はアップリンクでＶｏＬＴＥパケットを受信する(６００)。基地局は受信したパケットがＩＲパケットであるかを判断し(６１０)、ＩＲパケットと判断すると、コンテクストを生成する(６４０)。ＩＲパケットではないと判断すると、再びコンテクストが予め存在するかを判断する(６２０)。コンテクストが存在すると、受信されたパケットのヘッダーを圧縮解除するＲＯＨＣ圧縮解除動作を行い(６５０)、コンテクストが存在しなければ呼を解除する(６３０)。６４０段階でコンテクストが生成された後、ＩＲパケットや６５０でＲＯＨＣ圧縮解除動作が行われたパケットはＥＰＣで送信される(６６０)。
【００５２】
端末が送信したＩＲパケットが損失されると、基地局はコンテクストを生成することができない状態でＩＲパケット後に受信されるヘッダーが圧縮された音声パケットを受信するようになる。音声パケットを受信すると、ＩＲパケットがないので(６１０)コンテクストが予め存在するかを判断するようになり(６２０、コンテクストが存在しないので呼を解除する(６３０)。それで、端末が送信したＩＲパケットが損失される場合、呼は解除されるようになる。
【００５３】
図６の６３０段階のような呼の解除を阻むために図７では改善したパケット受信方法を提案する。
【００５４】
図７は、改善したＶｏＬＴＥパケット受信方法を示すフローチャートである。
【００５５】
図７によれば、基地局はアップリンクでＶｏＬＴＥパケットを受信する(７００)。基地局は受信したパケットがＩＲパケットであるかを判断し(７１０)、ＩＲパケットと判断すると、コンテクストを生成する(７４０)。ＩＲパケットではないと判断すると、再びコンテクストが予め存在するかを判断する(７２０)。コンテクストが存在すると、受信されたパケットのヘッダーを圧縮解除するＲＯＨＣ圧縮解除動作を行い(７５０)、コンテクストが存在しなければ端末へＳＮＡＣＫを送信する(７３０)。７４０段階でコンテクストが生成された後、ＩＲパケットや７５０でＲＯＨＣ圧縮解除動作が行われたパケットはＥＰＣで送信される(７６０)。
【００５６】
図７の改善したパケット受信方法と従来パケット受信方法の差は受信されたパケットがＩＲパケットではなくコンテクストが存在しないとき、呼を解除せず端末でＳＮＡＣＫを送信することである。ＳＮＡＣＫはＳＴＡＴＩＣ−ＮＡＣＫであり、これは静的なコンテクストが損傷されたと判断されるとき、デコンプレッサからコンプレッサに送信する否定応答確認でＯ−ＭｏｄｅとＲ−Ｍｏｄｅで送信することができるフィードバックである。
【００５７】
このようなＳＮＡＣＫを受信すると、コンプレッサはＦＯ状態でＩＲ状態となり、デコンプレッサでＩＲパケットを送信するようになる。端末がＩＲパケットを再び基地局へ送信すると、基地局は図７のパケット受信方法によりＩＲパケットによるコンテクストを生成するようになるので、基地局は端末がＩＲパケット送信後に送信した音声パケットの圧縮されたヘッダーを正常に圧縮解除して呼を維持することができるようになる。
【００５８】
図８は、本発明の実施形態を実施することができる装置のブロック図である。
【００５９】
図８によれば、受信機８１０は制御部８１３、ヘッダー圧縮部８１２及び送受信部８１１から構成されることができる。送受信部は信号を送受信する。制御部は端末から音声通話のためのパケットを受信し、音声通話のためのパケットがＩＲ(Ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ) パケットであるかを判断し、音声通話のためのパケットが前記ＩＲパケットではなければ、基地局にＲＯＨＣ圧縮解除のためのコンテクスト(ｃｏｎｔｅｘｔ)が生成されているかを判断し、コンテクストが生成されていないと、端末へ否定確認応答(Ｎｅｇａｔｉｖｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＮＡＣＫ)を送信するように制御することができる。
【００６０】
また、制御部は端末からＩＲパケットを受信するようにさらに制御することができ、受信したＩＲパケットを用いてコンテクストを生成するようにさらに制御することができる。さらに、端末から圧縮されたヘッダーを含む音声パケットを受信し、コンテクストに基づいて前記圧縮されたヘッダーを圧縮解除するように制御することができる。
【００６１】
また、制御部は音声通話のためのパケットがＩＲパケットであれば、前記音声通話のためのパケットを用いてコンテクストを生成するようにして、コンテクストが生成されていると、圧縮されたヘッダーを含む端末から受信された音声パケットを圧縮されたヘッダーをコンテクストに基づいて圧縮解除して受信するようにさらに制御することができる。
【００６２】
このようなヘッダー圧縮解除はヘッダー圧縮解除部により行われることができ、これは制御部により制御されることができる。
【００６３】
送信機８００は、制御部８０１、ヘッダー圧縮部８０２及び送受信部８０３から構成されることができる。送受信部は信号を送受信し、制御部は音声通話に係るパケットを送信するように制御する。さらに、制御部は、ＩＲパケット及び音声パケットを送信し、ＳＮＡＣＫを受信機から受信してＳＮＡＣＫを受信する場合、ＩＲパケットを再び送信するように制御することができる。
【００６４】
上述したように、本発明はｅＮＢが送信されたＩＲパケットが損失されてもＵＥが進行中の音声通話を維持することができるが点がある。
【００６５】
本発明は、様々な実施形態を参照して図示されて説明されたが、添付された特許請求の範囲及びその均等物により定義されたような本発明の思想と範囲を逸脱せず形態および細部事項における様々な変化がなされることを当業者は理解するだろう。
【符号の説明】
【００６６】
５００  端末
５１０  基地局
８００  送信機
８０１  制御部
８０２  ヘッダー圧縮部
８０３  送受信部
８１０  受信機
８１１  送受信部
８１３  制御部
【図１】
2020171015.tif 000003
【図２】
2020171015.tif 000004
【図３】
2020171015.tif 000005
【図４】
2020171015.tif 000006
【図５】
2020171015.tif 000007
【図６】
2020171015.tif 000008
【図７】
2020171015.tif 000009
【図８】
2020171015.tif 000010