以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
図4は、本発明の各実施の形態に係るネットワーク構成と、端末の位置関係の一例を示す図である。なお、図4において、図1と同一構成である部分には同一の符号を付してその説明を省略する。
HeNB(Home eNode B)400、402は、小型基地局(ここではフェムト基地局とする。例えば、「3GPP TS 23.830 v9.0.0, "Architecture aspects of Home NodeB and Home eNodeB"」を参照。以下同様)であり、限られたユーザが保有するUEのみ各HeNBに接続可能であることを示すCSG ID(Closed Subscriber Group Identifier。例えば、「3GPP TS 25.401 v9.0.0, "UTRAN overall description"」を参照)を保持する。HeNB400は、無線アクセス網406を構成し、HeNB402は、無線アクセス網408を構成する。
図4に示すネットワーク構成では、HeNB400、402は、同一のLocal GW(Gateway)404に接続されている。よって、HeNB400及びHeNB402にそれぞれ接続されているUE同士(UE100とUE102)は、オペレータのIPコア網124を経由することなく、Local GW404を経由してデータを送受信することができる。
図4に示す無線アクセス網406、408には、限られたユーザのみが接続されるため、各無線アクセス網における1UEあたりに割当可能な無線リソースは大きい。このような構成は、例えば、HeNBを用いて企業内の専用電話網を構築する場合等に適用される。なお、図4では、Local GW404がHeNB400、402から独立している例が挙げられているが、これに限定されない。その他の構成、例えばLocal GW404が各HeNB400、402にそれぞれ設置され、各HeNBに設置されたLocal GWが直接或いは他のノードを介して接続される構成が採用されてもよい。
図5は、本発明の各実施の形態に係るネットワーク構成と、端末の位置関係の別の例を示す図である。なお、図5において、図1と同一構成である部分には同一の符号を付してその説明を省略する。
HeNB500、502は、小型基地局(フェムト基地局)であり、HeNB500は、無線アクセス網506を構成し、HeNB502は、無線アクセス網508を構成する。
図5に示すネットワーク構成では、HeNB500とHeNB502とがそれぞれ別々にオペレータのIPコア網124に接続されている。よって、HeNB500及びHeNB502にそれぞれ接続されているUE同士(UE100とUE102)は、オペレータのIPコア網124を経由してデータを送受信する。ただし、無線アクセス網506、508には、図4と同様、限られたユーザのみが接続されるため、各無線アクセス網における1UEあたりに割当可能な無線リソースは大きい。このような構成は、例えば、個人宅等にHeNBが設置されている場合等に適用される。
以下の説明では、図4に示すUE100とUE102との間の通信形態(各々が接続されたHeNB及びLocal GWを介した通信形態)を、“HeNB+ローカル網通信”と呼ぶ。また、図5に示すUE100とUE102との間の通信形態(各々が接続されたHeNB及びIPコア網を介した通信形態)を、“HeNB+IPコア網通信”と呼ぶ。
ここで、図6を用いて、本発明の各実施の形態で用いるRTP関連用語を説明する。RTPパケットは、図6に示すように、RTPヘッダとRTPペイロードとから成る。
RTPヘッダはIETF(Internet Engineering Task Force)のRFC(Request for Comments)3550に記載の通りであり、RTPペイロードの種類(コーデックの種類等)によらず共通である。RTPペイロードのフォーマットはRTPペイロードの種類により異なる。図6に示すように、RTPペイロードは、ヘッダ部とデータ部とから成るが、RTPペイロードの種類によってはヘッダ部が存在しない場合もある。RTPペイロードのヘッダ部には、音声及び動画等のエンコードされたデータのビット数を特定するための情報等が含まれる。RTPペイロードデータ部には、音声及び動画等のエンコードされたデータの他、このRTPペイロード長が1オクテット(8ビット)の倍数にならなかった場合に付加されるpadding等が含まれる。また、図6に示すように、RTPパケットが伝送される際、更に下位層のヘッダ(UDP(User Datagram Protocol)ヘッダ、IPヘッダ、及びIP以下の伝送路固有のヘッダ)が付加される。
(実施の形態1)
図7は、本実施の形態に係る端末(UE100、102)の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図7では、本発明と密接に関連する端末同士の通信に関するネゴシエーションに関わる主な構成部(例えば、図2に示すST11〜ST15に関わる構成部)を示す。
図7に示す端末(UE100、102)において、無線受信部600は、自機が発呼側の場合、通信相手である相手端末(着呼側UE)から通知されるシグナリングメッセージ(SIP 183 Session Progressメッセージ)を受信する。そして、無線受信部600は、受信したシグナリングメッセージをモード決定部608に出力する。このシグナリングメッセージには、例えばSDPアンサー内に記述された、コーデックモードセット(ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ)が含まれている。一方、無線受信部600は、自機が着呼側の場合、通信相手のUE(発呼側)から通知されるシグナリングメッセージ(SIP INVITEメッセージ)を受信する。そして、無線受信部600は、受信したシグナリングメッセージを情報比較部606及びモード決定部608に出力する。このシグナリングメッセージには、例えばSDPオファー内に記述された、コーデックモードセット候補(ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせの候補)、及び、通信相手のUEが現在接続している無線アクセス網の特性に関する情報が含まれている。
無線送信部602は、シグナリング生成部610から出力されるシグナリングメッセージ(SIP INVITEメッセージ又はSIP 183 Session Progressメッセージ)を通信相手のUEへ送信する。
接続先判断部604は、自機が現在接続している無線アクセス網の特性を判断し、無線アクセス網の特性に関する情報を保持する。接続先判断部604は、無線アクセス網の特性に関する情報を、情報比較部606及びシグナリング生成部610に出力する。
情報比較部606は、自機が着呼側の場合、自機が現在接続している無線アクセス網の特性に関する情報と、通信相手のUE(発呼側)が現在接続している無線アクセス網の特性に関する情報とを比較する。前者は、接続先判断部604から入力される情報であり、後者は、無線受信部600から入力される、シグナリングメッセージに含まれる情報である。
具体的には、情報比較部606は、双方の無線アクセス網の特性に関する情報を比較して、自機と相手端末との間の通信形態を判断する。例えば、情報比較部606は、自機及び相手端末が、HeNB+ローカル網通信、HeNB+IPコア網通信、及び異なる通信形態のうち、いずれであるかを判断する。ここで、HeNB+ローカル網通信とは、同一のHeNB、複数のHeNB、又は複数のHeNB及びVPN(Virtual Private Network)バックボーンで構成されるような通信網で接続された通信形態である。また、HeNB+IPコア網通信とは、IPコア網124を介した異なるHeNB(フェムト基地局)に接続された通信形態である。そして、情報比較部606は、判断した通信形態をモード決定部608に出力する。
モード決定部608は、自機が発呼側の場合、無線受信部600から入力されるシグナリングメッセージに含まれるSDPアンサーに記述されたコーデックモードセットを、自機と通信相手との間の通信で使用するコーデックモードセットに決定する。モード決定部608は、自機が着呼側の場合、無線受信部600から入力されるシグナリングメッセージに含まれるSDPオファーに記述されたコーデックモードセット候補の中から、自機と相手端末との通信で使用するコーデックモードセットを選択する。この選択は、情報比較部606から入力される通信形態に基づいて行われる。
シグナリング生成部610は、自機が発呼側の場合、接続先判断部604から入力される、自機の接続先アクセス網の特性に関する情報を含むシグナリングメッセージを生成する。これにより、発呼側UEの接続先アクセス網の特性に関する情報は、着呼側UEに通知される。シグナリング生成部610は、自機が着呼側の場合、モード決定部608で決定されたコーデックモードセットを含むシグナリングメッセージを生成する。シグナリング生成部610は、生成したシグナリングメッセージを無線送信部602に出力する。
次に、図7を用いて、本実施の形態に係る端末(UE100及びUE102)における処理について詳細に説明する。
以下の説明では、図4又は図5において、現在、UE100がHeNB400又はHeNB500に接続され、UE102がHeNB402又は502に接続されており、UE100からUE102に対して電話をかけるとする。通話開始時点では、UE100(発呼側UE)及びUE102(着呼側UE)は、互いに通信相手がどこに位置しているのかに関する情報(例えば、UEが接続されているセル(HeNB)を示すセル情報、及び、UEの位置を示す位置情報等)を保持していない。
UE100の接続先判断部604は、UE100が接続している無線アクセス網406(又は506)の特性を判断する。例えば、接続先判断部604は、UE100が現在接続しているHeNB400(又は500)のCSG IDに基づいて、UE100に割り当てられる無線リソース(割当可能な無線リソース又は無線リソースの占有量)の状況を判断する。例えば、接続先判断部604は、CSG IDがフェムト基地局を表している場合、当該フェムト基地局ではUE100に割当可能なリソースが大きいと判断する。
また別の例としては、接続先判断部604は、UE100が現在接続している無線アクセス網が、3GPP等の携帯電話専用無線アクセス網以外の無線アクセス網、例えば無線LAN等で構成されたものであると判断する。この判断は、無線アクセス網の無線特性(無線周波数帯またはシグナリング等)などに基づいて行われる。この場合、通信データの送受信フォーマット(一度に送られるフレームの個数、RTPペイロードフォーマット等)は、3GPP等の携帯電話専用無線アクセス網用に制限されたフォーマットでなくてよい事などを判断する。
UE100のシグナリング生成部610は、通信相手(UE102)に通知する情報が記述された、呼制御のためのシグナリングメッセージ(例えば、SIP INVITEメッセージ)を生成する。例えば、接続先判断部604で無線アクセス網の特性が判断されると、シグナリング生成部610は、現在接続中の無線アクセス網がCSG IDを保持する場合、CSG IDを、SIP INVITEメッセージに含まれるSDPオファー内に記述する。又は、シグナリング生成部610は、SIPヘッダ(例えばP-Access-Network-Info header field)に記述してもよい(例えば、「3GPP TS 24.229 v10.0.0, "Session Initiation Protocol (SIP) and Session Description Protocol (SDP)"」を参照)。
また、無線アクセス網の特性に関する情報としては、CSG IDの代わりに、基地局ID(例えば、「3GPP TS 25.401 v9.0.0, "UTRAN overall description"」を参照)を用いてもよい。各UEでは、CSG ID又は基地局ID(無線アクセス網の特性に関する情報)に基づいて、無線アクセス網の特性(例えば、当該無線アクセス網における1UEあたりに割当可能な無線リソースが大きいか否か)を特定することができる。例えば、各UEは、CSG ID又は基地局IDに基づいて、当該無線アクセス網を構成する基地局がフェムト基地局である場合には、当該無線アクセス網における1UEあたりに割当可能な無線リソースが大きいと判断する。
また、UE100のシグナリング生成部610は、通信相手(UE102)が接続している無線アクセス網408(又は508)の特性の全て又は一部の可能性を考慮したコーデックモードセットの候補を作成する。そして、UE100のシグナリング生成部610は、コーデックモードセットの候補をSDPオファー内に記述する。
SDPオファーの記述の一例を図8に示す。例えば、UE100の接続先無線アクセス網のCSG IDが“Alice-femto”である場合、図8に示すように、SDPオファー内には、例えば“a=csg:Alice-femto”と記述される。なお、記述方法はこれに限らず別の記述方法でもよい。また、通信相手(UE102)の接続先無線アクセス網の特性の全て又は一部の可能性を考慮したコーデックモードのセット候補を記述する方法として、例えば各コーデックモードセットにそれぞれ対応付けられた数値のみを記述してもよい。この数値は、図8では“0x00”、“0x01”及び“0x02”としている。これにより、SDP内の記述量を削減することが可能となる。また、コーデックモードセットと数値との対応付けに限らず、記号又はその他の方法でコーデックモードセットを表してもよい。
例えば、図8に示す数値(番号)“0x00”、“0x01”、“0x02”と、これら数値の表わす意味及びこれらに対応するコーデックモードセットとの対応関係を図9に示す。
具体的には、図9に示す“0x00”は、例えば、後述する“0x01”及び“0x02”に対応する通信と異なる通信である通常通信を意味する。そして、図9に示す“0x00”は、ビットレートが(6kbps前後、8kbps前後、12kbps前後)であり、低い(Low)アルゴリズム遅延であるコーデックモードセットに対応する。通常通信では、例えば、選択可能なビットレートのうち低いビットレートで通話を開始し、その後、UE間の通信経路の品質に応じてコーデックビットレートを選択する。図9に示す“0x01”は、IPコア網を経由した通信(HeNB+IPコア網通信。例えば、図5を参照(個人宅))を意味し、ビットレートが(6kbps前後、8kbps前後、12kbps前後、24kbps前後)であり、低い(Low)アルゴリズム遅延であるコーデックモードセットに対応する。また、“0x02”は、Local GWを経由した通信(HeNB+ローカル網通信。例えば、図4を参照(企業内電話網))を意味し、ビットレートが(6kbps前後、8kbps前後、12kbps前後、24kbps前後)であり、高い(High)アルゴリズム遅延であるコーデックモードセットに対応する。
つまり、図9では、“0x02”が最も品質の良いコーデックを与えるコーデックモードセット(高ビットレート,長遅延)であり、続いて“0x01”、“0x00”の順に、品質を抑えたコーデックモードセット(低ビットレート化,低遅延化)となる。端末(UE100、102)には図9に示す対応付けが予め格納されていてもよい。
UE100のシグナリング生成部610で生成されたシグナリングメッセージ(SIP INVITEメッセージ)は、無線送信部602を介して、IMS網126経由でUE102に送信される。
一方、UE102の無線受信部600は、UE100から送信されたシグナリングメッセージ(SIP INVITEメッセージ)を受け取る。
UE102の接続先判断部604は、UE100と同様に、UE102が接続している無線アクセス網408(又は508)の特性を判断する。
UE102の情報比較部606は、受け取ったシグナリングメッセージに、通信相手(UE100)の接続先無線アクセス網(無線アクセス網406(又は506))の特性に関する情報が記述されているかを確認する。情報比較部606は、無線アクセス網の特性に関する情報が記述されている場合、通信相手の無線アクセス網の特性と、自機の接続先無線アクセス網の特性とを比較する。そして、情報比較部606は、自機(UE102)と通信相手(UE100)との間の通信形態(どのような通信が可能か)を判断する。例えば、情報比較部606は、通信相手(UE100)の接続先無線アクセス網の特性に関する情報として送信されたCSG IDと、自機(UE102)の接続先無線アクセス網の特性に関する情報であるCSG IDとを比較する。そして、情報比較部606は、自機と通信相手とが同一企業内電話網のHeNBにそれぞれ接続されているのか、互いに個人宅のHeNBにそれぞれ接続されているのか、又は、どちらか一方又は双方が公衆の基地局(eNB)に接続されているのか、を判断する。又は、情報比較部606が、通信相手(UE100)及び自機(UE102)の接続先無線アクセス網の特性に関する情報を比較して、双方が物理的に近くに位置するか否か(例えば、データ経路のホップ数が所定の閾値以下であるか否か)を判断してもよい。
UE102のモード決定部608は、情報比較部606での判断結果(自機と通信相手との間の通信形態)に基づいて、コーデックモードセット(ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ)を決定する。
本実施の形態における情報比較部606及びモード決定部608における処理の一例を図10に示す。図10は、情報比較部606及びモード決定部608における処理の流れを示すフロー図である。
図10において、ST101では、情報比較部606は、自機の接続先がHeNBであるか否かを判断する。自機の接続先がHeNBではない場合(ST101:NO)、ST102では、モード決定部608は、通常通信(0x00)に対するコーデックモードセットを選択する。
自機の接続先がHeNBである場合(ST101:YES)、ST103では、情報比較部606は、通信相手の接続先がHeNBであるか否かを判断する。通信相手の接続先がHeNBではない場合(ST103:NO)、ST104では、モード決定部608は、通常通信(0x00)に対応するコーデックモードセットを選択する。つまり、モード決定部608は、自機及び通信相手の何れか一方の接続先でもHeNBではない場合には、通常通信(0x00)に対応するコーデックモードセットを選択する。
通信相手の接続先がHeNBである場合(ST103:YES)、ST105では、情報比較部606は、自機及び通信相手の互いの接続先が同一ローカル網内であるか否かを判断する。
自機及び通信相手の互いの接続先が同一ローカル網内でない場合(ST105:NO)、ST106では、モード決定部608は、“HeNB+IPコア網通信(0x01)”に対応するコーデックモードセットを選択する。自機及び通信相手の互いの接続先が同一ローカル網内である場合(ST105:YES)、ST107では、モード決定部608は、“HeNB+ローカル網通信(0x02)”に対応するコーデックモードセットを選択する。
つまり、モード決定部608は、自機と通信相手との間の通信形態が、“HeNB+ローカル網通信”の場合に最も高品質なコーデックモードセットを選択する。また、モード決定部608は、上記通信形態が、“HeNB+IPコア網通信”の場合、“通常通信”の場合よりも高品質なコーデックモードセットを選択する。
このように、モード決定部608は、情報比較部606で自機と通信相手との間で良好な品質の通信経路を確保できるか否かの判断結果に基づいて、自機と通信相手との間の通信で使用するコーデックモード(又はコーデックモードセット)を判断する。すなわち、モード決定部608は、確保できると判断された場合(例えば、図10に示すST101:YESかつST103:YES)、使用するコーデックモード(又はコーデックモードセット)として、高品質(高ビットかつ長遅延)であるコーデックモードセット(“0x01”又は“0x02”)を選択する。一方、モード決定部608は、確保できるか不明であると判断された場合(例えば、図10に示すST101:NO又はST103:NO)、使用するコーデックモード(又はコーデックモードセット)として、通常のコーデックモードセット(つまり、上述した、どのような通信状況でも通信可能なコーデックモードセット)を選択する。
UE102のシグナリング生成部610は、モード決定部608で選択されたコーデックモードセットを、呼制御のためのシグナリングメッセージ(例えば、SIP 183 Session Progressメッセージ)の一部、例えばSDPアンサーに記述する。この際、シグナリング生成部610は、UE102の接続先HeNB402(又は502)のCSG ID又は基地局IDを、SDPアンサー又はSIPヘッダに記述してもよい。
SDPアンサーの記述の一例を図11に示す。例えば、UE100の接続先無線アクセス網のCSG IDが図8に示す“Alice-femto”であり、UE102の接続先無線アクセス網のCSG IDが“Bob-femto”であるとする(図10のST101、ST103:YES)。また、CSG ID(“Bob-femto”)の無線アクセス網とCSG ID(“Alice-femto”)の無線アクセス網とが同一ローカル網内ではないとする(図10のST105:NO)。
この場合、UE102の情報比較部606は、例えば、自機及び通信相手が互いに個人宅等に設置されているHeNBに接続されていると判断し、モード決定部608は、“HeNB+IPコア網通信(0x01)”に対応するコーデックモードセットを選択する。よって、図11に示すSDPアンサーには、選択されたコーデックモードセットとして“0x01”が記述される。なお、図11に示すように、UE102の接続先無線アクセス網の特性に関する情報(Bob-femto)をSDPアンサーに記述してもよい。
UE102のシグナリング生成部610で生成されたシグナリングメッセージ(例えば、SIP 183 Session Progressメッセージ)は、無線送信部602を介してIMS網126経由でUE100に送信される。
UE100のモード決定部608は、無線受信部600を介して、UE102から送信されたシグナリングメッセージを受け取ると、SDPアンサーに記述されている内容に基づいて、コーデックモードセットを決定する。図11の一例では、UE100のモード決定部608は、“HeNB+IPコア網通信(0x01)”に対応するコーデックモードセットを決定する。この際、UE100の通信相手(UE102)の接続先のCSG ID又は基地局IDを、参照情報として用いてもよい。
このように、本実施の形態では、UE間での通信開始時において、発呼側のUEは、自機の接続先無線アクセス網の特性に関する情報としてCSG ID(又は基地局ID)を通信相手である相手端末(着呼側UE)に通知する。着呼側のUEは、通信相手である相手端末(発呼側UE)から通知された、相手端末(発呼側)の接続先無線アクセス網の特性に関する情報(CSG ID等)と、自機の接続先無線アクセス網の特性に関する情報(CSG ID等)とを比較する。そして、着呼側のUEは、自機と相手端末との間の通信形態を判断する。着呼側のUEは、UE間で良好な品質の通信経路を確実に確保できると判断できる場合、通信開始時のコーデックモードセットとして、より高品質かつ長遅延のコーデックモード(又はコーデックモードセット)を選択する。これは、例えば、通信形態が企業内電話網での通信、又は、個人宅での通信である場合である。
これにより、各UEは、通信開始時(通信の初期段階)から、通信経路の品質に応じた適切なコーデックモードセット(ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ)を選択することができる。
なお、本実施の形態では、本発明を、コーデックモードセットの選択に適用した例を説明したが、これに限定されない。本発明に係る接続先の無線アクセス網の特性判断は、通信に必要な他の折衝、例えば通信データの送受信フォーマット(一度に送られるフレームの個数、RTPペイロードフォーマット等)を折衝する際の、送受信フォーマット選択に適用してもよい。
また、本実施の形態では、各UEが保有している情報(無線アクセス網の特性に関する情報)を通信相手に通知するだけでよく、ネットワーク側及びUE側のいずれにおいても無線アクセス網の状況(通信経路の品質)をモニタリングする必要がない。よって、適切なコーデックモード(又はコーデックモードセット)の選択のためにネットワーク及びUEに掛かる負担を抑えることができる。
よって、本実施の形態によれば、端末が保有している情報を折衝情報として用いる。これにより、ネットワーク及び端末(UE)の双方にビーコンあるいはシグナリング送受信等に伴う処理負荷をかけることなく、端末間の通信経路の状況を判断し、適切なコーデックモード(又はコーデックモードセット)を選択することができる。
(実施の形態2)
本実施の形態では、実施の形態1においてUEがシグナリングメッセージの一部に記述した、無線アクセス網の特性に関する情報を、IMS網のネットワークノードで確認する。このネットワークノードは、ネットワークを提供するオペレータ、つまり、呼制御のための処理機能を有するネットワークノードである。
図12は、本実施の形態に係るネットワークノードの構成を示すブロック図である。
図12に示すネットワークノードにおいて、受信部700は、UEからのシグナリングメッセージを受け取ると、シグナリングメッセージをシグナリング解析部704に出力する。
送信部702は、シグナリング生成部708から入力されるシグナリングメッセージを、シグナリングメッセージの送信先UEに送信する。
シグナリング解析部704は、受信部700から入力されるシグナリングメッセージに記述されている情報を解析し、確認が必要な情報を、適切な確認部に出力する。例えば、シグナリング解析部704は、シグナリングメッセージに記述された情報のうち、UEが現在接続されている無線アクセス網の特性に関する情報(例えば、CSG ID又は基地局ID等)を、端末位置情報確認部706に渡す。
端末位置情報確認部706は、シグナリングメッセージを送信したUEが現在接続されている無線アクセス網の特性に関する情報(CSG ID等。つまり、端末の位置情報)が妥当であるか否か(妥当性)を確認する。このとき、端末位置情報確認部706は、このネットワークノード内に保持されている情報を用いて確認を行ってもよく、他のネットワークノード(例えばMME(Mobility Management Entity)及びHSS(Home Subscriber Server)等。「3GPP TS 23.002 v10.0.0, " Network Architecture"」を参照)と連携して確認を行ってもよい。端末位置情報確認部706は、確認結果をシグナリング生成部708に出力する。
シグナリング生成部708は、UEから送信されたシグナリングメッセージの中で修正が必要な記載内容の上書きを行う。例えば、端末位置情報確認部706において、無線アクセス網の特性に関する情報が妥当であると判断されたとする。この場合、シグナリング生成部708は、ネットワークエンティティによる妥当性確認済を示す情報を、フラグ、数値、及び、テキスト等の記載方法でシグナリングメッセージに追加してもよい。また、端末位置情報確認部706において、無線アクセス網の特性に関する情報が妥当ではないと判断された場合、シグナリング生成部708は、シグナリングメッセージから、無線アクセス網の特性に関する情報を削除してもよい。又は、シグナリング生成部708は、端末位置情報確認部706での確認結果を示す情報(妥当性の確認結果)をシグナリングメッセージに追加してもよい。修正されたシグナリングメッセージは、送信部702を介して、シグナリングメッセージの送信先に送信される。
シグナリングメッセージを受け取ったUEは、例えば、ネットワークエンティティによる妥当性確認済であることを特定する。この場合、UEは、実施の形態1と同様にして、シグナリングメッセージに記述された通信相手の接続先無線アクセス網の特性に関する情報を用いて、通信相手との通信形態を判断する。一方、シグナリングメッセージを受け取ったUEは、例えば、ネットワークエンティティによる妥当性確認済であることを特定できなかったとする。この場合、UEは、通信相手の接続先無線アクセス網の特性に関する情報を用いた、通信相手との通信形態の判断を行わない。つまり、UEは、ネットワークノードでの妥当性の確認結果に基づいて、相手端末との通信形態の判断を行うか否かを決定すればよい。
これにより、UEは、自機と相手端末との間の通信形態を正確に判断することが可能となる。つまり、自機と相手端末との間の通信形態判断の確実性を向上させることができる。よって、本実施の形態によれば、実施の形態1と比較して、端末間の通信経路の状況をより正確に判断することができ、適切なコーデックモード(又はコーデックモードセット)を選択できる。
なお、本実施の形態において、ネットワークノードは、IMS網のエンティティ(P−CSCF及びS−CSCF等。「3GPP TS 23.002 v10.0.0, " Network Architecture"」を参照)であってもよく、企業内の専用電話網を構築する場合に用いられるIP−PBX(Internet Protocol Private Branch eXchange)等でもよい。例えば、IMS網のエンティティの1つであるP−CSCF(図4又は図5に示すP−CSCF108、116)には、SDPの内容を確認し、書き換える機能が備えられている。よって、本実施の形態に係るネットワークノードとしてP−CSCFを用いると、SDPの確認機能を無線アクセス網の特性に関する情報の確認にも利用できるので、ネットワーク側の負担の増やすことなく、本実施の形態と同様の効果を得ることができる。
また、本実施の形態では、ネットワークノードが妥当性確認済を示す情報をUEに通知する場合について説明したが、妥当性確認済を示す情報は、UEに通知されなくてもよい。例えば、上述したように、ネットワークノードは、妥当ではないと判断された無線アクセス網の特性に関する情報をシグナリングメッセージから削除する。この場合、シグナリングメッセージの送信先UEでは、誤った情報を用いて通信形態の判断を行うことがなくなる。よって、ネットワークノードが妥当性確認済を示す情報をUEに通知しない場合でも、本実施の形態と同様、端末間の通信形態判断の確実性を向上させることができる。例えば、ネットワークノードは、同一オペレータのIPコア網に接続されたUE同士の通信については上記妥当性確認済を示す情報を通知しなくてもよい。そして、その代わりに、ネットワークノードは、異なるオペレータのIPコア網にそれぞれ接続されたUE同士の通信については上記妥当性確認済を示す情報を通知してもよい。
(実施の形態3)
本実施の形態では、UEの接続先アクセス網の特性に関する情報に加え、UEのハンドオーバの可能性の有無を示す情報を用いて、コーデックモード(又はコーデックモードセット)選択が行われる。更に、本実施の形態では、通話途中でハンドオーバの可能性の有無に変更が生じた場合には、コーデックモード(又はコーデックモードセット)の変更が行われる。
図13は、本実施の形態に係る端末(UE100、102)の構成を示すブロック図である。なお、図13において、図7と同一構成である部分には同一の符号を付してその説明を省略する。図13に示す端末は、図7に示す端末の構成部に加え、状態解析部812及びモード変更部814が追加される。
図13に示す端末において、状態解析部812は、自機の種類及び状態等から、自機にハンドオーバの可能性があるか否かを解析(判断)する。例えば、UEが電話会議システム用の据え置き型端末である場合、状態解析部812は、自機のハンドオーバの可能性は低いと判断する。また、自機が小型のUEであっても据え置き型の機器、スピーカ及びマイクロフォン等に接続されている状態の場合、状態解析部812は、自機のハンドオーバの可能性は低いと判断する。あるいは、自機が電話会議モード設定部(図示せず)を具備し、ユーザにより明示的に(UEのユーザインタフェースの操作により)電話会議モードが選択された場合、状態解析部812は、自機のハンドオーバの可能性は低いと判断する。状態解析部812は、通信開始時の解析結果を示す情報を、シグナリング生成部610に出力する。これにより、当該解析結果(自機のハンドオーバの可能性の有無を示す情報)は、シグナリングメッセージに付加されて、通信相手に通知される。
また、状態解析部812は、通信途中における自機の状態を解析し、通信途中において自機の状態が変化した場合、自機の状態の変化内容をモード変更部814に出力する。例えば、据え置き型の機器、スピーカ及びマイクロフォン等に接続されて通信しているUEが、これらの機器と非接続になった場合、状態解析部812は、自機とこれらの機器とが非接続になったことをモード変更部814に出力する。
モード変更部814は、状態解析部812から入力される情報に基づいて、現在使用しているコーデックモード(又はコーデックモードセット)の変更を行う。なお、通信相手へのコーデックモード(又はコーデックモードセット)変更の要求は、呼制御のためのシグナリングメッセージを送信することで実施してもよい。また、かかる要求は、通信データのヘッダ(例えばRTPヘッダ、RTPペイロードのヘッダ部、通信データの制御情報、又は、RTCP(RTP Control Protocol))にコーデックモード(又はコーデックモードセット)の変更内容を示す変更情報を追加することで実施してもよい。
次に、図13を用いて、本実施の形態に係る端末(UE100及びUE102)における処理について詳細に説明する。
以下の説明では、実施の形態1と同様、図4又は図5において、現在、UE100がHeNB400又はHeNB500に接続され、UE102がHeNB402又は502に接続されており、UE100からUE102に対して電話をかけるとする。
UE100の状態解析部812は、自機の種類及び状態等から、自機にハンドオーバの可能性があるか否かを解析(判断)する。
UE100のシグナリング生成部610は、解析結果を示す情報を、呼制御のためのシグナリングメッセージの一部、例えばSDPオファー(又はSIPヘッダ)に記述する。また、シグナリング生成部610は、実施の形態1と同様、通信相手(UE102)の接続先無線アクセス網の特性を考慮したコーデックモード(又はコーデックモードセット)の候補を作成する。また、シグナリング生成部610は、実施の形態1と同様、通信相手(UE102)のハンドオーバの可能性等のUE102に関する各情報の全て又は一部の可能性を考慮したコーデックモード(又はコーデックモードセット)の候補を作成する。これらの情報を含むシグナリングメッセージ(SIP INVITEメッセージ)は、無線送信部602を介して通信相手(UE102)に送信される。
SDPオファーの記述の一例を図14に示す。例えば、UE100の状態解析部812においてUE100のハンドオーバの可能性が低いと判断された場合、図14に示すように、SDPオファー内には、例えば“a=handover:low”と記述される。なお、ハンドオーバの可能性の有無を“low”又は“High”と記述する代わりに、数値又は記号等で示してもよい。例えば“0x00”を「ハンドオーバの可能性高い」とし、“0x01”を「ハンドオーバの可能性低い」とした場合には、ハンドオーバの可能性が低い状態は、“a=handover:0x01”と記述される。記述方法は、これらに限らず、別の記述方法でもよい。
次いで、本実施の形態における、コーデックモードセット(UEのハンドオーバの可能性が低い場合のコーデックモードセットを含む)と、コーデックモードセットを示す数値(番号)との対応関係を図15に示す。図15では、図9に示す対応関係(“0x00”、“0x01”、“0x02”)に加え、“0x03”が設定されている。図15に示す“0x03”は、電話会議通信を意味し、ビットレートが100kbps前後であり、高い(High)アルゴリズム遅延であるコーデックモードセットに対応する。
一方、UE102(着呼側)の情報比較部606は、端末状態(UE100の状態解析部812での解析結果)及び接続先無線アクセス網の特性に関する情報と、自機の端末状態(UE102の状態解析部812での解析結果)及び接続先無線アクセス網の特性に関する情報とを比較する。前者は、UE100から送信されたシグナリングメッセージ(SIP INVITEメッセージ)に含まれる情報である。具体的には、情報比較部606は、比較結果に基づいて、自機(UE102)と通信相手(UE100)との間の通信形態(どのような通信が可能か)を判断する。例えば、情報比較部606は、UE100、102が共にHeNBに接続され、かつ、ハンドオーバの可能性が無い場合には、固定電話のような通信(高品質な通信)が可能と判断する。
UE102のモード決定部608は、情報比較部606での判断結果(自機と通信相手との間の通信形態)に基づいて、コーデックモードセット(ビットレート、アルゴリズム遅延、チャンネル数等の組み合わせ)を決定する。
本実施の形態における情報比較部606及びモード決定部608における処理の一例を図16に示す。図16は、情報比較部606及びモード決定部608における処理の流れを示すフロー図である。なお、図16において、図10と同一処理を行う部分には同一の符号を付してその説明を省略する。
図16において、自機(UE102)及び通信相手(UE100)の互いの接続先が同一ローカル網内である(ST105:YES)。この場合、情報比較部606は、ST201において、自機のハンドオーバの可能性があるかを判断し、ST202において通信相手のハンドオーバの可能性があるかを判断する。自機のハンドオーバの可能性がある場合(ST201:YES)、又は、通信相手のハンドオーバの可能性がある場合(ST202:YES)、ST107では、モード決定部608は、“HeNB+ローカル網通信(0x02)”に対応するコーデックモードセットを選択する。
一方、自機のハンドオーバの可能性が無く(ST201:NO)、かつ、通信相手のハンドオーバの可能性が無い場合(ST202:NO)、ST203では、モード決定部608は、“電話会議通信(0x03)”に対応するコーデックモードセットを選択する。
このように、モード決定部608は、情報比較部606で自機と通信相手との間で良好な品質の通信経路を確保できると判断されたか否か、及び、自機と通信相手との双方でハンドオーバの可能性が無いか否かに基づいて、自機と通信相手との間の通信で使用するコーデックモードセットを選択する。より具体的には、良好な品質の通信経路を確保できると判断され(例えば、図16に示すST101:YESかつST103:YES)、かつ、双方でハンドオーバの可能性が無い場合(例えば、図16に示すST201:NOかつST202:NO)、選択可能なコーデックモードセットのうち、最も高品質かつ長遅延であるコーデックモードセット(0x03)を選択する。
UE102のシグナリング生成部610は、モード決定部608で選択されたコーデックモードセットを、呼制御のためのシグナリングメッセージ(例えば、SIP 183 Session Progressメッセージ)の一部、例えばSDPアンサーに記述する。この際、シグナリング生成部610は、UE102の接続先HeNB402(又は502)のCSG ID又は基地局ID、及び、UE102のハンドオーバの可能性の有無を、SDPアンサー又はSIPヘッダに記述してもよい。
SDPアンサーの記述の一例を図17に示す。例えば、UE100の接続先無線アクセス網のCSG IDが図14に示す“Panasonic-femto”であり、UE102の接続先無線アクセス網のCSG IDが“Panasonic-femto”であるとする(図16のST101、ST103:YES)。また、CSG ID(“Panasonic-femto”)の無線アクセス網とCSG ID(“Panasonic-femto”)の無線アクセス網とが同一ローカル網内であるとする(図16のST105:YES)。更に、UE100及びUE102の双方のハンドオーバの可能性が低いとする(図16のST201、ST202:NO)。この場合、UE102の情報比較部606は、UE100及びUE102が互いに同一企業内のローカル網のHeNBに接続され、かつ、UE100及びUE102が共にハンドオーバの可能性が無いと判断する。そして、モード決定部608は、“電話会議通信(0x03)”に対応するコーデックモードセットを選択する。よって、図17に示すSDPアンサーには、選択されたコーデックモードセットとして“0x03”が記述される。
なお、図17に示すように、UE102の接続先無線アクセス網の特性に関する情報(Panasonic-femto)、及び、UE102のハンドオーバの可能性の有無(handover:low)をSDPアンサーに記述してもよい。
UE102のシグナリング生成部610で生成されたシグナリングメッセージ(例えば、SIP 183 Session Progressメッセージ)は、無線送信部602を介してIMS網126経由でUE100に送信される。
UE100のモード決定部608は、無線受信部600を介して、UE102から送信されたシグナリングメッセージを受け取ると、SDPアンサーに記述されている内容に基づいて、コーデックモードセットを決定する。図17の一例では、UE100のモード決定部608は、“電話会議通信(0x03)”に対応するコーデックモードセットを決定する。この際、UE100の通信相手(UE102)の接続先のCSG ID又は基地局ID、又は、ハンドオーバの可能性の有無を、参照情報として用いてもよい。
また、通信途中でUE100又はUE102の状態が変化した場合、モード変更部814は、コーデックモードセットの変更を行ってもよい。例えば、現在のコーデックモードセットが“電話会議通信(0x03)”に対応するものであるとする。この場合、モード変更部814は、RTPペイロードのヘッダ部又は、RTCPフィードバックのコーデックモードリクエストフィールドに、変更後のコーデックモードセット(例えば“HeNB配下+ローカル網通信(0x02)”を記載する(例えば、図18参照)。そして、モード変更部814は、通信相手に変更を促すと同時に、自機のコーデックモード(又はコーデックモードセット)も変更する。また、変更先コーデックモードセットではなく、変更先ビットレート、遅延モード、チャンネル数等の個別のコーデックモードがコーデックモードリクエストフィールドに直接指定されてもよい。また、この変更先ビットレート、遅延モード、チャンネル数等は複数のコーデックモード(又はコーデックモードセット)を跨いでもよい。
これにより、UEでは、無線アクセス網の特性のみでなく、ハンドオーバの可能性の有無を用いることで、実施の形態1と比較して、自機と通信相手である相手端末との間の通信形態をより細かく判断することが可能となる。よって、UEでは、判断された上記通信形態に応じて、より高品質なコーデックモード(又はコーデックモードセット)を選択することができる。
更に、UEは、通信中の自機又は相手端末において、ハンドオーバの可能性が変化した場合、現在使用しているコーデックモード(又はコーデックモードセット)を変更する。すなわち、UEは、通信途中であっても、自機又は通信相手のいずれかの状態が変化した場合、つまり、自機と通信相手との間の通信形態が変化し得る場合には、当該変化に応じて、コーデックモード(又はコーデックモードセット)を変更する。これにより、UEでは、通信途中における通信形態の変化に応じた適切なコーデックモード(又はコーデックモードセット)を使用することができる。
よって、本実施の形態によれば、実施の形態1と比較して、端末間の通信経路の状況をより細かく判断することができ、より適切なコーデックモード(又はコーデックモードセット)を選択できる。
(実施の形態4)
本実施の形態では、上記実施の形態1〜3の例で挙げたコーデック方式のように、ビットレート等のコーデックモードの種類が多いコーデック方式の場合に推奨される、RTPペイロードフォーマットの一例を以下に示す。なお、本実施の形態におけるRTPペイロードフォーマット例は、上記実施の形態1〜3に記載したネゴシエーション方法あるいはコーデックモード(又はコーデックモードセット)の選択が行われた場合に限定されるものではない。
ここでは、コーデックの1つの方式(又はモード)、又は、通話等の1つのリアルタイムセッションの中で互いに切り替えて使うことのできる複数の方式(又はモード)におけるビットレートとして、方式X(仮にマルチレートコーデックとする)では12、24kbpsがサポートされているものとする。そして、方式Y(仮にスケーラブルコーデックとする)では、かかるビットレートとして、基本部8、12、24kbps、第一拡張部4、12kbps、第二拡張部8kbpsがサポートされているものとする。ここで方式X、方式Yは異なるコーデックであってもよいし、単一のコーデックの中の異なるモードであってもよい。
ここで、スケーラブルコーデックの第一拡張部及び第二拡張部としては、例えばSuper Wideband拡張及びFull Band拡張であってもよく、又は、Enhance対応の拡張又はステレオ拡張等であってもよい。また、方式X及び方式Yの双方とも、遅延モードとしてはそれぞれ異なる遅延A及び遅延Bの両方、又はいずれか一方を持つとする。また、チャンネル数も1チャンネル(モノ)及び2チャンネル(ステレオ)の2つ、又は1チャンネル(モノ)のみをサポートしているとする。
図19は、本実施の形態におけるコーデックモード(本例ではビットレート及びこの組み合わせ)の番号対応付け(Frame Type Index)及びRTPペイロードフォーマットを示す第1の例である。
図19Aに示すように、ビットレートの全ての組み合わせに対して異なるFrame Type Indexがそれぞれ割り当てられる。図19Bは、第1の例でのRTPペイロードフォーマットの一例である。図19Bに示すように、RTPペイロードのデータ部に加え、RTPペイロードのヘッダ部に、RTPペイロードの情報として、Frame Type Index及びQビットが付加される。ここで、RTPペイロードのデータ部は、1frame分のエンコードされたデータ及びRTPペイロード長を調整するために加えられるパディングビット(padding bit)を含む。RTPペイロードのヘッダ部に含まれるFrame Type Indexは、図19Aのどの組み合わせが使われているかを示す。RTPペイロードのヘッダ部に含まれるQビットは、非特許文献1に記載のQビットと同等であり、Frame QualityのIndicatorである。
遅延モードに関しては、RTPペイロードのヘッダ部に含ませても、含ませなくてもよい。遅延モードをRTPペイロードのヘッダ部に含ませる場合には、図19Aの表の中に遅延モードを含ませてFrame Type Indexを割り当ててもよい。そして、RTPペイロードフォーマットの中に遅延モードを表すビット(例えば遅延Aは“0”、遅延Bは“1”)を含ませてもよい。
図19Bに示すように、第1の例でのRTPペイロードフォーマットには、非特許文献1に記載されているCodec Mode Requestのようなフィールドを持たない。このフィールドを持たないことによりRTPペイロードのサイズを抑えることができる。ただし、RTPペイロードのサイズに問題がない場合には(すなわち、RTPペイロードフォーマットに数ビットを付け加えても問題が無い場合には)、Codec Mode Requestのようなフィールドを含んでもよい。なお、Codec Mode Requestのフィールドを持たない場合で、通信相手にコーデックモード(又はコーデックモードセット)の変更を求める際には、例えば、RTCPを用いてもよい。
また、複数のフレーム(1フレーム分のエンコードされたデータ)を同時に(一つのIPパケットにして)送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットが、RTPペイロードのヘッダ部に含まれてもよい。
またヘッダに含まれるビット及びフィールドは、本例に挙げられているものに限らない。
また、本例では、図19Aに示すように方式X及び方式Yの各ビットレート、又はビットレートの組み合わせに対し一連のFrame Type Indexを与え、方式X及び方式Yがあたかも同一のコーデック方式であるかのように扱うことのできる例を挙げた。しかし、方式X及び方式Yに対して、それぞれ別にFrame Type Index及びRTPペイロードフォーマットが与えられ、独立して利用されるものであってもよい。
図20は、本実施の形態におけるコーデックモード(本例ではビットレート)の番号対応付け(Frame Type Index)及びRTPペイロードフォーマットを示す第2の例である。
図20Aに示すように、ビットレートのみに対してFrame Type Indexがそれぞれ割り当てられる。なお、図20Aに示すFrame Type Indexはビットレートのみを指定し、どのコーデック又はコーデックの組み合わせが使われているかは記述しない。かかる組み合わせには、図19A(第1の例)の組み合わせのうち、それぞれのビットレートに当てはまるコーデックモードが全て該当する。例えば、図20Aにおいて、Frame Type Indexの値が1(ビットレート:12kbps)であったとする。この場合、フレームの内容は、図19Aの中のビットレートが12kbpsとなるコーデックに対応するFrame Type Index“0”(方式Xの12kbps)、“3”(方式Yの12kbps)又は“5”(方式Yで基本部8kbps、及び第一拡張部4kbps)の組みあわせの可能性がある。ただし、図20Aが方式Yのコーデックのみに対応している場合には、Frame Type Index“3”(方式Yの12kbps)、又は、Frame Type Index“5”(方式Yで基本部8kbps、及び第一拡張部4kbps)の2通りの可能性となる。これらのコーデック方式及びビットレートの組み合わせのうち、どの組み合わせを選ぶかはエンコーダが決定する。エンコーダが決定した組み合わせを表す情報は、エンコードされたデータの中に含まれていてもよい。
図20Bは、第2の例でのRTPペイロードフォーマットの一例である。図20Bに示すように、RTPペイロードのデータ部に加え、RTPペイロードのヘッダ部に、RTPペイロードの情報として、Frame Type Index、Qビット、Codec Mode Request及びRビットが含まれる。RTPペイロードのデータ部は、1frame分のエンコードされたデータ及びRTPペイロード長を調整するために加えられるパディングビット(padding bit)を含む。RTPペイロードのヘッダ部のFrame Type Indexは、図19Aのどのビットレートが使われているのかを示す。Qビットは非特許文献1に記載のQビットと同等である。
Codec Mode Requestは通信相手にコーデックモード(ビットレート)の変更をリクエストするフィールドであり、図20BのFrame Type Indexが使われる。Codec Mode Requestを受け取った通信相手のエンコーダは指定されたビットレートを与えるコーデックの組み合わせのうち最適なものを選択しエンコードする。例えば、Codec Mode Requestに示されるFrame Type Indexの値が1(12kbps)であった場合、フレームの内容は、図19Aの中のFrame Type Index“0”、“3”又は“5”の組み合わせの可能性がある。ただし、図20Aが方式Yのコーデックのみに対応している場合には、Frame Type Index“3”(方式Yの12kbps)、又は、“5”(方式Yで基本部8kbps、及び第一拡張部4kbps)の2通りの可能性となる。エンコーダはこれらのうち最適と判断した組み合わせを用いてエンコードを実行する。
図20Bに示すRビットはCodec Mode Requestで相手にリクエストしきれない要求を示すフィールドである。例えば、Rビットはチャンネル数の指定(例えば、モノ=“0”、ステレオ=“1”)又は遅延の指定(例えば、遅延A=“0”、遅延B=“1”)等を示す。Rビットは例えばチャンネル数と遅延両方を示すため、2ビットまたはそれ以上であってもよい。なお、このRビットは、通信中に遅延あるいはチャンネル数を切り替えない場合にはRTPペイロードのヘッダ部に存在しなくてもよい。
また、遅延モードに関しては、図20Aの表の中に遅延モードも含ませてFrame Type Indexを割り当ててもよい。例えば、Frame Type Index“0”から“8”までに割り当てられているビットレートに関しては遅延Aを割り当てる。更に、図20Aに示すFrame Type Indexの値を31までに拡張して、Frame Type Index“11”から“19”までに割り当てられているビットレートに関しては遅延Bを割り当てる(図示せず)。また、図20Aの表の中に遅延モードを含ませない場合には、エンコード側(自分側)に対してRTPペイロードのヘッダ部の中に遅延モードを示すビットを含ませてもよい。また、エンコード側(自分側)のチャンネル数に関しても、遅延モードと同様に、図20Aの表の中に(Frame Type Indexの値を拡張して)含ませてもよい。また、RTPペイロードのヘッダ部の中にチャンネル数の指定を示すビットを含ませてもよいし、エンコードされたデータそのものに含ませてもよい。
第2の例のように、コーデックのビットレートだけを指定することにより、エンコード側で最適なエンコードを行うことができ、かつ、RTPペイロードのヘッダ部の中のFrame Type Index及びCodec Mode Requestのビット数を少なくすることができる。また、RTPペイロードのヘッダ部にCodec Mode Requestを含めることにより、通信相手に、コーデックモード(又はコーデックモードセット)の変更要求を迅速に送信することができる。ただし、通信相手に対する迅速なコーデックモード(又はコーデックモードセット)変更の要求が必要ない場合で、Codec Mode Request及びRビットが必要な場合には、これらをRTPペイロードのヘッダ部に含めず、RTCPに含めて相手に通知してもよい。また、複数のフレーム(1フレーム分のエンコードされたデータ)を同時に(一つのIPパケットにして)送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットがRTPペイロードのヘッダ部に含まれてもよい。また、RTPペイロードのヘッダ部に含まれるビット及びフィールドは、本例に挙げられているものに限らない。
図21は、本実施の形態におけるコーデックモード(本例ではビットレートとその種類)の番号対応付け(Frame Type Index)及びRTPペイロードフォーマットを示す第3の例である。
図21Aに示すように、マルチレートコーデック、スケーラブルコーデックの基本部、及び、スケーラブルコーデックの各拡張部のそれぞれに異なるFrame Type Indexが割り当てられる。
図21Bは、第3の例でのRTPペイロードフォーマットの一例である。
第3の例では、図21に示すように、スケーラブルコーデックにおけるレイヤ(基本部、第一拡張部、第二拡張部)毎にRTPペイロードのヘッダ部がつけられる。図21Bにおいて、RTPペイロードのヘッダ部に含まれるCビットは後続する拡張部が存在するか否かを示す。このように、基本部と各拡張部は別々のIPパケットとして送られてもよい。これにより、ネットワーク又は無線アクセス区間等が混雑している場合、プライオリティの低い拡張部のIPパケットを破棄できるという利点がある。
なお、各RTPペイロードのヘッダ部、又は基本部のRTPペイロードのヘッダ部のみに、Codec Mode Request及びQビットを付加してもよい。遅延モードの記述及び通信相手に対するコーデックモード(又はコーデックモードセット)の変更要求の方法に関しては、第1の例(図19)及び第2の例(図20)の場合と同様である。また、複数のフレームを同時に(一つのIPパケットにして)送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットが、RTPペイロードのヘッダ部に含まれてもよい。また、RTPペイロードのヘッダ部に含まれるビット及びフィールドは、本例に挙げられているものに限らない。
また、本例では、図21Aに示すように方式X(例えばマルチレートコーデック)及び方式Y(例えばスケーラブルコーデック)の各ビットレート、又はビットレートの種類に対して、一連のFrame Type Indexを与える例を挙げた。すなわち、方式X及び方式Yがあたかも同一のコーデック方式であるかのように扱うことのできる例を挙げた。しかし、方式X及び方式Yに対して、それぞれ別にFrame Type Index及びペイロードフォーマットが与えられ、独立して利用されるものであってもよい。
尚、本実施の形態において、Qビットが含まれる例を示したが、Qビットは無くてもよい。
(実施の形態5)
本実施の形態では、RTPペイロード長が複数の固定長に限定される場合で、かつ、一つのビットレート(若しくはその周辺のビットレート)を表す組み合わせが複数存在し得る場合における、好ましいRTPペイロードフォーマット及びその処理方法に関する。これは、例えば実施の形態4で説明した方式Yの場合である。
RTPペイロード長が複数の固定長に限定される例としては、携帯電話網の無線区間のように、伝送ブロックサイズが決められている場合がある。
図22は、本実施の形態におけるコーデックモードの番号対応付け(Frame Type Index)及びRTPペイロードフォーマットを示す第1の例である。
第1の例では、グロスビットレート(Gross Bit rate)に対して番号対応付け(Frame Type Indexとの対応付け)が行われる。ここでは、グロスビットレートは、RTPペイロード長を1秒あたりのキロビット数(kbps:kilo bit per second)に変換したものとする。グロスビットレートに対する番号対応付けの例を図22Aに示す。
また、第1の例では、RTPペイロードのヘッダ部に含む情報又は情報の一部(例えばCodec Mode Requestフィールド)を、通話開始時のネゴシエーション(SDPオファー及びアンサー)によって選択してもよい。この時、実施の形態1及び3でコーデックモード(又はコーデックモードセット)(使用されるビットレートの範囲、遅延モード等)が選択される際に、この選択されたコーデックモード(又はコーデックモードセット)に合わせて、RTPペイロードのヘッダ部に含まれる情報又は情報の一部が選択されてもよい。
例えば、図9及び図15に記載の“通常通信”等、利用されるビットレートの範囲が低い場合には、RTPペイロードのヘッダ部の比率を小さく抑えるために、Codec Mode RequestフィールドをRTPペイロードのヘッダ部に含めないという選択が行われる。
図22Bは、通話開始時のネゴシエーション、又は、サービスオペレータ等のポリシー等によって予めCodec Mode RequestフィールドをRTPペイロードのヘッダ部に含めないと決定された際の、RTPペイロードフォーマットの一例を示す。また図22Cは、通話開始時のネゴシエーション、又は、サービスオペレータ等のポリシー等によって予めCodec Mode RequestフィールドをRTPペイロードのヘッダ部に含めると決定された際の、RTPペイロードフォーマットの一例を示す。図22B及び図22Cにおいて、RTPペイロードのヘッダ部に含まれるQビットは、非特許文献1に記載のQビットと同等であり、Frame QualityのIndicatorである。
エンコーダ側は、Frame Type Indexと、RTPペイロードのヘッダ部の長さより決定されるRTPペイロードのデータ部の長さに応じたビットレートと、その組み合わせを、対応するコーデック方式がサポートするビットレート及びその組み合わせの中から決定する。ここで、RTPペイロードのヘッダ部の長さは、通話開始時のネゴシエーション又はサービスオペレータ等のポリシー等によって予め決められたものである。エンコーダが決定した組み合わせを表す情報は、エンコードされたデータの中に含まれていてもよい。なお、サービスオペレータ等のポリシー等により、通信開始から終了までコーデックビットレートの変更が行われない場合には、RTPペイロードのヘッダ部にFrame Type Indexを含まなくてもよい。この場合の一定のビットレートは、通話開始時のネゴシエーションによって決められてもよいし、サービスオペレータ等のポリシー等によって予め決められていてもよい。
図23は、RTPペイロードのヘッダ部に含まれる情報が通予め定められていた場合における、コーデックモードの番号対応付け(Frame Type Index)及びRTPペイロードフォーマットの例を示す(本実施の形態の第2の例とする)。これは、つまり、本実施の形態の第1の例(図22)のようにRTPペイロードのヘッダ部に含まれる情報が通信開始時のネゴシエーションによって決定されるのではなく、RTPペイロードのヘッダ部の長さが予め決められていた場合である。
本例では、図23Aに示すように、RTPペイロードのデータ部の長さを1秒あたりのキロビット数(kbps:kilo bit per second)に変換して得られるビットレートに対し、番号対応付け(Frame Type Indexとの対応付け)が行われる。本例では、20ミリ秒につき1frame分のエンコードされたデータがRTPパケットとなる。すなわち、1秒間に50個のRTPパケットが発生する。また、RTPペイロードのヘッダ部の長さは、図22Aに示すグロスビットレートが7.2kbps、8kbps、9.6kbpsの場合は5ビットとし、グロスビットレートが13.2kbps、16.4kbps、24.4kbpsの場合は8ビットとしている。なお、1秒あたりのRTPパケットの数、ペイロードのヘッダ部の長さ、及び、グロスビットレートとヘッダ部の長さとの対応付けはこれらに限らない。
図23B及び図23Cは、Codec Mode Requestフィールドを含む場合、及び、含まない場合のRTPペイロードフォーマットの例をそれぞれ示す。本例では、RTPペイロードのヘッダ部に含まれ得る情報である、Frame Type Indexフィールドを4ビットとし、Qビットフィールドを1ビットとし、Codec Mode Requestフィールドを3ビットとした場合の例を示す。
Frame Type Indexフィールドには、図23Aの中で該当するFrame Type Indexが入る。Qビットフィールドは非特許文献1に記載のQビットと同等である。また、Codec Mode Requestフィールドには図23AのFrame Type Indexのうち“0”〜“5”(すなわち、通信相手へのビットレート変更を要求するのに必要な情報のみ)が入る。また、Codec Mode Requestフィールドには、通信相手のエンコーダに対するビットレート変更が無いことを示す値として“6”あるいは“7”を使用してもよい。なお、本例のRTPペイロードのヘッダ部の各フィールド長あるいは該当する値は、これに限らなくてもよいし、本例のRTPペイロードのヘッダ部に含まれる情報(フィールド)もこれに限らない。
本実施の形態の第1の例(図22)、第2の例(図23)では、グロスビットレートあるいはグロスビットレートに応じたRTPペイロードのデータ部の長さだけをFrame Type Indexとして指定する、このようにすることにより、エンコード側でRTPペイロードのデータ部の長さに応じた最適なエンコードを行うことができ、かつ、RTPペイロードのヘッダ部の中のFrame Type Indexのビット数を少なくすることができる。
また、RTPペイロードのヘッダ部の長さを調整可能にする。このようにすることにより、伝送路の特性等によって決められるビットレートの範囲(実施の形態1〜3のコーデックモード(又はコーデックモードセット))等に応じてRTPペイロードのデータ部の長さを決定し、好適なエンコードを行うことができる。なお、Codec Mode RequestフィールドをRTPペイロードのヘッダ部に含めない場合で、通信相手側エンコーダへのビットレートの変更通知が必要な場合には、RTCPにより変更通知が行われる。
(実施の形態6)
本実施の形態では、各UEに対して通信/通話サービスを提供するオペレータのポリシーをコーデックモード(又はコーデックモードセット)選択に使用する方法について説明する。
オペレータのポリシーとしては、例えば、優先して使用されるコーデック(コーデックの方式)、優先して使用されるコーデックビットレート、優先して使用されるサンプリングレート、優先して使用されるオーディオ帯域(例えば、NB,WB,SWB,FB)、優先して使用されるアルゴリズム遅延、及び、優先して使用されるチャンネル数等が挙げられる。また、オペレータのポリシーとしては、他にも、例えば、セッション途中でのビットレート又はチャンネル数の切り替えを許可するか否か、Source-Controlled Variable Bit Rate(VBR)オペレーション(例えば、「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”」を参照)を許可するか否か、及び、非特許文献2に記載のような冗長フレームを許可するか否か等が挙げられる。
UEは、これらオペレータのポリシーの全て又は一部を、通話開始前、すなわち、図2に示すST11の処理が行われる前までに取得し、取得したポシリーに基づいてSDPオファーを生成する。
ポリシー(全て、又は一部)の取得方法として、例えば、オペレータのネットワークからUEに送られてくるシグナリングにポリシー(全て、又は一部)が含まれるようにし、かかるシグナリングから取得する手法を採用してもよい。
このシグナリングは、例えば、SIB(System Information Block。例えば、「3GPP TS 36.331 v10.0.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC) Protocol specification"」を参照)であってもよい。また、このシグナリングは、例えば、RRC(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)等のIMSのSIPシグナリング(例えば「3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (IMS) Stage 2"」を参照)と一緒に送られてきてもよい。また、ポリシー、例えば、P−CSCF検索の応答メッセージに含まれていてもよい。ポリシーが応答メッセージを使ってUEに送られてくる場合、UEからの要求メッセージ(例えば「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)に、オペレータのポリシーを応答メッセージで受け取る能力のあることを示すパラメータを付加してもよい。
また、ポリシーの他の取得方法として、UEは、UEがローカルに保持するポリシーに関する情報の中から、オペレータのネットワークからUEに送られてくる情報に基づいて、オペレータのポリシー(全て、又は一部)を決定してもよい。例えば、UEは、オペレータ毎のポリシー(全て、又は一部)をローカルに保持しており、或るオペレータのネットワークに接続した際に当該オペレータに関する情報(オペレータ情報)を取得し、ローカルに保持しているデータベースの中から該当するオペレータのポリシー(全て、又は一部)を選択する。UEがオペレータのネットワークに接続した際に取得するオペレータ情報は、例えば、Cell ID(例えば、「3GPP TS 23.003 v10.0.0, "Numbering, addressing and identification (Release 10)"」を参照)から取得される。
また、ポリシーの他の取得方法として、UEがオペレータのネットワークに接続した際に送られてくる、ユーザ毎に通話用に許されるQoS情報(例えば、「3GPP TS 23.401 v10.2.1, " Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 10)"」を参照)に基づいて、UEが、通話に優先して使われるコーデックビットレート等を選択してもよい。
次に、オペレータから取得されたポリシーに基づくSDPの生成方法の例を示す。
図24は発呼側UEが接続するオペレータ(オペレータA)のポリシー(図24A)、及び、発呼側UEにおけるSDPオファー生成例(図24B)を示す。また、図25は着呼側UEが接続するオペレータ(オペレータB)のポリシー(図25A)、及び、着呼側UEにおけるSDPアンサー生成例(図25B)を示す。なお、図24及び図25において、ポリシー又はSDPに記述されない項目、値等に関しては、例えば非特許文献2に記載された各方式のデフォルトが適応される。また、図24及び図25に示すポリシー及びSDPの記述方法は一例であり、他の記述方法であってもよい。
例えば、図24Aに示すように、オペレータAのポリシーには、「コーデック:方式1、オーディオ帯域:SWB、ビットレート:[12kbps,24kbps]及びVBR:可(VBRを許可)」というポリシー(以下、ポリシーA1と呼ぶ)が含まれる。また、オペレータAのポリシーには、「コーデック:方式1、オーディオ帯域:WB、ビットレート:[12kbps,24kbps]及びVBR:可(VBRを許可)」というポリシー(以下、ポリシーA2と呼ぶ)が含まれる。更に、オペレータAのポリシーには、「コーデック:方式2、オーディオ帯域:NB、ビットレート:[8kbps,12kbps]及びVBR:不可(VBRを許可しない)」というポリシー(以下、ポリシーA3と呼ぶ)が含まれる。
そこで、発呼側UEは、発呼側UEに対して通信又は通話サービスを提供するオペレータのポリシー(ここでは、図24Aに示すオペレータAのポリシー)の少なくとも一部に対応するコーデックモード(又はコーデックモードセット)の候補を含むSDPオファーを作成する。
例えば、図24Bに示すように、発呼側UEは、図24Aに示すポリシーA1の一部である、コーデック:方式1、オーディオ帯域:SWB、ビットレート:{12,24}kbpsに対応するコーデックモードセットの候補を選択する。具体的には、図24Bに示す、コーデック:方式1、オーディオ帯域:SWB、ビットレート:[12kbps,24kbps]であって、VBR:有(可)、又はVBR:無(不可)となる2つのコーデックモードセットの候補(a=rtpmap:97及び98)が作成される。
同様に、図24Bに示すように、発呼側UEは、図24Aに示すポリシーA2の一部である、コーデック:方式1、オーディオ帯域:WB、ビットレート:{12,24}kbpsに対応するコーデックモードセットの候補を選択する。具体的には、図24Bに示す、コーデック:方式1、オーディオ帯域:WB、ビットレート:[12kbps,24kbps]であって、VBR:有(可)、又はVBR:無(不可)となる2つのコーデックモードセットの候補(a=rtpmap:99及び100)が作成される。
同様に、図24Bに示すように、発呼側UEは、図24Aに示すポリシーA3の全てである、コーデック:方式2、オーディオ帯域:NB、ビットレート:[8kbps,12kbps]及びVBR:無(不可)に対応するコーデックモードセットの候補(a=rtpmap:101)を作成する。
図24Bに示すように、発呼側UEから着呼側UEへ通知されるSDPオファーに含まれる複数のコーデックモード(又はコーデックモードセット)の候補には、発呼側UEに対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード(又はコーデックモードセット)の候補が含まれる。
一方、図25Aに示すように、オペレータBのポリシーには、「コーデック:方式1、オーディオ帯域:WB、ビットレート:12kbps及びVBR:不可(VBRを許可しない)」というポリシー(以下、ポリシーB1と呼ぶ)が含まれる。また、オペレータBのポリシーには、「コーデック:方式2、オーディオ帯域:NB、ビットレート:12kbps、及びVBR:不可(VBRを許可しない)」というポリシー(以下、ポリシーB2と呼ぶ)が含まれる。
そこで、着呼側UEは、発呼側UEから通知された図24Bに示すSDPオファーに含まれるコーデックモードセットの候補のうち、図25Aに示すオペレータBのポリシーの少なくとも一部に対応するコーデックモードセットの候補の中から、発呼側UEとの通信で使用するコーデックモードセットを選択する。
具体的には、図25Bでは、着呼側UEは、図25Aに示すポリシーB1の全てに対応するコーデックモードセットの候補(コーデック:方式1、オーディオ帯域:WB、ビットレート:12kbps、及び、VBR:無(不可))を、発呼側UEとの通信で使用するコーデックモードセットとして選択する。
なお、本実施の形態におけるコーデックモード(又はコーデックモードセット)選択方法は、実施の形態1〜3に示すコーデックモード(又はコーデックモードセット)選択方法と連動して用いられてもよい。
こうすることで、本実施の形態によれば、発呼側UEはSDPオファーに記述するコーデックモード(又はコーデックモードセット)等を当該UEが接続しているオペレータのポリシーに応じて限定することができる。更に、着呼側UEは、発呼側UEとの通信で使用するコーデックモード(又はコーデックモードセット)として選択するコーデックモード(又はコーデックモードセット)等を当該UEが接続しているオペレータのポリシーに応じて限定することができる。これにより、発呼側UEと着呼側UEとの間における複雑なSDP折衝を回避することができる。また、オペレータはポリシーに基づいたサービス(コーデック)をUEに選択させることができる。
(実施の形態7)
本実施の形態では、実施の形態1〜3で用いたネットワーク構成とは異なるネットワーク構成例を用いた場合におけるコーデックモード(又はコーデックモードセット)選択方法について説明する。
図26は本実施の形態に係るネットワーク構成と、UE(端末)の位置関係の一例を示す図である。なお、図26において、UE100、UE102、IPコア網124及びIMS網126は図1と同じであるので同一の符号を付してその説明を省略する。
図26に示すAP2600及びAP2602はアクセスポイント(Access Point)であり、無線アクセス網2606及び無線アクセス網2608をそれぞれ構成する。例えば、AP2600及び2602は、Wi−Fi又はWiMAX等のアクセスポイントであってもよく、図1に示すHeNBであってもよい。
IP−PBX2604は、AP2600及びAP2602と接続しており、例えば企業等の組織内LANにおいて、IP電話による企業内電話網を実現する装置(呼制御のための処理機能を有するネットワークノード)である。例えば、IP−PBX2604は、オペレータのIMS網との接続機能、又は、オペレータのIMS網の機能の一部を有する(例えば、「3GPP TS 22.809 v1.0.0, Feasibility Study on Support for 3GPP Voice Interworking with Enterprise IP- PBX (VINE)"」を参照)。また、IP−PBX2604は、インターネットプロバイダのブロードバンド網等の外部IP網2610を通じてオペレータのIMS網126内に存在するサ−バ2612と接続している。また、IP−PBX2604は、外部IP網2610とのゲートウェイ機能又はIMSシグナリングを終端する機能(図示せず)等を合わせて有してもよい。
サーバ2612は、例えば、図1に示すS−CSCF100等のCSCF、AS(Application Server。例えば、「3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (IMS) Stage 2」に記載)、または、その両方であってもよく、これらCSCFあるいはASと、IP-PBX2604とを繋ぐ装置であってもよい。
AP2614は、IPコア網124に接続しているアクセスポイントである。AP2614は、基地局(eNBまたはHeNB)であってもよい。また、AP2614は、Wi−Fi又はWiMAX等のアクセスポイントであってもよい(例えば、「3GPP TS 23.402 v10.2.1, “Architecture enhancements for non-3GPP accesses"」を参照)。
図26では、UE100は、無線アクセス網2606内でAP2600に接続している。このとき、例えば、UE100の接続先判断部604(図7)は、自機の接続先(無線アクセス網2606)が企業等の組織内LANを構成する無線アクセス網であると判断したとする。なお、AP2600がHeNBである場合、接続先判断部604は、実施の形態1と同様、CSG ID等を用いて接続先を判断してもよい。また、AP2600がWi−Fi等の無線LANのアクセスポイントである場合、接続先判断部604は、SSID(Service Set Identifier)等を用いて接続先を判断してもよい。
本実施の形態では、UE100(発呼側)がUE102(着呼側)に対し発呼する場合、実施の形態1〜3と同様にして、UE100が接続先判断部604(図7、図13)の判断に従ってSDPオファーの中に記述するコーデックモード(又はコーデックモードセット)を選択してもよい。また、UE100でコーデックモード(又はコーデックモードセット)を選択せずにIP−PBX2604でコーデックモード(又はコーデックモードセット)を選択してもよい。
図27は、本実施の形態に係るIP−PBX2604の構成を示すブロック図である。
図27に示すIP−PBX2604において、受信部2700は、発呼側UE(ここではUE100)からのシグナリングメッセージを受け取ると、シグナリングメッセージをシグナリングインタセプト部2704に出力する。
送信部2702は、シグナリング生成部2710から入力されるシグナリングメッセージを、シグナリングメッセージの送信先UE(着呼側UE。ここではUE102)に送信する。
シグナリングインタセプト部2704は、受信部2700から入力されるシグナリングメッセージが自機宛(IP−PBX2604のIPアドレス宛て)でない場合でも、当該シグナリングメッセージを一旦インタセプト(intercept)する。シグナリングインタセプト部2704は、インタセプトしたシグナリングメッセージをシグナリング解析部2706に出力する。
シグナリング解析部2706は、入力されたシグナリングメッセージに記述されている情報を解析し、確認が必要な情報を、適切な確認部に出力する。例えば、シグナリング解析部2706は、着呼側UE(UE102)が現在接続されている無線アクセス網がIP−PBX2604の配下であるか否かを特定するために、シグナリングメッセージに記述された情報のうち、発呼先情報を、端末位置情報確認部2708に渡す。
端末位置情報確認部2708は、着呼側UE(UE102)が現在接続されている無線アクセス網がIP−PBX2604の配下であるか否か(例えば、同一企業内電話網に接続されているか否か)を確認する。この確認は、シグナリング解析部2706から受け取った発呼先情報に基づいて行われる。このとき、端末位置情報確認部2708は、IP−PBX2604内のUE102の登録情報等を用いて確認を行ってもよいし、サーバ2612を通じてIMS網126に存在するUE102の登録情報等の全て又は一部を用いて確認を行ってもよい。または、端末位置情報確認部2708は、これら双方の情報を用いて確認を行ってもよい。端末位置情報確認部2708は、確認結果をシグナリング生成部2710に出力する。
シグナリング生成部2710は、発呼側UE(UE100)から送信されたシグナリングメッセージの中で修正が必要な記載内容の上書き又は新規作成を行う。例えば、端末位置情報確認部2708において、着呼側UE(UE102)が同一企業内電話網(ここではIP−PBX2604配下)に存在すると判断されたとする。この場合、シグナリング生成部2710は、シグナリングメッセージ内のSDPオファーの記述内容について、同一企業内電話網内の通話に用いられるコーデックモード(又はコーデックモードセット)等を含むように新規記述又は上書きする。この際、シグナリング生成部2710は、IP−PBX2604によるSDPオファーの確認済を示す情報を、フラグ、数値及びテキスト等の記載方法でシグナリングメッセージに追加してもよい。
また、端末位置情報確認部2708において、着呼側UE(UE102)が例えば同一企業内電話網(ここではIP−PBX2604配下)の外部に存在すると判断されたとする。この場合にも、シグナリング生成部2710は、シグナリングメッセージ内のSDPオファーの記述内容について、通常の通話に用いられるコーデックモード(又はコーデックモードセット)等を含むように新規記述又は上書きしてもよい。この際、シグナリング生成部2710は、IP−PBX2604によるSDPオファーの確認済を示す情報を、フラグ、数値及びテキスト等の記載方法でシグナリングメッセージに追加してもよい。
新規作成又は修正されたシグナリングメッセージは、送信部2702を介して、シグナリングメッセージの送信先(UE102)に送信される。
シグナリングメッセージを受け取った着呼側UE(UE102)は、自機の接続先(無線アクセス網)が企業等の組織内LANを構成する無線アクセス網であると判断し、かつ受け取ったシグナリングメッセージ内のSDPオファーがIP−PBXによる確認済であることを特定したとする。この場合、着呼側UE(UE102)は、SDPオファー(IP−PBX2604で上書き又は新規作成されたSDPオファー)を参照して、同一企業内電話網内の通話に用いられるコーデックモード(又はコーデックモードセット)等を選択する。この際、実施の形態3と同様にして、着呼側UE(UE102)は、ハンドオーバの可能性の有無なども用いてコーデックモード(又はコーデックモードセット)を選択してもよい。
一方、着呼側UE(UE102)は、自機の接続先(無線アクセス網)が企業等の組織内LANを構成する無線アクセス網であると判断したが、受け取ったシグナリングメッセージ内のSDPオファーがIP−PBXによる確認済であることを特定できなかったとする。この場合、着呼側UE(UE102)は、SDPオファーに記述されたコーデックモード(又はコーデックモードセット)の候補の中から、通常の通信又は通常の通話に用いられるコーデックモード(又はコーデックモードセット)等を選択してもよい。
また、着呼側UE(UE102)の接続先が企業等の組織内LANを構成する無線アクセス網の外部であった場合、着呼側UE(UE102)では、実施の形態1〜3と同様のコーデックモード(又はコーデックモードセット)選択方法が適用される。
そして、着呼側UE(UE102)は、選択したコーデックモード(又はコーデックモードセット)を含むSDPアンサーを生成し、発呼側UE(UE100)へ送信する。
このようにして、本実施の形態では、IP−PBX2604は、着呼側UEが現在接続している無線アクセス網がIP−PBX2604配下である場合、発呼側UEから通知されたSDPオファーに示される複数のコーデックモード(又はコーデックモードセット)候補を変更(新規作成又は上書き)して、新たなSDPオファーを生成する。そして、着呼側UEは、IP−PBX2604で変更された変更後のSDPオファーに含まれる複数のコーデックモード(又はコーデックモードセット)候補の中から、発呼側UEとの通信で使用するコーデックモード(又はコーデックモードセット)を選択する。
これにより、着呼側UEが現在接続している無線アクセス網がIP−PBX2604配下である場合には、SDPオファー内に記述されるコーデックモード(又はコーデックモードセット)の候補等を、IP−PBX2604配下に存在するUEに対して適切なコーデックモード(又はコーデックモードセット)(例えば、同一企業内電話網内の通話に用いられるコーデックモード(又はコーデックモードセット)等)に限定することができる。これにより、発呼側UEと着呼側UEとの間における複雑なSDP折衝を回避することができる。
更に、IP−PBX2604は、SDPオファーを確認したか否か(確認済みであるか否か)を示す情報を着呼側UEへ送信する。そして、着呼側UEは、IP−PBX2604によりSDPオファーの確認済みであることを特定した場合には、IP−PBX2604で変更された変更後のSDPオファーに含まれる複数のコーデックモード(又はコーデックモードセット)候補の中から、発呼側UEとの通信で使用するコーデックモード(又はコーデックモードセット)を選択する。
これにより、UEがIP−PBX2604の配下(同一企業内電話網)に存在するか否かが正確に判断される。そして、例えば、UEがIP−PBX2604の配下(同一企業内電話網)に存在する場合、UEは、同一企業内電話網内の通話に用いられるコーデックモード(又はコーデックモードセット)等に限定してコーデックモード(又はコーデックモードセット)を選択することができる。また、例えば、UEがIP−PBX2604の配下(同一企業内電話網)に存在しない場合、UEは、通常の通信(通常の通話)に用いられるコーデックモード(又はコーデックモードセット)等に限定してコーデックモード(又はコーデックモードセット)を選択することもできる。
こうすることで、本実施の形態では、同一企業内電話網に存在するUEが正確に判断され、UEは好適なコーデックモード(又はコーデックモードセット)等を選択することができる。
なお、本実施の形態では、発呼側UEからのSDPオファーに関してIP−PBX2604で新規記述又は上書きを行う場合について説明した。しかし、本実施の形態において、UE102が同一企業内電話網(ここではIP−PBX2604配下)に存在していた場合、着呼側UEからのSDPアンサーに関しても、前述のようにIP−PBX2604で新規記述又は上書きしてもよい。
また、UE100、UE102、及び、IP−PBX2604でSDPオファー又はSDPアンサーが新規作成又は上書きされる場合に、実施の形態6と同様にして、オペレータのポリシーが使われてもよい。
(実施の形態8)
本実施の形態では、実施の形態4及び5に示したRTPペイロードフォーマットに関し、全てのRTPパケットのRTPペイロード(ヘッダ部、又はデータ部の一部)に含める必要のないフィールドの与え方について説明する。
例えば、実施の形態4及び5に示したコーデックモードリクエスト(Codec Mode Request)のフィールド、又は、モノ/ステレオの切り替え(チャンネル数の指定)及び遅延モードの切り替え(遅延の指定)等を通信相手に要求するフィールド等がある。これらは、要求が発生した場合のみ、RTPペイロード(ヘッダ部、又はデータ部の一部)に含めればよい。
なお、非特許文献3または非特許文献4に記載のSID(Silence Insertion Descriptor)、No Data、speech lostが、図19〜図23などに記載のFrame Type Indexの一部等として、RTPペイロード(ヘッダ部)に含まれない場合もある。この場合、これらSID、No Data、speech lostなどを送る要求が発生した場合にのみ、当該要求を、RTPペイロード(ヘッダ部、又はデータ部の一部)に含めればよい。
図23Aに示すFrame Type Indexを利用した場合のRTPペイロードフォーマットの一例を図28に示す。図23AのFrame Type Indexには上述のSIDは含まれていないが、ここでは、例えばFrame Type Indexの8としてSIDが設定されていたとする。図28Aは、上記フィールド(Codec Mode Requestフィールド、又は、モノ/ステレオの切り替え、遅延モードの切り替え等を通信相手に要求するフィールド)が存在しない場合のRTPペイロードフォーマットの一例を示す。図28Bは、上記フィールドが存在する場合のRTPペイロードフォーマットの一例を示す。
ここで、図28Aに示すRTPペイロードのヘッダ部は例えば1オクテット等の固定長である。図28Aに示すヘッダ部の中には、固定長の「後続ヘッダ部の有無を示すフィールド」、「その他」のフィールド、「Frame Type Index」が含まれる。なお、ここで「ヘッダ部」、「後続ヘッダ部」とは、RTPペイロードデータ部の一部と解釈してもよい。
図28Aに示す「後続ヘッダ部の有無を示すフィールド」には、図28Aに示す固定長のヘッダ部の後に、別の固定長ヘッダ部が続くか否かを示す情報が、例えばフラグ又は数値等の形で入る。図28Aでは、後続する別のヘッダ部は存在しないので、「後続ヘッダ部の有無を示すフィールド」には、後続する別のヘッダ部が「存在しない」ことを示す情報が入る。
図28Aに示す「その他」のフィールドには、「後続ヘッダ部の有無を示すフィールド」及び「Frame Type Index」の両方以外の他のフィールドが含まれる。
図28Aに示す「Frame Type Index」には、例えば図23Aに示すFrame Type Indexが入る。
図28Aに示すRTPペイロードのデータ部には、例えば、実施の形態5で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入る。
一方、図28Bに示す「後続ヘッダ部の有無を示すフィールド」には、図28Bに示す固定長のヘッダ部の後に、別の固定長ヘッダ部(後続ヘッダ)が「存在する」ことを示す情報が入る。
図28Bに示す「その他」のフィールド及び「Frame Type Index」は図28Aと同等である。
図28Bに示す後続ヘッダは例えば1オクテット等の固定長である。図28Bに示す後続ヘッダには、「後続ヘッダの種類」、「後続ヘッダの内容」、及び「その他」のフィールドが含まれる。
図28Bに示す「後続ヘッダの種類」には、当該後続ヘッダが何を示すものであるのか、を示す情報が、例えばフラグ又は数値等で示される。例えば、「後続ヘッダの種類」は、Codec Mode Request、モノ/ステレオ等のチャンネル数の切替要求、又は、遅延モードの切替要求を示してもよく、パケットロス隠蔽のための冗長データを示してもよい。
図28Bに示す「後続ヘッダの内容」には、「後続ヘッダの種類」に示される種類に応じた内容が入る。例えば、「後続ヘッダの種類」がCodec Mode Requestである場合には、通信相手に要求するコーデックビットレートを示す値(例えば図23Aに示すFrame Type Index等)が入る。また、「後続ヘッダの種類」がモノ/ステレオ等のチャンネル数の切替要求又は遅延モードの切替要求等である場合には、要求している切り替え先の情報(例えば、「モノ」への切り替えを示す情報、又は「遅延A」への切り替えを示す情報等)が入る。また、「後続ヘッダの種類」が冗長データである場合、冗長データのデータ長等が入る。
なお、図28Bに示す「後続ヘッダの種類」により上記「後続ヘッダの内容」が一意に決定できる場合には、後続ヘッダはなくてもよい。また、図28Bに示す「後続ヘッダの種類」のフィールドは固定長であるが、「後続ヘッダの内容」のフィールド長は、「後続ヘッダの種類」によって異なる値をとってもよい。
図28Bに示す「その他」のフィールドには、「後続ヘッダの種類」及び「後続ヘッダの内容」の両方以外の他のフィールドが入るが、必要無い場合は無くてもよい。
図28Bに示すRTPペイロードのデータ部には、例えば実施の形態5で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入る。また、データ部には、「後続ヘッダの種類」が冗長パケットであった場合には、冗長パケットも入る。この場合、エンコーダは、主データとして、データ部の長さから冗長パケットの長さを引いた長さに収まる適切なビットレート及び組み合わせを選択しビットストリームを生成する。
このように、本実施の形態の第1の例では、ヘッダ部とデータ部とから成るRTPペイロードにおいて、ヘッダ部は、全てのRTPペイロードにおいて常に設けられるヘッダ部と、全てのRTPペイロードにおいて常に設けられるとは限らないヘッダ部(図28Bに示す後続ヘッダ部)とを含む。また、図28A及び図28Bに示すように、全てのRTPペイロードにおいて常に設けられるヘッダ部には、後続ヘッダ部が設けられるか否かを示すフィールド(後続ヘッダ部の有無を示すフィールド)が含まれる。
なお、本実施の形態におけるRTPペイロードフォーマットは、別の構成を取り得る。
図29は、本実施の形態におけるRTPペイロードフォーマットの第2の例を示す。本例では、特にRTPペイロードで運ぶ必要のある全ての情報が、RTPペイロードのデータ部の一部として運ばれる事を想定し、エンコードされたデータ以外の情報をシグナリング(又はシグナリング部)と呼ぶ。また本例では、コーデックのビットレートを示す情報(Frame Type Index等)は、RTPペイロードに明示的に含まない事を想定する。
図29Aは、後続シグナリング部の有無を示すフィールドのみが、シグナリング部として存在する場合の、RTPペイロードフォーマットの一例を示す。図29Bは、後続シグナリング部の有無を示すフィールド及び後続シグナリング部が存在する場合の、RTPペイロードフォーマットの一例を示す。
ここで、図29Aに示すRTPペイロードの、最上位ビットからの固定長(例えば1ビット等)には、「後続シグナリング部の有無を示すフィールド」が含まれる。なお、ここで「最上位ビットからの固定長」、「後続シグナリング部」とは、上述のようにRTPペイロードデータ部の一部であってもよいし、RTPペイロードのヘッダ部であってもよい。
図29Aに示す「後続シグナリング部の有無を示すフィールド」には、このフィールドの後に、別のシグナリング部が続くか否かを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに“0”が入れば、後続するシグナリングは存在せず、“1”が入れば、後続するシグナリング部が存在する。
図29Aでは、後続する別のシグナリング部は存在しないので、「後続シグナリング部の有無を示すフィールド」には、後続する別のシグナリング部が「存在しない」ことを示す情報(つまり本例では“0”)が入る。
一方、図29Bに示す「後続シグナリング部の有無を示すフィールド」には、図29Bに示す固定長のシグナリング部の後に、別の固定長、又は可変長のシグナリング部(後続シグナリング)が「存在する」ことを示す情報(つまり本例では“1”)が入る。
図29Bに示す後続シグナリング部は、固定長又は可変長であり、「後続シグナリングの種類」及び「後続シグナリングの内容」フィールドを含む。
図29Bに示す「後続シグナリングの種類」では、当該後続シグナリングが何を示すものであるのか、を示す情報が、例えばフラグ又は数値等で示される。例えば、「後続シグナリングの種類」は、Codec Mode Request(コーデックビットレートの切替要求、チャンネル数の切替要求、帯域幅の切替要求など)を示してもよく、また、パケットロス隠蔽のための冗長データの存在を示してもよい。また、「後続シグナリングの種類」は、SID、No Data、図19〜図23などに記載のSpeech lostを示してもよい。
図29Bに示す「後続シグナリングの内容」には、「後続シグナリングの種類」に示される種類に応じた内容が入る。例えば、「後続シグナリングの種類」がCodec Mode Requestのコーデックビットレート切替要求である場合には、通信相手に要求するコーデックビットレートを示す値(例えば、図23Aに示すFrame Type Index等)が入る。また、「後続シグナリングの種類」がCodec Mode Requestのチャンネル数切替要求である場合には、「後続シグナリングの内容」には、要求している切替先の情報(例えば、「モノ」への切り替えを示す情報、「ステレオ」への切替を示す情報等)が入る。また、「後続シグナリングの種類」が冗長データの存在である場合、「後続シグナリングの内容」には、冗長データのデータ長等が入る。なお、「後続シグナリングの内容」が可変長である場合は、「後続シグナリングの種類」に示される種類に応じて、その長さは変わる。
なお、図29Bに示す「後続シグナリングの種類」により上記「後続シグナリングの内容」が一意に決定できる場合、又は、「後続シグナリングの内容」の決定が必要無い場合、「後続シグナリングの内容」はなくてもよい。これは、例えば、「後続シグナリングの種類」が、SID、No Data、あるいは、図19〜図23などに記載のspeech lostを示す場合である。また、図29Bに示す「後続シグナリングの種類」のフィールドは固定長であるのに対し、「後続シグナリングの内容」のフィールド長は、「後続シグナリングの種類」によって異なる値をとってもよい。「後続シグナリングの内容」が「後続シグナリングの種類」によって異なる値をとる場合には、後続シグナリングそのものが可変長となる。
また、RTPペイロードフォーマットは、図29Bにおいて、「後続シグナリングの種類」及び「後続シグナリングの内容」の後に、「後続シグナリング部の有無を示すフィールド」が設けられてもよい。そして、RTPペイロードフォーマットは、更に別の「後続シグナリングの種類」、「後続シグナリングの内容」、「後続シグナリング部の有無を示すフィールド」を続けてもよい(図示せず)。
図29Bに示すRTPペイロードのデータ部には、例えば実施の形態5で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入ってもよい。また、データ部には、「後続シグナリングの種類」が冗長パケットであった場合には、冗長パケットも入る。この場合、エンコーダは、データ部の長さから冗長パケットの長さを引いた長さに収まる適切なビットレート及び組み合わせを選択して、主データとして、ビットストリームを生成する。また、「後続シグナリングの種類」がSIDであった場合は、RTPペイロードのデータ部には、SIDの際に生成されるデータが含まれる。これに対し、「後続シグナリングの種類」がNo Dataあるいは、図19〜図23などに記載のspeech lostであった場合には、RTPペイロードのデータ部には、データは含まれない(データ部自体が存在しなくてもよい)。
本例では、コーデックのビットレートを示す情報(Frame Type Indexなど)がRTPペイロードに明示的に含まない事を想定した。この場合、受信側でRTPペイロード長を算出(IPヘッダまたはUDPヘッダに含まれるデータ長情報より、RTPペイロード長を算出、又はRTPペイロード長自体を計測)し、そこから図29のシグナリング部の長さを取り除く事により、コーデックビットレートが計算される。
また、図29の例では「後続シグナリング部の有無を示すフィールド」が最上位ビットからの固定長としてRTPペイロードの先頭に入る例を示したが、このフィールドは、RTPペイロードのどこに(例えばRTPペイロードの最後に)含まれてもよい。この場合、「後続シグナリング部の有無を示すフィールド」は、「後続のシグナリング部の有無を示す」という意味ではなく、「RTPペイロードの先頭にシグナリング部があるかどうかを示す」という意味となる。
このように、本実施の形態の第2の例では、RTPペイロードは、データ部と、これに含まれるシグナリング部から成る。そして、かかるRTPペイロードにおいて、シグナリング部は、全てのRTPペイロードにおいて常に設けられる「後続シグナリング部の有無を示すフィールド」と、全てのRTPペイロードにおいて常に設けられるとは限らないシグナリング部(図29Bに示す後続シグナリング)とを含む。
図30は、本実施の形態におけるRTPペイロードフォーマットの第3の例を示す。本例では、RTPペイロードの最上位ビットからの固定長に、ヘッダ部が存在するか否かを示すフィールドを設ける事により、RTPペイロードにヘッダ部が存在するか否かを切り替える。これにより、全てのRTPパケットのRTPペイロードに含める必要のないフィールド(シグナリング)が発生する場合には、このRTPペイロードのヘッダ部を利用し、このヘッダ部に情報(シグナリング)を含める。
図30Aは、ヘッダ部の有無を示すフィールドのみが、シグナリング部として存在する場合の、RTPペイロードフォーマットの一例を示す。図30Bは、ヘッダ部が存在する場合の、RTPペイロードフォーマットの一例を示す。
ここで、図30Aに示すRTPペイロードの最上位ビットからの固定長(例えば1ビット等)には、「ヘッダ部の有無を示すフィールド」が含まれる。図30Aに示す「ヘッダ部の有無を示すフィールド」には、このRTPペイロードにヘッダ部が存在するか否か示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに“0”が入ればヘッダ部は存在せず、“1”が入ればヘッダ部が存在する。
図30Aでは、ヘッダ部は存在しないので、「ヘッダ部の有無を示すフィールド」には、ヘッダが存在しない事ことを示す情報(つまり本例では“0”)が入る。なお、図30Aのように、「ヘッダ部の有無を示すフィールド」が、ヘッダが存在しない事ことを示す場合には、この「ヘッダ部の有無を示すフィールド」は、RTPペイロードのデータ部の一部とする。
一方、図30Bに示す「ヘッダ部の有無を示すフィールド」には、図30Bに示すヘッダ部が「存在する」ことを示す情報(つまり本例では“1”)が入る。ヘッダ部が存在する場合、図30B、図30C、図30Dに示すように、ヘッダ部は「基本ヘッダ」と「拡張ヘッダ」から成る。ヘッダ部が存在する場合、基本ヘッダは必ず存在するが、拡張ヘッダは、基本ヘッダの情報の内容によって、存在しない場合もある。
図30Cに、基本ヘッダの一例を示す。本例では、ヘッダ部が存在する場合に、「ヘッダ部の有無を示すフィールド」が基本ヘッダの一部として含まれる例を示すが、このフィールドは、ヘッダ部の一部とせずに、データ部の一部としてもよい。すなわち、「ヘッダ部の有無を示すフィールド」は、基本ヘッダに含まれていなくてもよい。基本ヘッダは固定長であり、基本ヘッダの残りには、例えば「mono/multi」フィールド、「Frame Type」フィールド、及び「後続ヘッダ有無」フィールドが含まれる。
「mono/multi」フィールドには、例えばこのRTPペイロードが運んでいるデータが、モノ(1チャンネル)なのか、ステレオなどのマルチチャンネルなのかを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに“0”が入ればモノを示し、“1”が入ればマルチチャンネルを示す。
「Frame Type」フィールドには、例えば前述の「mono/multi」フィールドがモノを表す場合、図19〜図23などに記載のFrame Type Indexのように、コーデックビットレートの情報、前述のSID(Silence Insertion Descriptor)、No Dataといった情報が含まれる。また上述の「mono/multi」フィールドがマルチチャンネルを表す場合、「Frame Type」には、例えば、マルチチャンネルの情報、ビットレートなどが含まれる。マルチチャンネルの情報とは、すなわち、チャンネル数またはマルチチャンネル用エンコード方式(例えば2チャンネルの場合、右と左とを別々にエンコードする方式か、2チャンネル拡張部を付ける方式か、など)を示す情報である。
「後続ヘッダ有無」フィールドには、例えば基本ヘッダの後に、拡張ヘッダが存在するか否かの情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに“0”が入れば後続ヘッダは存在しない事を示し、“1”が入れば後続ヘッダが存在する事を示す。
基本ヘッダは、固定長であるが、「mono/multi」フィールドの示す内容、つまり、モノかマルチチャンネルかに応じて、その固定長の値が異なっていてもよい。
図30Dに、後続ヘッダが存在する場合の、拡張ヘッダの一例を示す。拡張ヘッダは固定長であり、例えば「ヘッダタイプ」フィールド、「情報」フィールド、及び「後続ヘッダ有無」フィールドを含む。
「ヘッダタイプ」フィールドには、この拡張ヘッダのタイプを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが3ビットである場合、このフィールドに例えば“000”が入れば、拡張ヘッダのタイプが「冗長データ情報」であることを示す。「ヘッダタイプ」フィールドに“001”が入れば、拡張ヘッダのタイプが「Codec Mode Request (bitrate)」であることを示す。「ヘッダタイプ」フィールドに“010”が入れば、拡張ヘッダのタイプが「Codec Mode Request (チャンネル数)」であることを示す。「ヘッダタイプ」フィールドに“011”が入れば、拡張ヘッダのタイプが「Codec Mode Request (帯域)」であることを示す。
「情報」フィールドには、「ヘッダタイプ」の内容によって、異なる情報が入る。例えば上述のように、「ヘッダタイプ」が「冗長データ情報」である場合、例えば「情報」フィールドには冗長データのビットレートを表すFrame Type Indexが入る。これは、つまり、非特許文献2のように、一つのRTPパケットの中に複数のフレームのデータが入っている場合である。また、例えば上述のように、「ヘッダタイプ」が「Codec Mode Request (bitrate)」である場合、「情報」フィールドには、相手端末に要求するコーデックビットレートを示すFrame Type Indexが入る。また、例えば上述のように、「ヘッダタイプ」が「Codec Mode Request (チャンネル数)」である場合、「情報」フィールドには、相手端末に要求するチャンネル数またはマルチチャンネル用エンコード方式が入る。また、例えば上述のように、「ヘッダタイプ」が「Codec Mode Request (帯域)」である場合、「情報」フィールドには、相手端末に要求するエンコーディング帯域を示す情報が入る。
また、例えば、マルチチャンネルを示すフィールド及びマルチチャンネルの情報は、基本ヘッダではなく、拡張ヘッダに含めてもよい。また、逆に、「Codec Mode Request」及び冗長データを表すフィールド、及びその情報は、拡張ヘッダではなく、基本ヘッダに含んでもよい。
「後続ヘッダ有無」フィールドには、例えば、この拡張ヘッダの後に、さらに拡張ヘッダが存在するか否かの情報が、フラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに“0”が入れば、後続ヘッダは存在しない事を示し、“1”が入れば、後続ヘッダが存在する事を示す。
なお、拡張ヘッダは、固定長であるが、「ヘッダタイプ」フィールドの示す内容に応じて、その固定長の値が異なっていてもよい。
拡張ヘッダのヘッダタイプが、例えば「冗長データ情報」または「マルチチャンネル情報」である場合、図30Bに示すRTPペイロードのデータ部には、冗長データ、チャンネル数、マルチチャンネル用エンコード方式に合ったマルチチャンネルデータも含まれる。また、基本ヘッダのFrame TypeがNo Data、あるいは、図19〜図23などに記載のspeech lostなどであった場合には、RTPペイロードのデータ部は無くてもよい。
また、図30の例では「ヘッダ部の有無を示すフィールド」が最上位ビットからの固定長としてRTPペイロードの先頭に入る例を示したが、このフィールドは、RTPペイロードのどこに(例えばRTPペイロードの最後に)含まれてもよい。
このように、本実施の形態の第3の例では、ヘッダ部とデータ部とから成るRTPペイロードにおいて、ヘッダ部が存在しない場合(図30A)と、ヘッダ部が存在する場合(図30B)とを含む。また、図30A及び図30Bに示すように、全てのRTPペイロードにおいて常に、ヘッダ部が設けられるか否かを示すフィールド(ヘッダ部の有無を示すフィールド)が含まれる。
なお、実施の形態5で述べたように、伝送ブロックサイズ等が決められているために、RTPペイロード長、特に通常の音声等のデータを運ぶRTPペイロード長が、複数の固定長に限られる場合がある。このような場合、本実施の形態のように、通常の音声等のデータを運ぶRTPペイロードにCodec Mode Requestを含めると、RTPペイロード長が、対応する伝送ブロックサイズより長くなる可能性がある。
これを解決するため、端末は、データ部が存在しないRTPペイロード、又は、通常データを送る場合に比べてデータ部が短いRTPペイロードが送られるタイミングで、Codec Mode RequestをこれらRTPペイロードに含めて送ってもよい。データ部が存在しない場合、又は通常データを送る場合に比べてデータ部が短い場合とは、例えば、SID、No Data、あるいは図19〜図23に記載のspeech lostを用いる場合である。
このように、本実施の形態によれば、RTPペイロードにおいて、必要な場合にのみ必要なフィールドを与えた上で、データ部の長さに収まる適切なビットレートとその組み合わせをエンコーダに選択させることができる。
以上、本発明の各実施の形態について説明した。
なお、Frame Type Indexは用意されている全てのコーデックモード(ビットレートそのもの、又は、ビットレートの組み合わせ)を記述する必要はなく、コーデックモードの一部を定義してもよい。
また、上記実施の形態では、実際のコーデックモード(又はコーデックモードセット)とコーデックモード(又はコーデックモードセット)を示す番号(数値)との対応付けが規定されている場合について説明した。そして、コーデックモード(又はコーデックモードセット)を示す番号(数値)がSDP(図8及び図11)に記述される場合について説明した。しかし、実際のコーデックモード(又はコーデックモードセット)がSDPに直接記述されてもよい。
また、図8、図11、図14及び図17で記述されている「方式1」は、特定のコーデック名を表す。例えば、「方式1」はEVS、AMR又はAMR−WBでもよく、別のコーデックであってもよい。また、図8及び図14では、方式1のコーデックに関してのみオファーされている記述となっているが、他の方式(方式2、方式3...)に関しても同様に記述され、SDPオファーの中に含まれてもよい。
また、或るコーデック内での異なる種別、チャンネル数(モノ、ステレオ)等)は、コーデック名としてSDP内に記述されてもよく、図9及び図15に示すコーデックモードセットの対応付けの中で定義されてもよい。ここで、コーデック内での異なる種別とは、例えば、EVSの中の、AMR−WBインタオペラブルモード又はAMR−WB非インタオペラブルモード、オーディオ帯域(Narrow Band、Wide Band、Super Wide Band、Full Band等を含む。
また、上記実施の形態では、無線アクセス網の特性に関する情報として、CSG ID又は基地局IDを用いる場合について説明した。しかし、無線アクセス網の特性に関する情報としては、これらに限らず、例えば、UEが接続されているセル(HeNB)を示すセル情報、及び、UEの位置を示す位置情報等が挙げられる。
また、上記実施の形態では、UE間の通信開始時のコーデックモード(又はコーデックモードセット)(ビットレート及びアルゴリズム遅延を含む)を選択する場合について説明したが、これに限られない。例えば、UEが有している能力(例えば、ディスプレイの大きさ等)を選択する場合についても上記実施の形態を適用することができる。
また、上記実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。
また、本発明は、上記実施の形態に限定されず、種々変更して実施することが可能である。
また、上記実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部又は全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)、LSI内部の回路セルの接続または設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
2010年11月10日出願の特願2010−252113の日本出願、2010年12月14日出願の特願2010−278222の日本出願、2011年4月6日出願の特願2011−84442の日本出願、及び2011年8月9日出願の特願2011−173910の日本出願に含まれる明細書、図面及び要約書の開示内容は、すべて本願に援用される。