JP4882959B2 - パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置 - Google Patents

パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置 Download PDF

Info

Publication number
JP4882959B2
JP4882959B2 JP2007279116A JP2007279116A JP4882959B2 JP 4882959 B2 JP4882959 B2 JP 4882959B2 JP 2007279116 A JP2007279116 A JP 2007279116A JP 2007279116 A JP2007279116 A JP 2007279116A JP 4882959 B2 JP4882959 B2 JP 4882959B2
Authority
JP
Japan
Prior art keywords
packet
packet communication
access network
rohc
header
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.)
Expired - Fee Related
Application number
JP2007279116A
Other languages
English (en)
Other versions
JP2009111485A (ja
Inventor
出 佐藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2007279116A priority Critical patent/JP4882959B2/ja
Priority to US12/255,692 priority patent/US8483176B2/en
Priority to EP08167330.3A priority patent/EP2053817B1/en
Publication of JP2009111485A publication Critical patent/JP2009111485A/ja
Application granted granted Critical
Publication of JP4882959B2 publication Critical patent/JP4882959B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0064—Transmission or use of information for re-establishing the radio link of control information between different access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface

Description

本発明は、パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置に関する。本発明は、例えば、次世代ネットワークにおけるパケット通信に用いると好適である。
３ＧＰＰでは、既存の様々な無線アクセス方式（アクセス網）を収容可能とし、コア網の完全ＩＰ化（All IP）を可能とする次世代システム（Release 8）が検討されている。その内容は、後記の非特許文献１（3GPP TS 23.401 V1.2.1）に説明されている。
ここで検討されている次世代アーキテクチャは、Systems Architecture Evolution（ＳＡＥ）と呼ばれている。なお、ＳＡＥでの無線技術がＬＴＥ（Long Term Evolution）と呼ばれる。
また、この非特許文献１の第5.5.2.1章には、ＳＡＥにおいて、ユーザ端末（ＵＥ：User Equipment）がE-UTRAN（Evolved Universal Terrestrial Radio Access Network）からUTRANへハンドオーバする際の処理（E-UTRAN to UTRAN Iu mode Inter RAT(radio access technology) handover based on PS（Packet Switched） handover）について記載されている。E-UTRANについては、後記の非特許文献２（3GPP TS 36.300 V8.2.0）に記載がある。
なお、下記の特許文献１には、通信システムにおけるパケットフロープロセシングに関する技術が記載されている。この特許文献１には、リソース予約プロトコル（ＲＳＶＰ：Resource ReSerVation Protocol）のメッセージに、パケットフロー処理法を決定するために使用されるパケットフローパラメータ情報が含まれることが記載されている。また、パケットフローパラメータ情報の例として、パケットフローのＱｏＳ（Quality of Service）やパケットフローで使用されるべきヘッダ圧縮タイプ等が挙げられている（例えば段落００５１〜００５８等参照）。
特表２００５−５２９５５４号公報 3GPP TS23.401 V1.2.1 第5.5.2.1章、［online］、平成１９年９月２４日、［平成１９年１０月１５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/23401.htm＞ 3GPP TS36.300 V8.2.0 第4.1章、［online］、平成１９年１０月５日、［平成１９年１０月１５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/36300.htm＞
本発明の目的の一つは、無線端末が異なる無線アクセス網にハンドオーバ（ＨＯ）する前後で所定のヘッダ圧縮又は伸張方式による処理を継続できるようにすることにある。
また、無線端末と無線アクセス網との間の無線区間のリソース利用効率の低下を抑制することも本発明の他の目的の一つである。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の一つとして位置付けることができる。
前記目的を達成するために、本明細書では、以下に示す「パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置」を開示する。
（１）即ち、ここに開示するパケット通信方法は、無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおけるパケット通信方法であって、前記無線端末が異なる無線アクセス網にハンドオーバする際に、前記管理装置により、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いる第１のヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定し、サポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信において、前記無線端末により少なくとも前記第１のヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記第１のヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置とする制御を、前記管理装置により行なうとともに、前記制御において、前記管理装置により、前記無線端末及び前記パケット通信装置に対して、前記実施ポイントを前記パケット通信装置とする情報を通知する。
（２）ここで、前記ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式とは異なる第２のヘッダ圧縮又は伸張方式をサポートしている場合において、前記無線端末により、前記第１のヘッダ圧縮方式で処理されたパケットを、前記第２のパケット通信において前記実施ポイントへトンネルするトンネルパケットにカプセル化することとしてもよい。
（３）また、前記無線端末により、前記トンネルパケットを、前記第２のヘッダ圧縮方式でヘッダ圧縮することとしてもよい。
（４）さらに、ここに開示するパケット通信システムは、無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムであって、前記管理装置は、前記無線端末が異なる無線アクセス網にハンドオーバする処理を制御する手段と、前記ハンドオーバの際に、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いるヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定する手段と、サポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信において、前記無線端末により少なくとも前記ヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記ヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置とする制御を行なう手段と、をそなえ、前記制御を行なう手段は、前記無線端末及び前記パケット通信装置に対して、前記実施ポイントを前記パケット通信装置とする情報を通知する。
（５）また、ここに開示する管理装置は、無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、をそなえたパケット通信システムにおける管理装置であって、前記無線端末が異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段と、前記ハンドオーバの際に、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いるヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定する判定手段と、前記判定手段がサポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信において、前記無線端末により少なくとも前記ヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記ヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置とする制御を行なう制御手段と、をそなえ、前記制御手段は、前記無線端末及び前記パケット通信装置に対して、前記実施ポイントを前記パケット通信装置とする情報を通知する。
（６）ここで、前記制御手段は、前記制御のための情報を、前記ハンドオーバの過程で送受される制御メッセージを利用して前記無線端末と前記パケット通信装置に通知する、こととしてもよい。
（７）また、ここに開示する無線端末は、無線端末と、第１の無線アクセス網と、第２の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおける前記無線端末であって、第１のヘッダ圧縮又は伸張方式を用いてパケット通信を行なうパケット通信手段と、異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段と、ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式をサポートしていない場合に前記管理装置が前記無線端末及び前記パケット通信装置に対して送信した情報であって、前記ハンドオーバ先無線アクセス網を介したパケット通信において、前記無線端末により少なくとも前記第１のヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記第１のヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置に指定する情報を受信する受信手段と、前記受信手段で受信した情報に基づいて、前記ハンドオーバ先無線アクセス網を介したパケット通信についての前記実施ポイントが前記パケット通信装置となるよう前記パケット通信手段を制御する制御手段と、をそなえる。
（８）ここで、前記ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式とは異なる第２のヘッダ圧縮又は伸張方式をサポートしている場合において、前記パケット通信手段は、前記第１のヘッダ圧縮方式で処理されたパケットを、前記第２のパケット通信において前記実施ポイントへトンネルするトンネルパケットにカプセル化する手段をそなえていてもよい。
（９）また、前記パケット通信手段は、前記トンネルパケットを、前記第２のヘッダ圧縮方式でヘッダ圧縮する手段をそなえていてもよい。
（１０）さらに、ここに開示するパケット通信装置は、無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおける前記パケット通信装置であって、第１のヘッダ圧縮又は伸張方式を用いてパケット通信を行なうパケット通信手段と、前記無線端末のハンドオーバ先無線アクセス網が前記ヘッダ圧縮又は伸張方式をサポートしていない場合に前記管理装置が前記無線端末及び前記パケット通信装置に対して送信した情報であって、前記ハンドオーバ先無線アクセス網を介したパケット通信において、前記無線端末により少なくとも前記第１のヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記第１のヘッダ伸張方式による伸張処理の実施ポイントを指定する情報を受信する受信手段と、前記受信手段で受信した情報に基づいて、前記ハンドオーバ先無線アクセス網を介したパケット通信についての前記実施ポイントが自装置となるよう前記パケット通信手段を制御する制御手段と、をそなえる。
前記開示技術によれば、無線端末がハンドオーバする前後で所定のヘッダ圧縮又は伸張方式による処理を適切に継続することが可能となる。
また、無線端末と無線アクセス網との間の無線区間のリソース利用効率の低下を抑制することも可能となる。
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも非限定的な例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形して実施することができる。
〔１〕概要
図１は、本発明の適用対象の一例であるＳＡＥアーキテクチャを示すブロック図である。この図１は、前記非特許文献１のFigure 4.2.1-1（Non-Roaming Architecture for 3GPP Accesses）に対応する図である。
この図１に示すように、ＳＡＥアーキテクチャは、例えば、無線端末としてのユーザ端末（ＵＥ）と、無線基地局としてのeNodeB（略して、ｅＮＢ）を含むE-UTRANと、ＳＧＳＮ〔Serving GPRS（General Packet Radio Service）Support Node〕と、ＨＳＳ（Home Subscriber Server）と、ＭＭＥ（Mobility Management Entity）と、Ｓ−ＧＷ（Serving Gateway）と、ＰＤＮ−ＧＷ（Packet Data Network Gateway）と、ＰＣＲＦ（Policy and Charging Rules Function）と、ＣＳＣＦ（Call Session Control Function）と、を具備するシステムとして定義される。
ＵＥは、無線インタフェースを具備し、ｅＮＢのサービスエリア内において当該ｅＮＢと無線リンクにより接続し、当該ｅＮＢを介して他のＵＥやサーバ装置等と通信する。無線リンクには、ＵＥからｅＮＢへの方向であるアップリンク（ＵＬ）と、その逆の方向であるダウンリンク（ＤＬ）とが含まれる。なお、ＵＥとしては、携帯電話やＰＤＡ、ノート型ＰＣ等が挙げられる。また、ＵＥは、有線インタフェースによりｅＮＢと接続する通信端末であってもよい。
ｅＮＢは、ＵＥとの間の無線インタフェースを終端するエンティティ（ノード）であり、ＵＥからの無線パケットの受信、ＵＥ宛の無線パケットの送信を行なう。なお、ｅＮＢは、UTRANやGERAN（Enhanced Data Rates for GSM Radio Access Network）、UMTS（Universal Mobile Telecommunications System）、GPRS（General Packet Radio Service）網その他の第３世代以前の無線アクセス網（以下、便宜上、既存網と総称することがある）の構成要素である、無線基地局（ＢＳ）とＲＮＣ（Radio Network Controller）の機能の一部と、を統合したエンティティに相当する。
ＨＳＳは、ユーザ名やＵＥの位置情報などのユーザ情報を一元管理するデータベースを具備するサーバである。
ＭＭＥ（管理装置）は、ＨＳＳと連携して、ＵＥの位置（モビリティ）を管理し、ベアラ管理、ＮＡＳ（Non-Access-Stratum）シグナリング等を行なうエンティティ（論理ノード）である。
ＳＧＳＮは、GPRS環境でUTRANやGERAN等の無線アクセス網（より詳細には、その構成要素であるＲＮＣ）と接続するために提供されるノードであり、ＭＭＥと連携してＵＥの位置を把握し、ＵＥに対するセキュリティ機能およびアクセス制御を提供する。
Ｓ−ＧＷ（パケット通信装置）は、E-UTRAN及びＳＧＳＮに対するインタフェースとなるエンティティであり、E-UTRANのｅＮＢとの間、および、ＳＧＳＮを介してUTRANやGERANのＲＮＣとの間でユーザパケットを送受信する。
ＰＤＮ−ＧＷは、ＰＤＮ（Packet Data Network）との間のインタフェースを終端する関門（ゲートウェイ）ノードである。ＰＤＮとしては、インターネットや、オペレータ内のネットワーク、プライベートパケットデータネットワーク、オペレータ間のパケットデータネットワーク（ＩＭＳ（IP Multimedia Subsystem）サービスやＰＳＳ（Packet-switched Streaming Service）提供用等）等が挙げられる。なお、ＰＤＮ−ＧＷは、Ｓ−ＧＷと統合されて単一のノードとして提供される場合もある。
ＰＣＲＦは、ＣＳＣＦ（Call Session Control Function）と呼ばれる、ＩＭＳでのセッション（ベアラ）を管理、制御するエンティティ（論理ノード）からの要求に応じて、ベアラのＱｏＳ（Quality of Service）等の各種ポリシや課金を管理、制御するエンティティ（論理ノード）である。ＣＳＣＦは、例えば、前記ＰＤＮの構成要素であるＩＭＳサーバ等のアプリケーションサーバの一機能として実現される。
なお、図１において、“LTE-Uu”、“S1-U”、“S1-MME”、“S3”、“S4”、“S5”、“S6a”、“S7”、“S11”、“S12”、“SGi”、“Rx+”等は、ノード（エンティティ）間（“S10”はＭＭＥ内）のインタフェース名を表す。
即ち、“LTE-Uu”は、ＵＥ１０とｅＮＢ２０との間のインタフェース名、“S1-U”は、ｅＮＢとＳ−ＧＷとの間のインタフェース名、“S1-MME”は、ｅＮＢとＭＭＥとの間のインタフェース名、“S3”は、ＭＭＥとＳＧＳＮとの間のインタフェース名、“S4”は、ＳＧＳＮとＳ−ＧＷとの間のインタフェース名を表す。
また、“S5”は、Ｓ−ＧＷとＰＤＮ−ＧＷとの間のインタフェース名、“S6a”は、ＭＭＥとＨＳＳとの間のインタフェース名、“S7”は、ＰＤＮ−ＧＷとＰＣＲＦとの間のインタフェース名、“S11”は、ＭＭＥとＳ−ＧＷとの間のインタフェース名、“S12”は、UTRANの構成要素との間のインタフェース名、“SGi”は、ＰＤＮ−ＧＷとＰＤＮ（ＣＳＣＦ）との間のインタフェース名、“Rx+”はＰＤＮ（ＣＳＣＦ）とＰＣＲＦとの間のインタフェース名を表す。
さて、このようなＳＡＥアーキテクチャにおいて、例えば、或る無線アクセス網（E-UTRAN）のｅＮＢ（無線アクセスポイント）に無線リンクにより接続して通信しているＵＥが、他の無線アクセス網であるUTRANやGERANのサービスエリアに移動して、そのサービスエリアを提供するUTRANやGERANの無線基地局（ＢＳ：Base Station）（無線アクセスポイント）に接続先を変更する場合、つまりハンドオーバ（Inter RAT handover）する場合を想定する。
この場合、ハンドオーバ前のアップリンク（ＵＬ）のユーザプレーン（U-plane）のデータ（つまりユーザパケット）の転送経路（パケットフロー）とハンドオーバ後のＵＬの転送経路（パケットフロー）とは、それぞれ、例えば図２に示すように表される。
即ち、ハンドオーバ前にＵＥ１０から送信されたＵＬのユーザパケットは、ｅＮＢ２０を経由してＳ−ＧＷ３０に転送され、当該Ｓ−ＧＷ３０からＰＤＮ−ＧＷ６０へ転送され、ハンドオーバ後にＵＥ１０から送信されたＵＬのユーザパケットは、ＲＮＣ４０、ＳＧＳＮ５０を経由してＳ−ＧＷ３０へ転送され、当該Ｓ−ＧＷ３０からＰＤＮ−ＧＷへ転送される。換言するならば、ハンドオーバ前のパケットフローとハンドオーバ後のパケットフローとは、Ｓ−ＧＷ３０において合流してＰＤＮ−ＧＷ６０に接続される。
なお、ＵＥ１０は、通常はＲＮＣ４０に直接接続することはなく、ＲＮＣ４０配下のＢＳを介して通信を行なうが、図２では、簡略化して、ＵＥ１０とＲＮＣ４０との間に介在するＢＳ（無線アクセスポイント）の図示を省略している。以下の説明においても、ＵＥ１０がＲＮＣ４０に直接接続するかのような表現を用いることがあるが、便宜上のものであり、ＢＳを介した接続を意味する。また、図２において、ＵＥ１０とｅＮＢ２０との間が無線区間であり、ＵＥ１０と前記ＢＳとの間（ＵＥ１０とＲＮＣ４０との間の一部の区間）が無線区間である。
無線区間では、リソースを有効に使うことが重要である。そのため、無線区間の通信（パケットフロー）については、ＲＯＨＣ（RObust Header Compression）と呼ばれるヘッダ圧縮技術により、無線パケットのヘッダを圧縮することが望ましい。ＲＯＨＣでは、ＰＤＣＰ（Packet Data Convergence Protocol）パケットのペイロードに収容されるユーザデータのヘッダを動的に圧縮する。
例えば、ユーザデータがＶｏＩＰ通信等のＲＴＰ（Real Time Protocol）パケットの場合であれば、IPv6ヘッダ、ＵＤＰ（User Datagram Protocol）ヘッダ、ＲＴＰヘッダが圧縮対象となる。圧縮されたヘッダはＲＯＨＣヘッダとしてＲＴＰペイロードの先頭に付加される。
ところで、前記のようなハンドオーバ前後でパケット転送経路が異なることとなる通信において、両経路のパケットフローに関して同等のＲＯＨＣのプロトコルがそれぞれの経路上に位置するエンティティ（ｅＮＢ２０やＲＮＣ４０、ＳＧＳＮ５０）でサポートされてない場合（同一の圧縮技術が継続できない場合）には、ハンドオーバ前後でＵＥは適切な通信を継続することができなくなることがある。その場合、ヘッダ圧縮による無線区間のリソース利用効率が低下することがある。
例えば、ハンドオーバ（ＨＯ）元の無線アクセス網（ＴＡ：Tracking Area）であるE-UTRANのエンティティ（ｅＮＢ２０）では第１のヘッダ圧縮又は伸張方式としてＲＴＰプロファイルでＩＰヘッダがIPv6パケットのＲＯＨＣ（以下、ＲＯＨＣ（IPv6/RTP）と表記する）をサポートしているが、ＨＯ先の無線アクセス網であるUTRANやGERANのエンティティ（ＲＮＣ４０）では、ＲＯＨＣ（IPv6/RTP）をサポートしておらず、第２のヘッダ圧縮又は伸張方式としてＲＴＰプロファイルでＩＰヘッダがIPv4のＲＯＨＣ（以下、ＲＯＨＣ（IPv4/RTP）と表記する）はサポートしている環境を想定する。また、ＵＥ１０は、少なくともIPv6による通信機能をサポートしているものと仮定する。これらのサポート状況に関する情報は、後述するようにＭＭＥ７０にて保持、管理される。
この場合、ＵＥ１０は、E-UTRANのサービスエリアに位置しているときはIPv6によりｅＮＢ２０を介してパケット通信を行なう。その際、ＵＥ１０は、無線区間（無線リンク）のリソース利用効率向上のために、IPv6パケットについてＲＯＨＣ（IPv6/RTP）によるヘッダ圧縮を実施する。
このようにヘッダ圧縮されたパケット（以下、圧縮パケットともいう）が、ｅＮＢ２０で受信されると、ｅＮＢ２０は、前記ＲＯＨＣ（IPv6/RTP）に対応するヘッダ伸張処理を実施してIPv6パケットを復元する。復元されたIPv6パケットは、Ｓ−ＧＷ３０及びＰＤＮ−ＧＷへのインタフェース（S1-U及びS5）を転送するのに必要なヘッダがｅＮＢ２０において付加されて、Ｓ−ＧＷ３０を経由してＰＤＮ−ＧＷ６０へ転送される。
一方、ＨＯ後も、ＵＥ１０は、無線区間のリソース利用効率向上のために、ＵＬのIPv6パケットについてＲＯＨＣ（IPv6/RTP）のヘッダ圧縮を継続して行なうことが望ましい。しかし、ＨＯ先ＴＡのＲＮＣ４０がＲＯＨＣ（IPv6/RTP）をサポートしていない場合、ＲＮＣ４０は、ＵＥ１０から圧縮パケットを受信しても、ＲＯＨＣ（IPv6/RTP）ヘッダの伸張処理を正しく実施することができず、Ｓ−ＧＷ３０へ転送されるべきIPv6パケットを復元することができない。結果として、ＵＥ１０はＨＯ後に正常な通信を維持することができなくなる。
この回避策として、例えば、ＵＥ１０は、ＲＯＨＣ（IPv6/RTP）のヘッダ圧縮を行なわずにパケット送信を行なうことが一つの方法として考えられるが、無線区間のリソース利用効率が低下する。
そこで、本例では、ＨＯ後のＵＬの圧縮パケットについては、前記ＨＯ前後のパケットフローの双方を処理するノードであるＳ−ＧＷ３０において、ＲＯＨＣ（IPv6/RTP）のヘッダ伸張ポイント（ノード）をＳ−ＧＷ３０に設定することとし、Ｓ−ＧＷ３０に至るまでのパケット転送経路をトンネル転送できるようにする。
例えば、ＨＯ時に、ＭＭＥ７０を起点としてＵＥ１０とＳ−ＧＷ３０とに対して、ＵＬのＲＯＨＣ（IPv6/RTP）のヘッダ伸張ポイント（ノード）がＳ−ＧＷ３０になることを通知する。その際、少なくともＲＯＨＣ処理関連のパラメータ（以下、ＲＯＨＣパラメータという）を通知する。ＵＥ１０に対しては、前記ヘッダ伸張ポイントへのトンネルに関する情報（トンネル開始指示、Ｓ−ＧＷ３０のアドレス情報等）もＭＭＥ７０から通知する。
これらの通知は、ＭＭＥ７０からＵＥ１０及びＳ−ＧＷ３０に対して直接的に行なってもよいし、他のエンティティ経由で間接的に行なってもよい。間接的に行なう場合、当該通知は、例えば図５により後述するように、ＨＯプロシージャの過程で、ｅＮＢ２０とＭＭＥ７０との間、ＭＭＥ７０とＳＧＳＮ５０との間、および、ＳＧＳＮ５０とＳ−ＧＷ３０との間でＨＯ処理の過程で送受される制御メッセージを用いて、ＵＥ１０に対しては、ＳＧＳＮ５０及びＲＮＣ４０を経由して、Ｓ−ＧＷ３０に対しては、ＳＧＳＮ５０を経由して実施することができる。
前記通知（ＲＯＨＣパラメータ）を受けたＵＥ１０は、ＨＯ先ＴＡにおいて、IPv6パケットヘッダをＲＯＨＣ（IPv6/RTP）により圧縮し、その圧縮パケットを、宛先（トンネル先）をＳ−ＧＷ３０とする下位層（ＩＰ等）のパケットに必要に応じてカプセル化（前記圧縮パケットをペイロードとして下位層のプロトコル（ＩＰ等）のヘッダを付加）する。つまり、ＲＯＨＣ（IPv6/RTP）のヘッダ伸張ポイントを宛先とするトンネルパケットに変換する。そして、このトンネルパケットのヘッダを必要に応じてさらにＲＯＨＣ（IPv4/RTP）により圧縮して、ＲＮＣ４０へ送信する。
ＲＯＨＣ（IPv4/RTP）はサポートするがＲＯＨＣ（IPv6/RTP）はサポートしていない（ヘッダ圧縮されたIPv6パケットを伸張できない）ＲＮＣ４０では、ＵＥ１０から受信したパケットがトンネルパケットにカプセル化されているから、当該トンネルパケットのＲＯＨＣヘッダを必要に応じてＲＯＨＣ（IPv4/RTP）によりヘッダ伸張して圧縮前のヘッダを復元し、そのヘッダが表示する宛先（Ｓ−ＧＷ３０）へ転送（トンネル）することが可能となる。Ｓ−ＧＷ３０では、前記カプセル化されたトンネルパケットをデカプセル化してＲＯＨＣ（IPv6/RTP）パケットを取り出し、当該ＲＯＨＣパケットのヘッダをＲＯＨＣ（IPv6/RTP）処理により伸張して復元する。
このように、ＲＯＨＣ（IPv6/RTP）で圧縮したパケットをさらにＩＰ等の下位層のパケットにカプセル化してトンネルするケースとしては、例えば、ＨＯ先ＴＡのエンティティ（ＲＮＣ４０、ＳＧＳＮ５０）が受信ユーザパケットのペイロードとして下位層（ＩＰ等）のパケットを想定している場合や、ＵＥ１０とＳ−ＧＷ３０との間で必要なＲＯＨＣのネゴシエーション（ＲＯＨＣではＲＯＨＣパラメータのネゴシエーションが必要なときは下位層で行なうこととされている）を行なうために下位層のパケットを用いる場合が想定される。
したがって、ＨＯ先ＴＡのエンティティがユーザパケットとして下位層（ＩＰ等）のパケットを要求せず（Ｓ−ＧＷ３０）へ送るＲＯＨＣパケットをそのまま送っても構わない場合）で、かつ、ＵＥ１０とＳ−ＧＷ３０との間でＲＯＨＣ開始時のネゴシエーションが不要な場合には、下位層のパケットでのトンネルは不要となる。なお、ＩＰ等のパケットの代わりにＰＤＣＰパケットにカプセル化することも可能である。その場合、ｅＮＢ２０が受信したＰＤＣＰパケットのペイロードがＳ−ＧＷ３０でＲＯＨＣ終端される対象となる）。
また、ＲＮＣ４０が、ＲＯＨＣ機能自体をサポートしていない、あるいは、ＲＯＨＣ（IPv4/RTP）機能はサポートしているが無効（ＯＦＦ）に設定可能でＯＦＦに設定されている場合にも、ＵＥ１０は、ＲＯＨＣ（IPv6/RTP）でヘッダ圧縮したＲＯＨＣ（IPv6/RTP）パケットをIPv4パケットにカプセル化する必要はない。
ＲＮＣ４０がＲＯＨＣ（IPv6/RTP）をサポートしている場合は、例えば図３に示すように、ＨＯ前のパケット転送経路（ｅＮＢ２０）と同様に、ＵＥ１０が送信したIPv6の圧縮パケットをＲＮＣ４０にてヘッダ伸張してヘッダ圧縮前のパケットを復元し、ＳＧＳＮ５０経由でＳ−ＧＷ３０へ転送することができる。したがって、ＭＭＥ７０からの前記指示は必要ない。
なお、以上の処理はＵＬのパケットフローに関する処理であるが、ＤＬのパケットフローに関しては、基本的に、上述した処理とは逆の処理を行なう。即ち、上述した処理において、ＵＥ１０をＳ−ＧＷ３０に、Ｓ−ＧＷ３０をＵＥ１０に読み替えた処理を実施する。つまり、Ｓ−ＧＷ３０からＵＥ１０へのＤＬのパケットフローに関してはＲＯＨＣ（IPv6/RTP）のヘッダ圧縮（伸張）ポイントがＳ−ＧＷ３０（ＵＥ１０）となり、前記カプセル化はＳ−ＧＷ３０において行なわれ、前記デカプセル化はＵＥ１０にて行なわれることとなる。
したがって、ＵＬ及びＤＬの双方を考慮すれば、ＭＭＥ７０は、ＨＯ後のＵＬのパケットフローについてのＲＯＨＣ（IPv6/RTP）のヘッダ伸張ポイントと、ＨＯ後のＤＬのパケットフローについてのＲＯＨＣ（IPv6/RTP）のヘッダ圧縮ポイントと、をそれぞれＳ−ＧＷ３０に設定することとなる。
また、図４（Ａ）に、ＵＥ１０とｅＮＢ２０との間（UMTSの場合も同様）のユーザプレーンで用いられるプロトコルスタックの一例を示し、図４（Ｂ）に、ｅＮＢ２０とＳ−ＧＷ３０との間（ＳＧＳＮ５０とＳ−ＧＷ３０との間も同様）のユーザプレーンで用いられるプロトコルスタックの一例を示す。図４（Ａ）は前記非特許文献２のFigure 4.3.1に相当し、図４（Ｂ）は同文献２のFigure 19.1に相当する。
前記のカプセル化（トンネル転送）をＩＰベースで行なう場合は、図４（Ａ）に示すＰＤＣＰレイヤのパケットのペイロード、図４（Ｂ）に示すＧＴＰ−Ｕレイヤのパケットのペイロードとして、それぞれＩＰパケットを格納し、そのＩＰパケットのペイロードにＰＤＣＰレイヤに属するＲＯＨＣパケットを格納する。なお、ＧＴＰは、ＧＰＲＳ（General Packet Radio Service）トンネリングプロトコルの略称であり、ＧＴＰ−Ｕはユーザプレーン（U-plane）のデータ転送（トンネル）に用いられるＧＴＰであることを意味する。
このようにすることで、ＳＧＳＮ５０、ｅＮＢ２０、ＲＮＣ４０では、下位層のパケットのペイロードに格納されるデータ内容に依存せずに、下位層のプロトコルベースで適切なパケット処理を実施することができ、特別な機能変更を不要にすることができる。
なお、図２０に、図２に示すＨＯ前のＵＬのパケット転送経路におけるパケットフォーマットの一例を示し、図２１に、図２に示すＨＯ後のＵＥ１０がＲＯＨＣ（IPv6/RTP）パケットを下位層のパケットにカプセル化しない場合のＵＬのパケット転送経路におけるパケットフォーマットの一例を示し、図２２に、図２に示すＨＯ後のＵＥ１０がＲＯＨＣ（IPv6/RTP）パケットを下位層のパケットにカプセル化する場合のＵＬのパケット転送経路におけるパケットフォーマットの一例を示す。
図２０に示す例においては、ＨＯ前のＵＥ１０は、ユーザデータパケットがＶｏＩＰ通信等のＲＴＰパケットであると仮定して、ＲＴＰペイロードにユーザデータを格納し、このＲＴＰペイロードに、IPv6ヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダ（以下、RTP/UDP/IPv6ヘッダと略記することがある）を付加してＰＤＣＰペイロードに格納されるIPv6パケットを生成し、このIPv6パケットのRTP/UDP/IPv6ヘッダをＲＯＨＣ（IPv6/RTP）のヘッダ圧縮により圧縮してＲＯＨＣ（IPv6/RTP）ヘッダとする。
そして、このＲＯＨＣヘッダとＲＴＰペイロードとから成るＲＯＨＣパケットに、ＰＤＣＰヘッダが付加されてＰＤＣＰパケットとなり、さらにＲＬＣ（Radio Link Control）ヘッダが付加されてＲＬＣパケットとなり（符号１００参照）、これがＵＬパケットとしてｅＮＢ２０へ送信される。
ｅＮＢ２０では、当該ＲＬＣパケットを受信すると、ＲＬＣヘッダを終端してＲＬＣペイロードを抽出し、このＲＬＣペイロードに含まれるＰＤＣＰパケットのＰＤＣＰヘッダを終端してＲＯＨＣ（IPv6/RTP）パケットを抽出する。
そして、ＲＯＨＣ（IPv6/RTP）ヘッダをＲＯＨＣ（IPv6/RTP）によりヘッダ伸長してIPv6ヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを復元することによりIPv6パケットを復元し、これにＰＤＮ−ＧＷ６０への転送に必要な下位層のプロトコルのヘッダ（ＧＴＰ−Ｕヘッダ、ＵＤＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、Ｌ２ヘッダ）を付加（符号２００参照）してＳ−ＧＷ３０へ転送する。ここで、ＧＴＰ−Ｕヘッダを付加することは、ＰＤＣＰペイロード（ＲＯＨＣパケット）をＰＤＮ−ＧＷ６０へのＧＴＰ−Ｕ接続に乗せ換えることを意味する。なお、Ｌ２ヘッダは、レイヤ２（データリンク層）のヘッダである。
Ｓ−ＧＷ３０は、ｅＮＢ２０から転送されてきた前記パケットのヘッダ情報を解析して転送先（ＰＤＮ−ＧＷ６０）を特定し、当該受信パケットをＰＤＮ−ＧＷ６０へ転送する（符号３００参照）。
一方、図２１に示す例においては、ＨＯ後のＵＥ１０は、ＨＯ前と同様にしてＰＤＣＰパケット（符号１００参照）を生成し、これをＵＬパケットとしてそのまま（カプセル化せずに）ＲＮＣ４０へ送信する。
ＲＮＣ４０では、ＵＥ１０から受信したＲＬＣパケットのＲＬＣヘッダを終端してＲＬＣペイロードを抽出し、このＲＬＣペイロードに含まれるＰＤＣＰパケットのＰＤＣＰヘッダを終端してＲＯＨＣ（IPv6/RTP）パケットを抽出する。
そして、抽出したＲＯＨＣ（IPv6/RTP）パケットに、Ｓ−ＧＷ３０への転送に必要な下位層のプロトコルのヘッダ（ＧＴＰ−Ｕヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、Ｌ２ヘッダ）を付加して（符号２００参照）ＳＧＳＮ５０へ転送する。つまり、ＰＤＣＰペイロード（ＲＯＨＣパケット）をＳ−ＧＷ３０へのＧＴＰ−Ｕ接続に乗せ換える。
ＳＧＳＮ５０は、ＲＮＣ４０から転送されてきた前記パケットのヘッダ情報を解析して転送先（Ｓ−ＧＷ３０）を特定し、当該受信パケットをＳ−ＧＷ３０へ転送する（符号３００参照）。
Ｓ−ＧＷ３０は、ＳＧＳＮ５０から受信した前記パケットのペイロードに含まれるＲＯＨＣ（IPv6/RTP）パケットのヘッダをＲＯＨＣ（IPv6/RTP）によりヘッダ伸長してIPv6パケットのRTP/UDP/IPv6ヘッダを復元し、ＰＤＮ−ＧＷ６０へ転送する（符号４００参照）。
これに対し、図２２に示す例においては、ＨＯ後のＵＥ１０は、ＲＯＨＣ（IPv6/RTP）によりヘッダ圧縮したＲＯＨＣパケットをＰＤＣＰペイロードに含むＰＤＣＰパケットを生成し、これを、宛先（トンネル先）をＳ−ＧＷ３０とする下位層（例えばIPv4）のパケットにカプセル化し、当該パケットのヘッダ（IPv4ヘッダ）をＲＯＨＣ（IPV4/RTP）によりヘッダ圧縮してＲＯＨＣ（IPv4/RTP）ヘッダとする。
このＲＯＨＣ（IPv4/RTP）ヘッダとＰＤＣＰパケット（IPv4ペイロード）とから成るＲＯＨＣ（IPv4/RTP）パケットに、ＰＤＣＰヘッダが付加されてＰＤＣＰパケットとなり、さらにＲＬＣヘッダが付加されてＲＬＣパケットとなり（符号１００参照）、これがＵＬパケットとしてＲＮＣ４０へ送信される。
ＲＮＣ４０は、ＵＥ１０から当該ＲＬＣパケットを受信すると、ＲＬＣヘッダを終端してＲＬＣペイロードを抽出し、このＲＬＣペイロードに含まれるＰＤＣＰパケットのＰＤＣＰヘッダを終端してＰＤＣＰペイロード、つまり、ＲＯＨＣ（IPv4/RTP）パケットを抽出する。
そして、抽出したＲＯＨＣ（IPv4/RTP）パケットのＲＯＨＣ（IPv4/RTP）ヘッダをＲＯＨＣ（IPv4/RTP）により伸長してIPv4ヘッダを復元することによりIPv4パケットを生成し、当該IPv4パケットに、Ｓ−ＧＷ３０への転送に必要な下位層のプロトコルのヘッダ（ＧＴＰ−Ｕヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、Ｌ２ヘッダ）を付加して（符号２００参照）ＳＧＳＮ５０へ転送する。つまり、ＰＤＣＰペイロードに含まれていたＲＯＣＨ（IPv4/RTP）パケットをIPv4パケットに復元した上でＳ−ＧＷ３０へのＧＴＰ−Ｕ接続に乗せ換える。
ＳＧＳＮ５０は、ＲＮＣ４０から転送されてきた前記パケットのヘッダ情報を解析して転送先（Ｓ−ＧＷ３０）を特定し、当該受信パケットをＳ−ＧＷ３０へ転送する（符号３００参照）。
Ｓ−ＧＷ３０は、ＳＧＳＮ５０から受信した前記パケットのペイロードに含まれるIPv4パケットのヘッダを終端（ＩＰ接続を終端）し、さらに、ＰＤＣＰヘッダを終端し、ＰＤＣＰペイロードに含まれるＲＯＨＣ（IPv6/RTP）ヘッダをＲＯＨＣ（IPv6/RTP）により伸長してIPv6パケットのヘッダ（IPv6ヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダ）を復元し、ＰＤＮ−ＧＷ６０へ転送する（符号４００参照）。
なお、ＤＬについては、図２０、図２１、図２２に示す順序とはそれぞれ逆順の処理となり、ＵＬについての処理において、ヘッダ付加はヘッダ除去、ヘッダ終端（除去）はヘッダ付加、ヘッダ伸長はヘッダ圧縮など、それぞれ適宜読み替えた処理に相当する。
次に、ＵＥ１０のＨＯ時にＭＭＥ７０を起点としてＵＥ１０とＳ−ＧＷ３０とに対して前記ＲＯＨＣパラメータを通知する手法について説明する。この通知には、例えば、図５に示す、ＵＥ１０がE-UTRANのｅＮＢ２０から既存網のＲＮＣ４０にＨＯする際のプロシージャの過程で用いられるメッセージを利用することができる。
なお、この図５は、前記非特許文献１のFigure 5.5.2.1-1（E-UTRAN to UTRAN Iu mode Inter RAT HO, preparation phase）及びFigure 5.5.2.1-2（E-UTRAN to UTRAN Iu mode Inter RAT HO, execution phase）を統合、簡略化した図に相当する。例えば、パケットフォワーディング経路確立や位置登録に関するプロシージャについては省略している。
この図５に示すＨＯプロシージャにおいて、例えば、ＭＭＥ７０からｅＮＢ２０へ送信されるリロケーションコマンド（Relocation Command）メッセージ（ステップＳ７）及びｅＮＢ２０からＵＥ１０へ送信されるＨＯコマンド（ＨＯ command）メッセージ（ステップＳ８）をＵＥ１０に対する前記ＲＯＨＣパラメータ通知に用いることができる。
一方、Ｓ−ＧＷ３０に対する前記ＲＯＨＣパラメータ通知には、ＭＭＥ７０からＳＧＳＮ５０へ送信されるフォワードリロケーション完了応答（Forward Relocation Complete Acknowledge）メッセージ（ステップＳ１３）及びＳＧＳＮ５０からＳ−ＧＷ３０へ送信されるベアラ更新要求（Update Bearer Request）メッセージ（ステップＳ１４）を用いることができる。
即ち、ｅＮＢ２０は、ＵＥ１０からの電波受信強度に基づいて他の無線基地局（ここでは、ＲＮＣ４０）へのＨＯが必要と判断してＨＯ処理の起動を決定すると（ステップＳ１）、ＭＭＥ７０宛にリロケーション要求（Relocation Required）メッセージを発行する（ステップＳ２）。
したがって、ＭＭＥ７０は、このリロケーション要求メッセージを受信することにより、ＵＥ１０のＨＯ先ＴＡ（ＲＮＣ４０）を認識し、そのＨＯ先ＴＡでＲＯＨＣ処理の継続が可能か否かを判断することができる。ただし、ＭＭＥ７０は、ＵＥ１０が移動に伴ってＨＯしうるＨＯ先ＴＡのエンティティでのＲＯＨＣのサポート状況に関する情報を予め保持している。
ＲＯＨＣ処理の継続が不可能（ＲＮＣ４０がＲＯＨＣ（IPv6/RTP）をサポートしていない）と判断した場合、ＭＭＥ７０は、ＨＯ先ＴＡのエンティティ（ＲＮＣ４０）との間でＨＯの準備のための必要なネゴシエーションを行ない（ステップＳ３〜Ｓ６）、ＨＯの準備が整うと、リロケーションコマンド（Relocation Command）メッセージをＵＥ１０のＨＯ元ＴＡのエンティティ（ｅＮＢ２０）宛に送信する（ステップＳ７）。ＭＭＥ７０は、このリロケーションコマンドメッセージに前記ＲＯＨＣパラメータを含めて送信する。
当該リロケーションコマンドメッセージを受信したｅＮＢ２０は、ＨＯの実行を命令するＨＯコマンド（HO command）メッセージをＵＥ１０に送信する（ステップＳ８）。ｅＮＢ２０は、このメッセージに、受信したリロケーションコマンドメッセージに設定されていた前記ＲＯＨＣパラメータを含める。
前記ＨＯコマンドメッセージを受信したＵＥ１０は、ＨＯ先ＴＡへのアクセスプロシージャ（下位層のプロシージャ）を開始し（ステップＳ９）、ＨＯが完了すると、その旨を示すＨＯ完了（HO complete）メッセージをＨＯ先アクセス網（ＲＮＣ４０）に送信する（ステップＳ１０）。
このＨＯ完了メッセージを受信したＲＮＣ４０は、ＳＧＳＮ５０宛にフォワードリロケーション完了（Forward Relocation Complete）メッセージを送信し（ステップＳ１１）、当該メッセージを受信したＳＧＳＮ５０は、ＭＭＥ７０宛にフォワードリロケーション完了メッセージを送信（転送）してＨＯの完了をＭＭＥ７０に通知する（ステップＳ１２）。
ＭＭＥ７０は、受信した前記フォワードリロケーション完了メッセージに対する応答（Forward Relocation Complete Acknowledge）メッセージをＳＧＳＮ５０宛に送信する（ステップＳ１４）。ＭＭＥ７０は、この応答メッセージに、前記ＲＯＨＣパラメータを含める。
ＳＧＳＮ５０は、前記応答メッセージを受信すると、Ｓ−ＧＷ３０宛にＵＥ１０との間のベアラ設定の更新を要求するベアラ更新要求（Update Bearer Request）メッセージを送信する。ＳＧＳＮ５０は、このメッセージに、ＭＭＥ７０から受信した前記応答メッセージに設定されていた前記ＲＯＨＣパラメータを含める。これにより、当該ＲＯＨＣパラメータがＳ−ＧＷ３０に通知される。
Ｓ−ＧＷ３０は、前記ベアラ更新要求メッセージを受信し、ＵＥ１０との間のベアラ設定の更新を行なうと、ベアラ更新応答（Update Bearer Response）メッセージを要求元のＳＧＳＮ５０宛に送信する（ステップＳ１５）。なお、ベアラ設定の更新により、ＭＭＥ７０は、ＨＯ元ＴＡのｅＮＢ２０に対して割り当てていたリソースの解放処理を実施する（ステップＳ１６）。
また、図５には図示を省略しているが、ＨＯプロシージャの過程で、前記ステップＳ１４よりももっと早い段階で、ＳＧＳＮ５０からＳ−ＧＷ３０へメッセージが送信される場合がある。その場合には、当該メッセージを前記ＲＯＨＣパラメータの通知に用いてもよい。
例えば、ＨＯ中にパケットデータをフォワーディングするための直接の転送経路がｅＮＢ間に存在しないときには、Ｓ−ＧＷ３０経由のフォワーディング経路を作るためのメッセージ（Create Bearer Requestメッセージ）がＳＧＳＮ５０からＳ−ＧＷ３０へ送信される。このCreate Bearer Requestメッセージに、前記ＲＯＨＣパラメータを含めることとしてもよい。
〔２〕具体例
以下、上述した動作を実現する、ＭＭＥ７０、ＵＥ２０、Ｓ−ＧＷ３０の構成（機能）及び動作について説明する。なお、他のエンティティ（ｅＮＢ２０、ＲＮＣ４０、ＳＧＳＮ５０、ＰＤＮ−ＧＷ６０）については、特別な変更を要しないので、説明を省略する。
（２．１）ＭＭＥについて
図６は一実施形態に係るＭＭＥの構成を示すブロック図である。この図６に示すＭＭＥ（管理装置）７０は、シグナル処理部７１と、ＵＥ機能サポート情報記憶部７２と、ＴＡ機能サポート情報記憶部７３と、下位層処理部７４とをそなえる。
ＵＥ機能サポート情報記憶部７２は、ＵＥ１０がサポートする機能（ＲＯＨＣ（IPv6/RTP）／ＲＯＨＣ（IPv4/RTP）処理機能、ＲＯＨＣ（IPv6/RTP）によるヘッダ圧縮パケットをIPv4パケットにカプセル化する機能など）に関する情報（ＵＥ機能サポート状況情報）を記憶、管理するものである。このサポート状況に関する情報は、少なくともＵＥ１０がＨＯを実施するよりも前の段階で入手、登録しておく。例えば、ＵＥ１０が電源投入後にネットワークに接続する（アタッチする）時の位置登録関連のメッセージを用いて、前記ＵＥ機能サポート状況情報をＭＭＥ７０に通知することが可能である。
ＴＡ機能サポート情報記憶部７３は、ＵＥ１０がＨＯしうる無線アクセス網（ＴＡ）単位で、少なくともそのＴＡでサポートするＲＯＨＣ（IPv6/RTP）／ＲＯＨＣ（IPv4/RTP）に関する情報を含む、サポート状況情報（ＴＡ機能サポート状況情報）を記憶、管理するものである。このＴＡ機能サポート状況情報は、例えば網構築時に登録しておくのが好ましい。
なお、このようにＴＡ単位でサポート状況情報を記憶、管理するのは、ＵＥ１０の位置登録がＴＡ間をまたいで移動する時に行なわれることを前提としているからである。したがって、サポート状況情報を記憶、管理する単位は、ＵＥ１０の位置登録の方法（タイミング）に応じて適宜に変更してよい。
シグナル処理部７１は、制御プレーン（C-plane）で送受される制御メッセージの生成、転送を行なう機能を具備する。制御メッセージには、図５により前述したＨＯプロセスの過程で用いるリロケーション関連のメッセージが含まれる。つまり、シグナル処理部７１は、ＵＥ１０が異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段としての機能を具備する。
本例では、このシグナル処理部７１において、既述のように、リロケーションコマンドメッセージにＵＥ１０に通知すべきＲＯＨＣ（IPv6/RTP）処理（ヘッダ伸張／圧縮）の実施ポイントの設定情報（ＲＯＨＣパラメータ等）を含め、ベアラ更新要求メッセージにＳ−ＧＷ３０に通知すべきＲＯＨＣ（IPv6/RTP）実施ポイントの設定情報（ＲＯＨＣパラメータ等）が含められる。
また、本例のシグナル処理部７１は、下位層処理部７４を通じて前記リロケーション要求メッセージを受信すると（図５のステップＳ２参照）、そのメッセージ内容と、前記ＵＥ機能サポート状況情報と、前記ＴＡ機能サポート状況情報とに基づいて、ＲＯＨＣ（IPv6/RTP）処理の継続可否、ＲＯＨＣ（IPv6/RTP）の実施ポイント変更の可否を判断する機能も具備し、可能な場合に、前記リロケーションコマンドメッセージ、ベアラ更新要求メッセージを生成する。
下位層処理部７４は、既述の“S1-MME”、“S3”等のインタフェースを具備し、当該インタフェースを通じてｅＮＢ２０やＳＧＳＮ５０との間で送受信される制御メッセージ（パケット）に関して、シグナル処理部７１で扱うメッセージのレイヤよりも下位のレイヤでの処理（メッセージパケットの組立、分解、送受信等の処理）を実施するものである。
以下、上述のごとく構成されたＭＭＥ７０の動作（ＭＭＥ７０がＨＯ先ＴＡで用いるパケットフォーマットを決定する処理）について、図７に示すフローチャートを用いて説明する。
ＭＭＥ７０（シグナル処理部７１）は、ＨＯ元ＴＡのｅＮＢ２０から前記リロケーション要求メッセージを受信すると（図５のステップＳ２）、そのメッセージ内容からＨＯするＵＥ１０とＨＯ先ＴＡとを特定し、ＴＡ機能サポート情報記憶部７３の記憶情報（ＴＡ機能サポート状況情報）を参照して、ＨＯ先ＴＡで、ＵＥ１０がＨＯ前の通信で使用していたＲＯＨＣ（IPv6/RTP）処理と同じＲＯＨＣ（IPv6/RTP）処理を引き続き実施できるか、つまり、ＨＯ先ＴＡがＲＯＨＣ（IPv6/RTP）サポートしているか否かを判断する（ステップＳ２１）。
つまり、シグナル処理部７１は、ＨＯの際に、ＨＯ元ＴＡを介したパケット通信に用いるＲＯＨＣ（IPv6/RTP）をハンドオーバ先ＴＡがサポートしているか否かを判定する判定手段として機能する。
その結果、ＨＯ先ＴＡがＲＯＨＣ（IPv6/RTP）をサポートしていれば、シグナル処理部７１は、そのまま処理を終了する（ステップＳ２１のＹＥＳルート）。この場合、ＵＥ１０は、ＨＯ後もＵＬの送信パケットをＲＯＨＣ（IPv6/RTP）でヘッダ圧縮した上で送信を行なう。これにより、圧縮パケットは、例えば図３に示したように、ＨＯ先ＴＡのＲＮＣ４０でヘッダ伸張された上で、ＳＧＳＮ５０経由でＳ−ＧＷ３０に転送されることになる。
一方、ＨＯ先ＴＡがＲＯＨＣ（IPv6/RTP）をサポートしていなければ、シグナル処理部７１は、ＵＥ機能サポート情報記憶部７２のＵＥ機能サポート状況情報を基に、前記特定したＵＥ１０が既述のようにＲＯＨＣ（IPv6/RTP）の圧縮パケットを下位層のパケットにカプセル化してＳ−ＧＷ３０へトンネルする機能（以下、トンネリング機能という）をサポートしているか否かを判断する（ステップＳ２１のＹＥＳルートからステップＳ２２）。
その結果、ＵＥ１０が前記トンネリング機能をサポートしていなければ、シグナル処理部７１は、処理を終了するが（ステップＳ２２のＮＯルート）、サポートしていれば、さらに、トンネリング機能に関して下位層のプロトコル（ＩＰ，ＧＴＰ等）の処理が必要か否かを判定する（ステップＳ２２のＹＥＳルートからステップＳ２３）。
即ち、ＨＯ先ＴＡのエンティティ（ＲＮＣ４０、ＧＳＮ５０）が受信ユーザパケットのペイロードとしてＩＰ等のパケットを想定している場合や、ＵＥ１０とＳ−ＧＷ３０との間で必要なＲＯＨＣのネゴシエーションを行なうためにＩＰ等のパケットを用いる場合には、下位層のプロトコル（ＩＰ等）の処理が必要になる。
必要な場合（ステップＳ２３でＹＥＳの場合）には、シグナル処理部７１は、ＵＥ１０に通知すべき情報として、下位層のプロトコル処理も含めてＲＯＨＣ処理の変更を指示する情報（前記ＲＯＨＣパラメータ、トンネル開始指示、トンネル先アドレス等を含む）を生成し、これを前記リロケーションコマンドメッセージに含める。これにより、当該変更指示に関する情報は、前記ＨＯコマンドにてＵＥ１０に通知されることとなり、この通知を受けたＵＥ１０は、ＲＯＨＣ処理を初期化し、トンネリング機能による処理を実施する（ステップＳ２４）。
また、シグナル処理部７１は、Ｓ−ＧＷ３０に通知すべき情報として、下位層のプロトコル処理も含めてＲＯＨＣ処理の変更を指示する情報（前記ＲＯＨＣパラメータ等を含む）を生成し、これを前記ベアラ更新要求メッセージに含める。これにより、当該変更指示に関する情報がベアラ変更要求メッセージにてＳ−ＧＷ３０に通知され（ステップＳ２５）、Ｓ−ＧＷ３０は、ＨＯ後のＵＥ１０からのＵＬのパケットについてＲＯＨＣ（IPv6/RTP）のヘッダ伸張を行なうノードが自ノードに設定されたことを認識する。なお、これらのステップＳ２４及びＳ２５の処理順序は不問であり、並行して実施してもよい。
一方、トンネリング機能に関して下位層のプロトコル（ＩＰ，ＧＴＰ等）の処理が不要であれば（ステップＳ２３でＮＯなら）、シグナル処理部７１は、ＵＥ１０に通知すべき情報として、ＲＯＨＣのリセットを指示する情報を生成し、これを前記リロケーションコマンドメッセージに含める。これにより、当該情報は、前記ＨＯコマンドにてＵＥ１０に通知されることとなり、この通知を受けたＵＥ１０は、ＲＯＨＣ処理を初期化する（ステップＳ２６）。
このように、ＵＥ１０でのＲＯＨＣ処理を初期化するのは、ＨＯ先ＴＡにＲＯＨＣコンテキスト（フローのＲＯＨＣパラメータ）がフォワードされない場合にＲＯＨＣ処理を初期化する必要があるからである。また、ＲＯＨＣパラメータ（サポートしている機能等）のネゴシエーションをＨＯ先ＴＡでの通信開始前に行なう必要があるためでもある。
また、シグナル処理部７１は、Ｓ−ＧＷ３０に通知すべき情報として、ＲＯＨＣ処理の変更を指示する情報（前記ＲＯＨＣパラメータ等を含む）を生成し、これを前記ベアラ更新要求メッセージに含める。これにより、当該変更指示に関する情報がベアラ変更要求メッセージにてＳ−ＧＷ３０に通知され（ステップＳ２７）、Ｓ−ＧＷ３０は、ＨＯ後のＵＥ１０からのＵＬのパケットについてＲＯＨＣ（IPv6/RTP）のヘッダ伸張を行なうノードが自ノードに設定されたことを認識する。なお、これらのステップＳ２６及びＳ２７の処理順序についても不問であり、並行して実施してもよい。
つまり、シグナル処理部７１は、ＨＯ先ＴＡがＲＯＨＣ（IPv6/RTP）をサポートしていないと判定した場合に、ＨＯ先ＴＡを介したパケット通信に関して、ＲＯＨＣ（IPv6/RTP）に対応する処理の実施ポイントをＳ−ＧＷとする制御を行なう制御手段としても機能する。
（２．２）ＵＥについて
図８は、ＵＥ１０の構成を示すブロック図である。この図８に示すＵＥ１０は、例えば、ベアラ管理部１１と、制御プレーン（C-plane）処理部１２と、上位層処理部１３と、ＲＯＨＣ処理部１４と、下位層処理部１５と、アプリケーション部１６と、をそなえる。
ここで、ベアラ管理部１１は、ＤＬ及びＵＬのベアラ（無線ベアラ）を管理し、制御プレーン処理部１２と連携して、ベアラの設定（確立、更新等）処理（シグナリングの生成、送受）を実施する機能を具備する。また、このベアラ管理部１１は、制御プレーン処理部１２からのベアラ設定要求に応じて、上位層処理部１３、ＲＯＨＣ処理部１４及び下位層処理部１５に対して各プロトコル処理の設定を行なう機能も具備する。
制御プレーン処理部１２は、下位層処理部１５（ＭＭＥ７０との間のインタフェース（“S1-MME”））を通じて、ＨＯ処理に伴う制御メッセージ（ＨＯコマンドやＨＯ完了メッセージ等）や、ベアラ管理部１１からの要求に応じたベアラ設定に伴うシグナリングの送受信を行なう機能を具備する。つまり、制御プレーン処理部１２は、異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段としての機能を果たす。
したがって、既述のように、ＵＬのＲＯＨＣ（IPv6/RTP）処理のヘッダ伸張ポイント及びＤＬのＲＯＨＣ（IPv6/RTP）処理のヘッダ圧縮ポイントをＳ−ＧＷ３０とする設定（指定）情報の通知を、ＨＯコマンドを用いて行なう場合、当該設定情報は、この制御プレーン処理部１２にて受信されることになる。
その場合の制御プレーン処理部１２は、ＨＯコマンドを受信することにより、ＨＯ先ＴＡを介したパケットフローのＲＯＨＣ（IPv6/RTP）処理（ヘッダ伸張／圧縮）の実施ポイントを、Ｓ−ＧＷ３０とする情報を受信する受信手段として機能することとなる。
そして、制御プレーン処理部１２は、その設定情報に従ってベアラ管理部１１を通じ上位層処理部１３、ＲＯＨＣ処理部１４及び下位層処理部１５（パケット通信手段）に対して設定を行なう。即ち、ＲＯＨＣ（IPv6/RTP）の実施ポイントをＳ−ＧＷ３０とする設定を行なう。
この設定により、ＵＥ１０は、ＨＯ後のパケットフローについてのＲＯＨＣ（IPv6/RTP）の実施ポイントをＳ−ＧＷ３０とする制御が可能となる。換言すれば、ベアラ管理部１１は、ＨＯを実施する際に、ＭＭＥ７０から受信した情報に基づいて、ＨＯ先ＴＡでのＲＯＨＣ（IPv6/RTP）処理を実施するポイントをＳ−ＧＷ３０とする制御を行なう制御手段として機能する。
上位層処理部１３は、ＰＤＣＰ（ＲＯＨＣ）層よりも上位層で規定される処理を実施するもので、例えば、ＩＰやＵＤＰ、ＲＴＰ（ＲＴＣＰ）等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能（処理スタック）を具備する。
ＲＯＨＣ処理部１４は、ＰＤＣＰ層のプロトコルスタックの一つとして位置付けられるＲＯＨＣプロトコルによる送信（ＵＬ）パケットのヘッダ圧縮及び受信（ＤＬ）パケットのヘッダ伸張機能（ＲＯＨＣ処理スタック）を具備する。本例のＲＯＨＣ処理部１４は、少なくともＲＯＨＣ（IPv6/RTP）処理機能を具備し、選択付加的にＲＯＨＣ（IPv4/RTP）処理機能を具備する。
下位層処理部１５は、ＰＤＣＰ層よりも下位層で規定されるプロトコル処理を担当する。例えば、ＲＬＣ層やＭＡＣ（Media Access Control）層、物理（ＰＨＹ）層等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能（処理スタック）を具備する。
アプリケーション部１６は、ＶｏＩＰ等による音声通信やＨＴＴＰやＦＴＰ等のデータ通信、その他の上位の各種アプリケーションプログラム（ソフトウェア）を具備し、当該プログラムに応じた処理（ユーザデータの生成、送受信等）を行なうものである。
以下、上述のごとく構成されたＵＥ１０の動作例について、図９〜図１４を用いて詳述する。ただし、ベアラ設定処理に関しては、既知の技術を適用することができ、以下では、ベアラ設定が済んでいる状態で、かつ、ＨＯ後の処理に着目して説明を行なう。
（ＵＬ処理）
まず、ＵＥ１０でのＵＬ処理について、図９に示すフローチャート並びに図１０及び図１１に示すシーケンス図を用いて説明する。なお、図１０は、ＲＯＨＣ（IPv6/RTP）パケットをカプセル化しない場合のＵＥ１０内のシーケンス、図１１は、ＲＯＨＣ（IPv6/RTP）パケットをカプセル化する場合のＵＥ１０内のシーケンスをそれぞれ表している。また、図９のフローチャートで示す処理は、Ｓ−ＧＷ３０にとっての後述するＤＬ処理（Ｄ１〜Ｄ８）にも相当する。
ＵＥ１０は、アプリケーション部１６にて、ユーザデータが生成されると、当該ユーザデータは、上位層処理部１３に渡す（図１０及び図１１のステップＥ１）。上位層処理部１３は、アプリケーション部１６から受信したユーザデータが、ＲＯＨＣ（IPv6/RTP）による圧縮対象のデータか否かを判定する（図９のステップＡ１）。この判定は、例えば、ＲＯＨＣ処理部１４において、ＨＯ時にＭＭＥ７０から通知（指示）された接続を記憶しておき、その情報を基にして行なう。
その結果、非ＲＯＨＣ対象のデータであれば（図９のステップＡ１でＮＯなら）、以降、ＵＥ１０は、通常どおりのパケット処理を実施する（図９のステップＡ２）。
例えば、上位層処理部１３は、当該データをＲＴＰペイロードとしてRTP/UDP/IPv6ヘッダを付加してIPv6パケットを生成し、ＲＯＨＣ処理部１４に転送する。
ＲＯＨＣ処理部１４は、当該IPv6パケットに、ＰＤＣＰヘッダを付加して下位層処理部１５に転送し、下位層処理部１５は、さらにＲＬＣヘッダを付加してＲＬＣパケットを生成し、これを無線（ＵＬ）パケットとして送信する。
一方、上位層処理部１３において、アプリケーション部１６から受信したユーザデータがＲＯＨＣ対象のデータあれば（図９のステップＡ１でＹＥＳなら）、当該データをＲＴＰペイロードとして当該ＲＴＰペイロードにRTP/UDP/IPv6を付加してIPv6パケットを生成し（図１０及び図１１のステップＥ２）、ＲＯＨＣ処理部１４に転送する（図１０及び図１１のステップＥ３）。
ＲＯＨＣ処理部１４は、Ｓ−ＧＷ３０との間でＲＯＨＣパラメータのネゴシエーションが済んでいるか否かを確認し（図９のステップＡ３）、済んでいれば（ステップＡ３でＹＥＳなら）、IPv6パケットのIPv6/UDP/RTPヘッダをネゴシエーションしたＲＯＨＣパラメータを基にＲＯＨＣ（IPv6/RTP）により圧縮する（図９のステップＡ４、図１０及び図１１のステップＥ４）。
ＲＯＨＣパラメータのネゴシエーションが済んでいなければ（図９のステップＡ３でＮＯなら）、ＲＯＨＣ処理部１４は、ＲＯＨＣパラメータのネゴシエーションをするパケット（以下、ネゴシエーションパケットともいう）を生成する（図９のステップＡ５）。なお、ＲＯＨＣは、圧縮（伸長）対象のデータフローとは別に、ＲＯＨＣパラメータ（例えば、サポートしているプロトコルの種類、コンテキスト（フロー）の最大数等）をＳ−ＧＷ３０との間で交渉することができる。
そして、ＲＯＨＣ処理部１４は、ＲＯＨＣ（IPv6/RTP）パケット又はネゴシエーションパケットがカプセル化してトンネルすべきものか否かを確認する（図９のステップＡ６）。その確認は、例えば、ＭＭＥ７０からＨＯ時に通知された情報を基に行なう。なお、前記ＲＯＨＣパラメータのネゴシエーションをＩＰ接続で行なう場合には、ネゴシエーションパケットは、IPv4パケットにカプセル化してトンネルすべきパケットである。
その結果、トンネルするパケットであれば（図９のステップＡ６でＹＥＳなら）、ＲＯＨＣ処理部１４は、当該トンネルパケットにＰＤＣＰヘッダを付加して（図１１のステップＥ５）、上位層処理部１３に送信（返送）する（図１１のステップＥ６）。
上位層処理部１３は、受信したパケットにIPv4ヘッダを付加してIPv4パケットにカプセル化する（図９のステップＡ７、図１１のステップＥ７）。
カプセル化されたパケット（トンネルパケット）は、上位層処理部１３から再びＲＯＨＣ処理部１４に転送され（図１１のステップＥ８）、ＲＯＨＣ処理部１４は、当該IPv4パケットのIPv4ヘッダをＲＯＨＣ（IPv4/RTP）にて圧縮し（図１１のステップＥ９）、ＰＤＣＰヘッダを付加して（図１１のステップＥ１０）、下位層処理部１５に転送する（図１１のステップＥ１１）。
一方、図９のステップＡ６において、非トンネルパケットであれば（ＮＯであれば）、ＲＯＨＣ処理部１４は、当該パケットにＰＤＣＰヘッダを付加して（図１０のステップＥ５）、下位層処理部１５に転送する（図１０のステップＥ１１）。
そして、下位層処理部１５は、ＲＯＨＣ処理部１４から転送されてきたＰＤＣＰパケット（トンネル又は非トンネルパケット）に、ＲＬＣヘッダを付加して（図１０及び図１１のステップＥ１２）、ＨＯ先ＴＡのエンティティ（ＲＮＣ４０）に送信する（図９のステップＡ８、図１０及び図１１のステップＥ１３）。
（ＤＬ処理）
次に、ＵＥ１０でのＤＬ処理について、図１２に示すフローチャート並びに図１３及び図１４に示すシーケンス図を用いて説明する。なお、図１３は、ＲＯＨＣ（IPv6/RTP）パケットがカプセル化されていない場合のＵＥ１０内のシーケンス、図１４は、ＲＯＨＣ（IPv6/RTP）パケットがカプセル化されている場合のＵＥ１０内のシーケンスをそれぞれ表している。また、図１２のフローチャートで示す処理は、Ｓ−ＧＷ３０にとっての後述するＵＬ処理（Ｃ１〜Ｃ８）にも相当する。
ＵＥ１０は、ＨＯ先ＴＡのエンティティ（ＲＮＣ４０）からＤＬパケット（ＲＬＣ）パケットを下位層処理部１５にて受信する（図１３及び図１４のステップＦ１）。
下位層処理部１５は、受信パケットのＲＬＣヘッダを終端（除去）し（図１３及び図１４のステップＦ２）、そのペイロードであるＰＤＣＰパケットをＲＯＣＨ処理部１４に転送する（図１３及び図１４のステップＦ３）。
ＲＯＨＣ処理部１４は、下位層処理部１５から受信したＰＤＣＰパケットがＲＯＨＣ（IPv6/RTP）によるヘッダ伸張対象のパケットか否かを確認する（図１２のステップＢ１）。例えば、ＲＯＨＣ処理部１４は、ＨＯ時にＭＭＥ７０から指示された接続を記憶しておき、その情報に基づいて、受信パケットがどの接続からのものかを判定することで、当該ヘッダ伸張対象のパケットを識別する。
その結果、非ＲＯＨＣ対象のパケットであれば（図１２のステップＢ１でＮＯなら）、ＵＥ１０は、当該受信パケットについて通常のパケット処理を実施する（図１２のステップＢ２）。
例えば、ＲＯＨＣ処理部１４は、受信したＰＤＣＰパケットのヘッダを終端（除去）し、ＰＤＣＰペイロードを上位層処理部１３へ転送する。上位層処理部１３は、受信したＰＤＣＰペイロードのRTP/UDP/IPv6ヘッダを終端（除去）し、ＲＴＰペイロードのデータ（ユーザデータ）をアプリケーション部１６に転送する。
一方、下位層処理部１５から受信したＰＤＣＰパケットがＲＯＨＣ（IPv6/RTP）によるＲＯＨＣ対象のパケットであれば（図１２のステップＢ１でＹＥＳなら）、ＲＯＨＣ処理部１４は、受信パケットがカプセル化されたトンネルパケットであるか否かを確認する（図１２のステップＢ３）。その確認は、例えば、ＭＭＥ７０からＨＯ時に通知された情報を基に行なう。
その結果、トンネルパケットであれば（図１２のステップＢ３でＹＥＳなら）、ＲＯＨＣ処理部１４は、受信したＰＤＣＰパケットのヘッダを終端（除去）し（図１４のステップＦ４）、そのペイロードにおけるＲＯＨＣ（IPv4/RTP）ヘッダを伸長し（図１４のステップＦ５）、ヘッダ伸長したパケットを上位層処理部１３に転送する（図１４のステップＦ６）。
上位層処理部１３は、受信したパケットのヘッダを終端（除去）してデカプセル化を行ない（図１２のステップＢ４、図１４のステップＦ７）、ヘッダ除去したＰＤＣＰパケットをＲＯＨＣ処理部１４に送信（返送）する（図１４のステップＦ８）。
ＲＯＨＣ処理部１４は、受信したＰＤＣＰパケットのヘッダを終端（除去）し（図１４のステップＦ９）、ＰＤＣＰペイロードがＲＯＨＣパラメータのネゴシエーションパケットであるか否かを確認する（図１２のステップＢ５）。
なお、受信パケットがトンネルパケットでなかった場合（図１２のステップＢ３でＮＯの場合）、ＲＯＨＣ処理部１４は、下位層処理部１５から受信したＰＤＣＰパケットのヘッダを終端（除去）して（図１３のステップＦ９）、同様に、ＰＤＣＰペイロードがＲＯＨＣパラメータのネゴシエーションパケットであるか否かを確認する（図１２のステップＢ５）。
その結果、ネゴシエーションパケットであれば（図１２のステップＢ５でＹＥＳなら）、ＲＯＨＣ処理部１４は、その内容を階層処理部１３経由でベアラ管理部１１に通知する。これにより、ベアラ管理部１１は、ネゴシエーションの応答（ＲＯＨＣパラメータの通知）を生成し、当該応答を下位層処理部１５経由でＵＬのベアラで送信する（図１２のステップＢ７）。
一方、ネゴシエーションパケットでなければ（図１２のステップＢ５でＮＯなら）、ＲＯＨＣ処理部１４は、ＰＤＣＰペイロードのＲＯＨＣ（IPv6/RTP）ヘッダを伸長してIPv6パケットを復元し（図１２のステップＢ６、図１３及び図１４のステップＦ１０）、当該パケットを、再度、上位層処理部１３に転送する（図１３及び図１４のステップＦ１１）。
上位層処理部１３は、受信したパケットのRTP/UDP/IPv6ヘッダを終端（除去）し（図１３及び図１４のステップＦ１２）、ＲＴＰペイロードのデータ（ユーザデータ）をアプリケーション部１６に転送する（図１２のステップＢ８、図１３及び図１４のステップＦ１３）。
（２．３）Ｓ−ＧＷについて
図１５は、Ｓ−ＧＷ３０の構成例を示すブロック図である。この図１５に示すＳ−ＧＷ３０は、例えば、ベアラ管理部３１と、シグナル処理部３２と、上位層処理部３３と、ＲＯＨＣ処理部３４と、下位層処理部３５と、をそなえる。
ここで、ベアラ管理部３１は、ＤＬ及びＵＬのベアラを管理し、シグナル処理部３２と連携して、ベアラの設定（確立、更新等）処理（シグナリングの生成、送受）を実施する機能を具備する。また、このベアラ管理部３１は、シグナル処理部３２からのベアラ設定要求に応じて、上位層処理部３３、ＲＯＨＣ処理部３４及び下位層処理部３５に対して各プロトコル処理の設定を行なう機能も具備する。
シグナル処理部３２は、下位層処理部３５（ＭＭＥ７０との間のインタフェース（“S1-MME”））を通じて、ＨＯ処理に伴う制御メッセージ（ベアラ更新要求メッセージやその応答メッセージ等）や、ベアラ管理部３１からの要求に応じたベアラ設定に伴うシグナリングの送受信を行なう機能を具備する。
したがって、既述のように、ＲＯＨＣ（IPv6/RTP）処理の実施ポイントを自局３０とする設定情報の通知を、ベアラ更新要求メッセージを用いて行なう場合、当該設定情報は、このシグナル処理部３２にて受信されることになる。
つまり、シグナル処理部３２は、ＵＥ１０のＨＯ先ＴＡがＲＯＨＣ（IPv6/RTP）をサポートしていない場合にＭＭＥ７０が送信した情報であって、ＨＯ先ＴＡを介したパケット通信に関して、ＲＯＨＣ（IPv6/RTP）に対応する処理の実施ポイントを指定する情報を受信する受信手段としての機能を果たす。
その場合のシグナル処理部３２は、前記ベアラ更新要求メッセージを受信することにより、ＨＯ後のパケットフローに関するＲＯＨＣ（IPv6/RTP）処理の実施ポイントを自局３０とする設定情報を受信する受信手段として機能することとなる。
そして、シグナル処理部１２は、その設定情報に基づいてベアラ管理部３１を通じ上位層処理部３３、ＲＯＨＣ処理部３４及び下位層処理部３５（パケット通信手段）に対して設定を行なう。即ち、ＵＥ１０がＨＯした後のＨＯ先ＴＡを介したパケットフローについてのＲＯＨＣ（IPv6/RTP）処理の実施ポイントを自局３０とする設定を行なう。
この設定により、Ｓ−ＧＷ３０は、ＵＥ１０がＨＯした後のＨＯ先ＴＡを介したパケットフローについてのＲＯＨＣ（IPv6/RTP）処理の実施ポイントを自局３０とするパケット通信制御が可能となる。換言すれば、ベアラ管理部３１は、ＵＥ１０がＨＯを実施する際にＭＭＥ７０から受信した情報に基づいて、ＨＯ先ＴＡを介したパケット通信に関するＲＯＨＣ（IPv6/RTP）処理の実施ポイントを自局３０とする制御を行なう制御手段として機能する。
上位層処理部３３は、ＰＤＣＰ（ＲＯＨＣ）層よりも上位層で規定される処理を実施するもので、例えば、ＩＰやＵＤＰ，ＲＴＰ（ＲＴＣＰ）等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能（処理スタック）を具備する。
ＲＯＨＣ処理部３４は、ＰＤＣＰ層のプロトコルスタックの一つとして位置付けられるＲＯＨＣプロトコルによる送信（ＵＬ）パケットのヘッダ圧縮及び受信（ＤＬ）パケットのヘッダ伸張機能（ＲＯＨＣ処理スタック）を具備する。本例のＲＯＨＣ処理部３４は、少なくともIPv6のＲＯＨＣ処理機能を具備し、選択付加的にIPv4のＲＯＨＣ処理機能を具備する。
下位層処理部３５は、ＰＤＣＰ層よりも下位層で規定されるプロトコル処理を担当する。例えば、ＲＬＣ層やＭＡＣ（Media Access Control）層、物理（ＰＨＹ）層等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能（処理スタック）を具備する。
以下、上述のごとく構成されたＳ−ＧＷ３０の動作例について、図９，図１２，図１６〜図１９を用いて詳述する。ただし、ベアラ設定処理に関しては、既知の技術を適用することができ、以下では、ベアラ設定が済んでいる状態で、かつ、ＨＯ後の処理に着目して説明を行なう。
（ＵＬ処理）
まず、Ｓ−ＧＷ３０が、ＵＥ１０からＵＬパケットを受信した場合の処理について、図１２に示すフローチャート並びに図１６及び図１７に示すシーケンス図を用いて説明する。なお、図１６は、ＲＯＨＣ（IPv6/RTP）パケットがカプセル化されていない場合のＳ−ＧＷ３０内のシーケンス、図１７は、ＲＯＨＣ（IPv6/RTP）パケットがカプセル化されている場合のＳ−ＧＷ３０内のシーケンスをそれぞれ表している。
Ｓ−ＧＷ３０は、ＵＥ１０のＨＯ先ＴＡのエンティティ（ＳＧＳＮ５０）からＤＬパケット（ＲＬＣ）パケットを下位層処理部３５にて受信する（図１６及び図１７のステップＧ１）。
下位層処理部３５は、受信パケットのＬ２，ＩＰ，ＵＤＰ，ＧＴＰ−Ｕの各ヘッダを終端（除去）し（図１６及び図１７のステップＧ２）、そのペイロードであるＰＤＣＰパケットがＲＯＨＣ（IPv6/RTP）のヘッダ伸張対象のパケットか否かを確認する（図１２のステップＣ１）。
例えば、ＩＰでカプセル化されている接続の場合、宛先ＩＰアドレスが自身（Ｓ−ＧＷ３０）のアドレスであるパケットがヘッダ伸張対象であると判定することができる。この判定は、前記ヘッダ除去したパケットをＲＯＨＣ処理部３４に転送してＲＯＨＣ処理部３４で行なうこととしてもよい。その場合、ＲＯＨＣ処理部３４は、ＨＯ時にＭＭＥ７０から指示された接続を記憶しておき、その情報に基づいて、受信パケットがどの接続からのものかを判定することで、当該ヘッダ伸張対象のパケットを識別することができる。
その結果、非ＲＯＨＣ対象のパケットであれば（図１２のステップＣ１でＮＯなら）、下位層処理部３５は、前記ヘッダ除去したパケットを上位層処理部３３に転送する。上位層処理部３３は、受信したパケットをＰＤＮ−ＧＷ６０へ転送するため、下位層処理部３５に転送し、下位層処理部３５は、ＰＤＮ−ＧＷ６０を宛先とするＧＴＰ−Ｕ（又は、モバイルＩＰ）ヘッダを付加してカプセル化し、送信を行なう（図１２のステップＣ２）。
一方、ＲＯＨＣ対象のパケットであれば（図１２のステップＣ１でＹＥＳなら）、下位層処理部３５は、受信パケットがカプセル化されたトンネルパケット（例えば、ＩＰパケット）であるか否かを確認する（図１２のステップＣ３）。
その結果、トンネルパケットであれば（図１２のステップＣ３でＹＥＳなら）、下位層処理部３５は、前記ヘッダ除去したパケット（ＧＴＰ−Ｕペイロード）を上位層処理部３３へ転送する（図１７のステップＧ３ｂ）。
上位層処理部３３は、受信したＧＴＰ−ＵペイロードのＩＰヘッダを終端（除去）してデカプセル化を行ない（図１２のステップＣ４、図１７のステップＧ４）、そのペイロードをＲＯＨＣ処理部３４に転送する（図１７のステップＧ５）。
受信パケットが非トンネルパケットであれば（図１２のステップＣ３でＮＯなら）、下位層処理部３５は、Ｌ２，ＩＰ，ＵＤＰ，ＧＴＰ−Ｕの各ヘッダを除去したパケット（ＧＴＰペイロード）をＲＯＨＣ処理部３４へ転送する（図１６のステップＧ３ａ）。
そして、ＲＯＨＣ処理部３４は、上位層処理部３３又は下位層処理部３５から受信したトンネル又は非トンネルパケットのＧＴＰペイロードがＲＯＨＣパラメータのネゴシエーションパケットであるか否かを確認する（図１２のステップＣ５）。
ネゴシエーションパケットであれば（ステップＣ５でＹＥＳなら）、ＲＯＨＣ処理部３４は、その内容を上位層処理部３３経由でベアラ管理部３１に通知する。これにより、ベアラ管理部３１は、ネゴシエーションの応答（ＲＯＨＣパラメータの通知）を生成し、当該応答を下位層処理部３５経由でＤＬのベアラで送信する（図１２のステップＣ７）。
一方、ネゴシエーションパケットでなければ（図１２のステップＣ５でＮＯなら）、ＲＯＨＣ処理部１４は、ＰＤＣＰヘッダを除去し（図１６及び図１７のステップＧ６）、ＰＤＣＰペイロードのＲＯＨＣ（IPv6/RTP）ヘッダを伸長してIPv6パケットを復元し（図１２のステップＣ６、図１６及び図１７のステップＧ７）、当該パケットを、再度、上位層処理部３３に転送する（図１６及び図１７のステップＧ８）。
上位層処理部３３は、受信したパケットをそのまま下位層処理部３５に転送し（図１６及び図１７のステップＧ９）、下位層処理部３５は、受信したIPv6パケットにＬ２，ＩＰ，ＵＤＰ，ＧＴＰ−Ｕの各ヘッダを付加し（図１６及び図１７のステップＧ１０）、ＰＤＮ−ＧＷ６０へ送信する（図１２のステップＣ８、図１６及び図１７のステップＧ１１）。
（ＤＬ処理）
次に、Ｓ−ＧＷ３０が、ＵＥ１０宛にＤＬパケットを送信する場合の処理について、図９に示すフローチャート並びに図１８及び図１９に示すシーケンス図を用いて説明する。なお、図１８は、ＲＯＨＣ（IPv6/RTP）パケットをカプセル化しない場合のＳ−ＧＷ３０内のシーケンス、図１９は、ＲＯＨＣ（IPv6/RTP）パケットをカプセル化する場合のＳ−ＧＷ３０内のシーケンスをそれぞれ表している。
Ｓ−ＧＷ３０は、ＰＤＮ−ＧＷ６０からパケットを下位層処理部３５にて受信すると、当該下位層処理部３５にて、Ｌ２，ＩＰ，ＵＤＰ，ＧＴＰ−Ｕの各ヘッダを終端（除去）し（図１８及び図１９のステップＨ１，Ｈ２）、そのＧＴＰペイロード（ＩＰパケット）を上位層処理部３３に転送する（図１８及び図１９のステップＨ３）。
上位層処理部３３は、受信したＧＴＰペイロードをそのままＲＯＨＣ処理部３４に転送する（図１８及び図１９のステップＨ４）。
ＲＯＨＣ処理部３４は、受信したペイロード（ＩＰパケット）が、ＲＯＨＣ（IPv6/RTP）による圧縮対象のデータか否かを判定する（図９のステップＤ１）。この判定は、例えば、ＲＯＨＣ処理部１４において、ＨＯ時にＭＭＥ７０から通知（指示）された接続を記憶しておき、その情報を基にして行なう。
その結果、非ＲＯＨＣ対象のデータであれば（図９のステップＤ１でＮＯなら）、以降、Ｓ−ＧＷ３０は、通常どおりのパケット処理を実施する（図９のステップＤ２）。
例えば、ＲＯＨＣ処理部３４は、前記ペイロードを下位層処理部３５に転送し、下位層処理部３５は、受信したペイロードにＬ２，ＩＰ，ＵＤＰ，ＧＴＰ−Ｕの各ヘッダを付加して、ＳＧＳＮ５０へ送信する。
一方、ＰＤＮ−ＧＷ６０から受信したパケットのＧＴＰペイロード（IPv6パケット）がＲＯＨＣ対象のデータあれば（図９のステップＤ１でＹＥＳなら）、ＲＯＨＣ処理部３４は、ＵＥ１０との間でＲＯＨＣパラメータのネゴシエーションが済んでいるか否かを確認する（図９のステップＤ３）。なお、ＲＯＨＣは、圧縮（伸長）対象のデータフローとは別に、ＲＯＨＣパラメータ（例えば、サポートしているプロトコルの種類、コンテキスト（フロー）の最大数等）をＵＥ１０との間で交渉することができる。
済んでいれば（図９のステップＤ３でＹＥＳなら）、ＲＯＨＣ処理部３４は、IPv6パケットのRTP/UDP/IPv6ヘッダを圧縮してＲＯＨＣ（IPv6/RTP）ヘッダとする（図９のステップＤ４、図１８及び図１９のステップＨ５）。
ＲＯＨＣパラメータのネゴシエーションが済んでいなければ（図９のステップＤ３でＮＯなら）、ＲＯＨＣ処理部３４は、ＲＯＨＣパラメータのネゴシエーションをするパケット（以下、ネゴシエーションパケットともいう）を生成する（図９のステップＤ５）。
そして、ＲＯＨＣ処理部３４は、ＲＯＨＣ（IPv6/RTP）パケット又はネゴシエーションパケットがカプセル化してトンネルすべきものか否かを確認する（図９のステップＤ６）。その確認は、例えば、ＭＭＥ７０からＨＯ時に通知された情報を基に行なう。なお、前記ＲＯＨＣパラメータのネゴシエーションをＩＰ接続で行なう場合には、ネゴシエーションパケットは、ＩＰパケットにカプセル化してトンネルすべきパケットである。
その結果、トンネルするパケットであれば（図９のステップＤ６でＹＥＳなら）、ＲＯＨＣ処理部３４は、トンネルパケットにＰＤＣＰヘッダを付加して上位層処理部３３に転送する（図１９のステップＨ７）。
上位層処理部３３は、受信したパケットにIPv4ヘッダを付加してIPv4パケットにカプセル化し（図９のステップＤ７、図１９のステップＨ８）、下位層処理部３５に転送する（図１９のステップＨ９ａ）。
一方、トンネルするパケットでなければ（図９のステップＤ６でＮＯなら）、ＲＯＨＣ処理部３４は、そのパケットにＰＤＣＰヘッダを付加して（図１８のステップＨ６）、下位層処理部３５に転送する（図１８のステップＨ９ｂ）。
そして、下位層処理部３５は、ＲＯＨＣ処理部３４から転送されてきたトンネル又は非トンネルのＰＤＣＰパケットに、Ｌ２，ＩＰ，ＵＤＰ，ＧＴＰ−Ｕの各ヘッダを付加して（図１８及び図１９のステップＨ１０）、ＳＧＳＮ５０へ送信する（図９のステップＤ８、図１８及び図１９のステップＨ１１）。
以上のように、本例によれば、ＵＥ１０のＨＯ先ＴＡがＨＯ前のＲＯＨＣ（IPv6/RTP）処理をサポートしていない場合であっても、ＵＥ１０は、ＨＯ前に使用していたＲＯＨＣ（IPv6/RTP）処理をＨＯ先ＴＡで適切に継続することが可能となる。したがって、無線リンクの利用効率の低下を抑制することができる。
また、ＵＬについてのＵＥ１０（ＤＬについてのＳ−ＧＷ３０）は、ＨＯ後のパケットフローにおいて、ヘッダ圧縮したIPv6パケットをIPv4パケットにカプセル化し、そのIPv4パケットのヘッダをさらにＲＯＨＣ（IPv4/RTP）により圧縮して情報量を削減することが可能である。したがって、ＵＬ（ＤＬ）パケットをＲＯＨＣ（IPv6/RTP）処理の実施ポイントへトンネルする際の無線リンクのリソース占有率の増加を抑制することも可能である。
さらに、前記ＲＯＨＣ（IPv6/RTP）処理の実施ポイントを設定する機能（手段）を、ＵＥ１０の移動を管理するＭＭＥ７０に実装して、ＵＥ１０の移動に伴うＨＯ処理に関連するメッセージを用いて前記ＲＯＨＣ実施ポイントの設定（情報通知）を行なうことができるので、ＳＡＥアーキテクチャに大幅な変更を加えることなく、ＵＥ１０がＨＯ前のＲＯＨＣ（IPv6/RTP）処理をＨＯ後にも適切に継続することを容易に実現できる。もっとも、当該設定機能は、ＳＡＥアーキテクチャの他のエンティティに実装してもよい。
また、上述した処理（機能）を実現するには、ＵＥ１０、Ｓ−ＧＷ３０、ＭＭＥ７０についての機能追加で足りるから、ＳＡＥアーキテクチャにおける他のエンティティには変更を加えることなく、互換性の維持を容易に図ることができる。
〔３〕付記
（付記１）
無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、をそなえたパケット通信システムにおけるパケット通信方法であって、
前記無線端末が異なる無線アクセス網にハンドオーバする際に、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いる第１のヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定し、
サポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信に関して、前記第１のヘッダ圧縮又は伸張方式に対応する処理の実施ポイントを前記パケット通信装置とする制御を行なう、
ことを特徴とする、パケット通信方法。
（付記２）
前記ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式とは異なる第２のヘッダ圧縮又は伸張方式をサポートしている場合において、
前記制御は、
前記第１のヘッダ圧縮方式で処理されたパケットを、前記第２のパケット通信において前記実施ポイントへトンネルするトンネルパケットに変換するトンネル処理を含む、ことを特徴とする、付記１記載のパケット通信方法。
（付記３）
前記制御は、
前記トンネルパケットを、前記第２のヘッダ圧縮方式でヘッダ圧縮する処理を含む、ことを特徴とする、付記２記載のパケット通信方法。
（付記４）
無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、をそなえたパケット通信システムであって、
前記無線端末が異なる無線アクセス網にハンドオーバする処理を制御する手段と、
前記ハンドオーバの際に、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いるヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定する手段と、
サポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信に関して、前記ヘッダ圧縮又は伸張方式に対応する処理の実施ポイントを前記パケット通信装置とする制御を行なう手段と、
をそなえたことを特徴とする、パケット通信システム。
（付記５）
無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、をそなえたパケット通信システムにおける管理装置であって、
前記無線端末が異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段と、
前記ハンドオーバの際に、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いるヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定する判定手段と、
前記判定手段がサポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信に関して、前記ヘッダ圧縮又は伸張方式に対応する処理の実施ポイントを前記パケット通信装置とする制御を行なう制御手段と、
をそなえたことを特徴とする、管理装置。
（付記６）
前記制御手段は、
前記制御のための情報を、前記ハンドオーバの過程で送受される制御メッセージを利用して前記無線端末と前記パケット通信装置に通知する、ことを特徴とする、付記５記載の管理装置。
（付記７）
無線端末と、第１の無線アクセス網と、第２の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおける前記無線端末であって、
第１のヘッダ圧縮又は伸張方式を用いてパケット通信を行なうパケット通信手段と、
異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段と、
ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式をサポートしていない場合に前記管理装置が送信した情報であって、前記ハンドオーバ先無線アクセス網を介したパケット通信に関して、前記第１のヘッダ圧縮又は伸張方式に対応する処理の実施ポイントを前記パケット通信装置に指定する情報を受信する受信手段と、
前記受信手段で受信した情報に基づいて、前記ハンドオーバ先無線アクセス網を介したパケット通信についての前記実施ポイントが前記パケット通信装置となるよう前記パケット通信手段を制御する制御手段と、
をそなえたことを特徴とする、無線端末。
（付記８）
前記ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式とは異なる第２のヘッダ圧縮又は伸張方式をサポートしている場合において、
前記パケット通信手段は、
前記第１のヘッダ圧縮方式で処理されたパケットを、前記第２のパケット通信において前記実施ポイントへトンネルするトンネルパケットにカプセル化する手段をそなえたことを特徴とする、付記７記載の無線端末。
（付記９）
前記パケット通信手段は、
前記トンネルパケットを、前記第２のヘッダ圧縮方式でヘッダ圧縮する手段をそなえたことを特徴とする、付記８記載の無線端末。
（付記１０）
無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおける前記パケット通信装置であって、
第１のヘッダ圧縮又は伸張方式を用いてパケット通信を行なうパケット通信手段と、
前記無線端末のハンドオーバ先無線アクセス網が前記ヘッダ圧縮又は伸張方式をサポートしていない場合に前記管理装置が送信した情報であって、前記ハンドオーバ先無線アクセス網を介したパケット通信に関して、前記第１のヘッダ圧縮又は伸張方式に対応する処理の実施ポイントを指定する情報を受信する受信手段と、
前記受信手段で受信した情報に基づいて、前記ハンドオーバ先無線アクセス網を介したパケット通信についての前記実施ポイントが自装置となるよう前記パケット通信手段を制御する制御手段と、
をそなえたことを特徴とする、パケット通信装置。
（付記１１）
前記ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式とは異なる第２のヘッダ圧縮又は伸張方式をサポートしている場合において、
前記パケット通信手段は、
前記無線端末において前記第１のヘッダ圧縮方式で処理され前記第２のパケット通信において前記実施ポイントへトンネルするトンネルパケットにカプセル化されたパケットをデカプセル化する手段をそなえたことを特徴とする、付記１０記載のパケット通信装置。
（付記１２）
前記パケット通信手段は、
前記トンネルパケットが、前記第２のヘッダ圧縮方式でヘッダ圧縮されている場合に、当該トンネルパケットを前記第２のヘッダ伸張方式で伸張する手段をそなえたことを特徴とする、付記１１記載のパケット通信装置。
本発明の適用対象の一例であるＳＡＥアーキテクチャを示すブロック図である。 ＳＡＥアーキテクチャにおけるＨＯ前のアップリンク（ＵＬ）のユーザパケットの転送経路（パケットフロー）とＨＯ後のＵＬのパケットフローとを示す図である。 ＳＡＥアーキテクチャにおけるＨＯ後のアップリンク（ＵＬ）のユーザパケットの転送経路（パケットフロー）示す図である。 （Ａ）はユーザプレーンのプロトコルスタックの一例を示す図であり、（Ｂ）はＳ１インタフェースのユーザプレーンのプロトコルスタックの一例を示す図である。 図２に示すようにＵＥがＨＯする際のプロシージャを説明するシーケンス図である。 本発明の一実施形態に係るＭＭＥの構成を示すブロック図である。 図６に示すＭＭＥの動作を説明するフローチャートである。 本発明の一実施形態に係るＵＥの構成を示すブロック図である。 図８に示すＵＥのＵＬ処理（図１５に示すＳ−ＧＷのＤＬ処理）を説明するフローチャートである。 図８に示すＵＥがＲＯＨＣパケットをカプセル化しない場合のＵＬ処理を説明するシーケンス図である。 図８に示すＵＥがＲＯＨＣパケットをカプセル化する場合のＵＬ処理を説明するシーケンス図である。 図８に示すＵＥのＤＬ処理（図１５に示すＳ−ＧＷのＵＬ処理）を説明するフローチャートである。 図８に示すＵＥのＤＬ処理（ＲＯＨＣ非カプセル化時）を説明するシーケンス図である。 図８に示すＵＥのＤＬ処理（ＲＯＨＣカプセル化時）を説明するシーケンス図である。 本発明の一実施形態に係るＳ−ＧＷの構成を示すブロック図である。 図１５に示すＳ−ＧＷのＵＬ処理（ＲＯＨＣ非カプセル化時）を説明するシーケンス図である。 図１５に示すＳ−ＧＷのＵＬ処理（ＲＯＨＣカプセル化時）を説明するシーケンス図である。 図１５に示すＳ−ＧＷのＤＬ処理（ＲＯＨＣ非カプセル化時）を説明するシーケンス図である。 図１５に示すＳ−ＧＷのＤＬ処理（ＲＯＨＣカプセル化時）を説明するシーケンス図である。 図２に示すＨＯ前のＵＬのパケット転送経路におけるパケットフォーマットの一例を示す図である。 図２に示すＨＯ後のＵＬのパケット転送経路（ＲＯＨＣ非カプセル化時）におけるパケットフォーマットの一例を示す図である。 図２に示すＨＯ後のＵＬのパケット転送経路（ＲＯＨＣカプセル化時）におけるパケットフォーマットの一例を示す図である。
符号の説明
１０ 無線端末（ユーザ端末：ＵＥ）
１１ ベアラ管理部
１２ 制御プレーン（C-plane）処理部
１３ 上位層処理部
１４ ＲＯＨＣ処理部
１５ 下位層処理部
１６ アプリケーション部
２０ 無線基地局（ｅＮＢ）
３０ Ｓ−ＧＷ（通信装置）
３１ ベアラ管理部
３２ シグナル処理部
３３ 上位層処理部
３４ ＲＯＨＣ処理部
３５ 下位層処理部
４０ ＲＮＣ
５０ ＳＧＳＮ
６０ ＰＤＮ−ＧＷ
７０ ＭＭＥ
７１ シグナル処理部
７２ ＵＥ機能サポート情報記憶部
７３ ＴＡ機能サポート情報記憶部
７４ 下位層処理部

Claims (10)

  1. 無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおけるパケット通信方法であって、
    前記無線端末が異なる無線アクセス網にハンドオーバする際に、前記管理装置により、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いる第１のヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定し、
    サポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信において、前記無線端末により少なくとも前記第１のヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記第１のヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置とする制御を、前記管理装置により行なうとともに、
    前記制御において、前記管理装置により、前記無線端末及び前記パケット通信装置に対して、前記実施ポイントを前記パケット通信装置とする情報を通知することを特徴とする、パケット通信方法。
  2. 前記ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式とは異なる第２のヘッダ圧縮又は伸張方式をサポートしている場合において、
    前記無線端末により、前記第１のヘッダ圧縮方式で処理されたパケットを、前記第２のパケット通信において前記実施ポイントへトンネルするトンネルパケットにカプセル化することを特徴とする、請求項１記載のパケット通信方法。
  3. 前記無線端末により、前記トンネルパケットを、前記第２のヘッダ圧縮方式でヘッダ圧縮することを特徴とする、請求項２記載のパケット通信方法。
  4. 無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムであって、
    前記管理装置は、
    前記無線端末が異なる無線アクセス網にハンドオーバする処理を制御する手段と、
    前記ハンドオーバの際に、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いるヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定する手段と、
    サポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信において、前記無線端末により少なくとも前記ヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記ヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置とする制御を行なう手段と、
    をそなえ、
    前記制御を行なう手段は、前記無線端末及び前記パケット通信装置に対して、前記実施ポイントを前記パケット通信装置とする情報を通知することを特徴とする、パケット通信システム。
  5. 無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、をそなえたパケット通信システムにおける管理装置であって、
    前記無線端末が異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段と、
    前記ハンドオーバの際に、ハンドオーバ元無線アクセス網を介した第１のパケット通信に用いるヘッダ圧縮又は伸張方式をハンドオーバ先無線アクセス網がサポートしているか否かを判定する判定手段と、
    前記判定手段がサポートしていないと判定した場合に、前記ハンドオーバ先無線アクセス網を介した第２のパケット通信において、前記無線端末により少なくとも前記ヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記ヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置とする制御を行なう制御手段と、
    をそなえ、
    前記制御手段は、前記無線端末及び前記パケット通信装置に対して、前記実施ポイントを前記パケット通信装置とする情報を通知することを特徴とする、管理装置。
  6. 前記制御手段は、
    前記制御のための情報を、前記ハンドオーバの過程で送受される制御メッセージを利用して前記無線端末と前記パケット通信装置に通知する、ことを特徴とする、請求項５記載の管理装置。
  7. 無線端末と、第１の無線アクセス網と、第２の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおける前記無線端末であって、
    第１のヘッダ圧縮又は伸張方式を用いてパケット通信を行なうパケット通信手段と、
    異なる無線アクセス網にハンドオーバする処理を制御するハンドオーバ制御手段と、
    ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式をサポートしていない場合に前記管理装置が前記無線端末及び前記パケット通信装置に対して送信した情報であって、前記ハンドオーバ先無線アクセス網を介したパケット通信において、前記無線端末により少なくとも前記第１のヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記第１のヘッダ伸張方式による伸張処理の実施ポイントを前記パケット通信装置に指定する情報を受信する受信手段と、
    前記受信手段で受信した情報に基づいて、前記ハンドオーバ先無線アクセス網を介したパケット通信についての前記実施ポイントが前記パケット通信装置となるよう前記パケット通信手段を制御する制御手段と、
    をそなえたことを特徴とする、無線端末。
  8. 前記ハンドオーバ先無線アクセス網が前記第１のヘッダ圧縮又は伸張方式とは異なる第２のヘッダ圧縮又は伸張方式をサポートしている場合において、
    前記パケット通信手段は、
    前記第１のヘッダ圧縮方式で処理されたパケットを、前記第２のパケット通信において前記実施ポイントへトンネルするトンネルパケットにカプセル化する手段をそなえたことを特徴とする、請求項７記載の無線端末。
  9. 前記パケット通信手段は、
    前記トンネルパケットを、前記第２のヘッダ圧縮方式でヘッダ圧縮する手段をそなえたことを特徴とする、請求項８記載の無線端末。
  10. 無線端末と、複数の無線アクセス網と、前記各無線アクセス網と接続されたパケット通信装置と、管理装置と、をそなえたパケット通信システムにおける前記パケット通信装置であって、
    第１のヘッダ圧縮又は伸張方式を用いてパケット通信を行なうパケット通信手段と、
    前記無線端末のハンドオーバ先無線アクセス網が前記ヘッダ圧縮又は伸張方式をサポートしていない場合に前記管理装置が前記無線端末及び前記パケット通信装置に対して送信した情報であって、前記ハンドオーバ先無線アクセス網を介したパケット通信において、前記無線端末により少なくとも前記第１のヘッダ圧縮方式で処理されるパケットであって前記ハンドオーバ先無線アクセス網を伝送されるパケットに関して、当該パケットに対する前記第１のヘッダ伸張方式による伸張処理の実施ポイントを指定する情報を受信する受信手段と、
    前記受信手段で受信した情報に基づいて、前記ハンドオーバ先無線アクセス網を介したパケット通信についての前記実施ポイントが自装置となるよう前記パケット通信手段を制御する制御手段と、
    をそなえたことを特徴とする、パケット通信装置。
JP2007279116A 2007-10-26 2007-10-26 パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置 Expired - Fee Related JP4882959B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2007279116A JP4882959B2 (ja) 2007-10-26 2007-10-26 パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置
US12/255,692 US8483176B2 (en) 2007-10-26 2008-10-22 Packet communication method, packet communication system, wireless terminal, and packet communication device
EP08167330.3A EP2053817B1 (en) 2007-10-26 2008-10-22 Packet communication method, packet communication system, wireless terminal, and packet communication device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007279116A JP4882959B2 (ja) 2007-10-26 2007-10-26 パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置

Publications (2)

Publication Number Publication Date
JP2009111485A JP2009111485A (ja) 2009-05-21
JP4882959B2 true JP4882959B2 (ja) 2012-02-22

Family

ID=40417150

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007279116A Expired - Fee Related JP4882959B2 (ja) 2007-10-26 2007-10-26 パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置

Country Status (3)

Country Link
US (1) US8483176B2 (ja)
EP (1) EP2053817B1 (ja)
JP (1) JP4882959B2 (ja)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5018890B2 (ja) * 2007-10-31 2012-09-05 富士通株式会社 通信方法並びに通信端末、データ転送装置及び制御装置
US8488553B2 (en) * 2008-06-05 2013-07-16 Alcatel Lucent Method for providing seamless transition between networks following different protocols
US8902805B2 (en) * 2008-10-24 2014-12-02 Qualcomm Incorporated Cell relay packet routing
KR101521886B1 (ko) * 2009-01-23 2015-05-28 삼성전자주식회사 이동통신 시스템에서 지티피 처리를 위한 장치 및 방법
US8031607B2 (en) * 2009-01-29 2011-10-04 Alcatel Lucent Implementation of internet protocol header compression with traffic management quality of service
US8750140B2 (en) * 2009-05-05 2014-06-10 Motorola Mobility Llc Support of home network base station local internet protocol access
US8792408B2 (en) * 2009-06-18 2014-07-29 Telefonaktiebolaget L M Ericsson (Publ) Backhaul header compression
CA2766689C (en) * 2009-06-30 2018-07-03 Ralf Keller Handling of access capability information in a mobile network
US8588227B2 (en) * 2009-07-17 2013-11-19 Qualcomm Incorporated Recursive header compression for relay nodes
EP2282577B1 (en) 2009-07-27 2012-05-23 Institute for Imformation Industry Wireless communication apparatus, header compression method thereof, and header decompression method thereof
US9674311B2 (en) * 2009-08-14 2017-06-06 Qualcomm Incorporated Robust header compression for relay nodes
CN102045299B (zh) * 2009-10-19 2014-02-05 中兴通讯股份有限公司 一种单模业务连续性实现方法和系统
CN102170667B (zh) * 2010-02-25 2013-02-27 中兴通讯股份有限公司 一种实现基站间切换的方法、系统及基站装置
JP5052642B2 (ja) * 2010-04-21 2012-10-17 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム、ネットワーク装置及び移動通信方法
US9769287B2 (en) * 2010-05-10 2017-09-19 Telefonaktiebolaget Lm Ericsson (Publ) Reducing protocol overhead in single-block packet access procedures
US9756009B2 (en) * 2011-11-07 2017-09-05 Telefonaktiebolaget Lm Ericsson (Publ) Message forwarding among disparate communication networks
US10560882B2 (en) * 2012-06-08 2020-02-11 Blackberry Limited Method and apparatus for multi-rat transmission
WO2013186323A1 (en) * 2012-06-13 2013-12-19 Telefonaktiebolaget L M Ericsson (Publ) Data compression in a communications network
KR102192165B1 (ko) * 2013-11-25 2020-12-16 삼성전자주식회사 전자 장치에서 헤더 압축된 패킷을 처리하기 위한 장치 및 방법
US20150230121A1 (en) * 2014-02-07 2015-08-13 Telefonaktiebolaget L M Ericsson (Publ) Mtc device, serving node, and various methods for implementing a downlink stack reduction feature
US20150230122A1 (en) * 2014-02-07 2015-08-13 Telefonaktiebolaget L M Ericsson (Publ) Mtc device, serving node, and various methods for implementing an uplink stack reduction feature
US9491575B2 (en) * 2014-06-13 2016-11-08 Qualcomm Incorporated Positioning beacons with wireless backhaul
EP3183868A1 (en) * 2014-08-21 2017-06-28 Nokia Technologies Oy Ipv4 communications using 6lowpan header compression mechanisms
US10470090B2 (en) 2014-11-14 2019-11-05 Qualcomm Incorporated Data compression techniques for handover and radio link failure recovery
US9860786B1 (en) * 2016-02-01 2018-01-02 Sprint Spectrum L.P. Efficient backhaul for relay nodes
US10887799B2 (en) * 2019-01-10 2021-01-05 Cisco Technology, Inc. SRv6 user-plane-based triggering methods and apparatus for session or flow migration in mobile networks
WO2020176890A1 (en) * 2019-02-28 2020-09-03 Apple Inc. Methods and systems for compression and decompression of information centric networking names at the packet data convergence protocol (pdcp)
US20230027419A1 (en) * 2020-02-13 2023-01-26 Lg Electronics Inc. Method and apparatus for processing duplicated packets during handover procedure in wireless communication system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7277455B2 (en) 2002-06-10 2007-10-02 Qualcomm Incorporated Packet flow processing in a communication system
CN1675909B (zh) 2002-06-10 2011-01-26 高通股份有限公司 通信系统中的分组流处理
CA2432594C (en) * 2002-06-12 2011-01-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for increased internet protocol (ip) headers compression performance by reporting cause of missing packets
US20040148427A1 (en) * 2002-11-27 2004-07-29 Nakhjiri Madjid F. Method and apparatus for PPP link handoff
US20050265284A1 (en) * 2003-10-10 2005-12-01 Hsu Liangchi Alan Apparatus, and associated method, for facilitating communication handoff in multiple-network radio communication system
KR100594773B1 (ko) * 2004-12-20 2006-06-30 한국전자통신연구원 다중 네트워크 인터페이스를 가진 노드의 이기종 네트워크연동 방법
EP1798929A1 (en) * 2005-12-19 2007-06-20 Thomson Licensing Providing an independent compression server within a network, as well as a method, network station and DHCP server

Also Published As

Publication number Publication date
US8483176B2 (en) 2013-07-09
US20090109924A1 (en) 2009-04-30
JP2009111485A (ja) 2009-05-21
EP2053817B1 (en) 2016-08-24
EP2053817A1 (en) 2009-04-29

Similar Documents

Publication Publication Date Title
JP4882959B2 (ja) パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置
JP5018890B2 (ja) 通信方法並びに通信端末、データ転送装置及び制御装置
JP5680633B2 (ja) バックホールヘッダ圧縮
US10608842B2 (en) GTP-U downlink packet sending method and apparatus
US9544821B2 (en) Mobile communication system
JP2019135865A (ja) ネットワークシステムと方法と装置並びにプログラム
WO2011039985A1 (ja) パケット回復方法、パケット回復システム、その方法で用いられる移動端末及び中間装置
JP5363629B2 (ja) 異なるプロトコルに準拠するネットワーク間でのシームレスな移行を提供するための方法
KR101896394B1 (ko) 릴레이 무선 단말, 코어 네트워크 장치, 및 이들의 방법
US20150271710A1 (en) Method, apparatus, and system for processing radio network user access
JP2009005342A (ja) 通信ネットワーク内において複数のトンネルを利用する方法
EP2200369A2 (en) Method and apparatus for handover between heterogeneous networks
CN109155946B (zh) 切换过程中的通信方法和装置
EP2981133A1 (en) Pdn gateway device and mobile communication method
WO2010127511A1 (zh) Srvcc切换及其数据传输的方法、装置和系统
WO2010106653A1 (ja) 基地局、通信装置、中継方法および通信方法
EP3167687B1 (en) Network node and method for co-located epdg and pgw functions
EP1879404A1 (en) Method and apparatus for interfacing a fixed/mobile convergence access network with the PS domain of a mobile core network
EP3841833A1 (en) Technique for preparing user equipment mobility
JP2008294963A (ja) ネットワークベースｉｐモビリティプロトコルを利用した通信システム、制御装置、ルータ及びその通信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100715

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110810

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110816

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111017

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111108

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111121

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

Free format text: PAYMENT UNTIL: 20141216

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4882959

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees