図面 (/)

技術 サービス要求手順実行方法及びユーザ装置

出願人 エルジーエレクトロニクスインコーポレイティド
発明者 キム,ジェヒュンリ,ヨンデキム,レヨンキム,ヒュンソクキム,テフンジュン,スンフン
出願日 2015年3月18日 (4年3ヶ月経過) 出願番号 2016-540831
公開日 2016年9月23日 (2年9ヶ月経過) 公開番号 2016-529856
状態 特許登録済
技術分野 移動無線通信システム
主要キーワード 上位水準 発明提案 遅延時間タイマ レファレンスポイント 適用状態 一部構成要素 一般セル ファームウェアアップグレード
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年9月23日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

本明細書の一開示は、ユーザ装置(user equipment:UE)におけるサービス要求手順(Service Request procedure)を実行する方法を提供する。

解決手段

前記方法は、ACB(access class barring)により発信呼び(originating call)のためのアクセスを前記UEの下位階層遮断するステップアップリンクデータのための要求により上位階層からの開始インジケーションを前記UEのNAS階層が受信するステップ;及び、前記下位階層は、前記発信呼びに対する前記アクセスが遮断されたと指示したが、前記NAS階層は、前記開始インジケーションを受信した場合、前記NAS階層は、サービス要求手順を開始するステップ;を含む。

概要

背景

移動通信システムの技術規格を制定する3GPPでは、4世代移動通信と関連した多様なフォーラム及び新しい技術に対応するために、2004年末から3GPP技術の性能を最適化させて向上させようとする努力一環としてLTE/SAE(Long Term Evolution/System Architecture Evolution)技術に対する研究を始めた。

3GPP SA WG2を中心に進行されたSAEは、3GPP TSG RANのLTE作業と並行してネットワークの構造を決定し、異機種ネットワーク間の移動性サポートすることを目的とするネットワーク技術に対する研究であって、最近3GPPの重要な標準化問題のうち一つである。これは3GPPシステムIPベースの多様な無線接続技術をサポートするシステムに発展させるための作業であって、より向上したデータ送信能力送信遅延を最小化する、最適化されたパケットベースのシステムを目標にして作業が進行されてきた。

3GPP SA WG2で定義したEPS(Evolved Packet System)上位水準参照モデル(reference model)は、非ローミングケース(non−roaming case)及び多様なシナリオローミングケース(roaming case)を含んでおり、詳細内容は、3GPP標準文書TS23.401とTS23.402で参照することができる。図1のネットワーク構造図は、これを簡略に再構成したものである。

図1は、進化した移動通信ネットワークの構造図である。

EPCは、多様な構成要素を含むことができ、図1は、そのうち一部に該当する、S−GW(Serving Gateway)52、PDN GW(Packet Data Network Gateway)53、MME(Mobility Management Entity)51、SGSN(Serving GPRS(General Packet Radio Service) Supporting Node)、ePDG(enhanced Packet Data Gateway)を示す。

S−GW52は、無線アクセスネットワーク(RAN)とコアネットワークとの間の境界点として動作し、eNodeB22とPDN GW53との間のデータ経路を維持する機能をする要素である。また、端末(または、User Equipment:UE)がeNodeB22によりサービング(serving)される領域にわたって移動する場合、S−GW52は、ローカル移動性アンカポイント(anchor point)の役割をする。即ち、E−UTRAN(3GPPリリース8以後で定義されるEvolved−UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access Network)内での移動性のために、S−GW52を介してパケットルーティングされることができる。また、S−GW52は、他の3GPPネットワーク(3GPPリリース8以前に定義されるRAN、例えば、UTRANまたはGERAN(GSM登録商標)(Global System for Mobile Communication)/EDGE(Enhanced Data rates for Global Evolution) Radio Access Network)との移動性のためのアンカーポイントとして機能することもできる。

PDN GW(または、P−GW)53は、パケットデータネットワークに向かうデータインターフェース終端点(termination point)に該当する。PDN GW53は、政策執行特徴(policy enforcement features)、パケットフィルタリング(packet filtering)、課金サポート(charging support)などをサポートすることができる。また、3GPPネットワークと非3GPPネットワーク(例えば、I−WLAN(Interworking Wireless Local Area Network)のような信頼されないネットワーク、CDMA(Code Division Multiple Access)ネットワークやWiMaxのような信頼されるネットワーク)との移動性管理のためのアンカーポイント役割をすることができる。

図1のネットワーク構造の例示は、S−GW52とPDN GW53が別途ゲートウェイで構成されるものを示すが、二つのゲートウェイが単一ゲートウェイ構成オプション(Single Gateway Configuration Option)によって具現されることもできる。

MME51は、UEのネットワーク連結に対するアクセスネットワークリソース割当トラッキング(tracking)、ページング(paging)、ローミング(roaming)及びハンドオーバなどをサポートするためのシグナリング及び制御機能を実行する要素である。MME51は、加入者及びセッション管理に関連した制御平面(control plane)機能を制御する。MME51は、数多くのeNodeB22を管理し、他の2G/3Gネットワークに対するハンドオーバのための従来のゲートウェイの選択のためのシグナリングを実行する。また、MME51は、セキュリティ過程(Security Procedures)、端末−対−ネットワークセッションハンドリング(Terminal−to−network Session Handling)、アイドル端末位置決定管理(Idle Terminal Location Management)などの機能を遂行する。

SGSNは、異なるアクセス3GPPネットワーク(例えば、GPRSネットワーク、UTRAN/GERAN)に対するユーザの移動性管理及び認証(authentication)といった全てのパケットデータをハンドリングする。

ePDGは、信頼されない非3GPPネットワーク(例えば、I−WLAN、WiFiホットスポット(hotspot)等)に対するセキュリティノードとしての役割をする。

図1を参照して説明したように、IP能力を有する端末(または、UE)は、3GPPアクセスはもちろん非3GPPアクセスに基づいても、EPC内の多様な要素を経由して事業者(即ち、オペレータ(operator))が提供するIPサービスネットワーク(例えば、IMS)にアクセスすることができる。

また、図1は、多様なレファレンスポイント(例えば、S1−U、S1−MME等)を示す。3GPPシステムでは、E−UTRAN及びEPCの異なる機能エンティティ(functional entity)に存在する2個の機能を連結する概念的なリンクをレファレンスポイント(reference point)と定義する。以下の表1は、図1に示すレファレンスポイントを整理したものである。表1の例示外にもネットワーク構造によって多様なレファレンスポイントが存在できる。

図1に示すレファレンスポイントのうち、S2a及びS2bは、非3GPPインターフェースに該当する。S2aは、信頼される非3GPPアクセス及びPDNGW間の関連制御及び移動性サポートをユーザ平面に提供するレファレンスポイントである。S2bは、ePDG及びPDNGW間の関連制御及び移動性サポートをユーザ平面に提供するレファレンスポイントである。

図2は、一般的にE−UTRANと一般的なEPCのアーキテクチャを示す例示図である。

図示されたように、eNodeB20は、RRC接続活性化されている中、ゲートウェイへのルーティング、ページングメッセージスケジューリング及び送信、ブロードキャスタチャネル(BCH)のスケジューリング及び送信、アップリンク及びダウンリンクでのリソースをUEに動的割当、eNodeB20の測定のための設定及び提供、無線ベアラ制御、無線許可制御(radio admission control)、そして、接続移動性制御などのための機能を遂行することができる。EPC内では、ページング発生、LTE_IDLE状態管理、ユーザ平面の暗号化、EPSベアラ制御、NASシグナリングの暗号化及び完全性保護機能を遂行することができる。

図3は、UEとeNodeBとの間の制御平面での無線インターフェースプロトコル(Radio Interface Protocol)の構造を示す例示図であり、図4は、端末と基地局との間のユーザ平面での無線インターフェースプロトコル(Radio Interface Protocol)の構造を示す他の例示図である。

前記無線インターフェースプロトコルは、3GPP無線アクセスネットワーク規格に基盤とする。前記無線インターフェースプロトコルは、水平的には物理階層(Physical Layer)、データリンク階層(Data Link Layer)、及びネットワーク階層(Network Layer)からなり、垂直的にはデータ情報送信のためのユーザ平面(User Plane)と、制御信号(Signaling)伝達のための制御平面(Control Plane)とに区分される。

前記プロトコル階層は、通信システムで広く知られた開放型システム間相互接続(Open System Interconnection;OSI)基準モデルの下位3個階層に基づいてL1(第1の階層)、L2(第2の階層)、L3(第3の階層)に区分されることができる。

以下、前記図3に示す制御平面での無線プロトコルと図4に示すユーザ平面での無線プロトコルの各階層を説明する。

第1の階層である物理階層は、物理チャネル(Physical Channel)を利用して情報転送サービス(Information Transfer Service)を提供する。前記物理階層は、上位にある媒体アクセス制御(Medium Access Control)階層とはトランスポートチャネル(Transport Channel)を介して連結されており、前記トランスポートチャネルを介して媒体アクセス制御階層と物理階層との間のデータが伝達される。そして、互いに異なる物理階層間、即ち、送信側と受信側の物理階層間は、物理チャネルを介してデータが伝達される。

物理チャネル(Physical Channel)は、時間軸上にある複数個サブフレームと、周波数軸上にある複数個のサブキャリア(Sub−carrier)とで構成される。ここで、一つのサブフレーム(Sub−frame)は、時間軸上に複数のシンボル(Symbol)と複数のサブキャリアとで構成される。一つのサブフレームは、複数のリソースブロック(Resource Block)で構成され、一つのリソースブロックは、複数のシンボル(Symbol)と複数のサブキャリアとで構成される。データが送信される単位時間であるTTI(Transmission Time Interval)は、1個のサブフレームに該当する1msである。

前記送信側と受信側の物理階層に存在する物理チャネルは、3GPPLTEによると、データチャネルであるPDSCH(Physical Downlink Shared Channel)及びPUSCH(Physical Uplink Shared Channel)と、制御チャネルであるPDCCH(Physical Downlink Control Channel)、PCFICH(Physical Control Format Indicator Channel)、PHICH(Physical Hybrid−ARQIndicator Channel)及びPUCCH(Physical Uplink Control Channel)と、に分けられる。

サブフレームの1番目OFDMシンボルで送信されるPCFICHは、サブフレーム内で制御チャネルの送信に使われるOFDMシンボルの数(即ち、制御領域の大きさ)に対するCFI(control format indicator)を伝送する。無線機器は、まず、PCFICH上にCFIを受信した後、PDCCHをモニタリングする。

PDCCHと違って、PCFICHは、ブラインドデコーディングを使用せずに、サブフレームの固定されたPCFICHリソースを介して送信される。

PHICHは、ULHARQ(hybrid automatic repeat request)のためのACK(positive−acknowledgement)/NACK(negative−acknowledgement)信号を伝送する。無線機器により送信されるPUSCH上のUL(uplink)データに対するACK/NACK信号は、PHICH上に送信される。

PBCH(Physical Broadcast Channel)は、無線フレームの1番目のサブフレームの第2のスロットの前方部の4個のOFDMシンボルで送信される。PBCHは、無線機器が基地局と通信するときに必須なシステム情報を伝送し、PBCHを介して送信されるシステム情報をMIB(master information block)という。これと比較して、PDCCHにより指示されるPDSCH上に送信されるシステム情報をSIB(system information block)という。

PDCCHは、DL−SCH(downlink−shared channel)のリソース割当及び送信フォーマット、UL−SCH(uplink shared channel)のリソース割当情報、PCH上のページング情報、DL−SCH上のシステム情報、PDSCH上に送信されるランダムアクセス応答のような上位階層制御メッセージのリソース割当、任意のUEグループ内の個別UEに対する送信パワー制御命令のセット及びVoIP(voice over internet protocol)の活性化などを伝送することができる。複数のPDCCHが制御領域内で送信されることができ、端末は、複数のPDCCHをモニタリングすることができる。PDCCHは、一つまたは複数個の連続的なCCE(control channel elements)のアグリゲーション(aggregation)上に送信される。CCEは、無線チャネルの状態による符号化率をPDCCHに提供するために使われる論理割当単位である。CCEは、複数のリソース要素グループ(resource element group)に対応される。CCEの数とCCEにより提供される符号化率の関係によってPDCCHのフォーマット及び可能なPDCCHのビット数が決定される。

PDCCHを介して送信される制御情報ダウンリンク制御情報(downlink control information、DCI)という。DCIは、PDSCHのリソース割当(これをDLグラント(downlink grant)ともいう)、PUSCHのリソース割当(これをULグラント(uplink grant)ともいう)、任意のUEグループ内の個別UEに対する送信パワー制御命令のセット及び/またはVoIP(Voice over Internet Protocol)の活性化を含むことができる。

第2の階層にはさまざまな階層が存在する。まず、媒体アクセス制御(Medium Access Control;MAC)階層は、多様な論理チャネル(Logical Channel)を多様なトランスポートチャネルにマッピングさせる役割をし、また、複数の論理チャネルを一つのトランスポートチャネルにマッピングさせる論理チャネル多重化(Multiplexing)の役割を遂行する。MAC階層は、上位階層であるRLC階層とは論理チャネル(Logical Channel)を介して接続されており、論理チャネルは、大いに、送信される情報の種類によって、制御平面(Control Plane)の情報を送信する制御チャネル(Control Channel)と、ユーザ平面(User Plane)の情報を送信するトラフィックチャネル(Traffic Channel)と、に分けられる。

第2の階層の無線リンク制御(Radio Link Control;RLC)階層は、上位階層から受信したデータを分割(Segmentation)及び連結(Concatenation)して下位階層無線区間へのデータの送信に適合するようにデータの大きさを調節する役割を遂行する。また、各々の無線ベアラ(Radio Bearer;RB)が要求する多様なQoSが保障可能にするために、TM(Transparent Mode、透明モード)、UM(Un−acknowledged Mode、無応答モード)、及びAM(Acknowledged Mode、応答モード)の三つの動作モードを提供している。特に、AM RLCは、信頼性のあるデータ送信のために、自動反復及び要求(Automatic Repeat and Request;ARQ)機能を介した再送信機能を遂行している。

第2の階層のパケットデータ収束(Packet Data Convergence Protocol;PDCP)階層は、IPv4やIPv6のようなIPパケット送信時、帯域幅が小さい無線区間で効率的に送信するために相対的に大きさが大きくて不要な制御情報を含んでいるIPパケットヘッダサイズを減らすヘッダ圧縮(Header Compression)機能を遂行する。これはデータのヘッダ(Header)部分で必ず必要な情報のみを送信するようにすることで、無線区間の送信効率を増加させる役割をする。また、LTEシステムでは、PDCP階層がセキュリティ(Security)機能も実行し、これは第3者のデータ盗聴を防止する暗号化(Ciphering)と第3者のデータ操作を防止する完全性保護(Integrity protection)とで構成される。

第3階層の最も上部に位置した無線リソース制御(Radio Resource Control;以下、RRCと略称する)階層は、制御平面でのみ定義され、無線ベアラ(Radio Bearer;RBと略称する)の設定(Configuration)、再設定(Re−configuration)及び解除(Release)と関連して論理チャネル、トランスポートチャネル、及び物理チャネルの制御を担当する。このとき、RBは、端末とE−UTRANとの間のデータ伝達のために、第2の階層により提供されるサービスを意味する。

前記端末のRRCと無線ネットワークのRRC階層との間にRRC接続(RRC connection)がある場合、端末は、RRC接続状態(Connected Mode)になり、そうでない場合、RRCアイドル状態(Idle Mode)になる。

以下、端末の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を構成することができる。

ユーザが端末の電源を最初にオンした時、端末は、まず、適切なセルを探索した後、該当セルで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からページングメッセージを受信した場合、これに対する応答メッセージ送信などを挙げることができる。

前記RRC階層の上位に位置するNAS(Non−Access Stratum)階層は、セッション管理(Session Management)と移動性管理(Mobility Management)等の機能を遂行する。

以下、図3に示すNAS階層に対して詳細に説明する。

NAS階層に属するESM(Evolved Session Management)は、Default Bearer管理及びDedicated Bearer管理のような機能を遂行し、端末がネットワークからPSサービスを利用するための制御を担当する。Default Bearerリソースは、特定Packet Data Network(PDN)に最初接続する時またはネットワークに接続される時、ネットワークから割当を受けるという特徴を有する。このとき、ネットワークは、端末がデータサービスを使用することができるように端末が使用可能なIPアドレス割り当て、また、default bearerのQoSを割り当てる。LTEでは、大いに、データ送受信のための特定帯域幅を保障するGBR(Guaranteed bit rate)QoS特性を有するbearerと、帯域幅の保障無しでBest effort QoS特性を有するNon−GBR bearerの2種類をサポートする。Default bearerの場合、Non−GBR bearerの割当を受ける。Dedicated bearerの場合は、GBRまたはNon−GBRのQoS特性を有するbearerの割当を受けることができる。

ネットワークから端末に割り当てたbearerをEPS(evolved packet service)bearerといい、EPS bearerを割当する時、ネットワークは、一つのIDを割り当てるようになる。これをEPS Bearer IDという。一つのEPS bearerは、MBR(maximum bit rate)とGBR(guaranteed bit rate)またはAMBR(Aggregated maximum bit rate)のQoS特性を有する。

一方、図3において、NAS階層下に位置するRRC階層、RLC階層、MAC階層、PHY階層を束ねアクセス階層(Access Stratum:AS)とも呼ばれる。

図5aは、3GPPLTEでランダムアクセス過程を示す流れ図である。

ランダムアクセス過程は、UE10が基地局、即ち、eNodeB20とUL同期を得たり、UL無線リソースの割当を受けたりするために使われる。

UE10は、ルートインデックス(root index)とPRACH(physical random access channel)設定インデックス(configuration index)をeNodeB20から受信する。各セル毎にZC(Zadoff−Chu)シーケンスにより定義される64個の候補(candidate)ランダムアクセスプリアンブルがあり、ルートインデックスは、端末が64個の候補ランダムアクセスプリアンブルを生成するための論理的インデックスである。

ランダムアクセスプリアンブルの送信は、各セル毎に特定時間及び周波数リソースに限定される。PRACH設定インデックスは、ランダムアクセスプリアンブルの送信が可能な特定サブフレームプリアンブルフォーマットを指示する。

UE10は、任意に選択されたランダムアクセスプリアンブルをeNodeB20に送信する。UE10は、64個の候補ランダムアクセスプリアンブルの中から一つを選択する。そして、PRACH設定インデックスにより該当するサブフレームを選択する。UE10は、選択されたランダムアクセスプリアンブルを選択されたサブフレームで送信する。

前記ランダムアクセスプリアンブルを受信したeNodeB20は、ランダムアクセス応答(random access response、RAR)をUE10に送る。ランダムアクセス応答は、2ステップに検出される。まず、UE10は、RA−RNTI(random access−RNTI)でマスキングされたPDCCHを検出する。UE10は、検出されたPDCCHにより指示されるPDSCH上にMAC(Medium Access Control)PDU(Protocol Data Unit)内のランダムアクセス応答を受信する。

図5bは、無線リソース制御(RRC)階層での接続過程を示す。

図5bに示すように、RRC接続可否によるRRC状態が示されている。前記RRC状態とは、UE10のRRC階層のエンティティ(entity)がeNodeB20のRRC階層のエンティティと論理的接続(logical connection)されているかどうかを意味し、接続されている場合をRRC接続状態(connected state)といい、接続されていない状態をRRCアイドル状態(idle state)という。

前記接続状態(Connected state)のUE10は、RRC接続(connection)が存在するため、E−UTRANは、該当端末の存在をセル単位で把握することができ、したがって、UE10を効果的に制御することができる。それに対し、アイドル状態(idle state)のUE10は、eNodeB20が把握することはできず、セルより大きい地域単位であるトラッキング地域(Tracking Area)単位に核心ネットワーク(Core Network)が管理する。前記トラッキング地域(Tracking Area)は、セルの集合単位である。即ち、アイドル状態(idle state)のUE10は、大きい地域単位に存在可否のみが把握され、音声やデータのような通常の移動通信サービスを受けるために、端末は、接続状態(connected state)に切り替えしなければならない。

ユーザがUE10の電源を最初にオンにした時、前記UE10は、まず、適切なセルを探索した後、該当セルでアイドル状態(idle state)にとどまる。前記アイドル状態(idle state)のUE10は、RRC接続を確立する必要がある時になって初めてRRC接続過程(RRC connection procedure)を介してeNodeB20のRRC階層とRRC接続を確立することでRRC接続状態(connected state)に切り替える。

前記アイドル状態(Idle state)の端末がRRC接続を確立する必要がある場合は多様であり、例えば、ユーザの通話試みまたはアップリンクデータ送信などが必要な場合、またはEUTRANからページングメッセージを受信した場合、これに対する応答メッセージ送信などを挙げることができる。

アイドル状態(idle state)のUE10が前記eNodeB20とRRC接続を確立するためには、前記したように、RRC接続過程(RRC connection procedure)を進行しなければならない。RRC接続過程は、大いに、UE10がeNodeB20にRRC接続要求(RRC connection request)メッセージ送信する過程、eNodeB20がUE10にRRC接続設定(RRC connection setup)メッセージを送信する過程、そしてUE10がeNodeB20にRRC接続設定完了(RRC connection setup complete)メッセージを送信する過程を含む。このような過程に対して図5bを参照してより詳細に説明すると、下記の通りである。

1)アイドル状態(Idle state)のUE10は、通話試み、データ送信試み、またはeNodeB20のページングに対する応答などの理由でRRC接続を確立しようとする場合、まず、前記UE10は、RRC接続要求(RRC connection request)メッセージをeNodeB20に送信する。

2)前記UE10からRRC接続要求メッセージを受信すると、前記eNB20は、無線リソースが十分な場合、前記UE10のRRC接続要求を受諾し、応答メッセージであるRRC接続設定(RRC connection setup)メッセージを前記UE10に送信する。

3)前記UE10が前記RRC接続設定メッセージを受信すると、前記eNodeB20にRRC接続設定完了(RRC connection setup complete)メッセージを送信する。前記UE10がRRC接続設定メッセージを成功的に送信すると、そのとき、前記UE10は、eNodeB20とRRC接続を確立するようになってRRC接続モードに切り替える。

一方、UE10がユーザ平面のデータ送信を目的としてRRC接続要求をする時、前記ネットワーク、例えば、基地局(即ち、eNodeB)が混雑状態の場合はこれを拒絶することができる。

他の一方、最近、MMTel(Multimedia Telephony service)が多く研究された。前記MMTelは、IMS(IP Multimedia Subsystem)に基づくグローバル標準であって、集中的(converged)、固定的(fixed)モバイルリアルタイムマルチメディア通信を提供し、これを介して音声、リアルタイムビデオテキストファイル送信などのようなメディア能力(media capabilities)を使用し、及び写真オーディオビデオクリップなどを共有することができる。MMTelにおいて、ユーザは、セッション中にメディアを追加したり、または除外したりすることができる。即ち、セッション中にチャット、音声追加、他の発信者追加、ビデオ追加、メディア共有及びファイル送信、並びにこれらのうち特定能力に対する除去が可能である。

しかし、UEがMMTelを実行することを希望する時、ネットワーク、例えば、基地局(即ち、eNodeB)が混雑状態の場合はサービスを実行することができないという問題点がある。

概要

本明細書の一開示は、ユーザ装置(user equipment:UE)におけるサービス要求手順(Service Request procedure)を実行する方法を提供する。前記方法は、ACB(access class barring)により発信呼び(originating call)のためのアクセスを前記UEの下位階層が遮断するステップ;アップリンクデータのための要求により上位階層からの開始インジケーションを前記UEのNAS階層が受信するステップ;及び、前記下位階層は、前記発信呼びに対する前記アクセスが遮断されたと指示したが、前記NAS階層は、前記開始インジケーションを受信した場合、前記NAS階層は、サービス要求手順を開始するステップ;を含む。a

目的

3GPP SA WG2を中心に進行されたSAEは、3GPP TSG RANのLTE作業と並行してネットワークの構造を決定し、異機種ネットワーク間の移動性をサポートすることを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ユーザ装置(userequipment:UE)におけるサービス要求手順(ServiceRequestprocedure)を実行する方法であって、ACB(accessclassbarring)により発信呼び(originatingcall)のためのアクセスを前記UEの下位階層遮断するステップアップリンクデータのための要求により上位階層からの開始インジケーションを前記UEのNAS階層が受信するステップ;及び、前記下位階層は、前記発信呼びに対する前記アクセスが遮断されたと指示したが、前記NAS階層は、前記開始インジケーションを受信した場合、前記NAS階層は、サービス要求手順を開始するステップ;を含み、前記サービス要求手順を開始するステップは、サービス要求メッセージまたは拡張サービス要求メッセージを送信するために設定された呼びタイプを下位階層に伝達するステップを含み、前記呼びタイプ(calltype)は、発信(originating)MMTEL音声、発信(originating)MMTEL映像、発信(originating)SMS(shortmessageservice)overIPまたは発信SMSのうちいずれか一つに設定されることを特徴とするサービス要求手順実行方法

請求項2

前記アップリンクデータに対する要求は、IP(InternetProtocol)を介した発信(originating)メッセージの送信に対する要求に該当することを特徴とする請求項1に記載のサービス要求手順実行方法。

請求項3

前記IPを介した発信メッセージの送信に対する要求が受信され、IPを介した他の発信メッセージは存在しない場合、前記NAS階層が前記上位階層から前記開始インジケーションを受信することを特徴とする請求項2に記載のサービス要求手順実行方法。

請求項4

前記アップリンクデータに対する前記要求は、発信(originating)MMTEL(multimediatelephony)通信セッション確立、そして発信(originating)SMS(shortmessageservice)overIP通信セッションの確立に対する要求に該当することを特徴とする請求項1に記載のサービス要求手順実行方法。

請求項5

前記MMTEL通信セッション内で音声(voice)が提供され、または前記MMTEL通信セッション内で映像(video)が提供される場合、そして前記SMSoverIPが提供される場合、前記NAS階層が前記上位階層から前記開始インジケーションを受信することを特徴とする請求項4に記載のサービス要求手順実行方法。

請求項6

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面無線リソースを要求するためのものである場合、そしてMMTEL音声呼び(call)が開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)MMTEL音声に設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項1に記載のサービス要求手順実行方法。

請求項7

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてMMTEL映像呼び(call)が開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)MMTEL映像に設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項1に記載のサービス要求手順実行方法。

請求項8

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてSMSoverIPが開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)SMSoverIPに設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項1に記載のサービス要求手順実行方法。

請求項9

前記サービス要求メッセージまたは拡張サービス要求メッセージがSMS(SMSoverNAS)のためのアップリンクシグナリング(ULsignaling)のためのリソースを要求するためのものである場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)SMS(SMSoverNAS)に設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項1に記載のサービス要求手順実行方法。

請求項10

前記サービス要求メッセージは、サービスタイプフィールドを含み、前記サービスタイプフィールドは、MOMMTELvoice、MOMMTELvideo、MOSMSoverIP、またはMOSMS(SMSoverNAS)に設定されることを特徴とする請求項1に記載のサービス要求手順実行方法。

請求項11

サービス要求手順(ServiceRequestprocedure)を実行するユーザ装置(userequipment:UE)であって、送受信部;及び、前記送受信部を制御するプロセッサ;を含み、前記プロセッサは:ACB(accessclassbarring)により発信呼び(originatingcall)のためのアクセスを遮断する下位階層;及び、アップリンクデータのための要求により上位階層から開始インジケーションを受信するNAS階層;を含み、前記下位階層は、前記発信呼びに対する前記アクセスが遮断されたと指示したが、前記NAS階層は、前記開始インジケーションを受信した場合、前記NAS階層は、サービス要求手順の開始のためのサービス要求メッセージまたは拡張サービス要求メッセージを送信するために設定された呼びタイプを下位階層に伝達し、前記呼びタイプ(calltype)は、発信(originating)MMTEL音声、発信(originating)MMTEL映像、発信(originating)SMS(shortmessageservice)overIPまたは発信SMSのうちいずれか一つに設定されることを特徴とするユーザ装置。

請求項12

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてMMTEL音声呼び(call)が開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)MMTEL音声に設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項11に記載のユーザ装置。

請求項13

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてMMTEL映像呼び(call)が開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)MMTEL映像に設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項11に記載のユーザ装置。

請求項14

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてSMSoverIPが開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)SMSoverIPに設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項11に記載のユーザ装置。

請求項15

前記サービス要求メッセージまたは拡張サービス要求メッセージがSMS(SMSoverNAS)のためのアップリンクシグナリング(ULsignaling)のためのリソースを要求するためのものである場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)SMS(SMSoverNAS)に設定された呼びタイプ(calltype)フィールドと、MOdataに設定された確立原因(establishcause)フィールドと、を含むことを特徴とする請求項11に記載のユーザ装置。

請求項16

前記サービス要求メッセージは、サービスタイプフィールドを含み、前記サービスタイプフィールドは、MOMMTELvoice、MOMMTELvideo、MOSMSoverIP、またはMOSMS(SMSoverNAS)に設定されることを特徴とする請求項11に記載のユーザ装置。

技術分野

0001

本発明は、移動通信に関する。

背景技術

0002

移動通信システムの技術規格を制定する3GPPでは、4世代移動通信と関連した多様なフォーラム及び新しい技術に対応するために、2004年末から3GPP技術の性能を最適化させて向上させようとする努力一環としてLTE/SAE(Long Term Evolution/System Architecture Evolution)技術に対する研究を始めた。

0003

3GPP SA WG2を中心に進行されたSAEは、3GPP TSG RANのLTE作業と並行してネットワークの構造を決定し、異機種ネットワーク間の移動性サポートすることを目的とするネットワーク技術に対する研究であって、最近3GPPの重要な標準化問題のうち一つである。これは3GPPシステムIPベースの多様な無線接続技術をサポートするシステムに発展させるための作業であって、より向上したデータ送信能力送信遅延を最小化する、最適化されたパケットベースのシステムを目標にして作業が進行されてきた。

0004

3GPP SA WG2で定義したEPS(Evolved Packet System)上位水準参照モデル(reference model)は、非ローミングケース(non−roaming case)及び多様なシナリオローミングケース(roaming case)を含んでおり、詳細内容は、3GPP標準文書TS23.401とTS23.402で参照することができる。図1ネットワーク構造図は、これを簡略に再構成したものである。

0005

図1は、進化した移動通信ネットワークの構造図である。

0006

EPCは、多様な構成要素を含むことができ、図1は、そのうち一部に該当する、S−GW(Serving Gateway)52、PDN GW(Packet Data Network Gateway)53、MME(Mobility Management Entity)51、SGSN(Serving GPRS(General Packet Radio Service) Supporting Node)、ePDG(enhanced Packet Data Gateway)を示す。

0007

S−GW52は、無線アクセスネットワーク(RAN)とコアネットワークとの間の境界点として動作し、eNodeB22とPDN GW53との間のデータ経路を維持する機能をする要素である。また、端末(または、User Equipment:UE)がeNodeB22によりサービング(serving)される領域にわたって移動する場合、S−GW52は、ローカル移動性アンカポイント(anchor point)の役割をする。即ち、E−UTRAN(3GPPリリース8以後で定義されるEvolved−UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access Network)内での移動性のために、S−GW52を介してパケットルーティングされることができる。また、S−GW52は、他の3GPPネットワーク(3GPPリリース8以前に定義されるRAN、例えば、UTRANまたはGERAN(GSM登録商標)(Global System for Mobile Communication)/EDGE(Enhanced Data rates for Global Evolution) Radio Access Network)との移動性のためのアンカーポイントとして機能することもできる。

0008

PDN GW(または、P−GW)53は、パケットデータネットワークに向かうデータインターフェース終端点(termination point)に該当する。PDN GW53は、政策執行特徴(policy enforcement features)、パケットフィルタリング(packet filtering)、課金サポート(charging support)などをサポートすることができる。また、3GPPネットワークと非3GPPネットワーク(例えば、I−WLAN(Interworking Wireless Local Area Network)のような信頼されないネットワーク、CDMA(Code Division Multiple Access)ネットワークやWiMaxのような信頼されるネットワーク)との移動性管理のためのアンカーポイント役割をすることができる。

0009

図1のネットワーク構造の例示は、S−GW52とPDN GW53が別途ゲートウェイで構成されるものを示すが、二つのゲートウェイが単一ゲートウェイ構成オプション(Single Gateway Configuration Option)によって具現されることもできる。

0010

MME51は、UEのネットワーク連結に対するアクセスネットワークリソース割当トラッキング(tracking)、ページング(paging)、ローミング(roaming)及びハンドオーバなどをサポートするためのシグナリング及び制御機能を実行する要素である。MME51は、加入者及びセッション管理に関連した制御平面(control plane)機能を制御する。MME51は、数多くのeNodeB22を管理し、他の2G/3Gネットワークに対するハンドオーバのための従来のゲートウェイの選択のためのシグナリングを実行する。また、MME51は、セキュリティ過程(Security Procedures)、端末−対−ネットワークセッションハンドリング(Terminal−to−network Session Handling)、アイドル端末位置決定管理(Idle Terminal Location Management)などの機能を遂行する。

0011

SGSNは、異なるアクセス3GPPネットワーク(例えば、GPRSネットワーク、UTRAN/GERAN)に対するユーザの移動性管理及び認証(authentication)といった全てのパケットデータをハンドリングする。

0012

ePDGは、信頼されない非3GPPネットワーク(例えば、I−WLAN、WiFiホットスポット(hotspot)等)に対するセキュリティノードとしての役割をする。

0013

図1を参照して説明したように、IP能力を有する端末(または、UE)は、3GPPアクセスはもちろん非3GPPアクセスに基づいても、EPC内の多様な要素を経由して事業者(即ち、オペレータ(operator))が提供するIPサービスネットワーク(例えば、IMS)にアクセスすることができる。

0014

また、図1は、多様なレファレンスポイント(例えば、S1−U、S1−MME等)を示す。3GPPシステムでは、E−UTRAN及びEPCの異なる機能エンティティ(functional entity)に存在する2個の機能を連結する概念的なリンクをレファレンスポイント(reference point)と定義する。以下の表1は、図1に示すレファレンスポイントを整理したものである。表1の例示外にもネットワーク構造によって多様なレファレンスポイントが存在できる。

0015

0016

図1に示すレファレンスポイントのうち、S2a及びS2bは、非3GPPインターフェースに該当する。S2aは、信頼される非3GPPアクセス及びPDNGW間の関連制御及び移動性サポートをユーザ平面に提供するレファレンスポイントである。S2bは、ePDG及びPDNGW間の関連制御及び移動性サポートをユーザ平面に提供するレファレンスポイントである。

0017

図2は、一般的にE−UTRANと一般的なEPCのアーキテクチャを示す例示図である。

0018

図示されたように、eNodeB20は、RRC接続活性化されている中、ゲートウェイへのルーティング、ページングメッセージスケジューリング及び送信、ブロードキャスタチャネル(BCH)のスケジューリング及び送信、アップリンク及びダウンリンクでのリソースをUEに動的割当、eNodeB20の測定のための設定及び提供、無線ベアラ制御、無線許可制御(radio admission control)、そして、接続移動性制御などのための機能を遂行することができる。EPC内では、ページング発生、LTE_IDLE状態管理、ユーザ平面の暗号化、EPSベアラ制御、NASシグナリングの暗号化及び完全性保護機能を遂行することができる。

0019

図3は、UEとeNodeBとの間の制御平面での無線インターフェースプロトコル(Radio Interface Protocol)の構造を示す例示図であり、図4は、端末と基地局との間のユーザ平面での無線インターフェースプロトコル(Radio Interface Protocol)の構造を示す他の例示図である。

0020

前記無線インターフェースプロトコルは、3GPP無線アクセスネットワーク規格に基盤とする。前記無線インターフェースプロトコルは、水平的には物理階層(Physical Layer)、データリンク階層(Data Link Layer)、及びネットワーク階層(Network Layer)からなり、垂直的にはデータ情報送信のためのユーザ平面(User Plane)と、制御信号(Signaling)伝達のための制御平面(Control Plane)とに区分される。

0021

前記プロトコル階層は、通信システムで広く知られた開放型システム間相互接続(Open System Interconnection;OSI)基準モデルの下位3個階層に基づいてL1(第1の階層)、L2(第2の階層)、L3(第3の階層)に区分されることができる。

0022

以下、前記図3に示す制御平面での無線プロトコル図4に示すユーザ平面での無線プロトコルの各階層を説明する。

0023

第1の階層である物理階層は、物理チャネル(Physical Channel)を利用して情報転送サービス(Information Transfer Service)を提供する。前記物理階層は、上位にある媒体アクセス制御(Medium Access Control)階層とはトランスポートチャネル(Transport Channel)を介して連結されており、前記トランスポートチャネルを介して媒体アクセス制御階層と物理階層との間のデータが伝達される。そして、互いに異なる物理階層間、即ち、送信側と受信側の物理階層間は、物理チャネルを介してデータが伝達される。

0024

物理チャネル(Physical Channel)は、時間軸上にある複数個サブフレームと、周波数軸上にある複数個のサブキャリア(Sub−carrier)とで構成される。ここで、一つのサブフレーム(Sub−frame)は、時間軸上に複数のシンボル(Symbol)と複数のサブキャリアとで構成される。一つのサブフレームは、複数のリソースブロック(Resource Block)で構成され、一つのリソースブロックは、複数のシンボル(Symbol)と複数のサブキャリアとで構成される。データが送信される単位時間であるTTI(Transmission Time Interval)は、1個のサブフレームに該当する1msである。

0025

前記送信側と受信側の物理階層に存在する物理チャネルは、3GPPLTEによると、データチャネルであるPDSCH(Physical Downlink Shared Channel)及びPUSCH(Physical Uplink Shared Channel)と、制御チャネルであるPDCCH(Physical Downlink Control Channel)、PCFICH(Physical Control Format Indicator Channel)、PHICH(Physical Hybrid−ARQIndicator Channel)及びPUCCH(Physical Uplink Control Channel)と、に分けられる。

0026

サブフレームの1番目OFDMシンボルで送信されるPCFICHは、サブフレーム内で制御チャネルの送信に使われるOFDMシンボルの数(即ち、制御領域の大きさ)に対するCFI(control format indicator)を伝送する。無線機器は、まず、PCFICH上にCFIを受信した後、PDCCHをモニタリングする。

0027

PDCCHと違って、PCFICHは、ブラインドデコーディングを使用せずに、サブフレームの固定されたPCFICHリソースを介して送信される。

0028

PHICHは、ULHARQ(hybrid automatic repeat request)のためのACK(positive−acknowledgement)/NACK(negative−acknowledgement)信号を伝送する。無線機器により送信されるPUSCH上のUL(uplink)データに対するACK/NACK信号は、PHICH上に送信される。

0029

PBCH(Physical Broadcast Channel)は、無線フレームの1番目のサブフレームの第2のスロットの前方部の4個のOFDMシンボルで送信される。PBCHは、無線機器が基地局と通信するときに必須なシステム情報を伝送し、PBCHを介して送信されるシステム情報をMIB(master information block)という。これと比較して、PDCCHにより指示されるPDSCH上に送信されるシステム情報をSIB(system information block)という。

0030

PDCCHは、DL−SCH(downlink−shared channel)のリソース割当及び送信フォーマット、UL−SCH(uplink shared channel)のリソース割当情報、PCH上のページング情報、DL−SCH上のシステム情報、PDSCH上に送信されるランダムアクセス応答のような上位階層制御メッセージのリソース割当、任意のUEグループ内の個別UEに対する送信パワー制御命令のセット及びVoIP(voice over internet protocol)の活性化などを伝送することができる。複数のPDCCHが制御領域内で送信されることができ、端末は、複数のPDCCHをモニタリングすることができる。PDCCHは、一つまたは複数個の連続的なCCE(control channel elements)のアグリゲーション(aggregation)上に送信される。CCEは、無線チャネルの状態による符号化率をPDCCHに提供するために使われる論理割当単位である。CCEは、複数のリソース要素グループ(resource element group)に対応される。CCEの数とCCEにより提供される符号化率の関係によってPDCCHのフォーマット及び可能なPDCCHのビット数が決定される。

0031

PDCCHを介して送信される制御情報ダウンリンク制御情報(downlink control information、DCI)という。DCIは、PDSCHのリソース割当(これをDLグラント(downlink grant)ともいう)、PUSCHのリソース割当(これをULグラント(uplink grant)ともいう)、任意のUEグループ内の個別UEに対する送信パワー制御命令のセット及び/またはVoIP(Voice over Internet Protocol)の活性化を含むことができる。

0032

第2の階層にはさまざまな階層が存在する。まず、媒体アクセス制御(Medium Access Control;MAC)階層は、多様な論理チャネル(Logical Channel)を多様なトランスポートチャネルにマッピングさせる役割をし、また、複数の論理チャネルを一つのトランスポートチャネルにマッピングさせる論理チャネル多重化(Multiplexing)の役割を遂行する。MAC階層は、上位階層であるRLC階層とは論理チャネル(Logical Channel)を介して接続されており、論理チャネルは、大いに、送信される情報の種類によって、制御平面(Control Plane)の情報を送信する制御チャネル(Control Channel)と、ユーザ平面(User Plane)の情報を送信するトラフィックチャネル(Traffic Channel)と、に分けられる。

0033

第2の階層の無線リンク制御(Radio Link Control;RLC)階層は、上位階層から受信したデータを分割(Segmentation)及び連結(Concatenation)して下位階層無線区間へのデータの送信に適合するようにデータの大きさを調節する役割を遂行する。また、各々の無線ベアラ(Radio Bearer;RB)が要求する多様なQoSが保障可能にするために、TM(Transparent Mode、透明モード)、UM(Un−acknowledged Mode、無応答モード)、及びAM(Acknowledged Mode、応答モード)の三つの動作モードを提供している。特に、AM RLCは、信頼性のあるデータ送信のために、自動反復及び要求(Automatic Repeat and Request;ARQ)機能を介した再送信機能を遂行している。

0034

第2の階層のパケットデータ収束(Packet Data Convergence Protocol;PDCP)階層は、IPv4やIPv6のようなIPパケット送信時、帯域幅が小さい無線区間で効率的に送信するために相対的に大きさが大きくて不要な制御情報を含んでいるIPパケットヘッダサイズを減らすヘッダ圧縮(Header Compression)機能を遂行する。これはデータのヘッダ(Header)部分で必ず必要な情報のみを送信するようにすることで、無線区間の送信効率を増加させる役割をする。また、LTEシステムでは、PDCP階層がセキュリティ(Security)機能も実行し、これは第3者のデータ盗聴を防止する暗号化(Ciphering)と第3者のデータ操作を防止する完全性保護(Integrity protection)とで構成される。

0035

第3階層の最も上部に位置した無線リソース制御(Radio Resource Control;以下、RRCと略称する)階層は、制御平面でのみ定義され、無線ベアラ(Radio Bearer;RBと略称する)の設定(Configuration)、再設定(Re−configuration)及び解除(Release)と関連して論理チャネル、トランスポートチャネル、及び物理チャネルの制御を担当する。このとき、RBは、端末とE−UTRANとの間のデータ伝達のために、第2の階層により提供されるサービスを意味する。

0036

前記端末のRRCと無線ネットワークのRRC階層との間にRRC接続(RRC connection)がある場合、端末は、RRC接続状態(Connected Mode)になり、そうでない場合、RRCアイドル状態(Idle Mode)になる。

0037

以下、端末の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を構成することができる。

0038

ユーザが端末の電源を最初にオンした時、端末は、まず、適切なセルを探索した後、該当セルで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からページングメッセージを受信した場合、これに対する応答メッセージ送信などを挙げることができる。

0039

前記RRC階層の上位に位置するNAS(Non−Access Stratum)階層は、セッション管理(Session Management)と移動性管理(Mobility Management)等の機能を遂行する。

0040

以下、図3に示すNAS階層に対して詳細に説明する。

0041

NAS階層に属するESM(Evolved Session Management)は、Default Bearer管理及びDedicated Bearer管理のような機能を遂行し、端末がネットワークからPSサービスを利用するための制御を担当する。Default Bearerリソースは、特定Packet Data Network(PDN)に最初接続する時またはネットワークに接続される時、ネットワークから割当を受けるという特徴を有する。このとき、ネットワークは、端末がデータサービスを使用することができるように端末が使用可能なIPアドレス割り当て、また、default bearerのQoSを割り当てる。LTEでは、大いに、データ送受信のための特定帯域幅を保障するGBR(Guaranteed bit rate)QoS特性を有するbearerと、帯域幅の保障無しでBest effort QoS特性を有するNon−GBR bearerの2種類をサポートする。Default bearerの場合、Non−GBR bearerの割当を受ける。Dedicated bearerの場合は、GBRまたはNon−GBRのQoS特性を有するbearerの割当を受けることができる。

0042

ネットワークから端末に割り当てたbearerをEPS(evolved packet service)bearerといい、EPS bearerを割当する時、ネットワークは、一つのIDを割り当てるようになる。これをEPS Bearer IDという。一つのEPS bearerは、MBR(maximum bit rate)とGBR(guaranteed bit rate)またはAMBR(Aggregated maximum bit rate)のQoS特性を有する。

0043

一方、図3において、NAS階層下に位置するRRC階層、RLC階層、MAC階層、PHY階層を束ねアクセス階層(Access Stratum:AS)とも呼ばれる。

0044

図5aは、3GPPLTEでランダムアクセス過程を示す流れ図である。

0045

ランダムアクセス過程は、UE10が基地局、即ち、eNodeB20とUL同期を得たり、UL無線リソースの割当を受けたりするために使われる。

0046

UE10は、ルートインデックス(root index)とPRACH(physical random access channel)設定インデックス(configuration index)をeNodeB20から受信する。各セル毎にZC(Zadoff−Chu)シーケンスにより定義される64個の候補(candidate)ランダムアクセスプリアンブルがあり、ルートインデックスは、端末が64個の候補ランダムアクセスプリアンブルを生成するための論理的インデックスである。

0047

ランダムアクセスプリアンブルの送信は、各セル毎に特定時間及び周波数リソースに限定される。PRACH設定インデックスは、ランダムアクセスプリアンブルの送信が可能な特定サブフレームプリアンブルフォーマットを指示する。

0048

UE10は、任意に選択されたランダムアクセスプリアンブルをeNodeB20に送信する。UE10は、64個の候補ランダムアクセスプリアンブルの中から一つを選択する。そして、PRACH設定インデックスにより該当するサブフレームを選択する。UE10は、選択されたランダムアクセスプリアンブルを選択されたサブフレームで送信する。

0049

前記ランダムアクセスプリアンブルを受信したeNodeB20は、ランダムアクセス応答(random access response、RAR)をUE10に送る。ランダムアクセス応答は、2ステップに検出される。まず、UE10は、RA−RNTI(random access−RNTI)でマスキングされたPDCCHを検出する。UE10は、検出されたPDCCHにより指示されるPDSCH上にMAC(Medium Access Control)PDU(Protocol Data Unit)内のランダムアクセス応答を受信する。

0050

図5bは、無線リソース制御(RRC)階層での接続過程を示す。

0051

図5bに示すように、RRC接続可否によるRRC状態が示されている。前記RRC状態とは、UE10のRRC階層のエンティティ(entity)がeNodeB20のRRC階層のエンティティと論理的接続(logical connection)されているかどうかを意味し、接続されている場合をRRC接続状態(connected state)といい、接続されていない状態をRRCアイドル状態(idle state)という。

0052

前記接続状態(Connected state)のUE10は、RRC接続(connection)が存在するため、E−UTRANは、該当端末の存在をセル単位で把握することができ、したがって、UE10を効果的に制御することができる。それに対し、アイドル状態(idle state)のUE10は、eNodeB20が把握することはできず、セルより大きい地域単位であるトラッキング地域(Tracking Area)単位に核心ネットワーク(Core Network)が管理する。前記トラッキング地域(Tracking Area)は、セルの集合単位である。即ち、アイドル状態(idle state)のUE10は、大きい地域単位に存在可否のみが把握され、音声やデータのような通常の移動通信サービスを受けるために、端末は、接続状態(connected state)に切り替えしなければならない。

0053

ユーザがUE10の電源を最初にオンにした時、前記UE10は、まず、適切なセルを探索した後、該当セルでアイドル状態(idle state)にとどまる。前記アイドル状態(idle state)のUE10は、RRC接続を確立する必要がある時になって初めてRRC接続過程(RRC connection procedure)を介してeNodeB20のRRC階層とRRC接続を確立することでRRC接続状態(connected state)に切り替える。

0054

前記アイドル状態(Idle state)の端末がRRC接続を確立する必要がある場合は多様であり、例えば、ユーザの通話試みまたはアップリンクデータ送信などが必要な場合、またはEUTRANからページングメッセージを受信した場合、これに対する応答メッセージ送信などを挙げることができる。

0055

アイドル状態(idle state)のUE10が前記eNodeB20とRRC接続を確立するためには、前記したように、RRC接続過程(RRC connection procedure)を進行しなければならない。RRC接続過程は、大いに、UE10がeNodeB20にRRC接続要求(RRC connection request)メッセージ送信する過程、eNodeB20がUE10にRRC接続設定(RRC connection setup)メッセージを送信する過程、そしてUE10がeNodeB20にRRC接続設定完了(RRC connection setup complete)メッセージを送信する過程を含む。このような過程に対して図5bを参照してより詳細に説明すると、下記の通りである。

0056

1)アイドル状態(Idle state)のUE10は、通話試み、データ送信試み、またはeNodeB20のページングに対する応答などの理由でRRC接続を確立しようとする場合、まず、前記UE10は、RRC接続要求(RRC connection request)メッセージをeNodeB20に送信する。

0057

2)前記UE10からRRC接続要求メッセージを受信すると、前記eNB20は、無線リソースが十分な場合、前記UE10のRRC接続要求を受諾し、応答メッセージであるRRC接続設定(RRC connection setup)メッセージを前記UE10に送信する。

0058

3)前記UE10が前記RRC接続設定メッセージを受信すると、前記eNodeB20にRRC接続設定完了(RRC connection setup complete)メッセージを送信する。前記UE10がRRC接続設定メッセージを成功的に送信すると、そのとき、前記UE10は、eNodeB20とRRC接続を確立するようになってRRC接続モードに切り替える。

0059

一方、UE10がユーザ平面のデータ送信を目的としてRRC接続要求をする時、前記ネットワーク、例えば、基地局(即ち、eNodeB)が混雑状態の場合はこれを拒絶することができる。

0060

他の一方、最近、MMTel(Multimedia Telephony service)が多く研究された。前記MMTelは、IMS(IP Multimedia Subsystem)に基づくグローバル標準であって、集中的(converged)、固定的(fixed)モバイルリアルタイムマルチメディア通信を提供し、これを介して音声、リアルタイムビデオテキストファイル送信などのようなメディア能力(media capabilities)を使用し、及び写真オーディオビデオクリップなどを共有することができる。MMTelにおいて、ユーザは、セッション中にメディアを追加したり、または除外したりすることができる。即ち、セッション中にチャット、音声追加、他の発信者追加、ビデオ追加、メディア共有及びファイル送信、並びにこれらのうち特定能力に対する除去が可能である。

0061

しかし、UEがMMTelを実行することを希望する時、ネットワーク、例えば、基地局(即ち、eNodeB)が混雑状態の場合はサービスを実行することができないという問題点がある。

発明が解決しようとする課題

0062

したがって、本明細書の一開示は、前述した問題点を解決することができる方案提示することを目的とする。

課題を解決するための手段

0063

前記のような目的を達成するために、本明細書の一開示は、ユーザ装置(user equipment:UE)におけるサービス要求手順(Service Request procedure)を実行する方法を提供する。前記方法は、ACB(access class barring)により発信呼び(originating call)のためのアクセスを前記UEの下位階層が遮断するステップ;アップリンクデータのための要求により上位階層からの開始インジケーションを前記UEのNAS階層が受信するステップ;及び、前記下位階層は、前記発信呼びに対する前記アクセスが遮断されたと指示したが、前記NAS階層は、前記開始インジケーションを受信した場合、前記NAS階層は、サービス要求手順を開始するステップ;を含む。

0064

前記アップリンクデータに対する要求は:IP(Internet Protocol)を介した発信(originating)メッセージの送信に対する要求に該当する。

0065

前記IPを介した発信メッセージの送信に対する要求が受信され、IPを介した他の発信メッセージは存在しない場合、前記NAS階層が前記上位階層から前記開始インジケーションを受信する。

0066

前記アップリンクデータに対する前記要求は、発信(originating)MMTEL(multimedia telephony)通信セッションの確立、そして発信(originating)SMS(short message service)over IP通信セッションの確立に対する要求に該当する。

0067

前記MMTEL通信セッション内で音声(voice)が提供され、または前記MMTEL通信セッション内で映像(video)が提供される場合、そして前記SMS over IPが提供される場合、前記NAS階層が前記上位階層から前記開始インジケーションを受信する。

0068

前記サービス要求手順を開始するステップは:サービス要求メッセージまたは拡張サービス要求メッセージを送信するステップを含む。

0069

前記サービス要求メッセージまたは拡張サービス要求メッセージは、呼びタイプ(call type)フィールドを含む。前記呼びタイプ(call type)フィールドは、発信(originating)MMTEL音声、発信(originating)MMTEL映像、発信(originating)SMS(short message service)over IPまたは発信SMSのうちいずれか一つに設定される。

0070

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてMMTEL音声呼び(call)が開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)MMTEL音声に設定された呼びタイプ(call type)フィールドと、MO dataに設定された確立原因(establish cause)フィールドと、を含む。

0071

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてMMTEL映像呼び(call)が開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)MMTEL映像に設定された呼びタイプ(call type)フィールドと、MO dataに設定された確立原因(establish cause)フィールドと、を含む。

0072

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてSMS over IPが開始された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)SMS over IPに設定された呼びタイプ(call type)フィールドと、MO dataに設定された確立原因(establish cause)フィールドと、を含む。

0073

前記サービス要求メッセージまたは拡張サービス要求メッセージがSMS(SMS over NAS)のためのアップリンクシグナリング(UL signaling)のためのリソースを要求するためのものである場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは:発信(originating)SMS(SMS over NAS)に設定された呼びタイプ(call type)フィールドと、MO dataに設定された確立原因(establish cause)フィールドと、を含む。

0074

前記サービス要求メッセージは、サービスタイプフィールドを含む。ここで、前記サービスタイプフィールドは、MO MMTEL voice、MO MMTEL video、MOSMS over IP、またはMO SMS(SMS over NAS)に設定される。

0075

また、前記のような目的を達成するために、本明細書の一開示は、サービス要求手順(Service Request procedure)を実行するユーザ装置(user equipment:UE)を提供する。前記ユーザ装置は、送受信部;及び、前記送受信部を制御するプロセッサ;を含み、前記プロセッサは:ACB(access class barring)により発信呼び(originating call)のためのアクセスを遮断する下位階層;及び、アップリンクデータのための要求により上位階層から開始インジケーションを受信するNAS階層;を含む。ここで、前記下位階層は、前記発信呼びに対する前記アクセスが遮断されたと指示したが、前記NAS階層は、前記開始インジケーションを受信した場合、前記NAS階層は、サービス要求手順を開始する。

発明の効果

0076

本明細書の開示によると、前述した従来技術の問題点が解決される。

図面の簡単な説明

0077

進化した移動通信ネットワークの構造図である。

0078

一般的にE−UTRANと一般的なEPCのアーキテクチャを示す例示図である。

0079

UEとeNodeBとの間の制御平面での無線インターフェースプロトコル(Radio Interface Protocol)の構造を示す例示図である。

0080

端末と基地局との間のユーザ平面での無線インターフェースプロトコル(Radio Interface Protocol)の構造を示す他の例示図である。

0081

3GPPLTEでランダムアクセス過程を示す流れ図である。

0082

無線リソース制御(RRC)階層での接続過程を示す。

0083

ネットワーク過負荷状態を示す。

0084

ネットワーク混雑状態でアクセスクラスによる禁止(Access Class Barring)による動作を示す例示的な流れ図である。

0085

問題点を示す一例示図である。

0086

本明細書の提案1−1、1−2及び1−3を示す信号流れ図である。
本明細書の提案1−1、1−2及び1−3を示す信号流れ図である。

0087

本明細書の提案1−1を示す信号流れ図である。
本明細書の提案1−1を示す信号流れ図である。

0088

本明細書の提案2−1、2−2及び2−3を示す信号流れ図である。
本明細書の提案2−1、2−2及び2−3を示す信号流れ図である。

0089

本明細書の提案2−2を示す信号流れ図である。
本明細書の提案2−2を示す信号流れ図である。

0090

本明細書の提案3を示す信号流れ図である。
本明細書の提案3を示す信号流れ図である。

0091

本明細書の提案3の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案3の内容のうち、SMSに対する例を示す信号流れ図である。

0092

本明細書の提案4を示す信号流れ図である。
本明細書の提案4を示す信号流れ図である。

0093

本明細書の提案4の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案4の内容のうち、SMSに対する例を示す信号流れ図である。

0094

本明細書の提案5−1を示す信号流れ図である。
本明細書の提案5−1を示す信号流れ図である。

0095

本明細書の提案5の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案5の内容のうち、SMSに対する例を示す信号流れ図である。

0096

本明細書の提案5−2に対する例を示す信号流れ図である。
本明細書の提案5−2に対する例を示す信号流れ図である。

0097

本明細書の提案5−2の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案5−2の内容のうち、SMSに対する例を示す信号流れ図である。

0098

本明細書の提案6を示す信号流れ図である。
本明細書の提案6を示す信号流れ図である。

0099

本明細書の提案6−1の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案6−1の内容のうち、SMSに対する例を示す信号流れ図である。

0100

本明細書の提案7を示す信号流れ図である。
本明細書の提案7を示す信号流れ図である。

0101

本明細書の提案7の変形例を示す信号流れ図である。
本明細書の提案7の変形例を示す信号流れ図である。

0102

本明細書の提案8を示す信号流れ図である。
本明細書の提案8を示す信号流れ図である。

0103

本明細書の提案9を示す信号流れ図である。
本明細書の提案9を示す信号流れ図である。

0104

本明細書の提案9の変形例を示す信号流れ図である。
本明細書の提案9の変形例を示す信号流れ図である。

0105

本明細書の提案10−1/10−2/10−3を示す信号流れ図である。
本明細書の提案10−1/10−2/10−3を示す信号流れ図である。

0106

本明細書の提案10−1の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案10−1の内容のうち、SMSに対する例を示す信号流れ図である。

0107

本明細書の提案11を示す信号流れ図である。
本明細書の提案11を示す信号流れ図である。

0108

本明細書の提案11の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案11の内容のうち、SMSに対する例を示す信号流れ図である。

0109

本明細書の提案12を示す信号流れ図である。
本明細書の提案12を示す信号流れ図である。

0110

本明細書の提案12の変形例を示す信号流れ図である。
本明細書の提案12の変形例を示す信号流れ図である。

0111

本明細書の提案12の内容のうち、SMSに対する例を示す信号流れ図である。
本明細書の提案12の内容のうち、SMSに対する例を示す信号流れ図である。

0112

本発明の実施例に係るUE100及び基地局200の構成ブロック図である。

実施例

0113

本発明は、UMTS(Universal Mobile Telecommunication System)及びEPC(Evolved Packet Core)を基準にして説明するが、このような通信システムにのみ限定されるものではなく、本発明の技術的思想が適用されることができる全ての通信システム及び方法にも適用されることができる。

0114

本明細書で使われる技術的用語は、単に特定の実施例を説明するために使われたものであり、本発明を限定するものではないことに留意しなければならない。また、本明細書で使われる技術的用語は、本明細書で特別に他の意味で定義されない限り、本発明が属する技術分野において、通常の知識を有する者により一般的に理解される意味で解釈されなければならず、過度包括的な意味または過度に縮小された意味で解釈されてはならない。また、本明細書で使われる技術的な用語が本発明の思想を正確に表現することができない技術的な用語である場合、当業者が正確に理解することができる技術的用語に変えて理解しなければならない。また、本発明で使われる一般的な用語は、辞書の定義によってまたは前後文脈によって解釈されなければならず、過度に縮小された意味で解釈されてはならない。

0115

また、本明細書で使われる単数の表現は、文脈上、明白に異なる意味ではない限り、複数の表現を含む。本出願において、構成されるまたは有するなどの用語は、明細書上に記載された多様な構成要素、または多様なステップを必ず全て含むと解釈されてはならず、そのうち一部構成要素または一部ステップは含まれない場合もあり、または追加的な構成要素またはステップをさらに含む場合もあると解釈されなければならない。

0116

また、本明細書で使われる第1及び第2などのように序数を含む用語は、多様な構成要素の説明に使われることができるが、前記構成要素は、前記用語により限定されてはならない。前記用語は、一つの構成要素を他の構成要素から区別する目的としてのみ使われる。例えば、本発明の権利範囲外れない限り、第1の構成要素は第2の構成要素と命名することができ、同様に、第2の構成要素も第1の構成要素と命名することができる。

0117

一構成要素が他の構成要素に連結されており、または接続されていると言及された場合は、該当他の構成要素に直接的に連結されており、または接続されている場合もあるが、中間に他の構成要素が存在する場合もある。それに対し、一構成要素が他の構成要素に直接連結されており、または直接接続されていると言及された場合は、中間に他の構成要素が存在しないと理解しなげればならない。

0118

以下、添付図面を参照して本発明による好ましい実施例を詳細に説明し、図面符号に関係なしに同じまたは類似の構成要素は同じ参照番号を付与し、これに対する重複説明は省略する。また、本発明を説明するにあたって、関連した公知技術に対する具体的な説明が本発明の要旨を不明にすると判断される場合、その詳細な説明を省略する。また、添付図面は、本発明の思想を容易に理解することができるようにするためのものであり、添付図面により本発明の思想が制限されると解釈されてはならないことに留意しなければならない。本発明の思想は、添付図面外に全ての変更、均等物乃至代替物にまで拡張されると解釈されなければならない。

0119

添付図面には例示的にUE(User Equipment)が示されているが、図示された前記UEは、端末(Terminal)、ME(Mobile Equipment)などの用語で呼ばれる場合もある。また、前記UEは、ノートブック携帯電話、PDA、スマートフォン(Smart Phone)、マルチメディア機器などのように携帯可能な機器であり、またはPC、車両搭載装置のように携帯不可能な機器である。

0120

用語の定義

0121

以下、図面を参照して説明する前に、本発明の理解を容易にするために、本明細書で使われる用語を簡略に定義する。

0122

UMTS:Universal Mobile Telecommunication Systemの略字であって、3世代移動通信ネットワークを意味する。

0123

UE/MS:User Equipment/Mobile Station、端末装置を意味する。

0124

EPS:Evolved Packet Systemの略字であって、LTE(Long Term Evolution)ネットワークをサポートするコアネットワークを意味する。UMTSが進化した形態のネットワーク。

0125

PDN(Public Data Network):サービスを提供するサーバが位置した独立的なネットワーク。

0126

PDN connection:端末からPDNへの接続、即ち、ipアドレスで表現される端末とAPNで表現されるPDNとの連関(接続)。

0127

PDN−GW(Packet Data Network Gateway):UE IP address allocation、Packet screening&filtering、Charging data collection機能を遂行するEPSネットワークのネットワークノード

0128

Serving GW(Serving Gateway):移動性担当(Mobility anchor)、パケットルーティング(Packet routing)、アイドルモードパケットバッファリング(Idle mode packet buffering)、Triggering MME to page UE機能を遂行するEPSネットワークのネットワークノード。

0129

PCRF(Policy and Charging Rule Function):サービス流れ(flow)別に差別化されたQoS及び課金政策を動的(dynamic)に適用するための政策決定(Policy decision)を実行するEPSネットワークのノード

0130

APN(Access Point Name):ネットワークで管理する接続ポイント名称であって、UEに提供される。即ち、PDNを指称したり区分したりする文字列。要求したサービスやネットワーク(PDN)に接続するためには該当P−GWを経由するようになり、このP−GWをさがすことができるようにネットワーク内で予め定義した名称(文字列)。例えば、internet.mnc012.mcc345.gprs

0131

EID(Tunnel Endpoint Identifier):ネットワーク内のノード間に設定されたトンネルのEnd point ID、各UEのbearer単位に区間別に設定される。

0132

NodeB:UMTSネットワークの基地局であって、屋外に設置され、セルカバレッジ規模マクロセルに該当する。

0133

eNodeB:EPS(Evolved Packet System)の基地局であって、屋外に設置され、セルカバレッジ規模はマクロセルに該当する。

0134

(e)NodeB:NodeBとeNodeBを指称する用語である。

0135

MME:Mobility Management Entityの略字であって、UEに対するセッションと移動性を提供するためにEPS内で各エンティティを制御する役割をする。

0136

セッション(Session):セッションは、データ送信のための通路であって、その単位は、PDN、Bearer、IP flow単位などになる。各単位は、3GPPで定義したように、ターゲットネットワーク体単位(APNまたはPDN単位)、その内でQoSに区分する単位(Bearer単位)、宛先IPアドレス単位に区分することができる。

0137

PDN接続(connection):端末からPDNへの接続、即ち、ipアドレスで表現される端末とAPNで表現されるPDNとの連関(接続)を示す。これはセッションが形成されることができるようにコアネットワーク内のエンティティ間接続(端末−PDN GW)を意味する。

0138

UE Context:ネックワークでUEを管理するために使われるUEの状況情報、即ち、UE id、移動性(現在位置等)、セッションの属性(QoS、優先順位等)で構成された状況情報。

0139

OMADM(Open Mobile Alliance Device Management):携帯電話、PDA、携帯用コンピュータなどのようなモバイルデバイス管理のためにデザインされたプロトコルであって、デバイス設定(configuration)、ファームウェアアップグレード(firmware upgrade)、エラー報告(Error Report)等の機能を遂行する。

0140

OAM(Operation Administration and Maintenance):OAMとは、ネットワーク欠陥表示機能情報、そしてデータと診断機能を提供するネットワーク管理機能群をいう。

0141

NAS configuration MO(Management Object):NAS機能(Functionality)と関連したパラメータ(parameters)をUEに設定(configuration)する時に使用するMO(Management object)を意味する。

0142

NAS(Non−Access−Stratum):UEとMMEとの間の制御平面(control plane)の上位stratum。UEとネットワークとの間の移動性管理(Mobility management)とセッション管理(Session management)、IPアドレス管理(IP address maintenance)などをサポート。

0143

MM(Mobility Management)動作/手順:UEの移動性(mobility)制御/管理/controlのための動作または手順。MM動作/手順は、CSネットワークでのMM動作/手順、GPRSネットワークでのGMM動作/手順、EPSネットワークでのEMM動作/手順のうち一つ以上を含むと解釈されることができる。UEとネットワークノード(MME、SGSN、MSC)は、MM動作/手順を実行するためにMMメッセージを交わす。

0144

SM(Session Management)動作/手順:UEのuser plane及び/またはbearer context/PDPcontextを制御/管理/処理/handlingするための動作または手順。SM動作/手順は、GPRSネットワークでのSM動作/手順、EPSネットワークでのESM動作/手順のうち一つ以上を含むと解釈されることができる。UEとネットワークノード(MME、SGSN)は、SM動作/手順を実行するためにSMメッセージを交わす。

0145

低順位(Low priority)端末:NAS信号低順位に設定された端末。詳細な事項は、標準文書3GPP TS 24.301及びTS 24.008を参考にすることができる。

0146

正常順位(Normal priority)端末:低順位(Low priority)に設定されない一般的な端末。

0147

二重順位(Dual priority)端末:二重順位(Dual priority)に設定された端末、これはNAS信号低順位に設定されると同時に前記設定されたNAS信号低順位を無視(override)することができるように設定された端末(即ち、UE which provides dual priority support is configured for NAS signalling low priority and also configured to override the NAS signalling low priority indicator)。詳細な事項は、標準文書3GPP TS 24.301及びTS 24.008を参考にすることができる。

0148

以下、図面を参照して本明細書の開示に対して説明する。

0149

図6は、ネットワーク過負荷状態を示す。

0150

図6に示すように、eNodeB200のカバレッジには数多いUE100a、100b、100c、100dが存在し、データ送受信を試みる。それによって、前記eNodeB200と前記S−GW520との間のインターフェースにトラフィック過負荷(overload)または混雑(congestion)するようになった場合、前記UE100へのダウンリンクデータまたは前記UE100からのアップリンクデータは、正確に送信されずに失敗するようになる。

0151

または、前記S−GW520と前記PDN−GW530との間のインターフェース、または前記PDN−GW530と移動通信事業者のIP(Internet Protocol)サービスネットワークとの間のインターフェースが過負荷(overload)または混雑(congestion)する場合にも、前記UE100a、100b、100c、100dへのダウンリンクデータまたはUE100a、100b、100c、100dからのアップリンクデータは、正確に送信されずに失敗するようになる。

0152

前記eNodeB200と前記S−GW520との間のインターフェースに過負荷または混雑がある場合、または前記S−GW520と前記PDN−GW530との間のインターフェースに過負荷または混雑がある場合、前記核心ネットワークのノード(例えば、MME)は、NASレベルでの混雑制御(NAS level congestion control)を実行することで、信号混雑(signaling congestion)及びAPN混雑を回避したり制御したりするようになる。

0153

このようなNASレベルでの混雑制御は、APNベースの混雑制御(APN based congestion control)と一般NASレベルで移動管理制御(General NAS level mobility management control)で構成される。

0154

前記APNベースの混雑制御は、UEそして特定APN(混雑状態と関連したAPN)と関連したEMM、GMMと(E)SM信号混雑制御を意味し、APNベースのセッション管理混雑制御(APN based Session Management congestion control)とAPNベースの移動管理混雑制御(APN based Mobility Management congestion control)とを含む。

0155

それに対し、前記一般NASレベルの移動管理制御は、一般的なネットワーク混雑(congestion)や過負荷(overload)状況で、UE/MSが要求する移動管理信号(Mobility Management signaling)要求を核心ネットワーク内のノード(MME、SGSN)が拒絶することで混雑及び過負荷を回避することを意味する。

0156

一般的に、核心ネットワークがNASレベルの混雑制御を実行する場合、アイドルモード(idleモード)または接続モード(connected mode)のUEに遅延時間タイマ(バックオフタイマ)(back−off timer)値をNAS拒絶メッセージ(reject message)に載せて送信するようになり、UEは、遅延時間タイマ(バックオフタイマ)(back−off timer)が満了(expire)される前までネットワークにEMM/GMM/(E)SM信号を要求しなくなる。前記NAS拒絶メッセージは、アタッチ拒絶(ATTACH REJECT)、TAU(Tracking Area Updating)拒絶、RAU(Routing Area Updating)拒絶、サービス拒絶、拡張サービス(EXTENDED SERVICE)拒絶、PDN接続(connectivity)拒絶、ベアラリソース割当(bearer resource allocation)拒絶、ベアラリソース修正(bearer resource modification)拒絶、EPSベアラコンテキスト非活性化要求(deactivateEPSbearer context request)に対する拒絶のメッセージのうち一つに該当する。

0157

このような遅延時間タイマ(back−off timer)は、移動管理(Mobility Management:MM)遅延時間(back−off)タイマとセッション管理(Session Management:SM)遅延時間(back−off)タイマとに分けられる。

0158

前記MM遅延時間(back−off)タイマはUE毎に、そしてSM遅延時間(back−off)タイマはAPN毎にそしてUE毎に、各々、独立的に動作する。

0159

簡略には、前記MM遅延時間(back−off)タイマは、EMM/GMM信号(例えば、Attach、TAU/RAU要求等)制御のためのものである。前記SM遅延時間(back−off)タイマは、(E)SM信号(例えば、PDN connectivity、Bearer Resource Allocation、Bearer Modification、PDPContext Activation、PDP Context Modification要求等)制御のためのものである。

0160

具体的には、MM遅延時間(back−off)タイマは、ネットワークに混雑(congestion)が発生した場合、それを制御するために使用する移動性関連遅延時間(back−off)タイマであって、タイマが動作している間、UEは、アタッチ(attach)、位置情報更新(TAU、RAU)、サービス要求手順(サービス要求手順)をすることができないようにするタイマである。ただ、緊急ベアラサービス(emergency bearer service)、MPS(Multimedia Priority Service)の場合は例外であって、タイマが動作しているとしてもUEが要求可能である。

0161

前述したように、UEがMM遅延時間(back−off)タイマ値を核心ネットワークノード(例えば、MME、SGSN等)から提供を受けたり、下位階層(lower階層;Access Stratum)から伝達を受けたりすることができる。また、UEにより15分から30分までの範囲内でランダムに設定されることもできる。

0162

前記SM遅延時間(back−off)タイマは、ネットワークに混雑(congestion)が発生した場合、それを制御するために使用するセッション管理(Session Management)関連遅延時間(back−off)タイマであって、タイマが動作している間、UEは、関連した(associated)APNベースのセッションを設定または変更することができないようにするタイマである。ただ、同様に、緊急ベアラサービス、MPS(Multimedia Priority Service)の場合は例外であって、タイマが動作しているとしてもUE100が要求可能である。

0163

UEは、このようなSM遅延時間(back−off)タイマ値を核心ネットワークノード(例えば、MME、SGSN等)から提供を受け、最大72時間以内でランダムに設定される。また、UE100により15分から30分までの範囲内でランダムに設定されることもできる。

0164

他方、前記eNodeB200で混雑が発生した場合、前記eNodeB200も混雑制御を実行することができる。即ち、UEがユーザ平面のデータ送信を目的としてRRC接続確立(connection establishment)を要求する時、eNodeB200が混雑状態の場合、延長待機タイマ(extended wait timer)と共に拒絶応答をUEに送信することができる。このような場合、RRC接続確立要求を前記延長待機タイマ(extended wait timer)が満了する前まで再試図することができない。それに対し、UEがCS(circuit switch)ベースの呼び(call)受信のための制御平面の信号を送信する目的としてRRC接続要求をする時、前記eNodeB200が混雑状態であるとしても、これを拒絶することができない。

0165

図7は、ネットワーク混雑状態でアクセスクラスによる禁止(Access Class Barring)による動作を示す例示的な流れ図である。

0166

図7に示すように、ネットワークまたはeNodeB200の過負荷または混雑状態で、eNodeB200は、システム情報を介してACB(Access Class Barring)関連情報ブロードキャスティングすることができる。前記システム情報は、SIB(System Information Block)タイプ2である。

0167

前記SIB(System Information Block)タイプ2は、以下の表のようなACB関連情報を含むことができる。

0168

0169

一方、前記UE1 100aは、IMSサービス、例えば、VoLTEによる呼び(call)の発信を決定し、前記ACBの適用対象になるかどうかを決定する。同様に、UE2 100bは、一般データの発信を決定し、前記ACBの適用対象になるかどうかを決定する。

0170

一般的に、UEは、10個のアクセスクラス(例えば、AC0、AC1、…、AC9)のうち少なくとも一つがランダムに割り当てられている。例外的に、緊急非常アクセスのためにはAC10が割り当てられる。このように、ランダムに割り当てられたアクセスクラスの値は、前記UE1 100a及びUE2 100bの各USIMには格納されることができる。

0171

そのとき、前記UE1 100aと前記UE2 100bは、前記格納されたアクセスクラスに基づいて、前記受信したACB関連情報に含まれているbarring factorフィールドを利用することで、アクセス禁止が適用されるかどうかを確認する。このようなAccess Barringチェックは、前記UE1 100aと前記UE2 100bの各AS(Access Stratum)階層、即ち、RRC階層で実行される。

0172

もし、前記ACBの適用対象でない場合、前記UE1 100aと前記UE2 100bは、各々、サービス要求(または、拡張サービス要求)メッセージとRRC接続要求メッセージを送信することができる。

0173

しかし、前記ACBの適用対象の場合、前記UE1 100aと前記UE2 100bは、両方ともRRC接続要求メッセージを送信することができない。

0174

<マルチメディアテレフォニ(MultiMedia Telephony:MMtel)>

0175

最近、MMTelが多く研究された。前記MMTelは、IMS(IP Multimedia Subsystem)に基づくグローバル標準であって、集中的(converged)、固定的(fixed)モバイルリアルタイムマルチメディア通信を提供し、これを介して音声、リアルタイムビデオ、テキスト、ファイル送信などのようなメディア能力(media capabilities)を使用し、及び写真、オーディオ、ビデオクリップなどを共有することができる。MMTelにおいて、ユーザは、セッション中にメディアを追加したり、または除外したりすることができる。即ち、セッション中にチャット、音声追加、他の発信者追加、ビデオ追加、メディア共有及びファイル送信、並びにこれらのうち特定能力に対する除去が可能である。

0176

現在、3GPP標準MMTEL(MultiMedia Telephony)ベース(即ち、IMSベース)のサービスをサポートするシステム環境ではMMTEL音声、MMTEL映像、SMS overIPサービスを開始するために、UEのNAS(Non−Access Stratum)階層ではサービス要求(Service Request)手順の開始時、呼びタイプ(call type)を発信呼び(originating calls)に設定し、RRC確立原因(establishment cause)を発信データ(Mobile Originated data)に設定することで、RRC接続要求(RRC connection Request)メッセージを送信する。

0177

一般的に、MMTEL音声、MMTEL映像、SMS over IP signalingは、ユーザ平面(User plane)に送信されるため、一般的なデータサービス(即ち、呼びタイプ(call type)=発信呼び(originating calls))と区分されずに提供される。

0178

したがって、UEがMMTELベース(即ち、IMSベース)のサービス、例えば、MO(Mobile Originated)MMTEL音声、MMTEL映像、SMS overIPベースのサービスの提供を受けることを希望し、UEがサービス要求手順を開始する前にアクセス禁止可否をチェックしようとすると、voice call、video callまたはSMS over IPを連結するためのMMTEL(即ち、IMS)シグナリングが既存の一般データシグナリング(即ち、呼びタイプ(call type)=発信呼び(originating calls))と差等化できないため、ACBが適用されて禁止されることができる。したがって、MMTELベース(IMSベース)のMOサービス(特に、MMTEL音声call、MMTEL映像call or SMS over IP)を実行することができない。

0179

また、UEがMOSMS(Short Message Service)サービスを実行しようとする場合にも、既存の一般シグナリング(即ち、呼び(call)タイプ=発信呼び(originating calls))と差等化できないため、同様に、ACBが適用されて禁止されることができる。したがって、MO SMSサービスを実行することができない。

0180

図8は、問題点を示す一例示図である。

0181

図8を参照すると、一般的なデータとMMTEL音声/MMTEL映像/SMS over IP、SMSシグナリングを区別(差等化/差別化)することができないため、ACBによるMO MMTEL音声/MMTEL映像/SMS over IP、MO SMSサービス連結要求が結局失敗される状況が示されている。

0182

一方、RRC確立原因(establishment cause)をマッピングするNAS階層の手順を説明すると、下記の通りである。

0183

EMMがNASシグナリング連結の確立を要求する場合、UEにより使われるRRC確立原因は、NAS手順によって選択される。EMMは、アクセス制御の目的として、下位階層にRRC確立原因と関連した呼びタイプ(call type)を知らせなければならない。UEがEAB(Extended Access Barring)が設定される場合、アクセス制御の目的として、EMMは、下記のケースを除いてはEABをそのような要求に適用させる。

0184

−選択されたPLMNでAC11からAC15のうち一つを使用するように設定されたUE

0185

ページング信号に応答するUE

0186

−RRC確立原因が応急呼び(Emergency call)に設定される

0187

−UEがEABを無視(override)するように設定された場合

0188

−UEがEABを無視するように設定され、EABを無視したままで確立されたPDN接続を既に有している場合

0189

0190

0191

結論的に、現在3GPP標準ではMMTELベース(IMSベース)のMO MMTEL音声、MO MMTEL映像、MOSMS over IPとMO SMSサービスを差別化してサポートしようとする時、効率的な方案がない。このような問題は、ネットワークリソース浪費及びUser experienceを悪化させる。

0192

<本明細書の開示>

0193

したがって、本明細書の開示は、前述した問題点を解決するための解決策を提案する。

0194

本発明では、MMTELベース(IMSベース)のMO(Mobile Originated)MMTEL音声/MMTEL映像/SMS overIPサービスの差別化のために、MMTEL(IMS)シグナリングと既存一般データシグナリングを区分してACB(access class barring)をSkip(通過)する方案を提案する。このようにACB skipをすることによって、MMTELベース(IMSベース)のMO(Mobile Originated)MMTEL音声/MMTEL映像/SMS over IPサービスは、常に連結を許容して他の一般data serviceなどと差別化してサービスを提供するようになる。

0195

そのために、ネットワーク(eNB;基地局)は、MMTEL音声/MMTEL映像/SMS overIPサービスに対するACB skip information(例えば、ACB skippingbit=set/true/not set/false for MMTEL音声及び/またはMMTEL映像及び/またはSMS over IP及び/またはSMS(SMS over SGs))をSIB2を介してUEのAS階層(例えば、RRC階層)に提供する。UEのAS階層(例えば、RRC階層)は、ネットワークから提供を受けたMMTEL音声/MMTEL映像/SMS over IPサービスに対するACB skip informationをMMTEL/SMS over IPのためのIMS階層またはNAS階層に提供することもできる。

0196

<提案1−1/1−2/1−3の概要>

0197

まず、提案1−1は、NAS階層とAS階層(即ち、RRC階層)の動作に関し、提案1−2は、MMTEL(IMS)動作に関し、提案1−3は、SMS−over IP動作に関する。

0198

図9a及び図9bは、本明細書の提案1−1、1−2及び1−3を示す信号流れ図である。

0199

図9a及び図9bを参照して分かるように、提案1−1/1−2/1−3ではMMTELベース(IMSベース)のMO(Mobile Originated)MMTEL音声/MMTEL映像/SMS overIPサービスの差別化のために、MMTEL(IMS)シグナリングと既存一般データシグナリングを区分してACB(access class barring)を通過(skip)させる方案を提示した。このようにACBに対する検査を通過(skip)させることによって、MMTELベース(IMSベース)の発信(MO)MMTEL音声/MMTEL映像/SMS over IPサービスは、常に連結を許容して他の一般データサービスと差別化してサービスを提供するようになる。

0200

そのために、ネットワーク(例えば、基地局)は、MMTEL音声/MMTEL映像/SMS over IP/SMS(SMS over SGs)サービスに対するACBスキップ情報(即ち、ACB skippingbit=set/true/not set/false for MMTEL voice、MMTEL video、SMS over IP and/or SMS(SMS over SGs))をシステム情報ブロック(例えば、SIB2)を介してUEのAS階層(即ち、RRC階層)に提供する。

0201

MMTEL/SMS over IPのためのIMS階層が発信(MO)MMTEL音声/MMTEL映像、MO SMS overIPサービス連結を開始する時、MMTELのためのIMS階層がMMTEL音声、MMTEL映像のためのセッション/呼び(call)であることを知らせるインジケーション/情報をNAS階層に提供する。同様に、SMS over IPのためのIMS階層がSMS overIPセッションであることを知らせるインジケーション/情報をNAS階層に提供する。

0202

MMTEL/SMS over IPのためのIMS階層がMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)インジケーションを提供すると、NAS階層は、前記セッション/呼び(call)が一般データセッション/呼び(call)でないMMTEL音声、MMTEL映像or/SMS over IPのためのセッション/呼び(call)であることを認知するようになる。以後、NAS階層は、MMTEL音声、MMTEL映像またはSMS over IPのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、サービスタイプをmobile originating MMTEL voice for MMTEL voice/mobile originating MMTEL video for MMTEL video/mobile originating SMS over IP for SMS over IPに設定し、RRC確立原因は、MO dataに設定し、呼びタイプ(call type)は、originating MMTEL voice calls for MO MMTEL voice/originating MMTEL video calls for MO MMTEL video/mobile originating SMS for MO SMS over IPに設定する。

0203

図10a及び図10bは、本明細書の提案1−1を示す信号流れ図である。

0204

図10a及び図10bを参照して分かるように、提案1−1によると、SMS(SMS over SGs;SMS over NAS)の場合、NAS階層は、MO(Mobile Originated)SMS連結のためのサービス要求手順の開始時、サービスタイプをmobile originating SMS over SGsに設定し、RRC確立原因は、MO dataに設定し、呼びタイプ(call type)は、mobile originating SMS for MO SMS(SMS over SGs)に設定する。

0205

提案1−1/1−2/1−3によると、MMTEL/SMS over IPのためのIMS階層がMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)インジケーションを提供すると、NAS階層は、前記セッション/呼び(call)が一般データセッション/呼び(call)でないMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)であることを認知するようになる。以後、NAS階層は、MMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション連結のためにサービス要求手順を開始する。呼びタイプ(call type)は、originating MMTEL voice calls for MO MMTEL voice/originating MMTEL video calls for MO MMTEL video/originating SMS for MO SMS over IPに設定し、RRC確立原因は、MO dataに設定する。

0206

以下、各提案に対して説明する。

0207

<提案1−1:標準改善>

0208

下記の非正常ケースが確認されることができる。

0209

a)ACBにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Extended wait time)なしにネットワークから拒絶されたNASシグナリング連結確立

0210

−もし、下位階層が指示したアクセスが遮断(barred)されたが、サービス要求は、SMS over IPを除外したSMSのために開始された場合、サービス要求手順は開始されることができる。

0211

もし、下位階層が指示したアクセスが遮断(barred)されたが、サービス要求は、MMTEL音声、MMTEL映像、またはSMS over IPのために開始された場合、サービス要求手順は開始されることができる。

0212

そうでない場合、アクセスが発信呼び(originating calls)に対して遮断(barred)される時、サービス要求手順は開始されない。UEが現在サービングセルでとどまった状態で正常なセル再選択手順を実行する。

0213

b)下位階層失敗またはサービス要求手順が完了する以前に下位階層から受信された延長待機時間(Extended wait time)がないままでNASシグナリング連結を解除する。

0214

0215

<提案1−2:標準改善>

0216

ユーザからマルチメディアテレフォニ通信セッションの確立に対する要求がある場合、SCM(Smart Congestion Mitigation)をサポートするUEは、下記のように動作する。

0217

1)もし、ビデオがマルチメディアテレフォニ通信セッション内で提供される場合、EMM階層にMMTEL映像を指示し、セッション確立を進行する。

0218

2)それに対し、オーディオがマルチメディアテレフォニ通信セッション内で提供される場合、EMM階層にMMTEL音声を指示し、セッション確立を進行する。

0219

一方、SCMに対して説明すると、下記の通りである。

0220

下記の情報がNAS階層に提供される。

0221

−MMTEL音声識別子を有するACB−skip−set(例えば、true/start/begin)−indication

0222

−MMTEL音声識別子を有するACB−skip−reset(例えば、false/stop/end)−indication;

0223

−MMTEL映像識別子を有するACB−skip−set(例えば、true/start/begin)−indication

0224

−MMTEL映像識別子を有するACB−skip−reset(例えば、false/stop/end)−indication

0225

ユーザからマルチメディアテレフォニ通信セッションの確立に対する要求がある場合、そしてセッション確立がサービス特定アクセス制御を実行した以後に続く場合、下記のように動作する。

0226

1)もし、オーディオまたはリアルタイムテキストまたはオーディオ及びテキストの組合せがマルチメディアテレフォニ通信セッション内で提供され、他のマルチメディアテレフォニ通信セッションはない場合、UEは、MMTEL音声識別子を有するACB−skip−set(例えば、true/start/begin)−indicationをNAS階層に提供する。

0227

2)もし、ビデオがマルチメディアテレフォニ通信セッション内で提供され、他のマルチメディアテレフォニ通信セッションはない場合、UEは、MMTEL映像識別子を有するACB−skip−set(例えば、true/start/begin)−indicationをNAS階層に提供する。

0228

一方、マルチメディアテレフォニ通信セッションが終了する時、マルチメディアテレフォニ通信セッションがオーディオまたはリアルタイムテキスト、またはオーディオ及びテキストの組合せを送信するために確立されたものであり、他のセッションはない場合、UEは、MMTEL音声識別子を有するACB−skip−reset(例えば、false/stop/end)−indicationをNAS階層に提供することができる。

0229

一方、マルチメディアテレフォニ通信セッションが終了する時、マルチメディアテレフォニ通信セッションがビデオを送信するために確立されたものであり、他のセッションはない場合、UEは、MMTEL映像識別子を有するACB−skip−reset(例えば、false/stop/end)−indicationをNAS階層に提供することができる。

0230

<提案1−3:標準改善>

0231

提案1−3によると、マルチメディアテレフォニ通信セッションの確立がユーザから要求され、UEがSCMをサポートする場合、下記のように動作する。

0232

1)SMS−over−IPがマルチメディアテレフォニ通信セッション内で提供される場合、UEは、EMM階層にSMS−over−IPを指示し、セッション確立を続ける。

0233

2)そうでない場合、セッション確立を進行し続ける。

0234

一方、下記の情報がNAS階層に提供される。

0235

−SMS−over−IP識別子を有するACB−skip−set(例えば、true/start/begin)−indication

0236

−SMS−over−IP識別子を有するACB−skip−reset(例えば、false/stop/end)−indication

0237

ユーザからSMS over IPの送信に対する要求があり、他のSMS over IPを送信するものがない場合、UEは、SMS−over−IP識別子を有するACB−skip−set(例えば、true/start/begin)−indicationをNAS階層に指示する。

0238

SMS over IPの送信が完了し、他のSMS over IPは送信するものがない場合、UEは、SMS−over−IP識別子を有するACB−skip−reset(例えば、false/stop/end)−indicationをNAS階層に指示する。

0239

<提案2−1/2−2/2−3の概要>

0240

提案2−1は、NAS階層とAS階層(例えば、RRC階層)の動作に関し、提案2−2は、MMTELのためのIMS階層とAS階層(例えば、RRC階層)の動作に関し、提案2−3は、SMS over IPのためのIMS階層とAS階層(例えば、RRC階層)の動作に関する。

0241

提案2−1/2−2/2−3は、MMTELベース(IMSベース)の発信(MO:Mobile Originated)MMTEL音声/MMTEL映像/SMS overIPサービスの差別化のために、MMTEL(IMS)シグナリングと既存一般データシグナリングを区分してACBに対する検査を通過(skip)させる方案を提案する。このようにACBに対する検査を通過(skip)させることによって、MMTELベース(IMSベース)のMO MMTEL音声/MMTEL映像/SMS over IPサービスは、常に連結を許容して他の一般データサービスなどと差別化してサービスを提供するようになる。

0242

図11a及び図11bは、本明細書の提案2−1、2−2及び2−3を示す信号流れ図である。

0243

図11a及び図11bを参照して分かるように、ネットワーク(例えば、基地局)は、MMTEL音声/MMTEL映像/SMS overIPサービスに対するACBスキップ情報(即ち、ACB skippingbit=set/true/not set/false for MMTEL voice及び/またはMMTEL video及び/またはSMS over IP及び/またはSMS(SMS over SGs))をシステム情報ブロック(例えば、SIB2)を介してUEのAS階層(例えば、RRC階層)に提供する。UEのAS階層(例えば、RRC階層)は、ネットワークから提供を受けたMMTEL音声/MMTEL映像/SMS over IPサービスに対するACBスキップ情報をMMTEL/SMS over IPのためのIMS階層に提供する。

0244

上記提案2−1/2−2/2−3によると、MMTEL/SMS over IPのためのIMS階層がMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)に対するACBスキップインジケーション/情報を提供すると、NAS階層は、前記セッション/呼び(call)が一般データセッション/呼び(call)でないMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)であることを認知するようになる。以後、NAS階層は、MMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ACBスキップインジケーション(即ち、ACB skip=set/true)をAS階層(例えば、RRC階層)に提供する。

0245

図12a及び図12bは、本明細書の提案2−2を示す信号流れ図である。

0246

図12a及び図12bを参照して分かるように、提案2−1によると、SMS(SMS over SGs;SMS over NAS)の場合、NAS階層は、MO SMS連結のためのサービス要求手順の開始時、サービスタイプをmobile originating SMS over SGsに設定し、RRC確立原因は、MO dataに設定し、呼びタイプ(call type)は、mobile originating SMS for MO SMS(SMS over SGs)に設定する。

0247

以下、各提案に対して詳細に説明する。

0248

<提案2−1>

0249

下記の非正常ケースが確認されることができる。

0250

a)ACBにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Extended wait time)なしにネットワークから拒絶されたNASシグナリング連結確立

0251

−もし、下位階層が示すアクセスが遮断(barred)されたが、サービス要求は、SMS over IPを除外したSMSのために開始された場合、サービス要求手順は開始されなければならない。

0252

−もし、下位階層が示すアクセスが遮断されたが、サービス要求は、MMTEL音声、MMTEL映像、orSMS over IPのために開始された場合、そして、UEは、上位階層からACBに対する検査の通過(skip)が指示された場合、サービス要求手順は開始されなければならない。

0253

b)下位階層失敗またはサービス要求手順が完了する以前に下位階層から受信された延長待機時間(Extended wait time)がないままでNASシグナリング連結を解除する。

0254

一方、RRC確立原因(establishment cause)をマッピングするNAS階層の手順を説明すると、下記の通りである。

0255

EMMがNASシグナリング連結の確立を要求する場合、UEにより使われるRRC確立原因は、NAS手順によって選択される。EMMは、アクセス制御の目的として、下位階層にRRC確立原因と関連した呼びタイプ(call type)を知らせなければならない。さらに、EMMがNASシグナリング連結を要求する時、上位階層がACBに対する検査の通過を指示する場合、EMMは、ACBに対する検査の通過を下位階層に伝達しなければならない。UEがEAB(Extended Access Barring)が設定される場合、アクセス制御の目的として、EMMは、下記のケースを除いてはEABをそのような要求に適用させる。

0256

−選択されたPLMNでAC11からAC15のうち一つを使用するように設定されたUE

0257

−ページング信号に応答するUE

0258

−RRC確立原因が応急呼び(Emergency call)に設定される

0259

−UEがEABを無視(override)するように設定された場合

0260

−UEがEABを無視するように設定され、EABを無視したままで確立されたPDN接続を既に有している場合

0261

0262

一方、提案2−1によると、下記の非正常ケースが確認されることができる。

0263

a)ACBにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Extended wait time)なしにネットワークから拒絶されたNASシグナリング連結確立

0264

ACBが下記の場合に適用されない。

0265

−サービス要求手順がページング要求に対する応答として開始される場合

0266

−上位階層から受信されるACBスキップインジケーション内にACBに対する検査の通過(skip)が設定されている場合

0267

一方、上記提案は、下記のように変形されることができる。

0268

EMMがNASシグナリング連結の確立を要求する場合、UEにより使われるRRC確立原因は、NAS手順によって選択される。EMMは、アクセス制御の目的として、下位階層にRRC確立原因と関連した呼びタイプ(call type)を知らせなければならない。UEがEAB(Extended Access Barring)が設定される場合、アクセス制御の目的として、EMMは、下記のケースを除いてはEABをそのような要求に適用させる。

0269

−選択されたPLMNでAC11からAC15のうち一つを使用するように設定されたUE

0270

−ページング信号に応答するUE

0271

−RRC確立原因が応急呼び(Emergency call)に設定される

0272

−UEがEABを無視(override)するように設定された場合

0273

−UEがEABを無視するように設定され、EABを無視したままで確立されたPDN接続を既に有している場合

0274

上位階層から受信されたACBスキップインジケーション内にACBに対する検査の通過が設定されている場合、EMMは、アクセス制御の目的として、下位階層にこの要求に対してACBを適用させないことを指示する。

0275

0276

その代案として、上記提案は、下記のように変形されることができる。

0277

上記変形例によると、下記の非正常ケースが確認されることができる。

0278

a)ACBにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Extended wait time)なしにネットワークから拒絶されたNASシグナリング連結確立

0279

ACBが下記の場合に適用されない。

0280

−サービス要求手順がページング要求に対する応答として開始される場合

0281

−サービス要求手順が上位階層のユーザ平面無線リソースの要求により開始され、上位階層から受信されるACBスキップ情報内にACBのスキップが設定されている場合

0282

その代案として、上記提案は、下記のように変形されることができる。

0283

EMMがNASシグナリング連結の確立を要求する場合、UEにより使われるRRC確立原因は、NAS手順によって選択される。EMMはアクセス制御の目的として、下位階層にRRC確立原因と関連した呼びタイプ(call type)を知らせなければならない。UEがEAB(Extended Access Barring)が設定される場合、アクセス制御の目的として、EMMは、下記のケースを除いてはEABをそのような要求に適用させる。

0284

−選択されたPLMNでAC11からAC15のうち一つを使用するように設定されたUE

0285

−ページング信号に応答するUE

0286

−RRC確立原因が応急呼び(Emergency call)に設定される

0287

−UEがEABを無視(override)するように設定された場合

0288

−UEがEABを無視するように設定され、EABを無視したままで確立されたPDN接続を既に有している場合

0289

EMMは、アクセス制御の目的として、下記のケースに該当すると、下位階層にACBを適用しないことを指示することができる。

0290

−UEがユーザ平面の無線リソースに対する要求を上位階層から受信し、上位階層から受信したACBスキップ情報内にはACBに対する検査の通過(skip)が設定されている場合

0291

0292

<提案2−2>

0293

提案2−2によるSCM(Smart Congestion Mitigation)に対する改善を説明すると、下記の通りである。

0294

下記の情報が下位階層により提供される。

0295

−ACBSkipForMMTEL−Voice:MMTEL音声のためのACB skippingbit;

0296

−ACBSkipForMMTEL−Video:MMTEL映像のためのACB skippingbit

0297

マルチメディアテレフォニ通信セッションの確立に対するユーザ要求を受信する場合、UEは、下記のように動作する。

0298

1)下位階層から受信されるACBスキップ情報の検索

0299

2)マルチメディアテレフォニ通信セッション内でビデオが提供され、ACB skippingbitがMMTEL映像に対して設定された場合、UEは、EMM階層にACBに対する検査の通過を指示し、セッション確立を続ける。

0300

3)マルチメディアテレフォニ通信セッション内でオーディオが提供され、ACB skippingbitがMMTEL音声に対して設定された場合、UEは、EMM階層にACBに対する検査の通過を指示し、セッション確立を続ける。

0301

<提案2−3>

0302

提案2−3によるSCM(Smart Congestion Mitigation)に対する改善を説明すると、下記の通りである。

0303

下記の情報が下位階層から提供される。

0304

−ACBSkipForSMS−over−IP:SMS−over−IPに対するACB skippingbit

0305

ユーザからマルチメディアテレフォニ通信セッションの確立に対する要求を受信する場合、UEは、下記のように動作する。

0306

1)下位階層から受信されたACBスキップ情報の検索

0307

2)マルチメディアテレフォニ通信セッション内でSMS−over−IPが提供され、ACB skippingbitがSMS−over−IPに対して設定された場合、UEは、EMM階層にACBに対する検査の通過(skip)を指示し、セッション確立を続ける。

0308

<提案3>

0309

提案3は、MMTELベース(IMSベース)のMMTEL音声/MMTEL映像/SMS overIPサービスの差別化のために、MMTEL(IMS)シグナリングと既存一般データシグナリングを区分してACBに対する検査を通過(skip)する方案を提案する。このようにACBに対する検査を通過(skip)させることによって、MMTELベース(IMSベース)のMO(Mobile Originated)MMTEL音声/MMTEL映像/SMS over IPサービスは、常に連結を許容して他の一般データサービスなどと差別化してサービスを提供するようになる。

0310

図13a及び図13bは、本明細書の提案3を示す信号流れ図である。

0311

図13a及び図13bを参照して分かるように、提案3によると、MMTEL音声/MMTEL映像/SMS(具体的に、SMS over IP)に対して、MMTEL/SMS over IPのためのIMS階層がMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)に対するACBスキップインジケーション/情報をAS(RRC)階層から提供すると、NAS階層は、前記セッション/呼び(call)が一般データセッション/呼び(call)でないMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)であることを認知するようになる。以後、NAS階層は、MMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ACBスキップインジケーション(即ち、ACB skip=set/true)をAS階層(例えば、RRC階層)に提供する。

0312

図14a及び図14bは、本明細書の提案3の内容のうち、SMSに対する例を示す信号流れ図である。

0313

図14a及び図14bを参照すると、SMS(SMS over SGs;SMS over NAS)の場合、NAS階層は、MO(Mobile Originated)SMS連結のためのサービス要求の開始時、呼びタイプ(call type)は、mobile originating SMS for MO SMS(SMS over SGs)に設定し、RRC確立原因は、MO dataに設定する。

0314

<提案4:標準改善>

0315

提案4は、MMTELベース(IMSベース)のMMTEL音声/MMTEL映像/SMS overIPサービスの差別化のために、MMTEL(IMS)シグナリングと既存一般データシグナリングを区分してACBに対する検査を通過(skip)させる方案を提案する。このようにACBに対する検査を通過(skip)させることによって、MMTELベース(IMSベース)のMO MMTEL音声/MMTEL映像/SMS over IPサービスは、常に連結を許容して他の一般データサービスなどと差別化してサービスを提供するようになる。

0316

提案4は、提案1−1と類似する。具体的に説明すると、下記の通りである。

0317

図15a及び図15bは、本明細書の提案4を示す信号流れ図である。

0318

図15a及び図15bを参照して分かるように、提案4によると、MMTEL音声/MMTEL映像/SMS(具体的に、SMS over IP)に対して、NAS階層は、サービス要求手順を開始する時、呼びタイプ(call type)をmobile originating MMTEL voice、mobile originating MMTEL videoまたはmobile originating SMS over IP for MO SMS over IPに設定し、RRC確立原因は、MO dataに設定する。

0319

図16a及び図16bは、本明細書の提案4の内容のうち、SMSに対する例を示す信号流れ図である。

0320

図16a及び図16bに示すように、提案4によると、SMS(SMS over SGs;SMS over NAS)の場合、NAS階層は、MO(Mobile Originated)SMS連結のためのサービス要求手順の開始時、呼びタイプ(call type)は、originating SMS for MO SMS(SMS over SGs)に設定し、RRC確立原因は、MO dataに設定する。

0321

提案4によると、下記の非正常ケースが確認されることができる。

0322

a)ACBにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Extended wait time)なしにネットワークから拒絶されたNASシグナリング連結確立

0323

ACBが下記の場合に適用されない。

0324

−サービス要求手順がネットワークのページング要求に応答して開始される場合

0325

−ACBが通過(skip)されるようにサービスインジケーション(MMTEL音声、MMTEL映像、またはSMS over IP)が上位階層から受信される場合

0326

0327

上記提案で、上位階層(MMTEL階層)からEMM階層(non−access stratum階層)に提供するサービスインジケーションは、MMTEL音声またはMMTEL映像またはSMS over IPのためのACB skip bits indicationであり、またはMMTEL音声またはMMTEL映像またはSMS over IPを示すサービスインジケータ/情報である。

0328

上記提案で、NAS階層は、MMTEL音声、MMTEL映像、SMS over IP、SMS over NASを区分してサービス要求手順(即ち、サービス要求メッセージの送信)を開始する時、AS階層(即ち、RRC階層)にMMTEL音声、MMTEL映像、SMS over IP、SMS over NASを区分するための新しい呼びタイプ(call type)(call types)として、originating MMTEL voice for MMTEL voice、originating MMTEL video for MMTEL video、originating SMS over IP for SMS over IP、originating SMS for SMS over NASを定義して送る。AS階層(即ち、RRC階層)は、NASが要求したサービス要求手順(即ち、サービス要求メッセージの送信)を実行するためにRRC接続を確立(establishment)するようになり、前記IMSサービスとSMSサービスを新しい呼びタイプ(call type)(call types)を使用して区分し、各々に対して基地局から受信されたシステム情報ブロック(SIB)内に含まれているACBスキップ情報によって最終ACBに対する検査を通過(skip)させるかどうかを決定するようになる。即ち、AS階層(即ち、RRC階層)は、NAS階層のサービス要求メッセージの新しい呼びタイプ(call type)を判読し、IMSサービスとSMSサービスを認知した後、ネットワークから受信したACBスキップ情報内に該当サービスが設定(例えば、ACB skippingON)されている場合、該当RRC接続確立を実行し、そうでない場合、該当RRC接続確立を実行せずにアクセスを遮断(barring)する。

0329

その代案として、上記提案は、下記のように変形されることもできる。

0330

0331

上記提案で、上位階層(例えば、MMTEL階層)からEMM階層(例えば、NAS階層)に提供するサービスインジケーションは、MMTEL音声、MMTEL映像、またはSMS over IPのためのACB skip bits indicationであり、またはMMTEL音声、MMTEL映像またはSMS over IPを示すサービスインジケータ/情報である。

0332

上記提案で、NAS階層は、MMTEL音声、MMTEL映像、SMS over IP、SMS over NASを区分してサービス要求手順(即ち、拡張サービス要求メッセージの送信)を開始する時、AS階層(即ち、RRC階層)にMMTEL音声、MMTEL映像、SMS over IP、SMS over NASを区分するための新しいサービスタイプとしてmobile originating MMTEL voice、mobile originating MMTEL video、mobile originating SMS over IP、mobile originating SMSを定義して送る。このとき、新しく定義されたサービスタイプと共に新しい呼びタイプ(call type)が定義されて使われることもできる。AS階層(即ち、RRC階層)は、NASが要求したサービス要求手順(即ち、拡張サービス要求メッセージの送信)を実行するためにRRC接続を確立(establishment)するようになり、前記IMSサービスとSMSサービスをサービスタイプ及び/または新しい呼びタイプ(call type)を介して区分し、各々に対してネットワークから受信したシステム情報(例えば、SIB)内に含まれているACBスキップ情報によって最終的にACBに対する検査を通過(skip)させるかどうかを決定するようになる。即ち、AS階層(即ち、RRC階層)は、NAS階層の拡張サービス要求メッセージの新しいサービスタイプ及び/または呼びタイプ(call type)を判読し、IMSサービスとSMSサービスを認知した後、ネットワークから受信したACBスキップ情報が該当サービスに対してセッティング(ACB skippingON)されている場合、該当RRC接続を確立し、そうでない場合、該当RRC接続を確立しない。

0333

一方、拡張サービス要求メッセージは、下記の場合に送信される。

0334

−CSフォールバックを開始するために、またはCSフォールバックの着信(Mobile terminating)に応答するために

0335

−NASシグナリング連結の確立を要求するために

0336

拡張サービス要求メッセージは、サービスタイプを含む。前記サービスタイプは、下記の通りである。

0337

0338

または、上位階層は、MMTEL音声のためにACBに対する検査の通過(skip)を指示する:MMTEL音声識別子を有するACB−skip−set−indicationが上位階層から受信され、そしてMMTEL音声識別子を有するACB−skip−set−indicationが上位階層から受信された以後、MMTEL音声識別子を有するACB−skip−reset−indicationが受信されない。

0339

上位階層は、MMTEL映像に対してACBに対する検査の通過(skip)を指示する:MMTEL映像識別子を有するACB−skip−set−indicationが上位階層から受信され、そしてMMTEL映像識別子を有するACB−skip−set−indicationが上位階層から受信された以後、MMTEL映像識別子を有するACB−skip−reset−indicationが受信されない。

0340

上位階層は、MMTELSMS−over−IPに対してACBに対する検査の通過を指示する:SMS−over−IP識別子を有するACB−skip−set−indicationが上位階層から受信され、そしてSMS−over−IP識別子を有するACB−skip−set−indicationが上位階層から受信された以後、SMS−over−IP識別子を有するACB−skip−reset−indicationが受信されない。

0341

他の一方、上記提案は、下記のように変形されることもできる。

0342

下記の非正常ケースが確認されることができる。

0343

a)ACBにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Extended wait time)なしにネットワークから拒絶されたNASシグナリング連結確立

0344

ACBが下記の場合に適用されない。

0345

−サービス要求手順がページング要求に応答して開始される場合

0346

−サービス要求手順がSMSの発信のために開始される場合

0347

−サービス要求手順がユーザ平面の無線リソースに対する上位階層の要求により開始される時、上位階層がMMTEL音声のためにACBに対する検査の通過(skip)を指示する場合

0348

−サービス要求手順がユーザ平面の無線リソースに対する上位階層の要求により開始される時、上位階層がMMTEL映像のためにACBに対する検査の通過(skip)を指示する場合

0349

−サービス要求手順がユーザ平面の無線リソースに対する上位階層の要求により開始される時、上位階層がSMS−over−IPのためにACBに対する検査の通過(skip)を指示する場合

0350

サービス要求手順に対するトリガがページング要求に対する応答であり、NASシグナリング連結確立がネットワークにより拒絶された場合、前記サービス要求手順は開始されない。UEが現在サービングセルにとどまっている状態の場合、一般セル再選択手順を実行する。サービス要求手順は、着信呼び(terminating calls)に対するアクセスが許容される場合またはセル変更の理由などで開始されることができる。

0351

0352

上記提案で、NAS階層は、発信(MO:mobile originating)MMTEL音声、MMTEL映像、SMS(具体的に、SMS over IP、SMS over SGs、SMS in MME、またはSMS over S102)を区分してサービス要求手順(サービス要求メッセージの送信)を開始する時、AS階層(例えば、RRC階層)にMO MMTEL音声、MMTEL映像、SMS(具体的に、SMS over IP、SMS over SGs、SMS in MME、or SMS over S102)を区分し、各々新しい呼びタイプ(call type)として、originating MMTEL voice、originating MMTEL video、originating SMSを定義して送る。AS階層(例えば、RRC階層)は、NASが要求したサービス要求手順を実行するためにRRC接続を確立(establishment)するようになり、前記IMSサービスとSMSサービスを新しい呼びタイプ(call type)(call types)を介して区分し、各々に対してネットワークから受信したシステム情報(例えば、SIB)内に含まれているACBスキップ情報によって最終ACBに対する検査を通過(skip)させるかどうかを決定するようになる。即ち、AS階層(例えば、RRC階層)は、NAS階層のサービス要求メッセージの新しい呼びタイプ(call type)を判読し、IMSサービスとSMSサービスを認知した後、ネットワークから受信したACBスキップ情報が該当サービスに対してセッティング(ACB skippingON)されている場合、該当RRC接続確立を実行し、そうでない場合、該当RRC接続確立を実行しない。

0353

また、上記提案で、NAS復旧のためのTAU(Tracking Area Update)要求手順が開始(実行)される場合、NAS階層は、MO MMTEL音声、MMTEL映像、SMS(具体的に、SMS over IP、SMS over SGs、SMS in MME、or SMS over S102)を区分してTAU手順(即ち、TAU要求メッセージの送信)を開始する時、AS階層(例えば、RRC階層)にMO MMTEL音声、MMTEL映像、SMS(SMS over IP、SMS over SGs、SMS in MME、or SMS over S102)を区分するための新しい呼びタイプ(call type)として、originating MMTEL voice、originating MMTEL video、originating SMSを定義して送る。AS階層(例えば、RRC階層)は、NASが要求したTAU手順を実行するためにRRC接続を確立(establishment)するようになり、このとき、前記IMSサービスとSMSサービスを呼びタイプ(call type)を介して区分し、各々に対してネットワークから提供されたSIB情報内に含まれているACBスキップ情報によって最終ACBに対する検査を通過(skip)させるかどうかを決定するようになる。即ち、AS階層(例えば、RRC階層)でNAS階層のTAU要求メッセージの呼びタイプ(call type)を判読し、IMSサービスとSMSサービスを認知した後、ネットワークから受信したACBスキップ情報が該当サービスに対してセッティング(ACB skippingON)されている場合、該当RRC接続の確立(このとき、RRC確立原因は、MO signallingに設定される)を実行し、そうでない場合、該当RRC接続を確立しない。

0354

他の一方、上位階層は、MMTEL音声のためにACBに対する検査の通過(skip)を指示することができる:例えば、MMTEL音声識別子を有するACB−skip−set−indicationが上位階層から受信され、MMTEL音声識別子を有するACB−skip−set−indicationが上位階層から受信された以後、MMTEL音声識別子を有するACB−skip−reset−indicationが上位階層から受信されない場合である。

0355

上位階層は、MMTEL映像のためにACBに対する検査の通過(skip)を指示することができる。例えば、MMTEL映像識別子を有するACB−skip−set−indicationが上位階層から受信され、MMTEL映像識別子を有するACB−skip−set−indicationが上位階層から受信された以後、MMTEL映像識別子を有するACB−skip−reset−indicationが上位階層から受信されない場合である。

0356

上位階層は、MMTELSMS−over−IPのためにACBに対する検査の通過(skip)を指示することができる。例えば、SMS−over−IP識別子を有するACB−skip−set−indicationが上位階層から受信され、SMS−over−IP識別子を有するACB−skip−set−indicationが上位階層から受信された以後、SMS−over−IP識別子を有するACB−skip−reset−indicationが上位階層から受信されない場合である。

0357

他の一方、上記提案は、下記のように変形されることもできる。

0358

下記の非正常ケースが確認されることができる。

0359

a)ACBにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Extended wait time)なしにネットワークから拒絶されたNASシグナリング連結確立

0360

ACBが下記の場合に適用されない。

0361

−サービス要求手順がページング要求に応答して開始される場合

0362

−サービス要求手順が発信(MO)SMS(例えば、SMS in MME、SMS over SGs or SMS over S102)により開始された場合

0363

−サービス要求手順がユーザ平面の無線リソースのための上位階層の要求により開始された時、上位階層は、MMTEL音声のためにACBに対する検査の通過(skip)を指示した場合、

0364

−サービス要求手順がユーザ平面の無線リソースのための上位階層の要求により開始された時、上位階層は、MMTEL映像のためにACBに対する検査の通過(skip)を指示した場合、

0365

−サービス要求手順がユーザ平面の無線リソースのための上位階層の要求により開始された時、上位階層は、SMS−over−IPのためにACBに対する検査の通過(skip)を指示した場合、

0366

サービス要求手順に対するトリガがネットワークからのページングに対する応答として開始され、NASシグナリング連結確立がネットワークにより拒絶された場合、サービス要求手順は開始されてはならない。UEが現在サービングセルにとどまった状態にある場合、一般的なセル再選択手順を実行することができる。

0367

0368

上記提案で、NAS階層は、発信(MO)MMTEL音声、MMTEL映像、SMS(具体的に、SMS over IP、SMS over SGs、SMS in MME、or SMS over S102)を区分してサービス要求手順(拡張サービス要求メッセージの送信)を開始する時、AS階層(例えば、RRC階層)にMMTEL音声、MMTEL映像、SMS(具体的に、SMS over IP、SMS over SGs、SMS in MME、or SMS over S102)を区分するための新しいサービスタイプ、例えば、mobile originating MMTEL voice for MMTEL voice、mobile originating MMTEL video for MMTEL video、mobile originating SMSを定義して送る。このとき、新しく定義されたサービスタイプと共に新しい呼びタイプ(call type)が定義されて使われることもできる。AS階層(例えば、RRC階層)は、NASが要求したサービス要求手順(例えば、拡張サービス要求メッセージの送信)を実行するためにRRC接続を確立(establishment)するようになり、前記IMSサービスとSMSサービスをサービスタイプ及び/または呼びタイプ(call type)を介して区分し、各々に対してネットワークから提供されたSIB内に含まれているACBスキップ情報によって最終ACBに対する検査を通過(skip)させるかどうかを決定するようになる。即ち、AS階層(例えば、RRC階層)でNAS階層の拡張サービス要求メッセージ内のサービスタイプ及び/または呼びタイプ(call type)を判読し、IMSサービスとSMSサービスを認知した後、ネットワークから受信したACBスキップ情報内に該当サービスがセッティング(即ち、ACB skippingON)されている場合、該当RRC接続確立を実行し、そうでない場合、該当RRC接続確立を実行しない。

0369

0370

<提案5−1:標準改善>

0371

図17a及び図17bは、本明細書の提案5−1を示す信号流れ図である。

0372

図17a及び図17bを参照して分かるように、提案5−1によると、MMTEL/SMS over IPのためのIMS階層がMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)に対するACBスキップインジケーションを提供すると、NAS階層は、前記セッション/呼び(call)が一般データセッション/呼び(call)でないMMTEL音声、MMTEL映像or/SMS over IPのためのセッション/呼び(call)であることを認知するようになる。以後、NAS階層は、MMTEL音声、MMTEL映像or SMS over IPのためのセッション連結のためにサービス要求手順を開始する。このとき、拡張サービス要求(EXTENDED SERVICE REQUEST)メッセージを使用する。サービス要求手順の開始時、拡張サービス要求メッセージのサービスタイプは、mobile originating MMTEL voice for MMTEL voice/mobile originating MMTEL video for MMTEL video/mobile originating SMS over IP for SMS over IPに設定し、RRC確立原因は、MO dataに設定し、呼びタイプ(call type)は、mobile originating MMTEL voice calls for MO MMTEL voice/mobile originating MMTEL video calls for MO MMTEL video/mobile originating SMS for MO SMS(SMS over IP)に設定する。

0373

図18a及び図18bは、本明細書の提案5の内容のうち、SMSに対する例を示す信号流れ図である。

0374

図18a及び図18bを参照すると、SMS(SMS over SGs;SMS over NAS)の場合、NAS階層は、MO(Mobile Originated)SMS連結のためのサービス要求手順の開始時、拡張サービス要求メッセージのサービスタイプをmobile originating SMSに設定し、RRC確立原因は、MO dataに設定し、呼びタイプ(call type)は、originating SMS for MO SMSに設定する。

0375

<提案5−2>

0376

図19a及び図19bは、本明細書の提案5−2に対する例を示す信号流れ図である。

0377

提案5−2によると、MMTEL/SMS over IPのためのIMS階層がMO MMTEL音声/MMTEL映像、MO SMS overIPサービス連結を開始する時、AS階層(例えば、RRC階層)から提供を受けたMMTEL音声/MMTEL映像/SMS over IPサービスに対するACBスキップ情報を確認し、もし、MMTEL音声及び/またはMMTEL映像及び/またはSMS over IPに対してACB skippingbit=set/trueの場合、MMTELのためのIMS階層がMMTEL音声、MMTEL映像のためのセッション/呼び(call)の開始を知らせるACBスキップ開始インジケーション/情報をNAS階層に提供する。同様に、SMS over IPのためのIMS階層がSMS over IPのためのセッションの開始を知らせるACBスキップ開始インジケーション/情報をNAS階層に提供する。

0378

また、提案5−2によると、MMTEL/SMS over IPのためのIMS階層からMO MMTEL音声、MO MMTEL映像or MO SMS over IPのためのセッション/呼び(call)に対するACBスキップ開始インジケーション/情報(即ち、ACB skip begin indication)を受信すると、NAS階層は、前記セッション/呼び(call)が一般データセッション/呼び(call)でないMMTEL音声、MMTEL映像及び/またはSMS over IPのためのセッション/呼び(call)開始であることを認知するようになる。以後、NAS階層は、MMTEL音声、MMTEL映像またはSMS over IPのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ACBスキップインジケーション(即ち、ACB skip=set/true)を共にAS階層(例えば、RRC階層)に提供する。

0379

図20a及び図20bは、本明細書の提案5−2の内容のうち、SMSに対する例を示す信号流れ図である。

0380

図20a及び図20bを参照すると、SMS(SMS over SGs;SMS over NAS)の場合、NAS階層は、MO(Mobile Originated)SMS連結のためのサービス要求手順の開始時、呼びタイプ(call type)は、originating SMS for MO SMS(SMS over SGs)に設定し、RRC確立原因は、MO dataに設定する。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ