JP2020036371A - 通信システム - Google Patents

通信システム Download PDF

Info

Publication number
JP2020036371A
JP2020036371A JP2019217724A JP2019217724A JP2020036371A JP 2020036371 A JP2020036371 A JP 2020036371A JP 2019217724 A JP2019217724 A JP 2019217724A JP 2019217724 A JP2019217724 A JP 2019217724A JP 2020036371 A JP2020036371 A JP 2020036371A
Authority
JP
Japan
Prior art keywords
enb
rrc
message
keep alive
monitoring
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.)
Granted
Application number
JP2019217724A
Other languages
English (en)
Other versions
JP6860644B2 (ja
Inventor
望月　満
Mitsuru Mochizuki
満 望月
前田　美保
Miho Maeda
美保 前田
晋介 宇賀
Shinsuke Uga
晋介 宇賀
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.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
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 Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Publication of JP2020036371A publication Critical patent/JP2020036371A/ja
Priority to JP2021052795A priority Critical patent/JP2021101583A/ja
Application granted granted Critical
Publication of JP6860644B2 publication Critical patent/JP6860644B2/ja
Priority to JP2022186225A priority patent/JP2023018061A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/02—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration by periodical registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/25—Maintenance of established connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/045—Public Land Mobile systems, e.g. cellular systems using private Base Stations, e.g. femto Base Stations, home Node B

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】処理負荷および消費電力を抑えて、通信端末装置の状態を確認することができる通信システムを提供する。【解決手段】通信システムは、ネットワークに接続される基地局装置と、基地局装置に無線通信可能に接続される通信端末装置とを備える。基地局装置と通信端末装置との間で、通信端末装置の状態を確認するためのモニタリング用メッセージを、予め定めるモニタリング周期で送受信し、基地局装置は、通信端末装置が検出されたかどうかを、モニタリング用メッセージが周辺基地局装置によって、予め定めるモニタリング周期内に受信されたかどうかに基づいて、判断する。【選択図】図１４

Description

本発明は、通信システムに関する。
第３世代と呼ばれる通信方式のうち、Ｗ−ＣＤＭＡ（Wideband Code division Multiple Access）方式が、２００１年から日本で商用サービスが開始されている。また、下りリンク（個別データチャネル、個別制御チャネル）にパケット伝送用のチャネル（High Speed-Downlink Shared Channel：ＨＳ−ＤＳＣＨ）を追加することにより、下りリンクを用いたデータ送信の更なる高速化を実現するＨＳＤＰＡ（High Speed Downlink Packet Access）のサービスが開始されている。さらに、上り方向のデータ送信をより高速化するために、ＨＳＵＰＡ（High Speed Uplink Packet Access）方式についてもサービスが開始されている。Ｗ−ＣＤＭＡは、移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）により定められた通信方式であり、リリース１０版の規格書がとりまとめられている。
また、３ＧＰＰにおいて、Ｗ−ＣＤＭＡとは別の通信方式として、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される新たな通信方式が検討されている。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。
ＬＴＥでは、アクセス方式、無線のチャネル構成やプロトコルが、Ｗ−ＣＤＭＡ（ＨＳＤＰＡ／ＨＳＵＰＡ）とは全く異なるものになる。例えば、アクセス方式は、Ｗ−ＣＤＭＡが符号分割多元接続（Code Division Multiple Access）を用いているのに対して、ＬＴＥは下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ−ＦＤＭＡ（Single Career Frequency Division Multiple Access）を用いる。また、帯域幅は、Ｗ−ＣＤＭＡが５ＭＨｚであるのに対し、ＬＴＥでは１．４ＭＨｚ，３ＭＨｚ，５ＭＨｚ，１０ＭＨｚ，１５ＭＨｚ，２０ＭＨｚの中で基地局毎に選択可能となっている。また、ＬＴＥでは、Ｗ−ＣＤＭＡとは異なり、回線交換を含まず、パケット通信方式のみになる。
ＬＴＥでは、Ｗ−ＣＤＭＡのコアネットワークであるＧＰＲＳ（General Packet Radio Service）とは異なる新たなコアネットワークを用いて通信システムが構成されるので、ＬＴＥの無線アクセス網（無線アクセスネットワーク（radio access network））は、Ｗ−ＣＤＭＡ網とは別の独立した無線アクセス網として定義される。
したがって、Ｗ−ＣＤＭＡの通信システムと区別するために、ＬＴＥの通信システムでは、コアネットワークはＥＰＣ（Evolved Packet Core）と称され、無線アクセスネットワークはＥ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access）と称される。また無線アクセスネットワークにおいて、通信端末装置である移動端末（User Equipment：ＵＥ）と通信を行う基地局（Base station）はｅＮＢ（E-UTRAN NodeB）と称される。また複数の基地局と制御データおよびユーザデータのやり取りを行う基地局制御装置（Radio Network Controller）の機能は、ＥＰＣが担う。ＥＰＣは、ａＧＷ（Access Gateway）とも称される。またＥＰＣとＥ−ＵＴＲＡＮとで構成されるシステムは、ＥＰＳ（Evolved Packet System）と称される。
ＬＴＥの通信システムでは、ユニキャスト（Unicast）サービスとＥ-ＭＢＭＳサービス（Evolved Multimedia Broadcast Multicast Service）とが提供される。Ｅ−ＭＢＭＳサービスとは、放送型マルチメディアサービスである。Ｅ−ＭＢＭＳサービスは、単にＭＢＭＳと称される場合もある。Ｅ−ＭＢＭＳサービスでは、複数の移動端末に対して、ニュースおよび天気予報、ならびにモバイル放送などの大容量放送コンテンツが送信される。これを１対多（Point to Multipoint）サービスともいう。
３ＧＰＰでの、ＬＴＥシステムにおける全体的なアーキテクチャ（Architecture）に関する決定事項が、非特許文献１（４章）に記載されている。全体的なアーキテクチャについて図１を用いて説明する。図１は、ＬＴＥ方式の通信システムの構成を示す説明図である。図１において、移動端末１０１に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン、例えばＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とが基地局１０２で終端するならば、Ｅ−ＵＴＲＡＮは１つあるいは複数の基地局１０２によって構成される。
基地局１０２は、移動管理エンティティ（Mobility Management Entity：ＭＭＥ）１０３から通知されるページング信号（Paging Signal、ページングメッセージ（paging messages）とも称される）のスケジューリング（Scheduling）および送信を行う。基地局１０２は、Ｘ２インタフェースにより、互いに接続される。また基地局１０２は、Ｓ１インタフェースによりＥＰＣ（Evolved Packet Core）に接続される。より明確には、基地局１０２は、Ｓ１＿ＭＭＥインタフェースによりＭＭＥ（Mobility Management Entity）１０３に接続され、Ｓ１＿ＵインタフェースによりＳ−ＧＷ（Serving Gateway）１０４に接続される。
ＭＭＥ１０３は、複数あるいは単数の基地局１０２へのページング信号の分配を行う。また、ＭＭＥ１０３は、待受け状態（Idle State）のモビリティ制御（Mobility control）を行う。ＭＭＥ１０３は、移動端末が待ち受け状態の際、および、アクティブ状態（Active State）の際に、トラッキングエリア（Tracking Area）リストの管理を行う。
Ｓ−ＧＷ１０４は、一つまたは複数の基地局１０２とユーザデータの送受信を行う。Ｓ−ＧＷ１０４は、基地局間のハンドオーバの際、ローカルな移動性のアンカーポイント（Mobility Anchor Point）となる。ＥＰＣには、さらにＰ−ＧＷ（PDN Gateway）が存在する。Ｐ−ＧＷは、ユーザ毎のパケットフィルタリングやＵＥ−ＩＤアドレスの割当などを行う。
移動端末１０１と基地局１０２との間の制御プロトコルＲＲＣは、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC connection management）などを行う。ＲＲＣにおける基地局と移動端末との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤとがある。ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public Land Mobile Network）選択、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell re-selection）、モビリティなどが行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができる。またＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbour cell）のメジャメントなどが行われる。
非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図２を用いて説明する。図２は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図２において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink Synchronization Signal：ＳＳ）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ−ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ−ＳＳ）とがある。
サブフレーム単位で、ＭＢＳＦＮ（Multimedia Broadcast multicast service Single Frequency Network）用のチャネルと、ＭＢＳＦＮ以外用のチャネルとの多重が行われる。ＭＢＳＦＮ送信（MBSFN Transmission）とは、同時に複数のセルから同じ波形の送信により実現される同時放送送信技術（simulcast transmission technique）である。ＭＢＳＦＮ領域（MBSFN Area）の複数のセルからのＭＢＳＦＮ送信は、移動端末には、１つの送信と認識される。ＭＢＳＦＮとは、このようなＭＢＳＦＮ送信をサポートするネットワークである。以降、ＭＢＳＦＮ送信用のサブフレームをＭＢＳＦＮサブフレーム（MBSFN subframe）と称する。
非特許文献２に、ＭＢＳＦＮサブフレームの割り当て時のシグナリング例が記載されている。図３は、ＭＢＳＦＮフレームの構成を示す説明図である。図３に示すように、割当周期（radio Frame Allocation Period）毎にＭＢＳＦＮサブフレームを含む無線フレームが割り当てられる。ＭＢＳＦＮサブフレームは、割当周期と割当オフセット（radio Frame Allocation Offset）とによって定義された無線フレームにてＭＢＳＦＮのために割り当てられるサブフレームであり、マルチメディアデータを伝送するためのサブフレームである。以下の式（１）を満たす無線フレームが、ＭＢＳＦＮサブフレームを含む無線フレームである。
ＳＦＮ ｍｏｄ radioFrameAllocationPeriod＝radioFrameAllocationOffset …（１）
ＭＢＳＦＮサブフレームの割当は６ビットにて行われる。１番左のビットは、サブフレームの２番目（＃１）のＭＢＳＦＮ割当を定義する。左から２番目のビットはサブフレームの３番目（＃２）、左から３番目のビットはサブフレームの４番目（＃３）、左から４番目のビットはサブフレームの７番目（＃６）、左から５番目のビットはサブフレームの８番目（＃７）、左から６番目のビットはサブフレームの９番目（＃８）のＭＢＳＦＮ割当を定義する。該ビットが「１」を示す場合、対応するサブフレームがＭＢＳＦＮのために割当てられることを示す。
３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed Subscriber Group）セルにおいてもｎｏｎ−ＣＳＧセルと同じチャネル構成が用いられると想定されている。物理チャネル（Physical channel）について、図４を用いて説明する。図４は、ＬＴＥ方式の通信システムで使用される物理チャネルを説明する説明図である。
図４において、物理報知チャネル（Physical Broadcast channel：ＰＢＣＨ）４０１は、基地局１０２から移動端末１０１への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。
物理制御チャネルフォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）４０２は、基地局１０２から移動端末１０１への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭシンボルの数について基地局１０２から移動端末１０１へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。
物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）４０３は、基地局１０２から移動端末１０１への下り送信用のチャネルである。ＰＤＣＣＨは、後述の図５に示されるトランスポートチャネルの１つである下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）のリソース割り当て（allocation）情報、図５に示されるトランスポートチャネルの１つであるページングチャネル（Paging Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ−ＳＣＨに関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。
物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）４０４は、基地局１０２から移動端末１０１への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。
物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）４０５は、基地局１０２から移動端末１０１への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast Channel：ＭＣＨ）がマッピングされている。
物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）４０６は、移動端末１０１から基地局１０２への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＱＩ（Channel Quality Indicator）レポートを運ぶ。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。
物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）４０７は、移動端末１０１から基地局１０２への上り送信用のチャネルである。ＰＵＳＣＨには、図５に示されるトランスポートチャネルの１つである上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）がマッピングされている。
物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）４０８は、基地局１０２から移動端末１０１への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）４０９は、移動端末１０１から基地局１０２への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。
下り参照信号（リファレンスシグナル（Reference Signal）：ＲＳ）は、移動体通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific Reference Signals：ＣＲＳ）、ＭＢＳＦＮ参照信号（MBSFN reference signals）、ＵＥ固有参照信号（UE-specific reference signals）であるデータ復調用参照信号（Demodulation Reference Signal：ＤＭ−ＲＳ）、位置決定参照信号（Positioning Reference Signals：ＰＲＳ）、チャネル情報参照信号（Channel-State Information Reference Signals：ＣＳＩ−ＲＳ）。移動端末の物理レイヤの測定として、リファレンスシグナルの受信電力（Reference Signal Received Power：ＲＳＲＰ）測定がある。
非特許文献１（５章）に記載されるトランスポートチャネル（Transport channel）について、図５を用いて説明する。図５は、ＬＴＥ方式の通信システムで使用されるトランスポートチャネルを説明する説明図である。図５（Ａ）には、下りトランスポートチャネルと下り物理チャネルとの間のマッピングを示す。図５（Ｂ）には、上りトランスポートチャネルと上り物理チャネルとの間のマッピングを示す。
図５（Ａ）に示す下りトランスポートチャネルのうち、報知チャネル（Broadcast Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。
下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＤＬ−ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent Scheduling）ともいわれる。ＤＬ−ＳＣＨは、移動端末の低消費電力化のために移動端末の間欠受信（Discontinuous reception：ＤＲＸ）をサポートする。ＤＬ−ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。
ページングチャネル（Paging Channel：ＰＣＨ）は、移動端末の低消費電力を可能とするために移動端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソースへマッピングされる。
マルチキャストチャネル（Multicast Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳサービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。
図５（Ｂ）に示す上りトランスポートチャネルのうち、上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＵＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ−ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。
図５（Ｂ）に示されるランダムアクセスチャネル（Random Access Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。
ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送要求（Automatic Repeat reQuest：ＡＲＱ）と誤り訂正（Forward Error Correction）との組合せにより、伝送路の通信品質を向上させる技術である。ＨＡＲＱには、通信品質が変化する伝送路に対しても、再送により誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。
再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic Redundancy Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。
ＨＡＲＱ方式の一例として、チェースコンバイニング（Chase Combining）がある。チェースコンバイニングとは、初送と再送とにおいて、同じデータを送信するものであり、再送において初送のデータと再送のデータとの合成を行うことで、利得を向上させる方式である。チェースコンバイニングは、初送データに誤りがあったとしても、部分的に正確なものも含まれており、正確な部分の初送データと再送データとを合成することで、より高精度にデータを送信できるという考え方に基づいている。また、ＨＡＲＱ方式の別の例として、ＩＲ（Incremental Redundancy）がある。ＩＲとは、冗長度を増加させるものであり、再送においてパリティビットを送信することで、初送と組合せて冗長度を増加させ、誤り訂正機能により品質を向上させるものである。
非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical channel）について、図６を用いて説明する。図６は、ＬＴＥ方式の通信システムで使用される論理チャネルを説明する説明図である。図６（Ａ）には、下りロジカルチャネルと下りトランスポートチャネルとの間のマッピングを示す。図６（Ｂ）には、上りロジカルチャネルと上りトランスポートチャネルとの間のマッピングを示す。
報知制御チャネル（Broadcast Control Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。
ページング制御チャネル（Paging Control Channel：ＰＣＣＨ）は、ページング情報（Paging Information）およびシステム情報（System Information）の変更を送信するための下りチャネルである。ＰＣＣＨは、移動端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。
共有制御チャネル（Common Control Channel：ＣＣＣＨ）は、移動端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、移動端末がネットワークとの間でＲＲＣ接続（connection）を有していない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされる。
マルチキャスト制御チャネル（Multicast Control Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ＭＣＣＨは、ネットワークから移動端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられる。ＭＣＣＨは、トランスポートチャネルであるマルチキャストチャネル（ＭＣＨ）へマッピングされる。
個別制御チャネル（Dedicated Control Channel：ＤＣＣＨ）は、１対１にて、移動端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、移動端末がＲＲＣ接続（connection）である場合に用いられる。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）にマッピングされる。
個別トラフィックチャネル（Dedicated Traffic Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別移動端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。
マルチキャストトラフィックチャネル（Multicast Traffic channel：ＭＴＣＨ）は、ネットワークから移動端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の移動端末のみに用いられるチャネルである。ＭＴＣＨは、マルチキャストチャネル（ＭＣＨ）へマッピングされる。
ＣＧＩとは、セルグローバル識別子（Cell Global Identification）のことである。ＥＣＧＩとは、Ｅ−ＵＴＲＡＮセルグローバル識別子（E-UTRAN Cell Global Identification）のことである。ＬＴＥ、後述のＬＴＥ−Ａ（Long Term Evolution Advanced）およびＵＭＴＳ（Universal Mobile Telecommunication System）において、ＣＳＧ（Closed Subscriber Group）セルが導入される。ＣＳＧセルについて以下に説明する（非特許文献３ ３．１章参照）。
ＣＳＧ（Closed Subscriber Group）セルとは、利用可能な加入者をオペレータが特定しているセル（以下「特定加入者用セル」という場合がある）である。特定された加入者は、ＰＬＭＮ（Public Land Mobile Network）の１つ以上のセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている１つ以上のセルを「ＣＳＧセル（ＣＳＧ ｃｅｌｌ（ｓ））」と呼ぶ。ただし、ＰＬＭＮにはアクセス制限がある。
ＣＳＧセルは、固有のＣＳＧアイデンティティ（CSG identity：ＣＳＧ ＩＤ；ＣＳＧ−ＩＤ）を報知し、ＣＳＧインジケーション（CSG Indication）にて「ＴＲＵＥ」を報知するＰＬＭＮの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのＣＳＧ−ＩＤを用いてＣＳＧセルにアクセスする。
ＣＳＧ−ＩＤは、ＣＳＧセルまたはセルによって報知される。移動体通信システムにＣＳＧ−ＩＤは複数存在する。そして、ＣＳＧ−ＩＤは、ＣＳＧ関連のメンバーのアクセスを容易にするために、移動端末（ＵＥ）によって使用される。
移動端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても移動端末の位置を追跡し、移動端末を呼び出す、換言すれば移動端末が着呼することを可能にするために行われる。この移動端末の位置追跡のための区域をトラッキングエリアと呼ぶ。
ＣＳＧホワイトリスト（CSG White List）とは、加入者が属するＣＳＧセルのすべてのＣＳＧ ＩＤが記録されている、ＵＳＩＭ（Universal Subscriber Identity Module）に格納されることもあるリストである。ＣＳＧホワイトリストは、単にホワイトリスト、あるいは許可ＣＳＧリスト（Allowed CSG List）と呼ばれることもある。ＣＳＧセルを通しての移動端末のアクセスは、ＭＭＥがアクセスコントロール（access control）を実行する（非特許文献４ ４．３．１．２章参照）。移動端末のアクセスの具体例としては、アタッチ（attach）、コンバインドアタッチ（combined attach）、デタッチ（detach）、サービスリクエスト（service request）、トラッキングエリアアップデートプロシジャー（Tracking Area Update procedure）などがある（非特許文献４ ４．３．１．２章参照）。
待受け状態の移動端末のサービスタイプについて以下に説明する（非特許文献３ ４．３章参照）。待受け状態の移動端末のサービスタイプとしては、制限されたサービス（Limited service、限られたサービスとも称される）、標準サービス（ノーマルサービス（Normal service））、オペレータサービス（Operator service）がある。制限されたサービスとは、後述のアクセプタブルセル上の緊急呼（Emergency calls）、ＥＴＷＳ（Earthquake and Tsunami Warning System）、ＣＭＡＳ（Commercial Mobile Alert System）である。標準サービス（通常サービスとも称される）とは、後述の適切なセル上の公共のサービスである。オペレータサービスとは、後述のリザーブセル上のオペレータのためのみのサービスである。
「適切なセル（Suitable cell）」について以下に説明する。「適切なセル（Suitable cell）」とは、ＵＥが通常（normal）サービスを受けるためにキャンプオン（Camp ON）するかもしれないセルである。そのようなセルは、以下の（１），（２）の条件を満たすものとする。
（１）セルは、選択されたＰＬＭＮもしくは登録されたＰＬＭＮ、または「Ｅｑｕｉｖａｌｅｎｔ ＰＬＭＮリスト」のＰＬＭＮの一部であること。
（２）ＮＡＳ（Non-Access Stratum）によって提供された最新情報にて、さらに以下の（ａ）〜（ｄ）の条件を満たすこと。
（ａ）そのセルが禁じられた（barred）セルでないこと。
（ｂ）そのセルが「ローミングのための禁止されたＬＡｓ」リストの一部でないトラッキングエリア（Tracking Area：ＴＡ）の一部であること。その場合、そのセルは前記（１）を満たす必要がある。
（ｃ）そのセルが、セル選択評価基準を満たしていること。
（ｄ）そのセルが、ＣＳＧセルとしてシステム情報（System Information：ＳＩ）によって特定されたセルに関しては、ＣＳＧ−ＩＤはＵＥの「ＣＳＧホワイトリスト」（CSG WhiteList）の一部であること、すなわちＵＥのCSG WhiteList中に含まれること。
「アクセプタブルセル（Acceptable cell）」について以下に説明する。「アクセプタブルセル（Acceptable cell）」とは、ＵＥが制限されたサービスを受けるためにキャンプオンするかもしれないセルである。そのようなセルは、以下の（１），（２）のすべての要件を充足するものとする。
（１）そのセルが禁じられたセル（「バードセル（Barred cell）」とも称される）でないこと。
（２）そのセルが、セル選択評価基準を満たしていること。
「バードセル（Barred cell）」は、システム情報で指示がある。「リザーブセル（Reserved cell）」は、システム情報で指示がある。
「セルにキャンプオン（camp on）する」とは、ＵＥがセル選択（cell selection）またはセル再選択（cell reselection）の処理を完了し、ＵＥがシステム情報とページング情報とをモニタするセルを選択した状態になることをいう。ＵＥがキャンプオンするセルを「サービングセル（Serving cell）」と称することがある。
３ＧＰＰにおいて、Ｈｏｍｅ−ＮｏｄｅＢ（Ｈｏｍｅ−ＮＢ；ＨＮＢ）、Ｈｏｍｅ−ｅＮｏｄｅＢ（Ｈｏｍｅ−ｅＮＢ；ＨｅＮＢ）と称される基地局が検討されている。ＵＴＲＡＮにおけるＨＮＢ、およびＥ−ＵＴＲＡＮにおけるＨｅＮＢは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献５には、ＨｅＮＢおよびＨＮＢへのアクセスの３つの異なるモードが開示されている。具体的には、オープンアクセスモード（Open access mode）と、クローズドアクセスモード（Closed access mode）と、ハイブリッドアクセスモード（Hybrid access mode）とが開示されている。
各々のモードは、以下のような特徴を有する。オープンアクセスモードでは、ＨｅＮＢおよびＨＮＢは、通常のオペレータのノーマルセルとして操作される。クローズドアクセスモードでは、ＨｅＮＢおよびＨＮＢは、ＣＳＧセルとして操作される。このＣＳＧセルは、ＣＳＧメンバーのみアクセス可能なＣＳＧセルである。ハイブリッドアクセスモードでは、ＨｅＮＢおよびＨＮＢは、非ＣＳＧメンバーも同時にアクセス許可されているＣＳＧセルとして操作される。言い換えれば、ハイブリッドアクセスモードのセル（ハイブリッドセルとも称する）は、オープンアクセスモードとクローズドアクセスモードとの両方をサポートするセルである。
３ＧＰＰでは、全ＰＣＩ（Physical Cell Identity）のうち、ＣＳＧセルで使用するためにネットワークによって予約されたＰＣＩ範囲がある（非特許文献１ １０．５．１．１章参照）。ＰＣＩ範囲を分割することをＰＣＩスプリットと称することがある。ＰＣＩスプリットに関する情報（ＰＣＩスプリット情報とも称する）は、システム情報によって基地局から傘下の移動端末に対して報知される。基地局の傘下とは、該基地局をサービングセルとすることを意味する。
非特許文献６は、ＰＣＩスプリットを用いた移動端末の基本動作を開示する。ＰＣＩスプリット情報を有していない移動端末は、全ＰＣＩを用いて、例えば５０４コード全てを用いて、セルサーチを行う必要がある。これに対して、ＰＣＩスプリット情報を有する移動端末は、当該ＰＣＩスプリット情報を用いてセルサーチを行うことが可能である。
また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long Term Evolution Advanced：ＬＴＥ−Ａ）の規格策定が進められている（非特許文献７、非特許文献８参照）。
ＬＴＥ−Ａシステムでは、高い通信速度、セルエッジでの高いスループット、新たなカバレッジエリアなどを得るために、リレー（Relay）およびリレーノード（Relay Node：ＲＮ）をサポートすることが検討されている。中継装置であるリレーノードは、ドナーセル（Donor cell、以下「ドナーｅＮＢ（Donor eNB；ＤｅＮＢ）」という場合がある）と呼ばれるセルを介して、無線アクセスネットワークに無線で接続される。ドナーセルの範囲内で、ネットワーク（Network：ＮＷ）からリレーノードへのリンクは、ネットワークからＵＥへのリンクと同じ周波数帯域（周波数バンド（band））を共用する。この場合、３ＧＰＰのリリース８対応のＵＥも該ドナーセルに接続可能とする。ドナーセルとリレーノードとの間のリンクをバックホールリンク（backhaul link）と称し、リレーノードとＵＥとの間のリンクをアクセスリンク（access link）と称する。
ＦＤＤ（Frequency Division Duplex）におけるバックホールリンクの多重方法として、ＤｅＮＢからＲＮへの送信は下り（ＤＬ）周波数バンドで行われ、ＲＮからＤｅＮＢへの送信は上り（ＵＬ）周波数バンドで行われる。リレーにおけるリソースの分割方法として、ＤｅＮＢからＲＮへのリンクおよびＲＮからＵＥへのリンクが一つの周波数バンドで時分割多重され、ＲＮからＤｅＮＢへのリンクおよびＵＥからＲＮへのリンクも一つの周波数バンドで時分割多重される。こうすることで、リレーにおいて、リレーの送信が自リレーの受信へ干渉することを防ぐことができる。
３ＧＰＰでは、通常のｅＮＢ（マクロセル）だけでなく、ピコｅＮＢ（ピコセル（pico cell））、ＨｅＮＢ（ＨＮＢ、ＣＳＧセル）、ホットゾーンセル用のノード、リレーノード、リモートラジオヘッド（Remote Radio Head：ＲＲＨ）、リピータなどのいわゆるローカルノードが検討されている。前述のような各種タイプのセルからなるネットワークは、異機種ネットワーク（heterogeneous network、ヘットネット）と称されることもある。
ＬＴＥでは、通信に使用可能な周波数バンド（以下「オペレーティングバンド」という場合がある）が予め決められている。非特許文献９には、該周波数バンドが記載されている。
ＬＴＥ−Ａシステムでは、１００ＭＨｚまでのより広い周波数帯域幅（transmission bandwidths）をサポートするために、二つ以上のコンポーネントキャリア（Component Carrier：ＣＣ）を集約する（アグリゲーション（aggregation）するとも称する）、キャリアアグリゲーション（Carrier Aggregation：ＣＡ）が検討されている。
ＬＴＥ対応である、３ＧＰＰのリリース８または９対応のＵＥは、一つのサービングセルに相当する一つのＣＣ上のみで送受信可能である。これに対して、３ＧＰＰのリリース１０対応のＵＥは、複数のサービングセルに相当する複数のＣＣ上で同時に送受信、あるいは受信のみ、あるいは送信のみをするための能力（ケーパビリティ、capability）を有することが考えられている。
各ＣＣは、３ＧＰＰのリリース８または９の構成を用いており、ＣＡは、連続ＣＣ、非連続ＣＣ、および異なる周波数帯域幅のＣＣをサポートする。ＵＥが下りリンクのＣＣ（ＤＬ ＣＣ）の個数以上の個数の、上りリンクのＣＣ（ＵＬ ＣＣ）を構成することは不可能である。同一ｅＮＢから構成されるＣＣは、同じカバレッジを提供する必要は無い。ＣＣは、３ＧＰＰのリリース８または９と互換性を有する。
ＣＡにおいて、上りリンク、下りリンクともに、サービングセル毎に一つの独立したＨＡＲＱエンティティがある。トランスポートブロックは、サービングセル毎にＴＴＩ毎に生成される。各トランスポートブロックとＨＡＲＱ再送とは、シングルサービングセルにマッピングされる。
ＣＡが構成される場合、ＵＥはＮＷと唯一つのＲＲＣ接続（RRC connection）を有する。ＲＲＣ接続において、一つのサービングセルがＮＡＳモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル（Primary Cell：ＰＣｅｌｌ）と呼ぶ。下りリンクで、ＰＣｅｌｌに対応するキャリアは、下りプライマリコンポーネントキャリア（Downlink Primary Component Carrier：ＤＬ ＰＣＣ）である。上りリンクで、ＰＣｅｌｌに対応するキャリアは、上りプライマリコンポーネントキャリア（Uplink Primary Component Carrier：ＵＬ ＰＣＣ）である。
ＵＥの能力（ケーパビリティ（capability））に応じて、セカンダリセル（Secondary Cell：ＳＣｅｌｌ）が、ＰＣｅｌｌとサービングセルとの組を形成するために構成される。下りリンクで、ＳＣｅｌｌに対応するキャリアは、下りセカンダリコンポーネントキャリア（Downlink Secondary Component Carrier：ＤＬ ＳＣＣ）である。上りリンクで、ＳＣｅｌｌに対応するキャリアは、上りセカンダリコンポーネントキャリア（Uplink Secondary Component Carrier：ＵＬ ＳＣＣ）である。
一つのＵＥに対して、一つのＰＣｅｌｌと、一つ以上のＳＣｅｌｌからなるサービングセルとの組が構成される。
３ＧＰＰにおいて、さらに進んだ新たな無線区間の通信方式として、前述のＬＴＥアドヴァンスド（LTE Advanced：ＬＴＥ−Ａ）が検討されている（非特許文献７および非特許文献８参照）。ＬＴＥ−Ａは、ＬＴＥの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。新技術としては、より広い帯域をサポートする技術（Wider bandwidth extension）、および多地点協調送受信（Coordinated Multiple Point transmission and reception：ＣｏＭＰ）技術などがある。３ＧＰＰでＬＴＥ−Ａのために検討されているＣｏＭＰについては、非特許文献１０に記載されている。
ＣｏＭＰとは、地理的に分離された多地点間で協調した送信あるいは受信を行うことによって、高いデータレートのカバレッジの拡大、セルエッジでのスループットの向上、および通信システムにおけるスループットの増大を図る技術である。ＣｏＭＰには、下りＣｏＭＰ（ＤＬ ＣｏＭＰ）と、上りＣｏＭＰ（ＵＬ ＣｏＭＰ）とがある。
ＤＬ ＣｏＭＰでは、一つの移動端末（ＵＥ）へのＰＤＳＣＨを多地点（マルチポイント）間で協調して送信する。一つのＵＥへのＰＤＳＣＨを、マルチポイントの一つのポイントから送信してもよいし、マルチポイントの複数のポイントから送信してもよい。ＤＬ ＣｏＭＰにおいて、サービングセルとは、ＰＤＣＣＨによってリソース割当を送信する単独のセルである。
ＤＬ ＣｏＭＰの方法として、結合処理（Joint Processing：ＪＰ）と、協調スケジューリング（Coordinated Scheduling：ＣＳ）または協調ビームフォーミング（Coordinated Beamforming：ＣＢ）（以下「ＣＳ／ＣＢ」という場合がある）とが検討されている。
ＪＰは、ＣｏＭＰコオペレーティングセット（CoMP cooperating set）中のそれぞれのポイントでデータが利用可能である。ＪＰには、結合送信（Joint Transmission：ＪＴ）と、動的ポイント選択（Dynamic Point Selection：ＤＰＳ）とがある。ＤＰＳは、動的セル選択（Dynamic Cell Selection：ＤＣＳ）を含む。ＪＴでは、ある時点で複数のポイント、具体的にはＣｏＭＰコオペレーティングセット（CoMP cooperating set）の一部あるいは全部から、ＰＤＳＣＨの送信が行われる。ＤＰＳでは、ある時点でＣｏＭＰコオペレーティングセット内の１つのポイントから、ＰＤＳＣＨの送信が行われる。
ＣＳ／ＣＢは、サービングセルからのデータ送信でのみ利用可能である。ＣＳ／ＣＢでは、ＣｏＭＰコオペレーティングセットに対応するセル間での調整と併せて、ユーザスケジューリングまたはビームフォーミングの決定がなされる。
マルチポイントで送受信するポイントとしてユニットおよびセルが、ユニットおよびセルとして基地局（NB、eNB、HNB、HeNB）、ＲＲＵ（Remote Radio Unit）、ＲＲＥ（Remote Radio Equipment）、ＲＲＨ（Remote Radio Head）、リレーノード（Relay Node：ＲＮ）などが検討されている。多地点協調送信を行うユニットおよびセルを、それぞれマルチポイントユニット、マルチポイントセルと称する場合がある。
３ＧＰＰ ＴＳ３６．３００ Ｖ１０．５．０ ３ＧＰＰ ＴＳ３６．３３１ Ｖ１０．３．０ ３ＧＰＰ ＴＳ３６．３０４ Ｖ１０．３．０ ３．１章、４．３章、５．２．４章 ３ＧＰＰ ＴＲ ２３．８３０ Ｖ９．０．０ ３ＧＰＰ Ｓ１−０８３４６１ ３ＧＰＰ Ｒ２−０８２８９９ ３ＧＰＰ ＴＲ ３６．８１４ Ｖ９．０．０ ３ＧＰＰ ＴＲ ３６．９１２ Ｖ１０．０．０ ３ＧＰＰ ＴＳ ３６．１０１ Ｖ１０．３．０ ３ＧＰＰ ＴＲ ３６．８１９ Ｖ１１．０．０ ３ＧＰＰ ＴＲ ２３．８８８ Ｖ１．６．０ ３ＧＰＰ ＴＲ ２２．８０１ Ｖ１２．０．０ ３ＧＰＰ ＴＳ ２３．４０１ Ｖ１１．０．０ ３ＧＰＰ ＴＳ ２４．３０１ Ｖ１１．１．０ ３ＧＰＰ Ｒ２−１２０４４４ ３ＧＰＰ Ｓ２−１１４３４１
前述の３ＧＰＰの規格に代表されるセルラー系無線通信の発展により、その無線ネットワークを用いた様々な形態のアプリケーション間の通信が実行され、もしくは実行されようとしている。例えば、３ＧＰＰにおけるマシンタイプコミュニケーション（（Machine Type Communication；略称：ＭＴＣ）、およびＩＥＥＥ８０２．３規格などの有線通信を想定したアプリケーションの通信などである。
このようなアプリケーションは、従来の移動体通信における想定と異なる環境および形態で使用されるので、様々な課題および問題を引き起こす。
例えば、ＭＴＣを行う通信端末装置（以下「ＭＴＣ端末」という）は、使用環境として、ガスメータおよび動物などに設置されることが考えられている（非特許文献１１参照）。その場合、ＭＴＣ端末はバッテリによって駆動されることになるので、バッテリの交換および再充電が困難であることを想定する必要がある。したがって、通常の通信端末装置に比べて、一層の低消費電力化が必要となる。また、盗難および破壊などのリスクも考慮する必要があるので、ＭＴＣ端末のモニタリングの必要性もある。
また、ＭＴＣとは異なるアプリケーションでは、ＨＴＴＰ（HyperText Transfer Protocol）およびＴＣＰ（Transmission Control Protocol）を用いた通信などにおいて、通信のエンド−エンド（Ｅｎｄ−Ｅｎｄ）となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット（以下「ｋｅｅｐ-ａｌｉｖｅパケット」という）を定期的に送信する場合がある（非特許文献１２参照）。このとき、通信端末装置は、ｋｅｅｐ-ａｌｉｖｅパケットを伝送するために、定期的に接続処理、具体的には発信処理を行う必要がある。
この接続処理によって、無線アクセスネットワークにおけるシステムリソースを使用してしまい、無線リソースおよび通信ノードにおける処理負荷などの増加を招くという問題が発生している。また、定期的に接続処理を行うことは、通信端末装置における消費電力を増加させることにもつながる。
本発明の目的は、処理負荷および消費電力を抑えて、通信端末装置の状態を確認することができる通信システムを提供することである。
本発明の通信システムは、ネットワークに接続される基地局装置と、前記基地局装置に無線通信可能に接続される通信端末装置とを備える通信システムであって、前記基地局装置と前記通信端末装置との間で、前記通信端末装置の状態を確認するためのモニタリング用メッセージを、予め定めるモニタリング周期で送受信し、前記基地局装置は、前記通信端末装置が検出されたかどうかを、前記モニタリング用メッセージが周辺基地局装置によって、前記予め定めるモニタリング周期内に受信されたかどうかに基づいて、判断することを特徴とする。
本発明の通信システムによれば、処理負荷および消費電力を抑えて、通信端末装置の状態を確認することができる。
この発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
ＬＴＥ方式の通信システムの構成を示す説明図である。 ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。 ＭＢＳＦＮフレームの構成を示す説明図である。 ＬＴＥ方式の通信システムで使用される物理チャネルを説明する説明図である。 ＬＴＥ方式の通信システムで使用されるトランスポートチャネルを説明する説明図である。 ＬＴＥ方式の通信システムで使用される論理チャネルを説明する説明図である。 ３ＧＰＰにおいて議論されているＬＴＥ方式の移動体通信システムの全体的な構成を示すブロック図である。 本発明に係る移動端末である図７に示す移動端末７１の構成を示すブロック図である。 本発明に係る基地局である図７に示す基地局７２の構成を示すブロック図である。 本発明に係るＭＭＥである図７に示すＭＭＥ部７３の構成を示すブロック図である。 本発明に係るＨｅＮＢＧＷである図７に示すＨｅＮＢＧＷ７４の構成を示すブロック図である。 ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。 ＬＴＥ方式の通信システムにおいて周期的に実行するＴＡＵ処理のシーケンスの一例を示す図である。 実施の形態１における通信システムのシーケンスの一例を示す図である。 実施の形態１の変形例２における通信システムのシーケンスの一例を示す図である。 ランダムアクセス処理のシーケンスの一例を示す図である。 実施の形態１の変形例４における通信システムのシーケンスの一例を示す図である。 実施の形態１の変形例４における通信システムのシーケンスの他の例を示す図である。 ＬＴＥ方式の通信システムにおけるページング処理のシーケンスの一例を示す図である。 ＬＴＥ方式の通信システムにおけるページング処理のシーケンスの一例を示す図である。 実施の形態１の変形例５における通信システムのシーケンスの一例を示す図である。 実施の形態１の変形例５における通信システムのシーケンスの一例を示す図である。 実施の形態１の変形例５における通信システムのシーケンスの他の例を示す図である。 実施の形態１の変形例５における通信システムのシーケンスの他の例を示す図である。 実施の形態１の変形例５における通信システムのシーケンスの他の例を示す図である。 実施の形態１の変形例５における通信システムのシーケンスの他の例を示す図である。 実施の形態２で解決する課題を説明するためのシーケンスを示す図である。 実施の形態２で解決する課題を説明するためのシーケンスを示す図である。 実施の形態２で解決する課題を説明するためのシーケンスを示す図である。 実施の形態２における通信システムのシーケンスの一例を示す図である。 実施の形態３で解決する課題を説明するためのシーケンスを示す図である。 実施の形態３で解決する課題を説明するためのシーケンスを示す図である。 実施の形態３における通信システムのシーケンスの一例を示す図である。 実施の形態３における通信システムのシーケンスの一例を示す図である。 実施の形態３における通信システムのシーケンスの一例を示す図である。 実施の形態３の変形例１における通信システムのシーケンスの一例を示す図である。 実施の形態３の変形例１における通信システムのシーケンスの一例を示す図である。 実施の形態４における通信システムのシーケンスの一例を示す図である。 実施の形態４における通信システムのシーケンスの一例を示す図である。 実施の形態４の変形例１における通信システムのシーケンスの一例を示す図である。 実施の形態４の変形例１における通信システムのシーケンスの一例を示す図である。 実施の形態５における通信システムのシーケンスの一例を示す図である。 実施の形態５における通信システムのシーケンスの一例を示す図である。 実施の形態６における通信システムのシーケンスの一例を示す図である。 実施の形態６における通信システムのシーケンスの一例を示す図である。 実施の形態６における通信システムのシーケンスの一例を示す図である。 実施の形態６における通信システムのシーケンスの一例を示す図である。 実施の形態６における通信システムのシーケンスの他の例を示す図である。 実施の形態６における通信システムのシーケンスの他の例を示す図である。 実施の形態６の変形例１で解決する課題を説明するためのシーケンスを示す図である。 実施の形態６の変形例１で解決する課題を説明するためのシーケンスを示す図である。 実施の形態６の変形例１における通信システムのシーケンスの一例を示す図である。 実施の形態６の変形例１における通信システムのシーケンスの一例を示す図である。 実施の形態６の変形例１における通信システムのシーケンスの他の例を示す図である。 実施の形態６の変形例１における通信システムのシーケンスの他の例を示す図である。 実施の形態６の変形例１における通信システムのシーケンスの他の例を示す図である。 実施の形態７の課題を説明するためのシーケンスを示す図である。 実施の形態７の課題を説明するためのシーケンスを示す図である。 実施の形態７における通信システムのシーケンスの一例を示す図である。 実施の形態７における通信システムのシーケンスの一例を示す図である。 実施の形態７における通信システムのシーケンスの一例を示す図である。 実施の形態７における通信システムのシーケンスの他の例を示す図である。 実施の形態７における通信システムのシーケンスの他の例を示す図である。 実施の形態７における通信システムのシーケンスの他の例を示す図である。 実施の形態７における通信システムのシーケンスの他の例を示す図である。
実施の形態１．
図７は、３ＧＰＰにおいて議論されているＬＴＥ方式の移動体通信システムの全体的な構成を示すブロック図である。３ＧＰＰにおいては、ＣＳＧ（Closed Subscriber Group）セル（Ｅ−ＵＴＲＡＮのＨｏｍｅ−ｅＮｏｄｅＢ（Ｈｏｍｅ−ｅＮＢ；ＨｅＮＢ）、ＵＴＲＡＮのＨｏｍｅ−ＮＢ（ＨＮＢ））と、ｎｏｎ−ＣＳＧセル（Ｅ−ＵＴＲＡＮのｅＮｏｄｅＢ（ｅＮＢ）、ＵＴＲＡＮのＮｏｄｅＢ（ＮＢ）、ＧＥＲＡＮのＢＳＳ）とを含めたシステムの全体的な構成が検討されており、Ｅ−ＵＴＲＡＮについては、図７のような構成が提案されている（非特許文献１ ４．６．１章参照）。
図７について説明する。通信端末装置である移動端末装置（以下「移動端末（User Equipment：ＵＥ）」という）７１は、基地局装置（以下「基地局」という）７２と無線通信可能であり、無線通信で信号の送受信を行う。基地局７２は、マクロセルであるｅＮＢ７２−１と、ローカルノードであるＨｏｍｅ−ｅＮＢ７２−２とに分類される。ｅＮＢ７２−１は、移動端末（ＵＥ）７１と通信可能な範囲であるカバレッジとして、比較的大きい大規模カバレッジを有する。Ｈｏｍｅ−ｅＮＢ７２−２は、カバレッジとして、比較的小さい小規模カバレッジを有する。
ｅＮＢ７２−１は、ＭＭＥ、あるいはＳ−ＧＷ、あるいはＭＭＥおよびＳ−ＧＷを含むＭＭＥ／Ｓ−ＧＷ部（以下「ＭＭＥ部」という場合がある）７３とＳ１インタフェースにより接続され、ｅＮＢ７２−１とＭＭＥ部７３との間で制御情報が通信される。一つのｅＮＢ７２−１に対して、複数のＭＭＥ部７３が接続されてもよい。ＭＭＥ部７３は、コアネットワークであるＥＰＣに含まれる。ｅＮＢ７２−１間は、Ｘ２インタフェースにより接続され、ｅＮＢ７２−１間で制御情報が通信される。
Ｈｏｍｅ−ｅＮＢ７２−２は、ＭＭＥ部７３とＳ１インタフェースにより接続され、Ｈｏｍｅ−ｅＮＢ７２−２とＭＭＥ部７３との間で制御情報が通信される。一つのＭＭＥ部７３に対して、複数のＨｏｍｅ−ｅＮＢ７２−２が接続される。あるいは、Ｈｏｍｅ−ｅＮＢ７２−２は、ＨｅＮＢＧＷ（Home-eNB GateWay）７４を介してＭＭＥ部７３と接続される。Ｈｏｍｅ−ｅＮＢ７２−２とＨｅＮＢＧＷ７４とは、Ｓ１インタフェースにより接続され、ＨｅＮＢＧＷ７４とＭＭＥ部７３とはＳ１インタフェースを介して接続される。
一つまたは複数のＨｏｍｅ−ｅＮＢ７２−２が一つのＨｅＮＢＧＷ７４と接続され、Ｓ１インタフェースを通して情報が通信される。ＨｅＮＢＧＷ７４は、一つまたは複数のＭＭＥ部７３と接続され、Ｓ１インタフェースを通して情報が通信される。
ＭＭＥ部７３およびＨｅＮＢＧＷ７４は、上位ノード装置であり、基地局であるｅＮＢ７２−１およびＨｏｍｅ−ｅＮＢ７２−２と、移動端末（ＵＥ）７１との接続を制御する。ＭＭＥ部７３およびＨｅＮＢＧＷ７４は、コアネットワークであるＥＰＣに含まれる。
さらに３ＧＰＰでは、以下のような構成が検討されている。Ｈｏｍｅ−ｅＮＢ７２−２間のＸ２インタフェースはサポートされる。すなわち、Ｈｏｍｅ−ｅＮＢ７２−２間は、Ｘ２インタフェースにより接続され、Ｈｏｍｅ−ｅＮＢ７２−２間で制御情報が通信される。ＭＭＥ部７３からは、ＨｅＮＢＧＷ７４はＨｏｍｅ−ｅＮＢ７２−２として見える。Ｈｏｍｅ−ｅＮＢ７２−２からは、ＨｅＮＢＧＷ７４はＭＭＥ部７３として見える。
Ｈｏｍｅ−ｅＮＢ７２−２が、ＨｅＮＢＧＷ７４を介してＭＭＥ部７３に接続される場合および直接ＭＭＥ部７３に接続される場合のいずれの場合も、Ｈｏｍｅ−ｅＮＢ７２−２とＭＭＥ部７３との間のインタフェースは、Ｓ１インタフェースで同じである。ＨｅＮＢＧＷ７４は、複数のＭＭＥ部７３にまたがるような、Ｈｏｍｅ−ｅＮＢ７２−２へのモビリティ、あるいはＨｏｍｅ−ｅＮＢ７２−２からのモビリティはサポートしない。Ｈｏｍｅ−ｅＮＢ７２−２は、唯一のセルを構成し、サポートする。
基地局装置は、例えばＨｏｍｅ−ｅＮＢ７２−２のように唯一のセルをサポートするが、これに限定されず、１つの基地局装置が複数のセルをサポートしてもよい。１つの基地局装置が複数のセルをサポートする場合、１つ１つのセルが、基地局装置として機能する。
図８は、本発明に係る移動端末である図７に示す移動端末７１の構成を示すブロック図である。図８に示す移動端末７１の送信処理を説明する。まず、プロトコル処理部８０１からの制御データ、およびアプリケーション部８０２からのユーザデータが、送信データバッファ部８０３へ保存される。送信データバッファ部８０３に保存されたデータは、エンコーダー部８０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部８０３から変調部８０５へ直接出力されるデータが存在してもよい。エンコーダー部８０４でエンコード処理されたデータは、変調部８０５にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部８０６へ出力され、無線送信周波数に変換される。その後、アンテナ８０７から基地局７２に送信信号が送信される。
また、移動端末７１の受信処理は、以下のように実行される。基地局７２からの無線信号がアンテナ８０７により受信される。受信信号は、周波数変換部８０６にて無線受信周波数からベースバンド信号に変換され、復調部８０８において復調処理が行われる。復調後のデータは、デコーダー部８０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部８０１へ渡され、ユーザデータはアプリケーション部８０２へ渡される。移動端末７１の一連の処理は、制御部８１０によって制御される。よって制御部８１０は、図８では省略しているが、各部８０１〜８０９と接続している。
図９は、本発明に係る基地局である図７に示す基地局７２の構成を示すブロック図である。図９に示す基地局７２の送信処理を説明する。ＥＰＣ通信部９０１は、基地局７２とＥＰＣ（ＭＭＥ部７３、ＨｅＮＢＧＷ７４など）との間のデータの送受信を行う。他基地局通信部９０２は、他の基地局との間のデータの送受信を行う。ＥＰＣ通信部９０１および他基地局通信部９０２は、それぞれプロトコル処理部９０３と情報の受け渡しを行う。プロトコル処理部９０３からの制御データ、ならびにＥＰＣ通信部９０１および他基地局通信部９０２からのユーザデータおよび制御データは、送信データバッファ部９０４へ保存される。
送信データバッファ部９０４に保存されたデータは、エンコーダー部９０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部９０４から変調部９０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部９０６にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部９０７へ出力され、無線送信周波数に変換される。その後、アンテナ９０８より一つもしくは複数の移動端末７１に対して送信信号が送信される。
また、基地局７２の受信処理は以下のように実行される。一つもしくは複数の移動端末７１からの無線信号が、アンテナ９０８により受信される。受信信号は、周波数変換部９０７にて無線受信周波数からベースバンド信号に変換され、復調部９０９で復調処理が行われる。復調されたデータは、デコーダー部９１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部９０３あるいはＥＰＣ通信部９０１、他基地局通信部９０２へ渡され、ユーザデータはＥＰＣ通信部９０１および他基地局通信部９０２へ渡される。基地局７２の一連の処理は、制御部９１１によって制御される。よって制御部９１１は、図９では省略しているが、各部９０１〜９１０と接続している。
３ＧＰＰにおいて議論されているＨｏｍｅ−ｅＮＢ７２−２の機能を以下に示す（非特許文献１ ４．６．２章参照）。Ｈｏｍｅ−ｅＮＢ７２−２は、ｅＮＢ７２−１と同じ機能を有する。加えて、ＨｅＮＢＧＷ７４と接続する場合、Ｈｏｍｅ−ｅＮＢ７２−２は、適当なサービングＨｅＮＢＧＷ７４を発見する機能を有する。Ｈｏｍｅ−ｅＮＢ７２−２は、１つのＨｅＮＢＧＷ７４に唯一接続する。つまり、ＨｅＮＢＧＷ７４との接続の場合は、Ｈｏｍｅ−ｅＮＢ７２−２は、Ｓ１インタフェースにおけるＦｌｅｘ機能を使用しない。Ｈｏｍｅ−ｅＮＢ７２−２は、１つのＨｅＮＢＧＷ７４に接続されると、同時に別のＨｅＮＢＧＷ７４および別のＭＭＥ部７３に接続しない。
Ｈｏｍｅ−ｅＮＢ７２−２のＴＡＣとＰＬＭＮ ＩＤは、ＨｅＮＢＧＷ７４によってサポートされる。Ｈｏｍｅ−ｅＮＢ７２−２をＨｅＮＢＧＷ７４に接続すると、「ＵＥ ａｔｔａｃｈｍｅｎｔ」でのＭＭＥ部７３の選択は、Ｈｏｍｅ−ｅＮＢ７２−２の代わりに、ＨｅＮＢＧＷ７４によって行われる。Ｈｏｍｅ−ｅＮＢ７２−２は、ネットワーク計画なしで配備される可能性がある。この場合、Ｈｏｍｅ−ｅＮＢ７２−２は、１つの地理的な領域から別の地理的な領域へ移される。したがって、この場合のＨｏｍｅ−ｅＮＢ７２−２は、位置によって、異なったＨｅＮＢＧＷ７４に接続する必要がある。
図１０は、本発明に係るＭＭＥの構成を示すブロック図である。図１０では、前述の図７に示すＭＭＥ部７３に含まれるＭＭＥ７３ａの構成を示す。ＰＤＮ ＧＷ通信部１００１は、ＭＭＥ７３ａとＰＤＮ ＧＷとの間のデータの送受信を行う。基地局通信部１００２は、ＭＭＥ７３ａと基地局７２との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮ ＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮ ＧＷ通信部１００１から、ユーザプレイン通信部１００３経由で基地局通信部１００２に渡され、１つあるいは複数の基地局７２へ送信される。基地局７２から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部１００２から、ユーザプレイン通信部１００３経由でＰＤＮ ＧＷ通信部１００１に渡され、ＰＤＮ ＧＷへ送信される。
ＰＤＮ ＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮ ＧＷ通信部１００１から制御プレイン制御部１００５へ渡される。基地局７２から受信したデータが制御データであった場合、制御データは、基地局通信部１００２から制御プレイン制御部１００５へ渡される。
ＨｅＮＢＧＷ通信部１００４は、ＨｅＮＢＧＷ７４が存在する場合に設けられ、情報種別によって、ＭＭＥ７３ａとＨｅＮＢＧＷ７４との間のインタフェース（ＩＦ）によるデータの送受信を行う。ＨｅＮＢＧＷ通信部１００４から受信した制御データは、ＨｅＮＢＧＷ通信部１００４から制御プレイン制御部１００５へ渡される。制御プレイン制御部１００５での処理の結果は、ＰＤＮ ＧＷ通信部１００１経由でＰＤＮ ＧＷへ送信される。また、制御プレイン制御部１００５で処理された結果は、基地局通信部１００２経由でＳ１インタフェースにより１つあるいは複数の基地局７２へ送信され、またＨｅＮＢＧＷ通信部１００４経由で１つあるいは複数のＨｅＮＢＧＷ７４へ送信される。
制御プレイン制御部１００５には、ＮＡＳセキュリティ部１００５−１、ＳＡＥベアラコントロール部１００５−２、アイドルステート（Idle State）モビリティ管理部１００５―３などが含まれ、制御プレインに対する処理全般を行う。ＮＡＳセキュリティ部１００５―１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部１００５―２は、ＳＡＥ（System Architecture Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部１００５―３は、待受け状態（アイドルステート（Idle State）；ＬＴＥ−ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末７１のトラッキングエリア（ＴＡ）の追加、削除、更新、検索、トラッキングエリアリスト（TA List）管理などを行う。
ＭＭＥ７３ａは、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area：ＴＡ）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ７３ａに接続されるＨｏｍｅ−ｅＮＢ７２−２のＣＳＧの管理やＣＳＧ−ＩＤの管理、そしてホワイトリスト管理は、アイドルステートモビリティ管理部１００５―３で行ってもよい。
ＣＳＧ−ＩＤの管理では、ＣＳＧ−ＩＤに対応する移動端末とＣＳＧセルとの関係が管理（例えば追加、削除、更新、検索）される。この関係は、例えば、あるＣＳＧ−ＩＤにユーザアクセス登録された一つまたは複数の移動端末と該ＣＳＧ−ＩＤに属するＣＳＧセルとの関係であってもよい。ホワイトリスト管理では、移動端末とＣＳＧ−ＩＤとの関係が管理（例えば追加、削除、更新、検索）される。例えば、ホワイトリストには、ある移動端末がユーザ登録した一つまたは複数のＣＳＧ−ＩＤが記憶されてもよい。これらのＣＳＧに関する管理は、ＭＭＥ７３ａの中の他の部分で行われてもよい。ＭＭＥ７３ａの一連の処理は、制御部１００６によって制御される。よって制御部１００６は、図１０では省略しているが、各部１００１〜１００５と接続している。
３ＧＰＰにおいて議論されているＭＭＥ７３ａの機能を以下に示す（非特許文献１ ４．６．２章参照）。ＭＭＥ７３ａは、ＣＳＧ（Closed Subscriber Group）のメンバーの１つあるいは複数の移動端末のアクセスコントロールを行う。ＭＭＥ７３ａは、ページングの最適化（Paging optimization）の実行をオプションとして認める。
図１１は、本発明に係るＨｅＮＢＧＷである図７に示すＨｅＮＢＧＷ７４の構成を示すブロック図である。ＥＰＣ通信部１１０１は、ＨｅＮＢＧＷ７４とＭＭＥ７３ａとの間のＳ１インタフェースによるデータの送受信を行う。基地局通信部１１０２は、ＨｅＮＢＧＷ７４とＨｏｍｅ−ｅＮＢ７２−２との間のＳ１インタフェースによるデータの送受信を行う。ロケーション処理部１１０３は、ＥＰＣ通信部１１０１経由で渡されたＭＭＥ７３ａからのデータのうちレジストレーション情報などを、複数のＨｏｍｅ−ｅＮＢ７２−２に送信する処理を行う。ロケーション処理部１１０３で処理されたデータは、基地局通信部１１０２に渡され、一つまたは複数のＨｏｍｅ−ｅＮＢ７２−２にＳ１インタフェースを介して送信される。
ロケーション処理部１１０３での処理を必要とせず通過（透過）させるだけのデータは、ＥＰＣ通信部１１０１から基地局通信部１１０２に渡され、一つまたは複数のＨｏｍｅ−ｅＮＢ７２−２にＳ１インタフェースを介して送信される。ＨｅＮＢＧＷ７４の一連の処理は、制御部１１０４によって制御される。よって制御部１１０４は、図１１では省略しているが、各部１１０１〜１１０３と接続している。
３ＧＰＰにおいて議論されているＨｅＮＢＧＷ７４の機能を以下に示す（非特許文献１ ４．６．２章参照）。ＨｅＮＢＧＷ７４は、Ｓ１アプリケーションについてリレーする。Ｈｏｍｅ−ｅＮＢ７２−２へのＭＭＥ７３ａの手順の一部分であるが、ＨｅＮＢＧＷ７４は、移動端末７１に関係しないＳ１アプリケーションについて終端する。ＨｅＮＢＧＷ７４が配置されるとき、移動端末７１に無関係な手順がＨｏｍｅ−ｅＮＢ７２−２とＨｅＮＢＧＷ７４との間、そしてＨｅＮＢＧＷ７４とＭＭＥ７３ａとの間を通信される。ＨｅＮＢＧＷ７４と他のノードとの間でＸ２インタフェースは設定されない。ＨｅＮＢＧＷ７４は、ページングの最適化（Paging optimization）の実行をオプションとして認める。
次に移動体通信システムにおけるセルサーチ方法の一例を示す。図１２は、ＬＴＥ方式の通信システムにおいて移動端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップＳＴ１２０１で、周辺の基地局から送信される第一同期信号（Ｐ−ＳＳ）、および第二同期信号（Ｓ−ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。
Ｐ−ＳＳとＳ−ＳＳとを合わせて、同期信号（ＳＳ）という。同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩ（Physical Cell Identity）に１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は５０４通りが検討されている。この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。
次に同期がとれたセルに対して、ステップＳＴ１２０２で、基地局からセル毎に送信される参照信号（リファレンスシグナル：ＲＳ）であるセル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）を検出し、ＲＳの受信電力（Reference Signal Received Power：ＲＳＲＰ）の測定を行う。参照信号（ＲＳ）には、ＰＣＩと１対１に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップＳＴ１２０１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳの受信電力を測定することが可能となる。
次にステップＳＴ１２０３で、ステップＳＴ１２０２までで検出された一つ以上のセルの中から、ＲＳの受信品質が最もよいセル、例えば、ＲＳの受信電力が最も高いセル、つまりベストセルを選択する。
次にステップＳＴ１２０４で、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master Information Block）がマッピングされる。したがってＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission bandwidth configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System Frame Number）などがある。
次にステップＳＴ１２０５で、ＭＩＢのセル構成情報をもとに該セルのＤＬ−ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System Information Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報や、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、ＴＡＣ（Tracking Area Code）が含まれる。
次にステップＳＴ１２０６で、移動端末は、ステップＳＴ１２０５で受信したＳＩＢ１のＴＡＣと、移動端末が既に保有しているＴＡ（Tracking Area）リスト内のトラッキングエリア識別子（Tracking Area Identity：ＴＡＩ）のＴＡＣ部分とを比較する。ＴＡ（Tracking Area）リストは、ＴＡＩリスト（TAI list）とも称される。ＴＡＩはＴＡの識別子であり、ＭＣＣ（Mobile Country Code）と、ＭＮＣ（Mobile Network Code）と、ＴＡＣ（Tracking Area Code）とによって構成される。ＭＣＣは国コードである。ＭＮＣはネットワークコードである。ＴＡＣはＴＡのコード番号である。
移動端末は、ステップＳＴ１２０６で比較した結果、ステップＳＴ１２０５で受信したＴＡＣがＴＡ（Tracking Area）リスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ１２０５で受信したＴＡＣがＴＡ（Tracking Area）リスト内に含まれなければ、移動端末は、該セルを通して、ＭＭＥなどが含まれるコアネットワーク（Core Network，ＥＰＣ）へ、ＴＡＵ（Tracking Area Update）を行うためにＴＡ（Tracking Area）の変更を要求する。
コアネットワークは、ＴＡＵ要求信号とともに移動端末から送られてくる該移動端末の識別番号（ＵＥ−ＩＤなど）をもとに、ＴＡ（Tracking Area）リストの更新を行う。コアネットワークは、移動端末に更新後のＴＡ（Tracking Area）リストを送信する。移動端末は、受信したＴＡ（Tracking Area）リストに基づいて、移動端末が保有するＴＡＣリストを書き換える（更新する）。その後、移動端末は、該セルで待ち受け動作に入る。
ＬＴＥ、ＬＴＥ−ＡおよびＵＭＴＳ（Universal Mobile Telecommunication System）においては、ＣＳＧ（Closed Subscriber Group）セルの導入が検討されている。前述したように、ＣＳＧセルに登録した一つまたは複数の移動端末のみにアクセスが許される。ＣＳＧセルと登録された一つまたは複数の移動端末とが一つのＣＳＧを構成する。このように構成されたＣＳＧには、ＣＳＧ−ＩＤと呼ばれる固有の識別番号が付される。一つのＣＳＧには、複数のＣＳＧセルがあってもよい。移動端末は、どれか一つのＣＳＧセルに登録すれば、そのＣＳＧセルが属するＣＳＧの他のＣＳＧセルにアクセス可能となる。
また、ＬＴＥおよびＬＴＥ−ＡでのＨｏｍｅ−ｅＮＢやＵＭＴＳでのＨｏｍｅ−ＮＢが、ＣＳＧセルとして使われることがある。ＣＳＧセルに登録した移動端末は、ホワイトリストを有する。具体的には、ホワイトリストはＳＩＭ（Subscriber Identity Module）またはＵＳＩＭに記憶される。ホワイトリストには、移動端末が登録したＣＳＧセルのＣＳＧ情報が格納される。ＣＳＧ情報として具体的には、ＣＳＧ−ＩＤ、ＴＡＩ（Tracking Area Identity）、ＴＡＣなどが考えられる。ＣＳＧ−ＩＤとＴＡＣとが対応付けられていれば、どちらか一方でよい。また、ＣＳＧ−ＩＤおよびＴＡＣと、ＥＣＧＩとが対応付けられていれば、ＥＣＧＩでもよい。
以上から、ホワイトリストを有しない（本発明においては、ホワイトリストが空（empty）の場合も含める）移動端末は、ＣＳＧセルにアクセスすることは不可能であり、ｎｏｎ−ＣＳＧセルのみにしかアクセスできない。一方、ホワイトリストを有する移動端末は、登録したＣＳＧ−ＩＤのＣＳＧセルにも、ｎｏｎ−ＣＳＧセルにもアクセスすることが可能となる。
ＨｅＮＢおよびＨＮＢに対しては、様々なサービスへの対応が求められている。例えば、あるサービスでは、オペレータは、ある決められたＨｅＮＢおよびＨＮＢに移動端末を登録させ、登録した移動端末のみにＨｅＮＢおよびＨＮＢのセルへのアクセスを許可することで、該移動端末が使用できる無線リソースを増大させて、高速に通信を行えるようにする。その分、オペレータは、課金料を通常よりも高く設定する。
このようなサービスを実現するために、登録した（加入した、メンバーとなった）移動端末のみがアクセスできるＣＳＧ（Closed Subscriber Group）セルが導入されている。ＣＳＧ（Closed Subscriber Group）セルは、商店街やマンション、学校、会社などへ数多く設置されることが要求される。例えば、商店街では店舗毎、マンションでは部屋毎、学校では教室毎、会社ではセクション毎にＣＳＧセルを設置し、各ＣＳＧセルに登録したユーザのみが該ＣＳＧセルを使用可能とするような使用方法が要求されている。
ＨｅＮＢ／ＨＮＢは、マクロセルのカバレッジ外での通信を補完するため（エリア補完型ＨｅＮＢ／ＨＮＢ）だけでなく、上述したような様々なサービスへの対応（サービス提供型ＨｅＮＢ／ＨＮＢ）が求められている。このため、ＨｅＮＢ／ＨＮＢがマクロセルのカバレッジ内に設置される場合も生じる。
実施の形態１で解決する課題について、以下に再度説明する。ＭＴＣなどにおいては、低消費電力化を図るために、周期的に実行するＬＡＵ（Location Area Update）処理、ＲＡＵ（Routing Area Update）処理およびＴＡＵ（Tracking Area Update）処理の長周期化の対策が開示されている（非特許文献１１ ６．２０章参照）。
図１３は、ＬＴＥ方式の通信システムにおいて周期的に実行するＴＡＵ処理のシーケンスの一例を示す図である（非特許文献１３参照）。
ステップＳＴ１３０１において、ＵＥは、ｅＮＢ経由でＭＭＥに、ＴＡＵ要求（TAU Request）メッセージを通知する。具体的には、ＵＥは、ＮＡＳ（Non-Access-Stratum）プロトコルを用いて、ＴＡＵ要求メッセージを通知する（非特許文献１４参照）。
ステップＳＴ１３０２において、ＭＭＥは、ＨＳＳ（Home Subscriber Server）の情報を用いて、ＵＥの認証（authentication）およびセキュリティ（security）制御の処理を行う。
ステップＳＴ１３０１でＵＥからのＴＡＵ要求メッセージを受信したＭＭＥは、ＴＡＵ要求を許可する場合、ステップＳＴ１３０３において、ｅＮＢ経由でＵＥに、ＴＡＵアクセプト（TAU Accept）メッセージを通知する。具体的には、ＭＭＥは、ＮＡＳ（Non-Access-Stratum）プロトコルを用いて、ＴＡＵアクセプトメッセージを通知する（非特許文献１４参照）。
ステップＳＴ１３０３でＭＭＥからのＴＡＵアクセプトメッセージを受信したＵＥは、ステップＳＴ１３０４において、ｅＮＢ経由でＭＭＥに、ＴＡＵコンプリート（TAU Complete）メッセージを通知する。具体的には、ＵＥは、ＮＡＳ（Non-Access-Stratum）プロトコルを用いて、ＴＡＵコンプリートメッセージを通知する（非特許文献１４参照）。
以上のステップＳＴ１３０１〜ステップＳＴ１３０４の処理をまとめてステップＳＴ１３０５とし、ステップＳＴ１３０５の処理を、ＴＡＵ処理（TAU Procedure）と称することとする。
例えば、周期ＴＡＵタイマ（periodic TAU Timer）の設定周期毎に、ＴＡＵを実行する場合について説明すると、以下のようになる。周期ＴＡＵタイマ（periodic TAU Timer）には、周期的に実行するＴＡＵの周期が設定される。
周期ＴＡＵタイマ（periodic TAU Timer）のＴＡＵの周期１３０６が満了した場合、ステップＳＴ１３０７において、ＴＡＵ処理（TAU Procedure）が実行される。ステップＳＴ１３０７では、前述のステップＳＴ１３０１〜ステップＳＴ１３０４の処理と同様の処理が行われる。
また、周期ＴＡＵタイマ（periodic TAU Timer）のＴＡＵの周期１３０８が満了した場合、ステップＳＴ１３０９において、ＴＡＵ処理（TAU Procedure）が実行される。ステップＳＴ１３０９では、前述のステップＳＴ１３０１〜ステップＳＴ１３０４の処理と同様の処理が行われる。
以下、同様にして、周期ＴＡＵタイマ（periodic TAU Timer）のＴＡＵの周期１３１０が満了した場合、ステップＳＴ１３１１において、ＴＡＵ処理（TAU Procedure）が実行される。周期ＴＡＵタイマ（periodic TAU Timer）のＴＡＵの周期１３１２が満了した場合、ステップＳＴ１３１３において、ＴＡＵ処理（TAU Procedure）が実行される。周期ＴＡＵタイマ（periodic TAU Timer）のＴＡＵの周期１３１４が満了した場合、ステップＳＴ１３１５において、ＴＡＵ処理（TAU Procedure）が実行される。
次に、ＭＴＣなどの低消費電力化を図るために、周期的に実行するＴＡＵの長周期化の対策が行われた場合について説明する。
例えば、長周期ＴＡＵタイマ（long periodic TAU Timer）の設定周期毎に、ＴＡＵを実行する場合について説明すると、以下のようになる。長周期ＴＡＵタイマ（long periodic TAU Timer）には、周期的に実行するＴＡＵの周期が設定される。長周期ＴＡＵタイマ（long periodic TAU Timer）に設定されるＴＡＵの周期は、前述の周期ＴＡＵタイマ（periodic TAU Timer）に設定されるＴＡＵの周期に比べて長い。
長周期ＴＡＵタイマ（long periodic TAU Timer）のＴＡＵの周期１３１６が満了した場合、ステップＳＴ１３１５において、ＴＡＵ処理（TAU Procedure）が実行される。ステップＳＴ１３１５では、前述のステップＳＴ１３０１〜ステップＳＴ１３０４の処理と同様の処理が行われる。
このように、周期的に実行するＬＡＵ処理、ＲＡＵ処理およびＴＡＵ処理を長周期化することによって、例えば図１３のステップＳＴ１３０７、ステップＳＴ１３０９、ステップＳＴ１３１１、およびステップＳＴ１３１３のＴＡＵ処理（TAU Procedure）を省略することが可能となる。これによって、ＭＴＣなどの低消費電力化を図ることができる。
しかしながら、周期的に実行するＬＡＵ処理、ＲＡＵ処理およびＴＡＵ処理を長周期化すると、例えば図１３のステップＳＴ１３０７、ステップＳＴ１３０９、ステップＳＴ１３１１、およびステップＳＴ１３１３のＴＡＵ処理（TAU Procedure）において実行していた、ネットワークによるモニタリングまたは移動監視の処理が実行されないこととなる。したがって、モニタリングおよび移動監視の観点においては、悪影響があるという問題がある。
実施の形態１での解決策を以下に示す。ＵＥとｅＮＢとの間におけるＵＥモニタリング用メッセージを設ける。ＵＥは、周期的にＵＥモニタリング用メッセージをｅＮＢへ送信する。ｅＮＢは、ＵＥから周期内に、ＵＥモニタリング用メッセージを受信した場合は、ＵＥ検出と判断する。ｅＮＢは、ＵＥから周期内に、ＵＥモニタリング用メッセージを受信しない場合は、ＵＥ不検出と判断する。このようにＵＥモニタリング用メッセージを用いることによって、ＴＡＵ処理を長周期化した場合でも、モニタリングが必要な頻度でモニタリングを行うことが可能となる。
以下の説明では、ＵＥがｅＮＢにＵＥモニタリング用メッセージを送信する周期を、「ＵＥモニタリング周期」と称することもある。
またＵＥが、タイマ満了後、あるいはタイマ満了を契機に、ＵＥモニタリング用メッセージを送信するようにしてもよい。このタイマを、「ＵＥモニタリングタイマ」と称することもある。
以下、主にＵＥモニタリング周期を用いて説明するが、ＵＥモニタリングタイマを用いることもできる。
ｅＮＢは、ＵＥから送信されるＵＥモニタリング用メッセージを受信した場合、送達確認情報をＵＥに送信してもよい。あるいは、ｅＮＢは、ＵＥから周期内に、ＵＥモニタリング用メッセージを受信した場合、送達確認情報をＵＥに送信してもよい。送達確認情報の具体例としては、ＲＬＣレイヤにおける応答メッセージ（ＡＣＫ）がある。送達確認情報は、ステータスＰＤＵ（Status PDU）であってもよい。
ｅＮＢは、ＵＥモニタリング用メッセージを用いて、ＵＥが存在するか否かの判断（以下「不検出判断」と称することもある）をしてもよい。ｅＮＢは、ＵＥが存在しない、すなわちＵＥ不検出と判断した場合、不検出処理を実行してもよい。
不検出判断の具体例として、以下の（１）〜（７）の７つを開示する。
（１）ｅＮＢは、周期内にＵＥモニタリング用メッセージを受信しない場合は、ＵＥ不検出と判断する。ｅＮＢは、周期内にＵＥモニタリング用メッセージを受信した場合は、ＵＥが存在する、すなわちＵＥ検出と判断する。
（２）ｅＮＢは、周期内にＵＥモニタリング用メッセージを受信しないことが、予め決められた回数連続して発生した場合は、不検出と判断する。予め決められた回数は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた回数を準静的に決定する場合は、ｅＮＢから、あるいはｅＮＢ経由で、ＵＥに、予め決められた回数を通知すればよい。
予め決められた回数の通知方法の具体例として、以下の（２−１）〜（２−４）の４つを開示する。
（２−１）報知情報によって通知する。
（２−２）個別情報によって通知する。
（２−３）ＴＡＵ処理によって通知する。具体的には、ＴＡＵアクセプト（TAU Accept）メッセージなどによって通知する。
（２−４）アタッチ処理によって通知する。具体的には、アタッチアクセプト（Attach Accept）、ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージなどによって通知する。
（３）ｅＮＢは、予め決められた期間内にＵＥモニタリング用メッセージを受信しない場合は、ＵＥ不検出と判断する。予め決められた期間は、ＵＥがＵＥモニタリング用メッセージを送信する周期よりも長くすればよい。予め決められた期間は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた期間を準静的に決定する場合は、ｅＮＢから、あるいはｅＮＢ経由で、ＵＥに、予め決められた期間を通知すればよい。予め決められた期間の通知方法の具体例は、前記不検出判断の具体例（２）における予め決められた回数の通知方法と同様であるので、説明を省略する。
（４）周期的なＬＡＵ処理、ＲＡＵ処理およびＴＡＵ処理と併用してもよい。ｅＮＢは、周期内にＵＥモニタリング用メッセージを受信した場合は、ＵＥ検出と判断する。ｅＮＢは、周期内にＵＥモニタリング用メッセージを受信しない場合は、ＭＭＥに通知する。ＭＭＥは、周期内にＴＡＵ処理が実行された場合は、ＵＥ検出と判断する。ＭＭＥは、周期内にＴＡＵ処理が実行されない場合は、ＵＥ不検出と判断する。これによって、ｅＮＢがＵＥモニタリング用メッセージを受信しない理由が、該ｅＮＢのカバレッジ外へのＵＥの移動である場合にも、ＭＭＥは適切に処理することができる。つまり、ＭＭＥは、適切にＵＥ検出と判断することができる。
（５）ｅＮＢは、周期内にＵＥモニタリング用メッセージを受信しない場合、周辺ｅＮＢに、その旨の通知（以下「ＵＥモニタリング用メッセージパラメータ通知」と称する場合がある）を送信してもよい。ＵＥモニタリング用メッセージパラメータ通知は、Ｘ２インタフェース、またはＳ１インタフェースを用いて、周辺ｅＮＢに送信されてもよい。
ＵＥモニタリング用メッセージパラメータ通知を受信した周辺ｅＮＢは、ＵＥからのＵＥモニタリング用メッセージの受信を開始する。ＵＥからのＵＥモニタリング用メッセージを受信した周辺ｅＮＢは、ＵＥモニタリング用メッセージパラメータ通知を送信したｅＮＢに、ＵＥモニタリング用メッセージを受信した旨を通知する。ＵＥからのＵＥモニタリング用メッセージを受信しない周辺ｅＮＢは、ＵＥモニタリング用メッセージパラメータ通知を送信したｅＮＢに、ＵＥモニタリング用メッセージを受信しない旨を通知する。
ｅＮＢは、周辺ｅＮＢから、ＵＥモニタリング用メッセージを受信した旨の通知を受信した場合は、ＵＥ検出と判断する。また、ｅＮＢは、周辺ｅＮＢから、ＵＥモニタリング用メッセージを受信しない旨の通知を受信した場合、あるいは周辺ｅＮＢから、ＵＥモニタリング用メッセージを受信しない場合は、ＵＥ不検出と判断する。
ＵＥモニタリング用メッセージパラメータ通知の送信方法の具体例として、以下の（５−１），（５−２）の２つを開示する。
（５−１）新たにＸ２シグナル、またはＸ２メッセージを設ける。あるいは新たにＳ１シグナル、またはＳ１メッセージを設ける。
（５−２）既存のＸ２シグナル、またはＸ２メッセージを用いる。あるいは既存のＳ１シグナル、またはＳ１メッセージを設ける。本具体例（５−２）は、具体例（５−１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（５−２）によって、通信システムが複雑化することを回避することができる。
Ｘ２シグナル、またはＳ１シグナルにマッピングするパラメータの具体例として、以下の（５−ａ）〜（５−ｄ）の４つを開示する。
（５−ａ）該移動端末の識別番号（ＵＥ−ＩＤなど）。
（５−ｂ）該移動端末が、ＵＥモニタリング用メッセージをｅＮＢに送信するＵＥである旨。ＭＴＣである旨であってもよい。
（５−ｃ）ＵＥモニタリング周期。
（５−ｄ）前記（５−ａ）〜（５−ｃ）の組合せ。
本具体例（５）によって、ｅＮＢがＵＥモニタリング用メッセージを受信しない理由が、該ｅＮＢのカバレッジ外へのＵＥの移動である場合にも、適切にＵＥを検出することができる。加えて、移動先のｅＮＢにおいても、例えば周期などが同じ条件で、ＵＥがＵＥモニタリング用メッセージの送信を継続することができるという効果を得ることができる。また、移動先のｅＮＢとＵＥとが新たにパラメータのやり取りをすることなく、ＵＥがＵＥモニタリング用メッセージの送信を継続することができ、制御遅延を防止することができるという効果を得ることができる。
（６）前記（１）〜（５）においてＵＥ不検出と判断した後に、該ＵＥ宛にページングを通知する。該ＵＥから応答が有る場合は、ＵＥ検出と判断する。該ＵＥから応答が無い場合は、ＵＥ不検出と判断する。
（７）前記（１）〜（６）の組合せ。
不検出処理の具体例として、以下の（１）〜（３）の３つを開示する。
（１）ｅＮＢは、予め定められた通知先にＵＥ不検出を通知する。予め定められた通知先の具体例としては、ＯＡＭ（Operation Administration and Maintenance）、アプリケーションサーバ、およびＭＴＣサーバなどがある。
（２）デタッチ処理を開始する。デタッチ処理をトリガとする。
（３）前記（１），（２）の組合せ。
ＵＥが、ＵＥモニタリング用メッセージをｅＮＢに通知する目的の具体例として、以下の（１）〜（４）の４つを開示する。
（１）「生きている」ことを相手に伝えるため。キープアライブ（keep alive）のため。
（２）存在することを相手に伝えるため。
（３）ダウンしていないことを伝えるため。正常に動作していることを伝えるため。
（４）前記（１）〜（３）の組合せ。
ＵＥモニタリング用メッセージの具体例として、以下の（１）〜（４）の４つを開示する。
（１）Ｕｕ点のみのメッセージとする。Ｕｕ点とは、ＵＥとｅＮＢ、ＵＥとＨｅＮＢ、またはＵＥとＲＮのインタフェース点である。本具体例（１）では、ＴＡＵは、ＵＥからＭＭＥに通知されるので、Ｕｕ点とＳ１点に関わるメッセージとなる（図１３のステップＳＴ１３０１、ステップＳＴ１３０２、ステップＳＴ１３０３、ステップＳＴ１３０４参照）。本具体例（１）によって、ＵＥとｅＮＢとの間の通信時間が短くなり、ＵＥの低消費電力化が可能となる。
（２）ｅＮＢの上位装置への通知が不要なメッセージとする。上位装置の具体例としては、ＭＭＥ、ＨＳＳなどである。本具体例（２）では、ＵＥモニタリング用メッセージと異なり、ＴＡＵは、ＭＭＥおよびＨＳＳへの通知が必要なメッセージとなる（図１３のステップＳＴ１３０１、ステップＳＴ１３０２参照）。本具体例（２）によって、ＵＥとｅＮＢとの間の通信時間が短くなり、ＵＥの低消費電力化が可能となる。
（３）ＲＲＣメッセージとする。本具体例（３）では、ＵＥモニタリング用メッセージと異なり、ＴＡＵは、ＮＡＳメッセージとなる。
（４）前記（１）〜（３）の組合せ。
ＵＥモニタリング用メッセージをＲＲＣメッセージとする場合の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＲＲＣシグナル、あるいはＲＲＣメッセージを設ける。
（２）既存のＲＲＣシグナル、あるいはＲＲＣメッセージを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＲＲＣシグナルにマッピングするパラメータの具体例として、以下の（１）〜（４）の４つを開示する。
（１）ＵＥモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨など。
（２）ＵＥの識別子。ＵＥの識別子としては、移動端末識別子（ＵＥ−ＩＤ）でもよいし、国際移動加入者識別番号（International Mobile Subscriber Identity：ＩＭＳＩ）であってもよい。
（３）シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、ＴＡＵ処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
（４）前記（１）〜（３）の組合せ。
次に、既存のＲＲＣシグナルを用いる場合の具体例を開示する。メジャメントレポート（Measurement Report）メッセージを用いる。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨などがある。
ＵＥモニタリング用メッセージを、ＴＡＵの認証（authentication）処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、ｅＮＢにおいて、不正なＵＥの成りすましによるＵＥモニタリング用メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にＴＡＵの認証（authentication）処理時に実行すればよい。
また、メッセージ認証コード（Message Authentication Code）を付加して、メッセージ認証を実行してもよい。
ｅＮＢにおいて、ＵＥの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った処理（以下「不正ＵＥ検出処理」という）を実行してもよい。不正ＵＥ検出処理の具体例として、以下の（１）〜（３）の３つを開示する。
（１）ｅＮＢは、予め定められた通知先に不正ＵＥ検出を通知する。予め定められた通知先の具体例としては、ＯＡＭ、アプリケーションサーバ、およびＭＴＣサーバなどがある。
（２）デタッチ処理を開始する。デタッチ処理をトリガとする。
（３）前記（１），（２）の組合せ。
ＵＥモニタリング周期の設定方法の具体例として、以下の（１）〜（４）の４つを開示する。
（１）報知情報によって通知する。本具体例（１）によれば、ＵＥ毎に通知する必要がないので、無線リソースを有効に活用することができるという効果を得ることができる。
（２）個別情報によって通知する。本具体例（２）によって、ＵＥ毎に設定値を決定することができるので、柔軟な通信システムの構築が可能となる。
（３）ＴＡＵ処理によって通知する。具体的には、ＴＡＵアクセプト（TAU Accept）メッセージなどによって通知する。
（４）アタッチ処理によって通知する。具体的には、アタッチアクセプト（Attach Accept）メッセージ、またはＲＲＣ接続再設定（RRC Connection Reconfiguration）などによって通知する。
ＵＥモニタリング周期と、周期的に実行するＴＡＵの周期とが、同時に満了する場合の動作の具体例として、以下の（１），（２）の２つを開示する。
（１）ＵＥモニタリング処理およびＴＡＵ処理の両方の処理を実行する。本具体例（１）によって、周期毎に処理を決定することができるので、制御の複雑性を回避することができるという効果を得ることができる。
（２）ＵＥモニタリング処理は実行せずに、ＴＡＵ処理を実行するようにしてもよい。本具体例（２）によれば、ＵＥは、ＵＥモニタリング用メッセージの送信を行わなくてもよい。ネットワーク側のＵＥのモニタリングは、ＴＡＵ処理によって実行することが可能であるので、ＵＥモニタリング用メッセージの送信を省略することによって、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
ＵＥモニタリング周期、および周期的に実行するＴＡＵの周期の設定値の具体例としては、周期ＴＡＵタイマ（periodic TAU timer）に設定される値が挙げられる。
周期的に実行するＴＡＵの周期は、ＵＥモニタリング周期の整数倍としてもよく、整数の逆数倍（１／整数倍）としてもよい。これによって、ＵＥモニタリング周期と、周期的に実行するＴＡＵの周期とが同時に満了する機会が増え、ＵＥの低消費電力化を図ることができるという効果が得られ易くなる。
ＵＥモニタリング周期の設定値の具体例として、以下の（１）〜（４）の４つを開示する。
（１）無線フレーム数。
（２）サブフレーム数。
（３）ＵＥモニタリング周期を、周期的に実行するＴＡＵの周期に対する整数倍、または整数の逆数倍（１／整数倍）とする場合において、「整数」をＵＥモニタリング周期の設定値とする。
（４）前記（１）〜（３）の組合せ。
次に、図１４を用いて、実施の形態１における通信システムのシーケンスの具体例について説明する。図１４は、実施の形態１における通信システムのシーケンスの一例を示す図である。図１４では、ＵＥが、ＵＥモニタリング周期毎に、ＵＥモニタリング用メッセージを送信する場合のシーケンスを示している。図１４に示すシーケンスは、図１３に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ１４１４において、前述のステップＳＴ１３０５と同様にして、ＴＡＵ処理（TAU Procedure）が実行される。
ステップＳＴ１４０２において、ＵＥは、ＵＥモニタリング周期１４０１で、ｅＮＢにＵＥモニタリング用メッセージを通知する。
ステップＳＴ１４０２でＵＥモニタリング用メッセージを受信したｅＮＢは、ステップＳＴ１４０３において、ＵＥに送達確認情報を送信する。
以上のステップＳＴ１４０２およびステップＳＴ１４０３の処理をまとめてステップＳＴ１４０４とし、ステップＳＴ１４０４の処理を、ＵＥモニタリング処理と称することとする。
ステップＳＴ１４０６において、ＵＥとｅＮＢとの間では、ＵＥモニタリング周期１４０５で、ＵＥモニタリング処理が実行される。
またステップＳＴ１４０８において、ＵＥとｅＮＢとの間では、ＵＥモニタリング周期１４０７で、ＵＥモニタリング処理が実行される。
またステップＳＴ１４１０において、ＵＥとｅＮＢとの間では、ＵＥモニタリング周期１４０９で、ＵＥモニタリング処理が実行される。
ＵＥモニタリング周期１４１１と、周期的に実行するＴＡＵの周期１４１２とが同時に発生する場合は、ステップＳＴ１４１３において、ＴＡＵ処理（TAU Procedure）が実行される。
以上の実施の形態１によって、以下の効果を得ることができる。ＵＥモニタリング処理を新たに設けることによって、周期的なＴＡＵ処理の周期を長期化しても、ＵＥモニタリング処理によりモニタリング可能となる。
ＵＥモニタリング処理を、ＴＡＵ処理と比較して低消費電力可能な構成とすることにより、低消費電力化を図ることができるという効果を得ることもできる。
ＵＥモニタリング周期と、ＴＡＵの周期とを別個に設定することができる。これにより、ＴＡＵ処理の柔軟な運用が可能となる効果を得ることができる。
以上のことによって、通信端末装置の低消費電力化とネットワークによるモニタリングおよび移動監視の適切な実現が可能となる。
したがって、本実施の形態の通信システムによれば、処理負荷および消費電力を抑えて、ＵＥの状態を確認することができる。
また本実施の形態では、ＵＥモニタリング用メッセージは、ＵＥからｅＮＢに送信され、ｅＮＢは、ＵＥからＵＥモニタリング用メッセージを受信したか否かに基づいて、ＵＥの状態を判断する。これによって、前述のように処理負荷および消費電力を抑えてＵＥの状態を確認することができる通信システムを実現することができる。
実施の形態１ 変形例１．
実施の形態１の変形例１では、前述の実施の形態１の更なる改善点について示す。本変形例では、前述の実施の形態１の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態１と同様とする。
ｅＮＢは、ＵＥからＵＥモニタリング用メッセージを受信した場合、ＵＥモニタリング用メッセージに対する応答メッセージをＵＥに送信する。本変形例１では、応答メッセージに、暗号化（cipher）を施すようにすればよい。実施の形態１の送達確認情報が単純な確認メッセージ、例えばＡＣＫ情報と比較して、本変形例１では、ＵＥモニタリング用メッセージに対する暗号化を実行した応答メッセージを送信するので、ＵＥによるｅＮＢの成りすましを検出することが可能となる。
ＵＥモニタリング用メッセージに対する応答メッセージを、ＲＲＣメッセージとしてもよい。ＵＥモニタリング用メッセージに対する応答メッセージをＲＲＣメッセージとする場合の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＲＲＣシグナル、あるいはＲＲＣメッセージを設ける。
（２）既存のＲＲＣシグナル、あるいはＲＲＣメッセージを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＲＲＣシグナルにマッピングするパラメータの具体例として、以下の（１）〜（４）の４つを開示する。
（１）ＵＥモニタリング用メッセージに対する応答メッセージである旨。
（２）セルの識別子。具体的には、ＰＣＩ、ＣＧＩ、ＥＣＧＩであってもよい。
（３）シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、ＴＡＵ処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
（４）前記（１）〜（３）の組合せ。
次に、既存のＲＲＣシグナルを用いる場合の具体例を開示する。ＲＲＣ接続再設定「RRC Connection Reconfiguration」メッセージを用いる。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。ＵＥモニタリング用メッセージに対する応答メッセージである旨は、既存のＲＲＣシグナリングに設定されている「理由（cause）」のパラメータに含めて通知されてもよい。
ＵＥモニタリング用メッセージに対する応答メッセージを、ＴＡＵの認証（authentication）処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、ＵＥにおいて、不正なｅＮＢの成りすましによるＵＥモニタリング用メッセージに対する応答メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にＴＡＵの認証（authentication）処理時に実行すればよい。
また、メッセージ認証コード（Message Authentication Code）を付加して、メッセージ認証を実行してもよい。
ＵＥにおいて、ｅＮＢの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った処理（以下「不正ｅＮＢ検出処理」という）を実行してもよい。不正ｅＮＢ検出処理の具体例としては、内部情報の削除などがある。
次に、図１４を用いて、実施の形態１の変形例１における通信システムのシーケンスの具体例について説明する。
ステップＳＴ１４０２でＵＥモニタリング用メッセージを受信したｅＮＢは、ステップＳＴ１４０３において、ＵＥにＵＥモニタリング用メッセージに対する応答メッセージを送信する。
以上の実施の形態１の変形例１によって、実施の形態１の効果に加えて、以下の効果を得ることができる。ＵＥによるｅＮＢの成りすましを検出することが可能となる。
実施の形態１ 変形例２．
実施の形態１の変形例２では、前述の実施の形態１と同じ課題について、別の解決策を開示する。実施の形態１の変形例２での解決策を以下に示す。本変形例では、前述の実施の形態１の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態１と同様とする。
本変形例では、ＵＥとｅＮＢとの間におけるＵＥモニタリング用メッセージを設ける。ｅＮＢは、周期的にＵＥモニタリング用メッセージをＵＥに送信する。ＵＥは、ＵＥモニタリング用メッセージを受信した場合は、送達確認用情報をｅＮＢに通知する。ｅＮＢは、送達確認用情報を受信した場合は、ＵＥ検出と判断する。ｅＮＢは、送達確認用情報を受信しない場合は、ＵＥ不検出と判断する。このようにＵＥモニタリング用メッセージを用いることによって、ＴＡＵ処理を長周期化した場合でも、モニタリングが必要な頻度でモニタリングを行うことが可能となる。
以下の説明では、ｅＮＢがＵＥにＵＥモニタリング用メッセージを送信する周期を、「ＵＥモニタリング周期」と称することもある。
またｅＮＢが、タイマ満了後、あるいはタイマ満了を契機に、ＵＥモニタリング用メッセージを送信するようにしてもよい。このタイマを、「ＵＥモニタリングタイマ」と称することもある。
以下、主にＵＥモニタリング周期を用いて説明するが、ＵＥモニタリングタイマを用いることもできる。
送達確認情報の具体例としては、ＲＬＣレイヤにおける応答メッセージ（ＡＣＫ）がある。送達確認情報は、ステータスＰＤＵ（Status PDU）であってもよい。
ｅＮＢは、ＵＥモニタリング用メッセージに対する送達確認情報を用いて、ＵＥが存在するか否かの判断（以下「不検出判断」と称することもある）をしてもよい。ｅＮＢは、ＵＥが存在しない、すなわちＵＥ不検出と判断した場合、不検出処理を実行してもよい。
不検出判断の具体例として、以下の（１）〜（６）の６つを開示する。
（１）ｅＮＢは、周期内に送達確認情報を受信しない場合は、ＵＥ不検出と判断する。ｅＮＢは、周期内に送達確認情報を受信した場合は、ＵＥが存在する、すなわちＵＥ検出と判断する。
（２）ｅＮＢは、周期内に送達確認情報を受信しないことが、予め決められた回数連続して発生した場合は、ＵＥ不検出と判断する。予め決められた回数は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた回数を準静的に決定する場合は、ｅＮＢから、あるいはｅＮＢ経由で、ＵＥに、予め決められた回数を通知すればよい。
予め決められた回数の通知方法の具体例として、以下の（２−１）〜（２−４）の４つを開示する。
（２−１）報知情報によって通知する。
（２−２）個別情報によって通知する。
（２−３）ＴＡＵ処理によって通知する。具体的には、ＴＡＵアクセプト（TAU Accept）メッセージなどによって通知する。
（２−４）アタッチ処理によって通知する。具体的には、アタッチアクセプト（Attach Accept）メッセージ、ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージなどによって通知する。
（３）ｅＮＢは、予め決められた期間内に送達確認情報を受信しない場合は、ＵＥ不検出と判断する。予め決められた期間は、ＵＥがＵＥモニタリング用メッセージを送信する周期よりも長くすればよい。予め決められた期間は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた期間を準静的に決定する場合は、ｅＮＢから、あるいはｅＮＢ経由で、ＵＥに、予め決められた期間を通知すればよい。予め決められた期間の通知方法の具体例は、前記不検出判断の具体例（２）における予め決められた回数の通知方法と同様であるので、説明を省略する。
（４）周期的なＬＡＵ処理、ＲＡＵ処理およびＴＡＵ処理と併用してもよい。ｅＮＢは、周期内に送達確認情報を受信した場合は、ＵＥ検出と判断する。ｅＮＢは、周期内に送達確認情報を受信しない場合は、ＭＭＥに通知する。ＭＭＥは、周期内にＴＡＵ処理が実行された場合は、ＵＥ検出と判断する。ＭＭＥは、周期内にＴＡＵ処理が実行されない場合は、ＵＥ不検出と判断する。これによって、ｅＮＢがＵＥモニタリング用メッセージを受信しない理由が、該ｅＮＢのカバレッジ外へのＵＥの移動である場合にも、ＭＭＥは適切に処理することができる。つまり、ＭＭＥは、適切にＵＥ検出と判断することができる。
（５）前記（１）〜（４）においてＵＥ不検出と判断した後に、該ＵＥ宛にページングを通知する。該ＵＥから応答が有る場合は、ＵＥ検出と判断する。該ＵＥから応答が無い場合は、ＵＥ不検出と判断する。
（６）前記（１）〜（５）の組合せ。
不検出処理の具体例は、前述の実施の形態１と同様であるので、説明を省略する。
また、ＵＥは、周期内にＵＥモニタリング用メッセージを受信しない場合、その旨をｅＮＢに通知してもよい。これによって、ｅＮＢ、あるいはネットワーク側が異常を検出することが可能となる。
ｅＮＢが、ＵＥモニタリング用メッセージをＵＥに通知する目的の具体例として、以下の（１）〜（４）の４つを開示する。
（１）「生きている」の問合せ。
（２）ＵＥが存在することの問合せ。
（３）ＵＥが正常に動作していることの問合せ。
（４）前記（１）〜（３）の組合せ。
ＵＥモニタリング用メッセージの具体例として、以下の（１）〜（３）の３つを開示する。
（１）Ｕｕ点のみのメッセージとする。Ｕｕ点とは、ＵＥとｅＮＢ、ＵＥとＨｅＮＢ、またはＵＥとＲＮのインタフェース点である。
（２）ＲＲＣメッセージとする。本具体例（２）では、ＵＥモニタリング用メッセージと異なり、ＴＡＵは、ＮＡＳメッセージとなる。
（３）前記（１），（２）の組合せ。
ＵＥモニタリング用メッセージをＲＲＣメッセージとする場合の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＲＲＣシグナル、あるいはＲＲＣメッセージを設ける。
（２）既存のＲＲＣシグナル、あるいはＲＲＣメッセージを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＲＲＣシグナルにマッピングするパラメータの具体例として、以下の（１）〜（４）の４つを開示する。
（１）「生きている」の問合せである旨、ＵＥが存在することの問合せである旨、ＵＥが正常に動作していることの問合せである旨など。
（２）セルの識別子。具体的には、ＰＣＩ、ＣＧＩ、ＥＣＧＩであってもよい。
（３）シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、ＴＡＵ処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
（４）前記（１）〜（３）の組合せ。
次に、既存のＲＲＣシグナルを用いる場合の具体例を以下に開示する。ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージを用いる。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例としては、「生きている」の問合せである旨、ＵＥが存在することの問合せである旨、ＵＥが正常に動作していることの問合せである旨などがある。
ＵＥモニタリング用メッセージを、ＴＡＵの認証（authentication）処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、ＵＥにおいて、不正なｅＮＢの成りすましによるＵＥモニタリング用メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にＴＡＵの認証（authentication）処理時に実行すればよい。
また、メッセージ認証コード（Message Authentication Code）を付加して、メッセージ認証を実行してもよい。
ＵＥにおいて、ｅＮＢの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った不正ｅＮＢ検出処理を実行してもよい。不正ｅＮＢ検出処理の具体例としては、内部情報の削除などがある。
ＵＥモニタリング周期の設定値の具体例として、以下の（１）〜（５）の５つを開示する。
（１）無線フレーム数。
（２）サブフレーム数。
（３）ＵＥモニタリング周期を、周期的に実行するＴＡＵの周期に対する整数倍、または整数の逆数倍（１／整数倍）とする場合において、「整数」をＵＥモニタリング周期の設定値とする。
（４）ページングメッセージを受信するタイミングと同じタイミングとする。あるいは、ページングメッセージを受信するタイミングを、ＵＥモニタリング周期の整数倍、または整数の逆数倍（１／整数倍）とする。
ページングメッセージを受信するタイミングと同じタイミングとする場合の具体例としては、ＵＥモニタリング周期に、ページングフレーム（Paging Frame：ＰＦ）、またはページングオケージョン（Paging Occasion：ＰＯ）を用いる場合が挙げられる（非特許文献３参照）。これによって、ＵＥモニタリング周期を改めて設定する必要がなくなり、無線リソースを有効に活用することができるという効果を得ることができる。
また、ＵＥの動作としては、ページングメッセージを受信するタイミングとＵＥモニタリング用メッセージの受信タイミングとを合わせることができる。これによって、ＵＥによって受信回路の電源をオンするタイミングを減らすことができる。したがって、ＵＥの低消費電力化を図るという効果を得ることができる。
（５）前記（１）〜（４）の組合せ。
次に、図１５を用いて、実施の形態１の変形例２における通信システムのシーケンスの具体例について説明する。図１５は、実施の形態１の変形例２における通信システムのシーケンスの一例を示す図である。図１５では、ｅＮＢが、ＵＥモニタリング周期毎に、ＵＥモニタリング用メッセージを送信する場合のシーケンスを示している。図１５に示すシーケンスは、図１３に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ１５０２において、ｅＮＢは、ＵＥモニタリング周期１５０１で、ＵＥにＵＥモニタリング用メッセージを通知する。
ステップＳＴ１５０２でＵＥモニタリング用メッセージを受信したＵＥは、ステップＳＴ１５０３において、ｅＮＢに送達確認情報を送信する。
以上のステップＳＴ１５０２およびステップＳＴ１５０３の処理をまとめてステップＳＴ１５０４とし、ステップＳＴ１５０４の処理を、ＵＥモニタリング処理と称することとする。
ステップＳＴ１５０６において、ＵＥとｅＮＢとの間では、ＵＥモニタリング周期１５０５で、ＵＥモニタリング処理が実行される。
またステップＳＴ１５０８において、ＵＥとｅＮＢとの間では、ＵＥモニタリング周期１５０７で、ＵＥモニタリング処理が実行される。
またステップＳＴ１５１０において、ＵＥとｅＮＢとの間では、ＵＥモニタリング周期１５０９で、ＵＥモニタリング処理が実行される。
ＵＥモニタリング周期１５１１と、周期的に実行するＴＡＵの周期１５１２とが同時に発生する場合は、ステップＳＴ１５１３において、ＴＡＵ処理（TAU Procedure）が実行される。
以上の実施の形態１の変形例２によって、前述の実施の形態１と同様の効果を得ることができる。
実施の形態１ 変形例３．
実施の形態１の変形例３では、前述の実施の形態１の変形例２の更なる改善点について示す。本変形例では、前述の実施の形態１の変形例２の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態１の変形例２と同様とする。
ＵＥは、ｅＮＢからＵＥモニタリング用メッセージを受信した場合、ＵＥモニタリング用メッセージに対する応答メッセージをｅＮＢに送信する。本変形例では、応答メッセージに、暗号化（cipher）を施すようにすればよい。実施の形態１の変形例２の送達確認情報が単純な確認メッセージ、例えばＡＣＫ情報と比較して、本変形例３では、ＵＥモニタリング用メッセージに対する応答メッセージを送信するので、ｅＮＢによるＵＥの成りすましを検出することが可能となる。
ＵＥモニタリング用メッセージに対する応答メッセージを、ＲＲＣメッセージとしてもよい。ＵＥモニタリング用メッセージに対する応答メッセージをＲＲＣメッセージとする場合の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＲＲＣシグナル、あるいはＲＲＣメッセージを設ける。
（２）既存のＲＲＣシグナル、あるいはＲＲＣメッセージを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＲＲＣシグナルにマッピングするパラメータの具体例として、以下の（１）〜（４）の４つを開示する。
（１）ＵＥモニタリング用メッセージに対する応答メッセージである旨。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、ＴＡＵ処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
（４）前記（１）〜（３）の組合せ。
次に、既存のＲＲＣシグナルを用いる場合の具体例を開示する。ＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）メッセージを用いる。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。ＵＥモニタリング用メッセージに対する応答メッセージである旨は、既存のＲＲＣシグナリングに設定されている「設定理由（Establishment Cause）」のパラメータに含めて通知されてもよい。
ＵＥモニタリング用メッセージに対する応答メッセージを、ＴＡＵの認証（authentication）処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、ｅＮＢにおいて、不正なＵＥの成りすましによるＵＥモニタリング用メッセージに対する応答メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にＴＡＵの認証（authentication）処理時に実行すればよい。
また、メッセージ認証コード（Message Authentication Code）を付加して、メッセージ認証を実行してもよい。
ｅＮＢにおいて、ＵＥの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った不正ＵＥ検出処理を実行してもよい。不正ＵＥ検出処理の具体例は、前述の実施の形態１と同様であるので、説明を省略する。
次に、図１５を用いて、実施の形態１の変形例３における通信システムのシーケンスの具体例について説明する。
ステップＳＴ１５０２でＵＥモニタリング用メッセージを受信したＵＥは、ステップＳＴ１５０３において、ｅＮＢにＵＥモニタリング用メッセージに対する応答メッセージを送信する。
以上の実施の形態１の変形例３によって、実施の形態１の変形例２の効果に加えて、以下の効果を得ることができる。ｅＮＢによるＵＥの成りすましを検出することが可能となる。
実施の形態１ 変形例４．
実施の形態１の変形例４では、前述の実施の形態１と同じ課題について、別の解決策を開示する。実施の形態１の変形例４での解決策を以下に示す。
本変形例では、ＵＥは、ＲＲＣ接続（RRC Connection）を確立せずに、周期的にＵＥモニタリング用メッセージをｅＮＢに送信する。言い換えると、ＵＥは、ＲＲＣ待受け状態（ＲＲＣ＿Ｉｄｌｅ）で、周期的にＵＥモニタリング用メッセージをｅＮＢに送信する。これによって、ＲＲＣ接続の確立および解放の手続きが不要となり、ＵＥの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
ＲＲＣ接続を確立せずに、ＵＥモニタリング用メッセージを送信する方法の具体例としては、ＵＥモニタリング用メッセージを、ランダムアクセス（Random Access）処理中に送信する方法が挙げられる。この方法によれば、新たな処理を新設する必要がないので、通信システムの複雑性を回避することができるという効果を得ることができる。
既存のランダムアクセス処理について、図１６を用いて説明する（非特許文献１参照）。図１６は、ランダムアクセス処理のシーケンスの一例を示す図である。
ステップＳＴ１６０１において、ＵＥは、ｅＮＢにランダムアクセスプリアンブル（Random Access Preamble）を送信する。
ステップＳＴ１６０２において、ｅＮＢは、ＵＥにランダムアクセスレスポンス（Random Access Response）を送信する。ＰＤＣＣＨ上のランダムアクセス無線ネットワーク一時的識別子（Random Access-Radio Network Temporary Identity：ＲＡ−ＲＮＴＩ）がアドレスされる。ＤＬ−ＳＣＨによって、タイミングアライメント（Timing Alignment：ＴＡ）、初期上りグラント、セル無線ネットワーク一時的識別子（Cell Radio Network Temporary Identifier：Ｃ−ＲＮＴＩ）の割当てなどが行われる。
ステップＳＴ１６０３において、ＵＥは、ｅＮＢにスケジュールされた送信（Scheduled Transmission）を送信する。初期アクセス（initial access）が実行される。ＲＲＣレイヤによって、ＲＲＣ接続要求（RRC Connection Request）が送信される。ＵＥのＣ−ＲＮＴＩが通知される。
ステップＳＴ１６０４において、ｅＮＢは、ＵＥに競合解決（Contention Resolution）を送信する。ＲＲＣ接続のＵＥのために、ＰＤＣＣＨ上のＣ−ＲＮＴＩがアドレスされる。
ＵＥモニタリング用メッセージを、ＲＡＣＨ処理中に送信する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）ランダムアクセスプリアンブル（Random Access Preamble）を用いる。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨などがある。
（２）スケジュールされた送信（Scheduled Transmission）メッセージを用いる。さらに具体的には、ＲＲＣ接続要求（RRC Connection Request）メッセージ（非特許文献２参照）を用いる。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨などがある。これらは、前記メッセージに設定されている「設定理由（Establishment Cause）」のパラメータに含めて通知されてもよい。
ＵＥモニタリング用メッセージに対する応答メッセージを、ＲＡＣＨ処理中に送信する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）ランダムアクセスレスポンス（Random Access Response）を用いる。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。
（２）競合解決（Contention Resolution）メッセージを用いる。さらに具体的には、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージを用いる。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。
次に、図１７を用いて、実施の形態１の変形例４における通信システムのシーケンスの具体例について説明する。図１７は、実施の形態１の変形例４における通信システムのシーケンスの一例を示す図である。図１７では、ランダムアクセスプリアンブル（Random Access Preamble）を用いて、ＵＥモニタリング用メッセージを通知する場合のシーケンスを示している。図１７に示すシーケンスは、図１６に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ１７０１において、ＵＥは、ランダムアクセスプリアンブル（Random Access Preamble）を用いて、ＵＥモニタリング用メッセージをｅＮＢに送信する。
ステップＳＴ１７０２において、ｅＮＢは、ステップＳＴ１７０１で受信したランダムアクセスプリアンブル（Random Access Preamble）がＵＥモニタリング用メッセージを通知するか否かを判断する。ステップＳＴ１７０２において、ランダムアクセスプリアンブル（Random Access Preamble）がＵＥモニタリング用メッセージを通知すると判断された場合は、ステップＳＴ１７０３に移行し、ランダムアクセスプリアンブル（Random Access Preamble）がＵＥモニタリング用メッセージを通知するものではないと判断された場合は、ステップＳＴ１６０２に移行する。
具体的には、ランダムアクセスプリアンブル（Random Access Preamble）にＵＥモニタリング用メッセージである旨が含まれていない場合は、ＵＥモニタリング用メッセージを通知するものではないと判断されて、ステップＳＴ１６０２に移行する。つまり、通常のランダムアクセス処理に移行する。また、ランダムアクセスプリアンブル（Random Access Preamble）にＵＥモニタリング用メッセージである旨が含まれている場合は、ＵＥモニタリング用メッセージを通知すると判断されて、ステップＳＴ１７０３に移行する。
ステップＳＴ１７０３において、ｅＮＢは、ＵＥモニタリング用メッセージに対する送達確認情報をＵＥに送信する。送達確認情報の具体例としては、ＲＬＣレイヤにおける応答メッセージがある。送達確認情報は、ステータスＰＤＵ（Status PDU）であってもよい。ＵＥモニタリング用メッセージに対する送達確認情報は、ランダムアクセスレスポンス（Random Access Response）を用いて送信してもよい。その後、処理が終了する。つまり、ステップＳＴ１６０２およびステップＳＴ１６０４などで行われるＲＲＣ接続のための処理は行われない。
次に、図１８を用いて、実施の形態１の変形例４における通信システムのシーケンスの具体例について説明する。図１８は、実施の形態１の変形例４における通信システムのシーケンスの他の例を示す図である。図１８では、ＲＲＣ接続要求（RRC Connection Request）を用いて、ＵＥモニタリング用メッセージを通知する場合のシーケンスを示している。図１８に示すシーケンスは、図１６および図１７に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ１８０１において、ＵＥは、ＲＲＣ接続要求（RRC Connection Request）を用いて、ＵＥモニタリング用メッセージをｅＮＢに送信する。
ステップＳＴ１８０２において、ｅＮＢは、ステップＳＴ１８０１で受信したＲＲＣ接続要求（RRC Connection Request）がＵＥモニタリング用メッセージを通知するか否かを判断する。ステップＳＴ１８０２において、ＲＲＣ接続要求（RRC Connection Request）がＵＥモニタリング用メッセージを通知すると判断された場合は、ステップＳＴ１８０３に移行し、ＲＲＣ接続要求（RRC Connection Request）がＵＥモニタリング用メッセージを通知するものではないと判断された場合は、ステップＳＴ１６０４に移行する。
具体的には、ＲＲＣ接続要求（RRC Connection Request）にＵＥモニタリング用メッセージである旨が含まれていない場合は、ＵＥモニタリング用メッセージを通知するものではないと判断されて、ステップＳＴ１６０４に移行する。つまり、通常のランダムアクセス処理に移行する。また、ＲＲＣ接続要求（RRC Connection Request）にＵＥモニタリング用メッセージである旨が含まれている場合は、ＵＥモニタリング用メッセージを通知すると判断されて、ステップＳＴ１８０３に移行する。
ステップＳＴ１８０３において、ｅＮＢは、ＵＥモニタリング用メッセージに対する応答メッセージをＵＥに送信する。ＵＥモニタリング用メッセージに対する応答メッセージは、ＲＲＣ接続セットアップ（RRC Connection Setup）を用いて送信してもよい。その後、処理が終了する。つまり、ステップＳＴ１６０４などで行われるＲＲＣ接続のための処理は行われない。
ＭＭＥからｅＮＢに通知するメッセージとして、ＭＭＥの過負荷を示すメッセージが既存する。このメッセージは、Ｓ１インタフェース上の「Overload START」メッセージである（３ＧＰＰ ＴＳ３６．４１３ Ｖ１０．４．０参照）。ＭＭＥが「Over load START」メッセージを受信したｅＮＢに要求する動作は、「Overload Action」として、「Overload START」メッセージの情報要素として通知される（３ＧＰＰ ＴＳ３６．４１３ Ｖ１０．４．０参照）。「Overload Action」には、ＲＲＣ接続要求に対して、ＲＲＣ接続を拒否することが主に規定されている。
つまり、既存の技術では、ＭＭＥは、ｅＮＢに対してＲＲＣ接続（RRC Connection）を確立せずにメッセージを通知する本変形例を用いたＵＥからｅＮＢへのメッセージ通知を禁止することはできない。ＭＭＥが過負荷の場合、問題となる。
前記課題の解決策として、「Overload Action」に、ＲＲＣ接続（RRC Connection）を確立せずに行われるメッセージの通知を禁止するパラメータを追加する。これによって、ＭＭＥが過負荷の場合、ＲＲＣ接続（RRC Connection）を確立せずに行われるメッセージの通知を禁止することが可能となる。
実施の形態１の変形例４は、前述の実施の形態１または実施の形態１の変形例１と組合せて用いることが可能である。
以上の実施の形態１の変形例４によって、実施の形態１の効果に加えて、以下の効果を得ることができる。ＲＲＣ接続の確立および解放の手続きが不要となり、ＵＥの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
実施の形態１ 変形例５．
実施の形態１の変形例５では、前述の実施の形態１と同じ課題について、別の解決策を開示する。実施の形態１の変形例５での解決策を以下に示す。
本変形例では、ｅＮＢは、ＲＲＣ接続（RRC Connection）を確立せずに、周期的にＵＥモニタリング用メッセージをＵＥに送信する。言い換えると、ｅＮＢは、ＲＲＣ待受け状態（ＲＲＣ＿Ｉｄｌｅ）のＵＥに、周期的にＵＥモニタリング用メッセージを送信する。これによって、ＲＲＣ接続の確立および解放の手続きが不要となり、ＵＥの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
ＲＲＣ接続を確立せずにＵＥモニタリング用メッセージを送信する方法の具体例としては、ＵＥモニタリング用メッセージを、ページング処理中に送信する方法が挙げられる。この方法によれば、新たな処理を新設する必要がないので、通信システムの複雑性を回避することができるという効果を得ることができる。
既存のページング処理について、図１９および図２０を用いて説明する（非特許文献２参照）。図１９および図２０は、ＬＴＥ方式の通信システムにおけるページング処理のシーケンスの一例を示す図である。図１９と図２０とは、境界線ＢＬ１の位置で、つながっている。
ステップＳＴ１９０１において、ＭＭＥは、ＵＥが位置するトラッキングエリアに属するｅＮＢに、ＵＥ宛のページングメッセージ（Paging message）を送信する。
ステップＳＴ１９０２において、ｅＮＢは、ステップＳＴ１９０１で受信したページングメッセージ（Paging message）を、カバレッジ内のＵＥに送信する。
ステップＳＴ１９０３において、ＵＥは、ページングメッセージを受信するタイミングであるか否かを判断する。ステップＳＴ１９０３において、ページングメッセージを受信するタイミングであると判断された場合は、ステップＳＴ１９０４に移行し、ページングメッセージを受信するタイミングでないと判断された場合は、ステップＳＴ１９０３の処理を繰り返す。
ステップＳＴ１９０４において、ＵＥは、ページングメッセージを受信するタイミングでＰＤＣＣＨを受信し、ＰＤＣＣＨにページング無線ネットワーク一時的識別子（Paging-Radio Network Temporary Identity：Ｐ-ＲＮＴＩ）が有るか否かを判断する。換言すれば、ＵＥは、Ｐ−ＲＮＴＩがアドレスされているか否かを判断する。ステップＳＴ１９０４において、ＰＤＣＣＨにＰ-ＲＮＴＩが有ると判断された場合は、ステップＳＴ１９０５に移行し、ＰＤＣＣＨにＰ-ＲＮＴＩが無いと判断された場合は、ステップＳＴ１９０３に戻る。
ステップＳＴ１９０５において、ＵＥは、ＲＲＣ＿ＩＤＬＥであるか否かを判断する。ステップＳＴ１９０５において、ＲＲＣ＿ＩＤＬＥであると判断された場合は、ステップＳＴ１９０６に移行し、ＲＲＣ＿ＩＤＬＥでないと判断された場合は、図２０のステップＳＴ１９１１に移行する。
ステップＳＴ１９０６において、ＵＥは、ページングメッセージ中のＵＥ−ＩＤが自ＵＥ−ＩＤと一致するか否かを判断する。ページングメッセージは、ロジカルチャネルであるＰＣＣＨにマッピングされ、トランスポートチャネルであるＰＣＨにマッピングされ、物理チャネルであるＰＤＳＣＨにマッピングされるメッセージである。ステップＳＴ１９０６において、ページングメッセージ中のＵＥ−ＩＤが自ＵＥ−ＩＤと一致すると判断された場合は、ステップＳＴ１９０７に移行し、ページングメッセージ中のＵＥ−ＩＤが自ＵＥ−ＩＤと一致しないと判断された場合は、図２０のステップＳＴ１９１１に移行する。
ステップＳＴ１９０７において、ＵＥは、ＲＲＣ接続要求（RRC Connection Request）メッセージをｅＮＢに送信する。
ステップＳＴ１９０８において、ｅＮＢは、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージをＵＥに送信する。
ステップＳＴ１９０９において、ＵＥは、ＲＲＣ接続セットアップ完了（RRC Connection Setup Complete）メッセージをｅＮＢに送信する。
ステップＳＴ１９１０において、ＵＥ、ｅＮＢおよびＭＭＥは、ステップＳＴ１９０７〜ステップＳＴ１９０９で確立したＲＲＣ接続を用いて、サービス要求（Service Request）処理を実行する。
ステップＳＴ１９１１において、ＵＥは、ページングメッセージ中に、システム情報の変更を示す情報であるシステム情報変更インジケータ（System Information Modification Indicator）が有るか否かを判断する。ステップＳＴ１９１１において、ページングメッセージ中にシステム情報変更インジケータが有ると判断された場合は、ステップＳＴ１９１２に移行し、ページングメッセージ中にシステム情報変更インジケータが無いと判断された場合は、ステップＳＴ１９１３に移行する。
ステップＳＴ１９１２において、ＵＥは、システム情報を受信して、ステップＳＴ１９１３に移行する。
ステップＳＴ１９１３において、ＵＥは、ページングメッセージ中に、ＥＴＷＳインジケータ（Earthquake and Tsunami Warning System Indicator）が有るか否かを判断する。ステップＳＴ１９１３において、ページングメッセージ中にＥＴＷＳインジケータが有ると判断された場合は、ステップＳＴ１９１４に移行し、ページングメッセージ中にＥＴＷＳインジケータが無いと判断された場合は、ステップＳＴ１９１５に移行する。
ステップＳＴ１９１４において、ＵＥは、ＥＴＷＳ情報を受信する。ＥＴＷＳ情報は、特有のシステム情報にマッピングされている。ＥＴＷＳ情報を受信すると、ステップＳＴ１９１５に移行する。
ステップＳＴ１９１５において、ＵＥは、ページングメッセージ中に、ＣＭＡＳインジケータ（Commercial Mobile Alert Service Indicator）が有るか否かを判断する。ステップＳＴ１９１５において、ページングメッセージ中にＣＭＡＳインジケータが有ると判断された場合は、ステップＳＴ１９１６に移行し、ページングメッセージ中にＣＭＡＳインジケータが無いと判断された場合は、処理が終了する。
ステップＳＴ１９１６において、ＵＥは、ＣＭＡＳ情報を受信する。ＣＭＡＳ情報は、特有のシステム情報にマッピングされている。ＣＭＡＳ情報を受信すると、処理が終了する。
ＵＥモニタリング用メッセージをページング処理中に送信する方法の具体例として、以下の（１）〜（３）の３つを開示する。
（１）ＰＤＣＣＨにＵＥモニタリング用メッセージの有無を通知する識別子を新たに設ける。前記識別子は、例えばマルチメディアブロードキャスト／マルチメディアサービス無線ネットワーク一時的識別子（Multimedia Broadcast/Multicast Service Radio Network Temporary Identity：Ｍ−ＲＮＴＩ）とする。ＵＥは、ＵＥモニタリング用周期でＰＤＣＣＨを受信し、ＰＤＣＣＨにＭ−ＲＮＴＩが有るか否かを判断する。換言すれば、ＵＥは、Ｍ−ＲＮＴＩがアドレスされているか否かを判断する。ＰＤＣＣＨにＭ-ＲＮＴＩが有ると判断された場合は、ＵＥは、ＵＥモニタリング用メッセージを受信したと判断する。ＰＤＣＣＨにＭ−ＲＮＴＩが無いと判断された場合は、ＵＥは、ＵＥモニタリング用メッセージを受信していないと判断する。本具体例（１）は、後述する具体例（２），（３）と異なり、ページングメッセージ（Paging message）の受信が不要となるので、制御遅延の防止を図ることができるという効果を得ることができる。
（２）ページングメッセージ（Paging message）中にＵＥモニタリング用メッセージの送信を示すインジケータをマッピングする。ＵＥは、ページングメッセージ中に、ＵＥモニタリング用メッセージの送信を示すインジケータが有るか否かを判断する。ページングメッセージ中にＵＥモニタリング用メッセージの送信を示すインジケータが有ると判断された場合は、ＵＥは、ＵＥモニタリング用メッセージを受信したと判断する。ページングメッセージ中にＵＥモニタリング用メッセージの送信を示すインジケータが無いと判断された場合は、ＵＥは、ＵＥモニタリング用メッセージを受信していないと判断する。本具体例（２）は、前記具体例（１）と異なり、Ｐ-ＲＮＴＩを併用することができ、ＵＥがＰＤＣＣＨをデコードする回数が減るので、ＵＥの負荷を削減することができるという効果を得ることができる。
（３）ページングメッセージ中に、ＵＥモニタリング用メッセージをマッピングする。追加が必要なパラメータの具体例としては、「生きている」の問合せである旨、ＵＥが存在することの問合せである旨、ＵＥが正常に動作していることの問合せである旨などがある。具体例（３）は、前記具体例（１）と比較して、Ｐ-ＲＮＴＩを併用することができ、ＵＥがＰＤＣＣＨをデコードする回数が減るので、ＵＥの負荷を削減することができるという効果を得ることができる。
ＵＥモニタリング用メッセージに対する応答メッセージをＲＡＣＨ処理中に送信する方法の具体例としては、サービス要求処理中に送信する方法がある。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。
サービス要求処理中に送信する方法の具体例としては、サービス要求処理中におけるＲＡＣＨ処理中に送信する方法がある。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。
サービス要求処理中におけるＲＡＣＨ処理中に送信する方法の具体例として、以下の（１），（２）を開示する。
（１）ランダムアクセスプリアンブル（Random Access Preamble）を用いる。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。
（２）スケジュールされた送信（Scheduled Transmission）メッセージを用いる。さらに具体的には、ＲＲＣ接続要求（RRC Connection Request）メッセージを用いる（非特許文献２参照）。追加が必要なパラメータの具体例としては、ＵＥモニタリング用メッセージに対する応答メッセージである旨がある。ＵＥモニタリング用メッセージに対する応答メッセージである旨は、前記メッセージに設定されている「設定理由（Establishment Cause）」のパラメータに含めて通知されてもよい。
次に、図２１および図２２を用いて、実施の形態１の変形例５における通信システムのシーケンスの具体例について説明する。図２１および図２２は、実施の形態１の変形例５における通信システムのシーケンスの一例を示す図である。図２１と図２２とは、境界線ＢＬ２の位置で、つながっている。図２１および図２２では、ＰＤＣＣＨにＵＥモニタリング用メッセージの有無を通知する識別子を新たに設けて、ＵＥモニタリング用メッセージを通知する場合のシーケンスを示している。図２１および図２２に示すシーケンスは、図１９および図２０に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ１９０４において、ＵＥは、ページングメッセージを受信するタイミングでＰＤＣＣＨを受信し、ＰＤＣＣＨにＰ-ＲＮＴＩが有るか否かを判断する。換言すれば、ＵＥは、Ｐ−ＲＮＴＩがアドレスされているか否かを判断する。ステップＳＴ１９０４において、ＰＤＣＣＨにＰ-ＲＮＴＩが有ると判断された場合は、ステップＳＴ１９０５に移行し、ＰＤＣＣＨにＰ-ＲＮＴＩが無いと判断された場合は、ステップＳＴ２００１に移行する。
ステップＳＴ１９０５において、ＵＥは、ＲＲＣ＿ＩＤＬＥであるか否かを判断する。ステップＳＴ１９０５において、ＲＲＣ＿ＩＤＬＥであると判断された場合は、ステップＳＴ１９０６に移行し、ＲＲＣ＿ＩＤＬＥでないと判断された場合は、ステップＳＴ２００１に移行する。
ステップＳＴ１９０６において、ＵＥは、ページングメッセージ中のＵＥ−ＩＤが自ＵＥ−ＩＤと一致するか否かを判断する。ステップＳＴ１９０６において、ページングメッセージ中のＵＥ−ＩＤが自ＵＥ−ＩＤと一致すると判断された場合は、ステップＳＴ２００３に移行し、ページングメッセージ中のＵＥ−ＩＤが自ＵＥ−ＩＤと一致しないと判断された場合は、ステップＳＴ２００１に移行する。
ステップＳＴ２００１において、ＵＥは、ＰＤＣＣＨにＭ-ＲＮＴＩが有るか否かを判断する。換言すれば、ＵＥは、Ｍ−ＲＮＴＩがアドレスされているか否かを判断する。ステップＳＴ２００１において、ＰＤＣＣＨにＭ-ＲＮＴＩが有ると判断された場合は、ステップＳＴ２００２に移行し、ＰＤＣＣＨにＭ-ＲＮＴＩが無いと判断された場合は、ステップＳＴ１９０３に戻る。
ステップＳＴ２００２において、ＵＥは、ＵＥモニタリング用メッセージに対する応答メッセージを、ＭＭＥに送信する。ＵＥモニタリング用メッセージに対する応答メッセージは、ランダムアクセスプリアンブル（Random Access Preamble）、スケジュールされた送信（Scheduled Transmission）、またはＲＲＣ接続要求（RRC Connection Request）を用いて送信してもよい。その後、ＵＥは、図２２のステップＳＴ１９１１に移行する。
ステップＳＴ２００３において、ＵＥは、ＰＤＣＣＨにＭ-ＲＮＴＩが有るか否かを判断する。換言すれば、ＵＥは、Ｍ−ＲＮＴＩがアドレスされているか否かを判断する。ステップＳＴ２００３において、ＰＤＣＣＨにＭ-ＲＮＴＩが有ると判断された場合は、ステップＳＴ２００４に移行し、ＰＤＣＣＨにＭ-ＲＮＴＩが無いと判断された場合は、ステップＳＴ１９０７に移行する。
ステップＳＴ２００４において、ＵＥは、ＲＲＣ接続要求（RRC Connection Request）に、ＵＥモニタリング用メッセージに対する応答メッセージを付加する。
ページングに対する通常の応答メッセージに、ＵＥモニタリング用メッセージに対する応答メッセージを付加してもよい。ランダムアクセスプリアンブル（Random Access Preamble）、またはスケジュールされた送信（Scheduled Transmission）に、ＵＥモニタリング用メッセージに対する応答メッセージを付加してもよい。その後、ＵＥは、ステップＳＴ１９０７に移行する。
次に、図２３および図２４を用いて、実施の形態１の変形例５における通信システムのシーケンスの具体例について説明する。図２３および図２４は、実施の形態１の変形例５における通信システムのシーケンスの他の例を示す図である。図２３と図２４とは、境界線ＢＬ３の位置で、つながっている。図２３および図２４では、ページングメッセージ中に、ＵＥモニタリング用メッセージの送信を示すインジケータ（以下「ＵＥモニタリング用インジケータ」と称することもある）をマッピングし、ＵＥモニタリング用メッセージを通知する場合のシーケンスを示している。図２３および図２４に示すシーケンスは、図１９および図２０に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
図２４のステップＳＴ２１０１において、ＵＥは、ページングメッセージ中に、ＵＥモニタリング用インジケータが有るか否かを判断する。ステップＳＴ２１０１において、ＵＥモニタリング用インジケータが有ると判断された場合は、ステップＳＴ２１０２に移行し、ＵＥモニタリング用インジケータが無いと判断された場合は、処理を終了する。
ステップＳＴ２１０２において、ＵＥは、ＵＥモニタリング用メッセージに対する応答メッセージを、ＭＭＥに送信する。ＵＥモニタリング用メッセージに対する応答メッセージは、ランダムアクセスプリアンブル（Random Access Preamble）、スケジュールされた送信（Scheduled Transmission）、またはＲＲＣ接続要求（RRC Connection Request）を用いて送信してもよい。
次に、図２５および図２６を用いて、実施の形態１の変形例５における通信システムのシーケンスの具体例について説明する。図２５および図２６は、実施の形態１の変形例５における通信システムのシーケンスの他の例を示す図である。図２５と図２６とは、境界線ＢＬ４の位置で、つながっている。図２５および図２６では、ページングメッセージ中に、ＵＥモニタリング用メッセージをマッピングし、ＵＥモニタリング用メッセージを通知する場合のシーケンスを示している。図２５および図２６に示すシーケンスは、図１９および図２０に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
図２６のステップＳＴ２２０１において、ＵＥは、ページングメッセージ中にＵＥモニタリング用メッセージがマッピングされているか否かを判断する。換言すれば、ＵＥは、ページングメッセージ中にＵＥモニタリング用メッセージが有るか否かを判断する。ステップＳＴ２２０１において、ページングメッセージ中にＵＥモニタリング用メッセージが有ると判断された場合は、ステップＳＴ２１０２に移行し、ページングメッセージ中にＵＥモニタリング用メッセージが無いと判断された場合は、処理が終了する。
実施の形態１の変形例５は、前述の実施の形態１の変形例２または実施の形態１の変形例３と組合せて用いることが可能である。
以上の実施の形態１の変形例５によって、実施の形態１の効果に加えて、以下の効果を得ることができる。ＲＲＣ接続の確立および解放の手続きが不要となり、ＵＥの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
実施の形態１ 変形例６．
実施の形態１の変形例６では、前述の実施の形態１の更なる改善点について示す。本変形例では、前述の実施の形態１の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態１と同様とする。
本変形例では、ｅＮＢからＵＥへの送達確認情報に、該ｅＮＢ、または該ｅＮＢが属するネットワーク側のシステムに関する情報を含める。
システムに関する情報の具体例として、以下の（１）〜（４）の４つを開示する。
（１）ステータス情報、または規制情報。ステータス情報および規制情報の具体例として、以下の（１−１）〜（１−３）の３つを開示する。（１−１）ｅＮＢ、または該ｅＮＢが属するネットワークの正常／異常の旨。（１−２）ｅＮＢ、または該ｅＮＢが属するネットワークの混雑／非混雑の旨。（１−３）ｅＮＢ、または該ｅＮＢが属するネットワークの使用可／不可の旨。
（２）システム情報そのもの。システム情報の一部であってもよい。
（３）前記（１）〜（２）などの変更があった日時。
（４）前記（１）〜（３）の組合せ。
実施の形態１の変形例６は、前述の実施の形態１の変形例１、実施の形態１の変形例２、実施の形態１の変形例３、実施の形態１の変形例４、または実施の形態１の変形例５と組合せて用いることが可能である。
実施の形態１の変形例６と実施の形態１の変形例１とを組合せる場合は、ＵＥモニタリング用メッセージに対する応答メッセージに、該ｅＮＢ、または該ｅＮＢが属するネットワーク側のシステムに関する情報を含めればよい。
実施の形態１の変形例６と、実施の形態１の変形例２または実施の形態１の変形例３とを組合せる場合は、ｅＮＢからＵＥへのＵＥモニタリング用メッセージに、該ｅＮＢ、または該ｅＮＢが属するネットワーク側のシステムに関する情報を含めればよい。
以上の実施の形態１の変形例６によって、実施の形態１の効果に加えて、以下の効果を得ることができる。ＵＥは、ＵＥモニタリング周期でｅＮＢ、または該ｅＮＢが属するネットワーク側のシステムに関する情報を取得することができる。
実施の形態２．
実施の形態２で解決する課題について、以下に説明する。現在の３ＧＰＰのＥ−ＵＴＲＡＮ規格においては、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態において、ＵＥ側が起点となるＲＲＣ接続リリース（RRC Connection Release）をＥ−ＵＴＲＡＮに通知する手段が規定されていない。したがって、ＵＥのアプリケーションの指示によって、ＲＲＣ＿ＩＤＬＥ状態に移行した場合、ＵＥとＥ−ＵＴＲＡＮとのＲＲＣ状態が一致せず、Ｅ−ＵＴＲＡＮが不必要にシステムリソースを確保し続けるという問題がある。
図２７〜図２９は、実施の形態２で解決する課題を説明するためのシーケンスを示す図である。図２７と図２８とは、境界線ＢＬ５の位置で、つながっている。図２８と図２９とは、境界線ＢＬ６の位置で、つながっている。
ＵＥは、ＴＣＰ／ＩＰ上実行されるアプリケーション（以下「ＡＰＰ」という場合がある）を有する。
図２７〜図２９では、ステップＳＴ５１０１において、ＵＥがＲＲＣ＿ＩＤＬＥ状態およびＥＣＭ（EPS Connection Management）＿ＩＤＬＥ状態にあり、ステップＳＴ５１０２において、ｅＮＢがＵＥに対してＲＲＣ＿ＩＤＬＥ状態にあり、ステップＳＴ５１０３において、ＭＭＥがＵＥに対してＥＣＭ＿ＩＤＬＥ状態にある場合について示す。ｅＮＢのＲＲＣ状態とは、ｅＮＢが想定する対象となるＵＥのＲＲＣ状態（以下、単に「ｅＮＢのＲＲＣ状態」という場合がある）を表す。
ＵＥのアプリケーションがアクセス開始するような場合、ステップＳＴ５１０４において、ＵＥのアプリケーションは、ＵＥのＮＡＳに対してアクセス要求（Access Request）を行う。このアクセス要求に従い、ＵＥは、ステップＳＴ５１０５において、サービス要求処理Ａ（Service Request Procedure A）を起動する。
ステップＳＴ５１０５のサービス要求処理Ａの具体例を以下に示す。ステップＳＴ５１０６において、ＵＥのＮＡＳは、ＡＳ（Access Stratum）（ＲＲＣ）に対してサービス要求（Service Request）を行う。
ステップＳＴ５１０８〜ステップＳＴ５１１０の処理を含むステップＳＴ５１０７において、ＵＥは、ｅＮＢとの間で、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）を実行する。
ステップＳＴ５１０８において、ＵＥのＡＳ（ＲＲＣ）は、ＲＲＣ接続要求（RRC Connection Request）をｅＮＢに通知する。ステップＳＴ５１０９において、ｅＮＢは、ＲＲＣ接続セットアップ（RRC Connection Setup）をＵＥのＡＳ（ＲＲＣ）に通知する。ステップＳＴ５１１０において、ＵＥのＡＳ（ＲＲＣ）は、ＲＲＣ接続セットアップ完了（RRC Connection Setup Complete）をＵＥのＡＳ（ＲＲＣ）に通知する。
このようにして、ステップＳＴ５１０７のＲＲＣ接続セットアップ処理が完了すると、ＵＥは、ステップＳＴ５１１１において、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態およびＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。また、ｅＮＢは、ステップＳＴ５１１２において、ＵＥに対してＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。
このように、ＵＥとｅＮＢとの間で、ＲＲＣ接続を設立してＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行した後、ＵＥは、ステップＳＴ５１１３において、サービス要求（Service Request）メッセージをｅＮＢに対して通知する。
サービス要求メッセージを受信したｅＮＢは、ステップＳＴ５１１４において、サービスト要求メッセージをＭＭＥに通知する。
ステップＳＴ５１１５において、ＵＥ、ＭＭＥおよびＨＳＳの間で、認証（authentication）処理およびセキュリティ（security）制御処理が実行される。
ＭＭＥは、無線ベアラおよびＳ１ベアラをアクティブにするために、図２８のステップＳＴ５１１６において、ｅＮＢに対して初期コンテキストセットアップ要求（Initial Context Setup Request）メッセージを通知する。
初期コンテキストセットアップ要求メッセージを受信したｅＮＢは、ステップＳＴ５１１８およびステップＳＴ５１１９の処理を含むステップＳＴ５１１７において、ＵＥとの間で、無線ベアラ設立処理（Radio Bearer Establishment Procedure）を実行する。
ステップＳＴ５１１８において、ｅＮＢは、ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージをＵＥに通知する。ステップＳＴ５１１９において、ＵＥは、ＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）メッセージをｅＮＢに通知する。
このようにしてＵＥ間の無線ベアラ設立およびＳ１ベアラの設定を行ったｅＮＢは、ステップＳＴ５１２０において、ＭＭＥに対して初期コンテキストセットアップ完了（Initial Context Setup Complete）メッセージを通知する。
初期コンテキストセットアップ完了メッセージを受信したＭＭＥは、ステップＳＴ５１２１において、Ｓ−ＧＷに対してベアラ修正要求（Modify Bearer Request）メッセージを通知する。
ベアラ修正要求メッセージを受信したＳ−ＧＷは、ステップＳＴ５１２３〜ステップＳＴ５１２５の処理を含むステップＳＴ５１２２の処理を行う。具体的には、ステップＳＴ５１２３において、Ｓ−ＧＷは、Ｐ−ＧＷに対してベアラ修正要求メッセージを通知する。ベアラ要求メッセージを受信したＰ−ＧＷは、ステップＳＴ５１２４において、ベアラ要求メッセージに従って、ＰＣＲＦ（Policy and Charging Rule Function）との間で、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）セッションコントロールを行う。具体的には、Ｐ−ＧＷは、ＩＰ−ＣＡＮのセッション変更を行う。ＩＰ−ＣＡＮのセッション変更は、「PCEF Initiated IP-CAN Session Modification」という場合がある。
ステップＳＴ５１２５でベアラ修正応答メッセージを受信したＳ−ＧＷは、ステップＳＴ５１２６において、ＭＭＥに対してベアラ修正応答（Modify Bearer Response）メッセージを通知する。
ベアラ修正応答メッセージを受信したＭＭＥは、ステップＳＴ５１２７において、該ＵＥに対してＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。あるいは、該ＵＥに対するＳ１コネクションの設立が完了したことで、ＭＭＥは該ＵＥに対してＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行してもよい。該ＵＥに対するＳ１コネクションの設立が完了したことは、ＭＭＥは、ステップＳＴ５１２０における初期コンテキストセットアップ完了メッセージの受信で認識する。
これらの処理によって、ステップＳＴ５１２８において、ＵＥとＰ−ＧＷとの間でＥＰＳベアラが設立される。
ステップＳＴ５１０５のサービス要求処理によってＥＰＳベアラが設立されることによって、ステップＳＴ５１２９において、ＵＥとアプリケーションサーバ（APP server）との間で、エンドツーエンド（End to End）のサービスが実行され、ステップＳＴ５１３０において、アプリケーションデータがＵＥからアプリケーションサーバに通信される。
ＬＴＥにおいては、ＵＥおよびｅＮＢが、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態において、ＵＥ側が起点となるＲＲＣ接続リリース（RRC Connection Release）をＥ−ＵＴＲＡＮに通知する手段が規定されていない。したがって、ネットワーク側からＲＲＣ接続リリース（RRC Connection Release）が起動されない限り、ＵＥとｅＮＢとの間でＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態が維持され、ＵＥとＭＭＥとの間でＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態が維持される。
ネットワーク側は、ＵＥのアプリケーションにおけるデータの発生の有無を認識できない。したがって、ＵＥ側のアプリケーションで、たとえデータの発生が無いとしても、ネットワーク側はその状況を認識することができないので、即座にＲＲＣ接続リリース（RRC Connection Release）処理を起動することができない。ネットワーク側は、ＵＥとｅＮＢとの間でＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を維持し続け、ＵＥとＭＭＥとの間でＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を維持し続けることになる。
この問題を解消するために、ネットワーク側は、所定の期間にデータの送受信が行われたか否かを判断し、行われていない場合にはＳ１リリース処理を起動するとよい。これによって、ネットワーク側は、ＲＲＣ接続およびＳ１ベアラをリリースし、ｅＮＢ間でＲＲＣ＿ＩＤＬＥ状態に遷移させ、ＵＥとＭＭＥとの間でＥＣＭ＿ＩＤＬＥ状態に遷移させることができる。
しかし、このような処理を行ったとしても、例えば、ＵＥのアプリケーションの指示によってＲＲＣ＿ＩＤＬＥに移行した場合、ＵＥはＲＲＣ＿ＩＤＬＥ状態に移行するが、Ｅ−ＵＴＲＡＮはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を維持しているので、ＵＥとＥ−ＵＴＲＡＮとのＲＲＣ状態が一致せず、Ｅ−ＵＴＲＡＮが不必要にシステムリソースを確保し続けてしまうという問題が残る。
ＲＲＣ状態が一致しなくなる例を、図２７〜図２９を用いて説明する。例えば、ＵＥのアプリケーションでデータの発生が無くなった場合、図２９のステップＳＴ５１３１において、ＵＥのＮＡＳは、接続リリース（Connection Release）の指示をＡＳに通知する。
ステップＳＴ５１０１において、ＵＥは、ＲＲＣ接続リリース（RRC Connection Release）処理を行い、ＲＲＣ＿ＩＤＬＥに移行する。ＲＲＣ＿ＩＤＬＥの移行とともに、ＥＣＭ＿ＩＤＬＥへ移行してもよい。しかし、この状態をネットワーク側は認識できないので、ｅＮＢは、ステップＳＴ５１１２において、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を維持する。
ｅＮＢは、データの送受信が行われたか否かをモニタし、所定の期間にデータの送受信が行われなかった場合、ステップＳＴ５１３４のＳ１リリース処理Ａ（S1 Release Procedure A）を起動する。所定の期間として、データモニタタイマを設けて、ステップＳＴ５１３３において、ｅＮＢは、データモニタタイマが満了したか否かを判断する。
Ｓ１リリース処理Ａでは、ステップＳＴ５１３５〜ステップＳＴ５１４０の処理を行う。ステップＳＴ５１３５において、ｅＮＢは、ＭＭＥにＵＥコンテキストリリース要求（UE Context Release Request）を通知する。ステップＳＴ５１３６において、ＭＭＥは、Ｓ−ＧＷにアクセスベアラリリース要求（Release Access Bearers Request）を通知する。ステップＳＴ５１３７において、Ｓ−ＧＷは、ＭＭＥにアクセスベアラリリース応答（Release Access Bearers Response）を通知する。ステップＳＴ５１３８において、ＭＭＥは、ｅＮＢにＵＥコンテキストリリースコマンド（UE Context Release Command）を通知する。ステップＳＴ５１３９において、ｅＮＢは、ＵＥにＲＲＣ接続リリース（RRC Connection Release）を通知する。ステップＳＴ５１４０において、ｅＮＢは、ＭＭＥにＵＥコンテキストリリース完了（UE Context Release Complete）を通知する。これによって、ＵＥに対する無線ベアラ、Ｓ１ベアラ、ＥＰＳベアラがリリースされる。ｅＮＢは、ステップＳＴ５１４１においてＲＲＣ＿ＩＤＬＥ状態に移行し、ＭＭＥは、ステップＳＴ５１４２においてＥＣＭ＿ＩＤＬＥ状態に移行する。
このように、アプリケーションデータの発生が無くなると、ＵＥは、ステップＳＴ５１０１において、ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行するが、ｅＮＢおよびＭＭＥは、データモニタタイマが満了するまで、Ｓ１リリース処理を起動せず、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態、およびＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態のままである。したがって、ステップＳＴ５１３２に示すように、ＵＥとｅＮＢおよびＭＭＥとで、状態不一致の期間が生じてしまう。
実施の形態２での解決策を以下に示す。ＵＥとｅＮＢとの間におけるＵＥのＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ状態通知用のメッセージ（以下、「Uu keep alive indication」、「Uu keep alive ind」または「uu-keep-alive」という場合がある）を設ける。
ＵＥは、周期的に「Uu keep alive ind」をｅＮＢに送信する。ｅＮＢは、「Uu keep alive ind」を用いて、ＵＥのＲＲＣ状態を判断（以下「ＲＲＣ状態判断」という場合がある）してもよい。ＲＲＣ状態判断の具体例は、後述する。
これによって、ＵＥのアプリケーションの指示により、ＵＥがＲＲＣ＿ＩＤＬＥに移行した場合に、ＵＥからｅＮＢへの周期的な「Uu keep alive ind」の送信が止まる。したがって、ＵＥのＲＲＣ状態が、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤではない、つまりＲＲＣ＿ＩＤＬＥであると、ｅＮＢが判断することが可能となる。これによって、ＵＥとネットワーク（Ｅ−ＵＴＲＡＮ）側でのＲＲＣ状態が一致せず、Ｅ−ＵＴＲＡＮが不必要にシステムリソースを確保し続けるという問題を解決することができる。
ＵＥが「Uu keep alive ind」をｅＮＢに送信する周期を、「Uu keep alive ind」送信周期と称することもある。またＵＥが、タイマ満了後、あるいはタイマ満了を契機に「Uu keep alive ind」を送信するようにしてもよい。該タイマを「Uu keep alive ind」送信タイマと称することもある。
以下、主に「Uu keep alive ind」送信周期を用いて説明するが、「Uu keep alive ind」送信タイマを用いることもできる。
ｅＮＢは、「Uu keep alive ind」を受信した場合、送達確認情報を送信してもよい。あるいは、ｅＮＢは、周期内に「Uu keep alive ind」を受信した場合、送達確認情報を送信してもよい。送達確認情報の具体例としては、ＲＬＣレイヤにおける応答メッセージ（ＡＣＫ）がある。送達確認情報は、ステータスＰＤＵ（Status PDU）であってもよい。
ＵＥが「Uu keep alive ind」をｅＮＢに通知する目的の具体例として、以下の（１）〜（３）の３つを開示する。
（１）「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」であることを伝えるため。
（２）「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求するため。
（３）前記（１），（２）の組合せ。
ＲＲＣ状態判断の具体例として、以下の（１）〜（４）の４つを開示する。
（１）ｅＮＢは、「Uu keep alive ind」送信周期に「Uu keep alive ind」を受信しない場合は、ＵＥがＲＲＣ＿ＩＤＬＥである、あるいはＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥへ移行した、あるいはＲＲＣ＿ＣＯＮＮＥＣＴＥＤの継続を要求しないと判断する（以下、まとめて「ＲＲＣ＿ＩＤＬＥと判断する」という場合がある）。また、ｅＮＢは、「Uu keep alive ind」送信周期内に「Uu keep alive ind」を受信する場合は、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤである、あるいはＲＲＣ＿ＣＯＮＮＥＣＴＥＤを継続する、あるいはＲＲＣ＿ＣＯＮＮＥＣＴＥＤの継続を要求すると判断する（以下、まとめて「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤと判断する」という場合がある）。「Uu keep alive ind」送信周期の決定方法および通知方法は、後述する。
（２）ｅＮＢは、「Uu keep alive ind」送信周期内に「Uu keep alive ind」を受信しないことが、予め決められた回数連続して発生した場合は、ＲＲＣ＿ＩＤＬＥと判断する。予め決められた回数は、静的に決定されても、準静的に決定されてもよい。予め決められた回数の決定方法および通知方法は、後述する。
（３）ｅＮＢは、予め決められた期間内に「Uu keep alive ind」を受信しない場合は、ＲＲＣ＿ＩＤＬＥと判断する。予め決められた期間は、ＵＥが「Uu keep alive ind」送信周期より長くすればよい。予め決められた期間は、静的に決定されても、準静的に決定されてもよい。予め決められた期間の決定方法および通知方法は、後述する。この予め決められた期間を、前記データモニタタイマとしてもよい。したがって、ＵＥが「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求している期間、ｅＮＢによるデータモニタタイマ満了による、ｅＮＢによるＲＲＣ＿ＩＤＬＥへの移行起動を避けることができる。これによって、ＵＥとｅＮＢとの間のＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を継続することが可能となる。データモニタタイマは、Ｕｕ点においてデータを受信した場合にタイマをスタートさせる。新たにＵｕ点においてデータを受信した場合は、データモニタタイマをストップし、リセットし、初めからスタートさせる。Ｕｕ点におけるデータの具体例として、以下の（３−１）〜（３−３）の３つを開示する。（３−１）ＲＲＣレベルでのデータ。（３−２）ＮＡＳレベルでのデータ。（３−３）前記（３−１），（３−２）の組合せ。
（４）前記（１）〜（３）の組合せ。
「Uu keep alive ind」送信周期の決定主体の具体例としては、ＵＥ、ｅＮＢ、ＡＰＰサーバ（アプリケーション）などがある。
ＵＥの「Uu keep alive ind」送信周期の決定方法の具体例として、以下の（１）〜（６）の６つを開示する。
（１）アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報、セッションタイマなどから、ＵＥのＮＡＳが「Uu keep alive ind」送信周期を決定してもよい。また通信のエンド−エンド（Ｅｎｄ−Ｅｎｄ）となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット（以下「ｋｅｅｐ-ａｌｉｖｅパケット」という）を定期的に送信する周期、あるいは前記周期の整数の逆数倍（１／整数倍）としてもよい。
（２）ｅＮＢから通知されるＤＲＸ周期に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をＤＲＸ周期の整数倍、あるいはＤＲＸ周期の整数の逆数倍（１／整数倍）としてもよい。これによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＥがＰＤＣＣＨをモニタするタイミングであるＤＲＸ周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
（３）ｅＮＢから通知されるデータモニタタイマに依存して決定するとしてもよい。「Uu keep alive ind」送信周期を、データモニタタイマよりも短い値としてもよい。これによって、ＵＥが「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求している期間、ｅＮＢによるデータモニタタイマ満了による、ｅＮＢによるＲＲＣ＿ＩＤＬＥへの移行起動を避けることができる。
（４）タイミングアドバンス（Timing Advance）の有効期間に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をタイミングアドバンスの有効期間の整数倍、あるいはタイミングアドバンスの有効期間の整数の逆数倍（１／整数倍）としてもよい。これによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＥがＲＡＣＨ処理を行うタイミングであるタイミングアドバンスの有効期間と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
（５）ＵＥの負荷状況、電池残量により決定する。負荷状況が高い場合、または電池残量が少ない場合は、「Uu keep alive ind」送信周期を長くする。負荷状況が低い場合、または電池残量が多い場合は、「Uu keep alive ind」送信周期を短くする、あるいは通常通りとする。これによって、ＵＥの負荷低減、電池残量が少ない場合の対策を行うことが可能となる。
（６）前記（１）〜（５）の組合せ。
ＵＥが決定した「Uu keep alive ind」送信周期をｅＮＢに通知する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）「Uu keep alive ind」と共に通知する。「Uu keep alive ind」毎に通知してもよいし、最初の１回通知してもよい。毎回通知する場合と比較して、最初の１回通知する場合は、情報量を削減することができるという効果を得ることができる。
（２）「Uu keep alive ind」の送信に先立って通知する。１回通知するとしてもよい。具体例（１）と比較して、ｅＮＢにおいて「Uu keep alive ind」用受信準備が可能となるという効果を得ることができる。具体例として、以下の（２−１），（２−２）の２つを開示する。
（２−１）新たにＲＲＣシグナリング、あるいはＮＡＳシグナリングを新設する。
（２−２）既存のＲＲＣシグナリング、あるいはＮＡＳシグナリングを用いる。本具体例（２−２）は、具体例（２−１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２−２）によって、通信システムが複雑化することを回避することができる。
新たにＲＲＣシグナリング、あるいはＮＡＳシグナリングにマッピングするパラメータの具体例として、以下の（１）〜（４）の４つを開示する。
（１）「Uu keep alive ind」送信周期。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）接続先であるアプリケーションサーバの情報。
（４）前記（１）〜（３）の組合せ。
既存のＲＲＣシグナルを用いる場合の具体例としては、ＲＲＣ接続再設定「RRC Connection Request」メッセージを用いる場合が挙げられる。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例としては、（１）「Uu keep alive ind」送信周期、（２）接続先であるアプリケーションサーバの情報、などがある。
既存のＮＡＳシグナルを用いる場合の具体例としては、サービスリクエスト「Service Request」メッセージを用いる場合が挙げられる。
既存のＮＡＳシグナリングに追加が必要なパラメータの具体例としては、（１）「Uu keep alive ind」送信周期、（２）接続先であるアプリケーションサーバの情報、などがある。
ｅＮＢの「Uu keep alive ind」送信周期の決定方法の具体例として、以下の（１）〜（５）の５つを開示する。
（１）ＤＲＸ周期に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をＤＲＸ周期の整数倍、あるいはＤＲＸ周期の整数の逆数倍（１／整数倍）としてもよい。これによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＥがＰＤＣＣＨをモニタするタイミングであるＤＲＸ周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
（２）データモニタタイマ、あるいは、アプリケーションのセッションタイマに依存して決定するとしてもよい。「Uu keep alive ind」送信周期を、データモニタタイマよりも短い値としてもよい。これによって、ＵＥが「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求している期間、ｅＮＢによるデータモニタタイマ満了による、ｅＮＢによるＲＲＣ＿ＩＤＬＥへの移行起動を避けることができる。
（３）タイミングアドバンス（Timing Advance）の有効期間に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をタイミングアドバンスの有効期間の整数倍、あるいはタイミングアドバンスの有効期間の整数の逆数倍（１／整数倍）としてもよい。これによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＥがＲＡＣＨ処理を行うタイミングであるタイミングアドバンスの有効期間と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
（４）ｅＮＢの負荷状況、ネットワークの負荷状況により決定する。負荷状況が高い場合は、「Uu keep alive ind」送信周期を長くする、あるいは「Uu keep alive ind」送信を禁止、換言すれば「Uu keep alive ind」送信を無限大にする。負荷状況が低い場合は、「Uu keep alive ind」送信周期を短くする、あるいは通常通りとする。これによって、ｅＮＢ、ネットワークの負荷の低減を行うことが可能となる。ネットワークの負荷状況は、ＭＭＥからｅＮＢに通知する、ＭＭＥの過負荷を示すメッセージが既存する。Ｓ１インタフェース上の「Overload START」メッセージを用いてもよい。「Overload Action」に、「Uu keep alive ind」に関するパラメータを追加してもよい。「Uu keep alive ind」禁止のパラメータを追加してもよい。
（５）前記（１）〜（４）の組合せ。
ｅＮＢが決定した「Uu keep alive ind」送信周期をＵＥに通知する方法の具体例として、以下の（１）〜（６）の６つを開示する。
（１）報知情報によって通知する。
（２）個別情報によって通知する。
（３）ＴＡＵ処理で通知する。具体例としては、「TAU Accept」などによって通知する方法がある。
（４）アタッチ処理で通知する。具体例としては、「Attach Accept」、「RRC Connection Reconfiguration」などによって通知する方法がある。
（５）ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）で通知する。具体例としては、「RRC Connection Setup」などによって通知する方法がある。
（６）サービス要求処理（Service Request Procedure）で通知する。具体例としては、「RRC Connection Reconfiguration」などによって通知する方法がある。
ＡＰＰサーバの「Uu keep alive ind」送信周期の決定方法の具体例を以下に開示する。
アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報、セッションタイマなどから、「Uu keep alive ind」送信周期を決定してもよい。また通信のエンド−エンド（Ｅｎｄ−Ｅｎｄ）となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット（以下「ｋｅｅｐ-ａｌｉｖｅパケット」という）を定期的に送信する周期、あるいは前記周期の整数の逆数倍（１／整数倍）としてもよい。
ＡＰＰサーバが決定した「Uu keep alive ind」送信周期をｅＮＢに通知するとともに、ｅＮＢ経由でＵＥに通知する。
予め決められた回数の決定主体の具体例としては、ＵＥ、ｅＮＢ、ＡＰＰサーバ（アプリケーション）などがある。
ＵＥの予め決められた回数の決定方法の具体例として、以下の（１）〜（３）の３つを開示する。
（１）アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報、セッションタイマなどから、ＵＥのＮＡＳが予め決められた回数を決定してもよい。また、通信のエンド−エンド（Ｅｎｄ−Ｅｎｄ）となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット（以下「ｋｅｅｐ-ａｌｉｖｅパケット」という）を定期的に送信する周期、または「UE keep alive ind」送信周期としてもよい。
（２）ｅＮＢから通知されるデータモニタタイマに依存して決定するとしてもよい。予め決められた回数は、データモニタタイマ、または「Uu keep alive ind」送信周期としてもよい。これによって、ＵＥが「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求している期間、ｅＮＢによるＲＲＣ＿ＩＤＬＥへの移行起動を避けることができる。
（３）前記（１），（２）の組合せ。
ＵＥが決定した予め決められた回数をｅＮＢに通知する方法の具体例は、ＵＥが決定した「Uu keep alive ind」送信周期をｅＮＢに通知する方法の具体例と同様であるので、説明を省略する。
ｅＮＢの予め決められた回数の決定方法の具体例を以下に開示する。データモニタタイマ、あるいはアプリケーションの、セッションタイマに依存して決定するとしてもよい。予め決められた回数は、データモニタタイマ、または「Uu keep alive ind」送信周期としてもよい。これによって、ＵＥが「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求している期間、ｅＮＢによるＲＲＣ＿ＩＤＬＥへの移行起動を避けることができる。
ｅＮＢが決定した予め決められた回数をＵＥに通知する方法の具体例は、ｅＮＢが決定した「Uu keep alive ind」送信周期をＵＥに通知する方法の具体例と同様であるので、説明を省略する。
ＡＰＰサーバの予め決められた回数の決定方法の具体例を以下に開示する。アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報、セッションタイマなどから、予め決められた回数を決定してもよい。また通信のエンド−エンド（Ｅｎｄ−Ｅｎｄ）となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット（以下「ｋｅｅｐ-ａｌｉｖｅパケット」という）を定期的に送信する周期、または「UE keep alive ind」送信周期としてもよい。
ＡＰＰサーバが決定した予め決められた回数をｅＮＢに通知するとともに、ｅＮＢ経由でＵＥに通知する。
予め決められた期間の決定主体の具体例としては、ＵＥ、ｅＮＢ、ＡＰＰサーバ（アプリケーション）などがある。
ＵＥの予め決められた期間の決定方法の具体例として、以下の（１）〜（６）の６つを開示する。
（１）アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報、セッションタイマなどから、ＵＥのＮＡＳが予め決められた期間を決定してもよい。また、通信のエンド−エンド（Ｅｎｄ−Ｅｎｄ）となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット（以下「ｋｅｅｐ-ａｌｉｖｅパケット」という）を定期的に送信する周期、あるいは前記周期の整数の逆数倍（１／整数倍）としてもよい。また、前記データ量、データ送信周期などを、そのまま予め決められた期間として他ノードへ通知してもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報などから、ＵＥのＮＡＳがＲＲＣ＿ＣＯＮＮＥＣＴＥＤを要求する期間、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤが予想される期間を予め決められた期間としてもよい。
（２）ｅＮＢから通知されるＤＲＸ周期に依存して決定するとしてもよい。予め決められた期間をＤＲＸ周期の整数倍、あるいはＤＲＸ周期の整数の逆数倍（１／整数倍）としてもよい。これによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＥがＰＤＣＣＨをモニタするタイミングであるＤＲＸ周期と、「Uu keep alive ind」を送信するタイミングである予め決められた期間とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
（３）ｅＮＢから通知されるデータモニタタイマに依存して決定するとしてもよい。予め決められた期間を、データモニタタイマよりも短い値としてもよい。これによって、ＵＥが「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求している期間、ｅＮＢによるデータモニタタイマ満了による、ｅＮＢによるＲＲＣ＿ＩＤＬＥへの移行起動を避けることができる。
（４）タイミングアドバンス（Timing Advance）の有効期間に依存して決定するとしてもよい。予め決められた期間をタイミングアドバンスの有効期間の整数倍、あるいはタイミングアドバンスの有効期間の整数の逆数倍（１／整数倍）としてもよい。これによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＥがＲＡＣＨ処理を行うタイミングであるタイミングアドバンスの有効期間と、「Uu keep alive ind」を送信するタイミングである予め決められた期間とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
（５）ＵＥの負荷状況、電池残量により決定する。負荷状況が高い場合、または電池残量が少ない場合は、予め決められた期間を長くする。負荷状況が低い場合、または電池残量が多い場合は、予め決められた期間を短くする、あるいは通常通りとする。これによって、ＵＥの負荷低減、電池残量が少ない場合の対策を行うことが可能となる。
（６）前記（１）〜（５）の組合せ。
ｅＮＢの予め決められた期間の決定方法の具体例は、ｅＮＢの「Uu keep alive ind」送信周期の決定方法と同様であるので、説明を省略する。
ＡＰＰサーバの予め決められた期間の決定方法の具体例を以下に開示する。アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報、セッションタイマなどから、予め決められた期間を決定してもよい。また、通信のエンド−エンド（Ｅｎｄ−Ｅｎｄ）となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット（以下「ｋｅｅｐ-ａｌｉｖｅパケット」という）を定期的に送信する周期、あるいは前記周期の整数の逆数倍（１／整数倍）としてもよい。また、前記データ量、データ送信周期などを、そのまま予め決められた期間として他ノードへ通知してもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報などから、ＵＥのＮＡＳがＲＲＣ＿ＣＯＮＮＥＣＴＥＤを要求する期間、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤが予想される期間を予め決められた期間としてもよい。
決定主体毎の通知方法は、「Uu keep alive ind」送信周期の決定方法および通知方法と同様であるので、説明を省略する。
ｅＮＢは、ＲＲＣ状態判断でＲＲＣ＿ＩＤＬＥと判断した場合、ＩＤＬＥ移行処理を実行してもよい。ＩＤＬＥ移行処理の具体例として、以下の（１）〜（３）の３つを開示する。
（１）該ＵＥのＣＯＮＮＥＣＴＥＤ用にＥ−ＵＴＲＡＮが確保しているシステムリソースを開放する。システムリソースの具体例としては、該ＵＥに対する無線ベアラ、Ｓ１ベアラ、ＥＰＳベアラなどがある。開放方法の具体例としては、ｅＮＢによるＳ１リリース処理（S1 Release Procedure）の起動、ｅＮＢによるＭＭＥへのＵＥコンテキストリリース処理、Ｓ−ＧＷへのアクセスベアラリリース処理、ＵＥへのＲＲＣ接続リリース処理などがある。
（２）ネットワーク側のＥＣＭ状態をＥＣＭ＿ＩＤＬＥへ移行させる。ＭＭＥのＥＣＭ状態をＥＣＭ＿ＩＤＬＥへ移行させる。移行方法の具体例としては、前記（１）の開放方法の具体例と同様であるので、説明を省略する。
（３）ネットワーク側のＲＲＣ状態をＲＲＣ＿ＩＤＬＥへ移行させる。ｅＮＢのＲＲＣ状態をＲＲＣ＿ＩＤＬＥに移行させる。移行方法の具体例としては、前記（１）の開放方法の具体例と同様であるので、説明を省略する。
「Uu keep alive ind」の具体例として、以下の（１）〜（４）の４つを開示する。
（１）Ｕｕ点のみのメッセージとする。Ｕｕ点とは、ＵＥとｅＮＢ、ＵＥとＨｅＮＢ、またはＵＥとＲＮのインタフェース点である。
（２）ｅＮＢの上位装置への通知が不要なメッセージとする。上位装置の具体例としては、ＭＭＥ、ＨＳＳなどがある。
（３）ＲＲＣメッセージとする。
（４）前記（１）〜（３）の組合せ。
「Uu keep alive ind」をＲＲＣメッセージとする場合の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＲＲＣシグナル、あるいはＲＲＣメッセージを設ける。
（２）既存のＲＲＣシグナル、あるいはＲＲＣメッセージを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＲＲＣシグナルにマッピングするパラメータの具体例として、以下の（１）〜（７）の７つを開示する。
（１）「Uu keep alive ind」である旨、「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」である旨、「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求する旨など。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。
（４）「Uu keep alive ind」送信周期。「Uu keep alive ind」送信周期を受信したｅＮＢは、データモニタタイマを「Uu keep alive ind」送信周期よりも長く設定してもよい。ｅＮＢは、ＤＲＸ周期を「Uu keep alive ind」送信周期の整数倍、あるいは整数の逆数倍（１／整数倍）と設定してもよい。「Uu keep alive ind」送信周期の決定主体がＵＥの場合のみ通知するとすればよい。
（５）ＲＲＣ状態判断の際に用いる、予め決められた回数。予め決められた回数の決定主体がＵＥの場合のみ通知するとしてもよい。
（６）ＲＲＣ状態判断の際に用いる、予め決められた期間。予め決められた回数の決定主体がＵＥの場合のみ通知するとしてもよい。
（７）前記（１）〜（６）の組合せ。
「Uu keep alive ind」送信周期をＤＲＸ周期に依存して決定しない場合であっても、「Uu keep alive ind」を、ＤＲＸ周期タイミングで送信するとしてもよい。ＤＲＸ周期のアクティブ期間（on duration期間）で送信するとしてもよい。これによって、RRC＿CONNECTED中のＵＥがＰＤＣＣＨをモニタするタイミングであるＤＲＸ周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
「Uu keep alive ind」送信周期をＤＲＸ周期に依存して決定しない場合に、「Uu keep alive ind」を、ＤＲＸ周期タイミングで送信する方法の具体例を以下に開示する。
「Uu keep alive ind」送信周期の満了直後のＤＲＸ周期タイミングで、「Uu keep alive ind」を送信する。その場合、ｅＮＢは、「Uu keep alive ind」送信周期の満了直後のＤＲＸ周期タイミングで、「Uu keep alive ind」を受信すればよい。
また、前述の実施の形態２に示す「Uu keep alive ind」は、コネクションの状態通知用のメッセージであるので、通常のユーザデータの送信とは異なり、本データ送信によって、ＤＲＸ長を変更しないとしてもよい。具体例としては、「Uu keep alive ind」によって、比較的長いＤＲＸ周期から比較的短いＤＲＸ周期に移行しない。
図３０に示すシーケンスは、図２７〜図２９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ５１０１、ステップＳＴ５１０３〜ステップＳＴ５１０５、ステップＳＴ５１２９〜ステップＳＴ５１３０において、ＵＥとアプリケーションサーバとの間で、エンドツーエンド（End to End）のサービスが実行され、アプリケーションデータがＵＥからアプリケーションサーバに通信される。
ＵＥは、ＮＡＳからのＲＲＣ＿ＩＤＬＥへの移行指示によってＲＲＣ接続リリース（RRC Connection release）処理が起動されるまで、ステップＳＴ５２０１〜ステップＳＴ５２０４において、ｅＮＢに、「Uu keep alive indication」を通知する。
ＵＥは、「Uu keep alive indication」を通知することによって、ＵＥがまだＲＲＣ＿ＩＤＬＥに移行しないこと、すなわちＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態であることをｅＮＢに示す。ｅＮＢは、ＵＥからの「Uu keep alive indication」を受信することによって、ＵＥがまだＲＲＣ＿ＩＤＬＥに移行していないこと、すなわちＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態であることを認識する。
ｅＮＢは、ＵＥからの「Uu keep alive indication」を受信できたか否かで、ｅＮＢとのＲＲＣ接続（RRC Connection）状態を判断する。ｅＮＢは、「Uu keep alive indication」送信周期のタイミングにおいて、ＵＥからの「Uu keep alive indication」を受信できたか否かを判断する。
ステップＳＴ５２０１〜ステップＳＴ５２０４において、ＵＥは、ｅＮＢに「Uu keep alive indication」を周期的に送信した後、ＵＥのアプリケーションでデータの発生が無くなると、ＮＡＳの指示によってＵＥは、ステップＳＴ５１３１において、ＲＲＣ接続リリース（RRC Connection Release）処理を行い、ステップＳＴ５１０１において、ＲＲＣ＿ＩＤＬＥに移行する。ＵＥは、ＲＲＣ＿ＩＤＬＥに移行すると、「Uu keep alive indication」の送信を停止する。
ＵＥが「Uu keep alive indication」の送信を停止すると、ｅＮＢは、「Uu keep alive indication」送信周期のタイミングで「Uu keep alive indication」を受信できないことになる。すなわち、ステップＳＴ５２０５において、キープアライブ未達でキープアライブ送信周期タイマが満了する。したがって、ｅＮＢは、ＵＥがＲＲＣ＿ＩＤＬＥへの移行、またはｅＮＢ圏外への移動などの何らかの原因によって、ｅＮＢとＵＥとの間のＲＲＣ接続（RRC Connection）中の状態が正常に維持されていないことを認識することができる。
ステップＳＴ５２０５において、ｅＮＢは、「Uu keep alive indication」送信周期のタイミングにおいて「Uu keep alive indication」を受信できない場合、ステップＳＴ５１３４のＳ１リリース処理Ａ（S1 Release Procedure A）を起動する。
ステップＳＴ５１３４においてＳ１リリース処理が行われると、ｅＮＢは、ステップＳＴ５１０２において、ＵＥに対してＲＲＣ＿ＩＤＬＥ状態に移行し、ＭＭＥは、ステップＳＴ５１０３において、ＵＥに対してＥＣＭ＿ＩＤＬＥ状態に移行する。Ｓ１リリース処理において、ｅＮＢおよびＭＭＥは、ＵＥに対するシステムリソースをリリースする。
本実施の形態で開示した方法によって、Ｅ−ＵＴＲＡＮは、ＵＥのＲＲＣ接続（RRC Connection）状態を認識することができるので、前記状態不一致の期間を多くとも「Uu keep alive indication」送信周期内に収めることができる。したがって、その状態不一致による影響を大幅に軽減することが可能となる。例えば、ｅＮＢにおけるＵＥのためのリソースの不必要な消費を無くすことが可能となる。また、ＵＥへの呼出しが不可能な状態が発生する頻度を低減することが可能となる。
また、「Uu keep alive ind」送信周期とＤＲＸ周期とを関係付けることで、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＥがＰＤＣＣＨをモニタするタイミングであるＤＲＸ周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、ＵＥの低消費電力化を図ることができるという効果を得ることができる。
また、「Uu keep alive ind」送信周期とデータモニタタイマとを関係付けることで、ＵＥが「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」の継続を要求している期間、ｅＮＢによるデータモニタタイマ満了による、ｅＮＢによるＲＲＣ＿ＩＤＬＥへの移行起動を避けることができる。これによって、ＵＥとｅＮＢとの間のＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を継続することが可能となる。
実施の形態３．
実施の形態３で解決する課題について、以下に説明する。前述したように、定期的に送信されるｋｅｅｐ-ａｌｉｖｅパケット（以下「APP keep alive packet」ともいう）によって、無線アクセスネットワークにおけるシステムリソースを使用してしまい、無線リソースおよび通信ノードにおける処理負荷などの増加を招くという問題が発生している。また、ＵＥの消費電力を増加させるという問題が発生している。
これらの問題は、以下のようにして発生する。ＵＥでは、アプリケーションレベルのセッションを接続中であるが、データ送信がないので、ＲＲＣ接続（RRC connection）および無線アクセスベアラなどを解放する処理を行い、ＩＤＬＥに移行する。しかし、アプリケーションからｋｅｅｐ-ａｌｉｖｅパケットが送信されると、ＲＲＣ接続（RRC connection）および無線アクセスベアラの設定を行う処理を行う。このようにＲＲＣ接続および無線アクセスベアラの解放処理と設定処理とを繰り返すことによって、前述の問題が発生する。
図３１および図３２は、実施の形態３で解決する課題を説明するためのシーケンスを示す図である。図３１と図３２とは、境界線ＢＬ７の位置で、つながっている。図３１および図３２に示すシーケンスは、図２７〜図２９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ５１０１、ステップＳＴ５１０４〜ステップＳＴ５１０５、ステップＳＴ５１２９〜ステップＳＴ５１３０において、ＵＥとアプリケーションサーバとの間で、エンドツーエンド（End to End）のサービスが実行され、アプリケーションデータがＵＥからアプリケーションサーバに通信される。
ｅＮＢは、データの送受信が行われたか否かをモニタし、所定の期間にデータの送受信が行われなかった場合、ステップＳＴ５１３４のＳ１リリース処理Ａ（S1 Release Procedure A）を起動する。所定の期間として、データモニタタイマを設けてもよい。ステップＳＴ７１０１において、データモニタタイマが満了したか否かを判断する。ステップＳＴ５１３４のＳ１リリース処理によって、無線ベアラ、Ｓ１ベアラ、ＥＰＳベアラがリリースされる。ＵＥは、ステップＳＴ５１０１においてＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行する。また、ｅＮＢはＲＲＣ＿ＩＤＬＥ状態に移行し、ＭＭＥはＥＣＭ＿ＩＤＬＥ状態に移行する。
その後、ステップＳＴ７１０２において、ＵＥのアプリケーションから定期的に送信される「APP keep alive packet」が発生し、ＵＥは、「APP keep alive packet」に応じて再度、ステップＳＴ５１０５のサービス要求処理Ａを起動する。サービス要求処理Ａによって、ＵＥはＲＲＣ／ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。また、ｅＮＢは、ＵＥに対してＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行し、ＭＭＥは、ＵＥに対してＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。これによって、ＵＥとアプリケーションサーバとの間での通信が可能となる。
ＵＥは、ステップＳＴ７１０３において、「APP keep alive packet」をアプリケーションサーバに送信する。
ｅＮＢは、データの送受信が行われたか否かをモニタしており、ＵＥからアプリケーションサーバへの「APP keep alive packet」の送信後、データの送受信が行われず、ステップＳＴ７１０４において、データモニタタイマが満了した場合、ステップＳＴ５１３４において、再びＳ１リリース処理Ａを起動することになる。このＳ１リリース処理Ａによって、無線ベアラ、Ｓ１ベアラ、ＥＰＳベアラがリリースされ、ステップＳＴ５１０１において、再びＵＥは、ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行してしまう。また、ｅＮＢは、ＲＲＣ＿ＩＤＬＥ状態に移行し、ＭＭＥは、ＥＣＭ＿ＩＤＬＥ状態に移行してしまう。
「APP keep alive packet」の送信終了後にアプリケーションデータが発生せず、定期的に「APP keep alive packet」が送信される状態になる場合が多く存在するので、前述のように、ＵＥとｅＮＢとの間のＲＲＣ接続状態の遷移が頻繁に繰り返されることになる。このようにＲＲＣ接続状態の遷移が頻繁に繰り返されると、ＲＲＣ接続状態の遷移のためのシグナリング量が増大し、無線アクセスネットワークにおけるシステムリソースの増大およびＵＥの消費電力の増加という問題が発生する。
また、ＵＥでは、ＲＲＣの状態とＥＣＭの状態とは連動して遷移する。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態のＵＥにおいてＲＲＣ接続（RRC Connection）がリリースされた場合、ＥＣＭ＿ＩＤＬＥ状態となる。ＲＲＣ接続がリリースされると、ＲＲＣ＿ＩＤＬＥ状態となる。したがって、ＲＲＣ接続のリリースによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥに遷移し、連動してＥＣＭ＿ＣＯＮＮＥＣＴＥＤからＥＣＭ＿ＩＤＬＥに遷移する（非特許文献１４ ４．６．４章参照）。
ネットワークでは、ＲＲＣの状態とＥＣＭの状態とは連動して遷移する。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態のｅＮＢにおいて、対象となるＵＥのＲＲＣ状態がＲＲＣ＿ＩＤＬＥに遷移したと想定した場合、Ｓ１リリース処理（S1 Release Procedure）が起動される。Ｓ１接続がリリースされることから、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤからＥＣＭ＿ＩＤＬＥに遷移する。したがって、ＲＲＣ＿ＩＤＬＥへの遷移に連動し、Ｓ１接続がリリースされ、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤからＥＣＭ＿ＩＤＬＥに遷移する（非特許文献１４ ４．６．４章参照）。
前述のように、ＲＲＣ接続状態の遷移が頻繁に繰り返されることで、ＥＣＭ状態の遷移も頻繁に繰り返される。これによって、例えばＳ１ベアラの設立および解放の制御処理が頻繁に行われることとなり、シグナリング量が増大し、無線アクセスネットワークにおけるシステムリソースの増大という問題が発生する。
実施の形態３における前記課題の解決策を以下に示す。前述の問題を解決するために、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させる。ｅＮＢにおいて、そのＵＥのＲＲＣ状態を認識することによって、ＡＰＰセッションの接続状態を認識し、ネットワーク側エンティティ、例えばＳ−ＧＷにその情報を通知する。通知を受けたネットワーク側エンティティ、例えばＳ−ＧＷにおいて、擬似的なｋｅｅｐ-ａｌｉｖｅパケット（以下、「擬似APP keep alive packet」または「ローカルAPP keep alive packet」ともいう）の送信制御を行う。
なお、ｅＮＢにおけるＵＥのＲＲＣ状態認識は、現状の３ＧＰＰ規格に準ずるものとする。
また、ＵＥは、アプリケーションから送信要求のあるｋｅｅｐ-ａｌｉｖｅパケットはＵｕ点上に送信しないものとする。
Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させる方法を実行するか否かの判断主体の具体例を以下に示す。（１）ＵＥ。（２）ネットワーク側。具体的には、Ｓ−ＧＷ、あるいはＰ−ＧＷ。
判断の具体例として、以下の（１Ａ），（２Ａ）の２つを開示する。
（１Ａ）判断主体がＵＥの場合について開示する。ＵＥは、アクセス要求を行ったアプリケーションに基づいて判断する。ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションか否かを判断する。
ＵＥは、前記判断の結果、ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションであると判断した場合は、ＵＥ（ＮＡＳ）において、ＵＥのアプリケーションに対して、ローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）を通知する。
また、ＵＥは、前記判断の結果（以下「APP keep alive情報」と称することもある）をネットワーク側へ通知する。ネットワーク側の具体例としては、ローカルAPP keep alive packetをアプリケーションサーバに送信するエンティティがある。例えば、Ｓ−ＧＷなどである。
通知方法の具体例としては、ＵＥはＭＭＥに、ローカルAPP keep alive packetの送信の要求を通知する。ローカルAPP keep alive packetの送信の要求を受信したＭＭＥは、Ｓ−ＧＷに対して、ローカルAPP keep alive packetの送信の要求を通知する。
ＵＥがＭＭＥにローカルAPP keep alive packetの送信の要求を通知する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＮＡＳシグナルを新設する。
（２）既存のＮＡＳシグナルを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＮＡＳシグナルにマッピングするパラメータの具体例として、以下の（１）〜（５）の５つを開示する。
（１）ローカルAPP keep alive packetの送信の要求である旨、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報など。以下、「APP keep alive情報」と称することもある。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）接続先であるアプリケーションサーバの情報。
（４）ｋｅｅｐ-ａｌｉｖｅパケットの送信周期。
（５）前記（１）〜（４）の組合せ。
既存のＮＡＳシグナルを用いる場合の具体例としては、サービス要求（Service Request）メッセージを用いる場合が挙げられる。
既存のＮＡＳシグナリングに追加が必要なパラメータの具体例として、以下の（１）〜（３）の３つを開示する。
（１）ローカルAPP keep alive packetの送信の要求である旨など、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報など。
（２）接続先であるアプリケーションサーバの情報。
（３）ｋｅｅｐ-ａｌｉｖｅパケットの送信周期。
ＭＭＥがＳ−ＧＷにローカルAPP keep alive packetの送信の要求を通知する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＳ１１シグナルを新設する。
（２）既存のＳ１１シグナルを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＳ１１シグナルにマッピングするパラメータの具体例として、以下の（１）〜（５）の５つを開示する。
（１）ローカルAPP keep alive packetの送信の要求である旨など、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報など。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）接続先であるアプリケーションサーバの情報。
（４）ｋｅｅｐ-ａｌｉｖｅパケットの送信周期。ｋｅｅｐ−ａｌｉｖｅパケットの送信周期を受信したＳ−ＧＷは、ローカルAPP keep alive packetの送信周期をｋｅｅｐ−ａｌｉｖｅパケットの送信周期と同じに設定してもよい。
（５）前記（１）〜（４）の組合せ。
既存のＳ１１シグナルを用いる場合の具体例としては、ベアラ修正要求（Modify Bearer Request）メッセージを用いる場合が挙げられる。
既存のＳ１１シグナリングに追加が必要なパラメータの具体例として、以下の（１）〜（３）の３つを開示する。
（１）ローカルAPP keep alive packetの送信の要求である旨など、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報など。
（２）接続先であるアプリケーションサーバの情報。
（３）ｋｅｅｐ-ａｌｉｖｅパケットの送信周期など。
ｋｅｅｐ−ａｌｉｖｅパケットの送信周期を受信したＳ−ＧＷは、ローカルAPP keep alive packetの送信周期を、ｋｅｅｐ−ａｌｉｖｅパケットの送信周期と同じに設定してもよい。
（２Ａ）判断主体がネットワーク側、例えばＳ−ＧＷの場合について開示する。Ｓ−ＧＷは、アクセス要求を行ったアプリケーションに基づいて判断する。ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションか否かを判断する。
Ｓ−ＧＷは、前記判断の結果、ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションであると判断した場合は、ローカルAPP keep alive packetをアプリケーションサーバに送信する。
また、Ｓ−ＧＷは、前記判断の結果（以下「APP keep alive情報」と称することもある）をＵＥ側に通知する。
通知方法の具体例としては、Ｓ−ＧＷはＭＭＥにローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求を通知する。ローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求を受信したＭＭＥは、ｅＮＢ経由で、ＵＥに対してローカルAPP keep alive packet送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求を通知する。
Ｓ−ＧＷがＭＭＥにローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求を通知する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＳ１１シグナルを新設する。
（２）既存のＳ１１シグナルを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＳ１１シグナルにマッピングするパラメータの具体例として、以下の（１）〜（５）の５つを開示する。
（１）ローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求である旨など、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報など。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）接続先であるアプリケーションサーバの情報。
（４）ローカルAPP keep alive packet送信周期。
（５）前記（１）〜（４）の組合せ。
既存のＳ１１シグナルを用いる場合の具体例としては、ベアラ修正応答（Modify Bearer Response）メッセージを用いる場合が挙げられる。
既存のＳ１１シグナリングに追加が必要なパラメータの具体例として、以下の（１）〜（３）の３つを開示する。
（１）ローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求である旨など、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報など。
（２）接続先であるアプリケーションサーバの情報。
（３）ローカルAPP keep alive packetの送信周期。
ＭＭＥがＵＥにローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）の要求を通知する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにシグナルを新設する。
（２）既存のシグナルを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たにＮＡＳシグナルにマッピングするパラメータの具体例として、以下の（１）〜（５）の５つを開示する。
（１）ローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求である旨、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態を一致させることを設定するための情報など。以下、「APP keep alive情報」と称することもある。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）接続先であるアプリケーションサーバの情報。
（４）ローカルAPP keep alive packet送信周期。
（５）前記（１）〜（４）の組合せ。
次に、既存のシグナルを用いる場合の具体例としては、サービス要求（Service Request）処理を用いる。具体的には、サービス要求処理中の初期コンテキストセットアップ要求（Initial Context Setup Request）、ＲＲＣ接続再設定（RRC Connection Reconfiguration）などがある。
既存のシグナリングに追加が必要なパラメータの具体例として、以下の（１）〜（３）の３つを開示する。
（１）ローカルAPP keep alive packetの送信に対するＡｃｋ（ローカルＡｃｋ）送信の要求である旨など、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報など。
（２）接続先であるアプリケーションサーバの情報。
（３）ローカルAPP keep alive packetの送信周期。
図３３〜図３５は、実施の形態３における通信システムのシーケンスの一例を示す図である。図３３と図３４とは、境界線ＢＬ８の位置で、つながっている。図３４と図３５とは、境界線ＢＬ９の位置で、つながっている。図３３〜図３５に示すシーケンスは、図２７〜図２９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ＵＥは、ＴＣＰ／ＩＰ上で実行されるアプリケーションを有する。図３３〜図３５では、ステップＳＴ５１０１において、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態にあり、ステップＳＴ５１０２において、ｅＮＢは、ＵＥに対してＲＲＣ＿ＩＤＬＥ状態にあり、ステップＳＴ５１０３において、ＭＭＥは、ＵＥに対してＥＣＭ＿ＩＤＬＥ状態にある場合について示している。
ＵＥのアプリケーションがアクセス開始するような場合、ステップＳＴ５１０４において、ＵＥのアプリケーションは、ＵＥのＮＡＳに対してアクセス要求（Access Request）を行う。このアクセス要求に従い、ＵＥは、ステップＳＴ７２０１において、サービス要求処理Ｂ（Service Request Procedure B）を起動する。
ステップＳＴ７２０１のサービス要求処理Ｂは、図２７のステップＳＴ５１０５のサービス要求処理Ａの一部を変更すればよい。以下に、変更部分について説明する。
ステップＳＴ７２０２においてＵＥのＮＡＳからＡＳに通知するサービス要求メッセージに、「APP keep alive情報」を含める。「APP keep alive情報」は、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するための情報である。例えば、設定するか否かを示す情報としてもよいし、設定する場合にのみ該情報をメッセージに含めるようにしてもよい。
ＵＥは、ステップＳＴ７２０３において、サービス要求メッセージに「APP keep alive情報」を含めてｅＮＢに通知する。
ステップＳＴ７２０３で「APP keep alive情報」を受信したｅＮＢは、ステップＳＴ７２０４のサービス要求メッセージに、「APP keep alive情報」を含めてＭＭＥに通知する。
「APP keep alive情報」を受信したＭＭＥは、ステップＳＴ７２０５のベアラ修正要求メッセージに「APP keep alive情報」を含めてＳ−ＧＷに通知する。このようにすることによって、ネットワーク側のエンティティであるＳ−ＧＷに、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するか否かを通知することが可能となる。したがって、Ｓ−ＧＷは、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることを設定するか否かに応じた処理を行うことが可能となる。
図３３〜図３５に示す例では、ステップＳＴ７２０２、ステップＳＴ７２０３、ステップＳＴ７２０４、ステップＳＴ７２０５の「APP keep alive情報」として、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させるように設定する場合について示している。
ＵＥは、アプリケーションから送信要求のあるｋｅｅｐ-ａｌｉｖｅパケットをＵｕ点上に送信しないものとする。図３５のステップＳＴ７２０６において、ＵＥは、アプリケーションにおいて、APP keep alive packet送信周期タイマ（以下「キープアライブ送信周期タイマ」という場合がある）が満了したか否かを判断する。キープアライブ送信周期タイマが満了したと判断された場合は、ステップＳＴ７２０７において、ＮＡＳに対して「APP keep alive packet」を送信する。「APP keep alive packet」の発生で、ＵＥは、「APP keep alive packet」をＵｕ点上に送信しないので、サービス要求処理を起動しない。
なお、ＵＥにおいて、アプリケーションからの「APP keep alive packet」を受信したＮＡＳは、ステップＳＴ７２０９において、応答メッセージをアプリケーションに通知してもよい。この応答メッセージを、ローカル応答と称する。ＵＥのＮＡＳは、ＲＲＣ／ＥＣＭの状態を認識し、ＲＲＣ／ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態の場合、アプリケーションに対してＡｃｋ（ローカルＡｃｋ）を通知する。ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態の場合、アプリケーションに対してＮａｃｋ（ローカルＮａｃｋ）を通知する。
ローカルＡｃｋを受信したＵＥのアプリケーションは、ＲＲＣ／ＥＣＭが接続されている状態と判断し、「APP keep alive packet」の送信を継続してセッションの接続状態を保つ。ローカルＮａｃｋを受信したＵＥのアプリケーションは、ＲＲＣ／ＥＣＭが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
ステップＳＴ７２０９においてＮＡＳからローカルＡｃｋを受信したアプリケーションは、ステップＳＴ７２１１においてキープアライブ送信周期タイマが満了したと判断された場合、ステップＳＴ７２１３において、継続して「APP keep alive packet」の送信を行う。ＵＥのＲＲＣ／ＥＣＭの状態が接続状態であるので、ステップＳＴ７２１５において、ＮＡＳは、ローカルＡｃｋをアプリケーションに通知する。
一方、ネットワーク側エンティティ、例えばＳ−ＧＷは、擬似的なｋｅｅｐ-ａｌｉｖｅパケット（以下「ローカルAPP keep alive packet」ともいう）の送信制御を行う。Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させる設定の「APP keep alive情報」を受信したＳ−ＧＷは、ローカルAPP keep alive packetを発生させ、アプリケーションサーバに送信することを決定する。
Ｓ−ＧＷは、ローカルAPP keep alive packetを定期的または周期的に発生させ、ＥＰＳベアラが設立されている限り、ローカルAPP keep alive packetを定期的または周期的に発生させ、アプリケーションサーバに送信する。
ステップＳＴ７２０５において、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させる設定の「APP keep alive情報」を受信したＳ−ＧＷは、ステップＳＴ７２０８において、ローカルAPP keep alive packet送信周期タイマ（以下「ローカルキープアライブ送信周期タイマ」という場合がある）が満了したか否かを判断する。
Ｓ−ＧＷは、ローカルキープアライブ送信周期タイマが満了したと判断した場合は、ステップＳＴ７２１０において、ローカル（Local）APP keep alive packetをアプリケーションサーバに送信する。
Ｓ−ＧＷは、ＥＰＳベアラが設立されているか否かを判断し、設立されていると判断した場合は、継続してステップＳＴ７２１２において、ローカルキープアライブ送信周期タイマが満了したか否かを判断する。Ｓ−ＧＷは、ローカルキープアライブ送信周期タイマが満了したと判断した場合は、ステップＳＴ７２１４において、ローカル（Local）APP keep alive packetをアプリケーションサーバに送信する。
ここで、ローカルAPP keep alive packetを受信したＡＰＰサーバは、Ｓ−ＧＷに対して応答信号（Ａｃｋ）を送信してもよい。応答信号は、応答メッセージであってもよい。アプリケーション側で、該ＵＥとのセッション終了となった場合は、ＡＰＰサーバから、Ｓ−ＧＷに対して、前記応答信号が送信されないようにしてもよい。
Ｓ−ＧＷは、ローカルAPP keep alive packetに対する、ＡＰＰサーバからの応答信号を受信した場合、該ＵＥに対するセッションが継続していると判断してもよい。一方、ローカルAPP keep alive packetに対する、ＡＰＰサーバからの応答信号を受信しない場合、Ｓ−ＧＷは、該ＵＥに対するセッションが終了していると判断してもよい。該ＵＥに対するセッションが終了していると判断した場合、Ｓ−ＧＷは、ＥＰＳベアラのリリース処理を起動してもよい。
ステップＳＴ７２１６において、ｅＮＢは、データの送受信が行われたか否かをモニタする。所定の期間にデータの送受信が行われなかった場合、ステップＳＴ５１３４のＳ１リリース処理Ａを起動する。Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させる設定を行った場合、ステップＳＴ７２１６において、データモニタタイマを長期間に設定する。図３１および図３２のステップＳＴ７１０１、ステップＳＴ７１０４およびステップＳＴ７１１８に示したデータモニタタイマよりも長期間に設定するとよい。
ステップＳＴ５１３４のＳ１リリース処理Ａによって、無線ベアラ、Ｓ１ベアラ、ＥＰＳベアラがリリースされる。ステップＳＴ５１０１において、ＵＥは、ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行する。ステップＳＴ５１０２において、ｅＮＢは、ＵＥに対してＲＲＣ＿ＩＤＬＥ状態に移行する。ステップＳＴ５１０３において、ＭＭＥは、ＵＥに対してＥＣＭ＿ＩＤＬＥ状態に移行する。
また、ＵＥがデータの送受信が行われたか否かをモニタしてもよい。所定の期間にデータの送受信が行われなかった場合、ＵＥのＮＡＳは、アプリケーションから「APP keep alive packet」を受信した場合においても、ローカル応答をアプリケーションに通知しないようにしてもよい。これによって、ＵＥ側のアプリケーションは、セッションが終了されたと認識する。
また、所定の期間にデータの送受信が行われなかった場合、ＵＥはＭＭＥにローカルAPP keep alive packetの送信停止の要求を通知する。ローカルAPP keep alive packetの送信停止の要求を受信したＭＭＥは、Ｓ−ＧＷに対してローカルAPP keep alive packetの送信停止の要求を通知するようにしてもよい。ローカルAPP keep alive packetの送信停止の要求を受信したＳ−ＧＷは、ローカルAPP keep alive packetの送信を停止する。これによって、ＡＰＰサーバ側のアプリケーションにおいても該ＵＥに対するセッションを終了させることが可能となる。
ステップＳＴ５１０１においてＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを認識したＵＥは、ステップＳＴ７２１８において、アプリケーションに対してＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを通知する。このメッセージを、ローカルリリースと称する。ローカルリリースを受信したアプリケーションは、ＲＲＣ／ＥＣＭが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
一方、ＥＰＳベアラがリリースしたことを認識したＳ−ＧＷは、ステップＳＴ７２１７において、ローカルAPP keep alive packet（以下「ローカルキープアライブパケット」という場合がある）の生成を停止する。
ステップＳＴ７２１９において、Ｓ−ＧＷは、アプリケーションサーバに対してアプリケーションセッションのリリース（Local APP Session Release）メッセージを通知する。アプリケーションセッションのリリースメッセージ内に、ローカルAPP keep alive packetの生成を停止する理由の情報を含めてもよい。また、ローカルAPP keep alive packetの生成を停止する場合のアプリケーションセッションリリースメッセージを新たに設けてもよい。ローカルAPP keep alive packetの生成を停止する場合のアプリケーションセッションリリースメッセージを、ローカルアプリケーションリリースと称する。アプリケーションリリースメッセージを受信したアプリケーションサーバは、ＥＰＳベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。また、セッションの再起動を行ってもよい。
前述の方法を行うことによって、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させることができる。これによって、Ｕｕ点においてアプリケーションからのｋｅｅｐ-ａｌｉｖｅパケットの発生によってＲＲＣおよびＲＡＢの状態を適宜変化させる必要が無くなる。
ステップＳＴ７２１６のデータモニタタイマを長期間に設定することで、ステップＳＴ５１３４のＳ１リリース処理Ａを起動させる頻度を削減することが可能となる。したがって、無線ベアラ、Ｓ１ベアラ、ＥＰＳベアラがリリースされる頻度を削減することができ、アプリケーションからの「APP keep alive packet」送信のためにＲＲＣ／ＥＣＭ状態を移行させるためのシグナリングを削減することが可能となる。これによって、アプリケーションからのｋｅｅｐ-ａｌｉｖｅパケットの発生による不要なシグナリングの増大を抑制することができ、システムリソースに対する影響を軽減することができる。
実施の形態３ 変形例１．
実施の形態３の変形例１で解決する課題は、前述の実施の形態３における課題と同一であり、以下に説明する。実施の形態３においては、ＵＥとｅＮＢのＲＲＣ接続（RRC Connection）の状態を用いていたので、前述の実施の形態２において挙げた、ＵＥとｅＮＢとの間での状態不一致の課題が発生し得る。
前記課題を解決するために、実施の形態３の変形例１では、前述の実施の形態２の対策案を実施の形態３において適用する。図３６および図３７は、実施の形態３の変形例１における通信システムのシーケンスの一例を示す図である。図３６と図３７とは、境界線ＢＬ１０の位置で、つながっている。図３６および図３７に示すシーケンスは、図３３〜図３５に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ５１０１〜ステップＳＴ５１０４、ステップＳＴ７２０１、ステップＳＴ５１２９〜ステップＳＴ５１３０において、ＵＥとアプリケーションサーバとの間でエンドツーエンド（End to End）のサービスが実行され、アプリケーションデータがＵＥからアプリケーションサーバに通信される。
本変形例では、前述の実施の形態３で開示した方法を用いるので、サービス要求処理として、ステップＳＴ７２０１において、「APP keep alive情報」を用いるサービス要求処理Ｂを行う。図３６および図３７では、「APP keep alive情報」として、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させるように設定する場合のシーケンスについて示している。
前述の実施の形態３で開示したように、ＵＥは、アプリケーションから送信要求のあるｋｅｅｐ-ａｌｉｖｅパケットをＵｕ点上に送信しないものとする。また、ネットワーク側エンティティ、例えばＳ−ＧＷは、ローカルAPP keep alive packetの送信制御を行う。このため、ステップSＴ７２０６〜ステップＳＴ７２１５の処理が行われる。
前述の実施の形態３では、ステップＳＴ５１３０のデータ送信が行われた後、ステップＳＴ７２１６においてデータモニタタイマが満了し、ステップＳＴ５１３４においてＳ１リリース処理が行われるまで、ＵＥとｅＮＢとのＲＲＣ接続（RRC Connection）の状態が維持される。この状態において、ＵＥがｅＮＢ圏外へ移動したり、ＵＥでの受信品質の劣化などの何らかの原因によって、ｅＮＢとのＲＲＣ接続（RRC Connection）中の状態が正常に維持されなくなる場合がある。このような場合、ＵＥは、ＲＲＣ状態をＲＲＣ＿ＩＤＬＥに移行するが、ｅＮＢでは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を維持したままとなる。したがって、ＵＥとｅＮＢとの間で状態不一致が生じるという問題が発生する。
また、ＵＥとｅＮＢとの間で状態不一致が生じたときに、ＲＲＣ＿ＩＤＬＥ状態になったことを認識したＵＥは、アプリケーションに対してＲＲＣ＿ＩＤＬＥ状態になったことを通知する。この通知を受信したアプリケーションは、ＲＲＣが接続されていない状態と判断し、「APP keep alive packet」の送信を停止し、セッションを終了する。このように、ＵＥのアプリケーションではセッションが終了する。しかし、ｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態を維持しているので、ＭＭＥは、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を維持し、Ｓ−ＧＷは、継続してローカルkeep alive packetを生成してアプリケーションサーバに送信する。したがって、アプリケーションサーバでは、セッションが接続されていると認識する。このように、ＵＥ側のアプリケーションとアプリケーションサーバとでも状態不一致が発生することになる。
前述の実施の形態２では、このような状態不一致の問題を改善するために、Ｕｕ点において、ＵＥのＲＲＣ接続（RRC Connection）中の状態通知用のメッセージを設け、ＵＥが、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態においては、定期的あるいは周期的に「Uu keep alive indication」を送信する方法を開示した。
本変形例では、この実施の形態２の対策案を適用する。図３６および図３７に示す例において、ステップＳＴ５１３０のデータ送信が行われた後、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥは、ステップＳＴ７３０１〜ステップＳＴ７３０５に示すように、「Uu keep alive indication」を周期的にｅＮＢに通知する。ＵＥは、「Uu keep alive indication」を通知することによって、ＵＥがまだＲＲＣ＿ＩＤＬＥに移行しないこと、すなわちＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態であることをｅＮＢに示す。
ｅＮＢは、ＵＥからの「Uu keep alive indication」を受信することで、ＵＥがまだＲＲＣ＿ＩＤＬＥに移行していない、すなわちＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態であると認識する。ｅＮＢは、ＵＥからの「Uu keep alive indication」を受信できたか否かで、ｅＮＢとのＲＲＣ接続（RRC Connection）の状態を判断する。ｅＮＢは、「Uu keep alive indication」送信周期のタイミングにおいて、ＵＥからの「Uu keep alive indication」を受信できたか否かを判断する。
ステップＳＴ７３０４において、ＵＥは、ｅＮＢに「Uu keep alive indication」を送信するが、何らかの原因によって、ＵＥとｅＮＢとのＲＲＣ接続（RRC Connection）状態が正常に維持されなくなり、ｅＮＢに「Uu keep alive indication」が未達になる場合がある。この場合、ステップＳＴ５２０５において、ｅＮＢは、「Uu keep alive indication」送信周期のタイミングで「Uu keep alive indication」を受信できないことになる。したがって、ｅＮＢは、ＵＥが何らかの原因によって、ｅＮＢとＵＥとの間のＲＲＣ接続（RRC Connection）中の状態が正常に維持されていないことを認識し、ステップＳＴ５１３４のＳ１リリース処理Ａを起動する。
ステップＳＴ５１３４においてＳ１リリース処理が行われると、ＵＥは、ステップＳＴ５１０１において、ＲＲＣ＿ＩＤＬＥ状態に移行する。ｅＮＢは、ステップＳＴ５１０２において、ＵＥに対してＲＲＣ＿ＩＤＬＥ状態に移行する。ＭＭＥは、ステップＳＴ５１０３において、ＵＥに対してＥＣＭ＿ＩＤＬＥ状態に移行する。Ｓ１リリース処理において、ｅＮＢおよびＭＭＥは、ＵＥに対するシステムリソースをリリースする。
ステップＳＴ５１０１においてＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを認識したＵＥは、ステップＳＴ７２１８において、アプリケーションに対してＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを通知する。ローカルリリースを受信したアプリケーションは、ＲＲＣ／ＥＣＭが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
ステップＳＴ５１３４においてＳ１リリース処理が行われ、ＥＰＳベアラがリリースされたことを認識したＳ−ＧＷは、ステップＳＴ７２１７において、ローカルAPP keep alive packetの生成を停止する。
ステップＳＴ７２１９において、Ｓ−ＧＷは、アプリケーションサーバに対してローカルアプリケーションセッションリリースメッセージを通知する。ローカルアプリケーションリリースメッセージを受信したアプリケーションサーバは、ＥＰＳベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。
本実施の形態で開示した方法により、Ｅ−ＵＴＲＡＮは、ＵＥのＲＲＣ接続（RRC Connection）状態を認識できるので、前述の実施の形態３で開示した方法において発生する前記状態不一致の期間を無くすことができる。したがって、その状態不一致による影響を大幅に軽減することが可能となる。例えば、ｅＮＢにおけるＵＥのためのリソースの不必要な消費を無くすことが可能となる。また、ＵＥへの呼出しが不可能な状態が発生する頻度を低減することが可能となる。
図３６および図３７で示した例では、ＵＥは、ステップＳＴ５１３４のＳ１リリース処理によって、ステップＳＴ５１０１においてＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行した。他の方法として、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にいるＵＥが、受信品質の劣化などの何らかの原因によってＲＲＣ＿ＩＤＬＥ状態に移行した場合に、ＵＥがＲＲＣ＿ＩＤＬＥ状態に移行したと判断し、ＵＥのアプリケーションに対してローカルリリースメッセージを通知してもよい。ＵＥは、ＲＲＣ＿ＩＤＬＥ状態に移行した場合、同時にＥＣＭ＿ＩＤＬＥ状態に移行したと判断してもよい。この場合、ステップＳＴ５１３４のＳ１リリース処理よりも前に、ＵＥは、ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行し、ＵＥのアプリケーションは、「APP keep alive packet」の送信を停止あるいはセッションの接続を切断する。
この場合も、前述の実施の形態３で開示した方法において発生する前記状態不一致の期間を多くとも「Uu keep alive indication」送信周期内に収めることができる。したがって、その状態不一致による影響を大幅に軽減することが可能となる。例えば、ｅＮＢにおけるＵＥのためのリソースの不必要な消費の削減、およびＵＥへの呼出しが不可能な状態が発生する頻度を低減することが可能となる。
実施の形態４．
実施の形態４で解決する課題は、前述の実施の形態３おける課題と同一であり、以下に説明する。
前述の実施の形態３においては、ＲＲＣ接続（RRC Connection）の状態とアプリケーションレベルのセッションの状態とを一致させたいので、アプリケーションレベルのセッションの接続中は、ＲＲＣ接続（RRC Connection）を維持する必要があった。このことは、ｋｅｅｐ-ａｌｉｖｅパケットによる影響を避けられる効果は大きいが、その代償として、ＲＲＣ接続（RRC Connection）を維持するための無線リソースを使用することとなる。
実施の形態４における前記課題の解決策を以下に示す。前述の問題を解決するために、ＲＲＣ＿ＩＤＬＥ状態においてアプリケーションのセッションの接続状態を通知するＵｕ点メッセージ（uu keep alive packet）を設ける。ＵＥは、ＲＲＣ＿ＩＤＬＥ状態に遷移した状態において、定期的あるいは周期的に「uu keep alive packet」を送信する。ｅＮＢは、ＵＥからの「uu keep alive packet」の受信およびＵＥに対するＲＲＣ状態から、ＵＥのアプリケーションのセッションの接続状態を認識し、何らかのネットワーク装置、例えばＳ−ＧＷにその情報を通知する。通知を受けた前記ネットワーク装置であるＳ−ＧＷにおいて、ローカルAPP keep alive packetの送信制御を行う。「uu keep alive packet」は、ＵＥがＲＲＣ＿ＩＤＬＥのときのみ送信する。「uu keep alive packet」送信において、ＲＲＣ状態は変化させない。つまり、ＩＤＬＥ時は、ＲＲＣ接続を開設せずに通知する。例えば、ＲＡＣＨを用いて通知する。なお、前述の実施の形態３と同様に、ＵＥは、アプリケーションから送信要求のあるｋｅｅｐ-ａｌｉｖｅパケットはＵｕ点上に送信しないものとする。
図３８および図３９は、実施の形態４における通信システムのシーケンスの一例を示す図である。図３８と図３９とは、境界線ＢＬ１１の位置で、つながっている。図３８および図３９に示すシーケンスは、図３３〜図３５に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ５１０１〜ステップＳＴ５１０４、ステップＳＴ７２０１、ステップＳＴ５１２９〜ステップＳＴ５１３０において、ＵＥとアプリケーションサーバとの間でエンドツーエンド（End to End）のサービスが実行され、アプリケーションデータがＵＥからアプリケーションサーバに通信される。
本変形例では、前述の実施の形態３で開示した方法を用いるので、サービス要求処理として、ステップＳＴ７２０１において、「APP keep alive情報」を用いるサービス要求処理Ｂを行う。図３８および図３９では、「APP keep alive情報」として、Ｕｕ点のＲＲＣ状態とＡＰＰのセッションの接続状態とを一致させるように設定する場合のシーケンスについて示している。
前述の実施の形態３で開示したように、ＵＥは、アプリケーションから送信要求のあるｋｅｅｐ-ａｌｉｖｅパケットをＵｕ点上に送信しないものとする。また、ネットワーク側エンティティ、例えばＳ−ＧＷは、ローカルAPP keep alive packetの送信制御を行う。このため、ステップＳＴ７２０６〜ステップＳＴ７２１５の処理が行われる。
前述の実施の形態３では、ＲＲＣ接続（RRC Connection）の状態とアプリケーションレベルのセッションの状態とを一致させたいので、アプリケーションレベルのセッションの接続中は、ＲＲＣ接続（RRC Connection）を維持する必要があった。したがって、ステップＳＴ５１３０のデータ送信が行われた後、ステップＳＴ７２１６においてデータモニタタイマが満了し、ステップＳＴ５１３４においてＳ１リリース処理が行われるまで、ＵＥとｅＮＢとのＲＲＣ接続（RRC Connection）の状態が維持される。このことは、ｋｅｅｐ-ａｌｉｖｅパケットによる影響を避けられる効果は大きいが、その代償として、ＲＲＣ接続（RRC Connection）を維持するための無線リソースを使用することとなる。
本実施の形態では、このような問題を改善する方法を開示する。図３８のステップＳＴ５１３０のデータ送信が行われた後、ＵＥに対するＲＲＣ接続（RRC connection）がＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるｅＮＢは、所定の期間に、ＵＥへのデータの発生の有無をモニタする。またはＵＥとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。所定の期間を計測する手段として、タイマを設けてもよい。以下、このタイマを「ＲＲＣデータモニタタイマ」と称する。
ｅＮＢは、ステップＳＴ７４０２でＵＥへのデータが発生せず、ＲＲＣデータモニタタイマが満了した場合、ステップＳＴ７４０３において、ＲＲＣ接続のリリース処理を起動する。この処理により、ステップＳＴ７４０４およびステップＳＴ７４０５において、ｅＮＢとＵＥとは、ＲＲＣ＿ＩＤＬＥ状態に移行する。
前述の処理では、ＵＥとｅＮＢとの間のＲＲＣ接続状態のみを、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態からＲＲＣ＿ＩＤＬＥ状態に移行させる。このようにすることによって、ＵＥとｅＮＢとは、ＲＲＣ接続のための無線リソースをリリースできる。
ＵＥは、ｅＮＢからのＲＲＣ接続リリースメッセージに従って、ＲＲＣ＿ＩＤＬＥ状態に移行することを開示したが、他の方法として、ＵＥにおいてもｅＮＢへのデータの発生の有無をモニタしてもよい。またはｅＮＢとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。データの発生が無く、ＵＥ側のＲＲＣデータモニタタイマが満了した場合、ＲＲＣ接続のリリース処理を起動し、ＲＲＣ＿ＩＤＬＥ状態に移行する。また、他の方法として、ＵＥは、ＲＲＣの規定に従い、ＲＲＣ＿ＩＤＬＥ状態に移行してもよい。ＲＲＣの規定としては、例えば、ＲＬＦ（Rsdio Link Failure）などがある。
本実施の形態では、ステップＳＴ７４０４でＲＲＣ＿ＩＤＬＥ状態に移行したＵＥは、アプリケーションに対してＲＲＣ＿ＩＤＬＥ状態になったことを通知しないようにする。あるいは、ＲＲＣ＿ＩＤＬＥ状態に移行したＵＥは、アプリケーションに対してＲＲＣ＿ＩＤＬＥ状態になったことを通知するが、アプリケーションは、ＲＲＣ＿ＩＤＬＥ状態になったことの通知を受信したとき、「APP keep alive packet」の送信の停止、またはセッションの接続の切断を行わないようにしてもよい。ＲＲＣ＿ＩＤＬＥ状態になったことの通知に、ＲＲＣ状態のみ、ＲＲＣ＿ＩＤＬＥ状態に移行したことを示す情報を含めておくとよい。あるいは、ＵＥにおいて、ＲＲＣ状態、ＥＣＭ状態など、どの状態がＩＤＬＥに移行したかどうかの情報としてもよい。あるいは、無線ベアラ、Ｓ１ベアラ、ＥＰＳベアラなど、どのベアラがリリースされたかを示す情報としてもよい。前記情報に基づいて、ＵＥのアプリケーションは、「APP keep alive packet」の送信の停止、またはセッションの接続の切断を行うかどうかを判断することができる。
ステップＳＴ７４０４において、ＲＲＣ＿ＩＤＬＥ状態に遷移したＵＥは、アプリケーションのセッションが接続していることをｅＮＢに通知するために、ステップＳＴ７２０７において、「uu keep alive packet」をｅＮＢに送信する。「uu keep alive packet」の送信は、アプリケーションのセッションが接続している限り、ステップＳＴ７４０６〜ステップＳＴ７４０８において周期的に継続して行われる。
ｅＮＢは、ＲＲＣ状態を判断し、ＲＲＣ＿ＩＤＬＥ状態において「uu keep alive packet」を受信することによって、ＵＥのアプリケーションのセッションの接続状態を認識することが可能となる。ＵＥのアプリケーションのセッションが接続状態に有る場合、ｅＮＢはＳ１リリース処理など、Ｓ１ベアラおよびＥＰＳベアラのリリース処理を行わない。Ｓ１リリース処理が行われないので、Ｓ−ＧＷは、ローカルkeep alive packetを生成し、アプリケーションサーバに対して通知する。これによって、アプリケーションサーバは、ＵＥとの接続を認識することができ、セッションを接続状態に保つことができる。
「uu keep alive packet」は、ＵＥがＲＲＣ＿ＩＤＬＥ時のみに送信するが、「uu keep alive packet」送信において、ＲＲＣ状態は変化させない。つまり、ＩＤＬＥ時は、ＲＲＣ接続（RRC connection）を設立せずに通知する。例えば、ＲＡＣＨを用いて通知する。これによって、「uu keep alive packet」送信時にＲＲＣ状態の遷移が不要になり、シグナリング量を削減することができる。
アプリケーションセッションが接続状態にある場合に、ステップＳＴ７４０９において、ＵＥは、ｅＮＢに「uu keep alive packet」を送信するが、何らかの原因によって、ｅＮＢに「uu keep alive packet」が未達になる場合がある。例えば、ＵＥがｅＮＢの圏外に移動したような場合に生じる。この場合、ステップＳＴ７４１０において、ｅＮＢは、「uu keep alive packet」送信周期のタイミングで「uu keep alive packet」を受信できないことになる。
したがって、ｅＮＢは、ＵＥが何らかの原因によって、ｅＮＢとＵＥとの間においてＲＲＣ接続（RRC Connection）することが不可能であることを認識し、ステップＳＴ５１３４のＳ１リリース処理Ａを起動する。
既存のＳ１リリース処理に限らず、ｅＮＢがＳ−ＧＷに、該ＵＥのＲＲＣ＿ＩＤＬＥ状態への移行を通知するメッセージを新たに設けてもよい。
新たに設けるメッセージの具体例としては、ｅＮＢが該ＵＥに対する無線リソースを解放している場合においては、ＲＲＣ接続処理を伴わず、Ｓ１ベアラのリリース処理を行うメッセージとする。あるいは、既存のＳ１リリース処理において、該ＵＥに対する無線リソースの有無を示す情報を新たに設けてもよい。該情報は、アクティブフラグであってもよい。
ステップＳＴ５１３４において、Ｓ１リリース処理Ａが行われると、ステップＳＴ５１０１において、ＵＥはＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行する。ステップＳＴ５１０２において、ｅＮＢは、ＵＥに対してＲＲＣ＿ＩＤＬＥ状態を維持する。ステップＳＴ５１０３において、ＭＭＥは、ＵＥに対してＥＣＭ＿ＩＤＬＥ状態に移行する。Ｓ１リリース処理において、ｅＮＢおよびＭＭＥは、ＵＥに対するシステムリソースをリリースする。
ステップＳＴ５１０１でＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを認識したＵＥは、ステップＳＴ７２１８において、アプリケーションに対してＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを通知する。ローカルリリースを受信したアプリケーションは、ＲＲＣ／ＥＣＭが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
ステップＳＴ５１３４において、Ｓ１リリース処理が行われ、ＥＰＳベアラがリリースされたことを認識したＳ−ＧＷは、ステップＳＴ７２１７において、ローカルAPP keep alive packetの生成を停止する。
ステップＳＴ７２１９において、Ｓ−ＧＷは、アプリケーションサーバに対してローカルアプリケーションセッションリリースメッセージを通知する。ローカルアプリケーションリリースメッセージを受信したアプリケーションサーバは、ＥＰＳベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。
本実施の形態で開示した方法によって、アプリケーションのセッションを接続状態に保ったまま、ＵＥは、ＲＲＣ＿ＩＤＬＥに遷移可能である。したがって、ＵＥとｅＮＢとの間でのＲＲＣ接続（RRC Connection）の維持が不要となり、不要な無線リソースの使用を削減することができる。
本実施の形態で開示し方法では、ＲＲＣ＿ＩＤＬＥ状態において、「uu keep alive packet」を送信する必要があるので、その無線リソースを使用することとなる。したがって、運用状況に応じて、他の実施の形態を含めた方法の中から適切に選択するとよい。
実施の形態４ 変形例１．
実施の形態４の変形例１で解決する課題は、前述の実施の形態４における課題と同一であり、以下に説明する。実施の形態４においても、ＲＲＣデータモニタタイマの満了によって、ＲＲＣ接続リリース処理が行われるまでは、ＲＲＣ接続（RRC Connection）の状態を用いるので、前述の実施の形態２において挙げた、ＵＥとｅＮＢとの間での状態不一致の課題が発生し得る。また、ＩＤＬＥ時の「uu keep alive packet」による情報とＲＲＣ状態の２つ情報から、アプリケーションレベルのセッション状態の判定を行うので、実装が煩雑になる。
実施の形態４の変形例１における前記課題を解決するために、前述の実施の形態２の対策案を実施の形態４において適用する。なお、前述の実施の形態２と同様に、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態における「Uu keep alive indication」の送信によって、ＤＲＸ長を変更すべきではない。また、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態における「Uu keep alive indication」の送信とＲＲＣデータモニタタイマとは、独立に運用される。すなわち、ＵＥは、ＲＲＣ接続状態がどの状態であっても、「Uu keep alive indication」または「Uu keep alive packet」を通知することによって、アプリケーションセッションが接続している状態であることをｅＮＢに通知する。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の場合は、「Uu keep alive indication」が用いられ、ＲＲＣ＿ＩＤＬＥ状態の場合は、「Uu keep alive packet」が用いられる。「Uu keep alive indication」と「Uu keep alive packet」とを同じ名称のメッセージ、例えば「Uu keep alive」として、ＲＲＣ接続状態によらず使用可能としてもよい。
図４０および図４１は、実施の形態４の変形例１における通信システムのシーケンスの一例を示す図である。図４０と図４１とは、境界線ＢＬ１２の位置で、つながっている。図４０および図４１に示すシーケンスは、図３８および図３９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ＵＥとｅＮＢとは、ステップＳＴ７２０１のサービス要求処理Ｂ（Service Request Procedure B）において、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態およびＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。
ステップＳＴ５１３０において、ＵＥとアプリケーションサーバとの間で、エンドツーエンド（End to End）のサービスが実行され、アプリケーションデータがＵＥからアプリケーションサーバに通信される。
ＵＥは、アプリケーションセッションの接続を保つために、ステップＳＴ７５０１において、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態における「Uu keep alive indication」をｅＮＢに送信し、アプリケーションセッションが接続している状態であること通知する。
アプリケーションセッションが接続している状態であることを通知するために、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のＵＥは、継続して周期的に「Uu keep alive indication」をｅＮＢに送信する。ｅＮＢは、該通知を受信することによって、アプリケーションセッションが接続している状態であることを認識する。
したがって、ｅＮＢが該通知を受信している間は、Ｓ１リリース処理など、Ｓ１ベアラおよびＥＰＳベアラのリリース処理を行わない。Ｓ１リリース処理が行われないので、Ｓ−ＧＷは、ローカルkeep alive packetを生成し、アプリケーションサーバに対して通知する。これによって、アプリケーションサーバは、ＵＥとの接続を認識することができ、セッションを接続状態に保つことができる。
一方、ｅＮＢは、所定の期間に、ＵＥへのデータの発生の有無をモニタする。または、ＵＥとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。所定の期間を計測する手段として、タイマを設けてもよい。以下、このタイマを「ＲＲＣデータモニタタイマ」と称する。
ｅＮＢは、ステップＳＴ７５０５において、ＵＥへのデータが発生せず、ＲＲＣデータモニタタイマが満了した場合、ステップＳＴ７５０６において、ＲＲＣ接続のリリース処理を起動する。この処理によって、ｅＮＢとＵＥとの間の無線ベアラはリリースされ、ＵＥとｅＮＢとは、ステップＳＴ７４０４およびステップＳＴ７４０５において、ＲＲＣ＿ＩＤＬＥ状態に移行する。
前述の処理では、ＵＥとｅＮＢとの間のＲＲＣ接続状態のみを、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態からＲＲＣ＿ＩＤＬＥ状態に移行させる。このようにすることによって、ＵＥとｅＮＢとは、ＲＲＣ接続のための無線リソースをリリースできる。
ＵＥは、ｅＮＢからのＲＲＣ接続リリースメッセージに従って、ＲＲＣ＿ＩＤＬＥ状態に移行することを開示したが、他の方法として、ＵＥにおいてもｅＮＢへのデータの発生の有無をモニタしてもよい。またはｅＮＢとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。ステップＳＴ７４０４において、データの発生が無く、ＵＥ側のＲＲＣデータモニタタイマが満了した場合、ＲＲＣ接続のリリース処理を起動し、ＲＲＣ＿ＩＤＬＥ状態に移行する。また、他の方法として、ＵＥは、ＲＲＣの規定に従い、ＲＲＣ＿ＩＤＬＥ状態に移行してもよい。ＲＲＣの規定としては、例えば、ＲＬＦ（Rsdio Link Failure）などがある。
ＲＲＣ＿ＩＤＬＥ状態に移行したＵＥは、アプリケーションセッションの接続を保つために、ステップＳＴ７４０６において、ＲＲＣ＿ＩＤＬＥ状態における「Uu keep alive packet」をｅＮＢに送信し、アプリケーションセッションが接続している状態であること通知する。アプリケーションセッションが接続している状態であること通知するために、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のＵＥは、継続して周期的に「Uu keep alive indication」をｅＮＢに送信する。ｅＮＢは、該通知を受信することによって、アプリケーションセッションが接続している状態であることを認識する。
したがって、ｅＮＢが該通知を受信している間は、Ｓ１リリース処理など、Ｓ１ベアラおよびＥＰＳベアラのリリース処理を行わない。Ｓ１リリース処理が行われないので、Ｓ−ＧＷは、ローカルkeep alive packetを生成し、アプリケーションサーバに対して通知する。これによって、アプリケーションサーバは、ＵＥとの接続を認識することができ、セッションを接続状態に保つことができる。
ステップＳＴ７４０９において、ｅＮＢが「keep alive packet」の未達を確認した場合の処理は、前述の実施の形態４を適用することができるので、ここでは説明を省略する。
本実施の形態で開示した方法によって、ＵＥとｅＮＢとの間での状態不一致が軽減されるので、システムリソースに対する影響を軽減することができる。また、ｅＮＢが、アプリケーションレベルのセッション状態の判定を、アプリケーションセッションが接続している状態であることを通知するメッセージ、具体的にはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の場合は「uu keep alive indication」、ＲＲＣ＿ＩＤＬＥ状態の場合は「uu keep alive packet」のみで判断できるので、実装が容易となる。
本実施の形態で開示し方法では、ＲＲＣ＿ＩＤＬＥ状態およびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態において、「uu keep alive indication」および「uu keep alive packet」を送信する必要があるので、その無線リソースを使用することとなる。したがって、運用状況に応じて、他の実施の形態を含めた方法の中から適切に選択するとよい。
実施の形態５．
実施の形態５で解決する課題は、前述の実施の形態３、実施の形態３の変形例１、実施の形態４および実施の形態４の変形例１における課題と同一であり、以下に説明する。
前述の実施の形態および変形例においては、定期的に送信されるｋｅｅｐ-ａｌｉｖｅパケットに起因する問題の対策として、Ｕｕ点のメッセージである「uu keep alive」を利用しているが、ＲＲＣ接続（RRC Connection）を維持するための無線リソースを使用することとなる。
本実施の形態では、前記課題を解決するために、Ｕｕ点のメッセージである「uu keep alive」の利用、およびＲＲＣ接続（RRC Connection）の維持を行わない方法を開示する。
ｅＮＢとＵＥとは、所定の期間にデータの発生の有無をモニタする。ｅＮＢとＵＥとは、所定の期間にデータの発生が無い場合は、アプリケーションレベルのセッションが切断されたと判断し、所定の期間内にデータの発生が有る場合は、セッションが接続されていると判断する、セッション接続判断機能を有する。
ｅＮＢは、何らかのネットワーク装置、例えばＳ−ＧＷに、セッション接続状態の情報を通知する。セッション接続状態の情報の通知を受けた前記ネットワーク装置であるＳ−ＧＷにおいて、ローカルAPP keep alive packetの送信制御を行う。
図４２および図４３は、実施の形態５における通信システムのシーケンスの一例を示す図である。図４２と図４３とは、境界線ＢＬ１３の位置で、つながっている。図４２および図４３に示すシーケンスは、図３８および図３９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ５１３０のデータ送信が行われた後、ＵＥに対するＲＲＣ接続（RRC connection）がＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるｅＮＢは、ＵＥへのデータの発生の有無をモニタする。前述の実施の形態４で開示したように、所定の期間にＵＥへのデータが発生せず、ＲＲＣデータモニタタイマが満了した場合、ステップＳＴ７４０４およびステップＳＴ７４０５において、ｅＮＢとＵＥとは、ＲＲＣ＿ＩＤＬＥ状態に移行する。
前述の処理では、ＵＥとｅＮＢとの間のＲＲＣ接続状態のみを、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態からＲＲＣ＿ＩＤＬＥ状態に移行させる。このようにすることによって、ＵＥとｅＮＢとは、ＲＲＣ接続のための無線リソースをリリースできる。
本実施の形態では、前述の実施の形態４とは異なり、ＲＲＣ＿ＩＤＬＥ状態に遷移したＵＥは、セッション接続通知用のＵｕ点のメッセージである「uu keep alive」をｅＮＢに送信しない。
本実施の形態では、ＵＥとｅＮＢとが、所定の期間にデータの発生の有無をモニタする。ｅＮＢとＵＥとは、所定の期間にデータの発生が無い場合は、アプリケーションレベルのセッションが切断されたと判断し、所定の期間内にデータの発生が有る場合は、セッションが接続されていると判断する、セッション接続判断機能を有する。
ｅＮＢとＵＥとは、所定の期間にデータの発生の有無をモニタするようにしているが、ＵＥに対するＳ１ベアラが必要か否かをモニタするようにしてもよい。また、ＵＥに対するＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態が必要か否かをモニタするようにしてもよい。所定の期間を計測する手段として、タイマを設けてもよい。以下、このタイマを「ＮＡＳデータモニタタイマ」と称する。ＵＥは、セッション接続機能をＮＡＳの機能として有するとよい。あるいは、ＡＳの機能として有してもよい。ＡＳの機能とする場合、ＮＡＳデータモニタの満了時、ＡＳからＮＡＳへその旨の通知を行うとよい。ｅＮＢは、セッション接続機能をＡＳの機能として有するようにするとよい。
ＵＥは、データの発生の有無をモニタし、ステップＳＴ７６０１においてＮＡＳデータモニタタイマが満了した場合、ステップＳＴ５１０１において、ＵＥは、ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行する。ステップＳＴ５１０１でＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを認識したＵＥは、ステップＳＴ７２１８において、アプリケーションに対してＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを通知する。
ローカルリリースを受信したアプリケーションは、ＲＲＣ／ＥＣＭが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
ｅＮＢは、データの発生の有無をモニタし、ステップＳＴ７６０２においてＮＡＳデータモニタタイマが満了した場合、ステップＳＴ５１３４のＳ１リリース処理Ａを起動する。
ステップＳＴ５１３４でＳ１リリース処理Ａが行われると、ステップＳＴ５１０２において、ｅＮＢは、ＵＥに対してＲＲＣ＿ＩＤＬＥ状態を維持する。ステップＳＴ５１０３において、ＭＭＥは、ＵＥに対してＥＣＭ＿ＩＤＬＥ状態に移行する。Ｓ１リリース処理において、ｅＮＢおよびＭＭＥは、ＵＥに対するシステムリソースをリリースする。
ステップＳＴ５１３４でＳ１リリース処理Ａが行われ、ＥＰＳベアラがリリースされたことを認識したＳ−ＧＷは、ステップＳＴ７２１７において、ローカルAPP keep alive packetの生成を停止する。
ステップＳＴ７２１９において、Ｓ−ＧＷは、アプリケーションサーバに対してローカルアプリケーションセッションリリースメッセージを通知する。ローカルアプリケーションリリースメッセージを受信したアプリケーションサーバは、ＥＰＳベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。
前述の方法では、ＵＥとｅＮＢとがセッション接続判断機能を有することを開示した。他の方法として、ＵＥはセッション接続判断機能を有しておらず、ｅＮＢがセッション接続判断機能を有するようにしてもよい。この場合、ｅＮＢがデータの発生の有無をモニタし、ＮＡＳデータモニタタイマが満了した場合、Ｓ１リリース処理を起動する。
Ｓ１リリース処理が行われることによって、ＵＥは、ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態に移行する。ＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを認識したＵＥは、アプリケーションに対してＲＲＣ／ＥＣＭ＿ＩＤＬＥ状態になったことを通知する。ローカルリリースを受信したアプリケーションは、ＲＲＣ／ＥＣＭが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
これによって、ＵＥ側でＮＡＳデータモニタを行う必要が無くなり、制御を簡易にすることができる。
本実施の形態で開示した方法によって、セッション接続通知用のＵｕ点のメッセージである「uu keep alive」の利用、およびＲＲＣ接続（RRC Connection）の維持を行わずに、セッション接続判断を行うことが可能となる。これによって、無線リソースの使用量を削減することが可能となる。また、ＲＲＣデータモニタタイマおよびＮＡＳデータモニタタイマなどのデータモニタタイマのみによって、ＲＲＣ接続状態の遷移、およびアプリケーションセッション接続状態の遷移を制御することができるので、実装が容易になる。
また、本実施の形態で開示した、ＮＡＳデータモニタタイマは、アプリケーションが持つセッションタイマと一致させるようにしてもよい。ＵＥは、セッションタイマをｅＮＢに通知しておけばよい。これによって、アプリケーションの接続制御時間と通信システム上の接続制御時間とを一致させることができ、システムの誤動作を低減することができる。ＮＡＳデータモニタタイマと、アプリケーションが持つセッションタイマとを一致させることは、変形例を含む他の実施の形態においても適用可能である。
また、本実施の形態で開示した方法は、頻繁に接続を行わないことが想定されＮＡＳデータモニタタイマの値を短く設定可能なアプリケーションに使用するなど、アプリケーションの特性を考慮して利用すると、より効果的である。
実施の形態６．
実施の形態６で解決する課題を以下に説明する。インスタントメッセージおよびＳＮＳ（Social Networking Service）などの常に起動されていて、定期的に比較的小さなサイズデータを送受信するようなアプリケーションについても、前述の実施の形態３と同様の問題が生じる。この場合は、実際に送信先となるサーバなどに情報を伝送する必要があり、前述の実施の形態３〜実施の形態５の解決策をそのまま利用することはできない。
例えば非特許文献１５および非特許文献１６には、ユーザデータに対して専用の無線アクセスベアラを開設することなく、ＮＡＳシグナリング用ベアラを用いて伝送を行うコンセプトが提案されている。本提案において、通信のエンドツーエンド（End to End）を、ＵＥとあるＰＤＮ（Public Data Network）におけるサーバとしたとき、そのＰＤＮに対応するＰ−ＧＷと対象のＵＥが在圏するＭＭＥとの間に、データ伝送用のセッションを設定し、データ伝送用の経路とＮＡＳシグナリング用ベアラとを用いて通信を行うこととしている。
非特許文献１５の図１（ａ）に、コンセプト図が示されている。また、図１（ａ）の構成における通信をコネクションライト（connection-lite）型通信とし、図１（ｂ）の構成における通信をコネクションオリエンテッド（connection-oriented）型通信としている。
非特許文献１６の図１において、非特許文献１５の図１（ａ）を適用して実行するときに設定するＰＤＮとの接続手順が開示されている。ここでは、ＵＥからのＰＤＮの接続要求に対し、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）のセッション確立を行っている。
なお、前述の非特許文献１５において、connection-liteとconnection-orientedとを併用することが示唆されている。非特許文献１５によれば、connection-liteにおいて送信すべきでない大きなデータを伝送したい場合は、通常の伝送パス（connection-oriented）で伝送することを示唆している。
しかしながら、その実現方法、例えばconnection-liteとconnection-orientedとの切替方法などは明示されていない。したがって、connection-liteとconnection-orientedとを切替えて用いることは不可能であり、安定した通信ステムの構築ができないという課題が発生する。
実施の形態６での解決策を以下に示す。本実施の形態では、connection-liteとconnection-orientedとの切替方法を開示する。ＵＥ、Ｐ−ＧＷ、あるいはＳ−ＧＷが、connection-liteで送信するか、またはconnection-orientedで送信するかを判断する。判断方法の具体例として、以下の（１）〜（３）の３つを開示する。
（１）データによって判断する。具体的には、データの大きさによって判断する。
（２）状態に応じて判断する。
（３）前記（１），（２）の組合せ。
なお、connection-liteとconnection-orientedとの切替えは、ＵＥがデータを送信する場合と、ＡＰＰサーバがデータを送信する場合とで同じであってもよいし、異なっていてもよい。異なる場合の具体例としては、ＵＥがデータを送信する場合は、connection-liteを用い、ＡＰＰサーバがデータを送信する場合は、connection-orientedを用いるなどである。
データによって判断する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）データ量が閾値よりも大きければ、connection-orientedで送信すると判断し、閾値以下であれば、connection-liteで送信すると判断する。
（２）トラフィック量が閾値よりも大きければ、connection-orientedで送信すると判断し、閾値以下であれば、onnection-liteで送信すると判断する。小さいトラフィックであるか否かを判断するとしてもよい。トラフィック量の具体例としては、ある単位時間あたりのデータ量である。非特許文献１６に開示されているように、データ量で判断する場合は、パケット単位にconnection-liteとconnection-orientedとの切替えが発生する可能性がある。他方、トラフック量で判断する場合は、単位時間の間はconnection-liteとconnection-orientedとの切替えが発生しないので、制御のオーバーヘッドが少なくなるという効果を得ることができる。
上記で開示した閾値は、ＵＥとＰ−ＧＷあるいはＳ−ＧＷとで、別の値にしてもよい。上りと下りとで、閾値を異なる値にしてもよい。Ｐ−ＧＷあるいはＳ−ＧＷ内の構成、およびＵＥ内の構成に対して、小さいデータとして扱うデータ量あるいはトラフィック量を最適にすることができる。上りと下りの負荷状況に応じて、小さいデータとして扱うデータ量あるいはトラフィック量を最適にすることができる。
以下、connection-orientedで送信すると判断されるデータを、通常サイズのデータ（Normal size data）と称することもある。また、connection-liteで送信すると判断されるデータを、小さいサイズのデータ、または小さいデータ（small data）と称することもある。
前記閾値、例えば、データ量の閾値およびトラフック量の閾値の決定方法の具体例として、以下の（１）〜（９）の９つを開示する。
（１）アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求する接続先に依存して決定されるとしてもよい。アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報などから、ＵＥのＮＡＳ、Ｐ−ＧＷ、あるいはＳ−ＧＷが閾値を決定してもよい。
（２）ｅＮＢとＭＭＥとの間の通信システムの状態によって、ｅＮＢ、ＭＭＥが決定するとしてもよい。Ｓ１インタフェースの通信システム状態としてもよい。通信システムの状態の具体例としては、静的に決定される最大伝送能力、負荷状況などがある。
（３）ＭＭＥとＳ−ＧＷとの間の通信システムの状態によって、ＭＭＥ、Ｓ−ＧＷが決定するとしてもよい。Ｓ１１インタフェースの通信システム状態としてもよい。通信システムの状態の具体例としては、静的に決定される最大伝送能力、負荷状況などがある。
（４）オペレータポリシーに依存して決定されるとしてもよい。小さいデータ送信ポリシーに依存して決定されるとしてもよい。小さいデータ送信ポリシーは、オペレータによって設定されてもよい。
（５）Ｓ−ＧＷとＰ−ＧＷとの間のインタフェースであるＳ５／Ｓ８インタフェースの通信システムの状態によって決定するとしてもよい。Ｐ−ＧＷ、あるいはＳ−ＧＷが決定するとしてもよい。
（６）ＯＡＭが決定してもよい。
（７）ＵＥの能力に応じて決定する。
（８）前記（１）〜（７）の組合せ。
（９）静的に決定する。
閾値の通知方法の具体例として、以下の（１）〜（８）の８つを開示する。
（１）通知しない。閾値の決定方法（１）を用いる場合、ＵＥと、Ｓ-ＧＷあるいはＰ−ＧＷとが、それぞれ同じアプリケーションに依存して閾値を決定すればよい。また、閾値の決定方法（５）を用いる場合も通知不要となる。通知方法（１）は、以下の通知方法（２）〜（４）と比較して、通信エラーを考慮する必要がない点、および制御負荷を減らせる点において有効である。
（２）ｅＮＢが決定した値をＵＥと、Ｓ−ＧＷあるいはＰ−ＧＷとに通知する。
（３）ＭＭＥが決定した値をＵＥと、Ｓ−ＧＷあるいはＰ−ＧＷとに通知する。
（４）Ｓ−ＧＷが決定した値をＵＥと、Ｐ−ＧＷとに通知する。ＴＦＴ（Traffic Flow Templates）を用いて通知してもよい。ＴＦＴを用いて小さいデータ送信ポリシーと閾値とを通知することによって、以下の効果を得ることができる。小さいデータ送信ポリシーと、connection-liteで送信する小さいデータか、connection-orientedで送信する通常サイズのデータであるかを判断する閾値とを、まとめて通知することができる。connection-liteを用いるか、connection-orientedを用いるかの判断に必要な「小さいデータ送信ポリシー」と「閾値」とを共に受信することができるので、処理が容易となる。
（５）Ｐ−ＧＷが決定した値をＵＥへ通知する。ＴＦＴ（Traffic Flow Templates）を用いて通知してもよい。ＴＦＴを用いて小さいデータ送信ポリシーと閾値とを通知することによって、以下の効果を得ることができる。小さいデータ送信ポリシーと、connection-liteで送信する小さいデータか、connection-orientedで送信する通常サイズのデータであるかを判断する閾値とを、まとめて通知することができる。connection-liteを用いるか、connection-orientedを用いるかの判断に必要な「小さいデータ送信ポリシー」と「閾値」とを共に受信することができるので、処理が容易となる。
（６）オペレータが決定した値をＰ−ＧＷあるいはＳ−ＧＷとＵＥに通知する。
（７）ＯＡＭが決定した値をＰ−ＧＷあるいはＳ−ＧＷとＵＥに通知する。
（８）小さいデータ送信ポリシーを、ネットワーク側エンティティズとＵＥとの間で交換する際に付随して閾値を交換する。connection-liteを用いるか、connection-orientedを用いるかの判断に必要な「小さいデータ送信ポリシー」と「閾値」とを共に受信することができるので、処理が容易となる。
状態に応じて判断する方法の具体例について以下に開示する。対象となるＵＥとのＥＣＭ接続状態およびＲＲＣ接続状態で、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断する。ＥＰＳベアラ（EPS bearer）が設立されていたとしても、ＥＣＭ＿ＩＤＬＥ状態およびＲＲＣ＿ＩＤＬＥ状態の場合がある。したがって、対象となるＵＥとのＥＣＭ接続状態およびＲＲＣ接続状態を切替えの判断基準とする方法は、ＥＰＳベアラの設立有無を切替えの判断基準とする方法と比較して、ベアラ接続に多くのシグナリングが必要となることを防ぐことができる。
以下に、具体例を説明する。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤかつＲＲＣ＿ＣＯＮＮＥＣＴＥＤの場合は、connection-orientedで通信を行うようにするとよい。発生するデータの量あるいはトラフィックの量にかかわらず、connection-orientedで通信を行うとよい。小さいデータ（small data）が発生したとしても、connection-orientedで通信が行われる。
ＥＣＭ＿ＩＤＬＥまたはＲＲＣ＿ＩＤＬＥの場合は、小さいデータが発生した場合はconnection-liteで通信を行い、通常のデータが発生した場合はconnection-orientedで通信を行うようにするとよい。ＥＰＳベアラが設立されていたとしても、ＥＣＭ＿ＩＤＬＥの場合、Ｓ1−ＵまたはＲＲＣが接続状態にあるとは限らない。したがって、小さいデータが発生した場合にconnection-liteで通信を行うことで、Ｕ−ｐｌａｎｅの接続に必要となるシグナリングを削減することが可能となる。また、ＲＲＣ＿ＩＤＬＥの場合のconnection-liteでの通信は、ＲＲＣ＿ＣＯＮＮＥＸＴＥＤ状態に移行しないで行うようにしてもよい。これによって、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）を起動しなくてすむ。具体的な方法としては、例えば、ＲＡＣＨ処理を用いて小さいデータを送信する、あるいは、ページング処理で小さいデータを送信するなどがある。ＲＡＣＨ処理を用いて小さいデータを送信する方法は、前述の実施の形態１の変形例４と同様であるので、説明を省略する。ページング処理を用いて小さいデータを送信する方法は、前述の実施の形態１の変形例５と同様であるので、説明を省略する。
以上に開示した判断基準を、小さいデータ送信ポリシーに加えておき、ＵＥおよびＳ−ＧＷあるいはＰ−ＧＷで有するようにしてもよい。小さいデータ送信ポリシーとは別に、データ（data）送信ポリシーとして、ＵＥおよびＳ−ＧＷあるいはＰ−ＧＷで有するようにしてもよい。
なお、前記では、対象となるＵＥとのＥＣＭ接続状態およびＲＲＣ接続状態で、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断することを開示したが、これに限らず、対象となるＵＥとのＳ1−Ｕベアラの設立状態および無線ベアラの設立状態で、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断してもよい。ＥＣＭ接続状態をＳ1−Ｕベアラの設立状態に置き換え、ＲＲＣ接続状態を無線ベアラの設立状態に置き換えればよい。
ＵＥがデータを送信する場合（ＭＯとも称される）については、ＵＥがconnection-liteで通信を行うか、connection-orientedで通信を行うか判断する。したがってＵＥは、ＲＲＣ状態あるいはＥＣＭ状態を認識しておく必要がある。
ＵＥは、ＲＲＣ状態を認識している。従来、ＲＲＣ状態とＥＣＭ状態とは一致するので、ＵＥはＥＣＭ状態も認識することができる。しかし、実施の形態４、実施の形態５、あるいは後述の実施の形態７で開示するように、ＲＲＣ状態とＥＣＭ状態とが異なる場合がある。このような場合、ＵＥはＥＣＭ状態を認識できない。
この問題は、以下の方法によって解決することができる。ＲＲＣ状態とＥＣＭ状態とが異なる場合は、ＭＭＥあるいはｅＮＢから、ＵＥに対してＥＣＭ状態を示す情報を通知するようにしてもよい。
ＡＰＰサーバがデータを送信する場合（ＭＴとも称される）については、Ｐ−ＧＷあるいはＳ−ＧＷがconnection-liteで通信を行うか、connection-orientedで通信を行うかを判断する。したがって、Ｐ−ＧＷあるいはＳ−ＧＷは、ＲＲＣ状態あるいはＥＣＭ状態を認識しておく必要がある。
Ｓ−ＧＷは、ＥＣＭ状態を認識している。従来、ＲＲＣ状態とＥＣＭ状態とは一致するので、Ｓ−ＧＷは、ＲＲＣ状態も認識することができる。しかし、実施の形態４、実施の形態５、あるいは後述の実施の形態７で開示するように、ＲＲＣ状態とＥＣＭ状態とが異なる場合がある。このような場合、Ｓ−ＧＷは、ＲＲＣ状態を認識できない。
この問題は、以下の方法によって解決することができる。ＲＲＣ状態とＥＣＭ状態とが異なる場合は、ｅＮＢからＳ−ＧＷに対して、ＲＲＣ状態を示す情報を通知するようにしてもよい。また、ＵＥからＳ−ＧＷに対して、ＲＲＣ状態を示す情報を通知するようにしてもよい。
また、Ｐ−ＧＷは、ＲＲＣ状態およびＥＣＭ状態を認識しているとは限らない。ＭＭＥからＰ−ＧＷに対して、ＥＣＭ状態を示す情報を通知するようにしてもよい。また、Ｓ−ＧＷからＰ−ＧＷに対して、ＥＣＭ状態を示す情報を通知するようにしてもよい。ｅＮＢからＰ−ＧＷに対して、ＲＲＣ状態を示す情報を通知するようにしてもよい。また、ＵＥからＰ−ＧＷに対して、ＲＲＣ状態を示す情報を通知するようにしてもよい。
このようにすることによって、ＭＯにおいてはＵＥが、ＭＴにおいては、Ｐ−ＧＷあるいはＳ−ＧＷが、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断することができる。
connection-liteからconnection-orientedへの切替方法について、以下に開示する。Coonection-liteの状態で、ＵＥがconnection-orientedで送信すると判断した場合、ＵＥは、サービス要求処理（Service Request Procedure）を起動する。通常の発呼処理と同様となるので、通信システムが複雑化することを回避することができるという効果を得ることができる。
Coonection-liteの状態で、Ｐ−ＧＷおよびＳ−ＧＷなどのネットワーク側がconnection-orientedで送信すると判断した場合、Ｐ−ＧＷは、個別ベアラアクティブ化処理（Dedicated Bearer Activation Procedure）を起動する（非特許文献１３ ５．４．１章参照）。通常の着呼処理と同様となるので、通信システムが複雑化することを回避することができるという効果を得ることができる。
connection-liteからconnection-orientedへの切替えが発生した場合、Ｓ1−ＭＭＥおよびＳ１１上で小さいデータを送信する機能および設定をディアクティブにしなくてもよい。例えば、ＮＡＳメッセージに、小さいデータを含める機能および設定、ＧＴＰ−Ｃに小さいデータを含める機能および設定などをディアクティブにしなくてもよい。別途、シグナリング、または再度connection-liteへの切替えが発生した場合に、再設定が不要となり、通信システムとしての処理の負荷を軽減することができるという効果を得ることができる。
次に、図４４〜図４７を用いて、実施の形態６における通信システムのシーケンスの具体例について説明する。図４４〜図４７は、実施の形態６における通信システムのシーケンスの一例を示す図である。図４４と図４５とは、境界線ＢＬ１４の位置で、つながっている。図４５と図４６とは、境界線ＢＬ１５の位置で、つながっている。図４６と図４７とは、境界線ＢＬ１６の位置で、つながっている。図４４〜図４７では、connection-lite状態において、ＵＥ側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスを示している。
まず、図４４および図４５のステップＳＴ９１０１〜ステップＳＴ９１２２に、非特許文献１６に開示された、connection-liteを実行する際に設定するＰＤＮ接続手順を示す。
ステップＳＴ９１０１において、ＵＥのアプリケーション、あるいはＴＰＣ／ＩＰが、ＮＡＳへアクセス要求（Access Request）を行う。
ステップＳＴ９１０２において、ＵＥのＮＡＳは、ＰＤＮ設立処理（PDN Establishment Procedure）を起動する。ステップＳＴ９１０２のＰＤＮ設立処理は、ステップＳＴ９１０３〜ステップＳＴ９１２１の処理を含む。
ステップＳＴ９１０３において、ＵＥのＮＡＳは、ＡＳ（Access Stratum）にＰＤＮ接続要求（PDN Connectivity Request）メッセージを送信する。ＵＥのＮＡＳが、ＲＲＣレイヤに通知してもよい。
ステップＳＴ９１０４において、ＵＥのＲＲＣレイヤは、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）を起動する。ステップＳＴ９１０４のＲＲＣ接続セットアップ処理は、ステップＳＴ９１０５〜ステップＳＴ９１０７の処理を含む。
ステップＳＴ９１０５において、ＵＥのＲＲＣレイヤは、ｅＮＢにＲＲＣ接続セットアップ要求（RRC Connection Setup Request）メッセージを送信する。
ステップＳＴ９１０５でＲＲＣ接続セットアップ要求メッセージを受信したｅＮＢは、ステップＳＴ９１０６において、ＵＥのＲＲＣレイヤにＲＲＣ接続セットアップ（RRC Connection Setup）メッセージを送信する。
ステップＳＴ９１０６でＲＲＣ接続セットアップメッセージを受信したＵＥは、ステップＳＴ９１０７において、ｅＮＢにＲＲＣ接続セットアップ完了（RRC Connection Setup Complete）メッセージを送信する。
ステップＳＴ９１０８において、ＵＥのＲＲＣレイヤは、ｅＮＢにＰＤＮ接続要求（PDN Connectivity Request）メッセージを送信する。
ステップＳＴ９１０８でＰＤＮ接続要求メッセージを受信したｅＮＢは、ステップＳＴ９１０９において、ＭＭＥにＰＤＮ接続要求メッセージを送信する。
ステップＳＴ９１１０において、ＭＭＥは、Ｓ−ＧＷにセッション生成要求（Create Session Request）メッセージを送信する。
ステップＳＴ９１１０でセッション生成要求メッセージを受信したＳ−ＧＷは、ステップＳＴ９１１１において、Ｐ−ＧＷにセッション生成要求メッセージを送信する。
ステップＳＴ９１１２において、Ｐ−ＧＷは、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）のセッション確立（IP-CAN Session Establishment）を実行する。
ステップＳＴ９１１２でＩＰ−ＣＡＮのセッション確立が完了した場合、ステップＳＴ９１１３において、Ｐ−ＧＷは、セッション生成応答（Create Session Response）メッセージをＳ−ＧＷに送信する。
ステップＳＴ９１１３でセッション生成応答メッセージを受信したＳ−ＧＷは、ステップＳＴ９１１４において、ＭＭＥにセッション生成応答メッセージを送信する。
ステップＳＴ９１１５において、ＭＭＥは、デフォルトベアラコンテキスト要求アクティブ化（Activate Default Bearer Context Request）メッセージをｅＮＢに送信する。
ステップＳＴ９１１５でデフォルトベアラコンテキスト要求アクティブ化メッセージを受信したｅＮＢは、ステップＳＴ９１１６において、ＵＥにデフォルトベアラコンテキスト要求アクティブ化メッセージを送信する。
ステップＳＴ９１１６でデフォルトベアラコンテキスト要求アクティブ化メッセージを受信したＵＥは、ステップＳＴ９１１７において、ｅＮＢにデフォルトベアラコンテキスト応答アクティブ化（Activate Default Bearer Context Response）メッセージを送信する。
ステップＳＴ９１１７でデフォルトベアラコンテキスト応答アクティブ化メッセージを受信したｅＮＢは、ステップＳＴ９１１８において、ＭＭＥにデフォルトベアラコンテキスト応答アクティブ化メッセージを送信する。
そして、前述のＰＤＮ接続手順を用いて、小さいデータ（small data）送信ポリシーをネットワーク側エンティティズとＵＥとの間で交換する。これによって、小さいデータ送信時に、ＵＥとアプリケーションサーバとの間で、ｅＮＢ、ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷを介した小さいデータの送信が可能となる。
ステップＳＴ９１１９において、ＭＭＥとＳ−ＧＷとの間に、Ｓ１１ベアラ（S11 Bearer）を設立する。ＭＭＥとＳ−ＧＷとの間のＳ１１上で、小さいデータの送信が可能となる（Ｓ１１（ｓｍｌ））。
ステップＳＴ９１２０において、Ｓ−ＧＷとＰ−ＧＷとの間に、Ｓ５／Ｓ８ベアラ（S5/S8 Bearer）を設立する。Ｓ−ＧＷとＰ−ＧＷとの間のＳ５／Ｓ８上で、小さいデータの送信が可能となる（Ｓ５／Ｓ８（ｓｍｌ））。
ステップＳＴ９１２１において、ｅＮＢとＭＭＥとの間に、Ｓ１ベアラ（S1 Bearer）を設立する。ｅＮＢとＭＭＥとの間のＳ１上で、小さいデータの送信が可能となる（Ｓ１(ｓｍｌ））。
これによって、ステップＳＴ９１２２において、ＵＥから、ｅＮＢとＭＭＥとＳ−ＧＷとＰ−ＧＷとを経由して、アプリケーションサーバ（APP Server）にデータを送信することが可能となる。
以下、このような状態を「connection-lite状態」と称することもある。小さいデータが送信可能となようにとしてもよい。
図４６のステップＳＴ９１２３において、ＵＥのアプリケーションから、ＮＡＳに通常サイズのデータの送信が要求され、送信データが送信される。
ステップＳＴ９１２３で通常サイズのデータを受信したＵＥのＮＡＳは、ステップＳＴ９１２４において、connection-liteで送信するか、connection-orientedで送信するかを判断する。図示は省略しているが、前述の状態に応じての判断を実行するようにしてもよい。具体的には、送信データが小さいデータであるか否かを判断する。ステップＳＴ９１２４において、小さいデータであると判断された場合は、connection-liteで送信すると判断し、ステップＳＴ９１２５に移行する。ステップＳＴ９１２４において、小さいデータでないと判断された場合は、connection-orientedで送信すると判断し、ステップＳＴ９１２６に移行する。
ステップＳＴ９１２５において、ＵＥのＮＡＳは、送信データをconnection-lite状態で送信する。小さいデータ用に開設されているベアラ、connection-liteで設立が完了しているベアラ（以下「Connection lite bearer」と称することもある）を用いて送信するようにしてもよい。
ステップＳＴ９１２６において、ＵＥのＮＡＳは、connection-orientedでの送信準備を開始する。具体例としては、サービス要求処理Ｃ（Service Request Procedure C）を起動する。
ステップＳＴ９１２６のサービス要求処理Ｃは、ステップＳＴ９１２７〜ステップＳＴ９１４７の処理を含む。
ステップＳＴ９１２７において、ＵＥのＮＡＳは、ＡＳにサービス要求（Service Request）メッセージを送信する。ＵＥのＮＡＳがＲＲＣレイヤに通知してもよい。
ステップＳＴ９１２７でサービス要求メッセージを受信したＵＥは、ステップＳＴ９１２８において、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）を起動する。ＲＲＣ接続セットアップ処理の詳細は、図４４のステップＳＴ９１０４の処理と同様であるので、説明を省略する。
ステップＳＴ９１３２において、ＵＥのＲＲＣレイヤは、ｅＮＢにサービス要求（Service Request）メッセージを送信する。
ステップＳＴ９１３２でサービス要求メッセージを受信したｅＮＢは、ステップＳＴ９１３３において、ＭＭＥにサービス要求（Service Request）メッセージを送信する。
ステップＳＴ９１３３でサービス要求メッセージを受信したＭＭＥは、図４７のステップＳＴ９１３４において、ｅＮＢに初期コンテキストセットアップ要求（Initial Context Setup Request）メッセージを送信する。
ステップＳＴ９１３４で初期コンテキストセットアップ要求メッセージを受信したｅＮＢは、ステップＳＴ９１３５において、無線ベアラ設立処理（Radio Bearer Establishment Procedure）を起動する。
ステップＳＴ９１３５の無線ベアラ設立処理は、ステップＳＴ９１３６〜ステップＳＴ９１３７の処理を含む。
ステップＳＴ９１３６において、ｅＮＢは、ＵＥにＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージを送信する。
ステップＳＴ９１３６でＲＲＣ接続再設定メッセージを受信したＵＥは、ステップＳＴ９１３７において、ｅＮＢにＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）メッセージを送信する。
ステップＳＴ９１３７でＲＲＣ接続再設定完了メッセージを受信したｅＮＢは、ステップＳＴ９１３８において、ＭＭＥに初期コンテキストセットアップ完了（Initial Context Setup Complete）メッセージを送信する。
ステップＳＴ９１３９において、ＭＭＥは、ベアラ修正要求（Modify Bearer Request）メッセージをＳ−ＧＷに送信する。
ステップＳＴ９１３９でベアラ修正要求メッセージを受信したＳ−ＧＷは、ステップＳＴ９１４１において、Ｐ−ＧＷにベアラ修正要求（Modify Bearer Request）メッセージを送信する。
ステップＳＴ９１４２において、Ｐ−ＧＷは、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）のセッション変更（IP-CAN Session Modification）を実行する。ＩＰ−ＣＡＮのセッション変更を、「PCEF initiated IP-CAN Session Modification」と称することもある。
ステップＳＴ９１４２でＩＰ−ＣＡＮのセッション変更が完了した場合、ステップＳＴ９１４３において、Ｐ−ＧＷは、ベアラ修正応答（Modify Bearer Response）メッセージをＳ−ＧＷに送信する。
ステップＳＴ９１４３でベアラ修正応答メッセージを受信したＳ−ＧＷは、ステップＳＴ９１４４において、ＭＭＥにベアラ修正応答（Modify Bearer Response）メッセージを送信する。
ステップＳＴ９１４５において、ｅＮＢとＳ−ＧＷとの間に、Ｓ１ベアラ（S1 Bearer）を設立する。
ステップＳＴ９１４６において、Ｓ−ＧＷとＰ−ＧＷとの間に、Ｓ５／Ｓ８ベアラ（S5/S8 Bearer）を設立する。
ステップＳＴ９１４７において、ＵＥとＰ−ＧＷとの間に、ＥＰＳベアラ（EPS Bearer）を設立する。
これによって、ステップＳＴ９１４８において、ＵＥから、ｅＮＢとＳ−ＧＷとＰ−ＧＷとを経由して、アプリケーションサーバ（APP Server）へのデータの送信が可能となる。以下、このような状態をconnection-oriented状態と称することもある。通常サイズデータが送信可能となるようにしてもよい。
次に、図４８および図４９を用いて、実施の形態６における通信システムのシーケンスの具体例について説明する。図４８および図４９は、実施の形態６における通信システムのシーケンスの他の例を示す図である。図４８と図４９とは、境界線ＢＬ１７の位置で、つながっている。図４８および図４９に示すシーケンスは、図４４〜図４７に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図４８および図４９では、connection-lite状態において、ネットワーク（ＮＷ）側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスを示している。
ステップＳＴ９２０１において、アプリケーションサーバから、Ｐ−ＧＷに通常サイズのデータの送信が要求され、送信データが送信される。
ステップＳＴ９２０１で通常サイズのデータを受信したＰ−ＧＷは、ステップＳＴ９２０２において、connection-liteで送信するか、connection-orientedで送信するかを判断する。具体的には、送信データが小さいデータであるか否かを判断する。図示は省略しているが、前述の状態に応じての判断を実行するようにしてもよい。ステップＳＴ９２０２において、小さいデータであると判断された場合は、connection-liteで送信すると判断し、ステップＳＴ９２０３に移行する。ステップＳＴ９２０２において、小さいデータでないと判断された場合は、connection-orientedで送信すると判断し、ステップＳＴ９２０４に移行する。
ステップＳＴ９２０３において、Ｐ−ＧＷは、送信データをconnection-lite状態で送信する。コネクションライトベアラ（connection lite bearer）を用いて送信するようにしてもよい。
ステップＳＴ９２０４において、Ｐ−ＧＷは、connection-orientedでの送信準備を開始する。具体例としては、個別ベアラアクティブ化処理（Dedicated Bearer Activation Procedure）を起動する。
ステップＳＴ９２０４の個別ベアラアクティブ化処理は、ステップＳＴ９２０５〜ステップＳＴ９１４６の処理を含む。
ステップＳＴ９２０５において、Ｐ−ＧＷは、Ｓ−ＧＷにベアラ生成要求（Create Bearer Request）メッセージを送信する。
ステップＳＴ９２０５でベアラ生成要求メッセージを受信したＳ−ＧＷは、ステップＳＴ９２０６において、ＭＭＥにベアラ生成要求メッセージを送信する。
ステップＳＴ９２０６でベアラ生成要求メッセージを受信したＭＭＥは、ステップＳＴ９１３５において、無線ベアラ設立処理（Radio Bearer Establishment Procedure）を起動する。
ステップＳＴ９２０８において、ｅＮＢは、ベアラセットアップ応答（Bearer Setup Response）メッセージをＭＭＥに送信する。
ステップＳＴ９２０９において、ＵＥは、「Direct Transfer」をｅＮＢに送信する。あるいはセッション管理応答（Session Management Response）メッセージを送信するようにしてもよい。
ステップＳＴ９２０９でセッション管理応答メッセージを受信したｅＮＢは、ステップＳＴ９２１０において、ＭＭＥにセッション管理応答メッセージを送信する。
ステップＳＴ９２１０でセッション管理応答メッセージを受信したＭＭＥは、ステップＳＴ９２１１において、Ｓ−ＧＷにベアラ生成応答（Create Bearer Response）メッセージを送信する。
ステップＳＴ９２１１でベアラ生成応答メッセージを受信したＳ−ＧＷは、ステップＳＴ９２１２において、Ｐ−ＧＷにベアラ生成応答メッセージを送信する。
以上の実施の形態６によって、以下の効果を得ることができる。connection-liteとconnection-orientedとの併用を実現することが可能となる。実現方法が決定することによって、安定した通信ステムの構築が可能となる。
実施の形態６ 変形例１．
実施の形態６の変形例１で解決する課題を以下に説明する。前述の実施の形態６を実行した場合、以下の課題が発生する。
例えば、図４４〜図４７に示すシーケンスを実行した場合、同じアプリケーションサーバへの接続であるにも関わらず、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）のセッションの確立を、例えば図４５のステップＳＴ９１１２と図４７のステップＳＴ９１４２とで、二重に設定することとなる。このことは、場合によっては、同一のアプリケーションのセッションに対し、不要な手続きを実行することとなる。また、場合によっては、ＰＤＮ側が不正要求として接続を許可しない可能性もあるので、問題となる。
加えて、connection-lite状態において、ＵＥとＮＷとの双方から、通常サイズのデータを送信する場合、以下の問題が発生する。
ＵＥからのサービス要求（Service Request）に基づいて、無線ベアラ設立処理（Radio Bearer Establishment Procedure）が起動され、Ｐ−ＧＷからのベアラ生成要求（Create Bearer Request）に基づいて、同じベアラであるにもかからず、再度、無線ベアラ（Radio Bearer）の設定がなされてしまう。
図５０および図５１を用いて、実施の形態６の変形例１の課題の具体例について説明する。図５０および図５１は、実施の形態６の変形例１で解決する課題を説明するためのシーケンスを示す図である。図５０と図５１とは、境界線ＢＬ１８の位置で、つながっている。図５０および図５１に示すシーケンスは、図４４〜図４７、図４８および図４９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
図５０および図５１では、同じ無線ベアラ（Radio Bearer）の設立のために、ステップＳＴ９１３５において、無線ベアラ設立処理（Radio Bearer Establishment Procedure）が重複して起動される。
実施の形態６の変形例１での解決策を以下に示す。既にコネクションライトベアラ（connection lite bearer）が存在する場合、あるいはconnection-orientedで設立が完了しているベアラ（以下「Connection oriented bearer」と称することもある）が存在する場合、Ｐ−ＧＷは、ＩＰ−ＣＡＮセッション（IP-CAN session）に関する手続きを実行しないものとする。または、はじめに設定したＰＤＮ接続要求（PDN Connectivity Request）によって、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）のセッションは維持し、Ｐ−ＧＷは、ＩＰ−ＣＡＮセッションに関する手続きを実行しないものとする。これによって、同一のアプリケーションのセッションに対し、不要な手続きを防ぐことができる。
次に、ＭＭＥが、ＵＥとＰ−ＧＷとの間において、connection-orientedで使用するベアラが開設手順中、変更手順中、または開設済みであるか否かの判断を行う。以下、この判断を「ベアラ開設有無判断」と称することもある。開設手順中、変更手順中または開設済みでなければ、connection-orientedで使用するベアラの開設手続きを起動する。あるいは、ＭＭＥは、ＲＲＣ／ＥＣＭ状態がＣＯＮＮＥＣＴＥＤかＩＤＬＥかの判断を行い、ＩＤＬＥであれば、connection-orientedで使用するベアラの開設手続きを起動する。開設手順中、変更手順中または開設済みであれば、connection-orientedで使用するベアラの開設手続きを起動しない。あるいは、ＭＭＥは、ＲＲＣ／ＥＣＭ状態がＣＯＮＮＥＣＴＥＤかＩＤＬＥかの判断を行い、ＣＯＮＮＥＣＴＥＤであれば、connection-orientedで使用するベアラの開設手続きを起動しない。これによって、重複したベアラの設定を回避することが可能となる。
ＵＥがデータを送信する場合について開示する。ＭＭＥは、サービス要求（Service Request）の受信によって、ベアラ開設有無判断を起動してもよい。
開設手順中または開設済みでなければ、connection-orientedで使用するベアラの開設手続きを起動する。具体例としては、通常のサービス要求処理（Service Request Procedure）に沿った処理を実行する。例えば、ＭＭＥは、ｅＮＢに初期コンテキストセットアップ要求（Initial Context Setup Request）メッセージを送信する。
開設手順中または開設済みであれば、その旨をＵＥに通知する。あるいは通知せずに、処理を終了してもよい。
ＡＰＰサーバがデータを送信する場合について開示する。Ｐ−ＧＷ、あるいはＳ−ＧＷは、アプリケーションサーバから、データの送信が要求され、送信データが送信された場合、既存ベアラの有無判断を起動する。
既存ベアラ有りと判断した場合、その旨をＭＭＥに通知する。既存ベアラ有りの場合のみ、ＭＭＥに通知するようにしてもよい。
通知方法としては、Ｐ−ＧＷからＭＭＥに通知する新たなメッセージを新設する。例えば、ベアラ変更要求（Bearer Change Request）メッセージなどである。あるいは、既存のベアラ生成要求（Create Bearer Request）メッセージに、既存ベアラ有りの旨を示す情報要素を追加してもよい。
ベアラ変更要求メッセージを受信したＭＭＥは、ベアラ開設有無判断を起動してもよい。
開設手順中または開設済みでなければ、connection-orientedで使用するベアラの開設手続きを起動する。具体例としては、ＭＭＥは、Ｐ−ＧＷに通常の個別ベアラアクティブ化処理（Dedicated Bearer Activation Procedure）の起動を要求する。要求方法の具体例としては、ベアラ生成応答（Create Bearer Response）、あるいはベアラ変更応答（Bearer Change Response）を新たに設ける、あるいはベアラ設定要求（Bearer Set Request）を新たに設けるなどがある。
ベアラ変更要求（Bearer Change Request）に対して、拒絶（Reject）信号を送信し、その理由として、開設手順中または開設済みで有る旨を通知してもよい。あるいは、ＭＭＥ自身が、eＮＢにベアラセットアップ要求／セッション管理要求（Bearer Setup Request/Session Management Request）を送信し、個別ベアラアクティブ化処理（Dedicated Bearer Activation Procedure）を起動してもよい。
開設手順中または開設済みであれば、その旨をＰ−ＧＷに通知する。通知方法の具体例としては、ベアラ修正要求（Modify Bearer Request）、あるいはベアラ変更応答（Bearer Change Response）などがある。
開設手順中または開設済みである旨を受信したＰ−ＧＷは、新たに開設されるベアラを用いて、下りデータをＵＥに送信する。
以上に開示した方法では、ＭＭＥがＵＥとＰ−ＧＷとの間において、connection-orientedで使用するベアラが開設手順中もしくは開設済みであるか否かの判断を行うようにした。
他の方法として、ＵＥ、あるいは、Ｐ−ＧＷあるいはＳ−ＧＷが、ＵＥとＰ−ＧＷとの間において、connection-orientedで使用するベアラが開設済みであるか否かの判断を行い、Ｐ−ＧＷあるいはＭＭＥに通知するようにしてもよい。
ＵＥがデータを送信する場合について開示する。ＵＥが、コネクションライトベアラ（connection lite bearer）、あるいはコネクションオリエンテッドベアラ（connection oriented bearer）が存在するか否かを判断する。以下、この判断を「既存ベアラの有無判断」と称することがある。ＵＥは、既存ベアラの有無判断の結果を、ネットワーク側に通知する。具体的には、ＵＥは、Ｐ−ＧＷあるいはＳ−ＧＷに通知する。
既存ベアラの有無判断の結果の通知内容の具体例として、以下の（１）〜（３）の３つを開示する。
（１）既存ベアラの有無。あるいは既存ベアラ有りの旨のみ。あるいは既存ベアラ無しの旨のみ。
（２）ＥＰＳベアラ変更の要否。あるいはＥＰＳベアラ変更が必要の旨のみ。あるいはＥＰＳベアラ変更が不要の旨のみ。既存ベアラが有る場合は、ＥＰＳベアラの変更は不要となり、既存ベアラが無い場合は、ＥＰＳベアラの変更は必要となる。
（３）ＩＰ−ＣＡＮセッションに関する手続の要否。あるいはＩＰ−ＣＡＮセッションに関する手続が必要の旨のみ。あるいはＩＰ−ＣＡＮセッションに関する手続が不要の旨のみ。既存ベアラが有る場合は、ＩＰ−ＣＡＮセッションに関する手続は不要となり、既存ベアラが無い場合は、ＩＰ−ＣＡＮセッションに関する手続は必要となる。
既存ベアラの有無判断の結果の通知方法の具体例を、以下に開示する。
ＵＥは、ＭＭＥ経由でＰ−ＧＷ、あるいはＳ−ＧＷに通知する。たとえば、ＵＥは、ＮＡＳシグナルを用いて、ＭＭＥに、既存ベアラの有無判断の結果を通知する。この場合の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＮＡＳシグナルを新設する。
（２）既存のＮＡＳシグナルを用いる。既存のシグナルに、既存ベアラの有無判断の情報要素を追加すればよい。既存のシグナルの具体例としては、サービス要求（Service Request）メッセージなどがある。
既存ベアラの有無判断の結果を受信したＭＭＥは、Ｓ−ＧＷ、Ｐ−ＧＷに、ＵＥから受信した既存ベアラの有無判断の結果を通知する。この場合の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにシグナルを新設する。
（２）既存のシグナルを用いる。既存のシグナルに、既存ベアラの有無判断の情報要素を追加すればよい。既存のシグナルの具体例としては、ベアラ修正要求（Modify Bearer Request）メッセージ、ベアラ削除要求（Delete Bearer Request）メッセージなどがある。
既存ベアラの有無判断の結果を受信したＳ−ＧＷ、あるいはＰ-ＧＷは、受信した既存ベアラの有無判断の結果に基づいて、ＩＰ−ＣＡＮセッションに関する手続きを実行するか否かを判断する。具体的には、以下の（１），（２）のように判断する。
（１）既存ベアラの有、あるいはＥＰＳベアラ変更不要、ＩＰ−ＣＡＮセッションに関する手続不要が通知された場合、ＩＰ−ＣＡＮセッションに関する手続が不要と判断する。ベアラ修正要求（Modify Bearer Request）などにおいて参照するダイナミックＰＣＣ（Dynamic PCC）によらず、Ｐ−ＧＷは、ＩＰ−ＣＡＮセッションに関する手続き不要と判断してもよい。
（２）既存ベアラの無、あるいはＥＰＳベアラ変更必要、ＩＰ−ＣＡＮセッションに関する手続必要が通知された場合、ＩＰ−ＣＡＮセッションに関する手続が必要と判断する。
ＡＰＰサーバがデータを送信する場合について開示する。この場合、Ｐ−ＧＷ、あるいはＳ−ＧＷが既存ベアラの有無判断を行う。その結果に基づいて、Ｓ−ＧＷ、あるいはＰ-ＧＷは、ＩＰ−ＣＡＮセッションに関する手続きを実行するか否かを判断する。具体的には、以下の（１），（２）のように判断する。
（１）既存ベアラの有りの場合、ＩＰ−ＣＡＮセッションに関する手続が不要と判断する。
（２）既存ベアラの無しの場合、ＩＰ−ＣＡＮセッションに関する手続が必要と判断する。具体例としては、通常の個別ベアラアクティブ化処理（Dedicated Bearer Activation Procedure）を起動する。
次に、図５２および図５３を用いて、実施の形態６の変形例１における通信システムのシーケンスの具体例について説明する。図５２および図５３は、実施の形態６の変形例１における通信システムのシーケンスの一例を示す図である。図５２と図５３とは、境界線ＢＬ１９の位置で、つながっている。図５２および図５３に示すシーケンスは、図４４〜図４７に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図５２および図５３では、connection-lite状態において、ＵＥ側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスについて示している。
ステップＳＴ９４０１において、ＵＥは、既存ベアラの有無判断を実行する。ＵＥのＮＡＳが判断してもよい。既存ベアラ無しと判断した場合、ＵＥは、通常のサービス要求処理（Service Request Procedure）を起動する。図５２および図５３では、通常のサービス要求処理の説明を省略し、「終了」と記載する。既存ベアラ有りと判断した場合、ＵＥは、ステップＳＴ９４０２に移行する。
ステップＳＴ９４０２において、ＵＥのＮＡＳは、ＡＳに既存ベアラの有無判断の情報要素が追加されたサービス要求（Service Request）を送信する。ＵＥのＮＡＳがＲＲＣレイヤに通知してもよい。
図５３のステップＳＴ９４０３において、ＵＥのＲＲＣレイヤは、ｅＮＢに既存ベアラの有無判断の情報要素が追加されたサービス要求（Service Request）メッセージを送信する。
ステップＳＴ９４０３で既存ベアラの有無判断の情報要素が追加されたサービス要求メッセージを受信したｅＮＢは、ステップＳＴ９４０４において、ＭＭＥに既存ベアラの有無判断の情報要素が追加されたサービス要求（Service Request）メッセージを送信する。
ステップＳＴ９４０４でサービス要求メッセージを受信したＭＭＥは、コネクションオリエンテッドベアラ（connection oriented bearer）が開設手順中または開設済みであるかを判断する。すなわち、ベアラ開設有無判断を実行する。ＭＭＥは、既存ベアラの有無判断の結果に基づいて既存ベアラ有りの旨の通知を受けたときに、ベアラ開設有無判断を実行するようにしてもよい。
開設手順中または開設済みの場合、処理を終了する。必要に応じて、ＭＭＥは、ｅＮＢ経由でＵＥに応答メッセージを送信してもよい。応答メッセージを受けたＵＥは、開設中ベアラのＲＲＣ接続（RRC connection）の設定を待ち、通常データの送信を行う。応答メッセージが存在しない場合においても、開設中、または開設されたベアラのＲＲＣ接続（RRC connection）の設定によって送信が可能となる。
開設手順中または開設済みでない場合は、ステップＳＴ９４１０に移行し、ＭＭＥは、ｅＮＢに初期コンテキストセットアップ要求（Initial Context Setup Request）メッセージを送信する。初期コンテキストセットアップ要求メッセージに、既存ベアラの有無判断の情報要素が追加されていてもよい。
ステップＳＴ９４１１において、ｅＮＢは、ＭＭＥに初期コンテキストセットアップ完了（Initial Context Setup Complete）メッセージを送信する。初期コンテキストセットアップ完了メッセージに、既存ベアラの有無判断の情報要素が追加されていてもよい。
ステップＳＴ９４０６において、ＭＭＥは、既存ベアラの有無判断の情報要素を追加したベアラ修正要求（Modify Bearer Request）をＳ−ＧＷに送信する。
ステップＳＴ９４０６で既存ベアラの有無判断の情報要素を追加したベアラ修正要求メッセージを受信したＳ−ＧＷは、ステップＳＴ９４０７において、Ｐ−ＧＷに、既存ベアラの有無判断の情報要素を追加したベアラ修正要求（Modify Bearer Request）メッセージを送信する。
ステップＳＴ９４０７で既存ベアラの有無判断の情報要素を追加したベアラ修正要求メッセージを受信したＰ−ＧＷは、ＩＰ−ＣＡＮセッションに関する手続きを実行しない。
ステップＳＴ９４０８において、Ｐ−ＧＷは、ベアラ修正応答（Modify bearer Response）をＳ−ＧＷに送信する。ＥＰＳベアラを変更していない旨、あるいはＩＰ−ＣＡＮセッションに関する手続きをしていない旨を併せて通知してもよい。
ステップＳＴ９４０８でベアラ修正応答メッセージを受信したＳ−ＧＷは、ステップＳＴ９４０９において、ＭＭＥにベアラ修正応答（Modify bearer Response）メッセージを送信する。
次に、図５４〜図５６を用いて、実施の形態６の変形例１における通信システムのシーケンスの具体例について説明する。図５４〜図５６は、実施の形態６の変形例１における通信システムのシーケンスの他の例を示す図である。図５４と図５５とは、境界線ＢＬ２０の位置で、つながっている。図５５と図５６とは、境界線ＢＬ２１の位置で、つながっている。図５４〜図５６に示すシーケンスは、図４４〜図４９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図５４〜図５６では、connection-lite状態において、ネットワーク（ＮＷ）側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスについて示している。
図５５のステップＳＴ９５０１において、Ｐ−ＧＷは、既存ベアラの有無判断を実行する。Ｐ−ＧＷは、既存ベアラ無しと判断した場合、ステップＳＴ９２０４に移行し、通常の個別ベアラアクティブ化処理（Dedicated Bearer Activation Procedure）を起動する。Ｐ−ＧＷは、既存ベアラ有りと判断した場合、ステップＳＴ９５０２に移行する。
ステップＳＴ９５０２において、Ｐ−ＧＷは、既存ベアラが有る旨をＭＭＥに通知する。具体的には、ベアラ変更要求（Bearer Change Request）メッセージをＭＭＥに通知する。
ステップＳＴ９５０２で既存ベアラが有る旨を受信したＭＭＥは、ステップＳＴ９４０５において、コネクションオリエンテッドベアラ（connection oriented bearer）が開設手順中または開設済みであるかを判断する。すなわち、ベアラ開設有無判断を実行する。
開設手順中または開設済みの場合、ステップＳＴ９５０１に移行し、ＭＭＥは、Ｐ−ＧＷにその旨を通知する。
開設手順中または開設済みでない場合は、ステップＳＴ９５０４に移行し、ＭＭＥは、Ｐ−ＧＷに、通常の個別ベアラアクティブ化処理（Dedicated Bearer Activation Procedure）の起動を要求する。
図５６のステップＳＴ９５０５において、Ｐ−ＧＷは、ＵＥに対して、ステップＳＴ９１４８で開設されたベアラを用いて、データの送信を行う。つまり、通常サイズのデータ（Normal size data）の送信を行い、その後、処理を終了する。
ステップＳＴ９５０６において、Ｐ−ＧＷは、新しいベアラが開設されたか否かを判断する。開設されていないと判断された場合は、ステップＳＴ９５０６の判断を繰り返す。開設されたと判断された場合は、ステップＳＴ９５０７に移行する。
ステップＳＴ９５０７において、Ｐ−ＧＷは、ＵＥに対して、新しく開設されたベアラを用いて、データの送信を行う。つまり、通常サイズのデータ（Normal size data）の送信を行い、その後、処理を終了する。
以上の実施の形態６の変形例１によって、前述の実施の形態１の効果に加えて、以下の効果を得ることができる。
ＩＰ接続アクセスネットワークへの不要な手続きを回避することが可能となる。重複してＥＰＳベアラを開設する処理が実行されることから、ＰＤＮ側に不正要求として接続を拒否される危険性を回避することができる。
また、不要な無線ベアラ設定を回避することができ、制御処理の重複、また制御処理が重複することによって通信システムが不安定になることを回避することができる。
これによって、安全な手順で通信ベアラを切り替えることが可能となり、また、外部ネットワークの動作による通信の影響を軽減することが可能となる。
実施の形態６ 変形例２．
実施の形態６の変形例２で解決する課題を以下に説明する。実施の形態６のconnection-liteの場合における伝送においては、１回の伝送データ量が小さい場合に利用されることが想定される。しかしながら、ＩＰパケットによる伝送を行うことを想定すると、例えば、ＲＦＣ２４６０などに示されるＩＰｖ６（Internet Protocol Version 6）のＩＰヘッダは、４０バイト（byte）であり、ＰＤＣＰにおけるヘッダ圧縮を考慮しても、送信データ量に対するヘッダオーバヘッドは小さくない。
前述の状態においては、ＵＥのＩＰアドレスの割当は１つであることが想定され、ＵＥのＩＤと等価と見なせることからも、少なくともＵＥのＩＰアドレスの情報伝送は、無線リソースを無駄に利用することとなる。また、ＵＥの通信相手となる装置のＩＰアドレスが限定されることから、通信相手となる装置のＩＰアドレスの情報伝送も無駄な無線リソースを利用する可能性がある。
前述の問題を解決するために、以下の対策を行う。connection-liteの場合におけるＵｕ点の伝送において、ＩＰヘッダのネットワークアドレス情報などを伝送せず、ＩＰヘッダのうち、上位プロトコルを示す要素および送信元アドレスなどを縮退化し、別のヘッダとして再構築する。
ＩＰヘッダの縮退化、別のヘッダの再構築を実行するエンティティの具体例としては、ＭＭＥなどがある。
縮退化し、別のヘッダとして再構築する縮退化対象パラメータの具体例として、以下の（１）〜（７）の７つを開示する。
（１）ソースアドレス（Source Address）。ＵＥのＩＰアドレスの割当は１つであることが想定されていることから、縮退化しての再構築が可能となる。ＵＥの通信相手となる装置も限定されることが想定されていることから、縮退化しての再構築が可能となる。
（２）ディスティネーションアドレス（Destination Address）。ＵＥのＩＰアドレスの割当は１つであることが想定されていることから、縮退化しての再構築が可能となる。ＵＥの通信相手となる装置も限定されることが想定されていることから、縮退化しての再構築が可能となる。
（３）バージョン。３ＧＰＰで定められた通信方式で用いるＩＰヘッダのバージョンは静的に決定されていることから、縮退化しても、問題なく通信を行うことができる。
（４）トラフィッククラス。ＥＰＳベアラ設定（「呼設定」と称される場合もある）の際に静的に決定されることから、縮退化しても、問題なく通信を行うことができる。
（５）ホップリミット。移動端末で終端する場合、つまり移動端末の先に更ホップすることが無い場合、縮退化しても、問題なく通信を行うことができる。
（６）フローレベル（Flow Label）。
（７）前記（１）〜（６）の組合せ。
本変形例は、前述の実施の形態６および実施の形態６の変形例１と組合わせて用いることができる。
以上の実施の形態６の変形例２によって、以下の効果を得ることができる。ＩＰアドレス分の伝送量の削減が可能となり、使用する無線リソースの低減が可能となる。
実施の形態６ 変形例３．
実施の形態６の変形例３で解決する課題を以下に説明する。非特許文献１５で提案されているコネクションライト（connection-lite）の場合における伝送においては、無線区間の接続（RRC Connection）を設定してから、データを伝送する構成となっている。しかしながら、小データで、１パケットの伝送であることを想定すると、無線区間の接続を実行することは、通信端末装置の消費電力および無線リソースに影響が大きい。
前述の問題を解決するために、前述の実施の形態１の変形例４と同様の以下の対策を行う。
コネクションライト（connection-lite）の場合において、小データは、前述の実施の形態１の変形例４を用いて送信する。ＲＲＣ待受け状態（ＲＲＣ＿ＩＤＬＥ）で、小データをｅＮＢに送信する。小データをランダムアクセス（Random Access）処理中に送信する。詳細は、前述の実施の形態１の変形例４と同様であるので、説明を省略する。
本変形例は、前述の実施の形態６、実施の形態６の変形例１、および実施の形態６の変形例２と組合せて用いることができる。
以上の実施の形態６の変形例３によって、以下の効果を得ることができる。ＲＲＣ接続（RRC Connection）を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
実施の形態６ 変形例４．
実施の形態６の変形例４で解決する課題は、前述の実施の形態６の変形例３と同様である。
前述の問題を解決するために、実施の形態１の変形例５と同様の以下の対策を行う。
コネクションライト（connection-lite）の場合において、小データは、前述の実施の形態１の変形例５を用いて送信する。ＲＲＣ待受け状態（ＲＲＣ＿ＩＤＬＥ）で、小データをｅＮＢに送信する。小データをページング処理中に送信する。詳細は、前述の実施の形態１の変形例５と同様であるので、説明を省略する。
本変形例は、前述の実施の形態６、実施の形態６の変形例１、実施の形態６の変形例２、および実施の形態６の変形例３と組合せて用いることができる。
以上の実施の形態６の変形例４によって、以下の効果を得ることができる。ＲＲＣ接続（RRC Connection）を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
実施の形態６ 変形例５．
実施の形態６の変形例５で解決する課題を以下に説明する。実施の形態６およびその変形例１〜４において、ＵＥとｅＮＢのＥＭＣ（ＲＲＣ）接続の状態を用いる場合は、前述の実施の形態２において挙げたＵＥとｅＮＢとの間での状態不一致の課題が発生し得る。
前記の問題を解決するために、前述の実施の形態２と同様に、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態においては、定期的に、「uu-keep-alive」の送信を行い、ネットワークにその状態を通知する機能を、前述の実施の形態６およびその変形例１〜３に追加する。詳細は、前述の実施の形態２と同様であるので、説明を省略する。
本変形例は、前述の実施の形態６、実施の形態６の変形例１、実施の形態６の変形例２、実施の形態６の変形例３、および実施の形態６の変形例４と組合せて用いることができる。
以上の実施の形態６の変形例４によって、以下の効果を得ることができる。ＵＥとｅＮＢとの間での状態不一致が軽減されるので、システムリソースに対する影響を軽減することができる。
実施の形態７．
実施の形態７で解決する課題は、実施の形態６における課題と基本的に同一である。非特許文献１５および非特許文献１６などに示される対策ならびに前述の実施の形態６の対策は、伝送データによってコネクションライト（connection lite）という構成とコネクションオリエンテッド（connection oriented）の構成とを切り替える必要があった。しかし、前記方法では、構成の切替時に、ベアラのセットアップなどが必要となり、シグナリング処理が多くなるという課題、およびデータの伝送遅延が発生するという課題がある。
図５７および図５８は、実施の形態７の課題を説明するためのシーケンスを示す図である。図５７と図５８とは、境界線ＢＬ２２の位置で、つながっている。図５７および図５８では、定期的に比較的小さなサイズのデータを送受信するようなアプリケーションのシーケンスを示している。図５７および図５８に示すシーケンスは、図２７〜図２９に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ１１１０７において、ＵＥにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップＳＴ１１１０９に移行する。
ステップＳＴ１１１０８において、ｅＮＢにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップＳＴ１１１１０に移行する。本タイマが満了したことによって、対象のＵＥのＲＲＣ状態がＩＤＬＥになったと推定する。
ステップＳＴ１１１０９において、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態となる。また、ＥＣＭ＿ＩＤＬＥ状態となる。
ステップＳＴ１１１１０において、ｅＮＢは、ＲＲＣ＿ＩＤＬＥ状態となり、ステップＳＴ１１１１１に移行する。
ステップＳＴ１１１１１において、Ｓ１リリース処理Ａ（S1 Release Procedure A）が起動される。詳細は、図２９のステップＳＴ５１３４の処理と同様であるので、説明を省略する。
ステップＳＴ１１１１１の処理が完了し、ステップＳＴ１１１１２において、ＭＭＥは、ＥＣＭ＿ＩＤＬＥ状態となる。
ステップＳＴ１１１１１におけるＳ１リリース処理Ａが完了した後に、ステップＳＴ１１１１３において、ＵＥのアプリケーションから、ＮＡＳにデータの送信が要求され、送信データが送信される。
ステップＳＴ１１１１４において、サービス要求処理Ａ（Service Request Procedure A）が起動される。詳細は、図２７のステップＳＴ５１０５の処理と同様であるので、説明を省略する。
ステップＳＴ１１１１５において、ステップＳＴ１１１１４で設立されたＥＰＳベアラ（EPS Bearer）を用いて、ＵＥからＰ−ＧＷ経由でアプリケーションサーバにデータが送信される。
ステップＳＴ１１１１６において、ＵＥにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップＳＴ１１１１８に移行する。
ステップＳＴ１１１１７において、ｅＮＢにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップＳＴ１１１１９に移行する。
ステップＳＴ１１１１８において、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態となる。また、ＥＣＭ＿ＩＤＬＥ状態となる。
ステップＳＴ１１１１９において、ｅＮＢは、ＲＲＣ＿ＩＤＬＥ状態となる。また、ＥＣＭ＿ＩＤＬＥ状態となり、ステップＳＴ１１１２０に移行する。
ステップＳＴ１１１２０において、Ｓ１リリース処理Ａ（S1 Release Procedure A）が起動される。詳細は、図２９のステップＳＴ５１３４の処理と同様であるので、説明を省略する。
ステップＳＴ１１１２０の処理が完了し、ステップＳＴ１１１２１において、ＭＭＥは、ＥＣＭ＿ＩＤＬＥ状態となる。
ステップＳＴ１１１２２において、ＵＥのアプリケーションから、ＮＡＳにデータの送信が要求され、送信データが送信される。
ステップＳＴ１１１２３において、サービス要求処理Ａ（Service Request Procedure A）が起動される。詳細は、図２７のステップＳＴ５１０５の処理と同様であるので、説明を省略する。
このように、小さなサイズのデータを送信するたびに、ステップＳＴ１１１１４のサービス要求処理Ａと、ステップＳＴ１１１２０のサービス要求処理Ａとが繰り返されることとなる。これによって、多くの手順が必要となり、これに伴うネットワークリソースおよび通信端末装置の消費電力を消費してしまうこととなる。
前記の問題を解決するために、以下の対策を行う。
ＲＲＣの状態と、ＮＡＳの状態とが連動して遷移させない。以下、ＮＡＳの状態はＥＣＭ状態とも称する。
図５７および図５８を用いて具体的に説明すると、ステップＳＴ１１１０９とは異なり、ＵＥにおいてＲＲＣ＿ＩＤＬＥ状態に遷移しても、該遷移と連動して、ＵＥをＥＣＭ＿ＩＤＬＥ状態に遷移させない。ＵＥにおいて、ＲＲＣ接続（RRC Connection）がリリースされても、ＥＣＭ＿ＩＤＬＥ状態へは遷移せず、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を維持する。
また、ステップＳＴ１１１１０とは異なり、ｅＮＢがＲＲＣ＿ＩＤＬＥ状態に遷移しても、該遷移と連動して、ｅＮＢは、Ｓ１リリース処理（S1 Release Procedure）を起動させない。つまり、ｅＮＢがＲＲＣ＿ＩＤＬＥ状態に遷移しても、該遷移と連動して、ＭＭＥはＥＣＭ＿ＩＤＬＥ状態へ遷移させない。つまり、ｅＮＢがＲＲＣ＿ＩＤＬＥ状態に遷移しても、Ｓ１リリース処理（S1 Releaser Procedure）を起動させないことによって、ＭＭＥにおけるＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を維持する。
Ｕ−ｐｌａｎｅ用のＥ−ＲＡＢ（E-UTRAN Radio Access Bearer）が設定される状態において、ＮＡＳレベル（Ｓ１レベル）の接続は維持したまま、無線区間の接続のみを解放および設定することを可能とする機構を取り入れる。
これによって、上位のベアラ、例えばＳ１ベアラなどを保ったまま、無線区間のリソースを開放することが可能となる。無線区間のリソースの開放の目的を達成するので、上位のベアラの再設定が必要になるという問題を解決することができる。
通常、ＵＥでは、ＲＲＣの状態とＥＣＭの状態とは連動して遷移する。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態のＵＥにおいてＲＲＣ接続（RRC Connection）がリリースされた場合、ＥＣＭ＿ＩＤＬＥ状態となる。ＲＲＣ接続がリリースされると、ＲＲＣ＿ＩＤＬＥ状態となる。したがって、ＲＲＣ接続のリリースによって、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥに遷移し、連動してＥＣＭ＿ＣＯＮＮＥＣＴＥＤからＥＣＭ＿ＩＤＬＥに遷移する（非特許文献１４ ４．６．４章参照）。
通常のネットワークでは、ＲＲＣの状態とＥＣＭの状態とは連動して遷移する。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態のｅＮＢにおいて、対象となるＵＥのＲＲＣ状態がＲＲＣ＿ＩＤＬＥに遷移したと想定した場合、Ｓ１リリース処理（S1 Release Procedure）が起動される。Ｓ１接続がリリースされることから、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤからＥＣＭ＿ＩＤＬＥに遷移する。したがって、ＲＲＣ＿ＩＤＬＥへの遷移に連動し、Ｓ１接続がリリースされ、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤからＥＣＭ＿ＩＤＬＥに遷移する（非特許文献１４ ４．６．４章参照）。
通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させるか、本実施の形態の解決策であるＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないかを判断する主体としては、ＵＥがある。前記判断を「状態遷移方法判断」と称することもある。
状態遷移方法判断の具体例として、以下の（１），（２）の２つを開示する。
（１）ＵＥは、アクセス要求を行ったアプリケーションに基づいて判断する。
（１−１）定期的に比較的小さなサイズのデータを送信するアプリケーションであるか否かを判断する。定期的に比較的小さなサイズデータを送信するアプリケーションであると判断された場合は、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないと決定する。定期的に比較的小さなサイズデータを送信するアプリケーションでないと判断された場合は、通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させると決定する。定期的に比較的小さなサイズデータを送信するアプリケーションは、従来の技術においては、無線ベアラの解放と開設とを繰り返すことなる。つまり、ＲＲＣ＿ＩＤＬＥ状態と、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態との間の遷移を繰り返す。これに連動して、ＥＣＭ＿ＩＤＬＥ状態と、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態との間の遷移を繰り返す。したがって、本実施の形態を用いることによって、処理手順の簡易化を図ることができるという効果が顕著に現れる。
（１−２）ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションであるか否かを判断する。ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションであると判断された場合は、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないと決定する。ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションでないと判断された場合は、通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させると決定する。ｋｅｅｐ-ａｌｉｖｅパケットの送信を要求するアプリケーションは、従来の技術においては、無線ベアラの解放と開設とを繰り返すことなる。つまり、ＲＲＣ＿ＩＤＬＥ状態と、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態との間の遷移を繰り返す。これに連動して、ＥＣＭ＿ＩＤＬＥ状態と、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態との間の遷移を繰り返す。したがって、本実施の形態を用いることによって、処理手順の簡易化を図ることができるという効果が顕著に現れる。
（２）ＵＥは、繰り返し発生する送信であるか否かを判断する。ＵＥは、閾値未満の周期で繰り返し発生する送信であるか否かを判断するようにしてもよい。繰り返し発生する送信の具体例としては、「Uu keep alive ind」、ＵＥモニタリング用メッセージ、周期的なメジャメントレポート、周期的なＴＡＵなどがある。繰り返し発生する送信であると判断された場合は、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないと決定する。繰り返し発生する送信でないと判断された場合は、通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させる決定する。周期的に繰り返される送信は、従来の技術においては、無線ベアラの解放と開設とを繰り返すことなる。つまり、ＲＲＣ＿ＩＤＬＥ状態と、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態との間の遷移を繰り返す。これに連動して、ＥＣＭ＿ＩＤＬＥ状態と、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態との間の遷移を繰り返す。したがって、本実施の形態を用いることによって、処理手順の簡易化を図ることができるという効果が顕著に現れる。
ＵＥは、ネットワーク側に、状態遷移判断の結果を通知する。状態遷移判断の結果をネットワーク側に通知する方法の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにシグナル、あるいはメッセージを設ける。
（１−１）新たにＲＲＣシグナル、あるいはＲＲＣメッセージを設ける。
（１−２）新たにＮＡＳシグナル、あるいはＮＡＳメッセージを設ける。
（１−３）新たにＲＲＣシグナル、ＮＡＳシグナルの双方を設ける。
（２）既存のシグナル、あるいはメッセージを用いる。本具体例（２）は、具体例（１）と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例（２）によって、通信システムが複雑化することを回避することができる。
新たなシグナルにマッピングするパラメータの具体例として、以下の（１）〜（３）の３つを開示する。
（１）状態遷移判断の結果。ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないと判断した場合のみ通知するようにしてもよい。以下の説明では、ＲＲＣ状態と、ＥＣＭの状態とを連動して遷移させないと判断した場合を「ＲＲＣ独立」といい、また追加するパラメータを「ＲＲＣ独立」という場合がある。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）前記（１），（２）の組合せ。
次に、既存のＲＲＣシグナルを用いる場合の具体例としては、ＲＲＣ接続要求（RRC Connection Rquest）メッセージを用いる。以下の説明では、ＲＲＣ状態と、ＥＣＭの状態とを連動して遷移させないと判断した場合を「ＲＲＣ独立」といい、また追加するパラメータを「ＲＲＣ独立」という場合がある。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例としては、状態遷移判断の結果などがある。
次に、既存のＮＡＳシグナルを用いる場合の具体例としては、サービス要求（Service Request）メッセージを用いる。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例としては、状態遷移判断の結果などがある。パラメータを既存のＲＲＣシグナル、既存のＮＡＳシグナルの双方に追加してもよい。
状態遷移判断の結果を得たｅＮＢは、Ｓ１ベアラの設定の際に、状態遷移判断の結果を、該Ｓ１ベアラに対応付けて記憶する。具体例としては、Ｓ１ベアラの設定の際に、該Ｓ１ベアラは、通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させるベアラか、または、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないベアラかを記憶する。あるいは、該Ｓ１ベアラとＲＲＣベアラとは連動させて管理するか、Ｓ１ベアラとＲＲＣベアラとは独立させて管理するかを記憶する。あるいは、ＲＲＣベアラが解放された場合にＳ１ベアラの解放処理（S1 Release Procedure）を開始するか、ＲＲＣベアラが解放された場合にＳ１ベアラの解放処理を開始しないかを記憶する。
ｅＮＢは、状態遷移判断の結果の記憶に基づいて、以下のように動作してもよい。状態遷移判断の結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させる場合、所定の期間にＲＲＣデータの送受信が行われるか否かの判断を行う。所定の期間を「ＲＲＣデータモニタタイマ（ｅＮＢ）」と称する。
ＲＲＣデータモニタタイマ（ｅＮＢ）が満了するまでに、ＲＲＣデータの送受信が行われる場合、ｅＮＢは、ＲＲＣ＿ＣＯＮＥＣＴＥＤ状態を継続する。またＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を継続する。一方、ＲＲＣデータモニタタイマ（ｅＮＢ）が満了するまでに、ＲＲＣデータの送受信が行われない場合、ｅＮＢは、ＲＲＣ＿ＩＤＬＥ状態に遷移する。またＥＣＭ＿ＩＤＬＥ状態に遷移する。つまり、Ｓ１リリース処理（S1 Release Procedure）を起動する。
状態遷移判断の結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない場合、所定の期間にＲＲＣデータの送受信が行われるか否かの判断を行う。また、別個に所定の期間にＮＡＳデータの送受信が行われるか否かの判断を行う。所定の期間を「ＮＡＳデータモニタタイマ（ｅＮＢ）」と称する。
ＲＲＣデータモニタタイマ（ｅＮＢ）が満了するまでに、ＲＲＣデータの送受信が行われる場合、ｅＮＢは、ＲＲＣ＿ＣＯＮＥＣＴＥＤ状態を継続する。一方、ＲＲＣデータモニタタイマ（ｅＮＢ）が満了するまでに、ＲＲＣデータの送受信が行われない場合、ｅＮＢは、ＲＲＣ＿ＩＤＬＥ状態に遷移する。つまり、無線ベアラのリソースを解放する。無線ベアラのリソースの具体例としては、該ＵＥに対するスケジューリングリクエストのリソースなどがある。しかし、ＥＣＭ＿ＩＤＬＥ状態に遷移しない。つまり、Ｓ１リリース処理（S1 Release Procedure）を起動しない。
ＮＡＳデータモニタタイマ（ｅＮＢ）が満了するまでに、ＮＡＳデータの送受信が行われる場合、ｅＮＢは、ＥＣＭ＿ＣＯＮＥＣＴＥＤ状態を継続する。一方、ＮＡＳデータモニタタイマ（ｅＮＢ）が満了するまでに、ＮＡＳデータの送受信が行われない場合、ｅＮＢは、ＥＣＭ＿ＩＤＬＥ状態に遷移する。つまり、Ｓ１ベアラ、ＥＰＳベアラのリソースを解放する。Ｓ１リリース処理（S1 Release Procedure）を起動するようにしてもよい。
またＵＥは、状態遷移判断の結果を記憶してもよい。状態遷移判断の結果を該Ｓ１ベアラに対応付けて記憶してもよい。
状態遷移判断の結果が、通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させる場合、所定の期間にＲＲＣデータの送受信が行われるか否かの判断を行う。所定の期間を「ＲＲＣデータモニタタイマ（ＵＥ）」と称する。
ＲＲＣデータモニタタイマ（ＵＥ）が満了するまでに、ＲＲＣデータの送受信が行われる場合、ＵＥは、ＲＲＣ＿ＣＯＮＥＣＴＥＤ状態を継続する。またＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を継続する。一方、ＲＲＣデータモニタタイマ（ＵＥ）が満了するまでに、ＲＲＣデータの送受信が行われない場合、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態に遷移する。またＥＣＭ＿ＩＤＬＥ状態に遷移する。
状態遷移判断の結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない場合、所定の期間にＲＲＣデータの送受信が行われるか否かの判断を行う。また、別個に所定の期間にＮＡＳデータの送受信が行われるか否かの判断を行う。所定の期間を「ＮＡＳデータモニタタイマ（ＵＥ）」と称する。
ＲＲＣデータモニタタイマ（ＵＥ）が満了するまでに、ＲＲＣデータの送受信が行われる場合、ＵＥは、ＲＲＣ＿ＣＯＮＥＣＴＥＤ状態を継続する。一方、ＲＲＣデータモニタタイマ（ＵＥ）が満了するまでに、ＲＲＣデータの送受信が行われない場合、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態に遷移する。しかし、ＥＣＭ＿ＩＤＬＥ状態に遷移しない。
ＮＡＳデータモニタタイマ（ＵＥ）が満了するまでに、ＮＡＳデータの送受信が行われる場合、ＵＥは、ＥＣＭ＿ＣＯＮＥＣＴＥＤ状態を継続する。一方、ＮＡＳデータモニタタイマ（ＵＥ）が満了するまでに、ＮＡＳデータの送受信が行われない場合、ＵＥは、ＥＣＭ＿ＩＤＬＥ状態に遷移する。
ＮＡＳデータモニタタイマ（ｅＮＢ）とＮＡＳデータモニタタイマ（ＵＥ）とは、同じであってもよい。同じである場合のタイマを、「ＮＡＳデータモニタタイマ」と称することもある。ＵＥとｅＮＢとの状態不一致の期間を低減することができるという効果を得ることができる。
ＮＡＳデータモニタタイマの決定の主体の具体例としては、ＵＥおよびｅＮＢがある。ＮＡＳデータモニタタイマの決定方法の具体例として、以下の（１）〜（３）の３つを開示する。
（１）アプリケーションに依存して決定されるようにしてもよい。
（１−１）アプリケーションが要求するＱｏＳ、ＱＣＩ、ベアラ情報などから決定してもよい。
（１−２）アプリケーションが、ｋｅｅｐ-ａｌｉｖｅパケットを送信する場合、その周期よりも長い値。ＮＡＳデータモニタタイマが満了するまでに、ｋｅｅｐ-ａｌｉｖｅパケットの送信が発生することになる。したがって、アプリケーションが継続している間、ＵＥとｅＮＢとの間のＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を継続することが可能となる。
（２）Ｓ１リソース状況。Ｓ１リソースが不足している場合は、短く設定し、Ｓ１リソースが不足していない場合は、長く設定してもよい。
（３）静的に決定する。これによって、ＵＥとｅＮＢとの間で通知する必要がないという効果を得ることができる。
ＮＡＳデータモニタタイマをＵＥが決定した場合のｅＮＢへの通知方法の具体例として、以下の（１）〜（４）の４つを開示する。
（１）ＴＡＵ処理で通知する。具体例としては、ＴＡＵ要求（TAU Request）などによって通知する。
（２）アタッチ処理で通知する。具体例としては、アタッチ要求（Attach Request）、ＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）などによって通知する。
（３）ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）によって通知する。具体例としては、ＲＲＣ接続セットアップ要求（RRC Connection Setup Request）などによって通知する。
（４）サービス要求処理（Service Request Procedure）によって通知する。具体例としては、サービス要求（Service Request）、ＲＲＶ接続再設定完了（RRC Connection Reconfiguration Complete）などによって通知する。
ＮＡＳデータモニタタイマをｅＮＢが決定した場合のＵＥへの通知方法の具体例として、以下の（１）〜（６）の６つを開示する。
（１）報知情報によって通知する。
（２）個別情報によって通知する。
（３）ＴＡＵ処理によって通知する。具体例としては、ＴＡＵアクセプト（TAU Accept）などによって通知する。
（４）アタッチ処理によって通知する。具体例としては、アタッチアクセプト（Attach Accept）、ＲＲＣ接続再設定（RRC Connection Reconfiguration）などによって通知する。
（５）ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）によって通知する。具体例としては、ＲＲＣ接続セットアップ（RRC Connection Setup）などによって通知する。
（６）サービス要求処理（Service Request Procedure）によって通知する。具体例としては、ＲＲＣ接続再設定（RRC Connection Reconfiguration）などによって通知する。
ＲＲＣデータモニタタイマ（ｅＮＢ）と、ＲＲＣデータモニタタイマ（ＵＥ）とは、同じであってもよい。同じである場合のタイマを、「ＲＲＣデータモニタタイマ」と称する。ＵＥとｅＮＢとの状態不一致の期間を低減することができるという効果を得ることができる。
ＲＲＣデータモニタタイマの決定の主体の具体例としては、ＵＥおよびｅＮＢがある。ＲＲＣデータモニタタイマの決定方法の具体例として、以下の（１），（２）の２つを開示する。
（１）無線リソース状況。無線リソースが不足している場合は、短く設定し、無線リソースが不足していない場合は、長く設定してもよい。
（２）静的に決定する。これによって、ＵＥとｅＮＢとの間で通知する必要がないという効果を得ることができる。
ＲＲＣデータモニタタイマをＵＥが決定した場合のｅＮＢへの通知方法の具体例として、以下の（１）〜（３）の３つを開示する。
（１）ＴＡＵ処理によって通知する。具体例としては、ＴＡＵ要求（TAU Request）などによって通知する。
（２）アタッチ処理によって通知する。具体例としては、アタッチ要求（Attach Request）、ＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）などによって通知する。
（３）ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）によって通知する。具体例としては、ＲＲＣ接続セットアップ要求（RRC Connection Setup Request）などによって通知する。
ＲＲＣデータモニタタイマをｅＮＢが決定した場合のＵＥへの通知方法の具体例として、以下の（１）〜（５）の５つを開示する。
（１）報知情報によって通知する。
（２）個別情報によって通知する。
（３）ＴＡＵ処理によって通知する。具体例としては、ＴＡＵアクセプト（TAU Accept）などによって通知する。
（４）アタッチ処理によって通知する。具体例としては、アタッチアクセプト（Attach Accept）、ＲＲＣ接続再設定（RRC Connection Reconfiguration）などによって通知する。
（５）ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）によって通知する。具体例としては、ＲＲＣ接続セットアップ（RRC Connection Setup）などによって通知する。
ＵＥは、ＲＲＣ＿ＩＤＬＥ状態で、アプリケーションからアクセス要求が発生した場合、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持しているか否かを判断してもよい。あるいは、継続しているＳ１ベアラが存在するか否かを判断してもよい。
ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持していないと判断された場合、あるいは継続しているＳ１ベアラが存在しないと判断された場合は、該アクセス要求に対して、前記状態遷移方法判断を実行すればよい。
ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持していると判断された場合、あるいは継続しているＳ１ベアラが存在すると判断された場合は、維持しているＥＣＭ＿ＣＯＮＮＥＣＴＥＤと対応付けられたＥＰＳベアラで送信可能なデータであるか否かを判断する。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤと対応付けられたＥＰＳベアラを設立した際と同様のアプリケーションからの送信要求であるか否かを判断してもよい。
ＥＰＳベアラで送信不可能なデータであると判断された場合は、該アクセス要求に対して、前記状態遷移方法判断を実行すればよい。
ＥＰＳベアラで送信可能なデータであると判断された場合は、ＲＲＣ接続の確立を要求する。その場合、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している旨を併せて通知する。具体例としては、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）を起動し、併せてＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している旨を通知する。また、サービス要求処理（Service Request Procedure）を起動しないようにしてもよい。
通知方法の具体例を以下に開示する。既存のＲＲＣシグナル、あるいはＲＲＣメッセージを用いる。具体例としては、ＲＲＣ接続要求（RRC Connection Request）を用いる。既存のＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）で用いるメッセージと同様であるので、通信システムが複雑化することを回避することができる。
既存のＲＲＣシグナリングに追加が必要なパラメータの具体例として、以下の（１）〜（３）の３つを開示する。
（１）既存のＳ１ベアラを用いる旨、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している旨など。Ｓ１ベアラの設立が不要である旨。
（２）既存のＳ１ベアラを特定可能な情報。例えば、インデックス番号などがある。
（３）前記（１），（２）の組合せ。
ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）で既存のＳ１ベアラを用いる旨などの通知を受けたｅＮＢは、Ｓ１ベアラのセットアップを起動しない。また、ＵＥからサービス要求（Service Request）が通知されてこないと認識してもよい。また、ＲＲＣ接続（RRC connection）とＳ１ベアラとの関連付けを行い、ＵＥにＲＲＣ接続セットアップ（RRC Connection Setup）を送信する。Ｓ１ベアラのセットアップを行うことなく、ＲＲＣ接続の手続きのみでデータの送信が可能となる。
ＵＥは、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないとしている際に、アプリケーションから、サービス切断要求、あるいはサービスリリース要求を受信した場合、ｅＮＢにＳ１ベアラリリース要求を通知してもよい。あるいはＮＡＳレベルのリソースリリース要求を通知してもよい。
通知方法の具体例として、以下の（１），（２）の２つを開示する。
（１）新たにＲＲＣシグナル、あるいはＲＲＣメッセージを設ける。以下「ＮＡＳリリース要求」と称することもある。
（２）新たにＮＡＳシグナル、あるいはＮＡＳメッセージを設ける。以下「ＮＡＳリリース要求」と称することもある。
新たなシグナルにマッピングするパラメータの具体例として、以下の（１）〜（４）の４つを開示する。
（１）Ｓ１ベアラリリース要求である旨、ＮＡＳレベルのリソースリリース要求である旨など、ＥＣＭ＿ＩＤＬＥへの遷移要求である旨など。
（２）ＵＥの識別子。具体的には、ＵＥ−ＩＤ、ＩＭＳＩであってもよい。
（３）既存のＳ１ベアラを特定可能な情報。例えば、インデックス番号などがある。
（４）前記（１）〜（３）の組合せ。
次に、図５９〜図６１を用いて、実施の形態７における通信システムのシーケンスの具体例について説明する。図５９〜図６１は、実施の形態７における通信システムのシーケンスの一例を示す図である。図５９と図６０とは、境界線ＢＬ２３の位置で、つながっている。図６０と図６１とは、境界線ＢＬ２４の位置で、つながっている。図５９〜図６１に示すシーケンスは、図２７〜図２９および図４４〜図４７に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ５１０４でアクセス要求（Access Request）を受信したＵＥのＮＡＳは、状態遷移方法判断を実行する。状態遷移方法判断の結果がＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない、つまり「ＲＲＣ独立」となった場合において、ステップＳＴ１１２０３において、サービス要求処理（Service Request Procedure）（ＲＲＣ独立）を起動する。
ステップＳＴ１１２０３のサービス要求処理（ＲＲＣ独立）は、ステップＳＴ１１２０４〜ステップＳＴ９１４７の処理を含む。
ステップＳＴ１１２０４において、ＵＥのＮＡＳは、ＡＳ（Access Stratum）にサービス要求（Service Request）メッセージを送信する。ＵＥのＮＡＳが、ＲＲＣレイヤに通知してもよい。ステップＳＴ１１２０４のサービス要求メッセージには、状態遷移判断の結果が含まれていてもよい。
ステップＳＴ１１２０４でＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報（ＲＲＣ独立）が含まれているサービス要求メッセージを受信したＵＥのＲＲＣレイヤは、ステップＳＴ１１２０５において、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）（ＲＲＣ独立）を起動する。
ステップＳＴ１１２０５のＲＲＣ接続セットアップ処理（ＲＲＣ独立）は、ステップＳＴ１１２０６〜ステップＳＴ１１２０８の処理を含む。
ステップＳＴ１１２０６において、ＵＥのＲＲＣレイヤは、ｅＮＢにＲＲＣ接続セットアップ要求（RRC Connection Setup Request）メッセージを送信する。 ＲＲＣ接続セットアップ要求メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報（ＲＲＣ独立）が含まれていてもよい。
ステップＳＴ１１２０６でＲＲＣ接続セットアップ要求メッセージを受信したｅＮＢは、ステップＳＴ１１２０７において、ＵＥのＲＲＣレイヤにＲＲＣ接続セットアップ（RRC Connection Setup）メッセージを送信する。ＲＲＣ接続セットアップメッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ステップＳＴ１１２０７でＲＲＣ接続セットアップメッセージを受信したＵＥは、ステップＳＴ１１２０８において、ｅＮＢにＲＲＣ接続セットアップ完了（RRC Connection Setup Complete）メッセージを送信する。ＲＲＣ接続セットアップ完了メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ステップＳＴ１１２０５のＲＲＣ接続セットアップ処理（ＲＲＣ独立）が完了することによって、ステップＳＴ１１２０９において、ＵＥは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態となる。また、ＵＥは、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態となる。
同様に、ステップＳＴ１１２１０において、ｅＮＢは、該ＵＥのＲＲＣ状態を、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態と想定する。以下、単に「ｅＮＢはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態となる」という。
ステップＳＴ１１２１１において、ＵＥのＲＲＣレイヤは、ｅＮＢにサービス要求（Service Request）メッセージを送信する。サービス要求メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ステップＳＴ１１２１１でサービス要求メッセージを受信したｅＮＢは、ステップＳＴ１１２１２において、ＭＭＥにサービス要求（Service Request）メッセージを送信する。サービス要求メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ステップＳＴ１１２１３において、ＭＭＥは、ＨＳＳの情報を用いて、ＵＥの認証（authentication）およびセキュリティ（security）制御の処理を行う。
ステップＳＴ１１２１４において、ＭＭＥは、ｅＮＢに初期コンテキストセットアップ要求（Initial Context Setup Request）メッセージを送信する。 初期コンテキストセットアップ要求メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ステップＳＴ１１２１４で初期コンテキストセットアップ要求メッセージを受信したｅＮＢは、ステップＳＴ１１２１５において、無線ベアラ設立処理（Radio Bearer Establishment Procedure）（ＲＲＣ独立）を起動する。
ステップＳＴ１１２１５の無線ベアラ設立処理（ＲＲＣ独立）は、ステップＳＴ１１２１６〜ステップＳＴ１１２１７の処理を含む。
ステップＳＴ１１２１６において、ｅＮＢは、ＵＥにＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージを送信する。ＲＲＣ接続再設定メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ステップＳＴ１１２１６でＲＲＣ接続再設定メッセージを受信したＵＥは、ステップＳＴ１１２１７において、ｅＮＢにＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）メッセージを送信する。ＲＲＣ接続再設定完了メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ステップＳＴ１１２１７でＲＲＣ接続再設定完了メッセージを受信したｅＮＢは、ステップＳＴ１１２１８において、ＭＭＥに初期コンテキストセットアップ完了（Initial Context Setup Complete）メッセージを送信する。初期コンテキストセットアップ完了メッセージには、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
ベアラ修正応答メッセージを受信したＭＭＥは、ステップＳＴ１１２２５において、該ＵＥに対してＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行する。あるいは、該ＵＥに対するＳ１コネクションの設立が完了したことで、ＭＭＥは、該ＵＥに対してＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態に移行してもよい。該ＵＥに対するＳ１コネクションの設立が完了したことは、ＭＭＥは、ステップＳＴ１１２１８における初期コンテキストセットアップ完了メッセージの受信で認識する。
ステップＳＴ１１２０３において、サービス要求処理（ＲＲＣ独立）が完了することによって、ステップＳＴ１１２２９において、ＵＥから、ｅＮＢとＭＭＥとＳ−ＧＷとＰ−ＧＷとを経由して、アプリケーションサーバ（APP Server）へのデータの送信が可能となる。
図６１のステップＳＴ１１２３０において、ＵＥにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。ＵＥは、現在のＲＲＣ接続がＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない（ＲＲＣ独立）のベアラであるか否かを判断する。ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない（ＲＲＣ独立）ベアラであると判断された場合は、ＲＲＣのみＩＤＬＥ状態へ移行し、ＥＣＭはＣＯＮＮＥＣＴＥＤを維持する。ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない（ＲＲＣ独立）ベアラでないと判断された場合は、ＲＲＣおよびＥＣＭともに、ＩＤＬＥ状態へ移行する。本シーケンスでは、ＲＲＣ独立ベアラであるので、ステップＳＴ１１２３２およびステップＳＴ１１２３３に移行する。
ステップＳＴ１１２３１において、ｅＮＢにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップＳＴ１１２３４に移行する。前記タイマが満了したことによって、対象のＵＥのＲＲＣ状態がＩＤＬＥになったと想定、あるいは推定する。
ステップＳＴ１１２３２において、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態となる。
ステップＳＴ１１２３３において、ＵＥは、記憶している状態遷移判断結果を参照してもよい。状態遷移判断結果が、通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させる場合、ＵＥは、ＥＣＭの状態をＲＲＣの状態と連動して遷移させる。つまりＥＣＭ状態をＥＣＭ＿ＩＤＬＥへ遷移させる。一方、状態遷移判断結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない場合、ＵＥは、ＥＣＭの状態をＲＲＣの状態と連動して遷移させずに、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を維持する。本動作例では、ステップＳＴ１１２３３において、ＵＥは、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を維持する。
ステップＳＴ１１２３４において、ｅＮＢは、ＲＲＣ＿ＩＤＬＥ状態となり、ステップＳＴ１１２３５に移行する。
ステップＳＴ１１２３５において、ｅＮＢは、記憶している状態遷移判断結果を参照してもよい。状態遷移判断結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない場合は、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ状態を維持する。つまり、Ｓ１リリース処理Ａ（S1 Release Procedure A）を起動しない。
状態遷移判断結果が、通常のＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させる場合は、ＥＣＭ状態もＩＤＬＥへ移行させる。つまり、ステップＳＴ１１２３６に移行し、Ｓ１リリース処理Ａ（S1 Release Procedure A）を起動する。Ｓ１リリース処理Ａの詳細は、図２７のステップＳＴ５１０５の処理と同様であるので、説明を省略する。また、図５９〜図６１では、その後の処理の説明を省略し、「終了」と記載する。
ステップＳＴ１１２３５において、状態遷移判断結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないと判断された場合は、Ｓ１リリース処理Ａが起動されないので、ステップＳＴ１１２３７において、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤは維持される。
ステップＳＴ１１２３８において、ＵＥのアプリケーションから、ＮＡＳにデータの送信が要求され、送信データが送信される。
ＵＥのＮＡＳは、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持しているか否かを判断してもよい。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持していない場合は、通常のサービス要求処理Ａ（Service Request Procedure A）を起動させる。通常のサービス要求処理Ａの詳細は、ステップＳＴ１１１１４の処理と同様であるので、説明を省略する。
ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している場合、維持しているＥＣＭ＿ＣＯＮＮＥＣＴＥＤと対応付けられたＥＰＳベアラ（EPS Bearer）で送信可能なデータであるか否かを判断する。言い換えれば、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤと対応付けられたＥＰＳベアラ（EPS Bearer）を設立したときと同様のアプリケーションからの送信要求であるか否かを判断する。ＥＰＳベアラで送信不可能なデータである場合は、通常のサービス要求処理Ａを起動させる。通常のサービス要求処理Ａの詳細は、ステップＳＴ１１１１４の処理と同様であるので、説明を省略する。ＥＰＳベアラで送信可能なデータである場合は、ステップＳＴ１１２３９に移行する。
ステップＳＴ１１２３９において、ＵＥは、ＲＲＣ接続セットアップ処理を起動する。その場合、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している旨を併せて通知する（以下「既存Ｓ１ベアラ」という場合がある）。また既存のＳ１ベアラとして特定可能な情報を通知してもよい。ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）（既存Ｓ１ベアラ）を起動する。
ステップＳＴ１１２３９のＲＲＣ接続セットアップ処理（既存Ｓ１ベアラ）は、ステップＳＴ１１２４０〜ステップＳＴ１１２４２の処理を含む。
ステップＳＴ１１２４０において、ＵＥのＲＲＣレイヤは、ｅＮＢにＲＲＣ接続要求（RRC Connection Request）メッセージを送信する。 ＲＲＣ接続要求メッセージには、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している旨、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。
ステップＳＴ１１２４０でＲＲＣ接続要求メッセージを受信したｅＮＢは、ステップＳＴ１１２４１において、ＵＥのＲＲＣレイヤにＲＲＣ接続セットアップ（RRC Connection Setup）メッセージを送信する。ＲＲＣ接続セットアップメッセージには、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している旨、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。
ステップＳＴ１１２４１でＲＲＣ接続セットアップメッセージを受信したＵＥは、ステップＳＴ１１２４２において、ｅＮＢにＲＲＣ接続セットアップ完了（RRC Connection Setup Complete）メッセージを送信する。ＲＲＣ接続セットアップ完了メッセージには、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持している旨、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。
ステップＳＴ１１２４３において、対応する接続を用いて、ＵＥから、Ｐ−ＧＷ経由でアプリケーションサーバにデータが送信される。具体的には、対応するＥＰＳベアラ（EPS bearer）を用いて、データが送信される。
ステップ１１２４４において、ＵＥにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。ステップＳＴ１１２４４の処理の詳細は、ステップＳＴ１１２３０の処理と同様であるので、説明を省略する。
ステップＳＴ１１２４５において、ｅＮＢにおけるＲＲＣレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。ステップＳＴ１１２４５の処理の詳細は、ステップＳＴ１１２３１の処理と同様であるので、説明を省略する。
ステップＳＴ１１２４７において、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態となる。ステップＳＴ１１２４８において、ｅＮＢは、ＲＲＣ＿ＩＤＬＥ状態となり、ステップＳＴ１１２３５の処理と同様の処理を実行する。ステップＳＴ１１２３５と同様の処理を行うことによって、状態遷移判断結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させない場合は、Ｓ１リリース処理Ａが起動されないので、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤは維持される。
ステップＳＴ１１２４５において、ＵＥのアプリケーションから、ＮＡＳにデータの送信が要求され、送信データが送信される。ステップＳＴ１１２４５の処理の詳細は、ステップＳＴ１１２３８の処理と同様であるので、説明を省略する。
ステップＳＴ１１２４９において、ＵＥは、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）（既存Ｓ１ベアラ）を起動する。ステップＳＴ１１２４９の処理の詳細は、ステップＳＴ１１２３９の処理と同様であるので、説明を省略する。
ステップＳＴ１１２５０において、対応する接続を用いて、ＵＥから、Ｐ−ＧＷ経由でアプリケーションサーバにデータが送信される。具体的には、対応するＥＰＳベアラ（EPS bearer）を用いて、データが送信される。以下、前述の処理を繰り返す。
次に、図６２および図６３を用いて、実施の形態７における通信システムのシーケンスの具体例にについて説明する。図６２および図６３は、実施の形態７における通信システムのシーケンスの他の例を示す図である。図６２と図６３とは、境界線ＢＬ２５の位置で、つながっている。図６２および図６３では、状態遷移判断結果が、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないとして開設されたＳ１ベアラを、ＵＥ起点の解放手続きで開放する場合のシーケンスを示している。図６２および図６３に示すシーケンスは、図２７〜図２９および図５９〜図６１に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
図６３のステップＳＴ１１３２３において、ＵＥのアプリケーションから、ＵＥのＮＡＳに、サービス切断要求、あるいはサービスリリース要求が送信される。
ＵＥのＮＡＳは、ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持しているか否かを判断してもよい。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持していないと判断された場合は、ＵＥの状態をＲＲＣ＿ＩＤＬＥと、ＥＣＭ＿ＩＤＬＥとに遷移させる処理を実行する。ＥＣＭ＿ＣＯＮＮＥＣＴＥＤを維持していると判断された場合は、ステップＳＴ１１３２４に移行するようにしてもよい。
ステップＳＴ１１３２４において、ＵＥのＮＡＳは、ＡＳ（Access Stratum）に、ＮＡＳレベル（Ｓ１ベアラ）の接続のリリースを要求する。具体的には、ＮＡＳリリース要求（NAS Release Request）メッセージの送信を要求する。ＵＥのＮＡＳが、ＲＲＣレイヤに通知してもよい。
ステップＳＴ１１３２５において、ＵＥは、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）を行う。ＲＲＣ接続セットアップ処理の詳細は、ステップＳＴ９１０４と同様であるので、説明を省略する。あるいは、ステップＳＴ１１３２５において、ＵＥは、ＲＲＣ接続セットアップ処理（RRC Connection Setup Procedure）（既存Ｓ１ベアラ）を起動する。ＲＲＣ接続セットアップ処理（既存Ｓ１ベア）の詳細は、ステップＳＴ１１２３９の処理と同様であるので、説明を省略する。
ステップＳＴ１１３２６において、ＵＥは、ＮＡＳレベル（Ｓ１ベアラ）の接続のリリース要求をｅＮＢに送信する。具体的には、ＮＡＳリリース要求（NAS Release Request）メッセージを送信する。ＮＡＳリリース要求メッセージには、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。
ステップＳＴ１１３２６でＮＡＳリリース要求メッセージを受信したｅＮＢは、ステップＳＴ１１３２７において、ＭＭＥにＮＡＳリリース要求（NAS Release Request）メッセージを送信する。ＮＡＳリリース要求メッセージには、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。
ステップＳＴ１１３２７でＮＡＳリリース要求メッセージを受信したＭＭＥは、ステップＳＴ１１３２８において、該Ｓ１ベアラをリリースする処理を起動する。具体的には、Ｓ１リリース処理Ｂ（S1 Release Procedure B）を起動する。Ｓ１リリース処理ＢとＳ１リリース処理Ａとの違いは、Ｓ１リリース処理Ｂには、ｅＮＢ起点のＵＥコンテキストリリース要求（UE Context Release Request）が存在しないことである。
ステップＳＴ１１３２８のＳ１リリース処理Ｂは、ステップＳＴ１１３２９〜ステップＳＴ１１３３３の処理を含む。
ステップＳＴ１１３２９において、ＭＭＥは、Ｓ−ＧＷにアクセスベアラリリース要求（Release Access Bearers Request）メッセージを送信する。 アクセスベアラリリース要求メッセージには、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。あるいは、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないＳ１ベアラをリリースする処理である旨の情報が含まれていてもよい。
ステップＳＴ１１３２９でアクセスベアラリリース要求メッセージを受信したＳ−ＧＷは、ステップＳＴ１１３３０において、アクセスベアラリリース応答（Release Access Bearers Response）メッセージをＭＭＥに送信する。アクセスベアラリリース応答メッセージは、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。あるいは、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないＳ１ベアラをリリースする処理である旨の情報が含まれていてもよい。
ステップＳＴ１１３３０でアクセスベアラリリース応答メッセージを受信したＭＭＥは、ステップＳＴ１１３３１において、ＵＥコンテキストリリースコマンド（UE Context Release Command）をｅＮＢに送信する。ＵＥコンテキストリリースコマンドには、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。あるいは、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないＳ１ベアラをリリースする処理である旨の情報が含まれていてもよい。
ステップＳＴ１１３３１でＵＥコンテキストリリースコマンドを受信したｅＮＢは、ステップＳＴ１１３３２において、ＲＲＣ接続リリース（RRC Connection Release）メッセージをＵＥに通知する。
ステップＳＴ１１３３３において、ｅＮＢは、ＵＥコンテキストリリース完了（UE Context Release Complete）メッセージをＭＭＥに通知する。 ＵＥコンテキストリリース完了メッセージには、対応する接続に該当するＳ１ベアラを特定する情報が含まれていてもよい。あるいは、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないＳ１ベアラをリリースする処理である旨の情報が含まれていてもよい。
このような動作によって、ＲＲＣ独立ベアラに対して開設されたＳ１ベアラのタイマによる解放が可能となる。
次に、図６４および図６５を用いて、実施の形態７における通信システムのシーケンスの具体例について説明する。図６４および図６５は、実施の形態７における通信システムのシーケンスの他の例を示す図である。図６４と図６５とは、境界線ＢＬ２６の位置で、つながっている。図６４および図６５では、ＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させないとして開設されたＳ１ベアラのタイマによる解放手続で開放する場合のシーケンスを示している。図６４および図６５に示すシーケンスは、図２７〜図２９および図５９〜図６１に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
図６５のステップＳＴ１１４２３において、ＵＥにおけるＮＡＳレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。ＮＡＳレベルでのデータ未送信期間の計測は、状態遷移方法判断の結果がＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させなかった場合のＳ１ベアラが設定された場合のみとしてもよい。ステップＳＴ１１４２４において、ＵＥは、ＥＣＭ＿ＩＤＬＥ状態となる。
ステップＳＴ１１４２５において、ｅＮＢにおけるＮＡＳレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップＳＴ１１４２６に移行する。前記タイマが満了したことによって、対象のＵＥのＥＣＭ状態がＩＤＬＥになったと推定する。ＮＡＳレベルでのデータ未送信期間の計測は、状態遷移方法判断の結果がＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させなかった場合のＳ１ベアラが設定された場合のみとしてもよい。
ステップＳＴ１１４２６において、ｅＮＢは、Ｓ１リリース処理Ａ（S1 Release Procedure A）を起動する。ステップＳＴ１１４２６の処理の詳細は、図２９のステップＳＴ５１３４の処理と同様であるので、説明を省略する。
ステップＳＴ１１４２６の処理が完了すると、ステップＳＴ１１４２８において、ＭＭＥは、ＥＣＭ＿ＩＤＬＥ状態となる。
このような動作によって、状態遷移方法判断の結果がＲＲＣの状態と、ＥＣＭの状態とを連動して遷移させなかった場合のＳ１ベアラのタイマによる解放が可能となる。
以上の実施の形態７によって、以下の効果を得ることができる。ＮＡＳレベルの接続は維持したまま、無線区間の接続のみを解放および設定することを可能とする機構の実現が可能となる。
ＲＲＣの状態の遷移と上位ベアラ、例えばＳ１ベアラの設定とが独立化されるので、無線アクセスネットワークにおけるシステムリソース、具体的には無線リソースおよび通信ノードにおける処理負荷などを利用してしまうという問題、ならびにＵＥの消費電力を増加させるという問題を軽減することができる。また、前述の実施の形態６のようなＳ１ベアラのセットアップを含まず、ＲＲＣの接続のみで対応可能であるので、処理手順が簡易化される。
実施の形態７ 変形例１．
実施の形態７の変形例１で解決する課題を以下に説明する。前述の実施の形態７において、ＲＲＣ独立ベアラの開設時で、ＵＥがＲＲＣ＿ＩＤＬＥ状態でデータを送信する場合に、ＲＲＣ接続（RRC Connection）を開設する必要があった。しかしながら、小さいデータで、１パケットの伝送であることを想定すると、無線区間の接続を実行することは、通信端末装置の消費電力および無線リソースに影響が大きい。
前記の問題を解決するために、前述の実施の形態１の変形例４と同様の以下の対策を行う。コネクションライト（connection-lite）の場合において、小さいデータは、ＲＲＣ接続（RRC Connection）を開設せずに、ランダムアクセス手順内において、データを送信する。なお、送信手順は、前述の実施の形態１の変形例４と同様とする。
前記対策によって、ＲＲＣ接続（RRC Connection）を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
実施の形態７ 変形例２．
実施の形態７変形例２で解決する課題は、実施の形態７の変形例１と同様である。
前記の問題を解決するために、前述の実施の形態１の変形例５と同様の以下の対策を行う。コネクションライト（connection-lite）の場合において、小さいデータは、ＲＲＣ接続（RRC Connection）を開設せずに、ページング手順内において、データを送信する。なお、送信手順は、前述の実施の形態１の変形例５と同様とする。
前記対策によって、ＲＲＣ接続（RRC Connection）を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
実施の形態７ 変形例３．
実施の形態７の変形例３で解決する課題を以下に説明する。前述の実施の形態７およびその変形例１，２において、ＵＥとｅＮＢのＥＭＣ（ＲＲＣ）接続の状態を用いる場合は、前述の実施の形態２において挙げたＵＥとｅＮＢとの間での状態不一致の課題が発生し得る。
前記の問題を解決するために、前述の実施の形態２と同様に、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態においては、定期的に、「uu-keep-alive」の送信を行い、ネットワークにその状態を通知する機能を、前述の実施の形態６およびその変形例１〜３に追加する。なお、「uu-keep-alive」の送信手順は、前述の実施の形態２と同様とする。
本変形例によれば、ＵＥとｅＮＢとの間での状態不一致が軽減されるので、システムリソースに対する影響を軽減することができる。
この発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。
７１ 通信端末装置（ＵＥ）、７２ 基地局装置、７２−１ ｅＮＢ、７２−２ Ｈｏｍｅ−ｅＮＢ、７３ ＭＭＥ／Ｓ−ＧＷ部（ＭＭＥ部）、７４ ＨｅＮＢＧＷ。

Claims (4)

  1. ネットワークに接続される基地局装置と、前記基地局装置に無線通信可能に接続される通信端末装置とを備える通信システムであって、
    前記基地局装置と前記通信端末装置との間で、前記通信端末装置の状態を確認するためのモニタリング用メッセージを、予め定めるモニタリング周期で送受信し、
    前記基地局装置は、前記通信端末装置が検出されたかどうかを、前記モニタリング用メッセージが周辺基地局装置によって、前記予め定めるモニタリング周期内に受信されたかどうかに基づいて、判断する、
    ことを特徴とする通信システム。
  2. 前記モニタリング用メッセージは、前記基地局装置から前記通信端末装置に送信され、
    前記通信端末装置は、前記モニタリング用メッセージを受信すると、前記モニタリング用メッセージが送達されたことを示す送達確認用情報を前記基地局装置に送信することを特徴とする請求項１に記載の通信システム。
  3. 前記モニタリング用メッセージは、前記通信端末装置が無線リソース制御接続状態であることを通知するための状態通知用メッセージであり、
    前記通信端末装置は、前記無線リソース制御接続状態であるとき、前記状態通知用メッセージを前記基地局装置に送信することを特徴とする請求項１に記載の通信システム。
  4. 前記通信端末装置と前記基地局装置との間の通信は、コネクションライト（connection-lite）型通信と、コネクションオリエンテッド（connection-oriented）型通信とを切替え可能であり、
    前記コネクションライト型通信と、前記コネクションオリエンテッド型通信との切替えは、前記通信端末装置と前記基地局装置との間で送受信されるデータ量、または前記通信端末装置と前記基地局装置との間のトラフィック量に基づいて行われることを特徴とする請求項１に記載の通信システム。
JP2019217724A 2012-04-27 2019-12-02 通信システム Active JP6860644B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021052795A JP2021101583A (ja) 2012-04-27 2021-03-26 通信システム
JP2022186225A JP2023018061A (ja) 2012-04-27 2022-11-22 通信システム、移動端末、基地局、移動管理装置および関門装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012103541 2012-04-27
JP2012103541 2012-04-27

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2018120640A Division JP2018164306A (ja) 2012-04-27 2018-06-26 通信システム、移動端末、基地局、移動管理装置および関門装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2021052795A Division JP2021101583A (ja) 2012-04-27 2021-03-26 通信システム

Publications (2)

Publication Number Publication Date
JP2020036371A true JP2020036371A (ja) 2020-03-05
JP6860644B2 JP6860644B2 (ja) 2021-04-21

Family

ID=49483109

Family Applications (6)

Application Number Title Priority Date Filing Date
JP2014512599A Pending JPWO2013161798A1 (ja) 2012-04-27 2013-04-23 通信システム
JP2017165591A Ceased JP2017208862A (ja) 2012-04-27 2017-08-30 通信システム
JP2018120640A Pending JP2018164306A (ja) 2012-04-27 2018-06-26 通信システム、移動端末、基地局、移動管理装置および関門装置
JP2019217724A Active JP6860644B2 (ja) 2012-04-27 2019-12-02 通信システム
JP2021052795A Pending JP2021101583A (ja) 2012-04-27 2021-03-26 通信システム
JP2022186225A Pending JP2023018061A (ja) 2012-04-27 2022-11-22 通信システム、移動端末、基地局、移動管理装置および関門装置

Family Applications Before (3)

Application Number Title Priority Date Filing Date
JP2014512599A Pending JPWO2013161798A1 (ja) 2012-04-27 2013-04-23 通信システム
JP2017165591A Ceased JP2017208862A (ja) 2012-04-27 2017-08-30 通信システム
JP2018120640A Pending JP2018164306A (ja) 2012-04-27 2018-06-26 通信システム、移動端末、基地局、移動管理装置および関門装置

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2021052795A Pending JP2021101583A (ja) 2012-04-27 2021-03-26 通信システム
JP2022186225A Pending JP2023018061A (ja) 2012-04-27 2022-11-22 通信システム、移動端末、基地局、移動管理装置および関門装置

Country Status (5)

Country Link
US (4) US9832672B2 (ja)
EP (3) EP4243562A3 (ja)
JP (6) JPWO2013161798A1 (ja)
CN (3) CN108684079A (ja)
WO (1) WO2013161798A1 (ja)

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2638713B1 (en) * 2010-11-11 2019-02-20 Nokia Solutions and Networks Oy Method and apparatus for handling closed subscriber groups in relay-enhanced system
US20140038622A1 (en) * 2012-05-22 2014-02-06 Qualcomm Incorporated Methods and apparatus for efficient communication of small data amounts while in idle mode
US8923880B2 (en) * 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
JP6163006B2 (ja) * 2013-05-09 2017-07-12 株式会社Ｎｔｔドコモ 移動通信方法及び無線基地局
US9807818B2 (en) * 2013-08-08 2017-10-31 Industrial Technology Research Institute Method of radio bearer establishment in dual connectivity
CN104969619B (zh) * 2013-09-13 2020-01-31 华为技术有限公司 回程链路建立方法、基站、中继节点及系统
US10278232B2 (en) * 2013-09-20 2019-04-30 Qualcomm Incorporated Apparatus and method for handling out-of-sync and radio link failure with fractional DPCH calls
WO2015062008A1 (zh) * 2013-10-31 2015-05-07 华为技术有限公司 广播多播单频网络测量数据的传输方法和装置
US9743458B2 (en) * 2013-11-06 2017-08-22 Google Technology Holdings LLC Adaptive crowdsourced keep-alive interval determination
KR102275354B1 (ko) * 2014-02-17 2021-07-09 삼성전자 주식회사 기지국 및 기지국의 단말 연결 관리 방법
JP6403402B2 (ja) * 2014-03-12 2018-10-10 Kddi株式会社 通信装置、基地局装置、通信システムおよび通信方法
US9787439B2 (en) * 2014-04-04 2017-10-10 Mitsubishi Electric Corporation Data transmitting method, data receiving apparatus, data transmitting apparatus, base station, mobile station, data transmitting/receiving apparatus, and mobile communication system
CN106688266B (zh) * 2014-08-11 2020-08-25 Lg 电子株式会社 在无线通信系统中监测ue可达性的方法及用于其的设备
US9820184B2 (en) * 2014-09-23 2017-11-14 Qualcomm Incorporated Methods and apparatus for secure connectionless uplink small data transmission
CN109041271B (zh) * 2014-10-02 2020-11-03 宏达国际电子股份有限公司 网络节点
US10694496B2 (en) 2014-11-07 2020-06-23 Samsung Electronics Co., Ltd. Method and apparatus for transmitting group message to user equipment (UE)
JP2016144180A (ja) * 2015-02-05 2016-08-08 富士通株式会社 無線通信システム
WO2016172521A1 (en) 2015-04-22 2016-10-27 Convida Wireless, Llc Small data usage enablement in 3gpp networks
US20180109977A1 (en) * 2015-04-27 2018-04-19 Telefonaktiebolaget Lm Ericsson (Publ) Load based signaling in a communication network
US9930516B2 (en) 2015-05-15 2018-03-27 Samsung Electronics Co., Ltd. UE monitoring configuration method and apparatus
CN105050111B (zh) * 2015-06-15 2018-05-18 上海斐讯数据通信技术有限公司 一种接入点向服务器报告终端接入状态的方法及系统
BR112018001437A2 (pt) * 2015-08-05 2018-09-11 Ipcom Gmbh & Co. Kg método de transferência de funcionalidade de controle operacional dentro de uma rede de frequência única
WO2017027124A1 (en) * 2015-08-13 2017-02-16 Intel IP Corporation Lightweight s-1 lite protocol design for cellular internet of things
US10285168B2 (en) * 2015-09-16 2019-05-07 Intel Corporation Systems and methods for elimination of PDCCH in resource allocation signaling for MTC devices
EP3145269A1 (en) * 2015-09-16 2017-03-22 Alcatel Lucent Method, devices and system for a hybrid bearer service
EP3378275B1 (en) 2015-12-21 2023-05-10 Sony Group Corporation Telecommunications apparatus and methods
CN106961653B (zh) * 2016-01-11 2021-06-08 中兴通讯股份有限公司 一种实现数据传输的方法、装置和系统
CN106961722B (zh) * 2016-01-12 2018-09-11 展讯通信（上海）有限公司 数据的传输方法及基站
CN107295637B (zh) * 2016-03-31 2019-09-17 电信科学技术研究院 一种寻呼方法、设备及系统
EP3446536B1 (en) 2016-04-21 2020-04-08 Telefonaktiebolaget LM Ericsson (publ) Status detection of rrc connection
WO2017193293A1 (zh) * 2016-05-10 2017-11-16 华为技术有限公司 数据传输的方法和设备
JP6612976B2 (ja) * 2016-05-13 2019-11-27 京セラ株式会社 ユーザ装置、プロセッサ、及び方法
US10299083B2 (en) * 2016-07-31 2019-05-21 Lg Electronics Inc. Method for providing continuity of MBMS service and device supporting the same
WO2018062249A1 (ja) * 2016-09-30 2018-04-05 京セラ株式会社 無線端末及び基地局
JP6817424B2 (ja) * 2016-09-30 2021-01-20 テレフオンアクチーボラゲット エルエム エリクソン（パブル） ユーザ機器、ｕｅ、状態のコアネットワーク認識
JP6888093B2 (ja) * 2016-12-22 2021-06-16 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 非連続受信用のデータ伝送方法及び装置
EP3562211A4 (en) * 2016-12-23 2020-09-23 Fujitsu Limited DATA SENDING / RECEIVING DEVICE AND PROCEDURES AND COMMUNICATION SYSTEM
CN108924893B (zh) * 2017-04-26 2020-12-25 中国移动通信有限公司研究院 一种承载释放方法、装置、mme及sae-gw
CN109547932B (zh) * 2017-08-15 2023-05-16 华为技术有限公司 一种通信方法及装置
CN110012535B (zh) * 2018-01-05 2022-06-07 中国移动通信有限公司研究院 跟踪区更新周期确定方法、用户设备和网络侧设备
WO2019141349A1 (en) * 2018-01-16 2019-07-25 Nokia Technologies Oy Communication system
US20190313311A1 (en) * 2018-04-09 2019-10-10 Mediatek Inc. Apparatuses, service networks, and methods for handling plmn-specific parameters for an inter-plmn handover
KR102544861B1 (ko) * 2018-05-24 2023-06-19 삼성전자 주식회사 무선 통신 시스템에서 단말의 전력 소모 감소 방법 및 장치
CN108901049B (zh) * 2018-06-28 2021-02-02 武汉虹信科技发展有限责任公司 一种用于sr过程恢复专有承载的方法
CN112788744B (zh) 2019-11-01 2022-04-12 维沃移动通信有限公司 连接处理方法及通信设备
US11716747B2 (en) 2021-04-02 2023-08-01 Nokia Technologies Oy Polling and keep-alive signals for multimedia broadcast multicast service
WO2023135935A1 (ja) * 2022-01-14 2023-07-20 ソニーグループ株式会社 端末およびその無線送信制御方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100459126B1 (ko) * 2002-01-09 2004-12-03 엘지전자 주식회사 통신망의 세션 유지 제어 방법
JP2008085829A (ja) 2006-09-28 2008-04-10 Oki Electric Ind Co Ltd 無線通信基地局、無線通信ネットワーク及び無線通信端末状況管理方法
US8477811B2 (en) * 2008-02-02 2013-07-02 Qualcomm Incorporated Radio access network (RAN) level keep alive signaling
US8331337B2 (en) 2008-04-18 2012-12-11 Nec Corporation Session management apparatus, communication system, and session clear-out method
ES2401400T3 (es) * 2008-06-24 2013-04-19 Telefonaktiebolaget Lm Ericsson (Publ) Servicio de información localizada
CN101931898B (zh) * 2009-06-26 2014-03-05 华为技术有限公司 用户面数据的传输方法、装置及系统
KR20140063902A (ko) * 2010-02-10 2014-05-27 블랙베리 리미티드 상태/모드 전이 방법 및 장치
CN101808407A (zh) 2010-03-02 2010-08-18 中兴通讯股份有限公司 一种无线通信装置及其网络连接方法
JP5593781B2 (ja) * 2010-03-30 2014-09-24 富士通株式会社 端末及び通信制御方法
EP2566277B1 (en) * 2010-04-28 2020-09-23 LG Electronics Inc. Method and apparatus for performing random access procedures in a wireless communication system
JP5524410B2 (ja) * 2010-05-11 2014-06-18 エヌイーシー ヨーロッパ リミテッド Ｌｔｅ／ｅｐｃネットワークにおけるｍｍｅの障害を処理する方法
US8762450B2 (en) * 2010-07-27 2014-06-24 Qualcomm Incorporated Apparatus and method for reducing frequent server messages
US9622286B2 (en) 2010-09-13 2017-04-11 Nokia Solutions And Networks Oy Reduced radio resource control connectivity
US8537829B2 (en) * 2010-09-15 2013-09-17 Cisco Technology, Inc. Paging control in communication networks
ES2729550T3 (es) * 2011-03-29 2019-11-04 Lg Electronics Inc Método para que un equipo de usuario transmita/reciba datos en un sistema de comunicación inalámbrica y aparato para el mismo
EP2557890B1 (en) * 2011-08-12 2019-07-17 BlackBerry Limited Simplified ue + enb messaging
CN102340754B (zh) * 2011-09-23 2014-07-23 电信科学技术研究院 数据发送和接收方法及设备

Also Published As

Publication number Publication date
JP2023018061A (ja) 2023-02-07
EP3407672A1 (en) 2018-11-28
CN104247556B (zh) 2018-06-08
JP2017208862A (ja) 2017-11-24
US20190090152A1 (en) 2019-03-21
JPWO2013161798A1 (ja) 2015-12-24
US20180070257A1 (en) 2018-03-08
CN108684080A (zh) 2018-10-19
JP2021101583A (ja) 2021-07-08
EP2844023A4 (en) 2015-12-02
EP4243562A3 (en) 2023-11-08
CN108684079A (zh) 2018-10-19
JP6860644B2 (ja) 2021-04-21
US20150092554A1 (en) 2015-04-02
US20230091559A1 (en) 2023-03-23
CN104247556A (zh) 2014-12-24
EP4243562A2 (en) 2023-09-13
EP2844023A1 (en) 2015-03-04
WO2013161798A1 (ja) 2013-10-31
US9832672B2 (en) 2017-11-28
JP2018164306A (ja) 2018-10-18

Similar Documents

Publication Publication Date Title
JP6860644B2 (ja) 通信システム
JP6633712B2 (ja) 通信システムおよび基地局
JP6366763B2 (ja) 通信システム、通信端末装置およびプライマリセル
US9820254B2 (en) Mobile communication system
JP7321322B2 (ja) 移動端末装置
CN105379346B (zh) 通信系统

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200106

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201124

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: 20210224

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210326

R150 Certificate of patent or registration of utility model

Ref document number: 6860644

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250