JP6847115B2 - 端末、基地局及び通信方法 - Google Patents

端末、基地局及び通信方法 Download PDF

Info

Publication number
JP6847115B2
JP6847115B2 JP2018533431A JP2018533431A JP6847115B2 JP 6847115 B2 JP6847115 B2 JP 6847115B2 JP 2018533431 A JP2018533431 A JP 2018533431A JP 2018533431 A JP2018533431 A JP 2018533431A JP 6847115 B2 JP6847115 B2 JP 6847115B2
Authority
JP
Japan
Prior art keywords
application
ecn
terminal
terminals
information
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.)
Active
Application number
JP2018533431A
Other languages
English (en)
Other versions
JPWO2018029939A1 (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.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JPWO2018029939A1 publication Critical patent/JPWO2018029939A1/ja
Application granted granted Critical
Publication of JP6847115B2 publication Critical patent/JP6847115B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/22—Performing reselection for specific purposes for handling the traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/26—Reselection being triggered by specific parameters by agreed or negotiated communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/34—Reselection control
    • H04W36/38—Reselection control by fixed network equipment
    • H04W36/385—Reselection control by fixed network equipment of the core network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/35—Flow control; Congestion control by embedding flow control information in regular packets, e.g. piggybacking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point

Description

本開示は、端末、基地局及び通信方法に関する。
３ＧＰＰ（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)を送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する。
本開示の基地局は、自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、を具備する。
本開示の通信方法は、端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、前記アプリケーションの折衝結果に基づいて圧縮モードを決定する。
本開示の通信方法は、基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する。
本開示は、通信に使用されるアプリケーション及びアプリケーションの特性に対して効率的なヘッダ圧縮方式を選択する通信システム等に好適である。
４００，４０２ 端末
４０４，４０６ 基地局
４０８，４１０ 無線アクセス網
４１２ コア網
５００ 無線受信部
５０１ 無線送信部
５０２，６０３ アプリケーション対応情報取得部
５０３，６０２ アプリケーション対応情報通知部
５０４ 利用アプリケーション折衝部
５０５ 利用アプリケーション情報通知部
５０６，６０５ 圧縮モード決定部
５０７ 利用アプリケーション制御部
６００ 受信部
６０１ 送信部
６０４ 利用アプリケーション情報取得部
６０６ 利用アプリケーション制御情報取得部

Claims (10)

  1. 通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得する取得部と、
    自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝する折衝部と、
    前記アプリケーションの折衝結果に基づいて圧縮モードを決定する圧縮モード決定部と、
    を具備し、
    前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、
    前記圧縮モード決定部は、前記ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する、
    端末。
  2. 自機が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションを示す第２のアプリケーション対応情報を前記基地局へ通知する第１通知部、をさらに具備する、
    請求項１に記載の端末。
  3. 前記折衝部によって利用が決定されたアプリケーションを示す利用アプリケーション情報を前記基地局へ通知する第２通知部、をさらに具備する、
    請求項１に記載の端末。
  4. 前記端末がハンドオーバする場合、ハンドオーバ先基地局が対応するアプリケーションの情報に基づいて、利用中のアプリケーションの停止又は継続を判断する制御部、をさらに具備する、
    請求項１に記載の端末。
  5. 前記制御部は、前記アプリケーションを停止した後、前記端末が当該アプリケーションに対応する基地局へハンドオーバする場合、当該アプリケーションの利用を再開する、
    請求項４に記載の端末。
  6. 前記ＥＣＮの通知ビットを送信するフィールドは、ＴｏＳ（Type of Service）フィールド又はTraffic Classフィールドである、
    請求項１に記載の端末。
  7. 前記アプリケーションは、ＭＭＣＭＨ（Multi-stream Multiparty Conferencing for Multimedia Telephony Service for MTSI）であり、
    前記圧縮モード決定部は、ＣＩＤ(Context ID)を送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する、
    請求項１に記載の端末。
  8. 自機が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知する通知部と、
    前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得するアプリケーション情報取得部と、
    前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定する圧縮モード決定部と、
    を具備し、
    前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、
    前記圧縮モード決定部は、前記ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードを選択する、
    基地局。
  9. 端末と通信相手端末との通信経路上に存在する基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を取得し、
    前記端末が対応するアプリケーションのうち、前記第１のアプリケーション対応情報に示されるアプリケーションと一致するアプリケーションの利用を前記通信相手端末と折衝し、
    前記アプリケーションの折衝結果に基づいて圧縮モードを決定し、
    前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、
    前記ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードが選択される、
    通信方法。
  10. 基地局が対応するアプリケーションを示す第１のアプリケーション対応情報を端末へ通知し、
    前記端末において前記第１のアプリケーション対応情報に基づき前記端末の通信相手端末との間で折衝された、アプリケーションの情報を取得し、
    前記取得した折衝されたアプリケーションの情報に基づいて圧縮モードを決定し、
    前記アプリケーションは、ＥＣＮ（Explicit Congestion Notification）であり、
    前記ＥＣＮの通知ビットを送信するフィールドを有するモードのうち圧縮率が最も高いモードが選択される、
    通信方法。
JP2018533431A 2016-08-12 2017-05-25 端末、基地局及び通信方法 Active JP6847115B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016158839 2016-08-12
JP2016158839 2016-08-12
PCT/JP2017/019456 WO2018029939A1 (ja) 2016-08-12 2017-05-25 端末、基地局及び通信方法

Publications (2)

Publication Number Publication Date
JPWO2018029939A1 JPWO2018029939A1 (ja) 2019-06-06
JP6847115B2 true JP6847115B2 (ja) 2021-03-24

Family

ID=61162104

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018533431A Active JP6847115B2 (ja) 2016-08-12 2017-05-25 端末、基地局及び通信方法

Country Status (3)

Country Link
US (1) US10716029B2 (ja)
JP (1) JP6847115B2 (ja)
WO (1) WO2018029939A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180096370A (ko) * 2017-02-21 2018-08-29 삼성전자주식회사 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법
CN114710781A (zh) * 2020-12-16 2022-07-05 华为技术有限公司 一种终端识别方法及装置

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1142422A1 (en) * 1998-12-23 2001-10-10 Ericsson Inc. Configurable communication system having ip-based capabilities
JP2001211443A (ja) * 2000-01-27 2001-08-03 Mega Chips Corp 情報配信システム
JP3799326B2 (ja) * 2002-12-02 2006-07-19 Ｎｅｃインフロンティア株式会社 パケット送信方式及びパケット受信方式
US8339963B2 (en) * 2003-08-27 2012-12-25 Rockstar Consortium Us Lp Technique for end-to-end admission control of real-time packet flows
CN100477851C (zh) * 2005-01-05 2009-04-08 国际商业机器公司 在无线局域网的两种通信模式之间进行切换的方法和系统
JP2006237940A (ja) * 2005-02-24 2006-09-07 Kyocera Corp パケット通信装置、パケット通信システム、パケット通信方法、及びパケット通信プログラム
US8014381B2 (en) * 2005-06-02 2011-09-06 Sharp Kabushiki Kaisha Communication system and communication terminal
JP4722028B2 (ja) 2006-12-26 2011-07-13 富士通株式会社 データ転送システム、接近通知システム、およびデータ転送方法
CN101035375A (zh) * 2007-02-02 2007-09-12 华为技术有限公司 一种自适应通信系统、终端、方法及接入点
KR101376816B1 (ko) * 2007-04-24 2014-04-01 엘지전자 주식회사 무선통신 시스템에서 제어신호 전송방법
JP2008306419A (ja) * 2007-06-07 2008-12-18 Sony Corp 送信装置及び方法、並びにプログラム
WO2010124471A1 (zh) * 2009-04-30 2010-11-04 华为技术有限公司 一种数据传输的方法、装置
US8427949B2 (en) * 2009-08-07 2013-04-23 Future Wei Technologies, Inc. System and method for adapting a source rate
CN102026320B (zh) * 2009-09-22 2013-10-09 华为终端有限公司 网络切换方法、系统及设备
US8416690B2 (en) * 2010-01-11 2013-04-09 Research In Motion Limited Explicit congestion notification based rate adaptation using binary marking in communication systems
CN102137451A (zh) * 2010-01-22 2011-07-27 中兴通讯股份有限公司 一种终端与基站协商应用支持能力的系统及方法
CN102158896B (zh) * 2010-02-12 2014-01-01 华为技术有限公司 处理本地链路拥塞的方法和装置
US20130029716A1 (en) * 2010-04-12 2013-01-31 Lg Electronics Inc. Apparatus and method for performing group-based m2m communication
EP2464180A1 (en) * 2010-12-07 2012-06-13 LG Electronics Inc. Apparatus and method for updating a location in a wireless access system
US8843165B2 (en) * 2010-12-08 2014-09-23 At&T Intellectual Property I, L.P. Enhanced delivery of messaging data traffic
WO2012110301A1 (en) * 2011-02-14 2012-08-23 Nokia Siemens Networks Oy Different application of compressed mode
US9392624B2 (en) * 2011-03-02 2016-07-12 Zte Corporation Methods and apparatus for radio configuration indication
CN110049431B (zh) 2011-09-09 2021-07-23 交互数字专利控股公司 用于直接通信的方法和设备
WO2013076945A1 (ja) * 2011-11-25 2013-05-30 日本電気通信システム株式会社 無線通信装置
EP2786613A4 (en) * 2011-12-01 2015-07-22 Ericsson Telefon Ab L M REDUCING COMPRESSION LOAD OF PACKET HEADERS DUE TO HIGH ECN FLOW
US20130194937A1 (en) * 2012-01-31 2013-08-01 Alcatel-Lucent Usa Inc. Method and apparatus for providing intelligent codec rate adaptation for wireless users
US10574417B2 (en) * 2013-03-04 2020-02-25 Qualcomm Incorporated Method and apparatus for MTC device association schemes
US20150201411A1 (en) * 2014-01-10 2015-07-16 Qualcomm Incorporated Handling invalid configurations for enhanced uplink in cell_fach state
US20150312319A1 (en) * 2014-04-29 2015-10-29 Qualcomm Incorporated Access point with limited range
CN105637935B (zh) * 2014-07-10 2019-09-20 华为技术有限公司 一种数据的传输方法、系统及相关装置
US10341466B2 (en) * 2014-11-14 2019-07-02 Qualcomm Incorporated Evolved data compression scheme signaling
US10470090B2 (en) * 2014-11-14 2019-11-05 Qualcomm Incorporated Data compression techniques for handover and radio link failure recovery
CN106301679B (zh) * 2015-06-10 2020-10-23 华为技术有限公司 业务速率的调整方法和装置
EP3439360B1 (en) * 2016-03-28 2021-10-06 Panasonic Intellectual Property Corporation of America User equipment, base station and codec mode switching method
US11171999B2 (en) * 2016-07-21 2021-11-09 Qualcomm Incorporated Methods and apparatus for use of compact concurrent codecs in multimedia communications
US10674351B2 (en) * 2017-06-16 2020-06-02 Qualcomm Incorporated Antenna port compatibility signaling

Also Published As

Publication number Publication date
WO2018029939A1 (ja) 2018-02-15
US10716029B2 (en) 2020-07-14
US20190124550A1 (en) 2019-04-25
JPWO2018029939A1 (ja) 2019-06-06

Similar Documents

Publication Publication Date Title
USRE49636E1 (en) Method and apparatus of improving quality of calls in mobile communication system
EP3721674B1 (en) Method, computer program, carrier containing the computer program and wireless device for supporting multiple access networks
US20180359672A1 (en) Quality of Service Initiated Handover
US20130294283A1 (en) Facilitating device-to-device communication
WO2011050525A1 (zh) 一种将视频通话从ps域切换到cs域的方法和装置
KR102254396B1 (ko) 통신 시스템에서 단말의 헤더 압축 기능을 제어하는 방법 및 장치
US9332094B2 (en) Communication system and method
US11909775B2 (en) Methods and apparatuses for enhancement to IP multimedia subsystem
JP6847115B2 (ja) 端末、基地局及び通信方法
US20180317144A1 (en) Communication system, terminal, and communication control method
CN112753240B (zh) 终端装置、基站装置以及方法
JP2023169450A (ja) 端末装置、基地局装置、および方法
KR100882903B1 (ko) 브이 오 아이피 네트워크의 호 설정 시스템 및 호 설정방법
JP4912833B2 (ja) 無線通信システムおよび移動端末
WO2020166310A1 (ja) 端末装置、および、方法
WO2020196008A1 (ja) 端末装置、基地局装置、および通信方法
WO2020195529A1 (ja) 端末装置、基地局装置、および、方法
CN110915291B (zh) 语音会话建立方法、装置、设备及存储介质
WO2024015474A1 (en) Managing multicast data reception
WO2024015436A1 (en) Managing multicast reception in an inactive state
JP2020137084A (ja) 端末装置、基地局装置、方法、および、集積回路
WO2024015434A1 (en) Managing multicast communication for user equipment operating in an inactive state
WO2024015437A1 (en) Managing multicast communication with a user equipment
WO2024015438A1 (en) Managing state transition for a user equipment in multicast communication

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20190717

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20191114

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191217

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201117

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210128

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: 20210224

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210302

R150 Certificate of patent or registration of utility model

Ref document number: 6847115

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150