(57)【要約】携帯電話システムにおけるリソース負荷を低減することができる移動通信システム及びデータ通信方法を提供することを目的とする。本発明にかかる移動通信システムは、ｅＮｏｄｅＢ（２０）との間においてユーザデータを伝送するＳＧＷ（４０）と、外部ネットワークとの間においてユーザデータを伝送するＰＧＷ（５０）と、を備え、ＳＧＷ（４０）及びＰＧＷ（５０）は、ＳＧＷ（４０）とＰＧＷ（５０）との間において、端末装置からｅＮｏｄｅＢ（２０）を介して自律的に送受信される少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送するように構成されるものである。
2014041805.tif 000002
【特許請求の範囲】
【請求項１】
基地局との間においてユーザデータを伝送する第１のゲートウェイ装置と、
前記第１のゲートウェイ装置と外部ネットワークとの間において前記ユーザデータを伝送する第２のゲートウェイ装置と、を備え、
前記第１のゲートウェイ装置及び前記第２のゲートウェイ装置は、
前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間において、端末装置から前記基地局を介して自律的に送信される少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、移動通信システム。
【請求項２】
前記端末装置はマシンタイプであることを特徴とする、請求項１に記載の移動通信システム。
【請求項３】
前記第１のゲートウェイ装置は、
前記端末装置から送信されたデータが前記少量データか否かを判定し、前記少量データであると判定した場合に、前記端末装置から送信されたデータを前記制御信号を伝送する通信リソースを用いて、前記第２のゲートウェイ装置へ送信することを特徴とする、請求項１又は２に記載の移動通信システム。
【請求項４】
前記第１のゲートウェイ装置は、
前記端末装置から送信されたデータが前記少量データではないと判定した場合、前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間に前記ユーザデータを伝送するために用いられる通信リソースを設定することを特徴とする、請求項１乃至３のいずれか１項に記載の移動通信システム。
【請求項５】
前記第２のゲートウェイ装置は、
前記端末装置を宛先とするデータが前記少量データか否かを判定し、前記少量データであると判定した場合に、前記端末装置を宛先とするデータを前記制御信号を伝送する通信リソースを用いて、前記第１のゲートウェイ装置へ送信することを特徴とする、請求項１乃至４のいずれか１項に記載の移動通信システム。
【請求項６】
前記第２のゲートウェイ装置は、
前記端末装置を宛先とするデータが前記少量データではないと判定した場合、前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間に前記ユーザデータを伝送するために用いられる通信リソースを設定することを特徴とする、請求項１乃至５のいずれか１項に記載の移動通信システム。
【請求項７】
前記第１のゲートウェイ装置及び前記第２のゲートウェイ装置は、
加入者データを管理するサービス制御装置から、前記端末装置が、前記少量データを伝送するか否かに関する情報を取得することを特徴とする、請求項１乃至６のいずれか１項に記載の移動通信システム。
【請求項８】
前記第１のゲートウェイ装置及び前記第２のゲートウェイ装置は、
前記端末装置の位置登録処理を実行する際に、前記移動通信システム内における呼処理制御を行う呼処理制御装置から、前記ユーザデータを伝送する通信リソースの確保を指示された場合、実質的に通信リソースを確保しない疑似的な前記ユーザデータを伝送する通信リソースの確保処理を実行することを特徴とする、請求項１乃至７のいずれか１項に記載の移動通信システム。
【請求項９】
前記第１のゲートウェイ装置は、
前記端末装置から送信されたデータが前記少量データではないと判定した場合、前記疑似的に確保した前記ユーザデータを伝送する通信リソースを、前記端末装置から送信されたデータを伝送するために用いられる通常の通信リソースに変更することを特徴とする、請求項８に記載の移動通信システム。
【請求項１０】
前記第２のゲートウェイ装置は、
前記端末装置を宛先とするデータが前記少量データではないと判定した場合、前記疑似的に確保した前記ユーザデータを伝送する通信リソースを、前記端末装置から送信されたデータを伝送するために用いられる通常の通信リソースに変更することを特徴とする、請求項８に記載の移動通信システム。
【請求項１１】
前記基地局及び前記第１のゲートウェイ装置は、さらに、前記基地局及び前記第１のゲートウェイ装置の間において前記端末装置から送信される前記少量データを、前記制御信号を送受信する通信リソースを用いて伝送することを特徴とする、請求項１に記載の移動通信システム。
【請求項１２】
前記第１のゲートウェイ装置は、３ＧＰＰにおいて規定されるＳＧＷ（Serving Gateway）であり、前記第２のゲートウェイ装置は、３ＧＰＰにおいて規定されるＰＧＷ（Packet Data Network Gateway）である、請求項１乃至１１のいずれか１項に記載の移動通信システム。
【請求項１３】
前記第１のゲートウェイ装置は、３ＧＰＰにおいて規定されるＳＧＳＮ（Serving GPRS Support Node）であり、前記第２のゲートウェイ装置は、３ＧＰＰにおいて規定されるＧＧＳＮ（Gateway GPRS Support Node）である、請求項１乃至１１のいずれか１項に記載の移動通信システム。
【請求項１４】
基地局との間においてユーザデータを伝送する第１のゲートウェイ装置と、外部ネットワークとの間において前記ユーザデータを伝送する第２のゲートウェイ装置との間のデータ通信方法であって、
前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間において、端末装置から前記基地局を介して自律的に送信される少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、データ通信方法。
【請求項１５】
基地局と外部ネットワークとの間においてユーザデータを伝送するゲートウェイ装置であって、
端末装置から前記基地局を介して自律的に送信される少量データをユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、ゲートウェイ装置。
【請求項１６】
端末装置とゲートウェイ装置との間においてユーザデータを伝送する基地局であって、
前記端末装置から自律的に送信される少量データをユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は移動通信システム、データ通信方法、ゲートウェイ装置及び基地局に関し、特にＭＴＣデバイスを収容する移動通信システム及びその移動通信システムにおけるデータ通信方法に関する。
【背景技術】
【０００２】
3GPP（3rd Generation Partnership Project）標準化団体などで規定される現在の携帯電話システムのネットワークには、GTP（GPRS Tunnelling Protocol）もしくはPMIP（Proxy Mobile IP）というプロトコルが適用されている。これらのプロトコルは、ユーザが要求する通信を実現するために必要なリソースを確保することによってユーザに伝送路の提供を行う。必要なリソースは、ユーザ数および各ユーザから要求される接続数に応じて準備される必要がある。これらのプロトコルは、通信制御を行う制御信号（Control Plane、或いはC-Plane）及びユーザデータを伝送するためのユーザデータ信号（User Plane、或いはU-Plane）から構成される。また、ユーザデータ信号伝送に用いる伝送路（ＧＴＰの場合、ＧＴＰトンネル、ＰＭＩＰの場合、ＩＰトンネル）は、ユーザの要求により複数確保する事も可能である。【０００３】
一方、最近の技術トレンドとして、一般的な携帯電話システムを用いて、通常の携帯電話のみならず、データ端末、センサー、自動販売機もしくは自動車などの人間による操作を必要としない装置（以下、非人間とする）を対象とした通信が検討されている。このような非人間を対象とした通信は、一般的にＭＴＣ(Machine Type Communication)といわれている。ＭＴＣの特徴のひとつとして、比較的小さいサイズのデータ通信を行う事が挙げられる。たとえば、温度センサーが定期に温度を報告する場合、一回の通信に必要なデータ数は、数バイトで十分となる。更にＭＴＣに用いられるデバイス（以下、ＭＴＣデバイス）の別の特徴として、携帯電話システムが多用される最繁時を避け、比較的空いている深夜帯などで通信を実現する事も可能である。この様な特徴を生かし、携帯電話事業者では、携帯電話システムに通常の移動体端末の数百倍規模のＭＴＣデバイスを収容する事を想定している。【０００４】
ＭＴＣデバイスが、携帯電話システムに接続（つまりアッタチ処理完了）されると、携帯電話システム内のノード装置は、ＭＴＣのためにユーザデータ伝送路を確保する。このユーザデータ伝送路確保は、携帯電話システム内のノード装置によってＭＴＣデバイスのためにユーザデータ伝送路に必要なリソースを確保することを意図している。【０００５】
非特許文献１には、3GPPで規定されているネットワークにおいて、ユーザデータ伝送路に必要なリソースを確保する手順が開示されている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】3GPP TS 23.401 V11.1.0 "GPRS enhancements for E-UTRAN access (Release 11)" , clauses 5.3.2 and 5.10.2, 2012-03
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、上述したように携帯電話事業者は、携帯電話システムに通常の移動体端末の数百倍規模のＭＴＣデバイスの収容を前提としている。そのため、携帯電話システム内のノード装置において、ＭＴＣデバイスに対して通常の移動体端末と同様に必要なリソースを確保した場合に、携帯電話システムにおけるリソース負荷（メモリ負荷)が大きな問題となる。【０００８】
本発明は、このような問題を解決するために携帯電話システムにおけるリソース負荷を低減することができる移動通信システム、データ通信方法、ゲートウェイ装置及び基地局を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の態様にかかる移動通信システムは、基地局との間においてユーザデータを伝送する第１のゲートウェイ装置と、外部ネットワークとの間において前記ユーザデータを伝送する第２のゲートウェイ装置と、を備え、前記第１のゲートウェイ装置及び前記第２のゲートウェイ装置は、前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間において、端末装置から前記基地局を介して自律的に送信される少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送するものである。【００１０】
本発明の第２の態様にかかるデータ通信方法は、基地局との間においてユーザデータを伝送する第１のゲートウェイ装置と、外部ネットワークとの間において前記ユーザデータを伝送する第２のゲートウェイ装置との間のデータ通信方法であって、前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間において、端末装置から前記基地局を介して自律的に送信される少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送するものである。
【発明の効果】
【００１１】
本発明により、携帯電話システムにおけるリソース負荷を低減することができる移動通信システム、データ通信方法、ゲートウェイ装置及び基地局を提供することができる。
【図面の簡単な説明】
【００１２】
【図１】実施の形態１にかかる移動通信システムの構成図である。
【図２】実施の形態１にかかる移動通信システムの構成図である。
【図３】実施の形態１にかかる移動通信システムの構成図である。
【図４】実施の形態１にかかるＧＴＰ−Ｃメッセージの構成図である。
【図５】実施の形態１にかかるＡＴＴＡＣＨ処理の流れを説明する図である。
【図６】実施の形態１にかかるＴＡＵ実行時の処理の流れを説明する図である。
【図７】実施の形態１にかかるＵＥから少量データを送信する場合の処理の流れを説明する図である。
【図８】実施の形態１にかかるハンドオーバ処理の流れを説明する図である。
【図９】実施の形態１にかかるハンドオーバ処理の流れを説明する図である。
【図１０】実施の形態１にかかるＰＧＷにおいて少量データを受信した場合の処理の流れを説明する図である。
【図１１】実施の形態１にかかるＵＥから少量データを送信する場合の処理の流れを説明する図である。
【図１２】実施の形態１にかかる大型データを送信する場合の処理の流れを説明する図である。
【図１３】実施の形態１にかかる大型データを送信する場合の処理の流れを説明する図である。
【図１４】実施の形態１にかかる専用ベアラを削除する場合の処理の流れを説明する図である。
【図１５】実施の形態１にかかる専用ベアラを削除する場合の処理の流れを説明する図である。
【図１６】実施の形態２にかかるＡＴＴＡＣＨ処理の流れを説明する図である。
【図１７】実施の形態２にかかるＡＴＴＡＣＨ処理の流れを説明する図である。
【図１８】実施の形態２にかかるＴＡＵ実行時の処理の流れを説明する図である。
【図１９】実施の形態２にかかるハンドオーバ処理の流れを説明する図である。
【図２０】実施の形態３にかかる移動通信システムの構成図である。
【図２１】実施の形態３にかかる移動通信システムの構成図である。
【図２２】実施の形態３にかかる移動通信システムの構成図である。
【図２３】実施の形態３にかかるＲＡＮＡＰメッセージの構成図である。
【図２４】実施の形態３にかかるＡＴＴＡＣＨ処理の流れを説明する図である。
【図２５】実施の形態３にかかるＵＥから少量データを送信する場合の処理の流れを説明する図である。
【図２６】実施の形態３にかかるＲＡＵ実行時の処理の流れを説明する図である。
【図２７】実施の形態３にかかるＲＮＣ及びＳＧＳＮが変更される場合の処理の流れを説明する図である。
【図２８】実施の形態３にかかるＲＮＣ及びＳＧＳＮが変更される場合の処理の流れを説明する図である。
【図２９】実施の形態３にかかるＧＧＳＮにおいて少量データを受信した場合の処理の流れを説明する図である。
【図３０】実施の形態３にかかるＵＥから少量データを送信する場合の処理の流れを説明する図である。
【図３１】実施の形態３にかかる大型データを送受信する場合の処理の流れを説明する図である。
【図３２】実施の形態３にかかる大型データを送受信する場合の処理の流れを説明する図である。
【図３３】実施の形態３にかかる専用ベアラを削除する場合の処理の流れを説明する図である。
【図３４】実施の形態３にかかる専用ベアラを削除する場合の処理の流れを説明する図である。
【図３５】実施の形態４にかかるＡＴＴＡＣＨ処理の流れを説明する図である。
【図３６】実施の形態４にかかるＲＡＵ実行時の処理の流れを説明する図である。
【図３７】実施の形態４にかかるＵＥから少量データを送信する場合の処理の流れを説明する図である。
【図３８】実施の形態４にかかるハンドオーバ処理の流れを説明する図である。
【図３９】実施の形態４にかかるハンドオーバ処理の流れを説明する図である。
【図４０】実施の形態４にかかるＧＧＳＮにおいて少量データを受信した場合の処理の流れを説明する図である。
【図４１】実施の形態４にかかるＵＥから少量データを送信する場合の処理の流れを説明する図である。
【図４２】実施の形態４にかかる大型データを送受信する場合の処理の流れを説明する図である。
【図４３】実施の形態４にかかる大型データを送受信する場合の処理の流れを説明する図である。
【図４４】実施の形態４にかかる専用ベアラを削除する場合の処理の流れを説明する図である。
【図４５】実施の形態４にかかる専用ベアラを削除する場合の処理の流れを説明する図である。
【発明を実施するための形態】
【００１３】
（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。はじめに、図１を用いて本発明の実施の形態１にかかる移動通信システムの構成例について説明する。図１に示される移動通信システムの構成は、アクセスネットワークに３ＧＰＰにおいて規定されるＬＴＥ（Long Term Evolution）を用いる例を示している。本図に示す移動通信システムは、ＵＥ（User Equipment）１０、ｅＮｏｄｅＢ（enhanced Node B）２０、ＭＭＥ（Mobility Management Entity）３０、ＳＧＷ（Serving Gateway）４０及びＰＧＷ（Packet Data Network Gateway）５０を有している。
【００１４】
ＵＥ１０は、無線通信を行う通信機器もしくは移動局であり、例えば、携帯電話もしくはスマートフォン端末等であってもよい。さらに、ＵＥ１０は、ＭＴＣデバイス（マシンタイプの端末装置）であってもよい。ｅＮｏｄｅＢ２０は、移動局と無線通信を行う基地局である。ＵＥ１０及びｅＮｏｄｅＢ２０は、３ＧＰＰにおいて規定される無線通信規格であるＬＴＥを用いて無線通信を行う。
【００１５】
ＳＧＷ４０は、ｅＮｏｄｅＢ２０とＰＧＷ５０との間においてユーザデータを送受信するデータ中継装置として用いられる。ユーザデータは、ＵＥ１０から送信される音声データ等を含むパケットデータである。
【００１６】
ＰＧＷ５０は、外部ネットワークとの間においてユーザデータを送受信するゲートウェイ装置として用いられる。外部ネットワークは、ｅＮｏｄｅＢ２０、ＭＭＥ３０、ＳＧＷ４０及びＰＧＷ５０を有するネットワークとは異なるネットワークである。外部ネットワークは、例えば、ｅＮｏｄｅＢ２０、ＭＭＥ３０、ＳＧＷ４０及びＰＧＷ５０を管理する事業者とは異なる事業者によって管理されているネットワークである。但し、外部ネットワークは、上記だけに限らず、携帯電話事業者が同一の場合、ｅＮｏｄｅＢ２０、ＭＭＥ３０、ＳＧＷ４０及びＰＧＷ５０を有するネットワークと同一のネットワークであってもよい。
【００１７】
ＭＭＥ３０は、呼制御処理を行う装置である。例えば、ＭＭＥ３０は、ｅＮｏｄｅＢ２０から送信されるユーザデータの宛先となるＳＧＷを指定し、ｅＮｏｄｅＢ２０へ指定したＳＧＷを通知する。ＭＭＥ３０は、ｅＮｏｄｅＢ２０との間において制御信号を送受信するとともに、ＳＧＷ４０との間においても制御信号を送受信する。
【００１８】
続いて、各ノード装置間において規定されているプロトコルについて説明する。ＵＥ１０及びｅＮｏｄｅＢ２０の間における制御信号は、ＲＲＣ（Radio Resource Control）として規定されているプロトコルを用いて送受信される。さらに、ＵＥ１０及びｅＮｏｄｅＢ２０におけるユーザデータは、Ｔｒａｆｆｉｃ ｃｈａｎｎｅｌを用いて送受信される。
【００１９】
ｅＮｏｄｅＢ２０及びＳＧＷ４０の間におけるユーザデータ並びにＳＧＷ４０及びＰＧＷ５０の間におけるユーザデータは、ＧＴＰ−Ｕとして規定されているプロトコルを用いて送受信される。
【００２０】
ｅＮｏｄｅＢ２０及びＭＭＥ３０の間における制御信号は、Ｓ１ＡＰ（S1 Application Protocol）として規定されているプロトコルを用いて送受信される。ＭＭＥ３０及びＳＧＷ４０の間における制御信号並びにＳＧＷ４０及びＰＧＷ５０の間における制御信号は、ＧＴＰ−Ｃとして規定されているプロトコルを用いて送受信される。
【００２１】
続いて、図２を用いて、ＳＧＷ４０及びＰＧＷ５０の間において、少量データを、制御信号を送受信する通信リソースを用いて送受信する構成について説明する。少量データとは、例えば、ＭＴＣデバイスから送信されるデータである。その具体例としては、センサーやメータの測定値、自動販売機の売上などがある。さらに、少量データは、ユーザ操作を伴わずに通信機器間で自律的に送受信が行われるユーザデータであってもよい。また、少量データは、３ＧＰＰにおいてはＳｍａｌｌ Ｄａｔａと規定されている（3GPP TS 22.368 V11.5.0 "Service requirements for Machine-Type Communications (MTC)", clause 7.2.5, 2012-06など）。通信機器は、例えば、自動販売機もしくはセンサ端末等である。通信機器間の通信は、３ＧＰＰにおいてはＭＴＣ(Machine Type Communication)と規定されている。つまり少量データは、ＭＴＣデバイス間もしくはＭＴＣデバイスとサーバ装置等との間において伝送されるデータである。ＭＴＣは、一般的に、ユーザ操作を伴わず自律的に行われる通信を示している。通信リソースとは、例えば、ユーザデータもしくは制御信号を送受信するために設定されるパラメータ、パラメータを保持するメモリもしくは通信経路上においてユーザデータもしくは制御信号を送受信するために必要なリソース等である。
【００２２】
図２は、ＳＧＷ４０及びＰＧＷ５０の間において少量データをＧＴＰ−Ｃとして規定されているプロトコルを用いて送受信することを示している。例えば、ＳＧＷ４０は、ｅＮｏｄｅＢ２０からＧＴＰ−Ｕを介して送信されたＵＥ１０を送信元とする少量データを、ＧＴＰ−Ｃを介してＰＧＷ５０へ送信する。もしくは、ＰＧＷ５０は、ＵＥ１０を宛先とする少量データを受信した場合、ＧＴＰ-Ｃを介して少量データをＳＧＷ４０へ送信する。このように、ＳＧＷ４０及びＰＧＷ５０の間において少量データをＧＴＰ−Ｃを用いて送受信することにより、ＳＧＷ４０及びＰＧＷ５０においてユーザデータ用（例えばＧＴＰ−Ｕ）の通信リソースを確保する必要がなく、リソース負荷を低減することができる。
【００２３】
また、図３は、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間において、ＧＴＰ−Ｕを用いて送受信されていた少量データを、制御信号を送受信するプロトコルを用いて送信する例について示している。ｅＮｏｄｅＢ２０は、Ｔｒａｆｆｉｃ ｃｈａｎｎｅｌを介して送信された少量データを、Ｓ１ＡＰを介してＭＭＥ３０へ送信する。さらに、ＭＭＥ３０は、ｅＮｏｄｅＢ２０から送信された少量データをＧＴＰ−Ｃを介してＳＧＷ４０へ送信する。もしくは、ＳＧＷ４０は、ＰＧＷ５０からＵＥ１０を宛先とする少量データを受信した場合、ＧＴＰ−Ｃを介して少量データをＭＭＥ３０へ送信する。さらに、ＭＭＥ３０は、受信した少量データをＳ１ＡＰを介してｅＮｏｄｅＢ２０へ送信する。ＳＧＷ４０及びＰＧＷ５０の間は、図２と同様であるため詳細な説明を省略する。
【００２４】
ここで、図４を用いて、ＧＴＰ−Ｃメッセージの構成例について説明する。ＧＴＰ−Ｃを介して送信されるＧＴＰ−Ｃメッセージは、ＧＴＰ−Ｃメッセージヘッダ及びＩＥ（Information Element）Ａ〜Ｃを有している。さらに、ＧＴＰ−Ｃメッセージは、少量データを送信するために、ＵＰ−ＰＤＵ（User Plane-Protocol Date Unit） ＩＥが規定されている。また、ｅＮｏｄｅＢ２０及びＭＭＥ３０の間に用いられるＳ１ＡＰメッセージもＧＴＰ−Ｃメッセージと同様に、ＵＰ−ＰＤＵ ＩＥが規定されている。
【００２５】
このように、ＳＧＷ４０及びＰＧＷ５０の間に加えてさらにｅＮｏｄｅＢ２０及びＳＧＷ４０の間においても少量データを、制御信号を送信するために用いられるＳ１ＡＰ及びＧＴＰ−Ｃを用いて送受信することにより、ｅＮｏｄｅＢ２０においてユーザデータ用の通信リソースを確保する必要がなく、リソース負荷を低減することができる。
【００２６】
また、図２の構成においては、ＵＥ１０及びｅＮｏｄｅＢ２０の処理動作は、図１のＵＥ１０及びｅＮｏｄｅＢ２０と同様である。そのため、ＵＥ１０及びｅＮｏｄｅＢ２０には、本発明を実現するために新規機能を搭載する必要がない。一方、図３の構成においては、ＵＥ１０の処理動作は、図１のＵＥ１０と同様である。そのため、ＵＥ１０には、本発明を実現するために新規機能を搭載する必要がない。ここで、新規機能とは、例えば、ユーザデータ用ベアラを介して送信された少量データを受信し、受信した少量データを制御信号用ベアラを介して送信する機能である。
【００２７】
続いて、図５を用いてＵＥの位置登録時（ＡＴＴＡＣＨ）の処理の流れについて説明する。ＡＴＴＡＣＨは、ＵＥに電源が投入された際等に、自装置の位置を移動通信ネットワークに登録するために行われる。また、図５においてはｅＮｏｄｅＢをｅＮＢと表記して説明している。以降、ｅＮｏｄｅＢ及びｅＮＢは同じ装置として説明を行う。
【００２８】
はじめに、ＵＥ１０は、ＡＴＴＡＣＨ信号をＭＭＥ３０へ送信する（Ｓ１）。次に、ＵＥ１０とＨＳＳ（Home Subscriber Server）との間でＵＥ１０の認証動作とセキュリティ設定が行われる（Ｓ２）。次に、ＭＭＥ３０は、Update Location request信号をＨＳＳへ送信する（Ｓ３）。次に、ＨＳＳは、Update Location Ack信号をＭＭＥ３０へ送信する。Update Location Ack信号には、ＡＰＮ単位に設定されているpseudo-U/Size attributionが含まれる。pseudo-U/Size attributionは、ＡＰＮ単位以外にも、ＩＭＳＩ単位もしくはＩＭＥＩＳＶ単位等に設定されてもよい。ＨＳＳは、ＵＥ１０に関連付けられた加入者データとして、pseudo-U/Size attributionを管理している。そのため、ＨＳＳは、ＵＥ１０から送信されたUpdate Location request信号に対して応答信号であるUpdate Location Ack信号に、pseudo-U/Size attributionを含めることができる。
【００２９】
pseudo-U/Size attribution は、pseudo-Uベアラを設定するために用いられる。pseudo-Uベアラとは、疑似的もしくは仮想的に設定されるＧＴＰ−Ｕベアラである。ベアラとは、装置間の通信経路を示している。ベアラは、装置間の通信経路を設定するために確保された通信リソースであってもよい。pseudo-Uベアラは、疑似的もしくは仮想的に設定されるベアラであるため、通信リソースの確保は行われないか、或いは必要最小の通信リソースが確保される。つまり、ＵＥ１０がＡＴＴＡＣＨ処理を実行する際に、通常はＧＴＰ−Ｕベアラを設定するために、通信リソースの確保処理が実行される。ここで、ＧＴＰ−Ｕベアラを設定する代わりに、実際には通信リソースの確保が行われないpseudo-Uベアラを設定することにより、各装置間の処理シーケンスを変更せず、さらに、無駄な通信リソースの確保を行わないようにすることができる。つまり、少量データをＧＴＰ−Ｃベアラを用いて伝送する場合に、通常であればＧＴＰ−Ｕベアラを設定する処理を実行する代わりに、pseudo-Uベアラを設定する処理を行う。このようにして、少量データを送信する通信機器に対して、ＧＴＰ−Ｕベアラを設定するための通信リソースを割り当てることなく、その通信機器を移動通信システムに収容することができる。
【００３０】
また、pseudo-U/Size attributionは、少量データとして定義するサイズ（Size）に関する情報も規定されている。定義されたサイズを超えるデータは、少量データとして扱われない。つまり、定義されたサイズを下回るデータが、少量データとして扱われる。
【００３１】
pseudo-U/Size attributionを受け取ったＭＭＥ３０は、ＰＵ（pseudo-U） ｆｌａｇを含むCreate Session request信号をＳＧＷ４０へ送信する。さらに、ＳＧＷ４０は、ＰＵ（pseudo-U） ｆｌａｇを含むCreate Session request信号をＰＧＷ５０へ送信する（Ｓ５）。ＰＵ ｆｌａｇは、ＳＧＷ４０及びＰＧＷ５０の間において、通常のＧＴＰ−Ｕベアラではなくpseudo-Uベアラを設定することを通知するパラメータである。また、ＰＵ ｆｌａｇは、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間において、通常のＧＴＰ−Ｕベアラではなく、pseudo-Uベアラを設定することを通知するパラメータであってもよい。
【００３２】
次に、ＰＧＷ５０は、ＰＵ ｓｔａｔｕｓ１を含むCreate Session response信号をＳＧＷ４０へ送信する。さらに、ＳＧＷ４０は、ＰＵ ｓｔａｔｕｓ１を含むCreate Session response信号をＭＭＥ３０へ送信する（Ｓ６）。ＰＵ ｓｔａｔｕｓ１は、ＳＧＷ４０及びＰＧＷ５０の間にpseudo-Uベアラが設定されている状態であることを示すパラメータである。ＰＧＷ５０からＳＧＷ４０、さらに、ＳＧＷ４０からＭＭＥ３０に対してCreate Session response信号が送信され、ＳＧＷ４０においてＰＵ ｓｔａｔｕｓ１が保持されることにより、ＳＧＷ４０及びＰＧＷ５０の間におけるpseudo-Uベアラ（以下、Pseudo-U treatment(1)）の設定が完了する（Ｓ７）。
【００３３】
次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０へＰＵ ｆｌａｇを含むInitial Context Setup Request/Attach Accept信号を送信する（Ｓ８）。これにより、ＭＭＥ３０は、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間に、ＧＴＰ−Ｕベアラではなく、pseud-Uベアラを設定することを通知する。次に、ｅＮｏｄｅＢ２０は、ＵＥ１０へRRC Connection Reconfiguration信号を送信する（Ｓ９）。次に、ＵＥ１０は、ｅＮｏｄｅＢ２０へRRC Connection Reconfiguration Complete信号を送信する（Ｓ１０）。
【００３４】
次に、ｅＮｏｄｅＢ２０は、ＰＵ ｓｔａｔｕｓ２を含むInitial Context Setup Response信号をＭＭＥ３０へ送信する（Ｓ１１）。ＰＵ ｓｔａｔｕｓ２は、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間にpseudo-Uベアラが設定されている状態であることを示すパラメータである。これにより、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間に、pseudo-Uベアラ（以下、Pseudo-U treatment(2)）の設定が完了する（Ｓ１２）。
【００３５】
次に、ＭＭＥ３０は、ＳＧＷ４０へＰＵ ｆｌａｇ及びＰＵ ｓｔａｔｕｓ２を含むModify bearer request信号を送信する（Ｓ１３）。これにより、ＭＭＥ３０は、Pseudo-U treatment(2)の状態をＳＧＷ４０へ通知する。次に、ＳＧＷ４０は、ＭＭＥ３０へModify bearer response信号を送信する（Ｓ１４）。
【００３６】
ＳＧＷ４０は、ＰＵ ｓｔａｔｕｓ１及びＰＵ ｓｔａｔｕｓ２を保持する。そのため、ＳＧＷ４０は、受信した少量データをどのベアラに設定して送信するかを判定することができる。例えば、ＳＧＷ４０は、ｅＮｏｄｅＢ２０との間にpseudo-Uベアラが設定されていることを示すＰＵ ｓｔａｔｕｓ２を保持している状態とする。この時に、ＳＧＷ４０は、ＰＧＷ５０から少量データを受信すると、ＧＴＰ−Ｃベアラを介して少量データをＭＭＥ３０へ送信する。例えば、ＳＧＷ４０が、ＰＵ ｓｔａｔｕｓ２を保持していない場合、ＳＧＷ４０は、ＰＧＷ５０から受信した少量データをＧＴＰ−Ｕベアラを介して少量データをｅＮｏｄｅＢ２０へ送信する。ＳＧＷ４０が、ＰＵ ｓｔａｔｕｓ２を保持していない場合とは、例えば、ｅＮｏｄｅＢ２０及びＳＧＷ４０が、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間においてpseudo-Uベアラを設定する機能を有していない場合等に発生する。
【００３７】
上述した説明においては、Pseudo-U treatment(1)及びPseudo-U treatment(2)を設定する例について説明した。つまり、ｅＮｏｄｅＢ２０からＰＧＷ５０の間において、少量データを、制御信号を送信するベアラを用いて送信する例について説明した。ただし、ＳＧＷ４０及びＰＧＷ５０の間においてのみ少量データを、制御信号を送信するベアラを用いて送信する場合については、Pseudo-U treatment(2)を設定する手順を省略してもよい。以下の説明においても同様である。
【００３８】
続いて、図６を用いて、ＴＡＵ（Tracking Area Update）が行われる場合の処理の流れについて説明する。Tracking Area（TA）は、移動通信ネットワーク上例えばコアネットワーク上で管理されるＵＥ１０の位置情報である。Tracking Area（TA）は、複数のセルから構成される領域であってもよい。ＴＡＵは、ＵＥ１０が位置するＴＡが変更される際に実行される処理である。
【００３９】
はじめに、ＵＥ１０は、ＴＡが変更されたＵＥ１０を管理する新たなＭＭＥ３０（Ｎｅｗ ＭＭＥ）へ、TAU request信号を送信する（Ｓ２１）。次に、Ｎｅｗ ＭＭＥは、ＴＡが変更される前のＵＥ１０を管理していたＭＭＥ３０（Ｏｌｄ ＭＭＥ）へContext Request信号を送信する（Ｓ２２）。次に、Ｏｌｄ ＭＭＥは、Ｎｅｗ ＭＭＥへ、Context Response信号を送信する（Ｓ２３）。Context Response信号には、ＰＵ ｆｌａｇが含まれる。つまり、Ｏｌｄ ＭＭＥは、ＵＥ１０に関しては、ＧＴＰ−Ｕの代わりにpseudo-Uベアラを設定することをＮｅｗ ＭＭＥへ通知したこととなる。次に、ＵＥ１０とＨＳＳ（Home Subscriber Server）との間でＵＥ１０の認証動作とセキュリティ設定が行われる（Ｓ２４）。次に、Ｎｅｗ ＭＭＥは、Ｏｌｄ ＭＭＥへContext Request Ack信号を送信する（Ｓ２５）。
【００４０】
次に、Ｎｅｗ ＭＭＥは、ＴＡが変更されたことによりＵＥ１０から送信される少量データを伝送するために新たに割り当てられるＳＧＷ４０（Ｎｅｗ ＳＧＷ）へ、ＰＵ ｆｌａｇを含むCreate Session request信号を送信する（Ｓ２６）。次に、ＴＡが変更される前に割り当てられていたＳＧＷ４０（Ｏｌｄ ＳＧＷ）及びＰＧＷ５０の間に設定されていたpseudo-Uベアラを、Ｎｅｗ ＳＧＷ及びＰＧＷ５０の間にpseudo-Uベアラを設定する。そのため、Ｎｅｗ ＳＧＷは、ＰＵ ｆｌａｇを含むModify bearer request信号をＰＧＷ５０へ送信する（Ｓ２７）。次に、ＰＧＷ５０は、ＰＵ ｓｔａｔｕｓ１を含むModify bearer response信号をＮｅｗ ＳＧＷへ送信する（Ｓ２８）。次に、Ｎｅｗ ＳＧＷは、Ｎｅｗ ＭＭＥへＰＵ ｓｔａｔｕｓ１を含むCreate Session response信号を送信する（Ｓ２９）。これにより、Ｎｅｗ ＳＧＷ及びＰＧＷ５０の間に、Pseudo-U treatment（１）が設定される（Ｓ３０）。
【００４１】
次に、Ｎｅｗ ＭＭＥは、ＨＳＳへ、Update Location request信号を送信する（Ｓ３１）。次に、ＨＳＳは、Ｎｅｗ ＭＭＥへ、Update Location Ack信号を送信する。Update Location Ack信号には、ＡＰＮ単位に設定されるpseudo-U/Size attributionが含まれている（Ｓ３２）。pseudo-U/Size attributionは、ＡＰＮ単位以外にも、ＩＭＳＩ単位もしくはＩＭＥＩＳＶ単位等に設定されてもよい。次に、Ｎｅｗ ＭＭＥは、ＵＥ１０へTAU accept信号を送信する（Ｓ３３）。
【００４２】
続いて、図７を用いてＵＥ１０から少量データを送信する場合の処理の流れについて説明する。はじめに、ＵＥ１０は、ＭＭＥ３０へPDN Connectivity Request(APN)信号を送信する（Ｓ４１）。次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０へ、ＰＵ ｆｌａｇを含むInitial Context Setup Request信号を送信する（Ｓ４２）。ステップＳ４３〜Ｓ４８の処理は、図５のステップＳ９〜Ｓ１４と同様であるため詳細な説明を省略する。
【００４３】
続いて、図８及び図９を用いてハンドオーバ処理の流れについて説明する。図８及び図９のハンドオーバにおいては、ＵＥ１０が属するｅＮｏｄｅＢ、ＭＭＥ及びＳＧＷが変更される場合について説明する。はじめに、ハンドオーバ元のｅＮｏｄｅＢ２０（Ｏｌｄ ｅＮＢ）は、Ｏｌｄ ｅＮＢを管理しているＭＭＥ３０（Ｏｌｄ ＭＭＥ）へ、Handover required信号を送信する（Ｓ５１）。次に、Ｏｌｄ ＭＭＥは、ハンドオーバ先のｅＮｏｄｅＢ２０（Ｎｅｗ ｅＮＢ）を管理しているＭＭＥ３０（Ｎｅｗ ＭＭＥ）へForward relocation request信号を送信する（Ｓ５２）。Forward relocation request信号には、ＰＵ ｆｌａｇが含まれる。次に、Ｎｅｗ ＭＭＥは、Ｎｅｗ ｅＮＢに接続されるＮｅｗ ＳＧＷへCreate Session request信号を送信する（Ｓ５３）。Create Session request信号には、ＰＵ ｆｌａｇが含まれる。次に、Ｎｅｗ ＳＧＷは、Ｎｅｗ ＭＭＥへCreate Session response信号を送信する（Ｓ５４）。
【００４４】
次に、Ｎｅｗ ＭＭＥは、Ｎｅｗ ｅＮＢへＰＵ ｆｌａｇを含むHandover request信号を送信する（Ｓ５５）。次に、Ｎｅｗ ｅＮＢは、Ｎｅｗ ＭＭＥへＰＵ ｓｔａｔｕｓ２を含むHandover request ack信号を送信する（Ｓ５６）。これにより、Ｎｅｗ ｅＮＢ及びＮｅｗ ＳＧＷの間に、Pseudo-U treatment(2)が設定される（Ｓ５７）。次に、Ｎｅｗ ＭＭＥは、Ｏｌｄ ＭＭＥへForward relocation response信号を送信する（Ｓ５８）。次に、Ｏｌｄ ＭＭＥは、Ｏｌｄ ｅＮＢへHandover command信号を送信する（Ｓ５９）。次に、Ｏｌｄ ｅＮＢは、ＵＥ１０へHandover command信号を送信する（Ｓ６０）。
【００４５】
次に、ステップＳ６０以降のハンドオーバ処理について、図９を用いて説明する。ステップＳ６０の後、ＵＥ１０は、Ｎｅｗ ｅＮＢへHandover confirm信号を送信する（Ｓ６１）。次に、Ｎｅｗ ｅＮＢは、Ｎｅｗ ＭＭＥへHandover Notify信号を送信する（Ｓ６２）。次に、Ｎｅｗ ＭＭＥは、Ｏｌｄ ＭＭＥへForward relocation complete Notification信号を送信する（Ｓ６３）。次に、Ｏｌｄ ＭＭＥは、Ｎｅｗ ＭＭＥへForward relocation complete Ack信号を送信する（Ｓ６４）。次に、Ｎｅｗ ＭＭＥは、Ｎｅｗ ＳＧＷへModify bearer request信号を送信する（Ｓ６５）。Modify bearer request信号には、ＰＵ ｆｌａｇ及びＰＵ ｓｔａｔｕｓ２が含まれている。
【００４６】
次に、Ｎｅｗ ＳＧＷは、ＰＧＷ５０へＰＵ ｆｌａｇを含むModify bearer request信号を送信する（Ｓ６６）。次に、ＰＧＷ５０は、Ｎｅｗ ＳＧＷへＰＵ ｓｔａｔｕｓ１を含むModify bearer response信号を送信する（Ｓ６７）。さらに、Ｎｅｗ ＳＧＷは、Ｎｅｗ ＭＭＥへＰＵ ｓｔａｔｕｓ１を含むModify bearer response信号を送信する（Ｓ６８）。これにより、Ｎｅｗ ＳＧＷ及びＰＧＷ５０の間に、Pseudo-U treatment(1)が設定される（Ｓ６９）。
【００４７】
次に、図１０を用いて、ＰＧＷ５０においてＵＥ１０を宛先とする少量データを受信した場合に処理の流れについて説明する。はじめに、ＳＧＷ４０及びＰＧＷ５０の間には、Pseudo-U treatment(1)が設定されている状態とする（Ｓ７１）。ＰＧＷ５０は、Pseudo-U treatment(1)と関連付けられているＵＥ１０を宛先とする少量データを受信した場合、受信した少量データをＧＴＰ−Ｃを介してＳＧＷ４０へ送信する（Ｓ７２）。次に、ＳＧＷ４０は、ＭＭＥ３０へ少量データを受信したことを通知するために、Downlink Data Notification信号を送信する（Ｓ７３）。このDownlink Data Notification信号には、少量データが含まれても良い。次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０へPage信号を送信し（Ｓ７４）、さらにｅＮｏｄｅＢ２０は、ＵＥ１０へPage信号を送信する（Ｓ７５）。なお、ＰＧＷ５０は、受信したデータが少量データであるか否かを判定するために、データのサイズが少量データとして定義されているサイズを超えているか否かを判定してもよい。
【００４８】
続いて、図１１を用いてＵＥ１０から少量データを送信する場合の処理の流れについて説明する。なお、図１１に示す処理は、図１０においてPage信号を受信したＵＥ１０が実行する処理としても用いられる。
【００４９】
はじめに、ＵＥ１０は、ＭＭＥ３０へService Request信号を送信する（Ｓ７６）。次に、ＵＥ１０とＨＳＳ（Home Subscriber Server）との間でＵＥ１０の認証動作とセキュリティ設定が行われる（Ｓ７７）。次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０へＰＵ ｆｌａｇを含むS1-AP:Initial Context Setup Request信号を送信する（Ｓ７８）。このS1-AP:Initial Context Setup Request信号には、少量データが含まれても良い。次に、ｅＮｏｄｅＢ２０は、ＵＥ１０との間に無線ベアラ（Radio bearer）を設定する（Ｓ７９）。eＮｏｄｅＢ２０は、S1-AP:Initial Context Setup Request信号で受信した少量データを設定された無線ベアラ（Radio bearer）を用いてＵＥ１０に送信しても良い。次に、ｅＮｏｄｅＢ２０は、ＭＭＥ３０へＰＵ ｓｔａｔｕｓ２を含むS1-AP:Initial Context Setup Complete信号を送信する（Ｓ８０）。これにより、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間に、Pseudo-U treatment(2)が設定される（Ｓ８１）。
【００５０】
次に、ＭＭＥ３０は、ＰＵ ｆｌａｇ及びＰＵ ｓｔａｔｕｓ２を含むModify bearer request信号を送信する（Ｓ８２）。次に、ＳＧＷ４０は、ＭＭＥ３０へModify bearer response信号を送信する（Ｓ８３）。
【００５１】
続いて、図１２を用いて少量データをＧＴＰ−Ｃを用いて送受信する環境において、少量データとして定義されるデータサイズ（もしくはデータ量）よりも大きい大型データを送受信する場合について説明する。例えば、ＭＴＣに用いられる通信機器として、温度センサーが用いられる場合に、温度センサーは、定期的に気温情報をサーバ装置等へ通知する。この場合の気温情報は、少量データとして扱われる。一方、温度センサーのソフトウェアのアップデートが要求された場合に、温度センサーは、少量データよりもデータ量が大きいデータ（以下、大型データと称する）を伝送する場合がある。このような場合の大型データの伝送方法について説明する。大型データは、pseudo-U/Size attributionにおいて定義されているデータサイズを超えるデータである。
【００５２】
ＳＧＷ４０及びＰＧＷ５０の間に少量データを伝送するためにＧＴＰ−Ｃベアラが設定されている場合に、ＰＧＷ５０にＵＥ１０を宛先とする大型データが到着すると、ＰＧＷ５０は、ＳＧＷ４０との間に新たに大型データを伝送するための専用のベアラを設定する。専用のベアラは、例えばＧＴＰ−Ｕベアラであってもよい。そのため、ＰＧＷ５０は、ＳＧＷ４０へCreate Bearer Request信号を送信する。さらに、ＳＧＷ４０は、ＭＭＥ３０へCreate Bearer Request信号を送信する（Ｓ９１）。次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０へBearer Setup Request信号を送信する（Ｓ９２）。次に、ｅＮｏｄｅＢ２０は、ＭＭＥ３０へBearer Setup Response信号を送信する（Ｓ９３）。次に、ＭＭＥ３０は、ＳＧＷ４０へCreate Bearer Response信号を送信する。さらに、ＳＧＷ４０は、ＰＧＷ５０へCreate Bearer Response信号を送信する（Ｓ９４）。
【００５３】
このようにして、Create Bearer Request/Response信号を送信することにより、ＳＧＷ４０及びＰＧＷ５０の間に大型データを伝送するための専用のベアラを設定し、Bearer Setup Request/Response信号を送受信することにより、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間にも専用のベアラを設定する。
【００５４】
また、ＳＧＷ４０及びＰＧＷ５０の間に少量データを伝送するためにＧＴＰ−Ｃが設定されている場合に、ＰＧＷ５０に大型データが到着すると、ＰＧＷ５０は、すでにＳＧＷ４０及びＰＧＷ５０の間に設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕベアラもしくは専用のベアラに変更してもよい。この場合、図１２のステップＳ９１及びＳ９４におけるCreate Bearer Request/Response信号の代わりに、Update Bearer Request/Response信号を用いる。さらに、図１２のステップＳ９２及びＳ９３におけるBearer Setup Request/Responseの代わりに、Bearer Modify Request/Response信号を用いる。
【００５５】
また、Bearer Modify Request/Response信号は、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間にPseudo-U treatment(2)が設定されている場合にのみ伝送される。
【００５６】
続いて、図１３を用いて少量データをＧＴＰ−Ｃ及びＳ１−ＡＰを用いて送受信する環境において、ＵＥ１０から大型データを送信する場合について説明する。
【００５７】
少量データを伝送するためにｅＮｏｄｅＢ２０及びＭＭＥ３０の間にＳ１−ＡＰが設定され、ＭＭＥ３０及びＰＧＷ５０の間にＧＴＰ−Ｃが設定されている場合に、ＵＥ１０から大型データを送信するために、ｅＮｏｄｅＢ２０とＰＧＷ５０との間に新たに大型データを伝送するための専用のベアラを設定する。
【００５８】
はじめに、ｅＮｏｄｅＢ２０がＵＥ１０から大型データを受信した場合、ｅＮｏｄｅＢ２０は、ＭＭＥ３０へBearer Resource Command信号を送信する（Ｓ１１１）。次に、ＭＭＥ３０は、ＳＧＷ４０へBearer Resource Command信号を送信し、さらにＳＧＷ４０は、ＰＧＷ５０へBearer Resource Command信号を送信する（Ｓ１１２）。次に、ＰＧＷ５０は、ＳＧＷ４０へCreate Bearer Request信号を送信し、さらにＳＧＷ４０は、ＭＭＥ３０へCreate Bearer Request信号を送信する（Ｓ１１３）。
【００５９】
次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０へBearer Setup Request信号を送信する（Ｓ１１４）。次に、ｅＮｏｄｅＢ２０は、ＭＭＥ３０へBearer Setup Response信号を送信する（Ｓ１１５）。次に、ＭＭＥ３０は、ＳＧＷ４０へCreate Bearer Response信号を送信する（Ｓ１１６）。
【００６０】
このようにして、ＭＭＥ３０及びＰＧＷ５０の間においてCreate Bearer Request/Response信号を送信することにより、ＳＧＷ４０及びＰＧＷ５０の間に大型データを伝送するための専用のベアラを設定し、ＭＭＥ３０及びｅＮｏｄｅＢ２０の間においてBearer Setup Request/Response信号を送信することにより、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間にも専用のベアラを設定する。
【００６１】
ここで、少量データをＳＧＷ４０及びＰＧＷ５０の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＷ４０及びｅＮｏｄｅＢ２０の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＵＥ１０からＳＧＷ４０までは、ＧＴＰ−Ｕベアラを介して大型データが伝送される。このような場合、ＳＧＷ４０からＰＧＷ５０へBearer Resource Command信号が送信される。さらに、ＰＧＷ５０及びＭＭＥ３０の間において、Create Bearer Request/Response信号が伝送される。これにより、ＳＧＷ４０及びＰＧＷ５０の間に大型データを伝送するために用いられる専用のベアラが設定される。またこの場合、図１３におけるBearer Setup Request/Response信号は、伝送されない。
【００６２】
また、ＳＧＷ４０及びＰＧＷ５０の間並びにＭＭＥ３０及びＳＧＷ４０の間に少量データを伝送するためにＧＴＰ−Ｃが設定され、ｅＮｏｄｅＢ２０及びＭＭＥ３０の間にＳ１ＡＰが設定されている場合に、ｅＮｏｄｅＢ２０がＵＥ１０から大型データを受信すると、ｅＮｏｄｅＢ２０とＰＧＷ５０との間に、すでに設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕベアラもしくは専用のベアラに変更してもよい。この場合、図１３のステップＳ１１３及びＳ１１６におけるCreate Bearer Request/Response信号の代わりに、Modify Bearer Request信号を用いる。さらに、図１３のステップＳ１１４及びＳ１１５におけるBearer Setup Request/Responseの代わりに、Bearer Modify Request/Response信号を用いる。
【００６３】
また、Bearer Modify Request/Response信号は、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間にPseudo-U treatment(2)が設定されている場合にのみ伝送される。
【００６４】
ここで、少量データをＳＧＷ４０及びＰＧＷ５０の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＷ４０及びｅＮｏｄｅＢ２０の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＵＥ１０からＳＧＷ４０までは、ＧＴＰ−Ｕベアラを用いて大型データが伝送される。このような場合、ＳＧＷ４０からＰＧＷ５０へBearer Resource Command信号が送信される。さらに、ＰＧＷ５０及びＭＭＥ３０の間において、Modify Bearer Request/Response信号が伝送される。これにより、ＳＧＷ４０及びＰＧＷ５０の間にすでに設定されているPseudo-Uベアラを大型データを伝送するために用いられる専用のベアラもしくはＧＴＰ−Ｕベアラへ変更することができる。また、この場合図１３におけるBearer Modify Request/Response信号は、伝送されない。
【００６５】
続いて、図１４を用いて、大型データを伝送するために設定された専用ベアラを削除する場合の処理の流れについて説明する。専用ベアラは、ｅＮｏｄｅＢ２０及びＰＧＷ５０の間において大型データの伝送が終了すると削除される。具体的には、大型データが一定時間伝送されないことがｅＮｏｄｅＢ２０もしくはＰＧＷ５０において検出された場合に、専用ベアラを削除してもよい。
【００６６】
はじめに、ＰＧＷ５０は、一定時間大型データの伝送が行われていないことを検出すると、ＳＧＷ４０へDelete Bearer Request信号を送信し、さらに、ＳＧＷ４０は、ＭＭＥ３０へDelete Bearer Request信号を送信する（Ｓ１３１）。次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間に設定された専用ベアラを削除するために、ｅＮｏｄｅＢ２０へDeactivate Bearer Request信号を送信する（Ｓ１３２）。
【００６７】
次に、ｅＮｏｄｅＢ２０は、ＭＭＥ３０へDeactivate Bearer Response信号を送信する（Ｓ１３３）。次に、ＭＭＥ３０は、ＳＧＷ４０へDelete Bearer Response信号を送信し、さらに、ＳＧＷ４０は、ＰＧＷ５０へDelete Bearer Response信号を送信する（Ｓ１３４）。これにより、ｅＮｏｄｅＢ２０及びＰＧＷ５０の間に設定された専用ベアラを削除することができる。
【００６８】
また、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、pseudo-Uベアラへ戻す処理の流れについて説明する。具体的には、図１４におけるステップＳ１３１及びＳ１３４におけるDelete Bearer Request/Response信号の代わりに、Update Bearer Request/Response信号を用いる。さらに、図１４のステップＳ１３２及びＳ１３３におけるDeactivate Bearer Request/Response信号の代わりに、Bearer Modify Request/Response信号を用いる。これらの信号を用いて、ＧＴＰ−Ｕベアラもしくは専用ベアラを、pseudo-Uベアラへ戻す処理を実行する。
【００６９】
続いて、図１５を用いて、ｅＮｏｄｅＢ２０が、大型データの伝送が行われていないことを検出した場合に、専用ベアラを削除する場合の処理の流れについて説明する。はじめに、ｅＮｏｄｅＢ２０は、一定時間大型データの伝送が行われていないことを検出すると、ＭＭＥ３０へBearer Resource Command信号を送信する（Ｓ１４１）。
【００７０】
次に、ＭＭＥ３０は、ＳＧＷ４０へDelete Bearer Command信号を送信し、さらに、ＳＧＷ４０は、ＰＧＷ５０へDelete Bearer Command信号を送信する（Ｓ１４２）。次に、ＰＧＷ５０は、ＳＧＷ４０へDelete Bearer Request信号を送信し、さらにＳＧＷ４０は、ＭＭＥ３０へDelete Bearer Request信号を送信する（Ｓ１４３）。次に、ＭＭＥ３０は、ｅＮｏｄｅＢ２０へDeactivate Bearer Request信号を送信する（Ｓ１４４）。次に、ｅＮｏｄｅＢ２０は、ＭＭＥ３０へDeactivate Bearer Response信号を送信する（Ｓ１４５）。次に、ＭＭＥ３０は、ＳＧＷ４０へDelete Bearer Response信号を送信し、さらにＳＧＷ４０は、ＰＧＷ５０へDelete Bearer Response信号を送信する（Ｓ１４６）。
【００７１】
このようにして、Delete Bearer Request/Response信号を送信することにより、ＳＧＷ４０及びＰＧＷ５０の間の大型データを伝送するための専用ベアラを削除し、Deactivate Bearer Request/Response信号を送信することにより、ｅＮｏｄｅＢ２０及びＳＧＷ４０の間の専用のベアラを削除する。
【００７２】
また、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、pseudo-Uベアラへ戻す処理の流れについて説明する。具体的には、図１５におけるステップＳ１４３及びＳ１４６におけるDelete Bearer Request/Response信号の代わりに、Modify Bearer Request/Response信号を用いる。さらに、図１５のステップＳ１４４及びＳ１４５におけるDeactivate Bearer Request/Response信号の代わりに、Bearer Modify Request/Response信号を用いる。これらの信号を用いて、ＧＴＰ−Ｕベアラもしくは専用ベアラを、pseudo-Uベアラへ戻す処理を実行する。
【００７３】
ここで、少量データをＳＧＷ４０及びＰＧＷ５０の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＷ４０及びｅＮｏｄｅＢ２０の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＳＧＷ４０において、大型データの伝送が行われていないことが検出されてもよい。この場合、ＳＧＷ４０からＰＧＷ５０へDelete Bearer Command信号が送信される。さらに、ＰＧＷ５０及びＭＭＥ３０の間において、Delete Bearer Request/Response信号が伝送される。これにより、ＳＧＷ４０及びＰＧＷ５０の間に設定されていた大型データを伝送するために用いられる専用のベアラを削除することができる。また、この場合、図１５におけるDeactivate Bearer Request/Response信号は、伝送されない。
【００７４】
以上説明したように、本発明の実施の形態１にかかる移動通信システムを用いることにより、ｅＮｏｄｅＢ２０及びＰＧＷ５０の間に通信リソースの確保を必要としないpseudo-Uベアラを設定することができる。これにより、少量データの伝送にＧＴＰ−Ｕベアラを用いる場合と同様の処理の流れを用いて、ＧＴＰ−Ｃ及びＳ１−ＡＰ等の制御信号を伝送するために用いられる通信リソースを利用して、少量データを伝送することができる。
【００７５】
（実施の形態２）
続いて、本発明の実施の形態２にかかる、ＳＧＷ４０及びＰＧＷ５０の間を、ＰＭＩＰ（Proxy Mobile IP）として規定される転送方式を用いて制御信号及びユーザデータの転送が行われる例について説明する。ＳＧＷ４０及びＰＧＷ５０の間における制御信号は、ＰＭＩＰにおいて規定されているプロトコル（以下、ＰＭＩＰと称する）を用いて送受信される。さらに、ＳＧＷ４０及びＰＧＷ５０の間におけるユーザデータは、一般的なＩＰパケットとして転送される。
【００７６】
ここで、ＳＧＷ４０及びＰＧＷ５０の間において、ＰＭＩＰが用いられる場合、少量データの伝送には、図２におけるＳＧＷ４０及びＰＧＷ５０の間のＧＴＰ−Ｃベアラの代わりに、ＰＭＩＰベアラが用いられる。
【００７７】
また、ＰＭＩＰを介して送信されるＰＭＩＰメッセージは、図４におけるＧＴＰ−Ｃメッセージヘッダの代わりに、ＰＭＩＰメッセージヘッダがもちいられ、図４と同様にＩＥ Ａ〜Ｃを有している。さらに、ＰＭＩＰメッセージは、少量データを送信するために、ＵＰ−ＰＤＵ ＩＥが規定されている。
【００７８】
続いて、図１６及び図１７を用いて、ＳＧＷ４０及びＰＧＷ５０の間にＰＭＩＰが用いられる場合の、ＵＥ１０のＡＴＴＡＣＨ処理の流れについて説明する。ステップＳ１５１〜ステップＳ１５４は、図５のステップＳ１〜ステップＳ４と同様であるため詳細な説明を省略する。ステップＳ１５４において、ＭＭＥ３０は、Update Location Ack信号を受信すると、ＳＧＷ４０へＰＵ ｆｌａｇを含むCreate Session request信号を送信する（Ｓ１５５）。
【００７９】
次に、ＳＧＷ４０は、ＰＧＷ５０へＰＢＵ（Proxy Binding Update）信号を送信する（Ｓ１５６）。ＰＢＵ信号には、ＰＵ ｆｌａｇが含まれている。次に、ＰＧＷ５０は、ＰＢＡ（Proxy Binding Ack）信号を送信する（Ｓ１５７）。ＰＢＡ信号には、ＰＵ ｓｔａｔｕｓ１が含まれている。次に、ＳＧＷ４０は、ＭＭＥ３０へCreate Session response信号を送信する（Ｓ１５８）。Create Session response信号には、ＰＵ ｓｔａｔｕｓ１が含まれている。これにより、ＳＧＷ４０及びＰＧＷ５０の間に、Pseudo-U treatment(1)が設定される（Ｓ１５９）。図１７のステップＳ１６０〜ステップＳ１６６は、図５のステップＳ８〜ステップＳ１４と同様であるため詳細な説明を省略する。
【００８０】
続いて、図１８を用いてＳＧＷ４０及びＰＧＷ５０の間にＰＭＩＰが用いられる場合の、ＴＡＵ（Tracking Area Update）の処理の流れについて説明する。ステップＳ１７１〜ステップＳ１７６は、図６のステップＳ２１〜ステップＳ２６と同様であるため詳細な説明を省略する。ステップＳ１７６においてCreate Session request信号を受信したＮｅｗ ＳＧＷは、ＰＧＷ５０へＰＵ ｆｌａｇを含むＰＢＵ信号を送信する（Ｓ１７７）。次に、ＰＧＷ５０は、Ｎｅｗ ＳＧＷへ、ＰＵ ｓｔａｔｕｓ１を含むＰＢＡ信号を送信する（Ｓ１７８）。ステップＳ１７９〜ステップＳ１８３は、図６のステップＳ２９〜ステップＳ３３と同様であるため詳細な説明を省略する。
【００８１】
続いて、図１９を用いてＵＥ１０へHandover commandが送信された後のHandover処理の流れについて説明する。ステップＳ１９１〜ステップＳ１９５は、図９のステップＳ６１〜Ｓ６５と同様であるため詳細な説明を省略する。ステップＳ１９５においてModify bearer request信号を受信したＮｅｗ ＳＧＷは、ＰＧＷ５０へＰＵ ｆｌａｇを含むＰＢＵ信号を送信する（Ｓ１９６）。次に、ＰＧＷ５０は、Ｎｅｗ ＳＧＷへＰＵ ｓｔａｔｕｓ１を含むＰＢＡ信号を送信する（Ｓ１９７）。ステップＳ１９８及びステップＳ１９９は、図９のステップＳ６８及びＳ６９と同様であるため詳細な説明を省略する。
【００８２】
以上説明したように、本発明の実施の形態２にかかる移動通信システムを用いることにより、ＳＧＷ４０及びＰＧＷ５０の間においてＰＭＩＰとして規定される転送方式を用いた場合においても、ｅＮｏｄｅＢ２０及びＰＧＷ５０の間に通信リソースの確保を必要としないpseudo-Uベアラを設定することができる。これにより、少量データの伝送にＧＴＰ−Ｕベアラを用いる場合と同様の処理の流れを用いて、ＰＭＩＰ等の制御信号を伝送するために用いられる通信リソースを利用して、少量データを伝送することができる。
【００８３】
（実施の形態３）
続いて、図２０を用いて、本発明の実施の形態３にかかる移動通信システムの構成例について説明する。図２０に示される移動通信システムの構成は、コアネットワークに３ＧＰＰにおいて規定される第２世代もしくは第３世代として規定されているＧＰＲＳを用いる例を示している。ＧＰＲＳを構成する装置にはは、ＳＧＳＮ４５、ＧＧＳＮ５５が含まれる。さらに、アクセスネットワークもしくはＲＡＮ（Radio Area Network）には、ＲＮＣ２５が用いられ、ＲＮＣ２５にＵＥ１０が接続されている。
【００８４】
ＵＥ１０は、図１と同様であるため詳細な説明を省略する。ＲＮＣ２５は、基地局を集約する装置であり、基地局を介してＵＥ（移動局）と通信を行う。例えば、ＲＮＣ２５は、ＵＥ１０から送信されたユーザデータを送信する送信先のＳＧＳＮ４５を特定し、特定したＳＧＳＮ４５に対してユーザデータを送信する。
【００８５】
ＳＧＳＮ４５は、ＲＮＣ２５とＧＧＳＮ５５との間においてユーザデータを送受信するデータ中継装置として用いられる。ユーザデータは、ＵＥ１０から送信される音声データ等を含むパケットデータである。
【００８６】
ＧＧＳＮ５５は、外部ネットワークとの間においてユーザデータを送受信するゲートウェイ装置として用いられる。外部ネットワークは、ＲＮＣ２５、ＳＧＳＮ４５及びＧＧＳＮ５５を有するネットワークとは異なるネットワークである。外部ネットワークは、例えば、ＲＮＣ２５、ＳＧＳＮ４５及びＧＧＳＮ５５を管理する事業者とは異なる事業者によって管理されているネットワークの場合もある。
【００８７】
続いて、図２０を用いて、各ノード装置間において規定されているプロトコルについて説明する。ＵＥ１０及びＲＮＣ２５の間における制御信号は、ＲＲＣとして規定されているプロトコルを用いて送受信される。さらに、ＵＥ１０及びＲＮＣ２５におけるユーザデータは、Ｔｒａｆｆｉｃ ｃｈａｎｎｅｌを用いて送受信される。
【００８８】
ＲＮＣ２５及びＳＧＳＮ４５の間におけるユーザデータ並びにＳＧＳＮ４５及びＧＧＳＮ５５の間におけるユーザデータは、ＧＴＰ−Ｕとして規定されているプロトコルを用いて送受信される。
【００８９】
ＲＮＣ２５及びＳＧＳＮ４５の間における制御信号は、ＲＡＮＡＰとして規定されているプロトコルを用いて送受信される。ＳＧＳＮ４５及びＧＧＳＮ５５の間における制御信号は、ＧＴＰ−Ｃとして規定されているプロトコルを用いて送受信される。
【００９０】
続いて、図２１を用いて、ＳＧＳＮ４５及びＧＧＳＮ５５の間において、少量データを、制御信号を送受信する通信リソースを用いて送受信する構成について説明する。
【００９１】
図２１は、ＳＧＳＮ４５及びＧＧＳＮ５５の間において少量データをＧＴＰ−Ｃとして規定されているプロトコルを用いて送受信することを示している。例えば、ＳＧＳＮ４５は、ＲＮＣ２５からＧＴＰ−Ｕを介して送信された少量データを、ＧＴＰ−Ｃを介してＧＧＳＮ５５へ送信する。もしくは、ＧＧＳＮ５５は、ＵＥ１０を宛先とする少量データを受信した場合、ＧＴＰ-Ｃを介して少量データをＳＧＳＮ４５へ送信する。このように、ＳＧＳＮ４５及びＧＧＳＮ５５の間において少量データをＧＴＰ−Ｃを用いて送受信することにより、ＳＧＳＮ４５及びＧＧＳＮ５５においてユーザデータ用の通信リソースを確保する必要がなく、リソース負荷を低減することができる。
【００９２】
また、図２２は、ＲＮＣ２５及びＳＧＳＮ４５の間において、ＧＴＰ−Ｕを用いて送受信されていた少量データを、制御信号を送受信するプロトコルを用いて送信する例について示している。ＲＮＣ２５は、Ｔｒａｆｆｉｃ ｃｈａｎｎｅｌを介して送信された少量データを、ＲＡＮＡＰを介してＳＧＳＮ４５へ送信する。もしくは、ＳＧＳＮ４５は、ＧＧＳＮ５５からＵＥ１０を宛先とする少量データを受信した場合、ＲＡＮＡＰを介して少量データをＲＮＣ２５へ送信する。ＳＧＳＮ４５及びＧＧＳＮ５５の間は、図２１と同様であるため詳細な説明を省略する。
【００９３】
このように、ＳＧＳＮ４５及びＧＧＳＮ５５の間に加えてさらにＲＮＣ２５及びＳＧＳＮ４５の間においても少量データを、制御信号を送信するために用いられるＲＡＮＡＰを用いて送受信することにより、ＲＮＣ２５においてユーザデータ用の通信リソースを確保する必要がなく、リソース負荷を低減することができる。
【００９４】
ここで、図２３を用いてＲＡＮＡＰの構成例について説明する。ＲＡＮＡＰを介して送信されるＲＡＮＡＰメッセージは、ＲＡＮＡＰメッセージヘッダ及びＩＥ Ａ〜Ｃを有している。さらに、ＲＡＮＡＰメッセージは、少量データを送信するために、ＵＰ−ＰＤＵ ＩＥが規定されている。
【００９５】
また、図２１の構成においては、ＵＥ１０及びＲＮＣ２５の処理動作は、図２０のＵＥ１０及びＲＮＣ２５と同様である。そのため、ＵＥ１０及びＲＮＣ２５には、本発明を実現するために新規機能を搭載する必要がない。一方、図２２の構成においては、ＵＥ１０の処理動作は、図２０のＵＥ１０と同様である。そのため、ＵＥ１０には、本発明を実現するために新規機能を搭載する必要がない。
【００９６】
続いて、図２４を用いて、本発明の実施の形態２にかかるネットワークにおけるＡＴＴＡＣＨ処理の流れについて説明する。はじめに、ＵＥ１０は、ＳＧＳＮ４５へＡＴＴＡＣＨ信号を送信する（Ｓ２０１）。次に、ＵＥ１０とＨＳＳ（Home Subscriber Server）との間でＵＥ１０の認証動作とセキュリティ設定が行われる（Ｓ２０２）。次に、ＳＧＳＮ４５は、ＨＳＳへUpdate Location request信号を送信する（Ｓ２０３）。次に、ＨＳＳは、ＳＧＳＮ４５へInsert subscriber data信号を送信する（Ｓ２０４）。Insert subscriber data信号には、ＡＰＮ単位に設定されているpseudo-U/Size attributionが含まれる。pseudo-U/Size attributionは、ＡＰＮ単位以外にも、ＩＭＳＩ単位もしくはＩＭＥＩＳＶ単位等に設定されてもよい。
【００９７】
次に、ＳＧＳＮ４５は、ＨＳＳへInsert subscriber data Ack信号を送信する（Ｓ２０５）。次に、ＨＳＳは、ＳＧＳＮ４５へUpdate Location ACK信号を送信する。ＳＧＳＮ４５は、このようにしてＡＰＮ単位等に設定されているpseudo-U attribution情報を取得すると共に管理を行う。次に、ＳＧＳＮ４５は、ＵＥ１０へATTACH accept信号を送信する（Ｓ２０７）。
【００９８】
続いて、図２５を用いて、PDP Context Activation処理の流れについて説明する。PDP Contextは、ＳＧＳＮ４５及びＧＧＳＮ５５の間においてユーザデータを伝送するために用いられる通信リソースである。また、本図においては、ユーザデータとして少量データが伝送される例について説明する。
【００９９】
はじめに、ＵＥ１０は、ＳＧＳＮ４５へActivate PDP Context Request(APN)信号を送信する（Ｓ２１１）。次に、ＳＧＳＮ４５は、ＧＧＳＮ５５へＰＵ ｆｌａｇを含むCreate PDP Context Request信号を送信する（Ｓ２１２）。次に、ＧＧＳＮ５５は、ＳＧＳＮ４５へＰＵ ｓｔａｔｕｓ１を含むCreate PDP Context Response信号を送信する（Ｓ２１３）。このようにしてＰＵ ｓｔａｔｕｓ１をＳＧＳＮ４５及びＧＧＳＮ５５において共有することにより、ＳＧＳＮ４５及びＧＧＳＮ５５の間にPseudo-U treatment(1)が設定される（Ｓ２１４）。
【０１００】
次に、ＲＮＣ２５及びＳＧＳＮ４５の間にpseudo-Uベアラを設定するために、ＳＧＳＮ４５は、ＲＮＣ２５へＰＵ ｆｌａｇを含むRAB assignment Request信号を送信する（Ｓ２１５）。次に、ＲＮＣ２５は、ＵＥ１０との間においてRadioベアラ（無線ベアラ）を設定する（Ｓ２１６）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へＰＵ ｓｔａｔｕｓ２を含むRAB assignment Response信号を送信する（Ｓ２１７）。このようにしてＰＵ ｓｔａｔｕｓ２をＲＮＣ２５及びＳＧＳＮ４５において共有することにより、ＲＮＣ２５及びＳＧＳＮ４５の間にPseudo-U treatment(2)（Ｓ２１８）が設定される。次に、ＳＧＳＮ４５は、ＵＥ１０へActivate PDP Context Accept信号を送信する（Ｓ２１９）。
【０１０１】
続いて、図２６を用いて、ＳＧＳＮの変更を伴うＲＡＵ（Routing Area Update）処理の流れについて説明する。Routing Area（RA）は、ＧＰＲＳネットワーク上で管理されるＵＥ１０の位置情報である。ＲＡは、複数のセルから構成される領域であってもよい。ＲＡＵは、ＵＥ１０が位置するＲＡが変更される際に実行される処理である。
【０１０２】
はじめに、ＵＥ１０は、変更後のＲＡを管理するＳＧＳＮ（以下、Ｎｅｗ ＳＧＳＮ）へＲＡＵ信号を送信する（Ｓ２２１）。次に、Ｎｅｗ ＳＧＳＮは、変更前のＲＡを管理するＳＧＳＮ（以下、Ｏｌｄ ＳＧＳＮ）へSGSN Context request信号を送信する（Ｓ２２２）。次に、Ｏｌｄ ＳＧＳＮは、Ｎｅｗ ＳＧＳＮへSGSN Context response信号を送信する（Ｓ２２３）。SGSN Context response信号には、ＵＥ１０に関連付けられているpseudo-U/Size attributionが含まれる。次に、ＵＥ１０とＨＳＳ（Home Subscriber Server）との間でＵＥ１０の認証動作とセキュリティ設定が行われる（Ｓ２２４）。
【０１０３】
次に、Ｎｅｗ ＳＧＳＮは、Ｏｌｄ ＳＧＳＮへSGSN Context Ack信号を送信する（Ｓ２２５）。次に、Ｎｅｗ ＳＧＳＮは、ＧＧＳＮ５５との間にpseudo-Uベアラを設定するために、ＧＧＳＮ５５へUpdate PDP Context Request信号を送信する（Ｓ２２６）。Update PDP Context Request信号には、ＰＵ ｆｌａｇが含まれる。次に、ＧＧＳＮ５５は、Ｎｅｗ ＳＧＳＮへＰＵ ｓｔａｔｕｓ１を含むUpdate PDP Context Response信号を送信する（Ｓ２２７）。これにより、Ｎｅｗ ＳＧＳＮ及びＧＧＳＮ５５の間にPseudo-U treatment(1)が設定される（Ｓ２２８）。
【０１０４】
ステップＳ２２９〜ステップＳ２３２は、図２４におけるステップＳ２０３〜ステップＳ２０６と同様であるため詳細な説明を省略する。ステップＳ２３２においてUpdate Location Ack信号を受信したＮｅｗ ＳＧＳＮは、ＵＥ１０へRAU accept信号を送信する（Ｓ２３３）。
【０１０５】
続いて、図２７及び図２８を用いてＵＥ１０が接続されるＲＮＣ及びＳＧＳＮが変更される場合の処理の流れについて説明する。
【０１０６】
はじめに、変更前のＲＮＣ（以下、Ｏｌｄ ＲＮＣ）は、変更前のＳＧＳＮ（以下、Ｏｌｄ ＳＧＳＮ）へRelocation Required信号を送信する（Ｓ２４１）。次に、Ｏｌｄ ＳＧＳＮは、変更後のＳＧＳＮ（以下、Ｎｅｗ ＳＧＳＮ）へＰＵ ｆｌａｇを含むForward Relocation Request信号を送信する（Ｓ２４２）。次に、Ｎｅｗ ＳＧＳＮは、Ｎｅｗ ＲＮＣへＰＵ ｆｌａｇを含むRelocation Request信号を送信する（Ｓ２４３）。次に、Ｎｅｗ ＲＮＣは、Ｎｅｗ ＳＧＳＮへＰＵ ｓｔａｔｕｓ２を含むRelocation Request Acknowledge信号を送信する（Ｓ２４４）。これにより、Ｎｅｗ ＲＮＣ及びＮｅｗ ＳＧＳＮの間にPseudo-U treatment(2)が設定される（Ｓ２４５）。
【０１０７】
次に、Ｎｅｗ ＳＧＳＮは、Ｏｌｄ ＳＧＳＮへForward Relocation Response信号を送信する（Ｓ２４６）。次に、Ｏｌｄ ＳＧＳＮは、Ｏｌｄ ＲＮＣへRelocation command信号を送信する（Ｓ２４７）。次に、Ｏｌｄ ＲＮＣは、ＵＥ１０へRRC message信号を送信する（Ｓ２４８）。次に、Ｏｌｄ ＲＮＣは、Ｏｌｄ ＳＧＳＮへForward SRNS Context信号を送信する（Ｓ２４９）。次に、Ｏｌｄ ＳＧＳＮは、Ｎｅｗ ＳＧＳＮへForward SRNS Context信号を送信する（Ｓ２５０）。次に、Ｎｅｗ ＳＧＳＮは、ＯｌｄＳＧＳＮへForward SRNS Context Ack信号を送信し（Ｓ２５１）、さらにＮｅｗ ＲＮＣへForward SRNS Context 信号を送信する（Ｓ２５２）。
【０１０８】
図２８に移り、次に、Ｎｅｗ ＲＮＣによってＵＥ１０が検出されると（Ｓ２５３）、Ｎｅｗ ＲＮＣは、Ｎｅｗ ＳＧＳＮへRelocation detect信号を送信する（Ｓ２５４）。次に、ＵＥ１０は、Ｎｅｗ ＲＮＣへRRC message信号を送信する（Ｓ２５５）。次に、Ｎｅｗ ＲＮＣは、Ｎｅｗ ＳＧＳＮへRelocation complete信号を送信する（Ｓ２５６）。次に、Ｎｅｗ ＳＧＳＮは、Ｏｌｄ ＳＧＳＮへForward relocation complete信号を送信する（Ｓ２５７）。次に、Ｏｌｄ ＳＧＳＮは、Ｎｅｗ ＳＧＳＮへForward relocation complete Ack信号を送信する（Ｓ２５８）。次に、Ｎｅｗ ＳＧＳＮは、ＧＧＳＮ５５へＰＵ ｆｌａｇを含むUpdate PDP Context request信号を送信する（Ｓ２５９）。次に、ＧＧＳＮ５５は、Ｎｅｗ ＳＧＳＮへＰＵ ｓｔａｔｕｓ１を含むUpdate PDP Context Response信号を送信する（Ｓ２６０）。これにより、Ｎｅｗ ＳＧＳＮ及びＧＧＳＮ５５の間にPseudo-U treatment(1)が設定される（Ｓ２６１）。
【０１０９】
また、Ｏｌｄ ＳＧＳＮは、Ｏｌｄ ＲＮＣとの間において確保していた通信リソースを解放するために、Ｏｌｄ ＲＮＣへIu release command信号を送信する（Ｓ２６２）。次に、Ｏｌｄ ＲＮＣは、Ｏｌｄ ＳＧＳＮへIu release command complete信号を送信する（Ｓ２６３）。
【０１１０】
次に、図２９を用いて、ＧＧＳＮ５５においてＵＥ１０を宛先とする少量データを受信した場合の処理の流れについて説明する。
【０１１１】
はじめに、ＳＧＳＮ４５及びＧＧＳＮ５５の間には、Pseudo-U treatment(1)が設定されている状態とする（Ｓ２７１）。ＧＧＳＮ５５は、Pseudo-U treatment(1)と関連付けられているＵＥ１０を宛先とする少量データを受信した場合、受信した少量データをＧＴＰ−Ｃを介してＳＧＳＮ４５へ送信する（Ｓ２７２）。次に、ＳＧＳＮ４５は、ＲＮＣ２５へPage信号を送信し（Ｓ２７３）、さらにＲＮＣ２５は、ＵＥ１０へPage信号を送信する（Ｓ２７４）。
【０１１２】
続いて、図３０を用いてＵＥ１０から少量データを送信する場合の処理の流れについて説明する。尚、図３０に示す処理は、図２９においてPage信号を受信したＵＥ１０が実行する処理としても用いられる。
【０１１３】
はじめに、ＵＥ１０は、ＳＧＳＮ４５へService Request信号を送信する（Ｓ２７５）。次に、ＳＧＳＮ４５は、ＲＮＣ２５へＰＵ ｆｌａｇを含むRAB assignment Request信号を送信する（Ｓ２７６）。このRAB assignment Request信号には、少量データが含まれても良い。次に、ＲＮＣ２５は、ＵＥ１０との間に無線ベアラ（Radio bearer）を設定する（Ｓ２７７）。ＲＮＣ２５は、RAB assignment Request信号で受信した少量データを設定された無線ベアラ（Radio bearer）を用いてＵＥ１０に送信しても良い。次に、ＲＮＣ２５は、ＳＧＳＮ４５へＰＵ ｓｔａｔｕｓ２を含むRAB assignment Response信号を送信する（Ｓ２７８）。これにより、ＲＮＣ２５及びＳＧＳＮ４５の間に、Pseudo-U treatment(2)が設定される（Ｓ２７９）。
【０１１４】
続いて、図３１を用いて少量データをＧＴＰ−Ｃを用いて送受信する環境においてＵＥ１０を宛先とする大型データを送受信する場合について説明する。
【０１１５】
ＳＧＳＮ４５及びＧＧＳＮ５５の間に少量データを伝送するためにＧＴＰ−Ｃが設定されている場合に、ＧＧＳＮ５５にＵＥ１０を宛先とする大型データが到着すると、ＧＧＳＮ５５は、ＳＧＳＮ４５との間に新たに大型データを伝送するための専用のベアラ（PDP Context）を設定する。専用ベアラは、pseudoベアラがPrimary PDP Contextとすると、Secondary PDP Contextと称されてもよい。ＧＧＳＮ５５は、専用ベアラを設定するため、ＳＧＳＮ４５へInitiate PDP Context Activation Request信号を送信する（Ｓ２８１）。次に、ＳＧＳＮ４５は、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ２８２）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ２８３）。次に、ＳＧＳＮ４５は、ＧＧＳＮ５５へCreate PDP context Request信号を送信する（Ｓ２８４）。次に、ＧＧＳＮ５５は、ＳＧＳＮ４５へCreate PDP context Response信号を送信する（Ｓ２８５）。次に、ＳＧＳＮ４５は、ＧＧＳＮ５５へInitiate PDP Context Activation Response信号を送信する（Ｓ２８６）。
【０１１６】
このようにして、Create PDP Context Request/Response信号を送信することにより、ＳＧＳＮ４５及びＧＧＳＮ５５の間に大型データを伝送するための専用のベアラを設定し、RAB assignment Request/Response信号を送信することにより、ＲＮＣ２５及びＳＧＳＮ４５の間にも専用のベアラを設定する。この処理を経て、ＧＧＳＮ５５は受信した大型データを専用ベアラを用いてＳＧＳＮ４５に、更にＳＧＳＮ４５はＲＮＣ２５に送信する事が可能となる。
【０１１７】
また、ＳＧＳＮ４５及びＧＧＳＮ５５の間に少量データを伝送するためにＧＴＰ−Ｃが設定されている場合に、ＧＧＳＮ５５に大型データが到着すると、ＧＧＳＮ５５は、ＳＧＳＮ４５及びＧＧＳＮ５５の間にすでに設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕベアラもしくは専用のベアラに変更してもよい。この場合、図３１のステップＳ２８１及びＳ２８６におけるInitiate PDP Context Activation Request信号の代わりに、Update PDP Context Request/Response信号を用いる。また、この場合図３１におけるステップＳ２８４及びステップＳ２８５の処理は省略される。
【０１１８】
また、RAB assignment Request/Response信号は、ＲＮＣ２５及びＳＧＳＮ４５の間にPseudo-U treatment(2)が設定されている場合にのみ伝送される。
【０１１９】
続いて、図３２を用いて少量データをＧＴＰ−Ｃを用いて送受信する環境において、ＵＥ１０から大型データを送信する場合について説明する。少量データを伝送するためにＲＮＣ２５及びＳＧＳＮ４５の間にＲＡＮＡＰが設定され、ＳＧＳＮ４５及びＧＧＳＮ５５の間にＧＴＰ−Ｃが設定されている場合に、ＵＥ１０から大型データを送信するために、ｅＮｏｄｅＢ２０とＰＧＷ５０との間に新たに大型データを伝送するための専用のベアラを設定する。
【０１２０】
はじめに、ＲＮＣ２５がＵＥ１０から大型データを受信した場合、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Request信号を送信する（Ｓ２９１）。次に、ＳＧＳＮ４５は、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ２９２）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ２９３）。次に、ＳＧＳＮ４５は、ＧＧＳＮ５５へCreate PDP Context Request信号を送信する（Ｓ２９４）。次に、ＧＧＳＮ５５は、ＳＧＳＮ４５へCreate PDP Context Response信号を送信する（Ｓ２９５）。
【０１２１】
このようにして、Create PDP Context Request/Response信号を送信することにより、ＳＧＳＮ４５及びＧＧＳＮ５５の間に大型データを伝送するための専用のベアラを設定し、RAB assignment Request/Response信号を送信することにより、ＲＮＣ２５及びＳＧＳＮ４５の間にも専用のベアラを設定する。この処理を経て、ＲＮＣ２５は受信した大型データを専用ベアラを用いてＳＧＳＮ４５に、更にＳＧＳＮ４５はＧＧＳＮ５５に送信する事が可能となる。
【０１２２】
ここで、少量データをＳＧＳＮ４５及びＧＧＳＮ５５の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＳＮ４５及びＲＮＣ２５の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＵＥ１０からＳＧＳＮ４５までは、ＧＴＰ−Ｕベアラを用いて大型データが伝送される。このような場合、ＳＧＳＮ４５及びＧＧＳＮ５５の間においてCreate PDP Context Request/Response信号が送信される。これにより、ＳＧＳＮ４５及びＧＧＳＮ５５の間に専用ベアラが設定あれる。また、この場合、図３２におけるRAB assignment Request/Response信号は、伝送されない。
【０１２３】
また、ＲＮＣ２５及びＳＧＳＮ４５の間に少量データを伝送するためにＲＡＮＡＰが設定され、ＳＧＳＮ４５及びＧＧＳＮ５５の間に少量データを伝送するためにＧＴＰ−Ｃが設定されている場合に、ＲＮＣ２５がＵＥ１０から大型データを受信すると、ＲＮＣ２５とＧＧＳＮ５５との間に、すでに設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕベアラもしくは専用のベアラに変更してもよい。この場合、図３２のステップＳ２９１におけるRAB assignment Request信号の代わりに、RAB modify Request/Response信号を用いる。さらに、図３２のステップＳ２９４及びＳ２９５におけるCreate PDP Context Request/Response信号の代わりに、Update PDP Context Request/Response信号を用いる。これにより、ＲＮＣ２５とＧＧＳＮ５５との間に、すでに設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕベアラもしくは専用のベアラに変更することができる。
【０１２４】
ここで、少量データをＳＧＳＮ４５及びＧＧＳＮ５５の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＳＮ４５及びＲＮＣ２５の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＵＥ１０からＳＧＳＮ４５までは、ＧＴＰ−Ｕベアラを用いて大型データが伝送される。このような場合、ＳＧＳＮ４５からＧＧＳＮ５５の間においてUpdate PDP Context Request/Response信号が送信される。これにより、ＳＧＳＮ４５及びＧＧＳＮ５５の間に設定されていたpseudo-Uベアラを専用ベアラへ変更することができる。また、この場合、図３２におけるRAB assignment Request/Response信号は、伝送されない。
【０１２５】
続いて、図３３を用いて、大型データを伝送するために設定された専用ベアラを削除する場合の処理の流れについて説明する。専用ベアラは、ＲＮＣ２５及びＧＧＳＮ５５の間において大型データの伝送が終了すると削除される。具体的には、大型データが一定時間伝送されないことがＲＮＣ２５もしくはＧＧＳＮ５５において検出された場合に、専用ベアラを削除してもよい。
【０１２６】
はじめに、ＧＧＳＮ５５は、一定時間大型データの伝送が行われていないことを検出すると、ＳＧＳＮ４５へDelete PDP Context Request信号を送信する（Ｓ３０１）。次に、ＲＮＣ２５は、ＲＮＣ２５及びＳＧＳＮ４５の間に設定された専用ベアラを削除するために、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ３０２）。
【０１２７】
次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ３０３）。次に、ＳＧＳＮ４５は、ＧＧＳＮ５５へDelete PDP Context Response信号を送信する（Ｓ３０４）。これにより、ＲＮＣ２５及びＧＧＳＮ５５の間に設定された専用ベアラを削除することができる。
【０１２８】
また、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、ＧＴＰ−Ｕベアラもしくは専用ベアラをpseudo-Uベアラへ戻す場合の処理の流れについて説明する。具体的には、図３３におけるステップＳ３０１及びＳ３０４におけるDelete PDP Context Request/Response信号の代わりに、Update PDP Context Request/Response信号を用いる。これらの信号を用いて、ＧＴＰ−Ｕベアラもしくは専用いベアラを、pseudo-Uベアラへ戻す処理を実行する。
【０１２９】
続いて、図３４を用いて、ＲＮＣ２５が、大型データの伝送が行われていないことを検出した場合に、専用ベアラを削除する場合の処理の流れについて説明する。はじめに、ＲＮＣ２５は、一定時間大型データの伝送が行われていないことを検出すると、ＳＧＳＮ４５へRAB Release Request信号を送信する（Ｓ３１１）。
【０１３０】
次に、ＳＧＳＮ４５は、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ３１２）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ３１３）。次に、ＳＧＳＮ４５は、ＧＧＳＮ５５へDelete PDP Context Request信号を送信する（Ｓ３１４）。次に、ＧＧＳＮ５５は、ＳＧＳＮ４５へDelete PDP Context Response信号を送信する（Ｓ３１５）。
【０１３１】
このようにして、Delete PDP Context Request/Response信号を送信することにより、ＳＧＳＮ４５及びＧＧＳＮ５５の間の大型データを伝送するための専用ベアラを削除し、RAB assignment Request/Response信号を送信することにより、ＲＮＣ２５及びＳＧＳＮ４５の間の専用のベアラを削除する。
【０１３２】
また、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、pseudo-Uベアラへ戻す処理の流れについて説明する。具体的には、図３３におけるステップＳ３１１におけるRAB Release Request信号の代わりに、RAB modify Request信号を用いる。さらに、図３３のステップＳ３１４及びＳ３１５におけるDelete PDP Context Request/Response信号の代わりに、Update PDP Context Request/Response信号を用いる。これらの信号を用いて、ＧＴＰ−Ｕベアラもしくは専用ベアラを、pseudo-Uベアラへ戻す処理を実行する。
【０１３３】
ここで、少量データをＳＧＳＮ４５及びＧＧＳＮ５５の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＳＮ４５及びＲＮＣ２５の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＳＧＳＮ４５において、大型データの伝送が行われていないことが検出されてもよい。この場合、ＳＧＳＮ４５及びＧＧＳＮ５５の間においてDelete PDP Context Request/Response信号が伝送されることによって、ＳＧＳＮ４５及びＧＧＳＮ５５の間の専用ベアラを削除することができる。図３４におけるRAB Release Request信号及びRAB assignment Request/Response信号は、伝送されない。
【０１３４】
さらに、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、pseudo-Uベアラへ戻す処理の流れについて説明する。ここでは、ＳＧＳＮ４５において大型データの伝送終了を検出した場合の処理について説明する。この場合、ＳＧＳＮ４５及びＧＧＳＮ５５の間において、Update PDP Context Request/Response信号を伝送することにより、ＧＴＰ−Ｕベアラもしくは専用ベアラをpseudo-Uベアラへ戻す処理を実行する。
【０１３５】
以上説明したように、本発明の実施の形態３にかかる移動通信システムを用いることにより、ＲＮＣ２５及びＧＧＳＮ５５の間に通信リソースの確保を必要としないpseudo-Uベアラを設定することができる。これにより、少量データの伝送にＧＴＰ−Ｕベアラを用いる場合と同様の処理の流れを用いて、ＧＴＰ−Ｃ及びＲＡＮＡＰ等の制御信号を伝送するために用いられる通信リソースを利用して、少量データを伝送することができる。
【０１３６】
（実施の形態４）
続いて、図３５を用いて本発明の実施の形態４にかかるＡＴＴＣＨ処理の流れについて説明する。実施の形態４において説明するネットワークは、アクセスネットワークに、３Ｇアクセスとして用いられるＲＮＣ２５を有し、コアネットワークにＥＰＣとして用いられるＳＧＷ４０及びＰＧＷ５０を有する。さらに、アクセスネットワークとコアネットワークとの間にはＳＧＳＮ４５を配置する。ＲＮＣ２５には、少量データを送受信するＵＥ１０が接続されている。以下の説明においてもこのようなネットワーク構成を前提として説明を行う。
【０１３７】
図３５におけるステップＳ３２１〜ステップＳ３２７は、図５におけるステップＳ１〜Ｓ７と同様であるため詳細な説明を省略する。但し、図３５においては、図５のＭＭＥ３０の代わりにＳＧＳＮ４５が用いられている。さらに、図３５におけるステップＳ３２８〜ステップＳ３３１は、図２５におけるステップＳ２１５〜ステップＳ２１８と同様であるため詳細な説明を省略する。ステップＳ３３１においてPseudo-U treatment(2)が設定されると、ＳＧＳＮ４５は、ＳＧＷ４０へModify bearer request信号を送信する（Ｓ３３２）。Modify bearer request信号は、ＰＵ ｆｌａｇ及びＰＵ ｓｔａｔｕｓ２を含んでいる。次に、ＳＧＷ４０は、ＳＧＳＮ４５へModify bearer response信号を送信する（Ｓ３３３）。次に、ＳＧＳＮ４５は、ＵＥ１０へATTACH accept信号を送信する（Ｓ３３４）。
【０１３８】
ここで、図３５におけるPseudo-U treatment(2)は、ＲＮＣ２５、ＳＧＳＮ４５及びＳＧＷ４０の間に設定されてもよく、ＳＧＳＮ４５を介さずにＲＮＣ２５及びＳＧＳＮ４５の間に設定されてもよい。以下の説明においても同様である。
【０１３９】
続いて、図３６を用いて、ＳＧＳＮ及びＳＧＷの変更を伴うＲＡＵ（Routing Area Update）処理の流れについて説明する。ステップＳ３４１〜ステップＳ３４５は、図２６におけるステップＳ２２１〜ステップＳ２２５と同様であるため詳細な説明を省略する。また、ステップＳ３４６〜ステップＳ３５２は、図６におけるステップＳ２６〜ステップＳ３２と同様であるため詳細な説明を省略する。ただし、図３６においては、図６におけるＭＭＥの代わりにＳＧＳＮが用いられている。ステップＳ３５２において、Update Location Ack信号を受信したＮｅｗ ＳＧＳＮは、ＵＥ１０へRAU accept信号を送信する（Ｓ３５３）。
【０１４０】
続いて、図３７を用いてＵＥ１０から少量データを送信する場合の処理の流れについて説明する。図３７におけるステップＳ３６１〜ステップＳ３６５は、図３０におけるステップＳ２７５〜ステップＳ２７９と同様であるため詳細な説明を省略する。また、図３７におけるステップＳ３６６及びステップＳ３６７は、図３５におけるステップＳ３３２及びステップＳ３３３と同様であるため詳細な説明を省略する。
【０１４１】
続いて、図３８及び図３９を用いて、ハンドオーバ処理の流れについて説明する。図３８及び図３９は、図８及び図９におけるＯｌｄ ｅＮＢ及びＮｅｗ ｅＮＢの代わりにＯｌｄ ＲＮＣ及びＮｅｗ ＲＮＣが用いられ、さらに、図８及び図９におけるＯｌｄ ＭＭＥ及びＮｅｗ ＭＭＥの代わりにＯｌｄ ＳＧＳＮ及びＮｅｗ ＳＧＳＮが用いられている。また、図３８及び図３９におけるステップＳ３７１〜ステップＳ３８９は、図８及び図９におけるステップＳ５１〜ステップＳ６９と同様であるため詳細な説明を省略する。
【０１４２】
続いて、図４０を用いてＰＧＷ５０においてＵＥ１０を宛先とする少量データを受信した場合に処理の流れについて説明する。図４０は、図１０におけるＭＭＥの代わりにＳＧＳＮが用いられ、図１０におけるｅＮＢの代わりにＲＮＣが用いられている。図４０におけるステップＳ３９１〜ステップＳ３９５は、図１０におけるステップＳ７１〜ステップＳ７５と同様であるため詳細な説明を省略する。
【０１４３】
続いて、図４１を用いてＵＥ１０から少量データを送信する場合の処理の流れについて説明する。なお、図４１に示す処理は、図４０においてPage信号を受信したＵＥ１０が実行する処理としても用いられる。
【０１４４】
はじめに、ＵＥ１０は、ＳＧＳＮ４５へService Request信号を送信する（Ｓ４０１）。次に、ＵＥ１０とＨＳＳ（Home Subscriber Server）との間でＵＥ１０の認証動作とセキュリティ設定が行われる（Ｓ４０２）。次に、ＳＧＳＮ４５は、ＲＮＣ２５へＰＵ ｆｌａｇを含むRAB assignment Request信号を送信する（Ｓ４０３）。次に、ＲＮＣ２５は、ＵＥ１０との間に無線ベアラ（Radio bearer）を設定する（Ｓ４０４）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へＰＵ ｓｔａｔｕｓ２を含むRAB assignment Response信号を送信する（Ｓ４０５）。これにより、ＲＮＣ２５及びＳＧＷ４０の間に、Pseudo-U treatment(2)が設定される（Ｓ４０６）。
【０１４５】
続いて、図４２を用いて少量データをＧＴＰ−Ｃを用いて送受信する環境において、少量データを送受信するＵＥ１０を宛先とする大型データを送受信する場合について説明する。
【０１４６】
ＳＧＷ４０及びＰＧＷ５０の間に少量データを伝送するためにＧＴＰ−Ｃが設定されている場合に、ＰＧＷ５０に大型データが到着すると、ＰＧＷ５０は、ＳＧＷ４０との間に新たに大型データを伝送するための専用のベアラを設定する。そのため、ＰＧＷ５０は、ＳＧＷ４０へCreate Bearer Request信号を送信する。さらに、ＳＧＷ４０は、ＳＧＳＮ４５へCreate Bearer Request信号を送信する（Ｓ４１１）。次に、ＳＧＳＮ４５は、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ４１２）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ４１３）。次に、ＳＧＳＮ４５は、ＳＧＷ４０へCreate Bearer Response信号を送信する。さらに、ＳＧＷ４０は、ＰＧＷ５０へCreate Bearer Response信号を送信する（Ｓ４１４）。
【０１４７】
このようにして、Create Bearer Request/Response信号を送受信することにより、ＳＧＷ４０及びＰＧＷ５０の間に大型データを伝送するための専用のベアラを設定し、RAB assignment Request/Response信号を送受信することにより、ＲＮＣ２５及びＳＧＳＮ４５並びにＳＧＳＮ４５及びＳＧＷ４０の間にも専用のベアラを設定する。もしくは、ＲＮＣ２５及びＳＧＷ４０の間に専用ベアラが設定されてもよい。この処理を経て、ＰＧＷ５０は受信した大型データを専用ベアラを用いてＳＧＷ４０に、更にＳＧＷ４０はＲＮＣ２５に、またはＳＧＳＮ４５を経由してＲＮＣ２５に送信する事が可能となる。
【０１４８】
また、ＳＧＷ４０及びＰＧＷ５０の間に少量データを伝送するためにＧＴＰ−Ｃが設定されている場合に、ＰＧＷ５０に大型データが到着すると、ＰＧＷ５０は、すでに設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕベアラもしくは専用のベアラに変更してもよい。この場合、図４２のステップＳ４１１及びＳ４１４におけるCreate Bearer Request/Response信号の代わりに、Update Bearer Request/Response信号を用いる。
【０１４９】
また、図４２のステップＳ４１２及びＳ４１３のRAB assignment Request/Response信号は、ＲＮＣ２５及びＳＧＳＮ４５の間にPseudo-U treatment(2)が設定されている場合にのみ伝送される。
【０１５０】
続いて、図４３を用いて、少量データをＧＴＰ−ＣもしくはＲＡＮＡＰを用いて送受信する環境において、ＵＥ１０から大型データを送信する場合について説明する。
【０１５１】
少量データを伝送するためにＲＮＣ２５及びＳＧＳＮ４５の間にＲＡＮＡＰが設定され、ＳＧＳＮ４５及びＰＧＷ５０の間にＧＴＰ−Ｃが設定されている場合に、ＵＥ１０から大型データを送信するために、ＲＮＣ２５とＰＧＷ５０との間に新たに大型データを伝送するための専用のベアラを設定する。
【０１５２】
はじめに、ＲＮＣ２５がＵＥ１０から大型データを受信した場合、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Request信号を送信する（Ｓ４２１）。次に、ＳＧＳＮ４５は、ＳＧＷ４０へBearer Resource Command信号を送信し、さらにＳＧＷ４０は、ＰＧＷ５０へBearer Resource Command信号を送信する（Ｓ４２２）。次に、ＰＧＷ５０は、ＳＧＷ４０へCreate Bearer Request信号を送信し、さらにＳＧＷ４０は、ＳＧＳＮ４５へCreate Bearer Request信号を送信する（Ｓ４２３）。
【０１５３】
次に、ＳＧＳＮ４５は、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ４２４）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ４２５）。次に、ＳＧＳＮ４５は、ＳＧＷ４０へCreate Bearer Response信号を送信し、さらにＳＧＷ４０はＰＧＷ５０へCreate Bearer Response信号を送信する（Ｓ４２６）。
【０１５４】
このようにして、Create Bearer Request/Response信号を送信することにより、ＳＧＷ４０及びＰＧＷ５０の間に大型データを伝送するための専用のベアラを設定し、Bearer Setup Request/Response信号を送信することにより、ＲＮＣ２５及びＳＧＳＮ４５並びにＳＧＳＮ４５及びＳＧＷ４０の間にも専用のベアラを設定する。もしくは、Bearer Setup Request/Response信号を送信することにより、ＲＮＣ２５及びＳＧＷ４０の間に専用ベアラを設定してもよい。この処理を経て、ＲＮＣ２５は受信した大型データを専用ベアラを用いてＳＧＷ４０に、またはＳＧＳＮ４５を経由してＳＧＷ４０に、更にＳＧＷ４０はＰＧＷ５０に送信する事が可能となる。
【０１５５】
ここで、少量データをＳＧＳＮ４５及びＰＧＷ５０の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＳＮ４５及びＲＮＣ２５の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＵＥ１０からＳＧＳＮ４５までは、ＧＴＰ−Ｕベアラを用いて大型データが伝送される。このような場合、ＳＧＳＮ４５からＰＧＷ５０へBearer Resource Command信号が送信される。さらに、ＰＧＷ５０及びＳＧＳＮ４５の間において、Create Bearer Request/Response信号が伝送される。これにより、ＳＧＳＮ４５及びＰＧＷ５０の間に専用ベアラが設定される。また、この場合、図４３におけるRAB assignment Request/Response信号は、伝送されない。
【０１５６】
また、ＲＮＣ２５及びＰＧＷ５０の間に少量データを伝送するためにＧＴＰ−Ｃ及びＲＡＮＡＰが設定されている場合に、ＲＮＣ２５がＵＥ１０から大型データを受信すると、ＲＮＣ２５とＰＧＷ５０との間に、すでに設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕベアラもしくは専用のベアラに変更してもよい。この場合、図４３のステップＳ４２３及びＳ４２６におけるCreate Bearer Request/Response信号の代わりに、Modify Bearer Request/Response信号を用いる。
【０１５７】
ここで、少量データをＳＧＷ４０及びＰＧＷ５０の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＷ４０及びｅＮｏｄｅＢ２０の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＵＥ１０からＳＧＷ４０までは、ＧＴＰ−Ｕベアラを用いて大型データが伝送される。このような場合、ＳＧＷ４０及びＰＧＷ５０の間にすでに設定されているpseudo-Uベアラを通常のＧＴＰ−Ｕもしくは専用のベアラに変更してもよい。この場合、ＳＧＷ４０からＰＧＷ５０へBearer Resource Command信号が送信される。さらに、ＰＧＷ５０及びＭＭＥ３０の間において、Modify Bearer Request/Response信号が伝送される。また、この場合に、図４３におけるRAB assignment Request/Response信号は、伝送されない。
【０１５８】
続いて、図４４を用いて、大型データを伝送するために設定された専用ベアラを削除する場合の処理の流れについて説明する。専用ベアラは、ＲＮＣ２５及びＰＧＷ５０の間において大型データの伝送が終了すると削除される。具体的には、大型データが一定時間伝送されないことがＲＮＣ２５もしくはＰＧＷ５０において検出された場合に、専用ベアラを削除してもよい。
【０１５９】
はじめに、ＰＧＷ５０は、一定時間大型データの伝送が行われていないことを検出すると、ＳＧＷ４０へDelete Bearer Request信号を送信し、さらに、ＳＧＷ４０は、ＳＧＳＮ４５へDelete Bearer Request信号を送信する（Ｓ４３１）。次に、ＳＧＳＮ４５は、ＲＮＣ２５、ＳＧＳＮ４５及びＳＧＷ４０又はＲＮＣ２５及びＳＧＷ４０の間に設定された専用ベアラを削除するために、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ４３２）。
【０１６０】
次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ４３３）。次に、ＳＧＳＮ４５は、ＳＧＷ４０へDelete Bearer Response信号を送信し、さらに、ＳＧＷ４０は、ＰＧＷ５０へDelete Bearer Response信号を送信する（Ｓ４３４）。これにより、ＲＮＣ２５及びＰＧＷ５０の間に設定された専用ベアラを削除することができる。
【０１６１】
また、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、ＧＴＰ−Ｕベアラもしくは専用ベアラをpseudo-Uベアラへ戻す処理の流れについて説明する。具体的には、図４４におけるステップＳ４３１及びＳ４３４におけるDelete Bearer Request/Response信号の代わりに、Update Bearer Request/Response信号を用いる。このようにして、ＧＴＰ−Ｕベアラもしくは専用ベアラを、pseudo-Uベアラへ戻す処理を実行する。
【０１６２】
続いて、図４５を用いて、ＲＮＣ２５が、大型データの伝送が行われていないことを検出した場合に、専用ベアラを削除する場合の処理の流れについて説明する。はじめに、ＲＮＣ２５は、一定時間大型データの伝送が行われていないことを検出すると、ＳＧＳＮ４５へRAB Release Request信号を送信する（Ｓ４４１）。
【０１６３】
次に、ＳＧＳＮ４５は、ＳＧＷ４０へDelete Bearer Command信号を送信し、さらに、ＳＧＷ４０は、ＰＧＷ５０へDelete Bearer Command信号を送信する（Ｓ４４２）。次に、ＰＧＷ５０は、ＳＧＷ４０へDelete Bearer Request信号を送信し、さらにＳＧＷ４０は、ＳＧＳＮ４５へDelete Bearer Request信号を送信する（Ｓ４４３）。次に、ＳＧＳＮ４５は、ＲＮＣ２５へRAB assignment Request信号を送信する（Ｓ４４４）。次に、ＲＮＣ２５は、ＳＧＳＮ４５へRAB assignment Response信号を送信する（Ｓ４４５）。次に、ＳＧＳＮ４５は、ＳＧＷ４０へDelete Bearer Response信号を送信し、さらにＳＧＷ４０は、ＰＧＷ５０へDelete Bearer Response信号を送信する（Ｓ４４６）。
【０１６４】
このようにして、Delete Bearer Request/Response信号を送信することにより、ＳＧＷ４０及びＰＧＷ５０の間の大型データを伝送するための専用ベアラを削除し、Deactivate Bearer Request/Response信号を送信することにより、ＲＮＣ２５、ＳＧＳＮ４５及びＳＧＷ４０又はＲＮＣ２５及びＳＧＷ４０の間の専用のベアラを削除する。
【０１６５】
また、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、pseudo-Uベアラへ戻す処理の流れについて説明する。具体的には、図４５におけるステップＳ４４３及びＳ４４６におけるDelete Bearer Request/Response信号の代わりに、Modify Bearer Request/Response信号を用いる。この信号を用いて、ＧＴＰ−Ｕベアラもしくは専用ベアラを、pseudo-Uベアラへ戻す処理を実行する。
【０１６６】
ここで、少量データをＳＧＳＮ４５及びＰＧＷ５０の間ではＧＴＰ−Ｃベアラを用いて伝送し、ＳＧＳＮ４５及びＲＮＣ２５の間においては、ＧＴＰ−Ｕベアラを用いて伝送する場合、ＳＧＳＮ４５において、大型データの伝送が行われていないことが検出されてもよい。この場合、専用ベアラを削除するために、ＳＧＳＮ４５からＰＧＷ５０へDelete Bearer Command信号が送信される。さらに、ＰＧＷ５０及びＳＧＳＮ４５の間において、Delete Bearer Request/Response信号が伝送される。また、この場合、図４５におけるDeactivate Bearer Request/Response信号は、伝送されない。
【０１６７】
さらに、大型データを伝送するために、pseudo-UベアラをＧＴＰ−Ｕベアラもしくは専用ベアラへ変更していた場合に、大型データの伝送終了に伴い、pseudo-Uベアラへ戻す処理の流れについて説明する。ここでは、ＳＧＳＮ４５において大型データの伝送終了を検出した場合の処理について説明する。この場合、ＳＧＳＮ４５及びＧＧＳＮ５５の間において、Modify Bearer Request/Response信号を伝送することにより、ＧＴＰ−Ｕベアラもしくは専用ベアラをpseudo-Uベアラへ戻す処理を実行する。
【０１６８】
以上説明したように、本発明の実施の形態４にかかる移動通信システムを用いることにより、ＲＮＣ２５及びＰＧＷ５０の間に通信リソースの確保を必要としないpseudo-Uベアラを設定することができる。これにより、少量データの伝送にＧＴＰ−Ｕベアラを用いる場合と同様の処理の流れを用いて、ＧＴＰ−Ｃ、Ｓ１−ＡＰもしくはＲＡＮＡＰ等の制御信号を伝送するために用いられる通信リソースを利用して、少量データを伝送することができる。
【０１６９】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
【０１７０】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１７１】
この出願は、２０１２年９月１２日に出願された日本出願特願２０１２−２００７３１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０１７２】
１０  ＵＥ
２０  ｅＮｏｄｅＢ
２５  ＲＮＣ
３０  ＭＭＥ
４０  ＳＧＷ
４５  ＳＧＳＮ
５０  ＰＧＷ
５５  ＧＧＳＮ
【図１】
2014041805.tif 000003
【図２】
2014041805.tif 000004
【図３】
2014041805.tif 000005
【図４】
2014041805.tif 000006
【図５】
2014041805.tif 000007
【図６】
2014041805.tif 000008
【図７】
2014041805.tif 000009
【図８】
2014041805.tif 000010
【図９】
2014041805.tif 000011
【図１０】
2014041805.tif 000012
【図１１】
2014041805.tif 000013
【図１２】
2014041805.tif 000014
【図１３】
2014041805.tif 000015
【図１４】
2014041805.tif 000016
【図１５】
2014041805.tif 000017
【図１６】
2014041805.tif 000018
【図１７】
2014041805.tif 000019
【図１８】
2014041805.tif 000020
【図１９】
2014041805.tif 000021
【図２０】
2014041805.tif 000022
【図２１】
2014041805.tif 000023
【図２２】
2014041805.tif 000024
【図２３】
2014041805.tif 000025
【図２４】
2014041805.tif 000026
【図２５】
2014041805.tif 000027
【図２６】
2014041805.tif 000028
【図２７】
2014041805.tif 000029
【図２８】
2014041805.tif 000030
【図２９】
2014041805.tif 000031
【図３０】
2014041805.tif 000032
【図３１】
2014041805.tif 000033
【図３２】
2014041805.tif 000034
【図３３】
2014041805.tif 000035
【図３４】
2014041805.tif 000036
【図３５】
2014041805.tif 000037
【図３６】
2014041805.tif 000038
【図３７】
2014041805.tif 000039
【図３８】
2014041805.tif 000040
【図３９】
2014041805.tif 000041
【図４０】
2014041805.tif 000042
【図４１】
2014041805.tif 000043
【図４２】
2014041805.tif 000044
【図４３】
2014041805.tif 000045
【図４４】
2014041805.tif 000046
【図４５】
2014041805.tif 000047
【手続補正書】
【提出日】平成27年12月10日(2015.12.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
基地局との間においてユーザデータを伝送する第１のゲートウェイ装置と、
前記第１のゲートウェイ装置と外部ネットワークとの間において前記ユーザデータを伝送する第２のゲートウェイ装置と、を備え、
前記基地局は、
端末装置から自律的に送信される少量データを、ユーザデータを伝送する通信リソースを介して受信し、さらに、前記少量データを、制御信号を伝送する通信リソースもしくはユーザデータを伝送する通信リソースを用いて前記第１のゲートウェイ装置へ送信し、
前記第１のゲートウェイ装置及び前記第２のゲートウェイ装置は、
前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間において、端末装置から前記基地局を介して自律的に送信される前記少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、移動通信システム。
【請求項２】
前記端末装置はマシンタイプであることを特徴とする、請求項１に記載の移動通信システム。
【請求項３】
前記第１のゲートウェイ装置は、
前記端末装置から送信されたデータが前記少量データか否かを判定し、前記少量データであると判定した場合に、前記端末装置から送信されたデータを前記制御信号を伝送する通信リソースを用いて、前記第２のゲートウェイ装置へ送信することを特徴とする、請求項１又は２に記載の移動通信システム。
【請求項４】
前記第１のゲートウェイ装置は、
前記端末装置から送信されたデータが前記少量データではないと判定した場合、前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間に前記ユーザデータを伝送するために用いられる通信リソースを設定することを特徴とする、請求項１乃至３のいずれか１項に記載の移動通信システム。
【請求項５】
前記第２のゲートウェイ装置は、
前記端末装置を宛先とするデータが前記少量データか否かを判定し、前記少量データであると判定した場合に、前記端末装置を宛先とするデータを前記制御信号を伝送する通信リソースを用いて、前記第１のゲートウェイ装置へ送信することを特徴とする、請求項１乃至４のいずれか１項に記載の移動通信システム。
【請求項６】
前記第２のゲートウェイ装置は、
前記端末装置を宛先とするデータが前記少量データではないと判定した場合、前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間に前記ユーザデータを伝送するために用いられる通信リソースを設定することを特徴とする、請求項１乃至５のいずれか１項に記載の移動通信システム。
【請求項７】
前記第１のゲートウェイ装置及び前記第２のゲートウェイ装置は、
加入者データを管理するサービス制御装置から、前記端末装置が、前記少量データを伝送するか否かに関する情報を取得することを特徴とする、請求項１乃至６のいずれか１項に記載の移動通信システム。
【請求項８】
前記第１のゲートウェイ装置及び前記第２のゲートウェイ装置は、
前記端末装置の位置登録処理を実行する際に、前記移動通信システム内における呼処理制御を行う呼処理制御装置から、前記ユーザデータを伝送する通信リソースの確保を指示された場合、実質的に通信リソースを確保しない疑似的な前記ユーザデータを伝送する通信リソースの確保処理を実行することを特徴とする、請求項１乃至７のいずれか１項に記載の移動通信システム。
【請求項９】
前記第１のゲートウェイ装置は、
前記端末装置から送信されたデータが前記少量データではないと判定した場合、前記疑似的に確保した前記ユーザデータを伝送する通信リソースを、前記端末装置から送信されたデータを伝送するために用いられる通常の通信リソースに変更することを特徴とする、請求項８に記載の移動通信システム。
【請求項１０】
前記第２のゲートウェイ装置は、
前記端末装置を宛先とするデータが前記少量データではないと判定した場合、前記疑似的に確保した前記ユーザデータを伝送する通信リソースを、前記端末装置から送信されたデータを伝送するために用いられる通常の通信リソースに変更することを特徴とする、請求項８に記載の移動通信システム。
【請求項１１】
前記第１のゲートウェイ装置は、３ＧＰＰにおいて規定されるＳＧＷ（Serving Gateway）であり、前記第２のゲートウェイ装置は、３ＧＰＰにおいて規定されるＰＧＷ（Packet Data Network Gateway）である、請求項１乃至１０のいずれか１項に記載の移動通信システム。
【請求項１２】
前記第１のゲートウェイ装置は、３ＧＰＰにおいて規定されるＳＧＳＮ（Serving GPRS Support Node）であり、前記第２のゲートウェイ装置は、３ＧＰＰにおいて規定されるＧＧＳＮ（Gateway GPRS Support Node）である、請求項１乃至１０のいずれか１項に記載の移動通信システム。
【請求項１３】
基地局との間においてユーザデータを伝送する第１のゲートウェイ装置と、外部ネットワークとの間において前記ユーザデータを伝送する第２のゲートウェイ装置との間のデータ通信方法であって、
前記基地局が、端末装置から自律的に送信される少量データを、ユーザデータを伝送する通信リソースを介して受信し、さらに、前記少量データを、制御信号を伝送する通信リソースもしくはユーザデータを伝送する通信リソースを用いて前記第１のゲートウェイ装置へ送信し、
前記第１のゲートウェイ装置と前記第２のゲートウェイ装置との間において、端末装置から前記基地局を介して自律的に送信される前記少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、データ通信方法。
【請求項１４】
基地局と外部ネットワークとの間においてユーザデータを伝送するゲートウェイ装置であって、
端末装置から自律的に送信される少量データがユーザデータを伝送する通信リソースを介して前記基地局へ送信され、さらに、前記基地局から、制御信号を伝送する通信リソースもしくはユーザデータを伝送する通信リソースを介して送信される前記少量データをユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、ゲートウェイ装置。
【請求項１５】
端末装置とゲートウェイ装置との間においてユーザデータを伝送する基地局であって、
前記端末装置から自律的に送信される少量データをユーザデータを伝送する通信リソースを介して受信し、さらに、前記少量データを、ユーザデータを伝送する通信リソースではなく制御信号を伝送する通信リソースを用いて伝送することを特徴とする、基地局。
【国際調査報告】
2014041805.tif 000048
2014041805.tif 000049
2014041805.tif 000050
2014041805.tif 000051