JP6313839B2 - 通信端末及び通信方法 - Google Patents

通信端末及び通信方法 Download PDF

Info

Publication number
JP6313839B2
JP6313839B2 JP2016240409A JP2016240409A JP6313839B2 JP 6313839 B2 JP6313839 B2 JP 6313839B2 JP 2016240409 A JP2016240409 A JP 2016240409A JP 2016240409 A JP2016240409 A JP 2016240409A JP 6313839 B2 JP6313839 B2 JP 6313839B2
Authority
JP
Japan
Prior art keywords
codec
codec mode
communication
rtp payload
header
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
JP2016240409A
Other languages
English (en)
Other versions
JP2017060191A (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 JP2017060191A publication Critical patent/JP2017060191A/ja
Application granted granted Critical
Publication of JP6313839B2 publication Critical patent/JP6313839B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/08—Protocols for interworking; Protocol conversion
    • 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/22—Parsing or analysis of headers
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • 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/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • 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/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/00837—Determination of triggering parameters for hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/045—Public Land Mobile systems, e.g. cellular systems using private Base Stations, e.g. femto Base Stations, home Node B
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/181—Transcoding devices; Rate adaptation devices

Description

本発明は、端末の接続先の無線アクセス網（無線アクセスネットワーク）の特性を用いた好適なコーデックモード選択を行う通信端末及び通信方法に関する。
３ＧＰＰ（Third Generation Partnership Project）において、ＩＭＳ（IP Multimedia Subsystem）を使ったＶｏＩＰ（Voice over IP）サービスが行われつつある。
図１は、３ＧＰＰのＩＭＳを使ったＶｏＩＰサービスのネットワーク構成の一例を示す。図１に示すネットワークは、ＩＭＳ網１２６と、オペレータのＩＰコア網１２４と、基地局（ｅＮＢ：e Node B）及びｅＮＢ配下で構成される無線アクセス網（無線アクセスネットワーク）１２０、１２２とから成る。図１において、端末（ＵＥ：User Equipment）１００、１０２は、無線アクセス網１２０、１２２でｅＮＢ１０４、１０６にそれぞれ無線接続し、ｅＮＢ１０４、１０６を介してＩＰコア網１２４に接続する。
ＩＭＳ網は、呼制御のための情報管理及び呼制御のシグナリングメッセージ（ＳＩＰ：Session Initiation Protocol）のルーティング及び３ＧＰＰのレガシー網あるいは３ＧＰＰ以外の網との相互接続を行うための網である。
図１に示すＩＭＳ網１２６において、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function）１０８、１１６は、ＵＥ１００、１０２と接するＣＳＣＦである。ＵＥは、ＩＭＳシグナリングメッセージ（SIP REGISTERメッセージ、SIP INVITEメッセージ等）を送信する際、自分が接続できるＰ−ＣＳＣＦを検索し、このＰ−ＣＳＣＦにＩＭＳシグナリングメッセージを送信する。
Ｓ−ＣＳＣＦ（Serving CSCF）１１０、１１４は、ＵＥのコンタクト情報の管理及びセッションの管理を行うＣＳＣＦである。Ｓ−ＣＳＣＦ１１０、１１４は、ＵＥのコンタクト情報の管理を行う際、ＨＳＳ（Home Subscriber Server）１１８から必要な情報をダウンロードする。
Ｉ−ＣＳＣＦ（Interrogating CSCF）１１２は、管理ドメイン（各オペレータが管理している網の単位）間のＣＳＣＦの情報を保持する。Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦがＩＭＳシグナリングメッセージを転送すべき次のノード情報を持たない場合等に、ＩＭＳシグナリングメッセージはＩ−ＣＳＣＦ１１２経由で転送される。また、Ｉ−ＣＳＣＦ１１２は、ＨＳＳ１１８に情報を照会することにより、メッセージ転送先ＣＳＣＦの情報を確認することもある。例えば、SIP INVITEメッセージが送られる場合について説明する。
この場合、SIP INVITEメッセージは、まず発呼側ＵＥから、当該ＵＥが存在するドメイン（発呼側ドメイン）のＰ−ＣＳＣＦにＩＰコア網経由で送られ、Ｐ−ＣＳＣＦから発呼側Ｓ−ＣＳＣＦに転送される。SIP INVITEメッセージは、発呼側Ｓ−ＣＳＣＦで適当な処理が行われた後、着呼側ドメインのＳ−ＣＦＣＳへと転送される。この際、SIP INVITEメッセージがＩ−ＣＳＣＦ１１２を経由する場合もある。着呼側Ｓ−ＣＳＣＦは、受け取ったSIP INVITEメッセージをＰ−ＣＳＣＦ経由で着呼側ＵＥへと転送する。
図１に示すオペレータのＩＰコア網１２４は、通信データのルーティング、ＱｏＳ（Quality of Service）制御、及び、端末の位置情報の管理等を行う。
図２は、３ＧＰＰのＩＭＳを使ったＶｏＩＰの通話が行われるまでの手順の一例を示すフローである。図２は、ＵＥ１００からＵＥ１０２に電話をかける場合のフロー例を示す。図２に示すように、SIP INVITEメッセージがＩＭＳ網経由でＵＥ１００からＵＥ１０２に送信され（ステップ（以下、「ＳＴ」という）１１）、SIP 183 Session ProgressメッセージがＩＭＳ網経由でＵＥ１０２からＵＥ１００へ送信される（ＳＴ１２）。このように、SIP INVITEメッセージ及びSIP 183 Session ProgressメッセージがＵＥ間でやりとりされ、通信に関するネゴシエーションが行われる。
SIP INVITEメッセージに付加されたＳＤＰ（Session Description Protocol）オファーには、ＶｏＩＰ通信で使用されるメカニズムが記述される。記述されるメカニズムとしては、例えば、コーデックの方式あるいはコーデックモード、及び、プロトコルに関する候補等である。コーデックの方式あるいはコーデックモードは、ビットレート、アルゴリズム遅延、チャンネル数等の、このコーデックに採用されている要素を含む。また、プロトコルは、ＲＴＰ（Real-time Transport Protocol）ペイロードフォーマットの種類等を含む。ＵＥ１０２は、ＳＴ１１でSIP INVITEメッセージを受け取ると、ＳＤＰオファーに記述された複数の候補の中から１つのメカニズムを選択し、ＳＤＰアンサーに記述する。ＵＥ１０２は、ＳＴ１２においてＳＤＰアンサーをSIP 183 Session Progressメッセージに付加してＵＥ１００に送る。
ＵＥ１０２で選択されたメカニズムはＩＭＳ網で解析され、解析結果に応じたリソースをこの通話セッションに割り当てる指示が、ＩＰコア網に出される。ＩＭＳ網からの指示に従って、ＩＰコア網及び無線アクセス網でのリソース割当処理が行われる（ＳＴ１３）。リソース割当処理が完了すると、ＵＥ１０２ではユーザの呼び出しが行われ（ＳＴ１４）、ユーザが応答するとＵＥ１００に２００ＯＫメッセージが送信され（ＳＴ１５）、ＵＥ１００とＵＥ１０２との間で通話が開始される（ＳＴ１６）。
図３にＳＤＰオファー（SDP offer）及びＳＤＰアンサー（SDP answer）の一例を示す。図３では、ＳＤＰオファーによって、AMR-WB（Adaptive Multi Rate - Wide Band） bandwidth-efficiencyモード、AMR-WB octet-alignモード、AMR bandwidth-efficiencyモード、及び、AMR octet-alignモードの４モードがＵＥ１００においてオファーされている。また、AMR bandwidth-efficiencyモードが、ＵＥ１０２において選択されている。
なお、bandwidth-efficiencyモード及びoctet-alignモードに関しては、非特許文献１に記載されている、AMR(又はAMR-NB：Narrow Band)及びAMR-WBに用いられるＲＴＰペイロードフォーマットである。また、非特許文献２において、このときのコーデックビットレートがAMR 4.75、5.90、7.40、及び12.2kbpsと定められている。
リソース割当処理（図２に示すＳＴ１３）の際に必要なリソースが割り当てられない場合にはネゴシエーション失敗となり、再度SIP INVITEメッセージの送信（ＳＴ１１）からやり直しとなる。このため、リソース割当が確実に行われるよう、低めの限られたビットレートの範囲を使用することが推奨されている。例えば、非特許文献３では、AMR-NB : 4.75、5.15、5.90、6.70、7.40、7.95、10.2、及び12.2kbpsがサポートされ、非特許文献４では、AMR-WB : 6.60、8.85、12.65、14.25、15.85、18.25、19.85、23.05、及び23.85kbpsがサポートされる。非特許文献２では、AMR-NB : 4.75、5.90、7.40、及び12.2kbps、AMR-WB : 6.60、8.85、及び12.65kbpsの使用が推奨されている。
上述した通話開始時のネゴシエーションでのコーデックモード選択は、データのやり取りが実際に行われるネットワークの状況とは独立に行われる。このため、通話開始時点、或いは、通話期間全体で使用されるコーデックモードとして、適切なコーデックモードが選択されない場合があるという課題がある。現在３ＧＰＰ ＳＡ４で議論されているＥＶＳ（Enhanced Voice Services）では、ＡＭＲ及びＡＭＲ−ＷＢに比べ、より高ビットレートのサポート、複数のアルゴリズムのサポート、２チャンネル（ステレオ）のサポート等が考えられている。このため、特にＥＶＳでは、好適なコーデックモードの選択が求められる。
上記課題に対して、ＵＥが現在のAir Interfaceの帯域幅をサーバに通知し、Air Interfaceの帯域幅に基づいてサーバにビットレートを決定させる方法が提案されている（例えば、「特表２００６−５００８０８号公報」を参照）。また、ＵＥが無線区間の状況をモニタリングし、無線区間の状況に応じて好適なデジッタ バッファ(de-Jitter Buffer)長を調整する方法が提案されている（例えば、「米国特許出願公開第２００６／００７７９９４号明細書」を参照）。
しかしながら、どちらの方法も、ＵＥが無線の状態（現在のAir Interfaceの帯域幅又は無線区間の状況）をモニタリングする分、ＵＥに負担がかかる。その上、上記方法では、エンド ツー エンド(End-to-End)での通信状況（ＵＥ間の通信経路の品質）は考慮されていない。
また、非特許文献２には、ネゴシエーション時に、通信状況に関わらず確実に通信可能なコーデックモード（つまり、ネゴシエーション失敗が生じる可能性が低いコーデックモード）を選択する方法が記載されている。そして、非特許文献２には、更に、ネゴシエーションで選択されたコーデックビットレートの範囲のうち、低いコーデックビットレートを用いて通話を開始する方法が記載されている。この方法では、通話開始後、エンド ツー エンドのネットワークの通信状況（ＵＥ間の通信経路の品質）に応じて、選択されたコーデックビットレートの範囲内でコーデックビットレートを調整する。しかし、この方法では、通話開始時から適当なコーデックビットレート（実際の通信状況に適したコーデックビットレート）を設定できない上、通話期間全体において使用可能なコーデックビットレートの上限も限定されてしまう。
一方、ネットワークノードが、ネットワークの通信状況（ＵＥ間の通信経路の品質）をＵＥにフィードバックし、ＵＥがネットワークの通信状況に応じてコーデックモードを選択する方法も考えられる。しかし、この方法では、ネットワークのトラフィック量が増大し、ネットワークに負担がかかってしまう。
本発明の目的は、ネットワーク及び端末（ＵＥ）に対する処理負荷を抑えつつ、端末間の通信経路の品質に応じたコーデックモードを通信の初期段階から選択することができる通信端末及び通信方法を提供することである。
本発明の一態様に係る通信端末は、ＲＴＰ（Real-time Transport Protocol）を用いて相手端末との通信を行う通信端末であって、前記相手端末に対し、エンコードされたデータをＲＴＰペイロードのフォーマットを用いて送信する送信部と、前記相手端末から送信されたデータをＲＴＰペイロードのフォーマットを用いて受信する受信部と、前記相手端末との通信開始時に、ＳＤＰオファー/アンサーによる折衝を行った結果に基づいて、前記相手端末との通信に用いるコーデックモードまたはコーデックセットを決定するモード決定部と、を備え、前記ＲＴＰペイロードは、ＳＤＰオファー/アンサーによる折衝に基づいて、当該ＲＴＰペイロードのヘッダ部に、前記相手端末にコーデックモードの変更を要求するコーデックモードリクエストフィールドを含むか否かが設定され、前記コーデックモードは、ビットレート情報を含む。
本発明の一態様に係る通信方法は、ＲＴＰ（Real-time Transport Protocol）を用いて相手端末との通信を行う通信方法であって、前記相手端末に対し、エンコードされたデータをＲＴＰペイロードのフォーマットを用いて送信し、前記相手端末から送信されたデータをＲＴＰペイロードのフォーマットを用いて受信し、前記相手端末との通信開始時に、ＳＤＰオファー/アンサーによる折衝を行った結果に基づいて、前記相手端末との通信に用いるコーデックモードまたはコーデックセットを決定し、前記ＲＴＰペイロードは、ＳＤＰオファー/アンサーによる折衝に基づいて、当該ＲＴＰペイロードのヘッダ部に、前記相手端末にコーデックモードの変更を要求するコーデックモードリクエストフィールドを含むか否かが設定され、前記コーデックモードは、ビットレート情報を含む。
本発明によれば、端末が保有している情報を折衝情報として用いることにより、ネットワーク及び端末の双方に処理負荷をかけることなく、端末間の通信経路の状況を判断し、適切なコーデックモードを選択できる。
ＩＭＳ網、ＩＰコア網及び無線アクセス網の構成の一例を示す図 通話セッション確立の基本動作の一例を示す図 ＳＤＰオファー及びＳＤＰアンサーの一例を示す図 本発明の各実施の形態に係るネットワークの構成の一例を示す図 本発明の各実施の形態に係るネットワークの構成の一例を示す図 本発明の各実施の形態に係るＲＴＰパケットの説明に供する図 本発明の実施の形態１に係る端末（ＵＥ）の構成を示すブロック図 本発明の実施の形態１に係るＳＤＰオファーの一例を示す図 本発明の実施の形態１に係るコーデックモードセットと番号との対応付けを示す図 本発明の実施の形態１に係る情報比較部及びモード決定部における処理の流れを示すフロー図 本発明の実施の形態１に係るＳＤＰアンサーの一例を示す図 本発明の実施の形態２に係るネットワークノードの構成を示すブロック図 本発明の実施の形態３に係る端末（ＵＥ）の構成を示すブロック図 本発明の実施の形態３に係るＳＤＰオファーの一例を示す図 本発明の実施の形態３に係るコーデックモードセットと番号との対応付けを示す図 本発明の実施の形態３に係る情報比較部及びモード決定部における処理の流れを示すフロー図 本発明の実施の形態３に係るＳＤＰアンサーの一例を示す図 本発明の実施の形態３に係るＩＰパケットのフォーマットの一例を示す図 本発明の実施の形態４に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第１の例） 本発明の実施の形態４に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第２の例） 本発明の実施の形態４に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第３の例） 本発明の実施の形態５に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第１の例） 本発明の実施の形態５に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第２の例） 本発明の実施の形態６に係るオペレータのポリシー及びＳＤＰオファーの一例を示す図 本発明の実施の形態６に係るオペレータのポリシー及びＳＤＰアンサーの一例を示す図 本発明の実施の形態７に係るネットワークの構成の一例を示す図 本発明の実施の形態７に係るＩＰ−ＰＢＸの構成を示すブロック図 本発明の実施の形態８に係るＲＴＰペイロードフォーマットの第１の例を示す図 本発明の実施の形態８に係るＲＴＰペイロードフォーマットの第２の例を示す図 本発明の実施の形態８に係るＲＴＰペイロードフォーマットの第３例を示す図
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
図４は、本発明の各実施の形態に係るネットワーク構成と、端末の位置関係の一例を示す図である。なお、図４において、図１と同一構成である部分には同一の符号を付してその説明を省略する。
ＨｅＮＢ（Home eNode B）４００、４０２は、小型基地局（ここではフェムト基地局とする。例えば、「3GPP TS 23.830 v9.0.0, "Architecture aspects of Home NodeB and Home eNodeB"」を参照。以下同様）であり、限られたユーザが保有するＵＥのみ各ＨｅＮＢに接続可能であることを示すＣＳＧ ＩＤ（Closed Subscriber Group Identifier。例えば、「3GPP TS 25.401 v9.0.0, "UTRAN overall description"」を参照）を保持する。ＨｅＮＢ４００は、無線アクセス網４０６を構成し、ＨｅＮＢ４０２は、無線アクセス網４０８を構成する。
図４に示すネットワーク構成では、ＨｅＮＢ４００、４０２は、同一のＬｏｃａｌ ＧＷ（Gateway）４０４に接続されている。よって、ＨｅＮＢ４００及びＨｅＮＢ４０２にそれぞれ接続されているＵＥ同士（ＵＥ１００とＵＥ１０２）は、オペレータのＩＰコア網１２４を経由することなく、Ｌｏｃａｌ ＧＷ４０４を経由してデータを送受信することができる。
図４に示す無線アクセス網４０６、４０８には、限られたユーザのみが接続されるため、各無線アクセス網における１ＵＥあたりに割当可能な無線リソースは大きい。このような構成は、例えば、ＨｅＮＢを用いて企業内の専用電話網を構築する場合等に適用される。なお、図４では、Ｌｏｃａｌ ＧＷ４０４がＨｅＮＢ４００、４０２から独立している例が挙げられているが、これに限定されない。その他の構成、例えばＬｏｃａｌ ＧＷ４０４が各ＨｅＮＢ４００、４０２にそれぞれ設置され、各ＨｅＮＢに設置されたＬｏｃａｌ ＧＷが直接或いは他のノードを介して接続される構成が採用されてもよい。
図５は、本発明の各実施の形態に係るネットワーク構成と、端末の位置関係の別の例を示す図である。なお、図５において、図１と同一構成である部分には同一の符号を付してその説明を省略する。
ＨｅＮＢ５００、５０２は、小型基地局（フェムト基地局）であり、ＨｅＮＢ５００は、無線アクセス網５０６を構成し、ＨｅＮＢ５０２は、無線アクセス網５０８を構成する。
図５に示すネットワーク構成では、ＨｅＮＢ５００とＨｅＮＢ５０２とがそれぞれ別々にオペレータのＩＰコア網１２４に接続されている。よって、ＨｅＮＢ５００及びＨｅＮＢ５０２にそれぞれ接続されているＵＥ同士（ＵＥ１００とＵＥ１０２）は、オペレータのＩＰコア網１２４を経由してデータを送受信する。ただし、無線アクセス網５０６、５０８には、図４と同様、限られたユーザのみが接続されるため、各無線アクセス網における１ＵＥあたりに割当可能な無線リソースは大きい。このような構成は、例えば、個人宅等にＨｅＮＢが設置されている場合等に適用される。
以下の説明では、図４に示すＵＥ１００とＵＥ１０２との間の通信形態（各々が接続されたＨｅＮＢ及びＬｏｃａｌ ＧＷを介した通信形態）を、“ＨｅＮＢ＋ローカル網通信”と呼ぶ。また、図５に示すＵＥ１００とＵＥ１０２との間の通信形態（各々が接続されたＨｅＮＢ及びＩＰコア網を介した通信形態）を、“ＨｅＮＢ＋ＩＰコア網通信”と呼ぶ。
ここで、図６を用いて、本発明の各実施の形態で用いるＲＴＰ関連用語を説明する。ＲＴＰパケットは、図６に示すように、ＲＴＰヘッダとＲＴＰペイロードとから成る。
ＲＴＰヘッダはＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ（Request for Comments）3550に記載の通りであり、ＲＴＰペイロードの種類（コーデックの種類等）によらず共通である。ＲＴＰペイロードのフォーマットはＲＴＰペイロードの種類により異なる。図６に示すように、ＲＴＰペイロードは、ヘッダ部とデータ部とから成るが、ＲＴＰペイロードの種類によってはヘッダ部が存在しない場合もある。ＲＴＰペイロードのヘッダ部には、音声及び動画等のエンコードされたデータのビット数を特定するための情報等が含まれる。ＲＴＰペイロードデータ部には、音声及び動画等のエンコードされたデータの他、このＲＴＰペイロード長が１オクテット（８ビット）の倍数にならなかった場合に付加されるpadding等が含まれる。また、図６に示すように、ＲＴＰパケットが伝送される際、更に下位層のヘッダ（ＵＤＰ（User Datagram Protocol）ヘッダ、ＩＰヘッダ、及びＩＰ以下の伝送路固有のヘッダ）が付加される。
（実施の形態１）
図７は、本実施の形態に係る端末（ＵＥ１００、１０２）の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図７では、本発明と密接に関連する端末同士の通信に関するネゴシエーションに関わる主な構成部（例えば、図２に示すＳＴ１１〜ＳＴ１５に関わる構成部）を示す。
図７に示す端末（ＵＥ１００、１０２）において、無線受信部６００は、自機が発呼側の場合、通信相手である相手端末（着呼側ＵＥ）から通知されるシグナリングメッセージ（SIP 183 Session Progressメッセージ）を受信する。そして、無線受信部６００は、受信したシグナリングメッセージをモード決定部６０８に出力する。このシグナリングメッセージには、例えばＳＤＰアンサー内に記述された、コーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）が含まれている。一方、無線受信部６００は、自機が着呼側の場合、通信相手のＵＥ（発呼側）から通知されるシグナリングメッセージ（SIP INVITEメッセージ）を受信する。そして、無線受信部６００は、受信したシグナリングメッセージを情報比較部６０６及びモード決定部６０８に出力する。このシグナリングメッセージには、例えばＳＤＰオファー内に記述された、コーデックモードセット候補（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせの候補）、及び、通信相手のＵＥが現在接続している無線アクセス網の特性に関する情報が含まれている。
無線送信部６０２は、シグナリング生成部６１０から出力されるシグナリングメッセージ（SIP INVITEメッセージ又はSIP 183 Session Progressメッセージ）を通信相手のＵＥへ送信する。
接続先判断部６０４は、自機が現在接続している無線アクセス網の特性を判断し、無線アクセス網の特性に関する情報を保持する。接続先判断部６０４は、無線アクセス網の特性に関する情報を、情報比較部６０６及びシグナリング生成部６１０に出力する。
情報比較部６０６は、自機が着呼側の場合、自機が現在接続している無線アクセス網の特性に関する情報と、通信相手のＵＥ（発呼側）が現在接続している無線アクセス網の特性に関する情報とを比較する。前者は、接続先判断部６０４から入力される情報であり、後者は、無線受信部６００から入力される、シグナリングメッセージに含まれる情報である。
具体的には、情報比較部６０６は、双方の無線アクセス網の特性に関する情報を比較して、自機と相手端末との間の通信形態を判断する。例えば、情報比較部６０６は、自機及び相手端末が、ＨｅＮＢ＋ローカル網通信、ＨｅＮＢ＋ＩＰコア網通信、及び異なる通信形態のうち、いずれであるかを判断する。ここで、ＨｅＮＢ＋ローカル網通信とは、同一のＨｅＮＢ、複数のＨｅＮＢ、又は複数のＨｅＮＢ及びＶＰＮ（Virtual Private Network）バックボーンで構成されるような通信網で接続された通信形態である。また、ＨｅＮＢ＋ＩＰコア網通信とは、ＩＰコア網１２４を介した異なるＨｅＮＢ（フェムト基地局）に接続された通信形態である。そして、情報比較部６０６は、判断した通信形態をモード決定部６０８に出力する。
モード決定部６０８は、自機が発呼側の場合、無線受信部６００から入力されるシグナリングメッセージに含まれるＳＤＰアンサーに記述されたコーデックモードセットを、自機と通信相手との間の通信で使用するコーデックモードセットに決定する。モード決定部６０８は、自機が着呼側の場合、無線受信部６００から入力されるシグナリングメッセージに含まれるＳＤＰオファーに記述されたコーデックモードセット候補の中から、自機と相手端末との通信で使用するコーデックモードセットを選択する。この選択は、情報比較部６０６から入力される通信形態に基づいて行われる。
シグナリング生成部６１０は、自機が発呼側の場合、接続先判断部６０４から入力される、自機の接続先アクセス網の特性に関する情報を含むシグナリングメッセージを生成する。これにより、発呼側ＵＥの接続先アクセス網の特性に関する情報は、着呼側ＵＥに通知される。シグナリング生成部６１０は、自機が着呼側の場合、モード決定部６０８で決定されたコーデックモードセットを含むシグナリングメッセージを生成する。シグナリング生成部６１０は、生成したシグナリングメッセージを無線送信部６０２に出力する。
次に、図７を用いて、本実施の形態に係る端末（ＵＥ１００及びＵＥ１０２）における処理について詳細に説明する。
以下の説明では、図４又は図５において、現在、ＵＥ１００がＨｅＮＢ４００又はＨｅＮＢ５００に接続され、ＵＥ１０２がＨｅＮＢ４０２又は５０２に接続されており、ＵＥ１００からＵＥ１０２に対して電話をかけるとする。通話開始時点では、ＵＥ１００（発呼側ＵＥ）及びＵＥ１０２（着呼側ＵＥ）は、互いに通信相手がどこに位置しているのかに関する情報（例えば、ＵＥが接続されているセル（ＨｅＮＢ）を示すセル情報、及び、ＵＥの位置を示す位置情報等）を保持していない。
ＵＥ１００の接続先判断部６０４は、ＵＥ１００が接続している無線アクセス網４０６（又は５０６）の特性を判断する。例えば、接続先判断部６０４は、ＵＥ１００が現在接続しているＨｅＮＢ４００（又は５００）のＣＳＧ ＩＤに基づいて、ＵＥ１００に割り当てられる無線リソース（割当可能な無線リソース又は無線リソースの占有量）の状況を判断する。例えば、接続先判断部６０４は、ＣＳＧ ＩＤがフェムト基地局を表している場合、当該フェムト基地局ではＵＥ１００に割当可能なリソースが大きいと判断する。
また別の例としては、接続先判断部６０４は、ＵＥ１００が現在接続している無線アクセス網が、３ＧＰＰ等の携帯電話専用無線アクセス網以外の無線アクセス網、例えば無線ＬＡＮ等で構成されたものであると判断する。この判断は、無線アクセス網の無線特性（無線周波数帯またはシグナリング等）などに基づいて行われる。この場合、通信データの送受信フォーマット（一度に送られるフレームの個数、ＲＴＰペイロードフォーマット等）は、３ＧＰＰ等の携帯電話専用無線アクセス網用に制限されたフォーマットでなくてよい事などを判断する。
ＵＥ１００のシグナリング生成部６１０は、通信相手（ＵＥ１０２）に通知する情報が記述された、呼制御のためのシグナリングメッセージ（例えば、SIP INVITEメッセージ）を生成する。例えば、接続先判断部６０４で無線アクセス網の特性が判断されると、シグナリング生成部６１０は、現在接続中の無線アクセス網がＣＳＧ ＩＤを保持する場合、ＣＳＧ ＩＤを、SIP INVITEメッセージに含まれるＳＤＰオファー内に記述する。又は、シグナリング生成部６１０は、ＳＩＰヘッダ（例えばP-Access-Network-Info header field）に記述してもよい（例えば、「3GPP TS 24.229 v10.0.0, "Session Initiation Protocol (SIP) and Session Description Protocol (SDP)"」を参照）。
また、無線アクセス網の特性に関する情報としては、ＣＳＧ ＩＤの代わりに、基地局ＩＤ（例えば、「3GPP TS 25.401 v9.0.0, "UTRAN overall description"」を参照）を用いてもよい。各ＵＥでは、ＣＳＧ ＩＤ又は基地局ＩＤ（無線アクセス網の特性に関する情報）に基づいて、無線アクセス網の特性（例えば、当該無線アクセス網における１ＵＥあたりに割当可能な無線リソースが大きいか否か）を特定することができる。例えば、各ＵＥは、ＣＳＧ ＩＤ又は基地局ＩＤに基づいて、当該無線アクセス網を構成する基地局がフェムト基地局である場合には、当該無線アクセス網における１ＵＥあたりに割当可能な無線リソースが大きいと判断する。
また、ＵＥ１００のシグナリング生成部６１０は、通信相手（ＵＥ１０２）が接続している無線アクセス網４０８（又は５０８）の特性の全て又は一部の可能性を考慮したコーデックモードセットの候補を作成する。そして、ＵＥ１００のシグナリング生成部６１０は、コーデックモードセットの候補をＳＤＰオファー内に記述する。
ＳＤＰオファーの記述の一例を図８に示す。例えば、ＵＥ１００の接続先無線アクセス網のＣＳＧ ＩＤが“Alice-femto”である場合、図８に示すように、ＳＤＰオファー内には、例えば“a=csg:Alice-femto”と記述される。なお、記述方法はこれに限らず別の記述方法でもよい。また、通信相手（ＵＥ１０２）の接続先無線アクセス網の特性の全て又は一部の可能性を考慮したコーデックモードのセット候補を記述する方法として、例えば各コーデックモードセットにそれぞれ対応付けられた数値のみを記述してもよい。この数値は、図８では“０ｘ００”、“０ｘ０１”及び“０ｘ０２”としている。これにより、ＳＤＰ内の記述量を削減することが可能となる。また、コーデックモードセットと数値との対応付けに限らず、記号又はその他の方法でコーデックモードセットを表してもよい。
例えば、図８に示す数値（番号）“０ｘ００”、“０ｘ０１”、“０ｘ０２”と、これら数値の表わす意味及びこれらに対応するコーデックモードセットとの対応関係を図９に示す。
具体的には、図９に示す“０ｘ００”は、例えば、後述する“０ｘ０１”及び“０ｘ０２”に対応する通信と異なる通信である通常通信を意味する。そして、図９に示す“０ｘ００”は、ビットレートが（6kbps前後、8kbps前後、12kbps前後）であり、低い（Low）アルゴリズム遅延であるコーデックモードセットに対応する。通常通信では、例えば、選択可能なビットレートのうち低いビットレートで通話を開始し、その後、ＵＥ間の通信経路の品質に応じてコーデックビットレートを選択する。図９に示す“０ｘ０１”は、ＩＰコア網を経由した通信（ＨｅＮＢ＋ＩＰコア網通信。例えば、図５を参照（個人宅））を意味し、ビットレートが（6kbps前後、8kbps前後、12kbps前後、24kbps前後）であり、低い（Low）アルゴリズム遅延であるコーデックモードセットに対応する。また、“０ｘ０２”は、Ｌｏｃａｌ ＧＷを経由した通信（ＨｅＮＢ＋ローカル網通信。例えば、図４を参照（企業内電話網））を意味し、ビットレートが（6kbps前後、8kbps前後、12kbps前後、24kbps前後）であり、高い（High）アルゴリズム遅延であるコーデックモードセットに対応する。
つまり、図９では、“０ｘ０２”が最も品質の良いコーデックを与えるコーデックモードセット（高ビットレート，長遅延）であり、続いて“０ｘ０１”、“０ｘ００”の順に、品質を抑えたコーデックモードセット（低ビットレート化，低遅延化）となる。端末（ＵＥ１００、１０２）には図９に示す対応付けが予め格納されていてもよい。
ＵＥ１００のシグナリング生成部６１０で生成されたシグナリングメッセージ（SIP INVITEメッセージ）は、無線送信部６０２を介して、ＩＭＳ網１２６経由でＵＥ１０２に送信される。
一方、ＵＥ１０２の無線受信部６００は、ＵＥ１００から送信されたシグナリングメッセージ（SIP INVITEメッセージ）を受け取る。
ＵＥ１０２の接続先判断部６０４は、ＵＥ１００と同様に、ＵＥ１０２が接続している無線アクセス網４０８（又は５０８）の特性を判断する。
ＵＥ１０２の情報比較部６０６は、受け取ったシグナリングメッセージに、通信相手（ＵＥ１００）の接続先無線アクセス網（無線アクセス網４０６（又は５０６））の特性に関する情報が記述されているかを確認する。情報比較部６０６は、無線アクセス網の特性に関する情報が記述されている場合、通信相手の無線アクセス網の特性と、自機の接続先無線アクセス網の特性とを比較する。そして、情報比較部６０６は、自機（ＵＥ１０２）と通信相手（ＵＥ１００）との間の通信形態（どのような通信が可能か）を判断する。例えば、情報比較部６０６は、通信相手（ＵＥ１００）の接続先無線アクセス網の特性に関する情報として送信されたＣＳＧ ＩＤと、自機（ＵＥ１０２）の接続先無線アクセス網の特性に関する情報であるＣＳＧ ＩＤとを比較する。そして、情報比較部６０６は、自機と通信相手とが同一企業内電話網のＨｅＮＢにそれぞれ接続されているのか、互いに個人宅のＨｅＮＢにそれぞれ接続されているのか、又は、どちらか一方又は双方が公衆の基地局（ｅＮＢ）に接続されているのか、を判断する。又は、情報比較部６０６が、通信相手（ＵＥ１００）及び自機（ＵＥ１０２）の接続先無線アクセス網の特性に関する情報を比較して、双方が物理的に近くに位置するか否か（例えば、データ経路のホップ数が所定の閾値以下であるか否か）を判断してもよい。
ＵＥ１０２のモード決定部６０８は、情報比較部６０６での判断結果（自機と通信相手との間の通信形態）に基づいて、コーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）を決定する。
本実施の形態における情報比較部６０６及びモード決定部６０８における処理の一例を図１０に示す。図１０は、情報比較部６０６及びモード決定部６０８における処理の流れを示すフロー図である。
図１０において、ＳＴ１０１では、情報比較部６０６は、自機の接続先がＨｅＮＢであるか否かを判断する。自機の接続先がＨｅＮＢではない場合（ＳＴ１０１：ＮＯ）、ＳＴ１０２では、モード決定部６０８は、通常通信（０ｘ００）に対するコーデックモードセットを選択する。
自機の接続先がＨｅＮＢである場合（ＳＴ１０１：ＹＥＳ）、ＳＴ１０３では、情報比較部６０６は、通信相手の接続先がＨｅＮＢであるか否かを判断する。通信相手の接続先がＨｅＮＢではない場合（ＳＴ１０３：ＮＯ）、ＳＴ１０４では、モード決定部６０８は、通常通信（０ｘ００）に対応するコーデックモードセットを選択する。つまり、モード決定部６０８は、自機及び通信相手の何れか一方の接続先でもＨｅＮＢではない場合には、通常通信（０ｘ００）に対応するコーデックモードセットを選択する。
通信相手の接続先がＨｅＮＢである場合（ＳＴ１０３：ＹＥＳ）、ＳＴ１０５では、情報比較部６０６は、自機及び通信相手の互いの接続先が同一ローカル網内であるか否かを判断する。
自機及び通信相手の互いの接続先が同一ローカル網内でない場合（ＳＴ１０５：ＮＯ）、ＳＴ１０６では、モード決定部６０８は、“ＨｅＮＢ＋ＩＰコア網通信（０ｘ０１）”に対応するコーデックモードセットを選択する。自機及び通信相手の互いの接続先が同一ローカル網内である場合（ＳＴ１０５：ＹＥＳ）、ＳＴ１０７では、モード決定部６０８は、“ＨｅＮＢ＋ローカル網通信（０ｘ０２）”に対応するコーデックモードセットを選択する。
つまり、モード決定部６０８は、自機と通信相手との間の通信形態が、“ＨｅＮＢ＋ローカル網通信”の場合に最も高品質なコーデックモードセットを選択する。また、モード決定部６０８は、上記通信形態が、“ＨｅＮＢ＋ＩＰコア網通信”の場合、“通常通信”の場合よりも高品質なコーデックモードセットを選択する。
このように、モード決定部６０８は、情報比較部６０６で自機と通信相手との間で良好な品質の通信経路を確保できるか否かの判断結果に基づいて、自機と通信相手との間の通信で使用するコーデックモード（又はコーデックモードセット）を判断する。すなわち、モード決定部６０８は、確保できると判断された場合（例えば、図１０に示すＳＴ１０１：ＹＥＳかつＳＴ１０３：ＹＥＳ）、使用するコーデックモード（又はコーデックモードセット）として、高品質（高ビットかつ長遅延）であるコーデックモードセット（“０ｘ０１”又は“０ｘ０２”）を選択する。一方、モード決定部６０８は、確保できるか不明であると判断された場合（例えば、図１０に示すＳＴ１０１：ＮＯ又はＳＴ１０３：ＮＯ）、使用するコーデックモード（又はコーデックモードセット）として、通常のコーデックモードセット（つまり、上述した、どのような通信状況でも通信可能なコーデックモードセット）を選択する。
ＵＥ１０２のシグナリング生成部６１０は、モード決定部６０８で選択されたコーデックモードセットを、呼制御のためのシグナリングメッセージ（例えば、SIP 183 Session Progressメッセージ）の一部、例えばＳＤＰアンサーに記述する。この際、シグナリング生成部６１０は、ＵＥ１０２の接続先ＨｅＮＢ４０２（又は５０２）のＣＳＧ ＩＤ又は基地局ＩＤを、ＳＤＰアンサー又はＳＩＰヘッダに記述してもよい。
ＳＤＰアンサーの記述の一例を図１１に示す。例えば、ＵＥ１００の接続先無線アクセス網のＣＳＧ ＩＤが図８に示す“Alice-femto”であり、ＵＥ１０２の接続先無線アクセス網のＣＳＧ ＩＤが“Bob-femto”であるとする（図１０のＳＴ１０１、ＳＴ１０３：ＹＥＳ）。また、ＣＳＧ ＩＤ（“Bob-femto”）の無線アクセス網とＣＳＧ ＩＤ（“Alice-femto”）の無線アクセス網とが同一ローカル網内ではないとする（図１０のＳＴ１０５：ＮＯ）。
この場合、ＵＥ１０２の情報比較部６０６は、例えば、自機及び通信相手が互いに個人宅等に設置されているＨｅＮＢに接続されていると判断し、モード決定部６０８は、“ＨｅＮＢ＋ＩＰコア網通信（０ｘ０１）”に対応するコーデックモードセットを選択する。よって、図１１に示すＳＤＰアンサーには、選択されたコーデックモードセットとして“０ｘ０１”が記述される。なお、図１１に示すように、ＵＥ１０２の接続先無線アクセス網の特性に関する情報（Bob-femto）をＳＤＰアンサーに記述してもよい。
ＵＥ１０２のシグナリング生成部６１０で生成されたシグナリングメッセージ（例えば、SIP 183 Session Progressメッセージ）は、無線送信部６０２を介してＩＭＳ網１２６経由でＵＥ１００に送信される。
ＵＥ１００のモード決定部６０８は、無線受信部６００を介して、ＵＥ１０２から送信されたシグナリングメッセージを受け取ると、ＳＤＰアンサーに記述されている内容に基づいて、コーデックモードセットを決定する。図１１の一例では、ＵＥ１００のモード決定部６０８は、“ＨｅＮＢ＋ＩＰコア網通信（０ｘ０１）”に対応するコーデックモードセットを決定する。この際、ＵＥ１００の通信相手（ＵＥ１０２）の接続先のＣＳＧ ＩＤ又は基地局ＩＤを、参照情報として用いてもよい。
このように、本実施の形態では、ＵＥ間での通信開始時において、発呼側のＵＥは、自機の接続先無線アクセス網の特性に関する情報としてＣＳＧ ＩＤ（又は基地局ＩＤ）を通信相手である相手端末（着呼側ＵＥ）に通知する。着呼側のＵＥは、通信相手である相手端末（発呼側ＵＥ）から通知された、相手端末（発呼側）の接続先無線アクセス網の特性に関する情報（ＣＳＧ ＩＤ等）と、自機の接続先無線アクセス網の特性に関する情報（ＣＳＧ ＩＤ等）とを比較する。そして、着呼側のＵＥは、自機と相手端末との間の通信形態を判断する。着呼側のＵＥは、ＵＥ間で良好な品質の通信経路を確実に確保できると判断できる場合、通信開始時のコーデックモードセットとして、より高品質かつ長遅延のコーデックモード（又はコーデックモードセット）を選択する。これは、例えば、通信形態が企業内電話網での通信、又は、個人宅での通信である場合である。
これにより、各ＵＥは、通信開始時（通信の初期段階）から、通信経路の品質に応じた適切なコーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）を選択することができる。
なお、本実施の形態では、本発明を、コーデックモードセットの選択に適用した例を説明したが、これに限定されない。本発明に係る接続先の無線アクセス網の特性判断は、通信に必要な他の折衝、例えば通信データの送受信フォーマット（一度に送られるフレームの個数、ＲＴＰペイロードフォーマット等）を折衝する際の、送受信フォーマット選択に適用してもよい。
また、本実施の形態では、各ＵＥが保有している情報（無線アクセス網の特性に関する情報）を通信相手に通知するだけでよく、ネットワーク側及びＵＥ側のいずれにおいても無線アクセス網の状況（通信経路の品質）をモニタリングする必要がない。よって、適切なコーデックモード（又はコーデックモードセット）の選択のためにネットワーク及びＵＥに掛かる負担を抑えることができる。
よって、本実施の形態によれば、端末が保有している情報を折衝情報として用いる。これにより、ネットワーク及び端末（ＵＥ）の双方にビーコンあるいはシグナリング送受信等に伴う処理負荷をかけることなく、端末間の通信経路の状況を判断し、適切なコーデックモード（又はコーデックモードセット）を選択することができる。
（実施の形態２）
本実施の形態では、実施の形態１においてＵＥがシグナリングメッセージの一部に記述した、無線アクセス網の特性に関する情報を、ＩＭＳ網のネットワークノードで確認する。このネットワークノードは、ネットワークを提供するオペレータ、つまり、呼制御のための処理機能を有するネットワークノードである。
図１２は、本実施の形態に係るネットワークノードの構成を示すブロック図である。
図１２に示すネットワークノードにおいて、受信部７００は、ＵＥからのシグナリングメッセージを受け取ると、シグナリングメッセージをシグナリング解析部７０４に出力する。
送信部７０２は、シグナリング生成部７０８から入力されるシグナリングメッセージを、シグナリングメッセージの送信先ＵＥに送信する。
シグナリング解析部７０４は、受信部７００から入力されるシグナリングメッセージに記述されている情報を解析し、確認が必要な情報を、適切な確認部に出力する。例えば、シグナリング解析部７０４は、シグナリングメッセージに記述された情報のうち、ＵＥが現在接続されている無線アクセス網の特性に関する情報（例えば、ＣＳＧ ＩＤ又は基地局ＩＤ等）を、端末位置情報確認部７０６に渡す。
端末位置情報確認部７０６は、シグナリングメッセージを送信したＵＥが現在接続されている無線アクセス網の特性に関する情報（ＣＳＧ ＩＤ等。つまり、端末の位置情報）が妥当であるか否か（妥当性）を確認する。このとき、端末位置情報確認部７０６は、このネットワークノード内に保持されている情報を用いて確認を行ってもよく、他のネットワークノード（例えばＭＭＥ（Mobility Management Entity）及びＨＳＳ（Home Subscriber Server）等。「3GPP TS 23.002 v10.0.0, " Network Architecture"」を参照）と連携して確認を行ってもよい。端末位置情報確認部７０６は、確認結果をシグナリング生成部７０８に出力する。
シグナリング生成部７０８は、ＵＥから送信されたシグナリングメッセージの中で修正が必要な記載内容の上書きを行う。例えば、端末位置情報確認部７０６において、無線アクセス網の特性に関する情報が妥当であると判断されたとする。この場合、シグナリング生成部７０８は、ネットワークエンティティによる妥当性確認済を示す情報を、フラグ、数値、及び、テキスト等の記載方法でシグナリングメッセージに追加してもよい。また、端末位置情報確認部７０６において、無線アクセス網の特性に関する情報が妥当ではないと判断された場合、シグナリング生成部７０８は、シグナリングメッセージから、無線アクセス網の特性に関する情報を削除してもよい。又は、シグナリング生成部７０８は、端末位置情報確認部７０６での確認結果を示す情報（妥当性の確認結果）をシグナリングメッセージに追加してもよい。修正されたシグナリングメッセージは、送信部７０２を介して、シグナリングメッセージの送信先に送信される。
シグナリングメッセージを受け取ったＵＥは、例えば、ネットワークエンティティによる妥当性確認済であることを特定する。この場合、ＵＥは、実施の形態１と同様にして、シグナリングメッセージに記述された通信相手の接続先無線アクセス網の特性に関する情報を用いて、通信相手との通信形態を判断する。一方、シグナリングメッセージを受け取ったＵＥは、例えば、ネットワークエンティティによる妥当性確認済であることを特定できなかったとする。この場合、ＵＥは、通信相手の接続先無線アクセス網の特性に関する情報を用いた、通信相手との通信形態の判断を行わない。つまり、ＵＥは、ネットワークノードでの妥当性の確認結果に基づいて、相手端末との通信形態の判断を行うか否かを決定すればよい。
これにより、ＵＥは、自機と相手端末との間の通信形態を正確に判断することが可能となる。つまり、自機と相手端末との間の通信形態判断の確実性を向上させることができる。よって、本実施の形態によれば、実施の形態１と比較して、端末間の通信経路の状況をより正確に判断することができ、適切なコーデックモード（又はコーデックモードセット）を選択できる。
なお、本実施の形態において、ネットワークノードは、ＩＭＳ網のエンティティ（Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦ等。「3GPP TS 23.002 v10.0.0, " Network Architecture"」を参照）であってもよく、企業内の専用電話網を構築する場合に用いられるＩＰ−ＰＢＸ（Internet Protocol Private Branch eXchange）等でもよい。例えば、ＩＭＳ網のエンティティの１つであるＰ−ＣＳＣＦ（図４又は図５に示すＰ−ＣＳＣＦ１０８、１１６）には、ＳＤＰの内容を確認し、書き換える機能が備えられている。よって、本実施の形態に係るネットワークノードとしてＰ−ＣＳＣＦを用いると、ＳＤＰの確認機能を無線アクセス網の特性に関する情報の確認にも利用できるので、ネットワーク側の負担の増やすことなく、本実施の形態と同様の効果を得ることができる。
また、本実施の形態では、ネットワークノードが妥当性確認済を示す情報をＵＥに通知する場合について説明したが、妥当性確認済を示す情報は、ＵＥに通知されなくてもよい。例えば、上述したように、ネットワークノードは、妥当ではないと判断された無線アクセス網の特性に関する情報をシグナリングメッセージから削除する。この場合、シグナリングメッセージの送信先ＵＥでは、誤った情報を用いて通信形態の判断を行うことがなくなる。よって、ネットワークノードが妥当性確認済を示す情報をＵＥに通知しない場合でも、本実施の形態と同様、端末間の通信形態判断の確実性を向上させることができる。例えば、ネットワークノードは、同一オペレータのＩＰコア網に接続されたＵＥ同士の通信については上記妥当性確認済を示す情報を通知しなくてもよい。そして、その代わりに、ネットワークノードは、異なるオペレータのＩＰコア網にそれぞれ接続されたＵＥ同士の通信については上記妥当性確認済を示す情報を通知してもよい。
（実施の形態３）
本実施の形態では、ＵＥの接続先アクセス網の特性に関する情報に加え、ＵＥのハンドオーバの可能性の有無を示す情報を用いて、コーデックモード（又はコーデックモードセット）選択が行われる。更に、本実施の形態では、通話途中でハンドオーバの可能性の有無に変更が生じた場合には、コーデックモード（又はコーデックモードセット）の変更が行われる。
図１３は、本実施の形態に係る端末（ＵＥ１００、１０２）の構成を示すブロック図である。なお、図１３において、図７と同一構成である部分には同一の符号を付してその説明を省略する。図１３に示す端末は、図７に示す端末の構成部に加え、状態解析部８１２及びモード変更部８１４が追加される。
図１３に示す端末において、状態解析部８１２は、自機の種類及び状態等から、自機にハンドオーバの可能性があるか否かを解析（判断）する。例えば、ＵＥが電話会議システム用の据え置き型端末である場合、状態解析部８１２は、自機のハンドオーバの可能性は低いと判断する。また、自機が小型のＵＥであっても据え置き型の機器、スピーカ及びマイクロフォン等に接続されている状態の場合、状態解析部８１２は、自機のハンドオーバの可能性は低いと判断する。あるいは、自機が電話会議モード設定部（図示せず）を具備し、ユーザにより明示的に（ＵＥのユーザインタフェースの操作により）電話会議モードが選択された場合、状態解析部８１２は、自機のハンドオーバの可能性は低いと判断する。状態解析部８１２は、通信開始時の解析結果を示す情報を、シグナリング生成部６１０に出力する。これにより、当該解析結果（自機のハンドオーバの可能性の有無を示す情報）は、シグナリングメッセージに付加されて、通信相手に通知される。
また、状態解析部８１２は、通信途中における自機の状態を解析し、通信途中において自機の状態が変化した場合、自機の状態の変化内容をモード変更部８１４に出力する。例えば、据え置き型の機器、スピーカ及びマイクロフォン等に接続されて通信しているＵＥが、これらの機器と非接続になった場合、状態解析部８１２は、自機とこれらの機器とが非接続になったことをモード変更部８１４に出力する。
モード変更部８１４は、状態解析部８１２から入力される情報に基づいて、現在使用しているコーデックモード（又はコーデックモードセット）の変更を行う。なお、通信相手へのコーデックモード（又はコーデックモードセット）変更の要求は、呼制御のためのシグナリングメッセージを送信することで実施してもよい。また、かかる要求は、通信データのヘッダ（例えばＲＴＰヘッダ、ＲＴＰペイロードのヘッダ部、通信データの制御情報、又は、ＲＴＣＰ（RTP Control Protocol））にコーデックモード（又はコーデックモードセット）の変更内容を示す変更情報を追加することで実施してもよい。
次に、図１３を用いて、本実施の形態に係る端末（ＵＥ１００及びＵＥ１０２）における処理について詳細に説明する。
以下の説明では、実施の形態１と同様、図４又は図５において、現在、ＵＥ１００がＨｅＮＢ４００又はＨｅＮＢ５００に接続され、ＵＥ１０２がＨｅＮＢ４０２又は５０２に接続されており、ＵＥ１００からＵＥ１０２に対して電話をかけるとする。
ＵＥ１００の状態解析部８１２は、自機の種類及び状態等から、自機にハンドオーバの可能性があるか否かを解析（判断）する。
ＵＥ１００のシグナリング生成部６１０は、解析結果を示す情報を、呼制御のためのシグナリングメッセージの一部、例えばＳＤＰオファー（又はＳＩＰヘッダ）に記述する。また、シグナリング生成部６１０は、実施の形態１と同様、通信相手（ＵＥ１０２）の接続先無線アクセス網の特性を考慮したコーデックモード（又はコーデックモードセット）の候補を作成する。また、シグナリング生成部６１０は、実施の形態１と同様、通信相手（ＵＥ１０２）のハンドオーバの可能性等のＵＥ１０２に関する各情報の全て又は一部の可能性を考慮したコーデックモード（又はコーデックモードセット）の候補を作成する。これらの情報を含むシグナリングメッセージ（SIP INVITEメッセージ）は、無線送信部６０２を介して通信相手（ＵＥ１０２）に送信される。
ＳＤＰオファーの記述の一例を図１４に示す。例えば、ＵＥ１００の状態解析部８１２においてＵＥ１００のハンドオーバの可能性が低いと判断された場合、図１４に示すように、ＳＤＰオファー内には、例えば“a=handover:low”と記述される。なお、ハンドオーバの可能性の有無を“low”又は“High”と記述する代わりに、数値又は記号等で示してもよい。例えば“０ｘ００”を「ハンドオーバの可能性高い」とし、“０ｘ０１”を「ハンドオーバの可能性低い」とした場合には、ハンドオーバの可能性が低い状態は、“a=handover:0x01”と記述される。記述方法は、これらに限らず、別の記述方法でもよい。
次いで、本実施の形態における、コーデックモードセット（ＵＥのハンドオーバの可能性が低い場合のコーデックモードセットを含む）と、コーデックモードセットを示す数値（番号）との対応関係を図１５に示す。図１５では、図９に示す対応関係（“０ｘ００”、“０ｘ０１”、“０ｘ０２”）に加え、“０ｘ０３”が設定されている。図１５に示す“０ｘ０３”は、電話会議通信を意味し、ビットレートが100kbps前後であり、高い（High）アルゴリズム遅延であるコーデックモードセットに対応する。
一方、ＵＥ１０２（着呼側）の情報比較部６０６は、端末状態（ＵＥ１００の状態解析部８１２での解析結果）及び接続先無線アクセス網の特性に関する情報と、自機の端末状態（ＵＥ１０２の状態解析部８１２での解析結果）及び接続先無線アクセス網の特性に関する情報とを比較する。前者は、ＵＥ１００から送信されたシグナリングメッセージ（SIP INVITEメッセージ）に含まれる情報である。具体的には、情報比較部６０６は、比較結果に基づいて、自機（ＵＥ１０２）と通信相手（ＵＥ１００）との間の通信形態（どのような通信が可能か）を判断する。例えば、情報比較部６０６は、ＵＥ１００、１０２が共にＨｅＮＢに接続され、かつ、ハンドオーバの可能性が無い場合には、固定電話のような通信（高品質な通信）が可能と判断する。
ＵＥ１０２のモード決定部６０８は、情報比較部６０６での判断結果（自機と通信相手との間の通信形態）に基づいて、コーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）を決定する。
本実施の形態における情報比較部６０６及びモード決定部６０８における処理の一例を図１６に示す。図１６は、情報比較部６０６及びモード決定部６０８における処理の流れを示すフロー図である。なお、図１６において、図１０と同一処理を行う部分には同一の符号を付してその説明を省略する。
図１６において、自機（ＵＥ１０２）及び通信相手（ＵＥ１００）の互いの接続先が同一ローカル網内である（ＳＴ１０５：ＹＥＳ）。この場合、情報比較部６０６は、ＳＴ２０１において、自機のハンドオーバの可能性があるかを判断し、ＳＴ２０２において通信相手のハンドオーバの可能性があるかを判断する。自機のハンドオーバの可能性がある場合（ＳＴ２０１：ＹＥＳ）、又は、通信相手のハンドオーバの可能性がある場合（ＳＴ２０２：ＹＥＳ）、ＳＴ１０７では、モード決定部６０８は、“ＨｅＮＢ＋ローカル網通信（０ｘ０２）”に対応するコーデックモードセットを選択する。
一方、自機のハンドオーバの可能性が無く（ＳＴ２０１：ＮＯ）、かつ、通信相手のハンドオーバの可能性が無い場合（ＳＴ２０２：ＮＯ）、ＳＴ２０３では、モード決定部６０８は、“電話会議通信（０ｘ０３）”に対応するコーデックモードセットを選択する。
このように、モード決定部６０８は、情報比較部６０６で自機と通信相手との間で良好な品質の通信経路を確保できると判断されたか否か、及び、自機と通信相手との双方でハンドオーバの可能性が無いか否かに基づいて、自機と通信相手との間の通信で使用するコーデックモードセットを選択する。より具体的には、良好な品質の通信経路を確保できると判断され（例えば、図１６に示すＳＴ１０１：ＹＥＳかつＳＴ１０３：ＹＥＳ）、かつ、双方でハンドオーバの可能性が無い場合（例えば、図１６に示すＳＴ２０１：ＮＯかつＳＴ２０２：ＮＯ）、選択可能なコーデックモードセットのうち、最も高品質かつ長遅延であるコーデックモードセット（０ｘ０３）を選択する。
ＵＥ１０２のシグナリング生成部６１０は、モード決定部６０８で選択されたコーデックモードセットを、呼制御のためのシグナリングメッセージ（例えば、SIP 183 Session Progressメッセージ）の一部、例えばＳＤＰアンサーに記述する。この際、シグナリング生成部６１０は、ＵＥ１０２の接続先ＨｅＮＢ４０２（又は５０２）のＣＳＧ ＩＤ又は基地局ＩＤ、及び、ＵＥ１０２のハンドオーバの可能性の有無を、ＳＤＰアンサー又はＳＩＰヘッダに記述してもよい。
ＳＤＰアンサーの記述の一例を図１７に示す。例えば、ＵＥ１００の接続先無線アクセス網のＣＳＧ ＩＤが図１４に示す“Panasonic-femto”であり、ＵＥ１０２の接続先無線アクセス網のＣＳＧ ＩＤが“Panasonic-femto”であるとする（図１６のＳＴ１０１、ＳＴ１０３：ＹＥＳ）。また、ＣＳＧ ＩＤ（“Panasonic-femto”）の無線アクセス網とＣＳＧ ＩＤ（“Panasonic-femto”）の無線アクセス網とが同一ローカル網内であるとする（図１６のＳＴ１０５：ＹＥＳ）。更に、ＵＥ１００及びＵＥ１０２の双方のハンドオーバの可能性が低いとする（図１６のＳＴ２０１、ＳＴ２０２：ＮＯ）。この場合、ＵＥ１０２の情報比較部６０６は、ＵＥ１００及びＵＥ１０２が互いに同一企業内のローカル網のＨｅＮＢに接続され、かつ、ＵＥ１００及びＵＥ１０２が共にハンドオーバの可能性が無いと判断する。そして、モード決定部６０８は、“電話会議通信（０ｘ０３）”に対応するコーデックモードセットを選択する。よって、図１７に示すＳＤＰアンサーには、選択されたコーデックモードセットとして“０ｘ０３”が記述される。
なお、図１７に示すように、ＵＥ１０２の接続先無線アクセス網の特性に関する情報（Panasonic-femto）、及び、ＵＥ１０２のハンドオーバの可能性の有無（handover：low）をＳＤＰアンサーに記述してもよい。
ＵＥ１０２のシグナリング生成部６１０で生成されたシグナリングメッセージ（例えば、SIP 183 Session Progressメッセージ）は、無線送信部６０２を介してＩＭＳ網１２６経由でＵＥ１００に送信される。
ＵＥ１００のモード決定部６０８は、無線受信部６００を介して、ＵＥ１０２から送信されたシグナリングメッセージを受け取ると、ＳＤＰアンサーに記述されている内容に基づいて、コーデックモードセットを決定する。図１７の一例では、ＵＥ１００のモード決定部６０８は、“電話会議通信（０ｘ０３）”に対応するコーデックモードセットを決定する。この際、ＵＥ１００の通信相手（ＵＥ１０２）の接続先のＣＳＧ ＩＤ又は基地局ＩＤ、又は、ハンドオーバの可能性の有無を、参照情報として用いてもよい。
また、通信途中でＵＥ１００又はＵＥ１０２の状態が変化した場合、モード変更部８１４は、コーデックモードセットの変更を行ってもよい。例えば、現在のコーデックモードセットが“電話会議通信（０ｘ０３）”に対応するものであるとする。この場合、モード変更部８１４は、ＲＴＰペイロードのヘッダ部又は、ＲＴＣＰフィードバックのコーデックモードリクエストフィールドに、変更後のコーデックモードセット（例えば“ＨｅＮＢ配下＋ローカル網通信（０ｘ０２）”を記載する（例えば、図１８参照）。そして、モード変更部８１４は、通信相手に変更を促すと同時に、自機のコーデックモード（又はコーデックモードセット）も変更する。また、変更先コーデックモードセットではなく、変更先ビットレート、遅延モード、チャンネル数等の個別のコーデックモードがコーデックモードリクエストフィールドに直接指定されてもよい。また、この変更先ビットレート、遅延モード、チャンネル数等は複数のコーデックモード（又はコーデックモードセット）を跨いでもよい。
これにより、ＵＥでは、無線アクセス網の特性のみでなく、ハンドオーバの可能性の有無を用いることで、実施の形態１と比較して、自機と通信相手である相手端末との間の通信形態をより細かく判断することが可能となる。よって、ＵＥでは、判断された上記通信形態に応じて、より高品質なコーデックモード（又はコーデックモードセット）を選択することができる。
更に、ＵＥは、通信中の自機又は相手端末において、ハンドオーバの可能性が変化した場合、現在使用しているコーデックモード（又はコーデックモードセット）を変更する。すなわち、ＵＥは、通信途中であっても、自機又は通信相手のいずれかの状態が変化した場合、つまり、自機と通信相手との間の通信形態が変化し得る場合には、当該変化に応じて、コーデックモード（又はコーデックモードセット）を変更する。これにより、ＵＥでは、通信途中における通信形態の変化に応じた適切なコーデックモード（又はコーデックモードセット）を使用することができる。
よって、本実施の形態によれば、実施の形態１と比較して、端末間の通信経路の状況をより細かく判断することができ、より適切なコーデックモード（又はコーデックモードセット）を選択できる。
（実施の形態４）
本実施の形態では、上記実施の形態１〜３の例で挙げたコーデック方式のように、ビットレート等のコーデックモードの種類が多いコーデック方式の場合に推奨される、ＲＴＰペイロードフォーマットの一例を以下に示す。なお、本実施の形態におけるＲＴＰペイロードフォーマット例は、上記実施の形態１〜３に記載したネゴシエーション方法あるいはコーデックモード（又はコーデックモードセット）の選択が行われた場合に限定されるものではない。
ここでは、コーデックの１つの方式（又はモード）、又は、通話等の１つのリアルタイムセッションの中で互いに切り替えて使うことのできる複数の方式（又はモード）におけるビットレートとして、方式Ｘ（仮にマルチレートコーデックとする）では１２、２４ｋｂｐｓがサポートされているものとする。そして、方式Ｙ（仮にスケーラブルコーデックとする）では、かかるビットレートとして、基本部８、１２、２４ｋｂｐｓ、第一拡張部４、１２ｋｂｐｓ、第二拡張部８ｋｂｐｓがサポートされているものとする。ここで方式Ｘ、方式Ｙは異なるコーデックであってもよいし、単一のコーデックの中の異なるモードであってもよい。
ここで、スケーラブルコーデックの第一拡張部及び第二拡張部としては、例えばSuper Wideband拡張及びFull Band拡張であってもよく、又は、Enhance対応の拡張又はステレオ拡張等であってもよい。また、方式Ｘ及び方式Ｙの双方とも、遅延モードとしてはそれぞれ異なる遅延Ａ及び遅延Ｂの両方、又はいずれか一方を持つとする。また、チャンネル数も１チャンネル（モノ）及び２チャンネル（ステレオ）の２つ、又は１チャンネル（モノ）のみをサポートしているとする。
図１９は、本実施の形態におけるコーデックモード（本例ではビットレート及びこの組み合わせ）の番号対応付け（Frame Type Index）及びＲＴＰペイロードフォーマットを示す第１の例である。
図１９Ａに示すように、ビットレートの全ての組み合わせに対して異なるFrame Type Indexがそれぞれ割り当てられる。図１９Ｂは、第１の例でのＲＴＰペイロードフォーマットの一例である。図１９Ｂに示すように、ＲＴＰペイロードのデータ部に加え、ＲＴＰペイロードのヘッダ部に、ＲＴＰペイロードの情報として、Frame Type Index及びＱビットが付加される。ここで、ＲＴＰペイロードのデータ部は、１ｆｒａｍｅ分のエンコードされたデータ及びＲＴＰペイロード長を調整するために加えられるパディングビット（padding bit）を含む。ＲＴＰペイロードのヘッダ部に含まれるFrame Type Indexは、図１９Ａのどの組み合わせが使われているかを示す。ＲＴＰペイロードのヘッダ部に含まれるＱビットは、非特許文献１に記載のＱビットと同等であり、Frame QualityのIndicatorである。
遅延モードに関しては、ＲＴＰペイロードのヘッダ部に含ませても、含ませなくてもよい。遅延モードをＲＴＰペイロードのヘッダ部に含ませる場合には、図１９Ａの表の中に遅延モードを含ませてFrame Type Indexを割り当ててもよい。そして、ＲＴＰペイロードフォーマットの中に遅延モードを表すビット（例えば遅延Ａは“０”、遅延Ｂは“１”）を含ませてもよい。
図１９Ｂに示すように、第１の例でのＲＴＰペイロードフォーマットには、非特許文献１に記載されているCodec Mode Requestのようなフィールドを持たない。このフィールドを持たないことによりＲＴＰペイロードのサイズを抑えることができる。ただし、ＲＴＰペイロードのサイズに問題がない場合には（すなわち、ＲＴＰペイロードフォーマットに数ビットを付け加えても問題が無い場合には）、Codec Mode Requestのようなフィールドを含んでもよい。なお、Codec Mode Requestのフィールドを持たない場合で、通信相手にコーデックモード（又はコーデックモードセット）の変更を求める際には、例えば、ＲＴＣＰを用いてもよい。
また、複数のフレーム（１フレーム分のエンコードされたデータ）を同時に（一つのＩＰパケットにして）送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットが、ＲＴＰペイロードのヘッダ部に含まれてもよい。
またヘッダに含まれるビット及びフィールドは、本例に挙げられているものに限らない。
また、本例では、図１９Ａに示すように方式Ｘ及び方式Ｙの各ビットレート、又はビットレートの組み合わせに対し一連のFrame Type Indexを与え、方式Ｘ及び方式Ｙがあたかも同一のコーデック方式であるかのように扱うことのできる例を挙げた。しかし、方式Ｘ及び方式Ｙに対して、それぞれ別にFrame Type Index及びＲＴＰペイロードフォーマットが与えられ、独立して利用されるものであってもよい。
図２０は、本実施の形態におけるコーデックモード（本例ではビットレート）の番号対応付け（Frame Type Index）及びＲＴＰペイロードフォーマットを示す第２の例である。
図２０Ａに示すように、ビットレートのみに対してFrame Type Indexがそれぞれ割り当てられる。なお、図２０Ａに示すFrame Type Indexはビットレートのみを指定し、どのコーデック又はコーデックの組み合わせが使われているかは記述しない。かかる組み合わせには、図１９Ａ（第１の例）の組み合わせのうち、それぞれのビットレートに当てはまるコーデックモードが全て該当する。例えば、図２０Ａにおいて、Frame Type Indexの値が１（ビットレート：１２ｋｂｐｓ）であったとする。この場合、フレームの内容は、図１９Ａの中のビットレートが１２ｋｂｐｓとなるコーデックに対応するFrame Type Index“０”（方式Ｘの１２ｋｂｐｓ）、“３”（方式Ｙの１２ｋｂｐｓ）又は“５”（方式Ｙで基本部８ｋｂｐｓ、及び第一拡張部４ｋｂｐｓ）の組みあわせの可能性がある。ただし、図２０Ａが方式Ｙのコーデックのみに対応している場合には、Frame Type Index“３”（方式Ｙの１２ｋｂｐｓ）、又は、Frame Type Index“５”（方式Ｙで基本部８ｋｂｐｓ、及び第一拡張部４ｋｂｐｓ）の２通りの可能性となる。これらのコーデック方式及びビットレートの組み合わせのうち、どの組み合わせを選ぶかはエンコーダが決定する。エンコーダが決定した組み合わせを表す情報は、エンコードされたデータの中に含まれていてもよい。
図２０Ｂは、第２の例でのＲＴＰペイロードフォーマットの一例である。図２０Ｂに示すように、ＲＴＰペイロードのデータ部に加え、ＲＴＰペイロードのヘッダ部に、ＲＴＰペイロードの情報として、Frame Type Index、Ｑビット、Codec Mode Request及びＲビットが含まれる。ＲＴＰペイロードのデータ部は、１ｆｒａｍｅ分のエンコードされたデータ及びＲＴＰペイロード長を調整するために加えられるパディングビット（padding bit）を含む。ＲＴＰペイロードのヘッダ部のFrame Type Indexは、図１９Ａのどのビットレートが使われているのかを示す。Ｑビットは非特許文献１に記載のＱビットと同等である。
Codec Mode Requestは通信相手にコーデックモード（ビットレート）の変更をリクエストするフィールドであり、図２０ＢのFrame Type Indexが使われる。Codec Mode Requestを受け取った通信相手のエンコーダは指定されたビットレートを与えるコーデックの組み合わせのうち最適なものを選択しエンコードする。例えば、Codec Mode Requestに示されるFrame Type Indexの値が１（１２ｋｂｐｓ）であった場合、フレームの内容は、図１９Ａの中のFrame Type Index“０”、“３”又は“５”の組み合わせの可能性がある。ただし、図２０Ａが方式Ｙのコーデックのみに対応している場合には、Frame Type Index“３”（方式Ｙの１２ｋｂｐｓ）、又は、“５”（方式Ｙで基本部８ｋｂｐｓ、及び第一拡張部４ｋｂｐｓ）の２通りの可能性となる。エンコーダはこれらのうち最適と判断した組み合わせを用いてエンコードを実行する。
図２０Ｂに示すＲビットはCodec Mode Requestで相手にリクエストしきれない要求を示すフィールドである。例えば、Ｒビットはチャンネル数の指定（例えば、モノ＝“０”、ステレオ＝“１”）又は遅延の指定（例えば、遅延Ａ＝“０”、遅延Ｂ＝“１”）等を示す。Ｒビットは例えばチャンネル数と遅延両方を示すため、２ビットまたはそれ以上であってもよい。なお、このＲビットは、通信中に遅延あるいはチャンネル数を切り替えない場合にはＲＴＰペイロードのヘッダ部に存在しなくてもよい。
また、遅延モードに関しては、図２０Ａの表の中に遅延モードも含ませてFrame Type Indexを割り当ててもよい。例えば、Frame Type Index“０”から“８”までに割り当てられているビットレートに関しては遅延Ａを割り当てる。更に、図２０Ａに示すFrame Type Indexの値を３１までに拡張して、Frame Type Index“１１”から“１９”までに割り当てられているビットレートに関しては遅延Ｂを割り当てる（図示せず）。また、図２０Ａの表の中に遅延モードを含ませない場合には、エンコード側（自分側）に対してＲＴＰペイロードのヘッダ部の中に遅延モードを示すビットを含ませてもよい。また、エンコード側（自分側）のチャンネル数に関しても、遅延モードと同様に、図２０Ａの表の中に（Frame Type Indexの値を拡張して）含ませてもよい。また、ＲＴＰペイロードのヘッダ部の中にチャンネル数の指定を示すビットを含ませてもよいし、エンコードされたデータそのものに含ませてもよい。
第２の例のように、コーデックのビットレートだけを指定することにより、エンコード側で最適なエンコードを行うことができ、かつ、ＲＴＰペイロードのヘッダ部の中のFrame Type Index及びCodec Mode Requestのビット数を少なくすることができる。また、ＲＴＰペイロードのヘッダ部にCodec Mode Requestを含めることにより、通信相手に、コーデックモード（又はコーデックモードセット）の変更要求を迅速に送信することができる。ただし、通信相手に対する迅速なコーデックモード（又はコーデックモードセット）変更の要求が必要ない場合で、Codec Mode Request及びＲビットが必要な場合には、これらをＲＴＰペイロードのヘッダ部に含めず、ＲＴＣＰに含めて相手に通知してもよい。また、複数のフレーム（１フレーム分のエンコードされたデータ）を同時に（一つのＩＰパケットにして）送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットがＲＴＰペイロードのヘッダ部に含まれてもよい。また、ＲＴＰペイロードのヘッダ部に含まれるビット及びフィールドは、本例に挙げられているものに限らない。
図２１は、本実施の形態におけるコーデックモード（本例ではビットレートとその種類）の番号対応付け（Frame Type Index）及びＲＴＰペイロードフォーマットを示す第３の例である。
図２１Ａに示すように、マルチレートコーデック、スケーラブルコーデックの基本部、及び、スケーラブルコーデックの各拡張部のそれぞれに異なるFrame Type Indexが割り当てられる。
図２１Ｂは、第３の例でのＲＴＰペイロードフォーマットの一例である。
第３の例では、図２１に示すように、スケーラブルコーデックにおけるレイヤ（基本部、第一拡張部、第二拡張部）毎にＲＴＰペイロードのヘッダ部がつけられる。図２１Ｂにおいて、ＲＴＰペイロードのヘッダ部に含まれるＣビットは後続する拡張部が存在するか否かを示す。このように、基本部と各拡張部は別々のＩＰパケットとして送られてもよい。これにより、ネットワーク又は無線アクセス区間等が混雑している場合、プライオリティの低い拡張部のＩＰパケットを破棄できるという利点がある。
なお、各ＲＴＰペイロードのヘッダ部、又は基本部のＲＴＰペイロードのヘッダ部のみに、Codec Mode Request及びＱビットを付加してもよい。遅延モードの記述及び通信相手に対するコーデックモード（又はコーデックモードセット）の変更要求の方法に関しては、第１の例（図１９）及び第２の例（図２０）の場合と同様である。また、複数のフレームを同時に（一つのＩＰパケットにして）送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットが、ＲＴＰペイロードのヘッダ部に含まれてもよい。また、ＲＴＰペイロードのヘッダ部に含まれるビット及びフィールドは、本例に挙げられているものに限らない。
また、本例では、図２１Ａに示すように方式Ｘ（例えばマルチレートコーデック）及び方式Ｙ（例えばスケーラブルコーデック）の各ビットレート、又はビットレートの種類に対して、一連のFrame Type Indexを与える例を挙げた。すなわち、方式Ｘ及び方式Ｙがあたかも同一のコーデック方式であるかのように扱うことのできる例を挙げた。しかし、方式Ｘ及び方式Ｙに対して、それぞれ別にFrame Type Index及びペイロードフォーマットが与えられ、独立して利用されるものであってもよい。
尚、本実施の形態において、Ｑビットが含まれる例を示したが、Ｑビットは無くてもよい。
（実施の形態５）
本実施の形態では、ＲＴＰペイロード長が複数の固定長に限定される場合で、かつ、一つのビットレート（若しくはその周辺のビットレート）を表す組み合わせが複数存在し得る場合における、好ましいＲＴＰペイロードフォーマット及びその処理方法に関する。これは、例えば実施の形態４で説明した方式Ｙの場合である。
ＲＴＰペイロード長が複数の固定長に限定される例としては、携帯電話網の無線区間のように、伝送ブロックサイズが決められている場合がある。
図２２は、本実施の形態におけるコーデックモードの番号対応付け（Frame Type Index）及びＲＴＰペイロードフォーマットを示す第１の例である。
第１の例では、グロスビットレート（Gross Bit rate）に対して番号対応付け（Frame Type Indexとの対応付け）が行われる。ここでは、グロスビットレートは、ＲＴＰペイロード長を１秒あたりのキロビット数（kbps：kilo bit per second）に変換したものとする。グロスビットレートに対する番号対応付けの例を図２２Ａに示す。
また、第１の例では、ＲＴＰペイロードのヘッダ部に含む情報又は情報の一部（例えばCodec Mode Requestフィールド）を、通話開始時のネゴシエーション（ＳＤＰオファー及びアンサー）によって選択してもよい。この時、実施の形態１及び３でコーデックモード（又はコーデックモードセット）（使用されるビットレートの範囲、遅延モード等）が選択される際に、この選択されたコーデックモード（又はコーデックモードセット）に合わせて、ＲＴＰペイロードのヘッダ部に含まれる情報又は情報の一部が選択されてもよい。
例えば、図９及び図１５に記載の“通常通信”等、利用されるビットレートの範囲が低い場合には、ＲＴＰペイロードのヘッダ部の比率を小さく抑えるために、Codec Mode RequestフィールドをＲＴＰペイロードのヘッダ部に含めないという選択が行われる。
図２２Ｂは、通話開始時のネゴシエーション、又は、サービスオペレータ等のポリシー等によって予めCodec Mode RequestフィールドをＲＴＰペイロードのヘッダ部に含めないと決定された際の、ＲＴＰペイロードフォーマットの一例を示す。また図２２Ｃは、通話開始時のネゴシエーション、又は、サービスオペレータ等のポリシー等によって予めCodec Mode RequestフィールドをＲＴＰペイロードのヘッダ部に含めると決定された際の、ＲＴＰペイロードフォーマットの一例を示す。図２２Ｂ及び図２２Ｃにおいて、ＲＴＰペイロードのヘッダ部に含まれるＱビットは、非特許文献１に記載のＱビットと同等であり、Frame QualityのIndicatorである。
エンコーダ側は、Frame Type Indexと、ＲＴＰペイロードのヘッダ部の長さより決定されるＲＴＰペイロードのデータ部の長さに応じたビットレートと、その組み合わせを、対応するコーデック方式がサポートするビットレート及びその組み合わせの中から決定する。ここで、ＲＴＰペイロードのヘッダ部の長さは、通話開始時のネゴシエーション又はサービスオペレータ等のポリシー等によって予め決められたものである。エンコーダが決定した組み合わせを表す情報は、エンコードされたデータの中に含まれていてもよい。なお、サービスオペレータ等のポリシー等により、通信開始から終了までコーデックビットレートの変更が行われない場合には、ＲＴＰペイロードのヘッダ部にFrame Type Indexを含まなくてもよい。この場合の一定のビットレートは、通話開始時のネゴシエーションによって決められてもよいし、サービスオペレータ等のポリシー等によって予め決められていてもよい。
図２３は、ＲＴＰペイロードのヘッダ部に含まれる情報が通予め定められていた場合における、コーデックモードの番号対応付け（Frame Type Index）及びＲＴＰペイロードフォーマットの例を示す（本実施の形態の第２の例とする）。これは、つまり、本実施の形態の第１の例（図２２）のようにＲＴＰペイロードのヘッダ部に含まれる情報が通信開始時のネゴシエーションによって決定されるのではなく、ＲＴＰペイロードのヘッダ部の長さが予め決められていた場合である。
本例では、図２３Ａに示すように、ＲＴＰペイロードのデータ部の長さを１秒あたりのキロビット数（kbps：kilo bit per second）に変換して得られるビットレートに対し、番号対応付け（Frame Type Indexとの対応付け）が行われる。本例では、２０ミリ秒につき１ｆｒａｍｅ分のエンコードされたデータがＲＴＰパケットとなる。すなわち、１秒間に５０個のＲＴＰパケットが発生する。また、ＲＴＰペイロードのヘッダ部の長さは、図２２Ａに示すグロスビットレートが7.2kbps、8kbps、9.6kbpsの場合は５ビットとし、グロスビットレートが13.2kbps、16.4kbps、24.4kbpsの場合は８ビットとしている。なお、１秒あたりのＲＴＰパケットの数、ペイロードのヘッダ部の長さ、及び、グロスビットレートとヘッダ部の長さとの対応付けはこれらに限らない。
図２３Ｂ及び図２３Ｃは、Codec Mode Requestフィールドを含む場合、及び、含まない場合のＲＴＰペイロードフォーマットの例をそれぞれ示す。本例では、ＲＴＰペイロードのヘッダ部に含まれ得る情報である、Frame Type Indexフィールドを４ビットとし、Ｑビットフィールドを１ビットとし、Codec Mode Requestフィールドを３ビットとした場合の例を示す。
Frame Type Indexフィールドには、図２３Ａの中で該当するFrame Type Indexが入る。Ｑビットフィールドは非特許文献１に記載のＱビットと同等である。また、Codec Mode Requestフィールドには図２３ＡのFrame Type Indexのうち“０”〜“５”（すなわち、通信相手へのビットレート変更を要求するのに必要な情報のみ）が入る。また、Codec Mode Requestフィールドには、通信相手のエンコーダに対するビットレート変更が無いことを示す値として“６”あるいは“７”を使用してもよい。なお、本例のＲＴＰペイロードのヘッダ部の各フィールド長あるいは該当する値は、これに限らなくてもよいし、本例のＲＴＰペイロードのヘッダ部に含まれる情報（フィールド）もこれに限らない。
本実施の形態の第１の例（図２２）、第２の例（図２３）では、グロスビットレートあるいはグロスビットレートに応じたＲＴＰペイロードのデータ部の長さだけをFrame Type Indexとして指定する、このようにすることにより、エンコード側でＲＴＰペイロードのデータ部の長さに応じた最適なエンコードを行うことができ、かつ、ＲＴＰペイロードのヘッダ部の中のFrame Type Indexのビット数を少なくすることができる。
また、ＲＴＰペイロードのヘッダ部の長さを調整可能にする。このようにすることにより、伝送路の特性等によって決められるビットレートの範囲（実施の形態１〜３のコーデックモード（又はコーデックモードセット））等に応じてＲＴＰペイロードのデータ部の長さを決定し、好適なエンコードを行うことができる。なお、Codec Mode RequestフィールドをＲＴＰペイロードのヘッダ部に含めない場合で、通信相手側エンコーダへのビットレートの変更通知が必要な場合には、ＲＴＣＰにより変更通知が行われる。
（実施の形態６）
本実施の形態では、各ＵＥに対して通信／通話サービスを提供するオペレータのポリシーをコーデックモード（又はコーデックモードセット）選択に使用する方法について説明する。
オペレータのポリシーとしては、例えば、優先して使用されるコーデック（コーデックの方式）、優先して使用されるコーデックビットレート、優先して使用されるサンプリングレート、優先して使用されるオーディオ帯域（例えば、ＮＢ，ＷＢ，ＳＷＢ，ＦＢ）、優先して使用されるアルゴリズム遅延、及び、優先して使用されるチャンネル数等が挙げられる。また、オペレータのポリシーとしては、他にも、例えば、セッション途中でのビットレート又はチャンネル数の切り替えを許可するか否か、Source-Controlled Variable Bit Rate（ＶＢＲ）オペレーション（例えば、「3GPP2 C.S0052-A Version 1.0 “Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR-WB)”」を参照）を許可するか否か、回線交換網へのハンドオーバ（例えば、「3GPP TS23.216 v9.6.0 “Single Radio Voice Call Continuity (SRVCC); Stage 2”」を参照）を許可するか否か、及び、非特許文献２に記載のような冗長フレームを許可するか否か等が挙げられる。
ＵＥは、これらオペレータのポリシーの全て又は一部を、通話開始前、すなわち、図２に示すＳＴ１１の処理が行われる前までに取得し、取得したポシリーに基づいてＳＤＰオファーを生成する。
ポリシー（全て、又は一部）の取得方法として、例えば、オペレータのネットワークからＵＥに送られてくるシグナリングにポリシー（全て、又は一部）が含まれるようにし、かかるシグナリングから取得する手法を採用してもよい。
このシグナリングは、例えば、ＳＩＢ（System Information Block。例えば、「3GPP TS 36.331 v10.0.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC) Protocol specification"」を参照）であってもよい。また、このシグナリングは、例えば、ＲＲＣ（Radio Resource Control）コネクション確立の際のシグナリング（例えば、「3GPP TS 36.331 v10.0.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC) Protocol specification"」に記載のRRC Connection Setup）であってもよい。
また、ポリシーは、例えば、Registerに対する応答メッセージ（200OK）等のＩＭＳのＳＩＰシグナリング（例えば「3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (IMS) Stage 2"」を参照）と一緒に送られてきてもよい。また、ポリシー、例えば、Ｐ−ＣＳＣＦ検索の応答メッセージに含まれていてもよい。ポリシーが応答メッセージを使ってＵＥに送られてくる場合、ＵＥからの要求メッセージ（例えば「3GPP TS 36.331 v10.0.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC) Protocol specification"」に記載のRRC Connection Request、又は、「3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (IMS) Stage 2"」に記載のRegister）に、オペレータのポリシーを応答メッセージで受け取る能力のあることを示すパラメータを付加してもよい。
また、ポリシーの他の取得方法として、ＵＥは、ＵＥがローカルに保持するポリシーに関する情報の中から、オペレータのネットワークからＵＥに送られてくる情報に基づいて、オペレータのポリシー（全て、又は一部）を決定してもよい。例えば、ＵＥは、オペレータ毎のポリシー（全て、又は一部）をローカルに保持しており、或るオペレータのネットワークに接続した際に当該オペレータに関する情報（オペレータ情報）を取得し、ローカルに保持しているデータベースの中から該当するオペレータのポリシー（全て、又は一部）を選択する。ＵＥがオペレータのネットワークに接続した際に取得するオペレータ情報は、例えば、Ｃｅｌｌ ＩＤ（例えば、「3GPP TS 23.003 v10.0.0, "Numbering, addressing and identification (Release 10)"」を参照）から取得される。
また、ポリシーの他の取得方法として、ＵＥがオペレータのネットワークに接続した際に送られてくる、ユーザ毎に通話用に許されるＱｏＳ情報（例えば、「3GPP TS 23.401 v10.2.1, " Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 10)"」を参照）に基づいて、ＵＥが、通話に優先して使われるコーデックビットレート等を選択してもよい。
次に、オペレータから取得されたポリシーに基づくＳＤＰの生成方法の例を示す。
図２４は発呼側ＵＥが接続するオペレータ（オペレータＡ）のポリシー（図２４Ａ）、及び、発呼側ＵＥにおけるＳＤＰオファー生成例（図２４Ｂ）を示す。また、図２５は着呼側ＵＥが接続するオペレータ（オペレータＢ）のポリシー（図２５Ａ）、及び、着呼側ＵＥにおけるＳＤＰアンサー生成例（図２５Ｂ）を示す。なお、図２４及び図２５において、ポリシー又はＳＤＰに記述されない項目、値等に関しては、例えば非特許文献２に記載された各方式のデフォルトが適応される。また、図２４及び図２５に示すポリシー及びＳＤＰの記述方法は一例であり、他の記述方法であってもよい。
例えば、図２４Ａに示すように、オペレータＡのポリシーには、「コーデック：方式１、オーディオ帯域：ＳＷＢ、ビットレート：［12kbps，24kbps］及びＶＢＲ：可（ＶＢＲを許可）」というポリシー（以下、ポリシーＡ１と呼ぶ）が含まれる。また、オペレータＡのポリシーには、「コーデック：方式１、オーディオ帯域：ＷＢ、ビットレート：［12kbps，24kbps］及びＶＢＲ：可（ＶＢＲを許可）」というポリシー（以下、ポリシーＡ２と呼ぶ）が含まれる。更に、オペレータＡのポリシーには、「コーデック：方式２、オーディオ帯域：ＮＢ、ビットレート：［8kbps，12kbps］及びＶＢＲ：不可（ＶＢＲを許可しない）」というポリシー（以下、ポリシーＡ３と呼ぶ）が含まれる。
そこで、発呼側ＵＥは、発呼側ＵＥに対して通信又は通話サービスを提供するオペレータのポリシー（ここでは、図２４Ａに示すオペレータＡのポリシー）の少なくとも一部に対応するコーデックモード（又はコーデックモードセット）の候補を含むＳＤＰオファーを作成する。
例えば、図２４Ｂに示すように、発呼側ＵＥは、図２４Ａに示すポリシーＡ１の一部である、コーデック：方式１、オーディオ帯域：ＳＷＢ、ビットレート：｛12,24｝kbpsに対応するコーデックモードセットの候補を選択する。具体的には、図２４Ｂに示す、コーデック：方式１、オーディオ帯域：ＳＷＢ、ビットレート：［12kbps，24kbps］であって、ＶＢＲ：有（可）、又はＶＢＲ：無（不可）となる２つのコーデックモードセットの候補（a=rtpmap:97及び98）が作成される。
同様に、図２４Ｂに示すように、発呼側ＵＥは、図２４Ａに示すポリシーＡ２の一部である、コーデック：方式１、オーディオ帯域：ＷＢ、ビットレート：｛12,24｝kbpsに対応するコーデックモードセットの候補を選択する。具体的には、図２４Ｂに示す、コーデック：方式１、オーディオ帯域：ＷＢ、ビットレート：［12kbps，24kbps］であって、ＶＢＲ：有（可）、又はＶＢＲ：無（不可）となる２つのコーデックモードセットの候補（a=rtpmap:99及び100）が作成される。
同様に、図２４Ｂに示すように、発呼側ＵＥは、図２４Ａに示すポリシーＡ３の全てである、コーデック：方式２、オーディオ帯域：ＮＢ、ビットレート：［8kbps，12kbps］及びＶＢＲ：無（不可）に対応するコーデックモードセットの候補（a=rtpmap:101）を作成する。
図２４Ｂに示すように、発呼側ＵＥから着呼側ＵＥへ通知されるＳＤＰオファーに含まれる複数のコーデックモード（又はコーデックモードセット）の候補には、発呼側ＵＥに対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード（又はコーデックモードセット）の候補が含まれる。
一方、図２５Ａに示すように、オペレータＢのポリシーには、「コーデック：方式１、オーディオ帯域：ＷＢ、ビットレート：12kbps及びＶＢＲ：不可（ＶＢＲを許可しない）」というポリシー（以下、ポリシーＢ１と呼ぶ）が含まれる。また、オペレータＢのポリシーには、「コーデック：方式２、オーディオ帯域：ＮＢ、ビットレート：12kbps、及びＶＢＲ：不可（ＶＢＲを許可しない）」というポリシー（以下、ポリシーＢ２と呼ぶ）が含まれる。
そこで、着呼側ＵＥは、発呼側ＵＥから通知された図２４Ｂに示すＳＤＰオファーに含まれるコーデックモードセットの候補のうち、図２５Ａに示すオペレータＢのポリシーの少なくとも一部に対応するコーデックモードセットの候補の中から、発呼側ＵＥとの通信で使用するコーデックモードセットを選択する。
具体的には、図２５Ｂでは、着呼側ＵＥは、図２５Ａに示すポリシーＢ１の全てに対応するコーデックモードセットの候補（コーデック：方式１、オーディオ帯域：ＷＢ、ビットレート：12kbps、及び、ＶＢＲ：無（不可））を、発呼側ＵＥとの通信で使用するコーデックモードセットとして選択する。
なお、本実施の形態におけるコーデックモード（又はコーデックモードセット）選択方法は、実施の形態１〜３に示すコーデックモード（又はコーデックモードセット）選択方法と連動して用いられてもよい。
こうすることで、本実施の形態によれば、発呼側ＵＥはＳＤＰオファーに記述するコーデックモード（又はコーデックモードセット）等を当該ＵＥが接続しているオペレータのポリシーに応じて限定することができる。更に、着呼側ＵＥは、発呼側ＵＥとの通信で使用するコーデックモード（又はコーデックモードセット）として選択するコーデックモード（又はコーデックモードセット）等を当該ＵＥが接続しているオペレータのポリシーに応じて限定することができる。これにより、発呼側ＵＥと着呼側ＵＥとの間における複雑なＳＤＰ折衝を回避することができる。また、オペレータはポリシーに基づいたサービス（コーデック）をＵＥに選択させることができる。
（実施の形態７）
本実施の形態では、実施の形態１〜３で用いたネットワーク構成とは異なるネットワーク構成例を用いた場合におけるコーデックモード（又はコーデックモードセット）選択方法について説明する。
図２６は本実施の形態に係るネットワーク構成と、ＵＥ（端末）の位置関係の一例を示す図である。なお、図２６において、ＵＥ１００、ＵＥ１０２、ＩＰコア網１２４及びＩＭＳ網１２６は図１と同じであるので同一の符号を付してその説明を省略する。
図２６に示すＡＰ２６００及びＡＰ２６０２はアクセスポイント（Access Point）であり、無線アクセス網２６０６及び無線アクセス網２６０８をそれぞれ構成する。例えば、ＡＰ２６００及び２６０２は、Ｗｉ−Ｆｉ又はＷｉＭＡＸ等のアクセスポイントであってもよく、図１に示すＨｅＮＢであってもよい。
ＩＰ−ＰＢＸ２６０４は、ＡＰ２６００及びＡＰ２６０２と接続しており、例えば企業等の組織内ＬＡＮにおいて、ＩＰ電話による企業内電話網を実現する装置（呼制御のための処理機能を有するネットワークノード）である。例えば、ＩＰ−ＰＢＸ２６０４は、オペレータのＩＭＳ網との接続機能、又は、オペレータのＩＭＳ網の機能の一部を有する（例えば、「3GPP TS 22.809 v1.0.0, Feasibility Study on Support for 3GPP Voice Interworking with Enterprise IP- PBX (VINE)"」を参照）。また、ＩＰ−ＰＢＸ２６０４は、インターネットプロバイダのブロードバンド網等の外部ＩＰ網２６１０を通じてオペレータのＩＭＳ網１２６内に存在するサ−バ２６１２と接続している。また、ＩＰ−ＰＢＸ２６０４は、外部ＩＰ網２６１０とのゲートウェイ機能又はＩＭＳシグナリングを終端する機能（図示せず）等を合わせて有してもよい。
サーバ２６１２は、例えば、図１に示すＳ−ＣＳＣＦ１００等のＣＳＣＦ、ＡＳ（Application Server。例えば、「3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (IMS) Stage 2」に記載）、または、その両方であってもよく、これらＣＳＣＦあるいはＡＳと、ＩＰ-ＰＢＸ２６０４とを繋ぐ装置であってもよい。
ＡＰ２６１４は、ＩＰコア網１２４に接続しているアクセスポイントである。ＡＰ２６１４は、基地局（ｅＮＢまたはＨｅＮＢ）であってもよい。また、ＡＰ２６１４は、Ｗｉ−Ｆｉ又はＷｉＭＡＸ等のアクセスポイントであってもよい（例えば、「3GPP TS 23.402 v10.2.1, “Architecture enhancements for non-3GPP accesses"」を参照）。
図２６では、ＵＥ１００は、無線アクセス網２６０６内でＡＰ２６００に接続している。このとき、例えば、ＵＥ１００の接続先判断部６０４（図７）は、自機の接続先（無線アクセス網２６０６）が企業等の組織内ＬＡＮを構成する無線アクセス網であると判断したとする。なお、ＡＰ２６００がＨｅＮＢである場合、接続先判断部６０４は、実施の形態１と同様、ＣＳＧ ＩＤ等を用いて接続先を判断してもよい。また、ＡＰ２６００がＷｉ−Ｆｉ等の無線ＬＡＮのアクセスポイントである場合、接続先判断部６０４は、ＳＳＩＤ（Service Set Identifier）等を用いて接続先を判断してもよい。
本実施の形態では、ＵＥ１００（発呼側）がＵＥ１０２（着呼側）に対し発呼する場合、実施の形態１〜３と同様にして、ＵＥ１００が接続先判断部６０４（図７、図１３）の判断に従ってＳＤＰオファーの中に記述するコーデックモード（又はコーデックモードセット）を選択してもよい。また、ＵＥ１００でコーデックモード（又はコーデックモードセット）を選択せずにＩＰ−ＰＢＸ２６０４でコーデックモード（又はコーデックモードセット）を選択してもよい。
図２７は、本実施の形態に係るＩＰ−ＰＢＸ２６０４の構成を示すブロック図である。
図２７に示すＩＰ−ＰＢＸ２６０４において、受信部２７００は、発呼側ＵＥ（ここではＵＥ１００）からのシグナリングメッセージを受け取ると、シグナリングメッセージをシグナリングインタセプト部２７０４に出力する。
送信部２７０２は、シグナリング生成部２７１０から入力されるシグナリングメッセージを、シグナリングメッセージの送信先ＵＥ（着呼側ＵＥ。ここではＵＥ１０２）に送信する。
シグナリングインタセプト部２７０４は、受信部２７００から入力されるシグナリングメッセージが自機宛（ＩＰ−ＰＢＸ２６０４のＩＰアドレス宛て）でない場合でも、当該シグナリングメッセージを一旦インタセプト（intercept）する。シグナリングインタセプト部２７０４は、インタセプトしたシグナリングメッセージをシグナリング解析部２７０６に出力する。
シグナリング解析部２７０６は、入力されたシグナリングメッセージに記述されている情報を解析し、確認が必要な情報を、適切な確認部に出力する。例えば、シグナリング解析部２７０６は、着呼側ＵＥ（ＵＥ１０２）が現在接続されている無線アクセス網がＩＰ−ＰＢＸ２６０４の配下であるか否かを特定するために、シグナリングメッセージに記述された情報のうち、発呼先情報を、端末位置情報確認部２７０８に渡す。
端末位置情報確認部２７０８は、着呼側ＵＥ（ＵＥ１０２）が現在接続されている無線アクセス網がＩＰ−ＰＢＸ２６０４の配下であるか否か（例えば、同一企業内電話網に接続されているか否か）を確認する。この確認は、シグナリング解析部２７０６から受け取った発呼先情報に基づいて行われる。このとき、端末位置情報確認部２７０８は、ＩＰ−ＰＢＸ２６０４内のＵＥ１０２の登録情報等を用いて確認を行ってもよいし、サーバ２６１２を通じてＩＭＳ網１２６に存在するＵＥ１０２の登録情報等の全て又は一部を用いて確認を行ってもよい。または、端末位置情報確認部２７０８は、これら双方の情報を用いて確認を行ってもよい。端末位置情報確認部２７０８は、確認結果をシグナリング生成部２７１０に出力する。
シグナリング生成部２７１０は、発呼側ＵＥ（ＵＥ１００）から送信されたシグナリングメッセージの中で修正が必要な記載内容の上書き又は新規作成を行う。例えば、端末位置情報確認部２７０８において、着呼側ＵＥ（ＵＥ１０２）が同一企業内電話網（ここではＩＰ−ＰＢＸ２６０４配下）に存在すると判断されたとする。この場合、シグナリング生成部２７１０は、シグナリングメッセージ内のＳＤＰオファーの記述内容について、同一企業内電話網内の通話に用いられるコーデックモード（又はコーデックモードセット）等を含むように新規記述又は上書きする。この際、シグナリング生成部２７１０は、ＩＰ−ＰＢＸ２６０４によるＳＤＰオファーの確認済を示す情報を、フラグ、数値及びテキスト等の記載方法でシグナリングメッセージに追加してもよい。
また、端末位置情報確認部２７０８において、着呼側ＵＥ（ＵＥ１０２）が例えば同一企業内電話網（ここではＩＰ−ＰＢＸ２６０４配下）の外部に存在すると判断されたとする。この場合にも、シグナリング生成部２７１０は、シグナリングメッセージ内のＳＤＰオファーの記述内容について、通常の通話に用いられるコーデックモード（又はコーデックモードセット）等を含むように新規記述又は上書きしてもよい。この際、シグナリング生成部２７１０は、ＩＰ−ＰＢＸ２６０４によるＳＤＰオファーの確認済を示す情報を、フラグ、数値及びテキスト等の記載方法でシグナリングメッセージに追加してもよい。
新規作成又は修正されたシグナリングメッセージは、送信部２７０２を介して、シグナリングメッセージの送信先（ＵＥ１０２）に送信される。
シグナリングメッセージを受け取った着呼側ＵＥ（ＵＥ１０２）は、自機の接続先（無線アクセス網）が企業等の組織内ＬＡＮを構成する無線アクセス網であると判断し、かつ受け取ったシグナリングメッセージ内のＳＤＰオファーがＩＰ−ＰＢＸによる確認済であることを特定したとする。この場合、着呼側ＵＥ（ＵＥ１０２）は、ＳＤＰオファー（ＩＰ−ＰＢＸ２６０４で上書き又は新規作成されたＳＤＰオファー）を参照して、同一企業内電話網内の通話に用いられるコーデックモード（又はコーデックモードセット）等を選択する。この際、実施の形態３と同様にして、着呼側ＵＥ（ＵＥ１０２）は、ハンドオーバの可能性の有無なども用いてコーデックモード（又はコーデックモードセット）を選択してもよい。
一方、着呼側ＵＥ（ＵＥ１０２）は、自機の接続先（無線アクセス網）が企業等の組織内ＬＡＮを構成する無線アクセス網であると判断したが、受け取ったシグナリングメッセージ内のＳＤＰオファーがＩＰ−ＰＢＸによる確認済であることを特定できなかったとする。この場合、着呼側ＵＥ（ＵＥ１０２）は、ＳＤＰオファーに記述されたコーデックモード（又はコーデックモードセット）の候補の中から、通常の通信又は通常の通話に用いられるコーデックモード（又はコーデックモードセット）等を選択してもよい。
また、着呼側ＵＥ（ＵＥ１０２）の接続先が企業等の組織内ＬＡＮを構成する無線アクセス網の外部であった場合、着呼側ＵＥ（ＵＥ１０２）では、実施の形態１〜３と同様のコーデックモード（又はコーデックモードセット）選択方法が適用される。
そして、着呼側ＵＥ（ＵＥ１０２）は、選択したコーデックモード（又はコーデックモードセット）を含むＳＤＰアンサーを生成し、発呼側ＵＥ（ＵＥ１００）へ送信する。
このようにして、本実施の形態では、ＩＰ−ＰＢＸ２６０４は、着呼側ＵＥが現在接続している無線アクセス網がＩＰ−ＰＢＸ２６０４配下である場合、発呼側ＵＥから通知されたＳＤＰオファーに示される複数のコーデックモード（又はコーデックモードセット）候補を変更（新規作成又は上書き）して、新たなＳＤＰオファーを生成する。そして、着呼側ＵＥは、ＩＰ−ＰＢＸ２６０４で変更された変更後のＳＤＰオファーに含まれる複数のコーデックモード（又はコーデックモードセット）候補の中から、発呼側ＵＥとの通信で使用するコーデックモード（又はコーデックモードセット）を選択する。
これにより、着呼側ＵＥが現在接続している無線アクセス網がＩＰ−ＰＢＸ２６０４配下である場合には、ＳＤＰオファー内に記述されるコーデックモード（又はコーデックモードセット）の候補等を、ＩＰ−ＰＢＸ２６０４配下に存在するＵＥに対して適切なコーデックモード（又はコーデックモードセット）（例えば、同一企業内電話網内の通話に用いられるコーデックモード（又はコーデックモードセット）等）に限定することができる。これにより、発呼側ＵＥと着呼側ＵＥとの間における複雑なＳＤＰ折衝を回避することができる。
更に、ＩＰ−ＰＢＸ２６０４は、ＳＤＰオファーを確認したか否か（確認済みであるか否か）を示す情報を着呼側ＵＥへ送信する。そして、着呼側ＵＥは、ＩＰ−ＰＢＸ２６０４によりＳＤＰオファーの確認済みであることを特定した場合には、ＩＰ−ＰＢＸ２６０４で変更された変更後のＳＤＰオファーに含まれる複数のコーデックモード（又はコーデックモードセット）候補の中から、発呼側ＵＥとの通信で使用するコーデックモード（又はコーデックモードセット）を選択する。
これにより、ＵＥがＩＰ−ＰＢＸ２６０４の配下（同一企業内電話網）に存在するか否かが正確に判断される。そして、例えば、ＵＥがＩＰ−ＰＢＸ２６０４の配下（同一企業内電話網）に存在する場合、ＵＥは、同一企業内電話網内の通話に用いられるコーデックモード（又はコーデックモードセット）等に限定してコーデックモード（又はコーデックモードセット）を選択することができる。また、例えば、ＵＥがＩＰ−ＰＢＸ２６０４の配下（同一企業内電話網）に存在しない場合、ＵＥは、通常の通信（通常の通話）に用いられるコーデックモード（又はコーデックモードセット）等に限定してコーデックモード（又はコーデックモードセット）を選択することもできる。
こうすることで、本実施の形態では、同一企業内電話網に存在するＵＥが正確に判断され、ＵＥは好適なコーデックモード（又はコーデックモードセット）等を選択することができる。
なお、本実施の形態では、発呼側ＵＥからのＳＤＰオファーに関してＩＰ−ＰＢＸ２６０４で新規記述又は上書きを行う場合について説明した。しかし、本実施の形態において、ＵＥ１０２が同一企業内電話網（ここではＩＰ−ＰＢＸ２６０４配下）に存在していた場合、着呼側ＵＥからのＳＤＰアンサーに関しても、前述のようにＩＰ−ＰＢＸ２６０４で新規記述又は上書きしてもよい。
また、ＵＥ１００、ＵＥ１０２、及び、ＩＰ−ＰＢＸ２６０４でＳＤＰオファー又はＳＤＰアンサーが新規作成又は上書きされる場合に、実施の形態６と同様にして、オペレータのポリシーが使われてもよい。
（実施の形態８）
本実施の形態では、実施の形態４及び５に示したＲＴＰペイロードフォーマットに関し、全てのＲＴＰパケットのＲＴＰペイロード（ヘッダ部、又はデータ部の一部）に含める必要のないフィールドの与え方について説明する。
例えば、実施の形態４及び５に示したコーデックモードリクエスト（Codec Mode Request）のフィールド、又は、モノ／ステレオの切り替え（チャンネル数の指定）及び遅延モードの切り替え（遅延の指定）等を通信相手に要求するフィールド等がある。これらは、要求が発生した場合のみ、ＲＴＰペイロード（ヘッダ部、又はデータ部の一部）に含めればよい。
なお、非特許文献３または非特許文献４に記載のＳＩＤ(Silence Insertion Descriptor)、Ｎｏ Ｄａｔａ、ｓｐｅｅｃｈ ｌｏｓｔが、図１９〜図２３などに記載のFrame Type Indexの一部等として、ＲＴＰペイロード（ヘッダ部）に含まれない場合もある。この場合、これらＳＩＤ、Ｎｏ Ｄａｔａ、ｓｐｅｅｃｈ ｌｏｓｔなどを送る要求が発生した場合にのみ、当該要求を、ＲＴＰペイロード（ヘッダ部、又はデータ部の一部）に含めればよい。
図２３Ａに示すFrame Type Indexを利用した場合のＲＴＰペイロードフォーマットの一例を図２８に示す。図２３ＡのFrame Type Indexには上述のＳＩＤは含まれていないが、ここでは、例えばFrame Type Indexの8としてＳＩＤが設定されていたとする。図２８Ａは、上記フィールド（Codec Mode Requestフィールド、又は、モノ／ステレオの切り替え、遅延モードの切り替え等を通信相手に要求するフィールド）が存在しない場合のＲＴＰペイロードフォーマットの一例を示す。図２８Ｂは、上記フィールドが存在する場合のＲＴＰペイロードフォーマットの一例を示す。
ここで、図２８Ａに示すＲＴＰペイロードのヘッダ部は例えば１オクテット等の固定長である。図２８Ａに示すヘッダ部の中には、固定長の「後続ヘッダ部の有無を示すフィールド」、「その他」のフィールド、「Frame Type Index」が含まれる。なお、ここで「ヘッダ部」、「後続ヘッダ部」とは、ＲＴＰペイロードデータ部の一部と解釈してもよい。
図２８Ａに示す「後続ヘッダ部の有無を示すフィールド」には、図２８Ａに示す固定長のヘッダ部の後に、別の固定長ヘッダ部が続くか否かを示す情報が、例えばフラグ又は数値等の形で入る。図２８Ａでは、後続する別のヘッダ部は存在しないので、「後続ヘッダ部の有無を示すフィールド」には、後続する別のヘッダ部が「存在しない」ことを示す情報が入る。
図２８Ａに示す「その他」のフィールドには、「後続ヘッダ部の有無を示すフィールド」及び「Frame Type Index」の両方以外の他のフィールドが含まれる。
図２８Ａに示す「Frame Type Index」には、例えば図２３Ａに示すFrame Type Indexが入る。
図２８Ａに示すＲＴＰペイロードのデータ部には、例えば、実施の形態５で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入る。
一方、図２８Ｂに示す「後続ヘッダ部の有無を示すフィールド」には、図２８Ｂに示す固定長のヘッダ部の後に、別の固定長ヘッダ部（後続ヘッダ）が「存在する」ことを示す情報が入る。
図２８Ｂに示す「その他」のフィールド及び「Frame Type Index」は図２８Ａと同等である。
図２８Ｂに示す後続ヘッダは例えば１オクテット等の固定長である。図２８Ｂに示す後続ヘッダには、「後続ヘッダの種類」、「後続ヘッダの内容」、及び「その他」のフィールドが含まれる。
図２８Ｂに示す「後続ヘッダの種類」には、当該後続ヘッダが何を示すものであるのか、を示す情報が、例えばフラグ又は数値等で示される。例えば、「後続ヘッダの種類」は、Codec Mode Request、モノ／ステレオ等のチャンネル数の切替要求、又は、遅延モードの切替要求を示してもよく、パケットロス隠蔽のための冗長データを示してもよい。
図２８Ｂに示す「後続ヘッダの内容」には、「後続ヘッダの種類」に示される種類に応じた内容が入る。例えば、「後続ヘッダの種類」がCodec Mode Requestである場合には、通信相手に要求するコーデックビットレートを示す値（例えば図２３Ａに示すFrame Type Index等）が入る。また、「後続ヘッダの種類」がモノ／ステレオ等のチャンネル数の切替要求又は遅延モードの切替要求等である場合には、要求している切り替え先の情報（例えば、「モノ」への切り替えを示す情報、又は「遅延Ａ」への切り替えを示す情報等）が入る。また、「後続ヘッダの種類」が冗長データである場合、冗長データのデータ長等が入る。
なお、図２８Ｂに示す「後続ヘッダの種類」により上記「後続ヘッダの内容」が一意に決定できる場合には、後続ヘッダはなくてもよい。また、図２８Ｂに示す「後続ヘッダの種類」のフィールドは固定長であるが、「後続ヘッダの内容」のフィールド長は、「後続ヘッダの種類」によって異なる値をとってもよい。
図２８Ｂに示す「その他」のフィールドには、「後続ヘッダの種類」及び「後続ヘッダの内容」の両方以外の他のフィールドが入るが、必要無い場合は無くてもよい。
図２８Ｂに示すＲＴＰペイロードのデータ部には、例えば実施の形態５で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入る。また、データ部には、「後続ヘッダの種類」が冗長パケットであった場合には、冗長パケットも入る。この場合、エンコーダは、主データとして、データ部の長さから冗長パケットの長さを引いた長さに収まる適切なビットレート及び組み合わせを選択しビットストリームを生成する。
このように、本実施の形態の第１の例では、ヘッダ部とデータ部とから成るＲＴＰペイロードにおいて、ヘッダ部は、全てのＲＴＰペイロードにおいて常に設けられるヘッダ部と、全てのＲＴＰペイロードにおいて常に設けられるとは限らないヘッダ部（図２８Ｂに示す後続ヘッダ部）とを含む。また、図２８Ａ及び図２８Ｂに示すように、全てのＲＴＰペイロードにおいて常に設けられるヘッダ部には、後続ヘッダ部が設けられるか否かを示すフィールド（後続ヘッダ部の有無を示すフィールド）が含まれる。
なお、本実施の形態におけるＲＴＰペイロードフォーマットは、別の構成を取り得る。
図２９は、本実施の形態におけるＲＴＰペイロードフォーマットの第２の例を示す。本例では、特にＲＴＰペイロードで運ぶ必要のある全ての情報が、ＲＴＰペイロードのデータ部の一部として運ばれる事を想定し、エンコードされたデータ以外の情報をシグナリング（又はシグナリング部）と呼ぶ。また本例では、コーデックのビットレートを示す情報（Frame Type Index等）は、ＲＴＰペイロードに明示的に含まない事を想定する。
図２９Ａは、後続シグナリング部の有無を示すフィールドのみが、シグナリング部として存在する場合の、ＲＴＰペイロードフォーマットの一例を示す。図２９Ｂは、後続シグナリング部の有無を示すフィールド及び後続シグナリング部が存在する場合の、ＲＴＰペイロードフォーマットの一例を示す。
ここで、図２９Ａに示すＲＴＰペイロードの、最上位ビットからの固定長（例えば１ビット等）には、「後続シグナリング部の有無を示すフィールド」が含まれる。なお、ここで「最上位ビットからの固定長」、「後続シグナリング部」とは、上述のようにＲＴＰペイロードデータ部の一部であってもよいし、ＲＴＰペイロードのヘッダ部であってもよい。
図２９Ａに示す「後続シグナリング部の有無を示すフィールド」には、このフィールドの後に、別のシグナリング部が続くか否かを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが１ビットである場合、このフィールドに“０”が入れば、後続するシグナリングは存在せず、“１”が入れば、後続するシグナリング部が存在する。
図２９Ａでは、後続する別のシグナリング部は存在しないので、「後続シグナリング部の有無を示すフィールド」には、後続する別のシグナリング部が「存在しない」ことを示す情報（つまり本例では“０”）が入る。
一方、図２９Ｂに示す「後続シグナリング部の有無を示すフィールド」には、図２９Ｂに示す固定長のシグナリング部の後に、別の固定長、又は可変長のシグナリング部（後続シグナリング）が「存在する」ことを示す情報（つまり本例では“１”）が入る。
図２９Ｂに示す後続シグナリング部は、固定長又は可変長であり、「後続シグナリングの種類」及び「後続シグナリングの内容」フィールドを含む。
図２９Ｂに示す「後続シグナリングの種類」では、当該後続シグナリングが何を示すものであるのか、を示す情報が、例えばフラグ又は数値等で示される。例えば、「後続シグナリングの種類」は、Codec Mode Request（コーデックビットレートの切替要求、チャンネル数の切替要求、帯域幅の切替要求など）を示してもよく、また、パケットロス隠蔽のための冗長データの存在を示してもよい。また、「後続シグナリングの種類」は、ＳＩＤ、Ｎｏ Ｄａｔａ、図１９〜図２３などに記載のＳｐｅｅｃｈ ｌｏｓｔを示してもよい。
図２９Ｂに示す「後続シグナリングの内容」には、「後続シグナリングの種類」に示される種類に応じた内容が入る。例えば、「後続シグナリングの種類」がCodec Mode Requestのコーデックビットレート切替要求である場合には、通信相手に要求するコーデックビットレートを示す値（例えば、図２３Ａに示すFrame Type Index等）が入る。また、「後続シグナリングの種類」がCodec Mode Requestのチャンネル数切替要求である場合には、「後続シグナリングの内容」には、要求している切替先の情報（例えば、「モノ」への切り替えを示す情報、「ステレオ」への切替を示す情報等）が入る。また、「後続シグナリングの種類」が冗長データの存在である場合、「後続シグナリングの内容」には、冗長データのデータ長等が入る。なお、「後続シグナリングの内容」が可変長である場合は、「後続シグナリングの種類」に示される種類に応じて、その長さは変わる。
なお、図２９Ｂに示す「後続シグナリングの種類」により上記「後続シグナリングの内容」が一意に決定できる場合、又は、「後続シグナリングの内容」の決定が必要無い場合、「後続シグナリングの内容」はなくてもよい。これは、例えば、「後続シグナリングの種類」が、ＳＩＤ、Ｎｏ Ｄａｔａ、あるいは、図１９〜図２３などに記載のｓｐｅｅｃｈ ｌｏｓｔを示す場合である。また、図２９Ｂに示す「後続シグナリングの種類」のフィールドは固定長であるのに対し、「後続シグナリングの内容」のフィールド長は、「後続シグナリングの種類」によって異なる値をとってもよい。「後続シグナリングの内容」が「後続シグナリングの種類」によって異なる値をとる場合には、後続シグナリングそのものが可変長となる。
また、ＲＴＰペイロードフォーマットは、図２９Ｂにおいて、「後続シグナリングの種類」及び「後続シグナリングの内容」の後に、「後続シグナリング部の有無を示すフィールド」が設けられてもよい。そして、ＲＴＰペイロードフォーマットは、更に別の「後続シグナリングの種類」、「後続シグナリングの内容」、「後続シグナリング部の有無を示すフィールド」を続けてもよい（図示せず）。
図２９Ｂに示すＲＴＰペイロードのデータ部には、例えば実施の形態５で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入ってもよい。また、データ部には、「後続シグナリングの種類」が冗長パケットであった場合には、冗長パケットも入る。この場合、エンコーダは、データ部の長さから冗長パケットの長さを引いた長さに収まる適切なビットレート及び組み合わせを選択して、主データとして、ビットストリームを生成する。また、「後続シグナリングの種類」がＳＩＤであった場合は、ＲＴＰペイロードのデータ部には、ＳＩＤの際に生成されるデータが含まれる。これに対し、「後続シグナリングの種類」がＮｏ Ｄａｔａあるいは、図１９〜図２３などに記載のｓｐｅｅｃｈ ｌｏｓｔであった場合には、ＲＴＰペイロードのデータ部には、データは含まれない（データ部自体が存在しなくてもよい）。
本例では、コーデックのビットレートを示す情報（Frame Type Indexなど）がＲＴＰペイロードに明示的に含まない事を想定した。この場合、受信側でＲＴＰペイロード長を算出（ＩＰヘッダまたはＵＤＰヘッダに含まれるデータ長情報より、ＲＴＰペイロード長を算出、又はＲＴＰペイロード長自体を計測）し、そこから図２９のシグナリング部の長さを取り除く事により、コーデックビットレートが計算される。
また、図２９の例では「後続シグナリング部の有無を示すフィールド」が最上位ビットからの固定長としてＲＴＰペイロードの先頭に入る例を示したが、このフィールドは、ＲＴＰペイロードのどこに（例えばＲＴＰペイロードの最後に）含まれてもよい。この場合、「後続シグナリング部の有無を示すフィールド」は、「後続のシグナリング部の有無を示す」という意味ではなく、「ＲＴＰペイロードの先頭にシグナリング部があるかどうかを示す」という意味となる。
このように、本実施の形態の第２の例では、ＲＴＰペイロードは、データ部と、これに含まれるシグナリング部から成る。そして、かかるＲＴＰペイロードにおいて、シグナリング部は、全てのＲＴＰペイロードにおいて常に設けられる「後続シグナリング部の有無を示すフィールド」と、全てのＲＴＰペイロードにおいて常に設けられるとは限らないシグナリング部（図２９Ｂに示す後続シグナリング）とを含む。
図３０は、本実施の形態におけるＲＴＰペイロードフォーマットの第３の例を示す。本例では、ＲＴＰペイロードの最上位ビットからの固定長に、ヘッダ部が存在するか否かを示すフィールドを設ける事により、ＲＴＰペイロードにヘッダ部が存在するか否かを切り替える。これにより、全てのＲＴＰパケットのＲＴＰペイロードに含める必要のないフィールド（シグナリング）が発生する場合には、このＲＴＰペイロードのヘッダ部を利用し、このヘッダ部に情報（シグナリング）を含める。
図３０Ａは、ヘッダ部の有無を示すフィールドのみが、シグナリング部として存在する場合の、ＲＴＰペイロードフォーマットの一例を示す。図３０Ｂは、ヘッダ部が存在する場合の、ＲＴＰペイロードフォーマットの一例を示す。
ここで、図３０Ａに示すＲＴＰペイロードの最上位ビットからの固定長（例えば１ビット等）には、「ヘッダ部の有無を示すフィールド」が含まれる。図３０Ａに示す「ヘッダ部の有無を示すフィールド」には、このＲＴＰペイロードにヘッダ部が存在するか否か示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが１ビットである場合、このフィールドに“０”が入ればヘッダ部は存在せず、“１”が入ればヘッダ部が存在する。
図３０Ａでは、ヘッダ部は存在しないので、「ヘッダ部の有無を示すフィールド」には、ヘッダが存在しない事ことを示す情報（つまり本例では“０”）が入る。なお、図３０Ａのように、「ヘッダ部の有無を示すフィールド」が、ヘッダが存在しない事ことを示す場合には、この「ヘッダ部の有無を示すフィールド」は、ＲＴＰペイロードのデータ部の一部とする。
一方、図３０Ｂに示す「ヘッダ部の有無を示すフィールド」には、図３０Ｂに示すヘッダ部が「存在する」ことを示す情報（つまり本例では“１”）が入る。ヘッダ部が存在する場合、図３０Ｂ、図３０Ｃ、図３０Ｄに示すように、ヘッダ部は「基本ヘッダ」と「拡張ヘッダ」から成る。ヘッダ部が存在する場合、基本ヘッダは必ず存在するが、拡張ヘッダは、基本ヘッダの情報の内容によって、存在しない場合もある。
図３０Ｃに、基本ヘッダの一例を示す。本例では、ヘッダ部が存在する場合に、「ヘッダ部の有無を示すフィールド」が基本ヘッダの一部として含まれる例を示すが、このフィールドは、ヘッダ部の一部とせずに、データ部の一部としてもよい。すなわち、「ヘッダ部の有無を示すフィールド」は、基本ヘッダに含まれていなくてもよい。基本ヘッダは固定長であり、基本ヘッダの残りには、例えば「mono/multi」フィールド、「Frame Type」フィールド、及び「後続ヘッダ有無」フィールドが含まれる。
「mono/multi」フィールドには、例えばこのＲＴＰペイロードが運んでいるデータが、モノ（１チャンネル）なのか、ステレオなどのマルチチャンネルなのかを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが１ビットである場合、このフィールドに“０”が入ればモノを示し、“１”が入ればマルチチャンネルを示す。
「Frame Type」フィールドには、例えば前述の「mono/multi」フィールドがモノを表す場合、図１９〜図２３などに記載のFrame Type Indexのように、コーデックビットレートの情報、前述のＳＩＤ(Silence Insertion Descriptor)、Ｎｏ Ｄａｔａといった情報が含まれる。また上述の「mono/multi」フィールドがマルチチャンネルを表す場合、
「Frame Type」には、例えば、マルチチャンネルの情報、ビットレートなどが含まれる。マルチチャンネルの情報とは、すなわち、チャンネル数またはマルチチャンネル用エンコード方式（例えば２チャンネルの場合、右と左とを別々にエンコードする方式か、２チャンネル拡張部を付ける方式か、など）を示す情報である。
「後続ヘッダ有無」フィールドには、例えば基本ヘッダの後に、拡張ヘッダが存在するか否かの情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが１ビットである場合、このフィールドに“０”が入れば後続ヘッダは存在しない事を示し、“１”が入れば後続ヘッダが存在する事を示す。
基本ヘッダは、固定長であるが、「mono/multi」フィールドの示す内容、つまり、モノかマルチチャンネルかに応じて、その固定長の値が異なっていてもよい。
図３０Ｄに、後続ヘッダが存在する場合の、拡張ヘッダの一例を示す。拡張ヘッダは固定長であり、例えば「ヘッダタイプ」フィールド、「情報」フィールド、及び「後続ヘッダ有無」フィールドを含む。
「ヘッダタイプ」フィールドには、この拡張ヘッダのタイプを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが３ビットである場合、このフィールドに例えば“０００”が入れば、拡張ヘッダのタイプが「冗長データ情報」であることを示す。「ヘッダタイプ」フィールドに“００１”が入れば、拡張ヘッダのタイプが「Codec Mode Request (bitrate)」であることを示す。「ヘッダタイプ」フィールドに“０１０”が入れば、拡張ヘッダのタイプが「Codec Mode Request (チャンネル数)」であることを示す。「ヘッダタイプ」フィールドに“０１１”が入れば、拡張ヘッダのタイプが「Codec Mode Request (帯域)」であることを示す。
「情報」フィールドには、「ヘッダタイプ」の内容によって、異なる情報が入る。例えば上述のように、「ヘッダタイプ」が「冗長データ情報」である場合、例えば「情報」フィールドには冗長データのビットレートを表すFrame Type Indexが入る。これは、つまり、非特許文献２のように、一つのＲＴＰパケットの中に複数のフレームのデータが入っている場合である。また、例えば上述のように、「ヘッダタイプ」が「Codec Mode Request (bitrate)」である場合、「情報」フィールドには、相手端末に要求するコーデックビットレートを示すFrame Type Indexが入る。また、例えば上述のように、「ヘッダタイプ」が「Codec Mode Request (チャンネル数)」である場合、「情報」フィールドには、相手端末に要求するチャンネル数またはマルチチャンネル用エンコード方式が入る。また、例えば上述のように、「ヘッダタイプ」が「Codec Mode Request (帯域)」である場合、「情報」フィールドには、相手端末に要求するエンコーディング帯域を示す情報が入る。
また、例えば、マルチチャンネルを示すフィールド及びマルチチャンネルの情報は、基本ヘッダではなく、拡張ヘッダに含めてもよい。また、逆に、「Codec Mode Request」及び冗長データを表すフィールド、及びその情報は、拡張ヘッダではなく、基本ヘッダに含んでもよい。
「後続ヘッダ有無」フィールドには、例えば、この拡張ヘッダの後に、さらに拡張ヘッダが存在するか否かの情報が、フラグ又は数値等の形で入る。例えば、このフィールドが１ビットである場合、このフィールドに“０”が入れば、後続ヘッダは存在しない事を示し、“１”が入れば、後続ヘッダが存在する事を示す。
なお、拡張ヘッダは、固定長であるが、「ヘッダタイプ」フィールドの示す内容に応じて、その固定長の値が異なっていてもよい。
拡張ヘッダのヘッダタイプが、例えば「冗長データ情報」または「マルチチャンネル情報」である場合、図３０Ｂに示すＲＴＰペイロードのデータ部には、冗長データ、チャンネル数、マルチチャンネル用エンコード方式に合ったマルチチャンネルデータも含まれる。また、基本ヘッダのFrame TypeがＮｏ Ｄａｔａ、あるいは、図１９〜図２３などに記載のｓｐｅｅｃｈ ｌｏｓｔなどであった場合には、ＲＴＰペイロードのデータ部は無くてもよい。
また、図３０の例では「ヘッダ部の有無を示すフィールド」が最上位ビットからの固定長としてＲＴＰペイロードの先頭に入る例を示したが、このフィールドは、ＲＴＰペイロードのどこに（例えばＲＴＰペイロードの最後に）含まれてもよい。
このように、本実施の形態の第３の例では、ヘッダ部とデータ部とから成るＲＴＰペイロードにおいて、ヘッダ部が存在しない場合（図３０Ａ）と、ヘッダ部が存在する場合（図３０Ｂ）とを含む。また、図３０Ａ及び図３０Ｂに示すように、全てのＲＴＰペイロードにおいて常に、ヘッダ部が設けられるか否かを示すフィールド（ヘッダ部の有無を示すフィールド）が含まれる。
なお、実施の形態５で述べたように、伝送ブロックサイズ等が決められているために、ＲＴＰペイロード長、特に通常の音声等のデータを運ぶＲＴＰペイロード長が、複数の固定長に限られる場合がある。このような場合、本実施の形態のように、通常の音声等のデータを運ぶＲＴＰペイロードにCodec Mode Requestを含めると、ＲＴＰペイロード長が、対応する伝送ブロックサイズより長くなる可能性がある。
これを解決するため、端末は、データ部が存在しないＲＴＰペイロード、又は、通常データを送る場合に比べてデータ部が短いＲＴＰペイロードが送られるタイミングで、Codec Mode RequestをこれらＲＴＰペイロードに含めて送ってもよい。データ部が存在しない場合、又は通常データを送る場合に比べてデータ部が短い場合とは、例えば、ＳＩＤ、Ｎｏ Ｄａｔａ、あるいは図１９〜図２３に記載のｓｐｅｅｃｈ ｌｏｓｔを用いる場合である。
このように、本実施の形態によれば、ＲＴＰペイロードにおいて、必要な場合にのみ必要なフィールドを与えた上で、データ部の長さに収まる適切なビットレートとその組み合わせをエンコーダに選択させることができる。
以上、本発明の各実施の形態について説明した。
なお、Frame Type Indexは用意されている全てのコーデックモード（ビットレートそのもの、又は、ビットレートの組み合わせ）を記述する必要はなく、コーデックモードの一部を定義してもよい。
また、上記実施の形態では、実際のコーデックモード（又はコーデックモードセット）とコーデックモード（又はコーデックモードセット）を示す番号（数値）との対応付けが規定されている場合について説明した。そして、コーデックモード（又はコーデックモードセット）を示す番号（数値）がＳＤＰ（図８及び図１１）に記述される場合について説明した。しかし、実際のコーデックモード（又はコーデックモードセット）がＳＤＰに直接記述されてもよい。
また、図８、図１１、図１４及び図１７で記述されている「方式１」は、特定のコーデック名を表す。例えば、「方式１」はＥＶＳ、ＡＭＲ又はＡＭＲ−ＷＢでもよく、別のコーデックであってもよい。また、図８及び図１４では、方式１のコーデックに関してのみオファーされている記述となっているが、他の方式（方式２、方式３．．．）に関しても同様に記述され、ＳＤＰオファーの中に含まれてもよい。
また、或るコーデック内での異なる種別、チャンネル数（モノ、ステレオ）等）は、コーデック名としてＳＤＰ内に記述されてもよく、図９及び図１５に示すコーデックモードセットの対応付けの中で定義されてもよい。ここで、コーデック内での異なる種別とは、例えば、ＥＶＳの中の、ＡＭＲ−ＷＢインタオペラブルモード又はＡＭＲ−ＷＢ非インタオペラブルモード、オーディオ帯域（Narrow Band、Wide Band、Super Wide Band、Full Band等を含む。
また、上記実施の形態では、無線アクセス網の特性に関する情報として、ＣＳＧ ＩＤ又は基地局ＩＤを用いる場合について説明した。しかし、無線アクセス網の特性に関する情報としては、これらに限らず、例えば、ＵＥが接続されているセル（ＨｅＮＢ）を示すセル情報、及び、ＵＥの位置を示す位置情報等が挙げられる。
また、上記実施の形態では、ＵＥ間の通信開始時のコーデックモード（又はコーデックモードセット）（ビットレート及びアルゴリズム遅延を含む）を選択する場合について説明したが、これに限られない。例えば、ＵＥが有している能力（例えば、ディスプレイの大きさ等）を選択する場合についても上記実施の形態を適用することができる。
また、上記実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。
また、本発明は、上記実施の形態に限定されず、種々変更して実施することが可能である。
また、上記実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）、ＬＳＩ内部の回路セルの接続または設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
２０１０年１１月１０日出願の特願２０１０−２５２１１３の日本出願、２０１０年１２月１４日出願の特願２０１０−２７８２２２の日本出願、２０１１年４月６日出願の特願２０１１−８４４４２の日本出願、及び２０１１年８月９日出願の特願２０１１−１７３９１０の日本出願に含まれる明細書、図面及び要約書の開示内容は、すべて本願に援用される。
本発明は、特に、通信開始時にシグナリングメッセージによってネゴシエーションを行う端末等に好適である。
１００，１０２ ＵＥ
１０４，１０６ ｅＮＢ
１０８，１１６ Ｐ−ＣＳＣＦ
１１０，１１４ Ｓ−ＣＳＣＦ
１１２ Ｉ−ＣＳＣＦ
１１８ ＨＳＳ
１２０，１２２，４０６，４０８，５０６，５０８，２６０６，２６０８ 無線アクセス網
１２４ ＩＰコア網
１２６ ＩＭＳ網
４００，４０２，５００，５０２ ＨｅＮＢ
４０４ Ｌｏｃａｌ ＧＷ
６００ 無線受信部
６０２ 無線送信部
６０４ 接続先判断部
６０６ 情報比較部
６０８ モード決定部
６１０，７０８，２７１０ シグナリング生成部
７００，２７００ 受信部
７０２，２７０２ 送信部
７０４，２７０６ シグナリング解析部
７０６，２７０８ 端末位置情報確認部
８１２ 状態解析部
８１４ モード変更部
２６００，２６０２，２６１４ ＡＰ
２６０４ ＩＰ−ＰＢＸ
２６１０ ＩＰ網
２６１２ サーバ
２７０４ シグナリングインタセプト部

Claims (10)

  1. ＲＴＰ（Real-time Transport Protocol）を用いて相手端末との通信を行う通信端末であって、
    前記相手端末に対し、エンコードされたデータをＲＴＰペイロードのフォーマットを用いて送信する送信部と、
    前記相手端末から送信されたデータをＲＴＰペイロードのフォーマットを用いて受信する受信部と、
    前記相手端末との通信開始時に、ＳＤＰオファー/アンサーによる折衝を行った結果に基づいて、前記相手端末との通信に用いるコーデックモードまたはコーデックセットを決定するモード決定部と、
    を備え、
    前記ＲＴＰペイロードは、ＳＤＰオファー/アンサーによる折衝に基づいて、当該ＲＴＰペイロードのヘッダ部に、前記相手端末にコーデックモードの変更を要求するコーデックモードリクエストのフィールドを含むか否かが設定され、前記コーデックモードは、ビットレート情報を含む、
    通信端末。
  2. 前記ＲＴＰペイロードにおいて、前記ヘッダ部に前記コーデックモードリクエストを含めると設定された場合、前記送信部は、前記コーデックモードリクエストを前記ヘッダ部に含めて送信する、
    請求項１に記載の通信端末。
  3. 前記ＲＴＰペイロードは、データ部を含み、
    前記ビットレート情報は、
    前記データ部におけるデータ基本部及び拡張部のビットレートであって、前記ヘッダ部に含まれ、
    前記データ部は、前記データ基本部と前記拡張部とのビットレートの組み合わせ情報を含む、
    請求項１に記載の通信端末。
  4. 前記ＲＴＰペイロードは、データ部を含み、
    前記ビットレート情報は、
    前記データ部におけるデータ基本部及び拡張部のビットレートであって、どのコーデックモードの組み合わせ又はどのビットレートの組み合わせが使われているかは含まない、
    請求項１に記載の通信端末。
  5. 前記ヘッダ部は、ＳＤＰオファー/アンサーによる折衝後、自端末で使用中のコーデックモードを示すフィールドを含む、
    請求項１に記載の通信端末。
  6. ＲＴＰ（Real-time Transport Protocol）を用いて相手端末との通信を行う通信方法であって、
    前記相手端末に対し、エンコードされたデータをＲＴＰペイロードのフォーマットを用いて送信し、
    前記相手端末から送信されたデータをＲＴＰペイロードのフォーマットを用いて受信し、
    前記相手端末との通信開始時に、ＳＤＰオファー/アンサーによる折衝を行った結果に基づいて、前記相手端末との通信に用いるコーデックモードまたはコーデックセットを決定し、
    前記ＲＴＰペイロードは、ＳＤＰオファー/アンサーによる折衝に基づいて、当該ＲＴＰペイロードのヘッダ部に、前記相手端末にコーデックモードの変更を要求するコーデックモードリクエストのフィールドを含むか否かが設定され、前記コーデックモードは、ビットレート情報を含む、
    通信方法。
  7. 前記ＲＴＰペイロードにおいて、前記ヘッダ部に前記コーデックモードリクエストを含めると設定された場合、前記コーデックモードリクエストを前記ヘッダ部に含めて送信する、
    請求項６に記載の通信方法。
  8. 前記ＲＴＰペイロードは、データ部を含み、
    前記ビットレート情報は、
    前記データ部におけるデータ基本部及び拡張部のビットレートであって、前記ヘッダ部に含まれ、
    前記データ部は、前記データ基本部と前記拡張部とのビットレートの組み合わせ情報を含む、
    請求項６に記載の通信方法。
  9. 前記ＲＴＰペイロードは、データ部を含み、
    前記ビットレート情報は、
    前記データ部におけるデータ基本部及び拡張部のビットレートであって、どのコーデックモードの組み合わせ又はどのビットレートの組み合わせが使われているかは含まない、
    請求項６に記載の通信方法。
  10. 前記ヘッダ部は、ＳＤＰオファー/アンサーによる折衝後、自端末で使用中のコーデックモードを示すフィールドを含む、
    請求項６に記載の通信方法。
JP2016240409A 2010-11-10 2016-12-12 通信端末及び通信方法 Active JP6313839B2 (ja)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
JP2010252113 2010-11-10
JP2010252113 2010-11-10
JP2010278222 2010-12-14
JP2010278222 2010-12-14
JP2011084442 2011-04-06
JP2011084442 2011-04-06
JP2011173910 2011-08-09
JP2011173910 2011-08-09

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2012542796A Division JP6061679B2 (ja) 2010-11-10 2011-10-26 通信端末及び通信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018054352A Division JP6595650B2 (ja) 2010-11-10 2018-03-22 通信端末、通信方法、及び集積回路

Publications (2)

Publication Number Publication Date
JP2017060191A JP2017060191A (ja) 2017-03-23
JP6313839B2 true JP6313839B2 (ja) 2018-04-18

Family

ID=46050588

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2012542796A Active JP6061679B2 (ja) 2010-11-10 2011-10-26 通信端末及び通信方法
JP2016240409A Active JP6313839B2 (ja) 2010-11-10 2016-12-12 通信端末及び通信方法
JP2018054352A Active JP6595650B2 (ja) 2010-11-10 2018-03-22 通信端末、通信方法、及び集積回路

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2012542796A Active JP6061679B2 (ja) 2010-11-10 2011-10-26 通信端末及び通信方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2018054352A Active JP6595650B2 (ja) 2010-11-10 2018-03-22 通信端末、通信方法、及び集積回路

Country Status (6)

Country Link
US (2) US9401975B2 (ja)
EP (2) EP2640052B1 (ja)
JP (3) JP6061679B2 (ja)
ES (1) ES2749222T3 (ja)
PL (1) PL2640052T3 (ja)
WO (1) WO2012063417A1 (ja)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8542802B2 (en) 2007-02-15 2013-09-24 Global Tel*Link Corporation System and method for three-way call detection
US9225838B2 (en) 2009-02-12 2015-12-29 Value-Added Communications, Inc. System and method for detecting three-way call circumvention attempts
EP2590164B1 (en) * 2010-07-01 2016-12-21 LG Electronics Inc. Audio signal processing
WO2012063417A1 (ja) * 2010-11-10 2012-05-18 パナソニック株式会社 端末及びコーデックモード選択方法
EP2745499B1 (en) * 2011-08-17 2019-03-27 Telefonaktiebolaget LM Ericsson (publ) Mechanism for dynamic signaling of encoder capabilities
USRE49284E1 (en) 2013-10-17 2022-11-08 Panasonic Intellectual Property Corporation Of America Method for controlling cordless telephone device, handset of cordless telephone device, and cordless telephone device
JP6309382B2 (ja) * 2013-10-17 2018-04-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ コードレス電話機器の制御方法、コードレス電話機器の子機及びコードレス電話機器
EP3917112B1 (en) * 2013-11-27 2022-10-05 Telefonaktiebolaget LM Ericsson (publ) Hybrid rtp payload format
KR101864122B1 (ko) 2014-02-20 2018-06-05 삼성전자주식회사 전자 장치 및 전자 장치의 제어 방법
US9397947B2 (en) 2014-03-11 2016-07-19 International Business Machines Corporation Quality of experience for communication sessions
US9680507B2 (en) * 2014-07-22 2017-06-13 Qualcomm Incorporated Offset selection for error correction data
KR102318763B1 (ko) 2014-08-28 2021-10-28 삼성전자주식회사 기능 제어 방법 및 이를 지원하는 전자 장치
JP6634686B2 (ja) * 2015-03-11 2020-01-22 株式会社リコー 情報処理装置、プログラム、通信プラットフォーム決定方法、伝送システム
US9917673B2 (en) * 2015-03-12 2018-03-13 Telefonaktiebolaget Lm Ericsson (Publ) Rate control in circuit switched systems
CN105100046A (zh) * 2015-05-19 2015-11-25 华为技术有限公司 一种媒体互通方法及其装置
WO2016185649A1 (ja) * 2015-05-20 2016-11-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信ノード、端末及び通信制御方法
WO2017045115A1 (zh) * 2015-09-15 2017-03-23 华为技术有限公司 一种建立无线承载的方法及网络设备
KR102477464B1 (ko) * 2015-11-12 2022-12-14 삼성전자주식회사 무선 통신 시스템에서 음성 패킷의 크기를 제어하기 위한 장치 및 방법
KR102401477B1 (ko) * 2015-11-24 2022-05-25 삼성전자주식회사 사용자 단말 장치 및 그 제어 방법
US10035438B2 (en) * 2016-02-22 2018-07-31 Ford Global Technologies, Llc Vehicle seat bottom with independently deployable devices
JP7019561B2 (ja) * 2016-03-28 2022-02-15 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 端末及びコーデックモード切替方法
US10057393B2 (en) 2016-04-05 2018-08-21 T-Mobile Usa, Inc. Codec-specific radio link adaptation
WO2017177382A1 (zh) * 2016-04-12 2017-10-19 广东欧珀移动通信有限公司 用于确定业务通信的编解码模式集的方法和装置
CN111224857A (zh) * 2016-06-29 2020-06-02 华为技术有限公司 用于实现组合虚拟专用网vpn的方法与装置
US10616376B2 (en) * 2016-07-20 2020-04-07 Vivint, Inc. Communications protocol
WO2018031614A1 (en) * 2016-08-11 2018-02-15 Kyocera Corporation Ran-assisted rate adaptation
WO2018064386A1 (en) * 2016-09-30 2018-04-05 Kyocera Corporation Ran-assisted rate adaptation under mobility
US9930088B1 (en) * 2017-06-22 2018-03-27 Global Tel*Link Corporation Utilizing VoIP codec negotiation during a controlled environment call
US10469668B1 (en) * 2017-08-30 2019-11-05 Sprint Spectrum L.P. Determining access parameters based on likelihood of HD voice service
JP2019066205A (ja) * 2017-09-28 2019-04-25 サトーホールディングス株式会社 検査システム、検査方法
US10728303B2 (en) 2017-12-05 2020-07-28 At&T Intellectual Property I, L.P. Codec selection for end-to-end communication without intermediate transcoding
CN116566958A (zh) * 2018-09-07 2023-08-08 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
KR102526699B1 (ko) * 2018-09-13 2023-04-27 라인플러스 주식회사 통화 품질 정보를 제공하는 방법 및 장치
WO2020092818A1 (en) 2018-11-02 2020-05-07 Intel Corporation Signaling codec mode notifications for multimedia telephony sessions
US11689583B2 (en) * 2018-12-10 2023-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Network node, entity and methods performed therein for handling a communication session in a communication network
CN114040130A (zh) * 2021-11-05 2022-02-11 深圳市瑞云科技有限公司 动态切换单双声道的方法、系统及计算机可读存储介质
WO2023219210A1 (ko) * 2022-05-10 2023-11-16 삼성전자 주식회사 적응형 polar coding configuration 송수신 방법 및 장치

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9616237D0 (en) 1996-08-01 1996-09-11 Norton Healthcare Ltd Aerosol formulations
JP3310205B2 (ja) 1997-10-01 2002-08-05 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム
US6512924B2 (en) 1997-10-01 2003-01-28 Ntt Mobile Communications Network Inc. Mobile communications system
CN101917745B (zh) * 1999-05-17 2013-05-01 艾利森电话股份有限公司 用于电信网络中的能力协商的系统、设备和方法
EP2043375B1 (en) 1999-05-17 2011-10-26 Telefonaktiebolaget LM Ericsson (publ) Capability negotiation in a telecommunications network
US20010041981A1 (en) * 2000-02-22 2001-11-15 Erik Ekudden Partial redundancy encoding of speech
EP1968282A3 (en) * 2000-08-14 2008-11-26 Nokia Siemens Networks Oy System, method and devices providing a communication mode selection procedure
US20020163908A1 (en) * 2001-05-07 2002-11-07 Ari Lakaniemi Apparatus, and associated method, for synchronizing operation of codecs operable pursuant to a communicaton session
WO2003041408A1 (fr) * 2001-11-05 2003-05-15 Matsushita Electric Industrial Co., Ltd. Terminal utilise dans un systeme de transmission video
US7778242B1 (en) * 2001-11-27 2010-08-17 Alcatel Lucent Protecting content of a packet containing speech data using unequal error protection
BR0215544A (pt) 2002-06-07 2004-12-28 Siemens Ag Processo e disposição para a transmissão de pacotes-ip entre um rádio controlada de rede e uma outra instalação de uma rede de rádio móvel
FI116498B (fi) 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
TWI517649B (zh) 2003-12-01 2016-01-11 內數位科技公司 以會話初始化協定為基礎之使用者啟動換手
JP2005167458A (ja) * 2003-12-01 2005-06-23 Matsushita Electric Ind Co Ltd 音声画像伝送方法
JP2005175694A (ja) 2003-12-09 2005-06-30 Toyota Motor Corp 音声通信装置、及び、音声通信方法
US8085678B2 (en) 2004-10-13 2011-12-27 Qualcomm Incorporated Media (voice) playback (de-jitter) buffer adjustments based on air interface
JP4507822B2 (ja) 2004-10-21 2010-07-21 日本電気株式会社 音楽提供システム、音楽提供方法及び音楽提供用プログラム
WO2006066246A2 (en) * 2004-12-15 2006-06-22 Dilithium Networks Pty Ltd. Fast session setup extensions to h.324
KR100800794B1 (ko) * 2005-07-01 2008-02-04 삼성전자주식회사 패킷망을 통해 음성 서비스를 지원하는 이동통신시스템에서 음성 서비스의 전송률을 제어하는 방법 및 장치
WO2007034809A1 (ja) * 2005-09-20 2007-03-29 Taisho Pharmaceutical Co., Ltd. 組み換え蛋白質産生のための宿主細胞
EP1768337A1 (en) 2005-09-26 2007-03-28 Alcatel Intelligent border element
DE102005050586B3 (de) * 2005-10-21 2006-11-02 Siemens Ag Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
JP4782847B2 (ja) 2006-03-02 2011-09-28 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 広帯域コーデック・ネゴシエーション
US20080077410A1 (en) * 2006-09-26 2008-03-27 Nokia Corporation System and method for providing redundancy management
US20080117906A1 (en) * 2006-11-20 2008-05-22 Motorola, Inc. Payload header compression in an rtp session
JP4937005B2 (ja) 2007-06-13 2012-05-23 三菱電機株式会社 音声伝送装置
KR101167523B1 (ko) * 2008-01-17 2012-07-20 노키아 코포레이션 무선 시스템에서의 적응적 멀티-레이트 코덱 비트 레이트 제어
CN102077558A (zh) 2008-07-16 2011-05-25 日本电气株式会社 用于网关的装置和方法及程序
KR101523590B1 (ko) * 2009-01-09 2015-05-29 한국전자통신연구원 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기
US9454973B2 (en) * 2009-04-07 2016-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for providing a backwards compatible payload format
WO2010117326A1 (en) * 2009-04-07 2010-10-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for session negotiation
JP5019234B2 (ja) 2009-04-16 2012-09-05 Ｎｅｃアクセステクニカ株式会社 通信システムおよび障害切り分け試験方法
JP5303364B2 (ja) 2009-05-28 2013-10-02 日東電工株式会社 両面配線回路基板およびその製造方法
WO2010142312A1 (en) * 2009-06-12 2010-12-16 Telefonaktiebolaget L M Ericsson (Publ) Monitoring of delay in packet-switched networks
US9432414B2 (en) * 2009-08-25 2016-08-30 Nokia Solutions And Networks Oy Control of codec negotiation for communication connection
JP2011084442A (ja) 2009-10-16 2011-04-28 Doshisha 細線状チタン化合物、色素増感型太陽電池用チタニア電極および色素増感型太陽電池
US8416690B2 (en) * 2010-01-11 2013-04-09 Research In Motion Limited Explicit congestion notification based rate adaptation using binary marking in communication systems
US9398517B2 (en) * 2010-01-11 2016-07-19 Blackberry Limited System and method for enabling discovery of local service availability in local cellular coverage
WO2012063417A1 (ja) * 2010-11-10 2012-05-18 パナソニック株式会社 端末及びコーデックモード選択方法
WO2012077701A1 (ja) * 2010-12-07 2012-06-14 日本電気株式会社 ゲートウェイ装置および音声通信方法
US9031679B2 (en) * 2012-05-15 2015-05-12 Ixia Methods, systems, and computer readable media for utilizing a plurality of pre-encoded payloads to generate a packet stream transmission

Also Published As

Publication number Publication date
WO2012063417A1 (ja) 2012-05-18
US20130230057A1 (en) 2013-09-05
JP2018121357A (ja) 2018-08-02
US9401975B2 (en) 2016-07-26
EP3554127B1 (en) 2020-09-09
ES2749222T3 (es) 2020-03-19
EP3554127A1 (en) 2019-10-16
PL2640052T3 (pl) 2019-12-31
EP2640052A1 (en) 2013-09-18
JP2017060191A (ja) 2017-03-23
EP2640052B1 (en) 2019-07-24
JP6061679B2 (ja) 2017-01-18
JPWO2012063417A1 (ja) 2014-05-12
US20160301777A1 (en) 2016-10-13
US10645198B2 (en) 2020-05-05
JP6595650B2 (ja) 2019-10-23
EP2640052A4 (en) 2017-11-29

Similar Documents

Publication Publication Date Title
JP6595650B2 (ja) 通信端末、通信方法、及び集積回路
US11647428B2 (en) Communication terminal apparatus and communication method
US8165090B2 (en) Efficient handover of media communications in heterogeneous IP networks
US11405432B2 (en) Communication apparatus, base station, and codec mode switching method
JP6454683B2 (ja) 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
US11799922B2 (en) Network core facilitating terminal interoperation
WO2012063889A1 (ja) コアネットワークおよび通信システム
CN102047648A (zh) 移动通信系统、节点装置以及网间转移控制方法
WO2012063888A1 (ja) コアネットワークおよび通信システム
US20160353509A1 (en) Wireless communication network bearer management
US9350764B2 (en) Gateway apparatus and method and communication system
WO2012063890A1 (ja) コアネットワークおよび通信システム

Legal Events

Date Code Title Description
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: 20180306

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180323

R150 Certificate of patent or registration of utility model

Ref document number: 6313839

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150