(実施の形態1)
以下、図面を参照して本開示の実施の形態について説明する。図1を用いて実施の形態1にかかるゲートウェイ装置10の構成例について説明する。ゲートウェイ装置10は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。ゲートウェイ装置10は、3GPPにおいて定められているSGWもしくはGGSN(Gateway GPRS(General Packet Radio Service) Support Node)であってもよい。
ゲートウェイ装置10は、記憶部11及び通信部(transceiver)12を有している。記憶部11及び通信部12は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、記憶部11及び通信部12は、回路もしくはチップ等のハードウェアであってもよい。通信部は、送信部(transmitter)及び受信部(receiver)であってもよい。
記憶部11は、通信端末に一時的に割り当てられている一時割当識別情報及び通信端末に関するeDRXパラメータを記憶する。通信端末は、携帯電話端末、スマートフォン端末、もしくはタブレット型端末であってもよい。もしくは、通信端末は、IoT(Internet of Things)サービスに用いられるIoTデバイス、M2M(Machine to Machine)デバイス、もしくはMTC(Machine Type Communication)デバイスであってもよい。
一時割当識別情報は、例えば、GUTIであってもよく、GUTIに含まれるM-TMSIおよびMMECから成るS-TMSIであってもよい。eDRXパラメータは、通信端末がeDRX機能を実行する際に用いる情報である。eDRXパラメータは、例えば、paging time window及びeDRX valueであってもよい。ゲートウェイ装置10は、例えば、MMEから一時割当識別情報及びeDRXパラメータを取得してもよい。ゲートウェイ装置10は、取得した一時割当識別情報及びeDRXパラメータを、記憶部11に記憶してもよい。
通信部12は、移動管理装置20、21を含む複数の移動管理装置と通信を行う。移動管理装置20は、例えば、MMEやSGSN(Serving GPRS Support Node)であってもよい。ここで、ゲートウェイ装置10は、通信部12を介して、移動管理装置20に障害が発生した後に、移動管理装置20が管理していた通信端末を宛先とするダウンリンクデータを受信した場合を想定する。なお、ゲートウェイ装置10は、例えば、移動管理装置20との間において実施されているヘルスチェック処理等に基づいて、移動管理装置20に発生した障害及び障害からの復旧を検出することができる。ヘルスチェック処理は、GTPプロトコルで規定されるECHO Request、およびECHO responseの送受で実施されても良い。移動管理装置20は、障害から復旧した場合でも、障害前まで管理していた通信端末に関する情報を消失している場合がある。なお、通信端末に関する情報は、一時割当識別情報及びeDRXパラメータ等であってもよい。さらに、通信端末に関する情報は、通信端末を識別するIMSIであってもよい。このような場合、ゲートウェイ装置10の通信部12は、記憶部11において記憶されている、ダウンリンクデータの宛先となる通信端末に関する一時割当識別情報及びeDRXパラメータを設定した通知メッセージを、移動管理装置20もしくは移動管理装置20とは異なる他の移動管理装置21へ送信する。
その通知メッセージは、移動管理装置20もしくは移動管理装置20とは異なる他の移動管理装置21に対して、通信端末を宛先とするダウンリンクデータを受信したことを通知するために用いられる。ここで、通信部12は、障害から復旧した移動管理装置20に通知メッセージを送信してもよく、移動管理装置20とは異なる他の移動管理装置21へ通知メッセージを送信してもよい。
通知メッセージを受信した移動管理装置20もしくは他の移動管理装置21は、通知メッセージに含まれる一時割当識別情報及びeDRXパラメータを用いて、通信端末に対するPaging処理を実行することができる。言い換えると、移動管理装置20もしくは他の移動管理装置21は、GUTIに含まれるS-TMSI、及びeDRXパラメータを用いてページングを実行するタイミングを算出することができる。また、通信端末は、TAU処理時に通知されたGUTIに含まれるS-TMSI、及びeDRXパラメータを用いてPaging Channelを監視するタイミングを算出する。そのため、eDRX機能を実行している通信端末がPaging Channelを監視するタイミングと、移動管理装置20が基地局を介してページングを実行するタイミングとを一致させることができる。その結果、通信端末は、正常に、自装置宛のページングに関する処理を実行することができる。
(実施の形態2)
続いて、図2を用いて実施の形態2にかかる通信システムの構成例について説明する。図2の通信システムは、無線通信方式としてLTEをサポートする通信システムであり、3GPPにおいてEPS(Evolved Packet System)として規定された通信システムを含む。なお、図2は、TS 23.401 V 13.8.0 Figure 4.2.1-1の図に基づいている。
図2の通信システムは、UE40、E-UTRAN(Evolved-Universal Terrestrial Radio Access Network)41、MME42、HSS(Home Subscriber Server)43、SGSN44、SGW(Serving Gateway)45、PGW(Packet Data Network Gateway)46、PCRF(Policy and Charging Rules Function)エンティティ47(以下、PCRF47とする)、UTRAN48、GERAN(GSM(Global System for Mobile communications)(登録商標) EDGE(Enhanced Data Rates for Global Evolution) Radio Access Network)49、Operator’s IP Services50を有している。
MME42は、図1の移動管理装置20に相当する。SGW45は、図1のゲートウェイ装置10に相当する。SGSN44は、図1の移動管理装置20に相当する。GGSNは、図1のゲートウェイ装置10に相当する。
UEは、3GPPにおいて通信端末の総称として用いられる用語である。UEは、MS(Mobile Station)と置き換えられてもよい。E-UTRAN41は、無線アクセスシステムとしてLTEを用いるRAN(Radio Access Network)であり、eNBを備える。UTRAN48は、無線アクセスシステムとして3G無線方式を用いるRANであり、NodeBを備える。GERAN49は、無線アクセスシステムとして2G無線方式を用いるRANである。
MME42及びSGSN44は、UE40に関するモビリティ管理及びセッション管理等を実行するノードである。HSS43は、UE40に関する加入者情報を管理するノードである。加入者情報は、UE40が利用するサービスに関する情報を含んでいてもよい。SGW45及びPGW46は、UE40とOperator’s IP Services50との間において伝送されるデータを中継するゲートウェイである。Operator’s IP Services50は、例えば、UE40へサービスを提供する事業者等が管理するサーバ装置、もしくは、サーバ装置群等であってもよい。また、Operator’s IP Services50は、INTERNETへの接続を提供するサーバ装置でもよい。
PCRF47は、ポリシー及び課金ルール等を管理するノードである。
UE40とE-UTRAN41との間は、LTE-Uuリファレンスポイントが定められている。E-UTRAN41とMME42との間は、S1-MMEリファレンスポイントが定められている。MME42とHSS43との間は、S6リファレンスポイントが定められている。MME42とSGSN44との間は、S3リファレンスポイントが定められている。E-UTRAN41とSGW45との間は、S1-Uリファレンスポイントが定められている。MME42とSGW45との間は、S11リファレンスポイントが定められている。SGSN44とSGW45との間は、S4リファレンスポイントが定められている。SGW45とUTRAN48との間は、S12リファレンスポイントが定められている。SGW45とPGW46との間は、S5/S8リファレンスポイントが定められている。PGW46とPCRF47との間は、Gxリファレンスポイントが定められている。PGW46とOperator’s IP Services50との間は、SGiリファレンスポイントが定められている。PCRF47とOperator’s IP Services50との間は、Rxリファレンスポイントが定められている。MME42と他のMMEとの間は、S1-10リファレンスポイントが定められている。
続いて、図3を用いて実施の形態2にかかるMME42の構成例について説明する。MME42は、計算部(calculator)71及び通信部(transceiver)72を有している。計算部71及び通信部72は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、計算部71及び通信部72は、チップもしくは回路等のハードウェアであってもよい。通信部は、送信部(transmitter)及び受信部(receiver)であってもよい。
通信部72は、SGW45へ、UE40に割り当てたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータとを送信する。通信部72が、SGW45へUE40に割り当てたGUTI等を送信するタイミングについては後に詳述する。SGW45は、図1のゲートウェイ装置10と同様の構成である。MME42は、UE40に関するeDRXパラメータを、UE40から取得してもよい。さらに、MME42が障害発生後に障害から復旧した場合、通信部72は、SGW45から、UE40に割り当てたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータとを含むDDN(Downlink Data Notification)メッセージを受信する。DDNメッセージは、SGW45にUE40を宛先とするDownlink Dataが送信されてきたことをMME42へ通知するために用いられるメッセージである。
MME42は、UE40を含む複数のUEに関する情報、具体的にはUEの加入者データを管理している。しかし、MME42は、障害発生後に障害から復旧した場合、複数のUEに関する情報を消失する。
計算部71は、MME42が障害から復旧した場合に、DDNメッセージを受信すると、そのDDNメッセージに含まれるS-TMSI及びeDRXパラメータを用いて、eDRX機能を適用するUE40におけるPaging Channelの監視周期を計算する。
通信部72は、計算部71において計算された監視周期に間に合うように、E-UTRAN41に含まれるeNB51へPagingメッセージを送信する。Pagingメッセージには、UE40に割り当てたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータとが含まれる。
続いて、図4を用いて実施の形態2にかかるeNB51の構成例について説明する。eNB51は、計算部81及び通信部82を有している。計算部81及び通信部82は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、計算部81及び通信部82は、チップもしくは回路等のハードウェアであってもよい。
通信部82は、MME42から、Pagingメッセージを受信する。Pagingメッセージには、UE40に割り当てたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータとが含まれる。
計算部81は、Pagingメッセージを受信すると、S-TMSI及びeDRXパラメータを用いて、eDRX機能を適用するUE40におけるPaging Channelの監視周期を計算する。
通信部72は、計算部71において計算された監視周期に合わせて、UE40を含む複数のUEに対してPagingを実行する。
続いて、図5を用いて実施の形態2にかかるUE40の構成例について説明する。UE40は、通信部(transceiver)61及び制御部(controller)62を有している。通信部61及び制御部62は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、通信部61及び制御部62は、チップもしくは回路等のハードウェアであってもよい。
制御部62は、eDRX機能を実行する。例えば、制御部62は、eDRXサイクルに従って、通信部61を介して、UE40宛てのページングが実行されているかを監視する。言い換えると、制御部62は、eDRXサイクルに従って通信部61を介してPaging Channelを監視する。制御部62は、UE40宛てのページングが実行されていると判定した場合、通信部61を介して応答メッセージをeNB51へ送信する。また、通信部61は、TAU処理、Attach処理、もしくは任意のタイミングにおいて、MME42からeNB51を介してGUTIを受信する。制御部62は、eDRXパラメータ及びGUTIに含まれるS-TMSIを用いて、Paging Channelの監視タイミングを計算する。
MME42においてGUTIが更新された場合、制御部62は、通信部61を介して、MME42から更新後の新たなGUTIを受信する。制御部62は、受信したGUTIに含まれる新たなS-TMSI及びeDRXパラメータを用いて新たな監視タイミングを計算する。Paging Channelの監視タイミングは、S-TMSI及びeDRXパラメータに基づいて定まるため、S-TMSIが更新された場合、Paging Channelの監視タイミングも変更される。
続いて、図6を用いて、TAU処理の流れについて説明する。はじめに、UE40は、予め定められたタイミング、もしくは、在圏エリアを示すTAが変更されたタイミング等に、TAU Requestメッセージを含むRRCメッセージをeNB51へ送信する(S11)。UE40は、eDRX適用端末であるとする。この場合、UE40が送信するTAU Requestメッセージには、eDRXパラメータが含まれる。次に、eNB51は、UE40から送信されたTAU Requestメッセージを含むS1-APメッセージをMME42へ送信する(S12)。
MME42は、GUTI Reallocation Procedureを実行する(S13)。具体的には、MME42は、現在UE40に割り当てられているGUTI(old GUTI)を更新して新たなGUTI(new GUTI)を生成する。例えば、MME42は、old GUTIに含まれるM-TMSIを更新する。
MME42は、new GUTIを含むTAU Acceptメッセージを含むS1-APメッセージをeNBへ送信する(S14)。ステップS12からS14の間に実行されるTAU処理については、既知の処理であるため詳細な説明を省略する。次に、eNB51は、MME42から送信されたTAU Acceptメッセージを含むRRCメッセージをUE40へ送信する(S15)。
MME42は、S14においてTAU Acceptメッセージを含むS1-APメッセージをeNB51へ送信した後に、Modify Bearer RequestメッセージをSGW45へ送信する(S16)。MME42が送信するModify Bearer Requestメッセージには、new GUTI及びUE40に関するeDRXパラメータが含まれている。また、MME42は、ステップS13におけるGUTI Reallocation Procedureを実行後であって、ステップS14においてTAU AcceptメッセージをeNB51に送信する前に、Modify Bearer RequestメッセージをSGW45へ送信してもよい。
ステップS11~S16の処理が実行されることによって、SGW45は、UE40に一時的に割り当てられたGUTI及びUE40に関するeDRXパラメータを取得することができる。また、ステップS16において、MME42が送信するModify Bearer Requestには、new GUTIの代わりに、new GUTIに含まれるS-TMSIが含まれてもよい。
また、図6においては、TAU処理においてGUTI及びeDRXパラメータがSGW45へ送信されることが説明されているが、Attach処理において、TAU処理と同様にGUTIもしくはGUTIに含まれるS-TMSIと、eDRXパラメータとがSGW45へ送信されてもよい。Attach処理においては、ステップS11及びS12では、TAU Requestメッセージの代わりに、Attach Requestメッセージが用いられる。また、ステップS14及びS15では、TAU Acceptメッセージの代わりにAttach Acceptメッセージが用いられる。ステップS13及びS16では、Attach処理においてもTAU処理と同様に実施される。また、Attach処理においては、ステップS13の後に、MME42が送信するCreate Session RequestメッセージにGUTIもしくはGUTIに含まれるS-TMSIと、eDRXパラメータとを設定しSGW45へ送信されてもよい。もしくは、周期位置登録(periodic TAU)においてもS1 connection復旧まで実施しない(Active Flag=OFFの)場合や、主にS1 connectionが有る状態での移動、つまり非特許文献1の5.5節に規定されているHandover処理が発生した後に、変更後のTAを通知をするためだけのUplink NAS Transportで送信するTAUにおいては、Create Session Request/Modify Bearer Requestの送信契機は無い為、これらの場合においてはMME42は、他のメッセージを用いてnew GUTI等をSGW45へ送信してもよい。
続いて、図7を用いて、実施の形態2にかかるGUTIの通知シーケンスについて説明する。図7は、MME42が、任意のタイミングに更新したGUTI(new GUTI)をUE40へ送信することを示している。MME42は、任意のタイミングにGUTI Reallocation CommandメッセージをeNB51を介してUE40へ送信する(S21)。GUTI Reallocation Commandメッセージは、new GUTIを含む。次に、UE40は、GUTI Reallocation Commandメッセージに対する応答としてGUTI Reallocation CompleteメッセージをeNB51を介してMME42へ送信する(S22)。次に、MME42は、SGW45へChange Notification Requestメッセージを送信する(S23)。MME42が送信するChange Notification Requestメッセージには、new GUTI及びUE40に関するeDRXパラメータが含まれている。
次に、SGW45は、Change Notification Requestメッセージに対する応答として、Change Notification ResponseメッセージをMME42へ送信する(S24)。
ステップS21~S24の処理が実行されることによって、SGW45は、UE40に一時的に割り当てられたGUTI及びUE40に関するeDRXパラメータを取得することができる。また、ステップS23において、MME42が送信するChange Notification Requestメッセージには、new GUTIの代わりに、new GUTIに含まれるS-TMSIが含まれてもよい。
図7においては、MME42が、Change Notification Requestメッセージを用いて、new GUTI及びUE40に関するeDRXパラメータをSGW45へ送信している例を示したが、MME42は、他のメッセージを用いてnew GUTI等をSGW45へ送信してもよい。
また、図6及び図7において、TAU処理、Attach処理、及び任意のタイミングにGUTIを通知する処理において、new GUTI等をSGW45へ送信する例を示したが、MME42は、これら以外の処理において、new GUTI等をSGW45へ送信してもよい。具体的には、周期位置登録(periodeic TAU)時にS1 connection復旧まで実施しない(Active Flag=OFFの)TAU、もしくは、S1 connectionが有る状態でのUE移動、つまり非特許文献1の5.5節に規定されているHandover処理が発生した後に、変更後のTAを通知をするためだけのUplink NAS Transportで送信するTAUにおいてはCreate Session RequestもしくはModify Bearer Requestを送信しない場合等がある。
続いて、図8を用いて実施の形態2にかかるパケット着信処理の流れについて説明する。ここで、MME42は、障害が発生し(S30)、その後、発生した障害が復旧する(S33)。MME42は、障害から復旧した場合に、障害前まで管理していたUE40を含む複数のUEに関する情報を消失している。
また、SGW45は、TAU処理、Attach処理、もしくは任意のタイミングに行われたGUTI Reallocation処理において、MME42において管理されていたUEのGUTIもしくはGUTIに含まれるS-TMSIと、UEに関するeDRXパラメータとを通知され、通知された情報を管理している。そのため、SGW45は、PGW46との間において、UE40を含む複数のUEに関するセッション接続状態を維持している(S31)。また、SGW45は、ステップS31においてMME42に発生した障害を検出(S32)した後も、MME42において障害発生前まで管理されていたUEに関するセッション接続状態を維持している。SGW45は、MME42に対するヘルスチェック、もしくはMME42から受信しているRestart Counterを用いてMME42に発生した障害を検出してもよい。また、障害の検出は、これらの方法に制限されない。
UE40に関するセッション接続状態を維持するとは、例えば、SGW45は、図6もしくは図7においてMME42から通知されたUE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータと、UE40を識別するIMSIとを記憶し続けることであってもよい。さらに、UE40に関するセッション接続状態を維持するとは、SGW45とPGW46との間において、UE40に関するベアラを設定し続けることであってもよい。SGW45は、MME42に対するヘルスチェック、もしくはMME42から受信しているRestart Counterを用いてMME42に発生した障害が復旧した事を検出してもよい。(S34)また、障害の検出は、これらの方法に制限されない。
次に、PGW46は、Operator’s IP Services50等からUE40を宛先とするDownlink Dataを受信すると、SGW45へDownlink Dataを送信する(S35)。次に、SGW45は、UE40を宛先とするDownlink Dataを受信したことをMME42へ通知するために、MME42へDDNメッセージを送信する(S36)。SGW45が送信するDDNメッセージには、UE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータと、UE40を識別するIMSIとが含まれる。
次に、MME42は、S-TMSIとeDRXパラメータとを用いてUE40がPaging Channelを監視するタイミングを計算する(S37)。言い換えると、MME42は、S-TMSIとeDRXパラメータとを用いてUE40へページングを行うタイミングを計算する。
次に、MME42は、DDNメッセージに対する応答として、DDN Ack(Acknowledge)メッセージをSGW45へ送信する(S38)。次に、MME42は、S37の処理において、DDNメッセージ(S36)に含まれているGUTIが既に別のUEに配布されているか否かのチェックを行う。MME42は、DDNメッセージ(S36)に含まれているGUTIが、まだどのUEにも配布されていない事を確認した後、ステップS37において計算したUE40へページングを行うタイミングに間に合わせるように、eNB51へPagingメッセージを送信する(S39)。MME42が送信するPagingメッセージには、UE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータとが含まれる。また、Pagingメッセージ(S39)にIMSIが含まれても良い。一方、S37の処理において、DDNメッセージ(S36)に含まれているGUTIが既に別のUEに配布されている場合がおいては、MME42が送信するPagingメッセージ(S39)に、UE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータとに加えて、さらにUE40を識別するIMSIが含まれる。
次に、eNB51は、UE40に関するS-TMSI及びeDRXパラメータを用いて計算したページングタイミングに、UE40に対するページングを実行する(S40)。UE40は、UE40に割り当てられたGUTIを含む、自装置宛のPaging Channelを検出すると、Service Request Procedureを実行する(S41)。
以上説明したように、実施の形態2にかかる通信システムを用いることによって、SGW45は、UE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、eDRXパラメータとを取得することができる。また、MME42は、障害発生後に復旧した場合、UE40に関する情報を消失する。このような場合であっても、SGW45は、UE40に関するDonwlink Dataを受信した場合、MME42へUE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、eDRXパラメータとを送信することができる。
MME42及びeNB51は、SGW45から送信されたS-TMSI及びeDRXパラメータを用いることによって、UE40が監視しているPaging Channelの監視タイミングを計算することができる。その結果、MME42は、UE40に関する情報を消失した場合であっても、UE40に対するページングを正常に実行することができる。
また、図8においては、SGW45は、DDNメッセージを、障害から復旧した後のMME42へ送信しているが、MME42とは異なる他のMMEへ送信してもよい。これは、SGW45が、Down Link Data(S35)をMME42の障害復旧前(S34の前)に受信した場合などに起きえる。他のMMEとは、具体的にMME42を含むMME pool内の他のMMEであってもよい。MME poolとは、複数のMMEがeNBと接続されることでMMEの耐障害性を高める技術である。MME pool内の他のMMEは、MME42において管理されていたUEに関する情報を管理していない。他のMMEは、図8のMME42と同様に、SGW45から送信されたDDNメッセージを受信すると、UE40のS-TMSI及びeDRXパラメータを用いてUE40がPaging Channelを監視する周期を計算する。つまり、他のMMEは、図8のステップS37以降と同様の処理を実行する。ただし、この場合、他のMMEが送信するPagingメッセージには、UE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータとUE40を識別するIMSIとが含まれる。
(実施の形態3)
続いて、図9を用いて実施の形態3にかかるパケット着信処理の流れについて説明する。図9のステップS30~S40に示す処理の流れは、図8のステップS30~S40と同様であるため、図8と同様の符号を付して説明する。
図9のページング処理においては、図8のページング処理と比較して、ステップS39以降に送信されるメッセージに設定されるパラメータが異なる。
図9のステップS39において送信されるPagingメッセージには、図8のPagingメッセージにも含まれていた、UE40に割り当てられたGUTIもしくはGUTIに含まれるS-TMSIと、UE40に関するeDRXパラメータと、に加えて、新たにUE40を識別するIMSIが含まれる。
ここで、図10を用いて、Pagingメッセージに設定される情報要素(Information Element)について説明する。図10は、Pagingメッセージに設定される情報要素として、UE Paging Identity及びUE Paging Identity2とする、二つのUE Paging Identityが設定されていることを示している。例えば、UE Paging Identityに、UE40に関するS-TMSIが設定され、UE Paging Identity2に、UE40に関するIMSIが設定されてもよい。また、UE Paging Identity2との名称は、これに制限されず、他の名称が用いられてもよい。
図9に戻り、図9のステップS40において、eNB51は、UE40に関するS-TMSI及びeDRXパラメータを用いて計算したページングタイミングに、UE40に対するページングを実行する。ただし、図9のステップS40においては、eNB51は、UE40の識別情報としてIMSIを用いて、ページングを実行する。UE40は、UE40を示すIMSIを含む、自装置宛のPaging Channelを検出すると、Attach Procedureを実行する(S51)。また、図8において、DDNメッセージ(S36)に含まれているGUTIが既に別のUEに配布されている場合や、他のMMEがPagingメッセージ(S39)を実行する場合においても同様に、eNB51は、UE40に関するS-TMSI及びeDRXパラメータを用いて計算したページングタイミングにUE40の識別情報としてIMSIを用いて、ページングを実行する。
UE40の識別情報としてIMSIが用いられるページングは、通常、MMEが障害から復旧後に、MME42がUE40に関する情報を有さない状態において実行される。そのため、UE40は、UE40を示すIMSIを含むPaging Channelを検出すると、MME42へUE40に関する情報を登録させるために、Attach処理を実行する。
以下に、図8のページング処理と比較した、図9のページング処理の効果について説明する。図8においては、MME42が障害から復旧した後に、MME42が管理していたUE40に関する情報が消失した状態において、UE40の識別情報としてGUTIが用いられるページングが実行される。そのため、UE40は、MME42においてUE40に関する情報が管理されていることを前提として、Service Request Procedureを実行する。
しかし、MME42は、UE40に関する情報を消失しているため、Service Request処理を継続することができない。その結果、MME42は、Service Requestメッセージを送信してきたUE40に対して、Rejectメッセージを送信する。UE40は、Rejectメッセージを受信すると、Attach Procedureを行うことによって、MME42へUE40に関する情報を登録させる。
一方、図9のページング処理においては、UE40の識別情報として、IMSIが用いられている。図9のステップS39におけるPagingメッセージにも、GUTIもしくはS-TMSIが設定されているが、GUTIもしくはS-TMSIは、あくまでページングを実行するタイミングを計算するために用いられている。つまり、図9のステップS40において、UE40を識別するためにPaging Channelに設定される情報は、UE40のIMSIとなる。eNB51は、MME42から送信されたPagingメッセージに、GUTI及びIMSIが含まれている場合、IMSIを用いたページングを優先して実施してもよい。
UE40は、UE40を示すIMSIを含むPaging Channelを検出すると、Service Request Procedureを実行することなく、Attach Procedureを実行することができる。そのため、図9のページング処理は、Service Request Procedureが実行されないため、図8のページング処理と比較すると、Service Request Procedureに伴う処理負担が軽減されるという効果を生じる。
(実施の形態4)
続いて、図11を用いて、実施の形態4にかかるパケット着信処理の流れについて説明する。図11においては、図8のステップS31~S34の事象が発生しているとする。また、図11においては、MME42が障害から復旧した後に、SGW45が、一斉に、MME42が管理していたUEに対する大量のDownlink Dataを受信したとする(S61)。
SGW45が、一斉に大量のDownlink Dataを受信したことに伴い、MME42に対して一斉に大量のDDNメッセージを送信した場合、MME42における処理負荷が急激に上昇し、再度障害状態となることがある。このような状況を回避するために、SGW45は、一斉に大量のDownlink Dataを受信した場合であっても、徐々にゆっくりとMME42へDDNメッセージを送信する(S62~S64)。
例えば、SGW45は、所定期間内に所定数以上のDownlink Dataを新たに受信した場合、徐々にゆっくりとMME42へDDNメッセージを送信してもよい。SGW45が、徐々にゆっくりとMME42へDDNメッセージを送信するとは、MME42における処理負荷が急激に上昇しない程度に、DDNメッセージを送信する間隔を所定期間以上あけることであってもよい。例えば、SGW45は、所定期間内に所定数以上のDownlink Dataを新たに受信した場合に、予め定められたタイマを用いて、DDNメッセージを送信する間隔を決定してもよい。ここでは、SGW45が、一斉に大量のDownlink Dataを受信した場合の動作について説明したが、この動作は、SGW45が、MME42が障害から復旧した時点に、既にUEに対するDownlink Dataをバッファしている場合にも同様に適用する事ができる。この場合、図11のDownlink Data Notificationメッセージ(S62、S63、およびS64)は、Downlink Data(S61)を受信を契機とするのではなく、SGW45の自発的な動作になる。
今後、eDRX機能を有するIoTデバイスが飛躍的に増加し、MME42が管理するIoTデバイスが増加した場合に、障害から復旧したMME42が管理していたUEに対して、一斉にDownlink Dataが送信されることも考えられる。このような場合であっても、SGW45が、DDNメッセージを送信する間隔を制御することによって、MME42の処理負荷が急激に上昇することを回避することができる。
(実施の形態5)
続いて、実施の形態5にかかる、SGW45とPGW46との間におけるUEのセッション接続状態を維持する期間について説明する。UE40は、在圏するTAが変更しない場合であっても、定期的にTAU処理を実行する。定期的に実行するTAU処理は、周期位置登録もしくはperiodic TAUと称されてもよい。UE40が周期位置登録を実行する間隔は、3GPPにおいて規定されているT3412タイマに基づいて決定される。例えば、UE40が周期位置登録を実行する最大間隔は、T3412タイマに基づいて最大約186分と定められている。
また、UE40のバッテリー消費抑止、及びネットワークの負荷低減を目的として、周期位置登録を実行する間隔をより長くすることを目的として、3GPPにおいて、T3412 extended valueが規定されている。UE40が周期位置登録を実行する最大間隔は、T3412 extended valueに基づくと、最大約413日に拡張される。T3412 extended valueに基づく周期位置登録は、主にIoTデバイスに適用されることが検討されている。
実施の形態5においては、SGW45は、図8及び図9のステップS32における、UEのセッション接続状態を維持する期間を、T3412タイマもしくはT3412 extended valueに基づいて決定する。
具体的には、図6のTAU処理もしくはAttach処理において、MME42は、UE40へ周期位置登録の周期を通知するために、TAU AcceptメッセージもしくはAttach AcceptメッセージにT3412タイマもしくはT3412 extended valueを設定する。さらに、MME42は、Modify Bearer Requestメッセージ、あるいはCreate Session Requestメッセージに、TAU AcceptメッセージもしくはAttach Acceptメッセージにおいて設定したT3412タイマもしくはT3412 extended valueを設定する。
SGW45は、T3412タイマが設定されたModify Bearer Requestメッセージ、あるいはCreate Session Requestメッセージを受信した場合、例えば、図8及び図9のステップS33においてMME42の障害を検出後、T3412タイマに基づいて定められる周期位置登録の間隔と同じ期間、UEのセッション接続状態を維持する。また、SGW45は、T3412 extended valueが設定されたModify Bearer Requestメッセージ、あるいはCreate Session Requestメッセージを受信した場合、例えば、図8及び図9のステップS33においてMME42の障害を検出後、T3412 extended valueに基づいて定められる周期位置登録の間隔と同じ期間、UEのセッション接続状態を維持する。このようにUEのセッション接続状態を維持する期間を定めることによって次の効果が得られる。
SGW45は、T3412タイマもしくはT3412 extended valueが設定されたModify Bearer Requestメッセージを受信しない場合、UE40の周期位置登録の間隔を認識することができない。そのため、例えば、SGW45は、一律T3412タイマに基づいて定められる周期位置登録の間隔と同じ期間、UEのセッション接続状態を維持すると決定することが考えられる。しかし、この場合、UE40の周期位置登録の間隔が、T3412 extended valueに基づいて定められている場合、SGW45は、UE40のセッション接続状態が解放された後に受信したDownlink Dataに関するDDNメッセージをMME42へ送信することができなくなる。なぜなら、SGW45は、UE40のセッション接続状態が解放された場合、UE40に関するGUTI及びIMSI等も消失するため、DDNメッセージに、UE40の識別情報を設定することができなくなるからである。
また、SGW45が、一律T3412 extended valueに基づいて定められる周期位置登録の間隔と同じ期間、UEのセッション接続状態を維持すると決定することも考えられる。ここで、UE40の故障、もしくは電波が届かない場所での電源がON状態からOFF状態へ遷移した等の理由により、UE40が電源OFFへの状態遷移すらeNBへ通知できずに通信できない状態であるとする。このような場合に、SGW45が、T3412タイマに基づいて定められる周期位置登録の間隔と同じ期間、UEのセッション接続状態を維持する場合、最大約186分後にはUE40のセッション接続状態を解消することができる。しかし、SGW45が一律T3412 extended valueに基づいて定められる周期位置登録の間隔と同じ期間、UEのセッション接続状態を維持する場合、最大413日もの間、通信することができないUE40のセッション接続状態を維持する必要がある。
このように、SGW45が、UE40の周期位置登録の間隔が、T3412タイマ及びT3412 extended valueのどちらに基づいて定められていることを認識せずに、UEのセッション接続状態を維持することを決定すると上記の問題が発生する。
一方、実施の形態5においては、SGW45が、T3412タイマもしくはT3412 extended valueのいずれかが設定されたModify Bearer Requestメッセージ、あるいはCreate Session Requestメッセージを受信することができる。そのため、SGW45は、UE40の周期位置登録の間隔が、T3412タイマ及びT3412 extended valueのどちらに基づいて定められているかを認識することができる。これより、SGW45は、UE毎に、セッション接続状態を維持する期間を決定することができるため、セッション接続状態を解消することによりDDNメッセージをMME42へ送信することができなくなることも、通信することができないUEに関するセッション接続状態を長期間維持することも回避することができる。
続いて以下では、上述の複数の実施形態で説明された、eNB51、UE40、MME42及びSGW45の構成例について説明する。図12は、eNB51の構成例を示すブロック図である。図12を参照すると、eNB51は、RFトランシーバ1001、ネットワークインターフェース1003、プロセッサ1004、及びメモリ1005を含む。RFトランシーバ1001は、UEsと通信するためにアナログRF信号処理を行う。RFトランシーバ1001は、複数のトランシーバを含んでもよい。RFトランシーバ1001は、アンテナ1002及びプロセッサ1004と結合される。RFトランシーバ1001は、変調シンボルデータ(又はOFDMシンボルデータ)をプロセッサ1004から受信し、送信RF信号を生成し、送信RF信号をアンテナ1002に供給する。また、RFトランシーバ1001は、アンテナ1002によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ1004に供給する。
ネットワークインターフェース1003は、ネットワークノード(e.g., 他のコアネットワークノード)と通信するために使用される。ネットワークインターフェース1003は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード(NIC)を含んでもよい。
プロセッサ1004は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ1004によるデジタルベースバンド信号処理は、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。
プロセッサ1004は、複数のプロセッサを含んでもよい。例えば、プロセッサ1004は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。
メモリ1005は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1005は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ1005は、プロセッサ1004から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1004は、ネットワークインターフェース1003又は図示されていないI/Oインタフェースを介してメモリ1005にアクセスしてもよい。
メモリ1005は、上述の複数の実施形態で説明されたeNB51による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、プロセッサ1004は、当該ソフトウェアモジュールをメモリ1005から読み出して実行することで、上述の実施形態で説明されたeNB51の処理を行うよう構成されてもよい。
図13は、UE40の構成例を示すブロック図である。Radio Frequency(RF)トランシーバ1101は、eNB51と通信するためにアナログRF信号処理を行う。RFトランシーバ1101により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ1101は、アンテナ1102及びベースバンドプロセッサ1103と結合される。すなわち、RFトランシーバ1101は、変調シンボルデータ(又はOFDMシンボルデータ)をベースバンドプロセッサ1103から受信し、送信RF信号を生成し、送信RF信号をアンテナ1102に供給する。また、RFトランシーバ1101は、アンテナ1102によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ1103に供給する。
ベースバンドプロセッサ1103は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮/復元、(b) データのセグメンテーション/コンカテネーション、(c) 伝送フォーマット(伝送フレーム)の生成/分解、(d) 伝送路符号化/復号化、(e) 変調(シンボルマッピング)/復調、及び(f) Inverse Fast Fourier Transform(IFFT)によるOFDMシンボルデータ(ベースバンドOFDM信号)の生成などを含む。一方、コントロールプレーン処理は、レイヤ1(e.g., 送信電力制御)、レイヤ2(e.g., 無線リソース管理、及びhybrid automatic repeat request(HARQ)処理)、及びレイヤ3(e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング)の通信管理を含む。
例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ1103によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol(PDCP)レイヤ、Radio Link Control(RLC)レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ1103によるコントロールプレーン処理は、Non-Access Stratum(NAS)プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
ベースバンドプロセッサ1103は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., Digital Signal Processor(DSP))とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., Central Processing Unit(CPU)、又はMicro Processing Unit(MPU))を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ1104と共通化されてもよい。
アプリケーションプロセッサ1104は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ1104は、複数のプロセッサ(複数のプロセッサコア)を含んでもよい。アプリケーションプロセッサ1104は、メモリ1106又は図示されていないメモリから読み出されたシステムソフトウェアプログラム(Operating System(OS))及び様々なアプリケーションプログラム(例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション)を実行することによって、UE40の各種機能を実現する。
いくつかの実装において、図13に破線(1105)で示されているように、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのSystem on Chip(SoC)デバイス1105として実装されてもよい。SoCデバイスは、システムLarge Scale Integration(LSI)またはチップセットと呼ばれることもある。
メモリ1106は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ1106は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ1106は、ベースバンドプロセッサ1103、アプリケーションプロセッサ1104、及びSoC1105からアクセス可能な外部メモリデバイスを含んでもよい。メモリ1106は、ベースバンドプロセッサ1103内、アプリケーションプロセッサ1104内、又はSoC1105内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ1106は、Universal Integrated Circuit Card(UICC)内のメモリを含んでもよい。
メモリ1106は、上述の複数の実施形態で説明されたUE80による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、ベースバンドプロセッサ1103又はアプリケーションプロセッサ1104は、当該ソフトウェアモジュールをメモリ1106から読み出して実行することで、上述の実施形態で説明されたUE40の処理を行うよう構成されてもよい。
図14は、MME42及びSGW45の構成例を示すブロック図である。図14を参照すると、MME42及びSGW45は、ネットワークインターフェース1201、プロセッサ1202、及びメモリ1203を含む。ネットワークインターフェース1201は、ネットワークノード(e.g., SGSN44、HSS43、PGW46等)と通信するために使用される。ネットワークインターフェース1201は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード(NIC)を含んでもよい。
プロセッサ1202は、メモリ1203からソフトウェア(コンピュータプログラム)を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたセンターノード20の処理を行う。プロセッサ1202は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ1202は、複数のプロセッサを含んでもよい。
プロセッサ1202は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ1004によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、およびMACレイヤの信号処理を含んでもよい。さらに、プロセッサ1202による信号処理は、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を含んでもよい。また、プロセッサ1004によるコントロールプレーン処理は、X2APプロトコル、S1-MMEプロトコルおよびRRCプロトコルの処理を含んでもよい。
プロセッサ1202は、複数のプロセッサを含んでもよい。例えば、プロセッサ1004は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を行うプロセッサ(e.g., DSP)、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。
メモリ1203は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1203は、プロセッサ1202から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1202は、図示されていないI/Oインタフェースを介してメモリ1203にアクセスしてもよい。
図14の例では、メモリ1203は、ソフトウェアモジュール群を格納するために使用される。プロセッサ1202は、これらのソフトウェアモジュール群をメモリ1203から読み出して実行することで、上述の実施形態において説明されたMECサーバ40の処理を行うことができる。
図12~図14を用いて説明したように、上述の実施形態におけるeNB51、UE40、MME42及びSGW45が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD-ROM(Read Only Memory)、CD-R、CD-R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
なお、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。また、上記実施の形態において説明したMMEの代わりにSGSNが用いられ、eNBの代わりにRNCが用いられてもよい。この場合、TAUは、RAU(Routing Area Update)に置き換えられ、GUTI、S-TMSI、及びM-TMSIは、P(Packet)-TMSIに置き換えられる。また、上記実施の形態において説明したMMEの代わりにMMF(Mobility Management Function)が用いられ、SGWの代わりにUPF(U-Plane Function)が用いられ、eNBの代わりにNRが用いられてもよい。