JP2002521866A - 通信装置と信頼性が高く遅延が短いパケット通信方法 - Google Patents
通信装置と信頼性が高く遅延が短いパケット通信方法Info
- Publication number
- JP2002521866A JP2002521866A JP2000560694A JP2000560694A JP2002521866A JP 2002521866 A JP2002521866 A JP 2002521866A JP 2000560694 A JP2000560694 A JP 2000560694A JP 2000560694 A JP2000560694 A JP 2000560694A JP 2002521866 A JP2002521866 A JP 2002521866A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- data
- protocol
- mode
- communication
- 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.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims description 201
- 238000000034 method Methods 0.000 title claims description 117
- 230000005540 biological transmission Effects 0.000 claims abstract description 26
- 239000000872 buffer Substances 0.000 claims description 47
- 230000008569 process Effects 0.000 claims description 41
- 238000012937 correction Methods 0.000 claims description 18
- 230000006978 adaptation Effects 0.000 claims description 15
- 238000011084 recovery Methods 0.000 claims description 6
- 230000002265 prevention Effects 0.000 claims description 5
- 230000007480 spreading Effects 0.000 claims description 5
- 238000001514 detection method Methods 0.000 claims description 4
- 238000002789 length control Methods 0.000 claims description 4
- 238000004321 preservation Methods 0.000 claims description 4
- 238000012790 confirmation Methods 0.000 claims description 3
- 230000003044 adaptive effect Effects 0.000 claims 4
- 230000007246 mechanism Effects 0.000 description 11
- 230000006399 behavior Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 230000008859 change Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 238000005538 encapsulation Methods 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 235000009508 confectionery Nutrition 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 238000001228 spectrum Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 102100036738 Guanine nucleotide-binding protein subunit alpha-11 Human genes 0.000 description 1
- 101100283445 Homo sapiens GNA11 gene Proteins 0.000 description 1
- 108010003272 Hyaluronate lyase Proteins 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
- H04L69/085—Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Transmitters (AREA)
Abstract
(57)【要約】
本発明においては、パケットの埋め込みに関するプロトコルを、埋め込まれるデータの種類を反映させたものにして、埋め込まれたパケットに応じてパラメータを自動的に設定する。封じ込めるか分割するかしたあとでさらに(リンクに対して直接又は下位のレイヤに)送り出すべく高次のレイヤから受け取られたパケットの中のデータを、調整可能なパラメータに関していくつかのカテゴリに分類され、パケットのパラメータはその分類されたカテゴリに従ってパケット毎に自動的に調節される。
Description
【０００１】 発明の属する技術分野 本発明は、例えばインターネットと称するパケット交換ネットワークとコンピ
ュータの間に確立した接続を介してデータパケットを送るための通信装置と方法
に関するものである。
ュータの間に確立した接続を介してデータパケットを送るための通信装置と方法
に関するものである。
【０００２】 発明の背景 近年のデータ処理及び通信技術の進歩に伴い、現代社会の多くの側面、例えば
科学及び軍事の世界あるいは急速に発展しつつあるビジネスと個人利用、におい
てデータ交換ネートワークの確立が必須となっている。この最も良い例が、イン
ターネットと称する世界規模の通信網において躍進しているサービスの提供とサ
ービス需要である。基本的には、「インターネット」という用語は、非常に良く知
られた言葉であるが、この言葉は単に他のネットワークから構成されたネットワ
ークを意味するに過ぎず、いわゆるワールドワイド「インターネット」はその一
例に過ぎない。
科学及び軍事の世界あるいは急速に発展しつつあるビジネスと個人利用、におい
てデータ交換ネートワークの確立が必須となっている。この最も良い例が、イン
ターネットと称する世界規模の通信網において躍進しているサービスの提供とサ
ービス需要である。基本的には、「インターネット」という用語は、非常に良く知
られた言葉であるが、この言葉は単に他のネットワークから構成されたネットワ
ークを意味するに過ぎず、いわゆるワールドワイド「インターネット」はその一
例に過ぎない。
【０００３】 ネットワークにおいて広く使用されているデータ交換の基本はパケット交換に
よるものである。つまり、送信すべきデータをユニットに分割する。ユニットの
送受信規則とユニットの構成に関する規則はいわゆるプロトコルによって定めら
れている。プロトコルとは送信側と受信側の通信を可能にする規則の集合であり
、規則とは、送信側と受信側を拘束するプロトコルの下で受信側がデータを解釈
して対応することができるようにするためには、送信データをどのように構成し
て送るべきかを定めるものである。
よるものである。つまり、送信すべきデータをユニットに分割する。ユニットの
送受信規則とユニットの構成に関する規則はいわゆるプロトコルによって定めら
れている。プロトコルとは送信側と受信側の通信を可能にする規則の集合であり
、規則とは、送信側と受信側を拘束するプロトコルの下で受信側がデータを解釈
して対応することができるようにするためには、送信データをどのように構成し
て送るべきかを定めるものである。
【０００４】 異なるネットワーク間すなわち多くのソフトウエアとハードウエアの間でのデ
ータ交換を可能にする重要な概念は、プロトコルの階層化である。これは、多く
のプロトコル（スウィートと呼ばれることも有る)が、階層化されたレイヤ構造
をしており、各レイヤが固有の機能と責任を有するというものである。図３ない
し５を参照してこの点を簡単に説明する。この概念に関するより詳細な解説は、
Ｗ．リチャード スティーブンス著「図解ＴＣＰ／ＩＰ，第１巻，プロトコル」
、１９９４年、アディソン ウェズリー社刊に記載されている。
ータ交換を可能にする重要な概念は、プロトコルの階層化である。これは、多く
のプロトコル（スウィートと呼ばれることも有る)が、階層化されたレイヤ構造
をしており、各レイヤが固有の機能と責任を有するというものである。図３ない
し５を参照してこの点を簡単に説明する。この概念に関するより詳細な解説は、
Ｗ．リチャード スティーブンス著「図解ＴＣＰ／ＩＰ，第１巻，プロトコル」
、１９９４年、アディソン ウェズリー社刊に記載されている。
【０００５】 通信制御プロトコル(ＴＣＰ)とインターネットプロトコル(ＩＰ)はインターネ
ット上で通信を行うことができるプロトコルの一例である。しかし、通常ＴＣＰ
／ＩＰと呼ばれているものは他のプロトコルも含むものである。いわゆるＴＣＰ
／ＩＰスウィートは、図３に示したように４つの階層を有する。リンクレイヤは
、ケーブルや無線通信のような物理通信媒体に対するデータの入出力を取り扱う
。代表的な場合は、リンクレイヤはＯＳと対応するネットワークインターフェー
スの中のデバイスドライバに組み込まれている。ネットワークレイヤはネットワ
ークの中でのパケットの移動つまりルーティングを行う。ＩＰはネットワークレ
イヤプロトコルの一例である。搬送レイヤは上位のアプリケーションレイヤに対
してデータの流れを供給する。ＴＣＰは搬送レイヤの一例である。ＴＣＰに代わ
るものとして利用者データグラムプロトコル(ＵＤＰ)がある。アプリケーション
レイヤとしてはデータを送受信するプログラムつまりe-mailプログラムがある。
ット上で通信を行うことができるプロトコルの一例である。しかし、通常ＴＣＰ
／ＩＰと呼ばれているものは他のプロトコルも含むものである。いわゆるＴＣＰ
／ＩＰスウィートは、図３に示したように４つの階層を有する。リンクレイヤは
、ケーブルや無線通信のような物理通信媒体に対するデータの入出力を取り扱う
。代表的な場合は、リンクレイヤはＯＳと対応するネットワークインターフェー
スの中のデバイスドライバに組み込まれている。ネットワークレイヤはネットワ
ークの中でのパケットの移動つまりルーティングを行う。ＩＰはネットワークレ
イヤプロトコルの一例である。搬送レイヤは上位のアプリケーションレイヤに対
してデータの流れを供給する。ＴＣＰは搬送レイヤの一例である。ＴＣＰに代わ
るものとして利用者データグラムプロトコル(ＵＤＰ)がある。アプリケーション
レイヤとしてはデータを送受信するプログラムつまりe-mailプログラムがある。
【０００６】 ２点間における相互通信の概要を図４に示す。データはまず階層を通じて下に
降ろされ送信側の物理接続に入力され、次に受信側の階層を情報に移動する。こ
の移動が実線の矢印で示されている。所定のレイヤにおいて当該レイヤに与えら
れたプロトコルに従ってデータ処理を行うエレメントは（図４に示した搬送レイ
ヤにおけるＴＣＰ)は、ピアとも呼ばれる。換言すれば、図４に例示した搬送レ
イヤはＰＣＴピアによって処理される。図４の下部に示した物理接続は、接続の
種類によっては当該レイヤの１つ以上のプロトコルでもありえることに注意する
必要がある。この点は以下においてさらに詳細に説明する。
降ろされ送信側の物理接続に入力され、次に受信側の階層を情報に移動する。こ
の移動が実線の矢印で示されている。所定のレイヤにおいて当該レイヤに与えら
れたプロトコルに従ってデータ処理を行うエレメントは（図４に示した搬送レイ
ヤにおけるＴＣＰ)は、ピアとも呼ばれる。換言すれば、図４に例示した搬送レ
イヤはＰＣＴピアによって処理される。図４の下部に示した物理接続は、接続の
種類によっては当該レイヤの１つ以上のプロトコルでもありえることに注意する
必要がある。この点は以下においてさらに詳細に説明する。
【０００７】 図５は、レイヤ間のデータ搬送を示したものである。パケットの典型的な基本
構造は２つの部分、つまりヘッダとペイロード部分からなる。ヘッダはペイロー
ド部分に含まれるデータのタイプと対応するレイヤの通信制御に関する情報を有
する。図５に示されているように、アプリケーションレイヤにおいて、利用者の
データにヘッダが追加される。その結果として得られるデータユニット又はパケ
ットが搬送レイヤに送られ、そこでＴＣＰヘッダが追加される。このＴＣＰヘッ
ダは受信側のＴＣＰピアのための情報を含む。その結果得られるパケットは場合
によってはＴＣＰセグメントとも呼ばれる。このＴＣＰセグメントはネットワー
クレイヤに送られ、ここで図５に示した例に従えば、ルーティング情報を含むＩ
Ｐヘッダが追加される。その結果のパケットはＩＰデータグラムと呼ばれること
も有る。最終的に、ＩＰデータグラムはリンクレイヤに送られ、リンクレイヤプ
ロトコル(ＬＬＰ)に関するヘッダ、つまりポイントからポイントへのプロトコル
（ＰＰＰ)が追加される。その結果として得られるパケットは一般にフレームと
称する。フレームには、受信側でフレームの開始と終了を認識できるように、開
始フラグと終了フラグが追加される。このような上位レイヤのパケットを下位レ
イヤのパケットに埋め込む手続をカプセル化(encapsulation)と称する。
構造は２つの部分、つまりヘッダとペイロード部分からなる。ヘッダはペイロー
ド部分に含まれるデータのタイプと対応するレイヤの通信制御に関する情報を有
する。図５に示されているように、アプリケーションレイヤにおいて、利用者の
データにヘッダが追加される。その結果として得られるデータユニット又はパケ
ットが搬送レイヤに送られ、そこでＴＣＰヘッダが追加される。このＴＣＰヘッ
ダは受信側のＴＣＰピアのための情報を含む。その結果得られるパケットは場合
によってはＴＣＰセグメントとも呼ばれる。このＴＣＰセグメントはネットワー
クレイヤに送られ、ここで図５に示した例に従えば、ルーティング情報を含むＩ
Ｐヘッダが追加される。その結果のパケットはＩＰデータグラムと呼ばれること
も有る。最終的に、ＩＰデータグラムはリンクレイヤに送られ、リンクレイヤプ
ロトコル(ＬＬＰ)に関するヘッダ、つまりポイントからポイントへのプロトコル
（ＰＰＰ)が追加される。その結果として得られるパケットは一般にフレームと
称する。フレームには、受信側でフレームの開始と終了を認識できるように、開
始フラグと終了フラグが追加される。このような上位レイヤのパケットを下位レ
イヤのパケットに埋め込む手続をカプセル化(encapsulation)と称する。
【０００８】 受信側では、利用者のデータは、図５に示したのとは逆の順序で逆カプセル化
(de-encapsulation)を行うことによって取り出される。上述の説明は一例であっ
て多くの変形が可能であることは注意する必要がある。例えば、プロトコルによ
ってはヘッダだけでなくテーラを追加するものもある。
(de-encapsulation)を行うことによって取り出される。上述の説明は一例であっ
て多くの変形が可能であることは注意する必要がある。例えば、プロトコルによ
ってはヘッダだけでなくテーラを追加するものもある。
【０００９】 パケットはアプリケーションレイヤから出発しなければならないわけではなく
、ずっと下位のレイヤが、当該レイヤにのみ関する情報を受信側の対応するピア
に送り届けるために、パケットを作成しても良いことは注意が必要である。この
例として、リンク制御プロトコル(ＬＣＰ)パケットを、上位の階層のデータを送
る前に送り、前記ＬＣＰパケットがリンクレイヤピアによって調整可能および／
またはネゴをすることができる(物理的に確立された）リンクを形成するために
使用することが挙げられる。
、ずっと下位のレイヤが、当該レイヤにのみ関する情報を受信側の対応するピア
に送り届けるために、パケットを作成しても良いことは注意が必要である。この
例として、リンク制御プロトコル(ＬＣＰ)パケットを、上位の階層のデータを送
る前に送り、前記ＬＣＰパケットがリンクレイヤピアによって調整可能および／
またはネゴをすることができる(物理的に確立された）リンクを形成するために
使用することが挙げられる。
【００１０】 図４は、４つのピアが送受信のそれぞれの側にある概念を示すものである。現
実の状態はもっと複雑である。図６は、ＩＰ‐ホスト１とＩＰ‐ホスト２の間の
通信の概念を示すものである。図の最上部は物理通信パスを示し、図の下の部分
は種々のプロトコルに対応する論理通信パスを表す。図６に示した例はＧＳＭネ
ットワークを介したインターネット接続に関するものである。
実の状態はもっと複雑である。図６は、ＩＰ‐ホスト１とＩＰ‐ホスト２の間の
通信の概念を示すものである。図の最上部は物理通信パスを示し、図の下の部分
は種々のプロトコルに対応する論理通信パスを表す。図６に示した例はＧＳＭネ
ットワークを介したインターネット接続に関するものである。
【００１１】 ＩＰ‐ホスト１はラップトップコンピュータであっても良い。端末適用機能Ｔ
ＡＦは、移動局ＭＳつまり移動電話に接続されたＰＣＭＣＩＡインターフェース
カードによって果たされる。移動局ＭＳは、基地局制御装置ＢＳＣに接続された
無線基地局ＢＴＳと通信を行う。公衆切替電話網ＰＳＴＮへの接続は、無線基地
局ＢＴＳと対応する移動スイッチングセンタＭＳＣのインターワーキング機能Ｉ
ＷＦ内のモデムによって公衆切替電話網ＰＳＴＮと接続される。ＧＳＭがデジタ
ル回線なので、ＴＡＦはモデムではないことに注意する必要がある。最終的に、
ＰＳＴＮはインターネットサービスプロバイダＩＳＰへの接続を提供し、ＩＳＰ
がインターネットへのゲートウエイとなる。インターネットと、ＩＰ‐ホスト１
からのe-mailが送られるパーソナルコンピュータであるＩＰ‐ホスト２との物理
接続は図示されていない。
ＡＦは、移動局ＭＳつまり移動電話に接続されたＰＣＭＣＩＡインターフェース
カードによって果たされる。移動局ＭＳは、基地局制御装置ＢＳＣに接続された
無線基地局ＢＴＳと通信を行う。公衆切替電話網ＰＳＴＮへの接続は、無線基地
局ＢＴＳと対応する移動スイッチングセンタＭＳＣのインターワーキング機能Ｉ
ＷＦ内のモデムによって公衆切替電話網ＰＳＴＮと接続される。ＧＳＭがデジタ
ル回線なので、ＴＡＦはモデムではないことに注意する必要がある。最終的に、
ＰＳＴＮはインターネットサービスプロバイダＩＳＰへの接続を提供し、ＩＳＰ
がインターネットへのゲートウエイとなる。インターネットと、ＩＰ‐ホスト１
からのe-mailが送られるパーソナルコンピュータであるＩＰ‐ホスト２との物理
接続は図示されていない。
【００１２】 図６の下部に示されているように、ＴＣＰピア、ＩＰピアとＰＰＰピアがＩＰ
‐ホスト１に埋め込まれている。対応するＴＣＰピアとＩＰピアはＩＰ‐ホスト
２に設けられ、ＩＰピアとＰＰＰピアはインターネットサービスプロバイダＩＳ
Ｐに設けられている。
‐ホスト１に埋め込まれている。対応するＴＣＰピアとＩＰピアはＩＰ‐ホスト
２に設けられ、ＩＰピアとＰＰＰピアはインターネットサービスプロバイダＩＳ
Ｐに設けられている。
【００１３】 階層化スキームの重要な側面の一つは、異なる階層は「透明」なことである。
これは、あるレイヤのピアは別のレイヤで発生することに対して自明であること
を意味する。例えば、ＰＰＰピアは、ＩＰ‐ホスト１とインターネットサービス
プロバイダＩＳＰとの間に擬似的なＰＰＰ接続を確立する。２つのＰＰＰピアは
使用されている物理接続の種類によらず独立に動く、つまり、下位のレイヤにど
のプロトコルが使用されているかとは独立に動く。同様に、ＰＰＰピアは上位の
レイヤから到来するパケットを透明に、つまりその中身を感知することなく通過
させる。
これは、あるレイヤのピアは別のレイヤで発生することに対して自明であること
を意味する。例えば、ＰＰＰピアは、ＩＰ‐ホスト１とインターネットサービス
プロバイダＩＳＰとの間に擬似的なＰＰＰ接続を確立する。２つのＰＰＰピアは
使用されている物理接続の種類によらず独立に動く、つまり、下位のレイヤにど
のプロトコルが使用されているかとは独立に動く。同様に、ＰＰＰピアは上位の
レイヤから到来するパケットを透明に、つまりその中身を感知することなく通過
させる。
【００１４】 図６に示した例では、移動ステーションＭＳと無線基地局ＢＴＳとの間に前方
誤差修正(ＦＥＣ)レイヤとインターリーブレイヤが設けられ、レイヤ２の伝送(
Ｌ２Ｒ)と無線接続プロトコル(ＲＬＰ)による接続が、端末適合機能ＴＡＦと移
動スイッチングセンタＭＳＣとの間に確立され、Ｖ．４２とＶ．３２インターフ
ェースが、中間動作機能ＩＷＦとインターネットプロバイダＩＳＰとの間に確立
される。これらのプロトコルは、ＲＬＰ以外全て既知なので、以下においてはこ
れ以上詳細な記述を行わないことにする。
誤差修正(ＦＥＣ)レイヤとインターリーブレイヤが設けられ、レイヤ２の伝送(
Ｌ２Ｒ)と無線接続プロトコル(ＲＬＰ)による接続が、端末適合機能ＴＡＦと移
動スイッチングセンタＭＳＣとの間に確立され、Ｖ．４２とＶ．３２インターフ
ェースが、中間動作機能ＩＷＦとインターネットプロバイダＩＳＰとの間に確立
される。これらのプロトコルは、ＲＬＰ以外全て既知なので、以下においてはこ
れ以上詳細な記述を行わないことにする。
【００１５】 ＲＬＰは上位の階層からのデータの移動を担当するものでは有るが、カプセル
化によってこれを行うのではなく、つまり、上位の階層のデータユニットを１つ
の下位のレイヤのデータユニットとするのではなく、ＲＬＰは分割を行う、つま
り、上位の１つのデータユニットを複数のセグメントに分割して、それぞれのセ
グメントを１つの下位のデータユニットに挿入することに留意する必要がある。
換言すれば、ＲＬＰデータユニットはそれが取り扱う上位のレイヤのデータユニ
ット（つまりＰＰＰフレーム)よりも小さい。上位のレイヤのデータユニットを
下位のレイヤのデータユニットに挿入する基本的な考え方は、本明細書では埋め
込みと称し、カプセル化と分割とを包括する概念である。
化によってこれを行うのではなく、つまり、上位の階層のデータユニットを１つ
の下位のレイヤのデータユニットとするのではなく、ＲＬＰは分割を行う、つま
り、上位の１つのデータユニットを複数のセグメントに分割して、それぞれのセ
グメントを１つの下位のデータユニットに挿入することに留意する必要がある。
換言すれば、ＲＬＰデータユニットはそれが取り扱う上位のレイヤのデータユニ
ット（つまりＰＰＰフレーム)よりも小さい。上位のレイヤのデータユニットを
下位のレイヤのデータユニットに挿入する基本的な考え方は、本明細書では埋め
込みと称し、カプセル化と分割とを包括する概念である。
【００１６】 上の記載からも理解されるように、異なるプロトコルに対応したパケットは、
場合に応じて、フレーム、セグメント、データグラム等のような異なる呼び名で
呼ばれる。明確化のために、本明細書では「パケット」の用語を、定義された構
文を有し、プロトコルによって予め定められたデータ構造を有するデータユニッ
トを包括的に意味するものとする。「データ構造」とは、規定された位置(アドレ
ス)に有る特定のデータが対応するプロトコルに従って特定の意味を有すること
を意味する。この一例を、高レヴェルデータリンク制御プロトコル(ＨＤＬＣ)に
基づくフレーム構造を示す図７を参照して説明する。ＨＤＬＣは非常に基本的な
プロトコルであり、ＰＰＰはＨＤＬＣの基本特性の多くを採用している。
場合に応じて、フレーム、セグメント、データグラム等のような異なる呼び名で
呼ばれる。明確化のために、本明細書では「パケット」の用語を、定義された構
文を有し、プロトコルによって予め定められたデータ構造を有するデータユニッ
トを包括的に意味するものとする。「データ構造」とは、規定された位置(アドレ
ス)に有る特定のデータが対応するプロトコルに従って特定の意味を有すること
を意味する。この一例を、高レヴェルデータリンク制御プロトコル(ＨＤＬＣ)に
基づくフレーム構造を示す図７を参照して説明する。ＨＤＬＣは非常に基本的な
プロトコルであり、ＰＰＰはＨＤＬＣの基本特性の多くを採用している。
【００１７】 図７に、アドレスフィールド、制御フィールド、情報フィールド及びチェック
フィールドを有するＨＤＬＣフレームを示す。ＨＤＬＣでは、アドレスフィール
ド、制御フィールド及び情報フィールドは可変長であるが、チェックフィールド
はプロトコルによって定められた固定長を有する。例えば、情報フィールドは単
に制御フィールドに続きチェック値の前の８文字である。
フィールドを有するＨＤＬＣフレームを示す。ＨＤＬＣでは、アドレスフィール
ド、制御フィールド及び情報フィールドは可変長であるが、チェックフィールド
はプロトコルによって定められた固定長を有する。例えば、情報フィールドは単
に制御フィールドに続きチェック値の前の８文字である。
【００１８】 従ってフィールドは前述の意味において規定された位置の例であり、プロトコ
ルは特定のフィールド内の特定の数が予め定められた方法に従って解釈されるべ
きことを定める、つまり、その値はプロトコルによって定められる特定の意味を
有する。
ルは特定のフィールド内の特定の数が予め定められた方法に従って解釈されるべ
きことを定める、つまり、その値はプロトコルによって定められる特定の意味を
有する。
【００１９】 本発明が解決する課題 パケットを送る際は、通信信頼性モードを付与することが知られている。つま
り、上述のＨＤＬＣは２つの通信信頼性、つまりいわゆる数値化されたモード（
またはＩ‐モード)及びいわゆる無番（ＵＩ‐モード)モードである。
り、上述のＨＤＬＣは２つの通信信頼性、つまりいわゆる数値化されたモード（
またはＩ‐モード)及びいわゆる無番（ＵＩ‐モード)モードである。
【００２０】 番号つきのモードにおいて、送り出されたパケットが受け取りピアで正しく受
け取られなかった場合には、送り側のピアは当該パケットを再度送信する。送信
されたパケットの数に基づいて、このようにして、遅延を生じはするが全てのパ
ケットが正しく伝達される。パケットが正しく受信された旨の情報は受信ピアか
ら送信ピアへの確認メッセージによって一般に伝達され、送信と再送信の正確な
流れの制御は移動ウインドウによって（いわゆるウインドウベースフロー制御に
よって)、送信側は確認を受領する前に複数のパケットを送信することによって
、つまり、パケットを送信するたびに個々のパケットについての受信確認をする
ことなく行われる。このフロー制御は当該技術において、例えば前出のスティー
ブンスの著書によって良く知られているのでここで繰り返すことはしない。
け取られなかった場合には、送り側のピアは当該パケットを再度送信する。送信
されたパケットの数に基づいて、このようにして、遅延を生じはするが全てのパ
ケットが正しく伝達される。パケットが正しく受信された旨の情報は受信ピアか
ら送信ピアへの確認メッセージによって一般に伝達され、送信と再送信の正確な
流れの制御は移動ウインドウによって（いわゆるウインドウベースフロー制御に
よって)、送信側は確認を受領する前に複数のパケットを送信することによって
、つまり、パケットを送信するたびに個々のパケットについての受信確認をする
ことなく行われる。このフロー制御は当該技術において、例えば前出のスティー
ブンスの著書によって良く知られているのでここで繰り返すことはしない。
【００２１】 番号つきのモードとは異なり、無番モードにおいては再送信は行われない。こ
れは、パケットが正しく受信されたか否かとは無関係に、パケットは所定の順序
で送信されるだけであることを意味する。このモードは送信が早い特徴を有する
が、伝送の信頼性は物理接続の品質に依存する。
れは、パケットが正しく受信されたか否かとは無関係に、パケットは所定の順序
で送信されるだけであることを意味する。このモードは送信が早い特徴を有する
が、伝送の信頼性は物理接続の品質に依存する。
【００２２】 伝送の信頼性は無線接続の場合に、特に問題となる。図６に示した例では、無
線接続プロトコルＲＬＰが使用されている。ＲＬＰの全ての知られている設定は
番号付のモードを使用するように固定されている。このようにして、通信品質が
大きく変動する無線接続による信頼性の有るデータの伝送が確保されている。図
６に示すように、移動局ＭＳが接続のセットアップにおいて、ＲＬＰを実行する
ことが内容に要求することができるように（図６に示した例では透明回路切替Ｇ
ＳＭデータサービスとも呼ばれる)システムを構成することが知られている。こ
れによって伝送遅延を縮小することができるが、その代わりに伝送の信頼性は低
下することになる。
線接続プロトコルＲＬＰが使用されている。ＲＬＰの全ての知られている設定は
番号付のモードを使用するように固定されている。このようにして、通信品質が
大きく変動する無線接続による信頼性の有るデータの伝送が確保されている。図
６に示すように、移動局ＭＳが接続のセットアップにおいて、ＲＬＰを実行する
ことが内容に要求することができるように（図６に示した例では透明回路切替Ｇ
ＳＭデータサービスとも呼ばれる)システムを構成することが知られている。こ
れによって伝送遅延を縮小することができるが、その代わりに伝送の信頼性は低
下することになる。
【００２３】 問題はＲＬＰや無線接続に限定されるものではなく、上述の番号付モードのよ
うに信頼性の有るモードを提供するどのようなプロトコルに関しても存在する。
うに信頼性の有るモードを提供するどのようなプロトコルに関しても存在する。
【００２４】 さらに、一般的に、特定のレイヤにおいてパケットを送信するために何れのモ
ードを選択すべきかという問題も存在する。
ードを選択すべきかという問題も存在する。
【００２５】 ブレーク他によるコメント募集(ＲｆＣ)２４７５、１９９８年１２付により（
http://www.ietf.org/htm.charters/diffserv-charger.html)、異なるサービス
のためのアーキテクチャーが知られている。ＲｆＣ２４７５はパスに存在するノ
ードにおける特定のホップごとの前進挙動(ＰＨＢ)を受け取ることができるよう
にパケットをクラス分類して指標をつけることを提案している。所定のプロトコ
ルレイヤに属するパケットのヘッダのヘッダ情報はそのプロトコルレイヤの操作
にのみ使用されるものである。区別されたサービスアーキテクチャは、ネットワ
ークに入ってくるトラヒックをネットワークの境界においてクラス分けして場合
によっては条件付けを行い、異なる挙動の集合に対応付けるモデルに基づくもの
である。それぞれの挙動の集合は単一の区別されたサービス(ＤＳ)コードポイン
トによって区別される。トラフィックストリーム中のパケットをパケットヘッダ
中の一部に含まれる内容に基づいて選別するパケット分類機能が記述されている
。すでに述べたように、ＩＰレイヤに属するＤＳコードポイントやＤＳフィール
ドは、そのＩＰレイヤにおいてのみ使用される。ＤＳコードポイントのみに基づ
いてパケットを分類する挙動集合分類手段が記載されている。同様に、１つ以上
のヘッダフィールドの組み合わせからなる値によってパケットを分類する多フィ
ールド分類手段が記載されている。
http://www.ietf.org/htm.charters/diffserv-charger.html)、異なるサービス
のためのアーキテクチャーが知られている。ＲｆＣ２４７５はパスに存在するノ
ードにおける特定のホップごとの前進挙動(ＰＨＢ)を受け取ることができるよう
にパケットをクラス分類して指標をつけることを提案している。所定のプロトコ
ルレイヤに属するパケットのヘッダのヘッダ情報はそのプロトコルレイヤの操作
にのみ使用されるものである。区別されたサービスアーキテクチャは、ネットワ
ークに入ってくるトラヒックをネットワークの境界においてクラス分けして場合
によっては条件付けを行い、異なる挙動の集合に対応付けるモデルに基づくもの
である。それぞれの挙動の集合は単一の区別されたサービス(ＤＳ)コードポイン
トによって区別される。トラフィックストリーム中のパケットをパケットヘッダ
中の一部に含まれる内容に基づいて選別するパケット分類機能が記述されている
。すでに述べたように、ＩＰレイヤに属するＤＳコードポイントやＤＳフィール
ドは、そのＩＰレイヤにおいてのみ使用される。ＤＳコードポイントのみに基づ
いてパケットを分類する挙動集合分類手段が記載されている。同様に、１つ以上
のヘッダフィールドの組み合わせからなる値によってパケットを分類する多フィ
ールド分類手段が記載されている。
【００２６】 本発明の目的 上述の問題を解決し、より効率的にモードの選択制御を行うことができる、つ
まり送信信頼性と送信速度の関係を改善することのできるプロトコルを実現する
メカニズムを提供することが本発明の目的である。
まり送信信頼性と送信速度の関係を改善することのできるプロトコルを実現する
メカニズムを提供することが本発明の目的である。
【００２７】 発明の記述 上記の目的は、所定の第２のプロトコルによって規定された第２の構造を有す
るデータパケットを受け取るように構成された、第１の所定のプロトコルによっ
て規定される第１のデータ構造を有するデータパケットを作成し、前記の第１の
構造のデータパケット１つ以上に前記第２の構造を有するデータパケットを埋め
込んで前記第１の構造のデータパケットを作成する通信装置であって、前記第２
の構造を有するデータパケットの内容に基づいて、所定の規則に従って前記第２
の構造を有するデータパケットを区別するように構成された判別手段を有する独
立請求項に記載された装置によって達成する。
るデータパケットを受け取るように構成された、第１の所定のプロトコルによっ
て規定される第１のデータ構造を有するデータパケットを作成し、前記の第１の
構造のデータパケット１つ以上に前記第２の構造を有するデータパケットを埋め
込んで前記第１の構造のデータパケットを作成する通信装置であって、前記第２
の構造を有するデータパケットの内容に基づいて、所定の規則に従って前記第２
の構造を有するデータパケットを区別するように構成された判別手段を有する独
立請求項に記載された装置によって達成する。
【００２８】 発明の好ましい実施態様は従属請求項に記載されている。
【００２９】 本発明に従えば、プロトコルの実行は送信されるデータのタイプに依存し、送
信に関連するパラメータの設定を自動的に送信されるパケットの内容に応じて調
整するレイヤにおいて行うことができる。換言すれば、本発明はデータが上位の
レイヤから受け取られたものであることを考慮して、カプセル化又、セグメント
化、さらに転送（リンクに直接かあるいは低層のレイヤを介してであるかにかか
わらず)、調整可能なパラメータに関してクラス分類に従ってパケットごとにパ
ラメータが自動的に調整される異なるカテゴリーに分類される。
信に関連するパラメータの設定を自動的に送信されるパケットの内容に応じて調
整するレイヤにおいて行うことができる。換言すれば、本発明はデータが上位の
レイヤから受け取られたものであることを考慮して、カプセル化又、セグメント
化、さらに転送（リンクに直接かあるいは低層のレイヤを介してであるかにかか
わらず)、調整可能なパラメータに関してクラス分類に従ってパケットごとにパ
ラメータが自動的に調整される異なるカテゴリーに分類される。
【００３０】 内容という用語はいかなる内容をも含む広い意味で使用する。判別のために使
用する特定のタイプの内容は下位のレイヤの分類操作を考慮して特定のレイヤに
おいてパケットの製作時にデータに注意して追加されても良い、つまり、上位の
レイヤプロトコルの所定のフィールドを利用して、上位のレイヤのピアが下位の
レイヤでの処理に影響を与えるために上位のレイヤのピアが下位のレイヤのピア
に対して情報を特定することも可能であるし、あるいは、下位のレイヤにおける
判別処理は独立にかつ個々に、上位のレイヤからの影響無しに、下位のレイヤに
対して情報を伝達することを意図していないデータつまりヘッダのプロトコルＩ
Ｄを分析することによって行うことも可能であることに留意する必要がある。
用する特定のタイプの内容は下位のレイヤの分類操作を考慮して特定のレイヤに
おいてパケットの製作時にデータに注意して追加されても良い、つまり、上位の
レイヤプロトコルの所定のフィールドを利用して、上位のレイヤのピアが下位の
レイヤでの処理に影響を与えるために上位のレイヤのピアが下位のレイヤのピア
に対して情報を特定することも可能であるし、あるいは、下位のレイヤにおける
判別処理は独立にかつ個々に、上位のレイヤからの影響無しに、下位のレイヤに
対して情報を伝達することを意図していないデータつまりヘッダのプロトコルＩ
Ｄを分析することによって行うことも可能であることに留意する必要がある。
【００３１】 本発明は、従って、全てのレイヤは互いに独立に用いられなければならないと
いう強固に確立された規準と基本的に矛盾するものである。これまで知られてい
たものとは対照的に、接続を確立する際に、下位のレイヤにおいて、上位のレイ
ヤに特定のパラメータ（つまり信頼性)をセットさせる可能性に対して、本発明
は所定のレイヤにおける所定のプロトコルに情報を与え、柔軟にかつそれ自身の
決定に従って連続的にどの種類のパケットが送信されるかに従ってパラメータを
設定するものである。
いう強固に確立された規準と基本的に矛盾するものである。これまで知られてい
たものとは対照的に、接続を確立する際に、下位のレイヤにおいて、上位のレイ
ヤに特定のパラメータ（つまり信頼性)をセットさせる可能性に対して、本発明
は所定のレイヤにおける所定のプロトコルに情報を与え、柔軟にかつそれ自身の
決定に従って連続的にどの種類のパケットが送信されるかに従ってパラメータを
設定するものである。
【００３２】 本発明の好ましい実施例によれば、前記の調整可能なパラメータは信頼性モー
ドに関連し、信頼性モード(番号つき又は無番のモード)は、判別結果に従って、
埋め込みを行うレイヤにおいて自動的に調整される。
ドに関連し、信頼性モード(番号つき又は無番のモード)は、判別結果に従って、
埋め込みを行うレイヤにおいて自動的に調整される。
【００３３】 この好ましい実施例によれば、本発明が適用される送信信頼性モードが異なる
データパケットが複数のピアの間で自動的に同時送信することができる利点を有
する。例えば、セグメンテーションによってＰＰＰパケットの埋め込みを行い、
上位のレイヤのパケットのカプセル化を行うＩＰあるいはより上位のＴＣＰやＵ
ＤＰにおけるＲＬＰの埋め込みに本発明を利用すれば、本発明に基づくＲＬＰの
実行によってＵＤＰパケットを含むパケットとＴＣＰパケットを含むパケットと
を区別することができ、したがって、ＲＬＰレイヤにおいて、ＵＤＰパケットは
無番モードで送信しＴＣＰパケットは番号つきモードで送信することが可能にな
る。
データパケットが複数のピアの間で自動的に同時送信することができる利点を有
する。例えば、セグメンテーションによってＰＰＰパケットの埋め込みを行い、
上位のレイヤのパケットのカプセル化を行うＩＰあるいはより上位のＴＣＰやＵ
ＤＰにおけるＲＬＰの埋め込みに本発明を利用すれば、本発明に基づくＲＬＰの
実行によってＵＤＰパケットを含むパケットとＴＣＰパケットを含むパケットと
を区別することができ、したがって、ＲＬＰレイヤにおいて、ＵＤＰパケットは
無番モードで送信しＴＣＰパケットは番号つきモードで送信することが可能にな
る。
【００３４】 この例ですでに述べたように、信頼性モードの設定に関する実施例は好ましく
はリンクレイヤのプロトコル（例えばＲＬＰ)の実行に適用されるものである。
同様に、カテゴリへの分類は好ましくは、分類された上位のレイヤパケットの信
頼性規定を考慮して行われる。上述の例では、ＵＤＰパケットは無番モードで送
信されるカテゴリに分類されるが、このことはＵＤＰが誤差を含むパケットの再
送信を行わないことを考慮すると長所である。対照的に、ＴＣＰは再送信の可能
性を提供する。本発明を適用することによって、ＴＣＰパケットとＵＤＰパケッ
トをＲＬＰレイヤで同時送信することが可能であり、この方式にもかかわらずＲ
ＬＰレイヤにおけるそれぞれのパケットの通信信頼性モードは、ＴＣＰパケット
を番号つきモードの必要な所望の信頼性の下で送信し、ＵＤＰパケットを同様に
番号つきのモードで送信しながら再送信による不要な遅延を生じることがない。
はリンクレイヤのプロトコル（例えばＲＬＰ)の実行に適用されるものである。
同様に、カテゴリへの分類は好ましくは、分類された上位のレイヤパケットの信
頼性規定を考慮して行われる。上述の例では、ＵＤＰパケットは無番モードで送
信されるカテゴリに分類されるが、このことはＵＤＰが誤差を含むパケットの再
送信を行わないことを考慮すると長所である。対照的に、ＴＣＰは再送信の可能
性を提供する。本発明を適用することによって、ＴＣＰパケットとＵＤＰパケッ
トをＲＬＰレイヤで同時送信することが可能であり、この方式にもかかわらずＲ
ＬＰレイヤにおけるそれぞれのパケットの通信信頼性モードは、ＴＣＰパケット
を番号つきモードの必要な所望の信頼性の下で送信し、ＵＤＰパケットを同様に
番号つきのモードで送信しながら再送信による不要な遅延を生じることがない。
【００３５】 上述の例に関しては、発明には非常に大きな利点がある。ＰＰＰは、ＩＰ、Ｌ
ＣＰ（リンク制御プロトコル)、ＰＡＰ(パスワード認証プロトコル)等のような
複数のプロトコルをシリアルリンクを介して同時に伝送するために使用される。
ＰＰＰプロトコル識別子は、特定のＰＰＰパケットにどのプロトコルデータユニ
ット(ＰＤＵ)またはプロトコルパケットが含まれているかを表示する。ＰＰＰに
よって送信されるＩＰは、ＴＣＰ、ＵＤＰ及びＩＣＭＰ(インターネット制御メ
ッセージプロトコル)複数プロトコルのパケットを送信することができ、これら
のプロトコルもまたＩＰヘッダの中のプロトコル識別によって区別される。ＰＰ
Ｐによって送信されるプロトコルは、信頼性と遅延に関するトレードオフ要求が
異なる。したがって、特定のデータストリームに対して番号つきモードが好まし
いか、あるいは無番モードが好ましいかは一様でない。より具体的には、ＬＣＰ
やＰＡＰのような信号メッセージは番号つきモードで送信する必要があり、実時
間データストリーム（例えば、ＵＤＰパケットで送信されるインターネット電話
会話の音声信号）は通常データ喪失に強いが遅延に敏感なので、無番モードによ
る送信が好ましい。
ＣＰ（リンク制御プロトコル)、ＰＡＰ(パスワード認証プロトコル)等のような
複数のプロトコルをシリアルリンクを介して同時に伝送するために使用される。
ＰＰＰプロトコル識別子は、特定のＰＰＰパケットにどのプロトコルデータユニ
ット(ＰＤＵ)またはプロトコルパケットが含まれているかを表示する。ＰＰＰに
よって送信されるＩＰは、ＴＣＰ、ＵＤＰ及びＩＣＭＰ(インターネット制御メ
ッセージプロトコル)複数プロトコルのパケットを送信することができ、これら
のプロトコルもまたＩＰヘッダの中のプロトコル識別によって区別される。ＰＰ
Ｐによって送信されるプロトコルは、信頼性と遅延に関するトレードオフ要求が
異なる。したがって、特定のデータストリームに対して番号つきモードが好まし
いか、あるいは無番モードが好ましいかは一様でない。より具体的には、ＬＣＰ
やＰＡＰのような信号メッセージは番号つきモードで送信する必要があり、実時
間データストリーム（例えば、ＵＤＰパケットで送信されるインターネット電話
会話の音声信号）は通常データ喪失に強いが遅延に敏感なので、無番モードによ
る送信が好ましい。
【００３６】 従来知られている実施方法とシステムではこの問題を解決することができない
。ＲＬＰが番号つきのモードに固定して動いていれば、実時間のＵＤＰデータス
トリームを番号つきのモードを必要としているデータストリーム（例えばＴＣＰ
)と移動計算装置の上で同時に送信することはできない。ＲＬＰが使用されてい
なければ、回路切替接続が達成された後は、つまり課金が開始された後は、無番
モードでＬＣＰパケットのデータが変容する可能性があるので、ＰＰＰ接続を行
うことができない。したがって、利用者は使用料を支払わなければならないにも
かかわらず必要なサービスを受けることができない。
。ＲＬＰが番号つきのモードに固定して動いていれば、実時間のＵＤＰデータス
トリームを番号つきのモードを必要としているデータストリーム（例えばＴＣＰ
)と移動計算装置の上で同時に送信することはできない。ＲＬＰが使用されてい
なければ、回路切替接続が達成された後は、つまり課金が開始された後は、無番
モードでＬＣＰパケットのデータが変容する可能性があるので、ＰＰＰ接続を行
うことができない。したがって、利用者は使用料を支払わなければならないにも
かかわらず必要なサービスを受けることができない。
【００３７】 本発明は、ＲＬＰの実行が自動的にＬＣＰメッセージを番号つきモードで送っ
て安全なＰＰＰリンクを達成し、続いて無番モードでＵＤＰパケットを含むＰＰ
Ｐパケットを送ることで、遅延を生じさせずにこの問題を解消するものである。
さらに、同一の接続において異なる時間に種類の異なるパケットを送るこの問題
を解決するだけでなく、本発明は同時に２つの（信頼性に関して）互いに対立す
るストリームを並行して送信する、例えば上述のＵＤＰデータストリームと同時
にＴＣＰパケットを送信することを可能にするものである。
て安全なＰＰＰリンクを達成し、続いて無番モードでＵＤＰパケットを含むＰＰ
Ｐパケットを送ることで、遅延を生じさせずにこの問題を解消するものである。
さらに、同一の接続において異なる時間に種類の異なるパケットを送るこの問題
を解決するだけでなく、本発明は同時に２つの（信頼性に関して）互いに対立す
るストリームを並行して送信する、例えば上述のＵＤＰデータストリームと同時
にＴＣＰパケットを送信することを可能にするものである。
【００３８】 上述のプロトコルと上述の状態は本発明の実施例と利点を説明するために用い
た例に過ぎない点に留意する必要がある。すでに述べたように、信頼性の設定に
関する実施例は２つ以上の信頼性モードを許容するプロトコルの実行に用いるこ
とができる。例えば、本発明はＬＬＣ（論理リンク制御）パケットをＲＬＣ（無
線リンク制御）リンク上で送信する場合にも使用することができる。同様に、実
施の位置は上述の図６に示した例に限定されず、与えられたプロトコルにおいて
適当又は必要な位置であれば何処にでも用いることができる。例えば、一般パケ
ット無線サービス(ＧＰＲＳ)においては、ＴＡＦとＧＳＮ（ＧＰＲＳサポートノ
ード)である。
た例に過ぎない点に留意する必要がある。すでに述べたように、信頼性の設定に
関する実施例は２つ以上の信頼性モードを許容するプロトコルの実行に用いるこ
とができる。例えば、本発明はＬＬＣ（論理リンク制御）パケットをＲＬＣ（無
線リンク制御）リンク上で送信する場合にも使用することができる。同様に、実
施の位置は上述の図６に示した例に限定されず、与えられたプロトコルにおいて
適当又は必要な位置であれば何処にでも用いることができる。例えば、一般パケ
ット無線サービス(ＧＰＲＳ)においては、ＴＡＦとＧＳＮ（ＧＰＲＳサポートノ
ード)である。
【００３９】 結果的には、このことは、本発明を信頼性モードの設定に適用することによっ
て自動的に、提供または選択された通信信頼性モードの数に対応して、特定のパ
ケットを特定の仮想チャネルに設定する、仮想的通信信頼性チャネルが提供され
ることを意味する。上述の例では、番号つきチャネルと無番チャネルが提供され
、ＴＣＰパケット（より正確に言えばＴＣＰパケットを埋め込んだパケット)が
番号つきチャネルで送られＵＤＰパケットが無番チャネルで送られるように、２
つの送信信頼性モードが使用されているので、２つの仮想的チャネルが提供され
ることになる。
て自動的に、提供または選択された通信信頼性モードの数に対応して、特定のパ
ケットを特定の仮想チャネルに設定する、仮想的通信信頼性チャネルが提供され
ることを意味する。上述の例では、番号つきチャネルと無番チャネルが提供され
、ＴＣＰパケット（より正確に言えばＴＣＰパケットを埋め込んだパケット)が
番号つきチャネルで送られＵＤＰパケットが無番チャネルで送られるように、２
つの送信信頼性モードが使用されているので、２つの仮想的チャネルが提供され
ることになる。
【００４０】 上述の例をより一般的に表現すれば、本発明は、運転モード（ＡＲＱのこの意
味においては信頼性モード) の選択が埋め込まれたパケットの内容に基づくこと
ができるＡＲＱ準拠誤り修正（ＡＲＱは自動繰り返し要求)に適用することがで
きる。適用可能なモードは当然２つ、つまり、非信頼（ＵＩモード)と信頼（Ｉ
モード)、に限定されず、非信頼（ＵＩモード)と信頼（Ｉモード)に加えて前記
の２つのモードに加えてシーケンス中の配信又はシーケンス外の配信による半信
頼モードを有するなどもっと数が多くても良い。
味においては信頼性モード) の選択が埋め込まれたパケットの内容に基づくこと
ができるＡＲＱ準拠誤り修正（ＡＲＱは自動繰り返し要求)に適用することがで
きる。適用可能なモードは当然２つ、つまり、非信頼（ＵＩモード)と信頼（Ｉ
モード)、に限定されず、非信頼（ＵＩモード)と信頼（Ｉモード)に加えて前記
の２つのモードに加えてシーケンス中の配信又はシーケンス外の配信による半信
頼モードを有するなどもっと数が多くても良い。
【００４１】 上述のように、本発明は信頼性モードの設定に提供することができるが、これ
に限定されるわけではない。全く反対に、本発明は上位のレイヤのパケットを下
位のレイヤに埋め込むことに関する全ての種類の処理モードの設定又は調整に対
して適用することができる。より具体的には、本発明は、少なくとも２つのモー
ドを有する全ての通信スキームに対して適用することができる。例えば、受信側
が誤りを有するフレームを廃棄する、受信側が誤りを有するフレームに標識をつ
けるが廃棄しない、あるいは、受信側が誤りを有するフレームに標識もせずに廃
棄もせず、判別操作は当然これらのうちの２つのモード又は３つのモード全てに
もとづくものであるような動作モードを有するＦＣＳ（フレームチェックシーケ
ンス）エラー検出通信スキームである。あるいは、本発明は、２つあるいはそれ
以上のＦＥＣスキームを使用した動作モードを使用したＦＥＣ準拠エラー修正（
前方エラー制御)に適用することもできる。あるいは、本発明は、例えば、２つ
あるいはそれ以上のインターリーブスキームを利用した動作モードを利用したイ
ンターリーブに基づくエラー防止通信スキームに適用することができる。あるい
は、本発明は、例えば、２つ又はそれ以上のパワーレベルを利用した動作モード
を利用したパワー制御通信スキームに適用することができる。さらに本発明は、
例えば、２つ又はそれ以上の拡散係数を使用した拡散に基づく(例えばＣＤＭＡ
のようなスペクトル拡散技術）通信スキームに適用することができる。また本発
明は、例えば２つ又はそれ以上のフレーム長を採ることができる動作モードを利
用したフレーム長制御通信スキームに対して適用することができる。また、本発
明は、例えばＧＰＲＳ通信規準のような１、２、３、・・・８倍スロット割り当
てのような適当な動作モードを利用したバンド幅保存制御通信スキームに提供す
ることができる。
に限定されるわけではない。全く反対に、本発明は上位のレイヤのパケットを下
位のレイヤに埋め込むことに関する全ての種類の処理モードの設定又は調整に対
して適用することができる。より具体的には、本発明は、少なくとも２つのモー
ドを有する全ての通信スキームに対して適用することができる。例えば、受信側
が誤りを有するフレームを廃棄する、受信側が誤りを有するフレームに標識をつ
けるが廃棄しない、あるいは、受信側が誤りを有するフレームに標識もせずに廃
棄もせず、判別操作は当然これらのうちの２つのモード又は３つのモード全てに
もとづくものであるような動作モードを有するＦＣＳ（フレームチェックシーケ
ンス）エラー検出通信スキームである。あるいは、本発明は、２つあるいはそれ
以上のＦＥＣスキームを使用した動作モードを使用したＦＥＣ準拠エラー修正（
前方エラー制御)に適用することもできる。あるいは、本発明は、例えば、２つ
あるいはそれ以上のインターリーブスキームを利用した動作モードを利用したイ
ンターリーブに基づくエラー防止通信スキームに適用することができる。あるい
は、本発明は、例えば、２つ又はそれ以上のパワーレベルを利用した動作モード
を利用したパワー制御通信スキームに適用することができる。さらに本発明は、
例えば、２つ又はそれ以上の拡散係数を使用した拡散に基づく(例えばＣＤＭＡ
のようなスペクトル拡散技術）通信スキームに適用することができる。また本発
明は、例えば２つ又はそれ以上のフレーム長を採ることができる動作モードを利
用したフレーム長制御通信スキームに対して適用することができる。また、本発
明は、例えばＧＰＲＳ通信規準のような１、２、３、・・・８倍スロット割り当
てのような適当な動作モードを利用したバンド幅保存制御通信スキームに提供す
ることができる。
【００４２】 本発明の重要な利点の一つは、本発明は基本的にプロトコルの変更を必要とせ
ず、ピア実行の変更のみによって適合性や移行の問題を生じずにどのような内容
に対しても広く適用可能な点である。
ず、ピア実行の変更のみによって適合性や移行の問題を生じずにどのような内容
に対しても広く適用可能な点である。
【００４３】 本発明の他の好ましい実施例によれば、本発明は、上位のレイヤのパケット又
はデータユニットが下位のレイヤで埋め込まれるときに上位のレイヤのピアによ
って特定された通信品質の要求に従って、仮想のレイヤでパケット通信を行うこ
とができる(たとえばＱｏＳ(サービス品質)要求および／又は通信特性) 。上位
のレイヤのピアはそのレイヤのパケットを下位のレイヤに品質要求を送るための
ビークルとして使用する、つまり、前記品質要求を両方のレイヤにおいて理解さ
れる標準化されたスキームが存在する。たとえば、これは上位のレイヤパケット
のヘッダ中の所定のフィールドを使用して、そのフィールドに含まれる内容を標
準化することによって行われる。他の表現をすれば、上位のレイヤから下位のレ
イヤに品質要求を伝達するためにある種の制御チャネルが提供されている。この
品質要求は上位のレイヤパケットやフロー（フローは特定することができる連続
したパケットである)をオペレーティングモードのために下位のレイヤに伝達さ
れるだけでなく、前記品質要求に基づいて少なくとも一部については、それ自身
によってオペレーションモードを動的に適用する。
はデータユニットが下位のレイヤで埋め込まれるときに上位のレイヤのピアによ
って特定された通信品質の要求に従って、仮想のレイヤでパケット通信を行うこ
とができる(たとえばＱｏＳ(サービス品質)要求および／又は通信特性) 。上位
のレイヤのピアはそのレイヤのパケットを下位のレイヤに品質要求を送るための
ビークルとして使用する、つまり、前記品質要求を両方のレイヤにおいて理解さ
れる標準化されたスキームが存在する。たとえば、これは上位のレイヤパケット
のヘッダ中の所定のフィールドを使用して、そのフィールドに含まれる内容を標
準化することによって行われる。他の表現をすれば、上位のレイヤから下位のレ
イヤに品質要求を伝達するためにある種の制御チャネルが提供されている。この
品質要求は上位のレイヤパケットやフロー（フローは特定することができる連続
したパケットである)をオペレーティングモードのために下位のレイヤに伝達さ
れるだけでなく、前記品質要求に基づいて少なくとも一部については、それ自身
によってオペレーションモードを動的に適用する。
【００４４】 通信品質要求は、上位のレイヤが下位のレイヤに対して特定のオペレーティン
グモードを設定させる品質命令と指定使用することができる制御情報であるか、
あるいは、下位のレイヤが当該品質要求を搬送している特定のパケットに対して
当該品質要求に従って自由に動作モードを選択するが、上位のレイヤは下位のレ
イヤがどのモードを選択するかについて直接制御を行わないものであることに留
意する必要がある。
グモードを設定させる品質命令と指定使用することができる制御情報であるか、
あるいは、下位のレイヤが当該品質要求を搬送している特定のパケットに対して
当該品質要求に従って自由に動作モードを選択するが、上位のレイヤは下位のレ
イヤがどのモードを選択するかについて直接制御を行わないものであることに留
意する必要がある。
【００４５】 本発明の上記以外の側面と利点は、本発明の好ましい実施態様を示す図面を参
照して行う以下の発明の好ましい実施例についての詳細な説明によって一層明ら
かになるはずである。
照して行う以下の発明の好ましい実施例についての詳細な説明によって一層明ら
かになるはずである。
【００４６】 ［発明の詳細な説明］ 通信信頼性モードの設定に関する実施例を示して本発明について説明すること
にする。既に述べたように、これは本発明の好ましい実施例であり、本発明の説
明のために記述するものである。しかし、発明は全ての種類の調製可能なパラメ
ータを設定することに適用可能で、セキュリティモードの設定に使用することも
できる。
にする。既に述べたように、これは本発明の好ましい実施例であり、本発明の説
明のために記述するものである。しかし、発明は全ての種類の調製可能なパラメ
ータを設定することに適用可能で、セキュリティモードの設定に使用することも
できる。
【００４７】 図１を参照して本発明の基本構成について説明する。この実施例の場合は、レ
イヤｎの通信プロトコルを装備した通信装置が上位のレイヤ(ｎ＋１)からパケッ
トを受け取り、このパケットをレイヤｎのパケットに埋め込む。既に述べたよう
に、「埋め込む」という言葉は、カプセル化およびセグメント化の両方を含む概
念である。説明の重複を避けるために、本発明の導入部分の記載はすべて本発明
の説明に取り込まれていることに注意する必要がある。
イヤｎの通信プロトコルを装備した通信装置が上位のレイヤ(ｎ＋１)からパケッ
トを受け取り、このパケットをレイヤｎのパケットに埋め込む。既に述べたよう
に、「埋め込む」という言葉は、カプセル化およびセグメント化の両方を含む概
念である。説明の重複を避けるために、本発明の導入部分の記載はすべて本発明
の説明に取り込まれていることに注意する必要がある。
【００４８】 たとえば、レイヤｎのプロトコルはＲＬＰであり、レイヤ（ｎ＋１）のパケッ
トはＰＰＰフレームであってもよく、この場合には埋め込みは、ＰＰＰフレーム
又はパケットを複数のＲＬＰパケットへの分割を意味することになる。ＰＰＰフ
レームは典型的には１５００バイトの長さを有し、それに対してＲＬＰフレーム
は典型的には３０バイトの長さしかない。別の例を示せば、レイヤｎのプロトコ
ルがＰＰＰであって、レイヤ（ｎ＋１)のプロトコルがより上位の適当なプロト
コル、たとえば図５に示したようなプロトコルであって、この場合には埋め込み
はカプセル化によって行われる。
トはＰＰＰフレームであってもよく、この場合には埋め込みは、ＰＰＰフレーム
又はパケットを複数のＲＬＰパケットへの分割を意味することになる。ＰＰＰフ
レームは典型的には１５００バイトの長さを有し、それに対してＲＬＰフレーム
は典型的には３０バイトの長さしかない。別の例を示せば、レイヤｎのプロトコ
ルがＰＰＰであって、レイヤ（ｎ＋１)のプロトコルがより上位の適当なプロト
コル、たとえば図５に示したようなプロトコルであって、この場合には埋め込み
はカプセル化によって行われる。
【００４９】 本発明によれば、実施例は判別装置１を具備しており、これがレイヤｎ＋１の
パケットを受け取り、この判別装置が受け取ったパケットをあらかじめ定められ
たクラス分類規則に従って判別する。つまり、判別装置が受け取ったパケットの
特定の特徴を確認し、受け取ったパケットをその特徴に基づいて分類することを
意味する。この例の１つとして、レイヤｎのパケットがＰＰＰフレームであって
、受け取ったＰＰＰフレームの個々のヘッダをチェックしてこのフレームによっ
てどの種類の情報が送られているかを決定し、その結果に従ってフレームをクラ
ス分類する。たとえば、フレームがＬＣＰ情報を搬送していれば、これは「信頼
性の高い伝送」に分類され、これがＵＤＰ情報を搬送していれば、「信頼性は要
求されていない」カテゴリに分類される。
パケットを受け取り、この判別装置が受け取ったパケットをあらかじめ定められ
たクラス分類規則に従って判別する。つまり、判別装置が受け取ったパケットの
特定の特徴を確認し、受け取ったパケットをその特徴に基づいて分類することを
意味する。この例の１つとして、レイヤｎのパケットがＰＰＰフレームであって
、受け取ったＰＰＰフレームの個々のヘッダをチェックしてこのフレームによっ
てどの種類の情報が送られているかを決定し、その結果に従ってフレームをクラ
ス分類する。たとえば、フレームがＬＣＰ情報を搬送していれば、これは「信頼
性の高い伝送」に分類され、これがＵＤＰ情報を搬送していれば、「信頼性は要
求されていない」カテゴリに分類される。
【００５０】 上述のプロトコルとカテゴリは例示に過ぎないものであり、本発明は受信した
パケットをその内容にしたがってクラス分類することができる全ての形式のディ
スクリミネータに関連するものである。したがって、これらのパケットのプロト
コルは何でもよくパケットがクラス分類されるカテゴリの数は任意である。この
カテゴリの数はレイヤｎのプロトコルが提供する通信信頼性モードの数と同じで
あっても良いが、レイヤｎのプロトコルが２つ以上のモードを提供する場合には
それよりも少なくても良い。
パケットをその内容にしたがってクラス分類することができる全ての形式のディ
スクリミネータに関連するものである。したがって、これらのパケットのプロト
コルは何でもよくパケットがクラス分類されるカテゴリの数は任意である。この
カテゴリの数はレイヤｎのプロトコルが提供する通信信頼性モードの数と同じで
あっても良いが、レイヤｎのプロトコルが２つ以上のモードを提供する場合には
それよりも少なくても良い。
【００５１】 判別の結果、つまり、クラス分類は制御手段２に伝達され、制御手段２は次に
通信信頼性設定コマンドによって埋め込み手段３を制御する。換言すれば、判別
装置は埋め込まれるべきパケットを埋め込み手段３にし、そこでレイヤｎの１つ
以上のパケットに埋め込まれ、レイヤｎのそれぞれのパケットに対して対応する
フラグによって適宜設定されている通信信頼性モードが通信信頼性設定コマンド
に従って設定される。
通信信頼性設定コマンドによって埋め込み手段３を制御する。換言すれば、判別
装置は埋め込まれるべきパケットを埋め込み手段３にし、そこでレイヤｎの１つ
以上のパケットに埋め込まれ、レイヤｎのそれぞれのパケットに対して対応する
フラグによって適宜設定されている通信信頼性モードが通信信頼性設定コマンド
に従って設定される。
【００５２】 次に、このようにして作成されたレイヤｎのパケットは、次の処理ステージに
対して伝達される。次の処理ステージはアプリケーションによって異なり、所望
のあるいは必要な方法に従って適宜選択されることができる。たとえば、レイヤ
ｎのパケットが次の（図示しない）仮想レイヤ（ｎ−１）に直接進むことが意図
されていれば、レイヤｎのパケットは次のレイヤの入力バッファにただ渡される
だけであってもよい。しかし、もし、パケットを確立されたリンクを通じて送り
出すことが想定されている場合は、それらは出力バッファに置かれ、該当する状
況に応じて適宜制御されることが好ましい。その種の出力バッファからのデータ
送信の適当な制御はアプリケーションに依存する、つまりレイヤｎのプロトコル
とそのリンクに依存する。
対して伝達される。次の処理ステージはアプリケーションによって異なり、所望
のあるいは必要な方法に従って適宜選択されることができる。たとえば、レイヤ
ｎのパケットが次の（図示しない）仮想レイヤ（ｎ−１）に直接進むことが意図
されていれば、レイヤｎのパケットは次のレイヤの入力バッファにただ渡される
だけであってもよい。しかし、もし、パケットを確立されたリンクを通じて送り
出すことが想定されている場合は、それらは出力バッファに置かれ、該当する状
況に応じて適宜制御されることが好ましい。その種の出力バッファからのデータ
送信の適当な制御はアプリケーションに依存する、つまりレイヤｎのプロトコル
とそのリンクに依存する。
【００５３】 上述の記載から理解されるように、本発明は、１つのレイヤのパケットを他の
レイヤのパケットに埋め込み、少なくとも２つの異なる信頼性モードを提供する
どのようなプロトコルに対しても適用することができるので非常に柔軟性が高い
。
レイヤのパケットに埋め込み、少なくとも２つの異なる信頼性モードを提供する
どのようなプロトコルに対しても適用することができるので非常に柔軟性が高い
。
【００５４】 図２は、本発明にかかる方法を示すフローチャートである。第１のステップＳ
１では、より上位のレイヤのパケットが受信されたか否かが判断される。上位の
レイヤのパケットが受信されたときは、処理はＳ２に進み、受信されたパケット
はあらかじめ定められたクラス分類規則に従って判別される。次にステップＳ３
において、受信されたパケットは所定のレイヤの１つ又はそれ以上のパケットに
埋め込まれ（図１ではｎ）、パケットそれぞれの通信信頼性モードは判別結果に
従って設定される。最終的に、埋め込まれたパケットは次のステージに送られ、
そこで図２に示した処理によってパケットはステップＳ４で送信のために出力バ
ッファに送られる。
１では、より上位のレイヤのパケットが受信されたか否かが判断される。上位の
レイヤのパケットが受信されたときは、処理はＳ２に進み、受信されたパケット
はあらかじめ定められたクラス分類規則に従って判別される。次にステップＳ３
において、受信されたパケットは所定のレイヤの１つ又はそれ以上のパケットに
埋め込まれ（図１ではｎ）、パケットそれぞれの通信信頼性モードは判別結果に
従って設定される。最終的に、埋め込まれたパケットは次のステージに送られ、
そこで図２に示した処理によってパケットはステップＳ４で送信のために出力バ
ッファに送られる。
【００５５】 図１に示したシステムに対応し、かつ入出力バッファを具備するシステムを図
８に示す。図に示されているように、図８に示した装置もまた判別装置１、制御
手段２と埋め込み手段３とを有し、さらに入力バッファ４と出力バッファ５が図
示されているが、これらは共に制御手段２に接続されてこれによって制御されて
いる。この動作は図１に関して説明したものと同様であるが、レイヤｎのパケッ
トが入力バッファ４を通じて判別装置１に供給され、そこでは制御手段２が入力
バッファ４がパケットを判別装置１に適宜渡すように制御し、図８に一例を例示
したように、埋め込み手段３がレイヤｎのパケットを出力バッファに送り、次に
レイヤｎのこのパケットが制御手段２の制御の元で送り出されるされる点が異な
っている。
８に示す。図に示されているように、図８に示した装置もまた判別装置１、制御
手段２と埋め込み手段３とを有し、さらに入力バッファ４と出力バッファ５が図
示されているが、これらは共に制御手段２に接続されてこれによって制御されて
いる。この動作は図１に関して説明したものと同様であるが、レイヤｎのパケッ
トが入力バッファ４を通じて判別装置１に供給され、そこでは制御手段２が入力
バッファ４がパケットを判別装置１に適宜渡すように制御し、図８に一例を例示
したように、埋め込み手段３がレイヤｎのパケットを出力バッファに送り、次に
レイヤｎのこのパケットが制御手段２の制御の元で送り出されるされる点が異な
っている。
【００５６】 既に記載したように、本発明は、適当などのようなフロー制御をを選択する
ことができるという柔軟性を有する。たとえば、上述の番号つきモードと無番モ
ードのような２つの通信信頼性モードが存在する場合、レイヤｎの対応するパケ
ットは出力バッファ５の別々のキューに入れておくことができる。換言すれば、
レイヤｎのパケットに対して設定することができる通信信頼性モードが２つあれ
ば、出力バッファは番号つきのモードのパケット用のキューと無番パケット用の
キューの２つを具備することになる。
ことができるという柔軟性を有する。たとえば、上述の番号つきモードと無番モ
ードのような２つの通信信頼性モードが存在する場合、レイヤｎの対応するパケ
ットは出力バッファ５の別々のキューに入れておくことができる。換言すれば、
レイヤｎのパケットに対して設定することができる通信信頼性モードが２つあれ
ば、出力バッファは番号つきのモードのパケット用のキューと無番パケット用の
キューの２つを具備することになる。
【００５７】 一般的に、図８に示したこのシステムの１つの実施例では、出力バッファ５は
、通信信頼性モードそれぞれに対応してキューを有しており、パケットは判別装
置１によって判別されてそれぞれのキューに収用される。それぞれのキュー内の
パケットは適当な又は所望のどのような方法によっても取り扱うことができる、
つまり、それぞれのキューにあらかじめ設定した優先順位を設けることもできる
（固有の信頼性モード）。番号つきのモードと無番モードのみを有する場合の例
は、第１に送り出すべきパケットに関しては番号つきのパケットと無番のパケッ
トの間に基本的な優先順位は無いが（これらのパケットはどのキューにあったか
とは無関係にＦＩＦＯで扱われる）、再送しなければならない番号つきのパケッ
トは優先順位が高く、したがって優先的に送信される。このような場合には、番
号つきのモードのキューからのフローの制御は、これらのパケットを単に適当な
順序で送信することによって行われる。
、通信信頼性モードそれぞれに対応してキューを有しており、パケットは判別装
置１によって判別されてそれぞれのキューに収用される。それぞれのキュー内の
パケットは適当な又は所望のどのような方法によっても取り扱うことができる、
つまり、それぞれのキューにあらかじめ設定した優先順位を設けることもできる
（固有の信頼性モード）。番号つきのモードと無番モードのみを有する場合の例
は、第１に送り出すべきパケットに関しては番号つきのパケットと無番のパケッ
トの間に基本的な優先順位は無いが（これらのパケットはどのキューにあったか
とは無関係にＦＩＦＯで扱われる）、再送しなければならない番号つきのパケッ
トは優先順位が高く、したがって優先的に送信される。このような場合には、番
号つきのモードのキューからのフローの制御は、これらのパケットを単に適当な
順序で送信することによって行われる。
【００５８】 しかし、以下に他の実施例を用いて説明するように、上記とは異なる方法を採
用することも可能である。
用することも可能である。
【００５９】 本発明の好ましい実施例を図９ａと９ｂに示す。図２との関連で既に説明した
ステップには同じ引用番号をつけた。図９ａと９ｂに示した方法は、番号つきの
信頼性モード（Ｉ−モード)と無番の信頼性モード（ＵＩ−モード)を提供するプ
ロトコルが実行される場合に対応する。換言すれば、番号つきのモードでは、正
しく受信したことは確認パッケージによって送信側のピアに知らされ受信側のピ
アによってパケットが正しく受信されなかったときは当該パケットは再送信され
るが、無番モードでは再送信は行われない。
ステップには同じ引用番号をつけた。図９ａと９ｂに示した方法は、番号つきの
信頼性モード（Ｉ−モード)と無番の信頼性モード（ＵＩ−モード)を提供するプ
ロトコルが実行される場合に対応する。換言すれば、番号つきのモードでは、正
しく受信したことは確認パッケージによって送信側のピアに知らされ受信側のピ
アによってパケットが正しく受信されなかったときは当該パケットは再送信され
るが、無番モードでは再送信は行われない。
【００６０】 図９では、図２に示したものと同じ又はそれに対応するステップには同じ番号
を付与してある。第１のステップＳ１では、上位のレイヤのパケットが受信され
たか否かが決定される。仮にそうであれば、処理はステップＳ２１に進み、そこ
で受信された上位のレイヤのパケットに含まれるプロトコルＩＤが分析される。
たとえば、仮に受信された上位のパケットが図５の底部に示すようにＰＰＰフレ
ームであれば、プロセスは単に開始フラグから直接続くＰＰＰヘッダをチェック
するだけである。次に、ステップＳ２２において、確認されたプロトコルＩＤが
番号つきモードのものであるか否かが判断され、この分類は前述のあらかじめ設
定された規則にしたがって行われる。仮に、ＰＰＰパケットの場合は、前記の規
則はＬＣＰパケットを番号付のモードに入れるようにするものであることが好ま
しい。何故なら、ＬＣＰパケットは高レベルの信頼性が必要なリンク確立手順の
一部だからである。したがって、ステップＳ２２において、処理の結果ＬＣＰ情
報が送られてきたと判断されると、処理はステップＳ３１のほうに枝分かれし、
そこで受信された上位のレイヤのパケットは本発明が実行されているレイヤの１
つ又はそれ以上のパケットに埋め込まれ、埋め込まれたパケットそれぞれの信頼
性モードは、各パケットの対応する信頼性モードフラグを設定して番号つきのモ
ードに設定する。
を付与してある。第１のステップＳ１では、上位のレイヤのパケットが受信され
たか否かが決定される。仮にそうであれば、処理はステップＳ２１に進み、そこ
で受信された上位のレイヤのパケットに含まれるプロトコルＩＤが分析される。
たとえば、仮に受信された上位のパケットが図５の底部に示すようにＰＰＰフレ
ームであれば、プロセスは単に開始フラグから直接続くＰＰＰヘッダをチェック
するだけである。次に、ステップＳ２２において、確認されたプロトコルＩＤが
番号つきモードのものであるか否かが判断され、この分類は前述のあらかじめ設
定された規則にしたがって行われる。仮に、ＰＰＰパケットの場合は、前記の規
則はＬＣＰパケットを番号付のモードに入れるようにするものであることが好ま
しい。何故なら、ＬＣＰパケットは高レベルの信頼性が必要なリンク確立手順の
一部だからである。したがって、ステップＳ２２において、処理の結果ＬＣＰ情
報が送られてきたと判断されると、処理はステップＳ３１のほうに枝分かれし、
そこで受信された上位のレイヤのパケットは本発明が実行されているレイヤの１
つ又はそれ以上のパケットに埋め込まれ、埋め込まれたパケットそれぞれの信頼
性モードは、各パケットの対応する信頼性モードフラグを設定して番号つきのモ
ードに設定する。
【００６１】 ステップＳ２２で特定されたプロトコルＩＤは番号つきモードのものではない
ことが確認されると、ステップＳ２３において、プロトコルＩＤが無番モードの
ものであるか否かが判断される。そうであれば、処理はステップＳ３２に進み、
そこで、受信された上位のレイヤのパケットは本発明が実施されているレイヤの
１つ又は２つ以上のパケットに埋め込まれて、前記１つ又は２つ以上のパケット
のそれぞれの信頼性モードは適当なフラグを設定することによって無番モードに
設定される。ステップＳ２２とＳ２３の結果が共に否定的であれば、ステップＳ
２４は受信されたパケットのプロトコルレイヤまでチェックが行われることを示
しており、次のヘッダがチェックされる。図５の底部に示した例に戻れば、これ
は、ＴＣＰ、ＵＤＰまたはＩＣＭＰデータを識別するためのプロトコルＩＤを含
むＩＰヘッダである。次にステップＳ２１からＳ２４を繰り返す。もし識別され
たプロトコルＩＤが再度番号つきモードか無番モードかを特定できないときは、
処理は再度プロトコルレイヤ、図５に示した例の場合にはＴＣＰヘッダにあがる
。
ことが確認されると、ステップＳ２３において、プロトコルＩＤが無番モードの
ものであるか否かが判断される。そうであれば、処理はステップＳ３２に進み、
そこで、受信された上位のレイヤのパケットは本発明が実施されているレイヤの
１つ又は２つ以上のパケットに埋め込まれて、前記１つ又は２つ以上のパケット
のそれぞれの信頼性モードは適当なフラグを設定することによって無番モードに
設定される。ステップＳ２２とＳ２３の結果が共に否定的であれば、ステップＳ
２４は受信されたパケットのプロトコルレイヤまでチェックが行われることを示
しており、次のヘッダがチェックされる。図５の底部に示した例に戻れば、これ
は、ＴＣＰ、ＵＤＰまたはＩＣＭＰデータを識別するためのプロトコルＩＤを含
むＩＰヘッダである。次にステップＳ２１からＳ２４を繰り返す。もし識別され
たプロトコルＩＤが再度番号つきモードか無番モードかを特定できないときは、
処理は再度プロトコルレイヤ、図５に示した例の場合にはＴＣＰヘッダにあがる
。
【００６２】 一般に、所定のプロトコルパケットと番号つきモード又は無番モードの関係は
判断ステップＳ２２とＳ２３から参照される表に記憶されている。理想的には、
全ての可能なプロトコルが表に記録されており、受信されたパケットは全て番号
つきのモードか無番モードに分類されることが望ましい。しかし、経済性の観点
から、図９ａ、と９ｂに示したプロセスにフェールセーフシステム、つまり、次
のプロトコルレイヤにあがることができる回数が制限されているカウンタがステ
ップＳ２４に設けられており、あらかじめ定められた回数を超えると受信された
パケットに対してデフォルトモードを設定するようになっていることが好ましい
。このデフォルトモードは、番号付モードであっても無番モードであっても良い
、当然、別のフェイルセーフ構造も可能であり、必要又は所望に応じて選択する
ことができる。
判断ステップＳ２２とＳ２３から参照される表に記憶されている。理想的には、
全ての可能なプロトコルが表に記録されており、受信されたパケットは全て番号
つきのモードか無番モードに分類されることが望ましい。しかし、経済性の観点
から、図９ａ、と９ｂに示したプロセスにフェールセーフシステム、つまり、次
のプロトコルレイヤにあがることができる回数が制限されているカウンタがステ
ップＳ２４に設けられており、あらかじめ定められた回数を超えると受信された
パケットに対してデフォルトモードを設定するようになっていることが好ましい
。このデフォルトモードは、番号付モードであっても無番モードであっても良い
、当然、別のフェイルセーフ構造も可能であり、必要又は所望に応じて選択する
ことができる。
【００６３】 図９ｂに戻れば、ステップＳ３１とＳ３２の後、処理はステップＳ４に進み、
パケットは図２に示したものと同様に、出力バッファに送られる。処理は次にス
テップＳ１に戻って、次の上位レイヤパケットが受信されるのを待つ。
パケットは図２に示したものと同様に、出力バッファに送られる。処理は次にス
テップＳ１に戻って、次の上位レイヤパケットが受信されるのを待つ。
【００６４】 一般的には、図９に示した方法によれば、データパケットはパケットの内容に
関する情報を含む１つ以上のセクションを有し（プロトコルの階層をカプセル化
したパケット)、判別手段は前記１つ以上のセクションを分析してその内容に従
ってデータパケットを判別する。より正確に言えば、前記の１つ以上のセクショ
ンは対応するプロトコルレイヤに対応し、パケットの内容が関連づけられている
プロトコルを識別することができるプロトコル識別情報を含むパケットヘッダで
ある。パケットヘッダはプロトコルレイヤによって階層構造を有しており、判別
されるべきパケットに関しては、判別装置はまず第１の上位レイヤのプロトコル
に対応するヘッダのプロトコル識別子を決定し、次にこのプロトコル識別子を記
憶された規則と照らし合わせてプロトコル識別子とあらかじめ設定された通信信
頼性モードを対応させる。さらに、判別装置は前記パケットの通信信頼性モード
を、もしこのプロトコル識別子が記憶されている規則の中に発見できればあらか
じめ定められていた対応に基づいて通信信頼性モードを設定し、もし前記プロト
コル識別子が記憶されている規則の中に発見できなければ、階層上１つ上位の次
のプロトコルに関連づけられたヘッダに含まれるプロトコル識別子を読み出して
前記次のプロトコル識別子を通信信頼性モードを関連付ける記憶された規則と比
較する。ここで、プロトコル識別子を確定して比較する処理を、パケット中の判
別すべく決定されたプロトコル識別子が規則の１つにしたがってあらかじめ定め
られた通信信頼性モードの一つに対応付けられて通信信頼性モードが当該判別さ
れるべきパケットに対して設定されるか、あるいは、フェイルセーフ条件が満足
されて当該判別すべきパケットに対してデフォルト通信信頼性モードが設定され
る。
関する情報を含む１つ以上のセクションを有し（プロトコルの階層をカプセル化
したパケット)、判別手段は前記１つ以上のセクションを分析してその内容に従
ってデータパケットを判別する。より正確に言えば、前記の１つ以上のセクショ
ンは対応するプロトコルレイヤに対応し、パケットの内容が関連づけられている
プロトコルを識別することができるプロトコル識別情報を含むパケットヘッダで
ある。パケットヘッダはプロトコルレイヤによって階層構造を有しており、判別
されるべきパケットに関しては、判別装置はまず第１の上位レイヤのプロトコル
に対応するヘッダのプロトコル識別子を決定し、次にこのプロトコル識別子を記
憶された規則と照らし合わせてプロトコル識別子とあらかじめ設定された通信信
頼性モードを対応させる。さらに、判別装置は前記パケットの通信信頼性モード
を、もしこのプロトコル識別子が記憶されている規則の中に発見できればあらか
じめ定められていた対応に基づいて通信信頼性モードを設定し、もし前記プロト
コル識別子が記憶されている規則の中に発見できなければ、階層上１つ上位の次
のプロトコルに関連づけられたヘッダに含まれるプロトコル識別子を読み出して
前記次のプロトコル識別子を通信信頼性モードを関連付ける記憶された規則と比
較する。ここで、プロトコル識別子を確定して比較する処理を、パケット中の判
別すべく決定されたプロトコル識別子が規則の１つにしたがってあらかじめ定め
られた通信信頼性モードの一つに対応付けられて通信信頼性モードが当該判別さ
れるべきパケットに対して設定されるか、あるいは、フェイルセーフ条件が満足
されて当該判別すべきパケットに対してデフォルト通信信頼性モードが設定され
る。
【００６５】 本発明は上位のレイヤパケットをリンクを介して送信するパケットに埋め込む
際に分割を行うプロトコルであって、番号つきモードと無番モードの２種類の通
信信頼性モードを実行するものに適用されるのが好ましい。この種のプロトコル
としては、上述のＲＬＰやＲＬＣのような無線リンク状の通信を取り扱うプロト
コルを挙げることができる。
際に分割を行うプロトコルであって、番号つきモードと無番モードの２種類の通
信信頼性モードを実行するものに適用されるのが好ましい。この種のプロトコル
としては、上述のＲＬＰやＲＬＣのような無線リンク状の通信を取り扱うプロト
コルを挙げることができる。
【００６６】 この種のプロトコルに対する本発明の適用は、図８および９に示した実施例に
従って行われるのが好ましい。
従って行われるのが好ましい。
【００６７】 このような場合には、本発明は送信すべきパケットの埋め込みに関して特徴を
有するだけでなく、送信側のピアからそのような埋め込まれたリンクレイヤプロ
トコルを受信することに関しても、受信ピアとしての実行特性に関して特徴を有
するのが好ましい。
有するだけでなく、送信側のピアからそのような埋め込まれたリンクレイヤプロ
トコルを受信することに関しても、受信ピアとしての実行特性に関して特徴を有
するのが好ましい。
【００６８】 以下においては、送信機および受信機として使用されるリンクレイヤプロトコ
ルのピアのいくつかの基本的なメカニズムを、ＰＰＰフレームを分割して埋め込
むリンクレイヤプロトコルの例としてＲＬＰを使って説明することにする。ただ
し、これらのプロトコルは説明のために例示しただけであって、ここに説明した
メカニズムは他のどのようなプロトコルに対しても、適当であれば適用できるこ
とに留意する必要がある。
ルのピアのいくつかの基本的なメカニズムを、ＰＰＰフレームを分割して埋め込
むリンクレイヤプロトコルの例としてＲＬＰを使って説明することにする。ただ
し、これらのプロトコルは説明のために例示しただけであって、ここに説明した
メカニズムは他のどのようなプロトコルに対しても、適当であれば適用できるこ
とに留意する必要がある。
【００６９】 基本構成に基づけば、ＲＬＰ送信装置は上位のレイヤから受け取ったデータス
トリーム、つまりＰＰＰフレーム、を分析し、それぞれの上位レイヤフレームを
どのモードで、つまり番号つきモードか無番モードで、送信すべきかを決定する
。この処理は図８と９とに示した方法で実行されたのでここでは繰り返して説明
しない。出力バッファからのフロー制御は、番号つきモードと無番モードのＲＬ
Ｐパケットの(番号つきモードのパケットに関して、何故なら無番モードは常に
１度送られるだけだからである）第１の送信はＦＩＦＯにしたがって行われる。
しかし、再送信しなければならない番号つきモードのＲＬＰパケットは高い優先
順位を持っており、したがって、常に可能な限り速やかに送られる。
トリーム、つまりＰＰＰフレーム、を分析し、それぞれの上位レイヤフレームを
どのモードで、つまり番号つきモードか無番モードで、送信すべきかを決定する
。この処理は図８と９とに示した方法で実行されたのでここでは繰り返して説明
しない。出力バッファからのフロー制御は、番号つきモードと無番モードのＲＬ
Ｐパケットの(番号つきモードのパケットに関して、何故なら無番モードは常に
１度送られるだけだからである）第１の送信はＦＩＦＯにしたがって行われる。
しかし、再送信しなければならない番号つきモードのＲＬＰパケットは高い優先
順位を持っており、したがって、常に可能な限り速やかに送られる。
【００７０】 ＲＬＰ受信装置は無番モードと番号つきモードのパケットを分離してそれぞれ
固有の別のバッファ又は少なくとも別のキューに入れる。ＲＬＰ送信装置と同様
に、ＲＬＰ受信装置は常にそれぞれのバッファに含まれるデータを分析してこれ
によってより上位のレイヤフレームを判別する。より上位のレイヤフレームが一
度だけ受信されると、受信側の上位のレイヤに送られる。無番モードで送信され
たパケットに関しては、より高いレイヤのパケットのデリミタ(つまり開始又は
終了フラグ)が再送信が行われないために通信途中で変わってしまっている可能
性があるので、問題が起こる場合がある。この場合は、ＲＬＰ受信装置は無番モ
ードのパケットのために固定バッファリミットを使用し、これを越えた無番モー
ドのパケットはデリミタが受信されたか否かとは無関係に上位のレイヤに送られ
る。より正確に言えば、固定のバッファ限界を超過すると、ＲＬＰ受信装置は次
の上位レイヤパケットデリミタが検出されるまでＲＬＰは受信した全ての無番モ
ードのＲＬＰパケットを１つ上のレイヤに送る。前記の上位のレイヤパケットデ
リミタを新しい開始点として、ＲＬＰ受信装置はまた上位レイヤのパケットデリ
ミタが次に到着するのを待つことができる、つまり、次の完全な上位レイヤパケ
ットが受信されるのを待つことができる。
固有の別のバッファ又は少なくとも別のキューに入れる。ＲＬＰ送信装置と同様
に、ＲＬＰ受信装置は常にそれぞれのバッファに含まれるデータを分析してこれ
によってより上位のレイヤフレームを判別する。より上位のレイヤフレームが一
度だけ受信されると、受信側の上位のレイヤに送られる。無番モードで送信され
たパケットに関しては、より高いレイヤのパケットのデリミタ(つまり開始又は
終了フラグ)が再送信が行われないために通信途中で変わってしまっている可能
性があるので、問題が起こる場合がある。この場合は、ＲＬＰ受信装置は無番モ
ードのパケットのために固定バッファリミットを使用し、これを越えた無番モー
ドのパケットはデリミタが受信されたか否かとは無関係に上位のレイヤに送られ
る。より正確に言えば、固定のバッファ限界を超過すると、ＲＬＰ受信装置は次
の上位レイヤパケットデリミタが検出されるまでＲＬＰは受信した全ての無番モ
ードのＲＬＰパケットを１つ上のレイヤに送る。前記の上位のレイヤパケットデ
リミタを新しい開始点として、ＲＬＰ受信装置はまた上位レイヤのパケットデリ
ミタが次に到着するのを待つことができる、つまり、次の完全な上位レイヤパケ
ットが受信されるのを待つことができる。
【００７１】 ＲＬＰ受信装置が各上位レイヤパケットを区別する方法は、ＲＬＰ送信装置が
送信するデータの中に上位レイヤのデリミタを検出したらそれを全てコピーして
から送信させることである。換言すれば、データをその内容によって判別する代
わりに、ＲＬＰ送信機もまた１つ上位のレイヤつまりＰＰＰのデリミタを探し、
検出したデリミタの隣に必ず同じデリミタを挿入する。この方法は越えられてし
まった固定バッファリミットがＲＬＰの受信特性内であるとき、つまり、送信機
側のデリミタのコピーが送信機のバッファリミット特性と組み合わせられたとき
に利点がある。
送信するデータの中に上位レイヤのデリミタを検出したらそれを全てコピーして
から送信させることである。換言すれば、データをその内容によって判別する代
わりに、ＲＬＰ送信機もまた１つ上位のレイヤつまりＰＰＰのデリミタを探し、
検出したデリミタの隣に必ず同じデリミタを挿入する。この方法は越えられてし
まった固定バッファリミットがＲＬＰの受信特性内であるとき、つまり、送信機
側のデリミタのコピーが送信機のバッファリミット特性と組み合わせられたとき
に利点がある。
【００７２】 ＲＬＰの送信側と受信側に関連する他のメカニズムについて説明する。送信側
の特徴は前と同様、つまり、送信機は受け取ったデータストリームを分析して上
位のレイヤのフレームをどのモードで、つまり番号つきモードか無番モードか、
送信すべきかを決定する。出力バッファからのフロー制御は、再送信される番号
つきモードのパケットが常に最も高い優先順位を有するようなやり方で行われる
。ＲＬＰの受信特性に関しては、前述の例と同様に、受信機は受信した番号つき
モードパケットと無番パケットとをそれぞれに固有のバッファ又はキューに収用
する。この場合は、受信装置だけが上位のレイヤパケットを判別するために番号
つきモードのパケット(ＰＰＰフレーム)を解析する。一般に、受信装置は番号つ
きのモードと無番モードのパケットを、番号付のモードは正しい順で渡さなけれ
ばならないという通常の制約の下で、上位のレイヤにすぐに渡す。換言すれば、
これは、上位のレイヤに正しい順序で渡すために一定数のパケットを記憶しなけ
ればならないことになるのを回避するために、再送信が行われている番号付きパ
ケットの場合を除いて、受信バッファは通常は受信したパケットを保持すること
はせずに即刻次に引き渡す。
の特徴は前と同様、つまり、送信機は受け取ったデータストリームを分析して上
位のレイヤのフレームをどのモードで、つまり番号つきモードか無番モードか、
送信すべきかを決定する。出力バッファからのフロー制御は、再送信される番号
つきモードのパケットが常に最も高い優先順位を有するようなやり方で行われる
。ＲＬＰの受信特性に関しては、前述の例と同様に、受信機は受信した番号つき
モードパケットと無番パケットとをそれぞれに固有のバッファ又はキューに収用
する。この場合は、受信装置だけが上位のレイヤパケットを判別するために番号
つきモードのパケット(ＰＰＰフレーム)を解析する。一般に、受信装置は番号つ
きのモードと無番モードのパケットを、番号付のモードは正しい順で渡さなけれ
ばならないという通常の制約の下で、上位のレイヤにすぐに渡す。換言すれば、
これは、上位のレイヤに正しい順序で渡すために一定数のパケットを記憶しなけ
ればならないことになるのを回避するために、再送信が行われている番号付きパ
ケットの場合を除いて、受信バッファは通常は受信したパケットを保持すること
はせずに即刻次に引き渡す。
【００７３】 受信機が受信側でどのような順序でパケットを上位のレイヤに渡すかに関する
この規則によって４つの状態が区別される。 (ａ)無番モードのパケットのみが送信されており（たとえば、ＵＤＰセッション
と呼ばれる、送信側がＵＤＰパケットのみを送信している状態)、まったく問題
が無い。 (ｂ)番号つきモードのパケットのみが送信されており（たとえば、ＴＣＰセッシ
ョンと呼ばれる、送信側がＴＣＰパケットのみを送信している状態)、やはりま
ったく問題が無い。 (ｃ)無番モードのパケットに続いて番号つきモードのパケットが送信されている
(たとえばＵＤＰセッションに続いてＴＣＰセッションが行われている)、同様に
まったく問題が無い。 (ｄ)番号つきモードパケットに続いて無番モードのパケットが送信されている(
たとえば、ＴＣＰセッションに続いてＵＤＰセッションが、あるいは、ＵＤＰセ
ッションとＴＣＰセッションがパラレルに送信されている)、番号つきモードの
パケットが再送信を必要とするときに無番モードのパケットを受けとると問題が
起こりえる。
この規則によって４つの状態が区別される。 (ａ)無番モードのパケットのみが送信されており（たとえば、ＵＤＰセッション
と呼ばれる、送信側がＵＤＰパケットのみを送信している状態)、まったく問題
が無い。 (ｂ)番号つきモードのパケットのみが送信されており（たとえば、ＴＣＰセッシ
ョンと呼ばれる、送信側がＴＣＰパケットのみを送信している状態)、やはりま
ったく問題が無い。 (ｃ)無番モードのパケットに続いて番号つきモードのパケットが送信されている
(たとえばＵＤＰセッションに続いてＴＣＰセッションが行われている)、同様に
まったく問題が無い。 (ｄ)番号つきモードパケットに続いて無番モードのパケットが送信されている(
たとえば、ＴＣＰセッションに続いてＵＤＰセッションが、あるいは、ＵＤＰセ
ッションとＴＣＰセッションがパラレルに送信されている)、番号つきモードの
パケットが再送信を必要とするときに無番モードのパケットを受けとると問題が
起こりえる。
【００７４】 (ｄ)に記載した問題を解決するために、以下のメカニズムを使用することがで
きる。番号つきモードで送信した上位レイヤのパケットが完全に受信されていな
い以上(ＴＣＰパケットの終了を示すＰＰＰフレームデリミタを含むパケットが
再送信されなければならない)、無番モードのパケットは一時退避させられなけ
ればならない。バッファは番号つきモードパケット全体が受信されて受け渡され
るまでは上位レイヤに渡されることは無い。番号つきモードパケットが完全に受
信されて１つ上位のレイヤに渡された後、無番モードパケットを含むバッファが
渡される。それ以降は通常のオペレーションが続く。
きる。番号つきモードで送信した上位レイヤのパケットが完全に受信されていな
い以上(ＴＣＰパケットの終了を示すＰＰＰフレームデリミタを含むパケットが
再送信されなければならない)、無番モードのパケットは一時退避させられなけ
ればならない。バッファは番号つきモードパケット全体が受信されて受け渡され
るまでは上位レイヤに渡されることは無い。番号つきモードパケットが完全に受
信されて１つ上位のレイヤに渡された後、無番モードパケットを含むバッファが
渡される。それ以降は通常のオペレーションが続く。
【００７５】 上記に示したメカニズムの好ましい実施例に拠れば、受信機はさらにどのパケ
ットデリミタが現在使用されているかに関する知識又は情報を有している。デフ
ォールトデリミタは１つ上のレイヤの通常のパケットのデリミタ（つまりＰＰＰ
フレームデリミタ)であるが、もし他のデリミタを使用しなければならないなら
、２つのリンクレイヤ、つまり２つのＲＬＰピア相互の間で取り決めることがで
きる。これは換言すれば、上位レイヤのプロトコルパケットを処理すること、１
つ以上のプロトコルの処理もできることを意味している。ＰＰＰフレームがＲＬ
Ｐパケットに埋め込まれた前記の例においては、これはＲＬＰの実行はＰＰＰを
埋め込むだけでなく、ＰＰＰと同じレイヤに属する他のプロトコルのフレームを
埋め込むことも可能であることを意味する。受信機がこの情報を受け取る方法は
種々考えられる。リンクパラメータを相互間で決定する標準ＨＤＬＣフレームで
ある、特別な信号フレームやＸＩＤフレームを使用したＤＨＬＣ（たとえばＧＳ
ＭやＲＬＰ)に基づくリンクレイヤプロトコルの場合は、新しいパラメータを有
する前記ＸＩＤフレームを使用することができる。
ットデリミタが現在使用されているかに関する知識又は情報を有している。デフ
ォールトデリミタは１つ上のレイヤの通常のパケットのデリミタ（つまりＰＰＰ
フレームデリミタ)であるが、もし他のデリミタを使用しなければならないなら
、２つのリンクレイヤ、つまり２つのＲＬＰピア相互の間で取り決めることがで
きる。これは換言すれば、上位レイヤのプロトコルパケットを処理すること、１
つ以上のプロトコルの処理もできることを意味している。ＰＰＰフレームがＲＬ
Ｐパケットに埋め込まれた前記の例においては、これはＲＬＰの実行はＰＰＰを
埋め込むだけでなく、ＰＰＰと同じレイヤに属する他のプロトコルのフレームを
埋め込むことも可能であることを意味する。受信機がこの情報を受け取る方法は
種々考えられる。リンクパラメータを相互間で決定する標準ＨＤＬＣフレームで
ある、特別な信号フレームやＸＩＤフレームを使用したＤＨＬＣ（たとえばＧＳ
ＭやＲＬＰ)に基づくリンクレイヤプロトコルの場合は、新しいパラメータを有
する前記ＸＩＤフレームを使用することができる。
【００７６】 送信特性のみに関連する別のメカニズムについて説明する。換言すれば、受信
機についてはなんら変更が無い。したがって、受信機は常に無番モードパケット
を受信したときは無番モードパケットを、番号付のパケットは通常通り順序に従
って送り出す。したがって、上位のレイヤのパケット（つまりＰＰＰフレーム)
が受信機の側で正しく受け渡されることを確保するのは送信機である。これは、
送信機が無番モードのセッションを開始する前に、無番モードのパケットは完全
に終了していなければならない、つまり番号つきモードのパケットが受信機によ
って認識されなければならないことを意味している。受信機構を変更しないので
このメカニズムを導入するのは容易であるが、無番モードセッションと番号つき
モードセッションとが切り替わるときに遅延を生じる。
機についてはなんら変更が無い。したがって、受信機は常に無番モードパケット
を受信したときは無番モードパケットを、番号付のパケットは通常通り順序に従
って送り出す。したがって、上位のレイヤのパケット（つまりＰＰＰフレーム)
が受信機の側で正しく受け渡されることを確保するのは送信機である。これは、
送信機が無番モードのセッションを開始する前に、無番モードのパケットは完全
に終了していなければならない、つまり番号つきモードのパケットが受信機によ
って認識されなければならないことを意味している。受信機構を変更しないので
このメカニズムを導入するのは容易であるが、無番モードセッションと番号つき
モードセッションとが切り替わるときに遅延を生じる。
【００７７】 最後に、別のメカニズムは送信機の出力バッファを、送信機で無番モードセッ
ションが行われているときは、無番モードを示すフラグを有するＲＬＰフレーム
で全ての無番モードパケットを連続的に送信するというように制御する方法であ
る。
ションが行われているときは、無番モードを示すフラグを有するＲＬＰフレーム
で全ての無番モードパケットを連続的に送信するというように制御する方法であ
る。
【００７８】 既に述べたように、上述の例は好ましい実施例としてＲＬＰとＰＰＰを使用し
た場合について例示したが、このメカニズムはこれらのプロトコルに限定される
わけではない。むしろこれらは適当な特徴を有するプロトコルであればどのよう
なプロトコルにも使用できるものである。
た場合について例示したが、このメカニズムはこれらのプロトコルに限定される
わけではない。むしろこれらは適当な特徴を有するプロトコルであればどのよう
なプロトコルにも使用できるものである。
【００７９】 上述の実施例では、埋め込まれるパケットのパケットヘッダの特定のフィール
ド、つまり上位レイヤのＩＤフィールド、を用いて判別を行うこと、および、番
号つきモードと無番モードである信頼性に関する２つの動作モードを使用したＡ
ＲＱ−準拠誤り回復を用いた特定の通信スキームに基づいて発明を説明した。し
かし、本発明はいかなる意味においてもこれらに限定されるものではない。
ド、つまり上位レイヤのＩＤフィールド、を用いて判別を行うこと、および、番
号つきモードと無番モードである信頼性に関する２つの動作モードを使用したＡ
ＲＱ−準拠誤り回復を用いた特定の通信スキームに基づいて発明を説明した。し
かし、本発明はいかなる意味においてもこれらに限定されるものではない。
【００８０】 本発明はパケットどのような場所にあるかに無制限に、たとえばＤＳフィール
ドはＩＰオプションなどに限らず、またどのようなパケットの内容かに限らず判
別を行う方法を提供することができる。ＡＲＱに関連付けられた動作モードに関
しては、既に記載した番号モードと無番モードに加えて混合モードを使用するな
ど２つより多いモードを使用することもできる。
ドはＩＰオプションなどに限らず、またどのようなパケットの内容かに限らず判
別を行う方法を提供することができる。ＡＲＱに関連付けられた動作モードに関
しては、既に記載した番号モードと無番モードに加えて混合モードを使用するな
ど２つより多いモードを使用することもできる。
【００８１】 本発明は、ＡＲＱの通信スキームつまり誤り回復に関しても制限されず、どの
ような形のフォワード誤り修正を使用した動作モードに対しても適用することが
できる。より詳細には、本発明は少なくとも２つの異なる動作モード、たとえば
ＦＣＳ−に基づく誤り検出（ＦＣＳはフレームチェックシーケンスを意味する)
つまり受信機が誤りを有するフレームを廃棄するか、受信機は誤りを有するフレ
ームに標識をつけるが廃棄しないか、受信機は誤りを含むフレームを標識付けも
せず廃棄もしないか、２つのモード又は３つのモードの間で区別する動作モード
全てに対して適用することができる。本発明はまた、２つ以上のＦＥＣスキムを
使用したＦＥＣ−に基づく（フォワード誤り訂正)誤り訂正通信スキーム、に対
して適用することもできる。あるいは、本発明は２つ以上のインターリーブスキ
ームを使用した動作モードを用いたインターリーブに基づく誤り防止通信スキー
ムに対しても適用することができる。さらに、本発明は、２つ以上のパワーレベ
ルを使用した動作モードのパワー制御通信スキームに使用することもできる。さ
らに、本発明は、２つ以上の拡散係数を使用した動作モードを使用する拡散に基
づく誤り防止(たとえばＣＤＭＡのようなスペクトル拡散技術)通信スキームに適
用することができる。さらに、本発明は、フレーム長として２つ以上の長さを選
択することができる動作モードを利用したフレーム長制御通信スキームに適用す
ることができる。さらに本発明は、１，２，３，．．．または８時間スロット割
り当てのような動作モードつまりＧＰＲＳ通信標準を利用したバンド幅保存制御
の通信スキームに適用することができる。
ような形のフォワード誤り修正を使用した動作モードに対しても適用することが
できる。より詳細には、本発明は少なくとも２つの異なる動作モード、たとえば
ＦＣＳ−に基づく誤り検出（ＦＣＳはフレームチェックシーケンスを意味する)
つまり受信機が誤りを有するフレームを廃棄するか、受信機は誤りを有するフレ
ームに標識をつけるが廃棄しないか、受信機は誤りを含むフレームを標識付けも
せず廃棄もしないか、２つのモード又は３つのモードの間で区別する動作モード
全てに対して適用することができる。本発明はまた、２つ以上のＦＥＣスキムを
使用したＦＥＣ−に基づく（フォワード誤り訂正)誤り訂正通信スキーム、に対
して適用することもできる。あるいは、本発明は２つ以上のインターリーブスキ
ームを使用した動作モードを用いたインターリーブに基づく誤り防止通信スキー
ムに対しても適用することができる。さらに、本発明は、２つ以上のパワーレベ
ルを使用した動作モードのパワー制御通信スキームに使用することもできる。さ
らに、本発明は、２つ以上の拡散係数を使用した動作モードを使用する拡散に基
づく誤り防止(たとえばＣＤＭＡのようなスペクトル拡散技術)通信スキームに適
用することができる。さらに、本発明は、フレーム長として２つ以上の長さを選
択することができる動作モードを利用したフレーム長制御通信スキームに適用す
ることができる。さらに本発明は、１，２，３，．．．または８時間スロット割
り当てのような動作モードつまりＧＰＲＳ通信標準を利用したバンド幅保存制御
の通信スキームに適用することができる。
【００８２】 当然ながら、これらの通信スキームと動作モードはどのような任意の組み合わ
せも適当であれば可能である。これはたとえば番号付けられたモードと無番モー
ドおよび４つのパワーレベルが８つのモードつまり(Ｉ−モード、パワーレベル
１)、(Ｉ−モード、パワーレベル２)、．．．、（ＵＩ−モード、パワーレベル
４)と組み合わせられるパワー制御モードとＡＲＱ−関連モードの組み合わせか
らなる一般的な動作モードにおいて判別を行うことが可能であることを意味する
。既に述べたように、具体的なアプリケーションに好適なものであれば、任意の
組み合わせが可能である。
せも適当であれば可能である。これはたとえば番号付けられたモードと無番モー
ドおよび４つのパワーレベルが８つのモードつまり(Ｉ−モード、パワーレベル
１)、(Ｉ−モード、パワーレベル２)、．．．、（ＵＩ−モード、パワーレベル
４)と組み合わせられるパワー制御モードとＡＲＱ−関連モードの組み合わせか
らなる一般的な動作モードにおいて判別を行うことが可能であることを意味する
。既に述べたように、具体的なアプリケーションに好適なものであれば、任意の
組み合わせが可能である。
【００８３】 次に、図１０を参照してさらに別の好ましい実施例について説明する。この好
ましい実施例の場合には、本発明は、たとえばＱｏＳ（クオリティオブサービス
)要求および／または上位のレイヤのピアによって特定されて前記上位のレイヤ
のパケット又はデータユニットが下位のレイヤに埋め込まれる通信特性のような
通信品質要求に従って下位のレイヤにおけるパケット通信方法に適用される。
ましい実施例の場合には、本発明は、たとえばＱｏＳ（クオリティオブサービス
)要求および／または上位のレイヤのピアによって特定されて前記上位のレイヤ
のパケット又はデータユニットが下位のレイヤに埋め込まれる通信特性のような
通信品質要求に従って下位のレイヤにおけるパケット通信方法に適用される。
【００８４】 以下の記載においては、Ｌ３という用語は、たとえばＩＰｖ４やＩＰｖ６のよ
うなネットワークレイヤプロトコルを指すものとして使用する。図３を参照。Ｌ
３プロトコルによるデータユニット(ＰＤＵ)は、パケットと呼ばれ、ＰＤＵヘッ
ダはパケットヘッダと呼ばれる。Ｌ１／Ｌ２という用語は、たとえば、特定のネ
ットワークの物理および／またはリンクのレイヤのようなＬ３レイヤ下位の１つ
又は２つ以上のプロトコルを示す。ベアラという用語は、Ｌ１／Ｌ２の全て固定
された動作モードが固定されたＱｏＳ（クオリティオブサービス)セッティング
であって、全てのＬ１／Ｌ２動作モードが中間に設けられたＬ１／Ｌ２（たとえ
ば無線)の時刻毎の条件に依存して動的に適用されるものを意味する。ピアとい
う用語はプロセスに関連して使用されたときは、特定のレイヤにおいて共通のプ
ロトコルで通信を行うプロセスを意味する。一例として、ＷＷＷクライアントと
アプリケーションレイアでＨＴＴＰプロトコルで通信を行っているサーバ、トラ
ンスポートレイア上のＴＣＰ送信機と受信機、があり図６を参照されたい。以下
の文脈においては、ピアという用語は常にＬ３に直接又は間接的に基づくプロト
コルで通信するピアを意味する。フローという用語は、ピアからピアへのＬ３パ
ケットに基づく（パケット切り替え)通信であって、ソースアドレス、ソースポ
ート、あて先アドレス−あて先ポートおよびプロトコルＩＤで識別されるものを
意味する。換言すれば、フローは特定のＱoＳ要求を有すると考えられている。
ＱｏＳ要求は時間の経過と共に変化することがある。
うなネットワークレイヤプロトコルを指すものとして使用する。図３を参照。Ｌ
３プロトコルによるデータユニット(ＰＤＵ)は、パケットと呼ばれ、ＰＤＵヘッ
ダはパケットヘッダと呼ばれる。Ｌ１／Ｌ２という用語は、たとえば、特定のネ
ットワークの物理および／またはリンクのレイヤのようなＬ３レイヤ下位の１つ
又は２つ以上のプロトコルを示す。ベアラという用語は、Ｌ１／Ｌ２の全て固定
された動作モードが固定されたＱｏＳ（クオリティオブサービス)セッティング
であって、全てのＬ１／Ｌ２動作モードが中間に設けられたＬ１／Ｌ２（たとえ
ば無線)の時刻毎の条件に依存して動的に適用されるものを意味する。ピアとい
う用語はプロセスに関連して使用されたときは、特定のレイヤにおいて共通のプ
ロトコルで通信を行うプロセスを意味する。一例として、ＷＷＷクライアントと
アプリケーションレイアでＨＴＴＰプロトコルで通信を行っているサーバ、トラ
ンスポートレイア上のＴＣＰ送信機と受信機、があり図６を参照されたい。以下
の文脈においては、ピアという用語は常にＬ３に直接又は間接的に基づくプロト
コルで通信するピアを意味する。フローという用語は、ピアからピアへのＬ３パ
ケットに基づく（パケット切り替え)通信であって、ソースアドレス、ソースポ
ート、あて先アドレス−あて先ポートおよびプロトコルＩＤで識別されるものを
意味する。換言すれば、フローは特定のＱoＳ要求を有すると考えられている。
ＱｏＳ要求は時間の経過と共に変化することがある。
【００８５】 ピア（たとえばレガシーＷＷＷブラウザ)がフローのためにＱｏＳ要求を選択
したといった場合は、これは同時にピアのために別のプロセスがそうさせること
を含むことに留意する必要がある。
したといった場合は、これは同時にピアのために別のプロセスがそうさせること
を含むことに留意する必要がある。
【００８６】 図１０は、ＩＰパケットに適合した移動電話に好適にリンクした（図１０には
いわゆるブルートゥースリンクが示されている)移動ＩＰ−ホストを示す。電話
は無線アクセスネットワークを通じて無線のリンクを確立することができ、ＧＳ
Ｍ、ＧＰＲＳやＷ−ＣＤＭＡのようなどのような通信標準を使用することもでき
る。無線アクセスネットワークは、２つだけを図１０に示したが非常に多くのホ
ストが接続されているインターネットに接続されている。
いわゆるブルートゥースリンクが示されている)移動ＩＰ−ホストを示す。電話
は無線アクセスネットワークを通じて無線のリンクを確立することができ、ＧＳ
Ｍ、ＧＰＲＳやＷ−ＣＤＭＡのようなどのような通信標準を使用することもでき
る。無線アクセスネットワークは、２つだけを図１０に示したが非常に多くのホ
ストが接続されているインターネットに接続されている。
【００８７】 図の下の部分には通信状況が示されている。ピアＡ．１とＢ．１は移動局の例
として示されており、ピアＡ．２とＢ．２はそれぞれ対応する相手方である。こ
れらのピアはＱｏＳ要求および／または通信特性、一般的には制御情報としての
品質要求をＬ３レイヤに通過させる。ピアはＬ３ピアかＬ３よりも上位のレイヤ
のプロトコルである。これは、Ｌ３ヘッダの所定のフィールドを品質要求に関連
するものとして特定して、Ｌ３レイヤが、ピアがそのＱｏＳ要求および／または
優先度をフロー毎又はパケット毎のレベルとして使用されるようにすることで行
われる。
として示されており、ピアＡ．２とＢ．２はそれぞれ対応する相手方である。こ
れらのピアはＱｏＳ要求および／または通信特性、一般的には制御情報としての
品質要求をＬ３レイヤに通過させる。ピアはＬ３ピアかＬ３よりも上位のレイヤ
のプロトコルである。これは、Ｌ３ヘッダの所定のフィールドを品質要求に関連
するものとして特定して、Ｌ３レイヤが、ピアがそのＱｏＳ要求および／または
優先度をフロー毎又はパケット毎のレベルとして使用されるようにすることで行
われる。
【００８８】 Ｌ３パケットの判別は、Ｌ１／Ｌ２のそれぞれの側の制御装置又は制御プロセ
ス１１によって行われ、制御装置等は判別結果に従ってアダプタ又はアダプタプ
ロセス１２を制御する。制御プロセス１１は、パケット毎のＱｏＳ要求および／
または特性を読んで、対応するＬ１／Ｌ２動作モードおよび／またはネットワー
クの特性にマップする。適用プロセス１２はＬ１／Ｌ２の動作モードをパケット
毎に適合させることができ、この決定を少なくとも一部は制御装置から提供され
た情報に基づいて行う。典型的な場合には、Ｌ１／Ｌ２動作モードの適用はＬ１
／Ｌ２の下に存在する媒体の測定状況に基づいて行われる。
ス１１によって行われ、制御装置等は判別結果に従ってアダプタ又はアダプタプ
ロセス１２を制御する。制御プロセス１１は、パケット毎のＱｏＳ要求および／
または特性を読んで、対応するＬ１／Ｌ２動作モードおよび／またはネットワー
クの特性にマップする。適用プロセス１２はＬ１／Ｌ２の動作モードをパケット
毎に適合させることができ、この決定を少なくとも一部は制御装置から提供され
た情報に基づいて行う。典型的な場合には、Ｌ１／Ｌ２動作モードの適用はＬ１
／Ｌ２の下に存在する媒体の測定状況に基づいて行われる。
【００８９】 結果的に、本発明は動的に適応する、パケット毎に対応可能で、フロー／パケ
ットのＱｏＳ要求と／または特性にアクセス可能な制御プロセスを有し、これら
をそれぞれ提供プロセスおよび／またはＬ１／Ｌ２スケジューラを制御するため
に使用することができるＬ１／Ｌ２を有することになる。
ットのＱｏＳ要求と／または特性にアクセス可能な制御プロセスを有し、これら
をそれぞれ提供プロセスおよび／またはＬ１／Ｌ２スケジューラを制御するため
に使用することができるＬ１／Ｌ２を有することになる。
【００９０】 例として、Ｌ１／Ｌ２のＴＣＰへの最適適用は、Ｉ−モードまたはそれ以外の
通信スキーム、例えばスループットを最も高くするように最適化するにはＦＥＣ
、においてＡＲＱ−に基づく誤り回復を使用する。（ＴＣＰフローであることを
示す)プロトコルＩＤフィールドを読み取ることで制御装置は、例えば移動端末
ＴＣＰのフローであるというような妥当な判断をすることができる。実時間ＩＰ
上の音声通信フロー（セッションの開始プロトコルを有しない無線放送)につい
ての最適適用は、ＡＲＱに基づく誤り回復（ＵＩモード)もそれ以外の通信スキ
ームも有さない、つまり、ＦＥＣはソース送信率と残存誤りが最も小さくなるよ
うに最適化される。パケットヘッダのＤＳフィールドを読み取ることで、制御装
置は、移動端末実時間ＩＰ上の音声フローに最適な判断をすることができる。
通信スキーム、例えばスループットを最も高くするように最適化するにはＦＥＣ
、においてＡＲＱ−に基づく誤り回復を使用する。（ＴＣＰフローであることを
示す)プロトコルＩＤフィールドを読み取ることで制御装置は、例えば移動端末
ＴＣＰのフローであるというような妥当な判断をすることができる。実時間ＩＰ
上の音声通信フロー（セッションの開始プロトコルを有しない無線放送)につい
ての最適適用は、ＡＲＱに基づく誤り回復（ＵＩモード)もそれ以外の通信スキ
ームも有さない、つまり、ＦＥＣはソース送信率と残存誤りが最も小さくなるよ
うに最適化される。パケットヘッダのＤＳフィールドを読み取ることで、制御装
置は、移動端末実時間ＩＰ上の音声フローに最適な判断をすることができる。
【００９１】 上述の実施例は既知のＬ１／Ｌ２プロトコルの実行が有する問題を解決するこ
とができる。現在のネットワーク（無線ネットワーク)におけるＬ１／Ｌ２は、
それぞれが異なるＱｏＳ要求をもつ可能性がある別のフローを同時に送信しなけ
ればならない。しかし、現在のネットワーク上のＬ１／Ｌ２はそれぞれのフロー
が有するＱｏＳ要求を完全に満足させるレベルにまで降りることはできず、また
フローのそれぞれのパケットが有するＱｏＳ要求を満足させるようにさらに一段
下の層まで降りることもできない。後者は、ＱｏＳ要求が時間と共に変化して同
一のフローのパケットのＱｏＳが異なる場合に必要になる。代わりに、現在のネ
ットワークは最大限１つ以上のベアラを同時にサポートすることができる。しか
し、フローの方法はこのベアラにマップされておりこれらのフローのＱｏＳ要求
に直接関連付けられているわけではなく、パケット毎のネットワークオペレータ
チャージ特性のような基準に基づいている（ＧＰＲＳ通信システムで行われてい
るように)。その結果問題になるのは、フロー／パケットのいくつかについては
ＱｏＳ要求が満たされないか、いくつかのフロー／パケットについてはＱｏＳ要
求が満たされはするが最適な方法では満たされない（ＴＣＰウィンドウフローの
ために選択されたＦＥＣスキームが、最適なＦＥＣスキームが提供する下位ビッ
トレートに比較して強すぎる)というものであるか、フロー／パケットのＱｏＳ
要求が過剰に満たされてネットワーク資源が無駄になるというものである。
とができる。現在のネットワーク（無線ネットワーク)におけるＬ１／Ｌ２は、
それぞれが異なるＱｏＳ要求をもつ可能性がある別のフローを同時に送信しなけ
ればならない。しかし、現在のネットワーク上のＬ１／Ｌ２はそれぞれのフロー
が有するＱｏＳ要求を完全に満足させるレベルにまで降りることはできず、また
フローのそれぞれのパケットが有するＱｏＳ要求を満足させるようにさらに一段
下の層まで降りることもできない。後者は、ＱｏＳ要求が時間と共に変化して同
一のフローのパケットのＱｏＳが異なる場合に必要になる。代わりに、現在のネ
ットワークは最大限１つ以上のベアラを同時にサポートすることができる。しか
し、フローの方法はこのベアラにマップされておりこれらのフローのＱｏＳ要求
に直接関連付けられているわけではなく、パケット毎のネットワークオペレータ
チャージ特性のような基準に基づいている（ＧＰＲＳ通信システムで行われてい
るように)。その結果問題になるのは、フロー／パケットのいくつかについては
ＱｏＳ要求が満たされないか、いくつかのフロー／パケットについてはＱｏＳ要
求が満たされはするが最適な方法では満たされない（ＴＣＰウィンドウフローの
ために選択されたＦＥＣスキームが、最適なＦＥＣスキームが提供する下位ビッ
トレートに比較して強すぎる)というものであるか、フロー／パケットのＱｏＳ
要求が過剰に満たされてネットワーク資源が無駄になるというものである。
【００９２】 Ｌ１／Ｌ２のフローのＱｏＳ要求に対する適用は、優先権に基づくトラヒック
の計画概念とは独立である。例えば、実時間音声ストリームは、最大努力又はあ
る種の予測的ＱｏＳトラヒッククラスとされているか否かとは無関係に特定のＱ
ｏＳ要求をもつことができる。
の計画概念とは独立である。例えば、実時間音声ストリームは、最大努力又はあ
る種の予測的ＱｏＳトラヒッククラスとされているか否かとは無関係に特定のＱ
ｏＳ要求をもつことができる。
【００９３】 この実施例は、Ｌ１／Ｌ２をそれぞれのフロー又はパケット毎のＱｏＳに対し
て動的に適合させることによってこの問題を解決する。本方法は以下に示した機
能とそれらを実現する内部構造を有する： −機能１：ここのフロー／パケットのＱｏＳ要求が排他的に特定されて、当該ス
キームをサポートするいずれのネットワークにおいてもセマンテックが同じにな
るような標準スキーム； −機能２：Ｌ１／Ｌ２を制御プロセスから供給された動作モードに従って適応さ
せる適応プロセス。動作モードはローカルなつまり、当該Ｌ１／Ｌ２のネットワ
ークに固有のＱｏＳに対してのみ意味を有する形で、明示的にあるいは暗示的に
提供されても良い。適応プロセスは、制御プロセスから提供された動作モードと
Ｌ１／Ｌ２の下層に位置する当該媒体（無線)の条件に関する測定情報を組み合
わせて最終的に動作モードを決定することができる。これはしかし実行に関する
詳細に過ぎない。 −機能３：制御チャネルにアクセスを有して、フロー／パケット毎のＱｏＳ要求
が与えられたときにフロー／パケット毎に適合プロセスを制御することができる
制御プロセス；および、 −機能４：フロー／パケット毎のＱｏＳ要求が制御プロセスにとって利用できる
ようにする制御チャネル。
て動的に適合させることによってこの問題を解決する。本方法は以下に示した機
能とそれらを実現する内部構造を有する： −機能１：ここのフロー／パケットのＱｏＳ要求が排他的に特定されて、当該ス
キームをサポートするいずれのネットワークにおいてもセマンテックが同じにな
るような標準スキーム； −機能２：Ｌ１／Ｌ２を制御プロセスから供給された動作モードに従って適応さ
せる適応プロセス。動作モードはローカルなつまり、当該Ｌ１／Ｌ２のネットワ
ークに固有のＱｏＳに対してのみ意味を有する形で、明示的にあるいは暗示的に
提供されても良い。適応プロセスは、制御プロセスから提供された動作モードと
Ｌ１／Ｌ２の下層に位置する当該媒体（無線)の条件に関する測定情報を組み合
わせて最終的に動作モードを決定することができる。これはしかし実行に関する
詳細に過ぎない。 −機能３：制御チャネルにアクセスを有して、フロー／パケット毎のＱｏＳ要求
が与えられたときにフロー／パケット毎に適合プロセスを制御することができる
制御プロセス；および、 −機能４：フロー／パケット毎のＱｏＳ要求が制御プロセスにとって利用できる
ようにする制御チャネル。
【００９４】 適応と制御プロセスはそれぞれ分散プロセスである可能性があり、Ｌ１／Ｌ２
通信スキーム毎に１プロセスか、全てのＬ１／Ｌ２通信スキーム全てに対する単
一の適応／制御プロセスである。これもまた実行に関する詳細に過ぎない。上述
の機能は、パケット毎に又は少なくともパケットシーケンスに対するものである
ことが必要である。つまり、ＦＥＣを一つのパケットから別のものに対して又は
少なくとも１つのパケットシーケンスから別のパケットシーケンスに対して代え
る事は可能である。
通信スキーム毎に１プロセスか、全てのＬ１／Ｌ２通信スキーム全てに対する単
一の適応／制御プロセスである。これもまた実行に関する詳細に過ぎない。上述
の機能は、パケット毎に又は少なくともパケットシーケンスに対するものである
ことが必要である。つまり、ＦＥＣを一つのパケットから別のものに対して又は
少なくとも１つのパケットシーケンスから別のパケットシーケンスに対して代え
る事は可能である。
【００９５】 ＲｆＣ２４７５の現状から知られていることに関しては、ＲｆＣはＬ１／Ｌ２
を動的に適応させることをいささかも示唆するものではないことに留意されたい
。先行技術からはＬ１／Ｌ２をここのパケット／フローのＱｏＳに対して適応さ
せることはまったく知られておらず（機能２)、機能を有する制御プロセスを用
いることは知られていない。
を動的に適応させることをいささかも示唆するものではないことに留意されたい
。先行技術からはＬ１／Ｌ２をここのパケット／フローのＱｏＳに対して適応さ
せることはまったく知られておらず（機能２)、機能を有する制御プロセスを用
いることは知られていない。
【００９６】 従来技術に属するネットワークの例としてＧＳＭ−ＣＳＤまたはＧＰＲＳ通信
システムを使用して、いずれのネットワークもフロー／パケット適応をサポート
する機能を有していないことをいろいろなシナリオによって示すことができる。
システムを使用して、いずれのネットワークもフロー／パケット適応をサポート
する機能を有していないことをいろいろなシナリオによって示すことができる。
【００９７】 例えば、図１０にし示した、ピアＡ．１、Ｂ．１、Ａ．２およびＢ．２を有す
る構成（本発明の特徴は有していないとする）を考えると、ＧＳＭ−ＣＳＤとＧ
ＰＲＳのＬ１／Ｌ２に物理的には（つまり、Ａ．１とＢ．１)近い従来型のネッ
トワークは、当該ピアにおいて明示的に知られたＱｏＳにしたがってＬ１／Ｌ２
を適応させる直接的制御チャネル（あるいはそのために動くプロセス)を有する
。例えば、ピアＡ．１とＢ．１はＡＴコマンド解釈装置に対してアクセスするこ
とができ、それを通じて信頼性のあるリンクレイヤプロトコル(ＲＬＰ)を動かす
か否かを決定することができる。しかし、一方、Ａ．２とＢ．２はそれらが始ま
ったときのＴＣＰフローに対するＬ１／Ｌ２と異なるＬ１／Ｌ２に対して適応す
ることはできない。ピアＡ．２とＢ．２に関しては適応を行わせることのできる
制御プロセス(機能３）も存在しない。
る構成（本発明の特徴は有していないとする）を考えると、ＧＳＭ−ＣＳＤとＧ
ＰＲＳのＬ１／Ｌ２に物理的には（つまり、Ａ．１とＢ．１)近い従来型のネッ
トワークは、当該ピアにおいて明示的に知られたＱｏＳにしたがってＬ１／Ｌ２
を適応させる直接的制御チャネル（あるいはそのために動くプロセス)を有する
。例えば、ピアＡ．１とＢ．１はＡＴコマンド解釈装置に対してアクセスするこ
とができ、それを通じて信頼性のあるリンクレイヤプロトコル(ＲＬＰ)を動かす
か否かを決定することができる。しかし、一方、Ａ．２とＢ．２はそれらが始ま
ったときのＴＣＰフローに対するＬ１／Ｌ２と異なるＬ１／Ｌ２に対して適応す
ることはできない。ピアＡ．２とＢ．２に関しては適応を行わせることのできる
制御プロセス(機能３）も存在しない。
【００９８】 ＧＳＭ−ＣＳＤは異なるＱｏＳ要求を有する複数のフローを同時に送信しなけ
ればならないにもかかわらず、回路の起動コールにおいては固定されたモード（
ＦＥＣスキームとＩモード誤り回復)で動作することができるだけである。
ればならないにもかかわらず、回路の起動コールにおいては固定されたモード（
ＦＥＣスキームとＩモード誤り回復)で動作することができるだけである。
【００９９】 本発明を具体的な実施例に基づいて記載したが、実施例は説明の明確さと完全
な説明のために記載したに過ぎず発明は添付のクレームによって解釈されるもの
なので、実施例の記載によって日本発明がこれらの実施例に限定されるものと解
釈してはならない。請求の範囲に記載された符号は、請求項の理解を助けるため
につけたもので、請求項の範囲をこれらに限定する意味のものではない。
な説明のために記載したに過ぎず発明は添付のクレームによって解釈されるもの
なので、実施例の記載によって日本発明がこれらの実施例に限定されるものと解
釈してはならない。請求の範囲に記載された符号は、請求項の理解を助けるため
につけたもので、請求項の範囲をこれらに限定する意味のものではない。
【図１】 本発明に基づく通信装置を示す概念図である。
【図２】 本発明に基づく方法の実施例を示すフローチャートである。
【図３】 ＴＣＰ／ＩＰを例にとってプロトコルの階層構造を示した概念図
である。
である。
【図４】 図３に示したレイヤの中をパケットが流れる状態を示した概念図
である。
である。
【図５】 図３と図４の次のプロトコルレイヤにおけるカプセル化の概念を
示した概念図である。
示した概念図である。
【図６】 回路切り替えＧＳＭリンクを介して２つのＩＰホストの間の接続
とこれに対応するプロトコルの階層構造を例示した概念図である。
とこれに対応するプロトコルの階層構造を例示した概念図である。
【図７】 ＨＤＬＣフレームの基本構造を示すものである。
【図８】 本発明に基づく好ましい実施例のブロック図である。
【図９】 本発明に基づく好ましい方法の実施例を示すフローチャートであ
る。
る。
【図１０】 本発明の別の好ましい実施例を説明する図である。
【手続補正書】
【提出日】平成１３年１月１７日（２００１．１．１７）
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正内容】
【特許請求の範囲】
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００２５
【補正方法】変更
【補正内容】
【００２５】 ブレーク他によるコメント募集(ＲｆＣ)２４７５、１９９８年１２月により（
http://www.ietf.org/html.charters/diffserv-charger.html)、異なるサービス
のためのアーキテクチャーが知られている。ＲｆＣ２４７５はパスに存在するノ
ードにおける特定のホップごとの前進挙動(ＰＨＢ)を受け取ることができるよう
にパケットをクラス分類して指標をつけることを提案している。所定のプロトコ
ルレイヤに属するパケットのヘッダのヘッダ情報はそのプロトコルレイヤの操作
にのみ使用されるものである。区別されたサービスアーキテクチャは、ネットワ
ークに入ってくるトラヒックをネットワークの境界においてクラス分けして場合
によっては条件付けを行い、異なる挙動の集合に対応付けるモデルに基づくもの
である。それぞれの挙動の集合は単一の区別されたサービス(ＤＳ)コードポイン
トによって区別される。トラヒックストリーム中のパケットをパケットヘッダ中
の一部に含まれる内容に基づいて選別するパケット分類機能が記述されている。
すでに述べたように、ＩＰレイヤに属するＤＳコードポイントやＤＳフィールド
は、そのＩＰレイヤにおいてのみ使用される。ＤＳコードポイントのみに基づい
てパケットを分類する挙動集合分類手段が記載されている。同様に、１つ以上の
ヘッダフィールドの組み合わせからなる値によってパケットを分類する多フィー
ルド分類手段が記載されている。 国際公開公報ＷＯ９５ ３１０６０Ａは、メッセージの種類に基づいてデータ
パケットを伝送する方法を開示するものである。データは情報源から端末まで伝
送されるに際して、ネットワークインターフェースは、送られるメッセージの種
類に基づいてパケットスイッチネットワークか回路スイッチネットワークかを選
択することができる。開示された方法の目的は、パケットスイッチネットワーク
か回路スイッチネットワークのいずれかを通じて、最適パスを使用するようデー
タを適切にルーティングすることである。例えば、電子メールのような短いメッ
セージはパケットスイッチネットワークを通じて送る必要があるのに対して、フ
ァイル転送のような長いメッセージは回路スイッチネットワークを通じて送る必
要がある。
http://www.ietf.org/html.charters/diffserv-charger.html)、異なるサービス
のためのアーキテクチャーが知られている。ＲｆＣ２４７５はパスに存在するノ
ードにおける特定のホップごとの前進挙動(ＰＨＢ)を受け取ることができるよう
にパケットをクラス分類して指標をつけることを提案している。所定のプロトコ
ルレイヤに属するパケットのヘッダのヘッダ情報はそのプロトコルレイヤの操作
にのみ使用されるものである。区別されたサービスアーキテクチャは、ネットワ
ークに入ってくるトラヒックをネットワークの境界においてクラス分けして場合
によっては条件付けを行い、異なる挙動の集合に対応付けるモデルに基づくもの
である。それぞれの挙動の集合は単一の区別されたサービス(ＤＳ)コードポイン
トによって区別される。トラヒックストリーム中のパケットをパケットヘッダ中
の一部に含まれる内容に基づいて選別するパケット分類機能が記述されている。
すでに述べたように、ＩＰレイヤに属するＤＳコードポイントやＤＳフィールド
は、そのＩＰレイヤにおいてのみ使用される。ＤＳコードポイントのみに基づい
てパケットを分類する挙動集合分類手段が記載されている。同様に、１つ以上の
ヘッダフィールドの組み合わせからなる値によってパケットを分類する多フィー
ルド分類手段が記載されている。 国際公開公報ＷＯ９５ ３１０６０Ａは、メッセージの種類に基づいてデータ
パケットを伝送する方法を開示するものである。データは情報源から端末まで伝
送されるに際して、ネットワークインターフェースは、送られるメッセージの種
類に基づいてパケットスイッチネットワークか回路スイッチネットワークかを選
択することができる。開示された方法の目的は、パケットスイッチネットワーク
か回路スイッチネットワークのいずれかを通じて、最適パスを使用するようデー
タを適切にルーティングすることである。例えば、電子メールのような短いメッ
セージはパケットスイッチネットワークを通じて送る必要があるのに対して、フ
ァイル転送のような長いメッセージは回路スイッチネットワークを通じて送る必
要がある。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，Ｚ Ｗ (72)発明者 ラソニー， ベラ スウェーデン国 エス−214 40 マルモ， キヴィクスグ． ８シー Ｆターム(参考） 5K014 AA02 BA05 DA01 EA01 5K030 GA11 HA08 JA05 KA01 KA06 KA13 KX13 LA01 LD11 MB18 5K034 AA05 BB06 DD03 FF01 HH01 HH02 HH06 HH63 MM01
Claims (54)
- 【請求項１】 予め設定された第１のプロトコルによって決定される第１の
データ構造を有するデータパケットを作成する通信装置であって、予め設定され
た第２のプロトコルによって決定される第２のデータ構造を有するデータパケッ
トを受け取り該第２の構造を有する各データパケットを１つ以上の該第１の構造
を有するデータパケットに埋め込む通信装置であって、さらに、該第２の構造を
有するデータパケットを当該第２の構造を有するデータパケットの内容に基づき
、予め設定された規則に従って判別する判別手段(１)を具備するデータパケット
を作成する通信装置。 - 【請求項２】 前記予め設定された第１のプロトコルは、データパケットの
送信に関して、データパケットの再送信規則に関して区別することができる少な
くとも２つの送信信頼性モードをサポートし、作成された各データパケットは、
データパケットの受信手段が当該データパケットがどの通信信頼性モードで送信
されたかを決定できるように、当該データパケットが送信されるべき通信信頼性
モードに関する情報を有しており、通信信頼性モードに関する情報は当該データ
パケットを送信するに先立って前記通信装置によって各々のデータパケットに挿
入されたものであり、さらに、 前記判別手段(１)は前記第２の構造を有するデータパケットを前記予め定めら
れた規則に従って判別するように構成されており、前記第２の構造を有する前記
所定のデータパケットを含む１つ以上の前記第１の構造を有するデータパケット
の通信信頼性モードに関する情報を判別結果に基づいて設定することを特徴とす
る請求項１に記載の通信装置。 - 【請求項３】 前記第１のプロトコルは２つの通信信頼性モード、すなわち
、所定の条件でデータパケットを再送信する規則を含む第１のモードと、データ
パケットの再送信を行わない第２のモードをサポートすることを特徴とする請求
項２に記載の通信装置。 - 【請求項４】 前記通信装置は、前記第１の構造を有するデータパケットの
中の前記第２の構造を有するデータパケットを分割するように構成されているこ
とを特徴とする請求項１、２又は３のいずれかに記載の通信装置。 - 【請求項５】 前記通信装置は、前記第１の構造を有するデータパケットの
中に前記第２の構造を有するデータパケットを封じ込めるように構成されている
ことを特徴とする請求項１、２又は３のいずれかに記載の通信装置。 - 【請求項６】 前記第１の構造を有するデータパケットが出力バッファ(５)
に渡され、パケットは出力バッファから送り出されることを特徴とする請求項１
ないし５のいずれかに記載の通信装置。 - 【請求項７】 前記第１の構造を有するデータパケットが渡され、そこから
出力されるバッファ(５)は、前記第１の構造を有する各データパケットを、各々
のパケットに対して設定された通信信頼性モード別のキューに入れることを特徴
とする請求項２に記載の通信装置。 - 【請求項８】 前記第１のプロトコルは２つの通信信頼性モード、すなわち
、所定の条件でデータパケットの再送信を行う規則を含む第１のモードと、デー
タパケットの再送信を行わない第２のモードとをサポートし、前記出力バッファ
(５)は、再送信すべき第１モードのデータパケットを他のデータパケットよりも
高い優先度で再送信することを特徴とする請求項７に記載の通信装置。 - 【請求項９】 前記第２の構造を有するデータパケットはパケットの内容に
関する情報を含む１つ以上のセクションを有しており、前記判別手段(１)は、当
該１つ以上のセクションを分析してこれに基づいてその内容によって前記第２の
構造を有するデータパケットを判別することを特徴とする請求項１ないし８のい
ずれかに記載の通信装置。 - 【請求項１０】 前記１つ以上のセクションは対応するプロトコルレイヤの
パケットヘッダであり、パケットの内容が関連するプロトコルを識別するための
プロトコル識別情報を含むことを特徴とする請求項９に記載の通信装置。 - 【請求項１１】 前記第２の構造を有するデータパケットはパケットの内容
に関する情報を含むセクションを１つ以上含んでおり、前記判別手段(１)は、当
該１つ以上のセクションを分析して第２の構造を有するデータパケットをその内
容に従って判別し、前記１つ以上のセクションは対応するプロトコルレイヤのパ
ケットヘッダであってパケットの内容が関連するプロトコルを識別するプロトコ
ル識別情報を含んでおり、前記パケットヘッダはプロトコルレイヤに従って階層
構造を有しており、判別すべきパケットに関して判別手段(１)は、 前記第２のプロトコルに関連するヘッダの中のプロトコル識別を行って、次に
該プロトコル識別子を、予め設定されたプロトコル識別子と予め設定された通信
信頼性モードとを対応させる規則に照らし合わせ、 判別すべきパケットの通信信頼性モードを、もし該プロトコル識別子が記憶さ
れた規則の中にあれば予め設定された規則に従って通信信頼性モードを設定し、
該プロトコル識別子が記憶された規則の中に無ければ、階層構造において１層分
上位の層にあるプロトコルのヘッダに有るプロトコル識別子を識別して、当該次
のプロトコルのプロトコル識別子を予め設定された通信信頼性モードとの割り当
てを示す記憶された規則を照らし合わせ、 ここで上記の識別と比較ステップを、 判別すべきパケットの中の識別されたプロトコル識別子が規則のうち
の１つに従って予め設定された通信信頼性モードの１つに割り当てて、前記判別
すべきパケットの通信信頼性モードとして当該モードを設定するか、 フェールセーフ条件に該当して、前記判別すべきパケットに通信信頼
性モードのデフォルト値を設定するか、 いずれかが行われるまで繰り返すことを特徴とする請求項２に記載の通信装置。 - 【請求項１２】 前記第１のプロトコルは、前記第２の構造のパケットを、
前記第１の構造のパケットに埋め込むために分割することを特徴とする請求項３
に記載の通信装置。 - 【請求項１３】 前記第１のプロトコルはリンクを通じてパケットを送信す
るためのプロトコルであることを特徴とする請求項１ないし１２のいずれかに記
載の通信装置。 - 【請求項１４】 前記リンクは無線リンクであることを特徴とする請求項１
３に記載の通信装置。 - 【請求項１５】 前記通信装置は前記リンクを通じて前記第１の構造を有す
るデータパケットを受信することを特徴とする請求項１３または１４に記載の通
信装置。 - 【請求項１６】 前記第１のプロトコルはリンクを通じてパケットを送信す
るためのプロトコルであり、前記通信装置は当該リンクを通して前記第１の構造
を有するデータパケットを受信し、リンクを通じて前記第１の構造のデータパケ
ットを受信するために受信バッファ手段が設けられており、当該受信バッファ手
段は、前記第１の通信信頼性モードで送られたデータを記憶するための前記第１
の送信信頼性モード用の第１の部分と、前記第２の通信信頼性モードで送られた
データパケットを記憶するための第２の通信信頼性モード用の第２の部分とを有
することを特徴とする請求項１２に記載の通信装置。 - 【請求項１７】 前記第１のデータ構造の受信したパケットの中の前記第２
のデータ構造を有するパケットに含まれるパケットデリミタを検出し、前記受信
バッファが前記第１のデータ構造を有する受信パケットを、 前記第２の構造を有するデータ構造のパケットが完全に受信され、前記第２の
データ構造を有するパケットに含まれるパケットデリミタが受信されることによ
って確認されるか、 前記第２の通信信頼性モードに属する前記第１のデータ構造に関して予め設定
されていたバッファの限界を超えたこと、のうちのいずれか一つが起こるまで記
憶することを特徴とする請求項１６に記載の通信装置。 - 【請求項１８】 埋め込まれるべき前記第２のデータ構造を有するパケット
に含まれる前記第２のデータ構造を有するパケットに属するパケットデリミタを
検出して埋め込みを行う前にそのパケットデリミタを複製することを特徴とする
請求項１２に記載の通信装置。 - 【請求項１９】 前記第１の通信信頼性モードは、前記第１の通信信頼性モ
ードのパケットは正しい順序を特定するために付番されており、 前記通信装置は、前記第１の通信信頼性モードに属する第１のデータ構造を有
する受信パケットの中の前記第２のデータ構造を有するパケットに含まれるパケ
ットデリミタを検出し、 前記受信バッファは、第１の通信信頼性モードであれ第２の通信信頼性モード
であれ、第１のデータ構造を有する受信したパケットを、即座に直ぐ上の階層に
当るレイヤに、 ‐前記第１の通信信頼性モードに属するパケットを再送信しなければならず、
第１の通信信頼性モードに属する受信パケットが正しい順序で送り出すことがで
きるまでバッファに記憶されているとき、 ‐あるいは、前記第１の通信信頼性モードに属するパケットに、第２の通信信
頼性モードのパケットが続いており、前記受信バッファが、第１の通信信頼性モ
ードのパケットが全く記憶されていなければ、第２の通信信頼性モードに属する
受信された第１のデータ構造を有するパケットを即座に送り出し、第１の通信信
頼性モードに属するパケットが記憶されていれば第２の通信信頼性モードに属す
る第１のデータ構造を有する受信パケットを、第２のデータ構造を有する第１の
通信信頼性モードのパケットが完全に受信されて送り出されるまで記憶し、その
後に第２の通信信頼性モードに属する第１のデータ構造を有する記憶されていた
パケットを送り出すように構成されていることを特徴とする請求項１６に記載の
通信装置。 - 【請求項２０】 前記予め設定されたパケットデリミタが前記のリンクを通
じて受信されたメッセージによって特定されていることを特徴とする請求項１７
ないし１９のうちのいずれかに記載の通信装置。 - 【請求項２１】 前記第１のプロトコルはリンクを通じてパケットを送信す
るプロトコルであり、 前記第１の通信信頼性モードに属するパケットの通信を、既にリンクを通じて
送信したパケットの受信確認が得られた後に決定し、 出力バッファ手段は、既に送信した第１の通信信頼性モードに属するパケット
の全ての受信確認が得られた後に、第２の信頼性モードに属するパケットの送信
を行うことを特徴とする請求項１２に記載の通信装置。 - 【請求項２２】 前記第１の予め設定されたプロトコルは、データパケット
を送信する動作モードを少なくとも２つサポートし、前記判別手段(１)は制御手
段(１１)を具備してこの制御手段(１１)が第２の構造を有するデータパケットを
その内容に基づいて判別して判別結果に基づいて動作モードに対応付けて判別結
果に基づいて適応制御データを作成し、前記適応手段(１２)は適応制御データに
従って前記少なくとも２つの動作モードのうちの１つを選択することを特徴とす
る請求項１に記載された通信手段。 - 【請求項２３】 前記適応手段(１２)は、さらに前記適応制御データに応じ
て少なくとも２つの動作モードのうちの１つを選択する際に、前記第１の構造を
有するデータパケットが送られるリンクと関連したデータを考慮するように構成
されたことを特徴とする請求項２２に記載の通信装置。 - 【請求項２４】 前記制御手段(１１)は、前記第２の構造を有するデータパ
ケットのヘッダにある所定のフィールドの内容に基づいて前記第２の構造を有す
るデータパケットを判別することを特徴とする請求項２２または２３に記載の通
信装置。 - 【請求項２５】 前記所定のフィールドは第２の構造を有するデータパケッ
トの一部に通信品質要求を含むことを特徴とする請求項２４に記載の通信装置。 - 【請求項２６】 前記動作モードは、自動繰り返し要求誤り復元およびフォ
ワードエラー修正のうちの少なくとも一方を採用していることを特徴とする請求
項２２から２５のうちのいずれかに記載の通信装置。 - 【請求項２７】 前記フォワードエラー修正は、フレームチェックシーケン
スに基づく誤り検出、フォワードエラー制御に基づく誤り修正、インターリーブ
に基づく誤り防止、パワー制御、拡散に基づく誤り防止、フレーム長制御及びバ
ンド幅保存制御の内の少なくとも１つであることを特徴とする請求項２６に記載
の通信装置。 - 【請求項２８】 予め設定された第１のプロトコルに従って第１の構造を有
するデータパケットを作成する方法であって、 −第２の構造を有するデータパケットの内容に基づいて、予め設定された規則に
従って予め設定された第２のプロトコルに基づく第２の構造を有する受信データ
パケットを判別（Ｓ２)し、 −第１の構造を有するデータパケットに第２の構造を有するデータパケットを埋
め込む(Ｓ３)ことを含む方法。 - 【請求項２９】 前記予め設定された第１のプロトコルはデータパケットを
送信する通信信頼性モードを少なくとも２つサポートし、通信信頼性モードは少
なくともデータパケットの再送信規則に関して区別することができ、作成した各
データパケットはデータパケットの受信側が当該データパケットが送信された通
信信頼性モードを特定できるように当該それぞれのデータパケットを送る際の通
信信頼性モードに関する情報を含み、第２の構造を有するデータパケットを含む
第１の構造を有するデータパケットの通信信頼性モードに関する情報は、第２の
構造を有するデータパケットに関する判別結果によって設定されることを特徴と
する請求項２８に記載のデータパケットの作成方法。 - 【請求項３０】 前記第１のプロトコルは２つの通信信頼性モード、つまり
、特定の条件の下でデータパケットの再送信を定める第１のモードと、データパ
ケットの再送信を行わない第２のモードをサポートする請求項２９に記載の方法
。 - 【請求項３１】 前記第２の構造を有するデータパケットは前記第１の構造
を有するデータパケットに封じ込められていることを特徴とする請求項２８、２
９または３０のうちのいずれかに記載の方法。 - 【請求項３２】 前記第２の構造を有するデータパケットは前記第１の構造
を有するパケットに分割されることを特徴とする請求項２８、２９または３０の
うちのいずれかに記載の方法。 - 【請求項３３】 前記第１の構造を有するデータパケットが出力バッファ(
５)に渡されることを特徴とする請求項２８ないし３２の内のいずれかに記載の
方法。 - 【請求項３４】 前記第１の構造を有するデータパケットが出力バッファ(
５)に渡され、出力バッファ(５)は第１の構造を有するデータパケットを当該パ
ケットごとに設定された通信信頼性モードに対応するキューに書き込むことを特
徴とする請求項２９に記載の方法。 - 【請求項３５】 前記第１のプロトコルは２つの通信信頼性モード、特定の
条件においてデータパケットの再送信を規定する第１のモードと、データパケッ
トの再送信を行わない第２のモードをサポートし、前記出力バッファ(５)は、他
のデータパケットよりも高い優先順位で第１のモードのデータパケットを再送信
することを特徴とする請求項３４に記載の方法。 - 【請求項３６】 前記第２の構造を有するデータパケットが、パケットの内
容に関する情報を有する１つ以上のセクションを含み、前記判別ステップ(Ｓ２)
が当該１つ以上のセクションを分析してこれによってその内容に従って前記第２
の構造を有するデータパケットを判別することを特徴とする請求項２８に記載の
方法。 - 【請求項３７】 前記１つ以上のセクションは対応するプロトコルレイヤの
パケットヘッダであってパケットの内容が関連付けられるプロトコルを識別する
プロトコル識別情報を含むことを特徴とする請求項３６に記載の方法。 - 【請求項３８】 前記第２の構造を有するデータパケットはパケットの内容
に関する情報を含む１つ以上のセクションを有し、前記判別ステップ(Ｓ２)はこ
の１つ以上のセクションを分析してこれに基づいてその内容に従って第２の構造
を有するデータパケットを判別し、 前記１つ以上のセクションは、対応するプロトコルのパケットヘッダであり、
パケットの内容と関連付けられたプロトコルを識別するプロトコル識別情報を含
み、 前記パケットヘッダはプロトコルの層によって階層化構造を有し、判別すべき
パケットに関して前記判別ステップ(Ｓ２)は、 −前記第２のプロトコルに関連するヘッダの中のプロトコル識別を行って、次に
該プロトコル識別子を、予め設定されたプロトコル識別子と予め設定された通信
信頼性モードとを対応させる規則に照らし合わせ、 −判別すべきパケットの通信信頼性モードを、もし該プロトコル識別子が記憶さ
れた規則の中にあれば予め設定された規則に従って通信信頼性モードを設定し、
該プロトコル識別子が記憶された規則の中に無ければ、階層構造において１層分
上位の層にあるプロトコルのヘッダに有るプロトコル識別子を識別して、当該次
のプロトコルのプロトコル識別子を予め設定された通信信頼性モードとの割り当
てを示す記憶された規則を照らし合わせ、 ここで上記の識別と比較ステップを、 ――判別すべきパケットの中の識別されたプロトコル識別子が規則のうちの１
つに従って予め設定された通信信頼性モードの１つに割り当てて、前記判別すべ
きパケットの通信信頼性モードとして当該モードを設定するか、 ――フェールセーフ条件に該当して、前記判別すべきパケットに通信信頼性モ
ードのデフォルト値を設定するか、 いずれかが行われるまで繰り返すことを特徴とする請求項２９に記載の方法。 - 【請求項３９】前記第１のプロトコルは、前記第２の構造のパケットを、前
記第１の構造のパケットに埋め込むために分割することを特徴とする請求項３０
に記載の方法。 - 【請求項４０】 前記第１のプロトコルはリンクを通じてパケットを送信す
るためのプロトコルであることを特徴とする請求項２８ないし３９のいずれかに
記載の方法。 - 【請求項４１】 前記リンクは無線リンクであることを特徴とする請求項４
０に記載の方法。 - 【請求項４２】 前記通信装置は前記リンクを通じて前記第１の構造を有す
るデータパケットを受信することを特徴とする請求項４０または４１に記載の方
法。 - 【請求項４３】 前記第１のプロトコルはリンクを通じてパケットを送信す
るためのプロトコルであり、 前記通信装置は当該リンクを通して前記第１の構造を有するデータパケットを
受信し、 リンクを通じて前記第１の構造のデータパケットを受信するために受信バッフ
ァ手段を使用し、当該受信バッファ手段は、前記第１の通信信頼性モードで送ら
れたデータを記憶するための前記第１の送信信頼性モード用の第１の部分と、前
記第２の通信信頼性モードで送られたデータパケットを記憶するための第２の通
信信頼性モード用の第２の部分とを有することを特徴とする請求項３９に記載の
方法。 - 【請求項４４】 前記第１のデータ構造の受信したパケットの中の前記第２
のデータ構造を有するパケットに含まれるパケットデリミタを検出し、前記受信
バッファが前記第１のデータ構造を有する受信パケットを、 前記第２の構造を有するデータ構造のパケットが完全に受信され、前記第２の
データ構造を有するパケットに含まれるパケットデリミタが受信されることによ
って確認されるか、 前記第２の通信信頼性モードに属する前記第１のデータ構造に関して予め設定
されていたバッファの限界を超えたこと、のうちのいずれか一つが起こるまで記
憶することを特徴とする請求項４３に記載の方法。 - 【請求項４５】 埋め込まれるべき前記第２のデータ構造を有するパケット
に含まれる前記第２のデータ構造を有するパケットに属するパケットデリミタを
検出して埋め込みを行う前にそのパケットデリミタを複製することを特徴とする
請求項３９に記載の方法。 - 【請求項４６】 前記第１の通信信頼性モードは、前記第１の通信信頼性モ
ードのパケットは正しい順序を特定するために付番されており、 前記通信装置は、前記第１の通信信頼性モードに属する第１のデータ構造を有
する受信パケットの中の前記第２のデータ構造を有するパケットに含まれるパケ
ットデリミタを検出し、 前記受信バッファは、第１の通信信頼性モードであれ第２の通信信頼性モード
であれ、第１のデータ構造を有する受信したパケットを、即座に直ぐ上の階層に
当るレイヤに、 ‐前記第１の通信信頼性モードに属するパケットを再送信しなければならず、
第１の通信信頼性モードに属する受信パケットが正しい順序で送り出すことがで
きるまでバッファに記憶されているとき、 ‐あるいは、前記第１の通信信頼性モードに属するパケットに、第２の通信信
頼性モードのパケットが続いており、前記受信バッファが、第１の通信信頼性モ
ードのパケットが全く記憶されていなければ、第２の通信信頼性モードに属する
受信された第１のデータ構造を有するパケットを即座に送り出し、第１の通信信
頼性モードに属するパケットが記憶されていれば第２の通信信頼性モードに属す
る第１のデータ構造を有する受信パケットを、第２のデータ構造を有する第１の
通信信頼性モードのパケットが完全に受信されて送り出されるまで記憶し、その
後に第２の通信信頼性モードに属する第１のデータ構造を有する記憶されていた
パケットを送り出すように構成されていることを特徴とする請求項４３に記載の
方法。 - 【請求項４７】 前記予め設定されたパケットデリミタが前記のリンクを通
じて受信されたメッセージによって特定されていることを特徴とする請求項４４
ないし４６のうちのいずれかに記載の方法。 - 【請求項４８】 前記第１のプロトコルはリンクを通じてパケットを送信す
るプロトコルであり、 前記第１の通信信頼性モードに属するパケットの通信を、既にリンクを通じて
送信したパケットの受信確認が得られた後に決定し、 出力バッファ手段は、既に送信した第１の通信信頼性モードに属するパケット
の全ての受信確認が得られた後に、第２の信頼性モードに属するパケットの送信
を行うことを特徴とする請求項３９に記載の方法。 - 【請求項４９】 前記第１の予め設定されたプロトコルは、データパケット
を送信する動作モードを少なくとも２つサポートし、前記判別プロセスは制御プ
ロセスを含みこの制御プロセスが第２の構造を有するデータパケットをその内容
に基づいて判別して判別結果に基づいて動作モードに対応付けて判別結果に基づ
いて適応制御データを作成し、前記適応プロセスは適応制御データに従って前記
少なくとも２つの動作モードのうちの１つを選択することを特徴とする請求項２
８に記載された方法。 - 【請求項５０】 前記適応プロセスはさらに前記適応制御データに応じて少
なくとも２つの動作モードのうちの１つを選択する際に、前記第１の構造を有す
るデータパケットが送られるリンクと関連したデータを考慮するように構成され
たことを特徴とする請求項４９に記載の方法。 - 【請求項５１】 前記制御プロセスは、前記第２の構造を有するデータパケ
ットのヘッダにある所定のフィールドの内容に基づいて前記第２の構造を有する
データパケットを判別することを特徴とする請求項４９または５０に記載の方法
。 - 【請求項５２】 前記所定のフィールドは第２の構造を有するデータパケッ
トの一部に通信品質要求を含むことを特徴とする請求項５１に記載の方法。 - 【請求項５３】 前記動作モードは、自動繰り返し要求誤り復元およびフォ
ワードエラー修正のうちの少なくとも一方を採用していることを特徴とする請求
項４９から５２のうちのいずれかに記載の方法。 - 【請求項５４】 前記フォワードエラー修正は、フレームチェックシーケン
スに基づく誤り検出、フォワードエラー制御に基づく誤り修正、インターリーブ
に基づく誤り防止、パワー制御、拡散に基づく誤り防止、フレーム長制御及びバ
ンド幅保存制御の内の少なくとも１つであることを特徴とする請求項５１に記載
の方法。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP98113212A EP0973302A1 (en) | 1998-07-15 | 1998-07-15 | Device and method for reliable and low-delay packet transmission |
| EP98113212.9 | 1998-07-15 | ||
| EP99101121A EP0975123A1 (en) | 1998-07-15 | 1999-01-21 | Communication device and method for reliable and low-delay packet transmission |
| EP99101121.4 | 1999-01-21 | ||
| PCT/EP1999/004550 WO2000004680A1 (en) | 1998-07-15 | 1999-07-01 | Communication device and method for reliable and low-delay packet transmission |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002521866A true JP2002521866A (ja) | 2002-07-16 |
| JP4334770B2 JP4334770B2 (ja) | 2009-09-30 |
Family
ID=26149435
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000560694A Expired - Lifetime JP4334770B2 (ja) | 1998-07-15 | 1999-07-01 | 通信装置と信頼性が高く遅延が短いパケット通信方法 |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US6697352B1 (ja) |
| EP (2) | EP0975123A1 (ja) |
| JP (1) | JP4334770B2 (ja) |
| CN (1) | CN1188991C (ja) |
| AT (1) | ATE312461T1 (ja) |
| AU (1) | AU756050B2 (ja) |
| CA (1) | CA2337050C (ja) |
| DE (1) | DE69928812T2 (ja) |
| WO (1) | WO2000004680A1 (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002051082A (ja) * | 2000-05-24 | 2002-02-15 | Sony Internatl Europ Gmbh | 通信ネットワーク用の処理装置及びソフトウェア |
| JP2007502585A (ja) * | 2003-08-14 | 2007-02-08 | インフォーカス コーポレイション | データ技術領域を送信する装置、システムおよび方法 |
| JP2008295070A (ja) * | 2008-07-03 | 2008-12-04 | Ntt Docomo Inc | 適応無線パラメータ制御方法、ＱｏＳ制御装置、基地局及び無線通信システム |
| JP2012095087A (ja) * | 2010-10-27 | 2012-05-17 | Kyocera Corp | 通信装置および通信方法 |
Families Citing this family (95)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6389010B1 (en) * | 1995-10-05 | 2002-05-14 | Intermec Ip Corp. | Hierarchical data collection network supporting packetized voice communications among wireless terminals and telephones |
| EP1018821A1 (en) * | 1999-01-08 | 2000-07-12 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Communication device and method |
| JP3743194B2 (ja) * | 1999-02-25 | 2006-02-08 | 株式会社日立製作所 | パケット中継装置 |
| KR100308152B1 (ko) * | 1999-07-31 | 2001-09-29 | 서평원 | 단문 메시지 서비스를 위한 셀 브로드캐스팅 방법 |
| US7522631B1 (en) * | 1999-10-26 | 2009-04-21 | Qualcomm, Incorporated | Method and apparatus for efficient data transmission control in a wireless voice-over-data communication system |
| US7023820B2 (en) * | 2000-12-28 | 2006-04-04 | Nokia, Inc. | Method and apparatus for communicating data in a GPRS network based on a plurality of traffic classes |
| US6987777B1 (en) * | 1999-12-02 | 2006-01-17 | Nortel Networks Ltd | Priority forwarding in a communication system |
| DE19959160B4 (de) * | 1999-12-08 | 2005-06-16 | Siemens Ag | Verfahren zur paketorientierten Datenübermittlung in einem Funk-Kommunikationssystem, Basisstation und Teilnehmerstation |
| US6922548B1 (en) * | 2000-04-24 | 2005-07-26 | Microsoft Corporation | Providing remote network driver interface specification services over a wireless radio-frequency medium |
| KR100612003B1 (ko) * | 2000-02-26 | 2006-08-11 | 삼성전자주식회사 | 통신망에서 비트 스트림 송수신 장치 및 그 방법 |
| JP2001245268A (ja) * | 2000-02-29 | 2001-09-07 | Toshiba Corp | コンテンツ伝送システム及びコンテンツ処理装置 |
| JP2001251366A (ja) | 2000-03-07 | 2001-09-14 | Sony Corp | 通信装置及び通信方法 |
| JP4479040B2 (ja) * | 2000-03-07 | 2010-06-09 | ソニー株式会社 | 通信装置及び通信方法 |
| KR100667738B1 (ko) * | 2000-03-29 | 2007-01-11 | 삼성전자주식회사 | 무선 패킷 송수신 장치 및 그 방법 |
| US7200684B1 (en) * | 2000-04-13 | 2007-04-03 | International Business Machines Corporation | Network data packet classification and demultiplexing |
| KR100667739B1 (ko) * | 2000-06-09 | 2007-01-12 | 삼성전자주식회사 | 무선 데이터 송수신 장치 및 그 방법 |
| JP3525869B2 (ja) * | 2000-07-12 | 2004-05-10 | 日本電気株式会社 | パケット通信システムの接続装置及び方法 |
| US7151754B1 (en) * | 2000-09-22 | 2006-12-19 | Lucent Technologies Inc. | Complete user datagram protocol (CUDP) for wireless multimedia packet networks using improved packet level forward error correction (FEC) coding |
| US7031257B1 (en) * | 2000-09-22 | 2006-04-18 | Lucent Technologies Inc. | Radio link protocol (RLP)/point-to-point protocol (PPP) design that passes corrupted data and error location information among layers in a wireless data transmission protocol |
| US7039025B1 (en) * | 2000-09-29 | 2006-05-02 | Siemens Communications, Inc. | System and method for providing general packet radio services in a private wireless network |
| US6839327B1 (en) * | 2000-12-01 | 2005-01-04 | Cisco Technology, Inc. | Method and apparatus for maintaining consistent per-hop forwarding behavior in a network using network-wide per-hop behavior definitions |
| EP1358639A1 (en) * | 2001-02-08 | 2003-11-05 | Nokia Corporation | Smart card reader |
| US20030235206A1 (en) * | 2001-02-15 | 2003-12-25 | Tantivy Communications, Inc. | Dual proxy approach to TCP performance improvements over a wireless interface |
| US20020124095A1 (en) * | 2001-03-02 | 2002-09-05 | Sultan Israel Daniel | Apparatus and method for sending point-to-point protocol over ethernet |
| CN1809029B (zh) * | 2001-03-12 | 2012-01-11 | 高通股份有限公司 | 在无线分组数据服务连接中提供多重质量服务等级的方法和设备 |
| US7096261B2 (en) | 2001-03-12 | 2006-08-22 | Qualcomm Incorporated | Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection |
| US8370525B2 (en) * | 2001-03-30 | 2013-02-05 | Intel Corporation | Transmitting new data format under existing infrastructure |
| US20020142765A1 (en) * | 2001-03-30 | 2002-10-03 | Rhoads Monte J. | Network appliance wireless configuration interface |
| US7154909B2 (en) * | 2001-06-15 | 2006-12-26 | Nokia Corporation | Apparatus, and associated method, for facilitating maintenance of sensitivity level of data communicated in a packet communication system |
| WO2003013168A1 (en) * | 2001-07-29 | 2003-02-13 | Yuval Barkan | Cellular network system and method |
| FI113926B (fi) * | 2001-08-16 | 2004-06-30 | Teliasonera Finland Oyj | QOS-arvon monitoroiminen ja välittäminen tietoliikenneverkossa |
| DE10141092A1 (de) * | 2001-08-22 | 2003-03-06 | Siemens Ag | Verfahren zur Übertragung von Datenpaketen in einem Funk-Kommunikationssystem |
| EP1372310A1 (en) * | 2002-06-12 | 2003-12-17 | Motorola, Inc. | Apparatus and method for communicating data using header compression |
| US20050180464A1 (en) * | 2002-10-01 | 2005-08-18 | Adondo Corporation | Audio communication with a computer |
| US7472135B2 (en) * | 2002-10-18 | 2008-12-30 | Nokia Corporation | Method and system for recalling details regarding past events |
| US7525994B2 (en) * | 2003-01-30 | 2009-04-28 | Avaya Inc. | Packet data flow identification for multiplexing |
| US8036122B2 (en) * | 2003-04-03 | 2011-10-11 | Alcatel Lucent | Initiation of network treatment for data packet associated with real-time application different from network treatment applicable to data packet non-associated with the real-time application |
| US20040199622A1 (en) * | 2003-04-07 | 2004-10-07 | Huscher Anthony Alan | eRoom operations console |
| US7050397B2 (en) | 2003-07-02 | 2006-05-23 | Nokia Corporation | Apparatus, and associated method, for facilitating retransmission of data packets in a packet radio communication system that utilizes a feedback acknowledgement scheme |
| US7447203B2 (en) | 2003-07-29 | 2008-11-04 | At&T Intellectual Property I, L.P. | Broadband access for virtual private networks |
| JP4335619B2 (ja) * | 2003-09-04 | 2009-09-30 | 株式会社エヌ・ティ・ティ・ドコモ | パケット優先制御装置及びその方法 |
| US7450568B2 (en) * | 2003-12-05 | 2008-11-11 | Cisco Technology, Inc. | System and method for managing a VolP network |
| US7162092B2 (en) * | 2003-12-11 | 2007-01-09 | Infocus Corporation | System and method for processing image data |
| US7197026B2 (en) * | 2003-12-23 | 2007-03-27 | Nokia Corporation | Method and system for RLP optimization |
| US8520605B2 (en) * | 2004-01-06 | 2013-08-27 | Vasu Networks Corporation | Apparatus for controlling broadband access and distribution of content and communications through an access point |
| US10419996B2 (en) | 2004-01-06 | 2019-09-17 | Vasu Networks Corporation | Mobile device with automatic switching between cellular and wifi networks |
| EP1738538B1 (en) | 2004-01-06 | 2018-08-08 | Vasu Networks Corporation | Telephone with automatic switching between cellular and voip networks |
| US8913604B2 (en) | 2004-01-06 | 2014-12-16 | Vasu Networks Corporation | Access point with controller for billing and generating income for access point owner |
| US8078164B2 (en) * | 2004-01-06 | 2011-12-13 | Vasu Networks Corporation | Mobile telephone VOIP/cellular seamless roaming switching controller |
| US8514867B2 (en) | 2004-01-06 | 2013-08-20 | Hava Corporation | Method of determining broadband content usage within a system |
| US20050216625A1 (en) * | 2004-03-09 | 2005-09-29 | Smith Zachary S | Suppressing production of bus transactions by a virtual-bus interface |
| US7065603B2 (en) * | 2004-03-29 | 2006-06-20 | Hewlett-Packard Development Company, L.P. | Virtual bus interface production of header-type fields from data-type fields |
| US20050228926A1 (en) * | 2004-04-05 | 2005-10-13 | Smith Zachary S | Virtual-bus interface and associated system and method |
| US20060026181A1 (en) * | 2004-05-28 | 2006-02-02 | Jeff Glickman | Image processing systems and methods with tag-based communications protocol |
| US7848236B2 (en) * | 2004-08-10 | 2010-12-07 | Nokia Corporation | Differentiation of quality classes to different PDUs with support for multiple terminals |
| US7474642B1 (en) * | 2004-09-15 | 2009-01-06 | Nortel Networks Limited | Signaling reliability in using high-speed shared packet data channel |
| US7680100B1 (en) | 2004-09-30 | 2010-03-16 | Avaya Inc. | Internet protocol appliance manager |
| US9288713B2 (en) * | 2005-01-31 | 2016-03-15 | Google Technology Holdings LLC | Method and apparatus for dynamically changing modes of a reliable transport protocol |
| US10320989B2 (en) | 2005-02-11 | 2019-06-11 | Vasu Networks Corporation | Access point with controller for billing and generating income for access point owner |
| US8266237B2 (en) * | 2005-04-20 | 2012-09-11 | Microsoft Corporation | Systems and methods for providing distributed, decentralized data storage and retrieval |
| US8634422B2 (en) * | 2005-08-17 | 2014-01-21 | Qualcomm Incorporated | Prioritization techniques for quality of service packet transmission over a network lacking quality of service support at the media access control layer |
| KR100673177B1 (ko) | 2005-12-15 | 2007-01-22 | 에스케이 텔레콤주식회사 | 이동통신 단말기에서 실행되는 네트워크 기반어플리케이션의 ＱｏＳ 보장 방법 |
| JP4696008B2 (ja) * | 2006-03-20 | 2011-06-08 | 富士通株式会社 | Ｉｐ送信装置およびｉｐ送信方法 |
| KR100838375B1 (ko) * | 2006-04-28 | 2008-06-13 | 주식회사 하이닉스반도체 | 반도체 메모리 장치 |
| US20070258445A1 (en) * | 2006-05-02 | 2007-11-08 | Harris Corporation | Systems and methods for protocol filtering for quality of service |
| US8516153B2 (en) * | 2006-06-16 | 2013-08-20 | Harris Corporation | Method and system for network-independent QoS |
| US20070291768A1 (en) * | 2006-06-16 | 2007-12-20 | Harris Corporation | Method and system for content-based differentiation and sequencing as a mechanism of prioritization for QOS |
| US8730981B2 (en) * | 2006-06-20 | 2014-05-20 | Harris Corporation | Method and system for compression based quality of service |
| US20070291765A1 (en) * | 2006-06-20 | 2007-12-20 | Harris Corporation | Systems and methods for dynamic mode-driven link management |
| US20080013559A1 (en) * | 2006-07-14 | 2008-01-17 | Smith Donald L | Systems and methods for applying back-pressure for sequencing in quality of service |
| US20100238801A1 (en) * | 2006-07-31 | 2010-09-23 | Smith Donald L | Method and system for stale data detection based quality of service |
| US8300653B2 (en) * | 2006-07-31 | 2012-10-30 | Harris Corporation | Systems and methods for assured communications with quality of service |
| US20100241759A1 (en) * | 2006-07-31 | 2010-09-23 | Smith Donald L | Systems and methods for sar-capable quality of service |
| US20080025318A1 (en) * | 2006-07-31 | 2008-01-31 | Harris Corporation | Systems and methods for dynamically customizable quality of service on the edge of a network |
| US20080205309A1 (en) * | 2006-10-04 | 2008-08-28 | Nokia Corporation | Virtual adaptation layer for wireless communication |
| JP5128496B2 (ja) * | 2006-12-27 | 2013-01-23 | 京セラ株式会社 | 通信システム、無線通信端末、通信方法、無線通信方法、無線通信装置、およびその制御方法 |
| EP2103085B1 (en) * | 2006-12-29 | 2012-12-05 | Telecom Italia S.p.A. | Communications method for a packet-switched network and network employing the method |
| KR100877065B1 (ko) * | 2007-01-12 | 2009-01-09 | 삼성전자주식회사 | 통신 프로토콜 결정 방법 및 장치 |
| US8483142B2 (en) * | 2007-02-07 | 2013-07-09 | Wichorus, Inc. | Method and apparatus for managing backhaul links in a communication network |
| CN101277175B (zh) | 2007-03-30 | 2012-02-29 | 国际商业机器公司 | 改进会话启动协议服务器性能的方法和装置 |
| US8687482B2 (en) | 2007-09-07 | 2014-04-01 | Wichorus, Inc. | Apparatus and method for controlling traffic flow in backhaul link in wireless communication network |
| EP2241007A4 (en) * | 2008-01-03 | 2013-12-18 | Ikanos Technology Ltd | COGNITIVE AND UNIVERSAL IMPULSE NOISE PROTECTION |
| CN101222508A (zh) * | 2008-01-22 | 2008-07-16 | 张建中 | 一种数据分组差错处理和控制的方法和装置以及系统 |
| JP4545806B2 (ja) * | 2008-02-29 | 2010-09-15 | 富士通株式会社 | 通信装置および配置決定方法 |
| JP5206788B2 (ja) * | 2008-05-29 | 2013-06-12 | 富士通株式会社 | データ中継装置、データ中継プログラム、データ受信装置および通信システム |
| US20120033563A1 (en) * | 2010-08-05 | 2012-02-09 | Apple Inc. | Packet classification and prioritization using an ip header in a mobile wireless device |
| US8942104B2 (en) | 2010-08-05 | 2015-01-27 | Apple Inc. | Packet classification and prioritization using a UDP checksum in a mobile wireless device |
| KR20120084234A (ko) * | 2011-01-19 | 2012-07-27 | 삼성전자주식회사 | Ｍｐｅｇ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ｍｍｔ）에서 ｍｍｔ ａｕ를 전송하는 방법 |
| JP6088658B2 (ja) * | 2012-11-26 | 2017-03-01 | コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ | ネットワークにおけるデータのルーティング |
| US9369926B2 (en) * | 2013-05-08 | 2016-06-14 | Qualcomm Incorporated | Method and apparatus for handover VoLTE call to UMTS PS-based voice call |
| KR102195069B1 (ko) * | 2014-08-06 | 2020-12-24 | 삼성전자주식회사 | 패킷 송신기 및 이를 포함하는 인터페이스 장치 |
| CN108462646B (zh) | 2017-02-17 | 2020-08-25 | 华为技术有限公司 | 一种报文处理方法及装置 |
| US11128739B2 (en) * | 2018-12-24 | 2021-09-21 | Verizon Patent And Licensing Inc. | Network-edge-deployed transcoding methods and systems for just-in-time transcoding of media data |
| KR20200117131A (ko) * | 2019-04-03 | 2020-10-14 | 삼성전자주식회사 | 데이터 송신 방법 및 이를 위한 장치 |
| CN112584447A (zh) * | 2019-09-29 | 2021-03-30 | 索尼公司 | 无线通信系统中的电子设备和方法 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5729544A (en) * | 1994-05-09 | 1998-03-17 | Motorola, Inc. | Method for transmitting data packets based on message type |
| JPH09510596A (ja) * | 1994-06-08 | 1997-10-21 | エイチイー・ホールディングス・インコーポレーテッド・ディー ビーエー・ヒューズ・エレクトロニクス | ハイブリッドネットワークアクセスのための装置および方法 |
| FI98027C (fi) * | 1995-01-10 | 1997-03-25 | Nokia Telecommunications Oy | Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten |
| DE19640220A1 (de) * | 1996-01-31 | 1997-08-07 | Siemens Ag | Schnurloskommunikationsanlage gemäß dem ETSI-Standard DECT |
| JP3636399B2 (ja) * | 1996-05-29 | 2005-04-06 | 富士通株式会社 | プロトコル変換システム及びプロトコル変換方法 |
| US5708655A (en) * | 1996-06-14 | 1998-01-13 | Telefonaktiebolaget L M Ericsson Publ | Method and apparatus for addressing a wireless communication station with a dynamically-assigned address |
| JPH10178421A (ja) * | 1996-10-18 | 1998-06-30 | Toshiba Corp | パケット処理装置、移動計算機装置、パケット転送方法及びパケット処理方法 |
| US6304564B1 (en) * | 1996-11-29 | 2001-10-16 | Lucent Technologies Inc. | Method for transmitting messages in wireless communication system using a server process |
| US5987022A (en) * | 1996-12-27 | 1999-11-16 | Motorola, Inc. | Method for transmitting multiple-protocol packetized data |
| US6075796A (en) * | 1997-03-17 | 2000-06-13 | At&T | Methods and apparatus for providing improved quality of packet transmission in applications such as internet telephony |
| US5889772A (en) * | 1997-04-17 | 1999-03-30 | Advanced Micro Devices, Inc. | System and method for monitoring performance of wireless LAN and dynamically adjusting its operating parameters |
| US6385195B2 (en) * | 1997-07-21 | 2002-05-07 | Telefonaktiebolaget L M Ericsson (Publ) | Enhanced interworking function for interfacing digital cellular voice and fax protocols and internet protocols |
| US6041054A (en) * | 1997-09-24 | 2000-03-21 | Telefonaktiebolaget Lm Ericsson | Efficient transport of internet protocol packets using asynchronous transfer mode adaptation layer two |
| US6421714B1 (en) * | 1997-10-14 | 2002-07-16 | Lucent Technologies | Efficient mobility management scheme for a wireless internet access system |
| US6112084A (en) * | 1998-03-24 | 2000-08-29 | Telefonaktiebolaget Lm Ericsson | Cellular simultaneous voice and data including digital simultaneous voice and data (DSVD) interwork |
| US6278706B1 (en) * | 1998-04-03 | 2001-08-21 | Opuswave Networks, Inc. | Wireless packet data communication apparatus and method |
| US6400712B1 (en) * | 1998-05-26 | 2002-06-04 | Qualcomm Incorporated | Fast circuit switched data architecture and method |
| US6266337B1 (en) * | 1998-06-23 | 2001-07-24 | Expand Network Ltd. | Packet retransmission eliminator |
| EP0973302A1 (en) | 1998-07-15 | 2000-01-19 | Telefonaktiebolaget L M Ericsson (Publ) | Device and method for reliable and low-delay packet transmission |
-
1999
- 1999-01-21 EP EP99101121A patent/EP0975123A1/en not_active Withdrawn
- 1999-07-01 CN CNB998109436A patent/CN1188991C/zh not_active Expired - Fee Related
- 1999-07-01 AU AU49041/99A patent/AU756050B2/en not_active Ceased
- 1999-07-01 DE DE69928812T patent/DE69928812T2/de not_active Expired - Lifetime
- 1999-07-01 WO PCT/EP1999/004550 patent/WO2000004680A1/en active IP Right Grant
- 1999-07-01 AT AT99932775T patent/ATE312461T1/de not_active IP Right Cessation
- 1999-07-01 JP JP2000560694A patent/JP4334770B2/ja not_active Expired - Lifetime
- 1999-07-01 EP EP99932775A patent/EP1097548B1/en not_active Expired - Lifetime
- 1999-07-01 CA CA002337050A patent/CA2337050C/en not_active Expired - Lifetime
- 1999-07-15 US US09/353,853 patent/US6697352B1/en not_active Expired - Lifetime
-
2003
- 2003-08-20 US US10/644,473 patent/US7382763B2/en not_active Expired - Lifetime
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002051082A (ja) * | 2000-05-24 | 2002-02-15 | Sony Internatl Europ Gmbh | 通信ネットワーク用の処理装置及びソフトウェア |
| JP4615148B2 (ja) * | 2000-05-24 | 2011-01-19 | ソニー インターナショナル （ヨーロッパ） ゲゼルシャフト ミット ベシュレンクテル ハフツング | 通信ネットワーク用の処理装置及びソフトウェア |
| JP2007502585A (ja) * | 2003-08-14 | 2007-02-08 | インフォーカス コーポレイション | データ技術領域を送信する装置、システムおよび方法 |
| JP2008295070A (ja) * | 2008-07-03 | 2008-12-04 | Ntt Docomo Inc | 適応無線パラメータ制御方法、ＱｏＳ制御装置、基地局及び無線通信システム |
| JP2012095087A (ja) * | 2010-10-27 | 2012-05-17 | Kyocera Corp | 通信装置および通信方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2337050C (en) | 2009-12-01 |
| US7382763B2 (en) | 2008-06-03 |
| EP1097548A1 (en) | 2001-05-09 |
| JP4334770B2 (ja) | 2009-09-30 |
| DE69928812T2 (de) | 2006-08-24 |
| WO2000004680A1 (en) | 2000-01-27 |
| EP0975123A1 (en) | 2000-01-26 |
| US6697352B1 (en) | 2004-02-24 |
| US20040039833A1 (en) | 2004-02-26 |
| CA2337050A1 (en) | 2000-01-27 |
| DE69928812D1 (de) | 2006-01-12 |
| EP1097548B1 (en) | 2005-12-07 |
| CN1188991C (zh) | 2005-02-09 |
| AU756050B2 (en) | 2003-01-02 |
| AU4904199A (en) | 2000-02-07 |
| CN1318241A (zh) | 2001-10-17 |
| ATE312461T1 (de) | 2005-12-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4334770B2 (ja) | 通信装置と信頼性が高く遅延が短いパケット通信方法 | |
| US6577596B1 (en) | Method and apparatus for packet delay reduction using scheduling and header compression | |
| RU2296423C2 (ru) | Способ и устройство для обеспечения уровней с множеством показателей качества обслуживания в соединениях беспроводной передачи пакетов данных | |
| US8064345B2 (en) | Optimisation process of the control of traffic in a packet telecommunications network | |
| US20070091900A1 (en) | Prioritized control packet delivery for transmission control protocol (TCP) | |
| EP1261183A1 (en) | Method and system for processing a data unit | |
| US7843849B2 (en) | Packet data transmission in third generation mobile system | |
| EP1134942A1 (en) | Method and arrangement for control of non real-time application flows | |
| JP2000224261A (ja) | ネットワ―ク層プロトコルを直接サポ―トするデ―タリンク制御プロトコルおよび方法 | |
| WO1999051055A2 (en) | A method in packet data transmission between a wireless terminal and a mobile ip router | |
| GB2341059A (en) | Internet protocol flow detection | |
| JP2005064594A (ja) | フレーム送受信システム、フレーム送信装置、フレーム受信装置、及びフレーム送受信方法 | |
| WO2002028017A2 (en) | Method and apparatus for maintaining sequence numbering in header compressed packets | |
| EP1046266A1 (en) | Method and device for configuring a link | |
| JP2003520461A (ja) | データ送信の適正化方法 | |
| JP2000244603A (ja) | 情報転送方法、通信装置及びデータ通信システム | |
| JP2002534001A (ja) | 通信ネットワークにおけるデータ処理時間の削減に関する方法および装置 | |
| CA2514086C (en) | Methods and devices for transmitting data between storage area networks | |
| EP0973302A1 (en) | Device and method for reliable and low-delay packet transmission | |
| KR101333083B1 (ko) | 통신시스템에서 서비스 플로우별 패킷 데이터 분류 방법 및장치 | |
| EP1505759A2 (en) | Method and device for transmitting/receiving data using acknowledged transport layer protocols | |
| PACKETS | 1” ME?“UP LAYER n | |
| COMMAND et al. | Related US. Application Data (Continued)(63) Continuation of application No. 09/353,853,? led on Primary Examinel’4chi Pham | |
| JP2003008682A (ja) | パケット転送方法、中継装置および端末装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060523 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081202 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090227 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090526 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090624 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120703 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4334770 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120703 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130703 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |