特表-13161798IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 三菱電機株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
【公報種別】再公表特許(A1)
(11)【国際公開番号】WO/0
(43)【国際公開日】2013年10月31日
【発行日】2015年12月24日
(54)【発明の名称】通信システム
(51)【国際特許分類】
   H04W 24/06 20090101AFI20151201BHJP
   H04W 40/24 20090101ALI20151201BHJP
【FI】
   H04W24/06
   H04W40/24
【審査請求】未請求
【予備審査請求】未請求
【全頁数】130
【出願番号】特願2014-512599(P2014-512599)
(21)【国際出願番号】PCT/0/0
(22)【国際出願日】2013年4月23日
(31)【優先権主張番号】特願2012-103541(P2012-103541)
(32)【優先日】2012年4月27日
(33)【優先権主張国】JP
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IS,JP,KE,KG,KM,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US,UZ,VC
(71)【出願人】
【識別番号】000006013
【氏名又は名称】三菱電機株式会社
(74)【代理人】
【識別番号】100088672
【弁理士】
【氏名又は名称】吉竹 英俊
(74)【代理人】
【識別番号】100088845
【弁理士】
【氏名又は名称】有田 貴弘
(72)【発明者】
【氏名】望月 満
(72)【発明者】
【氏名】前田 美保
(72)【発明者】
【氏名】宇賀 晋介
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067AA33
5K067AA43
5K067BB04
5K067BB21
5K067DD51
5K067EE02
5K067EE10
5K067FF16
5K067GG01
5K067LL15
(57)【要約】
本発明の通信システムでは、eNBとUEとの間で、UEの状態を確認するためのUEモニタリング用メッセージを、予め定めるUEモニタリング周期で送受信する。例えば、UEモニタリング周期1401,1405,1407,1409,1411で、UEモニタリング処理を実行し、UEからeNBにUEモニタリング用メッセージを送信する。eNBは、UEモニタリング用メッセージを受信すると、送達確認情報をUEに送信する。UEモニタリング周期は、例えばTAU周期1412よりも短い周期に設定される。これによって、TAU周期を長期化しても、UEモニタリング処理によってUEの状態を確認することができる。UEモニタリング用メッセージは、eNBからUEに送信するようにしてもよい。
【特許請求の範囲】
【請求項1】
ネットワークに接続される基地局装置と、前記基地局装置に無線通信可能に接続される通信端末装置とを備える通信システムであって、
前記基地局装置と前記通信端末装置との間で、前記通信端末装置の状態を確認するためのモニタリング用メッセージを、予め定めるモニタリング周期で送受信することを特徴とする通信システム。
【請求項2】
前記モニタリング用メッセージは、前記通信端末装置から前記基地局装置に送信され、
前記基地局装置は、前記通信端末装置から前記モニタリング用メッセージを受信したか否かに基づいて、前記通信端末装置の状態を判断することを特徴とする請求項1に記載の通信システム。
【請求項3】
前記モニタリング用メッセージは、前記基地局装置から前記通信端末装置に送信され、
前記通信端末装置は、前記モニタリング用メッセージを受信すると、前記モニタリング用メッセージが送達されたことを示す送達確認用情報を前記基地局装置に送信することを特徴とする請求項1に記載の通信システム。
【請求項4】
前記モニタリング用メッセージは、前記通信端末装置が無線リソース制御接続状態であることを通知するための状態通知用メッセージであり、
前記通信端末装置は、前記無線リソース制御接続状態であるとき、前記状態通知用メッセージを前記基地局装置に送信することを特徴とする請求項1に記載の通信システム。
【請求項5】
前記通信端末装置と前記基地局装置との間の通信は、コネクションライト(connection-lite)型通信と、コネクションオリエンテッド(connection-oriented)型通信とを切替え可能であり、
前記コネクションライト型通信と、前記コネクションオリエンテッド型通信との切替えは、前記通信端末装置と前記基地局装置との間で送受信されるデータ量、または前記通信端末装置と前記基地局装置との間のトラフィック量に基づいて行われることを特徴とする請求項1に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ネットワークに接続される基地局装置と、基地局装置と無線通信可能な通信端末装置とを備える通信システムに関する。
【背景技術】
【0002】
第3世代と呼ばれる通信方式のうち、W−CDMA(Wideband Code division Multiple Access)方式が、2001年から日本で商用サービスが開始されている。また、下りリンク(個別データチャネル、個別制御チャネル)にパケット伝送用のチャネル(High Speed-Downlink Shared Channel:HS−DSCH)を追加することにより、下りリンクを用いたデータ送信の更なる高速化を実現するHSDPA(High Speed Downlink Packet Access)のサービスが開始されている。さらに、上り方向のデータ送信をより高速化するために、HSUPA(High Speed Uplink Packet Access)方式についてもサービスが開始されている。W−CDMAは、移動体通信システムの規格化団体である3GPP(3rd Generation Partnership Project)により定められた通信方式であり、リリース10版の規格書がとりまとめられている。
【0003】
また、3GPPにおいて、W−CDMAとは別の通信方式として、無線区間についてはロングタームエボリューション(Long Term Evolution:LTE)と称し、コアネットワークおよび無線アクセスネットワーク(以下、まとめて、ネットワークとも称する)を含めたシステム全体構成については、システムアーキテクチャエボリューション(System Architecture Evolution:SAE)と称される新たな通信方式が検討されている。この通信方式は3.9G(3.9 Generation)システムとも呼ばれる。
【0004】
LTEでは、アクセス方式、無線のチャネル構成やプロトコルが、W−CDMA(HSDPA/HSUPA)とは全く異なるものになる。例えば、アクセス方式は、W−CDMAが符号分割多元接続(Code Division Multiple Access)を用いているのに対して、LTEは下り方向はOFDM(Orthogonal Frequency Division Multiplexing)、上り方向はSC−FDMA(Single Career Frequency Division Multiple Access)を用いる。また、帯域幅は、W−CDMAが5MHzであるのに対し、LTEでは1.4MHz,3MHz,5MHz,10MHz,15MHz,20MHzの中で基地局毎に選択可能となっている。また、LTEでは、W−CDMAとは異なり、回線交換を含まず、パケット通信方式のみになる。
【0005】
LTEでは、W−CDMAのコアネットワークであるGPRS(General Packet Radio Service)とは異なる新たなコアネットワークを用いて通信システムが構成されるので、LTEの無線アクセス網(無線アクセスネットワーク(radio access network))は、W−CDMA網とは別の独立した無線アクセス網として定義される。
【0006】
したがって、W−CDMAの通信システムと区別するために、LTEの通信システムでは、コアネットワークはEPC(Evolved Packet Core)と称され、無線アクセスネットワークはE−UTRAN(Evolved Universal Terrestrial Radio Access)と称される。また無線アクセスネットワークにおいて、通信端末装置である移動端末(User Equipment:UE)と通信を行う基地局(Base station)はeNB(E-UTRAN NodeB)と称される。また複数の基地局と制御データおよびユーザデータのやり取りを行う基地局制御装置(Radio Network Controller)の機能は、EPCが担う。EPCは、aGW(Access Gateway)とも称される。またEPCとE−UTRANとで構成されるシステムは、EPS(Evolved Packet System)と称される。
【0007】
LTEの通信システムでは、ユニキャスト(Unicast)サービスとE-MBMSサービス(Evolved Multimedia Broadcast Multicast Service)とが提供される。E−MBMSサービスとは、放送型マルチメディアサービスである。E−MBMSサービスは、単にMBMSと称される場合もある。E−MBMSサービスでは、複数の移動端末に対して、ニュースおよび天気予報、ならびにモバイル放送などの大容量放送コンテンツが送信される。これを1対多(Point to Multipoint)サービスともいう。
【0008】
3GPPでの、LTEシステムにおける全体的なアーキテクチャ(Architecture)に関する決定事項が、非特許文献1(4章)に記載されている。全体的なアーキテクチャについて図1を用いて説明する。図1は、LTE方式の通信システムの構成を示す説明図である。図1において、移動端末101に対する制御プロトコル、例えばRRC(Radio Resource Control)と、ユーザプレイン、例えばPDCP(Packet Data Convergence Protocol)、RLC(Radio Link Control)、MAC(Medium Access Control)、PHY(Physical layer)とが基地局102で終端するならば、E−UTRANは1つあるいは複数の基地局102によって構成される。
【0009】
基地局102は、移動管理エンティティ(Mobility Management Entity:MME)103から通知されるページング信号(Paging Signal、ページングメッセージ(paging messages)とも称される)のスケジューリング(Scheduling)および送信を行う。基地局102は、X2インタフェースにより、互いに接続される。また基地局102は、S1インタフェースによりEPC(Evolved Packet Core)に接続される。より明確には、基地局102は、S1_MMEインタフェースによりMME(Mobility Management Entity)103に接続され、S1_UインタフェースによりS−GW(Serving Gateway)104に接続される。
【0010】
MME103は、複数あるいは単数の基地局102へのページング信号の分配を行う。また、MME103は、待受け状態(Idle State)のモビリティ制御(Mobility control)を行う。MME103は、移動端末が待ち受け状態の際、および、アクティブ状態(Active State)の際に、トラッキングエリア(Tracking Area)リストの管理を行う。
【0011】
S−GW104は、一つまたは複数の基地局102とユーザデータの送受信を行う。S−GW104は、基地局間のハンドオーバの際、ローカルな移動性のアンカーポイント(Mobility Anchor Point)となる。EPCには、さらにP−GW(PDN Gateway)が存在する。P−GWは、ユーザ毎のパケットフィルタリングやUE−IDアドレスの割当などを行う。
【0012】
移動端末101と基地局102との間の制御プロトコルRRCは、報知(Broadcast)、ページング(paging)、RRC接続マネージメント(RRC connection management)などを行う。RRCにおける基地局と移動端末との状態として、RRC_IDLEと、RRC_CONNECTEDとがある。RRC_IDLEでは、PLMN(Public Land Mobile Network)選択、システム情報(System Information:SI)の報知、ページング(paging)、セル再選択(cell re-selection)、モビリティなどが行われる。RRC_CONNECTEDでは、移動端末はRRC接続(connection)を有し、ネットワークとのデータの送受信を行うことができる。またRRC_CONNECTEDでは、ハンドオーバ(Handover:HO)、隣接セル(Neighbour cell)のメジャメントなどが行われる。
【0013】
非特許文献1(5章)に記載される、3GPPでの、LTEシステムにおけるフレーム構成に関する決定事項について、図2を用いて説明する。図2は、LTE方式の通信システムで使用される無線フレームの構成を示す説明図である。図2において、1つの無線フレーム(Radio frame)は10msである。無線フレームは10個の等しい大きさのサブフレーム(Subframe)に分割される。サブフレームは、2個の等しい大きさのスロット(slot)に分割される。無線フレーム毎に1番目および6番目のサブフレームに下り同期信号(Downlink Synchronization Signal:SS)が含まれる。同期信号には、第一同期信号(Primary Synchronization Signal:P−SS)と、第二同期信号(Secondary Synchronization Signal:S−SS)とがある。
【0014】
サブフレーム単位で、MBSFN(Multimedia Broadcast multicast service Single Frequency Network)用のチャネルと、MBSFN以外用のチャネルとの多重が行われる。MBSFN送信(MBSFN Transmission)とは、同時に複数のセルから同じ波形の送信により実現される同時放送送信技術(simulcast transmission technique)である。MBSFN領域(MBSFN Area)の複数のセルからのMBSFN送信は、移動端末には、1つの送信と認識される。MBSFNとは、このようなMBSFN送信をサポートするネットワークである。以降、MBSFN送信用のサブフレームをMBSFNサブフレーム(MBSFN subframe)と称する。
【0015】
非特許文献2に、MBSFNサブフレームの割り当て時のシグナリング例が記載されている。図3は、MBSFNフレームの構成を示す説明図である。図3に示すように、割当周期(radio Frame Allocation Period)毎にMBSFNサブフレームを含む無線フレームが割り当てられる。MBSFNサブフレームは、割当周期と割当オフセット(radio Frame Allocation Offset)とによって定義された無線フレームにてMBSFNのために割り当てられるサブフレームであり、マルチメディアデータを伝送するためのサブフレームである。以下の式(1)を満たす無線フレームが、MBSFNサブフレームを含む無線フレームである。
SFN mod radioFrameAllocationPeriod=radioFrameAllocationOffset …(1)
【0016】
MBSFNサブフレームの割当は6ビットにて行われる。1番左のビットは、サブフレームの2番目(#1)のMBSFN割当を定義する。左から2番目のビットはサブフレームの3番目(#2)、左から3番目のビットはサブフレームの4番目(#3)、左から4番目のビットはサブフレームの7番目(#6)、左から5番目のビットはサブフレームの8番目(#7)、左から6番目のビットはサブフレームの9番目(#8)のMBSFN割当を定義する。該ビットが「1」を示す場合、対応するサブフレームがMBSFNのために割当てられることを示す。
【0017】
3GPPでの、LTEシステムにおけるチャネル構成に関する決定事項が、非特許文献1(5章)に記載されている。CSG(Closed Subscriber Group)セルにおいてもnon−CSGセルと同じチャネル構成が用いられると想定されている。物理チャネル(Physical channel)について、図4を用いて説明する。図4は、LTE方式の通信システムで使用される物理チャネルを説明する説明図である。
【0018】
図4において、物理報知チャネル(Physical Broadcast channel:PBCH)401は、基地局102から移動端末101への下り送信用のチャネルである。BCHトランスポートブロック(transport block)は、40ms間隔中の4個のサブフレームにマッピングされる。40msタイミングの明白なシグナリングはない。
【0019】
物理制御チャネルフォーマットインジケータチャネル(Physical Control Format Indicator Channel:PCFICH)402は、基地局102から移動端末101への下り送信用のチャネルである。PCFICHは、PDCCHsのために用いるOFDMシンボルの数について基地局102から移動端末101へ通知する。PCFICHは、サブフレーム毎に送信される。
【0020】
物理下り制御チャネル(Physical Downlink Control Channel:PDCCH)403は、基地局102から移動端末101への下り送信用のチャネルである。PDCCHは、後述の図5に示されるトランスポートチャネルの1つである下り共有チャネル(Downlink Shared Channel:DL−SCH)のリソース割り当て(allocation)情報、図5に示されるトランスポートチャネルの1つであるページングチャネル(Paging Channel:PCH)のリソース割り当て(allocation)情報、DL−SCHに関するHARQ(Hybrid Automatic Repeat reQuest)情報を通知する。PDCCHは、上りスケジューリンググラント(Uplink Scheduling Grant)を運ぶ。PDCCHは、上り送信に対する応答信号であるAck(Acknowledgement)/Nack(Negative Acknowledgement)を運ぶ。PDCCHは、L1/L2制御信号とも呼ばれる。
【0021】
物理下り共有チャネル(Physical Downlink Shared Channel:PDSCH)404は、基地局102から移動端末101への下り送信用のチャネルである。PDSCHには、トランスポートチャネルである下り共有チャネル(DL−SCH)、およびトランスポートチャネルであるPCHがマッピングされている。
【0022】
物理マルチキャストチャネル(Physical Multicast Channel:PMCH)405は、基地局102から移動端末101への下り送信用のチャネルである。PMCHには、トランスポートチャネルであるマルチキャストチャネル(Multicast Channel:MCH)がマッピングされている。
【0023】
物理上り制御チャネル(Physical Uplink Control Channel:PUCCH)406は、移動端末101から基地局102への上り送信用のチャネルである。PUCCHは、下り送信に対する応答信号(response signal)であるAck/Nackを運ぶ。PUCCHは、CQI(Channel Quality Indicator)レポートを運ぶ。CQIとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またPUCCHは、スケジューリングリクエスト(Scheduling Request:SR)を運ぶ。
【0024】
物理上り共有チャネル(Physical Uplink Shared Channel:PUSCH)407は、移動端末101から基地局102への上り送信用のチャネルである。PUSCHには、図5に示されるトランスポートチャネルの1つである上り共有チャネル(Uplink Shared Channel:UL−SCH)がマッピングされている。
【0025】
物理HARQインジケータチャネル(Physical Hybrid ARQ Indicator Channel:PHICH)408は、基地局102から移動端末101への下り送信用のチャネルである。PHICHは、上り送信に対する応答信号であるAck/Nackを運ぶ。物理ランダムアクセスチャネル(Physical Random Access Channel:PRACH)409は、移動端末101から基地局102への上り送信用のチャネルである。PRACHは、ランダムアクセスプリアンブル(random access preamble)を運ぶ。
【0026】
下り参照信号(リファレンスシグナル(Reference Signal):RS)は、移動体通信システムとして既知のシンボルである。以下の5種類の下りリファレンスシグナルが定義されている。セル固有参照信号(Cell-specific Reference Signals:CRS)、MBSFN参照信号(MBSFN reference signals)、UE固有参照信号(UE-specific reference signals)であるデータ復調用参照信号(Demodulation Reference Signal:DM−RS)、位置決定参照信号(Positioning Reference Signals:PRS)、チャネル情報参照信号(Channel-State Information Reference Signals:CSI−RS)。移動端末の物理レイヤの測定として、リファレンスシグナルの受信電力(Reference Signal Received Power:RSRP)測定がある。
【0027】
非特許文献1(5章)に記載されるトランスポートチャネル(Transport channel)について、図5を用いて説明する。図5は、LTE方式の通信システムで使用されるトランスポートチャネルを説明する説明図である。図5(A)には、下りトランスポートチャネルと下り物理チャネルとの間のマッピングを示す。図5(B)には、上りトランスポートチャネルと上り物理チャネルとの間のマッピングを示す。
【0028】
図5(A)に示す下りトランスポートチャネルのうち、報知チャネル(Broadcast Channel:BCH)は、その基地局(セル)のカバレッジ全体に報知される。BCHは、物理報知チャネル(PBCH)にマッピングされる。
【0029】
下り共有チャネル(Downlink Shared Channel:DL−SCH)には、HARQ(Hybrid ARQ)による再送制御が適用される。DL−SCHは、基地局(セル)のカバレッジ全体への報知が可能である。DL−SCHは、ダイナミックあるいは準静的(Semi-static)なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング(Persistent Scheduling)ともいわれる。DL−SCHは、移動端末の低消費電力化のために移動端末の間欠受信(Discontinuous reception:DRX)をサポートする。DL−SCHは、物理下り共有チャネル(PDSCH)へマッピングされる。
【0030】
ページングチャネル(Paging Channel:PCH)は、移動端末の低消費電力を可能とするために移動端末のDRXをサポートする。PCHは、基地局(セル)のカバレッジ全体への報知が要求される。PCHは、動的にトラフィックに利用できる物理下り共有チャネル(PDSCH)のような物理リソースへマッピングされる。
【0031】
マルチキャストチャネル(Multicast Channel:MCH)は、基地局(セル)のカバレッジ全体への報知に使用される。MCHは、マルチセル送信におけるMBMSサービス(MTCHとMCCH)のSFN合成をサポートする。MCHは、準静的なリソース割り当てをサポートする。MCHは、PMCHへマッピングされる。
【0032】
図5(B)に示す上りトランスポートチャネルのうち、上り共有チャネル(Uplink Shared Channel:UL−SCH)には、HARQ(Hybrid ARQ)による再送制御が適用される。UL−SCHは、ダイナミックあるいは準静的(Semi-static)なリソース割り当てをサポートする。UL−SCHは、物理上り共有チャネル(PUSCH)へマッピングされる。
【0033】
図5(B)に示されるランダムアクセスチャネル(Random Access Channel:RACH)は、制御情報に限られている。RACHは、衝突のリスクがある。RACHは、物理ランダムアクセスチャネル(PRACH)へマッピングされる。
【0034】
HARQについて説明する。HARQとは、自動再送要求(Automatic Repeat reQuest:ARQ)と誤り訂正(Forward Error Correction)との組合せにより、伝送路の通信品質を向上させる技術である。HARQには、通信品質が変化する伝送路に対しても、再送により誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。
【0035】
再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればCRC(Cyclic Redundancy Check)エラーが発生した場合(CRC=NG)、受信側から送信側へ「Nack」を送信する。「Nack」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればCRCエラーが発生しない場合(CRC=OK)、受信側から送信側へ「Ack」を送信する。「Ack」を受信した送信側は次のデータを送信する。
【0036】
HARQ方式の一例として、チェースコンバイニング(Chase Combining)がある。チェースコンバイニングとは、初送と再送とにおいて、同じデータを送信するものであり、再送において初送のデータと再送のデータとの合成を行うことで、利得を向上させる方式である。チェースコンバイニングは、初送データに誤りがあったとしても、部分的に正確なものも含まれており、正確な部分の初送データと再送データとを合成することで、より高精度にデータを送信できるという考え方に基づいている。また、HARQ方式の別の例として、IR(Incremental Redundancy)がある。IRとは、冗長度を増加させるものであり、再送においてパリティビットを送信することで、初送と組合せて冗長度を増加させ、誤り訂正機能により品質を向上させるものである。
【0037】
非特許文献1(6章)に記載される論理チャネル(ロジカルチャネル:Logical channel)について、図6を用いて説明する。図6は、LTE方式の通信システムで使用される論理チャネルを説明する説明図である。図6(A)には、下りロジカルチャネルと下りトランスポートチャネルとの間のマッピングを示す。図6(B)には、上りロジカルチャネルと上りトランスポートチャネルとの間のマッピングを示す。
【0038】
報知制御チャネル(Broadcast Control Channel:BCCH)は、報知システム制御情報のための下りチャネルである。論理チャネルであるBCCHは、トランスポートチャネルである報知チャネル(BCH)、あるいは下り共有チャネル(DL−SCH)へマッピングされる。
【0039】
ページング制御チャネル(Paging Control Channel:PCCH)は、ページング情報(Paging Information)およびシステム情報(System Information)の変更を送信するための下りチャネルである。PCCHは、移動端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるPCCHは、トランスポートチャネルであるページングチャネル(PCH)へマッピングされる。
【0040】
共有制御チャネル(Common Control Channel:CCCH)は、移動端末と基地局との間の送信制御情報のためのチャネルである。CCCHは、移動端末がネットワークとの間でRRC接続(connection)を有していない場合に用いられる。下り方向では、CCCHは、トランスポートチャネルである下り共有チャネル(DL−SCH)へマッピングされる。上り方向では、CCCHは、トランスポートチャネルである上り共有チャネル(UL−SCH)へマッピングされる。
【0041】
マルチキャスト制御チャネル(Multicast Control Channel:MCCH)は、1対多の送信のための下りチャネルである。MCCHは、ネットワークから移動端末への1つあるいはいくつかのMTCH用のMBMS制御情報の送信のために用いられる。MCCHは、MBMS受信中の移動端末のみに用いられる。MCCHは、トランスポートチャネルであるマルチキャストチャネル(MCH)へマッピングされる。
【0042】
個別制御チャネル(Dedicated Control Channel:DCCH)は、1対1にて、移動端末とネットワークとの間の個別制御情報を送信するチャネルである。DCCHは、移動端末がRRC接続(connection)である場合に用いられる。DCCHは、上りでは上り共有チャネル(UL−SCH)へマッピングされ、下りでは下り共有チャネル(DL−SCH)にマッピングされる。
【0043】
個別トラフィックチャネル(Dedicated Traffic Channel:DTCH)は、ユーザ情報の送信のための個別移動端末への1対1通信のチャネルである。DTCHは、上りおよび下りともに存在する。DTCHは、上りでは上り共有チャネル(UL−SCH)へマッピングされ、下りでは下り共有チャネル(DL−SCH)へマッピングされる。
【0044】
マルチキャストトラフィックチャネル(Multicast Traffic channel:MTCH)は、ネットワークから移動端末へのトラフィックデータ送信のための下りチャネルである。MTCHは、MBMS受信中の移動端末のみに用いられるチャネルである。MTCHは、マルチキャストチャネル(MCH)へマッピングされる。
【0045】
CGIとは、セルグローバル識別子(Cell Global Identification)のことである。ECGIとは、E−UTRANセルグローバル識別子(E-UTRAN Cell Global Identification)のことである。LTE、後述のLTE−A(Long Term Evolution Advanced)およびUMTS(Universal Mobile Telecommunication System)において、CSG(Closed Subscriber Group)セルが導入される。CSGセルについて以下に説明する(非特許文献3 3.1章参照)。
【0046】
CSG(Closed Subscriber Group)セルとは、利用可能な加入者をオペレータが特定しているセル(以下「特定加入者用セル」という場合がある)である。特定された加入者は、PLMN(Public Land Mobile Network)の1つ以上のセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている1つ以上のセルを「CSGセル(CSG cell(s))」と呼ぶ。ただし、PLMNにはアクセス制限がある。
【0047】
CSGセルは、固有のCSGアイデンティティ(CSG identity:CSG ID;CSG−ID)を報知し、CSGインジケーション(CSG Indication)にて「TRUE」を報知するPLMNの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのCSG−IDを用いてCSGセルにアクセスする。
【0048】
CSG−IDは、CSGセルまたはセルによって報知される。移動体通信システムにCSG−IDは複数存在する。そして、CSG−IDは、CSG関連のメンバーのアクセスを容易にするために、移動端末(UE)によって使用される。
【0049】
移動端末の位置追跡は、1つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても移動端末の位置を追跡し、移動端末を呼び出す、換言すれば移動端末が着呼することを可能にするために行われる。この移動端末の位置追跡のための区域をトラッキングエリアと呼ぶ。
【0050】
CSGホワイトリスト(CSG White List)とは、加入者が属するCSGセルのすべてのCSG IDが記録されている、USIM(Universal Subscriber Identity Module)に格納されることもあるリストである。CSGホワイトリストは、単にホワイトリスト、あるいは許可CSGリスト(Allowed CSG List)と呼ばれることもある。CSGセルを通しての移動端末のアクセスは、MMEがアクセスコントロール(access control)を実行する(非特許文献4 4.3.1.2章参照)。移動端末のアクセスの具体例としては、アタッチ(attach)、コンバインドアタッチ(combined attach)、デタッチ(detach)、サービスリクエスト(service request)、トラッキングエリアアップデートプロシジャー(Tracking Area Update procedure)などがある(非特許文献4 4.3.1.2章参照)。
【0051】
待受け状態の移動端末のサービスタイプについて以下に説明する(非特許文献3 4.3章参照)。待受け状態の移動端末のサービスタイプとしては、制限されたサービス(Limited service、限られたサービスとも称される)、標準サービス(ノーマルサービス(Normal service))、オペレータサービス(Operator service)がある。制限されたサービスとは、後述のアクセプタブルセル上の緊急呼(Emergency calls)、ETWS(Earthquake and Tsunami Warning System)、CMAS(Commercial Mobile Alert System)である。標準サービス(通常サービスとも称される)とは、後述の適切なセル上の公共のサービスである。オペレータサービスとは、後述のリザーブセル上のオペレータのためのみのサービスである。
【0052】
「適切なセル(Suitable cell)」について以下に説明する。「適切なセル(Suitable cell)」とは、UEが通常(normal)サービスを受けるためにキャンプオン(Camp ON)するかもしれないセルである。そのようなセルは、以下の(1),(2)の条件を満たすものとする。
【0053】
(1)セルは、選択されたPLMNもしくは登録されたPLMN、または「Equivalent PLMNリスト」のPLMNの一部であること。
【0054】
(2)NAS(Non-Access Stratum)によって提供された最新情報にて、さらに以下の(a)〜(d)の条件を満たすこと。
(a)そのセルが禁じられた(barred)セルでないこと。
(b)そのセルが「ローミングのための禁止されたLAs」リストの一部でないトラッキングエリア(Tracking Area:TA)の一部であること。その場合、そのセルは前記(1)を満たす必要がある。
(c)そのセルが、セル選択評価基準を満たしていること。
(d)そのセルが、CSGセルとしてシステム情報(System Information:SI)によって特定されたセルに関しては、CSG−IDはUEの「CSGホワイトリスト」(CSG WhiteList)の一部であること、すなわちUEのCSG WhiteList中に含まれること。
【0055】
「アクセプタブルセル(Acceptable cell)」について以下に説明する。「アクセプタブルセル(Acceptable cell)」とは、UEが制限されたサービスを受けるためにキャンプオンするかもしれないセルである。そのようなセルは、以下の(1),(2)のすべての要件を充足するものとする。
【0056】
(1)そのセルが禁じられたセル(「バードセル(Barred cell)」とも称される)でないこと。
(2)そのセルが、セル選択評価基準を満たしていること。
【0057】
「バードセル(Barred cell)」は、システム情報で指示がある。「リザーブセル(Reserved cell)」は、システム情報で指示がある。
【0058】
「セルにキャンプオン(camp on)する」とは、UEがセル選択(cell selection)またはセル再選択(cell reselection)の処理を完了し、UEがシステム情報とページング情報とをモニタするセルを選択した状態になることをいう。UEがキャンプオンするセルを「サービングセル(Serving cell)」と称することがある。
【0059】
3GPPにおいて、Home−NodeB(Home−NB;HNB)、Home−eNodeB(Home−eNB;HeNB)と称される基地局が検討されている。UTRANにおけるHNB、およびE−UTRANにおけるHeNBは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献5には、HeNBおよびHNBへのアクセスの3つの異なるモードが開示されている。具体的には、オープンアクセスモード(Open access mode)と、クローズドアクセスモード(Closed access mode)と、ハイブリッドアクセスモード(Hybrid access mode)とが開示されている。
【0060】
各々のモードは、以下のような特徴を有する。オープンアクセスモードでは、HeNBおよびHNBは、通常のオペレータのノーマルセルとして操作される。クローズドアクセスモードでは、HeNBおよびHNBは、CSGセルとして操作される。このCSGセルは、CSGメンバーのみアクセス可能なCSGセルである。ハイブリッドアクセスモードでは、HeNBおよびHNBは、非CSGメンバーも同時にアクセス許可されているCSGセルとして操作される。言い換えれば、ハイブリッドアクセスモードのセル(ハイブリッドセルとも称する)は、オープンアクセスモードとクローズドアクセスモードとの両方をサポートするセルである。
【0061】
3GPPでは、全PCI(Physical Cell Identity)のうち、CSGセルで使用するためにネットワークによって予約されたPCI範囲がある(非特許文献1 10.5.1.1章参照)。PCI範囲を分割することをPCIスプリットと称することがある。PCIスプリットに関する情報(PCIスプリット情報とも称する)は、システム情報によって基地局から傘下の移動端末に対して報知される。基地局の傘下とは、該基地局をサービングセルとすることを意味する。
【0062】
非特許文献6は、PCIスプリットを用いた移動端末の基本動作を開示する。PCIスプリット情報を有していない移動端末は、全PCIを用いて、例えば504コード全てを用いて、セルサーチを行う必要がある。これに対して、PCIスプリット情報を有する移動端末は、当該PCIスプリット情報を用いてセルサーチを行うことが可能である。
【0063】
また3GPPでは、リリース10として、ロングタームエボリューションアドヴァンスド(Long Term Evolution Advanced:LTE−A)の規格策定が進められている(非特許文献7、非特許文献8参照)。
【0064】
LTE−Aシステムでは、高い通信速度、セルエッジでの高いスループット、新たなカバレッジエリアなどを得るために、リレー(Relay)およびリレーノード(Relay Node:RN)をサポートすることが検討されている。中継装置であるリレーノードは、ドナーセル(Donor cell、以下「ドナーeNB(Donor eNB;DeNB)」という場合がある)と呼ばれるセルを介して、無線アクセスネットワークに無線で接続される。ドナーセルの範囲内で、ネットワーク(Network:NW)からリレーノードへのリンクは、ネットワークからUEへのリンクと同じ周波数帯域(周波数バンド(band))を共用する。この場合、3GPPのリリース8対応のUEも該ドナーセルに接続可能とする。ドナーセルとリレーノードとの間のリンクをバックホールリンク(backhaul link)と称し、リレーノードとUEとの間のリンクをアクセスリンク(access link)と称する。
【0065】
FDD(Frequency Division Duplex)におけるバックホールリンクの多重方法として、DeNBからRNへの送信は下り(DL)周波数バンドで行われ、RNからDeNBへの送信は上り(UL)周波数バンドで行われる。リレーにおけるリソースの分割方法として、DeNBからRNへのリンクおよびRNからUEへのリンクが一つの周波数バンドで時分割多重され、RNからDeNBへのリンクおよびUEからRNへのリンクも一つの周波数バンドで時分割多重される。こうすることで、リレーにおいて、リレーの送信が自リレーの受信へ干渉することを防ぐことができる。
【0066】
3GPPでは、通常のeNB(マクロセル)だけでなく、ピコeNB(ピコセル(pico cell))、HeNB(HNB、CSGセル)、ホットゾーンセル用のノード、リレーノード、リモートラジオヘッド(Remote Radio Head:RRH)、リピータなどのいわゆるローカルノードが検討されている。前述のような各種タイプのセルからなるネットワークは、異機種ネットワーク(heterogeneous network、ヘットネット)と称されることもある。
【0067】
LTEでは、通信に使用可能な周波数バンド(以下「オペレーティングバンド」という場合がある)が予め決められている。非特許文献9には、該周波数バンドが記載されている。
【0068】
LTE−Aシステムでは、100MHzまでのより広い周波数帯域幅(transmission bandwidths)をサポートするために、二つ以上のコンポーネントキャリア(Component Carrier:CC)を集約する(アグリゲーション(aggregation)するとも称する)、キャリアアグリゲーション(Carrier Aggregation:CA)が検討されている。
【0069】
LTE対応である、3GPPのリリース8または9対応のUEは、一つのサービングセルに相当する一つのCC上のみで送受信可能である。これに対して、3GPPのリリース10対応のUEは、複数のサービングセルに相当する複数のCC上で同時に送受信、あるいは受信のみ、あるいは送信のみをするための能力(ケーパビリティ、capability)を有することが考えられている。
【0070】
各CCは、3GPPのリリース8または9の構成を用いており、CAは、連続CC、非連続CC、および異なる周波数帯域幅のCCをサポートする。UEが下りリンクのCC(DL CC)の個数以上の個数の、上りリンクのCC(UL CC)を構成することは不可能である。同一eNBから構成されるCCは、同じカバレッジを提供する必要は無い。CCは、3GPPのリリース8または9と互換性を有する。
【0071】
CAにおいて、上りリンク、下りリンクともに、サービングセル毎に一つの独立したHARQエンティティがある。トランスポートブロックは、サービングセル毎にTTI毎に生成される。各トランスポートブロックとHARQ再送とは、シングルサービングセルにマッピングされる。
【0072】
CAが構成される場合、UEはNWと唯一つのRRC接続(RRC connection)を有する。RRC接続において、一つのサービングセルがNASモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル(Primary Cell:PCell)と呼ぶ。下りリンクで、PCellに対応するキャリアは、下りプライマリコンポーネントキャリア(Downlink Primary Component Carrier:DL PCC)である。上りリンクで、PCellに対応するキャリアは、上りプライマリコンポーネントキャリア(Uplink Primary Component Carrier:UL PCC)である。
【0073】
UEの能力(ケーパビリティ(capability))に応じて、セカンダリセル(Secondary Cell:SCell)が、PCellとサービングセルとの組を形成するために構成される。下りリンクで、SCellに対応するキャリアは、下りセカンダリコンポーネントキャリア(Downlink Secondary Component Carrier:DL SCC)である。上りリンクで、SCellに対応するキャリアは、上りセカンダリコンポーネントキャリア(Uplink Secondary Component Carrier:UL SCC)である。
【0074】
一つのUEに対して、一つのPCellと、一つ以上のSCellからなるサービングセルとの組が構成される。
【0075】
3GPPにおいて、さらに進んだ新たな無線区間の通信方式として、前述のLTEアドヴァンスド(LTE Advanced:LTE−A)が検討されている(非特許文献7および非特許文献8参照)。LTE−Aは、LTEの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。新技術としては、より広い帯域をサポートする技術(Wider bandwidth extension)、および多地点協調送受信(Coordinated Multiple Point transmission and reception:CoMP)技術などがある。3GPPでLTE−Aのために検討されているCoMPについては、非特許文献10に記載されている。
【0076】
CoMPとは、地理的に分離された多地点間で協調した送信あるいは受信を行うことによって、高いデータレートのカバレッジの拡大、セルエッジでのスループットの向上、および通信システムにおけるスループットの増大を図る技術である。CoMPには、下りCoMP(DL CoMP)と、上りCoMP(UL CoMP)とがある。
【0077】
DL CoMPでは、一つの移動端末(UE)へのPDSCHを多地点(マルチポイント)間で協調して送信する。一つのUEへのPDSCHを、マルチポイントの一つのポイントから送信してもよいし、マルチポイントの複数のポイントから送信してもよい。DL CoMPにおいて、サービングセルとは、PDCCHによってリソース割当を送信する単独のセルである。
【0078】
DL CoMPの方法として、結合処理(Joint Processing:JP)と、協調スケジューリング(Coordinated Scheduling:CS)または協調ビームフォーミング(Coordinated Beamforming:CB)(以下「CS/CB」という場合がある)とが検討されている。
【0079】
JPは、CoMPコオペレーティングセット(CoMP cooperating set)中のそれぞれのポイントでデータが利用可能である。JPには、結合送信(Joint Transmission:JT)と、動的ポイント選択(Dynamic Point Selection:DPS)とがある。DPSは、動的セル選択(Dynamic Cell Selection:DCS)を含む。JTでは、ある時点で複数のポイント、具体的にはCoMPコオペレーティングセット(CoMP cooperating set)の一部あるいは全部から、PDSCHの送信が行われる。DPSでは、ある時点でCoMPコオペレーティングセット内の1つのポイントから、PDSCHの送信が行われる。
【0080】
CS/CBは、サービングセルからのデータ送信でのみ利用可能である。CS/CBでは、CoMPコオペレーティングセットに対応するセル間での調整と併せて、ユーザスケジューリングまたはビームフォーミングの決定がなされる。
【0081】
マルチポイントで送受信するポイントとしてユニットおよびセルが、ユニットおよびセルとして基地局(NB、eNB、HNB、HeNB)、RRU(Remote Radio Unit)、RRE(Remote Radio Equipment)、RRH(Remote Radio Head)、リレーノード(Relay Node:RN)などが検討されている。多地点協調送信を行うユニットおよびセルを、それぞれマルチポイントユニット、マルチポイントセルと称する場合がある。
【先行技術文献】
【非特許文献】
【0082】
【非特許文献1】3GPP TS36.300 V10.5.0
【非特許文献2】3GPP TS36.331 V10.3.0
【非特許文献3】3GPP TS36.304 V10.3.0 3.1章、4.3章、5.2.4章
【非特許文献4】3GPP TR 23.830 V9.0.0
【非特許文献5】3GPP S1−083461
【非特許文献6】3GPP R2−082899
【非特許文献7】3GPP TR 36.814 V9.0.0
【非特許文献8】3GPP TR 36.912 V10.0.0
【非特許文献9】3GPP TS 36.101 V10.3.0
【非特許文献10】3GPP TR 36.819 V11.0.0
【非特許文献11】3GPP TR 23.888 V1.6.0
【非特許文献12】3GPP TR 22.801 V12.0.0
【非特許文献13】3GPP TS 23.401 V11.0.0
【非特許文献14】3GPP TS 24.301 V11.1.0
【非特許文献15】3GPP R2−120444
【非特許文献16】3GPP S2−114341
【発明の概要】
【発明が解決しようとする課題】
【0083】
前述の3GPPの規格に代表されるセルラー系無線通信の発展により、その無線ネットワークを用いた様々な形態のアプリケーション間の通信が実行され、もしくは実行されようとしている。例えば、3GPPにおけるマシンタイプコミュニケーション((Machine Type Communication;略称:MTC)、およびIEEE802.3規格などの有線通信を想定したアプリケーションの通信などである。
【0084】
このようなアプリケーションは、従来の移動体通信における想定と異なる環境および形態で使用されるので、様々な課題および問題を引き起こす。
【0085】
例えば、MTCを行う通信端末装置(以下「MTC端末」という)は、使用環境として、ガスメータおよび動物などに設置されることが考えられている(非特許文献11参照)。その場合、MTC端末はバッテリによって駆動されることになるので、バッテリの交換および再充電が困難であることを想定する必要がある。したがって、通常の通信端末装置に比べて、一層の低消費電力化が必要となる。また、盗難および破壊などのリスクも考慮する必要があるので、MTC端末のモニタリングの必要性もある。
【0086】
また、MTCとは異なるアプリケーションでは、HTTP(HyperText Transfer Protocol)およびTCP(Transmission Control Protocol)を用いた通信などにおいて、通信のエンド−エンド(End−End)となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット(以下「keep-aliveパケット」という)を定期的に送信する場合がある(非特許文献12参照)。このとき、通信端末装置は、keep-aliveパケットを伝送するために、定期的に接続処理、具体的には発信処理を行う必要がある。
【0087】
この接続処理によって、無線アクセスネットワークにおけるシステムリソースを使用してしまい、無線リソースおよび通信ノードにおける処理負荷などの増加を招くという問題が発生している。また、定期的に接続処理を行うことは、通信端末装置における消費電力を増加させることにもつながる。
【0088】
本発明の目的は、処理負荷および消費電力を抑えて、通信端末装置の状態を確認することができる通信システムを提供することである。
【課題を解決するための手段】
【0089】
本発明の通信システムは、ネットワークに接続される基地局装置と、前記基地局装置に無線通信可能に接続される通信端末装置とを備える通信システムであって、前記基地局装置と前記通信端末装置との間で、前記通信端末装置の状態を確認するためのモニタリング用メッセージを、予め定めるモニタリング周期で送受信することを特徴とする。
【発明の効果】
【0090】
本発明の通信システムによれば、処理負荷および消費電力を抑えて、通信端末装置の状態を確認することができる。
【0091】
この発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
【図面の簡単な説明】
【0092】
図1】LTE方式の通信システムの構成を示す説明図である。
図2】LTE方式の通信システムで使用される無線フレームの構成を示す説明図である。
図3】MBSFNフレームの構成を示す説明図である。
図4】LTE方式の通信システムで使用される物理チャネルを説明する説明図である。
図5】LTE方式の通信システムで使用されるトランスポートチャネルを説明する説明図である。
図6】LTE方式の通信システムで使用される論理チャネルを説明する説明図である。
図7】3GPPにおいて議論されているLTE方式の移動体通信システムの全体的な構成を示すブロック図である。
図8】本発明に係る移動端末である図7に示す移動端末71の構成を示すブロック図である。
図9】本発明に係る基地局である図7に示す基地局72の構成を示すブロック図である。
図10】本発明に係るMMEである図7に示すMME部73の構成を示すブロック図である。
図11】本発明に係るHeNBGWである図7に示すHeNBGW74の構成を示すブロック図である。
図12】LTE方式の通信システムにおいて移動端末(UE)が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。
図13】LTE方式の通信システムにおいて周期的に実行するTAU処理のシーケンスの一例を示す図である。
図14】実施の形態1における通信システムのシーケンスの一例を示す図である。
図15】実施の形態1の変形例2における通信システムのシーケンスの一例を示す図である。
図16】ランダムアクセス処理のシーケンスの一例を示す図である。
図17】実施の形態1の変形例4における通信システムのシーケンスの一例を示す図である。
図18】実施の形態1の変形例4における通信システムのシーケンスの他の例を示す図である。
図19】LTE方式の通信システムにおけるページング処理のシーケンスの一例を示す図である。
図20】LTE方式の通信システムにおけるページング処理のシーケンスの一例を示す図である。
図21】実施の形態1の変形例5における通信システムのシーケンスの一例を示す図である。
図22】実施の形態1の変形例5における通信システムのシーケンスの一例を示す図である。
図23】実施の形態1の変形例5における通信システムのシーケンスの他の例を示す図である。
図24】実施の形態1の変形例5における通信システムのシーケンスの他の例を示す図である。
図25】実施の形態1の変形例5における通信システムのシーケンスの他の例を示す図である。
図26】実施の形態1の変形例5における通信システムのシーケンスの他の例を示す図である。
図27】実施の形態2で解決する課題を説明するためのシーケンスを示す図である。
図28】実施の形態2で解決する課題を説明するためのシーケンスを示す図である。
図29】実施の形態2で解決する課題を説明するためのシーケンスを示す図である。
図30】実施の形態2における通信システムのシーケンスの一例を示す図である。
図31】実施の形態3で解決する課題を説明するためのシーケンスを示す図である。
図32】実施の形態3で解決する課題を説明するためのシーケンスを示す図である。
図33】実施の形態3における通信システムのシーケンスの一例を示す図である。
図34】実施の形態3における通信システムのシーケンスの一例を示す図である。
図35】実施の形態3における通信システムのシーケンスの一例を示す図である。
図36】実施の形態3の変形例1における通信システムのシーケンスの一例を示す図である。
図37】実施の形態3の変形例1における通信システムのシーケンスの一例を示す図である。
図38】実施の形態4における通信システムのシーケンスの一例を示す図である。
図39】実施の形態4における通信システムのシーケンスの一例を示す図である。
図40】実施の形態4の変形例1における通信システムのシーケンスの一例を示す図である。
図41】実施の形態4の変形例1における通信システムのシーケンスの一例を示す図である。
図42】実施の形態5における通信システムのシーケンスの一例を示す図である。
図43】実施の形態5における通信システムのシーケンスの一例を示す図である。
図44】実施の形態6における通信システムのシーケンスの一例を示す図である。
図45】実施の形態6における通信システムのシーケンスの一例を示す図である。
図46】実施の形態6における通信システムのシーケンスの一例を示す図である。
図47】実施の形態6における通信システムのシーケンスの一例を示す図である。
図48】実施の形態6における通信システムのシーケンスの他の例を示す図である。
図49】実施の形態6における通信システムのシーケンスの他の例を示す図である。
図50】実施の形態6の変形例1で解決する課題を説明するためのシーケンスを示す図である。
図51】実施の形態6の変形例1で解決する課題を説明するためのシーケンスを示す図である。
図52】実施の形態6の変形例1における通信システムのシーケンスの一例を示す図である。
図53】実施の形態6の変形例1における通信システムのシーケンスの一例を示す図である。
図54】実施の形態6の変形例1における通信システムのシーケンスの他の例を示す図である。
図55】実施の形態6の変形例1における通信システムのシーケンスの他の例を示す図である。
図56】実施の形態6の変形例1における通信システムのシーケンスの他の例を示す図である。
図57】実施の形態7の課題を説明するためのシーケンスを示す図である。
図58】実施の形態7の課題を説明するためのシーケンスを示す図である。
図59】実施の形態7における通信システムのシーケンスの一例を示す図である。
図60】実施の形態7における通信システムのシーケンスの一例を示す図である。
図61】実施の形態7における通信システムのシーケンスの一例を示す図である。
図62】実施の形態7における通信システムのシーケンスの他の例を示す図である。
図63】実施の形態7における通信システムのシーケンスの他の例を示す図である。
図64】実施の形態7における通信システムのシーケンスの他の例を示す図である。
図65】実施の形態7における通信システムのシーケンスの他の例を示す図である。
【発明を実施するための形態】
【0093】
実施の形態1.
図7は、3GPPにおいて議論されているLTE方式の移動体通信システムの全体的な構成を示すブロック図である。3GPPにおいては、CSG(Closed Subscriber Group)セル(E−UTRANのHome−eNodeB(Home−eNB;HeNB)、UTRANのHome−NB(HNB))と、non−CSGセル(E−UTRANのeNodeB(eNB)、UTRANのNodeB(NB)、GERANのBSS)とを含めたシステムの全体的な構成が検討されており、E−UTRANについては、図7のような構成が提案されている(非特許文献1 4.6.1章参照)。
【0094】
図7について説明する。通信端末装置である移動端末装置(以下「移動端末(User Equipment:UE)」という)71は、基地局装置(以下「基地局」という)72と無線通信可能であり、無線通信で信号の送受信を行う。基地局72は、マクロセルであるeNB72−1と、ローカルノードであるHome−eNB72−2とに分類される。eNB72−1は、移動端末(UE)71と通信可能な範囲であるカバレッジとして、比較的大きい大規模カバレッジを有する。Home−eNB72−2は、カバレッジとして、比較的小さい小規模カバレッジを有する。
【0095】
eNB72−1は、MME、あるいはS−GW、あるいはMMEおよびS−GWを含むMME/S−GW部(以下「MME部」という場合がある)73とS1インタフェースにより接続され、eNB72−1とMME部73との間で制御情報が通信される。一つのeNB72−1に対して、複数のMME部73が接続されてもよい。MME部73は、コアネットワークであるEPCに含まれる。eNB72−1間は、X2インタフェースにより接続され、eNB72−1間で制御情報が通信される。
【0096】
Home−eNB72−2は、MME部73とS1インタフェースにより接続され、Home−eNB72−2とMME部73との間で制御情報が通信される。一つのMME部73に対して、複数のHome−eNB72−2が接続される。あるいは、Home−eNB72−2は、HeNBGW(Home-eNB GateWay)74を介してMME部73と接続される。Home−eNB72−2とHeNBGW74とは、S1インタフェースにより接続され、HeNBGW74とMME部73とはS1インタフェースを介して接続される。
【0097】
一つまたは複数のHome−eNB72−2が一つのHeNBGW74と接続され、S1インタフェースを通して情報が通信される。HeNBGW74は、一つまたは複数のMME部73と接続され、S1インタフェースを通して情報が通信される。
【0098】
MME部73およびHeNBGW74は、上位ノード装置であり、基地局であるeNB72−1およびHome−eNB72−2と、移動端末(UE)71との接続を制御する。MME部73およびHeNBGW74は、コアネットワークであるEPCに含まれる。
【0099】
さらに3GPPでは、以下のような構成が検討されている。Home−eNB72−2間のX2インタフェースはサポートされる。すなわち、Home−eNB72−2間は、X2インタフェースにより接続され、Home−eNB72−2間で制御情報が通信される。MME部73からは、HeNBGW74はHome−eNB72−2として見える。Home−eNB72−2からは、HeNBGW74はMME部73として見える。
【0100】
Home−eNB72−2が、HeNBGW74を介してMME部73に接続される場合および直接MME部73に接続される場合のいずれの場合も、Home−eNB72−2とMME部73との間のインタフェースは、S1インタフェースで同じである。HeNBGW74は、複数のMME部73にまたがるような、Home−eNB72−2へのモビリティ、あるいはHome−eNB72−2からのモビリティはサポートしない。Home−eNB72−2は、唯一のセルを構成し、サポートする。
【0101】
基地局装置は、例えばHome−eNB72−2のように唯一のセルをサポートするが、これに限定されず、1つの基地局装置が複数のセルをサポートしてもよい。1つの基地局装置が複数のセルをサポートする場合、1つ1つのセルが、基地局装置として機能する。
【0102】
図8は、本発明に係る移動端末である図7に示す移動端末71の構成を示すブロック図である。図8に示す移動端末71の送信処理を説明する。まず、プロトコル処理部801からの制御データ、およびアプリケーション部802からのユーザデータが、送信データバッファ部803へ保存される。送信データバッファ部803に保存されたデータは、エンコーダー部804へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部803から変調部805へ直接出力されるデータが存在してもよい。エンコーダー部804でエンコード処理されたデータは、変調部805にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部806へ出力され、無線送信周波数に変換される。その後、アンテナ807から基地局72に送信信号が送信される。
【0103】
また、移動端末71の受信処理は、以下のように実行される。基地局72からの無線信号がアンテナ807により受信される。受信信号は、周波数変換部806にて無線受信周波数からベースバンド信号に変換され、復調部808において復調処理が行われる。復調後のデータは、デコーダー部809へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部801へ渡され、ユーザデータはアプリケーション部802へ渡される。移動端末71の一連の処理は、制御部810によって制御される。よって制御部810は、図8では省略しているが、各部801〜809と接続している。
【0104】
図9は、本発明に係る基地局である図7に示す基地局72の構成を示すブロック図である。図9に示す基地局72の送信処理を説明する。EPC通信部901は、基地局72とEPC(MME部73、HeNBGW74など)との間のデータの送受信を行う。他基地局通信部902は、他の基地局との間のデータの送受信を行う。EPC通信部901および他基地局通信部902は、それぞれプロトコル処理部903と情報の受け渡しを行う。プロトコル処理部903からの制御データ、ならびにEPC通信部901および他基地局通信部902からのユーザデータおよび制御データは、送信データバッファ部904へ保存される。
【0105】
送信データバッファ部904に保存されたデータは、エンコーダー部905へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部904から変調部906へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部906にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部907へ出力され、無線送信周波数に変換される。その後、アンテナ908より一つもしくは複数の移動端末71に対して送信信号が送信される。
【0106】
また、基地局72の受信処理は以下のように実行される。一つもしくは複数の移動端末71からの無線信号が、アンテナ908により受信される。受信信号は、周波数変換部907にて無線受信周波数からベースバンド信号に変換され、復調部909で復調処理が行われる。復調されたデータは、デコーダー部910へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部903あるいはEPC通信部901、他基地局通信部902へ渡され、ユーザデータはEPC通信部901および他基地局通信部902へ渡される。基地局72の一連の処理は、制御部911によって制御される。よって制御部911は、図9では省略しているが、各部901〜910と接続している。
【0107】
3GPPにおいて議論されているHome−eNB72−2の機能を以下に示す(非特許文献1 4.6.2章参照)。Home−eNB72−2は、eNB72−1と同じ機能を有する。加えて、HeNBGW74と接続する場合、Home−eNB72−2は、適当なサービングHeNBGW74を発見する機能を有する。Home−eNB72−2は、1つのHeNBGW74に唯一接続する。つまり、HeNBGW74との接続の場合は、Home−eNB72−2は、S1インタフェースにおけるFlex機能を使用しない。Home−eNB72−2は、1つのHeNBGW74に接続されると、同時に別のHeNBGW74および別のMME部73に接続しない。
【0108】
Home−eNB72−2のTACとPLMN IDは、HeNBGW74によってサポートされる。Home−eNB72−2をHeNBGW74に接続すると、「UE attachment」でのMME部73の選択は、Home−eNB72−2の代わりに、HeNBGW74によって行われる。Home−eNB72−2は、ネットワーク計画なしで配備される可能性がある。この場合、Home−eNB72−2は、1つの地理的な領域から別の地理的な領域へ移される。したがって、この場合のHome−eNB72−2は、位置によって、異なったHeNBGW74に接続する必要がある。
【0109】
図10は、本発明に係るMMEの構成を示すブロック図である。図10では、前述の図7に示すMME部73に含まれるMME73aの構成を示す。PDN GW通信部1001は、MME73aとPDN GWとの間のデータの送受信を行う。基地局通信部1002は、MME73aと基地局72との間のS1インタフェースによるデータの送受信を行う。PDN GWから受信したデータがユーザデータであった場合、ユーザデータは、PDN GW通信部1001から、ユーザプレイン通信部1003経由で基地局通信部1002に渡され、1つあるいは複数の基地局72へ送信される。基地局72から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部1002から、ユーザプレイン通信部1003経由でPDN GW通信部1001に渡され、PDN GWへ送信される。
【0110】
PDN GWから受信したデータが制御データであった場合、制御データは、PDN GW通信部1001から制御プレイン制御部1005へ渡される。基地局72から受信したデータが制御データであった場合、制御データは、基地局通信部1002から制御プレイン制御部1005へ渡される。
【0111】
HeNBGW通信部1004は、HeNBGW74が存在する場合に設けられ、情報種別によって、MME73aとHeNBGW74との間のインタフェース(IF)によるデータの送受信を行う。HeNBGW通信部1004から受信した制御データは、HeNBGW通信部1004から制御プレイン制御部1005へ渡される。制御プレイン制御部1005での処理の結果は、PDN GW通信部1001経由でPDN GWへ送信される。また、制御プレイン制御部1005で処理された結果は、基地局通信部1002経由でS1インタフェースにより1つあるいは複数の基地局72へ送信され、またHeNBGW通信部1004経由で1つあるいは複数のHeNBGW74へ送信される。
【0112】
制御プレイン制御部1005には、NASセキュリティ部1005−1、SAEベアラコントロール部1005−2、アイドルステート(Idle State)モビリティ管理部1005―3などが含まれ、制御プレインに対する処理全般を行う。NASセキュリティ部1005―1は、NAS(Non-Access Stratum)メッセージのセキュリティなどを行う。SAEベアラコントロール部1005―2は、SAE(System Architecture Evolution)のベアラの管理などを行う。アイドルステートモビリティ管理部1005―3は、待受け状態(アイドルステート(Idle State);LTE−IDLE状態、または、単にアイドルとも称される)のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の1つあるいは複数の移動端末71のトラッキングエリア(TA)の追加、削除、更新、検索、トラッキングエリアリスト(TA List)管理などを行う。
【0113】
MME73aは、UEが登録されている(registered)追跡領域(トラッキングエリア:Tracking Area:TA)に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。MME73aに接続されるHome−eNB72−2のCSGの管理やCSG−IDの管理、そしてホワイトリスト管理は、アイドルステートモビリティ管理部1005―3で行ってもよい。
【0114】
CSG−IDの管理では、CSG−IDに対応する移動端末とCSGセルとの関係が管理(例えば追加、削除、更新、検索)される。この関係は、例えば、あるCSG−IDにユーザアクセス登録された一つまたは複数の移動端末と該CSG−IDに属するCSGセルとの関係であってもよい。ホワイトリスト管理では、移動端末とCSG−IDとの関係が管理(例えば追加、削除、更新、検索)される。例えば、ホワイトリストには、ある移動端末がユーザ登録した一つまたは複数のCSG−IDが記憶されてもよい。これらのCSGに関する管理は、MME73aの中の他の部分で行われてもよい。MME73aの一連の処理は、制御部1006によって制御される。よって制御部1006は、図10では省略しているが、各部1001〜1005と接続している。
【0115】
3GPPにおいて議論されているMME73aの機能を以下に示す(非特許文献1 4.6.2章参照)。MME73aは、CSG(Closed Subscriber Group)のメンバーの1つあるいは複数の移動端末のアクセスコントロールを行う。MME73aは、ページングの最適化(Paging optimization)の実行をオプションとして認める。
【0116】
図11は、本発明に係るHeNBGWである図7に示すHeNBGW74の構成を示すブロック図である。EPC通信部1101は、HeNBGW74とMME73aとの間のS1インタフェースによるデータの送受信を行う。基地局通信部1102は、HeNBGW74とHome−eNB72−2との間のS1インタフェースによるデータの送受信を行う。ロケーション処理部1103は、EPC通信部1101経由で渡されたMME73aからのデータのうちレジストレーション情報などを、複数のHome−eNB72−2に送信する処理を行う。ロケーション処理部1103で処理されたデータは、基地局通信部1102に渡され、一つまたは複数のHome−eNB72−2にS1インタフェースを介して送信される。
【0117】
ロケーション処理部1103での処理を必要とせず通過(透過)させるだけのデータは、EPC通信部1101から基地局通信部1102に渡され、一つまたは複数のHome−eNB72−2にS1インタフェースを介して送信される。HeNBGW74の一連の処理は、制御部1104によって制御される。よって制御部1104は、図11では省略しているが、各部1101〜1103と接続している。
【0118】
3GPPにおいて議論されているHeNBGW74の機能を以下に示す(非特許文献1 4.6.2章参照)。HeNBGW74は、S1アプリケーションについてリレーする。Home−eNB72−2へのMME73aの手順の一部分であるが、HeNBGW74は、移動端末71に関係しないS1アプリケーションについて終端する。HeNBGW74が配置されるとき、移動端末71に無関係な手順がHome−eNB72−2とHeNBGW74との間、そしてHeNBGW74とMME73aとの間を通信される。HeNBGW74と他のノードとの間でX2インタフェースは設定されない。HeNBGW74は、ページングの最適化(Paging optimization)の実行をオプションとして認める。
【0119】
次に移動体通信システムにおけるセルサーチ方法の一例を示す。図12は、LTE方式の通信システムにおいて移動端末(UE)が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップST1201で、周辺の基地局から送信される第一同期信号(P−SS)、および第二同期信号(S−SS)を用いて、スロットタイミング、フレームタイミングの同期をとる。
【0120】
P−SSとS−SSとを合わせて、同期信号(SS)という。同期信号(SS)には、セル毎に割り当てられたPCI(Physical Cell Identity)に1対1に対応するシンクロナイゼーションコードが割り当てられている。PCIの数は504通りが検討されている。この504通りのPCIを用いて同期をとるとともに、同期がとれたセルのPCIを検出(特定)する。
【0121】
次に同期がとれたセルに対して、ステップST1202で、基地局からセル毎に送信される参照信号(リファレンスシグナル:RS)であるセル固有参照信号(Cell-specific Reference Signal:CRS)を検出し、RSの受信電力(Reference Signal Received Power:RSRP)の測定を行う。参照信号(RS)には、PCIと1対1に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップST1201で特定したPCIから、該セルのRS用のコードを導出することによって、RSを検出し、RSの受信電力を測定することが可能となる。
【0122】
次にステップST1203で、ステップST1202までで検出された一つ以上のセルの中から、RSの受信品質が最もよいセル、例えば、RSの受信電力が最も高いセル、つまりベストセルを選択する。
【0123】
次にステップST1204で、ベストセルのPBCHを受信して、報知情報であるBCCHを得る。PBCH上のBCCHには、セル構成情報が含まれるMIB(Master Information Block)がマッピングされる。したがってPBCHを受信してBCCHを得ることで、MIBが得られる。MIBの情報としては、例えば、DL(ダウンリンク)システム帯域幅(送信帯域幅設定(transmission bandwidth configuration:dl-bandwidth)とも呼ばれる)、送信アンテナ数、SFN(System Frame Number)などがある。
【0124】
次にステップST1205で、MIBのセル構成情報をもとに該セルのDL−SCHを受信して、報知情報BCCHの中のSIB(System Information Block)1を得る。SIB1には、該セルへのアクセスに関する情報や、セルセレクションに関する情報、他のSIB(SIBk;k≧2の整数)のスケジューリング情報が含まれる。また、SIB1には、TAC(Tracking Area Code)が含まれる。
【0125】
次にステップST1206で、移動端末は、ステップST1205で受信したSIB1のTACと、移動端末が既に保有しているTA(Tracking Area)リスト内のトラッキングエリア識別子(Tracking Area Identity:TAI)のTAC部分とを比較する。TA(Tracking Area)リストは、TAIリスト(TAI list)とも称される。TAIはTAの識別子であり、MCC(Mobile Country Code)と、MNC(Mobile Network Code)と、TAC(Tracking Area Code)とによって構成される。MCCは国コードである。MNCはネットワークコードである。TACはTAのコード番号である。
【0126】
移動端末は、ステップST1206で比較した結果、ステップST1205で受信したTACがTA(Tracking Area)リスト内に含まれるTACと同じならば、該セルで待ち受け動作に入る。比較して、ステップST1205で受信したTACがTA(Tracking Area)リスト内に含まれなければ、移動端末は、該セルを通して、MMEなどが含まれるコアネットワーク(Core Network,EPC)へ、TAU(Tracking Area Update)を行うためにTA(Tracking Area)の変更を要求する。
【0127】
コアネットワークは、TAU要求信号とともに移動端末から送られてくる該移動端末の識別番号(UE−IDなど)をもとに、TA(Tracking Area)リストの更新を行う。コアネットワークは、移動端末に更新後のTA(Tracking Area)リストを送信する。移動端末は、受信したTA(Tracking Area)リストに基づいて、移動端末が保有するTACリストを書き換える(更新する)。その後、移動端末は、該セルで待ち受け動作に入る。
【0128】
LTE、LTE−AおよびUMTS(Universal Mobile Telecommunication System)においては、CSG(Closed Subscriber Group)セルの導入が検討されている。前述したように、CSGセルに登録した一つまたは複数の移動端末のみにアクセスが許される。CSGセルと登録された一つまたは複数の移動端末とが一つのCSGを構成する。このように構成されたCSGには、CSG−IDと呼ばれる固有の識別番号が付される。一つのCSGには、複数のCSGセルがあってもよい。移動端末は、どれか一つのCSGセルに登録すれば、そのCSGセルが属するCSGの他のCSGセルにアクセス可能となる。
【0129】
また、LTEおよびLTE−AでのHome−eNBやUMTSでのHome−NBが、CSGセルとして使われることがある。CSGセルに登録した移動端末は、ホワイトリストを有する。具体的には、ホワイトリストはSIM(Subscriber Identity Module)またはUSIMに記憶される。ホワイトリストには、移動端末が登録したCSGセルのCSG情報が格納される。CSG情報として具体的には、CSG−ID、TAI(Tracking Area Identity)、TACなどが考えられる。CSG−IDとTACとが対応付けられていれば、どちらか一方でよい。また、CSG−IDおよびTACと、ECGIとが対応付けられていれば、ECGIでもよい。
【0130】
以上から、ホワイトリストを有しない(本発明においては、ホワイトリストが空(empty)の場合も含める)移動端末は、CSGセルにアクセスすることは不可能であり、non−CSGセルのみにしかアクセスできない。一方、ホワイトリストを有する移動端末は、登録したCSG−IDのCSGセルにも、non−CSGセルにもアクセスすることが可能となる。
【0131】
HeNBおよびHNBに対しては、様々なサービスへの対応が求められている。例えば、あるサービスでは、オペレータは、ある決められたHeNBおよびHNBに移動端末を登録させ、登録した移動端末のみにHeNBおよびHNBのセルへのアクセスを許可することで、該移動端末が使用できる無線リソースを増大させて、高速に通信を行えるようにする。その分、オペレータは、課金料を通常よりも高く設定する。
【0132】
このようなサービスを実現するために、登録した(加入した、メンバーとなった)移動端末のみがアクセスできるCSG(Closed Subscriber Group)セルが導入されている。CSG(Closed Subscriber Group)セルは、商店街やマンション、学校、会社などへ数多く設置されることが要求される。例えば、商店街では店舗毎、マンションでは部屋毎、学校では教室毎、会社ではセクション毎にCSGセルを設置し、各CSGセルに登録したユーザのみが該CSGセルを使用可能とするような使用方法が要求されている。
【0133】
HeNB/HNBは、マクロセルのカバレッジ外での通信を補完するため(エリア補完型HeNB/HNB)だけでなく、上述したような様々なサービスへの対応(サービス提供型HeNB/HNB)が求められている。このため、HeNB/HNBがマクロセルのカバレッジ内に設置される場合も生じる。
【0134】
実施の形態1で解決する課題について、以下に再度説明する。MTCなどにおいては、低消費電力化を図るために、周期的に実行するLAU(Location Area Update)処理、RAU(Routing Area Update)処理およびTAU(Tracking Area Update)処理の長周期化の対策が開示されている(非特許文献11 6.20章参照)。
【0135】
図13は、LTE方式の通信システムにおいて周期的に実行するTAU処理のシーケンスの一例を示す図である(非特許文献13参照)。
【0136】
ステップST1301において、UEは、eNB経由でMMEに、TAU要求(TAU Request)メッセージを通知する。具体的には、UEは、NAS(Non-Access-Stratum)プロトコルを用いて、TAU要求メッセージを通知する(非特許文献14参照)。
【0137】
ステップST1302において、MMEは、HSS(Home Subscriber Server)の情報を用いて、UEの認証(authentication)およびセキュリティ(security)制御の処理を行う。
【0138】
ステップST1301でUEからのTAU要求メッセージを受信したMMEは、TAU要求を許可する場合、ステップST1303において、eNB経由でUEに、TAUアクセプト(TAU Accept)メッセージを通知する。具体的には、MMEは、NAS(Non-Access-Stratum)プロトコルを用いて、TAUアクセプトメッセージを通知する(非特許文献14参照)。
【0139】
ステップST1303でMMEからのTAUアクセプトメッセージを受信したUEは、ステップST1304において、eNB経由でMMEに、TAUコンプリート(TAU Complete)メッセージを通知する。具体的には、UEは、NAS(Non-Access-Stratum)プロトコルを用いて、TAUコンプリートメッセージを通知する(非特許文献14参照)。
【0140】
以上のステップST1301〜ステップST1304の処理をまとめてステップST1305とし、ステップST1305の処理を、TAU処理(TAU Procedure)と称することとする。
【0141】
例えば、周期TAUタイマ(periodic TAU Timer)の設定周期毎に、TAUを実行する場合について説明すると、以下のようになる。周期TAUタイマ(periodic TAU Timer)には、周期的に実行するTAUの周期が設定される。
【0142】
周期TAUタイマ(periodic TAU Timer)のTAUの周期1306が満了した場合、ステップST1307において、TAU処理(TAU Procedure)が実行される。ステップST1307では、前述のステップST1301〜ステップST1304の処理と同様の処理が行われる。
【0143】
また、周期TAUタイマ(periodic TAU Timer)のTAUの周期1308が満了した場合、ステップST1309において、TAU処理(TAU Procedure)が実行される。ステップST1309では、前述のステップST1301〜ステップST1304の処理と同様の処理が行われる。
【0144】
以下、同様にして、周期TAUタイマ(periodic TAU Timer)のTAUの周期1310が満了した場合、ステップST1311において、TAU処理(TAU Procedure)が実行される。周期TAUタイマ(periodic TAU Timer)のTAUの周期1312が満了した場合、ステップST1313において、TAU処理(TAU Procedure)が実行される。周期TAUタイマ(periodic TAU Timer)のTAUの周期1314が満了した場合、ステップST1315において、TAU処理(TAU Procedure)が実行される。
【0145】
次に、MTCなどの低消費電力化を図るために、周期的に実行するTAUの長周期化の対策が行われた場合について説明する。
【0146】
例えば、長周期TAUタイマ(long periodic TAU Timer)の設定周期毎に、TAUを実行する場合について説明すると、以下のようになる。長周期TAUタイマ(long periodic TAU Timer)には、周期的に実行するTAUの周期が設定される。長周期TAUタイマ(long periodic TAU Timer)に設定されるTAUの周期は、前述の周期TAUタイマ(periodic TAU Timer)に設定されるTAUの周期に比べて長い。
【0147】
長周期TAUタイマ(long periodic TAU Timer)のTAUの周期1316が満了した場合、ステップST1315において、TAU処理(TAU Procedure)が実行される。ステップST1315では、前述のステップST1301〜ステップST1304の処理と同様の処理が行われる。
【0148】
このように、周期的に実行するLAU処理、RAU処理およびTAU処理を長周期化することによって、例えば図13のステップST1307、ステップST1309、ステップST1311、およびステップST1313のTAU処理(TAU Procedure)を省略することが可能となる。これによって、MTCなどの低消費電力化を図ることができる。
【0149】
しかしながら、周期的に実行するLAU処理、RAU処理およびTAU処理を長周期化すると、例えば図13のステップST1307、ステップST1309、ステップST1311、およびステップST1313のTAU処理(TAU Procedure)において実行していた、ネットワークによるモニタリングまたは移動監視の処理が実行されないこととなる。したがって、モニタリングおよび移動監視の観点においては、悪影響があるという問題がある。
【0150】
実施の形態1での解決策を以下に示す。UEとeNBとの間におけるUEモニタリング用メッセージを設ける。UEは、周期的にUEモニタリング用メッセージをeNBへ送信する。eNBは、UEから周期内に、UEモニタリング用メッセージを受信した場合は、UE検出と判断する。eNBは、UEから周期内に、UEモニタリング用メッセージを受信しない場合は、UE不検出と判断する。このようにUEモニタリング用メッセージを用いることによって、TAU処理を長周期化した場合でも、モニタリングが必要な頻度でモニタリングを行うことが可能となる。
【0151】
以下の説明では、UEがeNBにUEモニタリング用メッセージを送信する周期を、「UEモニタリング周期」と称することもある。
【0152】
またUEが、タイマ満了後、あるいはタイマ満了を契機に、UEモニタリング用メッセージを送信するようにしてもよい。このタイマを、「UEモニタリングタイマ」と称することもある。
【0153】
以下、主にUEモニタリング周期を用いて説明するが、UEモニタリングタイマを用いることもできる。
【0154】
eNBは、UEから送信されるUEモニタリング用メッセージを受信した場合、送達確認情報をUEに送信してもよい。あるいは、eNBは、UEから周期内に、UEモニタリング用メッセージを受信した場合、送達確認情報をUEに送信してもよい。送達確認情報の具体例としては、RLCレイヤにおける応答メッセージ(ACK)がある。送達確認情報は、ステータスPDU(Status PDU)であってもよい。
【0155】
eNBは、UEモニタリング用メッセージを用いて、UEが存在するか否かの判断(以下「不検出判断」と称することもある)をしてもよい。eNBは、UEが存在しない、すなわちUE不検出と判断した場合、不検出処理を実行してもよい。
【0156】
不検出判断の具体例として、以下の(1)〜(7)の7つを開示する。
(1)eNBは、周期内にUEモニタリング用メッセージを受信しない場合は、UE不検出と判断する。eNBは、周期内にUEモニタリング用メッセージを受信した場合は、UEが存在する、すなわちUE検出と判断する。
【0157】
(2)eNBは、周期内にUEモニタリング用メッセージを受信しないことが、予め決められた回数連続して発生した場合は、不検出と判断する。予め決められた回数は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた回数を準静的に決定する場合は、eNBから、あるいはeNB経由で、UEに、予め決められた回数を通知すればよい。
【0158】
予め決められた回数の通知方法の具体例として、以下の(2−1)〜(2−4)の4つを開示する。
(2−1)報知情報によって通知する。
(2−2)個別情報によって通知する。
(2−3)TAU処理によって通知する。具体的には、TAUアクセプト(TAU Accept)メッセージなどによって通知する。
(2−4)アタッチ処理によって通知する。具体的には、アタッチアクセプト(Attach Accept)、RRC接続再設定(RRC Connection Reconfiguration)メッセージなどによって通知する。
【0159】
(3)eNBは、予め決められた期間内にUEモニタリング用メッセージを受信しない場合は、UE不検出と判断する。予め決められた期間は、UEがUEモニタリング用メッセージを送信する周期よりも長くすればよい。予め決められた期間は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた期間を準静的に決定する場合は、eNBから、あるいはeNB経由で、UEに、予め決められた期間を通知すればよい。予め決められた期間の通知方法の具体例は、前記不検出判断の具体例(2)における予め決められた回数の通知方法と同様であるので、説明を省略する。
【0160】
(4)周期的なLAU処理、RAU処理およびTAU処理と併用してもよい。eNBは、周期内にUEモニタリング用メッセージを受信した場合は、UE検出と判断する。eNBは、周期内にUEモニタリング用メッセージを受信しない場合は、MMEに通知する。MMEは、周期内にTAU処理が実行された場合は、UE検出と判断する。MMEは、周期内にTAU処理が実行されない場合は、UE不検出と判断する。これによって、eNBがUEモニタリング用メッセージを受信しない理由が、該eNBのカバレッジ外へのUEの移動である場合にも、MMEは適切に処理することができる。つまり、MMEは、適切にUE検出と判断することができる。
【0161】
(5)eNBは、周期内にUEモニタリング用メッセージを受信しない場合、周辺eNBに、その旨の通知(以下「UEモニタリング用メッセージパラメータ通知」と称する場合がある)を送信してもよい。UEモニタリング用メッセージパラメータ通知は、X2インタフェース、またはS1インタフェースを用いて、周辺eNBに送信されてもよい。
【0162】
UEモニタリング用メッセージパラメータ通知を受信した周辺eNBは、UEからのUEモニタリング用メッセージの受信を開始する。UEからのUEモニタリング用メッセージを受信した周辺eNBは、UEモニタリング用メッセージパラメータ通知を送信したeNBに、UEモニタリング用メッセージを受信した旨を通知する。UEからのUEモニタリング用メッセージを受信しない周辺eNBは、UEモニタリング用メッセージパラメータ通知を送信したeNBに、UEモニタリング用メッセージを受信しない旨を通知する。
【0163】
eNBは、周辺eNBから、UEモニタリング用メッセージを受信した旨の通知を受信した場合は、UE検出と判断する。また、eNBは、周辺eNBから、UEモニタリング用メッセージを受信しない旨の通知を受信した場合、あるいは周辺eNBから、UEモニタリング用メッセージを受信しない場合は、UE不検出と判断する。
【0164】
UEモニタリング用メッセージパラメータ通知の送信方法の具体例として、以下の(5−1),(5−2)の2つを開示する。
(5−1)新たにX2シグナル、またはX2メッセージを設ける。あるいは新たにS1シグナル、またはS1メッセージを設ける。
(5−2)既存のX2シグナル、またはX2メッセージを用いる。あるいは既存のS1シグナル、またはS1メッセージを設ける。本具体例(5−2)は、具体例(5−1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(5−2)によって、通信システムが複雑化することを回避することができる。
【0165】
X2シグナル、またはS1シグナルにマッピングするパラメータの具体例として、以下の(5−a)〜(5−d)の4つを開示する。
(5−a)該移動端末の識別番号(UE−IDなど)。
(5−b)該移動端末が、UEモニタリング用メッセージをeNBに送信するUEである旨。MTCである旨であってもよい。
(5−c)UEモニタリング周期。
(5−d)前記(5−a)〜(5−c)の組合せ。
【0166】
本具体例(5)によって、eNBがUEモニタリング用メッセージを受信しない理由が、該eNBのカバレッジ外へのUEの移動である場合にも、適切にUEを検出することができる。加えて、移動先のeNBにおいても、例えば周期などが同じ条件で、UEがUEモニタリング用メッセージの送信を継続することができるという効果を得ることができる。また、移動先のeNBとUEとが新たにパラメータのやり取りをすることなく、UEがUEモニタリング用メッセージの送信を継続することができ、制御遅延を防止することができるという効果を得ることができる。
【0167】
(6)前記(1)〜(5)においてUE不検出と判断した後に、該UE宛にページングを通知する。該UEから応答が有る場合は、UE検出と判断する。該UEから応答が無い場合は、UE不検出と判断する。
(7)前記(1)〜(6)の組合せ。
【0168】
不検出処理の具体例として、以下の(1)〜(3)の3つを開示する。
(1)eNBは、予め定められた通知先にUE不検出を通知する。予め定められた通知先の具体例としては、OAM(Operation Administration and Maintenance)、アプリケーションサーバ、およびMTCサーバなどがある。
(2)デタッチ処理を開始する。デタッチ処理をトリガとする。
(3)前記(1),(2)の組合せ。
【0169】
UEが、UEモニタリング用メッセージをeNBに通知する目的の具体例として、以下の(1)〜(4)の4つを開示する。
(1)「生きている」ことを相手に伝えるため。キープアライブ(keep alive)のため。
(2)存在することを相手に伝えるため。
(3)ダウンしていないことを伝えるため。正常に動作していることを伝えるため。
(4)前記(1)〜(3)の組合せ。
【0170】
UEモニタリング用メッセージの具体例として、以下の(1)〜(4)の4つを開示する。
(1)Uu点のみのメッセージとする。Uu点とは、UEとeNB、UEとHeNB、またはUEとRNのインタフェース点である。本具体例(1)では、TAUは、UEからMMEに通知されるので、Uu点とS1点に関わるメッセージとなる(図13のステップST1301、ステップST1302、ステップST1303、ステップST1304参照)。本具体例(1)によって、UEとeNBとの間の通信時間が短くなり、UEの低消費電力化が可能となる。
【0171】
(2)eNBの上位装置への通知が不要なメッセージとする。上位装置の具体例としては、MME、HSSなどである。本具体例(2)では、UEモニタリング用メッセージと異なり、TAUは、MMEおよびHSSへの通知が必要なメッセージとなる(図13のステップST1301、ステップST1302参照)。本具体例(2)によって、UEとeNBとの間の通信時間が短くなり、UEの低消費電力化が可能となる。
【0172】
(3)RRCメッセージとする。本具体例(3)では、UEモニタリング用メッセージと異なり、TAUは、NASメッセージとなる。
(4)前記(1)〜(3)の組合せ。
【0173】
UEモニタリング用メッセージをRRCメッセージとする場合の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにRRCシグナル、あるいはRRCメッセージを設ける。
(2)既存のRRCシグナル、あるいはRRCメッセージを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0174】
新たにRRCシグナルにマッピングするパラメータの具体例として、以下の(1)〜(4)の4つを開示する。
(1)UEモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨など。
【0175】
(2)UEの識別子。UEの識別子としては、移動端末識別子(UE−ID)でもよいし、国際移動加入者識別番号(International Mobile Subscriber Identity:IMSI)であってもよい。
【0176】
(3)シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、TAU処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
(4)前記(1)〜(3)の組合せ。
【0177】
次に、既存のRRCシグナルを用いる場合の具体例を開示する。メジャメントレポート(Measurement Report)メッセージを用いる。
【0178】
既存のRRCシグナリングに追加が必要なパラメータの具体例としては、UEモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨などがある。
【0179】
UEモニタリング用メッセージを、TAUの認証(authentication)処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、eNBにおいて、不正なUEの成りすましによるUEモニタリング用メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にTAUの認証(authentication)処理時に実行すればよい。
【0180】
また、メッセージ認証コード(Message Authentication Code)を付加して、メッセージ認証を実行してもよい。
【0181】
eNBにおいて、UEの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った処理(以下「不正UE検出処理」という)を実行してもよい。不正UE検出処理の具体例として、以下の(1)〜(3)の3つを開示する。
(1)eNBは、予め定められた通知先に不正UE検出を通知する。予め定められた通知先の具体例としては、OAM、アプリケーションサーバ、およびMTCサーバなどがある。
(2)デタッチ処理を開始する。デタッチ処理をトリガとする。
(3)前記(1),(2)の組合せ。
【0182】
UEモニタリング周期の設定方法の具体例として、以下の(1)〜(4)の4つを開示する。
(1)報知情報によって通知する。本具体例(1)によれば、UE毎に通知する必要がないので、無線リソースを有効に活用することができるという効果を得ることができる。
(2)個別情報によって通知する。本具体例(2)によって、UE毎に設定値を決定することができるので、柔軟な通信システムの構築が可能となる。
(3)TAU処理によって通知する。具体的には、TAUアクセプト(TAU Accept)メッセージなどによって通知する。
(4)アタッチ処理によって通知する。具体的には、アタッチアクセプト(Attach Accept)メッセージ、またはRRC接続再設定(RRC Connection Reconfiguration)などによって通知する。
【0183】
UEモニタリング周期と、周期的に実行するTAUの周期とが、同時に満了する場合の動作の具体例として、以下の(1),(2)の2つを開示する。
(1)UEモニタリング処理およびTAU処理の両方の処理を実行する。本具体例(1)によって、周期毎に処理を決定することができるので、制御の複雑性を回避することができるという効果を得ることができる。
【0184】
(2)UEモニタリング処理は実行せずに、TAU処理を実行するようにしてもよい。本具体例(2)によれば、UEは、UEモニタリング用メッセージの送信を行わなくてもよい。ネットワーク側のUEのモニタリングは、TAU処理によって実行することが可能であるので、UEモニタリング用メッセージの送信を省略することによって、UEの低消費電力化を図ることができるという効果を得ることができる。
【0185】
UEモニタリング周期、および周期的に実行するTAUの周期の設定値の具体例としては、周期TAUタイマ(periodic TAU timer)に設定される値が挙げられる。
【0186】
周期的に実行するTAUの周期は、UEモニタリング周期の整数倍としてもよく、整数の逆数倍(1/整数倍)としてもよい。これによって、UEモニタリング周期と、周期的に実行するTAUの周期とが同時に満了する機会が増え、UEの低消費電力化を図ることができるという効果が得られ易くなる。
【0187】
UEモニタリング周期の設定値の具体例として、以下の(1)〜(4)の4つを開示する。
(1)無線フレーム数。
(2)サブフレーム数。
(3)UEモニタリング周期を、周期的に実行するTAUの周期に対する整数倍、または整数の逆数倍(1/整数倍)とする場合において、「整数」をUEモニタリング周期の設定値とする。
(4)前記(1)〜(3)の組合せ。
【0188】
次に、図14を用いて、実施の形態1における通信システムのシーケンスの具体例について説明する。図14は、実施の形態1における通信システムのシーケンスの一例を示す図である。図14では、UEが、UEモニタリング周期毎に、UEモニタリング用メッセージを送信する場合のシーケンスを示している。図14に示すシーケンスは、図13に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0189】
ステップST1414において、前述のステップST1305と同様にして、TAU処理(TAU Procedure)が実行される。
【0190】
ステップST1402において、UEは、UEモニタリング周期1401で、eNBにUEモニタリング用メッセージを通知する。
【0191】
ステップST1402でUEモニタリング用メッセージを受信したeNBは、ステップST1403において、UEに送達確認情報を送信する。
【0192】
以上のステップST1402およびステップST1403の処理をまとめてステップST1404とし、ステップST1404の処理を、UEモニタリング処理と称することとする。
【0193】
ステップST1406において、UEとeNBとの間では、UEモニタリング周期1405で、UEモニタリング処理が実行される。
【0194】
またステップST1408において、UEとeNBとの間では、UEモニタリング周期1407で、UEモニタリング処理が実行される。
【0195】
またステップST1410において、UEとeNBとの間では、UEモニタリング周期1409で、UEモニタリング処理が実行される。
【0196】
UEモニタリング周期1411と、周期的に実行するTAUの周期1412とが同時に発生する場合は、ステップST1413において、TAU処理(TAU Procedure)が実行される。
【0197】
以上の実施の形態1によって、以下の効果を得ることができる。UEモニタリング処理を新たに設けることによって、周期的なTAU処理の周期を長期化しても、UEモニタリング処理によりモニタリング可能となる。
【0198】
UEモニタリング処理を、TAU処理と比較して低消費電力可能な構成とすることにより、低消費電力化を図ることができるという効果を得ることもできる。
【0199】
UEモニタリング周期と、TAUの周期とを別個に設定することができる。これにより、TAU処理の柔軟な運用が可能となる効果を得ることができる。
【0200】
以上のことによって、通信端末装置の低消費電力化とネットワークによるモニタリングおよび移動監視の適切な実現が可能となる。
【0201】
したがって、本実施の形態の通信システムによれば、処理負荷および消費電力を抑えて、UEの状態を確認することができる。
【0202】
また本実施の形態では、UEモニタリング用メッセージは、UEからeNBに送信され、eNBは、UEからUEモニタリング用メッセージを受信したか否かに基づいて、UEの状態を判断する。これによって、前述のように処理負荷および消費電力を抑えてUEの状態を確認することができる通信システムを実現することができる。
【0203】
実施の形態1 変形例1.
実施の形態1の変形例1では、前述の実施の形態1の更なる改善点について示す。本変形例では、前述の実施の形態1の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態1と同様とする。
【0204】
eNBは、UEからUEモニタリング用メッセージを受信した場合、UEモニタリング用メッセージに対する応答メッセージをUEに送信する。本変形例1では、応答メッセージに、暗号化(cipher)を施すようにすればよい。実施の形態1の送達確認情報が単純な確認メッセージ、例えばACK情報と比較して、本変形例1では、UEモニタリング用メッセージに対する暗号化を実行した応答メッセージを送信するので、UEによるeNBの成りすましを検出することが可能となる。
【0205】
UEモニタリング用メッセージに対する応答メッセージを、RRCメッセージとしてもよい。UEモニタリング用メッセージに対する応答メッセージをRRCメッセージとする場合の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにRRCシグナル、あるいはRRCメッセージを設ける。
(2)既存のRRCシグナル、あるいはRRCメッセージを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0206】
新たにRRCシグナルにマッピングするパラメータの具体例として、以下の(1)〜(4)の4つを開示する。
(1)UEモニタリング用メッセージに対する応答メッセージである旨。
(2)セルの識別子。具体的には、PCI、CGI、ECGIであってもよい。
【0207】
(3)シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、TAU処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
(4)前記(1)〜(3)の組合せ。
【0208】
次に、既存のRRCシグナルを用いる場合の具体例を開示する。RRC接続再設定「RRC Connection Reconfiguration」メッセージを用いる。
【0209】
既存のRRCシグナリングに追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。UEモニタリング用メッセージに対する応答メッセージである旨は、既存のRRCシグナリングに設定されている「理由(cause)」のパラメータに含めて通知されてもよい。
【0210】
UEモニタリング用メッセージに対する応答メッセージを、TAUの認証(authentication)処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、UEにおいて、不正なeNBの成りすましによるUEモニタリング用メッセージに対する応答メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にTAUの認証(authentication)処理時に実行すればよい。
【0211】
また、メッセージ認証コード(Message Authentication Code)を付加して、メッセージ認証を実行してもよい。
【0212】
UEにおいて、eNBの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った処理(以下「不正eNB検出処理」という)を実行してもよい。不正eNB検出処理の具体例としては、内部情報の削除などがある。
【0213】
次に、図14を用いて、実施の形態1の変形例1における通信システムのシーケンスの具体例について説明する。
【0214】
ステップST1402でUEモニタリング用メッセージを受信したeNBは、ステップST1403において、UEにUEモニタリング用メッセージに対する応答メッセージを送信する。
【0215】
以上の実施の形態1の変形例1によって、実施の形態1の効果に加えて、以下の効果を得ることができる。UEによるeNBの成りすましを検出することが可能となる。
【0216】
実施の形態1 変形例2.
実施の形態1の変形例2では、前述の実施の形態1と同じ課題について、別の解決策を開示する。実施の形態1の変形例2での解決策を以下に示す。本変形例では、前述の実施の形態1の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態1と同様とする。
【0217】
本変形例では、UEとeNBとの間におけるUEモニタリング用メッセージを設ける。eNBは、周期的にUEモニタリング用メッセージをUEに送信する。UEは、UEモニタリング用メッセージを受信した場合は、送達確認用情報をeNBに通知する。eNBは、送達確認用情報を受信した場合は、UE検出と判断する。eNBは、送達確認用情報を受信しない場合は、UE不検出と判断する。このようにUEモニタリング用メッセージを用いることによって、TAU処理を長周期化した場合でも、モニタリングが必要な頻度でモニタリングを行うことが可能となる。
【0218】
以下の説明では、eNBがUEにUEモニタリング用メッセージを送信する周期を、「UEモニタリング周期」と称することもある。
【0219】
またeNBが、タイマ満了後、あるいはタイマ満了を契機に、UEモニタリング用メッセージを送信するようにしてもよい。このタイマを、「UEモニタリングタイマ」と称することもある。
【0220】
以下、主にUEモニタリング周期を用いて説明するが、UEモニタリングタイマを用いることもできる。
【0221】
送達確認情報の具体例としては、RLCレイヤにおける応答メッセージ(ACK)がある。送達確認情報は、ステータスPDU(Status PDU)であってもよい。
【0222】
eNBは、UEモニタリング用メッセージに対する送達確認情報を用いて、UEが存在するか否かの判断(以下「不検出判断」と称することもある)をしてもよい。eNBは、UEが存在しない、すなわちUE不検出と判断した場合、不検出処理を実行してもよい。
【0223】
不検出判断の具体例として、以下の(1)〜(6)の6つを開示する。
(1)eNBは、周期内に送達確認情報を受信しない場合は、UE不検出と判断する。eNBは、周期内に送達確認情報を受信した場合は、UEが存在する、すなわちUE検出と判断する。
【0224】
(2)eNBは、周期内に送達確認情報を受信しないことが、予め決められた回数連続して発生した場合は、UE不検出と判断する。予め決められた回数は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた回数を準静的に決定する場合は、eNBから、あるいはeNB経由で、UEに、予め決められた回数を通知すればよい。
【0225】
予め決められた回数の通知方法の具体例として、以下の(2−1)〜(2−4)の4つを開示する。
(2−1)報知情報によって通知する。
(2−2)個別情報によって通知する。
(2−3)TAU処理によって通知する。具体的には、TAUアクセプト(TAU Accept)メッセージなどによって通知する。
(2−4)アタッチ処理によって通知する。具体的には、アタッチアクセプト(Attach Accept)メッセージ、RRC接続再設定(RRC Connection Reconfiguration)メッセージなどによって通知する。
【0226】
(3)eNBは、予め決められた期間内に送達確認情報を受信しない場合は、UE不検出と判断する。予め決められた期間は、UEがUEモニタリング用メッセージを送信する周期よりも長くすればよい。予め決められた期間は、静的に決定されてもよいし、準静的に決定されてもよい。予め決められた期間を準静的に決定する場合は、eNBから、あるいはeNB経由で、UEに、予め決められた期間を通知すればよい。予め決められた期間の通知方法の具体例は、前記不検出判断の具体例(2)における予め決められた回数の通知方法と同様であるので、説明を省略する。
【0227】
(4)周期的なLAU処理、RAU処理およびTAU処理と併用してもよい。eNBは、周期内に送達確認情報を受信した場合は、UE検出と判断する。eNBは、周期内に送達確認情報を受信しない場合は、MMEに通知する。MMEは、周期内にTAU処理が実行された場合は、UE検出と判断する。MMEは、周期内にTAU処理が実行されない場合は、UE不検出と判断する。これによって、eNBがUEモニタリング用メッセージを受信しない理由が、該eNBのカバレッジ外へのUEの移動である場合にも、MMEは適切に処理することができる。つまり、MMEは、適切にUE検出と判断することができる。
【0228】
(5)前記(1)〜(4)においてUE不検出と判断した後に、該UE宛にページングを通知する。該UEから応答が有る場合は、UE検出と判断する。該UEから応答が無い場合は、UE不検出と判断する。
(6)前記(1)〜(5)の組合せ。
【0229】
不検出処理の具体例は、前述の実施の形態1と同様であるので、説明を省略する。
【0230】
また、UEは、周期内にUEモニタリング用メッセージを受信しない場合、その旨をeNBに通知してもよい。これによって、eNB、あるいはネットワーク側が異常を検出することが可能となる。
【0231】
eNBが、UEモニタリング用メッセージをUEに通知する目的の具体例として、以下の(1)〜(4)の4つを開示する。
(1)「生きている」の問合せ。
(2)UEが存在することの問合せ。
(3)UEが正常に動作していることの問合せ。
(4)前記(1)〜(3)の組合せ。
【0232】
UEモニタリング用メッセージの具体例として、以下の(1)〜(3)の3つを開示する。
(1)Uu点のみのメッセージとする。Uu点とは、UEとeNB、UEとHeNB、またはUEとRNのインタフェース点である。
(2)RRCメッセージとする。本具体例(2)では、UEモニタリング用メッセージと異なり、TAUは、NASメッセージとなる。
(3)前記(1),(2)の組合せ。
【0233】
UEモニタリング用メッセージをRRCメッセージとする場合の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにRRCシグナル、あるいはRRCメッセージを設ける。
(2)既存のRRCシグナル、あるいはRRCメッセージを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0234】
新たにRRCシグナルにマッピングするパラメータの具体例として、以下の(1)〜(4)の4つを開示する。
(1)「生きている」の問合せである旨、UEが存在することの問合せである旨、UEが正常に動作していることの問合せである旨など。
(2)セルの識別子。具体的には、PCI、CGI、ECGIであってもよい。
【0235】
(3)シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、TAU処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
(4)前記(1)〜(3)の組合せ。
【0236】
次に、既存のRRCシグナルを用いる場合の具体例を以下に開示する。RRC接続再設定(RRC Connection Reconfiguration)メッセージを用いる。
【0237】
既存のRRCシグナリングに追加が必要なパラメータの具体例としては、「生きている」の問合せである旨、UEが存在することの問合せである旨、UEが正常に動作していることの問合せである旨などがある。
【0238】
UEモニタリング用メッセージを、TAUの認証(authentication)処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、UEにおいて、不正なeNBの成りすましによるUEモニタリング用メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にTAUの認証(authentication)処理時に実行すればよい。
【0239】
また、メッセージ認証コード(Message Authentication Code)を付加して、メッセージ認証を実行してもよい。
【0240】
UEにおいて、eNBの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った不正eNB検出処理を実行してもよい。不正eNB検出処理の具体例としては、内部情報の削除などがある。
【0241】
UEモニタリング周期の設定値の具体例として、以下の(1)〜(5)の5つを開示する。
(1)無線フレーム数。
(2)サブフレーム数。
(3)UEモニタリング周期を、周期的に実行するTAUの周期に対する整数倍、または整数の逆数倍(1/整数倍)とする場合において、「整数」をUEモニタリング周期の設定値とする。
【0242】
(4)ページングメッセージを受信するタイミングと同じタイミングとする。あるいは、ページングメッセージを受信するタイミングを、UEモニタリング周期の整数倍、または整数の逆数倍(1/整数倍)とする。
ページングメッセージを受信するタイミングと同じタイミングとする場合の具体例としては、UEモニタリング周期に、ページングフレーム(Paging Frame:PF)、またはページングオケージョン(Paging Occasion:PO)を用いる場合が挙げられる(非特許文献3参照)。これによって、UEモニタリング周期を改めて設定する必要がなくなり、無線リソースを有効に活用することができるという効果を得ることができる。
また、UEの動作としては、ページングメッセージを受信するタイミングとUEモニタリング用メッセージの受信タイミングとを合わせることができる。これによって、UEによって受信回路の電源をオンするタイミングを減らすことができる。したがって、UEの低消費電力化を図るという効果を得ることができる。
(5)前記(1)〜(4)の組合せ。
【0243】
次に、図15を用いて、実施の形態1の変形例2における通信システムのシーケンスの具体例について説明する。図15は、実施の形態1の変形例2における通信システムのシーケンスの一例を示す図である。図15では、eNBが、UEモニタリング周期毎に、UEモニタリング用メッセージを送信する場合のシーケンスを示している。図15に示すシーケンスは、図13に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0244】
ステップST1502において、eNBは、UEモニタリング周期1501で、UEにUEモニタリング用メッセージを通知する。
【0245】
ステップST1502でUEモニタリング用メッセージを受信したUEは、ステップST1503において、eNBに送達確認情報を送信する。
【0246】
以上のステップST1502およびステップST1503の処理をまとめてステップST1504とし、ステップST1504の処理を、UEモニタリング処理と称することとする。
【0247】
ステップST1506において、UEとeNBとの間では、UEモニタリング周期1505で、UEモニタリング処理が実行される。
【0248】
またステップST1508において、UEとeNBとの間では、UEモニタリング周期1507で、UEモニタリング処理が実行される。
【0249】
またステップST1510において、UEとeNBとの間では、UEモニタリング周期1509で、UEモニタリング処理が実行される。
【0250】
UEモニタリング周期1511と、周期的に実行するTAUの周期1512とが同時に発生する場合は、ステップST1513において、TAU処理(TAU Procedure)が実行される。
【0251】
以上の実施の形態1の変形例2によって、前述の実施の形態1と同様の効果を得ることができる。
【0252】
実施の形態1 変形例3.
実施の形態1の変形例3では、前述の実施の形態1の変形例2の更なる改善点について示す。本変形例では、前述の実施の形態1の変形例2の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態1の変形例2と同様とする。
【0253】
UEは、eNBからUEモニタリング用メッセージを受信した場合、UEモニタリング用メッセージに対する応答メッセージをeNBに送信する。本変形例では、応答メッセージに、暗号化(cipher)を施すようにすればよい。実施の形態1の変形例2の送達確認情報が単純な確認メッセージ、例えばACK情報と比較して、本変形例3では、UEモニタリング用メッセージに対する応答メッセージを送信するので、eNBによるUEの成りすましを検出することが可能となる。
【0254】
UEモニタリング用メッセージに対する応答メッセージを、RRCメッセージとしてもよい。UEモニタリング用メッセージに対する応答メッセージをRRCメッセージとする場合の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにRRCシグナル、あるいはRRCメッセージを設ける。
(2)既存のRRCシグナル、あるいはRRCメッセージを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0255】
新たにRRCシグナルにマッピングするパラメータの具体例として、以下の(1)〜(4)の4つを開示する。
(1)UEモニタリング用メッセージに対する応答メッセージである旨。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。また、TAU処理などにおいて初期化されるようなシーケンス番号とすれば、シーケンス番号を送信するために必要なビット数が膨大になることを防ぐことができる。
(4)前記(1)〜(3)の組合せ。
【0256】
次に、既存のRRCシグナルを用いる場合の具体例を開示する。RRC接続再設定完了(RRC Connection Reconfiguration Complete)メッセージを用いる。
【0257】
既存のRRCシグナリングに追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。UEモニタリング用メッセージに対する応答メッセージである旨は、既存のRRCシグナリングに設定されている「設定理由(Establishment Cause)」のパラメータに含めて通知されてもよい。
【0258】
UEモニタリング用メッセージに対する応答メッセージを、TAUの認証(authentication)処理において合意した暗号化鍵を用いて暗号化したデータとして送信してもよい。これによって、暗号化鍵およびセキュリティ対策強化のためのシーケンス番号が解読されない限り、eNBにおいて、不正なUEの成りすましによるUEモニタリング用メッセージに対する応答メッセージの検出を行うことが可能となる。暗号化鍵の変更は、通信量および期間を考慮して、適切にTAUの認証(authentication)処理時に実行すればよい。
【0259】
また、メッセージ認証コード(Message Authentication Code)を付加して、メッセージ認証を実行してもよい。
【0260】
eNBにおいて、UEの成りすましを検出した場合、そのサービス提供者の運用ポリシーに従った不正UE検出処理を実行してもよい。不正UE検出処理の具体例は、前述の実施の形態1と同様であるので、説明を省略する。
【0261】
次に、図15を用いて、実施の形態1の変形例3における通信システムのシーケンスの具体例について説明する。
【0262】
ステップST1502でUEモニタリング用メッセージを受信したUEは、ステップST1503において、eNBにUEモニタリング用メッセージに対する応答メッセージを送信する。
【0263】
以上の実施の形態1の変形例3によって、実施の形態1の変形例2の効果に加えて、以下の効果を得ることができる。eNBによるUEの成りすましを検出することが可能となる。
【0264】
実施の形態1 変形例4.
実施の形態1の変形例4では、前述の実施の形態1と同じ課題について、別の解決策を開示する。実施の形態1の変形例4での解決策を以下に示す。
【0265】
本変形例では、UEは、RRC接続(RRC Connection)を確立せずに、周期的にUEモニタリング用メッセージをeNBに送信する。言い換えると、UEは、RRC待受け状態(RRC_Idle)で、周期的にUEモニタリング用メッセージをeNBに送信する。これによって、RRC接続の確立および解放の手続きが不要となり、UEの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
【0266】
RRC接続を確立せずに、UEモニタリング用メッセージを送信する方法の具体例としては、UEモニタリング用メッセージを、ランダムアクセス(Random Access)処理中に送信する方法が挙げられる。この方法によれば、新たな処理を新設する必要がないので、通信システムの複雑性を回避することができるという効果を得ることができる。
【0267】
既存のランダムアクセス処理について、図16を用いて説明する(非特許文献1参照)。図16は、ランダムアクセス処理のシーケンスの一例を示す図である。
【0268】
ステップST1601において、UEは、eNBにランダムアクセスプリアンブル(Random Access Preamble)を送信する。
【0269】
ステップST1602において、eNBは、UEにランダムアクセスレスポンス(Random Access Response)を送信する。PDCCH上のランダムアクセス無線ネットワーク一時的識別子(Random Access-Radio Network Temporary Identity:RA−RNTI)がアドレスされる。DL−SCHによって、タイミングアライメント(Timing Alignment:TA)、初期上りグラント、セル無線ネットワーク一時的識別子(Cell Radio Network Temporary Identifier:C−RNTI)の割当てなどが行われる。
【0270】
ステップST1603において、UEは、eNBにスケジュールされた送信(Scheduled Transmission)を送信する。初期アクセス(initial access)が実行される。RRCレイヤによって、RRC接続要求(RRC Connection Request)が送信される。UEのC−RNTIが通知される。
【0271】
ステップST1604において、eNBは、UEに競合解決(Contention Resolution)を送信する。RRC接続のUEのために、PDCCH上のC−RNTIがアドレスされる。
【0272】
UEモニタリング用メッセージを、RACH処理中に送信する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)ランダムアクセスプリアンブル(Random Access Preamble)を用いる。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨などがある。
【0273】
(2)スケジュールされた送信(Scheduled Transmission)メッセージを用いる。さらに具体的には、RRC接続要求(RRC Connection Request)メッセージ(非特許文献2参照)を用いる。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージである旨、「生きている」旨、キープアライブである旨、存在している旨、ダウンしていない旨、正常に動作している旨などがある。これらは、前記メッセージに設定されている「設定理由(Establishment Cause)」のパラメータに含めて通知されてもよい。
【0274】
UEモニタリング用メッセージに対する応答メッセージを、RACH処理中に送信する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)ランダムアクセスレスポンス(Random Access Response)を用いる。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。
(2)競合解決(Contention Resolution)メッセージを用いる。さらに具体的には、RRC接続セットアップ(RRC Connection Setup)メッセージを用いる。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。
【0275】
次に、図17を用いて、実施の形態1の変形例4における通信システムのシーケンスの具体例について説明する。図17は、実施の形態1の変形例4における通信システムのシーケンスの一例を示す図である。図17では、ランダムアクセスプリアンブル(Random Access Preamble)を用いて、UEモニタリング用メッセージを通知する場合のシーケンスを示している。図17に示すシーケンスは、図16に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0276】
ステップST1701において、UEは、ランダムアクセスプリアンブル(Random Access Preamble)を用いて、UEモニタリング用メッセージをeNBに送信する。
【0277】
ステップST1702において、eNBは、ステップST1701で受信したランダムアクセスプリアンブル(Random Access Preamble)がUEモニタリング用メッセージを通知するか否かを判断する。ステップST1702において、ランダムアクセスプリアンブル(Random Access Preamble)がUEモニタリング用メッセージを通知すると判断された場合は、ステップST1703に移行し、ランダムアクセスプリアンブル(Random Access Preamble)がUEモニタリング用メッセージを通知するものではないと判断された場合は、ステップST1602に移行する。
【0278】
具体的には、ランダムアクセスプリアンブル(Random Access Preamble)にUEモニタリング用メッセージである旨が含まれていない場合は、UEモニタリング用メッセージを通知するものではないと判断されて、ステップST1602に移行する。つまり、通常のランダムアクセス処理に移行する。また、ランダムアクセスプリアンブル(Random Access Preamble)にUEモニタリング用メッセージである旨が含まれている場合は、UEモニタリング用メッセージを通知すると判断されて、ステップST1703に移行する。
【0279】
ステップST1703において、eNBは、UEモニタリング用メッセージに対する送達確認情報をUEに送信する。送達確認情報の具体例としては、RLCレイヤにおける応答メッセージがある。送達確認情報は、ステータスPDU(Status PDU)であってもよい。UEモニタリング用メッセージに対する送達確認情報は、ランダムアクセスレスポンス(Random Access Response)を用いて送信してもよい。その後、処理が終了する。つまり、ステップST1602およびステップST1604などで行われるRRC接続のための処理は行われない。
【0280】
次に、図18を用いて、実施の形態1の変形例4における通信システムのシーケンスの具体例について説明する。図18は、実施の形態1の変形例4における通信システムのシーケンスの他の例を示す図である。図18では、RRC接続要求(RRC Connection Request)を用いて、UEモニタリング用メッセージを通知する場合のシーケンスを示している。図18に示すシーケンスは、図16および図17に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0281】
ステップST1801において、UEは、RRC接続要求(RRC Connection Request)を用いて、UEモニタリング用メッセージをeNBに送信する。
【0282】
ステップST1802において、eNBは、ステップST1801で受信したRRC接続要求(RRC Connection Request)がUEモニタリング用メッセージを通知するか否かを判断する。ステップST1802において、RRC接続要求(RRC Connection Request)がUEモニタリング用メッセージを通知すると判断された場合は、ステップST1803に移行し、RRC接続要求(RRC Connection Request)がUEモニタリング用メッセージを通知するものではないと判断された場合は、ステップST1604に移行する。
【0283】
具体的には、RRC接続要求(RRC Connection Request)にUEモニタリング用メッセージである旨が含まれていない場合は、UEモニタリング用メッセージを通知するものではないと判断されて、ステップST1604に移行する。つまり、通常のランダムアクセス処理に移行する。また、RRC接続要求(RRC Connection Request)にUEモニタリング用メッセージである旨が含まれている場合は、UEモニタリング用メッセージを通知すると判断されて、ステップST1803に移行する。
【0284】
ステップST1803において、eNBは、UEモニタリング用メッセージに対する応答メッセージをUEに送信する。UEモニタリング用メッセージに対する応答メッセージは、RRC接続セットアップ(RRC Connection Setup)を用いて送信してもよい。その後、処理が終了する。つまり、ステップST1604などで行われるRRC接続のための処理は行われない。
【0285】
MMEからeNBに通知するメッセージとして、MMEの過負荷を示すメッセージが既存する。このメッセージは、S1インタフェース上の「Overload START」メッセージである(3GPP TS36.413 V10.4.0参照)。MMEが「Over load START」メッセージを受信したeNBに要求する動作は、「Overload Action」として、「Overload START」メッセージの情報要素として通知される(3GPP TS36.413 V10.4.0参照)。「Overload Action」には、RRC接続要求に対して、RRC接続を拒否することが主に規定されている。
【0286】
つまり、既存の技術では、MMEは、eNBに対してRRC接続(RRC Connection)を確立せずにメッセージを通知する本変形例を用いたUEからeNBへのメッセージ通知を禁止することはできない。MMEが過負荷の場合、問題となる。
【0287】
前記課題の解決策として、「Overload Action」に、RRC接続(RRC Connection)を確立せずに行われるメッセージの通知を禁止するパラメータを追加する。これによって、MMEが過負荷の場合、RRC接続(RRC Connection)を確立せずに行われるメッセージの通知を禁止することが可能となる。
【0288】
実施の形態1の変形例4は、前述の実施の形態1または実施の形態1の変形例1と組合せて用いることが可能である。
【0289】
以上の実施の形態1の変形例4によって、実施の形態1の効果に加えて、以下の効果を得ることができる。RRC接続の確立および解放の手続きが不要となり、UEの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
【0290】
実施の形態1 変形例5.
実施の形態1の変形例5では、前述の実施の形態1と同じ課題について、別の解決策を開示する。実施の形態1の変形例5での解決策を以下に示す。
【0291】
本変形例では、eNBは、RRC接続(RRC Connection)を確立せずに、周期的にUEモニタリング用メッセージをUEに送信する。言い換えると、eNBは、RRC待受け状態(RRC_Idle)のUEに、周期的にUEモニタリング用メッセージを送信する。これによって、RRC接続の確立および解放の手続きが不要となり、UEの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
【0292】
RRC接続を確立せずにUEモニタリング用メッセージを送信する方法の具体例としては、UEモニタリング用メッセージを、ページング処理中に送信する方法が挙げられる。この方法によれば、新たな処理を新設する必要がないので、通信システムの複雑性を回避することができるという効果を得ることができる。
【0293】
既存のページング処理について、図19および図20を用いて説明する(非特許文献2参照)。図19および図20は、LTE方式の通信システムにおけるページング処理のシーケンスの一例を示す図である。図19図20とは、境界線BL1の位置で、つながっている。
【0294】
ステップST1901において、MMEは、UEが位置するトラッキングエリアに属するeNBに、UE宛のページングメッセージ(Paging message)を送信する。
【0295】
ステップST1902において、eNBは、ステップST1901で受信したページングメッセージ(Paging message)を、カバレッジ内のUEに送信する。
【0296】
ステップST1903において、UEは、ページングメッセージを受信するタイミングであるか否かを判断する。ステップST1903において、ページングメッセージを受信するタイミングであると判断された場合は、ステップST1904に移行し、ページングメッセージを受信するタイミングでないと判断された場合は、ステップST1903の処理を繰り返す。
【0297】
ステップST1904において、UEは、ページングメッセージを受信するタイミングでPDCCHを受信し、PDCCHにページング無線ネットワーク一時的識別子(Paging-Radio Network Temporary Identity:P-RNTI)が有るか否かを判断する。換言すれば、UEは、P−RNTIがアドレスされているか否かを判断する。ステップST1904において、PDCCHにP-RNTIが有ると判断された場合は、ステップST1905に移行し、PDCCHにP-RNTIが無いと判断された場合は、ステップST1903に戻る。
【0298】
ステップST1905において、UEは、RRC_IDLEであるか否かを判断する。ステップST1905において、RRC_IDLEであると判断された場合は、ステップST1906に移行し、RRC_IDLEでないと判断された場合は、図20のステップST1911に移行する。
【0299】
ステップST1906において、UEは、ページングメッセージ中のUE−IDが自UE−IDと一致するか否かを判断する。ページングメッセージは、ロジカルチャネルであるPCCHにマッピングされ、トランスポートチャネルであるPCHにマッピングされ、物理チャネルであるPDSCHにマッピングされるメッセージである。ステップST1906において、ページングメッセージ中のUE−IDが自UE−IDと一致すると判断された場合は、ステップST1907に移行し、ページングメッセージ中のUE−IDが自UE−IDと一致しないと判断された場合は、図20のステップST1911に移行する。
【0300】
ステップST1907において、UEは、RRC接続要求(RRC Connection Request)メッセージをeNBに送信する。
【0301】
ステップST1908において、eNBは、RRC接続セットアップ(RRC Connection Setup)メッセージをUEに送信する。
【0302】
ステップST1909において、UEは、RRC接続セットアップ完了(RRC Connection Setup Complete)メッセージをeNBに送信する。
【0303】
ステップST1910において、UE、eNBおよびMMEは、ステップST1907〜ステップST1909で確立したRRC接続を用いて、サービス要求(Service Request)処理を実行する。
【0304】
ステップST1911において、UEは、ページングメッセージ中に、システム情報の変更を示す情報であるシステム情報変更インジケータ(System Information Modification Indicator)が有るか否かを判断する。ステップST1911において、ページングメッセージ中にシステム情報変更インジケータが有ると判断された場合は、ステップST1912に移行し、ページングメッセージ中にシステム情報変更インジケータが無いと判断された場合は、ステップST1913に移行する。
【0305】
ステップST1912において、UEは、システム情報を受信して、ステップST1913に移行する。
【0306】
ステップST1913において、UEは、ページングメッセージ中に、ETWSインジケータ(Earthquake and Tsunami Warning System Indicator)が有るか否かを判断する。ステップST1913において、ページングメッセージ中にETWSインジケータが有ると判断された場合は、ステップST1914に移行し、ページングメッセージ中にETWSインジケータが無いと判断された場合は、ステップST1915に移行する。
【0307】
ステップST1914において、UEは、ETWS情報を受信する。ETWS情報は、特有のシステム情報にマッピングされている。ETWS情報を受信すると、ステップST1915に移行する。
【0308】
ステップST1915において、UEは、ページングメッセージ中に、CMASインジケータ(Commercial Mobile Alert Service Indicator)が有るか否かを判断する。ステップST1915において、ページングメッセージ中にCMASインジケータが有ると判断された場合は、ステップST1916に移行し、ページングメッセージ中にCMASインジケータが無いと判断された場合は、処理が終了する。
【0309】
ステップST1916において、UEは、CMAS情報を受信する。CMAS情報は、特有のシステム情報にマッピングされている。CMAS情報を受信すると、処理が終了する。
【0310】
UEモニタリング用メッセージをページング処理中に送信する方法の具体例として、以下の(1)〜(3)の3つを開示する。
(1)PDCCHにUEモニタリング用メッセージの有無を通知する識別子を新たに設ける。前記識別子は、例えばマルチメディアブロードキャスト/マルチメディアサービス無線ネットワーク一時的識別子(Multimedia Broadcast/Multicast Service Radio Network Temporary Identity:M−RNTI)とする。UEは、UEモニタリング用周期でPDCCHを受信し、PDCCHにM−RNTIが有るか否かを判断する。換言すれば、UEは、M−RNTIがアドレスされているか否かを判断する。PDCCHにM-RNTIが有ると判断された場合は、UEは、UEモニタリング用メッセージを受信したと判断する。PDCCHにM−RNTIが無いと判断された場合は、UEは、UEモニタリング用メッセージを受信していないと判断する。本具体例(1)は、後述する具体例(2),(3)と異なり、ページングメッセージ(Paging message)の受信が不要となるので、制御遅延の防止を図ることができるという効果を得ることができる。
【0311】
(2)ページングメッセージ(Paging message)中にUEモニタリング用メッセージの送信を示すインジケータをマッピングする。UEは、ページングメッセージ中に、UEモニタリング用メッセージの送信を示すインジケータが有るか否かを判断する。ページングメッセージ中にUEモニタリング用メッセージの送信を示すインジケータが有ると判断された場合は、UEは、UEモニタリング用メッセージを受信したと判断する。ページングメッセージ中にUEモニタリング用メッセージの送信を示すインジケータが無いと判断された場合は、UEは、UEモニタリング用メッセージを受信していないと判断する。本具体例(2)は、前記具体例(1)と異なり、P-RNTIを併用することができ、UEがPDCCHをデコードする回数が減るので、UEの負荷を削減することができるという効果を得ることができる。
【0312】
(3)ページングメッセージ中に、UEモニタリング用メッセージをマッピングする。追加が必要なパラメータの具体例としては、「生きている」の問合せである旨、UEが存在することの問合せである旨、UEが正常に動作していることの問合せである旨などがある。具体例(3)は、前記具体例(1)と比較して、P-RNTIを併用することができ、UEがPDCCHをデコードする回数が減るので、UEの負荷を削減することができるという効果を得ることができる。
【0313】
UEモニタリング用メッセージに対する応答メッセージをRACH処理中に送信する方法の具体例としては、サービス要求処理中に送信する方法がある。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。
【0314】
サービス要求処理中に送信する方法の具体例としては、サービス要求処理中におけるRACH処理中に送信する方法がある。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。
【0315】
サービス要求処理中におけるRACH処理中に送信する方法の具体例として、以下の(1),(2)を開示する。
(1)ランダムアクセスプリアンブル(Random Access Preamble)を用いる。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。
【0316】
(2)スケジュールされた送信(Scheduled Transmission)メッセージを用いる。さらに具体的には、RRC接続要求(RRC Connection Request)メッセージを用いる(非特許文献2参照)。追加が必要なパラメータの具体例としては、UEモニタリング用メッセージに対する応答メッセージである旨がある。UEモニタリング用メッセージに対する応答メッセージである旨は、前記メッセージに設定されている「設定理由(Establishment Cause)」のパラメータに含めて通知されてもよい。
【0317】
次に、図21および図22を用いて、実施の形態1の変形例5における通信システムのシーケンスの具体例について説明する。図21および図22は、実施の形態1の変形例5における通信システムのシーケンスの一例を示す図である。図21図22とは、境界線BL2の位置で、つながっている。図21および図22では、PDCCHにUEモニタリング用メッセージの有無を通知する識別子を新たに設けて、UEモニタリング用メッセージを通知する場合のシーケンスを示している。図21および図22に示すシーケンスは、図19および図20に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0318】
ステップST1904において、UEは、ページングメッセージを受信するタイミングでPDCCHを受信し、PDCCHにP-RNTIが有るか否かを判断する。換言すれば、UEは、P−RNTIがアドレスされているか否かを判断する。ステップST1904において、PDCCHにP-RNTIが有ると判断された場合は、ステップST1905に移行し、PDCCHにP-RNTIが無いと判断された場合は、ステップST2001に移行する。
【0319】
ステップST1905において、UEは、RRC_IDLEであるか否かを判断する。ステップST1905において、RRC_IDLEであると判断された場合は、ステップST1906に移行し、RRC_IDLEでないと判断された場合は、ステップST2001に移行する。
【0320】
ステップST1906において、UEは、ページングメッセージ中のUE−IDが自UE−IDと一致するか否かを判断する。ステップST1906において、ページングメッセージ中のUE−IDが自UE−IDと一致すると判断された場合は、ステップST2003に移行し、ページングメッセージ中のUE−IDが自UE−IDと一致しないと判断された場合は、ステップST2001に移行する。
【0321】
ステップST2001において、UEは、PDCCHにM-RNTIが有るか否かを判断する。換言すれば、UEは、M−RNTIがアドレスされているか否かを判断する。ステップST2001において、PDCCHにM-RNTIが有ると判断された場合は、ステップST2002に移行し、PDCCHにM-RNTIが無いと判断された場合は、ステップST1903に戻る。
【0322】
ステップST2002において、UEは、UEモニタリング用メッセージに対する応答メッセージを、MMEに送信する。UEモニタリング用メッセージに対する応答メッセージは、ランダムアクセスプリアンブル(Random Access Preamble)、スケジュールされた送信(Scheduled Transmission)、またはRRC接続要求(RRC Connection Request)を用いて送信してもよい。その後、UEは、図22のステップST1911に移行する。
【0323】
ステップST2003において、UEは、PDCCHにM-RNTIが有るか否かを判断する。換言すれば、UEは、M−RNTIがアドレスされているか否かを判断する。ステップST2003において、PDCCHにM-RNTIが有ると判断された場合は、ステップST2004に移行し、PDCCHにM-RNTIが無いと判断された場合は、ステップST1907に移行する。
【0324】
ステップST2004において、UEは、RRC接続要求(RRC Connection Request)に、UEモニタリング用メッセージに対する応答メッセージを付加する。
【0325】
ページングに対する通常の応答メッセージに、UEモニタリング用メッセージに対する応答メッセージを付加してもよい。ランダムアクセスプリアンブル(Random Access Preamble)、またはスケジュールされた送信(Scheduled Transmission)に、UEモニタリング用メッセージに対する応答メッセージを付加してもよい。その後、UEは、ステップST1907に移行する。
【0326】
次に、図23および図24を用いて、実施の形態1の変形例5における通信システムのシーケンスの具体例について説明する。図23および図24は、実施の形態1の変形例5における通信システムのシーケンスの他の例を示す図である。図23図24とは、境界線BL3の位置で、つながっている。図23および図24では、ページングメッセージ中に、UEモニタリング用メッセージの送信を示すインジケータ(以下「UEモニタリング用インジケータ」と称することもある)をマッピングし、UEモニタリング用メッセージを通知する場合のシーケンスを示している。図23および図24に示すシーケンスは、図19および図20に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0327】
図24のステップST2101において、UEは、ページングメッセージ中に、UEモニタリング用インジケータが有るか否かを判断する。ステップST2101において、UEモニタリング用インジケータが有ると判断された場合は、ステップST2102に移行し、UEモニタリング用インジケータが無いと判断された場合は、処理を終了する。
【0328】
ステップST2102において、UEは、UEモニタリング用メッセージに対する応答メッセージを、MMEに送信する。UEモニタリング用メッセージに対する応答メッセージは、ランダムアクセスプリアンブル(Random Access Preamble)、スケジュールされた送信(Scheduled Transmission)、またはRRC接続要求(RRC Connection Request)を用いて送信してもよい。
【0329】
次に、図25および図26を用いて、実施の形態1の変形例5における通信システムのシーケンスの具体例について説明する。図25および図26は、実施の形態1の変形例5における通信システムのシーケンスの他の例を示す図である。図25図26とは、境界線BL4の位置で、つながっている。図25および図26では、ページングメッセージ中に、UEモニタリング用メッセージをマッピングし、UEモニタリング用メッセージを通知する場合のシーケンスを示している。図25および図26に示すシーケンスは、図19および図20に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0330】
図26のステップST2201において、UEは、ページングメッセージ中にUEモニタリング用メッセージがマッピングされているか否かを判断する。換言すれば、UEは、ページングメッセージ中にUEモニタリング用メッセージが有るか否かを判断する。ステップST2201において、ページングメッセージ中にUEモニタリング用メッセージが有ると判断された場合は、ステップST2102に移行し、ページングメッセージ中にUEモニタリング用メッセージが無いと判断された場合は、処理が終了する。
【0331】
実施の形態1の変形例5は、前述の実施の形態1の変形例2または実施の形態1の変形例3と組合せて用いることが可能である。
【0332】
以上の実施の形態1の変形例5によって、実施の形態1の効果に加えて、以下の効果を得ることができる。RRC接続の確立および解放の手続きが不要となり、UEの低消費電力化を図ることができるという効果と、無線リソースを有効に活用することができるという効果を得ることができる。
【0333】
実施の形態1 変形例6.
実施の形態1の変形例6では、前述の実施の形態1の更なる改善点について示す。本変形例では、前述の実施の形態1の解決策と異なる部分を中心に説明し、説明していない部分については、実施の形態1と同様とする。
【0334】
本変形例では、eNBからUEへの送達確認情報に、該eNB、または該eNBが属するネットワーク側のシステムに関する情報を含める。
【0335】
システムに関する情報の具体例として、以下の(1)〜(4)の4つを開示する。
(1)ステータス情報、または規制情報。ステータス情報および規制情報の具体例として、以下の(1−1)〜(1−3)の3つを開示する。(1−1)eNB、または該eNBが属するネットワークの正常/異常の旨。(1−2)eNB、または該eNBが属するネットワークの混雑/非混雑の旨。(1−3)eNB、または該eNBが属するネットワークの使用可/不可の旨。
(2)システム情報そのもの。システム情報の一部であってもよい。
(3)前記(1)〜(2)などの変更があった日時。
(4)前記(1)〜(3)の組合せ。
【0336】
実施の形態1の変形例6は、前述の実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3、実施の形態1の変形例4、または実施の形態1の変形例5と組合せて用いることが可能である。
【0337】
実施の形態1の変形例6と実施の形態1の変形例1とを組合せる場合は、UEモニタリング用メッセージに対する応答メッセージに、該eNB、または該eNBが属するネットワーク側のシステムに関する情報を含めればよい。
【0338】
実施の形態1の変形例6と、実施の形態1の変形例2または実施の形態1の変形例3とを組合せる場合は、eNBからUEへのUEモニタリング用メッセージに、該eNB、または該eNBが属するネットワーク側のシステムに関する情報を含めればよい。
【0339】
以上の実施の形態1の変形例6によって、実施の形態1の効果に加えて、以下の効果を得ることができる。UEは、UEモニタリング周期でeNB、または該eNBが属するネットワーク側のシステムに関する情報を取得することができる。
【0340】
実施の形態2.
実施の形態2で解決する課題について、以下に説明する。現在の3GPPのE−UTRAN規格においては、RRC_CONNECTED状態において、UE側が起点となるRRC接続リリース(RRC Connection Release)をE−UTRANに通知する手段が規定されていない。したがって、UEのアプリケーションの指示によって、RRC_IDLE状態に移行した場合、UEとE−UTRANとのRRC状態が一致せず、E−UTRANが不必要にシステムリソースを確保し続けるという問題がある。
【0341】
図27図29は、実施の形態2で解決する課題を説明するためのシーケンスを示す図である。図27図28とは、境界線BL5の位置で、つながっている。図28図29とは、境界線BL6の位置で、つながっている。
【0342】
UEは、TCP/IP上実行されるアプリケーション(以下「APP」という場合がある)を有する。
【0343】
図27図29では、ステップST5101において、UEがRRC_IDLE状態およびECM(EPS Connection Management)_IDLE状態にあり、ステップST5102において、eNBがUEに対してRRC_IDLE状態にあり、ステップST5103において、MMEがUEに対してECM_IDLE状態にある場合について示す。eNBのRRC状態とは、eNBが想定する対象となるUEのRRC状態(以下、単に「eNBのRRC状態」という場合がある)を表す。
【0344】
UEのアプリケーションがアクセス開始するような場合、ステップST5104において、UEのアプリケーションは、UEのNASに対してアクセス要求(Access Request)を行う。このアクセス要求に従い、UEは、ステップST5105において、サービス要求処理A(Service Request Procedure A)を起動する。
【0345】
ステップST5105のサービス要求処理Aの具体例を以下に示す。ステップST5106において、UEのNASは、AS(Access Stratum)(RRC)に対してサービス要求(Service Request)を行う。
【0346】
ステップST5108〜ステップST5110の処理を含むステップST5107において、UEは、eNBとの間で、RRC接続セットアップ処理(RRC Connection Setup Procedure)を実行する。
【0347】
ステップST5108において、UEのAS(RRC)は、RRC接続要求(RRC Connection Request)をeNBに通知する。ステップST5109において、eNBは、RRC接続セットアップ(RRC Connection Setup)をUEのAS(RRC)に通知する。ステップST5110において、UEのAS(RRC)は、RRC接続セットアップ完了(RRC Connection Setup Complete)をUEのAS(RRC)に通知する。
【0348】
このようにして、ステップST5107のRRC接続セットアップ処理が完了すると、UEは、ステップST5111において、RRC_CONNECTED状態およびECM_CONNECTED状態に移行する。また、eNBは、ステップST5112において、UEに対してRRC_CONNECTED状態に移行する。
【0349】
このように、UEとeNBとの間で、RRC接続を設立してRRC_CONNECTED状態に移行した後、UEは、ステップST5113において、サービス要求(Service Request)メッセージをeNBに対して通知する。
【0350】
サービス要求メッセージを受信したeNBは、ステップST5114において、サービスト要求メッセージをMMEに通知する。
【0351】
ステップST5115において、UE、MMEおよびHSSの間で、認証(authentication)処理およびセキュリティ(security)制御処理が実行される。
【0352】
MMEは、無線ベアラおよびS1ベアラをアクティブにするために、図28のステップST5116において、eNBに対して初期コンテキストセットアップ要求(Initial Context Setup Request)メッセージを通知する。
【0353】
初期コンテキストセットアップ要求メッセージを受信したeNBは、ステップST5118およびステップST5119の処理を含むステップST5117において、UEとの間で、無線ベアラ設立処理(Radio Bearer Establishment Procedure)を実行する。
【0354】
ステップST5118において、eNBは、RRC接続再設定(RRC Connection Reconfiguration)メッセージをUEに通知する。ステップST5119において、UEは、RRC接続再設定完了(RRC Connection Reconfiguration Complete)メッセージをeNBに通知する。
【0355】
このようにしてUE間の無線ベアラ設立およびS1ベアラの設定を行ったeNBは、ステップST5120において、MMEに対して初期コンテキストセットアップ完了(Initial Context Setup Complete)メッセージを通知する。
【0356】
初期コンテキストセットアップ完了メッセージを受信したMMEは、ステップST5121において、S−GWに対してベアラ修正要求(Modify Bearer Request)メッセージを通知する。
【0357】
ベアラ修正要求メッセージを受信したS−GWは、ステップST5123〜ステップST5125の処理を含むステップST5122の処理を行う。具体的には、ステップST5123において、S−GWは、P−GWに対してベアラ修正要求メッセージを通知する。ベアラ要求メッセージを受信したP−GWは、ステップST5124において、ベアラ要求メッセージに従って、PCRF(Policy and Charging Rule Function)との間で、IP接続アクセスネットワーク(IP−CAN)セッションコントロールを行う。具体的には、P−GWは、IP−CANのセッション変更を行う。IP−CANのセッション変更は、「PCEF Initiated IP-CAN Session Modification」という場合がある。
【0358】
ステップST5125でベアラ修正応答メッセージを受信したS−GWは、ステップST5126において、MMEに対してベアラ修正応答(Modify Bearer Response)メッセージを通知する。
【0359】
ベアラ修正応答メッセージを受信したMMEは、ステップST5127において、該UEに対してECM_CONNECTED状態に移行する。あるいは、該UEに対するS1コネクションの設立が完了したことで、MMEは該UEに対してECM_CONNECTED状態に移行してもよい。該UEに対するS1コネクションの設立が完了したことは、MMEは、ステップST5120における初期コンテキストセットアップ完了メッセージの受信で認識する。
【0360】
これらの処理によって、ステップST5128において、UEとP−GWとの間でEPSベアラが設立される。
【0361】
ステップST5105のサービス要求処理によってEPSベアラが設立されることによって、ステップST5129において、UEとアプリケーションサーバ(APP server)との間で、エンドツーエンド(End to End)のサービスが実行され、ステップST5130において、アプリケーションデータがUEからアプリケーションサーバに通信される。
【0362】
LTEにおいては、UEおよびeNBが、RRC_CONNECTED状態において、UE側が起点となるRRC接続リリース(RRC Connection Release)をE−UTRANに通知する手段が規定されていない。したがって、ネットワーク側からRRC接続リリース(RRC Connection Release)が起動されない限り、UEとeNBとの間でRRC_CONNECTED状態が維持され、UEとMMEとの間でECM_CONNECTED状態が維持される。
【0363】
ネットワーク側は、UEのアプリケーションにおけるデータの発生の有無を認識できない。したがって、UE側のアプリケーションで、たとえデータの発生が無いとしても、ネットワーク側はその状況を認識することができないので、即座にRRC接続リリース(RRC Connection Release)処理を起動することができない。ネットワーク側は、UEとeNBとの間でRRC_CONNECTED状態を維持し続け、UEとMMEとの間でECM_CONNECTED状態を維持し続けることになる。
【0364】
この問題を解消するために、ネットワーク側は、所定の期間にデータの送受信が行われたか否かを判断し、行われていない場合にはS1リリース処理を起動するとよい。これによって、ネットワーク側は、RRC接続およびS1ベアラをリリースし、eNB間でRRC_IDLE状態に遷移させ、UEとMMEとの間でECM_IDLE状態に遷移させることができる。
【0365】
しかし、このような処理を行ったとしても、例えば、UEのアプリケーションの指示によってRRC_IDLEに移行した場合、UEはRRC_IDLE状態に移行するが、E−UTRANはRRC_CONNECTED状態を維持しているので、UEとE−UTRANとのRRC状態が一致せず、E−UTRANが不必要にシステムリソースを確保し続けてしまうという問題が残る。
【0366】
RRC状態が一致しなくなる例を、図27図29を用いて説明する。例えば、UEのアプリケーションでデータの発生が無くなった場合、図29のステップST5131において、UEのNASは、接続リリース(Connection Release)の指示をASに通知する。
【0367】
ステップST5101において、UEは、RRC接続リリース(RRC Connection Release)処理を行い、RRC_IDLEに移行する。RRC_IDLEの移行とともに、ECM_IDLEへ移行してもよい。しかし、この状態をネットワーク側は認識できないので、eNBは、ステップST5112において、RRC_CONNECTED状態を維持する。
【0368】
eNBは、データの送受信が行われたか否かをモニタし、所定の期間にデータの送受信が行われなかった場合、ステップST5134のS1リリース処理A(S1 Release Procedure A)を起動する。所定の期間として、データモニタタイマを設けて、ステップST5133において、eNBは、データモニタタイマが満了したか否かを判断する。
【0369】
S1リリース処理Aでは、ステップST5135〜ステップST5140の処理を行う。ステップST5135において、eNBは、MMEにUEコンテキストリリース要求(UE Context Release Request)を通知する。ステップST5136において、MMEは、S−GWにアクセスベアラリリース要求(Release Access Bearers Request)を通知する。ステップST5137において、S−GWは、MMEにアクセスベアラリリース応答(Release Access Bearers Response)を通知する。ステップST5138において、MMEは、eNBにUEコンテキストリリースコマンド(UE Context Release Command)を通知する。ステップST5139において、eNBは、UEにRRC接続リリース(RRC Connection Release)を通知する。ステップST5140において、eNBは、MMEにUEコンテキストリリース完了(UE Context Release Complete)を通知する。これによって、UEに対する無線ベアラ、S1ベアラ、EPSベアラがリリースされる。eNBは、ステップST5141においてRRC_IDLE状態に移行し、MMEは、ステップST5142においてECM_IDLE状態に移行する。
【0370】
このように、アプリケーションデータの発生が無くなると、UEは、ステップST5101において、RRC/ECM_IDLE状態に移行するが、eNBおよびMMEは、データモニタタイマが満了するまで、S1リリース処理を起動せず、RRC_CONNECTED状態、およびECM_CONNECTED状態のままである。したがって、ステップST5132に示すように、UEとeNBおよびMMEとで、状態不一致の期間が生じてしまう。
【0371】
実施の形態2での解決策を以下に示す。UEとeNBとの間におけるUEのRRC Connection状態通知用のメッセージ(以下、「Uu keep alive indication」、「Uu keep alive ind」または「uu-keep-alive」という場合がある)を設ける。
【0372】
UEは、周期的に「Uu keep alive ind」をeNBに送信する。eNBは、「Uu keep alive ind」を用いて、UEのRRC状態を判断(以下「RRC状態判断」という場合がある)してもよい。RRC状態判断の具体例は、後述する。
【0373】
これによって、UEのアプリケーションの指示により、UEがRRC_IDLEに移行した場合に、UEからeNBへの周期的な「Uu keep alive ind」の送信が止まる。したがって、UEのRRC状態が、RRC_CONNECTEDではない、つまりRRC_IDLEであると、eNBが判断することが可能となる。これによって、UEとネットワーク(E−UTRAN)側でのRRC状態が一致せず、E−UTRANが不必要にシステムリソースを確保し続けるという問題を解決することができる。
【0374】
UEが「Uu keep alive ind」をeNBに送信する周期を、「Uu keep alive ind」送信周期と称することもある。またUEが、タイマ満了後、あるいはタイマ満了を契機に「Uu keep alive ind」を送信するようにしてもよい。該タイマを「Uu keep alive ind」送信タイマと称することもある。
【0375】
以下、主に「Uu keep alive ind」送信周期を用いて説明するが、「Uu keep alive ind」送信タイマを用いることもできる。
【0376】
eNBは、「Uu keep alive ind」を受信した場合、送達確認情報を送信してもよい。あるいは、eNBは、周期内に「Uu keep alive ind」を受信した場合、送達確認情報を送信してもよい。送達確認情報の具体例としては、RLCレイヤにおける応答メッセージ(ACK)がある。送達確認情報は、ステータスPDU(Status PDU)であってもよい。
【0377】
UEが「Uu keep alive ind」をeNBに通知する目的の具体例として、以下の(1)〜(3)の3つを開示する。
(1)「RRC_CONNECTED」であることを伝えるため。
(2)「RRC_CONNECTED」の継続を要求するため。
(3)前記(1),(2)の組合せ。
【0378】
RRC状態判断の具体例として、以下の(1)〜(4)の4つを開示する。
(1)eNBは、「Uu keep alive ind」送信周期に「Uu keep alive ind」を受信しない場合は、UEがRRC_IDLEである、あるいはRRC_CONNECTEDからRRC_IDLEへ移行した、あるいはRRC_CONNECTEDの継続を要求しないと判断する(以下、まとめて「RRC_IDLEと判断する」という場合がある)。また、eNBは、「Uu keep alive ind」送信周期内に「Uu keep alive ind」を受信する場合は、UEがRRC_CONNECTEDである、あるいはRRC_CONNECTEDを継続する、あるいはRRC_CONNECTEDの継続を要求すると判断する(以下、まとめて「RRC_CONNECTEDと判断する」という場合がある)。「Uu keep alive ind」送信周期の決定方法および通知方法は、後述する。
【0379】
(2)eNBは、「Uu keep alive ind」送信周期内に「Uu keep alive ind」を受信しないことが、予め決められた回数連続して発生した場合は、RRC_IDLEと判断する。予め決められた回数は、静的に決定されても、準静的に決定されてもよい。予め決められた回数の決定方法および通知方法は、後述する。
【0380】
(3)eNBは、予め決められた期間内に「Uu keep alive ind」を受信しない場合は、RRC_IDLEと判断する。予め決められた期間は、UEが「Uu keep alive ind」送信周期より長くすればよい。予め決められた期間は、静的に決定されても、準静的に決定されてもよい。予め決められた期間の決定方法および通知方法は、後述する。この予め決められた期間を、前記データモニタタイマとしてもよい。したがって、UEが「RRC_CONNECTED」の継続を要求している期間、eNBによるデータモニタタイマ満了による、eNBによるRRC_IDLEへの移行起動を避けることができる。これによって、UEとeNBとの間のRRC_CONNECTED状態を継続することが可能となる。データモニタタイマは、Uu点においてデータを受信した場合にタイマをスタートさせる。新たにUu点においてデータを受信した場合は、データモニタタイマをストップし、リセットし、初めからスタートさせる。Uu点におけるデータの具体例として、以下の(3−1)〜(3−3)の3つを開示する。(3−1)RRCレベルでのデータ。(3−2)NASレベルでのデータ。(3−3)前記(3−1),(3−2)の組合せ。
(4)前記(1)〜(3)の組合せ。
【0381】
「Uu keep alive ind」送信周期の決定主体の具体例としては、UE、eNB、APPサーバ(アプリケーション)などがある。
【0382】
UEの「Uu keep alive ind」送信周期の決定方法の具体例として、以下の(1)〜(6)の6つを開示する。
(1)アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するQoS、QCI、ベアラ情報、セッションタイマなどから、UEのNASが「Uu keep alive ind」送信周期を決定してもよい。また通信のエンド−エンド(End−End)となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット(以下「keep-aliveパケット」という)を定期的に送信する周期、あるいは前記周期の整数の逆数倍(1/整数倍)としてもよい。
【0383】
(2)eNBから通知されるDRX周期に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をDRX周期の整数倍、あるいはDRX周期の整数の逆数倍(1/整数倍)としてもよい。これによって、RRC_CONNECTED中のUEがPDCCHをモニタするタイミングであるDRX周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0384】
(3)eNBから通知されるデータモニタタイマに依存して決定するとしてもよい。「Uu keep alive ind」送信周期を、データモニタタイマよりも短い値としてもよい。これによって、UEが「RRC_CONNECTED」の継続を要求している期間、eNBによるデータモニタタイマ満了による、eNBによるRRC_IDLEへの移行起動を避けることができる。
【0385】
(4)タイミングアドバンス(Timing Advance)の有効期間に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をタイミングアドバンスの有効期間の整数倍、あるいはタイミングアドバンスの有効期間の整数の逆数倍(1/整数倍)としてもよい。これによって、RRC_CONNECTED中のUEがRACH処理を行うタイミングであるタイミングアドバンスの有効期間と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0386】
(5)UEの負荷状況、電池残量により決定する。負荷状況が高い場合、または電池残量が少ない場合は、「Uu keep alive ind」送信周期を長くする。負荷状況が低い場合、または電池残量が多い場合は、「Uu keep alive ind」送信周期を短くする、あるいは通常通りとする。これによって、UEの負荷低減、電池残量が少ない場合の対策を行うことが可能となる。
(6)前記(1)〜(5)の組合せ。
【0387】
UEが決定した「Uu keep alive ind」送信周期をeNBに通知する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)「Uu keep alive ind」と共に通知する。「Uu keep alive ind」毎に通知してもよいし、最初の1回通知してもよい。毎回通知する場合と比較して、最初の1回通知する場合は、情報量を削減することができるという効果を得ることができる。
【0388】
(2)「Uu keep alive ind」の送信に先立って通知する。1回通知するとしてもよい。具体例(1)と比較して、eNBにおいて「Uu keep alive ind」用受信準備が可能となるという効果を得ることができる。具体例として、以下の(2−1),(2−2)の2つを開示する。
(2−1)新たにRRCシグナリング、あるいはNASシグナリングを新設する。
(2−2)既存のRRCシグナリング、あるいはNASシグナリングを用いる。本具体例(2−2)は、具体例(2−1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2−2)によって、通信システムが複雑化することを回避することができる。
【0389】
新たにRRCシグナリング、あるいはNASシグナリングにマッピングするパラメータの具体例として、以下の(1)〜(4)の4つを開示する。
(1)「Uu keep alive ind」送信周期。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)接続先であるアプリケーションサーバの情報。
(4)前記(1)〜(3)の組合せ。
【0390】
既存のRRCシグナルを用いる場合の具体例としては、RRC接続再設定「RRC Connection Request」メッセージを用いる場合が挙げられる。
【0391】
既存のRRCシグナリングに追加が必要なパラメータの具体例としては、(1)「Uu keep alive ind」送信周期、(2)接続先であるアプリケーションサーバの情報、などがある。
【0392】
既存のNASシグナルを用いる場合の具体例としては、サービスリクエスト「Service Request」メッセージを用いる場合が挙げられる。
【0393】
既存のNASシグナリングに追加が必要なパラメータの具体例としては、(1)「Uu keep alive ind」送信周期、(2)接続先であるアプリケーションサーバの情報、などがある。
【0394】
eNBの「Uu keep alive ind」送信周期の決定方法の具体例として、以下の(1)〜(5)の5つを開示する。
(1)DRX周期に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をDRX周期の整数倍、あるいはDRX周期の整数の逆数倍(1/整数倍)としてもよい。これによって、RRC_CONNECTED中のUEがPDCCHをモニタするタイミングであるDRX周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0395】
(2)データモニタタイマ、あるいは、アプリケーションのセッションタイマに依存して決定するとしてもよい。「Uu keep alive ind」送信周期を、データモニタタイマよりも短い値としてもよい。これによって、UEが「RRC_CONNECTED」の継続を要求している期間、eNBによるデータモニタタイマ満了による、eNBによるRRC_IDLEへの移行起動を避けることができる。
【0396】
(3)タイミングアドバンス(Timing Advance)の有効期間に依存して決定するとしてもよい。「Uu keep alive ind」送信周期をタイミングアドバンスの有効期間の整数倍、あるいはタイミングアドバンスの有効期間の整数の逆数倍(1/整数倍)としてもよい。これによって、RRC_CONNECTED中のUEがRACH処理を行うタイミングであるタイミングアドバンスの有効期間と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0397】
(4)eNBの負荷状況、ネットワークの負荷状況により決定する。負荷状況が高い場合は、「Uu keep alive ind」送信周期を長くする、あるいは「Uu keep alive ind」送信を禁止、換言すれば「Uu keep alive ind」送信を無限大にする。負荷状況が低い場合は、「Uu keep alive ind」送信周期を短くする、あるいは通常通りとする。これによって、eNB、ネットワークの負荷の低減を行うことが可能となる。ネットワークの負荷状況は、MMEからeNBに通知する、MMEの過負荷を示すメッセージが既存する。S1インタフェース上の「Overload START」メッセージを用いてもよい。「Overload Action」に、「Uu keep alive ind」に関するパラメータを追加してもよい。「Uu keep alive ind」禁止のパラメータを追加してもよい。
(5)前記(1)〜(4)の組合せ。
【0398】
eNBが決定した「Uu keep alive ind」送信周期をUEに通知する方法の具体例として、以下の(1)〜(6)の6つを開示する。
(1)報知情報によって通知する。
(2)個別情報によって通知する。
(3)TAU処理で通知する。具体例としては、「TAU Accept」などによって通知する方法がある。
(4)アタッチ処理で通知する。具体例としては、「Attach Accept」、「RRC Connection Reconfiguration」などによって通知する方法がある。
(5)RRC接続セットアップ処理(RRC Connection Setup Procedure)で通知する。具体例としては、「RRC Connection Setup」などによって通知する方法がある。
(6)サービス要求処理(Service Request Procedure)で通知する。具体例としては、「RRC Connection Reconfiguration」などによって通知する方法がある。
【0399】
APPサーバの「Uu keep alive ind」送信周期の決定方法の具体例を以下に開示する。
【0400】
アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するQoS、QCI、ベアラ情報、セッションタイマなどから、「Uu keep alive ind」送信周期を決定してもよい。また通信のエンド−エンド(End−End)となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット(以下「keep-aliveパケット」という)を定期的に送信する周期、あるいは前記周期の整数の逆数倍(1/整数倍)としてもよい。
【0401】
APPサーバが決定した「Uu keep alive ind」送信周期をeNBに通知するとともに、eNB経由でUEに通知する。
予め決められた回数の決定主体の具体例としては、UE、eNB、APPサーバ(アプリケーション)などがある。
【0402】
UEの予め決められた回数の決定方法の具体例として、以下の(1)〜(3)の3つを開示する。
(1)アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するQoS、QCI、ベアラ情報、セッションタイマなどから、UEのNASが予め決められた回数を決定してもよい。また、通信のエンド−エンド(End−End)となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット(以下「keep-aliveパケット」という)を定期的に送信する周期、または「UE keep alive ind」送信周期としてもよい。
【0403】
(2)eNBから通知されるデータモニタタイマに依存して決定するとしてもよい。予め決められた回数は、データモニタタイマ、または「Uu keep alive ind」送信周期としてもよい。これによって、UEが「RRC_CONNECTED」の継続を要求している期間、eNBによるRRC_IDLEへの移行起動を避けることができる。
(3)前記(1),(2)の組合せ。
【0404】
UEが決定した予め決められた回数をeNBに通知する方法の具体例は、UEが決定した「Uu keep alive ind」送信周期をeNBに通知する方法の具体例と同様であるので、説明を省略する。
【0405】
eNBの予め決められた回数の決定方法の具体例を以下に開示する。データモニタタイマ、あるいはアプリケーションの、セッションタイマに依存して決定するとしてもよい。予め決められた回数は、データモニタタイマ、または「Uu keep alive ind」送信周期としてもよい。これによって、UEが「RRC_CONNECTED」の継続を要求している期間、eNBによるRRC_IDLEへの移行起動を避けることができる。
【0406】
eNBが決定した予め決められた回数をUEに通知する方法の具体例は、eNBが決定した「Uu keep alive ind」送信周期をUEに通知する方法の具体例と同様であるので、説明を省略する。
【0407】
APPサーバの予め決められた回数の決定方法の具体例を以下に開示する。アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するQoS、QCI、ベアラ情報、セッションタイマなどから、予め決められた回数を決定してもよい。また通信のエンド−エンド(End−End)となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット(以下「keep-aliveパケット」という)を定期的に送信する周期、または「UE keep alive ind」送信周期としてもよい。
【0408】
APPサーバが決定した予め決められた回数をeNBに通知するとともに、eNB経由でUEに通知する。
【0409】
予め決められた期間の決定主体の具体例としては、UE、eNB、APPサーバ(アプリケーション)などがある。
【0410】
UEの予め決められた期間の決定方法の具体例として、以下の(1)〜(6)の6つを開示する。
(1)アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するQoS、QCI、ベアラ情報、セッションタイマなどから、UEのNASが予め決められた期間を決定してもよい。また、通信のエンド−エンド(End−End)となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット(以下「keep-aliveパケット」という)を定期的に送信する周期、あるいは前記周期の整数の逆数倍(1/整数倍)としてもよい。また、前記データ量、データ送信周期などを、そのまま予め決められた期間として他ノードへ通知してもよい。アプリケーションが要求するQoS、QCI、ベアラ情報などから、UEのNASがRRC_CONNECTEDを要求する期間、RRC_CONNECTEDが予想される期間を予め決められた期間としてもよい。
【0411】
(2)eNBから通知されるDRX周期に依存して決定するとしてもよい。予め決められた期間をDRX周期の整数倍、あるいはDRX周期の整数の逆数倍(1/整数倍)としてもよい。これによって、RRC_CONNECTED中のUEがPDCCHをモニタするタイミングであるDRX周期と、「Uu keep alive ind」を送信するタイミングである予め決められた期間とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0412】
(3)eNBから通知されるデータモニタタイマに依存して決定するとしてもよい。予め決められた期間を、データモニタタイマよりも短い値としてもよい。これによって、UEが「RRC_CONNECTED」の継続を要求している期間、eNBによるデータモニタタイマ満了による、eNBによるRRC_IDLEへの移行起動を避けることができる。
【0413】
(4)タイミングアドバンス(Timing Advance)の有効期間に依存して決定するとしてもよい。予め決められた期間をタイミングアドバンスの有効期間の整数倍、あるいはタイミングアドバンスの有効期間の整数の逆数倍(1/整数倍)としてもよい。これによって、RRC_CONNECTED中のUEがRACH処理を行うタイミングであるタイミングアドバンスの有効期間と、「Uu keep alive ind」を送信するタイミングである予め決められた期間とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0414】
(5)UEの負荷状況、電池残量により決定する。負荷状況が高い場合、または電池残量が少ない場合は、予め決められた期間を長くする。負荷状況が低い場合、または電池残量が多い場合は、予め決められた期間を短くする、あるいは通常通りとする。これによって、UEの負荷低減、電池残量が少ない場合の対策を行うことが可能となる。
(6)前記(1)〜(5)の組合せ。
【0415】
eNBの予め決められた期間の決定方法の具体例は、eNBの「Uu keep alive ind」送信周期の決定方法と同様であるので、説明を省略する。
【0416】
APPサーバの予め決められた期間の決定方法の具体例を以下に開示する。アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求するQoS、QCI、ベアラ情報、セッションタイマなどから、予め決められた期間を決定してもよい。また、通信のエンド−エンド(End−End)となるアプリケーション間でのセッション接続の監視のみを目的として、データ量の小さなパケット(以下「keep-aliveパケット」という)を定期的に送信する周期、あるいは前記周期の整数の逆数倍(1/整数倍)としてもよい。また、前記データ量、データ送信周期などを、そのまま予め決められた期間として他ノードへ通知してもよい。アプリケーションが要求するQoS、QCI、ベアラ情報などから、UEのNASがRRC_CONNECTEDを要求する期間、RRC_CONNECTEDが予想される期間を予め決められた期間としてもよい。
【0417】
決定主体毎の通知方法は、「Uu keep alive ind」送信周期の決定方法および通知方法と同様であるので、説明を省略する。
【0418】
eNBは、RRC状態判断でRRC_IDLEと判断した場合、IDLE移行処理を実行してもよい。IDLE移行処理の具体例として、以下の(1)〜(3)の3つを開示する。
【0419】
(1)該UEのCONNECTED用にE−UTRANが確保しているシステムリソースを開放する。システムリソースの具体例としては、該UEに対する無線ベアラ、S1ベアラ、EPSベアラなどがある。開放方法の具体例としては、eNBによるS1リリース処理(S1 Release Procedure)の起動、eNBによるMMEへのUEコンテキストリリース処理、S−GWへのアクセスベアラリリース処理、UEへのRRC接続リリース処理などがある。
【0420】
(2)ネットワーク側のECM状態をECM_IDLEへ移行させる。MMEのECM状態をECM_IDLEへ移行させる。移行方法の具体例としては、前記(1)の開放方法の具体例と同様であるので、説明を省略する。
【0421】
(3)ネットワーク側のRRC状態をRRC_IDLEへ移行させる。eNBのRRC状態をRRC_IDLEに移行させる。移行方法の具体例としては、前記(1)の開放方法の具体例と同様であるので、説明を省略する。
【0422】
「Uu keep alive ind」の具体例として、以下の(1)〜(4)の4つを開示する。
(1)Uu点のみのメッセージとする。Uu点とは、UEとeNB、UEとHeNB、またはUEとRNのインタフェース点である。
(2)eNBの上位装置への通知が不要なメッセージとする。上位装置の具体例としては、MME、HSSなどがある。
(3)RRCメッセージとする。
(4)前記(1)〜(3)の組合せ。
【0423】
「Uu keep alive ind」をRRCメッセージとする場合の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにRRCシグナル、あるいはRRCメッセージを設ける。
(2)既存のRRCシグナル、あるいはRRCメッセージを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0424】
新たにRRCシグナルにマッピングするパラメータの具体例として、以下の(1)〜(7)の7つを開示する。
(1)「Uu keep alive ind」である旨、「RRC_CONNECTED」である旨、「RRC_CONNECTED」の継続を要求する旨など。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
【0425】
(3)シーケンス番号。送信毎にインクリメントするようなシーケンス番号としてもよい。セキュリティ対策強化のためのシーケンス番号としてもよい。暗号化鍵を取得された場合であっても、該シーケンス番号が正確でなければ、メッセージを解読できないなど、セキュリティ対策を強化することができる。
【0426】
(4)「Uu keep alive ind」送信周期。「Uu keep alive ind」送信周期を受信したeNBは、データモニタタイマを「Uu keep alive ind」送信周期よりも長く設定してもよい。eNBは、DRX周期を「Uu keep alive ind」送信周期の整数倍、あるいは整数の逆数倍(1/整数倍)と設定してもよい。「Uu keep alive ind」送信周期の決定主体がUEの場合のみ通知するとすればよい。
【0427】
(5)RRC状態判断の際に用いる、予め決められた回数。予め決められた回数の決定主体がUEの場合のみ通知するとしてもよい。
(6)RRC状態判断の際に用いる、予め決められた期間。予め決められた回数の決定主体がUEの場合のみ通知するとしてもよい。
(7)前記(1)〜(6)の組合せ。
【0428】
「Uu keep alive ind」送信周期をDRX周期に依存して決定しない場合であっても、「Uu keep alive ind」を、DRX周期タイミングで送信するとしてもよい。DRX周期のアクティブ期間(on duration期間)で送信するとしてもよい。これによって、RRC_CONNECTED中のUEがPDCCHをモニタするタイミングであるDRX周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0429】
「Uu keep alive ind」送信周期をDRX周期に依存して決定しない場合に、「Uu keep alive ind」を、DRX周期タイミングで送信する方法の具体例を以下に開示する。
【0430】
「Uu keep alive ind」送信周期の満了直後のDRX周期タイミングで、「Uu keep alive ind」を送信する。その場合、eNBは、「Uu keep alive ind」送信周期の満了直後のDRX周期タイミングで、「Uu keep alive ind」を受信すればよい。
【0431】
また、前述の実施の形態2に示す「Uu keep alive ind」は、コネクションの状態通知用のメッセージであるので、通常のユーザデータの送信とは異なり、本データ送信によって、DRX長を変更しないとしてもよい。具体例としては、「Uu keep alive ind」によって、比較的長いDRX周期から比較的短いDRX周期に移行しない。
【0432】
図30に示すシーケンスは、図27図29に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0433】
ステップST5101、ステップST5103〜ステップST5105、ステップST5129〜ステップST5130において、UEとアプリケーションサーバとの間で、エンドツーエンド(End to End)のサービスが実行され、アプリケーションデータがUEからアプリケーションサーバに通信される。
【0434】
UEは、NASからのRRC_IDLEへの移行指示によってRRC接続リリース(RRC Connection release)処理が起動されるまで、ステップST5201〜ステップST5204において、eNBに、「Uu keep alive indication」を通知する。
【0435】
UEは、「Uu keep alive indication」を通知することによって、UEがまだRRC_IDLEに移行しないこと、すなわちRRC_CONNECTED状態であることをeNBに示す。eNBは、UEからの「Uu keep alive indication」を受信することによって、UEがまだRRC_IDLEに移行していないこと、すなわちRRC_CONNECTED状態であることを認識する。
【0436】
eNBは、UEからの「Uu keep alive indication」を受信できたか否かで、eNBとのRRC接続(RRC Connection)状態を判断する。eNBは、「Uu keep alive indication」送信周期のタイミングにおいて、UEからの「Uu keep alive indication」を受信できたか否かを判断する。
【0437】
ステップST5201〜ステップST5204において、UEは、eNBに「Uu keep alive indication」を周期的に送信した後、UEのアプリケーションでデータの発生が無くなると、NASの指示によってUEは、ステップST5131において、RRC接続リリース(RRC Connection Release)処理を行い、ステップST5101において、RRC_IDLEに移行する。UEは、RRC_IDLEに移行すると、「Uu keep alive indication」の送信を停止する。
【0438】
UEが「Uu keep alive indication」の送信を停止すると、eNBは、「Uu keep alive indication」送信周期のタイミングで「Uu keep alive indication」を受信できないことになる。すなわち、ステップST5205において、キープアライブ未達でキープアライブ送信周期タイマが満了する。したがって、eNBは、UEがRRC_IDLEへの移行、またはeNB圏外への移動などの何らかの原因によって、eNBとUEとの間のRRC接続(RRC Connection)中の状態が正常に維持されていないことを認識することができる。
【0439】
ステップST5205において、eNBは、「Uu keep alive indication」送信周期のタイミングにおいて「Uu keep alive indication」を受信できない場合、ステップST5134のS1リリース処理A(S1 Release Procedure A)を起動する。
【0440】
ステップST5134においてS1リリース処理が行われると、eNBは、ステップST5102において、UEに対してRRC_IDLE状態に移行し、MMEは、ステップST5103において、UEに対してECM_IDLE状態に移行する。S1リリース処理において、eNBおよびMMEは、UEに対するシステムリソースをリリースする。
【0441】
本実施の形態で開示した方法によって、E−UTRANは、UEのRRC接続(RRC Connection)状態を認識することができるので、前記状態不一致の期間を多くとも「Uu keep alive indication」送信周期内に収めることができる。したがって、その状態不一致による影響を大幅に軽減することが可能となる。例えば、eNBにおけるUEのためのリソースの不必要な消費を無くすことが可能となる。また、UEへの呼出しが不可能な状態が発生する頻度を低減することが可能となる。
【0442】
また、「Uu keep alive ind」送信周期とDRX周期とを関係付けることで、RRC_CONNECTED中のUEがPDCCHをモニタするタイミングであるDRX周期と、「Uu keep alive ind」を送信するタイミングである「Uu keep alive ind」送信周期とを極力一致させることができるので、UEの低消費電力化を図ることができるという効果を得ることができる。
【0443】
また、「Uu keep alive ind」送信周期とデータモニタタイマとを関係付けることで、UEが「RRC_CONNECTED」の継続を要求している期間、eNBによるデータモニタタイマ満了による、eNBによるRRC_IDLEへの移行起動を避けることができる。これによって、UEとeNBとの間のRRC_CONNECTED状態を継続することが可能となる。
【0444】
実施の形態3.
実施の形態3で解決する課題について、以下に説明する。前述したように、定期的に送信されるkeep-aliveパケット(以下「APP keep alive packet」ともいう)によって、無線アクセスネットワークにおけるシステムリソースを使用してしまい、無線リソースおよび通信ノードにおける処理負荷などの増加を招くという問題が発生している。また、UEの消費電力を増加させるという問題が発生している。
【0445】
これらの問題は、以下のようにして発生する。UEでは、アプリケーションレベルのセッションを接続中であるが、データ送信がないので、RRC接続(RRC connection)および無線アクセスベアラなどを解放する処理を行い、IDLEに移行する。しかし、アプリケーションからkeep-aliveパケットが送信されると、RRC接続(RRC connection)および無線アクセスベアラの設定を行う処理を行う。このようにRRC接続および無線アクセスベアラの解放処理と設定処理とを繰り返すことによって、前述の問題が発生する。
【0446】
図31および図32は、実施の形態3で解決する課題を説明するためのシーケンスを示す図である。図31図32とは、境界線BL7の位置で、つながっている。図31および図32に示すシーケンスは、図27図29に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0447】
ステップST5101、ステップST5104〜ステップST5105、ステップST5129〜ステップST5130において、UEとアプリケーションサーバとの間で、エンドツーエンド(End to End)のサービスが実行され、アプリケーションデータがUEからアプリケーションサーバに通信される。
【0448】
eNBは、データの送受信が行われたか否かをモニタし、所定の期間にデータの送受信が行われなかった場合、ステップST5134のS1リリース処理A(S1 Release Procedure A)を起動する。所定の期間として、データモニタタイマを設けてもよい。ステップST7101において、データモニタタイマが満了したか否かを判断する。ステップST5134のS1リリース処理によって、無線ベアラ、S1ベアラ、EPSベアラがリリースされる。UEは、ステップST5101においてRRC/ECM_IDLE状態に移行する。また、eNBはRRC_IDLE状態に移行し、MMEはECM_IDLE状態に移行する。
【0449】
その後、ステップST7102において、UEのアプリケーションから定期的に送信される「APP keep alive packet」が発生し、UEは、「APP keep alive packet」に応じて再度、ステップST5105のサービス要求処理Aを起動する。サービス要求処理Aによって、UEはRRC/ECM_CONNECTED状態に移行する。また、eNBは、UEに対してRRC_CONNECTED状態に移行し、MMEは、UEに対してECM_CONNECTED状態に移行する。これによって、UEとアプリケーションサーバとの間での通信が可能となる。
【0450】
UEは、ステップST7103において、「APP keep alive packet」をアプリケーションサーバに送信する。
【0451】
eNBは、データの送受信が行われたか否かをモニタしており、UEからアプリケーションサーバへの「APP keep alive packet」の送信後、データの送受信が行われず、ステップST7104において、データモニタタイマが満了した場合、ステップST5134において、再びS1リリース処理Aを起動することになる。このS1リリース処理Aによって、無線ベアラ、S1ベアラ、EPSベアラがリリースされ、ステップST5101において、再びUEは、RRC/ECM_IDLE状態に移行してしまう。また、eNBは、RRC_IDLE状態に移行し、MMEは、ECM_IDLE状態に移行してしまう。
【0452】
「APP keep alive packet」の送信終了後にアプリケーションデータが発生せず、定期的に「APP keep alive packet」が送信される状態になる場合が多く存在するので、前述のように、UEとeNBとの間のRRC接続状態の遷移が頻繁に繰り返されることになる。このようにRRC接続状態の遷移が頻繁に繰り返されると、RRC接続状態の遷移のためのシグナリング量が増大し、無線アクセスネットワークにおけるシステムリソースの増大およびUEの消費電力の増加という問題が発生する。
【0453】
また、UEでは、RRCの状態とECMの状態とは連動して遷移する。ECM_CONNECTED状態のUEにおいてRRC接続(RRC Connection)がリリースされた場合、ECM_IDLE状態となる。RRC接続がリリースされると、RRC_IDLE状態となる。したがって、RRC接続のリリースによって、RRC_CONNECTEDからRRC_IDLEに遷移し、連動してECM_CONNECTEDからECM_IDLEに遷移する(非特許文献14 4.6.4章参照)。
【0454】
ネットワークでは、RRCの状態とECMの状態とは連動して遷移する。ECM_CONNECTED状態のeNBにおいて、対象となるUEのRRC状態がRRC_IDLEに遷移したと想定した場合、S1リリース処理(S1 Release Procedure)が起動される。S1接続がリリースされることから、ECM_CONNECTEDからECM_IDLEに遷移する。したがって、RRC_IDLEへの遷移に連動し、S1接続がリリースされ、ECM_CONNECTEDからECM_IDLEに遷移する(非特許文献14 4.6.4章参照)。
【0455】
前述のように、RRC接続状態の遷移が頻繁に繰り返されることで、ECM状態の遷移も頻繁に繰り返される。これによって、例えばS1ベアラの設立および解放の制御処理が頻繁に行われることとなり、シグナリング量が増大し、無線アクセスネットワークにおけるシステムリソースの増大という問題が発生する。
【0456】
実施の形態3における前記課題の解決策を以下に示す。前述の問題を解決するために、Uu点のRRC状態とAPPのセッションの接続状態とを一致させる。eNBにおいて、そのUEのRRC状態を認識することによって、APPセッションの接続状態を認識し、ネットワーク側エンティティ、例えばS−GWにその情報を通知する。通知を受けたネットワーク側エンティティ、例えばS−GWにおいて、擬似的なkeep-aliveパケット(以下、「擬似APP keep alive packet」または「ローカルAPP keep alive packet」ともいう)の送信制御を行う。
【0457】
なお、eNBにおけるUEのRRC状態認識は、現状の3GPP規格に準ずるものとする。
【0458】
また、UEは、アプリケーションから送信要求のあるkeep-aliveパケットはUu点上に送信しないものとする。
【0459】
Uu点のRRC状態とAPPのセッションの接続状態とを一致させる方法を実行するか否かの判断主体の具体例を以下に示す。(1)UE。(2)ネットワーク側。具体的には、S−GW、あるいはP−GW。
【0460】
判断の具体例として、以下の(1A),(2A)の2つを開示する。
(1A)判断主体がUEの場合について開示する。UEは、アクセス要求を行ったアプリケーションに基づいて判断する。keep-aliveパケットの送信を要求するアプリケーションか否かを判断する。
【0461】
UEは、前記判断の結果、keep-aliveパケットの送信を要求するアプリケーションであると判断した場合は、UE(NAS)において、UEのアプリケーションに対して、ローカルAPP keep alive packetの送信に対するAck(ローカルAck)を通知する。
【0462】
また、UEは、前記判断の結果(以下「APP keep alive情報」と称することもある)をネットワーク側へ通知する。ネットワーク側の具体例としては、ローカルAPP keep alive packetをアプリケーションサーバに送信するエンティティがある。例えば、S−GWなどである。
【0463】
通知方法の具体例としては、UEはMMEに、ローカルAPP keep alive packetの送信の要求を通知する。ローカルAPP keep alive packetの送信の要求を受信したMMEは、S−GWに対して、ローカルAPP keep alive packetの送信の要求を通知する。
【0464】
UEがMMEにローカルAPP keep alive packetの送信の要求を通知する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにNASシグナルを新設する。
(2)既存のNASシグナルを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0465】
新たにNASシグナルにマッピングするパラメータの具体例として、以下の(1)〜(5)の5つを開示する。
(1)ローカルAPP keep alive packetの送信の要求である旨、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報など。以下、「APP keep alive情報」と称することもある。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)接続先であるアプリケーションサーバの情報。
(4)keep-aliveパケットの送信周期。
(5)前記(1)〜(4)の組合せ。
【0466】
既存のNASシグナルを用いる場合の具体例としては、サービス要求(Service Request)メッセージを用いる場合が挙げられる。
【0467】
既存のNASシグナリングに追加が必要なパラメータの具体例として、以下の(1)〜(3)の3つを開示する。
(1)ローカルAPP keep alive packetの送信の要求である旨など、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報など。
(2)接続先であるアプリケーションサーバの情報。
(3)keep-aliveパケットの送信周期。
【0468】
MMEがS−GWにローカルAPP keep alive packetの送信の要求を通知する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにS11シグナルを新設する。
(2)既存のS11シグナルを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0469】
新たにS11シグナルにマッピングするパラメータの具体例として、以下の(1)〜(5)の5つを開示する。
(1)ローカルAPP keep alive packetの送信の要求である旨など、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報など。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)接続先であるアプリケーションサーバの情報。
(4)keep-aliveパケットの送信周期。keep−aliveパケットの送信周期を受信したS−GWは、ローカルAPP keep alive packetの送信周期をkeep−aliveパケットの送信周期と同じに設定してもよい。
(5)前記(1)〜(4)の組合せ。
【0470】
既存のS11シグナルを用いる場合の具体例としては、ベアラ修正要求(Modify Bearer Request)メッセージを用いる場合が挙げられる。
【0471】
既存のS11シグナリングに追加が必要なパラメータの具体例として、以下の(1)〜(3)の3つを開示する。
(1)ローカルAPP keep alive packetの送信の要求である旨など、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報など。
(2)接続先であるアプリケーションサーバの情報。
(3)keep-aliveパケットの送信周期など。
【0472】
keep−aliveパケットの送信周期を受信したS−GWは、ローカルAPP keep alive packetの送信周期を、keep−aliveパケットの送信周期と同じに設定してもよい。
【0473】
(2A)判断主体がネットワーク側、例えばS−GWの場合について開示する。S−GWは、アクセス要求を行ったアプリケーションに基づいて判断する。keep-aliveパケットの送信を要求するアプリケーションか否かを判断する。
【0474】
S−GWは、前記判断の結果、keep-aliveパケットの送信を要求するアプリケーションであると判断した場合は、ローカルAPP keep alive packetをアプリケーションサーバに送信する。
【0475】
また、S−GWは、前記判断の結果(以下「APP keep alive情報」と称することもある)をUE側に通知する。
【0476】
通知方法の具体例としては、S−GWはMMEにローカルAPP keep alive packetの送信に対するAck(ローカルAck)送信の要求を通知する。ローカルAPP keep alive packetの送信に対するAck(ローカルAck)送信の要求を受信したMMEは、eNB経由で、UEに対してローカルAPP keep alive packet送信に対するAck(ローカルAck)送信の要求を通知する。
【0477】
S−GWがMMEにローカルAPP keep alive packetの送信に対するAck(ローカルAck)送信の要求を通知する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにS11シグナルを新設する。
(2)既存のS11シグナルを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0478】
新たにS11シグナルにマッピングするパラメータの具体例として、以下の(1)〜(5)の5つを開示する。
(1)ローカルAPP keep alive packetの送信に対するAck(ローカルAck)送信の要求である旨など、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報など。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)接続先であるアプリケーションサーバの情報。
(4)ローカルAPP keep alive packet送信周期。
(5)前記(1)〜(4)の組合せ。
【0479】
既存のS11シグナルを用いる場合の具体例としては、ベアラ修正応答(Modify Bearer Response)メッセージを用いる場合が挙げられる。
【0480】
既存のS11シグナリングに追加が必要なパラメータの具体例として、以下の(1)〜(3)の3つを開示する。
(1)ローカルAPP keep alive packetの送信に対するAck(ローカルAck)送信の要求である旨など、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報など。
(2)接続先であるアプリケーションサーバの情報。
(3)ローカルAPP keep alive packetの送信周期。
【0481】
MMEがUEにローカルAPP keep alive packetの送信に対するAck(ローカルAck)の要求を通知する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにシグナルを新設する。
(2)既存のシグナルを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0482】
新たにNASシグナルにマッピングするパラメータの具体例として、以下の(1)〜(5)の5つを開示する。
(1)ローカルAPP keep alive packetの送信に対するAck(ローカルAck)送信の要求である旨、Uu点のRRC状態とAPPのセッションの接続状態を一致させることを設定するための情報など。以下、「APP keep alive情報」と称することもある。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)接続先であるアプリケーションサーバの情報。
(4)ローカルAPP keep alive packet送信周期。
(5)前記(1)〜(4)の組合せ。
【0483】
次に、既存のシグナルを用いる場合の具体例としては、サービス要求(Service Request)処理を用いる。具体的には、サービス要求処理中の初期コンテキストセットアップ要求(Initial Context Setup Request)、RRC接続再設定(RRC Connection Reconfiguration)などがある。
【0484】
既存のシグナリングに追加が必要なパラメータの具体例として、以下の(1)〜(3)の3つを開示する。
(1)ローカルAPP keep alive packetの送信に対するAck(ローカルAck)送信の要求である旨など、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報など。
(2)接続先であるアプリケーションサーバの情報。
(3)ローカルAPP keep alive packetの送信周期。
【0485】
図33図35は、実施の形態3における通信システムのシーケンスの一例を示す図である。図33図34とは、境界線BL8の位置で、つながっている。図34図35とは、境界線BL9の位置で、つながっている。図33図35に示すシーケンスは、図27図29に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0486】
UEは、TCP/IP上で実行されるアプリケーションを有する。図33図35では、ステップST5101において、UEは、RRC_IDLE状態にあり、ステップST5102において、eNBは、UEに対してRRC_IDLE状態にあり、ステップST5103において、MMEは、UEに対してECM_IDLE状態にある場合について示している。
【0487】
UEのアプリケーションがアクセス開始するような場合、ステップST5104において、UEのアプリケーションは、UEのNASに対してアクセス要求(Access Request)を行う。このアクセス要求に従い、UEは、ステップST7201において、サービス要求処理B(Service Request Procedure B)を起動する。
【0488】
ステップST7201のサービス要求処理Bは、図27のステップST5105のサービス要求処理Aの一部を変更すればよい。以下に、変更部分について説明する。
【0489】
ステップST7202においてUEのNASからASに通知するサービス要求メッセージに、「APP keep alive情報」を含める。「APP keep alive情報」は、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するための情報である。例えば、設定するか否かを示す情報としてもよいし、設定する場合にのみ該情報をメッセージに含めるようにしてもよい。
【0490】
UEは、ステップST7203において、サービス要求メッセージに「APP keep alive情報」を含めてeNBに通知する。
【0491】
ステップST7203で「APP keep alive情報」を受信したeNBは、ステップST7204のサービス要求メッセージに、「APP keep alive情報」を含めてMMEに通知する。
【0492】
「APP keep alive情報」を受信したMMEは、ステップST7205のベアラ修正要求メッセージに「APP keep alive情報」を含めてS−GWに通知する。このようにすることによって、ネットワーク側のエンティティであるS−GWに、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するか否かを通知することが可能となる。したがって、S−GWは、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることを設定するか否かに応じた処理を行うことが可能となる。
【0493】
図33図35に示す例では、ステップST7202、ステップST7203、ステップST7204、ステップST7205の「APP keep alive情報」として、Uu点のRRC状態とAPPのセッションの接続状態とを一致させるように設定する場合について示している。
【0494】
UEは、アプリケーションから送信要求のあるkeep-aliveパケットをUu点上に送信しないものとする。図35のステップST7206において、UEは、アプリケーションにおいて、APP keep alive packet送信周期タイマ(以下「キープアライブ送信周期タイマ」という場合がある)が満了したか否かを判断する。キープアライブ送信周期タイマが満了したと判断された場合は、ステップST7207において、NASに対して「APP keep alive packet」を送信する。「APP keep alive packet」の発生で、UEは、「APP keep alive packet」をUu点上に送信しないので、サービス要求処理を起動しない。
【0495】
なお、UEにおいて、アプリケーションからの「APP keep alive packet」を受信したNASは、ステップST7209において、応答メッセージをアプリケーションに通知してもよい。この応答メッセージを、ローカル応答と称する。UEのNASは、RRC/ECMの状態を認識し、RRC/ECM_CONNECTED状態の場合、アプリケーションに対してAck(ローカルAck)を通知する。RRC/ECM_IDLE状態の場合、アプリケーションに対してNack(ローカルNack)を通知する。
【0496】
ローカルAckを受信したUEのアプリケーションは、RRC/ECMが接続されている状態と判断し、「APP keep alive packet」の送信を継続してセッションの接続状態を保つ。ローカルNackを受信したUEのアプリケーションは、RRC/ECMが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
【0497】
ステップST7209においてNASからローカルAckを受信したアプリケーションは、ステップST7211においてキープアライブ送信周期タイマが満了したと判断された場合、ステップST7213において、継続して「APP keep alive packet」の送信を行う。UEのRRC/ECMの状態が接続状態であるので、ステップST7215において、NASは、ローカルAckをアプリケーションに通知する。
【0498】
一方、ネットワーク側エンティティ、例えばS−GWは、擬似的なkeep-aliveパケット(以下「ローカルAPP keep alive packet」ともいう)の送信制御を行う。Uu点のRRC状態とAPPのセッションの接続状態とを一致させる設定の「APP keep alive情報」を受信したS−GWは、ローカルAPP keep alive packetを発生させ、アプリケーションサーバに送信することを決定する。
【0499】
S−GWは、ローカルAPP keep alive packetを定期的または周期的に発生させ、EPSベアラが設立されている限り、ローカルAPP keep alive packetを定期的または周期的に発生させ、アプリケーションサーバに送信する。
【0500】
ステップST7205において、Uu点のRRC状態とAPPのセッションの接続状態とを一致させる設定の「APP keep alive情報」を受信したS−GWは、ステップST7208において、ローカルAPP keep alive packet送信周期タイマ(以下「ローカルキープアライブ送信周期タイマ」という場合がある)が満了したか否かを判断する。
【0501】
S−GWは、ローカルキープアライブ送信周期タイマが満了したと判断した場合は、ステップST7210において、ローカル(Local)APP keep alive packetをアプリケーションサーバに送信する。
【0502】
S−GWは、EPSベアラが設立されているか否かを判断し、設立されていると判断した場合は、継続してステップST7212において、ローカルキープアライブ送信周期タイマが満了したか否かを判断する。S−GWは、ローカルキープアライブ送信周期タイマが満了したと判断した場合は、ステップST7214において、ローカル(Local)APP keep alive packetをアプリケーションサーバに送信する。
【0503】
ここで、ローカルAPP keep alive packetを受信したAPPサーバは、S−GWに対して応答信号(Ack)を送信してもよい。応答信号は、応答メッセージであってもよい。アプリケーション側で、該UEとのセッション終了となった場合は、APPサーバから、S−GWに対して、前記応答信号が送信されないようにしてもよい。
【0504】
S−GWは、ローカルAPP keep alive packetに対する、APPサーバからの応答信号を受信した場合、該UEに対するセッションが継続していると判断してもよい。一方、ローカルAPP keep alive packetに対する、APPサーバからの応答信号を受信しない場合、S−GWは、該UEに対するセッションが終了していると判断してもよい。該UEに対するセッションが終了していると判断した場合、S−GWは、EPSベアラのリリース処理を起動してもよい。
【0505】
ステップST7216において、eNBは、データの送受信が行われたか否かをモニタする。所定の期間にデータの送受信が行われなかった場合、ステップST5134のS1リリース処理Aを起動する。Uu点のRRC状態とAPPのセッションの接続状態とを一致させる設定を行った場合、ステップST7216において、データモニタタイマを長期間に設定する。図31および図32のステップST7101、ステップST7104およびステップST7118に示したデータモニタタイマよりも長期間に設定するとよい。
【0506】
ステップST5134のS1リリース処理Aによって、無線ベアラ、S1ベアラ、EPSベアラがリリースされる。ステップST5101において、UEは、RRC/ECM_IDLE状態に移行する。ステップST5102において、eNBは、UEに対してRRC_IDLE状態に移行する。ステップST5103において、MMEは、UEに対してECM_IDLE状態に移行する。
【0507】
また、UEがデータの送受信が行われたか否かをモニタしてもよい。所定の期間にデータの送受信が行われなかった場合、UEのNASは、アプリケーションから「APP keep alive packet」を受信した場合においても、ローカル応答をアプリケーションに通知しないようにしてもよい。これによって、UE側のアプリケーションは、セッションが終了されたと認識する。
【0508】
また、所定の期間にデータの送受信が行われなかった場合、UEはMMEにローカルAPP keep alive packetの送信停止の要求を通知する。ローカルAPP keep alive packetの送信停止の要求を受信したMMEは、S−GWに対してローカルAPP keep alive packetの送信停止の要求を通知するようにしてもよい。ローカルAPP keep alive packetの送信停止の要求を受信したS−GWは、ローカルAPP keep alive packetの送信を停止する。これによって、APPサーバ側のアプリケーションにおいても該UEに対するセッションを終了させることが可能となる。
【0509】
ステップST5101においてRRC/ECM_IDLE状態になったことを認識したUEは、ステップST7218において、アプリケーションに対してRRC/ECM_IDLE状態になったことを通知する。このメッセージを、ローカルリリースと称する。ローカルリリースを受信したアプリケーションは、RRC/ECMが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
【0510】
一方、EPSベアラがリリースしたことを認識したS−GWは、ステップST7217において、ローカルAPP keep alive packet(以下「ローカルキープアライブパケット」という場合がある)の生成を停止する。
【0511】
ステップST7219において、S−GWは、アプリケーションサーバに対してアプリケーションセッションのリリース(Local APP Session Release)メッセージを通知する。アプリケーションセッションのリリースメッセージ内に、ローカルAPP keep alive packetの生成を停止する理由の情報を含めてもよい。また、ローカルAPP keep alive packetの生成を停止する場合のアプリケーションセッションリリースメッセージを新たに設けてもよい。ローカルAPP keep alive packetの生成を停止する場合のアプリケーションセッションリリースメッセージを、ローカルアプリケーションリリースと称する。アプリケーションリリースメッセージを受信したアプリケーションサーバは、EPSベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。また、セッションの再起動を行ってもよい。
【0512】
前述の方法を行うことによって、Uu点のRRC状態とAPPのセッションの接続状態とを一致させることができる。これによって、Uu点においてアプリケーションからのkeep-aliveパケットの発生によってRRCおよびRABの状態を適宜変化させる必要が無くなる。
【0513】
ステップST7216のデータモニタタイマを長期間に設定することで、ステップST5134のS1リリース処理Aを起動させる頻度を削減することが可能となる。したがって、無線ベアラ、S1ベアラ、EPSベアラがリリースされる頻度を削減することができ、アプリケーションからの「APP keep alive packet」送信のためにRRC/ECM状態を移行させるためのシグナリングを削減することが可能となる。これによって、アプリケーションからのkeep-aliveパケットの発生による不要なシグナリングの増大を抑制することができ、システムリソースに対する影響を軽減することができる。
【0514】
実施の形態3 変形例1.
実施の形態3の変形例1で解決する課題は、前述の実施の形態3における課題と同一であり、以下に説明する。実施の形態3においては、UEとeNBのRRC接続(RRC Connection)の状態を用いていたので、前述の実施の形態2において挙げた、UEとeNBとの間での状態不一致の課題が発生し得る。
【0515】
前記課題を解決するために、実施の形態3の変形例1では、前述の実施の形態2の対策案を実施の形態3において適用する。図36および図37は、実施の形態3の変形例1における通信システムのシーケンスの一例を示す図である。図36図37とは、境界線BL10の位置で、つながっている。図36および図37に示すシーケンスは、図33図35に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0516】
ステップST5101〜ステップST5104、ステップST7201、ステップST5129〜ステップST5130において、UEとアプリケーションサーバとの間でエンドツーエンド(End to End)のサービスが実行され、アプリケーションデータがUEからアプリケーションサーバに通信される。
【0517】
本変形例では、前述の実施の形態3で開示した方法を用いるので、サービス要求処理として、ステップST7201において、「APP keep alive情報」を用いるサービス要求処理Bを行う。図36および図37では、「APP keep alive情報」として、Uu点のRRC状態とAPPのセッションの接続状態とを一致させるように設定する場合のシーケンスについて示している。
【0518】
前述の実施の形態3で開示したように、UEは、アプリケーションから送信要求のあるkeep-aliveパケットをUu点上に送信しないものとする。また、ネットワーク側エンティティ、例えばS−GWは、ローカルAPP keep alive packetの送信制御を行う。このため、ステップST7206〜ステップST7215の処理が行われる。
【0519】
前述の実施の形態3では、ステップST5130のデータ送信が行われた後、ステップST7216においてデータモニタタイマが満了し、ステップST5134においてS1リリース処理が行われるまで、UEとeNBとのRRC接続(RRC Connection)の状態が維持される。この状態において、UEがeNB圏外へ移動したり、UEでの受信品質の劣化などの何らかの原因によって、eNBとのRRC接続(RRC Connection)中の状態が正常に維持されなくなる場合がある。このような場合、UEは、RRC状態をRRC_IDLEに移行するが、eNBでは、RRC_CONNECTED状態を維持したままとなる。したがって、UEとeNBとの間で状態不一致が生じるという問題が発生する。
【0520】
また、UEとeNBとの間で状態不一致が生じたときに、RRC_IDLE状態になったことを認識したUEは、アプリケーションに対してRRC_IDLE状態になったことを通知する。この通知を受信したアプリケーションは、RRCが接続されていない状態と判断し、「APP keep alive packet」の送信を停止し、セッションを終了する。このように、UEのアプリケーションではセッションが終了する。しかし、eNBは、RRC_CONNECTED状態を維持しているので、MMEは、ECM_CONNECTED状態を維持し、S−GWは、継続してローカルkeep alive packetを生成してアプリケーションサーバに送信する。したがって、アプリケーションサーバでは、セッションが接続されていると認識する。このように、UE側のアプリケーションとアプリケーションサーバとでも状態不一致が発生することになる。
【0521】
前述の実施の形態2では、このような状態不一致の問題を改善するために、Uu点において、UEのRRC接続(RRC Connection)中の状態通知用のメッセージを設け、UEが、RRC_CONNECTED状態においては、定期的あるいは周期的に「Uu keep alive indication」を送信する方法を開示した。
【0522】
本変形例では、この実施の形態2の対策案を適用する。図36および図37に示す例において、ステップST5130のデータ送信が行われた後、RRC_CONNECTED状態にあるUEは、ステップST7301〜ステップST7305に示すように、「Uu keep alive indication」を周期的にeNBに通知する。UEは、「Uu keep alive indication」を通知することによって、UEがまだRRC_IDLEに移行しないこと、すなわちRRC_CONNECTED状態であることをeNBに示す。
【0523】
eNBは、UEからの「Uu keep alive indication」を受信することで、UEがまだRRC_IDLEに移行していない、すなわちRRC_CONNECTED状態であると認識する。eNBは、UEからの「Uu keep alive indication」を受信できたか否かで、eNBとのRRC接続(RRC Connection)の状態を判断する。eNBは、「Uu keep alive indication」送信周期のタイミングにおいて、UEからの「Uu keep alive indication」を受信できたか否かを判断する。
【0524】
ステップST7304において、UEは、eNBに「Uu keep alive indication」を送信するが、何らかの原因によって、UEとeNBとのRRC接続(RRC Connection)状態が正常に維持されなくなり、eNBに「Uu keep alive indication」が未達になる場合がある。この場合、ステップST5205において、eNBは、「Uu keep alive indication」送信周期のタイミングで「Uu keep alive indication」を受信できないことになる。したがって、eNBは、UEが何らかの原因によって、eNBとUEとの間のRRC接続(RRC Connection)中の状態が正常に維持されていないことを認識し、ステップST5134のS1リリース処理Aを起動する。
【0525】
ステップST5134においてS1リリース処理が行われると、UEは、ステップST5101において、RRC_IDLE状態に移行する。eNBは、ステップST5102において、UEに対してRRC_IDLE状態に移行する。MMEは、ステップST5103において、UEに対してECM_IDLE状態に移行する。S1リリース処理において、eNBおよびMMEは、UEに対するシステムリソースをリリースする。
【0526】
ステップST5101においてRRC/ECM_IDLE状態になったことを認識したUEは、ステップST7218において、アプリケーションに対してRRC/ECM_IDLE状態になったことを通知する。ローカルリリースを受信したアプリケーションは、RRC/ECMが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
【0527】
ステップST5134においてS1リリース処理が行われ、EPSベアラがリリースされたことを認識したS−GWは、ステップST7217において、ローカルAPP keep alive packetの生成を停止する。
【0528】
ステップST7219において、S−GWは、アプリケーションサーバに対してローカルアプリケーションセッションリリースメッセージを通知する。ローカルアプリケーションリリースメッセージを受信したアプリケーションサーバは、EPSベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。
【0529】
本実施の形態で開示した方法により、E−UTRANは、UEのRRC接続(RRC Connection)状態を認識できるので、前述の実施の形態3で開示した方法において発生する前記状態不一致の期間を無くすことができる。したがって、その状態不一致による影響を大幅に軽減することが可能となる。例えば、eNBにおけるUEのためのリソースの不必要な消費を無くすことが可能となる。また、UEへの呼出しが不可能な状態が発生する頻度を低減することが可能となる。
【0530】
図36および図37で示した例では、UEは、ステップST5134のS1リリース処理によって、ステップST5101においてRRC/ECM_IDLE状態に移行した。他の方法として、RRC_CONNECTED状態にいるUEが、受信品質の劣化などの何らかの原因によってRRC_IDLE状態に移行した場合に、UEがRRC_IDLE状態に移行したと判断し、UEのアプリケーションに対してローカルリリースメッセージを通知してもよい。UEは、RRC_IDLE状態に移行した場合、同時にECM_IDLE状態に移行したと判断してもよい。この場合、ステップST5134のS1リリース処理よりも前に、UEは、RRC/ECM_IDLE状態に移行し、UEのアプリケーションは、「APP keep alive packet」の送信を停止あるいはセッションの接続を切断する。
【0531】
この場合も、前述の実施の形態3で開示した方法において発生する前記状態不一致の期間を多くとも「Uu keep alive indication」送信周期内に収めることができる。したがって、その状態不一致による影響を大幅に軽減することが可能となる。例えば、eNBにおけるUEのためのリソースの不必要な消費の削減、およびUEへの呼出しが不可能な状態が発生する頻度を低減することが可能となる。
【0532】
実施の形態4.
実施の形態4で解決する課題は、前述の実施の形態3おける課題と同一であり、以下に説明する。
【0533】
前述の実施の形態3においては、RRC接続(RRC Connection)の状態とアプリケーションレベルのセッションの状態とを一致させたいので、アプリケーションレベルのセッションの接続中は、RRC接続(RRC Connection)を維持する必要があった。このことは、keep-aliveパケットによる影響を避けられる効果は大きいが、その代償として、RRC接続(RRC Connection)を維持するための無線リソースを使用することとなる。
【0534】
実施の形態4における前記課題の解決策を以下に示す。前述の問題を解決するために、RRC_IDLE状態においてアプリケーションのセッションの接続状態を通知するUu点メッセージ(uu keep alive packet)を設ける。UEは、RRC_IDLE状態に遷移した状態において、定期的あるいは周期的に「uu keep alive packet」を送信する。eNBは、UEからの「uu keep alive packet」の受信およびUEに対するRRC状態から、UEのアプリケーションのセッションの接続状態を認識し、何らかのネットワーク装置、例えばS−GWにその情報を通知する。通知を受けた前記ネットワーク装置であるS−GWにおいて、ローカルAPP keep alive packetの送信制御を行う。「uu keep alive packet」は、UEがRRC_IDLEのときのみ送信する。「uu keep alive packet」送信において、RRC状態は変化させない。つまり、IDLE時は、RRC接続を開設せずに通知する。例えば、RACHを用いて通知する。なお、前述の実施の形態3と同様に、UEは、アプリケーションから送信要求のあるkeep-aliveパケットはUu点上に送信しないものとする。
【0535】
図38および図39は、実施の形態4における通信システムのシーケンスの一例を示す図である。図38図39とは、境界線BL11の位置で、つながっている。図38および図39に示すシーケンスは、図33図35に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0536】
ステップST5101〜ステップST5104、ステップST7201、ステップST5129〜ステップST5130において、UEとアプリケーションサーバとの間でエンドツーエンド(End to End)のサービスが実行され、アプリケーションデータがUEからアプリケーションサーバに通信される。
【0537】
本変形例では、前述の実施の形態3で開示した方法を用いるので、サービス要求処理として、ステップST7201において、「APP keep alive情報」を用いるサービス要求処理Bを行う。図38および図39では、「APP keep alive情報」として、Uu点のRRC状態とAPPのセッションの接続状態とを一致させるように設定する場合のシーケンスについて示している。
【0538】
前述の実施の形態3で開示したように、UEは、アプリケーションから送信要求のあるkeep-aliveパケットをUu点上に送信しないものとする。また、ネットワーク側エンティティ、例えばS−GWは、ローカルAPP keep alive packetの送信制御を行う。このため、ステップST7206〜ステップST7215の処理が行われる。
【0539】
前述の実施の形態3では、RRC接続(RRC Connection)の状態とアプリケーションレベルのセッションの状態とを一致させたいので、アプリケーションレベルのセッションの接続中は、RRC接続(RRC Connection)を維持する必要があった。したがって、ステップST5130のデータ送信が行われた後、ステップST7216においてデータモニタタイマが満了し、ステップST5134においてS1リリース処理が行われるまで、UEとeNBとのRRC接続(RRC Connection)の状態が維持される。このことは、keep-aliveパケットによる影響を避けられる効果は大きいが、その代償として、RRC接続(RRC Connection)を維持するための無線リソースを使用することとなる。
【0540】
本実施の形態では、このような問題を改善する方法を開示する。図38のステップST5130のデータ送信が行われた後、UEに対するRRC接続(RRC connection)がRRC_CONNECTED状態にあるeNBは、所定の期間に、UEへのデータの発生の有無をモニタする。またはUEとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。所定の期間を計測する手段として、タイマを設けてもよい。以下、このタイマを「RRCデータモニタタイマ」と称する。
【0541】
eNBは、ステップST7402でUEへのデータが発生せず、RRCデータモニタタイマが満了した場合、ステップST7403において、RRC接続のリリース処理を起動する。この処理により、ステップST7404およびステップST7405において、eNBとUEとは、RRC_IDLE状態に移行する。
【0542】
前述の処理では、UEとeNBとの間のRRC接続状態のみを、RRC_CONNECTED状態からRRC_IDLE状態に移行させる。このようにすることによって、UEとeNBとは、RRC接続のための無線リソースをリリースできる。
【0543】
UEは、eNBからのRRC接続リリースメッセージに従って、RRC_IDLE状態に移行することを開示したが、他の方法として、UEにおいてもeNBへのデータの発生の有無をモニタしてもよい。またはeNBとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。データの発生が無く、UE側のRRCデータモニタタイマが満了した場合、RRC接続のリリース処理を起動し、RRC_IDLE状態に移行する。また、他の方法として、UEは、RRCの規定に従い、RRC_IDLE状態に移行してもよい。RRCの規定としては、例えば、RLF(Rsdio Link Failure)などがある。
【0544】
本実施の形態では、ステップST7404でRRC_IDLE状態に移行したUEは、アプリケーションに対してRRC_IDLE状態になったことを通知しないようにする。あるいは、RRC_IDLE状態に移行したUEは、アプリケーションに対してRRC_IDLE状態になったことを通知するが、アプリケーションは、RRC_IDLE状態になったことの通知を受信したとき、「APP keep alive packet」の送信の停止、またはセッションの接続の切断を行わないようにしてもよい。RRC_IDLE状態になったことの通知に、RRC状態のみ、RRC_IDLE状態に移行したことを示す情報を含めておくとよい。あるいは、UEにおいて、RRC状態、ECM状態など、どの状態がIDLEに移行したかどうかの情報としてもよい。あるいは、無線ベアラ、S1ベアラ、EPSベアラなど、どのベアラがリリースされたかを示す情報としてもよい。前記情報に基づいて、UEのアプリケーションは、「APP keep alive packet」の送信の停止、またはセッションの接続の切断を行うかどうかを判断することができる。
【0545】
ステップST7404において、RRC_IDLE状態に遷移したUEは、アプリケーションのセッションが接続していることをeNBに通知するために、ステップST7207において、「uu keep alive packet」をeNBに送信する。「uu keep alive packet」の送信は、アプリケーションのセッションが接続している限り、ステップST7406〜ステップST7408において周期的に継続して行われる。
【0546】
eNBは、RRC状態を判断し、RRC_IDLE状態において「uu keep alive packet」を受信することによって、UEのアプリケーションのセッションの接続状態を認識することが可能となる。UEのアプリケーションのセッションが接続状態に有る場合、eNBはS1リリース処理など、S1ベアラおよびEPSベアラのリリース処理を行わない。S1リリース処理が行われないので、S−GWは、ローカルkeep alive packetを生成し、アプリケーションサーバに対して通知する。これによって、アプリケーションサーバは、UEとの接続を認識することができ、セッションを接続状態に保つことができる。
【0547】
「uu keep alive packet」は、UEがRRC_IDLE時のみに送信するが、「uu keep alive packet」送信において、RRC状態は変化させない。つまり、IDLE時は、RRC接続(RRC connection)を設立せずに通知する。例えば、RACHを用いて通知する。これによって、「uu keep alive packet」送信時にRRC状態の遷移が不要になり、シグナリング量を削減することができる。
【0548】
アプリケーションセッションが接続状態にある場合に、ステップST7409において、UEは、eNBに「uu keep alive packet」を送信するが、何らかの原因によって、eNBに「uu keep alive packet」が未達になる場合がある。例えば、UEがeNBの圏外に移動したような場合に生じる。この場合、ステップST7410において、eNBは、「uu keep alive packet」送信周期のタイミングで「uu keep alive packet」を受信できないことになる。
【0549】
したがって、eNBは、UEが何らかの原因によって、eNBとUEとの間においてRRC接続(RRC Connection)することが不可能であることを認識し、ステップST5134のS1リリース処理Aを起動する。
【0550】
既存のS1リリース処理に限らず、eNBがS−GWに、該UEのRRC_IDLE状態への移行を通知するメッセージを新たに設けてもよい。
【0551】
新たに設けるメッセージの具体例としては、eNBが該UEに対する無線リソースを解放している場合においては、RRC接続処理を伴わず、S1ベアラのリリース処理を行うメッセージとする。あるいは、既存のS1リリース処理において、該UEに対する無線リソースの有無を示す情報を新たに設けてもよい。該情報は、アクティブフラグであってもよい。
【0552】
ステップST5134において、S1リリース処理Aが行われると、ステップST5101において、UEはRRC/ECM_IDLE状態に移行する。ステップST5102において、eNBは、UEに対してRRC_IDLE状態を維持する。ステップST5103において、MMEは、UEに対してECM_IDLE状態に移行する。S1リリース処理において、eNBおよびMMEは、UEに対するシステムリソースをリリースする。
【0553】
ステップST5101でRRC/ECM_IDLE状態になったことを認識したUEは、ステップST7218において、アプリケーションに対してRRC/ECM_IDLE状態になったことを通知する。ローカルリリースを受信したアプリケーションは、RRC/ECMが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
【0554】
ステップST5134において、S1リリース処理が行われ、EPSベアラがリリースされたことを認識したS−GWは、ステップST7217において、ローカルAPP keep alive packetの生成を停止する。
【0555】
ステップST7219において、S−GWは、アプリケーションサーバに対してローカルアプリケーションセッションリリースメッセージを通知する。ローカルアプリケーションリリースメッセージを受信したアプリケーションサーバは、EPSベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。
【0556】
本実施の形態で開示した方法によって、アプリケーションのセッションを接続状態に保ったまま、UEは、RRC_IDLEに遷移可能である。したがって、UEとeNBとの間でのRRC接続(RRC Connection)の維持が不要となり、不要な無線リソースの使用を削減することができる。
【0557】
本実施の形態で開示し方法では、RRC_IDLE状態において、「uu keep alive packet」を送信する必要があるので、その無線リソースを使用することとなる。したがって、運用状況に応じて、他の実施の形態を含めた方法の中から適切に選択するとよい。
【0558】
実施の形態4 変形例1.
実施の形態4の変形例1で解決する課題は、前述の実施の形態4における課題と同一であり、以下に説明する。実施の形態4においても、RRCデータモニタタイマの満了によって、RRC接続リリース処理が行われるまでは、RRC接続(RRC Connection)の状態を用いるので、前述の実施の形態2において挙げた、UEとeNBとの間での状態不一致の課題が発生し得る。また、IDLE時の「uu keep alive packet」による情報とRRC状態の2つ情報から、アプリケーションレベルのセッション状態の判定を行うので、実装が煩雑になる。
【0559】
実施の形態4の変形例1における前記課題を解決するために、前述の実施の形態2の対策案を実施の形態4において適用する。なお、前述の実施の形態2と同様に、RRC_CONNECTED状態における「Uu keep alive indication」の送信によって、DRX長を変更すべきではない。また、RRC_CONNECTED状態における「Uu keep alive indication」の送信とRRCデータモニタタイマとは、独立に運用される。すなわち、UEは、RRC接続状態がどの状態であっても、「Uu keep alive indication」または「Uu keep alive packet」を通知することによって、アプリケーションセッションが接続している状態であることをeNBに通知する。RRC_CONNECTED状態の場合は、「Uu keep alive indication」が用いられ、RRC_IDLE状態の場合は、「Uu keep alive packet」が用いられる。「Uu keep alive indication」と「Uu keep alive packet」とを同じ名称のメッセージ、例えば「Uu keep alive」として、RRC接続状態によらず使用可能としてもよい。
【0560】
図40および図41は、実施の形態4の変形例1における通信システムのシーケンスの一例を示す図である。図40図41とは、境界線BL12の位置で、つながっている。図40および図41に示すシーケンスは、図38および図39に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0561】
UEとeNBとは、ステップST7201のサービス要求処理B(Service Request Procedure B)において、RRC_CONNECTED状態およびECM_CONNECTED状態に移行する。
【0562】
ステップST5130において、UEとアプリケーションサーバとの間で、エンドツーエンド(End to End)のサービスが実行され、アプリケーションデータがUEからアプリケーションサーバに通信される。
【0563】
UEは、アプリケーションセッションの接続を保つために、ステップST7501において、RRC_CONNECTED状態における「Uu keep alive indication」をeNBに送信し、アプリケーションセッションが接続している状態であること通知する。
【0564】
アプリケーションセッションが接続している状態であることを通知するために、RRC_CONNECTED状態のUEは、継続して周期的に「Uu keep alive indication」をeNBに送信する。eNBは、該通知を受信することによって、アプリケーションセッションが接続している状態であることを認識する。
【0565】
したがって、eNBが該通知を受信している間は、S1リリース処理など、S1ベアラおよびEPSベアラのリリース処理を行わない。S1リリース処理が行われないので、S−GWは、ローカルkeep alive packetを生成し、アプリケーションサーバに対して通知する。これによって、アプリケーションサーバは、UEとの接続を認識することができ、セッションを接続状態に保つことができる。
【0566】
一方、eNBは、所定の期間に、UEへのデータの発生の有無をモニタする。または、UEとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。所定の期間を計測する手段として、タイマを設けてもよい。以下、このタイマを「RRCデータモニタタイマ」と称する。
【0567】
eNBは、ステップST7505において、UEへのデータが発生せず、RRCデータモニタタイマが満了した場合、ステップST7506において、RRC接続のリリース処理を起動する。この処理によって、eNBとUEとの間の無線ベアラはリリースされ、UEとeNBとは、ステップST7404およびステップST7405において、RRC_IDLE状態に移行する。
【0568】
前述の処理では、UEとeNBとの間のRRC接続状態のみを、RRC_CONNECTED状態からRRC_IDLE状態に移行させる。このようにすることによって、UEとeNBとは、RRC接続のための無線リソースをリリースできる。
【0569】
UEは、eNBからのRRC接続リリースメッセージに従って、RRC_IDLE状態に移行することを開示したが、他の方法として、UEにおいてもeNBへのデータの発生の有無をモニタしてもよい。またはeNBとの個別の無線ベアラが必要か否かをモニタするようにしてもよい。ステップST7404において、データの発生が無く、UE側のRRCデータモニタタイマが満了した場合、RRC接続のリリース処理を起動し、RRC_IDLE状態に移行する。また、他の方法として、UEは、RRCの規定に従い、RRC_IDLE状態に移行してもよい。RRCの規定としては、例えば、RLF(Rsdio Link Failure)などがある。
【0570】
RRC_IDLE状態に移行したUEは、アプリケーションセッションの接続を保つために、ステップST7406において、RRC_IDLE状態における「Uu keep alive packet」をeNBに送信し、アプリケーションセッションが接続している状態であること通知する。アプリケーションセッションが接続している状態であること通知するために、RRC_CONNECTED状態のUEは、継続して周期的に「Uu keep alive indication」をeNBに送信する。eNBは、該通知を受信することによって、アプリケーションセッションが接続している状態であることを認識する。
【0571】
したがって、eNBが該通知を受信している間は、S1リリース処理など、S1ベアラおよびEPSベアラのリリース処理を行わない。S1リリース処理が行われないので、S−GWは、ローカルkeep alive packetを生成し、アプリケーションサーバに対して通知する。これによって、アプリケーションサーバは、UEとの接続を認識することができ、セッションを接続状態に保つことができる。
【0572】
ステップST7409において、eNBが「keep alive packet」の未達を確認した場合の処理は、前述の実施の形態4を適用することができるので、ここでは説明を省略する。
【0573】
本実施の形態で開示した方法によって、UEとeNBとの間での状態不一致が軽減されるので、システムリソースに対する影響を軽減することができる。また、eNBが、アプリケーションレベルのセッション状態の判定を、アプリケーションセッションが接続している状態であることを通知するメッセージ、具体的にはRRC_CONNECTED状態の場合は「uu keep alive indication」、RRC_IDLE状態の場合は「uu keep alive packet」のみで判断できるので、実装が容易となる。
【0574】
本実施の形態で開示し方法では、RRC_IDLE状態およびRRC_CONNECTED状態において、「uu keep alive indication」および「uu keep alive packet」を送信する必要があるので、その無線リソースを使用することとなる。したがって、運用状況に応じて、他の実施の形態を含めた方法の中から適切に選択するとよい。
【0575】
実施の形態5.
実施の形態5で解決する課題は、前述の実施の形態3、実施の形態3の変形例1、実施の形態4および実施の形態4の変形例1における課題と同一であり、以下に説明する。
【0576】
前述の実施の形態および変形例においては、定期的に送信されるkeep-aliveパケットに起因する問題の対策として、Uu点のメッセージである「uu keep alive」を利用しているが、RRC接続(RRC Connection)を維持するための無線リソースを使用することとなる。
【0577】
本実施の形態では、前記課題を解決するために、Uu点のメッセージである「uu keep alive」の利用、およびRRC接続(RRC Connection)の維持を行わない方法を開示する。
【0578】
eNBとUEとは、所定の期間にデータの発生の有無をモニタする。eNBとUEとは、所定の期間にデータの発生が無い場合は、アプリケーションレベルのセッションが切断されたと判断し、所定の期間内にデータの発生が有る場合は、セッションが接続されていると判断する、セッション接続判断機能を有する。
【0579】
eNBは、何らかのネットワーク装置、例えばS−GWに、セッション接続状態の情報を通知する。セッション接続状態の情報の通知を受けた前記ネットワーク装置であるS−GWにおいて、ローカルAPP keep alive packetの送信制御を行う。
【0580】
図42および図43は、実施の形態5における通信システムのシーケンスの一例を示す図である。図42図43とは、境界線BL13の位置で、つながっている。図42および図43に示すシーケンスは、図38および図39に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0581】
ステップST5130のデータ送信が行われた後、UEに対するRRC接続(RRC connection)がRRC_CONNECTED状態にあるeNBは、UEへのデータの発生の有無をモニタする。前述の実施の形態4で開示したように、所定の期間にUEへのデータが発生せず、RRCデータモニタタイマが満了した場合、ステップST7404およびステップST7405において、eNBとUEとは、RRC_IDLE状態に移行する。
【0582】
前述の処理では、UEとeNBとの間のRRC接続状態のみを、RRC_CONNECTED状態からRRC_IDLE状態に移行させる。このようにすることによって、UEとeNBとは、RRC接続のための無線リソースをリリースできる。
【0583】
本実施の形態では、前述の実施の形態4とは異なり、RRC_IDLE状態に遷移したUEは、セッション接続通知用のUu点のメッセージである「uu keep alive」をeNBに送信しない。
【0584】
本実施の形態では、UEとeNBとが、所定の期間にデータの発生の有無をモニタする。eNBとUEとは、所定の期間にデータの発生が無い場合は、アプリケーションレベルのセッションが切断されたと判断し、所定の期間内にデータの発生が有る場合は、セッションが接続されていると判断する、セッション接続判断機能を有する。
【0585】
eNBとUEとは、所定の期間にデータの発生の有無をモニタするようにしているが、UEに対するS1ベアラが必要か否かをモニタするようにしてもよい。また、UEに対するECM_CONNECTED状態が必要か否かをモニタするようにしてもよい。所定の期間を計測する手段として、タイマを設けてもよい。以下、このタイマを「NASデータモニタタイマ」と称する。UEは、セッション接続機能をNASの機能として有するとよい。あるいは、ASの機能として有してもよい。ASの機能とする場合、NASデータモニタの満了時、ASからNASへその旨の通知を行うとよい。eNBは、セッション接続機能をASの機能として有するようにするとよい。
【0586】
UEは、データの発生の有無をモニタし、ステップST7601においてNASデータモニタタイマが満了した場合、ステップST5101において、UEは、RRC/ECM_IDLE状態に移行する。ステップST5101でRRC/ECM_IDLE状態になったことを認識したUEは、ステップST7218において、アプリケーションに対してRRC/ECM_IDLE状態になったことを通知する。
【0587】
ローカルリリースを受信したアプリケーションは、RRC/ECMが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
【0588】
eNBは、データの発生の有無をモニタし、ステップST7602においてNASデータモニタタイマが満了した場合、ステップST5134のS1リリース処理Aを起動する。
【0589】
ステップST5134でS1リリース処理Aが行われると、ステップST5102において、eNBは、UEに対してRRC_IDLE状態を維持する。ステップST5103において、MMEは、UEに対してECM_IDLE状態に移行する。S1リリース処理において、eNBおよびMMEは、UEに対するシステムリソースをリリースする。
【0590】
ステップST5134でS1リリース処理Aが行われ、EPSベアラがリリースされたことを認識したS−GWは、ステップST7217において、ローカルAPP keep alive packetの生成を停止する。
【0591】
ステップST7219において、S−GWは、アプリケーションサーバに対してローカルアプリケーションセッションリリースメッセージを通知する。ローカルアプリケーションリリースメッセージを受信したアプリケーションサーバは、EPSベアラが設立されていない状態と判断し、セッションの接続を切断してもよい。
【0592】
前述の方法では、UEとeNBとがセッション接続判断機能を有することを開示した。他の方法として、UEはセッション接続判断機能を有しておらず、eNBがセッション接続判断機能を有するようにしてもよい。この場合、eNBがデータの発生の有無をモニタし、NASデータモニタタイマが満了した場合、S1リリース処理を起動する。
【0593】
S1リリース処理が行われることによって、UEは、RRC/ECM_IDLE状態に移行する。RRC/ECM_IDLE状態になったことを認識したUEは、アプリケーションに対してRRC/ECM_IDLE状態になったことを通知する。ローカルリリースを受信したアプリケーションは、RRC/ECMが接続されていない状態と判断し、「APP keep alive packet」の送信を停止する。セッションの接続を切断してもよい。
【0594】
これによって、UE側でNASデータモニタを行う必要が無くなり、制御を簡易にすることができる。
【0595】
本実施の形態で開示した方法によって、セッション接続通知用のUu点のメッセージである「uu keep alive」の利用、およびRRC接続(RRC Connection)の維持を行わずに、セッション接続判断を行うことが可能となる。これによって、無線リソースの使用量を削減することが可能となる。また、RRCデータモニタタイマおよびNASデータモニタタイマなどのデータモニタタイマのみによって、RRC接続状態の遷移、およびアプリケーションセッション接続状態の遷移を制御することができるので、実装が容易になる。
【0596】
また、本実施の形態で開示した、NASデータモニタタイマは、アプリケーションが持つセッションタイマと一致させるようにしてもよい。UEは、セッションタイマをeNBに通知しておけばよい。これによって、アプリケーションの接続制御時間と通信システム上の接続制御時間とを一致させることができ、システムの誤動作を低減することができる。NASデータモニタタイマと、アプリケーションが持つセッションタイマとを一致させることは、変形例を含む他の実施の形態においても適用可能である。
【0597】
また、本実施の形態で開示した方法は、頻繁に接続を行わないことが想定されNASデータモニタタイマの値を短く設定可能なアプリケーションに使用するなど、アプリケーションの特性を考慮して利用すると、より効果的である。
【0598】
実施の形態6.
実施の形態6で解決する課題を以下に説明する。インスタントメッセージおよびSNS(Social Networking Service)などの常に起動されていて、定期的に比較的小さなサイズデータを送受信するようなアプリケーションについても、前述の実施の形態3と同様の問題が生じる。この場合は、実際に送信先となるサーバなどに情報を伝送する必要があり、前述の実施の形態3〜実施の形態5の解決策をそのまま利用することはできない。
【0599】
例えば非特許文献15および非特許文献16には、ユーザデータに対して専用の無線アクセスベアラを開設することなく、NASシグナリング用ベアラを用いて伝送を行うコンセプトが提案されている。本提案において、通信のエンドツーエンド(End to End)を、UEとあるPDN(Public Data Network)におけるサーバとしたとき、そのPDNに対応するP−GWと対象のUEが在圏するMMEとの間に、データ伝送用のセッションを設定し、データ伝送用の経路とNASシグナリング用ベアラとを用いて通信を行うこととしている。
【0600】
非特許文献15の図1(a)に、コンセプト図が示されている。また、図1(a)の構成における通信をコネクションライト(connection-lite)型通信とし、図1(b)の構成における通信をコネクションオリエンテッド(connection-oriented)型通信としている。
【0601】
非特許文献16の図1において、非特許文献15の図1(a)を適用して実行するときに設定するPDNとの接続手順が開示されている。ここでは、UEからのPDNの接続要求に対し、IP接続アクセスネットワーク(IP−CAN)のセッション確立を行っている。
【0602】
なお、前述の非特許文献15において、connection-liteとconnection-orientedとを併用することが示唆されている。非特許文献15によれば、connection-liteにおいて送信すべきでない大きなデータを伝送したい場合は、通常の伝送パス(connection-oriented)で伝送することを示唆している。
【0603】
しかしながら、その実現方法、例えばconnection-liteとconnection-orientedとの切替方法などは明示されていない。したがって、connection-liteとconnection-orientedとを切替えて用いることは不可能であり、安定した通信ステムの構築ができないという課題が発生する。
【0604】
実施の形態6での解決策を以下に示す。本実施の形態では、connection-liteとconnection-orientedとの切替方法を開示する。UE、P−GW、あるいはS−GWが、connection-liteで送信するか、またはconnection-orientedで送信するかを判断する。判断方法の具体例として、以下の(1)〜(3)の3つを開示する。
【0605】
(1)データによって判断する。具体的には、データの大きさによって判断する。
(2)状態に応じて判断する。
(3)前記(1),(2)の組合せ。
【0606】
なお、connection-liteとconnection-orientedとの切替えは、UEがデータを送信する場合と、APPサーバがデータを送信する場合とで同じであってもよいし、異なっていてもよい。異なる場合の具体例としては、UEがデータを送信する場合は、connection-liteを用い、APPサーバがデータを送信する場合は、connection-orientedを用いるなどである。
【0607】
データによって判断する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)データ量が閾値よりも大きければ、connection-orientedで送信すると判断し、閾値以下であれば、connection-liteで送信すると判断する。
【0608】
(2)トラフィック量が閾値よりも大きければ、connection-orientedで送信すると判断し、閾値以下であれば、onnection-liteで送信すると判断する。小さいトラフィックであるか否かを判断するとしてもよい。トラフィック量の具体例としては、ある単位時間あたりのデータ量である。非特許文献16に開示されているように、データ量で判断する場合は、パケット単位にconnection-liteとconnection-orientedとの切替えが発生する可能性がある。他方、トラフック量で判断する場合は、単位時間の間はconnection-liteとconnection-orientedとの切替えが発生しないので、制御のオーバーヘッドが少なくなるという効果を得ることができる。
【0609】
上記で開示した閾値は、UEとP−GWあるいはS−GWとで、別の値にしてもよい。上りと下りとで、閾値を異なる値にしてもよい。P−GWあるいはS−GW内の構成、およびUE内の構成に対して、小さいデータとして扱うデータ量あるいはトラフィック量を最適にすることができる。上りと下りの負荷状況に応じて、小さいデータとして扱うデータ量あるいはトラフィック量を最適にすることができる。
【0610】
以下、connection-orientedで送信すると判断されるデータを、通常サイズのデータ(Normal size data)と称することもある。また、connection-liteで送信すると判断されるデータを、小さいサイズのデータ、または小さいデータ(small data)と称することもある。
【0611】
前記閾値、例えば、データ量の閾値およびトラフック量の閾値の決定方法の具体例として、以下の(1)〜(9)の9つを開示する。
【0612】
(1)アプリケーションに依存して決定されるとしてもよい。アプリケーションが要求する接続先に依存して決定されるとしてもよい。アプリケーションが要求するQoS、QCI、ベアラ情報などから、UEのNAS、P−GW、あるいはS−GWが閾値を決定してもよい。
【0613】
(2)eNBとMMEとの間の通信システムの状態によって、eNB、MMEが決定するとしてもよい。S1インタフェースの通信システム状態としてもよい。通信システムの状態の具体例としては、静的に決定される最大伝送能力、負荷状況などがある。
【0614】
(3)MMEとS−GWとの間の通信システムの状態によって、MME、S−GWが決定するとしてもよい。S11インタフェースの通信システム状態としてもよい。通信システムの状態の具体例としては、静的に決定される最大伝送能力、負荷状況などがある。
【0615】
(4)オペレータポリシーに依存して決定されるとしてもよい。小さいデータ送信ポリシーに依存して決定されるとしてもよい。小さいデータ送信ポリシーは、オペレータによって設定されてもよい。
【0616】
(5)S−GWとP−GWとの間のインタフェースであるS5/S8インタフェースの通信システムの状態によって決定するとしてもよい。P−GW、あるいはS−GWが決定するとしてもよい。
【0617】
(6)OAMが決定してもよい。
(7)UEの能力に応じて決定する。
(8)前記(1)〜(7)の組合せ。
(9)静的に決定する。
【0618】
閾値の通知方法の具体例として、以下の(1)〜(8)の8つを開示する。
(1)通知しない。閾値の決定方法(1)を用いる場合、UEと、S-GWあるいはP−GWとが、それぞれ同じアプリケーションに依存して閾値を決定すればよい。また、閾値の決定方法(5)を用いる場合も通知不要となる。通知方法(1)は、以下の通知方法(2)〜(4)と比較して、通信エラーを考慮する必要がない点、および制御負荷を減らせる点において有効である。
【0619】
(2)eNBが決定した値をUEと、S−GWあるいはP−GWとに通知する。
(3)MMEが決定した値をUEと、S−GWあるいはP−GWとに通知する。
(4)S−GWが決定した値をUEと、P−GWとに通知する。TFT(Traffic Flow Templates)を用いて通知してもよい。TFTを用いて小さいデータ送信ポリシーと閾値とを通知することによって、以下の効果を得ることができる。小さいデータ送信ポリシーと、connection-liteで送信する小さいデータか、connection-orientedで送信する通常サイズのデータであるかを判断する閾値とを、まとめて通知することができる。connection-liteを用いるか、connection-orientedを用いるかの判断に必要な「小さいデータ送信ポリシー」と「閾値」とを共に受信することができるので、処理が容易となる。
【0620】
(5)P−GWが決定した値をUEへ通知する。TFT(Traffic Flow Templates)を用いて通知してもよい。TFTを用いて小さいデータ送信ポリシーと閾値とを通知することによって、以下の効果を得ることができる。小さいデータ送信ポリシーと、connection-liteで送信する小さいデータか、connection-orientedで送信する通常サイズのデータであるかを判断する閾値とを、まとめて通知することができる。connection-liteを用いるか、connection-orientedを用いるかの判断に必要な「小さいデータ送信ポリシー」と「閾値」とを共に受信することができるので、処理が容易となる。
【0621】
(6)オペレータが決定した値をP−GWあるいはS−GWとUEに通知する。
(7)OAMが決定した値をP−GWあるいはS−GWとUEに通知する。
(8)小さいデータ送信ポリシーを、ネットワーク側エンティティズとUEとの間で交換する際に付随して閾値を交換する。connection-liteを用いるか、connection-orientedを用いるかの判断に必要な「小さいデータ送信ポリシー」と「閾値」とを共に受信することができるので、処理が容易となる。
【0622】
状態に応じて判断する方法の具体例について以下に開示する。対象となるUEとのECM接続状態およびRRC接続状態で、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断する。EPSベアラ(EPS bearer)が設立されていたとしても、ECM_IDLE状態およびRRC_IDLE状態の場合がある。したがって、対象となるUEとのECM接続状態およびRRC接続状態を切替えの判断基準とする方法は、EPSベアラの設立有無を切替えの判断基準とする方法と比較して、ベアラ接続に多くのシグナリングが必要となることを防ぐことができる。
【0623】
以下に、具体例を説明する。ECM_CONNECTEDかつRRC_CONNECTEDの場合は、connection-orientedで通信を行うようにするとよい。発生するデータの量あるいはトラフィックの量にかかわらず、connection-orientedで通信を行うとよい。小さいデータ(small data)が発生したとしても、connection-orientedで通信が行われる。
【0624】
ECM_IDLEまたはRRC_IDLEの場合は、小さいデータが発生した場合はconnection-liteで通信を行い、通常のデータが発生した場合はconnection-orientedで通信を行うようにするとよい。EPSベアラが設立されていたとしても、ECM_IDLEの場合、S1−UまたはRRCが接続状態にあるとは限らない。したがって、小さいデータが発生した場合にconnection-liteで通信を行うことで、U−planeの接続に必要となるシグナリングを削減することが可能となる。また、RRC_IDLEの場合のconnection-liteでの通信は、RRC_CONNEXTED状態に移行しないで行うようにしてもよい。これによって、RRC接続セットアップ処理(RRC Connection Setup Procedure)を起動しなくてすむ。具体的な方法としては、例えば、RACH処理を用いて小さいデータを送信する、あるいは、ページング処理で小さいデータを送信するなどがある。RACH処理を用いて小さいデータを送信する方法は、前述の実施の形態1の変形例4と同様であるので、説明を省略する。ページング処理を用いて小さいデータを送信する方法は、前述の実施の形態1の変形例5と同様であるので、説明を省略する。
【0625】
以上に開示した判断基準を、小さいデータ送信ポリシーに加えておき、UEおよびS−GWあるいはP−GWで有するようにしてもよい。小さいデータ送信ポリシーとは別に、データ(data)送信ポリシーとして、UEおよびS−GWあるいはP−GWで有するようにしてもよい。
【0626】
なお、前記では、対象となるUEとのECM接続状態およびRRC接続状態で、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断することを開示したが、これに限らず、対象となるUEとのS1−Uベアラの設立状態および無線ベアラの設立状態で、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断してもよい。ECM接続状態をS1−Uベアラの設立状態に置き換え、RRC接続状態を無線ベアラの設立状態に置き換えればよい。
【0627】
UEがデータを送信する場合(MOとも称される)については、UEがconnection-liteで通信を行うか、connection-orientedで通信を行うか判断する。したがってUEは、RRC状態あるいはECM状態を認識しておく必要がある。
【0628】
UEは、RRC状態を認識している。従来、RRC状態とECM状態とは一致するので、UEはECM状態も認識することができる。しかし、実施の形態4、実施の形態5、あるいは後述の実施の形態7で開示するように、RRC状態とECM状態とが異なる場合がある。このような場合、UEはECM状態を認識できない。
【0629】
この問題は、以下の方法によって解決することができる。RRC状態とECM状態とが異なる場合は、MMEあるいはeNBから、UEに対してECM状態を示す情報を通知するようにしてもよい。
【0630】
APPサーバがデータを送信する場合(MTとも称される)については、P−GWあるいはS−GWがconnection-liteで通信を行うか、connection-orientedで通信を行うかを判断する。したがって、P−GWあるいはS−GWは、RRC状態あるいはECM状態を認識しておく必要がある。
【0631】
S−GWは、ECM状態を認識している。従来、RRC状態とECM状態とは一致するので、S−GWは、RRC状態も認識することができる。しかし、実施の形態4、実施の形態5、あるいは後述の実施の形態7で開示するように、RRC状態とECM状態とが異なる場合がある。このような場合、S−GWは、RRC状態を認識できない。
【0632】
この問題は、以下の方法によって解決することができる。RRC状態とECM状態とが異なる場合は、eNBからS−GWに対して、RRC状態を示す情報を通知するようにしてもよい。また、UEからS−GWに対して、RRC状態を示す情報を通知するようにしてもよい。
【0633】
また、P−GWは、RRC状態およびECM状態を認識しているとは限らない。MMEからP−GWに対して、ECM状態を示す情報を通知するようにしてもよい。また、S−GWからP−GWに対して、ECM状態を示す情報を通知するようにしてもよい。eNBからP−GWに対して、RRC状態を示す情報を通知するようにしてもよい。また、UEからP−GWに対して、RRC状態を示す情報を通知するようにしてもよい。
【0634】
このようにすることによって、MOにおいてはUEが、MTにおいては、P−GWあるいはS−GWが、connection-liteで通信を行うか、connection-orientedで通信を行うかを判断することができる。
【0635】
connection-liteからconnection-orientedへの切替方法について、以下に開示する。Coonection-liteの状態で、UEがconnection-orientedで送信すると判断した場合、UEは、サービス要求処理(Service Request Procedure)を起動する。通常の発呼処理と同様となるので、通信システムが複雑化することを回避することができるという効果を得ることができる。
【0636】
Coonection-liteの状態で、P−GWおよびS−GWなどのネットワーク側がconnection-orientedで送信すると判断した場合、P−GWは、個別ベアラアクティブ化処理(Dedicated Bearer Activation Procedure)を起動する(非特許文献13 5.4.1章参照)。通常の着呼処理と同様となるので、通信システムが複雑化することを回避することができるという効果を得ることができる。
【0637】
connection-liteからconnection-orientedへの切替えが発生した場合、S1−MMEおよびS11上で小さいデータを送信する機能および設定をディアクティブにしなくてもよい。例えば、NASメッセージに、小さいデータを含める機能および設定、GTP−Cに小さいデータを含める機能および設定などをディアクティブにしなくてもよい。別途、シグナリング、または再度connection-liteへの切替えが発生した場合に、再設定が不要となり、通信システムとしての処理の負荷を軽減することができるという効果を得ることができる。
【0638】
次に、図44図47を用いて、実施の形態6における通信システムのシーケンスの具体例について説明する。図44図47は、実施の形態6における通信システムのシーケンスの一例を示す図である。図44図45とは、境界線BL14の位置で、つながっている。図45図46とは、境界線BL15の位置で、つながっている。図46図47とは、境界線BL16の位置で、つながっている。図44図47では、connection-lite状態において、UE側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスを示している。
【0639】
まず、図44および図45のステップST9101〜ステップST9122に、非特許文献16に開示された、connection-liteを実行する際に設定するPDN接続手順を示す。
【0640】
ステップST9101において、UEのアプリケーション、あるいはTPC/IPが、NASへアクセス要求(Access Request)を行う。
【0641】
ステップST9102において、UEのNASは、PDN設立処理(PDN Establishment Procedure)を起動する。ステップST9102のPDN設立処理は、ステップST9103〜ステップST9121の処理を含む。
【0642】
ステップST9103において、UEのNASは、AS(Access Stratum)にPDN接続要求(PDN Connectivity Request)メッセージを送信する。UEのNASが、RRCレイヤに通知してもよい。
【0643】
ステップST9104において、UEのRRCレイヤは、RRC接続セットアップ処理(RRC Connection Setup Procedure)を起動する。ステップST9104のRRC接続セットアップ処理は、ステップST9105〜ステップST9107の処理を含む。
【0644】
ステップST9105において、UEのRRCレイヤは、eNBにRRC接続セットアップ要求(RRC Connection Setup Request)メッセージを送信する。
【0645】
ステップST9105でRRC接続セットアップ要求メッセージを受信したeNBは、ステップST9106において、UEのRRCレイヤにRRC接続セットアップ(RRC Connection Setup)メッセージを送信する。
【0646】
ステップST9106でRRC接続セットアップメッセージを受信したUEは、ステップST9107において、eNBにRRC接続セットアップ完了(RRC Connection Setup Complete)メッセージを送信する。
【0647】
ステップST9108において、UEのRRCレイヤは、eNBにPDN接続要求(PDN Connectivity Request)メッセージを送信する。
【0648】
ステップST9108でPDN接続要求メッセージを受信したeNBは、ステップST9109において、MMEにPDN接続要求メッセージを送信する。
【0649】
ステップST9110において、MMEは、S−GWにセッション生成要求(Create Session Request)メッセージを送信する。
【0650】
ステップST9110でセッション生成要求メッセージを受信したS−GWは、ステップST9111において、P−GWにセッション生成要求メッセージを送信する。
【0651】
ステップST9112において、P−GWは、IP接続アクセスネットワーク(IP−CAN)のセッション確立(IP-CAN Session Establishment)を実行する。
【0652】
ステップST9112でIP−CANのセッション確立が完了した場合、ステップST9113において、P−GWは、セッション生成応答(Create Session Response)メッセージをS−GWに送信する。
【0653】
ステップST9113でセッション生成応答メッセージを受信したS−GWは、ステップST9114において、MMEにセッション生成応答メッセージを送信する。
【0654】
ステップST9115において、MMEは、デフォルトベアラコンテキスト要求アクティブ化(Activate Default Bearer Context Request)メッセージをeNBに送信する。
【0655】
ステップST9115でデフォルトベアラコンテキスト要求アクティブ化メッセージを受信したeNBは、ステップST9116において、UEにデフォルトベアラコンテキスト要求アクティブ化メッセージを送信する。
【0656】
ステップST9116でデフォルトベアラコンテキスト要求アクティブ化メッセージを受信したUEは、ステップST9117において、eNBにデフォルトベアラコンテキスト応答アクティブ化(Activate Default Bearer Context Response)メッセージを送信する。
【0657】
ステップST9117でデフォルトベアラコンテキスト応答アクティブ化メッセージを受信したeNBは、ステップST9118において、MMEにデフォルトベアラコンテキスト応答アクティブ化メッセージを送信する。
【0658】
そして、前述のPDN接続手順を用いて、小さいデータ(small data)送信ポリシーをネットワーク側エンティティズとUEとの間で交換する。これによって、小さいデータ送信時に、UEとアプリケーションサーバとの間で、eNB、MME、S−GW、P−GWを介した小さいデータの送信が可能となる。
【0659】
ステップST9119において、MMEとS−GWとの間に、S11ベアラ(S11 Bearer)を設立する。MMEとS−GWとの間のS11上で、小さいデータの送信が可能となる(S11(sml))。
【0660】
ステップST9120において、S−GWとP−GWとの間に、S5/S8ベアラ(S5/S8 Bearer)を設立する。S−GWとP−GWとの間のS5/S8上で、小さいデータの送信が可能となる(S5/S8(sml))。
【0661】
ステップST9121において、eNBとMMEとの間に、S1ベアラ(S1 Bearer)を設立する。eNBとMMEとの間のS1上で、小さいデータの送信が可能となる(S1(sml))。
【0662】
これによって、ステップST9122において、UEから、eNBとMMEとS−GWとP−GWとを経由して、アプリケーションサーバ(APP Server)にデータを送信することが可能となる。
【0663】
以下、このような状態を「connection-lite状態」と称することもある。小さいデータが送信可能となようにとしてもよい。
【0664】
図46のステップST9123において、UEのアプリケーションから、NASに通常サイズのデータの送信が要求され、送信データが送信される。
【0665】
ステップST9123で通常サイズのデータを受信したUEのNASは、ステップST9124において、connection-liteで送信するか、connection-orientedで送信するかを判断する。図示は省略しているが、前述の状態に応じての判断を実行するようにしてもよい。具体的には、送信データが小さいデータであるか否かを判断する。ステップST9124において、小さいデータであると判断された場合は、connection-liteで送信すると判断し、ステップST9125に移行する。ステップST9124において、小さいデータでないと判断された場合は、connection-orientedで送信すると判断し、ステップST9126に移行する。
【0666】
ステップST9125において、UEのNASは、送信データをconnection-lite状態で送信する。小さいデータ用に開設されているベアラ、connection-liteで設立が完了しているベアラ(以下「Connection lite bearer」と称することもある)を用いて送信するようにしてもよい。
【0667】
ステップST9126において、UEのNASは、connection-orientedでの送信準備を開始する。具体例としては、サービス要求処理C(Service Request Procedure C)を起動する。
【0668】
ステップST9126のサービス要求処理Cは、ステップST9127〜ステップST9147の処理を含む。
【0669】
ステップST9127において、UEのNASは、ASにサービス要求(Service Request)メッセージを送信する。UEのNASがRRCレイヤに通知してもよい。
【0670】
ステップST9127でサービス要求メッセージを受信したUEは、ステップST9128において、RRC接続セットアップ処理(RRC Connection Setup Procedure)を起動する。RRC接続セットアップ処理の詳細は、図44のステップST9104の処理と同様であるので、説明を省略する。
【0671】
ステップST9132において、UEのRRCレイヤは、eNBにサービス要求(Service Request)メッセージを送信する。
【0672】
ステップST9132でサービス要求メッセージを受信したeNBは、ステップST9133において、MMEにサービス要求(Service Request)メッセージを送信する。
【0673】
ステップST9133でサービス要求メッセージを受信したMMEは、図47のステップST9134において、eNBに初期コンテキストセットアップ要求(Initial Context Setup Request)メッセージを送信する。
【0674】
ステップST9134で初期コンテキストセットアップ要求メッセージを受信したeNBは、ステップST9135において、無線ベアラ設立処理(Radio Bearer Establishment Procedure)を起動する。
【0675】
ステップST9135の無線ベアラ設立処理は、ステップST9136〜ステップST9137の処理を含む。
【0676】
ステップST9136において、eNBは、UEにRRC接続再設定(RRC Connection Reconfiguration)メッセージを送信する。
【0677】
ステップST9136でRRC接続再設定メッセージを受信したUEは、ステップST9137において、eNBにRRC接続再設定完了(RRC Connection Reconfiguration Complete)メッセージを送信する。
【0678】
ステップST9137でRRC接続再設定完了メッセージを受信したeNBは、ステップST9138において、MMEに初期コンテキストセットアップ完了(Initial Context Setup Complete)メッセージを送信する。
【0679】
ステップST9139において、MMEは、ベアラ修正要求(Modify Bearer Request)メッセージをS−GWに送信する。
【0680】
ステップST9139でベアラ修正要求メッセージを受信したS−GWは、ステップST9141において、P−GWにベアラ修正要求(Modify Bearer Request)メッセージを送信する。
【0681】
ステップST9142において、P−GWは、IP接続アクセスネットワーク(IP−CAN)のセッション変更(IP-CAN Session Modification)を実行する。IP−CANのセッション変更を、「PCEF initiated IP-CAN Session Modification」と称することもある。
【0682】
ステップST9142でIP−CANのセッション変更が完了した場合、ステップST9143において、P−GWは、ベアラ修正応答(Modify Bearer Response)メッセージをS−GWに送信する。
【0683】
ステップST9143でベアラ修正応答メッセージを受信したS−GWは、ステップST9144において、MMEにベアラ修正応答(Modify Bearer Response)メッセージを送信する。
【0684】
ステップST9145において、eNBとS−GWとの間に、S1ベアラ(S1 Bearer)を設立する。
【0685】
ステップST9146において、S−GWとP−GWとの間に、S5/S8ベアラ(S5/S8 Bearer)を設立する。
【0686】
ステップST9147において、UEとP−GWとの間に、EPSベアラ(EPS Bearer)を設立する。
【0687】
これによって、ステップST9148において、UEから、eNBとS−GWとP−GWとを経由して、アプリケーションサーバ(APP Server)へのデータの送信が可能となる。以下、このような状態をconnection-oriented状態と称することもある。通常サイズデータが送信可能となるようにしてもよい。
【0688】
次に、図48および図49を用いて、実施の形態6における通信システムのシーケンスの具体例について説明する。図48および図49は、実施の形態6における通信システムのシーケンスの他の例を示す図である。図48図49とは、境界線BL17の位置で、つながっている。図48および図49に示すシーケンスは、図44図47に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図48および図49では、connection-lite状態において、ネットワーク(NW)側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスを示している。
【0689】
ステップST9201において、アプリケーションサーバから、P−GWに通常サイズのデータの送信が要求され、送信データが送信される。
【0690】
ステップST9201で通常サイズのデータを受信したP−GWは、ステップST9202において、connection-liteで送信するか、connection-orientedで送信するかを判断する。具体的には、送信データが小さいデータであるか否かを判断する。図示は省略しているが、前述の状態に応じての判断を実行するようにしてもよい。ステップST9202において、小さいデータであると判断された場合は、connection-liteで送信すると判断し、ステップST9203に移行する。ステップST9202において、小さいデータでないと判断された場合は、connection-orientedで送信すると判断し、ステップST9204に移行する。
【0691】
ステップST9203において、P−GWは、送信データをconnection-lite状態で送信する。コネクションライトベアラ(connection lite bearer)を用いて送信するようにしてもよい。
【0692】
ステップST9204において、P−GWは、connection-orientedでの送信準備を開始する。具体例としては、個別ベアラアクティブ化処理(Dedicated Bearer Activation Procedure)を起動する。
【0693】
ステップST9204の個別ベアラアクティブ化処理は、ステップST9205〜ステップST9146の処理を含む。
【0694】
ステップST9205において、P−GWは、S−GWにベアラ生成要求(Create Bearer Request)メッセージを送信する。
【0695】
ステップST9205でベアラ生成要求メッセージを受信したS−GWは、ステップST9206において、MMEにベアラ生成要求メッセージを送信する。
【0696】
ステップST9206でベアラ生成要求メッセージを受信したMMEは、ステップST9135において、無線ベアラ設立処理(Radio Bearer Establishment Procedure)を起動する。
【0697】
ステップST9208において、eNBは、ベアラセットアップ応答(Bearer Setup Response)メッセージをMMEに送信する。
【0698】
ステップST9209において、UEは、「Direct Transfer」をeNBに送信する。あるいはセッション管理応答(Session Management Response)メッセージを送信するようにしてもよい。
【0699】
ステップST9209でセッション管理応答メッセージを受信したeNBは、ステップST9210において、MMEにセッション管理応答メッセージを送信する。
【0700】
ステップST9210でセッション管理応答メッセージを受信したMMEは、ステップST9211において、S−GWにベアラ生成応答(Create Bearer Response)メッセージを送信する。
【0701】
ステップST9211でベアラ生成応答メッセージを受信したS−GWは、ステップST9212において、P−GWにベアラ生成応答メッセージを送信する。
【0702】
以上の実施の形態6によって、以下の効果を得ることができる。connection-liteとconnection-orientedとの併用を実現することが可能となる。実現方法が決定することによって、安定した通信ステムの構築が可能となる。
【0703】
実施の形態6 変形例1.
実施の形態6の変形例1で解決する課題を以下に説明する。前述の実施の形態6を実行した場合、以下の課題が発生する。
【0704】
例えば、図44図47に示すシーケンスを実行した場合、同じアプリケーションサーバへの接続であるにも関わらず、IP接続アクセスネットワーク(IP−CAN)のセッションの確立を、例えば図45のステップST9112と図47のステップST9142とで、二重に設定することとなる。このことは、場合によっては、同一のアプリケーションのセッションに対し、不要な手続きを実行することとなる。また、場合によっては、PDN側が不正要求として接続を許可しない可能性もあるので、問題となる。
【0705】
加えて、connection-lite状態において、UEとNWとの双方から、通常サイズのデータを送信する場合、以下の問題が発生する。
【0706】
UEからのサービス要求(Service Request)に基づいて、無線ベアラ設立処理(Radio Bearer Establishment Procedure)が起動され、P−GWからのベアラ生成要求(Create Bearer Request)に基づいて、同じベアラであるにもかからず、再度、無線ベアラ(Radio Bearer)の設定がなされてしまう。
【0707】
図50および図51を用いて、実施の形態6の変形例1の課題の具体例について説明する。図50および図51は、実施の形態6の変形例1で解決する課題を説明するためのシーケンスを示す図である。図50図51とは、境界線BL18の位置で、つながっている。図50および図51に示すシーケンスは、図44図47図48および図49に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0708】
図50および図51では、同じ無線ベアラ(Radio Bearer)の設立のために、ステップST9135において、無線ベアラ設立処理(Radio Bearer Establishment Procedure)が重複して起動される。
【0709】
実施の形態6の変形例1での解決策を以下に示す。既にコネクションライトベアラ(connection lite bearer)が存在する場合、あるいはconnection-orientedで設立が完了しているベアラ(以下「Connection oriented bearer」と称することもある)が存在する場合、P−GWは、IP−CANセッション(IP-CAN session)に関する手続きを実行しないものとする。または、はじめに設定したPDN接続要求(PDN Connectivity Request)によって、IP接続アクセスネットワーク(IP−CAN)のセッションは維持し、P−GWは、IP−CANセッションに関する手続きを実行しないものとする。これによって、同一のアプリケーションのセッションに対し、不要な手続きを防ぐことができる。
【0710】
次に、MMEが、UEとP−GWとの間において、connection-orientedで使用するベアラが開設手順中、変更手順中、または開設済みであるか否かの判断を行う。以下、この判断を「ベアラ開設有無判断」と称することもある。開設手順中、変更手順中または開設済みでなければ、connection-orientedで使用するベアラの開設手続きを起動する。あるいは、MMEは、RRC/ECM状態がCONNECTEDかIDLEかの判断を行い、IDLEであれば、connection-orientedで使用するベアラの開設手続きを起動する。開設手順中、変更手順中または開設済みであれば、connection-orientedで使用するベアラの開設手続きを起動しない。あるいは、MMEは、RRC/ECM状態がCONNECTEDかIDLEかの判断を行い、CONNECTEDであれば、connection-orientedで使用するベアラの開設手続きを起動しない。これによって、重複したベアラの設定を回避することが可能となる。
【0711】
UEがデータを送信する場合について開示する。MMEは、サービス要求(Service Request)の受信によって、ベアラ開設有無判断を起動してもよい。
【0712】
開設手順中または開設済みでなければ、connection-orientedで使用するベアラの開設手続きを起動する。具体例としては、通常のサービス要求処理(Service Request Procedure)に沿った処理を実行する。例えば、MMEは、eNBに初期コンテキストセットアップ要求(Initial Context Setup Request)メッセージを送信する。
【0713】
開設手順中または開設済みであれば、その旨をUEに通知する。あるいは通知せずに、処理を終了してもよい。
【0714】
APPサーバがデータを送信する場合について開示する。P−GW、あるいはS−GWは、アプリケーションサーバから、データの送信が要求され、送信データが送信された場合、既存ベアラの有無判断を起動する。
【0715】
既存ベアラ有りと判断した場合、その旨をMMEに通知する。既存ベアラ有りの場合のみ、MMEに通知するようにしてもよい。
【0716】
通知方法としては、P−GWからMMEに通知する新たなメッセージを新設する。例えば、ベアラ変更要求(Bearer Change Request)メッセージなどである。あるいは、既存のベアラ生成要求(Create Bearer Request)メッセージに、既存ベアラ有りの旨を示す情報要素を追加してもよい。
【0717】
ベアラ変更要求メッセージを受信したMMEは、ベアラ開設有無判断を起動してもよい。
【0718】
開設手順中または開設済みでなければ、connection-orientedで使用するベアラの開設手続きを起動する。具体例としては、MMEは、P−GWに通常の個別ベアラアクティブ化処理(Dedicated Bearer Activation Procedure)の起動を要求する。要求方法の具体例としては、ベアラ生成応答(Create Bearer Response)、あるいはベアラ変更応答(Bearer Change Response)を新たに設ける、あるいはベアラ設定要求(Bearer Set Request)を新たに設けるなどがある。
【0719】
ベアラ変更要求(Bearer Change Request)に対して、拒絶(Reject)信号を送信し、その理由として、開設手順中または開設済みで有る旨を通知してもよい。あるいは、MME自身が、eNBにベアラセットアップ要求/セッション管理要求(Bearer Setup Request/Session Management Request)を送信し、個別ベアラアクティブ化処理(Dedicated Bearer Activation Procedure)を起動してもよい。
【0720】
開設手順中または開設済みであれば、その旨をP−GWに通知する。通知方法の具体例としては、ベアラ修正要求(Modify Bearer Request)、あるいはベアラ変更応答(Bearer Change Response)などがある。
【0721】
開設手順中または開設済みである旨を受信したP−GWは、新たに開設されるベアラを用いて、下りデータをUEに送信する。
【0722】
以上に開示した方法では、MMEがUEとP−GWとの間において、connection-orientedで使用するベアラが開設手順中もしくは開設済みであるか否かの判断を行うようにした。
【0723】
他の方法として、UE、あるいは、P−GWあるいはS−GWが、UEとP−GWとの間において、connection-orientedで使用するベアラが開設済みであるか否かの判断を行い、P−GWあるいはMMEに通知するようにしてもよい。
【0724】
UEがデータを送信する場合について開示する。UEが、コネクションライトベアラ(connection lite bearer)、あるいはコネクションオリエンテッドベアラ(connection oriented bearer)が存在するか否かを判断する。以下、この判断を「既存ベアラの有無判断」と称することがある。UEは、既存ベアラの有無判断の結果を、ネットワーク側に通知する。具体的には、UEは、P−GWあるいはS−GWに通知する。
【0725】
既存ベアラの有無判断の結果の通知内容の具体例として、以下の(1)〜(3)の3つを開示する。
(1)既存ベアラの有無。あるいは既存ベアラ有りの旨のみ。あるいは既存ベアラ無しの旨のみ。
(2)EPSベアラ変更の要否。あるいはEPSベアラ変更が必要の旨のみ。あるいはEPSベアラ変更が不要の旨のみ。既存ベアラが有る場合は、EPSベアラの変更は不要となり、既存ベアラが無い場合は、EPSベアラの変更は必要となる。
(3)IP−CANセッションに関する手続の要否。あるいはIP−CANセッションに関する手続が必要の旨のみ。あるいはIP−CANセッションに関する手続が不要の旨のみ。既存ベアラが有る場合は、IP−CANセッションに関する手続は不要となり、既存ベアラが無い場合は、IP−CANセッションに関する手続は必要となる。
【0726】
既存ベアラの有無判断の結果の通知方法の具体例を、以下に開示する。
UEは、MME経由でP−GW、あるいはS−GWに通知する。たとえば、UEは、NASシグナルを用いて、MMEに、既存ベアラの有無判断の結果を通知する。この場合の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにNASシグナルを新設する。
(2)既存のNASシグナルを用いる。既存のシグナルに、既存ベアラの有無判断の情報要素を追加すればよい。既存のシグナルの具体例としては、サービス要求(Service Request)メッセージなどがある。
【0727】
既存ベアラの有無判断の結果を受信したMMEは、S−GW、P−GWに、UEから受信した既存ベアラの有無判断の結果を通知する。この場合の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにシグナルを新設する。
(2)既存のシグナルを用いる。既存のシグナルに、既存ベアラの有無判断の情報要素を追加すればよい。既存のシグナルの具体例としては、ベアラ修正要求(Modify Bearer Request)メッセージ、ベアラ削除要求(Delete Bearer Request)メッセージなどがある。
【0728】
既存ベアラの有無判断の結果を受信したS−GW、あるいはP-GWは、受信した既存ベアラの有無判断の結果に基づいて、IP−CANセッションに関する手続きを実行するか否かを判断する。具体的には、以下の(1),(2)のように判断する。
【0729】
(1)既存ベアラの有、あるいはEPSベアラ変更不要、IP−CANセッションに関する手続不要が通知された場合、IP−CANセッションに関する手続が不要と判断する。ベアラ修正要求(Modify Bearer Request)などにおいて参照するダイナミックPCC(Dynamic PCC)によらず、P−GWは、IP−CANセッションに関する手続き不要と判断してもよい。
【0730】
(2)既存ベアラの無、あるいはEPSベアラ変更必要、IP−CANセッションに関する手続必要が通知された場合、IP−CANセッションに関する手続が必要と判断する。
【0731】
APPサーバがデータを送信する場合について開示する。この場合、P−GW、あるいはS−GWが既存ベアラの有無判断を行う。その結果に基づいて、S−GW、あるいはP-GWは、IP−CANセッションに関する手続きを実行するか否かを判断する。具体的には、以下の(1),(2)のように判断する。
【0732】
(1)既存ベアラの有りの場合、IP−CANセッションに関する手続が不要と判断する。
(2)既存ベアラの無しの場合、IP−CANセッションに関する手続が必要と判断する。具体例としては、通常の個別ベアラアクティブ化処理(Dedicated Bearer Activation Procedure)を起動する。
【0733】
次に、図52および図53を用いて、実施の形態6の変形例1における通信システムのシーケンスの具体例について説明する。図52および図53は、実施の形態6の変形例1における通信システムのシーケンスの一例を示す図である。図52図53とは、境界線BL19の位置で、つながっている。図52および図53に示すシーケンスは、図44図47に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図52および図53では、connection-lite状態において、UE側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスについて示している。
【0734】
ステップST9401において、UEは、既存ベアラの有無判断を実行する。UEのNASが判断してもよい。既存ベアラ無しと判断した場合、UEは、通常のサービス要求処理(Service Request Procedure)を起動する。図52および図53では、通常のサービス要求処理の説明を省略し、「終了」と記載する。既存ベアラ有りと判断した場合、UEは、ステップST9402に移行する。
【0735】
ステップST9402において、UEのNASは、ASに既存ベアラの有無判断の情報要素が追加されたサービス要求(Service Request)を送信する。UEのNASがRRCレイヤに通知してもよい。
【0736】
図53のステップST9403において、UEのRRCレイヤは、eNBに既存ベアラの有無判断の情報要素が追加されたサービス要求(Service Request)メッセージを送信する。
【0737】
ステップST9403で既存ベアラの有無判断の情報要素が追加されたサービス要求メッセージを受信したeNBは、ステップST9404において、MMEに既存ベアラの有無判断の情報要素が追加されたサービス要求(Service Request)メッセージを送信する。
【0738】
ステップST9404でサービス要求メッセージを受信したMMEは、コネクションオリエンテッドベアラ(connection oriented bearer)が開設手順中または開設済みであるかを判断する。すなわち、ベアラ開設有無判断を実行する。MMEは、既存ベアラの有無判断の結果に基づいて既存ベアラ有りの旨の通知を受けたときに、ベアラ開設有無判断を実行するようにしてもよい。
【0739】
開設手順中または開設済みの場合、処理を終了する。必要に応じて、MMEは、eNB経由でUEに応答メッセージを送信してもよい。応答メッセージを受けたUEは、開設中ベアラのRRC接続(RRC connection)の設定を待ち、通常データの送信を行う。応答メッセージが存在しない場合においても、開設中、または開設されたベアラのRRC接続(RRC connection)の設定によって送信が可能となる。
【0740】
開設手順中または開設済みでない場合は、ステップST9410に移行し、MMEは、eNBに初期コンテキストセットアップ要求(Initial Context Setup Request)メッセージを送信する。初期コンテキストセットアップ要求メッセージに、既存ベアラの有無判断の情報要素が追加されていてもよい。
【0741】
ステップST9411において、eNBは、MMEに初期コンテキストセットアップ完了(Initial Context Setup Complete)メッセージを送信する。初期コンテキストセットアップ完了メッセージに、既存ベアラの有無判断の情報要素が追加されていてもよい。
【0742】
ステップST9406において、MMEは、既存ベアラの有無判断の情報要素を追加したベアラ修正要求(Modify Bearer Request)をS−GWに送信する。
【0743】
ステップST9406で既存ベアラの有無判断の情報要素を追加したベアラ修正要求メッセージを受信したS−GWは、ステップST9407において、P−GWに、既存ベアラの有無判断の情報要素を追加したベアラ修正要求(Modify Bearer Request)メッセージを送信する。
【0744】
ステップST9407で既存ベアラの有無判断の情報要素を追加したベアラ修正要求メッセージを受信したP−GWは、IP−CANセッションに関する手続きを実行しない。
【0745】
ステップST9408において、P−GWは、ベアラ修正応答(Modify bearer Response)をS−GWに送信する。EPSベアラを変更していない旨、あるいはIP−CANセッションに関する手続きをしていない旨を併せて通知してもよい。
【0746】
ステップST9408でベアラ修正応答メッセージを受信したS−GWは、ステップST9409において、MMEにベアラ修正応答(Modify bearer Response)メッセージを送信する。
【0747】
次に、図54図56を用いて、実施の形態6の変形例1における通信システムのシーケンスの具体例について説明する。図54図56は、実施の形態6の変形例1における通信システムのシーケンスの他の例を示す図である。図54図55とは、境界線BL20の位置で、つながっている。図55図56とは、境界線BL21の位置で、つながっている。図54図56に示すシーケンスは、図44図49に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図54図56では、connection-lite状態において、ネットワーク(NW)側が大きなデータを伝送する場合に、connection-oriented状態へ遷移する場合のシーケンスについて示している。
【0748】
図55のステップST9501において、P−GWは、既存ベアラの有無判断を実行する。P−GWは、既存ベアラ無しと判断した場合、ステップST9204に移行し、通常の個別ベアラアクティブ化処理(Dedicated Bearer Activation Procedure)を起動する。P−GWは、既存ベアラ有りと判断した場合、ステップST9502に移行する。
【0749】
ステップST9502において、P−GWは、既存ベアラが有る旨をMMEに通知する。具体的には、ベアラ変更要求(Bearer Change Request)メッセージをMMEに通知する。
【0750】
ステップST9502で既存ベアラが有る旨を受信したMMEは、ステップST9405において、コネクションオリエンテッドベアラ(connection oriented bearer)が開設手順中または開設済みであるかを判断する。すなわち、ベアラ開設有無判断を実行する。
【0751】
開設手順中または開設済みの場合、ステップST9501に移行し、MMEは、P−GWにその旨を通知する。
【0752】
開設手順中または開設済みでない場合は、ステップST9504に移行し、MMEは、P−GWに、通常の個別ベアラアクティブ化処理(Dedicated Bearer Activation Procedure)の起動を要求する。
【0753】
図56のステップST9505において、P−GWは、UEに対して、ステップST9148で開設されたベアラを用いて、データの送信を行う。つまり、通常サイズのデータ(Normal size data)の送信を行い、その後、処理を終了する。
【0754】
ステップST9506において、P−GWは、新しいベアラが開設されたか否かを判断する。開設されていないと判断された場合は、ステップST9506の判断を繰り返す。開設されたと判断された場合は、ステップST9507に移行する。
【0755】
ステップST9507において、P−GWは、UEに対して、新しく開設されたベアラを用いて、データの送信を行う。つまり、通常サイズのデータ(Normal size data)の送信を行い、その後、処理を終了する。
【0756】
以上の実施の形態6の変形例1によって、前述の実施の形態1の効果に加えて、以下の効果を得ることができる。
【0757】
IP接続アクセスネットワークへの不要な手続きを回避することが可能となる。重複してEPSベアラを開設する処理が実行されることから、PDN側に不正要求として接続を拒否される危険性を回避することができる。
【0758】
また、不要な無線ベアラ設定を回避することができ、制御処理の重複、また制御処理が重複することによって通信システムが不安定になることを回避することができる。
【0759】
これによって、安全な手順で通信ベアラを切り替えることが可能となり、また、外部ネットワークの動作による通信の影響を軽減することが可能となる。
【0760】
実施の形態6 変形例2.
実施の形態6の変形例2で解決する課題を以下に説明する。実施の形態6のconnection-liteの場合における伝送においては、1回の伝送データ量が小さい場合に利用されることが想定される。しかしながら、IPパケットによる伝送を行うことを想定すると、例えば、RFC2460などに示されるIPv6(Internet Protocol Version 6)のIPヘッダは、40バイト(byte)であり、PDCPにおけるヘッダ圧縮を考慮しても、送信データ量に対するヘッダオーバヘッドは小さくない。
【0761】
前述の状態においては、UEのIPアドレスの割当は1つであることが想定され、UEのIDと等価と見なせることからも、少なくともUEのIPアドレスの情報伝送は、無線リソースを無駄に利用することとなる。また、UEの通信相手となる装置のIPアドレスが限定されることから、通信相手となる装置のIPアドレスの情報伝送も無駄な無線リソースを利用する可能性がある。
【0762】
前述の問題を解決するために、以下の対策を行う。connection-liteの場合におけるUu点の伝送において、IPヘッダのネットワークアドレス情報などを伝送せず、IPヘッダのうち、上位プロトコルを示す要素および送信元アドレスなどを縮退化し、別のヘッダとして再構築する。
【0763】
IPヘッダの縮退化、別のヘッダの再構築を実行するエンティティの具体例としては、MMEなどがある。
【0764】
縮退化し、別のヘッダとして再構築する縮退化対象パラメータの具体例として、以下の(1)〜(7)の7つを開示する。
(1)ソースアドレス(Source Address)。UEのIPアドレスの割当は1つであることが想定されていることから、縮退化しての再構築が可能となる。UEの通信相手となる装置も限定されることが想定されていることから、縮退化しての再構築が可能となる。
【0765】
(2)ディスティネーションアドレス(Destination Address)。UEのIPアドレスの割当は1つであることが想定されていることから、縮退化しての再構築が可能となる。UEの通信相手となる装置も限定されることが想定されていることから、縮退化しての再構築が可能となる。
(3)バージョン。3GPPで定められた通信方式で用いるIPヘッダのバージョンは静的に決定されていることから、縮退化しても、問題なく通信を行うことができる。
(4)トラフィッククラス。EPSベアラ設定(「呼設定」と称される場合もある)の際に静的に決定されることから、縮退化しても、問題なく通信を行うことができる。
(5)ホップリミット。移動端末で終端する場合、つまり移動端末の先に更ホップすることが無い場合、縮退化しても、問題なく通信を行うことができる。
【0766】
(6)フローレベル(Flow Label)。
(7)前記(1)〜(6)の組合せ。
【0767】
本変形例は、前述の実施の形態6および実施の形態6の変形例1と組合わせて用いることができる。
【0768】
以上の実施の形態6の変形例2によって、以下の効果を得ることができる。IPアドレス分の伝送量の削減が可能となり、使用する無線リソースの低減が可能となる。
【0769】
実施の形態6 変形例3.
実施の形態6の変形例3で解決する課題を以下に説明する。非特許文献15で提案されているコネクションライト(connection-lite)の場合における伝送においては、無線区間の接続(RRC Connection)を設定してから、データを伝送する構成となっている。しかしながら、小データで、1パケットの伝送であることを想定すると、無線区間の接続を実行することは、通信端末装置の消費電力および無線リソースに影響が大きい。
【0770】
前述の問題を解決するために、前述の実施の形態1の変形例4と同様の以下の対策を行う。
【0771】
コネクションライト(connection-lite)の場合において、小データは、前述の実施の形態1の変形例4を用いて送信する。RRC待受け状態(RRC_IDLE)で、小データをeNBに送信する。小データをランダムアクセス(Random Access)処理中に送信する。詳細は、前述の実施の形態1の変形例4と同様であるので、説明を省略する。
【0772】
本変形例は、前述の実施の形態6、実施の形態6の変形例1、および実施の形態6の変形例2と組合せて用いることができる。
【0773】
以上の実施の形態6の変形例3によって、以下の効果を得ることができる。RRC接続(RRC Connection)を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
【0774】
実施の形態6 変形例4.
実施の形態6の変形例4で解決する課題は、前述の実施の形態6の変形例3と同様である。
【0775】
前述の問題を解決するために、実施の形態1の変形例5と同様の以下の対策を行う。
【0776】
コネクションライト(connection-lite)の場合において、小データは、前述の実施の形態1の変形例5を用いて送信する。RRC待受け状態(RRC_IDLE)で、小データをeNBに送信する。小データをページング処理中に送信する。詳細は、前述の実施の形態1の変形例5と同様であるので、説明を省略する。
【0777】
本変形例は、前述の実施の形態6、実施の形態6の変形例1、実施の形態6の変形例2、および実施の形態6の変形例3と組合せて用いることができる。
【0778】
以上の実施の形態6の変形例4によって、以下の効果を得ることができる。RRC接続(RRC Connection)を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
【0779】
実施の形態6 変形例5.
実施の形態6の変形例5で解決する課題を以下に説明する。実施の形態6およびその変形例1〜4において、UEとeNBのEMC(RRC)接続の状態を用いる場合は、前述の実施の形態2において挙げたUEとeNBとの間での状態不一致の課題が発生し得る。
【0780】
前記の問題を解決するために、前述の実施の形態2と同様に、RRC_CONNECTED状態においては、定期的に、「uu-keep-alive」の送信を行い、ネットワークにその状態を通知する機能を、前述の実施の形態6およびその変形例1〜3に追加する。詳細は、前述の実施の形態2と同様であるので、説明を省略する。
【0781】
本変形例は、前述の実施の形態6、実施の形態6の変形例1、実施の形態6の変形例2、実施の形態6の変形例3、および実施の形態6の変形例4と組合せて用いることができる。
【0782】
以上の実施の形態6の変形例4によって、以下の効果を得ることができる。UEとeNBとの間での状態不一致が軽減されるので、システムリソースに対する影響を軽減することができる。
【0783】
実施の形態7.
実施の形態7で解決する課題は、実施の形態6における課題と基本的に同一である。非特許文献15および非特許文献16などに示される対策ならびに前述の実施の形態6の対策は、伝送データによってコネクションライト(connection lite)という構成とコネクションオリエンテッド(connection oriented)の構成とを切り替える必要があった。しかし、前記方法では、構成の切替時に、ベアラのセットアップなどが必要となり、シグナリング処理が多くなるという課題、およびデータの伝送遅延が発生するという課題がある。
【0784】
図57および図58は、実施の形態7の課題を説明するためのシーケンスを示す図である。図57図58とは、境界線BL22の位置で、つながっている。図57および図58では、定期的に比較的小さなサイズのデータを送受信するようなアプリケーションのシーケンスを示している。図57および図58に示すシーケンスは、図27図29に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0785】
ステップST11107において、UEにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップST11109に移行する。
【0786】
ステップST11108において、eNBにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップST11110に移行する。本タイマが満了したことによって、対象のUEのRRC状態がIDLEになったと推定する。
【0787】
ステップST11109において、UEは、RRC_IDLE状態となる。また、ECM_IDLE状態となる。
【0788】
ステップST11110において、eNBは、RRC_IDLE状態となり、ステップST11111に移行する。
【0789】
ステップST11111において、S1リリース処理A(S1 Release Procedure A)が起動される。詳細は、図29のステップST5134の処理と同様であるので、説明を省略する。
【0790】
ステップST11111の処理が完了し、ステップST11112において、MMEは、ECM_IDLE状態となる。
【0791】
ステップST11111におけるS1リリース処理Aが完了した後に、ステップST11113において、UEのアプリケーションから、NASにデータの送信が要求され、送信データが送信される。
【0792】
ステップST11114において、サービス要求処理A(Service Request Procedure A)が起動される。詳細は、図27のステップST5105の処理と同様であるので、説明を省略する。
【0793】
ステップST11115において、ステップST11114で設立されたEPSベアラ(EPS Bearer)を用いて、UEからP−GW経由でアプリケーションサーバにデータが送信される。
【0794】
ステップST11116において、UEにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップST11118に移行する。
【0795】
ステップST11117において、eNBにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップST11119に移行する。
【0796】
ステップST11118において、UEは、RRC_IDLE状態となる。また、ECM_IDLE状態となる。
【0797】
ステップST11119において、eNBは、RRC_IDLE状態となる。また、ECM_IDLE状態となり、ステップST11120に移行する。
【0798】
ステップST11120において、S1リリース処理A(S1 Release Procedure A)が起動される。詳細は、図29のステップST5134の処理と同様であるので、説明を省略する。
【0799】
ステップST11120の処理が完了し、ステップST11121において、MMEは、ECM_IDLE状態となる。
【0800】
ステップST11122において、UEのアプリケーションから、NASにデータの送信が要求され、送信データが送信される。
【0801】
ステップST11123において、サービス要求処理A(Service Request Procedure A)が起動される。詳細は、図27のステップST5105の処理と同様であるので、説明を省略する。
【0802】
このように、小さなサイズのデータを送信するたびに、ステップST11114のサービス要求処理Aと、ステップST11120のサービス要求処理Aとが繰り返されることとなる。これによって、多くの手順が必要となり、これに伴うネットワークリソースおよび通信端末装置の消費電力を消費してしまうこととなる。
【0803】
前記の問題を解決するために、以下の対策を行う。
【0804】
RRCの状態と、NASの状態とが連動して遷移させない。以下、NASの状態はECM状態とも称する。
【0805】
図57および図58を用いて具体的に説明すると、ステップST11109とは異なり、UEにおいてRRC_IDLE状態に遷移しても、該遷移と連動して、UEをECM_IDLE状態に遷移させない。UEにおいて、RRC接続(RRC Connection)がリリースされても、ECM_IDLE状態へは遷移せず、ECM_CONNECTED状態を維持する。
【0806】
また、ステップST11110とは異なり、eNBがRRC_IDLE状態に遷移しても、該遷移と連動して、eNBは、S1リリース処理(S1 Release Procedure)を起動させない。つまり、eNBがRRC_IDLE状態に遷移しても、該遷移と連動して、MMEはECM_IDLE状態へ遷移させない。つまり、eNBがRRC_IDLE状態に遷移しても、S1リリース処理(S1 Releaser Procedure)を起動させないことによって、MMEにおけるECM_CONNECTED状態を維持する。
【0807】
U−plane用のE−RAB(E-UTRAN Radio Access Bearer)が設定される状態において、NASレベル(S1レベル)の接続は維持したまま、無線区間の接続のみを解放および設定することを可能とする機構を取り入れる。
【0808】
これによって、上位のベアラ、例えばS1ベアラなどを保ったまま、無線区間のリソースを開放することが可能となる。無線区間のリソースの開放の目的を達成するので、上位のベアラの再設定が必要になるという問題を解決することができる。
【0809】
通常、UEでは、RRCの状態とECMの状態とは連動して遷移する。ECM_CONNECTED状態のUEにおいてRRC接続(RRC Connection)がリリースされた場合、ECM_IDLE状態となる。RRC接続がリリースされると、RRC_IDLE状態となる。したがって、RRC接続のリリースによって、RRC_CONNECTEDからRRC_IDLEに遷移し、連動してECM_CONNECTEDからECM_IDLEに遷移する(非特許文献14 4.6.4章参照)。
【0810】
通常のネットワークでは、RRCの状態とECMの状態とは連動して遷移する。ECM_CONNECTED状態のeNBにおいて、対象となるUEのRRC状態がRRC_IDLEに遷移したと想定した場合、S1リリース処理(S1 Release Procedure)が起動される。S1接続がリリースされることから、ECM_CONNECTEDからECM_IDLEに遷移する。したがって、RRC_IDLEへの遷移に連動し、S1接続がリリースされ、ECM_CONNECTEDからECM_IDLEに遷移する(非特許文献14 4.6.4章参照)。
【0811】
通常のRRCの状態と、ECMの状態とを連動して遷移させるか、本実施の形態の解決策であるRRCの状態と、ECMの状態とを連動して遷移させないかを判断する主体としては、UEがある。前記判断を「状態遷移方法判断」と称することもある。
【0812】
状態遷移方法判断の具体例として、以下の(1),(2)の2つを開示する。
(1)UEは、アクセス要求を行ったアプリケーションに基づいて判断する。
【0813】
(1−1)定期的に比較的小さなサイズのデータを送信するアプリケーションであるか否かを判断する。定期的に比較的小さなサイズデータを送信するアプリケーションであると判断された場合は、RRCの状態と、ECMの状態とを連動して遷移させないと決定する。定期的に比較的小さなサイズデータを送信するアプリケーションでないと判断された場合は、通常のRRCの状態と、ECMの状態とを連動して遷移させると決定する。定期的に比較的小さなサイズデータを送信するアプリケーションは、従来の技術においては、無線ベアラの解放と開設とを繰り返すことなる。つまり、RRC_IDLE状態と、RRC_CONNECTED状態との間の遷移を繰り返す。これに連動して、ECM_IDLE状態と、ECM_CONNECTED状態との間の遷移を繰り返す。したがって、本実施の形態を用いることによって、処理手順の簡易化を図ることができるという効果が顕著に現れる。
【0814】
(1−2)keep-aliveパケットの送信を要求するアプリケーションであるか否かを判断する。keep-aliveパケットの送信を要求するアプリケーションであると判断された場合は、RRCの状態と、ECMの状態とを連動して遷移させないと決定する。keep-aliveパケットの送信を要求するアプリケーションでないと判断された場合は、通常のRRCの状態と、ECMの状態とを連動して遷移させると決定する。keep-aliveパケットの送信を要求するアプリケーションは、従来の技術においては、無線ベアラの解放と開設とを繰り返すことなる。つまり、RRC_IDLE状態と、RRC_CONNECTED状態との間の遷移を繰り返す。これに連動して、ECM_IDLE状態と、ECM_CONNECTED状態との間の遷移を繰り返す。したがって、本実施の形態を用いることによって、処理手順の簡易化を図ることができるという効果が顕著に現れる。
【0815】
(2)UEは、繰り返し発生する送信であるか否かを判断する。UEは、閾値未満の周期で繰り返し発生する送信であるか否かを判断するようにしてもよい。繰り返し発生する送信の具体例としては、「Uu keep alive ind」、UEモニタリング用メッセージ、周期的なメジャメントレポート、周期的なTAUなどがある。繰り返し発生する送信であると判断された場合は、RRCの状態と、ECMの状態とを連動して遷移させないと決定する。繰り返し発生する送信でないと判断された場合は、通常のRRCの状態と、ECMの状態とを連動して遷移させる決定する。周期的に繰り返される送信は、従来の技術においては、無線ベアラの解放と開設とを繰り返すことなる。つまり、RRC_IDLE状態と、RRC_CONNECTED状態との間の遷移を繰り返す。これに連動して、ECM_IDLE状態と、ECM_CONNECTED状態との間の遷移を繰り返す。したがって、本実施の形態を用いることによって、処理手順の簡易化を図ることができるという効果が顕著に現れる。
【0816】
UEは、ネットワーク側に、状態遷移判断の結果を通知する。状態遷移判断の結果をネットワーク側に通知する方法の具体例として、以下の(1),(2)の2つを開示する。
【0817】
(1)新たにシグナル、あるいはメッセージを設ける。
(1−1)新たにRRCシグナル、あるいはRRCメッセージを設ける。
(1−2)新たにNASシグナル、あるいはNASメッセージを設ける。
(1−3)新たにRRCシグナル、NASシグナルの双方を設ける。
【0818】
(2)既存のシグナル、あるいはメッセージを用いる。本具体例(2)は、具体例(1)と比較して、新たなシグナルを設ける必要がない点において有効である。本具体例(2)によって、通信システムが複雑化することを回避することができる。
【0819】
新たなシグナルにマッピングするパラメータの具体例として、以下の(1)〜(3)の3つを開示する。
(1)状態遷移判断の結果。RRCの状態と、ECMの状態とを連動して遷移させないと判断した場合のみ通知するようにしてもよい。以下の説明では、RRC状態と、ECMの状態とを連動して遷移させないと判断した場合を「RRC独立」といい、また追加するパラメータを「RRC独立」という場合がある。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)前記(1),(2)の組合せ。
【0820】
次に、既存のRRCシグナルを用いる場合の具体例としては、RRC接続要求(RRC Connection Rquest)メッセージを用いる。以下の説明では、RRC状態と、ECMの状態とを連動して遷移させないと判断した場合を「RRC独立」といい、また追加するパラメータを「RRC独立」という場合がある。
【0821】
既存のRRCシグナリングに追加が必要なパラメータの具体例としては、状態遷移判断の結果などがある。
【0822】
次に、既存のNASシグナルを用いる場合の具体例としては、サービス要求(Service Request)メッセージを用いる。
【0823】
既存のRRCシグナリングに追加が必要なパラメータの具体例としては、状態遷移判断の結果などがある。パラメータを既存のRRCシグナル、既存のNASシグナルの双方に追加してもよい。
【0824】
状態遷移判断の結果を得たeNBは、S1ベアラの設定の際に、状態遷移判断の結果を、該S1ベアラに対応付けて記憶する。具体例としては、S1ベアラの設定の際に、該S1ベアラは、通常のRRCの状態と、ECMの状態とを連動して遷移させるベアラか、または、RRCの状態と、ECMの状態とを連動して遷移させないベアラかを記憶する。あるいは、該S1ベアラとRRCベアラとは連動させて管理するか、S1ベアラとRRCベアラとは独立させて管理するかを記憶する。あるいは、RRCベアラが解放された場合にS1ベアラの解放処理(S1 Release Procedure)を開始するか、RRCベアラが解放された場合にS1ベアラの解放処理を開始しないかを記憶する。
【0825】
eNBは、状態遷移判断の結果の記憶に基づいて、以下のように動作してもよい。状態遷移判断の結果が、RRCの状態と、ECMの状態とを連動して遷移させる場合、所定の期間にRRCデータの送受信が行われるか否かの判断を行う。所定の期間を「RRCデータモニタタイマ(eNB)」と称する。
【0826】
RRCデータモニタタイマ(eNB)が満了するまでに、RRCデータの送受信が行われる場合、eNBは、RRC_CONECTED状態を継続する。またECM_CONNECTED状態を継続する。一方、RRCデータモニタタイマ(eNB)が満了するまでに、RRCデータの送受信が行われない場合、eNBは、RRC_IDLE状態に遷移する。またECM_IDLE状態に遷移する。つまり、S1リリース処理(S1 Release Procedure)を起動する。
【0827】
状態遷移判断の結果が、RRCの状態と、ECMの状態とを連動して遷移させない場合、所定の期間にRRCデータの送受信が行われるか否かの判断を行う。また、別個に所定の期間にNASデータの送受信が行われるか否かの判断を行う。所定の期間を「NASデータモニタタイマ(eNB)」と称する。
【0828】
RRCデータモニタタイマ(eNB)が満了するまでに、RRCデータの送受信が行われる場合、eNBは、RRC_CONECTED状態を継続する。一方、RRCデータモニタタイマ(eNB)が満了するまでに、RRCデータの送受信が行われない場合、eNBは、RRC_IDLE状態に遷移する。つまり、無線ベアラのリソースを解放する。無線ベアラのリソースの具体例としては、該UEに対するスケジューリングリクエストのリソースなどがある。しかし、ECM_IDLE状態に遷移しない。つまり、S1リリース処理(S1 Release Procedure)を起動しない。
【0829】
NASデータモニタタイマ(eNB)が満了するまでに、NASデータの送受信が行われる場合、eNBは、ECM_CONECTED状態を継続する。一方、NASデータモニタタイマ(eNB)が満了するまでに、NASデータの送受信が行われない場合、eNBは、ECM_IDLE状態に遷移する。つまり、S1ベアラ、EPSベアラのリソースを解放する。S1リリース処理(S1 Release Procedure)を起動するようにしてもよい。
【0830】
またUEは、状態遷移判断の結果を記憶してもよい。状態遷移判断の結果を該S1ベアラに対応付けて記憶してもよい。
【0831】
状態遷移判断の結果が、通常のRRCの状態と、ECMの状態とを連動して遷移させる場合、所定の期間にRRCデータの送受信が行われるか否かの判断を行う。所定の期間を「RRCデータモニタタイマ(UE)」と称する。
【0832】
RRCデータモニタタイマ(UE)が満了するまでに、RRCデータの送受信が行われる場合、UEは、RRC_CONECTED状態を継続する。またECM_CONNECTED状態を継続する。一方、RRCデータモニタタイマ(UE)が満了するまでに、RRCデータの送受信が行われない場合、UEは、RRC_IDLE状態に遷移する。またECM_IDLE状態に遷移する。
【0833】
状態遷移判断の結果が、RRCの状態と、ECMの状態とを連動して遷移させない場合、所定の期間にRRCデータの送受信が行われるか否かの判断を行う。また、別個に所定の期間にNASデータの送受信が行われるか否かの判断を行う。所定の期間を「NASデータモニタタイマ(UE)」と称する。
【0834】
RRCデータモニタタイマ(UE)が満了するまでに、RRCデータの送受信が行われる場合、UEは、RRC_CONECTED状態を継続する。一方、RRCデータモニタタイマ(UE)が満了するまでに、RRCデータの送受信が行われない場合、UEは、RRC_IDLE状態に遷移する。しかし、ECM_IDLE状態に遷移しない。
【0835】
NASデータモニタタイマ(UE)が満了するまでに、NASデータの送受信が行われる場合、UEは、ECM_CONECTED状態を継続する。一方、NASデータモニタタイマ(UE)が満了するまでに、NASデータの送受信が行われない場合、UEは、ECM_IDLE状態に遷移する。
【0836】
NASデータモニタタイマ(eNB)とNASデータモニタタイマ(UE)とは、同じであってもよい。同じである場合のタイマを、「NASデータモニタタイマ」と称することもある。UEとeNBとの状態不一致の期間を低減することができるという効果を得ることができる。
【0837】
NASデータモニタタイマの決定の主体の具体例としては、UEおよびeNBがある。NASデータモニタタイマの決定方法の具体例として、以下の(1)〜(3)の3つを開示する。
【0838】
(1)アプリケーションに依存して決定されるようにしてもよい。
(1−1)アプリケーションが要求するQoS、QCI、ベアラ情報などから決定してもよい。
(1−2)アプリケーションが、keep-aliveパケットを送信する場合、その周期よりも長い値。NASデータモニタタイマが満了するまでに、keep-aliveパケットの送信が発生することになる。したがって、アプリケーションが継続している間、UEとeNBとの間のECM_CONNECTED状態を継続することが可能となる。
(2)S1リソース状況。S1リソースが不足している場合は、短く設定し、S1リソースが不足していない場合は、長く設定してもよい。
(3)静的に決定する。これによって、UEとeNBとの間で通知する必要がないという効果を得ることができる。
【0839】
NASデータモニタタイマをUEが決定した場合のeNBへの通知方法の具体例として、以下の(1)〜(4)の4つを開示する。
(1)TAU処理で通知する。具体例としては、TAU要求(TAU Request)などによって通知する。
(2)アタッチ処理で通知する。具体例としては、アタッチ要求(Attach Request)、RRC接続再設定完了(RRC Connection Reconfiguration Complete)などによって通知する。
(3)RRC接続セットアップ処理(RRC Connection Setup Procedure)によって通知する。具体例としては、RRC接続セットアップ要求(RRC Connection Setup Request)などによって通知する。
(4)サービス要求処理(Service Request Procedure)によって通知する。具体例としては、サービス要求(Service Request)、RRV接続再設定完了(RRC Connection Reconfiguration Complete)などによって通知する。
【0840】
NASデータモニタタイマをeNBが決定した場合のUEへの通知方法の具体例として、以下の(1)〜(6)の6つを開示する。
(1)報知情報によって通知する。
(2)個別情報によって通知する。
(3)TAU処理によって通知する。具体例としては、TAUアクセプト(TAU Accept)などによって通知する。
(4)アタッチ処理によって通知する。具体例としては、アタッチアクセプト(Attach Accept)、RRC接続再設定(RRC Connection Reconfiguration)などによって通知する。
(5)RRC接続セットアップ処理(RRC Connection Setup Procedure)によって通知する。具体例としては、RRC接続セットアップ(RRC Connection Setup)などによって通知する。
(6)サービス要求処理(Service Request Procedure)によって通知する。具体例としては、RRC接続再設定(RRC Connection Reconfiguration)などによって通知する。
【0841】
RRCデータモニタタイマ(eNB)と、RRCデータモニタタイマ(UE)とは、同じであってもよい。同じである場合のタイマを、「RRCデータモニタタイマ」と称する。UEとeNBとの状態不一致の期間を低減することができるという効果を得ることができる。
【0842】
RRCデータモニタタイマの決定の主体の具体例としては、UEおよびeNBがある。RRCデータモニタタイマの決定方法の具体例として、以下の(1),(2)の2つを開示する。
(1)無線リソース状況。無線リソースが不足している場合は、短く設定し、無線リソースが不足していない場合は、長く設定してもよい。
(2)静的に決定する。これによって、UEとeNBとの間で通知する必要がないという効果を得ることができる。
【0843】
RRCデータモニタタイマをUEが決定した場合のeNBへの通知方法の具体例として、以下の(1)〜(3)の3つを開示する。
(1)TAU処理によって通知する。具体例としては、TAU要求(TAU Request)などによって通知する。
(2)アタッチ処理によって通知する。具体例としては、アタッチ要求(Attach Request)、RRC接続再設定完了(RRC Connection Reconfiguration Complete)などによって通知する。
(3)RRC接続セットアップ処理(RRC Connection Setup Procedure)によって通知する。具体例としては、RRC接続セットアップ要求(RRC Connection Setup Request)などによって通知する。
【0844】
RRCデータモニタタイマをeNBが決定した場合のUEへの通知方法の具体例として、以下の(1)〜(5)の5つを開示する。
(1)報知情報によって通知する。
(2)個別情報によって通知する。
(3)TAU処理によって通知する。具体例としては、TAUアクセプト(TAU Accept)などによって通知する。
(4)アタッチ処理によって通知する。具体例としては、アタッチアクセプト(Attach Accept)、RRC接続再設定(RRC Connection Reconfiguration)などによって通知する。
(5)RRC接続セットアップ処理(RRC Connection Setup Procedure)によって通知する。具体例としては、RRC接続セットアップ(RRC Connection Setup)などによって通知する。
【0845】
UEは、RRC_IDLE状態で、アプリケーションからアクセス要求が発生した場合、ECM_CONNECTEDを維持しているか否かを判断してもよい。あるいは、継続しているS1ベアラが存在するか否かを判断してもよい。
【0846】
ECM_CONNECTEDを維持していないと判断された場合、あるいは継続しているS1ベアラが存在しないと判断された場合は、該アクセス要求に対して、前記状態遷移方法判断を実行すればよい。
【0847】
ECM_CONNECTEDを維持していると判断された場合、あるいは継続しているS1ベアラが存在すると判断された場合は、維持しているECM_CONNECTEDと対応付けられたEPSベアラで送信可能なデータであるか否かを判断する。ECM_CONNECTEDと対応付けられたEPSベアラを設立した際と同様のアプリケーションからの送信要求であるか否かを判断してもよい。
【0848】
EPSベアラで送信不可能なデータであると判断された場合は、該アクセス要求に対して、前記状態遷移方法判断を実行すればよい。
【0849】
EPSベアラで送信可能なデータであると判断された場合は、RRC接続の確立を要求する。その場合、ECM_CONNECTEDを維持している旨を併せて通知する。具体例としては、RRC接続セットアップ処理(RRC Connection Setup Procedure)を起動し、併せてECM_CONNECTEDを維持している旨を通知する。また、サービス要求処理(Service Request Procedure)を起動しないようにしてもよい。
【0850】
通知方法の具体例を以下に開示する。既存のRRCシグナル、あるいはRRCメッセージを用いる。具体例としては、RRC接続要求(RRC Connection Request)を用いる。既存のRRC接続セットアップ処理(RRC Connection Setup Procedure)で用いるメッセージと同様であるので、通信システムが複雑化することを回避することができる。
【0851】
既存のRRCシグナリングに追加が必要なパラメータの具体例として、以下の(1)〜(3)の3つを開示する。
(1)既存のS1ベアラを用いる旨、ECM_CONNECTEDを維持している旨など。S1ベアラの設立が不要である旨。
(2)既存のS1ベアラを特定可能な情報。例えば、インデックス番号などがある。
(3)前記(1),(2)の組合せ。
【0852】
RRC接続セットアップ処理(RRC Connection Setup Procedure)で既存のS1ベアラを用いる旨などの通知を受けたeNBは、S1ベアラのセットアップを起動しない。また、UEからサービス要求(Service Request)が通知されてこないと認識してもよい。また、RRC接続(RRC connection)とS1ベアラとの関連付けを行い、UEにRRC接続セットアップ(RRC Connection Setup)を送信する。S1ベアラのセットアップを行うことなく、RRC接続の手続きのみでデータの送信が可能となる。
【0853】
UEは、RRCの状態と、ECMの状態とを連動して遷移させないとしている際に、アプリケーションから、サービス切断要求、あるいはサービスリリース要求を受信した場合、eNBにS1ベアラリリース要求を通知してもよい。あるいはNASレベルのリソースリリース要求を通知してもよい。
【0854】
通知方法の具体例として、以下の(1),(2)の2つを開示する。
(1)新たにRRCシグナル、あるいはRRCメッセージを設ける。以下「NASリリース要求」と称することもある。
(2)新たにNASシグナル、あるいはNASメッセージを設ける。以下「NASリリース要求」と称することもある。
【0855】
新たなシグナルにマッピングするパラメータの具体例として、以下の(1)〜(4)の4つを開示する。
(1)S1ベアラリリース要求である旨、NASレベルのリソースリリース要求である旨など、ECM_IDLEへの遷移要求である旨など。
(2)UEの識別子。具体的には、UE−ID、IMSIであってもよい。
(3)既存のS1ベアラを特定可能な情報。例えば、インデックス番号などがある。
(4)前記(1)〜(3)の組合せ。
【0856】
次に、図59図61を用いて、実施の形態7における通信システムのシーケンスの具体例について説明する。図59図61は、実施の形態7における通信システムのシーケンスの一例を示す図である。図59図60とは、境界線BL23の位置で、つながっている。図60図61とは、境界線BL24の位置で、つながっている。図59図61に示すシーケンスは、図27図29および図44図47に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0857】
ステップST5104でアクセス要求(Access Request)を受信したUEのNASは、状態遷移方法判断を実行する。状態遷移方法判断の結果がRRCの状態と、ECMの状態とを連動して遷移させない、つまり「RRC独立」となった場合において、ステップST11203において、サービス要求処理(Service Request Procedure)(RRC独立)を起動する。
【0858】
ステップST11203のサービス要求処理(RRC独立)は、ステップST11204〜ステップST9147の処理を含む。
【0859】
ステップST11204において、UEのNASは、AS(Access Stratum)にサービス要求(Service Request)メッセージを送信する。UEのNASが、RRCレイヤに通知してもよい。ステップST11204のサービス要求メッセージには、状態遷移判断の結果が含まれていてもよい。
【0860】
ステップST11204でRRCの状態と、ECMの状態とを連動して遷移させないことを示す情報(RRC独立)が含まれているサービス要求メッセージを受信したUEのRRCレイヤは、ステップST11205において、RRC接続セットアップ処理(RRC Connection Setup Procedure)(RRC独立)を起動する。
【0861】
ステップST11205のRRC接続セットアップ処理(RRC独立)は、ステップST11206〜ステップST11208の処理を含む。
【0862】
ステップST11206において、UEのRRCレイヤは、eNBにRRC接続セットアップ要求(RRC Connection Setup Request)メッセージを送信する。 RRC接続セットアップ要求メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報(RRC独立)が含まれていてもよい。
【0863】
ステップST11206でRRC接続セットアップ要求メッセージを受信したeNBは、ステップST11207において、UEのRRCレイヤにRRC接続セットアップ(RRC Connection Setup)メッセージを送信する。RRC接続セットアップメッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0864】
ステップST11207でRRC接続セットアップメッセージを受信したUEは、ステップST11208において、eNBにRRC接続セットアップ完了(RRC Connection Setup Complete)メッセージを送信する。RRC接続セットアップ完了メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0865】
ステップST11205のRRC接続セットアップ処理(RRC独立)が完了することによって、ステップST11209において、UEは、RRC_CONNECTED状態となる。また、UEは、ECM_CONNECTED状態となる。
【0866】
同様に、ステップST11210において、eNBは、該UEのRRC状態を、RRC_CONNECTED状態と想定する。以下、単に「eNBはRRC_CONNECTED状態となる」という。
【0867】
ステップST11211において、UEのRRCレイヤは、eNBにサービス要求(Service Request)メッセージを送信する。サービス要求メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0868】
ステップST11211でサービス要求メッセージを受信したeNBは、ステップST11212において、MMEにサービス要求(Service Request)メッセージを送信する。サービス要求メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0869】
ステップST11213において、MMEは、HSSの情報を用いて、UEの認証(authentication)およびセキュリティ(security)制御の処理を行う。
【0870】
ステップST11214において、MMEは、eNBに初期コンテキストセットアップ要求(Initial Context Setup Request)メッセージを送信する。 初期コンテキストセットアップ要求メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0871】
ステップST11214で初期コンテキストセットアップ要求メッセージを受信したeNBは、ステップST11215において、無線ベアラ設立処理(Radio Bearer Establishment Procedure)(RRC独立)を起動する。
【0872】
ステップST11215の無線ベアラ設立処理(RRC独立)は、ステップST11216〜ステップST11217の処理を含む。
【0873】
ステップST11216において、eNBは、UEにRRC接続再設定(RRC Connection Reconfiguration)メッセージを送信する。RRC接続再設定メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0874】
ステップST11216でRRC接続再設定メッセージを受信したUEは、ステップST11217において、eNBにRRC接続再設定完了(RRC Connection Reconfiguration Complete)メッセージを送信する。RRC接続再設定完了メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0875】
ステップST11217でRRC接続再設定完了メッセージを受信したeNBは、ステップST11218において、MMEに初期コンテキストセットアップ完了(Initial Context Setup Complete)メッセージを送信する。初期コンテキストセットアップ完了メッセージには、RRCの状態と、ECMの状態とを連動して遷移させないことを示す情報が含まれていてもよい。
【0876】
ベアラ修正応答メッセージを受信したMMEは、ステップST11225において、該UEに対してECM_CONNECTED状態に移行する。あるいは、該UEに対するS1コネクションの設立が完了したことで、MMEは、該UEに対してECM_CONNECTED状態に移行してもよい。該UEに対するS1コネクションの設立が完了したことは、MMEは、ステップST11218における初期コンテキストセットアップ完了メッセージの受信で認識する。
【0877】
ステップST11203において、サービス要求処理(RRC独立)が完了することによって、ステップST11229において、UEから、eNBとMMEとS−GWとP−GWとを経由して、アプリケーションサーバ(APP Server)へのデータの送信が可能となる。
【0878】
図61のステップST11230において、UEにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。UEは、現在のRRC接続がRRCの状態と、ECMの状態とを連動して遷移させない(RRC独立)のベアラであるか否かを判断する。RRCの状態と、ECMの状態とを連動して遷移させない(RRC独立)ベアラであると判断された場合は、RRCのみIDLE状態へ移行し、ECMはCONNECTEDを維持する。RRCの状態と、ECMの状態とを連動して遷移させない(RRC独立)ベアラでないと判断された場合は、RRCおよびECMともに、IDLE状態へ移行する。本シーケンスでは、RRC独立ベアラであるので、ステップST11232およびステップST11233に移行する。
【0879】
ステップST11231において、eNBにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップST11234に移行する。前記タイマが満了したことによって、対象のUEのRRC状態がIDLEになったと想定、あるいは推定する。
【0880】
ステップST11232において、UEは、RRC_IDLE状態となる。
【0881】
ステップST11233において、UEは、記憶している状態遷移判断結果を参照してもよい。状態遷移判断結果が、通常のRRCの状態と、ECMの状態とを連動して遷移させる場合、UEは、ECMの状態をRRCの状態と連動して遷移させる。つまりECM状態をECM_IDLEへ遷移させる。一方、状態遷移判断結果が、RRCの状態と、ECMの状態とを連動して遷移させない場合、UEは、ECMの状態をRRCの状態と連動して遷移させずに、ECM_CONNECTED状態を維持する。本動作例では、ステップST11233において、UEは、ECM_CONNECTED状態を維持する。
【0882】
ステップST11234において、eNBは、RRC_IDLE状態となり、ステップST11235に移行する。
【0883】
ステップST11235において、eNBは、記憶している状態遷移判断結果を参照してもよい。状態遷移判断結果が、RRCの状態と、ECMの状態とを連動して遷移させない場合は、ECM_CONNECTED状態を維持する。つまり、S1リリース処理A(S1 Release Procedure A)を起動しない。
【0884】
状態遷移判断結果が、通常のRRCの状態と、ECMの状態とを連動して遷移させる場合は、ECM状態もIDLEへ移行させる。つまり、ステップST11236に移行し、S1リリース処理A(S1 Release Procedure A)を起動する。S1リリース処理Aの詳細は、図27のステップST5105の処理と同様であるので、説明を省略する。また、図59図61では、その後の処理の説明を省略し、「終了」と記載する。
【0885】
ステップST11235において、状態遷移判断結果が、RRCの状態と、ECMの状態とを連動して遷移させないと判断された場合は、S1リリース処理Aが起動されないので、ステップST11237において、ECM_CONNECTEDは維持される。
【0886】
ステップST11238において、UEのアプリケーションから、NASにデータの送信が要求され、送信データが送信される。
【0887】
UEのNASは、ECM_CONNECTEDを維持しているか否かを判断してもよい。ECM_CONNECTEDを維持していない場合は、通常のサービス要求処理A(Service Request Procedure A)を起動させる。通常のサービス要求処理Aの詳細は、ステップST11114の処理と同様であるので、説明を省略する。
【0888】
ECM_CONNECTEDを維持している場合、維持しているECM_CONNECTEDと対応付けられたEPSベアラ(EPS Bearer)で送信可能なデータであるか否かを判断する。言い換えれば、ECM_CONNECTEDと対応付けられたEPSベアラ(EPS Bearer)を設立したときと同様のアプリケーションからの送信要求であるか否かを判断する。EPSベアラで送信不可能なデータである場合は、通常のサービス要求処理Aを起動させる。通常のサービス要求処理Aの詳細は、ステップST11114の処理と同様であるので、説明を省略する。EPSベアラで送信可能なデータである場合は、ステップST11239に移行する。
【0889】
ステップST11239において、UEは、RRC接続セットアップ処理を起動する。その場合、ECM_CONNECTEDを維持している旨を併せて通知する(以下「既存S1ベアラ」という場合がある)。また既存のS1ベアラとして特定可能な情報を通知してもよい。RRC接続セットアップ処理(RRC Connection Setup Procedure)(既存S1ベアラ)を起動する。
【0890】
ステップST11239のRRC接続セットアップ処理(既存S1ベアラ)は、ステップST11240〜ステップST11242の処理を含む。
【0891】
ステップST11240において、UEのRRCレイヤは、eNBにRRC接続要求(RRC Connection Request)メッセージを送信する。 RRC接続要求メッセージには、ECM_CONNECTEDを維持している旨、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。
【0892】
ステップST11240でRRC接続要求メッセージを受信したeNBは、ステップST11241において、UEのRRCレイヤにRRC接続セットアップ(RRC Connection Setup)メッセージを送信する。RRC接続セットアップメッセージには、ECM_CONNECTEDを維持している旨、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。
【0893】
ステップST11241でRRC接続セットアップメッセージを受信したUEは、ステップST11242において、eNBにRRC接続セットアップ完了(RRC Connection Setup Complete)メッセージを送信する。RRC接続セットアップ完了メッセージには、ECM_CONNECTEDを維持している旨、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。
【0894】
ステップST11243において、対応する接続を用いて、UEから、P−GW経由でアプリケーションサーバにデータが送信される。具体的には、対応するEPSベアラ(EPS bearer)を用いて、データが送信される。
【0895】
ステップ11244において、UEにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。ステップST11244の処理の詳細は、ステップST11230の処理と同様であるので、説明を省略する。
【0896】
ステップST11245において、eNBにおけるRRCレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。ステップST11245の処理の詳細は、ステップST11231の処理と同様であるので、説明を省略する。
【0897】
ステップST11247において、UEは、RRC_IDLE状態となる。ステップST11248において、eNBは、RRC_IDLE状態となり、ステップST11235の処理と同様の処理を実行する。ステップST11235と同様の処理を行うことによって、状態遷移判断結果が、RRCの状態と、ECMの状態とを連動して遷移させない場合は、S1リリース処理Aが起動されないので、ECM_CONNECTEDは維持される。
【0898】
ステップST11245において、UEのアプリケーションから、NASにデータの送信が要求され、送信データが送信される。ステップST11245の処理の詳細は、ステップST11238の処理と同様であるので、説明を省略する。
【0899】
ステップST11249において、UEは、RRC接続セットアップ処理(RRC Connection Setup Procedure)(既存S1ベアラ)を起動する。ステップST11249の処理の詳細は、ステップST11239の処理と同様であるので、説明を省略する。
【0900】
ステップST11250において、対応する接続を用いて、UEから、P−GW経由でアプリケーションサーバにデータが送信される。具体的には、対応するEPSベアラ(EPS bearer)を用いて、データが送信される。以下、前述の処理を繰り返す。
【0901】
次に、図62および図63を用いて、実施の形態7における通信システムのシーケンスの具体例にについて説明する。図62および図63は、実施の形態7における通信システムのシーケンスの他の例を示す図である。図62図63とは、境界線BL25の位置で、つながっている。図62および図63では、状態遷移判断結果が、RRCの状態と、ECMの状態とを連動して遷移させないとして開設されたS1ベアラを、UE起点の解放手続きで開放する場合のシーケンスを示している。図62および図63に示すシーケンスは、図27図29および図59図61に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0902】
図63のステップST11323において、UEのアプリケーションから、UEのNASに、サービス切断要求、あるいはサービスリリース要求が送信される。
【0903】
UEのNASは、ECM_CONNECTEDを維持しているか否かを判断してもよい。ECM_CONNECTEDを維持していないと判断された場合は、UEの状態をRRC_IDLEと、ECM_IDLEとに遷移させる処理を実行する。ECM_CONNECTEDを維持していると判断された場合は、ステップST11324に移行するようにしてもよい。
【0904】
ステップST11324において、UEのNASは、AS(Access Stratum)に、NASレベル(S1ベアラ)の接続のリリースを要求する。具体的には、NASリリース要求(NAS Release Request)メッセージの送信を要求する。UEのNASが、RRCレイヤに通知してもよい。
【0905】
ステップST11325において、UEは、RRC接続セットアップ処理(RRC Connection Setup Procedure)を行う。RRC接続セットアップ処理の詳細は、ステップST9104と同様であるので、説明を省略する。あるいは、ステップST11325において、UEは、RRC接続セットアップ処理(RRC Connection Setup Procedure)(既存S1ベアラ)を起動する。RRC接続セットアップ処理(既存S1ベア)の詳細は、ステップST11239の処理と同様であるので、説明を省略する。
【0906】
ステップST11326において、UEは、NASレベル(S1ベアラ)の接続のリリース要求をeNBに送信する。具体的には、NASリリース要求(NAS Release Request)メッセージを送信する。NASリリース要求メッセージには、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。
【0907】
ステップST11326でNASリリース要求メッセージを受信したeNBは、ステップST11327において、MMEにNASリリース要求(NAS Release Request)メッセージを送信する。NASリリース要求メッセージには、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。
【0908】
ステップST11327でNASリリース要求メッセージを受信したMMEは、ステップST11328において、該S1ベアラをリリースする処理を起動する。具体的には、S1リリース処理B(S1 Release Procedure B)を起動する。S1リリース処理BとS1リリース処理Aとの違いは、S1リリース処理Bには、eNB起点のUEコンテキストリリース要求(UE Context Release Request)が存在しないことである。
【0909】
ステップST11328のS1リリース処理Bは、ステップST11329〜ステップST11333の処理を含む。
【0910】
ステップST11329において、MMEは、S−GWにアクセスベアラリリース要求(Release Access Bearers Request)メッセージを送信する。 アクセスベアラリリース要求メッセージには、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。あるいは、RRCの状態と、ECMの状態とを連動して遷移させないS1ベアラをリリースする処理である旨の情報が含まれていてもよい。
【0911】
ステップST11329でアクセスベアラリリース要求メッセージを受信したS−GWは、ステップST11330において、アクセスベアラリリース応答(Release Access Bearers Response)メッセージをMMEに送信する。アクセスベアラリリース応答メッセージは、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。あるいは、RRCの状態と、ECMの状態とを連動して遷移させないS1ベアラをリリースする処理である旨の情報が含まれていてもよい。
【0912】
ステップST11330でアクセスベアラリリース応答メッセージを受信したMMEは、ステップST11331において、UEコンテキストリリースコマンド(UE Context Release Command)をeNBに送信する。UEコンテキストリリースコマンドには、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。あるいは、RRCの状態と、ECMの状態とを連動して遷移させないS1ベアラをリリースする処理である旨の情報が含まれていてもよい。
【0913】
ステップST11331でUEコンテキストリリースコマンドを受信したeNBは、ステップST11332において、RRC接続リリース(RRC Connection Release)メッセージをUEに通知する。
【0914】
ステップST11333において、eNBは、UEコンテキストリリース完了(UE Context Release Complete)メッセージをMMEに通知する。 UEコンテキストリリース完了メッセージには、対応する接続に該当するS1ベアラを特定する情報が含まれていてもよい。あるいは、RRCの状態と、ECMの状態とを連動して遷移させないS1ベアラをリリースする処理である旨の情報が含まれていてもよい。
【0915】
このような動作によって、RRC独立ベアラに対して開設されたS1ベアラのタイマによる解放が可能となる。
【0916】
次に、図64および図65を用いて、実施の形態7における通信システムのシーケンスの具体例について説明する。図64および図65は、実施の形態7における通信システムのシーケンスの他の例を示す図である。図64図65とは、境界線BL26の位置で、つながっている。図64および図65では、RRCの状態と、ECMの状態とを連動して遷移させないとして開設されたS1ベアラのタイマによる解放手続で開放する場合のシーケンスを示している。図64および図65に示すシーケンスは、図27図29および図59図61に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
【0917】
図65のステップST11423において、UEにおけるNASレベルでのデータ未送信期間を計測するデータモニタタイマが満了する。NASレベルでのデータ未送信期間の計測は、状態遷移方法判断の結果がRRCの状態と、ECMの状態とを連動して遷移させなかった場合のS1ベアラが設定された場合のみとしてもよい。ステップST11424において、UEは、ECM_IDLE状態となる。
【0918】
ステップST11425において、eNBにおけるNASレベルでのデータ未送信期間を計測するデータモニタタイマが満了し、ステップST11426に移行する。前記タイマが満了したことによって、対象のUEのECM状態がIDLEになったと推定する。NASレベルでのデータ未送信期間の計測は、状態遷移方法判断の結果がRRCの状態と、ECMの状態とを連動して遷移させなかった場合のS1ベアラが設定された場合のみとしてもよい。
【0919】
ステップST11426において、eNBは、S1リリース処理A(S1 Release Procedure A)を起動する。ステップST11426の処理の詳細は、図29のステップST5134の処理と同様であるので、説明を省略する。
【0920】
ステップST11426の処理が完了すると、ステップST11428において、MMEは、ECM_IDLE状態となる。
【0921】
このような動作によって、状態遷移方法判断の結果がRRCの状態と、ECMの状態とを連動して遷移させなかった場合のS1ベアラのタイマによる解放が可能となる。
【0922】
以上の実施の形態7によって、以下の効果を得ることができる。NASレベルの接続は維持したまま、無線区間の接続のみを解放および設定することを可能とする機構の実現が可能となる。
【0923】
RRCの状態の遷移と上位ベアラ、例えばS1ベアラの設定とが独立化されるので、無線アクセスネットワークにおけるシステムリソース、具体的には無線リソースおよび通信ノードにおける処理負荷などを利用してしまうという問題、ならびにUEの消費電力を増加させるという問題を軽減することができる。また、前述の実施の形態6のようなS1ベアラのセットアップを含まず、RRCの接続のみで対応可能であるので、処理手順が簡易化される。
【0924】
実施の形態7 変形例1.
実施の形態7の変形例1で解決する課題を以下に説明する。前述の実施の形態7において、RRC独立ベアラの開設時で、UEがRRC_IDLE状態でデータを送信する場合に、RRC接続(RRC Connection)を開設する必要があった。しかしながら、小さいデータで、1パケットの伝送であることを想定すると、無線区間の接続を実行することは、通信端末装置の消費電力および無線リソースに影響が大きい。
【0925】
前記の問題を解決するために、前述の実施の形態1の変形例4と同様の以下の対策を行う。コネクションライト(connection-lite)の場合において、小さいデータは、RRC接続(RRC Connection)を開設せずに、ランダムアクセス手順内において、データを送信する。なお、送信手順は、前述の実施の形態1の変形例4と同様とする。
【0926】
前記対策によって、RRC接続(RRC Connection)を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
【0927】
実施の形態7 変形例2.
実施の形態7変形例2で解決する課題は、実施の形態7の変形例1と同様である。
【0928】
前記の問題を解決するために、前述の実施の形態1の変形例5と同様の以下の対策を行う。コネクションライト(connection-lite)の場合において、小さいデータは、RRC接続(RRC Connection)を開設せずに、ページング手順内において、データを送信する。なお、送信手順は、前述の実施の形態1の変形例5と同様とする。
【0929】
前記対策によって、RRC接続(RRC Connection)を設定しないので、その手順が省略可能となり、通信端末装置の消費電力および無線リソースの低減が可能となる。
【0930】
実施の形態7 変形例3.
実施の形態7の変形例3で解決する課題を以下に説明する。前述の実施の形態7およびその変形例1,2において、UEとeNBのEMC(RRC)接続の状態を用いる場合は、前述の実施の形態2において挙げたUEとeNBとの間での状態不一致の課題が発生し得る。
【0931】
前記の問題を解決するために、前述の実施の形態2と同様に、RRC_CONNECTED状態においては、定期的に、「uu-keep-alive」の送信を行い、ネットワークにその状態を通知する機能を、前述の実施の形態6およびその変形例1〜3に追加する。なお、「uu-keep-alive」の送信手順は、前述の実施の形態2と同様とする。
【0932】
本変形例によれば、UEとeNBとの間での状態不一致が軽減されるので、システムリソースに対する影響を軽減することができる。
【0933】
この発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。
【符号の説明】
【0934】
71 通信端末装置(UE)、72 基地局装置、72−1 eNB、72−2 Home−eNB、73 MME/S−GW部(MME部)、74 HeNBGW。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37
図38
図39
図40
図41
図42
図43
図44
図45
図46
図47
図48
図49
図50
図51
図52
図53
図54
図55
図56
図57
図58
図59
図60
図61
図62
図63
図64
図65
【国際調査報告】