JPWO2011070740A1

JPWO2011070740A1 - ゲートウェイ装置、中継方法、プログラム、フェムトシステム

Info

Publication number: JPWO2011070740A1
Application number: JP2011545067A
Authority: JP
Inventors: 日出海細部; 佳央植田
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2009-12-10
Filing date: 2010-11-29
Publication date: 2013-04-22
Anticipated expiration: 2030-11-29
Also published as: EP2512177A4; US20120245928A1; CN102714817B; WO2011070740A1; EP2512177B1; EP2512177A1; KR101457282B1; US9178724B2; KR20120094110A; CN102714817A; JP5708494B2

Abstract

ＨＮＢ−ＧＷとＨＮＢ間の帯域不足に起因する音質劣化を回避するために、フェムトシステム１００において、ＨＮＢ−ＧＷ１４０は、ネットワーク１３０を介してＨＮＢ１２０と接続され、ＭＧＷ１７０とＨＮＢ１２０間における音声データの送受信を中継する。ＨＮＢ−ＧＷ１４０における狭帯域判定部１５０は、ネットワーク１３０の帯域が所定の閾値以下となる狭帯域であるか否かを判定する。変換部１６０は、狭帯域判定部１５０により狭帯域である判定がなされたときに、ＭＧＷ１７０からＨＮＢ１２０に転送する音声データのビットレートを下げるように音声データを変換する。

Description

本発明は、中継技術、具体的にはメディアゲートウェイとフェムトセルとの間における音声データの中継技術に関する。

半径数百メートルから十数キロメールの通話エリアを持つ従来の携帯電話基地局同士の境界領域やビルの奥、地下などでは、電波強度が微弱であるため、これらの場所では上記基地局に接続できない問題が発生する。この問題を解決するために、通話エリアが半径数十メートル程度の小型基地局を設置し、上記場所でも通話可能としたサービスが提供されている。このような小型基地局は、フェムトセルと呼ばれている。以下の説明において、フェムトセルが設けられたシステムをフェムトシステムという。

図１８は、フェムトシステムの例を示す。このフェムトシステム１０は、フェムトセル３０と、ゲートウェイ装置５０と、メディアゲートウェイ５２と、回線交換機５４を備える。なお、メディアゲートウェイ５２は、回線交換機５４に含まれる場合もあるが、分かりやすいように、メディアゲートウェイ５２と回線交換機５４を分けて図示および説明をする。

なお、以下の説明において、フェムトセル、ゲートウェイ装置、メディアゲートウェイ、回線交換機をそれぞれＨＮＢ（ＨｏｍｅＮｏｄｅＢ）、ＨＮＢ−ＧＷ（ＨｏｍｅＮｏｄｅＢＧａｔｅｗａｙ）、ＭＧＷ（ＭｅｄｉａＧａｔｅｗａｙ）、ＭＳＣ（Ｍｏｂｉｌｅ−ｓｅｒｖｉｃｅＳｗｉｔｃｈｉｎｇＣｅｎｔｅｒ）という。また、ＨＮＢ３０に接続する各端末装置２０をＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ）という。

ゲートウェイ装置５０は、ＭＧＷ５２とＨＮＢ３０間における音声データの送受信の中継を行うものであり、ネットワーク４０を介してＨＮＢ３０と接続される。通話の音声データは、ＭＧＷ５２、ＨＮＢ−ＧＷ５０、ネットワーク４０、ＨＮＢ３０の順にＵＥ２０に送信され、または、ＨＮＢ３０、ネットワーク４０、ＨＮＢ−ＧＷ５０、ＭＧＷ５２の順にＵＥ２０から送信される。また、非特許文献６と非特許文献１に記載れたように、「ＴｈｅＲＵＡｈａｓｔｈｅｆｏｌｌｏｗｉｎｇｆｕｎｃｔｉｏｎｓ：ＴｒａｎｓｐａｒｅｎｔｔｒａｎｓｆｅｒｏｆＲＡＮＡＰｍｅｓｓａｇｅｓ」、「ＩｕＵＰｉｓｔｅｒｍｉｎａｔｅｄｉｎＣＮａｎｄＨＮＢ（ｉ．ｅ．ｎｏｔｉｎｔｈｅＨＮＢＧＷ）、すなわちＨＮＢ−ＧＷ５０では、ＲＡＮＡＰ、および、Ｉｕ−ＵＰより上位のデータを透過転送することになっており、ＭＳＣ５４／ＭＧＷ５２、ＨＮＢ３０、ＵＥ２０は、同一のコーデックが使用されるようになっている。

３ＧＰＰＴＳ２５．４６７ＵＴＲＡＮａｒｃｈｉｔｅｃｔｕｒｅｆｏｒ３ＧＨｏｍｅＮｏｄｅＢ（Ｖ８．３．０）３ＧＰＰＴＳ２５．４６９ＵＴＲＡＮＩｕｈｉｎｔｅｒｆａｃｅＨｏｍｅＮｏｄｅＢＡｐｐｌｉｃａｔｉｏｎＰａｒｔ（Ｖ８．３．０）３ＧＰＰＴＳ２４．００８Ｃｏｒｅｎｅｔｗｏｒｋｐｒｏｔｏｃｏｌｓ（Ｖ８．７．０）３ＧＰＰＴＳ２５．４１３ＵＴＲＡＮＩｕｉｎｔｅｒｆａｃｅＲＡＮＡＰｓｉｇｎａｌｌｉｎｇ（Ｖ８．４．０）ＲＦＣ１８８９ＲＴＰ３ＧＰＰＴＳ２５．４６８ＵＴＲＡＮＩｕｈＩｎｔｅｒｆａｃｅＲＡＮＡＰＵｓｅｒＡｄａｐｔａｔｉｏｎｓｉｇｎａｌｌｉｎｇ

ところで、ＨＮＢ３０とＨＮＢ−ＧＷ５０を接続するネットワーク４０は、通常、インターネット（登録商標）やイントラネットなどの汎用回線である。この汎用回線の帯域が狭い場合には、帯域不足に起因して音質の劣化が生じうる。

一方、ネットワーク４０として帯域の広い回線例えば衛星回線を使用してフェムトシステムを構築すればＨＮＢ−ＧＷ５０とＨＮＢ３０間の帯域不足の問題を解消することが考えられるが、ＨＮＢ−ＧＷ５０とＨＮＢ３０のいずれも衛星回線に対応する必要があり、高価となるため、フェムトシステムの普及が困難になる。

本発明は、上記事情に鑑みてなされたものであり、フェムトシステムにおいて、ＨＮＢ−ＧＷとＨＮＢを接続するネットワークの帯域が狭くても音質の劣化を回避できる技術を提供する。

本発明の１つの態様は、ネットワークを介してフェムトセルと接続され、メディアゲートウェイとフェムトセル間における音声データの送受信を中継するゲートウェイ装置である。このゲートウェイ装置は、上記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定部と、該狭帯域判定部により狭帯域である判定がなされたときに、メディアゲートウェイからフェムトセルに転送する音声データのビットレートを下げるように音声データを変換する変換部を備える。

なお、上記態様のゲートウェイ装置を方法やシステムに置換えて表現したもの、該ゲートウェイ装置を備えたシステム、コンピュータを該ゲートウェイ装置として動作せしめるプログラム、該プログラムを記録した記録媒体なども、本発明の態様としては有効である。

本発明にかかる技術によれば、フェムトシステムにおいて、ＨＮＢ−ＧＷとＨＮＢを接続するネットワークの帯域が狭くても音質の劣化を回避できる。

本発明の第１の実施の形態にかかるフェムトシステムを示す図である。図１に示すフェムトシステムにおいてＨＮＢが使用する帯域が狭帯域であるか否かを判定する処理を示すフローチャートである。図１に示すフェムトシステムにおけるＡＭＲ起動の手順を示す図である。本発明の第２の実施の形態にかかるフェムトシステムにおいてが使用する帯域が狭帯域であるか否かを判定する処理を示すフローチャートである。本発明の第２の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージの例を示す図である。本発明の第５の実施の形態のフェムトシステムにおいてＨＮＢがＡＭＲフレーム多重化をサポートするか否かを判定する処理を示すフローチャートである。本発明の第５の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージの例を示す図である。本発明の第５の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの例を示す図である。本発明の第６の実施の形態のフェムトシステムにおいてＨＮＢがＲＴＰパケット多重化をサポートするか否かを判定する処理を示すフローチャートである。本発明の第６の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージの例を示す図である。本発明の第６の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの例を示す図である。本発明の第７の実施の形態のフェムトシステムにおいてＨＮＢがＵＤＰパケット多重化をサポートするか否かを判定する処理を示すフローチャートである。本発明の第７の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージの例を示す図である。本発明の第７の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの例を示す図である。本発明の第８の実施の形態のフェムトシステムにおいてＨＮＢがｄｅｆｌａｔｅをサポートするか否かを判定する処理を示すフローチャートである。本発明の第８の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージの例を示す図である。本発明の第８の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの例を示す図である。従来のフェムトシステムを説明するための図である。

以下、図面を参照しながら、本発明にかかる実施の形態を説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡略化がなされている。また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙｃｏｍｐｕｔｅｒｒｅａｄａｂｌｅｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅｓｔｏｒａｇｅｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（ＰｒｏｇｒａｍｍａｂｌｅＲＯＭ）、ＥＰＲＯＭ（ＥｒａｓａｂｌｅＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙｃｏｍｐｕｔｅｒｒｅａｄａｂｌｅｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜第１の実施の形態＞
図１は、本発明の第１の実施の形態にかかるフェムトシステム１００を示す。フェムトシステム１００は、３ＧＰＰ（ＴｈｉｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）で定められた仕様に準拠するものであり、フェムトセル（ＨＮＢ）１２０と、ゲートウェイ装置（ＨＮＢ−ＧＷ）１４０と、メディアゲートウェイ（ＭＧＷ）１７０と、回線交換機（ＭＳＣ）１８０を備える。ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０とＨＮＢ１２０間における音声データの送受信を中継するものであり、インターネットなどのネットワーク１３０を介してＨＮＢ１２０と接続されている。ＨＮＢ−ＧＷ１４０は、狭帯域判定部１５０と変換部１６０を有する。

各端末（ＵＥ）１１０は、ＨＮＢ１２０に接続して通話を行う。通話の音声データは、ＭＧＷ１７０、ＨＮＢ−ＧＷ１４０、ネットワーク１３０、ＨＮＢ１２０の順にＵＥ１１０に送信され、ＨＮＢ１２０、ネットワーク１３０、ＨＮＢ−ＧＷ１４０、ＭＧＷ１７０の順にＵＥ１１０から送信される。

フェムトシステム１００は、ＨＮＢ−ＧＷ１４０を除いて、通常のこの種のシステムと同様である。そのため、ＨＮＢ−ＧＷ１４０についてのみ詳細に説明する。また、ＨＮＢ−ＧＷ１４０は、狭帯域判定部１５０と変換部１６０を備える点以外、通常のＨＮＢ−ＧＷと同様の構成と機能を有するため、ＨＮＢ−ＧＷ１４０については、狭帯域判定部１５０と変換部１６０についてのみ詳細に説明する。

狭帯域判定部１５０は、ネットワーク１３０の帯域が狭帯域であるか否かを判定し、判定結果を変換部１６０に出力する。具体的には、ネットワーク１３０の帯域が所定の閾値例えば２００ｋｂｐｓ以下であれば狭帯域と判定し、ネットワーク１３０の帯域が閾値より広ければ狭帯域ではないと判定する。

本実施の形態において、狭帯域判定部１５０は、ＨＮＢ１２０の設置場所に基づいて狭帯域か否かの判定を行う。狭帯域判定部１５０には、狭帯域の位置を示す狭帯域位置情報が予めデータベースに登録されている。この狭帯域位置情報は、例えば非特許文献２に記載された、３ＧＰＰで定められているパラメータ（ＨＮＢＬｏｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ）、ＬＡＣ（ＬｏｃａｔｉｏｎＡｒｅａＣｏｄｅ）、ＲＡＣ（ＲｏｕｔｉｎｇＡｒｅａＣｏｄｅ）、ＳＡＣ（ＳｅｒｖｉｃｅＡｒｅａＣｏｄｅ）のうちの１つまたは複数の組合せである。

狭帯域判定部１５０は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅ）の中でネットワーク１３０の帯域が狭帯域か否かの判定をする。図２を参照して説明する。

図２において、ステップＳ１は、狭帯域位置情報が予めＨＮＢ−ＧＷ１４０に登録される手順であり、ステップＳ２〜６は、ＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅに含まれる処理である。ステップＳ５を除き、ステップＳ２〜６のうちの他の各ステップは、通常のフェムトシステムにおけるＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅの手順である。

ステップＳ４で、ＨＮＢ１２０は、「ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。このメッセージの中に、前述したパラメータ「ＨＮＢＬｏｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ」、「ＬＡＣ」、「ＲＡＣ」、「ＳＡＣ」が含まれている。これらのパラメータは、ＨＮＢ１２０の設置場所を示しうる情報である。

ＨＮＢ−ＧＷ１４０における狭帯域判定部１５０は、ステップＳ５で、「ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージに含まれる上述のパラメータを、ＨＮＢ１２０の設置場所を示す情報として取得して、予め登録された狭帯域位置情報と照合する。ＨＮＢ１２０の設置場所が、狭帯域位置情報が示す位置のいずれかと一致する場合には、ネットワーク１３０の帯域が狭帯域であると判定する。一方、ＨＮＢ１２０の設置場所が、狭帯域位置情報が示す位置のいずれとも一致しない場合には、ネットワーク１３０の帯域が狭帯域ではないと判定する。

ＨＮＢ−ＧＷ１４０における変換部１６０は、狭帯域判定部１５０により狭帯域である判定がなされたときに、ＭＧＷ１７０からの音声データのビットレートを低いビットレートに変換してＨＮＢ１２０に転送する。なお、変換に際して、ＨＮＢ１２０に接続されたＵＥ１１０がサポートするビットレートを確認し、ＵＥ１１０がサポートする低いビットレートに音声データを変換する。フェムトシステムにおいて、音声データは、符号化されて伝送される。本実施の形態においては、音声データは、ＡＭＲ（ＡｄａｐｔｉｖｅＭｕｌｔｉ−Ｒａｔｅ：適応多重レート）と呼ばれるコーデック方式で符号化されて伝送されているとする。ここで、ＭＧＷ１７０からの音声データが音声通信システムに広く用いられるＡＭＲ１２．２ｋｂｐｓのものであるとする。また、例として、本実施の形態において、変換部１６０は、低いビットレートとしてＡＭＲのうちの最も低いＡＭＲ４．７５ｋｂｐｓを用い、狭帯域判定部１５０により狭帯域である判定がなされ、かつＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートする場合において、ＭＧＷ１７０からの音声データをＡＭＲ１２．２ｋｂｐｓからＡＭＲ４．７５ｋｂｐｓに変換する。

フェムトシステムにおいて、ＵＥとＭＧＷ間の音声データの転送に先立って、「ＡＭＲ起動」と呼ばれる処理が行われる。この処理は、当該ＵＥと、ＨＮＢ、ＭＳＣ間でＡＭＲに関する情報を交換し、ＡＭＲビットレートの取り決めなどを行う。なお、ＡＭＲ起動は、ＵＥへの発呼があった際と、ＵＥからの発呼があった際に行われ、ＡＭＲ起動後は、通話に伴う音声データの転送がなされる。

ＵＥからの発呼によるＡＭＲ起動の場合、ＮＡＳＰｒｏｃｅｄｕｒｅの中でＵＥからＨＮＢ−ＧＷにＣＣ（ＣａｌｌＣｏｎｔｒｏｌ）のためのＳＥＴＵＰメッセージが発信される。ＵＥへの発呼によるＡＭＲ起動の場合、ＮＡＳＰｒｏｃｅｄｕｒｅの中でＵＥからＨＮＢ−ＧＷにＣＣのためのＣＡＬＬＣＯＮＦＩＲＭメッセージが発信される。通常のフェムトシステムにおいて、これらのメッセージは、ＨＮＢ−ＧＷによりＭＳＣに転送される。本実施の形態のフェムトシステム１００では、ＨＮＢ−ＧＷ１４０において、上記転送に加え、さらに変換部１６０による該メッセージに基づいたＵＥ１１０のＡＭＲ能力の確認が行われる。ＵＥ１１０のＡＭＲ能力とは、ＵＥ１１０がサポートするＡＭＲビットレートを意味する。上記ＳＥＴＵＰメッセージおよびＣＡＬＬＣＯＮＦＩＲＭメッセージには、パラメータ「ＳｕｐｐｏｒｔｅｄＣｏｄｅｃＬｉｓｔ」が含まれており、該パラメータを参照して、ＵＥ１１０がサポートするＡＭＲビットレートを確認することができる。本実施の形態において、変換部１６０は、上記パラメータから、ＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートするか否かを確認する。以降、変換部１６０は、この確認の結果をＵＥ１１０と対応付けて保持する。以下の説明において、変換部１６０が既にＵＥ１１０のＡＭＲ能力を把握したとする。

図３を参照して、ネットワーク１３０の帯域が狭帯域であり、かつ発呼された、または発呼したＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートする場合、フェムトシステム１００におけるＡＭＲ起動の処理を説明する。

ＵＥ１１０への発呼、またはＵＥ１１０からの発呼があると、まず、ＵＥ１１０、ＨＮＢ１２０、ＨＮＢ−ＧＷ１４０、ＭＳＣ１８０間でＮＡＳＰｒｏｃｅｄｕｒｅが行われる（Ｓ１１）。そして、ＭＳＣ１８０からＨＮＢ−ＧＷ１４０に「ＲＡＮＡＰ：ＲＡＢＡＳＳＩＧＮＭＥＮＴＲＥＱＵＥＳＴ」メッセージが送信される（Ｓ１２）。このメッセージは、非特許文献４の９．１．３章に定められるパラメータ「ＲＡＢＰａｒａｍｅｔｅｒｓ」が含まれている。このパラメータは、ＵＥ１１０に送信する音声データのＡＭＲビットレートを示すものであり、本実施の形態では、１２．２ｋｂｐｓに対応する値が設定される。このステップは、通常のフェムトシステムにおいて行われる手順である。

次に、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に「ＲＡＮＡＰ：ＲＡＢＡＳＳＩＧＮＭＥＮＴＲＥＱＵＥＳＴ」メッセージを転送する。通常のフェムトシステムにおいて、この「ＲＡＮＡＰ：ＲＡＢＡＳＳＩＧＮＭＥＮＴＲＥＱＵＥＳＴ」メッセージはそのままＨＮＢ１２０に転送されるが、本実施の形態において、ネットワーク１３０が狭帯域である判定がなされ、かつＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートする場合に、ＨＮＢ−ＧＷ１４０における変換部１６０は、該メッセージに含まれるパラメータ「ＲＡＢＰａｒａｍｅｔｅｒｓ」の値をＡＭＲ４．７５ｋｂｐｓに対応する値に書き換えてＨＮＢ１２０に送信する（Ｓ１３、Ｓ１４）。

これにより、ＵＥ１１０とＨＮＢ１２０間でＡＭＲ４．７５ｋｂｐｓでＲＢ（ＲａｄｉｏＢｅａｒｅｒ）が確立される（Ｓ１５）。

ＲＢの確立後に、ステップＳ１６を経て、ＨＮＢ−ＧＷ１４０により、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＲＡＢＡＳＳＩＧＮＭＥＮＴＲＥＳＰＯＮＳＥ」メッセージが転送される。このメッセージは、非特許文献４の９．１．４章に定められるパラメータＡｓｓｉｇｎｅｄＲＡＢＰａｒａｍｅｔｅｒＶａｌｕｅｓ」が含まれている。ここで、ＨＮＢ１２０からのメッセージに含まれるこのパラメータは、ＡＭＲ４．７５ｋｂｐｓに対応する値になっている。

通常のフェムトシステムにおいて、このメッセージはそのままＭＳＣ１８０に転送されるが、本実施の形態において、ＨＮＢ−ＧＷ１４０は、該メッセージをＭＳＣ１８０に転送する際に、メッセージに含まれるパラメータ「ＡｓｓｉｇｎｅｄＲＡＢＰａｒａｍｅｔｅｒＶａｌｕｅｓ」の値をＡＭＲ４．７５ｋｂｐｓに対応する値からＡＭＲ１２．２ｋｂｐｓに書き換えてＭＳＣ１８０に送信する（Ｓ１７、Ｓ１８）。

これにて、ＡＭＲ起動が完了する。
以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０とＵＥ１１０間での音声データの送受信を中継する（Ｓ１９〜）。中継に際して、変換部１６０により、音声データのビットレートの変換を行う。具体的には、ＭＧＷ１７０からの音声データをＵＥ１１０に転送する際に、変換部１６０は、まず、ＭＧＷ１７０から受信したＡＭＲ１２．２ｋｂｐｓの音声データをＰＣＭ（ＰｕｌｓｅＣｏｄｅＭｏｄｕｌａｔｉｏｎ）の音声データに変換する。そして、ＰＣＭ音声データをＡＭＲ４．７５ｋｂｐｓの音声データに変換して該ＵＥ１１０に送信する。また、ＵＥ１１０からの音声データをＭＧＷ１７０に転送する際には、変換部１６０は、該ＵＥ１１０から受信したＡＭＲ４．７５ｋｂｐｓの音声データをＰＣＭデータに変換し、そしてＰＣＭデータをＡＭＲ１２．２ｋｂｐｓの音声データに変換してＭＧＷ１７０に送信する。

ＡＭＲの音声データからＰＣＭの音声データへの変換、及びＰＣＭの音声データからＡＭＲの音声データへの変換については、従来からよく知られているため、ここで詳細な説明を省略する。

このように、本実施の形態のフェムトシステム１００のＨＮＢ−ＧＷ１４０は、ネットワーク１３０の帯域が狭帯域であり、かつＵＥ１１０が低いＡＭＲビットレートをサポートする場合において、ＡＭＲ起動中に、ＭＳＣ１８０からの「ＲＡＮＡＰ：ＲＡＢＡＳＳＩＧＮＭＥＮＴＲＥＱＵＥＳＴ」メッセージをＨＮＢ１２０に転送する際に、該メッセージに含まれるパラメータ「ＲＡＢＰａｒａｍｅｔｅｒｓ」の値をＵＥ１１０のサポートする低いビットレートに対応する値に書き換え、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＲＡＢＡＳＳＩＧＮＭＥＮＴＲＥＳＰＯＮＳＥ」メッセージに含まれるパラメータ「ＡｓｓｉｇｎｅｄＲＡＢＰａｒａｍｅｔｅｒＶａｌｕｅｓ」の値をＭＳＣ１８０のＡＭＲビットレートに書き換える。その後、このＵＥ１１０とＭＧＷ１７０間で音声データを転送する際に、ＭＧＷ１７０から受信した音声データのビットレートを下げてＵＥ１１０に転送し、ＵＥ１１０から受信した音声データのビットレートを上げてＭＧＷ１７０に転送する。こうすることにより、ネットワーク１３０の帯域が狭帯域であっても、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０間で送受信される音声データのビットレートが低いため、帯域不足に起因する音声劣化を回避することができる。また、従来のフェムトシステムと比べ、ＨＮＢ−ＧＷのみが異なり、ＵＥや、ＭＧＷ、ＭＳＣについでは、従来と同様のものを用いることができる。

以下、本発明にかかる他の実施の形態について説明する。これらの実施の形態のいずれもフェムトシステムであり、基本的な構成は、フェムトシステム１００と同様である。そのため、これらの実施の形態の説明に際して、フェムトシステム１００と異なる点についてのみ説明し、機能ブロックについては、フェムトシステム１００のものと同様の名称と符号を用いる。

＜第２の実施の形態＞
本発明にかかる第２の実施の形態のフェムトシステムは、ＨＮＢ１２０が、自身が使用する帯域（すなわちネットワーク１３０の帯域）を測定してＨＮＢ−ＧＷ１４０に報告し、ＨＮＢ−ＧＷ１４０がＨＮＢ１２０からの報告に基づいてネットワーク１３０の帯域が狭帯域であるか否かを判定する点においてのみ、フェムトシステム１００と異なる。図４と図５を参照して説明する。

図４に示すように、ＨＮＢ１２０は、初期化（ＨＮＢＩｎｉｔｉａｌｉｚａｔｉｏｎ）の実行中に、自身が使用する帯域を測定する（Ｓ２１）。帯域の測定方法については、従来知られている種々の方法を用いればよい。

初期化後、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０間でＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎが確立される（Ｓ２２）。

そして、ＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージを送信する。図５は、このメッセージの例を示す。図５に示す例では、最下欄のパラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージにも含まれるものである。

本実施の形態において、ＨＮＢ１２０は、ＨＮＢＩｎｉｔｉａｌｉｚａｔｉｏｎの実行中に帯域を測定し、測定した帯域を示す情報を、「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージに対して追加したパラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」に設定する。

図４に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージに含まれるパラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」の値に基づいて、ＨＮＢ１２０が使用する帯域すなわちネットワーク１３０の帯域が狭帯域であるか否かを判定する。具体的には、パラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」の値が所定の閾値以下であれば狭帯域である判定をし、パラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」の値が所定の閾値より大きければ狭帯域ではない判定をする。

本実施の形態のフェムトシステムは、以降の動作についてフェムトシステム１００と同様であり、フェムトシステム１００と同様の効果を得ることができる。また、フェムトシステム１００で使用される狭帯域位置情報の登録をする必要が無い。

＜第３の実施の形態＞
本発明にかかる第３の実施の形態のフェムトシステムは、ＨＮＢ−ＧＷ１４０が、ＵＥ１１０から受信した音声データのＲＴＰｔｉｍｅｓｔａｍｐと該音声データの受信時刻とを用いてネットワーク１３０の帯域が狭帯域であるか否かの判定を行う点と、ＡＭＲ起動後に該判定を行うため、ＵＥ１１０のＡＭＲ能力を把握する処理を常に実行する必要がある点において、フェムトシステム１００と異なる。

ＨＮＢ１２０から送信される音声データには、ＲＴＰヘッダが付与され、非特許文献５の５．１章で定められる通り、ＲＴＰｔｉｍｅｓｔａｍｐが含まれる。

本実施の形態において、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から音声データ（ＲＴＰパケット）を受信した時、該ＲＴＰパケットの受信時刻と、該ＲＴＰパケットのＲＴＰヘッダに含まれるＲＴＰｔｉｍｅｓｔａｍｐとを比較することにより、該ＲＴＰパケットがＨＮＢ１２０からＨＮＢ−ＧＷ１４０までのＲＴＰパケット到達時間を算出する。そして、所定期間における、到達時間が所定の閾値以上のＲＴＰパケットの割合が所定の割合以上である場合に、ＨＮＢ１２０が使用する帯域すなわちネットワーク１３０の帯域が狭帯域であると判定する。以降、該ＨＮＢ１２０から起動されるＡＭＲに対して、ＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートするか否かを判定し、ＡＭＲ４．７５ｋｂｐｓをサポートする場合には、フェムトシステム１００のときと同様に、パラメータの書換えと、音声データのビットレートの変換を行う。それ以外の場合には、パラメータの書換えと音声データのビットレートの変換を行わない。

本実施の形態のフェムトシステムも、フェムトシステム１００と同様の効果を得ることができる。また、フェムトシステム１００で使用される狭帯域位置情報の登録をする必要が無い。

なお、到達時間の閾値およびＲＴＰパケットの割合の閾値の決定に、ＲＴＰパケット受信時に該当ＨＮＢで起動されている呼の種別と呼の数を考慮することが望ましい。多数のＵＥが呼を起動している状態で起こった遅延より、少数のＵＥが呼を起動している状態で起こった遅延のほうが、帯域がより狭いと判断する。また、データ速度が大きい呼が起動されている状態で起こった遅延より、データ速度が小さい呼が起動されている状態で起こった遅延のほうが、帯域が狭いと判断する。

＜第４の実施の形態＞
本発明にかかる第４の実施の形態のフェムトシステムは、ＨＮＢ−ＧＷ１４０が、ＨＮＢ１２０が既に起動されている状態でｐｉｎｇコマンドを実行することによりＨＮＢ１２０が使用する帯域が狭帯域であるか否かの判定を行う点において、フェムトシステム１００と異なる。

ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０で呼が１つ以上起動されている場合、所定の周期で該ＨＮＢ１２０にｐｉｎｇコマンドを送信する。

その後、ＨＮＢ−ＧＷ１４０は、該ＨＮＢ１２０からｐｉｎｇコマンドに対する応答を受信し、ｒｏｕｎｄ−ｔｒｉｐｔｉｍｅを計算し、その統計を取る。ＨＮＢ−ＧＷ１４０は、ｒｏｕｎｄ−ｔｒｉｐｔｉｍｅが所定の閾値以上となるｐｉｎｇコマンドの割合が所定の割合以上になった場合、該ＨＮＢ１２０が使用する帯域が狭帯域であると判定する。以後、該ＨＮＢ１２０から起動されるＡＭＲに対して、ＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートするか否かを判定し、ＡＭＲ４．７５ｋｂｐｓをサポートする場合には、フェムトシステム１００のときと同様に、パラメータの書換えと、音声データのビットレートの変換を行う。それ以外の場合には、パラメータの書換えと音声データのビットレートの変換を行わない。

なお、ｒｏｕｎｄ−ｔｒｉｐｔｉｍｅの閾値およびｐｉｎｇコマンドの割合の閾値の決定に、ｐｉｎｇコマンド実施時に該ＨＮＢで起動されている呼の種別と呼の数を考慮することが好ましい。多数のＵＥが呼を起動している状態で起こった遅延より、少数のＵＥが呼を起動している状態で起こった遅延のほうが、帯域がより狭いと判断する。また、データ速度が大きい呼が起動されている状態で起こった遅延より、データ速度が小さい呼が起動されている状態で起こった遅延のほうが、帯域がより狭いと判断する。

＜第５の実施の形態＞
本発明の第５の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してＡＭＲフレーム多重化を実行するＡＭＲフレーム多重化機能を備える点と、ＨＮＢ１２０が、ＡＭＲフレーム多重化機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。

ＡＭＲフレーム多重化は、複数のＡＭＲフレームを１つのＲＴＰペイロードに多重化してヘッダサイズを小さくする処理である。

図６〜図８を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がＡＭＲフレーム多重機能をサポートするか否かを判定する処理を説明する。

この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅ）の中で行われる。図６において、ステップＳ３４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅの手順である。

ステップＳ３３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図７は、このメッセージの例を示す。図７に示す例では、最下欄のパラメータ「ＡＭＲｆｒａｍｅｍｕｌｔｉｐｌｅｘｉｎｇｓｕｐｐｏｒｔ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージにも含まれるものである。

本実施の形態において、ＨＮＢ１２０は、自身がＡＭＲフレーム多重機能をサポートするものである場合に、図７に示すように、通常の「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージに対して、ＡＭＲフレーム多重機能をサポートすることを示すパラメータ「ＡＭＲｆｒａｍｅｍｕｌｔｉｐｌｅｘｉｎｇｓｕｐｐｏｒｔ」を追加設定する。

図６に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ＡＭＲｆｒａｍｅｍｕｌｔｉｐｌｅｘｉｎｇｓｕｐｐｏｒｔ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がＡＭＲフレーム多重機能をサポートするか否かを判定する（Ｓ３４）

ＨＮＢ１２０がＡＭＲフレーム多重機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図８の最下欄が示す、ＡＭＲフレーム多重化を指示するパラメータ「ｍａｘｐｔｉｍｅ」を設定する。「ｍａｘｐｔｉｍｅ」は、一つのＲＴＰパケットに含まれる音声データの最大時間長に設定され、「ｍａｘｐｔｉｍｅ」から、一つのＲＴＰペイロードに含まれる音声データフレームの数が決定できる。

以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＡＭＲフレームを、最大、「ｍａｘｐｔｉｍｅ」時間、キューイングを行う。その後、キューイングされているＡＭＲフレームを一つのＲＴＰペイロードとしてＨＮＢ１２０へ送信する。ＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０から受信した一つのＲＴＰペイロードから複数のＡＭＲフレームを生成して、該当するＵＥ１１０に送信する。

また、ＡＭＲフレーム多重機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のＡＭＲフレーム多重化を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信した一つのＲＴＰペイロードから複数のＡＭＲフレームを生成してＭＧＷ１７０に送信する。

なお、ＡＭＲフレーム多重機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ＡＭＲフレーム多重化を実行しない。

このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ＡＭＲフレーム多重機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをＡＭＲフレーム多重化によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。

＜第６の実施の形態＞
本発明の第６の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してＲＴＰパケット多重化を実行するＲＴＰパケット多重機能を備える点と、ＨＮＢ１２０が、ＲＴＰパケット多重機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。

ＲＴＰパケット多重化は、複数のＲＴＰパケットを１つのＵＤＰペイロードに多重化してヘッダサイズを小さくする処理である。

図９〜図１１を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がＲＴＰパケット多重機能をサポートするか否かを判定する処理を説明する。

この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅ）の中で行われる。図９において、ステップＳ４４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅの手順である。

ステップＳ４３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図１０は、このメッセージの例を示す。図１０に示す例では、最下欄のパラメータ「ＤＬＭｕｘＰｏｒｔＮｕｍｂｅｒ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージにも含まれるものである。

本実施の形態において、ＨＮＢ１２０は、自身がＲＴＰパケット多重機能をサポートするものである場合に、図１０に示すように、通常の「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージに対して、ＲＴＰパケット多重機能をサポートすることを示すパラメータ「ＤＬＭｕｘＰｏｒｔＮｕｍｂｅｒ」を追加する。パラメータ「ＤＬＭｕｘＰｏｒｔＮｕｍｂｅｒ」は、ＲＴＰパケット多重化を使用した場合にＨＮＢ１２０が受け取るＵＤＰｐｏｒｔの番号に設定される。

図９に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ＤＬＭｕｘＰｏｒｔＮｕｍｂｅｒ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がＲＴＰパケット多重機能をサポートするか否かを判定する（Ｓ４４）

ＨＮＢ１２０がＲＴＰパケット多重機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図１１の最下２つの欄に示す、ＲＴＰパケット多重化を指示するパラメータ「ＵＬＭｕｘＰｏｒｔＮｕｍｂｅｒ」と「ＬｅｎｇｔｈＩｎｄｉｃａｔｏｒ」を設定する。「ＵＬＭｕｘＰｏｒｔＮｕｍｂｅｒ」は、ＲＴＰパケット多重を使用した場合にＨＮＢ−ＧＷ１４０が受け取るＵＤＰｐｏｒｔ番号に設定される。「ＬｅｎｇｔｈＩｎｄｉｃａｔｏｒ」は、一つのＲＴＰパケットの最大データ長に設定され、"ＬｅｎｇｔｈＩｎｄｉｃａｔｏｒ"から、一つのＵＤＰペイロードに含まれるＲＴＰパケットの数が決定できる。

以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＲＴＰパケットを、最大、「ＬｅｎｇｔｈＩｎｄｉｃａｔｏｒ」から決定されるサイズのキューイングを行う。その後、キューイングされているＲＴＰパケットを一つのＵＤＰペイロードとしてＨＮＢ１２０へ送信する。ＨＮＢ１２０は、ＨＮＢ１４０から受信した一つのＵＤＰペイロードから、複数のＲＴＰパケットを生成して、該当するＵＥ１１０に送信する。

また、ＲＴＰパケット多重機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のＲＴＰパケット多重化を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信した一つのＵＤＰペイロードから複数のＲＴＰパケットを生成してＭＧＷ１７０に送信する。

なお、ＲＴＰパケット多重機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ＲＴＰパケット多重化を実行しない。

このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ＲＴＰパケット多重機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをＲＴＰパケット多重化によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。

＜第７の実施の形態＞
本発明の第７の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してＵＤＰパケット多重化を実行するＵＤＰパケット多重機能を備える点と、ＨＮＢ１２０が、ＵＤＰパケット多重機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。

ＵＤＰパケット多重化は、複数のＵＤＰパケットを１つのＩＰペイロードに多重化してヘッダサイズを小さくする処理である。

図１２〜図１４を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がＵＤＰパケット多重機能をサポートするか否かを判定する処理を説明する。

この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅ）の中で行われる。図１２において、ステップＳ５４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅの手順である。

ステップＳ５３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図１３は、このメッセージの例を示す。図１３に示す例では、最下欄のパラメータ「ＵＤＰｐａｃｋｅｔｍｕｌｔｉｐｌｅｘｉｎｇｓｕｐｐｏｒｔ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージにも含まれるものである。

本実施の形態において、ＨＮＢ１２０は、自身がＵＤＰパケット多重機能をサポートするものである場合に、図１３に示すように、通常の「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージに対して、ＵＤＰパケット多重機能をサポートすることを示すパラメータ「ＵＤＰｐａｃｋｅｔｍｕｌｔｉｐｌｅｘｉｎｇｓｕｐｐｏｒｔ」を追加する。

図１２に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ＵＤＰｐａｃｋｅｔｍｕｌｔｉｐｌｅｘｉｎｇｓｕｐｐｏｒｔ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がＵＤＰパケット多重機能をサポートするか否かを判定する（Ｓ５４）。

ＨＮＢ１２０がＵＤＰパケット多重機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図１４の最下欄に示す、ＵＤＰパケット多重化を指示するパラメータ「ＭａｘｉｍｕｍＭｅｓｓａｇｅＳｉｚｅ」を設定する。パラメータ「ＭａｘｉｍｕｍＭｅｓｓａｇｅＳｉｚｅ」には、一つのＩＰペイロードの最大データ長に設定され、「ＭａｘｉｍｕｍＭｅｓｓａｇｅＳｉｚｅ」から、一つのＩＰペイロードに含まれる音声データフレームの数が決定できる。

以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＵＤＰパケットを、最大、「ＭａｘｉｍｕｍＭｅｓｓａｇｅＳｉｚｅ」から決定されるサイズのキューイングを行う。その後、キューイングされているＵＤＰパケットを一つのＩＰペイロードとしてＨＮＢ１２０へ送信する。

また、ＵＤＰパケット多重機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のＵＤＰパケット多重化を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信した一つのＩＰペイロードから複数のＵＤＰパケットを生成してＭＧＷ１７０に送信する。

なお、ＵＤＰパケット多重機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ＵＤＰパケット多重化を実行しない。

このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ＵＤＰパケット多重機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをＵＤＰパケット多重化によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。

＜第８の実施の形態＞
本発明の第８の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してｄｅｆｌａｔｅ圧縮／解凍を実行するｄｅｆｌａｔｅ機能を備える点と、ＨＮＢ１２０が、ｄｅｆｌａｔｅ機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。

ｄｅｆｌａｔｅ機能とは、ｄｅｆｌａｔｅ方式でデータを圧縮する処理（ｄｅｆｌａｔｅ圧縮）と、ｄｅｆｌａｔｅ方式で圧縮されたデータを解凍する処理（ｄｅｆｌａｔｅ解凍）であり、これにより、ＩＰペイロード自体を圧縮することができる。

図１５〜図１７を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がｄｅｆｌａｔｅ機能をサポートするか否かを判定する処理を説明する。

この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅ）の中で行われる。図１５において、ステップＳ６４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢＲｅｇｉｓｔｒａｔｉｏｎｐｒｏｃｅｄｕｒｅの手順である。

ステップＳ６３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図１６は、このメッセージの例を示す。図１６に示す例では、最下欄のパラメータ「ｄｅｆｌａｔｅｓｕｐｐｏｒｔ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージにも含まれるものである。

本実施の形態において、ＨＮＢ１２０は、自身がｄｅｆｌａｔｅ機能をサポートするものである場合に、図１６に示すように、通常の「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージに対して、ｄｅｆｌａｔｅ機能をサポートすることを示すパラメータ「ｄｅｆｌａｔｅｓｕｐｐｏｒｔ」を追加する。

図１５に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ｄｅｆｌａｔｅｓｕｐｐｏｒｔ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がｄｅｆｌａｔｅ機能をサポートするか否かを判定する（Ｓ６４）。

ＨＮＢ１２０がｄｅｆｌａｔｅ機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢＲＥＧＩＳＴＥＲＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図１７の最下欄に示す、ｄｅｆｌａｔｅを指示するパラメータ「ｄｅｆｌａｔｅ」を設定する。

以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＩＰペイロードに対してｄｅｆｌａｔｅ圧縮を行ってからＨＮＢ１２０へ送信する。

また、ｄｅｆｌａｔｅ機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のｄｅｆｌａｔｅ圧縮を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信したＩＰペイロードに対してｄｅｆｌａｔｅ解凍を行ってＭＧＷ１７０に送信する。

なお、ｄｅｆｌａｔｅ機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ｄｅｆｌａｔｅ化を実行しない。

このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ｄｅｆｌａｔｅ機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをｄｅｆｌａｔｅ圧縮によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。

以上、実施の形態をもとに本発明を説明した。実施の形態は例示であり、本発明の主旨から逸脱しない限り、上述各実施の形態に対して、さまざまな変更、増減、組合せを加えてもよい。これらの変更、増減、組合せが加えられた変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）でも同様に、ＨｅＮＢやＨｅＮＢ−ＧＷに本発明の技術を適用できる。また、多重化情報、ポート情報の通知には、上述した各実施の形態に用いられたＨＮＢＡＰ、ＵＲＡ、ＲＡＮＡＰ以外のプロトコルを用いてもよい。

この出願は、２００９年１２月１０日に出願された日本出願特願２００９−２８０１５４を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、メディアゲートウェイとフェムトセルとの間における音声データの中継に適用することができる。

１０フェムトシステム
２０ＵＥ
３０ＨＮＢ
４０ネットワーク
５０ＨＮＢ−ＧＷ
５２ＭＧＷ
５４ＭＳＣ
１００フェムトシステム
１１０ＵＥ
１２０ＨＮＢ
１３０ネットワーク
１４０ＨＮＢ−ＧＷ
１５０狭帯域判定部
１６０変換部
１７０ＭＧＷ
１８０ＭＳＣ

Claims

ネットワークを介してフェムトセルと接続され、メディアゲートウェイと前記フェムトセル間における音声データの送受信を中継するゲートウェイ装置であって、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定手段と、
前記狭帯域判定手段により狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する変換手段とを備えることを特徴とするゲートウェイ装置。
前記変換手段は、さらに、前記フェムトセルに接続された端末装置がサポートしうるビットレートを確認し、
前記音声データを変換する際に、そのビットレートを、前記端末装置がサポートしうるビットレートに下げることを特徴とする請求項１に記載のゲートウェイ装置。
前記変換手段は、さらに、前記狭帯域判定手段により狭帯域である判定がなされたときに、前記フェムトセルから前記メディアゲートウェイに転送する音声データのビットレートを上げるように前記音声データを変換することを特徴とする請求項１または２に記載のゲートウェイ装置。
前記変換手段は、前記フェムトセルに転送する音声データを変換する際に、さらに、前記フェムトセルが対応可能な多重化方式で多重化を行うことを特徴とする請求項１から３のいずれか１項に記載のゲートウェイ装置。
前記多重化方式は、複数のフレームを１つのＲＴＰペイロードに多重化するフレーム多重と、複数のＲＴＰパケットを１つのＵＤＰペイロードに多重化するＲＴＰパケット多重と、複数のＵＤＰパケットを１つのＩＰペイロードに多重化するｄｅｆｌａｔｅのうちのいずれか１つであることを特徴とする請求項４に記載のゲートウェイ装置。
前記変換手段は、デフレートに対応するフェムトセルに転送する音声データを変換する際に、さらに、デフレートで圧縮を行うことを特徴とする請求項１から５のいずれか１項に記載のゲートウェイ装置。
ネットワークを介してメディアゲートウェイと音声データの送受信を行うフェムトセルと、前記メディアゲートウェイとの間における音声データの送受信を中継する際に、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定し、
狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換することを特徴とする中継方法。
ネットワークを介してメディアゲートウェイと音声データの送受信を行うフェムトセルと、前記メディアゲートウェイとの間における音声データの送受信を中継する際に、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定し、
狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する処理をコンピュータに実行せしめるプログラムを格納した非一時的なコンピュータ可読媒体。
メディアゲートウェイと、
フェムトセルと、
ネットワークを介して前記フェムトセルと接続され、前記メディアゲートウェイと前記フェムトセル間における音声データの送受信を中継するゲートウェイ装置とを有し、
前記ゲートウェイ装置は、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定手段と、
前記狭帯域判定手段により狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する変換手段とを備えることを特徴とするフェムトシステム。