(57)【要約】端末は、通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得するアプリケーション対応情報取得部と、自機が対応するアプリケーションのうち、第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を通信相手端末と折衝する利用アプリケーション折衝部と、アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
2018029939.tif 000002
【特許請求の範囲】
【請求項１】
通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得する取得部と、
自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝する折衝部と、
前記アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、
を具備する端末。
【請求項２】
自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションを示す第２のアプリケーション対応情報を前記基地局へ通知する第１通知部、をさらに具備する、
請求項１に記載の端末。
【請求項３】
前記折衝部によって利用が決定されたアプリケーションを示す利用アプリケーション情報を前記基地局へ通知する第２通知部、をさらに具備する、
請求項１に記載の端末。
【請求項４】
前記端末がハンドオーバする場合、ハンドオーバ先基地局が対応するアプリケーションの情報に基づいて、利用中のアプリケーションの停止又は継続を判断する制御部、をさらに具備する、
請求項１に記載の端末。
【請求項５】
前記制御部は、前記アプリケーションを停止した後、前記端末が当該アプリケーションに対応する基地局へハンドオーバする場合、当該アプリケーションの利用を再開する、
請求項４に記載の端末。
【請求項６】
前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、
前記圧縮モード決定部は、ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する、
請求項１に記載の端末。
【請求項７】
前記ＥＣＮの通知ビットを送信するフィールドは、ＴｏＳ（Type of Service）フィールド又はTraffic Classフィールドである、
請求項６に記載の端末。
【請求項８】
前記アプリケーションは、ＭＭＣＭＨ（Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI）であり、
前記圧縮モード決定部は、ＣＩＤ(Context ID)を送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する、
請求項１に記載の端末。
【請求項９】
自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、
前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、
前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、
を具備する基地局。
【請求項１０】
端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、
前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、
前記アプリケーションの折衝結果に基づいて圧縮モードを決定する、
通信方法。
【請求項１１】
基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、
前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、
前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する、
通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、端末、基地局及び通信方法に関する。
【背景技術】
【０００２】
３ＧＰＰ（Third Generation Partnership Project）のＬＴＥ（Long Term Evolution）ネットワークにおける無線アクセス網の端末（ＵＥ（User Equipment）と呼ばれることもある）及び基地局（ｅＮＢ（e Node B）と呼ばれることもある）の間においてヘッダ圧縮（ＲｏＨＣ：Robust Header Compression）がサポートされている（例えば、非特許文献１を参照）。ＲｏＨＣは、非特許文献２等に規格化されている。ＲｏＨＣでは、ＩＰ(Internet Protocol)ヘッダ、ＵＤＰ(User Datagram Protocol)ヘッダ、ＲＴＰ(Real-time Transport Protocol)ヘッダ等に含まれる情報のうち、静的(static)なフィールドを省略したり、動的(dynamic)なフィールド中でも該当通信において変化し得ないフィールドを省略したりすること等により、ヘッダの圧縮を行う。【０００３】
図１は、ＲｏＨＣの状態遷移図を示す。ＲｏＨＣの状態には、ＩＲ（Initialization and Refresh）状態、ＦＯ（First Order）状態、ＳＯ（Second Order）状態の３つの状態が存在する。ＩＲ状態が最も低圧縮で、ＦＯ状態、ＳＯ状態になるほど高圧縮となる。【０００４】
図２は、一例として、（Ａ）ＩＰｖ４(IP version 4)ヘッダ、（Ｂ）ＩＰｖ６(IP version 6)ヘッダ、（Ｃ）ＵＤＰヘッダ、及び、（Ｄ）ＲＴＰヘッダの静的フィールド（Static part）及び動的フィールド（Dynamic part）の分類を示す。【０００５】
ＩＲ状態では、圧縮はほとんど行われず、端末は、静的情報及び動的情報を全て送信する。ＦＯ状態では、端末は、静的フィールドを圧縮し、動的フィールドを圧縮せずに送信する。ＳＯ状態では、端末は、動的フィールドでも該当通信でほとんど変化しないフィールド、又は他のフィールドの情報から再現できるフィールド情報を見極め、最低限のフィールドのみを簡略化した形で送信する。【０００６】
通信開始時にはＩＲ状態から始まり、送信側の判断又は受信側からのフィードバック情報により、ＦＯ状態又はＳＯ状態へと高圧縮モードに遷移する。ＦＯ状態からＳＯ状態に遷移する場合も同様である。反対に、例えば、圧縮期限のタイマが期限切れになった場合、又は、受信側からのフィードバック情報又は圧縮したフィールドに変化が生じた場合等にはＳＯ状態からＦＯ状態又はＩＲ状態、又はＦＯ状態からＩＲ状態へと低圧縮モードに遷移する。【０００７】
非特許文献２に記載の通り、低圧縮モードにはＩＲ及びＩＲ−ＤＹＮがあり、高圧縮モードにはＵＯ−０、Ｒ−０、Ｒ−０−ＣＲＣ、Ｒ−１、Ｒ−１−ＩＤ、Ｒ−１−ＴＳ、ＵＯ−１、ＵＯ−１−ＩＤ、ＵＯ−１−ＴＳ、ＵＯＲ−２、ＵＯＲ−２−ＩＤ、ＵＯＲ−２−ＴＳ等があり、高圧縮モードの中には拡張フィールドとして、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダの特定のフィールドを付加できるモードもある。【０００８】
ＬＴＥを用いた通信において、の圧縮モード（高圧縮モードと呼ぶこともある）が、例えばＶｏＬＴＥ(Voice over LTE)等で使われている。ＶｏＬＴＥでは、有音区間ではＲＴＰシーケンス番号及びＵＤＰチェックサム（ＩＰｖ６の場合）のみを送信することにより、ＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを最大３バイトまで圧縮する（例えば、非特許文献３を参照）。また、ＶｏＬＴＥで使用する高圧縮モードでは、ＩＰヘッダの情報を含むことを想定していない。そのため、ＶｏＬＴＥでは、ＩＰヘッダの情報に変化があった場合の圧縮モードに関しては実装依存とされている。【０００９】
また、３ＧＰＰでは、ＶｏＬＴＥ等のリアルタイム通信の際、通信路の輻輳を端末に通知し、コーデックのビットレート変更を促す技術としてＥＣＮ（Explicit Congestion Notification）がサポートされている（例えば、非特許文献４及び非特許文献５を参照）。ＥＣＮは非特許文献６に規格化されている。【００１０】
ＥＣＮでは、ＩＰヘッダを利用して輻輳通知する場合、ＩＰｖ４のＴｏＳ(Type of Service)フィールド又はＩＰｖ６のTraffic Classフィールドの最下位２ビット（以下、ＥＣＮビットと呼ぶ）を利用する。非特許文献５によると、通信を行う端末同士は、接続先の基地局がＥＣＮに対応しているか否かにかかわらず、端末がＥＣＮに対応しているか否かの情報を、ＳＤＰ(Session Description Protocol)オファー及びＳＤＰアンサーを用いて通信直前に端末間で交換し、両端末でＥＣＮを利用するか否かを折衝する。図３は、非特許文献５に記載されたＥＣＮ折衝に関するＳＤＰオファー及びＳＤＰアンサーの一例を示す。【００１１】
ＥＣＮの利用が折衝された場合、一方の端末は、ＩＰヘッダのＥＣＮビットを“01”又は“10”に設定し、ＥＣＮに対応していることを基地局に通知し、ＥＣＮに対応している基地局が輻輳送信方向の輻輳を検出した場合には、基地局は、ＩＰヘッダのＥＣＮビットを“11”に設定し、輻輳が生じていることを他方の端末へ通知する。基地局から輻輳が生じていることを通知された端末は、通信相手端末に対して、コーデックのビットレートを下げるように要求シグナリングを送信する。【００１２】
図４Ａ及び図４Ｂは、ＥＣＮを用いた輻輳通知及びビットレート変更要求の一例を示す。図４Ａは、端末４００から端末４０２へのＩＰパケット送信において、基地局４０４によってコア網４１２方向の輻輳が検出された例を示し、図４Ｂは、端末４００から端末４０２へのＩＰパケット送信において、基地局４０６によって無線アクセス網４１０方向の輻輳が検出された例を示す。【００１３】
図４Ａでは、端末４００は、ＥＣＮに対応していることを示すために、ＩＰヘッダのＥＣＮビットを“10”に設定し、端末４０２へ送信する。端末４００から端末４０２への通信路上に存在する基地局４０４は、コア網４１２側の輻輳又は無線アクセス網４０８側の上り(uplink)方向の輻輳を検出し、ＩＰヘッダのＥＣＮビットを“11”に変更し、端末４０２へ送信する。端末４０２は、ＩＰヘッダのＥＣＮビットが“11”であることを検出すると、ビットレートを下げるように要求するビットレート変更要求を端末４００へ送信する。【００１４】
また、図４Ｂでは、端末４００は、ＥＣＮに対応していることを示すために、ＩＰヘッダのＥＣＮビットを“10”に設定し、端末４０２へ送信する。端末４００から端末４０２への通信路上に存在する基地局４０６は、無線アクセス網４１０側の下り(downlink)方向の輻輳を検出し、ＩＰヘッダのＥＣＮビットを“11”に変更し、端末４０２へ送信する。端末４０２は、ＩＰヘッダのＥＣＮビットが“11”であることを検出すると、ビットレートを下げるように要求するビットレート変更要求を端末４００に送信する。なお、この処理は、端末４０２から端末４００へのＩＰパケット送信においても同様である。
【先行技術文献】
【非特許文献】
【００１５】
【非特許文献１】3GPP TS 36.323 v13.2.1, “Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification”
【非特許文献２】IETF RFC 3095, “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed”, C. Bormann, Editor
【非特許文献３】3GPP R2-084764, “LS on considerations on transport block sizes for VoIP”
【非特許文献４】3GPP TS 36.300 v13.4.0, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2”
【非特許文献５】3GPP TS 26.114 v14.0.0, “IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction”
【非特許文献６】IETF RFC 3168, “The Addition of Explicit Congestion Notification (ECN) to IP”, K. Ramakrishnan, S. Floyd and D. Black
【非特許文献７】3GPP TS 36.331 v13.2.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification”
【非特許文献８】3GPP TS 36.321 v13.2.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification”
【非特許文献９】3GPP TS 23.401 v14.0.0, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”
【非特許文献１０】3GPP TR 26.980 v13.0.0, “Media handling aspects of multi-stream multiparty conferencing for Multimedia Telephony Service for IMS (MTSI)”
【非特許文献１１】3GPP TR 23.799 v0.6.0, “Study on Architecture for Next Generation System”
【発明の概要】
【００１６】
上述したように、ＶｏＬＴＥの高圧縮モードではＩＰヘッダを含むことが想定されていない。一方で、ＥＣＮでは、ＩＰヘッダを用いて輻輳の通知を行う。よって、ＥＣＮをサポートする環境において高圧縮モードを適用することは困難である。
【００１７】
本開示の非限定的な実施例は、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することができる端末、基地局及び通信方法を提供することである。
【００１８】
本開示の一態様に係る端末は、通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得する取得部と、自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝する折衝部と、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
【００１９】
本開示の一態様に係る基地局は、自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
【００２０】
本開示の一態様に係る通信方法は、端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する。
【００２１】
本開示の一態様に係る通信方法は、基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する。
【００２２】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【００２３】
本開示の一態様によれば、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することができる。
【００２４】
本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【００２５】
【図１】図１は、ＲｏＨＣの状態遷移とヘッダ圧縮率の関係を示す図である。
【図２】図２は、ＲｏＨＣで用いる、ＩＰｖ４、ＩＰｖ６、ＵＤＰ及びＲＴＰヘッダの、静的部分と動的部分を示す図である。
【図３】図３は、ＳＤＰオファー及びＳＤＰアンサーでＥＣＮ折衝を行う一例を示す図である。
【図４Ａ】図４Ａは、ＥＣＮを用いた輻輳制御の一例を示す図である。
【図４Ｂ】図４Ｂは、ＥＣＮを用いた輻輳制御の一例を示す図である。
【図５】図５は、本開示の一実施の形態に係る端末の構成例を示すブロック図である。
【図６】図６は、本開示の一実施の形態に係る基地局の構成例を示すブロック図である。
【図７Ａ】図７Ａは、本開示の一実施の形態に係るアプリケーション対応情報の通知方法の一例を示す図である。
【図７Ｂ】図７Ｂは、本開示の一実施の形態に係るアプリケーション対応情報の通知方法の一例を示す図である。
【図８Ａ】図８Ａは、本開示の一実施の形態に係る利用アプリケーション情報の通知方法の一例を示す図である。
【図８Ｂ】図８Ｂは、本開示の一実施の形態に係る利用アプリケーション情報の通知方法の一例を示す図である。
【図９】図９は、本開示の一実施の形態に係るＥＣＮに対する高圧縮モードの一例を示す図である。
【図１０Ａ】図１０Ａは、本開示の一実施の形態に係るハンドオーバ時の利用アプリケーションの制御方法の一例を示す図である。
【図１０Ｂ】図１０Ｂは、本開示の一実施の形態に係るハンドオーバ時の利用アプリケーションの制御方法の一例を示す図である。
【図１１】図１１は、本開示の他の実施の形態に係るＭＭＣＭＨに対する高圧縮モードの一例を示す図である。
【発明を実施するための形態】
【００２６】
［本開示の一態様に至る経緯］
ＥＣＮを用いた輻輳通知を行う端末間の通信経路上に存在する複数の基地局の中にＥＣＮに対応していない基地局が含まれる場合も想定される。例えば、図４Ａの例において、基地局４０６（又は基地局４０４の場合もある）がＥＣＮに対応していない場合、基地局４０６は、ＩＰヘッダに生じる変化（ＥＣＮビットの変更）の理由が分からない。このため、基地局４０６は、ＩＰヘッダを省略するような高圧縮モードを適用してＩＰヘッダ内のＥＣＮビットを送信しない可能性がある。または、基地局４０６は、ＥＣＮを用いた輻輳通知に関係無く、ＲｏＨＣの圧縮モードをＩＲ又はＩＲ−ＤＹＮ等の低圧縮モードに変更して送信する可能性もある。
【００２７】
また、ＥＣＮを用いた場合の圧縮モードに関する仕様上の規定はなく実装依存である。よって、ＥＣＮを用いた輻輳通知を行う端末間の通信経路上に存在する基地局がＥＣＮに対応していても、実装によっては、基地局は、ＥＣＮを用いた輻輳通知の際にＩＲ又はＩＲ−ＤＹＮ等の低圧縮モードに変更する可能性もあり得る。
【００２８】
このように、ＥＣＮを用いた輻輳通知を行う際、ＥＣＮによる輻輳が正常に通知されなかったり、低圧縮モードに変更されたりして、輻輳通知が頻繁に発生することにより、無線リソースを無駄に消費してしまう。
【００２９】
そこで、本開示の一態様では、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することを目的とする。これにより、輻輳通知が頻繁に発生することを防ぎ、無線リソースの無駄な消費を抑えることができる。
【００３０】
以下、本開示の実施の形態について、図４〜図１１を参照して詳細に説明する。
【００３１】
以下では、一例として、図４に示すように、端末４００，４０２、基地局４０４，４０６を含み、端末４００と端末４０２との間で通信を行う通信システムについて説明する。
【００３２】
［端末の構成］
図５は、本実施の形態に係る端末４００，４０２の構成を示すブロック図である。なお、図５では、本開示と密接に関連する構成部のみを示し、端末の従来の機能等は省略している。
【００３３】
図５に示す端末４００，４０２において、無線受信部５００は、基地局４０４，４０６等から送信されるシグナリング又はデータを受信し、受信したシグナリング又はデータを、端末４００，４０２の対応する構成部へ出力する。無線送信部５０１は、各構成部から入力されるシグナリング又はデータを基地局４０４，４０６等へ送信する。
【００３４】
アプリケーション対応情報取得部５０２は、基地局４０４、４０６が対応しているアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を取得する。例えば、基地局４０４，４０６がＥＣＮに対応する場合、アプリケーション対応情報にはＥＣＮが含まれる。
【００３５】
アプリケーション対応情報通知部５０３は、基地局４０４，４０６に対して、自機（端末４００，４０２）が対応しているアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を通知する。例えば、アプリケーション対応情報通知部５０３は、自機（端末４００，４０２）が対応するアプリケーション（又はアプリケーションに関する機能）のうち、基地局４０４，４０６のアプリケーション対応情報に示されるアプリケーション（又はアプリケーションに関連する機能）と一致するアプリケーションを、端末４００，４０２のアプリケーション対応情報として、基地局４０４，４０６へ通知する。
【００３６】
利用アプリケーション折衝部５０４は、アプリケーション対応情報取得部５０２が取得した、基地局４０４，４０６のアプリケーション対応情報に基づいて、通信で利用するアプリケーション及びアプリケーションに関する機能を通信相手端末との間で折衝する。具体的には、利用アプリケーション折衝部５０４は、自機が対応するアプリケーションのうち、基地局４０４，４０６から取得したアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を通信相手端末と折衝する。例えば、利用アプリケーション折衝部５０４は、基地局４０４，４０６がＥＣＮに対応する場合にはＥＣＮを利用するか否かを折衝する一方、基地局４０４，４０６がＥＣＮに対応しない場合にはＥＣＮを利用するか否かを折衝しない。
【００３７】
利用アプリケーション情報通知部５０５は、利用アプリケーション折衝部５０４によって折衝して決定された、端末４００，４０２が通信で利用するアプリケーション又はアプリケーションに関する機能（以下、単に「利用アプリケーション」と呼ぶこともある）を示す利用アプリケーション情報を基地局４０４、４０６に通知する。
【００３８】
圧縮モード決定部５０６は、利用アプリケーション折衝部５０４で折衝された利用アプリケーションに基づいてヘッダ圧縮モードを決定する。例えば、圧縮モード決定部５０６は、利用アプリケーションがＥＣＮの場合、ＥＣＮに適した圧縮モードを決定してもよい。例えば、ＥＣＮに適した圧縮モードとしては、ＥＣＮビットを通知するフィールドを含む圧縮率が最も高いモード等が挙げられる。
【００３９】
利用アプリケーション制御部５０７は、例えば、ハンドオーバを行う際に、ハンドオーバ先の基地局４０４，４０６が対応するアプリケーションに基づいて、利用中のアプリケーションの停止又は継続を決定する。また、利用アプリケーション制御部５０７は、アプリケーションを停止した後、停止中のアプリケーションに対応する基地局４０４，４０６へ再びハンドオーバする場合、当該アプリケーションの利用の再開を決定する。そして、利用アプリケーション制御部５０７は、利用アプリケーションの停止又は再開を決定した場合、通信相手端末との間で利用アプリケーションの停止又は再開に関する折衝を行う。また、利用アプリケーション制御部５０７は、折衝して決定した内容（停止又は再開等）を示す利用アプリケーション制御情報を基地局４０４，４０６に通知する。
【００４０】
［基地局の構成］
図６は、本実施の形態に係る基地局４０４，４０６の構成を示すブロック図である。なお、図６では、本開示と密接に関連する構成部のみを示し、基地局の従来の機能等は省略している。
【００４１】
図６に示す基地局４０４，４０６において、受信部６００は、端末４００，４０２又はコア網４１２から送信されるシグナリング又はデータを受信し、受信したシグナリング又はデータを、基地局４０４，４０６の対応する構成部へ出力する。送信部６０１は、各構成部から入力されるシグナリング又はデータを、端末４００，４０２又はコア網４１２へ送信する。
【００４２】
アプリケーション対応情報通知部６０２は、自機（基地局４０４、４０６）が対応するアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を端末４００、４０２に通知する。
【００４３】
アプリケーション対応情報取得部６０３は、端末４００、４０２が対応しているアプリケーション及びアプリケーションに関連する機能を示すアプリケーション対応情報を取得する。例えば、端末４００，４０２のアプリケーション対応情報には、端末４００，４０２が対応するアプリケーション（又はアプリケーションに関する機能）のうち、基地局４０４，４０６が対応するアプリケーション（又はアプリケーションに関する機能）と一致するアプリケーションが含まれる。
【００４４】
利用アプリケーション情報取得部６０４は、端末４００，４０２において通信相手端末との間で折衝して決定された、端末４００，４０２が通信で利用するアプリケーション（利用アプリケーション）を示す利用アプリケーション情報を、端末４００、４０２から取得する。
【００４５】
圧縮モード決定部６０５は、利用アプリケーション情報取得部６０４が取得した利用アプリケーション情報に示される利用アプリケーションに基づいてヘッダ圧縮モードを決定する。
【００４６】
利用アプリケーション制御情報取得部６０６は、端末４００、４０２が決定・折衝した内容（利用アプリケーションの停止又は再開）を示す利用アプリケーション制御情報を取得する。そして、利用アプリケーション制御情報取得部６０６は、取得した利用アプリケーション制御情報に基づいて、端末４００，４０２が利用するアプリケーションの機能を制御（停止又は再開等）する。
【００４７】
［アプリケーション対応情報の通知方法］
図７Ａ及び図７Ｂは、基地局４０４，４０６のアプリケーション対応情報及び端末４００，４０２のアプリケーション対応情報を通知する方法の一例を示す。
【００４８】
図７Ａ及び図７Ｂに示す動作は、例えば、端末４００，４０２によるアプリケーション利用の折衝前に行われる。
【００４９】
図７Ａは、非特許文献７に記載のRRC (Radio Resource Control) connection establishmentに係るシグナリングメッセージを用いる。
【００５０】
具体的には、RRC connection establishmentの際、基地局４０４、４０６のアプリケーション対応情報通知部６０２は、ＥＣＮ等の基地局４０４，４０６が対応しているアプリケーションを示すアプリケーション対応情報をRRCConnectionSetupシグナリングに含めて、送信部６０１を介して端末４００、４０２へ通知する。
【００５１】
なお、このアプリケーション対応情報の中には、基地局４０４，４０６が対応するアプリケーションに適したヘッダ圧縮に対応しているか否か、また、対応している場合にはどのヘッダ圧縮モードを使用するか等の情報が含まれていてもよい。
【００５２】
一方、端末４００、４０２では、無線受信部５００が基地局４０４、４０６から通知されるRRCConnectionSetupシグナリングを受信すると、アプリケーション対応情報取得部５０２は、RRCConnectionSetupシグナリングを解析する。そして、アプリケーション対応情報取得部５０２は、基地局４０４、４０６のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報と、自機（端末４００、４０２）が対応するアプリケーションとを比較して、一致するアプリケーションを示す、端末４００，４０２のアプリケーション対応情報を生成する。そして、端末４００、４０２のアプリケーション対応情報通知部５０３は、端末４００，４０２のアプリケーション対応情報をRRCConnectionSetupCompleteシグナリングに含めて、無線送信部５０１を介して基地局４０４、４０６へ通知する。
【００５３】
基地局４０４、４０６では、受信部６００が端末４００、４０２から送信されるRRCConnectionSetupCompleteシグナリングを受信すると、アプリケーション対応情報取得部６０３はRRCConnectionSetupCompleteシグナリングを解析し、端末４００、４０２のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報を取得する。
【００５４】
図７Ｂは、非特許文献７に記載のSystem information acquisition、及びUE capability transferに係るシグナリングメッセージを用いる。
【００５５】
具体的には、基地局４０４、４０６のアプリケーション対応情報通知部６０２は、ＥＣＮ等の基地局４０４，４０６が対応しているアプリケーションを示すアプリケーション対応情報をSystemInformationBlock（ＳＩＢ）シグナリングに含めて、送信部６０１を介して端末４００、４０２へ通知する。
【００５６】
なお、このアプリケーション対応情報の中には、基地局４０４，４０６が対応するアプリケーションに適したヘッダ圧縮に対応しているか否か、また、対応している場合にはどのヘッダ圧縮モードを使用するか等の情報が含まれていてもよい。
【００５７】
一方、端末４００、４０２では、無線受信部５００が基地局４０４、４０６から通知されるSystemInformationBlockシグナリングを受信すると、アプリケーション対応情報取得部５０２は、SystemInformationBlockシグナリングを解析する。そして、アプリケーション対応情報取得部５０２は、基地局４０４、４０６のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報と、自機（端末４００、４０２）が対応するアプリケーションとを比較して、一致するアプリケーションを示す、端末４００，４０２のアプリケーション対応情報を生成する。
【００５８】
その後、基地局４０４、４０６のアプリケーション対応情報取得部６０３は、端末４００、４０２のアプリケーション対応情報の提供を要求するためのアプリケーション対応情報要求をUECapabilityEnquiryシグナリングに含めて、送信部６０１を介して端末４００、４０２へ通知する。
【００５９】
端末４００、４０２では、無線受信部５００が基地局４０４、４０６から送信されたUECapabilityEnquiryシグナリング（アプリケーション対応情報要求）を受信すると、アプリケーション対応情報通知部５０３は、アプリケーション対応情報取得部５０２で生成された端末４００，４０２のアプリケーション対応情報をUECapabilityInformationシグナリングに含めて、無線送信部５０１を介して基地局４０４、４０６へ通知する。
【００６０】
基地局４０４、４０６では、受信部６００が端末４００、４０２から送信されるUECapabilityInformationシグナリングを受信すると、アプリケーション対応情報取得部６０３はUECapabilityInformationシグナリングを解析し、端末４００，４０２のアプリケーション対応情報が含まれている場合、当該アプリケーション対応情報を取得する。
【００６１】
このようにして端末４００，４０２のアプリケーション対応情報を基地局４０４，４０６へ通知することにより、基地局４０４，４０６は、端末４００，４０２が利用可能なアプリケーションを特定することができる。
【００６２】
なお、図７Ａ及び図７Ｂに示す例では、端末４００、４０２が通信開始前に、基地局４０４、４０６のアプリケーション対応情報、及び、端末４００、４０２のアプリケーション対応情報を通知する方法として、非特許文献７に記載のシグナリングを用いる方法を一例として示した。しかし、アプリケーション対応情報の通知に用いられるシグナリングは、これらに限定されず、例えば、非特許文献８に記載のＭＡＣ  ＣＥ（MAC Control Element）等を用いてもよい。
【００６３】
［利用アプリケーションの折衝方法］
次に、端末４００，４０２におけるアプリケーション利用のための通信相手端末との折衝について説明する。
【００６４】
端末４００、４０２がアプリケーションを用いた通信、例えばＶｏＬＴＥ等を開始する際、利用アプリケーション折衝部５０４は、アプリケーション対応情報取得部５０２が取得した、基地局４０４、４０６のアプリケーション対応情報に基づいてＳＤＰオファーを作成する。
【００６５】
例えば、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれている場合、利用アプリケーション折衝部５０４は、自機がＥＣＮに対応していれば、ＥＣＮをＳＤＰオファーに含めてもよい（例えば、図３を参照）。一方、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれていない場合、利用アプリケーション折衝部５０４は、たとえ自機がＥＣＮに対応している場合でも、ＥＣＮをＳＤＰオファーに含めない。つまり、利用アプリケーション折衝部５０４は、基地局４０４，４０６及び自機の双方がＥＣＮに対応している場合のみ、ＥＣＮを含むＳＤＰオファーを作成する。
【００６６】
利用アプリケーション折衝部５０４が作成したＳＤＰオファーは、無線送信部５００を介して通信相手の端末４００、４０２へ送信される。
【００６７】
一方、無線受信部５０１でＳＤＰオファーを受け取った端末４００、４０２の利用アプリケーション折衝部５０４は、アプリケーション対応情報取得部５０２が取得した、基地局４０４、４０６のアプリケーション対応情報に基づいてＳＤＰアンサーを作成する。
【００６８】
例えば、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれており、かつ、ＳＤＰオファーにＥＣＮが含まれている場合、利用アプリケーション折衝部５０４は、自機がＥＣＮに対応していれば、ＥＣＮをＳＤＰアンサーに含める（例えば、図３を参照）。一方、基地局４０４，４０６のアプリケーション対応情報の中にＥＣＮが含まれていない場合、利用アプリケーション折衝部５０４は、たとえＳＤＰオファーにＥＣＮが含まれており、かつ自機がＥＣＮに対応している場合でも、ＥＣＮをＳＤＰアンサーには含めない。つまり、利用アプリケーション折衝部５０４は、基地局４０４，４０６及び自機の双方がＥＣＮに対応し、かつ、ＳＤＰオファーにＥＣＮが含まれている場合のみ、ＥＣＮを含むＳＤＰアンサーを作成する。
【００６９】
利用アプリケーション折衝部５０４が作成したＳＤＰアンサーは、無線送信部５０１を介して通信相手の端末４００、４０２へ送信される。
【００７０】
このようにして、通信を行う双方の端末４００，４０２がＥＣＮに対応し、かつ、端末４００，４０２の通信経路上に存在する基地局４０４，４０６がＥＣＮに対応しているときに、折衝によってＥＣＮの利用が決定される。換言すると、通信を行う双方の端末４００，４０２でＥＣＮの利用が可能であっても、通信経路上に存在する基地局４０４，４０６がＥＣＮに対応していない場合には、端末４００，４０２間においてＥＣＮ利用の折衝は行われない。これにより、ＥＣＮが利用される場合は、端末４００，４０２間の通信経路上に存在する基地局４０４，４０６もＥＣＮに対応しているので、ＥＣＮによって輻輳を正常に通知することができる。
【００７１】
［利用アプリケーション情報の通知方法］
次に、端末４００，４０２間でＳＤＰオファー及びＳＤＰアンサーを用いた折衝によって決定された利用アプリケーションを示す利用アプリケーション情報の通知方法について説明する。
【００７２】
図８Ａ及び図８Ｂは、利用アプリケーション情報を端末４００，４０２から基地局４０４，４０６に通知する方法の一例を示す。
【００７３】
図８Ａでは、非特許文献７に記載のRRC connection reconfigurationに係るシグナリングメッセージを用いる。
【００７４】
具体的には、端末４００、４０２では、無線受信部５００が、アプリケーションを用いた通信のデータ送受信用無線ベアラ(radio bearer)を設定するために、基地局４０４、４０６より送信されるRRCConnectionReconfigurationシグナリングを受信する。RRCConnectionReconfigurationシグナリングを受信すると、利用アプリケーション情報通知部５０５は、利用アプリケーション折衝部５０４で折衝して決定された利用アプリケーション情報の全て又は一部（例えばＥＣＮ利用等）を、RRCConnectionReconfigurationCompleteシグナリングに含めて、無線送信部５０１を介して基地局４０４、４０６へ通知する。
【００７５】
端末４００、４０２が基地局４０４、４０６よりRRCConnectionReconfigurationシグナリングを受信した時点で、利用アプリケーション折衝部５０４における利用アプリケーションの折衝が完了していない場合、利用アプリケーション情報通知部５０５は、折衝の完了を待ってRRCConnectionReconfigurationCompleteシグナリングを送信する。
【００７６】
基地局４０４、４０６では、受信部６００が端末４００、４０２から送信されるRRCConnectionReconfigurationCompleteシグナリングを受信すると、利用アプリケーション情報取得部６０４は、RRCConnectionReconfigurationCompleteシグナリングを解析し、利用アプリケーション情報が含まれている場合、当該利用アプリケーション情報を取得する。
【００７７】
図８Ｂでは、非特許文献９に記載のDedicated bearer activationに係るシグナリングメッセージを用いる。
【００７８】
まず、ＬＴＥのアプリケーションシグナリング網であるＩＭＳ(IP Multimedia Subsystem)において、ＳＤＰオファー及びＳＤＰアンサーで折衝された情報を取得可能なネットワークノードであるＰ−ＣＳＣＦ(Proxy-Call Session Control Function)が、アプリケーションを用いた通信を行う端末４００、４０２間で折衝された利用アプリケーションを示す利用アプリケーション情報を取得する。
【００７９】
そして、Ｐ−ＣＳＣＦは、利用アプリケーション情報の全て又は一部（例えばＥＣＮ利用等）を、ＬＴＥのコア網４１２上のネットワークノードであるＰＣＲＦ(Policy and Charging Rules Function)に通知する。また、ＰＣＲＦは、利用アプリケーション情報を、ＬＴＥのコア網４１２上のネットワークノードであるＰ−ＧＷ(Packet Data Network GateWay)に通知する。利用アプリケーション情報の全て又は一部を受け取ったＰ−ＧＷは、利用アプリケーション情報を、アプリケーションを用いた通信のデータ送受信用ベアラを設定するための、Dedicated Bearer Establishment処理のシグナリングに含めて送信する。
【００８０】
基地局４０４、４０６では、受信部６００がDedicated Bearer Establishment処理のシグナリングを受信すると、利用アプリケーション情報取得部６０４は、Dedicated Bearer Establishment処理のシグナリングを解析し、利用アプリケーション情報が含まれている場合、当該利用アプリケーション情報を取得する。
【００８１】
このようにして、端末４００，４０２において基地局４０４，４０６のアプリケーション対応情報に基づき通信相手端末との間で折衝されたアプリケーションを示す利用アプリケーション情報は基地局４０４，４０６へ通知される。これにより、基地局４０４，４０６は、例えば、端末４００，４０２において、基地局４０４，４０６が対応するアプリケーションに基づいて折衝が正常に行われたこと確認することができる。また、基地局４０４，４０６は、端末４００，４０２が利用するアプリケーションに基づいてヘッダ圧縮モードを変更することができる（詳細は後述する）。
【００８２】
なお、端末４００，４０２は、図８ＢのようにDedicated Bearer Establishment処理のシグナリングに利用アプリケーション情報を含める代わりに、利用アプリケーションに応じたＱＣＩ(QoS Class Identifier)を設定し、設定したＱＣＩを通知することにより、利用アプリケーションを通知してもよい。例えば、非特許文献９等に記載の通り、ＶｏＬＴＥのデータ送受信用ベアラのＱＣＩは“１”である。これに対して、ＥＣＮを用いたＶｏＬＴＥ用に新たにＱＣＩを“１．１”と定義し、端末４００，４０２は、“QCI=1.1”をDedicated Bearer Establishment処理のシグナリングに含めて送信してもよい。
【００８３】
また、図８Ａ及び図８Ｂでは、基地局４０４、４０６が利用アプリケーション情報を取得するためにRRC connection reconfigurationに係るシグナリング、又は、Dedicated Bearer Establishmentのシグナリングを用いる方法を一例として示したが、利用アプリケーション情報の通知方法はこれらに限定されない。例えば、基地局４０４，４０６（利用アプリケーション情報取得部６０４）は、通信を開始した端末４００、４０２が送信するＩＰパケットの中にＥＣＮに対応する情報（ＩＰヘッダのＥＣＮビットが”01”または”10”）が含まれることにより、利用アプリケーションの中にＥＣＮが含まれることを特定してもよい。つまり、利用アプリケーション情報取得部６０４は、ＥＣＮビットの内容を特定することにより、ＥＣＮを含む利用アプリケーション情報を暗黙的に取得する。この場合、利用アプリケーション情報の通知のための図８Ａ及び図８Ｂに示すようなシグナリングは不要となる。
【００８４】
［圧縮モード決定方法］
次に、端末４００，４０２の圧縮モード決定部５０６、及び、基地局４０４，４０６の圧縮モード決定部６０５におけるヘッダ圧縮モードの決定方法について説明する。
【００８５】
圧縮モード決定部５０６及び圧縮モード決定部６０５は、利用アプリケーション情報（つまり、端末４００，４０２間のアプリケーションの折衝結果）に基づいて、利用アプリケーションに適したヘッダ圧縮モードを決定する。
【００８６】
なお、前述の通り、基地局４０４、４０６から端末４００、４０２へ通知されたアプリケーション対応情報にどのヘッダ圧縮モードを使用するかを示す情報が含まれている場合、圧縮モード決定部５０６及び圧縮モード決定部６０５は、アプリケーション対応情報に含まれるヘッダ圧縮モードに従って適用する圧縮モードを決定する。
【００８７】
図９は、利用アプリケーションとしてＶｏＬＴＥでのＥＣＮを利用する際のＲｏＨＣの高圧縮モードの一例を示す。
【００８８】
前述の通り、ＶｏＬＴＥにおいて、有音区間ではＲＴＰシーケンス番号及びＵＤＰチェックサム（ＩＰｖ６の場合）のみが送信され、ＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを最大３バイトまで圧縮することが想定されている。
【００８９】
一方で、ＥＣＮは、ＩＰヘッダのＴｏＳフィールド（ＩＰｖ４の場合）又はTraffic Classフィールド（ＩＰｖ６の場合）の下位２ビットを利用する。
【００９０】
したがって、ＥＣＮ利用に適したＲｏＨＣの高圧縮モードとしては、ＴｏＳフィールド又はTraffic Classフィールドのみを含むことができる高圧縮モードを用いればよい。
【００９１】
例えば、非特許文献２によると、高圧縮モードに拡張フラグ（X）を立てて、IPヘッダ拡張部を用意し、このIPヘッダ拡張部に特定のフィールド（ＴｏＳフィールド又はTraffic Classフィールド）を含めることができる。
【００９２】
そこで、圧縮モード決定部５０６及び圧縮モード決定部６０５は、高圧縮モードの中で、拡張フラグに対応しているモードを選択すればよい。図９の例では、拡張フラグ（X）に対応している高圧縮モードであるＵＯＲ−２モードに拡張フラグを立て（X=1）、ＩＰヘッダ拡張部（ip=1に対応するフィールド）を用意し、IPヘッダ拡張部にTraffic Classフィールドを付け加えている。
【００９３】
これにより、端末４００，４０２は、基地局４０４，４０６が対応するアプリケーションを考慮して決定されたアプリケーションに適した圧縮モードを決定することができる。また、基地局４０４，４０６は、端末４００，４０２において折衝により決定されたアプリケーションに適したヘッダ圧縮モードを決定することができる。例えば、基地局４０４，４０６は、端末４００，４０２がＥＣＮを利用する場合には、ＥＣＮを用いた輻輳通知に対応するようなＲｏＨＣの圧縮モードを適切に決定することができる。
【００９４】
なお、ＥＣＮ利用に適したＲｏＨＣの高圧縮モードは、ＵＯＲ−２モードに限定されず、ＥＣＮビットの送信に用いられるフィールド（例えば、ＴｏＳフィールド又はTraffic Classフィールド）を含むことができる高圧縮モードであればよい。例えば、圧縮モード決定部５０６及び圧縮モード決定部６０５は、ＴｏＳフィールド又はTraffic Classフィールドを含むことができる高圧縮モードの中で、圧縮率が最も高いモードを選択してもよい。
【００９５】
［ハンドオーバ時の利用アプリケーションの制御］
次に、端末４００，４０２が接続中の基地局４０４，４０６から他の基地局４０４，４０６配下にハンドオーバする場合について説明する。
【００９６】
図１０Ａ及び図１０Ｂは、端末４００、４０２が他の基地局４０４、４０６配下にハンドオーバする場合の端末４００，４０２の利用アプリケーションに対する制御に関する処理を示す。
【００９７】
まず、端末４００、４０２の利用アプリケーション制御部５０７は、ハンドオーバ先基地局４０４、４０６(例えば、target eNodeBと呼ばれる)のアプリケーション対応情報に基づいて、ハンドオーバ先基地局４０４，４０６が、端末４００，４０２が現在利用中のアプリケーションに対応しているか否かを示す情報を得る。
【００９８】
この情報は、ハンドオーバ元基地局４０４、４０６(例えば、serving eNodeBと呼ばれる)からハンドオーバ直前に送信されるRRCConnectionReconfigurationの情報に含まれてもよく、ハンドオーバ先基地局４０４、４０６から送られるSystemInformationBlock又はＭＡＣ  ＣＥの中に含まれてもよい。または、利用アプリケーション制御部５０７は、ハンドオーバ先基地局４０４、４０６が利用するヘッダ圧縮モードが、端末４００、４０２が利用中のアプリケーションに対応しているか否かをすることにより、ハンドオーバ先基地局４０４，４０６が現在利用中のアプリケーションに対応しているか否かを暗黙的に判断してもよい。
【００９９】
ハンドオーバ元基地局４０４、４０６が端末４００，４０２の利用アプリケーションに対応しており、ハンドオーバ先基地局４０４、４０６も端末４００，４０２の利用アプリケーションに対応していることを検出した場合（図１０Ｂのステップ（ＳＴ）２０１）、端末４００，４０２は、利用アプリケーションを継続して利用すると判断する（図１０ＢのＳＴ２０２）。
【０１００】
一方、ハンドオーバ元基地局４０４、４０６が端末４００，４０２の利用アプリケーションに対応しているが、ハンドオーバ先基地局４０４、４０６が端末４００，４０２の利用アプリケーションに対応していないことを検出した場合（図１０ＡのＳＴ１０１）、端末４００、４０２は、利用アプリケーション又はアプリケーション機能の一部（例えばＥＣＮ等）の利用を停止すると判断する（図１０ＡのＳＴ１０２）。そして、端末４００，４０２は、利用アプリケーションの機能を停止することを示す利用アプリケーション制御情報を通信相手端末へ通知する（図１０ＡのＳＴ１０３）。通信相手端末は、利用アプリケーションの機能を停止することを示す利用アプリケーション制御情報を受け取ると、ＥＣＮの利用を停止する。
【０１０１】
なお、利用アプリケーション機能停止の通知方法として、例えば、ＥＣＮの利用を停止する場合、端末４００，４０２は、これまで使用していたＥＣＮビットを、ＥＣＮ非対応を示す“00”に設定して送信してもよい。ＥＣＮビットが“00”であるＩＰパケットを受け取った通信相手の端末４００，４０２の利用アプリケーション制御部５０７、及び、通信相手側の基地局４０４，４０６の利用アプリケーション制御情報取得部６０６は、ＥＣＮの利用を停止する。
【０１０２】
また、端末４００、４０２の利用アプリケーション制御部５０７は、ＥＣＮビットを”00”として送信する前に、通信相手の端末４００、４０２に対してＳＤＰオファーを再度送信し、ＳＤＰオファー及びＳＤＰアンサーによってＥＣＮの停止を折衝してもよい。
【０１０３】
次に、端末４００，４０２の利用アプリケーションの全て又は一部（例えば、ＥＣＮ等）が一度停止した状態で、端末４００，４０２が再びハンドオーバし、ハンドオーバ先基地局４０４，４０６が当該利用アプリケーションに対応していると判断した場合の動作について説明する。
【０１０４】
この場合、端末４００，４０２は、ハンドオーバ先基地局４０４、４０６において停止中の利用アプリケーションを再開すると判断する（図１０ＢのＳＴ２０２）。
【０１０５】
そして、端末４００，４０２は、通信開始時に利用していたアプリケーションを再開することを通信相手の端末４００，４０２に照会する（図１０ＢのＳＴ２０３）。照会方法としては、例えば、ＥＣＮの場合、端末４００，４０２は、ＥＣＮビットを、ＥＮＣ対応を示す“01”又は“10”に設定して送信してもよい。ＥＣＮビットが“01”又は“10”であるＩＰパケットを受け取った通信相手の端末４００、４０２の利用アプリケーション制御部５０７は、ＥＣＮの再開を行っても問題無い場合、ＥＣＮビットを、ＥＣＮ対応を示す“01”又は“10”に設定してＩＰパケットを送り返す。
【０１０６】
なお、ＥＣＮの再開を行っても問題無い場合とは、すなわち、ＥＣＮビットが“01”又は“10”となったＩＰパケットを受け取った通信相手の端末４００、４０２側で現在接続している基地局４０４、４０６もＥＣＮに対応している場合である。
【０１０７】
一方、ＥＣＮビットが“01”又は“10”となったＩＰパケットを受け取った通信相手の端末４００、４０２側で現在接続している基地局４０４、４０６がＥＣＮに対応していない場合、すなわち、ＥＣＮの再開を行うと問題が生じる場合、通信相手の端末４００，４０２の利用アプリケーション制御部５０７は、ＥＣＮビットを、非対応を示す”00”に設定してＩＰパケットを送り返す。
【０１０８】
なお、ＥＣＮの再開が端末４００、４０２間で折衝された場合、基地局４０４、４０６の利用アプリケーション制御情報取得部６０６は、ＥＣＮビットが“01”又は“10”であるＩＰパケットを受け取ることにより、ＥＣＮの再開情報を取得する。これにより、基地局４０４，４０６は、停止したＥＣＮの機能を再開する。
【０１０９】
また、端末４００、４０２の利用アプリケーション制御部５０７は、ＥＣＮのビットを“01”又は“10”として送信する前に、通信相手の端末４００、４０２に対してＳＤＰオファーを再度送信し、ＳＤＰオファー及びＳＤＰアンサーによってＥＣＮの再開を折衝してもよい。
【０１１０】
このようにして、端末４００，４０２は、ハンドオーバ先基地局４０４，４０６が対応するアプリケーションに基づいて、利用するアプリケーションの継続、停止又は再開を制御する。これにより、端末４００，４０２は、ハンドオーバの度にＳＤＰオファー及びＳＤＰアンサーを用いることなく、通信相手端末との間で確立されたデータパス上で当該アプリケーションの利用を折衝することができる。
【０１１１】
［本実施の形態の効果］
以上のように、本実施の形態では、端末４００，４０２は、通信相手端末との通信経路上に存在する基地局４０４，４０６が対応するアプリケーションを示すアプリケーション対応情報を取得し、自機が対応するアプリケーションのうち、基地局４０４，４０６のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を通信相手端末と折衝し、折衝されたアプリケーションに基づいてヘッダ圧縮モードを決定する。
【０１１２】
これにより、ＥＣＮを用いた輻輳通知を行う端末４００，４０２間の通信経路上に存在する基地局４０４，４０６の中にＥＣＮに対応していない基地局が含まれる場合には、端末４００，４０２間でＥＣＮの利用について折衝しない。よって、端末４００，４０２間の通信経路上に存在する基地局が、ＩＰヘッダを省略するような高圧縮モードを適用してしまい、ＩＰヘッダ内のＥＣＮビットが送信されなくなることを防ぐことができる。
【０１１３】
また、端末４００，４０２及び基地局４０４，４０６は、折衝されたアプリケーション（例えば、ＥＣＮ）に基づいてヘッダ圧縮モードを決定する。これにより、ＲｏＨＣの高圧縮モードが適用される場合でも、ＥＣＮビットの通知を考慮した高圧縮モード（例えば、図９を参照）の使用が可能となる。換言すると、ＥＣＮを用いた輻輳通知に関係無く、ＲｏＨＣの圧縮モードが低圧縮モードに変更されてしまうことを防ぐことができる。
【０１１４】
このように、本実施の形態によれば、ＥＣＮをサポートする環境において高圧縮モードを適切に適用することができる。また、高圧縮モードにおいてＥＣＮによって輻輳を正常に通知することができるので、輻輳通知が頻繁に発生することを防ぎ、無線リソースの無駄な消費を抑えることができる。
【０１１５】
［他の実施の形態］
なお、端末４００，４０２が利用するアプリケーションは、ＥＣＮに限定されず、他のアプリケーションを利用してもよい。
【０１１６】
例えば、非特許文献５及び非特許文献１０に記載のＭＭＣＭＨ（Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI：マルチストリーム対応端末)に本開示の方式を適用しても、効率的なヘッダ圧縮モードを利用することができる。図１１は、ＶｏＬＴＥでのＭＭＣＭＨ利用に適したＲｏＨＣの高圧縮モードの例を示す。ＭＭＣＭＨでは、１セッション内の複数のＶｏＬＴＥフロー（ストリーム）を区別できればよい。従って、ＭＭＣＭＨ利用時には、非特許文献２に記載のＣＩＤ(Context ID)を含むような高圧縮モードを用いればよい。例えば、基地局４０４，４０６（圧縮モード決定部６０５）は、ＣＩＤを送信するフィールドを有するヘッダ圧縮モードのうち圧縮率が最も高い圧縮モードを選択してもよい。なお、ＣＩＤを用いるにあたり、使用されるＶｏＬＴＥフロー数に従い、ＣＩＤの上限(maxCID)を、非特許文献１及び非特許文献７に記載の方法で、端末４００、４０２と基地局４０４、４０６の間で折衝してもよい。
【０１１７】
また、基地局４０４、４０６のアプリケーション対応情報通知部６０２から、サポートしているアプリケーションの情報だけでなく、無線品質の状態などにより、サポートできないアプリケーションの情報を通知しても良い。例えば、無線アクセス網４０８、４１０の混雑などにより、音声のみの通話（ＶｏＬＴＥ）に対する無線リソースを割り当てる事は可能だが、テレビ電話等のビデオに対する無線リソースを割り当てる事が難しい場合、基地局４０４，４０６は、図７Ａ又は図７Ｂに示す方法などにより、ビデオをサポートしていない事、又はビデオを一時的にサポートできない事を端末４００、４０２に通知しても良い。この通知を受け取った端末４００、４０２の利用アプリケーション折衝部５０４は、通信を開始する際、ＳＤＰオファー又はアンサーにｖｉｄｅｏに関するメディアライン(media line)を含めない事により、テレビ電話ではなく音声のみの通話を折衝する。なお、端末４００、４０２のアプリケーション対応情報取得部５０２が、基地局４０４、４０６からビデオをサポートしていない事、又はビデオを一時的にサポートできない事を取得した際、端末４００，４０２のユーザにビデオが使えない事を通知するため、画面などにビデオが使えない事を示す情報を表示しても良い。また、通信開始時にはテレビ電話を利用していたが、ハンドオーバ先の基地局４０４，４０６でビデオをサポートしていない、又はビデオを一時的にサポートできないとなった場合、端末４００、４０２の利用アプリケーション制御部５０７は、非特許文献９に記載の、UE requested bearer resource modificationなどを用いて、ビデオ用ベアラに割り当てられているリソースを開放するなどの方法で、ビデオ利用を停止する。ビデオ利用の再開に関しても同様に、ビデオ用ベアラに再度リソースを割り当てる方法が適応できる。また、ベアラのリソースを開放、再割当の方法ではなく、通信相手端末４００、４０２との間でＳＤＰオファー及びＳＤＰアンサーを交換し、再折衝する事により、ビデオの停止及び再開を行っても良い。ビデオの停止、再開の際、端末４００、４０２のユーザに伝えるため、画面に表示する、又は音を鳴らすなどの方法を用いても良い。
【０１１８】
また、上記実施の形態では、ＬＴＥネットワークにおいて、アプリケーション及びアプリケーションの特性に対し、効率的なヘッダ圧縮方式を選択する方法について記述したが、本開示の方式が適用されるのはＬＴＥネットワークに限るものではない。例えば、非特許文献１１に記載のような、次世代ネットワークに本開示の方式を適応してもよい。この場合、ＬＴＥネットワークの場合のベアラは、次世代ネットワークのスライスであってもよい。
【０１１９】
また、上記実施の形態に限定されず、種々変更して実施することが可能である。
【０１２０】
また、上記実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアで実現することも可能である。
【０１２１】
また、上記実施の形態の説明に用いた各機能ブロックは、典型的には、入力端子および出力端子を有する集積回路であるＬＳＩとして実現される。集積回路は、上記実施の形態の説明に用いた各機能ブロックを制御し、入力端子と出力端子を備えてもよい。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１２２】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１２３】
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【０１２４】
本開示の端末は、通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得する取得部と、自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝する折衝部と、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
【０１２５】
本開示の端末において、自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションを示す第２のアプリケーション対応情報を前記基地局へ通知する第１通知部、をさらに具備する。
【０１２６】
本開示の端末において、前記折衝部によって利用が決定されたアプリケーションを示す利用アプリケーション情報を前記基地局へ通知する第２通知部、をさらに具備する。
【０１２７】
本開示の端末において、前記端末がハンドオーバする場合、ハンドオーバ先基地局が対応するアプリケーションの情報に基づいて、利用中のアプリケーションの停止又は継続を判断する制御部、をさらに具備する。
【０１２８】
本開示の端末において、前記制御部は、前記アプリケーションを停止した後、前記端末が当該アプリケーションに対応する基地局へハンドオーバする場合、当該アプリケーションの利用を再開する。
【０１２９】
本開示の端末において、前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、前記圧縮モード決定部は、ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する。
【０１３０】
本開示の端末において、前記ＥＣＮの通知ビットを送信するフィールドは、ＴｏＳ（Type of Service）フィールド又はTraffic Classフィールドである。
【０１３１】
本開示の端末において、前記アプリケーションは、ＭＭＣＭＨ（Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI）であり、前記圧縮モード決定部は、ＣＩＤ(Context ID)を送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する。
【０１３２】
本開示の基地局は、自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
【０１３３】
本開示の通信方法は、端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する。
【０１３４】
本開示の通信方法は、基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する。
【産業上の利用可能性】
【０１３５】
本開示は、通信に使用されるアプリケーション及びアプリケーションの特性に対して効率的なヘッダ圧縮方式を選択する通信システム等に好適である。
【符号の説明】
【０１３６】
４００，４０２  端末
４０４，４０６  基地局
４０８，４１０  無線アクセス網
４１２  コア網
５００  無線受信部
５０１  無線送信部
５０２，６０３  アプリケーション対応情報取得部
５０３，６０２  アプリケーション対応情報通知部
５０４  利用アプリケーション折衝部
５０５  利用アプリケーション情報通知部
５０６，６０５  圧縮モード決定部
５０７  利用アプリケーション制御部
６００  受信部
６０１  送信部
６０４  利用アプリケーション情報取得部
６０６  利用アプリケーション制御情報取得部
【図１】
2018029939.tif 000003
【図２】
2018029939.tif 000004
【図３】
2018029939.tif 000005
【図４Ａ】
2018029939.tif 000006
【図４Ｂ】
2018029939.tif 000007
【図５】
2018029939.tif 000008
【図６】
2018029939.tif 000009
【図７Ａ】
2018029939.tif 000010
【図７Ｂ】
2018029939.tif 000011
【図８Ａ】
2018029939.tif 000012
【図８Ｂ】
2018029939.tif 000013
【図９】
2018029939.tif 000014
【図１０Ａ】
2018029939.tif 000015
【図１０Ｂ】
2018029939.tif 000016
【図１１】
2018029939.tif 000017
【国際調査報告】
2018029939.tif 000018
2018029939.tif 000019
2018029939.tif 000020
2018029939.tif 000021