【文献】
Nokia, Alcatel-Lucent Shanghai Bell,23.501: Corrections in the AMF procedures for Non-3GPP,3GPP TSG SA WG2#120 S2-172408,フランス,3GPP,2017年 4月 3日,Section 2
【文献】
Huawei, HiSilicon,TS 23.502: Replacing information flows by UDM service presentation,3GPP TSG SA WG2#120 S2-172286,フランス,3GPP,2017年 3月21日,Section 4.2.2.2.2
【文献】
LG Electronics, ETRI, HTC,TS 23.502: De-registration procedure,3GPP TSG SA WG2#120 S2-171851,フランス,3GPP,2017年 3月21日,Section 4.2.2.3.4
【文献】
China Mobile,23.502: Describe NF services provided by UDM,3GPP TSG SA WG2#120 S2-171819,フランス,3GPP,2017年 3月21日,Section 1
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0020】
以下の実施例は本発明の構成要素と特徴を所定の形態で結合したものである。各構成要素又は特徴は、別の明示的な言及がない限り、選択的なものとして考慮することができる。各構成要素又は特徴は他の構成要素や特徴と結合しない形態で実施されてもよく、一部の構成要素及び/又は特徴を結合して本発明の実施例を構成してもよい。本発明の実施例において説明される動作の順序は変更されてもよい。ある実施例の一部の構成や特徴は別の実施例に含まれてもよく、別の実施例の対応する構成又は特徴に取り替わってもよい。
【0021】
以下の説明で使われる特定用語は、本発明の理解を助けるために提供されたもので、これらの特定用語の使用は、本発明の技術的思想から逸脱することなく他の形態に変更されてもよい。
【0022】
場合によっては、本発明の概念が曖昧になることを避けるために、公知の構造及び装置は省略されたり、各構造及び装置の核心機能を中心にしたブロック図の形式で示されてもよい。また、本明細書全体を通じて同一の構成要素には同一の図面符号を付して説明する。
【0023】
本発明の実施例はIEEE(Institute of Electrical and Electronics Engineers)802系システム、3GPPシステム、3GPP LTE及びLTE−Aシステム及び3GPP2システムのうち少なくとも一つに関して開示された標準文書によって裏付けられることができる。即ち、本発明の実施例において本発明の技術的思想を明確に示すために説明しなかった段階又は部分は前記文書によって裏付けられることができる。また、本文書で開示している全ての用語は前記標準文書によって説明可能である。
【0024】
以下の技術は多様な無線通信システムで使用可能である。明確性のために、以下では3GPP LTE及び3GPP LTE−Aシステムを主として説明するが、本発明の技術的思想がこれに制限されるものではない。
【0025】
本文書で使われる用語は次のように定義される。
【0026】
−UMTS(Universal Mobile Telecommunications System):3GPPによって開発された、GSM(Global System for Mobile Communication)ベースの3世代(Generation)移動通信技術。
【0027】
−EPS(Evolved Packet System):IP(Internet Protocol)ベースのPS(packet switched)コア(core)ネットワークであるEPC(Evolved Packet Core)とLTE/UTRANなどのアクセスネットワークとで構成されたネットワークシステム。UMTSが進化した形態のネットワークである。
【0028】
−NodeB:GERAN/UTRANの基地局。屋外に設置し、カバレッジはマクロセル(macro cell)規模である。
【0029】
−eNodeB:E−UTRANの基地局。屋外に設置し、カバレッジはマクロセル(macro cell)規模である。
【0030】
−UE(User Equipment):ユーザ機器。UEは、端末(terminal)、ME(Mobile Equipment)、MS(Mobile Station)などと呼ぶこともできる。また、UEは、ノートパソコン、携帯電話、PDA(Personal Digital Assistant)、スマートフォン、マルチメディア機器などのように携帯可能な機器であってもよく、PC(Personal Computer)、車両搭載装置のように携帯不可能な機器であってもよい。MTC関連内容においてUE又は端末という用語は、MTCデバイスを指すことができる。
【0031】
−HNB(Home NodeB):UMTSネットワークの基地局であり、屋内に設置し、カバレッジはマイクロセル(micro cell)規模である。
【0032】
−HeNB(Home eNodeB):EPSネットワークの基地局であり、屋内に設置し、カバレッジはマイクロセル規模である。
【0033】
−MME(Mobility Management Entity):移動性管理(Mobility Management;MM)、セッション管理(Session Management;SM)機能を有するEPSネットワークのネットワークノード。
【0034】
−PDN−GW(Packet Data Network−Gateway)/PGW/P−GW:UE IPアドレス割り当て、パケットスクリーニング(screening)及びフィルタリング、課金データ集合(charging data collection)機能などを有するEPSネットワークのネットワークノード。
【0035】
−SGW(Serving Gateway):移動性アンカー(mobility anchor)、パケットルーティング(routing)、遊休(idle)モードパケットバッファリング、MMEがUEをページングするようにトリガーする機能などを有するEPSネットワークのネットワークノード。
【0036】
−NAS(Non−Access Stratum):UEとMME間の制御プレーン(control plane)の上位端(stratum)。LTE/UMTSプロトコルスタックにおいてUEとコアネットワーク間のシグナリング、トラフィックメッセージを取り交わすための機能的な階層であって、UEの移動性を支援し、UEとPDN GW間のIP連結を確立(establish)及び維持するセッション管理過程を支援することを主な機能とする。
【0037】
−PDN(Packet Data Network):特定のサービスを支援するサーバー(例えば、MMS(Multimedia Messaging Service)サーバー、WAP(Wireless Application Protocol)サーバーなど)が位置しているネットワーク。
【0038】
−PDN連結:一つのIP住所(一つのIPv4住所及び/又は一つのIPv6プレフィックス)で表現される、UEとPDN間の論理的連結。
【0039】
−RAN(Radio Access Network):3GPPネットワークでNodeB、eNodeB及びこれらを制御するRNC(Radio Network Controller)を含む単位。UE間に存在し、コアネットワークへの連結を提供する。
【0040】
−HLR(Home Location Register)/HSS(Home Subscriber Server):3GPPネットワーク内の加入者情報を持っているデータベース。HSSは設定保存(configuration storage)、アイデンティティ管理(identity management)、使用者状態保存などの機能を行うことができる。
【0041】
−PLMN(Public Land Mobile Network):個人に移動通信サービスを提供する目的で構成されたネットワーク。オペレータ別に区分されて構成できる。
【0042】
−Proximity Service(又はProSe Service又はProximity based Service):物理的に近接した装置間のディスカバリー及び互いに直接的なコミュニケーション又は基地局を介してのコミュニケーション又は第3の装置を介してのコミュニケーションが可能なサービス。この際、使用者平面データ(user plane data)は3GPPコアネットワーク(例えば、EPC)を介せずに直接データ経路(direct data path)を介して交換される。
【0043】
EPC(Evolved Packet Core)
【0044】
図1はEPC(Evolved Packet Core)を含むEPS(Evolved Packet System)の概略的な構造を示す図である。
【0045】
EPCは3GPP技術の性能を向上するためのSAE(System Architecture Evolution)の核心的な要素である。SAEは多様な種類のネットワーク間の移動性を支援するネットワーク構造を決定する研究課題に相当する。SAEは、例えばIPに基づいて多様な無線接続技術を支援し、より向上したデータ伝送能力を提供するなどの最適化したパケットに基づくシステムを提供することを目標とする。
【0046】
具体的に、EPCは3GPP LTEシステムのためのIP移動通信システムのコアネットワーク(Core Network)であり、パケットに基づく実時間及び非実時間サービスを支援することができる。既存の移動通信システム(即ち、2世代又は3世代移動通信システム)では音声のためのCS(Circuit−Switched)及びデータのためのPS(Packet−Switched)の二つの区別されるサブドメインによってコアネットワークの機能が具現された。しかし、3世代移動通信システムの進化である3GPP LTEシステムでは、CS及びPSのサブドメインが一つのIPドメインに単一化した。即ち、3GPP LTEシステムでは、IP能力(capability)を有する端末と端末間の連結が、IPに基づく基地局(例えば、eNodeB(evolved NodeB))、EPC、アプリケーションドメイン(例えば、IMS(IP Multimedia Subsystem))で構成されることができる。即ち、EPCは端対端(end−to−end)IPサービス具現に必須な構造である。
【0047】
EPCは多様な構成要素を含むことができ、
図1は、その一部に相当する、SGW(Serving Gateway)、PDN GW(Packet Data Network Gateway)、MME(Mobility Management Entity)、SGSN(Serving GPRS(General Packet Radio Service)Supporting Node)、ePDG(enhanced Packet Data Gateway)を示す。
【0048】
SGW(又はS−GW)は無線接続ネットワーク(RAN)とコアネットワーク間の境界点として動作し、eNodeBとPDN GW間のデータ経路を維持する機能を行う要素である。また、端末がeNodeBによってサービング(serving)される領域にわたって移動する場合、SGWはローカル移動性アンカーポイント(anchor point)の役目をする。即ち、E−UTRAN(3GPPリリース8以後に定義されるEvolved−UMTS(Universal Mobile Telecommunications System)Terrestrial Radio Access Network)内での移動性のためにSGWを介してパケットがルーティングされることができる。また、SGWは他の3GPPネットワーク(3GPPリリース8以前に定義されるRAN、例えばUTRAN又はGERAN(GSM(Global System for Mobile Communication)/EDGE(Enhanced Data rates for Global Evolution)Radio Access Network)との移動性のためのアンカーポイントとして機能することもできる。
【0049】
PDN GW(又はP−GW)はパケットデータネットワークに向かうデータインターフェースの終了点(termination point)に相当する。PDN GWは政策執行特徴(policy enforcement features)、パケットフィルタリング(packet filtering)、課金支援(charging support)などを支援することができる。また、3GPPネットワークと非3GPPネットワーク(例えば、I−WLAN(Interworking Wireless Local Area Network)のような信頼できないネットワーク、CDMA(Code division multiple access)ネットワーク又はWiMaxのような信頼できるネットワーク)との移動性管理のためのアンカーポイントの役目をすることができる。
【0050】
図1のネットワーク構造の例示ではSGWとPDN GWが別個のゲートウェイで構成されるものを示すが、2つのゲートウェイが単一ゲートウェイ構成オプション(Single Gateway Configuration Option)によって具現されることもできる。
【0051】
MMEは、UEのネットワーク連結に対するアクセス、ネットワークリソースの割当て、トラッキング(tracking)、ページング(paging)、ローミング(roaming)及びハンドオーバーなどを支援するためのシグナリング及び制御機能を行う要素である。MMEは加入者及びセッション管理に係わる制御平面(control plane)の機能を制御する。MMEは幾多のeNodeBを管理し、他の2G/3Gネットワークに対するハンドオーバーのための従来のゲートウェイの選択のためのシグナリングを行う。また、MMEは保安過程(Security Procedures)、端末対ネットワークセッションハンドリング(Terminal−to−network Session Handling)、遊休端末位置決定管理(Idle Terminal Location Management)などの機能を行う。
【0052】
SGSNは他の3GPPネットワーク(例えば、GPRSネットワーク)に対する使用者の移動性管理及び認証(authentication)のような全てのパケットデータをハンドリングする。
【0053】
ePDGは信頼できない非3GPPネットワーク(例えば、I−WLAN、WiFiホットスポット(hotspot)など)に対する保安ノードとしての役目をする。
【0054】
図1を参照して説明したように、IP能力を有する端末は、3GPPアクセスはもちろんのこと、非3GPPアクセスに基づいてもEPC内の多様な要素を介して事業者(即ち、オペレータ(operator))が提供するIPサービスネットワーク(例えば、IMS)にアクセスすることができる。
【0055】
また、
図1では多様なレファレンスポイント(例えば、S1−U、S1−MMEなど)を示す。3GPPシステムでは、E−UTRAN及びEPCの相異なる機能個体(functional entity)に存在する二つの機能を連結する概念的なリンクをレファレンスポイント(reference point)と定義する。次の表1は
図1に示したレファレンスポイントをまとめたものである。表1の例示の外にもネットワーク構造によって多様なレファレンスポイントが存在することができる。
【0058】
図1に示したレファレンスポイントのうちS2a及びS2bは非3GPPインターフェースに相当する。S2aは信頼できる非3GPPアクセス及びPDN GW間の関連制御及び移動性支援を使用者平面に提供するレファレンスポイントである。S2bはePDG及びPDN GW間の関連制御及び移動性支援を使用者平面に提供するレファレンスポイントである。
【0059】
図2は一般的なE−UTRANとEPCのアーキテクチャーを示した例示図である。
【0060】
図示のように、eNodeBはRRC(Radio Resource Control)連結が活性化しているうちにゲートウェイへのルーティング、ページングメッセージのスケジューリング及び伝送、ブロードキャストチャネル(BCH)のスケジューリング及び伝送、上りリンク及び下りリンクでのリソースのUEへの動的割当て、eNodeBの測定のための設定及び提供、無線ベアラー制御、無線許可制御(radio admission control)、及び連結移動性制御などのための機能を行うことができる。EPC内ではページング発生、LTE_IDLE状態管理、使用者平面の暗号化、SAEベアラー制御、NASシグナリングの暗号化及び無欠性保護機能を行うことができる。
【0061】
図3は端末と基地局間の制御平面での無線インターフェースプロトコル(Radio Interface Protocol)の構造を示した例示図、
図4は端末と基地局間の使用者平面での無線インターフェースプロトコルの構造を示した例示図である。
【0062】
無線インターフェースプロトコルは3GPP無線接続網規格を基盤とする。無線インターフェースプロトコルは水平的に物理階層(Physical Layer)、データリンク階層(Data Link Layer)及びネットワーク階層(Network Layer)からなり、垂直的にはデータ情報伝送のための使用者平面(User Plane)と制御信号(Signaling)伝達のための制御平面(Control plane)に区分される。
【0063】
プロトコル階層は通信システムで広く知られた開放型システム間の相互接続(Open System Interconnection;OSI)基準モデルの下位3個階層を基にしてL1(第1階層)、L2(第2階層)、L3(第3階層)に区分されることができる。
【0064】
以下で、
図3に示した制御平面の無線プロトコルと、
図4に示した使用者平面での無線プロトコルの各階層を説明する。
【0065】
第1階層である物理階層は物理チャネル(Physical Channel)を用いて情報伝送サービス(Information Transfer Service)を提供する。物理階層は上位の媒体接続制御(Medium Access Control)階層とは伝送チャネル(Transport Channel)を介して連結されており、伝送チャネルを介して媒体接続制御階層と物理階層間のデータが伝達される。そして、相異なる物理階層の間、つまり送信側と受信側の物理階層の間は物理チャネルを介してデータが伝達される。
【0066】
物理チャネル(Physical Channel)は時間軸上の複数のサブフレームと周波数軸上の複数のサブキャリア(Sub−carrier)で構成される。ここで、一つのサブフレーム(Sub−frame)は時間軸上の複数のシンボル(Symbol)と複数のサブキャリアで構成される。一つのサブフレームは複数のリソースブロック(Resource Block)で構成され、一つのリソースブロックは複数のシンボル(Symbol)と複数のサブキャリアで構成される。データが伝送される単位時間であるTTI(Transmission Time Interval)は一つのサブフレームに相当する1msである。
【0067】
送信側と受信側の物理階層に存在する物理チャネルは、3GPP LTEによれば、データチャネルであるPDSCH(Physical Downlink Shared Channel)及びPUSCH(Physical Uplink Shared Channel)、及び制御チャネルであるPDCCH(Physical Downlink Control Channel)、PCFICH(Physical Control Format Indicator Channel)、PHICH(Physical Hybrid−ARQ Indicator Channel)及びPUCCH(Physical Uplink Control Channel)に区分することができる。
【0069】
まず、第2階層の媒体接続制御(Medium Access Control;MAC)階層は多様な論理チャネル(Logical Channel)を多様な伝送チャネルにマッピングする役目をし、また多様な論理チャネルを一つの伝送チャネルにマッピングする論理チャネル多重化(Multiplexing)の役目を行う。MAC階層は上位階層であるRLC階層とは論理チャネル(Logical Channel)で連結されており、論理チャネルは、大別して、伝送される情報の種類によって制御平面(Control plane)の情報を送信する制御チャネル(Control Channel)と使用者平面(User Plane)の情報を送信するトラフィックチャネル(Traffic Channel)に区分される。
【0070】
第2階層の無線リンク制御(Radio Link Control;RLC)階層は上位階層から受信したデータを分割(Segmentation)及び連結(Concatenation)して、下位階層が無線区間にデータを送信するのに適するようにデータの大きさを調節する役目を行う。
【0071】
第2階層のパケットデータ収斂プロトコル(Packet Data Convergence Protocol;PDCP)階層はIPv4又はIPv6のようなIPパケットの伝送時に帯域幅の小さな無線区間で効率的に送信するために、相対的に大きくて不必要な制御情報を含んでいるIPパケットヘッダーのサイズを減らすヘッダー圧縮(Header Compression)の機能を行う。また、LTEシステムではPDCP階層が保安(Security)機能も行う。これは第3者のデータ傍受を防止する暗号化(Ciphering)と第3者のデータ操作を防止する無欠性保護(Integrity protection)で構成される。
【0072】
第3階層の最上部に位置する無線リソース制御(Radio Resource Control;以下RRCと略称する)階層は制御平面でのみ定義され、無線運搬子(Radio Bearer;RBと略称する)の設定(Configuration)、再設定(Re−configuration)及び解除(Release)に関連して論理チャネル、伝送チャネル及び物理チャネルの制御を担う。この際、RBは端末とE−UTRAN間のデータ伝達のために第2階層によって提供されるサービスを意味する。
【0073】
端末のRRCと無線網のRRC階層の間にRRC連結(RRC connection)がある場合、端末はRRC連結状態(Connected Mode)にあるようになり、そうでない場合はRRC遊休モード(Idle mode)にあるようになる。
【0074】
以下で端末のRRC状態(RRC state)とRRC連結方法について説明する。RRC状態とは端末のRRCがE−UTRANのRRCとの論理的連結(logical connection)をなしているか否かを言い、連結されている場合はRRC_CONNECTED状態(state)、連結されていない場合はRRC_IDLE状態と言う。RRC_CONNECTED状態の端末はRRC連結が存在するから、E−UTRANは該当端末の存在をセル単位で把握することができ、よって端末を効果的に制御することができる。一方、RRC_IDLE状態の端末はE−UTRANが端末の存在を把握することはできなく、セルより大きな地域単位であるTA(Tracking Area)単位で核心網が管理する。即ち、RRC_IDLE状態の端末はセルに比べて大きな地域単位で該当端末の存在有無のみ把握され、音声又はデータのような通常の移動通信サービスを受けるためには、該当端末がRRC_CONNECTED状態に遷移しなければならない。各TAはTAI(Tracking area identity)によって区分される。端末はセルで放送(broadcasting)される情報であるTAC(Tracking area code)によってTAIを構成することができる。
【0075】
使用者が端末の電源を最初に入れたとき、端末は先に適切なセルを探索した後、該当セルでRRC連結をなし、核心網に端末の情報を登録する。その後、端末はRRC_IDLE状態に留まる。RRC_IDLE状態に留まる端末は必要によってセルを(再)選択し、システム情報(System information)又はページング情報を調べる。これをセルにキャンプオン(Camp on)すると言う。RRC_IDLE状態に留まっていた端末はRRC連結をなす必要があるときに初めてRRC連結過程(RRC connection procedure)によってE−UTRANのRRCとRRC連結をなし、RRC_CONNECTED状態に遷移する。RRC_IDLE状態にあった端末がRRC連結をなす必要がある場合は色々がある。例えば、使用者の通話試み、データ伝送試み、又はE−UTRANからページングメッセージを受信した後、これに対する応答メッセージ伝送などを挙げることができる。
【0076】
RRC階層上に位置するNAS(Non−Access Stratum)階層は連結管理(Session Management)と移動性管理(Mobility Management)などの機能を行う。
【0077】
以下、
図3に示したNAS階層について詳しく説明する。
【0078】
NAS階層に属するeSM(evolved Session Management)はデフォルトベアラー(Default Bearer)管理、専用ベアラー(Dedicated Bearer)管理のような機能を行い、端末が網からPSサービスを用いるための制御を担う。デフォルトベアラーリソースは特定のパケットデータネットワーク(Packet Data Network;PDN)に最初に接続するとき、網から割り当てられるという特徴を有する。この際、ネットワークは、端末がデータサービスを使えるように端末が使用可能なIP住所を割り当て、そしてデフォルトベアラーのQoSを割り当てる。LTEでは、大別して、データ送受信のための特定の帯域幅を保障するGBR(Guaranteed bit rate)QoS特性を有するベアラーと帯域幅の保障なしにBest effort QoS特性を有するNon−GBRベアラーの2種を支援する。デフォルトベアラーの場合、Non−GBRベアラーが割り当てられる。専用ベアラーの場合にはGBR又はNon−GBRのQoS特性を有するベアラーが割り当てられることができる。
【0079】
ネットワークで端末に割り当てたベアラーをEPS(evolved packet service)ベアラーと言い、EPSベアラーを割り当てるとき、ネットワークは一つのIDを割り当てるようになる。これをEPSベアラーIDと言う。一つのEPSベアラーはMBR(maximum bit rate)又は/及びGBR(Guaranteed bit rate)のQoS特性を有する。
【0080】
図5は3GPP LTEでのランダムアクセス過程を示したフローチャートである。
【0081】
ランダムアクセス過程はUEが基地局に対するUL同期を得るかUL無線リソースを割り当てられるために用いられる。
【0082】
UEはルートインデックス(root index)とPRACH(physical random access channel)設定インデックス(configuration index)をeNodeBから受信する。各セルごとにZC(Zadoff−Chu)シーケンスによって定義される64個の候補(candidate)ランダムアクセスプリアンブルがあり、ルートインデックスは端末が64個の候補ランダムアクセスプリアンブルを生成するための論理的インデックスである。
【0083】
ランダムアクセスプリアンブルの伝送は各セルごとに特定の時間及び周波数リソースに限定される。PRACH設定インデックスはランダムアクセスプリアンブルの伝送が可能な特定のサブフレームとプリアンブルフォーマットを指示する。
【0084】
UEは任意に選択されたランダムアクセスプリアンブルをeNodeBに送信する。UEは64個の候補ランダムアクセスプリアンブルの一つを選択する。そして、PRACH設定インデックスによって該当のサブフレームを選択する。UEは選択されたランダムアクセスプリアンブルを選択されたサブフレームに送信する。
【0085】
ランダムアクセスプリアンブルを受信したeNodeBはランダムアクセス応答(random access response、RAR)をUEに送る。ランダムアクセス応答は2段階で検出される。まず、UEはRA−RNTI(random access−RNTI)でマスキングされたPDCCHを検出する。UEは検出されたPDCCHによって指示されるPDSCH上でMAC(Medium Access Control)PDU(Protocol Data Unit)内のランダムアクセス応答を受信する。
【0086】
図6は無線リソース制御(RRC)階層での連結過程を示す。
【0087】
図6に示したように、RRC連結可否によってRRC状態が示されている。RRC状態とはUEのRRC階層のエンティティ(entity)がeNodeBのRRC階層のエンティティと論理的連結(logical connection)をなしているか否かを言い、連結されている場合はRRC連結状態(connected state)と言い、連結されていない状態をRRC遊休モードと言う。
【0088】
連結状態(Connected state)のUEはRRC連結(connection)が存在するから、E−UTRANは該当端末の存在をセル単位で把握することができ、よってUEを効果的に制御することができる。一方、遊休モードのUEはeNodeBが把握することはできなく、セルより大きな地域単位であるトラッキング地域(Tracking Area)単位で核心網(Core Network)が管理する。トラッキング地域(Tracking Area)はセルの集合単位である。即ち、遊休モードUEは大きな地域単位で存在有無のみ把握され、音声やデータのような通常の移動通信サービスを受けるためには、端末は連結状態(connected state)に遷移しなければならない。
【0089】
使用者がUEの電源を最初に入れたとき、UEは先に適切なセルを探索した後、該当セルで遊休モードで留まる。遊休モードで留まっていたUEはRRC連結をなす必要があるときに初めてRRC連結過程(RRC connection procedure)によってeNodeBのRRC階層とのRRC連結をなし、RRC連結状態(connected state)に遷移する。
【0090】
遊休モードにあったUEがRRC連結をなす必要がある場合はいろいろがある。例えば、使用者の通話試み、データ伝送、又はEUTRANからページングメッセージを受信した後、これに対する応答メッセージの伝送を挙げることができる。
【0091】
遊休モードのUEがeNodeBとRRC連結をなすためには、前述したようにRRC連結過程(RRC connection procedure)を進行しなければならない。RRC連結過程は、大別して、UEがeNodeBにRRC連結要求(RRC connection request)メッセージを送信する過程、eNodeBがUEにRRC連結設定(RRC connection setup)メッセージを送信する過程、及びUEがeNodeBにRRC連結設定完了(RRC connection setup complete)メッセージを送信する過程を含む。このような過程について
図6を参照してより詳細に説明すると次のようである。
【0092】
1)遊休モード(Idle state)のUEは、通話試み、データ伝送試み、又はeNodeBのページングに対する応答などの理由でRRC連結をなそうとする場合、まずRRC連結要求(RRC connection request)メッセージをeNodeBに送信する。
【0093】
2)UEからRRC連結要求メッセージを受信すれば、eNBは、無線リソースが十分な場合、UEのRRC連結要求を受諾し、応答メッセージであるRRC連結設定(RRC connection setup)メッセージをUEに送信する。
【0094】
3)UEがRRC連結設定メッセージを受信すれば、eNodeBにRRC連結設定完了(RRC connection setup complete)メッセージを送信する。UEがRRC連結設定メッセージを成功的に送信すれば、初めてUEはeNodeBとmpRRC連結をなし、RRC連結モードに遷移する。
【0095】
従来のEPCにおけるMMEは、次世代システム(又は5G CN(Core network))ではAMF(Core Access and Mobility Management Function)とSMF(Session Management Function)に分離された。よって、UEとのNAS interaction及びMM(Mobility Management)はAMFが、またSM(Session Management)はSMFが行った。SMFはuser−plane機能を有する、即ちuser trafficをルーティングするgatewayであるUPF(User Plane Function)を管理するが、これは従来のEPCにおいてS−GWとP−GWのcontrol−plane部分をSMFが担当し、user−plane部分はUPFが担当することと見なすことができる。User trafficのルーティングのためにRANとDN(Data Network)の間にUPFが1つ以上存在できる。即ち、従来のEPCは5Gにおいて
図7に示したように構成される。また、従来のEPSにおけるPDN connectionに対応する概念として、5G SystemではPDU(Protocol Data Unit) sessionが定義されている。PDUセッション(PDU session)はIP typeだけではなく、Ethernet type又はunstructured typeのPDU connectivity serviceを提供するUEとDNの間のassociationを言う。なお、UDM(Unified Data Management)はEPCのHSSに対応する機能を行い、PCF(Policy Control Function)はEPCのPCRFに対応する機能を行う。勿論、5G Systemの要求事項を満たすために、その機能が拡張された形態で提供されることもできる。N1は5G UEとAMFの間の制御平面に対するreference pointであり、N2は5G(R)ANとAMFの間の制御平面に対するreference pointであり、N3は5G(R)ANとUPFの間のユーザ平面のreference pointである。またN4はSMFとUPFの間のreference pointであり、N5はpcf機能と応用機能の間のreference pointであり、N6はUPFとデータネットワークの間のreference pointである。データネットワークは運営者外部公開、個人データネットワーク又は運営者データネットワークである。N7はSMFとPCFの間のreference pointである。5G System architecture、各function、各interfaceに関する詳しい事項はTS 23.501を準用する。特に、5Gシステム(即ち、next generation system)は、non−3GPP Accessも支援する必要があり、よってTS 23.501V0.2.0の4.2.7にはnon−3GPP Accessを支援するためのアーキテクチャー、ネットワーク要素などの内容が記載されている。Non−3GPP接続の例としては、代表的にWLAN接続があり、これはtrusted WLANとuntrusted WLANを全て含む。
【0096】
TS 23.501には様々なnon−3GPPアクセスが含まれたアーキテクチャーがあるが、一例として、
図8のように、3GPPアクセスに対するAMF(即ち、UEの3GPPアクセスに対するサービングAMF)とnon−3GPPアクセスに対するAMF(即ち、UEのnon−3GPPアクセスに対するサービングAMF)が異なる場合がある。これは各アクセスが属する/位置するPLMNが異なるためである。
【0097】
このようにUEに対してサービングAMFが2つ(以上)である場合、サービングAMFを格納するUDMはAMFからサービングノードの登録要請があった時(例えば、TS 23.502v0.3.0の5.2.3.1(NUDM_Serving NF_Registration service)動作)、このAMFがどのアクセスタイプに対するサービングAMFであるかが分からない。従って、UDMはUEに対するサービングAMFが既に存在する場合、それを取り替えるか、又はそれとは異なるアクセスに対するサービングAMFとして追加するかを決定することができない。その他にも、あるネットワークエンティティがUDMにUEのサービングAMFに関する情報を尋ねるか、又はサービングAMFへの動作を要請する時、UDMはどのアクセスタイプに対するAMFであるかを決定できない問題がある。
【0098】
以下、このように3GPP、non−3GPPアクセスに関連してAMFがアクセスごとに存在する場合、サービングAMFを効率的に管理する方法、又はサービングAMFに関する情報を管理する方法などを説明する。
【0100】
本発明の一実施例によるUDMは、AMF(Access and Mobility Management Function)の登録に関連する手続きにおいて、アクセスタイプ情報及びID情報を含む、UEのサービングAMF登録に関連するメッセージを第1AMFから受信する。UDMはAMFに関連するアクセスタイプ情報及びAMF ID情報を格納する。もし該アクセスタイプ情報に該当する、UEのサービングAMFとして登録された第2AMFが存在する場合、UDMは第2AMFで登録解除関連メッセージを送信する。ここで、アクセスタイプは3GPPアクセス、non−3GPPアクセスを含む(AMFに関連するアクセスタイプ情報及びAMF ID情報の格納は、アクセスタイプ情報に該当するUEのサービングAMFとして登録された第2AMFが存在する場合、又は存在しない場合にも行うことができる)。
【0101】
即ち、AMFがサービングAMFとして登録されるために送信するメッセージはAMFのIDを含むが、このAMFがどのアクセスタイプに関するかという情報をUDMに知らせることである。UDMは従来にはAMFのIDのみを格納したこととは異なり、AMF IDに関連するアクセスタイプ情報まで一緒に格納する。この場合、UDMはAMFをアクセスタイプごとに管理することができ、受信された特定のアクセスタイプと同じ、既にUEのサービングAMFに登録されたAMFが存在する場合、既に登録されたAMFを登録解除させることである。AMFが送信するメッセージに含まれるAMF IDはAMFアドレス、AMF NF(Network Function) ID、AMF識別子、AMF IP住所、AMFのFQDNのうちのいずれか1つであり、AMFというNFタイプ情報を含むこともできる。又はAMF IDはGUAMI(Globally Unique AMF IDentifier)形態であることもできる。これはAMFが送信するメッセージだけではなく、他のNFが送信するメッセージに含まれるAMF IDにも適用される。また、これはNFが送信するメッセージに含まれるNF IDにも適用される。UDMが格納するAMFのIDは、上記AMFが送信するメッセージに含まれたAMF IDであるか、その一部の情報であるか、又はUDMが理解する形態に変形したものである。また本発明の全般にわたってUDMが格納するNFのIDに適用できる。
【0102】
上述した動作を
図9を参照しながら、一般登録(General Registration)手続きにより詳しく説明する。
図9には3GPP TS 23.502v0.3.0の一般登録手続きが示されている。
図9において、段階S901におけるUEが登録要請を送信することから段階S913に関する内容、及びS915〜S923に関する詳しい内容は、3GPP TS 23.502v0.3.0の一般登録部分の説明で代替する。
【0103】
段階S914において、もしAMFが最後の登録手続きにより変更されるか、AMF内のUEのために有効な加入コンテキスト(subscription context)がないか、又はUEがAMF内の有効なコンテキストを参照しないSUPI(Subscription Permanent Identifier)を提供する場合、新AMFは位置更新手続きを開始する。新AMFはサービングするアクセスタイプをUDMに提供する。もしアクセスタイプに該当するAMFが存在する場合、UDMがこのAMF、即ち、旧AMFに位置取り消しを開始することを含む。UDMはサービングAMF(情報)と共に関連アクセスタイプを格納する。(新AMFがUDMにアクセスタイプ情報を提供する事項及び関連UDM動作の詳しい事項は、
図11の内容を参考)。旧AMFはMMコンテキストを削除してできる限り全ての連関SMFに知らせ、新AMFはUDMからAMF関連の加入データ(subscription data)を得た後、UEのためのMMコンテキストを生成する。この時、旧AMFは3GPPアクセスに該当するMMコンテキストを削除して、3GPPアクセス上のPDUセクションに対するSMFにそれを通知する。また新AMFは3GPPアクセスに対するMMコンテキストを生成する。旧AMFと新AMFがアクセスタイプが3GPPアクセスであることを認知することは、UDMから得るか、又はサービングするアクセスが3GPPアクセスだけであるためである。
【0104】
この手続きにおいて、もしUEがnon−3GPPアクセスに既に登録されたことと同じAMFに登録する場合(例えば、UE is registered over a non−3GPP access and initiates this registration procedure to add a 3GPP access)、AMF通知要請(AMF Notify Request)(AMF ID、アクセスタイプ)メッセージをUDMに送信する必要がある。アクセスタイプは"3GPPアクセス"と設定され、通知要請はUDM内で3GPPアクセスのためのサービングAMFを登録するためのものである。UDMは通知応答メッセージ(Notify Response message)をAMFに送信する。上述したように、AMFが新しいアクセスの追加を通知要請メッセージによりUDMに知らせることができ、その他には、位置更新要請メッセージなどの様々なメッセージを用いることができる。
【0105】
図10にはuntrusted non−3GPPアクセスによる登録手続きが示されている。段階S1007の後、
図9の段階S913及びS914が行われる。異なる点は、
図9ではアクセスタイプを3GPPアクセスと説明したが、ここではアクセスタイプをNon−3GPPアクセスとして解釈する。勿論、段階S913〜914は段階S1007の前に行われることもできる。一方、
図10の各手続きに関する詳しい説明は、3GPP TS 23.502v0.3.0のUntrusted non−3GPPアクセスによる登録部分の説明で代替する。
【0106】
図11にはNUDM_Serving NF_Registration serviceのサービス/サービス運用情報の流れが示されている。ここで、Nudm_Serving NF_Registration serviceは以下の表2のように明記できる。以下の説明において本発明の範囲は特定名称などにより制限されない。
【0108】
図11を参照すると、段階S1101において、Requester NFはUDMにUEのサービングNFとして登録されようとする。Requester NFは登録UEサービングNF要請(SUPI、NF ID)メッセージをUDMに送信する。NF IDはNFタイプ及びサービングNFのID(識別子)を示す。選択的には、RequesterのNFタイプによって、要請メッセージはUDMに格納される追加情報を含むことができる。例えば、もしNFがSMFである場合、NFタイプは関連APNを含むことができる。
【0109】
もしRequesterのタイプがAMFである場合、要請メッセージはUDM内のAMF(情報)と共に格納されるアクセスタイプを含む(例えば、"3GPPアクセス"又は"Non−3GPPアクセス")。
【0110】
AMFは段階S1101をアクセスタイプごとに行う。例えば、UE#1が3GPPアクセスによりAMF#1に登録すると、AMF#1はUDMにアクセスタイプ="3GPPアクセス"を含めて要請メッセージを送信する。その後、UE#1がnon−3GPPアクセスによりAMF#1に登録すると、AMF#1はUDMにアクセスタイプ="Non−3GPPアクセス"を含めて要請メッセージを送信する。他の例として、UE#2が3GPPアクセスによりAMF#2に登録すると、AMF#2はUDMにアクセスタイプ="3GPPアクセス"を含めて要請メッセージを送信する。その後、UE#2がnon−3GPPアクセスによりAMF#3に登録すると、AMF#3はUDMにアクセスタイプ="Non−3GPPアクセス"を含めて要請メッセージを送信する。
【0111】
上記ではアクセスタイプ情報として"3GPPアクセス"又は"Non−3GPPアクセス"を言及したが、これらは様々なレベル/形態で表すことができる。例えば、3GPPアクセスは、NG-RAN(又はNR)、E-UTRAN(又はLTE)のように表現できる。また3GPPアクセスであり、かつ詳しくどのRANであるかを表現することもできる。またnon−3GPPアクセスは、untrusted non−3GPPアクセス、trusted non−3GPPアクセス、WLANなどのように表現できる。またnon−3GPPアクセスであり、かつ詳しくどのアクセスであるかを表現することもできる。またアクセスタイプは"All accesses"又は"Both accesses"のように、全てのアクセスタイプを示すことができる。このように全てのアクセスタイプを示しながら、S1101を行う場合、AMFは全てのアクセスタイプに対して自分がサービングAMFであることを認知するまで、S1101を延期することができる。またアクセスタイプ情報を暗示的に示すこともできるが、例えば、UEの位置情報(セルID、WLAN APのSSIDなど)によりRAT種類を類推するようにすることができる。またアクセスタイプ情報はRATタイプ情報とも解釈できる。かかるアクセスタイプ関連説明及び動作は、本発明の全般にわたってそのまま又は変形して適用できる。
【0112】
上記のようにAMFが要請メッセージにアクセスタイプ情報を含めることは、全てのUEに対して行われるか(即ち、常に)、又は以下のうちのいずれかの条件を満たす場合に行われる。これは本発明の全般にわたって適用される。
【0113】
i)UEがnon−3GPPアクセス(又はWLAN)によりサービスを受けることができる場合、
【0114】
ii)UEがnon−3GPPアクセス(又はWLAN)によりハンドオーバーすることができる場合、
【0115】
iii)AMFが位置する/属するPLMNがnon−3GPPアクセス(又はWLAN)を支援しない場合、
【0116】
iv)AMFが位置する/属するPLMNがN3IWFを支援/ルーティングしない場合。
【0117】
上記において、AMFがサービングするアクセスタイプが3GPPアクセスである場合、アクセスタイプ情報を含まないこともできる。この場合、UDMはAMFの連関アクセスが3GPPアクセスであると見なす。またこの場合、アクセスタイプ情報はアクセスタイプがnon−3GPPアクセスである場合のみを示せばよいので、フラグ(又はビット)を1又はYes又はSetすることにより、AMFがnon−3GPPアクセスに対してサービングすることを示すことができ、フラグ自体を含ませることにより、この場合にAMFがnon−3GPPアクセスに対してサービングすることを示すことができる(例えば、フラグの名前をN3GPP Flagのようにする)。これは本発明の全般にわたって適用できる。
【0118】
選択的に加入データ回収指示が含まれる場合は、Requester NFは応答メッセージによりNFタイプに関連するUE加入データをリターンすることをUDMに要請する。この指示は、上記データが変更されるか又はそれ以上同期化されない時に、暗黙的に(UDM_Subscription data_UpdateNotification、
図18を参照)により通報される。
【0119】
Requester NFがUDMに登録UEサービングNF要請メッセージを送信する時、それはNF IDの変更(例えば、"NUDM_Serving NF_ChangeNotification"及び"NUDM_Subscription Data_UpdateNotification"サービスに対する)を暗黙的に知らせる。かかる通知サービスへの加入は、該当アクセスタイプに対する加入である。
【0120】
段階S1102において、UDMは登録サービングNFをUEコンテキストに格納する。加入データに関連するNFタイプは加入データ回収指示が要請メッセージに含まれる場合、Requester NFにリターンされる。
【0121】
登録されたサービングNFがAMFであると、UDMは関連するアクセスタイプをサービングNFと共に格納する。関連アクセスタイプに対するAMFがUDMにおいてUEに対して存在すると、UDMは既存のAMFを新AMF、即ち、Requester NFで代替する。この場合、さらにUDMは現AMFに位置取り消しメッセージを送信することができる。結局、UDM内における連関アクセスタイプのためのAMFが存在しない場合、UDMは新AMF情報(アクセスタイプを有するRequester NF)を格納する。
【0122】
一方、UDMがNFからUEコンテキストの削除に関連する要請メッセージを受信し、NFがAMFである場合には、UEコンテキストの削除に関連する要請メッセージは、アクセスタイプ情報を含むことができる。これに関連して、
図12(a)にはNUDM_Subscriber Data_Purge serviceのサービス/サービス運用情報の流れが示されている。
【0123】
段階S1201において、Requester NFはUEデータ除去要請(SUPI)メッセージをUDMに送信する。これはUDMがUEコンテキストから格納されたRequester NFを削除する要請である。Requester NFがUEデータ除去要請メッセージを送信する時、NFの連関アクセスタイプ情報を含むことができる。これはNFがAMFである場合にのみ含むことができる。またアクセスタイプ情報はnon−3GPPアクセスである場合にのみ含むことができる。
【0124】
段階S1202において、UDMはRequester NFをUEコンテキストから除去し、UE除去応答メッセージで応答する。その後、requesterにそれ以上加入データ更新通報を送らない。UDMは要請メッセージに含まれた又は含まれていないアクセスタイプ情報に基づいて、それに該当する、即ち、要請された(又は要請されたと見なされた)アクセスタイプについて、Requester NFをUEコンテキストから削除する。この時、アクセスタイプ情報を応答に含ませることもできる。
【0125】
上述した説明において、Nudm_Subscriber Data_Purgeは以下の表3のように明記(specify)できる。
【0127】
一方、UDM内で利用者プロフィールが変更される度に、またその変更がAMFの利用者プロフィールに影響を与える度に、UDMはこれらの変更を"Subscriber data Update Notification to AMF"手続きにより影響を受けるAMFに知らせる。この場合、AMFは利用者プロフィールを追加又は変更する。UDMがAMFにSubscriber data Update Notification to AMF動作を行う時、どのアクセスタイプに対する利用者プロフィール変更であるかを示す情報をAMFに提供することができる。もし3GPPアクセスとnon−3GPPアクセスをサービングするAMFが異なると、UDMは利用者プロフィール変更に対応するアクセスをサービングするAMFでSubscriber data Update Notification to AMF動作を行う。"Subscriber data Update Notification"サービスは、UDMがAMFに格納された加入データを更新する時に使用される。
【0128】
AMFは変更された加入データによって適切な動作を開始する。例えば、更新された加入データがこのネットワーク内でUEのローミングが許容されないことを指示する場合、AMF初期登録解除手続きを開始する。AMFはUDMから提供されたアクセスタイプに関する情報に基づいてこのアクセスについて、又は情報がなくても自分が1つのアクセスについてサービングしていると、該当アクセスについて、上記変更された加入者情報に対応する適切な動作を行う。
【0129】
図12(b)にはAMFによる加入データ削除手続きが示されている。段階S1211において、UE登録解除のMMコンテキスト及び加入データを除去した後、AMFはUDMにUE削除(SUPI)メッセージを送信する。AMFがUE除去メッセージをUDMに送信する時、どのアクセスタイプに対する削除であるかを明示的に又は暗示的に含む。明示的に含む場合は、例えば、3GPPアクセス、non−3GPPアクセス、2つのアクセスを示す情報の形態で含むことができる。暗示的に含む場合は、UEの位置情報を含むことによりアクセスタイプを知らせることができるが、例えば、セルIDのような情報は3GPPアクセスと解釈され、WLAN APのSSIDのような情報はnon−3GPPアクセスと解釈される。勿論、2つのアクセスについて削除する場合には、2つのアクセスに関する位置情報を含むことができる。
【0130】
段階S1212において、UDMはUE削除フラグを設定し、UE Ack削除メッセージにより応答する。UDMはUE削除フラグをアクセスタイプごとに管理することができる。よって、AMFが提供した情報、AMFがどのアクセスをサービングするかに関する情報などに基づいて、削除されたアクセスに該当するUE削除フラグを設定(set)する。
【0131】
図13には、Nudm_Serving NF_RemoveNotification serviceのサービス/サービス運用情報の流れが示されている。段階S1301において、UEサービングNFが除去されたことをUDMが検出した場合(例えば、新AMFがUDMに登録)、UDMは以前にNudm_Serving NF_RemoveNotificationサービスに加入されたRequester NFに、UEサービングNF除去通知(SUPI、サービングNF除去理由)を通報する。上記提供されるサービングNF除去理由は、なぜNFが除去されたかという理由(例えば、update due to a new Serving NF is registered)を指示する。さらにRequester NFは関連処理を行う(例えば、remove the UE context it maintains when the UE is not served by the requester)。UDMはかかる動作をAMFがサービングするアクセスタイプに合わせて行うことができる。即ち、Requester NFが特定のアクセスタイプに対するNudm_Serving NF_RemoveNotificationサービスに加入した場合、該当アクセスタイプに対応するUEサービングNFの除去が発生した時、これをRequester NFに通報することができる。この時、UEサービングNF除去通報メッセージにサービングNFの関連アクセスタイプを追加することもできる。
【0132】
上述した説明において、Nudm_Serving NF_RemoveNotificationは以下の表4のように明記(specify)できる。
【0134】
一方、UDMが加入撤回(subscription withdrawn)により登録解除関連メッセージを送信する場合は、登録解除関連メッセージはどのアクセスタイプに対するものであるかを指示することができる。
【0135】
上記説明した動作を
図14を参照しながらUDM初期登録解除手続きに基づいて詳しく説明する。
図14には3GPP TS 23.502v0.3.0の登録解除手続きが示されている。
図14において、段階S1403以後に関する詳しい内容は、3GPP TS 23.502v0.3.0の登録解除手続き部分の説明で代替する。
【0136】
段階S1401aにおいて、もしUDMが加入者のMMコンテキスト及びPDUセクションの即刻削除を望む場合、UDMは位置取り消し(SUPI(Subscriber Permanent Identifier)、Cancellation type)メッセージをRegistered AMFに対して加入撤回が設定されたキャンセルタイプと共に送信しなければならない。
【0137】
UDMが位置取り消しメッセージを送る時、どのアクセスタイプに対する取り消し要請であるかを追加することができる。UDMはAMFが3GPPアクセス及びnon−3GPPアクセスの両方に対してサービングする場合にのみ情報を追加することもできる。情報が含まれていないが、AMFが両方のアクセスを全てサービングしていると、AMFは、i)該当UEに対して自分がサービングする全てのアクセスについて取り消し要請があったと見なすことができ、ii)3GPPアクセスのみについて取り消し要請があったと見なすこともでき、iii)non−3GPPアクセスのみについて取り消し要請があったと見なすこともできる。この場合、AMFにおけるローカル設定(local configuration)、オペレータ政策(operator policy)などの情報に基づいて、i)又はii)又はiii)と見なすことができる。
【0138】
3GPPアクセスに対するサービングAMFとnon−3GPPアクセスに対するサービングAMFが異なる場合、UDMは取り消し要請を行うアクセスに対応するAMFに位置取り消しメッセージを送信する。2つのアクセスについて取り消す場合(これはアクセスに関係なく取り消す場合であると解釈できる)、2つのAMFに各々位置取り消しメッセージを送信する。AMFはどのアクセスタイプに対する取り消し要請であるかという情報がある場合はその情報に基づいて、又はかかる情報がなくても自分がサービングするアクセスタイプを分かるので、どのアクセスタイプに対する取り消し要請であるかを決定することができる。
【0139】
段階S1402において、もしキャンセルタイプが加入撤回である場合、活性UEコンテキストを有するAMFはCM−CONNECTED状態のUEに登録解除要請(登録解除タイプ)メッセージを送信することにより登録解除されたことを知らせる。もし位置取り消しメッセージが再添付される必要があることを指示するフラグを含む場合は、AMFは登録解除タイプを再添付必要を指示するものと設定する必要がある。もしUEがCM−IDLE状態である場合、AMFはUEをページングする。上述したように、AMFは取り消し要請を受けたアクセスタイプ又は取り消すと決定されたアクセスタイプを認知できるので、該当アクセスにUEの登録解除動作を行う。もし3GPPアクセス及びnon−3GPPアクセスの両方に対して登録解除が必要であると、1つのアクセスに登録解除要請を送信しながら2つのアクセスに対して登録解除することを明示的に又は暗示的に知らせることができる。
【0140】
一方、NFからサービングAMF情報を要請するメッセージが受信されると、UDMは上記アクセスタイプに該当するサービングAMF情報をNFに送信し、サービングAMF情報を要請するメッセージはアクセスタイプ情報を含むことができる。
【0141】
これに関連して、
図15(a)にはNudm_Serving NF_Get serviceのサービス/サービス運用情報の流れが示されている。
【0142】
段階S1501において、NF消費者はUEサービングNFを得るために、UEサービングNF獲得要請(UE ID、NFタイプ)メッセージをUDMに送信する。NFタイプはどのタイプのNF(例えば、AMF、SMFなど)が尋ねられたかを指示する。NF消費者(即ち、申請人)がUEサービングNF獲得要請メッセージを送信する時、サービングNFの関連アクセスタイプ情報を含むことができる。これはNFタイプがAMFである場合にのみ含むこともできる。またアクセスタイプ情報はnon−3GPPアクセスである場合にのみ含むこともできる。
【0143】
段階S1502において、UDMはRequester NFが要求された加入サービングNFデータにアクセスすることが許容されるか否かを検証し、許容される場合、要求された加入サービングNFデータ(例えば、FQDN又はサービングNFの住所)を申請人に提供する。UDMは要請メッセージに含まれた又は含まれていないアクセスタイプ情報に基づいてそれに該当する、即ち、要請された(又は要請されたと見なされた)アクセスタイプに対してUEのサービングNFを提供する。この時、上記アクセスタイプ情報を応答に含ませることもできる。
【0144】
UDMは段階S1501の要請メッセージを受信すると、必ず3GPPアクセスに対応するAMF IDを応答に提供することもできる。これは上記提案するアクセスタイプ情報に関する事項が追加されないことを仮定しているとも解釈できる。
【0145】
ここで、Nudm_Serving NF_Get serviceは以下の表5のように明記(specify)できる。以下の説明において、本発明の範囲は特定名称などにより制限されない。
【0147】
図15(b)にはNudm_Subscriber data_Get serviceのサービス/サービス運用情報の流れが示されている。
【0148】
段階S1511において、Requester NFはUDMから相応する加入者データを得るために、UE ID(例えば、SUPI)及びNFタイプ情報を提供しながらUDMに要請する。
【0149】
段階S1512において、もしNFタイプがSMFであると、DNNも含まれる。Requester NFが加入者データ獲得要請メッセージを送信する時、アクセスタイプ情報を含むことができる。これはNFがAMFである場合にのみ含むこともできる。またアクセスタイプ情報はnon−3GPPアクセスである場合にのみ含まれることもできる。
【0150】
段階S1512において、UDMは相応する加入者データを回収し、Requester NFにデータを提供するためにUE ID及びNFタイプをチェックする。Requester NFがSMFである場合、加入者データは、例えば、PDUタイプ、公認SSCモード、基本QoSプロファイルなどを含む。UDMは要請メッセージに含まれた又は含まれていないアクセスタイプ情報に基づいてそれに該当する、即ち、要請された(又は要請されたと見なされた)アクセスタイプに関する加入者情報をRequester NFに提供する。この時、アクセスタイプ情報を応答に含ませることもできる。
【0151】
ここで、Nudm_Subscriber Data_Getは以下の表6のように明記(specify)できる。以下の説明において、本発明の範囲は特定名称などにより制限されない。
【0153】
一方、UDMはNFからUE到達可能性(Reachability)の情報提供を要求する要請を受信することができるが、UE到達可能性の情報提供を要求する要請はアクセスタイプ情報を含む。UDMはアクセスタイプに該当するAMFで、UE到達可能性イベントに対する通知サービスに加入することができる。アクセスタイプに該当するAMFからUEが到達可能であるという情報を受信すると、NFにUEが到達可能であるという情報を送信する。
【0154】
上述した動作を
図16を参照しながら、到達可能性手続きにより詳しく説明する。
図16には3GPP TS 23.502v0.3.0の到達可能性手続きが示されている。
【0155】
段階S1600の登録手続き又は加入更新手続きにおいて、UDMはAMFにUEの到達可能性に対する通知要請が承認されたネットワークエンティティの身元(例えば、FQDNs)を知らせる。UDMとSMSFは承認されたことが基本状態である。
【0156】
以上、UDMがAMFでUE到達可能性通報を要請したネットワークエンティティを知らせる時、各ネットワークエンティティがどのアクセスタイプに対して到達可能性通知サービスを受けようとするかを提供することができる。これは各ネットワークエンティティから提供された関連情報、UDMに設定されている情報(ローカル設定、オペレータ政策など)、エンティティの種類/特定(例えば、エンティティが提供するサービス)、UEの加入者情報などに基づいて決定される。UDMはAMFが3GPPアクセス及びnon−3GPPアクセスの両方に対してサービングする場合にのみ情報を提供することができる。上記情報が含まれていないが、AMFが両方のアクセスをサービングしていると、AMFはi)該当UEに対して自分がサービングする全てのアクセスについて到達可能性の通報要請があったと見なすことができ、ii)3GPPアクセスのみについて到達可能性の通報要請があったと見なすこともでき、iii)non−3GPPアクセスのみについて到達可能性の通報要請があったと見なすこともできる。これはAMFにおけるローカル設定、オペレータ政策、UEの加入者情報などに基づいて、i)又はii)又はiii)と見なすことができる。
【0157】
3GPPアクセスに対するサービングAMFとnon−3GPPアクセスに対するサービングAMFが異なる場合、UDMはUE到達可能性の通報要請を行うアクセスに対応するAMFにネットワークエンティティを知らせるメッセージを送信する。AMFはどのアクセスタイプに対する到達可能性通報要請であるかに関する情報がある場合はその情報に基づいて、又はかかる情報がなくても自分がサービングするアクセスタイプを分かるので、どのアクセスタイプに対する到達可能性通報要請であるかを決定することができる。
【0158】
AMFは各エンティティがどのアクセスタイプに対してUE到達可能性通報要請をしたかというアクセスタイプ情報をentity IDと共に格納する。
【0159】
段階S1601において、もしサービス関連エンティティがUDMにUE到達可能性に関する指示提供を要請する場合、UDMは加入上にそのエンティティが該要請を行うように承認されたかをチェックする。もしエンティティが承認されていない場合、要請は拒絶されるか(例えば、要請エンティティが有効なエンティティとして認識されているが、その加入に対して許可されていない場合)、又は削除される(例えば、要請エンティティが認識されていない場合)。適切なO&Mリポートが生成される。
【0160】
上記において、サービス関連エンティティがUDMにUE到達可能性通知を要請する時、どのアクセスタイプに対して到達可能性通知サービスを受けようとするかを追加することができる。上記情報が含まれていないと、UDMはi)該当UEに対して全てのアクセスについて通知要請があったと見なすことができ、ii)3GPPアクセスのみについて通知要請があったと見なすこともでき、iii)non−3GPPアクセスのみについて通知要請があったと見なすこともできる。この場合、UDMにおけるローカル設定、オペレータ政策、到達可能性通報要請をしたエンティティの種類/特定(例えば、エンティティが提供するサービス)、UEの加入者情報などに基づいて、i)又はii)又はiii)と見なすことができる。
【0161】
UDMは各エンティティがどのアクセスタイプに対してUE到達可能性通報要請をしたかというアクセスタイプ情報をentity IDと共に格納する。
【0162】
段階S1602aにおいて、UDMはサービス関連エンティティのIDを格納し、URRP−AMFパラメータをかかる要請が受信されたと設定する。もしURRP−AMFパラメータ値が"未設定(not set)"から"設定(set)"に変更された場合、UDMはUE−REACHABILI-NOTIFICATION−REQUEST(URRP−AMF)をAMFに送信する。上記において、UDMがAMFでUE到達可能性通知を要請する時、どのアクセスタイプに対して到達可能性通知サービスを受けようとするかを提供することができる。これは、上述したように、UDMにUE到達可能性通知を要請したエンティティから受信したアクセスタイプ関連情報、UDMに設定されている情報(ローカル設定、オペレータ政策など)、エンティティの種類/特定(例えば、エンティティが提供するサービス)、UEの加入者情報などに基づいて決定される。UDMはAMFが3GPPアクセス及びnon−3GPPアクセスの両方に対してサービングする場合にのみ情報を提供することができる。上記情報が含まれていないが、AMFが両方のアクセスを全てサービングしていると、AMFはi)該当UEに対して自分がサービングする全てのアクセスについて到達可能性の通報要請があったと見なすことができ、ii)3GPPアクセスのみについて到達可能性の通報要請があったと見なすこともでき、iii)non−3GPPアクセスのみについて到達可能性の通報要請があったと見なすこともできる。この場合、AMFにおけるローカル設定、オペレータ政策、UEの加入者情報などに基づいて、i)又はii)又はiii)と見なすことができる。
【0163】
3GPPアクセスに対するサービングAMFとnon−3GPPアクセスに対するサービングAMFが異なる場合、UDMはUE到達可能性通報を要請するアクセスに対応するAMFに要請メッセージを送信する。AMFはどのアクセスタイプに対する到達可能性通報要請であるかに関する情報がある場合はその情報に基づいて、又はかかる情報がなくても自分がサービングするアクセスタイプを分かるので、どのアクセスタイプに対する到達可能性通報要請であるかを決定することができる。
【0164】
上記UDMが管理するURRP−AMFパラメータはアクセスごとに管理できる。例えば、あるエンティティが3GPPアクセスに対してUE到達可能性通報を要請すると、3GPPアクセスに対するURRP−AMFパラメータを"set"に設定する。
【0165】
AMFはUDMがどのアクセスタイプに対してUE到達可能性通報を要請したかをアクセスタイプ情報と共に格納する。
【0166】
段階S1602bにおいて、SMSFはUE−REACHABILI-NOTIFICATION−REQUEST(URRP−AMF)をAMFに送信する。上記において、SMSFがAMFでUE到達可能性を通知要請する時、どのアクセスタイプに対して到達可能性通知サービスを受けようとするかを追加することができる。上記情報が含まれていないと、AMFはi)該当UEに対して全てのアクセスについて通知要請があったと見なすことができ、ii)3GPPアクセスのみについて通知要請があったと見なすこともでき、iii)non−3GPPアクセスのみについて通知要請があったと見なすこともできる。この場合、AMFにおけるローカル設定、オペレータ政策、UE加入者情報などに基づいて、i)又はii)又はiii)と見なすことができる。又は上記情報が含まれていないと、AMFはSMSFがSMSを担当する機能であるので、3GPPアクセスについて通知要請があったと見なすことができる。AMFはSMSFがどのアクセスタイプに対してUE到達可能性通知を要請したかというアクセスタイプ情報をSMSF IDと共に格納する。
【0167】
段階S1603において、AMFは要請エンティティが加入者の要請を行うように承認されたかをチェックする。もしエンティティが承認されていない場合は、要請が拒絶されるか(例えば、要請エンティティが有効なエンティティとして認識されているが、その加入に対して許可されていない場合)、又は削除される(例えば、要請エンティティが認識されていない場合)。適切なO&Mリポートが生成される。
【0168】
もしAMFがその使用者のためにMMコンテキストを有する場合、AMFはURRP−AMFをUE到達可能性から変更関連UDM情報を報告する必要があると指示するように設定する(例えば、UEの次のNAS活動が検出された時)
【0169】
上記AMFが管理するURRP−AMFパラメータはアクセスごとに管理できる。例えば、UDMが3GPPアクセスに対してUE到達可能性通知を要請すると、3GPPアクセスに対するURRP−AMFパラメータを"set"に設定する。
【0170】
UDMが他のネットワークエンティティからUE到達可能性通知要請を受けたので、又は自分がUE到達可能性を要請するためにAMFを選択/決定する時、該当UEに対して3GPPアクセスをサービングするAMFを必ず選択/決定して、AMFにUE到達可能性通報要請を送信することもできる(S1600、S1602aを行う時)。これはUEをサービングするAMFが多数個である場合、これらのうち、3GPPアクセスに該当するAMFを選択/決定することとも解釈できる。
【0171】
図17にはNUDM_UE Reachability_Notification serviceのサービス/サービス運用情報の流れが示されている。段階S1701において、Requester NFはUE ID、任意パラメータなどの情報を提供するUE到達可能性加入をUDMに送信する。UE ID(例えば、SUPI)はUDMによりUEを識別しなければならない。Requester NFがUE到達可能性加入メッセージを送信する時、アクセスタイプ情報を含むことができる。これはNFがAMFである場合にのみ含むことができる。またアクセスタイプ情報はnon−3GPPアクセスである場合にのみ含むことができる。
【0172】
段階S1702において、選択的にUDMは任意パラメータに含まれたNF IDに基づいて要請を承認することができる。もしRequester NFがこのサービスを使用するように承認されていない場合は、UDMは拒絶応答を送信する。
【0173】
段階S1703において、もしRequester NFがこのサービスにアクセスすることが承認された場合、UDMはUEが到達可能であることを獲得すると直ちにUE到達可能性通知メッセージをRequester NFに送信する。UDMは要請メッセージに含まれた又は含まれていないアクセスタイプ情報に基づいてそれに該当する、即ち、要請された(又は要請されたと見なされた)アクセスタイプに対するUEの到達可能性情報をRequester NFに提供する。この時、アクセスタイプ情報を応答に含ませることもできる。例えば、Requester NFが3GPPアクセスに対するUE到達可能性加入をしたと見なされると、UDMはUEが3GPPアクセス上で到達可能になったことを検出した時、それをRequester NFに通報する。
【0174】
UDMは段階S1701の加入メッセージを受信すると、必ず3GPPアクセスに対するUE到達可能性通知サービスに加入すると見なすことができる。これは段階S1701で提案するアクセスタイプ情報に対する事項が追加されないことを仮定しているとも解釈できる。
【0175】
ここで、Nudm_UE Reachability_Notificationは以下の表7のように明記(specify)できる。以下の説明において、本発明の範囲は特定名称などにより制限されない。
【0177】
一方、
図18にはNUDM_Subscription Data_UpdateNotification serviceのサービス/サービス運用情報の流れが示されている。段階S1801において、UDMは加入データ更新通知(SUPI、Subscription data)メッセージを、以前のNUDM_Serving NF_Registrationにより以前のUDMに登録されたRequester NFに送信する。もしUDMはUEに対してRequester NFが多数個である場合(例えば、UEに対してサービングAMFが2つであり、1つは3GPPアクセスに対するAMF、他の1つはnon−3GPPアクセスに対するAMFである場合)、段階S1801の動作を全てのRequester NFで行う。
【0178】
UDMは上記動作をAMFがサービングするアクセスタイプに合わせて行うことができる。即ち、特定のアクセスタイプに関する加入者情報が変更された場合、該当アクセスタイプに対応するRequester NFにそれを通報することができる。この時、加入データ更新通知メッセージに加入者情報が変更されたアクセスタイプを追加することもできる。
【0179】
例えば、non−3GPPアクセスに関する加入者情報が変更された場合、UDMはこのアクセスに対応するAMFに通報する。これは、もし3GPPアクセスに対応するAMFが存在する場合、該AMFには上記通報を行わないことを意味する。ここで、NUDM_Subscription data_UpdateNotificationは以下の表8のように明記できる。以下の説明において、本発明の範囲は特定名称などにより制限されない。
【0181】
図19にはUE活動の通知手続きが示されている。
図19を参照すると、段階S1901において、AMFはUE到達可能性に関する指示を受信する(例えば、UEから登録要請メッセージ又はサービス要請メッセージ、RANからUE到達可能性の指示)。RANは3GPPアクセス関連RANであることができ、N3IWFであることもできる。
【0182】
段階S1902において、もしAMFがUEのMMコンテキストを含み、UEのためのURRP−AMFはUEが到達可能になると直ちに報告するように設定された場合、AMFはUE活動の通知メッセージ(永久ID、UE−Reachable)をUDMに(段階S1902a)又はSMSFに(段階S1902b)に送信し、該当URRP−AMFをクリアする。
【0183】
AMFがURRP−AMFパラメータをアクセスごとに管理する場合、UEが到達可能になったアクセスに対するURRP−AMFが"set"されていると、該当アクセスについてUE到達可能性通報を要請したエンティティ(例えば、UDM、SMSFなど)に上記のようにUEが活動中であることを通報するメッセージを送ることができる。この時、上記メッセージはUEが到達可能になったアクセスが何であるかを含むことができる。しかし、かかる情報を含まなくても、UDMなどのエンティティはAMFがどのようなアクセスに対するサービングAMFであるかを分かっているので、どのアクセスについてUEが到達可能になったかを判断することができる。その後、AMFは該当アクセスに対するURRP−AMFをクリアする。
【0184】
段階S1903において、もしUDMがUE−Activity−Notification(永久ID、UE−Reachable)メッセージ又はURRP−AMF設定を有するUEのための位置更新メッセージを受信した場合は、この要請に対してこの通報を受信するエンティティに対して適切な通報をトリガーし、このUEのためのURRP−AMFをクリアする。
【0185】
UDMがAMFからUEが活動中であることを知らせる通報メッセージを受信すると、該当アクセスについて(これを分かる方法は、段階S1902を参照)UE到達可能性通報を要請したエンティティに上記のようにUEが活動中であることを通報するメッセージを送ることができる。この時、上記メッセージはUEが到達可能になったアクセスが何であるかを含む。UDMがURRP−AMFパラメータをアクセスごとに管理する場合、UEが到達可能になったアクセスに対するURRP−AMFをクリアする。
【0186】
一方、
図20には3GPP TS 23.502v0.3.0の5GS to EPS handover for Single-registration mode with Nx interface手続きが示されている。Nxインターフェースは5GSとEPSの連動のためのAMFとMMEの間のインターフェースである。
図20の各段階に関する詳しい内容は、3GPP TS 23.502v0.3.0の5GS to EPS handover for Single-registration mode with Nx interface部分の説明で代替する。
【0187】
MMEはHSS(以下、これはHSS+UDMとも解釈でき、UDMと称することもできる)と位置更新動作を行うことができる。これはMMEがUEに対するサービングノードになったことをHSSに知らせるためのものである。よってMMEはHSSに位置更新要請メッセージを送信し、それを受信したHSSはAMFと位置取り消し動作を行う。HSSが位置取り消し動作を行うAMFは、3GPPアクセスに該当するAMFである。即ち、UEが5GSからEPSにハンドオーバーする場合、HSSとUDMによる位置取り消しは、アクセスタイプが3GPPであるAMFに対して行われることができる。例えば、該当UEに対して3GPPアクセスに関連するAMF#1があり、non−3GPPアクセスに関連するAMF#2があれば、AMF#1と位置取り消し動作を行う(かかる位置取り消しに関する詳しい事項は、Nudm_Serving NF_RemoveNotification serviceの説明を参照)。
【0188】
一方、MMEがHSSに位置更新要請メッセージを送信すると、HSSは3GPPに該当するAMFをキャンセルせず、維持することができる。MMEの位置更新動作はUEのTAU動作に基づくか又は基づかない(EPSにおける位置更新動作及び位置取り消し動作はTS 29.272を参照)。
【0189】
以上の内容は示された手続きだけではなく、UEが5GシステムからEPSにシステムを変更する他のシナリオにも拡張して又は同様に適用することができる。またUEが遊休モードにおいて5GシステムからEPSに変更する時、及び接続モードにおいて5GシステムからEPSに変更する時の両方に適用できる。例えば、UEが遊休モードである場合(又は遊休モードのUEが)5GSからEPSに変更する時、UDMはアクセスタイプが3GPPであるAMFに位置取り消し動作を行う、即ち、登録解除メッセージを送信することができる。
【0190】
また、UEがSR(Single Registered:1つのシステムのみに登録)である場合と、DR(Dual Registered:2つのシステムに登録)である場合の両方に適用できる。また5GシステムとEPSの間(これはMMEとAMFの間)にインターフェース(Nxインターフェース)がある場合と、ない場合の両方にも適用できる。
【0191】
一方、
図21には3GPP TS 23.502v0.3.0のEPS to 5GS handover using NX interface手続きが示されている。
【0192】
図21を参照すると、段階S2101において、source E-UTRANはUEが5G-RANにハンドオーバーすることを決定する。E−UTRANはハンドオーバー要求(Target 5G-RAN Node ID、Source to Target Transparent Container)メッセージをMMEに送信する。
【0193】
段階S2102において、MMEはtarget AMFを選択し、Nx再配置要請(Target 5G-RAN Node ID、Source to Target Transparent Container、EPS MM context、PDN Connection info)メッセージをAMFに送信する。
【0194】
MMEがtarget AMFを選択する時、HSS(以下、これはHSS+UDMとも解釈でき、UDMと称することもできる)に尋ねることもできる。HSSはUEに対してサービングAMFが既に存在すると、これをMMEに提供する。この時、HSSはサービングAMFとMMEが同じPLMNに属する場合にのみ提供することができる。一方、PLMN情報をサービングAMFと共にMMEに提供することにより、MMEがtarget AMFを選択/決定する時に使用することができる。またHSSはサービングAMFがnon−3GPPアクセスに該当するAMFである場合にも、このAMFに関する情報(例えば、AMF ID)を提供することができる。もしUEに対するサービングAMFが3GPPアクセスについても存在し、non−3GPPアクセスについても存在する場合、HSSは3GPPアクセスに該当するサービングAMF情報を提供することができる。
【0195】
その他の段階S2103〜2118に関する詳しい内容は、3GPP TS 23.502v0.3.0の5GS to EPS handover for Single-registration mode With NX interface部分の説明で代替する。
【0196】
図21に関連して、AMFはUDM(以下、これはHSS+UDMとも解釈でき、UDMと称することもできる)と位置更新動作を行うことができる。これはAMFがUEに対するサービングノードになったことをUDMに知らせるためのものである。AMFがUDMに位置更新動作(又は
図11のNUDM_Serving NF_Registration serviceで説明した動作)を行うと、UDMはMMEと位置取り消し動作を行う。一方、UDMはMMEをキャンセルせず、維持することもできる。
【0197】
以上の内容は示された手続きだけではなく、UEがEPSから5Gシステムにシステムを変更する他のシナリオにも拡張して、又は同様に適用することができる。またUEが遊休モードにおいてEPSから5Gシステムに変更する時、及び接続モードにおいてEPSから5Gシステムに変更する時の両方に適用できる。またUEがSR(Single Registered:1つのシステムのみに登録)である場合と、DR(Dual Registered:2つのシステムに登録)である場合の両方に適用できる。また5GシステムとEPSの間(これはMMEとAMFの間)にインターフェース(Nxインターフェース)がある場合と、ない場合の両方にも適用できる。
【0198】
上記では、提案する動作をNFタイプがAMFである場合を中心として説明したが、それに限られず、他のNF(例えば、SMF、PCF、SMSFなど)も本発明で提案する動作を行うことができる。上記において、ネットワーク機能、ネットワークエンティティ、ネットワークノードは同じエンティティを称する。
【0199】
図22は本発明の一例による端末装置及びネットワークノード装置の好適な実施例の構成を示す図である。
【0200】
図22を参照すると、本発明による端末装置100は、送受信装置110、プロセッサ120及びメモリ130を含む。送受信装置110は、外部装置に各種の信号、データ及び情報を送信し、外部装置から各種の信号、データ及び情報を受信するように構成される。端末装置100は外部装置と有線及び/又は無線で連結される。プロセッサ120は端末装置100の全ての動作を制御し、端末装置100が外部装置と送受信すべき情報などを演算処理する機能を行うように構成されることができる。メモリ130は演算処理された情報などを所定時間の間に記憶し、バッファー(図示せず)などの構成要素に取り替えられることができる。また、プロセッサ120は本発明で提案する端末動作を行うように構成される。
【0201】
図22を参照すると、本発明によるネットワークノード装置200は、送受信装置210、プロセッサ220及びメモリ230を含む。送受信装置210は、外部装置に各種の信号、データ及び情報を送信し、外部装置から各種の信号、データ及び情報を受信するように構成される。ネットワークノード装置200は外部装置と有線及び/又は無線で連結される。プロセッサ220はネットワークノード装置200の全ての動作を制御し、ネットワークノード装置200が外部装置と送受信すべき情報などを演算処理する機能を行うように構成されることができる。メモリ230は演算処理された情報などを所定時間の間に記憶し、バッファー(図示せず)などの構成要素に取り替えられることができる。また、プロセッサ220は本発明で提案するネットワークノード動作を行うように構成される。具体的には、プロセッサ220は、UDMがアクセスタイプ情報及びAMF ID(Identity)情報を含む、UEのサービングAMF登録に関連するメッセージを第1AMFから受信し、アクセスタイプ情報に該当する、UEのサービングAMFとして登録された第2AMFが存在する場合、UDMは第2AMFに登録解除関連メッセージを送信することができる。
【0202】
また、このような端末装置100及びネットワーク装置200の具体的な構成は、前述した本発明の多様な実施例で説明した事項が独立的に適用されるか、或いは2つ以上の実施例が同時に適用されるように具現でき、重複する内容は明確性のために説明を省略する。
【0203】
上述した本発明の実施例は多様な手段によって具現されることができる。例えば、本発明の実施例は、ハードウェア、ファームウエア(firmware)、ソフトウェア又はそれらの組合せなどによって具現できる。
【0204】
ハードウェアによる具現の場合、本発明の実施例による方法は、一つ又はそれ以上のASICs(Application Specific Integrated Circuits)、DSPs(Digital Signal Processors)、DSPDs(Digital Signal Processing Devices)、PLDs(Programmable Logic Devices)、FPGAs(Field Programmable Gate Arrays)、プロセッサ、コントローラー、マイクロコントローラー、マイクロプロセッサなどによって具現できる。
【0205】
ファームウエア又はソフトウェアによる具現の場合、本発明の実施例による方法は以上で説明した機能又は動作を行う装置、過程又は関数などの形態に具現できる。ソフトウェアコードはメモリユニットに記憶され、プロセッサによって駆動されることができる。メモリユニットはプロセッサの内部又は外部に位置し、既に知られた多様な手段によってプロセッサとデータを取り交わすことができる。
【0206】
以上のように開示された本発明の好適な実施形態についての詳細な説明は当業者が本発明を具現して実施することができるように提供した。以上では本発明の好適な実施形態に基づいて説明したが、当該技術分野の熟練した当業者は下記の特許請求範囲に記載された本発明の思想及び領域から逸脱しない範疇内で本発明を多様に修正及び変更することができることを理解することが可能であろう。よって、本発明はここで開示した実施形態に制限されるものではなく、ここで開示した原理及び新規の特徴と一致する最広の範囲を付与しようとするものである。