(57)【要約】  ＨＮＢ−ＧＷとＨＮＢ間の帯域不足に起因する音質劣化を回避するために、フェムトシステム１００において、ＨＮＢ−ＧＷ１４０は、ネットワーク１３０を介してＨＮＢ１２０と接続され、ＭＧＷ１７０とＨＮＢ１２０間における音声データの送受信を中継する。ＨＮＢ−ＧＷ１４０における狭帯域判定部１５０は、ネットワーク１３０の帯域が所定の閾値以下となる狭帯域であるか否かを判定する。変換部１６０は、狭帯域判定部１５０により狭帯域である判定がなされたときに、ＭＧＷ１７０からＨＮＢ１２０に転送する音声データのビットレートを下げるように音声データを変換する。
2011070740.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してフェムトセルと接続され、メディアゲートウェイと前記フェムトセル間における音声データの送受信を中継するゲートウェイ装置であって、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定手段と、
前記狭帯域判定手段により狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する変換手段とを備えることを特徴とするゲートウェイ装置。
【請求項２】
前記変換手段は、さらに、前記フェムトセルに接続された端末装置がサポートしうるビットレートを確認し、
前記音声データを変換する際に、そのビットレートを、前記端末装置がサポートしうるビットレートに下げることを特徴とする請求項１に記載のゲートウェイ装置。
【請求項３】
前記変換手段は、さらに、前記狭帯域判定手段により狭帯域である判定がなされたときに、前記フェムトセルから前記メディアゲートウェイに転送する音声データのビットレートを上げるように前記音声データを変換することを特徴とする請求項１または２に記載のゲートウェイ装置。
【請求項４】
前記変換手段は、前記フェムトセルに転送する音声データを変換する際に、さらに、前記フェムトセルが対応可能な多重化方式で多重化を行うことを特徴とする請求項１から３のいずれか１項に記載のゲートウェイ装置。
【請求項５】
前記多重化方式は、複数のフレームを１つのＲＴＰペイロードに多重化するフレーム多重と、複数のＲＴＰパケットを１つのＵＤＰペイロードに多重化するＲＴＰパケット多重と、複数のＵＤＰパケットを１つのＩＰペイロードに多重化するｄｅｆｌａｔｅのうちのいずれか１つであることを特徴とする請求項４に記載のゲートウェイ装置。
【請求項６】
前記変換手段は、デフレートに対応するフェムトセルに転送する音声データを変換する際に、さらに、デフレートで圧縮を行うことを特徴とする請求項１から５のいずれか１項に記載のゲートウェイ装置。
【請求項７】
ネットワークを介してメディアゲートウェイと音声データの送受信を行うフェムトセルと、前記メディアゲートウェイとの間における音声データの送受信を中継する際に、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定し、
狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換することを特徴とする中継方法。
【請求項８】
ネットワークを介してメディアゲートウェイと音声データの送受信を行うフェムトセルと、前記メディアゲートウェイとの間における音声データの送受信を中継する際に、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定し、
狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する処理をコンピュータに実行せしめるプログラムを格納した非一時的なコンピュータ可読媒体。
【請求項９】
メディアゲートウェイと、
フェムトセルと、
ネットワークを介して前記フェムトセルと接続され、前記メディアゲートウェイと前記フェムトセル間における音声データの送受信を中継するゲートウェイ装置とを有し、
前記ゲートウェイ装置は、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定手段と、
前記狭帯域判定手段により狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する変換手段とを備えることを特徴とするフェムトシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、中継技術、具体的にはメディアゲートウェイとフェムトセルとの間における音声データの中継技術に関する。
【背景技術】
【０００２】
半径数百メートルから十数キロメールの通話エリアを持つ従来の携帯電話基地局同士の境界領域やビルの奥、地下などでは、電波強度が微弱であるため、これらの場所では上記基地局に接続できない問題が発生する。この問題を解決するために、通話エリアが半径数十メートル程度の小型基地局を設置し、上記場所でも通話可能としたサービスが提供されている。このような小型基地局は、フェムトセルと呼ばれている。以下の説明において、フェムトセルが設けられたシステムをフェムトシステムという。【０００３】
図１８は、フェムトシステムの例を示す。このフェムトシステム１０は、フェムトセル３０と、ゲートウェイ装置５０と、メディアゲートウェイ５２と、回線交換機５４を備える。なお、メディアゲートウェイ５２は、回線交換機５４に含まれる場合もあるが、分かりやすいように、メディアゲートウェイ５２と回線交換機５４を分けて図示および説明をする。【０００４】
なお、以下の説明において、フェムトセル、ゲートウェイ装置、メディアゲートウェイ、回線交換機をそれぞれＨＮＢ（Ｈｏｍｅ  Ｎｏｄｅ  Ｂ）、ＨＮＢ−ＧＷ（Ｈｏｍｅ  Ｎｏｄｅ  Ｂ  Ｇａｔｅｗａｙ）、ＭＧＷ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ）、ＭＳＣ（Ｍｏｂｉｌｅ−ｓｅｒｖｉｃｅ  Ｓｗｉｔｃｈｉｎｇ  Ｃｅｎｔｅｒ）という。また、ＨＮＢ３０に接続する各端末装置２０をＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）という。【０００５】
ゲートウェイ装置５０は、ＭＧＷ５２とＨＮＢ３０間における音声データの送受信の中継を行うものであり、ネットワーク４０を介してＨＮＢ３０と接続される。通話の音声データは、ＭＧＷ５２、ＨＮＢ−ＧＷ５０、ネットワーク４０、ＨＮＢ３０の順にＵＥ２０に送信され、または、ＨＮＢ３０、ネットワーク４０、ＨＮＢ−ＧＷ５０、ＭＧＷ５２の順にＵＥ２０から送信される。また、非特許文献６と非特許文献１に記載れたように、「Ｔｈｅ  ＲＵＡ  ｈａｓ  ｔｈｅ  ｆｏｌｌｏｗｉｎｇ  ｆｕｎｃｔｉｏｎｓ：Ｔｒａｎｓｐａｒｅｎｔ  ｔｒａｎｓｆｅｒ  ｏｆ  ＲＡＮＡＰ  ｍｅｓｓａｇｅｓ」、「Ｉｕ  ＵＰ  ｉｓ  ｔｅｒｍｉｎａｔｅｄ  ｉｎ  ＣＮ  ａｎｄ  ＨＮＢ（ｉ．ｅ．ｎｏｔ  ｉｎ  ｔｈｅ  ＨＮＢ  ＧＷ）、すなわちＨＮＢ−ＧＷ５０では、ＲＡＮＡＰ、および、Ｉｕ−ＵＰより上位のデータを透過転送することになっており、ＭＳＣ５４／ＭＧＷ５２、ＨＮＢ３０、ＵＥ２０は、同一のコーデックが使用されるようになっている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】３ＧＰＰ  ＴＳ  ２５．４６７  ＵＴＲＡＮ  ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  ３Ｇ Ｈｏｍｅ  Ｎｏｄｅ  Ｂ（Ｖ８．３．０）
【非特許文献２】３ＧＰＰ  ＴＳ  ２５．４６９  ＵＴＲＡＮ  Ｉｕｈ  ｉｎｔｅｒｆａｃｅ  Ｈｏｍｅ  Ｎｏｄｅ  Ｂ  ＡｐｐｌｉｃａｔｉｏｎＰａｒｔ（Ｖ８．３．０）
【非特許文献３】３ＧＰＰ  ＴＳ  ２４．００８  Ｃｏｒｅ  ｎｅｔｗｏｒｋ  ｐｒｏｔｏｃｏｌｓ（Ｖ８．７．０）
【非特許文献４】３ＧＰＰ  ＴＳ  ２５．４１３  ＵＴＲＡＮ  Ｉｕ  ｉｎｔｅｒｆａｃｅ  ＲＡＮＡＰ  ｓｉｇｎａｌｌｉｎｇ（Ｖ８．４．０）
【非特許文献５】ＲＦＣ  １８８９  ＲＴＰ
【非特許文献６】３ＧＰＰ  ＴＳ  ２５．４６８  ＵＴＲＡＮ  Ｉｕｈ  ＩｎｔｅｒｆａｃｅＲＡＮＡＰ  Ｕｓｅｒ  Ａｄａｐｔａｔｉｏｎ  ｓｉｇｎａｌｌｉｎｇ
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、ＨＮＢ３０とＨＮＢ−ＧＷ５０を接続するネットワーク４０は、通常、インターネット（登録商標）やイントラネットなどの汎用回線である。この汎用回線の帯域が狭い場合には、帯域不足に起因して音質の劣化が生じうる。【０００８】
一方、ネットワーク４０として帯域の広い回線例えば衛星回線を使用してフェムトシステムを構築すればＨＮＢ−ＧＷ５０とＨＮＢ３０間の帯域不足の問題を解消することが考えられるが、ＨＮＢ−ＧＷ５０とＨＮＢ３０のいずれも衛星回線に対応する必要があり、高価となるため、フェムトシステムの普及が困難になる。【０００９】
本発明は、上記事情に鑑みてなされたものであり、フェムトシステムにおいて、ＨＮＢ−ＧＷとＨＮＢを接続するネットワークの帯域が狭くても音質の劣化を回避できる技術を提供する。
【課題を解決するための手段】
【００１０】
本発明の１つの態様は、ネットワークを介してフェムトセルと接続され、メディアゲートウェイとフェムトセル間における音声データの送受信を中継するゲートウェイ装置である。このゲートウェイ装置は、上記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定部と、該狭帯域判定部により狭帯域である判定がなされたときに、メディアゲートウェイからフェムトセルに転送する音声データのビットレートを下げるように音声データを変換する変換部を備える。【００１１】
なお、上記態様のゲートウェイ装置を方法やシステムに置換えて表現したもの、該ゲートウェイ装置を備えたシステム、コンピュータを該ゲートウェイ装置として動作せしめるプログラム、該プログラムを記録した記録媒体なども、本発明の態様としては有効である。
【発明の効果】
【００１２】
本発明にかかる技術によれば、フェムトシステムにおいて、ＨＮＢ−ＧＷとＨＮＢを接続するネットワークの帯域が狭くても音質の劣化を回避できる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施の形態にかかるフェムトシステムを示す図である。
【図２】図１に示すフェムトシステムにおいてＨＮＢが使用する帯域が狭帯域であるか否かを判定する処理を示すフローチャートである。
【図３】図１に示すフェムトシステムにおけるＡＭＲ起動の手順を示す図である。
【図４】本発明の第２の実施の形態にかかるフェムトシステムにおいてが使用する帯域が狭帯域であるか否かを判定する処理を示すフローチャートである。
【図５】本発明の第２の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージの例を示す図である。
【図６】本発明の第５の実施の形態のフェムトシステムにおいてＨＮＢがＡＭＲフレーム多重化をサポートするか否かを判定する処理を示すフローチャートである。
【図７】本発明の第５の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージの例を示す図である。
【図８】本発明の第５の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの例を示す図である。
【図９】本発明の第６の実施の形態のフェムトシステムにおいてＨＮＢがＲＴＰパケット多重化をサポートするか否かを判定する処理を示すフローチャートである。
【図１０】本発明の第６の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージの例を示す図である。
【図１１】本発明の第６の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの例を示す図である。
【図１２】本発明の第７の実施の形態のフェムトシステムにおいてＨＮＢがＵＤＰパケット多重化をサポートするか否かを判定する処理を示すフローチャートである。
【図１３】本発明の第７の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージの例を示す図である。
【図１４】本発明の第７の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの例を示す図である。
【図１５】本発明の第８の実施の形態のフェムトシステムにおいてＨＮＢがｄｅｆｌａｔｅをサポートするか否かを判定する処理を示すフローチャートである。
【図１６】本発明の第８の実施の形態のフェムトシステムにおいてＨＮＢが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージの例を示す図である。
【図１７】本発明の第８の実施の形態のフェムトシステムにおいてＨＮＢ−ＧＷが送信する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの例を示す図である。
【図１８】従来のフェムトシステムを説明するための図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照しながら、本発明にかかる実施の形態を説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡略化がなされている。また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ  ｓｔｏｒａｇｅ  ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【００１５】
＜第１の実施の形態＞
図１は、本発明の第１の実施の形態にかかるフェムトシステム１００を示す。フェムトシステム１００は、３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で定められた仕様に準拠するものであり、フェムトセル（ＨＮＢ）１２０と、ゲートウェイ装置（ＨＮＢ−ＧＷ）１４０と、メディアゲートウェイ（ＭＧＷ）１７０と、回線交換機（ＭＳＣ）１８０を備える。ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０とＨＮＢ１２０間における音声データの送受信を中継するものであり、インターネットなどのネットワーク１３０を介してＨＮＢ１２０と接続されている。ＨＮＢ−ＧＷ１４０は、狭帯域判定部１５０と変換部１６０を有する。
【００１６】
各端末（ＵＥ）１１０は、ＨＮＢ１２０に接続して通話を行う。通話の音声データは、ＭＧＷ１７０、ＨＮＢ−ＧＷ１４０、ネットワーク１３０、ＨＮＢ１２０の順にＵＥ１１０に送信され、ＨＮＢ１２０、ネットワーク１３０、ＨＮＢ−ＧＷ１４０、ＭＧＷ１７０の順にＵＥ１１０から送信される。
【００１７】
フェムトシステム１００は、ＨＮＢ−ＧＷ１４０を除いて、通常のこの種のシステムと同様である。そのため、ＨＮＢ−ＧＷ１４０についてのみ詳細に説明する。また、ＨＮＢ−ＧＷ１４０は、狭帯域判定部１５０と変換部１６０を備える点以外、通常のＨＮＢ−ＧＷと同様の構成と機能を有するため、ＨＮＢ−ＧＷ１４０については、狭帯域判定部１５０と変換部１６０についてのみ詳細に説明する。
【００１８】
狭帯域判定部１５０は、ネットワーク１３０の帯域が狭帯域であるか否かを判定し、判定結果を変換部１６０に出力する。具体的には、ネットワーク１３０の帯域が所定の閾値例えば２００ｋｂｐｓ以下であれば狭帯域と判定し、ネットワーク１３０の帯域が閾値より広ければ狭帯域ではないと判定する。
【００１９】
本実施の形態において、狭帯域判定部１５０は、ＨＮＢ１２０の設置場所に基づいて狭帯域か否かの判定を行う。狭帯域判定部１５０には、狭帯域の位置を示す狭帯域位置情報が予めデータベースに登録されている。この狭帯域位置情報は、例えば非特許文献２に記載された、３ＧＰＰで定められているパラメータ（ＨＮＢ  Ｌｏｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ）、ＬＡＣ（Ｌｏｃａｔｉｏｎ  Ａｒｅａ  Ｃｏｄｅ）、ＲＡＣ（Ｒｏｕｔｉｎｇ  Ａｒｅａ  Ｃｏｄｅ）、ＳＡＣ（Ｓｅｒｖｉｃｅ  Ａｒｅａ  Ｃｏｄｅ）のうちの１つまたは複数の組合せである。
【００２０】
狭帯域判定部１５０は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅ）の中でネットワーク１３０の帯域が狭帯域か否かの判定をする。図２を参照して説明する。
【００２１】
図２において、ステップＳ１は、狭帯域位置情報が予めＨＮＢ−ＧＷ１４０に登録される手順であり、ステップＳ２〜６は、ＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅに含まれる処理である。ステップＳ５を除き、ステップＳ２〜６のうちの他の各ステップは、通常のフェムトシステムにおけるＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅの手順である。
【００２２】
ステップＳ４で、ＨＮＢ１２０は、「ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。このメッセージの中に、前述したパラメータ「ＨＮＢ  Ｌｏｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ」、「ＬＡＣ」、「ＲＡＣ」、「ＳＡＣ」が含まれている。これらのパラメータは、ＨＮＢ１２０の設置場所を示しうる情報である。
【００２３】
ＨＮＢ−ＧＷ１４０における狭帯域判定部１５０は、ステップＳ５で、「ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージに含まれる上述のパラメータを、ＨＮＢ１２０の設置場所を示す情報として取得して、予め登録された狭帯域位置情報と照合する。ＨＮＢ１２０の設置場所が、狭帯域位置情報が示す位置のいずれかと一致する場合には、ネットワーク１３０の帯域が狭帯域であると判定する。一方、ＨＮＢ１２０の設置場所が、狭帯域位置情報が示す位置のいずれとも一致しない場合には、ネットワーク１３０の帯域が狭帯域ではないと判定する。
【００２４】
ＨＮＢ−ＧＷ１４０における変換部１６０は、狭帯域判定部１５０により狭帯域である判定がなされたときに、ＭＧＷ１７０からの音声データのビットレートを低いビットレートに変換してＨＮＢ１２０に転送する。なお、変換に際して、ＨＮＢ１２０に接続されたＵＥ１１０がサポートするビットレートを確認し、ＵＥ１１０がサポートする低いビットレートに音声データを変換する。フェムトシステムにおいて、音声データは、符号化されて伝送される。本実施の形態においては、音声データは、ＡＭＲ（Ａｄａｐｔｉｖｅ  Ｍｕｌｔｉ−Ｒａｔｅ：適応多重レート）と呼ばれるコーデック方式で符号化されて伝送されているとする。ここで、ＭＧＷ１７０からの音声データが音声通信システムに広く用いられるＡＭＲ１２．２ｋｂｐｓのものであるとする。また、例として、本実施の形態において、変換部１６０は、低いビットレートとしてＡＭＲのうちの最も低いＡＭＲ４．７５ｋｂｐｓを用い、狭帯域判定部１５０により狭帯域である判定がなされ、かつＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートする場合において、ＭＧＷ１７０からの音声データをＡＭＲ１２．２ｋｂｐｓからＡＭＲ４．７５ｋｂｐｓに変換する。
【００２５】
フェムトシステムにおいて、ＵＥとＭＧＷ間の音声データの転送に先立って、「ＡＭＲ起動」と呼ばれる処理が行われる。この処理は、当該ＵＥと、ＨＮＢ、ＭＳＣ間でＡＭＲに関する情報を交換し、ＡＭＲビットレートの取り決めなどを行う。なお、ＡＭＲ起動は、ＵＥへの発呼があった際と、ＵＥからの発呼があった際に行われ、ＡＭＲ起動後は、通話に伴う音声データの転送がなされる。
【００２６】
ＵＥからの発呼によるＡＭＲ起動の場合、ＮＡＳ  Ｐｒｏｃｅｄｕｒｅの中でＵＥからＨＮＢ−ＧＷにＣＣ（Ｃａｌｌ  Ｃｏｎｔｒｏｌ）のためのＳＥＴＵＰメッセージが発信される。ＵＥへの発呼によるＡＭＲ起動の場合、ＮＡＳ  Ｐｒｏｃｅｄｕｒｅの中でＵＥからＨＮＢ−ＧＷにＣＣのためのＣＡＬＬ  ＣＯＮＦＩＲＭメッセージが発信される。通常のフェムトシステムにおいて、これらのメッセージは、ＨＮＢ−ＧＷによりＭＳＣに転送される。本実施の形態のフェムトシステム１００では、ＨＮＢ−ＧＷ１４０において、上記転送に加え、さらに変換部１６０による該メッセージに基づいたＵＥ１１０のＡＭＲ能力の確認が行われる。ＵＥ１１０のＡＭＲ能力とは、ＵＥ１１０がサポートするＡＭＲビットレートを意味する。上記ＳＥＴＵＰメッセージおよびＣＡＬＬ  ＣＯＮＦＩＲＭメッセージには、パラメータ「Ｓｕｐｐｏｒｔｅｄ  Ｃｏｄｅｃ  Ｌｉｓｔ」が含まれており、該パラメータを参照して、ＵＥ１１０がサポートするＡＭＲビットレートを確認することができる。本実施の形態において、変換部１６０は、上記パラメータから、ＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートするか否かを確認する。以降、変換部１６０は、この確認の結果をＵＥ１１０と対応付けて保持する。以下の説明において、変換部１６０が既にＵＥ１１０のＡＭＲ能力を把握したとする。
【００２７】
図３を参照して、ネットワーク１３０の帯域が狭帯域であり、かつ発呼された、または発呼したＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートする場合、フェムトシステム１００におけるＡＭＲ起動の処理を説明する。
【００２８】
ＵＥ１１０への発呼、またはＵＥ１１０からの発呼があると、まず、ＵＥ１１０、ＨＮＢ１２０、ＨＮＢ−ＧＷ１４０、ＭＳＣ１８０間でＮＡＳ  Ｐｒｏｃｅｄｕｒｅが行われる（Ｓ１１）。そして、ＭＳＣ１８０からＨＮＢ−ＧＷ１４０に「ＲＡＮＡＰ：ＲＡＢ  ＡＳＳＩＧＮＭＥＮＴ  ＲＥＱＵＥＳＴ」メッセージが送信される（Ｓ１２）。このメッセージは、非特許文献４の９．１．３章に定められるパラメータ「ＲＡＢＰａｒａｍｅｔｅｒｓ」が含まれている。このパラメータは、ＵＥ１１０に送信する音声データのＡＭＲビットレートを示すものであり、本実施の形態では、１２．２ｋｂｐｓに対応する値が設定される。このステップは、通常のフェムトシステムにおいて行われる手順である。
【００２９】
次に、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に「ＲＡＮＡＰ：ＲＡＢ  ＡＳＳＩＧＮＭＥＮＴ  ＲＥＱＵＥＳＴ」メッセージを転送する。通常のフェムトシステムにおいて、この「ＲＡＮＡＰ：ＲＡＢ  ＡＳＳＩＧＮＭＥＮＴ  ＲＥＱＵＥＳＴ」メッセージはそのままＨＮＢ１２０に転送されるが、本実施の形態において、ネットワーク１３０が狭帯域である判定がなされ、かつＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートする場合に、ＨＮＢ−ＧＷ１４０における変換部１６０は、該メッセージに含まれるパラメータ「ＲＡＢＰａｒａｍｅｔｅｒｓ」の値をＡＭＲ４．７５ｋｂｐｓに対応する値に書き換えてＨＮＢ１２０に送信する（Ｓ１３、Ｓ１４）。
【００３０】
これにより、ＵＥ１１０とＨＮＢ１２０間でＡＭＲ４．７５ｋｂｐｓでＲＢ（Ｒａｄｉｏ  Ｂｅａｒｅｒ）が確立される（Ｓ１５）。
【００３１】
ＲＢの確立後に、ステップＳ１６を経て、ＨＮＢ−ＧＷ１４０により、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＲＡＢ  ＡＳＳＩＧＮＭＥＮＴ  ＲＥＳＰＯＮＳＥ」メッセージが転送される。このメッセージは、非特許文献４の９．１．４章に定められるパラメータＡｓｓｉｇｎｅｄＲＡＢ  Ｐａｒａｍｅｔｅｒ  Ｖａｌｕｅｓ」が含まれている。ここで、ＨＮＢ１２０からのメッセージに含まれるこのパラメータは、ＡＭＲ４．７５ｋｂｐｓに対応する値になっている。
【００３２】
通常のフェムトシステムにおいて、このメッセージはそのままＭＳＣ１８０に転送されるが、本実施の形態において、ＨＮＢ−ＧＷ１４０は、該メッセージをＭＳＣ１８０に転送する際に、メッセージに含まれるパラメータ「ＡｓｓｉｇｎｅｄＲＡＢ  Ｐａｒａｍｅｔｅｒ  Ｖａｌｕｅｓ」の値をＡＭＲ４．７５ｋｂｐｓに対応する値からＡＭＲ１２．２ｋｂｐｓに書き換えてＭＳＣ１８０に送信する（Ｓ１７、Ｓ１８）。
【００３３】
これにて、ＡＭＲ起動が完了する。
以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０とＵＥ１１０間での音声データの送受信を中継する（Ｓ１９〜）。中継に際して、変換部１６０により、音声データのビットレートの変換を行う。具体的には、ＭＧＷ１７０からの音声データをＵＥ１１０に転送する際に、変換部１６０は、まず、ＭＧＷ１７０から受信したＡＭＲ１２．２ｋｂｐｓの音声データをＰＣＭ（Ｐｕｌｓｅ  Ｃｏｄｅ  Ｍｏｄｕｌａｔｉｏｎ）の音声データに変換する。そして、ＰＣＭ音声データをＡＭＲ４．７５ｋｂｐｓの音声データに変換して該ＵＥ１１０に送信する。また、ＵＥ１１０からの音声データをＭＧＷ１７０に転送する際には、変換部１６０は、該ＵＥ１１０から受信したＡＭＲ４．７５ｋｂｐｓの音声データをＰＣＭデータに変換し、そしてＰＣＭデータをＡＭＲ１２．２ｋｂｐｓの音声データに変換してＭＧＷ１７０に送信する。
【００３４】
ＡＭＲの音声データからＰＣＭの音声データへの変換、及びＰＣＭの音声データからＡＭＲの音声データへの変換については、従来からよく知られているため、ここで詳細な説明を省略する。
【００３５】
このように、本実施の形態のフェムトシステム１００のＨＮＢ−ＧＷ１４０は、ネットワーク１３０の帯域が狭帯域であり、かつＵＥ１１０が低いＡＭＲビットレートをサポートする場合において、ＡＭＲ起動中に、ＭＳＣ１８０からの「ＲＡＮＡＰ：ＲＡＢ  ＡＳＳＩＧＮＭＥＮＴ  ＲＥＱＵＥＳＴ」メッセージをＨＮＢ１２０に転送する際に、該メッセージに含まれるパラメータ「ＲＡＢＰａｒａｍｅｔｅｒｓ」の値をＵＥ１１０のサポートする低いビットレートに対応する値に書き換え、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＲＡＢ  ＡＳＳＩＧＮＭＥＮＴ  ＲＥＳＰＯＮＳＥ」メッセージに含まれるパラメータ「ＡｓｓｉｇｎｅｄＲＡＢ  Ｐａｒａｍｅｔｅｒ  Ｖａｌｕｅｓ」の値をＭＳＣ１８０のＡＭＲビットレートに書き換える。その後、このＵＥ１１０とＭＧＷ１７０間で音声データを転送する際に、ＭＧＷ１７０から受信した音声データのビットレートを下げてＵＥ１１０に転送し、ＵＥ１１０から受信した音声データのビットレートを上げてＭＧＷ１７０に転送する。こうすることにより、ネットワーク１３０の帯域が狭帯域であっても、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０間で送受信される音声データのビットレートが低いため、帯域不足に起因する音声劣化を回避することができる。また、従来のフェムトシステムと比べ、ＨＮＢ−ＧＷのみが異なり、ＵＥや、ＭＧＷ、ＭＳＣについでは、従来と同様のものを用いることができる。
【００３６】
以下、本発明にかかる他の実施の形態について説明する。これらの実施の形態のいずれもフェムトシステムであり、基本的な構成は、フェムトシステム１００と同様である。そのため、これらの実施の形態の説明に際して、フェムトシステム１００と異なる点についてのみ説明し、機能ブロックについては、フェムトシステム１００のものと同様の名称と符号を用いる。
【００３７】
＜第２の実施の形態＞
本発明にかかる第２の実施の形態のフェムトシステムは、ＨＮＢ１２０が、自身が使用する帯域（すなわちネットワーク１３０の帯域）を測定してＨＮＢ−ＧＷ１４０に報告し、ＨＮＢ−ＧＷ１４０がＨＮＢ１２０からの報告に基づいてネットワーク１３０の帯域が狭帯域であるか否かを判定する点においてのみ、フェムトシステム１００と異なる。図４と図５を参照して説明する。
【００３８】
図４に示すように、ＨＮＢ１２０は、初期化（ＨＮＢ  Ｉｎｉｔｉａｌｉｚａｔｉｏｎ）の実行中に、自身が使用する帯域を測定する（Ｓ２１）。帯域の測定方法については、従来知られている種々の方法を用いればよい。
【００３９】
初期化後、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０間でＴｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎが確立される（Ｓ２２）。
【００４０】
そして、ＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージを送信する。図５は、このメッセージの例を示す。図５に示す例では、最下欄のパラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージにも含まれるものである。
【００４１】
本実施の形態において、ＨＮＢ１２０は、ＨＮＢ  Ｉｎｉｔｉａｌｉｚａｔｉｏｎの実行中に帯域を測定し、測定した帯域を示す情報を、「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージに対して追加したパラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」に設定する。
【００４２】
図４に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージに含まれるパラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」の値に基づいて、ＨＮＢ１２０が使用する帯域すなわちネットワーク１３０の帯域が狭帯域であるか否かを判定する。具体的には、パラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」の値が所定の閾値以下であれば狭帯域である判定をし、パラメータ「ＬＡＮｂａｎｄｗｉｄｔｈ」の値が所定の閾値より大きければ狭帯域ではない判定をする。
【００４３】
本実施の形態のフェムトシステムは、以降の動作についてフェムトシステム１００と同様であり、フェムトシステム１００と同様の効果を得ることができる。また、フェムトシステム１００で使用される狭帯域位置情報の登録をする必要が無い。
【００４４】
＜第３の実施の形態＞
本発明にかかる第３の実施の形態のフェムトシステムは、ＨＮＢ−ＧＷ１４０が、ＵＥ１１０から受信した音声データのＲＴＰ  ｔｉｍｅｓｔａｍｐと該音声データの受信時刻とを用いてネットワーク１３０の帯域が狭帯域であるか否かの判定を行う点と、ＡＭＲ起動後に該判定を行うため、ＵＥ１１０のＡＭＲ能力を把握する処理を常に実行する必要がある点において、フェムトシステム１００と異なる。
【００４５】
ＨＮＢ１２０から送信される音声データには、ＲＴＰヘッダが付与され、非特許文献５の５．１章で定められる通り、ＲＴＰ  ｔｉｍｅｓｔａｍｐが含まれる。
【００４６】
本実施の形態において、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から音声データ（ＲＴＰパケット）を受信した時、該ＲＴＰパケットの受信時刻と、該ＲＴＰパケットのＲＴＰヘッダに含まれるＲＴＰ  ｔｉｍｅｓｔａｍｐとを比較することにより、該ＲＴＰパケットがＨＮＢ１２０からＨＮＢ−ＧＷ１４０までのＲＴＰパケット到達時間を算出する。そして、所定期間における、到達時間が所定の閾値以上のＲＴＰパケットの割合が所定の割合以上である場合に、ＨＮＢ１２０が使用する帯域すなわちネットワーク１３０の帯域が狭帯域であると判定する。以降、該ＨＮＢ１２０から起動されるＡＭＲに対して、ＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートするか否かを判定し、ＡＭＲ４．７５ｋｂｐｓをサポートする場合には、フェムトシステム１００のときと同様に、パラメータの書換えと、音声データのビットレートの変換を行う。それ以外の場合には、パラメータの書換えと音声データのビットレートの変換を行わない。
【００４７】
本実施の形態のフェムトシステムも、フェムトシステム１００と同様の効果を得ることができる。また、フェムトシステム１００で使用される狭帯域位置情報の登録をする必要が無い。
【００４８】
なお、到達時間の閾値およびＲＴＰパケットの割合の閾値の決定に、ＲＴＰパケット受信時に該当ＨＮＢで起動されている呼の種別と呼の数を考慮することが望ましい。多数のＵＥが呼を起動している状態で起こった遅延より、少数のＵＥが呼を起動している状態で起こった遅延のほうが、帯域がより狭いと判断する。また、データ速度が大きい呼が起動されている状態で起こった遅延より、データ速度が小さい呼が起動されている状態で起こった遅延のほうが、帯域が狭いと判断する。
【００４９】
＜第４の実施の形態＞
本発明にかかる第４の実施の形態のフェムトシステムは、ＨＮＢ−ＧＷ１４０が、ＨＮＢ１２０が既に起動されている状態でｐｉｎｇコマンドを実行することによりＨＮＢ１２０が使用する帯域が狭帯域であるか否かの判定を行う点において、フェムトシステム１００と異なる。
【００５０】
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０で呼が１つ以上起動されている場合、所定の周期で該ＨＮＢ１２０にｐｉｎｇコマンドを送信する。
【００５１】
その後、ＨＮＢ−ＧＷ１４０は、該ＨＮＢ１２０からｐｉｎｇコマンドに対する応答を受信し、ｒｏｕｎｄ−ｔｒｉｐ  ｔｉｍｅを計算し、その統計を取る。ＨＮＢ−ＧＷ１４０は、ｒｏｕｎｄ−ｔｒｉｐｔｉｍｅが所定の閾値以上となるｐｉｎｇコマンドの割合が所定の割合以上になった場合、該ＨＮＢ１２０が使用する帯域が狭帯域であると判定する。以後、該ＨＮＢ１２０から起動されるＡＭＲに対して、ＵＥ１１０がＡＭＲ４．７５ｋｂｐｓをサポートするか否かを判定し、ＡＭＲ４．７５ｋｂｐｓをサポートする場合には、フェムトシステム１００のときと同様に、パラメータの書換えと、音声データのビットレートの変換を行う。それ以外の場合には、パラメータの書換えと音声データのビットレートの変換を行わない。
【００５２】
本実施の形態のフェムトシステムも、フェムトシステム１００と同様の効果を得ることができる。また、フェムトシステム１００で使用される狭帯域位置情報の登録をする必要が無い。
【００５３】
なお、ｒｏｕｎｄ−ｔｒｉｐ ｔｉｍｅの閾値およびｐｉｎｇコマンドの割合の閾値の決定に、ｐｉｎｇコマンド実施時に該ＨＮＢで起動されている呼の種別と呼の数を考慮することが好ましい。多数のＵＥが呼を起動している状態で起こった遅延より、少数のＵＥが呼を起動している状態で起こった遅延のほうが、帯域がより狭いと判断する。また、データ速度が大きい呼が起動されている状態で起こった遅延より、データ速度が小さい呼が起動されている状態で起こった遅延のほうが、帯域がより狭いと判断する。
【００５４】
＜第５の実施の形態＞
本発明の第５の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してＡＭＲフレーム多重化を実行するＡＭＲフレーム多重化機能を備える点と、ＨＮＢ１２０が、ＡＭＲフレーム多重化機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。
【００５５】
ＡＭＲフレーム多重化は、複数のＡＭＲフレームを１つのＲＴＰペイロードに多重化してヘッダサイズを小さくする処理である。
【００５６】
図６〜図８を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がＡＭＲフレーム多重機能をサポートするか否かを判定する処理を説明する。
【００５７】
この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅ）の中で行われる。図６において、ステップＳ３４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅの手順である。
【００５８】
ステップＳ３３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図７は、このメッセージの例を示す。図７に示す例では、最下欄のパラメータ「ＡＭＲ  ｆｒａｍｅ  ｍｕｌｔｉｐｌｅｘｉｎｇ  ｓｕｐｐｏｒｔ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージにも含まれるものである。
【００５９】
本実施の形態において、ＨＮＢ１２０は、自身がＡＭＲフレーム多重機能をサポートするものである場合に、図７に示すように、通常の「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージに対して、ＡＭＲフレーム多重機能をサポートすることを示すパラメータ「ＡＭＲ  ｆｒａｍｅ  ｍｕｌｔｉｐｌｅｘｉｎｇ  ｓｕｐｐｏｒｔ」を追加設定する。
【００６０】
図６に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ＡＭＲ  ｆｒａｍｅ  ｍｕｌｔｉｐｌｅｘｉｎｇ  ｓｕｐｐｏｒｔ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がＡＭＲフレーム多重機能をサポートするか否かを判定する（Ｓ３４）
【００６１】
ＨＮＢ１２０がＡＭＲフレーム多重機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図８の最下欄が示す、ＡＭＲフレーム多重化を指示するパラメータ「ｍａｘｐｔｉｍｅ」を設定する。「ｍａｘｐｔｉｍｅ」は、一つのＲＴＰパケットに含まれる音声データの最大時間長に設定され、「ｍａｘｐｔｉｍｅ」から、一つのＲＴＰペイロードに含まれる音声データフレームの数が決定できる。
【００６２】
以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＡＭＲフレームを、最大、「ｍａｘｐｔｉｍｅ」時間、キューイングを行う。その後、キューイングされているＡＭＲフレームを一つのＲＴＰペイロードとしてＨＮＢ１２０へ送信する。ＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０から受信した一つのＲＴＰペイロードから複数のＡＭＲフレームを生成して、該当するＵＥ１１０に送信する。
【００６３】
また、ＡＭＲフレーム多重機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のＡＭＲフレーム多重化を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信した一つのＲＴＰペイロードから複数のＡＭＲフレームを生成してＭＧＷ１７０に送信する。
【００６４】
なお、ＡＭＲフレーム多重機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ＡＭＲフレーム多重化を実行しない。
【００６５】
このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ＡＭＲフレーム多重機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをＡＭＲフレーム多重化によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。
【００６６】
＜第６の実施の形態＞
本発明の第６の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してＲＴＰパケット多重化を実行するＲＴＰパケット多重機能を備える点と、ＨＮＢ１２０が、ＲＴＰパケット多重機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。
【００６７】
ＲＴＰパケット多重化は、複数のＲＴＰパケットを１つのＵＤＰペイロードに多重化してヘッダサイズを小さくする処理である。
【００６８】
図９〜図１１を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がＲＴＰパケット多重機能をサポートするか否かを判定する処理を説明する。
【００６９】
この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅ）の中で行われる。図９において、ステップＳ４４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅの手順である。
【００７０】
ステップＳ４３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図１０は、このメッセージの例を示す。図１０に示す例では、最下欄のパラメータ「ＤＬ  Ｍｕｘ  Ｐｏｒｔ  Ｎｕｍｂｅｒ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージにも含まれるものである。
【００７１】
本実施の形態において、ＨＮＢ１２０は、自身がＲＴＰパケット多重機能をサポートするものである場合に、図１０に示すように、通常の「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージに対して、ＲＴＰパケット多重機能をサポートすることを示すパラメータ「ＤＬ  Ｍｕｘ  Ｐｏｒｔ  Ｎｕｍｂｅｒ」を追加する。パラメータ「ＤＬ  Ｍｕｘ  Ｐｏｒｔ  Ｎｕｍｂｅｒ」は、ＲＴＰパケット多重化を使用した場合にＨＮＢ１２０が受け取るＵＤＰ  ｐｏｒｔの番号に設定される。
【００７２】
図９に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ＤＬ  Ｍｕｘ  Ｐｏｒｔ  Ｎｕｍｂｅｒ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がＲＴＰパケット多重機能をサポートするか否かを判定する（Ｓ４４）
【００７３】
ＨＮＢ１２０がＲＴＰパケット多重機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図１１の最下２つの欄に示す、ＲＴＰパケット多重化を指示するパラメータ「ＵＬＭｕｘ  Ｐｏｒｔ  Ｎｕｍｂｅｒ」と「Ｌｅｎｇｔｈ  Ｉｎｄｉｃａｔｏｒ」を設定する。「ＵＬＭｕｘ  Ｐｏｒｔ  Ｎｕｍｂｅｒ」は、ＲＴＰパケット多重を使用した場合にＨＮＢ−ＧＷ１４０が受け取るＵＤＰｐｏｒｔ番号に設定される。「Ｌｅｎｇｔｈ  Ｉｎｄｉｃａｔｏｒ」は、一つのＲＴＰパケットの最大データ長に設定され、"Ｌｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ"から、一つのＵＤＰペイロードに含まれるＲＴＰパケットの数が決定できる。
【００７４】
以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＲＴＰパケットを、最大、「ＬｅｎｇｔｈＩｎｄｉｃａｔｏｒ」から決定されるサイズのキューイングを行う。その後、キューイングされているＲＴＰパケットを一つのＵＤＰペイロードとしてＨＮＢ１２０へ送信する。ＨＮＢ１２０は、ＨＮＢ１４０から受信した一つのＵＤＰペイロードから、複数のＲＴＰパケットを生成して、該当するＵＥ１１０に送信する。
【００７５】
また、ＲＴＰパケット多重機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のＲＴＰパケット多重化を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信した一つのＵＤＰペイロードから複数のＲＴＰパケットを生成してＭＧＷ１７０に送信する。
【００７６】
なお、ＲＴＰパケット多重機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ＲＴＰパケット多重化を実行しない。
【００７７】
このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ＲＴＰパケット多重機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをＲＴＰパケット多重化によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。
【００７８】
＜第７の実施の形態＞
本発明の第７の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してＵＤＰパケット多重化を実行するＵＤＰパケット多重機能を備える点と、ＨＮＢ１２０が、ＵＤＰパケット多重機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。
【００７９】
ＵＤＰパケット多重化は、複数のＵＤＰパケットを１つのＩＰペイロードに多重化してヘッダサイズを小さくする処理である。
【００８０】
図１２〜図１４を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がＵＤＰパケット多重機能をサポートするか否かを判定する処理を説明する。
【００８１】
この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅ）の中で行われる。図１２において、ステップＳ５４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅの手順である。
【００８２】
ステップＳ５３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図１３は、このメッセージの例を示す。図１３に示す例では、最下欄のパラメータ「ＵＤＰ  ｐａｃｋｅｔ  ｍｕｌｔｉｐｌｅｘｉｎｇ  ｓｕｐｐｏｒｔ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージにも含まれるものである。
【００８３】
本実施の形態において、ＨＮＢ１２０は、自身がＵＤＰパケット多重機能をサポートするものである場合に、図１３に示すように、通常の「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージに対して、ＵＤＰパケット多重機能をサポートすることを示すパラメータ「ＵＤＰ  ｐａｃｋｅｔ  ｍｕｌｔｉｐｌｅｘｉｎｇ  ｓｕｐｐｏｒｔ」を追加する。
【００８４】
図１２に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ＵＤＰ  ｐａｃｋｅｔ  ｍｕｌｔｉｐｌｅｘｉｎｇ  ｓｕｐｐｏｒｔ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がＵＤＰパケット多重機能をサポートするか否かを判定する（Ｓ５４）。
【００８５】
ＨＮＢ１２０がＵＤＰパケット多重機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図１４の最下欄に示す、ＵＤＰパケット多重化を指示するパラメータ「Ｍａｘｉｍｕｍ  Ｍｅｓｓａｇｅ  Ｓｉｚｅ」を設定する。パラメータ「Ｍａｘｉｍｕｍ  Ｍｅｓｓａｇｅ  Ｓｉｚｅ」には、一つのＩＰペイロードの最大データ長に設定され、「Ｍａｘｉｍｕｍ  Ｍｅｓｓａｇｅ  Ｓｉｚｅ」から、一つのＩＰペイロードに含まれる音声データフレームの数が決定できる。
【００８６】
以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＵＤＰパケットを、最大、「Ｍａｘｉｍｕｍ  Ｍｅｓｓａｇｅ  Ｓｉｚｅ」から決定されるサイズのキューイングを行う。その後、キューイングされているＵＤＰパケットを一つのＩＰペイロードとしてＨＮＢ１２０へ送信する。
【００８７】
また、ＵＤＰパケット多重機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のＵＤＰパケット多重化を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信した一つのＩＰペイロードから複数のＵＤＰパケットを生成してＭＧＷ１７０に送信する。
【００８８】
なお、ＵＤＰパケット多重機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ＵＤＰパケット多重化を実行しない。
【００８９】
このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ＵＤＰパケット多重機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをＵＤＰパケット多重化によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。
【００９０】
＜第８の実施の形態＞
本発明の第８の実施の形態にかかるフェムトシステムは、ＨＮＢ−ＧＷ１４０が、音声データをＨＮＢ１２０に転送する際に、音声データに対してｄｅｆｌａｔｅ圧縮／解凍を実行するｄｅｆｌａｔｅ機能を備える点と、ＨＮＢ１２０が、ｄｅｆｌａｔｅ機能をサポートするものである場合に、その旨をＨＮＢ−ＧＷ１４０に通知する機能を備える点において、フェムトシステム１００と異なる。
【００９１】
ｄｅｆｌａｔｅ機能とは、ｄｅｆｌａｔｅ方式でデータを圧縮する処理（ｄｅｆｌａｔｅ圧縮）と、ｄｅｆｌａｔｅ方式で圧縮されたデータを解凍する処理（ｄｅｆｌａｔｅ解凍）であり、これにより、ＩＰペイロード自体を圧縮することができる。
【００９２】
図１５〜図１７を参照して、ＨＮＢ−ＧＷ１４０によりＨＮＢ１２０がｄｅｆｌａｔｅ機能をサポートするか否かを判定する処理を説明する。
【００９３】
この判定は、ＨＮＢ１２０によるＨＮＢ−ＧＷ１４０への初回接続時に開始される認証手順（ＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅ）の中で行われる。図１５において、ステップＳ６４を除いた他の各ステップは、通常のフェムトシステムにおけるＨＮＢ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅの手順である。
【００９４】
ステップＳ６３で、ＨＮＢ１２０は、「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージをＨＮＢ−ＧＷ１４０に送信する。図１６は、このメッセージの例を示す。図１６に示す例では、最下欄のパラメータ「ｄｅｆｌａｔｅ  ｓｕｐｐｏｒｔ」を除き、各パラメータは、非特許文献２に定義されたパラメータであり、通常のフェムトシステムにおける「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージにも含まれるものである。
【００９５】
本実施の形態において、ＨＮＢ１２０は、自身がｄｅｆｌａｔｅ機能をサポートするものである場合に、図１６に示すように、通常の「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージに対して、ｄｅｆｌａｔｅ機能をサポートすることを示すパラメータ「ｄｅｆｌａｔｅ  ｓｕｐｐｏｒｔ」を追加する。
【００９６】
図１５に戻って説明する。
ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０からの「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴ」メッセージを受信すると、該メッセージにパラメータ「ｄｅｆｌａｔｅ  ｓｕｐｐｏｒｔ」が含まれているか否かを確認することにより、該ＨＮＢ１２０がｄｅｆｌａｔｅ機能をサポートするか否かを判定する（Ｓ６４）。
【００９７】
ＨＮＢ１２０がｄｅｆｌａｔｅ機能をサポートする場合、ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０に返送する「ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＡＣＣＥＰＴ」メッセージの中に、通常のパラメータ以外に、例えば図１７の最下欄に示す、ｄｅｆｌａｔｅを指示するパラメータ「ｄｅｆｌａｔｅ」を設定する。
【００９８】
以降、ＨＮＢ−ＧＷ１４０は、ＭＧＷ１７０から受信したＩＰペイロードに対してｄｅｆｌａｔｅ圧縮を行ってからＨＮＢ１２０へ送信する。
【００９９】
また、ｄｅｆｌａｔｅ機能をサポートするＨＮＢ１２０は、ＨＮＢ−ＧＷ１４０に音声データを送信する際にも、同様のｄｅｆｌａｔｅ圧縮を行う。ＨＮＢ−ＧＷ１４０は、ＨＮＢ１２０から受信したＩＰペイロードに対してｄｅｆｌａｔｅ解凍を行ってＭＧＷ１７０に送信する。
【０１００】
なお、ｄｅｆｌａｔｅ機能をサポートしないＨＮＢ１２０の場合には、ＨＮＢ−ＧＷ１４０は、ｄｅｆｌａｔｅ化を実行しない。
【０１０１】
このように、本実施の形態のフェムトシステムは、フェムトシステム１００と同様の処理を行うと共に、ｄｅｆｌａｔｅ機能をサポートするＨＮＢ１２０の場合には、ＨＮＢ１２０とＨＮＢ−ＧＷ１４０で伝送される音声データをｄｅｆｌａｔｅ圧縮によりさらに圧縮するので、帯域不足の問題解消により効果を発揮することができる。
【０１０２】
以上、実施の形態をもとに本発明を説明した。実施の形態は例示であり、本発明の主旨から逸脱しない限り、上述各実施の形態に対して、さまざまな変更、増減、組合せを加えてもよい。これらの変更、増減、組合せが加えられた変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１０３】
例えば、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）でも同様に、ＨｅＮＢやＨｅＮＢ−ＧＷに本発明の技術を適用できる。また、多重化情報、ポート情報の通知には、上述した各実施の形態に用いられたＨＮＢＡＰ、ＵＲＡ、ＲＡＮＡＰ以外のプロトコルを用いてもよい。
【０１０４】
この出願は、２００９年１２月１０日に出願された日本出願特願２００９−２８０１５４を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１０５】
本発明は、メディアゲートウェイとフェムトセルとの間における音声データの中継に適用することができる。
【符号の説明】
【０１０６】
１０  フェムトシステム
２０  ＵＥ
３０  ＨＮＢ
４０  ネットワーク
５０  ＨＮＢ−ＧＷ
５２  ＭＧＷ
５４  ＭＳＣ
１００  フェムトシステム
１１０  ＵＥ
１２０  ＨＮＢ
１３０  ネットワーク
１４０  ＨＮＢ−ＧＷ
１５０  狭帯域判定部
１６０  変換部
１７０  ＭＧＷ
１８０  ＭＳＣ
【図１】
2011070740.tif 000003
【図２】
2011070740.tif 000004
【図３】
2011070740.tif 000005
【図４】
2011070740.tif 000006
【図５】
2011070740.tif 000007
【図６】
2011070740.tif 000008
【図７】
2011070740.tif 000009
【図８】
2011070740.tif 000010
【図９】
2011070740.tif 000011
【図１０】
2011070740.tif 000012
【図１１】
2011070740.tif 000013
【図１２】
2011070740.tif 000014
【図１３】
2011070740.tif 000015
【図１４】
2011070740.tif 000016
【図１５】
2011070740.tif 000017
【図１６】
2011070740.tif 000018
【図１７】
2011070740.tif 000019
【図１８】
2011070740.tif 000020
【手続補正書】
【提出日】平成24年6月7日(2012.6.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介してフェムトセルと接続され、メディアゲートウェイと前記フェムトセル間における音声データの送受信を中継するゲートウェイ装置であって、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定手段と、
前記狭帯域判定手段により狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する変換手段とを備えることを特徴とするゲートウェイ装置。
【請求項２】
前記変換手段は、さらに、前記フェムトセルに接続された端末装置がサポートしうるビットレートを確認し、
前記音声データを変換する際に、そのビットレートを、前記端末装置がサポートしうるビットレートに下げることを特徴とする請求項１に記載のゲートウェイ装置。
【請求項３】
前記変換手段は、さらに、前記狭帯域判定手段により狭帯域である判定がなされたときに、前記フェムトセルから前記メディアゲートウェイに転送する音声データのビットレートを上げるように前記音声データを変換することを特徴とする請求項１または２に記載のゲートウェイ装置。
【請求項４】
前記変換手段は、前記フェムトセルに転送する音声データを変換する際に、さらに、前記フェムトセルが対応可能な多重化方式で多重化を行うことを特徴とする請求項１から３のいずれか１項に記載のゲートウェイ装置。
【請求項５】
前記多重化方式は、複数のフレームを１つのＲＴＰペイロードに多重化するフレーム多重と、複数のＲＴＰパケットを１つのＵＤＰペイロードに多重化するＲＴＰパケット多重と、複数のＵＤＰパケットを１つのＩＰペイロードに多重化するｄｅｆｌａｔｅのうちのいずれか１つであることを特徴とする請求項４に記載のゲートウェイ装置。
【請求項６】
前記変換手段は、デフレートに対応するフェムトセルに転送する音声データを変換する際に、さらに、デフレートで圧縮を行うことを特徴とする請求項１から５のいずれか１項に記載のゲートウェイ装置。
【請求項７】
ネットワークを介してメディアゲートウェイと音声データの送受信を行うフェムトセルと、前記メディアゲートウェイとの間における音声データの送受信を中継する際に、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定し、
狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換することを特徴とする中継方法。
【請求項８】
ネットワークを介してメディアゲートウェイと音声データの送受信を行うフェムトセルと、前記メディアゲートウェイとの間における音声データの送受信を中継する際に、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定し、
狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する処理をコンピュータに実行せしめるプログラム。
【請求項９】
メディアゲートウェイと、
フェムトセルと、
ネットワークを介して前記フェムトセルと接続され、前記メディアゲートウェイと前記フェムトセル間における音声データの送受信を中継するゲートウェイ装置とを有し、
前記ゲートウェイ装置は、
前記ネットワークの帯域が所定の閾値以下となる狭帯域であるか否かを判定する狭帯域判定手段と、
前記狭帯域判定手段により狭帯域である判定がなされたときに、前記メディアゲートウェイから前記フェムトセルに転送する音声データのビットレートを下げるように前記音声データを変換する変換手段とを備えることを特徴とするフェムトシステム。
【国際調査報告】
2011070740.tif 000021
2011070740.tif 000022
2011070740.tif 000023
2011070740.tif 000024