(57)【要約】【課題】好適なビットを含む伝送ブロックサイズのテーブルを持つ事により、基地局装置と端末装置との通信を効率的に行う端末装置、方法、および集積回路に関する技術を提供すること。【解決手段】一つ又は複数の基地局装置と通信と行う端末装置であって、基地局から伝送ブロックサイズの決定に必要な情報を受信する受信部と、受信部より受信した前記情報と、伝送ブロックサイズのテーブルより伝送ブロックサイズを決定する処理部と、を有し、前記伝送ブロックサイズのテーブルには、前記伝送ブロックサイズとして１５２ビット、１６０ビット、３４４ビット、３５２ビット、６７２ビット、及び６８８ビットを含む。【選択図】図５
2019121830.tif 000002
【特許請求の範囲】
【請求項１】
一つ又は複数の基地局装置と通信と行う端末装置であって、
前記基地局から伝送ブロックサイズの決定に必要な情報を受信する受信部と、
前記受信部より受信した前記情報と、伝送ブロックサイズのテーブルより伝送ブロックサイズを決定する処理部と、を有し、
前記伝送ブロックサイズのテーブルには、前記伝送ブロックサイズとして１５２ビット、１６０ビット、３４４ビット、３５２ビット、６７２ビット、及び６８８ビットを含む、端末装置。
【請求項２】
一つ又は複数の基地局装置と通信と行う端末装置の方法であって、
前記基地局から伝送ブロックサイズの決定に必要な情報を受信し、
前記情報と、伝送ブロックサイズのテーブルより伝送ブロックサイズを決定し、
前記伝送ブロックサイズのテーブルには、前記伝送ブロックサイズとして１５２ビット、１６０ビット、３４４ビット、３５２ビット、６７２ビット、及び６８８ビットを含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置、方法、および、集積回路に関する。
【背景技術】
【０００２】
セルラ−移動通信の無線アクセス方式および無線ネットワーク（以下、「Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ：登録商標）」、または、「Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ：ＥＵＴＲＡ」と称する。）、及びコアネットワーク（以下、「Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ：ＥＰＣ」）が、第三世代パートナーシッププロジェクト（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ：３ＧＰＰ）において検討されている。
【０００３】
また、３ＧＰＰにおいて、第５世代のセルラ−システムに向けた無線アクセス方式および無線ネットワーク技術として、ＬＴＥの拡張技術であるＬＴＥ−Ａｄｖａｎｃｅｄ  Ｐｒｏおよび新しい無線アクセス技術であるＮＲ（Ｎｅｗ  Ｒａｄｉｏ  ｔｅｃｈｎｏｌｏｇｙ）の技術検討及び規格策定が行われている（非特許文献１）。また第５世代セルラーシステムに向けたコアネットワークである、５ＧＣ（５  Ｇｅｎｅｒａｔｉｏｎ  Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）の検討も行われている（非特許文献２）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ  ＲＰ−１７０８５５，”Ｗｏｒｋ  Ｉｔｅｍ  ｏｎ  Ｎｅｗ  Ｒａｄｉｏ  （ＮＲ）  Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ”
【非特許文献２】３ＧＰＰ  ＴＳ  ２３．５０１,“Ｓｙｓｔｅｍ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  ｔｈｅ  ５Ｇ  Ｓｙｓｔｅｍ；  Ｓｔａｇｅ  ２”
【非特許文献３】３ＧＰＰ  ＴＳ  ３６．３００,  “Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  （Ｅ−ＵＴＲＡ）ａｎｄ  Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  （Ｅ−ＵＴＲＡＮ）；Ｏｖｅｒａｌｌ  ｄｅｓｃｒｉｐｔｉｏｎ；  Ｓｔａｇｅ  ２”
【非特許文献４】３ＧＰＰ  ＴＳ  ３６．３３１,“Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  （Ｅ−ＵＴＲＡ）；Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  （ＲＲＣ）；Ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎｓ”
【非特許文献５】３ＧＰＰ  ＴＳ  ３６．３２３,“Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  （Ｅ−ＵＴＲＡ）；Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ  （ＰＤＣＰ）  ｓｐｅｃｉｆｉｃａｔｉｏｎ”
【非特許文献６】３ＧＰＰ  ＴＳ  ３６．３２２,“Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  （Ｅ−ＵＴＲＡ）；Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  （ＲＬＣ）  ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ”
【非特許文献７】３ＧＰＰ  ＴＳ  ３６．３２１,“Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  （Ｅ−ＵＴＲＡ）；Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  （ＭＡＣ）  ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ”
【非特許文献８】３ＧＰＰ  ＴＳ  ３６．２１３,“Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  （Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｒｏｃｅｄｕｒｅｓ”
【非特許文献９】３ＧＰＰ  ＴＳ  ３８．２１４,  “ＮＲ；Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｒｏｃｅｄｕｒｅ  ｆｏｒ  ｄａｔａ”
【非特許文献１０】３ＧＰＰ  ＴＳ  ３８．３３１,“ＮＲ；Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  （ＲＲＣ）；Ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎｓ”
【非特許文献１１】３ＧＰＰ  ＴＳ  ３８．３２３,“ＮＲ；Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ  （ＰＤＣＰ）  ｓｐｅｃｉｆｉｃａｔｉｏｎ”
【非特許文献１２】３ＧＰＰ  ＴＳ  ３８．３２２,“ＮＲ；Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  （ＲＬＣ）  ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ”
【非特許文献１３】３ＧＰＰ  ＴＳ  ３８．３２１,“ＮＲ；Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  （ＭＡＣ）  ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ”
【非特許文献１４】３ＧＰＰ  ＴＳ  ２３．４０１  ｖ１４．３．０，“Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ  （ＧＰＲＳ）  ｅｎｈａｎｃｅｍｅｎｔｓ  ｆｏｒ  Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  （Ｅ−ＵＴＲＡＮ）  ａｃｃｅｓｓ”
【非特許文献１５】３ＧＰＰ  ＴＳ  ２６．４４５,“Ｃｏｄｅｃ  ｆｏｒ  Ｅｎｈａｎｃｅｄ  Ｖｏｉｃｅ  Ｓｅｒｖｉｃｅｓ  （ＥＶＳ）；Ｄｅｔａｉｌｅｄ  Ａｌｇｏｒｉｔｈｍｉｃ  Ｄｅｓｃｒｉｐｔｉｏｎ”
【非特許文献１６】３ＧＰＰ  ＴＳ  ３８．３２４,  “ＮＲ；Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ａｄａｐｔａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  （ＳＤＡＰ）  ｓｐｅｃｉｆｉｃａｔｉｏｎ”
【非特許文献１７】３ＧＰＰ  Ｒ２−１７１４０７０，  “ＬＳ  ｏｎ  ＶｏＩＰ  ｐａｃｋｅｔ  ｓｉｚｅｓ  ａｎｄ  ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋｓ”
【発明の概要】
【発明が解決しようとする課題】
【０００５】
３ＧＰＰのサービスとして、３ＧＰＰのＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ベースの無線ネットワーク及びコアネットワーク上で音声通話サービスを提供するＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）がある。
【０００６】
しかしながら、データ長が予測可能なＶｏＩＰデータに対し、適切なサイズの無線リソースを割り当てない限り、無線ネットワークの無線リソース効率を最大化できず、基地局装置と端末装置との通信を効率的に行うことができないという課題があった。
【０００７】
本発明の一態様は、上記した事情に鑑みてなされたもので、基地局装置との通信を効率的に行うことができる端末装置、該当端末に用いられる方法、該端末装置に実装される集積回路を提供することを目的の一つとする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本発明の一態様は、以下のような手段を講じた。すなわち、本発明の一態様は、一つ又は複数の基地局装置と通信と行う端末装置であって、前記基地局から伝送ブロックサイズの決定に必要な情報を受信する受信部と、前記受信部より受信した前記情報と、伝送ブロックサイズのテーブルより伝送ブロックサイズを決定する処理部と、を有し、前記伝送ブロックサイズのテーブルには、前記伝送ブロックサイズとして１５２ビット、１６０ビット、３４４ビット、３５２ビット、６７２ビット、及び６８８ビットを含む。
【０００９】
また、本発明の一態様は、一つ又は複数の基地局装置と通信と行う端末装置の方法であって、前記基地局から伝送ブロックサイズの決定に必要な情報を受信し、前記情報と、伝送ブロックサイズのテーブルより伝送ブロックサイズを決定し、前記伝送ブロックサイズのテーブルには、前記伝送ブロックサイズとして１５２ビット、１６０ビット、３４４ビット、３５２ビット、６７２ビット、及び６８８ビットを含む。
【００１０】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【００１１】
本発明の一態様によれば、端末装置は、伝送ブロックサイズのテーブルに、好適なビット数を持つ事により、効率的な通信を行うことができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態に係る通信システムの概略図。
【図２】本発明の実施の形態における、Ｅ−ＵＴＲＡにおける端末装置と基地局装置のＵＰ及びＣＰのプロトコルスタック図。
【図３】本発明の実施の形態における、ＮＲにおける端末装置と基地局装置のＵＰ及びＣＰのプロトコルスタック図。
【図４】ＮＲにおいてＵＥ１２２がアップリンクデータを送信する際の、無線リソース割り当てを示すシーケンスチャート。
【図５】本発明の実施の形態における、ＵＥ１２２の構成を示すブロック図。
【図６】ＡＭＲコーデック及びＡＭＲ−ＷＢコーデックのＳＩＤ及び各ビットレートにおけるデータ長に関するテーブル。
【図７】ＥＶＳコーデックのプライマリモードにおけるＳＩＤ及び各ビットレートにおけるデータ長に関するテーブル。
【図８】ＥＶＳプライマリモード１３．２Ｋｂｐｓ以下のコンパクトフォーマット及びＣＭＲバイト付きヘッダフルフォーマットに対する伝送ブロックサイズを示すテーブル。
【発明を実施するための形態】
【００１３】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００１４】
ＬＴＥ（およびＬＴＥ−Ａ  Ｐｒｏ）とＮＲは、異なるＲＡＴとして定義されてもよい。またＮＲは、ＬＴＥに含まれる技術として定義されてもよい。ＬＴＥは、ＮＲに含まれる技術として定義されてもよい。また、ＮＲとＤｕａｌ  ｃｏｎｎｅｃｔｉｖｉｔｙで接続可能なＬＴＥは、従来のＬＴＥと区別されてもよい。本実施形態はＮＲ、ＬＴＥおよび他のＲＡＴに適用されてよい。以下の説明では、ＬＴＥおよびＮＲに関連する用語を用いて説明するが、他の用語を用いる他の技術において適用されてもよい。
【００１５】
図１は本発明の実施の形態に係る通信システムの概略図である。
【００１６】
Ｅ−ＵＴＲＡ１００は非特許文献３等に記載の無線アクセス技術であり、１つ又は複数の周波数帯域で構成するセルグループ（Ｃｅｌｌ  Ｇｒｏｕｐ：ＣＧ）から成る。ｅＮＢ（Ｅ−ＵＴＲＡＮ  Ｎｏｄｅ  Ｂ）１０２は、Ｅ−ＵＴＲＡの基地局装置である。ＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）１０４は、非特許文献１４等に記載のコア網であり、Ｅ−ＵＴＲＡ用コア網として設計された。インタフェース１１２はｅＮＢ１０２とＥＰＣ１０４の間のインタフェース（ｉｎｔｅｒｆａｃｅ）であり、制御信号が通る
制御プレーン（Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ：ＣＰ）と、そのユーザデータが通るユーザプレーン（Ｕｓｅｒ  Ｐｌａｎｅ：ＵＰ）が存在する。
【００１７】
ＮＲ１０６は現在３ＧＰＰにて検討している新しい無線アクセス技術であり、１つ又は複数の周波数帯域で構成するセルグループ（Ｃｅｌｌ  Ｇｒｏｕｐ：ＣＧ）から成る。ｇＮＢ（ｇ  Ｎｏｄｅ  Ｂ）１０８は、ＮＲの基地局装置である。５ＧＣ１１０は、現在３ＧＰＰにて検討しているＮＲ用の新しいコア網であり、非特許文献２等に記載される。
【００１８】
インタフェース１１４はｅＮＢ１０２と５ＧＣ１１０の間のインタフェース、インタフェース１１６はｇＮＢ１０８と５ＧＣ１１０の間のインタフェース、インタフェース１１８はｇＮＢ１０８とＥＰＣ１０４の間のインタフェース、インタフェース１２０はｅＮＢ１０２とｇＮＢ１０８の間のインタフェース、インタフェース１２４はＥＰＣ１０４と５ＧＣ１１０間のインタフェースである。インタフェース１１４、インタフェース１１６、インタフェース１１８、インタフェース１２０、インタフェース１２４はＣＰのみ、又はＵＰのみ、又はＣＰ及びＵＰ両方を通すインタフェースであるが詳細は３ＧＰＰにおいて議論中である。また、インタフェース１１４、インタフェース１１６、インタフェース１１８、インタフェース１２０、インタフェース１２４は、通信事業者が提供する通信システムに応じて存在しない場合もある。
【００１９】
ＵＥ１２２はＮＲに対応、又はＥ−ＵＴＲＡ及びＮＲ両方に対応した端末装置である。
【００２０】
図２は本発明の実施の形態における、Ｅ−ＵＴＲＡ無線アクセスレイヤにおける端末装置と基地局装置のＵＰ及びＣＰのプロトコルスタック（Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）図である。
【００２１】
図２（Ａ）はＵＥ１２２がｅＮＢ１０２と通信を行う際に用いるＵＰのプロトコルスタック図である。
【００２２】
ＰＨＹ（Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）２００は、無線物理層であり、物理チャネル（Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）を利用して上位層に伝送サービスを提供する。ＰＨＹ２００は、後述する上位のＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  ｌａｙｅｒ）２０２とトランスポートチャネル（Ｔｒａｎｓｐｏｒｔ  Ｃｈａｎｎｅｌ）で接続される。トランスポートチャネルを介して、ＭＡＣ２０２とＰＨＹ２００の間でデ−タが移動する。ＵＥ１２２とｅＮＢ１０２のＰＨＹ間において、無線物理チャネルを介してデ−タの送受信が行われる。
【００２３】
ＭＡＣ２０２は、多様な論理チャネル（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）を多様なトランスポートチャネルにマッピングを行う。ＭＡＣ２０２は、後述する上位のＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  ｌａｙｅｒ）２０４と、論理チャネルで接続される。論理チャネルは、伝送される情報の種類によって大きく分けられ、制御情報を伝送する制御チャネルとユ−ザ情報を伝送するトラフィックチャネルに分けられる。ＭＡＣ２０２は、間欠受送信（ＤＲＸ・ＤＴＸ）を行うためにＰＨＹ２００の制御を行う機能、ランダムアクセス（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ）手順を実行する機能、送信電力の情報を通知する機能、ＨＡＲＱ制御を行う機能などを持つ（非特許文献７）。
【００２４】
ＲＬＣ２０４は、後述する上位のＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ  Ｌａｙｅｒ）２０６から受信したデ−タを分割（Ｓｅｇｍｅｎｔａｔｉｏｎ）し、下位層が適切にデ−タ送信できるようにデ−タサイズを調節する。また、ＲＬＣ２００は、各デ−タが要求するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を保証するための機能も持つ。すなわち、ＲＬＣ２０４は、デ−タの再送制御等
の機能を持つ（非特許文献６）。
【００２５】
ＰＤＣＰ２０６は、ユーザデータであるＩＰパケット（ＩＰ  Ｐａｃｋｅｔ）を無線区間で効率的に伝送するために、不要な制御情報の圧縮を行うヘッダ圧縮（ＲｏＨＣ：Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）機能を持ってもよい。また、ＰＤＣＰ２０６は、デ−タの暗号化の機能も持ってもよい（非特許文献５）。
【００２６】
なお、ＭＡＣ２０２、ＲＬＣ２０４、ＰＤＣＰ２０６において処理されたデータの事を、それぞれＭＡＣ  ＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）、ＲＬＣ  ＰＤＵ、ＰＤＣＰ  ＰＤＵと呼ぶ。また、ＭＡＣ２０２、ＲＬＣ２０４、ＰＤＣＰ２０６に上位層から渡されるデータ、又は上位層に渡すデータの事を、それぞれＭＡＣ  ＳＤＵ（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）、ＲＬＣ  ＳＤＵ、ＰＤＣＰ  ＳＤＵと呼ぶ。
【００２７】
図２（Ｂ）はＵＥ１２２がｅＮＢ１０２と通信を行う際に用いるＣＰのプロトコルスタック図である。
【００２８】
ＣＰのプロトコルスタックには、ＰＨＹ２００、ＭＡＣ２０２、ＲＬＣ２０４、ＰＤＣＰ２０６に加え、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  ｌａｙｅｒ）２０８が存在する。ＲＲＣ２０８は、無線ベアラ（Ｒａｄｉｏ  Ｂｅａｒｅｒ：ＲＢ）の設定・再設定を行い、論理チャネル、トランスポートチャネル及び物理チャネルの制御を行う。ＲＢは、シグナリグ無線ベアラ（Ｓｉｇｎａｌｉｎｇ  Ｒａｄｉｏ  Ｂｅａｒｅｒ：ＳＲＢ）とデ−タ無線ベアラ（Ｄａｔａ  Ｒａｄｉｏ  Ｂｅａｒｅｒ：ＤＲＢ）とに分けられてもよく、ＳＲＢは、制御情報であるＲＲＣメッセージを送信する経路として利用されてもよい。ＤＲＢは、ユーザデータを送信する経路として利用されてもよい。ｅＮＢ１０２とＵＥ１２２のＲＲＣ２０８間で各ＲＢの設定が行われてもよい（非特許文献４）。
【００２９】
前述のＭＡＣ２０２、ＲＬＣ２０４、ＰＤＣＰ２０６、及びＲＲＣ２０８の機能分類は一例であり、各機能の一部あるいは全部が実装されなくてもよい。また、各層の機能の一部あるいは全部が他の層に含まれてもよい。
【００３０】
図３は本発明の実施の形態における、ＮＲ無線アクセスレイヤにおける端末装置と基地局装置のＵＰ及びＣＰのプロトコルスタック（Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）図である。
【００３１】
図３（Ａ）はＵＥ１２２がｇＮＢ１０８と通信を行う際に用いるＵＰのプロトコルスタック図である。
【００３２】
ＰＨＹ（Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）３００は、ＮＲの無線物理層であり、物理チャネル（Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）を利用して上位層に伝送サービスを提供してもよい。ＰＨＹ３００は、後述する上位のＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  ｌａｙｅｒ）３０２とトランスポートチャネル（Ｔｒａｎｓｐｏｒｔ  Ｃｈａｎｎｅｌ）で接続されてもよい。トランスポートチャネルを介して、ＭＡＣ３０２とＰＨＹ３００の間でデ−タが移動してもよい。ＵＥ１２２とｇＮＢ１０８のＰＨＹ間において、無線物理チャネルを介してデ−タの送受信が行われてもよい。詳細においてはＥ−ＵＴＲＡの無線物理層ＰＨＹ２００とは異なり、３ＧＰＰにおいて議論中である。
【００３３】
ＭＡＣ３０２は、多様な論理チャネル（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）を多様なトランスポートチャネルにマッピングを行ってもよい。ＭＡＣ３０２は、後述する上位のＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  ｌａｙｅｒ）３０４と、論理チャネルで
接続されてもよい。論理チャネルは、伝送される情報の種類によって大きく分けられ、制御情報を伝送する制御チャネルとユ−ザ情報を伝送するトラフィックチャネルに分けられてもよい。ＭＡＣ３０２は、間欠受送信（ＤＲＸ・ＤＴＸ）を行うためにＰＨＹ３００の制御を行う機能、ランダムアクセス（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ）手順を実行する機能、送信電力の情報を通知する機能、ＨＡＲＱ制御を行う機能などを持ってもよい（非特許文献１３）。詳細においてはＥ−ＵＴＲＡのＭＡＣ２０２とは異なり、３ＧＰＰにおいて議論中である。
【００３４】
ＲＬＣ３０４は、後述する上位のＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ  Ｌａｙｅｒ）２０６から受信したデ−タを分割（Ｓｅｇｍｅｎｔａｔｉｏｎ）し、下位層が適切にデ−タ送信できるようにデ−タサイズを調節してもよい。また、ＲＬＣ３０４は、各デ−タが要求するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を保証するための機能も持っても良い。すなわち、ＲＬＣ３０４は、デ−タの再送制御等の機能を持っても良い（非特許文献１２）。詳細においてはＥ−ＵＴＲＡのＲＬＣ２０４とは異なり、３ＧＰＰにおいて議論中である。
【００３５】
ＰＤＣＰ３０６は、ユーザデータであるＩＰパケット（ＩＰ  Ｐａｃｋｅｔ）を無線区間で効率的に伝送するために、不要な制御情報の圧縮を行うヘッダ圧縮（ＲｏＨＣ：Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）機能を持ってもよい。また、ＰＤＣＰ３０６は、デ−タの暗号化の機能も持ってもよい（非特許文献１１）。詳細においてはＥ−ＵＴＲＡのＰＤＣＰ２０６とは異なり、３ＧＰＰにおいて議論中である。
【００３６】
ＳＤＡＰ（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ａｄａｐｔａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）３１０は、コアネットワークから基地局装置を介して端末装置に送られるダウンリンクのＱｏＳフローとＤＲＢとのマッピング（ｍａｐｐｉｎｇ）、及び端末装置から基地局装置を介してコアネットワークに送られるアップリンクのＱｏＳ情報フローと、ＤＲＢとのマッピングを行い、マッピングルール情報を格納する機能を持ってもよい（非特許文献１６）。ＱｏＳフローは同じＱｏＳポリシーによって処理される、一つ又は複数のサービスデータフロー（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｆｌｏｗ：ＳＤＦ）から成る（非特許文献２）。またＳＤＡＰはダウンリンクＱｏＳフローの情報を基に、アップリンクのＱｏＳフローとＤＲＢとのマッピングを行う、リフレクティブＱｏＳ（Ｒｅｆｌｅｃｔｉｖｅ  ＱｏＳ）の機能を持っても良い（非特許文献２、非特許文献１６）。詳細においては３ＧＰＰにおいて議論中である。
【００３７】
なお、ＩＰレイヤ、及びＩＰレイヤより上のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）レイヤ、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）レイヤ、アプリケーションレイヤなどは、ＳＤＡＰの上位レイヤとなる（不図示）。また端末装置のＳＤＡＰにおいて、サービスデータフローとＱｏＳフローとの対応付けを行うレイヤも、ＳＤＡＰの上位レイヤとなる。
【００３８】
なお、ＭＡＣ３０２、ＲＬＣ３０４、ＰＤＣＰ３０６、ＳＤＡＰ３１０において処理されたデータの事を、それぞれＭＡＣ  ＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）、ＲＬＣ  ＰＤＵ、ＰＤＣＰ  ＰＤＵ、ＳＤＡＰ  ＰＤＵと呼んでも良い。また、ＭＡＣ２０２、ＲＬＣ２０４、ＰＤＣＰ２０６に上位層から渡されるデータ、又は上位層に渡すデータの事を、それぞれＭＡＣ  ＳＤＵ（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）、ＲＬＣ  ＳＤＵ、ＰＤＣＰ  ＳＤＵ、ＳＤＡＰ  ＳＤＵと呼んでも良い。
【００３９】
図３（Ｂ）はＵＥ１２２がｇＮＢ１０８と通信を行う際に用いるＣＰのプロトコルスタック図である。
【００４０】
ＣＰのプロトコルスタックには、ＰＨＹ３００、ＭＡＣ３０２、ＲＬＣ３０４、ＰＤＣＰ３０６に加え、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  ｌａｙｅｒ）３０８が存在する。ＲＲＣ３０８は、無線ベアラ（Ｒａｄｉｏ  Ｂｅａｒｅｒ：ＲＢ）の設定・再設定を行い、論理チャネル、トランスポートチャネル及び物理チャネルの制御を行っても良い。ＲＢは、シグナリグ無線ベアラ（Ｓｉｇｎａｌｉｎｇ  Ｒａｄｉｏ  Ｂｅａｒｅｒ：ＳＲＢ）とデ−タ無線ベアラ（Ｄａｔａ  Ｒａｄｉｏ  Ｂｅａｒｅｒ：ＤＲＢ）とに分けられてもよく、ＳＲＢは、制御情報であるＲＲＣメッセージを送信する経路として利用されてもよい。ＤＲＢは、ユーザデータを送信する経路として利用されてもよい。ｇＮＢ１０８とＵＥ１２２のＲＲＣ３０８間で各ＲＢの設定が行われてもよい（非特許文献１０）。
【００４１】
前述のＭＡＣ３０２、ＲＬＣ３０４、ＰＤＣＰ３０６、ＳＤＡＰ３１０、及びＲＲＣ３０８の機能分類は一例であり、各機能の一部あるいは全部が実装されなくてもよい。また、各層の機能の一部あるいは全部が他の層に含まれてもよい。
【００４２】
なお、本発明の実施の形態では、以下Ｅ−ＵＴＲＡのプロトコルとＮＲのプロトコルを区別するため、ＭＡＣ２０２、ＲＬＣ２０４、ＰＤＣＰ２０６、及びＲＲＣ２０８を、それぞれＥ−ＵＴＲＡ用ＭＡＣ又はＬＴＥ用ＭＡＣ、Ｅ−ＵＴＲＡ用ＲＬＣ又はＬＴＥ用ＲＬＣ、Ｅ−ＵＴＲＡ用ＰＤＣＰ又はＬＴＥ用ＰＤＣＰ、及びＥ−ＵＴＲＡ用ＲＲＣ又はＬＴＥ用ＲＲＣと呼ぶ事もある。また、ＭＡＣ３０２、ＲＬＣ３０４、ＰＤＣＰ３０６、ＲＲＣ３０８を、それぞれＮＲ用ＭＡＣ、ＮＲ用ＲＬＣ、ＮＲ用ＲＬＣ、及びＮＲ用ＲＲＣと呼ぶ事もある。
【００４３】
また、図１に示す通り、ｅＮＢ１０２、ｇＮＢ１０８、ＥＰＣ１０４、５ＧＣ１１０は、インタフェース１１２、インタフェース１１６、インタフェース１１８、インタフェース１２０、及びインタフェース１１４を介して繋がってもよい。このため、多様な通信システムに対応するため、図２のＲＲＣ２０８は、図３のＲＲＣ３０８に置き換えられてもよい。また図２のＰＤＣＰ２０６は、図３のＰＤＣＰ３０６に置き換えられても良い。また、図３のＲＲＣ３０８は、図２のＲＲＣ２０８の機能を含んでも良い。また図３のＰＤＣＰ３０６は、図２のＰＤＣＰ２０６であっても良い。  
【００４４】
（実施の形態）
図１から図７を用いて、本発明の実施の形態を説明する。
【００４５】
図４はＮＲにおいてＵＥ１２２がＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）でアップリンクデータを送信する際、またはＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）でダウンリンクデータを受信する際の、無線リソース割り当てを示すシーケンスチャートである。また図５は本発明の実施の形態におけるＵＥ１２２の構成を示すブロック図である。
【００４６】
ＵＥ１２２の受信部５００はｇＮＢ１０８からＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｎｅｌ）に含まれるＤＣＩ（Ｄｏｗｎｌｉｎｋ
Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を受信する（ステップＳ４００）。ＤＣＩにはデータ送信に必要な情報が含まれ、この情報の中には、この送信に対し、最大何ビットのデータ送信が可能かを示す伝送ブロックサイズ（Ｔｒａｎｓｐｏｒｔ  Ｂｌｏｃｋ  Ｓｉｚｅ）の決定に必要な情報が含まれる。ＵＥ１２２の処理部５０２は上記情報から伝送ブロックサイズの決定に必要な数値を計算し、あらかじめ決められた伝送ブロックサイズのテーブルより、計算した数値より少なくない伝送ブロックサイズの中で最も近いものを選び、伝送ブロックサイズを決定する（ステップＳ４０２）。ＤＣＩは、ダウンリンクリソース割り当て用と、アップリンクリソース割り当て用がある。ダウンリンクリソース
割り当て用のＤＣＩを受信した場合は、決定された伝送ブロックサイズに基づいて、ＰＤＳＣＨをデコードする。  アップリンクリソース割り当て用のＤＣＩを受信した場合は、決定された伝送ブロックサイズに基づいて、ＰＵＳＣＨを送信する。
【００４７】
伝送ブロックサイズは仕様によって決定されていて、Ｅ−ＵＴＲＡの伝送ブロックサイズは非特許文献８に、ＮＲの伝送ブロックサイズは非特許文献９に記載されている。伝送ブロックサイズの中にはＶｏＩＰ向けに設計されたものもあり、例えば非特許文献８の伝送ブロックサイズのテーブル中に頻出する１４４ビット、３２８ビットなどがＶｏＩＰ用に相当する。
【００４８】
Ｅ−ＵＴＲＡの際のＶｏＩＰ向け伝送ブロックサイズの決定方法は、音声データ１フレーム分に対するＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）ペイロード長（音声データ１フレーム長＋ＲＴＰペイロードフォーマットオーバーヘッド＋パディング（ｐａｄｄｉｎｇ））＋ＲｏＨＣヘッダ長＋Ｅ−ＵＴＲＡプロトコルヘッダ長＋２バイトで計算されていた（非特許文献１７）。
【００４９】
ここでＲｏＨＣヘッダ長に関しては、有音区間の１音声フレームに対し３バイト、無音区間のＳＩＤ（Ｓｉｌｅｎｃｅ  Ｉｎｓｅｒｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に対し６バイトとして計算されていた。またＥ−ＵＴＲＡプロトコルオーバーヘッドとしては、最小値である３バイト（ＰＤＣＰ２０６において１バイト、ＲＬＣ２０４において１バイト、ＭＡＣ２０２において１バイト）として計算されていた。
【００５０】
図６は３ＧＰＰのＶｏＩＰサービスにおいて必須の音声コーデックである、ＡＭＲ（Ａｄａｐｔｉｖｅ  Ｍｕｌｔｉ Ｒａｔｅ）コーデック及びＡＭＲ−ＷＢ（ＡＭＲ−Ｗｉｄ
ｅＢａｎｄ）コーデックのＳＩＤ及び各ビットレートにおけるデータ長を、ＩＥＴＦ  ＲＦＣ４８６７に記載の２つのＲＴＰペイロードフォーマットである、Ｂａｎｄｗｉｄｔｈ−Ｅｆｆｉｃｉｅｎｔ（ＢＥ）モード及びＯｃｔｅｔ−Ａｌｉｇｎｅｄ（ＯＡ）モードそれぞれにおいて計算したテーブルで、単位はビット（ｂｉｔｓ）で表している。Ｅ−ＵＴＲＡでのＶｏＩＰ向け伝送ブロックサイズを決定するにあたり、ＲＴＰペイロードフォーマットは１０ビットのオーバーヘッドが付加されるＢＥモードが想定された。
【００５１】
しかしながら、実際のサービスにおいては、実装インパクトの少なくＢＥモードより１バイト大きいＯＡモードの利用や、２バイトのＰＤＣＰヘッダの利用、また、伝搬状況の良い場所ではデータ２フレームを一つの伝送ブロックとして送るなどを採用する通信事業者もあり、ＶｏＩＰ用に決定された伝送ブロックサイズが利用される例が少なかった。
【００５２】
現在、３ＧＰＰにおいてＮＲでのＶｏＩＰサービス用の伝送ブロックサイズの決定が議論されている。本発明の実施の形態では、Ｅ−ＵＴＲＡでのＶｏＩＰ用伝送ブロックサイズの算出方法を踏襲すると共に、音声コーデックの種類やＲＴＰペイロードフォーマットの種類、及びデータ２フレームを一つの伝送ブロックとして送る場合を考慮したＮＲのＶｏＩＰ用伝送ブロックサイズの計算及び決定を行う。
【００５３】
１フレームを１つの伝送ブロックで送る場合のサイズの計算方法は、Ｅ−ＵＴＲＡと同じ、音声データ１フレーム分に対するＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ
Ｐｒｏｔｏｃｏｌ）ペイロード長（音声データ１フレーム長＋ＲＴＰペイロードフォーマットオーバーヘッド＋パディング（ｐａｄｄｉｎｇ））＋ＲｏＨＣヘッダ長＋ＮＲプロトコルヘッダ長＋２バイトでよい。
【００５４】
ＲｏＨＣヘッダ長はＥ−ＵＴＲＡと同じく、有音区間の１音声フレームに対し３バイト、無音区間のＳＩＤ（Ｓｉｌｅｎｃｅ  Ｉｎｓｅｒｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）
に対し６バイトとして計算しても良い。
【００５５】
ＮＲプロトコルヘッダ長の最小値は、ＳＤＡＰ３１０において０バイト、ＰＤＣＰ３０６において２バイト、ＲＬＣ３０４において１バイト、ＭＡＣ３０２において２バイトであり、この合計５バイトを用いて良い。
【００５６】
図７は３ＧＰＰのＶｏＩＰサービスにおいて別の必須コーデックである、ＥＶＳ（Ｅｎｈａｎｃｅｄ  Ｖｏｉｃｅ  Ｓｅｒｖｉｃｅｓ）コーデックのプライマリモードにおけるＳＩＤ及び各ビットレートにおけるデータ長を、非特許文献１５に記載のペイロードフォーマットである、コンパクトフォーマット、ヘッダフルフォーマット（Ｃｏｄｅｃ  Ｍｏｄｅ  Ｒｅｑｕｅｓｔ（ＣＭＲ）バイト無し）及びヘッダフルフォーマット（Ｃｏｄｅｃ
Ｍｏｄｅ  Ｒｅｑｕｅｓｔ（ＣＭＲ）バイト有り）それぞれにおいて計算したテーブルで、単位はビット（ｂｉｔｓ）で表している。
【００５７】
図６、図７のうち、特に実運用上で利用され、重要なＲＴＰペイロードサイズは、ＡＭＲコーデック及びＡＭＲ−ＷＢコーデックのＳＩＤである５６ビット、ＥＶＳプライマリモードコンパクトフォーマットＳＩＤである４８ビット、ＡＭＲ−ＷＢ１２．６５ｋｂｐｓ  ＢＥモード及びＥＶＳプライマリ１３．２ｋｂｐｓコンパクトフォーマットである２６４ビット、及びＡＭＲ−ＷＢ１２．６５ｋｂｐｓ  ＯＡモードである２７２ビットである。上記ビットに、上記１フレームを一つの伝送ブロックで送信する場合のＮＲのＶｏＩＰ向け伝送ブロックサイズの算出方法、を適用させると、ＳＩＤ５６ビットにはＲｏＨＣ６バイト（４８ビット）、ＮＲプロトコルヘッダ長５バイト（４０ビット）及び２バイト（１６ビット）が加算され、１６０ビットとなる。またＳＩＤ４８ビットには同じくＲｏＨＣ６バイト（４８ビット）、ＮＲプロトコルヘッダ長５バイト（４０ビット）及び２バイト（１６ビット）が加算され１５２ビットとなる。また有音区間の音声データ２６４ビットには、ＲｏＨＣ３バイト（２４ビット）、ＮＲプロトコルヘッダ長５バイト（４０ビット）及び２バイト（１６ビット）が加算され、３４４ビットとなる。また有音区間の音声データ２７２ビットには、同じくＲｏＨＣ３バイト（２４ビット）、ＮＲプロトコルヘッダ長５バイト（４０ビット）及び２バイト（１６ビット）が加算され、３５２ビットとなる。
【００５８】
即ち、ＮＲのＶｏＩＰサービスにおいて、１フレームを１つの伝送ブロックで送る場合に好適な伝送ブロックサイズは、１５２ビット、１６０ビット、３４４ビット、及び３５２ビットとなる。
【００５９】
また、有音区間の音声データ２６４ビット及び２７２ビットは、ＮＲのＭＡＣ３０２において２フレーム分がまとめられ、１つの伝送ブロックで送られる事が想定される。この場合、有音区間の音声データ長、ＲｏＨＣヘッダ長、及びＮＲプロトコルヘッダ長がそれぞれ２倍され、これに２バイトが加算される計算となる。即ち有音区間の音声データ２６４ビットに対し、倍の５２８ビットに、ＲｏＨＣヘッダ長２倍の６バイト（４８ビット）、ＮＲプロトコルヘッダ長２倍の１０ビット（８０ビット）、及び２バイト（１６ビット）が加算され、６７２ビットとなる。また、有音区間の音声データ２７２ビットに対し、倍の５４４ビットに、ＲｏＨＣヘッダ長２倍の６バイト（４８ビット）、ＮＲプロトコルヘッダ長２倍の１０ビット（８０ビット）、及び２バイト（１６ビット）が加算され、６８８ビットとなる。
【００６０】
即ち、ＮＲのＶｏＩＰサービスにおいて、２フレームを１つの伝送ブロックで送る場合に好適な伝送ブロックサイズは、６７２ビット、及び６８８ビットとなる。
【００６１】
このように、本発明の実施の形態では、端末装置は、伝送ブロックサイズのテーブルに
、１５２ビット、１６０ビット、３４４ビット、３５２ビット、６７２ビット、及び６８８ビットを持つ事により、効率的な通信を行うことができる。
【００６２】
なお、今後の様々なＶｏＩＰサービス形態を考慮にいれた場合、図７のＥＶＳプライマリモード１３．２Ｋｂｐｓ以下のコンパクトフォーマット及びＣＭＲバイト付きヘッダフルフォーマットにおいて、伝送ブロックサイズが用意される事が望ましい。これは例えば非特許文献７に記載のＲＡＮ  ａｓｓｉｓｔｅｄ  Ｃｏｄｅｃ  Ｒａｔｅ  Ａｄａｐｔａｔｉｏｎや、非特許文献１５に記載のＥＶＳ  Ｃｈａｎｎｅｌ Ａｗａｒｅ  Ｍｏｄｅな
どのサービスを考えた場合である。図８にＥＶＳプライマリモード１３．２Ｋｂｐｓ以下のコンパクトフォーマット及びＣＭＲバイト付きヘッダフルフォーマットに対する伝送ブロックサイズを示す。即ち図８によると、伝送ブロックサイズのテーブルに、更に１３６ビット、１６８ビット、２２４ビット、２４０ビット、２４８ビット、２５６ビット、２７２ビット、２８８ビット、及び３６０ビットが存在するのが望ましい。
【００６３】
また、本発明の実施の形態において、ＮＲのＶｏＩＰサービスにおける好適な伝送ブロックサイズ及びその算出方法について説明したが、本算出方法は、Ｅ−ＵＴＲＡ（ＬＴＥ）のＶｏＩＰサービスにおける伝送ブロックサイズの最適化に用いられても良い。
【００６４】
例えば、上述の通り図６、図７のうち、特に実運用上で利用され、重要なＲＴＰペイロードサイズは、ＡＭＲコーデック及びＡＭＲ−ＷＢコーデックのＳＩＤである５６ビット、ＥＶＳプライマリモードコンパクトフォーマットＳＩＤである４８ビット、ＡＭＲ−ＷＢ１２．６５ｋｂｐｓ  ＢＥモード及びＥＶＳプライマリ１３．２ｋｂｐｓコンパクトフォーマットである２６４ビット、及びＡＭＲ−ＷＢ１２．６５ｋｂｐｓ  ＯＡモードである２７２ビットである。これに、１フレームを１伝送ブロックで送る場合のＥ−ＵＴＲＡプロトコルオーバーヘッドを、４バイト（ＰＤＣＰ２０６において２バイト、ＲＬＣ２０４において１バイト、ＭＡＣ２０２において１バイト）として計算し、これに上述のＲｏＨＣオーバーヘッド（ＳＩＤフレームに対し６バイト、音声フレームに対し３バイト）及び２バイトを加算し、１５２ビット、１４４ビット、３３６ビット、及び３４４ビットの伝送ブロックサイズを算出する。よって、Ｅ−ＵＴＲＡの伝送ブロックサイズとして１５２ビット、１４４ビット、３３６ビット、及び３４４ビットが複数用意されても良い。
【００６５】
更に、音声フレーム２６４ビット、及び２７２ビットに対し、２フレームが１伝送ブロックで送られる場合において、Ｅ−ＵＴＲＡではＲＬＣ２０４で２フレームが連結（Ｃｏｎｃａｔｅｎａｔｅ）される事になり、この際のＲＬＣ２０４におけるオーバーヘッドは４バイトとなる（非特許文献６）。従って、この場合、有音区間の音声データ長、ＲｏＨＣヘッダ長、及びＰＤＣＰヘッダ長がそれぞれ２倍され、これに４バイトのＲＬＣヘッダ、１バイトのＭＡＣヘッダ、及び２バイトが加算される計算となる。即ち有音区間の音声データ２６４ビットに対し、倍の５２８ビットに、ＲｏＨＣヘッダ長２倍の６バイト（４８ビット）、ＰＤＣＰヘッダ長２倍の４バイト（３２ビット）、ＲＬＣヘッダ長４バイト（３２ビット）、ＭＡＣヘッダ長１バイト（８ビット）、及び２バイト（１６ビット）が加算され、６８０ビットとなる。また、有音区間の音声データ２７２ビットに対し、倍の５４４ビットに、ＲｏＨＣヘッダ長２倍の６バイト（４８ビット）、ＰＤＣＰヘッダ長２倍の４バイト（３２ビット）、ＲＬＣヘッダ長４バイト（３２ビット）、ＭＡＣヘッダ長１バイト（８ビット）、及び２バイト（１６ビット）が加算され、６９６ビットとなる。よって、Ｅ−ＵＴＲＡの伝送ブロックサイズとして６８０ビット、６９６ビットが複数用意されても良い。
【００６６】
本発明に関わる装置で動作するプログラムは、本発明に関わる上述した実施形態の機能を実現するように、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）等を制御してコンピュ−タを機能させるプログラムであっても良い。プログラムあるいはプログ
ラムによって取り扱われる情報は、処理時に一時的にＲａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）などの揮発性メモリに読み込まれ、あるいはフラッシュメモリなどの不揮発性メモリやＨａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ（ＨＤＤ）に格納され、必要に応じてＣＰＵによって読み出し、修正・書き込みが行なわれる。
【００６７】
なお、上述した実施形態における装置の一部、をコンピュ−タで実現するようにしてもよい。その場合、この制御機能を実現するためのプログラムをコンピュ−タが読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュ−タシステムに読み込ませ、実行することによって実現してもよい。ここでいう「コンピュ−タシステム」とは、装置に内蔵されたコンピュ−タシステムであって、オペレ−ティングシステムや周辺機器等のハ−ドウェアを含むものとする。また、「コンピュ−タが読み取り可能な記録媒体」とは、半導体記録媒体、光記録媒体、磁気記録媒体等のいずれであってもよい。
【００６８】
さらに「コンピュ−タが読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュ−タシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュ−タシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【００６９】
また、上述した実施形態に用いた装置の各機能ブロック、または諸特徴は、電気回路、すなわち典型的には集積回路あるいは複数の集積回路で実装または実行され得る。本明細書で述べられた機能を実行するように設計された電気回路は、汎用用途プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェア部品、またはこれらを組み合わせたものを含んでよい。汎用用途プロセッサは、マイクロプロセッサであってもよいし、代わりにプロセッサは従来型のプロセッサ、コントロ−ラ、マイクロコントロ−ラ、またはステ−トマシンであってもよい。汎用用途プロセッサ、または前述した各回路は、デジタル回路で構成されていてもよいし、アナログ回路で構成されていてもよい。また、半導体技術の進歩により現在の集積回路に代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いることも可能である。
【００７０】
なお、本願発明は上述の実施形態に限定されるものではない。実施形態では、装置の一例を記載したが、本願発明は、これに限定されるものではなく、屋内外に設置される据え置き型、または非可動型の電子機器、たとえば、ＡＶ機器、キッチン機器、掃除・洗濯機器、空調機器、オフィス機器、自動販売機、その他生活機器などの端末装置もしくは通信装置に適用出来る。
【００７１】
以上、この発明の実施形態に関して図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。また、本発明は、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。また、上記実施形態に記載された要素であり、同様の効果を奏する要素同士を置換した構成も含まれる。
【符号の説明】
【００７２】
１００  Ｅ−ＵＴＲＡ
１０２  ｅＮＢ
１０４  ＥＰＣ
１０６  ＮＲ
１０８  ｇＮＢ
１１０  ５ＧＣ
１１２、１１４、１１６，１１８、１２０、１２４  インタフェース
１２２  ＵＥ
２００、３００  ＰＨＹ
２０２、３０２  ＭＡＣ
２０４、３０４  ＲＬＣ
２０６、３０６  ＰＤＣＰ
２０８、３０８  ＲＲＣ
３１０  ＳＤＡＰ
５００  受信部
５０２  処理部
【図１】
2019121830.tif 000003
【図２】
2019121830.tif 000004
【図３】
2019121830.tif 000005
【図４】
2019121830.tif 000006
【図５】
2019121830.tif 000007
【図６】
2019121830.tif 000008
【図７】
2019121830.tif 000009
【図８】
2019121830.tif 000010