JP2005217626A - 無線アクセスネットワークを介するパケットデータ交換ノード、端末及びそのプログラム - Google Patents
無線アクセスネットワークを介するパケットデータ交換ノード、端末及びそのプログラム Download PDFInfo
- Publication number
- JP2005217626A JP2005217626A JP2004020021A JP2004020021A JP2005217626A JP 2005217626 A JP2005217626 A JP 2005217626A JP 2004020021 A JP2004020021 A JP 2004020021A JP 2004020021 A JP2004020021 A JP 2004020021A JP 2005217626 A JP2005217626 A JP 2005217626A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- header
- flow identifier
- management table
- information
- 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.)
- Withdrawn
Links
Images
Abstract
【課題】 無線リンクにおいて、プロトコルのための制御ヘッダ及び制御パケットを極力減らし、ＲＡＮにおけるトラヒック量を抑制することができるパケットデータ交換ノード、端末及びそのプログラムを提供する。
【解決手段】 発／着ＩＰアドレス毎にFlowIDを対応付けたＩＰヘッダ管理テーブル蓄積手段と、送信すべきＩＰパケットについて、ＩＰヘッダ部を削除し、ＩＰヘッダ省略パケットを生成するＩＰヘッダ削除手段と、そのパケット毎に複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて当該ＩＰアドレスに対応したFlowIDを付加して送信するヘッダ付加手段と、受信した分割パケットについて、１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、そのＩＰヘッダ省略パケットにFlowIDに対応するＩＰアドレスを付加するＩＰヘッダ付加手段とを有する。
【選択図】 図６
【解決手段】 発／着ＩＰアドレス毎にFlowIDを対応付けたＩＰヘッダ管理テーブル蓄積手段と、送信すべきＩＰパケットについて、ＩＰヘッダ部を削除し、ＩＰヘッダ省略パケットを生成するＩＰヘッダ削除手段と、そのパケット毎に複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて当該ＩＰアドレスに対応したFlowIDを付加して送信するヘッダ付加手段と、受信した分割パケットについて、１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、そのＩＰヘッダ省略パケットにFlowIDに対応するＩＰアドレスを付加するＩＰヘッダ付加手段とを有する。
【選択図】 図６
Description
本発明は、無線アクセスネットワーク（以下「ＲＡＮ」(Radio Access Network)という）を介して、移動端末とパケットを通信するパケットデータ交換ノード（以下「ＰＤＳＮ」(Packet Data Serving Node)という」、端末及びそのプログラムに関する。
図１は、従来のＨＲＰＤ(High Rate Packet Data)システムの構成図である。
図１によれば、ＲＡＮは、携帯電話事業者センタ内におけるＰＤＳＮ１及びパケット制御装置（以下「ＰＣＦ」(Packet Control Function)という）２と、アクセスネットワークトランシーバシステム（以下「ＡＮＴＳ」(Access Network Transceiver System)という）３と、移動端末であるアクセスターミナル（以下「ＡＴ」(Access Terminal)という）４とから構成されている。一方、ＰＤＳＮ１は、携帯電話事業者センタ内におけるホームエージェント（以下「ＨＡ」(Home Agent)という）５を介してインターネット７に接続されており、サーバ６と通信することができる。
図２は、図１におけるプロトコルスタックである（例えば非特許文献１、２及び３参照）。
図２によれば、サーバ６とＡＴ４との間は、トランスポート層と、ネットワーク層とによって通信が実現されている。トランスポート層としては、例えばＴＣＰ(Transmission Control Protocol)又はＵＤＰ(User Datagram Protocol)があり、ネットワーク層としてはＩＰ(Internet Protocol)がある。また、ＰＤＳＮ１とＨＡ５との間の通信では、ＭＰＡ(Mobile Proxy Agent)によってカプセル化が行われる（例えば非特許文献５参照）。ＰＤＳＮ１とＡＴ４との間は、ＰＰＰ(Point to Point Protocol)によってＩＰパケットの通信が実現されている（例えば非特許文献６参照）。ＰＰＰとは、シリアルラインを使って通信するための物理層／データリンク層プロトコルであり、両端で使用するＩＰアドレスの自動的なネゴシエーション、認証機能又は圧縮機能等をサポートする。更に、ＰＤＳＮ１とＰＣＦ２との間は、ＧＲＥ(General Routing Encapsulation)プロトコルによってパケット転送パスの制御が実現されている（例えば非特許文献７参照）。更に、ＰＣＦ２とＡＴ４との間は、ＲＬＰ(Radio Link Protocol)によってＰＰＰフレームが分割送信される（例えば非特許文献４参照）。尚、ＰＨＹ(Physical Layer)は、物理層を意味する。
ＨＲＰＤシステムの無線リンクは、ユーザデータを運ぶTraffic Channelと、呼確立などのシグナリングに用いるSignaling Channelとが存在する。Traffic Channelは、ＡＮＴＳからＡＴへの方向のForward Linkと、ＡＴからＡＮＴＳへの方向のReverse Linkとから構成される。
ＲＬＰは、無線リンクのTraffic Channelで用いられるプロトコルであり、上位層パケットの分割及び再構成の機能と、再送の機能とを有する。分割及び再構成の機能は、送信すべき上位層パケットを無線リンクで送信可能な無線パケットに分割し、受信されたＲＬＰフレームを上位層パケットに再構成する。再送の機能は、無線リンクにおいて、エラーの発生したＲＬＰフレームを再送する。エラー発生時に、送信元装置へＮＡＫ(Negative AcKnowledgement)フレームを送信することにより、再送を促すことができる。ここでの再送回数は、携帯電話事業者がシステムに設定した値によって決定され、ユーザの使用しているアプリケーション等には依存していない。
図３は、図１のシステムの中で転送されるパケットの構成図である。
図３によれば、サーバ６からＡＴ４へ送信されるパケットについて説明している。
（Ｓ３１）サーバ６は、データが含まれたパケット、例えばＴＣＰ／ＩＰパケット（ＩＰヘッダ＋ＴＣＰヘッダ＋データ）をＨＡ５へ送信する。
（Ｓ３２）ＨＡ５は、受信したＴＣＰ／ＩＰパケットに対してＭＰＡカプセル化処理を行い、ＭＰＡヘッダを付加したパケットをＰＤＳＮ１へ送信する。
（Ｓ３３）ＰＤＳＮ１は、ＭＰＡヘッダを取り除き、ＴＣＰ／ＩＰパケットをＰＰＰフレーム化する。
（Ｓ３４）そのＰＰＰフレームにＧＲＥカプセル化処理を行い、ＧＲＥヘッダを付加したパケットをＰＣＦ２へ送信する。
（Ｓ３５）ＰＣＦ２は、ＧＲＥヘッダを取り除き、ＰＰＰフレームを無線リンクでの送信単位であるＲＬＰフレームに分割する。このとき、ストリームデータである複数のＰＰＰフレームをまとめてＲＬＰフレームに分割するので、１つのＲＬＰフレームのデータが、前後２つのＰＰＰフレームに属する場合もある。図３によれば、ＲＬＰ３のデータは、前後２つのＰＰＰフレームに属するものである。その後、ＰＣＦ２はＲＬＰフレームにＵＤＰ／ＩＰヘッダを付け、ＡＴ４の属するＡＮＴＳ３へ送信する。
（Ｓ３６）ＡＮＴＳ３は、ＵＤＰ／ＩＰヘッダを取り除き、複数のＲＬＰフレームを、シーケンス番号順に無線を介して送信する。
（Ｓ３７）ＡＴ４は、受信した複数のＲＬＰフレームを結合した上で、ＰＰＰフレームを再構成し、その後、１つ以上のＴＣＰ／ＩＰパケットを再構成する。
（Ｓ３１）サーバ６は、データが含まれたパケット、例えばＴＣＰ／ＩＰパケット（ＩＰヘッダ＋ＴＣＰヘッダ＋データ）をＨＡ５へ送信する。
（Ｓ３２）ＨＡ５は、受信したＴＣＰ／ＩＰパケットに対してＭＰＡカプセル化処理を行い、ＭＰＡヘッダを付加したパケットをＰＤＳＮ１へ送信する。
（Ｓ３３）ＰＤＳＮ１は、ＭＰＡヘッダを取り除き、ＴＣＰ／ＩＰパケットをＰＰＰフレーム化する。
（Ｓ３４）そのＰＰＰフレームにＧＲＥカプセル化処理を行い、ＧＲＥヘッダを付加したパケットをＰＣＦ２へ送信する。
（Ｓ３５）ＰＣＦ２は、ＧＲＥヘッダを取り除き、ＰＰＰフレームを無線リンクでの送信単位であるＲＬＰフレームに分割する。このとき、ストリームデータである複数のＰＰＰフレームをまとめてＲＬＰフレームに分割するので、１つのＲＬＰフレームのデータが、前後２つのＰＰＰフレームに属する場合もある。図３によれば、ＲＬＰ３のデータは、前後２つのＰＰＰフレームに属するものである。その後、ＰＣＦ２はＲＬＰフレームにＵＤＰ／ＩＰヘッダを付け、ＡＴ４の属するＡＮＴＳ３へ送信する。
（Ｓ３６）ＡＮＴＳ３は、ＵＤＰ／ＩＰヘッダを取り除き、複数のＲＬＰフレームを、シーケンス番号順に無線を介して送信する。
（Ｓ３７）ＡＴ４は、受信した複数のＲＬＰフレームを結合した上で、ＰＰＰフレームを再構成し、その後、１つ以上のＴＣＰ／ＩＰパケットを再構成する。
これに対し、ＡＴ４からサーバ６へパケットを転送する場合は、図３のシーケンスと全く逆の方向に流れる。即ち、ＡＴ４は、送信すべきＴＣＰ／ＩＰパケットをＰＰＰフレーム化し、そのＰＰＰフレームをＲＬＰフレームに分割してＡＮＴＳ３へ送信する。一方、ＡＮＴＳ３を介してＲＬＰフレームを受信したＰＣＦ２は、そのＲＬＰフレームを組み立ててＰＰＰフレームを構成する。そのＰＰＰフレームは、ＰＤＳＮ１によってＴＣＰ／ＩＰパケットに構成される。
図４は、従来のＶＪ圧縮の転送方法の説明図である。
ＰＰＰリンク部分においては、無線リンクの通信帯域を有効に使用するため、ＴＣＰ／ＩＰパケットのうち、ＴＣＰ／ＩＰヘッダ部分の圧縮を行うことが可能である（例えば非特許文献８参照）。
（Ｓ４１）最初に、ＰＤＳＮは、ヘッダ圧縮をしない通常のＴＣＰ／ＩＰヘッダを付加したパケットをＡＴへ転送する。このとき、ＡＴは、そのヘッダ全体をキャッシュする。
（Ｓ４２）次に、ＰＤＳＮは、同じＡＴへ送信するＴＣＰ／ＩＰパケットについては、そのパケットのＴＣＰ／ＩＰヘッダ全体を取り除き、それに代わって、先のＴＣＰ／ＩＰパケットからのシーケンス番号の差分情報、及びＴＣＰチェックサム情報のみを付加して、ＡＴへ送信する。この差分情報を受信したＡＴは、その差分情報と、キャッシュしたヘッダ情報からヘッダを復元する。更に、ＡＴは、そのヘッダ情報とシーケンス番号の差分情報とから、元のＴＣＰ／ＩＰパケットを再構成し、ＴＣＰチェックサム情報を用いて正しく復元できたか否かを確認する。
（Ｓ４３）このとき、ＰＤＳＮとＡＴとの間で、ヘッダ圧縮を行ったパケットがエラーによって欠落する場合がある。
（Ｓ４４）一度、差分情報を含むパケットが欠落すると、その後、シーケンス番号がずれた状態でＴＣＰ／ＩＰヘッダが復元されてしまい、ヘッダを正しく復元することができない。この場合、再度、ＰＤＳＮが、ヘッダ圧縮していないＴＣＰ／ＩＰヘッダを含むパケットを送信し、ＡＴが、再度、ＴＣＰ／ＩＰヘッダをキャッシュする必要がある。ＴＣＰ／ＩＰヘッダが圧縮されていないＴＣＰ／ＩＰパケットの送信は、ＴＣＰタイムアウトが発生してから行われるので、通信が正常にできない状態が一定時間続くこととなる。
（Ｓ４１）最初に、ＰＤＳＮは、ヘッダ圧縮をしない通常のＴＣＰ／ＩＰヘッダを付加したパケットをＡＴへ転送する。このとき、ＡＴは、そのヘッダ全体をキャッシュする。
（Ｓ４２）次に、ＰＤＳＮは、同じＡＴへ送信するＴＣＰ／ＩＰパケットについては、そのパケットのＴＣＰ／ＩＰヘッダ全体を取り除き、それに代わって、先のＴＣＰ／ＩＰパケットからのシーケンス番号の差分情報、及びＴＣＰチェックサム情報のみを付加して、ＡＴへ送信する。この差分情報を受信したＡＴは、その差分情報と、キャッシュしたヘッダ情報からヘッダを復元する。更に、ＡＴは、そのヘッダ情報とシーケンス番号の差分情報とから、元のＴＣＰ／ＩＰパケットを再構成し、ＴＣＰチェックサム情報を用いて正しく復元できたか否かを確認する。
（Ｓ４３）このとき、ＰＤＳＮとＡＴとの間で、ヘッダ圧縮を行ったパケットがエラーによって欠落する場合がある。
（Ｓ４４）一度、差分情報を含むパケットが欠落すると、その後、シーケンス番号がずれた状態でＴＣＰ／ＩＰヘッダが復元されてしまい、ヘッダを正しく復元することができない。この場合、再度、ＰＤＳＮが、ヘッダ圧縮していないＴＣＰ／ＩＰヘッダを含むパケットを送信し、ＡＴが、再度、ＴＣＰ／ＩＰヘッダをキャッシュする必要がある。ＴＣＰ／ＩＰヘッダが圧縮されていないＴＣＰ／ＩＰパケットの送信は、ＴＣＰタイムアウトが発生してから行われるので、通信が正常にできない状態が一定時間続くこととなる。
ＨＲＰＤシステムでは、ＡＴがサーバと通信する場合、ＡＮＴＳと無線リンクを確立した後で、ＡＴとＰＤＳＮとの間でＰＰＰリンクを確立する。このとき、極めて多くの制御パケットの送受信が無線リンク上で行われることとなる。
3GPP2 P.S0001-B v1.0 cdma2000 Wireless IP Network Standard、p.12〜p.26、［online］、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/P.S0001-B_v1.0.pdf＞ 3GPP2 A.S.0008-0 v3.0 Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Access Network Interfaces 3、p.1-1〜p.2-6、特にp.1-5掲載の参照モデル図、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/A.S0008-0_v3.0.pdf＞ 3GPP2 A.S.0012-A v1.0 Interoperability Specification (IOS) for cdma2000 Access Network Interfaces - Part 2 Transport 12、p.7〜p.16、p.46〜p.48、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/A.S0012-A_v1.0.pdf＞ 3GPP2 C.S.0024 Version 3.0 cdma2000 High Packet Data Air Interface Specification、p.3-5〜p.3-11、p.8-1〜p8-85、p9-1〜p.9-5、p.9-26〜p.9-40、p.9-56〜p.9-70、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/C.S0024-0_v3.0.pdf＞ Internet Engineering Task Force、RFC 2002 - IP Mobility Support Internet Engineering Task Force、RFC 1661 - Point-to-Point Protocol Internet Engineering Task Force、RFC 1701 - Generic Routing Encapsulation Internet Engineering Task Force、RFC 1144 - Compressing TCP/IP Headers for Low-Speed Serial Links Internet Engineering Task Force、RFC 2460 - Internet Protocol、Version 6 (IPv6) Specification 2.3
3GPP2 P.S0001-B v1.0 cdma2000 Wireless IP Network Standard、p.12〜p.26、［online］、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/P.S0001-B_v1.0.pdf＞ 3GPP2 A.S.0008-0 v3.0 Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Access Network Interfaces 3、p.1-1〜p.2-6、特にp.1-5掲載の参照モデル図、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/A.S0008-0_v3.0.pdf＞ 3GPP2 A.S.0012-A v1.0 Interoperability Specification (IOS) for cdma2000 Access Network Interfaces - Part 2 Transport 12、p.7〜p.16、p.46〜p.48、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/A.S0012-A_v1.0.pdf＞ 3GPP2 C.S.0024 Version 3.0 cdma2000 High Packet Data Air Interface Specification、p.3-5〜p.3-11、p.8-1〜p8-85、p9-1〜p.9-5、p.9-26〜p.9-40、p.9-56〜p.9-70、［平成１６年１月１３日検索］、インターネット＜ＵＲＬ：http://www.3gpp2.org/Public_html/specs/C.S0024-0_v3.0.pdf＞ Internet Engineering Task Force、RFC 2002 - IP Mobility Support Internet Engineering Task Force、RFC 1661 - Point-to-Point Protocol Internet Engineering Task Force、RFC 1701 - Generic Routing Encapsulation Internet Engineering Task Force、RFC 1144 - Compressing TCP/IP Headers for Low-Speed Serial Links Internet Engineering Task Force、RFC 2460 - Internet Protocol、Version 6 (IPv6) Specification 2.3
無線リンクは、その伝送容量又は割当可能な伝送帯域に限界があるだけでなく、送信されるパケットがエラーとなる割合が有線リンクと比較して多い。加えて、前述した図２のプロトコルスタックによれば、無線リンクにおいてユーザトラヒック以外の制御用パケットの送受信が多数必要となっている。即ち、無線リンクにおいて、ＰＰＰリンク確立、又はＲＬＰの再送を行うためのＮＡＫフレーム等の多数の制御用パケットが流れる。また、ＡＮＴＳとＡＴとの間は１対１通信であるが、サーバと端末との間で通信を行うために、ユーザトラヒックに宛先を示すＩＰヘッダを付加する必要がある。特に、ＩＰｖ６を用いた場合、そのアドレス長は１２８ビットであるため、ＩＰヘッダがパケットに占める割合が大きい（例えば非特許文献９参照）。加えて、モバイルＩＰを端末がサポートした場合、端末から定期的に制御用パケットを送信する必要がある（例えば非特許文献５参照）。このような制御用パケットが、有限な無線リンク帯域を消費する。
また、ＰＰＰリンクを確立するためには、端末の認証及びユーザ認証のような多数の手順を必要とする。加えて、ＰＰＰは端末がそれぞれ独自に状態遷移を行うプロトコルであるため、必要な返答を相手端末より受けるまで、不要な制御用パケットが再送されることになる。
更に、ＲＬＰについても、無線リンクにおいて発生した誤りを訂正するために、専用線を介して、センタに設置されたＰＣＦまでの通信を必要とする。このようにプロトコル手順が煩雑であり、その結果、システム内遅延が大きくならざるを得ない。
更に、１つのＲＬＰフレームに２つ以上のＰＰＰフレームが属している場合、当該ＲＬＰフレームのエラーは、複数のＩＰパケットのエラーにつながり、再送のオーバヘッドが大きくなる一因でもあった。
ＶＪ圧縮利用時には、無線リンクでのエラーの影響により、ＴＣＰ／ＩＰパケットにエラーが発生した場合、ＴＣＰ／ＩＰスループットの低下が顕著となる。これは、無線リンクでのエラーの影響が、１つのＴＣＰ／ＩＰパケットだけであっても、図４で述べたように、のみに影響したとしても、その後の複数のＴＣＰ／ＩＰパケットがエラーとなり、エラーからの回復が、Fast Retransmitによるものではなく、タイムアウト再送によるものになるためである。
従って、本発明は、無線リンクにおいて、プロトコルのためのヘッダ及び制御パケットを極力減らし、ＲＡＮにおけるトラヒック量を抑制することができるパケットデータ交換ノード、端末及びそのプログラムを提供することを目的とする。
本発明のパケットデータ交換ノードによれば、
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
受信したＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、ＩＰパケットの発／着ＩＰアドレスに対応したフロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
を有し、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とする。これにより、無線リンクにおいて、プロトコルのためのヘッダ及び制御パケットを極力減らすことができ、ＲＡＮにおけるシステム構成を簡素化することができる。特に、プロトコルスタックを簡素化することができるので、プロトコルのヘッダ量を削減でき、同一の帯域で、より多くのユーザデータを送信することができる。また、ＩＰパケット毎に分割するために、１つの分割パケットのエラーが、複数のＩＰパケットのエラーにつながることもない。
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
受信したＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、ＩＰパケットの発／着ＩＰアドレスに対応したフロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
を有し、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とする。これにより、無線リンクにおいて、プロトコルのためのヘッダ及び制御パケットを極力減らすことができ、ＲＡＮにおけるシステム構成を簡素化することができる。特に、プロトコルスタックを簡素化することができるので、プロトコルのヘッダ量を削減でき、同一の帯域で、より多くのユーザデータを送信することができる。また、ＩＰパケット毎に分割するために、１つの分割パケットのエラーが、複数のＩＰパケットのエラーにつながることもない。
本発明のパケットデータ交換ノードにおける他の実施形態によれば、
分割ヘッダ付加手段は、分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、分割パケットのヘッダに更に含めており、
受信した分割パケットがＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報とフロー識別子とをＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
パケット組立手段は、最初、最後又は継続の情報とシーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てることも好ましい。これにより、最初にＩＰヘッダを送信すればその後はフロー識別子で判断されるので、ＩＰｖ６のようにＩＰヘッダが拡張されても無線リンクにおけるオーバヘッドが増えることがない。特に、ＶＪ圧縮のようにヘッダ全体を圧縮するのではなく、ＩＰヘッダのみ（トランスポート層に依存しない）を圧縮するために、エラー率が比較的高い無線リンクで安定した通信が可能となる。
分割ヘッダ付加手段は、分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、分割パケットのヘッダに更に含めており、
受信した分割パケットがＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報とフロー識別子とをＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
パケット組立手段は、最初、最後又は継続の情報とシーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てることも好ましい。これにより、最初にＩＰヘッダを送信すればその後はフロー識別子で判断されるので、ＩＰｖ６のようにＩＰヘッダが拡張されても無線リンクにおけるオーバヘッドが増えることがない。特に、ＶＪ圧縮のようにヘッダ全体を圧縮するのではなく、ＩＰヘッダのみ（トランスポート層に依存しない）を圧縮するために、エラー率が比較的高い無線リンクで安定した通信が可能となる。
また、本発明のパケットデータ交換ノードにおける他の実施形態によれば、ＩＰの制御要求パケットを受信した際に、ＩＰの制御応答パケットを返信する制御用ＩＰパケット応答手段を更に有し、ＩＰの制御要求パケットを転送しないように構成されていることも好ましい。これにより、制御用ＩＰパケットが無線リンクに流れないので、リソースに制限のある無線リンクの有効的に活用することができる。
更に、本発明のパケットデータ交換ノードにおける他の実施形態によれば、分割ヘッダ付加手段は、元のＩＰパケットのデータ部に含まれるデータ属性に応じた再送回数を示す情報を分割パケットのヘッダに更に含め、分割パケットを中継する装置が、無線リンクでエラーが発生した当該分割パケットを、最大、再送回数だけ再送することができるようにすることも好ましい。これにより、再送シーケンスが通信事業者設備まで通知されることがない。加えて、ＩＰパケットのデータ部分が有するトラヒック種別に応じた再送回数を指定できるので、無線リンクで効率的且つ遅延の少ない再送を実現することができる。
本発明の端末によれば、
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
送信すべきＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、ＩＰパケットの発／着ＩＰアドレスに対応したフロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
を有し、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とする。
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
送信すべきＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、ＩＰパケットの発／着ＩＰアドレスに対応したフロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
を有し、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とする。
本発明の端末における他の実施形態によれば、
分割ヘッダ付加手段は、分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、分割パケットのヘッダに更に含めており、
受信した分割パケットがＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報とフロー識別子とをＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
パケット組立手段は、最初、最後又は継続の情報とシーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てることも好ましい。
分割ヘッダ付加手段は、分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、分割パケットのヘッダに更に含めており、
受信した分割パケットがＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報とフロー識別子とをＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
パケット組立手段は、最初、最後又は継続の情報とシーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てることも好ましい。
本発明の装置におけるプログラムによれば、
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
送信すべきＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、ＩＰパケットの発／着ＩＰアドレスに対応したフロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
としてコンピュータを機能させ、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とする。
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
送信すべきＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、ＩＰパケットの発／着ＩＰアドレスに対応したフロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
としてコンピュータを機能させ、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とする。
本発明のプログラムにおける他の実施形態によれば、
分割ヘッダ付加手段は、分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、分割パケットのヘッダに更に含めており、
受信した分割パケットがＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報とフロー識別子とをＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
パケット組立手段は、最初、最後又は継続の情報とシーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てるようにコンピュータを機能させることも好ましい。
分割ヘッダ付加手段は、分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、分割パケットのヘッダに更に含めており、
受信した分割パケットがＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報とフロー識別子とをＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
パケット組立手段は、最初、最後又は継続の情報とシーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てるようにコンピュータを機能させることも好ましい。
また、本発明のプログラムにおける他の実施形態によれば、ＩＰの制御要求パケットを受信した際に、ＩＰの制御応答パケットを返信する制御用ＩＰパケット応答手段を更に有し、ＩＰの制御要求パケットを転送しないようにコンピュータを機能させることも好ましい。
更に、本発明のプログラムにおける他の実施形態によれば、分割ヘッダ付加手段は、元のＩＰパケットのデータ部に含まれるデータ属性に応じた再送回数を示す情報を分割パケットのヘッダに更に含め、分割パケットを中継する装置が、無線リンクでエラーが発生した当該分割パケットを、最大、再送回数だけ再送することができるようにすることも好ましい。
本発明のパケットデータ交換ノード、端末及びそのプログラムによれば、無線リンクにおいて、プロトコルのためのヘッダ及び制御パケットを極力減らすことができ、ＲＡＮにおけるトラヒック量を抑制することができる。特に、プロトコルスタックを簡素化することができるので、プロトコルのヘッダ量を削減でき、同一の帯域で、より多くのユーザデータを送信することができる。
また、最初にＩＰヘッダを送信すればその後はフロー識別子で判断されるので、ＩＰｖ６のようにＩＰヘッダが拡張されても、パケット全体におけるオーバヘッドが増えることがない。加えて、ＶＪ圧縮のようにヘッダ全体を圧縮するのではなく、ＩＰヘッダのみ（トランスポート層に依存しない）を圧縮するために、エラー率が比較的高い無線リンクで安定した通信が可能となる。
更に、制御用ＩＰパケットが無線リンクで転送されないので、リソースに制限のある無線リンクの有効的に活用することができる。
更に、再送シーケンスが通信事業者設備まで通知されることがなく、加えて、ＩＰパケットのデータ部分が有するトラヒック種別に応じた再送回数を指定できるので、無線リンクで効率的且つ遅延の少ない再送を実現することができる。
以下では、図面を用いて、本発明を実施するための最良の形態を説明する。
図５は、本発明における無線アクセスネットワークシステムの構成図である。
従来技術である図１のシステムによればＰＣＦ２及びＡＮＴＳ３が存在していたが、図５のシステムによればそれらは必要とされず、無線リンクのためのＢＳ(Base Station)８を備えるだけである。
図６は、図５におけるプロトコルスタックである。
従来技術である図２のプロトコルスタックによれば、ＰＤＳＮ１とＰＣＦ２との間のＧＲＥプロトコルと、ＰＣＦ２とＡＴ４との間のＲＬＰとを必要とするが、図６のプロトコルスタックによればそれらは必要とされず、ＰＤＳＮ１とＡＴ４との間に新たなＡＬＰ(Air Link Protocol)を備えるだけである。このとき、ＰＤＳＮ１が、サーバ６との間でＩＰパケットの交換を行い、ＡＴ４は、ＡＬＰの機能に基づいてＩＰヘッダを復元する機能を有する。尚、図６によれば、サーバ６とＰＤＳＮ１との間の構成は、図２のものと全く同一であって、ＲＡＮの部分のシステム構成のみの変更に留まる。
ここで、ＰＤＳＮ１のネットワーク層のＩＰ部分について説明する。図２のプロトコルスタックによれば、サーバ６とＡＴ４との間でＩＰによる処理が行われているために、ユーザデータだけでなく、制御用ＩＰパケットも全て、無線リンクを介して通信される。しかしながら、制御用ＩＰパケットについては、必ずしもＡＴ４と送受信する必要がない。例えば、ICMP echo requestや、モバイルＩＰにおけるRegistration Request/Reply等の制御用ＩＰパケットは、ＡＴ４に代わってＰＤＳＮ１が処理を行うこともできる。このように、サーバ６とＰＤＳＮ１との間でＩＰによる処理を完結させることよって、ＡＴ４が制御用ＩＰパケットの処理を行う必要がなくなり、ＲＡＮの無線リンクに制御用ＩＰパケットを流す必要がなくなる。もちろん、ＰＤＳＮ１が行うＩＰによる処理は、無線リンクの状態に基づいて変更することもできる。例えば、ICMP echo requestに対してecho replyを返信するか否かは、ＰＤＳＮ１とＡＴ４との間に無線リンクが確立しているか否かによって判断することができる。無線リンク確立等の情報は、ＲＡＮ内の制御パケットにより容易に把握することができる。また、ＰＤＳＮ１がＡＴ４に代わって処理を代行する制御用ＩＰパケットの種別について、無線リンク確立時にＰＤＳＮ１に対して通知を行うこともできる。
以下では、上位層となるトランスポート層がＴＣＰであって、サーバ６とＡＴ４との間で送受信されるパケットはＴＣＰ／ＩＰパケットであるとして説明する。しかしながら、本発明は、トランスポート層がＴＣＰに限定されるものではなく、少なくとも何らかの上位層からのパケットに対して転送処理を行うものである。
図７は、図５のシステムの中で転送されるパケットの構成図である。
図７によれば、図３と同様に、サーバ６からＡＴ４へ転送されるパケットについて説明している。
（Ｓ７１）サーバ６は、ＴＣＰ／ＩＰパケット（ＩＰヘッダ＋ＴＣＰヘッダ＋データ）をＨＡ５へ送信する。
（Ｓ７２）ＨＡ５は、ＴＣＰ／ＩＰパケットにＭＰＡカプセル化処理を行い、ＭＰＡヘッダを付加したパケットをＰＤＳＮ１へ転送する。
（Ｓ７３）ＰＤＳＮ１は、ＭＰＡヘッダを取り除き、次にＩＰヘッダを取り除いて、ＩＰヘッダ省略パケット（ＴＣＰヘッダ＋データ）にする。更に、ＰＤＳＮ１は、ＩＰヘッダ省略パケット毎に、無線リンクに対応するようにＡＬＰフレームに分割する。そして、ＰＤＳＮ１は、ＡＴ４からＢＳ８に送信するために、ＡＬＰフレーム毎にＵＤＰ／ＩＰヘッダを付加し、そのＡＬＰフレームを有線リンクを介してＢＳ８へ送信する。宛先となるＡＴ４が収容されているＢＳ８のアドレスは、無線リンクを確立した際の情報から取得される。
（Ｓ７１）サーバ６は、ＴＣＰ／ＩＰパケット（ＩＰヘッダ＋ＴＣＰヘッダ＋データ）をＨＡ５へ送信する。
（Ｓ７２）ＨＡ５は、ＴＣＰ／ＩＰパケットにＭＰＡカプセル化処理を行い、ＭＰＡヘッダを付加したパケットをＰＤＳＮ１へ転送する。
（Ｓ７３）ＰＤＳＮ１は、ＭＰＡヘッダを取り除き、次にＩＰヘッダを取り除いて、ＩＰヘッダ省略パケット（ＴＣＰヘッダ＋データ）にする。更に、ＰＤＳＮ１は、ＩＰヘッダ省略パケット毎に、無線リンクに対応するようにＡＬＰフレームに分割する。そして、ＰＤＳＮ１は、ＡＴ４からＢＳ８に送信するために、ＡＬＰフレーム毎にＵＤＰ／ＩＰヘッダを付加し、そのＡＬＰフレームを有線リンクを介してＢＳ８へ送信する。宛先となるＡＴ４が収容されているＢＳ８のアドレスは、無線リンクを確立した際の情報から取得される。
ＡＬＰフレームはヘッダ部とデータ部とからなり、ヘッダ部には以下の情報が含まれ、データ部には分割されたＩＰヘッダ省略パケットが含まれる。
（１）FlowID： ＰＤＳＮとＡＴとの間で通信を識別するための識別子
（２）CRC： ＡＬＰフレーム全体のＣＲＣ(Cyclic Redundancy Check)
（３）SEQ： シーケンス番号（増分すると共に巡回的に繰り返す）
（４）LEN： データ長
（５）Flag： 特性フラグ「ＩＰヘッダを含む／含まない」「ＩＰパケットの最初／最後／継続」「再送回数」
（１）FlowID： ＰＤＳＮとＡＴとの間で通信を識別するための識別子
（２）CRC： ＡＬＰフレーム全体のＣＲＣ(Cyclic Redundancy Check)
（３）SEQ： シーケンス番号（増分すると共に巡回的に繰り返す）
（４）LEN： データ長
（５）Flag： 特性フラグ「ＩＰヘッダを含む／含まない」「ＩＰパケットの最初／最後／継続」「再送回数」
（Ｓ７４）ＢＳ８は、ＵＤＰ／ＩＰヘッダが付加されたＡＬＰフレームを受信すると、そのＵＤＰ／ＩＰヘッダを取り除き、ＡＬＰフレームをシーケンス番号順にＡＴ４へ無線で送信する。
（Ｓ７５）ＡＴ４は、受信したＡＬＰフレームを、「最初」「最後」「継続」のフラグとSEQとに従って組み立てて、ＩＰヘッダ省略パケットを再構成する。更に、ＡＬＰフレームのFlowIDから、ＩＰヘッダ管理テーブルを検索し、予めキャッシュされたＩＰヘッダを取得する。取得したＩＰヘッダをそのＩＰヘッダ省略パケットに付加し、ＴＣＰ／ＩＰパケットが再構成される。
（Ｓ７５）ＡＴ４は、受信したＡＬＰフレームを、「最初」「最後」「継続」のフラグとSEQとに従って組み立てて、ＩＰヘッダ省略パケットを再構成する。更に、ＡＬＰフレームのFlowIDから、ＩＰヘッダ管理テーブルを検索し、予めキャッシュされたＩＰヘッダを取得する。取得したＩＰヘッダをそのＩＰヘッダ省略パケットに付加し、ＴＣＰ／ＩＰパケットが再構成される。
ＩＰヘッダ管理テーブルとは、表１のようなものであり、一意のFlowIDと、発／着ＩＰアドレスと、ＩＰヘッダの情報との組を管理する。
一方、ＡＴ４からサーバ６へパケットを転送する場合は、図７のシーケンスと全く逆の方向に流れる。即ち、ＡＴ４は、送信すべきデータを含んでいるＴＣＰ／ＩＰパケットからＩＰヘッダを取り除き、そのＩＰヘッダ省略パケットをＡＬＰフレームに分割してＢＳ８へ送信する。このとき、ＡＬＰフレームのヘッダには、FlowID、CRC、SEQ、LEN及びFlagが含まれる。ＢＳ８は、ＡＬＰフレームにＵＤＰ／ＩＰヘッダを付加してＰＤＳＮ１へ送信する。ＰＤＳＮ１は、そのＡＬＰフレームを、Flag及びSEQに基づいて組み立て、ＩＰヘッダ省略パケットを再構成する。更に、ＰＤＳＮ１は、ＡＬＰフレームのFlowIDから、ＩＰヘッダ管理テーブルを検索し、予めキャッシュされたＩＰヘッダを取得する。取得したＩＰヘッダをそのＩＰヘッダ省略パケットに付加し、ＴＣＰ／ＩＰパケットが再構成される。
前述したように、本発明によれば、ＰＤＳＮ１とＡＴ４との間のＲＡＮの中では、ＩＰヘッダを含まないＩＰヘッダ省略パケットが複数のＡＬＰフレームに分割されて送受信される。また、制御用ＩＰパケットは、ＲＡＮの中で送受信されず、ＰＤＳＮ１が、ＡＴ４との間の無線リンクの状態によって、サーバ６に対してＩＰの制御応答パケットの返信を行う。
図８は、ＡＬＰフレームを受信した際のフローチャートである。ＰＤＳＮ１及びＡＴ４のいずれにおいても、このフローチャートの処理が行われる。
（Ｓ８０１）ＡＬＰフレームのＡＬＰヘッダを抽出する。ＡＬＰヘッダには、FlowID、CRC、SEQ、LEN及びFlagが含まれている。
（Ｓ８０２）CRCからＡＬＰフレームの正常受信を確認し、SEQからＡＬＰフレームの順序を確認し、LENからＡＬＰフレームのデータ長を確認する。このとき、ＡＬＰフレームが異常であれば、そのＡＬＰフレームを廃棄する（Ｓ８１４）。
（Ｓ８０３）ＡＬＰヘッダに含まれるFlowIDが、ＩＰヘッダ管理テーブルに登録されているか否かを確認する。既に登録されていれば、ＡＬＰフレームの組み立てを行う（Ｓ８０６）。
（Ｓ８０４）FlowIDがＩＰヘッダ管理テーブルに登録されていなければ、ＡＬＰフレームがＩＰヘッダを含んでいるか否かを確認する。これは、ＡＬＰヘッダのFlagを確認することにより判断できる。ＡＬＰヘッダのFlagが「ＩＰヘッダを含まない」になっていたならば、そのＡＬＰフレームを廃棄する（Ｓ８１４）。
（Ｓ８０５）ＡＬＰヘッダのFlagが「ＩＰヘッダを含む」になっていたならば、ＩＰヘッダ管理テーブルに、一意のFlowIDと発／着ＩＰアドレスとＩＰヘッダの情報とを登録する。
（Ｓ８０６）ＡＬＰヘッダのFlag「最初」「最後」「継続」とSEQとに基づいて、ＡＬＰフレームを１つのＩＰヘッダ省略パケットに組み立てる。
（Ｓ８０７）Flagが「最後」か否かを判定する。Flagが「最後」でないならば、その組み立て途中のＩＰヘッダ省略パケットを一時蓄積して終了する（Ｓ８１５）。
（Ｓ８０８）Flagが「最後」であるならば、最初から最後までの全てのＡＬＰフレームを受信できたか否かを判定する。
（Ｓ８０９）もし、途中抜けのＡＬＰフレームがあるならば、そのＡＬＰフレームが受信されるか、再送待ちタイマが満了になるまで待つ。
（Ｓ８１０）途中抜けのＡＬＰフレームがなく、ＡＬＰヘッダのFlagが「ＩＰヘッダを含む」になっていたらＳ８１３、そうでなければＳ８１１、及びＳ８１２の処理を実行する。
（Ｓ８１１）ＩＰヘッダが省略されている場合、全てのＡＬＰフレームから再構成されたひとつのＩＰヘッダ省略パケットについて、ＩＰヘッダ管理テーブルを検索し、ＡＬＰヘッダのFlowIDに対応するＩＰヘッダを取得する。
（Ｓ８１２）取得したＩＰヘッダを、組み立てられたＩＰヘッダ省略パケットに付加して、ＴＣＰ／ＩＰパケットを再構成する。
（Ｓ８１３）ＩＰヘッダが省略されていない場合、単に全てのＡＬＰフレームからひとつのＴＣＰ／ＩＰパケットを再構成する。
（Ｓ８０２）CRCからＡＬＰフレームの正常受信を確認し、SEQからＡＬＰフレームの順序を確認し、LENからＡＬＰフレームのデータ長を確認する。このとき、ＡＬＰフレームが異常であれば、そのＡＬＰフレームを廃棄する（Ｓ８１４）。
（Ｓ８０３）ＡＬＰヘッダに含まれるFlowIDが、ＩＰヘッダ管理テーブルに登録されているか否かを確認する。既に登録されていれば、ＡＬＰフレームの組み立てを行う（Ｓ８０６）。
（Ｓ８０４）FlowIDがＩＰヘッダ管理テーブルに登録されていなければ、ＡＬＰフレームがＩＰヘッダを含んでいるか否かを確認する。これは、ＡＬＰヘッダのFlagを確認することにより判断できる。ＡＬＰヘッダのFlagが「ＩＰヘッダを含まない」になっていたならば、そのＡＬＰフレームを廃棄する（Ｓ８１４）。
（Ｓ８０５）ＡＬＰヘッダのFlagが「ＩＰヘッダを含む」になっていたならば、ＩＰヘッダ管理テーブルに、一意のFlowIDと発／着ＩＰアドレスとＩＰヘッダの情報とを登録する。
（Ｓ８０６）ＡＬＰヘッダのFlag「最初」「最後」「継続」とSEQとに基づいて、ＡＬＰフレームを１つのＩＰヘッダ省略パケットに組み立てる。
（Ｓ８０７）Flagが「最後」か否かを判定する。Flagが「最後」でないならば、その組み立て途中のＩＰヘッダ省略パケットを一時蓄積して終了する（Ｓ８１５）。
（Ｓ８０８）Flagが「最後」であるならば、最初から最後までの全てのＡＬＰフレームを受信できたか否かを判定する。
（Ｓ８０９）もし、途中抜けのＡＬＰフレームがあるならば、そのＡＬＰフレームが受信されるか、再送待ちタイマが満了になるまで待つ。
（Ｓ８１０）途中抜けのＡＬＰフレームがなく、ＡＬＰヘッダのFlagが「ＩＰヘッダを含む」になっていたらＳ８１３、そうでなければＳ８１１、及びＳ８１２の処理を実行する。
（Ｓ８１１）ＩＰヘッダが省略されている場合、全てのＡＬＰフレームから再構成されたひとつのＩＰヘッダ省略パケットについて、ＩＰヘッダ管理テーブルを検索し、ＡＬＰヘッダのFlowIDに対応するＩＰヘッダを取得する。
（Ｓ８１２）取得したＩＰヘッダを、組み立てられたＩＰヘッダ省略パケットに付加して、ＴＣＰ／ＩＰパケットを再構成する。
（Ｓ８１３）ＩＰヘッダが省略されていない場合、単に全てのＡＬＰフレームからひとつのＴＣＰ／ＩＰパケットを再構成する。
図９は、ＰＤＳＮ１におけるＩＰパケットを受信した際のフローチャートである。
（Ｓ９０１）ＩＰパケットのＩＰヘッダを抽出する。ＩＰヘッダには、発ＩＰアドレス及び着ＩＰアドレスが含まれる。
（Ｓ９０２）受信したＩＰパケットが、ＰＤＳＮ１で処理すべき制御用ＩＰパケットか否かを判定する。処理対象の制御用ＩＰパケットであれば、その応答パケットを返信する（Ｓ９１１）。
（Ｓ９０３）制御用ＩＰパケットでないならば、ＩＰヘッダ管理テーブルに、その発／着ＩＰアドレスとＩＰヘッダの情報との組が登録されているか否かを判定する。
（Ｓ９０４）発／着ＩＰアドレスの組が登録されているならば、ＩＰヘッダ管理テーブルからFlowIDを取得する。
（Ｓ９０５）受信したＩＰパケットからＩＰヘッダ部分を削除し、ＩＰヘッダ省略パケットを生成する。
（Ｓ９０６）発／着ＩＰアドレスの組が登録されていなければ、ＩＰヘッダ管理テーブルに、発／着ＩＰアドレスと、一意なFlowIDとを登録する。このとき、ＩＰヘッダは付加されたままである。
（Ｓ９０７）Ｓ９０５で生成されたＩＰヘッダ省略パケット又はＳ９０６の処理を通過したＩＰパケットを、無線リンクに対応したパケット長に分割する。
（Ｓ９０８）分割パケットそれぞれにＡＬＰヘッダを付加し、ＡＬＰフレームを生成する。ＡＬＰヘッダには、FlowID、CRC、SEQ及びLENが含まれる。このとき、ＩＰヘッダを削除していれば（Ｓ９０５）、Flagは「IPヘッダを含まない」とされ、ＩＰヘッダを付加したままであれば（Ｓ９０７）、Flagは「IPヘッダを含む」とされる。また、分割パケットにはそれぞれ、「最初」「最後」「継続」のいずれかがFlagに設定され、SEQが設定される。更に、データ部のデータ属性に応じて（例えば動画像データ、音声データ、ファイルデータ等）、「再送回数」をFlagに設定する。
（Ｓ９０９）ＡＬＰフレーム毎に、ＵＤＰ／ＩＰヘッダを付加する。宛先ＩＰアドレスのＡＴを収容するＢＳへ適切に送信するためである。
（Ｓ９１０）ＡＬＰフレームを、シーケンス番号順にＢＳへ送信する。
（Ｓ９０２）受信したＩＰパケットが、ＰＤＳＮ１で処理すべき制御用ＩＰパケットか否かを判定する。処理対象の制御用ＩＰパケットであれば、その応答パケットを返信する（Ｓ９１１）。
（Ｓ９０３）制御用ＩＰパケットでないならば、ＩＰヘッダ管理テーブルに、その発／着ＩＰアドレスとＩＰヘッダの情報との組が登録されているか否かを判定する。
（Ｓ９０４）発／着ＩＰアドレスの組が登録されているならば、ＩＰヘッダ管理テーブルからFlowIDを取得する。
（Ｓ９０５）受信したＩＰパケットからＩＰヘッダ部分を削除し、ＩＰヘッダ省略パケットを生成する。
（Ｓ９０６）発／着ＩＰアドレスの組が登録されていなければ、ＩＰヘッダ管理テーブルに、発／着ＩＰアドレスと、一意なFlowIDとを登録する。このとき、ＩＰヘッダは付加されたままである。
（Ｓ９０７）Ｓ９０５で生成されたＩＰヘッダ省略パケット又はＳ９０６の処理を通過したＩＰパケットを、無線リンクに対応したパケット長に分割する。
（Ｓ９０８）分割パケットそれぞれにＡＬＰヘッダを付加し、ＡＬＰフレームを生成する。ＡＬＰヘッダには、FlowID、CRC、SEQ及びLENが含まれる。このとき、ＩＰヘッダを削除していれば（Ｓ９０５）、Flagは「IPヘッダを含まない」とされ、ＩＰヘッダを付加したままであれば（Ｓ９０７）、Flagは「IPヘッダを含む」とされる。また、分割パケットにはそれぞれ、「最初」「最後」「継続」のいずれかがFlagに設定され、SEQが設定される。更に、データ部のデータ属性に応じて（例えば動画像データ、音声データ、ファイルデータ等）、「再送回数」をFlagに設定する。
（Ｓ９０９）ＡＬＰフレーム毎に、ＵＤＰ／ＩＰヘッダを付加する。宛先ＩＰアドレスのＡＴを収容するＢＳへ適切に送信するためである。
（Ｓ９１０）ＡＬＰフレームを、シーケンス番号順にＢＳへ送信する。
図１０は、ＡＴ４におけるＩＰパケットを送信する際のフローチャートである。
（Ｓ１００１）ＩＰパケットのＩＰヘッダを抽出する。ＩＰヘッダには、発／着ＩＰアドレスが含まれる。
（Ｓ１００２）ＩＰヘッダ管理テーブルに、その発／着ＩＰアドレスの組が登録されているか否かを判定する。
（Ｓ１００３）発／着ＩＰアドレスの組が登録されているならば、ＩＰヘッダ管理テーブルからFlowIDを取得する。
（Ｓ１００４）発／着ＩＰアドレスの組が登録されていなければ、ＩＰヘッダ管理テーブルに、発／着ＩＰアドレスと、ＩＰヘッダの情報と、一意なFlowIDとを登録する。このとき、ＩＰヘッダは付加されたままである。
（Ｓ１００５）Ｓ１００３に続いて、送信すべきＩＰパケットからＩＰヘッダ部分を削除し、ＩＰヘッダ省略パケットにする。
（Ｓ１００６）Ｓ１００５で生成されたＩＰヘッダ省略パケット又はＳ１００４の処理を通過したＩＰパケットを、無線リンクに対応したパケット長に分割する。
（Ｓ１００７）分割パケットそれぞれにＡＬＰヘッダを付加し、ＡＬＰフレームを生成する。ＡＬＰヘッダには、FlowID、CRC、SEQ及びLENが含まれる。このとき、ＩＰヘッダを削除していれば（Ｓ１００５）、Flagは「IPヘッダを含まない」とされ、ＩＰヘッダを付加したままであれば（Ｓ１００４）、Flagは「IPヘッダを含む」とされる。また、分割パケットにはそれぞれ、「最初」「最後」「継続」のいずれかがFlagに設定され、SEQが設定される。更に、データ部のデータ属性に応じて、「再送回数」を決定する。ここで決定された「再送回数」に応じて、無線リンクでの再送が実現される。
（Ｓ１００８）ＡＬＰフレームを、シーケンス番号順にＢＳへ送信する。
（Ｓ１００２）ＩＰヘッダ管理テーブルに、その発／着ＩＰアドレスの組が登録されているか否かを判定する。
（Ｓ１００３）発／着ＩＰアドレスの組が登録されているならば、ＩＰヘッダ管理テーブルからFlowIDを取得する。
（Ｓ１００４）発／着ＩＰアドレスの組が登録されていなければ、ＩＰヘッダ管理テーブルに、発／着ＩＰアドレスと、ＩＰヘッダの情報と、一意なFlowIDとを登録する。このとき、ＩＰヘッダは付加されたままである。
（Ｓ１００５）Ｓ１００３に続いて、送信すべきＩＰパケットからＩＰヘッダ部分を削除し、ＩＰヘッダ省略パケットにする。
（Ｓ１００６）Ｓ１００５で生成されたＩＰヘッダ省略パケット又はＳ１００４の処理を通過したＩＰパケットを、無線リンクに対応したパケット長に分割する。
（Ｓ１００７）分割パケットそれぞれにＡＬＰヘッダを付加し、ＡＬＰフレームを生成する。ＡＬＰヘッダには、FlowID、CRC、SEQ及びLENが含まれる。このとき、ＩＰヘッダを削除していれば（Ｓ１００５）、Flagは「IPヘッダを含まない」とされ、ＩＰヘッダを付加したままであれば（Ｓ１００４）、Flagは「IPヘッダを含む」とされる。また、分割パケットにはそれぞれ、「最初」「最後」「継続」のいずれかがFlagに設定され、SEQが設定される。更に、データ部のデータ属性に応じて、「再送回数」を決定する。ここで決定された「再送回数」に応じて、無線リンクでの再送が実現される。
（Ｓ１００８）ＡＬＰフレームを、シーケンス番号順にＢＳへ送信する。
図１１は、最終的にＩＰパケットの受信に成功するような場合におけるＢＳとＡＴとの間の再送シーケンス図である。
ＢＳとＡＴとの間の無線リンクでエラーが発生した場合、ＰＤＳＮから受信したＡＬＰフレームにおけるＡＬＰヘッダの「再送回数」に応じて再送する。再送方法は、受信装置が送信装置に対して、各ＡＬＰフレームに対するＡＣＫ又はＮＡＫを送信するものである。ＡＣＫ又はＮＡＫの判断は、ＡＬＰフレームのＣＲＣの結果に基づく。ＮＡＫを受信した装置は、エラーとなったＡＬＰフレームを再送する。
再送回数は、無線リンクを確立した時、又はポート番号などで識別可能なアプリケーション毎に指定することが可能である。リアルタイム性が要求される属性のデータであれば、再送回数は少なく設定し、データ通信の信頼性を必要とする属性のデータであれば、再送回数を多く設定することができる。１回再送をすると、ＡＬＰフレームのFlag部分の再送回数を１減少させ、その値が０になると再送を止め、そのＡＬＰフレームを廃棄する。廃棄されたＡＬＰフレームについてのエラー訂正は、トランスポート層のような上位層によって行われる。尚、無線リンクにおけるＡＬＰフレームの送信は、送信先ＡＴが無線帯域の割当を受けている限り複数送信可能とするが、再送ＡＬＰフレームは新規ＡＬＰフレームより優先されることとする。
図１１によれば、ＡＬＰフレームに設定された再送回数が３回の場合である。ＡＬＰフレームは、エラーの発生状況によってはシーケンス番号順に受信されないことがある。そのため、ＡＴには、受信バッファと、ＡＬＰフレームをSEQ順に整列させる機能とが必要とされる。再送によって抜けていたＡＬＰフレームが受信されると（例えば図１１によればＡＬＰ２）、上位層パケットが再構成される。また、再送のＡＬＰフレームは、新規のＡＬＰフレームより先にＡＴへ送信されるので、その間にＢＳに到着したＡＬＰフレームはＢＳでバッファされる。
図１２は、最終的にＩＰパケットの受信に失敗するような場合におけるＢＳとＡＴとの間の再送シーケンス図である。
図１２によれば、ＡＬＰフレームに設定された再送回数が１回の場合である。ＢＳから送信されたＡＬＰフレームに対して、無線リンクでエラーが発生すると、ＡＴではＡＬＰフレームが送信されたか否かについて判断できない。そこで、ＡＴの受信バッファについて、再送待ちタイマが備えられる。この再送待ちタイマには、ＡＴからみて、ＢＳへＡＣＫ／ＮＡＫを送信してから、再送されたＡＬＰフレームを受信するまでに要する時間に、再送回数を乗算した時間が設定される。再送待ちタイマ内に、再送されたＡＬＰフレームが受信されない場合は、エラーパケットとして、上位層にパケットを引き渡すことができる。
図１３は、本発明におけるＰＤＳＮの機能構成図である。
図１１によれば、ＰＤＳＮ１は、ＨＡ５と通信するＩＰパケット通信インタフェース１０１と、ＢＳ８と通信するＡＬＰフレーム通信インタフェース１０２と、ＩＰヘッダ管理テーブル蓄積部１０３とを有する。また、ＰＤＳＮ１は、ＩＰパケットに対して、ＩＰヘッダ削除部１０４と、パケット分割部１０５と、ＡＬＰヘッダ付加部１０６と、再送回数指定部１０７と、制御用ＩＰパケット応答部１１２とがある。更に、ＰＤＳＮ１は、ＡＬＰフレームに対してＡＬＰヘッダ確認部１０８と、FlowID登録部１０９と、パケット組立部１１０と、ＩＰヘッダ付加部１１１と、一時蓄積部１１３とを有する。
制御用ＩＰパケット応答部１１２は、ＩＰパケット通信インタフェース１０１から通知された制御用ＩＰパケットに対して、その応答パケットを返信する。
ＩＰヘッダ削除部１０４は、ＩＰヘッダ管理テーブル蓄積部１０３のＩＰヘッダ管理テーブルについて、ＩＰパケット通信インタフェース１０１から通知されたＩＰパケットの発／着ＩＰアドレスの組が登録されているか否かを判定する。当該組が登録されていれば、ＩＰヘッダ部分を削除して、ＩＰヘッダ省略パケットのみにする。一方、当該組が登録されていなければ、ＩＰヘッダ部分は付加されたままとし、ＩＰヘッダ管理テーブルに、発／着ＩＰアドレスと、ＩＰヘッダの情報と、一意なFlowIDとを登録する。
パケット分割部１０５は、ＩＰヘッダ削除部１０４から通知されたパケットを、無線リンクに対応したパケット長に分割する。
ＡＬＰヘッダ付加部１０６は、分割パケットそれぞれにＡＬＰヘッダを付加し、ＡＬＰフレームを生成する。ＡＬＰヘッダには、FlowID、CRC、SEQ、LEN、Flagが含まれる。それらの内容は前述したとおりである。更に、ＡＬＰフレーム毎に、宛先ＩＰアドレスのＡＴを収容するＢＳへ適切に送信するために、ＵＤＰ／ＩＰヘッダを付加する。そして、ＵＤＰ／ＩＰヘッダが付加されたＡＬＰフレームは、シーケンス番号順に、ＡＬＰフレーム通信インタフェース１０２へ通知される。
再送回数指定部１０７は、元のＩＰパケットのデータ特性に応じた再送回数をＡＬＰフレームのヘッダに指定する。再送回数は元のＩＰパケットのデータ特性に応じてあらかじめ決定しておくか、無線リンクの確立時に指定することができる。
ＡＬＰヘッダ確認部１０８は、ＡＬＰヘッダについて、CRC、SEQ及びLENから当該ＡＬＰフレームが異常か否かを確認する。異常と判断されれば、そのＡＬＰフレームを廃棄する。
FlowID登録部１０９は、ＡＬＰヘッダに含まれるFlowIDが、ＩＰヘッダ管理テーブルに登録されているか否かを確認する。ここで、FlowIDがＩＰヘッダ管理テーブルに登録されていなければ、ＡＬＰフレームがＩＰヘッダを含んでいるか否かを、Flagから確認する。ＡＬＰヘッダのFlagが「ＩＰヘッダを含む」になっていたならば、ＩＰヘッダ管理テーブルに、一意のFlowIDと、発／着ＩＰアドレスと、ＩＰヘッダの情報とを登録する。
パケット組立部１１０は、ＡＬＰヘッダのFlag「最初」「最後」「継続」とSEQとに基づいて、ＡＬＰフレームを１つの元のパケットに組み立てる。Flagが「最初」「継続」であるか、「最後」であっても「最初」から「最後」までのＡＬＰフレームが全て受信されていない場合は、一時蓄積部１１３に蓄積する。「最初」から「最後」までの全てのＡＬＰフレームが受信されるか、ＡＬＰフレームの再送待ちタイマが満了になったら、元のパケットを再構成する。
ＩＰヘッダ付加部１１１は、組み立てられたパケットがＩＰヘッダ省略パケットである場合、ＩＰヘッダ管理テーブルを検索し、FlowIDに対応するＩＰヘッダを取得し、ＩＰヘッダ省略パケットに付加し、ＩＰヘッダを再構成する。組み立てられたパケットがＩＰヘッダを含むＩＰパケットである場合、何もしない。このＩＰパケットはＩＰパケット通信インタフェース１０１に通知される。
図１４は、本発明におけるＡＴの機能構成図である。
図１４によれば、アプリケーション部４１４が、サーバ６との間でＴＣＰ／ＩＰパケットを送受信する。アプリケーション部４１４は、ＩＰヘッダ削除部４０４へＴＣＰ／ＩＰパケットを送信し、ＩＰヘッダ付加部４１１からＴＣＰ／ＩＰパケットを受信する。その他の機能部は、制御用ＩＰパケット応答部１１２以外は、全て同じである。
図１５は、従来のＰＰＰにおける認証シーケンスである。これに対し、図１６は、本発明のＰＤＳＮによって実現された認証シーケンスである。
図１５によれば、極めて多くの制御パケットの送受信が無線リンク上で行われることとなる。これに対し、図１６によれば、ＰＤＳＮが認証サーバに対するアクセスを担うために、認証シーケンスが極めて簡素化される。最初に、ＡＴがＢＳを介してＰＤＳＮへ認証要求を送信する。認証要求には、無線リンクに関するパラメータ (再送回数など)や、ＡＴに関する情報（端末ＩＤ等）が含まれる。これに対し、ＰＤＳＮが、認証サーバとの間で認証シーケンスを行い、認証が確認できたとき、ＰＤＳＮは、ＢＳを介してＡＴへ認証確認を送信する。認証確認には、ＡＴに割り当てられるべきＩＰアドレスが含まれる。また、認証確認を受信したＢＳは、認証要求を受信した無線リンクの特性をＡＴとの無線リンクに設定する。
図１７は、従来のハンドオフシーケンスである。これに対し、図１８は、本発明のハンドオフシーケンスである。
ＡＴが移動するなどして、収容されるＡＮＴＳが変わることをハンドオフという。ＨＲＰＤシステムにおけるハンドオフには次の３種類が存在する。
（１）ＡＮＴＳのみが変わるＡＮＴＳ間ハンドオフ
（２）ＡＮＴＳ及びＰＣＦが変わるＰＣＦ間ハンドオフ
（３）ＡＮＴＳ、ＰＣＦ及びＰＤＳＮが変わるＰＤＳＮ間ハンドオフ
（１）ＡＮＴＳのみが変わるＡＮＴＳ間ハンドオフ
（２）ＡＮＴＳ及びＰＣＦが変わるＰＣＦ間ハンドオフ
（３）ＡＮＴＳ、ＰＣＦ及びＰＤＳＮが変わるＰＤＳＮ間ハンドオフ
図１７は、ＰＣＦ間ハンドオフの場合の一例である。ＡＴがハンドオフしたとき（図１７では、旧ＡＮＴＳから新ＡＮＴＳにＡＴが移動）、ハンドオフ開始後、旧ＡＮＴＳに残されたＡＴ向けのデータ、即ち送信できなかったデータを、新ＡＮＴＳに送信する。新ＡＮＴＳは、移動してきたＡＴにデータを送信する。送信は、旧ＡＮＴＳからのデータが到着してから行われるため、旧ＡＮＴＳからのデータ転送を行っている間、ＡＴはデータ受信を行うことができない。
現在のＨＲＰＤシステムでは、ＡＴが移動したために送信できなかったデータについて、移動前のＡＮＴＳから移動先ＡＮＴＳに転送する必要がある。それが完了するまでは、データの順番誤りが発生しないように移動先ＡＮＴＳからの送信は行われない。ハンドオフ発生時に通信断が発生することにより、ＩＰ通信を行うアプリケーションの挙動に影響を与える。
これに対し、図１８によれば、ＢＳが残りのＡＬＰフレームに対する処理を担う。ＡＴは、電波状況によってハンドオフが必要と判断すると、ＰＤＳＮに対してハンドオフ開始通知を行う。ハンドオフ開始通知には移動先のＢＳ（新ＢＳ）に関する情報を付加する。旧ＢＳは、ハンドオフ開始通知に現在旧ＢＳにあるＡＬＰフレームのFlowID、シーケンス番号を付加する。ここで、旧ＢＳは可能な限り、ＡＴに残存しているＡＬＰフレームを送信する。次に、新ＢＳに無線リソースが確保されると、ＡＴはハンドオフを開始する。これに対し、ＰＤＳＮは、ハンドオフ開始通知を受信すると、新／旧ＢＳにＡＬＰフレームを送信する。新ＢＳに対しては、ＡＬＰフレームをハンドオフ開始通知で通知したFlowID及びシーケンス番号により送信する。これにより、ＡＴは新／旧両方のＢＳからＡＬＰフレームを受信することができる。重複して受信したＡＬＰフレームは、シーケンス番号により、どちらか一方を選択して受信する。ＡＴがハンドオフを終了すると、新ＢＳ経由でＰＤＳＮに対してハンドオフ完了通知を行う。ＰＤＳＮは、ＡＬＰフレームを旧ＢＳに送信するのを中止し、新ＢＳのみに送信する。
前述した本発明の種々の実施形態において、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
１ ＰＤＳＮ、パケット交換ノード
１０１ ＩＰパケット通信インタフェース
１０２、４０２ ＡＬＰフレーム通信インタフェース
１０３、４０３ ＩＰヘッダ管理テーブル
１０４、４０４ ＩＰヘッダ削除部
１０５、４０５ パケット分割部
１０６、４０６ ＡＬＰヘッダ付加部
１０７、４０７ 再送回数指定部
１０８、４０８ ＡＬＰヘッダ確認部
１０９、４０９ FlowID登録部
１１０、４１０ パケット組立部
１１１、４１１ ＩＰヘッダ付加部
１１２ 制御用ＩＰパケット応答部
１１３、４１３ 一時蓄積部
２ ＰＣＦ、パケット制御装置
３ ＡＮＴＳ、アクセスネットワークトランシーバシステム
４ ＡＴ、アクセスターミナル、無線通信端末
４１４ アプリケーション部
５ ＨＡ、ホームエージェント
６ サーバ
７ インターネット
８ ＢＳ、基地局
１０１ ＩＰパケット通信インタフェース
１０２、４０２ ＡＬＰフレーム通信インタフェース
１０３、４０３ ＩＰヘッダ管理テーブル
１０４、４０４ ＩＰヘッダ削除部
１０５、４０５ パケット分割部
１０６、４０６ ＡＬＰヘッダ付加部
１０７、４０７ 再送回数指定部
１０８、４０８ ＡＬＰヘッダ確認部
１０９、４０９ FlowID登録部
１１０、４１０ パケット組立部
１１１、４１１ ＩＰヘッダ付加部
１１２ 制御用ＩＰパケット応答部
１１３、４１３ 一時蓄積部
２ ＰＣＦ、パケット制御装置
３ ＡＮＴＳ、アクセスネットワークトランシーバシステム
４ ＡＴ、アクセスターミナル、無線通信端末
４１４ アプリケーション部
５ ＨＡ、ホームエージェント
６ サーバ
７ インターネット
８ ＢＳ、基地局
Claims (10)
- ＩＰパケットを、無線アクセスネットワークを介して転送するパケットデータ交換ノードにおいて、
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
受信したＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、前記ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、前記ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、前記ＩＰパケットの発／着ＩＰアドレスに対応した前記フロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、前記ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、前記フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
を有し、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とするパケットデータ交換ノード。 - 前記分割ヘッダ付加手段は、前記分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、前記ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、前記分割パケットのヘッダに更に含めており、
受信した前記分割パケットが前記ＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報と前記フロー識別子とを前記ＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
前記パケット組立手段は、前記最初、最後又は継続の情報と前記シーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てることを特徴とする請求項１に記載のパケットデータ交換ノード。 - ＩＰの制御要求パケットを受信した際に、ＩＰの制御応答パケットを返信する制御用ＩＰパケット応答手段を更に有し、前記ＩＰの制御要求パケットを転送しないように構成されていることを特徴とする請求項１又は２に記載のパケットデータ交換ノード。
- 前記分割ヘッダ付加手段は、元のＩＰパケットのデータ部に含まれるデータ属性に応じた再送回数を示す情報を前記分割パケットのヘッダに更に含め、前記分割パケットを中継する装置が、無線リンクでエラーが発生した当該分割パケットを、最大、前記再送回数だけ再送することができるようにすることを特徴とする請求項１から３のいずれか１項に記載のパケットデータ交換ノード。
- ＩＰパケットを、無線アクセスネットワークを介して転送する端末において、
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
送信すべきＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、前記ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、前記ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、前記ＩＰパケットの発／着ＩＰアドレスに対応した前記フロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、前記ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、前記フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
を有し、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とする端末。 - 前記分割ヘッダ付加手段は、前記分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、前記ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、前記分割パケットのヘッダに更に含めており、
受信した前記分割パケットが前記ＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報と前記フロー識別子とを前記ＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
前記パケット組立手段は、前記最初、最後又は継続の情報と前記シーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てることを特徴とする請求項５に記載の端末。 - ＩＰパケットを、無線アクセスネットワークを介して転送する装置におけるプログラムにおいて、
発／着ＩＰアドレス毎にフロー識別子を対応付けたＩＰヘッダ管理テーブル蓄積手段と、
送信すべきＩＰパケットについて、ＩＰヘッダ部を削除するＩＰヘッダ削除手段と、前記ＩＰヘッダ部が削除されたＩＰヘッダ省略パケット毎に、無線リンクに対応した複数のパケットに分割するパケット分割手段と、前記ＩＰヘッダ管理テーブルを用いて、分割パケットのヘッダに、前記ＩＰパケットの発／着ＩＰアドレスに対応した前記フロー識別子を付加して該分割パケットを送信する分割ヘッダ付加手段と、
受信した分割パケットについて、同一フロー識別子を有する該分割パケットを１つのＩＰヘッダ省略パケットに組み立てるパケット組立手段と、前記ＩＰヘッダ管理テーブルを用いて、組み立てられた該ＩＰヘッダ省略パケットに、前記フロー識別子に対応するＩＰヘッダを付加するＩＰヘッダ付加手段と
としてコンピュータを機能させ、ＩＰパケットを無線アクセスネットワークを介して転送することを特徴とするプログラム。 - 前記分割ヘッダ付加手段は、前記分割パケットのデータ部にＩＰヘッダを含むか否かの情報と、前記ＩＰパケットの最初、最後又は継続の情報と、シーケンス番号情報とを、前記分割パケットのヘッダに更に含めており、
受信した前記分割パケットが前記ＩＰヘッダを含む場合、その発／着ＩＰアドレス及びＩＰヘッダの情報と前記フロー識別子とを前記ＩＰヘッダ管理テーブル蓄積手段に登録するフロー識別子登録手段を更に有しており、
前記パケット組立手段は、前記最初、最後又は継続の情報と前記シーケンス番号情報とに基づいて、複数の分割パケットから１つのＩＰヘッダ省略パケットを組み立てるようにコンピュータを機能させることを特徴とする請求項７に記載のプログラム。 - ＩＰの制御要求パケットを受信した際に、ＩＰの制御応答パケットを返信する制御用ＩＰパケット応答手段を更に有し、前記ＩＰの制御要求パケットを転送しないようにコンピュータを機能させることを特徴とする請求項７又は８に記載のプログラム。
- 前記分割ヘッダ付加手段は、前記分割パケットのデータ部に含まれるデータ属性に応じた再送回数を示す情報を前記分割パケットのヘッダに更に含め、前記分割パケットを中継する装置が、無線リンクでエラーが発生した当該分割パケットを、最大、前記再送回数だけ再送することができるようにすることを特徴とする請求項７から９のいずれか１項に記載のプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004020021A JP2005217626A (ja) | 2004-01-28 | 2004-01-28 | 無線アクセスネットワークを介するパケットデータ交換ノード、端末及びそのプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004020021A JP2005217626A (ja) | 2004-01-28 | 2004-01-28 | 無線アクセスネットワークを介するパケットデータ交換ノード、端末及びそのプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005217626A true JP2005217626A (ja) | 2005-08-11 |
Family
ID=34904069
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004020021A Withdrawn JP2005217626A (ja) | 2004-01-28 | 2004-01-28 | 無線アクセスネットワークを介するパケットデータ交換ノード、端末及びそのプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005217626A (ja) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006270914A (ja) * | 2005-02-23 | 2006-10-05 | Ntt Docomo Inc | センサ端末、センサ端末の制御方法 |
| WO2008136446A1 (ja) * | 2007-04-26 | 2008-11-13 | Kyocera Corporation | 無線通信システム、無線通信装置及び無線通信方法 |
| JP2008311974A (ja) * | 2007-06-15 | 2008-12-25 | Hitachi Communication Technologies Ltd | 通信システム、サーバ、制御装置および通信装置 |
| JP2009512343A (ja) * | 2005-10-11 | 2009-03-19 | クゥアルコム・インコーポレイテッド | 接続を確立するための基地局の方法及び装置 |
| JP2009512350A (ja) * | 2005-10-11 | 2009-03-19 | クゥアルコム・インコーポレイテッド | 接続を確立するための無線端末の方法および装置 |
| JP2009516439A (ja) * | 2005-11-15 | 2009-04-16 | テレコム・イタリア・エッセ・ピー・アー | 無線通信ネットワークにおけるシグナリングメッセージを利用する方法 |
| JP2012500598A (ja) * | 2008-08-20 | 2012-01-05 | クゥアルコム・インコーポレイテッド | ワイヤレス通信ネットワーク内でのヘッダ圧縮の方法 |
| US8184615B2 (en) | 2005-10-12 | 2012-05-22 | Qualcomm Incorporated | Wireless terminal methods and apparatus for establishing connections |
| JP2012199958A (ja) * | 2007-04-25 | 2012-10-18 | Qualcomm Inc | 順方向リンク及び逆方向リンクのサービングアクセスポイントの変更 |
| JP2013526173A (ja) * | 2010-04-21 | 2013-06-20 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Ｍｔｃデバイスの帯域幅削減 |
| JP2013530614A (ja) * | 2010-05-10 | 2013-07-25 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | シングルブロックパケットアクセス手続きにおけるプロトコルオーバーヘッドの低減 |
-
2004
- 2004-01-28 JP JP2004020021A patent/JP2005217626A/ja not_active Withdrawn
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006270914A (ja) * | 2005-02-23 | 2006-10-05 | Ntt Docomo Inc | センサ端末、センサ端末の制御方法 |
| JP2009512343A (ja) * | 2005-10-11 | 2009-03-19 | クゥアルコム・インコーポレイテッド | 接続を確立するための基地局の方法及び装置 |
| JP2009512350A (ja) * | 2005-10-11 | 2009-03-19 | クゥアルコム・インコーポレイテッド | 接続を確立するための無線端末の方法および装置 |
| US8184615B2 (en) | 2005-10-12 | 2012-05-22 | Qualcomm Incorporated | Wireless terminal methods and apparatus for establishing connections |
| US8238948B2 (en) | 2005-11-15 | 2012-08-07 | Telecom Italia S.P.A. | Method for exploiting signalling messages in a wireless communication network |
| JP2009516439A (ja) * | 2005-11-15 | 2009-04-16 | テレコム・イタリア・エッセ・ピー・アー | 無線通信ネットワークにおけるシグナリングメッセージを利用する方法 |
| US8768357B2 (en) | 2007-04-25 | 2014-07-01 | Qualcomm Incorporated | Changes of forward-link and reverse-link serving access points |
| JP2012199958A (ja) * | 2007-04-25 | 2012-10-18 | Qualcomm Inc | 順方向リンク及び逆方向リンクのサービングアクセスポイントの変更 |
| JP2015092678A (ja) * | 2007-04-25 | 2015-05-14 | クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ | 順方向リンク及び逆方向リンクのサービングアクセスポイントの変更 |
| WO2008136446A1 (ja) * | 2007-04-26 | 2008-11-13 | Kyocera Corporation | 無線通信システム、無線通信装置及び無線通信方法 |
| JPWO2008136446A1 (ja) * | 2007-04-26 | 2010-07-29 | 京セラ株式会社 | 無線通信システム、無線通信装置及び無線通信方法 |
| JP2008311974A (ja) * | 2007-06-15 | 2008-12-25 | Hitachi Communication Technologies Ltd | 通信システム、サーバ、制御装置および通信装置 |
| JP2012500598A (ja) * | 2008-08-20 | 2012-01-05 | クゥアルコム・インコーポレイテッド | ワイヤレス通信ネットワーク内でのヘッダ圧縮の方法 |
| US8867566B2 (en) | 2008-08-20 | 2014-10-21 | Qualcomm Incorporated | Methods of header compression within a wireless communications network |
| JP2013526173A (ja) * | 2010-04-21 | 2013-06-20 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Ｍｔｃデバイスの帯域幅削減 |
| US9445215B2 (en) | 2010-04-21 | 2016-09-13 | Telefonaktiebolaget Lm Ericsson (Publ) | MTC device bandwidth reduction |
| JP2013530614A (ja) * | 2010-05-10 | 2013-07-25 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | シングルブロックパケットアクセス手続きにおけるプロトコルオーバーヘッドの低減 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Ott et al. | A disconnection-tolerant transport for drive-thru internet environments | |
| JP4164365B2 (ja) | デュアル・プロキシ装置を設けることによる無線インタフェースを介するｔｃｐ性能の改良技術 | |
| JP6025880B2 (ja) | データ伝送方法、装置及びシステム | |
| CN101385375B (zh) | 用于为切换而配置链路层实体的技术 | |
| JP5089584B2 (ja) | 動的で耐性のあるヘッダ圧縮 | |
| JP3802420B2 (ja) | パケット交換データ伝送におけるデータ・パケット番号付加方式 | |
| JP4005508B2 (ja) | ヘッダ圧縮におけるコンテキスト情報の再配置 | |
| JP4652358B2 (ja) | パケット交換データ伝送におけるデータ・パケット番号付加方式 | |
| JP4188774B2 (ja) | フレーム送受信システム、フレーム送信装置、フレーム受信装置、及びフレーム送受信方法 | |
| Wang et al. | Mobile-end transport protocol: an alternative to TCP/IP over wireless links | |
| US20090103445A1 (en) | Method and apparatus for enhancing various pdcp and layer 2 operations | |
| US8400982B2 (en) | Method for handling correctly received but header compression failed packets | |
| US7848280B2 (en) | Tunnel overhead reduction | |
| JP2003504968A (ja) | 移動通信システムにおいて高信頼リンクを提供する技術 | |
| JP2003283592A (ja) | ワイヤレスコミュニケーションシステムのデータ伝送確認方法 | |
| WO2005109791A2 (en) | A sub-segment based transport layer protocol for wireless medium | |
| KR101169581B1 (ko) | 상이한 프로토콜들에 따르는 네트워크들 사이의 끊김 없는 전환을 제공하기 위한 방법 | |
| WO2014131153A1 (zh) | 数据传输方法、系统及代理设备 | |
| CN102780712B (zh) | 会话的切换方法及装置 | |
| WO2007139161A1 (ja) | 移動端末及び通信方法 | |
| CN111385268A (zh) | 一种数据包头压缩确认方法及通信设备 | |
| JP2005217626A (ja) | 無線アクセスネットワークを介するパケットデータ交換ノード、端末及びそのプログラム | |
| JP5124591B2 (ja) | Ｒａｎにおける連続するデータユニットの表示の方法 | |
| JP4911222B2 (ja) | 通信システム、通信システムにおける通信方法、及び中継装置 | |
| WO2017133595A1 (zh) | 数据处理的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20070403 |