(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-06-10
(45)【発行日】2022-06-20
(54)【発明の名称】LTEシステムを用いた呼の実行方法及び装置
(51)【国際特許分類】
H04W 80/02 20090101AFI20220613BHJP
H04W 28/04 20090101ALI20220613BHJP
H04L 1/16 20060101ALI20220613BHJP
H04W 76/19 20180101ALI20220613BHJP
【FI】
H04W80/02
H04W28/04
H04L1/16
H04W76/19
(21)【出願番号】P 2020082136
(22)【出願日】2020-05-07
(62)【分割の表示】P 2017514648の分割
【原出願日】2015-09-23
【審査請求日】2020-05-07
(32)【優先日】2014-09-24
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】10-2014-0177523
(32)【優先日】2014-12-10
(33)【優先権主張国・地域又は機関】KR
(73)【特許権者】
【識別番号】503447036
【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド
(74)【代理人】
【識別番号】100133400
【氏名又は名称】阿部 達彦
(74)【代理人】
【識別番号】100110364
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100154922
【氏名又は名称】崔 允辰
(74)【代理人】
【識別番号】100140534
【氏名又は名称】木内 敬二
(72)【発明者】
【氏名】ヨンヨン・キム
(72)【発明者】
【氏名】タイホ・ユン
【審査官】桑原 聡一
(56)【参考文献】
【文献】国際公開第2013/052136(WO,A1)
【文献】特表2017-535117(JP,A)
【文献】国際公開第2009/072175(WO,A1)
【文献】特表2014-528674(JP,A)
【文献】NTT DOCOMO, INC., LG Electronics Inc., Nokia Networks,Clarification of the decompressor state and mode after PDCP re-establishment[online], 3GPP TSG-RAN WG2#87 R2-143832,2014年08月18日,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_87/Docs/R2-143832.zip>
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24-7/26
H04W 4/00-99/00
H04L 1/16
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
受信機がLTE(Long-Term Evolution)システムを用いた音声通話を行う方法であって、
送信機から音声通話のためのパケットを受信する過程と、
UM(unacknowledged mode)であるRLC(radio link control)階層から前記受信された音声通話のためのパケットをPDCP(packet data convergence protocol)階層に伝達する過程と、
前記PDCP階層において、
前記音声通話のためのパケットのヘッダーに対するROHC(Robust Header Compression)圧縮解除動作を行えるか否か判断する過程と、
前記
ROHC圧縮解除動作を行えないと判断すると
、前記音声通話の接続を
解消せずに、前記送信機に否定確認応答(Negative Acknowledgement、NACK)を送信する過程と、
前記NACKの送信に対応し、前記送信機からIR
(Initialization and Refresh)パケットを受信する過程と、を含み、
前記ROHC圧縮解除動作は、前記受信された音声通話のためのパケットが前記IRパケットではなく、前記受信機において前記ROHC圧縮解除動作に利用可能なコンテクストが確認されないことに基づいて検出され、
前記コンテクストは、パケットヘッダーから抽出された静的な(static)コンテクスト、圧縮と圧縮解除の基準情報及びフィールドの変動に関する情報を含み、
前記
NACKは、
前記静的な(static)コンテクスト
が損傷
したと判断されることに基づいて送信される
ことを特徴とする音声通話実行方法。
【請求項2】
前記NACKに対応して受信した前記IRパケットを用いて
、前記コンテクストを生成する過程をさらに含む
ことを特徴とする、請求項1に記載の音声通話実行方法。
【請求項3】
前記送信機から圧縮されたヘッダーを含む音声パケットが受信されると、前記生成されたコンテクストに基づいて前記圧縮されたヘッダーを圧縮解除する段階をさらに含む
ことを特徴とする、請求項2に記載の音声通話実行方法。
【請求項4】
前記ROHC圧縮解除動作を行えるか否か判断する過程は、
前記受信された音声通話のためのパケットが前記IRパケットであるか否か確認する過程と、
前記受信された音声通話のためのパケットが前記IRパケット
ではないと、前記コンテクストが
前記受信機に保存されているか否かを確認する過程と、
前記コンテクストが保存されていると、
前記保存されたコンテクストを用いて前記ROHC圧縮解除動作を行えるか否か確認する過程と、をさらに含む
ことを特徴とする、請求項1に記載の音声通話実行方法。
【請求項5】
前記コンテクストが保存されていないと、前記NACKを前記送信機に送信する過程をさらに含む
ことを特徴とする、請求項4に記載の音声通話実行方法。
【請求項6】
前記NACKは、スタティックNACK(Static NACK)である
ことを特徴とする、請求項1に記載の音声通話実行方法。
【請求項7】
LTE(Long-Term Evolution)システムを用いた音声通話を行う受信機であって、
信号を送受信する送受信部と、
送信機から音声通話のためのパケットを受信し、UM(unacknowledged mode)であるRLC(radio link control)階層から前記受信された音声通話のためのパケットをPDCP(packet data convergence protocol)階層に伝達し、前記PDCP階層において、
前記音声通話のためのパケットのヘッダーに対するROHC(Robust Header Compression)圧縮解除動作を行えるか否か判断し、前記ROHC圧縮解除動作を行えないと判断すると、前記音声通話の接続を
解除せずに、前記送信機に否定確認応答(Negative Acknowledgement、NACK)を送信するように制御し、前記NACKの送信に対応し、前記送信機からIR
(Initialization and Refresh)パケットを受信するように制御する制御部と、を含
み、
前記ROHC圧縮解除動作は、前記受信された音声通話のためのパケットが前記IRパケットではなく、前記受信機において前記ROHC圧縮解除動作に利用可能なコンテクストが確認されないことに基づいて検出され、
前記コンテクストは、パケットヘッダーから抽出された静的な(static)コンテクスト、圧縮と圧縮解除の基準情報及びフィールドの変動に関する情報を含み、
前記NACKは、前記静的な(static)コンテクストが損傷したと判断されることに基づいて送信される
ことを特徴とする受信機。
【請求項8】
前記制御部は、
前記NACKに対応して受信した前記IRパケットを用い
て前記コンテクストを生成するようにさらに制御する
ことを特徴とする、請求項7に記載の受信機。
【請求項9】
前記制御部は、
前記送信機から圧縮されたヘッダーを含む音声パケットが受信されると、前記生成されたコンテクストに基づいて前記圧縮されたヘッダーを圧縮解除するようにさらに制御する
ことを特徴とする、請求項8に記載の受信機。
【請求項10】
前記制御部は、
前記受信された音声通話のためのパケットが前記IRパケットであるか否か確認し、前記受信された音声通話のためのパケットが前記IRパケット
ではないと、
前記コンテクストが
前記受信機に保存されているか否かを確認し、前記コンテクストが保存されていると、
前記保存されたコンテクストを用いて前記ROHC圧縮解除動作を行えるか否か確認するようにさらに制御する
ことを特徴とする、請求項7に記載の受信機。
【請求項11】
前記制御部は、
前記コンテクストが保存されていないと、前記NACKを前記送信機に送信するようにさらに制御する
ことを特徴とする、請求項10に記載の受信機。
【請求項12】
前記NACKは、スタティックNACK(Static NACK)である
ことを特徴とする、請求項7に記載の受信機。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、Voice over LTE(以下、VoLTEとする)に関し、より具体的にLTEシステムを用いて音声通話時に呼を維持する方法及び装置に関する。
【背景技術】
【0002】
VoLTEは、3GPP(3rd Generation Partnership Project)LTE(Long-Term Evolution)及びLTE-A(LTE Advanced)ネットワークでパケットを用いた音声通話を可能にする技術を統合的に呼ぶ用語である。VoLTEを用いる場合、既存のサーキット通話方式に対して接続速度が早く、通話品質を向上させることができるという特徴があり、近年、VoLTE技術は商用化段階に入っている。
【0003】
3GPP規格に応じてVoLTE呼の場合、PDCP(Packet Data Convergence Protocol)階層(layer)がRFC(Request for Comments)3095規格を用いたパケットのROHC(Robust Header Compression)及び圧縮解除動作を行う。音声通話動作において、ROHC動作を行うために基地局は端末が送信するIR(Initialization and Refresh)パケットを受信し、受信されたIRパケットの情報に基づいて以後に受信される圧縮されたヘッダーを有する音声パケットに対してROHC圧縮解除動作を行う。
【0004】
上述した情報は、ただ本明細書の理解を助けるための背景技術情報で存在する。上述したものなかのいずれも本明細書の開示と関連して先行技術として適用されることができるかに関してはどんな決定も下ろされないか、又はどんな主張も申し立てられない。
【先行技術文献】
【特許文献】
【0005】
【発明の概要】
【発明が解決しようとする課題】
【0006】
ところで、ROHC規格はパケット損失に対する復旧メカニズムを定義しているが、IRパケットに対する復旧メカニズムは明示的に定義されなかった。よって、IRパケットが損失される場合、基地局は音声パケットに対するコンテクスト(Context)を形成することができないからROHC動作が失敗するようになり、発生した呼が解除されるようになる。そこで音声呼を維持するための方法が必要である。
【課題を解決するための手段】
【0007】
本発明は、少なくとも前述した問題点及び/又は欠点を解消し、後述する利点を提供するものである。そこで、本発明の一側面は、LTE(Long-Term Evolution) システムにおいて音声呼を処理する方法及び装置を提供することである。
【0008】
本発明の一側面によれば、基地局がLTE(Long-Term Evolution)システムを用いた音声通話を行う方法であって、端末から音声通話のためのパケットを受信する過程と、前記音声通話のためのパケットがIR(Initialization and Refresh)パケットであるかを判断する過程と、前記音声通話のためのパケットが前記IRパケットではなければ、前記基地局にROHC圧縮解除のためのコンテクスト(context) が生成されているかを決定する過程と、前記コンテクストが生成されていないと、前記端末へ否定確認応答(Negative Acknowledgement、NACK)を送信する過程と、及び前記端末から前記IRパケットを受信する過程と、をさらに含むことを特徴とする。
【0009】
本発明の他の側面によれば、LTE(Long-Term Evolution)システムを用いた音声通話を行う基地局であって、信号を送受信する送受信部と、及び端末から音声通話のためのパケットを受信し、前記音声通話のためのパケットがIR(Initialization and Refresh) パケットであるかを判断し、前記音声通話のためのパケットが前記IRパケットではなければ、前記基地局にROHC圧縮解除のためのコンテクスト(context) が生成されているかを決定し、前記コンテクストが生成されていないと、前記端末へ否定確認応答(Negative Acknowledgement、NACK)を送信し、前記端末から前記IRパケットを受信するように制御することを特徴とする制御部と、を含むことを特徴とする。
【0010】
本開示の他の態様、利点、および顕著な特徴は添付の図面に係る以下の詳細な説明から当業者には明らかであり、これは本開示の様々な実施形態を開示する。
【発明の効果】
【0011】
本発明の実施形態による音声通話を維持する方法によれば、端末が基地局へ送信したIRパケットが損失されても音声呼を維持することができる。
【図面の簡単な説明】
【0012】
【
図3】ROHCの動作を行うモードを示す図面である。
【
図4】RLC UMでのデータ流れを示す図面である。
【
図5】IRパケット損失により呼が解除される問題を示す図面である。
【
図6】従来のVoLTEパケット受信方法を示すフローチャートである。
【
図7】改善したVoLTEパケット受信方法を示すフローチャートである。
【
図8】本発明の実施形態を行うことができる装置のブロック図である。
【発明を実施するための形態】
【0013】
添付された図面を参照する次の説明は請求範囲及びこの等価物によって定義されるような本発明の多様な実施形態の包括的な理解を助けるために提供される。それはこのような理解を助けるために多様な特定詳細事項を含むが、これらはただ例示的なことで見なされなければならない。したがって、本技術分野の通常の技術者は本明細書に説明された多様な実施形態の多様な変更及び修正が本発明の範囲及び思想から逸脱せず成ることができるということを認識するだろう。さらに、公知された機能及び構成に対する説明は明確性及び簡潔性のために省略されることができる。
【0014】
次の説明及び請求範囲で用いられた用語及び単語は書誌意味に限定されず、ただ発明者によって本発明の明確で一貫性ある理解ができるようにするために用いられる。したがって、本発明の多様な実施形態に対する次の説明は添付された請求範囲及びこの等価物によって定義されるように本発明を制限するためではなく、ただ例示のために提供されるということは本技術分野の技術者には明白であろう。
【0015】
単数形態“a”、“an”及び“the”は文脈がはっきり異なり指示しなければ複数の指示ターゲットを含むことに理解されなければならない。したがって、例えば、“構成要素表面(component surface)”に対する参照物はこのような表面中の1つ以上に対する参照物を含む。
【0016】
また、本発明の実施形態を具体的に説明するにあたり、直交周波数分割多重方式(Orthogonal frequency-division multiplexing、OFDM)に基づく無線通信システム、特に3GPPLTE標準を主な対象とするが、本発明の主な要旨は類似の技術的背景及びチャンネル形態を有するそのほかの通信システムにも本発明の範囲を大きく逸脱せず範囲で僅かの変形で適用可能であり、これは本発明の技術分野で熟練された技術的知識を有する者の判断で可能であろう。
【0017】
この時、処理フローチャートの各ブロックとフローチャートの図面の組合は、コンピュータープログラムインストラクションによって行われることができることを理解することができるだろう。これらコンピュータープログラムインストラクションは、汎用コンピューター、特殊用コンピューター又はその他プログラム可能なデータプロセッシング装備のプロセッサに搭載されることができるので、コンピューター又はその他プログラム可能なデータプロセッシング装備のプロセッサを介して行われるそのインストラクションが、フローチャートブロックで説明された機能を行う手段を生成するようになる。これらコンピュータープログラムインストラクションは、特定方式で機能を具現するためにコンピューター又はその他プログラム可能なデータプロセッシング装備を志向することができるコンピューター利用可能、又はコンピューター判読可能メモリーに保存されることも可能であるので、そのコンピューター利用可能又はコンピューター判読可能メモリーに保存されたインストラクションは、フローチャートブロックで説明された機能を行うインストラクション手段を内包する製造品目を生産することも可能である。コンピュータープログラムインストラクションは、コンピューター又はその他プログラム可能なデータプロセッシング装備上に搭載されることも可能であるので、コンピューター又はその他プログラム可能なデータプロセッシング装備上で一連の動作段階が行われ、コンピューターで実行されるプロセスを生成してコンピューター又はその他プログラム可能なデータプロセッシング装備を行うインストラクションはフローチャートブロックで説明された機能を行うための段階を提供することも可能である。
【0018】
また、各ブロックは、特定された論理的機能を行うための1つ以上の実行可能なインストラクションを含むモジュール、セグメント又はコードの一部を示すことができる。また、幾つか代替実行例ではブロックで言及された機能が手順を外れて発生することも可能であることを注目しなければならない。例えば、接して示されている2つのブロックは、実は実質的に同時に行われることも可能で、又はそのブロックが時々該当する機能によって逆順に行われることも可能である。
【0019】
この時、本実施形態に用いられる‘~部’という用語は、ソフトウェア又はFPGA、並びにASICのようなハードウェア構成要素を意味し、‘~部’はどんな役目を行う。しかし、‘~部’は、ソフトウェア又はハードウェアで限定される意味ではない。‘~部’はアドレシングすることができる保存媒体にあるように構成されることもでき、1つ又はその以上のプロセッサを再生させるように構成されることもできる。したがって、一例として‘~部’はソフトウェア構成要素、客体志向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーティン、プログラムコードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素と‘~部’のうちで提供される機能はより小さい数の構成要素及び‘~部’に結合されたり追加的な構成要素と‘~部’でさらに分離することができる。だけでなく、構成要素及び‘~部’はデバイス又は保安マルチメディアカード内の1つ又はその以上のCPUを再生させるように具現されることもできる。
【0020】
【0021】
図1によれば、PDCP階層は無線網プロトコルを構成する階層のうちの一つとして、ユーザ平面(user plane)及び制御平面(control plane)に共通的に含まれる。PDCPはRLC(Radio Link Control)階層上に存在してベアラー別でそれぞれのPDCPエンティティー100、110が存在する。
【0022】
【0023】
図2によれば、PDCPエンティティーは送信部のPDCP階層200から送信されて
ラジオインターフェース220を経て受信部のPDCP階層210で受信される。この時、PDCP階層は端末やE-UTRAN(evolved UMTS Terrestrial RadioAccess Network)に存在することができる。
【0024】
送信部のPDCP階層はパケットにシーケンスナンバー(sequence number)を付し(201)、パケットのヘッダーを圧縮する(ユーザ平面の場合、202)。PDCP SDU(Servicedataunit)に関連されるパケットの場合、無欠性(integrity)保護(制御平面の場合、203)と暗号化(204)過程を経て、PDCP SDUに関連されないパケットは無欠性保護と暗号化過程を経ない。前記過程を通過したパケットはPDCPヘッダーが付加されて受信部のPDCP階層へ送信される。
【0025】
受信部のPDCP階層は受信されたパケットのPDCPヘッダーを除去し(215)、PDC P SDUに関連されるパケットの場合、暗号を解読し(214)、無欠性を検査(制御平面の場合、213)する。PDCP SDUに関連されないパケットの場合、無欠性検査と暗号解読過程を経ない。PDCP階層は、パケットヘッダーの圧縮を解除し(ユーザ平面の場合、212)、適切な送信であるか、及び重複されたパケットであるかを判断して(ユーザ平面の場合、211)パケットを伝達する。
【0026】
PDCP階層のヘッダー圧縮は、ROHCというインターネットパケットのIP(InternetProtocol)、UDP(User Datagram Protocol)、RTP(Real-time Transport Protocol)及びTCP(Transmission Control Protocol)などのヘッダーを圧縮する標準化された方法を用いる。ROHC方法は3GPP LTE規格に定義されておらず、RFC3095規格に定義されている。IP、UDP、RTPパケットのオーバーヘッドはIPv4の場合、40バイト(byte)であり、IPv6の場合、60バイトであり、特にVoIP(Voice over Internet Protocol)の場合、このようなオーバーヘッドは帯域幅が限定された無線通信システムで通信の効率を大きく落すことができる。
【0027】
RFC3095によれば、パケットはコンプレッサ(compressor)からデコンプレッサ(decompressor)に送信される。RFC3095を用いたROHC方法は、ヘッダーを構成するフィールドを一つのパケットストリーム(packet stream) に対して静的なフィールドと動的なフィールドから構成し、全体フィールドをコンプレッサからデコンプレッサに送信した後、静的なフィールドの内容をコンプレッサとデコンプレッサに保存し、動的なフィールドの変化内容だけをコンプレッサからデコンプレッサに送信して実際送信するヘッダーの大きさを減らすことである。例えば、IPv6ヘッダーでバージョン(version)、フローレベル(flow level)、次のヘッダー(next header)、ソース住所(source address) 及び目的地住所(destination address)などは静的なフィールドに該当し、トラフィッククラス(traffic class)及びhop limitなどは動的なフィールドに該当する。デコンプレッサは動的なヘッダーの変化内容を受信して保存されていたコンテクストに基づいて圧縮を解除して元ヘッダーの内容を修復する。
【0028】
コンテクスト(context)とは、コンプレッサとデコンプレッサがヘッダーを圧縮して圧縮を解除するための情報である。コンテクストはパケット流れ中で前ヘッダーで抽出された静的なフィールド、圧縮と圧縮解除の基準情報を含む関連情報及びフィールドの変動に係る情報などを含む。
【0029】
ROHCコンプレッサは3つの状態のうちのいずれか1つに置かれるようになる。コンプレッサは最も低い圧縮状態であるIR(Initialization and Ref
resh)状態から起動して段階的にFO(First Order)状態からSO(Second Order)状態に高い圧縮状態で変化するようになる。
【0030】
IR状態は、コンプレッサが生成されたり再設定された状態でコンテクスト(context) の静的な部分を再起動する目的を有する。コンプレッサは完全なヘッダー情報(complete header information)を送信し、完全なヘッダー情報は圧縮されない形態の静的なフィールドと動的なフィールドと付加情報を含む。この時、送信するパケットをIRパケットと言う。
【0031】
FO状態ではコンプレッサが接続の両末端間のIP住所、ポート番号のような静的なフィールドを認識して保存した状態で、この状態でコンプレッサは動的なフィールドの差を送信する。すなわち、FO状態は静的フィールドを圧縮しながら部分的に動的フィールドも圧縮された状態である。
【0032】
SO状態でコンプレッサはRTPシーケンスナンバーのようなすべての動的フィールドを圧縮し、ただ論理的なシーケンスナンバーと次のパケットを検証するための一部チェックサム(checksum)だけを送信する。一般的に、FO状態ではすべての静的フィールドと大部分の動的フィールドが圧縮され、SO状態ではシーケンスナンバーとチェックサムを用いてすべての動的フィールドを圧縮する。
【0033】
デコンプレッサも3つ状態のうちのいずれか1つに置かれるようになる。デコンプレッサは最も低い圧縮状態であるコンテクスト無し(No Context)状態から静的なコンテクスト(Static Context)、完全なコンテクスト(Full Context)状態に変化するようになる。
【0034】
図3は、ROHCの動作を行うモードを示す図面である。
【0035】
図3によれば、ROHCは一方向(Unidiretional)モード(300、U-Mode)、両方向オプチミスティック(Bidirectional Optimistic)モード(310、O-Mode)、及び信頼できる両方向(Bidirectional Reliable)モード(320、R-Mode)の3つ動作方式を行う。各モード内でコンプレッサはIR状態、FO状態及びSO状態に該当することができる。
【0036】
U-Modeでパケットはコンプレッサからデコンプレッサに一方向に送信され、このモードはデコンプレッサからコンプレッサへの経路がないか、使用することができない場合、使用される。ROHCの圧縮は必ずU-Modeで起動すべきであり、両方向モードへの変更はパケットがデコンプレッサにより受信された後、モードの変更を望むと指示するフィードバックパケットによって成る。
【0037】
O-Modeは、U-Modeと類似であるがエラー復旧リクエストメッセージ(error recovery request)と重要コンテクストアップデートに対する受信確認メッセージがデコンプレッサからコンプレッサに送信されることに使用されるフィードバックチャンネルがあるという差がある。O-Modeは圧縮効率を極大化させながら間歇的にフィードバックチャンネルを用いる特徴を有する。
【0038】
R-modeは、多くの側面において前記2つのモードと差がある。重要な差異点としてはフィードバックチャンネルの集中的な使用とコンプレッサとデコンプレッサ間のコンテクスト同期化(context synchronization)の損失を阻むための厳格なロジッグ(logic)の適用を挙げることができる。R-modeではすべてのコンテクストアップデートに対してフィードバックが提供される。
【0039】
VoLTEは3GPP規格によりRLC UM(Unacknowledged Mode)及びPDCPシーケンスナンバーが7ビットの大きさで操作される。RLC UMはヘッダーが付加するが接続の相手から受信に対する応答が必要ではないモードを意味する。
【0040】
図4は、RLC UMにおけるデータ流れを示す図面である。
【0041】
図4によれば、RLC UMエンティティーは送信部のRLC階層400から送信されてラジオインターフェースを経て420受信部のRLC階層410で受信される。この時、RLC階層は端末や基地局に存在することができる。
【0042】
送信部のRLC階層では上位階層(PDCP又はRRC(Radio Resource Control)階層)でデータ(SDU)を受信してSDUを送信バッファーに入れる(401)。SDUを分割したり連接してRLC PDU(Protocol Data Unit)を生成する(402)。RLC PDUにRLCヘッダーを付加する(403)。このような方法で生成したRLC PDUを次の階層へ送信し、このように送信されたデータは受信団のRLC階層へ伝達する。
【0043】
受信部のRLC階層では下位階層でRLC PDUを受信して受信バッファーに入れてHARQ再配置を経る(413)。RLC PDUでRLCヘッダーを除去して(412)PDUを上位階層のSDUに再組み立てる(411)。このような方法で生成したSDUを上位階層(PDCP又はRRC階層)へ送信する。
【0044】
このようなRLC UMは受信確認メッセージ(ACK/NACK)を要求しないから受信確認メッセージによりパケットが再送信される無線通信環境が良くない場合、送信された音声パケットがアップリンクで損失されることができる。特に、ROHC動作のためにデコンプレッサはコンテクストを生成するためにIRパケットを受信すべきであり、受信されたIRパケットの情報に基づいて以後に受信される音声パケットに対してROHC圧縮解除動作が行われる。
【0045】
ROHCは接続が生成された直後にはRFC3095によるU-Modeで動作する。ところで、U-Modeはフィードバックチャンネルが用いることができない状況に基づいたモードであるので、フィードバックチャンネルが使用可能であっても肯定確認応答(Acknowledgement、ACK)だけがフィードバックされる。そこでIRパケットがアップリンク送信中で損失されても否定確認応答(Negative Acknowledgement、NACK)を受けることができなく、端末はIRパケットの損失が分かることができないからIRパケットを再送信しない。IRパケットが損失されると、基地局のデコンプレッサは音声パケットに対するコンテクストを生成することができないのでROHC動作が行うことができなく、発生した呼が解除されるようになる。
【0046】
図5は、IRパケット損失によって呼が解除される問題を示す図面である。
【0047】
図5によれば、端末500は基地局510へIRパケットと音声パケットを送信する。端末は基地局へIRパケットを送信し(s501)、基地局はIRパケットを受信してコンテクストを生成する(s502)。基地局はヘッダーが圧縮された音声パケットを端末から受信して(s503)生成されたコンテクストに基づいてヘッダーの圧縮解除を行う。
【0048】
もし、端末が送信したIRパケットが損失されて送信が失敗すると(s505)、基地局はコンテクストを生成することができず、その結果、端末が音声パケットを送信しても(s506)基地局がコンテクストに基づいて圧縮されたヘッダーを圧縮解除することがで
きないので呼が解除されるようになる。
【0049】
このようなVoLTEでの呼動作時、IRパケット損失によって呼が解除される問題を防止するためにIRパケットの損失を検出して連続的な通話を維持する方法を提案する。
【0050】
図6は、従来のVoLTEパケット受信方法を示すフローチャートである。
【0051】
図6によれば、基地局はアップリンクでVoLTEパケットを受信する(600)。基地局は受信したパケットがIRパケットであるかを判断し(610)、IRパケットと判断すると、コンテクストを生成する(640)。IRパケットではないと判断すると、再びコンテクストが予め存在するかを判断する(620)。コンテクストが存在すると、受信されたパケットのヘッダーを圧縮解除するROHC圧縮解除動作を行い(650)、コンテクストが存在しなければ呼を解除する(630)。640段階でコンテクストが生成された後、IRパケットや650でROHC圧縮解除動作が行われたパケットはEPCで送信される(660)。
【0052】
端末が送信したIRパケットが損失されると、基地局はコンテクストを生成することができない状態でIRパケット後に受信されるヘッダーが圧縮された音声パケットを受信するようになる。音声パケットを受信すると、IRパケットがないので(610)コンテクストが予め存在するかを判断するようになり(620、コンテクストが存在しないので呼を解除する(630)。それで、端末が送信したIRパケットが損失される場合、呼は解除されるようになる。
【0053】
図6の630段階のような呼の解除を阻むために
図7では改善したパケット受信方法を提案する。
【0054】
図7は、改善したVoLTEパケット受信方法を示すフローチャートである。
【0055】
図7によれば、基地局はアップリンクでVoLTEパケットを受信する(700)。基地局は受信したパケットがIRパケットであるかを判断し(710)、IRパケットと判断すると、コンテクストを生成する(740)。IRパケットではないと判断すると、再びコンテクストが予め存在するかを判断する(720)。コンテクストが存在すると、受信されたパケットのヘッダーを圧縮解除するROHC圧縮解除動作を行い(750)、コンテクストが存在しなければ端末へSNACKを送信する(730)。740段階でコンテクストが生成された後、IRパケットや750でROHC圧縮解除動作が行われたパケットはEPCで送信される(760)。
【0056】
図7の改善したパケット受信方法と従来パケット受信方法の差は受信されたパケットがIRパケットではなくコンテクストが存在しないとき、呼を解除せず端末でSNACKを送信することである。SNACKはSTATIC-NACKであり、これは静的なコンテクストが損傷されたと判断されるとき、デコンプレッサからコンプレッサに送信する否定応答確認でO-ModeとR-Modeで送信することができるフィードバックである。
【0057】
このようなSNACKを受信すると、コンプレッサはFO状態でIR状態となり、デコンプレッサでIRパケットを送信するようになる。端末がIRパケットを再び基地局へ送信すると、基地局は
図7のパケット受信方法によりIRパケットによるコンテクストを生成するようになるので、基地局は端末がIRパケット送信後に送信した音声パケットの圧縮されたヘッダーを正常に圧縮解除して呼を維持することができるようになる。
【0058】
図8は、本発明の実施形態を実施することができる装置のブロック図である。
【0059】
図8によれば、受信機810は制御部813、ヘッダー圧縮部812及び送受信部811から構成されることができる。送受信部は信号を送受信する。制御部は端末から音声通話のためのパケットを受信し、音声通話のためのパケットがIR(Initialization and Refresh) パケットであるかを判断し、音声通話のためのパケットが前記IRパケットではなければ、基地局にROHC圧縮解除のためのコンテクスト(context)が生成されているかを判断し、コンテクストが生成されていないと、端末へ否定確認応答(Negative Acknowledgement、NACK)を送信するように制御することができる。
【0060】
また、制御部は端末からIRパケットを受信するようにさらに制御することができ、受信したIRパケットを用いてコンテクストを生成するようにさらに制御することができる。さらに、端末から圧縮されたヘッダーを含む音声パケットを受信し、コンテクストに基づいて前記圧縮されたヘッダーを圧縮解除するように制御することができる。
【0061】
また、制御部は音声通話のためのパケットがIRパケットであれば、前記音声通話のためのパケットを用いてコンテクストを生成するようにして、コンテクストが生成されていると、圧縮されたヘッダーを含む端末から受信された音声パケットを圧縮されたヘッダーをコンテクストに基づいて圧縮解除して受信するようにさらに制御することができる。
【0062】
このようなヘッダー圧縮解除はヘッダー圧縮解除部により行われることができ、これは制御部により制御されることができる。
【0063】
送信機800は、制御部801、ヘッダー圧縮部802及び送受信部803から構成されることができる。送受信部は信号を送受信し、制御部は音声通話に係るパケットを送信するように制御する。さらに、制御部は、IRパケット及び音声パケットを送信し、SNACKを受信機から受信してSNACKを受信する場合、IRパケットを再び送信するように制御することができる。
【0064】
上述したように、本発明はeNBが送信されたIRパケットが損失されてもUEが進行中の音声通話を維持することができるが点がある。
【0065】
本発明は、様々な実施形態を参照して図示されて説明されたが、添付された特許請求の範囲及びその均等物により定義されたような本発明の思想と範囲を逸脱せず形態および細部事項における様々な変化がなされることを当業者は理解するだろう。
【符号の説明】
【0066】
500 端末
510 基地局
800 送信機
801 制御部
802 ヘッダー圧縮部
803 送受信部
810 受信機
811 送受信部
813 制御部