JP2003505961A - パケット交換網において同じユーザからの多数のパケットのための単一ヘッダ符号化 - Google Patents
パケット交換網において同じユーザからの多数のパケットのための単一ヘッダ符号化Info
- Publication number
- JP2003505961A JP2003505961A JP2001512353A JP2001512353A JP2003505961A JP 2003505961 A JP2003505961 A JP 2003505961A JP 2001512353 A JP2001512353 A JP 2001512353A JP 2001512353 A JP2001512353 A JP 2001512353A JP 2003505961 A JP2003505961 A JP 2003505961A
- Authority
- JP
- Japan
- Prior art keywords
- bits
- header
- block
- class
- bit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 71
- 230000005540 biological transmission Effects 0.000 claims description 51
- 229910000831 Steel Inorganic materials 0.000 claims description 4
- 239000010959 steel Substances 0.000 claims description 4
- 238000012937 correction Methods 0.000 description 24
- 125000004122 cyclic group Chemical group 0.000 description 24
- 238000010586 diagram Methods 0.000 description 22
- 108091006146 Channels Proteins 0.000 description 19
- 238000001514 detection method Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 208000011580 syndromic disease Diseases 0.000 description 5
- 230000006872 improvement Effects 0.000 description 4
- 238000004088 simulation Methods 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 238000010295 mobile communication Methods 0.000 description 3
- 238000012549 training Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0067—Rate matching
- H04L1/0068—Rate matching by puncturing
- H04L1/0069—Puncturing patterns
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0064—Concatenated codes
- H04L1/0065—Serial concatenated codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/007—Unequal error protection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0072—Error control for data other than payload data, e.g. control data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0057—Block codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0059—Convolutional codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0071—Use of interleaving
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L2001/0098—Unequal error protection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Error Detection And Correction (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Time-Division Multiplex Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
(57)【要約】
パケット交換網において、少なくとも2つのパケットを1つのブロックに符号化する方法が開示される。各パケットはヘッダ部に関連付けられる。少なくとも2つのパケットは同じユーザに関連付けられる。その方法は、少なくとも2つのパケットと、関連付けられたヘッダ部のうちの1つのみとを符号化するステップを含む。そのような方法を用いるEDGEネットワークも開示される。
Description
【0001】
〔発明の分野〕
本発明は、パケット交換網におけるパケットの符号化に関し、詳細には、限定
はしないが、EDGEネットワークにおける音声を含むパケットの符号化に関す
る。 〔発明の背景〕
はしないが、EDGEネットワークにおける音声を含むパケットの符号化に関す
る。 〔発明の背景〕
【0002】
近年、GSM(Global System for Mobile Communication:移動体通信のため
のグローバルシステム)、およびDAMPS(Digital Advanced Mobile System
:高度デジタル移動体通信システム)のような音声のためのデジタル移動体通信
システムが非常に急速に普及してきた。
のグローバルシステム)、およびDAMPS(Digital Advanced Mobile System
:高度デジタル移動体通信システム)のような音声のためのデジタル移動体通信
システムが非常に急速に普及してきた。
【0003】
さらに、インターネットが幅広く受け入れられてきたことに起因して、移動体
ユーザによる、データサービスへの多くの要求が生み出されてきた。GPRS(
General Packet Radio Service:汎用パケット無線サービス)、EDGE(enha
nced data rate of GSM:GSM進化型高速データ伝送)およびUMTS(Unive
rsal Mobile Telecommunication Service:ユニバーサル移動体電気通信サービ
ス)は全て、無線ネットワークにおいて、データユーザを収容するために開発中
である。
ユーザによる、データサービスへの多くの要求が生み出されてきた。GPRS(
General Packet Radio Service:汎用パケット無線サービス)、EDGE(enha
nced data rate of GSM:GSM進化型高速データ伝送)およびUMTS(Unive
rsal Mobile Telecommunication Service:ユニバーサル移動体電気通信サービ
ス)は全て、無線ネットワークにおいて、データユーザを収容するために開発中
である。
【0004】
近年、固定のパケット交換網上での音声伝送のための方式も開発されており、
将来には、増加の一途をたどっている音声トラフィック量がパケット交換網上で
搬送されることになるであろう。
将来には、増加の一途をたどっている音声トラフィック量がパケット交換網上で
搬送されることになるであろう。
【0005】
GSM進化型高速データ伝送(EDGE)は、より高速のデータ伝送速度を利
用可能にし、これらのネットワークの容量を増加する目的で、既存の時分割多元
接続(TDMA)無線セルラーシステムを進化させるために提案されたものであ
る。EDGEの適用範囲は、GSMセルラーネットワークに止まらず、UWCC
(Universal Wireless Communications Consortium:ユニバーサル無線通信コン
ソーシアム)によるIS−136システムを進化させるためにも受け入れられて
きた。高速データ伝送は、8−PSK(位相変調)のような、より高いレベルの
変調形式を導入することにより達成される。そのような変調方式の導入により、
EDGEシステムは、標準的なGSM/GPRS/IS−136システムに比べ
て、約3倍までのビット速度を提供することができる。
用可能にし、これらのネットワークの容量を増加する目的で、既存の時分割多元
接続(TDMA)無線セルラーシステムを進化させるために提案されたものであ
る。EDGEの適用範囲は、GSMセルラーネットワークに止まらず、UWCC
(Universal Wireless Communications Consortium:ユニバーサル無線通信コン
ソーシアム)によるIS−136システムを進化させるためにも受け入れられて
きた。高速データ伝送は、8−PSK(位相変調)のような、より高いレベルの
変調形式を導入することにより達成される。そのような変調方式の導入により、
EDGEシステムは、標準的なGSM/GPRS/IS−136システムに比べ
て、約3倍までのビット速度を提供することができる。
【0006】
EDGEは最初に、2値GMSKの代わりに多相変調(たとえば、8−PSK
)を利用することにより、GSMあるいはGPRSより高い速度でデータサービ
スを提供するために開発された。しかしながら、データ伝送のために提案された
RLC/MACブロックの構造は、音声伝送のために利用可能な無線リソースを
効率的に利用することを考慮していない。さらに、8−PSKの使用に起因して
、ある一定レベルの音声品質を保持するために、より強力なチャネル符号化が必
要とされる。
)を利用することにより、GSMあるいはGPRSより高い速度でデータサービ
スを提供するために開発された。しかしながら、データ伝送のために提案された
RLC/MACブロックの構造は、音声伝送のために利用可能な無線リソースを
効率的に利用することを考慮していない。さらに、8−PSKの使用に起因して
、ある一定レベルの音声品質を保持するために、より強力なチャネル符号化が必
要とされる。
【0007】
より強力なチャネル符号化技術を用いると、より多くの符号化されたビットが
生成される。符号化されたビットの数が利用可能なビット空間の数を超える場合
には、ある一定のビットを除去するために、通常、パンクチャ(ビット削除)処
理が適用される。それゆえ、強力なチャネル符号化技術を実現することと、パン
クチャ処理されるビットの数を最小限にすることとの間には、性能上のトレード
オフが存在する。
生成される。符号化されたビットの数が利用可能なビット空間の数を超える場合
には、ある一定のビットを除去するために、通常、パンクチャ(ビット削除)処
理が適用される。それゆえ、強力なチャネル符号化技術を実現することと、パン
クチャ処理されるビットの数を最小限にすることとの間には、性能上のトレード
オフが存在する。
【0008】
それゆえ、本発明の目的は、EDGEネットワークにおいて、音声を効率的に
チャネル符号化するのに適した、改善された符号化技術を提供することである。
チャネル符号化するのに適した、改善された符号化技術を提供することである。
【0009】
〔発明の概要〕
本発明によれば、パケット交換網において、少なくとも2つのパケットを1つ
のブロックに符号化する方法が提供され、その方法では、各パケットはヘッダ部
に関連付けられ、少なくとも2つのパケットが同じユーザに関連付けられ、その
方法は、少なくとも2つのパケットと、関連付けられたヘッダ部のうちの1つの
みとを符号化するステップを含む。
のブロックに符号化する方法が提供され、その方法では、各パケットはヘッダ部
に関連付けられ、少なくとも2つのパケットが同じユーザに関連付けられ、その
方法は、少なくとも2つのパケットと、関連付けられたヘッダ部のうちの1つの
みとを符号化するステップを含む。
【0010】
少なくとも2つのパケットは、スピーチフレームを含むペイロード部と、スピ
ーチヘッダとを有することが好ましい。各スピーチフレームは1組のクラスIビ
ットと、1組のクラスIIビットとを含む場合があり、その方法は、1組のクラ
スIビットを符号化することにより第1のスピーチフレームを符号化するステッ
プと、1組のクラスIビットを符号化することにより第2のスピーチフレームを
符号化するステップと、ヘッダの少なくとも一部を符号化するステップとを含む
。
ーチヘッダとを有することが好ましい。各スピーチフレームは1組のクラスIビ
ットと、1組のクラスIIビットとを含む場合があり、その方法は、1組のクラ
スIビットを符号化することにより第1のスピーチフレームを符号化するステッ
プと、1組のクラスIビットを符号化することにより第2のスピーチフレームを
符号化するステップと、ヘッダの少なくとも一部を符号化するステップとを含む
。
【0011】
そのスピーチフレームは、無線パケット交換網のダウンリンク上で伝送するた
めのものである場合があり、その場合に各符号化ステップは、2つの異なる符号
化技術を用いて、ヘッダの2つの異なる部分を符号化するステップを含む。クラ
スIビットおよびヘッダの一部は、たたみ込み符号を用いて符号化される場合が
ある。たたみ込み符号として、3,1,7たたみ込み符号を用いることができる
。ヘッダの残りの部分は、ブロック符号を用いて符号化されることができる。ブ
ロック符号は36,3ブロック符号である。
めのものである場合があり、その場合に各符号化ステップは、2つの異なる符号
化技術を用いて、ヘッダの2つの異なる部分を符号化するステップを含む。クラ
スIビットおよびヘッダの一部は、たたみ込み符号を用いて符号化される場合が
ある。たたみ込み符号として、3,1,7たたみ込み符号を用いることができる
。ヘッダの残りの部分は、ブロック符号を用いて符号化されることができる。ブ
ロック符号は36,3ブロック符号である。
【0012】
そのスピーチフレームは、無線パケット交換網のアップリンク上で伝送するた
めのものである場合があり、その場合にクラスIビットおよび共通ヘッダが、た
たみ込み符号を用いて符号化される。
めのものである場合があり、その場合にクラスIビットおよび共通ヘッダが、た
たみ込み符号を用いて符号化される。
【0013】
1つのブロックは、1組のスチールビットをさらに含む場合がある。その1つ
のブロックは1組のスペアビットを含む場合がある。そのブロックには、EDG
E RLC/MACブロックを用いることができる。
のブロックは1組のスペアビットを含む場合がある。そのブロックには、EDG
E RLC/MACブロックを用いることができる。
【0014】
ここで本発明は、添付の図面を参照しつつ、例を用いて記載されるであろう。
【0015】
〔好ましい実施形態の説明〕
GMS進化型高速データ伝送(EDGE)は、無線ネットワークにおいて、デ
ータパケットの伝送を可能にするために開発されてきた。データパケットの伝送
を可能にするネットワークは、従来からパケット交換網として知られている。E
DGEのようなパケット交換網では、データは、ヘッダおよびペイロードを含む
データパケットで伝送される。各データパケットは、無線リンク制御/媒体アク
セス制御(RLC/MAC)ブロックに符号化される。ペイロードは、データパ
ケットの情報部を含む。ヘッダは、データパケットに関連する制御およびルーテ
ィング情報を含む。たとえば、ヘッダは通常、データパケットの宛先アドレスと
、誤り検査情報と、パケットの受信に肯定応答し、必要に応じて、そのパケット
の再送を要求できるようにするための制御ビットとを含む。データパケット伝送
の1つの特徴は、ネットワーク内の受信機が、送信されたパケットの受信に成功
しない場合には、データパケットの再送が要求されることである。
ータパケットの伝送を可能にするために開発されてきた。データパケットの伝送
を可能にするネットワークは、従来からパケット交換網として知られている。E
DGEのようなパケット交換網では、データは、ヘッダおよびペイロードを含む
データパケットで伝送される。各データパケットは、無線リンク制御/媒体アク
セス制御(RLC/MAC)ブロックに符号化される。ペイロードは、データパ
ケットの情報部を含む。ヘッダは、データパケットに関連する制御およびルーテ
ィング情報を含む。たとえば、ヘッダは通常、データパケットの宛先アドレスと
、誤り検査情報と、パケットの受信に肯定応答し、必要に応じて、そのパケット
の再送を要求できるようにするための制御ビットとを含む。データパケット伝送
の1つの特徴は、ネットワーク内の受信機が、送信されたパケットの受信に成功
しない場合には、データパケットの再送が要求されることである。
【0016】
音声を送信する際には、データとは対照的に、伝送要件が異なる。たとえば、
音声伝送では、時間遅延に制限があるので、情報が再送されることは現実的では
ない。それゆえ、パケット交換網における音声伝送は、肯定応答されない音声パ
ケット伝送である。さらに、音声の場合、符号化された音声の種々のビットは異
なる重要度を有し、ある一定のビットが失われることが許容可能である。しかし
ながら、データでは、全ビットが等しく重要であるものと仮定され、それゆえ、
ビットは失われてはならない。
音声伝送では、時間遅延に制限があるので、情報が再送されることは現実的では
ない。それゆえ、パケット交換網における音声伝送は、肯定応答されない音声パ
ケット伝送である。さらに、音声の場合、符号化された音声の種々のビットは異
なる重要度を有し、ある一定のビットが失われることが許容可能である。しかし
ながら、データでは、全ビットが等しく重要であるものと仮定され、それゆえ、
ビットは失われてはならない。
【0017】
本明細書では、EDGEパケット交換網上で音声を伝送することが提案される
。これを達成するために、新しいRLC/MACブロック構造が提案され、その
中では、従来のEDGEヘッダが、音声伝送に対応するためだけに必要とされる
フィールドを含むように変更される。図1を参照すると、EDGE上で音声を伝
送するのに適した、新しいRLC/MACブロックヘッダの第1の実施形態が示
される。その新しいRLC/MACブロック構造は、EDGEのためのデータパ
ケットのヘッダと比べて、削減されたヘッダを含む。すなわち、ヘッダの長さは
、データパケットの伝送に必要とされる長さより短い。
。これを達成するために、新しいRLC/MACブロック構造が提案され、その
中では、従来のEDGEヘッダが、音声伝送に対応するためだけに必要とされる
フィールドを含むように変更される。図1を参照すると、EDGE上で音声を伝
送するのに適した、新しいRLC/MACブロックヘッダの第1の実施形態が示
される。その新しいRLC/MACブロック構造は、EDGEのためのデータパ
ケットのヘッダと比べて、削減されたヘッダを含む。すなわち、ヘッダの長さは
、データパケットの伝送に必要とされる長さより短い。
【0018】
したがって、EDGEネットワーク上で音声を送信するために、標準的なデー
タパケットのRLC/MACを変更することが提案される。その新しいブロック
は、ヘッダと、標準的なGSM音声符号化器を用いて符号化された符号化スピー
チビットからなるペイロードとを含む。
タパケットのRLC/MACを変更することが提案される。その新しいブロック
は、ヘッダと、標準的なGSM音声符号化器を用いて符号化された符号化スピー
チビットからなるペイロードとを含む。
【0019】
この新しいRLC/MACブロックは、知られている標準的なEDGEパケッ
トのブロックとは異なる態様で符号化される。この符号化の変更は、音声データ
の場合、種々のビットが異なる重要度を有するのに対して、データの場合、全て
のビットが同じ重要度を有するために必要とされる。
トのブロックとは異なる態様で符号化される。この符号化の変更は、音声データ
の場合、種々のビットが異なる重要度を有するのに対して、データの場合、全て
のビットが同じ重要度を有するために必要とされる。
【0020】
図1(a)は、RLC/MACブロックにチャネル符号化する前の、EDGE
ネットワークのダウンリンクにおける音声伝送のためのヘッダを示す。そのヘッ
ダ2は、アップリンクステータスフラグ(USF)フィールド4と、一時フロー
識別(TFI)フィールド6と、最終ブロック指示子(FBI)フィールド8と
を含む。USFフィールドは3ビットフィールドであり、TFIフィールドは7
ビットフィールドであり、FBIフィールドは1ビットフィールドである。これ
ら全てのフィールド、およびその長さは、EDGEが用いるGPRS標準規格に
よって定義され、削減されたヘッダ内のこれらのフィールドの機能は、データパ
ケット伝送のためにEDGEにおいて用いられる通常のヘッダと同じである。
ネットワークのダウンリンクにおける音声伝送のためのヘッダを示す。そのヘッ
ダ2は、アップリンクステータスフラグ(USF)フィールド4と、一時フロー
識別(TFI)フィールド6と、最終ブロック指示子(FBI)フィールド8と
を含む。USFフィールドは3ビットフィールドであり、TFIフィールドは7
ビットフィールドであり、FBIフィールドは1ビットフィールドである。これ
ら全てのフィールド、およびその長さは、EDGEが用いるGPRS標準規格に
よって定義され、削減されたヘッダ内のこれらのフィールドの機能は、データパ
ケット伝送のためにEDGEにおいて用いられる通常のヘッダと同じである。
【0021】
図1(b)は、EDGEネットワークのアップリンクにおいて音声を伝送する
ためのヘッダを示す。ヘッダ10は、一時フロー識別(TFI)フィールド12
と、スピーチフラグ(SF)フィールド14と、最終ブロック指示子(FBI)
フィールド16とを含む。TFIフィールドは7ビットフィールドであり、SF
フィールドは2ビットフィールドであり、FBIフィールドは1ビットフィール
ドである。スピーチフラグフィールドは、EDGEヘッダに新たに導入されてお
り、GPRSのS/Pビットに対応する。
ためのヘッダを示す。ヘッダ10は、一時フロー識別(TFI)フィールド12
と、スピーチフラグ(SF)フィールド14と、最終ブロック指示子(FBI)
フィールド16とを含む。TFIフィールドは7ビットフィールドであり、SF
フィールドは2ビットフィールドであり、FBIフィールドは1ビットフィール
ドである。スピーチフラグフィールドは、EDGEヘッダに新たに導入されてお
り、GPRSのS/Pビットに対応する。
【0022】
以下に説明されるような、EDGE上で音声を伝送するための1つの好ましい
実装形態では、各EDGE RLC/MACブロックは2つのスピーチフレーム
を含み、それゆえ、これらのフレームがそれぞれ無音に対応するか、音声に対応
するかを知らせるために、図1(b)のアップリンクヘッダに2つのスピーチフ
ラグが設けられることが好ましい。スピーチフラグフィールドは、RLC/MA
Cブロックに、より多くのスピーチフレームが含まれるか、より少ないスピーチ
フレームが含まれるかに応じて、増減される場合がある。
実装形態では、各EDGE RLC/MACブロックは2つのスピーチフレーム
を含み、それゆえ、これらのフレームがそれぞれ無音に対応するか、音声に対応
するかを知らせるために、図1(b)のアップリンクヘッダに2つのスピーチフ
ラグが設けられることが好ましい。スピーチフラグフィールドは、RLC/MA
Cブロックに、より多くのスピーチフレームが含まれるか、より少ないスピーチ
フレームが含まれるかに応じて、増減される場合がある。
【0023】
完全を期すために、図1のアップリンクおよびダウンリンクヘッダの各フィー
ルドの要約が以下に与えられるが、当業者には、これらのフィールドおよび機能
がよく知られているであろう。
ルドの要約が以下に与えられるが、当業者には、これらのフィールドおよび機能
がよく知られているであろう。
【0024】
USFフィールドは、移動局のアドレスを固有に指定するために用いられる。
具体的には、移動局がダウンリンクにおいてパケットを受信し、そのパケットヘ
ッダを読み取り、かつそのUSFを含むことを見いだすとき、これは、基地局が
、所定のタイムスロットにおいてアップリンク上で、この移動局にそのパケット
を伝送することの許可を与えたことを意味する。
具体的には、移動局がダウンリンクにおいてパケットを受信し、そのパケットヘ
ッダを読み取り、かつそのUSFを含むことを見いだすとき、これは、基地局が
、所定のタイムスロットにおいてアップリンク上で、この移動局にそのパケット
を伝送することの許可を与えたことを意味する。
【0025】
TFIフィールドは、データフローを固有に特定する。ある呼が確立されると
き、その呼は固有の番号を割り当てられる。移動局あるいは基地局がパケットを
受信し、そのヘッダを読み取るとき、TFIフィールドを読み取ることにより、
このパケットがどのデータフロー(呼)に属するかがわかる。
き、その呼は固有の番号を割り当てられる。移動局あるいは基地局がパケットを
受信し、そのヘッダを読み取るとき、TFIフィールドを読み取ることにより、
このパケットがどのデータフロー(呼)に属するかがわかる。
【0026】
SFフィールドが1に設定されるとき、スピーチフレームは音声に対応する。
SFフィールドが0に設定されるとき、そのスピーチフレームは無音に対応する
。
SFフィールドが0に設定されるとき、そのスピーチフレームは無音に対応する
。
【0027】
FBIフィールドが1に設定されるとき、これは、現在のデータフローが終了
することを受信機に示す。FBIが0に設定される場合には、これは、現在のデ
ータフローにおいて、さらに多くのパケットが送信されることになることを意味
する。
することを受信機に示す。FBIが0に設定される場合には、これは、現在のデ
ータフローにおいて、さらに多くのパケットが送信されることになることを意味
する。
【0028】
図2は、EDGE上で音声を伝送するための新しいヘッダの第2の実施形態を
示す。図2(a)は、巡回冗長検査(CRC)フィールド18に1組の誤り検査
ビットを含むようにさらに変更された、EDGEネットワークのアップリンクに
おいて音声を伝送するためのヘッダを示す。新しいヘッダ20は依然として、U
SFフィールド4と、TFIフィールド6と、FBIフィールド8とを含む。
示す。図2(a)は、巡回冗長検査(CRC)フィールド18に1組の誤り検査
ビットを含むようにさらに変更された、EDGEネットワークのアップリンクに
おいて音声を伝送するためのヘッダを示す。新しいヘッダ20は依然として、U
SFフィールド4と、TFIフィールド6と、FBIフィールド8とを含む。
【0029】
図2(b)は、同様に巡回冗長検査(CRC)フィールド22に1組の誤り検
査ビットを含むようにさらに変更された、EDGEネットワークのダウンリンク
において音声を伝送するためのヘッダを示す。新しいヘッダ24は依然として、
TFIフィールド12と、SFフィールド14と、FBIフィールド16とを含
む。誤り検査ビットを用意することにより、そのヘッダのための特別な保護が提
供される。図2(a)および図2(b)のヘッダは誤り検査のためにCRCフィ
ールドを参照して記載されるが、その応用形態に応じて、誤りの検出に適した任
意の他の誤り検査方式が用いられる場合があることは理解されよう。
査ビットを含むようにさらに変更された、EDGEネットワークのダウンリンク
において音声を伝送するためのヘッダを示す。新しいヘッダ24は依然として、
TFIフィールド12と、SFフィールド14と、FBIフィールド16とを含
む。誤り検査ビットを用意することにより、そのヘッダのための特別な保護が提
供される。図2(a)および図2(b)のヘッダは誤り検査のためにCRCフィ
ールドを参照して記載されるが、その応用形態に応じて、誤りの検出に適した任
意の他の誤り検査方式が用いられる場合があることは理解されよう。
【0030】
アップリンクヘッダおよびダウンリンクヘッダの両方におけるCRCフィール
ドのサイズは、そのシステムにおいて用いられる誤り符号に依存する。簡単な誤
り検査方式では、CRCフィールドは、ヘッダ内の他のフィールドに応じて生成
される。受信機側では、誤りフィールドが、受信されたヘッダに基づくCRCフ
ィールドの再計算値と比較され、誤りが検出される場合には、スピーチブロック
が破棄される。データ伝送では、これが標準的であり、元のパケットが破棄され
た後に、データパケットの再送が要求される場合がある。
ドのサイズは、そのシステムにおいて用いられる誤り符号に依存する。簡単な誤
り検査方式では、CRCフィールドは、ヘッダ内の他のフィールドに応じて生成
される。受信機側では、誤りフィールドが、受信されたヘッダに基づくCRCフ
ィールドの再計算値と比較され、誤りが検出される場合には、スピーチブロック
が破棄される。データ伝送では、これが標準的であり、元のパケットが破棄され
た後に、データパケットの再送が要求される場合がある。
【0031】
音声では、上記のように、再送は現実的ではない。パケット交換網において音
声が送信される場合には、標準的な誤り技術によって、ペイロード内の音声に誤
りがない場合であっても、ヘッダ内のみに誤りが存在すれば、スピーチブロック
は破棄されるようになる。
声が送信される場合には、標準的な誤り技術によって、ペイロード内の音声に誤
りがない場合であっても、ヘッダ内のみに誤りが存在すれば、スピーチブロック
は破棄されるようになる。
【0032】
それゆえ、ここでは、情報がヘッダおよびペイロードを含むブロックで送信さ
れる任意のネットワークに一般的に適用可能な、さらに新しいヘッダが提案され
る。ここで、この新しいヘッダは、図1および図2の他の実施形態を参照して記
載されるEDGE上の音声の場合のヘッダの第3の実施形態を参照して記載され
るが、実際にはその技術は、全てのパケット交換網、すなわち、パケットあるい
はブロックが音声を搬送するか、データを搬送するかにかかわらず、ヘッダ部と
ペイロードとを有するパケットあるいはブロックにおいて情報が搬送される環境
に適用可能であるということを認識されたい。
れる任意のネットワークに一般的に適用可能な、さらに新しいヘッダが提案され
る。ここで、この新しいヘッダは、図1および図2の他の実施形態を参照して記
載されるEDGE上の音声の場合のヘッダの第3の実施形態を参照して記載され
るが、実際にはその技術は、全てのパケット交換網、すなわち、パケットあるい
はブロックが音声を搬送するか、データを搬送するかにかかわらず、ヘッダ部と
ペイロードとを有するパケットあるいはブロックにおいて情報が搬送される環境
に適用可能であるということを認識されたい。
【0033】
この新しいヘッダの原理は、ヘッダに含まれるビットのみに応じて生成される
、ヘッダ内の誤りフィールドを提供することである。その際、この誤りフィール
ドは、ヘッダ内に任意の誤りが存在するか否かを判定するために、受信機端にお
いて用いられる。ヘッダ内に1つあるいは複数の誤りが存在する場合には、その
誤りフィールドの性質によって、受信機は、伝送中に導入された1つあるいは複
数の誤りを訂正するように試みることができるようになる。
、ヘッダ内の誤りフィールドを提供することである。その際、この誤りフィール
ドは、ヘッダ内に任意の誤りが存在するか否かを判定するために、受信機端にお
いて用いられる。ヘッダ内に1つあるいは複数の誤りが存在する場合には、その
誤りフィールドの性質によって、受信機は、伝送中に導入された1つあるいは複
数の誤りを訂正するように試みることができるようになる。
【0034】
これは、ペイロードに誤りが存在しない、あるいは許容可能な誤りを含むブロ
ックが自動的に破棄されないことを意味する。それゆえ、システム性能は、特に
パケット交換網において音声が伝送される場合に向上する。
ックが自動的に破棄されないことを意味する。それゆえ、システム性能は、特に
パケット交換網において音声が伝送される場合に向上する。
【0035】
それゆえ、図3(a)を参照すると、EDGE上で音声を伝送するためのアッ
プリンクヘッダは、誤り検査フィールドが巡回符号方式(CCS)フィールド2
8を含む、新しいヘッダ26を生成するようにさらに変更される。同様に、図3
(b)を参照すると、EDGE上で音声を伝送するためのダウンリンクヘッダは
、誤り検査フィールドが巡回符号方式(CCS)フィールド32を含む、新しい
ヘッダ30を生成するようにさらに変更されている。
プリンクヘッダは、誤り検査フィールドが巡回符号方式(CCS)フィールド2
8を含む、新しいヘッダ26を生成するようにさらに変更される。同様に、図3
(b)を参照すると、EDGE上で音声を伝送するためのダウンリンクヘッダは
、誤り検査フィールドが巡回符号方式(CCS)フィールド32を含む、新しい
ヘッダ30を生成するようにさらに変更されている。
【0036】
EDGEネットワークのためのアップリンクの場合のヘッダ26では、ヘッダ
を保護するために、以下の生成多項式を有する、15,10巡回符号が用いられ
ることが好ましい。 g(D)=D5+D4+D2+1 したがって、ヘッダの元の9ビットから、15ビットヘッダが生成される。標準
的なEDGEによれば、FBIビットは、CCSフィールドの計算には含まれな
い。そのような巡回符号はよく知られており、当業者の理解の範囲内にある。こ
のブロック符号は、2バースト誤り訂正能力と、1ランダム誤り訂正能力とを有
する。それは、3つまでのランダム誤りを検出することができる。それは、長さ
5以下の全てのバースト誤りパターンを検出することができる。6に等しい長さ
の検出されない誤りパターンの小数部は0.0625である。6より大きい長さ
の検出されない誤りパターンの小数部は0.03125である。その符号は4の
最小距離を有し、長さ15および次元10で知られる最良の符号である。
を保護するために、以下の生成多項式を有する、15,10巡回符号が用いられ
ることが好ましい。 g(D)=D5+D4+D2+1 したがって、ヘッダの元の9ビットから、15ビットヘッダが生成される。標準
的なEDGEによれば、FBIビットは、CCSフィールドの計算には含まれな
い。そのような巡回符号はよく知られており、当業者の理解の範囲内にある。こ
のブロック符号は、2バースト誤り訂正能力と、1ランダム誤り訂正能力とを有
する。それは、3つまでのランダム誤りを検出することができる。それは、長さ
5以下の全てのバースト誤りパターンを検出することができる。6に等しい長さ
の検出されない誤りパターンの小数部は0.0625である。6より大きい長さ
の検出されない誤りパターンの小数部は0.03125である。その符号は4の
最小距離を有し、長さ15および次元10で知られる最良の符号である。
【0037】
EDGEネットワークのためのダウンリンクの場合のヘッダ30では、ヘッダ
を保護するために、以下の生成多項式を有する、15,9巡回符号が用いられる
ことが好ましい。 g(D)=D6+D5+D4+D3+1 したがって、ヘッダの元の10ビットから、15ビットヘッダが生成される。標
準的なEDGEによれば、再びFBIビットは、CCSフィールドの計算には含
まれない。このブロック符号は、3バースト誤り訂正能力と、1ランダム誤り訂
正能力とを有する。それは、2つまでのランダム誤りを検出することもできる。
それは、長さ6までの全ての誤りパターンを検出することができる。7に等しい
長さの検出されない誤りパターンの小数部は0.03125である。8以上の長
さの検出されない誤りパターンの小数部は0.015625である。TFIおよ
びSFフィールドは良好に保護され、3バースト誤り訂正能力を有するこの符号
を用いる場合、誤りの確率は著しく低減されるということは明らかである。
を保護するために、以下の生成多項式を有する、15,9巡回符号が用いられる
ことが好ましい。 g(D)=D6+D5+D4+D3+1 したがって、ヘッダの元の10ビットから、15ビットヘッダが生成される。標
準的なEDGEによれば、再びFBIビットは、CCSフィールドの計算には含
まれない。このブロック符号は、3バースト誤り訂正能力と、1ランダム誤り訂
正能力とを有する。それは、2つまでのランダム誤りを検出することもできる。
それは、長さ6までの全ての誤りパターンを検出することができる。7に等しい
長さの検出されない誤りパターンの小数部は0.03125である。8以上の長
さの検出されない誤りパターンの小数部は0.015625である。TFIおよ
びSFフィールドは良好に保護され、3バースト誤り訂正能力を有するこの符号
を用いる場合、誤りの確率は著しく低減されるということは明らかである。
【0038】
符号語の受信時に受信機において行われる計算の結果であるシンドロームは、
誤り訂正を用いないヘッダの場合に計算されるであろう。シンドローム値が0で
ある場合には、これは、その符号語が誤りを含まないことを示す。シンドローム
が計算される態様は、用いられる特定の符号に依存する。したがって、RLCブ
ロックは、そのシンドロームが正しい場合には、受け入れられるであろう。その
シンドロームが間違っている場合には、誤り訂正のためにヘッダが送られるであ
ろう。誤りの数が符号誤り訂正能力を超えているため、誤り訂正器によっても依
然としてヘッダに誤りが存在する場合には、そのRLCブロックは破棄されるで
あろう。誤り訂正器が、誤り訂正後にヘッダ内に誤りが存在しないことを示すと
き、RLCブロックは受け入れられ、ヘッダ内の全ての誤りが訂正されたことに
なる。
誤り訂正を用いないヘッダの場合に計算されるであろう。シンドローム値が0で
ある場合には、これは、その符号語が誤りを含まないことを示す。シンドローム
が計算される態様は、用いられる特定の符号に依存する。したがって、RLCブ
ロックは、そのシンドロームが正しい場合には、受け入れられるであろう。その
シンドロームが間違っている場合には、誤り訂正のためにヘッダが送られるであ
ろう。誤りの数が符号誤り訂正能力を超えているため、誤り訂正器によっても依
然としてヘッダに誤りが存在する場合には、そのRLCブロックは破棄されるで
あろう。誤り訂正器が、誤り訂正後にヘッダ内に誤りが存在しないことを示すと
き、RLCブロックは受け入れられ、ヘッダ内の全ての誤りが訂正されたことに
なる。
【0039】
図4は、ダウンリンクおよびアップリンクにおける性能結果のシミュレーショ
ンを示しており、誤り訂正を用いる場合、用いない場合の性能を比較する。その
シミュレーションでは、そのシステムは干渉がないものと想定され、全ての結果
が、dBで表された搬送波対干渉比の関数として提示される。典型的な市街地(
TU)伝搬条件が想定され、移動局は時速3kmの速度を有する。理想的な周波
数ホッピングが用いられる。このシミュレーション中に、誤り訂正が用いられた
場合の欠落したヘッダの数と、誤り訂正が用いられない場合の欠落したヘッダの
数とが計算された。全ての場合に、5000RLC/MACブロック伝送の全数
がシミュレートされた。
ンを示しており、誤り訂正を用いる場合、用いない場合の性能を比較する。その
シミュレーションでは、そのシステムは干渉がないものと想定され、全ての結果
が、dBで表された搬送波対干渉比の関数として提示される。典型的な市街地(
TU)伝搬条件が想定され、移動局は時速3kmの速度を有する。理想的な周波
数ホッピングが用いられる。このシミュレーション中に、誤り訂正が用いられた
場合の欠落したヘッダの数と、誤り訂正が用いられない場合の欠落したヘッダの
数とが計算された。全ての場合に、5000RLC/MACブロック伝送の全数
がシミュレートされた。
【0040】
図4(a)および図4(b)の両方において、性能表は4欄を有する。第1の
欄34は、上記のような搬送波対干渉波比を示し、第2の欄36は、誤り訂正を
用いない場合の欠落したヘッダの数を示し、第3の欄38は、誤り訂正を用いる
場合の欠落したヘッダの数を示し、第4の欄40は、新しい技術を用いることに
より得られる改善率を示す。
欄34は、上記のような搬送波対干渉波比を示し、第2の欄36は、誤り訂正を
用いない場合の欠落したヘッダの数を示し、第3の欄38は、誤り訂正を用いる
場合の欠落したヘッダの数を示し、第4の欄40は、新しい技術を用いることに
より得られる改善率を示す。
【0041】
図4(a)では、15,10巡回符号が用いられる場合のダウンリンクのため
の結果が示される。誤り訂正を用いることから生じる相対的な改善率も示される
。図4(b)は、15,9巡回符号が用いられる場合のアップリンク伝送の場合
の対応する結果を示す。
の結果が示される。誤り訂正を用いることから生じる相対的な改善率も示される
。図4(b)は、15,9巡回符号が用いられる場合のアップリンク伝送の場合
の対応する結果を示す。
【0042】
誤りが訂正されたヘッダは、そのシミュレーションによれば、約10〜20%
である。1つの訂正されたヘッダが少なくとも1つのスピーチフレームを保護す
るので、それは、音声の品質を著しく改善するであろう。
である。1つの訂正されたヘッダが少なくとも1つのスピーチフレームを保護す
るので、それは、音声の品質を著しく改善するであろう。
【0043】
図5を参照すると、図3(a)に示されるダウンリンクの場合のヘッダを生成
するための符号化回路のブロック図が示される。符号化回路は、制御回路50と
、USFフィールド生成器回路52と、TFIフィールド生成器回路54と、F
BIフィールド生成器回路56と、巡回符号生成器回路58と、出力回路60と
を備える。制御回路50は、巡回符号生成器回路58と、ヘッダフィールド生成
器回路52、54および56とのそれぞれに対する信号線72上に、制御信号お
よびタイミング信号を生成する。信号線74および76上の、USFヘッダフィ
ールド生成器回路52およびTFIヘッダフィールド生成器回路54それぞれの
出力は、巡回符号生成器回路58への入力をそれぞれ形成する。巡回符号生成器
回路は、上記のようなヘッダの各フィールドの10ビットから巡回符号を生成し
、信号線80上に巡回符号を、および信号線78上にFBIフィールドを生成す
る。出力回路は、入力として、信号線80上の巡回符号生成器回路の出力を受信
する。その後、出力回路は、信号線74、78および80上の信号を適当に並べ
て、信号線68上に図3(a)のヘッダを生成する。ヘッダをさらに符号化する
実施形態は、以下にさらに記載されるであろう。
するための符号化回路のブロック図が示される。符号化回路は、制御回路50と
、USFフィールド生成器回路52と、TFIフィールド生成器回路54と、F
BIフィールド生成器回路56と、巡回符号生成器回路58と、出力回路60と
を備える。制御回路50は、巡回符号生成器回路58と、ヘッダフィールド生成
器回路52、54および56とのそれぞれに対する信号線72上に、制御信号お
よびタイミング信号を生成する。信号線74および76上の、USFヘッダフィ
ールド生成器回路52およびTFIヘッダフィールド生成器回路54それぞれの
出力は、巡回符号生成器回路58への入力をそれぞれ形成する。巡回符号生成器
回路は、上記のようなヘッダの各フィールドの10ビットから巡回符号を生成し
、信号線80上に巡回符号を、および信号線78上にFBIフィールドを生成す
る。出力回路は、入力として、信号線80上の巡回符号生成器回路の出力を受信
する。その後、出力回路は、信号線74、78および80上の信号を適当に並べ
て、信号線68上に図3(a)のヘッダを生成する。ヘッダをさらに符号化する
実施形態は、以下にさらに記載されるであろう。
【0044】
図5のブロック図から、図3(b)のヘッダ構造を生成するために、その符号
化器が、アップリンクのための符号化器を実現するために如何に変更される場合
があるかが理解されよう。
化器が、アップリンクのための符号化器を実現するために如何に変更される場合
があるかが理解されよう。
【0045】
図6を参照すると、ダウンリンクにおける誤り訂正のためのヘッダ復号化回路
の部分のブロック図が示される。ヘッダ復号化回路の部分は、入力回路62と、
巡回符号生成器回路64と、誤り訂正および検出ブロック66とを備える。入力
回路は、信号線70上で、図3(a)のフォーマットを有する、16ビットの復
号化されたヘッダを受信する。5ビットの巡回符号は、誤り訂正および検出ブロ
ックへの信号線84上に供給される。巡回符号が基にしている12ビットのヘッ
ダは、巡回符号生成器回路への信号線82上に供給され、それは、その送信機の
巡回符号生成器回路58において適用された同じ巡回符号を利用する。こうして
生成された付加的な巡回符号は、誤り訂正および検出回路66への信号線86に
提供される。こうして、誤り訂正および検出回路66は、誤りの存在を検出し、
上記のようにそれを訂正しようと試みる。再び、上記の説明から、図6の回路が
アップリンクのために如何に変更されることができるかが容易に理解されよう。
の部分のブロック図が示される。ヘッダ復号化回路の部分は、入力回路62と、
巡回符号生成器回路64と、誤り訂正および検出ブロック66とを備える。入力
回路は、信号線70上で、図3(a)のフォーマットを有する、16ビットの復
号化されたヘッダを受信する。5ビットの巡回符号は、誤り訂正および検出ブロ
ックへの信号線84上に供給される。巡回符号が基にしている12ビットのヘッ
ダは、巡回符号生成器回路への信号線82上に供給され、それは、その送信機の
巡回符号生成器回路58において適用された同じ巡回符号を利用する。こうして
生成された付加的な巡回符号は、誤り訂正および検出回路66への信号線86に
提供される。こうして、誤り訂正および検出回路66は、誤りの存在を検出し、
上記のようにそれを訂正しようと試みる。再び、上記の説明から、図6の回路が
アップリンクのために如何に変更されることができるかが容易に理解されよう。
【0046】
以下の説明では、EDGE上で伝送するためにスピーチフレームを符号化する
特定の例が与えられる。これらの例では、上記の改善されたヘッダのうちの1つ
のヘッダあるいは別のヘッダが用いられる。しかしながら、依然として上記の符
号化技術の利点から利益を得つつ、代わりのヘッダが用いられることは明らかで
あろう。
特定の例が与えられる。これらの例では、上記の改善されたヘッダのうちの1つ
のヘッダあるいは別のヘッダが用いられる。しかしながら、依然として上記の符
号化技術の利点から利益を得つつ、代わりのヘッダが用いられることは明らかで
あろう。
【0047】
EDGE上で音声を伝送する際に、可能なときはいつでも、伝送するためのス
ピーチフレームを生成するために標準的な音声符号化器の構成要素を用いること
が有利である。以下の例では、標準的なGSM音声符号化器が用いられる。しか
しながら、他の音声符号化器が用いられる場合もある。GSMでは、スピーチフ
レームはクラスIビットと、クラスIIビットとを有し、クラスIビットはさら
に、クラスIaカテゴリと、クラスIbカテゴリとに分割される。一般に音声で
は、種々のビットが異なる重要度を有し、それゆえ、より一般的な場合には、そ
の重要なビット(GSMのクラスI)は主要ビットと見なされ、重要度の低いビ
ット(GSMのクラスII)は副次ビットと見なされることができる。
ピーチフレームを生成するために標準的な音声符号化器の構成要素を用いること
が有利である。以下の例では、標準的なGSM音声符号化器が用いられる。しか
しながら、他の音声符号化器が用いられる場合もある。GSMでは、スピーチフ
レームはクラスIビットと、クラスIIビットとを有し、クラスIビットはさら
に、クラスIaカテゴリと、クラスIbカテゴリとに分割される。一般に音声で
は、種々のビットが異なる重要度を有し、それゆえ、より一般的な場合には、そ
の重要なビット(GSMのクラスI)は主要ビットと見なされ、重要度の低いビ
ット(GSMのクラスII)は副次ビットと見なされることができる。
【0048】
同じユーザからの2つのスピーチフレーム
図7は、2つのスピーチフレームが同じユーザに関連する際に、EDGEシス
テムのダウンリンク上で2つのスピーチフレームを符号化するのに適した符号化
器のブロック図を示す。その符号化器は、一対の予備符号化回路104および1
06と、一対のブロック符号回路112および118と、一対のリオーダ回路1
14および120と、一対のたたみ込み符号化器126および128と、出力回
路116と付加ブロック符号回路140とを備える。
テムのダウンリンク上で2つのスピーチフレームを符号化するのに適した符号化
器のブロック図を示す。その符号化器は、一対の予備符号化回路104および1
06と、一対のブロック符号回路112および118と、一対のリオーダ回路1
14および120と、一対のたたみ込み符号化器126および128と、出力回
路116と付加ブロック符号回路140とを備える。
【0049】
標準的なGSM進化型フルレート音声符号化器は、244ビットを有するスピ
ーチフレームを生成する。これらのビットのうちの174ビットはクラスIビッ
トであり、そのうちの50ビットはクラスIaで、124ビットはクラスIbで
ある。残りの70ビットはクラスIIビットである。第1のユーザからの最初の
スピーチフレームU1SF1の244ビットは、信号線100上で受信され、同
じ第1のユーザからの第2のスピーチフレームU1SF2の244ビットは、信
号線102上で受信される。244ビットのスピーチフレームU1SF1および
U1SF2はそれぞれ、各予備符号化回路104および106の1つに入力され
る。
ーチフレームを生成する。これらのビットのうちの174ビットはクラスIビッ
トであり、そのうちの50ビットはクラスIaで、124ビットはクラスIbで
ある。残りの70ビットはクラスIIビットである。第1のユーザからの最初の
スピーチフレームU1SF1の244ビットは、信号線100上で受信され、同
じ第1のユーザからの第2のスピーチフレームU1SF2の244ビットは、信
号線102上で受信される。244ビットのスピーチフレームU1SF1および
U1SF2はそれぞれ、各予備符号化回路104および106の1つに入力され
る。
【0050】
予備符号化回路104および106はそれぞれ、各出力信号線108および1
10上に、1組の260ビットを生成する。244ビットの各スピーチフレーム
U1SF1およびU1SF2は、予備符号化回路のうちの1つの中を伝送し、そ
れぞれ1組の260ビットが生成される。予備符号化回路では、付加的な16ビ
ットが、クラスIビットのうちの最も重要な65ビットに関する8ビットの巡回
冗長符号と、4つの最も重要なクラスIIビットを2回繰り返したものとによっ
て生成される。こうして、各スピーチフレームは、50クラスIaビットと、1
32クラスIbビットと、78クラスIIビットとを有するように変更され、全
260ビットが与えられる。この予備符号化ステップは、標準的なGSM技術に
準拠する。
10上に、1組の260ビットを生成する。244ビットの各スピーチフレーム
U1SF1およびU1SF2は、予備符号化回路のうちの1つの中を伝送し、そ
れぞれ1組の260ビットが生成される。予備符号化回路では、付加的な16ビ
ットが、クラスIビットのうちの最も重要な65ビットに関する8ビットの巡回
冗長符号と、4つの最も重要なクラスIIビットを2回繰り返したものとによっ
て生成される。こうして、各スピーチフレームは、50クラスIaビットと、1
32クラスIbビットと、78クラスIIビットとを有するように変更され、全
260ビットが与えられる。この予備符号化ステップは、標準的なGSM技術に
準拠する。
【0051】
信号線108上の50クラスIaビットは、ブロック符号回路112に入力さ
れる。その後、その50クラスIaビットを用いて、3つのパリティビットが生
成され、ブロック符号回路の出力線121上に53ビットが生成されるようにな
る。同様に、信号線110上の50クラスIaビットは、ブロック符号回路11
8に入力され、それにより信号線124上に53ビット(3パリティビットを含
む)が生成される。
れる。その後、その50クラスIaビットを用いて、3つのパリティビットが生
成され、ブロック符号回路の出力線121上に53ビットが生成されるようにな
る。同様に、信号線110上の50クラスIaビットは、ブロック符号回路11
8に入力され、それにより信号線124上に53ビット(3パリティビットを含
む)が生成される。
【0052】
信号線108上の132クラスIbビットは、リオーダ回路114に入力され
る。信号線110上の132クラスIbビットは、リオーダブロック回路120
に入力される。信号線121上の53ビットは、リオーダ回路114への付加的
な入力を形成し、信号線124上の53ビットは、リオーダ回路120への付加
的な入力を形成する。
る。信号線110上の132クラスIbビットは、リオーダブロック回路120
に入力される。信号線121上の53ビットは、リオーダ回路114への付加的
な入力を形成し、信号線124上の53ビットは、リオーダ回路120への付加
的な入力を形成する。
【0053】
各リオーダ回路114および120はさらに、信号線130および132上で
、1組の6テールビットTBをそれぞれ受信する。その後、テールは、それぞれ
リオーダブロック114および120において、クラスIビットの最後に追加さ
れ、以下に記載されるように、クラスIビットをさらに符号化するために用いら
れるたたみ込み符号化器のためのトレリス終端として用いられる。EDGEでは
、6テールビットが付加される。
、1組の6テールビットTBをそれぞれ受信する。その後、テールは、それぞれ
リオーダブロック114および120において、クラスIビットの最後に追加さ
れ、以下に記載されるように、クラスIビットをさらに符号化するために用いら
れるたたみ込み符号化器のためのトレリス終端として用いられる。EDGEでは
、6テールビットが付加される。
【0054】
リオーダ回路114は、信号線121上の53クラスIビットと、信号線10
8上の132クラスIビットと、信号線130上の6テールビットとを並べ替え
、信号線122上に191クラスIビットを生成する。リオーダ回路120は、
信号線124上の53クラスIビットと、信号線110上の132クラスIビッ
トと、信号線132上の6テールビットとを並べ替え、信号線125上の191
クラスIビットを生成する。それぞれ信号線122および124上の191ビッ
ト出力は、各たたみ込み符号化回路126および128の入力を形成する。
8上の132クラスIビットと、信号線130上の6テールビットとを並べ替え
、信号線122上に191クラスIビットを生成する。リオーダ回路120は、
信号線124上の53クラスIビットと、信号線110上の132クラスIビッ
トと、信号線132上の6テールビットとを並べ替え、信号線125上の191
クラスIビットを生成する。それぞれ信号線122および124上の191ビッ
ト出力は、各たたみ込み符号化回路126および128の入力を形成する。
【0055】
信号線108上の78クラスIIビットは、出力ブロック116に直接入力さ
れる。信号線110上の78クラスIIビットは、出力ブロック116に直接入
力される。
れる。信号線110上の78クラスIIビットは、出力ブロック116に直接入
力される。
【0056】
こうして、244ビットスピーチフレームU1SF1およびU1SF2は、こ
の段階で、191クラスIビットと78クラスIIビットとを有する、それぞれ
269ビットスピーチフレームに符号化される。
の段階で、191クラスIビットと78クラスIIビットとを有する、それぞれ
269ビットスピーチフレームに符号化される。
【0057】
ここまでのスピーチフレームの符号化は、GSMにおいて用いられる音声符号
化技術に適合しており、標準的なGSM音声符号化器で実装されることができる
。1つの相違点は、標準的なGSMでは、4つのみのテールビットが必要とされ
ることである。それゆえ、標準的なGSMでは、この段階において通常、189
クラスIビットのみが存在する。
化技術に適合しており、標準的なGSM音声符号化器で実装されることができる
。1つの相違点は、標準的なGSMでは、4つのみのテールビットが必要とされ
ることである。それゆえ、標準的なGSMでは、この段階において通常、189
クラスIビットのみが存在する。
【0058】
2つのスピーチフレームを符号化するこの有利な実施形態では、2つではなく
、1つのみのヘッダを符号化することにより、効率的な符号化技術を用いること
ができる。すなわち、2つのスピーチフレームに関連するヘッダが同じユーザに
関連するときには、それらは同一であると認識される。それゆえ、1つのヘッダ
は破棄され、結果として、以下に記載されるように、符号化される必要があるビ
ットの数が少なくなる。以下の説明からも明らかになるように、スピーチフレー
ムが進化型のフルレート符号化を用いて生成される際に、1つのヘッダのみを符
号化するための要件によって、2つのスピーチフレームは、符号化の際に任意の
パンクチャ処理を行うことを必要とせずに、1つのRLC/MACブロックに符
号化されるようになり、結果として、非常に効率的な符号化方式になる。
、1つのみのヘッダを符号化することにより、効率的な符号化技術を用いること
ができる。すなわち、2つのスピーチフレームに関連するヘッダが同じユーザに
関連するときには、それらは同一であると認識される。それゆえ、1つのヘッダ
は破棄され、結果として、以下に記載されるように、符号化される必要があるビ
ットの数が少なくなる。以下の説明からも明らかになるように、スピーチフレー
ムが進化型のフルレート符号化を用いて生成される際に、1つのヘッダのみを符
号化するための要件によって、2つのスピーチフレームは、符号化の際に任意の
パンクチャ処理を行うことを必要とせずに、1つのRLC/MACブロックに符
号化されるようになり、結果として、非常に効率的な符号化方式になる。
【0059】
16ビットのダウンリンクヘッダが信号線138上に提供される。この例では
、図3(a)のダウンリンクの場合の有利なヘッダ構造が用いられる。3つのU
SFビットが、ブロック符号回路140への入力を形成し、それは、EDGEか
らの標準的なブロック符号を用いて、出力回路116への出力信号線142上に
36ビットを生成する。信号線138上のヘッダの他の13ビットは、たたみ込
み符号化回路126への付加的な入力を形成する。
、図3(a)のダウンリンクの場合の有利なヘッダ構造が用いられる。3つのU
SFビットが、ブロック符号回路140への入力を形成し、それは、EDGEか
らの標準的なブロック符号を用いて、出力回路116への出力信号線142上に
36ビットを生成する。信号線138上のヘッダの他の13ビットは、たたみ込
み符号化回路126への付加的な入力を形成する。
【0060】
図8(a)を参照すると、これまでに記載された、符号化されないダウンリン
クスピーチブロックあるいはパケットが示される。信号線138上のヘッダのU
SFフィールドの3ビットは参照番号150によって示され、信号線138上の
ヘッダの残りの13ビットは参照番号152によって示される。信号線122上
の第1のユーザからの第1のスピーチフレームの191クラスIビットは、参照
番号154によって示され、信号線108上の第1のユーザからの第1のスピー
チフレームの78クラスIIビットは参照番号156によって示される。信号線
124上の第1のユーザからの第2のスピーチフレームの191クラスIビット
は参照番号158によって示され、信号線110上の第1のユーザからの第2の
スピーチフレームの78クラスIIビットは参照番号160によって示される。
クスピーチブロックあるいはパケットが示される。信号線138上のヘッダのU
SFフィールドの3ビットは参照番号150によって示され、信号線138上の
ヘッダの残りの13ビットは参照番号152によって示される。信号線122上
の第1のユーザからの第1のスピーチフレームの191クラスIビットは、参照
番号154によって示され、信号線108上の第1のユーザからの第1のスピー
チフレームの78クラスIIビットは参照番号156によって示される。信号線
124上の第1のユーザからの第2のスピーチフレームの191クラスIビット
は参照番号158によって示され、信号線110上の第1のユーザからの第2の
スピーチフレームの78クラスIIビットは参照番号160によって示される。
【0061】
上記のように、ダウンリンクヘッダの3つのUSFビットは、図8(b)の参
照符号162によって示されるように、36ビットにブロック符号化され、出力
回路116に渡される。ヘッダ内のUSFフィールドを符号化するために、ED
GEデータ伝送の場合に示唆されるような36,3線形ブロック符号が用いられ
る。この符号は以下の表1に与えられる。
照符号162によって示されるように、36ビットにブロック符号化され、出力
回路116に渡される。ヘッダ内のUSFフィールドを符号化するために、ED
GEデータ伝送の場合に示唆されるような36,3線形ブロック符号が用いられ
る。この符号は以下の表1に与えられる。
【表1】
【0062】
信号線122上の第1のスピーチフレームの191クラスIビットは、たたみ
込み符号化回路126において、信号線138上のヘッダの残りの13ビット(
すなわち、3USFビットを除く全てのフィールド)と結合される。出力回路1
16に渡される、出力信号線134上の612ビットを生成するために、たたみ
込み符号器回路126において3,1,7たたみ込み符号が用いられる。これら
の612ビットは、図8(b)に参照符号164によって示される。
込み符号化回路126において、信号線138上のヘッダの残りの13ビット(
すなわち、3USFビットを除く全てのフィールド)と結合される。出力回路1
16に渡される、出力信号線134上の612ビットを生成するために、たたみ
込み符号器回路126において3,1,7たたみ込み符号が用いられる。これら
の612ビットは、図8(b)に参照符号164によって示される。
【0063】
好ましい実施形態において用いられる3,1,7たたみ込み符号は、EDGE
においてデータ伝送するために提案されたものより強力である。その符号は、1
/3の符号化率と、7の限定長とを有し、それゆえ、EDGEのために提案され
た符号と同じ複雑さからなる。
においてデータ伝送するために提案されたものより強力である。その符号は、1
/3の符号化率と、7の限定長とを有し、それゆえ、EDGEのために提案され
た符号と同じ複雑さからなる。
【0064】
符号化率3,1,7たたみ込み符号の生成多項式は以下の通りである。
G0(D)=1+D2+D3+D5+D6
G1(D)=1+D+D2+D3+D4+D6
G2(D)=1+D+D4+D6
この符号は、そのクラスにおいて最もよく知られている符号である。この符号の
自由距離はdfree=15である。EDGEにおいて提案される符号は、14
の自由距離を有する(パンクチャ処理が適用されない場合)。
自由距離はdfree=15である。EDGEにおいて提案される符号は、14
の自由距離を有する(パンクチャ処理が適用されない場合)。
【0065】
78クラスIIビットは、信号線108から符号化されずに出力回路116に
渡され、図8(b)において参照符号166によって示される。それは、GSM
では、符号化されないクラスIIビットの場合に標準的である。
渡され、図8(b)において参照符号166によって示される。それは、GSM
では、符号化されないクラスIIビットの場合に標準的である。
【0066】
信号線125上の第2のスピーチフレームの191クラスIビットは、たたみ
込み符号化回路128に入力される。再び、たたみ込み符号化回路126におい
て3,1,7たたみ込み符号が用いられ、信号線136上に573ビットが生成
され、出力回路116に渡される。これらの573ビットは、図8(b)に参照
番号168によって示される。
込み符号化回路128に入力される。再び、たたみ込み符号化回路126におい
て3,1,7たたみ込み符号が用いられ、信号線136上に573ビットが生成
され、出力回路116に渡される。これらの573ビットは、図8(b)に参照
番号168によって示される。
【0067】
78クラスIIビットは、信号線110上で符号化されずに出力回路116に
渡され、図8(b)に参照番号170によって示される。
渡され、図8(b)に参照番号170によって示される。
【0068】
出力回路116はさらに、信号線146上で4つのスチールビットSBを受信
する。4つのスチールビットは、ヘッダのタイプを知らせるために用いられる(
EDGE上のデータ伝送の場合と同様)。各TDMAバーストは1つのスチール
ビットを含む。それゆえ、ここでは、RLC/MACブロックがEDGE上のデ
ータの場合のように4バーストにわたって拡散されることが提案されているので
、4つのスチールビットが与えられる。1377ビットが生成されるのに加えて
、図8(b)に示されるように、これは、全ビット数を、EDGE RLC/M
ACブロックにおいて利用可能なビット数より11ビット短いままにしておく。
こうして、出力回路116はさらに、信号線148上で、11スペアビットSP
Bを受信する。その後、出力回路は、伝送するために、信号線149上に、13
92ビットを含む完成したEDGE RLC/MACブロックを生成する。
する。4つのスチールビットは、ヘッダのタイプを知らせるために用いられる(
EDGE上のデータ伝送の場合と同様)。各TDMAバーストは1つのスチール
ビットを含む。それゆえ、ここでは、RLC/MACブロックがEDGE上のデ
ータの場合のように4バーストにわたって拡散されることが提案されているので
、4つのスチールビットが与えられる。1377ビットが生成されるのに加えて
、図8(b)に示されるように、これは、全ビット数を、EDGE RLC/M
ACブロックにおいて利用可能なビット数より11ビット短いままにしておく。
こうして、出力回路116はさらに、信号線148上で、11スペアビットSP
Bを受信する。その後、出力回路は、伝送するために、信号線149上に、13
92ビットを含む完成したEDGE RLC/MACブロックを生成する。
【0069】
図8(c)を参照すると、ダウンリンクのための完成したRLC/MACブロ
ックが示されており、それは、参照番号172によって示される4スチールビッ
トと、参照番号174によって示される11スペアビットとを加えた、図8(b
)の示されるフォーマットに対応する。参照番号176は、図8(b)の137
7ビットを表す。
ックが示されており、それは、参照番号172によって示される4スチールビッ
トと、参照番号174によって示される11スペアビットとを加えた、図8(b
)の示されるフォーマットに対応する。参照番号176は、図8(b)の137
7ビットを表す。
【0070】
実際には、たたみ込み符号化器126あるいは128の一方のみが設けられる
。そのような1つのたたみ込み符号化器が、両方のスピーチフレームを順次符号
化するための用いられる場合がある。
。そのような1つのたたみ込み符号化器が、両方のスピーチフレームを順次符号
化するための用いられる場合がある。
【0071】
上記の説明は、ダウンリンクにおいて、同じRLC/MACブロック内で2つ
のスピーチフレームを伝送することに関連しており、図8は、ダウンリンク伝送
の場合に、1つのRLC/MACブロックにおいて2つのスピーチフレームを伝
送するためのチャネル符号化の概要を表すが、同様の技術がアップリンクにも当
てはまる。図9は、アップリンク伝送の場合に、1つのRLC/MACブロック
において2つのスピーチフレームを伝送するために適用されるチャネル符号化原
理を示す。
のスピーチフレームを伝送することに関連しており、図8は、ダウンリンク伝送
の場合に、1つのRLC/MACブロックにおいて2つのスピーチフレームを伝
送するためのチャネル符号化の概要を表すが、同様の技術がアップリンクにも当
てはまる。図9は、アップリンク伝送の場合に、1つのRLC/MACブロック
において2つのスピーチフレームを伝送するために適用されるチャネル符号化原
理を示す。
【0072】
アップリンクにおいてRLC/MACブロックを生成するための符号化器は、
図7に示されるダウンリンクの場合の符号化器と非常に類似であり、それゆえこ
こで説明されないであろう。アップリンクの符号化器は、ヘッダのためのブロッ
ク符号回路140が設けられず、図3(b)の全16ビットのアップリンクヘッ
ダが、たたみ込み符号化器において、信号線122上の191ビットと結合され
る点で異なる。さらに、たたみ込み符号化後のRLC/MACブロック内のスペ
アビットの数は38であり、それゆえ信号線148上のスペアビットSPBの数
が38まで増やされる。
図7に示されるダウンリンクの場合の符号化器と非常に類似であり、それゆえこ
こで説明されないであろう。アップリンクの符号化器は、ヘッダのためのブロッ
ク符号回路140が設けられず、図3(b)の全16ビットのアップリンクヘッ
ダが、たたみ込み符号化器において、信号線122上の191ビットと結合され
る点で異なる。さらに、たたみ込み符号化後のRLC/MACブロック内のスペ
アビットの数は38であり、それゆえ信号線148上のスペアビットSPBの数
が38まで増やされる。
【0073】
図9(a)を参照すると、符号化されないアップリンクスピーチブロックある
いはパケットが示される。信号線138上の16ビットのヘッダは、参照番号1
80によって示される。信号線122上の第1のユーザからの第1のスピーチフ
レームのクラスIビットは、参照番号182によって示され、信号線108上の
第1のユーザからの第1のスピーチフレームのクラスIIビットは、参照番号1
84によって示される。信号線124上の第1のユーザからの第2のスピーチフ
レームのクラスIビットは、参照番号186によって示され、信号線110上の
第1のユーザからの第2のスピーチフレームのクラスIIビットは、参照番号1
88によって示される。
いはパケットが示される。信号線138上の16ビットのヘッダは、参照番号1
80によって示される。信号線122上の第1のユーザからの第1のスピーチフ
レームのクラスIビットは、参照番号182によって示され、信号線108上の
第1のユーザからの第1のスピーチフレームのクラスIIビットは、参照番号1
84によって示される。信号線124上の第1のユーザからの第2のスピーチフ
レームのクラスIビットは、参照番号186によって示され、信号線110上の
第1のユーザからの第2のスピーチフレームのクラスIIビットは、参照番号1
88によって示される。
【0074】
信号線122上の第1のスピーチフレームの191クラスIビットは、たたみ
込み符号化回路126において、信号線138上の16ビットのヘッダと結合さ
れる。再び、たたみ込み符号化回路126において3,1,7たたみ込み符号が
用いられ、出力信号線134上に621ビットが生成され、出力回路116に渡
される。これらの621ビットは図9(b)に参照番号190によって示される
。
込み符号化回路126において、信号線138上の16ビットのヘッダと結合さ
れる。再び、たたみ込み符号化回路126において3,1,7たたみ込み符号が
用いられ、出力信号線134上に621ビットが生成され、出力回路116に渡
される。これらの621ビットは図9(b)に参照番号190によって示される
。
【0075】
78クラスIIビットは、信号線108から符号化されずに出力回路116に
渡され、図9(b)に参照番号192によって示される。
渡され、図9(b)に参照番号192によって示される。
【0076】
信号線125上の第2のスピーチフレームの191クラスIビットは、たたみ
込み符号化回路128に入力される。再び、たたみ込み符号化回路126におい
て3,1,7たたみ込み符号が用いられ、出力信号線136上に573ビットが
生成され、出力回路116に渡される。これらの573ビットは図9(b)に参
照番号194によって示される。
込み符号化回路128に入力される。再び、たたみ込み符号化回路126におい
て3,1,7たたみ込み符号が用いられ、出力信号線136上に573ビットが
生成され、出力回路116に渡される。これらの573ビットは図9(b)に参
照番号194によって示される。
【0077】
78クラスIIビットは、信号線110から符号化されずに出力回路116に
渡され、図9(b)に参照番号196によって示される。
渡され、図9(b)に参照番号196によって示される。
【0078】
図9(c)を参照すると、アップリンクのための完成したRLC/MACブロ
ックが示されており、それは、参照番号198によって示される4スチールビッ
トと、参照番号202によって示される38スペアビットとを加えた、図9(b
)に示されるフォーマットに対応する。参照番号200は、図8(b)のビット
を表す。
ックが示されており、それは、参照番号198によって示される4スチールビッ
トと、参照番号202によって示される38スペアビットとを加えた、図9(b
)に示されるフォーマットに対応する。参照番号200は、図8(b)のビット
を表す。
【0079】
アップリンクあるいはダウンリンクでは、1392ビットのRLC/MACブ
ロックが、EDGE符号化器の8−PSK変調器に渡される。RLC/MACス
ピーチブロックは、EDGEのデータパケットの伝送の場合のように、4バース
トにわたってインターリーブされることが好ましい。
ロックが、EDGE符号化器の8−PSK変調器に渡される。RLC/MACス
ピーチブロックは、EDGEのデータパケットの伝送の場合のように、4バース
トにわたってインターリーブされることが好ましい。
【0080】
受信機では、逆の復号化ステージが用いられる。受信されたスピーチフレーム
のヘッダに誤りがある場合には、誤り訂正が試みられる。誤り訂正に成功する場
合でも、2つのCRC検査のいずれかが成功しない(3ビットが50クラスIa
ビットを保護するか、8ビットCRCが65ビットの最重要クラスIビットを保
護する)場合には、依然として、受信されるスピーチフレームは破棄される場合
がある。
のヘッダに誤りがある場合には、誤り訂正が試みられる。誤り訂正に成功する場
合でも、2つのCRC検査のいずれかが成功しない(3ビットが50クラスIa
ビットを保護するか、8ビットCRCが65ビットの最重要クラスIビットを保
護する)場合には、依然として、受信されるスピーチフレームは破棄される場合
がある。
【0081】
こうして、上記において、EDGE上で伝送するための1つのRLC/MAC
ブロックに、同じユーザからの2つのスピーチフレームを符号化するため技術が
記載されてきた。この技術は具体的には、EDGE上で音声を伝送するための技
術に関連して記載されてきたが、それは、パケット交換網上での音声の伝送によ
り幅広く当てはまる。その技術によって、1人のユーザからの2つのスピーチフ
レームが、有利であることが立証されている符号化方式を用いて、1つのRLC
/MACブロックに符号化されるようになる。さらに重要なのは、その符号化方
式を実施する際に、ビットをパンクチャ処理する必要が全くないことである。す
なわち、通常、音声データを符号化する際に必要とされるものと予想されるよう
な、ビット数が確実にRLC/MACブロックに嵌め込まれるように符号化され
たスピーチフレームのビットを除去する必要がない。この特別な利点は、2つの
スピーチフレームが同じユーザからのものである場合には、そのスピーチフレー
ムに関連するヘッダが同一であるという特徴を利用することにより達成される。
それゆえ、ヘッダの1つは余分であり、符号化されたパケットから除去される。
これにより、符号化されるビットの数を低減し、特に有利な符号化方式が用いら
れるようになる。
ブロックに、同じユーザからの2つのスピーチフレームを符号化するため技術が
記載されてきた。この技術は具体的には、EDGE上で音声を伝送するための技
術に関連して記載されてきたが、それは、パケット交換網上での音声の伝送によ
り幅広く当てはまる。その技術によって、1人のユーザからの2つのスピーチフ
レームが、有利であることが立証されている符号化方式を用いて、1つのRLC
/MACブロックに符号化されるようになる。さらに重要なのは、その符号化方
式を実施する際に、ビットをパンクチャ処理する必要が全くないことである。す
なわち、通常、音声データを符号化する際に必要とされるものと予想されるよう
な、ビット数が確実にRLC/MACブロックに嵌め込まれるように符号化され
たスピーチフレームのビットを除去する必要がない。この特別な利点は、2つの
スピーチフレームが同じユーザからのものである場合には、そのスピーチフレー
ムに関連するヘッダが同一であるという特徴を利用することにより達成される。
それゆえ、ヘッダの1つは余分であり、符号化されたパケットから除去される。
これにより、符号化されるビットの数を低減し、特に有利な符号化方式が用いら
れるようになる。
【0082】
さらに、この技術は、1つのRLC/MACブロックにおいて同じユーザから
の3つ以上のスピーチフレームを符号化する際に有利に用いられる場合があるこ
とを理解されたい。スピーチフレームの数に関係なく、そのフレームが同じユー
ザからのものである場合には、ヘッダは1つしか必要とされない。
の3つ以上のスピーチフレームを符号化する際に有利に用いられる場合があるこ
とを理解されたい。スピーチフレームの数に関係なく、そのフレームが同じユー
ザからのものである場合には、ヘッダは1つしか必要とされない。
【0083】
以下の説明では、異なるユーザに関連する2つのスピーチフレームの符号化に
関する2つの例が与えられる。異なるユーザからのスピーチフレームの1つの特
徴は、ダウンリンクにおいて、あるユーザが他のユーザについての情報を持たな
いことである。
関する2つの例が与えられる。異なるユーザからのスピーチフレームの1つの特
徴は、ダウンリンクにおいて、あるユーザが他のユーザについての情報を持たな
いことである。
【0084】
同じユーザからの4つのスピーチフレームを1つのRLC/MACブロックに
符号化するために先に記載された原理が、同じユーザからのさらに多くのスピー
チフレームを1つのRLC/MACブロックに符号化することにさらに拡張され
る場合がある。
符号化するために先に記載された原理が、同じユーザからのさらに多くのスピー
チフレームを1つのRLC/MACブロックに符号化することにさらに拡張され
る場合がある。
【0085】
異なるユーザからの2つのスピーチフレーム‐ケース1
図12を参照すると、パケット交換網のダウンリンクにおいて、2人の異なる
ユーザからの2つのスピーチフレームを符号化するための1つの実施形態を示す
ブロック図が示される。図12のダウンリンク符号化器は概ね図7のダウンリン
ク符号化器に対応し、同様の構成要素を示すために、同様の参照番号が用いられ
ている。主な違いは、付加ブロック符号回路140が追加されていることである
。さらに、たたみ込み符号化回路126および128は、以下にさらに記載され
るように、付加的にパンクチャ処理を含むように変更される。
ユーザからの2つのスピーチフレームを符号化するための1つの実施形態を示す
ブロック図が示される。図12のダウンリンク符号化器は概ね図7のダウンリン
ク符号化器に対応し、同様の構成要素を示すために、同様の参照番号が用いられ
ている。主な違いは、付加ブロック符号回路140が追加されていることである
。さらに、たたみ込み符号化回路126および128は、以下にさらに記載され
るように、付加的にパンクチャ処理を含むように変更される。
【0086】
この実施形態は、図7を参照して先に記載されたように、進化型フルレートG
SM音声符号化器によって生成される244ビットスピーチフレームを用いる。
第1のユーザからの244ビットの第1のスピーチフレームU1SF1は信号線
100上で受信され、第2のユーザからの244ビットの第1のスピーチフレー
ムU2SF1は信号線102上で受信される。244ビットスピーチフレームU
1SF1およびU2SF1はそれぞれ、図7を参照して厳密に先に記載されたよ
うに、予備符号化回路104および106と、ブロック符号回路112および1
18と、リオーダ回路120とによって処理される。
SM音声符号化器によって生成される244ビットスピーチフレームを用いる。
第1のユーザからの244ビットの第1のスピーチフレームU1SF1は信号線
100上で受信され、第2のユーザからの244ビットの第1のスピーチフレー
ムU2SF1は信号線102上で受信される。244ビットスピーチフレームU
1SF1およびU2SF1はそれぞれ、図7を参照して厳密に先に記載されたよ
うに、予備符号化回路104および106と、ブロック符号回路112および1
18と、リオーダ回路120とによって処理される。
【0087】
2つのスピーチフレームが異なるユーザからのものであるとき、各スピーチフ
レームに関連する2つのそれぞれ異なるヘッダが存在する。それゆえ、信号線1
02上の第2のユーザのスピーチフレームに関連するヘッダを処理するために、
ブロック符号回路141が導入される。信号線100の第1のユーザのスピーチ
フレームに関連するヘッダは、ブロック符号回路140によって、図7の回路に
おいて共通のヘッダが処理されるのと同じようにして処理される。
レームに関連する2つのそれぞれ異なるヘッダが存在する。それゆえ、信号線1
02上の第2のユーザのスピーチフレームに関連するヘッダを処理するために、
ブロック符号回路141が導入される。信号線100の第1のユーザのスピーチ
フレームに関連するヘッダは、ブロック符号回路140によって、図7の回路に
おいて共通のヘッダが処理されるのと同じようにして処理される。
【0088】
スピーチフレームU2SF1に関連する第2のユーザの16ビットのダウンリ
ンクヘッダは、信号線139上に与えられる。3つのUSFビットがブロック符
号回路141への入力を形成し、その回路では、図7を参照して先に説明された
EDGEからの標準的なブロック符号を用いて、出力回路116への出力信号線
143上に36ビットが生成される。信号線139上のヘッダの他の13ビット
は、たたみ込み符号化回路128への付加的な入力を形成する。
ンクヘッダは、信号線139上に与えられる。3つのUSFビットがブロック符
号回路141への入力を形成し、その回路では、図7を参照して先に説明された
EDGEからの標準的なブロック符号を用いて、出力回路116への出力信号線
143上に36ビットが生成される。信号線139上のヘッダの他の13ビット
は、たたみ込み符号化回路128への付加的な入力を形成する。
【0089】
図13(a)を参照すると、パンクチャ処理を伴うたたみ込み符号化回路12
6および128の動作の前の、2人の異なるユーザからの2つのスピーチフレー
ムを含む、符号化されないダウンリンクスピーチフレームブロックあるいはパケ
ットが示される。この例では、各スピーチフレームは、図3(a)のヘッダフォ
ーマットを用いることが有利である。したがって、第1のユーザからの第1のス
ピーチフレームは、ヘッダ213のUSFフィールド212を含み、ヘッダの残
りの部分は参照番号214によって示される。第1のユーザからの第1のスピー
チフレームのクラスIビットは、参照番号216によって示され、第1のユーザ
からの第1のスピーチフレームのクラスIIビットは参照番号218によって示
される。第2のユーザからの第1のスピーチフレームは、ヘッダ221のUSF
フィールド220を含み、ヘッダの残りの部分は参照番号222によって示され
る。第2のユーザからの第1のスピーチフレームのクラスIビットは、参照番号
224によって示され、第2のユーザからの第1のスピーチフレームのクラスI
Iビットは参照番号226によって示される。
6および128の動作の前の、2人の異なるユーザからの2つのスピーチフレー
ムを含む、符号化されないダウンリンクスピーチフレームブロックあるいはパケ
ットが示される。この例では、各スピーチフレームは、図3(a)のヘッダフォ
ーマットを用いることが有利である。したがって、第1のユーザからの第1のス
ピーチフレームは、ヘッダ213のUSFフィールド212を含み、ヘッダの残
りの部分は参照番号214によって示される。第1のユーザからの第1のスピー
チフレームのクラスIビットは、参照番号216によって示され、第1のユーザ
からの第1のスピーチフレームのクラスIIビットは参照番号218によって示
される。第2のユーザからの第1のスピーチフレームは、ヘッダ221のUSF
フィールド220を含み、ヘッダの残りの部分は参照番号222によって示され
る。第2のユーザからの第1のスピーチフレームのクラスIビットは、参照番号
224によって示され、第2のユーザからの第1のスピーチフレームのクラスI
Iビットは参照番号226によって示される。
【0090】
上記のように、第1のユーザに関連するヘッダのUSFフィールド212の3
ビットは、ブロック符号回路140においてブロック符号化され、信号線142
上に、図13(b)に参照番号238によって示される3ビットが与えられる。
ビットは、ブロック符号回路140においてブロック符号化され、信号線142
上に、図13(b)に参照番号238によって示される3ビットが与えられる。
【0091】
信号線122上の第1ユーザからの第1のスピーチフレームの191クラスI
ビットは、たたみ込み符号化回路126において、信号線138上の16ビット
のヘッダと結合される。再び、たたみ込み符号化回路126において3,1,7
たたみ込み符号が用いられ、符号化回路の出力134上に578ビットが生成さ
れるように、符号化回路は34ビットをパンクチャ処理(削除)する。これらの
578ビットは図13(b)に参照番号230によって示される。
ビットは、たたみ込み符号化回路126において、信号線138上の16ビット
のヘッダと結合される。再び、たたみ込み符号化回路126において3,1,7
たたみ込み符号が用いられ、符号化回路の出力134上に578ビットが生成さ
れるように、符号化回路は34ビットをパンクチャ処理(削除)する。これらの
578ビットは図13(b)に参照番号230によって示される。
【0092】
好ましい実装形態では、用いられるパンクチャ処理方式は以下の通りである。
b(9+j*17)j=0,1...33,
ただしb(i)は3,1,7符号化器の出力である。この方式は、CRCビット
をパンクチャ処理しない。クラスIビットの場合、全出力は573ビットであり
、CRCビットは位置151〜159に配置される。パンクチャ処理されるビッ
トのうちCRCに最も近いのは、ビット145および162である、パンクチャ
処理される最後のビットは570である。
をパンクチャ処理しない。クラスIビットの場合、全出力は573ビットであり
、CRCビットは位置151〜159に配置される。パンクチャ処理されるビッ
トのうちCRCに最も近いのは、ビット145および162である、パンクチャ
処理される最後のビットは570である。
【0093】
78クラスIIビット218は、信号線108上で符号化されずに出力回路1
16に渡され、図13(b)に参照番号232によって示される。
16に渡され、図13(b)に参照番号232によって示される。
【0094】
上記のように、第2のユーザに関連するヘッダの3ビットUSFフィールド2
20は、ブロック符号回路141においてブロック符号化され、信号線143上
に、図13(b)に参照番号240によって示される3ビットが与えられる。
20は、ブロック符号回路141においてブロック符号化され、信号線143上
に、図13(b)に参照番号240によって示される3ビットが与えられる。
【0095】
信号線125上の第2のユーザからの第1のスピーチフレームの191クラス
Iビットは、たたみ込み符号化回路128に入力される。たたみ込み符号化回路
128において3,1,7たたみ込み符号が再び用いられ、符号化回路128の
出力136上に578ビットが生成されるように、符号化回路は34ビットをパ
ンクチャ処理する。これらの578ビットは、図13(b)に参照番号234に
よって示される。
Iビットは、たたみ込み符号化回路128に入力される。たたみ込み符号化回路
128において3,1,7たたみ込み符号が再び用いられ、符号化回路128の
出力136上に578ビットが生成されるように、符号化回路は34ビットをパ
ンクチャ処理する。これらの578ビットは、図13(b)に参照番号234に
よって示される。
【0096】
78クラスIIビット224は、信号線110上で符号化されない状態で出力
回路116に渡され、図13(b)に参照番号236によって示される。
回路116に渡され、図13(b)に参照番号236によって示される。
【0097】
図12の符号化器は、信号線146上に8スチールビットSBが与えられ、ス
ペアビットが与えられる必要がないという点でも、図7の符号化器とは異なる。
ペアビットが与えられる必要がないという点でも、図7の符号化器とは異なる。
【0098】
図13(c)を参照すると、ダウンリンクのための完成したRLC/MACブ
ロックが示されており、参照番号240によって示される8スチールビットを加
えた、図13(b)に示されるフォーマットに対応する。参照番号242は、図
13(b)のビットを示す。
ロックが示されており、参照番号240によって示される8スチールビットを加
えた、図13(b)に示されるフォーマットに対応する。参照番号242は、図
13(b)のビットを示す。
【0099】
第2のユーザが存在しない場合、完全な帯域内信号を保証するために、4ビッ
トより多くのスチールビットが加えられる。
トより多くのスチールビットが加えられる。
【0100】
アップリンクあるいはダウンリンクでは、1392ビットのRLC/MACブ
ロックが、EDGE符号化器の8−PSK変調器に渡される。RLC/MACス
ピーチブロックは、EDGEのデータパケットの伝送の場合のように、4バース
トにわたってインターリーブされることが好ましい。
ロックが、EDGE符号化器の8−PSK変調器に渡される。RLC/MACス
ピーチブロックは、EDGEのデータパケットの伝送の場合のように、4バース
トにわたってインターリーブされることが好ましい。
【0101】
受信機では、逆の復号化ステージが用いられる。受信されたスピーチフレーム
のヘッダに誤りがある場合には、誤り訂正が試みられる。誤り訂正に成功する場
合でも、2つのCRC検査のいずれかが成功しない(3ビットが50クラスIa
ビットを保護するか、あるいは8ビットCRCが65ビットの最重要クラスIビ
ットを保護する)場合には、依然として、受信されるスピーチフレームは破棄さ
れる場合がある。
のヘッダに誤りがある場合には、誤り訂正が試みられる。誤り訂正に成功する場
合でも、2つのCRC検査のいずれかが成功しない(3ビットが50クラスIa
ビットを保護するか、あるいは8ビットCRCが65ビットの最重要クラスIビ
ットを保護する)場合には、依然として、受信されるスピーチフレームは破棄さ
れる場合がある。
【0102】
アップリンクにおいてRLC/MACブロックを生成するための符号化器は、
図12に示されるダウンリンクの場合の符号化器と非常に類似であり、それゆえ
ここでは説明されない。アップリンクの符号化器は、図12に示される符号化器
を単に有効に半分したものであるという点で異なる。アップリンクの符号化器の
動作は、図14を参照しながら最もわかりやすく説明される。
図12に示されるダウンリンクの場合の符号化器と非常に類似であり、それゆえ
ここでは説明されない。アップリンクの符号化器は、図12に示される符号化器
を単に有効に半分したものであるという点で異なる。アップリンクの符号化器の
動作は、図14を参照しながら最もわかりやすく説明される。
【0103】
アップリンクでは、各ユーザは、その関連するスピーチフレームを符号化する
。したがって、図14(a)は、ユーザのうちの1人、たとえば第1のユーザの
ための符号化されないスピーチフレームを示す。再び、図3(b)の好ましいヘ
ッダフォーマットがアップリンクにおいて用いられる。図14(a)に示される
ように、符号化されないスピーチフレームは、図12の16ビットを含むヘッダ
フィールド256と、参照番号258によって示される191クラスIビットと
、参照番号260によって示される78クラスIIビットとを含む。
。したがって、図14(a)は、ユーザのうちの1人、たとえば第1のユーザの
ための符号化されないスピーチフレームを示す。再び、図3(b)の好ましいヘ
ッダフォーマットがアップリンクにおいて用いられる。図14(a)に示される
ように、符号化されないスピーチフレームは、図12の16ビットを含むヘッダ
フィールド256と、参照番号258によって示される191クラスIビットと
、参照番号260によって示される78クラスIIビットとを含む。
【0104】
アップリンクでは、ヘッダの全16ビットが、同じユーザからの2つのスピー
チフレームの実施形態の場合に上記された、クラスIビットでたたみ込み符号化
される。再び、3,1,7たたみ込み符号が用いられ、アップリンクの場合には
、7ビットをパンクチャ処理する必要がある。したがって、アップリンクでは、
たたみ込み符号化器は、図14(b)に示されるような614ビット262を生
成する。アップリンクでは、7ビットしかパンクチャ処理されない。
チフレームの実施形態の場合に上記された、クラスIビットでたたみ込み符号化
される。再び、3,1,7たたみ込み符号が用いられ、アップリンクの場合には
、7ビットをパンクチャ処理する必要がある。したがって、アップリンクでは、
たたみ込み符号化器は、図14(b)に示されるような614ビット262を生
成する。アップリンクでは、7ビットしかパンクチャ処理されない。
【0105】
好ましい実装形態において用いられるパンクチャ処理方式は、クラスIbビッ
トだけのためのものであり、以下のように表すことができる。 b(200+j*49)j=0,1...6, ただしb(i)は3,1符号化器の出力である。この方式では、CRCビットは
全くパンクチャ処理されないであろう。CRCビットは151〜159に配置さ
れる。パンクチャ処理は200で開始し、494で終了する。
トだけのためのものであり、以下のように表すことができる。 b(200+j*49)j=0,1...6, ただしb(i)は3,1符号化器の出力である。この方式では、CRCビットは
全くパンクチャ処理されないであろう。CRCビットは151〜159に配置さ
れる。パンクチャ処理は200で開始し、494で終了する。
【0106】
78クラスIIビットは、上記のように符号化されずに、符号化されたスピー
チフレーム252に含まれ、参照番号264によって示される。
チフレーム252に含まれ、参照番号264によって示される。
【0107】
このように符号化されたスピーチフレーム252には、4つのスチールビット
266が加えられ、これは、図14(c)に示されるようなRLC/MACブロ
ックの半分を表しており、その場合に、図14(b)のビットが参照符号268
によって表される。
266が加えられ、これは、図14(c)に示されるようなRLC/MACブロ
ックの半分を表しており、その場合に、図14(b)のビットが参照符号268
によって表される。
【0108】
インターリーブ方式
この説明は、EDGEシステムに技術を適用することを特に強調している。E
DGEシステムでは、RLC/MACブロックに符号化されるデータパケットが
、4バーストにわたって、ダウンリンクあるいはアップリンク上で伝送されるこ
とが提案されている。すなわち、RLC/MACブロックの1392ビットが、
4つの部分に分割され、各部分が個別のバーストにおいて送信される。
DGEシステムでは、RLC/MACブロックに符号化されるデータパケットが
、4バーストにわたって、ダウンリンクあるいはアップリンク上で伝送されるこ
とが提案されている。すなわち、RLC/MACブロックの1392ビットが、
4つの部分に分割され、各部分が個別のバーストにおいて送信される。
【0109】
当業者にはよく知られているように、各バーストはTDMAフレームの1タイ
ムスロットを占有する。すなわち、TDMAシステムにおける伝送は一連のTD
MAフレームにおいて行われ、それぞれ、多数のタイムスロットに分割される。
専用の物理チャネルを有するパケット交換網において、各タイムスロットは、1
人の特定のユーザに割り当てられ、1回だけ使用するために予約される。その際
、各ユーザは、ダウンリンクおよびアップリンクの両方において、各TDMAフ
レームの自分のタイムスロットで伝送する。
ムスロットを占有する。すなわち、TDMAシステムにおける伝送は一連のTD
MAフレームにおいて行われ、それぞれ、多数のタイムスロットに分割される。
専用の物理チャネルを有するパケット交換網において、各タイムスロットは、1
人の特定のユーザに割り当てられ、1回だけ使用するために予約される。その際
、各ユーザは、ダウンリンクおよびアップリンクの両方において、各TDMAフ
レームの自分のタイムスロットで伝送する。
【0110】
図15(b)を参照すると、GSM/GPRSバーストの標準的なフォーマッ
トが示される。バースト600は、初めに1組の3テールビット606と、その
後に1組の58データビット608と、その後にトレーニングシーケンスを含む
1組の26ビット610と、その後に1組の58データビット612と、その後
にさらに3テールビット614と、最後にガード616を含む1組の8.25ビ
ットとを含む。
トが示される。バースト600は、初めに1組の3テールビット606と、その
後に1組の58データビット608と、その後にトレーニングシーケンスを含む
1組の26ビット610と、その後に1組の58データビット612と、その後
にさらに3テールビット614と、最後にガード616を含む1組の8.25ビ
ットとを含む。
【0111】
図15(a)に示されるように、情報は、TDMAタイムスロット内の物理チ
ャネル上で伝送される。TDMAシステムでは、各TDMA時間フレーム611
は、1組のタイムスロットを含み、図15(a)の例では、各時間フレームは、
1組の8タイムスロットTN1〜TN8を含む。TDMAフレームの各タイムス
ロットTN1〜TN8は、図15(b)に示されるフォーマットを有するバース
トを搬送する。通常、1フレーム内の各タイムスロットは、特定のユーザが使用
するために予約される。
ャネル上で伝送される。TDMAシステムでは、各TDMA時間フレーム611
は、1組のタイムスロットを含み、図15(a)の例では、各時間フレームは、
1組の8タイムスロットTN1〜TN8を含む。TDMAフレームの各タイムス
ロットTN1〜TN8は、図15(b)に示されるフォーマットを有するバース
トを搬送する。通常、1フレーム内の各タイムスロットは、特定のユーザが使用
するために予約される。
【0112】
図15(c)を参照すると、従来のGSM/GPRSシステムにおいて、デー
タRLC/MACブロックをTDMAフレームにインターリーブすることが示さ
れている。ブロック800は、第1のユーザに関連する464ビットの第1のR
LC/MACスピーチブロックを表し、ブロック802は、同じ第1のユーザに
関連する464ビットの第2のRLC/MACスピーチブロックを表し、ブロッ
ク804は、同じユーザに関連する464ビットの第3のRLC/MACスピー
チブロックを表す。
タRLC/MACブロックをTDMAフレームにインターリーブすることが示さ
れている。ブロック800は、第1のユーザに関連する464ビットの第1のR
LC/MACスピーチブロックを表し、ブロック802は、同じ第1のユーザに
関連する464ビットの第2のRLC/MACスピーチブロックを表し、ブロッ
ク804は、同じユーザに関連する464ビットの第3のRLC/MACスピー
チブロックを表す。
【0113】
従来のGSM/GPRSでは、特定のブロック、たとえば第2のブロック80
2の464ビットは、前のブロック800からの後半分のビット(参照番号80
1によって示される)と、次のブロック804からの前半分のビット(参照番号
805によって示される)とを有する、8バーストにわたって(8つのTDMA
フレームで)インターリーブされる。
2の464ビットは、前のブロック800からの後半分のビット(参照番号80
1によって示される)と、次のブロック804からの前半分のビット(参照番号
805によって示される)とを有する、8バーストにわたって(8つのTDMA
フレームで)インターリーブされる。
【0114】
したがって、図15(c)の矢印によって示されるように、ブロック802の
第1の組の58ビット(スチールビットを含む)は、ブロック800の第5の組
の58ビットとともに、第1の時間フレームTF1の第3のタイムスロットにイ
ンターリーブされることは、当業者には十分に理解されよう。ブロック802の
第2の組の58ビットは、ブロック800の第6の組の58ビットとともに、第
2の時間フレームTF2の第3のタイムスロットにインターリーブされる。ブロ
ック802の第3の組の58ビットは、ブロック800の第7の組の58ビット
とともに、第3の時間フレームTF3の第3のタイムスロットにインターリーブ
される。ブロック802の第4の組の58ビットは、ブロック800の第8の組
の58ビットとともに、第4の時間フレームTF4の第3のタイムスロットにイ
ンターリーブされる。ブロック802の第5の組の58ビットは、ブロック80
4の第1の組の58ビットとともに、第5の時間フレームTF5の第3のタイム
スロットにインターリーブされる。ブロック802の第6の組の58ビットは、
ブロック804の第2の組の58ビットとともに、第6の時間フレームTF6の
第3のタイムスロットにインターリーブされる。ブロック802の第7の組の5
8ビットは、ブロック804の第3の組の58ビットとともに、第7の時間フレ
ームTF7の第3のタイムスロットにインターリーブされる。ブロック802の
第8の組の58ビットは、ブロック804の第4の組の58ビットとともに、第
8の時間フレームTF8の第3のタイムスロットにインターリーブされる。その
ビットの組は、相関が最小になるように選択される。
第1の組の58ビット(スチールビットを含む)は、ブロック800の第5の組
の58ビットとともに、第1の時間フレームTF1の第3のタイムスロットにイ
ンターリーブされることは、当業者には十分に理解されよう。ブロック802の
第2の組の58ビットは、ブロック800の第6の組の58ビットとともに、第
2の時間フレームTF2の第3のタイムスロットにインターリーブされる。ブロ
ック802の第3の組の58ビットは、ブロック800の第7の組の58ビット
とともに、第3の時間フレームTF3の第3のタイムスロットにインターリーブ
される。ブロック802の第4の組の58ビットは、ブロック800の第8の組
の58ビットとともに、第4の時間フレームTF4の第3のタイムスロットにイ
ンターリーブされる。ブロック802の第5の組の58ビットは、ブロック80
4の第1の組の58ビットとともに、第5の時間フレームTF5の第3のタイム
スロットにインターリーブされる。ブロック802の第6の組の58ビットは、
ブロック804の第2の組の58ビットとともに、第6の時間フレームTF6の
第3のタイムスロットにインターリーブされる。ブロック802の第7の組の5
8ビットは、ブロック804の第3の組の58ビットとともに、第7の時間フレ
ームTF7の第3のタイムスロットにインターリーブされる。ブロック802の
第8の組の58ビットは、ブロック804の第4の組の58ビットとともに、第
8の時間フレームTF8の第3のタイムスロットにインターリーブされる。その
ビットの組は、相関が最小になるように選択される。
【0115】
EDGE提案書の場合とは異なり、各RLC/MACブロックは4つの時間フ
レームにわたって、それゆえ、図15(d)に示されるような4つの連続した時
間フレームの4つのタイムスロットにわたって伝送される。
レームにわたって、それゆえ、図15(d)に示されるような4つの連続した時
間フレームの4つのタイムスロットにわたって伝送される。
【0116】
図15(d)は、8PSK変調器が用いられる場合のEDGEの構成を示す。
これにより、従来の各バーストは、従来のビットの数、すなわち464(456
ビット +8スチールビット)の3倍を収容できるようになる。したがって、図15(d
)のブロック810によって表される、1392ビットのEDGE RLC/M
ACブロックが、4つの連続したTDMA時間フレームTF1〜TF4にわたっ
て、第3のタイムスロットにインターリーブされる。各タイムスロットは、34
8ビットのデータを搬送する1つのバーストを搬送する。
これにより、従来の各バーストは、従来のビットの数、すなわち464(456
ビット +8スチールビット)の3倍を収容できるようになる。したがって、図15(d
)のブロック810によって表される、1392ビットのEDGE RLC/M
ACブロックが、4つの連続したTDMA時間フレームTF1〜TF4にわたっ
て、第3のタイムスロットにインターリーブされる。各タイムスロットは、34
8ビットのデータを搬送する1つのバーストを搬送する。
【0117】
図15(d)から明らかなように、各バーストは348ビットのデータを搬送
することができ、それゆえ、符号化されたRLC/MACブロックの1392ビ
ットのデータは4バーストにわたって伝送されることができる。しかしながら、
EDGE上で音声を伝送するためにここで記載された実施形態では、1392ビ
ットのデータは2人の異なるユーザからのものである場合があり、各ユーザは各
時間フレーム内の個別のタイムスロットを割り当てられる必要があるのが普通で
あろう。
することができ、それゆえ、符号化されたRLC/MACブロックの1392ビ
ットのデータは4バーストにわたって伝送されることができる。しかしながら、
EDGE上で音声を伝送するためにここで記載された実施形態では、1392ビ
ットのデータは2人の異なるユーザからのものである場合があり、各ユーザは各
時間フレーム内の個別のタイムスロットを割り当てられる必要があるのが普通で
あろう。
【0118】
特に有利な伝送方式を実現しやすくするために、ここでは、ダウンリンクおよ
びアップリンクの両方のTDMAフレーム内のタイムスロットを2人のユーザが
共有する方式が提案される。この方式は、上記の技術にしたがって符号化される
、EDGE上の2人の異なるユーザからのスピーチフレームを伝送することに有
利に適用されることができる。
びアップリンクの両方のTDMAフレーム内のタイムスロットを2人のユーザが
共有する方式が提案される。この方式は、上記の技術にしたがって符号化される
、EDGE上の2人の異なるユーザからのスピーチフレームを伝送することに有
利に適用されることができる。
【0119】
本明細書において提案される新しい技術によれば、2人の各ユーザからのデー
タは、共通の時間フレームにおいて伝送される。図13(c)を参照すると、符
号化されたRLC/MACブロックは、第1のユーザに関連する696ビット(
4スチールビットを含む)と、第2のユーザに関連する696ビット(4スチー
ルビットを含む)とを含む。新しい技術によれば、ダウンリンクにおいて、第1
のユーザに関連する符号化されたビットの4分の1が、4つの連続したフレーム
上の各フレームの割り当てられたタイムスロットにおいて伝送され、第2のユー
ザに関連する符号化されたビットの4分の1が、同じ4つの連続したフレーム上
の各時間フレームの同じ割り当てられたタイムスロットにおいて伝送される。
タは、共通の時間フレームにおいて伝送される。図13(c)を参照すると、符
号化されたRLC/MACブロックは、第1のユーザに関連する696ビット(
4スチールビットを含む)と、第2のユーザに関連する696ビット(4スチー
ルビットを含む)とを含む。新しい技術によれば、ダウンリンクにおいて、第1
のユーザに関連する符号化されたビットの4分の1が、4つの連続したフレーム
上の各フレームの割り当てられたタイムスロットにおいて伝送され、第2のユー
ザに関連する符号化されたビットの4分の1が、同じ4つの連続したフレーム上
の各時間フレームの同じ割り当てられたタイムスロットにおいて伝送される。
【0120】
したがって、タイムスロットTN3が2人のユーザに割り当てられるものとす
る。時間フレームTF1のタイムスロットTN3では、第1のユーザに関連する
符号化された174ビット(1スチールビットを含む)のRLC/MACが、そ
のバーストのデータ部608において伝送され、第2のユーザに関連する符号化
された174ビット(1スチールビットを含む)RLC/MACが、そのバース
トのデータ部612において伝送される。時間フレームTF2のタイムスロット
TN3では、第1のユーザに関連する符号化された、さらに別の174ビット(
1スチールビットを含む)RLC/MACが、そのバーストのデータ部608に
おいて伝送され、第2のユーザに関連する符号化された、さらに別の174ビッ
ト(1スチールビットを含む)RLC/MACが、そのバーストのデータ部61
2において伝送される。これはその後、さらに2つのバーストの場合に繰り返さ
れ、全1392ビットのバーストが4つの連続したバーストにおいて伝送される
。
る。時間フレームTF1のタイムスロットTN3では、第1のユーザに関連する
符号化された174ビット(1スチールビットを含む)のRLC/MACが、そ
のバーストのデータ部608において伝送され、第2のユーザに関連する符号化
された174ビット(1スチールビットを含む)RLC/MACが、そのバース
トのデータ部612において伝送される。時間フレームTF2のタイムスロット
TN3では、第1のユーザに関連する符号化された、さらに別の174ビット(
1スチールビットを含む)RLC/MACが、そのバーストのデータ部608に
おいて伝送され、第2のユーザに関連する符号化された、さらに別の174ビッ
ト(1スチールビットを含む)RLC/MACが、そのバーストのデータ部61
2において伝送される。これはその後、さらに2つのバーストの場合に繰り返さ
れ、全1392ビットのバーストが4つの連続したバーストにおいて伝送される
。
【0121】
図16を参照すると、図13(c)のRLC/MACブロックを伝送するため
に、そのような方式がダウンリンクに適用される原理がさらに例示される。
に、そのような方式がダウンリンクに適用される原理がさらに例示される。
【0122】
参照番号400によって示されるブロックは、最初のチャネル符号化の前の、
20ms時間フレーム内の第1のユーザに関連する160サンプルの音声を表す
。矢印404によって表されるように、これらの160サンプルは、参照番号4
08によって示されるような、第1のユーザのために260ビットスピーチフレ
ームに符号化され、それは、予備符号化回路104の出力108上のビットの組
になる。これらの260ビットは依然として20ms時間を占有する。その後、
260ビットのスピーチフレームは、出力回路116の出力149上のRLC/
MACブロックの半分を構成する696ビットに符号化され、そのステップが矢
印412によって表される。696ビットのRLC/MACブロックは、参照番
号416によって示される。
20ms時間フレーム内の第1のユーザに関連する160サンプルの音声を表す
。矢印404によって表されるように、これらの160サンプルは、参照番号4
08によって示されるような、第1のユーザのために260ビットスピーチフレ
ームに符号化され、それは、予備符号化回路104の出力108上のビットの組
になる。これらの260ビットは依然として20ms時間を占有する。その後、
260ビットのスピーチフレームは、出力回路116の出力149上のRLC/
MACブロックの半分を構成する696ビットに符号化され、そのステップが矢
印412によって表される。696ビットのRLC/MACブロックは、参照番
号416によって示される。
【0123】
同様に、第2のユーザの場合、矢印406、410および414がそれぞれ、
矢印400、408および416によって示される機能に直接対応する。第2の
ユーザの場合に示されるブロック402、410および414は、第1のユーザ
の場合のブロック404、412および416に直接対応する。
矢印400、408および416によって示される機能に直接対応する。第2の
ユーザの場合に示されるブロック402、410および414は、第1のユーザ
の場合のブロック404、412および416に直接対応する。
【0124】
こうして、ブロック418は、第2のユーザに関連する図13(c)のRLC
/MACブロックの696ビットの組に対応する。
/MACブロックの696ビットの組に対応する。
【0125】
TDMAフレームの第3のタイムスロットが両方にユーザに割り当てられる。
第1のフレームTF1では、各ユーザのための符号化されたデータと2つの各ス
テアリングビットとを加えたものの最初の4分の1が伝送される。第2のフレー
ムTF2では、各ユーザのための符号化されたデータと2つの各スチールビット
とを加えたものの2番目の4分の1が伝送される。第3のフレームTF3では、
各ユーザのための符号化されたデータと2つの各スチールビットとを加えたもの
の3番目の4分の1が伝送される。第4のフレームTF4では、各ユーザのため
の符号化されたデータと2つの各スチールビットとを加えたものの4番目の4分
の1が伝送される。こうして、全てのRLC/MACブロックが4つのバースト
あるいはタイムスロットにわたって伝送される。
第1のフレームTF1では、各ユーザのための符号化されたデータと2つの各ス
テアリングビットとを加えたものの最初の4分の1が伝送される。第2のフレー
ムTF2では、各ユーザのための符号化されたデータと2つの各スチールビット
とを加えたものの2番目の4分の1が伝送される。第3のフレームTF3では、
各ユーザのための符号化されたデータと2つの各スチールビットとを加えたもの
の3番目の4分の1が伝送される。第4のフレームTF4では、各ユーザのため
の符号化されたデータと2つの各スチールビットとを加えたものの4番目の4分
の1が伝送される。こうして、全てのRLC/MACブロックが4つのバースト
あるいはタイムスロットにわたって伝送される。
【0126】
好ましい実施形態では、符号化されたビットは、以下に記載される規則にした
がって、並べ替えられ、インターリーブされる。 i(B,j)=c(n,k) for: k=0,1,...,691 n=0,1,...,n,n+1n... ただしnはフレーム番号である。
がって、並べ替えられ、インターリーブされる。 i(B,j)=c(n,k) for: k=0,1,...,691 n=0,1,...,n,n+1n... ただしnはフレーム番号である。
【0127】
インターリーブを行った結果は、偶数の番号を付されたビットの最初の2ブロ
ック(B=B0+2N+0,1)と、奇数の番号を付されたビットの最後の2ブ
ロック(B=B0+2N+2,3)とを用いる、4ブロックにわたって所与のユ
ーザの1つのスピーチブロック、n=Nの並べ替えられた692ビットの分布に
なる。第2のユーザのスピーチブロック、n=Kの並べ替えられたビットは、奇
数の番号を付されたビットの最初の2ブロック(B=B0+2N+0,1)と、
偶数の番号を付されたビットの最後の2ブロック(B=B0+2N+2,3)と
を用いる。
ック(B=B0+2N+0,1)と、奇数の番号を付されたビットの最後の2ブ
ロック(B=B0+2N+2,3)とを用いる、4ブロックにわたって所与のユ
ーザの1つのスピーチブロック、n=Nの並べ替えられた692ビットの分布に
なる。第2のユーザのスピーチブロック、n=Kの並べ替えられたビットは、奇
数の番号を付されたビットの最初の2ブロック(B=B0+2N+0,1)と、
偶数の番号を付されたビットの最後の2ブロック(B=B0+2N+2,3)と
を用いる。
【0128】
そのマッピングは以下の規則によって与えられる。
e(B,j)=i(B,j)and e(B,176+j)=i(B,174+j)for j=0,1...,173
and
e(B,174)=SB(2B)and e(B,175)=SB(2B+1)
【0129】
バースト番号B上でSB(2B)およびSB(2B+1)を付された2つのビ
ットは、制御チャネルシグナリングを示すためのフラグである。
ットは、制御チャネルシグナリングを示すためのフラグである。
【0130】
アップリンクでは、いずれのユーザも他のユーザと同期していないため、図1
6を参照して提案される技術は適切ではない。しかしながら、その技術を適用す
ることは依然として可能であり、4つの連続したバーストにわたって1392ビ
ットのRLC/MACブロックを伝送するために、同じタイムスロットを2人の
ユーザが共有するという概念が依然として用いられる。
6を参照して提案される技術は適切ではない。しかしながら、その技術を適用す
ることは依然として可能であり、4つの連続したバーストにわたって1392ビ
ットのRLC/MACブロックを伝送するために、同じタイムスロットを2人の
ユーザが共有するという概念が依然として用いられる。
【0131】
再び、タイムスロットTN3が2人のユーザに割り当てられるものとする。時
間フレームTF1のタイムスロットTN3では、第1のユーザに関連する符号化
された174ビット(1スチールビットを含む)のRLC/MACがそのバース
トのデータ部608において伝送され、第1のユーザに関連する符号化された、
さらに別の174ビット(1スチールビットを含む)のRLC/MACがそのバ
ーストのデータ部612において伝送される。時間フレームTF2のタイムスロ
ットT3では、第2のユーザに関連する符号化された174ビット(1スチール
ビットを含む)のRLC/MACがそのバーストのデータ部608において伝送
され、第2のユーザに関連する符号化された、さらに別の174ビット(1スチ
ールビットを含む)のRLC/MACがそのバーストのデータ部612において
伝送される。その後、第1のユーザに関連する残りのビットが第3の時間フレー
ムTF3において伝送され、さらにその後、第2のユーザに関連する残りのビッ
トが第4の時間フレームにおいて伝送される。
間フレームTF1のタイムスロットTN3では、第1のユーザに関連する符号化
された174ビット(1スチールビットを含む)のRLC/MACがそのバース
トのデータ部608において伝送され、第1のユーザに関連する符号化された、
さらに別の174ビット(1スチールビットを含む)のRLC/MACがそのバ
ーストのデータ部612において伝送される。時間フレームTF2のタイムスロ
ットT3では、第2のユーザに関連する符号化された174ビット(1スチール
ビットを含む)のRLC/MACがそのバーストのデータ部608において伝送
され、第2のユーザに関連する符号化された、さらに別の174ビット(1スチ
ールビットを含む)のRLC/MACがそのバーストのデータ部612において
伝送される。その後、第1のユーザに関連する残りのビットが第3の時間フレー
ムTF3において伝送され、さらにその後、第2のユーザに関連する残りのビッ
トが第4の時間フレームにおいて伝送される。
【0132】
図17を参照すると、図13(c)のRLC/MACブロックを伝送するため
に、そのような方式がアップリンクに適用される原理をさらに例示する。
に、そのような方式がアップリンクに適用される原理をさらに例示する。
【0133】
図17のブロック400、408および416は、図16の同様の参照番号と
同じブロックに対応し、第1のユーザに関連する。図17のブロック402、4
10および418は、図16の同様の参照番号と同じブロックに対応し、第2の
ユーザに関連する。
同じブロックに対応し、第1のユーザに関連する。図17のブロック402、4
10および418は、図16の同様の参照番号と同じブロックに対応し、第2の
ユーザに関連する。
【0134】
第1のユーザのための696ビットのRLC/MACブロックは参照番号41
6によって示され、第2のユーザのための696ビットのRLC/MACブロッ
クは参照番号418によって示される。
6によって示され、第2のユーザのための696ビットのRLC/MACブロッ
クは参照番号418によって示される。
【0135】
同様に、第2のユーザの場合、矢印406、410および414はそれぞれ、
矢印400、408および416によって示される機能に直接対応する。第2の
ユーザの場合に示されるブロック402、410および414は、第1のユーザ
のブロック404、412および416に直接対応する。
矢印400、408および416によって示される機能に直接対応する。第2の
ユーザの場合に示されるブロック402、410および414は、第1のユーザ
のブロック404、412および416に直接対応する。
【0136】
696ビットの符号化されたRLC/MACブロックは、2つの偶数/奇数バ
ーストにわたってインターリーブされ、8−PSK変調器に渡される。
ーストにわたってインターリーブされ、8−PSK変調器に渡される。
【0137】
アップリンクでは、符号化されたビットは、以下の規則にしたがって、並べ替
えられ、インターリーブされることが好ましい。 i(B,j)=c(n,k)for k=0,1,...,691 n=0,1,...,N,N+1
えられ、インターリーブされることが好ましい。 i(B,j)=c(n,k)for k=0,1,...,691 n=0,1,...,N,N+1
【0138】
インターリーブを行った結果は、2つの偶数ブロック(B=B0+2N+0,
2)にわたる、ユーザの1つのスピーチブロック、n=Nの並べ替えられた69
2ビットの分布になり、ユーザの2つのスピーチブロック、n=Kの並べ替えら
れたビットは奇数ブロック(B=B0+2N+1,3)を用いる。
2)にわたる、ユーザの1つのスピーチブロック、n=Nの並べ替えられた69
2ビットの分布になり、ユーザの2つのスピーチブロック、n=Kの並べ替えら
れたビットは奇数ブロック(B=B0+2N+1,3)を用いる。
【0139】
マッピングは以下の規則によって与えられる。
e(B,j)=i(B,j)and e(B,176+j)=i(B,174+j)for j=0,1,...,173
and
e(B,174)=SB(2B)and e(B,175)=SB(2B+1)
【0140】
バースト番号B上でSB(2B)およびSB(2B+1)を付された2つのビ
ットは、制御チャネルシグナリングを示すためのフラグである。
ットは、制御チャネルシグナリングを示すためのフラグである。
【0141】
異なるユーザからの2つのスピーチフレーム‐ケースII
図18を参照すると、パケット交換網のダウンリンクにおいて、2人の異なる
ユーザからの2つのスピーチフレームを符号化するための第2の実施形態を例示
するブロック図が示される。図18のダウンリンク符号化器は、図12のダウン
リンク符号化器に概ね対応し、同様の構成要素を示すために、同様の参照番号が
用いられている。主な違いは、パンクチャ処理を伴うたたみ込み符号化回路12
6および128を、パンクチャ処理を伴う1つのたたみ込み符号化回路127に
結合していることにある。
ユーザからの2つのスピーチフレームを符号化するための第2の実施形態を例示
するブロック図が示される。図18のダウンリンク符号化器は、図12のダウン
リンク符号化器に概ね対応し、同様の構成要素を示すために、同様の参照番号が
用いられている。主な違いは、パンクチャ処理を伴うたたみ込み符号化回路12
6および128を、パンクチャ処理を伴う1つのたたみ込み符号化回路127に
結合していることにある。
【0142】
この実施形態では、図1(a)に示されるダウンリンクのためのヘッダが用い
られる。
られる。
【0143】
第1のユーザからの244ビットの第1のスピーチフレームU1SF1が信号
線100上で受信され、第2のユーザからの244ビットの第1のスピーチフレ
ームU2SF1が信号線102上で受信される。244ビットスピーチフレーム
U1SF1およびU2SF1はそれぞれ、図7および図12を参照して厳密に先
に記載されたように、予備符号化回路104および106と、ブロック符号回路
112および118とによって処理される。
線100上で受信され、第2のユーザからの244ビットの第1のスピーチフレ
ームU2SF1が信号線102上で受信される。244ビットスピーチフレーム
U1SF1およびU2SF1はそれぞれ、図7および図12を参照して厳密に先
に記載されたように、予備符号化回路104および106と、ブロック符号回路
112および118とによって処理される。
【0144】
リオーダ回路120は、図7および図12を参照して先に記載されたのと全く
同じように、信号線124上の53クラスIaビットと、信号線110上の13
2クラスIIビットとを処理する。したがって、リオーダ回路120は、信号線
130上のテールビット入力TBにおいて供給される6テールビットを含む、並
べ替えられた191ビットを生成する。
同じように、信号線124上の53クラスIaビットと、信号線110上の13
2クラスIIビットとを処理する。したがって、リオーダ回路120は、信号線
130上のテールビット入力TBにおいて供給される6テールビットを含む、並
べ替えられた191ビットを生成する。
【0145】
しかしながら、リオーダ回路114は、図7および図12のリオーダ回路11
4に対して変更される。図18のリオーダ回路114は、テールビットを受信せ
ず、それゆえ、その入力185ビットは出力信号線122上に与えられる。リオ
ーダブロック114にテールビットが与えられない理由は、図19を参照すれば
、最も容易に理解されよう。
4に対して変更される。図18のリオーダ回路114は、テールビットを受信せ
ず、それゆえ、その入力185ビットは出力信号線122上に与えられる。リオ
ーダブロック114にテールビットが与えられない理由は、図19を参照すれば
、最も容易に理解されよう。
【0146】
図19(a)は、RLC/MACブロックのためのフォーマットに符号化する
前の、2つのスピーチフレーム、およびその関連するヘッダのフォーマットを示
す。
前の、2つのスピーチフレーム、およびその関連するヘッダのフォーマットを示
す。
【0147】
信号線138上の第1のユーザのヘッダからの3ビットのUSFフィールドは
、参照番号282によって示される。信号線139上の第2のユーザのヘッダか
らの3ビットのUSFフィールドは、参照番号284によって示される。信号1
38上の第1のユーザのヘッダからの残りの8ビットは参照番号286によって
示され、信号138上の第2のユーザのヘッダからの残りの8ビットは参照番号
288によって示される。信号線122上の第1のユーザからの185クラスI
ビットは参照番号290によって示され、信号線125上の第2のユーザからの
191クラスIビットは参照番号292によって示される。信号線108上の第
1のユーザからの78クラスIIビットは参照番号294によって示され、信号
線110上の第2のユーザからの78クラスIIビットは参照番号296によっ
て示される。
、参照番号282によって示される。信号線139上の第2のユーザのヘッダか
らの3ビットのUSFフィールドは、参照番号284によって示される。信号1
38上の第1のユーザのヘッダからの残りの8ビットは参照番号286によって
示され、信号138上の第2のユーザのヘッダからの残りの8ビットは参照番号
288によって示される。信号線122上の第1のユーザからの185クラスI
ビットは参照番号290によって示され、信号線125上の第2のユーザからの
191クラスIビットは参照番号292によって示される。信号線108上の第
1のユーザからの78クラスIIビットは参照番号294によって示され、信号
線110上の第2のユーザからの78クラスIIビットは参照番号296によっ
て示される。
【0148】
図19(a)を検討し、それを図13(a)と比較することから明らかになる
ように、図19(a)の符号化されないブロック内のフィールドは、各ユーザか
らの同じフィールドが隣接するように配列し直されている。これは、互いに隣接
して各ブロックの2つのクラスIフィールドを配置することによる利点を導入す
る。上記のように、たたみ込み符号化器を終端するためのテールとして、6テー
ルビットが、クラスIビットに導入される。2組のクラスIビットを一緒に配置
し、それらを一緒に符号化することにより、1つの組のクラスIビットのための
テールビットの組を削除することができる。こうして、第1のユーザに関連する
テールビットの組が削除され、それゆえ、リオーダ回路114に必要とされるの
は、185ビットを生成することだけであり、テールビットを含む必要はない。
ように、図19(a)の符号化されないブロック内のフィールドは、各ユーザか
らの同じフィールドが隣接するように配列し直されている。これは、互いに隣接
して各ブロックの2つのクラスIフィールドを配置することによる利点を導入す
る。上記のように、たたみ込み符号化器を終端するためのテールとして、6テー
ルビットが、クラスIビットに導入される。2組のクラスIビットを一緒に配置
し、それらを一緒に符号化することにより、1つの組のクラスIビットのための
テールビットの組を削除することができる。こうして、第1のユーザに関連する
テールビットの組が削除され、それゆえ、リオーダ回路114に必要とされるの
は、185ビットを生成することだけであり、テールビットを含む必要はない。
【0149】
このビットの省略の結果、たたみ込み符号の実装形態がより効率的になる。パ
ンクチャ処理を伴う結合されたたたみ込み符号化回路は、各ヘッダの2つの残り
の組の8ビットと、2つの組のクラスIビットとを、上記のような3,1,7た
たみ込み符号を用いることにより、1組の1112ビットに符号化する。そのパ
ンクチャ処理を伴うたたみこみ符号化器は16ビットを削除する。符号化された
スピーチフレームは図19(b)に示される。たたみ込み符号化された1112
ビットは、参照番号300によって示される。
ンクチャ処理を伴う結合されたたたみ込み符号化回路は、各ヘッダの2つの残り
の組の8ビットと、2つの組のクラスIビットとを、上記のような3,1,7た
たみ込み符号を用いることにより、1組の1112ビットに符号化する。そのパ
ンクチャ処理を伴うたたみこみ符号化器は16ビットを削除する。符号化された
スピーチフレームは図19(b)に示される。たたみ込み符号化された1112
ビットは、参照番号300によって示される。
【0150】
そのパンクチャ処理方式はクラスIbビットに対してのみ適用され、その好ま
しい方式は以下の式によって表される。 b(200+j*49)j=0,1...7, ただしb(i)は3,1,7符号化器の出力である。 また、 b(755+j*49)j=8,...15, ただしb(i)は3,1,7符号化器の出力である。全ビット数は1128から
1112に低減される。
しい方式は以下の式によって表される。 b(200+j*49)j=0,1...7, ただしb(i)は3,1,7符号化器の出力である。 また、 b(755+j*49)j=8,...15, ただしb(i)は3,1,7符号化器の出力である。全ビット数は1128から
1112に低減される。
【0151】
図12を参照して先に記載されたように、3ビットUSFフィールドはそれぞ
れ、ブロック符号回路140および141において、上記のブロック符号を用い
て36ビットのそれぞれの組に符号化される。第1のユーザに対応する36ビッ
トは参照番号302によって示され、第2のユーザに対応する36ビットは参照
番号304によって示される。
れ、ブロック符号回路140および141において、上記のブロック符号を用い
て36ビットのそれぞれの組に符号化される。第1のユーザに対応する36ビッ
トは参照番号302によって示され、第2のユーザに対応する36ビットは参照
番号304によって示される。
【0152】
78クラスIIビットの各組は上記のように符号化されず、参照番号306お
よび308によって示される。
よび308によって示される。
【0153】
図19(c)を参照すると、最終的に符号化されたRLC/MACブロック3
10が示されており、それは、参照番号314によって示される4スチールビッ
トとともに、参照番号312によって示される、図19(b)からの1388ビ
ットを含む。
10が示されており、それは、参照番号314によって示される4スチールビッ
トとともに、参照番号312によって示される、図19(b)からの1388ビ
ットを含む。
【0154】
この実施形態では、ダウンリンクは、RLC/MACブロックを4バーストに
インターリーブするために、図16において導入されたインターリーブ技術を用
いる。
インターリーブするために、図16において導入されたインターリーブ技術を用
いる。
【0155】
この特定の実施形態の場合、アップリンク上で符号化するために、以下に記載
される2つの別の技術が存在する。アップリンクにおける異なるユーザからの2
つのスピーチフレームの第1の実施形態の場合に先に記載されたように、ユーザ
はいずれも他のユーザについての情報を持たず、それゆえ、各ユーザからの各ス
ピーチフレームは個別に符号化される。
される2つの別の技術が存在する。アップリンクにおける異なるユーザからの2
つのスピーチフレームの第1の実施形態の場合に先に記載されたように、ユーザ
はいずれも他のユーザについての情報を持たず、それゆえ、各ユーザからの各ス
ピーチフレームは個別に符号化される。
【0156】
図20は、アップリンク符号化の第1の例を示す。図20(a)では、図1(
b)のヘッダに対応する参照番号326によって示されるヘッダと、参照番号3
28によって示される1組の191クラスIビットと、参照番号330によって
示される1組の78クラスIIビットとを有する符号化されないスピーチブロッ
ク322が示される。
b)のヘッダに対応する参照番号326によって示されるヘッダと、参照番号3
28によって示される1組の191クラスIビットと、参照番号330によって
示される1組の78クラスIIビットとを有する符号化されないスピーチブロッ
ク322が示される。
【0157】
符号化されたスピーチブロック322は図20(b)に示される。この例では
、アップリンクヘッダおよびクラスIビットの組が、28ビットをパンクチャ処
理して、2,1,7たたみ込み符号によって一緒に符号化される。
、アップリンクヘッダおよびクラスIビットの組が、28ビットをパンクチャ処
理して、2,1,7たたみ込み符号によって一緒に符号化される。
【0158】
クラスIbビットのみに対して適用される好ましいパンクチャ処理方式は以下
の通りである。 b(110+j*10)j=0,1...27, ただしb(i)は1/2符号化器の出力である。全ビット数は402から374
に低減される。
の通りである。 b(110+j*10)j=0,1...27, ただしb(i)は1/2符号化器の出力である。全ビット数は402から374
に低減される。
【0159】
この結果、参照番号322によって示されるような1組の374ビットになる
。上記のように、78クラスIIビットは符号化されないままであり、参照番号
334によって示される。
。上記のように、78クラスIIビットは符号化されないままであり、参照番号
334によって示される。
【0160】
最後に、伝送するためのRLC/MACブロック324が図20(c)に示さ
れており、参照番号328によって示される4スチールビットとともに、参照番
号326によって示される、図20(b)の全てのビットを含む。
れており、参照番号328によって示される4スチールビットとともに、参照番
号326によって示される、図20(b)の全てのビットを含む。
【0161】
第2のユーザのスピーチフレームも同様に符号化され、その結果、図20(c
)のブロックと同一のフォーマットを有するRLC/MACブロックになる。
)のブロックと同一のフォーマットを有するRLC/MACブロックになる。
【0162】
新しいバースト構造
図21は、標準のバーストの従来の構造を示しており、図15(b)を参照し
て先に図示および記載されたものと同じである。しかしながら、図21では、バ
ーストの各部内のビット数が、8PSK変調を用いて収容することができるビッ
ト数に対応する。
て先に図示および記載されたものと同じである。しかしながら、図21では、バ
ーストの各部内のビット数が、8PSK変調を用いて収容することができるビッ
ト数に対応する。
【0163】
以下の説明では、GSM/GPRSバースト構造に基づく新しいバースト構造
が提案されており、それは、図20を参照して記載された、アップリンクのため
の符号化技術を用いる点で有利である。図22を参照すると、図21のバースト
構造に等しい長さを有するが、テール部618、626、630および638と
、データ部620、624、632および636と、トレーニングシーケンス6
22および634と、ガード部628および640とを有する新しいバースト構
造602が示される。456ビットの符号化されたRLC/MACブロックは、
4つの半バーストにわたってインターリーブされ、8PSK変調器に渡される。
が提案されており、それは、図20を参照して記載された、アップリンクのため
の符号化技術を用いる点で有利である。図22を参照すると、図21のバースト
構造に等しい長さを有するが、テール部618、626、630および638と
、データ部620、624、632および636と、トレーニングシーケンス6
22および634と、ガード部628および640とを有する新しいバースト構
造602が示される。456ビットの符号化されたRLC/MACブロックは、
4つの半バーストにわたってインターリーブされ、8PSK変調器に渡される。
【0164】
図23は、アップリンク符号化の第2の例を示す。図23(a)では、図20
(a)の符号化されないスピーチブロック320が示される。
(a)の符号化されないスピーチブロック320が示される。
【0165】
符号化されたスピーチブロック340は図23(b)に示される。この例では
、アップリンクヘッダおよびクラスIビットの組が、181ビットをパンクチャ
処理して、3,1,7たたみ込み符号によって一緒に符号化される。
、アップリンクヘッダおよびクラスIビットの組が、181ビットをパンクチャ
処理して、3,1,7たたみ込み符号によって一緒に符号化される。
【0166】
この方式は、前のセクションの(2,1,7)たたみ込み符号ではなく、(3
,1,7)たたみ込み符号を用いる。この符号は、良好な符号化利得を有するが
、より多くのビットを生成し、多くのパンクチャ処理が行われなければならない
。
,1,7)たたみ込み符号を用いる。この符号は、良好な符号化利得を有するが
、より多くのビットを生成し、多くのパンクチャ処理が行われなければならない
。
【0167】
パンクチャ処理方式は以下の通りである。
b(43+j*3)j=0,1...44,
ただしb(i)は1/3符号化器の出力である。また、
b(193+j*3)j=0,1...135,
ただしb(i)は1/3符号化器の出力である。この方式は、ヘッダあるいはC
RCビットを全くパンクチャ処理しないであろう。ヘッダは、ビット1〜30に
配置され、CRCはビット181〜189に配置される。
RCビットを全くパンクチャ処理しないであろう。ヘッダは、ビット1〜30に
配置され、CRCはビット181〜189に配置される。
【0168】
この結果は、参照番号342によって示されるような1組の422ビットにな
る。上記のように、78クラスIIビットは符号化されないままであり、参照番
号344によって示される。
る。上記のように、78クラスIIビットは符号化されないままであり、参照番
号344によって示される。
【0169】
最後に、伝送するためのRLC/MACブロック350が図23(c)に示さ
れており、参照番号346によって示される4スチールビットとともに、参照番
号348によって示される、図23(b)の全てのビットを含む。
れており、参照番号346によって示される4スチールビットとともに、参照番
号348によって示される、図23(b)の全てのビットを含む。
【0170】
第2のユーザのスピーチフレームは同様に符号化され、その結果、図23(c
)と同じフォーマットを有するRLC/MACブロックになる。
)と同じフォーマットを有するRLC/MACブロックになる。
【0171】
図24を参照すると、再び図21のバースト構造に等しい長さを有するが、テ
ール部642、650、652および660と、データ部644、648、65
4および658と、トレーニングシーケンス646および656とを有する、図
22の新しいバースト構造604のさらに別の適用形態が示される。したがって
、図24の新しいバースト構造は、図22の新しいバースト構造に対応するが、
ガードバンドを持たない。図23の符号化された504ビットのRLC/MAC
ブロックは、4つの半バーストにわたってインターリーブされ、8PSK変調器
に渡される。
ール部642、650、652および660と、データ部644、648、65
4および658と、トレーニングシーケンス646および656とを有する、図
22の新しいバースト構造604のさらに別の適用形態が示される。したがって
、図24の新しいバースト構造は、図22の新しいバースト構造に対応するが、
ガードバンドを持たない。図23の符号化された504ビットのRLC/MAC
ブロックは、4つの半バーストにわたってインターリーブされ、8PSK変調器
に渡される。
【0172】
図25を参照すると、図20を参照して先に記載された符号化技術と、符号化
されたRLC/MACブロックを新しいバースト構造にインターリーブの一例が
示される。図25のブロック400、408および416は、図17の同様の参
照番号と同じブロックに対応し、第1のユーザに関連する。同様に、図25のブ
ロック402、410および418は、図17の同様の参照番号と同じブロック
を指し、第2のユーザに関連する。この例では、ブロック416および418は
それぞれ、第1および第2の各ユーザの場合の図20(c)の456ビットに対
応する456ビットを含む。
されたRLC/MACブロックを新しいバースト構造にインターリーブの一例が
示される。図25のブロック400、408および416は、図17の同様の参
照番号と同じブロックに対応し、第1のユーザに関連する。同様に、図25のブ
ロック402、410および418は、図17の同様の参照番号と同じブロック
を指し、第2のユーザに関連する。この例では、ブロック416および418は
それぞれ、第1および第2の各ユーザの場合の図20(c)の456ビットに対
応する456ビットを含む。
【0173】
図25に示されるように、各時間フレームは1タイムスロットを含み、そのタ
イムスロットは第3のタイムスロットTN3であるものと想定され、2つのタイ
ムスロットに分割される。したがって、第1の時間フレームTF1では、第3の
タイムスロット900は、第1のサブタイムスロット908および第2のサブタ
イムスロット910に分割される。第2の時間フレームTF2では、第3のタイ
ムスロット902は、第1のサブタイムスロット912および第2のサブタイム
スロット914に分割される。第3の時間フレームTF3では、第3のタイムス
ロット904は、第1のサブタイムスロット916および第2のサブタイムスロ
ット918に分割される。第4の時間フレームTF4では、第3のタイムスロッ
ト906は、第1のサブタイムスロット920および第2のサブタイムスロット
922に分割される。各時間フレームの他のタイムスロットは、図面を明瞭にす
るために示されない。
イムスロットは第3のタイムスロットTN3であるものと想定され、2つのタイ
ムスロットに分割される。したがって、第1の時間フレームTF1では、第3の
タイムスロット900は、第1のサブタイムスロット908および第2のサブタ
イムスロット910に分割される。第2の時間フレームTF2では、第3のタイ
ムスロット902は、第1のサブタイムスロット912および第2のサブタイム
スロット914に分割される。第3の時間フレームTF3では、第3のタイムス
ロット904は、第1のサブタイムスロット916および第2のサブタイムスロ
ット918に分割される。第4の時間フレームTF4では、第3のタイムスロッ
ト906は、第1のサブタイムスロット920および第2のサブタイムスロット
922に分割される。各時間フレームの他のタイムスロットは、図面を明瞭にす
るために示されない。
【0174】
したがって、この技術によれば、第1のユーザに関連し、ブロック416によ
って表される456ビットの4分の1が、4つのサブタイムスロット908、9
12、916および920のそれぞれにおいて伝送される。第2のユーザに関連
し、ブロック418によって表される456ビットの4分の1が、4つのサブタ
イムスロット910、914、918および922のそれぞれにおいて伝送され
る。各サブタイムスロットのバースト構造は、図22のバースト構造に対応する
。
って表される456ビットの4分の1が、4つのサブタイムスロット908、9
12、916および920のそれぞれにおいて伝送される。第2のユーザに関連
し、ブロック418によって表される456ビットの4分の1が、4つのサブタ
イムスロット910、914、918および922のそれぞれにおいて伝送され
る。各サブタイムスロットのバースト構造は、図22のバースト構造に対応する
。
【0175】
このようにして、従来のタイムスロットによって形成される各物理チャネルは
2つの物理チャネルになる。このようにして、8物理チャネルシステムを、16
物理チャネルシステムにすることができる。
2つの物理チャネルになる。このようにして、8物理チャネルシステムを、16
物理チャネルシステムにすることができる。
【0176】
こうして、元のバーストは2つの個別のバーストとして処理されることができ
る。第1のユーザの情報は第1の新しいバースト(元のバーストの上位半分)を
占有し、第2のユーザの情報は第2の新しいバースト(元のバーストの下位半分
)を占有するであろう。従来のGSM/GPRS方法によってインターリーブが
行われる場合があるが、図22のバースト構造のための456の新しいサイズ、
および図24のバースト構造のための504の新しいサイズを用いることになる
。
る。第1のユーザの情報は第1の新しいバースト(元のバーストの上位半分)を
占有し、第2のユーザの情報は第2の新しいバースト(元のバーストの下位半分
)を占有するであろう。従来のGSM/GPRS方法によってインターリーブが
行われる場合があるが、図22のバースト構造のための456の新しいサイズ、
および図24のバースト構造のための504の新しいサイズを用いることになる
。
【0177】
各タイムスロットを、より多くの数のサブタイムスロットに分割することが可
能である。したがって、一般に、1つのタイムスロットが標準的にnビットを有
するバースト構造を支持する場合には、各タイムスロットは、mサブタイムスロ
ットに分割される場合があり、n/mビットを有する対応するバースト構造内の
各サブタイムスロットにおいてビットが伝送される。
能である。したがって、一般に、1つのタイムスロットが標準的にnビットを有
するバースト構造を支持する場合には、各タイムスロットは、mサブタイムスロ
ットに分割される場合があり、n/mビットを有する対応するバースト構造内の
各サブタイムスロットにおいてビットが伝送される。
【0178】
一般的な場合には、p人のユーザからのデータが、それぞれが1/pビットの
RLC/MACブロックを形成するように符号化されることができ、その場合に
、符号化されたデータはpサブタイムスロットのうちの1つに符号化される。
RLC/MACブロックを形成するように符号化されることができ、その場合に
、符号化されたデータはpサブタイムスロットのうちの1つに符号化される。
【0179】
図20の符号化技術を用いるとき、図24のバースト構造は、同じように、図
24のようなシステムにおいて用いられる場合がある。図22の構造のガードバ
ンドは、ユーザ間が良好な同期状態にある場合に、削除される場合がある。
24のようなシステムにおいて用いられる場合がある。図22の構造のガードバ
ンドは、ユーザ間が良好な同期状態にある場合に、削除される場合がある。
【0180】
したがって回線あるいはパケット交換TDMAネットワークにおいて、物理チ
ャネルの数を2倍以上に増やすことができる。
ャネルの数を2倍以上に増やすことができる。
【0181】
たとえば、図16および図17を参照して先に記載された、同じタイムスロッ
トにおいて異なるユーザからのユーザデータを伝送するためのインターリーブ技
術は、タイムスロットを分割するために、たとえば、図25を参照して先に記載
された技術と結合される場合がある。このように、サブタイムスロットは分割さ
れることができる。
トにおいて異なるユーザからのユーザデータを伝送するためのインターリーブ技
術は、タイムスロットを分割するために、たとえば、図25を参照して先に記載
された技術と結合される場合がある。このように、サブタイムスロットは分割さ
れることができる。
【0182】
種々のユーザからの4つのスピーチフレーム
ここで、全て異なるユーザに関連する4つのスピーチフレームが、EDGE上
で伝送するために1つのRLC/MACブロックに符号化される、さらに別に実
施形態が記載される。この実施形態では、標準的なGSMハーフレート符号化器
が用いられる。
で伝送するために1つのRLC/MACブロックに符号化される、さらに別に実
施形態が記載される。この実施形態では、標準的なGSMハーフレート符号化器
が用いられる。
【0183】
標準的なGSMハーフレート音声符号化器は、112ビットを有するスピーチ
フレームを生成する。これらの95ビットはクラスIビットであり、そのうちの
22ビットはクラスIaビット、73ビットはクラスIbビットである。残りの
17ビットはクラスIIビットである。
フレームを生成する。これらの95ビットはクラスIビットであり、そのうちの
22ビットはクラスIaビット、73ビットはクラスIbビットである。残りの
17ビットはクラスIIビットである。
【0184】
ハーフレートスピーチフレームのビットの並びが図10(a)に示される。図
から明らかなように、スピーチフレーム700は、73クラスIbビット702
と、それに続く22クラスIaビット704と、それに続く17クラスIIビッ
ト706とを含む。
から明らかなように、スピーチフレーム700は、73クラスIbビット702
と、それに続く22クラスIaビット704と、それに続く17クラスIIビッ
ト706とを含む。
【0185】
標準的なGSMでは、図10(a)のハーフレートに符号化されたスピーチフ
レーム700のクラスIaビットは、誤り検出のための3つのパリティビットに
よって保護される。3つのパリティビットを加えた後、図10(b)に示される
フォーマットを有する、115ビットのハーフレートに符号化されたスピーチフ
レーム708が形成される。3つのパリティビット710は、クラスIaビット
704とクラスIIビット706との間に配置される。
レーム700のクラスIaビットは、誤り検出のための3つのパリティビットに
よって保護される。3つのパリティビットを加えた後、図10(b)に示される
フォーマットを有する、115ビットのハーフレートに符号化されたスピーチフ
レーム708が形成される。3つのパリティビット710は、クラスIaビット
704とクラスIIビット706との間に配置される。
【0186】
図10(b)のハーフレートに符号化されたスピーチフレーム708を生成す
るための回路には、標準的なGSM音声符号化器を用いることができ、その実装
形態は、十分に当業者の理解の範囲内にあるであろう。そのようなスピーチフレ
ームをEDGE RLC/MACブロックにさらに符号化するための回路も、上
記の図7の回路と、以下のさらなる説明とを参照すれば、当業者には明らかにな
るであろう。簡略化するために、ここでは、そのような回路をさらに変更した実
装形態は示されない。図7の回路に対する必要な変更形態は、図10および図1
1をさらに参照しつつ、以下の説明から明らかになるであろう。
るための回路には、標準的なGSM音声符号化器を用いることができ、その実装
形態は、十分に当業者の理解の範囲内にあるであろう。そのようなスピーチフレ
ームをEDGE RLC/MACブロックにさらに符号化するための回路も、上
記の図7の回路と、以下のさらなる説明とを参照すれば、当業者には明らかにな
るであろう。簡略化するために、ここでは、そのような回路をさらに変更した実
装形態は示されない。図7の回路に対する必要な変更形態は、図10および図1
1をさらに参照しつつ、以下の説明から明らかになるであろう。
【0187】
ここまでのハーフレートスピーチフレームの符号化は、GSMにおいて用いら
れるスピーチフレームに対応している。この例では、図3(a)のダウンリンク
のための有利なヘッダ構造が再び用いられる。
れるスピーチフレームに対応している。この例では、図3(a)のダウンリンク
のための有利なヘッダ構造が再び用いられる。
【0188】
図10(b)を参照すると、1人のユーザに関連する1つの符号化されないダ
ウンリンクスピーチフレーム712が示される。信号線138上のヘッダの3ビ
ットのUSFフィールドは参照番号720によって示され、ヘッダの残りの13
ビットは参照番号722によって示される。
ウンリンクスピーチフレーム712が示される。信号線138上のヘッダの3ビ
ットのUSFフィールドは参照番号720によって示され、ヘッダの残りの13
ビットは参照番号722によって示される。
【0189】
ダウンリンクヘッダの3USFビットは、図10(d)において参照番号72
6によって示されるように、36ビットにブロック符号化される。ヘッダ内のU
SFフィールドを符号化する場合に、EDGEデータ伝送の場合に示唆され、表
1において先に示されたような36,3線形ブロック符号が用いられる。
6によって示されるように、36ビットにブロック符号化される。ヘッダ内のU
SFフィールドを符号化する場合に、EDGEデータ伝送の場合に示唆され、表
1において先に示されたような36,3線形ブロック符号が用いられる。
【0190】
第1のスピーチフレームの95クラスIビット702および704は、たたみ
込み符号化回路において、ヘッダ722の残りの13ビット(すなわち、3US
Fビットを除く全てのフィールド)と、3CRCビット710と結合される。図
10(c)において参照番号724によって示される351ビットを生成するた
めに、3,1,7たたみ込み符号が、上記のように用いられる。
込み符号化回路において、ヘッダ722の残りの13ビット(すなわち、3US
Fビットを除く全てのフィールド)と、3CRCビット710と結合される。図
10(c)において参照番号724によって示される351ビットを生成するた
めに、3,1,7たたみ込み符号が、上記のように用いられる。
【0191】
以下のような符号化率3,1,7たたみ込み符号の生成多項式を有する、図7
を参照して先に記載された3,1,7たたみ込み符号が再び用いられる。 G0(D)=1+D2+D3+D5+D6 G1(D)=1+D+D2+D3+D4+D6 G2(D)=1+D+D4+D6
を参照して先に記載された3,1,7たたみ込み符号が再び用いられる。 G0(D)=1+D2+D3+D5+D6 G1(D)=1+D+D2+D3+D4+D6 G2(D)=1+D+D4+D6
【0192】
たたみ込み符号化器の出力は351ビット[b(1),...,b(351)
]を含む。EDGE RLC/MACブロックの長さの要件を満足するために、
この段階において、パンクチャ処理が用いられなければならない。より具体的に
は、351ビット724のうちの58ビットがパンクチャ処理され、その結果、
図10(b)において参照番号728によって示される、1組の293符号化ビ
ットになる。パンクチャ処理されるビットは以下の通りである。 b(40+5・j)=0 ,i=0,1,...,56 b(324)=0 パンクチャ処理されるビットを入念に検討してみると、重要なCRCビットおよ
びヘッダビットがパンクチャ処理されないことがわかる。
]を含む。EDGE RLC/MACブロックの長さの要件を満足するために、
この段階において、パンクチャ処理が用いられなければならない。より具体的に
は、351ビット724のうちの58ビットがパンクチャ処理され、その結果、
図10(b)において参照番号728によって示される、1組の293符号化ビ
ットになる。パンクチャ処理されるビットは以下の通りである。 b(40+5・j)=0 ,i=0,1,...,56 b(324)=0 パンクチャ処理されるビットを入念に検討してみると、重要なCRCビットおよ
びヘッダビットがパンクチャ処理されないことがわかる。
【0193】
17クラスIIビットは符号化されず、図10(d)に参照番号730によっ
て示される。
て示される。
【0194】
図10(e)を参照すると、ダウンリンクのための完成したRLC/MACブ
ロック742が示されており、参照番号734によって示される8スチールビッ
トと、736、738および740によって示される符号化された第2、第3お
よび第4のスピーチフレームとを加えた、図10(d)に示されるフォーマット
に対応する。
ロック742が示されており、参照番号734によって示される8スチールビッ
トと、736、738および740によって示される符号化された第2、第3お
よび第4のスピーチフレームとを加えた、図10(d)に示されるフォーマット
に対応する。
【0195】
同じユーザからの第2、第3および第4のハーフレートに符号化されたスピー
チフレームはそれぞれ、図10(a)〜図10(d)を参照して、第1のスピー
チフレームに関連して記載されるフレームと同じようにして符号化される。フレ
ーム当たり58ビットをパンクチャ処理する技術を用いると、EDGE RLC
/MACブロックと同じ長さのビット(8スチールビットを含む)長になるため
、この実施形態では、全てのスピーチフレームがそのヘッダとともに符号化され
る。
チフレームはそれぞれ、図10(a)〜図10(d)を参照して、第1のスピー
チフレームに関連して記載されるフレームと同じようにして符号化される。フレ
ーム当たり58ビットをパンクチャ処理する技術を用いると、EDGE RLC
/MACブロックと同じ長さのビット(8スチールビットを含む)長になるため
、この実施形態では、全てのスピーチフレームがそのヘッダとともに符号化され
る。
【0196】
受信機端では、復号化する前に、パンクチャ処理されたビットが0で置き換え
られる。パンクチャ処理されたブロックは293ビットからなり、それは、伝送
されるRLC/MACブロックの第1のブロックを形成するために、符号化され
た36USFビットと、符号化されない17クラスIIビットと結合される。同
じ手順が、残りの3つのスピーチフレームの場合に続けられる。最後に、8スチ
ールビットが挿入される。RLC/MACブロックが形成された後、それは変調
器およびインターリーブ装置に転送される。EDGEデータ伝送の場合のように
、ダウンリンクでは、4バーストにわたるインターリーブが用いられることが好
ましい。
られる。パンクチャ処理されたブロックは293ビットからなり、それは、伝送
されるRLC/MACブロックの第1のブロックを形成するために、符号化され
た36USFビットと、符号化されない17クラスIIビットと結合される。同
じ手順が、残りの3つのスピーチフレームの場合に続けられる。最後に、8スチ
ールビットが挿入される。RLC/MACブロックが形成された後、それは変調
器およびインターリーブ装置に転送される。EDGEデータ伝送の場合のように
、ダウンリンクでは、4バーストにわたるインターリーブが用いられることが好
ましい。
【0197】
全てのヘッダが符号化されるので、全て同じユーザに関連するとは限らない4
つのスピーチフレームを符号化するために、この同じ技術が用いられる場合があ
る。
つのスピーチフレームを符号化するために、この同じ技術が用いられる場合があ
る。
【0198】
上記の説明は、ダウンリンクにおける同じRLC/MACブロック内の4つの
スピーチフレームの伝送に関連付けており、図8は、ダウンリンク伝送のための
1つのRLC/MACブロック内の4つのスピーチフレームの伝送のためのチャ
ネル符号化の概要を表しているが、同様の技術はアップリンクにも当てはまる。
図11は、アップリンク伝送のための1つのRLC/MACブロック内の4つの
スピーチフレームの伝送のために適用されるチャネル符号化原理を示す。
スピーチフレームの伝送に関連付けており、図8は、ダウンリンク伝送のための
1つのRLC/MACブロック内の4つのスピーチフレームの伝送のためのチャ
ネル符号化の概要を表しているが、同様の技術はアップリンクにも当てはまる。
図11は、アップリンク伝送のための1つのRLC/MACブロック内の4つの
スピーチフレームの伝送のために適用されるチャネル符号化原理を示す。
【0199】
図11(b)を参照すると、再び、1人のユーザに関連する1つの符号化され
ないダウンリンクスピーチフレーム713が示される。16ビットヘッダは、参
照番号723によって示される。
ないダウンリンクスピーチフレーム713が示される。16ビットヘッダは、参
照番号723によって示される。
【0200】
第1のスピーチフレームの95クラスIビット702および704は、たたみ
込み符号化回路において、16ビットのヘッダ723と、3CRCビット710
と結合される。再び、図11(c)において参照番号750によって示される3
60ビット(6テールビットを含む)を生成するために、3,1,7たたみ込み
符号が用いられる。
込み符号化回路において、16ビットのヘッダ723と、3CRCビット710
と結合される。再び、図11(c)において参照番号750によって示される3
60ビット(6テールビットを含む)を生成するために、3,1,7たたみ込み
符号が用いられる。
【0201】
たたみ込み符号化器の出力は、360ビット[b(1),...,b(360
)]を含む。EDGE RLC/MACブロックの長さの要件を満足するために
、この段階において、再びパンクチャ処理が用いられなければならない。360
ビット750のうちの31ビットがパンクチャ処理され、その結果、図10(d
)に参照番号756によって示される1組の329符号化ビットになる。パンク
チャ処理されるビットは以下の通りである。 b(53+9・i)=0 ,i=0,1,...,29 b(324)=0
)]を含む。EDGE RLC/MACブロックの長さの要件を満足するために
、この段階において、再びパンクチャ処理が用いられなければならない。360
ビット750のうちの31ビットがパンクチャ処理され、その結果、図10(d
)に参照番号756によって示される1組の329符号化ビットになる。パンク
チャ処理されるビットは以下の通りである。 b(53+9・i)=0 ,i=0,1,...,29 b(324)=0
【0202】
17クラスIIビット706は符号化されない。その後、符号化されたフレー
ム752は2つのスチールビット766を割り当てられ、3つの他のフレームを
有するRLC/MACブロックに多重化される。3つの他の符号化されたフレー
ム760、762および764はそれぞれ、2つのスチールビット768、77
0および772に関連付けられる。
ム752は2つのスチールビット766を割り当てられ、3つの他のフレームを
有するRLC/MACブロックに多重化される。3つの他の符号化されたフレー
ム760、762および764はそれぞれ、2つのスチールビット768、77
0および772に関連付けられる。
【0203】
後に記載されるように、4つの符号化されたスピーチフレームが異なるユーザ
からのものである場合には、好ましい実施形態では、そのフレームは共通のTD
MAタイムスロットを共有する。
からのものである場合には、好ましい実施形態では、そのフレームは共通のTD
MAタイムスロットを共有する。
【0204】
符号化された各フレームは1バースト内で伝送されることが好ましい。アップ
リンクにおいて、4つの異なるブロックが4人の異なるユーザからものである場
合があるため、RCL/MACブロックを4バーストにわたってインターリーブ
することはできない。別法では、各バースト内の各ブロックのために、ブロック
インターリーブが用いられる。具体的には、346ビットが、18×20の矩形
行列の列毎に挿入される。この行列は360要素を有し、それゆえ、最後の14
要素は空である。そのビットは行毎に読み出される。このインターリーブ方式は
、連続したビット間の18の最小距離を達成する。受信機端では、逆の手順(デ
インターリーブ)が行われる。
リンクにおいて、4つの異なるブロックが4人の異なるユーザからものである場
合があるため、RCL/MACブロックを4バーストにわたってインターリーブ
することはできない。別法では、各バースト内の各ブロックのために、ブロック
インターリーブが用いられる。具体的には、346ビットが、18×20の矩形
行列の列毎に挿入される。この行列は360要素を有し、それゆえ、最後の14
要素は空である。そのビットは行毎に読み出される。このインターリーブ方式は
、連続したビット間の18の最小距離を達成する。受信機端では、逆の手順(デ
インターリーブ)が行われる。
【図1a】
EDGEネットワーク上で音声を伝送するためのヘッダ構造の第1の例を示す
図である。
図である。
【図1b】
EDGEネットワーク上で音声を伝送するためのヘッダ構造の第1の例を示す
図である。
図である。
【図2a】
EDGEネットワーク上で音声を伝送するためのヘッダ構造の第2の例を示す
図である。
図である。
【図2b】
EDGEネットワーク上で音声を伝送するためのヘッダ構造の第2の例を示す
図である。
図である。
【図3a】
EDGEネットワーク上で音声を伝送するためのヘッダ構造の第3の例を示す
図である。
図である。
【図3b】
EDGEネットワーク上で音声を伝送するためのヘッダ構造の第3の例を示す
図である。
図である。
【図4a】
図3のヘッダを用いるシステム性能の改善を示す図である。
【図4b】
図3のヘッダを用いるシステム性能の改善を示す図である。
【図5】
図3(a)のヘッダを生成するための符号化器を示す図である。
【図6】
図3(a)のヘッダを復号化するための復号化器を示す図である。
【図7】
EDGEシステムのダウンリンクにおいてRLC/MACブロックを生成する
ための回路を示す図である。
ための回路を示す図である。
【図8】
a〜cは、図7の回路を用いて、EDGEネットワークのダウンリンクにおい
て同じユーザからの2つのスピーチフレームからRLC/MACブロックを生成
する一実施形態を示す図である。
て同じユーザからの2つのスピーチフレームからRLC/MACブロックを生成
する一実施形態を示す図である。
【図9】
a〜cは、EDGEシステムのアップリンクにおいてRLC/MACブロック
を生成するための、図8の実施形態に対応する実施形態を示す図である。
を生成するための、図8の実施形態に対応する実施形態を示す図である。
【図10】
a〜eは、EDGEネットワークのダウンリンクにおいて異なるユーザからの
4つのスピーチフレームからRLC/MACブロックを生成する一実施形態を示
す図である。
4つのスピーチフレームからRLC/MACブロックを生成する一実施形態を示
す図である。
【図11】
a〜eは、EDGEシステムのアップリンクにおいてRLC/MACブロック
を生成するための、図10の実施形態に対応する実施形態を示す図である。
を生成するための、図10の実施形態に対応する実施形態を示す図である。
【図12】
EDGEシステムのダウンリンクにおいてRLC/MACブロックを生成する
ための回路を示す図である。
ための回路を示す図である。
【図13】
a〜cは、図12の回路を用いて、EDGEネットワークのダウンリンクにお
いて異なるユーザからの2つのスピーチフレームからRLC/MACブロックを
生成する一実施形態を示す図である。
いて異なるユーザからの2つのスピーチフレームからRLC/MACブロックを
生成する一実施形態を示す図である。
【図14】
a〜cは、EDGEシステムのアップリンクにおいてRLC/MACブロック
を生成するための、図13の実施形態に対応する実施形態を示す図である。
を生成するための、図13の実施形態に対応する実施形態を示す図である。
【図15】
a〜bは、従来のインターリーブ技術を示す図である。
【図15c】
従来のインターリーブ技術を示す図である。
【図15d】
従来のインターリーブ技術を示す図である。
【図16】
無線ネットワークのダウンリンクのための好ましいインターリーブ技術を示す
図である。
図である。
【図17】
無線ネットワークのアップリンクのための好ましいインターリーブ技術を示す
図である。
図である。
【図18】
EDGEシステムのダウンリンクにおいてRLC/MACブロックを生成する
ための回路を示す図である。
ための回路を示す図である。
【図19】
a〜cは、図18の回路を用いて、EDGEネットワークのダウンリンクにお
いて同じユーザからの2つのスピーチフレームからRLC/MACブロックを生
成する一実施形態を示す図である。
いて同じユーザからの2つのスピーチフレームからRLC/MACブロックを生
成する一実施形態を示す図である。
【図20】
a〜cは、EDGEシステムのアップリンクにおいてRLC/MACブロック
を生成するための、図19の実施形態に対応する実施形態を示す図である。
を生成するための、図19の実施形態に対応する実施形態を示す図である。
【図21】
従来のGSM/GPRSバースト構造を示す図である。
【図22】
好ましいバースト構造の一実施形態を示す図である。
【図23】
a〜cは、EDGEシステムのアップリンクにおいてRLC/MACブロック
を生成するための、図19の実施形態に対応する実施形態を示す図である。
を生成するための、図19の実施形態に対応する実施形態を示す図である。
【図24】
好ましいバースト構造の別の実施形態を示す図である。
【図25】
図22および図24の好ましいバースト構造の一例の実装形態を示す図である
。
。
─────────────────────────────────────────────────────
フロントページの続き
(72)発明者 サマラス,コンスタンティノス
イギリス国 エスエヌ2 2エッチエル
スウィンドン,モンタギュ ストリート
53
(72)発明者 ウー,ジアン,ジュン
イギリス国 エスエヌ5 6エーダブリュ
スウィンドン,マーニー ロード 32
(72)発明者 ヤン,ラン−ホン
イギリス国 エスエヌ7 7エスエス フ
ァリングドン,キングス レーン,ホーソ
ーンズ
Fターム(参考) 5J065 AA01 AB04 AB05 AC02 AD04
AD06 AD10 AE06 AF02
5K014 AA01 BA06 BA10 EA01 HA06
HA10
5K028 BB06 CC02 CC05 HH00 KK01
KK12 MM05 SS04 SS14
5K030 HB01 HB11 JA05 JL08
5K067 AA13 AA23 BB02 BB21 CC08
DD51 EE02 EE10 EE16 FF02
HH22 HH24
Claims (12)
- 【請求項1】 パケット交換網において、少なくとも2つのパケットを1つ
のブロックに符号化する方法であって、前記各パケットはヘッダ部に関連付けら
れ、前記少なくとも2つのパケットは同じユーザに関連付けられ、前記少なくと
も2つのパケットと、前記関連付けられたヘッダ部の1つのみとを符号化するス
テップを含む方法。 - 【請求項2】 前記少なくとも2つパケットはスピーチフレームを含むペイ
ロード部と、スピーチヘッダ部とを有する請求項1に記載の方法。 - 【請求項3】 前記各スピーチフレームは、1組のクラスIビットと、1組
のクラスIIビットとを含み、前記方法は前記1組のクラスIビットを符号化す
ることによって第1のスピーチフレームを符号化するステップと、前記1組のク
ラスIビットを符号化することにより第2のスピーチフレームを符号化するステ
ップと、前記ヘッダの少なくとも一部を符号化するステップとをさらに含む請求
項2に記載の方法。 - 【請求項4】 前記スピーチフレームは、無線パケット交換網のダウンリン
ク上で伝送するためのものであり、前記各符号化するステップは、2つの異なる
符号化技術を用いて、前記ヘッダの2つの異なる部分を符号化するステップを含
む請求項1もしくは2に記載の方法。 - 【請求項5】 前記クラスIビットおよび前記ヘッダの一部は、たたみ込み
符号を用いて符号化される請求項4に記載の方法。 - 【請求項6】 前記たたみ込み符号は3,1,7たたみ込み符号である請求
項5に記載の方法。 - 【請求項7】 前記ヘッダの残りの部分はブロック符号を用いて符号化され
る請求項4もしくは5に記載の方法。 - 【請求項8】 前記ブロック符号は、36,3ブロック符号である請求項6
に記載の方法。 - 【請求項9】 前記スピーチフレームは、無線パケット交換網のアップリン
ク上で伝送するためのものであり、前記クラスIビットおよび共通ヘッダは、た
たみ込み符号を用いて符号化される請求項1に記載の方法。 - 【請求項10】 前記1つのブロックは1組のスチールビットをさらに含む
請求項1ないし9のいずれか一項に記載の方法。 - 【請求項11】 前記1つのブロックは1組のスペアビットを含む請求項1
ないし10のいずれか一項に記載の方法。 - 【請求項12】 前記ブロックは、EDGE RLC/MACブロックであ
る請求項1ないし11のいずれか一項に記載の方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP99304484.1 | 1999-06-09 | ||
EP99304484A EP1059754A1 (en) | 1999-06-09 | 1999-06-09 | Common header encoding for packet switched networks |
PCT/GB2000/001182 WO2000076110A1 (en) | 1999-06-09 | 2000-03-28 | Single header encoding for multiple packets in a packet switched network |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2003505961A true JP2003505961A (ja) | 2003-02-12 |
Family
ID=8241437
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001512353A Pending JP2003505961A (ja) | 1999-06-09 | 2000-03-28 | パケット交換網において同じユーザからの多数のパケットのための単一ヘッダ符号化 |
Country Status (5)
Country | Link |
---|---|
US (1) | US6987813B1 (ja) |
EP (2) | EP1059754A1 (ja) |
JP (1) | JP2003505961A (ja) |
AU (1) | AU1638301A (ja) |
WO (1) | WO2000076110A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006324773A (ja) * | 2005-05-17 | 2006-11-30 | Alps Electric Co Ltd | 受信装置 |
JP2012044356A (ja) * | 2010-08-17 | 2012-03-01 | Nippon Telegr & Teleph Corp <Ntt> | 光パケット経路決定方法および光パケット交換装置 |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1059755A1 (en) * | 1999-06-09 | 2000-12-13 | Lucent Technologies Inc. | Unequal error protection for packet switched networks |
US8458754B2 (en) | 2001-01-22 | 2013-06-04 | Sony Computer Entertainment Inc. | Method and system for providing instant start multimedia content |
US7035289B2 (en) * | 2002-05-03 | 2006-04-25 | Cedar Point Communications | Communications switching architecture |
KR100926707B1 (ko) * | 2002-11-05 | 2009-11-17 | 엘지전자 주식회사 | 이동통신 시스템의 데이터 통신방법 |
US7342956B2 (en) * | 2003-06-16 | 2008-03-11 | Broadcom Corporation | System and method to extract uplink status flag bits in a cellular wireless network |
US8239446B2 (en) * | 2003-11-19 | 2012-08-07 | Sony Computer Entertainment America Llc | Content distribution architecture |
US8359398B1 (en) * | 2004-01-20 | 2013-01-22 | Oracle America, Inc. | Efficient proxying of messages |
US7508884B2 (en) * | 2005-03-24 | 2009-03-24 | Harris Corporation | System and method for communicating data using constant amplitude equalized waveform |
US9483405B2 (en) * | 2007-09-20 | 2016-11-01 | Sony Interactive Entertainment Inc. | Simplified run-time program translation for emulating complex processor pipelines |
US20100293072A1 (en) * | 2009-05-13 | 2010-11-18 | David Murrant | Preserving the Integrity of Segments of Audio Streams |
US8433759B2 (en) | 2010-05-24 | 2013-04-30 | Sony Computer Entertainment America Llc | Direction-conscious information sharing |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4703477A (en) | 1986-02-28 | 1987-10-27 | American Telephone And Telegraph Company At&T Bell Laboratories | Packet information field data format |
US4894823A (en) | 1986-02-28 | 1990-01-16 | American Telephone And Telegraph Company | Time stamping for packet system nodes |
DE4229654A1 (de) * | 1991-09-25 | 1993-04-22 | Thomson Brandt Gmbh | Verfahren zur uebertragung eines audio- und/oder videosignals |
CA2143374A1 (en) | 1994-09-21 | 1996-03-22 | Isaac Shpantzer | Data communication system with adaptive concatenation |
JPH08274803A (ja) | 1995-03-29 | 1996-10-18 | Hitachi Ltd | Lan間接続方式 |
FI103456B (fi) * | 1996-03-29 | 1999-06-30 | Nokia Telecommunications Oy | Puheen siirto pakettiverkossa |
US5905727A (en) | 1996-10-08 | 1999-05-18 | International Business Machines Corporation | Method and system for transmitting ATM cells on an ATM link |
US6212230B1 (en) * | 1998-04-04 | 2001-04-03 | Sigmatel, Inc. | Method and apparatus for pulse position modulation |
US6862278B1 (en) * | 1998-06-18 | 2005-03-01 | Microsoft Corporation | System and method using a packetized encoded bitstream for parallel compression and decompression |
US6590876B1 (en) * | 1998-10-13 | 2003-07-08 | Lucent Technologies Inc. | Direct path matrix communication system and method |
US6609223B1 (en) * | 1999-04-06 | 2003-08-19 | Kencast, Inc. | Method for packet-level fec encoding, in which on a source packet-by-source packet basis, the error correction contributions of a source packet to a plurality of wildcard packets are computed, and the source packet is transmitted thereafter |
-
1999
- 1999-06-09 EP EP99304484A patent/EP1059754A1/en not_active Withdrawn
-
2000
- 2000-03-28 US US09/979,390 patent/US6987813B1/en not_active Expired - Lifetime
- 2000-03-28 AU AU16383/01A patent/AU1638301A/en not_active Abandoned
- 2000-03-28 JP JP2001512353A patent/JP2003505961A/ja active Pending
- 2000-03-28 EP EP00975654A patent/EP1183812A1/en not_active Withdrawn
- 2000-03-28 WO PCT/GB2000/001182 patent/WO2000076110A1/en not_active Application Discontinuation
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006324773A (ja) * | 2005-05-17 | 2006-11-30 | Alps Electric Co Ltd | 受信装置 |
JP2012044356A (ja) * | 2010-08-17 | 2012-03-01 | Nippon Telegr & Teleph Corp <Ntt> | 光パケット経路決定方法および光パケット交換装置 |
Also Published As
Publication number | Publication date |
---|---|
US6987813B1 (en) | 2006-01-17 |
AU1638301A (en) | 2000-12-28 |
EP1059754A1 (en) | 2000-12-13 |
WO2000076110A1 (en) | 2000-12-14 |
EP1183812A1 (en) | 2002-03-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5182753A (en) | Method of transmitting signaling messages in a mobile radio communication system | |
KR20010047396A (ko) | 전송 포맷 조합 식별자에 대한 전송 성능 향상 방법 | |
US7240270B2 (en) | Method of transmitting signaling messages in a mobile telecommunications network | |
US7814388B2 (en) | System and method for interleaving data in a wireless transmitter | |
EP1183811B1 (en) | Unequal error protection for packet switched networks | |
US6819718B1 (en) | Apparatus and method for transmitting punctured or repeated data | |
JP2003505961A (ja) | パケット交換網において同じユーザからの多数のパケットのための単一ヘッダ符号化 | |
EP1183796B1 (en) | Time-slot partitioning in a tdma system | |
EP1188259B1 (en) | Multi-user time slots for tdma | |
US7146312B1 (en) | Transmission of voice in packet switched networks | |
RU2298878C2 (ru) | Передача данных в транспортном формате | |
JP3566651B2 (ja) | 信号の符号化 | |
US6987470B2 (en) | Method to efficiently generate the row and column index for half rate interleaver in GSM | |
EP1059775A1 (en) | Error correction based on headers | |
EP1059776A1 (en) | Transmission of voice in an edge network | |
JPH04114517A (ja) | データ伝送方法 | |
KR20070021236A (ko) | 데이터 스트림 복구방법 및 프로세서 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041101 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041110 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050126 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050511 |