JP2003509901A - 効率的な早期プロトコル検出方法 - Google Patents

効率的な早期プロトコル検出方法

Info

Publication number
JP2003509901A
JP2003509901A JP2001522721A JP2001522721A JP2003509901A JP 2003509901 A JP2003509901 A JP 2003509901A JP 2001522721 A JP2001522721 A JP 2001522721A JP 2001522721 A JP2001522721 A JP 2001522721A JP 2003509901 A JP2003509901 A JP 2003509901A
Authority
JP
Japan
Prior art keywords
bytes
information
communication device
content
byte
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
Application number
JP2001522721A
Other languages
English (en)
Other versions
JP2003509901A5 (ja
JP4472228B2 (ja
Inventor
アブロール、ニシャール
リオイ、マルセロ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Priority claimed from PCT/US2000/024623 external-priority patent/WO2001019027A2/en
Publication of JP2003509901A publication Critical patent/JP2003509901A/ja
Publication of JP2003509901A5 publication Critical patent/JP2003509901A5/ja
Application granted granted Critical
Publication of JP4472228B2 publication Critical patent/JP4472228B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18Negotiating wireless communication parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

(57)【要約】 全体的なパケットをアンフレームせずにPPPパケット中のプロトコルおよび構成メッセージを検出する方法およびシステムである。この方法は複数のデータフレームS306を受信する通信装置MT2 を含み、その通信装置は受信されたフレーム内の情報部分S305の開始を確認できる。通信装置は情報部分が予め定められたタイプのプロトコルおよび構成メッセージのような構成情報を含んでいるか否かを検出する。第1の実施形態では、この検出はS315で複数のバイトの内容をアンエスケープし、S325、S330、S335で、エスケープされたバイトが所望の構成情報を含んでいるか否かを決定する通信装置によって行われる。第2の実施形態では、通信装置は特定のバイトの内容がエスケープされた形態またはアンエスケープされた形態で所望の構成内容を含んでいるか否かを決定し、所望の構成情報を典型的に含んでいるバイトが処理されるまで、通信装置は情報部分内のバイトを逐次的に処理し続ける。

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】
本発明は無線通信分野、特に全体的なPPPパケットをアンフレームする必要
なく、早期のプロトコルおよび構成メッセージ検出を行う優れた方法およびシス
テムに関する。
【0002】
【従来の技術】
無線通信システムとコンピュータに関する技術における最近の革新と、インタ
ーネット加入者の前例にない成長は、移動体コンピュータ処理の道を切り開いて
いる。実際に、移動体コンピュータ処理の普及により、移動体ユーザにさらにサ
ポートを与えるための現在のインターネットインフラストラクチャには大きな需
要がある。これらの需要を満たしてユーザに必要なサポートを与える決定的な部
分は無線通信システムにおけるコード分割多元アクセス(CDMA)技術の使用
である。
【0003】 CDMAは、題名“MOBILE STATION-BASE STATION COMPATIBILITY STANDARD
FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM ”で1993年7月に
出版された米国電気通信工業会/米国電子工業会の暫定標準−95(TIA/E
IA IS−95)で規定されているデジタル無線周波数(RF)チャンネル化
技術であり、ここで参考文献とされる。この技術を使用する無線通信システムは
特有のコードを通信信号に割当て、これらの通信信号を共通の(広帯域)の拡散
スペクトル帯域幅を横切って拡散する。CDMAシステムの受信装置が正確なコ
ードを有する限り、これは適切にその通信信号を同一周波数帯域で他の同時に送
信された他の信号から検出し選択することができる。CDMAの使用はシステム
のトラフィック容量の増加を生成し、全体的な呼品質および雑音減少を改良し、
データサービストラフィックの信頼性のある伝送機構を与える。
【0004】 図1はこのような無線データ通信システム100 の基本素子を示している。当
業者はこれらの素子、またはそれらのインターフェースがそれらの技術的範囲ま
たは機能を限定せずに、変更、増加または技術で知られている種々の標準を受け
てもよいことを容易に認識するであろう。システム100 は移動体端末装置、即ち
TE2装置102 (例えばラップトップまたはパームトップコンピュータのような
端末装置)が相互作用機能(IWF)108 と通信することを可能にする。システ
ム100 は無線通信装置、即ちMT2装置104 (例えば無線電話)とベース局/移
動体交換局(BS/MSC)106 とを含んでいる。IWF108 は無線ネットワー
クと、インターネットまたはイントラネットベースのアクセスを行う公共交換電
話網または有線パケットデータ網のような他のネットワークとの間のゲートウェ
イとして機能する。
【0005】 図1で示されているように、IWF108 はLインターフェースを介してBS
/MSC106 に結合される。しばしば、IWF108 はBS/MSC106 と同じ位
置に配置される。TE2装置102 はRm インターフェースを介してMT2装置10
4 に電子的に結合される。MT2装置104 は無線インターフェースUm を介して
BS/MSC106 と通信する。TE2装置102 とMT2装置104 は単一の装置に
一体化されるか、ラップトップがTE2装置102 でありそのトランシーバがMT
2装置104 である設置された移動体電話装置の場合にように分離されてもよい。
図2により示されているように、一体化されているか分離されているかのいずれ
かのTE2装置102 とMT2装置104 の組合わせは移動局(MS)103 と通常呼
ばれることに注意することが重要である。
【0006】 無線通信の異なる特徴を制御、管理または容易にするために種々の既知のプ
ロトコルを適用することによって他のサポートが可能にされる。例えばインター
ネッインフラストラクチャの活動源、インターネットプロトコル(IP)はパケ
ット向けのサービスに適合するために無線通信に含まれている。IPプロトコル
はホストコンピュータ間のパケット(データグラム)のアドレスと経路設定を特
定し、それは1981年9月に出版された題名“INTERNET PROTOCOL DARPA INTERNET
PROGRAM PROTOCOL SPECIFICATION ”のRequest For Comment 791 (RFC 791
)に規定されており、ここで参考文献とされている。
【0007】 IPプロトコルは送信するためのIPパケット中にデータをカプセル化する
ネットワーク層プロトコルである。アドレス情報はパケットのヘッダに貼付けら
れる。IPヘッダ(例えばIPバージョン4)は送信および受信しているホスト
を識別する32ビットアドレスを含んでいる。これらのアドレスは中間ルータに
よって目的とするアドレスの最終目的地方向へのパケットのネットワークを通る
通路を選択するために使用される。したがって、IPプロトコルは、発生するパ
ケットが目的地のパーティのIPアドレスを部分的に知っているならば、世界中
の任意のインターネットノードで発生するパケットが世界中の他の任意のインタ
ーネットノードに伝送されることを可能にする。
【0008】 無線通信システムで実行されている別のよく知られたプロトコルはとりわけ
インターネットアクセスを与えるポイント・ツー・ポイントプロトコル(PPP
プロトコル)である。PPPプロトコルは1994年7月に出版された題名“THE PO
INT-TO-POINT PROTOCOL (PPP) ”のRequest For Comment 1661(RFC 1661 )
に詳細に説明されており、ここで参考文献とされている。
【0009】 基本的に、PPPプロトコルはポイント・ツー・ポイントリンクによってマ
ルチプロトコルデータグラムを転送する方法を特定し、3つの主なコンポーネン
ト、即ち直列リンクによるマルチプロトコルデータグラムのカプセル化方法と、
データリンク接続を設定し試験し構成し維持するためのリンク制御プロトコル(
LCP)と、異なるネットワーク層プロトコルを設定し構成するためのネットワ
ーク制御プロトコル(NCP)のファミリを含んでいる。
【0010】 無線通信システムでサービスのホストを与えるために、種々の標準方式がT
E2装置102 とIWF108 との間の無線データ送信に適合するために開発されて
いる。例えば、1998年2月出版の題名“DATA SERVICE OPTIONS FOR WIDEBAND SP
READ SPECTRUM SYSTEMS: PACKET DATA SERVICES ”(ここで参考文献とされてい
る)に記載されたTIA/EIA IS-707.5標準方式は、TIA/EIA I
S-95 システムのパケットデータ伝送容量のサポートのための要求を規定し、1
組のパケットデータベアラサービスを特定している。同様に、両者とも1999年3
月出版であり、ここで参考文献とされている題名“DATA SERVICE OPTIONS FOR S
PREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES”と題するTIA/EIA I
S-707-A.5標準と、題名“DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS
: HIGH-SPEED PACKET DATA SERVICES ”に記載されているTIA/EIA IS
-707-A.9標準方式はTIA/EIA IS-95 システムのパケットデータ送信サ
ポートのための要求を規定している。
【0011】 これらの標準方式はBS/MSC 106を介してTE2装置102 とIWF 108
との間で通信するために使用されてもよいあるパケットデータサービス選択肢を
与える。そうするために、IS-707.5はネットワークモデルを導入し、これはR m インターフェースとUm インターフェースとLインターフェースのパケットデ
ータプロトコルの要求事項を詳細に規定している。このモデル下では、2つの別
々のPPPリンクはデータリンク層で与えられ、即ち第1のPPPリンク(PP
R )はTE2装置102 とMT2装置104 との間に(即ちRm インターフェース
を横切って)データリンク層を与え、第2のPPPリンク(PPPU )は第1の
リンクと独立してMT2装置104 とIWF108 との間に(即ちUm とLインター
フェースを横切って)データリンク層を与える。
【0012】 別々の独立したPPPリンクは“透明な移動性”をサポートし、即ちTE2
装置102 は時間とその現在のIWF108 のポイント・ツー・ポイントの取付けと
関係なくシームレスで透明なサービスを受ける。このように、TE2装置102 は
位置の変化により影響されない。例えば、TE2装置102 はMT2装置104 が異
なるIWF108 に付こうとするときのように、Um リンクで生じるPPP再調整
から影響されてはならない。したがって、ネットワークモデルはUm リンクの変
化がRm リンクから影響されないように、PPPR リンクをPPPU リンクから
隔離するように動作する。換言すると、PPPU リンクはPPPR リンクを再調
整させずに再調整されることができる。
【0013】 図2はIS-707.5ネットワークモデルの各エンティティのプロトコルスタッ
クを示している。図2の最も左側には通常の垂直フォーマットで示されているプ
ロトコルスタックがあり、TE2装置102 (例えば移動体端末、ラップトップま
たはパームトップコンピュータ)で動作するプロトコル層を示している。TE2
装置104 のプロトコルスタックはRm インターフェースによってMT2装置104
のプロトコルスタックに論理的に接続されているように示されている。MT2装
置104 はUm インターフェースによってBS/MSC106 のプロトコルスタック
に論理的に接続されているように示されている。BS/MSC106 のプロトコル
スタックはLインターフェースによってIWF108 のプロトコルスタックに論理
的に接続されているように示されている。
【0014】 例示として、図2で示されているプロトコルは以下のように動作する。即ち
TE2装置 102上のPPPR プロトコル208 は上位層プロトコル204 とネットワ
ーク層IPプロトコル206 からパケットをコード化する。PPPR プロトコル20
8 はその後、TIA/EIA 232-Fプロトコル210 を使用してRm インターフェ
ースを横切ってパケットを、TIA/EIA 232-Fプロトコル212 を動作するM
T2装置104 上のTIA/EIA-232-F競合ポートへ送信する。TIA/EIA
-232-F標準方式は1997年10月出版の題名“INTERFACE BETWEEN DATA TERMINAL EQ
UIPMENT AND DATA CIRCUIT-TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY D
ATA INTERCHANGE ”で規定されており、ここでは参考文献とされている。当業者
に知られている他の標準方式またはプロトコルはRm インターフェースを横切る
送信を規定するために使用されてもよいことが理解される。例えば、他の応用可
能なRm インターフェース標準方式は1998年9月出版の“UNIVERSAL SERIAL BUS
(USB) SPECIFICATION,Revision 1.1 ”と、1999年7月出版の“BLUETOOTH SPEC
IFICATION VERSION 1.0A CORE ”に記載されており、両者は参考文献とされてい
る。
【0015】 MT2装置104 のTIA/EIA 232-F プロトコル212 はTE2装置102
からパケットを受信し、これらをPPPR プロトコル213 へ転送する。前述した
ように、PPPR プロトコル213 はPPPフレームにカプセル化されているパケ
ットをアンフレームし、典型的にデータ接続が設けられたとき、プロトコル213
はパケットをPPPU プロトコル217 へ転送する。プロトコル217 は基本的にI
WF108 に位置するPPPU ピアへ送信するためにパケットを再フレーム化する
。無線リンクプロトコル(RLP)216 とIS−95プロトコル214 は両者とも技
術でよく知られており、パケット−カプセル化されたPPPフレームをUm イン
ターフェースにわたってBS/MSC106 へ送信するために使用される。RLP
プロトコル216 は1998年2月出版でここで参考文献とされる題名“DATA SERVICE
OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS : RADIO LINK PROTOCOL ”の
IS-707.2標準方式と、1999年3月出版でここで参考文献とされる題名“DATA SER
VICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS : RADIO LINK PROTOCOL”のIS-707
-A.2標準方式に規定されている。
【0016】 BS/MSC106 の対応するRLPプロトコル222 とIS-95 プロトコル220
はLインターフェースを横切ってIWF 108上の中継層プロトコル224 へ送信
するためにパケットを中継層プロトコル224 へ転送する。PPPU プロトコル23
2 はその後、受信されたパケットをアンフレームし、これらをネットワーク層プ
ロトコルIP 230へ転送し、ネットワーク層プロトコルIP 230はこれらを上位
層プロトコル228 へ転送し、またはインターネットへ転送する。
【0017】 前述したように、PPPR プロトコル213 はデータリンク接続が設定された
ときにパケットをPPPU プロトコル217 へ転送する。RFC1661は、データリ
ンク接続を設定し構成し試験するためにリンク制御プロトコル(LCP)パケッ
トが各PPPリンク(即ちPPPR とPPPU )によって交換され調整されなけ
ればならないことを規定している。このように、これらのLCPパケットは構成
−リクエスト、構成−肯定応答、構成−否定応答、プロトコル−拒否、構成−拒
否メッセージを含み、それによって種々の選択肢を調整し、以下のように動作す
る。即ち構成−リクエストパケットは構成選択肢を調整するために使用される。
構成−肯定応答パケットは、受信された構成−リクエストパケットのあらゆる構
成選択肢が認識可能であり全ての値が受入れ可能である場合のみ送信される。構
成−否定応答パケットは、構成−リクエストパケット中のリクエストされた構成
選択肢が容認可能であるが受入れられないある値を含んでおり、構成−否定応答
選択肢フィールドが受入れられない構成−リクエスト構造選択肢で満たされ、作
用する値を指示しているときに送信される。構成−拒否パケットは、構成−リク
エスト中のリクエストされた構成選択肢が受信機により理解されない構成選択肢
を含んでおり構成−拒否選択肢フィールドが認められていない構成−リクエスト
構造選択肢を含んでいるとき送信される。
【0018】 一度、LCPパケットが交換されると、調整されたリンクの選択肢と、設定
されるデータリンク接続と、ネットワーク層接続がTE2装置 102とIWF 108
との間で設けられなければならない。このような接続はプロトコル206 、212 、
218 、230 を経て実現され、これらのプロトコルは例えばIPプロトコルを含ん
でいる。PPPリンクの両端部のIPプロトコルの調整、構成、エネーブリング
、ディスエーブリングはインターネットプロトコル制御プロトコル(IPCP)
により与えられる。IPCPはPPPプロトコルに含まれるネットワーク制御プ
ロトコル(NCP)のファミリの一部であり、1992年5月出版の題名“THE PPP
INTERNET PROTOCOL CONTROL PROTOCOL (IPCP) ”のRequest for Comment (RFC)
1332に記載され、ここで参考文献とされる。
【0019】 IPCPプロトコルはLCPプロトコルと同一の構成選択調整機構を使用し
、LCPプロトコルに非常に類似して、IPCP調停はRm インターフェースと
m インターフェースとの両者で別々に行われる。RFC1661に記載されている
ように、構成−肯定応答パケットは送信者が確認している選択肢のリストを含ん
でいる。MT2装置104 はRm およびUm インターフェースによって受信され送
信される構成−肯定応答パケットを監視し、コンピュータのメモリのような記憶
装置に各選択肢の値を記憶する。全ての構成選択肢はRFC1661により規定され
ているデフォルト値を有し、これらは対応する構成選択肢が調停されるときに使
用される。構成選択肢デフォルト値は例えば1995年12月出版で参考文献とされて
いる題名“PPP Internet Protocol Control Protocol Extensions for Name Ser
ver Addresses ”のRFC1877のような他のRFCにより規定されてもよいこと
に注意する。
【0020】
【発明が解決しようとする課題】
ネットワークモデルに関して前述したように、PPPU リンクはPPPR リン
クを再調停させずに再調停されることができる。Rm とUm インターフェース間
にこのような隔離を維持するため、MT2装置104 は通常受信されたPPPパケ
ットをアンフレームし、再度フレーム化する。MT2装置104 により受信される
パケットがMT2装置104 内の実行中の上位層プロトコルへ通過されなければ、
PPPパケットはアンフレームされ、後にPPPピアプロトコルへ送信するよう
に再度フレーム化されるだけである。このアンフレーム/再フレーム化はパケッ
トがMT2装置104 でさらに処理を必要としないときでさえも生じる。例えば、
呼が最初に行われるとき、LCPおよびIPCP機構はUm およびRm インター
フェースの両者で同一の構成選択肢を設定するように調整することができる。構
成選択肢が同一である限り、(構成パケットとは反対に)全てのPPPデータパ
ケットはMT2装置104 がパケットをアンフレーム/再フレーム化せずに1つの
インターフェースから他のインターフェースへ“通過”することができる。明ら
かに、構成選択肢が同一のままである場合、MT2装置104 は非常の多くの不必
要なPPPパケットのアンフレーム/再フレーム化動作を実行する。このような
動作はMT2装置104 の処理リソースと処理量の待ち時間に悪影響する。
【0021】 しかしながら、構成選択肢が変化するならば、これらは再調停されなければ
ならず、PPPパケットのアンフレーム/再フレーム化のために作用する。例え
ばMT2装置104 が可動であることにより、もとのIWF108 とは異なるIWF
108 によりサービスされる区域へ移動することができる。これが行われるとき、
MT2装置104 はサービスのため新しいIWF108 へ“ハンドオフ”される。こ
のハンドオフはMT2装置104 の介入と同様にUm インターフェースによって特
定のLCPとIPCPの構成選択肢の再調停を必要とする。構成選択肢メッセー
ジ(例えば構成−リクエスト、構成−肯定応答、構成−否定応答等)を含んだパ
ケットがパケットの内容をアンフレームまたは検査せずに単に“通過”されるだ
けならば、パケットはRm とUm リンクとは無関係に終端する全体的なリンクの
エンド・ツー・エンド再同期を強制する。
【0022】 それ故、PPPパケットをアンフレームする必要なく、早期のプロトコルお
よび構成メッセージの検出ができる優秀で実効的な方法およびシステムが必要と
されている。
【0023】
【課題を解決するための手段】
本発明はパケット全体をアンフレームする必要なくPPPパケット中のプロト
コルおよび構成メッセージを検出する方法およびシステムを提供することにより
上記のような必要性を解決する。
【0024】 実施され、ここで広く説明されている本発明の原理に一貫した方法およびシ
ステムは複数のデータフレームを受信する通信装置を含んでおり、その通信装置
は受信されたフレーム内の情報部分の開始位置を確認することができる。通信装
置は情報部分が予め定められたタイプのプロトコルおよび構成メッセージのよう
な構成情報を含んでいるか否かを検出する。第1の実施形態では、検出は複数の
バイトの内容をアンエスケープし、エスケープされたバイトが所望の構成情報を
含んでいるか否かを決定する通信装置によって行われる。第2の実施形態では、
通信装置は特定のバイトの内容がエスケープされた形態またはアンエスケープさ
れた形態で所望の構成情報を含んでいるか否かを決定し、所望の構成情報を典型
的に含んでいるバイトが処理されるか、情報が存在しないことが決定されるまで
、通信装置は情報部分内のバイトを逐次的に処理し続ける。
【0025】
【発明の実施の形態】 本明細書の一部に含まれそれを構成する添付図面は、本発明の実施形態を示し
ており、説明を伴って本発明の目的、利点、原理を説明する。 本発明の実施形態の以下の詳細な説明はこれらを示す添付図面に関連する。他
の実施形態が可能であり、実施形態に対する変更は本発明の技術的範囲を逸脱せ
ずに行われることができる。それ故、以下の詳細な説明は本発明を限定すること
を意味しない。本発明の技術的範囲は特許請求の範囲により限定される。
【0026】 以下説明するように、本発明の実施形態は図面で示されているエンティティ
のソフトウェア、ファームウェア、ハードウェア(即ちTE2装置102 、MT2
装置104 、BS/MSC106 、IWF108 )を含んでいる種々の構造で実現され
てもよいことは当業者には明白であろう。本発明の実行に使用される実際のソフ
トウェアコードまたは制御ハードウェアは本発明を限定するものではない。した
がって、本発明の動作と性質を実際のソフトウェアコードまたはハードウェアコ
ンポーネントを特別に参照せずに説明する。このような特別ではない参照は、当
業者がここでの説明に基づいて本発明の実施形態を実行するためにソフトウェア
と制御ハードウェアを設計できることが明白に理解されるので、受入れ可能であ
る。
【0027】 ここで説明される実施形態はHDLCフレームでカプセル化されるPPPパ
ケットで動作するので、図6はこのようなパケットの種々の属性を示している。
フレームの開始(および終了)は十六進法の符号“7E”により表される1バイ
トフレーミングフラグにより境界を定められる。それに続く2つのバイトはプロ
トコルアドレスと制御フィールドを示し、これは標準的なPPPパケットでは、
典型的にそれぞれ十六進法の符号“FF”および“03”として示される。次の
2つのバイトは例えば十六進法符号“C0”と“21”により示されるLCPプ
ロトコルと、十六進法符号“80”と“21”により示されるIPCPプロトコ
ルまたは十六進法符号(圧縮されてもよい)“00”と“2D”により示される
ファンヤコブセンプロトコルの圧縮された状態のようなプロトコルタイプを示し
ている。それに続くバイトは十六進法符号“01”により示される構成−リクエ
スト、十六進法符号“02”により示される構成−肯定応答、または十六進法符
号“03”により示される構成−否定応答のようなコードまたは構成メッセージ
を示している。
【0028】 1.第1の実施形態 図3は本発明の第1の実施形態を示しているフローチャートである。このよう
に、図3はPPPパケットで早期のプロトコルと構成メッセージの検出を実行す
るためのMT2装置104 の動作を詳細にしている。
【0029】 ステップS305で、MT2装置104 は最初に十六進法符号“7E”により示さ
れるフレーミングフラグを検出するために入来するデータ流を走査する。このフ
ラグはフレームの境界を定め、それ故PPPフレーム中でカプセル化されたパケ
ットの開始および/または終了を示すために使用されることができる。MT2装
置104 は“7E”フレーミングフラグを検出していない場合には、ステップS306
により示されているように、フラグを検出するまで入来するデータを走査し続け
る。MT2装置104 が一度“7E”フレーミングフラグを検出すると、ステップ
S310へ進行する。
【0030】 “7E”フラグを検出後、MT2装置104 はステップS310で、次のバイトも
“7E”フラグであるか否かを決定する。イエスであるならば、MT2装置104
はステップS320で示されているようにその特定のバイトをスキップし、“7E”
フラグ検査を次のバイトへ適用するためにS310へ戻る。次のバイトが“7E”フ
ラグではないならば、MT2装置104 はステップS315へ進む。フレームの最後を
示す“7E”フラグが新しいフレームの開始を示す次の“7E”フラグへ並列さ
れる背合せパケットの場合のように、入来するデータ流は連続的な“7E”フラ
グを含んでもよいことに注意することが重要である。ステップS310とS320はフレ
ーミングフラグを濾波するように動作し、MT2装置104 がフレームに形成され
たパケットの情報部分が開始する場所を見分けることを可能にする。
【0031】 次のバイトが“7E”フラグではなく情報バイトであることを認知すると、
MT2装置104 はステップS315で次のXの数のバイトを“アンエスケープ”し、
ここでXはフレームに形成されたパケット内で捜索された情報の相対位置に対応
する。技術で知られているようにPPPプロトコルが非同期のHDLCのような
フレーミング(即ちRFC1662当り)で送信されるとき、プロトコルは特別な制
御文字としても機能するパケットの情報部分内のある符号をマスクするため“エ
スケープ技術”を使用するので、このアンエスケープが実行される。このような
文字符号は前述の“7E”フラグと、エスケープフラグ“7D”を含んでいる。
これらの符号がフレームに形成されたパケットの情報部分で遭遇されるとき、エ
スケープ技術は符号の前にエスケープフラグ“7D”をスタッフし、その制御機
能を中和するためにその文字を変更する。それ故、あるプロトコルまたは構成情
報を入来するデータ流から探すために、MT2装置104 はステップS315でその真
のアイデンティティをアンカバーするために探されている情報をアクセスするの
に必要なバイト数をアンエスケープする。Xバイトをアンエスケープした後、M
T2装置104 はステップS325に進む。
【0032】 ステップS325では、MT2装置104 はアンエスケープされたXバイトが標準
的なPPPアドレスと制御フィールド符号“FF”と“03”をそれぞれ含んで
いるか否かを決定する。これらの符号は典型的にPPPパケットの情報部分の第
1および第2のバイトを構成しているが(例えば図6参照)、これらの符号はパ
ケットから圧縮されてもよく、それによって続く情報バイトの位置に影響する。
それ故、MT2装置104 はこれらの符号が必要な調節を後に行うためにパケット
のアンエスケープされたバイト内に含まれるか否かをチェックしなければならな
い。符号“FF”と“03”がアンエスケープされたバイトに含まれていないな
らば(即ち符号“FF”と“03”が圧縮されているならば)、MT2装置104
はステップS330で、捜索されたプロトコルまたは構成メッセージ情報をこれらの
バイトが含んでいるか否かをチェックする。イエスであるならば、MT2装置10
4 はステップS340で、パケットをアンフレームし、検出された情報によって示さ
れた処理にかかわるようにパケット全体をMT2装置104 のアンフレーマへ転送
する。捜索された情報をバイトが含んでいないならば、MT2装置104 はパケッ
ト全体をMT2装置104 の送信部分へ送信し、ステップS345により示されている
ように適切なインターフェースを横切って転送される。
【0033】 ステップS325に戻り、アンエスケープされたXバイトが“FF”と“03”
を含んでいるならば、MT2装置104 はステップS335で特定されたXバイトに加
えて別の2バイトをアンエスケープすることにより補償する。これはXバイト内
の“FF”と“03”符号の含有を調節する。MT2装置104 はその後、X+2
のアンエスケープされたバイトをステップS330へ与え、ここで前述したようにア
ンエスケープされたバイトが所望の情報を含むか否かをチェックする。イエスで
あるならば、MT2装置104 はステップS340で、パケット全体をMT2装置104
のアンフレーマへ転送する。捜索されたプロトコルまたは構成情報メッセージを
バイトが含んでいないならば、MT2装置104 はステップS345で、パケットを適
切なインターフェースを横切って転送するためにパケット全体をMT2装置104
の送信部分へ送信する。
【0034】 この実施形態の動作を説明するために、LCPプロトコルパケットの早期の
検出が所望であると想定する。LCPプロトコル仕様はPPPフレームに形成さ
れたパケットのプロトコル情報部分内に設けられる。図6で示されているように
、プロトコル情報は2バイトの長さであり、標準的なPPPフレームのパケット
の情報部分のバイト位置3および4により占有される。入来データ流を走査し、
情報バイトが開始する場所を見分けた後(即ちステップS305、S310、S320)、M
T2装置104 はステップS315により示されているように次の2バイト(即ちXは
2に等しい)をアンエスケープする。ステップS325では、最初の2バイトが“F
F”と“03”符号を含んでいないならば、MT2装置104 は捜索されたLCP
情報をこれらのバイトが含んでいるか否かをチェックする。イエスならば、MT
2装置104 はステップS340で、パケット全体をMT2装置104 のアンフレーマへ
転送し、それによってパケットのフレームを解除し、LCPプロトコル情報によ
り必要とされる処理に従事する。バイトがLCP情報を含んでいないならば、M
T2装置104 はステップS345により示されているように、適切なインターフェー
スを横切って転送されるようにパケット全体をMT2装置104 の送信部分へ送信
する。
【0035】 他方で、アンエスケープされたXバイトの最初の2バイトが“FF”と“0
3”であるならば、MT2装置104 はステップS335で、最初の2バイトに加えて
次の2バイトをアンエスケープすることによって補償する。MT2装置104 はそ
の後、全部で4のアンエスケープされたバイトをステップS330へ与え、ここで前
述したようにこれらのバイトが捜索されたLCP情報を含むか否かをチェックす
る。イエスであるならば、MT2装置104 はステップS340で、パケット全体をM
T2装置104 のアンフレーマへ転送する。バイトがLCP情報を含んでいないな
らば、MT2装置104 はステップS345で、パケット全体をMT2装置104 の送信
部分へ送信する。
【0036】 前述の実施形態によって、PPPフレームのパケット内に含まれる全てのヘ
ッダ情報がパケット全体をアンフレームせずに検出されることができることに注
意することが重要である。例えば、ステップS315で単にX値を調節することによ
って、この実施形態はプロトコル情報、構成メッセージ、パケットID等として
このようなPPP情報を検出することができる。
【0037】 したがって、この実施形態はパケット全体をアンフレームする必要なくPP
Pパケット流内のプロトコルおよび構成メッセージを検出する。むしろ、パケッ
トの情報部分内のあるバイトをアンエスケープすることによって、この実施形態
は不必要なPPPパケットのアンフレーム/再フレーム動作を実行せずにプロト
コルおよび構成メッセージを実効的に検出するシステムおよび方法を与える。
【0038】 2.第2の実施形態 図4と5は本発明の第2の実施形態を示したフローチャートである。この実施
形態はパケットをアンフレームせずに、入来するデータ流を走査して、段の情報
バイトを機械的にチェックすることによってPPPフレームのパケットの情報部
分内に含まれるプロトコルおよび構成メッセージを検出する。所定のPPPフレ
ームのパケットのフォーマットでは図6により示されているように、第1の段は
パケットの情報部分内に含まれる1バイトのアドレスフィールドの内容を特別に
検出する。第2の段は1バイトの制御フィールドの内容の検出に関し、これはア
ドレスフィールドに従う。したがって、この実施形態は情報部分の最後まで、段
を進行し、全ての情報フィールドの内容を検出できる。例えば、第3の段は2バ
イトプロトコルフィールドの内容の検出に関し、これは制御フィールドに従う。
しかしながら、PPPフレームに形成されたパケット構造と、この実施形態の逐
次特性のために、フレームの後のフィールドに含まれる情報は通常、先のフィー
ルドに含まれる情報の処理および検出後に検出される。
【0039】 この実施形態の代表的な例として、捜索された情報が制御フィールド内に含
まれていると想定する。このフィールドをアクセスし、入来するデータ流から適
切な情報を検出するために、MT2装置104 はPPPパケットの情報部分の開始
を最初に識別し、その後アドレスフィールドの情報にアクセスし、検出しなけれ
ばならない。アドレスフィールド情報の処理後にのみ、MT2装置104 は制御フ
ィールド情報のアクセスおよび検出の準備が整えられる。
【0040】 このように、図4はこの実施形態の第1の段を示している。ステップS405に
おいて、MT2装置104 は最初に、フレーミングフラグ“7E”を検出するため
に入来するデータ流を走査する。“7E”フラグの検出後、MT2装置104 はス
テップS410で次のバイトもまた“7E”フラグであるか否かを決定する。イエス
であればMTS装置104 はステップS415で示されているように次のバイトへ移動
し、“7E”フラグ検査を次のバイトに適用するためにステップS410へ戻る。次
のバイトが“7E”フラグではないならば、MT2装置104 はステップS420へ進
む。第1の実施形態に関して前述したように、ステップS410とS415はフレーミン
グフラグを濾波するように動作し、MT2装置104 がPPPフレームのパケット
の情報部分の開始を識別することを可能にする。
【0041】 一度、MT2装置104 が開始情報部分を識別できると、段の情報を検出する
ためにPPPパケットのフォーマットを使用する。前述したように、この実施形
態の第1の段は符号“FF”を検出する。
【0042】 ステップS420で、MT2装置104 は第1の情報バイトがエスケープ符号“7
D”であるか否かをチェックする。前述したように、エスケープ技術はある符号
の前にエスケープフラグ“7D”をスタッフし、これらをマスクする。第1の情
報バイトが“7D”ではないならば(即ち第1の情報バイトがエスケープされな
いならば)、MT2装置104 はステップS425において、第1の情報バイトが“F
F”符号(即ちアンエスケープされた形態)であるか否かをチェックする。イエ
スならば、MT2装置104 はステップS435に進む。第1の情報バイトが“FF”
符号ではないならば、MT2装置104 はステップS426で、捜索されたフレームに
形成されたパケット内にさらに情報が存在するか否かを決定し、存在するならば
、MT2装置104 はステップS427で次の段へ移動する。付加的な所望の情報が存
在しないならば、MT2装置104 はステップS428で、適切なインターフェースを
横切ってパケットを転送するためにパケット全体をMT2装置104 の送信部分へ
送信する。
【0043】 ステップS420へ戻ると、第1の情報バイトが“7D”であるならば(即ち第
1の情報バイトがエスケープされているならば)、MT2装置104 はステップS4
30で、次のバイトがエスケープされたフォーマット(即ち十六進法符号“DF”
)の“FF”符号であるか否かをチェックする。イエスであるならば、MT2装
置104 はステップS435へ進む。次のバイトが“DF”符号ではないならば、MT
2装置104 はステップS426に進行し、ここでは前述したように、MT2装置104
はさらに所望の情報が存在するか否かをチェックする。存在するならば、MT2
装置104 はステップS427で次の段へ移動する。付加的な所望の情報が存在しない
ならば、MT2装置104 はステップS428で適切なインターフェースを横切ってパ
ケットを転送するためにパケット全体をMT2装置104 の送信部分へ送信する。
【0044】 ステップS430で、次のバイトがエスケープされたフォーマットの“FF”符
号(即ち十六進法符号“DF”)であるならば、MT2装置104 はステップS435
に移動し、そこで捜索される情報がさらに存在しているか否かを検査する。存在
する場合にはMT2装置104 はステップS427で次の段へ移動する。付加的な所望
の情報が存在しないならば、MT2装置104 はステップS437で、MT2装置104
のアンフレーマへパケット全体を転送し、それによってパケットをアンフレーム
し、検出された情報により示される処理に従事する。
【0045】 実施形態の第1の段を完了(即ちプロトコルアドレスフィールドの“FF”
符号の検出)後、MT2装置104 は代表的な例の目的と一貫して、制御フィール
ドの“03”符号を検出しようとしなければならない。前述したように、この検
出はこの実施形態の第2の段の検出と呼ばれ、図5に示されている。
【0046】 第1の段の終了時、ステップS427により示されているように、MT2装置104
は、ステップS440で再度、次のバイトが“7D”符号であるか否かを決定する
。前述したように、この決定は関連する情報フィールド内の符号がエスケープさ
れた場合に使用される。次のバイトが“7D”符号ではないならば、MT2装置
104 はステップS445で、バイトが“03”符号(即ちアンエスケープされたフォ
ーマット)であるか否かを決定する。イエスであるならば、MT2装置104 はス
テップS435へ進行し、ここで前述したように、MT2装置104 は捜索された付加
的な情報が存在するか否かを決定し、存在する場合にはMT2装置104 がステッ
プS427で次の段へ移動するか否かを決定する。存在しないならば、MT2装置10
4 はステップS428 で、適切なインターフェースを横切ってパケットを転送する
ためにパケット全体をMT2装置104 の送信部分へ送信する。
【0047】 ステップS440へ戻ると、MT2装置104 は続くバイトが“7D”符号である
ことを決定したならば、ステップS450で次のバイトがエスケープされたフォーマ
ット(即ち十六進法符号“23”)の“03”符号であるか否かをチェックする
。次のバイトが“23”符号ではないならば、MT2装置104 はステップS426へ
進み、ステップS427のように次の段へ移動するか否かを決定し、またはステップ
S428のように適切なインターフェースを横切ってパケットを転送するためパケッ
ト全体をMT2装置104 の送信部分へ送信する。次のバイトが“23”符号であ
るならば、MT2装置104 はステップS435に進行し、ここでは、ステップS427の
ように次の段へ移動するか否かを決定し、またはステップS437のようにパケット
全体をMT2装置104 のアンフレーマへ転送する。
【0048】 したがって、この実施形態はパケットをアンフレームする必要なくPPPパ
ケット流内のプロトコルおよび構成メッセージを検出する。むしろ、この実施形
態は入来するデータ流を走査し、段中の情報バイトを機械的にチェックする。こ
れらの段はPPPフレームパケットの情報フィールドに対応し、それ故、この実
施形態は不必要なPPPパケットアンフレーム/再フレーム動作を実行せずに、
リンク構造に影響するメッセージを無視せずに逐次的に所望の情報を検出する。
【0049】 本発明の好ましい実施形態の前述の説明は、例示と説明を与えるが、排他的
或いは、説明されている正確な形態に本発明を限定することを目的とするもので
はない。変更および変形は前述の教示と一貫して可能であり、または本発明の実
施から得られることができる。したがって、本発明の技術的範囲は特許請求の範
囲とその均等物により限定される。
【図面の簡単な説明】
【図1】 無線通信システムの種々の素子を示した高レベルのブロック図。
【図2】 無線通信システムのプロトコルスタックの概略図。
【図3】 本発明の第1の実施形態を示しているフローチャート。
【図4】 本発明の第2の実施形態を示しているフローチャート。
【図5】 本発明の第2の実施形態を示しているフローチャート。
【図6】 PPPフレームにカプセル化されたパケットの一般的なフォーマットを示した
図。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 EP(AT,BE,CH,CY, DE,DK,ES,FI,FR,GB,GR,IE,I T,LU,MC,NL,PT,SE),OA(BF,BJ ,CF,CG,CI,CM,GA,GN,GW,ML, MR,NE,SN,TD,TG),AP(GH,GM,K E,LS,MW,MZ,SD,SL,SZ,TZ,UG ,ZW),EA(AM,AZ,BY,KG,KZ,MD, RU,TJ,TM),AE,AG,AL,AM,AT, AU,AZ,BA,BB,BG,BR,BY,BZ,C A,CH,CN,CR,CU,CZ,DE,DK,DM ,DZ,EE,ES,FI,GB,GD,GE,GH, GM,HR,HU,ID,IL,IN,IS,JP,K E,KG,KP,KR,KZ,LC,LK,LR,LS ,LT,LU,LV,MA,MD,MG,MK,MN, MW,MX,MZ,NO,NZ,PL,PT,RO,R U,SD,SE,SG,SI,SK,SL,TJ,TM ,TR,TT,TZ,UA,UG,UZ,VN,YU, ZA,ZW (72)発明者 リオイ、マルセロ アメリカ合衆国、カリフォルニア州 92122 サン・ディエゴ、ナンバー1924、 チャーマント・ドライブ 7588 Fターム(参考) 5K034 AA02 EE03 HH63 JJ24 KK27 5K067 AA13 CC08 CC10 EE02 EE10 HH22

Claims (13)

    【特許請求の範囲】
  1. 【請求項1】 予め定められたタイプの構成情報を早期に検出する方法にお
    いて、 それぞれ情報部分を含んでいる複数のフレームに形成されたデータパケットを
    通信装置で受信し、 1つの前記フレームに形成されたデータパケット内の前記情報部分の開始点を
    前記通信装置で検出し、 前記情報部分が予め定められたタイプの前記構成情報を含んでいるか否かを前
    記通信装置で決定するステップを有し、 前記情報部分が予め定められたタイプの前記構成情報を含んでいるとき、前記
    通信装置は前記1つのフレームに形成されたデータパケットをアンフレームする
    検出方法。
  2. 【請求項2】 前記検出するステップは、前記複数の前記フレームに形成さ
    れたデータパケットを走査し、フレームの境界を定める符号を識別することによ
    って1つの前記フレームに形成されたデータパケットの前記情報部分の前記開始
    点を設定することを含んでいる請求項1記載の方法。
  3. 【請求項3】 前記検出するステップは、 前記情報部分内の予め定められた数のバイトの内容を前記通信装置でアンエス
    ケープし、 前記アンエスケープされた予め定められた数のバイトの内容が予め定められた
    符号を含んでいるか否かを前記通信装置で決定するステップを含んでおり、 前記通信装置は、前記アンエスケープされた予め定められた数のバイトの前記
    内容が前記予め定められた符号を含んでいるとき、前記予め定められた数のバイ
    トに続く付加的な連続的なバイトの内容をアンエスケープし、 前記通信装置は、前記アンエスケープされた予め定められた数のバイトの内容
    と、付加的な連続的なバイトの内容が予め定められたタイプの前記構成情報を含
    んでいるか否かを決定する請求項2記載の方法。
  4. 【請求項4】 前記検出するステップは、 前記情報部分の特定の1以上のバイトの内容が前記特定のバイトに関連するタ
    イプの情報を含んでいるか否かを前記通信装置で決定し、 前記特定のバイトの前記内容が予め定められたタイプの前記構成情報を含んで
    いるか否かを前記通信装置で決定するステップを含んでおり、 前記通信装置は、前記特定のバイトの前記内容が予め定められたタイプの前記
    構成情報をもたないとき次の段へ進行し、予め定められたタイプの前記構成情報
    は前記特定のバイトの次のバイト位置に配置される請求項2記載の方法。
  5. 【請求項5】 前記次の段へ進行するステップは、 前記情報部分の少なくとも1つの連続するバイトの内容を前記通信装置で検査
    し、前記連続するバイトは前記特定のバイトに後続しており、 前記連続するバイトの内容が前記連続するバイトに関連するタイプの情報を含
    んでいるか否かを前記通信装置で決定し、 前記連続するバイトの内容が予め定められたタイプの前記構成情報を含んでい
    るか否かを前記通信装置で決定するステップをさらに含んでおり、 前記通信装置は、前記連続するバイトが予め定められたタイプの前記構成情報
    を含むまで前記情報部分の連続的なバイトを逐次的に検査する請求項4記載の方
    法。
  6. 【請求項6】 前記特定のバイトの内容と前記連続するバイトの内容はエス
    ケープされた情報を含んでいる請求項5記載の方法。
  7. 【請求項7】 前記特定のバイトの内容と前記連続するバイトの内容はアン
    エスケープされた情報を含んでいる請求項5記載の方法。
  8. 【請求項8】 予め定められたタイプの構成情報を早期に検出するシステム
    において、 それぞれ情報部分を含んでいる複数のフレームに形成されたデータパケットを
    送信し受信する端末装置と、 前記端末装置に結合されている通信装置とを具備し、 前記通信装置は1つの前記フレームに形成されたデータパケット内の前記情報
    部分の開始点を検出し、前記情報部分が予め定められたタイプの前記構成情報を
    含んでいるか否かを決定し、 前記通信装置は、前記情報部分が予め定められたタイプの前記構成情報を含ん
    でいるとき、前記1つのフレームに形成されたデータパケットをアンフレームす
    るシステム。
  9. 【請求項9】 前記通信装置による前記検出において、前記複数の前記フレ
    ームに形成されたデータパケットを走査し、フレームの境界を定める符号を識別
    することによって1つの前記フレームに形成されたデータパケットの前記情報部
    分の前記開始点を設定することを含んでいる請求項8記載のシステム。
  10. 【請求項10】 前記通信装置による前記検出において、 前記情報部分内の予め定められた数のバイトの内容をアンエスケープし、 前記アンエスケープされた予め定められた数のバイトの前記内容が予め定めら
    れた符号を含んでいるか否かを決定し、 前記通信装置は、前記アンエスケープされた予め定められた数のバイトの内容
    が予め定められた符号を含んでいるとき、前記予め定められた数のバイトに続く
    付加的な連続的なバイトの内容をアンエスケープし、 前記通信装置は、前記アンエスケープされた予め定められた数のバイトの内容
    と、付加的な連続的なバイトの内容が予め定められたタイプの前記構成情報を含
    んでいるか否かを決定する請求項9記載のシステム。
  11. 【請求項11】 前記通信装置による前記検出において、 前記情報部分の1以上の特定のバイトの内容が前記特定のバイトに関連するタ
    イプの情報を含んでいるか否かを決定し、 前記1以上の特定のバイトの内容が予め定められたタイプの構成情報を含んで
    いるか否かを決定するステップを含んでおり、 前記通信装置は、前記1以上の特定のバイトの内容が予め定められたタイプの
    前記構成情報をもたないとき次の段へ進行し、予め定められたタイプの前記構成
    情報は前記1以上の特定のバイトの次のバイト位置に配置される請求項9記載の
    システム。
  12. 【請求項12】 前記次の段へ進行するとき前記通信装置はさらに、 前記情報部分の少なくとも1つの連続するバイトの内容を検査し、前記連続す
    るバイトは前記特定のバイトに後続しており、 前記連続するバイトの内容が前記連続するバイトに関連するタイプの情報を含
    んでいるか否かおよび前記連続するバイトの前記内容が予め定められたタイプの
    前記構成情報を含んでいるか否かを決定し、 前記通信装置は、前記連続するバイトが予め定められたタイプの前記構成情報
    を含むまで前記情報部分の連続的なバイトを逐次的に検査する請求項11記載の
    システム。
  13. 【請求項13】 前記特定のバイトの内容と前記連続するバイトの内容はエ
    スケープされた情報を含んでいる請求項12記載の方法。
JP2001522721A 1999-09-08 2000-09-07 効率的な早期プロトコル検出方法 Expired - Fee Related JP4472228B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/392,342 1999-09-08
US09/828,623 US6934276B1 (en) 1999-09-08 1999-09-08 Methods for efficient early protocol detection
PCT/US2000/024623 WO2001019027A2 (en) 1999-09-08 2000-09-07 Methods for efficient early protocol detection

Publications (3)

Publication Number Publication Date
JP2003509901A true JP2003509901A (ja) 2003-03-11
JP2003509901A5 JP2003509901A5 (ja) 2006-01-05
JP4472228B2 JP4472228B2 (ja) 2010-06-02

Family

ID=34838995

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001522721A Expired - Fee Related JP4472228B2 (ja) 1999-09-08 2000-09-07 効率的な早期プロトコル検出方法

Country Status (7)

Country Link
US (1) US6934276B1 (ja)
EP (1) EP1210829B1 (ja)
JP (1) JP4472228B2 (ja)
KR (1) KR100746866B1 (ja)
AT (1) ATE415789T1 (ja)
DE (1) DE60040916D1 (ja)
HK (1) HK1056073A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030172178A1 (en) * 2002-03-08 2003-09-11 Eduard Lecha Method to avoid high-level data link control (HDLC) frame abortion
RU2343636C2 (ru) * 2004-03-12 2009-01-10 Самсунг Электроникс Ко., Лтд. Способ и устройство для построения карты ie с использованием редуцированного cid в широкополосных ofdma системах

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5260942A (en) * 1992-03-06 1993-11-09 International Business Machines Corporation Method and apparatus for batching the receipt of data packets
FI98027C (fi) * 1995-01-10 1997-03-25 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten
US5666362A (en) * 1995-07-25 1997-09-09 3Com Corporation Method and apparatus for asynchronous PPP and synchronous PPP conversion
US5699350A (en) * 1995-10-06 1997-12-16 Canon Kabushiki Kaisha Reconfiguration of protocol stacks and/or frame type assignments in a network interface device
JP3471523B2 (ja) * 1996-05-21 2003-12-02 インターナショナル・ビジネス・マシーンズ・コーポレーション 通信方法及び通信端末
US5835036A (en) * 1997-05-12 1998-11-10 Cisco Systems Co. Method of encoding data for transmission
US6157641A (en) * 1997-08-22 2000-12-05 Cisco Technology, Inc. Multiprotocol packet recognition and switching
DE19800772C2 (de) * 1998-01-12 2000-04-06 Ericsson Telefon Ab L M Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz
WO2000057284A1 (en) * 1999-03-25 2000-09-28 Motorola Inc. Point to point protocol multiplexing/demultiplexing method and apparatus
US6542504B1 (en) * 1999-05-28 2003-04-01 3Com Corporation Profile based method for packet header compression in a point to point link
US6483822B1 (en) * 1999-06-07 2002-11-19 Marcello Lioy Establishing a packet network call between a mobile terminal device and an interworking function

Also Published As

Publication number Publication date
EP1210829B1 (en) 2008-11-26
US6934276B1 (en) 2005-08-23
DE60040916D1 (de) 2009-01-08
KR20020060948A (ko) 2002-07-19
HK1056073A1 (en) 2004-01-30
ATE415789T1 (de) 2008-12-15
EP1210829A2 (en) 2002-06-05
JP4472228B2 (ja) 2010-06-02
KR100746866B1 (ko) 2007-08-07

Similar Documents

Publication Publication Date Title
US6775553B1 (en) Method of avoiding PPP time-outs during IPCP negotiations
KR100343172B1 (ko) 무선 데이터 전송 방법과 그 이동 단말기 및 이종신호간 연동장치
US6400712B1 (en) Fast circuit switched data architecture and method
JP2003530764A (ja) パケット交換データ伝送におけるデータパケット番号付け
JP2003523137A (ja) パケット交換データ伝送におけるデータ・パケット番号付加方式
US8098617B2 (en) Method and apparatus for selective examination of PPP packets for renegotiation of a PPP link on a Um interface
RU2304854C2 (ru) Способ определения согласованных вариантов конфигурации для линии радиосвязи, использующей сетевую модель
CA2384162C (en) Methods for efficient early protocol detection
JP2002538674A (ja) Umおよびrmインターフェースにおけるポップの同時的なセットアップ
JP2000341339A (ja) アドレス解決方法とアドレス解決通信システム
EP1596554B1 (en) Selectively maintaining and applying PPP compression in a wireless communication system
IL147522A (en) Independent scheduling of PPP links in Um and Rm interfaces
JP2003509901A (ja) 効率的な早期プロトコル検出方法
JP2003519935A (ja) ポイントトゥポイントフレーム構成をフレーミングする通信網及び方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051006

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070814

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100127

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: 20100202

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: 20100303

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130312

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4472228

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130312

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140312

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

LAPS Cancellation because of no payment of annual fees