(57)【要約】圧縮ヘッダを有するパケットを転送するパケットネットワークにおけるヘッダ圧縮コンテキストを再配置する方法。接続が、移動体端末と第１ネットワークエンティティとの間で確立され、パケットのヘッダの圧縮と伸張で使用されるコンテキスト情報が、前記移動体端末と前記第１のネットワークエンティティで蓄積される。前記移動体端末における及び前記第１のネットワークエンティティにおいて、コンテキスト情報のアップデートが中止され、その後、前記圧縮伸張のコンテキスト情報のスナップショットが取り込まれ、前記第１のネットワークエンティティに蓄積される。前記第１のネットワークエンティティと前記移動体端末との間の接続が、前記移動体端末と第２のネットワークエンティティとの間の接続に変更される。前記第１のネットワークエンティティが蓄積するコンテキスト情報スナップショットを、第２のネットワークエンティティのコンテキスト情報として、前記第２のネットワークエンティティ転送し、第２のネットワークエンティティのコンテキスト情報として、蓄積される。前記移動体端末と前記第２ネットワークエンティティにおいて前記蓄積されたコンテキスト情報が、前記パケットのヘッダの圧縮と伸張のために、使用される。
2004517580.tif 000002
【特許請求の範囲】
【請求項１】
圧縮ヘッダを有するパケットを転送するパケットネットワークにおけるヘッダ圧縮コンテキストを再配置する方法であって、
移動体端末と第１ネットワークエンティティとの間の接続を確立するステップであって、前記移動体端末と前記第１のネットワークエンティティでパケットのヘッダの圧縮と伸張で使用されるコンテキスト情報を蓄積するステップを含むステップと、
前記移動体端末における及び前記第１のネットワークエンティティにおけるコンテキスト情報のアップデートを中止するステップと、
前記第１のネットワークエンティティの前記圧縮伸張のコンテキスト情報のスナップショットを取り込むステップであって、前記第１ネットワークエンティティにおける前記コンテキスト情報スナップショットを蓄積するステップを含むステップと、
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更するステップであって、前記第１のネットワークエンティティが蓄積するコンテキスト情報スナップショットを、第２のネットワークエンティティのコンテキスト情報として、前記第２のネットワークエンティティ転送し、それを前記第２のネットワークエンティティのコンテキスト情報として前記第２のネットワークエンティティが蓄積するステップ、及び、前記パケットの前記ヘッダの圧縮と伸張のために、前記移動体端末と前記第２ネットワークエンティティにおいて前記蓄積されたコンテキスト情報を使用するステップとを含むステップと、
を有する前記ヘッダ圧縮コンテキストを再配置する方法。
【請求項２】
前記コンテキスト情報アップデーティングが、前記移動体端末と前記第１のネットワークエンティティ伸張装置が対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより中止されることを特徴とする請求項１記載の方法。
【請求項３】
前記移動体端末がアップリンクデータを圧縮し転送するのを中止させ、前記第１ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させことにより、前記前記コンテキスト情報アップデーティングが中止されることを特徴とする請求項１記載の方法。
【請求項４】
前記第１のネットワークエンティティにおける前記圧縮と伸張コンテキスト情報のスナップショットの前記取り込みが、前記転送されたアップリンクデータとダウンリンクデータが受信され、伸張されるまで、遅延されることを特徴とする、請求項３記載の方法。
【請求項５】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末からの圧縮／伸張受信確認信号を放棄することにより、中止することを特徴とする、請求項１記載の方法。
【請求項６】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末へ、圧縮／伸張受信確認信号を送信することを不能にすることにより、中止することを特徴とする、請求項１記載の方法。
【請求項７】
前記第１のネットワークエンティティにおける前記移動体端末が送信するコンテキストアップデート要求の検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへコンテキストアップデート要求を送信するステップと、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットを送信するステップとを有する、請求項５記載の方法。
【請求項８】
前記第１のネットワークエンティティにおける前記コンテキスト情報の同期外れの検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへコンテキストアップデート要求を送信するステップと、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットを送信するステップとを有する、請求項５記載の方法。
【請求項９】
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更する前に、前記第１のネットワークエンティティが蓄積した前記コンテキスト情報スナップショットを前記第２のネットワークエンティティに転送するステップを、有する請求項１記載の方法。
【請求項１０】
前記方法は、ＵＭＴＳシステムで実行されるローバスト・ヘッダ圧縮（ＲＯＨＣ）に従って使用されることを特徴とする請求項１記載の方法。
【請求項１１】
前記再配置を、少なくとも、部分的に、サービング無線ネットワーク・サブシステム（ＳＲＮＳ）再配置と同時に行うことを特徴とする請求項１０記載の方法。
【請求項１２】
圧縮されたヘッダが、移動体端末とネットワークエンティティとの間を転送されるネットワークであって、
移動体端末と第ネットワークエンティティとの間に接続が確立されるよう構成され、
パケットのヘッダの圧縮と伸張で使用されるコンテキスト情報が前記移動体端末と前記第１のネットワークエンティティで蓄積されるように構成され、
前記移動体端末における及び前記第１のネットワークエンティティにおけるコンテキスト情報アップデーティングが中止されるように構成され、
前記第１のネットワークエンティティの前記圧縮伸張のコンテキスト情報のスナップショットを取り込まれ、前記第１ネットワークエンティティにおいて蓄積されるように構成され、
前記第１のネットワークエンティティと前記移動体端末との間の接続が、前記移動体端末と第２のネットワークエンティティとの間の接続を変更するように構成され、
前記第１のネットワークエンティティが蓄積するコンテキスト情報スナップショットが、前記第２のネットワークエンティティのコンテキスト情報として、前記第２のネットワークエンティティに転送し、第２のネットワークエンティティに蓄積されるように構成され、
前記移動体端末と前記第２ネットワークエンティティにおいて前記蓄積されたコンテキスト情報が、前記パケットの前記ヘッダの圧縮と伸張のために使用されるように構成されることを含むパケットネットワーク。
【請求項１３】
前記コンテキスト情報アップデーティングは、前記移動体端末と前記第１のネットワークエンティティの伸張装置が、対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより中止されるように構成されることを特徴とする請求項１２記載のパケットネットワーク。
【請求項１４】
前記移動体端末がアップリンクデータを圧縮し転送するのを中止させ、前記第１ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させることにより、前記前記コンテキスト情報アップデーティングが中止されるように構成されることを特徴とする請求項１２記載のパケットネットワーク。
【請求項１５】
前記第１のネットワークエンティティにおける前記圧縮と伸張コンテキスト情報のスナップショットの前記取り込みが、前記転送されたアップリンクデータとダウンリンクデータが受信され、伸張されるまで、遅延されるように構成されることを特徴とする請求項１４記載のパケットネットワーク。
【請求項１６】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末からの圧縮／伸張受信確認信号を、放棄することにより、中止するように構成することを特徴とする、請求項１２記載のパケットネットワーク。
【請求項１７】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末へ圧縮／伸張受信確認信号を送信することを不能にすることにより、中止するように構成することを特徴とする、請求項１２記載のパケットネットワーク。
【請求項１８】
前記第１のネットワークエンティティにおける前記移動体端末が送信するコンテキストアップデート要求の検出に応じて、
コンテキストアップデート要求が、前記第１のネットワークエンティティから前記第２のネットワークエンティティへ送信されるように構成し、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットが、送信されるように構成されることを特徴とする請求項１６記載のパケットネットワーク。
【請求項１９】
前記第１のネットワークエンティティにおける前記コンテキスト情報の同期外れの検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへ、コンテキストアップデート要求が送信されるよう構成し、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットが送信されるように構成されることを特徴とする請求項１６記載のパケットネットワーク。
【請求項２０】
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更する前に、前記第１のネットワークエンティティが蓄積した前記コンテキスト情報スナップショットが、前記第２のネットワークエンティティに転送されるように構成することを特徴とする請求項１２記載のパケットネットワーク。
【請求項２１】
前記パケットネットワークは、ＵＭＴＳシステムであって、ローバスト・ヘッダ圧縮（ＲＯＨＣ）が実行されるシステムであることを特徴とする請求項１２記載のパケットネットワーク。
【発明の詳細な説明】
【０００１】
（本発明の背景）
本発明は、ヘッダ圧縮におけるコンテキスト情報の再配置（ｒｅｌｏｃａｔｉｎｇ）に関する。
ここ数年のＩＰ（インターフェースプロトコール）技術における目覚しい進歩は、種々のＩＰベースのアプリケーション使用の可能性を、従来のインターフェースデータ転送以外の分野にも拡大した。特に、ＩＰベースの電話アプリケーションが長足な進歩を遂げており、その結果、従来の電話ネットワーク（公衆電話回線、ＩＳＤＮ）及び移動ネットワーク（公衆陸上移動ネットワーク）における呼の伝送パスの拡大する部分は、原則的に、ＩＰ技術を使って実施することができる。
【０００２】
特に、移動ネットワークにおいて、ＩＰ技術は、多くの利点を提供する。従来の移動ネットワークの音声サービス（これらは、各種ＩＰ音声アプリケーション手段が提供するものであるが）に加えて、移動ネットワークは、更に異なる各種のデータサービス（例えば、インターネット・ブラウジング、ｅメールサービス、ゲーム等）を提供するだろう。該データサービスがパケット切替ＩＰベースサービスにより実施されることが、通常好ましい。このように、ＩＰレイヤは、移動システムプロトコール内に構築され、オーディオ／ビデオサービス及び各種データサービスに役立つ。
【０００３】
移動ネットワークでは、有限な無線リソースをできるだけ効率よく使用することが、大切である。これは、無線インターフェースにおけるＩＰプロトコールの利用を困難にする。というのは、ＩＰベースプロトコールにおいて、転送データの各種ヘッダフィールドの占める割合が大きく、従って、ペイロードの占める部分が小さくなるからである。又、無線インターフェースビット誤り率（ＢＥＴ）、及び、アップリンクとダウンリンク方向のラウンドトリップ時間（ＲＴＴ）が、悪条件の時、かなり大きくなって、多くの公知のヘッダフィールド圧縮方法で種々の問題を起こすからである。このため、各種のＩＰプロトコールに適した種々のヘッダ圧縮方法（特に無線インターフェースにおけるリアルタイムデータ転送に適する）に対するニーズが生まれた。即ち、ビット誤り率とラウンドトリップ時間がかなり大きくなる状態で使用できる効率的なヘッダ圧縮方法である。
【０００４】
このために、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）は、最近、ローバストヘッダ圧縮ＲＯＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）とよばれるヘッダフィールド圧縮方法の標準化の作業を行ってきた。ＲＯＨＣ開発の背後にある考え方は、複数ＩＰヘッダフィールド間には多くの冗長性がある、それはデータパケット内部のみならず、データパケット間にもあるということである。換言すれば、ヘッダフィールドの情報の大多数は、データパケット転送間に変化しない、それ故、それが転送されないとしても、受信側で再構成することが容易であるということである。ヘッダフィールドのある小部分についてだけ、その情報を圧縮するとき、注意を払わねばならない。更に、ＲＯＨＣは、複数の圧縮レベル（その圧縮効率は、レベルが高くなるにつれ、増加する）を持っている。ＲＯＨＣは、常に、最高に効率的な圧縮を使うが、そのレベルの動作の十分な信頼性が確かめられてから、次のレベルに移行するという手順で進められる。ＲＯＨＣは、又、通常のやり方のように、不可欠な複数事項を、下位のリンクレイヤが取り扱う圧縮法に委ねるものである。
【０００５】
全てのヘッダ圧縮技術と同様に、ＲＯＨＣは、コンテキスト情報の記憶を必要とする。該情報は、圧縮装置（送信装置）及び伸張装置（受信装置）におけるはケットヘッダの圧縮・伸張に使用するためのものであり、本質的に全ヘッダを送信することにより、圧縮／伸張プロセスを開始する。コンテキスト情報が意味するところは、圧縮装置が送信用ヘッダフィールドを圧縮し、伸張装置が、受信用ヘッダフィールドを伸張するのに使う状態（ｓｔａｔｅ）を意味する。ヘッダ圧縮／伸張が無線リンクと共に使用される場合には、ヘッダはアップリンク線路で送信され、移動局により圧縮され、ネットワークエンティティが伸張する。ダウンリンク線路の場合はネットワークエンティティはヘッダを有し、移動体端末は、ヘッダを圧縮する
【０００６】
通常の圧縮・伸張の動作においては、伸張コンテキスト情報は、圧縮コンテキスト情報と同期をとっている。それは、伸張コンテキスト情報が、圧縮コンテキスト情報で圧縮されたヘッダを伸張するのに使用され、元の非圧縮ヘッダが再構成されるという意味である。圧縮コンテキスト情報と伸張コンテント情報は、絶えず、圧縮装置と伸張装置によりアップデートされ、二つのコンテキストは、同期状態に置かれる。
【０００７】
移動体端末が、他のネットワークエンティティが管理する他の無線セルにハンドオーバーされる場合、もしコンテキスト情報を新たなネットワークエンティティに再配置（ｒｅｌｏｃａｔｅ）する有効な手順が定義されない時には、ヘッダ圧縮／伸張プロセスは、再開始手順を経て進めなければならない。該再開始手順はダウンリンク・トラフィックとアップリンク・トラフィックにおける全ヘッダの送信を伴うものである。全ヘッダ付きの、この再開始手順は、現在進行中の通信を混乱させ、エアー・インターフェース（ａｉｒ ｉｎｔｅｒｆａｃｅ）上のバンド幅を消費する。そこで、旧ネットワークエンティティから、新ネットワークエンティティへの圧縮・伸張コンテキストを転送するための、開発されたメカニズムは、旧ネットワークと移動体端末との間の、圧縮・伸張コンテキスト情報のスナップショットを取り、このスナップショットを、新ネットワークエンティティに送信し、圧縮・伸張コンテキスト情報として使用するというものである。スナップショットを取り、それを新エンティティに転送するために必要な時間の間、通常、圧縮・伸張は、中止される。
【０００８】
上記のコンテキスト情報再配置手続きの一つの問題点は、スナップショットを取り、それを新たなネットワークエンティティに転送するのに長時間必要で、その間、圧縮・伸張が中止しなければならないことである。この結果、リアルタイムのデータ転送において重大な中断が起こる。この中断は、可能な限り短縮せねばならない。もう一つの問題点は、移動システムにおいて、移動体端末は、新旧ネットワークエンティティ間のハンドオーバーが何時発生するか、通常、前もって、知らないことである。それ故、旧ネットワークエンティティが、既にハンドオーバーによりデータの伸張を中止したとしても、移動体端末は、アップリンクデータを圧縮し、それを旧ネットワークエンティティに送信し続けることになる。その場合、前記端末が送信した圧縮データパケットは、消失することになる。
【０００９】
（本発明の概要）
従って、本発明の目的は、上記問題を軽減するために、方法と該方法を実装する装置を開発することである。本発明の目的は、特許請求の範囲の独立項に記載されたものにより特徴付けられる方法とシステムにより達成される。本発明の好ましい実施例は、従属項に示される。
【００１０】
本発明のアイデアは、圧縮装置と伸張装置の両方のコンテキストアップデーティングが、移動体端末と旧ネットワークエンティティにおいて中止される点で、これにより、移動体端末と旧ネットワークエンティティの両方が同一コンテキストを使うことを確実になる。この後で、圧縮・伸張コンテキスト情報が  旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、そこで蓄積される。移動体端末の圧縮装置は、前記コンテキスト情報で、少なくとも一つのパケットの少なくとも一つのヘッダを圧縮し、該圧縮された少なくとも一つのパケットの少なくとも一つのヘッダを新ネットワークエンティティに転送する。コンテキスト情報は、再配置プロセスで変更していないので、移動体端末の圧縮装置と新ネットワークエンティティの伸張装置は、自動的に同期状態になり、データ転送が継続される。
【００１１】
本発明の好ましい実施例によると、コンテキスト情報のアップデーティングは、前記移動体端末と前記第１のネットワークエンティティの両方の伸張装置が、対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより防止される。伸張装置が受信確認信号を送信しないので、圧縮装置のコンテキストは、アップデートされず、移動体端末と旧ネットワークエンティティの両方の圧縮装置は、新パケットの圧縮に同一のコンテキスト情報を使用する。本発明の第２の好ましい実施例によると、移動体端末がアップリンクデータを圧縮し転送するのを中止させ、旧ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させる。この結果、コンテキスト情報はそれ以上アップデートされない。本発明の第３の好ましい実施例によると、
移動体端末は、通常通りに、ヘッダ圧縮・伸張を継続して動作させる。しかし、移動体端末コンテキスト情報のコンテキストアップデートは、旧ネットワークエンティティのＲＮＣ圧縮装置／伸張装置において、移動体端末の圧縮装置／伸張装置からの受信確認信号を放棄することにより、又は、移動体端末の圧縮装置／伸張装置へ如何なる受信確認信号をも中止することにより、防止される。旧えんっとエンティティが全ての受信確認信号を放棄するので、移動体端末の圧縮装置のコンテキストはアップデートされないが、移動体端末は、前のコンテキスト情報でアップリンクデータを圧縮し、転送する。
【００１２】
本発明の方法と装置は、ヘッダ圧縮コンテキストの効率的な再配置を可能にするという利点を提供する。更に、本発明の方法は、移動体端末とネットワークエンティティとの間のコンテキストの同期外れを防止すると同時に、時間ドメーンにおける圧縮／伸張プロセスのブレークを最小化するという利点を提供する。本発明の実施例の更なる利点は、コンテキスト再配置が効率的に十個できることであり、その結果データ圧縮／伸張においてブレークが発生せず、継ぎ目なく継続できることである。
【００１３】
以下、本発明について、好ましい実施例を用いて、図面を参照しながら説明する。
【００１４】
以下、本発明について、実施例に基づいて、ヘッダフィールド圧縮法ＲＯＨＣに関連して説明する。該ＲＯＨＣ法は、無線インターフェース上のリアルタイムデータ転送に特に適したものである。本発明は、単にＲＯＨＣに限定されているものではなく、どのような他のヘッダ圧縮方法にも適用できるものである。更に、本発明は、ＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮にも適用できるものである。しかしこれに限定されるものではない。以下に、本発明に不可欠な部分について、ＲＯＨＣの実施について説明する。問題となる圧縮法の更に詳細な説明については、ミカンのインターネット草案“Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ）” 第４改訂版、２０００年１０月１１日を参照されたい。
【００１５】
各種圧縮方法において、通常、コンテキストが圧縮・伸張に対して提示される。コンテキストは、圧縮装置が送信ヘッダフィールドを圧縮するのに使用し、伸張装置が受信したヘッダフィールドを伸張するのに使用する状態である。通常、コンテキストは、データ転送接続上で、送信された（圧縮装置）又は受信された（伸張装置）、先行するヘッダフィールドの非圧縮版を含んでいる。更に、コンテキストは、データパケットフロー（例えば、シーケンスナンバ又はデータパケットの時間スタンプ）を識別する情報を含むことができる。このように、コンテキストは、通常、静的情報（全データパケットフロー中変化しない）と動的情報（データパケットフロー中変化するが、規定パターンに従って変化する）の両方の情報を含む。
【００１６】
ＲＯＨＣは、３圧縮レベルを有し、圧縮は最低レベルから開始し、より高いレベルに徐々に継続する。その基本原則は、圧縮は常にできるだけ高位レベルで行われるが、圧縮装置は、伸張装置が十分な情報を持って、問題レベルの伸張を行うことができることを確認して圧縮を行う。各種圧縮レベル間の移動に影響を与える要因は、連続ヘッダフィールドの変化、伸張装置から受信するポジティブ・ネガティブの受信確認信号、特定シーケンシャルカウンタの終了（受信確認信号が無い場合は）である。同様に、高い圧縮レベルから低いレベルに移動することも可能ではある。
【００１７】
ＩＰ（インターネットプロトコール）、ＵＤＰ（ユーザデータグラムプロトコール）及びＲＴＰ（リアルタイムプロトコール）等のプロトコールに関連してＲＯＨＣが使う圧縮レベルは、イニシエーション／リフレッシュ（Ｉ／Ｒ）、第１オーダ（ＦＯ）及び第２オーダ（ＳＯ）であり、これらレベル間の移動は、図１のダイアグラムで説明されている。ＩＲレベルは、伸張装置のコンテキストを生成する又はエラー状態から回復するために使われる。伸張装置が要請したり、アップデータタイマが満了した時に、ヘッダフィールド圧縮が開始する。この時に、圧縮装置は、ＩＲレベルへ移動する。ＩＲレベルにおいて、圧縮装置は、ＩＲヘッダフィールドを、非圧縮フォーマットで送信する。伸張装置がアップデート情報を受信したことが確かな時には、圧縮装置は、より高位レベルに移動しようと試みる。
【００１８】
ＦＯレベルは、データパケット・フローのヘッダフィールドにおける不規則性を受信者に通知するのに使われる。ＩＲレベルの後、圧縮装置は、ヘッダフィールドが一様なパターン（換言すれば、連続ヘッダフィールドは、変化を予測できないようなランダムな変化をする）を形成しない状況におけるＦＯレベルで動作する。即ち圧縮装置は、伸張装置が一様なパターンのヘッダフィールドを定めるパラメータを受信したことを確信できない。例えば、この典型的な状態は、音声を転送する時、特に最初の音声バースト期間である。ＦＯレベルでは、圧縮装置は、圧縮したＦＯヘッダフィールドを送信する。圧縮装置が、再度、より高位レベルに移ろうと試みるのは、ヘッダフィールドが一様なパターンを形成し、伸張装置が一様なパターンを表すパラメータを受信したことが確かな時である。ＦＯレベルのデータパケットは、通常、コンテキスト・アップデート情報を含む。それは、伸張に成功するには、連続ＦＯヘッダフィールドの転送を成功させる必要があることを意味する。このように、伸張のプロセスを成功させる為には、ＦＯレベルのパケットの消失、破壊に敏感に対応する必要がある。
【００１９】
ＳＯレベルにおいては、圧縮は最適である。ヘッダフィールドは、一様なパターンを形成する。該パターンは、圧縮装置が圧縮されたＳＯヘッダフィールドで表現するものであり、前記ＳＯヘッダフィールドは、実際には、データパケットのシーケンス数である。一様なパターンのヘッダフィールドを規定するパラメータについての情報は、伸張装置に転送される。そして、パラメータと受信シーケンス番号に基づいて、伸張装置は、元のヘッダフィールドを外挿する。ＳＯレベルで送られるデータパケットは、実際には、相互に独立であるから、伸張のエラー感度は低い。ヘッダフィールドが、もはや一様なパターンを形成しない場合は、圧縮装置は、ＦＯレベルに戻る。
【００２０】
伸張にも、圧縮レベルは３レベルあって、伸張装置のコンテキスト規定に拘束される。コンテキストが規定されていなかった場合、伸張装置は最低レベルから動作を開始する。その時、伸張装置は、いかなるデータパケットをも伸張していない。伸張装置が、静的及び動的コンテキスト情報を有する第１データパケットを伸張した時、中間レベル（静的コンテキスト）を超えて、直接最上位レベル（フルコンテキスト）に移る。最上位レベルで複数エラー状態がある場合、伸張装置は中間レベルに移動する。しかし、典型的に、成功裏に伸張されたデータパケットは、伸張装置を最上位レベルに戻す。
【００２１】
複数圧縮レベルに加えて、ＲＯＨＣは３動作モードを有する。即ち、一方向モード（Ｕモード）、双方向最適モード（Ｏモード）そして、双方向信頼モード（Ｒモード）であり、これを図２に示す。図２によると、各圧縮装置レベル（ＩＲ、ＦＯ、ＳＯ）は、各モードにおける前記機能を説明するものであるが、各モードは、それぞれ独自に機能し、独自の仕方でレベル間の移動を定義する。各圧縮状態に対するモードの選択は、使用データ転送接続のパラメータ、例えば戻りチャネルを使用する可能性、エラー確率、分布、ヘッダフィールド規模の変動の影響に基づいて決まる。
【００２２】
一方向モードでは、データパケットの転送は、圧縮装置から伸張装置への転送のみである。従って、ＲＯＨＣのＵモードが有効であるのは、戻りチャネルの使用が出来ない場合、又は、望ましくない状況の場合である。Ｕモードでは、各圧縮レベル間の移動は、シーケンスカウンタの終了の結果、又は、ヘッダフィールド・パターンの変動、を基にして行われる。戻りチャネルが使用されないから、Ｕモードでの圧縮は余り有効ではない。又、伝送路におけるデータパケットの消失は、双方向モードにおけるより更に発生する可能性が高い。ＲＯＨＣの使用は、常にＵモードから始まり、双方向モードへ移ることができるのは、伸張装置が１以上のパケットを受信した時であって、この時パケットへの応答として、伸張装置は、モード変更が必要であることを指示する。
【００２３】
双方向最適（Ｏ）モードは、一方向モードと類似しているが、相違する点は、Ｏモードでは、戻りチャネルを使用して、エラー状態を訂正し、伸張装置から圧縮装置へ重要なコンテキスト・アップデートをアクノリッジする点である。Ｏモードでは、シーケンシャルなアップデートは行わない。Ｏモードが適しているのは、小さい戻りチャネル・トラフィックを持った、最適圧縮効率を必要とする接続である。Ｏモードは適度に信頼性のあるデータパケット転送を提供する。その場合、圧縮装置・伸張装置間の同期化が典型的に保持されており、データパケットはほとんど消失しない。もし消失したとしても無視できる数である。しかし、伝送路では、データパケットは、極端に高いビットエラー率で消失する。
【００２４】
双方向信頼（Ｒ）モードは、明らかに、前記モードとは異なる。Ｒモードは、戻りチャネルを使って、前コンテキスト・アップデートをアクノリッジする。このように、Ｒモードでは、圧縮装置・伸張装置間でデータパケットをほぼ全体的に確実に転送する事ができる。Ｒモードでは、ヘッダフィールド圧縮をしてもパケットの消失は起こらない。Ｒモードの欠点は、複数ケースにおいて、ヘッダフィールド・サイズが前記のモードに比して、少し大きめであり、戻りチャネルトラフィックがかなり増加する点である。
【００２５】
３つの動作モードとＲＯＨＣの３つの圧縮レベルは、ヘッダフィールド圧縮に対する各種動作状態を形成する。各状態は、圧縮装置と伸張装置の動作（即ち、コンテキスト情報）、及び、両装置間のパケットの伝送の定義を必要とする。
圧縮装置及び伸張装置は、複数パラメータについて、各データパケットフロー毎に、別々にネゴーシエイトする。
ＲＯＨＣの定義によれば、低位プロトコールレイヤ（リンクレイヤ）は、使用される毎に、パラメータ（ヘッダフィールド圧縮に使用される）のネゴーシエイションのメカニズムを提供しなければならない。圧縮を開始する前に、パラメータをネゴーシエイトする。
【００２６】
以下において、再配置手続きを説明するが、用語「旧ネットワークエンティティ」とは、再配置手続きが開始する寸前の、移動体端末が接続しているネットワークエンティティを指す。「旧ネットワークエンティティ」は、又、「第１ネットワークエンティティ」とも呼ぶことができる。「新ネットワークエンティティ」とは、再配置手続き中、移動体端末が接続しているネットワークエンティティを指す。「新ネットワークエンティティ」は、又、「第２ネットワークエンティティ」とも呼ぶことができる。
【００２７】
移動体端末が別のネットワークエンティティがサービスを行う別の無線セルにハンドオーバーされる場合、旧ネットワークエンティティから新ネットワークエンティティへのコンテキスト情報の再配置を、同様に行わねばならない。既知の解決法によれば、これは、圧縮・伸張コンテキスト情報（旧ネットワークと新ネットワーク間で使用される）のスナップショットを取り、このスナップショットを新ネットワークエンティティに渡し、圧縮・伸張コンテキスト情報として使用することにより、行われる。前記既知の解決法によれば、圧縮・伸張は、スナップショットを取り、それを新ネットワークエンティティに転送するために必要な時間の間、中止される。
【００２８】
ダウンリンクトラフィックについて、旧ネットワークエンティティは、圧縮コンテキスト情報を有しており、それは、移動伸張装置の伸張コンテキスト情報に同期している。旧ネットワークエンティティは、圧縮コンテキスト情報のスナップショットを新ネットワークエンティティへ、転送する。すると、新ネットワークエンティティは、記憶された圧縮コンテキスト情報を使って、少なくとも１つのパケットのヘッダを圧縮し、移動伸張装置に転送し、移動伸張装置は先に一時保存した伸張コンテキスト情報を使い、少なくとも一つのデータパケットのヘッダフィールド圧縮を伸張する。アップリンク・トラフィックについて、旧ネットワークエンティティは、伸張コンテキスト情報を有する。前記情報は移動圧縮装置の圧縮コンテキスト情報に同期している。旧ネットワークエンティティは、伸張コンテキスト情報のスナップショットを新ネットワークエンティティに転送すると、該新ネットワークエンティティは、前記スナップショットを記憶し、その伸張コンテキスト情報として使用する。前記移動圧縮装置は、少なくとも一つのパケットの、少なくとも一つのヘッダを、そのコンテキスト情報で圧縮し、前記、少なくとも一つのパケットの、少なくとも一つのヘッダを、新ネットワークエンティティに転送する。すると、該新ネットワークエンティティは、受信した少なくとも一つのヘッダの、少なくとも一つのパケットを、記憶している伸張コンテキスト情報を用いて、伸張する。
【００２９】
再配置（ｒｅｌｏｃａｔｉｏｎ）は、無線ハンドオーバーと、同時に、又は、後に、実行することができる。それ故、コンテキスト情報のスナップショットを取り、ネットワークエンティティ間にそれらを転送する動作の順序は、実施の仕方で変化する。しかし、どのような場合にも、既知の解決法においては、圧縮・伸張は、スナップショットを取り、それを新ネットワークエンティティに転送するために必要な間、中止される。圧縮・伸張プロセスは、ハンドオーバープロセスに関し非同期的であり、該プロセスから独立しているから、又前者はパケットフローにより駆動され、後者は無線条件により駆動されているから、リアルタイムデータ転送で、目に付くブレーク（ｂｒｅａｋ）を起こす可能性がある。更に、移動体端末は、旧ネットワークエンティティから新ネットワークエンティティへの、ネットワーク側のハンドオーバーが何時行われるか、通常、前もって知る事は無い。従って、既知の解決法では、旧ネットワークエンティティが、ハンドオーバーのために、前記データの伸張を既に中止していたとしても、移動体端末は、アップリンクデータを圧縮し、それを旧ネットワークエンティティに転送し続ける。それ故、新ネットワークエンティティが転送コンテキスト情報を使うまでには、移動体端末では、それは、コンテキストとの同期から外れている可能性がある。従って、同時に、時間ドメインにおける圧縮／伸張プロセスにおける前記ブレークを最小化しながら、前記コンテキストの同期外れを、防止されねばならない。
【００３０】
本発明によれば、これは、移動体端末と旧ネットワークエンティティの両方の圧縮装置と伸張装置のコンテキスト・アップデーティングを中止することにより、達成される。この中止により、移動体端末と旧ネットワークエンティティの両方が同一コンテキストを使用することが保証され、その中止の後、圧縮装置と伸張装置のコンテキスト情報のスナップショットが、旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、蓄積される。移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、前記圧縮された少なくとも一つのパケットの少なくとも一つのヘッダを、新ネットワークエンティティへ転送する。次に、新ネットワークエンティティは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを伸張する。再配置プロセスの間、コンテキスト情報は変化しないから、移動体端末の圧縮装置と新ネットワークエンティティの伸張装置との間の同期が自動的に取られ、データ転送が継続される。
【００３１】
本発明の第１の好ましい実施例によると、これは、無線ネットワークから移動体端末へシグナリングすることにより達成される。そうすると、ハンドオーバー（また、コンテキスト再配置も同様に）が、直ぐに発生するが、これは、コンテキスト情報が、もうそれ以上アップデートされるべきでないことを意味する。このコンテキストのアップデーティングは、移動体端末と旧ネットワークエンティティの伸張装置が対抗する側の圧縮装置に対する受信確認信号の送信を不能にすることにより、防止することができる。伸張装置が受信確認信号を送信しないので、圧縮装置のコンテキストはアップデートされないし、移動体端末と旧ネットワークエンティティの圧縮装置は、新パケットの圧縮のために同一コンテキスト情報を使用することになる。この後で、圧縮と伸張のコンテキスト情報のスナップショットが、旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、蓄積される。
移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、前記圧縮された少なくとも一つのパケットの少なくとも一つのヘッダを、新ネットワークエンティティへ転送する。次に、新ネットワークエンティティは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを伸張する。
【００３２】
本発明の第２の好ましい実施例によると、移動体端末と旧ネットワークエンティティのコンテキスト情報のアップデーティングは、無線ネットワークから移動体端末へのシグナリングにより防止できる。そうすると、ハンドオーバー（また、コンテキスト再配置も同様に）が、直ぐに発生するが、それに応答して、移動体端末は、アップリンクデータの圧縮と転送を中止し、旧ネットワークエンティティは、ダウンリンクデータの圧縮と転送を中止する。これは、結果として、もうアップデートされないコンテキスト情報を生成する。現行コンテキスト情報は、移動体端末に記憶される。該移動体端末は、メモリからの前記コンテキスト情報をリフレッシュし、必要があれば、新パケットの圧縮のためにそれを使用する用意ができている。圧縮、伸張のコンテキスト情報のスナップショットは、旧ネットワークエンティティに取り込まれ、好ましくは、一定の遅延の後、新ネットワークエンティティに転送し、蓄積される。前記遅延の適当な時間待つことにより、圧縮・転送された全パケットが、確実に、受信され、それぞれの伸張装置により、確実に伸張される。すると、移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、一つのパケットの少なくとも一つのヘッダを新ネットワークエンティティに転送する。次に新ネットワークエンティティは、一つのヘッダの少なくとも一つのパケットを、蓄積された伸張コンテキスト情報で伸張する。
【００３３】
上記二つの実施例が、うまく機能するための条件は、ハンドオーバーの時刻が前もって知られている時、移動体端末が、来るべきハンドオーバーに事前に通知されることである。しかし、常にハンドオーバーが行われる時間を事前に知るというのは可能ではない。例えば、移動体端末が旧セルの無線カバレッジから消滅し、新セルに当然現われる場合のように。従って、再配置について、事前に移動体端末に通知することも可能ではない。本発明の第３の実施例によると、移動体端末はヘッダ圧縮・伸張を正常に継続して行うが、移動体端末コンテキスト情報のアップデートは、旧ネットワークエンティティの圧縮装置／伸張装置において、移動体端末の圧縮・伸張装置の受信確認信号を放棄することにより、妨げられる。前記実施例の他の解決方法として、旧ネットワークエンティティにおける移動体端末に対する受信確認信号の放棄に代え、再配置手続き中における、旧ネットワークエンティティの圧縮装置が、受信確認信号を送信しないように構成することにより置き換えることができる。全受信確認信号は、旧ネットワークエンティティが放棄するか、送信しないかのいずれかであるから、移動体端末の圧縮装置のコンテキストは、アップデートされないが、移動体端末は、前のコンテキスト情報でアップリンクデータを、継続して圧縮し、転送する。この後、圧縮・伸張コンテキスト情報は、旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、蓄積される。
【００３４】
移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、少なくとも一つのヘッダの少なくとも一つのパケットを新ネットワークエンティティに転送する。次に、新ネットワークエンティティは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを、蓄積された伸張コンテキスト情報で伸張する。この実施例は、ヘッダ圧縮コンテキスト再配置が、移動体端末にハンドオーバーを事前に通知することは不可能であるという条件で、実行されるのを可能にする。ＲＯＨＣヘッダ圧縮メカニズムが使用されるならば、受信確認信号の放棄プロセスは、ＲＯＨＣ実装の下位のプロトコールレイヤで行われることが好ましい。なぜならば、ＲＯＨＣ規定は、必要とされる構成を可能にするための、実装インターフェースを含まないからである。旧ネットワークエンティティの圧縮装置が再配置手続きの間如何なる受信確認信号をも送信しないように、代わって、構成されている場合は、圧縮装置とそれより低位のレイヤ間の事前に規定されたインターフェースを追加して容易に実行することができる。
【００３５】
移動ネットワークのシグナリング・メカニズムは、通常とおりに規定されており、コンテキスト再配置を極めて効率的にサポートするものではない。その理由は、パケット無線ネットワークの構造は、主として、非実時間データ転送のために設計されているからである。従って、既知の解決法に従って、旧ネットワークエンティティから新ネットワークエンティティへの、コンテキスト情報のスナップショットの転送が、同一メッセージにおいて、行われる。該メッセージは、新ネットワークエンティティへの接続の実制御をシフトするためのコマンドを含む。該メッセージは、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅと呼ばれ、通常、再配置プロセスにおける、旧ネットワークエンティティから新ネットワークエンティティへ転送される最後のメッセージである。新ネットワークエンティティは、旧ネットワークエンティティからコンテキスト情報スナップショットを、接続制御を引き継ぐコマンドと同時に受信するので、その結果、データ圧縮／伸張における中断を起こす。というのは、新ネットワークエンティティが前記受信コンテキスト情報を蓄積し、前記受信したコンテキスト情報に従って圧縮装置・伸張装置を構成するための、非ゼロの準備時間が必要であるからである。また、旧ネットワークエンティティから新ネットワークエンティティへのコンテキスト情報を転送するのに、時間が必要である。
【００３６】
前記中断を最小化し、本発明の好ましい実施例に従って、上記実施例を更に向上させ、前記コンテキスト情報スナップショットを含んだメッセージが、前記コマンドが接続制御を引き継ぐ前で、再配置プロセスが開始された後、旧ネットワークエンティティから新ネットワークエンティティに転送される。これは、新ネットワークエンティティが、前記受信コンテキスト情報を蓄積し、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅが実制御をハンドオーバーする前に、圧縮装置と伸張装置を設定することを可能にする。このように、コンテキスト再配置は、効率的に実行され、データ圧縮／伸張において、中断が発生しないようにできる。このように、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅが制御を与える時には、中断がないように継続できる。
【００３７】
上記の本発明の第３の実施例（旧ネットワークエンティティが全受信確認信号を放棄する）において、再配置プロセスの間に、移動体端末が、そのコンテキスト情報をアップデートしければならない状況が、例えば、無線インターフェース上の擾乱に起因して、発生するかもしれない。その場合、、コンテキスト・アップデート要求を旧ネットワークエンティティに送信するが、前記アップデートは、可能ではないかも知れない。というのは、受信確認信号は、ネットワーク側の如何なるイベントの発生をも、許されないからである。この結果、移動体端末のコンテキスト情報は、スナップショットコンテキスト情報（新ネットワークエンティティにアップデートされる）に関して同期外れとなる。又、移動体端末のコンテキスト情報と新ネットワークエンティティとが同期する時、データ圧縮／伸張において、中断が発生する。
【００３８】
本発明の好ましい実施例により、前記同期化をスピードアップすることができる。その場合、移動体端末が送信するコンテキストアップデート要求を、旧ネットワークエンティティが検知し、いずれかのメッセージ（例えば、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ）にその表示を付加し、コンテキスト情報のスナップショットが取り込まれた後、新ネットワークエンティティに送信する。このように、新ネットワークエンティティが、必要なコンテキストアップデートについての情報を受信し、再配置が達成された後、新ネットワークエンティティは、移動体端末に、コンテキスト・アップデート・メッセージとして第１パケットを送信することができる。移動体端末は、前記コンテキスト・アップデート・メッセージを含む前記パッケージのコンテキストに従って、そのコンテキスト情報をアップデートする。次に、移動体端末の伸張装置が、蓄積した伸張コンテキスト情報で、前記受信した少なくとも一つのヘッダの少なくとも一つのパケットを伸張し、受信したアップデートメッセージに従ってコンテキスト情報をアップデートする。圧縮同期が、再配置プロセス間に失われた場合には、これにより、コンテキスト再同期化がスピードアップされる。
【００３９】
同様に、旧ネットワークエンティティは、そのコンテキスト情報をアップデートする再配置プロセスの間に、終了した方がよい。しかし、移動体端末に一切受信確認信号を創始できないから、そのアップデートは、可能ではない。このような状況で、コンテキストアップデート表示が如何なるメッセージ（Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ）にも付加され、コンテキスト情報のスナップショットが取り込まれた後、新ネットワークエンティティに送信される場合には、本発明の上記実施例を利用することができる。又、新ネットワークエンティティは必要なコンテキストアップデートについての情報を受信し、再配置プロセスが完了した時、移動体端末にそれを知らせる。他の方法として、メッセージ（Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ）に付加し、旧ネットワークエンティティが新ネットワークエンティティに送信した前記コンテキストアップデート表示は、新ネットワークエンティティの伸張装置におけるトリガーとして使い、コンテキスト・フレッシュ・アップデートを直ちに開始することができる。
【００４０】
上記の方法とその実施例は、例えば、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）及びＩＭＴ−２０００（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｐｈｏｎｅ Ｓｙｓｔｅｍ）、並びに第２世代移動システムの更なる開発プロジェクトであるＧＥＲＡＮ（ＧＳＭ Ｅｄｇｅ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）と呼ばれる第３世代システムに応用できることが好ましい。
【００４１】
以下において、本発明を、ＵＭＴＳシステムのパケット無線サービスに関連した、具体的には、ＵＭＴＳ（ＳＲＮＳ Ｒｅｌｏｃａｔｉｏｎ）の無線ネットワークサブシステム間のハンドオーバーに関連した一例を以って説明する。その間ヘッダ圧縮コンテキスト情報は、旧無線ネットワークエンティティコントローラＲＮＣから新無線ネットワークコントローラへ再配置される必要がある。しかし、本発明はＵＭＴＳシステムに限定されるものではなく、ヘッダ圧縮コンテキスト情報再配置を実行しなければならない、どのようなパケット切替データ転送方法に適用できるものである。
【００４２】
ＵＭＴＳ移動通信システム構成を図３を参照しながら説明する。図３は、本発明の説明に関連したブロックだけを含む。当業者には明らかなことであるが、従来の移動通信システムは、又、この意味では、更に詳しく説明する必要のない、他の機能と構成を有する。移動通信システムの主要構成要素は、コアネットワークＣＮとＵＭＴＳ地上無線アクセスネットワークＵＴＲＡＮ（これは、移動通信システム、移動体端末又はユーザ装置ＵＥの固定ネットワークを形成する。）である。ＣＮとＵＴＲＡＮとの間のインターフェースは、ｌｕとよばれ、ＵＴＲＡＮとＵＥの間のインターフェースは、Ｕｕとして知られている。
【００４３】
ＵＴＲＡＮは、通常、複数の無線ネットワークサブシステムＲＮＳから構成される。前記サブシステム間には、ｌｕｒと呼ばれるインターフェースがある。ＲＮＳは、無線ネットワークコントローラＲＮＣと１つ又はそれ以上の基地局ＢＳ（これは、ノードＢｓと呼ばれる）から構成される。ＲＮＣとＢＳとの間のインターフェースは、ｌｕｂと呼ばれる。基地局ＢＳは、通常、無線パス（ｒａｄｉｏ ｐａｔｈ）の実行を担当している。又、無線ネットワークコントローラＲＮＣは少なくとも以下のことを担当している。即ち、無線リソース管理、セル間のハンドオーバーの制御、電源制御、タイミングと同期、加入者端末のページング。
【００４４】
コアネットワークＣＮは、ＵＴＲＡＮの外部の移動通信システムに属するインフラから構成される。コアネットワークにおいて、移動切替センタ／ビジタ位置レジスタ３Ｇ−ＭＳＣ／ＶＬＲは、ホームロケーションレジスタＨＬＲと、インテリジェントネットワークのサービス制御ポイントＳＣＰと通信することが好ましい。ホームロケーションレジスタＨＬＲとビジタロケーションレジスタＶＬＲは、移動通信加入者に関する情報を有する。ホームロケーション・レジスタＨＬＲは、移動通信ネットワークの全加入者及び加入者が注文するサービスに関する情報を有する。ビジタロケーションレジスタＶＬＲは、所定移動切替センタＭＳＣのエリアを訪問する移動局に関する情報を有する。無縁システムのサービングＧＰＲＳサポートノード３Ｇ−ＳＧＳＮへの接続は、Ｇｓ’のインターフェースを介して、確立される。ゲートウエー移動切替センタＧＭＳＣ（Ｇａｔｅｗａｙ ＭＳＣ図示しない）を介して公衆回線網ＰＳＴＮ／ＩＳＤＮに確立される。
Ｇｎインターフェースを介したサービングサポートノード３Ｇ−ＳＧＳＮからゲートウェーＧＰＲＳサポートノードＧＧＳＮ、又ＧＧＳＮから外部データネットワークＰＤＮへの接続が確立される。移動切替センタ３Ｇ−ＭＳＣ／ＶＬＲとサービングサポートノード３Ｇ−ＳＧＳＮは、双方共に、ｌｕインターフェースを介して、無線ネットワークＵＴＲＡＮ（ＵＭＴＳ Ｔｅｒｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）と通信する。
【００４５】
このように、ＵＭＴＳシステムは、パケット無線システムを有し、該システムは、ＧＳＭネットワークに接続したＧＲＰＳシステムに従って最大限実施される。そのために、ネットワーク構成要素の名称には、ＧＰＲＳシステムへの参照を含まれる。ＵＭＴＳのパケット無線システムは、複数のサービングサポートノードとゲートウェー・サポートノードを有し、通常、複数サービングサポートノード３Ｇ−ＳＧＳＮは、一つのゲートウェー３Ｇ−ＧＧＳＮへ接続される。３Ｇ−ＳＧＳＮノードと３Ｇ−ＧＧＳＮノードは、ルータとして機能し、移動体端末のモビリティをサポートし、移動体通信システムを制御し、その位置及び使用されるプロトコールに無関係に、移動体端末へデータパケットをルーティングする。サービングサポートノード３Ｇ−ＳＧＳＮは、無線ネットワークＵＴＲＡＮを介して、移動体端末ＵＥと通信する。サービングサポートノード３Ｇ−ＳＧＳＮの機能は、そのエリアにおいて、パケット無線接続ができる移動体端末を検出し、データパケットをこれら移動端末に送信し、該移動端末から受信し、そのサービスエリアにおける移動体端末の位置をモニタすることである。更に、サービングサポートノード３Ｇ−ＳＧＳＮは、移動体切替センタ３Ｇ−ＭＳＣ及びビジタ位置レジスタと、シグナリングインターフェースＧｓ’と通信し、また、ホームロケーションレジスタＨＬＲと、Ｇｒインターフェースを介して通信する。ホームロケーションレジスタＨＬＲは、又、パケット無線サービスに関する記録を有し、加入者向けパケットデータ・プロトコールのコンテントを有する。
【００４６】
ゲートウェー３Ｇ−ＧＧＳＮは、ＵＭＴＳネットワークのパケット無線システムと外部データネットワークＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）との間のゲートウェーとして機能する。外部データネットワークは、ＵＭＴＳ又は他のネットワークオペレータのＧＰＲＳネットワーク、インターネット、Ｘ．２５ネットワーク又はプライベートＬＡＮを含む。ゲートウェー・サポート・ノード３Ｇ−ＧＧＳＮは、Ｇｉインターネットを介して、これらデータネットワークと数進する。ゲートウェーサポートノード３Ｇ−ＧＧＳＮとサービングサポートノード３Ｇ−ＳＧＳＮとの間で転送されるデータパケットは、常に、ゲートウェー・トンネリング・プロトコールＧＴＰに従って、カプセル化される。ゲートウェーサポートノード３Ｇ−ＧＧＳＮは、移動体端末のＰＤＰアドレス（ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）、ルーティングデータ、即ち３Ｇ−ＧＧＳＮアドレスを有する。こうして、ルーティングデータは、外部データネットワークとサービングサポートノード３Ｇ−ＳＧＳＮとの間でデータパケットをリンクするのに使用される。ゲートウェー・サポート・ノード３Ｇ−ＧＧＳＮとサービングサポートノード３Ｇ−ＳＧＳＮと間のネットワークは、ＩＰプロトコール、好ましくはＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ， ｖｅｒｓｉｏｎ６）を使用するネットワークである。
【００４７】
ＵＭＴＳにおいては、図４に基づくプロトコールスタックが、パケット切替ユーザデータ（ユーザプレーン）の転送において、使用される。無線ネットワークＵＴＲＡＮと移動体端末ＵＥとの間のインターフェースＵｕにおいて、低位データ伝送は、物理層におけるＷＣＤＭＡ又はＴＤ−ＴＤＭＡプロトコールに従って実行される。データパケットは、物理層とＲＬＣ層（無線リンク層）との間を、ＭＡＣ層（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｌａｙｅｒ）により伝送される。ＭＡＣ層は、物理層より上位にあり、ＲＬＣ層は種々の無線ベアラの無線リンクの論理制御を担当しているものである。ＲＬＣの機能（ｆｕｎｃｔｉｏｎａｌｉｔｉｅｓ）は、１又はそれ以上のＲＬＣデータパケットＲＬＣ−ＰＤＵへ伝送されるユーザデータ（ＲＬＣ−ＳＤＵ、サービスデータ・ユニット）のセグメンテーションを有する。ＲＬＣのトップにあるＰＤＣＰ層のデータパケット（ＰＤＣＰ−ＰＤＵ）及びそれらに関連するヘッダフィールドは、必要があれば、無線ネットワークＵＴＲＡＮ及び移動体端末ＵＥがサポートするヘッダ圧縮方法により圧縮される。この後で、ＰＤＣＰ−ＰＤＵｓ（これはＲＬＣ−ＳＤＵに対応する）は、ＲＬＣに供給される。ユーザデータとＲＬＣ−ＳＤＵは、セグメント化され、データ転送に必要なアドレスと制御情報を付加したＲＬＣフレームで、転送される。ＲＬＣ層は、又、破壊されたフレームの再転送を担当する。サービング・サポートノード３Ｇ−ＤＧＳＮは、移動体端末ＵＥから到着したデータパケットを、無線ネットワークＲＡＮを通って正しいゲートウェーサポート・ノード３Ｇ−ＧＧＳＮへのルーティングを担当する。この接続に尾は、トンネリングプロトコールＧＴＰが使用される。該プロトコールは、コアネットワークを介して転送される全ユーザデータとシグナリングをカプセル化し、トンネルするものである。ＧＴＰプロトコールは、コアネットワークが使用するＩＰ以上で動作する。
【００４８】
パケット切替ユーザデータ用無線ベアラ確立され（ＲＥ ｅｓｔａｂｌｉｓｈｍｅｎｔ）、移動体端末と無線ネットワークとの間で再構成される場合、両ピア（ｐｅｅｒｓ）は、無線リソース制御プロトコールＲＲＣに基づくシグナリングを使って、無線ベアラのパラメータを交渉する。無線リソース制御プロトコールＲＲＣは、例えば、移動体端末と無線ネットワークＵＴＲＡＮとの間の接続を確立し、構成し、維持し、終了することを担当し、又、コアネットワークＣＮおよび無線ネットワークＲＡＮから転送された制御情報を、移動体端末ＵＥに転送することを担当する。無線ベアラを規定するパラメータの一つは、端末が使用するヘッダ圧縮方法である。転送データパケットのヘッダの圧縮と、受信データパケットヘッダの伸張装置は、ＵＭＴＳシステムにおいては、パケットデータプロトコールに属するパケットデータ・コンバージェンス・プロトコールＰＤＣＰ層にて実行される。前記ＰＤＣＰ層のタスクは、チャネル効率の改善に関連する機能を含む。前記チャネル効率の改善は、通常、データパケットヘッダ圧縮アルゴリズムの利用等、種々の最適化方法に基く。現在ＵＭＴＳのためのネットワークレベルプロトコールは、ＩＰプロトコールであるから、使われる圧縮アルゴリズムは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が標準化するアルゴリズムである。従って、ＲＯＨＣ圧縮法は、ＵＭＴＳシステムに特に適合しているものである。
【００４９】
ＵＭＴＳシステムにおける本発明の実装について、図５乃至７を参照して、サービング無線ネットワークサブシステム（ＳＲＮＳ）再配置に関し、説明する。
【００５０】
ＵＭＴＳシステムにおいて、移動体端末ＵＥが、無線ネットワークコントローラＲＮＣが管理する他の無線セルにハンドオーバーされる場合、新無線ネットワークコントローラＲＮＣへのコンテキスト情報の再配置を、同様に実行しなければならない。これは、既知の解決法に従って、実行される。即ち、旧無線ネットワークコントローラ（ソースＲＮＣ）と移動体端末との間で使用される圧縮・伸張コンテキスト情報のスナップショットを取り、このスナップショットを、圧縮・伸張コンテキスト情報として、新無線ネットワークコントローラ（ターゲットＲＮＣ）へ渡す。該スナップショットの転送は、ＵＭＴＳシステムに基づくＳＲＮＳ再配置シグナリングの、シグナリングメッセージに含まれるものとして実行される。スナップショットを取り込み、それをターゲットＲＮＣへ転送するのに必要な間、圧縮・伸張は中止される。
【００５１】
本発明によると、ＳＲＮＳ再配置、及び、移動体端末とソース無線ネットワークコントローラ（ソースＲＮＣ）とにおける圧縮／伸張のコンテキストアップデーティング、を実行する決定に対応して、ＵＭＴＳシステムにおけるコンテキストの同期外れは防止され、中止による時間度メーンの圧縮／伸張のブレークは同時に最小化される。前記アップデーティングは、移動体端末とソースＲＮＣが同一コンテキストを使用するのを保証し、その後、圧縮・伸張コンテキスト情報のスナップショットがソースＲＮＣに取り込まれ、ターゲット無線ネットワークコントローラ（ｔａｒｇｅｔ ＲＮＣ）に転送され、蓄積される。移動体圧縮装置は、前記コンテキスト情報を使って、少なくとも一つのパケットの少なくとも一つのヘッダを圧縮し、圧縮された少なくとも一つのパケットの少なくとも一つのヘッダをターゲットＲＮＣへ転送する。次に、ターゲットＲＮＣは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを、蓄積された伸張コンテキスト情報で伸張する。コンテキスト情報は、再配置プロセスの間、変化しないから、移動体端末の圧縮装置と、ターゲットＲＮＣの伸張装置は、自動的に、同期化され、データ転送は、継続される。
【００５２】
ＵＭＴＳシステムにおける本発明の、第１の好ましい実施例の実装について、図５を参照しながら、以下説明する。移動体端末ＵＥの移動又は無線状態の変化に基づいて、例えば、無線リソースコントローラＲＲＣにおいて、ＳＲＮＳ再配置（５００、５０２）を実行する決定がされる。本発明によると、無線リソースコントローラＲＲＣは、移動体端末ＵＥに、ハンドオーバー（コンテキスト再配置も同様に）が、まじかに発生すること（５０４）を知らせると、これに対応して、移動体端末ＵＥは、コンテキスト情報のアップデーティングを中止する。移動体端末ＵＥに対するシグナリングは、ＲＲＣシグナリングとして、又は、ＰＤＣＰ層上のインバンドシグナリングとして実行されることが、好ましい。コンテキスト情報のアップデーティングの中止は、移動体端末とソースＲＮＣ伸張装置が、対抗する側（ｏｐｐｏｓｉｔｅ ｓｉｄｅ）の圧縮装置への受信確認信号の送信を不能にすることにより行われる。伸張装置が受信確認信号を送信しないので、圧縮装置のコンテキストは、アップデートされず、移動体端末とソースＲＮＣ圧縮装置は、新パケットの圧縮に同一のコンテキスト情報を使用する。この後、ソースＲＮＣは、Ｒｅｌｏｃａｔｉｏｎ＿ｒｅｑｕｉｒｅｄ ｍｅｓｓａｇｅを旧ＳＧＳＮ（５０６）へ送信して、既知のＳＲＮＳ再配置プロセスを開始する。それは、更に新ＳＧＳＮ（５０８）を介してターゲットＲＮＣ（５１０）へ送られる。無線ベアラは、ＲＲＣ（５１２）が与えるインストラクションに従って、新ＳＧＳＮとターゲットＲＮＣとの間に確立される。ターゲットＲＮＣは、再配置リクエストに対し受信確認信号を送信する。その受信確認信号は、新ＳＧＳＮ（５１４）を介して、旧ＳＧＳＮ（５１６）にルーティングされ、更に、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍａｎｄ ｍｅｓｓａｇｅ（５１８）ソースＲＮＣにリーティングされる。
【００５３】
ＳＲＮＳ再配置プロセスの間、圧縮・伸張コンテキスト情報のスナップショットは、ソースＲＮＣ（５２０）に取り込まれ、遅くとも（ａｔ ｌａｔｅｓｔ）Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ（５２２）において、ソースＲＮＣからターゲットＲＮＣへ転送され、ターゲットＲＮＣにおいて、蓄積される。ソースＲＮＣは、移動体端末ＵＥへ送信する可能なダウンリンクデータを、ターゲットＲＮＣ（５２４）へ送る。これにより、新ＳＧＳＮ（５２６）へのＲｅｌｏｃａｔｉｏｎ＿ｄｅｔｅｃｔ ｍｅｓｓａｇｅを送信することにより、再配置が確認される。ターゲットＲＮＣは、ＲＮＴＩ＿ｒｅａｌｌｏｃａｔｉｏｎ ｍｅｓｓａｇｅ（５２８）を移動体端末ＵＥに送信する。前記端末は、新ＲＮＣの識別番号を移動体端末に表示する。要求があれば、ターゲットＲＮＣ圧縮装置は、コンテキストアップデートの表示を転送する。これが行われるのは、スナップショットがターゲットＲＮＣ（５２２）に転送された後で、ソースＲＮＣが、既に接続を開放されている場合である。そうでない場合は、コンテキストアップデートは、ターゲットＲＮＣと移動体端末ＵＥとの間の後のシグナリングの接続において、実行されねばならない。移動体端末ＵＥは、ＲＮＴＩ＿ｒｅａｌｌｏｃａｔｉｏｎ＿ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ（５３０）として、コンファメーションを送信し、ＲＮＣの変化を確認する。こうして、ターゲットＲＮＣへのコンテキスト情報の再配置は、成功裏に実行され、同時にコンテキストの同期外れを防止でき、圧縮／伸張プロセスのブレークを最小化できる。一方、新ＳＧＳＮは、ＧＧＳＮ（５３２，５３４）に対するＰＤＰコンテキストをアップデートする。ターゲットＲＮＣは、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅを新ＳＧＳＮ（５３６）に送り再配置を確認する。前記新ＳＧＳＮは、更に旧ＳＧＳＮ（５３８）に送られ、新ＳＧＳＮ（５４０）に受信確認に送り返される。その後、ソースＲＮＣと旧ＳＧＳＮとの間の接続は切断される（５２４、５４４）。
【００５４】
ＵＭＴＳシステムにおける本発明の、第２の好ましい実施例の実装について、図６を参照しながら、以下説明する。再び、移動体端末ＵＥの移動又は無線状態の変化に基づいて、例えば、無線リソースコントローラＲＲＣにおいて、ＳＲＮＳ再配置（６００、６０２）を実行する決定がされる。本発明の、この実施例によると、無線リソースコントローラＲＲＣは、移動体端末ＵＥに、ハンドオーバー（コンテキスト再配置も同様に）がまもなく発生すること（６０４）を知らせると、これに対応して、移動体端末ＵＥが、アップリンクデータの圧縮・転送を中止し、ソースＲＮＣは、ダウンリンクデータの圧縮・転送を中止する。
移動体端末ＵＥとソースＲＮＣに対するシグナリングは、ＲＲＣシグナリングとして、又は、ＰＤＣＰ層上のインバンドシグナリングとして実行されることが、好ましい。この結果、コンテキスト情報はそれ以上アップデートされない。現行コンテキスト情報は、移動体端末ＵＥに蓄積される。前記端末は、メモリからの前記コンテキスト情報を、直ぐにリフレッシュでき、必要があれば、新パケットの圧縮のためにそれを使用できる．この後、ソースＲＮＣは、既知のＳＲＮＳ再配置プロセスを開始する。これは、それぞれの参照番号で先に説明したものと同様である。従って、ここで再び説明する必要はない。圧縮・伸張コンテキスト情報のスナップショットは、好ましくは前記ＳＲＮＳ再配置プロセスの間に、ソースＲＮＣに取り込まれ、一定の遅延の後、遅くとも（ａｔ ｌａｔｅｓｔ）Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ（６２２）で、ターゲットＲＮＣへ転送され、ターゲットＲＮＣで蓄積される。前記遅延の適当な時間待つことにより、移動体端末が圧縮し、送信した全パケットが、確実に、受信され、ソースＲＮＣの伸張装置により、確実に伸張される。ソースＲＮＣは、移動体端末ＵＥに送信する可能なダウンリンクデータを、ターゲットＲＮＣ（６２４）に送る。これにより、新ＳＧＳＮ（６２６）へのＲｅｌｏｃａｔｉｏｎ＿ｄｅｔｅｃｔ ｍｅｓｓａｇｅを送信することにより、再配置が確認される。ターゲットＲＮＣは、又、ＲＮＴＩ＿ｒｅａｌｌｏｃａｔｉｏｎ ｍｅｓｓａｇｅ（６２８）を移動体端末ＵＥへ送信する。
前記端末は、新ＲＮＣの識別番号を移動体端末に表示する。要求があれば、ターゲットＲＮＣ圧縮装置は、コンテキストアップデートの表示を転送する。これが行われるのは、スナップショットがターゲットＲＮＣ（６２２）に転送された後で、ソースＲＮＣが、既に接続を開放されている場合である。そうでない場合は、コンテキストアップデートは、ターゲットＲＮＣと移動体端末ＵＥとの間の後のシグナリングの接続において、実行されねばない。移動体端末ＵＥは、ＲＮＴＩ＿ｒｅａｌｌｏｃａｔｉｏｎ＿ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ（６３０）として、コンファメーションを送信し、ＲＮＣの変化を確認する。こうして、ターゲットＲＮＣへのコンテキスト情報の再配置は、成功裏に実行され、同時に、コンテキストの同期外れを防止でき、圧縮／伸張プロセスのブレークを最小化できる。
【００５５】
ＵＭＴＳシステムにおける本発明の、第３の好ましい実施例の実装について、図７を参照しながら、以下説明する。この場合、移動体端末は、再配置について事前に通知されていない。再び、無線リソースコントローラＲＲＣにおいて、ＳＲＮＳ再配置（７００、７０２）を実行する決定がされる。しかし移動体端末ＵＥには、これについて通知しない。移動体端末ＵＥは、通常通りに、ヘッダ圧縮・伸張を継続して動作させる、しかし、移動体端末コンテキスト情報のコンテキストアップデートは、ソースＲＮＣ圧縮装置／伸張装置において、移動体端末の圧縮装置／伸張装置からの全ての受信確認信号を放棄することにより、又は、ソースＲＮＣの圧縮装置が再配置プロセスの期間、受信確認信号を送信しないように構成することにより、防止される。前記受信確認信号を放棄するプロセスは、ＲＯＨＣ圧縮アルゴリズムが動作するＰＤＣＰ層において、論理的に（ｌｏｇｉｃａｌｌｙ）行われることが好ましい。ＲＯＨＣの規定は、要求される構成を可能にする、如何なる実装インターフェースを含まないからである。
【００５６】
ソースＲＮＣは、放棄したことについて、ＲＲＣ（７０４）を介して通知されることが好ましい。ソースＲＮＣが全受信確認信号を放棄するのであるから、移動体端末圧縮装置の個的はアップデートされないが、移動体端末は、以前のコンテキスト情報で、継続して圧縮し、アップリンクデータを転送する。この後、ソースＲＮＣは、既知のＳＲＮＳ再配置プロセスを開始する。これは、それぞれの参照番号で先に説明したものと同様である。従って、ここで再び説明する必要はない。圧縮・伸張コンテキスト情報のスナップショットは、好ましくは前記ＳＲＮＳ再配置プロセスの間にソースＲＮＣに取り込まれ、一定の遅延の後、遅くとも（ａｔ ｌａｔｅｓｔ）Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ（７２２）で、ターゲットＲＮＣへ転送され、蓄積される。ＳＲＳＮを完成するプロセスとコンテキスト情報の再配置は、前記したものと同様である。再配置プロセスが終了した後、ＲＮＣ（以前ソースＲＮＣとして機能した）は、正常に機能しつづける。即ち、それは、移動体端末ＵＥの圧縮装置／伸張装置からの如何なる受信確認信号を放棄しない。事前に移動体端末ＵＥに通知することは不可能であるという状況で、この実施例によれば、ヘッダ圧縮コンテキスト再配置を実行することが可能になる。
【００５７】
ＵＭＴＳシステムにおける本発明の、更なる、好ましい実施例の実装について、図５を参照しながら、以下説明する。例えば、再配置プロセスが開始された後、しかし、接続制御を引き継ぐコマンド（５２２、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ）の前に、コンテキスト情報スナップショットがソースＲＮＣからターゲットＲＮＣへ転送される。コンテキスト情報スナップショットが、既知のメッセージ（例えば、Ｒｅｌｏｃａｔｉｏｎ＿ｒｅｑｕｉｒｅｄ ｍｅｓｓａｇｅ（５０６）又はＲｅｌｏｃａｔｉｏｎ＿ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ（５１０））と共に転送されることが好ましい。しかし、コンテキスト情報スナップショットを、更なる別のメッセージとして転送することができる。この更なるメッセージは、Ｒｅｌｏｃａｔｉｏｎ＿ｒｅｑｕｉｒｅｄ ｍｅｓｓａｇｅ（５０６）の後、行うことが好ましいが、どのような場合であろうと、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ（５２２）の前に行う。しかしながら、コンテキスト情報スナップショットを転送するメッセージ位置は、他の方法で、制限されてはいないが、再配置プロセスが開始した後で、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅ（５２２）の前のどのような時間に贈ることができる。これは、ターゲットＲＮＣが、前記受信したコンテキスト情報を蓄積し、実制御（ａｃｔｕａｌ ｃｏｎｔｒｏｌ）が、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅにより、引き継がれる前に、その圧縮装置・伸張装置を構成することを可能にする。こうして、コンテキスト再配置を効率的に実行でき、結果、データ圧縮／伸張でブレークが発生せず、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅが制御を与える時に、継ぎ目なく継続することができる。
【００５８】
ソースＲＮＣが全受信確認信号を放棄する場合（これは、本発明の第３実施例において説明したが）、再配置プロセスの期間に次のような状況が発生する可能性がある。即ち、移動体端末ＵＥが、無線インターフェース上の擾乱により、そのコンテキスト情報をアップデートする必要がある。それは、コンテキストアップデート要求をソースＲＮＣに送る。しかし、ネットワークにおいて、受信確認信号が放棄され、従って、ネットワークは如何なるアップデート情報を送信しないので、アップデートは不可能である。その結果、移動体端末ＵＥのコンテキスト情報は、ターゲットＲＮＣに現在アップデートされているスナップショットコンテキスト情報に関して、同期外れを起こしている。再び、移動体端末とターゲットＲＮＣのコンテキスト情報が同期している時、データ圧縮／伸張において、ブレークが発生する。
【００５９】
本発明の好ましい実施例に従うと、ＵＭＴＳシステムにおいて、ソースＲＮＣにおける移動体端末が送るコンテキストアップデート要求を検出することにより、同期化をスピードアップすることができる。コンテキストアップデート要求が検出された後、ソースＲＮＣは、ターゲットＲＮＣに送られる全てのメッセージ（例えば、図５におけるＲｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ，５２２）に、この表示を付加する。このように、ターゲットＲＮＣは、必要とされるコンテキストアップデートについての情報を受信する。そして再配置が完了した後で、ターゲットＲＮＣは、移動体端末に、第１パケットをコンテキストアップデートメッセージとして送信することができる。次に、移動体端末の伸張装置は、受信した少なくとも一つのヘッダの少なくとも一つのパケットを、蓄積されている伸張コンテキスト情報で伸張し、受信したコンテキストアップデート・メッセージに従ってコンテキスト情報をアップデートする。再配置プロセスの期間に、圧縮が失敗した場合、これは、コンテキスト再同期化をスピードアップする。
【００６０】
同様に、ソースＲＮＣが、再配置プロセスの期間に、そのコンテキスト情報をアップデートしなければならないが、移動体端末ＵＥへ受信確認信号を送信することができないために、アップデートが不可能な状況で、終了することは当然である。コンテキストアップデート表示が、コンテキストアップデート要求が検出された後で、ソースＲＮＣからターゲットＲＮＣへ送信される、どのようなメッセージ（例えば、Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ）にも付加されるような状況でも、本発明の上記実施例を使用することができる。再び、ターゲットＲＮＣは、必要なコンテキストアップデートについての情報を受信する。それは、更に、再配置プロセスが完了した時に、移動体端末に表示される。或いは、前記Ｒｅｌｏｃａｔｉｏｎ＿ｃｏｍｍｉｔ ｍｅｓｓａｇｅに付与され、ソースＲＮＣによりターゲットＲＮＣに送信される前記コンテキストアップデート表示は、ターゲットＲＮＣの伸張装置におけるトリガーとして使用され、コンテキストリフレッシュアップデートを即時に開始することができる。
【００６１】
実施例のプロセスは、例えば、以下のように実行される。コンテキストアップデート必要性が、ソースＲＮＣからターゲットＲＮＣへ送信されるメッセージに表示される。例えば、２ビットで表示される。ビット組合せ００は、アップデート不要を意味し、０１は、移動体端末ＵＥの伸張装置のコンテキストが同期外れであることを意味し、１０は、ネットワーク側の伸張装置のコンテキストが同期外れであることを意味し、１１は、移動体端末ＵＥの伸張装置のコンテキストとネットワーク側の伸張装置のコンテキストが両方ともに、同期外れであることを意味する。一旦、ターゲットＲＮＣが、この情報を受信したならば、コンテキストアップデートパケットを移動体端末ＵＥ（コンテキストアップデート表示０１）へ送信することにより、コンテキストアップデート要求を移動体端末ＵＥ（コンテキストアップデート表示１０）に送信することによりソースＲＮＣのコンテキスト情報をアップデートすることにより、又は、上記した動作の両方（コンテキストアップデート表示１１）を実行することにより、コンテキストアップデートプロセスを開始することができる。
【００６２】
技術が進歩すると、本発明の基本的アイデアを各種のやり方で実行することができることは、当業者には明らかである。本発明とその実施例は、上記の例に限定されるものではなく、特許請求の範囲の範囲内で変更し得るものである。
【図面の簡単な説明】
【図１】
ＲＯＨＣの種々の圧縮レベル間の移動のブロックダイアグラムである。
【図２】
ＲＯＨＣの種々の圧縮モード間の移動のブロックダイアグラムである。
【図３】
ＵＭＴＳの単純化された構造のブロックダイアグラムである。
【図４】
ユーザデータを送信するためのＵＭＴＳパケットデータサービスのプロトコールスタックである。
【図５】
本発明の第１の好ましい実施例に従う、サービング無線ネットワーク・サブシステム（ＳＲＮＳ）再配置のシグナリングチャートである。
【図６】
本発明の第２の好ましい実施例に従う、サービング無線ネットワーク・サブシステム（ＳＲＮＳ）再配置のシグナリングチャートである。
【図７】
本発明の第３の好ましい実施例に従う、サービング無線ネットワーク・サブシステム（ＳＲＮＳ）再配置のシグナリングチャートである。
【国際公開パンフレット】
2004517580.tif 000003
2004517580.tif 000004
2004517580.tif 000005
2004517580.tif 000006
2004517580.tif 000007
2004517580.tif 000008
2004517580.tif 000009
2004517580.tif 000010
2004517580.tif 000011
2004517580.tif 000012
2004517580.tif 000013
2004517580.tif 000014
2004517580.tif 000015
2004517580.tif 000016
2004517580.tif 000017
2004517580.tif 000018
2004517580.tif 000019
2004517580.tif 000020
2004517580.tif 000021
2004517580.tif 000022
2004517580.tif 000023
2004517580.tif 000024
2004517580.tif 000025
2004517580.tif 000026
2004517580.tif 000027
2004517580.tif 000028
2004517580.tif 000029
2004517580.tif 000030
2004517580.tif 000031
2004517580.tif 000032
2004517580.tif 000033
2004517580.tif 000034
2004517580.tif 000035
2004517580.tif 000036
2004517580.tif 000037
2004517580.tif 000038
【手続補正書】
【提出日】平成14年12月20日(2002.12.20)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
圧縮ヘッダを有するパケットを転送するパケットネットワークにおけるヘッダ圧縮コンテキストを再配置する方法であって、
移動体端末と第１ネットワークエンティティとの間の接続を確立するステップであって、前記移動体端末と前記第１のネットワークエンティティでパケットのヘッダの圧縮と伸張で使用されるコンテキスト情報を蓄積するステップを含むステップと、
前記移動体端末における及び前記第１のネットワークエンティティにおけるコンテキスト情報のアップデートを中止するステップと、
前記コンテキスト情報アップデーティングの前記中止に対応して、前記第１のネットワークエンティティの前記圧縮伸張のコンテキスト情報のスナップショットを取り込むステップであって、前記第１ネットワークエンティティにおける前記コンテキスト情報スナップショットを蓄積するステップを含むステップと、
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更するステップであって、前記第１のネットワークエンティティが蓄積するコンテキスト情報スナップショットを、第２のネットワークエンティティのコンテキスト情報として、前記第２のネットワークエンティティ転送し、それを前記第２のネットワークエンティティのコンテキスト情報として前記第２のネットワークエンティティが蓄積するステップ、及び、前記パケットの前記ヘッダの圧縮と伸張のために、前記移動体端末と前記第２ネットワークエンティティにおいて前記蓄積されたコンテキスト情報を使用するステップとを含むステップと、
を有する前記ヘッダ圧縮コンテキストを再配置する方法。
【請求項２】
前記コンテキスト情報アップデーティングが、前記移動体端末と前記第１のネットワークエンティティ伸張装置が対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより中止されることを特徴とする請求項１記載の方法。
【請求項３】
前記移動体端末がアップリンクデータを圧縮し転送するのを中止させ、前記第１ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させことにより、前記前記コンテキスト情報アップデーティングが中止されることを特徴とする請求項１記載の方法。
【請求項４】
前記第１のネットワークエンティティにおける前記圧縮と伸張コンテキスト情報のスナップショットの前記取り込みが、前記転送されたアップリンクデータとダウンリンクデータが受信され、伸張されるまで、遅延されることを特徴とする、請求項３記載の方法。
【請求項５】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末からの圧縮／伸張受信確認信号を放棄することにより、中止することを特徴とする、請求項１記載の方法。
【請求項６】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末へ、圧縮／伸張受信確認信号を送信することを不能にすることにより、中止することを特徴とする、請求項１記載の方法。
【請求項７】
前記第１のネットワークエンティティにおける前記移動体端末が送信するコンテキストアップデート要求の検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへコンテキストアップデート要求を送信するステップと、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットを送信するステップとを有する、請求項５記載の方法。
【請求項８】
前記第１のネットワークエンティティにおける前記コンテキスト情報の同期外れの検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへコンテキストアップデート要求を送信するステップと、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットを送信するステップとを有する、請求項５記載の方法。
【請求項９】
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更する前に、前記第１のネットワークエンティティが蓄積した前記コンテキスト情報スナップショットを前記第２のネットワークエンティティに転送するステップを、有する請求項１記載の方法。
【請求項１０】
前記方法は、ＵＭＴＳシステムで実行されるローバスト・ヘッダ圧縮（ＲＯＨＣ）に従って使用されることを特徴とする請求項１記載の方法。
【請求項１１】
前記再配置を、少なくとも、部分的に、サービング無線ネットワーク・サブシステム（ＳＲＮＳ）再配置と同時に行うことを特徴とする請求項１０記載の方法。
【請求項１２】
圧縮されたヘッダが、移動体端末とネットワークエンティティとの間を転送されるネットワークであって、
移動体端末と第ネットワークエンティティとの間に接続が確立されるよう構成され、
パケットのヘッダの圧縮と伸張で使用されるコンテキスト情報が前記移動体端末と前記第１のネットワークエンティティで蓄積されるように構成され、
前記移動体端末における及び前記第１のネットワークエンティティにおけるコンテキスト情報アップデーティングが中止されるように構成され、
前記コンテキスト情報アップデーティングの前記中止に対応して、前記第１のネットワークエンティティの前記圧縮伸張のコンテキスト情報のスナップショットを取り込まれ、前記第１ネットワークエンティティにおいて蓄積されるように構成され、
前記第１のネットワークエンティティと前記移動体端末との間の接続が、前記移動体端末と第２のネットワークエンティティとの間の接続を変更するように構成され、
前記第１のネットワークエンティティが蓄積するコンテキスト情報スナップショットが、前記第２のネットワークエンティティのコンテキスト情報として、前記第２のネットワークエンティティに転送し、第２のネットワークエンティティに蓄積されるように構成され、
前記移動体端末と前記第２ネットワークエンティティにおいて前記蓄積されたコンテキスト情報が、前記パケットの前記ヘッダの圧縮と伸張のために使用されるように構成されることを含むパケットネットワーク。
【請求項１３】
前記コンテキスト情報アップデーティングは、前記移動体端末と前記第１のネットワークエンティティの伸張装置が、対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより中止されるように構成されることを特徴とする請求項１２記載のパケットネットワーク。
【請求項１４】
前記移動体端末がアップリンクデータを圧縮し転送するのを中止させ、前記第１ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させることにより、前記前記コンテキスト情報アップデーティングが中止されるように構成されることを特徴とする請求項１２記載のパケットネットワーク。
【請求項１５】
前記第１のネットワークエンティティにおける前記圧縮と伸張コンテキスト情報のスナップショットの前記取り込みが、前記転送されたアップリンクデータとダウンリンクデータが受信され、伸張されるまで、遅延されるように構成されることを特徴とする請求項１４記載のパケットネットワーク。
【請求項１６】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末からの圧縮／伸張受信確認信号を、放棄することにより、中止するように構成することを特徴とする、請求項１２記載のパケットネットワーク。
【請求項１７】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末へ圧縮／伸張受信確認信号を送信することを不能にすることにより、中止するように構成することを特徴とする、請求項１２記載のパケットネットワーク。
【請求項１８】
前記第１のネットワークエンティティにおける前記移動体端末が送信するコンテキストアップデート要求の検出に応じて、
コンテキストアップデート要求が、前記第１のネットワークエンティティから前記第２のネットワークエンティティへ送信されるように構成し、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットが、送信されるように構成されることを特徴とする請求項１６記載のパケットネットワーク。
【請求項１９】
前記第１のネットワークエンティティにおける前記コンテキスト情報の同期外れの検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへ、コンテキストアップデート要求が送信されるよう構成し、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットが送信されるように構成されることを特徴とする請求項１６記載のパケットネットワーク。
【請求項２０】
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更する前に、前記第１のネットワークエンティティが蓄積した前記コンテキスト情報スナップショットが、前記第２のネットワークエンティティに転送されるように構成することを特徴とする請求項１２記載のパケットネットワーク。
【請求項２１】
前記パケットネットワークは、ＵＭＴＳシステムであって、ローバスト・ヘッダ圧縮（ＲＯＨＣ）が実行されるシステムであることを特徴とする請求項１２記載のパケットネットワーク。
【国際調査報告】
2004517580.tif 000039
2004517580.tif 000040
2004517580.tif 000041