JP2006508617A - 携帯電話を終点とするショートデータバースト通信のための方法及び装置 - Google Patents

Abstract

【課題】携帯電話を終点とするショートデータバースト通信のための方法及び装置
【解決手段】情報をターゲットの移動局へ送信する方法及び装置は、前記ターゲットの移動局が休眠モードになっている間、前記情報をショートデータバーストメッセージとして送信すべきか否かを判断することと、再確立すべき情報チャネルを待つことなく、前記情報を前記ターゲットの移動局へショートデータバーストメッセージとして送信することとを含む。

Description

本発明は、インターネット等の全世界に分散したネットワークにおいて情報を伝達することに関する。より具体的には、本発明は、ターゲットの通信装置が休眠モードであるときに、情報チャネルが起動されるのを待つことなく、情報をこのターゲットの通信装置へショートデータバーストフォーマットで送信するか否かを判断する方法及び装置に関する。

ターゲットの通信装置へ宛先が定められた情報を保持するインターネットプロトコル（ＩＰ）データグラムが、パケットデータサービスノード（ＰＤＳＮ）から基地局制御装置（ｂａｓｅ ｓｔａｔｉｏｎ ｃｏｎｔｒｏｌｌｅｒ）／パケット制御機能（ｐａｃｋｅｔ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）（ＢＳＣ／ＰＣＦ）へ送信されると共に、パケットセッションが休眠状態である場合には、ＢＳＣ／ＰＣＦは、前記情報をショートデータバースト（ＳＤＢ）として送信すべきか否かを判断する必要がある。１つのアルゴリズムは、受信した情報パケットのサイズをフィルタリングの判定基準としてとして用いることである。すなわち、前記受信した情報パケットが、所定のサイズより小さいことが分かった場合、この情報パケットは、情報チャネルが起動されるのを待つことなく、例えば、順方向共通チャネルを介してＳＤＢとしてターゲットの移動局へ送信することができる。そうでない場合には、情報チャネルは、前記情報パケットを送信する前に、再確立される必要がある。このアルゴリズムは、例えば、グループコールサービスにおいてうまく作用しない可能性があり、この場合、クライアント及びサーバは、前記データセッションが休眠状態であると、様々なサイズのメッセージを送信する。しかし、それら全てのメッセージは、タイムクリティカルであるとは限らないため、ＳＤＢとして送信する必要はない。一部の大きなメッセージは、ＳＤＢとして送信する必要がある可能性があると共に、一部の小さなメッセージは、情報チャネルが再確立された後に配信する必要がある可能性がある。大きなパケットサイズをフィルタリング判定基準として用いることは、ＳＤＢとして送信すべき多数の小さなメッセージをトリガする可能性があり、それによって、共通チャネルに対して大負荷を引き起こす可能性がある。一方、小さなパケットサイズを用いた場合には、タイムクリティカルなより大きなメッセージは、直ちにＳＤＢとして送信しなくてもよい。

従って、時間制限のあるメッセージが遅延されないように、何のメッセージをＳＤＢで伝達する必要があるかを判断するメカニズムが求められている。

開示した実施形態は、ターゲットの移動局が指定された情報をショートデータバーストとして送信するように指定されているか否かを判断する、新規で改良された方法及び装置を提供する。この方法は、ターゲットの移動局に宛先が定められた情報パケットを受信することと、この受信した情報パケットを構文解析することと、この受信した情報パケットをショートデータバーストメッセージとして送信するように指定されているか否かを判断することとを含む。

さらに、開示した実施形態は、情報を、無線通信ネットワークにおけるショートデータバースト（ＳＤＢ）に指定する、新規で改良された方法及び装置を提供する。この方法は、情報をデータグラムに入れることであって、このデータグラムがヘッダ部分を含むことと、無線通信インフラストラクチャが、このデータグラムに入れられた前記情報を、ＳＤＢメッセージとして宛先へ転送するように、前記データグラムのヘッダ部分を指定することとを含む。

別の態様において、ターゲットの移動局に宛先が定められた情報を伝達する装置は、メモリユニットと、レシーバと、トランスミッタと、これらのメモリユニット、レシーバ及びトランスミッタと通信可能に結合されたプロセッサとを含む。このプロセッサは、上述した方法を実行する命令を実行することが可能である。

本発明の特徴及び効果は、図面と共に解釈すれば、以下に記載したか維持した実施形態の詳細な説明からより明白になるであろう。

いくつかの実施形態を詳細に説明する前に、本発明の範囲は、以下の説明に記載された構成要素または図面に示された構成要素の構造及び構成の詳細に限定すべきではないことを理解すべきである。また、本明細書において用いられる表現及び用語が、説明目的のものであり、かつ限定するものと考えるべきではないことを理解すべきである。

図１は、休眠パケットデータセッション中の、携帯電話が終点になるショートデータバースト情報配信のコールフロー図を示す。休眠状態中、ポイントツーポイントプロトコル（ＰＰＰ）セッションは維持されるが、情報チャネルは、非アクティブにされる。例えば、ＩＰデータグラムとしてＰＤＳＮ１０２に着いた情報は、ステップ（ｂ）において、ＢＳＣ／ＰＣＦ１０４へ送信される。次に、ＢＳＣ／ＰＣＦ１０４は、ステップ（ｃ）において、前記情報をどのように送信するかに関する判断を行う。ステップ（ｃ）において、ＢＳＣ／ＰＣＦ１０４は、前記受信した情報を構文解析する。前記受信したＩＰデータグラムのヘッダ部分のサービス種別（ＴＯＳ）が、ＳＤＢ配信に指定されている場合には、ＢＳＣ／ＰＣＦ１０４は、ステップ（ｄ）からステップ（ｇ）を用いて、前記情報をＳＤＢとして配信する。ＢＳＣ／ＰＣＦ１０４が、前記受信した情報をＳＤＢとして送信すべきであると判断した場合には、ＢＳＣ／ＰＣＦ１０４は、まず、ステップ（ｄ）において、通常のページングを実行して、ターゲットの移動局を捜し出す。続いて、前記情報は、ステップ（ｆ）において、共通チャネルを介してＳＤＢとして、例えば、移動局（ＭＳ）１０６へ送信される。前記ターゲットの移動局は、ステップ（ｅ）において受信された前記移動局の通常ページングの応答メッセージで識別することができる。ＢＳＣ／ＰＣＦ１０４が、前記受信した情報をＳＤＢとして送信すべきではないと判断した場合には、ＢＳＣ／ＰＣＦ１０４は、移動局制御装置（ＭＳＣ）１０８に依存して、例えば、通常ページング処理手順を介して、ターゲットの移動局を捜し出し、情報チャネルを再確立した後、前記情報を送信する。この処理手順は、図示していない。

一実施形態において、グループコールサーバ１１０等のネットワークエンティティは、ターゲットＭＳ１０６に宛先が定められた情報をＩＰデータグラムとして生成してもよい。ＰＤＳＮ１０２は、受信したＩＰデータグラムをＢＳＣ／ＰＣＦ１０４へ送信する前に、前記受信したＩＰデータグラムを埋め込む。図２は、一実施形態によるＩＰデータグラムフレーム化プロセスを示す。ＩＰデータグラム２０２は、ヘッダ部と情報部とを含んでもよい。ＰＤＳＮ１０２がＭＳ１０６のＰＰＰピアである場合、ＰＤＳＮ１０２は、受信したＩＰデータグラム２０２を、ＰＰＰヘッダ２０４及びＰＰＰトレーラ２０６の内側に埋め込んで、ＰＰＰフレーム２０８を形成してもよい。

一実施形態によれば、ＴＩＡ／ＥＩＡ／ＩＳ−２００１、「ｃｄｍａ２０００ アクセスネットワークインタフェースのＩＯＳ（Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）」、２００１年８月、（ＩＯＳｖ４．１）に説明されているように、情報をＢＳＣ／ＰＣＦ１０４へ送信する前に、ＰＤＳＮ１０２は、ＧＲＥ（ｇｅｎｅｒｉｃ ｒｏｕｔｉｎｇ ｅｎｃａｐｓｕｌａｔｉｏｎ）ヘッダ２１０及びＩＰヘッダ２１２を受信したＰＰＰフレーム２０８に付加して、ＧＲＥパケット２１４を形成する。ＧＲＥパケット２１４は、ＩＰペイロードとして処理され、例えば、Ａ１０接続でＢＳＣ／ＰＣＦ１０４にアドレス指定される。

ＧＲＥパケット２１４を受信した後、ＢＳＣ／ＰＣＦ１０４は、ＧＲＥヘッダ２１０及びＩＰヘッダ２１２を受信したＧＲＥパケット２１４から取り除き、エアインタフェースを介して情報をターゲットのＭＳ１０６へ送信する前に、適当なヘッダを付加してもよい。上述したように、パケットデータセッションが休眠状態の場合、ＢＳＣ／ＰＣＦ１０４は、本明細書において、後述するように、受信したＰＰＰフレーム２０８を検査して、ＩＰデータグラム２０２を構文解析するのを始める前に、ＩＰデータグラム２０２のヘッダ部が始まる箇所を判断する必要がある。

単一のＧＲＥパケット２１４は、ＴＩＡ／ＥＩＡ／ＩＳ−８３５、「無線ＩＰネットワーク規格」、２００１年１２月６日、に指定されているように、不完全なＰＰＰフレームまたは多数のＰＰＰフレームを含むことが可能である。このような場合、前記規格は、ＧＲＥヘッダ２１０に含まれているシーケンス番号フィールドを、パケットの順次配信を保障するのに用いることができることを指定している。ＧＲＥヘッダ２１０のシーケンス番号フィールドが使用可能な場合、ＢＳＣ／ＰＣＦ１０４は、前記ＰＰＰフレームを構文解析する前に、前記受信したＧＲＥパケットを再び順序付ける。

図３は、ＢＳＣ／ＰＣＦ１０４及び移動局３０６の実施形態の単純化したブロック図であり、前記ＢＳＣ／ＰＣＦ及び移動局は、様々な開示実施形態を実施することが可能である。特定の通信の場合、音声データ、パケットデータおよび／またはメッセージは、エアインタフェース３０８を介して、ＢＳＣ／ＰＣＦ１０４と移動局３０６との間で交換することができる。ＢＳＣ／ＰＣＦ１０４と移動局３０６との間で通信セッションを確立するのに用いるメッセージ、登録及びページングメッセージ、およびデータ伝送を制御するのに用いるメッセージ（例えば、出力制御、データレート情報、肯定応答等）等の様々な種類のメッセージを送信することができる。これらのメッセージの一部を、以下にさらに詳細に説明する。

リバースリンクの場合、ＢＳＣ／ＰＣＦ３０６において、（例えば、データソース３１０からの）音声および／またはパケットデータ並びに（例えば、コントローラ３３０からの）メッセージが、送信（ＴＸ）データプロセッサ３１２へ供給され、このデータプロセッサは、１つ以上の符号化スキームを用いて前記データ及びメッセージをフォーマット化及び符号化して、符号化データを生成する。各符号化スキームは、巡回冗長検査（ＣＲＣ）、畳み込み、ターボ、ブロック及び他の符号化のいずれかの組合せを含んでもよく、あるいは符号化を含まなくてもよい。前記音声データ、パケットデータ及びメッセージは、異なるスキームを用いて符号化してもよく、異なる種類のメッセージは、異ならせて符号化してもよい。

次に、上記符号化したデータは、変調器（ＭＯＤ）３１４へ供給されて、さらに処理される（例えば、カバーされ、単ＰＮシーケンスで拡散され、およびユーザ端末に割当てられた長ＰＮシーケンスでスクランブルされる）。そして、前記変調されたデータは、送信機ユニット（ＴＭＴＲ）３１６へ供給されて、信号を調整し（例えば、１つ以上のアナログ信号に変換され、増幅され、フィルタリングされ、直交変調されて）、リバースリンク信号を生成する。このリバースリンク信号は、デュプレクサ（Ｄ）３１８を介してルーティングされ、アンテナ３２０を介してＢＳＣ／ＰＣＦ３０４へ送信される。

ＢＳＣ／ＰＣＦ３０４において、上記リバースリンク信号は、アンテナ３５０によって受信され、デュプレクサ３５２を介してルーティングされて、受信機ユニット（ＲＣＶＲ）３５４へ供給される。ＢＳＣ／ＰＣＦ３０４は、移動局３０６から登録情報及びステータス情報、例えば、移動局ロケーション情報を受信してもよい。受信機ユニット３５４は、前記受信信号を調整（例えば、フィルタリング、増幅、ダウンコンバート及びディジタル化）して、サンプルを生成する。復調器（ＤＥＭＯＤ）３５６は、前記サンプルを受取って処理し（例えば、逆拡散し、デカバーし、パイロット復調し）、復元したシンボルを生成する。復調器３５６は、受信信号の多数のインスタンスを処理して、結合シンボルを生成するレイク受信機を実施することが可能である。次いで、受信（ＲＸ）データプロセッサ３５８は、前記シンボルを復号して、リバースリンクによって送信されたデータ及びメッセージを復元する。前記復元された音声／パケットデータは、データシンク３６０へ供給され、前記復元されたメッセージは、コントローラ３７０へ供給してもよい。コントローラ３７０は、移動局からなる群をページングする命令を含んでもよく、前記ページングは、前記移動局の移動性に基づいてもよい。復調器３５６及びＲＸデータプロセッサ３５８による処理は、基地局３０６で実行される処理と相補的である。復調器３５６及びＲＸデータプロセッサ３５８は、さらに、多数のチャネル、例えば、Ｒ−ＦＣＨ（ｒｅｖｅｒｓｅ ｆｕｎｄａｍｅｎｔａｌ ｃｈａｎｎｅｌ）やＲ−ＳＣＨ（ｒｅｖｅｒｓｅ ｓｕｐｐｌｅｍｅｎｔａｌ ｃｈａｎｎｅｌ）を介して受信した多数のトランスミッションを処理するように作動してもよい。また、トランスミッションは、多数の移動局から同時であってもよく、各トランスミッションは、Ｒ−ＦＣＨ、Ｒ−ＳＣＨまたはそれら両方によって伝送することができる。

フォワードリンク上で、ＢＳＣ／ＰＣＦ３０４において、（例えば、データソース３６２からの）音声および／またはパケットデータ並びに（例えば、コントローラ３７０からの）メッセージは、送信（ＴＸ）データプロセッサ３６４によって処理され（例えば、フォーマット化され、および符号化され）、さらに変調器（ＭＯＤ）３６６によって処理され（例えば、カバーされ、および拡散され）、送信機ユニット（ＴＭＴＲ）３６８によって調整され（例えば、アナログ信号に変換され、増幅され、フィルタリングされ、直交変調され）、フォワードリンク信号を生成する。このフォワードリンク信号は、デュプレクサ３５２を介してルーティングされて、アンテナ３５０を介してＢＳＣ／ＰＣＦ３０４へ送信される。フォワードリンク信号は、ページング信号を含む。

ＢＳＣ／ＰＣＦ３０６において、上記フォワードリンク信号は、アンテナ２２０によって受信され、デュプレクサ３１８を介してルーティングされて、受信機ユニット３２２へ供給される。受信機ユニット３２２は、この受信信号を調整（例えば、ダウンコンバート、フィルタリング、増幅、直交変調及びディジタル化）して、サンプルを生成する。このサンプルは、復調器３２４によって処理（例えば、逆拡散、デカバー及びパイロット復調）されてシンボルを生成し、このシンボルは、受信データプロセッサ３２６によってさらに処理（例えば、復号及びチェック）されて、前記フォワードリンクによって送信されたデータ及びメッセージを復元する。前記復元されたデータはデータシンク３２８へ供給され、前記復元されたメッセージは、コントローラ３３０へ供給されてもよい。コントローラ３３０は、ＢＳＣ／ＰＣＦ３０６を登録する命令を含んでもよく、この登録は、上記移動局の移動性に基づいてもよい。

（ＩＰ ＴＯＳビット）
図４は、一実施形態、例えば、ＩＰバージョン４（ＩＰｖ４）による、図２に示すＩＰデータグラム２０２のヘッダ部を示す。ＩＰ ＴＯＳフィールド４０２は、ＩＰデータグラム２０２のヘッダ部内の第２のバイトである。ＩＰｖ４に対するサービス定義には、３つの幅広く受容されるＴＯＳビットのマッピングがある。第１のマッピングは、ＲＦＣ７９１、「インターネットプロトコル」、１９８１年９月に定義されている。このＲＦＣにおいて、前記ＴＯＳフィールドは、図５に示すように、５つのサブフィールドを有する。３つの「優先度」ビットは、０（通常優先度）から７（ネットワーク制御）の値を有するＩＰデータグラム優先度を指定し、送信者が各ＩＰデータグラムの重要度を表わすことを可能にする。次の３つのビットは、「Ｄ」、「Ｔ」及び「Ｒ」である。これらのビットは、ＩＰデータグラムのトランスポートの種類を指定する。最後の２ビットは、リザーブビットである。一実施形態において、グループコールサーバ１１０は、ＩＰデータグラムのＴＯＳフィールドのリザーブビットの一方または両方を用いて、例えば、図３に示すような無線通信インフラストラクチャが、前記ＩＰデータグラムをＳＤＭメッセージとしてターゲットの移動局へ送信することを指定する。

図６は、ＲＦＣ１４３９、「インターネットプロトコルスーツにおけるサービス種別」、１９９９年７月で定義されている、サービス定義のためのＴＯＳビットの別のマッピングを示す。このＲＦＣは、ＲＦＣ７９１における定義を更新しているが、多くの文献及び実施は、いまだ元のＲＦＣ７９１における定義を参照している。ＲＦＣ１４３９において、上記優先度サブフィールドは、ＲＦＣ７９１で定義されているものと同じである。次の４つのビットは、ＴＯＳビットとみなされ、最後のビットは、０でなければならない（ＭＢＺ）ビットとみなされる。ＲＦＣ１４３９は、Ｄ、Ｔ、Ｒビットを４ビットＴＯＳフィールドとして再定義する。ＲＦＣ１４３９は、最後のビットを利用するインターネットプロトコルの試みに関係しない限り、データグラムの発信者が、前記最後のビットを０に設定することを指定する。すなわち、このことにより、前記最後のビットのみが未使用のビットとして残される。一実施形態においては、グループコールサーバ１１０は、上記ＴＯＳフィールドのリザーブビットを用いて、図３に示すような無線通信インフラストラクチャが、例えば、前記ＩＰデータグラムをＳＤＭメッセージとしてターゲットの移動局へ送信することを指定する。

図７は、ＲＦＣ２４７４、「ＩＰｖ４及びＩＰｖ６ヘッダにおけるＤＳフィールド（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｆｉｅｌｄ）の定義」、１９９８年１２月に説明されているように、インターネット技術標準化委員会（ＩＥＴＦ）のディファレンシャルサービスフレームワークによって定義された第３のサービス定義を示す。この定義は、６ビットのディファレンシャルサービスコードポイント（ＤＳＣＰ）を用いて、前記ＩＰデータグラムに対するＰＨＢ（ｐｅｒ ｈｏｐ ｂｅｈａｖｉｏｒ）処理を表わす。最後の２ビットは、リザーブビットである。一実施形態において、グループコールサーバ１１０は、ＴＯＳフィールドの前記リザーブビットの一方または両方を用いて、例えば、図３に示すような無線通信インフラストラクチャが、前記ＩＰデータグラムをＳＤＭメッセージとしてターゲットの移動局へ送信することを指定する。

図８は、ＲＦＣ２４６０、「インターネットプロトコル、バージョン６（ＩＰｖ６）仕様」、１９９８年１２月による、ＩＰｖ６の場合のＩＰデータグラム２０２（図２）のヘッダ部を示す。トラフィッククラス８０２は、図８に示すように、４ビットのバージョンフィールド８０４のすぐ後の１バイトフィールドである。ＲＦＣ２４６０は、８ビットのトラフィッククラス８０２フィールドをどのように使用するかに関しては、オープンのままである。しかし、ＩＰｖ４のサービス定義と同様にＩＰｖ６のサービス定義を採用しようとする継続中のＩＥＴＦの努力がある。

図６に戻って、ＩＰｖ４のヘッダ部の最初の７ビットをサービス定義マッピングに使用できると仮定すると、最後のビットは、ＢＳＣ／ＰＣＦ１０４における受信情報をＳＤＢメッセージとしてターゲットのＭＳ１０６へ送信すべきであることを表わすのに用いることができる。ＲＦＣ１８１２、「ＩＰバージョン４ルータに対する要求事項」、１９９５年６月は、ゼロでない値が上記リザーブビットに使用されている場合、ＩＰｖ４ルータに対して、パケットをドロップしないように要求を出している。現在のＲＦＣｓは、他の新たなプロトコルが前記リザーブビットを使用してもよいか否かを指定していない。そのため、ＢＳＣ／ＰＣＦ１０４は、前記リザーブビットを０以外に指定した休眠パケットデータセッション中に、ＩＰデータグラムを受信することが可能である。また、ＩＰｖ６ルータが、どのようにＩＰｖ６ヘッダにおける８ビットのトラフィッククラスフィールドの最後のビットを処理すべきかを表わすＲＦＣ要求事項はない。

本明細書の残りに対しては、「ＩＰ ＴＯＳフィールド」という用語は、考えられる処理スキームにより、ＩＰｖ４ ＴＯＳフィールド４０２及びＩＰｖ６トラフィッククラスフィールド８０２の両方を表わすのに使用される。一実施形態によれば、グループコールサーバは、前記ＴＯＳフィールドの未使用のビットを、ＳＤＢ配信を表わすメカニズムとして利用する。例えば、ＳＤＢとして送信する必要があるメッセージの場合、グループコールサーバは、前記ＩＰ ＴＯＳフィールドの最後のビットを、０ｘ０１の値に設定する。

（ポイントツーポイントプロトコル）
上述したように、ＧＲＥパケット２１４（図２）は、多数のＰＰＰフレームまたは不完全なＰＰＰフレームを含んでもよい。ＢＳＣ／ＰＣＦ１０４は、受信したＧＲＥパケット２１４からＧＲＥヘッダ２１０及びＩＰヘッダ２１２を抽出し、前記情報をＲＬＰ（ｒａｄｉｏ ｌｉｎｋ ｐｒｏｔｏｃｏｌ）フレームとして再パッケージ化し、前記ＲＬＰフレームを上記エアインタフェースを介してターゲットのＭＳ１０６へ送信する。前記ＩＰ ＴＯＳフィールドを構文解析するＢＳＣ／ＰＣＦ１０４の場合、ＢＳＣ／ＰＣＦ１０４は、ＰＰＰフレーム２０８の始めと終わりを検知する。この部分において、我々は、ＴＩＡ／ＥＩＡ／ＩＳ−８３５、「無線ＩＰネットワーク規格」、２００１年１２月６日に指定されているように、前記ＰＰＰフレームの構造を検査し、リンク制御段階の間に取り決めることができるフィールドを識別する。ＰＰＰに関する詳細は、ＲＦＣ１６６１、「ポイントツーポイントプロトコル（ＰＰＰ）」、１９９４年７月で見つけることができる。

図９は、ＲＦＣ１６６２、「ハイレベルデータリンク制御手順（ＨＤＬＣ）のようなフレーム化におけるＰＰＰ」、１９９４年７月による、ＰＰＰフレーム２０８のＨＤＬＣフレーム構造を示す。フィールド９０２からフィールド９０８は、ＰＰＰフレーム２０８のＰＰＰヘッダ２０４に関連し、フィールド９１０は、ＰＰＰフレーム２０８のＩＰデータグラム２０２に関連し、フィールド９１２は、ＰＰＰフレーム２０８のＰＰＰトレーラ２０６に関連する。最初のフィールド９０２は、ＰＰＰフレーム２０８の始まりおよび／または終わりを示す「７Ｅ」フラグである。前記フラグの後に、ＨＤＬＣフレーム９０４、９０６、９０８が続く。

ＲＦＣ１６６２によれば、アドレスフィールド９０４は、８ビットバイトの０ｘＦＦに設定することができ、制御フィールド９０６は、８ビットバイトの０ｘ０３に設定することができる。ＨＤＬＣ情報フィールドは、プロトコルフィールド９０８と、ＩＰデータグラム（ＰＰＰペイロード）９１０とを含む。ＩＰサービスの場合、プロトコルフィールド９０８は、ＩＰデータグラム９１０が後に続く、０ｘ００２１の値を有する２つの８ビットバイトを含む。前記ＨＤＬＣパケットの最後のフィールドは、フレームチェックシーケンス（ＦＣＳ）９１２であり、前記ＦＣＳは、２つまたは４つの８ビットバイトを含んでもよい。各ＰＰＰフレームは、フラグシーケンスを用いて始まりかつ終了し、１つのフラグシーケンスは、２つのフレームの間で用いることができる。エンドフラグシーケンスは、図９には示していない。

一実施形態によれば、リンク制御プロトコル（ＬＣＰ）は、標準的なＨＤＬＣのようなフレーム構造への変更を処理し、これは上述した。ＰＰＰピアは、アドレスフィールド９０４及び制御フィールド９０６を圧縮するように処理してもよい。圧縮が使用可能な場合、２つの８ビットバイトは除去される。また、ＰＰＰピアは、プロトコルフィールド９０８を１つのバイト、例えば、０ｘ２１に圧縮するように処理してもよい。別の処理可能なパラメータは、ＦＣＳフィールド９１２における巡回冗長検査（ＣＲＣ）のためのビット数である。ＰＰＰピアは、１６ビットＣＲＣまたは３２ビットＣＲＣを処理してもよい。

ＰＰＰは、情報が送信されて、制御文字の透過性が実現される前に、ビットスタッフィングを実行してもよい。制御拡張８ビットバイトは、０ｘ７Ｄになるように選択してもよい。ＲＦＣ１６６２は、最低限でも、フラグシーケンス、例えば、０ｘ７Ｅ、及び制御拡張８ビットバイト、例えば、０ｘ７Ｄへの実施を要求する。ＦＣＳ計算の後、上記トランスミッタは、前記２つのフラグシーケンス間の全体のフレームを検査し、フラグシーケンス拡張を実行する。０ｘ００と０ｘ１Ｆの間の値（包含的）に値０ｘ７Ｄ及び０ｘ７Ｅを加えたものは、ＰＰＰフレームを送信したときに、前記トランスミッタによって拡張することができる。

非同期制御文字マップ（ＡＣＣＭ）は、０ｘ００から０ｘ１Ｆの３２のＡＳＣＩＩ制御文字に対する文字拡張を使用可能にし（ビットセット）、または、使用不能にする（ビットクリア）４つの８ビットバイトのビットマップを有するＬＣＰオプションである。例えば、前記ＡＣＣＭ値の最初の８ビットバイトは、０ｘ１９から０ｘ１Ｆの制御文字のためのビットを有し、ＭＳＢが０ｘ１０を示し、かつＬＳＢが０ｘ１８を示す。２番目の８ビットバイトは、文字０ｘ１０から０ｘ１７のためのビットを有する。値０ｘＦＦＦＦＦＦＦＦは、全ての制御文字が、「ＰＰＰデザイン、実施及びデバッギング」（Ｃａｒｌｓｏｎ，Ｊａｍｅｓ，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，２００２）に従って拡張されることを示す。０ｘ００００００００のＡＣＣＭ値は、０ｘ００と０ｘ１Ｆの値のＡＳＣＩＩ文字が拡張されないことを示す。各フラグシーケンス、制御拡張８ビットバイト及びＡＣＣＭを送信するときにフラグが立てられる８ビットバイトは、８ビットバイト０ｘ２０で排他的論理和される元の８ビットバイトが後に続く、制御拡張８ビットバイト、例えば、０ｘ７Ｄと置換される。

単純なＩＰ動作及びモバイルＩＰ動作の両方に対して、ＴＩＡ／ＥＩＡ／ＩＳ−８３５、「無線ＩＰネットワーク規格」、２００１年１２月６日は、両モバイル及びＰＤＳＮのために拡張する制御を指定する。ＰＤＳＮの場合、前記規格は、前記ＰＤＳＮが、０ｘ００００００００のＡＣＣＭ値を提案することにより、最少数の拡張文字によって制御文字マッピングを処理することを要求する。一方、前記規格は、上記ＭＳが制御文字マッピングを処理する場合、前記ＭＳが、０ｘ００００００００のＡＣＣＭを処理することにより、最少数の拡張を試みることを推奨する。すなわち、ＢＳＣ／ＰＣＦ１０４は、ＰＤＳＮ１０２からＰＰＰを受信することが可能であり、この場合、上記フラグシーケンスだけではなく、０ｘ００から０ｘ１Ｆの文字も拡張される。

ＢＳＣ／ＰＣＦ１０４がＰＤＳＮのＰＰＰピアでない場合、ＢＳＣ／ＰＣＦ１０４は、どのＬＣＰパラメータ、例えば、アドレスフィールド９０４、制御フィールド９０６及びプロトコルフィールド９０８が、ＭＳ１０６とＰＤＳＮ１０２との間で処理されるかに関して認識しなくてもよい。すなわち、ＰＰＰフレーム化を判断することのほかに、ＢＳＣ／ＰＣＦ１０４は、ＩＰ ＴＯＳビットを構文解析するために、どのフィールドが圧縮され、かついずれかの文字が拡張されて、ＩＰデータグラム２０２のヘッダ部の始まりを正しく認識しているか否かを判断する。次のセクションにおいては、ＢＳＣ／ＰＣＦ１０４がＰＰＰフレームを構文解析するために用いるアルゴリズムについて説明する。

（ＰＰＰフレーム構文解析アルゴリズム）
上述したように、ＢＳＣ／ＰＣＦ１０４に到達したＧＲＥパケット２１４は、多数のＰＰＰフレーム及び不完全なフレームを含んでもよく、このことは、ＢＳＣ／ＰＣＦ１０４が、休眠状態の間に、パケットデータストリームを構文解析して、ＰＰＰフレームフラグシーケンスを判断することを必要とする。ＢＳＣ／ＰＣＦ１０４が、情報ストリームを構文解析して、ＩＰデータグラム２０２のヘッダ部の始まりを判断するのに用いるアルゴリズムを図１０に示す。

前記アルゴリズムが、正当に認められていない文字のシーケンスを検知した場合、前記アルゴリズムは、ＰＰＰフレーム２０４がどこで始まるか分からないため、次のＰＰＰフレームの始まりへスキップする。このイベントは、不適当なＰＰＰ実施の結果として、あるいは、１つ以上のエラーがデータストリームに存在する場合に行われてもよい。前記アルゴリズムは、空白でないＰＰＰフレームを見つけるまで、「０ｘ７Ｅ」フラグシーケンスの存在を継続的にチェックする。具体的には、ステップ１００２において、最初の０ｘ７Ｅフラグを見つけた後、ステップ１００４において、次のバイトが、０ｘ７Ｅフラグに関してチェックされる。しかし、空白でないＰＰＰフレームが検出されたことを意味する、最初の０ｘ７Ｅフラグを含むバイトの後のバイトが０ｘ７Ｅフラグを含まない場合には、前記プロセスは、ステップ１００８において、アドレスフィールド９０４をチェックする。

一実施形態において、アドレスフィールド９０４及び制御フィールド９０６は、圧縮及びミッシングしてもよい。また、プロトコルフィールド９０８も、０ｘＦＦの値を有するこれの２番目のバイトのみが存在するように圧縮してもよい。このような場合、ＲＦＣ１６６２によれば、２つの８ビットバイトのプロトコルフィールド９０８の２番目のバイトは、０ｘＦＦの値を有するアドレスフィールド９０４として誤って解釈されることを避けるために、０ｘＦＦに設定すべきではない。

ステップ１００８でのチェック及びアドレスフィールド９０４に対応する０ｘＦＦを見つけることに続いて、ＢＳＣ／ＰＣＦ１０４は、ステップ１０１０において、次のバイトが、制御フィールド９０６に対応して、０ｘ０３を含むか否かをチェックする。ステップ１０１０において、次のバイトが０ｘ０３を含まないと判断された場合、ＢＳＣ／ＰＣＦ１０４は、処理の結果が、制御フィールド値０ｘ０３のためのＡＣＣＭ処理になったか否かをチェックする。ＡＣＣＭ処理の下で、ＢＳＣ／ＰＣＦ１０４は、制御拡張バイト、例えば、０ｘ７Ｄを送信し、その上、送信すべき元の情報のバイトの排他的論理和（ＸＯＲ）の結果を含むバイト、例えば、０ｘ０３を０ｘ２０とともに送信する。

ステップ１０１２において、ＢＳＣ／ＰＣＦ１０４は、まず、０ｘ７Ｄの存在をチェックし、見つかった場合には、０ｘ２３の存在をチェックし、これは、ステップ１０１４において、０ｘ０３を０ｘ２０で排他的論理和した結果である。制御フィールド９０６が検出されないことを意味する、０ｘ７Ｄまたは０ｘ２３のいずれかが見つからない場合には、上記プロセスは、上述したステップ１００２及びステップ１００４と同様に、ステップ１０１６及びステップ１０１８において、新たなＰＰＰフレームの始まりをチェックする。ステップ１００８における答えが「ｎｏ」である場合には、アドレスフィールド９０４が圧縮されて存在していないことに注意すべきである。

ステップ１０１０またはステップ１０１４のいずれかにおいて、制御フィールド９０６に対応する０ｘ０３の値が、直接に、またはＡＣＣＭ処理を通じて検出されたことを意味する、結果がｙｅｓの場合には、上記プロセスは、プロトコルフィールド９０８の最初のバイトに相当する、０ｘ００の存在のための次のバイトをチェックする。ＢＳＣ／ＰＣＦ１０４は、まず、処理の結果が、ＡＣＣＭによってプロトコルフィールド９０８へ送信されているか否かをチェックする。ステップ１０２０において、プロトコルフィールド９０８がＡＣＣＭ処理を介して送信される予定がないことを意味する、０ｘ７Ｄバイトが見つからない場合、ＢＳＣ／ＰＣＦ１０４は、ステップ１０２２において、次のバイトが、プロトコルフィールド９０８の最初のバイトに相当する０ｘ００を含んでいるか否かをチェックする。

ＢＳＣ／ＰＣＦ１０４が、ステップ１０２２において、プロトコルフィールド９０８の最初のバイトに相当する０ｘ００を見つけた後、ＢＳＣ／ＰＣＦ１０４は、処理の結果が、ＡＣＣＭ処理を介してプロトコルフィールド９０８の２番目のバイトを送信しているか否かをチェックする。ステップ１０２４において、プロトコルフィールド９０８がＡＣＣＭ処理を介して送信される予定がないことを意味する、０ｘ７Ｄバイトが見つからなかった場合、ＢＳＣ／ＰＣＦ１０４は、ステップ１０２６において、次のバイトが、プロトコルフィールド９０８の２番目のバイトに相当する０ｘ２１を含んでいるか否かをチェックする。ステップ１０２６において、ステップ１０２２において見つかった０ｘ００に続く０ｘ２１が見つかった場合、上記プロセスは、本明細書において後述するように、ＩＰデータグラム９１０のヘッダ部を構文解析するステップ１０２８で終了する。

ステップ１０２４において、プロトコルフィールド９０８がＡＣＣＭ処理を介して送信される予定があることを意味する、０ｘ７Ｄバイトが見つかった場合、ＢＳＣ／ＰＣＦは、ステップ１０３０において、次のバイトが、ＡＣＣＭ処理に従って、プロトコルフィールド９０８の２番目のバイト、例えば、０ｘ２０で排他的論理和した０ｘ２１の２番目のバイトである０ｘ０１を含むか否かをチェックする。ステップ１０２２で見つかった０ｘ００に続いて、ステップ１０３０において、０ｘ０１が見つかった場合、上記プロセスは、ＩＰデータグラム９１０のヘッダ部を構文解析するステップ１０２８で終了する。

プロトコルフィールド９０８の最初のバイト、例えば、０ｘ００を探すステップ１０２０へ戻って、ＢＳＣ／ＰＣＦ１０４が０ｘ７Ｄを見つけた場合には、次のバイトが０Ｘ２０に対してチェックされ、これは、プロトコルフィールド９０８の最初のバイト、例えば、ステップ１０３２において、０Ｘ２０で排他的論理和された０Ｘ００である。０ｘ００が、プロトコルフィールド９０８の最初のバイトで見つかったことを意味する、ステップ１０３２での結果がｙｅｓの場合、上記プロセスは、上述したように、ステップ１０２４に続き、プロトコルフィールド９０８の２番目のバイト、例えば、０ｘ２１の存在を探す。

ステップ１０３２において、０ｘ７Ｄを含むバイトが続くバイトが、プロトコルフィールド９０８の最初のバイトに相当する値、例えば、０ｘ００を含まない場合には、ＢＳＣ／ＰＣＦ１０２は、ステップ１０３４において、前記バイトが、プロトコルフィールド９０８の２番目のバイト、例えば、０ｘ２０で排他的論理和された０ｘ２１である０ｘ００を含むか否かを判断する。前記結果がｙｅｓの場合、上記プロセスは、ステップ１０２８で終了する。プロトコルフィールド９０８のチェックの結果が、プロトコルフィールド９０８の２番目のバイト、例えば、０ｘ２１が見つからない場合に終了すると、前記プロセスは、ステップ１０１６で終了して、次のＰＰＰフレームを探す。

ステップ１０２２における結果が、プロトコルフィールド９０８の最初のバイトが見つからなかったことを意味する「ｎｏ」の場合には、このフィールドが圧縮されることに注意すべきである。それに伴って、これの２番目のバイト、例えば、０ｘ２１の存在のみが、ステップ１０３６でチェックされる。

（ＩＰデータグラム構文解析アルゴリズム）
ＰＰＰフレーム構文解析アルゴリズムが、一旦、前記アルゴリズムが、ＩＰデータグラム９１０の始まりを良好に検出したことを示す、「ＩＰデータグラムの構文解析」状態１０２８に達すると、ＢＳＣ／ＰＣＦ１０４は、図１１に示す一実施形態によるアルゴリズムを用いて、ＩＰデータグラム９１０のヘッダ部４００（図４）または８００（図８）を構文解析し、ＳＤＢマーキングが存在するかを検出する。一実施形態において、前記構文解析アルゴリズムは、３２ビットのヘッダ部４００及び８００の４つのバイトが、次の順番、すなわち、まずビット０から７、ビット８から１５、ビット１６から２３、最後にビット２４から３１の順番で送信されると仮定する。この順番は、ビッグエンディアンバイト順と呼ばれ、これは、ＴＣＰ／ＩＰヘッダがネットワークを通過するときに、前記ＴＣＰ／ＩＰヘッダの全ての２進整数に用いられるバイト順である。この順序付けは、ネットワークバイトオーダーとも呼ばれる。ＢＳＣ／ＰＣＦ１０４が、２進整数を他のフォーマット、例えば、リトルエンディアンバイト順で格納した場合、ＢＳＣ／ＰＣＦ１０４は、上記アルゴリズムを実行する前に、前記ヘッダ値をネットワークバイトオーダーに変換し、または、前記アルゴリズムが正しく実行されるように、適切なマッピングを実行する。

ＩＰｖ４ ＴＯＳフィールド４０２（図４）及びＩＰｖ６トラフィッククラス８０２（図８）は、４ビットバージョンフィールドでスタートする。前記４ビットバージョンフィールドは、ＩＰバージョン番号を含む。ＩＰｖ４及びＩＰｖ６バージョンの場合、前記バージョン番号は、それぞれ、０ｘ０４及び０ｘ０６である。前記バージョン番号を判断する場合、図１１に示すアルゴリズムは、ＩＰデータグラム９１０のヘッダ部の最初のバイトが、ＡＣＣＭ処理に従って、あるいは、直接、送信されるか否かをチェックする。ステップ１１０２において、前記ヘッダ部の最初のバイトが、前記ヘッダ部の最初のバイトが、ＡＣＣＭに従って処理されることを意味する、０ｘ７Ｄを含むことが分かった場合、前記アルゴリズムは、ステップ１１０４において、次のバイトを０ｘ２０で排他的論理和して、０ｘ２０によるＸＯＲ関数を不適当なものとし、元の値を復元する。

ステップ１１０６において、ステップ１１０２から受取った、前記ＩＰヘッダの最初のバイトの元の内容、または、ステップ１１０４から受取った結果は、０ｘＦ０で刺激的に論理積がとられ、前記ヘッダ部の最初の４ビットが読み取られる。ステップ１１０８において、ステップ１１０６の結果が０ｘ６０に対してチェックされ、前記ヘッダ部の最初の４ビットが、前記バージョン番号がＩＰｖ６であることを示しているか否かが判断される。

ステップ１１０８の結果が、前記バージョンがＩＰｖ６であることを示している場合、上記プロセスは、ステップ１１１０、１１１２、１１１４及び１１１６に続いて、ＳＤＢマーキングを表わす、トラフィッククラス８０２（図８）の５番目のビットが設定されているか否かが判断される。ステップ１１１６の結果が、前記ＳＤＢビットが設定されていることを示す場合、前記プロセスは、ステップ１１１８で終了する。

１１２０を続けて、結果が、上記ヘッダ部のバージョン番号がＩＰｖ４であることを示す場合、上記プロセスは、ステップ１１２２、１１２４、１１２６及び１１２８に続いて、ＳＤＢマーキングを表わす、ＴＯＳフィールド４０２（図４）の８ビットが設定されているか否かが判断される。ステップ１１２８の結果が、前記ＳＤＢビットが設定されていることを示す場合、前記プロセスは、ステップ１１１８で終了する。

一旦、ＳＤＢマーキングが見つかると、ＢＳＣ／ＰＣＦ１０４は、次のフラグシーケンスを検出して、検査によって、ＰＰＰの最後を見つける。最初のＩＰデータグラムがＳＤＢマーキングを含む２つ以上のＩＰデータグラムを、ＢＳＣ／ＰＣＦ１０４に着いた単一のＰＰＰフレーム内に埋め込んでおいてもよい。また、ＳＤＢマーキングを伴うＩＰデータグラムは、予想サイズを超えてもよい。上記２つのイベントのうちのいずれか一方が発生した場合、受信メッセージが大きいことが予想される。大きなＳＤＢメッセージが共通チャネルを介して送信されることを防ぐために、休眠パケットデータセッション中に、追加的なチェックを実行してもよい。ステップ１１３０において、考慮中のＰＰＰフレームの最後が検出され、前記ＰＰＰフレームのバイトの数が、ステップ１１３２で判断されるように、許容数以下の場合、前記ＰＰＰフレームは、ステップ１１３４において、ＳＤＢとして送信される。そうでない場合、前記ＰＰＰフレームのバイト数が、前記許容数を超える場合、ステップ１１３６において、ＳＤＢマーキングに関係なく、情報チャネルが再確立されて、前記ＰＰＰフレームが送信される。

一実施形態による、ＢＳＣ／ＰＣＦが、上記エアインタフェースを介してＳＤＢを送信するのに用いる処理手順を図１に示す。休眠パケットデータセッション中は、１つのＰＰＰフレームのみが、ＰＤＳＮ１０２からＭＳ１０６へ宛先指定されることが適当である。余分な処理を回避するため、ＢＳＣ／ＰＣＦ１０４が、パケットデータ休眠中に同時に着いた数個のみのＰＰＰフレームを処理するのが適当である。

（単純化した構文解析アルゴリズム）
上記ＬＣＰ処理されたパラメータ、ＡＣＣＭ処理及びＩＰ処理スキームがＢＳＣ／ＰＣＦ１０４に知られている一実施形態においては、上記構文解析アルゴリズムを単純化することができる。このような場合、次の構成がＢＳＣ／ＰＣＦ１０４に知られている。

アドレスフィールド９０４及び制御フィールド９０６の圧縮が使用可能である
プロトコルフィールド９０８の圧縮が使用可能である。

ＡＣＣＭが、０ｘ００００００００の値を有している
ＩＰｖ４処理スキームが用いられる
図１０及び図１１に示すＰＰＰフレーム及びＩＰデータグラム構文解析は、それぞれ、一実施形態に従って、図１２に示すようにまとめて単純化される。ステップ１２０２において、空白でないＰＰＰフレームが検出されたとき、上記プロセスは、プロトコルフィールド９０８の２番目のバイト、例えば、０ｘ２１の存在をチェックして、前記プロトコルフィールドの最初のバイトは、前記フィールドの圧縮処理中に除去されたことに注意する。見つかった場合、前記プロセスは、ステップ１２０６において、図４に示すようなヘッダ部の最初のバイトをスキップして、ＴＯＳフィールド４０２に達する。ステップ１２０８及びステップ１２１０において、前記プロセスは、図６に示すようなＴＯＳフィールド４０２のＬＳＢが設定されているか否かをチェックし、そうである場合、前記プロセスは、ステップ１２１２において、ＳＤＢマーキングを示す。そして、前記プロセスは、ステップ１２１４からステップ１２２０を継続して、図１１のステップ１１３０からステップ１１３６と同様に、ＳＤＢメッセージのサイズをチェックする。前記サイズ基準が満たされている場合、上記ＰＰＰフレームは、ＳＤＢとして送信される。そうでない場合には、ステップ１２２０において、前記ＰＰＰフレームが送信される前に、情報チャネルが再確立される。

従って、上記開示した実施形態は、休眠モードになっているターゲットの移動局に宛先が定められた情報を、再確立すべき情報チャネルを待つことなく、ＳＤＢメッセージとして送信すべきか否かを判断する有効かつ信頼度が高いシステム及び方法を提供する。

当業者は、情報及び信号を、様々な異なる方法及びプロトコルのうちのいずれかを用いて表わすことができることを理解するであろう。例えば、上記説明を通して言及されるデータ、命令、コマンド、情報、信号、ビット、シンボル及びチップは、電圧、電流、電磁波、磁場または粒子、光場または粒子、あるいはそれらのいずれかの組合せによって表わすことができる。

さらに、当業者は、本明細書に開示した上記実施形態と共に説明した様々な例示的論理ブロック、モジュール、回路及びアルゴリズムステップを、電子ハードウェア、コンピュータソフトウェアまたはそれら両方の組合せとして実施することができることを正しく認識するであろう。ハードウェアとソフトウェアとのこの互換性を明確に説明するために、種々の例示的なコンポーネント、ブロック、モジュール、回路及びステップをそれらの機能性に関して広く説明してきた。このような機能性を、ハードウェアまたはソフトウェアとして実施するか否かは、上記全体のシステムに課せられた特定の用途及び設計の制約による。当業者は、上記説明した機能性を、各特定の用途に対して様々な方法で実施してもよいが、このような実施の決断は、本発明の範囲から逸脱するものとして解釈すべきではない。

本明細書に開示した上記実施形態と共に説明した様々な例示的論理ブロック、モジュール及び回路は、汎用プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、書き替え可能ゲートアレイ（ＦＰＧＡ）または他のプログラム可能な論理素子、個別ゲートまたはトランジスタ論理、個別ハードウェアコンポーネント、あるいは、本明細書に記載した上記機能を実行するように設計されたそれらのいずれかの組合せを用いて実施または実行することができる。汎用プロセッサは、マイクロプロセッサでもよいが、代替実施形態において、前記プロセッサは、従来のどのようなプロセッサ、コントローラ、マイクロコントローラまたは状態機械であってもよい。また、プロセッサは、計算デバイスの組合せ、例えば、ＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと１つ以上のマイクロプロセッサ、あるいは、他のそのような構成として実施してもよい。

本明細書に開示した上記実施形態と共に説明した上記方法またはアルゴリズムのステップは、ハードウェアに直接、プロセッサによって実行されるソフトウェアモジュールに、または、それら２つの組合せに、組み込んでもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または、公知の記憶媒体の他のどのような形態にあってもよい。例示的な記憶媒体は、上記プロセッサが、前記記憶媒体から情報を読み出し、かつ前記記憶媒体に情報を書き込むことができるように、前記プロセッサに結合されている。代替実施形態において、前記記憶媒体は、前記プロセッサと一体化してもよい。前記プロセッサ及び記憶媒体は、ＡＳＩＣ内にあってもよい。前記ＡＳＩＣは、ユーザ端末内にあってもよい。代替実施形態において、前記プロセッサ及び記憶媒体は、ユーザ端末内の個別コンポーネントとして存在してもよい。

上記開示した実施形態の説明は、当業者が本発明を実行または利用できるように説明されている。それらの実施形態に対する様々な変更は、当業者には、容易に理解でき、また、本明細書において定義した包括的な原理は、本発明の趣旨または範囲を逸脱することなく、他の実施形態、例えば、インスタントメッセージサービスまたはどのような一般的な無線データ通信用途にも適用することができる。従って、本発明は、本明細書に示した上記実施形態に限定しようとするものではなく、本明細書に開示した原理及び新規な特徴と一致する最も広い範囲を認容すべきである。「例示的な」という言葉は、本明細書において、「実施例、具体例または例証として扱うこと」を意味するのにもっぱら使用されている。

携帯電話が終点になるショートデータバーストを配信するコールフロー図を示す。 フレーム化され埋め込まれるＩＰデータグラムを示す。 基地局及び移動局の実施形態を示す。 図２に示すＩＰデータグラムのヘッダ部分を示す。 １つの実施形態に係る、図４に示すヘッダ部分のサービスフィールドの種類を示す。 別の実施形態に係る、図４に示すヘッダ部分のサービスフィールドの種類を示す。 また別の実施形態に係る、図４に示すヘッダ部分のサービスフィールドの種類を示す。 図２に示すＩＰデータグラムの代替のヘッダ部分を示す。 図２に示すＰＰＰフレームのフレーム構造を示す。 図２に示すＰＰＰフレームの構文解析アルゴリズムを示す。 図４及び図８に示すＩＰデータグラムのヘッダ部分の構文解析アルゴリズムを示す。 単純化した構文解析アルゴリズムを示す。

Claims (28)

1. ターゲットの移動局に宛先が定められた情報が、ショートデータバーストとして送信されるように指定されているか否かを判断する方法であって、
   ターゲットの移動局に宛先が定められた情報パケットを受信することと、
   前記受信した情報パケットを構文解析することと、
   前記受信した情報パケットが、ショートデータバースト（ＳＤＢ）配信に指定されているか否かを判断することとを含む、方法。
2. 前記情報パケットは、ヘッダ部及び情報部を含む、請求項１に記載の方法。
3. 前記構文解析することは、前記ヘッダ部を構文解析することを含む、請求項２に記載の方法。
4. 前記構文解析することは、ＳＤＢマーキングを検出することをさらに含む、請求項３に記載の方法。
5. ターゲットの移動局に宛先が定められた情報が、ショートデータバーストとして送信されるように指定されているか否かを判断する方法を埋め込んだコンピュータ読取り可能媒体であって、前記方法は、
   ターゲットの移動局に宛先が定められた情報パケットを受信することと、
   前記受信した情報パケットを構文解析することと、
   前記受信した情報パケットが、ショートデータバースト（ＳＤＢ）配信に指定されているか否かを判断することとを含む、コンピュータ読取り可能媒体。
6. 前記情報パケットは、ヘッダ部及び情報部を含む、請求項５に記載のコンピュータ読取り可能媒体。
7. 前記構文解析することは、前記ヘッダ部を構文解析することを含む、請求項６に記載のコンピュータ読取り可能媒体。
8. 前記構文解析することは、ＳＤＢマーキングを検出することをさらに含む、請求項７に記載のコンピュータ読取り可能媒体。
9. ターゲットの移動局に宛先が定められた情報が、ショートデータバーストとして送信されるように指定されているか否かを判断する装置であって、
   ターゲットの移動局に宛先が定められた情報パケットを受信する手段と、
   前記受信した情報パケットを構文解析する手段と、
   前記受信した情報パケットが、ショートデータバースト（ＳＤＢ）配信に指定されているか否かを判断する手段とを備える、装置。
10. 前記情報パケットは、ヘッダ部及び情報部を含む、請求項９に記載の装置。
11. 前記構文解析する手段は、前記ヘッダ部を構文解析する手段を含む、請求項１０に記載の装置。
12. 前記構文解析する手段は、ＳＤＢマーキングを検出する手段をさらに含む、請求項１１に記載の装置。
13. ターゲットの移動局に宛先が定められた情報が、ショートデータバーストとして送信されるように指定されているか否かを判断する装置であって、
    情報を受信することが可能なレシーバと、
    情報をターゲットの移動局へ送信することが可能なトランスミッタと、
    方法を実行することが可能なプロセッサであって、この方法は、
    ターゲットの移動局に宛先が定められた情報パケットを受信することと、
    前記受信した情報パケットを構文解析することと、
    前記受信した情報パケットが、ショートデータバースト（ＳＤＢ）配信に指定されているか否かを判断することとを含むプロセッサとを備える、装置。
14. 前記情報パケットは、ヘッダ部及び情報部を含む、請求項１３に記載の装置。
15. 前記構文解析することは、前記ヘッダ部を構文解析することを含む、請求項１４に記載の装置。
16. 前記構文解析することは、ＳＤＢマーキングを検出することをさらに含む、請求項１５載の装置。
17. 情報を、無線通信ネットワークにおけるショートデータバースト（ＳＤＢ）配信に指定する方法であって、
    情報をデータグラムに埋め込むことであって、このデータグラムがヘッダ部を含むことと、
    無線通信インフラストラクチャが、前記データグラムに埋め込まれた情報をＳＤＢメッセージとして宛先へ配信するように、前記データグラムのヘッダ部を指定することとを含む、方法。
18. 前記指定することは、前記ヘッダ部のフィールド種別（ＴＯＳ）を指定することを含む、請求項１７に記載の方法。
19. 前記指定することは、前記ヘッダ部のトラフィッククラスフィールドを指定することを含む、請求項１７に記載の方法。
20. 情報を、無線通信ネットワークにおけるショートデータバースト（ＳＤＢ）配信に指定する方法を埋め込んだコンピュータ読取り可能媒体であって、前記方法は、
    情報をデータグラムに埋め込むことであって、このデータグラムがヘッダ部を含むことと、
    無線通信インフラストラクチャが、前記データグラムに埋め込まれた情報をＳＤＢメッセージとして宛先へ配信するように、前記データグラムのヘッダ部を指定することとを含む、コンピュータ読取り可能媒体。
21. 前記指定することは、前記ヘッダ部のフィールド種別（ＴＯＳ）を指定することを含む、請求項２０に記載のコンピュータ読取り可能媒体。
22. 前記指定することは、前記ヘッダ部のトラフィッククラスフィールドを指定することを含む、請求項２０に記載のコンピュータ読取り可能媒体。
23. 情報を、無線通信ネットワークにおけるショートデータバースト（ＳＤＢ）配信に指定する装置であって、
    情報をデータグラムに埋め込む手段であって、このデータグラムがヘッダ部を含む手段と、
    無線通信インフラストラクチャが、前記データグラムに埋め込まれた情報をＳＤＢメッセージとして宛先へ配信するように、前記データグラムのヘッダ部を指定する手段とを備える、装置。
24. 前記指定する手段は、前記ヘッダ部のフィールド種別（ＴＯＳ）を指定する手段を含む、請求項２３に記載の装置。
25. 前記指定する手段は、前記ヘッダ部のトラフィッククラスフィールドを指定する手段を含む、請求項２３に記載の装置。
26. 情報を、無線通信ネットワークにおけるショートデータバースト（ＳＤＢ）配信に指定する装置であって、
    情報を受信することが可能なレシーバと、
    情報をターゲットの移動局へ送信することが可能なトランスミッタと、
    方法を実行することが可能なプロセッサであって、この方法が、
    情報をデータグラムに埋め込むことであって、このデータグラムがヘッダ部を含むことと、
    無線通信インフラストラクチャが、前記データグラムに埋め込まれた情報をＳＤＢメッセージとして宛先へ配信するように、前記データグラムのヘッダ部を指定することとを含むプロセッサとを備える、装置。
27. 前記指定することは、前記ヘッダ部のフィールド種別（ＴＯＳ）を指定することを含む、請求項２６に記載の装置。
28. 前記指定することは、前記ヘッダ部のトラフィッククラスフィールドを指定することを含む、請求項２６に記載の装置。

Images