(57)【要約】  端末が保有している情報を折衝情報として用いることにより、ネットワーク及び端末の双方に負荷をかけることなく、端末間の通信経路の状況を判断し、適切なコーデックモードを選択できる端末。ＵＥ（１００）は、ＵＥ（１００）とその通信相手である相手端末との間の通信開始時に、相手端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを相手端末に送信する端末であって、相手端末が現在接続しているアクセス網の特性に関する第１の情報を受信する無線受信部（６００）と、第１の情報と、自機が現在接続しているアクセス網の特性に関する第２の情報とを比較し、自機と相手端末との間の通信形態を判断する情報比較部（６０６）と、判断された通信形態に基づいて、複数のコーデックモード候補の中から、相手端末との通信で使用するコーデックモードを選択するモード決定部（６０８）とを有する。
2012063417.tif 000002
【特許請求の範囲】
【請求項１】
端末と前記端末の通信相手である相手端末との間の通信開始時に、前記相手端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記相手端末に送信する端末であって、
前記相手端末が現在接続しているアクセス網の特性に関する第１の情報を受信する受信手段と、
前記第１の情報と、自機が現在接続しているアクセス網の特性に関する第２の情報とを比較し、自機と前記相手端末との間の通信形態を判断する判断手段と、
前記判断手段で判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する選択手段と、
を具備する端末。
【請求項２】
前記判断手段は、前記通信形態が、同一の基地局、複数の基地局、又は、複数の基地局及びＶＰＮ（Virtual Private Network）バックボーンで構成される通信網で接続された第１の通信形態、ＩＰコア網を介した異なる基地局に接続された第２の通信形態、及び、前記第１の通信形態及び前記第２の通信形態のそれぞれと異なる第３の通信形態のいずれであるかを判断し、
前記選択手段は、前記通信形態が前記第１の通信形態の場合に最も高品質なコーデックモードを選択し、前記通信形態が、前記第２の通信形態の場合、前記第３の通信形態の場合よりも高品質なコーデックモードを選択する、
請求項１記載の端末。
【請求項３】
前記第１の情報は、呼制御のための処理機能を有するネットワークノードを経由して前記相手端末から前記端末へ送信され、
前記ネットワークノードは、前記第１の情報の妥当性を確認する、
請求項１記載の端末。
【請求項４】
前記受信手段は、更に、前記ネットワークノードでの前記妥当性の確認結果を受信し、
前記判断手段は、前記確認結果に基づいて、前記通信形態の判断を行うか否かを決定する、
請求項３記載の端末。
【請求項５】
前記受信手段は、更に、前記相手端末のハンドオーバの可能性の有無を示す第３の情報を受信し、
前記判断手段は、前記第１の情報、前記第２の情報、前記第３の情報、及び、自機のハンドオーバの可能性の有無を示す第４の情報に基づいて、前記通信形態を判断する、
請求項１記載の端末。
【請求項６】
前記第３の情報及び前記第４の情報は、前記相手端末及び前記端末のそれぞれが、据え置き型の装置であるか否か、据え置き型のノードに接続されているか否か、又は、通信モードが電話会議モードに設定されているか否か、を示す、
請求項５記載の端末。
【請求項７】
通信中の自機又は前記相手端末において、ハンドオーバの可能性が変化した場合、現在使用しているコーデックモードを変更する変更手段を、更に具備する、
請求項５記載の端末。
【請求項８】
前記第１の情報及び前記第２の情報は、ＣＳＧ  ＩＤ（Closed Subscriber Group Identifier）、又は、基地局ＩＤである、
請求項１記載の端末。
【請求項９】
前記アクセス網の特性は、１端末あたりに割当可能な無線リソース量である、
請求項１記載の端末。
【請求項１０】
前記コーデックモードには、ビットレート及び処理遅延が含まれる、
請求項１記載の端末。
【請求項１１】
前記選択手段で選択された、前記相手端末との通信で使用するコーデックモードは、ＲＴＰ（Real-time Transport Protocol）ペイロードを用いて通知される、
請求項１記載の端末。
【請求項１２】
前記ＲＴＰペイロードは、ヘッダ部とデータ部とから成り、
前記ヘッダ部の長さは、相手端末との通信で使用するコーデックモードに応じて変更される、
請求項１１記載の端末。
【請求項１３】
前記ＲＴＰペイロードは、ヘッダ部とデータ部とから成り、
前記ヘッダ部は、全てのＲＴＰペイロードにおいて常に設けられる第１のヘッダと、全てのＲＴＰペイロードにおいて常に設けられるとは限らない第２のヘッダとを含む、
請求項１１記載の端末。
【請求項１４】
前記第１のヘッダには、前記第２のヘッダが設けられるか否かを示すフィールドが含まれる、
請求項１３記載の端末。
【請求項１５】
前記選択手段は、更に、前記複数のコーデックモード候補のうち、前記端末に対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、
請求項１記載の端末。
【請求項１６】
前記相手端末から通知される前記複数のコーデックモード候補には、前記相手端末に対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード候補が含まれる、
請求項１５記載の端末。
【請求項１７】
前記ポリシーには、前記オペレータが優先的に使用する、コーデックの方式、コーデックビットレート、サンプリングレート、オーディオ帯域、処理遅延、チャンネル数、セッション途中でのビットレート及びチャンネル数の切り替えを許可するか否か、Variable Bit Rate（ＶＢＲ）オペレーションを許可するか否か、又は、冗長フレームを許可するか否かが含まれる、
請求項１５記載の端末。
【請求項１８】
前記ＲＴＰペイロードは、データ部と、全てのＲＴＰペイロードにおいて常に設けられるとは限らない後続シグナリング部と、全てのＲＴＰペイロードにおいて常に設けられる、前記後続シグナリング部の有無を示すフィールドと、を含み、
前記コーデックモードは、前記後続シグナリング部を用いて通知される、
請求項１１記載の端末。
【請求項１９】
前記ＲＴＰペイロードは、データ部と、全てのＲＴＰペイロードにおいて常に設けられるとは限らないヘッダ部と、全てのＲＴＰペイロードにおいて常に設けられる、前記ヘッダ部の有無を示すフィールドと、を含み、
前記コーデックモードは、前記ヘッダ部を用いて通知される、
請求項１１記載の端末。
【請求項２０】
前記相手端末が生成した前記複数のコーデックモード候補を含む第３の情報は、呼制御のための処理機能を有するネットワークノードを経由して前記端末へ送信され、
前記ネットワークノードは、前記端末が現在接続しているアクセス網が前記ネットワークノードの配下である場合、前記第３の情報に示される前記複数のコーデックモード候補を変更し、
前記選択手段は、変更後の前記第３の情報に含まれる前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、
請求項１記載の端末。
【請求項２１】
前記ネットワークノードは、更に、前記第３の情報を確認したか否かを示す確認情報を前記端末へ送信し、
前記選択手段は、前記第３の情報を確認済みであることを前記確認情報が示す場合、変更後の前記第３の情報に含まれる前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、
請求項２０記載の端末。
【請求項２２】
第１の端末と前記第１の端末の通信相手である第２の端末との間の通信開始時に、前記第１の端末が、前記第２の端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記第２の端末に送信する通信システムにおいて、
前記第２の端末が、前記第２の端末が現在接続しているアクセス網の特性に関する第１の情報を前記第１の端末に通知するステップと、
前記第１の端末が、前記第１の情報を受信するステップと、
前記第１の端末が、前記第１の情報と、前記第１の端末が現在接続しているアクセス網の特性に関する第２の情報とを比較し、前記第１の端末と前記第２の端末との間の通信形態を判断するステップと、
前記第１の端末が、判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記第２の端末との通信で使用するコーデックモードを選択するステップと、
を具備するコーデックモード選択方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末の接続先の無線アクセス網（無線アクセスネットワーク）の特性を用いた好適なコーデックモード選択を行う端末及びコーデックモード選択方法に関する。
【背景技術】
【０００２】
３ＧＰＰ（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の使用が推奨されている。
【先行技術文献】
【非特許文献】
【００１６】
【非特許文献１】IETF RFC 4867, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs"
【非特許文献２】3GPP TS 26.114 v9.3.0, "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction"
【非特許文献３】3GPP TS 26.101 v9.0.0, "Mandatory speech codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec frame structure"
【非特許文献４】3GPP TS 26.201 v9.0.0, "Speech codec speech processing functions; Adaptive Multi-Rate-Wideband (AMR-WB) speech codec Frame structure"
【発明の概要】
【発明が解決しようとする課題】
【００１７】
上述した通話開始時のネゴシエーションでのコーデックモード選択は、データのやり取りが実際に行われるネットワークの状況とは独立に行われる。このため、通話開始時点、或いは、通話期間全体で使用されるコーデックモードとして、適切なコーデックモードが選択されない場合があるという課題がある。現在３ＧＰＰ  ＳＡ４で議論されているＥＶＳ（Enhanced Voice Services）では、ＡＭＲ及びＡＭＲ−ＷＢに比べ、より高ビットレートのサポート、複数の処理遅延のサポート、２チャンネル（ステレオ）のサポート等が考えられている。このため、特にＥＶＳでは、好適なコーデックモードの選択が求められる。【００１８】
上記課題に対して、ＵＥが現在のAir Interfaceの帯域幅をサーバに通知し、Air Interfaceの帯域幅に基づいてサーバにビットレートを決定させる方法が提案されている（例えば、「特表２００６−５００８０８号公報」を参照）。また、ＵＥが無線区間の状況をモニタリングし、無線区間の状況に応じて好適なデジッタ  バッファ(de-Jitter Buffer)長を調整する方法が提案されている（例えば、「米国特許出願公開第２００６／００７７９９４号明細書」を参照）。【００１９】
しかしながら、どちらの方法も、ＵＥが無線の状態（現在のAir Interfaceの帯域幅又は無線区間の状況）をモニタリングする分、ＵＥに負担がかかる。その上、上記方法では、エンド  ツー  エンド(End-to-End)での通信状況（ＵＥ間の通信経路の品質）は考慮されていない。【００２０】
また、非特許文献２には、ネゴシエーション時に、通信状況に関わらず確実に通信可能なコーデックモード（つまり、ネゴシエーション失敗が生じる可能性が低いコーデックモード）を選択する方法が記載されている。そして、非特許文献２には、更に、ネゴシエーションで選択されたコーデックビットレートの範囲のうち、低いコーデックビットレートを用いて通話を開始する方法が記載されている。この方法では、通話開始後、エンド  ツー  エンドのネットワークの通信状況（ＵＥ間の通信経路の品質）に応じて、選択されたコーデックビットレートの範囲内でコーデックビットレートを調整する。しかし、この方法では、通話開始時から適当なコーデックビットレート（実際の通信状況に適したコーデックビットレート）を設定できない上、通話期間全体において使用可能なコーデックビットレートの上限も限定されてしまう。【００２１】
一方、ネットワークノードが、ネットワークの通信状況（ＵＥ間の通信経路の品質）をＵＥにフィードバックし、ＵＥがネットワークの通信状況に応じてコーデックモードを選択する方法も考えられる。しかし、この方法では、ネットワークのトラフィック量が増大し、ネットワークに負担がかかってしまう。【００２２】
本発明の目的は、ネットワーク及び端末（ＵＥ）に対する処理負荷を抑えつつ、端末間の通信経路の品質に応じたコーデックモードを通信の初期段階から選択することができる通信端末及びコーデックモード選択方法を提供することである。
【課題を解決するための手段】
【００２３】
本発明の一態様に係る端末は、端末と前記端末の通信相手である相手端末との間の通信開始時に、前記相手端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記相手端末に送信する端末であって、前記相手端末が現在接続しているアクセス網の特性に関する第１の情報を受信する受信手段と、前記第１の情報と、自機が現在接続しているアクセス網の特性に関する第２の情報とを比較し、自機と前記相手端末との間の通信形態を判断する判断手段と、前記判断手段で判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する選択手段と、を具備する構成を採る。【００２４】
本発明の一態様に係るコーデックモード選択方法は、第１の端末と前記第１の端末の通信相手である第２の端末との間の通信開始時に、前記第１の端末が、前記第２の端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記第２の端末に送信する通信システムにおいて、前記第２の端末が、前記第２の端末が現在接続しているアクセス網の特性に関する第１の情報を前記第１の端末に通知するステップと、前記第１の端末が、前記第１の情報を受信するステップと、前記第１の端末が、前記第１の情報と、前記第１の端末が現在接続しているアクセス網の特性に関する第２の情報とを比較し、前記第１の端末と前記第２の端末との間の通信形態を判断するステップと、前記第１の端末が、判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記第２の端末との通信で使用するコーデックモードを選択するステップと、を具備するようにした。
【発明の効果】
【００２５】
本発明によれば、端末が保有している情報を折衝情報として用いることにより、ネットワーク及び端末の双方に処理負荷をかけることなく、端末間の通信経路の状況を判断し、適切なコーデックモードを選択できる。
【図面の簡単な説明】
【００２６】
【図１】ＩＭＳ網、ＩＰコア網及び無線アクセス網の構成の一例を示す図
【図２】通話セッション確立の基本動作の一例を示す図
【図３】ＳＤＰオファー及びＳＤＰアンサーの一例を示す図
【図４】本発明の各実施の形態に係るネットワークの構成の一例を示す図
【図５】本発明の各実施の形態に係るネットワークの構成の一例を示す図
【図６】本発明の各実施の形態に係るＲＴＰパケットの説明に供する図
【図７】本発明の実施の形態１に係る端末（ＵＥ）の構成を示すブロック図
【図８】本発明の実施の形態１に係るＳＤＰオファーの一例を示す図
【図９】本発明の実施の形態１に係るコーデックモードセットと番号との対応付けを示す図
【図１０】本発明の実施の形態１に係る情報比較部及びモード決定部における処理の流れを示すフロー図
【図１１】本発明の実施の形態１に係るＳＤＰアンサーの一例を示す図
【図１２】本発明の実施の形態２に係るネットワークノードの構成を示すブロック図
【図１３】本発明の実施の形態３に係る端末（ＵＥ）の構成を示すブロック図
【図１４】本発明の実施の形態３に係るＳＤＰオファーの一例を示す図
【図１５】本発明の実施の形態３に係るコーデックモードセットと番号との対応付けを示す図
【図１６】本発明の実施の形態３に係る情報比較部及びモード決定部における処理の流れを示すフロー図
【図１７】本発明の実施の形態３に係るＳＤＰアンサーの一例を示す図
【図１８】本発明の実施の形態３に係るＩＰパケットのフォーマットの一例を示す図
【図１９】本発明の実施の形態４に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第１の例）
【図２０】本発明の実施の形態４に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第２の例）
【図２１】本発明の実施の形態４に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第３の例）
【図２２】本発明の実施の形態５に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第１の例）
【図２３】本発明の実施の形態５に係るコーデックモードの番号対応付け及びＲＴＰペイロードフォーマットを示す図（第２の例）
【図２４】本発明の実施の形態６に係るオペレータのポリシー及びＳＤＰオファーの一例を示す図
【図２５】本発明の実施の形態６に係るオペレータのポリシー及びＳＤＰアンサーの一例を示す図
【図２６】本発明の実施の形態７に係るネットワークの構成の一例を示す図
【図２７】本発明の実施の形態７に係るＩＰ−ＰＢＸの構成を示すブロック図
【図２８】本発明の実施の形態８に係るＲＴＰペイロードフォーマットの第１の例を示す図
【図２９】本発明の実施の形態８に係るＲＴＰペイロードフォーマットの第２の例を示す図
【図３０】本発明の実施の形態８に係るＲＴＰペイロードフォーマットの第３例を示す図
【発明を実施するための形態】
【００２７】
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
【００２８】
図４は、本発明の各実施の形態に係るネットワーク構成と、端末の位置関係の一例を示す図である。なお、図４において、図１と同一構成である部分には同一の符号を付してその説明を省略する。
【００２９】
ＨｅＮＢ（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）、ＬＳＩ内部の回路セルの接続または設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。
【０２７１】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【０２７２】
２０１０年１１月１０日出願の特願２０１０−２５２１１３の日本出願、２０１０年１２月１４日出願の特願２０１０−２７８２２２の日本出願、２０１１年４月６日出願の特願２０１１−８４４４２の日本出願、及び２０１１年８月９日出願の特願２０１１−１７３９１０の日本出願に含まれる明細書、図面及び要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【０２７３】
本発明は、特に、通信開始時にシグナリングメッセージによってネゴシエーションを行う端末等に好適である。
【符号の説明】
【０２７４】
１００，１０２  ＵＥ
１０４，１０６  ｅＮＢ
１０８，１１６  Ｐ−ＣＳＣＦ
１１０，１１４  Ｓ−ＣＳＣＦ
１１２  Ｉ−ＣＳＣＦ
１１８  ＨＳＳ
１２０，１２２，４０６，４０８，５０６，５０８，２６０６，２６０８  無線アクセス網
１２４  ＩＰコア網
１２６  ＩＭＳ網
４００，４０２，５００，５０２  ＨｅＮＢ
４０４  Ｌｏｃａｌ  ＧＷ
６００  無線受信部
６０２  無線送信部
６０４  接続先判断部
６０６  情報比較部
６０８  モード決定部
６１０，７０８，２７１０  シグナリング生成部
７００，２７００  受信部
７０２，２７０２  送信部
７０４，２７０６  シグナリング解析部
７０６，２７０８  端末位置情報確認部
８１２  状態解析部
８１４  モード変更部
２６００，２６０２，２６１４  ＡＰ
２６０４  ＩＰ−ＰＢＸ
２６１０  ＩＰ網
２６１２  サーバ
２７０４  シグナリングインタセプト部
【図１】
2012063417.tif 000003
【図２】
2012063417.tif 000004
【図３】
2012063417.tif 000005
【図４】
2012063417.tif 000006
【図５】
2012063417.tif 000007
【図６】
2012063417.tif 000008
【図７】
2012063417.tif 000009
【図８】
2012063417.tif 000010
【図９】
2012063417.tif 000011
【図１０】
2012063417.tif 000012
【図１１】
2012063417.tif 000013
【図１２】
2012063417.tif 000014
【図１３】
2012063417.tif 000015
【図１４】
2012063417.tif 000016
【図１５】
2012063417.tif 000017
【図１６】
2012063417.tif 000018
【図１７】
2012063417.tif 000019
【図１８】
2012063417.tif 000020
【図１９】
2012063417.tif 000021
【図２０】
2012063417.tif 000022
【図２１】
2012063417.tif 000023
【図２２】
2012063417.tif 000024
【図２３】
2012063417.tif 000025
【図２４】
2012063417.tif 000026
【図２５】
2012063417.tif 000027
【図２６】
2012063417.tif 000028
【図２７】
2012063417.tif 000029
【図２８】
2012063417.tif 000030
【図２９】
2012063417.tif 000031
【図３０】
2012063417.tif 000032
【手続補正書】
【提出日】平成25年5月22日(2013.5.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
端末と前記端末の通信相手である相手端末との間の通信開始時に、前記相手端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記相手端末に送信する端末であって、
前記相手端末が現在接続しているアクセス網の特性に関する第１の情報を受信する受信手段と、
前記第１の情報と、自機が現在接続しているアクセス網の特性に関する第２の情報とを比較し、自機と前記相手端末との間の通信形態を判断する判断手段と、
前記判断手段で判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する選択手段と、
を具備する端末。
【請求項２】
前記判断手段は、前記通信形態が、同一の基地局、複数の基地局、又は、複数の基地局及びＶＰＮ（Virtual Private Network）バックボーンで構成される通信網で接続された第１の通信形態、ＩＰコア網を介した異なる基地局に接続された第２の通信形態、及び、前記第１の通信形態及び前記第２の通信形態のそれぞれと異なる第３の通信形態のいずれであるかを判断し、
前記選択手段は、前記通信形態が前記第１の通信形態の場合に最も高品質なコーデックモードを選択し、前記通信形態が、前記第２の通信形態の場合、前記第３の通信形態の場合よりも高品質なコーデックモードを選択する、
請求項１記載の端末。
【請求項３】
前記第１の情報は、呼制御のための処理機能を有するネットワークノードを経由して前記相手端末から前記端末へ送信され、
前記ネットワークノードは、前記第１の情報の妥当性を確認する、
請求項１記載の端末。
【請求項４】
前記受信手段は、更に、前記ネットワークノードでの前記妥当性の確認結果を受信し、
前記判断手段は、前記確認結果に基づいて、前記通信形態の判断を行うか否かを決定する、
請求項３記載の端末。
【請求項５】
前記受信手段は、更に、前記相手端末のハンドオーバの可能性の有無を示す第３の情報を受信し、
前記判断手段は、前記第１の情報、前記第２の情報、前記第３の情報、及び、自機のハンドオーバの可能性の有無を示す第４の情報に基づいて、前記通信形態を判断する、
請求項１記載の端末。
【請求項６】
前記第３の情報及び前記第４の情報は、前記相手端末及び前記端末のそれぞれが、据え置き型の装置であるか否か、据え置き型のノードに接続されているか否か、又は、通信モードが電話会議モードに設定されているか否か、を示す、
請求項５記載の端末。
【請求項７】
通信中の自機又は前記相手端末において、ハンドオーバの可能性が変化した場合、現在使用しているコーデックモードを変更する変更手段を、更に具備する、
請求項５記載の端末。
【請求項８】
前記第１の情報及び前記第２の情報は、ＣＳＧ  ＩＤ（Closed Subscriber Group Identifier）、又は、基地局ＩＤである、
請求項１記載の端末。
【請求項９】
前記アクセス網の特性は、１端末あたりに割当可能な無線リソース量である、
請求項１記載の端末。
【請求項１０】
前記コーデックモードには、ビットレート及びアルゴリズム遅延が含まれる、
請求項１記載の端末。
【請求項１１】
前記選択手段で選択された、前記相手端末との通信で使用するコーデックモードは、ＲＴＰ（Real-time Transport Protocol）ペイロードを用いて通知される、
請求項１記載の端末。
【請求項１２】
前記ＲＴＰペイロードは、ヘッダ部とデータ部とから成り、
前記ヘッダ部の長さは、相手端末との通信で使用するコーデックモードに応じて変更される、
請求項１１記載の端末。
【請求項１３】
前記ＲＴＰペイロードは、ヘッダ部とデータ部とから成り、
前記ヘッダ部は、全てのＲＴＰペイロードにおいて常に設けられる第１のヘッダと、全てのＲＴＰペイロードにおいて常に設けられるとは限らない第２のヘッダとを含む、
請求項１１記載の端末。
【請求項１４】
前記第１のヘッダには、前記第２のヘッダが設けられるか否かを示すフィールドが含まれる、
請求項１３記載の端末。
【請求項１５】
前記選択手段は、更に、前記複数のコーデックモード候補のうち、前記端末に対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、
請求項１記載の端末。
【請求項１６】
前記相手端末から通知される前記複数のコーデックモード候補には、前記相手端末に対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード候補が含まれる、
請求項１５記載の端末。
【請求項１７】
前記ポリシーには、前記オペレータが優先的に使用する、コーデックの方式、コーデックビットレート、サンプリングレート、オーディオ帯域、アルゴリズム遅延、チャンネル数、セッション途中でのビットレート及びチャンネル数の切り替えを許可するか否か、Variable Bit Rate（ＶＢＲ）オペレーションを許可するか否か、又は、冗長フレームを許可するか否かが含まれる、
請求項１５記載の端末。
【請求項１８】
前記ＲＴＰペイロードは、データ部と、全てのＲＴＰペイロードにおいて常に設けられるとは限らない後続シグナリング部と、全てのＲＴＰペイロードにおいて常に設けられる、前記後続シグナリング部の有無を示すフィールドと、を含み、
前記コーデックモードは、前記後続シグナリング部を用いて通知される、
請求項１１記載の端末。
【請求項１９】
前記ＲＴＰペイロードは、データ部と、全てのＲＴＰペイロードにおいて常に設けられるとは限らないヘッダ部と、全てのＲＴＰペイロードにおいて常に設けられる、前記ヘッダ部の有無を示すフィールドと、を含み、
前記コーデックモードは、前記ヘッダ部を用いて通知される、
請求項１１記載の端末。
【請求項２０】
前記相手端末が生成した前記複数のコーデックモード候補を含む第３の情報は、呼制御のための処理機能を有するネットワークノードを経由して前記端末へ送信され、
前記ネットワークノードは、前記端末が現在接続しているアクセス網が前記ネットワークノードの配下である場合、前記第３の情報に示される前記複数のコーデックモード候補を変更し、
前記選択手段は、変更後の前記第３の情報に含まれる前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、
請求項１記載の端末。
【請求項２１】
前記ネットワークノードは、更に、前記第３の情報を確認したか否かを示す確認情報を前記端末へ送信し、
前記選択手段は、前記第３の情報を確認済みであることを前記確認情報が示す場合、変更後の前記第３の情報に含まれる前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、
請求項２０記載の端末。
【請求項２２】
第１の端末と前記第１の端末の通信相手である第２の端末との間の通信開始時に、前記第１の端末が、前記第２の端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記第２の端末に送信する通信システムにおいて、
前記第２の端末が、前記第２の端末が現在接続しているアクセス網の特性に関する第１の情報を前記第１の端末に通知するステップと、
前記第１の端末が、前記第１の情報を受信するステップと、
前記第１の端末が、前記第１の情報と、前記第１の端末が現在接続しているアクセス網の特性に関する第２の情報とを比較し、前記第１の端末と前記第２の端末との間の通信形態を判断するステップと、
前記第１の端末が、判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記第２の端末との通信で使用するコーデックモードを選択するステップと、
を具備するコーデックモード選択方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
SIP INVITEメッセージに付加されたＳＤＰ（Session Description Protocol）オファーには、ＶｏＩＰ通信で使用されるメカニズムが記述される。記述されるメカニズムとしては、例えば、コーデックの方式あるいはコーデックモード、及び、プロトコルに関する候補等である。コーデックの方式あるいはコーデックモードは、ビットレート、アルゴリズム遅延、チャンネル数等の、このコーデックに採用されている要素を含む。また、プロトコルは、ＲＴＰ（Real-time Transport Protocol）ペイロードフォーマットの種類等を含む。ＵＥ１０２は、ＳＴ１１でSIP INVITEメッセージを受け取ると、ＳＤＰオファーに記述された複数の候補の中から１つのメカニズムを選択し、ＳＤＰアンサーに記述する。ＵＥ１０２は、ＳＴ１２においてＳＤＰアンサーをSIP 183 Session Progressメッセージに付加してＵＥ１００に送る。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
上述した通話開始時のネゴシエーションでのコーデックモード選択は、データのやり取りが実際に行われるネットワークの状況とは独立に行われる。このため、通話開始時点、或いは、通話期間全体で使用されるコーデックモードとして、適切なコーデックモードが選択されない場合があるという課題がある。現在３ＧＰＰ  ＳＡ４で議論されているＥＶＳ（Enhanced Voice Services）では、ＡＭＲ及びＡＭＲ−ＷＢに比べ、より高ビットレートのサポート、複数のアルゴリズム遅延のサポート、２チャンネル（ステレオ）のサポート等が考えられている。このため、特にＥＶＳでは、好適なコーデックモードの選択が求められる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００３９
【補正方法】変更
【補正の内容】
【００３９】
図７に示す端末（ＵＥ１００、１０２）において、無線受信部６００は、自機が発呼側の場合、通信相手である相手端末（着呼側ＵＥ）から通知されるシグナリングメッセージ（SIP 183 Session Progressメッセージ）を受信する。そして、無線受信部６００は、受信したシグナリングメッセージをモード決定部６０８に出力する。このシグナリングメッセージには、例えばＳＤＰアンサー内に記述された、コーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）が含まれている。一方、無線受信部６００は、自機が着呼側の場合、通信相手のＵＥ（発呼側）から通知されるシグナリングメッセージ（SIP INVITEメッセージ）を受信する。そして、無線受信部６００は、受信したシグナリングメッセージを情報比較部６０６及びモード決定部６０８に出力する。このシグナリングメッセージには、例えばＳＤＰオファー内に記述された、コーデックモードセット候補（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせの候補）、及び、通信相手のＵＥが現在接続している無線アクセス網の特性に関する情報が含まれている。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００５５
【補正方法】変更
【補正の内容】
【００５５】
具体的には、図９に示す“０ｘ００”は、例えば、後述する“０ｘ０１”及び“０ｘ０２”に対応する通信と異なる通信である通常通信を意味する。そして、図９に示す“０ｘ００”は、ビットレートが（6kbps前後、8kbps前後、12kbps前後）であり、低い（Low）アルゴリズム遅延であるコーデックモードセットに対応する。通常通信では、例えば、選択可能なビットレートのうち低いビットレートで通話を開始し、その後、ＵＥ間の通信経路の品質に応じてコーデックビットレートを選択する。図９に示す“０ｘ０１”は、ＩＰコア網を経由した通信（ＨｅＮＢ＋ＩＰコア網通信。例えば、図５を参照（個人宅））を意味し、ビットレートが（6kbps前後、8kbps前後、12kbps前後、24kbps前後）であり、低い（Low）アルゴリズム遅延であるコーデックモードセットに対応する。また、“０ｘ０２”は、Ｌｏｃａｌ  ＧＷを経由した通信（ＨｅＮＢ＋ローカル網通信。例えば、図４を参照（企業内電話網））を意味し、ビットレートが（6kbps前後、8kbps前後、12kbps前後、24kbps前後）であり、高い（High）アルゴリズム遅延であるコーデックモードセットに対応する。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００６１
【補正方法】変更
【補正の内容】
【００６１】
ＵＥ１０２のモード決定部６０８は、情報比較部６０６での判断結果（自機と通信相手との間の通信形態）に基づいて、コーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）を決定する。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００７５
【補正方法】変更
【補正の内容】
【００７５】
これにより、各ＵＥは、通信開始時（通信の初期段階）から、通信経路の品質に応じた適切なコーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）を選択することができる。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】０１００
【補正方法】変更
【補正の内容】
【０１００】
次いで、本実施の形態における、コーデックモードセット（ＵＥのハンドオーバの可能性が低い場合のコーデックモードセットを含む）と、コーデックモードセットを示す数値（番号）との対応関係を図１５に示す。図１５では、図９に示す対応関係（“０ｘ００”、“０ｘ０１”、“０ｘ０２”）に加え、“０ｘ０３”が設定されている。図１５に示す“０ｘ０３”は、電話会議通信を意味し、ビットレートが100kbps前後であり、高い（High）アルゴリズム遅延であるコーデックモードセットに対応する。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】０１０２
【補正方法】変更
【補正の内容】
【０１０２】
ＵＥ１０２のモード決定部６０８は、情報比較部６０６での判断結果（自機と通信相手との間の通信形態）に基づいて、コーデックモードセット（ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ）を決定する。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】０１５５
【補正方法】変更
【補正の内容】
【０１５５】
オペレータのポリシーとしては、例えば、優先して使用されるコーデック（コーデックの方式）、優先して使用されるコーデックビットレート、優先して使用されるサンプリングレート、優先して使用されるオーディオ帯域（例えば、ＮＢ，ＷＢ，ＳＷＢ，ＦＢ）、優先して使用されるアルゴリズム遅延、及び、優先して使用されるチャンネル数等が挙げられる。また、オペレータのポリシーとしては、他にも、例えば、セッション途中でのビットレート又はチャンネル数の切り替えを許可するか否か、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"」を参照）を許可するか否か、及び、非特許文献２に記載のような冗長フレームを許可するか否か等が挙げられる。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】０２６５
【補正方法】変更
【補正の内容】
【０２６５】
また、上記実施の形態では、ＵＥ間の通信開始時のコーデックモード（又はコーデックモードセット）（ビットレート及びアルゴリズム遅延を含む）を選択する場合について説明したが、これに限られない。例えば、ＵＥが有している能力（例えば、ディスプレイの大きさ等）を選択する場合についても上記実施の形態を適用することができる。
【手続補正１２】
【補正対象書類名】図面
【補正対象項目名】図９
【補正方法】変更
【補正の内容】
【図９】
2012063417.tif 000033
【手続補正１３】
【補正対象書類名】図面
【補正対象項目名】図１５
【補正方法】変更
【補正の内容】
【図１５】
2012063417.tif 000034
【国際調査報告】
2012063417.tif 000035
2012063417.tif 000036
2012063417.tif 000037
2012063417.tif 000038
2012063417.tif 000039