JP6161825B2

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

Info

Publication number: JP6161825B2
Application number: JP2016540830A
Authority: JP
Inventors: ジェヒュンキム，; ヨンデリ，; レヨンキム，; ヒュンソクキム，; テフンキム，; スンフンジュン，
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2014-03-19
Filing date: 2015-03-18
Publication date: 2017-07-12
Anticipated expiration: 2035-03-18
Also published as: EP3119156A1; WO2015142049A1; EP3122145B1; KR20160052569A; KR20160048819A; EP3119156A4; US20160227468A1; CN105659691A; CN105794300A; EP3122145A1; JP6169799B2; KR101828725B1; US20160227469A1; JP2017184287A; EP3122145A4; WO2015142048A1; JP2016529855A; JP2016529856A

Description

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

移動通信システムの技術規格を制定する３ＧＰＰでは、４世代移動通信と関連した多様なフォーラム及び新しい技術に対応するために、２００４年末から３ＧＰＰ技術の性能を最適化させて向上させようとする努力の一環としてＬＴＥ/ＳＡＥ(ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ/ＳｙｓｔｅｍＡｒｃｈｉｔｅｃｔｕｒｅＥｖｏｌｕｔｉｏｎ)技術に対する研究を始めた。

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

３ＧＰＰＳＡＷＧ２で定義したＥＰＳ(ＥｖｏｌｖｅｄＰａｃｋｅｔＳｙｓｔｅｍ)上位水準参照モデル(ｒｅｆｅｒｅｎｃｅｍｏｄｅｌ)は、非ローミングケース(ｎｏｎ−ｒｏａｍｉｎｇｃａｓｅ)及び多様なシナリオのローミングケース(ｒｏａｍｉｎｇｃａｓｅ)を含んでおり、詳細内容は、３ＧＰＰ標準文書ＴＳ２３.４０１とＴＳ２３.４０２で参照することができる。図１のネットワーク構造図は、これを簡略に再構成したものである。

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

ＥＰＣは、多様な構成要素を含むことができ、図１は、そのうち一部に該当する、Ｓ−ＧＷ(ＳｅｒｖｉｎｇＧａｔｅｗａｙ)５２、ＰＤＮＧＷ(ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋＧａｔｅｗａｙ)５３、ＭＭＥ(ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ)５１、ＳＧＳＮ(ＳｅｒｖｉｎｇＧＰＲＳ(ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ) ＳｕｐｐｏｒｔｉｎｇＮｏｄｅ)、ｅＰＤＧ(ｅｎｈａｎｃｅｄＰａｃｋｅｔＤａｔａＧａｔｅｗａｙ)を示す。

Ｓ−ＧＷ５２は、無線アクセスネットワーク(ＲＡＮ)とコアネットワークとの間の境界点として動作し、ｅＮｏｄｅＢ２２とＰＤＮＧＷ５３との間のデータ経路を維持する機能をする要素である。また、端末(または、ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ＵＥ)がｅＮｏｄｅＢ２２によりサービング(ｓｅｒｖｉｎｇ)される領域にわたって移動する場合、Ｓ−ＧＷ５２は、ローカル移動性アンカーポイント(ａｎｃｈｏｒｐｏｉｎｔ)の役割をする。即ち、Ｅ−ＵＴＲＡＮ(３ＧＰＰリリース８以後で定義されるＥｖｏｌｖｅｄ−ＵＭＴＳ(ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｙｓｔｅｍ) ＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ)内での移動性のために、Ｓ−ＧＷ５２を介してパケットがルーティングされることができる。また、Ｓ−ＧＷ５２は、他の３ＧＰＰネットワーク(３ＧＰＰリリース８以前に定義されるＲＡＮ、例えば、ＵＴＲＡＮまたはＧＥＲＡＮ(ＧＳＭ（登録商標）(ＧｌｏｂａｌＳｙｓｔｅｍｆｏｒＭｏｂｉｌｅＣｏｍｍｕｎｉｃａｔｉｏｎ)/ＥＤＧＥ(ＥｎｈａｎｃｅｄＤａｔａｒａｔｅｓｆｏｒＧｌｏｂａｌＥｖｏｌｕｔｉｏｎ) ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ)との移動性のためのアンカーポイントとして機能することもできる。

ＰＤＮＧＷ(または、Ｐ−ＧＷ)５３は、パケットデータネットワークに向かうデータインターフェースの終端点(ｔｅｒｍｉｎａｔｉｏｎｐｏｉｎｔ)に該当する。ＰＤＮＧＷ５３は、政策執行特徴(ｐｏｌｉｃｙｅｎｆｏｒｃｅｍｅｎｔｆｅａｔｕｒｅｓ)、パケットフィルタリング(ｐａｃｋｅｔｆｉｌｔｅｒｉｎｇ)、課金サポート(ｃｈａｒｇｉｎｇｓｕｐｐｏｒｔ)などをサポートすることができる。また、３ＧＰＰネットワークと非３ＧＰＰネットワーク(例えば、Ｉ−ＷＬＡＮ(ＩｎｔｅｒｗｏｒｋｉｎｇＷｉｒｅｌｅｓｓＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ)のような信頼されないネットワーク、ＣＤＭＡ(ＣｏｄｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ)ネットワークやＷｉＭａｘのような信頼されるネットワーク)との移動性管理のためのアンカーポイント役割をすることができる。

図１のネットワーク構造の例示は、Ｓ−ＧＷ５２とＰＤＮＧＷ５３が別途のゲートウェイで構成されるものを示すが、二つのゲートウェイが単一ゲートウェイ構成オプション(ＳｉｎｇｌｅＧａｔｅｗａｙＣｏｎｆｉｇｕｒａｔｉｏｎＯｐｔｉｏｎ)によって具現されることもできる。

ＭＭＥ５１は、ＵＥのネットワーク連結に対するアクセス、ネットワークリソースの割当、トラッキング(ｔｒａｃｋｉｎｇ)、ページング(ｐａｇｉｎｇ)、ローミング(ｒｏａｍｉｎｇ)及びハンドオーバなどをサポートするためのシグナリング及び制御機能を実行する要素である。ＭＭＥ５１は、加入者及びセッション管理に関連した制御平面(ｃｏｎｔｒｏｌｐｌａｎｅ)機能を制御する。ＭＭＥ５１は、数多くのｅＮｏｄｅＢ２２を管理し、他の２Ｇ/３Ｇネットワークに対するハンドオーバのための従来のゲートウェイの選択のためのシグナリングを実行する。また、ＭＭＥ５１は、セキュリティ過程(ＳｅｃｕｒｉｔｙＰｒｏｃｅｄｕｒｅｓ)、端末−対−ネットワークセッションハンドリング(Ｔｅｒｍｉｎａｌ−ｔｏ−ｎｅｔｗｏｒｋＳｅｓｓｉｏｎＨａｎｄｌｉｎｇ)、アイドル端末位置決定管理(ＩｄｌｅＴｅｒｍｉｎａｌＬｏｃａｔｉｏｎＭａｎａｇｅｍｅｎｔ)などの機能を遂行する。

ＳＧＳＮは、異なるアクセス３ＧＰＰネットワーク(例えば、ＧＰＲＳネットワーク、ＵＴＲＡＮ/ＧＥＲＡＮ)に対するユーザの移動性管理及び認証(ａｕｔｈｅｎｔｉｃａｔｉｏｎ)といった全てのパケットデータをハンドリングする。

ｅＰＤＧは、信頼されない非３ＧＰＰネットワーク(例えば、Ｉ−ＷＬＡＮ、ＷｉＦｉホットスポット(ｈｏｔｓｐｏｔ)等)に対するセキュリティノードとしての役割をする。

図１を参照して説明したように、ＩＰ能力を有する端末(または、ＵＥ)は、３ＧＰＰアクセスはもちろん非３ＧＰＰアクセスに基づいても、ＥＰＣ内の多様な要素を経由して事業者(即ち、オペレータ(ｏｐｅｒａｔｏｒ))が提供するＩＰサービスネットワーク(例えば、ＩＭＳ)にアクセスすることができる。

また、図１は、多様なレファレンスポイント(例えば、Ｓ１−Ｕ、Ｓ１−ＭＭＥ等)を示す。３ＧＰＰシステムでは、Ｅ−ＵＴＲＡＮ及びＥＰＣの異なる機能エンティティ(ｆｕｎｃｔｉｏｎａｌｅｎｔｉｔｙ)に存在する２個の機能を連結する概念的なリンクをレファレンスポイント(ｒｅｆｅｒｅｎｃｅｐｏｉｎｔ)と定義する。以下の表１は、図１に示すレファレンスポイントを整理したものである。表１の例示外にもネットワーク構造によって多様なレファレンスポイントが存在できる。

図１に示すレファレンスポイントのうち、Ｓ２ａ及びＳ２ｂは、非３ＧＰＰインターフェースに該当する。Ｓ２ａは、信頼される非３ＧＰＰアクセス及びＰＤＮＧＷ間の関連制御及び移動性サポートをユーザ平面に提供するレファレンスポイントである。Ｓ２ｂは、ｅＰＤＧ及びＰＤＮＧＷ間の関連制御及び移動性サポートをユーザ平面に提供するレファレンスポイントである。

図２は、一般的にＥ−ＵＴＲＡＮと一般的なＥＰＣのアーキテクチャを示す例示図である。

図示されたように、ｅＮｏｄｅＢ２０は、ＲＲＣ接続が活性化されている中、ゲートウェイへのルーティング、ページングメッセージのスケジューリング及び送信、ブロードキャスタチャネル(ＢＣＨ)のスケジューリング及び送信、アップリンク及びダウンリンクでのリソースをＵＥに動的割当、ｅＮｏｄｅＢ２０の測定のための設定及び提供、無線ベアラ制御、無線許可制御(ｒａｄｉｏａｄｍｉｓｓｉｏｎｃｏｎｔｒｏｌ)、そして、接続移動性制御などのための機能を遂行することができる。ＥＰＣ内では、ページング発生、ＬＴＥ_ＩＤＬＥ状態管理、ユーザ平面の暗号化、ＥＰＳベアラ制御、ＮＡＳシグナリングの暗号化及び完全性保護機能を遂行することができる。

図３は、ＵＥとｅＮｏｄｅＢとの間の制御平面での無線インターフェースプロトコル(ＲａｄｉｏＩｎｔｅｒｆａｃｅＰｒｏｔｏｃｏｌ)の構造を示す例示図であり、図４は、端末と基地局との間のユーザ平面での無線インターフェースプロトコル(ＲａｄｉｏＩｎｔｅｒｆａｃｅＰｒｏｔｏｃｏｌ)の構造を示す他の例示図である。

前記無線インターフェースプロトコルは、３ＧＰＰ無線アクセスネットワーク規格に基盤とする。前記無線インターフェースプロトコルは、水平的には物理階層(ＰｈｙｓｉｃａｌＬａｙｅｒ)、データリンク階層(ＤａｔａＬｉｎｋＬａｙｅｒ)、及びネットワーク階層(ＮｅｔｗｏｒｋＬａｙｅｒ)からなり、垂直的にはデータ情報送信のためのユーザ平面(ＵｓｅｒＰｌａｎｅ)と、制御信号(Ｓｉｇｎａｌｉｎｇ)伝達のための制御平面(ＣｏｎｔｒｏｌＰｌａｎｅ)とに区分される。

前記プロトコル階層は、通信システムで広く知られた開放型システム間相互接続(ＯｐｅｎＳｙｓｔｅｍＩｎｔｅｒｃｏｎｎｅｃｔｉｏｎ；ＯＳＩ)基準モデルの下位３個階層に基づいてＬ１(第１の階層)、Ｌ２(第２の階層)、Ｌ３(第３の階層)に区分されることができる。

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

第１の階層である物理階層は、物理チャネル(ＰｈｙｓｉｃａｌＣｈａｎｎｅｌ)を利用して情報転送サービス(ＩｎｆｏｒｍａｔｉｏｎＴｒａｎｓｆｅｒＳｅｒｖｉｃｅ)を提供する。前記物理階層は、上位にある媒体アクセス制御(ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ)階層とはトランスポートチャネル(ＴｒａｎｓｐｏｒｔＣｈａｎｎｅｌ)を介して連結されており、前記トランスポートチャネルを介して媒体アクセス制御階層と物理階層との間のデータが伝達される。そして、互いに異なる物理階層間、即ち、送信側と受信側の物理階層間は、物理チャネルを介してデータが伝達される。

物理チャネル(ＰｈｙｓｉｃａｌＣｈａｎｎｅｌ)は、時間軸上にある複数個のサブフレームと、周波数軸上にある複数個のサブキャリア(Ｓｕｂ−ｃａｒｒｉｅｒ)とで構成される。ここで、一つのサブフレーム(Ｓｕｂ−ｆｒａｍｅ)は、時間軸上に複数のシンボル(Ｓｙｍｂｏｌ)と複数のサブキャリアとで構成される。一つのサブフレームは、複数のリソースブロック(ＲｅｓｏｕｒｃｅＢｌｏｃｋ)で構成され、一つのリソースブロックは、複数のシンボル(Ｓｙｍｂｏｌ)と複数のサブキャリアとで構成される。データが送信される単位時間であるＴＴＩ(ＴｒａｎｓｍｉｓｓｉｏｎＴｉｍｅＩｎｔｅｒｖａｌ)は、１個のサブフレームに該当する１ｍｓである。

前記送信側と受信側の物理階層に存在する物理チャネルは、３ＧＰＰＬＴＥによると、データチャネルであるＰＤＳＣＨ(ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ)及びＰＵＳＣＨ(ＰｈｙｓｉｃａｌＵｐｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ)と、制御チャネルであるＰＤＣＣＨ(ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ)、ＰＣＦＩＣＨ(ＰｈｙｓｉｃａｌＣｏｎｔｒｏｌＦｏｒｍａｔＩｎｄｉｃａｔｏｒＣｈａｎｎｅｌ)、ＰＨＩＣＨ(ＰｈｙｓｉｃａｌＨｙｂｒｉｄ−ＡＲＱＩｎｄｉｃａｔｏｒＣｈａｎｎｅｌ)及びＰＵＣＣＨ(ＰｈｙｓｉｃａｌＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ)と、に分けられる。

サブフレームの１番目のＯＦＤＭシンボルで送信されるＰＣＦＩＣＨは、サブフレーム内で制御チャネルの送信に使われるＯＦＤＭシンボルの数(即ち、制御領域の大きさ)に対するＣＦＩ(ｃｏｎｔｒｏｌｆｏｒｍａｔｉｎｄｉｃａｔｏｒ)を伝送する。無線機器は、まず、ＰＣＦＩＣＨ上にＣＦＩを受信した後、ＰＤＣＣＨをモニタリングする。

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

ＰＨＩＣＨは、ＵＬＨＡＲＱ(ｈｙｂｒｉｄａｕｔｏｍａｔｉｃｒｅｐｅａｔｒｅｑｕｅｓｔ)のためのＡＣＫ(ｐｏｓｉｔｉｖｅ−ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ)/ＮＡＣＫ(ｎｅｇａｔｉｖｅ−ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ)信号を伝送する。無線機器により送信されるＰＵＳＣＨ上のＵＬ(ｕｐｌｉｎｋ)データに対するＡＣＫ/ＮＡＣＫ信号は、ＰＨＩＣＨ上に送信される。

ＰＢＣＨ(ＰｈｙｓｉｃａｌＢｒｏａｄｃａｓｔＣｈａｎｎｅｌ)は、無線フレームの１番目のサブフレームの第２のスロットの前方部の４個のＯＦＤＭシンボルで送信される。ＰＢＣＨは、無線機器が基地局と通信するときに必須なシステム情報を伝送し、ＰＢＣＨを介して送信されるシステム情報をＭＩＢ(ｍａｓｔｅｒｉｎｆｏｒｍａｔｉｏｎｂｌｏｃｋ)という。これと比較して、ＰＤＣＣＨにより指示されるＰＤＳＣＨ上に送信されるシステム情報をＳＩＢ(ｓｙｓｔｅｍｉｎｆｏｒｍａｔｉｏｎｂｌｏｃｋ)という。

ＰＤＣＣＨは、ＤＬ−ＳＣＨ(ｄｏｗｎｌｉｎｋ−ｓｈａｒｅｄｃｈａｎｎｅｌ)のリソース割当及び送信フォーマット、ＵＬ−ＳＣＨ(ｕｐｌｉｎｋｓｈａｒｅｄｃｈａｎｎｅｌ)のリソース割当情報、ＰＣＨ上のページング情報、ＤＬ−ＳＣＨ上のシステム情報、ＰＤＳＣＨ上に送信されるランダムアクセス応答のような上位階層制御メッセージのリソース割当、任意のＵＥグループ内の個別ＵＥに対する送信パワー制御命令のセット及びＶｏＩＰ(ｖｏｉｃｅｏｖｅｒｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ)の活性化などを伝送することができる。複数のＰＤＣＣＨが制御領域内で送信されることができ、端末は、複数のＰＤＣＣＨをモニタリングすることができる。ＰＤＣＣＨは、一つまたは複数個の連続的なＣＣＥ(ｃｏｎｔｒｏｌｃｈａｎｎｅｌｅｌｅｍｅｎｔｓ)のアグリゲーション(ａｇｇｒｅｇａｔｉｏｎ)上に送信される。ＣＣＥは、無線チャネルの状態による符号化率をＰＤＣＣＨに提供するために使われる論理的割当単位である。ＣＣＥは、複数のリソース要素グループ(ｒｅｓｏｕｒｃｅｅｌｅｍｅｎｔｇｒｏｕｐ)に対応される。ＣＣＥの数とＣＣＥにより提供される符号化率の関係によってＰＤＣＣＨのフォーマット及び可能なＰＤＣＣＨのビット数が決定される。

ＰＤＣＣＨを介して送信される制御情報をダウンリンク制御情報(ｄｏｗｎｌｉｎｋｃｏｎｔｒｏｌｉｎｆｏｒｍａｔｉｏｎ、ＤＣＩ)という。ＤＣＩは、ＰＤＳＣＨのリソース割当(これをＤＬグラント(ｄｏｗｎｌｉｎｋｇｒａｎｔ)ともいう)、ＰＵＳＣＨのリソース割当(これをＵＬグラント(ｕｐｌｉｎｋｇｒａｎｔ)ともいう)、任意のＵＥグループ内の個別ＵＥに対する送信パワー制御命令のセット及び/またはＶｏＩＰ(ＶｏｉｃｅｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ)の活性化を含むことができる。

第２の階層にはさまざまな階層が存在する。まず、媒体アクセス制御(ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ；ＭＡＣ)階層は、多様な論理チャネル(ＬｏｇｉｃａｌＣｈａｎｎｅｌ)を多様なトランスポートチャネルにマッピングさせる役割をし、また、複数の論理チャネルを一つのトランスポートチャネルにマッピングさせる論理チャネル多重化(Ｍｕｌｔｉｐｌｅｘｉｎｇ)の役割を遂行する。ＭＡＣ階層は、上位階層であるＲＬＣ階層とは論理チャネル(ＬｏｇｉｃａｌＣｈａｎｎｅｌ)を介して接続されており、論理チャネルは、大いに、送信される情報の種類によって、制御平面(ＣｏｎｔｒｏｌＰｌａｎｅ)の情報を送信する制御チャネル(ＣｏｎｔｒｏｌＣｈａｎｎｅｌ)と、ユーザ平面(ＵｓｅｒＰｌａｎｅ)の情報を送信するトラフィックチャネル(ＴｒａｆｆｉｃＣｈａｎｎｅｌ)と、に分けられる。

第２の階層の無線リンク制御(ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ；ＲＬＣ)階層は、上位階層から受信したデータを分割(Ｓｅｇｍｅｎｔａｔｉｏｎ)及び連結(Ｃｏｎｃａｔｅｎａｔｉｏｎ)して下位階層が無線区間へのデータの送信に適合するようにデータの大きさを調節する役割を遂行する。また、各々の無線ベアラ(ＲａｄｉｏＢｅａｒｅｒ；ＲＢ)が要求する多様なＱｏＳが保障可能にするために、ＴＭ(ＴｒａｎｓｐａｒｅｎｔＭｏｄｅ、透明モード)、ＵＭ(Ｕｎ−ａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ、無応答モード)、及びＡＭ(ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ、応答モード)の三つの動作モードを提供している。特に、ＡＭＲＬＣは、信頼性のあるデータ送信のために、自動反復及び要求(ＡｕｔｏｍａｔｉｃＲｅｐｅａｔａｎｄＲｅｑｕｅｓｔ；ＡＲＱ)機能を介した再送信機能を遂行している。

第２の階層のパケットデータ収束(ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ；ＰＤＣＰ)階層は、ＩＰｖ４やＩＰｖ６のようなＩＰパケット送信時、帯域幅が小さい無線区間で効率的に送信するために相対的に大きさが大きくて不要な制御情報を含んでいるＩＰパケットヘッダサイズを減らすヘッダ圧縮(ＨｅａｄｅｒＣｏｍｐｒｅｓｓｉｏｎ)機能を遂行する。これはデータのヘッダ(Ｈｅａｄｅｒ)部分で必ず必要な情報のみを送信するようにすることで、無線区間の送信効率を増加させる役割をする。また、ＬＴＥシステムでは、ＰＤＣＰ階層がセキュリティ(Ｓｅｃｕｒｉｔｙ)機能も実行し、これは第３者のデータ盗聴を防止する暗号化(Ｃｉｐｈｅｒｉｎｇ)と第３者のデータ操作を防止する完全性保護(Ｉｎｔｅｇｒｉｔｙｐｒｏｔｅｃｔｉｏｎ)とで構成される。

第３階層の最も上部に位置した無線リソース制御(ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ；以下、ＲＲＣと略称する)階層は、制御平面でのみ定義され、無線ベアラ(ＲａｄｉｏＢｅａｒｅｒ；ＲＢと略称する)の設定(Ｃｏｎｆｉｇｕｒａｔｉｏｎ)、再設定(Ｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ)及び解除(Ｒｅｌｅａｓｅ)と関連して論理チャネル、トランスポートチャネル、及び物理チャネルの制御を担当する。このとき、ＲＢは、端末とＥ−ＵＴＲＡＮとの間のデータ伝達のために、第２の階層により提供されるサービスを意味する。

前記端末のＲＲＣと無線ネットワークのＲＲＣ階層との間にＲＲＣ接続(ＲＲＣｃｏｎｎｅｃｔｉｏｎ)がある場合、端末は、ＲＲＣ接続状態(ＣｏｎｎｅｃｔｅｄＭｏｄｅ)になり、そうでない場合、ＲＲＣアイドル状態(ＩｄｌｅＭｏｄｅ)になる。

以下、端末のＲＲＣ状態(ＲＲＣｓｔａｔｅ)とＲＲＣ接続方法に対して説明する。ＲＲＣ状態とは、端末のＲＲＣがＥ−ＵＴＲＡＮのＲＲＣと論理的接続(ｌｏｇｉｃａｌｃｏｎｎｅｃｔｉｏｎ)されているかどうかを意味し、接続されている場合はＲＲＣ_ＣＯＮＮＥＣＴＥＤ状態(ｓｔａｔｅ)といい、接続されていない場合はＲＲＣ_ＩＤＬＥ状態という。ＲＲＣ_ＣＯＮＮＥＣＴＥＤ状態の端末は、ＲＲＣ接続が存在するため、Ｅ−ＵＴＲＡＮは、該当端末の存在をセル単位で把握することができ、したがって、端末を効果的に制御することができる。それに対し、ＲＲＣ_ＩＤＬＥ状態の端末は、Ｅ−ＵＴＲＡＮが端末の存在を把握することはできず、セルより大きい地域単位であるＴＡ(ＴｒａｃｋｉｎｇＡｒｅａ)単位に核心ネットワークが管理する。即ち、ＲＲＣ_ＩＤＬＥ状態の端末は、セルに比べて大きい地域単位に該当端末の存在可否のみが把握され、音声やデータのような通常の移動通信サービスを受けるためには、該当端末がＲＲＣ_ＣＯＮＮＥＣＴＥＤ状態に移動しなければならない。各ＴＡは、ＴＡＩ(Ｔｒａｃｋｉｎｇａｒｅａｉｄｅｎｔｉｔｙ)を介して区分される。端末は、セルで放送(ｂｒｏａｄｃａｓｔｉｎｇ)される情報であるＴＡＣ(Ｔｒａｃｋｉｎｇａｒｅａｃｏｄｅ)を介してＴＡＩを構成することができる。

ユーザが端末の電源を最初にオンした時、端末は、まず、適切なセルを探索した後、該当セルでＲＲＣ接続を確立し、核心ネットワークに端末の情報を登録する。この後、端末は、ＲＲＣ_ＩＤＬＥ状態にとどまる。ＲＲＣ_ＩＤＬＥ状態にとどまる端末は、必要によって、セルを(再)選択し、システム情報(Ｓｙｓｔｅｍｉｎｆｏｒｍａｔｉｏｎ)やページング情報を確認する。これをセルにキャンプオン(Ｃａｍｐｏｎ)するという。ＲＲＣ_ＩＤＬＥ状態にとどまっていた端末は、ＲＲＣ接続を確立する必要がある時はじめてＲＲＣ接続過程(ＲＲＣｃｏｎｎｅｃｔｉｏｎｐｒｏｃｅｄｕｒｅ)を介してＥ−ＵＴＲＡＮのＲＲＣとＲＲＣ接続を確立し、ＲＲＣ_ＣＯＮＮＥＣＴＥＤ状態に移動する。ＲＲＣ_ＩＤＬＥ状態にあった端末がＲＲＣ接続を確立する必要がある場合は多様であり、例えば、ユーザの通話試みなどの理由でアップリンクデータ送信が必要であり、またはＥ−ＵＴＲＡＮからページングメッセージを受信した場合、これに対する応答メッセージ送信などを挙げることができる。

前記ＲＲＣ階層の上位に位置するＮＡＳ(Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ)階層は、セッション管理(ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔ)と移動性管理(ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ)等の機能を遂行する。

以下、図３に示すＮＡＳ階層に対して詳細に説明する。

ＮＡＳ階層に属するＥＳＭ(ＥｖｏｌｖｅｄＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔ)は、ＤｅｆａｕｌｔＢｅａｒｅｒ管理及びＤｅｄｉｃａｔｅｄＢｅａｒｅｒ管理のような機能を遂行し、端末がネットワークからＰＳサービスを利用するための制御を担当する。ＤｅｆａｕｌｔＢｅａｒｅｒリソースは、特定ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋ(ＰＤＮ)に最初接続する時またはネットワークに接続される時、ネットワークから割当を受けるという特徴を有する。このとき、ネットワークは、端末がデータサービスを使用することができるように端末が使用可能なＩＰアドレスを割り当て、また、ｄｅｆａｕｌｔｂｅａｒｅｒのＱｏＳを割り当てる。ＬＴＥでは、大いに、データ送受信のための特定帯域幅を保障するＧＢＲ(Ｇｕａｒａｎｔｅｅｄｂｉｔｒａｔｅ)ＱｏＳ特性を有するｂｅａｒｅｒと、帯域幅の保障無しでＢｅｓｔｅｆｆｏｒｔＱｏＳ特性を有するＮｏｎ−ＧＢＲｂｅａｒｅｒの２種類をサポートする。Ｄｅｆａｕｌｔｂｅａｒｅｒの場合、Ｎｏｎ−ＧＢＲｂｅａｒｅｒの割当を受ける。Ｄｅｄｉｃａｔｅｄｂｅａｒｅｒの場合は、ＧＢＲまたはＮｏｎ−ＧＢＲのＱｏＳ特性を有するｂｅａｒｅｒの割当を受けることができる。

ネットワークから端末に割り当てたｂｅａｒｅｒをＥＰＳ(ｅｖｏｌｖｅｄｐａｃｋｅｔｓｅｒｖｉｃｅ)ｂｅａｒｅｒといい、ＥＰＳｂｅａｒｅｒを割当する時、ネットワークは、一つのＩＤを割り当てるようになる。これをＥＰＳＢｅａｒｅｒＩＤという。一つのＥＰＳｂｅａｒｅｒは、ＭＢＲ(ｍａｘｉｍｕｍｂｉｔｒａｔｅ)とＧＢＲ(ｇｕａｒａｎｔｅｅｄｂｉｔｒａｔｅ)またはＡＭＢＲ(Ａｇｇｒｅｇａｔｅｄｍａｘｉｍｕｍｂｉｔｒａｔｅ)のＱｏＳ特性を有する。

一方、図３において、ＮＡＳ階層下に位置するＲＲＣ階層、ＲＬＣ階層、ＭＡＣ階層、ＰＨＹ階層を束ねてアクセス階層(ＡｃｃｅｓｓＳｔｒａｔｕｍ：ＡＳ)とも呼ばれる。

図５ａは、３ＧＰＰＬＴＥでランダムアクセス過程を示す流れ図である。

ランダムアクセス過程は、ＵＥ１０が基地局、即ち、ｅＮｏｄｅＢ２０とＵＬ同期を得たり、ＵＬ無線リソースの割当を受けたりするために使われる。

ＵＥ１０は、ルートインデックス(ｒｏｏｔｉｎｄｅｘ)とＰＲＡＣＨ(ｐｈｙｓｉｃａｌｒａｎｄｏｍａｃｃｅｓｓｃｈａｎｎｅｌ)設定インデックス(ｃｏｎｆｉｇｕｒａｔｉｏｎｉｎｄｅｘ)をｅＮｏｄｅＢ２０から受信する。各セル毎にＺＣ(Ｚａｄｏｆｆ−Ｃｈｕ)シーケンスにより定義される６４個の候補(ｃａｎｄｉｄａｔｅ)ランダムアクセスプリアンブルがあり、ルートインデックスは、端末が６４個の候補ランダムアクセスプリアンブルを生成するための論理的インデックスである。

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

ＵＥ１０は、任意に選択されたランダムアクセスプリアンブルをｅＮｏｄｅＢ２０に送信する。ＵＥ１０は、６４個の候補ランダムアクセスプリアンブルの中から一つを選択する。そして、ＰＲＡＣＨ設定インデックスにより該当するサブフレームを選択する。ＵＥ１０は、選択されたランダムアクセスプリアンブルを選択されたサブフレームで送信する。

前記ランダムアクセスプリアンブルを受信したｅＮｏｄｅＢ２０は、ランダムアクセス応答(ｒａｎｄｏｍａｃｃｅｓｓｒｅｓｐｏｎｓｅ、ＲＡＲ)をＵＥ１０に送る。ランダムアクセス応答は、２ステップに検出される。まず、ＵＥ１０は、ＲＡ−ＲＮＴＩ(ｒａｎｄｏｍａｃｃｅｓｓ−ＲＮＴＩ)でマスキングされたＰＤＣＣＨを検出する。ＵＥ１０は、検出されたＰＤＣＣＨにより指示されるＰＤＳＣＨ上にＭＡＣ(ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ)ＰＤＵ(ＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ)内のランダムアクセス応答を受信する。

図５ｂは、無線リソース制御(ＲＲＣ)階層での接続過程を示す。

図５ｂに示すように、ＲＲＣ接続可否によるＲＲＣ状態が示されている。前記ＲＲＣ状態とは、ＵＥ１０のＲＲＣ階層のエンティティ(ｅｎｔｉｔｙ)がｅＮｏｄｅＢ２０のＲＲＣ階層のエンティティと論理的接続(ｌｏｇｉｃａｌｃｏｎｎｅｃｔｉｏｎ)されているかどうかを意味し、接続されている場合をＲＲＣ接続状態(ｃｏｎｎｅｃｔｅｄｓｔａｔｅ)といい、接続されていない状態をＲＲＣアイドル状態(ｉｄｌｅｓｔａｔｅ)という。

前記接続状態(Ｃｏｎｎｅｃｔｅｄｓｔａｔｅ)のＵＥ１０は、ＲＲＣ接続(ｃｏｎｎｅｃｔｉｏｎ)が存在するため、Ｅ−ＵＴＲＡＮは、該当端末の存在をセル単位で把握することができ、したがって、ＵＥ１０を効果的に制御することができる。それに対し、アイドル状態(ｉｄｌｅｓｔａｔｅ)のＵＥ１０は、ｅＮｏｄｅＢ２０が把握することはできず、セルより大きい地域単位であるトラッキング地域(ＴｒａｃｋｉｎｇＡｒｅａ)単位に核心ネットワーク(ＣｏｒｅＮｅｔｗｏｒｋ)が管理する。前記トラッキング地域(ＴｒａｃｋｉｎｇＡｒｅａ)は、セルの集合単位である。即ち、アイドル状態(ｉｄｌｅｓｔａｔｅ)のＵＥ１０は、大きい地域単位に存在可否のみが把握され、音声やデータのような通常の移動通信サービスを受けるために、端末は、接続状態(ｃｏｎｎｅｃｔｅｄｓｔａｔｅ)に切り替えしなければならない。

ユーザがＵＥ１０の電源を最初にオンにした時、前記ＵＥ１０は、まず、適切なセルを探索した後、該当セルでアイドル状態(ｉｄｌｅｓｔａｔｅ)にとどまる。前記アイドル状態(ｉｄｌｅｓｔａｔｅ)のＵＥ１０は、ＲＲＣ接続を確立する必要がある時になって初めてＲＲＣ接続過程(ＲＲＣｃｏｎｎｅｃｔｉｏｎｐｒｏｃｅｄｕｒｅ)を介してｅＮｏｄｅＢ２０のＲＲＣ階層とＲＲＣ接続を確立することでＲＲＣ接続状態(ｃｏｎｎｅｃｔｅｄｓｔａｔｅ)に切り替える。

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

アイドル状態(ｉｄｌｅｓｔａｔｅ)のＵＥ１０が前記ｅＮｏｄｅＢ２０とＲＲＣ接続を確立するためには、前記したように、ＲＲＣ接続過程(ＲＲＣｃｏｎｎｅｃｔｉｏｎｐｒｏｃｅｄｕｒｅ)を進行しなければならない。ＲＲＣ接続過程は、大いに、ＵＥ１０がｅＮｏｄｅＢ２０にＲＲＣ接続要求(ＲＲＣｃｏｎｎｅｃｔｉｏｎｒｅｑｕｅｓｔ)メッセージ送信する過程、ｅＮｏｄｅＢ２０がＵＥ１０にＲＲＣ接続設定(ＲＲＣｃｏｎｎｅｃｔｉｏｎｓｅｔｕｐ)メッセージを送信する過程、そしてＵＥ１０がｅＮｏｄｅＢ２０にＲＲＣ接続設定完了(ＲＲＣｃｏｎｎｅｃｔｉｏｎｓｅｔｕｐｃｏｍｐｌｅｔｅ)メッセージを送信する過程を含む。このような過程に対して図５ｂを参照してより詳細に説明すると、下記の通りである。

１)アイドル状態(Ｉｄｌｅｓｔａｔｅ)のＵＥ１０は、通話試み、データ送信試み、またはｅＮｏｄｅＢ２０のページングに対する応答などの理由でＲＲＣ接続を確立しようとする場合、まず、前記ＵＥ１０は、ＲＲＣ接続要求(ＲＲＣｃｏｎｎｅｃｔｉｏｎｒｅｑｕｅｓｔ)メッセージをｅＮｏｄｅＢ２０に送信する。

２)前記ＵＥ１０からＲＲＣ接続要求メッセージを受信すると、前記ｅＮＢ２０は、無線リソースが十分な場合、前記ＵＥ１０のＲＲＣ接続要求を受諾し、応答メッセージであるＲＲＣ接続設定(ＲＲＣｃｏｎｎｅｃｔｉｏｎｓｅｔｕｐ)メッセージを前記ＵＥ１０に送信する。

３)前記ＵＥ１０が前記ＲＲＣ接続設定メッセージを受信すると、前記ｅＮｏｄｅＢ２０にＲＲＣ接続設定完了(ＲＲＣｃｏｎｎｅｃｔｉｏｎｓｅｔｕｐｃｏｍｐｌｅｔｅ)メッセージを送信する。前記ＵＥ１０がＲＲＣ接続設定メッセージを成功的に送信すると、そのとき、前記ＵＥ１０は、ｅＮｏｄｅＢ２０とＲＲＣ接続を確立するようになってＲＲＣ接続モードに切り替える。

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

他の一方、最近、ＭＭＴｅｌ(ＭｕｌｔｉｍｅｄｉａＴｅｌｅｐｈｏｎｙｓｅｒｖｉｃｅ)が多く研究された。前記ＭＭＴｅｌは、ＩＭＳ(ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ)に基づくグローバル標準であって、集中的(ｃｏｎｖｅｒｇｅｄ)、固定的(ｆｉｘｅｄ)モバイルリアルタイムマルチメディア通信を提供し、これを介して音声、リアルタイムビデオ、テキスト、ファイル送信などのようなメディア能力(ｍｅｄｉａｃａｐａｂｉｌｉｔｉｅｓ)を使用し、及び写真、オーディオ、ビデオクリップなどを共有することができる。ＭＭＴｅｌにおいて、ユーザは、セッション中にメディアを追加したり、または除外したりすることができる。即ち、セッション中にチャット、音声追加、他の発信者追加、ビデオ追加、メディア共有及びファイル送信、並びにこれらのうち特定能力に対する除去が可能である。

しかし、ＵＥがＭＭＴｅｌを実行することを希望する時、ネットワーク、例えば、基地局(即ち、ｅＮｏｄｅＢ)が混雑状態の場合はサービスを実行することができないという問題点がある。

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

前記のような目的を達成するために、本明細書の一開示は、ユーザ装置(ｕｓｅｒｅｑｕｉｐｍｅｎｔ：ＵＥ)におけるサービス要求手順(ＳｅｒｖｉｃｅＲｅｑｕｅｓｔｐｒｏｃｅｄｕｒｅ)を実行する方法を提供する。前記方法は、ＡＣＢ(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)検査に対するスキップ情報を受信するステップ；ＭＭＴＥＬ(ｍｕｌｔｉｍｅｄｉａｔｅｌｅｐｈｏｎｙ)サービス及び短文メッセージサービス(ＳＭＳ)のうちいずれか一つのためにサービス要求手順を実行すべき場合、前記スキップ情報を確認するステップ；及び、前記スキップ情報に前記ＭＭＴＥＬサービス及びＳＭＳのうちいずれか一つのためにはＡＣＢ検査をスキップするように設定されている場合、前記サービス要求手順のためにＲＲＣ(ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ)接続要求メッセージを送信するステップ；を含む。

前記ＭＭＴＥＬサービスは、ＭＭＴＥＬ音声及びＭＭＴＥＬ映像のうちいずれか一つのためのものである。

前記スキップ情報は、前記ＭＭＴＥＬ音声のためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報、前記ＭＭＴＥＬ映像のためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報、そして前記ＳＭＳのためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報を含む。

前記スキップ情報は、前記ＵＥのＲＲＣ階層が基地局から受信した後、ＮＡＳ階層または上位階層に伝達する。

前記サービス要求手順は、サービス要求メッセージまたは拡張サービス要求メッセージの送信を含む。

前記サービス要求メッセージまたは拡張サービス要求メッセージは、呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドを含む。前記呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドは、発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ音声、発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ映像、発信(ｏｒｉｇｉｎａｔｉｎｇ)ＳＭＳ(ｓｈｏｒｔｍｅｓｓａｇｅｓｅｒｖｉｃｅ)ｏｖｅｒＩＰまたは発信ＳＭＳのうちいずれか一つに設定される。

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてＭＭＴＥＬ音声呼び(ｃａｌｌ)が開示された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは：発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ音声に設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含む。

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてＭＭＴＥＬ映像呼び(ｃａｌｌ)が開示された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは：発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ映像に設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含む。

前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてＳＭＳｏｖｅｒＩＰが開示された場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは：発信(ｏｒｉｇｉｎａｔｉｎｇ)ＳＭＳｏｖｅｒＩＰに設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含む。

前記サービス要求メッセージまたは拡張サービス要求メッセージがＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)のためのアップリンクシグナリング(ＵＬｓｉｇｎａｌｉｎｇ)のためのリソースを要求するためのものである場合、前記サービス要求メッセージまたは拡張サービス要求メッセージは：発信(ｏｒｉｇｉｎａｔｉｎｇ)ＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)に設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含む。

前記サービス要求メッセージは、サービスタイプフィールドを含む。ここで、前記サービスタイプフィールドは、ＭＯＭＭＴＥＬｖｏｉｃｅ、ＭＯＭＭＴＥＬｖｉｄｅｏ、ＭＯＳＭＳｏｖｅｒＩＰ、またはＭＯＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)に設定される。

また、前記のような目的を達成するために、本明細書の一開示は、サービス要求手順(ＳｅｒｖｉｃｅＲｅｑｕｅｓｔｐｒｏｃｅｄｕｒｅ)を実行するユーザ装置(ｕｓｅｒｅｑｕｉｐｍｅｎｔ：ＵＥ)を提供する。前記ユーザ装置は、ＡＣＢ(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)検査に対するスキップ情報を受信する送受信部；及び、ＭＭＴＥＬ(ｍｕｌｔｉｍｅｄｉａｔｅｌｅｐｈｏｎｙ)サービス及び短文メッセージサービス(ＳＭＳ)のうちいずれか一つのためにサービス要求手順を実行すべき場合、前記スキップ情報を確認するプロセッサ；を含む。前記スキップ情報に前記ＭＭＴＥＬサービス及びＳＭＳのうちいずれか一つのためにはＡＣＢ検査をスキップするように設定されている場合、前記プロセッサは、前記送受信部を制御し、前記サービス要求手順のためにＲＲＣ(ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ)接続要求メッセージを送信する。
本明細書は、例えば、以下の項目も提供する。
（項目１）
ユーザ装置(ｕｓｅｒｅｑｕｉｐｍｅｎｔ：ＵＥ)におけるサービス要求手順(ＳｅｒｖｉｃｅＲｅｑｕｅｓｔｐｒｏｃｅｄｕｒｅ)を実行する方法であって、
ＡＣＢ(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)検査に対するスキップ情報を受信するステップ；
ＭＭＴＥＬ(ｍｕｌｔｉｍｅｄｉａｔｅｌｅｐｈｏｎｙ)サービス及び短文メッセージサービス(ＳＭＳ)のうちいずれか一つのためにサービス要求手順を実行すべき場合、前記スキップ情報を確認するステップ；及び、
前記スキップ情報に前記ＭＭＴＥＬサービス及びＳＭＳのうちいずれか一つのためにはＡＣＢ検査をスキップするように設定されている場合、前記サービス要求手順のためにＲＲＣ(ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ)接続要求メッセージを送信するステップ；を含むことを特徴とするサービス要求手順実行方法。
（項目２）
前記ＭＭＴＥＬサービスは、
ＭＭＴＥＬ音声及びＭＭＴＥＬ映像のうちいずれか一つのためのものであることを特徴とする項目１に記載のサービス要求手順実行方法。
（項目３）
前記スキップ情報は、
前記ＭＭＴＥＬ音声のためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報、前記ＭＭＴＥＬ映像のためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報、そして前記ＳＭＳのためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報を含むことを特徴とする項目２に記載のサービス要求手順実行方法。
（項目４）
前記スキップ情報は、前記ＵＥのＲＲＣ階層が基地局から受信した後、ＮＡＳ階層または上位階層に伝達することを特徴とする項目１に記載のサービス要求手順実行方法。
（項目５）
前記サービス要求手順は、
サービス要求メッセージまたは拡張サービス要求メッセージの送信を含むことを特徴とする項目１に記載のサービス要求手順実行方法。
（項目６）
前記サービス要求メッセージまたは拡張サービス要求メッセージは、呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドを含み、
前記呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドは、発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ音声、発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ映像、発信(ｏｒｉｇｉｎａｔｉｎｇ)ＳＭＳ(ｓｈｏｒｔｍｅｓｓａｇｅｓｅｒｖｉｃｅ)ｏｖｅｒＩＰまたは発信ＳＭＳのうちいずれか一つに設定されることを特徴とする項目５に記載のサービス要求手順実行方法。
（項目７）
前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてＭＭＴＥＬ音声呼び(ｃａｌｌ)が開示された場合、
前記サービス要求メッセージまたは拡張サービス要求メッセージは：
発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ音声に設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、
ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含むことを特徴とする項目５に記載のサービス要求手順実行方法。
（項目８）
前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてＭＭＴＥＬ映像呼び(ｃａｌｌ)が開示された場合、
前記サービス要求メッセージまたは拡張サービス要求メッセージは：
発信(ｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ映像に設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、
ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含むことを特徴とする項目５に記載のサービス要求手順実行方法。
（項目９）
前記サービス要求メッセージまたは拡張サービス要求メッセージがユーザ平面の無線リソースを要求するためのものである場合、そしてＳＭＳｏｖｅｒＩＰが開示された場合、
前記サービス要求メッセージまたは拡張サービス要求メッセージは：
発信(ｏｒｉｇｉｎａｔｉｎｇ)ＳＭＳｏｖｅｒＩＰに設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、
ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含むことを特徴とする項目５に記載のサービス要求手順実行方法。
（項目１０）
前記サービス要求メッセージまたは拡張サービス要求メッセージがＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)のためのアップリンクシグナリング(ＵＬｓｉｇｎａｌｉｎｇ)のためのリソースを要求するためのものである場合、
前記サービス要求メッセージまたは拡張サービス要求メッセージは：
発信(ｏｒｉｇｉｎａｔｉｎｇ)ＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)に設定された呼びタイプ(ｃａｌｌｔｙｐｅ)フィールドと、
ＭＯｄａｔａに設定された確立原因(ｅｓｔａｂｌｉｓｈｃａｕｓｅ)フィールドと、を含むことを特徴とする項目５に記載のサービス要求手順実行方法。
（項目１１）
前記サービス要求メッセージは、サービスタイプフィールドを含み、
前記サービスタイプフィールドは、ＭＯＭＭＴＥＬｖｏｉｃｅ、ＭＯＭＭＴＥＬｖｉｄｅｏ、ＭＯＳＭＳｏｖｅｒＩＰ、またはＭＯＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)に設定されることを特徴とする項目６に記載のサービス要求手順実行方法。
（項目１２）
サービス要求手順(ＳｅｒｖｉｃｅＲｅｑｕｅｓｔｐｒｏｃｅｄｕｒｅ)を実行するユーザ装置(ＵＥ)であって、
ＡＣＢ(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)検査に対するスキップ情報を受信する送受信部；及び、
ＭＭＴＥＬ(ｍｕｌｔｉｍｅｄｉａｔｅｌｅｐｈｏｎｙ)サービス及び短文メッセージサービス(ＳＭＳ)のうちいずれか一つのためにサービス要求手順を実行すべき場合、前記スキップ情報を確認するプロセッサ；を含み、
前記スキップ情報に前記ＭＭＴＥＬサービス及びＳＭＳのうちいずれか一つのためにはＡＣＢ検査をスキップするように設定されている場合、前記プロセッサは、前記送受信部を制御し、前記サービス要求手順のためにＲＲＣ(ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ)接続要求メッセージを送信することを特徴とするユーザ装置。
（項目１３）
前記ＭＭＴＥＬサービスは、
ＭＭＴＥＬ音声及びＭＭＴＥＬ映像のうちいずれか一つのためのものであることを特徴とする項目１１に記載のユーザ装置。
（項目１４）
前記スキップ情報は、
前記ＭＭＴＥＬ音声のためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報、前記ＭＭＴＥＬ映像のためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報、そして前記ＳＭＳのためのサービス要求手順に対してＡＣＢ検査を通過させるべきかどうかに対する情報を含むことを特徴とする項目１２に記載のユーザ装置。

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

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

一般的にＥ−ＵＴＲＡＮと一般的なＥＰＣのアーキテクチャを示す例示図である。

ＵＥとｅＮｏｄｅＢとの間の制御平面での無線インターフェースプロトコル(ＲａｄｉｏＩｎｔｅｒｆａｃｅＰｒｏｔｏｃｏｌ)の構造を示す例示図である。

端末と基地局との間のユーザ平面での無線インターフェースプロトコル(ＲａｄｉｏＩｎｔｅｒｆａｃｅＰｒｏｔｏｃｏｌ)の構造を示す他の例示図である。

３ＧＰＰＬＴＥでランダムアクセス過程を示す流れ図である。

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

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

ネットワーク混雑状態でアクセスクラスによる禁止(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)による動作を示す例示的な流れ図である。

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

本明細書の提案１−１、１−２及び１−３を示す信号流れ図である。本明細書の提案１−１、１−２及び１−３を示す信号流れ図である。

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

本明細書の提案２−１、２−２及び２−３を示す信号流れ図である。本明細書の提案２−１、２−２及び２−３を示す信号流れ図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本明細書の提案１０−１/１０−２/１０−３を示す信号流れ図である。本明細書の提案１０−１/１０−２/１０−３を示す信号流れ図である。

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

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

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

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

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

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

本発明の実施例に係るＵＥ１００及び基地局２００の構成ブロック図である。

本発明は、ＵＭＴＳ(ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＳｙｓｔｅｍ)及びＥＰＣ(ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ)を基準にして説明するが、このような通信システムにのみ限定されるものではなく、本発明の技術的思想が適用されることができる全ての通信システム及び方法にも適用されることができる。

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

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

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

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

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

添付図面には例示的にＵＥ(ＵｓｅｒＥｑｕｉｐｍｅｎｔ)が示されているが、図示された前記ＵＥは、端末(Ｔｅｒｍｉｎａｌ)、ＭＥ(ＭｏｂｉｌｅＥｑｕｉｐｍｅｎｔ)などの用語で呼ばれる場合もある。また、前記ＵＥは、ノートブック、携帯電話、ＰＤＡ、スマートフォン(ＳｍａｒｔＰｈｏｎｅ)、マルチメディア機器などのように携帯可能な機器であり、またはＰＣ、車両搭載装置のように携帯不可能な機器である。

用語の定義

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

ＵＭＴＳ：ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＳｙｓｔｅｍの略字であって、３世代移動通信ネットワークを意味する。

ＵＥ/ＭＳ：ＵｓｅｒＥｑｕｉｐｍｅｎｔ/ＭｏｂｉｌｅＳｔａｔｉｏｎ、端末装置を意味する。

ＥＰＳ：ＥｖｏｌｖｅｄＰａｃｋｅｔＳｙｓｔｅｍの略字であって、ＬＴＥ(ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ)ネットワークをサポートするコアネットワークを意味する。ＵＭＴＳが進化した形態のネットワーク。

ＰＤＮ(ＰｕｂｌｉｃＤａｔａＮｅｔｗｏｒｋ)：サービスを提供するサーバが位置した独立的なネットワーク。

ＰＤＮｃｏｎｎｅｃｔｉｏｎ：端末からＰＤＮへの接続、即ち、ｉｐアドレスで表現される端末とＡＰＮで表現されるＰＤＮとの連関(接続)。

ＰＤＮ−ＧＷ(ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋＧａｔｅｗａｙ)：ＵＥＩＰａｄｄｒｅｓｓａｌｌｏｃａｔｉｏｎ、Ｐａｃｋｅｔｓｃｒｅｅｎｉｎｇ＆ｆｉｌｔｅｒｉｎｇ、Ｃｈａｒｇｉｎｇｄａｔａｃｏｌｌｅｃｔｉｏｎ機能を遂行するＥＰＳネットワークのネットワークノード。

ＳｅｒｖｉｎｇＧＷ(ＳｅｒｖｉｎｇＧａｔｅｗａｙ)：移動性担当(Ｍｏｂｉｌｉｔｙａｎｃｈｏｒ)、パケットルーティング(Ｐａｃｋｅｔｒｏｕｔｉｎｇ)、アイドルモードパケットバッファリング(Ｉｄｌｅｍｏｄｅｐａｃｋｅｔｂｕｆｆｅｒｉｎｇ)、ＴｒｉｇｇｅｒｉｎｇＭＭＥｔｏｐａｇｅＵＥ機能を遂行するＥＰＳネットワークのネットワークノード。

ＰＣＲＦ(ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＲｕｌｅＦｕｎｃｔｉｏｎ)：サービス流れ(ｆｌｏｗ)別に差別化されたＱｏＳ及び課金政策を動的(ｄｙｎａｍｉｃ)に適用するための政策決定(Ｐｏｌｉｃｙｄｅｃｉｓｉｏｎ)を実行するＥＰＳネットワークのノード。

ＡＰＮ(ＡｃｃｅｓｓＰｏｉｎｔＮａｍｅ)：ネットワークで管理する接続ポイントの名称であって、ＵＥに提供される。即ち、ＰＤＮを指称したり区分したりする文字列。要求したサービスやネットワーク(ＰＤＮ)に接続するためには該当Ｐ−ＧＷを経由するようになり、このＰ−ＧＷをさがすことができるようにネットワーク内で予め定義した名称(文字列)。例えば、ｉｎｔｅｒｎｅｔ.ｍｎｃ０１２.ｍｃｃ３４５.ｇｐｒｓ

ＴＥＩＤ(ＴｕｎｎｅｌＥｎｄｐｏｉｎｔＩｄｅｎｔｉｆｉｅｒ)：ネットワーク内のノード間に設定されたトンネルのＥｎｄｐｏｉｎｔＩＤ、各ＵＥのｂｅａｒｅｒ単位に区間別に設定される。

ＮｏｄｅＢ：ＵＭＴＳネットワークの基地局であって、屋外に設置され、セルカバレッジ規模はマクロセルに該当する。

ｅＮｏｄｅＢ：ＥＰＳ(ＥｖｏｌｖｅｄＰａｃｋｅｔＳｙｓｔｅｍ)の基地局であって、屋外に設置され、セルカバレッジ規模はマクロセルに該当する。

(ｅ)ＮｏｄｅＢ：ＮｏｄｅＢとｅＮｏｄｅＢを指称する用語である。

ＭＭＥ：ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙの略字であって、ＵＥに対するセッションと移動性を提供するためにＥＰＳ内で各エンティティを制御する役割をする。

セッション(Ｓｅｓｓｉｏｎ)：セッションは、データ送信のための通路であって、その単位は、ＰＤＮ、Ｂｅａｒｅｒ、ＩＰｆｌｏｗ単位などになる。各単位は、３ＧＰＰで定義したように、ターゲットネットワーク全体単位(ＡＰＮまたはＰＤＮ単位)、その内でＱｏＳに区分する単位(Ｂｅａｒｅｒ単位)、宛先ＩＰアドレス単位に区分することができる。

ＰＤＮ接続(ｃｏｎｎｅｃｔｉｏｎ)：端末からＰＤＮへの接続、即ち、ｉｐアドレスで表現される端末とＡＰＮで表現されるＰＤＮとの連関(接続)を示す。これはセッションが形成されることができるようにコアネットワーク内のエンティティ間接続(端末−ＰＤＮＧＷ)を意味する。

ＵＥＣｏｎｔｅｘｔ：ネックワークでＵＥを管理するために使われるＵＥの状況情報、即ち、ＵＥｉｄ、移動性(現在位置等)、セッションの属性(ＱｏＳ、優先順位等)で構成された状況情報。

ＯＭＡＤＭ(ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅＤｅｖｉｃｅＭａｎａｇｅｍｅｎｔ)：携帯電話、ＰＤＡ、携帯用コンピュータなどのようなモバイルデバイス管理のためにデザインされたプロトコルであって、デバイス設定(ｃｏｎｆｉｇｕｒａｔｉｏｎ)、ファームウェアアップグレード(ｆｉｒｍｗａｒｅｕｐｇｒａｄｅ)、エラー報告(ＥｒｒｏｒＲｅｐｏｒｔ)等の機能を遂行する。

ＯＡＭ(ＯｐｅｒａｔｉｏｎＡｄｍｉｎｉｓｔｒａｔｉｏｎａｎｄＭａｉｎｔｅｎａｎｃｅ)：ＯＡＭとは、ネットワーク欠陥表示、機能情報、そしてデータと診断機能を提供するネットワーク管理機能群をいう。

ＮＡＳｃｏｎｆｉｇｕｒａｔｉｏｎＭＯ(ＭａｎａｇｅｍｅｎｔＯｂｊｅｃｔ)：ＮＡＳ機能(Ｆｕｎｃｔｉｏｎａｌｉｔｙ)と関連したパラメータ(ｐａｒａｍｅｔｅｒｓ)をＵＥに設定(ｃｏｎｆｉｇｕｒａｔｉｏｎ)する時に使用するＭＯ(Ｍａｎａｇｅｍｅｎｔｏｂｊｅｃｔ)を意味する。

ＮＡＳ(Ｎｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ)：ＵＥとＭＭＥとの間の制御平面(ｃｏｎｔｒｏｌｐｌａｎｅ)の上位ｓｔｒａｔｕｍ。ＵＥとネットワークとの間の移動性管理(Ｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔ)とセッション管理(Ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔ)、ＩＰアドレス管理(ＩＰａｄｄｒｅｓｓｍａｉｎｔｅｎａｎｃｅ)などをサポート。

ＭＭ(ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ)動作/手順：ＵＥの移動性(ｍｏｂｉｌｉｔｙ)制御/管理/ｃｏｎｔｒｏｌのための動作または手順。ＭＭ動作/手順は、ＣＳネットワークでのＭＭ動作/手順、ＧＰＲＳネットワークでのＧＭＭ動作/手順、ＥＰＳネットワークでのＥＭＭ動作/手順のうち一つ以上を含むと解釈されることができる。ＵＥとネットワークノード(ＭＭＥ、ＳＧＳＮ、ＭＳＣ)は、ＭＭ動作/手順を実行するためにＭＭメッセージを交わす。

ＳＭ(ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔ)動作/手順：ＵＥのｕｓｅｒｐｌａｎｅ及び/またはｂｅａｒｅｒｃｏｎｔｅｘｔ/ＰＤＰｃｏｎｔｅｘｔを制御/管理/処理/ｈａｎｄｌｉｎｇするための動作または手順。ＳＭ動作/手順は、ＧＰＲＳネットワークでのＳＭ動作/手順、ＥＰＳネットワークでのＥＳＭ動作/手順のうち一つ以上を含むと解釈されることができる。ＵＥとネットワークノード(ＭＭＥ、ＳＧＳＮ)は、ＳＭ動作/手順を実行するためにＳＭメッセージを交わす。

低順位(Ｌｏｗｐｒｉｏｒｉｔｙ)端末：ＮＡＳ信号低順位に設定された端末。詳細な事項は、標準文書３ＧＰＰＴＳ２４.３０１及びＴＳ２４.００８を参考にすることができる。

正常順位(Ｎｏｒｍａｌｐｒｉｏｒｉｔｙ)端末：低順位(Ｌｏｗｐｒｉｏｒｉｔｙ)に設定されない一般的な端末。

二重順位(Ｄｕａｌｐｒｉｏｒｉｔｙ)端末：二重順位(Ｄｕａｌｐｒｉｏｒｉｔｙ)に設定された端末、これはＮＡＳ信号低順位に設定されると同時に前記設定されたＮＡＳ信号低順位を無視(ｏｖｅｒｒｉｄｅ)することができるように設定された端末(即ち、ＵＥｗｈｉｃｈｐｒｏｖｉｄｅｓｄｕａｌｐｒｉｏｒｉｔｙｓｕｐｐｏｒｔｉｓｃｏｎｆｉｇｕｒｅｄｆｏｒＮＡＳｓｉｇｎａｌｌｉｎｇｌｏｗｐｒｉｏｒｉｔｙａｎｄａｌｓｏｃｏｎｆｉｇｕｒｅｄｔｏｏｖｅｒｒｉｄｅｔｈｅＮＡＳｓｉｇｎａｌｌｉｎｇｌｏｗｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｏｒ)。詳細な事項は、標準文書３ＧＰＰＴＳ２４.３０１及びＴＳ２４.００８を参考にすることができる。

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

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

図６に示すように、ｅＮｏｄｅＢ２００のカバレッジには数多いＵＥ１００ａ、１００ｂ、１００ｃ、１００ｄが存在し、データ送受信を試みる。それによって、前記ｅＮｏｄｅＢ２００と前記Ｓ−ＧＷ５２０との間のインターフェースにトラフィックが過負荷(ｏｖｅｒｌｏａｄ)または混雑(ｃｏｎｇｅｓｔｉｏｎ)するようになった場合、前記ＵＥ１００へのダウンリンクデータまたは前記ＵＥ１００からのアップリンクデータは、正確に送信されずに失敗するようになる。

または、前記Ｓ−ＧＷ５２０と前記ＰＤＮ−ＧＷ５３０との間のインターフェース、または前記ＰＤＮ−ＧＷ５３０と移動通信事業者のＩＰ(ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ)サービスネットワークとの間のインターフェースが過負荷(ｏｖｅｒｌｏａｄ)または混雑(ｃｏｎｇｅｓｔｉｏｎ)する場合にも、前記ＵＥ１００ａ、１００ｂ、１００ｃ、１００ｄへのダウンリンクデータまたはＵＥ１００ａ、１００ｂ、１００ｃ、１００ｄからのアップリンクデータは、正確に送信されずに失敗するようになる。

前記ｅＮｏｄｅＢ２００と前記Ｓ−ＧＷ５２０との間のインターフェースに過負荷または混雑がある場合、または前記Ｓ−ＧＷ５２０と前記ＰＤＮ−ＧＷ５３０との間のインターフェースに過負荷または混雑がある場合、前記核心ネットワークのノード(例えば、ＭＭＥ)は、ＮＡＳレベルでの混雑制御(ＮＡＳｌｅｖｅｌｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌ)を実行することで、信号混雑(ｓｉｇｎａｌｉｎｇｃｏｎｇｅｓｔｉｏｎ)及びＡＰＮ混雑を回避したり制御したりするようになる。

このようなＮＡＳレベルでの混雑制御は、ＡＰＮベースの混雑制御(ＡＰＮｂａｓｅｄｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌ)と一般ＮＡＳレベルで移動管理制御(ＧｅｎｅｒａｌＮＡＳｌｅｖｅｌｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔｃｏｎｔｒｏｌ)で構成される。

前記ＡＰＮベースの混雑制御は、ＵＥそして特定ＡＰＮ(混雑状態と関連したＡＰＮ)と関連したＥＭＭ、ＧＭＭと(Ｅ)ＳＭ信号混雑制御を意味し、ＡＰＮベースのセッション管理混雑制御(ＡＰＮｂａｓｅｄＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌ)とＡＰＮベースの移動管理混雑制御(ＡＰＮｂａｓｅｄＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌ)とを含む。

それに対し、前記一般ＮＡＳレベルの移動管理制御は、一般的なネットワーク混雑(ｃｏｎｇｅｓｔｉｏｎ)や過負荷(ｏｖｅｒｌｏａｄ)状況で、ＵＥ/ＭＳが要求する移動管理信号(ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔｓｉｇｎａｌｉｎｇ)要求を核心ネットワーク内のノード(ＭＭＥ、ＳＧＳＮ)が拒絶することで混雑及び過負荷を回避することを意味する。

一般的に、核心ネットワークがＮＡＳレベルの混雑制御を実行する場合、アイドルモード(ｉｄｌｅモード)または接続モード(ｃｏｎｎｅｃｔｅｄｍｏｄｅ)のＵＥに遅延時間タイマ(バックオフタイマ)(ｂａｃｋ−ｏｆｆｔｉｍｅｒ)値をＮＡＳ拒絶メッセージ(ｒｅｊｅｃｔｍｅｓｓａｇｅ)に載せて送信するようになり、ＵＥは、遅延時間タイマ(バックオフタイマ)(ｂａｃｋ−ｏｆｆｔｉｍｅｒ)が満了(ｅｘｐｉｒｅ)される前までネットワークにＥＭＭ/ＧＭＭ/(Ｅ)ＳＭ信号を要求しなくなる。前記ＮＡＳ拒絶メッセージは、アタッチ拒絶(ＡＴＴＡＣＨＲＥＪＥＣＴ)、ＴＡＵ(ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｉｎｇ)拒絶、ＲＡＵ(ＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｉｎｇ)拒絶、サービス拒絶、拡張サービス(ＥＸＴＥＮＤＥＤＳＥＲＶＩＣＥ)拒絶、ＰＤＮ接続(ｃｏｎｎｅｃｔｉｖｉｔｙ)拒絶、ベアラリソース割当(ｂｅａｒｅｒｒｅｓｏｕｒｃｅａｌｌｏｃａｔｉｏｎ)拒絶、ベアラリソース修正(ｂｅａｒｅｒｒｅｓｏｕｒｃｅｍｏｄｉｆｉｃａｔｉｏｎ)拒絶、ＥＰＳベアラコンテキスト非活性化要求(ｄｅａｃｔｉｖａｔｅＥＰＳｂｅａｒｅｒｃｏｎｔｅｘｔｒｅｑｕｅｓｔ)に対する拒絶のメッセージのうち一つに該当する。

このような遅延時間タイマ(ｂａｃｋ−ｏｆｆｔｉｍｅｒ)は、移動管理(ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ：ＭＭ)遅延時間(ｂａｃｋ−ｏｆｆ)タイマとセッション管理(ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔ：ＳＭ)遅延時間(ｂａｃｋ−ｏｆｆ)タイマとに分けられる。

前記ＭＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマはＵＥ毎に、そしてＳＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマはＡＰＮ毎にそしてＵＥ毎に、各々、独立的に動作する。

簡略には、前記ＭＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマは、ＥＭＭ/ＧＭＭ信号(例えば、Ａｔｔａｃｈ、ＴＡＵ/ＲＡＵ要求等)制御のためのものである。前記ＳＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマは、(Ｅ)ＳＭ信号(例えば、ＰＤＮｃｏｎｎｅｃｔｉｖｉｔｙ、ＢｅａｒｅｒＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎ、ＢｅａｒｅｒＭｏｄｉｆｉｃａｔｉｏｎ、ＰＤＰＣｏｎｔｅｘｔＡｃｔｉｖａｔｉｏｎ、ＰＤＰＣｏｎｔｅｘｔＭｏｄｉｆｉｃａｔｉｏｎ要求等)制御のためのものである。

具体的には、ＭＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマは、ネットワークに混雑(ｃｏｎｇｅｓｔｉｏｎ)が発生した場合、それを制御するために使用する移動性関連遅延時間(ｂａｃｋ−ｏｆｆ)タイマであって、タイマが動作している間、ＵＥは、アタッチ(ａｔｔａｃｈ)、位置情報更新(ＴＡＵ、ＲＡＵ)、サービス要求手順(サービス要求手順)をすることができないようにするタイマである。ただ、緊急ベアラサービス(ｅｍｅｒｇｅｎｃｙｂｅａｒｅｒｓｅｒｖｉｃｅ)、ＭＰＳ(ＭｕｌｔｉｍｅｄｉａＰｒｉｏｒｉｔｙＳｅｒｖｉｃｅ)の場合は例外であって、タイマが動作しているとしてもＵＥが要求可能である。

前述したように、ＵＥがＭＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマ値を核心ネットワークノード(例えば、ＭＭＥ、ＳＧＳＮ等)から提供を受けたり、下位階層(ｌｏｗｅｒ階層；ＡｃｃｅｓｓＳｔｒａｔｕｍ)から伝達を受けたりすることができる。また、ＵＥにより１５分から３０分までの範囲内でランダムに設定されることもできる。

前記ＳＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマは、ネットワークに混雑(ｃｏｎｇｅｓｔｉｏｎ)が発生した場合、それを制御するために使用するセッション管理(ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔ)関連遅延時間(ｂａｃｋ−ｏｆｆ)タイマであって、タイマが動作している間、ＵＥは、関連した(ａｓｓｏｃｉａｔｅｄ)ＡＰＮベースのセッションを設定または変更することができないようにするタイマである。ただ、同様に、緊急ベアラサービス、ＭＰＳ(ＭｕｌｔｉｍｅｄｉａＰｒｉｏｒｉｔｙＳｅｒｖｉｃｅ)の場合は例外であって、タイマが動作しているとしてもＵＥ１００が要求可能である。

ＵＥは、このようなＳＭ遅延時間(ｂａｃｋ−ｏｆｆ)タイマ値を核心ネットワークノード(例えば、ＭＭＥ、ＳＧＳＮ等)から提供を受け、最大７２時間以内でランダムに設定される。また、ＵＥ１００により１５分から３０分までの範囲内でランダムに設定されることもできる。

他方、前記ｅＮｏｄｅＢ２００で混雑が発生した場合、前記ｅＮｏｄｅＢ２００も混雑制御を実行することができる。即ち、ＵＥがユーザ平面のデータ送信を目的としてＲＲＣ接続確立(ｃｏｎｎｅｃｔｉｏｎｅｓｔａｂｌｉｓｈｍｅｎｔ)を要求する時、ｅＮｏｄｅＢ２００が混雑状態の場合、延長待機タイマ(ｅｘｔｅｎｄｅｄｗａｉｔｔｉｍｅｒ)と共に拒絶応答をＵＥに送信することができる。このような場合、ＲＲＣ接続確立要求を前記延長待機タイマ(ｅｘｔｅｎｄｅｄｗａｉｔｔｉｍｅｒ)が満了する前まで再試図することができない。それに対し、ＵＥがＣＳ(ｃｉｒｃｕｉｔｓｗｉｔｃｈ)ベースの呼び(ｃａｌｌ)受信のための制御平面の信号を送信する目的としてＲＲＣ接続要求をする時、前記ｅＮｏｄｅＢ２００が混雑状態であるとしても、これを拒絶することができない。

図７は、ネットワーク混雑状態でアクセスクラスによる禁止(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)による動作を示す例示的な流れ図である。

図７に示すように、ネットワークまたはｅＮｏｄｅＢ２００の過負荷または混雑状態で、ｅＮｏｄｅＢ２００は、システム情報を介してＡＣＢ(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)関連情報をブロードキャスティングすることができる。前記システム情報は、ＳＩＢ(ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ)タイプ２である。

前記ＳＩＢ(ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ)タイプ２は、以下の表のようなＡＣＢ関連情報を含むことができる。

一方、前記ＵＥ１１００ａは、ＩＭＳサービス、例えば、ＶｏＬＴＥによる呼び(ｃａｌｌ)の発信を決定し、前記ＡＣＢの適用対象になるかどうかを決定する。同様に、ＵＥ２１００ｂは、一般データの発信を決定し、前記ＡＣＢの適用対象になるかどうかを決定する。

一般的に、ＵＥは、１０個のアクセスクラス(例えば、ＡＣ０、ＡＣ１、…、ＡＣ９)のうち少なくとも一つがランダムに割り当てられている。例外的に、緊急非常アクセスのためにはＡＣ１０が割り当てられる。このように、ランダムに割り当てられたアクセスクラスの値は、前記ＵＥ１１００a及びＵＥ２１００ｂの各ＵＳＩＭには格納されることができる。

そのとき、前記ＵＥ１１００ａと前記ＵＥ２１００ｂは、前記格納されたアクセスクラスに基づいて、前記受信したＡＣＢ関連情報に含まれているｂａｒｒｉｎｇｆａｃｔｏｒフィールドを利用することで、アクセス禁止が適用されるかどうかを確認する。このようなＡｃｃｅｓｓＢａｒｒｉｎｇチェックは、前記ＵＥ１１００ａと前記ＵＥ２１００ｂの各ＡＳ(ＡｃｃｅｓｓＳｔｒａｔｕｍ)階層、即ち、ＲＲＣ階層で実行される。

もし、前記ＡＣＢの適用対象でない場合、前記ＵＥ１１００ａと前記ＵＥ２１００ｂは、各々、サービス要求(または、拡張サービス要求)メッセージとＲＲＣ接続要求メッセージを送信することができる。

しかし、前記ＡＣＢの適用対象の場合、前記ＵＥ１１００ａと前記ＵＥ２１００ｂは、両方ともＲＲＣ接続要求メッセージを送信することができない。

<マルチメディアテレフォニ(ＭｕｌｔｉＭｅｄｉａＴｅｌｅｐｈｏｎｙ：ＭＭｔｅｌ)>

最近、ＭＭＴｅｌが多く研究された。前記ＭＭＴｅｌは、ＩＭＳ(ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ)に基づくグローバル標準であって、集中的(ｃｏｎｖｅｒｇｅｄ)、固定的(ｆｉｘｅｄ)モバイルリアルタイムマルチメディア通信を提供し、これを介して音声、リアルタイムビデオ、テキスト、ファイル送信などのようなメディア能力(ｍｅｄｉａｃａｐａｂｉｌｉｔｉｅｓ)を使用し、及び写真、オーディオ、ビデオクリップなどを共有することができる。ＭＭＴｅｌにおいて、ユーザは、セッション中にメディアを追加したり、または除外したりすることができる。即ち、セッション中にチャット、音声追加、他の発信者追加、ビデオ追加、メディア共有及びファイル送信、並びにこれらのうち特定能力に対する除去が可能である。

現在、３ＧＰＰ標準ＭＭＴＥＬ(ＭｕｌｔｉＭｅｄｉａＴｅｌｅｐｈｏｎｙ)ベース(即ち、ＩＭＳベース)のサービスをサポートするシステム環境ではＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳｏｖｅｒＩＰサービスを開始するために、ＵＥのＮＡＳ(Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ)階層ではサービス要求(ＳｅｒｖｉｃｅＲｅｑｕｅｓｔ)手順の開始時、呼びタイプ(ｃａｌｌｔｙｐｅ)を発信呼び(ｏｒｉｇｉｎａｔｉｎｇｃａｌｌｓ)に設定し、ＲＲＣ確立原因(ｅｓｔａｂｌｉｓｈｍｅｎｔｃａｕｓｅ)を発信データ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄｄａｔａ)に設定することで、ＲＲＣ接続要求(ＲＲＣｃｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ)メッセージを送信する。

一般的に、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳｏｖｅｒＩＰｓｉｇｎａｌｉｎｇは、ユーザ平面(Ｕｓｅｒｐｌａｎｅ)に送信されるため、一般的なデータサービス(即ち、呼びタイプ(ｃａｌｌｔｙｐｅ)＝発信呼び(ｏｒｉｇｉｎａｔｉｎｇｃａｌｌｓ))と区分されずに提供される。

したがって、ＵＥがＭＭＴＥＬベース(即ち、ＩＭＳベース)のサービス、例えば、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳｏｖｅｒＩＰベースのサービスの提供を受けることを希望し、ＵＥがサービス要求手順を開始する前にアクセス禁止可否をチェックしようとすると、ｖｏｉｃｅｃａｌｌ、ｖｉｄｅｏｃａｌｌまたはＳＭＳｏｖｅｒＩＰを連結するためのＭＭＴＥＬ(即ち、ＩＭＳ)シグナリングが既存の一般データシグナリング(即ち、呼びタイプ(ｃａｌｌｔｙｐｅ)＝発信呼び(ｏｒｉｇｉｎａｔｉｎｇｃａｌｌｓ))と差等化できないため、ＡＣＢが適用されて禁止されることができる。したがって、ＭＭＴＥＬベース(ＩＭＳベース)のＭＯサービス(特に、ＭＭＴＥＬ音声ｃａｌｌ、ＭＭＴＥＬ映像ｃａｌｌｏｒＳＭＳｏｖｅｒＩＰ)を実行することができない。

また、ＵＥがＭＯＳＭＳ(ＳｈｏｒｔＭｅｓｓａｇｅＳｅｒｖｉｃｅ)サービスを実行しようとする場合にも、既存の一般シグナリング(即ち、呼び(ｃａｌｌ)タイプ＝発信呼び(ｏｒｉｇｉｎａｔｉｎｇｃａｌｌｓ))と差等化できないため、同様に、ＡＣＢが適用されて禁止されることができる。したがって、ＭＯＳＭＳサービスを実行することができない。

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

図８を参照すると、一般的なデータとＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰ、ＳＭＳシグナリングを区別(差等化/差別化)することができないため、ＡＣＢによるＭＯＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰ、ＭＯＳＭＳサービス連結要求が結局失敗される状況が示されている。

一方、ＲＲＣ確立原因(ｅｓｔａｂｌｉｓｈｍｅｎｔｃａｕｓｅ)をマッピングするＮＡＳ階層の手順を説明すると、下記の通りである。

ＥＭＭがＮＡＳシグナリング連結の確立を要求する場合、ＵＥにより使われるＲＲＣ確立原因は、ＮＡＳ手順によって選択される。ＥＭＭは、アクセス制御の目的として、下位階層にＲＲＣ確立原因と関連した呼びタイプ(ｃａｌｌｔｙｐｅ)を知らせなければならない。ＵＥがＥＡＢ(ＥｘｔｅｎｄｅｄＡｃｃｅｓｓＢａｒｒｉｎｇ)が設定される場合、アクセス制御の目的として、ＥＭＭは、下記のケースを除いてはＥＡＢをそのような要求に適用させる。

−選択されたＰＬＭＮでＡＣ１１からＡＣ１５のうち一つを使用するように設定されたＵＥ

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

−ＲＲＣ確立原因が応急呼び(Ｅｍｅｒｇｅｎｃｙｃａｌｌ)に設定される

−ＵＥがＥＡＢを無視(ｏｖｅｒｒｉｄｅ)するように設定された場合

−ＵＥがＥＡＢを無視するように設定され、ＥＡＢを無視したままで確立されたＰＤＮ接続を既に有している場合

結論的に、現在３ＧＰＰ標準ではＭＭＴＥＬベース(ＩＭＳベース)のＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰとＭＯＳＭＳサービスを差別化してサポートしようとする時、効率的な方案がない。このような問題は、ネットワークリソース浪費及びＵｓｅｒｅｘｐｅｒｉｅｎｃｅを悪化させる。

<本明細書の開示>

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

本発明では、ＭＭＴＥＬベース(ＩＭＳベース)のＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスの差別化のために、ＭＭＴＥＬ(ＩＭＳ)シグナリングと既存一般データシグナリングを区分してＡＣＢ(ａｃｃｅｓｓｃｌａｓｓｂａｒｒｉｎｇ)をＳｋｉｐ(通過)する方案を提案する。このようにＡＣＢｓｋｉｐをすることによって、ＭＭＴＥＬベース(ＩＭＳベース)のＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスは、常に連結を許容して他の一般ｄａｔａｓｅｒｖｉｃｅなどと差別化してサービスを提供するようになる。

そのために、ネットワーク(ｅＮＢ；基地局)は、ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢｓｋｉｐｉｎｆｏｒｍａｔｉｏｎ(例えば、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅ/ｎｏｔｓｅｔ/ｆａｌｓｅｆｏｒＭＭＴＥＬ音声及び/またはＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰ及び/またはＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ))をＳＩＢ２を介してＵＥのＡＳ階層(例えば、ＲＲＣ階層)に提供する。ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ネットワークから提供を受けたＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢｓｋｉｐｉｎｆｏｒｍａｔｉｏｎをＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層またはＮＡＳ階層に提供することもできる。

<提案１−１/１−２/１−３の概要>

まず、提案１−１は、ＮＡＳ階層とＡＳ階層(即ち、ＲＲＣ階層)の動作に関し、提案１−２は、ＭＭＴＥＬ(ＩＭＳ)動作に関し、提案１−３は、ＳＭＳ−ｏｖｅｒＩＰ動作に関する。

図９ａ及び図９ｂは、本明細書の提案１−１、１−２及び１−３を示す信号流れ図である。

図９ａ及び図９ｂを参照して分かるように、提案１−１/１−２/１−３ではＭＭＴＥＬベース(ＩＭＳベース)のＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスの差別化のために、ＭＭＴＥＬ(ＩＭＳ)シグナリングと既存一般データシグナリングを区分してＡＣＢ(ａｃｃｅｓｓｃｌａｓｓｂａｒｒｉｎｇ)を通過(ｓｋｉｐ)させる方案を提示した。このようにＡＣＢに対する検査を通過(ｓｋｉｐ)させることによって、ＭＭＴＥＬベース(ＩＭＳベース)の発信(ＭＯ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスは、常に連結を許容して他の一般データサービスと差別化してサービスを提供するようになる。

そのために、ネットワーク(例えば、基地局)は、ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰ/ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)サービスに対するＡＣＢスキップ情報(即ち、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅ/ｎｏｔｓｅｔ/ｆａｌｓｅｆｏｒＭＭＴＥＬｖｏｉｃｅ、ＭＭＴＥＬｖｉｄｅｏ、ＳＭＳｏｖｅｒＩＰａｎｄ/ｏｒＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ))をシステム情報ブロック(例えば、ＳＩＢ２)を介してＵＥのＡＳ階層(即ち、ＲＲＣ階層)に提供する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層が発信(ＭＯ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結を開始する時、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像のためのセッション/呼び(ｃａｌｌ)であることを知らせるインジケーション/情報をＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＳＭＳｏｖｅｒＩＰセッションであることを知らせるインジケーション/情報をＮＡＳ階層に提供する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)インジケーションを提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像ｏｒ/ＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、サービスタイプをｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＭＴＥＬｖｏｉｃｅ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＭＴＥＬｖｉｄｅｏ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＩＰｆｏｒＳＭＳｏｖｅｒＩＰに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定し、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｃａｌｌｓｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ/ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｃａｌｌｓｆｏｒＭＯＭＭＴＥＬｖｉｄｅｏ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳｏｖｅｒＩＰに設定する。

図１０ａ及び図１０ｂは、本明細書の提案１−１を示す信号流れ図である。

図１０ａ及び図１０ｂを参照して分かるように、提案１−１によると、ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ；ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのサービス要求手順の開始時、サービスタイプをｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＳＧｓに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定し、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)に設定する。

提案１−１/１−２/１−３によると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)インジケーションを提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｃａｌｌｓｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ/ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｃａｌｌｓｆｏｒＭＯＭＭＴＥＬｖｉｄｅｏ/ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳｏｖｅｒＩＰに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定する。

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

<提案１−１：標準改善>

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

ａ)ＡＣＢにより拒絶されたアクセスまたは下位階層から受信された延長待機タイム(Ｅｘｔｅｎｄｅｄｗａｉｔｔｉｍｅ)なしにネットワークから拒絶されたＮＡＳシグナリング連結確立

−もし、下位階層が指示したアクセスが遮断(ｂａｒｒｅｄ)されたが、サービス要求は、ＳＭＳｏｖｅｒＩＰを除外したＳＭＳのために開始された場合、サービス要求手順は開始されることができる。

もし、下位階層が指示したアクセスが遮断(ｂａｒｒｅｄ)されたが、サービス要求は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、またはＳＭＳｏｖｅｒＩＰのために開始された場合、サービス要求手順は開始されることができる。

そうでない場合、アクセスが発信呼び(ｏｒｉｇｉｎａｔｉｎｇｃａｌｌｓ)に対して遮断(ｂａｒｒｅｄ)される時、サービス要求手順は開始されない。ＵＥが現在サービングセルでとどまった状態で正常なセル再選択手順を実行する。

ｂ)下位階層失敗またはサービス要求手順が完了する以前に下位階層から受信された延長待機時間(Ｅｘｔｅｎｄｅｄｗａｉｔｔｉｍｅ)がないままでＮＡＳシグナリング連結を解除する。

<提案１−２：標準改善>

ユーザからマルチメディアテレフォニ通信セッションの確立に対する要求がある場合、ＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)をサポートするＵＥは、下記のように動作する。

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

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

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

下記の情報がＮＡＳ階層に提供される。

−ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎ

−ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎ；

−ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎ

−ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎ

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

１)もし、オーディオまたはリアルタイムテキストまたはオーディオ及びテキストの組合せがマルチメディアテレフォニ通信セッション内で提供され、他のマルチメディアテレフォニ通信セッションはない場合、ＵＥは、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

２)もし、ビデオがマルチメディアテレフォニ通信セッション内で提供され、他のマルチメディアテレフォニ通信セッションはない場合、ＵＥは、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

一方、マルチメディアテレフォニ通信セッションが終了する時、マルチメディアテレフォニ通信セッションがオーディオまたはリアルタイムテキスト、またはオーディオ及びテキストの組合せを送信するために確立されたものであり、他のセッションはない場合、ＵＥは、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供することができる。

一方、マルチメディアテレフォニ通信セッションが終了する時、マルチメディアテレフォニ通信セッションがビデオを送信するために確立されたものであり、他のセッションはない場合、ＵＥは、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供することができる。

<提案１−３：標準改善>

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

１)ＳＭＳ−ｏｖｅｒ−ＩＰがマルチメディアテレフォニ通信セッション内で提供される場合、ＵＥは、ＥＭＭ階層にＳＭＳ−ｏｖｅｒ−ＩＰを指示し、セッション確立を続ける。

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

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

−ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎ

−ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎ

ユーザからＳＭＳｏｖｅｒＩＰの送信に対する要求があり、他のＳＭＳｏｖｅｒＩＰを送信するものがない場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に指示する。

ＳＭＳｏｖｅｒＩＰの送信が完了し、他のＳＭＳｏｖｅｒＩＰは送信するものがない場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に指示する。

<提案２−１/２−２/２−３の概要>

提案２−１は、ＮＡＳ階層とＡＳ階層(例えば、ＲＲＣ階層)の動作に関し、提案２−２は、ＭＭＴＥＬのためのＩＭＳ階層とＡＳ階層(例えば、ＲＲＣ階層)の動作に関し、提案２−３は、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層とＡＳ階層(例えば、ＲＲＣ階層)の動作に関する。

提案２−１/２−２/２−３は、ＭＭＴＥＬベース(ＩＭＳベース)の発信(ＭＯ：ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスの差別化のために、ＭＭＴＥＬ(ＩＭＳ)シグナリングと既存一般データシグナリングを区分してＡＣＢに対する検査を通過(ｓｋｉｐ)させる方案を提案する。このようにＡＣＢに対する検査を通過(ｓｋｉｐ)させることによって、ＭＭＴＥＬベース(ＩＭＳベース)のＭＯＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスは、常に連結を許容して他の一般データサービスなどと差別化してサービスを提供するようになる。

図１１ａ及び図１１ｂは、本明細書の提案２−１、２−２及び２−３を示す信号流れ図である。

図１１ａ及び図１１ｂを参照して分かるように、ネットワーク(例えば、基地局)は、ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報(即ち、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅ/ｎｏｔｓｅｔ/ｆａｌｓｅｆｏｒＭＭＴＥＬｖｏｉｃｅ及び/またはＭＭＴＥＬｖｉｄｅｏ及び/またはＳＭＳｏｖｅｒＩＰ及び/またはＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ))をシステム情報ブロック(例えば、ＳＩＢ２)を介してＵＥのＡＳ階層(例えば、ＲＲＣ階層)に提供する。ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ネットワークから提供を受けたＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報をＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層に提供する。

上記提案２−１/２−２/２−３によると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢスキップインジケーション/情報を提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)をＡＳ階層(例えば、ＲＲＣ階層)に提供する。

図１２ａ及び図１２ｂは、本明細書の提案２−２を示す信号流れ図である。

図１２ａ及び図１２ｂを参照して分かるように、提案２−１によると、ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ；ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯＳＭＳ連結のためのサービス要求手順の開始時、サービスタイプをｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＳＧｓに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定し、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)に設定する。

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

<提案２−１>

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

−もし、下位階層が示すアクセスが遮断(ｂａｒｒｅｄ)されたが、サービス要求は、ＳＭＳｏｖｅｒＩＰを除外したＳＭＳのために開始された場合、サービス要求手順は開始されなければならない。

−もし、下位階層が示すアクセスが遮断されたが、サービス要求は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ｏｒＳＭＳｏｖｅｒＩＰのために開始された場合、そして、ＵＥは、上位階層からＡＣＢに対する検査の通過(ｓｋｉｐ)が指示された場合、サービス要求手順は開始されなければならない。

ＥＭＭがＮＡＳシグナリング連結の確立を要求する場合、ＵＥにより使われるＲＲＣ確立原因は、ＮＡＳ手順によって選択される。ＥＭＭは、アクセス制御の目的として、下位階層にＲＲＣ確立原因と関連した呼びタイプ(ｃａｌｌｔｙｐｅ)を知らせなければならない。さらに、ＥＭＭがＮＡＳシグナリング連結を要求する時、上位階層がＡＣＢに対する検査の通過を指示する場合、ＥＭＭは、ＡＣＢに対する検査の通過を下位階層に伝達しなければならない。ＵＥがＥＡＢ(ＥｘｔｅｎｄｅｄＡｃｃｅｓｓＢａｒｒｉｎｇ)が設定される場合、アクセス制御の目的として、ＥＭＭは、下記のケースを除いてはＥＡＢをそのような要求に適用させる。

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

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

ＡＣＢが下記の場合に適用されない。

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

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

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

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

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

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

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

ＡＣＢが下記の場合に適用されない。

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

ＥＭＭがＮＡＳシグナリング連結の確立を要求する場合、ＵＥにより使われるＲＲＣ確立原因は、ＮＡＳ手順によって選択される。ＥＭＭはアクセス制御の目的として、下位階層にＲＲＣ確立原因と関連した呼びタイプ(ｃａｌｌｔｙｐｅ)を知らせなければならない。ＵＥがＥＡＢ(ＥｘｔｅｎｄｅｄＡｃｃｅｓｓＢａｒｒｉｎｇ)が設定される場合、アクセス制御の目的として、ＥＭＭは、下記のケースを除いてはＥＡＢをそのような要求に適用させる。

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

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

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

<提案２−２>

提案２−２によるＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)に対する改善を説明すると、下記の通りである。

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

−ＡＣＢＳｋｉｐＦｏｒＭＭＴＥＬ−Ｖｏｉｃｅ：ＭＭＴＥＬ音声のためのＡＣＢｓｋｉｐｐｉｎｇｂｉｔ；

−ＡＣＢＳｋｉｐＦｏｒＭＭＴＥＬ−Ｖｉｄｅｏ：ＭＭＴＥＬ映像のためのＡＣＢｓｋｉｐｐｉｎｇｂｉｔ

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

１)下位階層から受信されるＡＣＢスキップ情報の検索

２)マルチメディアテレフォニ通信セッション内でビデオが提供され、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔがＭＭＴＥＬ映像に対して設定された場合、ＵＥは、ＥＭＭ階層にＡＣＢに対する検査の通過を指示し、セッション確立を続ける。

３)マルチメディアテレフォニ通信セッション内でオーディオが提供され、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔがＭＭＴＥＬ音声に対して設定された場合、ＵＥは、ＥＭＭ階層にＡＣＢに対する検査の通過を指示し、セッション確立を続ける。

<提案２−３>

提案２−３によるＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)に対する改善を説明すると、下記の通りである。

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

−ＡＣＢＳｋｉｐＦｏｒＳＭＳ−ｏｖｅｒ−ＩＰ：ＳＭＳ−ｏｖｅｒ−ＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ

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

１)下位階層から受信されたＡＣＢスキップ情報の検索

２)マルチメディアテレフォニ通信セッション内でＳＭＳ−ｏｖｅｒ−ＩＰが提供され、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔがＳＭＳ−ｏｖｅｒ−ＩＰに対して設定された場合、ＵＥは、ＥＭＭ階層にＡＣＢに対する検査の通過(ｓｋｉｐ)を指示し、セッション確立を続ける。

<提案３>

提案３は、ＭＭＴＥＬベース(ＩＭＳベース)のＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスの差別化のために、ＭＭＴＥＬ(ＩＭＳ)シグナリングと既存一般データシグナリングを区分してＡＣＢに対する検査を通過(ｓｋｉｐ)する方案を提案する。このようにＡＣＢに対する検査を通過(ｓｋｉｐ)させることによって、ＭＭＴＥＬベース(ＩＭＳベース)のＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスは、常に連結を許容して他の一般データサービスなどと差別化してサービスを提供するようになる。

図１３ａ及び図１３ｂは、本明細書の提案３を示す信号流れ図である。

図１３ａ及び図１３ｂを参照して分かるように、提案３によると、ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳ(具体的に、ＳＭＳｏｖｅｒＩＰ)に対して、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢスキップインジケーション/情報をＡＳ(ＲＲＣ)階層から提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)をＡＳ階層(例えば、ＲＲＣ階層)に提供する。

図１４ａ及び図１４ｂは、本明細書の提案３の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図１４ａ及び図１４ｂを参照すると、ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ；ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのサービス要求の開始時、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)に設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定する。

<提案４：標準改善>

提案４は、ＭＭＴＥＬベース(ＩＭＳベース)のＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスの差別化のために、ＭＭＴＥＬ(ＩＭＳ)シグナリングと既存一般データシグナリングを区分してＡＣＢに対する検査を通過(ｓｋｉｐ)させる方案を提案する。このようにＡＣＢに対する検査を通過(ｓｋｉｐ)させることによって、ＭＭＴＥＬベース(ＩＭＳベース)のＭＯＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスは、常に連結を許容して他の一般データサービスなどと差別化してサービスを提供するようになる。

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

図１５ａ及び図１５ｂは、本明細書の提案４を示す信号流れ図である。

図１５ａ及び図１５ｂを参照して分かるように、提案４によると、ＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳ(具体的に、ＳＭＳｏｖｅｒＩＰ)に対して、ＮＡＳ階層は、サービス要求手順を開始する時、呼びタイプ(ｃａｌｌｔｙｐｅ)をｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅ、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏまたはｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＩＰｆｏｒＭＯＳＭＳｏｖｅｒＩＰに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定する。

図１６ａ及び図１６ｂは、本明細書の提案４の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図１６ａ及び図１６ｂに示すように、提案４によると、ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ；ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのサービス要求手順の開始時、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)に設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定する。

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

ＡＣＢが下記の場合に適用されない。

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

−ＡＣＢが通過(ｓｋｉｐ)されるようにサービスインジケーション(ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、またはＳＭＳｏｖｅｒＩＰ)が上位階層から受信される場合

上記提案で、上位階層(ＭＭＴＥＬ階層)からＥＭＭ階層(ｎｏｎ−ａｃｃｅｓｓｓｔｒａｔｕｍ階層)に提供するサービスインジケーションは、ＭＭＴＥＬ音声またはＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰのためのＡＣＢｓｋｉｐｂｉｔｓｉｎｄｉｃａｔｉｏｎであり、またはＭＭＴＥＬ音声またはＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰを示すサービスインジケータ/情報である。

上記提案で、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＮＡＳを区分してサービス要求手順(即ち、サービス要求メッセージの送信)を開始する時、ＡＳ階層(即ち、ＲＲＣ階層)にＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＮＡＳを区分するための新しい呼びタイプ(ｃａｌｌｔｙｐｅ)(ｃａｌｌｔｙｐｅｓ)として、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＭＴＥＬｖｏｉｃｅ、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＭＴＥＬｖｉｄｅｏ、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＩＰｆｏｒＳＭＳｏｖｅｒＩＰ、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＳＭＳｏｖｅｒＮＡＳを定義して送る。ＡＳ階層(即ち、ＲＲＣ階層)は、ＮＡＳが要求したサービス要求手順(即ち、サービス要求メッセージの送信)を実行するためにＲＲＣ接続を確立(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するようになり、前記ＩＭＳサービスとＳＭＳサービスを新しい呼びタイプ(ｃａｌｌｔｙｐｅ)(ｃａｌｌｔｙｐｅｓ)を使用して区分し、各々に対して基地局から受信されたシステム情報ブロック(ＳＩＢ)内に含まれているＡＣＢスキップ情報によって最終ＡＣＢに対する検査を通過(ｓｋｉｐ)させるかどうかを決定するようになる。即ち、ＡＳ階層(即ち、ＲＲＣ階層)は、ＮＡＳ階層のサービス要求メッセージの新しい呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、ＩＭＳサービスとＳＭＳサービスを認知した後、ネットワークから受信したＡＣＢスキップ情報内に該当サービスが設定(例えば、ＡＣＢｓｋｉｐｐｉｎｇＯＮ)されている場合、該当ＲＲＣ接続確立を実行し、そうでない場合、該当ＲＲＣ接続確立を実行せずにアクセスを遮断(ｂａｒｒｉｎｇ)する。

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

上記提案で、上位階層(例えば、ＭＭＴＥＬ階層)からＥＭＭ階層(例えば、ＮＡＳ階層)に提供するサービスインジケーションは、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、またはＳＭＳｏｖｅｒＩＰのためのＡＣＢｓｋｉｐｂｉｔｓｉｎｄｉｃａｔｉｏｎであり、またはＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰを示すサービスインジケータ/情報である。

上記提案で、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＮＡＳを区分してサービス要求手順(即ち、拡張サービス要求メッセージの送信)を開始する時、ＡＳ階層(即ち、ＲＲＣ階層)にＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＮＡＳを区分するための新しいサービスタイプとしてｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅ、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏ、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＩＰ、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳを定義して送る。このとき、新しく定義されたサービスタイプと共に新しい呼びタイプ(ｃａｌｌｔｙｐｅ)が定義されて使われることもできる。ＡＳ階層(即ち、ＲＲＣ階層)は、ＮＡＳが要求したサービス要求手順(即ち、拡張サービス要求メッセージの送信)を実行するためにＲＲＣ接続を確立(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するようになり、前記ＩＭＳサービスとＳＭＳサービスをサービスタイプ及び/または新しい呼びタイプ(ｃａｌｌｔｙｐｅ)を介して区分し、各々に対してネットワークから受信したシステム情報(例えば、ＳＩＢ)内に含まれているＡＣＢスキップ情報によって最終的にＡＣＢに対する検査を通過(ｓｋｉｐ)させるかどうかを決定するようになる。即ち、ＡＳ階層(即ち、ＲＲＣ階層)は、ＮＡＳ階層の拡張サービス要求メッセージの新しいサービスタイプ及び/または呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、ＩＭＳサービスとＳＭＳサービスを認知した後、ネットワークから受信したＡＣＢスキップ情報が該当サービスに対してセッティング(ＡＣＢｓｋｉｐｐｉｎｇＯＮ)されている場合、該当ＲＲＣ接続を確立し、そうでない場合、該当ＲＲＣ接続を確立しない。

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

−ＣＳフォールバックを開始するために、またはＣＳフォールバックの着信(Ｍｏｂｉｌｅｔｅｒｍｉｎａｔｉｎｇ)に応答するために

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

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

または、上位階層は、ＭＭＴＥＬ音声のためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示する：ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信され、そしてＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信された以後、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎが受信されない。

上位階層は、ＭＭＴＥＬ映像に対してＡＣＢに対する検査の通過(ｓｋｉｐ)を指示する：ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信され、そしてＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信された以後、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎが受信されない。

上位階層は、ＭＭＴＥＬＳＭＳ−ｏｖｅｒ−ＩＰに対してＡＣＢに対する検査の通過を指示する：ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信され、そしてＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信された以後、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎが受信されない。

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

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

ＡＣＢが下記の場合に適用されない。

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

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

−サービス要求手順がユーザ平面の無線リソースに対する上位階層の要求により開始される時、上位階層がＭＭＴＥＬ音声のためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示する場合

−サービス要求手順がユーザ平面の無線リソースに対する上位階層の要求により開始される時、上位階層がＭＭＴＥＬ映像のためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示する場合

−サービス要求手順がユーザ平面の無線リソースに対する上位階層の要求により開始される時、上位階層がＳＭＳ−ｏｖｅｒ−ＩＰのためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示する場合

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

上記提案で、ＮＡＳ階層は、発信(ＭＯ：ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇ)ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳ(具体的に、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｉｎＭＭＥ、またはＳＭＳｏｖｅｒＳ１０２)を区分してサービス要求手順(サービス要求メッセージの送信)を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)にＭＯＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳ(具体的に、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｉｎＭＭＥ、ｏｒＳＭＳｏｖｅｒＳ１０２)を区分し、各々新しい呼びタイプ(ｃａｌｌｔｙｐｅ)として、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅ、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏ、ｏｒｉｇｉｎａｔｉｎｇＳＭＳを定義して送る。ＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳが要求したサービス要求手順を実行するためにＲＲＣ接続を確立(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するようになり、前記ＩＭＳサービスとＳＭＳサービスを新しい呼びタイプ(ｃａｌｌｔｙｐｅ)(ｃａｌｌｔｙｐｅｓ)を介して区分し、各々に対してネットワークから受信したシステム情報(例えば、ＳＩＢ)内に含まれているＡＣＢスキップ情報によって最終ＡＣＢに対する検査を通過(ｓｋｉｐ)させるかどうかを決定するようになる。即ち、ＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳ階層のサービス要求メッセージの新しい呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、ＩＭＳサービスとＳＭＳサービスを認知した後、ネットワークから受信したＡＣＢスキップ情報が該当サービスに対してセッティング(ＡＣＢｓｋｉｐｐｉｎｇＯＮ)されている場合、該当ＲＲＣ接続確立を実行し、そうでない場合、該当ＲＲＣ接続確立を実行しない。

また、上記提案で、ＮＡＳ復旧のためのＴＡＵ(ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅ)要求手順が開始(実行)される場合、ＮＡＳ階層は、ＭＯＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳ(具体的に、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｉｎＭＭＥ、ｏｒＳＭＳｏｖｅｒＳ１０２)を区分してＴＡＵ手順(即ち、ＴＡＵ要求メッセージの送信)を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)にＭＯＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳ(ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｉｎＭＭＥ、ｏｒＳＭＳｏｖｅｒＳ１０２)を区分するための新しい呼びタイプ(ｃａｌｌｔｙｐｅ)として、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅ、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏ、ｏｒｉｇｉｎａｔｉｎｇＳＭＳを定義して送る。ＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳが要求したＴＡＵ手順を実行するためにＲＲＣ接続を確立(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するようになり、このとき、前記ＩＭＳサービスとＳＭＳサービスを呼びタイプ(ｃａｌｌｔｙｐｅ)を介して区分し、各々に対してネットワークから提供されたＳＩＢ情報内に含まれているＡＣＢスキップ情報によって最終ＡＣＢに対する検査を通過(ｓｋｉｐ)させるかどうかを決定するようになる。即ち、ＡＳ階層(例えば、ＲＲＣ階層)でＮＡＳ階層のＴＡＵ要求メッセージの呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、ＩＭＳサービスとＳＭＳサービスを認知した後、ネットワークから受信したＡＣＢスキップ情報が該当サービスに対してセッティング(ＡＣＢｓｋｉｐｐｉｎｇＯＮ)されている場合、該当ＲＲＣ接続の確立(このとき、ＲＲＣ確立原因は、ＭＯｓｉｇｎａｌｌｉｎｇに設定される)を実行し、そうでない場合、該当ＲＲＣ接続を確立しない。

他の一方、上位階層は、ＭＭＴＥＬ音声のためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示することができる：例えば、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信され、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信された以後、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信されない場合である。

上位階層は、ＭＭＴＥＬ映像のためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示することができる。例えば、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信され、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信された以後、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信されない場合である。

上位階層は、ＭＭＴＥＬＳＭＳ−ｏｖｅｒ−ＩＰのためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示することができる。例えば、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信され、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信された以後、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎが上位階層から受信されない場合である。

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

ＡＣＢが下記の場合に適用されない。

−サービス要求手順が発信(ＭＯ)ＳＭＳ(例えば、ＳＭＳｉｎＭＭＥ、ＳＭＳｏｖｅｒＳＧｓｏｒＳＭＳｏｖｅｒＳ１０２)により開始された場合

−サービス要求手順がユーザ平面の無線リソースのための上位階層の要求により開始された時、上位階層は、ＭＭＴＥＬ音声のためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示した場合、

−サービス要求手順がユーザ平面の無線リソースのための上位階層の要求により開始された時、上位階層は、ＭＭＴＥＬ映像のためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示した場合、

−サービス要求手順がユーザ平面の無線リソースのための上位階層の要求により開始された時、上位階層は、ＳＭＳ−ｏｖｅｒ−ＩＰのためにＡＣＢに対する検査の通過(ｓｋｉｐ)を指示した場合、

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

上記提案で、ＮＡＳ階層は、発信(ＭＯ)ＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳ(具体的に、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｉｎＭＭＥ、ｏｒＳＭＳｏｖｅｒＳ１０２)を区分してサービス要求手順(拡張サービス要求メッセージの送信)を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)にＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳ(具体的に、ＳＭＳｏｖｅｒＩＰ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｉｎＭＭＥ、ｏｒＳＭＳｏｖｅｒＳ１０２)を区分するための新しいサービスタイプ、例えば、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＭＴＥＬｖｏｉｃｅ、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＭＴＥＬｖｉｄｅｏ、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳを定義して送る。このとき、新しく定義されたサービスタイプと共に新しい呼びタイプ(ｃａｌｌｔｙｐｅ)が定義されて使われることもできる。ＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳが要求したサービス要求手順(例えば、拡張サービス要求メッセージの送信)を実行するためにＲＲＣ接続を確立(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するようになり、前記ＩＭＳサービスとＳＭＳサービスをサービスタイプ及び/または呼びタイプ(ｃａｌｌｔｙｐｅ)を介して区分し、各々に対してネットワークから提供されたＳＩＢ内に含まれているＡＣＢスキップ情報によって最終ＡＣＢに対する検査を通過(ｓｋｉｐ)させるかどうかを決定するようになる。即ち、ＡＳ階層(例えば、ＲＲＣ階層)でＮＡＳ階層の拡張サービス要求メッセージ内のサービスタイプ及び/または呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、ＩＭＳサービスとＳＭＳサービスを認知した後、ネットワークから受信したＡＣＢスキップ情報内に該当サービスがセッティング(即ち、ＡＣＢｓｋｉｐｐｉｎｇＯＮ)されている場合、該当ＲＲＣ接続確立を実行し、そうでない場合、該当ＲＲＣ接続確立を実行しない。

<提案５−１：標準改善>

図１７ａ及び図１７ｂは、本明細書の提案５−１を示す信号流れ図である。

図１７ａ及び図１７ｂを参照して分かるように、提案５−１によると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢスキップインジケーションを提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像ｏｒ/ＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像ｏｒＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。このとき、拡張サービス要求(ＥＸＴＥＮＤＥＤＳＥＲＶＩＣＥＲＥＱＵＥＳＴ)メッセージを使用する。サービス要求手順の開始時、拡張サービス要求メッセージのサービスタイプは、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＭＴＥＬｖｏｉｃｅ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＭＴＥＬｖｉｄｅｏ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＩＰｆｏｒＳＭＳｏｖｅｒＩＰに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定し、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｃａｌｌｓｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｃａｌｌｓｆｏｒＭＯＭＭＴＥＬｖｉｄｅｏ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｏｖｅｒＩＰ)に設定する。

図１８ａ及び図１８ｂは、本明細書の提案５の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図１８ａ及び図１８ｂを参照すると、ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ；ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのサービス要求手順の開始時、拡張サービス要求メッセージのサービスタイプをｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定し、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳに設定する。

<提案５−２>

図１９ａ及び図１９ｂは、本明細書の提案５−２に対する例を示す信号流れ図である。

提案５−２によると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声/ＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報を確認し、もし、ＭＭＴＥＬ音声及び/またはＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰに対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像のためのセッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢスキップ開始インジケーション/情報をＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＳＭＳｏｖｅｒＩＰのためのセッションの開始を知らせるＡＣＢスキップ開始インジケーション/情報をＮＡＳ階層に提供する。

また、提案５−２によると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層からＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像ｏｒＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢスキップ開始インジケーション/情報(即ち、ＡＣＢｓｋｉｐｂｅｇｉｎｉｎｄｉｃａｔｉｏｎ)を受信すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像及び/またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)開始であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)を共にＡＳ階層(例えば、ＲＲＣ階層)に提供する。

図２０ａ及び図２０ｂは、本明細書の提案５−２の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図２０ａ及び図２０ｂを参照すると、ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ；ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのサービス要求手順の開始時、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)に設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定する。

再び、図１９ａ及び図１９ｂを参照すると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層が発信(ＭＯ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結が終われると/終了すると、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像セッション/呼び(ｃａｌｌ)の終了を知らせるＡＣＢスキップ終了インジケーション/情報をＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＳＭＳｏｖｅｒＩＰセッションの終了を知らせるＡＣＢスキップ終了インジケーション/情報をＮＡＳ階層に提供する。

具体的に、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対する終了インジケーション/情報(即ち、ＡＣＢｓｋｉｐｅｎｄｉｎｄｉｃａｔｉｏｎ/ｉｎｆｏｒｍａｔｉｏｎ)を提供すると、ＮＡＳ階層は、ＭＯＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)が終了することを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰセッションに対してＡＣＢに対する検査を通過させない。即ち、一般的なデータ/呼び(ｃａｌｌ)のためのセッションと認知し、一般的なサービス要求手順を実行するようになり、ＡＳ階層(即ち、ＲＲＣ階層)ではＡＣＢを適用する。

提案５−２によると、ＡＣＢスキップ開始インジケーション/情報とＡＣＢスキップ終了インジケーション/情報が使われる。

そのために、下記のようにＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)内容が改善されることができる。

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

−ＡＣＢＳｋｉｐＦｏｒＭＭＴＥＬ−Ｖｏｉｃｅ：ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ

−ＡＣＢＳｋｉｐＦｏｒＭＭＴＥＬ−Ｖｉｄｅｏ：ＭＭＴＥＬ映像に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ

下記の情報がＮＡＳ階層に提供される。

−ＡＣＢ−ｓｋｉｐ−ｂｅｇｉｎ−ｉｎｄｉｃａｔｉｏｎ；

−ＡＣＢ−ｓｋｉｐ−ｅｎｄ−ｉｎｄｉｃａｔｉｏｎ。

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

１)ＡＳ階層から取得したＡＣＢスキップ情報を検索する。

２)マルチメディアテレフォニ通信セッション内にビデオが提供される時、ＭＭＴＥＬ映像に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＮＡＳ階層にＡＣＢ−ｓｋｉｐ−ｂｅｇｉｎ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

３)マルチメディアテレフォニ通信セッション内にオーディオが提供される時、ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＮＡＳ階層にＡＣＢ−ｓｋｉｐ−ｂｅｇｉｎ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

マルチメディアテレフォニ通信セッションが完了する時、ＵＥは、ＡＣＢ−ｓｋｉｐ−ｅｎｄ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

その代案として、下記のようにＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)内容が改善されることができる。

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

下記の情報がＮＡＳ階層に伝達される。

−ＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎ：ＭＭＴＥＬ音声；

−ＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎ：ＭＭＴＥＬ音声；

−ＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎ：ＭＭＴＥＬ映像；ａｎｄ

−ＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎ：ＭＭＴＥＬ映像。

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

１)ＡＳ階層から取得したＡＣＢスキップ情報を検索する。

２)マルチメディアテレフォニ通信セッション内でオーディオが提供される場合、そしてＭＭＴＥＬ音声に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

３)マルチメディアテレフォニ通信セッション内でビデオが提供される場合、そしてＭＭＴＥＬ映像に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

音声のためのマルチメディアテレフォニ通信セッションが完了する場合、ＵＥは、ＭＭＴＥＬ音声識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

同様に、ビデオのためのマルチメディアテレフォニ通信セッションが完了する場合、ＵＥは、ＭＭＴＥＬ映像識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

<提案５−３>

提案５−３によると、提案５−２と同様に、ＡＣＢスキップ開始インジケーション/情報とＡＣＢスキップ終了インジケーション/情報が使われることができる。

ただし、提案５−２と違って、提案５−３によると、下記のようにＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)内容が改善されることができる。

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

下記の情報がＮＡＳ階層に伝達される。

−ＡＣＢ−ｓｋｉｐ−ｂｅｇｉｎ−ｉｎｄｉｃａｔｉｏｎ；ａｎｄ

−ＡＣＢ−ｓｋｉｐ−ｅｎｄ−ｉｎｄｉｃａｔｉｏｎ。

ＳＭＳｏｖｅｒＩＰの送信に対する要求をユーザから受けた場合、ＵＥは、下記のように動作する。

１)ＡＳ階層から取得したＡＣＢスキップ情報の検索

２)ＳＭＳｏｖｅｒＩＰに対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔがセッティングされた場合、ＵＥは、ＡＣＢ−ｓｋｉｐ−ｂｅｇｉｎ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達し、ＳＭＳｏｖｅｒＩＰ送信手順を続ける。

ＳＭＳｏｖｅｒＩＰ送信が完了した場合、ＵＥは、ＡＣＢ−ｓｋｉｐ−ｅｎｄ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する

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

下記の情報がＮＡＳ階層に伝達されることができる

−ＡＣＢ−ｓｋｉｐ−ｓｅｔ(例えば、ｔｒｕｅ/ｓｔａｒｔ/ｂｅｇｉｎ)−ｉｎｄｉｃａｔｉｏｎ：ＳＭＳ−ｏｖｅｒ−ＩＰ；

−ＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ(例えば、ｆａｌｓｅ/ｓｔｏｐ/ｅｎｄ)−ｉｎｄｉｃａｔｉｏｎ：ＳＭＳ−ｏｖｅｒ−ＩＰ。

ユーザからＳＭＳｏｖｅｒＩＰに対する送信要求がある場合、ＵＥは、下記のように動作する。

１)ＡＳ階層から取得したＡＣＢスキップ情報を検索する。

２)ＳＭＳ−ｏｖｅｒ−ＩＰに対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されている場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達し、ＳＭＳｏｖｅｒＩＰの送信を続ける。

ＳＭＳｏｖｅｒＩＰが完了すると、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

<提案６>

図２１ａ及び図２１ｂは、本明細書の提案６を示す信号流れ図である。

図２１ａ及び図２１ｂを参照して分かるように、提案６によると、ＭＭＴＥＬのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声サービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声サービスに対するＡＣＢスキップ情報を確認した結果、もし、ＭＭＴＥＬ音声に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ音声セッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢスキップ開始インジケーション/情報をＮＡＳ階層に提供する。または、ＭＭＴＥＬのためのＩＭＳ階層がＭＯＭＭＴＥＬ映像サービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ映像サービスに対するＡＣＢスキップ情報を確認した結果、もし、ＭＭＴＥＬ映像に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ映像セッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢスキップ開始インジケーション/情報をＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳｏｖｅｒＩＰサービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報を確認した結果、もし、ＳＭＳｏｖｅｒＩＰに対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、ＳＭＳｏｖｅｒＩＰセッションの開始を知らせるＡＣＢスキップ開始インジケーション/情報をＮＡＳ階層に提供する。

ＭＭＴＥＬ及びＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰに対するセッション/呼び(ｃａｌｌ)開始インジケーション/情報(即ち、ＡＣＢｓｋｉｐｂｅｇｉｎインジケーション/情報)を提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)開始であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)を共にＡＳ階層(例えば、ＲＲＣ階層)に提供する。

図２２ａ及び図２２ｂは、本明細書の提案６−１の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図２２ａ及び図２２ｂを参照して分かるように、ＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのサービス要求手順の開始時、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)に設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定する。

一方、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳ階層からサービス要求と共に提供されるＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰに対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)を確認し、前記サービス要求に対してＡＣＢに対する検査を通過させるようになる。以後、ＲＲＣ接続要求メッセージを基地局に送信する。このとき、ＲＲＣ接続要求メッセージの確立原因は、ＭＯ−ｄａｔａに設定される。

または、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳ階層からサービス要求と共に提供されるＭＭＴＥＬ音声に対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅｆｏｒＭＭＴＥＬｖｏｉｃｅ)、ＭＭＴＥＬ映像に対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅｆｏｒＭＭＴＥＬｖｉｄｅｏ)またはＳＭＳｏｖｅｒＩＰに対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅｆｏｒＳＭＳｏｖｅｒＩＰ)を確認し、前記サービス要求に対してＡＣＢに対する検査を通過させるようになる。以後、ＲＲＣ接続要求メッセージを基地局に送信する。このとき、ＲＲＣ接続要求メッセージの確立原因は、ＭＯ−ｄａｔａに設定される。

または、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳ階層からサービス要求と共に提供されるＭＭＴＥＬ音声/ビデオに対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅｆｏｒＭＭＴＥＬｖｏｉｃｅ/ｖｉｄｅｏ)またはＳＭＳｏｖｅｒＩＰに対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅｆｏｒＳＭＳｏｖｅｒＩＰ)を確認し、前記サービス要求に対してＡＣＢに対する検査を通過(ｓｋｉｐ)させるようになる。以後、ＲＲＣ接続要求メッセージを基地局に送信する。このとき、ＲＲＣ接続要求メッセージの確立原因は、ＭＯ−ｄａｔａに設定される。

ＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ；ＳＭＳｏｖｅｒＮＡＳ)の場合、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳ階層のサービス要求に対する呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、前記サービス要求が発信(ＭＯ)ＳＭＳサービス連結のためのサービス要求であることを認知し、ネットワークから提供を受けたＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)サービスに対するＡＣＢスキップ情報/インジケーションを確認した結果、もし、ＳＭＳに対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、前記サービス要求に対してＡＣＢに対する検査を通過(ｓｋｉｐ)させるようになる。以後、ＲＲＣ接続要求メッセージを基地局に送信する。このとき、ＲＲＣ接続要求メッセージの確立原因は、ＭＯ−ｄａｔａに設定される。

または、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結が終われると/終了すると、ＭＭＴＥＬのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声に対するＡＣＢスキップ終了(ｆａｌｓｅ/ｓｔｏｐ/ｒｅｓｅｔ)インジケーション/情報、ＭＯＭＭＴＥＬ映像に対するＡＣＢスキップ終了(ｆａｌｓｅ/ｓｔｏｐ/ｒｅｓｅｔ)インジケーション/情報をＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層からＳＭＳｏｖｅｒＩＰセッションの終了を知らせるＡＣＢスキップ終了(ｆａｌｓｅ/ｓｔｏｐ/ｒｅｓｅｔ)インジケーション/情報をＮＡＳ階層に提供する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰに対するセッション/呼び(ｃａｌｌ)終了(ｆａｌｓｅ/ｓｔｏｐ/ｒｅｓｅｔ)インジケーション/情報を提供すると、ＮＡＳ階層は、ＭＯＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰに対するセッション/呼び(ｃａｌｌ)終了であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像ｏｒＳＭＳｏｖｅｒＩＰセッションに対してＡＣＢに対する検査の通過を適用しない。即ち、一般的なセッションと認知してＡＣＢを適用させる。

<提案７>

提案７によると、ネットワーク(例えば、基地局)がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像、ＭＯＳＭＳのためのＡＣＢスキップ情報をＳＩＢ２を介してＵＥに提供する。このとき、ＡＳ階層(例えば、ＲＲＣ階層)からこのＡＣＢスキップ情報をＭＭＴＥＬ(ＩＭＳ；ＳＭＳｏｖｅｒＩＰを含む)階層及び/またはＮＡＳ階層に送信し、この情報に基づいてＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰに対してＡＣＢに対する検査を通過(ｓｋｉｐ)させるかどうかを決定し、ＮＡＳ階層またはＡＳ階層(例えば、ＲＲＣ階層)にＡＣＢスキップ情報を知らせる。

図２３ａ及び図２３ｂは、本明細書の提案７を示す信号流れ図である。

図２３ａ及び図２３ｂを参照すると、ネットワーク(例えば、基地局)からＡＣＢスキップ情報状態の変更/変動(例えば、ＡＣＢｓｋｉｐｓｅｔ/ｔｒｕｅからＡＣＢｓｋｉｐｒｅｓｅｔ/ｆａｌｓｅへの変更またはＡＣＢｓｋｉｐｒｅｓｅｔ/ｆａｌｓｅからＡＣＢｓｋｉｐｓｅｔ/ｒｅｓｅｔへの変更)が発生すると、直ちにＡＳ階層(即ち、ＲＲＣ階層)は、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層(または、ＮＡＳ階層)にＡＣＢスキップ情報変更/変動を知らせる。ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、ＮＡＳ階層(または、ＲＲＣ階層)にＡＣＢスキップ情報の変更/変動を知らせる。このようなＡＣＢスキップインジケーション/情報に基づいて、ＮＡＳ階層は、サービス要求手順を実行する。例えば、サービス要求またはＡＣＢスキップインジケーションを有する拡張サービス要求をＲＲＣ階層に伝達する。ＲＲＣ階層ではこのようなＮＡＳ階層(または、ＩＭＳ階層)から提供を受けたＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)情報変更/変動によって最終的にＡＣＢに対する検査を通過(ｓｋｉｐ)させたり、またはＡＣＢを適用させたりする。

ＲＲＣ階層がシステム情報(例えば、ＳＩＢ２)を介してＡＣＢスキップ情報/インジケーションの提供を受けない場合、前記ＲＲＣ階層は、ＡＣＢスキップ情報をＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰに対して検索し、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰに対するＡＣＢの検査通過(ｓｋｉｐ)に対して‘ＭＭＴＥＬｓｅｔ/ｓｔａｒｔ/ｔｒｕｅ/ｂｅｇｉｎ’でＩＭＳ階層(または、ＮＡＳ階層)に指示したり、またはＡＣＢの検査通過の非適用に対して‘ＭＭＴＥＬｒｅｓｅｔ/ｓｔｏｐ/ｆａｌｓｅ/ｅｎｄ’でＩＭＳ階層(または、ＮＡＳ階層)に指示する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰからＡＣＢスキップ情報を受信すると、ＮＡＳ階層は、サービス要求またはＡＣＢスキップインジケーションを有する拡張サービス要求をＲＲＣ階層に伝達する。前記階層は、サービス要求またはＡＣＢスキップインジケーションを有する拡張サービス要求を受信すると、前記ＲＲＣ階層は、ＡＣＢを適用せずに通過させる。

前記ＡＣＢスキップ情報は、周期的に提供/更新されることができる。このたびにＡＳ階層(即ち、ＲＲＣ階層)は、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層またはＮＡＳ階層にＡＣＢスキップ情報を提供することができる。

図２４ａ及び図２４ｂは、本明細書の提案７の変形例を示す信号流れ図である。

図２４ａ及び図２４ｂを参照すると、ネットワーク(例えば、基地局)から提供されるＡＣＢスキップ情報状態の変更/変動(例えば、ＡＣＢｓｋｉｐｓｅｔ/ｔｒｕｅからＡＣＢｓｋｉｐｒｅｓｅｔ/ｆａｌｓｅへの変更またはＡＣＢｓｋｉｐｒｅｓｅｔ/ｆａｌｓｅからＡＣＢｓｋｉｐｓｅｔ/ｒｅｓｅｔへの変更)が発生し、またはＡＣＢスキップ情報が周期的に受信されると、ＡＳ階層(即ち、ＲＲＣ階層)は、ＮＡＳ階層にＡＣＢスキップ情報変更/変動を直ちに知らせることができる。ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、ＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰに対するセッション/呼び(ｃａｌｌ)開始時、ＮＡＳ階層にＡＣＢｓｋｉｐｓｅｔ/ｓｔａｒｔ/ｔｒｕｅ/ｂｅｇｉｎ(/ｒｅｓｅｔ/ｓｔｏｐ/ｆａｌｓｅ/ｅｎｄ)インジケーション/情報を提供する。ＮＡＳ階層は、前記ＡＣＢスキップインジケーション/情報を認知した後、ＲＲＣ階層から提供を受けたＡＣＢスキップ情報変更/変動に基づいて、ＮＡＳ階層は、サービス要求手順を実行することができる。以後、ＲＲＣ階層ではこのようなＮＡＳ階層で提供を受けたＡＣＢスキップインジケーション/情報(変更/変動)によって最終的にＡＣＢに対する検査を通過(ｓｋｉｐ)させ、またはＡＣＢを適用することができる。

<提案８>

図２５ａ及び図２５ｂは、本明細書の提案８を示す信号流れ図である。

図２５ａ及び図２５ｂを参照すると、ネットワークがＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳのためのＡＣＢスキップ情報をＳＩＢ２を介してＵＥに提供する。このとき、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)からこのＡＣＢスキップ情報をＭＭＴＥＬ/ＳＭＳのための階層(即ち、ＩＭＳ階層)またはＮＡＳ階層に送信し、この情報に基づいてＭＭＴＥＬ/ＳＭＳのための階層(即ち、ＩＭＳ階層)でＭＭＴＥＬ音声/映像/ＳＭＳに対するＡＣＢの検査通過(ｓｋｉｐ)可否を決定し、ＮＡＳ階層にＡＣＢスキップ情報を知らせる。

提案８によると、ＲＬＦ(ｒａｄｉｏｌｉｎｋｆａｉｌｕｒｅ)または下位階層の失敗/エラーなどによりＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰに対する再送信が発生した場合(ＱＣＩ＝１ベアラ確立完了以前に再送信またはＱＣＩ＝１ベアラ確立完了以後に再送信)、ＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳ階層に下位階層の失敗/エラーを知らせ、ＮＡＳ階層は、ＮＡＳシグナリング連結(再)設定のためのＮＡＳ復旧手順を実行する。(ここで、ＱＣＩ＝１ベアラは、音声サービス(ＶｏＬＴＥｃａｌｌを含む)のためのベアラを意味する)

ＮＡＳ階層は、サービス要求手順を実行する時、ＡＣＢスキップインジケーションをＲＲＣ階層に提供したことを記憶している。

このとき、下位階層の失敗/エラーにより再送信が発生する場合、ＮＡＳ階層は、下位階層の失敗/エラーに対するインジケーションをＲＲＣ階層から提供を受けるようになり、これを以前状態(ＡＣＢｓｋｉｐ適用状態またはＡＣＢ適用状態)を維持(ｋｅｅｐ)すると認知することもできる。

ＮＡＳ階層は、再送信のためのサービス要求手順を(再)実行する時、以前に実行したサービス要求手順のＡＣＢスキップインジケーションの提供状態をそのまま適用することで、ＡＣＢスキップインジケーション/情報またはＮｏＡＣＢスキップインジケーション/情報を共に提供する。

ＲＲＣ階層ではこのようなＮＡＳ階層から提供を受けたＡＣＢスキップインジケーション/情報によって最終ＡＣＢｓｋｉｐし、またはＮｏＡＣＢｓｋｉｐ(例えば、ＡＣＢｉｓａｐｐｌｉｅｄ)する。

<提案９>

図２６ａ及び図２６ｂは、本明細書の提案９を示す信号流れ図である。

図２６ａ及び図２６ｂを参照すると、ネットワーク(例えば、基地局)がＭＭＴＥＬ音声、ＭＭＴＥＬ映像、ＳＭＳ(ＳＭＳｏｖｅｒＩＰ及び/またはＳＭＳｏｖｅｒＮＡＳ)のためのＡＣＢスキップ情報をシステム情報(例えば、ＳＩＢ２)を介してＵＥに提供する。このとき、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、このＡＣＢスキップ情報をＮＡＳ階層に送信する。このとき、ＳＩＢ２を介して提供されるＡＣＢスキップ情報は、周期的に提供されることもでき、ＡＣＢスキップ情報が変化された時に提供されることもでき、このように受信されたＡＣＢスキップ情報をＡＳ階層(例えば、ＲＲＣ階層)は、直ちにＮＡＳ階層に提供(送信)する。ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、ＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰが開始またはトリガリングされる時、ＡＣＢｓｋｉｐＳＥＴ/ＳＴＡＲＴをＮＡＳ階層に送信する。このとき、ＡＣＢｓｋｉｐＳＥＴ/ＳＴＡＲＴは、ｏｎｅ−ｂｉｔｉｎｄｉｃａｔｉｏｎであり、またはＭＭＴＥＬ−ｖｏｉｃｅ−ＡＣＢ−ｓｋｉｐ−ＳＥＴ/ＳＴＡＲＴ、ＭＭＴＥＬ−ｖｉｄｅｏ−ＡＣＢ−ｓｋｉｐ−ＳＥＴ/ＳＴＡＲＴ、ＳＭＳｏｖｅｒＩＰ−ＡＣＢ−ｓｋｉｐ−ＳＥＴ/ＳＴＡＲＴのようにＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰによって各々区分されるインジケーション/情報である。このとき、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、実際ネットワークからＡＣＢスキップ情報がＡＣＢｓｋｉｐ適用が設定された場合と関係なしに、ＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰが開始またはトリガリングされる時、前記ＭＭＴＥＬ−ｖｏｉｃｅ/ｖｉｄｅｏ−ＡＣＢ−ｓｋｉｐ−ＳＥＴ/ＳＴＡＲＴまたはＳＭＳｏｖｅｒＩＰ−ＡＣＢ−ｓｋｉｐ−ＳＥＴ/ＳＴＡＲＴインジケーション/情報をＮＡＳ階層に提供する。

前記ＮＡＳ階層は、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がこのようなＡＣＢｓｋｉｐＳＥＴ/ＳＴＡＲＴインジケーション/情報の受信を受けた後、ＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰのパケットを送信するためにサービス要求手順を開始(実行)する。このとき、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＡＣＢスキップ設定によって、ＡＳ階層(例えば、ＲＲＣ階層)にＡＣＢ−ｓｋｉｐ−ＯＮ/ＴＲＵＥ−ｉｎｄｉｃａｔｉｏｎ/ｉｎｆｏｒｍａｔｉｏｎ情報を提供する。このようなＡＣＢｓｋｉｐ−ＯＮ/ＴＲＵＥ−ｉｎｄｉｃａｔｉｏｎ/ｉｎｆｏｒｍａｔｉｏｎは、サービス要求手順を開始(実行)する時に提供されることもでき、サービス要求手順と関係なしに直ちに提供されることもできる。

図２７ａ及び図２７ｂは、本明細書の提案９の変形例を示す信号流れ図である。

図２７ａ及び図２７ｂを参照して分かるように、ＮＡＳ階層は、このようなＡＣＢｓｋｉｐ−ＯＮ/ＴＲＵＥ−ｉｎｄｉｃａｔｉｏｎ/ｉｎｆｏｒｍａｔｉｏｎをＮＡＳ復旧のためのＴＡＵ要求手順を開始(実行)する時も提供されることができ、またはＴＡＵ要求手順と関係なしに直ちに提供されることもできる。

ＡＳ階層(例えば、ＲＲＣ階層)で、ＮＡＳ階層で提供する前記ＡＣＢｓｋｉｐ−ＯＮ/ＴＲＵＥ−ｉｎｄｉｃａｔｉｏｎ/ｉｎｆｏｒｍａｔｉｏｎによって、該当サービス要求メッセージに対してＡＣＢに対する検査を通過させるようになる。

もし、ＮＡＳ復旧のためのＴＡＵ要求手順が開始(実行)する場合、ＡＳ階層(例えば、ＲＲＣ階層)で、前記ＡＣＢｓｋｉｐ−ＯＮ/ＴＲＵＥ−ｉｎｄｉｃａｔｉｏｎ/ｉｎｆｏｒｍａｔｉｏｎによって、該当ＴＡＵ要求メッセージ(ＲＲＣ確立原因は、ＭＯｓｉｇｎａｌｌｉｎｇに設定される)に対してＡＣＢに対する検査を通過させたり適用したりするようになる。

該当ＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰのためのセッションが終了すると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬサービス(送信)終了を知らせるＡＣＢｓｋｉｐＲＥＳＥＴ/ＳＴＯＰをＮＡＳ階層に送信する。このとき、ＡＣＢｓｋｉｐＲＥＳＥＴ/ＳＴＯＰは、ｏｎｅ−ｂｉｔｉｎｄｉｃａｔｉｏｎであり、またはＭＭＴＥＬ−ｖｏｉｃｅ−ＡＣＢ−ｓｋｉｐ−ＲＥＳＥＴ/ＳＴＯＰ、ＭＭＴＥＬ−ｖｉｄｅｏ−ＡＣＢ−ｓｋｉｐ−ＲＥＳＥＴ/ＳＴＯＰ、ＳＭＳｏｖｅｒＩＰ−ＡＣＢ−ｓｋｉｐ−ＲＥＳＥＴ/ＳＴＯＰのようにＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰによって各々区分されるインジケーション/情報である。ＭＭＴＥＬ階層でＡＣＢｓｋｉｐＲＥＳＥＴ/ＳＴＯＰインジケーション/情報を受信すると、ＮＡＳ階層は、以後に開始/発生するサービス要求手順(または、ＴＡＵ要求手順)にＡＣＢｓｋｉｐ−ＯＮ/ＴＲＵＥｉｎｄｉｃａｔｉｏｎ/ｉｎｆｏｒｍａｔｉｏｎを共に/別途にＡＳ階層(例えば、ＲＲＣ階層)に提供しない。

上記提案で、ＮＡＳ階層がサービス要求手順(または、ＴＡＵ要求手順)を開始/実行する時、ＲＲＣ階層にネットワークからＳＩＢ２を介して提供を受けたＡＣＢスキップ情報を要求することもでき、ＲＲＣ階層がシステム情報(ＳＩ)がアップデートされるたびにまたはシステム情報(ＳＩ)内のＡＣＢスキップ情報の変更を確認するたびに、ＮＡＳ階層に直ちに(ネットワークから提供を受けた)ＡＣＢスキップ情報を提供することもできる。

ＮＡＳ復旧のためにサービス要求手順またはＴＡＵ要求手順が実行されることができ、サービス要求手順は、アップリンクデータがある場合に実行されることができ、前記ＴＡＵ要求手順は、アップリンクデータがない場合に実行されることができる。

<提案１０−１/１０−２/１０−３の概要>

図２８ａ及び図２８ｂは、本明細書の提案１０−１/１０−２/１０−３を示す信号流れ図である。

図２８ａ及び図２８ｂを参照すると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰまたはＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像セッション/呼び(ｃａｌｌ)であることを知らせるインジケーション/情報をＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＳＭＳｏｖｅｒＩＰセッションであることを知らせるインジケーション/情報をＮＡＳ階層に提供する。

または、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声サービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、他のＭＭＴＥＬ音声サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ音声セッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ映像サービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ映像サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、他のＭＭＴＥＬ音声サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ映像セッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳｏｖｅｒＩＰサービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、ＳＭＳｏｖｅｒＩＰサービスセッションが進行していないかを確認した後、もし、ない場合、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、ＳＭＳｏｖｅｒＩＰセッションの開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声/映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎを提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声/映像またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声/映像またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ＡＣＢスキップインジケーションをＡＳ階層(例えば、ＲＲＣ階層)に提供する。

一方、提案１０−２/１０−３によると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結が終われると/終了すると、他のＭＭＴＥＬ音声、ＭＭＴＥＬ映像サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像セッション/呼び(ｃａｌｌ)の終了を知らせるＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層で他のＳＭＳｏｖｅｒＩＰサービスセッションが進行していないかを確認した後、もし、ない場合、ＳＭＳｏｖｅｒＩＰセッションの終了を知らせるＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

また、提案１０−２/１０−３によると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するｒｅｓｅｔｉｎｄｉｃａｔｉｏｎ(即ち、ＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎ)を提供すると、ＮＡＳ階層は、ＭＯＭＭＴＥＬ音声/映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)終了であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声/映像またはＳＭＳｏｖｅｒＩＰのためのセッションに対してＡＣＢに対する検査を通過(ｓｋｉｐ)させない。即ち、一般的なデータのためのセッションと認知し、サービス要求手順を実行するようになり、ＡＳ階層(即ち、ＲＲＣ階層)ではＡＣＢを適用させる。

一方、ネットワークで提供されるＡＣＢｓｋｉｐｉｎｆｏｒｍａｔｉｏｎが変更された時、ＡＳ階層(例えば、ＲＲＣ階層)は、変更された情報をＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層とＮＡＳ階層に提供する。ＭＭＴＥＬのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合(即ち、ＡＣＢスキップ情報が変更された場合)、ＭＭＴＥＬ音声セッションが進行していると、ＭＭＴＥＬのためのＩＭＳ階層は、直ちにＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。ＭＭＴＥＬのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ映像サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合(即ち、ＡＣＢスキップ情報が変更された場合)、ＭＭＴＥＬのためのＩＭＳ階層は、直ちにＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合(即ち、ＡＣＢスキップ情報が変更された場合)、ＳＭＳｏｖｅｒＩＰサービスセッションが進行していると、直ちにＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。もし、変更されたＡＣＢスキップ情報がＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｒｅｓｅｔ/ｆａｌｓｅの場合、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰセッションが進行していると、ＭＭＴＥＬ音声/映像のためのＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎ、ＳＭＳｏｖｅｒＩＰのためのＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎを直ちにＮＡＳ階層に提供する。ＮＡＳ階層は、前記ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰ(ＩＭＳ)階層で提供を受けたＡＣＢスキップインジケーション/情報変更によって、以後サービス要求手順を実行する。

<提案１０−１>

提案１０−１によると、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ネットワークから提供を受けたＡＣＢスキップ情報をＮＡＳ階層に提供する。このとき、ＡＳ階層(例えば、ＲＲＣ階層)は、ネットワークから提供を受けたＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰ/ＳＭＳｏｖｅｒＮＡＳのためのＡＣＢスキップ情報をＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層と共にＮＡＳ階層の両方ともに提供することもできる。もし、ネットワークから提供を受けた情報がＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰサービスのみの場合は、ＡＣＢスキップ情報をＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層にのみ提供することもできる。また、ネットワークから提供を受けた情報がＳＭＳサービスのみを含んでいる場合、ＡＣＢスキップ情報をＮＡＳ階層にのみ提供することもできる。

図２９ａ及び図２９ｂは、本明細書の提案１０−１の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図２９ａ及び図２９ｂを参照すると、ＳＭＳｏｖｅｒＮＡＳの場合、ＮＡＳ階層は、ＭＯＳＭＳ連結のためのサービス要求手順を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳｏｖｅｒＮＡＳサービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、ＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)を共にＡＳ階層(例えば、ＲＲＣ階層)に提供する。

一方、提案１０−１による改善を説明すると、下記の通りである。

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

ＡＣＢは、下記の場合に適用されない。

−サービス要求手順がＳＭＳ送信のために要求され、下位階層は、ＡＣＢをスキップするように設定される場合

−サービス要求手順がユーザ平面の無線リソースに対する上位階層の要求により開始され、上位階層がＡＣＢに対する検査の通過(ｓｋｉｐ)を指示した場合

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

一方、ＲＲＣ確立原因(ｅｓｔａｂｌｉｓｈｍｅｎｔｃａｕｓｅ)をマッピングするＮＡＳ階層の手順に対する改善を説明すると、下記の通りである。

ＥＭＭがＮＡＳシグナリング連結の確立を要求する場合、ＵＥにより使われるＲＲＣ確立原因は、ＮＡＳ手順によって選択される。ＥＭＭは、アクセス制御の目的として、下位階層にＲＲＣ確立原因と関連した呼びタイプ(ｃａｌｌｔｙｐｅ)を知らせなければならない。さらに、ＥＭＭがＮＡＳ−シグナリング連結を要求する時、上位階層がＡＣＢに対する検査の通過を指示する場合、ＥＭＭは、ＡＣＢに対する検査の通過を下位階層に伝達しなければならない。ＵＥがＥＡＢ(ＥｘｔｅｎｄｅｄＡｃｃｅｓｓＢａｒｒｉｎｇ)が設定される場合、アクセス制御の目的として、ＥＭＭは、下記のケースを除いてはＥＡＢをそのような要求に適用させる。

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

ＥＭＭは、アクセス制御の目的として、下記のケースに該当すると、下位階層にＡＣＢを適用しないことを指示する：

−ＳＭＳの送信に対する要求を受信し、下位階層がＳＭＳに対してはＡＣＢに対する検査の通過を指示する場合

−ユーザ平面の無線リソースに対して上位階層から要求を受信し、上位階層は、ＡＣＢに対する検査の通過を指示する場合

<提案１０−２>

提案１０−２によると、ＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)内容が下記のように改善されることができる。

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

−ＡＣＢＳｋｉｐＦｏｒＭＭＴＥＬ−Ｖｏｉｃｅ：ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ；

−ＡＣＢＳｋｉｐＦｏｒＭＭＴＥＬ−Ｖｉｄｅｏ：ＭＭＴＥＬ映像に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ。

下記の情報がＮＡＳ階層に伝達されることができる。

−ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎ；ａｎｄ

−ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎ

１)マルチメディアテレフォニ通信セッション内にオーディオが提供される場合、オーディオのための他のマルチメディアテレフォニ通信セッションはない場合、ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定される場合、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

２)マルチメディアテレフォニ通信セッション内にビデオが提供される場合、ビデオのための他のマルチメディアテレフォニ通信セッションはない場合、ＭＭＴＥＬ映像に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定される場合、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

ＡＳ階層から提供されたＡＣＢスキップ情報がマルチメディアテレフォニ通信セッションが進行中の状態で変更される場合、ＵＥは、下記のように動作する。

１)前記マルチメディアテレフォニ通信セッション内でオーディオが提供され、ＭＭＴＥＬ音声に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔが変更される場合、

もし、ＭＭＴＥＬ音声に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されていた場合、ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達し、進行中のセッションを続ける。

そうでない場合、ＵＥは、ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達し、進行中のセッションを続ける。

２)もし、前記マルチメディアテレフォニ通信セッション内で映像が提供され、ＭＭＴＥＬ映像に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔが変更される場合、

もし、ＭＭＴＥＬ映像に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されていた場合、ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達し、進行中のセッションを続ける。

ＡＳ階層から提供されたＡＣＢスキップ情報の変更は、下記を含む：(１)ＡＣＢスキップ情報が提供されない状態から提供される状態への変更、(２)ＡＣＢスキップ情報の値変更

マルチメディアテレフォニ通信セッションが終了する時、前記マルチメディアテレフォニ通信セッションが音声を提供するために開始されたものであり、音声を提供するための他のマルチメディアテレフォニ通信セッションは存在しない場合、前記ＵＥは、ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達しなければならない。

同様に、マルチメディアテレフォニ通信セッションが終了する時、前記マルチメディアテレフォニ通信セッションが映像を提供するために開始されたものであり、映像を提供するための他のマルチメディアテレフォニ通信セッションは存在しない場合、前記ＵＥは、ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達しなければならない。

その代案として、ＳＣＭ(ＳｍａｒｔＣｏｎｇｅｓｔｉｏｎＭｉｔｉｇａｔｉｏｎ)内容が下記のように改善されることができる。

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

−ＡＣＢＳｋｉｐＦｏｒＭＭＴＥＬ−Ｖｉｄｅｏ：ＭＭＴＥＬ映像のためのＡＣＢｓｋｉｐｐｉｎｇｂｉｔ。

下記の情報がＮＡＳ階層に伝達される。

−ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎ

１)マルチメディアテレフォニ通信セッション内にオーディオのみが提供される場合、オーディオのための他のマルチメディアテレフォニ通信セッションはない場合、ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されると、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

２)マルチメディアテレフォニ通信セッション内にビデオのみが提供される場合、ビデオのための他のマルチメディアテレフォニ通信セッションはない場合、ＭＭＴＥＬ映像に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されると、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

もし、マルチメディアテレフォニ通信セッションが開始された時はＡＳ階層からＡＣＢスキップ情報が提供されなかったが、マルチメディアテレフォニ通信セッションが進行中である時はＡＣＢスキップ情報が提供された場合、またはマルチメディアテレフォニ通信セッションが開始された時はＡＣＢスキップ情報が提供されたが、マルチメディアテレフォニ通信セッションが進行中である時はＡＣＢスキップ情報が変更された場合、ＵＥは、下記のように動作する。

マルチメディアテレフォニ通信セッション内にオーディオのみが提供される場合、

１)ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されない状態から設定される状態へ変更された場合、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

２)ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定される状態から設定されない状態へ変更された場合、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

３)マルチメディアテレフォニ通信セッションが開始された時はＭＭＴＥＬに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔがＡＳ階層から提供されなかったが、マルチメディアテレフォニ通信セッションが進行中である時はＡＣＢｓｋｉｐｐｉｎｇｂｉｔが提供され、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されている場合、ＵＥは、ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

他の一方、マルチメディアテレフォニ通信セッション内に映像のみが提供される場合、

１)ＭＭＴＥＬ映像に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されない状態から設定される状態へ変更された場合、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

２)ＭＭＴＥＬ映像に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定される状態から設定されない状態へ変更された場合、ＵＥは、ＮＡＳ階層にＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎを伝達し、セッション確立を続ける。

マルチメディアテレフォニ通信セッションが終了する時、マルチメディアテレフォニ通信セッションがオーディオを提供するために開始され、オーディオを提供するための他のマルチメディアテレフォニ通信セッションはない場合、ＵＥは、ＭＭＴＥＬ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

<提案１０−３>

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

−ＡＣＢＳｋｉｐＦｏｒＳＭＳ−ｏｖｅｒ−ＩＰ：ＳＭＳ−ｏｖｅｒ−ＩＰのためのＡＣＢｓｋｉｐｐｉｎｇｂｉｔｆｏｒ。

下記の情報がＮＡＳ階層に伝達されることができる。

−ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎ

−ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎ

ＳＭＳｏｖｅｒＩＰの送信に対するユーザからの要求を受信した時、他のＳＭＳｏｖｅｒＩＰの送信がない場合、ＵＥは、下記のように動作する。

１)もし、ＳＭＳ−ｏｖｅｒ−ＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達し、ＳＭＳｏｖｅｒＩＰの送信を進行し続ける。

ＡＳ階層から提供されたＡＣＢスキップ情報がＳＭＳｏｖｅｒＩＰの進行中に変更される場合、ＵＥは、下記のように動作する。

１)もし、ＳＭＳ−ｏｖｅｒ−ＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達し、ＳＭＳｏｖｅｒＩＰの送信を続ける。

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

−ＡＣＢＳｋｉｐＦｏｒＳＭＳ−ｏｖｅｒ−ＩＰ：ＳＭＳ−ｏｖｅｒ−ＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ。

下記の情報がＮＡＳ階層に伝達されることができる。

−ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎ；

ＳＭＳｏｖｅｒＩＰの送信に対するユーザからの要求を受信した時、送信する他のＳＭＳｏｖｅｒＩＰがない場合、ＵＥは、下記のように動作する。

１)ＳＭＳ−ｏｖｅｒ−ＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

ＳＭＳｏｖｅｒＩＰが開始される時はＡＣＢスキップ情報がＡＳ階層から提供されなかったが、ＳＭＳｏｖｅｒＩＰを進行する間はＡＣＢスキップ情報が提供された場合、またはＳＭＳｏｖｅｒＩＰが開始される時はＡＣＢスキップ情報がＡＳ階層から提供されたが、ＳＭＳｏｖｅｒＩＰを進行する間はＡＣＢスキップ情報が提供されない場合、ＵＥは、下記のように動作することができる。

１)ＳＭＳ−ｏｖｅｒ−ＩＰが開始される時はＳＭＳｏｖｅｒＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔがＡＳ階層から提供されない場合、そしてＳＭＳｏｖｅｒＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定された場合、ＵＥは、ＳＭＳｏｖｅｒＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

２)ＳＭＳ−ｏｖｅｒ−ＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定されない状態から設定される状態へ変更された場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

３)ＳＭＳ−ｏｖｅｒ−ＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔが設定される状態から設定されない状態へ変更された場合、ＵＥは、ＳＭＳ−ｏｖｅｒ−ＩＰ識別子を有するＡＣＢ−ｓｋｉｐ−ｒｅｓｅｔ−ｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に伝達する。

<提案１１>

図３０ａ及び図３０ｂは、本明細書の提案１１を示す信号流れ図である。

図３０ａ及び図３０ｂを参照して分かるように、ＭＭＴＥＬのためのＩＭＳ階層がＭＯ(Ｍｏｂｉｌｅｏｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声サービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声サービスに対するＡＣＢスキップ情報を確認し、もし、ＭＭＴＥＬ音声に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔの場合、他のＭＭＴＥＬ音声サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ音声のためのセッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＭＭＴＥＬのためのＩＭＳ階層がＭＯ(Ｍｏｂｉｌｅｏｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ映像サービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ映像サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔの場合、他のＭＭＴＥＬ映像サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ映像のためのセッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＳＭＳｏｖｅｒＩＰサービス連結を開始する時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢｓｋｉｐｉｎｆｏｒｍａｔｉｏｎを確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔの場合、ＳＭＳｏｖｅｒＩＰサービスセッションが進行していないかを確認した後、もし、ない場合、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、ＳＭＳｏｖｅｒＩＰセッションの開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声/映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎを提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データのためのセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声/映像またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)開始であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声/映像またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。サービス要求手順の開始時、ＭＭＴＥＬ音声/映像に対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)またはＳＭＳｏｖｅｒＩＰに対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ/ｔｒｕｅ)をＡＳ階層(例えば、ＲＲＣ階層)に提供する。

図３１ａ及び図３１ｂは、本明細書の提案１１の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図３１ａ及び図３１ｂを参照すると、ＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)の場合、ＮＡＳ階層は、ＭＯ(Ｍｏｂｉｌｅｏｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのサービス要求手順の開始時、ＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔの場合、ＳＭＳ(ＳＭＳｏｖｅｒＮＡＳ)に対するＡＣＢスキップインジケーション(即ち、ＡＣＢｓｋｉｐ＝ｓｅｔ)を共にＡＳ階層(例えば、ＲＲＣ階層)に提供する。

再び、図３０ａ及び図３０ｂを参照すると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結が終われると/終了すると、他のＭＭＴＥＬ音声、ＭＭＴＥＬ映像サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像のためのセッション/呼び(ｃａｌｌ)の終了を知らせるＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層で他のＳＭＳｏｖｅｒＩＰサービスセッションが進行していないかを確認した後、もし、ない場合、ＳＭＳｏｖｅｒＩＰのためのセッションの終了を知らせるＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎまたはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼びに対するＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎを提供すると、ＮＡＳ階層は、ＭＯＭＭＴＥＬ音声/映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)終了であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声/映像またはＳＭＳｏｖｅｒＩＰセッションに対してＡＣＢに対する検査を通過(ｓｋｉｐ)させない。

一方、ネットワークで提供されるＡＣＢスキップ情報が変更された時、ＡＳ階層(例えば、ＲＲＣ階層)は、変更された情報をＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層とＮＡＳ階層に提供する。ＭＭＴＥＬのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声サービスに対するＡＣＢスキップ情報を確認し、もし、ＭＭＴＥＬ音声に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔの場合(即ち、ＡＣＢスキップ情報が変更された場合)、ＭＭＴＥＬ音声セッションが進行していると、ＭＭＴＥＬのためのＩＭＳ階層は、直ちにＭＯＭＭＴＥＬに対するＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。ＭＭＴＥＬのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ映像サービスに対するＡＣＢスキップ情報を確認し、もし、ＭＭＴＥＬ映像に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合(即ち、ＡＣＢスキップ情報が変更された場合)、ＭＭＴＥＬのためのＩＭＳ階層は、直ちにＭＯＭＭＴＥＬに対するＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報を確認し、もし、ＳＭＳｏｖｅｒＩＰに対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅｆｏｒの場合(即ち、ＡＣＢスキップ情報が変更された場合)、ＳＭＳｏｖｅｒＩＰサービスセッションが進行していると、直ちにＭＯＳＭＳｏｖｅｒＩＰに対するＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。

もし、ＭＭＴＥＬのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ音声サービスに対するＡＣＢスキップ情報を確認し、もし、ＭＭＴＥＬ音声に対するＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｎｏｔｓｅｔの場合(ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔｆｏｒＭＭＴＥＬｖｏｉｃｅからＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｎｏｔｓｅｔｆｏｒＭＭＴＥＬｖｏｉｃｅに変更された場合)、ＭＭＴＥＬ音声セッションが進行していると、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＯＭＭＴＥＬに対するＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。ＭＭＴＥＬのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＭＭＴＥＬ映像サービスに対するＡＣＢスキップ情報を確認し、もし、ＭＭＴＥＬ映像に対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｎｏｔｓｅｔの場合(即ち、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔｆｏｒＭＭＴＥＬｖｉｄｅｏからＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｎｏｔｓｅｔｆｏｒＭＭＴＥＬｖｉｄｅｏに変更された場合)、ＭＭＴＥＬのためのＩＭＳ階層は、直ちにＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＡＳ階層(例えば、ＲＲＣ階層)から提供を受けたＳＭＳｏｖｅｒＩＰサービスに対するＡＣＢスキップ情報を確認し、もし、ＳＭＳｏｖｅｒＩＰに対してＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｎｏｔｓｅｔの場合(即ち、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔｆｏｒＳＭＳｏｖｅｒＩＰからＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｎｏｔｓｅｔｆｏｒＳＭＳｏｖｅｒＩＰに変更された場合)、ＳＭＳｏｖｅｒＩＰサービスセッションが進行していると、直ちにＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＳＭＳｏｖｅｒＩＰをＮＡＳ階層に提供する。

ＮＡＳ階層は、前記ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰ(ＩＭＳ)階層で提供を受けたＡＣＢスキップインジケーション/情報変更によって、以後サービス要求手順を実行する。

一方、ＮＡＳ階層は、このようなＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎ情報をＮＡＳ復旧のためのＴＡＵ要求手順を開始(実行)する時も提供することができる。

もし、ＮＡＳ復旧のためのＴＡＵ要求手順が開始(実行)する場合、ＡＳ階層(例えば、ＲＲＣ階層)で、前記ＮＡＳ階層から提供を受けたＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎ情報によって、該当ＴＡＵ要求メッセージ(ＲＲＣ確立原因は、ＭＯｓｉｇｎａｌｌｉｎｇに設定される)のＡＣＢをｓｋｉｐ(適用)するようになる。

該当ＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰセッションが終了すると、ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＭＴＥＬサービス(送信)終了を知らせるＡＣＢｓｋｉｐＲＥＳＥＴ/ＳＴＯＰをＮＡＳ階層に送信する。このとき、ＡＣＢｓｋｉｐＲＥＳＥＴ/ＳＴＯＰは、ｏｎｅ−ｂｉｔｉｎｄｉｃａｔｉｏｎであり、またはＭＭＴＥＬ−ｖｏｉｃｅ−ＡＣＢ−ｓｋｉｐ−ＲＥＳＥＴ/ＳＴＯＰ、ＭＭＴＥＬ−ｖｉｄｅｏ−ＡＣＢ−ｓｋｉｐ−ＲＥＳＥＴ/ＳＴＯＰ、ＳＭＳｏｖｅｒＩＰ−ＡＣＢ−ｓｋｉｐ−ＲＥＳＥＴ/ＳＴＯＰのようにＭＭＴＥＬ音声/映像/ＳＭＳｏｖｅｒＩＰによって各々区分されるインジケーション/情報である。ＭＭＴＥＬ階層でＡＣＢｓｋｉｐＲＥＳＥＴ/ＳＴＯＰインジケーション/情報を受信すると、ＮＡＳ階層は、以後に開始/発生するサービス要求手順(または、ＴＡＵ要求手順)にＡＣＢｓｋｉｐ−ＯＮ/ＴＲＵＥインジケーション/情報を共に/別途にＡＳ階層(例えば、ＲＲＣ階層)に提供しない。

上記提案で、ＮＡＳ階層がサービス要求手順(または、ＴＡＵ要求手順)を開始/実行する時、ＲＲＣ階層にネットワークからＳＩＢ２を介して提供を受けたＡＣＢスキップ情報を要求することもでき、ＲＲＣ階層がシステム情報(ＳＩ)がアップデートされるたびにまたはシステム情報(ＳＩ)内のＡＣＢｓｋｉｐｃｏｎｆｉｇｕｒａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎが変更されるたびに、ＮＡＳ階層に直ちにＡＣＢｓｋｉｐｉｎｆｏｒｍａｔｉｏｎを提供することもできる。

<提案１２：標準改善>

図３２ａ及び図３２ｂは、本明細書の提案１２を示す信号流れ図である。

図３２ａ及び図３２ｂを参照すると、ＭＭＴＥＬのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声サービス連結を開始する時、他のＭＭＴＥＬ音声サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ音声のためのセッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＭＭＴＥＬのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ映像サービス連結を開始する時、他のＭＭＴＥＬ音声サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層は、ＭＭＴＥＬ映像セッション/呼び(ｃａｌｌ)の開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳｏｖｅｒＩＰサービス連結を開始する時、ＳＭＳｏｖｅｒＩＰサービスセッションが進行していないかを確認した後、もし、ない場合、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層は、ＳＭＳｏｖｅｒＩＰセッションの開始を知らせるＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＳＭＳｏｖｅｒＩＰをＮＡＳ階層に提供する。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)に対するＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎ(例えば、ＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ、ＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＭＭＴＥＬ映像またはＡＣＢｓｋｉｐｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＳＭＳｏｖｅｒＩＰ)を提供すると、ＮＡＳ階層は、前記セッション/呼び(ｃａｌｌ)が一般データセッション/呼び(ｃａｌｌ)でないＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)開始であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰのためのセッション連結のためにサービス要求手順を開始する。このとき、サービス要求メッセージの呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＯＭＭＴＥＬｖｉｄｅｏまたはｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳｏｖｅｒＩＰに設定し、ＲＲＣ確立原因は、ＭＯｄａｔａに設定する。

図３３ａ及び図３３ｂは、本明細書の提案１２の変形例を示す信号流れ図である。

図３３ａ及び図３３ｂを参照すると、サービス要求手順のために拡張サービス要求メッセージが使われる場合、拡張サービス要求メッセージのサービスタイプは、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＭＴＥＬｖｏｉｃｅ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＭＴＥＬｖｉｄｅｏ/ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳｏｖｅｒＩＰｆｏｒＳＭＳｏｖｅｒＩＰに設定され、ＲＲＣ確立原因は、ＭＯｄａｔａに設定される。また、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＯＭＭＴＥＬｖｉｄｅｏまたはｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳｏｖｅｒＩＰに設定される。

図３４ａ及び図３４ｂは、本明細書の提案１２の内容のうち、ＳＭＳに対する例を示す信号流れ図である。

図３４ａ及び図３４ｂを参照すると、ＳＭＳ(ＳＭＳｉｎＭＭＥ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｏｖｅｒＳ１０２)の場合、ＮＡＳ階層は、ＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＳＭＳ連結のためのＳｅｒｖｉｃｅＲｅｑｕｅｓｔ開始時、ＳＥＲＶＩＣＥＲＥＱＵＥＳＴメッセージのｃａｌｌｔｙｐｅは、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｉｎＭＭＥ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｏｖｅｒＳ１０２)に設定され、ＲＲＣ確立原因は、ＭＯｄａｔａに設定される。または、サービス要求手順で拡張サービス要求メッセージが使われる場合、前記拡張サービス要求メッセージのサービスタイプは、ｍｏｂｉｌｅｏｒｉｇｉｎａｔｉｎｇＳＭＳ(ＲＲＣｅｓｔａｂｌｉｓｈｍｅｎｔｃａｕｓｅは、ＭＯｄａｔａに設定され、呼びタイプ(ｃａｌｌｔｙｐｅ)は、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｉｎＭＭＥ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｏｖｅｒＳ１０２)に設定される。

再び、図３２ａ及び図３２ｂを参照すると、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳのサービス要求に対する呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、前記サービス要求がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声/ＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰ、ＭＯＳＭＳサービス連結のためのサービス要求であることを認知し、ネットワークから提供を受けたＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰまたはＳＭＳ(ＳＭＳｏｖｅｒＳＧｓ)サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、前記サービス要求に対するＡＣＢ(ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ)チェックを通過(ｓｋｉｐ)させるようになる。そして、ＲＲＣ接続要求メッセージの確立原因は、ＭＯ−ｄａｔａに設定される。

または、ＵＥのＡＳ階層(例えば、ＲＲＣ階層)は、ＮＡＳのサービス要求手順(サービス要求メッセージの送信または拡張サービス要求メッセージの送信)に対する呼びタイプ(ｃａｌｌｔｙｐｅ)を判読し、前記サービス要求手順がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰ、ＭＯＳＭＳサービス連結のためのものであることを認知し、ネットワークから提供を受けたＭＭＴＥＬ音声/ＭＭＴＥＬ映像/ＳＭＳｏｖｅｒＩＰまたはＳＭＳ(ＳＭＳｉｎＭＭＥ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｏｖｅｒＳ１０２)サービスに対するＡＣＢスキップ情報を確認し、もし、ＡＣＢｓｋｉｐｐｉｎｇｂｉｔ＝ｓｅｔ/ｔｒｕｅの場合、前記サービス要求メッセージに対するＡＣＢ検査を通過(ｓｋｉｐ)させるようになる。このとき、ＲＲＣ接続要求メッセージの確立原因は、ＭＯ−ｄａｔａに設定される。

一方、ＮＡＳ階層は、このような呼びタイプ(ｃａｌｌｔｙｐｅ)(例えば、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｏｉｃｅｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ、ｏｒｉｇｉｎａｔｉｎｇＭＭＴＥＬｖｉｄｅｏｆｏｒＭＯＭＭＴＥＬｖｉｄｅｏまたはｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳｏｖｅｒＩＰ、ｏｒｉｇｉｎａｔｉｎｇＳＭＳｆｏｒＭＯＳＭＳ(ＳＭＳｉｎＭＭＥ、ＳＭＳｏｖｅｒＳＧｓ、ＳＭＳｏｖｅｒＳ１０２)をＮＡＳ復旧のためのＴＡＵ要求手順を開始(実行)する時も提供することができる。

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯ(ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ)ＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像、ＭＯＳＭＳｏｖｅｒＩＰサービス連結が終われると/終了すると、他のＭＭＴＥＬ音声、ＭＭＴＥＬ映像サービスセッションが進行していないかを確認した後、もし、ない場合、ＭＭＴＥＬのためのＩＭＳ階層がＭＭＴＥＬ音声、ＭＭＴＥＬ映像セッション/呼び(ｃａｌｌ)の終了を知らせるＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ、ＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＭＴＥＬｖｉｄｅｏをＮＡＳ階層に提供する。同様に、ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層で他のＳＭＳｏｖｅｒＩＰサービスセッションが進行していないかを確認した後、もし、ない場合、ＳＭＳｏｖｅｒＩＰセッションの終了を知らせるＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＳＭＳｏｖｅｒＩＰをＮＡＳ階層に提供する。(本発明提案１２−３/１２−４案動作内容)

ＭＭＴＥＬ/ＳＭＳｏｖｅｒＩＰのためのＩＭＳ階層がＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)ＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎ(例えば、ＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＭＭＴＥＬｖｏｉｃｅ、ＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＭＴＥＬｖｉｄｅｏまたはＡＣＢｓｋｉｐｒｅｓｅｔｉｎｄｉｃａｔｉｏｎｆｏｒＭＯＳＭＳｏｖｅｒＩＰ)を提供すると、ＮＡＳ階層は、ＭＯＭＭＴＥＬ音声、ＭＯＭＭＴＥＬ映像またはＭＯＳＭＳｏｖｅｒＩＰのためのセッション/呼び(ｃａｌｌ)終了であることを認知するようになる。以後、ＮＡＳ階層は、ＭＭＴＥＬ音声、ＭＭＴＥＬ映像またはＳＭＳｏｖｅｒＩＰセッションに対するＡＣＢチェック時に通過(ｓｋｉｐ)させない。

一方、上記で説明した提案は、組み合わさることができる。

以上、説明した内容は、ハードウェアで具現されることができる。それに対して図１２及び図１２ｂを参照して説明する。

図３５は、本発明の実施例に係るＵＥ１００及び基地局２００の構成ブロック図である。

図３５に示すように、前記ＵＥ１００は、格納手段１０１、コントローラ１０２、及び送受信部１０３を含む。そして、前記基地局２００は、格納手段２０１、コントローラ２０２、及び送受信部２０３を含む。

前記格納手段１０１、２０１は、前述した方法を格納する。

前記コントローラ１０２、２０２は、前記格納手段１０１、２０１及び前記送受信部１０３、２０３を制御する。具体的に、前記コントローラ１０２、２０２は、前記格納手段１０１、２０１に格納された前記方法を各々実行する。そして、前記コントローラ１０２、２０２は、前記送受信部１０３、２０３を介して前記前述した信号を送信する。

以上、本発明の好ましい実施例を例示的に説明したが、本発明の範囲は、このような特定実施例にのみ限定されるものではないため、本発明は、本発明の思想及び特許請求の範囲に記載された範ちゅう内で多様な形態に修正、変更または改善されることができる。

Claims

サービス要求手順を実行する方法であって、前記方法は、ユーザ装置（ＵＥ）により実行され、前記方法は、
前記ＵＥのＡＳ（ＡｃｃｅｓｓＳｔｒａｔｕｍ）により、ＡＣＢ（ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ）に対するスキップ情報を受信することと、
前記ＵＥのＮＡＳ（Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ）階層により、前記ＵＥの上位階層から、ＭＭＴＥＬ（ｍｕｌｔｉｍｅｄｉａｔｅｌｅｐｈｏｎｙ）サービスまたは短文メッセージサービス（ＳＭＳ）が開始されることを指示する開始インジケーションを受信することと、
前記サービス要求手順のためのＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）確立と関連した呼びタイプを、前記ＮＡＳ階層により、設定し、前記ＡＳ階層に伝達することと、
前記ＡＣＢに対する前記スキップ情報が前記ＭＭＴＥＬサービスまたは前記ＳＭＳに対するスキップを指示する場合に、前記ＡＳ階層により、前記呼びタイプに基づいて、前記ＲＲＣ確立を実行することと、
を含む、方法。
前記ＭＭＴＥＬサービスは、
ＭＭＴＥＬ音声及びＭＭＴＥＬ映像のうちの少なくとも１つのためのものである、請求項１に記載の方法。
前記スキップ情報は、
前記ＭＭＴＥＬ音声のための前記ＡＣＢをスキップすべきかどうかに対する情報と、前記ＭＭＴＥＬ映像のための前記ＡＣＢをスキップすべきかどうかに対する情報と、前記ＳＭＳのための前記ＡＣＢをスキップすべきかどうかに対する情報とを含む、請求項２に記載の方法。
前記サービス要求手順は、
サービス要求メッセージまたは拡張サービス要求を送信することを含む、請求項１に記載の方法。
前記呼びタイプは、発信ＭＭＴＥＬ音声、発信ＭＭＴＥＬ映像、及び、発信ＳＭＳｏｖｅｒＩＰのうちの少なくとも１つに設定される、請求項１に記載の方法。
前記呼びタイプが前記発信ＭＭＴＥＬ音声に設定される場合に、確立原因フィールドが、ＭＯ（ＭｏｂｉｌｅＯｒｉｅｎｔｉｎｇ）ｄａｔａを示すように設定される、請求項５に記載の方法。
前記呼びタイプが前記発信ＭＭＴＥＬ映像に設定される場合に、確立原因フィールドが、ＭＯ（ＭｏｂｉｌｅＯｒｉｅｎｔｉｎｇ）ｄａｔａを示すように設定される、請求項５に記載の方法。
前記呼びタイプが前記発信ＳＭＳｏｖｅｒＩＰに設定される場合に、確立原因フィールドが、ＭＯ（ＭｏｂｉｌｅＯｒｉｅｎｔｉｎｇ）ｄａｔａに設定される、請求項５に記載の方法。
サービス要求手順を実行するユーザ装置（ＵＥ）であって、前記ＵＥは、
送受信部と、
前記送受信部を制御し、ＡＳ（ＡｃｃｅｓｓＳｔｒａｔｕｍ）及びＮＡＳ（Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ）階層を動作させるように構成されるプロセッサと
を含み、
前記ＡＳ階層は、ＡＣＢ（ＡｃｃｅｓｓＣｌａｓｓＢａｒｒｉｎｇ）に対するスキップ情報を受信するように構成され、
前記ＮＡＳ階層は、ＭＭＴＥＬ（ｍｕｌｔｉｍｅｄｉａｔｅｌｅｐｈｏｎｙ）サービスまたは短文メッセージサービス（ＳＭＳ）が開始されることを指示する開始インジケーションを上位階層から受信するように構成され、
前記ＮＡＳ階層は、前記サービス要求手順のためのＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）確立と関連した呼びタイプを、設定し、前記ＡＳ階層に伝達するように構成され、
前記ＡＳ階層は、前記ＡＣＢに対する前記スキップ情報が前記ＭＭＴＥＬサービスまたは前記ＳＭＳに対するスキップを指示する場合に、前記呼びタイプに基づいて、前記ＲＲＣ確立を実行するように構成される、ＵＥ。
前記ＭＭＴＥＬサービスは、
ＭＭＴＥＬ音声及びＭＭＴＥＬ映像のうちの少なくとも１つのためのものである、請求項９に記載のＵＥ。
前記スキップ情報は、
前記ＭＭＴＥＬ音声のための前記ＡＣＢをスキップすべきかどうかに対する情報と、前記ＭＭＴＥＬ映像のための前記ＡＣＢをスキップすべきかどうかに対する情報と、前記ＳＭＳのための前記ＡＣＢをスキップすべきかどうかに対する情報とを含む、請求項１０に記載のＵＥ。