(57)【特許請求の範囲】
【請求項１】
圧縮ヘッダを有するパケットを転送するパケットネットワークにおけるヘッダ圧縮コンテキストを再配置する方法であって、
移動体端末と第１ネットワークエンティティとの間の接続を確立するステップであって、前記移動体端末と前記第１のネットワークエンティティでパケットのヘッダの圧縮と伸張で使用されるコンテキスト情報を蓄積するステップを含むステップと、
前記移動体端末における及び前記第１のネットワークエンティティにおけるコンテキスト情報のアップデートを中止するステップと、
前記第１のネットワークエンティティの前記圧縮伸張のコンテキスト情報のスナップショットを取り込むステップであって、前記第１ネットワークエンティティにおける前記コンテキスト情報スナップショットを蓄積するステップを含むステップと、
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更するステップであって、前記第１のネットワークエンティティが蓄積するコンテキスト情報スナップショットを、第２のネットワークエンティティのコンテキスト情報として、前記第２のネットワークエンティティ転送し、それを前記第２のネットワークエンティティのコンテキスト情報として前記第２のネットワークエンティティが蓄積するステップ、及び、前記パケットの前記ヘッダの圧縮と伸張のために、前記移動体端末と前記第２ネットワークエンティティにおいて前記蓄積されたコンテキスト情報を使用するステップとを含むステップと、
を有する前記ヘッダ圧縮コンテキストを再配置する方法。
【請求項２】
前記コンテキスト情報アップデーティングが、前記移動体端末と前記第１のネットワークエンティティ伸張装置が対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより中止されることを特徴とする請求項１記載の方法。
【請求項３】
前記移動体端末がアップリンクデータを圧縮し転送するのを中止させ、前記第１ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させことにより、前記前記コンテキスト情報アップデーティングが中止されることを特徴とする請求項１記載の方法。
【請求項４】
前記第１のネットワークエンティティにおける前記圧縮と伸張コンテキスト情報のスナップショットの前記取り込みが、前記転送されたアップリンクデータとダウンリンクデータが受信され、伸張されるまで、遅延されることを特徴とする、請求項３記載の方法。
【請求項５】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末からの圧縮/伸張受信確認信号を放棄することにより、中止することを特徴とする、請求項１記載の方法。
【請求項６】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末へ、圧縮/伸張受信確認信号を送信することを不能にすることにより、中止することを特徴とする、請求項１記載の方法。
【請求項７】
前記第１のネットワークエンティティにおける前記移動体端末が送信するコンテキストアップデート要求の検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへコンテキストアップデート要求を送信するステップと、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットを送信するステップとを有する、請求項５記載の方法。
【請求項８】
前記第１のネットワークエンティティにおける前記コンテキスト情報の同期外れの検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへコンテキストアップデート要求を送信するステップと、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットを送信するステップとを有する、請求項５記載の方法。
【請求項９】
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更する前に、前記第１のネットワークエンティティが蓄積した前記コンテキスト情報スナップショットを前記第２のネットワークエンティティに転送するステップを、有する請求項１記載の方法。
【請求項１０】
前記方法は、UMTSシステムで実行されるローバスト・ヘッダ圧縮（ROHC）に従って使用されることを特徴とする請求項１記載の方法。
【請求項１１】
前記再配置を、少なくとも、部分的に、サービング無線ネットワーク・サブシステム（SRNS）再配置と同時に行うことを特徴とする請求項１０記載の方法。
【請求項１２】
圧縮されたヘッダが、移動体端末とネットワークエンティティとの間を転送されるネットワークであって、
移動体端末と第ネットワークエンティティとの間に接続が確立されるよう構成され、
パケットのヘッダの圧縮と伸張で使用されるコンテキスト情報が前記移動体端末と前記第１のネットワークエンティティで蓄積されるように構成され、
前記移動体端末における及び前記第１のネットワークエンティティにおけるコンテキスト情報アップデーティングが中止されるように構成され、
前記第１のネットワークエンティティの前記圧縮伸張のコンテキスト情報のスナップショットを取り込まれ、前記第１ネットワークエンティティにおいて蓄積されるように構成され、
前記第１のネットワークエンティティと前記移動体端末との間の接続が、前記移動体端末と第２のネットワークエンティティとの間の接続を変更するように構成され、
前記第１のネットワークエンティティが蓄積するコンテキスト情報スナップショットが、前記第２のネットワークエンティティのコンテキスト情報として、前記第２のネットワークエンティティに転送し、第２のネットワークエンティティに蓄積されるように構成され、
前記移動体端末と前記第２ネットワークエンティティにおいて前記蓄積されたコンテキスト情報が、前記パケットの前記ヘッダの圧縮と伸張のために使用されるように構成されることを含むパケットネットワーク。
【請求項１３】
前記コンテキスト情報アップデーティングは、前記移動体端末と前記第１のネットワークエンティティの伸張装置が、対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより中止されるように構成されることを特徴とする請求項１２記載のパケットネットワーク。
【請求項１４】
前記移動体端末がアップリンクデータを圧縮し転送するのを中止させ、前記第１ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させることにより、前記前記コンテキスト情報アップデーティングが中止されるように構成されることを特徴とする請求項１２記載のパケットネットワーク。
【請求項１５】
前記第１のネットワークエンティティにおける前記圧縮と伸張コンテキスト情報のスナップショットの前記取り込みが、前記転送されたアップリンクデータとダウンリンクデータが受信され、伸張されるまで、遅延されるように構成されることを特徴とする請求項１４記載のパケットネットワーク。
【請求項１６】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末からの圧縮/伸張受信確認信号を、放棄することにより、中止するように構成することを特徴とする、請求項１２記載のパケットネットワーク。
【請求項１７】
前記コンテキスト情報アップデーティングが、前記第１のネットワークエンティティにおいて、前記移動体端末へ圧縮/伸張受信確認信号を送信することを不能にすることにより、中止するように構成することを特徴とする、請求項１２記載のパケットネットワーク。
【請求項１８】
前記第１のネットワークエンティティにおける前記移動体端末が送信するコンテキストアップデート要求の検出に応じて、
コンテキストアップデート要求が、前記第１のネットワークエンティティから前記第２のネットワークエンティティへ送信されるように構成し、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットが、送信されるように構成されることを特徴とする請求項１６記載のパケットネットワーク。
【請求項１９】
前記第１のネットワークエンティティにおける前記コンテキスト情報の同期外れの検出に応じて、前記第１のネットワークエンティティから前記第２のネットワークエンティティへ、コンテキストアップデート要求が送信されるよう構成し、
前記コンテキストアップデート要求を含むパケットとして、前記第２のネットワークエンティティから前記移動体端末へ、第１パケットが送信されるように構成されることを特徴とする請求項１６記載のパケットネットワーク。
【請求項２０】
前記第１のネットワークエンティティと前記移動体端末との間の接続を、前記移動体端末と第２のネットワークエンティティとの間の接続に変更する前に、前記第１のネットワークエンティティが蓄積した前記コンテキスト情報スナップショットが、前記第２のネットワークエンティティに転送されるように構成することを特徴とする請求項１２記載のパケットネットワーク。
【請求項２１】
前記パケットネットワークは、UMTSシステムであって、ローバスト・ヘッダ圧縮（ROHC）が実行されるシステムであることを特徴とする請求項１２記載のパケットネットワーク。
【請求項２２】
パケットネットワーク通信のための移動端末（UE）であって、圧縮ヘッダを有するパケットが前記移動端末（UE）とネットワークエンティティ（SGSN）との間を伝送され、以下のように構成される移動端末。
第１ネットワークエンティティ（旧SGSN）への接続を確立する；
パケットのヘッダの圧縮と伸張で使用されるコンテキスト情報を蓄積する；
コンテキスト情報のアップデートを中止する；
第１ネットワークエンティティ（旧SGSN）と移動端末（UE）との間の接続を、第２ネットワークエンティティ（新SGSN）と移動端末（UE）との間の接続に変更するのに応答して、移動端末（UE）が、移動端末（UE）と第２ネットワークエンティティ（新SGSN）との間の前記接続において、パケットのヘッダーの圧縮と伸張のための蓄積されたコンテキスト情報を使用するように構成される。
【請求項２３】
パケットネットワークのネットワークエンティティであって、圧縮ヘッダを有するパケットが移動端末（UE）とネットワークエンティティ（SGSN）との間を伝送され、ネットワーエンティティ（旧SGSN）が以下のように構成されるネットワークエンティティ。
移動体端末(UE)への接続を確立する；
パケットのヘッダの圧縮と伸張で使用されるコンテキスト情報を蓄積する；
コンテキスト情報のアップデートを中止する；
圧縮と伸張のコンテキスト情報のスナップショットを取り、それを格納する；
ネットワークエンティティ（旧SGSN）と移動端末（UE）との間の接続を、移動端末（UE）と第２ネットワークエンティティ（新SGSN）との間の接続に変更するのに応答して、ネットワーエンティティ（旧SGSN）が、移動端末（UE）と第２ネットワークエンティティ（新SGSN）との間の前記接続において、パケットのヘッダーの圧縮と伸張のためのコンテキスト情報として使用されるように、前記蓄積されたコンテキスト情報スナップショットを第２ネットワークエンティティ（新SGSN）に送信するように構成される。
【発明の詳細な説明】
【０００１】
（本発明の背景）
本発明は、ヘッダ圧縮におけるコンテキスト情報の再配置(relocating)に関する。
ここ数年のＩＰ（インターネットプロトコール）技術における目覚しい進歩は、種々のＩＰベースのアプリケーション使用の可能性を、従来のインターフェースデータ転送以外の分野にも拡大した。特に、ＩＰベースの電話アプリケーションが長足な進歩を遂げており、その結果、従来の電話ネットワーク（公衆電話回線、ＩＳＤＮ）及び移動ネットワーク（公衆陸上移動ネットワーク）における呼の伝送パスの拡大する部分は、原則的に、ＩＰ技術を使って実施することができる。
【０００２】
特に、移動ネットワークにおいて、ＩＰ技術は、多くの利点を提供する。従来の移動ネットワークの音声サービス（これらは、各種ＩＰ音声アプリケーション手段が提供するものであるが）に加えて、移動ネットワークは、更に異なる各種のデータサービス（例えば、インターネット・ブラウジング、ｅメールサービス、ゲーム等）を提供するだろう。該データサービスがパケット切替ＩＰベースサービスにより実施されることが、通常好ましい。このように、ＩＰレイヤは、移動システムプロトコール内に構築され、オーディオ/ビデオサービス及び各種データサービスに役立つ。
【０００３】
移動ネットワークでは、有限な無線リソースをできるだけ効率よく使用することが、大切である。これは、無線インターフェースにおけるＩＰプロトコールの利用を困難にする。というのは、ＩＰベースプロトコールにおいて、転送データの各種ヘッダフィールドの占める割合が大きく、従って、ペイロードの占める部分が小さくなるからである。又、無線インターフェースビット誤り率（ＢＥＴ）、及び、アップリンクとダウンリンク方向のラウンドトリップ時間（ＲＴＴ）が、悪条件の時、かなり大きくなって、多くの公知のヘッダフィールド圧縮方法で種々の問題を起こすからである。このため、各種のＩＰプロトコールに適した種々のヘッダ圧縮方法（特に無線インターフェースにおけるリアルタイムデータ転送に適する）に対するニーズが生まれた。即ち、ビット誤り率とラウンドトリップ時間がかなり大きくなる状態で使用できる効率的なヘッダ圧縮方法である。
【０００４】
このために、ＩＥＴＦ（Internet Engineering Task Force）は、最近、ローバストヘッダ圧縮ＲＯＨＣ（Robust Header Compression）とよばれるヘッダフィールド圧縮方法の標準化の作業を行ってきた。ＲＯＨＣ開発の背後にある考え方は、複数ＩＰヘッダフィールド間には多くの冗長性がある、それはデータパケット内部のみならず、データパケット間にもあるということである。換言すれば、ヘッダフィールドの情報の大多数は、データパケット転送間に変化しない、それ故、それが転送されないとしても、受信側で再構成することが容易であるということである。ヘッダフィールドのある小部分についてだけ、その情報を圧縮するとき、注意を払わねばならない。更に、ＲＯＨＣは、複数の圧縮レベル（その圧縮効率は、レベルが高くなるにつれ、増加する）を持っている。ＲＯＨＣは、常に、最高に効率的な圧縮を使うが、そのレベルの動作の十分な信頼性が確かめられてから、次のレベルに移行するという手順で進められる。ＲＯＨＣは、又、通常のやり方のように、不可欠な複数事項を、下位のリンクレイヤが取り扱う圧縮法に委ねるものである。
【０００５】
全てのヘッダ圧縮技術と同様に、ROHCは、コンテキスト情報の記憶を必要とする。該情報は、圧縮装置（送信装置）及び伸張装置（受信装置）におけるパケットヘッダの圧縮・伸張に使用するためのものであり、本質的に全ヘッダを送信することにより、圧縮／伸張プロセスを開始する。コンテキスト情報が意味するところは、圧縮装置が送信用ヘッダフィールドを圧縮し、伸張装置が、受信用ヘッダフィールドを伸張するのに使う状態(state)を意味する。ヘッダ圧縮／伸張が無線リンクと共に使用される場合には、ヘッダはアップリンク線路で送信され、移動局により圧縮され、ネットワークエンティティが伸張する。ダウンリンク線路の場合はネットワークエンティティはヘッダを有し、移動体端末は、ヘッダを圧縮する
【０００６】
通常の圧縮・伸張の動作においては、伸張コンテキスト情報は、圧縮コンテキスト情報と同期をとっている。それは、伸張コンテキスト情報が、圧縮コンテキスト情報で圧縮されたヘッダを伸張するのに使用され、元の非圧縮ヘッダが再構成されるという意味である。圧縮コンテキスト情報と伸張コンテント情報は、絶えず、圧縮装置と伸張装置によりアップデートされ、二つのコンテキストは、同期状態に置かれる。
【０００７】
移動体端末が、他のネットワークエンティティが管理する他の無線セルにハンドオーバーされる場合、もしコンテキスト情報を新たなネットワークエンティティに再配置(relocate)する有効な手順が定義されない時には、ヘッダ圧縮/伸張プロセスは、再開始手順を経て進めなければならない。該再開始手順はダウンリンク・トラフィックとアップリンク・トラフィックにおける全ヘッダの送信を伴うものである。全ヘッダ付きの、この再開始手順は、現在進行中の通信を混乱させ、エアー・インターフェース（air interface）上のバンド幅を消費する。そこで、旧ネットワークエンティティから、新ネットワークエンティティへの圧縮・伸張コンテキストを転送するための、開発されたメカニズムは、旧ネットワークと移動体端末との間の、圧縮・伸張コンテキスト情報のスナップショットを取り、このスナップショットを、新ネットワークエンティティに送信し、圧縮・伸張コンテキスト情報として使用するというものである。スナップショットを取り、それを新エンティティに転送するために必要な時間の間、通常、圧縮・伸張は、中止される。
【０００８】
上記のコンテキスト情報再配置手続きの一つの問題点は、スナップショットを取り、それを新たなネットワークエンティティに転送するのに長時間必要で、その間、圧縮・伸張が中止しなければならないことである。この結果、リアルタイムのデータ転送において重大な中断が起こる。この中断は、可能な限り短縮せねばならない。もう一つの問題点は、移動システムにおいて、移動体端末は、新旧ネットワークエンティティ間のハンドオーバーが何時発生するか、通常、前もって、知らないことである。それ故、旧ネットワークエンティティが、既にハンドオーバーによりデータの伸張を中止したとしても、移動体端末は、アップリンクデータを圧縮し、それを旧ネットワークエンティティに送信し続けることになる。その場合、前記端末が送信した圧縮データパケットは、消失することになる。
【０００９】
（本発明の概要）
従って、本発明の目的は、上記問題を軽減するために、方法と該方法を実装する装置を開発することである。本発明の目的は、特許請求の範囲の独立項に記載されたものにより特徴付けられる方法とシステムにより達成される。本発明の好ましい実施例は、従属項に示される。
【００１０】
本発明のアイデアは、圧縮装置と伸張装置の両方のコンテキストアップデーティングが、移動体端末と旧ネットワークエンティティにおいて中止される点で、これにより、移動体端末と旧ネットワークエンティティの両方が同一コンテキストを使うことを確実になる。この後で、圧縮・伸張コンテキスト情報が  旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、そこで蓄積される。移動体端末の圧縮装置は、前記コンテキスト情報で、少なくとも一つのパケットの少なくとも一つのヘッダを圧縮し、該圧縮された少なくとも一つのパケットの少なくとも一つのヘッダを新ネットワークエンティティに転送する。コンテキスト情報は、再配置プロセスで変更していないので、移動体端末の圧縮装置と新ネットワークエンティティの伸張装置は、自動的に同期状態になり、データ転送が継続される。
【００１１】
本発明の好ましい実施例によると、コンテキスト情報のアップデーティングは、前記移動体端末と前記第１のネットワークエンティティの両方の伸張装置が、対抗する側の圧縮装置に対し受信確認信号を送信することを不能にすることにより防止される。伸張装置が受信確認信号を送信しないので、圧縮装置のコンテキストは、アップデートされず、移動体端末と旧ネットワークエンティティの両方の圧縮装置は、新パケットの圧縮に同一のコンテキスト情報を使用する。本発明の第２の好ましい実施例によると、移動体端末がアップリンクデータを圧縮し転送するのを中止させ、旧ネットワークエンティティが、ダウンリンクデータを圧縮し転送するのを中止させる。この結果、コンテキスト情報はそれ以上アップデートされない。本発明の第３の好ましい実施例によると、
移動体端末は、通常通りに、ヘッダ圧縮・伸張を継続して動作させる。しかし、移動体端末コンテキスト情報のコンテキストアップデートは、旧ネットワークエンティティのRNC圧縮装置/伸張装置において、移動体端末の圧縮装置/伸張装置からの受信確認信号を放棄することにより、又は、移動体端末の圧縮装置/伸張装置へ如何なる受信確認信号をも中止することにより、防止される。旧えんっとエンティティが全ての受信確認信号を放棄するので、移動体端末の圧縮装置のコンテキストはアップデートされないが、移動体端末は、前のコンテキスト情報でアップリンクデータを圧縮し、転送する。
【００１２】
本発明の方法と装置は、ヘッダ圧縮コンテキストの効率的な再配置を可能にするという利点を提供する。更に、本発明の方法は、移動体端末とネットワークエンティティとの間のコンテキストの同期外れを防止すると同時に、時間ドメーンにおける圧縮/伸張プロセスのブレークを最小化するという利点を提供する。本発明の実施例の更なる利点は、コンテキスト再配置が効率的に十個できることであり、その結果データ圧縮/伸張においてブレークが発生せず、継ぎ目なく継続できることである。
【００１３】
以下、本発明について、好ましい実施例を用いて、図面を参照しながら説明する。
【００１４】
以下、本発明について、実施例に基づいて、ヘッダフィールド圧縮法ROHCに関連して説明する。該ROHC法は、無線インターフェース上のリアルタイムデータ転送に特に適したものである。本発明は、単にROHCに限定されているものではなく、どのような他のヘッダ圧縮方法にも適用できるものである。更に、本発明は、IP/UDP/RTPヘッダ圧縮にも適用できるものである。しかしこれに限定されるものではない。以下に、本発明に不可欠な部分について、ROHCの実施について説明する。問題となる圧縮法の更に詳細な説明については、ミカンのインターネット草案“Robust Header Compression(ROHC)” 第４改訂版、2000年10月11日を参照されたい。
【００１５】
各種圧縮方法において、通常、コンテキストが圧縮・伸張に対して提示される。コンテキストは、圧縮装置が送信ヘッダフィールドを圧縮するのに使用し、伸張装置が受信したヘッダフィールドを伸張するのに使用する状態である。通常、コンテキストは、データ転送接続上で、送信された（圧縮装置）又は受信された（伸張装置）、先行するヘッダフィールドの非圧縮版を含んでいる。更に、コンテキストは、データパケットフロー（例えば、シーケンスナンバ又はデータパケットの時間スタンプ）を識別する情報を含むことができる。このように、コンテキストは、通常、静的情報（全データパケットフロー中変化しない）と動的情報（データパケットフロー中変化するが、規定パターンに従って変化する）の両方の情報を含む。
【００１６】
ROHCは、３圧縮レベルを有し、圧縮は最低レベルから開始し、より高いレベルに徐々に継続する。その基本原則は、圧縮は常にできるだけ高位レベルで行われるが、圧縮装置は、伸張装置が十分な情報を持って、問題レベルの伸張を行うことができることを確認して圧縮を行う。各種圧縮レベル間の移動に影響を与える要因は、連続ヘッダフィールドの変化、伸張装置から受信するポジティブ・ネガティブの受信確認信号、特定シーケンシャルカウンタの終了（受信確認信号が無い場合は）である。同様に、高い圧縮レベルから低いレベルに移動することも可能ではある。
【００１７】
IP（インターネットプロトコール）、UDP（ユーザデータグラムプロトコール）及びRTP（リアルタイムプロトコール）等のプロトコールに関連してROHCが使う圧縮レベルは、イニシエーション／リフレッシュ（I/R）、第１オーダ（FO）及び第２オーダ(SO)であり、これらレベル間の移動は、図１のダイアグラムで説明されている。IRレベルは、伸張装置のコンテキストを生成する又はエラー状態から回復するために使われる。伸張装置が要請したり、アップデータタイマが満了した時に、ヘッダフィールド圧縮が開始する。この時に、圧縮装置は、IRレベルへ移動する。IRレベルにおいて、圧縮装置は、IRヘッダフィールドを、非圧縮フォーマットで送信する。伸張装置がアップデート情報を受信したことが確かな時には、圧縮装置は、より高位レベルに移動しようと試みる。
【００１８】
FOレベルは、データパケット・フローのヘッダフィールドにおける不規則性を受信者に通知するのに使われる。IRレベルの後、圧縮装置は、ヘッダフィールドが一様なパターン（換言すれば、連続ヘッダフィールドは、変化を予測できないようなランダムな変化をする）を形成しない状況におけるFOレベルで動作する。即ち圧縮装置は、伸張装置が一様なパターンのヘッダフィールドを定めるパラメータを受信したことを確信できない。例えば、この典型的な状態は、音声を転送する時、特に最初の音声バースト期間である。FOレベルでは、圧縮装置は、圧縮したFOヘッダフィールドを送信する。圧縮装置が、再度、より高位レベルに移ろうと試みるのは、ヘッダフィールドが一様なパターンを形成し、伸張装置が一様なパターンを表すパラメータを受信したことが確かな時である。FOレベルのデータパケットは、通常、コンテキスト・アップデート情報を含む。それは、伸張に成功するには、連続FOヘッダフィールドの転送を成功させる必要があることを意味する。このように、伸張のプロセスを成功させる為には、FOレベルのパケットの消失、破壊に敏感に対応する必要がある。
【００１９】
SOレベルにおいては、圧縮は最適である。ヘッダフィールドは、一様なパターンを形成する。該パターンは、圧縮装置が圧縮されたSOヘッダフィールドで表現するものであり、前記SOヘッダフィールドは、実際には、データパケットのシーケンス数である。一様なパターンのヘッダフィールドを規定するパラメータについての情報は、伸張装置に転送される。そして、パラメータと受信シーケンス番号に基づいて、伸張装置は、元のヘッダフィールドを外挿する。SOレベルで送られるデータパケットは、実際には、相互に独立であるから、伸張のエラー感度は低い。ヘッダフィールドが、もはや一様なパターンを形成しない場合は、圧縮装置は、FOレベルに戻る。
【００２０】
伸張にも、圧縮レベルは３レベルあって、伸張装置のコンテキスト規定に拘束される。コンテキストが規定されていなかった場合、伸張装置は最低レベルから動作を開始する。その時、伸張装置は、いかなるデータパケットをも伸張していない。伸張装置が、静的及び動的コンテキスト情報を有する第１データパケットを伸張した時、中間レベル（静的コンテキスト）を超えて、直接最上位レベル（フルコンテキスト）に移る。最上位レベルで複数エラー状態がある場合、伸張装置は中間レベルに移動する。しかし、典型的に、成功裏に伸張されたデータパケットは、伸張装置を最上位レベルに戻す。
【００２１】
複数圧縮レベルに加えて、ROHCは３動作モードを有する。即ち、一方向モード（Uモード）、双方向最適モード（Oモード）そして、双方向信頼モード（Rモード）であり、これを図２に示す。図２によると、各圧縮装置レベル（IR、FO、SO）は、各モードにおける前記機能を説明するものであるが、各モードは、それぞれ独自に機能し、独自の仕方でレベル間の移動を定義する。各圧縮状態に対するモードの選択は、使用データ転送接続のパラメータ、例えば戻りチャネルを使用する可能性、エラー確率、分布、ヘッダフィールド規模の変動の影響に基づいて決まる。
【００２２】
一方向モードでは、データパケットの転送は、圧縮装置から伸張装置への転送のみである。従って、ROHCのUモードが有効であるのは、戻りチャネルの使用が出来ない場合、又は、望ましくない状況の場合である。Uモードでは、各圧縮レベル間の移動は、シーケンスカウンタの終了の結果、又は、ヘッダフィールド・パターンの変動、を基にして行われる。戻りチャネルが使用されないから、Uモードでの圧縮は余り有効ではない。又、伝送路におけるデータパケットの消失は、双方向モードにおけるより更に発生する可能性が高い。ROHCの使用は、常にUモードから始まり、双方向モードへ移ることができるのは、伸張装置が１以上のパケットを受信した時であって、この時パケットへの応答として、伸張装置は、モード変更が必要であることを指示する。
【００２３】
双方向最適（O）モードは、一方向モードと類似しているが、相違する点は、Oモードでは、戻りチャネルを使用して、エラー状態を訂正し、伸張装置から圧縮装置へ重要なコンテキスト・アップデートをアクノリッジする点である。Oモードでは、シーケンシャルなアップデートは行わない。Oモードが適しているのは、小さい戻りチャネル・トラフィックを持った、最適圧縮効率を必要とする接続である。Oモードは適度に信頼性のあるデータパケット転送を提供する。その場合、圧縮装置・伸張装置間の同期化が典型的に保持されており、データパケットはほとんど消失しない。もし消失したとしても無視できる数である。しかし、伝送路では、データパケットは、極端に高いビットエラー率で消失する。
【００２４】
双方向信頼（R）モードは、明らかに、前記モードとは異なる。Rモードは、戻りチャネルを使って、前コンテキスト・アップデートをアクノリッジする。このように、Rモードでは、圧縮装置・伸張装置間でデータパケットをほぼ全体的に確実に転送する事ができる。Rモードでは、ヘッダフィールド圧縮をしてもパケットの消失は起こらない。Rモードの欠点は、複数ケースにおいて、ヘッダフィールド・サイズが前記のモードに比して、少し大きめであり、戻りチャネルトラフィックがかなり増加する点である。
【００２５】
３つの動作モードとROHCの３つの圧縮レベルは、ヘッダフィールド圧縮に対する各種動作状態を形成する。各状態は、圧縮装置と伸張装置の動作（即ち、コンテキスト情報）、及び、両装置間のパケットの伝送の定義を必要とする。
圧縮装置及び伸張装置は、複数パラメータについて、各データパケットフロー毎に、別々にネゴーシエイトする。
ROHCの定義によれば、低位プロトコールレイヤ（リンクレイヤ）は、使用される毎に、パラメータ（ヘッダフィールド圧縮に使用される）のネゴーシエイションのメカニズムを提供しなければならない。圧縮を開始する前に、パラメータをネゴーシエイトする。
【００２６】
以下において、再配置手続きを説明するが、用語「旧ネットワークエンティティ」とは、再配置手続きが開始する寸前の、移動体端末が接続しているネットワークエンティティを指す。「旧ネットワークエンティティ」は、又、「第１ネットワークエンティティ」とも呼ぶことができる。「新ネットワークエンティティ」とは、再配置手続き中、移動体端末が接続しているネットワークエンティティを指す。「新ネットワークエンティティ」は、又、「第２ネットワークエンティティ」とも呼ぶことができる。
【００２７】
移動体端末が別のネットワークエンティティがサービスを行う別の無線セルにハンドオーバーされる場合、旧ネットワークエンティティから新ネットワークエンティティへのコンテキスト情報の再配置を、同様に行わねばならない。既知の解決法によれば、これは、圧縮・伸張コンテキスト情報（旧ネットワークと新ネットワーク間で使用される）のスナップショットを取り、このスナップショットを新ネットワークエンティティに渡し、圧縮・伸張コンテキスト情報として使用することにより、行われる。前記既知の解決法によれば、圧縮・伸張は、スナップショットを取り、それを新ネットワークエンティティに転送するために必要な時間の間、中止される。
【００２８】
ダウンリンクトラフィックについて、旧ネットワークエンティティは、圧縮コンテキスト情報を有しており、それは、移動伸張装置の伸張コンテキスト情報に同期している。旧ネットワークエンティティは、圧縮コンテキスト情報のスナップショットを新ネットワークエンティティへ、転送する。すると、新ネットワークエンティティは、記憶された圧縮コンテキスト情報を使って、少なくとも１つのパケットのヘッダを圧縮し、移動伸張装置に転送し、移動伸張装置は先に一時保存した伸張コンテキスト情報を使い、少なくとも一つのデータパケットのヘッダフィールド圧縮を伸張する。アップリンク・トラフィックについて、旧ネットワークエンティティは、伸張コンテキスト情報を有する。前記情報は移動圧縮装置の圧縮コンテキスト情報に同期している。旧ネットワークエンティティは、伸張コンテキスト情報のスナップショットを新ネットワークエンティティに転送すると、該新ネットワークエンティティは、前記スナップショットを記憶し、その伸張コンテキスト情報として使用する。前記移動圧縮装置は、少なくとも一つのパケットの、少なくとも一つのヘッダを、そのコンテキスト情報で圧縮し、前記、少なくとも一つのパケットの、少なくとも一つのヘッダを、新ネットワークエンティティに転送する。すると、該新ネットワークエンティティは、受信した少なくとも一つのヘッダの、少なくとも一つのパケットを、記憶している伸張コンテキスト情報を用いて、伸張する。
【００２９】
再配置（relocation）は、無線ハンドオーバーと、同時に、又は、後に、実行することができる。それ故、コンテキスト情報のスナップショットを取り、ネットワークエンティティ間にそれらを転送する動作の順序は、実施の仕方で変化する。しかし、どのような場合にも、既知の解決法においては、圧縮・伸張は、スナップショットを取り、それを新ネットワークエンティティに転送するために必要な間、中止される。圧縮・伸張プロセスは、ハンドオーバープロセスに関し非同期的であり、該プロセスから独立しているから、又前者はパケットフローにより駆動され、後者は無線条件により駆動されているから、リアルタイムデータ転送で、目に付くブレーク(break)を起こす可能性がある。更に、移動体端末は、旧ネットワークエンティティから新ネットワークエンティティへの、ネットワーク側のハンドオーバーが何時行われるか、通常、前もって知る事は無い。従って、既知の解決法では、旧ネットワークエンティティが、ハンドオーバーのために、前記データの伸張を既に中止していたとしても、移動体端末は、アップリンクデータを圧縮し、それを旧ネットワークエンティティに転送し続ける。それ故、新ネットワークエンティティが転送コンテキスト情報を使うまでには、移動体端末では、それは、コンテキストとの同期から外れている可能性がある。従って、同時に、時間ドメインにおける圧縮/伸張プロセスにおける前記ブレークを最小化しながら、前記コンテキストの同期外れを、防止されねばならない。
【００３０】
本発明によれば、これは、移動体端末と旧ネットワークエンティティの両方の圧縮装置と伸張装置のコンテキスト・アップデーティングを中止することにより、達成される。この中止により、移動体端末と旧ネットワークエンティティの両方が同一コンテキストを使用することが保証され、その中止の後、圧縮装置と伸張装置のコンテキスト情報のスナップショットが、旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、蓄積される。移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、前記圧縮された少なくとも一つのパケットの少なくとも一つのヘッダを、新ネットワークエンティティへ転送する。次に、新ネットワークエンティティは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを伸張する。再配置プロセスの間、コンテキスト情報は変化しないから、移動体端末の圧縮装置と新ネットワークエンティティの伸張装置との間の同期が自動的に取られ、データ転送が継続される。
【００３１】
本発明の第１の好ましい実施例によると、これは、無線ネットワークから移動体端末へシグナリングすることにより達成される。そうすると、ハンドオーバー（また、コンテキスト再配置も同様に）が、直ぐに発生するが、これは、コンテキスト情報が、もうそれ以上アップデートされるべきでないことを意味する。このコンテキストのアップデーティングは、移動体端末と旧ネットワークエンティティの伸張装置が対抗する側の圧縮装置に対する受信確認信号の送信を不能にすることにより、防止することができる。伸張装置が受信確認信号を送信しないので、圧縮装置のコンテキストはアップデートされないし、移動体端末と旧ネットワークエンティティの圧縮装置は、新パケットの圧縮のために同一コンテキスト情報を使用することになる。この後で、圧縮と伸張のコンテキスト情報のスナップショットが、旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、蓄積される。
移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、前記圧縮された少なくとも一つのパケットの少なくとも一つのヘッダを、新ネットワークエンティティへ転送する。次に、新ネットワークエンティティは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを伸張する。
【００３２】
本発明の第２の好ましい実施例によると、移動体端末と旧ネットワークエンティティのコンテキスト情報のアップデーティングは、無線ネットワークから移動体端末へのシグナリングにより防止できる。そうすると、ハンドオーバー（また、コンテキスト再配置も同様に）が、直ぐに発生するが、それに応答して、移動体端末は、アップリンクデータの圧縮と転送を中止し、旧ネットワークエンティティは、ダウンリンクデータの圧縮と転送を中止する。これは、結果として、もうアップデートされないコンテキスト情報を生成する。現行コンテキスト情報は、移動体端末に記憶される。該移動体端末は、メモリからの前記コンテキスト情報をリフレッシュし、必要があれば、新パケットの圧縮のためにそれを使用する用意ができている。圧縮、伸張のコンテキスト情報のスナップショットは、旧ネットワークエンティティに取り込まれ、好ましくは、一定の遅延の後、新ネットワークエンティティに転送し、蓄積される。前記遅延の適当な時間待つことにより、圧縮・転送された全パケットが、確実に、受信され、それぞれの伸張装置により、確実に伸張される。すると、移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、一つのパケットの少なくとも一つのヘッダを新ネットワークエンティティに転送する。次に新ネットワークエンティティは、一つのヘッダの少なくとも一つのパケットを、蓄積された伸張コンテキスト情報で伸張する。
【００３３】
上記二つの実施例が、うまく機能するための条件は、ハンドオーバーの時刻が前もって知られている時、移動体端末が、来るべきハンドオーバーに事前に通知されることである。しかし、常にハンドオーバーが行われる時間を事前に知るというのは可能ではない。例えば、移動体端末が旧セルの無線カバレッジから消滅し、新セルに当然現われる場合のように。従って、再配置について、事前に移動体端末に通知することも可能ではない。本発明の第３の実施例によると、移動体端末はヘッダ圧縮・伸張を正常に継続して行うが、移動体端末コンテキスト情報のアップデートは、旧ネットワークエンティティの圧縮装置／伸張装置において、移動体端末の圧縮・伸張装置の受信確認信号を放棄することにより、妨げられる。前記実施例の他の解決方法として、旧ネットワークエンティティにおける移動体端末に対する受信確認信号の放棄に代え、再配置手続き中における、旧ネットワークエンティティの圧縮装置が、受信確認信号を送信しないように構成することにより置き換えることができる。全受信確認信号は、旧ネットワークエンティティが放棄するか、送信しないかのいずれかであるから、移動体端末の圧縮装置のコンテキストは、アップデートされないが、移動体端末は、前のコンテキスト情報でアップリンクデータを、継続して圧縮し、転送する。この後、圧縮・伸張コンテキスト情報は、旧ネットワークエンティティに取り込まれ、新ネットワークエンティティに転送され、蓄積される。
【００３４】
移動体端末の圧縮装置は、少なくとも一つのパケットの少なくとも一つのヘッダを、前記コンテキスト情報で圧縮し、少なくとも一つのヘッダの少なくとも一つのパケットを新ネットワークエンティティに転送する。次に、新ネットワークエンティティは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを、蓄積された伸張コンテキスト情報で伸張する。この実施例は、ヘッダ圧縮コンテキスト再配置が、移動体端末にハンドオーバーを事前に通知することは不可能であるという条件で、実行されるのを可能にする。ROHCヘッダ圧縮メカニズムが使用されるならば、受信確認信号の放棄プロセスは、ROHC実装の下位のプロトコールレイヤで行われることが好ましい。なぜならば、ROHC規定は、必要とされる構成を可能にするための、実装インターフェースを含まないからである。旧ネットワークエンティティの圧縮装置が再配置手続きの間如何なる受信確認信号をも送信しないように、代わって、構成されている場合は、圧縮装置とそれより低位のレイヤ間の事前に規定されたインターフェースを追加して容易に実行することができる。
【００３５】
移動ネットワークのシグナリング・メカニズムは、通常とおりに規定されており、コンテキスト再配置を極めて効率的にサポートするものではない。その理由は、パケット無線ネットワークの構造は、主として、非実時間データ転送のために設計されているからである。従って、既知の解決法に従って、旧ネットワークエンティティから新ネットワークエンティティへの、コンテキスト情報のスナップショットの転送が、同一メッセージにおいて、行われる。該メッセージは、新ネットワークエンティティへの接続の実制御をシフトするためのコマンドを含む。該メッセージは、Relocation_commit messageと呼ばれ、通常、再配置プロセスにおける、旧ネットワークエンティティから新ネットワークエンティティへ転送される最後のメッセージである。新ネットワークエンティティは、旧ネットワークエンティティからコンテキスト情報スナップショットを、接続制御を引き継ぐコマンドと同時に受信するので、その結果、データ圧縮／伸張における中断を起こす。というのは、新ネットワークエンティティが前記受信コンテキスト情報を蓄積し、前記受信したコンテキスト情報に従って圧縮装置・伸張装置を構成するための、非ゼロの準備時間が必要であるからである。また、旧ネットワークエンティティから新ネットワークエンティティへのコンテキスト情報を転送するのに、時間が必要である。
【００３６】
前記中断を最小化し、本発明の好ましい実施例に従って、上記実施例を更に向上させ、前記コンテキスト情報スナップショットを含んだメッセージが、前記コマンドが接続制御を引き継ぐ前で、再配置プロセスが開始された後、旧ネットワークエンティティから新ネットワークエンティティに転送される。これは、新ネットワークエンティティが、前記受信コンテキスト情報を蓄積し、Relocation_commit messageが実制御をハンドオーバーする前に、圧縮装置と伸張装置を設定することを可能にする。このように、コンテキスト再配置は、効率的に実行され、データ圧縮/伸張において、中断が発生しないようにできる。このように、Relocation_commit messageが制御を与える時には、中断がないように継続できる。
【００３７】
上記の本発明の第３の実施例（旧ネットワークエンティティが全受信確認信号を放棄する）において、再配置プロセスの間に、移動体端末が、そのコンテキスト情報をアップデートしければならない状況が、例えば、無線インターフェース上の擾乱に起因して、発生するかもしれない。その場合、、コンテキスト・アップデート要求を旧ネットワークエンティティに送信するが、前記アップデートは、可能ではないかも知れない。というのは、受信確認信号は、ネットワーク側の如何なるイベントの発生をも、許されないからである。この結果、移動体端末のコンテキスト情報は、スナップショットコンテキスト情報（新ネットワークエンティティにアップデートされる）に関して同期外れとなる。又、移動体端末のコンテキスト情報と新ネットワークエンティティとが同期する時、データ圧縮/伸張において、中断が発生する。
【００３８】
本発明の好ましい実施例により、前記同期化をスピードアップすることができる。その場合、移動体端末が送信するコンテキストアップデート要求を、旧ネットワークエンティティが検知し、いずれかのメッセージ（例えば、Relocation_commit message）にその表示を付加し、コンテキスト情報のスナップショットが取り込まれた後、新ネットワークエンティティに送信する。このように、新ネットワークエンティティが、必要なコンテキストアップデートについての情報を受信し、再配置が達成された後、新ネットワークエンティティは、移動体端末に、コンテキスト・アップデート・メッセージとして第１パケットを送信することができる。移動体端末は、前記コンテキスト・アップデート・メッセージを含む前記パッケージのコンテキストに従って、そのコンテキスト情報をアップデートする。次に、移動体端末の伸張装置が、蓄積した伸張コンテキスト情報で、前記受信した少なくとも一つのヘッダの少なくとも一つのパケットを伸張し、受信したアップデートメッセージに従ってコンテキスト情報をアップデートする。圧縮同期が、再配置プロセス間に失われた場合には、これにより、コンテキスト再同期化がスピードアップされる。
【００３９】
同様に、旧ネットワークエンティティは、そのコンテキスト情報をアップデートする再配置プロセスの間に、終了した方がよい。しかし、移動体端末に一切受信確認信号を創始できないから、そのアップデートは、可能ではない。このような状況で、コンテキストアップデート表示が如何なるメッセージ（Relocation_commit message）にも付加され、コンテキスト情報のスナップショットが取り込まれた後、新ネットワークエンティティに送信される場合には、本発明の上記実施例を利用することができる。又、新ネットワークエンティティは必要なコンテキストアップデートについての情報を受信し、再配置プロセスが完了した時、移動体端末にそれを知らせる。他の方法として、メッセージ（Relocation_commit message）に付加し、旧ネットワークエンティティが新ネットワークエンティティに送信した前記コンテキストアップデート表示は、新ネットワークエンティティの伸張装置におけるトリガーとして使い、コンテキスト・フレッシュ・アップデートを直ちに開始することができる。
【００４０】
上記の方法とその実施例は、例えば、ＵＭＴＳ(Universal Mobile Telecommunication System)及びＩＭＴ−2000(International Mobile Telephone System)、並びに第２世代移動システムの更なる開発プロジェクトであるＧＥＲＡＮ（GSM Edge Radio Access Network）と呼ばれる第３世代システムに応用できることが好ましい。
【００４１】
以下において、本発明を、ＵＭＴＳシステムのパケット無線サービスに関連した、具体的には、ＵＭＴＳ（ＳＲＮＳ Relocation）の無線ネットワークサブシステム間のハンドオーバーに関連した一例を以って説明する。その間ヘッダ圧縮コンテキスト情報は、旧無線ネットワークエンティティコントローラＲＮＣから新無線ネットワークコントローラへ再配置される必要がある。しかし、本発明はＵＭＴＳシステムに限定されるものではなく、ヘッダ圧縮コンテキスト情報再配置を実行しなければならない、どのようなパケット切替データ転送方法に適用できるものである。
【００４２】
ＵＭＴＳ移動通信システム構成を図３を参照しながら説明する。図３は、本発明の説明に関連したブロックだけを含む。当業者には明らかなことであるが、従来の移動通信システムは、又、この意味では、更に詳しく説明する必要のない、他の機能と構成を有する。移動通信システムの主要構成要素は、コアネットワークＣＮとＵＭＴＳ地上無線アクセスネットワークＵＴＲＡＮ（これは、移動通信システム、移動体端末又はユーザ装置ＵＥの固定ネットワークを形成する。）である。ＣＮとＵＴＲＡＮとの間のインターフェースは、ｌｕとよばれ、ＵＴＲＡＮとUEの間のインターフェースは、Ｕｕとして知られている。
【００４３】
UTRANは、通常、複数の無線ネットワークサブシステムRNSから構成される。前記サブシステム間には、ｌｕｒと呼ばれるインターフェースがある。ＲＮＳは、無線ネットワークコントローラＲＮＣと１つ又はそれ以上の基地局ＢＳ（これは、ノードＢｓと呼ばれる）から構成される。ＲＮＣとＢＳとの間のインターフェースは、ｌｕｂと呼ばれる。基地局ＢＳは、通常、無線パス（radio path）の実行を担当している。又、無線ネットワークコントローラRNCは少なくとも以下のことを担当している。即ち、無線リソース管理、セル間のハンドオーバーの制御、電源制御、タイミングと同期、加入者端末のページング。
【００４４】
コアネットワークCNは、UTRANの外部の移動通信システムに属するインフラから構成される。コアネットワークにおいて、移動切替センタ/ビジタ位置レジスタ３G−MSC/VLRは、ホームロケーションレジスタHLRと、インテリジェントネットワークのサービス制御ポイントSCPと通信することが好ましい。ホームロケーションレジスタHLRとビジタロケーションレジスタVLRは、移動通信加入者に関する情報を有する。ホームロケーション・レジスタHLRは、移動通信ネットワークの全加入者及び加入者が注文するサービスに関する情報を有する。ビジタロケーションレジスタVLRは、所定移動切替センタMSCのエリアを訪問する移動局に関する情報を有する。無縁システムのサービングGPRSサポートノード３G−SGSNへの接続は、Gｓ’のインターフェースを介して、確立される。ゲートウエー移動切替センタGMSC（Gateway MSC図示しない）を介して公衆回線網PSTN/ISDNに確立される。
Gnインターフェースを介したサービングサポートノード３G−SGSNからゲートウェーGPRSサポートノードGGSN、又GGSNから外部データネットワークPDNへの接続が確立される。移動切替センタ３G−MSC/VLRとサービングサポートノード３G−SGSNは、双方共に、ｌｕインターフェースを介して、無線ネットワークUTRAN（UMTS Terrrestrial Radio Access Network）と通信する。
【００４５】
このように、ＵＭＴＳシステムは、パケット無線システムを有し、該システムは、ＧＳＭネットワークに接続したＧＲＰＳシステムに従って最大限実施される。そのために、ネットワーク構成要素の名称には、ＧＰＲＳシステムへの参照を含まれる。ＵＭＴＳのパケット無線システムは、複数のサービングサポートノードとゲートウェー・サポートノードを有し、通常、複数サービングサポートノード3G-SGSNは、一つのゲートウェー3G−GGSNへ接続される。3G-SGSNノードと3G−GGSNノードは、ルータとして機能し、移動体端末のモビリティをサポートし、移動体通信システムを制御し、その位置及び使用されるプロトコールに無関係に、移動体端末へデータパケットをルーティングする。サービングサポートノード3G-SGSNは、無線ネットワークUTRANを介して、移動体端末UEと通信する。サービングサポートノード3G-SGSNの機能は、そのエリアにおいて、パケット無線接続ができる移動体端末を検出し、データパケットをこれら移動端末に送信し、該移動端末から受信し、そのサービスエリアにおける移動体端末の位置をモニタすることである。更に、サービングサポートノード3G-SGSNは、移動体切替センタ３G−MSC及びビジタ位置レジスタと、シグナリングインターフェースGｓ’と通信し、また、ホームロケーションレジスタHLRと、Grインターフェースを介して通信する。ホームロケーションレジスタHLRは、又、パケット無線サービスに関する記録を有し、加入者向けパケットデータ・プロトコールのコンテントを有する。
【００４６】
ゲートウェー3G−GGSNは、UMTSネットワークのパケット無線システムと外部データネットワークPDN（Packet Data Network）との間のゲートウェーとして機能する。外部データネットワークは、UMTS又は他のネットワークオペレータのGPRSネットワーク、インターネット、X．25ネットワーク又はプライベートLANを含む。ゲートウェー・サポート・ノード3G−GGSNは、Giインターネットを介して、これらデータネットワークと数進する。ゲートウェーサポートノード3G−GGSNとサービングサポートノード3G-SGSNとの間で転送されるデータパケットは、常に、ゲートウェー・トンネリング・プロトコールGTPに従って、カプセル化される。ゲートウェーサポートノード3G−GGSNは、移動体端末のPDPアドレス（packet Data Protocol）、ルーティングデータ、即ち3G−GGSNアドレスを有する。こうして、ルーティングデータは、外部データネットワークとサービングサポートノード3G-SGSNとの間でデータパケットをリンクするのに使用される。ゲートウェー・サポート・ノード3G−GGSNとサービングサポートノード3G-SGSNと間のネットワークは、IPプロトコール、好ましくはIPｖ６（Internet Protocol, version6）を使用するネットワークである。
【００４７】
UMTSにおいては、図４に基づくプロトコールスタックが、パケット切替ユーザデータ（ユーザプレーン）の転送において、使用される。無線ネットワークUTRANと移動体端末UEとの間のインターフェースUuにおいて、低位データ伝送は、物理層におけるWCDMA又はTD−TDMAプロトコールに従って実行される。データパケットは、物理層とRLC層（無線リンク層）との間を、MAC層（Media Access Layer）により伝送される。MAC層は、物理層より上位にあり、RLC層は種々の無線ベアラの無線リンクの論理制御を担当しているものである。RLCの機能（functionalities）は、１又はそれ以上のRLCデータパケットRLC−PDUへ伝送されるユーザデータ（RLC−SDU、サービスデータ・ユニット）のセグメンテーションを有する。RLCのトップにあるPDCP層のデータパケット（PDCP−PDU）及びそれらに関連するヘッダフィールドは、必要があれば、無線ネットワークUTRAN及び移動体端末UEがサポートするヘッダ圧縮方法により圧縮される。この後で、PDCP−PDUｓ（これはRLC−SDUに対応する）は、RLCに供給される。ユーザデータとRLC−SDUは、セグメント化され、データ転送に必要なアドレスと制御情報を付加したRLCフレームで、転送される。RLC層は、又、破壊されたフレームの再転送を担当する。サービング・サポートノード３G−DGSNは、移動体端末UEから到着したデータパケットを、無線ネットワークRANを通って正しいゲートウェーサポート・ノード３G−GGSNへのルーティングを担当する。この接続に尾は、トンネリングプロトコールGTPが使用される。該プロトコールは、コアネットワークを介して転送される全ユーザデータとシグナリングをカプセル化し、トンネルするものである。GTPプロトコールは、コアネットワークが使用するIP以上で動作する。
【００４８】
パケット切替ユーザデータ用無線ベアラ確立され（RE establishment）、移動体端末と無線ネットワークとの間で再構成される場合、両ピア（peers）は、無線リソース制御プロトコールRRCに基づくシグナリングを使って、無線ベアラのパラメータを交渉する。無線リソース制御プロトコールRRCは、例えば、移動体端末と無線ネットワークUTRANとの間の接続を確立し、構成し、維持し、終了することを担当し、又、コアネットワークCNおよび無線ネットワークRANから転送された制御情報を、移動体端末UEに転送することを担当する。無線ベアラを規定するパラメータの一つは、端末が使用するヘッダ圧縮方法である。転送データパケットのヘッダの圧縮と、受信データパケットヘッダの伸張装置は、UMTSシステムにおいては、パケットデータプロトコールに属するパケットデータ・コンバージェンス・プロトコールPDCP層にて実行される。前記PDCP層のタスクは、チャネル効率の改善に関連する機能を含む。前記チャネル効率の改善は、通常、データパケットヘッダ圧縮アルゴリズムの利用等、種々の最適化方法に基く。現在UMTSのためのネットワークレベルプロトコールは、IPプロトコールであるから、使われる圧縮アルゴリズムは、IETF(Internet Engineering Task Force)が標準化するアルゴリズムである。従って、ROHC圧縮法は、UMTSシステムに特に適合しているものである。
【００４９】
UMTSシステムにおける本発明の実装について、図５乃至７を参照して、サービング無線ネットワークサブシステム（SRNS）再配置に関し、説明する。
【００５０】
UMTSシステムにおいて、移動体端末UEが、無線ネットワークコントローラRNCが管理する他の無線セルにハンドオーバーされる場合、新無線ネットワークコントローラRNCへのコンテキスト情報の再配置を、同様に実行しなければならない。これは、既知の解決法に従って、実行される。即ち、旧無線ネットワークコントローラ（ソースRNC）と移動体端末との間で使用される圧縮・伸張コンテキスト情報のスナップショットを取り、このスナップショットを、圧縮・伸張コンテキスト情報として、新無線ネットワークコントローラ（ターゲットRNC）へ渡す。該スナップショットの転送は、UMTSシステムに基づくSRNS再配置シグナリングの、シグナリングメッセージに含まれるものとして実行される。スナップショットを取り込み、それをターゲットRNCへ転送するのに必要な間、圧縮・伸張は中止される。
【００５１】
本発明によると、SRNS再配置、及び、移動体端末とソース無線ネットワークコントローラ（ソースRNC）とにおける圧縮/伸張のコンテキストアップデーティング、を実行する決定に対応して、UMTSシステムにおけるコンテキストの同期外れは防止され、中止による時間度メーンの圧縮/伸張のブレークは同時に最小化される。前記アップデーティングは、移動体端末とソースRNCが同一コンテキストを使用するのを保証し、その後、圧縮・伸張コンテキスト情報のスナップショットがソースRNCに取り込まれ、ターゲット無線ネットワークコントローラ（target RNC）に転送され、蓄積される。移動体圧縮装置は、前記コンテキスト情報を使って、少なくとも一つのパケットの少なくとも一つのヘッダを圧縮し、圧縮された少なくとも一つのパケットの少なくとも一つのヘッダをターゲットRNCへ転送する。次に、ターゲットRNCは、受信された少なくとも一つのヘッダの少なくとも一つのパケットを、蓄積された伸張コンテキスト情報で伸張する。コンテキスト情報は、再配置プロセスの間、変化しないから、移動体端末の圧縮装置と、ターゲットRNCの伸張装置は、自動的に、同期化され、データ転送は、継続される。
【００５２】
UMTSシステムにおける本発明の、第１の好ましい実施例の実装について、図５を参照しながら、以下説明する。移動体端末UEの移動又は無線状態の変化に基づいて、例えば、無線リソースコントローラRRCにおいて、SRNS再配置（500、502）を実行する決定がされる。本発明によると、無線リソースコントローラRRCは、移動体端末UEに、ハンドオーバー（コンテキスト再配置も同様に）が、まじかに発生すること（504）を知らせると、これに対応して、移動体端末UEは、コンテキスト情報のアップデーティングを中止する。移動体端末UEに対するシグナリングは、RRCシグナリングとして、又は、PDCP層上のインバンドシグナリングとして実行されることが、好ましい。コンテキスト情報のアップデーティングの中止は、移動体端末とソースRNC伸張装置が、対抗する側（opposite side）の圧縮装置への受信確認信号の送信を不能にすることにより行われる。伸張装置が受信確認信号を送信しないので、圧縮装置のコンテキストは、アップデートされず、移動体端末とソースRNC圧縮装置は、新パケットの圧縮に同一のコンテキスト情報を使用する。この後、ソースRNCは、Relocation_required messageを旧SGSN(506)へ送信して、既知のSRNS再配置プロセスを開始する。それは、更に新SGSN(508)を介してターゲットRNC（510）へ送られる。無線ベアラは、RRC(512)が与えるインストラクションに従って、新SGSNとターゲットRNCとの間に確立される。ターゲットRNCは、再配置リクエストに対し受信確認信号を送信する。その受信確認信号は、新SGSN（514）を介して、旧SGSN（516）にルーティングされ、更に、Relocation_command message（518）ソースRNCにリーティングされる。
【００５３】
SRNS再配置プロセスの間、圧縮・伸張コンテキスト情報のスナップショットは、ソースRNC（520）に取り込まれ、遅くとも（at latest）Relocation_commit message（522）において、ソースRNCからターゲットRNCへ転送され、ターゲットRNCにおいて、蓄積される。ソースRNCは、移動体端末UEへ送信する可能なダウンリンクデータを、ターゲットRNC（524）へ送る。これにより、新SGSN(526)へのRelocation_detect messageを送信することにより、再配置が確認される。ターゲットRNCは、RNTI_reallocation message（528）を移動体端末UEに送信する。前記端末は、新RNCの識別番号を移動体端末に表示する。要求があれば、ターゲットRNC圧縮装置は、コンテキストアップデートの表示を転送する。これが行われるのは、スナップショットがターゲットRNC(522)に転送された後で、ソースRNCが、既に接続を開放されている場合である。そうでない場合は、コンテキストアップデートは、ターゲットRNCと移動体端末UEとの間の後のシグナリングの接続において、実行されねばならない。移動体端末UEは、RNTI_reallocation_complete message(530)として、コンファメーションを送信し、RNCの変化を確認する。こうして、ターゲットRNCへのコンテキスト情報の再配置は、成功裏に実行され、同時にコンテキストの同期外れを防止でき、圧縮／伸張プロセスのブレークを最小化できる。一方、新SGSNは、GGSN(532,534)に対するPDPコンテキストをアップデートする。ターゲットRNCは、Relocation_complete messageを新SGSN(536)に送り再配置を確認する。前記新SGSNは、更に旧SGSN(538)に送られ、新SGSN(540)に受信確認に送り返される。その後、ソースRNCと旧SGSNとの間の接続は切断される（524、544）。
【００５４】
UMTSシステムにおける本発明の、第２の好ましい実施例の実装について、図６を参照しながら、以下説明する。再び、移動体端末UEの移動又は無線状態の変化に基づいて、例えば、無線リソースコントローラRRCにおいて、SRNS再配置（600、602）を実行する決定がされる。本発明の、この実施例によると、無線リソースコントローラRRCは、移動体端末UEに、ハンドオーバー（コンテキスト再配置も同様に）がまもなく発生すること（604）を知らせると、これに対応して、移動体端末UEが、アップリンクデータの圧縮・転送を中止し、ソースRNCは、ダウンリンクデータの圧縮・転送を中止する。
移動体端末UEとソースRNCに対するシグナリングは、RRCシグナリングとして、又は、PDCP層上のインバンドシグナリングとして実行されることが、好ましい。この結果、コンテキスト情報はそれ以上アップデートされない。現行コンテキスト情報は、移動体端末UEに蓄積される。前記端末は、メモリからの前記コンテキスト情報を、直ぐにリフレッシュでき、必要があれば、新パケットの圧縮のためにそれを使用できる．この後、ソースRNCは、既知のSRNS再配置プロセスを開始する。これは、それぞれの参照番号で先に説明したものと同様である。従って、ここで再び説明する必要はない。圧縮・伸張コンテキスト情報のスナップショットは、好ましくは前記SRNS再配置プロセスの間に、ソースRNCに取り込まれ、一定の遅延の後、遅くとも（at latest）Relocation_commit message（622）で、ターゲットRNCへ転送され、ターゲットRNCで蓄積される。前記遅延の適当な時間待つことにより、移動体端末が圧縮し、送信した全パケットが、確実に、受信され、ソースRNCの伸張装置により、確実に伸張される。ソースRNCは、移動体端末UEに送信する可能なダウンリンクデータを、ターゲットRNC(624)に送る。これにより、新SGSN(626)へのRelocation_detect messageを送信することにより、再配置が確認される。ターゲットRNCは、又、RNTI_reallocation message(628)を移動体端末UEへ送信する。
前記端末は、新RNCの識別番号を移動体端末に表示する。要求があれば、ターゲットRNC圧縮装置は、コンテキストアップデートの表示を転送する。これが行われるのは、スナップショットがターゲットRNC(622)に転送された後で、ソースRNCが、既に接続を開放されている場合である。そうでない場合は、コンテキストアップデートは、ターゲットRNCと移動体端末UEとの間の後のシグナリングの接続において、実行されねばない。移動体端末UEは、RNTI_reallocation_complete message(630)として、コンファメーションを送信し、RNCの変化を確認する。こうして、ターゲットRNCへのコンテキスト情報の再配置は、成功裏に実行され、同時に、コンテキストの同期外れを防止でき、圧縮／伸張プロセスのブレークを最小化できる。
【００５５】
UMTSシステムにおける本発明の、第３の好ましい実施例の実装について、図７を参照しながら、以下説明する。この場合、移動体端末は、再配置について事前に通知されていない。再び、無線リソースコントローラRRCにおいて、SRNS再配置（700、702）を実行する決定がされる。しかし移動体端末UEには、これについて通知しない。移動体端末UEは、通常通りに、ヘッダ圧縮・伸張を継続して動作させる、しかし、移動体端末コンテキスト情報のコンテキストアップデートは、ソースRNC圧縮装置/伸張装置において、移動体端末の圧縮装置/伸張装置からの全ての受信確認信号を放棄することにより、又は、ソースRNCの圧縮装置が再配置プロセスの期間、受信確認信号を送信しないように構成することにより、防止される。前記受信確認信号を放棄するプロセスは、ROHC圧縮アルゴリズムが動作するPDCP層において、論理的に（logically）行われることが好ましい。ROHCの規定は、要求される構成を可能にする、如何なる実装インターフェースを含まないからである。
【００５６】
ソースRNCは、放棄したことについて、RRC（704）を介して通知されることが好ましい。ソースRNCが全受信確認信号を放棄するのであるから、移動体端末圧縮装置の個的はアップデートされないが、移動体端末は、以前のコンテキスト情報で、継続して圧縮し、アップリンクデータを転送する。この後、ソースRNCは、既知のSRNS再配置プロセスを開始する。これは、それぞれの参照番号で先に説明したものと同様である。従って、ここで再び説明する必要はない。圧縮・伸張コンテキスト情報のスナップショットは、好ましくは前記SRNS再配置プロセスの間にソースRNCに取り込まれ、一定の遅延の後、遅くとも（at latest）Relocation_commit message（722）で、ターゲットRNCへ転送され、蓄積される。SRSNを完成するプロセスとコンテキスト情報の再配置は、前記したものと同様である。再配置プロセスが終了した後、RNC（以前ソースRNCとして機能した）は、正常に機能しつづける。即ち、それは、移動体端末UEの圧縮装置/伸張装置からの如何なる受信確認信号を放棄しない。事前に移動体端末UEに通知することは不可能であるという状況で、この実施例によれば、ヘッダ圧縮コンテキスト再配置を実行することが可能になる。
【００５７】
UMTSシステムにおける本発明の、更なる、好ましい実施例の実装について、図５を参照しながら、以下説明する。例えば、再配置プロセスが開始された後、しかし、接続制御を引き継ぐコマンド（522、Relocation_commit message）の前に、コンテキスト情報スナップショットがソースRNCからターゲットRNCへ転送される。コンテキスト情報スナップショットが、既知のメッセージ（例えば、Relocation_required message(506)又はRelocation_request message(510)）と共に転送されることが好ましい。しかし、コンテキスト情報スナップショットを、更なる別のメッセージとして転送することができる。この更なるメッセージは、Relocation_required message(506)の後、行うことが好ましいが、どのような場合であろうと、Relocation_commit message（522）の前に行う。しかしながら、コンテキスト情報スナップショットを転送するメッセージ位置は、他の方法で、制限されてはいないが、再配置プロセスが開始した後で、Relocation_commit message（522）の前のどのような時間に贈ることができる。これは、ターゲットRNCが、前記受信したコンテキスト情報を蓄積し、実制御（actual control）が、Relocation_commit messageにより、引き継がれる前に、その圧縮装置・伸張装置を構成することを可能にする。こうして、コンテキスト再配置を効率的に実行でき、結果、データ圧縮/伸張でブレークが発生せず、Relocation_commit messageが制御を与える時に、継ぎ目なく継続することができる。
【００５８】
ソースRNCが全受信確認信号を放棄する場合（これは、本発明の第３実施例において説明したが）、再配置プロセスの期間に次のような状況が発生する可能性がある。即ち、移動体端末UEが、無線インターフェース上の擾乱により、そのコンテキスト情報をアップデートする必要がある。それは、コンテキストアップデート要求をソースRNCに送る。しかし、ネットワークにおいて、受信確認信号が放棄され、従って、ネットワークは如何なるアップデート情報を送信しないので、アップデートは不可能である。その結果、移動体端末UEのコンテキスト情報は、ターゲットRNCに現在アップデートされているスナップショットコンテキスト情報に関して、同期外れを起こしている。再び、移動体端末とターゲットRNCのコンテキスト情報が同期している時、データ圧縮/伸張において、ブレークが発生する。
【００５９】
本発明の好ましい実施例に従うと、UMTSシステムにおいて、ソースRNCにおける移動体端末が送るコンテキストアップデート要求を検出することにより、同期化をスピードアップすることができる。コンテキストアップデート要求が検出された後、ソースRNCは、ターゲットRNCに送られる全てのメッセージ（例えば、図５におけるRelocation_commit,522）に、この表示を付加する。このように、ターゲットRNCは、必要とされるコンテキストアップデートについての情報を受信する。そして再配置が完了した後で、ターゲットRNCは、移動体端末に、第１パケットをコンテキストアップデートメッセージとして送信することができる。次に、移動体端末の伸張装置は、受信した少なくとも一つのヘッダの少なくとも一つのパケットを、蓄積されている伸張コンテキスト情報で伸張し、受信したコンテキストアップデート・メッセージに従ってコンテキスト情報をアップデートする。再配置プロセスの期間に、圧縮が失敗した場合、これは、コンテキスト再同期化をスピードアップする。
【００６０】
同様に、ソースRNCが、再配置プロセスの期間に、そのコンテキスト情報をアップデートしなければならないが、移動体端末UEへ受信確認信号を送信することができないために、アップデートが不可能な状況で、終了することは当然である。コンテキストアップデート表示が、コンテキストアップデート要求が検出された後で、ソースRNCからターゲットRNCへ送信される、どのようなメッセージ（例えば、Relocation_commit）にも付加されるような状況でも、本発明の上記実施例を使用することができる。再び、ターゲットRNCは、必要なコンテキストアップデートについての情報を受信する。それは、更に、再配置プロセスが完了した時に、移動体端末に表示される。或いは、前記Relocation_commit messageに付与され、ソースRNCによりターゲットRNCに送信される前記コンテキストアップデート表示は、ターゲットRNCの伸張装置におけるトリガーとして使用され、コンテキストリフレッシュアップデートを即時に開始することができる。
【００６１】
実施例のプロセスは、例えば、以下のように実行される。コンテキストアップデート必要性が、ソースRNCからターゲットRNCへ送信されるメッセージに表示される。例えば、２ビットで表示される。ビット組合せ00は、アップデート不要を意味し、01は、移動体端末UEの伸張装置のコンテキストが同期外れであることを意味し、10は、ネットワーク側の伸張装置のコンテキストが同期外れであることを意味し、11は、移動体端末UEの伸張装置のコンテキストとネットワーク側の伸張装置のコンテキストが両方ともに、同期外れであることを意味する。一旦、ターゲットRNCが、この情報を受信したならば、コンテキストアップデートパケットを移動体端末UE(コンテキストアップデート表示01)へ送信することにより、コンテキストアップデート要求を移動体端末UE（コンテキストアップデート表示10）に送信することによりソースRNCのコンテキスト情報をアップデートすることにより、又は、上記した動作の両方（コンテキストアップデート表示11）を実行することにより、コンテキストアップデートプロセスを開始することができる。
【００６２】
技術が進歩すると、本発明の基本的アイデアを各種のやり方で実行することができることは、当業者には明らかである。本発明とその実施例は、上記の例に限定されるものではなく、特許請求の範囲の範囲内で変更し得るものである。
【図面の簡単な説明】
【図１】  ROHCの種々の圧縮レベル間の移動のブロックダイアグラムである。
【図２】  ROHCの種々の圧縮モード間の移動のブロックダイアグラムである。
【図３】  UMTSの単純化された構造のブロックダイアグラムである。
【図４】  ユーザデータを送信するためのUMTSパケットデータサービスのプロトコールスタックである。
【図５】  本発明の第１の好ましい実施例に従う、サービング無線ネットワーク・サブシステム（SRNS）再配置のシグナリングチャートである。
【図６】  本発明の第２の好ましい実施例に従う、サービング無線ネットワーク・サブシステム（SRNS）再配置のシグナリングチャートである。
【図７】  本発明の第３の好ましい実施例に従う、サービング無線ネットワーク・サブシステム（SRNS）再配置のシグナリングチャートである。
【図１】
0004005508.tif 000002
【図２】
0004005508.tif 000003
【図３】
0004005508.tif 000004
【図４】
0004005508.tif 000005
【図５】
0004005508.tif 000006
【図６】
0004005508.tif 000007
【図７】
0004005508.tif 000008