3GPP TS 24.008 V3.5 - 株式会社QT Packet services in UMTS (UMTS only) UMTS内でのパケットサービス（UMTS のみ）.....29 2 Normative references..... 29 2.1 2.1.1 Random

3GPP TS 24.008 V3.5.0 (2000-09)技術仕様書

3rd Generation Partnership Project;Technical Specification Group Core Network;

Mobile radio interface layer 3 specification;Core Network Protocols - Stage 3

(Release 1999)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification.Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 2

Keywords UMTS, layer 3, network

3GPP

Postal address

3GPP support office address 650 Route des Lucioles - Sophia Antipolis

Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.

© 2000, 3GPP Organizational Partners (ARIB, CWTS, ETSI, T1, TTA,TTC).

All rights reserved.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 3

Contents Foreword.......................................................................................................................................................... 24 Introduction（導入）...................................................................................................................................... 24

1 Scope（本書の範囲） ......................................................................................................................... 25 1.1 Scope of the Technical Specification（技術仕様書の範囲） .............................................................................25 1.2 Application to the interface structures （インタフェース構造への適用）.......................................................25 1.3 Structure of layer 3 procedures （L3手順の構造） ............................................................................................25 1.4 Test procedures（試験手順） ..............................................................................................................................26 1.5 Use of logical channels（論理チャネルの使用） ..............................................................................................26 1.6 Overview of control procedures（制御手順概説） .............................................................................................26 1.6.1 List of procedures（手順のリスト） ...........................................................................................................26 1.7 Applicability of implementations（実装への適用）...........................................................................................28 1.7.1 Voice Group Call Service (VGCS) and Voice Broadcast Service (VBS) （VGCS （Voice Group Call

Service）と VBS(Voice Broadcast Service)）..........................................................................................28 1.7.2 General Packet Radio Service (GPRS) ..........................................................................................................29 1.7.2.1 Packet services in GSM (GSM only) GSM内のパケットサービス（GSMのみ） ....................................29 1.7.2.2 Packet services in UMTS (UMTS only) UMTS内でのパケットサービス（UMTSのみ） ......................29 2 Normative references............................................................................................................................. 29 2.1 Definitions and abbreviations（定義と略語） .....................................................................................................33 2.1.1 Random values（乱数値） ...........................................................................................................................33 2.2.2 Vocabulary（用語） .....................................................................................................................................34

3 Radio Resource management procedures （無線リソース管理手順） ............................................. 36

4 Elementary procedures for Mobility Management （モビリティ管理用の基本的処理） ............... 36 4.1 General（概要）...................................................................................................................................................36 4.1.1 MM and GMM procedures（MMおよび GMM処理） ......................................................................................36 4.1.1.1 Types of MM and GMM procedures（MM処理および GMM処理のタイプ） ........................................36 4.1.1.1.1 Integrity Checking of Signalling Messages in the Mobile Station (UMTS only) （MS内の署名メ

ッセージの完全性確認（UMTSのみ）） .................................................................................38 4.1.1.1.1a Integrity protection for emergency call (UMTS only) （緊急呼の完全性保護（UMTSのみ）） .......39 4.1.1.2 MM-GMM co-ordination for GPRS MS's （GPRS MS 用のMM～GMM間のコーディネーショ

ン） ......................................................................................................................................................39 4.1.1.2.1 GPRS MS operating in mode A or B in a network that operates in mode I （ネットワークオペレ

ーションモード Iのネットワーク内の、MSオペレーションモード A / Bの GPRS MS） ...............................................................................................................................................39

4.1.1.2.2 GPRS MS operating in mode A or B in a network that operates in mode II or III （ネットワークオペレーションモード II ／ IIIのネットワーク内の、MSオペレーションモード A／ Bの GPRS MS） ...............................................................................................................................40

4.1.1.3 Core Network System Information for MM (UMTS only) （MM用の Core Network System Information（UMTSのみ））............................................................................................................40

4.1.1.4 Core Network System Information for GMM (UMTS only) （GMM用の Core Network System Information（UMTSのみ））............................................................................................................40

4.1.2 MM sublayer states（MMサブレイヤのステート）.................................................................................41 4.1.2.1 MM sublayer states in the mobile station （MS内のMMサブレイヤステート）.....................................41 4.1.2.1.1 Main states（メインステート） ..............................................................................................................41 4.1.2.1.2 Substates of the MM IDLE state（MM IDLEステートのサブステート） ...........................................44 4.1.2.2 The update Status（更新ステータス） .........................................................................................................45 4.1.2.3 MM sublayer states on the network side （ネットワーク側のMMサブレイヤのステート） .................46 4.1.3 GPRS mobility management (GMM) sublayer states （GMMサブレイヤのステート）.........................47 4.1.3.1 GMM states in the MS（MS内の GMMステート） ...................................................................................47 4.1.3.1.1 Main states（メインステート） ..............................................................................................................48

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 4

4.1.3.1.3 Substates of state GMM-REGISTERED....................................................................................................49 4.1.3.2 GPRS update status（GPRS更新ステータス）............................................................................................51 4.1.3.3 GMM mobility management states on the network side （GMMステータス、ネットワーク側）...........51 4.1.3.3.1 Main States（メインステート） .............................................................................................................52 4.1.3.3.2 Substates of state GMM-REGISTERED....................................................................................................52 4.2 Behaviour of the MS in MM Idle state, GMM-DEREGISTERED state and GMM-REGISTERED state

（MM Idleステート、DEREGISTEREDステート、GMM-REGISTEREDステートにおけるMSの動作）..........................................................................................................................................................53

4.2.1 Primary Service State selection （プライマリサービスステートの選択） .............................................53 4.2.1.1 Selection of the Service State after Power On. （電源投入後のサービスステートの選択） ....................53 4.2.1.2 Other Cases（その他のケース）...................................................................................................................54 4.2.2 Detailed Description of the MS behaviour in MM IDLE State. （MM IDLEステートにおけるMS

の動作の詳細な説明） ............................................................................................................................54 4.2.2.1 Service State, NORMAL SERVICE （サービスステート、NORMAL SERVICE）.................................54 4.2.2.2 Service State, ATTEMPTING TO UPDATE （サービスステート、ATTEMPTING TO UPDATE）......55 4.2.2.3 Service State, LIMITED SERVICE（サービスステート LIMITED SERVICE） ......................................55 4.2.2.4 Service State, NO IMSI（サービスステート, NO IMSI） ...........................................................................56 4.2.2.5 Service State, SEARCH FOR PLMN, NORMAL SERVICE （サービスステート、SEARCH FOR

PLMN, NORMAL SERVICE）...........................................................................................................56 4.2.2.6 Service State, SEARCH FOR PLMN （サービスステート, SEARCH FOR PLMN） ...............................57 4.2.2.7 Service State, RECEIVING GROUP CALL (NORMAL SERVICE) （サービスステート、

RECEIVING GROUP CALL (NORMAL SERVICE)）.....................................................................57 4.2.2.8 Service State, RECEIVING GROUP CALL (LIMITED SERVICE) （サービスステート,

RECEIVING GROUP CALL (LIMITED SERVICE)）......................................................................57 4.2.3 Service state when back to state MM IDLE from another state （他のステートからステートMM

IDLEに戻った場合のサービスステート）...........................................................................................58 4.2.4 Behaviour in state GMM-DEREGISTERED （ステート GMM-DEREGISTEREDにおける動作）......59 4.2.4.1 Primary substate selection（プライマリサブステートの選択） ................................................................59 4.2.4.1.1 Selection of the substate after power on or enabling the MS's GPRS capability （MS電源投入後ま

たはMSの GPRSケーパビリティを有効にした後のサブステートの選択） ......................59 4.2.4.1.2 Other Cases（その他のケース） .............................................................................................................60 4.2.4.2 Detailed description of the MS behaviour in state GMM-DEREGISTERED （ステート GMM-

DEREGISTEREDにおけるMSの動作の詳細な説明） .................................................................60 4.2.4.2.1 Substate, NORMAL-SERVICE（サブステート、NORMAL-SERVICE）...........................................60 4.2.4.2.2 Substate, ATTEMPTING-TO-ATTACH （サブステート、ATTEMPTING-TO-ATTACH） .............60 4.2.4.2.3 Substate, LIMITED-SERVICE（サブステート, LIMITED-SERVICE） ..............................................60 4.2.4.2.4 Substate, NO-IMSI（サブステート, NO-IMSI） ....................................................................................61 4.2.4.2.5 Substate, NO-CELL（サブステート, NO-CELL） .................................................................................61 4.2.4.2.6 Substate, PLMN-SEARCH（サブステート, PLMN-SEARCH） ...........................................................61 4.2.4.2.7 Substate, ATTACH-NEEDED（サブステート, ATTACH-NEEDED） ................................................61 4.2.4.2.8 Substate, SUSPENDED (GSM only) （サブステート, SUSPENDED (GSMのみ)）...........................61 4.2.4.3 Substate when back to state GMM-DEREGISTERED from another GMM state （他の GMMステー

トからステート GMM-DEREGISTEREDに戻った場合のサブステート） ................................61 4.2.5 Behaviour in state GMM-REGISTERED （ステート GMM-REGISTEREDにおける動作） ................62 4.2.5.1 Detailed description of the MS behaviour in state GMM-REGISTERED （ステート GMM-

REGISTEREDにおけるMSの動作の詳細な説明） ......................................................................62 4.2.5.1.1 Substate, NORMAL-SERVICE（サブステート, NORMAL-SERVICE）.............................................62 4.2.5.1.2 Substate, SUSPENDED (GSM only) （サブステート, SUSPENDED (GSM のみ)） ..........................62 4.2.5.1.3 Substate, UPDATE-NEEDED（サブステート, UPDATE-NEEDED） .................................................62 4.2.5.1.4 Substate, ATTEMPTING-TO-UPDATE （サブステート, ATTEMPTING-TO-UPDATE） ................63 4.2.5.1.5 Substate, NO-CELL-AVAILABLE（サブステート, NO-CELL-AVAILABLE） .................................63 4.2.5.1.6 Substate, LIMITED-SERVICE（サブステート, LIMITED-SERVICE） ..............................................63 4.2.5.1.7 Substate, ATTEMPTING-TO-UPDATE-MM （サブステート, ATTEMPTING-TO-UPDATE-

MM）..............................................................................................................................................63 4.3 MM common procedures（MM共通の処理） ...................................................................................................64

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 5

4.3.1 TMSI reallocation procedure（TMSI再配置処理） ...................................................................................64 4.3.1.1 TMSI reallocation initiation by the network （ネットワークによる TMSI再配置の開始） ....................64 4.3.1.2 TMSI reallocation completion by the mobile station （MSによる TMSI再配置の完了）.........................64 4.3.1.3 TMSI reallocation completion in the network （ネットワークにおける TMSI再配置の完了） ..............65 4.3.1.4 Abnormal cases（異常なケース） ................................................................................................................65 4.3.2 Authentication procedure（認証処理） .......................................................................................................66 4.3.2a Authentication procedure used for a UMTS authentication challenge （UMTS認証チャレンジに使用

される認証処理）...............................................................................................................................66 4.3.2b Authentication Procedure used for a GSM authentication challenge （GSM認証チャレンジに使用

される認証処理） ....................................................................................................................................66 4.3.2.1 Authentication request by the network（ネットワークからの認証要求） .................................................66 4.3.2.2 Authentication response by the mobile station （MSからの認証応答） .....................................................67 4.3.2.3 Authentication processing in the network（ネットワークにおける認証処理）.........................................67 4.3.2.4 Ciphering key sequence number（暗号鍵シーケンス番号）.......................................................................67 4.3.2.5 Authentication not accepted by the network （ネットワークが認証を受理しなかった場合） ................68 4.3.2.5.1 Authentication not accepted by the MS （認証がMSによって拒否された場合） ..............................68 4.3.2.6 Abnormal cases（異常なケース） ................................................................................................................69 4.3.2.6.1 MS behaviour towards a network that has failed the authentication procedure （認証処理に失敗した

ネットワークに対するMSの動作）..........................................................................................71 4.3.2.7 Handling of keys at intersystem change from UMTS to GSM （UMTS→GSMへのシステム間変更

時の鍵の扱い）...................................................................................................................................71 4.3.2.7a Use of established security contexts （確立されたセキュリティコンテキストの使用） ........................71 4.3.2.8 Handling of keys at intersystem change from GSM to UMTS （GSM →UMTSへのシステム間変更

時の鍵の扱い）...................................................................................................................................72 4.3.2.9 Void 72 4.3.3 Identification procedure（通知処理）..........................................................................................................72 4.3.3.1 Identity request by the network（ネットワークによる識別要求） ............................................................73 4.3.3.2 Identification response by the mobile station（MSによる識別応答）.........................................................73 4.3.3.3 Abnormal cases（異常なケース） ................................................................................................................73 4.3.4 IMSI detach procedure（IMSIデタッチ処理） ..........................................................................................73 4.3.4.1 IMSI detach initiation by the mobile station （MSによる IMSI デタッチの開始）...................................74 4.3.4.2 IMSI detach procedure in the network （ネットワーク内の IMSIデタッチ処理） .................................74 4.3.4.3 IMSI detach completion by the mobile station （MSによる IMSIデタッチの完了） ...............................74 4.3.4.4 Abnormal cases（異常なケース） ................................................................................................................74 4.3.5 Abort procedure（中断処理）......................................................................................................................74 4.3.5.1 Abort procedure initiation by the network （ネットワークによる中断処理の開始） ...............................75 4.3.5.2 Abort procedure in the mobile station（MSにおける中断処理）................................................................75 4.3.6 MM information procedure（MM情報処理） ............................................................................................75 4.3.6.1 MM information procedure initiation by the network （ネットワークによるMM情報処理の開始）.....75 4.3.6.2 MM information procedure in the mobile station （MS内のMM情報処理） ..........................................75 4.4 MM specific procedures（MM固有の処理）.....................................................................................................75 4.4.1 Location updating procedure（位置登録更新処理） ...........................................................................................76 4.4.2 Periodic updating（定期的更新）................................................................................................................77 4.4.3 IMSI attach procedure（IMSIアタッチ処理） ...........................................................................................78 4.4.4 Generic Location Updating procedure （一般的な位置登録更新処理）...................................................78 4.4.4.1 Location updating initiation by the mobile station （MSによる位置登録更新の開始）............................78 4.4.4.1a Network Request for Additional mobile station Capability Information （追加MSケーパビリティ情

報用のネットワーク要求）...............................................................................................................78 4.4.4.2 Identification request from the network（ネットワークからの識別要求）................................................78 4.4.4.3 Authentication by the network（ネットワークによる認証）......................................................................78 4.4.4.4 Security mode setting by the network （ネットワークによるセキュリティモードの設定） ..................79 4.4.4.5 Attempt Counter（試行カウンタ） ...............................................................................................................79 4.4.4.6 Location updating accepted by the network （ネットワークによる位置登録更新試行） ........................79 4.4.4.7 Location updating not accepted by the network （ネットワークが位置登録更新を受理しなかった

場合） ..................................................................................................................................................80

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 6

4.4.4.8 Release of RR connection after location updating （位置登録更新後の RRコネクション開放）............81 4.4.4.9 Abnormal cases on the mobile station side（異常なケース、MS側） ........................................................81 4.4.4.10 Abnormal cases on the network side（異常なケース、ネットワーク側） ...........................................82 4.4.5 Void................................................................................................................................................................83 4.4.6 Void................................................................................................................................................................83 4.5 Connection management sublayer service provision （CMサブレイヤのサービス提供） ............................83 4.5.1 MM connection establishment（MMコネクションの確立）....................................................................83 4.5.1.1 MM connection establishment initiated by the mobile station （MSが開始するMMコネクションの

確立） ..................................................................................................................................................83 4.5.1.2 Abnormal cases（異常なケース） ................................................................................................................86 4.5.1.3 MM connection establishment initiated by the network （ネットワークによるMMコネクション確

立の開始） ..........................................................................................................................................87 4.5.1.3.1 Mobile Terminating CM Activity （モバイル着信 CM Activity） .........................................................87 4.5.1.3.2 Mobile Originating CM Activity $(CCBS)$ （モバイル発 CM Activity $(CCBS)$）...........................88 4.5.1.3.3 Paging response in UMTS (UMTS only) （UMTS内のページング応答（UMTSのみ）） ...............89 4.5.1.4 Abnormal cases（異常なケース） ................................................................................................................89 4.5.1.5 MM connection establishment for emergency calls （緊急呼用のMMコネクション確立）....................89 4.5.1.6 Call re-establishment（呼の再確立） ............................................................................................................90 4.5.1.6.1 Call re-establishment, initiation by the mobile station （呼再確立、MSが開始） ................................90 4.5.1.6.2 Abnormal cases（異常なケース）...........................................................................................................92 4.5.1.7 Forced release during MO MM connection establishment （MO MMコネクション確立中の強制開

放） ......................................................................................................................................................93 4.5.2 MM connection information transfer phase （MMコネクション情報の送信フェーズ） .......................93 4.5.2.1 Sending CM messages（CMメッセージの送信）.......................................................................................93 4.5.2.2 Receiving CM messages（CMメッセージの受信）....................................................................................93 4.5.2.3 Abnormal cases（異常なケース） ................................................................................................................94 4.5.3 MM connection release（MMコネクションの開放）...............................................................................94 4.5.3.1 Release of associated RR connection（関連する RRコネクションの開放） ............................................94 4.5.3.2 Uplink release in a voice group call（音声グループ呼の上りリンクの開放）..........................................94 4.6 Receiving a MM STATUS message by a MM entity （MMエンティティによるMM STATUSメッセ

ージの受信）..................................................................................................................................................94 4.7 Elementary mobility management procedures for GPRS Service （GPRSサービス用の基本的モビリテ

ィ管理処理）..................................................................................................................................................95 4.7.1 General（概要） ...........................................................................................................................................95 4.7.1.1 Lower layer failure（下位レイヤの失敗） ...................................................................................................95 4.7.1.2 Ciphering of messages (GSM only)（メッセージの暗号化（GSMのみ）） ............................................95 4.7.1.3 P-TMSI signature（P-TMSI署名） ...............................................................................................................95 4.7.1.4 Radio resource sublayer address handling （無線リソースサブレイヤのアドレス処理） .......................95 4.7.1.4.1 Radio resource sublayer address handling (GSM only) （無線リソースサブレイヤのアドレス処

理（GSMのみ）） .......................................................................................................................96 4.7.1.5 P-TMSI handling（P-TMSI処理） ................................................................................................................96 4.7.1.5.1 PTMSI handling in GSM（GSMにおける P-TMSI処理）....................................................................96 4.7.1.5.2 PTMSI handling in UMTS（UMTS内の PTMSI処理） ........................................................................97 4.7.1.6 Change of network mode of operation （ネットワークオペレーションモードの変更）.........................97 4.7.1.6.1 Change of network mode of operation in GSM (GSM only) （GMS内でのネットワークオペレ

ーションモードの変更（GSMのみ））....................................................................................97 4.7.1.6.2 Change of network mode of operation in UMTS (UMTS only) （UMTSにおけるネットワーク

オペレーションモードの変更（UMTSのみ）） .....................................................................98 4.7.1.6.3 Change of network mode of operation at UMTS to GSM inter-system change （UMTS→GSMへの

システム間変更時のネットワークオペレーションモードの変更）......................................98 4.7.1.6.4 Change of network mode of operation at GSM to UMTS inter-system change （GSM→UMTSシス

テム間変更時のネットワークオペレーションモード変更） .................................................99 4.7.1.7 Intersystem change between GSM and UMTS （GSMと UMTS間のシステム間変更） .......................100 4.7.2 GPRS Mobility management timers and UMTS PS signalling connection control （GPRSのMMタ

イマと UMTSシグナリングコネクション制御）..............................................................................101

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 7

4.7.2.1 READY timer behaviour（READYタイマの動作） .................................................................................101 4.7.2.1.1 READY timer behaviour (GSM only)（READYタイマの動作（GPRSのみ）） .............................101 4.7.2.1.2 Handling of READY timer in UMTS (UMTS only) （UMTS内での READYタイマの処理

（UMTSのみ）） .......................................................................................................................102 4.7.2.2 Periodic routing area updating（定期的 RA更新） ....................................................................................103 4.7.2.3 PMM-IDLE mode and PMM-CONNECTED mode (UMTS only) （PMM-IDLEモードと PMM-

CONNECTEDモード（UMTSのみ）） ........................................................................................104 4.7.2.4 Handling of Force to standby in UMTS (UMTS only) （UMTS内の Force to standby（強制スタン

バイ）の処理（UMTSのみ）） ....................................................................................................104 4.7.3 GPRS attach procedure（GPRSアタッチ処理） ......................................................................................104 4.7.3.1 GPRS attach procedure for GPRSサービス（GPRSサービス用の GPRSアタッチ処理） ..................105 4.7.3.1.1 GPRS attach procedure initiation（GPRSアタッチ処理初期化） .......................................................105 4.7.3.1.2 GMM common procedure initiation（GMM共通処理の初期化）.......................................................105 4.7.3.1.3 GPRS attach accepted by the network （ネットワークによる GPRSアタッチの受理）..................105 4.7.3.1.4 GPRS attach not accepted by the network （ネットワークが GPRSアタッチを受理しなかった

場合）...........................................................................................................................................106 4.7.3.1.5 Abnormal cases in the MS（異常なケース、MS側）..........................................................................107 4.7.3.1.6 Abnormal cases on the network side （異常なケース、ネットワーク側） ........................................108 4.7.3.2 Combined GPRS attach procedure for GPRS and non-GPRS services （GPRS サービスと非 GPRSサ

ービスの複合 GPRSアタッチ処理） .............................................................................................110 4.7.3.2.1 Combined GPRS attach procedure initiation （複合 GPRSアタッチ処理の開始）............................110 4.7.3.2.2 GMM Common procedure initiation （GMM共通処理の開始）.........................................................111 4.7.3.2.3 Combined GPRS attach accepted by the network （ネットワークによる複合 GPRSアタッチの

受理）...........................................................................................................................................111 4.7.3.2.4 Combined GPRS attach not accepted by the network （ネットワークが複合 GPRSアタッチを受

理しなかった場合） ...................................................................................................................112 4.7.3.2.5 Abnormal cases in the MS（異常なケース、MS側）..........................................................................113 4.7.3.2.6 Abnormal cases on the network side（異常なケース、ネットワーク側） .........................................113 4.7.4 GPRS detouch procedure（GPRSデタッチ処理）...................................................................................113 4.7.4.1 MS initiated GPRS detach procedure （MSによる GPRSデタッチ処理の開始） ..................................114 4.7.4.1.1 MS initiated GPRS detach procedure initiation （MSによる GPRSデタッチ処理の開始） .............114 4.7.4.1.2 MS initiated GPRS detach procedure completion for GPRS services only （MSが開始した GPRS

デタッチ処理の完了、GPRSサービス用のみ）.....................................................................114 4.7.4.1.3 MS initiated combined GPRS detach procedure completion （MS開始型複合 GPRSデタッチ処

理の完了） ...................................................................................................................................115 4.7.4.1.4 Abnormal cases in the MS（異常なケース、MS側）..........................................................................115 4.7.4.2 Network initiated GPRS detach procedure （ネットワークが開始した GPRSデタッチ処理） ............116 4.7.4.2.1 Network initiated GPRS detach procedure initiation （ネットワークが開始した GPRSデタッチ

処理）...........................................................................................................................................116 4.7.4.2.2 Network initiated GPRS detach procedure completion by the MS （ネットワークが開始した

GPRSデタッチ処理をMSが完了） .........................................................................................116 4.7.4.2.3 Network initiated GPRS detouch procedure completion by the network （ネットワークが開始し

た GPRSデタッチ処理をネットワーク側で完了）................................................................118 4.7.4.2.4 Abnormal cases on the network side （異常なケース、ネットワーク側） ........................................118 4.7.5 Routing area updating procedure（RA更新処理） ...................................................................................119 4.7.5.1 Normal and periodic routing area updating procedure （通常および定期的 RA更新処理） ...................120 4.7.5.1.1 Normal and periodic routing area updating procedure initiation （通常 RA更新処理と定期的 RA

更新処理の開始） .......................................................................................................................121 4.7.5.1.2 GMM Common procedure initiation（GMM共通処理の開始）..........................................................121 4.7.5.1.3 Normal and periodic routing area updating procedure accepted by the network （通常 RA更新お

よび定期的 RA更新処理がネットワークによって受理された場合） ................................121 4.7.5.1.4 Normal and periodic routing area updating procedure not accepted by the network （通常 RA更新

処理と定期的 RA更新処理をネットワークが拒否した場合） ............................................122 4.7.5.1.5 Abnormal cases in the MS（異常なケース、MS側）..........................................................................123

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 8

4.7.5.1.6 Abnormal cases on the network side（異常なケース、ネットワーク側） .........................................124 4.7.5.2 Combined routing area updating procedure（複合 RA更新処理） ............................................................125 4.7.5.2.1 Combined routing area updating procedure initiation （複合 RA更新処理の開始） ..........................125 4.7.5.2.2 GMM Common procedure initiation（GMM共通処理の開始）..........................................................126 4.7.5.2.3 Combined routing area updating procedure accepted by the network （複合 RA更新処理がネット

ワークによって受理された場合） ...........................................................................................126 4.7.5.2.4 Combined routing area updating not accepted by the network （複合 RA更新がネットワークに

よって受理されなかった場合） ...............................................................................................128 4.7.5.2.5 Abnormal cases in the MS（異常なケース、MS側）..........................................................................129 4.7.5.2.6 Abnormal cases on the network side（異常なケース、ネットワーク側） .........................................129 4.7.6 P-TMSI reallocation procedure（P-TMSI再配置処理） ..........................................................................129 4.7.6.1 P-TMSI reallocation initiation by the network （ネットワークによる P-TMSI再配置の開始） ...........130 4.7.6.2 P-TMSI reallocation completion by the MS （MSによる P-TMSI再配置の完了） ................................130 4.7.6.3 P-TMSI reallocation completion by the network （ネットワークによる P-TMSI再配置処理の完

了） ....................................................................................................................................................130 4.7.6.4 Abnormal cases on the network side（異常なケース、ネットワーク側） ..............................................130 4.7.7 Authentication and ciphering procedure （認証と暗号化処理）..............................................................131 4.7.7a Authentication and ciphering procedure used for UMTS authentication challenge （UMTS認証チャレ

ンジに使用される認証と暗号化処理） .........................................................................................131 4.7.7b Authentication and ciphering procedure used for GSM authentication challenge （認証と暗号化処理

が GSM認証チャレンジ用に使用される場合） ..........................................................................132 4.7.7.1 Authentication and ciphering initiation by the network （ネットワークが認証と暗号化を開始した

場合） ................................................................................................................................................133 4.7.7.2 Authentication and ciphering response by the MS （MSからの認証と暗号化の応答）..........................133 4.7.7.3 Authentication and ciphering completion by the network （ネットワークによる認証と暗号化の完

了） ....................................................................................................................................................134 4.7.7.4 GPRS ciphering key sequence number （GPRS暗号鍵シーケンス番号） ...............................................134 4.7.7.5 Authentication not accepted by the network （ネットワークが認証を拒否した場合）..........................135 4.7.7.5.1 Authentication not accepted by the MS（MSによる認証拒否）..........................................................136 4.7.7.6 Abnormal cases on the network side（異常なケース、ネットワーク側） ..............................................136 4.7.7.6.1 MS behaviour towards a network that has failed the authentication procedure （認証が失敗したネ

ットワークに対するMSの動作）............................................................................................139 4.7.7.7 Use of established security contexts （確立されたセキュリティコンテキストの使用） ......................139 4.7.7.8 Handling of keys at intersystem change from UMTS to GSM （UMTS→GSMへのシステム間変更

時の鍵の取り扱い）.........................................................................................................................140 4.7.7.9 Handling of keys at intersystem change from GSM to UMTS （GSM→UMTSへのシステム間変更

時の鍵の取り扱い）.........................................................................................................................140 4.7.8 Identification procedure（識別処理） ................................................................................................................140 4.7.8.1 Identification initiation by the network（ネットワークによる識別の開始）...........................................141 4.7.8.2 Identification response by the MS（MSによる識別応答） .......................................................................141 4.7.8.3 Identification completion by the network（ネットワークによる識別の完了） .......................................141 4.7.8.4 Abnormal cases on the network side（異常なケース、ネットワーク側） ..............................................141 4.7.9 Paging procedure（ページング処理） ......................................................................................................142 4.7.9.1 Paging for GPRS services（GPRSサービス用ページング） ....................................................................142 4.7.9.1.1 Paging for GPRS services using P-TMSI （P-TMSIを使用した GPRSサービス用のページン

グ）...............................................................................................................................................142 4.7.9.1.2 Paging for GPRS services using IMSI （IMSIを使用した GPRSサービス用のページング） ........143 4.7.9.2 Paging for non-GPRS services（非 GPRSサービス用ページング）........................................................143 4.7.10 Receiving a GMM STATUS message by a GMM entity （GMMエンティティによる GMM STATUS

メッセージの受信） ..............................................................................................................................143 4.7.11 Void...............................................................................................................................................................144 4.7.12 GMM Information procedure（GMM情報処理） .....................................................................................144 4.7.12.1 GMM information procedure initiation by the network （ネットワークによる GMM情報処理の

開始） ................................................................................................................................................144 4.7.12.2 GMM information procedure in the mobile station （MS内での GMM情報処理） ...........................144

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 9

4.7.13 Service Request procedure (UMTS only) （サービスリクエスト処理（UMTSのみ）） .....................144 4.7.13.1 Service Request procedure initiation（サービスリクエスト処理の開始）.........................................145 4.7.13.2 GMM common procedure initiation（ GMM共通の処理の開始）......................................................145 4.7.13.3 Service request procedure accepted by the network （サービスリクエストがネットワークに

受理された場合）.............................................................................................................................145 4.7.13.4 Service request procedure not accepted by the network （サービスリクエストがネットワーク

に拒否された場合）.........................................................................................................................145 4.7.13.5 Abnormal cases in the MS（異常なケース、MS側）..........................................................................146 4.7.13.6 Abnormal cases on the network side（異常なケース（ネットワーク側）） .....................................147 4.7.14 Void...............................................................................................................................................................148 5 Elementary procedures for circuit-switched Call Control （CS呼制御用の基本的な処理）......... 148 5.1 Overview（概要）..............................................................................................................................................148 5.1.1 General（概説） .........................................................................................................................................148 5.1.2 Call Control States（呼制御ステート）...................................................................................................153 5.1.2.1 Call states at the mobile station side of the interface （インタフェースのMS側におけるコールス

テート） ............................................................................................................................................153 5.1.2.1.1 Null (State U0) .........................................................................................................................................153 5.1.2.1.2 MM Connection pending (U0.1) ..............................................................................................................154 5.1.2.1.2a CC prompt present (U0.2) $(CCBS)$.......................................................................................................154 5.1.2.1.2b Wait for network information (U0.3) $(CCBS)$......................................................................................154 5.1.2.1.2c CC-Establishment present (U0.4) $(CCBS)$ ...........................................................................................154 5.1.2.1.2d CC-Establishment confirmed (U0.5) $(CCBS)$ ......................................................................................154 5.1.2.1.2e Recall present (U0.6) $(CCBS)$ ..............................................................................................................154 5.1.2.1.3 Call initiated (U1).....................................................................................................................................154 5.1.2.1.4 Mobile originating call proceeding (U3) ..................................................................................................154 5.1.2.1.5 Call delivered (U4) ...................................................................................................................................154 5.1.2.1.6 Call present (U6) ......................................................................................................................................154 5.1.2.1.7 Call received (U7) ....................................................................................................................................154 5.1.2.1.8 Connect Request (U8) ..............................................................................................................................154 5.1.2.1.9 Mobile terminating call confirmed (U9)...................................................................................................155 5.1.2.1.10 Active (U10) .............................................................................................................................................155 5.1.2.1.11 Disconnect request (U11) .........................................................................................................................155 5.1.2.1.12 Disconnect indication (U12).....................................................................................................................155 5.1.2.1.13 Release request (U19)...............................................................................................................................155 5.1.2.1.14 Mobile originating modify (U26) .............................................................................................................155 5.1.2.1.15 Mobile terminating modify (U27) ............................................................................................................155 5.1.2.2 Network call states（ネットワークのコールステート）..........................................................................155 5.1.2.2.1 Null (State N0) .........................................................................................................................................155 5.1.2.2.2 MM connection pending (N0.1) ...............................................................................................................155 5.1.2.2.2a CC connection pending (N0.2) $(CCBS)$ ...............................................................................................155 5.1.2.2.2b Network answer pending (N0.3) $(CCBS)$.............................................................................................155 5.1.2.2.2c CC-Establishment present (N0.4) $(CCBS)$ ...........................................................................................156 5.1.2.2.2d CC-Establishment confirmed (N0.5) $(CCBS)$ ......................................................................................156 5.1.2.2.2e Recall present (N0.6) $(CCBS)$ ............................................................................................................156 5.1.2.2.3 Call initiated (N1).....................................................................................................................................156 5.1.2.2.4 Mobile originating call proceeding (N3) ..................................................................................................156 5.1.2.2.5 Call delivered (N4) ...................................................................................................................................156 5.1.2.2.6 Call present (N6) ......................................................................................................................................156 5.1.2.2.7 Call received (N7) ....................................................................................................................................156 5.1.2.2.8 Connect request (N8)................................................................................................................................156 5.1.2.2.9 Mobile terminating call confirmed (N9)...................................................................................................156 5.1.2.2.10 Active (N10) .............................................................................................................................................156 5.1.2.2.11 Not used....................................................................................................................................................157 5.1.2.2.12 Disconnect indication (N12).....................................................................................................................157 5.1.2.2.13 Release request (N19)...............................................................................................................................157 5.1.2.2.14 Mobile originating modify (N26) .............................................................................................................157 5.1.2.2.15 Mobile terminating modify (N27) ............................................................................................................157 5.1.2.2.16 Connect Indication (N28) .........................................................................................................................157 5.2 Call establishment procedures（呼確立手順）..................................................................................................157

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 10

5.2.1 Mobile originating call establishment（MS発信呼の確立） ....................................................................158 5.2.1.1 Call initiation （呼の開始）.........................................................................................................................158 5.2.1.2 Receipt of a setup message（セットアップメッセージの受信） .............................................................159 5.2.1.3 Receipt of a CALL PROCEEDING message （CALL PROCEEDINGメッセージの受信） ..................160 5.2.1.4 Notification of progressing mobile originated call （MS発信呼の処理の通知）......................................161 5.2.1.4.1 Notification of interworking in connection with mobile originated call establishment （MS発信呼

の確立との関係におけるインターワーキングの通知） .......................................................161 5.2.1.4.2 Call progress in the PLMN/ISDN environment （PLMN/ISDN環境内の呼の進行）.........................161 5.2.1.5 Alerting（アラート処理）...........................................................................................................................162 5.2.1.6 Call connected（コネクトされた呼） ........................................................................................................162 5.2.1.7 Call rejection（呼の拒否） ..........................................................................................................................163 5.2.1.8 Transit network selection（トランジットネットワークの選択）............................................................163 5.2.1.9 Traffic channel assignment at mobile originating call establishment （MS発信呼の確立におけるト

ラフィックチャネルの割当て）.....................................................................................................163 5.2.1.10 Call queuing at mobile originating call establishment （MS発信呼の確立における呼のキューイ

ング） ................................................................................................................................................164 5.2.2 Mobile terminating call establishment（MS着信呼の確立） ...................................................................164 5.2.2.1 Call indication（呼の通知） ........................................................................................................................164 5.2.2.2 Compatibility checking（互換性チェック） ..............................................................................................165 5.2.2.3 Call confirmation（呼の確認）....................................................................................................................165 5.2.2.3.1 Response to SETUP（SETUPへの応答） .............................................................................................165 5.2.2.3.2 Receipt of CALL CONFIRMED and ALERTING by the network （ネットワークによる CALL

CONFIRMED と ALERTINGの受信） .....................................................................................165 5.2.2.3.3 Call failure procedures（呼確立失敗処理） ..........................................................................................166 5.2.2.3.4 Called mobile station clearing during mobile terminating call establishment （MS着信呼の確立中

のコールされたMSのクリア）................................................................................................167 5.2.2.4 Notification of interworking in connection with mobile terminating call establishment （MS着信呼の

確立と関連するインターワーキングの通知） .............................................................................167 5.2.2.5 Call accept（呼試行） ..................................................................................................................................167 5.2.2.6 Active indication（アクティブ通知） ........................................................................................................167 5.2.2.7 Traffic channel assignment at mobile terminating call establishment （MS着信呼の確立におけるト

ラフィックチャネル割当て）.........................................................................................................168 5.2.2.8 Call queuing at mobile terminating call establishment （モバイル着信呼確立に際しての呼のキュー

イング） ............................................................................................................................................168 5.2.2.9 User connection attachment during a mobile terminating call （モバイル着信呼の間のユーザコネク

ションアタッチメント）.................................................................................................................168 5.2.3 Network initiated MO call $(CCBS)$ （ネットワークがMO call $(CCBS)$を開始した場合） .........169 5.2.3.1 Initiation（開始） .........................................................................................................................................169 5.2.3.2 CC-Establishment present ..............................................................................................................................169 5.2.3.2.1 Recall Alignment Procedure.....................................................................................................................170 5.2.3.3 CC-Establishment confirmation（CC確立の確認） ...................................................................................171 5.2.3.4 Recall present .................................................................................................................................................172 5.2.3.5 Traffic channel assignment during network initiated mobile originating call establishment （ネットワ

ークが開始したMS発信呼の確立中のトラフィックチャネルの割当て）..............................172 5.3 Signalling procedures during the "active" state （"active"ステート内のシグナリング処理） ......................173 5.3.1 User notification procedure（ユーザ通知処理） ......................................................................................173 5.3.2 Call rearrangements（呼の再アレンジ）..................................................................................................173 5.3.3 Not used .......................................................................................................................................................173 5.3.4 Support of Dual Services（デュアルサービスのサポート） ..................................................................173 5.3.4.1 Service Description（サービスディスクリプション）.............................................................................173 5.3.4.2 Call establishment（呼確立） ......................................................................................................................174 5.3.4.2.1 Mobile Originating Establishment（モバイル発信の確立） ................................................................174 5.3.4.2.2 Mobile Terminating Establishment（モバイル着信の確立）...............................................................175 5.3.4.3 Changing the Call Mode（コールモードの変更）.....................................................................................175 5.3.4.3.1 Initiation of in-call modification（インコール修正の開始） ...............................................................175

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 11

5.3.4.3.2 Successful completion of in-call modification（インコール修正の正常完了） ..................................175 5.3.4.3.3 Change of the channel configuration（チャネルコンフィギュレーションの変更）.........................176 5.3.4.3.4 Failure of in-call modification（インコール修正の失敗） ..................................................................176 5.3.4.4 Abnormal procedures（異常なケース） .....................................................................................................177 5.3.5 User initiated service level up- and downgrading (GSM only) （ユーザが開始したサービスレベル

のアップグレードまたはダウングレード（GSMのみ）） .............................................................177 5.3.5.1 Initiation of service level up- and downgrading （サービスレベルのアップグレードまたはダウン

グレードの開始）.............................................................................................................................177 5.3.5.2 Successful completion of service level up- and downgrading （サービスレベルのアップグレードま

たはダウングレードの正常終了）.................................................................................................178 5.3.5.3 Rejection of service level up- and downgrading （サービスレベルのアップグレードまたはダウン

グレードの拒否）.............................................................................................................................178 5.3.5.4 Time-out recovery（タイムアウトリカバリ） ..........................................................................................178 5.3.6 Support of multimedia calls（マルチメディア呼のサポート） ..............................................................178 5.3.6.1 Service description（サービスディスクリプション） .............................................................................178 5.3.6.2 Call establishment（呼の確立） ..................................................................................................................179 5.3.6.2.1 Mobile originated multimedia call establishment （モバイル発信マルチメディア呼の確立） ........179 5.3.6.2.2 Mobile terminating multimedia call （モバイル着信マルチメディア呼） .........................................179 5.3.6.3 In-call modification in the "active" state （"active"ステートにおけるインコ－ル修正） .......................180 5.3.6.3.1 Initiation of in-call modification（インコール修正の開始） ...............................................................180 5.3.6.3.2 Successful completion of in-call modification （インコール修正の正常完了） .................................180 5.3.6.3.3 Failure of in-call modification（インコール修正の失敗） ..................................................................181 5.4 Call clearing（呼のクリア） .............................................................................................................................181 5.4.1 Terminology（用語の定義） .....................................................................................................................181 5.4.2 Exception conditions（例外条件） ............................................................................................................181 5.4.3 Clearing initiated by the mobile station (MSによる呼のクリアの開始)..................................................182 5.4.3.1 Initiation of call clearing （呼のクリアの開始）.......................................................................................182 5.4.3.2 Receipt of a DISCONNECT message from the mobile station. （MSからの DISCONNECTメッセー

ジの受信） ........................................................................................................................................182 5.4.3.3 Receipt of a RELEASE message from the network （ネットワークからの RELEASEメッセージの

受信） ................................................................................................................................................182 5.4.3.4 Receipt of a RELEASE COMPLETE message from the mobile station （MSからの RELEASE

COMPLETEメッセージの受信） ...................................................................................................182 5.4.3.5 Abnormal cases（異常なケース） ..............................................................................................................183 5.4.4 Clearing initiated by the network （ネットワークによるクリア処理の開始）.....................................183 5.4.4.1 Clearing initiated by the network: mobile does not support "Prolonged Clearing Procedure" （ネットワ

ークが呼のクリアを開始する場合：MSが"Prolonged Clearing Procedure"をサポートしない場合） ............................................................................................................................................183

5.4.4.1.1 Clearing when tones/announcements provided （トーン／アナウンスが提供されるクリア） ........183 5.4.4.1.1.1 Receipt of a DISCONNECT message with progress indicator #8 from the network （進行識別子#8

といっしょに DISCONNECTメッセージをネットワークから受信した場合） ...........183 5.4.4.1.1.2 Expiry of timer T306（タイマ T306の満了） ......................................................................................184 5.4.4.1.2 Clearing when tones/announcements not provided （トーン/アナウンスが提供されない場合の

呼のクリア） ...............................................................................................................................184 5.4.4.1.2.1 Receipt of a DISCONNECT message without progress indicator or with progress indicator different

from #8 from the network （ネットワークから進行識別子なしで DISCONNECTメッセージを受信した場合、または#8以外の進行識別子といっしょにDISCONNECTメッセージを受信した場合）....................................................................184

5.4.4.1.2.2 Receipt of a RELEASE message from the mobile station （MSから RELEASEメッセージを受信） .........................................................................................................................................184

5.4.4.1.2.3 Abnormal cases（異常なケース）.........................................................................................................184 5.4.4.1.3 Completion of clearing（クリアの完了） .............................................................................................184 5.4.4.1.3.1 Abnormal cases（異常なケース）.........................................................................................................184 5.4.4.2 Clearing initiated by the network: mobile supports "Prolonged Clearing Procedure" （ネットワークに

よるクリア処理の開始：MSが"Prolonged Clearing Procedure"をサポートする場合） ...........185

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 12

5.4.4.2.1 Clearing when tones/announcements provided and the network does not indicate that "CCBS activation is possible" （トーン／アナウンスが提供され、かつネットワークが"CCBS activation is possible"を通知しない場合の呼のクリア） ........................................................185

5.4.4.2.1.1 Receipt of a DISCONNECT message（DISCONNECTメッセージの受信）.....................................185 5.4.4.2.1.2 Expiry of timer T306（タイマ T306の満了） ......................................................................................185 5.4.4.2.2 Clearing when the network indicates that "CCBS activation is possible" （ネットワークが"CCBS

activation is possible"を通知した場合のクリア） ....................................................................186 5.4.4.2.2.1 Receipt of a DISCONNECT（DISCONNECTの受信） .......................................................................186 5.4.4.2.2.2 Expiry of timer T338（タイマ T338の満了） ......................................................................................187 5.4.4.2.3 Clearing when tones/announcements are not provided and the network does not indicate that "CCBS

activation is possible" （トーン／アナウンスが提供されず、ネットワークが"CCBS activation is possible"を通知しない場合のクリア） ................................................................187

5.4.4.2.3.1 Receipt of a DISCONNECT message（DISCONNECTメッセージの受信）.....................................187 5.4.4.2.3.2 Abnormal cases（異常なケース）.........................................................................................................187 5.4.4.2.4 Receipt of a RELEASE message from the mobile station （MSからの RELEASEメッセージの

受信）...........................................................................................................................................187 5.4.4.2.4.1 Release, CCBS not requested（Release, CCBSが要求されない場合） ..............................................187 5.4.4.2.4.2 Release, CCBS Requested（Release, CCBSが要求された場合） .......................................................188 5.4.4.2.5 Completion of clearing（クリア処理の完了） .....................................................................................188 5.4.4.2.5.1 Abnormal cases（異常なケース）.........................................................................................................188 5.4.5 Clear collision ..............................................................................................................................................188 5.5 Miscellaneous procedures（その他の処理） ....................................................................................................188 5.5.1 In-band tones and announcements （インバンドトーンとアナウンス） ...............................................188 5.5.2 Call collisions（呼の衝突） .......................................................................................................................189 5.5.3 Status procedures（ステータス処理）......................................................................................................189 5.5.3.1 Status enquiry procedure（ステータス問合せ処理） ................................................................................189 5.5.3.2 Reception of a STATUS message by a CC entity （CCエンティティによる STATUSメッセージの

受信） ................................................................................................................................................190 5.5.3.2.1 STATUS message with incompatible state （STATUSメッセージと両立しないステート） ..........190 5.5.3.2.2 STATUS message with compatible state （互換性ステートとの STATUSメッセージ） ................190 5.5.4 Call re-establishment, mobile station side （呼の再確立、MS側）.........................................................190 5.5.4.1 Indication from the mobility management sublayer （MMサブレイヤからの通知） ..............................190 5.5.4.2 Reaction of call control（呼制御のリアクション）...................................................................................190 5.5.4.3 Completion of re-establishment（再確立の完了） .....................................................................................191 5.5.4.4 Unsuccessful outcome（失敗した場合の結果） ........................................................................................191 5.5.5 Call re-establishment, network side(呼の再確立、ネットワーク側) .......................................................191 5.5.5.1 State alignment（ステート配置） ...............................................................................................................191 5.5.6 Progress........................................................................................................................................................191 5.5.7 DTMF protocol control procedure（DTMF呼制御処理）........................................................................191 5.5.7.1 Start DTMF request by the mobile station（MSからの DTMF要求開始） ..............................................192 5.5.7.2 Start DTMF response by the network （ネットワークによる DTMF応答の開始） ...............................192 5.5.7.3 Stop DTMF request by the mobile station （MSによる DTMF要求の停止） .........................................192 5.5.7.4 Stop DTMF response by the network（ネットワークによる DTMFの停止） ........................................193 5.5.7.5 Sequencing of subsequent start DTMF requests by the mobile station （MSからの次の DTMF要求の

開始シーケンス）.............................................................................................................................193

6 Support for packet services （パケットサービスのサポート）..................................................... 194 6.1 GPRS Session management（GPRSセッション管理） ..................................................................................194 6.1.1 General（概要） .........................................................................................................................................194 6.1.2 Session management states（ＳＭステート）...........................................................................................194 6.1.2.1 Session management states in the MS（MS側の SMステート） ..............................................................194 6.1.2.1.1 PDP-INACTIVE.......................................................................................................................................194 6.1.2.1.2 PDP-ACTIVE-PENDING ........................................................................................................................194 6.1.2.1.3 PDP-INACTIVE-PENDING....................................................................................................................194 6.1.2.1.4 PDP-ACTIVE...........................................................................................................................................194 6.1.2.1.5 PDP-MODIFY_PENDING ......................................................................................................................195

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 13

6.1.2.2 Session management states on the network side （ネットワーク側の SMステート） ............................195 6.1.2.2.1 PDP-INACTIVE.......................................................................................................................................195 6.1.2.2.2 PDP-ACTIVE-PENDING ........................................................................................................................195 6.1.2.2.3 PDP-INACTIVE-PENDING....................................................................................................................196 6.1.2.2.4 PDP-ACTIVE...........................................................................................................................................196 6.1.2.2.5 PDP-MODIFY-PENDING.......................................................................................................................196 6.1.3 Session Management procedures（SM処理） ....................................................................................................196 6.1.3.1 PDP context activation（PDPコンテキスト活性化） ...............................................................................196 6.1.3.1.1 Successful PDP context activation initiated by the mobile station （MSが開始した PDPコンテキ

スト活性化の正常終了） ...........................................................................................................197 6.1.3.1.2 Successful PDP context activation requested by the network （ネットワークが要求した PDPコ

ンテキスト活性化の正常終了） ...............................................................................................197 6.1.3.1.3 Unsuccessful PDP context activation initiated by the MS （MSが開始した PDPコンテキスト活

性化処理が失敗した場合） .......................................................................................................198 6.1.3.1.4 Unsuccessful PDP context activation requested by the network （ネットワークが要求した PDP

コンテキスト活性化が失敗した場合） ...................................................................................198 6.1.3.1.5 Abnormal cases（異常なケース）.........................................................................................................198 6.1.3.2 Secondary PDP Context Activation Procedure （セカンダリ PDP コンテキスト活性化処理） .......................201 6.1.3.2.1 Successful Secondary PDP Context Activation Procedure Initiated by the MS （MSが開始したセ

カンダリ PDPコンテキスト活性化処理が正常終了した場合） ..........................................201 6.1.3.2.2 Unsuccessful Secondary PDP Context Activation Procedure initiated by the MS （MSが開始した

セカンダリ PDPコンテキスト活性化処理が失敗した場合） ..............................................202 6.1.3.2.3 Abnormal cases（異常なケース）.........................................................................................................202 6.1.3.3 PDP context modification procedure（PDPコンテキスト修正処理）......................................................204 6.1.3.3.1 Network initiated PDP Context Modification （ネットワークが PDPコンテキスト修正を開始

する場合） ...................................................................................................................................204 6.1.3.3.2 MS initiated PDP Context Modification accepted by the network （MSが開始した PDPコンテキ

スト修正がネットワークに受理された場合） .......................................................................204 6.1.3.3.3 MS initiated PDP Context Modification not accepted by the network （MSが開始した PDPコン

テキスト修正がネットワークに受理されない場合） ...........................................................205 6.1.3.3.4 Abnormal cases（異常なケース）.........................................................................................................206 6.1.3.4 PDP context deactivation procedure（PDPコンテキスト非活性化処理）...............................................207 6.1.3.4.1 PDP context deactivation initiated by the MS （MSが PDPコンテキスト非活性化処理を開始す

る場合） .......................................................................................................................................208 6.1.3.4.2 PDP context deactivation initiated by the network （ネットワークが PDPコンテキスト非活性

化処理を開始する場合） ...........................................................................................................208 6.1.3.4.3 Abnormal cases（異常なケース）.........................................................................................................208 6.1.3.4a Void 209 6.1.3.5 Void 209 6.1.3.6 Receiving a SM STATUS message by a SM entity .......................................................................................209 7 Examples of structured procedures 構造化処理の例......................................................................... 209

8 Handling of unknown, unforeseen, and erroneous protocol data （未知の、予見できない、誤ったプロトコルデータの処理） ..................................................................................................... 210

8.1 General（概要）.................................................................................................................................................210 8.2 Message too short（短すぎるメッセージ）.....................................................................................................210 8.3 Unknown or unforeseen transaction identifier （未知の、または予測できない TI）....................................211 8.3.1 Call Control（呼処理） ..............................................................................................................................211 8.3.2 Session Management（セッション管理） ................................................................................................212 8.4 Unknown or unforeseen message type (未知または予期せぬメッセージタイプ) .........................................212 8.5 Non-semantical mandatory information element errors （Non-semantical mandatory IEのエラー） .............213 8.5.1 Radio resource management（無線リソース管理）.................................................................................214 8.5.2 Mobility management（モビリティ管理）...............................................................................................214 8.5.3 Call control（呼制御） ...............................................................................................................................214 8.5.4 GMM mobility management（GMMモビリティ管理） .........................................................................214

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 14

8.5.5 Session management（セッション管理） ................................................................................................214 8.6 Unknown and unforeseen IEs in the non-imperative message part （非必須メッセージパート内で未知

の、予測できない IE） ...............................................................................................................................215 8.6.1 IEIs unknown in the message（メッセージ内で未知の IE） ..................................................................215 8.6.2 Out of sequence Ies（順序外の IE）..........................................................................................................215 8.6.3 Repeated Ies（反復 IE）.............................................................................................................................215 8.7 Non-imperative message part errors （非必須メッセージパートのエラー）................................................215 8.7.1 Syntactically incorrect optional Ies （構文的に不正なオプション IE） .................................................215 8.7.2 Conditional IE errors（条件付 IEのエラー）...........................................................................................215 8.8 Messages with semantically incorrect contents （意味的に不正な内容のメッセージ） ...............................216

9 Message functional definitions and contents (メッセージの機能定義と内容) ............................... 216 9.1 Messages for Radio Resources management （RR管理用メッセージ） ........................................................217 9.2 Messages for mobility management（MM用メッセージ） .............................................................................217 9.2.1 Authentication reject（認証拒否） ..............................................................................................................218 9.2.2 Authentication request（認証要求）............................................................................................................218 9.2.2.1 Authentication Parameter AUTN（認証パラメータ AUTN） ...................................................................218 9.2.3 Authentication response（認証応答） .........................................................................................................219 9.2.3.1 Authentication Response Parameter（認証応答パラメータ） ...................................................................219 9.2.3.2 Authentication Response Parameter (extension) （認証応答パラメータ（拡張）） ...............................219 9.2.3a Authentication Failure （認証の失敗） .......................................................................................................219 9.2.3a.1 Authentication Failure parameter（認証失敗パラメータ） .......................................................................220 9.2.4 CM Re-establishment request（CM再確立要求）......................................................................................220 9.2.4.1 Location area identification（LAI） .............................................................................................................220 9.2.4.2 Mobile Station Classmark（MSクラスマーク）........................................................................................221 9.2.5 CM service accept（CMサービス許容） ...................................................................................................221 9.2.5a CM service prompt $(CCBS)$（CMサービスプロンプト$(CCBS)$）....................................................221 9.2.6 CM service reject（CMサービス拒否）.....................................................................................................221 9.2.7 CM service abort（CMサービス中断） .....................................................................................................222 9.2.8 Abort（中断） ..............................................................................................................................................222 9.2.9 CM service request（CMサービス要求） ..................................................................................................223 9.2.9.1 Mobile Station Classmark（MSクラスマーク）........................................................................................223 9.2.9.2 Priority（優先度）........................................................................................................................................223 9.2.10 Identity request（ID要求） ..........................................................................................................................224 9.2.11 Identity response（ID応答） .......................................................................................................................224 9.2.12 IMSI detach indication（IMSIデタッチ通知） ..........................................................................................224 9.2.12.1 Mobile Station Classmark（MSクラスマーク） ..................................................................................225 9.2.13 Location updating accept（位置登録更新の許容）....................................................................................225 9.2.13.1 Follow on proceed ....................................................................................................................................225 9.2.13.2 CTS permission ........................................................................................................................................226 9.2.14 Location updating reject（位置登録更新の拒否） .....................................................................................226 9.2.15 Location updating request（位置登録更新要求） ......................................................................................226 9.2.15.1 Location area identification（LAI）........................................................................................................227 9.2.15.2 Mobile Station Classmark（MSクラスマーク） ..................................................................................227 9.2.15.3 Mobile Station Classmark for UMTS（UMTS用MSクラスマーク） ................................................227 9.2.15a MM information（MM情報） .....................................................................................................................227 9.2.15a.1 Full name for network ..............................................................................................................................228 9.2.15a.2 Short name for network ............................................................................................................................228 9.2.15a.3 Local time zone（ローカルタイムゾーン）.........................................................................................228 9.2.15a.4 Universal time and local time zone（ユニバーサルタイムとローカルタイムゾーン） ...................228 9.2.15a.5 LSA Identity .............................................................................................................................................229 9.2.15a.6 Network Daylight Saving Time................................................................................................................229 9.2.16 MM Status......................................................................................................................................................229 9.2.17 TMSI reallocation command（TMSI再配置コマンド）............................................................................229 9.2.18 TMSI reallocation complete（TMSI再配置完了）.....................................................................................230 9.2.19 MM Null ........................................................................................................................................................230

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 15

9.3 Messages for circuit-switched call control （CS呼制御用メッセージ） ........................................................231 9.3.1 Alerting（アラート） ..................................................................................................................................231 9.3.1.1 Alerting (Network→MS direction) （Alerting (ネットワーク→MS 方向)）............................................231 9.3.1.1.1 Facility......................................................................................................................................................232 9.3.1.1.2 Progress indicator .....................................................................................................................................232 9.3.1.1.3 User-user...................................................................................................................................................232 9.3.1.2 Alerting (MS→Network direction) （Alerting (MS→ネットワーク方向)）............................................232 9.3.1.2.1 Facility......................................................................................................................................................233 9.3.1.2.2 User-user...................................................................................................................................................233 9.3.1.2.3 SS version.................................................................................................................................................233 9.3.2 Call confirmed................................................................................................................................................233 9.3.2.1 Repeat indicator .............................................................................................................................................234 9.3.2.2 Bearer capability 1 and bearer capability 2 （Bearer capability 1と bearer capability 2）..........................234 9.3.2.3 Cause 234 9.3.2.4 CC Capabilities ..............................................................................................................................................235 9.3.2.5 Stream Identifier.............................................................................................................................................235 9.3.3 Call proceeding ..............................................................................................................................................235 9.3.3.1 Repeat indicator .............................................................................................................................................235 9.3.3.2 Bearer capability 1 and bearer capability 2 （Bearer capability 1 と bearer capability 2） .........................235 9.3.3.3 Facility ...........................................................................................................................................................236 9.3.3.4 Progress Indicator...........................................................................................................................................236 9.3.3.5 Priority granted...............................................................................................................................................236 9.3.3.6 Network Call Control Capabilities .................................................................................................................236 9.3.4 Congestion control（輻輳制御） .................................................................................................................236 9.3.4.1 Cause 237 9.3.5 Connect ..........................................................................................................................................................237 9.3.5.1 Connect (Network→MS direction) （Connect (ネットワーク→MS 方向)）............................................237 9.3.5.1.1 Facility......................................................................................................................................................237 9.3.5.1.2 Progress indicator .....................................................................................................................................237 9.3.5.1.3 User-user...................................................................................................................................................237 9.3.5.2 Connect (MS→Network direction) ................................................................................................................238 9.3.5.2.1 Facility......................................................................................................................................................238 9.3.5.2.2 User-user...................................................................................................................................................238 9.3.5.2.3 SS version.................................................................................................................................................238 9.3.5.2.4 Stream Identifier .......................................................................................................................................238 9.3.6 Connect acknowledge ....................................................................................................................................238 9.3.7 Disconnect......................................................................................................................................................239 9.3.7.1 Disconnect (ネットワーク→MS 方向)........................................................................................................239 9.3.7.1.1 Facility......................................................................................................................................................239 9.3.7.1.2 Progress indicator .....................................................................................................................................239 9.3.7.1.3 User-user...................................................................................................................................................240 9.3.7.2 Disconnect (MS→ネットワーク方向).........................................................................................................240 9.3.7.2.1 Facility......................................................................................................................................................240 9.3.7.2.2 User-user...................................................................................................................................................240 9.3.7.2.3 SS version.................................................................................................................................................240 9.3.8 Emergency setup ............................................................................................................................................240 9.3.8.1 Bearer capability ............................................................................................................................................241 9.3.8.2 Stream Identifier.............................................................................................................................................241 9.3.9 Facility ...........................................................................................................................................................241 9.3.9.1 Facility (ネットワーク→MS direction) .......................................................................................................241 9.3.9.2 Facility (MS→ネットワーク方向) ..............................................................................................................242 9.3.9.2.1 SS version.................................................................................................................................................242 9.3.10 Hold................................................................................................................................................................243 9.3.11 Hold Acknowledge.........................................................................................................................................243 9.3.12 Hold Reject ....................................................................................................................................................243 9.3.13 Modify............................................................................................................................................................244 9.3.13.1 Low layer compatibility............................................................................................................................244 9.3.13.2 High layer compatibility ...........................................................................................................................244 9.3.13.3 Reverse call setup direction ......................................................................................................................244 9.3.13.4 Immediate modification indicator.............................................................................................................245

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 16

9.3.14 Modify complete ............................................................................................................................................245 9.3.14.1 Low layer compatibility............................................................................................................................245 9.3.14.2 High layer compatibility ...........................................................................................................................245 9.3.14.3 Reverse call setup direction ......................................................................................................................245 9.3.15 Modify reject..................................................................................................................................................245 9.3.15.1 Low layer compatibility............................................................................................................................246 9.3.15.2 High layer compatibility ...........................................................................................................................246 9.3.16 Notify .............................................................................................................................................................246 9.3.17 Progress..........................................................................................................................................................246 9.3.17.1 User-user...................................................................................................................................................247 9.3.17a CC-Establishment $(CCBS)$.........................................................................................................................247 9.3.17a.1 Void ..........................................................................................................................................................247 9.3.17a.2 Setup container .........................................................................................................................................247 9.3.17b CC-Establishment confirmed $(CCBS)$ .......................................................................................................248 9.3.17b.1 Repeat indicator........................................................................................................................................248 9.3.17b.2 Bearer capability 1 and bearer capability 2...............................................................................................248 9.3.17b.3 Cause ........................................................................................................................................................248 9.3.18 Release ...........................................................................................................................................................248 9.3.18.1 Release (ネットワーク→MS方向)........................................................................................................248 9.3.18.1.1 Cause 249 9.3.18.1.2 Second cause ............................................................................................................................................249 9.3.18.1.3 Facility......................................................................................................................................................249 9.3.18.1.4 User-user...................................................................................................................................................249 9.3.18.2 Release (MS→ネットワーク方向).........................................................................................................249 9.3.18.2.1 Cause 250 9.3.18.2.2 Second cause ............................................................................................................................................250 9.3.18.2.3 Facility......................................................................................................................................................250 9.3.18.2.4 User-user...................................................................................................................................................250 9.3.18.2.5 SS version.................................................................................................................................................250 9.3.18a Recall $(CCBS)$............................................................................................................................................250 9.3.18a.1 Recall Type...............................................................................................................................................251 9.3.18a.2 Facility......................................................................................................................................................251 9.3.19 Release complete............................................................................................................................................251 9.3.19.1 Release complete (ネットワーク→MS方向) ........................................................................................251 9.3.19.1.1 Cause 252 9.3.19.1.2 Facility......................................................................................................................................................252 9.3.19.1.3 User-user...................................................................................................................................................252 9.3.19.2 Release complete (MS→ネットワーク方向) .........................................................................................252 9.3.19.2.1 Cause 252 9.3.19.2.2 Facility......................................................................................................................................................252 9.3.19.2.3 User-user...................................................................................................................................................252 9.3.19.2.4 SS version. ................................................................................................................................................253 9.3.20 Retrieve ..........................................................................................................................................................253 9.3.21 Retrieve Acknowledge ...................................................................................................................................253 9.3.22 Retrieve Reject ...............................................................................................................................................253 9.3.23 Setup ..............................................................................................................................................................254 9.3.23.1 Setup (mobile terminated call establishment)...........................................................................................254 9.3.23.1.1 BC repeat indicator...................................................................................................................................255 9.3.23.1.2 Bearer capability 1 と bearer capability 2 ................................................................................................256 9.3.23.1.3 Facility......................................................................................................................................................256 9.3.23.1.4 Progress indicator .....................................................................................................................................256 9.3.23.1.4a Called party BCD number ........................................................................................................................256 9.3.23.1.5 Called party subaddress ............................................................................................................................256 9.3.23.1.6 LLC repeat indicator.................................................................................................................................256 9.3.23.1.7 Low layer compatibility I .........................................................................................................................256 9.3.23.1.8 Low layer compatibility II ........................................................................................................................256 9.3.23.1.9 HLC repeat indicator ................................................................................................................................256 9.3.23.1.10 High layer compatibility i .........................................................................................................................257 9.3.23.1.11 High layer compatibility ii........................................................................................................................257 9.3.23.1.12 User-user...................................................................................................................................................257 9.3.23.1.13 Redirecting party BCD number ................................................................................................................257

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 17

9.3.23.1.14 Redirecting party subaddress....................................................................................................................257 9.3.23.1.15 Priority......................................................................................................................................................257 9.3.23.1.16 Alert $(Network Indication of Alerting in the MS )$ ...............................................................................257 9.3.23.1.17 Network Call Control Capabilities ...........................................................................................................257 9.3.23.1.18 Cause of No CLI.......................................................................................................................................257 9.3.23.2 Setup (mobile originating call establishment) ..........................................................................................257 9.3.23.2.1 BC repeat indicator...................................................................................................................................258 9.3.23.2.2 Facility......................................................................................................................................................258 9.3.23.2.3 LLC repeat indicator.................................................................................................................................259 9.3.23.2.4 Low layer compatibility I .........................................................................................................................259 9.3.23.2.5 Low layer compatibility II ........................................................................................................................259 9.3.23.2.6 HLC repeat indicator ................................................................................................................................259 9.3.23.2.7 High layer compatibility i .........................................................................................................................259 9.3.23.2.8 High layer compatibility ii........................................................................................................................259 9.3.23.2.9 User-user...................................................................................................................................................259 9.3.23.2.10 SS version.................................................................................................................................................259 9.3.23.2.11 CLIR suppression .....................................................................................................................................259 9.3.23.2.12 CLIR invocation .......................................................................................................................................259 9.3.23.2.13 CC Capabilities.........................................................................................................................................260 9.3.23.2.14 Stream Identifier .......................................................................................................................................260 9.3.23.2.15 Bearer capability 1 と bearer capability 2 ................................................................................................260 9.3.23a Start CC $(CCBS)$ ........................................................................................................................................260 9.3.23a.1 CC Capabilities.........................................................................................................................................260 9.3.24 Start DTMF....................................................................................................................................................260 9.3.25 Start DTMF Acknowledge .............................................................................................................................261 9.3.25.1 Keypad facility .........................................................................................................................................261 9.3.26 Start DTMF reject ..........................................................................................................................................261 9.3.27 Status..............................................................................................................................................................262 9.3.27.1 Auxiliary states .........................................................................................................................................262 9.3.28 Status enquiry.................................................................................................................................................262 9.3.29 Stop DTMF ....................................................................................................................................................263 9.3.30 Stop DTMF acknowledge ..............................................................................................................................263 9.3.31 User information ............................................................................................................................................264 9.3.31.1 User-user...................................................................................................................................................264 9.3.31.2 More data..................................................................................................................................................264 9.4 GPRS Mobility Management Messages （GPRSのMMメッセージ） ..........................................................264 9.4.1 Attach request ................................................................................................................................................264 9.4.1.1 Old P-TMSI signature ....................................................................................................................................265 9.4.1.2 Requested READY timer value .....................................................................................................................265 9.4.1.3 TMSI status ....................................................................................................................................................265 9.4.2 Attach accept..................................................................................................................................................265 9.4.2.1 P-TMSI signature ...........................................................................................................................................266 9.4.2.2 Negotiated READY timer ..............................................................................................................................266 9.4.2.3 Allocated P-TMSI ..........................................................................................................................................266 9.4.2.4 MS identity.....................................................................................................................................................266 9.4.2.5 GMM cause....................................................................................................................................................266 9.4.2.6 T3302 value....................................................................................................................................................266 9.4.2.7 Cell Notification (GSM のみ)........................................................................................................................267 9.4.3 Attach complete .............................................................................................................................................267 9.4.4 Attach reject ...................................................................................................................................................267 9.4.4.1 T3302 value....................................................................................................................................................267 9.4.5 Detach request................................................................................................................................................268 9.4.5.1 Detach request (モバイル着信デタッチ).....................................................................................................268 9.4.5.1.1 GMM cause ..............................................................................................................................................268 9.4.5.2 Detach request (モバイル発信デタッチ).....................................................................................................268 9.4.5.2.1 P-TMSI.....................................................................................................................................................269 9.4.5.2.2 P-TMSI signature .....................................................................................................................................269 9.4.6 Detach accept .................................................................................................................................................269 9.4.6.1 Detach accept (モバイル着信デタッチ) ......................................................................................................269 9.4.6.2 Detach accept (モバイル発信デタッチ) ......................................................................................................269 9.4.7 P-TMSI reallocation command ......................................................................................................................270

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 18

9.4.7.1 P-TMSI signature ...........................................................................................................................................270 9.4.8 P-TMSI reallocation complete .......................................................................................................................270 9.4.9 Authentication and ciphering request.............................................................................................................270 9.4.9.1 Authentication Parameter RAND...................................................................................................................271 9.4.9.2 GPRS ciphering key sequence number ..........................................................................................................271 9.4.9.3 Authentication Parameter AUTN...................................................................................................................271 9.4.10 Authentication and ciphering response ..........................................................................................................271 9.4.10.1 Authentication Response Parameter .........................................................................................................272 9.4.10.2 IMEISV ....................................................................................................................................................272 9.4.10.3 Authentication Response Parameter (extension) ......................................................................................272 9.4.10a Authentication and Ciphering Failure ............................................................................................................272 9.4.10a.1 Authentication Failure parameter .............................................................................................................273 9.4.11 Authentication and ciphering reject ...............................................................................................................273 9.4.12 Identity request...............................................................................................................................................273 9.4.13 Identity response ............................................................................................................................................274 9.4.14 Routing area update request ...........................................................................................................................274 9.4.14.1 Old P-TMSI signature ..............................................................................................................................275 9.4.14.2 Requested READY timer value................................................................................................................275 9.4.14.4 TMSI status ..............................................................................................................................................275 9.4.14.5 P-TMSI (UMTS only) ..............................................................................................................................275 9.4.14.6 MS network capability..............................................................................................................................275 9.4.15 Routing area update accept ............................................................................................................................276 9.4.15.1 P-TMSI signature .....................................................................................................................................276 9.4.15.2 Allocated P-TMSI.....................................................................................................................................276 9.4.15.3 MS identity ...............................................................................................................................................276 9.4.15.4 List of Receive N-PDU Numbers .............................................................................................................277 9.4.15.5 Negotiated READY timer value ...............................................................................................................277 9.4.15.6 GMM cause ..............................................................................................................................................277 9.4.15.7 T3302 value ..............................................................................................................................................277 9.4.15.8 Cell Notification (GSM only) ..................................................................................................................277 9.4.16 Routing area update complete ........................................................................................................................277 9.4.16.1 List of Receive N-PDU Numbers .............................................................................................................277 9.4.17 Routing area update reject..............................................................................................................................277 9.4.17.1 T3302 value ..............................................................................................................................................278 9.4.18 GMM Status ...................................................................................................................................................278 9.4.19 GMM Information..........................................................................................................................................278 9.4.19.1 Full name for network ..............................................................................................................................279 9.4.19.2 Short name for network ............................................................................................................................279 9.4.19.3 Local time zone ........................................................................................................................................279 9.4.19.4 Universal time and local time zone...........................................................................................................279 9.4.19.5 LSA Identity .............................................................................................................................................279 9.4.19.6 Network Daylight Saving Time................................................................................................................279 9.4.20 Service Request (UMTS only) .......................................................................................................................280 9.4.20.1 Void ..........................................................................................................................................................280 9.4.21 Service Accept (UMTS only).........................................................................................................................280 9.4.22 Service Reject (UMTS only)..........................................................................................................................280 9.5 GPRS Session Management Messages（GPRS SMメッセージ） ...................................................................281 9.5.1 Activate PDP context request.........................................................................................................................281 9.5.1.1 Access point name..........................................................................................................................................281 9.5.1.2 Protocol configuration options .......................................................................................................................281 9.5.2 Activate PDP context accept ..........................................................................................................................282 9.5.2.1 PDP address ...................................................................................................................................................282 9.5.2.2 Protocol configuration options .......................................................................................................................282 9.5.2.3 Packet Flow Identifier ....................................................................................................................................282 9.5.3 Activate PDP context reject ...........................................................................................................................282 9.5.3.1 Protocol configuration options .......................................................................................................................283 9.5.4 Activate Secondary PDP Context Request.....................................................................................................283 9.5.4.1 TFT 283 9.5.5 Activate Secondary PDP Context Accept ......................................................................................................284 9.5.5.1 Packet Flow Identifier ....................................................................................................................................284 9.5.6 Activate Secondary PDP Context Reject .......................................................................................................284 9.5.7 Request PDP context activation .....................................................................................................................285

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 19

9.5.8 Request PDP context activation reject ...........................................................................................................285 9.5.9 Modify PDP context request (Network to MS direction)...............................................................................285 9.5.9.1 PDP address ...................................................................................................................................................286 9.5.9.2 Packet Flow Identifier ....................................................................................................................................286 9.5.10 Modify PDP context request (MS to network direction)................................................................................286 9.5.10.1 Requested LLC SAPI ...............................................................................................................................287 9.5.10.2 Requested new QoS..................................................................................................................................287 9.5.10.3 New TFT ..................................................................................................................................................287 9.5.11 Modify PDP context accept (MS to network direction) .................................................................................287 9.5.12 Modify PDP context accept (Network to MS direction) ................................................................................287 9.5.12.1 Negotiated QoS ........................................................................................................................................288 9.5.12.2 Negotiated LLC SAPI ..............................................................................................................................288 9.5.12.3 New radio priority ....................................................................................................................................288 9.5.12.4 Packet Flow Identifier ..............................................................................................................................288 9.5.13 Modify PDP Context Reject...........................................................................................................................288 9.5.14 Deactivate PDP context request .....................................................................................................................289 9.5.14.1 Tear down indicator..................................................................................................................................289 9.5.15 Deactivate PDP context accept ......................................................................................................................289 9.5.16 Void................................................................................................................................................................290 9.5.17 Void................................................................................................................................................................290 9.5.18 Void................................................................................................................................................................290 9.5.19 Void................................................................................................................................................................290 9.5.20 Void................................................................................................................................................................290 9.5.21 SM Status .......................................................................................................................................................290 10 General message format and information elements coding （一般的なメッセージのフォーマ

ットと IEのコーディング）............................................................................................................ 291 10.1 Overview..............................................................................................................................................................291 10.2 PD（Protocol Discriminator）............................................................................................................................291 10.3 Skip indicator and transaction identifier （スキップインジケータと TI） .....................................................292 10.3.1 Skip indicator（スキップインジケータ）..................................................................................................292 10.3.2 Transaction identifier（TI）..........................................................................................................................292 10.4 Message Type ......................................................................................................................................................292 10.5 Other information elements（その他の IE）.....................................................................................................296 10.5.1 Common information elements（共通 IE） .................................................................................................298 10.5.1.1 Cell identity ..............................................................................................................................................298 10.5.1.2 Ciphering Key Sequence Number ............................................................................................................298 10.5.1.3 Location Area Identification.....................................................................................................................299 10.5.1.4 Mobile Identity .........................................................................................................................................300 10.5.1.5 Mobile Station Classmark 1......................................................................................................................302 10.5.1.6 Mobile Station Classmark 2......................................................................................................................303 10.5.1.7 Mobile Station Classmark 3......................................................................................................................307 10.5.1.8 Spare Half Octet .......................................................................................................................................313 10.5.1.9 Descriptive group or broadcast call reference ..........................................................................................313 10.5.1.10 Group Cipher Key Number ......................................................................................................................315 10.5.1.10a PD and SAPI $(CCBS)$...........................................................................................................................316 10.5.1.11 Priority Level............................................................................................................................................317 10.5.1.12 Core Network System Information (UMTS only) ....................................................................................317 10.5.1.12.1 CN Common GSM-MAP NAS system information ................................................................................317 10.5.1.12.2 CS domain specific system information ...................................................................................................318 10.5.1.12.3 PS domain specific system information....................................................................................................318 10.5.2 Radio Resource management information elements. .....................................................................................319 10.5.3 Mobility management information elements..................................................................................................319 10.5.3.1 Authentication parameter RAND .............................................................................................................319 10.5.3.1.1 Authentication Parameter AUTN (UMTS authentication challenge only) ...............................................319 10.5.3.2 Authentication Response parameter .........................................................................................................320 10.5.3.2.1 Authentication Response Parameter (extension) (UMTS authentication challenge only) ........................321 10.5.3.2.2 Authentication Failure parameter (UMTS authentication challenge only) ...............................................321 10.5.3.3 CM service type........................................................................................................................................322 10.5.3.4 Identity type..............................................................................................................................................322 10.5.3.5 Location updating type .............................................................................................................................322

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 20

10.5.3.5a Network Name..........................................................................................................................................323 10.5.3.6 Reject cause ..............................................................................................................................................324 10.5.3.7 Follow-on Proceed....................................................................................................................................325 10.5.3.8 Time Zone ................................................................................................................................................325 10.5.3.9 Time Zone and Time ................................................................................................................................326 10.5.3.10 CTS permission ........................................................................................................................................327 10.5.3.11 LSA Identifier...........................................................................................................................................328 10.5.3.12 Daylight Saving Time...............................................................................................................................328 10.5.4 Call control information elements..................................................................................................................329 10.5.4.1 Extensions of codesets..............................................................................................................................329 10.5.4.2 Locking shift procedure............................................................................................................................329 10.5.4.3 Non-locking shift procedure .....................................................................................................................330 10.5.4.4 Auxiliary states .........................................................................................................................................330 10.5.4.5 Bearer capability.......................................................................................................................................331 10.5.4.5.1 Static conditions for the bearer capability IE contents .............................................................................347 10.5.4.5a Call Control Capabilities ..........................................................................................................................347 10.5.4.6 Call state ...................................................................................................................................................348 10.5.4.7 Called party BCD number ........................................................................................................................349 10.5.4.8 Called party subaddress ............................................................................................................................351 10.5.4.9 Calling party BCD number .......................................................................................................................352 10.5.4.10 Calling party subaddress...........................................................................................................................353 10.5.4.11 Cause ........................................................................................................................................................354 10.5.4.11a CLIR suppression .....................................................................................................................................359 10.5.4.11b CLIR invocation .......................................................................................................................................360 10.5.4.12 Congestion level .......................................................................................................................................360 10.5.4.13 Connected number ....................................................................................................................................360 10.5.4.14 Connected subaddress...............................................................................................................................361 10.5.4.15 Facility......................................................................................................................................................361 10.5.4.16 High layer compatibility ...........................................................................................................................361 10.5.4.16.1 Static conditions for the high layer compatibility IE contents （high layer compatibility IEのコン

テンツ用の定常条件） ...............................................................................................................362 10.5.4.17 Keypad facility .........................................................................................................................................362 10.5.4.18 Low layer compatibility............................................................................................................................363 10.5.4.19 More data..................................................................................................................................................363 10.5.4.20 Notification indicator................................................................................................................................363 10.5.4.21 Progress indicator .....................................................................................................................................364 10.5.4.21a Recall type $(CCBS)$ ..............................................................................................................................365 10.5.4.21b Redirecting party BCD number ................................................................................................................366 10.5.4.21c Redirecting party subaddress....................................................................................................................366 10.5.4.22 Repeat indicator........................................................................................................................................367 10.5.4.22a Reverse call setup direction ......................................................................................................................367 10.5.4.22b SETUP Container $(CCBS)$ ...................................................................................................................367 10.5.4.23 Signal........................................................................................................................................................368 10.5.4.24 SS Version Indicator.................................................................................................................................368 10.5.4.25 User-user...................................................................................................................................................369 10.5.4.26 Alerting Pattern $(NIA)$..........................................................................................................................370 10.5.4.27 Allowed actions $(CCBS)$ ......................................................................................................................371 10.5.4.28 Stream Identifier .......................................................................................................................................371 10.5.4.29 Network Call Control Capabilities ...........................................................................................................372 10.5.4.30 Cause of No CLI.......................................................................................................................................372 10.5.4.31 Immediate modification indicator.............................................................................................................373 10.5.5 GPRS mobility management information elements .......................................................................................373 10.5.5.1 Attach result..............................................................................................................................................373 10.5.5.2 Attach type................................................................................................................................................373 10.5.5.3 Ciphering algorithm..................................................................................................................................374 10.5.5.4 TMSI status ..............................................................................................................................................374 10.5.5.5 Detach type ...............................................................................................................................................375 10.5.5.6 DRX parameter.........................................................................................................................................376 10.5.5.7 Force to standby .......................................................................................................................................378 10.5.5.8 P-TMSI signature .....................................................................................................................................378 10.5.5.9 Identity type 2...........................................................................................................................................379

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 21

10.5.5.10 IMEISV request........................................................................................................................................379 10.5.5.11 Receive N-PDU Numbers list...................................................................................................................380 10.5.5.12 MS network capability..............................................................................................................................381 10.5.5.12a MS Radio Access capability.....................................................................................................................383 10.5.5.13 Spare.........................................................................................................................................................387 10.5.5.14 GMM cause ..............................................................................................................................................387 10.5.5.15 Routing area identification .......................................................................................................................388 10.5.5.16 Spare.........................................................................................................................................................389 10.5.5.17 Update result.............................................................................................................................................389 10.5.5.18 Update type...............................................................................................................................................390 10.5.5.19 A&C reference number ............................................................................................................................390 10.5.5.20 Service type ..............................................................................................................................................391 10.5.6 Session management information elements ...................................................................................................392 10.5.6.1 Access Point Name...................................................................................................................................392 10.5.6.2 Network service access point identifier ....................................................................................................392 10.5.6.3 Protocol configuration options .................................................................................................................393 10.5.6.4 Packet data protocol address.....................................................................................................................396 10.5.6.5 Quality of service......................................................................................................................................398 10.5.6.6 SM cause ..................................................................................................................................................403 10.5.6.7 Linked TI ..................................................................................................................................................404 10.5.6.8 Spare.........................................................................................................................................................405 10.5.6.9 LLC service access point identifier ..........................................................................................................405 10.5.6.10 Tear down indicator..................................................................................................................................405 10.5.6.11 Packet Flow Identifier ..............................................................................................................................406 10.5.6.12 Traffic Flow Template..............................................................................................................................406 10.5.7 GPRS Common information elements ...........................................................................................................411 10.5.7.1 Void ..........................................................................................................................................................411 10.5.7.2 Radio priority............................................................................................................................................411 10.5.7.3 GPRS Timer .............................................................................................................................................411 11 List of system parameters（システムパラメータのリスト） ........................................................ 413 11.1 Timers and counters for radio resource management （RR管理用タイマとカウンタ）................................413 11.2 Timers of mobility management（MM用タイマ） ..........................................................................................413 11.2.1 Timer T3240 ..................................................................................................................................................414 11.2.2 Timers of GPRS mobility management （GPRSモビリティ管理のタイマ） ..........................................415 11.2.3 Timers of session management(SM用タイマ) .............................................................................................418 11.3 Timers of circuit-switched call control （CS呼制御用タイマ）......................................................................419

Annex A (informative): Example of subaddress information element coding （subaddress IEのコーディング例） ......................................................................................................................................... 421

Annex B (normative): Compatibility checking（互換性チェック）.......................................................... 422 B.1 Introduction（導入）..........................................................................................................................................422 B.2 Calling side compatibility checking （発呼側の互換性チェック） ................................................................422 B.2.1 Compatibility checking of the CM SERVICE REQUEST message （CM SERVICE REQUESTメッセ

ージの互換性チェック） ......................................................................................................................422 B.2.2 Compatibility/Subscription checking of the SETUP message （SETUPメッセージの互換性／加入者

チェック） ..............................................................................................................................................422 B.3 Called side compatibility checking （着信側の互換性チェック） .................................................................423 B.3.1 Compatibility checking with addressing information （アドレス情報との互換性チェック） ................423 B.3.2 Network-to-MS compatibility checking （ネットワーク→MSの互換性チェック）..............................423 B.3.3 User-to-User compatibility checking （ユーザ→ユーザ互換性チェック） .............................................423 B.4 High layer compatibility checking （上位レイヤ互換性チェック） ..............................................................424

Annex C (normative): Low layer information coding principles （下位レイヤ情報コーディングの原則） ..................................................................................................................................................... 425

C.1 Purpose（目的）.................................................................................................................................................425 C.2 Principles（原則） .............................................................................................................................................425 C.2.1 Definition of types of information（情報のタイプの定義） ......................................................................425

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 22

C.2.2 Examination by network（ネットワークによる検証）.............................................................................425 C.2.3 Location of type I information（Type Iの情報の位置） ............................................................................426 C.2.4 Location of types II and III information （type II および IIIの情報の位置） ...........................................426 C.2.5 Relationship between bearer capability and low layer compatibility information elements （bearer

capability IEと low layer compatibility IEの関係） .............................................................................426

Annex D (informative): Examples of bearer capability information element coding （bearer capability IEのエンコード例）......................................................................................................................... 427

D.1 Coding for speech for a full rate support only mobile station （フルレートの音声コーディングだけをサポートするMS） .....................................................................................................................................427

D.1.1 Mobile station to network direction（MS→ネットワーク方向） ..............................................................427 D.1.2 Network to mobile station direction（ネットワーク→MS方向）.............................................................427 D.2 An example of a coding for modem access with V22-bis, 2.4 kbit/s, 8 bit no parity （V22-bis, 2.4 kbit/s, 8

ビットノンパリティのモデムアクセス用エンコード例） ....................................................................428 D.2.1 Mobile station to network direction, data compression allowed （MS→ネットワーク方向、データ圧

縮許可） ..................................................................................................................................................428 D.2.2 Network to mobile station direction, data compression possible （ネットワーク→MS方向、データ

圧縮可能） ..............................................................................................................................................429 D.3 An example of a coding for group 3 facsimile (9.6 kbit/s, transparent) （G3FAX用のコーディング例

（9.6 kbit/s、トランスペアレント）） .....................................................................................................430 D.3.1 Mobile station to network direction（MS→ネットワーク方向） ..............................................................430 D.3.2 Network to mobile station direction（ネットワーク→MS方向）.............................................................430 Annex E (informative): Comparison between call control procedures specified in TS 24.008 and ITU-T

Recommendation Q.931 （TS 24.008と ITU-T 勧告 Q.931との呼制御処理との比較） ............ 432

Annex F (informative): GSM specific cause values for radio resource management （GSM固有の RR管理用理由値） ................................................................................................................................. 436

Annex G (informative): UMTS specific cause values for mobility management （UMTS固有のMM用理由値） ......................................................................................................................................... 437

G.1 Causes related to MS identification （MS識別に関係する理由値） ..............................................................437 G.2 Cause related to subscription options （加入者オプションに関する理由値） ..............................................437 G.3 Causes related to PLMN specific network failures and congestion / Authentication Failures （PLMN固有

のネットワークエラーおよび輻輳／認証エラーに関する理由値） ....................................................438 G.4 Causes related to nature of request ......................................................................................................................438 G.5 Causes related to invalid messages ......................................................................................................................438 G.6 Additional cause codes for GMM........................................................................................................................439 Annex I (informative): GPRS specific cause values for session management （GPRS固有の SM用理

由値） ................................................................................................................................................. 446 I.1 Causes related to nature of request （要求の性質に関する理由値） ..............................................................446 I.2 Causes related to invalid messages （無効なメッセージに関する理由値）..................................................448

Annex J (informative): Algorithm to encode frequency list information elements （frequency list IEのエンコードアルゴリズム） ............................................................................................................. 449

Annex K (informative): Default Codings of Information Elements （IEのデフォルトコーディング）. 450 K.1 Common information elements （共通 IE） ......................................................................................................450 K.2 Radio Resource management information elements （RR管理 IE） ................................................................450 K.3 Mobility management information elements （MM IE） ..................................................................................451 K.4 Call control information elements（CC IE）......................................................................................................451

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 23

Annex M (normative): Additional Requirements for backward compatibility with PCS 1900 for NA revision 0 ME （PCS 1900とのバックワード互換性のための追加要求条件、NA revision 0 のME用） ......................................................................................................................................... 453

Annex N (informative): Change Record（改版履歴） ................................................................................ 454

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 24

Foreword The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 Indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the specification;

Introduction（導入）本ドキュメントには、GSM 技術仕様書の Phase 2+ Release 96 には含まれないフィーチャへのリファレンスも含まれる。

これらのフィーチャの結果、変更された節には、フィーチャに関連するマーカ（下表参照）が含まれる。

下表は、GSM Release 96 の後に導入されたフィーチャの一覧表である。

Feature Designator BA Range IE handling $(impr-BA-range-handling)$ Advanced Speech Call Item $(ASCI)$ Call Completion Busy Subscriber $(CCBS)$ Mobile Assisted Frequency Allocation $(MAFA)$ Network Indication of Alerting in MS $(NIA)$

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 25

1 Scope（本書の範囲）本技術仕様書は、3G 移動通信システムと、ディジタルセルラ通信システムにおける無線インタフェースコアネットワ

ークプロトコル手順について規定するものである。

CC（Call Control、呼制御）、MM（Mobility Management、モビリティ管理）、そして SM（Session Management、セッショ

ン管理）のために、無線インタフェース（Reference Point Um, TS 24.002 参照）において使用される手順を規定する。

本技術仕様書中に、"further study" 、 "FS" 、"FFS"等の注記があった場合には、指定されたテキストが本仕様書の

標準的な部分内にないことを示す。

これらの手順は、無線インタフェースの制御チャネル上でのメッセージのやりとりとして定義される。制御チャネルに

ついては、GSM 04.03 で規定される。

本プロトコルの機能と手順の構造と、他レイヤおよびエンティティとの関係については、TS 24.007 で包括的に説明さ

れている。

1.1 Scope of the Technical Specification（技術仕様書の範囲）本技術仕様書内で現時点で説明されている処理は、CS 呼の呼制御、GPRS サービスのセッション管理、CS 呼およ

び GPRS サービスのモビリティ管理と無線リソース管理のための処理である。

TS 24.010 には、付加サービスをサポートするための、機能の処理に関する記載が含まれる。

GSM 04.11 には、point-to-point のショートメッセージサービス（SMS）をサポートするための、機能の処理に関する記

載が含まれる。

GSM 04.12 には、ショートメッセージ－セルブロードキャストの機能説明が含まれる。

GSM 04.60 には、パケットデータ物理チャネルの RLC/MAC（radio link control and medium access control）の手順が

含まれる。

TS 24.071 には、ロケーションサービスをサポートするための、機能説明と処理に関する記載が含まれる。

NOTE: 本技術仕様書中では、L3（layer 3）という用語には、機能とプロトコルが含まれる。L3 の直下のレイヤ

を指すために、データリンクレイヤ（data link layer）または L2 （layer 2）という用語が使用される。

1.2 Application to the interface structures （インタフェース構造への適用）

L3 手順は、GSM 04.03 中で定義されるインタフェース構造に対して適用される。L3 は、GSM 04.05 および GSM 04.06 中で定義される L2 が提供する機能とサービスを使用する。L3 のプロトコル手順、メッセージフォーマット、

そしてエラー処理に関する全体的な説明は、TS 24.007 中で与えられる。

1.3 Structure of layer 3 procedures （L3手順の構造）

L3 の手順を説明するために、ビルディングブロック手段が使用される。

基本的なビルディングブロックは、3 つのサブレイヤ（無線リソース管理、モビリティ管理、そしてコネクション管理サブ

レイヤ）のプロトコル制御エンティティが提供する"elementary procedure"である。

L3 の完全なトランザクションは、エレメンタリ手順の特定のシーケンスから成る。「構造化された手順」（"structured procedure"）という用語は、これらのシーケンスを指すために使用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 26

1.4 Test procedures（試験手順） GSM 無線インタフェースシグナリングの試験手順については、GSM 11.10 および GSM 11.2x シリーズ内に記載され

る。

1.5 Use of logical channels（論理チャネルの使用）論理チャネルは、GSM 05.02 で定義される。シグナリング情報または特定のタイプのユーザパケット情報を伝送する

論理チャネルとして、以下のチャネルがある。

i) BCCH(Broadcast Control CHannel)：セル固有の情報をブロードキャストするために使用されるチャネル。下り

リンクのみ。

ii) SCH（Synchronization CHannel ）：同期情報と BSS 識別情報をブロードキャストするために使用されるチャネ

ル。下りリンクのみ。

iii) PCH（Paging CHannel）：MS にページングリクエストを送信するために使用されるチャネル。下りリンクのみ。

iv) RACH（Random Access CHannel）：Dedicated Control CHannel を要求するために使用されるチャネル。上りリ

ンクのみ。

v) AGCH（Access Grant CHannel）：Dedicated Control CHannel を割当てるために使用されるチャネル。下りリン

クのみ。

vi) SDCCH（Standalone Dedicated Control CHannel）：双方向

vii) FACCH（Fast Associated Control CHannel）：Traffic CHannel に関連するチャネル。双方向。

viii) SACCH（Slow Associated Control CHannel）：SDCCH または Traffic CHannel に関連するチャネル。双方向。

ix) CBCH(Cell Broadcast CHannel)：一般的な（point to point でない）ショートメッセージサービス（SMS）に使用さ

れるチャネル。下りリンクのみ。

x) NCH(Notification CHannel)：VBS (Voice Broadcast Service) 呼、または VGCS (Voice Group Call Service) 呼の MS に対して通知するために使用されるチャネル。下りリンクのみ。

シグナリング L2 上では、2 つのアクセスポイントが定義される。これらはそれぞれの SAPI（Service Access Point Identifier）によって識別される（GSM 04.06 参照）。

i) SAPI 0：ユーザ対ユーザ情報を含むシグナリング情報の送信をサポート

ii) SAPI 3：ユーザのショートメッセージ送信をサポート

L3 は、メッセージ毎にそれぞれ必要な、SAP、論理チャネル、そして L2 の運用モード（acknowledged, unacknowledged 、または random access。GSM 04.05 および GSM 04.06 参照）を選択する。

1.6 Overview of control procedures（制御手順概説）

1.6.1 List of procedures（手順のリスト）本技術仕様書内では、以下の手順が規定されている。

a) 第 4 章では、モビリティ管理用のエレメント処理について規定する。

- モビリティ管理共通処理（mobility management common procedure）（4.3 節）

- TMSI 再割当処理（TMSI reallocation procedure）（4.3.1 節）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 27

- 認証処理（authentication procedure）（4.3.2 節）

- 識別処理（identification procedure）（4.3.3 節）

- IMSI デタッチ処理（IMSI detach procedure）（4.3.4 節）

- 中断処理（abort procedure）（4.3.5 節）

- MM 情報処理（MM information procedure）（4.3.6 節）

- モビリティ管理固有の処理（mobility management specific procedure）（4.4 節）

- 位置登録更新処理（location updating procedure）（4.4.1 節）

- 定期的更新（periodic updating）（4.4.2 節）

- IMSI アタッチ処理（IMSI attach procedure）（4.4.3 節）

- 一般的位置登録更新処理（generic location updating procedure）（4.4 節）

- コネクション管理サブレイヤサービスの提供

- MM コネクションの確立（mobility management connection establishment）（4.5.1 節）

- MM コネクション情報送信フェーズ（mobility management connection information transfer phase）（4.5.2節）

- MM コネクションの開放（mobility management connection release）（4.5.3 節）

- GPRS 固有の MM 処理（4.7 節）

- GPRS アタッチ処理（4.7.3 節）

- GPRS デタッチ処理（GPRS detach procedure）（4.7.4 節）

- GPRS RA 更新処理（GPRS routing area updating procedure）（4.7.5 節）

- GPRS 共通モビリティ管理処理（4.7 節）

- GPRS P-TMSI 再配置処理（GPRS P-TMSI reallocation procedure）（4.7.6 節）

- GPRS 認証と暗号化処理（GPRS authentication and ciphering procedure）（4.7.7 節）

- GPRS 識別処理（GPRS identification procedure）（4.7.8 節）

- GPRS 情報処理（GPRS information procedure）（4.7.12 節）

b) 第 5 章では、CS 呼制御用の基本的処理について規定する。以下のような基本的処理が含まれる。

- モバイル発信呼の確立（mobile originating call establishment）（5.2.1 節）

- モバイル着信呼の確立（mobile terminating call establishment）（5.2.2 節）

- アクティブステート中のシグナリング処理（signalling procedures during the active state）（5.3 節）

- ユーザ通知処理（user notification procedure）（5.3.1 節）

- 呼の再配置（call rearrangement）（5.3.2 節）

- DTMF プロトコル制御処理（DTMF protocol control procedure）（5.5.7 節）

- インコール修正（in-call modification）（5.3.4 節）

- MS が開始する呼のクリア（call clearing initiated by the mobile station）（5.4.3 節）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 28

- ネットワークが開始する呼のクリア（call clearing initiated by the network）（5.4.4 節）

- その他の処理

- インバンドトーンとアナウンス（in-band tones and announcement）（5.5.1 節）

- ステータス問い合わせ処理（status enquiry procedure ）（5.5.3 節）

- 呼再確立処理（call re-establishment procedure）（5.5.4 節）

d) 第 6 章では、セッション管理用の基本的処理について規定する。

- GPRS セッション管理処理（6.1 節）

- PDP コンテキストのアクティブ化（6.1.1 節）

- PDP コンテキストの修正（6.1.2 節）

- PDP コンテキストの非アクティブ化（6.1.3 節）

基本的処理は、フォーム構造化処理と組み合わせることもできる。第 7 章で、そのようなフォーム構造化処理の例が

示される。本技術仕様書では、実装をアシストするためのガイダンスを示すに留まる。

第 8 章では、さまざまなエラー条件下で取るべきアクションについて規定し、またプロトコルの将来の拡張に対して互

換性を保証するためのルールについて説明する。

1.7 Applicability of implementations（実装への適用）本技術仕様書の処理の MS に対する適用は、MS がサポートするサービスと機能によって異なる。

1.7.1 Voice Group Call Service (VGCS) and Voice Broadcast Service (VBS) （VGCS （Voice Group Call Service）と VBS(Voice Broadcast Service)）

VGCS （Voice Group Call Service）と VBS(Voice Broadcast Service)は、GSM でのみ適用される。

VGCS と VBS については、それらのサービスのために特定の処理が適用される場合には、それらのサービスをサ

ポートする MS の動作について本技術仕様書内で明示的に言及する。また、それらをサポートしない MS の動作に

ついても必要ならば言及する。

VGCS と VBS については、以下の MS 実装が存在する。

- VBS リスニングをサポートする MS

- VBS 発信をサポートする MS

- VGCS リスニングをサポートする MS

- VGCS トーキングをサポートする MS（この MS は常に VBS リスニングをサポートする）

- VGCS 発信をサポートする MS（この MS は常に VGCS トーキングをサポートする）

明示的に言及される組合せ以外にも、全ての可能な組合せはオプションであり、本技術仕様書によってサポートされ

る。

これらの実装オプションで情報が必要な場合には、本技術仕様書内の関連用語が使用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 29

1.7.2 General Packet Radio Service (GPRS)

1.7.2.1 GSM内のパケットサービス（GSMのみ）

GPRS（General Packet Radio Service）をサポートする MS に関しては、それらのサービスに関して特定の処理が適用

される場合には、技術仕様書で明示的に言及するが、それらのサービスをサポートしない MS の動作についても必

要ならば言及する。

GPRS MS は、以下の MS オペレーションモードのうち、どれか 1 つで運用される。03.60 [74]参照。

- MS operation mode A（MS オペレーションモード A）

- MS operation mode B（MS オペレーションモード B）

- MS operation mode C（MS オペレーションモード C）

MS オペレーションモードは、MS がアタッチされているサービス（GPRS サービスだけ、または GPRS と非 GPRS サー

ビスの両方）と、GPRS とそれ以外の GSM サービスを同時に運用する MS の能力によって決まる。GPRS サービスを

運用するケーパビリティを持つ MS は、GPRS MS と呼ばれる。

NOTE: 他の GSM 技術仕様書では、MS オペレーションモード A,B,C のことを GPRS class-A MS, GPRS class-B MS, GPRS class-C MS と呼ぶ場合もある。

GPRS MS に関しては、ETS 内で現在説明された GMM 処理が VGCS, VBS 、GPRS とのコンビネーションをサポート

しない可能性があることに注意。これらの潜在的なインターアクションについては、検討が必要。

1.7.2.2 UMTS内でのパケットサービス（UMTSのみ）

PS ドメインにアタッチされた MS は、次のいずれかの MS オペレーションモードで運用される。23.060 [74]参照。

- PS/CS モードの運用

- PS モードの運用

「PS/CS モードの運用」と「PS モードの運用」という用語は、原則として本仕様書では使用しない。その代わりに、「MSオペレーションモード A」と「MS オペレーションモード C」という用語が使用される。

ネットワークオペレーションモード I および II（23.060 [74]参照）においては、PS/CS モードで運用される MS は、明示

的に GSM 専用、または UMTS 専用と記載されている場合を除いて、MS オペレーションモード A で運用される

GPRS MS と同一の処理を使用すること。

ネットワークオペレーションモード I および II においては、PS モードで運用される MS は、明示的に GSM 専用、また

は UMTS 専用と記載されている場合を除いて、MS オペレーションモード C で運用される GPRS MS と同一の処理を

使用すること。

NOTE: ネットワークオペレーションモード III は、UMTS には適用されない。23.060 [74]参照。

2 Normative references The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 30

- A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same number.

[1] 3GPP TS 01.02: "Digital cellular telecommunications system (Phase 2+); General description of a GSM Public Land Mobile Network (PLMN)".

[2] 3GPP TS 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms".

[2a] 3GPP TS 21.905 "3G Vocabulary for 3GPP Specifications"

[3] 3GPP TS 22.002: "Digital cellular telecommunications system (Phase 2+); Bearer Services (BS) supported by a GSM Public Land Mobile Network (PLMN)".

[4] 3GPP TS 22.003: "Teleservices supported by a GSM Public Land Mobile Network (PLMN)".

[5] 3GPP TS 02.09: "Digital cellular telecommunications system (Phase 2+); Security aspects".

[6] 3GPP TS 22.011: "Digital cellular telecommunications system (Phase 2+); Service accessibility".

[7] 3GPP TS 02.17: "Digital cellular telecommunications system (Phase 2+); Subscriber identity modules Functional characteristics".

[8] 3GPP TS 02.40: "Digital cellular telecommunications system (Phase 2+); Procedures for call progress indications".

[9] 3GPP TS 03.01: "Digital cellular telecommunications system (Phase 2+); Network functions".

[10] 3GPP TS 23.003: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and identification".

[11] 3GPP TS 03.13: "Digital cellular telecommunications system (Phase 2+); Discontinuous Reception (DRX) in the GSM system".

[12] 3GPP TS 23.014: "Digital cellular telecommunications system (Phase 2+); Support of Dual Tone Multi-Frequency signalling (DTMF) via the GSM system".

[12a] 3GPP TS 23.071: "Digital cellular telecommunications system (Phase 2+); Location Services; Functional description – Stage 2".

[13] 3GPP TS 03.20: "Digital cellular telecommunications system (Phase 2+); Security related network functions".

[14] 3GPP TS 23.122: "NAS Functions related to Mobile Station (MS) in idle mode".

[15] 3GPP TS 24.002: "GSM-UMTS Public Land Mobile Network (PLMN) access reference configuration".

[16] 3GPP TS 04.03: "Digital cellular telecommunications system (Phase 2+); Mobile Station - Base Station System (MS - BSS) interface Channel structures and access capabilities".

[17] 3GPP TS 04.04: "Digital cellular telecommunications system (Phase 2+); layer 1 General requirements".

[18] 3GPP TS 04.05: "Digital cellular telecommunications system (Phase 2+); Data Link (DL) layer General aspects".

[19] 3GPP TS 04.06: "Digital cellular telecommunications system (Phase 2+); Mobile Station - Base Station System (MS - BSS) interface Data Link (DL) layer specification".

[20] 3GPP TS 24.007: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface signalling layer 3 General aspects".

[21] 3GPP TS 24.010: "Digital cellular telecommunications system ; Mobile radio interface layer 3 Supplementary services specification General aspects".

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 31

[22] 3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface".

[23] 3GPP TS 24.012: "Short Message Service Cell Broadcast (SMSCB) support on the mobile radio interface".

[23a] 3GPP TS 24.071: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 location services specification.

[23b] 3GPP TS 04.31 "Digital cellular telecommunication system (Phse 2+);Location Services;Mobile Station (MS) – Serving Mobile Location Centre (SMLC); Radio Resource LCS Protocol (RRLP)".

[24] 3GPP TS 24.080: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 supplementary services specification Formats and coding".

[25] 3GPP TS 24.081: "Digital cellular telecommunications system (Phase 2+); Line identification supplementary services - Stage 3".

[26] 3GPP TS 24.082: "Digital cellular telecommunications system (Phase 2+); Call Forwarding (CF) supplementary services - Stage 3".

[27] 3GPP TS 24.083: "Digital cellular telecommunications system (Phase 2+); Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 3".

[28] 3GPP TS 24.084: "Digital cellular telecommunications system (Phase 2+); MultiParty (MPTY) supplementary services - Stage 3".

[29] 3GPP TS 24.085: "Digital cellular telecommunications system (Phase 2+); Closed User Group (CUG) supplementary services - Stage 3".

[30] 3GPP TS 24.086: "Digital cellular telecommunications system (Phase 2+); Advice of Charge (AoC) supplementary services - Stage 3".

[31] 3GPP TS 24.088: "Call Barring (CB) supplementary services - Stage 3".

[32] 3GPP TS 05.02: "Digital cellular telecommunications system (Phase 2+); Multiplexing and multiple access on the radio path".

[33] 3GPP TS 05.05: "Digital cellular telecommunications system (Phase 2+); Radio transmission and reception".

[34] 3GPP TS 05.08: "Digital cellular telecommunications system (Phase 2+); Radio subsystem link control".

[35] 3GPP TS 05.10: "Digital cellular telecommunications system (Phase 2+); Radio subsystem synchronization".

[36] 3GPP TS 27.001: "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)".

[37] 3GPP TS 29.002: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification".

[38] 3GPP TS 29.007: "Digital cellular telecommunications system (Phase 2+); General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)".

[39] GSM 11.10: "Digital cellular telecommunications system (Phase 2+); Mobile Station (MS) conformity specification".

[40] GSM 11.21: "Digital cellular telecommunications system (Phase 2); The GSM Base Station System (BSS) equipment specification".

[41] ISO/IEC 646 (1991): "Information technology - ISO 7-bit coded character set for information interchange".

[42] ISO/IEC 6429: "Information technology - Control functions for coded character sets".

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 32

[43] ISO 8348 (1987): "Information processing systems - Data communications - Network service definition".

[44] ITU-T Recommendation E.163: "Numbering plan for the international telephone service".

[45] ITU-T Recommendation E.164: "Numbering plan for the ISDN era".

[46] ITU-T Recommendation E.212: "Identification plan for land mobile stations".

[47] ITU-T Recommendation F.69 (1993): "Plan for telex destination codes".

[48] ITU-T Recommendation I.330: "ISDN numbering and addressing principles".

[49] ITU-T Recommendation I.440 (1989): "ISDN user-network interface data link layer - General aspects".

[50] ITU-T Recommendation I.450 (1989): "ISDN user-network interface layer 3 General aspects".

[51] ITU-T Recommendation I.500 (1993): "General structure of the ISDN interworking recommendations".

[52] ITU-T Recommendation T.50: "International Alphabet No. 5".

[53] ITU Recommendation Q.931: ISDN user-network interface layer 3 specification for basic control".

[54] ITU-T Recommendation V.21: "300 bits per second duplex modem standardized for use in the general switched telephone network".

[55] ITU-T Recommendation V.22: "1200 bits per second duplex modem standardized for use in the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits".

[56] ITU-T Recommendation V.22bis: "2400 bits per second duplex modem using the frequency division technique standardized for use on the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits".

[57] ITU-T Recommendation V.23: "600/1200-baud modem standardized for use in the general switched telephone network".

[58] ITU-T Recommendation V.26ter: "2400 bits per second duplex modem using the echo cancellation technique standardized for use on the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits".

[59] ITU-T Recommendation V.32: "A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use on the general switched telephone network and on leased telephone-type circuits".

[60] ITU-T Recommendation V.110: "Support of data terminal equipments (DTEs) with V-Series interfaces by an integrated services digital network".

[61] ITU-T Recommendation V.120: "Support by an ISDN of data terminal equipment with V-Series type interfaces with provision for statistical multiplexing".

[62] ITU-T Recommendation X.21: "Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks".

[63] ITU-T Recommendation X.25: "Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit".

[64] ITU-T Recommendation X.28: "DTE/DCE interface for a start-stop mode data terminal equipment accessing the packet assembly/disassembly facility (PAD) in a public data network situated in the same country".

[65] ITU-T Recommendation X.30: "Support of X.21, X.21 bis and X.20 bis based data terminal equipments (DTEs) by an integrated services digital network (ISDN)".

[66] ITU-T Recommendation X.31: "Support of packet mode terminal equipment by an ISDN".

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 33

[67] ITU-T Recommendation X.32: "Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and accessing a packet switched public data network through a public switched telephone network or an integrated services digital network or a circuit switched public data network".

[68] ITU-T Recommendation X.75 (1988): "Packet-switched signalling system between public networks providing data transmission services".

[69] ITU-T Recommendation X.121: "International numbering plan for public data networks".

[70] ETS 300 102-1: "Integrated Services Digital Network (ISDN); User-network interface layer 3 Specifications for basic call control".

[71] ETS 300 102-2: "Integrated Services Digital Network (ISDN); User-network interface layer 3 Specifications for basic call control".

[72] ISO/IEC10646: "Universal Multiple-Octet Coded Character Set (UCS)"; UCS2, 16 bit coding.

[73] 3GPP TS 22.060: "General Packet Radio Service (GPRS); Service Description; Stage 1".

[74] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2".

[75] 3GPP TS 03.64: "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Overall description of the GPRS radio interface; Stage 2".

[76] 3GPP TS 04.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station - Base Station System (MS-BSS) interface; Radio Link Control and Medium Access Control (RLC/MAC) layer specification".

[77] IETF RFC 1034: "Domain names - Concepts and Facilities " (STD 7).

[78] 3GPP TS 04.65: "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Subnetwork Dependent Convergence Protocol (SNDCP)".

[79] ITU Recommendation I.460: "Multiplexing, rate adaption and support of existing services".

[80] 3GPP TS 26.111: "Codec for Circuit Switched Multimedia Telephony Service; Modifications to H.324"

[81] 3GPP TS 23.107: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; QoS Concept and Architecture"

[82] 3GPP TS 03.22: " Digital cellular telecommunications system (Phase 2+); Functions related to Mobile Station (MS) in idle mode and group receive mode".

2.1 Definitions and abbreviations（定義と略語）本仕様書で使用される略語は、GSM 01.04 中でリストアップされている。

2.1.1 Random values（乱数値）本技術仕様書内で使用される数値のうちいくつかは、特定の範囲内、またはより一般的な統計的分布に従った「乱

数」値を選択する必要があることが記載されている。そのようなケースは MS に関するものだけである。

同一条件下にある 2 つの MS が同一の値を選択する確率は、低いことが要求される（2 つの MS が同一メーカの同

一機種である場合も含む）。さらに、似たような条件下にある 2 つの MS が同一の値を選択した場合、次の機会に両

者が同一の値を選択する確率は、初に異なる値を選択した場合の確率と同一であることが要求される。

そのような仕様の意味するところは、一連の似たようなイベントについて行われる、これらの値に関するあらゆる統計

的試験によって、規定された分布を統計的に満たす結果が得られることを意味する。考えられるイベントのサブセット

といっしょに試験が行われる場合でも、いくつかの共通パラメータとともに、この要求条件は維持されること。さらにシ

リーズ内の数値とは独立した基本試験もパスすること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 34

値と相関のあるデータがあってはならないのは、プロトコルステート、IMSI、識別子、ネットワークによってブロードキ

ャストされるその他の無関係な情報、現行の TDMA フレーム番号などである。

2.2.2 Vocabulary（用語）本仕様書では、以下の用語が使用される。

- GSM security context（（（（GSM セキュリティコンテキスト）：セキュリティコンテキスト）：セキュリティコンテキスト）：セキュリティコンテキスト）：GSM の認証チャレンジが成功すると、GSM セキュリ

ティコンテキストが MS とネットワーク間で確立されて双方に保存される。GSM セキュリティコンテキストは、

GSM 暗号鍵と暗号鍵シーケンス番号から構成される。

- UMTS security context（（（（UMTS セキュリティコンテキスト）：セキュリティコンテキスト）：セキュリティコンテキスト）：セキュリティコンテキスト）：UMTS の認証チャレンジが成功すると、UMTS セ

キュリティコンテキストが MS とネットワーク間で確立されて双方に保存される。UMTS セキュリティコンテキス

トは、UMTS 暗号鍵、UMTS 完全鍵、GSM 暗号鍵、および暗号鍵シーケンス番号から構成される。

- idle mode（アイドルモ（アイドルモ（アイドルモ（アイドルモード）：ード）：ード）：ード）：アイドルモードにある MS には個別チャネルは割当てられず、MS は CCCH と

BCCH をリスニングする。

- group receive mode（グループ受信モード）：（（グループ受信モード）：（（グループ受信モード）：（（グループ受信モード）：（VGCS リスニングまたは VBS リスニングをサポートする MS に

のみ適用）本モードでは、ネットワークから MS に個別チャネルは割当てられず、セルに対して割当てられた

音声ブロードキャストチャネルまたは音声グループコールチャネルの下りリンクをリスニングする。まれに

TS 03.22 および 05.08 に仕様化されるように、MS がサービスセルの BCCH をリスニングする必要がある場

合もある。

- dedicated mode（個別モード）：（個別モード）：（個別モード）：（個別モード）：このモードでは、MS に対して低限 2 つの個別チャネルが割当てられる。そ

のうちの 1 つは SACCH である。

- group transmit mode（グループ送信モード）（グループ送信モード）（グループ送信モード）（グループ送信モード）:（VGCS トーキングをサポートする MS にのみ適用）本モードで

は、音声グループ呼に参加する MS1 つに対して、2 つの個別チャネルが割当てられる。そのうちの 1 つは

SACCH である。これらのチャネルは、音声グループ呼の間、1 つの MS にだけ割当てることができる。同時に

複数の MS に割当てることはできない。

- packet idle mode（パケットアイドルモード）：（パケットアイドルモード）：（パケットアイドルモード）：（パケットアイドルモード）：（GPRS をサポートする MS にのみ適用）本モードでは、MS に対し

てパケットデータ物理チャネル上の無線リソースは割当てられない。MS は、PBCCH と PCCCH をリスニング

するか、あるいはそれらのチャネルがネットワークによって提供されない場合には、BCCH と CCCH をリスニ

ングする。GSM 04.60 参照。

- packet transfer mode: (パケット送信モードパケット送信モードパケット送信モードパケット送信モード): （GPRS をサポートする MS にのみ適用）。MS に対して 1 つまた

は複数のパケットデータ物理チャネル上のリソースが割当てられ、LLC PDU の送信に使用される。

- main DCCH（メイン（メイン（メイン（メイン DCCH））））:個別モードおよびグループ送信モードにおいては、DCCH として使用されるチャ

ネルは 2 つだけである。1 つは SACCH、残る 1 つは SDCCH または FACCH である。ここでは SDCCH また

は FACCH を「メイン DCCH」と呼ぶ。

- チャネルは、低限 UI フレームといっしょに送信に使用可能な状態になったとき、特にシグナリングの送信が

可能な状態になったとき、アクティブ化アクティブ化アクティブ化アクティブ化される。SACCH 上でアクティブ化された場合には、L2 フレームの隣接

ストリームが送信可能でなくてはならない。

- 回線交換モードのユーザデータが送信可能になった場合、TCH がコネクトコネクトコネクトコネクトされる。TCH がアクティブにならな

い限り、コネクトすることはできない。アクティブ化されているもののコネクトされていない TCH は、シグナリン

グにのみ使用できる。つまり、DCCH として使用される。

- メイン DCCH 上の SAPI 0 のデータリンクを、メインシグナリングリンクメインシグナリングリンクメインシグナリングリンクメインシグナリングリンクと呼ぶ。メインシグナリングリンク上で送

信するように規定されたメッセージは、特に規定されない限り送達確認モードで送信される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 35

- リンクを"establish"（（（（確立する確立する確立する確立する））））という用語は、データリンク上で"to establish the multiframe mode"（（（（マルチフマルチフマルチフマルチフ

レームモードを確立するレームモードを確立するレームモードを確立するレームモードを確立する））））という言葉の短縮形である。たとえリンクが確立されていなくとも、対応するチャネル

がアクティブ化されれば直ちにデータリンク上で UI フレームを送信することは可能である。特に他で通知され

ない限り、データリンクレイヤは情報フィールドなしで確立される。

- "channel set"（チャネルセット）：（チャネルセット）：（チャネルセット）：（チャネルセット）："channel set"（チャネルセット）は、例えば回線交換コネクションをサポートす

るために使用されるマルチスロットコンフィギュレーション内のユーザ情報フロー（これらは同時に処理する必

要がある）が、どの TCH で運ばれるのかを識別するために使用される。

- TBF（（（（temporary block flow ）（テンポラリブロックフロー）：）（テンポラリブロックフロー）：）（テンポラリブロックフロー）：）（テンポラリブロックフロー）：パケットデータ物理チャネル上で、LLC PDU の一

方向の送信をサポートするために、2 つの RR ピアエンティティが使用する物理的コネクション。GSM 04.60 参

照。

- RLC/MAC block（（（（RLC/MAC ブロック）ブロック）ブロック）ブロック）: RLC/MAC エンティティ間で交換されるプロトコルデータユニット。

GSM 04.60 参照。

- GMM context （（（（GMM コンテキスト）コンテキスト）コンテキスト）コンテキスト）：GPRS アタッチ処理が正常完了すると、GMM コンテキストが確立され

る。

- Network operation mode（ネットワークオペレーションモード）（ネットワークオペレーションモード）（ネットワークオペレーションモード）（ネットワークオペレーションモード）

ネットワークオペレーションモード I, II, III の相違については、TS 23.060 [74]中で定義される。

ネットワークのオペレーションモードは、システム情報として通知されること。適切なオペレーションのために、1 つの

RA（Routing Area）内の各セルについて、ネットワークオペレーションモードは同一とすること。

- GPRS MS オペレーションモードオペレーションモードオペレーションモードオペレーションモード

TS 23.060 [74]において、3 種類の異なる GPRS MS オペレーションモード A,B,C が定義されている。

- RR connection（（（（RR コネクション）：コネクション）：コネクション）：コネクション）：RR コネクションとは、個別物理的回線交換ドメインのコネクションであり、2つの RR または RRC ピアエンティティが上位レイヤの情報フローの交換をサポートするために使用する。

- PS signalling connection（（（（PS シグナリングコネクション）：シグナリングコネクション）：シグナリングコネクション）：シグナリングコネクション）：MS と CN パケットドメインモード間の peer to peer のUMTS コネクション

- Inter-System change（システム間変更）：（システム間変更）：（システム間変更）：（システム間変更）：GSM と UMTS のような異なる無線アクセステクノロジ間にまたがる

無線アクセスの変更

- GPRS：：：：GSM および UMTS システム用パケットサービス

- 表記「表記「表記「表記「GSM のみ」のみ」のみ」のみ」：その節または段落が、GSM システムにのみ適用されることを示す。マルチシステムの場

合には、現在サービスを提供している RAN（radio access network）によって決まる。

- 表記「表記「表記「表記「UMTS のみ」のみ」のみ」のみ」：その節または段落が、UMTS システムにのみ適用されることを示す。マルチシステムの

場合には、現在サービスを提供している RAN によって決まる。

- 「GSM ではではではでは,...」：」：」：」：その段落が、GSM システムにのみ適用されることを示す。マルチシステムの場合には、現在

サービスを提供している RAN によって決まる。

- 「UMTS でででではははは,...」：」：」：」：その段落が、UMTS システムにのみ適用されることを示す。マルチシステムの場合には、

現在サービスを提供している RAN によって決まる。

- SIM（（（（Subscriber Identity Module）（TS GSM 02.17 参照）：本仕様書では、SIM と USIM の区別をしない。

- MS（（（（Mobile Station）：本仕様書では MS と UE の区別をしない。

- Cell Notification（（（（セル通知セル通知セル通知セル通知）：）：）：）：セル更新処理の（適化された）改良型。READY タイマの再開をトリガしない

セル変更通知用の LLC NULL フレームを使用する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 36

3 Radio Resource management procedures （無線リソース管理手順）

04.18 参照

4 Elementary procedures for Mobility Management （モビリティ管理用の基本的処理）

4.1 General（概要）本節では、無線インタフェース（リファレンスポイント Um および Uu）において、非 GPRS サービスおよび GPRS サー

ビス用のモビリティ管理に使用される処理手順について説明する。

MM（Mobility Management ）サブレイヤの主な機能は、ユーザ端末のモビリティ（移動）のサポートであり、ネットワー

クに MS の現在位置を通知したり、ユーザアイデンティティの機密を提供する。

それ以外の MM サブレイヤの機能として、上位の CM （Connection Management）サブレイヤ（TS 24.007 参照）の異

なるエンティティに対して、コネクション管理サービスを提供することが挙げられる。

本章では、2 組の処理が定義される。

- 非 GPRS サービス用の MM 処理（MM サブレイヤの MM エンティティが実行）

- GPRS サービス用の GMM 処理（MM サブレイヤの GMM エンティティが実行）、TS 24.007 [20]参照。

本節で説明される MM 処理は全て、MS とネットワーク間で RR コネクションが既に確立されている場合のみ、実行

可能である。それ以外の場合には、MM サブレイヤは RR コネクションの確立を開始しなくてはならない（GSM 04.18 の 3.3 節および TS 25.331 の 8.2.3 節参照）。本節で説明される GMM 処理は、先立って RR コネクションが確立さ

れることなく、RR サブレイヤによって提供されるサービスを使用する。

GMM 処理は、GPRS MS とそれらの MS をサポートするネットワークに対してのみ適用され、必須である。GPRS および非 GPRS サービス用に IMSI がアタッチされた GPRS MS については、いくつかの MM 処理の代わりに、ネット

ワークオペレーションモード I で運用されるネットワーク（つまり複合 GMM 処理をサポートするネットワーク）によって

提供される複合 GMM 処理が適用される。GMM 複合処理は、オペレーションモード C の GPRS MS には適用され

ないが、オペレーションモード A および B の GPRS MS と、ネットワークオペレーションモード I をサポートするネット

ワークに対しては適用される。TS 23.060 参照。

4.1.1 MM and GMM procedures（MMおよび GMM処理）

4.1.1.1 Types of MM and GMM procedures（MM処理および GMM処理のタイプ）

開始方法によって、MM 処理は 3 種類に区別される。

1) MM common procedures （MM 共通処理）：

MM 共通処理は、RR コネクションが存在するときに限り、いつでも開始することができる。このタイプに属する

処理としては、以下のものがある。

ネットワーク側が開始する処理:

- TMSI 再配置処理

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 37

- 認証処理

- 識別処理

- MM 情報処理

- 中断処理

ただし、中断処理は既に MM コネクションが確立されている場合のみ、使用される。つまり、MM 固有

の処理または IMSI デタッチ処理の間は使用できない。4.3.5 節参照。

MS 側が開始する処理:

- IMSI デタッチ処理 (4.3.4 節で規定される例外を除く)

ii) MM specific procedures（MM 固有処理）:

MM 固有処理は、他の MM 固有処理が開始されていない場合、または MM コネクションが存在しない場合

のみ、開始できる。このタイプに属する処理としては、以下のものがある。

- 通常の位置更新処理

- 定期的更新処理

- IMSI アタッチ処理.

iii) MM connection management procedures（MM コネクション管理処理）:

これらの処理は、MS とネットワーク間の MM コネクションを確立・維持・解放するために使用され、これらの処理を

通じて上位 CM レイヤのエンティティはそのピアと情報を交換できる。MM コネクションは、MM 固有処理が開始され

ていない場合のみ、MM コネクション確立処理を実行することができる。同時の複数の MM コネクションをアクティブ

にすることもできる。開始方法によって、GMM 処理は次の 2 つのタイプに分類される。

i) GMM common procedures（GMM 共通処理）:

GMM コンテキストが既に確立されている場合に、ネットワークが開始：

- P-TMSI （再）割当

- GPRS の認証と暗号化

- GPRS 識別

- GPRS 情報.

ii) GMM specific procedures（GMM 固有処理）:

GPRS サービスおよび／または非 GPRS サービスのために、ネットワーク内の IMSI をデタッチし、

GMM コンテキストを解放するために、ネットワーク側が開始して使用する処理には次のものがある：

- GPRS デタッチ

GPRS サービスおよび／または非 GPRS サービスのために、ネットワーク内の IMSI をデタッチし、

GMM コンテキストを確立または解放するために、MS 側が開始して使用する処理には次のものがある：

- GPRS アタッチおよび複合 GPRS アタッチ

- GPRS デタッチおよび複合 GPRS デタッチ

GMM コンテキストが既に確立されている場合に、MS が開始する処理には次のものがある:

- 通常の RA 更新および複合 RA 更新

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 38

- 定期的 RA 更新

UMTS では、ネットワークに安全なコネクションを確立するためおよび／またはデータ送信用リソースを

要求するために、MS が開始して使用する処理には次のものがある:

- サービスリクエスト

4.1.1.1.1 Integrity Checking of Signalling Messages in the Mobile Station (UMTS only) （MS内の署名メッセージの完全性確認（UMTSのみ））

UMTS に限り、緊急呼の例外を除いて、完全性保護された署名が必須である（4.1.1.1.1a 参照）。UMTS に限り、いっ

たんネットワークと MS 間でセキュリティモードの手順が正常に確立されたならば、それ以降全ての L3 プロトコルは

完全性保護されたシグナリングを使うこと。L3 のシグナリングメッセージの完全性保護は、下位のレイヤが行う。完

全性保護をアクティブにするのはネットワーク側であり、セキュリティモード制御手順を使用して行われる(TS 25.331参照)。

完全保護がアクティブになっていることを監視するのは MS 内の MM と GMM レイヤの責任で行われる。（TS 33.102 参照）。それを実現するために、下位のレイヤは、MM レイヤと GMM レイヤに対して、MS 内で完全性保護

がアクティブになった場合に通知する（つまり、CS ドメインのセキュリティモード制御処理が正常に終了したときには

MM レイヤに対して通知し、PS ドメインのセキュリティモード制御処理が正常に終了したときには GMM レイヤに対し

て通知する）。

ネットワーク内の CS ドメインおよび PS ドメインと、MS 内の MM レイヤおよび GMM レイヤは、他のドメインが下位

レイヤ内で完全性保護が開始したか否かを認識しない。ネットワークが、CS ドメインと PS ドメインに対してそれぞれ

１つのセキュリティモード制御処理を開始することは必須条件（mandatory）である。

全ての MM/GMM 管理が完全性保護されているわけではない。であるから、MS の MM/GMM エンティティは、以下

の MM/GMM メッセージを受信した場合には、MS 内の下位レイヤ内で該当ドメイン用のセキュリティモード制御処

理がアクティブになる前に、メッセージを受理すること。

- MM messages（MM メッセージ）:

- AUTHENTICATION REQUEST

- AUTHENTICATION REJECT

- IDENTITY REQUEST

- LOCATION UPDATING ACCEPT (at periodic location update with no change of location area or temporary identity)

- LOCATION UPDATING REJECT

- CM SERVICE REJECT

- ABORT

- GMM messages（GMM メッセージ）:

- AUTHENTICATION & CIPHERING REQUEST

- AUTHENTICATION & CIPHERING REJECT

- IDENTITY REQUEST

- ATTACH REJECT

- ROUTING AREA UPDATE ACCEPT (at periodic rouoting area update with no change of routing area or temporary identity)

- ROUTING AREA UPDATE REJECT

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 39

- - SERVICE REJECT

- DETACH ACCEPT (for non power-off)

上記以外の MM/GMM シグナリングメッセージは、該当ドメインのセキュリティモード制御処理がアクティブにならな

い限り、受信した MM および GMM エンティティで処理されてはならない。その上、（これらのメッセージを）受信した

MS 内の MM および GMM エンティティは、該当ドメイン用のセキュリティモード制御処理がアクティブになるまでは、

CM レイヤメッセージを CM サブレイヤに転送してはならない。

完全性保護がアクティブになったならば、（メッセージを）受信した MS 内の L3 エンティティは、下位レイヤによってメ

ッセージの完全性チェックが正常に終了するまでは、それ以外の L3 シグナリングメッセージを処理してはならない。

完全性チェックが正常に完了していないそれ以外のメッセージを受信したならば、MS 内の下位レイヤはこれらのメッ

セージを廃棄すること（TS 25.331 参照）。PS もしくは CS ドメイン内で、任意の L3 シグナリングメッセージを受信した

場合、たとえネットワーク内の該当ドメインによって MS 内で完全性保護がアクティブにされていたしても、それらのメ

ッセージの完全性が保護されているわけではないので、下位レイヤはそのメッセージを廃棄すること（TS 25.331 参

照）。

ネットワーク側の完全性チェックは、TS 25.331 で説明されている通り、RNC が行う。

4.1.1.1.1a Integrity protection for emergency call (UMTS only) （緊急呼の完全性保護（UMTSのみ））

その他の MM コネクションが確立されていない場合の緊急呼の MM コネクション確立（例えば、SIM カードなしで緊

急呼が確立された場合、他の MM コネクションは存在できない）、CN は完全性保護をアクティブにするために CS ド

メイン用のセキュリティモード制御処理を開始する必要はない。

その他の MM コネクションが確立されていない場合の緊急呼の MM コネクション確立については、MS 内の MM レ

イヤは MS 内で完全性保護がアクティブになっているか否かを監視する必要はない。

既に 1 つまたは複数の MM コネクションが確立されている場合の、緊急呼用の MM コネクションの確立については、

完全性保護が既にネットワークによってアクティブになっている。

4.1.1.2 MM-GMM co-ordination for GPRS MS's （GPRS MS 用の MM～GMM間のコーディネーション）

4.1.1.2.1 GPRS MS operating in mode A or B in a network that operates in mode I （ネットワークオペレーションモード Iのネットワーク内の、MSオペレーションモード A / Bの GPRS MS）

モード I でオペレーションされているネットワーク内で、GPRS MS がモード A または B で運用されており、かつ GPRS および非 GPRS サービス用に IMSI が同時にアタッチされているときは、GPRS MS は、対応する MM 固有の IMSIアタッチ処理および通常の定期的 LA 更新処理の代わりに、複合定期的 RA 更新処理処理を使用すること。

NOTE: モード I でオペレーションされているネットワーク内で、mode A または B で運用されている GPRS MSは、ATT フラグの値に関わらず、複合 GPRS アタッチ処理または RA 更新処理を実行すること。

モード I でオペレーションされているネットワーク内で、モード A または B で運用されている GPRS MS の場合、

GMM は複合 GPRS デタッチ処理を使用して IMSI デタッチを実行すること。

NOTE: モード I でオペレーションされているネットワーク内で、モード A または B でオペレーションされている

GPRS MS は、ATT フラグの値にかかわらず、複合 GPRS アタッチ処理を実行すること。

モード I でオペレーションされているネットワーク内で、モード A または B でオペレーションされている GPRS MS は、

MM 固有の処理の箇所で複合 GMM 固有の処理を使用する。であるから、4.3 節および 4.4 節でリストアップされて

いる MM 固有の処理をトリガする条件は、どれも適用してはならない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 40

モード I でオペレーションされているネットワーク内で、モード A または B でオペレーションされている GPRS MS は、

いくつかのエラーまたは異常なケースを除いて、MM 固有の処理に関連する全ての MM タイマ(例えば T3210, T3211, T3212, T3213)を使用してはならない。MM タイマが既に起動されている場合には、MS はたとえタイマ満了し

ても反応してはならない。

NOTE: GMM が複合 GMM 処理を実行する場合には必ず、MM が位置登録更新処理を実行することがない

ように、GPRS MS は MM ステート MM LOCATION UPDATING PENDING に入る。

MM が行った認証処理がネットワーク側で拒否された場合（例えば AUTHENTICATION REJECT を受信した場合

など）、MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し、可能ならば保存されている P-TMSI, P-TMSI 署名、 RAI、GPRS 暗号鍵シーケンス番号を削除すること。MS の電源が切断されるまで、または

SIM カードが抜かれるまで、SIM カードは GPRS および非 GPRS サービスについて無効と見なすこと。MS は全ての

GMM 処理を中断し、ステート GMM-DEREGISTERED に入ること。

4.1.1.2.2 GPRS MS operating in mode A or B in a network that operates in mode II or III （ネットワークオペレーションモード II ／ IIIのネットワーク内の、MSオペレーションモード A／ Bの GPRS MS）

モード II または III でオペレーションされているネットワーク内で、モード A または B で運用されている GPRS MS が、

GPRS および非 GPRS サービス用に同時に IMSI をアタッチしようとした、またはアタッチする必要がある場合には、

GPRS MS は 4.3 節および 4.4 節でリストアップされた MM 固有の処理と、4.7.3 節, 4.7.4 節,および 4.7.5 節でリストア

ップされた GMM 固有の処理を使用すること。定期的位置更新の適用については 4.4.2 節で、定期的 RA 更新の適

用については 4.7.2.2 節で規定されている。

MM が実行した認証処理がネットワーク側で拒否された場合（例えば AUTHENTICATION REJECT を受信した場

合など）には、MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し、可能ならば保存された

P-TMSI, P-TMSI 署名、 RAI、GPRS 暗号鍵シーケンス番号を削除すること。MS の電源が切断されるまで、または

SIM カードが抜かれるまで、SIM カードは GPRS および非 GPRS サービスについて無効と見なすこと。MS は全ての

GMM 処理を中断し、ステート GMM-DEREGISTERED に入ること。

4.1.1.3 Core Network System Information for MM (UMTS only) （MM用の Core Network System Information（UMTSのみ））

ネットワークブロードキャストシステム情報の中には、MM が使用するシステム情報が含まれる。

新しいシステム情報を受信した場合、MS 内の RRC レイヤは、MS 内の MM レイヤに対して、CN 共通システム情報

の内容と CS ドメイン固有の情報を配信する。

Core Network System Information は、RRC メッセージ内の特別な情報エレメント内に入れられて、MS に対して送信

される。TS 25.331 参照。Core Network System Information 内の共通システム情報パートと CS ドメイン固有システム

情報パートには、MM の機能を制御するためのパラメータ設定が含まれる。MM メッセージ内には Core Network System Information は含まれない。

4.1.1.4 Core Network System Information for GMM (UMTS only) （GMM用の Core Network System Information（UMTSのみ））

ネットワークブロードキャストシステム情報の中には、GMM が使用するシステム情報が含まれる。

新しいシステム情報を受信した場合、MS 内の RRC レイヤは、MS 内の GMM レイヤに対して、CN 共通システム情

報の内容と PS ドメイン固有の情報を配信する。

Core Network System Information は、RRC メッセージ内の特別な情報エレメント内に入れられて、MS に対して送信

される。TS 25.331 参照。Core Network System Information 内の共通システム情報パートと PS ドメイン固有システム

情報パートには、GMM の機能を制御するためのパラメータ設定が含まれる。GMM メッセージ内には Core Network System Information は含まれない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 41

4.1.2 MM sublayer states（MMサブレイヤのステート）以下に MM サブレイヤのステートに関する説明をまとめる。MS 側のメインステートと、関連する処理については、

4.1.2.1.1 節で説明する。MM IDLE ステートは、MM IDLE 内での動作を説明するするためにさらにサブステートに分

類される（4.1.2.1.2 節参照）。この動作は、4.1.2.2 節で説明される更新ステータスに依存する。ネットワーク側のステ

ートについては、4.1.2.3 節で説明される。

4.1.2.1 MM sublayer states in the mobile station （MS内の MMサブレイヤステート）

本節では、MS 内の MM サブレイヤにおいて想定されるステートについて説明する。MM サブレイヤプロトコルの概

要については、TS 24.008 の図 4.1 参照。

4.1.2.1.1 Main states（メインステート）

0 NULL

MS がインアクティブ（電源が切断されている、など）。重要なパラメータは保存される。ユーザによる手動

アクションによってのみ、MM サブレイヤは他のステートに移行可能。

3 LOCATION UPDATING INITIATED

位置登録更新処理が開始され、MM はネットワークからの応答を待つ。タイマ T3210 が起動している。

5 WAIT FOR OUTGOING MM CONNECTION

MM コネクションの確立が開始され、MM はネットワークからの応答を待つ。タイマ T3230 が起動している。

6 MM CONNECTION ACTIVE

MM サブレイヤは、ネットワーク側のピアエンティティと RR コネクションを持つ。1 つまたは複数の MM コ

ネクションがアクティブ。

7 IMSI DETACH INITIATED

IMSI デタッチ処理が開始され、タイマ T3220 が起動している。

8 PROCESS CM SERVICE PROMPT

MM サブレイヤは、ネットワーク側のピアエンティティと RR コネクションを持つ。MS は CM SERVICE PROMPT メッセージを受信したが、まだ$(CCBS)$を応答していない。

9 WAIT FOR NETWORK COMMAND

MM のサブレイヤは、ネットワーク側のピアエンティティと RR コネクションを持つが、MM コネクションは確

立されていない。MS は受動的であり、ネットワークからのコマンドを待っている状態。タイマ T3240 が起動

される場合もある。

10 LOCATION UPDATE REJECTED

位置登録更新処理が拒否され、RR コネクション開放を待つ状態。タイマ T3240 が起動している。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)

Release 1999

42

Attach or Locationupdate needed

Attach and Locationupdate not needed

RR connectionestablished

Locationupdate reject

Location updateaccept

RR connection released

New LAI, connection requestor T3212/T3211 timeout

MS deactivatedand attach NOT

allowed

MM-connectionrequest


First messagereceived

Last connectionreleased

Low layer failureand reestablish

RR connectionestablished(paging)

MS deactivatedand attachallowed

MS deactivated andattach allowed


RR connectionreleased

low layerfailure

Low layer failureand reestablish

Reestablishnot possible

update SIM

States 6,20

Send IMSIdetach

RequestRR connection

Send cmreestablish

request

IndicateMM connection

Send cm servicerequest

ConfirmMM connection

Send cm servicerequest


Update SIM

Store system info

Delete system info

Send locationupdate request


Activate RR

IMSI DETACHINITIATED

7

WAIT FORREESTABLISH

17MM CONNECTION

ACTIVE

6

WAIT FORRR CONNECTION(IMSI DETACH)

15

WAIT FOROUTGOING

MM CONNECTION

5

WAIT FORRR CONNECTION

(MM CONNECTION)

14

LOCATION UPDATINGINITIATED

3

LOCATION UPDATEREJECTED

10WAIT FOR

RR CONNECTION(LOCATION UPDATE)

13

WAIT FORRR ACTIVE

18NULL

States 3, 5, 9,10, 13, 14, 15

CM reestablish-ment accepted

WAIT FOR NETWORKCOMMAND

9

SIMinserted

MSactivated

Deletesysteminfo !!low layer failure and

no reestablish

CM serviceaccept

MM-IDLE19

Ciphering startedor CM service

accept

MM connectionrequest

WAIT FORADDITIONALOUTGOING

MM CONNECTION

20

RR connectionreleased

.

図図図図4.1a / TS 24.008: M

Mプロトコル

の概

要（

プロトコル

の概

要（

プロトコル

の概

要（

プロトコル

の概

要（M

S側）

側）

側）

側）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 43

RR gone toGroup Transmitmode

21MM CONNECTION

ACTIVE(Group TX MODE )

22WAIT FOR RRCONNECTION

(Group TX MODE )

RR Connection

established

6MM CONNECTION

ACTIVE

19MM-IDLE

5WAIT FOR

OUTGOINGMM CONNECTION

Send CM servicerequest

orNotification Response

RR gone toDedicated

mode

Uplinkrelease Uplink

accessrejected

Uplinkaccess

requested

RR connectionreleased, gone

to group receiveMode

RR connectionreleased, gone

to Group Receivemode

付図付図付図付図 4.1.a/TS 24.008

13. WAIT FOR RR CONNECTION (LOCATION UPDATING)

MM サブレイヤが位置登録更新処理を開始するために RR コネクション確立を要求した状態

14. WAIT FOR RR CONNECTION (MM CONNECTION)

MM サブレイヤが MM コネクションを確立するために、個別モード用に RR コネクション確立を要求した状

態

15. WAIT FOR RR CONNECTION (IMSI DETACH)

MM サブレイヤが IMSI デタッチ処理を開始するために RR コネクション確立を要求した状態

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 44

17. WAIT FOR REESTABLISH

下位レイヤでエラーが発生し、中断された CM レイヤのエンティティから再確立要求がある可能性がある

状態

18. WAIT FOR RR ACTIVE

MM サブレイヤが RR サブレイヤのアクティブ化を要求した状態

19. MM IDLE

この状態では、MM 処理は起動されておらず、RR サブレイヤが Group Receive モードにあってローカルな

MM コンテキストが存在する場合を除いて、RR コネクションも存在しない。本ステートは複合ステート

（compound state）であり、Connection Management 要求に対する MS の具体的動作は後述する実際のサ

ブステートによって決まる。

20. WAIT FOR ADDITIONAL OUTGOING MM CONNECTION.

追加的な MM コネクション用の MM コネクションが開始されて、MM がネットワークからの応答を待ってい

る状態

21. MM CONNECTION ACTIVE (GROUP TRANSMIT MODE)

（VGCS トーキングをサポートする MS にのみ適用：）MM サブレイヤが、ネットワーク側のピアエンティティ

に対する RR コネクションを VGCS チャネル上で確立した状態。MM コネクションだけがアクティブ。

22. WAIT FOR RR CONNECTION (GROUP TRANSMIT MODE)

（VGCS トーキングをサポートする MS にのみ適用：）MM サブレイヤが VGCS チャネル上で上りリンクアク

セス実行を要求した状態

23. LOCATION UPDATING PENDING

（オペレーションモード A と B の GPRS MS にのみ適用；図 4.1a には示されない：）複合 GPRS RA 更新処

理を使用して位置登録更新処理が開始された状態

24. IMSI DETACH PENDING

（オペレーションモード A と B の GPRS MS にのみ適用；図 4.1a には示されない：）電源が入っている状態

で、複合 GPRS デタッチ処理を使用して、非 GPRS サービス用の IMSI デタッチが開始された状態

4.1.2.1.2 Substates of the MM IDLE state（MM IDLEステートのサブステート）

MS の動作を説明するために、MM IDLE ステートは複数のサブステートに分割される。これらのサブステートはサー

ビスステートとも呼ばれる。サービスステートは MS 全体に関するものである（SIM カードが挿入されていない ME 単

体、または ME＋SIM カード）。サービスステートは更新ステータスに依存し（4.1.2.2 節参照）、選択されたセルに依

存する。

19.1 NORMAL SERVICE

有効な加入者データが利用可能であり、更新ステータスは U1。セルは加入者が登録されている LA に属

するセルから選択される。

本ステートでは、CM レイヤからの全ての要求は通常通り処理される。

19.2 ATTEMPTING TO UPDATE

有効な加入者データが利用可能であり、更新ステータスは U2。上位レイヤからの要求は受け入れられる。

緊急呼の要求は通常通り処理されるが、要求はまず選択されたセル内の位置登録更新試行をトリガし、

次に位置登録更新が成功した場合にのみ必要な処理をトリガする。それ以外の要求は拒否される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 45

19.3 LIMITED SERVICE

有効な加入者データが利用可能であり、更新ステータスは U3。通常のサービスを提供できないことが既

知であるセルが選択された状態。緊急呼サービスだけが提供される。

19.4 NO IMSI

有効な加入者データなし（SIM カードなし、または挿入された SIM カードが無効と ME が判断した場合な

ど）、かつセルが選択されている状態。緊急呼サービスだけが提供される。

19.5 NO CELL AVAILABLE

セルが選択できない状態。初の集中的な（intensive）セルサーチが失敗した後、本ステートに入る（ステ

ート 19.7）。セルは低頻度でサーチされる。サービスは何も提供されない。

19.6 LOCATION UPDATE NEEDED

有効な加入者データが利用可能であり、何らかの理由（更新ステータスが U1 なのにも関わらず選択され

たセルが LA に登録されていなかったり、タイマが満了した場合など）によって、位置登録更新をできるだ

け早く行う必要がある状態。本ステートは通常は長期間持続しないが、例えばアクセスクラスがブロックさ

れた場合などは、長期間持続することもありうる。

19.7 PLMN SEARCH

MS は PLMN をサーチし、ステート 19.8 に合致しなかった状態。セルが選択される（この場合の新しいス

テートは 19.1, 19.3,または 19.6）か、一定期間は利用可能なセルがないと結論された場合（この場合の新

しいステートは 19.5）には、本ステートは終了する。

19.8 PLMN SEARCH, NORMAL SERVICE

有効な加入者データが利用可能であり、ステータスが U1 に更新され、加入者が登録されている LA に属

するセルが選択され、MS は PLMN をサーチする。セルが選択される（この場合の新しいステートは 19.1, 19.3,または 19.6）か、一定期間は利用可能なセルがないと結論された場合（この場合の新しいステートは

19.5）には、本ステートは終了する。

19.9 RECEIVING GROUP CALL (NORMAL SERVICE)

VGCS リスニングまたは VBS リスニングをサポートする MS にのみ適用されるステート。有効な加入者デ

ータが利用可能であり、ステータスが U1 に更新され、加入者が登録されている LA に属するセル内で

VGCS チャネルまたは VBS チャネルを受信する状態。

本ステートでは、GCC レイヤまたは BCC レイヤからの要求だけが処理される。

19.10 RECEIVING GROUP CALL (LIMITED SERVICE)

VGCS リスニングまたは VBS リスニングをサポートする MS にのみ適用されるステート。有効な加入者デ

ータが利用可能であり、ステータスが U3 に更新され、通常のサービスを提供できないことが分かっている

セル内で VGCS チャネルまたは VBS チャネルを受信する状態。

本ステートでは、VGCS 呼または VBS 呼を受け付けるための GCC レイヤまたは BCC レイヤからの要求

だけが処理され、グループ呼緊急サービスが提供される。

4.1.2.2 The update Status（更新ステータス）

4.1.2.1 節で説明された MM サブレイヤプロトコルを制御するためのサブレイヤのステートと対応して、更新ステータ

ス（update status）が存在する。

更新ステータスは、特定の加入者に関するステートであり、SIM カード内に統合される。本ステータスは、たとえ加入

者がアクティブでない場合（SIM カードが抜かれた場合や、電源が切られた ME に挿入された場合など）にも定義さ

れる。本情報は SIM カードの不揮発性メモリーの保存される。更新ステータスは位置登録更新処理が試行された場

合のみ、変更される（認証が失敗した場合や CM サービスが拒否された場合を除く）。いくつかのケースでは、GPRS

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 46

アタッチ、GPRS RA 更新、サービスリクエスト、またはネットワーク側が開始した GPRS デタッチ処理の結果として、

更新ステータスが変更される。

U1 UPDATED

直前の位置登録更新試行が正常終了（正当な処理出力、応答がネットワークによって受理）。本ステート

において、SIM カードには加入者が登録されている LA の LAI が保存され、さらに有効な TMSI, GSM 暗

号鍵、UMTS 完全鍵、UMTS 暗号鍵、そして暗号鍵シーケンス番号を保存することも可能。SIM カード上

に保存されている"Location update status"は、"updated"に設定すること。

U2 NOT UPDATED

直前の位置登録更新試行が異常終了した場合（ネットワークから有効な応答が返されなかったり、ネット

ワーク内部でエラーや輻輳が起こった場合も含む）。

本ステータスでは、SIM カードには有効な TMSI, GSM 暗号鍵、UMTS 完全鍵、UMTS 暗号鍵、または暗

号鍵シーケンス番号は含まれない。互換性上の理由から、ステータスを NOT UPDATED に設定した時に

これら全てのフィールドの値を"deleted"に設定する必要がある。しかしこれ以外の値が存在した場合にも、

MS がエラーと判定することがないようにすること。SIM カード上に保存されている"Location update status"の値を "not updated"に設定すること。

U3 ROAMING NOT ALLOWED

直前の位置登録更新試行が正常に終了したが、（ローミング拒否または加入制限などにより）ネットワーク

からの応答がネガティブだった場合。

本ステータスでは、SIM カードに有効な TMSI, GSM 暗号鍵、UMTS 完全鍵、UMTS 暗号鍵、または暗号

鍵シーケンス番号が保存されることはない。互換性上の理由から、ステータスを ROAMING NOT ALLOWED に設定した時には、これら全てのフィールドの値を"deleted"に設定する必要がある。しかしこ

れ以外の値が存在した場合にも、MS がエラーと判定することがないようにすること。SIM カード上に保存

されている"Location update status"の値は "Location Area not allowed"に設定すること。

4.1.2.3 MM sublayer states on the network side （ネットワーク側の MMサブレイヤのステート）

1. IDLE

この状態では、RR サブレイヤが Group Receive モードにある場合を除いて、MM サブレイヤはアクティブ

ではない。

2. WAIT FOR RR CONNECTION

MM サブレイヤが CM サブレイヤから MM コネクション確立要求を受信した状態。RR サブレイヤは MSに対する RR コネクションを要求する（つまりページングが実行される）。

3. MM CONNECTION ACTIVE

MM サブレイヤは MS に対する RR コネクションを持つ。1 つまたは複数の MM コネクションがアクティブ。

4. IDENTIFICATION INITIATED

ネットワークが識別処理を開始した状態。タイマ T3270 が起動している。

5. AUTHENTICATION INITIATED

ネットワークが認証処理を開始した状態。タイマ T3260 が起動している。

6. TMSI REALLOCATION INITIATED

ネットワークが TMSI 再割当処理を開始した状態。タイマ T3250 が起動している。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 47

7. SECURITY MODE INITIATED

UMTS では、RR サブレイヤに対してセキュリティモード設定処理が要求された状態。GSM では、RR サブ

レイヤに対して暗号モード設定処理が要求された状態。

8a. WAIT FOR MOBILE ORIGINATED MM CONNECTION

CM SERVICE REQUEST メッセージを受信して処理しており、MM サブレイヤは MM コネクションの

"opening message"を待っている状態。

8b. WAIT FOR NETWORK ORIGINATED MM CONNECTION

ネットワークが CM SERVICE PROMPT メッセージを送信して、MM サブレイヤは MM コネクション

$(CCBS)$の"opening message"を待っている状態。

9. WAIT FOR REESTABLISHMENT

複数の Mmconnection を伴う Rrconnection を失った状態。ネットワークは想定される MS からの再確立要

求を待つ。

10. WAIT OF A GROUP CALL

VGCS トーキングをサポートする MS に対してのみ適用。MM サブレイヤが GCC サブレイヤからの VGCS確立要求を待っている状態。VGCS チャネルの確立要求は RR サブレイヤから与えられる。

11. GROUP CALL ACTIVE

VGCS トーキングをサポートする MS に対してのみ適用。VGCS チャネルは RR サブレイヤによって確立さ

れる。RR サブレイヤは、通話中 MS に対する RR コネクションを確立できる。MM サブレイヤはアクティブ

であるが、ネットワークと MS の間で MM メッセージが送受信されることはない。

12. MM CONNECTION ACTIVE (GROUP CALL)

VGCS トーキングをサポートする MS に対してのみ適用。MM サブレイヤが VGCS チャネル上でトーキン

グ MS に対する RR コネクションを確立した状態。1 つの MM コネクションのみがアクティブ。

13. WAIT FOR BROADCAST CALL

VBS の場合のみ適用。MM サブレイヤが BCC サブレイヤから VBS 確立要求を受信した状態。VBS チャ

ネル確立要求は RR サブレイヤに渡される。

14. BROADCAST CALL ACTIVE

VBS の場合のみ適用。RR サブレイヤが VBS チャネルを確立した状態。MM サブレイヤはアクティブであ

るが、ネットワークと MS の間で明示的な MM 確立は発生しない。

4.1.3 GPRS mobility management (GMM) sublayer states （GMMサブレイヤのステート）

本節では、MS およびネットワークの GMM プロトコルについて、2 つの異なるステートメカニズムを使用して説明する。

4.1.3.1 節では、MS 内の GMM エンティティのステートについて紹介する。GPRS 更新ステータスに依存する MS の

動作については、4.1.3.2 節で説明する。ネットワーク側のステートについては、4.1.3.3 節で説明する。

4.1.3.1 GMM states in the MS（MS内の GMMステート）

本節では、MS 内の GMM エンティティの取りうる GMM ステートについて記載する。4.1.3.1.1 節に GMM エンティテ

ィのメインステートについてまとめる。TS 24.008 の図 4.1b 参照。既に定義されたサブステートについては、4.1.3.1.2節および 4.1.3.1.3 節に記載する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 48

ただし、本節では特定のステート内における MS の詳細な動作に関する記載は含まれず、また異常なケースについ

てもカバーしていないことに注意。以上の理由により、TS 24.008 の図 4.1b は、完全なステート遷移ダイヤグラムで

はなく、ステート遷移の概要を示す図と見なすべきである。MS の動作の詳細な説明は 4.2 節で与えられる。特に、

異常なケースにおける MS の動作については 4.7 節参照のこと。

4.1.3.1.1 Main states（メインステート）

4.1.3.1.1.1 GMM-NULL

本ステートでは、MS の GPRS ケーパビリティは無効である。GPRS モビリティ管理機能は実行されない。

4.1.3.1.1.2 GMM-DEREGISTERED

本ステートでは、MS の GPRS ケーパビリティは有効にされているが、GMM コンテキストは未だ確立されていない。

本ステートでは、MS は GPRS アタッチまたは複合 GPRS アタッチ処理を開始することによって GMM コンテキストを

確立することができる。

4.1.3.1.1.3 GMM-REGISTERED-INITIATED

GPRS アタッチまたは複合 GPRS アタッチ処理が開始され、MS がネットワークからの応答を待っている状態。

4.1.3.1.1.4 GMM-REGISTERED

GMM コンテキストが確立された、つまり GPRS アタッチまたは複合 GPRS アタッチ処理が正常に完了した状態。MSは PDP コンテキストをアクティブにし、ユーザデータおよびシグナリング情報を送受信し、ページングリクエストに対し

て応答することができる。さらにセル更新と RA 更新が実行される。

4.1.3.1.1.5 GMM-DEREGISTERED-INITIATED

GPRS デタッチまたは複合 GPRS デタッチ処理が開始され、MS が GMM コンテキストの開放を要求されている状態。

本ステートに入るのは、デタッチ要求があったときに MS の電源が切られていない場合に限られる。

4.1.3.1.1.6 GMM-ROUTING-AREA-UPDATING-INITIATED

RA 更新処理が開始され、MS がネットワークからの応答を待っている状態。

4.1.3.1.1.7 GMM-SERVICE-REQUEST-INITIATED (UMTS only)

サービスリクエスト処理が開始され、MS がネットワークからの応答を待っている状態。

4.1.3.1.2 Substates of state GMM-DEREGISTERED

GMM-DEREGISTERED ステートは、以下に述べるように複数のサブステートに分類される。サブステートは MS 全

体に関するものである（SIM カードが挿入されていない ME 単体、または ME＋SIM カード）。適切なサブステートの

選択は、GPRS 更新ステータスおよび選択されたセルに依存する。4.1.3.2 節参照。

4.1.3.1.2.1 GMM-DEREGISTERED.NORMAL-SERVICE

有効な加入者データが利用可能であり、GPRS 更新ステータスが GU1 または GU2 で、かつセルが選択された状態。

本ステートでは、MS 内に保存された P-TMSI（temporary mobile subscriber identity for GPRS）、RAI（routing area identification）、そして GU1 の場合には GPRS 暗号鍵シーケンス番号を使用して、GPRS アタッチのための要求を実

行する。GPRS 更新ステータスが GU2 の場合には、GPRS サービス用のアタッチには IMSI を使用すること。

4.1.3.1.2.2 GMM-DEREGISTERED.LIMITED-SERVICE

有効な加入者データが利用可能であり、GPRS 更新ステータスが GU3、かつ通常のサービスを提供可能であること

が既知のセルが選択された状態。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 49

4.1.3.1.2.3 GMM-DEREGISTERED.ATTACH-NEEDED

有効な加入者データが利用可能であり、何らかの理由によって、位置登録更新をできるだけ早く行う必要がある状

態）。本ステートは通常は長期間持続しないが、例えばアクセスクラスがブロックされた場合などには、長期間持続す

ることも可能。

4.1.3.1.2.4 GMM-DEREGISTERED.ATTEMPTING-TO-ATTACH

GPRS 更新ステータスは GU2、セルが選択されており、前回の GPRS アタッチが拒否された状態。アタッチ処理をこ

れ以上続けるか否かは、GPRS アタッチ試行カウンタの値に依存する。本ステートにおいては、MS は GPRS アタッチ

以外の GMM 処理を開始することはない。

4.1.3.1.2.5 GMM-DEREGISTERED.NO-IMSI

有効な加入者データが利用不可能で（SIM カードなし、または SIM カードが ME によって無効と判定された場合な

ど）、かつセルが既に選択されている状態。

4.1.3.1.2.6 GMM-DEREGISTERED.NO-CELL-AVAILABLE

セルが選択できない状態。初の集中的なセルサーチが失敗した後、本ステートに入る（サブステート PLMN SEARCH）。セルは低頻度でサーチされる。サービスは何も提供されない。

4.1.3.1.2.7 GMM-DEREGISTERED.PLMN-SEARCH

MS が PLMN をサーチしている状態。セルが選択された場合（新しいサブステートは NORMAL-SERVICE または LIMITED-SERVICE）、またはそのとき利用可能なセルがないと結論された場合（新しいサブステートは NO-CELL-AVAILABLE）、MS は本サブステートを離れる。

4.1.3.1.2.8 GMM-DEREGISTERED.SUSPENDED (GSM only)

個別モードに入った MS は、本サブステートに入ること。また、MS 制限（MS limitation）によって、GPRS チャネル上

の通信を無効にすることもできる。MS が個別モードを外れた場合、本サブステートを離れる。

4.1.3.1.3 Substates of state GMM-REGISTERED

ステート GMM-REGISTERED は、後述するように複数のサブステートに分類される。サブステートは MS 全体に関

するものである（SIM カードが挿入されていない ME 単体、または ME＋SIM カード）。

4.1.3.1.3.1 GMM-REGISTERED.NORMAL-SERVICE

ユーザデータとシグナリング情報を送受信可能。

4.1.3.1.3.2 GMM-REGISTERED.SUSPENDED (GSM only)

MS が個別モードに入って、MS 制限によって GPRS チャネル上の通信が無効にされた場合に、本サブステートに入

る。本サブステートでは、ユーザデータもシグナリング情報も送信することはできない。MS は個別モードから離れた

ならば本サブステートを離れること。

4.1.3.1.3.3 GMM-REGISTERED.UPDATE-NEEDED

MS は RA 更新処理を実行する必要があるが、そのアクセスクラスがセル内で許容されていない状態。（セル再選択

または現行セルのアクセスクラスの変更によって）アクセスが許容され次第、できるだけ早く処理が開始される。MSが本ステートにある場合、RA 更新以外の GMM 処理は MS によって開始される。本サブステートでは、ユーザデー

タもシグナリングデータも送信できない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 50

4.1.3.1.3.4 GMM-REGISTERED.ATTEMPTING-TO-UPDATE

ネットワークからの応答がないために、RA 更新処理が失敗した状態。MS は処理を再試行し、その処理はタイマと

GPRS 試行カウンタによって制御される。MS が本ステートにある場合、MS は RA 更新以外の GMM 処理を開始す

ることはできない。データは何も送受信されない。

4.1.3.1.3.5 GMM-REGISTERED.NO-CELL-AVAILABLE

GPRS の圏内を出た状態。本サブステートでは、MS はセル（および PLMN）再選択以外の GMM 処理を開始するこ

とはできない。

GMM-NULLGMM-ROUTING-

AREA-UPDATING-INITIATED

GMM-DEREGISTERED

- enableGPRS mode

- DETACH requested(not power off)

GMM-REGISTERED

Any state

GMM-DEREGISTERED-

INITIATED

- ATTACHrequested - ATTACH rejected

DETACH requested (power off)

- Network init. DETACH requested- Lower layer failure

- RAU rejected- Network init. DETACH requested- implicit DETACH

- DETACH accepted- Lower layer failure

- disableGPRS mode

- RAUrequested

- RAU accepted- RAU failed

GMM-REGISTERED-

INITIATED

GMM-SERVICE-REQUEST-INITIATED

- SR accepted- SR failed

- SR requestedd

- ATTACHaccepted

図図図図 4.1b/TS 24.008:GMM メインステート、メインステート、メインステート、メインステート、MS 側側側側

4.1.3.1.3.6 GMM-REGISTERED.LIMITED-SERVICE

通常のサービスを提供できないことが分かっているセルが選択された状態。MS は、通常のサービスを提供できるセ

ルが選択されるまで、本サブステートにとどまる。

4.1.3.1.3.7 GMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM

GPRS サービスに関する複合 RA 更新処理または複合 GPRS アタッチ処理だけが正常に完了した状態。MS は処理

を再試行し、その処理はタイマと GPRS 試行カウンタによって制御される。ユーザデータおよびシグナリング情報を送

受信することが可能。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 51

4.1.3.1.3.8 GMM-REGISTERED.IMSI-DETACH-INITIATED

MS が非 GPRS サービスのためだけに複合 GPRS デタッチ処理だけを実行する状態（デタッチタイプ"IMSI Detach"）。ネットワークモード I で運用されているネットワーク内で、MS が GPRS および非 GPRS サービスにアタッチされ、そし

て MS が非 GPRS サービスのみデタッチしたい場合に、MS は本ステートに入る。ユーザデータおよびシグナリング

情報を送受信することが可能。

4.1.3.2 GPRS update status（GPRS更新ステータス）

今までに説明した GMM サブレイヤに加えて、GPRS 更新ステータスも存在する。

GPRS 更新ステータスは、SIM カードを実装した特定の加入者に関するものである。本ステートは、加入者がアクティ

ブでない場合（SIM カードが抜かれたり、電源 OFF の ME に挿入されている場合など）にも、本ステートは定義され

る。ステートに関する情報は SIM カードの不揮発性メモリ上に保存される。GPRS アタッチ処理、ネットワーク開始型

GPRS デタッチ処理、認証処理、または RA 更新処理の実行が完了した後にはじめて、GPRS 更新ステータスが変更

される。

GU1: UPDATED

後の GPRS アタッチまたは RA 更新試行が正常に終了した状態（正常な処理が行われ、応答がネットワー

クによって受領された場合）。SIM カードには、加入者がアタッチされた RA の RAI が保存され、場合によって

は有効な P-TMSI, GPRS GSM 暗号鍵、GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして GPRS 暗号鍵シ

ーケンス番号も保存される。

GU2: NOT UPDATED

後の GPRS アタッチまたは RA 更新試行が異常終了した状態。つまり、ネットワークからの応答がなかった

場合。ネットワーク内部でエラーまたは輻輳が発生した場合も含まれる。

この場合、SIM カードには、加入者がアタッチされた RA の RAI が保存され、場合によっては有効な P-TMSI, GPRS GSM 暗号鍵、GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして GPRS 暗号鍵シーケンス番号が保

存される。互換性上の理由から、RAI が削除された場合には、これら全てのフィールドの値を"deleted"に設定

すること。しかし、これ以外の値が存在した場合にも、MS はエラーと判定してはならない。

GU3: ROAMING NOT ALLOWED

後の GPRS アタッチまたは RA 更新試行が正常終了したが、（ローミング規制または加入者規制などによっ

て）ネットワークからの応答がネガティブだった場合。

このステートにおいては、SIM カードには、正当な P-TMSI, GPRS GSM 暗号鍵、GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして GPRS 暗号鍵シーケンス番号は保存されない。互換性上の理由から、ステータスを

ROAMING NOT ALLOWED に設定した時に、これら全てのフィールドの値を"deleted"に設定する必要があ

る。しかし、これ以外の値が存在した場合にも、MS はエラーと判定してはならない。

4.1.3.3 GMM mobility management states on the network side （GMMステータス、ネットワーク側）

本節では、ネットワーク側で、GMM がとりうるステートについて記載する。主要なステートを 4.1.3.3.1 節にまとめた。

関連するサブステートについては、4.1.3.3.2 節に記載。

ただし、本節では、特定のステート内におけるネットワークの詳細な動作に関する記載は含まれず、また異常なケー

スについてもカバーしていないことに注意。以上の理由により、TS 24.008 の図 4.1c は、完全なステート遷移ダイヤ

グラムではなく、ステート遷移の概要を示す図と見なすべきである。MS の動作の詳細な説明は、4.2 節で与えられる。

特に、異常なケースにおける MS の動作については、4.7 節参照のこと。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 52

4.1.3.3.1 Main States（メインステート）

4.1.3.3.1.1 GMM-DEREGISTERED

ネットワークが GMM コンテキストを持っていない、または GMM コンテキストがデタッチとしてマークされており、MSがデタッチされた状態。本ステートでは、ネットワークは MS によって開始された GPRS アタッチまたは複合 GPRS ア

タッチ処理に対して応答することができる。

4.1.3.3.1.2 GMM-COMMON-PROCEDURE-INITIATED

4.1.1 節で定義されたように、共通 GMM 処理が開始された状態。ネットワークは MS からの応答を待つ。

4.1.3.3.1.3 GMM-REGISTERED

GMM コンテキストが確立され、GPRS アタッチ処理が正常完了した状態。

4.1.3.3.1.4 GMM-DEREGISTERED-INITIATED

ネットワークが GPRS デタッチ処理を開始し、MS からの応答を待っている状態。

GMM-DE-REGISTERED

- Network initiatedDETACH requested

GMM-REGISTERED

GMM-COMMON-PROCEDURE-INITIATED

GMM-DE-REGISTERED-

INITIATED

- COMMON procedurefailed

- Lower layer failure

- ATTACH proceduresuccessful

- MS initiatedDETACH requestedRAU rejectedimplicit DETACH

- DETACH accepted- Lower layer failure

- COMMON proceduresuccessful

- ATTACH proceduresuccessful

- COMMON procedurerequested

- COMMON procedurerequested

図図図図 4.1c/TS 24.008: GMM メインステート、ネットワーク側メインステート、ネットワーク側メインステート、ネットワーク側メインステート、ネットワーク側

4.1.3.3.2 Substates of state GMM-REGISTERED

後述の通り、ステート GMM-REGISTERED は 2 つのサブステートに分類される。

4.1.3.3.2.1 GMM-REGISTERED.NORMAL-SERVICE

ユーザデータとシグナリング情報を送受信可能。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 53

4.1.3.3.2.2 GMM-REGISTERED.SUSPENDED (GSM only)

本サブステートでは、下位レイヤはユーザデータまたはシグナリング情報を送信してはならない。

4.2 Behaviour of the MS in MM Idle state, GMM-DEREGISTERED state and GMM-REGISTERED state （MM Idleステート、DEREGISTEREDステート、GMM-REGISTEREDステートにおけるMSの動作）

本節では、主要なステートである、MM Idle ステート、DEREGISTERED ステート、GMM-REGISTERED ステートに

おける MS の動作詳細について説明する。それぞれ、MM IDLE ステートについては 4.2.1～4.2.3 節で、

DEREGISTERED ステートについては 4.2.4 節で、GMM-REGISTERED ステートについては 4.2.5 節で説明する。

MM 処理が 1 つも起動されておらず、かつ RR コネクションも存在しない場合に MS は MM Idle ステートに入る。

MM 処理のうちどれか 1 つがトリガされるか、RR コネクションが確立されたならば MM Idle ステートを離れる。

MM Idle ステート固有の動作は、4.1.2.1.2 節に述べるように MS のサービスステートに依存する。サービスステート

は特に、4.1.2.2 節で規定した更新ステータスに依存する。

MS 電源投入後、どのように適切なサービスステートを選択するかについては 4.2.1 節で説明する。また、MM IDLEステートにある MS 固有の動作は 4.2.2 節で説明する。NULL ステートを除く他のステートから MM IDLE ステートに

復帰した場合に選択されるサービスステートについては 4.2.3 節で説明する。

以下のような理由でさまざまな MM idle ステート間のステート遷移が発生することに注意。

- RR コネクトモードにおける処理の結果（4.2.3 節参照）

- SIM カードの挿抜

- セルの選択／再選択（TS 03.22 も参照）

- PLMN サーチ

- 圏外

各種の MM 処理がサービスステートと更新ステータスに対して及ぼす影響については、4.3 ～4.5 節の処理の詳細

な説明中に記載する。

4.2.1 Primary Service State selection （プライマリサービスステートの選択）

4.2.1.1 Selection of the Service State after Power On. （電源投入後のサービスステートの選択）

電源投入後にモビリティ管理がアクティブになると、サービスステートは 19.7 PLMN SEARCH となる。本ステートに

おける処理の詳細については、TS 03.22 および 05.08 で詳細に説明される。そこでは、電源投入と PLMN の選択の

ための処理が詳しく説明される。SIM カード内に保存される位置更新ステータス（Location update status）が"updated"でなければ、MS は SIM カード内に保存される位置更新ステータスが "not updated"である場合と同様に動作するこ

と。

サービスステートがいつ PLMN SEARCH ステートを離れるかは、サーチの結果と SIM カードの有無によって決まる。

- セルが見つからない場合には、セルが見つかるまでステートは NO CELL AVAILABLE となる。

- SIM カードがない場合には、ステートは NO IMSI となる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 54

- MS が連続的に圏外と圏内を継続的に繰り返し、かつ選択されたセルが MS が登録された LA 内にあり、か

つタイマ T3212 が満了していない場合には、ステートは NORMAL SERVICE となる。

- 選択されたセルが MS が登録された LA 内になく、かつ IMSI ATTACH が要求されておらず、かつタイマ

T3212 が満了していない場合には、ステートは NORMAL SERVICE となる。

- MS が自動ネットワーク選択モードにあり、かつ選択されたセルが禁止 PLMN 内または禁止 LA 内にある場

合には、MS は LIMITED SERVICE ステートに入る。

- MS が自動ネットワーク選択モードにあり、かつ選択された PLMN 内にセルが見つからない場合には、MS は

LIMITED SERVICE ステートに入る。

- 上記以外の場合には、MS は LOCATION UPDATE NEEDED ステートに入る。

4.2.1.2 Other Cases（その他のケース）

以下のケースでも MS はステート PLMN SEARCH に入る。

- ステート NO IMSI で、SIM カードが挿入された場合

- ユーザが PLMN 選択を依頼した後、NO IMSI, NO CELL AVAILABLE, NORMAL SERVICE 、そして RECEIVING GROUP CALL (NORMAL SERVICE)以外のステートにある場合

- NO IMSI と NO CELL AVAILABLE 以外のステートで、圏外になった場合

- ローミングが拒否された場合

- オプションとして、MS が ATTEMPTING TO UPDATE ステートに入り、さらに自動ネットワーク選択モードに入

り、そして位置更新試行カウンタの値が 4 以上になった場合

PLMN SEARCH から離れた場合のサービスステートは、4.2.1.1 節で規定される通り、セルサーチの結果と SIM カー

ドの有無によって決まる。

4.2.2 Detailed Description of the MS behaviour in MM IDLE State. （MM IDLEステートにおけるMSの動作の詳細な説明）

MM IDLE ステートにおいては、MS の動作はサービスステートによって決められること。以下の節では、非遷移サー

ビスステートの場合の MS 動作について説明する。RR コネクトモードにおける処理（位置登録更新処理など）の後は、

MM idle ステートの選択を規定する 4.2.3 節が適用される。さらに、サブステート NORMAL SERVICE においては、

PLMN 選択が要求されたならば、MS はサブステート SEARCH FOR PLMN, NORMAL SERVICE に入る。

4.2.2.1 Service State, NORMAL SERVICE （サービスステート、NORMAL SERVICE）

ステート MM IDLE、サービスステート NORMAL SERVICE においては、MS は以下の処理を実行すること。

- 新しい LA に入った場合には、通常の位置登録更新処理を実行

- タイマ T3211 または T3213 が満了した場合には、位置登録更新処理を実行

- タイマ T3212 が満了した場合には、定期的更新処理を実行

- IMSI デタッチを実行

- CM レイヤからの要求をサポート

- ページングに対して応答

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 55

以上に加えて、VGCS リスニングまたは VBS リスニングをサポートする MS は以下の処理を実行すること。

- GCC または BCC サブレイヤに通知

- GCC または BCC サブレイヤが、RR サブレイヤによる通知中で受信したチャネル説明がない音声呼またはブ

ロードキャスト呼の受信を要求した場合、通知に応答

- GCC または BCC サブレイヤが、RR サブレイヤによる通知中で受信したチャネル説明がない音声呼またはブ

ロードキャスト呼の受信を要求した場合、RR サブレイヤに対して音声呼またはブロードキャスト呼の受信を要

求し、サービスステート RECEIVING GROUP CALL (NORMAL SERVICE)に入る。

4.2.2.2 Service State, ATTEMPTING TO UPDATE （サービスステート、ATTEMPTING TO UPDATE）

ステート MM IDLE、サービスステート ATTEMPTING TO UPDATE にある MS は、以下の処理を実行すること。

- タイマ T3211 または T3213 が満了した場合には、位置登録更新処理を実行

- サービスセルの変更の LA 識別にあたっては、通常の位置登録更新処理を実行

- 4.4.4.9 節の c)または d) または f) ("abnormal release, unspecified"以外の理由値) または g) (理由値"retry upon entry into a new cell")が原因で本ステートに入った場合には、新しいセルに入ったときに位置登録更新

処理を実行すること。

- 4.4.4.9 節の e) または f) （理由値"abnormal release, unspecified"）または g） ("retry upon entry into a new cell"以外の理由値)が原因で本ステートに入った場合には、新しいセルに入ったという理由で、位置登録更新処理

を実行してはならない。

- タイマ T3212 が満了した場合には、通常の位置登録更新を実行

- IMSI デタッチは実行しない

- 緊急呼のサポート要求

- 通常の位置登録更新処理をトリガするために、CM レイヤからのその他の要求を使用（位置登録更新処理正

常終了時には、MM コネクションのための要求が受理される。4.5.1 節参照）

- ページングに対して（IMSI で）応答

上記に加えて、VGCS リスニングまたは VBS リスニングをサポートする MS は、以下の処理を行うこと。

- GCC または BCC サブレイヤに対して、RR サブレイヤによる通知中でどのチャネル説明を受信したかを通知

する。

- RR サブレイヤによる通知内で受信したチャネル説明がない通知に対して、GCC または BCC サブレイヤから

の要求を拒否して応答する

- GCC または BCC サブレイヤが、RR サブレイヤからの通知内でチャネル構造を受信していない音声グループ

呼またはブロードキャスト呼の受信を要求した場合、RR サブレイヤに対して音声グループ呼またはブロード

キャスト呼の受信を要求する。そしてサービスステート RECEIVING GROUP CALL (LIMITED SERVICE)に移行。

4.2.2.3 Service State, LIMITED SERVICE（サービスステート LIMITED SERVICE）

ステート MM IDLE、サービスステート LIMITED SERVICE にある MS は、以下の処理を行うこと。

- 定期的更新は実行しない

- IMSI デタッチは実行しない

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 56

- 緊急呼以外の MM コネクション用の CM エンティティからの要求は拒否

- 通常のサービスを提供できるはずのセル（LA が禁止 LAI リスト内にないセルなど）に入ったとき、通常の位

置登録更新処理を実行

- ページングに対して（IMSI で）応答することも可能

VGCS リスニングまたは VBS リスニングをサポートする MS は、上記に加えて以下の処理を行うこと。

- RR サブレイヤによる通知でチャネル説明を受信した GCC または BCC サブレイヤに対して通知

- RR サブレイヤからの通知内でチャネル説明を受信していない GCC または BCC サブレイヤの通知に対する

応答要求を拒否

- RR サブレイヤからの通知内でチャネル説明を受信した音声グループ呼またはブロードキャスト呼を受信する

よう GCC または BCC サブレイヤが要求した場合、RR サブレイヤに対して音声グループ呼またはブロードキ

ャスト呼を受信するよう要求する。サービスステートは RECEIVING GROUP CALL (LIMITED SERVICE)に移行。

4.2.2.4 Service State, NO IMSI（サービスステート, NO IMSI）

ステート MM IDLE、サービスステート NO IMSI にある MS は、以下の処理を行うこと（TS 03.22 および GSM 05.08の 3.2 節参照）。

- 通常の位置登録更新試行は開始しない


- 電源切断時には IMSI デタッチを実行しない


- ページングには応答しない

- デフォルトのセル選択だけを実行

VGCS リスニングまたは VBS リスニングをサポートする MS は、上記に加えて以下の処理を行うこと

- GCC または BCC サブレイヤに対して通知しない

4.2.2.5 Service State, SEARCH FOR PLMN, NORMAL SERVICE （サービスステート、SEARCH FOR PLMN, NORMAL SERVICE）

ステート MM IDLE 、サービスステート SEARCH FOR PLMN, NORMAL SERVICE にある MS は、以下の処理を行

うこと。

- 本ステートでタイマ T3211 または T3213 が満了した場合には、NORMAL SERVICE ステートに戻り、かつセ

ルが変更されていないならば、後に位置登録更新処理を行う。

- 本ステートでタイマ T3212 が満了した場合には、NORMAL SERVICE ステートに戻ったときに後に定期的

位置登録更新を実行する。


- CM レイヤからの要求をサポート

- 可能な限りページングを聞いて、応答する

VGCS リスニングまたは VBS リスニングをサポートする MS は、上記に加えて以下の処理を行う。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 57

- 可能な限り通知に対して応答し、GCC または BCC レイヤに対して通知する

- RR サブレイヤからの通知内でチャネル説明を受信してない音声グループ呼またはブロードキャスト呼の受信

を GCC または BCC サブレイヤが要求した場合、通知するために応答

- RR サブレイヤからの通知内でチャネル説明を受信した音声グループ呼またはブロードキャスト呼の受信を

GCC または BCC サブレイヤが要求した場合、RR サブレイヤに対して、音声グループ呼またはブロードキャ

スト呼の受信を要求

4.2.2.6 Service State, SEARCH FOR PLMN （サービスステート, SEARCH FOR PLMN）

ステート MM IDLE 、サービスステート SEARCH FOR PLMN にある MS は、以下の処理を行うこと。

- 通常の位置登録更新試行は開始しない


- 電源 OFF の場合には ISMI デタッチを実行しない


- ページングには応答しない

4.2.2.7 Service State, RECEIVING GROUP CALL (NORMAL SERVICE) （サービスステート、RECEIVING GROUP CALL (NORMAL SERVICE)）

VGCS リスニングまたは VBS リスニングをサポートする MS においてのみ、適用される。

ステート MM IDLE、サービスステート RECEIVING GROUP CALL (NORMAL SERVICE)にある MS は、以下の処

理を行うこと。

- 新しい LA に入ったとき、通常の位置登録更新処理を実行

- タイマ T3211 または T3213 が満了したとき、位置登録更新処理を実行

- タイマ T3212 が満了したとき、定期的更新処理を実行


- GCC または BCC レイヤからの要求をサポート

- GCC または BCC サブレイヤに対して、通知またはページング情報を通知

- RR サブレイヤからの通知内でチャネル説明を受信していない音声グループ呼またはブロードキャスト呼の受

信を GCC または BCC サブレイヤが要求した場合、通知で応答

- RR サブレイヤからの通知内でチャネル説明を受信した音声グループ呼またはブロードキャスト呼の受信を

GCC または BCC サブレイヤが要求した場合、RR サブレイヤに対して、他の音声グループ呼またはブロード

キャスト呼の受信を要求

4.2.2.8 Service State, RECEIVING GROUP CALL (LIMITED SERVICE) （サービスステート, RECEIVING GROUP CALL (LIMITED SERVICE)）

VGCS リスニングまたは VBS リスニングをサポートする MS に対してのみ、適用。

ステートが MM IDLE 、サービスステートが RECEIVING GROUP CALL (LIMITED SERVICE)の場合、MS は以下

の処理を行うこと。


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 58

- ISMI デタッチを実行しない


- 通常のサービスを提供できるはずのセル（LA が禁止 LAI リスト内にないセルなど）に入ったとき、通常の位

置登録更新処理を実行

- ページングに対して（IMSI で）応答することは可能

- RR サブレイヤからの通知内で、どのチャネル説明を受信したかを GCC または BCC サブレイヤに対して通知

- RR サブレイヤからの通知内でチャネル説明を受信しなかったチャネルを、GCC または BCC サブレイヤに対

して通知して GCC または BCC サブレイヤからの要求を拒否

- RR サブレイヤからの通知内でチャネル説明を受信した音声グループ呼またはブロードキャスト呼の受信を、

GCC または BCC サブレイヤが要求した場合、RR サブレイヤに対して音声グループ呼またはブロードキャス

ト呼の受信を要求。サービスステートは RECEIVING GROUP CALL (LIMITED SERVICE)に移行。

4.2.3 Service state when back to state MM IDLE from another state （他のステートからステートMM IDLEに戻った場合のサービスステート）

例えば位置登録更新処理などで、MM IDLE ステートに戻った場合、MS は TS 03.22 内で規定されるセルを選択す

る。1 つの違いを除いて、これは通常のセル選択処理である。

位置登録更新処理の後に、理由値"Roaming not allowed in this location area"を受信してから、ステート MM IDLEに戻ったのではない場合には、サービスステートは、セル選択処理の結果、MS の更新ステータス、MS 内に保存さ

れている位置データ、および SIM カードの有無によって決まる。

- セルが見つからなかった場合には、セルが見つかるまでステートは NO CELL AVAILABLE

- SIM カードがない場合、または挿入された SIM カードが MS によって無効と判定された場合には、ステートはNO IMSI

- 選択されたセルが MS が登録された LA 内にある場合には、ステートは NORMAL SERVICE。4.4.4.9 節で説

明される異常なケースも含まれることに注意。

- （VGCS リスニングまたは VBS リスニングをサポートする MS にのみ適用）位置登録更新処理以前の MS の

サービスステートが RECEIVING GROUP CALL (NORMAL SERVICE) または RECEIVING GROUP CALL (LIMITED SERVICE)であり、かつ選択されたセルが MS が登録された LA 内にある場合には、ステートはRECEIVING GROUP CALL (NORMAL SERVICE)

- 選択されたセルが MS が登録されていない LA 内にあるが、そのセル内での MS の位置登録更新試行が許

容されている場合には、ステートは LOCATION UPDATE NEEDED

- セルが MS の位置登録更新試行が許容されていない LA 内にある場合、ステートは LIMITED SERVICE

- （VGCS リスニングまたは VBS リスニングをサポートする MS にのみ適用）位置登録更新処理以前の MS の

サービスステートが RECEIVING GROUP CALL (NORMAL SERVICE)または RECEIVING GROUP CALL (LIMITED SERVICE)であり、かつ選択されたセルが MS の位置登録更新試行が許容されていない LA 内に

ある場合には、ステートは RECEIVING GROUP CALL (LIMITED SERVICE)

- 位置登録更新処理が失敗している間に、何らかの異常なケースが発生したならば、4.4.4.9 節に説明されるよ

うに、ステートは ATTEMPTING TO UPDATE

位置登録更新処理に対する応答として"Roaming not allowed in this location area"が返された場合には、4.2.1.2 節に

規定されるように、サービスステートは PLMN SEARCH に入る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 59

4.2.4 Behaviour in state GMM-DEREGISTERED （ステート GMM-DEREGISTEREDにおける動作）

以下のケースで、MS はステート GMM-DEREGISTERED に入る：

- MS の電源が投入された場合

- MS 内で GPR ケーパビリティが有効にされた場合

- GPRS デタッチまたは複合 GPRS デタッチ処理が実行された場合

- GMM 処理が失敗した場合（RA 更新を除く、4.7.5 節参照）

電源投入後、GMM-DEREGISTERED の適切なサブステートが選択されるが、その詳細については 4.2.4.1 節参照。

ステート GMM-DEREGISTERED 固有の MS の動作については、4.2.4.2 節参照。ステート GMM-NULL を除くその

他のステートから GMM-DEREGISTERED ステートに戻ったときのサブステートの選択については、4.2.4.3 節参照。

以下の原因で、GMM-DEREGISTERED の各サブステート間でステート遷移が発生することに注意。

- SIM カードの挿抜

- セルの選択／再選択（TS 03.22 [82]参照）

- PLMN サーチ

- 圏外／圏内の移動

- RA 変更

各 GMM 処理がどのように GMM-DEREGISTERED のサブステートと GPRS 更新ステータスに影響を及ぼすかにつ

いては、4.7 節内の GMM 処理の詳細説明を参照。

4.2.4.1 Primary substate selection（プライマリサブステートの選択）

4.2.4.1.1 Selection of the substate after power on or enabling the MS's GPRS capability （MS電源投入後またはMSの GPRSケーパビリティを有効にした後のサブステートの選択）

MS 電源投入時、SIM カードが MS に挿入されておりかつそれが有効な場合には、サブステートは PLMN-SEARCHとなること。詳細については、TS 23.122 [14]および 05.08 [34]参照。

アクティブな MS 内の GPRS ケーパビリティが有効にされたとき、GMM-DEREGISTERED サブステートは MM ステ

ートと GPRS 更新ステータスによって決まる。

MS 電源投入後、または MS の GPRS ケーパビリティが有効にされたとき、PLMN-SEARCH の後のサブステートが

選択される。

- セルが GPRS をサポートしない場合、サブステートは NO-CELL-AVAILABLE とすること

- SIM カードが存在しない場合、サブステートは NO-IMSI とすること

- GPRS をサポートするセルが見つかって、かつ PLMN または LA が禁止リスト中にない場合には、サブステー

トは NORMAL-SERVICE とすること

- GPRS をサポートするセルが見つかったが、そのセルが PLMN または LA が禁止リスト中にある場合には、

サブステートは LIMITED-SERVICE とすること

- MS がマニュアルネットワーク選択モード（manual network selection mode）にあり、選択された PLMN のセル

が GPRS をサポートしなかった場合には、MS はサブステート NO-CELL-AVAILABLE に入ること

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 60

4.2.4.1.2 Other Cases（その他のケース）

When the MM state is IDLE, the GMM substate PLMN-SEARCH shall also be entered in the following cases: MM ステートが IDLE であるとき、以下のケースでも GMM サブステートは PLMN-SEARCH となること。

- サブステート NO-IMSI において、SIM カードが挿入された場合

- NO IMSI および NO CELL AVAILABLE 以外のサブステートで、ユーザが PLMN 選択を希望した場合

- NO IMSI および NO CELL AVAILABLE 以外のサブステートで、圏外になった場合

- ローミングが拒否された場合

- オプションとして、MS が自動ネットワーク選択モードにあり、GPRS のアタッチ試行カウンタ（4.7.3 節参照）によ

って制御されるアタッチ試行連続失敗の大許容回数に達した場合

- オプションとして、MS が自動ネットワーク選択モードにあり、GPRS の RA 更新試行カウンタ（4.7.5 節参照）に

よって制御される RA 更新試行連続失敗の大許容回数に達した場合

4.2.4.2 Detailed description of the MS behaviour in state GMM-DEREGISTERED （ステート GMM-DEREGISTEREDにおける MSの動作の詳細な説明）

ステート GMM-DEREGISTERED においては、MS はそのサブステートに従って動作すること。以下の節で、非遷移

サブステートに関する MS の動作の詳細について述べる。

4.2.4.2.1 Substate, NORMAL-SERVICE（サブステート、NORMAL-SERVICE）

MS は以下の動作を行うこと。

- GPRS アタッチを実行

4.2.4.2.2 Substate, ATTEMPTING-TO-ATTACH （サブステート、ATTEMPTING-TO-ATTACH）


- タイマ T3311 または T3302 が満了したならば GPRS アタッチを実行

- サービスセルの RA が変更され、そのセルが属する LA が禁止 LA リスト中にない場合、GPRS アタッチを実

行

- 4.7.3.1.5 節の b) または d)（理由値" Retry upon entry into a new cell "）が原因で本ステートに入った場合には、

新しいセルに入ったときに、GPRS アタッチを実行すること

- 4.7.3.1.5 節の c) または d)の条件（理由値が" Retry upon entry into a new cell "以外）が原因で本ステートに入

った場合には、新しいセルに入ったときに、GPRS アタッチを実行してはならない

- ネットワークがネットワークオペレーションモード I でオペレーションされている場合には、CM レイヤからの要

求を使用して複合 GPRS アタッチ処理をトリガする。MS は、タイマ T3311 または T3302 のうち、いずれか起

動している方のタイマを停止し、停止したタイマが満了したときと同様に動作すること。

4.2.4.2.3 Substate, LIMITED-SERVICE（サブステート, LIMITED-SERVICE）


- セルが通常のサービスを提供できるようになったならば（例えば LA が禁止リストから外れた場合など）、

GPRS アタッチを実行

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 61

4.2.4.2.4 Substate, NO-IMSI（サブステート, NO-IMSI）


- デフォルトのセル選択だけを実行

4.2.4.2.5 Substate, NO-CELL（サブステート, NO-CELL）


- TS 03.22 [82]に従ってセルの選択を実行し、適切なサブステートを選択すること

4.2.4.2.6 Substate, PLMN-SEARCH（サブステート, PLMN-SEARCH）

本ステートにおいては、特別なアクションは要求されない。

4.2.4.2.7 Substate, ATTACH-NEEDED（サブステート, ATTACH-NEEDED）

GPRS アタッチ処理がまだ必要な場合には、アクセスクラスがネットワークに対して選択されたセルへのコンタクトを

許容したならばできるだけ早く、MS は GPRS アタッチ処理を開始すること。

4.2.4.2.8 Substate, SUSPENDED (GSM only) （サブステート, SUSPENDED (GSMのみ)）

MS は、

- ユーザデータは送信してはならない

- シグナリング情報を送信してはならない

4.2.4.3 Substate when back to state GMM-DEREGISTERED from another GMM state （他の GMMステートからステート GMM-DEREGISTEREDに戻った場合のサブステート）

ステート GMM-DEREGISTERED に戻った場合、MS は TS 03.22 [82]に規定されている通りにセルを選択すること。

サブステートは、セルの選択処理の結果、その前に実行された GMM 固有の処理の結果、MS の GPRS 更新ステー

タス、MS に保存されている LA データ、そして SIM カードの有無によって決まる。

- セルが見つからなかった場合には、セルが見つかるまで、サブステートは NO-CELL-AVAILABLE

- SIM カードがない、または挿入された SIM カードが MS によって無効と判定されたならば、サブステートは

NO-IMSI とすること

- 選択されたセルが、MS のローミングが許可された LA 内にある場合には、サブステートは NORMAL-SERVICE とすること

- （例えばネットワークが再アタッチを要求して）GPRS アタッチ処理を実行する必要が生じた場合には、サブス

テートは ATTEMPTING-TO-ATTACH とすること

- PLMN 再選択（TS 23.122 [14] に従う）が必要な場合には、サブステートは PLMN SEARCH とすること

- 選択されたセルが MS のローミングが許可されていない LA 内にある場合には、サブステートは LIMITED-SERVICE とすること

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 62

4.2.5 Behaviour in state GMM-REGISTERED （ステート GMM-REGISTEREDにおける動作）

ステート GMM-REGISTERED に入るのは、以下の場合である。

- GMM コンテキストが確立された場合、つまり MS に対して GPRS サービス専用の IMSI、または GPRS と非

GPRS サービス用の IMSI がアタッチされた場合

ステート GMM-REGISTERED の MS 固有の動作については、4.2.5.1 節参照。ステート GMM-REGISTERED に入

ったときのプライマリサブステートは常に NORMAL-SERVICE。

GMM-REGISTERED の各サブステート間のステート遷移は、以下のような例が原因で発生することに注意すること。

- セルの選択／再選択（TS 03.22 も合わせて参照のこと）

- RA の変更

- 圏内／圏外への移動

それぞれの GMM 処理が GMM-REGISTERED サブステートに与える影響については、4.7 節内に記載した処理の

詳細な説明を参照。

4.2.5.1 Detailed description of the MS behaviour in state GMM-REGISTERED （ステート GMM-REGISTEREDにおける MSの動作の詳細な説明）

ステート GMM-REGISTERED においては、以下に説明するように、MS はそのサブステートに従って動作すること。

4.2.5.1.1 Substate, NORMAL-SERVICE（サブステート, NORMAL-SERVICE）

MS は以下の処理を実行すること。

- TS 03.22 [82]に従ってセルの選択／再選択を実行

- 通常の RA 更新および定期的 RA 更新を実行

- ユーザデータとシグナリング情報を送受信

オペレーションモード C または A の GPRS MS は、ページングリクエストに対して応答すること。

オペレーションモード B の GPRS MS は、ページングリクエストに対して応答してもしなくてもよい。

4.2.5.1.2 Substate, SUSPENDED (GSM only) （サブステート, SUSPENDED (GSM のみ)）

MS は、

- ユーザデータを送信してはならない


- セルの更新を実行してはならない

4.2.5.1.3 Substate, UPDATE-NEEDED（サブステート, UPDATE-NEEDED）

MS は、



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 63

- TS 03.22 [82]に従ってセルの選択／再選択を実行すること

- アクセスクラスがネットワークに対して選択されたセルに対するアクセスを許容したら直ちに、GPRS 更新ステ

ータスに従って、適切な新しいサブステートを選択する

4.2.5.1.4 Substate, ATTEMPTING-TO-UPDATE （サブステート, ATTEMPTING-TO-UPDATE）

MS は、


- タイマ T3311 または T3302 が満了したならば、RA 更新を実行すること

- サービスセルの RA が変更され、かつそのセルが属する LA が禁止 LA にリストされていない場合には、RA更新を実行すること

- 4.7.3.1.5 節の b) または d)（理由値" Retry upon entry into a new cell "）が原因で本ステートに入った場合には、

新しいセルに入ったときに、RA 更新を実行すること

- 4.7.3.1.5 節の c) または d)（理由値が" Retry upon entry into a new cell "以外）が原因で本ステートに入った場

合には、新しいセルに入ったときに、RA 更新を実行してはならない

- ネットワークがネットワークオペレーションモード I でオペレーションされている場合には、CM レイヤからの要

求を使用して複合 RA 更新処理をトリガする。MS は、タイマ T3311 または T3302 のうち、いずれか起動して

いる方のタイマを停止し、停止したタイマが満了したときと同様に動作すること。

4.2.5.1.5 Substate, NO-CELL-AVAILABLE（サブステート, NO-CELL-AVAILABLE）

MS は TS 03.22 [82]に従って、セルの選択／再選択を実行すること。

4.2.5.1.6 Substate, LIMITED-SERVICE（サブステート, LIMITED-SERVICE）

MS は TS 03.22 [82]に従って、セルの選択／再選択を実行すること。

4.2.5.1.7 Substate, ATTEMPTING-TO-UPDATE-MM （サブステート, ATTEMPTING-TO-UPDATE-MM）

MS は以下の処理を実行すること。

- TS 03.22 [82]に従って、セルの選択／再選択を実行すること

- ユーザデータとシグナリング情報の送受信

- タイマ T3311 または T3302 が満了したならば、"combined RA/LA updating with IMSI attach"を通知して RA更新を実行

- サービスセルの RA が変更され、かつそのセルが属する LA が禁止 LA にリストされていない場合には、

"combined RA/LA updating with IMSI attach" を通知して、RA 更新を実行

オペレーションモード C または A の GPRS MS は、ページングリクエストに対して応答すること。

オペレーションモード B の GPRS MS は、ページングリクエストに対して応答してもしなくてもよい。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 64

4.3 MM common procedures（MM共通の処理） 4.1.1 節に説明したように、MM 共通の処理は、ネットワークと MS の間に RR コネクションが存在するときはいつでも

開始することができる。

4.3.1 TMSI reallocation procedure（TMSI再配置処理） TMSI 再配置処理の目的は、アイデンティティの機密性を提供すること、つまり侵入者によってユーザのアイデンティ

ティとその位置が特定されないように保護することにある（GSM 02.09, 03.20 ,TS 33.102 参照）。

アイデンティティ機密性提供サービス（identity confidentiality service）が IMSI に対して適用される場合には、TMSI （Temporary Mobile Subscriber Identity）を使用して無線インタフェースのシグナリング処理においてユーザを特定す

る。

TMSI の構造は TS 23.003 で規定される。TMSI は LA 内でのみ有効である。その LA の外では、明確なアイデンテ

ィティを提供するために、LAI （Location Area Identifier）と TMSI を組み合わせる必要がある。

通常は低限 LA が変更される時には必ず、TMSI 再配置が実行される（そのような選択はネットワークオペレータ

に委ねられる）。

TMSI 再配置は、そのセッション内で定義されたユニークな処理手順によって実行することもできるし、あるいは

TMSI を使用して LA 更新処理によって暗黙裡に実行することもできる。TMSI の暗黙裡の再配置については、その

処理といっしょに説明される。

MS が提供した TMSI が、例えばデータベースのエラーなどによって、ネットワークにとって未知のものであった場合

には、ネットワークは MS に対してその IMSI（ International Mobile Subscriber Identity）を提供するよう要求すること

ができる。この場合、TMSI 再配置処理を開始する前に、識別処理 (4.3.3 節参照)を使用すること。

ネットワークと MS の間に RR コネクションが存在するときはいつでも、ネットワークは TMSI 再配置を開始することが

できる。

注 1: 通常、TMSI 再配置は暗号化モードで実行される

注 2: 通常、TMSI 再配置は他の処理、例えば位置登録更新や呼のセットアップなど（TS 29.002 参照）といっ

しょに実行される

4.3.1.1 TMSI reallocation initiation by the network （ネットワークによる TMSI再配置の開始）

ネットワークは、MS に対して TMSI REALLOCATION COMMAND メッセージを送信し、タイマ T3250 を起動して、

TMSI 再配置処理を開始する。

TMSI REALLOCATION COMMAND メッセージ中には、TMSI とネットワークが割当てた LAI の新しい組合せ、ま

たは使用された TMSI を削除する必要がある場合には LAI と IMSI の組合せが含まれる。通常、ネットワークは暗

号化モードの RR コネクションを使用して、TMSI-REALLOCATION COMMAND メッセージを MS に対して送信する

（GSM 03.20、TS 33.102 参照）。

4.3.1.2 TMSI reallocation completion by the mobile station （MSによる TMSI再配置の完了）

TMSI REALLOCATION COMMAND メッセージを受信した MS は、その SIM カード内に LAI（Location Area Identifier）を保持する。受信した識別子が、関連する MS の IMSI であった場合には、MS は TMSI を全て削除する。

受信した識別子が、関連する TMSI であった場合には、MS はその SIM カード内に TMSI を保持する。いずれの場

合でも、MS はネットワークに TMSI REALLOCATION COMPLETE メッセージを送信する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 65

4.3.1.3 TMSI reallocation completion in the network （ネットワークにおける TMSI再配置の完了）

TMSI REALLOCATION COMPLETE メッセージを受信したネットワークは、タイマ T3250 を停止し、新しい TMSI が有効であると見なすか、あるいは MS に対して IMSI が送信されたならば旧 TMSI が削除されたものと見なす。

RR コネクションがもう必要でないならば、ネットワークは RR サブレイヤに対して RR コネクションの開放を要求する

（GSM 04.18 の 3.5 節、 TS 25.331 の 8.2.2 節参照）。

4.3.1.4 Abnormal cases（異常なケース）

MS 側では、

MS は、新しい TMSI を含む TMSI REALLOCATION COMMAND またはその他のメッセージ（例えば

LOCATION UPDATING ACCEPT）を受信したならば直ちに、新しい TMSI と、もしあれば新しい LAI を有効

と見なして、旧 TMSI と旧 LAI を削除すること。これ以降のステージにおける RR コネクションのエラーは、

TMSI および LAI の保持に何もインパクトを与えない。

ネットワーク側では、

(a) RR コネクションでエラーが発生した場合

TMSI REALLOCATION COMPLETE メッセージを受信する前に RR コネクションを失った場合、全ての

MM コネクション（もしあれば）を開放し、一定のリカバリタイムの間は新旧双方の TMSI が占有されている

と見なすこと。

この間、ネットワーク側では以下の処理を行うことができる。

- CM レイヤ上のネットワーク発トランザクションの場合、IMSI を使用してページングするこができる。MSから応答がきてから、TMSI 再配置を再開する。

- MS が新しい TMSI を RR コネクションのためのモバイル発信の要求に使用する場合には、新しい

TMSI を有効であると見なす

- MS が旧 TMSI を使用した場合には、識別処理を使用して、その後に新しい TMSI 再配置を行う

上記以外の実装も可能。

(b) Expiry of timer T3250: タイマ T3250 の満了

TMSI 再配置は、ネットワーク側ではタイマ T3250 によって監視される。初にタイマ T3250 が満了したな

らば、ネットワークは RR コネクションを開放することができる。この場合、ネットワークは再配置処理を中

断し、もしあれば全ての MM コネクションを開放し、RR コネクションでエラーが発生した場合の規則に従う

こと。

図図図図 4.1/TS 24.008: TMSI 再配置シーケンス再配置シーケンス再配置シーケンス再配置シーケンス

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 66

4.3.2 Authentication procedure（認証処理）

4.3.2a Authentication procedure used for a UMTS authentication challenge （UMTS認証チャレンジに使用される認証処理）

認証処理の目的は、以下の 4 つである（TS 33.102 参照）。

第一に、MS が提供するアイデンティティが受け入れ可能なものであるか否か、ネットワークがチェックできる

ようにすること。

第二に、新しい UMTS 暗号鍵を計算するためのパラメータを MS に提供すること。

第三に、新しい UMTS 完全鍵を計算するためのパラメータを MS に提供すること。

第四に、MS がネットワークを認証できるようにすること。

認証処理を使用すべきケースについては、TS 33.102 で規定されている。

UMTS 認証処理は常に、ネットワーク側から開始され制御される。しかし、ネットワークが送信した UMTS 認証チャ

レンジを MS が拒否することもできる。GSM／UMTS の無線アクセスをサポートする ME は、UMTS 認証チャレンジ

をサポートすること。

GSM／UMTS 内で UMTS 認証チャレンジが実行されたときに、MS とネットワーク内で UMTS セキュリティコンテキ

ストが確立される。UMTS 認証が正常に終了した後、UMTS 暗号鍵、UMTS 完全鍵、GSM 暗号鍵、そして暗号鍵シ

ーケンス番号がネットワークと MS 双方で保持される。

4.3.2b Authentication Procedure used for a GSM authentication challenge （GSM認証チャレンジに使用される認証処理）

認証処理の目的は、以下の 2 つである（GSM 03.20 参照）。

第一に、MS が提供するアイデンティティが受け入れ可能なものであるか否か、ネットワークがチェックできる

ようにすること。

第二に、新しい GSM 暗号鍵を計算するためのパラメータを MS に提供すること。

認証処理を使用すべきケースについては、GSM 02.09 で規定されている。

UMTS 認証処理は常に、ネットワーク側から開始され制御される。GSM または UMTS の無線アクセスをサポートす

る ME は、UMTS 認証チャレンジをサポートすること。

GSM または UMTS 内で GSM 認証チャレンジが実行されたときに、MS とネットワーク内で GSM セキュリティコンテ

キストが確立される。GSM 認証が正常に終了した後に、GSM 暗号鍵と暗号鍵シーケンス番号がネットワークと MS双方で保持される。

4.3.2.1 Authentication request by the network（ネットワークからの認証要求）

ネットワークは、無線インタフェース上で AUTHENTICATION REQUEST メッセージを送信し、タイマ T3260 をスター

トさせて認証処理を開始する。AUTHENTICATION REQUEST メッセージには、応答パラメータを計算するために必

要なパラメータが含まれる（GSM 認証チャレンジについては GSM 03.20 を、UMTS 認証チャレンジについては TS 33.102 を参照）。GSM 認証チャレンジの場合には、AUTHENTICATION REQUEST メッセージにも GSM 暗号鍵シ

ーケンス番号が含まれる。GSM 暗号鍵シーケンス番号は鍵に割当てられた値であり、与えられたパラメータから計

算することができる。UMTS 認証チャレンジの場合には、AUTHENTICATION REQUEST メッセージにも暗号鍵シー

ケンス番号が含まれる。暗号鍵シーケンス番号は、UMTS 暗号鍵、UMTS 完全鍵、GSM 暗号鍵の組合せに割当て

られた値であり、与えられたパラメータから計算することができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 67

4.3.2.2 Authentication response by the mobile station （MSからの認証応答）

RR コネクションが存在する限り、MS は AUTHENTICATION REQUEST メッセージに対していつでも応答すること。

4.3.2.5.1 節で説明したケースを除き、MS はチャレンジ情報を処理し、ネットワークに AUTHENTICATION RESPONSE メッセージを送り返すこと。

GSM 認証チャレンジにおいては、チャレンジ情報から算出した新しい GSM 暗号鍵を、古い GSM 暗号鍵に上書きし、

前に保存した UMTS 暗号鍵と UMTS 完全鍵を削除すること。新しい GSM 暗号鍵は、暗号鍵シーケンス番号といっ

しょに SIM カード上に保存すること。

UMTS 認証チャレンジにおいては、新しい UMTS 暗号鍵、新しい GSM 暗号鍵、そして新しい UMTS 完全鍵をチャ

レンジ情報から算出し、古い UMTS 暗号鍵、古い GSM 暗号鍵、そして古い UMTS 完全鍵に上書きすること。新し

い UMTS 暗号鍵、GSM 暗号鍵、新しい UMTS 完全鍵は、暗号鍵シーケンス番号といっしょに SIM カード上に保存

すること。

SIM カードは、ネットワークからの認証チャレンジに基づいて MS に対して認証応答を提供する。UMTS 認証チャレ

ンジが行われた結果、SIM カード内で RES が ME にパスされる。GSM 認証チャレンジが行われた結果、SIM カード

内で SRES が ME にパスされる。

4.3.2.3 Authentication processing in the network（ネットワークにおける認証処理）

AUTHENTICATION RESPONSE メッセージを受信したネットワークは、タイマ T3260 を停止し、応答の有効性を検

証する（GSM 認証チャレンジについては GSM 03.20、UMTS 認証チャレンジについては TS 33.102 を参照）。

AUTHENTICATION FAILURE メッセージを受信したネットワークは、タイマ T3260 を停止する。Synch（同期）エラー

の場合には、CN は HLR/AuC とネゴシエーションし、MS に新たな認証パラメータを提供することもできる。

4.3.2.4 Ciphering key sequence number（暗号鍵シーケンス番号）

認証および暗号化のためのセキュリティパラメータは、組合せ（セット）として組み合わされている。GSM 認証チャレ

ンジの場合、チャレンジパラメータ RAND から認証応答パラメータ SRES と GSM 暗号鍵の双方が算出され、IMSI と秘密鍵を関連付ける。UMTS 認証チャレンジの場合、チャレンジパラメータ RAND から認証応答パラメータ RES と

UMTS 暗号鍵と UMTS 完全鍵が算出されて、IMSI と秘密鍵を関連付ける。それに加えて GSM 暗号鍵は、UMTS暗号鍵と UMST 完全鍵から、鍵がかけられていない変換関数（unkeyed conversion function）を使用して算出するこ

とができる。

認証なしで RR コネクション上で暗号化を開始することを可能にするために、暗号鍵シーケンス番号が導入された。

暗号鍵シーケンス番号はネットワークによって管理され、暗号鍵シーケンス番号を含む AUTHENTICATION REQUEST メッセージを GSM 暗号鍵に対して割当てる（GSM 認証チャレンジの場合）、またはメッセージ内の

RAND パラメータから UMTS 暗号鍵と UMTS 完全鍵を算出する（UMTS 認証チャレンジの場合）。

MS は、GSM 暗号鍵（GSM 認証チャレンジの場合）、および UMTS 暗号鍵と UMTS 完全鍵（UMTS 認証チャレンジ

の場合）といっしょに暗号鍵シーケンス番号を保存し、ネットワークに対して初のメッセージ（LOCATION UPDATING REQUEST, CM SERVICE REQUEST, PAGING RESPONSE, CM RE-ESTABLISHMENT REQUEST ）中で、どの暗号鍵シーケンス番号が GSM 暗号鍵（GSM 認証チャレンジの場合）または UMTS 暗号鍵、

UMTS 完全鍵、そして誘導された GSM 暗号鍵（UMTS 認証チャレンジの場合）を保存しているかを通知する。

暗号鍵シーケンス番号が削除される場合には、このことは関連する GSM 暗号鍵、UMST 暗号鍵、そして UMTS 完

全鍵も無効として見なす必要があることを意味する（つまり、確立された GSM セキュリティコンテキストまたは UMTSセキュリティコンテキストは無効と見なされる）。

GSM では、保存されている暗号鍵シーケンス番号と MS から送信された暗号鍵シーケンス番号が一致する場合に

は、ネットワークは保存された GSM 暗号鍵で暗号化を開始することもできる（ただし、GSM 02.09 で与えられる制約

のもとで）。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 68

UMTS では、保存されている暗号鍵シーケンス番号と MS から送信された暗号鍵シーケンス番号が一致する場合に

は、ネットワークは保存された UMTS 暗号鍵と UMTS 完全鍵で暗号化を開始することもできる（ただし、GSM 02.09 および TS 33.102 で与えられる制約のもとで）。

注: いくつかの仕様書では、暗号鍵シーケンス番号という用語の代わりに KSI(Key Set Identifier)という用

語が使用されれている。

4.3.2.5 Authentication not accepted by the network （ネットワークが認証を受理しなかった場合）

認証が失敗した場合、つまり応答が有効でなかった場合には、MS によって使用される 2 つの異なる識別方法を、ネ

ットワークは区別することができる。

- TMSI が使用された場合

- IMSI が使用された場合

TMSI が使用されていた場合には、ネットワークは識別処理を開始することを決定することができる。MS によって与

えられた IMSI の値が、ネットワークが TMSI と関連付けた値と異なる場合には、正しいパラメータを使用して認証を

再開すること。MS によって提供される IMSI の値が、予想された値だった（つまり認証が本当に失敗した）場合には、

ネットワークは次に述べる手順を開始すること。

TMSI が使用されていた場合、あるいはネットワークが識別処理を試行しないことを決定した場合には、

AUTHENTICATION REJECT メッセージを MS に送信すること。

本メッセージを送信後、（もしあれば）進行中の全ての MM コネクションを開放し、ネットワークは 04.18 の 3.5 節

（GSM の場合）または TS 25.331 の 3.5 節（UMTS の場合）に説明される手順に従って、RR コネクション開放処理を

開始すること。

AUTHENTICATION REJECT メッセージを受信したならば、MS は SIM カード内の更新ステータスを U2 ROAMING NOT ALLOWED に設定し、SIM カードに保存されている TMSI、LAI、暗号鍵シーケンス番号を削除すること。MSの電源が切断されるまで、または SIM カードが抜かれるまで、SIM カードは無効と見なすこと。

ステート IMSI DETACH INITIATED にある MS が AUTHENTICATION REJECT メッセージを受信したならば、

4.3.4.3 節の記載に従うこと。

その他のステートにある MS が AUTHENTICATION REJECT メッセージを受信した場合、全ての MM 固有の処理、

MM コネクション確立または呼の再確立処理を中断し、（もし起動されている場合には）タイマ T3210 または T3230の双方を停止し、（もし存在する場合には）MM コネクションを開放し、タイマ T3240 を起動し、ステート WAIT FOR NETWORK COMMAND に入り、RR コネクションの開放を待つこと。タイマ T3240 によって制御される所定時間内

に RR コネクションが開放されなかった場合には、MS は RR コネクションを中断すること。RR コネクションがネットワ

ーク側からのトリガによって開放された場合でも、MS 側からの要求によって開放された場合でも、MS はステート

MM IDLE、サブステート NO IMSI に入る。MS が他の CN ノードに対して別の進行中の RR コネクションを持ってい

る場合には、MS はその別のコネクションはまだ有効とみなすこと。

4.3.2.5.1 Authentication not accepted by the MS （認証が MSによって拒否された場合）

UMTS 認証チャレンジにおいては、認証処理は拡張され、MS が CN の信頼性をチェックすることができるようになっ

ている。こうすることによって、例えば偽基地局を検出することが可能になる。

R99 の CN に接続された R99 GSM 専用 MS は（たとえ GSM の RAN を使用していても）、UMTS 認証チャレンジを

サポートすること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 69

UMTS 認証チャレンジの結果、MS は AUTN パラメータが正しくないという理由で CN を拒否することができる（TS 33.102 参照）。本パラメータには、認証が失敗した理由を 2 つまで含めることができる。

a) MAC code failure（MAC コードのエラー）

MS が MAC コード（CN から AUTN パラメータ内で提示される）が無効と判定した場合には、MS はネット

ワークに拒否理由'MAC failure'といっしょに THENTICATION FAILURE メッセージを送信すること。次に

MS は 4.3.2.6 (c)節で説明される処理手順に従うこと。

b) SQN failure（SQN エラー）

MS が（CN から AUTN パラメータ内で提示された）SQN が範囲外にあると判定した場合には、MS はネッ

トワークに拒否理由'Synch failure'、および SIM カードが提供するトークン AUTS(TS 33.102 参照)といっし

ょに AUTHENTICATION FAILURE メッセージを送信すること。次に MS は 4.3.2.6 (d)節で説明される処

理手順に従うこと。


(a) RR connection failure（RR コネクションのエラー）:

AUTHENTICATION RESPONSE を受信する前に RR コネクションのエラーを検出したならば、ネットワークは

（もしあれば）MM コネクションを開放し、進行中の MM 固有の処理を全て中断すること。

(b) Expiry of timer T3260（タイマ T3260 の満了）:

ネットワーク側の認証処理はタイマ T3260 によって監視される。このタイマが満了したならば、ネットワークは

RR コネクションを開放することができる。この場合、ネットワークは認証処理と進行中の MM 固有の処理を全

て中断し、もしあれば MM コネクションを開放し、3.5 節で説明した RR コネクション開放処理を開始すること。

(c) Authentication failure (reject cause ‘MAC failure’)（認証の失敗（拒否理由‘MAC failure’））:

MS は、拒否理由‘MAC failure’といっしょに AUTHENTICATION FAILURE メッセージをネットワークに送信

し、タイマ T3214 を開始すること。MS から拒否理由‘MAC failure’といっしょに AUTHENTICATION FAILURE メッセージを受信したならば、ネットワークは 4.3.3 節で説明される識別処理を開始することができ

る。そうすることによってネットワークが MS から IMSI を獲得することができる。次にネットワークはもともと認

証チャレンジ内で使用された TMSI の値が正しい IMSI と一致するか否かをチェックすることができる。ネット

ワークから IDENTITY REQUEST メッセージを受信した MS は IDENTITY RESPONSE メッセージを送信する

こと。

ネットワーク内の TMSI/IMSI マッピングが正しくなかった場合には、ネットワークは MS に新たな

AUTHENTICATION REQUEST メッセージを送信して応答すること。ネットワークから AUTHENTICATION REQUEST を受信した MS は、タイマ T3214 が起動されている場合にはそれを停止し、次に通常通りチャレン

ジ情報を処理すること。

MS がネットワークから初に受信した AUTHENTICATION REQUEST 内に無効な MAC が含まれていた

場合には、MS は現在起動中の再送タイマ（つまり T3210, T3220,または T3230）を全て停止すること。

ネットワークを正常に有効化できた場合（有効な MAC が含まれる AUTHENTICATION REQUEST を受信し

た場合）、MS はネットワークに AUTHENTICATION RESPONSE メッセージを送信すること。また MS が有効

な MAC が含まれる初の AUTHENTICATION REQUEST メッセージを受信したときに、起動中の再送タイ

マ（T3210, T3220,または T3230 など）を停止させた場合には、それらを全てスタートさせること。

以下の現象が発生した場合には、認証チャレンジの発信元は不正と見なすことができる（認証は MS によって

受け付けられない）。

- 拒否理由‘MAC failure’といっしょに AUTHENTICATION FAILURE メッセージを送信した後、タイマ

T3214 が満了した場合

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 70

- タイマ T3214 が起動中に 2 回目の AUTHENTICATION REQUEST を受信し、かつ MAC の値が解決で

きない場合

MS が認証チャレンジの発信元が正当でないと判断した場合（つまり MS が認証を拒否した場合）、MS は

4.3.2.6.1 節で説明するように動作すること。

MS NetworkAUTHENTICATION REQUEST

Start T3260

AUTH FAILURE (cause=’MAC failure’)Stop T3260

IDENTITY REQUEST

IDENTITY RESPONSE (IMSI)

AUTHENTICATION REQUEST

AUTHENTICATION RESPONSE

Start T3214

Stop T3214

Start T3270

Stop T3270

Start T3260

Stop T3260

図図図図 4.2/TS 24.008: 認証失敗処理認証失敗処理認証失敗処理認証失敗処理 (拒否理由拒否理由拒否理由拒否理由 ‘MAC failure’)

(d) Authentication failure (reject cause ‘synch failure’)（認証の失敗（拒否理由‘synch failure’））:

MS は、拒否理由‘synch failure’といっしょに AUTHENTICATION FAILURE メッセージをネットワークに送信

し、タイマ T3216 をスタートさせること。MS から拒否理由‘synch failure’といっしょに AUTHENTICATION FAILURE メッセージを受信したならば、ネットワークは再同期するために AUTHENTICATION FAILURE メ

ッセージ内の認証が失敗したパラメータ IE から返された AUTS パラメータを使用すること。

有効な SQN を含む初の AUTHENTICATION REQUEST メッセージを MS がネットワークから受信したな

らば、MS は現在起動している再送タイマ（つまり T3210, T3220,または T3230）を全て停止すること。

タイマ T3216 が起動中にネットワークの有効性判断が正常に終了したならば（有効な SQN を含む第 2 の

AUTHENTICATION REQUEST メッセージを受信したならば）、MS はネットワークに AUTHENTICATION RESPONSE メッセージを送信すること。また MS が有効な SQN が含まれる初の AUTHENTICATION REQUEST メッセージを受信したときに、起動中の再送タイマ（T3210, T3220,または T3230 など）を停止させた

場合には、それらを全てスタートさせること。

タイマ T3216 が起動中に、MS が有効な SQN が含まれる第 2 の AUTHENTICATION REQUEST メッセージ

を受信した場合には、MS は 4.3.2.6.1 節で規定されたように動作すること。

タイマ T3216 が満了した場合には、MS は 4.3.2.6.1 節で規定されたように動作すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 71

MS NetworkAUTHENTICATION REQUEST Start T3360

AUTH FAILURE (cause=’Synch failure’) Stop T3360



Start T3216

Stop T3216

PerformRe-synchwith HLR

MS NetworkAUTHENTICATION REQUEST Start T3260

AUTH FAILURE (cause=’Synch failure’) Stop T3260



Start T3216

Stop T3216


図図図図 4.2a/TS 24.008: 認証失敗処理認証失敗処理認証失敗処理認証失敗処理 (拒否理由拒否理由拒否理由拒否理由‘Synch failure’)

4.3.2.6.1 MS behaviour towards a network that has failed the authentication procedure （認証処理に失敗したネットワークに対する MSの動作）

ネットワークが認証チェックに失敗したと MS が判断した場合には、MS はシステム情報データがリフレッシュされるま

で、AUTHENTICATION REQUEST メッセージを受信したセルを禁止（barred）として扱うこと。MS が有効な MAC ま

たは SQN が含まれる初の AUTHENTICATION REQUEST メッセージ受信時に起動中の再送タイマ（T3210, T3220,または T3230 など）を停止させた場合には、それらを全て起動させること。

4.3.2.7 Handling of keys at intersystem change from UMTS to GSM （UMTS→GSMへのシステム間変更時の鍵の扱い）

UMTS→GSM へのシステム間変更時には、認証処理を改めて行うことなく暗号化を開始することができる（GSM 04.18 参照）。GSM 内の暗号化用の適切なセキュリティ鍵をどれだけ省略できるかは、MS とネットワーク内に保存さ

れている現行の GSM/UMTS セキュリティコンテキストによって決まる。

表 4.3.2.7.1 に従って、ME は GSM 暗号鍵を処理すること。

表表表表 4.3.2.7.1/TS 24.008: UMTS からからからから GSM へのシステム間変更（へのシステム間変更（へのシステム間変更（へのシステム間変更（Intersystem change from UMTS to GSM））））

UMTS の MS とネットワーク内のセキュリティ

コンテキストの確立

GSM へのシステム間変更時

GSM セキュリティコンテキスト

ME は SIM カード内にある GSM セキュリティコンテキストから受け

取った GSM 暗号鍵を適用すること

UMTS セキュリティコンテキスト

ME は SIM カードが UMTS 暗号鍵と UMTS 完全鍵から誘導した

GSM 暗号鍵を適用すること

注 UMTS セキュリティコンテキストを持つ SIM カードは、現行の無線アクセスが UMTS か GSM かに関わ

らず、UMTS 暗号鍵、UMTS 完全鍵、そして誘導された GSM 暗号鍵を ME にパスする。

4.3.2.7a Use of established security contexts （確立されたセキュリティコンテキストの使用）

GSM 内で GSM セキュリティコンテキストが確立されている場合には、ME が RR コネクションで任意の有効な

CIPHERING MODE COMMAND メッセージを受信したとき、ME は GSM 暗号鍵を SIM カードからロードし、それを

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 72

使用すること（有効な CIPHERING MODE COMMAND メッセージの定義については、GSM 04.18 の 3.4.7.2 節参

照）。

GSM 内で UMTS セキュリティコンテキストが確立されている場合には、MS が RR コネクションで任意の有効な

CIPHERING MODE COMMAND メッセージを受信したとき、MS は GSM 暗号鍵を SIM カードからロードし、それを

使用すること（有効な CIPHERING MODE COMMAND メッセージの定義については、GSM 04.18 の 3.4.7.2 節参

照）。ネットワークは、TS 33.102 内で規定される“c3”と呼ばれる変換関数を使用して UMTS 暗号鍵と UMTS 完全鍵

から GSM 暗号鍵を誘導すること。

UMTS 内で GSM セキュリティコンテキストが確立されている場合には、ME は TS 33.102 内で規定される“c4”および “c5”と呼ばれる変換関数を使用して GSM 暗号鍵から UMTS 暗号鍵と UMTS 完全鍵を誘導すること。MS が CS ド

メインに通知される有効な SECURITY MODE COMMAND を RR コネクション上で受信したときに、MS は GSM 暗

号鍵を SIM カードからロードし、そのように誘導された UMTS 暗号鍵と UMTS 完全鍵の使用を開始すること（有効

な SECURITY MODE COMMAND メッセージの定義については、TS 25.331 参照）。ネットワークは TS 33.102 内で

規定される“c4” および“c5”と呼ばれる変換関数を使用して、 GSM 暗号鍵から UMTS 暗号鍵と UMTS 完全鍵を誘

導すること。

UMTS 内で UMTS セキュリティコンテキストが確立されている場合には、MS が CS ドメインに通知される有効な

SECURITY MODE COMMAND を RR コネクション上で受信したときに、MS は UMTS 暗号鍵と UMTS 完全鍵を

SIM カードからロードし、使用を開始すること（有効な SECURITY MODE COMMAND メッセージの定義については、

TS 25.331 参照）。

注: UMTS および GSM 内で、進行中の RR コネクションが既に暗号化されているおよび／または完全

性が保護されている場合には、ネットワークは新たな GSM/UMTS セキュリティコンテキストを確立する

ために、新しい認証処理を開始することがある。新しい有効な SECURITY MODE COMMAND メッセ

ージ（UMTS の場合）または新しい有効な CIPHERING MODE COMMAND メッセージ（GSM の場合）

が CS ドメインに対して通知されたとき、MS は新しい鍵の使用を開始する。

4.3.2.8 Handling of keys at intersystem change from GSM to UMTS （GSM →UMTSへのシステム間変更時の鍵の扱い）

GSM →UMTS へのシステム間変更時には、認証処理を改めて行うことなく暗号化を開始することができる（TS 25.331 参照）。UMTS 内の暗号鍵と完全鍵のチェックをどれだけ省略できるかは、MS とネットワーク内に保存されて

いる現行の GSM/UMTS セキュリティコンテキストによって決まる。

表 4.3.2.8.1 に従って、ME は UMTS 暗号鍵と UMTS 完全鍵を処理すること。

表表表表 4.3.2.8.1/TS 24.008:GSM からからからから UMTS へのシステム間変更（へのシステム間変更（へのシステム間変更（へのシステム間変更（Intersystem change from GSM to UMTS））））

GSM の MS とネットワーク内のセキュリティコ

ンテキストの確立

UMTS へのシステム間変更

GSM セキュリティコンテキスト

ME は SIM カードから提供された GSM 暗号鍵から UMTS 暗号鍵と UMTS 完全鍵を誘導する。そのために TS 33.102 内で"c4" およ

び"c5"と呼ばれる変換関数が使用される UMTS セキュリティコンテキスト ME は SIM カード内にある UMTS セキュリティコンテキストから受信

した UMTS 暗号鍵と UMTS 完全鍵を適用すること

注 UMTS セキュリティコンテキストを持つ SIM カードは、現行の無線アクセスが UMTS か GSM かにかか

わりなく、UMTS 暗号鍵、UMTS 完全鍵、そして誘導された GSM 暗号鍵を ME にパスする。

4.3.2.9 Void

4.3.3 Identification procedure（通知処理）識別処理は、ネットワークが MS に対して特定の識別パラメータ（例えば IMSI、IMEI など、TS 23.003 参照）を提供

するよう要求するために使用される。IMEI の提示に際しては、GSM 02.09 の要求条件が適用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 73

4.3.3.1 Identity request by the network（ネットワークによる識別要求）

ネットワークは MS に対して IDENTITY REQUEST メッセージを送信して、タイマ T3270 をスタートさせて識別処理を

開始する。IDENTITY REQUEST メッセージは、identity type IE 内のパラメータとして要求された識別パラメータを指

定する。

4.3.3.2 Identification response by the mobile station（MSによる識別応答）

MS は RR コネクションが存在する限り、いつでも IDENTITY REQUEST メッセージに対して応答できるようにするこ

と。

IDENTITY REQUEST メッセージを受信した MS は、IDENTITY RESPONSE メッセージを返す。IDENTITY RESPONSE メッセージには、ネットワークが要求した識別パラメータが含まれる。

IDENTITY RESPONSE を受信したネットワークは、タイマ T3270 を停止させること。


(a) RR connection failure（RR コネクションのエラー）:

IDENTITY RESPONSE メッセージを受信する前に RR コネクションでエラーが発生した場合、ネットワークは

（もし存在する場合には）MM コネクションを開放し、進行中の MM 固有の処理を全て中断すること。

(b) Expiry of timer T3270（タイマ T3270 の満了）:

識別処理はタイマ T3270 によって管理される。タイマ T3270 が満了したならば、ネットワークは RR コネクショ

ンを開放することができる。この場合、ネットワークは識別処理、進行中の全ての MM 固有の処理、そして存

在する場合には全ての MM コネクションを中断し、GSM 04.18 の 3.5 節および 25.331 の 8.2.1 節で規定され

る RR コネクション開放処理を開始すること。

図図図図 4.3/TS 24.008:識別シーケンス（識別シーケンス（識別シーケンス（識別シーケンス（ Identification sequence））））

4.3.4 IMSI detach procedure（IMSIデタッチ処理） MS が非アクティブにされた場合、または加入者識別モジュール（Subscriber Identity Module 、GSM 02.17 および 31.102 参照）が MS からデタッチされた場合、MS は IMSI デタッチ処理を開始することができる。

GSM の場合、ネットワークは BCCH 上の L3-RR SYSTEM INFORMATION TYPE 3 メッセージ内のフラグ(ATT)ブロードキャストを使用して、デタッチ処理が必要性の有無を通知する。考慮すべき ATT フラグの値は、MS が MM ア

イドルモードにある場合のブロードキャストの値である。

UMTS の場合、ネットワークは BCCH 上の L3-RRC SYSTEM INFORMATION BLOCK 1 メッセージ内のフラグ

(ATT)ブロードキャストを使用して、デタッチ処理が必要性の有無を通知する。考慮すべき ATT フラグの値は、MSが MM アイドルモードにある場合のブロードキャストの値である。

この処理の結果、MS はネットワーク内で非アクティブとしてマークされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 74

4.3.4.1 IMSI detach initiation by the mobile station （MSによる IMSI デタッチの開始）

IMSI デタッチ処理は、MS からネットワークに送信される IMSI DETACH INDICATION メッセージだけから構成され

る。次に MS はタイマ T3220 をスタートさせ、MM サブレイヤステート IMSI DETACH INITIATED に入る。

RR コネクションが存在しない場合には、MS 内の MM サブレイヤは RR サブレイヤに対して RR コネクションの確立

を要求する。適切なセルが（まだ）存在しないために、RR コネクションを確立することが不可能な場合には、MS は 5秒～20 秒の周期で適切なセルサーチを試行すること。この時間内に適切なセルが見つかった場合には、MS は次に

RR サブレイヤに対して RR コネクションの確立を要求する。見つからなかった場合には IMSI デタッチ処理は中断さ

れる。

RR コネクションが存在する場合、MM サブレイヤは IMSI DETACH INDICATION メッセージを送信する前に、ロー

カルに進行中の MM コネクションを全て開放する。

MM 固有の処理がアクティブになった場合には、IMSI デタッチ処理を開始することはできない。可能であれば、MM固有の処理が完了するまで IMSI デタッチ処理は延期すること。それが不可能であれば IMSI デタッチ処理は省略さ

れる。

4.3.4.2 IMSI detach procedure in the network （ネットワーク内の IMSIデタッチ処理）

ネットワークは IMSI DETACH INDICATION メッセージを受信したならば、IMSI に関するインアクティブ通知を設定

することができる。MS に対して応答は返されない。IMSI DETACH INDICATION メッセージを受信後、ネットワーク

は進行中の MM コネクションを全てローカルに開放し、通常の RR コネクション開放処理を開始すること（GSM 04.18の 3.5 節と 25.331 の 8.2.1 節参照）。

VGCS をサポートするネットワークにのみ適用：ネットワークのサービスステートが MM CONNECTION ACTIVE (GROUP TRANSMIT MODE)のときに、ネットワークがグループ呼内のトーキング MS から IMSI DETACH INDICATION を受信した場合、ネットワークは進行中の MM コネクションを全てローカルに開放し、次にサービスス

テート GROUP CALL ACTIVE に移行すること。

4.3.4.3 IMSI detach completion by the mobile station （MSによる IMSIデタッチの完了）

RR コネクション開放時にタイマ T3220 は停止される。MS は、可能であればローカルなチャネルの開放処理を延期

させて、ネットワーク側にタイマ T3220 のタイムアウトによる通常のチャネル開放をさせること。それが不可能な場合

（例えば電源断時のデタッチなど）には、MS 側の RR サブレイヤを中断すること。


RR コネクションの確立が失敗した場合、または RR コネクションが失われた場合には、IMSI デタッチ処理は MS に

よって中断される。

図図図図 4.4/TS 24.008: IMSI デタッデタッデタッデタッチシーケンス（チシーケンス（チシーケンス（チシーケンス（ IMSI detach sequence））））

4.3.5 Abort procedure（中断処理）進行中の任意の MM コネクションの確立、または既に確立された MM コネクションを中断するために、ネットワーク

は中断処理を起動することができる。少なくとも 1 つの MM コネクションが存在する場合、または MM コネクションが

確立中の場合に限り、MS は ABORT メッセージを現在のプロトコルステートと互換性のあるものとして扱うこと。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 75

4.3.5.1 Abort procedure initiation by the network （ネットワークによる中断処理の開始）

中断処理はネットワークから MS に送信される ABORT メッセージだけから構成される。ABORT メッセージを送信す

る前に、ネットワークはローカルに進行中の MM コネクションを全て開放すること。メッセージ送信後、ネットワークは

通常の RR コネクション開放処理を開始することができる。

中断した理由は Cause IE（Cause information element）で通知される。以下の理由値が適用される。

# 6: Illegal ME（不正 ME）

#17: Network failure（ネットワークエラー）

4.3.5.2 Abort procedure in the mobile station（MSにおける中断処理）

ABORT メッセージを受信した MS は、MM コネクション確立処理または呼再確立処理を中断し、（もしあれば）全て

の MM コネクションを開放すること。理由値#6 を受信した MS は、SIM カード上に保持している TSMI,LAI,暗号鍵シ

ーケンス番号を全て削除し、更新ステータスを ROAMING NOT ALLOWED に設定し（そしてその値を 4.1.2.2 節の

記載に従って SIM カード上に保持し）、電源が切断されるまで、または SIM カードが抜かれるまで、該当 SIM カード

は無効であると見なすこと。

次に MS はネットワークが RR コネクションを開放するのを待つこと。4.5.3.1 節参照。

4.3.6 MM information procedure（MM情報処理） MM 情報処理メッセージのサポートは、ネットワーク側のオプションである。

RR コネクションが存在する場合には、ネットワークはいつでも MM 情報処理を起動することができる。

4.3.6.1 MM information procedure initiation by the network （ネットワークによる MM情報処理の開始）

MM 情報処理は、ネットワークから MS に送信される MM INFORMATION メッセージだけから構成される。RR コネ

クション上で、ネットワークは 0、1 つ、または複数の MM INFORMATION メッセージを MS に対して送信すること。

複数の MM INFORMATION メッセージが送信された場合には、メッセージの内容が同じである必要はない。

注: ネットワークは、CM レイヤのトランザクションに遅延を加えたり干渉することがないように、MM INFORMATION メッセージを送信する瞬間を選択することができる。例えば、AUTHENTICATION REQUEST メッセージの直後など。

4.3.6.2 MM information procedure in the mobile station （MS内の MM情報処理）

（MM 情報メッセージをサポートする）MS が MM INFORMATION メッセージを受信した場合には、MS はメッセージ

を受理して、オプションとして内容を使用して MS 内に保存されている適切な情報を更新すること。

MS が MM 情報メッセージをサポートしない場合には、MS はメッセージの内容を無視して、理由値#97 で MM STATUS メッセージを返すこと。

4.4 MM specific procedures（MM固有の処理）他の MM 固有の処理が起動されていない場合、またはネットワークと MS 間に MM コネクションが存在しない場合

に限って、MM 固有の処理を開始することができる。新しい MM 固有の処理が開始できるようになるまで、現在起動

中の MM 固有処理の終了または全 MM コネクションの開放は留保されること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 76

MM 固有の処理の有効期限内は、CM エンティティが MM コネクションの確立を要求したならば、その要求は拒否さ

れるか、あるいは起動中の MM 固有の処理が完了するまで延期される（どちらにするかは実装次第）。

（IMSI デタッチ処理を除く）全ての MM 共通の処理は、MM 固有の処理の間に開始される。

MS がネットワークから特別なパーミッション（follow-on proceed）を与えられていない限り、MS 側は新たな MM 固有

の処理または MM コネクション確立が開始されるまで、MM 固有の処理のために使用される RR コネクションが開

放されるのを待つこと。

注: ネットワーク側では MM コネクション管理用に同じ RR コネクションを使用してもよい。

4.4.1 Location updating procedure（位置登録更新処理）位置登録更新処理は、以下の目的で使用される一般的な処理である。

- 通常位置登録更新（本節で説明）

- 定期的更新（4.4.2 節参照）

- IMSI アタッチ（4.4.3 節参照）

通常位置登録更新処理は、ネットワーク内にある MS の実際の LA（Location Area）の登録を更新するために使用さ

れる。LOCATION UPDATING REQUEST メッセージ内の updating type IE が、通常位置登録更新を通知すること。

MM IDLE ステートにある MS が使用する定期的位置登録更新処理を実行する条件は、4.2.2 節の各サービスステ

ート毎に定義されている。

VGCS リスニングまたは VBS リスニングをサポートする MS にのみ適用：RR グループ受信モードにある MS は、ス

テート MM IDLE、サブステート RECEIVING GROUP CALL (NORMAL SERVICE) または RECEIVING GROUP CALL (LIMITED SERVICE)にある。位置登録更新処理を実行するために RR グループ受信モードにある MS は、

グループ受信モードを離れて、独立した個別 RR コネクションを確立して上述の位置登録処理を実行してから、その

後グループ受信モードに戻ること。

MS からの MM コネクション確立要求に対する応答として、その MS が VLR 内で未知のものであることをネットワー

クが通知した場合にも、通常の位置登録更新処理が開始されること。

位置登録更新が失敗した場合の位置登録更新試行回数を制限するために、試行カウンタが使用される。MS の電

源が投入されたとき、または SIM カードが挿入されたときに、試行カウンタはリセットされる。

位置登録更新が正常に完了した場合、MS は SIM カード内の更新ステータスを UPDATED に設定し、受信した

Location Area Identification を SIM カード内に保持する。試行カウンタをリセットすること。

試行カウンタの詳細な処理については、4.4.4.6 ～ 4.4.4.9 節に述べる。

モバイル端末（Mobile Equipment）は、「局所的サービス供給禁止 LA」（"forbidden location areas for regional provision of service"）のリストといっしょに、「ローミング用禁止 LA」（"forbidden location areas for roaming"）のリスト

を持つこと。これらのリストは、MS の電源が切断されたときまたは SIM カードが抜かれた場合に消去され、また定期

的（12 時間～24 時間の範囲内）にも消去される。MS は BCCH 上で位置登録更新要求をトリガする LAI（location area identification）を受信するが、理由値“Roaming not allowed in this location area" または"Location Area not allowed"といっしょに位置登録更新拒否メッセージを受信した場合にはいつでも、LAI を適切なリストに追加すること。

リストには、LAI を 10 個またはそれ以上登録できること。リストがいっぱいになって、新しいエントリを挿入する必要

が生じた場合には、古いエントリから削除すること。

異なるステート内のセル選択処理は、TS 03.22 および GSM 05.08 に説明される。

位置登録更新処理は常に MS 側から開始される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 77

4.4.2 Periodic updating（定期的更新） MS が利用可能な状態にあることをネットワークに通知するために、定期的更新を使用することができる。位置登録

更新処理を使用して定期的更新が実行される。LOCATION UPDATING REQUEST メッセージ内の updating type IE が定期的更新を通知すること。

MS 内では、定期的更新はタイマ T3212 によって制御される。タイマが未だ起動していない場合には、MS がステート

MM IDLE、サブステート NORMAL SERVICE または ATTEMPTing TO UPDATE に入る度に、タイマがスタートす

る。MS が MM Idle ステートから離れたならば、タイマ T3212 は満了して停止するまで走り続ける。

タイマが停止する（そして次回スタート時用に初期値に設定されること）のは、以下の場合である：

- LOCATION UPDATING ACCEPT メッセージまたは LOCATION UPDATING REJECT メッセージを受信した

場合

- AUTHENTICATION REJECT メッセージを受信した場合

- 初の MM メッセージを受信した、または MM コネクションが確立されている場合にはセキュリティモードの

設定が完了した場合。ただし近のサービスステートが LIMITED SERVICE である場合を除く。

- MS がページングに対して応答し、その後 RR メッセージ以外の正しい初の L3 メッセージを受信した場合

- MS がデアクティブの場合（つまり装置の電源が切断されている場合、または SIM カードが抜かれている場

合）

タイマ T3212 が満了したならば、位置登録更新処理を開始し、タイマを次回スタートするときのために初期値に設定

すること。タイマ満了時の MS のステートが MM Idle ステート以外のときは、MS が MM Idle に入るまで位置登録更

新処理は延期される。

MM IDLE ステートにある MS が使用する定期的位置登録更新処理を実行する条件は、4.2.2 節の各サービスステ

ート毎に定義されている。

タイマ満了時に MS がサービスステート NO CELL AVAILABLE, LIMITED SERVICE, PLMN SEARCH または PLMN SEARCH-NORMAL SERVICE にあった場合には、位置登録更新処理はこれらのサービスステートから離れ

るまで延期される。

GSM の場合、処理がトリガされたときの BCCH 情報が定期的位置登録の使用禁止を通知していた場合には、（定

期的）位置登録更新処理は開始されない。タイムアウト値は BCCH 上の L3-RR SYSTEM INFORMATION TYPE 3メッセージ内、Control channel description IE 内でブロードキャストされる。GSM 04.18 の 10.5.2.11 節参照。

UMTS の場合、処理がトリガされたときの BCCH 上の情報または後に受信した個別システム情報が定期的位置

登録の使用禁止を通知していた場合には、（定期的）位置登録更新処理は開始されない。タイムアウト値は BCCH上の L3-RRC SYSTEM INFORMATION BLOCK 1 メッセージ内でブロードキャストされる。TS 25.331 の 10.1.6.4.3節参照。

ステート NO CELL AVAILABLE, LIMITED SERVICE, PLMN SEARCH、および PLMN SEARCH-NORMAL SERVICE の場合には、T3212 のタイムアウト値を変更してはならない。

T3212 のタイムアウト値を変更する必要が生じた時にタイマが起動している場合（サービスセルの変更時、または

T3212 のブロードキャスト値の変更時）には、MS は以下のように動作すること。

t1 を新しい T3212 のタイムアウト値とし、t を T3212 のタイムアウト値が新しく変更されたときの現行のタイマ

値とすると、タイマは値 t MOD t1 で再開すること。

MS がアクティブになったとき、またはタイマ起動中に T3212 のタイムアウト値を変更する必要が生じたときには、MSは以下のように動作すること。

t1 を新しい T3212 のタイムアウト値とし、新しいタイマを 0 から t1 までの均等な乱数値でスタートさせること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 78

4.4.3 IMSI attach procedure（IMSIアタッチ処理） The IMSI アタッチ処理 is the complement of the IMSI デタッチ処理 (see section 4.3.4). It is used to indicate the IMSI as active in the network. IMSI アタッチ処理は IMSI デタッチ処理と互いに補完しあう（4.3.4 節参照）。IMSI アタッチ処理は、IMSI がネットワ

ーク内でアクティブであることを通知するために使用される。

GSM では、L3-RR SYSTEM INFORMATION TYPE 3 メッセージ内でフラグ（ATT）がブロードキャストされる。このフ

ラグは、アタッチとデタッチ処理の使用が要求されているか否かを通知する。

UMTS では、L3-RRC SYSTEM INFORMATION BLOCK 1 メッセージ内でフラグ（ATT）がブロードキャストされる。

このフラグは、アタッチとデタッチ処理の使用が要求されているか否かを通知する。

ネットワークがデタッチ／アタッチ処理を要求し、かつネットワークの圏内に在圏する MS 内の IMSI がアクティブにさ

れた場合（つまり、プラグイン SIM による MS のアクティブ化、カード運用 MS 内にカードが挿入された場合など）、あ

るいは圏外で IMSI がアクティブになった MS が圏内に入った場合に、IMSI アタッチ処理が起動される。更新ステー

タスが UPDATED で、かつ MS に保存されている LAI が現在のサービスセルから BCCH 上で実際にブロードキャ

ストされた LAI が一致した場合に限り、IMSI アタッチ処理が使用される。その他の通常位置登録処理（4.4.1 節参

照）は、ATT フラグの通知とは無関係に起動される。

SI アタッチ処理は位置登録処理を使用して実行される。この場合は、LOCATION UPDATING REQUEST メッセー

ジ内の updating type IE は、IMSI アタッチを通知すること。

4.4.4 Generic Location Updating procedure （一般的な位置登録更新処理）

4.4.4.1 Location updating initiation by the mobile station （MSによる位置登録更新の開始）

登録更新をトリガするために使用されるタイマ（T3211, T3212 など）は、もし起動していれば全て停止する。

位置登録更新処理が開始された時点では RR コネクションは存在しないので、MS 内の MM サブレイヤは RR サブ

レイヤに対して RR コネクションの確立を要求し、ステート WAIT FOR RR CONNECTION (LOCATION UPDATE)に入る。RR コネクション確立手順は、GSM 04.18 の 3.3 節および TS 25.331 の 8.2.3 節に説明されている。

MS はネットワークに LOCATION UPDATING REQUEST メッセージを送信して、タイマ T3210 をスタートさせ、ステ

ート LOCATION UPDATING INITIATED に入って、位置登録更新処理を開始する。updating type IE で、どの種類

の更新を要求するかを通知すること。

4.4.4.1a Network Request for Additional mobile station Capability Information （追加 MSケーパビリティ情報用のネットワーク要求）

GSM の場合、ネットワークはクラスマーク調査処理（classmark interrogation procedure）を開始して、例えば MS の暗

号化能力に関するより詳細な情報を収集することができる。

4.4.4.2 Identification request from the network（ネットワークからの識別要求）

例えば、ネットワークが、MS が識別に使用した TMSI および LAI に基づいて、IMSI を獲得できない場合などに、ネ

ットワークは識別処理を開始することができる（4.3.3 節参照）。

4.4.4.3 Authentication by the network（ネットワークによる認証）

MS から LOCATION UPDATING REQUEST メッセージを受信したネットワークは、認証処理（4.3.3 節参照）を開始

することができる（GSM 02.09 で定義されるケース参照）。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 79

4.4.4.4 Security mode setting by the network （ネットワークによるセキュリティモードの設定）

GSM の場合、例えば新しい TMSI を割当てる必要が生じた場合などに、ネットワークはセキュリティモード設定処理

（GSM 04.18 の 3.4.7 節参照）を開始することができる。

UMTS の場合、例えば新しい TMSI を割当てる必要が生じた場合などに、ネットワークはセキュリティモード制御処

理（TS 25.331 の 8.1.10 節参照）を開始することができる。

4.4.4.5 Attempt Counter（試行カウンタ）

位置登録更新処理が失敗した場合の位置登録試行回数に上限を設定するために、試行カウンタが使用される。位

置登録更新処理の連続失敗回数をカウントする。

位置登録更新処理が失敗した場合には、試行カウンタの値が増加する。4.4.4.9 節内に、特別な状況が規定されて

いる。

以下の場合に試行カウンタがリセットされる。

- MS 電源投入時

- SIM カード挿入時

- 位置登録更新が正常に完了した場合

- 位置登録更新が理由値#11, #12,または #13 で完了した場合（4.4.4.7 節参照）

およびサービスステートが UPDATE の場合

- MS が自分が新しい LA に入ったことを検出した場合

- タイマ T3212 の満了

- CM サブレイヤの要求によって、位置登録更新がトリガされた場合

タイマ T3211 がタイムアウト後、位置登録更新を再試行するか否かを決定するために、試行カウンタが使用される。

4.4.4.6 Location updating accepted by the network （ネットワークによる位置登録更新試行）

ネットワークが（MS の）位置登録更新を受理した場合に、LOCATION UPDATING ACCEPT メッセージが MS に送

信される。

アイデンティティ機密保持サービス（identity confidentiality service）がアクティブな場合（ 4.3.1 節および 4.4.4.4 節参

照）には、TMSI 再割当が位置登録更新処理の一部となることもある。その後、LAI といっしょに LOCATION UPDATING ACCEPT メッセージ内に TMSI 割当が入れられる。この場合、ネットワークは 4.3.1 節に述べられたよう

にタイマの監視を開始すること。

MS に MM コネクションの確立をさせるために、ネットワークが RR コネクションの延長を希望する場合（例えば MSが LOCATION UPDATING REQUEST 中で MS が follow-on request pending を持っていることを通知した場合な

ど）には、ネットワークは LOCATION UPDATING ACCEPT 中で"follow on proceed"を送信して、タイマ T3255 をス

タートさせること。

LOCATION UPDATING ACCEPT メッセージを受信した MS は、受信した LAI を保持し、タイマ T3210 を停止して、

試行カウンタをリセットし、SIM カード内の更新ステータスを UPDATED に設定すること。LOCATION UPDATING ACCEPT メッセージ内に IMSI が含まれている場合には、MS には TMSI が割当てられていないので、SIM カード内

の全ての TMSI を削除すること。メッセージ内に TMSI が含まれている場合には、MS にはその TMSI が割当てられ

るので、MS はその TMSI を SIM カード内に保持し、TMSI REALLOCATION COMPLETE メッセージをネットワーク

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 80

に返すこと。LOCATION UPDATING ACCEPT 内で TMSI も IMSI も受信しなかった場合には、古い TMSI がもし有

効であればそれをキープすること。

LOCATION UPDATING ACCEPT メッセージ内に含まれる LAI または PLMN 識別子が、「禁止リスト」（"forbidden lists"）内に含まれている値であった場合には、そのようなエントリを全て削除すること。

その後、MS は LOCATION UPDATING ACCEPT メッセージ内の IE"Follow-on proceed"の有無に従って動作する

こと。つまり、IE"Follow-on proceed が存在し、かつ MS が CM アプリケーション要求ペンディングを持っている場合

には、MS はネットワークに CM SERVICE REQUEST を送信し、4.5.1.1 節で述べた処理を続行すること。IE"Follow-on proceed が存在しない場合には、タイマ T3240 をスタートさせて、ステート WAIT FOR NETWORK COMMANDに入る。

さらに、ネットワークは MS に対して、LA 内の GSM-CTS （GSM-Cordless Telephony System）のとその隣接ネイバー

リストの使用パーミッションを許可することもできる。MS はこのパーミッションを不揮発性メモリに保存すること。メッセ

ージ内に"CTS permission" IE が存在しない場合には、MS は GSM-CTS を使用することは許可されないので、保存

された全てのパーミッションを削除すること。

注: CTS と GPRS 処理の間の相互作用については未定義

4.4.4.7 Location updating not accepted by the network （ネットワークが位置登録更新を受理しなかった場合）

ネットワークが位置登録更新を受理できない場合には、ネットワークは LOCATION UPDATING REJECT メッセージ

を MS に送信する。LOCATION UPDATING REJECT メッセージを受信した MS は、タイマ T3210 を停止し、拒否理

由を保存し、タイマ T3240 をスタートさせて、ステート LOCATION UPDATING REJECTED に入り、RR コネクション

の開放がネットワークによってトリガされるのを待つ。RR コネクションが開放されたならば、MS は保存された拒否理

由に応じて、以下のアクションをとること。

# 2: IMSI unknown in HLR（HLR 内で未知の IMSI）;

# 3: Illegal MS（不正 MS）;

# 6: Illegal ME（不正 ME）.

（上記理由の場合）MS は更新ステータスを ROAMING NOT ALLOWED に設定し（そしてそれを 4.1.2.2節に従って SIM カードに保存し）、全ての TMSI を削除し、LAI と暗号鍵シーケンス番号を保持すること。

電源が切断されるまで、あるいは SIM カードが抜かれるまで、その SIM カードは無効であると見なすこと。

# 11: PLMN not allowed（許容されない PLMN）;

# 12: Location Area not allowed（許容されない LA）;

# 13: Roaming not allowed in this location area（該当 LA 内でのローミング不可）

（上記理由の場合）MS は SIM カード内に保持されている全ての LAI、TMSI、そして暗号鍵シーケンス番

号を削除し、試行カウンタをリセットし、更新ステータスを ROAMING NOT ALLOWED に設定すること（そ

してそれを 4.1.2.2 節に従って SIM カードに保存すること）。MS は、適切な禁止リスト内（理由値#11 の場

合には"forbidden PLMN list" 内、理由値#12 の場合には"forbidden location areas for regional provision of service" のリスト内に、理由値#13 の場合には"forbidden location areas for roaming" のリスト内に、LAI または PLMN 識別子を保存すること。さらに、理由値#13 を受信した場合には、MS はそれを記憶して、MM IDLE ステートに戻った場合にはセル選択処理の代わりに PLMN 選択処理を実行すること。

それ以外の値は異常なケースと見なされ、それらのケースにおける MS の動作の仕様は 4.4.4.9 節で与えられる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 81

4.4.4.8 Release of RR connection after location updating （位置登録更新後の RRコネクション開放）

位置登録更新処理が完了したとき（4.4.4.6 節および 4.4.4.7 節参照）、MS は（MS が follow-on CM application request pending を持っていて、かつ follow-on proceed 通知を既に受信した場合を除いて）、タイマ T3240 を設定して、

ステート WAIT FOR NETWORK COMMAND に入り、RR コネクションが開放されるのを待つこと。ネットワークは、

ネットワークが MM コネクションを確立するために RR コネクションをキープすることもできるし、MS に MM コネクショ

ン確立を開始させることもできる。

RR コネクションの開放は全て、GSM 04.18 の 3.5 節および TS 25.331 の 8.2.1 節に従って、ネットワークが開始する

こと。タイマ T3240 によって制御される所定時間内に RR コネクションが開放されなかった場合には、MS は RR コネ

クションを中断すること。ネットワーク側から RR コネクションの開放がトリガされた場合、MS 側から RR コネクション

の中断が要求された場合、いずれの場合でも MS はステート MM IDLE に戻ること。

ステート MM IDLE、サブステート NORMAL SERVICE または RECEIVING GROUP CALL (NORMAL SERVICE) または ATTEMPTING TO UPDATE へのステート移行時、タイマ T3212 または T3211 のいずれかが 4.4.4.9 節の記

述に従って起動される。

4.4.4.9 Abnormal cases on the mobile station side（異常なケース、MS側）

異常なケースは以下のように分類できる。すなわち、

a) アクセスクラス制御によってアクセスが禁止された場合

位置登録更新処理は開始されない。MS は現行のサービスセル内にとどまり、通常のセル再選択処理が適

用される。（禁止ステートが終了するか、あるいはセルが変更されて）処理が可能になったら、まだ必要な場合

には直ちに処理が開始される。

b) ランダムアクセスへの応答が IMMEDIATE ASSIGNMENT REJECT メッセージであった場合）

位置登録更新処理は開始されない。MS は選択されたセル内にとどまり、通常のセル再選択処理が適用され

る。セルの変更が起きた場合には、タイマ T3122 がリセットされる。T3122 がタイムアウトした後、必要が生じ

たら直ちに処理が開始される。

c) Random access failure（ランダムアクセス失敗）

タイマ T3213 が開始される。タイマ満了時、まだ処理が必要ならば再試行される。

注: GSM 05.08 で規定されるように、少なくとも 1 つの適切なセルが他にあった場合には、セル再選択が実

行されるが、5 秒間はセルに戻ることが禁止される。通常は、選択処理によって MS は 5 秒後にランダ

ムアクセスが失敗したセルに戻る。

タイマ T3213 満了時に、有効な情報（GSM 05.08 参照）が足りないために新しいセルが未だ選択されていな

い場合には、MS はオプションとして、反復試行を 8 秒間遅延させて、セルの再選択を実行することが許され

る。この場合、新しいセルが選択された、または他のセルを選択することが不可能と MS が判断したら直ちに、

処理が試行される。

位置登録更新のためのランダムアクセス試行が 2 回連続して失敗した場合、MS は以下の処理を行う。

d) RR connection failure（RR コネクションのエラー）

処理は中断され、MS は以下に定義される処理を行う。

e) T3210 timeout（T3210 タイムアウト）

処理は中断され、RR コネクションは中断され、MS は以下に定義される処理を行う。

f) 処理正常終了前に RR が開放された場合

処理は中断され、MS は以下に定義される処理を行う。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 82

g) 4.4.4.7 節で扱った以外の理由で位置登録更新が拒否された場合

4.4.4.8 節に規定される通り、MS は RR コネクションの開放を待ち、その後以下に定義される処理を行う。

上記の d) ～ g)、そして上記の c)で定義されるエラーが反復した場合には、MS は以下に定義される処理を行う。タ

イマ T3210 が起動されている場合にはそれを停止する。タイマ T3210 がタイムアウトした場合には RR コネクション

を中断する。試行カウンタ値は漸増される。次のアクションは（現行のサービスセルの BCCH 上で受信して保存され

た）LAI と、試行カウンタの値によって決まる。

– 更新ステータスが UPDATED で、かつ保存された LAI が現行のサービスセルの BCCH 上で受信した値と等

しく、試行カウンタが 4 よりも小さいとき：

MS は更新ステータスを UPDATED にキープして、RR コネクション解放後の MM IDLE サブステートは

NORMAL SERVICE とする。MS は位置登録更新処理内で使用した位置登録タイプを記憶すること。RR コネ

クションが開放されたならば MS はタイマ T3211 をスタートさせること。タイマ T3211 が満了したならば、記憶

しておいた位置登録タイプを使用して位置登録更新処理を再度トリガする。

– 更新ステータスが UPDATED 以外であった場合、または保存された LAI が現行のサービスセルの BCCH 上

で受信した値と異なった場合、または試行カウンタが 4 以上のとき：

RR コネクションが開放されたならば、MS は SIM カード上に保存されている LAI,TMSI、暗号鍵シーケンス番

号を全て削除し、更新ステータスを NOT UPDATED に設定し、ステート MM IDLE、サブステート

ATTEMPTING TO UPDATE に入る（サブステートのアクションについては 4.2.2.2 節参照）。アクセス試行カ

ウンタの値が 4 よりも小さい場合には、MS は RR コネクション開放時にタイマ T3211 で開始すべきことを記憶

すること。それ以外の場合には RR コネクション開放時にタイマ T3212 で開始すべきことを記憶すること。

4.4.4.10 Abnormal cases on the network side（異常なケース、ネットワーク側）

a) RR connection failure（RR コネクションのエラー）

位置登録更新処理と統合された共通処理の間に、RR コネクションでエラーが発生した場合には、ネットワー

クの動作は、共通処理の説明に従うこと。

共通処理が存在しないときに RR コネクションのエラーが発生した場合、MS に対する位置登録更新処理は中

断すること。

b) protocol error（プロトコルエラー）

プロトコルエラーを伴う LOCATION UPDATING REQUEST メッセージを受信した場合、ネットワークは可能

であれば、以下の拒否理由のうちの 1 つといっしょに LOCATION UPDATING REJECT メッセージを返すこと。

#96: Mandatory information element error（必須 IE エラー）

#99: Information element non-existent or not implemented（存在しない IE、または実装されていない IE）

#100: Conditional IE error（条件付 IE のエラー）

#111: Protocol error, unspecified（プロトコルエラー、未特定）

これらの応答を受信した後、ネットワークはチャネル開放処理を開始すること（3.5 節参照）。

図図図図 4.5/TS 24.008: 位置登録更新シーケンス（位置登録更新シーケンス（位置登録更新シーケンス（位置登録更新シーケンス（Location updating sequence））））

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 83

4.4.5 Void

4.4.6 Void

4.5 Connection management sublayer service provision （CMサブレイヤのサービス提供）

本節では MM コネクションの概念を導入する。概念は主に記述ツールに関するものである。ネットワークによる MMコネクションの確立は、ローカルなもの（つまり MM レイヤのメッセージ送信なしで、初の CM レイヤメッセージの

送信だけで実現）であってもよいし、また CM SERVICE PROMPT メッセージの送信によって実現してもよい（例えば

特定のリングバックサービスステートなど）。ネットワークまたは MS による MM コネクションの開放は常にローカル

である。つまりこれらの目的のために無線インタフェース上で MM メッセージを送信する必要はない（それとは逆に、

MS による MM コネクションの確立には無線インタフェース上で MM メッセージを送信する必要がある。唯一の例外

は VGCS であり、この場合は上りリンクアクセス処理の結果として MM コネクションが確立される（GSM 04.18 の

3.7.2.1.1 参照）。

MM（Mobility Management）管理サブレイヤは、上位の CM(Connection management)サブレイヤの異なるエンティテ

ィに、コネクション管理サービスを提供する（TS 24.007 参照）。MM 管理サブレイヤは CM エンティティに対して、その

ピアエンティティとの間で情報を交換するために MM コネクションを使用できるようにする。MM コネクションは、CMエンティティの要求に基づいて確立／開放される。異なる CM エンティティはそのピアエンティティと、異なる MM コネ

クションを使用して通信する。複数の MM コネクションを同時にアクティブにすることができる。

MM コネクションは RR コネクションを要求する。特定の MS に対する同時 MM コネクション全て、同一の RR コネク

ションを使用する。

以下の節では、MM コネクションの確立、再確立、維持、そして開放のための手順について、たいていは MS 側とネ

ットワーク側で分けて説明する。

4.5.1 MM connection establishment（MMコネクションの確立）

4.5.1.1 MM connection establishment initiated by the mobile station （MSが開始する MMコネクションの確立）

CM エンティティの MM コネクション確立要求を受けて、MM サブレイヤはまず初に、その要求を受理するか、延

期させるか、または拒否するかを決定する。

- 以下の条件が満たされている場合には、MM コネクション確立は MS 側からのみ開始できる

- 更新ステータスが UPDATED の場合

- MM サブレイヤのステートが、MM IDLE または MM connection active であり、MM connection active (Group call)ではない場合

この一般則の例外が緊急呼である（4.5.1.5 節参照）。これ以外の例外は、以下の節で定義する。

- CM サブレイヤからの要求受信時に MM 固有の処理が起動されていて、かつ LOCATION UPDATING REQUEST メッセージが既に送信されていた場合には、MM 固有の処理が完了し、かつネットワークが

"follow-on proceed"通知を送信しておらず、RR コネクションが開放されるまで、要求は拒否または延期される。

どちらになるかは実装次第。LOCATION UPDATING REQUEST メッセージが既に送信されていた場合には、

MS は”follow-on request"通知をメッセージ内に含めることができる。そして MS は、ネットワークから RR コネ

クション使用の機会を与えられるまで、MM 固有の処理が完了するまで要求を遅延させること。4.4.4.6 節参照。

MM コネクションを確立するために、MS は以下の処理を行う。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 84

a) RR コネクションが存在しない場合、MM サブレイヤは RR サブレイヤに対して RR コネクション確立を要求し、

MM サブレイヤステート WAIT FOR RR CONNECTION (MM CONNECTION)に入る。この要求には、確立

理由と CM SERVICE REQUEST メッセージが含まれる。RR コネクションの確立が RR サブレイヤによって通

知された場合には（この通知は無線インタフェース上で CM SERVICE REQUEST が正常に送信されたことを

意味する。2.2 節参照）、MS の MM サブレイヤは、タイマ T3230 をスタートさせ、CM エンティティに対して

MM コネクション確立が要求されたことを通知し、そして MM サブレイヤステート WAIT FOR OUTGOING MM CONNECTION に入る。

b) RR コネクションが利用可能な場合には、MS の MM サブレイヤはネットワークに CM SERVICE REQUEST メッセージを送信し、タイマ T3230 スタートさせ、CM エンティティに対して MM コネクション確立が要求されたこ

とを通知し、そして、

- MM コネクションがアクティブでないならば、MM サブレイヤステート WAIT FOR OUTGOING MM CONNECTION に入る

- 少なくとも 1 つの MM コネクションがアクティブならば、MM サブレイヤステート WAIT FOR ADDITIONAL OUTGOING MM CONNECTION に入る

- RR コネクションが存在するが、MS がステート WAIT FOR NETWORK COMMAND にあるときには、MSが本ステートから離れるまで CM サブレイヤから受信した要求をすべて拒否／延期する。

c) 以下は VGCS トーキングをサポートしている MS にのみ適用

MM サブレイヤステート MM IDLE、サービスステート RECEIVING GROUP CALL (NORMAL SERVICE)にある MS が、GCC サブレイヤから上りリンクアクセスを実行するよう要求された場合、MM サブレイヤは RRサブレイヤに対して上りリンクアクセス処理の実行を要求し、MM サブレイヤステート WAIT FOR RR CONNECTION (GROUP TRANSMIT MODE)に入る。

上りリンクアクセス正常完了が RR サブレイヤによって通知されたならば、MS の MM サブレイヤは GCC サ

ブレイヤに対して通知を与えて、MM サブレイヤステート MM CONNECTION ACTIVE (GROUP TRANSMIT MODE)に入る。

RR サブレイヤによって上りリンクアクセス拒否が通知されたならば、MS の MM サブレイヤは GCC サブレイ

ヤに通知を与えて、MM サブレイヤステート MM IDLE、サービスステート RECEIVING GROUP CALL (NORMAL SERVICE)に入る。

ネットワークでは、上りリンクアクセス処理が実行されたならば、ネットワーク内の RR サブレイヤは TALKER INDICATION メッセージ内で受信したモバイル加入者識別子といっしょに、MM サブレイヤに通知を提供す

る。ネットワークは MM サブレイヤステート MM CONNECTION ACTIVE (GROUP TRANSMIT MODE)に入

ること。

CM SERVICE REQUEST メッセージには以下の情報が含まれる。

- 10.5.1.4 節に従ったモバイル識別子

- MS クラスマーク 2

- 暗号鍵シーケンス番号

- CM サービスタイプ。トランザクションの要求タイプ（例えば、モバイル発の呼確立、緊急呼の確立、SMS、付加サービスアクティブ化、ロケーションサービスなど）を識別

eMLPP をサポートする MS は、オプションとして CM SERVICE REQUEST メッセージ内に優先レベルを含めることも

できる。

MM サブレイヤステート WAIT FOR OUTGOING MM CONNECTION または WAIT FOR ADDITIONAL OUTGOING MM CONNECTION にある MS が CM レイヤのメッセージを受信した場合、衝突（collision）が発生す

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 85

る可能性がある。この場合、MS 内の MM サブステートは、4.5.1.3 節に規定された通り、受信 CM メッセージ用の

MM コネクションを新たに確立すること。

CM SERVICE REQUEST メッセージを受信したネットワークは、その内容を解析すること。語義解析のタイプは、他

の進行中の MM コネクションに依存する。要求のタイプと RR コネクションの現在のステータスに応じて、ネットワー

クは任意の MM 共通処理と RR 処理を開始することができる。

GSM の場合、MS の暗号化ケーパビリティに関する詳細な情報を得るために、ネットワークはクラスマーク調査処理

を開始することができる。

MS から提供された TMSI が認識できない場合には、例えば識別処理 (4.3.3 節参照)を起動することができる。

ネットワークは CM サービスタイプに応じて、認証処理 (4.3.2 節参照) を起動することができる。

GSM では、ネットワークは暗号化モード設定処理を起動するかどうか決定することもできる（GSM 04.18 の 3.4.7 節

参照）。

UMTS では、ネットワークはセキュリティモード制御処理を起動するかどうか決定することもできる（TS 25.331 の

8.1.10 節参照）。

注: CM_SERVICE_REQUEST メッセージ内に優先レベルが含まれていた場合には、TS 23.067 に規定さ

れているように、ネットワークはこれを使用してキューイングとプリエンプション（pre-emption）を実行す

ることができる。

GSM では、RR サブレイヤから暗号化モード設定処理が完了したという通知を受信するか、あるいは CM SERVICE ACCEPT メッセージを受信したならば、それらを MS によるサービス受付通知として扱うこと。

UMTS では、RR サブレイヤからセキュリティモード制御処理が完了したという通知を受信するか、あるいは CM SERVICE ACCEPT メッセージを受信したならば、それらを MS によるサービス受付通知として扱うこと。4.1.1.1.1 節

の手順は常に、本節よりも優先させること。

UMTS では、他の MM コネクションが存在しないときに（4.1.1.1.1a 節参照）、緊急呼を除く全てのサービス用の MMコネクションを確立する間に、ネットワークは完全性保護の起動と同時にセキュリティモード制御手順を起動する必要

がある。ただし、完全性保護が既に開始されている場合を除く（4.1.1.1.1 節参照）。

MM コネクション確立が完了したならば、タイマ T3230 を停止させ、MM コネクションを要求した CM エンティティに対

して通知し、MM サブレイヤステート MM CONNECTION ACTIVE に入ること。MM コネクションはアクティブと見な

される。

サービスリクエストが受理されなかった場合には、ネットワークは CM SERVICE REJECT メッセージを MS に返すこ

と。

拒否理由は、拒否理由 IE(10.5.3.6 および Annex G 参照)で通知される。以下の理由値が適用される。

#4 : IMSI unknown in VLR（VLR 内で未知の IMSI）

#6 : Illegal ME（不正 ME）

#17 : Network failure（ネットワークエラー）

#22 : Congestion（輻輳）

#32 : Service option not supported（サポート外のサービスオプション）

#33 : Requested service option not subscribed（要求されたサービスオプションに未加入）

#34 : Service option temporarily out of order（サービスオプションが一時的に利用不可）

他の MM コネクションがアクティブでない場合には、ネットワークは CM SERVICE REJECT メッセージが送信された

ときに RR コネクションの開放（3.5 節参照）を開始することができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 86

MS が CM SERVICE REJECT メッセージを受信したならば、タイマ T3230 を停止させ、要求を出した CM サブレイヤ

エンティティに通知すること。そして MS は以下の処理を行うこと。

- 理由値が#4 または #6 以外であった場合、MM サブレイヤは前のステート（要求を受信したステート）に戻る。

CM SERVICE REJECT メッセージは他の MM コネクションに影響を及ぼすことがあってはならない。

- 理由値#4 を受信した場合、MS は MM コネクションを全て中断し、SIM カード内の TMSI、LAI、暗号鍵シーケ

ンス番号を全て削除し、更新ステータスを NOT UPDATED に変更し（そしてそれを 4.1.2.2 節の記載に従って

SIM カード上に保存し）、MM サブレイヤステート WAIT FOR NETWORK COMMAND に入ること。連続して

RR コネクションが開放／中断された場合には、MS は通常の位置登録更新処理を開始することを強制される。

位置登録更新処理の間に CM の要求を記憶するか否かは実装次第。

- 理由値#6 を受信した場合、MS は MM コネクションを全て中断し、SIM カード内の TMSI、LAI、暗号鍵シーケ

ンス番号を全て削除し、更新ステータスを ROAMING NOT ALLOWED に変更し（そしてそれを 4.1.2.2 節の

記載に従って SIM カード上に保存し）、MM サブレイヤステート WAIT FOR NETWORK COMMAND に入る

こと。電源が切断されるまで、あるいは SIM カードが抜かれるまで、MS は SIM カードが無効であると見なす

こと。


MS 側:

a) RR connection failure or IMSI deactivation（RR コネクションのエラーまたは IMSI のデアィティブ化）

MM コネクション確立中に RR コネクションでエラーが発生した場合、または IMSI がデアクティブになった場

合には、タイマ T3230 は停止し、MM コネクション確立を要求した CM エンティティに対して通知が送られる。

この場合、新しい MM コネクションの確立が拒否されたものとして扱い、MM サブレイヤはアクティブな MMコネクションを全て開放すること。

b) T3230 expiry（T3230 満了）

T3230 が満了した場合（つまり応答がないが RR コネクションが利用可能な場合）には、MM コネクションの確

立は中断され、要求した CM サブレイヤに通知される。他の MM コネクションが存在しない場合には、MS は

RR コネクションを開放するために 4.5.3.1 節に記載した処理を適用すること。他の MM コネクションが存在す

る場合には、MS は MM コネクションの要求を受信した時の MM サブレイヤステート、つまり MM サブレイヤ

ステート MM connection active に戻ること。（もしあれば）他の進行中の MM コネクションがそれによって影響

を受けてはならない。

c) Reject cause values #95, #96, #97, #99, #100, #111 received （拒否理由値#95, #96, #97, #99, #100, #111 を受信）

MS はタイマが満了した時と同じアクションを取ること。

d) Random access failure or RR connection establishment failure （ランダムアクセスの失敗または RR コネクション確立の失敗）

MM コネクション確立中に MS がランダムアクセスの失敗または RR コネクション確立の失敗を検出した場合

には、MS は MM コネクション確立を中断し、MM コネクション確立を要求した CM エンティティに対して通知

すること。

注: MS のこれ以上のアクションは、異常な状況が発生したときの RR 処理および MM 固有の処理に依存

するので、それぞれの処理と合わせて説明される。

Network side（ネットワーク側）:


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 87

MM 共通処理中に RR コネクションのエラーが発生した場合に取るべきアクションについては、その処理と合

わせて説明される。そのような MM 共通処理の範囲外で RR コネクションのエラーが発生した場合には、もし

あれば全てのアクティブな MM コネクションの開放をトリガすること。

b) Invalid message or message content（無効なメッセージまたはメッセージ内容）

無効な初期化メッセージまたは無効な内容を持つ CM SERVICE REQUEST メッセージを受信した場合には、

以下の拒否理由通知のうちどれか 1 つといっしょに CM SERVICE REJECT メッセージを送信すること。

# 95: Semantically incorrect message（意味が間違っているメッセージ）

# 96: Mandatory information element error（必須 IE のエラー）

# 97: Message type non-existent or not implemented（存在しない、あるいは実装されていないメッセージタイ

プ）

# 99: Information element non-existent or not implemented（存在しない、あるいは実装されていない IE）

# 100: Conditional IE error（条件付 IE エラー）

# 111: Protocol error, unspecified（プロトコルエラー、特定不能）

CM SERVICE REJECT メッセージを送信したときは、もし他の MM コネクションが存在する場合、あるいは異

常な条件が他の MM コネクションに対しても影響を及ぼす場合には、ネットワークは RR コネクション開放処

理を開始することができる。

4.5.1.3 MM connection establishment initiated by the network （ネットワークによる MMコネクション確立の開始）

4.5.1.3.1 Mobile Terminating CM Activity （モバイル着信 CM Activity）

ネットワーク内の CM サブレイヤが MM サブレイヤに対して MM コネクションの確立を要求したとき、希望する MSに対する RR コネクションが存在しない場合には、MM サブレイヤは RR コネクションの確立を RR サブレイヤに要求

する。ページング処理が完了したならば MM サブレイヤに通知され（GSM 04.18 の 3.3.2 節および TS 25.331 の 8.2.1 節参照）、MS は MM ステート WAIT FOR NETWORK COMMAND に入ること。

(* editor's note: this does not appear to be stated any where other than in fig 4.1a. Without this statement, there does not seem to be anything to stop the mobile sending a CM SERVICE REQUEST message which might cross (ambiguously) with a SECURITY MODE COMMAND or a SECURITY MODE CONTROL message. *)

GSM では、RR コネクション確立時（または要求受信時に既に RR コネクションが存在している場合）、MM サブレイ

ヤは任意の MM 共通処理（IMSI デタッチを除く）を開始することができる。MM サブレイヤは、RR サブレイヤに対し

て RR クラスマーク調査処理および／またはセキュリティモード設定処理を要求することができる。

UMTS では、RR コネクション確立時（または要求受信時に既に RR コネクションが存在している場合）、MM サブレイ

ヤは任意の MM 共通処理（IMSI デタッチを除く）を開始することができる。MM サブレイヤは、RR サブレイヤに対し

てセキュリティモード制御処理を要求することができる。

ネットワークが必要とみなす全ての MM 処理と RR 処理が正常に完了したならば、MM サブレイヤは、要求元のモ

バイル着信 CM サブレイヤエンティティに対して、MM コネクションが正常に完了したことを通知する。

RR コネクションが既に存在しており、かつ MM 固有の処理が起動されていない場合には、ネットワークは新しい

PD/TI コンビネーションといっしょに CM メッセージを送信して、モバイル着信 MM コネクションを新たに確立すること

ができる。

GSM では、RR コネクションの確立が失敗した場合、または MM 共通処理またはセキュリティモード設定処理のどち

らかが失敗した場合、適切な理由値といっしょに CM レイヤに通知される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 88

UMTS では、RR コネクションの確立が失敗した場合、または MM 共通処理またはセキュリティモード制御処理のど

ちらかが失敗した場合、適切な理由値といっしょに CM レイヤに通知される。

MM 固有の処理用に使用される RR コネクションが MS に対して存在する場合には、CM 要求を拒否または延期さ

せることができる。どちらにするかは実装次第。MM 固有の処理完了時、ネットワークは同じ RR コネクションを延期

された CM 要求のために使用することができる。

以下は VGCS トーキングの場合のみ適用。

MM CONNECTION ACTIVE (GROUP TRANSMIT MODE)ステートにある MS は、RR Group transmit モードにある。

1 つの MM コネクションだけがアクティブであること。

MM CONNECTION ACTIVE (GROUP TRANSMIT MODE) ステートにある場合、ネットワーク内の MM サブレイヤ

は他の全ての CM レイヤからの MM コネクション確立要求を拒否すること。

ネットワーク内の RR サブレイヤが、MS のモードを RR connected モードから RR Group transmit モードへの移行要

求を通知している場合（この結果 MM サブレイヤ内においては MM CONNECTION ACTIVE ステートから MM CONNECTION ACTIVE (GROUP TRANSMIT MODE)ステートへの移行が起こる）、もし MS 内で複数の MM コネ

クションがアクティブだったならば、MM サブレイヤはモードの移行を許可してはならない。

4.5.1.3.2 Mobile Originating CM Activity $(CCBS)$ （モバイル発 CM Activity $(CCBS)$）

ネットワーク内の CM サブレイヤが MM サブレイヤに対して MM コネクション確立を要求したとき、希望する MS に

対する RR コネクションが存在していない場合、MM サブレイヤは RR サブレイヤに RR コネクション確立を要求する。

ページング処理が完了したときは MM サブレイヤに通知され（GSM 04.18 の 3.3.2 節および TS 25.331 の 8.2.1 節参

照）、MS は MM ステート WAIT FOR NETWORK COMMAND に入ること。

GSM の場合、RR コネクション確立時（または要求受信時に既に RR コネクションが存在している場合）、MM サブレ

イヤは任意の MM 共通処理（IMSI デタッチを除く）を開始することができる。MM サブレイヤは、RR サブレイヤに対

して RR クラスマーク調査処理および／またはセキュリティモード設定処理を要求することができる。

UMTS の場合、RR コネクション確立時（または要求受信時に既に RR コネクションが存在している場合）、MM サブ

レイヤは任意の MM 共通処理（IMSI デタッチを除く）を開始することができる。MM サブレイヤは、RR サブレイヤに

対してセキュリティモード制御処理を要求することができる。

ネットワークは、"Network Initiated MO CM Connection Request" をサポートする MS 上の Mobile Station Classmark Type 2 IE に含まれる情報を使用して、以下の動作のいずれかを選択する。

本処理を開始しない（例えば RR コネクションが既に存在する場合など）

本処理を継続する

新しく確立された RR コネクションを開放する

"Network Initiated MO CM Connection Request"の場合、ネットワークは確立された RR コネクションを使用して MAに CM SERVICE PROMPT メッセージを送信すること。

MS が"Network Initiated MO CM Connection Request"をサポートする場合には、MS の MM サブレイヤは CM SERVICE PROMPT メッセージによって識別される CM エンティティに通知を与え、MM サブレイヤステート PROCESS CM SERVICE PROMPT に入る。ステート PROCESS CM SERVICE PROMPT においては、MM サブレイ

ヤは識別された CM エンティティによってリコールが拒否（rejection）または承認（confirmation）されるのを待つ。CMエンティティからのその他の要求は、MS が本ステートを離れるまで拒否または延期される。

識別された CM エンティティが MM サブレイヤに対して、CM リコール処理を開始するために CM エンティティが

初の CM メッセージを送信したことを通知したとき、MM サブレイヤのサブステートはステート MM CONNECTION ACTIVE に入る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 89

識別された CM エンティティが CM リコール処理を実行しないことを通知した場合には、MM サブレイヤはタイマ

T3240 をスタートさせてステート WAIT FOR NETWORK COMMAND に入り、RR コネクションの開放を待つ。

MM サブレイヤのステートが WAIT FOR OUTGOING MM CONNECTION または WAIT FOR ADDITIONAL OUTGOING MM CONNECTION にある MS が CM SERVICE PROMPT メッセージを受信した場合、MS は理由値

"Message not compatible with protocol state"を付けて MM STATUS メッセージを送信すること。

"Network Initiated MO CM Connection Request"をサポートしない MS は、理由値#97 "message type non-existent or not implemented"を付けて MM STATUS メッセージをネットワークに送信すること。

MS が"Network Initiated MO CM Connection Request"をサポートするが、MS 内で識別された CM エンティティが関

連するサポートを提供しない場合には、MS は理由値 "Service option not supported"を付けて MM STATUS メッセ

ージを送信すること。一時的な CM の問題の場合（TI（transaction identifier）の欠落など）には、MS は理由値

"Service option temporarily out of order"を付けて MM STATUS メッセージを送信すること。

RR コネクションが既に存在し、かつ MM 固有の処理が起動されていない場合には、ネットワークはそれを使用して

CM SERVICE PROMPT メッセージを送信することができる。

GSM では、RR コネクションの確立が失敗した場合、または MM 共通処理またはセキュリティモード設定のいずれか

が失敗した場合には、ネットワーク内の CM レイヤに対して適切なエラー理由といっしょに失敗が通知される。

UMTS では、RR コネクション確立がが失敗した場合、または MM 共通処理またはセキュリティモード制御のいずれ

か失敗した場合には、ネットワーク内の CM レイヤに対して適切なエラー理由といっしょに失敗が通知される。

MS に対して MM 固有の処理のための RR コネクションが存在する場合には、"Network Initiated MO CM Connection Request"は拒否することも延期することもできる。どちらになるかは実装次第。MM 固有の処理が完了し

たならば、ネットワークは同一の RR コネクションを延期された"Network Initiated MO CM Connection Request"のた

めに使用することができる。

4.5.1.3.3 Paging response in UMTS (UMTS only) （UMTS内のページング応答（UMTSのみ））

MS に CS サービス用の IMSI がアタッチされたならば、ネットワークは CS サービス用のページング処理を開始する

ことができる。処理を開始するために、MM エンティティは RR サブレイヤに対して、CS サービス用のページング（TS 25.331 および TS 25.413 参照）の開始を要求する。

ページングメッセージ受信時、そのページングがネットワーク内の MM エンティティによって開始されたものであった

場合には、MS 内の RR サブレイヤはページング通知を MM サブレイヤに配送すること（TS 25.331 参照）。MS は

GSM 04.18 の 9.1.25 節に規定される PAGING RESPONSE メッセージで応答すること。バックワード互換性上の理由

から、ページング応答は RRPD（RR protocol discriminator）を使用すること。


異常なイベントが発生した場合の動作については、関連する RR 処理または MM 共通処理といっしょに説明される。

4.5.1.5 MM connection establishment for emergency calls （緊急呼用の MMコネクション確立）

通常呼用の MM コネクションの確立は MM サブレイヤによって許可されるが、緊急呼用の MM コネクションは MMサブレイヤのステートには無関係に確立することができる。さらに、（MM コネクションの）確立は、セルが選択された

サービスステートでは試行することができる（4.2.2 節参照）が、MM CONNECTION ACTIVE (GROUP TRANSMIT MODE) ステートでは試行することができない。しかし、ネットワークの固有オプションとして、特定のステート内にお

ける緊急呼用の MM コネクションを拒否することもできる。

注: GSM では、MS が音声サービスを提供できないネットワーク(CELL_BAR_QUALIFY_2 parameter indicates no voice service)内にキャンプして、緊急呼サービスを要求した場合には、GSM 03.22 に規定

された通り、MS は緊急呼を確立する前に直ちに"Any Cell Selection"ステートに移行すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 90

ユーザが緊急呼の確立を要求した場合、MS は緊急呼確立を通知する CM service type IE といっしょに CM SERVICE REQUEST メッセージをネットワークに送信する。ネットワークがこの緊急呼要求を受け付けることができ

ない場合、例えば IMEI が通知用に使用されていてこのネットワークが本ケーパビリティをサポートしない場合など、

ネットワークは MS に CM SERVICE REJECT メッセージを返して要求を拒否する。

拒否理由は拒否理由 IE 内で示される。以下の理由値が適用される。

#3 "Illegal MS"（不正 MS）

#4 "IMSI unknown in VLR"（VLR で未知の IMSI）

#5 "IMEI not accepted"（受け付けられない IMEI）

#6 "Illegal ME"（不正 ME）

#17 "Network failure"（ネットワークエラー）

#22 "Congestion"（輻輳）

#32 "Service option not supported"（サポート外のサービスオプション）

#34 "Service option temporarily out of order"（サービスオプションが一時的に利用不可）

上に定義した例外について、4.5.1.1 節および 4.5.1.2 節の MM コネクション確立のために説明した手順が続くこと。

注: 通常は、MS は IMSI または TMSI によって識別される、しかし、MS 内でいずれの識別子も利用不可

能な場合には、MS は識別のために IMEI を使用すること。この場合、ネットワークは次の理由値といっ

しょに CM SERVICE REJECT メッセージを返して要求を拒否することができる。

#5 "IMEI not accepted".（IMEI は受け付けられない）

4.5.1.6 Call re-establishment（呼の再確立）

呼の再確立処理によって、無線リンクでエラー発生後に、新たなセルそして新たな LA 内で MS が進行中のコネクシ

ョンを再開することが可能になる。呼の再確立が試行される条件、または呼制御ステートに依存しない条件、また呼

の再確立を許容するセルが見出される条件（GSM 05.08 参照）については、5.5.4 節参照。MM コネクションは、その

PD と TI によって識別される。であるから、呼再確立中にこれらの値を変更してはならない。

下位レイヤでエラーが発生し、かつ少なくとも 1 つの MM コネクションがアクティブである場合（つまり、MM の MMサブレイヤがステート 6"MM CONNECTION ACTIVE" またはステート 20 "WAIT FOR ADDITIONAL OUTGOING MM CONNECTION"のいずれかである場合）に、再確立が実行される。

注: 再確立試行中に、MS が MM IDLE ステートに戻ることはない。であるから、たとえ選択されたセルの

LA 内で MS が更新されなくとも、位置登録更新は実行されない。

音声グループ呼およびブロードキャスト呼に関しては、呼の再確立を実行してはならない。

4.5.1.6.1 Call re-establishment, initiation by the mobile station （呼再確立、MSが開始）

注: ネットワークは呼再確立を開始することはできない。

MM コネクションが中断されたという通知（4.5.2.3 節参照）に対する応答として、CM エンティティから MM コネクショ

ンの再確立要求を少なくとも 1 つ受信したならば、MS は呼再確立処理を開始すること。複数の CM エンティティが呼

再確立処理を要求しても、開始される呼再確立処理は 1 つだけである。任意の CM エンティティが呼再確立を要求

した場合には、呼再確立にパーミッションを与える全ての PD（Protocol Discriminator）に属する全てのトランザクショ

ンの再確立を試行すること。

CM エンティティから MM コネクションの再確立要求を受信した MM サブレイヤは、RR サブレイヤに対して RR コネ

クションの確立を要求し、MM サブステート WAIT FOR REESTABLISH に入る。要求には、確立理由と CM RE-

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 91

ESTABLISHMENT REQUEST メッセージが含まれれている。RR コネクションの確立が RR サブレイヤによって通知

されると（この通知は無線インタフェース上で CM RE-ESTABLISHMENT REQUEST メッセージが正常に送信された

ことを意味する。2.2 節参照）、MS の MM サブレイヤはタイマ T3230 をスタートさせ、再確立すべき全ての CM エン

ティティに通知を送信し、MM サブレイヤ WAIT FOR REESTABLISH にとどまる。

CM RE-ESTABLISHMENT REQUEST には以下の情報が含まれる。

- 10.5.1.4 節によるモバイル識別子

- MS クラスマーク 2

- 暗号鍵シーケンス番号

注: CM エンティティが再確立を要求できるか否かは PD（Protocol Discriminator）に依存する。現時点では、

SMS （Short Message Service 、GSM 04.11）、呼非依存付加サービス（Call Independent Supplementary Services 、TS 24.010）、およびロケーションサービス（Location Services 、TS 24.071）の仕様は、再確立

処理の仕様については規定していない。

CM RE-ESTABLISHMENT REQUEST メッセージを受信したならば、ネットワークはその内容を解析すること。要求

のタイプに応じて、ネットワークは MM 共通処理および RR 処理のいずれかを開始することができる。

MS の暗号化ケーパビリティに関する詳細な情報を取得するために、ネットワークはクラスマーク調査処理を開始す


識別処理 (4.3.3 節参照)を起動できる。

ネットワークは認証処理 (4.3.2 節参照)を発動できる。

GSM では、ネットワークがセキュリティモード設定処理を起動するか否かを決定する（GSM 04.18 の 3.4.7 節参照）。

RR サブレイヤから、セキュリティモード設定処理の完了通知、または CM SERVICE ACCEPT メッセージを受信した

という通知を受信したならば、その通知を MS によるサービス受容通知として扱うこと。

UMTS では、ネットワークがセキュリティモード制御処理を発動するか否かを決定する（TS 25.331 の 8.1.10 節参照）。

RR サブレイヤから、セキュリティモード制御処理の完了通知、または CM SERVICE ACCEPT メッセージを受信した

という通知を受信したならば、その通知を MS によるサービス受容通知として扱うこと。

MM コネクション再確立が完了したならば、タイマ T3230 を停止させること。再確立に関係する全ての CM エンティテ

ィに対して通知し、MM サブレイヤステート MM CONNECTION ACTIVE に再び入ること。全ての MM コネクション

はアクティブにされたと見なされる。

ネットワークが再確立要求を該当 MS 用の既存の呼に関連付けることができない場合には、理由値といっしょに CM SERVICE REJECT メッセージが返される。

#38 "call cannot be identified"（呼が特定できない）

それ以外の理由で呼再確立が実行された場合には、以下のいずれかの適切な理由値といっしょに CM SERVICE REJECT メッセージが返される（annex G 参照）。

# 4 "IMSI unknown in VLR";（VLR 内で未知の IMSI）

# 6 "illegal ME";（不正 ME）

#17 "network failure";（ネットワークのエラー）

#22 "congestion";（輻輳）

#32 "service option not supported";（サービスオプションがサポート外）

#34 "service option temporarily out of order".（サービスオプションが一時的に利用不可）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 92

CM RE-ESTABLISHMENT REQUEST に対する応答として CM SERVICE REJECT を MS が受信したならば、その

理由値に関わらずタイマ T3230 を停止させ、全ての MM コネクションを開放し、4.5.3.1 節に記載された手順を進める

こと。さらに、

- 理由値#4 を受信した場合には、MS は SIM カード上の TMSI、 LAI、そして暗号鍵シーケンス番号を全て削

除し、更新ステータスを NOT UPDATED に変更し（そしてそれを 4.1.2.2 節の手順に従って SIM カード上に保

存し）、MM サブレイヤステート WAIT FOR NETWORK COMMAND に入る。その後、RR コネクションが開

放または中断された場合には、MS は強制的に通常の位置登録更新を開始させられる。位置登録更新処理

の間、CM の再確立要求を記憶してはならない。

- 理由値#6 を受信した場合には、MS は SIM カード上の TMSI、 LAI、そして暗号鍵シーケンス番号を全て削

除し、更新ステータスを ROAMING NOT ALLOWED に変更し（そしてそれを 4.1.2.2 節の手順に従って SIMカード上に保存し）、MM サブレイヤステート WAIT FOR NETWORK COMMAND に入る。電源が切断され

るか SIM カードが抜かれるまで、MS は SIM カードが無効であると見なすこと。

4.5.1.6.2 Abnormal cases（異常なケース）

MS 側

a) Random access failure or RR connection establishment failure（ランダムアクセスの失敗または RR コネクション

確立の失敗）

MM コネクション再確立中に、MS がランダムアクセスの失敗または RR コネクション確立の失敗を検出したな

らば、再確立処理は中断され、全ての MM コネクションは開放される。

b) RR connection failure（RR コネクションのエラー）

RR コネクションでエラーが発生した場合には、タイマ T3230 を停止し、再確立は中断され、アクティブな MMコネクションは全て開放される。

c) IMSI deactivation（IMSI のデアクティブ化）

MM コネクション再確立試行中に IMSI がデアクティブにされた場合には、タイマ T3230 を停止し、再確立は

中断され、MM コネクションは全て開放される。

d) T3230 expires（T3230 満了）

T3230 が満了した場合（つまり、応答がないが RR コネクションは有効な場合）、再確立は中断され、アクティ

ブな MM コネクションは全て開放され、MS は 4.5.3.1 節で述べた手順を進める。

e) Reject causes #96, #97, #99, #100, #111 received（拒否理由#96, #97, #99, #100, #111 を受信）

MS はタイマ T3230 満了時と同様のアクションを取ること。

ネットワーク側


CM RE-ESTABLISHMENT REQUEST 受信後に RR コネクションのエラーが発生した場合には、ネットワーク

は MM コネクションを全て開放すること。

b) Invalid message content（無効なメッセージ内容）

メッセージの無効な初期値、または無効な内容をもった CM RE-ESTABLISHMENT REQUEST メッセージを

受信した場合には、ネットワークは以下の理由値のうちいずれか適切なものといっしょに CM SERVICE REJECT メッセージを返すこと。

#96: Mandatory information element error（必須 IE のエラー）

#99: Information element non-existent or not implemented（存在しないまたは実装されていない IE）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 93


#111: Protocol error, unspecified（特定されないプロトコルエラー）

CM SERVICE REJECT メッセージが送信された後、ネットワークは RR コネクションを開放すること。

4.5.1.7 Forced release during MO MM connection establishment （MO MMコネクション確立中の強制開放）

MS の CM レイヤが MM コネクション確立を開始したが、確立フェーズ完了前に CM レイヤが確立を中断しようとし

た場合には、MS は RR コネクション完了後、初の CM メッセージ（SETUP など）送信前の任意の時刻に、CM SERVICE ABORT メッセージを送信すること。

初の CM メッセージが既に送信されている場合には、適切な CM プロトコルによって定義される通常の開放処理

を適用し、CM SERVICE ABORT を送信してはならない。

CM SERVICE ABORT メッセージの送信が許容されているのは、初の MM コネクションが確立される間、かつ他

の MM コネクションがパラレルで存在しない場合に限られる。他の MM コネクションがパラレルで存在する場合には、

新しいコネクション確立を中断することはできず、その場合は MM コネクション確立後に通常の MM コネクション開

放を 4.5.3 節に従って適用する。

CM SERVICE ABORT メッセージを送信した MS は、タイマ T3240 をセットし、ステート WAIT FOR NETWORK COMMAND に入り、RR コネクションが開放されるのを待つこと。

CM SERVICE ABORT メッセージを受信したネットワークは、進行中のプロセスを中断し、適切なリソースを開放し、

他の MM コネクション確立がペンディングでないかぎり、通常の RR コネクション開放処理を開始すること。

タイマ T3240 によって制御される所定時間内に RR コネクションが開放されなかった場合には、MS は RR コネクショ

ンを中断すること。ネットワーク側からトリガされて RR コネクションが開放された場合、MS 側の要求で RR コネクショ

ンが中断された場合、いずれの場合でもその後に MS はステート MM IDLE に戻ること。現行の更新ステータス上

のサービスステートペンディングについては、4.2.3 節で規定される。

4.5.2 MM connection information transfer phase （MMコネクション情報の送信フェーズ）

MM コネクションが確立された後は、CM サブレイヤのエンティティが情報を送信するために使用することができる。

TS 24.007 中に記載されるプロトコルアーキテクチャに従い、各 CM エンティティは自分自身の MM コネクションを持

つ。これらの異なる MM コネクションは、PD（protocol discriminator）と、追加的に TI（transaction identifier）によって

識別される。

MM コネクションがアクティブであるならば、全ての MM 共通処理をいつでも開始することができる。分離された L2のプライオリティの低いデータリンクを使用するショートメッセージ制御（Short Message Control）を除いて、CM, MM,RR サブレイヤメッセージの間でプライオリティメカニズムは定義されない。

4.5.2.1 Sending CM messages（CMメッセージの送信）

CM サブレイヤエンティティは、MM コネクションが既に確立されていることを確認した上で、CM メッセージの送信を

要求することができる。MM サブレイヤにパスされる CM メッセージは、次に PD といっしょにインタフェースの反対側

に送信され、TI が発信元エンティティに従って設定する。

4.5.2.2 Receiving CM messages（CMメッセージの受信）

CM メッセージを受信すると、MM サブレイヤは PD の値と TI の値に従ってそれを関連する CM エンティティに分配

する。しかし、受信した CM メッセージが MM コネクション（PD および TI によって識別される）にとって初のメッセ

ージであった場合には、MM サブレイヤは追加的に CM エンティティに対して新しい MM コネクションが確立された

ことを通知する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 94


RR connection failure（RR コネクションのエラー）:

RR／MM 共通処理の間に、RR コネクションでエラーが発生した場合には、その後のアクションは該当処理と

いっしょに説明される。

それ以外のケースでは、以下が適用される。

Mobile station（MS）:

MM サブレイヤはアクティブな MM コネクションに関連する全 CM エンティティに対して、MM コネクションが

中断されたことを通知する。その後 MM サブレイヤが取るべきアクション（呼再確立、4.5.1.6 節参照、または

ローカルな開放）は、CM エンティティの決定に委ねられる。

Network（ネットワーク）:

MM サブレイヤは、ローカルに全てのアクティブな MM コネクションを開放すること。オプションとして、ネットワ

ークは MM コネクションのうちの一部または全部の開放を延期させて、MS に呼再確立を開始させることもで

きる。

4.5.3 MM connection release（MMコネクションの開放）確立された MM コネクションは、ローカルな CM エンティティによって開放される。CM コネクションの開放は、次に

MM サブレイヤ内でローカルに行われる。つまり、そのために無線インタフェース上で MM メッセージが送信される

ことはない。

4.5.3.1 Release of associated RR connection（関連する RRコネクションの開放）

これらの CM エンティティによって全ての MM コネクションが開放された場合には、MS はタイマ T3240 をセットし、ス

テート WAIT FOR NETWORK COMMAND に入り、RR コネクションが開放されるのを待つ。

ネットワーク側では、後の MM コネクションがコネクションのユーザによって開放されたならば、MM サブレイヤは

RR コネクションを開放するか否か決定することができる。例えば他の MM コネクションを確立するために、ネットワ

ークは RR コネクションを維持することもできる。

RR コネクションがタイマ T3240 によって制御される所定時間内に開放されなかった場合には、MS は RR コネクショ

ンを中断すること。ネットワーク側からトリガされて RR コネクションが開放された場合、MS 側の要求で RR コネクショ

ンが中断された場合、いずれの場合でもその後に MS はステート MM IDLE に戻る。現行の更新ステータス上のサ

ービスステートペンディングについては、4.2.3 節で規定される。

4.5.3.2 Uplink release in a voice group call（音声グループ呼の上りリンクの開放）

（以下は VGCS トーキングをサポートする MS にのみ適用）

MM サブレイヤステート MM CONNECTION ACTIVE (GROUP TRANSMIT MODE)にある MS が GCC サブレイヤ

から上りリンク開放実行の要求を受信した場合、MM サブレイヤは RR サブレイヤに対して上りリンク開放処理の実

行を要求し、MM サブレイヤステート RECEIVING GROUP CALL (NORMAL SERVICE)に入る。

4.6 Receiving a MM STATUS message by a MM entity （MMエンティティによるMM STATUSメッセージの受信）

MS の MM エンティティが MM STATUS メッセージを受信した場合には、無線インタフェースの点からは、ステート遷

移や特別なアクションを実行する必要はない。つまりローカルなアクションでよい。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 95

CM SERVICE PROMPT メッセージに対する応答用の説明を除いて、受信した MM STATUS メッセージに対してネ

ットワーク内で取るべきアクションは実装に依存するオプションである。

4.7 Elementary mobility management procedures for GPRS Service （GPRSサービス用の基本的モビリティ管理処理）

4.7.1 General（概要）本節では、GMM（mobility management）サブレイヤが無線インタフェース上（リファレンスポイント Um/UU）で提供す

る基本的な機能について説明する。機能はタイマと処理という観点から説明される。GMM 処理の間、セッション管理

処理と SMS 処理（第 6 章参照）はサスペンドされる。

4.7.1.1 Lower layer failure（下位レイヤの失敗）

下位レイヤは GMM サブレイヤに対して、論理的リンクの失敗、または RR サブレイヤの失敗、または RRC サブレイ

ヤの失敗を通知すること。失敗とは、下位レイヤによって訂正できないエラーを指す。

4.7.1.2 Ciphering of messages (GSM only)（メッセージの暗号化（GSMのみ））

GMM コンテキストに対して暗号化が適用される場合には、以下のメッセージを除く全ての GMM メッセージを暗号

化すること。

-- ATTACH REQUEST;

-- ATTACH REJECT;

-- AUTHENTICATION AND CIPHERING REQUEST;

-- AUTHENTICATION AND CIPHERING RESPONSE;

-- AUTHENTICATION AND CIPHERING REJECT;

-- IDENTITY REQUEST;

-- IDENTITY RESPONSE;

-- ROUTING AREA UPDATE REQUEST; and

-- ROUTING AREA UPDATE REJECT.

4.7.1.3 P-TMSI signature（P-TMSI署名）

ネットワークはアタッチ／RA 更新／P-TMSI 再配置処理中 MS に対して、P-TMSI 署名を割当てることができる。有

効な P-TMSI 署名と組み合わせた場合のみ、MS はその後のアタッチ／RA 更新／P-TMSI 再配置処理の中でこの

P-TMSI 署名を認証と識別目的に使用することができる。MS が有効な P-TMSI を持たない場合には、その後のアタ

ッチ／RA 更新／P-TMSI 再配置処理中で P-TMSI 署名を使用してはならない。後続アタッチ／RA 更新処理が正常

終了後、使用した P-TMSI 署名は削除すること。デタッチ処理完了後、使用した P-TMSI 署名は削除すること。

4.7.1.4 Radio resource sublayer address handling （無線リソースサブレイヤのアドレス処理）

GSM では、GMM 内で MS の識別のために P-TMSI（packet TMSI）が使用されている間は、TLLI(temporary logical link identity)を使用して RR サブレイヤにおけるアドレス処理を行う。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 96

UMTS では、RNTI（Radio Network Temporary Identity）を使用して MS と UTRAN の間の UMTS ユーザを識別する。

RNTI と IMSI の関係は、MS と UTRAN だけが知っている。TS 25.301[10]参照。

4.7.1.4.1 Radio resource sublayer address handling (GSM only) （無線リソースサブレイヤのアドレス処理（GSMのみ））

本節では、GMM の RR アドレス管理方法について説明する。TLLI タイプ毎に異なる符号化の詳細や、P-TMSI から

TLLI を誘導する方法については、TS 23.003 [10]参照。

2 つのケースに分類することができる。

- MS 内で有効な P-TMSI が利用可能である場合

- MS 内で有効な P-TMSI が利用不可能な場合

i) valid P-TMSI available（有効な P-TMSI が利用可能）

MS が有効な P-TMSI を保持している場合には、MS はその P-TMSI から foreign TLLI を誘導し、それを使っ

て以下の情報を送信すること。

- 任意の GPRS 組合せ／非組合せアタッチ処理の ATTACH REQUEST メッセージ：本処理の間に送信さ

れた他の GMM メッセージは、ATTACH ACCEPT メッセージまたは ATTACH REJECT メッセージを受信

するまでに、同じ foreign TLLI を使用して送信すること。

- MS が新しい RA に入った場合、または GPRS の更新ステータスが GU1 UPDATED 以外であった場合の

組合せ／非組合せ RAU 処理の ATTACH REQUEST メッセージ。本処理の間に送信された他の GMMメッセージは、ROUTING AREA UPDATE ACCEPT メッセージまたは ROUTING AREA UPDATE REJECT メッセージを受信するまでに、同じ foreign TLLI を使用して送信すること。

GPRS アタッチまたは RA 更新処理が正常に終了した後は、新しい P-TMSI が割当てられているか否かに関

わらず、MS が有効な P-TMSI を保持しているならば、次に MS は保持している P-TMSI からローカルな TLLIを誘導し、それを使用して下位レイヤにおけるアドレス処理を行う。

ii) no valid P-TMSI available（有効な P-TMSI が利用不能）

MS が有効な P-TMSI を保持していない場合、つまり MS が GPRS にアタッチされていない場合には、MS は

ランダムに選択した TLLI を使って以下の情報を送信する。

- 任意の GPRS 組合せ／非複合 GPRS アタッチ処理の ATTACH REQUEST メッセージ

同じくランダムに選択した TLLI 値を、全てのメッセージ再送試行と、1 回のアタッチ試行内のセル更新用に使

用すること。

ATTACH REQUEST メッセージを受信したならば、ネットワークは MS に P-TMSI を割当てる。ネットワークは

割当てた P-TMSI からローカルな TLLI を誘導し、割当てられた P-TMSI を MS に送信する。

割当てられた P-TMSI を受信した MS は、この P-TMSI からローカルな TLLI を誘導し、下位レイヤのアドレシ

ングに使用すること。

いずれのケースでも、MS はアサインされた P-TMSI を受信したことをネットワークに送達確認すること。送達確認受

信後、ネットワークは下位レイヤのアドレシングにローカルな TLLI を使用すること。

4.7.1.5 P-TMSI handling（P-TMSI処理）

4.7.1.5.1 PTMSI handling in GSM（GSMにおける P-TMSI処理）

新たな P-TMSI をネットワークか割当てられたならば、MS とネットワークは新旧 P-TMSI を以下のように処理するこ

と。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 97

新しい P-TMSI を含む GMM メッセージを受信したならば、MS はページングリクエストと LLC フレームの下りリンク

送信に応答するために、新しい P-TMSI、新しい RAI、そしてまた旧 P-TMSI と旧 RAI を有効とみなすこと。LLC フレ

ームの上りリンク送信については、新しい P-TMSI を使用すること。

MS は、新しい P-TMSI から誘導されたローカルな TLLI とともに LLC フレームを受信したならば直ちに、旧 P-TMSI および旧 RAI を無効とみなすこと。

新しい P-TMSI を含む GMM メッセージを送信したならば、ネットワークは MS からの LLC フレーム受信を可能にす

るために、新しい P-TMSI、新しい RAI、そしてまた旧 P-TMSI と旧 RAI が有効とみなすこと。

ネットワークは、新しい P-TMSI から誘導されたローカルな TLLI とともに LLC フレームを受信したならば直ちに、旧

P-TMSI および旧 RAI を無効とみなすこと。

4.7.1.5.2 PTMSI handling in UMTS（UMTS内の PTMSI処理）

ネットワークによって新しい P-TMSI がアサインされたならば、MS とネットワークは新旧 P-TMSI を以下のように処理

すること。

新しい P-TMSI を含む GMM メッセージを受信したならば、MS は新しい P-TMSI および新しい RAI を有効と見なす

こと。旧 P-TMSI および P-TMSI の署名は無効と見なされる。

ネットワークは、送達確認メッセージ (例 ATTACH COMPLLETE, ROUTING AREA UPDATE COMPLETE, P-TMSI REALLOCATION COMPLETE など)を受信したならば直ちに、旧 P-TMSI および RAI を無効と見なすこと。

4.7.1.6 Change of network mode of operation （ネットワークオペレーションモードの変更）

下表では、GSM のネットワークオペレーションモード I, II ,III の略語として、'GSM I', 'GSM II' そして 'GSM III'を使用

する。

下表では、UMTS のネットワークオペレーションモード I, II の略語として、'UMTS I'と 'UMTS II'を使用する。

4.7.1.6.1 Change of network mode of operation in GSM (GSM only) （GMS内でのネットワークオペレーションモードの変更（GSMのみ））

MS が新しい RA に移動したときは常に、MS によって実行される処理は、新旧 RA 内のオペレーションのネットワー

クモードに依存する。

MS がステート GMM-REGISTERED または GMM-ROUTING-AREA-UPDATING-INITIATED にあり、かつ次のオ

ペレーションにある場合には、

a) A または B（次の b および c の場合を除く）、MS は以下の処理を行うこと。

表表表表 4.7.1.6.1/TS 24.008: モードモードモードモード A またはまたはまたはまたは B

ネットワークオペレーションネットワークオペレーションネットワークオペレーションネットワークオペレーション

モードの変更モードの変更モードの変更モードの変更実行すべき処理実行すべき処理実行すべき処理実行すべき処理

I → II or I → III 通常の位置登録更新(*)、その後通常 RA 更新 II → III or III → II 通常の位置登録更新(4.2.2 節参照)、その後通常 RA 更新 II → I or III → I IMSI アタッチと組み合わされた RA 更新

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 98

b) ネットワークオペレーションモード III で、B から C へ戻った場合、MS は以下の処理を行うこと。

表表表表 4.7.1.6.2/TS 24.008: ネットワークオペレーションモードネットワークオペレーションモードネットワークオペレーションモードネットワークオペレーションモード III で、で、で、で、B からからからから C へ戻った場合へ戻った場合へ戻った場合へ戻った場合



I → II 通常の位置登録更新(*)、その後通常 RA 更新 I → III or II → III IMSI デタッチ(4.3.4 節参照)、その後通常 RA 更新 II → I or III → I IMSI アタッチと組み合わされた RA 更新 III → II IMSI アタッチ(4.4.3 節参照)、その後通常 RA 更新

c) ネットワークオペレーションモード III で、B から CS サービス用の IMSI アタッチへ戻った場合、MS は以下

の処理を行うこと。

表表表表 4.7.1.6.3/TS 24.008: ネットワークオペレーションモードネットワークオペレーションモードネットワークオペレーションモードネットワークオペレーションモード III でででで B からからからから CS サービス用サービス用サービス用サービス用 IMSI アタッチへ戻った場合アタッチへ戻った場合アタッチへ戻った場合アタッチへ戻った場合

ネットワークオペレネットワークオペレネットワークオペレネットワークオペレーションーションーションーション


I → II 通常の位置登録更新(*)、その後通常 RA 更新 I → III 通常の位置登録更新(*)、その後タイプ通知"GPRS Detach"で GPRS デタッチ II → III 通常の位置登録更新(4.2.2 節参照)、その後タイプ通知"GPRS Detach"で

GPRS デタッチ II → I IMSI アタッチと組み合わされた RA 更新 III → I 複合 GPRS アタッチ III → II 通常の位置登録更新(4.2.2 節参照)、その後通常の GPRS アタッチ

(*)は、MSC/VLR 内の Gs 関係を削除するため

これ以上の詳細は実装問題。

4.7.1.6.2 Change of network mode of operation in UMTS (UMTS only) （UMTSにおけるネットワークオペレーションモードの変更（UMTSのみ））

MS が新しい RA に移動した場合は常に、MS によって実行される処理は、新旧 RA 内のオペレーションのネットワー

クモードに依存する。

MS がステート GMM-REGISTERED または GMM-ROUTING-AREA-UPDATING-INITIATED にあり、かつオペレーションモード A にある場合、MS は、

表表表表 4.7.1.6.4/TS 24.008: モードモードモードモード A



I → II 通常の位置登録更新(*)、その後通常 RA 更新 II → I IMSI アタッチとの複合 RA 更新

(*) (*)は、MSC/VLR 内の Gs 関係を削除するためこれ以上の詳細は実装の問題である。

4.7.1.6.3 Change of network mode of operation at UMTS to GSM inter-system change （UMTS→GSMへのシステム間変更時のネットワークオペレーションモードの変更）

MS が GSM 無線インタフェースをサポートする新しい RA に移動した場合は常に、MS によって実行される処理は、

新旧 RA 内のオペレーションのネットワークモードに依存する。


ペレーションモードにある場合、MS は、

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 99

a) UMTS 内の A の場合、GSM 内で GPRS オペレーションモード A または B に変更する MS は、以下の処

理を実行すること。

表表表表 4.7.1.6.5/TS 24.008: UMTS 内のモード内のモード内のモード内のモード A →→→→ GSM 内の内の内の内の GPRS モードモードモードモード A／／／／ B への変更への変更への変更への変更



UMTS I → GSM I 複合 RA 更新 UMTS II → GSM I IMSI アタッチとの複合 RA 更新 UMTS I → GSM II または UMTS I → GSM III

通常の位置登録更新(*)、その後通常 RA 更新

b) UMTS 内の A の場合、GSM 内でネットワークオペレーションモード III の GPRS オペレーションモード C に

変更する MS は、以下の処理を実行すること。

表表表表 4.7.1.6.6/TS 24.008: UMTS 内のモード内のモード内のモード内のモード A →→→→ GSM 内の内の内の内の GPRS モードモードモードモード C



UMTS I → GSM III また

は UMTS II → GSM III IMSI デタッチ(4.3.4 節参照)、その後通常 RA 更新

c) UMTS 内の A の場合、GSM 内でネットワークオペレーションモード III の場合のみ、MS 固有の処理によ

って CS サービス用の IMSI アタッチに変更する MS は、以下の処理を実行すること。

表表表表 4.7.1.6.7/TS 24.008: UMTS 内のモード内のモード内のモード内のモード A →→→→ GSM 内の内の内の内の CS サービス用サービス用サービス用サービス用 IMSI アタッチアタッチアタッチアタッチ



UMTS I → GSM III また

は UMTS II → GSM III

通常の位置登録更新（4.4.1 節参照）、その後デタッチタイプ通知"GPRS Detach"で GPRS デタッチ

d) UMTS 内の C の場合、GSM 内で GPRS オペレーションモード C に変更すべき MS は、通常の RA 更新処


e) UMTS 内の CS は、MS は通常の位置登録更新処理を実行すること。

(*) (*)は、MSC/VLR 内の Gs 関係を削除するため

これ以上の詳細は実装の問題である。

4.7.1.6.4 Change of network mode of operation at GSM to UMTS inter-system change （GSM→UMTSシステム間変更時のネットワークオペレーションモード変更）

MS が UMTS 無線インタフェースをサポートする新しい RA に移動した場合は常に、MS によって実行される処理は、

新旧 RA 内のオペレーションのネットワークモードに依存する。


ペレーションモードにある場合、MS は、

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 100

a) GSM 内で A または B の場合、MS は UMTS オペレーションモード A に変更し、以下の処理を実行するこ

と。

表表表表 4.7.1.6.8/TS 24.008: GSM 内モード内モード内モード内モード A／／／／ B →→→→ UMTS 内モード内モード内モード内モード A



GSM I → UMTS I 複合 RA 更新 GSM II → UMTS I IMSI アタッチとの複合 RA 更新 GSM I → UMTS II

通常の位置登録更新(*)、その後通常 RA 更新

GSM II → UMTS II or GSM III → UMTS II

通常の位置登録更新、その後通常 RA 更新

b) GSM 内の C では、UMTS 内でオペレーションモード C に変更される MS は、通常 RA 更新を実行すること。

c) GSM 内の C では、MS 固有の処理のために GSM 内でネットワークオペレーションモード III、GPRS オペ

レーションモード C から、UMTS 内でオペレーションモード A に変更される MS は、以下の処理を実行する

こと。

表表表表 4.7.1.6.9/TS 24.008:モードモードモードモード C→→→→UMTS 内のモード内のモード内のモード内のモード A への変更への変更への変更への変更



GSM III → UMTS I IMSI アタッチとの複合 RA 更新 GSM III → UMTS II IMSI アタッチ（4.4.3 節参照）、その後通常 RA 更新

d) 非 GPRS サービスのためだけの IMSI アタッチ、MS 固有の処理によって、GSM 内でネットワークオペレー

ションモード III で運用されていた MS が、UMTS 内でオペレーションモード A に変更される場合には、MSは以下の処理を行うこと。

表表表表 4.7.1.6.10/TS 24.008: 非非非非 GPRS サービスサービスサービスサービス用用用用 IMSI アタッチ、アタッチ、アタッチ、アタッチ、 UMTS 内モード内モード内モード内モード A への変更への変更への変更への変更



GSM III → UMTS I GPRS 用 GPRS と非 GPRS サービス用 GPRS の組合せ GSM III → UMTS II GPRS アタッチ

(*) (*)は、MSC/VLR 内の Gs 関係を削除するため

これ以上の詳細は実装の問題である。

4.7.1.7 Intersystem change between GSM and UMTS （GSMと UMTS間のシステム間変更）

UMTS→GSM、GSM→UMTS へのシステム間変更は、以下のケースに分類される。

a) 異なる RA に属するセル間のシステム間変更 MS によって実行される処理は、新旧 RA 内のオペレーションのネットワークモードに依存する。新 RA 内でネ

ットワークオペレーションモードが変更された場合、MS は 4.7.1.6 節で規定されたように動作すること。新 RA内でネットワークオペレーションモードが変更されなかった場合には、MS は現行 RA 内のネットワークオペレ

ーションモードに応じて、通常 RA 更新または複合 RA 更新処理を開始すること。

b) 同一 RA に属するセル間のシステム間変更

GPS 内の MS 内、または UMTS 内の PMM-CONNECTED モードにある MS 内で、READY タイマが動作し

ている場合には、MS は現行 RA 内のネットワークオペレーションモードに応じて、通常 RA 更新または複合

RA 更新処理を開始すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 101

GPS 内の MS 内、または UMTS 内の PMM-IDLE モードにある MS 内で、READY タイマが動作ない場合に

は、上りリンクのユーザデータまたはシグナリング情報を MS からネットワークに送信する必要が生じるまで、

（MS が同一 RA 内に留まる限り）MS は RA 更新処理を実行してはならない。

- MS が後にユーザデータまたはシグナリングデータを送信したときと同じアクセスネットワーク（GSM または UMTS）内にある場合には、MS はそのアクセスシステム用に定義された処理に従うこと。GSM セル

内では LLC PDU の送信、UMTS セル内では SERVICE REQUEST 処理開始である。

- MS が後にユーザデータまたはシグナリングデータを送信したときと異なるアクセスネットワーク（GSM または UMTS）内にある場合には、ユーザデータまたはシグナリングメッセージを送信する前に、情報現

行 RA のネットワークオペレーションモードに応じて通常または複合 RA 更新処理を実行すること。シグナ

リングメッセージが理由値"power off"を含む DETACH REQUEST メッセージであったならば、RA 更新処

理を実行する必要はない。

- 定期的 RA 更新タイマが満了した場合、MS は定期的 RA 更新処理を開始すること。

GSM 内のネットワーク、または UMTS 内の PMM-IDLE モードにあるネットワーク内で READY タイマが起動

されていない場合、もし下りリンクのユーザデータまたはシグナリング情報をネットワークから MS に送信する

必要があったならば、ネットワークは MS をページングすること。これには GSM セル、UMTS セル双方が含ま

れるものとする。

- MS が後にユーザデータまたはシグナリング情報を送信したアクセスネットワーク（GSM または UMTS）と同じネットワーク内でページング通知を受信した場合には、GSM セル内では任意の LLC PDU を送信す

るか、あるは UMTS セル内ではサービスタイプ"paging response" を通知する SERVICE REQUEST 処理

を開始すること。

- MS が後にユーザデータまたはシグナリング情報を送信したアクセスネットワーク（GSM または UMTS）とは異なるネットワーク内でページング通知を受信した場合には、情報現行 RA のネットワークオペレーシ

ョンモードに応じて通常または複合 RA 更新処理を実行すること。

4.7.2 GPRS Mobility management timers and UMTS PS signalling connection control （GPRSのMMタイマと UMTSシグナリングコネクション制御）

4.7.2.1 READY timer behaviour（READYタイマの動作）

4.7.2.1.1 READY timer behaviour (GSM only)（READYタイマの動作（GPRSのみ））

セルの更新処理を制御するために、アサインされた各 P-TMSI 毎に、MS およびネットワーク内で READY タイマ

T3314 を使用すること。

READY タイマが起動されている、またはデアクティブにされている場合、MS は新しいセルが選択されるたびにセル

更新処理を実行すること（TS 03.22 [82]参照）。RA の境界をまたぐ場合には、セル更新処理の代わりに RA 更新処


READY タイマ満了時、MS は、

- RA の境界をまたぐ場合には、RA 更新処理を実行する

- 新しいセルが選択された時も、セル更新は実行しない

他の全ての GMM 処理は、READY タイマの影響を受けることはない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 102

READY タイマは以下の場合に起動される、

- MS 内で、GMM エンティティが下位レイヤから、LLC NULL フレーム以外の LLC フレームが無線インタフェ

ース上で送信されたという通知を受信した場合、かつ

- ネットワーク内で、GMM エンティティが下位レイヤから、ネットワークが LLC NULL フレーム以外の LLC フレ

ームを無線インタフェース上で正常に受信したという通知を受信した場合

GMM-REGISTERED ステートに戻ったときに READY タイマを停止させるべきか否かを通知するために、ネットワー

クは GMM シグナリング処理の中に 'force to standby'（強制スタンバイ）IE を入れる。進行中の GMM 固有処理の

中で、複数のメッセージ内でこの 'force to standby' IE を受信したならば、後に受信したメッセージが適用される。

READY タイマがデアクティブにされた場合で、ネットワークが'force to standby' IE 内で「強制スタンバイ」を通知した

場合には、それが原因で READY タイマが修正されることがあってはならない。

READY タイマは、GMM-REGISTERED.SUSPENDED サブステートへ／からへのステート遷移によって影響され

てはならない。

GPRS アタッチまたは GPRS RA 更新処理を使用して、MS とネットワーク間のネゴシエーションのために READY タ

イマの値を使用することができる。

- MS が、自身が希望する READY タイマの値を通知したい場合には、MS は希望する値を ATTACH REQUEST および／または ROUTING AREA UPDATE REQUEST メッセージ内に入れる。希望値はデフォ

ルト値と同じでも異なってもよいし、READY タイマの機能をデアクティブにするために値と同じであってもよい。

- ネットワークが ATTACH REQUEST または ROUTING AREA UPDATE REQUEST メッセージ内でタイマ値

を受信したか否かに関わらず、ネットワークは READY タイマ用のタイマ値を ATTACH ACCEPT または ROUTING AREA UPDATE ACCEPT メッセージ内に１つづつ入れることができる。READY タイマ値が含ま

れていた場合には、ネットワークと MS はその値を GMM コンテキストに適用すること。

- MS が READY タイマ値を提案したが、ネットワークからの応答中に READY タイマ値が含まれていなかった

場合には、ネットワークと MS は MS によって提案された値を GMM コンテキストに適用すること。

- MS もネットワークも ATTACH ACCEPT または ROUTING AREA UPDATE ACCEPT メッセージ内に

READY タイマ値を入れなかった場合には、デフォルト値を使用すること。

ネゴシエーションされた READY タイマの値が、READY タイマ機能をデアクティブにするための値であった場合には、

READY タイマは満了せずに常に起動状態にあること。ネゴシエーションされた READY タイマの値が、READY タイ

マ機能をデアクティブにすることを通知しており、かつ同一処理内でネットワークが force to standby IE で'force to standby'（強制スタンバイ）を通知した場合には、READY タイマは満了せずに常に起動状態にあること。ネゴシエー

ションされた READY タイマの値が 0 であった場合には、READY タイマは直ちに停止されること。

LLC フレームの上りリンク送信遅延を保障するために、MS の READY タイマの値よりもネットワークの READY タイ

マの値を若干短くすること。これはネットワーク実装上の問題である。

READY タイマの値がネゴシエーションされたならば、MS は ATTACH ACCEPT または ROUTING AREA UPDATE ACCEPT メッセージを受信したならば（LLC フレーム、または要求されたならば ATTACH COMPLETE または ROUTING AREA UPDATE COMPLETE メッセージを送信して）、初期セル更新を実行して、新しい READY タイマ

の値を適用すること。ネットワークと MS の双方が Cell Notification をサポートしている場合には、初期セル更新には

LLC NULL フレーム以外の任意の LLC フレームを使用すること。新しい READY タイマの値が 0 に設定されている

場合、またはネットワークが force to standby IE で'force to standby'を通知している場合には、初期セル更新を実行し

てはならない。

4.7.2.1.2 Handling of READY timer in UMTS (UMTS only) （UMTS内での READYタイマの処理（UMTSのみ））

READY タイマは UMTS には適用されない。

MS は、ATTACH REQUEST および ROUTING AREA UPDATE REQUEST メッセージ内でネットワークに対して

READY タイマの値を通知することができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 103

UMTS と GSM 双方をサポートする MS が、ATTACH ACCEPT または ROUTING AREA UPDATE ACCEPT メッセ

ージ内で READY タイマの値を受信したならば、MS は受信した値を保存して、UMTS→GSM へのシステム変更時

に使用すること。

4.7.2.2 Periodic routing area updating（定期的 RA更新）

定期的 RA 更新は、MS が利用可能な状態にあることをネットワークに対して通知するために使用される。処理は

MS 内の定期的 RA 更新タイマ T3312 によって制御される。タイマ T3312 の値は、ネットワークから MS に対して、メ

ッセージ ATTACH ACCEPT と ROUTING AREA UPDATE ACCEPT 内で送信される。タイマ T3312 の値は RA 内

でユニークであること。

GSM では、READY タイマ停止／満了時に、タイマ T3312 はリセットされその初期値でスタートする。READY タイマ

起動時に、タイマ T3312 は停止されて次回スタート用の初期値に設定されること。READY タイマのネゴシエーション

後に READY タイマの値が 0 に設定されたならば、タイマ T3312 はリセットされて初期値でスタートする。初期

READY タイマの値が 0 の場合には、ROUTING AREA UPDATE REQUEST メッセージ送信時にタイマ T3312 はリ

セットされてその初期値でスタートする。

UMTS では、MS が PMM-CONNECTED モードから PMM-IDLE モードに移行したときにタイマ T3312 はリセットさ

れて初期値でスタートする。MS が PMM-CONNECTED モードに入ったときに、タイマ T3312 は停止される。

タイマ T3312 満了時に、定期的 RA 更新処理が開始され、タイマは次回スタート時の初期値に設定されること。

タイマ満了時に MS が GMM-REGISTERED.NORMAL-SERVICE 以外のステートにあった場合には、定期的 RA更新処理は MS が GMM-REGISTERED.NORMAL-SERVICE ステートに戻るまで延期される。

GSM では、タイマ満了時に MS オペレーションモード B にある MS がステート GMM-REGISTERED.SUSPENDEDにあった場合には、MS がそのステートを離れるまで RA 更新処理は延期される。

ネットワークは Mobile Reachable タイマを使用して定期的 RA 更新処理を監視する。Mobile Reachable タイマは、定

期的 RA 更新タイマよりも長いこと。Mobile Reachable タイマ満了時には、通常ネットワークは MS にページングメッ

セージを送信せずその他の適切なアクションを取ることができる。

GSM では、READY タイマ停止／満了時に Mobile Reachable タイマがリセットされて起動する。READY タイマ起動

時に、Mobile Reachable タイマは停止して次回起動時の初期値に設定される。

GSM では、READY タイマのネゴシエーション後に READY タイマの値が 0 に設定されたならば、Mobile Reachableタイマはリセットされて初期値で起動する。READY タイマの初期値が 0 の場合、ROUTING AREA UPDATE REQUEST メッセージを受信したときに Mobile Reachable タイマはリセットされて初期値で起動する。

UMTS では、MS が PMM-CONNECTED モードから PMM-IDLE モードに移行したときに、 Mobile Reachable タイマ

はリセットされて初期値で起動する。MS が PMM-CONNECTED モードに入ったときに、Mobile Reachable タイマは

停止する。

MS が GPRS サービスと非 GPRS サービスの双方に IMSI アタッチされており、かつ MS が登録された PLMN のカ

バレッジエリアを離れてタイマ T3312 が満了した場合には、

a) GPRS をサポートし、かつネットワークがネットワークオペレーションモード I にあることを通知しているセル内

のカバレッジエリアに MS が戻った場合には、MS は"combined RA/LA updating with IMSI attach"を通知して

複合 RA 更新処理を実行するか、あるいは、

b) GPRS をサポートし、かつネットワークがネットワークオペレーションモード II または III にあることを通知してい

るセル内のカバレッジエリアに MS が戻った場合には、MS は"Periodic updating"を通知して定期的 RA 更新

処理を実行し、定期的位置登録更新処理を実行すること、または、

c) GPRS をサポートしないセル内のカバレッジエリアに MS が戻った場合には、MS は定期的位置登録更新処理

または通常の位置登録更新処理を実行すること。さらに GPRS をサポートし、かつネットワークがネットワーク

オペレーションモード I にあることを通知しているセル内のカバレッジエリアに MS が戻った場合には、MS は

"combined RA/LA updating with IMSI attach"を通知して複合 RA 更新処理を実行すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 104

d) MS が新しい RA 内のカバレッジエリアに戻った場合には、4.7.5 節の説明が適用される。

ネットワークオペレーションモード I で運用されているネットワーク内で、MS が GPRS サービスと非 GPRS サービス双

方に IMSI アタッチされており、かつ MS が GPRS をサポートしないセルにキャンプしてタイマ T3312 が満了した場合

には、MS は MM 位置登録更新処理を開始すること。さらに MS が GPRS をサポートしてネットワークがオペレーショ

ンモード I にあることを通知しているセルに入った場合は、MS は複合 RA 更新処理を実行すること。

GSM では、GPRS MS がステート GMM-REGISTERED.SUSPENDED にあるときに、タイマ T3312 を停止してはなら

ない。

4.7.2.3 PMM-IDLE mode and PMM-CONNECTED mode (UMTS only) （PMM-IDLEモードと PMM-CONNECTEDモード（UMTSのみ））

PS ドメイン用の PS シグナリングコネクションが MS とネットワーク間で確立されたならば、MS は PMM-CONNECTED モードに入ること。MS は PMM-CONNECTED モード内では定期的 RA 更新処理を実行してはならな

い。

PS ドメイン用の PS シグナリングコネクションが MS とネットワーク間で開放されたならば、MS は PMM-IDLE モード

に入ること。PMM-IDLE モードにある MS は、定期的 RA 更新処理を実行すること。

4.7.2.4 Handling of Force to standby in UMTS (UMTS only) （UMTS内の Force to standby（強制スタンバイ）の処理（UMTSのみ））

強制スタンバイ（Force to standby）は UMTS では適用されない。

ネットワークは常に、Force to standby IE 内で Force to standby not indicated を通知すること。

MS は Force to standby IE を無視すること。

4.7.3 GPRS attach procedure（GPRSアタッチ処理） GPRS アタッチ処理は、以下の 2 つの目的で使用される。

- 通常の GPRS アタッチ。MS によって GPRS サービス用の IMSI アタッチのために実行される。MS オペレーシ

ョンモード C にある GPRS MS は、ネットワーク側のオペレーションモードには関係なく、通常の GPRS アタッチ

処理を使用すること。MS オペレーションモード A または B にある MS も、ネットワークがオペレーションモード II または III で運用される場合には、通常の GPRS アタッチ処理を使用すること。

- 複合 GPRS アタッチ処理。ネットワークオペレーションモード I で運用されるネットワークに提供された GPRSサービスおよび非 GPRS サービスに IMSI をアタッチするために、オペレーションモード A または B にある

MS 内の GPRS MS が使用する。

GPRS アタッチ処理が正常終了したならば、GMM コンテキストが確立される。

4.7.3.1 節では、IMSI を GPRS サービスのためだけにアタッチする GPRS アタッチ処理について説明する。IMSI をGPRS サービスと非 GPRS サービスの双方にアタッチするための複合 GPRS アタッチ処理については、4.7.3.2 節で

説明する。

非 GPRS サービスのために IMSI アタッチが要求され、かつ GMM コンテキストが存在する場合には、4.7.5.2 節で説

明される RA 更新処理を使用すること。

アタッチ試行が拒否された後の試行回数を制限するために、GPRS アタッチ試行カウンタが導入される。GPRS アタッ

チ試行カウンタは、4.7.3.1.5 節で規定されるように増加させること。GPRS アタッチ試行カウンタの値に応じて、特定

のアクションを実行すること。GPRS アタッチ試行カウンタが初期化されるのは、以下のケースである。

- MS 電源投入時

- SIM カード挿入時

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 105

- GPRS アタッチ処理が正常完了した場合

- GPRS サービス用の複合 GPRS アタッチ処理が、理由値#2, #16, #17 または #22 で完了した場合

- GPRS アタッチ処理が、理由値#11, #12 または #13 で完了した場合

さらに、MS がサブステート ATTEMPTING-TO-ATTACH にある場合には、

- タイマ T3302 満了時

- 新しい RA に入ったとき

- CM サブレイヤの要求により、アタッチがトリガされた場合

モバイル装置は、"forbidden location areas for regional provision of service"（局所的サービス供給のための禁止

LA）リストと同様に、"forbidden location areas for roaming"（ローミング用禁止 LA）のリストを持つ。これらのリストの

処理については、4.4.1 節で説明される。同一のリストが GMM 処理と MM 処理で使用される。

4.7.3.1 GPRS attach procedure for GPRSサービス（GPRSサービス用の GPRSアタッチ処理）

GPRS アタッチ処理とは、GPRS MS が GPRS サービス用の IMSI アタッチを行うために使用する GMM 処理を指す。

アタッチタイプの IE は、"GPRS attach"を通知すること。

4.7.3.1.1 GPRS attach procedure initiation（GPRSアタッチ処理初期化）

ステート GMM-DEREGISTERED において、MS はネットワークに ATTACH REQUEST メッセージを送信して GPRSアタッチ処理を初期化し、タイマ T3310 を起動し、ステート GMM-REGISTERED-INITIATED に入る。

UMTS と GSM 双方のケーパビリティを持つ MS、または GSM システムのケーパビリティだけを持つ MS は、有効な

P-TMSI と、利用可能な場合には P-TMSI と関連付けられた TMSI 署名と、P-TMSI と関連付けられた RAI を、

ATTACH REQUEST メッセージ内に入れること。利用可能な有効な P-TMSI がない場合には、P-TMSI および P-TMSI 署名の代わりに IMSI を入れること。

MS はまた、自身が CCCH 上でスプリット PG サイクルをサポートするか否かを、DRX パラメータ内で通知すること。

ネットワークによるスプリット PG サイクルのオプションサポートは、SI13 または PSI1 内で通知される。CCCH 上のス

プリット PG サイクルは、MS とネットワークの双方がスプリット PG サイクルオプションをサポートする場合に限ってネ

ットワークと MS 双方で適用される（GSM 05.02 参照）。

UMTS では、GPRS アタッチ処理の後、MS が確立された RR コネクションの延期を希望した場合、MS は follow-on request pending indicator を ON に設定する。

4.7.3.1.2 GMM common procedure initiation（GMM共通処理の初期化）

ネットワークは受信した IMSI, CKSN, 旧 RAI, P-TMSI, P-TMSI 署名などの情報に基づいて、GMM 共通処理、例え

ば GMM 識別や GMM 認証、そして暗号化処理などを開始することができる。

4.7.3.1.3 GPRS attach accepted by the network （ネットワークによる GPRSアタッチの受理）

ネットワークが GPRS アタッチ要求を受理した場合には、MS に対して ATTACH ACCEPT メッセージが送信される。

P-TMSI 再配置を GPRS アタッチ処理の一部にすることも可能である。RAI といっしょに ATTACH ACCEPT メッセー

ジ内に割当てるべき P-TMSI が入れられる。この場合、4.7.6 節に記載された通りに、ネットワークはステートを

GMM-COMMON-PROCEDURE-INITIATED に変更し、タイマ T3350 を起動すること。さらに、ネットワークは GMMコンテキスト用に P-TMSI 署名を割当てることも可能である。GMM コンテキストは次に、ATTACH ACCEPT メッセー

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 106

ジに入れられる。ATTACH ACCEPT メッセージ内で送信された LAI または PLMN が、"forbidden"（禁止）リスト内の

ものであった場合、そのようなエントリは削除すること。さらに、ネットワークは MS 発信 SMS 送信用に MS が使用す

る無線プライオリティレベルを、ATTACH ACCEPT メッセージ内に入れること。

GSM では、ネットワークが Cell Notification （セル通知）をサポートすることを通知するために、Cell Notification IEを ATTACH ACCEPT メッセージ内に入れること。

UMST では、MS が ATTACH REQUEST 内の follow-on request pending を通知された場合には、ネットワークは

RR コネクションを延長すること。また、MS からの通知がなくてもネットワークは RR コネクションを延長することがで

きる。

ATTACH ACCEPT メッセージを受信した MS は、受信した RAI を保存し、タイマ T3310 を停止し、GPRS アタッチ試

行カウンタをリセットし、RA 更新試行カウンタをリセットし、ステート GMM-REGISTERED に入り、GPRS 更新ステー

タスを GU1 UPDATED に設定する。

メッセージ内に P-TMSI が含まれていた場合には、MS はこの P-TMSI を GPRS サービス用の新しいテンポラリ識別

子として使用すること。この場合、ATTACH COMPLETE メッセージがネットワークに返される。MS は自身の旧 P-TMSI を削除し、新しい P-TMSI を保存すること。ネットワークが ATTACH ACCEPT メッセージ内に P-TMSI を入れ

なかった場合には、可能ならば旧 P-TMSI をキープすること。

メッセージに P-TMSI 署名が含まれている場合、MS はその P-TMSI 署名を GMM コンテキスト用の新しいテンポラ

リ署名として使用すること。MS は自身の旧 P-TMSI 署名を削除し、可能ならば新しい P-TMSI 署名を保存すること。

メッセージに P-TMSI 署名が含まれていない場合には、可能ならば旧 P-TMSI 署名を削除すること。

その後 UMTS では、MS が follow-on request pending を通知し、CM アプリケーション要求ペンディングを持っている

場合には、MS はネットワークに適切なメッセージ（例えば ACTIVATE PDP CONTEXT REQUEST）を送信すること。

GSM では、ATTACH ACCEPT メッセージに Cell Notification IE が含まれている場合には、次に MS は LLC NULLフレームの使用を開始し、セル更新を実行すること。ATTACH COMPLETE メッセージを受信したネットワークは、タ

イマ T3350 を停止し、ステートを GMM-REGISTERED に変更し、ATTACH ACCEPT メッセージ内で送信された P-TMSI を有効と見なすこと。

4.7.3.1.4 GPRS attach not accepted by the network （ネットワークが GPRSアタッチを受理しなかった場合）

ネットワークがアタッチ要求を受理しなかった場合には、ATTACH REJECT メッセージが MS に送信される。

ATTACH REJECT を受信した MS は、タイマ T3310 を停止させ、拒否理由値に応じて以下のいずれかのアクション

を取る。

# 3 (Illegal MS)（不正 MS）

# 6 (Illegal ME)（不正 ME）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し（そしてそれを 4.1.3.2 節の記

載に従って保存し）、全ての P-TMSI, P-TMSI 署名、そして GPRS 暗号鍵シーケンス番号を削除すること。

新しい GMM ステートは GMM-DEREGISTERED である。MS の電源が切断されるまで、または SIM カー

ドが抜かれるまで、SIM カードは GPRS サービスについて無効と見なすこと。

MM 処理の過程で MS に IMSI がアタッチされた場合には、MS はさらに更新ステータスを U3 ROAMING NOT ALLOWED に設定し、全ての TMSI、LAI、暗号鍵シーケンス番号を削除すること。新しい MM ステ

ートは MM IDLE である。MS の電源が切断されるまで、または SIM カードが抜かれるまで、SIM カードは

非 GPRS サービスについて無効と見なすこと。

# 7 (GPRS services not allowed) (許可されていない GPRS サービス)


載に従って保存し）、全ての P-TMSI, P-TMSI 署名、RAI 、そして GPRS 暗号鍵シーケンス番号を削除す

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 107

ること。MS の電源が切断されるまで、または SIM カードが抜かれるまで、SIM カードは GPRS サービスに

ついて無効と見なすこと。新しいステートは GMM-DEREGISTERED である。

# 8 (GPRS services and non-GPRS services not allowed)（許可されていない GPRS サービスと非 GPRS サービ

ス)


載に従って保存し）、全ての P-TMSI, P-TMSI 署名、RAI 、そして GPRS 暗号鍵シーケンス番号を削除す

ること。新しい GMM ステータスは GMM-DEREGISTERED。新しい MM ステートは MM IDLE。

MS は更新ステータスを U3 ROAMING NOT ALLOWED に設定し、全ての TMSI、LAI、暗号鍵シーケン

ス番号を削除すること。MS の電源が切断されるまで、または SIM カードが抜かれるまで、SIM カードは

GPRS サービスと非 GPRS サービスについて無効と見なすこと。

# 11 (PLMN not allowed) (許可されていない PLMN)

# 12 (Location area not allowed)(LA が許可されていない)

# 13 (Roaming not allowed in this location area) (本 LA ではローミングが許可されていない)

MS は全ての RAI, P-TMSI, P-TMSI 署名,および保存されている GPRS 暗号鍵シーケンス番号を削除し、

GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し（そして 4.1.3.2 節に従ってそれを保

存し）、GPRS アタッチ試行カウンタをリセットし、ステートを GMM-DEREGISTERED に変更すること。

MM 処理の過程で MS に IMSI がアタッチされた場合には、MS は追加セット設定の過程で更新ステータ

スを U3 ROAMING NOT ALLOWED に設定し、全ての TMSI, LAI,および暗号鍵シーケンス番号を削除

し、位置更新試行カウンタをリセットしすること。新しい MM ステートは MM IDLE。

MS は、適切な禁止リスト内に LAI または PLMN 識別子を保存すること。つまり、理由値#11 で forbidden PLMN list"内に、理由値#12 で"forbidden location areas for regional provision of service"のリスト内で、ま

たは理由値#13 で"forbidden location areas for roaming"のリスト内に保存すること。理由値#11 または#13を受信した MS は、セル選択の代わりに PLMN 選択処理を実行すること。

それ以外の値は異常なケースとみなされる。これらのケースにおける MS の動作についての仕様は、4.7.3.1.5 節で

規定される。

4.7.3.1.5 Abnormal cases in the MS（異常なケース、MS側）

以上なケースは次のように分類できる。

a) アクセスクラス制御によるアクセス禁止

GPRS アタッチ処理を開始してはならない。MS は現行のサービスセルに留まり、通常のセル再選択処理を開

始する。できるだけ早く、つまりアクセスが許可されるか、またはセルが変更されたならば、GPRS アタッチ処

理を開始すること。

b) ATTACH ACCEPT または ATTACH REJECT メッセージの前に下位レイヤの失敗を受信した場合

処理を中断すること。MS は以下の処理を続行すること。

c) T3310 タイムアウト

タイマが 1 回目に満了したならば、MS はタイマ T3310 をリセットして再開し、ATTACH REQUEST メッセージ

を再送すること。本再送は 4 回まで繰り返される。つまり、タイマ T3310 が 5 回目に満了したならば、GPRS ア

タッチ処理は中断され、MS は以下の処理を続行すること。

d) ATTACH REJECT、4.7.3.1.4 節で扱われていないその他の理由 MS は以下の処理を続行すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 108

e) 同一 RA 内でのセルの変更（GSM のみ）

MS がステート GMM-REGISTERED-INITIATED にあるときに同一 RA 内でのセルの変更が発生した場

合には、アタッチ処理が完了する前にセル更新処理を実行すること。

f) 新しい RA 内のセルへの変更

ATTACH ACCEPT または ATTACH REJECT メッセージを受信する前に、新しい RA 内のセルへの変更

が発生した場合には、GPRS アタッチ処理を中断し、直ちに再初期化すること。ATTACH ACCEPT メッセージを受信したが、ATTACH COMPLETE メッセージが送信される前に RA の境界をまたいだ場合には、

GPRS アタッチ処理を中断し、RA 更新処理を開始すること。GPRS アタッチ処理の過程で P-TMSI が割当

てられた場合には、RA 更新処理でこの P-TMSI を使用すること。GPRS アタッチ処理の過程で P-TMSI といっしょに P-TMSI 署名が割当てられた場合には、RA 更新処理でこの P-TMSI 署名を使用すること。

g) モバイル発のデタッチ要求

MS がステート GMM-REGISTERED-INITIATED にある場合には、GPRS アタッチ処理を中断し、GPRSデタッチ処理を実行すること（4.7.4.1 節参照）。

h) Procedure collision（処理のバッティング）

MS が DETACH REQUEST メッセージを受信した時のネットワークが、デタッチタイプ're-attach not required‘のステート GMM-REGISTERED-INITIATED にある場合には、GPRS デタッチ処理を進めて、

GPRS アタッチ処理は中断すること。それ以外の場合には、GPRS アタッチ処理を進めて、DETACH REQUEST メッセージは無視すること。

ケース b,c,d では、MS は以下のように処理を進めること。タイマ T3310 が起動している場合には停止させること。

GPRS 試行カウンタは漸増される。

GPRS アタッチ試行カウンタ値が 5 未満の場合

- タイマ T3311 を開始させ、ステートは GMM-DEREGISTERED.ATTEMPTING-TO-ATTACH に変更される

GPRS アタッチ試行カウンタ値が 5 以上の場合

- MS は RAI, P-TMSI, P-TMSI 署名、そして GPRS 暗号鍵シーケンス番号を全て削除し、GPRS 更新ステータ

スを GU2 NOT UPDATED に設定し、タイマ T3302 を起動すること。ステートは GMM-DEREGISTERED..ATTEMPTING-TO-ATTACH、またはオプションとして GMM-DEREGISTERED.PLMN-SEARCH (4.2.4.1.2 節参照)に変更される。

- UMTS では、ケース c では MS が PS シグナリングコネクションを開放し、ケース d ではネットワークが該当

MS 用の PS シグナリングコネクションを開放すること（TS 25.331 参照）。

4.7.3.1.6 Abnormal cases on the network side （異常なケース、ネットワーク側）

異常なケースとして、以下のケースが規定される。

a) 下位レイヤの失敗

MS から ATTACH COMPLETE メッセージを受信する前、かつ新しい P-TMSI（または新しい P-TMSI と新し

い P-TMSI 署名）が割当てられる前に、下位レイヤで失敗が発生した場合には、ネットワークは古い P-TMSIを有効と判断（4.7.1.5 節参照）するまでは、対応する P-TMSI 署名に関連付けられた新旧 P-TMSI をどちらも

有効とみなすこと。またメッセージ ATTACH ACCEPT を再送してはならない。この間、ネットワークは、以下

の処理を行うことができる。

- MS が後続メッセージ中で旧 P-TMSI を使用した場合には、識別処理の後に P-TMSI 再割当処理を行う。

b) プロトコルエラー

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 109

プロトコルエラーといっしょに ATTACH REQUEST メッセージを受信した場合には、ネットワークは以下の理

由値のうち 1 つといっしょに、ATTACH REJECT メッセージを返すこと。


#99: Information element non-existent or not implemented（実在しない／実装されていない IE）


#111: Protocol error, unspecified（プロトコルエラー、未分類）


タイマが 1 回目に満了したならば、ネットワークは ATTACH ACCEPT メッセージを再送し、タイマ T3350 をリ

セットして再開すること。

メッセージの再送は 4 回まで繰り返される。つまり、タイマ T3350 が 5 回目に満了したならば、GPRS アタッチ

処理は中断される。ATTACH ACCEPT メッセージ内で新しい P-TMSI または新しい P-TMSI が、新しい P-TMSI 署名といっしょに割当てられたならば、ネットワークは古い P-TMSI が無効と判断（4.7.1.5 節参照）でき

るまでは、対応する P-TMSI 署名に関連付けられた新旧 P-TMSI をどちらも有効とみなすこと。この間、ネット

ワークは、ケース a で規定された処理を行う。

d.1) ATTACH REQUEST 受信

- ATTACH REQUEST メッセージ内で受信した IE のうち、1 つまたは複数の IE が、前回の ATTACH REQUEST メッセージ内で受信した IE とは異なっていた場合には、既に開始された GPRS アタッチ処理を

中断し、新しい GPRS アタッチ処理を進行させること。または、

- IE に違いがない場合には、ATTACH ACCEPT メッセージを再送すること。

d.2) 複数の ATTACH REQUEST メッセージを受信し、かつ ATTACH ACCEPT または ATTACH REJECT メ

ッセージが送信されなかった場合

- ATTACH REQUEST メッセージ内で受信した IE のうち、1 つまたは複数の IE が、前回の ATTACH REQUEST メッセージ内で受信した IE とは異なっていた場合には、既に開始された GPRS アタッチ処理を

中断し、新しい GPRS アタッチ処理を進行させること。または、

- IE に違いがない場合には、ネットワークは前回のアタッチ処理を継続すること。今回以降の ATTACH ACCEPT メッセージを処理してはならない。

e) ステート GMM-REGISTERED で ATTACH REQUEST メッセージを受信した場合

ステート GMM-REGISTERED で ATTACH REQUEST メッセージを受信した場合には、ネットワークは GMM共通処理を開始することができる。その結果、既にアタッチされている MS から ATTACH REQUEST メッセー

ジが送信された場合には、GMM コンテキストと PDP コンテキストがもし存在するならば削除し、新しい

ATTACH REQUEST メッセージを処理すること。

f) ATTACH COMPLETE メッセージ受信前に ROUTING AREA UPDATE REQUEST メッセージを受信した場

合

タイマ T3350 を停止させること。割当てられた P-TMSI は有効と判断し、4.7.5 節で説明された RA 更新処理を

進行させること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 110

MS Network

ATTACH REQUESTStart T3310

ATTACH ACCEPT

ATTACH REJECTStop T3310

Stop T3310

or

ATTACH COMPLETEStop T3350

ATTACH REQUESTStart T3310

If P-TMSI and/orTMSI allocatedStart T3350

If P-TMSI and/orTMSI allocated

図図図図 4.7.3/1 TS 24.008: GPRS アタッチ処理と複合アタッチ処理と複合アタッチ処理と複合アタッチ処理と複合 GPRS アタッチ処理アタッチ処理アタッチ処理アタッチ処理

4.7.3.2 Combined GPRS attach procedure for GPRS and non-GPRS services （GPRS サービスと非 GPRSサービスの複合 GPRSアタッチ処理）

複合 GPRS アタッチ処理とは、MS がオペレーションモード A または B にあり、ネットワークがモード I にあるときに、

GPRS MS が GPRS サービスと非 GPRS サービス用に IMSI をアタッチするために使用する GMM 処理のことを指す。

MS オペレーションモード A または B で運用されている GPRS MS が、既に MM 固有の IMSI アタッチ処理を使用し

て非 GPRS サービスにアタッチされているものの、GPRS サービス用の IMSI アタッチの追加実行を希望した場合に

も、複合 GPRS アタッチ処理が使用される。

アタッチタイプ IE は"combined GPRS attach"を通知すること。この場合、複合 GPRS アタッチ処理が使用するメッセー

ジ ATTACH ACCEPT, ATTACH COMPLETE, および ATTACH REJECT は、GPRS サービスと非 GPRS サービス

双方のための情報を伝送する。

4.7.3.2.1 Combined GPRS attach procedure initiation （複合 GPRSアタッチ処理の開始）

MS が、GMM ステート GMM-DEREGISTERED、MM ステート MM IDLE にある場合には、MS はネットワークに

ATTACH REQUEST メッセージを送信して複合 GPRS アタッチ処理を開始し、タイマ T3310 を起動し、ステート

GMM-REGISTERED-INITIATED および MM LOCATION UPDATING PENDING に入る。

MS は、有効な P-TMSI と、可能な場合には P-TMSI に関連付けられた P-TMSI 署名、そして P-TMSI に関連付けら

れた RAI（routing area identity）を、ATTACH REQUEST メッセージ内に入れること。利用可能な有効な P-TMSI がない場合には、P-TMSI および P-TMSI 署名の代わりに IMSI を入れること。さらに、用可能な有効な P-TMSI がな

い場合、MS は TMSI ステート IE を入れること。

UMTS では、GPRS アタッチ後に MS が RR コネクション確立の延長を希望した場合には、MS は follow-on request pending indicator を ON に設定することもできる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 111

4.7.3.2.2 GMM Common procedure initiation （GMM共通処理の開始）

ネットワークは、受信した情報（IMSI, CKSN, 旧 RAI, P-TMSI 、そして P-TMSI 署名など）に応じて GMM 共通処理

（GMM 識別と GMM 認証および暗号化処理など）を開始することができる。

4.7.3.2.3 Combined GPRS attach accepted by the network （ネットワークによる複合 GPRSアタッチの受理）

ATTACH ACCEPT メッセージ内で受信したアタッチ結果 IE の値に応じて、以下の 2 つのケースに分けられる。

ケース 1) アタッチ結果 IE が"combined GPRS attach"を示していた場合：GPRS サービスと非 GPRS サービス用

の IMSI アタッチ処理は正常に完了

ケース 2) アタッチ結果 IE が"GPRS only"を示していた場合：GPRS サービス用の IMSI アタッチ処理は正常完了

したが、非 GPRS サービス用の IMSI アタッチ処理は失敗したことを示す

4.7.3.2.3.1 Combined attach successful for GPRS and non-GPRS services （GPRSサービスと非 GPRSサービス用の複合アタッチ処理正常完了）

4.7.3.1.3 節で規定される GPRS サービス用の IMSI アタッチの詳細を、以下に述べる。それに加えて、非 GPRS サー

ビス用には、以下に述べる IMSI アタッチが適用される。

複合 GPRS アタッチ処理の一部として、TMSI 再割当を行うこともできる。その場合、割当てられた TMSI は、LAI といっしょに ATTACH ACCEPT メッセージ内に入れられる。この場合、ネットワークはステートを GMM-COMMON-PROCEDURE-INITIATED に変更し、4.7.6 節に説明された通りタイマ T3350 を起動すること。

MS は ATTACH ACCEPT メッセージを受信したならば、受信した LAI を保存し、タイマ T3310 を停止させ、位置登

録更新試行カウンタをリセットし、更新ステータスを U1 UPDATED に設定すること。メッセージ内に IMSI が含まれて

いた場合には、MS には TMSI は割当てられないので、全ての TMSI を削除すること。メッセージ内に TMSI が含ま

れていた場合には、MS はその TMSI を新しいテンポラリ識別子として使用すること。MS は旧 TMSI を削除し、新し

い TMSI を保存すること。この場合、ATTACH COMPLETE メッセージがネットワークに返される。ネットワークが

ATTACH ACCEPT メッセージ内に TMSI も IMSI も入れなかった場合には、利用可能ならば旧 TMSI をキープする

こと。新しい MM ステートは MM IDLE、新しい GMM ステートは GMM-REGISTERED である。

位置登録更新処理をトリガするのに使用されるタイマ（T3211, T3212 など）が起動されている場合には停止すること。

ATTACH COMPLETE メッセージを受信したネットワークは、タイマ T3350 を停止させ、ステートを GMM-REGISTERED に変更させ、新しい TMSI を有効と見なすこと。

4.7.3.2.3.2 Combined attach successful for GPRS services only （複合アタッチのうち GPRSサービス用だけが正常終了した場合）

4.7.3.1.3 節で規定される GPRS サービス用の IMSI アタッチ処理の詳細を以下に述べる。それに加えて、非 GPRSサービス用には、以下に述べる IMSI アタッチが適用される。

ATTACH ACCEPT メッセージを受信した MS は、拒否理由に応じて以下のアクションのうちどれか 1 つを取ること。

# 2 (IMSI unknown in HLR) （HLR 内で未知の IMSI）

MS は更新ステータスを U3 ROAMING NOT ALLOWED に設定し、TMSI、LAI、そして暗号鍵シーケン

ス番号を全て削除すること。新しい MM ステートは MM IDLE。電源が切断されるまで、または SIM カード

が抜かれるまで、SIM カードは非 GPRS サービスに対して無効であると見なされる。

# 16 (MSC temporarily not reachable)（MSC が一時的にアクセス不可）

# 17 (Network failure)（ネットワークエラー）

# 22 (Congestion)（輻輳）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 112

MS はステートを GMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM に変更すること。タイマ T3310が起動されている場合には停止すること。RA 更新試行カウンタを漸増させること。

RA 更新試行カウンタの値が 5 未満で、かつ保存された RAI の値が現行サービスセルの RAI と等しく、か

つ GMM 更新ステータスが GU1 UPDATED の場合には、

- MS は GMM 更新ステータスを GU1 UPDATED のまま維持し、ステートを GMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM に変更すること。MS はタイマ T3311 を開始させるこ

と。タイマ T3311 が満了したならば、"combined RA/LA updating with IMSI attach"を通知して複合 RA更新処理が再度トリガされる。

RA 更新試行カウンタの値が 5 以上の場合

- MS はタイマ T3302 を開始させ、ステートを GMM-REGISTERED.ATTEMPTING-TO-UPDATE-MMに変更させる。

- MS オペレーションモード A で運用されている GPRS MS は、次に適切な MM 固有の処理を続行する

こと。MS オペレーションモード B で運用されている GPRS MS は、次に適切な MM 固有の処理を続

行することができる。複合 GMM 処理が正常完了して新しい RA に入るまで、MM サブレイヤはネット

ワークオペレーションモード II で機能すること。新しい MM ステートは IDLE。

それ以外の値は、異常なケースと見なされ、複合アタッチ処理は、 GPRS サービスに対しても非 GPRS サービスに対

しても失敗したものと見なされる。これらのケースにおける MS の動作は、4.7.3.2.5 節で規定される。

4.7.3.2.4 Combined GPRS attach not accepted by the network （ネットワークが複合 GPRSアタッチを受理しなかった場合）

ネットワークが、GPRS サービスに対するアタッチ要求も、非 GPRS サービスアタッチ要求も拒否した場合には、

ATTACH REJECT が MS に対して送信される。ATTACH REJECT メッセージを受信した MS は、タイマ T3310 を停

止させ、拒否理由に応じて以下のアクションのうちどれか１つを取ること。



# 8 (GPRS service and non-GPRS service not allowed)（GPRS サービスおよび非 GPRS サービス不許可）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し（その値を 4.1.3.2 節に従って保

存し）、P-TMSI, P-TMSI 署名, RAI、そして GPRS 暗号鍵シーケンス番号を全て削除すること。新しい GMMステートは GMM-DEREGISTERED。新しい MM ステートは MM IDLE。

MS は更新ステータスを U3 ROAMING NOT ALLOWED に設定し、TMSI, LAI、そして暗号鍵シーケンス番

号を全て削除すること。電源が切断されるまで、または SIM カードが抜かれるまで、SIM カードは非 GPRS サ

ービスおよび非 GPRS サービスに対して無効であると見なすこと。

# 7 (GPRS service not allowed) （GPRS サービス不許可）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し（その値を 4.1.3.2 節に従って保

存し）、P-TMSI, P-TMSI 署名, RAI、そして GPRS 暗号鍵シーケンス番号を全て削除すること。電源が切断さ

れるまで、または SIM カードが抜かれるまで、SIM カードは GPRS サービスに対して無効であると見なすこと。

新しい GMM ステートは GMM-DEREGISTERED。MM ステートは MM IDLE。MS オペレーションモード A に

ある GPRS MS は、次に MM IMSI アタッチ処理を使用して非 GPRS サービス用 IMSI アタッチ処理を実行す

ること。MS オペレーションモード B にある GPRS MS は、次に MM IMSI アタッチ処理を使用して非 GPRS サ

ービス用 IMSI アタッチ処理を実行すること。

# 11 (PLMN not allowed)（PLMN 不許可）

# 12 (Location area not allowed)（LA 不許可）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 113

# 13 (Roaming not allowed in this location area)（本 LA 内でローミング不許可）

MS は保存されている RAI, P-TMSI, P-TMSI 署名、GPRS 暗号鍵シーケンス番号を全て削除し、GPRS 更新

ステータスを GU3 ROAMING NOT ALLOWED に設定し（その値を 4.1.3.2 節に従って保存し）、RA 更新試

行カウンタをリセットし、GPRS アタッチ試行カウンタをリセットし、ステートを GMM-DEREGISTERED に変更す

ること。MS は更新ステータスを U3 ROAMING NOT ALLOWED に変更し、RA 更新試行カウンタをリセットし、

TMSI, LAI、暗号鍵シーケンス番号を全て削除すること。新しい MM ステートは MM IDLE。

MS は適切な禁止リスト（例えば理由値#11 の場合は"forbidden PLMN list"、理由値#12 の場合は"forbidden location areas for regional provision of service"のリスト内、理由値#13 の場合は"forbidden location areas for roaming"のリスト内）に、LAI または PLMN 識別子を保存すること。理由値#11 または#13 を受信した場合に

は、MS はセル選択の代わりに PLMN 選択を実行すること。

上記以外の値は異常なケースと見なされる。これらのケースにおける MS の動作は、4.7.3.2.5 節で規定される。


4.7.3.1.5 節で規定される異常なケースは、以下のように修正されて適用される。

GPRS アタッチ試行カウンタの値が 5 よりも小さい場合には、MM ステートは MM LOCATION UPDATING PENDING のままである。

4.7.3.1.5 節の規定に従って GPRS アタッチ試行カウンタの値が漸増された場合、MS が取るべき次のアクションは、

LAI（SIM カード上と、現行サービスセルのうち 1 つのセル内に保存される）とアタッチ試行カウンタの値によって決ま

る。

- 更新ステータスが U1 UPDATED、かつ保存された LAI の値が現行サービスセルのうち 1 つのセルの値と等

しく、かつアタッチ試行カウンタの値が 5 よりも小さい場合には、MS は更新ステータスを U1 UPDATED のま

まキープすること。新しい MM ステートは MM IDLE 、サブステートは NORMAL SERVICE。

- 更新ステータスが U1 UPDATED 以外の場合、または保存された LAI の値が現行サービスセル内のセルの

値と異なる場合、またはアタッチ試行カウンタの値が 5 以上の場合には、MS は SIM カード上に保存されてい

る LAI、TMSI、そして暗号鍵シーケンス番号を全て削除し、更新ステータスを U2 NOT UPDATED に設定す

ること。新しい MM ステートは MM IDLE、サブステートは ATTEMPTING TO UPDATE。

4.7.3.2.6 Abnormal cases on the network side（異常なケース、ネットワーク側）

4.7.3.1.6 に規定される異常なケースにおける動作が適用されるが、例外として、旧 TMSI に P-TMSI および P-TMSI署名が追加されるケース a および c の場合には、新しい TMSI が後続メッセージ内で MS によって使用されるまで適

用されない。

4.7.4 GPRS detouch procedure（GPRSデタッチ処理） GPRS デタッチが使用されるのは以下の場合である。

- GPRS サービスのためだけに IMSI をデタッチする場合。ネットワークオペレーションモードに関係なく、全種類

の GPRS MS が本処理を使用する。

- MS オペレーションモード A または B にある MS において、GPRS サービスと GPRS サービス用、または非

GPRS サービス用に IMSI をデタッチするために、GPRS MS が複合 GPRS デタッチ処理として使用。これはネ

ットワークがネットワークオペレーションモード I にある場合のみ。

- ネットワークで失敗が発生したケースで、ネットワークが MS に対して、既にアクティブな PDP コンテキストの

次の起動として再アタッチを実行すべきであることを通知する場合。

GPRS デタッチ処理または GPRS と非 GPRS サービス用複合 GPRS デタッチ処理が完了した後、GMM コンテキスト

は開放される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 114

MS の電源が切断された場合や、SIM カードが MS から抜かれた場合、または MS の GPRS ／非 GPRS ケーパビリ

ティが無効にされている場合には、 GPRS デタッチ処理は MS が起動すること。GPRS サービス用の IMSI デタッチ処

理は、ネットワーク側が起動することもできる。GPRS デタッチの結果、MS は GPRS サービスもしくは非 GPRS サー

ビスのいずれか、または双方のサービスについてインアクティブであるとマークされる。

GSM では、GPRS デタッチが実行された場合には、MS およびネットワーク内の SM エンティティと LLC エンティティ

間でピアツーピアのシグナリングなしで、PDP コンテキストがローカルにデアクティブにされる。

UMTS では、GPRS デタッチ処理が実行された場合、MS およびネットワーク内の SM エンティティと LLC エンティティ

間でピアツーピアのシグナリングなしで、PDP コンテキストがローカルにデアクティブにされる。

4.7.4.1 MS initiated GPRS detach procedure （MSによる GPRSデタッチ処理の開始）

4.7.4.1.1 MS initiated GPRS detach procedure initiation （MSによる GPRSデタッチ処理の開始）

MS は、DETACH REQUEST メッセージを送信して GPRS デタッチ処理を開始する。detach type IE は、"GPRS detouch with switching off", "GPRS detouch without switching off", "IMSI detach", "GPRS/IMSI detach with switching off" 、または "GPRS/IMSI detach without switching off"のいずれかである。

MS は DETACH REQUEST メッセージ内に P-TMSI を入れること。MS はまた、可能な場合には有効な P-TMSI 署名を入れること。

MS の電源が切断されていない場合には、DETACH REQUEST メッセージ送信後、MS はステート

GMM_REGISTERED にあり、タイマ T3321 を起動すること。detach type IE の値が"IMSI Detach"である場合には、

MS はステート GMM-REGISTERED.IMSI-DETACH_INITIATED に入ること。それ以外の場合には MS はステート

GMM-DEREGISTERED-INITIATED に入ること。detach type IE の値が"IMSI Detach" または "GPRS/IMSI Detach"であった場合には、ステート MM IMSI DETACH PENDING に入る。MS の電源を切る必要が生じた場合には、MSは 5 秒間 DETACH REQUEST メッセージの送信を試行すること。この時間内に MS が DETACH REQUEST メッセ

ージを送信できた場合には、MS の電源を切断できる。

detach type IE の値が"GPRS detouch without switching off "であり、かつ MS が GPRS サービスと非 GPRS サービス

用にアタッチされており、かつネットワークがネットワークオペレーションモード I で運用されている場合には、もし MS内でタイマ T3212 がまだ起動されていなければ DETACH REQUEST メッセージ送信後にタイマ T3212 をその初期

値にセットして再開すること。

4.7.4.1.2 MS initiated GPRS detach procedure completion for GPRS services only （MSが開始した GPRSデタッチ処理の完了、GPRSサービス用のみ）

ネットワークは DETACH REQUEST メッセージを受信した場合、もし detach type IE の値が電源断によってデタッチ

要求が送信されなかったことを示していたならば、MS に DETACH ACCEPT メッセージを送信すること。電源断が通

知された場合、ネットワークが DETACH REQUEST メッセージを受信したときに処理は完了する。ネットワークと MSは PDP コンテキストをデアクティブにし、もしあれば（1 つまたは複数の）論理的リンクをデアクティブにすること。

GPRS サービス用のネットワーク内では、MS はインアクティブとしてマークされる。MS およびネットワーク内で、ステ

ート GMM-DEREGISTERED に入る。

UMTS では、電源断によってデタッチが送信されたならば、ネットワークは該当 MS 用の下位レイヤのリソースを開

放すること（TS 25.331 参照）。

注: ネットワークが DETACH REQUEST メッセージを受信した場合、もし detach type IE の値が電源断によ

ってデタッチ要求が送信されたのではないことを示していたならば、識別処理だけでなく、認証および

暗号化処理を実行することができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 115

4.7.4.1.3 MS initiated combined GPRS detach procedure completion （MS開始型複合 GPRSデタッチ処理の完了）

ネットワークが DETACH REQUEST メッセージを受信した場合、もし detach type IE の値が電源断によってデタッチ

要求が送信されなかったことを示していたならば、MS に DETACH ACCEPT メッセージを送信すること。detach type IE の値に応じて、以下の処理が適用される。

GPRS/IMSI のデタッチ MS は GPRS と非 GPRS サービス用ネットワーク内で、インアクティブとしてマークされる。ネットワークと MS は、PDPコンテキストをデアクティブにし、もしあれば（1 つまたは複数の）論理的リンクをデアクティブにすること。MS、ネットワ

ーク双方とも、ステート GMM-DEREGISTERED と MM NULL に入る。

UMTS では、電源断によってデタッチが送信されたならば、ネットワークは該当 MS 用の下位レイヤのリソースを開

放すること（TS 25.331 参照）。

IMSI のデタッチ MS は非 GPRS サービス用ネットワーク内で、インアクティブとしてマークされる。MS とネットワーク内で、ステート

MM NULL に入る。


異常なケースは次のように分類される。

a) T3321 タイムアウト

タイマ満了第一回目には、MS は DETACH REQUEST メッセージを再送し、タイマ T3321 をリセットして再開

すること。この再送は 4 回まで繰り返される。つまり、5 回目にタイマ T3321 が満了したならば、GPRS デタッチ

処理は中断され、MS はステートを以下のように変更する。

- "IMSI detach"が要求された場合には、ステート MM-NULL

- "IMSI Detach"が要求された場合には、ステート GMM-REGISTERED.NORMAL-SERVICE

- "GPRS デタッチ"が要求された場合には、ステート GMM-DEREGISTERED

- "GPRS/IMSI"デタッチが要求された場合には、ステート GMM-DEREGISTERED および MM-NULL

b) DETACH ACCEPT メッセージ受信前に下位レイヤでエラーが発生した場合

デタッチ処理は中断され、MS はステートを以下のように変更する。

- "IMSI detach"が要求された場合には、ステート MM-NULL

- "IMSI Detach"が要求された場合には、ステート GMM-REGISTERED.NORMAL-SERVICE

- "GPRS デタッチ"が要求された場合には、ステート GMM-DEREGISTERED

- "IMSI/GPRS"デタッチが要求された場合には、ステート GMM-DEREGISTERED

c) デタッチ処理のバッティング

MS が開始した GPRS デタッチ処理が完了する前に DETACH REQUEST メッセージを受信した場合には、

MS はネットワークに DETACH ACCEPT メッセージを送信すること。

d) デタッチと GMM 共通処理のバッティング

理由値"power off"を含む GPRS デタッチ

- GPRS デタッチ処理が完了する前に、MS が GMM 共通処理中で使用されたメッセージを受信した場合に

は、そのメッセージは無視して GPRS デタッチ処理を継続すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 116

"power off"以外の理由値を含む GPRS デタッチ

- GPRS デタッチ処理が完了する前に、MS が P-TMSI REALLOCATION COMMAND、 GMM STATUS、または GMM INFORMATION メッセージを受信した場合には、そのメッセージは無視して GPRS デタッチ処理

を継続すること。

- GPRS デタッチ処理が完了する前に、MS が AUTHENTICATION AND CIPHERING REQUEST または IDENTITY REQUEST メッセージを受信した場合には、MS はそれに対して 4.7.7 節および 4.7.8 節に記載さ

れたとおりに応答すること。

e) 同一 RA 内でのセルの変更（GSM のみ）

DETACH ACCEPT メッセージを受信する前に、同一 RA 内でのセルの変更が発生した場合には、デタッチ処

理が完了する前にセル更新処理を実行すること。

f) 新しい RA 内のセルへの移動

DETACH ACCEPT メッセージを受信する前に、新しい RA 内のセルへ移動した場合には、GPRS デタッチ処

理を一度中断し、RA 更新処理が正常に完了した後に再度開始すること。

MS Network

DETACH REQUESTStart T3321

DETACH ACCEPTStop T3321

or at MS power switch off

DETACH REQUEST

図図図図 4.7.4/1 TS 24.008: MS が開始したが開始したが開始したが開始した GPRS デタッチデタッチデタッチデタッチ処理処理処理処理

4.7.4.2 Network initiated GPRS detach procedure （ネットワークが開始した GPRSデタッチ処理）

4.7.4.2.1 Network initiated GPRS detach procedure initiation （ネットワークが開始した GPRSデタッチ処理）

ネットワークは DETACH REQUEST メッセージを MS に送信して GPRS デタッチ処理を開始する。DETACH REQUEST メッセージには、必ず detach type IE が含まれていること。さらに、ネットワークはデタッチを要求する理由

を明示するために、理由 IE をメッセージ内に入れることもできる。ネットワークはタイマ T3322 を起動すること。detach type IE が"re-attach not required" または "re-attach required"であった場合には、ネットワークは PDP コンテキストをデ

アクティブにして、もしあれば（1 つまたは複数の）論理的リンクをデアクティブにして、ステートを GMM-DEREGISTERED-INITIATED に変更すること。

4.7.4.2.2 Network initiated GPRS detach procedure completion by the MS （ネットワークが開始した GPRSデタッチ処理を MSが完了）

MS が DETACH REQUEST メッセージを受信し、detach type IE が"re-attach not required"または "re-attach required"を示していた場合には、MS は PDP コンテキストをデアクティブにし、もしあれば（1 つまたは複数の）論理的リンクを

デアクティブにすること。MS はネットワークに DETACH ACCEPT メッセージを送信し、ステートを GMM-

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 117

DEREGISTERED に変更すること。MS は GPRS デタッチ処理完了後、ネットワークから detach type IE 内で通知され

たならば GPRS アタッチ処理を開始すること。

MS オペレーションモードが A または B、ネットワークオペレーションモード I で運用されている GPRS MS が、

DETACH REQUEST メッセージ内でデタッチタイプ"re-attach required" または "re-attach not required"を通知され、か

つ理由コードがなかった場合には、ネットワーク内で GPRS サービスだけデタッチされる。

DETACH REQUEST メッセージを受信時、detach type IE が"IMSI detach"であった場合には、MS は PDP コンテキス

トをデアクティブにしてはならない。MS のオペレーションモード A／B、ネットワークオペレーションモード I で運用され

ている MS は、ネットワークに DETACH ACCEPT メッセージを送信することができる。そして複合 RA 更新処理を実

行して非 GPRS サービスに再アタッチして、Update type IE"combined RA/LA updating with IMSI attach"のROUTING AREA UPDATE REQUEST メッセージを送信すること。MS がオペレーションモード C で運用されている

場合、または MS がネットワークオペレーションモード II／III 内で MS オペレーションモード A／B で運用されている

場合には、必ずネットワークに DETACH ACCEPT メッセージを送信すること。

detach type IE が"IMSI detach"または"re-attach required"の場合には、MS は理由コードを受信した場合にはそれを

無視すること。

detach type IE の値が"re-attach required" または"re-attach not required"で、かつ MS が GPRS と非 GPRS サービス

にアタッチされており、かつネットワークがネットワークオペレーションモード I で運用されている場合には、MS 内でタ

イマ T3212 がまだ起動していなかったならば、タイマ T3212 をその初期値にセットして再開すること。

detach type IE が"re-attach required"の場合には、MS は新たなアタッチ処理を実行すること。MS はまた PDP コンテ

キストをアクティブにして、前回のアクティブ PDP コンテキストを置換すること。

注: 特定のケースでは、ユーザ情報が要求され、MS が PDP コンテキストを自動的にアクティブにできない

場合もある。

detach type IE が"re-attach not required"のときは、受信した理由コードに従って、MS は以下のアクションをとること。

# 2 (IMSI unknown in HLR) （HLR 内で未知の IMSI）

MS は更新ステータスを U3 ROAMING NOT ALLOWED にセットし、TMSI, LAI 、暗号鍵シーケンス番号を

全て削除すること。新しい MM ステートは MM IDLE。電源が切断されるか SIM カードが抜かれるまで、SIMカードは非 GPRS サービスについて無効とみなすこと。

MS オペレーションモード A/B で運用されている GPRS MS は、ネットワーク内でまだ GPRS サービス用に

ISMI がアタッチされている。



MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED にセットし（そして 4.1.3.2 節に従ってその

値を保存し）、P-TMSI, P-TMSI 署名、RAI、そして GPRS 暗号鍵シーケンス番号を全て削除すること。新しい

GMM ステートは GMM-DEREGISTERED。電源が切断されるか SIM カードが抜かれるまで、SIM カードは

GPRS サービスについて無効とみなすこと。

MS オペレーションモード A/B で運用される GPRS MS は、更新ステータスを U3 ROAMING NOT ALLOWED にセットし、さらに TMSI, LAI、暗号鍵シーケンス番号を全て削除すること。新しい MM ステート

は MM idle。電源が切断されるか SIM カードが抜かれるまで、SIM カードは非 GPRS サービスについて無効

とみなすこと。

# 7 (GPRS service not allowed) （GPRS サービス不許可）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED にセットし（そして 4.1.3.2 節に従ってその

値を保存し）、P-TMSI, P-TMSI 署名、RAI、そして GPRS 暗号鍵シーケンス番号を全て削除すること。電源が

切断されるか SIM カードが抜かれるまで、SIM カードは GPRS サービスについて無効とみなすこと。新しいス

テートは GMM-DEREGISTERED。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 118

MS オペレーションモード A/B、ネットワークオペレーションモード I で運用される GPRS MS は、ネットワーク内

でまだ CS サービス用に IMSI がアタッチされている。

# 8 (GPRS service and non-GPRS service not allowed)（GPRS サービスと非 GRRS サービス非許容）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に、更新ステータスを U3 ROAMING NOT ALLOWED にセットすること（そして 4.1.3.2 節の記載に従ってそれを保存すること）。さらに、P-TMSI, P-TMSI 署名, TMSI, RAI, LAI, 暗号鍵シーケンス番号、そして GPRS 暗号鍵シーケンス番号を全て削除し、電

源が切断されるか SIM カードが抜かれるまで、SIM カードは GPRS サービスと非 GPRS サービスについて無

効とみなすこと。

# 11 (PLMN not allowed)（PLMN 非許容）

# 12 (Location area not allowed)（LA 非許容）

# 13 (Roaming not allowed in this location area)（本 LA 内でのローミング禁止）

MS は RAI または LAI, P-TMSI, P-TMSI 署名、そして GPRS 暗号鍵シーケンス番号を全て削除し、GPRS 更

新ステータスを GU3 ROAMING NOT ALLOWED にセットすること（そして 4.1.3.2 節の記載に従ってそれを

保存すること）。

MS オペレーションモード A/B で運用されている GPRS MS は、更新ステータスを U3 ROAMING NOT ALLOWED にセットした上で、TMSI, LAI 、暗号鍵シーケンス番号を全て削除すること。新しい MM ステート

は MM IDLE。

MS は LAI または PLMN 識別子を、適切な禁止リスト（理由値#11 の場合は the "forbidden PLMN list"、理由

値#12 の場合は"forbidden location areas for regional provision of service"のリスト、理由値#13 の場合は

"forbidden location areas for roaming"のリスト）内に保存すること。理由値#11 または#13 を受信した場合には、

MS はセル選択の代わりに PLMN 選択を実行すること。

その他の理由値によって、更新ステータスが影響を受けてはならない。これ以上詳細は MS の動作は、実装に委ね

る。

4.7.4.2.3 Network initiated GPRS detouch procedure completion by the network （ネットワークが開始した GPRSデタッチ処理をネットワーク側で完了）

ネットワークは DETACH ACCEPT メッセージを受信したならば、タイマ T3322 を停止させ、ステートを GMM-DEREGISTERED に変更すること。

4.7.4.2.4 Abnormal cases on the network side （異常なケース、ネットワーク側）


a) T3322 タイムアウト

タイマ満了第 1 回目には、ネットワークは DETACH REQUEST メッセージを再送し、タイマ T3322 を起動させ

る。この再送は 4 回まで繰り返される。つまり、タイマ T3322 が 5 回目に満了したならば、GPRS デタッチ処理

を中断し、ネットワークはステートを GMM-DEREGISTERED に変更すること。

b) 下位レイヤの失敗

GPRS デタッチ処理は中断され、ネットワークはステートを GMM-DEREGISTERED に変更する。

c) GPRS デタッチ処理のバッティング

ネットワークが開始した GPRS デタッチ処理が完了する前に、"switching off"を通知する DETACH REQUESTメッセージをネットワークが受信した場合には、双方の処理が完了したものとみなすこと。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 119

ネットワークが開始した GPRS デタッチ処理が完了する前に、"switching off"なしの DETACH REQUEST メッ

セージをネットワークが受信した場合には、ネットワークは MS に DETACH ACCEPT メッセージを送信するこ

と。

d) GPRS デタッチ処理と GPRS アタッチ処理のバッティング

ネットワークが開始したデタッチタイプ're-attach not required' の GPRS デタッチ処理が完了する前に、

ATTACH REQUEST メッセージをネットワークが受信した場合には、ネットワークは ATTACH REQUEST メッ

セージを無視すること。DETACH REQUEST メッセージ内で送信された detach type IE の値が、"re-attach required"を示していた場合には、デタッチ処理を中断し、PDP コンテキストが削除された後に GPRS アタッチ

処理を進行させること。DETACH REQUEST メッセージ内で送信された detach type IE の値が、"IMSI detach"であった場合には、デタッチ処理を中断し、GPRS アタッチ処理を進行させること。

e) GPRS デタッチ処理と RA 更新処理のバッティング

GPRS デタッチがデタッチタイプ"re-attach required" または"re-attach not required"を含む場合

ネットワークが開始した GPRS デタッチ処理が完了する前に、ROUTING AREA UPDATE REQUEST メッセ

ージをネットワークが受信した場合には、デタッチ処理を進行させること。つまり、ROUTING AREA UPDATE REQUEST メッセージは無視すること。

GPRS デタッチがデタッチタイプ"IMSI detach"を含む場合

ネットワークが開始した GPRS デタッチ処理が完了する前に、ROUTING AREA UPDATE REQUEST メッセ

ージをネットワークが受信した場合には、ネットワークはデタッチ処理を中断し、タイマ T3322 を停止させ、RA更新処理を進行させること。

f) GPRS デタッチ処理とサービスリクエスト処理のバッティング

ネットワークが開始した GPRS デタッチ処理が完了する前に、SERVICE REQUEST メッセージをネットワーク

が受信した場合には、ネットワークは SERVICE REQUEST メッセージを無視すること。

MS Network

DETACH REQUESTStart T3322

DETACH ACCEPTStop T3322

図図図図 4.7.4/2 TS 24.008: ネットワークが開始したネットワークが開始したネットワークが開始したネットワークが開始した GPRS デタッチ処理デタッチ処理デタッチ処理デタッチ処理

4.7.5 Routing area updating procedure（RA更新処理）本処理は以下の目的で使用される。

- ネットワーク内の MS の実質的な RA 登録の登録を更新するための、通常の RA 更新。本処理は、ネットワー

クがネットワークオペレーションモード II ／ III で運用されている場合には、MS オペレーションモード C にある

GPRS MS と、GPRS と非 GPRS サービスに IMSI アタッチされているモード A/B の GPRS MS が使用する。

- ネットワーク内の MS の実質的な RA と LA の登録を更新するための、複合 RA 更新。本処理は、ネットワー

クがネットワークオペレーションモード I で運用されているネットワーク内で、GPRS および非 GPRS サービス

用に IMSI がアタッチされている、MS オペレーションモード A/B にある GPRS MS が使用する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 120

- 定期的 RA 更新。本処理は、ネットワークオペレーションモードに関係なく、MS オペレーションモード C で運用

されている GPRS MS と、GPRS／非 GPRS サービス用に IMSI がアタッチされている MS オペレーションモー

ド A/B で運用されている GPRS MS が使用する。

- MS が GPRS サービス用に IMSI アタッチされている場合の、非 GPRS サービス用の IMSI アタッチ。本処理

は、ネットワークがネットワークオペレーションモード I で運用されている場合に、MS オペレーションモード A/Bで運用されている GPRS MS が使用する。

- GSM では、個別モードを離れた後に、RR サブレイヤが再開エラーを通知したときに、GPRS サービスを再開

する。GSM 04.18 参照。

- UMTS→GSM、GSM→UMTS へのシステム間変更。4.7.1.7 節参照。

4.7.5.1 節では、RA だけを更新する RA 更新処理について説明する。RA と LA を両方更新する、複合 RA 更新処理

については 4.7.5.2 節で説明する。

RA 更新処理は常に MS が開始する。MS がステート GMM-REGISTERED にある場合のみ、処理を起動できる。

RA 更新試行が連続して拒否される回数を制限するために、RA 更新試行カウンタが導入される。RA 更新試行カウ

ンタは、4.7.5.1.5 節に規定されるように漸増させること。RA 更新試行カウンタの値に応じて、特定のアクションが実

行される。RA 更新試行カウンタがリセットされるのは以下の場合である。

- GPRS アタッチ処理が正常完了した場合

- RA 更新処理が正常完了した場合

さらに、MS がサブステート ATTEMPTING-TO-UPDATE にある場合には、

- 新しい RA に入った場合

- タイマ T3302 が満了した場合

- 登録機能によって要求された場合

モバイル装置は、"forbidden location areas for regional provision of service"のリストと同様に、"forbidden location areas for roaming"のリストを持つこと。これらのリストの取り扱いについては、4.4.1 節で説明する。

GSM では、RA 更新処理中には MS 内のユーザデータの送信はサスペンドすること。ユーザデータの受信は可能。

新しい P-TMSI が割当てられた場合には、RA 更新処理中にはネットワーク内でのユーザデータ送信はサスペンドす

ること。

UMTS では、RA 更新処理中でも MS 内のユーザデータの送受信はサスペンドしてはならない。ネットワーク側でも、

RA 更新処理中にユーザデータの送信をサスペンドしてはならない。

4.7.5.1 Normal and periodic routing area updating procedure （通常および定期的 RA更新処理）

定期的 RA 更新処理は、MS が利用可能な状態にあることをネットワークに定期的に通知するために使用される。

ROUTING AREA UPDATE REQUEST メッセージ内の更新タイプ IE の値は、"periodic updating"を通知すること。

MS 内では処理はタイマ T3312 によって制御される。タイマ T3312 満了時に、定期的 RA 更新処理が開始される。タ

イマ T3312 の開始とリセットについては、4.7.2.2 節で説明される。

GSM では、MS がステート GMM-REGISTERED にある RA の変更を検出した場合、または MS が GPRS 再開の実

行を決定した場合に、通常の RA 更新処理が開始される。MS が RA の境界をまたいだときに、MS が初に送信す

るデータは常に ROUTING AREA UPDATE REQUEST メッセージであること。RAI はブロードキャストチャネル上で

ブロードキャストされる。

UMTS では、MS がステート GMM-REGISTERED にある RA の変更を検出した場合に、通常の RA 更新処理が開

始される。MS が RA の境界をまたいだときに、MS が初に送信する GMM メッセージは常に ROUTING AREA UPDATE REQUEST メッセージであること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 121

通常の RA 更新は、他の全ての GMM 処理を中断させること。通常の RA 更新処理が正常終了後、中断された

GMM 処理を繰り返すことができる。メッセージ内で示される更新タイプ IE の値は"normal routing area updating"であ

ること。

4.7.5.1.1 Normal and periodic routing area updating procedure initiation （通常 RA更新処理と定期的 RA更新処理の開始）

通常 RA 更新処理を開始するために、MS はネットワークに ROUTING AREA UPDATE REQUEST メッセージを送

信し、タイマ T3330 を起動し、ステートを GMM-ROUTING-AREA-UPDATING-INITIATED に変更させる。

ROUTING AREA UPDATE REQUEST には、前の ATTACH ACCEPT または ROUTING AREA UPDATE ACCEPT メッセージ内で受信した P-TMSI 署名が含まれること。

UMTS では、MS が通常 RA 更新処理後に RR コネクションの確立を延期を希望した場合には、MS は follow-on request pending indicator を ON にセットすることができる。

4.7.5.1.2 GMM Common procedure initiation（GMM共通処理の開始）

ネットワークは GMM 共通処理（例えば GMM 認証や暗号化処理など）を開始することができる。

4.7.5.1.3 Normal and periodic routing area updating procedure accepted by the network （通常 RA更新および定期的 RA更新処理がネットワークによって受理された場合）

ネットワークは RA 更新要求を受理したならば、ROUTING AREA UPDATE ACCEPT メッセージを MS に送信する

こと。ネットワークは新しい P-TMSI および／または新しい P-TMSI 署名を MS に割当てること。既に新しい P-TMSI および／または新しい P-TMSI 署名が MS に割当てられている場合には、これ（ら）を RAI といっしょに

ROUTING AREA UPDATE ACCEPT メッセージ内に入れて送信すること。

GSM では、ネットワークが Cell Notification をサポートできることを通知するために、Cell Notification IE を

ROUTING AREA UPDATE ACCEPT メッセージに入れること。

ネットワークは、ステートを GMM-COMMON-PROCEDURE-INITIATED に変更し、4.7.6 節に説明したようにタイマ

T3350 の監視を開始すること。

ROUTING AREA UPDATE ACCEPT メッセージ内の LAI または PLMN 識別子が、いずれかの「禁止」

（"forbidden" ）リストのメンバである場合には、それらのエントリを削除すること。

UMTS では、MS が ROUTING AREA UPDATE REQUEST メッセージ内で follow-on request pending を通知したな

らば、ネットワークは RR コネクションを延長すること。MS からの通知がない場合でも、ネットワークは RR コネクショ

ンを延長することができる。

MS は ROUTING AREA UPDATE ACCEPT メッセージを受信したならば、受信した RAI を保存し、タイマ T3330 を

停止させ、RA 更新試行カウンタをリセットし、GPRS 更新ステータスを GU1 UPDATED にセットすること。メッセージ

内に P-TMSI が含まれていた場合には、MS はその P-TMSI を GPRS サービス用の新しいテンポラリ識別子として使

用し、新しい P-TMSI を保存すること。ネットワークが ROUTING AREA UPDATING ACCEPT メッセージ内で P-TMSI を通知しなかった場合には、旧 P-TMSI をキープすること。さらに、MS が ROUTING AREA UPDATING ACCEPT メッセージ内で P-TMSI 署名を受信した場合には、MS は P-TMSI 署名を保存すること。メッセージ内に P-TMSI 署名が含まれていなかった場合には、旧 P-TMSI 署名が利用可能ならば削除すること。

GSM では、ROUTING AREA UPDATE ACCEPT メッセージ内に Cell Notification IE が含まれていた場合には、

MS は LLC NULL フレームの使用を開始してセル更新を実行すること。

ROUTING AREA UPDATE ACCEPT メッセージに以下の情報が含まれていた場合には、A ROUTING AREA UPDATE COMPLETE メッセージをネットワークに返すこと。

- P-TMSI および／または

- Receive N-PDU Number（04.65 [78] および TS 25.322 参照）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 122

この場合、MS 内で有効な Receive N-PDU Number の値は、ROUTING AREA UPDATE COMPLETE メッセージ内

に入れること。

注: UMTS では、リソースが既にネットワークによって開放されるか、あるいは上位レイヤのメッセージ

（ACTIVATE PDP CONTEXT REQUEST など）が既存 PS シグナリングコネクション経由でネットワーク

に送信された場合には、RA 更新処理後に MS がサービスリクエスト処理を開始してアクティブ PDP 用

のリソース予約を要求することができる。

UMTS ではその後、MS が follow-on request pending を通知し、CM application request pending を通知していたなら

ば、MS は適切なメッセージ（例えば ACTIVATE PDP CONTEXT REQUEST）をネットワークに送信すること。

4.7.5.1.4 Normal and periodic routing area updating procedure not accepted by the network （通常 RA更新処理と定期的 RA更新処理をネットワークが拒否した場合）

RA 更新を受容できない場合には、ネットワークは MS に ROUTING AREA UPDATE REJECT メッセージを送信す

る。ROUTING AREA UPDATE REJECT メッセージを受信した MS は、タイマ T3330 を停止させる。受信した拒否理

由に応じて、MS は異なるアクションをとること。


# 6 (Illegal ME) （不正 ME）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED にセットし（そしてその値を 4.1.3.2 節に従

って保存し）、ステート GMM-DEREGISTERED に入る。さらに、P-TMSI, P-TMSI 署名, RAI、そして GPRS 暗号鍵シーケンス番号を全て削除し、電源が切断されるか SIM カードが抜かれるまで、SIM カードは GPRS サ

ービスについて無効とみなすこと。

MM 処理の過程で MS に IMSI がアタッチされている場合には、さらに MS は更新ステータスを U3 ROAMING NOT ALLOWED にセットし、TMSI, LAI 、暗号鍵シーケンス番号を全て削除すること。新しい

MM ステートは MM IDLE。電源が切断されるか SIM カードが抜かれるまで、SIM カードは非 GPRS サービ

スについて無効とみなすこと。

# 7 (GPRS service not allowed) （GPRS サービス非許容）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED にセットし (そしてその値を 4.1.3.2 節に従

って保存し)、P-TMSI, P-TMSI 署名, RAI 、GPRS 暗号鍵シーケンス番号を全て削除すること。電源が切断さ

れるか SIM カードが抜かれるまで、SIM カードは GPRS サービスについて無効とみなすこと。新しいステート

は GMM-DEREGISTERED。

# 9 (MS identity cannot be derived by the network)（ネットワークが MS のアイデンティティを識別不能）

MS は GPRS 更新ステータスを GU2 NOT UPDATED にセットし（そしてその値を 4.1.3.2 節に従って保存し）、

ステート GMM-DEREGISTERED に入る。そして P-TMSI, P-TMSI 署名, RAI 、GPRS 暗号鍵シーケンス番号

を全て削除すること。その後、MS は自動的に GPRS アタッチ処理を開始することができる。

# 10 (Implicitly detached) （暗黙的デタッチ）

MS はステートを GMM-DEREGISTERED.NORMAL-SERVICE に変更すること。次に MS は新しいアタッチ

処理を実行すること。また MS は PDP コンテキストをアクティブにして、今までアクティブだった PDP コンテキ

ストを置換すること。

注: 特定のケースでは、ユーザ情報を要求することもできる。この場合 MS は自動的に PDP コンテキストを

アクティブにすることはできない。



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 123

# 13 (Roaming not allowed in this location area)（その LA 内でローミング不許可）

- MS は RAI, P-TMSI, P-TMSI 署名、GPRS 暗号鍵シーケンス番号を全て削除し、GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に変更し（そしてその値を 4.1.3.2 節に従って保存し）、ステート GMM-DEREGISTERED に入る。

MM 処理の過程で MS に IMSI がアタッチされている場合には、さらに MS は更新ステータスを U3 ROAMING NOT ALLOWED にセットし、TMSI, LAI 、暗号鍵シーケンス番号を全て削除し、LA 更新試行カ

ウンタをリセットすること。新しい MM ステートは MM IDLE。

MS は LAI または PLMN 識別子を適切な禁止リスト（理由値#11 の場合"forbidden PLMN list"、理由値#12の場合"forbidden location areas for regional provision of service"のリスト、理由値#13 の場合"forbidden location areas for roaming"のリスト内）に保存すること。理由値#11 または#13 を受信したならば、MS はセル

選択の代わりに PLMN 選択処理を実行すること。

これ以外の値は異常なケースと見なされる。これらのケースにおける MS の動作仕様については、4.7.5.1.5 節で説

明する。


異常なケースは以下のように分類される。

a) Access barred because of access class control（アクセスクラス制御によりアクセス禁止）

RA 更新処理を開始してはならない。MS は現行のサービスセルに留まり、通常のセル選択プロセスを適用す

ること。必要ならば処理は可能になり次第、つまり禁止ステートから抜けたり、セルが変更されたならば、でき

るだけ早く開始すること。

b) ROUTING AREA UPDATE ACCEPT または ROUTING AREA UPDATE REJECT メッセージを受信する前

に下位レイヤでエラーが発生

処理を中断すること。MS は下記の手順を進行させること。


処理は 4 回再開される。つまり、タイマ T3330 が 4 回目に満了したならば、MS は処理を中断すること。MS は

下記の手順を進行させること。

d) ROUTING AREA UPDATE REJECT、4.7.5.1.4 節で取り扱われない理由値

MS は下記の手順を進行させること。

e) MS が RA の境界をまたいだならば、MS はステート GMM-ROUTING-AREA-UPDATE-INITIATED に入り、

RA 更新処理は中断され、直ちに再初期化される。MS は GPRS 更新ステータスを GU2 NOT UPDATED に

セットすること。

f) GSM では、MS がステート GMM-ROUTING-AREA-UPDATE-INITIATED にあるときに同一 RA 内でセル

変更が起きたならば、RA 更新処理が完了する前にセル更新処理を実行する。

g) RA 更新とデタッチ処理のバッティング

GPRS デタッチが、デタッチタイプ"re-attach required" または"re-attach not required"を含む場合には、

RA 更新処理が完了する前に MS が DETACH REQUEST メッセージを受信した場合、RA 更新処理は中断さ

れ、GPRS デタッチ処理を進行させること。

GPRS デタッチが、デタッチタイプ"IMSI detach"を含む場合には、

RA 更新処理が完了する前に MS が DETACH REQUEST メッセージを受信した場合、RA 更新処理を進行さ

せること。つまり、DETACH REQUEST メッセージは無視される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 124

h) RA 更新と P-TMSI 再配置処理のバッティング

RA 更新処理が完了する前に MS が P-TMSI REALLOCATION REQUEST メッセージを受信した場合、P-TMSI 再割当処理は中断され、RA 更新処理を進行させること。

ケース b、c、および d では、MS は以下のように処理を進めること。

タイマ T3330 が起動している場合には停止させること。RA 更新試行カウンタを漸増させること。

RA 更新試行カウンタの値が 5 よりも小さく、かつ保存された RAI が現行サービスセルの RAI と等しく、かつ

GMM 更新ステータスが GU1 UPDATED と等しい場合には、

- MS は GMM 更新ステータスを GU1 UPDATED にキープし、ステートを GMM-REGISTERED.NORMAL-SERVICE に変更させること。MS はタイマ T3311 を起動すること。タイマ T3311 満了時に、RA 更新処理

は再度トリガされる。

RA 更新試行カウンタの値が 5 以上で、かつ保存された RAI が現行サービスセルの RAI と異なるかまたは

GMM 更新ステータスが GU1 UPDATED と異なる場合には、

- MS はタイマ T3311 を起動し、GPRS 更新ステータスを GU2 NOT UPDATED にセットし、ステートを

GMM-REGISTERED.ATTEMPTING-TO-UPDATE に変更すること。

- RA 更新試行カウンタの値が 5 以上の場合には、

- MS はタイマ T3302 を起動し、GPRS 更新ステータスを GU2 NOT UPDATED にセットし、ステートを GMM-REGISTERED.ATTEMPTING-TO-UPDATE またはオプションとして GMM-REGISTERED.PLMN-SEARCHに変更させること(4.2.4.1.2 節参照)。

- UMTS では、ケース c では MS が PS シグナリングコネクションを開放し、ケース d ではネットワークが該当

MS 用の PS シグナリングコネクションを開放すること（TS 25.331 参照）。



a) MS から ROUTING AREA UPDATE COMPLETE メッセージを受信する前に、下位レイヤで失敗が発生し、P-TMSI および／または P-TMSI 署名が既に割当てられている場合には、ネットワークは処理を中断し、ネッ

トワークが旧 P-TMSI を無効と見なすことができるようになるまで（4.7.1.5 節参照）、旧新 TMSI と関連する P-TMSI 署名をどちらも有効と見なすこと。その間、MS が後続メッセージ内で旧 P-TMSI を使用しているならば、

ネットワークは識別処理とそれに続く P-TMSI 再割当処理を行うことができる。

注: オプションとして、旧新 TMSI によるページングが失敗した場合には、IMSI を使ったページングも可能。

IMSI を使用したページングにより、4.7.9.1 節に説明されるように MS は再割当される。

b) プロトコルエラー

ROUTING AREA UPDATE REQUEST メッセージ受信時にプロトコルエラーが発生した場合、ネットワークは

以下のいずれかの拒否理由値といっしょに ROUTING AREA UPDATE REJECT メッセージを返すこと。


#99: Information element non-existent or not implemented（存在しない IE、または実装されていない IE）

#100: Conditional IE error（条件的 IE のエラー）

#111: Protocol error, unspecified（プロトコルエラー、未特定）


タイマ T3350 の第一回目満了時、ネットワークは ROUTING AREA UPDATE ACCEPT メッセージを再送し、

タイマ T3350 をリセットして再開させること。再送は 4 回まで行われる。つまり、T3350 が 5 回目に満了した場

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 125

合、RA 更新処理は中断される。ネットワークが旧 P-TMSI を無効と判断できるようになるまで、旧新 P-TMSIおよび関連する P-TMSI 署名は両方有効と見なすこと（4.7.1.5 節参照）。この間、ネットワークは上記 a のケ

ースについて説明したアクションを取る。

MS Network

ROUTING AREA UPDATE REQUEST

If P-TMSI orTMSI allocated,or Receive N-PDUNumber needed

ROUTING AREA UPDATE ACCEPT

ROUTING AREA UPDATE COMPLETE

Stop T3330

Start T3330

Stop T3350

Start T3350

or

ROUTING AREA UPDATE REJECTStop T3330

ROUTING AREA UPDATE REQUESTStart T3330

If P-TMSI orTMSI allocated,or Receive N-PDUNumber needed

図図図図 4.7.5/1 TS 24.008: RA 更新処理と複合更新処理と複合更新処理と複合更新処理と複合 RA 更新処理更新処理更新処理更新処理

4.7.5.2 Combined routing area updating procedure（複合 RA更新処理）

複合 RA 更新処理の過程で、メッセージ ROUTING AREA UPDATE ACCEPT と ROUTING AREA UPDATE COMPLETE は、RA 更新と LA 更新のための情報を伝送する。

4.7.5.2.1 Combined routing area updating procedure initiation （複合 RA更新処理の開始）

複合 RA 更新処理は、MS オペレーションモード A/B で運用されている GPRS MS だけが開始することができる。MSがステート GMM-REGISTERED にあり、ネットワークががネットワークオペレーションモード I にある場合には、

- GPRS サービスと非 GPRS サービス用に IMSI がアタッチされている GPRS MS が、ステート GMM-REGISTERED と MM-IDLE にあるときに RA の更新を検出したとき

- GPRS サービス用に IMSI がアタッチされている GPRS MS が、非 GPRS サービス用 IMSI アタッチの実行を

希望したとき

- MS が非 GPRS サービスの間に LA を変更したならば、非 GPRS チャネル経由で非 GPRS サービスを送信し

た後

- MS が理由値#4 の CM SERVICE REJECT メッセージを受信した後（4.5.1.1 節参照）。このケースでは更新タ

イプ IE は"Combined RA/LA updating with IMSI attach"にセットすること。

GSM では、RA と LA の識別子は、ブロードキャストチャネル上でブロードキャストされる。複合 RA 更新は、全ての

進行中の GMM 処理を中断させること。中断された GMM 処理は、複合 RA 更新が正常完了した後に繰り返すこと。

RA 更新後、新しい RA 内の MS から初に送信されるメッセージは、常に ROUTING AREA UPDATE REQUESTメッセージであること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 126

UMTS では、RA と LA の識別子は、ブロードキャストチャネル上でブロードキャストされ、PS シグナリングコネクショ

ン経由で MS に送信される。複合 RA 更新処理は、全ての進行中の GMM 処理を中断させること。中断された

GMM 処理は、複合 RA 更新が正常完了した後に繰り返すこと。RA 更新後、新しい RA 内の MS から初に送信さ

れる GMM メッセージは、常に ROUTING AREA UPDATE REQUEST メッセージであること。

複合 RA 更新処理を開始するために、MS はネットワークに ROUTING AREA UPDATE REQUEST メッセージを送

信し、タイマ T3330 を起動し、ステートを GMM-ROUTING-UPDATING-INITIATED および MM LOCATION UPDATING PENDING に変更すること。メッセージ内の更新タイプ IE の値は、"combined RA/LA updating"であるこ

と。RA の登録を更新するための近の試行として MM 固有の処理が実行された場合には、ROUTING AREA UPDATE REQUEST メッセージ内の更新タイプ IE の値は"combined RA/LA updating with IMSI attach"であること。

さらに、有効な TMSI が利用可能でない場合には、MS は TMSI status IE を入れること。

MS オペレーションモード A/B で運用されている GPRS MS が進行中の CS トランザクションを持っている場合、もし

MS が CS トランザクションの間に RA を変更し、かつネットワークがネットワークオペレーションモード I で運用されて

いたならば、CS トランザクションが開放された後に複合 RA 更新処理を開始すること。

MS オペレーションモード A で運用されている GPRS MS は、CS トランザクションの間に GPRS アタッチが実行され、

かつネットワークがネットワークオペレーションモード I で運用されていたならば、CS トランザクションが開放された後

に IMSI アタッチ処理といっしょに複合 RA 更新処理を開始すること。

MS オペレーションモード A で運用されている GPRS MS は、CS トランザクション進行中は通常の RA 更新処理を実

行すること。

UMTS では、MS が UMTS エリア内でサービスを受けているときに、通常 RA 更新処理後まで RR コネクション確立

の延期を希望するならば、follow-on request pending indicator を ON にセットすること。

4.7.5.2.2 GMM Common procedure initiation（GMM共通処理の開始）

ネットワークは、GMM 共通処理（例えば GMM 認証や暗号化処理など）を開始することができる。

4.7.5.2.3 Combined routing area updating procedure accepted by the network （複合 RA更新処理がネットワークによって受理された場合）

ROUTING AREA UPDATE ACCEPT メッセージ内で受信した update result IE の値に応じて、2 つのケースに分けら

れる。

Case 1) update result IE の値が"combined RA/LA"の場合：RA と LA 更新処理が正常完了

Case 2) update result IE の値が"RA only"の場合：RA 更新処理は正常終了したが、LA 更新は成功しなかった

ROUTING AREA UPDATE ACCEPT メッセージが含まれている場合には、ネットワークに ROUTING AREA UPDATE COMPLETE メッセージを返すこと。

- P-TMSI および／または TMSI および／または

- Receive N-PDU Number (04.65 [78] および TS 25.322 参照)

後者のケースでは、MS 内で有効な Receive N-PDU Number を、ROUTING AREA UPDATE COMPLETE メッセー

ジ内に入れること。

UMTS では、MS が ROUTING AREA UPDATE REQUEST メッセージ内で follow-on request pending を通知した場

合には、ネットワークは RR コネクションを延長することができる。MS から特に通知がない場合にも、ネットワークは

RR コネクションを延長することができる。

4.7.5.2.3.1 Combined routing area updating successful（複合 RA更新の正常終了）

4.7.5.1.3 節で規定した通常 RA 更新の説明を以下に述べる。さらに、以下の説明は LA 更新にも適用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 127

ROUTING AREA UPDATE ACCEPT メッセージ受信時の処理は、受信した update result IE の値に応じて、以下の

ように規定される。

TMSI 再配置を、複合 RA 更新処理の一部にすることも可能。割当てられた TMSI は、次に LAI（location area identification）といっしょに ROUTING AREA UPDATE ACCEPT メッセージに入れられる。この場合、ネットワークは

ステートを GMM-COMMON-PROCEDURE-INITIATED に変更し、4.7.6 節に記載されたとおりにタイマ T3350 を起

動させること。

MS は、ROUTING AREA UPDATE ACCEPT メッセージを受信したならば、受信した LAI を保存し、タイマ T3330 を

停止させ、ステート MM IDLE に入り、位置登録更新試行カウンタをリセットし、更新ステータスを U1 UPDATED に

セットすること。ROUTING AREA UPDATE ACCEPT メッセージ内に IMSI が含まれていた場合には、MS には

TMSI は割当てられないので、全ての TMSI を削除すること。ROUTING AREA UPDATE ACCEPT メッセージに

TMSI が含まれていた場合には、MS はこの TMSI を新しいテンポラリ識別子として使用すること。MS は旧 TMSI を削除し、新しい TMSI を保存すること。この場合、ROUTING AREA UPDATE COMPLETE メッセージがネットワーク

に返される。ROUTING AREA UPDATE ACCEPT メッセージ内に TMSI も IMSI も含まれていなかった場合には、

利用可能ならば旧 TMSI をキープすること。

LA 更新処理をトリガするために使用された全てのタイマ（T3211, T3212 など）は、もし起動しているならば停止する

こと。

ネットワークは ROUTING AREA UPDATE COMPLETE メッセージを受信したら、タイマ T3350 を停止させ、ステート

を GMM-REGISTERED に変更し、新しい TMSI を有効と見なすこと。

4.7.5.2.3.2 Combined routing are updating successful for GPRS service only （GPRSサービスのみ複合 RA更新処理が正常完了）

4.7.5.1.3 節に規定された通常 RA 行進処理について、以下に説明する。さらに、以下の説明は LA 更新にも適用さ

れる。

MS は ROUTING AREA UPDATE ACCEPT メッセージを受信したならば、その拒否理由に応じて以下のいずれか

のアクションを取る。

#2 (IMSI unknown in HLR) （HLR 内で未知の IMSI）

MS は更新ステータスを U3 ROAMING NOT ALLOWED にセットし、TMSI, LAI 、暗号鍵シーケンス番号を全て削

除すること。新しい MM ステートは MM IDLE。MS の電源が切断されるまで、または SIM カードが抜かれるまで、

SIM カードは非 GPRS サービスについて無効と見なすこと。

#16 (MSC temporarily not reachable)（MSC が一時的に到達不能）

#17 (Network failure)（ネットワークエラー）

#22 (Congestion)（輻輳）

MS はステートを GMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM に変更すること。タイマ T3330 が

起動している場合は停止すること。RA 更新試行カウンタの値を漸増させること。RA 更新試行カウンタの値が

5 未満で、かつ保存された RAI が現行のサービスセルの RAI と等しく、かつ GMM 更新ステータスが GU1 UPDATED に等しい場合には、

- MS は GMM 更新ステータスを GU1 UPDATED のままキープし、ステートを GMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM に変更すること。MS はタイマ T3311 を起動すること。タ

イマ満了した時に、"combined RA/LA updating with IMSI attach"を通知する複合 TA 更新処理が再度トリ

ガされる。

RA 更新試行カウンタの値が 5 以上の場合：

- MS はタイマ T3302 を起動させ、ステートを GMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM に変

更すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 128

- MS オペレーションモード A で運用されている GPRS MS は、適切な MM 固有の処理を進めること。MS オ

ペレーションモード B で運用されている GPRS MS は、適切な MM 固有の処理を進めることができる。複合 GMM 処理が成功しない間、また新しい RA に入らない間は、MM サブレイヤはネットワークオペレ

ーションモード II で動作すること。新しい MM ステートは IDLE。

上記以外の値は異常なケースと見なされ、複合 RA 更新処理は GPRS と非 GPRS サービス双方について失敗した

ものと見なされる。これらのケースにおける MS の動作は、4.7.5.2.5 節に規定される。

4.7.5.2.4 Combined routing area updating not accepted by the network （複合 RA更新がネットワークによって受理されなかった場合）

ネットワークは、複合 RA 更新を受理できない場合には、ROUTING AREA UPDATE REJECT メッセージを MS に送

信する。MS は ROUTING AREA UPDATE REJECT メッセージを受信したならば、タイマ T3330 を停止させ、ステー

ト MM IDLE に入る。MS は受信した拒否理由値に応じて、異なるアクションを取ること。



# 8 (GPRS service and non GPRS service not allowed)（GPRS サービスと非 GPRS サービスが非許容）

MS は、GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に、更新ステータスを U3 ROAMING NOT ALLOWED にセットし（そしてこれらの値を 4.1.3.2 節の記載に従って保存し）、ステート GMM-DEREGISTERED に入ること。さらに、MS は P-TMSI, P-TMSI 署名, TMSI, RAI, LAI, 暗号鍵シーケンス番号、 GPRS 暗号鍵シーケンス番号を全て削除し、MS の電源が切断されるまで、または SIM カードが抜かれるま

で、SIM カードは GPRS サービスと非 GPRS サービスについて無効と見なすこと。

# 7 (GPRS service not allowed) （GPRS サービス非許容）

MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED にセットし（そしてこれらの値を 4.1.3.2 節

の記載に従って保存し）、P-TMSI, P-TMSI 署名, RAI 、GPRS 暗号鍵シーケンス番号を全て削除すること。

MS の電源が切断されるまで、または SIM カードが抜かれるまで、SIM カードは GPRS サービスと非 GPRSサービスについて無効と見なすこと。新しいステートは GMM-DEREGISTERED。MS 内でタイマ T3212 が未

だ起動していない場合には、タイマを初期値にセットして再開すること。

MS オペレーションモード A / B、ネットワークオペレーションモード I で運用される GPRS MS は、まだネットワ

ーク内で CS サービスについて IMSI がアタッチされている。

# 9 (MS identity cannot be derived by the network)（MS のアイデンティティをネットワークが確認できない）

MS は GPRS 更新ステータスを GU2 NOT UPDATED にセットし（そしてこれらの値を 4.1.3.2 節の記載に従っ

て保存し）、ステート GMM-DEREGISTERED に入り、P-TMSI, P-TMSI 署名, RAI 、GPRS 暗号鍵シーケンス

番号を全て削除すること。さらに、MS は自動的に GPRS アタッチ処理を開始することもできる。

MS オペレーションモード A / B、ネットワークオペレーションモード I で運用される GPRS MS は、まだネットワ

ーク内で CS サービスについて IMSI がアタッチされている。

# 10 (Implicitly detached) （非明示的にデタッチされた）

MS オペレーションモード A / B、ネットワークオペレーションモード I で運用される GPRS MS は、ネットワーク

内で GPRS サービスと CS サービスの双方について IMSI がデタッチされている

MS はステートを GMM-DEREGISTERED.NORMAL-SERVICE に変更すること。次に MS は新しいアタッチ

処理を実行すること。MS はまた、PDP コンテキストをアクティブにして、既存のアクティブ PDP コンテキストを

置換すること。

注: 特定のケースでは、ユーザ情報が要求されることもある。この場合、MS は PDP コンテキストを自動的

にアクティブにすることはできない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 129



# 13 (Roaming not allowed in this location area)（該当 LA 内でローミング不許可）

MS は、GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に、更新ステータスを U3 ROAMING NOT ALLOWED にセットし（そしてこれらの値を 4.1.3.2 節の記載に従って保存し）、ステート GMM-DEREGISTERED に入ること。さらに、P-TMSI, P-TMSI 署名, TMSI, RAI, LAI, 暗号鍵シーケンス番号 GPRS暗号鍵シーケンス番号を全て削除し、位置登録更新試行カウンタをリセットすること。

MS は LAI または PLMN 識別子を適切な禁止リスト（理由値#11 の場合"forbidden PLMN list"、理由値#12の場合"forbidden location areas for regional provision of service"のリスト、理由値#13 の場合"forbidden location areas for roaming"のリスト内）に保存すること。理由値#11 または#13 を受信したならば、MS はセル

選択の代わりに PLMN 選択処理を実行すること。

上記以外の値は異常なケースと見なされる。これらのケースにおける MS の動作は、4.7.5.2.5 節に規定される


4.7.5.1.5 節に規定される異常なケースは、以下のように修正される。

GPRS RA更新カウンタの値が 5 よりも小さいとき、MM ステートは MM LOCATION UPDATING PENDING のまま

である。

GPRS RA更新試行カウンタの値が 4.7.5.1.5 節の規定に従って漸増されるとき、次のアクションは（SIM カード上に

保存されている、現行サービスセル中の 1 つの）LAI と、RA 更新試行カウンタの値によって決まる。

- 更新ステータスが U1 UPDATED で、保存された LAI の値が現行サービスセル中の 1 つのセルの値と等しく、

かつ更新試行カウンタが 5 未満の場合には、MS は更新ステータスを U1 UPDATED のまま維持して、新しい

MM ステートは MM IDLE、サブステートは NORMAL SERVICE とする。

- 更新ステータスが U1 UPDATED 以外、または保存された LAI の値が現行サービスセル中の 1 つのセルの

値と異なり、または RA 更新試行カウンタの値が 5 以上の場合には、MS は SIM カード上に保存されている

LAI, TMSI, 暗号鍵シーケンス番号を全て削除し、更新ステータスを U2 NOT UPDATED にセットすること。新

しい MM ステートは MM IDLE、サブステートは ATTEMPTING TO UPDATE。


4.7.5.1.6 で規定される異常なケースが適用されるが、ケース a と c では、P-TMSI と P-TMSI 署名に加えて、後続メッ

セージ内で MS が新しい TMSI を使用するまでは、旧 TMSI が有効と見なされる点が異なる。

4.7.6 P-TMSI reallocation procedure（P-TMSI再配置処理） Packet-TMSI (P-TMSI)とは、GPRS サービス用のモバイル端末のテンポラリ識別子であり、無線インタフェースシグ

ナリング処理において端末を識別するために使用される。P-TMSI の構造は TS 23.003 [10]で規定される。P-TMSIは、RA 内においてのみ有効である。RA の外では、明確に端末を特定するために、P-TMSI は RAI（routing area identification）と組み合わせて使用される。

P-TMSI 再配置処理の目的は、機密を保持しながらアイデンティティを特定する手段を提供することにある。つまり、

ユーザとユーザの位置を悪者に特定されないように保護することにある（GSM 02.09 [5] および 03.20 [34]参照）。

通常、低限 RA が変更された時には P-TMSI 再配置が実行される（そのような選択はネットワークオペレータに委

ねられる）。

P-TMSI 再配置は、そのセッション内で定義されたユニークな処理によって実行される。本処理は、ステート GMM-REGISTERED にあるネットワークだけが開始することができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 130

P-TMSI は、アタッチ処理または RA 更新処理の中で非明示的に再配置することもできる。P-TMSI の非明示的再配

置は、関連する節の中で説明される。

注: 通常、P-TMSI 再配置処理は、他の GMM 処理（例えば RA 更新など）といっしょに実行される

（TS 29.002 [37]参照）。

4.7.6.1 P-TMSI reallocation initiation by the network （ネットワークによる P-TMSI再配置の開始）

ネットワークが P-TMSI 再配置処理を開始する際は、MS に P-TMSI REALLOCATION COMMAND メッセージを送

信して、タイマ T3350 を起動する。

P-TMSI REALLOCATION COMMAND メッセージには、ネットワークによって割当てられた P-TMSI, RAI 、そして

オプションとして P-TMSI 署名の新しいコンビネーションが含まれる。

ネットワークは P-TMSI 再配置処理の過程で、いかなるユーザデータも送信してはならない。

4.7.6.2 P-TMSI reallocation completion by the MS （MSによる P-TMSI再配置の完了）

P-TMSI REALLOCATION COMMAND メッセージを受信した MS は、RAI と P-TMSI を保存し、ネットワークに P-TMSI REALLOCATION COMPLETE メッセージを送信する。

P-TMSI REALLOCATION COMMAND メッセージ内に P-TMSI 署名が存在する場合には、MS は新しい P-TMSI署名を保存し、可能ならば旧 P-TMSI 署名を削除すること。P-TMSI REALLOCATION COMMAND メッセージ内に

P-TMSI 署名が存在しない場合には、利用可能ならば旧 P-TMSI 署名をキープすること。

4.7.6.3 P-TMSI reallocation completion by the network （ネットワークによる P-TMSI再配置処理の完了）

ネットワークは P-TMSI REALLOCATION COMPLETE メッセージを受信したならば、タイマ T3350 を停止させ、新し

い P-TMSI を有効と見なし、旧 P-TMSI を無効と見なすこと。

GSM では、GMM レイヤは LCC レイヤに対して、P-TMSI が変更されたことを通知すること（GSM 04.64 [76]参照）。




P-TMSI REALLOCATION COMPLETE メッセージを受信する前に下位レイヤの失敗を検出した場合には、

ネットワークが旧 P-TMSI を無効と見なすまで、旧新 P-TMSI は占領されているものとみなすこと（4.7.1.5 節参

照）。

この間、ネットワークは、

ネットワーク発トランザクションの場合には、ページング用の旧 P-TMSI をまず初に使用することができ

る。ページング試行回数は、実装によって決まる。MS からの応答があれば、ネットワークは P-TMSI 再配

置を再初期化することができる。ページング試行に対する応答がない場合には、ネットワークは新しい P-TMSI を使用することができる。ページング試行回数は、実装によって決まる。MS からの応答があれば、

ネットワークは新しい P-TMSI を有効と見なし、旧 P-TMSI を無効と見なすこと。ページング試行に対する

応答がない場合には、ネットワークはページング用に IMSI を使用することができる。ページング試行回数

は、実装によって決まる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 131

注: IMSI によるページングの結果、4.7.9.1 節に記載されたように、MS は再アタッチされる。

- MS が新 P-TMSI を使用したならば、それを有効と見なすこと（4.7.1.5 節参照）

- MS が旧新 P-TMSI を使用したならば、識別処理の後に新たな P-TMSI を実行することができる。

b) タイマ T3350 の満了

P-TMSI 再配置処理は、タイマ T3350 によって監視される。ネットワークは、タイマ T3350 の第 1 回満了時、タ

イマ T3350 をリセットして再開し、P-TMSI REALLOCATION COMMAND を再送すること。この再送は 4 下

位まで繰り返される。つまり、タイマ T3350 の第 5 回満了時、ネットワークは再配置処理を中断し、上記のケ

ースでは以下の規則を適用すること。

c) P-TMSI 再配置と GPRS アタッチ処理のバッティング

進行中の P-TMSI 再配置処理が正常完了する前にネットワークが ATTACH REQUEST メッセージを受信し

た場合、ネットワークは GMM コンテキストを削除した後に、GPRS アタッチ処理を進行させること。

d) P-TMSI 再配置と MS が開始した GPRS デタッチ処理のバッティング

進行中の P-TMSI 再配置処理が正常完了する前にネットワークが DETACH REQUEST メッセージを受信し

た場合、ネットワークは-TMSI 再配置処理を中断し、GPRS デタッチ処理を進行させること。

e) P-TMSI 再配置と RA 更新処理のバッティング

進行中の P-TMSI 再配置処理が正常完了する前にネットワークが ROUTING AREA UPDATE REQUEST メ

ッセージを受信した場合、ネットワークは P-TMSI 再配置処理を中断し、RA 更新処理を進行させること。次に

ネットワークは新たな P-TMSI 再配置処理を実行することができる。

f) P-TMSI 再配置とサービスリクエスト処理のバッティング

進行中の P-TMSI 再配置処理が正常完了する前にネットワークが SERVICE REQUEST メッセージを受信し

た場合、ネットワークは両方のプロセスを進行させること。

P-TMSI 再配置処理を中断／繰り返した結果、次の P-TMSI REALLOCATION COMMAND メッセージ内に含まれ

ていた新 P-TMSI の値が（前の値と）異なる場合には、MS は常に新かつリカバリ時間用に有効とされた既存の P-TMSI を信用すること。

MS Network

P-TMSI REALLOCATION COMMANDStart T3350

P-TMSI REALLOCATION COMPLETEStop T3350

図図図図 4.7.6/1 TS 24.008: P-TMSI 再配置処理再配置処理再配置処理再配置処理

4.7.7 Authentication and ciphering procedure （認証と暗号化処理）

4.7.7a Authentication and ciphering procedure used for UMTS authentication challenge （UMTS認証チャレンジに使用される認証と暗号化処理）

認証と暗号化処理の目的は以下の 4 点である（TS 33.102 参照）。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 132

- MS から提供されたアイデンティティが受容できるものか否か、ネットワークがチェックできるようにすること

- MS が新しい GPRS UMTS 暗号鍵と新しい GPRS UMTS 完全鍵を計算するためのパラメータを提供すること

- ネットワークが GSM 暗号化モード（暗号化／非暗号化）と GSM 暗号化アルゴリズムを設定できるようにする

こと

- MS にネットワークの認証を許可すること

UMTS では、UMTS 認証チャレンジのケースでは、認証と暗号化処理は暗号化のためだけに使用することができる。

認証と暗号化処理を使用すべきケースは、TS 33.102 および GSM 02.09 [5]で定義される。

認証と暗号化処理は、常にネットワークが開始して制御する。しかし、UMTS 認証チャレンジのケースでは、MS がネ

ットワークを拒否することも可能である。

GSM または UMTS の無線アクセスをサポートする ME は、UMTS 認証チャレンジをサポートすること。

認証と暗号化処理は、以下の目的のために使用することができる。

- 認証のためだけ

- GSM 暗号化モードと GSM 暗号化アルゴリズムを設定するためだけ

- 認証と、GSM 暗号化モードと GSM 暗号化アルゴリズムを設定するため

GSM では、ネットワークは認証と暗号化処理の過程でいかなるユーザデータも送信してはならない。

GSM または UMTS 内で UMTS 認証チャレンジが実行された場合、 MS とネットワーク内で UMTS セキュリティコン

テキストが確立される。UMTS 認証正常完了後、GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、 GPRS GSM 暗号鍵、

そして GPRS 暗号鍵シーケンス番号がネットワークと MS の双方で保存される。

4.7.7b Authentication and ciphering procedure used for GSM authentication challenge （認証と暗号化処理が GSM認証チャレンジ用に使用される場合）

認証と暗号化処理の目的は、以下の 3 点である（GSM 03.20 [13]参照）。

- MS から提供されたアイデンティティが受容できるものか否か、ネットワークがチェックできるようにすること

- MS が新しい GPRS UMTS 暗号鍵を計算するためのパラメータを提供すること

- ネットワークが GSM 暗号化モード（暗号化／非暗号化）と GSM 暗号化アルゴリズムを設定できるようにする

こと

認証と暗号化処理は、以下の目的のために使用することができる。

- 認証のためだけ

- GSM 暗号化モードと GSM 暗号化アルゴリズムを設定するためだけ

- 認証と、GSM 暗号化モードと GSM 暗号化アルゴリズムを設定するため

認証と暗号化処理を使用すべきケースは、GSM 02.09 [5]で定義される。

GSM では、認証と暗号化処理は、常にネットワークが開始して制御する。それは、以下の理由により、非暗号化モー

ドで実行されるべきである。

- ネットワークは、認証されていない MS からの暗号化された AUTHENTICATION AND CIPHERING RESPONSE を解読できないので、それをブラックリストに載せてしまうため

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 133

- 時間軸上のあるポイントを定義して、そこから新しい GPRS GSM 暗号鍵を旧 GPRS GSM 暗号鍵の代わりに

使用できるようにするため

GSM または UMTS の無線アクセスをサポートする ME は、GSM 認証チャレンジをサポートすること。

GSM では、ネットワークは認証と暗号化処理の過程でいかなるユーザデータも送信してはならない。

GSM または UMTS 内で UMTS 認証チャレンジが実行された場合、 MS とネットワーク内で GSM セキュリティコンテ

キストが確立される。GSM 認証正常完了後、GPRS GSM 暗号鍵と GPRS 暗号鍵シーケンス番号がネットワークと

MS の双方で保存される。

4.7.7.1 Authentication and ciphering initiation by the network （ネットワークが認証と暗号化を開始した場合）

ネットワークは、無線インタフェース上で AUTHENTICATION AND CIPHERING REQUEST メッセージを送信し、タ

イマ T3360 を起動させて、認証と暗号化処理を開始する。AUTHENTICATION AND CIPHERING REQUEST メッ

セージ内には、認証実行時に応答パラメータを計算するために必要な全てのパラメータが含まれること（GSM 03.20 [13] と TS 33.102 参照）。

認証が要求された場合、AUTHENTICATION AND CIPHERING REQUEST メッセージには以下のいずれかが含ま

れる。

- GMS 認証チャレンジでは、GPRS GSM 暗号鍵と RAND に割当てられた GPRS 暗号鍵シーケンス番号

- UMTS 認証チャレンジでは、GPRS UMTS 暗号鍵、RAND、そして AUTN に割当てられた GPRS 暗号鍵シー

ケンス番号

GSM では、認証が要求されない場合には、AUTHENTICATION AND CIPHERING REQUEST メッセージ内に

GPRS 暗号鍵シーケンス番号、 RAND、 AUTN のいずれも含まれてはならない。

GSM では、GSM 認証チャレンジまたは UMTS 認証チャレンジの中で暗号化が要求された場合には、ネットワーク

は、AUTHENTICATION AND CIPHERING REQUEST メッセージ内に A&C reference number IE を含めること。そ

の値は、RA 内の AUTHENTICATION AND CIPHERING REQUEST をその RESPONSE にリンクさｓるために選択

される。A&C reference number の値は、RA Colour Code の値をベースにしてもよい。

さらに、ネットワークは MS に対して、AUTHENTICATION AND CIPHERING RESPONSE メッセージ内に MS の

IMEISV を入れるように要求することもできる。

4.7.7.2 Authentication and ciphering response by the MS （MSからの認証と暗号化の応答）

GSM では、GPRS にアタッチされた MS は、いつでも AUTHENTICATION AND CIPHERING REQUEST メッセージ

に応答できる状態にあること。

UMTS では、GPRS にアタッチされた MS は、PS シグナリングコネクションが存在する限り、いつでも

AUTHENTICATION AND CIPHERING REQUEST メッセージに応答できる状態にあること。

GSM の認証チャレンジでは、AUTHENTICATION AND CIPHERING REQUEST メッセージ内に認証パラメータ

RAND と GPRS CKSN が含まれていた場合には、メッセージを受信した MS はチャレンジ情報を進行させ、

AUTHENTICATION AND CIPHERING RESPONSE メッセージをネットワークに送信すること。受信した A&C reference number IE の値を、AUTHENTICATION AND CIPHERING RESPONSE メッセージ内の A&C reference number IE にコピーすること。GSM 認証チャレンジの結果、SIM カードは SRES および GPRS GSM 暗号鍵を ME に

パスする。チャレンジ情報から算出された新しい GPRS GSM 暗号鍵は、既存のものに上書きして、以前保存された

GPRS UMTS 暗号鍵と GPRS UMT 完全鍵を全て削除すること。AUTHENTICATION AND CIPHERING RESPONSE を送信する前に、算出された GSM 暗号鍵を GPRS 暗号鍵シーケンス番号といっしょに SIM カード上に

保存すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 134

UMTS 認証チャレンジでは、AUTHENTICATION AND CIPHERING REQUEST メッセージ内に UMTS 認証パラメ

ータ GPRS CKSN, RAND、AUTN が含まれていた場合には、メッセージを受信した MS は AUTN パラメータを検証

し、受入可能であれば MS はチャレンジ情報を進行させ、AUTHENTICATION AND CIPHERING RESPONSE メッ

セージをネットワークに送信すること。受信した A&C reference number IE の値を、AUTHENTICATION AND CIPHERING RESPONSE メッセージ内の A&C reference number IE にコピーすること。UMTS 認証チャレンジの結果、

SIM カードは RES、GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして GPRS GSM 暗号鍵を ME にパスする。チャ

レンジ情報から算出された新しい GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして GPRS GSM 暗号鍵は、既存

のものに上書きすること。AUTHENTICATION AND CIPHERING RESPONSE を送信する前に、新しい GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして GPRS GSM 暗号鍵を GPRS 暗号鍵シーケンス番号といっしょに SIMカード上に保存すること。

UMTS では、UMTS ケーパビリティだけを持つ MS は、AUTHENTICATION AND CIPHERING REQUEST メッセー

ジ内の Ciphering Algorithm IE を無視すること。UMTS と GSM 双方のケーパビリティを持つ MS は、

AUTHENTICATION AND CIPHERING REQUEST メッセージ内の Ciphering Algorithm IE 内で受信した値を保存

し、UMTS → GSM へのシステム間変更の際に使用すること。

AUTHENTICATION AND CIPHERING REQUEST メッセージ内に、GSM 認証パラメータ(RAND と GPRS CKSN) も UMTS 認証パラメータ (RAND, AUTN、そして GPRS CKSN)も含まれていない場合には、メッセージを受信した

MS はネットワークに AUTHENTICATION AND CIPHERING RESPONSE メッセージを送信して応答する。

GSM では、GMM レイヤは LCC レイヤに対して、暗号化を使用すべきか否か、また使用すべき場合にはどの GSM 暗号化アルゴリズムと GPRS GSM 暗号鍵を使用すべきかを通知すること（GSM 04.64 [76]参照）。

4.7.7.3 Authentication and ciphering completion by the network （ネットワークによる認証と暗号化の完了）

ネットワークは、AUTHENTICATION AND CIPHERING RESPONSE メッセージを受信したならば、タイマ T3360 を

停止させ、応答の有効性を検証する（GSM 03.20 [13] および TS 33.102 参照）。そのために、ネットワークは

AUTHENTICATION AND CIPHERING RESPONSE メッセージ内で A&C reference number IE を使用して、応答と

後に送信された要求との間に関連性があるか否かを確定することができる。

GSM では、GMM レイヤは LCC レイヤに対して、暗号化を使用すべきか否か、また使用すべき場合にはどのアルゴ

リズムと GPRS GSM 暗号鍵を使用すべきかを通知すること（GSM 04.64 [76]参照）。

ネットワークは、AUTHENTICATION AND CIPHERING FAILURE メッセージを受信したならば、タイマ T3360 を停

止させること。同期失敗の場合には、CN が HLR/AuC とネゴシエーションして、MS に新しい認証パラメータを提供す


4.7.7.4 GPRS ciphering key sequence number （GPRS暗号鍵シーケンス番号）

認証と暗号化のためのセキュリティパラメータは、セットで結び付けられている。GSM 認証チャレンジでは、チャレン

ジパラメータ RAND から、認証応答パラメータ SRES と GPRS GSM 暗号鍵の双方が算出できる。与えられた秘密鍵

は IMSI と関連付けられる。UMTS 認証チャレンジでは、チャレンジパラメータ RAND から、認証応答パラメータ

RES 、GPRS UMTS 暗号鍵、そして GPRS UMTS 完全鍵が算出できる。与えられた秘密鍵は IMSI と関連付けられ

る。

認証を行うことなく論理リンク上で暗号化を開始するために、 GPRS 暗号鍵シーケンス番号が導入された。

GPRS 暗号鍵シーケンス番号はネットワークによって管理され、AUTHENTICATION AND CIPHERING REQUESTなどのメッセージには、GPRS GSM 暗号鍵、または GPRS UMTS 暗号鍵と GPRS UMTS 完全鍵に割当てられた

GPRS 暗号鍵シーケンス番号が含まれ（GSM 認証チャレンジの場合）、その値はメッセージが伝送する RAND パラ

メータから計算することができる。

MS は、GPRS GSM 暗号鍵（GSM 認証チャレンジの場合）と、GPRS UMTS 暗号鍵と GPRS UMTS 完全鍵（UMTS認証チャレンジの場合）といっしょに、GPRS 暗号鍵シーケンス番号を保存し、関連する GPRS 暗号鍵シーケンス番

号を ROUTING AREA UPDATE REQUEST、SERVICE REQUEST および ATTACH REQUEST メッセージ内に入

れる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 135

GPRS 暗号鍵シーケンス番号が削除された場合には、関連する GPRS GSM 暗号鍵、GPRS UMTS 暗号鍵、そして

GPRS UMTS 完全鍵を削除すること（つまり、確立された GSM セキュリティコンテキストあるいは UMTS セキュリティ

コンテキスト情況はもはや有効ではない）。

UMTS では、保存された GPRS 暗号鍵シーケンス番号と MS から与えられた番号が一致しなかった場合には、

（GSM 02.09 および TS 33.102 中で与えられる制限の元で）保存された GPRS UMTS 暗号鍵と GPRS UMTS 完全

鍵を使用して、ネットワークが暗号化と完全性検証の開始を選択することができる。

GSM では、保存された GPRS 暗号鍵シーケンス番号と MS から与えられた番号が一致し、かつ既にネゴシエーショ

ンされた暗号化アルゴリズムがネットワーク内で既知でかつサポートされている場合には、（GSM 02.09 中で与えら

れる制限の元で）ネットワークが保存された GPRS UMTS 暗号鍵による暗号化を開始することができる。 GPRS アタ

ッチの際に暗号化が要求される場合には、MS はデタッチ時に暗号化アルゴリズムを保存していないので、認証と暗

号化処理を実行すること。

GPRS アタッチ時に、暗号化を使用する必要がある場合、MS に AUTHENTICATION AND CIPHERING REQUESTメッセージを送信し、暗号化を開始すること。

ネットワーク内で保存されている GPRS シーケンス番号が、MS から ATTACH REQUEST メッセージ内で受信した

GPRS 暗号鍵シーケンス番号と一致しない場合、ネットワークは MS を認証すること。

GSM では、MS 側は AUTHENTICATION AND CIPHERING RESPONSE メッセージを送信後に暗号化を開始する。

ネットワーク側では MS から有効な AUTHENTICATION AND CIPHERING RESPONSE を受信したときに暗号化を

開始する。

UMTS では、MS は仕様書 TS 25.331 内で仕様化された条件に従って、暗号化と完全性検証を開始する。

GSM ではオプションとして、有効な GPRS 暗号鍵シーケンス番号といっしょに ROUTING AREA UPDATE REQUEST メッセージを受信した後に、AUTHENTICATION AND CIPHERING REQUES を送信せずに暗号化を継

続することを決定することができる。MS およびネットワークの双方が、新の暗号化パラメータを使用すること。ネッ

トワークは暗号化された ROUTING AREA UPDATE ACCEPT メッセージを MS に送信したときに暗号化を開始する。

MS はネットワークから暗号化された ROUTING AREA UPDATE ACCEPT メッセージを受信した後に暗号化を開始

する。

注: 仕様書によっては、GPRS 暗号鍵シーケンス番号という用語の代わりに KSI (Key Set Identifier)という

用語が使用される。

4.7.7.5 Authentication not accepted by the network （ネットワークが認証を拒否した場合）

認証と暗号化が失敗した場合、つまり、レスポンスが有効でない場合には、ネットワークは MS が認証用に P-TMSIと IMSI のどちらを使用したか調べる。

- P-TMSI が使用された場合には、ネットワークは識別処理の開始を決定することができる。 MS によって与え

られた IMSI が、ネットワークが P-TMSI に関連させたものと異なる場合には、正しいパラメーターで認証を再

開すること。MS によって与えられた IMSI が、予測された値とは異なる場合（つまり認証が本当に失敗した場

合）には、ネットワークは以下の手順を進行させること。

- IMSI が使用された場合、もしくはネットワークが識別処理を試行しないことを決定した場合には、

AUTHENTICATION AND CIPHERING REJECT メッセージを MS に送信すること。

AUTHENTICATION AND CIPHERING REJECT メッセージを受信した MS は、GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED にセットし、保存されている P-TMSI, P-TMSI 署名, RAI 、GPRS 暗号鍵シーケンス

番号を全て削除すること。利用可能な場合には、さらに TMSI、LAI および暗号鍵シーケンス番号を削除し、更

新ステータスを U3 ROAMING NOT ALLOWED にセットすること。電源が切断されるまで、または SIM カードが

抜かれるまで、SIM カードは無効であると見なすこと。

MS が AUTHENTICATION AND CIPHERING REJECT メッセージを受信した場合には、MS は GMM 処理を中

断し、（もし起動しているならば）タイマ T3310 と T3330 を停止させ、ステート GMM-DEREGISTERED に入ること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 136

4.7.7.5.1 Authentication not accepted by the MS（MSによる認証拒否）

UMTS 認証チャレンジでは、MS が CN のオーソリティを検証できるように、認証処理が拡張されている。例えば、偽

基地局を検出することが可能になっている。

UMTS 認証チャレンジに従って、AUTN パラメータの値が正しくないという理由で、MS が CN を拒否することも可能

である (TS 33.102 参照)。このパラメーターは、認証が失敗した理由として、以下の 2 つ値を取ることができる。

a) MAC code failure（MAC コードの失敗）

MS が、 (CN から AUTN パラメーター中で提供された) MAC コードが無効であると見なした場合、MS は GMM 理由

値'MAC failure'といっしょに、AUTHENTICATION AND CIPHERING FAILURE メッセージをネットワークに送信す

ること。その後、MS は、4.7.7.6(f)節に記述された処理に従うこと。

b) SQN failure（SQN の失敗）

MS が、 (CN から AUTN パラメーター中で提供された) SQN が範囲外の値であると見なした場合、MS は GMM 理

由値'Synch failure'および SIM カードが提供する再同期トークン AUTS（TS 33.102 参照）といっしょに、

AUTHENTICATION AND CIPHERING FAILURE メッセージをネットワークに送信すること。その後、MS は、

4.7.7.6(g)節に記述された処理に従うこと。


異常なケースは次のように分類できる。

a) Lower layer failure（下位レイヤの失敗）

AUTHENTICATION AND CIPHERING RESPONSE メッセージを受信する前に下位レイヤの失敗を検出した

ならば、ネットワークは処理を中断すること。

b) Expiry of timer T3360（タイマ T3360 の満了）

ネットワークはタイマーT3360 が第 1 回目満了時に、AUTHENTICATION AND CIPHERING REQUEST を

再送し、タイマ T3360 をリセットして起動すること。この再送は、4 回繰り返される。つまり、タイマーT3360 の 5回目満了時には、処理を中断すること。

c) 認証・暗号化処理と GPRS アタッチ処理のバッティング

進行中の認証処理が完了する前にネットワークが ATTACH REQUEST メッセージを受信し、かつネットワー

ク内にペンディングの GPRS アタッチ処理がない場合（つまり、ATTACH REQUEST メッセージに対する応答

として ATTACH ACCEPT/REJECT メッセージを送信する必要がない場合）には、ネットワークは認証および

暗号化処理を中断し、新たな GPRS アタッチ処理を進行させること。

d) 前回の GPRS アタッチ処理によって認証・暗号化処理が開始された場合、認証・暗号化処理が GPRS アタッ

チ処理とバッティングした場合

進行中の認証処理が完了する前にネットワークが ATTACH REQUEST メッセージを受信し、かつ GPRS アタ

ッチ処理がペンディングであった場合（つまり、ATTACH ACCEPT/REJECT メッセージが ATTACH REQUEST メッセージよりも早く応答として送信された場合）には、

- ATTACH REQUEST メッセージ中の 1 つまたは複数の IE が、先行する ATTACH REQUEST メッセージ

内で受信したものと異なる場合には、ネットワークは認証を中断し、GPRS アタッチ処理を進行させること。

- IE に差異がない場合、ネットワークはそれ以上この新しい ATTACH REQUEST を処理してはならない。

認証・暗号化処理が GPRS デタッチ処理とバッティングした場合


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 137

進行中の認証・暗号化処理が完了する前にネットワークが DETACH REQUEST メッセージを受信した場

合には、ネットワークは認証・暗号化処理を中断し、GPRS デタッチ処理を進行させること。

"power off"以外の理由値を含む GPRS デタッチ

進行中の認証・暗号化処理が完了する前にネットワークが DETACH REQUEST メッセージを受信した場

合には、ネットワークは認証・暗号化処理を中断し、4.7.4 節に記載されている通り GPRS デタッチ処理に

応答すること。

e) 認証・暗号化処理が RA 更新処理とバッティングした場合

進行中の認証処理が完了する前にネットワークが ROUTING AREA UPDATE REQUEST メッセージを受信

した場合には、ネットワークは両方の処理を進行させること。

MS NetworkAUTHENTICATION AND CIPHERING REQUEST

Start T3360

AUTHENTICATION AND CIPHERING RESPONSEStop T3360

AUTHENTICATION AND CIPHERING REJECT

図図図図 4.7.7/1 TS 24.008: 認証および暗号化処理認証および暗号化処理認証および暗号化処理認証および暗号化処理

(f)認証の失敗（GMM 理由値‘MAC failure’）

MS はネットワークに、GMM 理由値‘MAC failure’と共に、AUTHENTICATION&CIPHERING FAILURE メッ

セージを送信し、タイマ T3318 を起動すること。 GMM 理由値‘MAC failure’の CIPHERING FAILURE メッセ

ージを MS から受信したならば、ネットワークは、4.7.8 節に記述された識別処理を開始することができる。そ

れによって、ネットワークが MS から IMSI を獲得することができる。その後、ネットワークは、本来認証チャレ

ンジの中で使用された P-TMSI が、正しい IMSI に関連付けられていることを検証することができる。MS はネ

ットワークから IDENTITY REQUEST メッセージを受信したならば、IDENTITY RESPONSE メッセージを送信

すること。

ネットワーク中で P-TMSI/IMSI マッピングが正しく行われていない場合、ネットワークは新しい

AUTHENTICATION & CIPHERING REQUEST メッセージを MS に送信して応答すること。ネットワークから

2 回目の AUTHENTICATION&CIPHERING REQUEST メッセージを受信した MS は、もしタイマ T3318 が起

動しているならばそれを停止し、チャレンジ情報を通常通り処理すること。

MS がネットワークから 1 回目に受信した AUTHENTICATION & CIPHERING REQUEST メッセージに無効

な MAC が含まれていた場合、MS は起動中の全ての送信タイマ(例えば T3310、T3321、T3330、T3317 など)を停止させること。

ネットワークを正常に有効にしたならば（無効な MAC が含まれている AUTHENTICATION & CIPHERING REQUEST メッセージを受信した場合）、MS はネットワークに AUTHENTICATION & CIPHERING RESPONSE メッセージを送信し、MS が無効な MAC を含む第 1 回目の AUTHENTICATION AND CIPHERING REQUEST メッセージを受信したときに起動していて停止された全ての再送タイマ(つまり T3310、T3321、T3330 または T3317)を起動させること。

以下のどちらかが発生した場合、認証チャレンジの発信元が不正であると見なされる（MS によって認証が拒

否される）：

- GMM 理由値 ‘MAC failure’の AUTHENTICATION & CIPHERING FAILURE メッセージを送信後、タイ

マ T3318 が満了した場合

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 138

- T3318 が起動中に、ネットワークから 2 回目の AUTHENTICATION & CIPHERING REQUEST メッセー

ジを受信し、その MAC 値が解決できない場合

認証チャレンジの発信元が不正であると MS が判断した場合（MS によって認証が拒否された場合）、MS は

4.7.7.6.1 節に記載された通りに動作すること。

MS NetworkAUTHENTICATION & CIPHERING REQUEST

Start T3360

AUTH & CIPH FAILURE (cause=’MAC failure’)Stop T3360

IDENTITY REQUEST

IDENTITY RESPONSE (IMSI)

AUTHENTICATION & CIPHERING REQUEST

AUTHENTICATION & CIPHERING RESPONSE

Start T3318

Stop T3318

Start T3370

Start T3370

Start T3360

Start T3360

図図図図 4.7.7a/1 TS 24.008: 理由値理由値理由値理由値‘MAC failure’の認証の失敗の認証の失敗の認証の失敗の認証の失敗

(g)認証の失敗(GMM 理由値‘Synch failure’)

MS はネットワークへ、GMM 理由値‘Synch failure’の AUTHENTICATION&CIPHERING FAILURE メッセー

ジを送信し、タイマ T3320 を起動すること。理由値‘Synch failure’の AUTHENTICATION & CIPHERING メッ

セージを MS から受信したネットワークは、再同期するために AUTHENTICATION&CIPHERING FAILUREメッセージ中の authentication & ciphering failure parameter IE から返された AUTS パラメータを使用すること。再同期処理のために、SGSN は未使用の IMSI 用の認証ベクトルを全て削除し、新しいベクトルを HLR 取得

しなくてはならない。再同期処理が完了したならば、ネットワークは認証・暗号化処理を開始すること。

AUTHENTICATION&CIPHERING REQUEST メッセージ受信時に、もしタイマ T3320 が起動していたならば

MS はそれを停止すること。

MS がネットワークから初に受信した AUTHENTICATION & CIPHERING REQUEST メッセージ中に無効

な SQN が含まれていた場合、MS は起動している全ての再送タイマ（T3310, T3321, T3330、または T3317 な

ど）を停止すること。

（有効な SQN を含んでいる別の AUTHENTICATION&CIPHERING REQUEST メッセージを受信して）タイマ

T3320 起動中にネットワークが正常に有効にされた場合、MS はネットワークに AUTHENTICATION & CIPHERING RESPONSE メッセージを送信すること。そして MS が無効な SQN を含む初の

AUTHENTICATION AND CIPHERING REQUEST メッセージを受信した際に起動している再送タイマを停止

した場合には、それらの再送タイマ(つまり T3310, T3321, T3330 または T3317)を起動すること。

タイマ T3320 起動中に、MS が 2 回目の AUTHENTICATION & CIPHERING REQUEST を受信し、それに

有効な SQN が含まれていた場合には、MS は 4.7.7.6.1 節に記載されているように動作すること。

タイマ T3320 満了時、MS は 4.7.7.6.1 節に記載されているように動作すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 139

MS NetworkAUTHENTICATION & CIPHERING REQUEST Start T3360

AUTH & CIPH FAILURE (cause=’Synch failure’) Stop T3360

AUTHENTICATION & CIPHERING REQUEST

AUTHENTICATION & CIPHERING RESPONSE

Start T3320

Stop T3320


図図図図 4.7.7b/1 TS 24.008: 認証失敗理由値認証失敗理由値認証失敗理由値認証失敗理由値 ‘Synch failure’

4.7.7.6.1 MS behaviour towards a network that has failed the authentication procedure （認証が失敗したネットワークに対する MSの動作）

ネットワークが認証チェックに失敗したと MS がみなした場合、システム情報データが更新されるまで、MS は

AUTHENTICATION&CIPHERING REQUEST メッセージを受信したセルを禁止扱いすること。MS が無効な MACまたは SQN を含む初の AUTHENTICATION AND CIPHERING REQUEST メッセージを受信した際に起動して

いる再送タイマを停止した場合には、それらの再送タイマ(つまり T3310, T3321, T3330 または T3317)を起動すること。

4.7.7.7 Use of established security contexts （確立されたセキュリティコンテキストの使用）

GSM では、GSM セキュリティコンテキストが確立されている場合には、AUTHENTICATION AND CIPHERING RESPONSE メッセージが送信される前に、MS は GPRS GSM 暗号鍵を使用すること。

GSM では、UMTS セキュリティコンテキストが確立されている場合には、AUTHENTICATION AND CIPHERING RESPONSE メッセージが送信される前に、MS は GPRS GSM 暗号鍵を使用すること。ネットワークは、GPRS UMTS暗号鍵と GPRS UMTS 完全鍵から、変換関数（TS 33.102 内で"c3"として定義される）を使用して GPRS GSM 暗号

鍵を誘導すること。

UMTS では、GSM セキュリティコンテキストが確立されている場合、ME は TS 33.102 中で"c4" および"c5" と命名・

定義される変換関数を使用して、GPRS GSM 暗号鍵から GPRS UMTS 暗号鍵と GPRS UMTS 完全鍵を誘導するこ

と。 MS は、RR コネクション上で PS ドメインを通知する、有効な SECURITY MODE COMMAND メッセージを受信

したならば、誘導された GPRS UMTS 暗号鍵および GPRS UMTS 完全鍵を使用すること（「有効な SECURITY MODE COMMAND メッセージ」の定義は、TS 25.331 中で与えられる）。ネットワークは TS 33.102 中で"c4" および

"c5" と命名・定義される変換関数を使用して、GPRS GSM 暗号鍵から GPRS UMTS 暗号鍵と GPRS UMTS 完全鍵

を誘導すること。

UMTS では、UMTS セキュリティコンテキストが確立されている場合、PS シグナリングコネクション上で PS ドメインを

通知する有効な SECURITY MODE COMMAND メッセージを受信した場合、MS は GPRS UMTS 暗号鍵と GPRS UMTS 完全鍵の使用を開始すること（有効な SECURITY MODE COMMAND メッセージの定義は、TS 25.331 中で

与えられる）。

注: UMTS では、新しい GSM/UMTS セキュリティコンテキストを確立するために、進行中の既に暗号化／

完全性保護された PS シグナリングコネクション上で、新しい認証・暗号化処理を開始することができる。

PS シグナリングコネクション上で PS ドメインを通知する有効な SECURITY MODE COMMAND メッセ

ージを受信した場合、MS は新しい GPRS UMTS 暗号鍵と GPRS UMTS 完全鍵の使用を開始するこ

と。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 140

4.7.7.8 Handling of keys at intersystem change from UMTS to GSM （UMTS→GSMへのシステム間変更時の鍵の取り扱い）

UMTS から GSM へのシステム間変更時には、新たな認証および暗号化処理なしで、暗号化を開始することができ

る（GSM 04.64 [76]参照）。GSM 内での暗号化用の適切な秘密鍵の省略は、MS とネットワーク内に保存されている

現行の GSM/UMTS セキュリティコンテキストに依存する。

表 4.7.7.8.1 に従って、ME は GPRS GSM 暗号鍵を取り扱うこと。

GSM 内の新しいセル内で初期 GMM メッセージが送信される前に、MS 内の GMM レイヤは LLC レイヤに対して、

暗号化を使用すべきか否か、通知すること。もし暗号化を使用すべき場合には、MS 内に保存されている Ciphering Algorithm IE に従って、GPRS GSM 暗号鍵と適切な暗号化アルゴリズムを通知すること (GSM 04.64[76]参照)。

表表表表 4.7.7.8.1/TS 24.008:システム間変更（システム間変更（システム間変更（システム間変更（UMTS→→→→GSM））））

Security context established in MS and network in UMTS

At intersystem change to GSM:

GSM security context

An ME shall apply the GPRS GSM cipher key received from the GSM security context residing in the SIM.

UMTS security context

An ME shall apply the GPRS GSM cipher key derived by the SIM from the GPRS UMTS cipher key and the GPRS UMTS integrity key.

注 UMTS セキュリティコンテキストを持つ SIM カードは、現行の RAN が UMTS か GSM かに関わらず、

GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして誘導された GPRS GSM 暗号鍵を ME にパスする。

4.7.7.9 Handling of keys at intersystem change from GSM to UMTS （GSM→UMTSへのシステム間変更時の鍵の取り扱い）

GSM から UMTS へのシステム間変更時には、新しい認証と暗号化処理なしで、暗号化と完全性保護を開始するこ

とができる（TS 25.331 参照）。UMTS 内での暗号化および完全性チェック用の適切な秘密鍵の省略は、MS とネット

ワーク内に保存されている現行の GSM/UMTS セキュリティコンテキストに依存する。

表 4.7.7.9.1 に従って、ME は GPRS 暗号鍵を取り扱うこと。

表表表表 4.7.7.9.1/TS 24.008: システム間変更（システム間変更（システム間変更（システム間変更（GSM→→→→UMTS））））

Security context established in MS and network in GSM

At intersystem change to UMTS:

GSM security context

An ME shall derive the GPRS UMTS cipher key and GPRS UMTS integrity key from the GPRS GSM cipher key provided by the SIM. The conversion functions named "c4" and "c5" in TS 33.102 are used for this purpose.

UMTS security context

An ME shall apply the GPRS UMTS ciphering key and the GPRS UMTS integrity key received from the UMTS security context residing in the SIM.

注: UMTS セキュリティコンテキストを持つ SIM カードは、現行の RAN が UMTS か GSM かに関わらず、

GPRS UMTS 暗号鍵、GPRS UMTS 完全鍵、そして誘導された GPRS GSM 暗号鍵を ME にパスする。

4.7.8 Identification procedure（識別処理）識別処理は、ネットワークが MS に対して、特定の識別パラメータ（例えば IMSI や IMEI、TS 23.003 参照）をネットワ

ークに対して提供するよう要求する際に使用される。IMEI を提供する際には、GSM 02.09 の要求条件が適用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 141

4.7.8.1 Identification initiation by the network（ネットワークによる識別の開始）

ネットワークは MS に IDENTITY REQUEST メッセージを送信してタイマ T3370 を起動させて、識別処理を開始する

ことができる。IDENTITY REQUEST メッセージは、identity type IE 内で要求された認識パラメータを規定する。

4.7.8.2 Identification response by the MS（MSによる識別応答）

GPRS にアタッチされた MS は、いつでも IDENTITY REQUEST メッセージに対して応答できること。

MS は IDENTITY REQUEST メッセージを受信したならば、IDENTITY RESPONSE メッセージを返す。IDENTITY RESPONSE メッセージには、ネットワークから要求された識別パラメータが含まれること。

4.7.8.3 Identification completion by the network（ネットワークによる識別の完了）

IDENTITY RESPONSE メッセージを受信したネットワークは、タイマ T3370 を停止すること。




ネットワークが IDENTITY RESPONSE メッセージを受信する前に下位レイヤの失敗を検出した場合、ネットワ

ークは進行中の GMM 処理を全て中断すること。

b) タイマ T3370 の満了

ネットワークはタイマ T3370 を使用して識別処理を監視する。タイマ T3370 の第 1 回目満了時に、ネットワー

クは IDENTITY REQUEST メッセージを再送し、タイマ T3370 をリセットして再開すること。この再送は、4 回

まで繰り返される。つまり、タイマ T3370 が 5 回目に満了したとき、ネットワークは識別食と進行中の GMM 処

理を全て中断すること。

c) 識別処理と GPRS アタッチ処理のバッティング

進行中の識別処理が完了する前にネットワークが ATTACH REQUEST メッセージを受信し、ネットワーク内

でペンディングとなっている GPRS アタッチ処理がない場合（つまり ATTACH REQUEST メッセージに対する

応答として ATTACH ACCEPT/REJECT メッセージを送信する必要がない場合）、ネットワークはに GPRS アタ

ッチ処理を進行させること。

d) GPRS アタッチ処理によって識別処理が発生した場合、識別処理と GPRS アタッチ処理がバッティング

進行中の識別処理が完了する前にネットワークが ATTACH REQUEST メッセージを受信し、かつ GPRS アタ

ッチ処理がペンディングとなっている（つまり前の ATTACH REQUEST メッセージに対する応答として

ATTACH ACCEPT/REJECT メッセージを送信する必要がある場合）、

- ATTACH REQUEST メッセージ内の 1 つまたは複数の IE が、前回の ATTACH REQUEST メッセージ内

で受信したものと異なる場合、ネットワークは GPRS アタッチ処理を進行させること。

- IE に差異がない場合、ネットワークはそれ以上この新しい ATTACH REQUEST を扱ってはならない。

識別処理と、MS が開始した GPRS デタッチ処理のバッティング


進行中の識別処理が完了する前にネットワークが DETACH REQUEST メッセージを受信した場合、ネット

ワークは識別処理を中断し、GPRS デタッチ処理を進行させること。

GPRS デタッチ containing other causes than "power off": 理由値"power off"以外の GPRS デタッチ

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 142

進行中の識別処理が完了する前にネットワークが DETACH REQUEST メッセージを受信した場合、ネットワ

ークは識別処理を完了し、4.7.4 節に記載されている通りに GPRS デタッチ処理に応答すること。

e) 識別処理と RA 更新処理のバッティング

進行中の識別処理が完了する前にネットワークが ROUTING AREA UPDATE REQUEST メッセージを受信

した場合、ネットワークは両方の処理を進行させること。

f) 識別処理とサービスリクエスト処理のバッティング

進行中の識別処理が完了する前にネットワークが SERVICE REQUEST メッセージを受信した場合、ネットワ

ークは両方の処理を進行させること。

MS Network

IDENTITY REQUESTStart T3370

IDENTITY RESPONSEStop T3370

図図図図 4.7.8/1 TS 24.008: 識別処理識別処理識別処理識別処理（（（（Identification procedure））））

4.7.9 Paging procedure（ページング処理）

4.7.9.1 Paging for GPRS services（GPRSサービス用ページング）

GSM では、ネットワークはページングを使用して、MS が現在選択しているセルを特定したり、またはネットワークで

失敗が発生したので必要ならば再アタッチするようモバイルに促すことができる。GPRS にアタッチされていない MSが GPRS サービス用のページングを受信した場合、MS はページングを無視すること。

UMTS では、ネットワークはページングを使用して、PS シグナリングコネクションの確立を要求したり、またはネットワ

ークで失敗が発生したので必要ならば再アタッチするようモバイルに促すことができる。GPRS にアタッチされていな

い MS が GPRS サービス用のページングを受信した場合、MS はページングを無視すること。

4.7.9.1.1 Paging for GPRS services using P-TMSI （P-TMSIを使用した GPRSサービス用のページング）

ネットワークは、Mobile Reachable タイマが起動している間、MS に送信すべき GMM シグナリングメッセージまたは

ユーザデータがペンディング状態のときには、P-TMSI を使用して GPRS サービス用ページング処理を開始すること。

ネットワークは、GMM-REGISTERED されて、かつローカル P-TMSI によって特定される GPRS MS に対してのみ、

ページングを行うことができる。

UMTS では、処理を開始するために、ネットワーク内の GMM エンティティが、下位レイヤに対してページング(TS 25.331 および TS 25.413 参照)の開始を要求し、タイマ T3313 を起動させる。ページング通知を受信した MS は、

service type "paging response"(TS 24.007[20]、TS23.060[74]、TS 25.331 および TS 25.413 参照)の SERVICE REQUEST メッセージで応答すること。

システム間変更時、GSM 内で起動している READY タイマを持たない MS、または UMTS の PMM-IDLE モードに

ある MS が、前回ユーザデータまたはシグナリングメッセージを送信したのとは異なる RAN からページングされたな

らば、ページング応答と ROUTING AREA UPDATE REQUEST メッセージを使用すること。つまり、選択的な RA 更

新処理ではなく、RA 更新処理を実行すること。

ネットワークは MS から応答を受信したならば、タイマ T3313 を停止させること。タイマ T3313 が満了したならば、ネッ

トワークはページングを再開することができる。

UMTS では、MS から応答受信時、ネットワークはモードを PMM-IDLE から PMM-CONNECTED に変更させること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 143

GSM では、MS から応答を受信したならば、ネットワークは READY タイマを起動すること。

4.7.9.1.2 Paging for GPRS services using IMSI （IMSIを使用した GPRSサービス用のページング）

IMSI を使用した GPRS サービス用ページングは、ネットワーク内でエラーを回復するために使用される異常な処理

である。

ネットワークのエラーにより、P-TMSI が使用できない場合、ネットワークは IMSI を使用してページングを開始するこ

とができる。

UMTS では、処理を開始するために、ネットワーク内の GMM エンティティは下位レイヤに対してページングの開始

を要求する（TS 25.331 および TS 25.413 を参照）。

GSM では、処理を開始するために、ネットワーク内の GMM エンティティは RR サブレイヤに対してページングの開

始を要求する（GSM 04.18、GSM 04.60[75]を参照）。

IMSI を使用した GPRS サービス用ページング通知を受信した MS は、ローカルに全てのアクティブな PDP コンテキ

ストを非アクティブにし、ローカルに GPRS からデタッチすること。ローカルなデタッチには、保存された全ての RAI, P-TMSI, P-TMSI 署名、GPRS 暗号鍵シーケンス番号の削除と、GPRS 更新ステータスの GU2 NOT UPDATED への

設定と、ステート GMM-DEREGISTERED へのステート変更が含まれる。

ローカルなデタッチ処理完了後、次に MS は GPRS アタッチ処理または複合 GPRS アタッチ処理を実行すること。

アタッチ実行後、MS は PDP コンテキストをアクティブにして、以前のアクティブな PDP コンテキストを置換すること。

注 1: 特定のケースでは、ユーザのインターアクションが必要になるために、MS が自動的に PDP コンテキス

トをアクティブにできないことがある。

注 2: MS は Attach Request 以外のページングには応答しない。であるから、IMSI を使用したページングの

場合には、ネットワーク内のタイマ T3313 は使用されない。

注 3: DRX パラメータなしのページングは、ページング期間の相当な拡張を要求することができる。

4.7.9.2 Paging for non-GPRS services（非 GPRSサービス用ページング）

MS が非 GPRS サービス用に IMSI アタッチされていない場合、ネットワークは非 GPRS サービス用ページングを開

始することができる。

UMTS では、処理を開始するために、GMM エンティティが下位レイヤに対して、非 GPRS サービス用ページングを

要求する(TS 25.331 および TS 25.413 を参照)。

GSM では、処理を開始するために、GMM エンティティが RR サブレイヤに対して、非 GPRS サービス用ページング

を要求する(GSM 04.18 GSM 04.60 [75]参照)。

ページングの際に使用する MS のアイデンティティは、MS が acknowledge されている場合には TMSI を、そうでない

場合には IMSI を割当てること。

4.7.10 Receiving a GMM STATUS message by a GMM entity （GMMエンティティによる GMM STATUSメッセージの受信）

MS が GMM STATUS メッセージを受信した場合、無線インタフェースの観点からは、ステート遷移も特別なアクショ

ンも起こらない。つまり、ローカルなアクションのみが可能である。GMM STATUS メッセージ受信に際してネットワー

クが取るべきアクションは、実装オプションに依存する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 144

4.7.11 Void

4.7.12 GMM Information procedure（GMM情報処理） GMM 情報メッセージのサポートは、ネットワーク内ではオプション。GMM コンテキストが確立されている間、ネットワ

ークはいつでも MM 情報処理を起動することができる。

4.7.12.1 GMM information procedure initiation by the network （ネットワークによる GMM情報処理の開始）

GMM 情報処理は、ネットワークから MS に送信される GMM INFORMATION メッセージだけから構成される。

GMM コンテキストが確立されている間、ネットワークは MS に対して GMM INFORMATION メッセージを送らなくて

もよいし、1 つまたは複数送信することもできる。複数の GMM INFORMATION メッセージが送信された場合、メッセ

ージは同一の内容を含んではならない。

4.7.12.2 GMM information procedure in the mobile station （MS内での GMM情報処理）

GMM 情報メッセージをサポートする）MS が GMM INFORMATION メッセージを受信した場合、MS はメッセージを

受け付けて、オプションとしてその内容を使用して MS 内に保存された適切な情報を更新することができる。

MS が GMM 情報メッセージをサポートしない場合には、MS は、メッセージの内容を無視し、理由値#97 といっしょに

GMM STATUS メッセージを返すこと。

4.7.13 Service Request procedure (UMTS only) （サービスリクエスト処理（UMTSのみ））

本処理の目的は、PMM モードを PMM-IDLE から PMM-CONNECTED に変化させ、および／または RAB（radio access bearer ）が割当てられずに PDP コンテキストがアクティブになった場合には RAB を割当てることにある。後者

のケースでは、PMM モードは PMM-IDLE あるいは PMM-CONNECTED モードの可能性がある。本処理は以下の

ような場合に使用される。

- PMM-IDLE モードにある MS が CM レイヤのサービス（SM や SMS など）処理を開始するとき

- ネットワークが下りリンクシグナリングを送信

- 上りおよび下りリンクのユーザパケット

下りリンクのシグナリング／ユーザパケット送信については、ページングリクエスト処理によってネットワークがトリガ

するが、それについては本仕様書の範囲外である。

サービスタイプは、次のいずれかの値をとることができる。すなわち、「シグナリング」（"signalling"）、「データ」

（"data"）、または「ページング応答」（ "paging response"）。その値を選択するかは、サービスリクエスト処理を開始す

るための基準に従う。

サービスリクエスト処理を起動するための基準は、

a) MS が PMM-IDLE モードにあり、セキュリティ保護が必要なネットワークに送信すべきシグナリングメッセージ

を持っている場合（つまり、セキュリティ確保されたシグナリングコネクションがまだ確立されていない場合）。こ

の場合、サービスタイプは、"signalling"に設定すること。

b) MS が PMM-IDLE および PMM-CONNECTED モードにあり、送信すべきペンディングのユーザパケットを持

っており、かつ PDP コンテキスト用に RAB が確立されていない場合。下位レイヤからの通知を受けて、処理

が開始される（TS 24.007 参照）。この場合、サービスタイプは、"data"に設定すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 145

c) MS が PMM-IDLE モードにあり、ネットワークから PS ドメイン用のページングリクエストを受信した場合。この

場合、サービスタイプは、"paging response"に設定すること。

サービスリクエスト処理が完了した後、ペンディングのサービスは再開され、（サービスリクエスト）処理によって確立

された接続を使用する。サービスタイプが"data"を示している場合には、アクティブになった全 PDP コンテキスト用の

RAB は再確立される。選択的再割当てケーパビリティは、機能を複雑にしないために、サポートされない。

4.7.13.1 Service Request procedure initiation（サービスリクエスト処理の開始）

MS は SERVICE REQUEST メッセージを送信し、サービスリクエスト処理を開始する。SERVICE REQUEST メッセー

ジが送信され、ステート GMM-SERVICE-REQUEST-INITIATED に入った後、タイマ T3317 を起動すること。メッセージ SERVICE REQUEST には P-TMSI が含まれること。サービスタイプは、データ、シグナリング、ページングのい

ずれかであること。

4.7.13.2 GMM common procedure initiation（ GMM共通の処理の開始）

ネットワークは、GPRS 暗号鍵シーケンス番号または P-TMSI などの受信した情報に基づいて、GMM 共通処理(例えば GMM 識別、GMM 認証、暗号化処理など)を開始することができる。

4.7.13.3 Service request procedure accepted by the network （サービスリクエストがネットワークに受理された場合）

下位レイヤから、セキュリティモード制御処理完了通知、または SERVICE ACCEPT メッセージの受信通知を受信し

たならば、処理が正常完了したものとみなされる。タイマ T3317 を停止し、MS は GMM-REGISTERED ステート、

PMM-CONNECTED モードに入ること。

4.7.13.4 Service request procedure not accepted by the network （サービスリクエストがネットワークに拒否された場合）

- ネットワークがサービスリクエストを受理できない場合、ネットワークは MS に SERVICE REJECT メッセージを

返す。MS は SERVICE REJECT メッセージを受信したならば、タイマ T3317 を停止する。そしてその後、MSは、受信した拒否理由値に応じて、異なるアクションを取ること。


# 6 (Illegal ME) （不正 ME）

- MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し（そして 4.1.3.2 節に従ってそれを

保存し）、ステート GMM-DEREGISTERED に入る。さらに、MS は P-TMSI, P-TMSI 署名, RAI、そして GPRS 暗号鍵シーケンス番号を全て削除し、電源が切断されるか SIM カードが抜かれるまで、SIM カードは GPRSサービスについて無効であると見なすこと。

- MS オペレーションモード A で運用される GPRS MS は、更新ステータスを U3 ROAMING NOT ALLOWEDに設定するほかに、TMSI, LAI、そして暗号鍵シーケンス番号を削除すること。新しい MM ステートは MM IDLE。電源が切断されるか SIM カードが抜かれるまで、SIM カードは非 GPRS サービスについても無効であ

ると見なすこと。

# 7 (GPRS Service not allowed) （GPRS サービス禁止）

- MS は GPRS 更新ステータスを GU3 ROAMING NOT ALLOWED に設定し（そして 4.1.3.2.9 節に従ってそれ

を保存し）、P-TMSI, P-TMSI 署名, RAI 、GPRS 暗号鍵シーケンス番号を全て削除すること。電源が切断され

るか SIM カードが抜かれるまで、SIM カードは GPRS サービスについて無効であると見なすこと。新しいステ

ートは GMM-DEREGISTERED。

# 9 (MS identity cannot be derived by the network)（ネットワークが MS のアイデンティティを識別不可能）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 146

- MS は GPRS 更新ステータスを GU2 NOT UPDATED に設定し（そして 4.1.3.2 節に従ってそれを保存し）、ス

テート GMM-DEREGISTERED に入り、P-TMSI, P-TMSI 署名, RAI 、GPRS 暗号鍵シーケンス番号を全て削

除すること。その後で、MS は自動的に GPRS アタッチ処理を開始することができる。

# 10 (Implicitly detached) （非明示的デタッチ）

- MS はステートを GMM-DEREGISTERED.NORMAL-SERVICE に変更すること。MS は次に新しいデタッチ

処理を実行すること。MS はまた、PDP コンテキストをアクティブにし、前のアクティブな PDP コンテキストを置

換すること。

注: 特定のケースでは、ユーザのインターアクションが必要になるために、MS が自動的に PDP コンテキス




# 13 (Roaming not allowed in this location area)（該当 LA 内でローミング禁止）

- MS は RAI, P-TMSI, P-TMSI 署名、GPRS 暗号鍵シーケンス番号を全て削除し、GPRS 更新ステータスを

GU3 ROAMING NOT ALLOWED に設定し（4.1.3.2 節に従ってそれを保存し）、ステート GMM-DEREGISTERED に入ること。

- MS オペレーションモード A で運用される GPRS MS は、更新ステータスを U3 ROAMING NOT ALLOWEDに設定した上で、TMSI, LAI、暗号鍵シーケンス番号を全て削除すること。新しい MM ステートは MM IDLE。

- MS は適切な禁止リスト内（理由値#11 の場合"forbidden PLMN list"、理由値#12 の場合"forbidden location areas for regional provision of service"のリスト、理由値#13 の場合"forbidden location areas for roaming"のリ

スト内）に、LAI または PLMN 識別子を保存すること。理由値#11 または#13 を受信したならば、MS はセル選

択の代わりに PLMN 選択処理を実行すること。

# 40 (No PDP context activated)（アクティブな PDP コンテキストがない）

- MS はローカルにアクティブな PDP コンテキストを全てインアクティブにして、ステート GMM-REGISTERED.NORMAL-SERVICE に入ること。MS はまた、PDP コンテキストをアクティブにして、前の

PDP コンテキストを置換することもできる。

注: 特定のケースでは、ユーザのインターアクションが必要になるために、MS が自動的に PDP コンテキス


上記以外の値は全て以上なケースと見なされる。これらのケースにおける MS の動作は、4.7.13.5 節に記載される。

4.7.13.5 Abnormal cases in the MS（異常なケース、MS側）


a) アクセスクラス制御によるアクセス禁止

サービスリクエスト処理を開始してはならない。MS は現行のサービスセル内に留まり、通常のセル再選択処

理を適用すること。サービスリクエスト処理が未だ必要ならば、つまりセルの変更によってアクセスが許可され

た場合に、CM レイヤが開始することができる。

b) セキュリティモード制御処理が完了する前に下位レイヤでエラーが発生し、SERVICE ACCEPT または SERVICE REJECT メッセージを受信した場合

処理を中断すること。

c) T3317 expired（T3317 の満了）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 147

MS は GMM-REGISTERED ステートに入ること。

MS が PMM-IDLE モードにある場合、処理を中断し、MS は PS シグナリングコネクションの開放を開始するこ

と。

MS が PMM-CONNECTED モードにある場合、タイマ T3317 が満了したならば、サービスリクエスト処理が完

了したものとみなされる。

d) 4.7.x.4 節で扱った理由値以外の SERVICE REJECT メッセージを受信

処理を中断すること。

e) RA 更新処理がトリガされた

セキュリティモード制御処理が完了する前に、新しい RA 内のセル変更が起きて、RA 更新処理を決定する必

要が生じた場合、SERVICE ACCEPT または SERVICE REJECT メッセージが受信されたならば、サービスリ

クエスト処理を中断し、RA 更新処理を直ちに開始すること。サービス用の OUTING AREA UPDATE REQUEST メッセージ内で Follow-on request pending を通知することができる。これは中断されたサービスリ

クエスト処理のトリガであり、ペンディングのサービスそれ自体、または RA 更新処理完了後のサービスリクエ

スト処理を再開させるために使用される。中断された SERVICE REQUEST 内のサービスタイプが"data"であ

った場合には、"data"を通知されたサービスリクエスト処理をその処理が未だ必要ならば、RA 更新処理の後

で再開することができる。

f) 電源断

電源断時に MS がステート GMM-SERVICE-REQUEST-INITIATED にあったならば、GPRS デタッチ処理を

実行すること。

g) 処理のバッティング

MS がステート GMM-SERVICE-REQUEST-INITIATED にあるネットワークから、DETACH REQUEST メッセ

ージを受信した場合、GPRS デタッチ処理を進行させ、サービスリクエスト処理は中断すること。、DETACH REQUEST メッセージ内の理由 IE が"reattach request"を示していた場合には、GPRS アタッチ処理を実行する

こと。

4.7.13.6 Abnormal cases on the network side（異常なケース（ネットワーク側））



セキュリティモード制御処理が完了する前に下位レイヤで失敗が発生した場合には、SERVICE ACCEPT または SERVICE REJECT メッセージが MS に送信され、ネットワークは PMM-IDLE に入る／留まる。

b) プロトコルのエラー

プロトコルのエラーを伴う SERVICE REQUEST メッセージを受信した場合、ネットワークは以下の拒否理由の

いずれかといっしょに SERVICE REJECT メッセージを返すこと。


#99: Information element non-existent or not implemented（存在しない、または実装されていない IE）


#111: Protocol error, unspecified（プロトコルエラー、特定不能）

ネットワークは PMM-IDLE に留まる。

c.) 複数の SERVICE REQUEST メッセージを受信し、処理が完了しなかった場合（つまり、セキュリティモード制

御処理が完了しなかった、または SERVICE ACCEPT, SERVICE REJECT メッセージが送信されなかった）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 148

- SERVICE REQUEST メッセージ内の 1 つまたは複数の IE が、前回の SERVICE REQUEST メッセージ内

で受信した値と異なる場合には、既に開始された前のサービスリクエスト処理を中断し、新しいサービスリ

クエスト処理を進めること。

- IE に差異がない場合、ネットワークは前のサービスリクエスト処理を進行させ、今回の SERVICE REQUEST メッセージをそれ以上処理してはならない。

d) セキュリティモード制御処理が完了する前、または SERVICE ACCEPT／SERVICE REJECT メッセージが送

信される前に ATTACH REQUEST を受信した場合

セキュリティモード制御処理が完了する前、または SERVICE ACCEPT／SERVICE REJECT メッセージが送

信される前に ATTACH REQUEST メッセージを受信した場合、ネットワークは GMM 共通処理（例えば

GMM 認証と暗号化処理）を開始することができる。ネットワークは、例えば GMM 認証と暗号化処理が正常

に完了した後で、サービスリクエスト処理を中断し、GMM コンテキストと、（もしあれば）PDP コンテキストを削

除し、新たな ATTACH REQUEST を進行させること。

e) セキュリティモード制御処理が完了する前、または SERVICE ACCEPT／SERVICE REJECT メッセージが送

信される前に ROUTING AREA UPDATE REQUEST メッセージを受信した場合

セキュリティモード制御処理が完了する前、または SERVICE ACCEPT／SERVICE REJECT メッセージが送

信される前に ROUTING AREA UPDATE REQUEST メッセージを受信した場合、ネットワークは GMM 共通

処理（例えば GMM 認証と暗号化処理）を開始することができる。ネットワークは、例えば GMM 認証と暗号

化処理が正常に完了した後で、サービスリクエスト処理を中断し、RA 更新処理を進行させること。

f) サービスタイプが‘data’で、ネットワークが RAB の一部／全部の再確立に失敗した場合、SGSN は、PDP Context Modification と PDP Context Deactivation のいずれを開始すべきか、決定することができる。適切なアクションは、PDP コンテキストの QoS プロファイルに依存する。QoS プロファイルはオペレータによっ

て選択される。

4.7.14 Void

5 Elementary procedures for circuit-switched Call Control （CS呼制御用の基本的な処理）

5.1 Overview（概要）

5.1.1 General（概説） (CM) sublayer (see TS 24.007).本セクションでは、コネクション管理(CM)サブレイヤ（TS24.007 を参照）のプロトコル

のうちの 1 つである、呼制御(CC)プロトコルについて記述する。

すべての MS は、移動局は呼制御プロトコルをサポートする必要がある。MS が何もベアラケーパビリティをサポート

しない場合、MS は section 5.2.2.2 中で規定されるように、SETUP メッセージに対して RELEASE COMPLETE メッセ

ージを応答する。

UMTS では、完全性保護されたシグナリングは mandatory である（本仕様の詳細については、セクション 4.1.1.1.1 を

参照、概要については TS 33.102 を参照）。UMTS に限れば、全てのプロトコルが完全性保護されたシグナリングを

使用すること。全ての CC シグナリングメッセージの完全性保護は、下位レイヤが行う。完全性保護をアクティブに

するのはネットワークであり、セキュリティモード制御手順を使用して行う(TS 25.331)。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 149

呼制御プロトコルでは、複数の CC エンティティが定義される。それぞれの CC エンティティは、互いに独立であり、そ

の自分の MM コネクションを使用して、対応するピアエンティティと通信すること。異なる CC エンティティは、異なる

トランザクション識別子を使用する。

少数の例外を除いて、本技術仕様書では、2 つのピアエンティティに関する呼制御プロトコルについて記述する。呼制御エンティティは、無線インタフェースを通じてメッセージを交換し、他のプロトコルの(サブ)レイヤと内部で通信す

る、コミュニケーション有限ステートマシンとして説明される。その結果、外部で観察できる動作に関しては、本記述

は単に normative である。

2 つのピアエンティティのアクションの特定のシーケンスは、本セクション内の記載の論拠として使用される「基本的

処理」（"elementary procedures" ）から構成される。これらの基本処理は、以下のクラスに分類することができる。

- 呼の確立処理

- 呼のクリア処理

- 呼情報フェーズ処理

- その他の処理

MO（"mobile originating"または "mobile originated"）という用語は、呼が MS によって開始されたことを表すために

使用される。MT（"mobile terminating" または"mobile terminated"）いう用語は、呼がネットワークによって開始された

ことを表すために使用される。

図 5.1a/TS 24.008 に、MS 側の主なステートと遷移の概要を示す。

MS 側の拡張図 5.1a.1/TS 24.008 は、ステート U0$(CCBS)$からステート U1.0 に MS がどのように遷移するかを、ネ

ットワーク発信の MO 呼について示したものである。

図 5.1b/TS 24.008 は、ネットワーク側の主なステートと遷移の概要を示す。

ネットワーク側の拡張図 5.1b.1/ TS 24.008 は、MO はネットワークを呼ぶ、ステート N0$(CCBS)$からのステート

N1.0 に達する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)

Release 1999

150

MNCC-REL-CNFMMCC-REL-REQ

U19 RELEASE REQUEST

DR (REL) DR (REL)MNCC-DISC-IND

U11 DISCONNECT REQUEST

U12 DISCONNECT INDICATION

MNCC-SETUP-IND

U6CALL PRESENT

DR (CALL CONF)

U9 MT CALLCONFIRMED

DR (ALERT)MNCC-SYNC-IND (res.ass)

U7 CALLRECEIVED

DR (CONN)DR (CONN)

MNCC-DISC-IND

U8 CONNECT REQUEST

MNCC-SETUPCOMPL. IND

DR (DISC)

STATESU3,4,7,8,9,10

MMCC-EST-REQ

DR (REL. COM)MNCC-REL-INDMMCC-REL-REQ

DR (SETUP)

U1CALL INIT

MNCC-CALL.PROC.IND.

MNCC-PROGRESS. IND U3 MO CALL

PROCEEDING

MNCC-SYNC. IND(res. ass)

MNCC-ALERT-IND

U4 CALLDELIVERED

MNCC-SETUP-CNFDR (CONN ACK)

MNCC-SETUP-CNFDR (CONN ACK)

U10ACTIVE

MNCC-SETUP.REQ.

MMCC. EST. IND (SETUP)

MNCC-CALL.CONF.REQ.

MNCC-ALERT.REQ.

(*)MMCC.SYNC.IND.(res.ass.)

MNCC. SETUP. RSP.

MNCC. SETUP. RSP

DI (CONN ACK)

DI (DISC)

MNCC. REL.REQ.

MNCC. DISC.REQ.

DI (DISC)

DI (REL COM)

DI (CALL PROC)

DI (PROGRESS)

DI (CONN)

DI (ALERT)

DI (CONN)

MMCC.SYNC.IND(*)

(res. ass)

(*) early assignment

U0NULL

U0.1 MM CON-NECTION PENDING

DI (CONN)

DI (ALERT)

MNCC.EST.CNF

NOTE:DR(MESSAGE) = MMCC_DATA_REQ(MESSAGE)DI (MESSAGE) = MMCC_DATA_IND (MESSAGE)

DI (REL)

.

Figure 5.1a/TS 24.008: Overview

call control protocol/MS side

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 151

MNCC.PROM

U0NU

U0.2PROMPT

S

MMCC.PROM

U0.3WAIT FORO

U0.4CC-EST.

S

DR(S A CC

DR (CC ESTABLISHMENTCO )

MNCC.RECA

U1CALL

A

DR(S )

DI( CA )

DI (CCS A S )

MNCC.SETUQ

U0.CC_EST.CO

U0.6RECALL_PR

S

Figure5.1a.1/TS 24.008: Overview call control protocol/MS side, extension:

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)

Release 1999

152

N0NULL

MNCC.SETUP.IND. MMCC.EST.REQ.(mobile ID)

MNCC.REL.CNF.MMCC.REL.REQ.

N0.1 MM-CON-NECTION PENDING

DR (SETUP)

N6CALL PRESENT

MNCC.CALL.CONF.IND

N9 MT CALL CONFIRMED

MNCC.ALERT.IND

MNCC.SETUP.CNF.

N7 CALLRECEIVED

MNCC.SETUP.CNFN8 CONNECTREQUEST

DR (CONN ACK)

N19 RELEASEREQUEST

DR (REL COM),MNCC.REL.IND,MMCC.REL.REQ.

DR (REL)MNCC.DISC.IND

N12 DISCON-NECT INDICATION

DR (DISC)

N1CALL INIT

N3 MO CALLPROCEEDING

DR (PROGRESS)DR (ALERT)

DR (CONN)

N4 CALLDELIVERED

DR (CONN)

N28 CONNECTINDICATION

MNCC. SETUP.COMPL. IND.

N10ACTIVE

DR (CALL PROC)

MMCC.EST.IND (SETUP) MNCC. SETUP REQ.

MMCC. EST. CNF.

DI (CALL CONF)

DI (ALERT)DI (CONN)_

DI (CONN)

MNCC. SETUP.COMPL. REQ.

DI (CONN ACK)

MNCC. SETUP. RSP

MNCC. DISC. REQ.

DI (DISC)

DI (DISC)DI (REL)

DI (REL COM)

MNCC. CALL. PROC. REQ

MNCC. PROGRESS.REQ. MNCC.

SETUP. RSP

DR (REL)

STATES N1, 3, 4,7, 8, 9; 10, 28

MNCC ALERT REQ

NOTE:DR(MESSAGE) = MMCC_DATA_REQ(MESSAGE)DI (MESSAGE) = MMCC_DATA_IND (MESSAGE)

.

Figure 5.1b/TS 24.008 Overview

call control protocol/Netw

ork side

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 153

MNCC.CC_CONN.REQ

MMCC.CC_CONN.REQ

N0NULL

N0.2CC_CONN_PENDING

N0.3NW_ANSWER_PENDING

DR (CC_ESTABLISH)

N0.4CC-EST.PESENT

N0.5CC_EST. CONFIRMED

DR (RECALL)

N0.6RECALL_PRESENT

N1CALL_INITIATED

MMCC.EST.IND (START CC)

DI (CC_EST_CONF)

DI (SETUP)

Figure 5.1b.1/TS 24.008 Overview call control protocol/Network side, extension

5.1.2 Call Control States（呼制御ステート）

5.1.2.1 Call states at the mobile station side of the interface （インタフェースの MS側におけるコールステート）

本セクションでは、無線インタフェースの MS 側に存在する可能性のあるステートについて定義する。

NOTE: ステート U0.1、U0.2、U0.3、U0.4、U0.5、U0.6、U26 および U27 は、GSM 固有のステートである。他のす

べてのステートで定義される。

5.1.2.1.1 Null (State U0)

呼が存在しない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 154

5.1.2.1.2 MM Connection pending (U0.1)

本ステートは、MS 発信呼について、MS が MM コネクションの確立を要求する状態。

5.1.2.1.2a CC prompt present (U0.2) $(CCBS)$

本ステートは、MS 発信呼について、ネットワークが CC コネクションを確立するように MS に促したが、MS がまだ応

答していない状態。

NOTE: 本ステートは中間ステート

5.1.2.1.2b Wait for network information (U0.3) $(CCBS)$

本ステートは、MS 発信呼について、MS がネットワークからの CC コネクション確立指示に既に応答しており、MS が

ネットワークからのさらに詳細な情報を待っている状態。

5.1.2.1.2c CC-Establishment present (U0.4) $(CCBS)$

本ステートは、MS 発信呼について、MS が CC 確立リクエストを受信したが、まだ応答していない状態。


5.1.2.1.2d CC-Establishment confirmed (U0.5) $(CCBS)$

本ステートは、MS 発信呼について、MS が必要とする CC 情報をすべて MS が受信したという送達確認を送信した

状態。

5.1.2.1.2e Recall present (U0.6) $(CCBS)$

本ステートは、MS 発信呼について、MS が再発呼リクエストを受け取ったが、まだ応答していない状態。


5.1.2.1.3 Call initiated (U1)

本ステートは、MS 発信呼について、MS がネットワークから呼の確立をリクエストされた状態。

5.1.2.1.4 Mobile originating call proceeding (U3)

本ステートは、MS 発信呼について、ネットワークが有効な呼を確立するために必要な呼情報を受信したという送達

確認を、MS がネットワークから受信した状態。

5.1.2.1.5 Call delivered (U4)

本ステートは、MS 発信呼について、リモートユーザアラートが開始されたという通知を、発呼中の MS が受信した状

態。

5.1.2.1.6 Call present (U6)

本ステートは、MS 着信呼について、MS が呼確立リクエストを受信したが、まだ応答していない状態。

5.1.2.1.7 Call received (U7)

本ステートは、MS 着信呼について、MS が示した場合、MS がアラートを通知したが、まだ応答していない状態。

5.1.2.1.8 Connect Request (U8)

本ステートは、MS 着信呼について、MS が呼に応答し、呼が割当てられるのを待っている状態。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 155

5.1.2.1.9 Mobile terminating call confirmed (U9)

本ステートは、MS 着信呼について、MS が有効な呼を確立するために必要な呼情報を受信したという送達確認を、

MS がネットワークに送信した状態。

5.1.2.1.10 Active (U10)

本ステートは、MS 着信呼について、MS が呼に応答した場合のために存在する。本ステートは、MS 発信呼について、

リモートユーザが呼に応答したという通知を MS が受信した状態。

5.1.2.1.11 Disconnect request (U11)

本ステートは、MS がネットワークに対して、end-to-end のコネクション(もしあれば)のクリアを要求し、その応答を待っ

ている状態。

5.1.2.1.12 Disconnect indication (U12)

本ステートは、ネットワークが既に(もしあれば) end-to-end のコネクションをクリアしたために、ディスコネクトするため

の通知を MS が受信した状態。

5.1.2.1.13 Release request (U19)

本ステートは、MS がネットワークに開放を要求し、応答を待っている状態。

5.1.2.1.14 Mobile originating modify (U26)

本ステートは、MS がネットワークに新しいモードのリクエストを送信したが、まだ応答を受信したいない状態。

5.1.2.1.15 Mobile terminating modify (U27)

本ステートは、MS がネットワークから新しいモードのリクエストを受信したが、その要求に対する応答を未だ送信して

いない状態。

5.1.2.2 Network call states（ネットワークのコールステート）

NOTE: ステート N0.1、N0.2、N0.3、N0.4、N0.5、N0.6、N26、N27、N28、N3a、N4、a、N7a および N9a は、GSM 固

有のステートである。他のすべての ITU-T で定義される。

本セクションでは、無線インタフェースのネットワーク側でとりうるステートについて定義する。

5.1.2.2.1 Null (State N0)

呼が存在しない。

5.1.2.2.2 MM connection pending (N0.1)

本ステートは、MS 着信呼について、ネットワークが MM コネクションの確立を要求する状態。

5.1.2.2.2a CC connection pending (N0.2) $(CCBS)$

このステートは、MS 発信呼について、ネットワークが MS に CC コネクション確立を要求した状態。

5.1.2.2.2b Network answer pending (N0.3) $(CCBS)$

このステートは、MS 発信呼について、MS がネットワークのリクエストに応じて CC コネクションを確立したが、ネット

ワークが未だ MS に対してネットワークのアクションの理由を通知していない状態。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 156

5.1.2.2.2c CC-Establishment present (N0.4) $(CCBS)$

このステートは MS 発信呼について、ネットワークが CC 確立リクエストを送信したが、まだ満足な応答を受信してい

ない状態。

5.1.2.2.2d CC-Establishment confirmed (N0.5) $(CCBS)$

このステートは MS 発信呼について、MS が有効な呼を確立するために必要な情報を全て受信したという送達確認を

ネットワークが受信した状態。

5.1.2.2.2e Recall present (N0.6) $(CCBS)$

このステートは MS 発信呼について、ネットワークが再発呼リクエストを送信したが、まだ満足な応答を受信していな

い状態。

5.1.2.2.3 Call initiated (N1)

このステートは MS 発信呼について、ネットワークが呼確立リクエストを受信したが、まだ応答していない状態。

5.1.2.2.4 Mobile originating call proceeding (N3)

このステートは MS 発信呼について、ネットワークが呼確立を達成するのに必要な呼情報をすべて得たという送達確

認をネットワークが送信した状態。

5.1.2.2.5 Call delivered (N4)

このステートは MS 発信呼について、リモートユーザアラートが開始されたことをネットワークが通知した状態。

5.1.2.2.6 Call present (N6)

このステートは MS 着信呼について、ネットワークが呼確立リクエストを送ったが、まだ満足な応答を受信していない

状態。

5.1.2.2.7 Call received (N7)

このステートは MS 着信呼について、MS がアラートしているという通知をネットワークが受信したが、まだ応答を受

信していない状態。

5.1.2.2.8 Connect request (N8)

このステートは MS 着信呼について、ネットワークが応答を受信したが、ネットワークがまだ呼を与えていない状態。

5.1.2.2.9 Mobile terminating call confirmed (N9)

このステートは MS 着信呼について、MS が呼確立を達成するのに必要な呼情報をすべて得たという送達確認をネ

ットワークが受信した状態。.

5.1.2.2.10 Active (N10)

このステートは MS 着信呼について、ネットワークが発呼した MS に呼を与えた状態。このステートは MS 発信呼に

ついて、リモートユーザが呼に応答したことをネットワークが通知した状態。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 157

5.1.2.2.11 Not used

5.1.2.2.12 Disconnect indication (N12)

このステートは、ネットワークが(もしあれば)end- to-end のコネクションを切断し、もしくは MS がネットワークに対して

切断を送出した状態。

5.1.2.2.13 Release request (N19)

ネットワークが MS にリリースを要求し、その応答を待っている状態。

5.1.2.2.14 Mobile originating modify (N26)

ネットワークが MS から新しいモードへのリクエストを受信したが、まだ応答を送信していない状態。

5.1.2.2.15 Mobile terminating modify (N27)

ネットワークが新しいモードへのリクエストを MS に送信したが、まだ応答を受信していない状態。

5.1.2.2.16 Connect Indication (N28)

リモートユーザが呼に応答したことをネットワークが通知し、かつネットワークが MS による送達確認を待っている状

態。

5.2 Call establishment procedures（呼確立手順）呼の確立は、MS またはネットワーク内で、上位レイヤの要求によって開始される。以下の処理から構成される。

- MS とネットワーク間の CC コネクションの確立

- CODEC またはインターワーキング機能のアクティブ化

TS 24.008 内で規定される限り、第 5 章では MS はユーザコネクションにアタッチするものとする。これは、適切なチャ

ネルが利用可能になったならば直ちに、MS が CODEC またはインターワーキング機能をアクティブにすることを意

味する。適切なチャネルが利用可能でなくなったならば、MS は CODEC またはインターワーキング機能をデアクティ

ブにするものとする。適切なチャネルが（再び）利用可能な状態になったならばすぐに、CODEC またはインターワー

キング機能を再度アクティブにするものとする。ユーザコネクションをアタッチするようについる新しいオーダを受信し

たならば、新しいオーダは古いオーダに代わること。

チャネルが、呼の実際のフェーズにとって適切な、ネゴシエーションされる可能性のあるベアラケーパビリティと矛盾

しないならば、チャネルは適切であると見なされること。チャネルのタイプ（フルレート／ハーフレート）が MS の希望

するタイプと一致しないからといって、MS はチャネルが不適切であると見なしてはならない。もし、

- ユーザコネクションをアタッチしなくてはならないが、30 秒間連続して適切なチャネルが利用できなかった場合

- CODEC またはあるいはインターワーキング機能が、30 秒間連続してデアクティブにされた場合

この場合、MS は呼のクリアを開始することができる。

上位レイヤからの呼確立リクエストに応じて、呼確立のための制限条件が検査される。これらの制限条件は、パラレ

ルな CC エンティティのステートに関係があり、別の箇所で定義される。制限条件が満たされていた場合には、呼確

立が拒否される。それ以外の場合には、呼を確立するために、ステート U0"null"にある CC エンティティが選択され

る。それは、CC エンティティは MM サブレイヤに要求し、MM コネクションの確立を開始する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 158

5.2.1 Mobile originating call establishment（MS発信呼の確立） MS の呼制御エンティティは、MM サブレイヤに対して MS 発の MM コネクションの確立を要求し CC コネクション確

立を開始し、"MM connection pending"ステートに入る。MS 発信呼には 2 種類ある。すなわち、基本呼と緊急呼であ

る。 MM コネクションの確立リクエスト中には、呼が基本呼か緊急呼であるかを特定するためのパラメータが含まる

こと。この情報によって、MM サブレイヤが提供するサービスの特定の品質に結びつくこともある。 CM SERVICE REQUEST メッセージが送信されたとき、タイマーT303(Timer T303)が起動する。

eMLPP をサポートする MS については、基本呼がオプションとして GSM03.67 で定義される関連する優先度レベル

を持つこともできる。この情報は、さらに、MM サブレイヤが提供すべきサービスの特定の品質につながる場合もあ

る。

"MM connection pending"ステートにある間、MS の呼エンティティは、セクション 4.5.1.7 に与えられる規則に従って、

初の呼制御メッセージを送信する前に呼をキャンセルすることができる。

緊急呼を開始しているマルチ呼をサポートする MS は、MS 内に保存されているマルチ呼サポート情報（セクション

5.2.1.2 および 5.2.2.1 で説明される）が、ネットワークがマルチ呼をサポートしていないか、または進行中の既存の呼

があることを示していた場合には、1 つまたは複数の既存の呼を開放して、緊急呼が確立できるようにすること。

"MM connection pending"ステートに入ったならば、MM コネクション確立にあたって、MS の呼制御エンティティはそ

のピアエンティティにセットアップメッセージを送信する。

本セットアップメッセージは、

- 確立すべき呼が基本呼の場合、SETUP メッセージ

- 確立すべき呼が緊急呼の場合、EMERGENCY SETUP メッセージ

UMTS 音声呼については、bearer capability IE には UMTS スピーチバージョンが含まれてはならない。GSM と

UMTS をサポートし、GSM スピーチバージョン 1 以上をサポートする ME については、Bearer Capability IE 内に

GSM 用スピーチバージョンが含まれること。UMTS が確立した呼については、GSM にハンドオーバするに際して、

ネットワークはこれらの GSM スピーチバージョンを使用すること。UMTS 音声呼については、デフォルトの UMTS AMR スピーチバージョンを仮定すること。

そしてその後、 "call initiated"ステートに入る。タイマーT303(Timer T303)は停止しない。

セットアップメッセージには、ネットワークが呼を処理するために必要な情報がすべて含まれること。特に、 SETUP メ

ッセージは発番号（party address）と呼ばれる情報が含まれること。MS がマルチ呼をサポートする場合、SETUP メッ

セージは SI(Stream Identifier)IE が含まれること。初の呼の場合、つまり他に進行中の呼がない場合、SI の値は 1であること。

"MM connection pending"ステートでタイマーT303 が満了した場合、進行中の MM コネクションは中断され、ユーザ

に対して呼の拒否に関する情報が通知されること。

5.2.1.1 Call initiation （呼の開始）

"call initiated"ステートは、タイマーT303 によって監視される。通常の MO 呼の場合には、"MM connection pending"ステートに入った後に、このタイマーは既に起動されている。ネットワークが開始した MO 呼の場合、セクション

5.2.3.4 中で定義される”recall present“ステートで本タイマが起動される。

MS の呼制御エンティティが"call initiated"ステートにあり、かつ、

i) CALL PROCEEDING メッセージを受信した場合には、MS の呼制御エンティティはセクション 5.2.1.3 で説明さ

れる処理を行うこと。

ii) ALERTING メッセージを受信した場合には、MS の呼制御エンティティはセクション 5.2.1.5 で説明される処理

を行うこと。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 159

iii) CONNECT メッセージを受信した場合には、MS の呼制御エンティティはセクション 5.2.1.6 で説明される処理

を行うこと。

iv) RELEASE COMPLETE メッセージを受信した場合には、MS の呼制御エンティティはセクション 5.2.1.2 で説明

される処理を行うこと。

異常なケースとして、

- CALL PROCEEDING、ALERTING、CONNECT あるいは RELEASE COMPLETE メッセージのいずれかを

受信する前に、"call initiated"ステートでタイマーT303 が満了した場合には、セクション 5.4 で説明されたクリ

ア処理が実行される。

5.2.1.2 Receipt of a setup message（セットアップメッセージの受信）

"null" もしくは "recall present"ステートにおいて、セットアップメッセージ(SETUP メッセージあるいは EMERGENCY SETUP メッセージ、セクション 5.2.1.1 を参照)を受信したならば、ネットワークの呼制御エンティティは"call initiated"ステートに入る。エンティティはその後、セットアップメッセージに含まれる呼情報を解析すること。

UMTS では、ネットワークは SETUP メッセージ中で受信した SI を RAB 識別子の中に入れて、MS に送り返すこと。

RAB 識別子については、TS 25.413 を参照。ネットワークが SI のない SETUP メッセージを受信した場合には、ネッ

トワークは SI 値を 1 にセットすること。

i) セットアップメッセージの受信に続いて、ネットワークの呼制御エンティティが MS から受信した呼情報が無効

である（例えば無効な番号など）と判断したならば、ネットワークは以下の理由値のいずれか 1 つといっしょに、

セクション 5.4 に定義された呼のクリアを開始すること。

# 1 "unassigned (unallocated) number"（割当てられていない（配置されてない）番号）

# 3 "no route to destination"（目的地までのルートがない）

# 22 "number changed"（変更された番号）

# 28 "invalid number format (incomplete number)"（無効な番号フォーマット（不完全な番号））

ii)セットアップメッセージの受信に続いて、ネットワークの呼制御エンティティが要求されたサービスが許可されて

いない、または無効であると判断したならば、ネットワークは以下の理由値のいずれか 1 つといっしょに、セク

ション 5.4.2 に定義された呼のクリアを開始すること。

# 8 "operator determined barring"（オペレータが決定した禁止）

# 57 "bearer capability not authorized"（許可されていないベアラケーパビリティ）

# 58 "bearer capability not presently available"（現在利用不可能なベアラケーパビリティ）

# 63 "service or option not available, unspecified"（サービスまたはオプションが利用不可、特定できない）

# 65 "bearer service not implemented"（実装されていないベアラケーパビリティ）

iii) それ以外の場合には、ネットワークの呼制御エンティティは、以下のいずれかの処理を行うこと。

- そのピアエンティティに CALL PROCEEDING メッセージを送信し、呼が処理中であることを通知し、

"mobile originating call proceeding"ステートに入る。

- そのピアエンティティに ALERTING メッセージを送信し、発呼ユーザ側でアラート処理が開始されたことを

通知し、"call received"ステートに入る。

- そのピアエンティティに CONNECT メッセージを送信し、発呼ユーザ側で呼が受け付けられたことを通知し、

"connect request "ステートに入る。

ネットワークの呼制御エンティティは、CALL PROCEEDING メッセージ内にの bearer capability IE を挿入し、

MS が SETUP メッセージの Bearer Capability IE で提示したオプションを選択することができる。選択を提示し

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 160

たパラメータを除き、bearer capability IE には、SETUP メッセージの中で受信したのと同じパラメータが含まれ

ること。選択が提示された場合には、これらの選択の結果を示すための適切なパラメータが含まれること。

EMLPP が適用されるならば、ユーザがリクエストしたのとは異なる優先度をネットワークが呼に対して割当て

た場合、またはユーザが優先度をリクエストせずにネットワークがデフォルトの優先度を割当てた場合には、

CALL_PROCEEDING メッセージもまた呼の優先度を含むこともできる。eMLPP をサポートする MS は、この

優先度レベルをより高いサブレイヤに通知し、呼の間この情報を別のアクションのために保存すること。

eMLPP をサポートしない MS は、CALL PROCEEDING メッセージ中で本 IE が提供されたならば、それを無

視すること。

- ネットワークがマルチ呼をサポートし、かつ MS に対する進行中の他の呼がない場合、

CALL_PROCEEDING メッセージはネットワーク呼制御ケーパビリティ内のマルチ呼サポート情報を含むこと。

マルチ呼をサポートする MS は、すべての呼のための呼制御ステートが null に戻るまで、本情報を保存する

こと。マルチ呼をサポートしない MS は、CALL PROCEEDING メッセージの中で本 IE が提供されたならば、

それを無視すること。CALL_PROCEEDING メッセージ中でマルチ呼サポート情報が送信されなかった場合、

マルチ呼をサポートする MS は、ネットワークはマルチ呼をサポートしないと判断すること。

"mobile originating call proceeding"ステートに既に入ったネットワーク呼制御エンティティは、セクション 5.2.1.9 に従

って、トラフィックチャネルの割当てを開始することができる(初期割り当て)。

UMTS 音声呼については、bearer capability IE には UMTS スピーチバージョンが含まれてはならない。デフォルトの

UMTS AMR スピーチバージョンであると仮定すること。

ネットワークは、Bearer Capability IE 内でネットワークが受信した GSM スピーチバージョンを使用して GSM 呼の確

立と GSM へのハンドオーバを行うこと。Bearer Capability IE 内にスピーチバージョンが含まれていない場合の GSM音声呼については、ネットワークは GSM スピーチバージョンを 1 と仮定すること。

Figure 5.2/TS 24.008 Mobile originated call initiation and possible subsequent responses.

5.2.1.3 Receipt of a CALL PROCEEDING message （CALL PROCEEDINGメッセージの受信）

MS の呼制御エンティティが CALL PROCEEDING メッセージを受信した際に、"call initiated"ステートに入っていた

場合には、MS はタイマーT303 を停止させ、タイマーT310 を起動する。ただし、以下の場合を除く。

- CALL PROCEEDING メッセージに、進行説明#1, #2,または#64 を規定する progress indicator IE が含まれて

いた場合

- MS が CALL PROCEEDING メッセージの前に、進行説明#1, #2,または#64 を規定する progress indicator IEが含まれている PROGRESS メッセージを受信した場合

そして、"mobile originating call proceeding"ステートに入る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 161

異常なケース

ALERTING、CONNECT あるいは DISCONNECT メッセージのうちのいずれかを受信する前に、タイマ T310が満了した場合、MS はセクション 5.4 に記述されたクリア処理を実行すること。

Figure 5.3/TS 24.008 MS 発信呼確立時の呼処理シーケンス発信呼確立時の呼処理シーケンス発信呼確立時の呼処理シーケンス発信呼確立時の呼処理シーケンス（（（（Call proceeding sequence at mobile originating call establishment））））

5.2.1.4 Notification of progressing mobile originated call （MS発信呼の処理の通知）

このセクションでは、"interworking"という用語は、" PLMN または ISDN 以外のネットワークとのインターワーキング

を指し、PLMN と ISDN 間のインターワーキングは通常のケースであるので"interworking"という用語は使用しない。

この意味で、PLMN と ISDN は、PLMN/ISDN 環境と呼ばれる同一環境にあると見なされる。

5.2.1.4.1 Notification of interworking in connection with mobile originated call establishment （MS発信呼の確立との関係におけるインターワーキングの通知）

呼確立中に、呼が PLMN/ISDN 環境を離れる場合もある。例えば非 PLMN/ISDN ユーザと別のネットワークでイン

ターワーキングするため、または発呼したユーザの家屋敷内の非 PLMN/ISDN 設備とインターワーキングするため

に。そのような状況が発生した場合、ネットワークは発呼中の MS に対して、以下のいずれかのメッセージ内で

progress indicator IE を送信することができる。

a) ステート変更が要求された場合には、適切な呼制御メッセージ（例えば ALERTING または CONNECT）内で

b) ステート変更が使用されない場合には、PROGRESS メッセージ内で

この progress indicator IE には、以下の進行説明値のいずれか 1 つが含まれること。

a) #1 "call is not end-to-end PLMN/ISDN; further call progress information may be available in-band". （呼は end-to-end の PLMN/ISDN ではない：インバンドでさらに呼進行情報が利用可能）

b) #2 "destination address is non-PLMN/ISDN". （宛先アドレスは非 PLMN/ISDN）

c) #4 "call has returned to PLMN/ISDN. （呼が PLMN/ISDN に戻された）

これ以上の MS のリアクションについては、セクション 5.5.1、および 5.5.6 を参照。

5.2.1.4.2 Call progress in the PLMN/ISDN environment （PLMN/ISDN環境内の呼の進行）

呼が PLMN/ISDN 環境内で処理されていることを MS に通知するために、ネットワークは以下のいずれかのメッセー

ジ内で、progress indicator IE を送信することもできる。

a) ステート変更が要求された場合には、適切な呼制御メッセージ（例えば ALERTING または CONNECT）内で

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 162

b) ステート変更が使用されない場合には、PROGRESS メッセージ内で

この progress indicator IE には、進行説明値#32 "Call is end-to-end ISDN/PLMN"が含まれること。これ以上の MSのリアクションについては、セクション 5.5.6 を参照。

5.2.1.5 Alerting（アラート処理）

"mobile originating call proceeding"ステートに入った後で、発呼アドレスにおいて、ユーザアラートが開始されたとい

う通知を受信したならば、ネットワークの呼制御エンティティは以下のことを行うこと。：すなわち、発呼 MS において

そのピアエンティティに ALERTING メッセージを送信し、"call delivered"ステートに入ること。

"call initiated" ステート、または "mobile originating call proceeding"ステートにある MS の呼制御エンティティが、

ALERTING メッセージを受信した場合には、MS の呼制御エンティティはタイマ T303 および T310(起動している場

合)を停止し、"call delivered" ステートに入ること。音声呼に関しては、このステートで、：

- ユーザにアラート通知を与えること。MS がまだユーザコネクションをアタッチしていない場合には、MS は内部

でアラート通知を生成すること。 MS が既にユーザコネクションをアタッチしている場合には、ネットワークがア

ラート通知の生成を行い、MS はそれを生成してはならない。

Abnormal cases:（異常なケース）

MS 側でタイマ T310 が満了した場合、MS の呼制御エンティティはセクション 5.4 に記述されるような呼のクリ

アを開始すること。

Figure 5.4/TS 24.008 Call confirmation at mobile originating call establishment

5.2.1.6 Call connected（コネクトされた呼）

呼が受理されたという通知を受信したならば、ネットワークの呼制御エンティティは以下のことを行うこと。すなわち、

トラフィックチャネル（もし要求されたならばインターワーキング機能のコネクションを含む）を接続する過程で、発呼中

MS においてそのピアエンティティに CONNECT メッセージを送信する：タイマ T313 を起動して"connect indication" ステートに入る。

このメッセージは、ネットワーク経由でコネクションが確立されたことを、発呼中 MS の呼制御エンティティに通知する。

"call initiated"ステート、"mobile originating call proceeding" ステート、または"call delivered"ステートにある MS の呼

制御エンティティは、CONNECT メッセージを受信したならば、以下の処理を行うこと。

- ユーザコネクションをアタッチする

- CONNECT ACKNOWLEDGE メッセージを返す

- （もし適用されているならば）ローカルに生成されたアラート通知を停止する

- （起動しているならば）タイマ T303 および T310 を停止する

- "active"ステートに入る

異常なケース

MS 側でタイマ T303 あるいは T310 が満了した場合には、MS の呼制御エンティティはセクション 5.4 に記述さ

れるような呼のクリアを開始するものとする。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 163

注：MS が追加的内部アラート処理監視を適用しており、それが原因となって T303 または T310 の満了に先立って

呼のクリアが開始される場合もある。

"connect indication"ステートにあるネットワークの呼制御エンティティは、CONNECT ACKNOWLEDGE メッセージを

受信したならば、

- タイマ T313 を停止させ、"active"ステートに入ること

異常なケース

ネットワーク側で、CONNECT ACKNOWLEDGE メッセージを受信する前にタイマ T313 が満了した場合には、

ネットワークはセクション 5.4 に記述されるようなクリア処理を実行すること。

Figure 5.5/TS 24.008 Call acceptance sequence at mobile originating call establishment

5.2.1.7 Call rejection（呼の拒否）

ネットワークまたは呼ばれたユーザが呼を受理することができないという通知を受信したならば、セクション 5.4 に記

述されるように、ネットワークは着信ネットワークまたは呼ばれたユーザによって提供された理由（値）を使用して、発

呼した MS に対して無線インタフェース上で呼のクリア処理を開始すること。

5.2.1.8 Transit network selection（トランジットネットワークの選択）

NOTE: For further study.

5.2.1.9 Traffic channel assignment at mobile originating call establishment （MS発信呼の確立におけるトラフィックチャネルの割当て）

マルチ呼をサポートする MS は、SETUP メッセージに流れ識別子(Stream Identifier)(SI)を含んでいる。ネットワーク

をサポートするマルチ呼は以下のように SI 値を解釈すること:

a) MS は発呼を開始するに際して新しい SI 値を生成し、そして発呼した MS に対して新しいトラフィックチャネル

が割当てられること

b) MS は既存の SI 値を通知し、そして発呼した MS は通知されたトラフィックチャネルを使用すること。

マルチ呼をサポートする MS は、マルチ呼をサポートしないネットワークに対して、新しいトラフィックチャネルが要求

されているという通知といっしょに、追加 SETUP を送信してはならない。

MS 発信呼確立フェーズ中のどの段階で適切なトラフィックチャネルの割当てを行うかは、ネットワークに依存する決

定である。適切なトラフィックを割当てるための適切な RR 処理の開始は、呼制御エンティティのステートも変更しな

いし、またどの呼制御タイマにも影響を与えない。

注：そのような RR 手続きの特定のフェーズ中で、CC メッセージおよび MM のメッセージの送信をサスペンドするこ

とができる。GSM04.18、第 3 章、および GSM08.08 参照。

割当て処理は呼制御タイマに影響しない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 164

5.2.1.10 Call queuing at mobile originating call establishment （MS発信呼の確立における呼のキューイング）

キューイングに適用する条件は、GSM 03.01 に記載される。

割当て時に、アイドルトラフィックチャネルが利用可能な状態にない場合、ネットワークはトラフィックチャネルリクエス

トをキューに置くことができる。キューの全ポジションが占有されたときに届いた呼は、理由値#34 "no circuit/channel available"を使用してネットワークによってクリアされる。

大キューイング間隔は、ネットワークによって監視される。上限はネットワークの選択に委ねられる。キューの限度

内でネットワークがトラフィックチャネルを割当てることができない場合には、ネットワークは理由値#34"no circuit/channel available"を使用して、呼をリリースする。

オプションとして、例えば eMLPP を使用する場合には、ネットワークは既存の呼を阻止するか、またはキュー内の優

先位置にトラフィックチャネルリクエストを置くか、決定することができる。

ネットワーク中でリモートユーザに提供される特定の通知は、ネットワークの選択に委ねられる。

5.2.2 Mobile terminating call establishment（MS着信呼の確立） MS 内で呼確立を開始する前に、ネットワークは MM コネクションを確立しなければならない。

5.2.2.1 Call indication（呼の通知）

リモートユーザからの呼が到着した後に、ネットワーク中の対応する呼制御エンティティは次のことを行うこと。第 4章に従い MM コネクション確立を開始し、"MM connection pending"ステートに入ること。MM コネクション確立リクエ

ストは、 CM サブレイヤから MM サブレイヤにパスされる。確立リクエストには、SETUP メッセージから誘導された必

要なルーチング情報が含まれる。

MM コネクションが確立せれたならば、ネットワークの呼制御エンティティは次のことを行うこと。MS でそのピアエン

ティティに SETUP メッセージを送信し、タイマ T303 を起動し、"call present"ステートに入る。

ネットワークがマルチ呼をサポートし、かつその MS で進行中の他の呼がない場合には、SETUP メッセージにネット

ワーク呼制御ケーパビリティ内のマルチ呼サポート情報が含まれること。すべての呼の呼制御ステートが NULL に

戻るまで、マルチ呼サポート MS はこの情報を保存すること。マルチ呼をサポートしない MS は、もし SETUP メッセ

ージ中でこの情報が提供されたならばそれを無視すること。 SETUP メッセージ中でマルチ呼サポート情報が送信さ

れなかった場合には、マルチ呼をサポートする MS はネットワークがマルチ呼をサポートしないと判断すること。

SETUP メッセージを受信した MS は、セクション 5.2.2.2 に記述される互換性検証を実行すること。互換性チェックの

結果、互換性があった場合には、MS の呼制御エンティティは"call present" ステートに入ること。非互換 MS は、セ

クション 5.2.2.3.4 に従って RELEASE COMPLETE メッセージを応答すること。

タイマ T303 が満了する前に、ネットワークの呼制御エンティティが SETUP メッセージに対する応答を受信しなかった

場合には、セクション 5.2.2.3.3 に記述された処理を適用すること。

Figure 5.6/TS 24.008 Mobile terminating call initiation and possible subsequent responses.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 165

5.2.2.2 Compatibility checking（互換性チェック）

SETUP メッセージを受信した MS は、その SETUP メッセージに応答する前に互換性チェックを実行すること。 Annex B に、SETUP メッセージの受信に際して MS が実行すべき互換性チェックを定義する。

5.2.2.3 Call confirmation（呼の確認）

5.2.2.3.1 Response to SETUP（SETUPへの応答）

"call present state"ステートに入った後に、MS の呼制御エンティティは SETUP メッセージに対する送達確認として

CALL CONFIRMED メッセージを送信し（下記に記述する例外を除く）、mobile terminating call confirmed"ステートに

入ること。

MS がマルチ呼をサポートする場合には、CALL CONFIRMED メッセージ中に SI(Stream Identifier)IE が含まれるこ

と。

- MS がマルチ呼をサポートするネットワーク内に在圏する場合、使用中の SI が含まれてはならない。以下の

いずれかの値が含まれること。：

- SI="no bearer"（ベアラなし）

- SI=new value (not used by any of the existing bearers)（新しい値（既存ベアラが使用してない値））

マルチ呼をサポートする MS が、マルチ呼をサポートしないネットワークに在圏する場合、それは値 1 の SI が含まれ

ること。

MS の呼制御エンティティは、ネットワークに対する CALL CONFIRMED メッセージの中で、1 つまたは複数の bearer capability IE を含めることができる。MS 内で事前選択された値、またはサービスに依存するディレィトリ番号(TS 29.007 参照)のどちらかである。 MS はまた、無線インタフェースの要求条件を定義するために、1 つまたは複数の

bearer capabilityを CALL CONFIRMED メッセージ中に入れることもできる。UMTS 音声呼については、bearer capability IE には UMTS スピーチバージョンが含まれてはならない。 GSM と UMTS をサポートし、かつ GSM スピ

ーチバージョン 1 以上をサポートする ME の場合、GSM 用スピーチバージョンが Bearer Capability IE に含まれるこ

と。 UMTS で確立された呼の場合、これらの GSM 用スピーチバージョンはネットワークが GSM へハンドオーバする

際に使用されること。UMTS 音声呼については、デフォルトの UMTS AMR のスピーチバージョンを仮定すること。以

上いずれの場合にも、セクション 9.3.2.2 で規定された規則に従うものとする。

NOTE: 代替応答の可能性（例えば付加サービス関連）については、FFS。

SETUP メッセージ中で通知された互換性要求条件を満たすビジーな MS は、呼セットアップの継続が許容される場

合には CALL CONFIRMED メッセージで、呼セットアップの継続が許容されない場合には RELEASE COMPLETEメッセージで応答すること。いずれの場合にも、理由値#17 で "user busy"を付けること。

モバイルユーザが呼を拒否したい場合には、理由値#21"call rejected"で RELEASE COMPLETE メッセージを送信

すること。

SETUP メッセージに対する応答として、MS が RELEASE COMPLETE メッセージを送信した場合には、MS は

RELEASE COMPLETE メッセージ送信完了後に MM コネクションを開放し、"null"ステートに入ること。

ネットワークはセクション 5.4 の記載に従って、RELEASE COMPLETE メッセージを処理すること。

5.2.2.3.2 Receipt of CALL CONFIRMED and ALERTING by the network （ネットワークによる CALL CONFIRMED と ALERTINGの受信）

"call present"ステートにあるネットワーク呼制御エンティティは、CALL CONFIRMED メッセージを受信したならば、タ

イマ T303 を停止し、タイマ T310 を起動し、"mobile terminating call confirmed" ステートに入ること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 166

UMTS では、ネットワークが、CALL CONFIRMED メッセージ中で受信した SI を RAB 識別子に入れて、それを MSに送り返すこと。 RAB 識別子については、TS 25.413 を参照。ネットワークが SI のない CALL CONFIRMED メッセ

ージを受信した場合、ネットワークは SI 値を 1 にセットすること。

UMTS 音声呼については、bearer capability IE 内に UMTS スピーチバージョンが含まれてはならない。デフォルトの

UMTS AMR のスピーチバージョンを仮定すること。

ネットワークが Bearer Capability IE 内で受信した GSM スピーチバージョンは、ネットワークが GSM 呼確立と GSMへのハンドオーバのために使用すること。bearer capability IE 内にスピーチバージョンが含まれない GSM 音声呼の

場合、ネットワークが GSM スピーチバージョンを 1 と仮定すること。

"mobile terminating call confirmed" ステートに入った MS の呼制御エンティティは、着信ユーザ側で呼が受理された

場合には、MS はセクション 5.2.2.5 に記述された手順を進める。着信ユーザ側で呼が拒否された場合には、SETUPメッセージ内にシグナル IE がある場合には、ユーザアラート処理が MS 側で開始される。SETUP メッセージ内にシ

グナル IE がない場合には、適切なチャネルが利用可能になった時点でユーザアラートが開始される。

ユーザアラートを開始するということは、以下のことを意味する。

- MS で、適切なトーンあるいは通知を生成すること、および

- MS の呼制御エンティティが ALERTING メッセージをネットワーク内のそのピアエンティティに送信し、"call received"ステートに入ること。

"mobile terminated call confirmed"ステートにあるネットワーク呼制御エンティティは、ALERTING メッセージを受信し

たならば、呼出されいるユーザに対応する ALERTING 通知を送信し、タイマ T310 を停止し、タイマ T301 を起動し、

"call received"ステートに入ること。

"mobile terminating call confirmed" ステートまたは "call received"ステートにある MS は、MS のユーザが User Determined User Busy であったならば、理由値#17"user busy"で DISCONNECT メッセージを送信すること。"mobile terminating call confirmed" ステートにある MS は、MS のユーザが呼を拒否したければ、理由値#21"call rejected"でDISCONNECT メッセージを送信すること。

5.2.2.3.3 Call failure procedures（呼確立失敗処理）

異常な動作のケースには、以下の処理が適用される。

i. タイマ T303 が満了する前に、ネットワークが SETUP メッセージに対する応答を受信しない場合には、ネットワ

ークは、理由値#18"no user responding"で発呼ユーザに対する呼のクリア処理を開始し、理由値

#102"recovery on timer expiry"を使用して、コールされた MS に対するクリア処理をセクション 5.4.4 に従って

開始すること。

ii. ネットワークが CALL CONFIRMED メッセージを受信したが、タイマ T303 が満了する前に ALERTING, CONNECT または DISCONNECT メッセージのいずれも受信しなかった場合には、ネットワークは以下の処

理を行うこと。

- 理由値#18"no user responding"で発呼ユーザに対する呼のクリア処理を開始し、

- 理由値#102"recovery on timer expiry"を使用して、コールされた MS に対するクリア処理をセクション 5.4.4に従って開始

iii. ネットワークが ALERTING メッセージを受信したが、タイマ T301(あるいは対応する内部のアラート監視タイミ

ング機能)が満了する前に CONNECT または DISCONNECT のメッセージを受信しなかった場合には、ネット

ワークは、理由値#19"user alerting, no answer"で発呼ユーザに対する呼のクリア処理を開始し、理由値

#102"recovery on timer expiry"または理由値 #31 "normal, unspecified"を使用して、セクション 5.4.4 に従って

コールされた MS に関するクリア処理を開始すること。

NOTE: 理由値#31 と#102 の選択は、MS が生成する通知に大きな影響を及ぼすことがある。GSM 02.40 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 167

5.2.2.3.4 Called mobile station clearing during mobile terminating call establishment （MS着信呼の確立中のコールされた MSのクリア）

セクション 5.4.2 参照。

5.2.2.4 Notification of interworking in connection with mobile terminating call establishment （MS着信呼の確立と関連するインターワーキングの通知）

このセクション中では、「インターワーキング」という用語は、 PLMN または ISDN 以外のネットワークとのインターワ

ーキングを意味するためだけに使用され、PLMN と ISDN 間のインターワーキングは正常なケースなので意味しな

い。この意味で、PLMN と ISDN は同一環境内にあるものと見なされ、PLMN/ISDN 環境と呼ばれる。

呼確立中に、呼が PLMN/ISDN 環境に入る場合もある。例えば非 PLMN/ISDN ユーザと別のネットワークでインタ

ーワーキングするため、または発呼中のユーザまたはコールされたユーザの家屋敷内の非 PLMN/ISDN 設備とイ

ンターワーキングするために。そのような状況が発生した場合、ネットワークはコールされた MS に対して、SETUP メ

ッセージ内で progress indicator IE を送信することができる。以下の progress description 値が規定される。

a) #1 "call is not end-to-end PLMN/ISDN; further call progress information may be available in-band" or （呼が end-to-end PLMN/ISDN でない。より多くの呼進行情報がインバンドで利用可能）

b) #3 "origination address is non-PLMN/ISDN". （発呼アドレスが非 PLMN/ISDN）

これ以上の MS 側のアクションについては、セクション 5.5.1 を参照。

5.2.2.5 Call accept（呼試行）

"mobile terminating call confirmed" ステートまたは"call received"ステートにおいて、MS 内の呼制御エンティティは

MS 着信呼を受け付けたことを以下のように通知する。

- ネットワーク内のピアエンティティに CONNECT メッセージを送信

- タイマ T313 を起動

- "connect request"ステートに入る

MS の呼制御エンティティに対して、CALL CONFIRMED メッセージ中の SI 値で"No Bearer"が通知された場合には、

MS は SI 値を割当てて、CONNECT メッセージに内に SI IE を含めること。それ以外の場合には、CONNECT メッセ

ージに内に SI IE を含めてはならない。

5.2.2.6 Active indication（アクティブ通知）

"mobile terminated call confirmed"ステートまたは "call received"ステート内で、ネットワークの呼制御エンティティは

CONNECT メッセージを受信したならば、トラフィックチャネル(要求された場合にはインターワーキング機能のコネク

ションを含める)をスルーコネクトし、 (起動されているならば) タイマ T310、T303 あるいは T301 を停止し、コールされ

たユーザの MS のピアエンティティに CONNECT ACKNOWLEDGE メッセージを送信し、呼出し中ユーザに

CONNECT メッセージを送信し、"active"ステートに入る。

"connect request"ステート内で、MS の呼制御エンティティは、CONNECT ACKNOWLEDGE メッセージを受信したな

らば、タイマ T313 を停止し、"active"ステートに入る。

CONNECT ACKNOWLEDGE メッセージを受信する前にタイマ T313 が満了した場合、MS はセクション 5.4.3 に従っ

て呼のクリアを開始するものとする。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 168

Figure 5.7/TS 24.008 Call acceptance and active indication at mobile terminating call establishment

5.2.2.7 Traffic channel assignment at mobile terminating call establishment （MS着信呼の確立におけるトラフィックチャネル割当て）

SETUP メッセージ受信後、マルチ呼をサポートする MS は新しいトラフィックチャネルを要求するか、あるいは既存の

トラフィックチャネルを再使用することができる。

マルチ呼をサポートするネットワーク内の MS が、新しいトラフィックチャネルを要求する場合、MS は、

- 既存のトラフィックチャネルが使用していない新しい値の SI を含む CALL CONFIRMED メッセージを送信す

ること。

マルチ呼をサポートするネットワーク内の MS が、新しいトラフィックチャネルを要求しない場合、MS は、

- "no bearer"に等しい値の SI を含む CALL CONFIRMED メッセージを送信すること。

MS が、SI="no bearer"の CALL CONFIRMED メッセージを送信した後、ネットワークは CONNECT メッセージ中の

SI 値を見て、ユーザが新しいトラフィックチャネルを要求しているか、または既存のチャネルを再利用しようとしている

かを判定する。

ユーザによって新しいトラフィックチャネルが要求された場合、マルチ呼をサポートするネットワーク内の MS は、

- 既存のトラフィックチャネルが使用していない、新しい値の SI を含む CONNECT メッセージを送信すること。

ユーザが、既存のトラフィックチャネルを再利用することを決定した場合、マルチ呼をサポートするネットワーク内の

MS は、

- SI を既存のトラフィックチャネルが使用している既存の値に設定して、CONNECT メッセージを送信すること。

モバイル着信呼の確立のどのフェーズで、トラフィックチャネルの割当てを開始するかは、ネットワークが決定する。

割当てフェーズの開始によって、直接 CC エンティティのステートが変更されることはなく、また呼制御タイマに影響を

与えることもないが、いくつかの二次的な影響を及ぼす場合もある（例えば節 5.2.2.3.2 など参照）。

5.2.2.8 Call queuing at mobile terminating call establishment （モバイル着信呼確立に際しての呼のキューイング）

セクション 5.2.1.10 に記述された原則が適用される。

NOTE: 固定ネットワークへのインターワーキングは、ネットワーク固有の要求条件を満足しなければならない。

5.2.2.9 User connection attachment during a mobile terminating call （モバイル着信呼の間のユーザコネクションアタッチメント）

音声呼の場合、

遅くとも CONNECT メッセージを送る時までに、MS はユーザコネクションをアタッチすること。

データ呼の場合、

ネットワークから CONNECT ACKNOWLEDGE メッセージを受信したときに、MS はユーザコネクションをアタッチ

すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 169

5.2.3 Network initiated MO call $(CCBS)$ （ネットワークがMO call $(CCBS)$を開始した場合）

セクション 5.2.3 の処理は、"Network initiated MO call"をサポートしている MS にとっては mandatory である。

NOTE: "Network initiated MO call"をサポートしない MS の動作については,第 4 章で説明される。

5.2.3.1 Initiation（開始）

MS の中で呼確立を開始する前に、ネットワークは MM コネクションを確立すること。

適切な刺激（例えば Remote User Free Indication）が到着した後、ネットワーク内の対応する呼制御エンティティは、

第 4 章の記載に従って MM コネクションの確立を開始し、"CC connection pending"ステートに入り、タイマ T331 を起

動すること。 MM コネクションの確立要求は、CM サブレイヤから MM サブレイヤにパスされる。確立要求には、受

信される刺激から誘導された、必要なルーチング情報を含んでいる。

MM コネクションが正常に確立されたならば、MS の呼制御エンティティはネットワーク中のそのピアエンティティに

START CC メッセージを送ること。その後、MS は"Wait for network information"ステートに入り、タイマ T332 を起動

すること。

"CC connection pending"ステートでネットワークが START CC メッセージを受信した場合、ネットワークはタイマ T331を停止し、CC-ESTABLISHMENT メッセージを送信し、タイマ T333 を起動し、the "CC-establishment present"ステー

トに入る。

各種の原因によって MM コネクションの確立が失敗した場合、ネットワーク中の MM サブレイヤは、ネットワーク中

の CC エンティティにに対して、コネクション確立の失敗の理由通知を通知する。その後、CC エンティティは起動中

のタイマをすべて停止し、"Null"ステートに入り、ネットワーク内の全ての適切なエンティティに通知すること。

タイマ T331 が満了した場合、ネットワークは MM コネクション確立試行を中断し、起動中の CC タイマをすべて停止

させ、止める、"Null"ステートに入り、ネットワーク内の全ての適切なエンティティに通知すること。

5.2.3.2 CC-Establishment present

"CC establishment present" ステートにおいて、MS が CC-ESTABLISHMENT メッセージを受信したならば、タイマ

T332 を停止させること。

CC-ESTABLISHMENT メッセージには、この CC-ESTABLISHMENT と関連する後続 SETUP メッセージ(もしあれ

ば)のために MS が使用する特定の情報が含まれる。

CC-ESTABLISHMENT メッセージには、Setup Container IE が含まれること。

タイマ T332 が満了する前に、、MS の呼制御エンティティが CC-ESTABLISHMENT メッセージを受信しなかった場

合には、MS は理由値#102 "recovery on timer expiry" の RELEASE COMPLETE メッセージを使用してネットワーク

に対するクリア処理を開始すること。そして、セクション 5.4.2 に従って処理を進めること。

MS は CC-ESTABLISHMENT メッセージを受信したならば、Setup Container IE のチェックを実行し、そこに含まれる

情報が MS の現行のケーパビリティとコンフィギュレーションと整合するか否かを検査すること。"recall alignment procedure"については、本セクション後半で定義される。

recall alignment procedure が正常終了したならば、MS の呼制御エンティティは、

- SETUP メッセージを生成し、後で"Recall present"ステートになったときに送信するために保存すること

- CC-ESTABLISHMENT メッセージの送達確認として、CC-ESTABLISHMENT CONFIRMED メッセージを

送信すること

- タイマ T335 を起動させること

- "CC-establishment confirmed"ステートに入ること

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 170

例外

recall alignment procedure を正常終了したビジーMS は、理由値#17"user busy"の CC-ESTABLISHMENT CONFIRMED メッセージで応答すること。そして上述の処理を進めること。

recall alignment procedure に失敗した MS は、セクション 5.4.2 の記載に従って、the recall alignment procedure の記

述の中で示されるような適切な理由値といっしょに、RELEASE COMPLETE メッセージで応答すること。

SETUP メッセージは、CC ESTABLISHMENT メッセージ内で受信した Setup Container IE から構成される。 MS は、

Setup Container IE には、PD(Protocol Discriminator)、トランザクション ID(Transaction ID)、およびメッセージタイプ

(Message Type)エレメント以外の完全な SETUP メッセージが含まれると仮定すること。 MS は、Setup Container IE の

内容が、モバイル発信の呼確立試行の中で前に送信された SETUP メッセージ内で、加入者から送信されたものと

同一と仮定することもできる。 MS は、Setup Container を SETUP メッセージにコピーすること。the recall alignment procedure で定義される例外、および以下に定義される例外を除き、内容を修正してはならない。 MS は SETUP メッ

セージの終わりに、他の IE を追加してはならない。

例外

Bearer Capability IE、HLC IE、そして LLC IE（2 つのベアラケーパビリティがあった場合には Repeat Indicato を含む）は、以下の recall alignment procedure で説明されるように、処理を要求する。

Setup Container IE 内の CC Capabilityが、MS がサポートするものとは異なる場合、MS は SETUP メッセージ

中の CC Capabilitiy を修正し、MS の実際のケーパビリティを通知すること。

recall alignment procedure 内で説明されるように、Facility IE と SS Version IE は処理を要求する。

Stream Identifier IE は、recall alignment procedure で説明されるように処理を要求する。

タイマ T333 が満了する前に、ネットワークの呼制御エンティティが CC-ESTABLISHMENT メッセージに対する応答

を受信しなかった場合、ネットワークは理由値#102 "recovery on timer expiry" の RELEASE COMPLETE メッセージ

を使用して、コールされた MS に対する呼のクリア処理を開始すること。そしてネットワーク内の全ての適切なエンテ

ィティに対して通知し、セクション 5.4.2 に従って処理を進めること。

Figure 5.7a/TS 24.008 Call initiation and possible subsequent responses.

5.2.3.2.1 Recall Alignment Procedure

recall alignment procedure は、以下の 3 つのパートから構成される。すなわち、

- 基本サービスグループ配置

- 施設の配置

- SI（stream identifier）の配置

MS は、Setup Container IE 内に組み込まれている Bearer Capability, HLC 、そして LLC と Repeat Indicator フィール

ドをチェックして、MS がサポートする基本サービスグループにマッチするか否かを検証する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 171

このチェックが失敗した場合、再発呼整列手続きは失敗した。その後、 MS は理由値#88"incompatible destination"を使用すること。

それ以外の場合には、MS は基本サービスグループを変更しないという条件下で、Bearer Capability, HLC、そして LLC IE(例えばスピーチコーダのバージョン、データレート、無線チャネル要求条件など)の内容を変更することが許

可される。 MS が Bearer Capability, HLC、そして LLC IE から導いた結果は、その構成とケーパビリティで後で呼の

セットアップに使用される。

Facility の整列：

Setup Container に 1 つまたは複数の Facility IE が含まれる場合のみ、以下が適用される。Setup Container内の各 Facility IE は、common SS version IE に関連付けられる。各 Facility IE の処理について、以下に定義

する。MS は、Setup Container 内に含まれる各 facility IE を整列させること。GSM 04.10 で定義される規則も

また、適用される。

Facility IE は、 'simple recall alignment', 'advanced recall alignment' または 'recall alignment not essential'としてエンコ

ードされる (GSM 04.10 参照)。エンコードが次のことを通知していた場合、

- 単純な再発呼整列が要求された場合、MS は内容を修正せずに、Setup Container から SETUP メッセージに

Facility IE と common SS version IE をコピーすること。

- 高度な再発呼整列が要求された場合、MS は facility 内で定義されたオペレーションを認識してサポートしな

ければならない。 MS がオペレーションを認識しない、あるいはサポートできない場合には、再発呼整列手続

きは失敗し、MS は CC 確立要求の事後拒否の中で理由値#29 facility rejected"を使用すること。

- 再発呼整列が不可欠ではないときには、facility オペレーションは SETUP の不可欠なパートではない。 MSがオペレーションを認識しない場合には、SS Version IE と Facility IE は廃棄され、SETUP メッセージにもコピ

ーされない。

NOTE. MS は、対応する SS Version IE がなくても Facility IE を含めることもできる。このことは、SS オペレーショ

ンが Phase 1 プロトコルを使用してエンコードされることを意味する。

Facility 処理のより詳細な記述は、GSM 04.10 で与えられる。

Stream識別子の整列：

MS は、Setup Container 内に Stream Identifier フィールドが含まれるか否かをチェックすること。

Setup Container 内に Stream Identifier フィールドが含まれる場合には、MS は以下のどちらかの動作をすること。

- MS は Stream Identifier の値を再アサインし、Stream Identifier フィールドを修正する

- MS は Stream Identifier フィールドを除去する

Setup Container 内に Stream Identifier フィールドが含まれない場合には、MS は以下のように動作をすること。

- MS は Stream Identifier の値をアサインし、SETUP メッセージの末尾に Stream Identifier IE を追加する。

5.2.3.3 CC-Establishment confirmation（CC確立の確認）

"CC-establishment present"ステートにあるネットワークの呼制御エンティティは、CC-ESTABLISHMENT CONFIRMED メッセージを受信したならば、タイマ T333 を停止し、"CC-establishment confirmed"ステートに入ること。

"CC-establishment confirmed"ステートにあるネットワークは、RECALL メッセージを送信する。このメッセージはユー

ザに対してアラートし、さらに Facility IE(ユーザに通知するために提供される追加情報を提供する)が含まれること。

ネットワークはタイマ T334 を起動し、'recall present'ステートに入る。

RECALL メッセージを受信した MS は、T335 を停止し、"recall present"ステートに入る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 172

Figure 5.7b/TS 24.008 Recall

5.2.3.4 Recall present

"recall present"ステートにある MS の呼制御エンティティは、ユーザが Recall を受理するのを待つ。確認を受信した

ならば、MS は以下の操作で受理を通知する：

- ネットワーク内のそのピアエンティティに SETUP メッセージを送信


- "call initiated"ステートに入り、セクション 5.2.1.1 に説明された処理を行なう

MS は、SETUP メッセージ内で送信された Bearer Capability IE の内容が、この Network Initiated MO Call に関係す

る前の CC-ESTABLISHMENT CONFIRMED メッセージ中の Bearer Capability IE と同一であることを確認すること。

"recall-present"ステートにおいて、MS のユーザが User Determined User Busy の場合には、理由値#17#17 "user busy"といっしょに RELEASE COMPLETE メッセージを送信すること。"recall-present"ステートにおいて、 MS のユー

ザが再発呼拒否を希望した場合には、理由値#21#21 "call rejected"といっしょに RELEASE COMPLETE メッセージ

を送信すること。

いずれの場合にも、モバイルはセクション 5.4.2 に従ってコネクションを開放すること。

recall-present"ステートにおいて SETUP メッセージを受信した場合には、ネットワークはタイマ T334 を停止し、セクシ

ョン 5.2.1.2 に規定されるように処理を進めること。

Ｔ３３４タイマーが満了する前に、ネットワークの呼制御エンティティが SETUP メッセージを受信した場合、理由値 #102 "recovery on timer expiry"を使用してモバイルに RELEASE COMPLETE メッセージを送信し、MM コネクション

を開放し、"null"ステートに入り、ネットワーク内の適切なエンティティにすべて通知すること。

Figure 5.7b/TS 24.008 Recall acceptance or rejection by user

5.2.3.5 Traffic channel assignment during network initiated mobile originating call establishment （ネットワークが開始した MS発信呼の確立中のトラフィックチャネルの割当て）

"CC-establishment confirmed"ステート内で、トラフィックチャネルの割当てを開始するか否かはネットワークが決定す

べき選択である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 173

5.3 Signalling procedures during the "active" state （"active"ステート内のシグナリング処理）

5.3.1 User notification procedure（ユーザ通知処理）ユーザ通知処理を完了するモバイルは、呼が"active"なステートにある間、ネットワークが呼に関連した任意の適切

なイベントを MS に通知することを許容する。処理はネットワークが MS に送信する NOTIFY メッセージから構成さ

れる。本メッセージを送信または受信した後、インタフェースのどちら側でもステート変更は発生しない（ただし、オプ

ションとして、MS 内で適切な通知を生成することはできる）。

ユーザ通知処理を開始するモバイルは、呼が"active"なステートにある間、ネットワークに対する通知インジケータを

含む NOTIFY メッセージを送信し、適切な呼に関係するイベントのリモートユーザに対して MS が通知することを許

容する。本メッセージを受信したネットワークは、呼に含まれるその他のユーザに対して、同一の通知インジケータを

含む NOTIFY メッセージを送信する。に本メッセージを送信または受信した後、インタフェースのどちら側でもステー

ト変更は発生しない。

5.3.2 Call rearrangements（呼の再アレンジ）明示的なメッセージ(例えば SUSPEND、ETS 300 102-1 中で定義される RESUME メッセージなど)を使用した、無線

インタフェース上の呼の再アレンジはサポートされない。ただし、リモートの非 PLMN ユーザが呼の再アレンジを開

始した場合、ネットワークは NOTIFY メッセージを使用して MS に通知すること。同様の方法で MS は、NOTIFY メッ

セージ(例えば MS に接続されたユーザ装置の変更など)を送信し、呼の再アレンジに関する情報をネットワークに通

知することができる。

5.3.3 Not used

5.3.4 Support of Dual Services（デュアルサービスのサポート）セクション 5.3.4 を通じて、以下の要求されたサービスを実現するために、本セクション内で説明される動作が使用さ

れる。MS は、ネットワークが起動したインコール修正手順ををサポートする必要がない。この場合、MS は MODIFYメッセージを受信したならば、メッセージを未知のものとして扱い、セクション 8.4 に記載されたように動作すること。

MS が既に双方向で処理をサポートする準備が整っていた場合、本セクションに記述されたように動作すること。

Alternate Speech/Group 3 fax (GSM 02.03 に従った Teleservice 61)

5.3.4.1 Service Description（サービスディスクリプション）

本 CS サービスは、2 人のユーザに対して、同一の呼中の異なる時間に、両者間の point-to-point のコネクションを使

用して、異なる情報を送信することを可能にさせる。

呼確立中のネゴシエーションにより、上述のサービスが認識されたならば、インコール修正処理が許可されて、ある

1 つのコールモードから他のモードに変更することによって、現在の呼の中で実行することが可能になる。

特定のケースでは、インコール修正処理によって新しいチャネルを許容することによってチャネル構成を変更するこ

とが必要になる場合もあるし、またそれ以外のケースでは、前に割当てられたチャネルをキープしながらチャネル構

成パラメータを変更することが必要になる。この変更はネットワークによって決定され、チャネル割当て処理、ハンド

オーバ処理、あるいはチャネルモード修正処理(第 3 章参照)のいずれかを通知する。

MS は、呼確立中に別々の IE を持つオペレーションの各モードを特定することによって、ケーパビリティと希望する初

期モードを特定する必要がある。さらに、リピートインジケータを使用して、モード間の変更のタイプを特定しなくては

ならない:

mode 1 "alternate" mode 2.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 174

5.3.4.2 Call establishment（呼確立）

モバイル発信呼、着信呼の双方に対して、通常の呼確立処理が適用される。

5.3.4.2.1 Mobile Originating Establishment（モバイル発信の確立）

発信元 MS がネットワークにサービスを要求する場合には、BC repeat indicator IE, bearer capability 1 IE、そして bearer capability 2 IE を含む SETUP メッセージを送信する。オペレーションの初のモード("call mode")は、bearer capability 1 IE によって通知され、2 回目のコールモードは bearer capability 2 IE によって通知される。

オプションとして、low layer compatibility I および low layer compatibility II 内の各コールモードを毎に、下位レイヤ

の互換性を規定することもできる。この場合、

- SETUP メッセージは、LLC repeat indicator IE と、low layer compatibility I および low layer compatibility II の双方を含むこと。この場合、low layer compatibility I IE は bearer capability 1IE に、low layer compatibility II IE は the bearer capability 2IE に対応する。

- 1 つもしくは複数のコールモードに対して、下位レイヤの互換性仕様が適用されない場合、対応する low layer compatibility IE (low layer compatibility I または low layer compatibility II)は、"not applicable"を通知すること。

- LLC repeat indicator は、BC repeat indicator IE と同じ反復インジケーションを規定すること。

同様に、high layer compatibility i および high layer compatibility ii 内で、オプションとして上位レイヤの互換性を規

定することもできる。この場合、

- SETUP メッセージは、HLC repeat indicator IE と、high layer compatibility i および high layer compatibility iiの双方が含まれること。high layer compatibility i IE は bearer capability 1 IE に、high layer compatibility ii IEは bearer capability 2 IE に対応する。

- 1 つもしくは複数のコールモードに対して、上位ヤの互換性仕様が適用されない場合、対応する high layer compatibility (high layer compatibility i または high layer compatibility ii)は、"not applicable"を通知 the HLC repeat indicator shall specify the same repeat indication as the BC repeat indicator IE. HLC repeat indicator は、BC repeat indicator IE と同じ反復インジケーションを規定すること。

受信中のエンティティは、indicator IE or HLC repeat indicator がメッセージ内に含まれるか否かを無視すること。エン

ティティはまた、LLC repeat indicator IE もしくは HLC repeat indicator IE の repeat indicator を無視すること。メッセー

ジ内に low layer compatibility II IE が含まれず、かつメッセージ内に low layer compatibility I IE が含まれる場合に

は、受信中エンティティは、それをスピーチを特定しないメッセージ内で通知されるコールコード（もしあれば）に関連

付けること。メッセージ内に high layer compatibility ii IE が含まれず、high layer compatibility i IE が含まれる場合

には、受信中のエンティティはそれをスピーチを特定しないメッセージ内で通知されるコールコード（もしあれば）に関

連付けること。

コールモードに対してセンシティブなネットワークの特別なパートは、Annex B で規定される互換性チェックを行い、

SETUP メッセージ内に含まれるベアラケーパビリティを検証すること。その互換性チェックの結果、ネットワークが呼

を拒否することを決定したならば、ネットワークは以下のいずれかの理由値といっしょにセクション 5.4 に規定される

ように呼のクリアを開始すること。

a) #57 "bearer capability not authorized"

b) #58 "bearer capability not presently available"

c) #65 "bearer service not implemented"

d) #70 "only restricted digital information bearer capability is available"

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 175

5.3.4.2.2 Mobile Terminating Establishment（モバイル着信の確立）

呼確立発信元モバイルと同様の方法で符号化された SETUP メッセージによって、サービスは着呼側の MS に通知

される。通常の着信呼確立を仕様化するために、CALL CONFIRMED メッセージ内で着信元 MS にサービスを通

知することができる。

着信 MS は、SETUP メッセージの中で通知された場合には、双方の要求されたモードについて、Annex B に定義さ

れる互換性チェックを実行すること。互換性チェックの結果、MS が呼を拒否することを決めた場合には、MS は下記

のいずれかの理由値といっしょに、セクション 5.4 の処理に従って呼のクリアを開始すること。




d) #88 "incompatible destination"

別のモードがフリーかビジーかに関わらず、通知された初のモードがフリーであれば、MS は呼を受理することが

できる。

5.3.4.3 Changing the Call Mode（コールモードの変更）

コールモードを変更するためには、以下のインコール修正処理を使用すること。

無線インタフェースはどちら側でも、ユーザに対してインコール修正の起動を要求することができる。

インコール修正処理の各処理が正常終了したならば、呼はこの確立フェーズ内でネゴシエーションされて合意された

次のモードへ変更することができる。

インコール修正処理は、無線インタフェースにおいて完全に対称である。

NOTE: 将来の拡張を容易にするために、インコール修正を対称な処理として規定する。

5.3.4.3.1 Initiation of in-call modification（インコール修正の開始）

"active"なステートにある、呼を発信した側の要求に基づいて、処理が開始される。変更すべき新しいモードを含む MODIFY メッセージを送信し、タイマ T323 を起動し、"mobile originating modify" ステート (MS 側) または"mobile terminating modify"ステート（ネットワーク側）に入ること。次のコールモードをサポートするために必要な内部リソー

スを予約すること。MODIFY メッセージの中で与えられる新しいモードは、呼の確立フェーズ中にネゴシエーションさ

れて既に合意されたモードのうちの 1 つとすること。データ呼の方向が呼セットアップの方向と異なる場合、

MODIFY メッセージ内に reverse call setup direction IE が含まれること。をデータ呼の方向が呼セットアップの方向と

一致する場合には、この IE が含まれてはならない。 MODIFY 発信側は、Bm-channel 情報の送信を停止し、古いコ

ールモードに従って受信した Bm-channel 情報を解釈することを停止すること。

MODIFY メッセージを受信したならば、着信側は要求されたコールモードをまだサポートすることができるかをチェッ

クし、もしサポートできるならば、次のコールモードをサポートするために必要な全てのリソース予約を開始し、

"mobile originating modify" ステート(ネットワーク側)または "mobile terminating modify"ステート（MS 側）に入ること。

5.3.4.3.2 Successful completion of in-call modification（インコール修正の正常完了）

着信ネットワーク/MS が MODIFY メッセージといっしょに受信した新しいモードが、既に存在している呼のものであっ

たならば、ネットワーク/MS は"active"ステートに留まり、実際のモードで MODIFY COMPLETE メッセージを送信す

ること。そして何も開始しないこと。

要求されたモードがスピーチモードで、かつ呼が UMTS の場合、デフォルトの UMTS AMR のスピーチバージョンを

仮定すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 176

要求されたモードがスピーチで、かつ呼が GSM の場合、ベアラケーパビリティにスピーチバージョンが含まれている

ならば、ネットワークはこれらのスピーチバージョンを使用すること。何も含まれていない場合には、GSM スピーチバ

ージョン 1 を仮定すること。

要求されたモードが実際のモードでなく、かつ着信インタフェースがサポートできる場合、もし要求されたならばチャネ

ルコンフィギュレーションを変更し、次のコールモードをサポートするのに必要な全ての内部リソースにステップを踏

み込むこと。要求されたモードがデータ/FAX モードの場合、さらにアカウントへデータ呼を方向付けるための適切な

手段を実行すること。チャネルコンフィギュレーション変更が正常終了した後で、次のコールモードに従ってユーザ情

報の送信を開始し、受信したユーザチャネル情報を次のコールモードに従って解釈し始めること。新しいコールモー

ドといっしょに MODIFY COMPLETE メッセージを送信し、"active" ステート(MS あるいはネットワーク側)に入ること。 MODIFY メッセージ内に reverse call setup direction IE が含まれていた場合、MODIFY COMPLETE メッセージ内に

同一 IE が含まれること。

代替スピーチ/G3 FAX サービス(セクション 5.3.4 を参照)の場合には、古いリソースをキープして予約することもでき

る。

MODIFY COMPLETE メッセージを受信した発信元側では、次のコールモードをサポートするために必要なこれらの

リソースへの振替を開始し、タイマ T323 を停止し、"active"ステート(MS あるいはネットワーク側)に入ること。 MODIFY メッセージ内に reverse call setup direction IE が含まれていた場合には、発信元側のリアクションであるが、

着信側が MODIFY COMPLETE メッセージに IE を含めるか否かは実装に依存する。

5.3.4.3.3 Change of the channel configuration（チャネルコンフィギュレーションの変更）

現在のチャネルコンフィギュレーションでは要求されたベアラケーパビリティをサポートすることができない場合には、

ネットワークは割当て処理を開始し、それに従ってチャネルコンフィギュレーションを変更すること。

5.3.4.3.4 Failure of in-call modification（インコール修正の失敗）

5.3.4.3.4.1 Network rejection of in-call modification（インコール修正をネットワークが拒否）

ネットワークが要求されたコールモードへの変更をサポートすることができない場合、あるいはチャネルコンフィギュ

レーションの変更が失敗した場合、ネットワークは次のことを行なうこと。すなわち、変更のために予約されたリソース

を開放し、旧ベアラケーパビリティと理由値 58"bearer capability not presently available" といっしょに MODIFY REJECT メッセージを送信し、"active"ステートに入ること。チャネルコンフィギュレーションの変更が失敗した場合、ネ

ットワークは、古いコールモードのために要求された内部リソースに返ること。

古いベアラケーパビリティといっしょに MODIFY REJECT メッセージを受信したならば、処理を開始した MS は次のこ

とを行なうこと。すなわち、タイマ T323 を停止し、変更のために予約されたリソースを開放し、現在のコールモードに

従ってユーザチャネル情報の送信を再開し、受信したユーザチャネル情報を現在のコールモードに従って解釈する

ことを開始し、"active"ステートに入ること。

5.3.4.3.4.2 Mobile station rejection of in-call modification （インコール修正を MSが拒否）

MS が要求されたコールモードへの変更をサポートできない場合、MS はのことを行なうこと。すなわち、変更のため

に予約されたすべてのリソースを開放し、古いベアラケーパビリティと理由値# 58 "bearer capability not presently available"といっしょに MODIFY REJECT メッセージを送信し、"active" ステートに入ること。

ネットワークは MODIFY REJECT メッセージを受信したならば、タイマ T323 を停止し、変更のために予約されたすべ

てのリソースを開放すること。

5.3.4.3.4.3 Time-out recovery（タイムアウト復旧）

MS あるいはネットワークのどちらかの T323 が満了したならば、理由値# 102 "recovery on timer expiry"といっしょに

呼のクリア処理を開始すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 177

5.3.4.4 Abnormal procedures（異常なケース）

MODIFY、MODIFY COMPLETE あるいは MODIFY REJECT メッセージを、ステート"disconnect indication", "disconnect request" (MS 側のみ) または "release request"で受信した場合には、受信したメッセージ廃棄し、何もアク

ションを起こさないこと。

MODIFY COMPLETE メッセージ、通知すること、要求された 1 つに相当しないコールモードを受信する、あるいは、

MODIFY REJECT メッセージ、通知すること、そのとき実際のものに相当しないコールモードを受信する場合は、受

信されたメッセージを廃棄するものとする、また、処置を講じないものとする。

MODIFY メッセージ内で通知されたコールモードが、呼の確立フェーズ中にネゴシエーションして合意したものでは

ない場合には、実際のコールモードと理由値で# 57 "bearer capability not authorized"といっしょに、MODIFY REJECT メッセージを送り返すこと。

Figure 5.10a/TS 24.008 In-call modification sequence initiated by MS

Figure 5.10b/TS 24.008 In-call modification sequence initiated by network

5.3.5 User initiated service level up- and downgrading (GSM only) （ユーザが開始したサービスレベルのアップグレードまたはダウングレード（GSMのみ））

ユーザが開始したサービスレベルのアップグレードまたはダウングレードは、非透過的マルチスロットデータサービス

にのみ、適用可能である。この処理を使用して、ユーザは"maximum number of traffic channels" および／または

"wanted air interface user rate"パラメータの変更を要求し、ネットワークに割当ててもらうことができる。

5.3.5.1 Initiation of service level up- and downgrading （サービスレベルのアップグレードまたはダウングレードの開始）

処理は呼の"active"ステートにある MS によって開始される。MS は、

- "maximum number of traffic channels" および／または"wanted air interface user rate"パラメータの希望値を入

れた MODIFY メッセージを送信すること。

- ネゴシエーションされる可能性のある、その他の bearer capability IE のパラメータを変更してはならない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 178

- タイマ T323 を起動すること。

- "mobile originating modify"ステートに入ること。

次のサービスパラメータをサポートために必要な内部リソースは全て予約すること。呼セットアップ時に、デュアルサ

ービスをネゴシエーションした場合には、MS はデュアルサービスのデータフェーズの中でのみ、サービスレベルのア

ップグレードまたはダウングレードを開始すること。

MODIFY メッセージを受信したネットワークは、通知されたトラフィックチャネルの大数をサポートできるか否かをチ

ェックし、"mobile originating modify"ステートに入ること。

5.3.5.2 Successful completion of service level up- and downgrading （サービスレベルのアップグレードまたはダウングレードの正常終了）

MODIFY メッセージを受信したネットワークは、MS に割当てられたチャネルコンフィギュレーションの変更を開始す


MODIFY メッセージへの応答として、ネットワークは MODIFY COMPLETE メッセージに呼セットアップ時にネゴシエ

ーションしたベアラケーパビリティを入れて送信し、"active"ステートに入る。

MODIFY COMPLETE メッセージを受信した MS は、タイマ T323 を停止し、"active"ステートに入ること。

5.3.5.3 Rejection of service level up- and downgrading （サービスレベルのアップグレードまたはダウングレードの拒否）

"maximum number of traffic channels" および／または "wanted air interface user rate"の変更と一緒に、ベアラサービ

スの変更を要求された場合、もしくは現在使用しているサービスがサービスレベルのアップグレードまたはダウング

レードが適用されないサービスの場合、もしくは受信者が要求を許可しないことを選択した場合、ネットワークは、

- 呼セットアップ時にネゴシエーションしたベアラケーパビリティ、理由値#58 "bearer capability not presently available"といっしょに MODIFY REJECT メッセージを送信し、

- "active"ステートに入る

MS は、呼セットアップ時にネゴシエーションされたベアラケーパビリティといっしょに MODIFY REJECT メッセージを

受信したならば、タイマ T323 を停止し、"active" ステートに入る。

5.3.5.4 Time-out recovery（タイムアウトリカバリ）

MS 内でタイマ T323 が満了したならば、理由値#102 "recovery on timer expiry"で呼のクリア処理が開始されること・

5.3.6 Support of multimedia calls（マルチメディア呼のサポート）

5.3.6.1 Service description（サービスディスクリプション）

GSM-UMTS 回線交換マルチメディア呼は、3G-324M[26.111]（ITU T H.324 勧告の 3GPP 版）に準拠する。 CS マル

チメディアテレフォニは、Synchronous Transparent Data(BS30)[3]を利用するベアラサービスである。

マルチメディア呼のセットアップに際して、要求コールタイプ 3G-324M が通知され、ネットワークが適切なインターワ

ーキング機能を実行できるようにする。ピアエンドにおいて、端末アプリケーションを起動するために H.324 情報が使

用される。H.324 のインジケーションに加えて、端末はマルチメディア呼のために ITC （Information Transfer Capability、情報転送ケーパビリティ）を選択する必要がある。「正確な」ITC はピアエンドと伝送ネットワークに依存

する。つまり、全ての ISDN 呼は UDI/RDI 呼であり、PSTN を含む呼はアナログの'3.1kHz audio”呼である。

マルチメディア呼のセットアップが成功しなかった場合のために、音声へのフォールバックが規定されている。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 179

5.3.6.2 Call establishment（呼の確立）

以下のセクションに規定される例外を除き、モバイル発信呼、モバイル着信呼の双方について、通常の呼確立処理

が適用される。

以下のセクション中の MSC/IWF の機能の詳細に関しては、TS 29.007[38]を参照。

5.3.6.2.1 Mobile originated multimedia call establishment （モバイル発信マルチメディア呼の確立）

呼セットアップ時に要求される呼タイプ 3G-324M は、発信元 MS からの SETUP メッセージ内で、bearer capabilityIEパラメータとして Other Rate Adaptation は'H.223 and H.245'がが通知される。SETUP メッセージ内で、スピーチインジ

ケーションといっしょに bearer capabilityIE 2 を入れることによって、音声呼を要求フォールバックがサポートされる。ネットワークは、Annex B に定義されるような互換性チェックを実行し、SETUP メッセージに含まれたベアラケーパビ

リティ IE に記述された各モードを検査する。この互換性チェックの結果、ネットワークが呼の拒否を決定した場合に

は、ネットワークは以下の理由値といっしょに、セクション 5.4 に規定されるような呼のクリアを開始すること。




d) #70 "only restricted digital information bearer capability is available"

発信元ユーザは、ディジタルコネクションが必要か、呼がアナログモデム呼であるかをチェックすること（おそらく端末

の事前設定によって）。ディジタル呼であると推測される場合には、bearer capability IE parameter ITC を UDI/RDI にセットする。アナログ呼の場合、bearer capability IE parameter ITC を '3.1kHz audio ex PLMN'にセットするさらに要

求されるモデムノタイプを通知することもできる（Other Modem Type = V.34）。

5.3.6.2.1.1 Fallback to speech（音声へのフォールバック）

アナログ H.324 呼のセットアップ中に、着信エンドが H.324 をサポートしないことをネットワークが検知した場合、MSが既に SETUP メッセージ内で speech bearer capability IE を含めていたならば、ネットワークは MS に対してインコー

ル修正処理(セクション 5.3.4.3 を参照)を開始し、コールモードを音声に修正する。

NOTE ディジタル(UDI) H.324 呼から音声呼へのフォールバックはサポートされない。

5.3.6.2.2 Mobile terminating multimedia call （モバイル着信マルチメディア呼）

呼セットアップ時に、bearer capability IE パラメータ Other Rate Adaptation は 'H.223 and H.245'に設定され、SETUPメッセージ内で、ネットワークから要求される呼タイプ 3G-324M が通知される。ITC は'3.1kHz audio ex PLMN' また

は 'UDI/RDI'のいずれかである。ネットワークが音声へのフォールバックをサポートする場合、および加入者が音声

（へのフォールバック）を予約していらば、SETUP メッセージに bearer capability IE 2 with speech indication が含まれ

る。SETUP メッセージから bearer capabilityIE が省かれることもある（例えば単一ナンバリングスキームの場合など）。

MS は、SETUP メッセージ内で通知されたならば、Annex B に定義される要求されたモードの互換性チェックを実行

すること。互換性チェックの結果、MS が呼を拒否することを決めたならば、MS は次の理由値のうち 1 つといっしょに、

セクション 5.4 の処理に従って呼のクリアを開始すること。




d) #88 "incompatible destination"

MS はサポートする呼のタイプを、SETUP に対する送達確認である CALL_CONFIRMED メッセージ内で通知するこ

と。MS は CALL_CONFIRMED メッセージ内で、bearer capability IE を包括するために、次のオプションを持つ。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 180

- MS またはユーザが、提示されたマルチメディア呼を受理し、かつ音声フォールバックをサポートする場合、

multimedia and speech bearer capability IE が含まれること。

- MS またはユーザが、提示されたマルチメディア呼を受理したが、音声フォールバックをサポートしない場合、

multimedia bearer capability IE だけが含まれること。

- MS またはユーザが、音声呼（だけ）を希望する場合、speech bearer capability IE が含まれる。

SETUP メッセージに bearer capability IE が含まれていない場合、ネットワークはセクション 5.3.6.2.1 で説明したモバ

イル発信呼の場合の SETUP メッセージ互換性チェックと同様の方法で、CALL CONFIRMED メッセージの互換性チ

ェックを実行すること。

(モデム呼で)モデムのハンドシェイクが失敗した場合、コールモードは音声に修正される。モデムのシグナリングは

インバンドなので、モデムの存在に関するこれらの結論を行なうときに、呼は既に active ステートに達しているに違い

ない。呼の修正は、インコール修正処理によって実現され、その処理によってネットワークは MS に対して呼のモー

ドの修正を要求する（セクション 5.3.4.3 を参照）。

NOTE: ディジタル(UDI) H.324 呼から音声呼へのフォールバックはサポートされない。

5.3.6.3 In-call modification in the "active" state （"active"ステートにおけるインコ－ル修正）

以下のインコール修正処理は、マルチメディア呼用のベアラケーパビリティを変更するために使用される。以下のベ

アラケーパビリティパラメータは、手順といっしょに修正することができる(TS 29.007[38]参照):

- Fixed Network User Rate

無線インタフェースのネットワーク側だけが、ユーザに対してインコール修正の起動を要求することができる。

5.3.6.3.1 Initiation of in-call modification（インコール修正の開始）

"active"ステートにある呼について、ネットワークは処理を開始する。ネットワークは MODIFY メッセージを送信する

こと。その中にはに Immediate modification indicator IE および変更すべき新しいベアラケーパビリティが含まれる。

タイマ T323 を起動し、"mobile terminating modify"ステートに入ること。新しいベアラケーパビリティをサポートするた

めに必要な内部リソースを全て予約すること。MODIFY 発信側は、Bm-channel 情報の送信を停止し、受信した Bm-channel 情報を古いベアラケーパビリティによって解釈することをやめること。

Immediate modification indicator IE といっしょに MODIFY メッセージを受信した MS は、要求されたベアラケーパビ

リティをサポートできるか否かをチェックし、サポートできるならば新しいベアラケーパビリティをサポートするために必

要な内部リソースを全て予約し、"mobile terminating modify"ステートに入ること。

5.3.6.3.2 Successful completion of in-call modification （インコール修正の正常完了）

MS が要求されたベアラケーパビリティをサポートすることができる場合、MS は TS 27.001[37]の中で定義されたアク

ションを実行すること。 TS 27.001[37]中で定義された修正が正常終了した後、MS は新しいベアラケーパビリティでて

ユーザ情報の送信を開始し、受信したユーザチャネル情報を新しいベアラケーパビリティで解釈し始めること。そして

新しいベアラケーパビリティといっしょに MODIFY COMPLETE メッセージを送信し、"active"ステートに入ること。

MODIFY COMPLETE メッセージを受信したネットワークは、新しいベアラケーパビリティをサポートするために必要

なこれらのリソースに対する修正を開始し、タイマ T323 を停止し、"active"ステートに入ること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 181

5.3.6.3.3 Failure of in-call modification（インコール修正の失敗）

5.3.6.3.3.1 MS rejection of in-call modification （MSによるインコール修正の拒否）

MS が要求されたベアラケーパビリティをサポートできない場合、MS は、修正用に予約された全リソースを開放し、古いベアラケーパビリティと理由値# 58 "bearer capability not presently available"といっしょに MODIFY REJECT メッセージを送信し、"active"ステートに入ること。

MODIFY REJECT メッセージを受信したネットワークは、タイマ T323 を停止し、修正用に予約された全リソースを開

放し、"active"ステートに入り、また TS 29.007 [38]中で定義されたアクションを実行すること。

5.3.6.3.3.2 Time-out recovery（タイムアウトリカバリ）

ネットワーク内でタイマ T323 が満了したならば、ネットワークは理由値# 102 "recovery on timer expiry"で呼のクリア

処理を開始すること。

5.4 Call clearing（呼のクリア）

5.4.1 Terminology（用語の定義）クリア処理を説明するために、本技術仕様書内では以下の用語が使用される。

- トラフィックチャネル（GSM 04.03 参照）は、チャネルが本技術仕様書に従って確立された CS コネクションの一

部であるときに、「接続された」という。

- チャネルが CS コネクションの一部ではなくなって、まだ新しいコネクションの中で使用可能でない場合に、トラ

フィックチャネルが「切断された」という。

5.4.2 Exception conditions（例外条件）正常な条件の下では、MS あるいはネットワークの呼制御エンティティが、そのピアエンティティに DISCONNECT メッ

セージを送信することにより呼のクリアが開始される。そしてその後、双方のエンティティは、セクション 5.4.3 および

5.4.4 の中でそれぞれ定義された処理に従う。

上記ルールの例外として、MS あるいはネットワークの呼制御エンティティは、他の応答が既に送信されていなけれ

ば、SETUP または START CC または CC-ESTABLISHMENT CC- ESTABLISHMENT CONFIRMED または RECALL メッセージに対する応答として RELEASE COMPLETE メッセージで応答し、起動中の呼制御タイマをすべ

て止めて、MM コネクションを開放し、"null"ステートに戻り、呼を拒否することができる。

更なる例外として、ネットワークの呼制御エンティティは起動中の呼制御タイマをすべて止めて、RELEASE メッセー

ジを送信し、タイマ T308 を起動し、"release request"ステートに入ることもできる。

NOTE: ネットワークは、RELEASE メッセージの送信により呼のクリアを開始するこの方法を使用してはならな

い:

- インバンドトーン／アナウンスが提供され、かつネットワークがセクション 5.4.4.1.1.1 または 5.4.4.2.1の手順を使用することを決定した場合。

- ネットワークが呼のクリア中に MS が送信した情報に対して応答する機会を持ちたい場合、例えば、

ネットワークが"CCBS activation is possible"を通知した場合

呼制御エンティティは、たとえ理由値 IE を含まれていなくても、呼のクリア処理の開始に使用された入力メッセージ

RELEASE COMPLETE を受け入れること。

制御エンティティは、たとえ理由値 IE を含まれていなくても、呼のクリア処理の開始に使用された入力メッセージ

RELEASE を受け入れること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 182

更に、呼制御エンティティは、入力メッセージ RELEASE COMPLETE を、そのステートの全てと一致するものと見な

すこと。つまり、呼制御エンティティは、入力メッセージ RELEASE COMPLETE が、null ステート以外の全てのステー

トと整合するものと見なすこと。MS の呼制御エンティティは、入力メッセージ DISCONNECT が、"null" ステート、

"release request" ステート、および "disconnect indication"ステート以外の全呼制御ステート整合するものと見なすこと。

ネットワークの呼制御エンティティは、入力メッセージ DISCONNECT が、"null" ステート、"release request" ステート

以外の全呼制御ステート整合するものと見なすこと。

NOTE: これは、将来より短い呼のクリア処理が導入されるための準備である。

5.4.3 Clearing initiated by the mobile station (MSによる呼のクリアの開始)

5.4.3.1 Initiation of call clearing （呼のクリアの開始）

セクション 5.4.2 に規定される例外を除き、MS の呼制御エンティティは、以下のようにして呼のクリアを開始すること。

すなわち、全ての起動中のタイマを停止し、DISCONNECT メッセージを送信し、タイマ T305 を起動し、"disconnect request"ステートに入ること。

5.4.3.2 Receipt of a DISCONNECT message from the mobile station. （MSからの DISCONNECTメッセージの受信）

"null" ステートと "release request"ステート以外のステートにあるネットワーク内の呼制御エンティティは、

DISCONNECT メッセージを受信したならば、

- 全ての起動中の呼制御タイマを停止

- ネットワークコネクションのクリア処理を開始し、リモートユーザの呼び出しを開始

- そのピアエンティティに RELEASE メッセージを送信


- "release request"ステートに入る

NOTE: RELEASE メッセージは、ローカルでのみ有意であり、リモートユーザからのクリアの送達確認を意味

するものではない。

5.4.3.3 Receipt of a RELEASE message from the network （ネットワークからの RELEASEメッセージの受信）

"null" ステートと "release request"ステート以外のステートにある MS 内の呼制御エンティティは、RELEASE メッセー

ジを受信したならば、全ての起動中の呼制御タイマを停止し、RELEASE COMPLETE メッセージを送信し、MM コネ

クションを開放し、"null" ステートに戻ること。

5.4.3.4 Receipt of a RELEASE COMPLETE message from the mobile station （MSからの RELEASE COMPLETEメッセージの受信）

任意の呼制御ステートにあるネットワーク内の呼制御エンティティは、MS 内のピアエンティティから RELEASE COMPLETE メッセージを受信したならば、全ての起動中の呼制御タイマを停止し、MM コネクションを開放し、"null" ステートに戻ること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 183


"disconnect request" ステートにある MS の呼制御エンティティは、タイマ T305 が満了したならば、元々

DISCONNECT メッセージ内に含まれていた理由値といっしょに DISCONNECT メッセージを送信すること。オプショ

ンとして理由値#102 "recovery on timer expiry"といっしょに second cause IE を送信することもできる。そして、タイマ

T308 を起動し、"release request"ステートに入ること。

"release request"ステートにあるネットワークの呼制御エンティティは、タイマ T308 が初に終了したならば、

RELEASE メッセージを再送し、タイマ T308 を起動し、"release request"ステートに入ること。タイマ T308 が 2 回目に

満了したならば、ネットワークの呼制御エンティティは、MM コネクションを開放し、"null" ステートに戻ること。

5.4.4 Clearing initiated by the network （ネットワークによるクリア処理の開始）

セクション 5.4.2 に規定された例外を除き、ネットワークの呼制御エンティティは、以下のようにして呼のクリアを開始

すること。すなわち、DISCONNECT メッセージを送信し、タイマ T305 を起動し、"disconnect request"ステートに入る

こと。 DISCONNECT メッセージは、ローカルな呼のクリアに対する誘因となる。

NOTE: ネットワークが RELEASE メッセージを送信して呼のクリアを開始する場合の処理は、以下のセクション

5.4.3、5.4.3.4、および 5.4.3.5 に記載される。

"Prolonged Clearing Procedure"をサポートしない MS は、セクション 5.4.4.1 の要求条件に応じて、セクション 5.4.4.1の要求条件を満足し、セクション 5.4.4.2 の要求条件は無視すること。"Prolonged Clearing Procedure"をサポートする

MS は、セクション 5.4.4.2 の要求条件を満足し、セクション 5.4.4.1 の要求条件は無視すること。

5.4.4.1 Clearing initiated by the network: mobile does not support "Prolonged Clearing Procedure" （ネットワークが呼のクリアを開始する場合：MSが"Prolonged Clearing Procedure"をサポートしない場合）

セクション 5.4.4.1 は、"Prolonged Clearing Procedure"をサポートしない MS に対してのみ、適用される。

5.4.4.1.1 Clearing when tones/announcements provided （トーン／アナウンスが提供されるクリア）

インバンドトーン/アナウンスが提供される場合(セクション 5.5.1 を参照)、ネットワークの呼制御エンティティは、進行

識別子#8 "in-band information or appropriate pattern now available"を含む DISCONNECT メッセージを送信して呼

のクリアを開始し、タイマ T306 を起動し、"disconnect indication"ステートに入ることができる。

5.4.4.1.1.1 Receipt of a DISCONNECT message with progress indicator #8 from the network （進行識別子#8といっしょに DISCONNECTメッセージをネットワークから受信した場合）

"null"ステート、"disconnect indication"ステート、および"release request"ステート以外の、任意のステートにある MSの呼制御エンティティは、進行識別子#8 といっしょに DISCONNECT メッセージを受信したならば、

i) 適切なスピーチトラフィックチャネルが接続されない場合、インバンドトーン/アナウンスに接続せずに、

section5.4.4.1.2.1 に規定されるクリア処理を継続すること。

ii) 適切なスピーチトラフィックチャネルが接続された場合、もしユーザコネクションがまだアタッチされていないな

らばそれをアタッチし、"disconnect indication"ステートに入ること。そのステートでは、上位レイヤに呼のクリア

を要求されたならば、MS の呼制御エンティティは、セクション 5.4.4. 1.2.1 に規定される処理を行うこと。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 184

5.4.4.1.1.2 Expiry of timer T306（タイマ T306の満了）

進行識別子#8 といっしょに DISCONNECT メッセージを送信後、"disconnect indication"ステートに入ったネットワーク

の呼制御エンティティは、タイマ T306 が満了したならば、元々DISCONNECT メッセージ内に含まれていた理由値と

いっしょに RELEASE メッセージを送信し、タイマ T308 を起動し、"release request"ステートに入ること。

5.4.4.1.2 Clearing when tones/announcements not provided （トーン/アナウンスが提供されない場合の呼のクリア）

インバンドトーンとアナウンスが提供されない場合、ネットワークの呼制御エンティティは起動中の呼制御タイマをす

べて停止し、進行識別子なしで DISCONNECT メッセージを送信し、タイマ T305 を起動し"disconnect indication"ステ

ートに入ること。

5.4.4.1.2.1 Receipt of a DISCONNECT message without progress indicator or with progress indicator different from #8 from the network （ネットワークから進行識別子なしで DISCONNECTメッセージを受信した場合、または#8以外の進行識別子といっしょに DISCONNECTメッセージを受信した場合）

"null"ステート、"disconnect indication"ステート、および"release request"ステート以外の、任意のステートにある MSの呼制御エンティティは、進行識別子なし、または#8 以外の進行識別子といっしょに DISCONNECT メッセージ#を受

信したならば、

- 全ての起動中のタイマを停止

- RELEASE メッセージを送信


- "release request"ステートに入る

5.4.4.1.2.2 Receipt of a RELEASE message from the mobile station （MSから RELEASEメッセージを受信）

"null"ステート、"disconnect indication"ステート、および"release request"ステート以外の、任意のステートにある MSの呼制御エンティティは、RELEASE メッセージを受信したならば、全ての起動中のタイマを停止し、RELEASE COMPLETE メッセージを送信し、MM コネクションを開放し、"null"ステートに戻ること。

5.4.4.1.2.3 Abnormal cases（異常なケース）

進行識別子なし、または#8 以外進行識別子といっしょに DISCONNECT メッセージを送信後、"disconnect indication"ステートに入ったネットワークの呼制御エンティティは、タイマ T305 が満了したならば、元々DISCONNECT メッセー

ジ内に含まれていた理由値といっしょに RELEASE メッセージを MS に送信し、タイマ T308 を起動し、"release request"ステートに入ること。オリジナルのクリア理由値に加えて、RELEASE メッセージには、理由値#102"recovery on timer expiry"といっしょに second cause IE が含まれる場合もある。

5.4.4.1.3 Completion of clearing（クリアの完了）

任意の呼制御ステートにある MS の呼制御エンティティは、ネットワーク中のピアエンティティから RELEASE COMPLETE メッセージを受信したならば、起動中の呼制御タイマをすべて停止し、 MM コネクションを開放し、"null"ステートに戻ること。


"release request" ステートにある MS の呼制御エンティティは、タイマ T308 の 1 回目満了時には RELEASE メッセー

ジを再送し、タイマ T308 を再起動すること。タイマ T308 の 2 回目満了時には MS の呼制御エンティティは、MM コ

ネクションを開放し、"null"ステートに戻ること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 185

5.4.4.2 Clearing initiated by the network: mobile supports "Prolonged Clearing Procedure" （ネットワークによるクリア処理の開始：MSが"Prolonged Clearing Procedure"をサポートする場合）

セクション 5.4.4. 2 は、"Prolonged Clearing Procedure"をサポートする MS に対してのみ、適用される。

5.4.4.2.1 Clearing when tones/announcements provided and the network does not indicate that "CCBS activation is possible" （トーン／アナウンスが提供され、かつネットワークが"CCBS activation is possible"を通知しない場合の呼のクリア）

インバンドトーン/アナウンスが提供され(セクション 5.5.1 参照)、かつ CCBS が適用可能でない場合には、ネットワー

クの呼制御エンティティは、DISCONNECT メッセージ内に、進行識別子#8"in-band information or appropriate pattern now available“を含めるか、Allowed Actions IE を含めないか、または"CCBS activation is not possible"を通知する

Allowed Actions IE を含めることによって、タイマ T306 を起動し、"disconnect indication"ステートに入ることができる。

5.4.4.2.1.1 Receipt of a DISCONNECT message（DISCONNECTメッセージの受信）

"null"ステート、"disconnect indication"ステート、および"release request"ステート以外の、任意のステートにある MSの呼制御エンティティは、進行識別子#8 といっしょに DISCONNECT メッセージ、または Allowed Actions IE を含ま

ない DISCONNECT メッセージ、または"CCBS activation is not possible"を通知する Allowed Actions IE を含む

DISCONNECT メッセージを受信したならば、以下の処理を行なうこと。

i) 適切な音声トラフィックチャネルがコネクトされていない場合、

- 起動中の呼制御タイマを全て停止し、

- RELEASE メッセージを送信し、

- タイマ T308 を起動し、

- "release request"ステートに入り、

- インバンドトーン/アナウンスを接続しないこと。

ii) 適切な音声トラフィックチャネルがコネクトされている場合、音声が未だアタッチされていないならばユーザコ

ネクションをアタッチし、"disconnect indication"ステートに入る。そのステートでは、もし上位レイヤから呼のク

リアを要求されたならば、MS の呼制御エンティティは、以下の処理を行なうこと。




- "release request"ステートに入ること。


"disconnect indication”ステートに入ったネットワークの呼制御エンティティは、タイマ T306 が満了したならば、元々

DISCONNECT メッセージ内に含まれていた理由値といっしょに RELEASE メッセージを MS に送信し、呼のクリアを

継続すること。タイマ T308 を起動し、"release request"ステートに入ること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 186

5.4.4.2.2 Clearing when the network indicates that "CCBS activation is possible" （ネットワークが"CCBS activation is possible"を通知した場合のクリア）

CCBS の Activation が可能な場合、ネットワークの呼制御エンティティは、"Activation of CCBS is possible" を通知す

る Allowed Actions IE を含む DISCONNECT メッセージを送信し、呼のクリアを開始し、タイマ T338 を起動すること

ができる。オプションとして、進行識別子#8 "in-band information or appropriate pattern now available"もDISCONNECT メッセージ内に入れることができる（その場合、タイマ T338 は T306 より小さいこと）。

5.4.4.2.2.1 Receipt of a DISCONNECT（DISCONNECTの受信）

現在のステートに応じて、以下のいずれかの処理が適用される。

- "null"ステート、"disconnect indication"ステート、および"release request"ステート以外の、任意のステートにあ

る MS の呼制御エンティティは、DISCONNECT メッセージを受信したならば、第 8 章で説明されたように反応

すること。

- "disconnect request"ステートにある MS 内の呼制御エンティティは、DISCONNECT メッセージを受信したなら

ば、





- その他の任意のステートにある MS 内の呼制御エンティティは、"Activation of CCBS is possible"を通知する

Allowed Actions IE を含む DISCONNECT メッセージを受信したならば、"Activation of CCBS is possible"通知

を上位レイヤにパスし、"disconnect indication"ステートに入り、起動中の呼制御タイマを全て停止し、上位レイ

ヤからの応答を待つこと。

DISCONNECT メッセージに進行識別子#88 "in-band information or appropriate pattern now available"が含まれ

ており、かつ適切な音声トラフィックチャネルがコネクトされている場合、MS は音声用にユーザコネクションが

まだアタッチされていない場合にはそれをアタッチすること。DISCONNECT メッセージに進行識別子#88 "in-band information or appropriate pattern now available"が含まれていなかった場合には、コネクトされた音声ト

ラフィックチャネルを全て切断すること。

上位レイヤからの応答：

i) 上位レイヤが呼のクリアを要求した場合、MS の呼制御エンティティは、





ii) 上位レイヤが"CCBS activation is to be attempted"を要求した場合、MS は、

- Facility IE を含む RELEASE を送信し、

- =CCBSRequest をネットワークに対して起動し、




3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 187

適切な音声トラフィックチャネルがコネクトされていない場合には、本 RELEASE メッセージの送信が、切断理

由にならないようにすること。


"Activation of CCBS is possible"を通知する Allowed Actions IE といっしょに DISCONNECT メッセージを送信後、

"disconnect indication"ステートに入ったネットワークの呼制御エンティティは、タイマ T338 が満了したならば、元々

DISCONNECT メッセージ内に含まれていた理由値といっしょ RELEASE メッセージを送信し、タイマ T308 を起動し、

"release request"ステートに入ること。

5.4.4.2.3 Clearing when tones/announcements are not provided and the network does not indicate that "CCBS activation is possible" （トーン／アナウンスが提供されず、ネットワークが"CCBS activation is possible"を通知しない場合のクリア）

インバンドトーンとアナウンスが提供されず、かつネットワークが Allowed Actions IE 内で"CCBS is possible"を通知

しようとしない場合、ネットワークの呼制御エンティティは、起動中の呼制御タイマを全て停止し、Allowed Actions IE なしで、もしくは"CCBS is not possible"を通知する Allowed Actions IE といっしょに、進行識別子のない

DISCONNECT メッセージを送り、タイマ T305 を起動し、"disconnect indication" ステートに入ること。

5.4.4.2.3.1 Receipt of a DISCONNECT message（DISCONNECTメッセージの受信）

"null"ステート、"disconnect indication"ステート、および"release request"ステート以外の任意のステートにある MSの呼制御エンティティは、進行識別子 IE のない DISCONNECT メッセージあるいは#8 以外の進行識別子を

持つ DISCONNECT メッセージを受信した場合、Allowed Actions IE なしで、あるいは"CCBS is not possible"を通知する Allowed Actions IE といっしょに DISCONNECT メッセージを受信した場合、






"release request"ステートに入ったネットワークの呼制御エンティティは、タイマ T305 が満了したならば、元々

DISCONNECT メッセージ内に含まれていた理由値といっしょ RELEASE メッセージを MS に送信し、タイマ T308 を

起動し、"release request"ステートに入ること。

5.4.4.2.4 Receipt of a RELEASE message from the mobile station （MSからの RELEASEメッセージの受信）

5.4.4.2.4.1 Release, CCBS not requested（Release, CCBSが要求されない場合）

"CCBS activation"オプションをサポートしないネットワークは、

"null"ステートおよび"release request"ステート以外のステートにあるネットワーク内の呼制御エンティティは、

RELEASE メッセージを受信したならば、起動中の呼制御タイマを全て停止し、RELEASE COMPLETE メッセ

ージを送信し、MM コネクションを開放し、"null"ステートに戻ること。

"CCBS activation"オプションをサポートするネットワークは、


RELEASE メッセージを受信したならば、Facility IE なしで Invoke=CCBSRequest を含む RELEASE メッセージ

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 188

を受信したならば、起動中の全てのタイマを停止し、RELEASE COMPLETE メッセージを送信し、MM コネク

ションを開放し、"null"ステートに戻ること。

5.4.4.2.4.2 Release, CCBS Requested（Release, CCBSが要求された場合）

"CCBS activation"オプションをサポートしないネットワークは、


RELEASE メッセージを受信したならば、起動中の呼制御タイマを全て停止し、RELEASE COMPLETE メッセ

ージを送信し、MM コネクションを開放し、"null"ステートに戻ること。

"CCBS activation"オプションをサポートするネットワークは、


RELEASE メッセージを受信したならば、Invoke=CCBSRequest を含む Facility IE を含む RELEASE メッセー

ジを受信したならば、起動中の全てのタイマを停止すること。次に再発呼をアクティブにし、再発呼アクティブ

化の成功または失敗を通知する RELEASE COMPLETE メッセージを送信し、MM コネクションを開放し、

"null"ステートに戻ること。

5.4.4.2.5 Completion of clearing（クリア処理の完了）

任意のステートにある MS 内の呼制御エンティティは、ネットワーク内のピアエンティティから RELEASE COMPLETEメッセージを受信したならば、起動中の全てのタイマを停止し、MM コネクションを開放し、"null"ステートに戻ること。


タイマ T308 第 1 回目満了時に"release request"ステート内にある MS の呼制御エンティティは、RELEASE メッセージ

を再送し、タイマ T308 を再起動すること。タイマ T308 が満了したならば、MS の呼制御エンティティは、MM コネクシ

ョンを開放し、"null"ステートに戻ること。

たとえ初の RELEASE メッセージに Invoke=CCBSRequest を含む Facility IE が含まれていない場合でも、再送す

る RELEASE メッセージ内には Invoke=CCBSRequest を含む Facility IE が含まれる必要はない。

5.4.5 Clear collision MS およびネットワークの双方が、同じ呼を指定する DISCONNECT メッセージを同時に転送した場合、明らかに衝

突が発生する。

"disconnect indication" ステートにおいてネットワークが DISCONNECT メッセージを受信した場合の動作は、セクシ

ョン 5.4.3 で規定される。 "disconnect request"ステートにおいてネットワーク DISCONNECT メッセージを受信した場

合の動作は、セクションセクション 5.4.4 で規定される。

MS およびネットワークの双方が、同じ呼に関係する RELEASE メッセージを同時に送信した場合、明らかに衝突が

発生する。"release request"ステートにおいて RELEASE などのメッセージを受信したエンティティは、タイマ T308 を停

止し、MM コネクションを開放し、（RELEASE COMPLETE メッセージを送信することなしに）"null"ステートに入ること。

5.5 Miscellaneous procedures（その他の処理）

5.5.1 In-band tones and announcements （インバンドトーンとアナウンス）

MS がある 1 つの呼の"active"ステートに達する前に、ネットワークが MS にユーザコネクションをアタッチしたい場合

（例えばインバンドトーン/アナウンスを提供するために）には、ネットワークは適切な CC メッセージ内にユーザアタッ

チを通知する進行識別子 IE を含めることができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 189

- MS は、呼確立中に送信された SETUP, CALL PROCEEDING, ALERTING,または CONNECT メッセージ内

に IE を含めるか、または

- MS は IE を含む PROGRESS メッセージを送信する。

progress indicator IE は、それが集合{1, 2, 3} または {6, 7, 8, ..., 20}内で進行説明を規定するならば、ユーザアタッ

チを通知する。

SETUP、CALL PROCEEDING、ALERTING、CONNECT または PROGRESS メッセージを受信した MS は、第 5 章

のどこかで規定された処理を進めること。進行識別子 IE がユーザアタッチを通知し、かつ音声モードトラフィックチャ

ネルが呼について適切だった場合には、MS はさらに、適切なチャネルが音声モードで利用可能になったならば直ち

に、音声用にユーザコネクションをアタッチすること（アタッチが完了する前に、ユーザコネクションをアタッチする新し

い命令を受信したならば、新しい命令は古い命令に優先する）。

特定の条件下では、MS は CONNECT メッセージの前にユーザコネクションをアタッチする必要が生じる場合もある。

MT 呼の確立中に、希望しない end-to-end のスルーコネクションを実行することを保証するか否かは、ネットワークに

依存する。

NOTE: これによって、呼にとって適切なチャネルモードとは独立して、progress indicator IE を使用することが

できるようになる。

5.5.2 Call collisions（呼の衝突）呼の衝突というものは、ネットワークでは起こりえない。同時に進行するモバイル着信呼とモバイル発信呼には、異

なるトランザクション識別子がそれぞれ割当てられ、別々に扱われる。

5.5.3 Status procedures（ステータス処理）

5.5.3.1 Status enquiry procedure（ステータス問合せ処理）

呼制御エンティティがそのピアエンティティの呼ステートをチェックしたいときはいつでも、呼制御エンティティはステー

タス問合せ処理を開始することができる。

注：典型的な例として、第 8 章に記載される手続きエラー条件に適用される。

呼制御エンティティは、STATUS ENQUIRY メッセージを送信し、タイマ T322 を起動して、ステータス問合せ処理を

開始する。タイマ T322 が起動している間は、呼制御エンティティは STATUS ENQUIRY メッセージをそれ以上送信

してはならない。

STATUS ENQUIRY メッセージを受信したならば、受信側は STATUS メッセージで応答し、現在の呼ステートと理由

値#30 "response to STATUS ENQUIRY"をレポートすること。STATUS ENQUIRY の受信によって、プロトコルおよび

受信者のコネクションに関するステートが変更されてはならない。

理由値#30"response to status enquiry"を含む STATUS メッセージを受信したならば、タイマ T322 を停止し、さらに

STATUS メッセージ内の情報に基づいて、STATUS メッセージ受信者の現在のステートについて適切なアクションを

取ること。これらの「適切なアクション」は実装依存である。しかし、（実装される場合には）セクション 5.5.3.2 に規定さ

れたアクションが適用されること。

タイマ T322 起動中に、呼をクリアするメッセージを受信した場合には、タイマ T322 を停止し、呼のクリアを継続する

こと。

タイマ T322 が満了したならば、STATUS ENQUIRY メッセージをもう一度だけ再送することもできる。STATUS ENQUIRY が大回数まで送信された後にタイマ T322 が満了したならば、呼のクリアは初の呼クリアメッセージ

中で理由値#41 "temporary failure"で開始されること。

.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 190

5.5.3.2 Reception of a STATUS message by a CC entity （CCエンティティによる STATUSメッセージの受信）

5.5.3.2.1 STATUS message with incompatible state （STATUSメッセージと両立しないステート）

STATUS メッセージで非互換性の呼制御ステートがレポートされたならば、受信エンティティは、理由値# 101 "message not compatible with protocol state"といっしょに RELEASE COMPLETE メッセージを送信し、呼をクリアする

こと。受信側と送信側の呼制御ステートのコンビネーションが発生しない、一致しない、または受信側のアクションと

整合しない場合には、レポートされた呼制御エンティティは非互換であると呼ばれる。非互換性の正確な定義は、実

装に依存する。

5.5.3.2.2 STATUS message with compatible state （互換性ステートとの STATUSメッセージ）

STATUS メッセージは、互換性呼ステートを通知するが、以下のいずれかの理由値を含むならば受信することがで

きる。

# 95 "semantically incorrect message"; または

# 96 "invalid mandatory information"; または

# 97 "message type non-existent or not implemented"; または

# 98 "message type not compatible with protocol state"; または

# 99 "information element non-existent or not implemented"; または

# 100 "conditional IE error",

これらの理由値は、STATUS メッセージの送信者が STATUS メッセージの受信者によって送信された情報を受理す

ることができなかったことを示す。これによって、受信者が情報のうちの一部または全てを再送することが可能にな

る。これ以外のアクションも可能であり、実装に依存する。呼を開放するアクションもそれに含まれる。

5.5.4 Call re-establishment, mobile station side （呼の再確立、MS側）

このセクションでは、呼コントロールに関する MS 内の内部処理について記述する。

5.5.4.1 Indication from the mobility management sublayer （MMサブレイヤからの通知）

MM コネクションがアクティブな場合、現在の MM コネクションが中断されたが、呼制御の要求に基づいて再確立す

ることが可能であることをアナウンスするために、MM サブレイヤは呼制御エンティティに通知を与えることができる。

5.5.4.2 Reaction of call control（呼制御のリアクション）

呼の再確立が許可されるか否か、およびその実際のステートに基づき、CC サブレイヤは呼の再確立を要求するか、

または MM コネクションを開放するかを決定する。

a) Re-establishment not required（再確立を要求しない場合）

呼が呼確立フェーズ、または呼クリアフェーズにある場合、つまり、"active"ステートまたは "mobile originating modify"ステート以外の任意のステートにある場合、CC サブレイヤは、MM コネクションを開放

すること。

b) Re-establishment required（再確立を要求する場合）

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 191

呼が"active"ステートまたは "mobile originating modify"ステートにある場合、再確立が可能であるという

MM からの通知が原因となって、CC サブレイヤは MM コネクションに再確立を要求し、これ以上メッセー

ジを送信することを中止し、再確立処理が完了するのを待つこと。

5.5.4.3 Completion of re-establishment（再確立の完了）

MM コネクションが再確立されたならば、CC サブレイヤに対して、保留されたメッセージの送信することを通知し、適

切なチャネルが利用可能になったならばユーザデータの交換を再開すること。

5.5.4.4 Unsuccessful outcome（失敗した場合の結果）

コネクション再確立試行が失敗した場合、MM コネクションは開放され、開放通知が CC サブレイヤに与えられる.セクション 4.5.1.6 を参照。

5.5.5 Call re-establishment, network side(呼の再確立、ネットワーク側) このセクションでは、呼コントロールに関するネットワーク側の処理について記述する。

5.5.5.1 State alignment（ステート配置）

呼再確立が正常終了後、（必要ならばステータス問合せ処理を使用して）ネットワークと MS の呼ステートまたは補

助ステートのミスマッチを発見し、可能ならばそれ解決するのは、ネットワーク側の責任である。

5.5.6 Progress 呼の確立中または開放中、または呼がアクティブである間は、ネットワークはいつでも MS に対して PROGRESS メッ

セージを送信することができる。

呼の確立中または開放中に、PROGRESS メッセージを受信したならば、MS は該当呼に関係する全ての呼制御タイ

マを停止すること。

NOTE: CALL PROCEEDING メッセージを受信する前に PROGRESS メッセージを受信した場合、MS は

CALL PROCEEDING メッセージを受信してもタイマ T310 を起動しない。セクション 5.2.1.1.3 を参照。

Figure 5.11/TS 24.008 Progress

5.5.7 DTMF protocol control procedure（DTMF呼制御処理） DTMF (Dual Tone Multi Frequency)とは、4 つのインバンドのうち 1 つに、電話通信ネットワーク内の端末装置で優

先的に使用される 4 つのシグナリングのうちの 1 つを足したものである。TS 23.014 にネットワークにおける DTMFのサポートが記載される。

MS が音声がアタッチされているユーザコネクションを持っており、かつ適切なチャネルが利用可能である場合に限り、

MS は DTMF メッセージを送信可能であること。

DTMF メッセージによって使用されるトランザクション識別子は、アタッチされた音声呼のトランザクション識別子であ

る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 192

NOTE 1: 本技術仕様書では、音声送信モードのアクティブステートにある場合、または呼のセットアップまたは開

放中にトラフィックチャネルが利用可能であり、かつ progress indicator IE を受信した場合には一般的に

DTMF メッセージを送信することができるものとする。

NOTE 2: シグナリングチャネル上の store モードおよび forward モード内で DTMF プロトコルメッセージが送信さ

れるので、遠隔端にあるデバイスの制御は、負荷またはチャネルの品質によっては遅延する場合があ

る。

NOTE 3: 本段落に記述された処理は、MS からネットワークに対する方向のみ、DTMF をサポートする。

5.5.7.1 Start DTMF request by the mobile station（MSからの DTMF要求開始）

ユーザは、例えば MS のキーを押すことによって DTMF トーンを生成させることができる。MS は、確立された

FACCH 上で START DTMFメッセージを送信するために、DTMF 数字を適切なアクションとして解釈する。このメッ

セージには、送信される数字(0、1、...、9、A、B、C、D、*、#)が含まれる。

START DTMF メッセージ 1 つにつき、1 つの数字だけを送信することができる。

START DTMF メッセージ送信に際して、MS はタイマ T336 を起動すること。

既に START DTMF メッセージを送った場合には、それに対する STOP DTMF ACKNOWLEDGE メッセージ(セクシ

ョン 5.5.7.4 を参照)または START DTMF REJECT メッセージ(セクション 5.5.7.2 を参照)を MS がネットワークから受

信した場合、またはタイマ T336 および T337 が満了した場合に限り、START DTMF メッセージをもう一度送信する

ことができること。

タイマ T336 が満了した場合、MS は進行中の DTMF 処理をメッセージを再送信せずに終了し、別の DTMF 処理(例えば別の START DTMF メッセージなど)を自由に開始することができる。

5.5.7.2 Start DTMF response by the network （ネットワークによる DTMF応答の開始）

START DTMF メッセージを受信したネットワークは、受信した数字を DTMF トーンに再変換し、それをリモートユー

ザに適用し、MS に START DTMF ACKNOWLEDGE メッセージを返す。正常終了した送信のフィードバックとして通

知を生成するために、MS 内でこの送達確認を使用することもできる。

ネットワークが START DTMF メッセージを受理できない場合、MS に DTMF REJECT メッセージが送信される。 START DTMF ACK メッセージまたは START DTMF REJECT メッセージを受信した MS は、タイマ T336 を停止す

ること。

5.5.7.3 Stop DTMF request by the mobile station （MSによる DTMF要求の停止）

例えばキーを開放することによって、DTMF 送信を停止すべきことをユーザが通知した場合、MS はネットワークへ

STOP DTMF メッセージを送信する。

STOP DTMF メッセージを送信した MS は、タイマ T337 を起動すること。

MS は、ネットワークから START DTMF ACKNOWLEDGE メッセージを受信したならば、単に STOP DTMF メッセー

ジを送信する (セクション 5.5.7.2 を参照)。

タイマ T337 が満了した場合、MS は再送信していない進行中の DTMF 処理を終了し、別の DTMF 処理(例えば別

の START DTMF メッセージ)を自由に開始することができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 193

5.5.7.4 Stop DTMF response by the network（ネットワークによる DTMFの停止）

STOP DTMF メッセージを受信したネットワークは、DTMF トーンの送信を停止し、MS に STOP DTMF ACKNOWLEDGE メッセージを返す。 STOP DTMF ACKNOWLEDGE メッセージを受信した MS は、タイマ T337 を

停止すること。

5.5.7.5 Sequencing of subsequent start DTMF requests by the mobile station （MSからの次の DTMF要求の開始シーケンス）

ネットワークは、(ETR 206 に従って)トーンの少の長さと、連続する 2 つのトーン間の少時間差を保証する。

NOTE 1: ETR 206 では、DTMF トーンの少時間は 70ms ±5ms

NOTE 2: ETR 206 では、DTMF トーンの時間間隔は 65ms

トーンの長時間は、トーンは MS から STOP DTMF メッセージを受信したならば停止するので規定されない。しか

し、オペレータは、送信されるトーンの長時間に予め定義した時間制限を設けることもできる。

図 5.8 および 5.9 中に、DTMF control メッセージの適切なシーケンスを示す。

NOTE 3: ネットワークが MS からの STOP DTMF メッセージ受信に関係なく DTMF トーン持続時間を制御する

場合には、ネットワークが時間制限オプションを実装することもできる。

Figure 5.8/TS 24.008 Single DTMF transmission

Figure 5.9/TS 24.008 Multiple DTMF transmission

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 194

6 Support for packet services （パケットサービスのサポート）

本章には、無線インタフェース(リファレンスポイント Uu および Um)における GPRS の point-to-point データサービス

のセッション管理用の処理が記載される。

6.1 GPRS Session management（GPRSセッション管理）

6.1.1 General（概要）セッション管理(SM)の主要な機能は、ユーザ端末の PDP コンテキスト処理である。 SM は、識別された PDP コンテ

キストの活性化、非活性化および修正のための処理から構成される。MS とネットワーク間に GMM コンテキストが

既に確立されている場合に限り、識別されたアクセスのための SM 処理を実行することができる。 GMM コンテキス

トが確立されていない場合、MM サブレイヤは、第 4 章に記述されるような GMM 処理を使用して、GMM コンテキス

トの確立を開始する必要がある。GMM コンテキスト確立後、SM は GMM が提供するサービスを利用する(TS 24.007[20]を参照)。 GMM 処理が実行される間、進行中の SM 処理は保留される。

UMTS 内のみでは、完全性が保護されたシグナリング(本仕様についてはセクション 4.1.1.1.1 を参照、概要は TS 33.102 を参照)が mandatory である。 UMTS 内のみでは、全てのプロトコルが完全性保護されたシグナリングを使用

すること。すべての SM シグナリングメッセージの完全性保護は、下位レイヤによって実行される。完全性保護をアク

ティブにするのはネットワークである。これはセキュリティモード制御手順(TS 25.331)を使用して行なわれる。

セッション管理プロトコルについては、拡張 TI メカニズムを使用することもできる(24.007 を参照)。

6.1.2 Session management states（ＳＭステート）このセクションでは、ある１つの SM エンティティに関する SM ステートについて記載する(TS24.007[20]参照)。各 SMエンティティは 1 つの PDP コンテキストに関連付けられる。セクション 6.1.2.1 では MS 側の SM ステートについて、セ

クション 6.1.2.2 ではネットワーク側の SM ステートについて記述する。

6.1.2.1 Session management states in the MS（MS側の SMステート）

このセクションでは、MS 内でとりうる可能性のある SM エンティティのステートについて記述する。図 6.1/TS 24.008にイラスト化されるように、MS では 5 つの SM ステートがある。

6.1.2.1.1 PDP-INACTIVE

PDP コンテキストが存在しないことを示すステート。

6.1.2.1.2 PDP-ACTIVE-PENDING

MS が PDP コンテキストの活性化を要求した時のステート。

6.1.2.1.3 PDP-INACTIVE-PENDING

MS が PDP コンテキストの非活性化を要求した場合のステート。

6.1.2.1.4 PDP-ACTIVE

PDP コンテキストがアクティブであることを示すステート。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 195

6.1.2.1.5 PDP-MODIFY_PENDING

MS によって PDP コンテキストの修正が要求された場合のステート。

PDP-ACTIVE- PENDING

PDP-ACTIVE

PDP-INACTIVE

PDP-INACTIVE- PENDING

DR (ACTIV. PDP CONTX. REQ)

DI (ACTIV. PDP CONTX. REJ) DI (DEACTIV. PDP CONTX. REQ)

DR: GMMSM-DATA-REQUEST (Message), i.e. message sent by an MSDI: GMMSM-DATA-INDICATION (Message), i.e. message received by an MS

DI (DEACTIV. PDP CONTX. REQ)

DR (DEACTIV. PDPCONTX. ACC)

DI (DEACTIV. PDP CONTX. ACC)

DR (DEACTIV. PDPCONTX. ACC)

DR (MOD PDP CONTXT ACC)

DI (ACTIV. PDP CONTX. ACC) DR (DEACTIV. PDP CONTX. REQ)

DI (MOD PDP CONTXT REQ) PDP-MODIFY-PENDING

DR (MOD. PDP CONTX. REQ)

DI (REQ PDP CONTX. ACTIV)

DR (ACTIV. PDP CONTX. REQ)

DR (DEACTIV. PDP CONTX. REQ)

DI(MOD. PDP CONTX. REJ)

DI(MOD. PDP CONTX. ACC)

図図図図 6.1/TS 24.008: MS におけるにおけるにおけるにおける SM ステート（概要）ステート（概要）ステート（概要）ステート（概要）

図 6.1/TS 24.008 は、PDP コンテキスト活性化処理、およびセカンダリ PDP コンテキスト活性化処理の双方に適用さ

れることに注意。および第 2 の PDP コンテキスト起動処理の両方に当てはまる。ただし、PDP コンテキストの活性化

に関するメッセージの違いについては、簡便のために省略されている。

6.1.2.2 Session management states on the network side （ネットワーク側の SMステート）

このセクションでは、ネットワーク側でとりうる可能性のある SM エンティティについて記載する。図 6.2/TS 24.008 に

示すように、ネットワーク側には 5 つの SM ステートがある。

6.1.2.2.1 PDP-INACTIVE

PDP コンテキストがアクティブでないことを示すステート。

6.1.2.2.2 PDP-ACTIVE-PENDING

ネットワーク側が PDP コンテキスト活性化を開始したことを示すステート。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 196

6.1.2.2.3 PDP-INACTIVE-PENDING

PDP コンテキストの非活性化がネットワークによって要求された時のステート。

6.1.2.2.4 PDP-ACTIVE

PDP コンテキストがアクティブであることを示すステート。

6.1.2.2.5 PDP-MODIFY-PENDING

ネットワークが PDP コンテキストの修正を要求した場合のステート。

DR: GMMSM-DATA-REQUEST (Message), i.e. message sent by network DI: GMMSM-DATA-INDICATION (Message), i.e. message received by the network

PDP-INACTIVE-PEND

DR (DEACTIV. PDP CONTX. REQ) DI (DEACTIV. PDP CONTX. ACC)


DR (DEACTIV. PDP CONTX. ACC)

DI (ACTIV. PDP CONTX. REQ)DR (ACTIV. PDP CONTX. ACC)

PDP ACTIVE

PDP-MODIFY- PEND

DR (MODIFY. PDP CONTX. REQ)

DI (MODIFY. PDP CONTX. ACC)

PDP-ACTIVE-PEND

DR (REQ PDP CONTX. ACTIV)

PDP-INACTIVE

DI (ACTIV. PDP CONTX. REQ)

DR (ACTIV. PDP CONTX. ACC)

DR (ACTIV. PDP CONTX. REJ)

DR (MOD PDP CONTXT REJ)

DI (MOD PDP CONTXT REQ)


DR (DEACTIV. PDP CONTX. ACC)

DI (REQ PDP CONTX. ACTIV. REJ) DR (MOD PDP CONTXT ACC)

図図図図 6.2/TS 24.008: ネットワーク側のネットワーク側のネットワーク側のネットワーク側の SM ステート（概要）ステート（概要）ステート（概要）ステート（概要）

図 6.2/TS 24.008 は、PDP コンテキスト活性化処理、およびセカンダリ PDP コンテキスト活性化処理の双方に適用さ

れることに注意。および第 2 の PDP コンテキスト起動処理の両方に当てはまる。ただし、PDP コンテキストの活性化

に関するメッセージの違いについては、簡便のために省略されている。

6.1.3 Session Management procedures（SM処理）

6.1.3.1 PDP context activation（PDPコンテキスト活性化）

本処理の目的は、MS とネットワークの間の PDP コンテキストを、特定の NSAPI の上で特定の QoS で確立すること

にある。PDP コンテキスト活性化の起動は、MS が開始することもできるし、ネットワーク側が要求することもできる。

それぞれの PDP アドレスは、MS あるいはネットワーク内で、1 つまたは複数の PDP コンテキストで記載することがで

きる。PDP コンテキスト活性化処理は、特定の PDP アドレス用の初の PDP コンテキストを活性化するために使用

される。一方、同一の PDP アドレスおよび APN に関連付けられた全ての追加コンテキストは、セカンダリ PDP コンテ

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 197

キスト活性化処理の中で活性化される。同一の PDP アドレスに複数の PDP コンテキストが関連付けられている場合

には、各コンテキストまたは 1 つ以外の全てのコンテキストに対して、TFT（Traffic Flow Template）が存在すること。

もし存在する場合には、TFT が SGSN を経由して GGSN にトランスペアレントに送信され、下りリンクデータ送信用

のパケット分類処理とポリシー処理が可能であること (TS 23.060 を参照)。

6.1.3.1.1 Successful PDP context activation initiated by the mobile station （MSが開始した PDPコンテキスト活性化の正常終了）

PDP コンテキスト活性化を要求するために、MS はネットワークへ ACTIVATE PDP CONTEXT REQUEST メッセー

ジを送信し、ステート PDP-ACTIVE-PENDING に入り、タイマ T3380 を起動する。メッセージには、選択された

NSAPI、PDP タイプ、要求された QoS、そして MS が固定アドレスを要求する場合には PDP アドレスが含まれる。MSは、選択された NSAPI が MS の中で別のセッション管理エンティティによって現在使用されていないことを保証する

こと。

ACTIVATE PDP CONTEXT REQUEST メッセージを受信したネットワークは、ネゴシエーションされた QoS に基づい

て無線優先レベル（radio priority level）を選択する。ACTIVATE PDP CONTEXT ACCEPT メッセージを応答するこ

ともできる。メッセージ ACTIVATE PDP CONTEXT ACCEPT を受信した MS は、タイマ T3380 を停止し、ステート

PDP-ACTIVE に入ること。ネットワークから受信した提示 QoS パラメータが、MS が要求した QoS パラメータと異なる

場合、MS はネゴシエーションされた QoS を受理するか、あるいは PDP コンテキスト非活性化処理を開始すること。

GSM では、該当 SAPI 用に論理リンクが未だ確立されていない場合には、MS がネットワーク提示された QoS と選

択された無線優先レベルで、ネットワークから通知された LLC SAPI 用の論理リンク確立を開始すること。ネットワー

クから受信した提示 QoS パラメーターが、MS が要求した QoS パラメータと異なる場合、MS はネゴシエーションされ

た QoS を受理するか、あるいは PDP コンテキスト非活性化処理を開始すること。ネットワークから示された LLC SAPI を MS がサポートしない場合、MS は PDP コンテキスト非活性化処理を開始すること。

UMTS では、ネットワークと MS の双方が、PDP コンテキスト内に LLC SAPI と無線優先度を格納する。 UMTS から

GSM へのシステム変更が実行される場合、新しい SGSN は、GSM から GSM への RA 更新時と同様に、PDP コン

テキスト内に格納された、ネゴシエーションされた QoS プロフィール、ネゴシエーションされた LLC SAPI 、そして選択

された無線優先度を使用して、論理リンクの確立を開始すること。

UMTS と GSM の双方でオペレーションできる MS は、有効な LLC SAPI を使用すること。一方、UMTS 内でしかオ

ペレーションできない MS は、不要な値の範囲のチェックとネットワーク内でその他の混乱を避けるために、LLC SAPI 値を"LLC SAPI not assigned"として通知すること。

NOTE: 無線優先レベルと LLC SAPI パラメータは、たとえ UMTS 内で使用されなくても、UMTS と GSM ネット

ワーク間のハンドオーバをサポートするために、メッセージ内に入れること。

6.1.3.1.2 Successful PDP context activation requested by the network （ネットワークが要求した PDPコンテキスト活性化の正常終了）

PDP コンテキスト活性化を要求するために、ネットワークは MS に REQUEST PDP CONTEXT ACTIVATION メッセージを送信し、タイマ T3385 を起動する。メッセージには、提示された PDP アドレスが含まれる。利用可能な場合に

は、APN を REQUEST PDP CONTEXT ACTIVATION メッセージ内に含めること。

REQUEST PDP CONTEXT ACTIVATION メッセージを受信した MS は、前のセクションに記述されるような PDP コンテキスト活性化処理を開始するか、あるいはセクション 6.1.3.1.4 に記述されるような REQUEST PDP CONTEXT ACTIVATION REJECT メッセージを送信して活性化要求を拒否すること。 REQUEST PDP CONTEXT ACTIVATION REJECT メッセージ内の reject cause IE の値は拒絶理由を通知する。例えば "insufficient resources to activate another context"（「他のコンテキストをアクティブにするためのリソースが不十分」）。

PDP コンテキスト活性化処理を開始するために、MS が送信した ACTIVATE PDP CONTEXT REQUEST メッセージ

には、REQUEST PDP CONTEXT ACTIVATION メッセージ内でネットワークが要求した PDP アドレス、PDP タイプ

および APN が含まれること。

ACTIVATE PDP CONTEXT REQUEST メッセージを受信したネットワークは、タイマ T3385 を停止する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 198

その後の処理は、MS が開始した PDP コンテキスト活性化処理の説明が適用される。

6.1.3.1.3 Unsuccessful PDP context activation initiated by the MS （MSが開始した PDPコンテキスト活性化処理が失敗した場合）

ACTIVATE PDP CONTEXT REQUEST メッセージを受信したネットワークは、MS に ACTIVATE PDP CONTEXT REJECT メッセージを送信して、PDP コンテキスト活性化を開始することができる。メッセージには理由コードが含ま

れること。通常は次の理由値のうちの 1 つである。

# 26: insufficient resources;

# 27: missing or unknown APN;

# 28: unknown PDP address or PDP type;

# 29: user authentication failed;

# 30: activation rejected by GGSN;

# 31: activation rejected, unspecified;

# 32: service option not supported;

# 33: requested service option not subscribed;

# 34: service option temporarily out of order;

# 35: NSAPI already used. The network shall not send this cause code (Note 1); or

# 95 - 111: protocol errors.

NOTE 1: R99 以前のネットワークは、本理由コードを送信できる。

ACTIVATE PDP CONTEXT REJECT メッセージを受信した MS は、タイマ T3380 を停止し、ステート PDP-INACTIVE に入る／留まる。

6.1.3.1.4 Unsuccessful PDP context activation requested by the network （ネットワークが要求した PDPコンテキスト活性化が失敗した場合）

REQUEST PDP CONTEXT ACTIVATION メッセージを受信した MS は、ネットワークへ REQUEST PDP CONTEXT ACTIVATION REJECT メッセージを送信することによって、ネットワークに要求された PDP コンテキスト

活性化を拒否することができる。メッセージには、REQUEST PDP CONTEXT ACTIVATION メッセージに含まれて

いる TI と同じ TI を含み、追加的に理由値を含むこともできる。通常は以下のうちのいずれかの値である。



# 40: feature not supported; or


ネットワークはタイマ T3385 を停止し、ステート PDP-INACTIVE に入ること。


異常なケースとして以下のものが定義される。

a) Expiry of timers（タイマの満了）

MS 側では、

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 199

タイマ T3380 の第 1 回目満了時には、MS は ACTIVATE PDP CONTEXT REQUEST を再送し、タイマ

T3380 をリセットして再起動する。この再送は、4 回まで繰り返される。つまり、タイマ T3380 の第 5 回満了

時には、MS は、再送の実施に関連する可能性のある全てのリソースを開放し、処理を中断すること。自

動 PDP コンテキスト活性化再試行を実行してはならない。

ネットワーク側では、

タイマ T3385 の第 1 回目満了時には、ネットワークはメッセージ REQUEST PDP CONTEXT ACTIVATION を再送し、タイマ T3385 をリセットして再開すること。この再送は、4 回まで繰り返される。

つまり、タイマ T3385 の第 5 回満了時には、ネットワークは、再送の実施に関連する可能性のある全ての

リソースを開放し、処理を中断すること。

b) MS が開始した PDP コンテキスト活性化処理と、ネットワークが要求した PDP コンテキスト活性化処理のバッ

ティング

動的に PDP アドレスがバッティングした場合：

MS が使用した動的な PDP アドレス割当て処理が、ネットワークが要求した PDP アドレスとバッティングした場

合の衝突の検出は仕様化されない。ネットワークの実装課題として残される。

静的 PDP アドレスのバッティングが MS 内で検出された場合：

MS が ACTIVATE PDP CONTEXT REQUEST メッセージ送信後 REQUEST PDP CONTEXT ACTIVATION メッセージをネットワークから受信して、かつ MS が ACTIVATE PDP CONTEXT ACCEPT あるいは ACTIVATE PDP CONTEXT REJECT メッセージを未受信ならば、MS は MS が開

始した PDP コンテキスト活性化処理と、ネットワークが要求した PDP コンテキスト活性化処理のバッテ

ィングを検出する。

注：一般的に MS は、REQUEST PDP CONTEXT ACTIVATION メッセージ中の PDP タイプ、PDP アドレスお

よび APN が、コンテキストをアクティブに仕様としている PDN のそれと同一であるかをテストすることはで

きない。これは、MS が ACTIVATE PDP CONTEXT REQUEST メッセージ内の 1 つまたは複数のパラメ

ータを省略する可能性があるためである。MS はネットワークから提供されたデフォルト値を中継する。

- そのようなバッティングが発生した場合には、MS が開始した PDP コンテキスト活性化が、ネットワークが要

求した PDP コンテキスト活性化よりも優先する。MS が ACTIVATE PDP CONTEXT REQUEST メッセージ

内で要求された PDP タイプ、PDP アドレスおよび APN を、REQUEST PDP CONTEXT ACTIVATION メッセ

ージ中のそれらの値と比較することができる場合には、MS は REQUEST PDP CONTEXT ACTIVATION メ

ッセージを廃棄し、ACTIVATE PDP CONTEXT REQUEST メッセージに対するネットワークからの応答を待

つ。 MS が ACTIVATE PDP CONTEXT REQUEST メッセージ内で要求された PDP タイプ、PDP アドレスお

よび APN を、REQUEST PDP CONTEXT ACTIVATION メッセージ中のそれらの値と比較することができな

い場合には、MS はネットワークへ理由値'insufficient resources'で REQUEST PDP CONTEXT ACTIVATION REJECT メッセージを送信し、ACTIVATE PDP CONTEXT ACCEPT メッセージを待つ。

静的 PDP アドレスのバッティングがネットワーク側で検出された場合：

MS から受信した REQUEST PDP CONTEXT ACTIVATION メッセージから(23.060 の annex A に従って)誘導された PDP アドレス、PDP タイプおよび APN が、MS が送信した REQUEST PDP CONTEXT ACTIVATION メッセージ内のそれらと一致した場合、ネットワークはバッティングを検出する。

- そのようなバッティングが発生した場合には、MS が開始した PDP コンテキスト活性化が、ネットワークが

要求した PDP コンテキスト活性化よりも優先する。ネットワークは、ネットワークが要求し PDP コンテキスト

活性化処理を終了し、MS が開始した PDP コンテキスト活性化処理を進行させること。

c) MS が、（ネットワーク側で）既に活性化された PDP コンテキストに対する PDP コンテキスト活性化要求を開始

した場合

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 200

i) 既にアクティブになっている PDP コンテキストの APN, PDP タイプ、そして PDP の組合せと同じ組合せ

の APN, PDP タイプ、そして PDP を持つ ACTIVATE PDP CONTEXT REQUEST メッセージを受信し

た場合には、ネットワークは既存の PDP コンテキストと、もし存在する場合にはリンクを持つ全ての

（APN, PDP タイプ、そして PDP の組合せが一致する）PDP コンテキストを、MS への通知なしにローカ

ルに非活性化し、MS から要求された PDP コンテキスト活性化を続けること。

Note: 既存の PDP コンテキストの PDP アドレスが動的で、かつ動的な PDP アドレスを使用する

PDP コンテキストの確立が同じ APN に対して要求された場合、PDP タイプについて 1 つの

APN は 1 つの動的な PDP アドレスを持つことしか許容されていないので、PDP コンテキスト

の複製と認識されること。

ii) それとは異なり（APN、PDP タイプおよび PDP アドレスの異なる組合せ）、NSAPI が既にアクティブにさ

れた PDP コンテキストの NSAPI と一致する場合には、ネットワークは MS への通知なしで既存の PDPコンテキストだけをローカルに非活性化し、要求された PDP コンテキスト活性化を進行させる。

d) ネットワークが、（MS 側で）既に活性化された PDP コンテキストに対する PDP コンテキスト活性化要求を開始

した場合

MS が既に活性化された PDP コンテキストと同じ APN、PDP タイプおよび PDP アドレスの組合せを持つ

REQUEST PDP CONTEXT ACTIVATION メッセージを受信した場合、MS はネットワークへの通知なしで、

既存の PDP コンテキストと、もしあれば（APN、PDP タイプおよび PDP アドレスの組合せが一致する）全て

のリンクされた PDP コンテキストをローカルに非活性化し、要求された PDP コンテキスト活性化を続ける。

MS NetworkACTIVATE PDP CONTEXT REQUEST

Start T3380

ACTIVATE PDP CONTEXT ACCEPT

ACTIVATE PDP CONTEXT REJECTStop T3380

Stop T3380

or

図図図図 6.3/TS 24.008: MS がががが PDP コンテキスト活性化処理を開始する場合コンテキスト活性化処理を開始する場合コンテキスト活性化処理を開始する場合コンテキスト活性化処理を開始する場合

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 201

MS Network

REQUEST PDP CONTEXT ACTIVATIONStart T3385

Start T3380

ACTIVATE PDP CONTEXT ACCEPTStop T3380

ACTIVATE PDP CONTEXT REQUEST

Stop T3380ACTIVATE PDP CONTEXT REJECT

Stop T3385

or

or

REQUEST PDP CONTEXT ACTIVATION REJECT Stop T3385

図図図図 6.4/TS 24.008: ネットワークがネットワークがネットワークがネットワークが PDP コンテキスト活性化処理を開始する場合コンテキスト活性化処理を開始する場合コンテキスト活性化処理を開始する場合コンテキスト活性化処理を開始する場合

6.1.3.2 Secondary PDP Context Activation Procedure （セカンダリ PDP コンテキスト活性化処理）

この処理の目的は、特定の PDP アドレスについて既に 1 つまたは複数の PDP コンテキストが確立されている場合

に、特定の TFT(Traffic Flow Template)および特定 NSAPI 上の QoS プロフィールについて、MS とネットワーク間で

追加的 PDP コンテキストを確立することにある。これらの PDP コンテキストについて、それぞれ異なる QoS プロフィ

ールおよび TFT が要求されるものとする。

6.1.3.2.1 Successful Secondary PDP Context Activation Procedure Initiated by the MS （MSが開始したセカンダリ PDPコンテキスト活性化処理が正常終了した場合）

既にアクティブな PDP コンテキストと同じ PDP アドレスおよび APN を持つ PDP コンテキスト活性化を要求するため

に、MS はネットワークへ ACTIVATE SECONDARY PDP CONTEXT REQUEST メッセージを送信し、ステート PDP-ACTIVE-PENDING に入り、タイマ T3380 を起動すること。メッセージには選択された NSAPI が含まれること。MSは、選択された NSAPI が MS の中で他の SM エンティティによって現在使用されていないことを保証すること。メッセ

ージには、さらに QoS プロフィール、要求された LLC SAPI およびリンクされた TI が含まれること。TFT が存在する

場合には、TFT は SGSN を経由して GGSN にトランスペアレントに送信され、下りリンクデータ送信について、パケッ

トの分類とポリシーを可能にする。

ACTIVATE SECONDARY PDP CONTEXT REQUEST メッセージを受信したネットワークは、Linked TI IE 内で与え

ら得た TI をアクティブな PDP コンテキストの TI と比較検証することによって、メッセージの有効性を検証すること。

SGSN は、該当 PDP アドレス用の PDP コンテキストが既に確立されている場合には、それと同一の GGSN アドレス

を使用すること。要求を受理することができる場合には、ネットワークはネゴシエーションされた QoS に基づいて無線

優先レベルを選択し、ACTIVATE SECONDARY PDP CONTEXT ACCEPT メッセージで応答すること。

メッセージ ACTIVATE SECONDARY PDP CONTEXT ACCEPT を受信した MS は、タイマ T3380 を停止し、ステー

ト PDP-ACTIVE に入ること。ネットワークから受信した提示 QoS パラメータが MS が要求した QoS と異なる場合、

MS はネゴシエーションされた QoS を受理するか、あるいは PDP コンテキスト非活性化処理を開始すること。

GSM では、該当 SAPI 用に論理リンクが未だ確立されていない場合には、MS がネットワーク提示された QoS と選

択された無線優先レベルで、ネットワークから通知された LLC SAPI 用の論理リンク確立を開始すること。ネットワー

クから示された LLC SAPI を MS がサポートしない場合、MS は PDP コンテキスト非活性化処理を開始すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 202

UMTS では、SGSN と MS の双方が、PDP コンテキスト内に LLC SAPI と無線優先度を格納する。 UMTS から GSM への RA 更新が実行される場合、新しい SGSN は、GSM から GSM への RA 更新時と同様に、PDP コンテキスト内

に格納された、ネゴシエーションされた LLC SAPI 、ネゴシエーションされた QoS プロフィール、そして選択された無

線優先度を使用して、論理リンクの確立を開始すること。

UMTS と GSM の双方でオペレーションできる MS は、有効な LLC SAPI を使用すること。一方、UMTS 内でしかオ

ペレーションできない MS は、不要な値の範囲のチェックとネットワーク内でその他の混乱を避けるために、LLC SAPI 値を"LLC SAPI not assigned"として通知すること。

NOTE: 無線優先レベルと LLC SAPI パラメータは、たとえ UMTS 内で使用されなくても、UMTS と GSM ネット

ワーク間のハンドオーバをサポートするために、メッセージ内に入れること。

6.1.3.2.2 Unsuccessful Secondary PDP Context Activation Procedure initiated by the MS （MSが開始したセカンダリ PDPコンテキスト活性化処理が失敗した場合）

ACTIVATE SECONDARY PDP CONTEXT REQUEST メッセージを受信したネットワークは、MS に ACTIVATE SECONDARY PDP CONTEXT REJECT メッセージを送信して、MS が開始した PDP コンテキスト活性化を拒否する

ことができる。メッセージには理由コードが含まれること。通常は次の理由値のうちの 1 つである。


# 30: activation rejected by GGSN;


# 32: service option not supported;

# 33: requested service option not subscribed;

# 34: service option temporarily out of order;

# 41: semantic error in the TFT operation;

# 42: syntactical error in the TFT operation;

# 43: unknown PDP context;

# 44: semantic errors in packet filter(s);

# 45: syntactical errors in packet filter(s);

# 46: PDP context without TFT already activated;


ACTIVATE SECONDARY PDP CONTEXT REJECT メッセージを受信した MS は、タイマ T3380 を停止し、ステート

PDP-INACTIVE に入ること。


異常なケースとして、以下のケースが規定される。

a) タイマの満了

タイマ T3380 の第 1 回目満了時には、MS は ACTIVATE SECONDARY PDP CONTEXT REQUEST を再送

し、タイマ T3380 をリセットして再起動する。この再送は、4 回まで繰り返される。つまり、タイマ T3380 の第 5回満了時には、MS は、再送の実施に関連する可能性のある全てのリソースを開放し、処理を中断すること。

自動 PDP コンテキスト活性化再試行を実行してはならない。

b) MS が、(ネットワーク側で)既にアクティブになっている PDP コンテキストに対する活性化処理を開始した場合

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 203

NSAPI が、既に活性化された PDP コンテキストの NSAPI と一致する場合、ネットワークは既存の PDP コ

ンテキストを MS に対する通知なしでローカルに非活性化し、要求された PDP コンテキスト活性化処理を

進めること。

それ以外の場合、ネットワークはパラメータを次のようにチェックすること。

ネットワークは初に、ACTIVATE SECONDARY PDP CONTEXT REQUEST メッセージ内の Linked TI IE の中で

与えられた TI について、既に活性化された PDP コンテキストがあるかどうかをチェックする。規定された TI 用のア

クティブな PDP コンテキストがない場合には、ネットワークは、理由値"unknown PDP context"とともに ACTIVATE SECONDARY PDP CONTEXT REJECT メッセージで応答する。Linked TI IE 中で与えられた TI 用 PDP コンテキス

トが存在する場合には、要求されたメッセージ内の TFT が、異なるタイプの TFT IE エラーがないか、以下のようにチ

ェックされる。

a) TFT オペレーションの意味エラー

1) TFT operation が"Create a new TFT"以外のオペレーションであった場合

ネットワークは、理由値"semantic error in the TFT operation"といっしょに、活性化要求を拒否すること。

b) TFT オペレーションの構文エラー

1) TFT operation = "Create a new TFT"であって、かつ TFT IE 中のパケットフィルタリストが空の場合

2) TFT IE の符号化において、例えばパケットフィルタフィールドの数とパケットフィルタリスト中のパケットフィ

ルタの数が一致しない場合など、1)以外の構文的なエラーがある場合

ネットワークは、理由値"syntactical error in the TFT operation"といっしょに、活性化要求を拒否すること。

c) パケットフィルタにおける意味エラー

1) パケットフィルタが、パケットフィルタリングの効果がなくなるような矛盾するパケットフィルタコンポーネント

から構成される場合、つまりいかなる IP パケットもこのパケットフィルタに適合しない場合。ネットワークが

パケットフィルタにおける意味的なエラーをどのように判定するかは、この仕様書の範囲外である。

ネットワークは、理由値"semantic errors in packet filter(s)"といっしょに、活性化要求を拒否すること。

d) パケットフィルタにおける構文エラー

1) TFT operation = "Create a new TFT"であり、かつ合成された TFT 内の 2 つまたはそれ以上のパケットフィ

ルタが同一のパケットフィルタ識別子を持つ場合

2) TFT operation = "Create a new TFT"であって、かつ本 PDP アドレスに関連する全ての TFT 内の 2 つまた

はそれ以上のパケットフィルタが、同一のパケットフィルタ処理値を持つ場合

3) パケットフィルタコンポーネント識別子に対する予約値の使用などの、パケットフィルタのコーディングにお

いて、他のタイプの構文的なエラーがある場合

ネットワークは、理由値"syntactical errors in packet filter(s)"といっしょに、活性化要求を拒否すること。

それ以外の場合には、ネットワークは ACTIVATE SECONDARY PDP CONTEXT ACCEPT メッセージを MS に応

答することによって、活性化要求を受け入れること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 204

MS Network

ACTIVATE SECONDARY PDP CONTEXT REQUESTStart T3380

ACTIVATE SECONDARY PDP CONTEXT ACCEPT

ACTIVATE SECONDARY PDP CONTEXT REJECTStop T3380

Stop T3380

or

図図図図 6.5/TS 24.008:セカンダリセカンダリセカンダリセカンダリ PDP コンテキスト活性化処理をコンテキスト活性化処理をコンテキスト活性化処理をコンテキスト活性化処理を MS が開始した場合が開始した場合が開始した場合が開始した場合

6.1.3.3 PDP context modification procedure（PDPコンテキスト修正処理）

PDP コンテキスト修正処理は、ネゴシエーションされた QoS、無線優先度、または PDP コンテキスト活性化処理、セ

カンダリ PDP コンテキスト活性化処理、または前回実行された PDP コンテキスト修正処理の過程でネゴシエーション

された TFT を変更するために、ネットワークあるいは MS によって起動される。 MS はまた、アクティブな PDP コンテ

キスト内の TFT を作成・削除することができる。 PDP コンテキストがアクティブならばいつでも、ネットワークまたは

MS は PDP コンテキスト修正処理を開始することができる。

ネットワークは、外部の PDN アドレス割当てが実行される時、PDP アドレスを更新するために、PDP コンテキスト修

正処理を要求することができる。この場合、MS は MODIFY PDP CONTEXT REQUEST(ネットワーク→MS の方向)メッセージ内で PDP アドレスを受信する。

NOTE: PDP コンテキストがアクティブな場合、SGSN 間 RA 更新によってネットワークが処理を開始することが

できる。

6.1.3.3.1 Network initiated PDP Context Modification （ネットワークが PDPコンテキスト修正を開始する場合）

処理を開始するために、ネットワークは MS に MODIFY PDP CONTEXT REQUEST メッセージを送信し、タイマ

T3386 を起動する。メッセージには、新しい QoS、無線優先レベル、および LLC SAPI が含まれ、これらは MS が

GSM 内で PDP コンテキストと関係するデータを送信するために、下位レイヤで使用される。

本メッセージを受信した MS は、新しい QoS と通知された LLC SAPI を受理するならば、MODIFY PDP CONTEXT ACCEPT メッセージで応答すること。

MS が新しい QoS と通知された LLC SAPI を受理しない場合、MS は PDP コンテキスト用の PDP コンテキスト非活

性化処理を開始すること。DEACTIVATE PDP CONTEXT REQUEST メッセージ内の reject cause IE 値は、"QoS not accepted"とすること。

ネットワークは、MODIFY PDP CONTEXT ACCEPT メッセージを受信したならばタイマ T3386 を停止すること。

GSM では、ネットワークは、MODIFY PDP CONTEXT REQUEST メッセージ内で通知された LLC SAPI 用の新しい

QoS を持つ論理的リンクを使用して、確立、リコンフィギュレーション、または継続すること。

UMTS では、ネットワークは、MODIFY PDP CONTEXT REQUEST メッセージ内で通知された新しい QoS を持った

RAB を使用して、確立、リコンフィギュレーション、または継続すること。

6.1.3.3.2 MS initiated PDP Context Modification accepted by the network （MSが開始した PDPコンテキスト修正がネットワークに受理された場合）

処理を開始するために、MS はネットワークへ MODIFY PDP CONTEXT REQUEST メッセージを送信し、ステート

PDP-MODIFY-PENDING に入り、タイマ T3381 を起動する。メッセージには、要求された新しい QoS および／また

は TFT と要求された LLC SAPI(GSM で使用される)を含めることができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 205

MODIFY PDP CONTEXT REQUEST メッセージを受信したネットワークは、コンテキスト修正を受理するために

MODIFY PDP CONTEXT ACCEPT メッセージを応答することができる。

応答メッセージには、新しい QoS プロフィールに基づいてネゴシエーションされた QoS と無線優先レベル、ならびに

GSM 内で論理リンクが使用すべきネゴシエーションされた LLC SAPI を含めることができる。

MODIFY PDP CONTEXT ACCEPT メッセージを受信した MS は、タイマ T3381 を停止すること。ネットワークから受

信した提示 QoS パラメータが、MS が要求した QoS と異なる場合、MS はネゴシエーションされた QoS を受理するか、

あるいは PDP コンテキスト非活性化処理を開始すること。

注: MS が QoS の修正を要求した場合、もしネットワークが要求された QoS を提供できないために MS の要求を受理

しなかったならば、MS は前回ネゴシエーションされた QoS を維持するか、または新しい QoS を提案すること。したが

って、ネットワークは、MS が要求した QoS を提供できないことが原因で、MS が開始した PDP コンテキスト修正要求

を拒否することはない。

6.1.3.3.3 MS initiated PDP Context Modification not accepted by the network （MSが開始した PDPコンテキスト修正がネットワークに受理されない場合）

MODIFY PDP CONTEXT REQUEST メッセージを受信したネットワークは、MS に MODIFY PDP CONTEXT REJECT メッセージを送信し、MS が開始した PDP コンテキスト修正要求を拒否することができる。メッセージには理

由コードが含まれる。その典型的な値は以下のとおり。


# 32: Service option not supported;

# 41: semantic error in the TFT operation;

# 42: syntactical error in the TFT operation;

# 44: semantic errors in packet filter(s);

# 45: syntactical errors in packet filter(s);


要求メッセージ中の TFT は、以下のように TFT IE エラーのタイプに応じてチェックされる:

a) TFT オペレーションの意味エラー

I. PDP コンテキスト用に既存の TFT が存在する場合、TFT operation = "Create a new TFT"

II. TFT operation の値が"Create a new TFT" 以外であって、かつ PDP コンテキスト用の TFT が存在しない場

合

III. TFT のない他の PDP コンテキスト用に既存の TFT が存在する場合、TFT operation = "Delete existing TFT"

IV. TFT が空であることを表現する場合、TFT operation = "Delete packet filters from existing TFT"

ネットワークは、理由値"semantic error in the TFT operation"で活性化要求を拒否すること。

b) TFT オペレーションの構文エラー

I. TFT operation の値が"Delete existing TFT"以外であって、かつ TFT IE 内のパケットフィルタリストが空の場合

II. TFT operation = "Delete existing TFT"で、TFT IE 内のパケットフィルタリストが空でない場合

III. 元の TFT 内に置換すべきパケットフィルタが存在しない場合、TFT operation = "Replace packet filters in existing TFT"

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 206

IV.元の TFT 内に削除すべきパケットフィルタが存在しない場合、TFT operation = "Delete packet filters from existing TFT"

V. パケットフィルタ識別子の代わりにパケットフィルタを含むパケットフィルタが存在する場合、TFT operation = "Delete packet filters from existing TFT"

VI. TFT IE の符号化において、例えばパケットフィルタフィールドの数とパケットフィルタリスト中のパケットフィルタ

の数が一致しない場合など、他のタイプの構文的なエラーがある場合。

ネットワークは、理由値"syntactical error in the TFT operation"で活性化要求を拒否すること。

c) パケットフィルタの意味エラー

パケットフィルタが、パケットフィルタリングの効果がなくなるような矛盾するパケットフィルタコンポーネントから

構成される場合、つまりいかなる IP パケットもこのパケットフィルタに適合しない場合。ネットワークがパケット

フィルタにおける意味的なエラーをどのように判定するかは、この仕様書の範囲外である。

ネットワークは、理由値"semantic errors in packet filter(s)"といっしょに、活性化要求を拒否すること。

d) パケットフィルタにおける構文エラー

I. TFT operation = "Create a new TFT"または"Add packet filters to existing TFT"であり、かつ合成された

TFT 内の 2 つまたはそれ以上のパケットフィルタが同一のパケットフィルタ識別子を持つ場合

II. TFT operation = "Create a new TFT"または"Add packet filters to existing TFT"または"Replace packet filters in existing TFT" であって、かつ本 PDP アドレスに関連する全ての TFT 内の 2 つまたはそれ以上の

パケットフィルタが、同一のパケットフィルタ処理値を持つ場合

III.パケットフィルタコンポーネント識別子に対する予約値の使用などの、パケットフィルタのコーディングにお

いて、他のタイプの構文的なエラーがある場合

ネットワークは、理由値"syntactical errors in packet filter(s)"といっしょに、活性化要求を拒否すること。

MODIFY PDP CONTEXT REJECT メッセージを受信した MS は、タイマ T3381 を停止し、ステート PDP-ACTIVE に

入ること。



ネットワーク側：

タイマ T3386 の第 1 回目満了時には、MS は MODIFY PDP CONTEXT REQUEST を再送し、タイマ


時、ネットワークは前回ネゴシエーションされた QoS を使用し続けることもできるし、あるいは PDP コンテ

キスト非活性化処理を開始することもできる。

MS 側：

タイマ T3381 の第 1 回目満了時には、MS は MODIFY PDP CONTEXT REQUEST を再送し、タイマ


時、MS は前回ネゴシエーションされた QoS を使用し続けることもできるし、あるいは PDP コンテキスト非

活性化処理を開始することもできる。

b) MS が開始した PDP コンテキスト修正処理とネットワークが開始した PDP コンテキスト修正処理がバッティン

グした場合

MS が MODIFY PDP CONTEXT REQUEST メッセージ送信後にネットワークから MODIFY PDP CONTEXT REQUEST メッセージを受信し、かつ両方のメッセージが同一の TI を含んでおり、かつ MS がまだネットワー

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 207

クから MODIFY PDP CONTEXT ACCEPT メッセージを受信していない場合、MS が開始した PDP コンテキス

ト修正処理とネットワークが開始した PDP コンテキスト修正処理がバッティングしたと見なされる。

ネットワークが MS から受信した MODIFY PDP CONTEXT REQUEST メッセージの TI が、ネットワークがMS に送信した MODIFY PDP CONTEXT REQUEST メッセージの TI と同じ場合、ネットワークは処理のバッ

ティングを検出する。

そのようなバッティングが発生した場合には、ネットワークが開始した PDP コンテキスト修正が、MS が開始し

た PDP コンテキスト修正よりも優先する。 MS は、MS が開始した PDP コンテキスト修正処理を内部で終了し、

ステート PDP-Active に入り、MODIFY PDP CONTEXT ACCEPT メッセージを送信してネットワークが開始し

た PDP コンテキスト修正処理を続行すること。ネットワークは、ステート PDP-MODIFY-PENDING で受信した

MODIFY PDP CONTEXT REQUEST メッセージを無視すること。ネットワークは、MODIFY PDP CONTEXT REQUEST メッセージを MS から受信しない場合と同様に、ネットワークが開始した PDP コンテキスト修正処

理を続行すること。

MS NetworkMODIFY PDP CONTEXT REQUEST

Start T3386

MODIFY PDP CONTEXT ACCEPTStop T3386

図図図図 6.6/TS 24.008: ネットワークが開始したネットワークが開始したネットワークが開始したネットワークが開始した PDP コンテキスト修正処理コンテキスト修正処理コンテキスト修正処理コンテキスト修正処理

MS Network

MODIFY PDP CONTEXT REQUESTStart T3381

MODIFY PDP CONTEXT ACCEPTStop T3381

MODIFY PDP CONTEXT REJEXTStop T3381

or

図図図図 6.7/TS 24.008: MS が開始したが開始したが開始したが開始した PDP コンテキスコンテキスコンテキスコンテキスト修正処理ト修正処理ト修正処理ト修正処理

6.1.3.4 PDP context deactivation procedure（PDPコンテキスト非活性化処理）

本処理の目的は、MS とネットワーク間の既存 PDP コンテキストを非活性化することにある。PDP コンテキスト非活性

化処理は MS が開始することもできるし、ネットワークが開始することもできる。PDP コンテキストがこの特別な TI にだけ関係するのか、あるいは全てのアクティブな PDP コンテキストが同じ PDP アドレスを共有するのか、この特定の

TI に関連する PDP コンテキストを非活性化すべきかを通知するために、DEACTIVATE PDP CONTEXT REQUEST メッセージ内に tear down indicator IE を含めることができる。DEACTIVATE PDP CONTEXT REQUEST メッセージ

内に tear down indicator IE が含まれない場合、この特定の TI に関連した PDP コンテキストだけが非活性化される

こと。

PDP コンテキスト非活性化処理が正常終了した後、関連する NSAPI および TI の値は開放され、別の PDP コンテキ

ストに対して再割当てすることができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 208

6.1.3.4.1 PDP context deactivation initiated by the MS （MSが PDPコンテキスト非活性化処理を開始する場合）

PDP コンテキストを非活性化するために、MS はネットワークへ DEACTIVATE PDP CONTEXT REQUEST メッセー

ジを送信し、ステート PDP-INACTIVE-PENDING に入り、タイマ T3390 を起動すること。メッセージには、PDP コンテ

キストを非活性化するために使用される TI（transaction identifier、トランザクション識別子）と、以下の理由値のうち 1つが含まれる。

# 25: LLC or SNDCP failure(GSM only);


# 36: regular PDP context deactivation; or

# 37: QoS not accepted.

ネットワークは DEACTIVATE PDP CONTEXT ACCEPT メッセージで応答すること。DEACTIVATE PDP CONTEXT ACCEPT メッセージを受信した MS は、タイマ T3390 を停止すること。GSM では、論理的なリンクが別の

PDP コンテキストによって使用されない場合には、MS およびネットワークの双方が、論理的なリンクのローカル開放

処理を開始すること。 UMTS では、ネットワークが本 PDP コンテキストに関連した RAB の開放を開始すること。

6.1.3.4.2 PDP context deactivation initiated by the network （ネットワークが PDPコンテキスト非活性化処理を開始する場合）

PDP コンテキストを非活性化するために、ネットワークは MS へ DEACTIVATE PDP CONTEXT REQUEST メッセー

ジを送信し、タイマ T3395 を起動すること。メッセージには、PDP コンテキストを非活性化するために使用される TI（transaction identifier、トランザクション識別子）と、理由値が含まれる。通常使用される値は以下の値である。

# 25: LLC or SNDCP failure (GSM only);

# 36: regular PDP context deactivation;

# 38: network failure; or

本メッセージを受信した MS は、DEACTIVATE PDP CONTEXT ACCEPT メッセージで応答すること。

DEACTIVATE PDP CONTEXT ACCEPT メッセージを受信したネットワークは、タイマ T3395 を停止すること。GSMでは、論理的なリンクが別の PDP コンテキストによって使用されない場合には、MS およびネットワークの双方が、論

理的なリンクのローカル開放処理を開始すること。 UMTS では、ネットワークが本 PDP コンテキストに関連した RABの開放を開始すること。


異常なケースとして、以下が定義される。


MS 側：

タイマ T3390 の第 1 回目満了時には、MS はメッセージ DEACTIVATE PDP CONTEXT REQUEST を再

送し、タイマ T3390 をリセットして再起動する。この再送は、4 回まで繰り返される。つまり、タイマ T3381の第 5 回満了時、MS は全てのリソースを開放し、PDP コンテキストに関連するデータを削除すること。

ネットワーク側：

タイマ T3395 の第 1 回目満了時には、ネットワークはメッセージ DEACTIVATE PDP CONTEXT REQUEST を再送し、タイマ T3395 をリセットして再起動する。この再送は、4 回まで繰り返される。つまり、

タイマ T3395 の第 5 回満了時、ネットワークは該当 MS 用の PDP コンテキストに関連するデータを削除す

ること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 209

b) MS が開始した PDP コンテキスト非活性化要求とネットワークが開始した PDP コンテキスト非活性化要求の

バッティング

MS が開始した PDP コンテキスト非活性化要求とネットワークが開始した PDP コンテキスト非活性化要求が

バッティングした場合、MS およびネットワークはそれぞれメッセージ DEACTIVATE PDP CONTEXT ACCEPT で応答し、タイマ T3390 および T3395 をそれぞれ停止すること。

MS Network

DEACTIVATE PDP CONTEXT REQUESTStart T3390

DEACTIVATE PDP CONTEXT ACCEPTStop T3390

図図図図 6.8/TS 24.008: MS がががが PDP コンテキスト非活性化処理を開始する場合コンテキスト非活性化処理を開始する場合コンテキスト非活性化処理を開始する場合コンテキスト非活性化処理を開始する場合

MS Network

Start T3395

DEACTIVATE PDP CONTEXT ACCEPTStop T3395

DEACTIVATE PDP CONTEXT REQUEST

図図図図 6.9/TS 24.008: ネットワークがネットワークがネットワークがネットワークが PDP コンテキスト非活性化処理を開始する場合コンテキスト非活性化処理を開始する場合コンテキスト非活性化処理を開始する場合コンテキスト非活性化処理を開始する場合

6.1.3.4a Void

6.1.3.5 Void

6.1.3.6 Receiving a SM STATUS message by a SM entity

MS の SM エンティティが SM STATUS メッセージを受信した場合、ステート遷移は発生せず、無線インタフェースの

観点からは何も特別なアクションをとる必要はない。つまり、ローカルなアクションは可能である。

ネットワーク内で SM STATUS メッセージを受信した場合に取るべきアクションは、実装に依存するオプションである。

7 Examples of structured procedures 構造化処理の例

See 23.108 23.108 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 210

8 Handling of unknown, unforeseen, and erroneous protocol data （未知の、予見できない、誤ったプロトコルデータの処理）

8.1 General（概要）は、本セクションで説明される検査をパスしたメッセージに対して、TS 24.008 中で規定される処理と TS 24.010 の中

で規定される呼に関連する付加サービスの取り扱いが適用される。

本セクションでは、未知の、予見できない、誤ったプロトコルデータの受信側エンティティにおける処理についても規

定する。これらの処理は、"error handling procedures"（「エラーハンドリング処理」）と呼ばれるが、エラーが発生した

状況に対する回復メカニズムを提供することに加えて、プロトコルの将来の拡張用互換性メカニズムについても定義

する。

Facility IE と SS Version Indicator IE の値に関するエラーハンドリングは、本技術的仕様書の範囲外である。それに

ついては、TS 24.010 および GSM 04.8x シリーズで規定される。

サブセクション 8.1～8.8 は、処理の順番に適用すること。

ほとんどのエラーハンドリング処理は、MS にとって mandatoryである。

ネットワーク中の詳細なエラーハンドリング処理は実装に依存するので、PLMN 毎に違う可能性もある。しかしながら、

本プロトコルの拡張が開発されている頃には、ネットワークは本セクション中で示されるエラーハンドリングを持って

いることが mandatory(shall 項目)であり、強く推奨される(should 項目)と仮定されるだろう。セクション 8.2、8.3、8.4、8.5 および 8.7.2 は、ネットワーク中での初期の L3 メッセージの受信におけるエラーハンドリングには適用されない。

すなわち、ネットワークが MS から受信した初期の L3 メッセージを診断した結果、これらのセクションに記述されたエ

ラーを発見した場合には、ネットワークは、以下のいずれかのアクションを取ること。

- クラスマーク識別と、実装依存のアクションを試行

- RR コネクションを開放

さらに、ネットワークのエラーハンドリングは、専用コネクションの間にエラー用の特定の閾値に達しない場合に、

mandatoryまたは「強く推奨」と見なされる。

本セクションでは、以下の用語が使用される:

- IE は、第 10 章で"reserved"として定義されている値のうち少なくとも 1 つの値を含んでいる場合、またはその

値のパートが第 10 章で規定される規則に違反する場合に、構文的に不正と定義される。ただし、タイプ 4 の IE が、その長さインディケータの中で第 10 章で規定された値より大きな長さを指定することは構文的なエラー

ではない。

- メッセージは、それが受信側のリソース（受信側のステートに依存する）および／または TS 24.008、TS 24.010 あるいは適切な GSM 04.8X シリーズの処理に関する部分（第 3, 4, 5 章）と反する情報を含んでいる場

合に、意味的に不正であると定義される。

8.2 Message too short（短すぎるメッセージ）短すぎて完全な message type IE を含むことができないメッセージを受信した場合、そのメッセージを無視すること。

TS 24.007 を参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 211

8.3 Unknown or unforeseen transaction identifier （未知の、または予測できない TI）

8.3.1 Call Control（呼処理） MS およびネットワークは、TI EXT ビット=0 で受信された呼制御メッセージを無視すること。それ以外の場合、つまり

TI EXT ビット=1 の場合、または拡張が使用されない場合には、下に記述された処理を行なうこと。

SETUP、EMERGENCY SETUP あるいは START CC メッセージの TI の値のオクテット 1 部が"111"として符号化さ

れていた場合には、MS およびネットワークは、理由値#81"Invalid transaction identifier value"といっしょに RELEASE COMPLETE メッセージを送信し、それらを拒否すること。RELEASE COMPLETE メッセージ中の TI の値は、メッセ

ージが拒絶される原因となった拡張オクテットを含む、完全な TI の値であること。

SETUP、EMERGENCY SETUP あるいは START CC メッセージ以外のメッセージの TI の値のオクテット 1 部が

"111"として符号化されていた場合には、それらを無視すること。

受信した呼制御メッセージの TI の値のオクテット 1 部が"111"以外の値で符号化されていた場合には、以下の処理

を適用すること。

a) ネットワークと全ての MS が"Network initiated MO call"オプションをサポートしない場合：

EMERGENCY SETUP、SETUP あるいは RELEASE COMPLETE を除く全ての呼制御メッセージについて、

受信した特定の TI がアクティブな呼あるいは進行中の呼に関係があると認められない場合には常に、受信

エンティティは、受信したトランザクション識別子の値を使用して理由値#81"invalid transaction identifier value"といっしょに RELEASE COMPLETE メッセージを送信し、Null ステートに留まること。

ネットワークが"Network initiated MO call"オプション$(CCBS)$をサポートする場合：

EMERGENCY SETUP, SETUP, START CC または RELEASE COMPLETE メッセージを除く全ての呼制御メ

ッセージについて、受信した特定の TI がアクティブな呼あるいは進行中の呼に関係があると認められない場

合には常に、受信エンティティは、受信したトランザクション識別子の値を使用して理由値#81"invalid transaction identifier value"といっしょに RELEASE COMPLETE メッセージを送信し、Null ステートに留まるこ

と。

b) RELEASE COMPLETE メッセージ受信時、その TI がアクティブな呼あるいは進行中の呼に関係があると認

められない場合には、その TI に関連した MM コネクションを開放すること。

c) ネットワークと全ての MS が"Network initiated MO call"オプションをサポートしない場合：

EMERGENCY SETUP メッセージまたは SETUP メッセージ受信時、その TI がアクティブな呼あるいは進行中

の呼に関係があると認められず、かつ TI のフラグが誤って"1"に設定されている場合には、そのメッセージを

無視すること。


EMERGENCY SETUP、START CC、または SETUP メッセージ受信時、その TI がアクティブな呼あるいは進

行中の呼に関係があると認められず、かつ TI のフラグが誤って"1"に設定されている場合には、そのメッセー

ジを無視すること。

d) MS が SETUP メッセージ受信時、その TI がアクティブな呼あるいは進行中の呼に関係があることが認められ

る場合、この SETUP メッセージを無視すること。

e) ネットワークが"Network initiated MO call"オプションをサポートしない場合

ネットワークが EMERGENCY SETUP または SETUP メッセージ受信時、その TI がアクティブな呼あるいは進

行中の呼に関係があることが認められる場合、ネットワークはこのメッセージを扱う必要がない。ネットワーク

は他のアクションを実行することもできる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 212


ネットワークが EMERGENCY SETUP メッセージまたは START CC メッセージ受信時、その TI がアクティブ

な呼あるいは進行中の呼に関係があることが認められる場合、ネットワークはこのメッセージを扱う必要がな

い。ネットワークは他のアクションを実行することもできる。

START_CC メッセージによってトランザクションが確立されておらず、かつネットワークが"recall present"ステ

ート(N0.6)にある場合に SETUP メッセージを受信した場合も同様である。

8.3.2 Session Management（セッション管理） MS およびネットワークは、TI EXT ビット=0 を持つセッション管理メッセージを無視すること。それ以外の場合には、

下記の処理を適用すること。

a) ネットワークが ACTIVATE PDP CONTEXT REQUEST、ACTIVATE SECONDARY PDP CONTEXT REQUEST、あるいは SM-STATUS 以外の全てのセッション管理メッセージを受信時、その TI が、アクティブ

なコンテキスト、または活性化／非活性化処理が進行中のコンテキスト、または [ 近]非活性化されたコンテ

キストに関係があると認められない場合、ネットワークは拡張オクテット内に含まれる受信した TI の値を使用

して、理由値#81"invalid transaction identifier value" といっしょに SM-STATUS メッセージを送信すること。そ

して PDP-INACTIVE ステートに留まること。

b) MS が REQUEST PDP CONTEXT ACTIVATION あるいは SM-STATUS 以外の全てのセッション管理メッセ

ージを受信時、その TI が、アクティブなコンテキスト、または活性化／非活性化処理が進行中のコンテキスト、

または [ 近]非活性化されたコンテキストに関係があると認められない場合、MS は拡張オクテット内に含ま

れる受信した TI の値を使用して、理由値#81"invalid transaction identifier value" といっしょに SM-STATUS メ

ッセージを送信すること。そして PDP-INACTIVE ステートに留まること。

c) TI フラグが"1"に設定されている REQUEST PDP CONTEXT ACTIVATION メッセージを受信した場合、その

メッセージを無視すること。

d) ACTIVATE PDP CONTEXT REQUEST メッセージ受信時、特定の TI が活性化処理に関係すると認められ

ず、かつその TI フラグが"1"に設定されている場合、そのメッセージを無視すること。

e) ネットワークが ACTIVATE PDP CONTEXT REQUEST メッセージ受信時、その TI が PDP-INACTIVE ステ

ートにない PDP コンテキストと関係すると認められた場合、ネットワークは MS に通知なく、受信した TI に関

係する古い PDP コンテキストを非活性化すること。さらに、ネットワークは、受信したメッセージ内に通知され

る新しい PDP コンテキストの活性化処理を継続すること。

f) MS が REQUEST PDP CONTEXT ACTIVATION メッセージ受信時、その TI がステート PDP-INACTIVE に

ない PDP コンテキストと関係すると認められた場合、MS は、受信したトランザクション識別子に関係のある古

い PDP コンテキストをローカルに非活性化すること。さらに、MS は受信したメッセージ内に通知される新しい

PDP コンテキストの活性化処理を継続すること。

8.4 Unknown or unforeseen message type (未知または予期せぬメッセージタイプ)

MS が受信した RR、MM あるいは CC メッセージのメッセージタイプが、PD 用に定義されていないものであった場合、

または非送達確認モードにおいて受信側で実装されていない場合には、MS はこれらのメッセージを無視すること。

MS が受信した RR、MM あるいは CC メッセージのメッセージタイプが、PD 用に定義されていないものであった場合、

または非送達確認モードにおいて受信側で実装されていない場合には、MS は理由値＃97"message type non-existent or not implemented"といっしょにステータスメッセージ（STATUS または MM STATUS 、PD に依存）を返すこ

と。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 213

MS が受信した GMM メッセージまたは SM メッセージのメッセージタイプが、PD 用に定義されていないものであった

場合、または受信側で実装されていない場合には、MS は理由値＃97"message type non-existent or not implemented"といっしょにステータスメッセージ(GMM STATUS あるいは SM STATUS、PD に依存)を返すこと。

ネットワークが受信した MM メッセージのメッセージタイプが、PD 用に定義されていないものであった場合、または

受信側が実装していない場合には、プロトコルステートのどのステートで MS からその PD を持つ非請求メッセージ

（unsolicited message）を受信するかはプロトコル内では予測不能であり、ネットワーク側のアクションは実装に依存す

る。そうでなければ、もしネットワークが受信したメッセージのメッセージタイプが PD に対して定義されていないか、ま

たは受信側で実装されていない場合には、ネットワークは理由値#97"message type non-existent or not implemented"といっしょにステータスメッセージ(STATUS、MM STATUS、GMM STATUS あるいは SM STATUS、どれになるか

は PD に依存)を返すだけで、メッセージを無視すること。

NOTE: 決められた方向で PD 用に定義されていないメッセージタイプは、受信側からは PD 用に定義されていな

いメッセージタイプとして見なされる。TS 24.007[20]参照。

MS が受信したメッセージが、プロトコルステートと互換性がない場合、MS は、RR コネクションが存在する場合には

理由値#98"Message type not compatible with protocol state"でステータスメッセージ(STATUS, MM STATUS、PD に

依存)を返すという点を除いて、メッセージを無視すること。メッセージが GMM メッセージの場合には、理由値#98 "Message type not compatible with protocol state"で GMM-STATUS メッセージを返すこと。メッセージが SM メッセー

ジの場合には、理由値#98 "Message type not compatible with protocol state"で SM-STATUS メッセージを返すこと。

ネットワークが受信したメッセージが、プロトコルステートと互換性のないものであった場合、ネットワークの取るべき

アクションは実装に依存する。

NOTE: 非送達確認 LLC の GMM および SM の使用は、結果的に"not compatible with the protocol state"メッセージを導くかもしれない。

8.5 Non-semantical mandatory information element errors （Non-semantical mandatory IEのエラー）

以下のメッセージを受信した場合、

- "imperative message part"エラー、または

- "missing mandatory IE"エラー

メッセージが以下を含むかが診断される。

- syntactically incorrect mandatory IE、または

- IE がメッセージ内で未知だが、"comprehension required" として符号化されている（GSM 04.07 参照）、または

- 順序外の IE、"comprehension required"として符号化される (セクション 04.07 参照)

is received,

- MS は以下の処理を行なうこと。

メッセージがセクション 8.5.1、8.5.2、8.5.3、8.5.4 および 8.5.5 の a)または b）にリストされたメッセージのうちの

1 つでない場合には、MS は RR コネクションが存在するならば、理由値# 96 "Invalid mandatory information"でステータスメッセージ(STATUS, MM STATUS、PD に依存)を返すという事実を除いてメッセージを無視する

こと。メッセージが GMM メッセージの場合、理由値#96 " Invalid mandatory information"で GMM-STATUS メ

ッセージを返すこと。メッセージが SM メッセージの場合、理由値#96 " Invalid mandatory information"で SM-STATUS メッセージを返すこと。

- ネットワークは以下の処理を行なうこと。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 214

メッセージがセクション 8.5.3 の b、c、d)か、e)、および 8.5.5 a)または c）の 1 つでない場合、ネットワー

クは以下のいずれかの処理を行なうこと。

- メッセージの処理を試行する（これ以上の詳細なアクションは実装依存）、または

- 理由値#96 " Invalid mandatory information"でステータスメッセージ(STATUS または MM STATUS 、PD に依存)を返す点を除いてメッセージを無視する。

8.5.1 Radio resource management（無線リソース管理） 04.18 参照。

8.5.2 Mobility management（モビリティ管理） MM メッセージに関する例外ケースは記載されない。

8.5.3 Call control（呼制御） a) メッセージが SETUP メッセージの場合、理由値# 96 "invalid mandatory information" で a RELEASE

COMPLETE メッセージを返すこと。

b) メッセージが DISCONNECT メッセージの場合、理由値# 96 "invalid mandatory information" で a RELEASE COMPLETE メッセージを返し、セクション 5.4 の"call clearing"が通常どおり適用されること。

c) メッセージが RELEASE メッセージの場合、理由値# 96 "invalid mandatory information" で RELEASE COMPLETE メッセージを返すこと。

d) メッセージが RELEASE COMPLETE メッセージの場合、メッセージは通常の RELEASE COMPLETE メッセ

ージとして処理されること。

e) メッセージが HOLD REJECT または RETRIEVE REJECT メッセージの場合、通常の HOLD REJECT または RETRIEVE REJECT メッセージとして処理すること。

f) ネットワークが受信したメッセージが STATUS メッセージの場合、理由値# 96 "invalid mandatory information" で RELEASE COMPLETE メッセージを返すことができる。

8.5.4 GMM mobility management（GMMモビリティ管理）モビリティ管理メッセージに関しては、例外ケースは記載されない。

8.5.5 Session management（セッション管理） a) メッセージが DEACTIVATE PDP CONTEXT REQUEST の場合、DEACTIVATE PDP CONTEXT ACCEPT

メッセージを返すこと。該当コンテキストに関連する全リソースを開放すること。

b) メッセージが REQUEST PDP CONTEXT ACTIVATION の場合、理由値# 96 "invalid mandatory information" で REQUEST PDP CONTEXT REJECT メッセージを返すこと。

c) メッセージが ACTIVATE PDP CONTEXT REQUEST の場合、理由値# 96 "invalid mandatory information" でACTIVATE PDP CONTEXT REJECT メッセージを返すこと。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 215

8.6 Unknown and unforeseen IEs in the non-imperative message part （非必須メッセージパート内で未知の、予測できない IE）

8.6.1 IEIs unknown in the message（メッセージ内で未知の IE） MS は、"comprehension required"としてエンコードされていないメッセージ内の IE は全て無視すること (GSM 04.07 を

参照)。

ネットワークも同様のアプローチを取ること。

8.6.2 Out of sequence Ies（順序外の IE） MS は、"comprehension required"としてエンコードされていないメッセージ内の順序外の IE は全て無視すること (TS 24.007 を参照)。


8.6.3 Repeated Ies（反復 IE）フォーマット T、TV、または TLV の IE がメッセージ中で反復され、その IE の反復が本技術仕様書の第 9 章で規定

されていない場合には、初の IE の内容だけが処理されて、それ以降の IE の繰り返しは無視されること。IE の反

復が仕様化されている場合には、仕様化された反復 IE の内容だけを処理すること。IE の反復が制限を超えた場合

には、反復制限までに初に現れる IE の内容だけが処理され、その後の IE の反復はすべて無視すること。


8.7 Non-imperative message part errors （非必須メッセージパートのエラー）

本カテゴリには以下のものが含まれる。

- 構文的に不正なオプション IE

- 条件付 IE のエラー

8.7.1 Syntactically incorrect optional Ies （構文的に不正なオプション IE）

MS は、メッセージ内にある構文的に不正なオプション IE を全て、メッセージ中に存在しないかのように扱うこと。

ネットワークも同様のアプローチをとること。

8.7.2 Conditional IE errors（条件付 IEのエラー） MS が RR、MM あるいは CC メッセージ診断 "missing conditional IE" エラーまたは"unexpected conditional IE"エラ

ーを受信した場合、または MS が受信した RR、MM あるいは CC メッセージに少なくとも 1 つの構文が不正な条件

付 IE が含まれる場合、MS は、もし RR コネクションが存在する場合には理由値# 100 "conditional IE error"でステー

タスメッセージ(STATUS または MM STATUS、PD に依存)を返すという事実を除き、メッセージを無視すること。

MS が GMM または SM メッセージ診断 "missing conditional IE" エラーまたは"unexpected conditional IE"エラーを

受信した場合、または MS が受信した GMM あるいは SM メッセージに少なくとも 1 つの構文が不正な条件付 IE が

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 216

含まれる場合、MS はメッセージを無視し、理由値# 100 "conditional IE error"でステータスメッセージ(GMM STATUS または SM STATUS、PD に依存)を返すこと。

ネットワークがメッセージと診断"missing conditional IE" エラーまたは"unexpected conditional IE"エラーを受信した場

合、またはネットワークが受信した GMM あるいは SM メッセージに少なくとも 1 つの構文が不正な条件付 IE が含ま

れる場合、ネットワークは以下のいずれかのアクションを取ること。

- メッセージの処理を試行する（より詳細なアクションは実装に依存）、または

- 理由値# 100 "conditional IE error"でステータスメッセージ(STATUS, MM STATUS, GMM STATUS 、または SM STATUS、PD に依存)を返す点を除き、メッセージを無視すること。

8.8 Messages with semantically incorrect contents （意味的に不正な内容のメッセージ）

意味的に不正な内容を持つメッセージを受信した場合、TS 24.008 の処理の予測リアクション (つまり第 3、4、5 章)が実行される。ただし、そのようなリアクションが仕様化されていない場合には、MS は、もし RR コネクションが存在す

るならば理由値# 95 "semantically incorrect message"でステータスメッセージ(STATUS または MM STATUS、PD に

依存)を返すという事実を除き、メッセージを無視すること。

ネットワーク側の処理は、ステータスメッセージが通常のように送信されない点を除き、MS 側の処理と同一とするこ

と。

値パートの Facility IE（TS 24.080 で規定される）の意味のチェックは、技術仕様書 TS 24.010 および GSM 04.8x シリ

ーズで仕様化される。

9 Message functional definitions and contents (メッセージの機能定義と内容)

本章では、TS 24.008 に定義された L3 プロトコルのメッセージの構造を定義する。これらは TS 24.007 に定義され

るような標準的な L3 メッセージである。

本章には以下の定義が含まれる:

a) メッセージの方向と使用に関する簡単な説明。メッセージが以下のものを含むか否かを説明。

1. ローカルシグニフィカント。つまり、接続または切断アクセスのいずれかにのみ関係

2. アクセスシグニフィカント。つまり、接続と切断アクセスの双方に関係するが、ネットワークには無関係

3. デュアルシグニフィカント。つまり、接続または切断アクセス、およびネットワークに関係

4. グローバルシグニフィカント。つまり、接続と切断アクセスの双方、およびネットワークに関関係

b) メッセージ中の既知の IE と、メッセージ内でのそれらの IE の順番ををリストアップした表。その表の中にたと

え含まれていなくとも、CS 呼制御用メッセージだけでなく、shift IE もまた考慮すること。反復される可能性の

ある IE は全て、明示的に通知される (メッセージの必須パートを構成する V および LV フォーマットの IE は、

メッセージ内の非必須パートを構成する T, TV, および TLV フォーマットの IE より前に置かれる。TS 24.007参照)。ハーフオクテット長の連続する IE の( 大)シーケンスでは、初の IE はハーフオクテット長であり、オ

クテット N のビット 1～4 を占有し、第 2 の IE はオクテット N のビット 5～8 を占有し、第 3 の IE は、オクテット

N+1 のビット 1～4 を占有する。そのようなシーケンスは常にエレメントを偶数個持つ。

各 IE について、表では、以下のことを示す。

1. IE のフォーマットが T, TV, または TLV ならば、IEI は 16 進で表記される、通常、IE のタイプ毎にデフォル

トの IEI が存在する。つまり、同一プロトコルでも IE のタイプが異なれば IEI の値も異なる。IEI がハーフオ

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 217

クテット長の場合、その IEI を表示する際には 16 進数の値の後にハイフン（-）を付けることが規定されて

いる（例えば、B- など）。

NOTE 同一プロトコルの異なるメッセージ内の異なる IE について、同一の IEI が使用されることもある。

2. （エレメントの意味を連想させる）IE の名称。メッセージ内の IE を参照する場合、TS 24.008 では"IE" また

は "information element"の後に IE 名称を（通常はイタリック体で）記載する。

3. IE のタイプ名（IE の値部分のコーディングを示す）。一般的には、TS 24.008 の 10 章の各セクションで IEの値部分について説明する。

4. IE の要求通知（M, C, または O）については、TS 24.007 内で定義される。

5. IE のフォーマット（T, V, TV, LV, TLV）については、TS 24.007 内で定義される。

6. メッセージ内の IE の長さ（または許容される長さの範囲）はオクテットで表記され、ここで"?"は IE の大

長がリンクレイヤプロトコルにのみ規制され、Facility IE の場合には、TS 24.010 内で規定されるより詳細

な条件が適用できる。本表記方法は標準化されたものではない。

c) サブセクションでは、TS 24.008 内で標準化されるその他の条件と共に、関連するメッセージ内の存在要求条

件 C または O の条件について規定し、IE を含めるか否か、そのような IE の不在が何を意味するか、そして

存在要求条件 C の IE が、IE の存在の有無の静的条件について規定する(TS 24.007 参照)。

9.1 Messages for Radio Resources management （RR管理用メッセージ）

04.18 参照。

9.2 Messages for mobility management（MM用メッセージ）表 9.2.1/TS 24.008 に、MM(モビリティ管理)用メッセージについてまとめた。

表表表表 9.2.1/TS 24.008: MM 用メッセージ用メッセージ用メッセージ用メッセージ

Registration messages: Reference IMSI DETACH INDICATION 9.2.12 LOCATION UPDATING ACCEPT 9.2.13 LOCATION UPDATING REJECT 9.2.14 LOCATION UPDATING REQUEST 9.2.15

Security messages: Reference AUTHENTICATION REJECT 9.2.1 AUTHENTICATION REQUEST 9.2.2 AUTHENTICATION RESPONSE 9.2.3 IDENTITY REQUEST 9.2.10 IDENTITY RESPONSE 9.2.11 TMSI REALLOCATION COMMAND 9.2.17 TMSI REALLOCATION COMPLETE 9.2.18

Connection management messages: Reference CM SERVICE ACCEPT 9.2.5 CM SERVICE REJECT 9.2.6 CM SERVICE ABORT 9.2.7 CM SERVICE REQUEST 9.2.9 CM RE-ESTABLISHMENT REQUEST 9.2.4 ABORT 9.2.8

Miscellaneous message: Reference MM INFORMATION 9.2.15a MM STATUS 9.2.16 MM NULL 9.2.19

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 218

9.2.1 Authentication reject（認証拒否）本メッセージはネットワークが MS に対して、認証が失敗したこと（そして受信した MS が処理を中断すべきであるこ

と）を通知するために送信する。表 9.2.2/TS 24.008 参照。

メッセージタイプ： AUTHENTICATION REJECT

Significance: dual

Direction: ネットワーク→MS

表表表表 9.2.2/TS 24.008: AUTHENTICATION REJECT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Authentication Reject Message type M V 1 message type 10.4

9.2.2 Authentication request（認証要求）本メッセージは、MS の ID 認証を開始するためにネットワークが MS に送信する。表 9.2.3/TS 24.008 を参照。

メッセージタイプ： AUTHENTICATION REQUEST

シグニフィカンス： dual

方向：ネットワーク→MS

表表表表 9.2.3/TS 24.008: AUTHENTICATION REQUEST メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Authentication Request Message type M V 1 message type 10.4 Ciphering key sequence Ciphering key sequence M V 1/2 number Number 10.5.1.2 Spare half octet Spare half octet M V 1/2 10.5.1.8 Authentication Auth. Parameter RAND M V 16 parameter RAND (UMTS

challenge or GSM challenge) 10.5.3.1

20 Authentication Auth. Parameter AUTN O TLV 18 Parameter AUTN 10.5.3.1.1

9.2.2.1 Authentication Parameter AUTN（認証パラメータ AUTN）

本 IE は、認証チャレンジが UMTS 認証チャレンジの場合に限って存在する。本 IE がない場合には GSM 認証チャ

レンジ、存在する場合には UMTS 認証チャレンジと定義される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 219

9.2.3 Authentication response（認証応答）本メッセージは、算出された応答を MS がネットワークに配信するために送信される。表 9.2.4/TS 24.008 参照。

メッセージタイプ： AUTHENTICATION RESPONSE


方向： MS→ネットワーク

表表表表 9.2.4/TS 24.008: AUTHENTICATION RESPONSE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Authentication Response Message type M V 1 message type 10.4 Authentication Response Auth. Response parameter M V 4 parameter 10.5.3.2 21 Authentication Response Auth. Response parameter O TLV 3-14 Parameter (extension) 10.5.3.2.1

9.2.3.1 Authentication Response Parameter（認証応答パラメータ）

本 IE には、GSM 認証チャレンジの場合には SRES が、UMTS 認証チャレンジの場合には RES（の全てまたは 4上位オクテット（most significant octet）が含まれる。

9.2.3.2 Authentication Response Parameter (extension) （認証応答パラメータ（拡張））

認証チャレンジが GSM 認証チャレンジの場合に限り本 IE が含まれ、RES パラメータの値は 4 オクテット長以上で

あること。本 IE には、RES の下位ビット(least significant remaining bit)が含まれること（4 上位オクテットは、

Authentication Response Parameter IE 内で送信されること（9.2.3.1 参照））。

9.2.3a Authentication Failure （認証の失敗）本メッセージは、ネットワークの認証が失敗したことを通知するために、ネットワークが MS に送信する。表

9.2.4a/TS 24.008 参照。

メッセージタイプ： AUTHENTICATION FAILURE



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 220

表表表表 9.2.4a/TS 24.008: AUTHENTICATION FAILURE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 Protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Authentication Failure Message type M V 1 Message type 10.4 Reject Cause

Reject Cause 10.5.3.6

M V 1

22 Authentication Failure parameter Authentication Failure parameter O TLV 16 10.5.3.2.2

9.2.3a.1 Authentication Failure parameter（認証失敗パラメータ）

本 IE は、拒否理由が'Synch failure.' の場合に送信されること。本 IE には、SIM カードからの認証チャレンジに対す

る応答（これから AUTS が作られる）も含まれる（TS 33.102 参照）。

9.2.4 CM Re-establishment request（CM再確立要求）本メッセージは、前のコネクションが失敗した場合に、コネクションの再確立を要求するために、MS がネットワークに

対して送信する。表 9.2.5/TS 24.008 参照。

メッセージタイプ： CM RE-ESTABLISHMENT REQUEST



表表表表 9.2.5/TS 24.008: CM RE-ESTABLISHMENT REQUEST メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V ½ protocol discriminator 10.2 Skip Indicator Skip Indicator M V ½ 10.3.1 CM Re-Establishment Message type M V 1 Request message type 10.4 Ciphering key sequence Ciphering key sequence M V ½ Number number 10.5.1.2 Spare half octet Spare half octet M V ½ 10.5.1.8 Mobile station Mobile station M LV 4 Classmark classmark 2 10.5.1.6 Mobile identity Mobile identity M LV 2-9 10.5.1.4 13 Location area Location area C TV 6 Identification identification 10.5.1.3

9.2.4.1 Location area identification（LAI）

TMSI を使用して MS を識別する場合には、該当モバイルの ID を明瞭にするために、location area identification IE を使用すること。SIM カードには LAI として保存される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 221

9.2.4.2 Mobile Station Classmark（MSクラスマーク）

本 IE は、使用中の周波数帯に関連するマルチバンド MS クラスマーク 2 用に含まれること。

9.2.5 CM service accept（CMサービス許容）本メッセージは、ネットワークが MS に対して、要求されたサービスが既に許容されたことを通知するために送信する。

表 9.2.6/TS 24.008 参照。

メッセージタイプ： CM SERVICE ACCEPT



表表表表 9.2.6/TS 24.008: CM SERVICE ACCEPT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 CM Service Accept Message type M V 1 message type 10.4

9.2.5a CM service prompt $(CCBS)$（CMサービスプロンプト$(CCBS)$）

"Network initiated MO call"オプションをサポートしない MS は、本メッセージを PD に対して定義されていないメッセ

ージタイプのメッセージとして扱うこと。

本メッセージは、ネットワークが MS に対して、特定の SAPI を使用して特定の CM プロトコル用のサービスの確立

を要求する場合に送信される。例えば CS コネクションの確立は SAPI 0 上で、付加サービス活性化は SAPI 0 上で、

SM 送信は SAPI 3 上で行なう。表 9.2.7/TS 24.008 を参照。

メッセージタイプ： CM SERVICE PROMPT



表表表表 9.2.7/TS 24.008: CM SERVICE PROMPT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 CM Service Prompt Message type M V 1 message type 10.4 PD and SAPI of CM PD and SAPI M V 1 10.5.1.10a

9.2.6 CM service reject（CMサービス拒否）本メッセージは、ネットワークが MS に対して、要求されたサービスを提供できないことを通知するために送信される。

表 9.2.8/TS 24.008 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 222

メッセージタイプ： CM SERVICE REJECT



表表表表 9.2.8/TS 24.008: CM SERVICE REJECT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 CM Service Reject Message type M V 1 message type 10.4 Reject cause Reject cause M V 1 10.5.3.6

9.2.7 CM service abort（CMサービス中断）本メッセージは、MS がネットワークに対して、進行中の初の MM コネクション確立の中断と RR コネクションの開

放を要求するために送信する。表 9.2.9/TS 24.008 参照。

メッセージタイプ： CM SERVICE ABORT



表表表表 9.2.9/TS 24.008: CM SERVICE ABORT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 CM Service Abort Message type M V 1 message type 10.4

9.2.8 Abort（中断）本メッセージは、ネットワークが MS に対して、全ての MM コネクションの中断を開始し、中断理由を通知するために

送信する。表 9.2.10/TS 24.008 参照。

メッセージタイプ： ABORT



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 223

表表表表 9.2.10/TS 24.008: ABORT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Abort Message type M V 1 message type 10.4 Reject cause Reject cause M V 1 10.5.3.6

9.2.9 CM service request（CMサービス要求）本メッセージは、MS がネットワークに対して、CM サブレイヤエンティティ用のサービス（例えば CS コネクションの確

立、付加サービスの活性化、SM 送信、ロケーションサービスなど）を要求するために送信する。表 9.2.11/TS 24.008 参照。

メッセージタイプ： CM SERVICE REQUEST



表表表表 9.2.11/TS 24.008: CM SERVICE REQUEST メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V ½ protocol discriminator 10.2 Skip Indicator Skip Indicator M V ½ 10.3.1 CM Service Request Message type M V 1 message type 10.4 CM service type CM service type M V ½ 10.5.3.3 Ciphering key sequence Ciphering key sequence M V ½ number number 10.5.1.2 Mobile station Mobile station M LV 4 classmark classmark 2 10.5.1.6 Mobile identity Mobile identity M LV 2-9 10.5.1.4 8- Priority Priority Level O TV 1 10.5.1.11


使用中の周波数帯に関連するマルチバンド MS クラスマーク 2 用に、本 IE が含まれること。

9.2.9.2 Priority（優先度）

eMLPP をサポートする MS が、要求された優先度を通知するために含めることができる。

本 IE は、CM サービスタイプが以下の場合のみ、意味を持つ。すなわち、

MS 発呼の確立

緊急呼の確立

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 224

音声グループ呼の確立

音声ブロードキャスト呼の確立

9.2.10 Identity request（ID要求）本メッセージは、ネットワークが MS に対して、特定の ID を MS がネットワークに対して提出することを要求するため

に送信される。

メッセージタイプ： IDENTITY REQUEST



表表表表 9.2.12/TS 24.008: IDENTITY REQUEST メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Identity Request Message type M V 1 message type 10.4 Identity type Identity type M V 1/2 10.5.3.4 Spare half octet Spare half octet M V 1/2 10.5.1.8

9.2.11 Identity response（ID応答）本メッセージは、MS がネットワークに対して、要求された ID を提供するための IDENTITY REQUEST メッセージに

対する応答として送信される。

メッセージタイプ： IDENTITY RESPONSE



表表表表 9.2.13/TS 24.008: IDENTITY RESPONSE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Identity Response Message type M V 1 message type 10.4 Mobile identity Mobile identity M LV 2-10 10.5.1.4

9.2.12 IMSI detach indication（IMSIデタッチ通知）本メッセージは、ネットワーク内の不活性化通知を設定するために、MS がネットワークに対して送信する。表

9.2.14/TS 24.008 参照。

メッセージタイプ： IMSI DETACH INDICATION

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 225



表表表表 9.2.14/TS 24.008: IMSI DETACH INDICATION メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 IMSI Detach Indication Message type M V 1 message type 10.4 Mobile station Mobile station M V 1 Classmark classmark 1 10.5.1.5 Mobile identity Mobile identity M LV 2-9 10.5.1.4



9.2.13 Location updating accept（位置登録更新の許容）本メッセージは、ネットワークが MS に対して、ネットワーク内の IMSI 更新またはアタッチ処理が完了したことを通知

するために送信される。

メッセージタイプ： LOCATION UPDATING ACCEPT



表表表表 9.2.15/TS 24.008: LOCATION UPDATING ACCEPT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Location Updating Message type M V 1 Accept message type 10.4 Location area Location area M V 5 Identification identification 10.5.1.3 17 Mobile identity Mobile identity O TLV 3-10 10.5.1.4 A1 Follow on proceed Follow on proceed O T 1 10.5.3.7 A2 CTS permission CTS permission O T 1 10.5.3.10

9.2.13.1 Follow on proceed

ネットワークが MS に対して、MS が同じ RR コネクションを使用して MM コネクション確立を試行できることを通知し

たい場合に、follow on proceed IE が使用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 226

9.2.13.2 CTS permission

ネットワークが MS に対して、LA 内の GSM-Cordless Telephony System の使用を MS に許可したい場合に、

CTS permission IE が使用される。

9.2.14 Location updating reject（位置登録更新の拒否）本メッセージは、ネットワークが MS に対して、IMSI 更新またはアタッチ処理が失敗したことを通知するために送信

する。表 9.2.16/TS 24.008 参照。

メッセージタイプ： LOCATION UPDATING REJECT



表表表表 9.2.16/TS 24.008: LOCATION UPDATING REJECT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Location Updating Message type M V 1 Reject message type 10.4 Reject cause Reject cause M V 1 10.5.3.6

9.2.15 Location updating request（位置登録更新要求）本メッセージは、MS のロケーションファイル（通常の更新か、または定期的更新）の更新を要求する場合、または

IMSI アタッチを要求する場合のいずれかに、MS がネットワークに対して送信する。表 9.2.17/TS 24.008 参照。

メッセージタイプ： LOCATION UPDATING REQUEST



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 227

表表表表 9.2.17/TS 24.008: LOCATION UPDATING REQUEST メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Location Updating Message type M V 1 Request message type 10.4 Location updating type Location updating type M V 1/2 10.5.3.5 Ciphering key sequence Ciphering key sequence M V 1/2 Number number 10.5.1.2 Location area Location area M V 5 Identification identification 10.5.1.3 Mobile station Mobile station M V 1 Classmark classmark 1 10.5.1.5 Mobile identity Mobile identity M LV 2-9 10.5.1.4 33 Mobile station Mobile station O TLV 5 classmark for UMTS classmark 2 10.5.1.6

9.2.15.1 Location area identification（LAI）

SIM カード内に保存される LAI が使用される。



9.2.15.3 Mobile Station Classmark for UMTS（UMTS用 MSクラスマーク）

MS が UMTS ネットワーク内で使用される場合に、本 IE が含まれること。MS が GSM ネットワーク内で使用される

場合には、本 IE が含まれてはならない。

9.2.15a MM information（MM情報）本メッセージは、加入者固有の情報を MS に提供するために、ネットワークが MS に対して送信する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 228

メッセージタイプ： MM INFORMATION



表表表表 9.2.18/TS 24.008 MM INFORMATION メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 MM Information Message type M V 1 message type 10.4 43 Full name for network Network Name O TLV 3-? 10.5.3.5a 45 Short name for network Network Name O TLV 3-? 10.5.3.5a 46 Local time zone Time Zone O TV 2 10.5.3.8 47 Universal time and local time

zone Time Zone and Time O TV 8

10.5.3.9 48 LSA Identity LSA Identifier

10.5.3.11 O TLV 2-5

49 Network Daylight Saving Time Daylight Saving Time O TLV 3 10.5.3.12

9.2.15a.1 Full name for network

ネットワークは本 IE を送信できる。本 IE が送信された場合には、本 IE のコンテンツは"full length name of the network"を通知し、ネットワークは MS が Channel Request メッセージを送信するセルの LAI 内に含まれる MCC と MNC に MS を関連付けることを希望することを通知する。

9.2.15a.2 Short name for network

ネットワークは本 IE を送信できる。本 IE が送信された場合には、本 IE のコンテンツは"abbreviated name of the network"を通知し、ネットワークは MS が Channel Request メッセージを送信するセルの LAI 内に含まれる MCC と MNC に MS を関連付けることを希望することを通知する。

9.2.15a.3 Local time zone（ローカルタイムゾーン）

ネットワークは本 IE を送信できる。MS は、自身が Channel Request メッセージを送信したセルの LA に、本タイム

ゾーンが適用されると仮定すること。

ローカルタイムゾーンがサマータイム用に調整されている場合には、ネットワークはそのことを IE Network Daylight Saving Time を入れることによって通知すること。

9.2.15a.4 Universal time and local time zone（ユニバーサルタイムとローカルタイムゾーン）

ネットワークは本 IE を送信できる。MS は、自身が Channel Request メッセージを送信したセルの LA に、本タイム

ゾーンが適用されると仮定すること。MS は、時間情報が正確であると仮定してはならない。

ローカルタイムゾーンがサマータイム用に調整されている場合には、ネットワークはそのことを IE Network Daylight Saving Time を入れることによって通知すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 229

9.2.15a.5 LSA Identity

ネットワークは本 IE を送信できる。本 IE のコンテンツは、サービスセルの LSA identity を示す。

9.2.15a.6 Network Daylight Saving Time

ネットワークは本 IE を送信できる。本 IE が送信された場合、本 IE のコンテンツは、ローカルタイムゾーンを調整す

るために使用された値を示す。

9.2.16 MM Status 本メッセージは、第 8 章でリストアップされた特定のエラーが発生したことを通知するために、任意の時刻に、MS ま

たはネットワークが送信する。表 9.2.19/TS 24.008 参照。

メッセージタイプ： MM STATUS

シグニフィカンス： local

方向： both

表表表表 9.2.19/TS 24.008: MM STATUS メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 MM Status message Message type M V 1 type 10.4 Reject cause Reject cause M V 1 10.5.3.6

9.2.17 TMSI reallocation command（TMSI再配置コマンド）本メッセージは、TMSI を再配置または削除するために、ネットワークが MS に対して送信する。表 9.2.20/TS 24.008 参照。

メッセージタイプ： TMSI REALLOCATION COMMAND



表表表表 9.2.20/TS 24.008: TMSI REALLOCATION COMMAND メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 TMSI Reallocation Message type M V 1 Command message type 10.4 Location area Location area M V 5 identification identification 10.5.1.3 Mobile identity Mobile identity M LV 2-9 10.5.1.4

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 230

9.2.18 TMSI reallocation complete（TMSI再配置完了）本メッセージは、TMSI の再配置または削除が実行されたことを通知するために、MS がネットワークに対して送信す

る。表 9.2.21/TS 24.008 参照。

メッセージタイプ： TMSI REALLOCATION COMPLETE



表表表表 9.2.21/TS 24.008: TMSI REALLOCATION COMPLETE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 TMSI Reallocation Message type M V 1 Complete message type 10.4

9.2.19 MM Null 本メッセージは、MS→ネットワークの方向で送信される。

本メッセージは無線インタフェース上では使用されない。ネットワークが受信した場合には、それを無視すること。

本メッセージの導入によって、インターワーキング関連の問題が解消できる。

メッセージタイプ： MM NULL

表表表表 9.2.22/TS 24.008 MM NULL メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 MM Null message Message type M V 1 type 10.4

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 231

9.3 Messages for circuit-switched call control （CS呼制御用メッセージ）

表 9.54/TS 24.008 は、CS 呼制御用メッセージをまとめたものである。

表表表表 9.54/TS 24.008: 回線交換モードコネクション制御用メッセージ回線交換モードコネクション制御用メッセージ回線交換モードコネクション制御用メッセージ回線交換モードコネクション制御用メッセージ

Call establishment messages: Reference ALERTING 9.3.1 CALL CONFIRMED 1) 9.3.2 CALL PROCEEDING 9.3.3 CONNECT 9.3.5 CONNECT ACKNOWLEDGE 9.3.6 EMERGENCY SETUP 1) 9.3.8 PROGRESS 9.3.17 SETUP 9.3.23

Call information phase messages: Reference MODIFY 1) 9.3.13 MODIFY COMPLETE 1) 9.3.14 MODIFY REJECT 1) 9.3.15 USER INFORMATION 9.3.31

Call clearing messages: Reference DISCONNECT 9.3.7 RELEASE 9.3.18 RELEASE COMPLETE 9.3.19

Messages for supplementary service control Reference FACILITY 9.3.9 HOLD 1) 9.3.10 HOLD ACKNOWLEDGE 1) 9.3.11 HOLD REJECT 1) 9.3.12 RETRIEVE 1) 9.3.20 RETRIEVE ACKNOWLEDGE 1) 9.3.21 RETRIEVE REJECT 1) 9.3.22

Miscellaneous messages Reference CONGESTION CONTROL 9.3.4 NOTIFY 9.3.16 START DTMF 1) 9.3.24 START DTMF ACKNOWLEDGE 1) 9.3.25 START DTMF REJECT 1) 9.3.26 STATUS 9.3.27 STATUS ENQUIRY 9.3.28 STOP DTMF 1) 9.3.29 STOP DTMF ACKNOWLEDGE 1) 9.3.30

NOTE: Blue Book ITU-T Rec. Q.931 にはサポートされない。

9.3.1 Alerting（アラート）

9.3.1.1 Alerting (Network→MS direction) （Alerting (ネットワーク→MS 方向)）

本メッセージは、発呼中の MS に対して、着信ユーザアラート処理が開始されたことを通知するために、ネットワーク

が送信する。

表 9.55/TS 24.008 参照。

メッセージタイプ： ALERTING

シグニフィカンス： global

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 232


表表表表 9.55/TS 24.008: ALERTING メッセージコンメッセージコンメッセージコンメッセージコンテンツテンツテンツテンツ (ネットワークネットワークネットワークネットワーク→MS 方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Alerting Message type M V 1 message type 10.4 1C Facility Facility O TLV 2-? 10.5.4.15 1E Progress indicator Progress indicator O TLV 4 10.5.4.21 7E User-user User-user O TLV 3-131 10.5.4.25

9.3.1.1.1 Facility

本 IE は、付加サービスの機能オペレーション用に使用することができる。

9.3.1.1.2 Progress indicator

本 IE は、以下の場合に、ネットワークがメッセージに含めることができる。

- 例えばインターワーキングのイベントにおいて、進行中の呼に関する情報をパスするため。および／または

- MS に音声用ユーザコネクションをアタッチするため

9.3.1.1.3 User-user

本 IE は、着信リモートユーザが ALERTING メッセージ内に user-user IE を含めた場合に、ネットワークが含める

ことができる。

9.3.1.2 Alerting (MS→Network direction) （Alerting (MS→ネットワーク方向)）

本メッセージは、着信リモートユーザのアラートが開始されたことを通知するために、着信 MS がネットワークに対し

て送信する。

表 9.55a/TS 24.008 参照。

メッセージタイプ： ALERTING



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 233

表表表表 9.55a/TS 24.008: ALERTING メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ (MS→ネットワークネットワークネットワークネットワーク方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Alerting Message type M V 1 message type 10.4 1C Facility Facility O TLV 2-? 10.5.4.15 7E User-user User-user O TLV 3-131 10.5.4.25 7F SS version SS version indicator O TLV 2-3 10.5.4.24

9.3.1.2.1 Facility


9.3.1.2.2 User-user

本 IE は、着信 MS が発信リモートユーザに対して情報を返すことを希望した場合に、含めることができる。

9.3.1.2.3 SS version

本 IE は、メッセージ内に facilityIE が存在しない場合に含まれること。

本 IE が含まれるか否か（included か excluded か）は TS 24.010 に定義される。本 IE は、TS 24.010 で明示的に

要求されない限り、送信してはならない。

9.3.2 Call confirmed 本メッセージは、着信 MS が、着信呼要求があったことを確認するために送信する。

表 9.56/TS 24.008 参照。

メッセージタイプ： CALL CONFIRMED



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 234

表表表表 9.56/TS 24.008: CALL CONFIRMED メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Call confirmed Message type M V 1 message type 10.4 D- Repeat Indicator Repeat Indicator C TV 1 10.5.4.22 04 Bearer capability 1 Bearer capability O TLV 3-16 10.5.4.5 04 Bearer capability 2 Bearer capability O TLV 3-16 10.5.4.5 08 Cause Cause O TLV 4-32 10.5.4.11 15 CC Capabilities Call Control Capabilities O TLV 3 10.5.4.5a 2D Stream Identifier Stream Identifier O TLV 3 10.5.4.28

9.3.2.1 Repeat indicator

メッセージ内に bearer capability 1 IE と bearer capability 2 IE の双方が含まれる場合に、repeat indicator IE が

含まれること。

9.3.2.2 Bearer capability 1 and bearer capability 2 （Bearer capability 1と bearer capability 2）

下記の 5 つの条件のうち、少なくとも 1 つが成立したならば、bearer capability 1 IE が含まれること。

- MS が、着信 SETUP メッセージの bearer capability 1 IE で与えられるベアラケーパビリティ以外のケーパビ

リティを希望する場合

- bearer capability 1 IE が消失した、または SETUP メッセージ内で完全に仕様化されていない場合

- SETUP メッセージ内で受信した bearer capability 1 IE が受理され、かつ MS の"radio channel requirement"が"full rate support only mobile station"以外である場合

- SETUP メッセージ内で受信した bearer capability 1 IE が音声を通知し、かつ受理され、かつ MS が

GSM version 1 以外の音声バージョンをサポートする場合。デフォルトの UMTS AMR 音声バージョンが仮

定されている UMTS 音声呼を除く。

- SETUP メッセージ内で受信した bearer capability 1 IE に"fixed network user rate"パラメータが含まれる場

合

SETUP メッセージ内で、bearer capability 1 IE の後に bearer capability 2 IE が続く場合、上記規則は bearer capability 1 IE と bearer capability 2 IE の双方に適用される。TS 27.001 で規定されるケースを除き、bearer capability1 と 2 のどちらかを含める必要がある場合には、双方含めること。

さらに、TS 27.001 で規定されるケースで、MS が bearer capability IE の順番の逆転を希望した場合には、双方の

bearer capability IE が存在する場合もある。

MS が代替呼モード（インコール修正の仮定で入ることができる）用のケーパビリティの通知を希望した場合、bearer capability2 IE を追加することによって、通知する（セクション 5.3.6 参照）。

9.3.2.3 Cause

本 IE は、MS は互換性があるがユーザがビジーな場合に入れられる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 235

9.3.2.4 CC Capabilities

本 IE は、MS が自身の呼制御ケーパビリティを通知するために追加することができる。

9.3.2.5 Stream Identifier

MS がマルチコールをサポートする場合には、本 IE を入れること。

9.3.3 Call proceeding 本メッセージは、ネットワークが要求された呼確立情報を受信したので、これ以上呼確立情報を受信しないことを通

知するために、ネットワークが発呼 MS に対して送信する。

表 9.57/TS 24.008 参照。

メッセージタイプ： CALL PROCEEDING



表表表表 9.57/TS 24.008: CALL PROCEEDING メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Call proceeding Message type M V 1 message type 10.4 D- Repeat Indicator Repeat Indicator C TV 1 10.5.4.22 04 Bearer capability 1 Bearer capability O TLV 3-16 10.5.4.5 04 Bearer capability 2 Bearer capability O TLV 3-16 10.5.4.5 1C Facility Facility O TLV 2-? 10.5.4.15 1E Progress indicator Progress indicator O TLV 4 10.5.4.21 8- Priority granted Priority Level O TV 1 10.5.1.11 2F Network Call Control Network Call Control cap. O TLV 3 Capabilities 10.5.4.29


本 IE は、メッセージ内に bearer capability 1 IE と bearer capability 2 IE の双方が含まれる場合にのみ、入れられ

る。

9.3.3.2 Bearer capability 1 and bearer capability 2 （Bearer capability 1 と bearer capability 2）

ネットワークが TS 27.001 で規定されるネゴシエーション可能なパラメータのうちの少なくとも 1 つを指定する必要が

ある場合、または SETUP メッセージ内で受信した bearer capability 1 IE に"fixed network user rate"パラメータが

含まれていた場合に、bearer capability 1 IE が入れられる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 236

SETUP メッセージ内で bearer capability 1 IE の後に bearer capability 2 IE が続く場合には、上記規則が bearer capability 1 IE と bearer capability 2 IE の双方に適用される。TS 27.001 で規定されるケースを除き、bearer capability1 と 2 のどちらかを含める必要がある場合には、双方含めること。

9.3.3.3 Facility


9.3.3.4 Progress Indicator

以下の目的で、本 IE を入れることができる。



9.3.3.5 Priority granted

eMLPP が使用され、かつネットワークによって割当てられた優先度が MS が要求した優先度と異なる場合に、ネット

ワークは優先度フィールド（priority field）を提供する。

9.3.3.6 Network Call Control Capabilities

ネットワークがマルチコールをサポートする場合、ネットワークが自身の呼制御ケーパビリティを通知するために、本

IE を含めること。

9.3.4 Congestion control（輻輳制御）本メッセージは、USER INFORMATION メッセージのトランザクション上でフロー制御の確立／完了を通知するため

に、ネットワークが送信する。

表 9.58/TS 24.008 参照。

メッセージタイプ： CONGESTION CONTROL

シグニフィカンス： local (note)


表表表表 9.58/TS 24.008: CONGESTION CONTROL メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Congestion control Message type M V 1 message type 10.4 Congestion level Congestion level M V 1/2 10.5.4.12 Spare half octet Spare half octet M V 1/2 10.5.1.8 08 Cause Cause O TLV 4-32 10.5.4.11

NOTE: 本メッセージは、ローカルな意味を持つが、グローバルな意味での情報を伝送することもできる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 237

9.3.4.1 Cause

輻輳状況が原因でユーザ対ユーザ情報が廃棄された場合に、本 IE が入れられる。

9.3.5 Connect

9.3.5.1 Connect (Network→MS direction) （Connect (ネットワーク→MS 方向)）

本メッセージは、着信ユーザによって呼が受け入れられたことを通知するために、ネットワークが MS に送信する。

表 9.59/TS 24.008 参照。

メッセージタイプ： CONNECT



表表表表 9.59/TS 24.008: CONNECT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ(ネットワークネットワークネットワークネットワーク→MS 方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Connect Message type M V 1 message type 10.4 1C Facility Facility O TLV 2-? 10.5.4.15 1E Progress indicator Progress indicator O TLV 4 10.5.4.21 4C Connected number Connected number O TLV 3-14 10.5.4.13 4D Connected subaddress Connected subaddress O TLV 2-23 10.5.4.14 7E User-user User-user O TLV 3-131 10.5.4.25

9.3.5.1.1 Facility



以下の目的で、ネットワークは本 IE を含めることができる。



9.3.5.1.3 User-user

リモートユーザが CONNECT メッセージ内で user- user IE を含む呼をアワードした場合に、ネットワークは本 IE を

含めることができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 238

9.3.5.2 Connect (MS→Network direction)

本メッセージは、着信 MS がネットワークに対して、着信ユーザによって呼が受け付けられたことを通知するために

送信される。

表 9.59a/TS 24.008 参照。

メッセージタイプ： CONNECT



表表表表 9.59a/TS 24.008: CONNECT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ (MS→ネットワークネットワークネットワークネットワーク方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Connect Message type M V 1 message type 10.4 1C Facility Facility O TLV 2-? 10.5.4.15 4D Connected subaddress Connected subaddress O TLV 2-23 10.5.4.14 7E User-user User-user O TLV 3-131 10.5.4.25 7F SS version SS version indicator O TLV 2-3 10.5.4.24 2D Stream Identifier Stream Identifier O TLV 3 10.5.4.28

9.3.5.2.1 Facility


9.3.5.2.2 User-user

応答 MS が発信リモートユーザに対してユーザ情報を返したい場合に、本 IE を含めることができる。


メッセージ内に facility IE が存在しない場合に、本 IE が含まれること。

本 IE は、TS 24.010 に規定されるように、含まれるか、あるいは含まれないこと。本 IE は TS 24.010 によって明示

的に要求されない限り、送信してはならない。

9.3.5.2.4 Stream Identifier

MS が CALL CONFIRMED メッセージ内で SI 値として"No Bearer"を通知した場合に、マルチ呼をサポートする

MS が本 IE を含めること。

9.3.6 Connect acknowledge 本メッセージは、ネットワークが着呼側 MS に対して、MS が呼をアワードしたことを通知するために送信する。また、

着呼側 MS はネットワークに対して、提示されたコネクションを確認する（acknowledge）ために本メッセージを送信

すること。

表 9.60/TS 24.008 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 239

メッセージタイプ： CONNECT ACKNOWLEDGE


方向： both

表表表表 9.60/TS 24.008: CONNECT ACKNOWLEDGE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Connect acknowledge Message type M V 1 message type 10.4

9.3.7 Disconnect

9.3.7.1 Disconnect (ネットワーク→MS 方向)

本メッセージは、ネットワークが End-to-End のコネクションがクリアされたことを通知するために送信する。

表 9.61/TS 24.008 参照。

メッセージタイプ： DISCONNECT



表表表表 9.61/TS 24.008: DISCONNECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (ネットワークネットワークネットワークネットワーク→MS 方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Disconnect Message type M V 1 message type 10.4 Cause Cause M LV 3-31 10.5.4.11 1C Facility Facility O TLV 2-? 10.5.4.15 1E Progress indicator Progress indicator O TLV 4 10.5.4.21 7E User-user User-user O TLV 3-131 10.5.4.25 7B Allowed actions $(CCBS)$ Allowed actions O TLV 3 10.5.4.27

9.3.7.1.1 Facility

本 IE は、User-user サービスなどの付加サービス機能的オペレーション用に使用することができる。


ネットワークは、MS に音声用コネクションをアタッチさせ、呼クリア中に特定方向で反応させるために、本 IE を含め

る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 240

9.3.7.1.3 User-user

リモートユーザが呼のクリアを開始し、user-user IE を DISCONNECT メッセージ内に入れた場合に、ネットワーク

は本 IE を含めることができる。

9.3.7.1.4 Allowed actions $(CCBS)$

MS に対して、より多くのリアクションに関する情報を通知するために、ネットワークは本 IE を含めることができる。

9.3.7.2 Disconnect (MS→ネットワーク方向)

MS はネットワークに対して end-to-end のコネクションのクリアを要求するために、本メッセージを送信する。

表 9.61a/TS 24.008 参照。

メッセージタイプ： DISCONNECT



表表表表 9.61a/TS 24.008: DISCONNECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (MS→ネットワーク方向ネットワーク方向ネットワーク方向ネットワーク方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Disconnect Message type M V 1 message type 10.4 Cause Cause M LV 3-31 10.5.4.11 1C Facility Facility O TLV 2-? 10.5.4.15 7E User-user User-user O TLV 3-131 10.5.4.25 7F SS version SS version indicator O TLV 2-3 10.5.4.24

9.3.7.2.1 Facility

本 IE は、User-user サービスなどの付加サービス機能的オペレーション用に使用することができる。

9.3.7.2.2 User-user

MS が呼のクリアを通知し、呼クリア時にリモートユーザに対してユーザ情報をパスすることを希望した場合に、本 IEが含まれる。


メッセージ内に facility IE が存在しない場合には、本 IE を含めてはならない。

TS 24.010 内に規定されるように、本 IE は included または excluded であること。本 IE は、TS 24.010 によって明

示的に要求されない限り、送信してはならない。

9.3.8 Emergency setup 緊急呼の確立を通知するために、MS は本メッセージを送信する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 241

表 9.62/TS 24.008 参照。

メッセージタイプ： EMERGENCY SETUP



表表表表 9.62/TS 24.008: EMERGENCY SETUP メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Emergency setup Message type M V 1 message type 10.4 04 Bearer capability Bearer capability O TLV 3-9 10.5.4.5 2D Stream Identifier Stream Identifier O TLV 3 10.5.4.28

9.3.8.1 Bearer capability

本 IE が含まれていない場合には、ネットワークはデフォルトで音声呼を仮定し、フルレートスピーチバージョン 1 を選

択すること。本 IE が含まれている場合には、IE は音声呼、適切なスピーチバージョンを通知し、無線チャネル要求

フィールドの適切な値を持つこと。

UMTS 音声呼の場合、デフォルト UMTS AMR スピーチバージョンを仮定すること。


マルチコールをサポートする MS は、本 IE を含めること。

9.3.9 Facility

9.3.9.1 Facility (ネットワーク→MS direction)

付加サービスを要求または送達確認（ACK）するために、ネットワークは MS に対して本メッセージを送信すること。

起動すべき付加サービスと、その適切なパラメータは、facility IE 内で指定される。

表 9.62a/TS 24.008 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 242

メッセージタイプ： FACILITY

シグニフィカンス： local (NOTE 1)


表表表表 9.62a/TS 24.008: FACILITY メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (ネットワークネットワークネットワークネットワーク→MS 方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Facility Message type M V 1 message type 10.4 Facility (note 2) Facility M LV 1-? 10.5.4.15

NOTE 1: 本メッセージはローカルで意味を持つ。しかし、グローバルな意味の情報を伝送することも可能。

NOTE 2: facility IE は、L3 メッセージ内の大オクテット数で規定される上限値を除いて、長さの制限はない。

GSM 04.06 参照。

9.3.9.2 Facility (MS→ネットワーク方向)

付加サービスを要求または確認するために、MS はネットワークに本メッセージを送信する。起動すべき付加サービ

スおよびその関連するパラメータは、facility IE 内で指定される。

表 9.62b/TS 24.008 参照。

メッセージタイプ： FACILITY

シグニフィカンス： local (note 1)


表表表表 9.62b/TS 24.008: FACILITY メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (MS→ネットワーク方向ネットワーク方向ネットワーク方向ネットワーク方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Facility Message type M V 1 message type 10.4 Facility (note 2) Facility M LV 1-? 10.5.4.15 7F SS version SS version indicator O TLV 2-3 10.5.4.24

NOTE 1: 本メッセージはローカルで意味を持つ。しかし、グローバルな意味の情報を伝送することも可能。

NOTE 2: facility IE は、L3 メッセージ内の大オクテット数で規定される上限値を除いて、長さの制限はない。

GSM 04.06 参照。


TS 24.010 内に定義されるように、本 IE は included または excluded であること。本 IE は、TS 24.010 によって明


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 243

9.3.10 Hold 既存呼の保留機能を要求するために、MS は本メッセージを送信する。

HOLD メッセージのコンテンツについては、表 9.62c/TS 24.008 参照。

本メッセージの使用方法については、TS 24.010 参照。

メッセージタイプ： HOLD



表表表表 9.62c/TS 24.008: HOLD メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Hold Message type M V 1 message type 10.4

9.3.11 Hold Acknowledge 保留機能が正常に実行されたことを通知するために、ネットワークは本メッセージを送信する。

HOLD ACKNOWLEDGE メッセージのコンテンツについては、9.62d/TS 24.008 参照。


メッセージタイプ： HOLD ACKNOWLEDGE



表表表表 9.62d/TS 24.008: HOLD ACKNOWLEDGE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Hold Acknowledge Message type M V 1 message type 10.4

9.3.12 Hold Reject 保留呼の要求拒否を通知するために、ネットワークは本メッセージを送信する。

HOLD REJECT メッセージのコンテンツについては、9.62e/TS 24.008 参照。


メッセージタイプ： HOLD REJECT


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 244


表表表表 9.62e/TS 24.008: HOLD REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Hold Reject Message type M V 1 message type 10.4 Cause 10.5.4.11 M LV 3-31

9.3.13 Modify 呼のベアラケーパビリティの変更を要求するために、MS がネットワークに対して、またはネットワークが MS に対し

て本メッセージを送信する。

表 9.63/TS 24.008 参照。

メッセージタイプ： MODIFY


方向： both

表表表表 9.63/TS 24.008: MODIFY メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Modify Message type M V 1 message type 10.4 Bearer capability Bearer capability M LV 2-15 10.5.4.5 7C Low layer comp. Low layer comp. O TLV 2-18 10.5.4.18 7D High layer comp. High layer comp. O TLV 2-5 10.5.4.16 A3 Reverse call setup Reverse call setup O T 1 direction Direction 10.5.4.22a A4 Immediate modification indicator Immediate modification indicator O T 1 10.5.4. 31

9.3.13.1 Low layer compatibility

初期 SETUP メッセージに本 IE が含まれていたならば、本 IE を含めること。

9.3.13.2 High layer compatibility


9.3.13.3 Reverse call setup direction

MS→ネットワーク方向では、本 IE が含まれるか省略されるかは、セクション 5.3.4.3.1 内に規定されるルールに従

う。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 245

9.3.13.4 Immediate modification indicator

即時インコール修正が要求された場合に限り、本 IE が含まれること。

9.3.14 Modify complete 呼のベアラケーパビリティの変更要求が完了したことを通知するために、MS がネットワークに対して、またはネット

ワークが MS に対して本メッセージを送信する。

表 9.64/TS 24.008 参照。

メッセージタイプ： MODIFY COMPLETE


方向： both

表表表表 9.64/TS 24.008: MODIFY COMPLETE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Modify complete Message type M V 1 message type 10.4 Bearer capability Bearer capability M LV 2-15 10.5.4.5 7C Low layer comp. Low layer comp. O TLV 2-18 10.5.4.18 7D High layer comp. High layer comp. O TLV 2-5 10.5.4.16 A3 Reverse call setup Reverse call setup O T 1 direction direction 10.5.4.22a





9.3.14.3 Reverse call setup direction

本 IE が含まれるか省略されるかは、セクション 5.3.4.3.2 内に規定されるルールに従う。

9.3.15 Modify reject 呼のベアラケーパビリティの変更要求が失敗したことを通知するために、MS がネットワークに対して、またはネット

ワークが MS に対して本メッセージを送信する。

表 9.65/TS 24.008 参照。

メッセージタイプ： MODIFY REJECT


方向： both

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 246

表表表表 9.65/TS 24.008: MODIFY REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Modify reject Message type M V 1 message type 10.4 Bearer capability Bearer capability M LV 2-15 10.5.4.5 Cause Cause M LV 3-31 10.5.4.11 7C Low layer comp. Low layer comp. O TLV 2-18 10.5.4.18 7D High layer comp. High layer comp. O TLV 2-5 10.5.4.16





9.3.16 Notify ユーザサスペンドなど呼に関する情報を通知するために、MS からネットワーク、またはネットワークから MS に対し

て本メッセージが送信される。

表 9.66/TS 24.008 参照。

メッセージタイプ： NOTIFY

シグニフィカンス： access

方向： both

表表表表 9.66/TS 24.008: NOTIFY メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Notify Message type M V 1 message type 10.4 Notification indicator Notification indicator M V 1 10.5.4.20

9.3.17 Progress インバンド情報／パターンの提供と共に、インターワーキングのイベント内またはコネクション内における呼の進行状

況を通知するために、ネットワークは MS に対して本メッセージを送信する。

表 9.67/TS 24.008 参照。

メッセージタイプ： PROGRESS

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 247



表表表表 9.67/TS 24.008: PROGRESS メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Progress Message type M V 1 message type 10.4 Progress indicator Progress indicator M LV 3 10.5.4.21 7E User-user User-user O TLV 3-131 10.5.4.25

9.3.17.1 User-user

ネットワークが active ステートになる前に、リモートユーザによって呼がクリアされた場合に、リモートユーザが呼の

クリア時にユーザ情報をパスすることを希望していることを通知するために、ネットワークが PROGRESS メッセージ

を送信した場合、本 IE が含まれる。

9.3.17a CC-Establishment $(CCBS)$ "Network initiated MO call"オプションをサポートしない MS は、本メッセージを PD 用のメッセージタイプが定義され

ていないメッセージとして扱うこと。

本メッセージは、MS が確立を試行すべき呼に関する情報を提供するために、ネットワークが MS に送信する。

表 9.67a/TS 24.008.参照。

メッセージタイプ： CC-ESTABLISHMENT シグニフィカンス： local 方向：ネットワーク→MS

表表表表 9.67a/TS 24.008: CC-Establishment メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 CC-Establishment Message type M V 1 message type 10.4 Setup container Container M LV 3-n 10.5.4.22a

* 4 番目の IE onward から、MS→ネットワーク方向で、SETUP メッセージと同様の方法で、メッセージは符号

化される。

9.3.17a.1 Void

9.3.17a.2 Setup container

本 IE は、SETUP メッセージ（MS→ネットワーク方向）のコンテンツを含む。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 248

9.3.17b CC-Establishment confirmed $(CCBS)$ "Network initiated MO call"オプションをサポートしないネットワークは、本メッセージを PD 用のメッセージタイプが

定義されていないメッセージとして扱うこと。

本メッセージは、MS が開始できる呼のために要求されたチャネル特性を通知するために、MS がネットワークに対し

て送信する。

表 9.67b/TS 24.008 参照。

メッセージタイプ： CC-ESTABLISHMENT CONFIRMED



表表表表 9.67b/TS 24.008: CC-ESTABLISHMENT CONFIRMED メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 CC-Establishment Confirmed Message type M V 1 message type 10.4 D- Repeat Indicator Repeat Indicator C TV 1 10.5.4.22 04 Bearer capability 1 Bearer capability M TLV 3-10 10.5.4.5 04 Bearer capability 2 Bearer capability O TLV 3-10 10.5.4.5 08 Cause Cause O TLV 4-32 10.5.4.11

9.3.17b.1 Repeat indicator

メッセージ内に bearer capability 1 IE と bearer capability 2 IE の双方が含まれていた場合に、repeat indicator IEが含まれること。

9.3.17b.2 Bearer capability 1 and bearer capability 2

そのトランザクション上で送信すべき次のいずれかの SETUP メッセージ内で、bearer capability 2 IE の後に

bearer capability 1 IE がある場合には、メッセージは bearer capability 2 IE を含むこと。

UMTS 音声呼の場合、デフォルト UMTS AMR スピーチバージョンを仮定すること。

9.3.17b.3 Cause

MS は互換性があるがユーザがビジーの場合に、本 IE が含まれること。

9.3.18 Release

9.3.18.1 Release (ネットワーク→MS方向)

ネットワークがトランザクション識別子を開放しようとしており、受信側装置は RELEASE COMPLETE 送信後にトラ

ンザクション識別子を開放しなくてはならないことを通知するために、ネットワークは MS に対して本メッセージを送信

する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 249

表 9.68/TS 24.008 参照。

メッセージタイプ： RELEASE

シグニフィカンス： local (note)


表表表表 9.68/TS 24.008: RELEASE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (ネットワークネットワークネットワークネットワーク→MS 方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Release Message type M V 1 message type 10.4 08 Cause Cause O TLV 4-32 10.5.4.11 08 Second cause Cause O TLV 4-32 10.5.4.11 1C Facility Facility O TLV 2-? 10.5.4.15 7E User-user User-user O TLV 3-131 10.5.4.25

NOTE: 本メッセージはローカルで意味を持つ。しかし、初の呼クリアメッセージ内で使用される場合には、グ

ローバルな意味の情報を伝送することも可能。

9.3.18.1.1 Cause

呼のクリアを開始するために使用された本メッセージには、本 IE が含まれること。

9.3.18.1.2 Second cause

セクション 5.4.4.1.2.3 " Abnormal cases " (ネットワークによるクリアの開始)で説明される条件下において、本 IE を

含めることができる。

9.3.18.1.3 Facility

本 IE は、付加サービス機能的オペレーション用に含めることができる。

9.3.18.1.4 User-user

呼のクリアを開始するために RELEASE メッセージが使用された場合に、user-user 情報をリモートユーザから伝送

するために、ネットワーク→MS 方向で本 IE を含めることができる。

9.3.18.2 Release (MS→ネットワーク方向)

MS がトランザクション識別子を開放しようとしており、RELEASE COMPLETE メッセージ送信後に受信側装置がト

ランザクション識別子を開放する必要があることを通知するために、MS からネットワークに対して本メッセージが送

信される。

表 9.68a/TS 24.008 参照。

メッセージタイプ： RELEASE

シグニフィカンス： local (注)

方向： MS→ネットワーク方向

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 250

表表表表 9.68a/TS 24.008: RELEASE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ (MS→ネットワーク方向ネットワーク方向ネットワーク方向ネットワーク方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Release Message type M V 1 message type 10.4 08 Cause Cause O TLV 4-32 10.5.4.11 08 Second cause Cause O TLV 4-32 10.5.4.11 1C Facility Facility O TLV 2-? 10.5.4.15 7E User-user User-user O TLV 3-131 10.5.4.25 7F SS version SS version indicator O TLV 2-3 10.5.4.24

注：本メッセージはローカルで意味を持つ。しかし、初の呼クリアメッセージ内で使用される場合には、グ


9.3.18.2.1 Cause

呼のクリアを開始するために使用された本メッセージには、本 IE が含まれること。

9.3.18.2.2 Second cause

セクション 5.4.3.5 "Abnormal cases" (MS によるクリアの開始)で説明される条件下において、本 IE を含めることが

できる。

9.3.18.2.3 Facility

本 IE は、付加サービス機能的オペレーション用に含めることができる。


呼のクリアを開始するために RELEASE メッセージが使用された場合に、MS が呼のクリア時にユーザ情報をリモー

トユーザにパスすることを希望することを通知するために、本 IE が含まれる。


メッセージ内に facility IE が含まれない場合には、本 IE が含まれてはならない。



9.3.18a Recall $(CCBS)$ "Network initiated MO call"オプションをサポートしない MS は、本メッセージを PD 用にメッセージタイプが定義され

ていないメッセージとして扱うこと。

本メッセージは、SETUP メッセージの送信を開始するために、ネットワークから MS に対して送信される。追加的に、

本メッセージにユーザ通知用の情報を提供する。

表 9.68b/TS 24.008 参照。

メッセージタイプ： RECALL

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 251

シグニフィカンス： local 方向：ネットワーク→MS

表表表表 9.68b/TS 24.008: Recall メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Recall Message type M V 1 message type 10.4 Recall Type Recall Type M V 1 10.5.4.21a Facility Facility M LV 2-n 10.5.4.15

9.3.18a.1 Recall Type

Recall Type IE の使用目的は、再発呼の理由を説明することである。

9.3.18a.2 Facility

付加サービスの機能的オペレーションのために、本 IE が含まれること。

9.3.19 Release complete

9.3.19.1 Release complete (ネットワーク→MS方向)

ネットワークがトランザクション識別子を開放し、MS がトランザクション識別子を開放すべきであることを通知するた

めに、ネットワークは MS に対して本メッセージを送信する。

表 9.69/TS 24.008 参照。

メッセージタイプ： RELEASE COMPLETE


方向：ネットワーク→MS 方向

表表表表 9.69/TS 24.008: RELEASE COMPLETE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (ネットワークネットワークネットワークネットワーク→MS 方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Release complete Message type M V 1 message type 10.4 08 Cause Cause O TLV 4-32 10.5.4.11 1C Facility Facility O TLV 2-? 10.5.4.15 7E User-user User-user O TLV 3-131 10.5.4.25



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 252

9.3.19.1.1 Cause

呼のクリアを開始するために使用されるメッセージには、本 IE が含まれること。

9.3.19.1.2 Facility

付加サービスの機能的オペレーションのために、本 IE が含まれてもよい。


呼のクリアを開始するために RELEASE COMPLETE メッセージが使用される場合、リモートユーザから user-user情報を伝送するために、ネットワーク→MS 方向で本 IE が含まれる。

9.3.19.2 Release complete (MS→ネットワーク方向)

MS が既にトランザクション識別子を開放し、ネットワークがトランザクション識別子を開放する必要があることを通知

するために、MS からネットワークに対して本メッセージが送信される。

表 9.69a/TS 24.008 参照。

メッセージタイプ： RELEASE COMPLETE


方向： MS→ネットワーク方向

表表表表 9.69a/TS 24.008: RELEASE COMPLETE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (MS→ネットワーク方向ネットワーク方向ネットワーク方向ネットワーク方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Release complete Message type M V 1 message type 10.4 08 Cause Cause O TLV 4-32 10.5.4.11 1C Facility Facility O TLV 2-? 10.5.4.15 7E User-user User-user O TLV 3-131 10.5.4.25 7F SS version SS version indicator O TLV 2-3 10.5.4.24



9.3.19.2.1 Cause

呼のクリアを開始するために使用されるメッセージには、本 IE が含まれること。

9.3.19.2.2 Facility



呼のクリアを開始するために RELEASE COMPLETE メッセージが使用され、かつ MS が呼のクリア時にリモートユ

ーザにユーザ情報をパスすることを希望する場合、ネットワーク→MS 方向で本 IE が含まれる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 253

9.3.19.2.4 SS version.

メッセージ内に facility IE が含まれない場合には、本 IE が含まれてはならない。



9.3.20 Retrieve 保留呼の回復を要求するために、モバイルユーザは本メッセージを送信する。

RETRIEVE メッセージのコンテンツについては、表 9.69b/TS 24.008 参照。


メッセージタイプ： RETRIEVE



表表表表 9.69b/TS 24.008: RETRIEVE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Retrieve Message type M V 1 message type 10.4

9.3.21 Retrieve Acknowledge 回復機能が正常に完了したことを通知するために、ネットワークは本メッセージを送信する。

RETRIEVE ACKNOWLEDGE メッセージのコンテンツについては、表 9.69c/TS 24.008 参照。


メッセージタイプ： RETRIEVE ACKNOWLEDGE



表表表表 9.69c/TS 24.008: RETRIEVE ACKNOWLEDGE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Retrieve Acknowledge Message type M V 1 message type 10.4

9.3.22 Retrieve Reject ネットワーク要求された回復機能を実行する能力がないことを通知するために、ネットワークは本メッセージを送信す

る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 254

RETRIEVE REJECT メッセージのコンテンツについては、9.69d/TS 24.008 参照。


メッセージタイプ： RETRIEVE REJECT



表表表表 9.69d/TS 24.008: RETRIEVE REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 Protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Retrieve Reject Message type M V 1 Message type 10.4 Cause 10.5.4.11 M LV 3-31

9.3.23 Setup

9.3.23.1 Setup (mobile terminated call establishment)

MS 着信呼の確立を開始するために、ネットワークは MS に対して本メッセージを送信する。

表 9.70/TS 24.008 参照。

メッセージタイプ： SETUP



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 255

表表表表 9.70/TS 24.008: SETUP メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (ネットワークネットワークネットワークネットワーク→MS 方向方向方向方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 Protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Setup Message type M V 1 Message type 10.4 D- BC repeat indicator Repeat indicator C TV 1 10.5.4.22 04 Bearer capability 1 Bearer capability O TLV 3-16 10.5.4.5 04 Bearer capability 2 Bearer capability O TLV 3-16 10.5.4.5 1C Facility Facility O TLV 2-? 10.5.4.15 1E Progress indicator Progress indicator O TLV 4 10.5.4.21 34 Signal Signal O TV 2 10.5.4.23 5C Calling party BCD Calling party BCD num. O TLV 3-14 Number 10.5.4.9 5D Calling party sub- Calling party subaddr. O TLV 2-23 Address 10.5.4.10 5E Called party BCD Called party BCD num. O TLV 3-19 Number 10.5.4.7 6D Called party sub- Called party subaddr. O TLV 2-23 Address 10.5.4.8 74 Redirecting party BCD number Redirecting party BCD num.

10.5.4.21a O TLV 3-19

75 Redirecting party sub-address Redirecting party subaddress. 10.5.4.21b

O TLV 2-23

D- LLC repeat indicator Repeat indicator O TV 1 10.5.4.22 7C Low layer Low layer comp. O TLV 2-18 Compatibility I 10.5.4.18 7C Low layer Low layer comp. C TLV 2-18 Compatibility II 10.5.4.18 D- HLC repeat indicator Repeat indicator O TV 1 10.5.4.22 7D High layer High layer comp. O TLV 2-5 Compatibility i 10.5.4.16 7D High layer High layer comp. C TLV 2-5 Compatibility ii 10.5.4.16 7E User-user User-user O TLV 3-35 10.5.4.25 8- Priority Priority Level O TV 1 10.5.1.11 19 Alert Alerting Pattern O TLV 3 10.5.4.26 2F Network Call Control Network Call Control cap. O TLV 3 Capabilities 10.5.4.29 3A Cause of No CLI Cause of No CLI O TLV 3 10.5.4.30

9.3.23.1.1 BC repeat indicator

メッセージ内に bearer capability 1 IE と bearer capability 2 IE の双方が含まれていた場合に限って、BC repeat indicator IE が含まれる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 256

9.3.23.1.2 Bearer capability 1 と bearer capability 2

ＭＳ加入者が一加入回線ですべてのサービスを受ける場合には、bearer capability 1 IE は省略可能である

（TS 29.007 参照）。bearer capability 1 IE がない場合には、少なくとも bearer capability 2 IE もない。

MSC が代替呼モード用のケーパビリティの通知を希望する場合には、MSC はフォールバックに入るが、bearer capability の２つの IE を追加することによって、それを通知する（セクション 5.3.6 参照）。

9.3.23.1.3 Facility



以下の場合に、ネットワークは本 IE を含める。

- 進行中の呼に関する情報（例えばインターワーキングのイベントなど）をパスするため。および／または

- MS を音声呼用ユーザコネクションにアタッチするため。

9.3.23.1.4a Called party BCD number

PCS1900 以外の全ての周波数帯において、ネットワークが送信する本 IE の大長は、13 オクテットとすること。

9.3.23.1.5 Called party subaddress

発呼ユーザが SETUP メッセージ内に a called party subaddress IE を含めた場合には、ネットワーク→MS 方向で

本 IE が含まれる。

9.3.23.1.6 LLC repeat indicator

LLC repeat indicator IE が含まれるのは、以下の条件が両方満たされた場合だけである。

- メッセージ内に BC repeat indicator IE が含まれる

- メッセージ内に low layer compatibility I IE が含まれる

LLC repeat indicator IE が含まれる場合には、LLC repeat indicator IE は BC repeat indicator IE と同じ反復通知

を指定する。

9.3.23.1.7 Low layer compatibility I

発呼ユーザが下位レイヤの互換性を指定した場合に、本 IE がネットワーク→MS 方向で含まれる。

9.3.23.1.8 Low layer compatibility II

メッセージ内に LLC repeat indicator IE が含まれる場合のみ、本 IE が含まれる。

9.3.23.1.9 HLC repeat indicator

HLC repeat indicator IE が含まれるのは、以下の条件が両方満たされた場合だけである。


- メッセージ内に high layer compatibility I IE が含まれる

HLC repeat indicator IE が含まれる場合、HLC repeat indicator は BC repeat indicator IE と同じ反復通知を指定

すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 257

9.3.23.1.10 High layer compatibility i

発呼ユーザが上位レイヤの互換性を指定した場合に、本 IE がネットワーク→MS 方向で含まれる。

9.3.23.1.11 High layer compatibility ii

メッセージ内に HLC repeat indicator IE が含まれる場合のみ、本 IE が含まれる。

9.3.23.1.12 User-user

発呼リモートユーザが SETUP メッセージ内に user-user IE を含めた場合に、ネットワーク→着信 MS 方向で本 IEを含めることができる。

9.3.23.1.13 Redirecting party BCD number

呼が再発呼された場合に、ネットワーク→着信 MS 方向で本 IE を含めることができる。

9.3.23.1.14 Redirecting party subaddress

発呼リモートユーザが SETUP メッセージ内に party subaddress を含めて、かつ呼がリダイレクトされた場合に、ネ

ットワーク→着信 MS 方向で本 IE を含めることができる。

9.3.23.1.15 Priority

eMLPP が使用される場合に、着信呼の優先度を通知するために、ネットワークは本 IE を含めることができる。

9.3.23.1.16 Alert $(Network Indication of Alerting in the MS )$

アラートに関する何らかの通知（カテゴリやレベル）を与えるために、ネットワークは本 IE を含めることができる。MSが本 IE がサポートする場合には、MS は GSM 02.07 で規定されるように、本オプション通知を使用すること。

9.3.23.1.17 Network Call Control Capabilities

ネットワークがマルチコールをサポートし、かつ MS に対して他の進行中の呼がない場合に、ネットワークは本 IE を

含めてネットワークの呼制御ケーパビリティを通知することができる。

9.3.23.1.18 Cause of No CLI

Calling Party BCD IE 内に数値番号が含まれない場合に限り、ネットワークは本 IE を含めることができる。

SETUP メッセージ内に Calling Party BCD number IE と Cause of No CLI IE が両方含まれている場合には、なぜ

数値番号が含まれていないのかという理由について、Cause of No CLI IE が追加情報を提供する。

9.3.23.2 Setup (mobile originating call establishment)

MS 発信呼を確立するために、MS はネットワークに対して本メッセージを送信する。

表 9.70a/TS 24.008 参照。

メッセージタイプ： SETUP



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 258

表表表表 9.70a/TS 24.008: SETUP メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ (MS→ネットワーク方向ネットワーク方向ネットワーク方向ネットワーク方向)

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Setup Message type M V 1 message type 10.4 D- BC repeat indicator Repeat indicator C TV 1 10.5.4.22 04 Bearer capability 1 Bearer capability M TLV 3-16 10.5.4.5 04 Bearer capability 2 Bearer capability O TLV 3-16 10.5.4.5 1C Facility(simple recall alignment) Facility O TLV 2- 10.5.4.15 5D Calling party sub- Calling party subaddr. O TLV 2-23 address 10.5.4.10 5E Called party BCD Called party BCD num. M TLV 3-43 number 10.5.4.7 6D Called party sub- Called party subaddr. O TLV 2-23 address 10.5.4.8 D- LLC repeat indicator Repeat indicator O TV 1 10.5.4.22 7C Low layer Low layer comp. O TLV 2-18 compatibility I 10.5.4.18 7C Low layer Low layer comp. O TLV 2-18 compatibility II 10.5.4.18 D- HLC repeat indicator Repeat indicator O TV 1 10.5.4.22 7D High layer High layer comp. O TLV 2-5 compatibility i 10.5.4.16 7D High layer High layer comp. O TLV 2-5 compatibility ii 10.5.4.16 7E User-user User-user O TLV 3-35 10.5.4.25 7F SS version SS version indicator O TLV 2-3 10.5.4.24 A1 CLIR suppression CLIR suppression C T 1 10.5.4.11a A2 CLIR invocation CLIR invocation C T 1 10.5.4.11b 15 CC capabilities Call Control Capabilities O TLV 3 10.5.4.5a 1D Facility $(CCBS)$ Facility O TLV 2-? (advanced recall alignment) 10.5.4.15 1B Facility (recall alignment Facility O TLV 2-? Not essential) $(CCBS)$ 10.5.4.15 2D Stream Identifier Stream Identifier O TLV 3 10.5.4.28

9.3.23.2.1 BC repeat indicator

メッセージ内に bearer capability 1 IE と bearer capability 2 IE の双方が含まれている場合に限り、BC repeat indicator IE が含まれる。

9.3.23.2.2 Facility


本 IE には 3 通りの異なるコーディングが存在する。詳細については、04.10 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 259

9.3.23.2.3 LLC repeat indicator

以下の 2 つの条件が満たされる場合に限り、LLC repeat indicator IE が含まれる。


- メッセージ内に low layer compatibility I IE が含まれる

LLC repeat indicator が含まれる場合には、BC repeat indicator IE と同じ反復通知を指定すること。

9.3.23.2.4 Low layer compatibility I

発信 MS が着信ユーザに対して下位レイヤ互換性情報をパスすることを希望した場合に、MS→ネットワーク方向で


9.3.23.2.5 Low layer compatibility II

メッセージ内に LLC repeat indicator IE が含まれる場合に限り、本 IE が含まれる。

9.3.23.2.6 HLC repeat indicator

以下の 2 つの条件が満たされる場合に限り、HLC repeat indicator IE が含まれる。


- メッセージ内に high layer compatibility i IE が含まれる

HLC repeat indicator IE が含まれる場合には、BC repeat indicator IE と同じ反復通知を指定すること。

9.3.23.2.7 High layer compatibility i

発信 MS が着信ユーザに対して上位レイヤ互換性情報をパスすることを希望した場合に、本 IE が含まれる。

9.3.23.2.8 High layer compatibility ii

メッセージ内に HLC repeat indicator IE が含まれる場合に限り、本 IE が含まれる。


発信 MS が着信ユーザに対してユーザ情報をパスすることを希望した場合に、MS→ネットワーク方向で本 IE が含

まれる。


メッセージ内に facility IE が存在しない場合には、本 IE を含めてはならない。



9.3.23.2.11 CLIR suppression

MS は本 IE を含めることができる（TS 24.081 参照）。本 IE が含まれている場合には、CLIR invocation IE が含ま

れてはならない。

9.3.23.2.12 CLIR invocation

MS は本 IE を含めることができる（TS 24.081 参照）。本 IE が含まれている場合には、CLIR suppression IE が含

まれてはならない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 260

9.3.23.2.13 CC Capabilities

MS は自分の呼制御ケーパビリティを通知するために、本 IE を含めることができる。

9.3.23.2.14 Stream Identifier

マルチコールをサポートする MS は、本 IE を含めること。

9.3.23.2.15 Bearer capability 1 と bearer capability 2

MS が代替呼モード用のケーパビリティの通知を希望する場合には、MS はフォールバックに入るが、bearer capability の 2 つの IE を追加することによって、それを通知する（セクション 5.3.6 参照）。

9.3.23a Start CC $(CCBS)$ "Network initiated MO call"オプションをサポートしないネットワークは、本メッセージを PD 用にメッセージタイプが

定義されていないメッセージとして扱うこと。

本メッセージは、ネットワークが MS に対してオープンすることを要求した呼制御トランザクションをオープンするため

に、MS がネットワークに対して送信する。

表 9.70b/TS 24.008 参照。

メッセージタイプ： START CC シグニフィカンス： local 方向： MS→ネットワーク

表表表表 9.70b/TS 24.008: START CC メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 Protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Start CC Message type M V 1 message type 10.4 15 CC Capabilities Call Control Capabilities O TLV 3 10.5.4.5a

9.3.23a.1 CC Capabilities

MS は自分の呼制御ケーパビリティを通知するために、本 IE を含めることができる。

9.3.24 Start DTMF 本メッセージは、MS からネットワークに対して送信され、ネットワークが DTMF トーンに再コンバートすべき数値を含

む。DTMF トーンは次にリモートユーザに対して適用される。

表 9.71/TS 24.008 参照。

メッセージタイプ： START DTMF



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 261

表表表表 9.71/TS 24.008: START DTMF メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Start DTMF Message type M V 1 message type 10.4 2C Keypad facility Keypad facility M TV 2 10.5.4.17

9.3.25 Start DTMF Acknowledge 本メッセージは、START DTMF メッセージによって要求されたアクション（本メッセージに含まれる数値の DTMF ト

ーンへの変換）が正常に開始されたことを通知するために、ネットワークが MS に対して送信する。

表 9.72/TS 24.008 参照。

メッセージタイプ： START DTMF ACKNOWLEDGE



表表表表 9.72/TS 24.008: START DTMF ACKNOWLEDGE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Start DTMF acknowledge Message type M V 1 message type 10.4 2C Keypad facility Keypad facility M TV 2 10.5.4.17

9.3.25.1 Keypad facility

本 IE には、ネットワークがリモートユーザに対して適用すべき DTMF トーンに関係する数値が含まれる。

9.3.26 Start DTMF reject ネットワークが START DTMF メッセージを受理できない場合に、ネットワークは MS に対して本メッセージを送信す

る。

表 9.73/TS 24.008 参照。

メッセージタイプ： START DTMF REJECT



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 262

表表表表 9.73/TS 24.008: START DTMF REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Start DTMF reject Message type M V 1 message type 10.4 Cause Cause M LV 3-31 10.5.4.11

9.3.27 Status 本メッセージは、第 8 章にリストアップされた特定のエラー条件をレポートするために、呼接続中はいつでも、MS が

ネットワークに対して、またはネットワークが MS に対して送信することができる。STATUS ENQUIRY メッセージに

対する応答中でも本メッセージが含まれること。

表 9.74/TS 24.008 参照。

メッセージタイプ： STATUS


方向： both

表表表表 9.74/TS 24.008: STATUS メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Status Message type M V 1 message type 10.4 Cause Cause M LV 3-31 10.5.4.11 Call state Call state M V 1 10.5.4.6 24 Auxiliary states Auxiliary states O TLV 3 10.5.4.4

9.3.27.1 Auxiliary states

本 IE は、呼ステートが"active" または "mobile originating modify"であって、かつ全ての補助ステートが"idle"以外

であった場合に限り、含まれる。補助ステートの定義については、TS 24.083 および TS 24.084 参照。

9.3.28 Status enquiry 本メッセージは、任意の時刻に、MS またはネットワークがピア L3 エンティティからの STATUS メッセージを請求す

るために送信する。STATUS ENQUIRY メッセージに対する STATUS メッセージの送信は mandatory である。

表 9.75/TS 24.008 参照。

メッセージタイプ： STATUS ENQUIRY


方向：両方

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 263

表表表表 9.75/TS 24.008: STATUS ENQUIRY メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Status enquiry Message type M V 1 message type 10.4

9.3.29 Stop DTMF 本メッセージは、MS がネットワークに対して送信し、リモートユーザに対する DTMF トーンの送信を停止するために

使用される。

表 9.76/TS 24.008 参照。

メッセージタイプ： STOP DTMF



表表表表 9.76/TS 24.008: STOP DTMF メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Stop DTMF Message type M V 1 message type 10.4

9.3.30 Stop DTMF acknowledge 本メッセージは、DTMF トーンの送信が停止されたことを通知するために、ネットワークから MS に対して送信される。

表 9.77/TS 24.008 参照。

メッセージタイプ： STOP DTMF ACKNOWLEDGE



表表表表 9.77/TS 24.008: STOP DTMF ACKNOWLEDGE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 Stop DTMF acknowledge Message type M V 1 message type 10.4

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 264

9.3.31 User information 本メッセージは、情報をリモートユーザに対して送信するために、MS からネットワークに対して送信される。本メッセ

ージはまた、リモートユーザから送信された情報を配信するために、ネットワークが MS に対して送信する。user-to-user 送信が、TS 24.010 で規定される許容された情報の送信の一部である場合に使用される。

表 9.78/TS 24.008 参照。

メッセージタイプ： USER INFORMATION

シグニフィカンス： access

方向：両方

表表表表 9.78/TS 24.008: USER INFORMATION メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Call control Protocol discriminator M V 1/2 protocol discriminator 10.2 Transaction identifier Transaction identifier M V 1/2 10.3.2 User Information Message type M V 1 message type 10.4 User-user User-user M LV 3-131 10.5.4.25 A0 More data More data O T 1 10.5.4.19

9.3.31.1 User-user

ネットワークによっては、大 35 オクテットまでしかサポートしない。インターワーキング用処理は、現時点では定義

されておらず、FFS である。

9.3.31.2 More data

本 IE は、同じメッセージブロックに関する他の USER INFORMATION メッセージが続くことを通知するために、送

信側ユーザが含める。

9.4 GPRS Mobility Management Messages （GPRSのMMメッセージ）

9.4.1 Attach request 本メッセージは、GPRS または結合 GPRS アタッチを実行するために、MS がネットワークに対して送信する。表

9.4.1/TS 24.008 参照。

メッセージタイプ： ATTACH REQUEST


方向： MS →ネットワーク

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 265

表表表表 9.4.1/TS 24.008: ATTACH REQUEST メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information Element Type/Reference Presence Format Length Protocol discriminator Protocol discriminator

10.2 M V 1/2

Skip indicator Skip indicator 10.3.1

M V ½

Attach request message identity Message type 10.4

M V 1

MS network capability MS network capability 10.5.5.12

M LV 3-9

Attach type Attach type 10.5.5.2

M V ½

GPRS ciphering key sequence number

Ciphering key sequence number 10.5.1.2

M V ½

DRX parameter DRX parameter 10.5.5.6

M V 2

P-TMSI or IMSI Mobile identity 10.5.1.4

M LV 6 - 9

Old routing area identification Routing area identification 10.5.5.15

M V 6

MS Radio Access capability MS Radio Access capability 10.5.5.12a

M LV 6 - 52

19 Old P-TMSI signature P-TMSI signature 10.5.5.8

O TV 4

17 Requested READY timer value

GPRS Timer 10.5.7.3

O TV 2

9- TMSI status TMSI status 10.5.5.4

O TV 1

9.4.1.1 Old P-TMSI signature

MS 内に有効な P-TMSI と P-TMSI 署名が含まれる場合に、本 IE が含まれる。

9.4.1.2 Requested READY timer value

MS が READY タイマの希望値を通知したい場合に、本 IE が含まれる。

9.4.1.3 TMSI status

MS が結合 GPRS アタッチを実行し、かつ有効な TMSI が利用可能でない場合に、本 IE が含まれる。

9.4.2 Attach accept 本メッセージは、対応するアタッチ要求が受理されたことを通知するために、ネットワークが MS に送信する。表

9.4.2/TS 24.008 参照。

メッセージタイプ： ATTACH ACCEPT


方向：ネットワーク → MS

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 266

表表表表 9.4.2/TS 24.008: ATTACH ACCEPT メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ


10.2 M V 1/2


M V 1/2

Attach accept message identity Message type 10.4

M V 1

Attach result Attach result 10.5.5.1

M V 1/2

Force to standby Force to standby 10.5.5.7

M V 1/2

Periodic RA update timer GPRS Timer 10.5.7.3

M V 1

Radio priority for SMS Radio priority 10.5.7.2

M V 1/2

Spare half octet Spare half octet 10.5.1.8

M V 1/2

Routing area identification Routing area identification 10.5.5.15

M V 6

19 P-TMSI signature P-TMSI signature 10.5.5.8

O TV 4

17 Negotiated READY timer value

GPRS Timer 10.5.7.3

O TV 2

18 Allocated P-TMSI Mobile identity 10.5.1.4

O TLV 7

23 MS identity Mobile identity 10.5.1.4

O TLV 6 - 7

25 GMM cause GMM cause 10.5.5.14

O TV 2

2A T3302 value GPRS Timer 10.5.7.3

O TLV 3

8C Cell Notification Cell Notification 10.5.5.21

O T 1

9.4.2.1 P-TMSI signature

MS の GMM コンテキストに ID を割当てるために、本 IE を含めることができる。

9.4.2.2 Negotiated READY timer

READY タイマ用の値を表示するために、本 IE を含めることができる。

9.4.2.3 Allocated P-TMSI

GPRS アタッチまたは複合 GPRS アタッチの場合、MS に P-TMSI を割当てるために、本 IE を含めることができる。

9.4.2.4 MS identity

複合 GPRS アタッチの場合、MS に TMSI を割当て／割当て解除するために、本 IE を含めることができる。

9.4.2.5 GMM cause

複合 GPRS アタッチ処理の過程で、非 GPRS 用 IMSI アタッチが正常終了しなかった場合に、本 IE を含めることが

できる。

9.4.2.6 T3302 value

タイマ T3302 用の値を通知するために、本 IE を含めることができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 267

9.4.2.7 Cell Notification (GSM のみ)

GSM では、セル通知（Cell Notification）のサポート能力を通知するために、SGSN は本 IE を含めること。

9.4.3 Attach complete attach accept メッセージ内に P-TMSI および／または TMSI が含まれていた場合に、MS はネットワークに対して

本メッセージを送信する。

メッセージタイプ： ATTACH COMPLETE


方向： MS → ネットワーク

表表表表 9.4.3/TS 24.008: ATTACH COMPLETE メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ


10.2 M V 1/2


M V 1/2

Attach complete message identity Message type 10.4

M V 1

9.4.4 Attach reject 本メッセージは、対応するアタッチ要求が拒否されたことを通知するために、ネットワークが MS に送信する。表

9.4.4/TS 24.008 参照。

メッセージタイプ： ATTACH REJECT



表表表表 9.4.4/TS 24.008: ATTACH REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Attach reject message identity Message type 10.4

M V 1

GMM cause GMM cause 10.5.5.14

M V 1


O TLV 3

9.4.4.1 T3302 value

タイマ T3302 の値を通知するために、本 IE を含めることができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 268

9.4.5 Detach request

9.4.5.1 Detach request (モバイル着信デタッチ)

GMM コンテキストの開放を要求するために、ネットワークは本メッセージを送信する。表 9.4.5.1/TS 24.008 参照。

メッセージタイプ： DETACH REQUEST



表表表表 9.4.5.1/TS 24.008:DETACH REQUEST メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Detach request message identity Message type 10.4

M V 1

Detach type Detach type 10.5.5.5

M V 1/2


M V 1/2


O TV 2

9.4.5.1.1 GMM cause

例えば IMEI チェックの失敗などにより、デタッチ理由を MS に対して通知する必要がある場合に、本 IE を含めるこ

と。

9.4.5.2 Detach request (モバイル発信デタッチ)

GMM コンテキストの開放を要求するために、ネットワークは本メッセージを送信する。表 9.4.5.2/TS 24.008 参照。

メッセージタイプ： DETACH REQUEST



表表表表 9.4.5.2/TS 24.008:DETACH REQUEST メッセージメッセージメッセージメッセージののののココココンテンツンテンツンテンツンテンツ


10.2 M V 1/2


M V 1/2

Detach request message identity Message type 10.4

M V 1

Detach type Detach type 10.5.5.5

M V 1/2


M V 1/2

18 P-TMSI Mobile identity 10.5.1.4

O TLV 7


O TLV 5

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 269

9.4.5.2.1 P-TMSI

MS は本 IE を含めること。

9.4.5.2.2 P-TMSI signature

MS が有効な P-TMSI 署名を持つ場合、本 IE を含めること。

9.4.6 Detach accept

9.4.6.1 Detach accept (モバイル着信デタッチ)

デタッチ処理が正常終了したことを通知するために、MS は本メッセージを送信すること。表 9.4.6.1/TS 24.008 参

照。

メッセージタイプ： DETACH ACCEPT



表表表表 9.4.6.1/TS 24.008:DETACH ACCEPT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Detach accept message identity Message type 10.4

M V 1

9.4.6.2 Detach accept (モバイル発信デタッチ)

デタッチ処理が正常終了したことを通知するために、ネットワークは本メッセージを送信する。表 9.4.6.2/TS 24.008参照。

メッセージタイプ： DETACH ACCEPT



表表表表 9.4.6.2/TS 24.008:DETACH ACCEPT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Detach accept message identity Message type 10.4

M V 1


M V 1/2


M V 1/2

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 270

9.4.7 P-TMSI reallocation command 本メッセージは、P-TMSI を再配置するために、ネットワークが MS に対して送信する。表 9.4.7/TS 24.008 参照。

メッセージタイプ： P-TMSI REALLOCATION COMMAND



表表表表 9.4.7/TS 24.008: P-TMSI REALLOCATION COMMAND メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

P-TMSI reallocation command message identity

Message type 10.4

M V 1

Allocated P-TMSI Mobile identity 10.5.1.4

M LV 6


M V 6


M V 1/2


M V 1/2


O TV 4



9.4.8 P-TMSI reallocation complete P-TMSI の再配置が実行されたことを通知するために、MS はネットワークに対して本メッセージを送信する。表

9.4.8/TS 24.008 参照。

メッセージタイプ： P-TMSI REALLOCATION COMPLETE



表表表表 9.4.8/TS 24.008: P-TMSI REALLOCATION COMPLETE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

P-TMSI reallocation complete message identity

Message type 10.4

M V 1

9.4.9 Authentication and ciphering request MS の ID の認証を開始するために、ネットワークは MS に対して本メッセージを送信する。さらに、暗号化モードが

設定されている場合には、暗号化が実行されるか否かを通知する。表 9.4.9/GSM 24.008 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 271

メッセージタイプ： AUTHENTICATION AND CIPHERING REQUEST



表表表表 9.4.9/GSM 24.008: AUTHENTICATION AND CIPHERING REQUEST メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Authentication and ciphering request message identity

Message type 10.4

M V 1

Ciphering algorithm Ciphering algorithm 10.5.5.3

M V 1/2

IMEISV request IMEISV request 10.5.5.10

M V 1/2


M V 1/2

A&C reference number A&C reference number 10.5.5.19

M V 1/2

21 Authentication parameter RAND Authentication parameter RAND 10.5.3.1

O TV 17

8 GPRS ciphering key sequence number


C TV 1

28 Authentication parameter AUTN

Authentication parameter AUTN 10.5.3.1.1

O TLV 18

9.4.9.1 Authentication Parameter RAND

認証を実行する必要がある場合に限り、本 IE を含めること。

9.4.9.2 GPRS ciphering key sequence number

本 IE は、メッセージ中に Authentication parameter RAND が含まれる場合に限り、本 IE を含めること。

9.4.9.3 Authentication Parameter AUTN

認証チャレンジが UMTS 認証チャレンジである場合に限り、本 IE を含めること。本 IE の有無によって、存在しない

場合には GSM の認証チャレンジ、存在する場合には UMTS の認証チャレンジである。

9.4.10 Authentication and ciphering response 本メッセージは、Authentication and ciphering request メッセージに対する応答として、MS からネットワークに対し

て送信される。表 9.4.10/TS 24.008 参照。

メッセージタイプ： AUTHENTICATION AND CIPHERING RESPONSE



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 272

表表表表 9.4.10/TS 24.008: AUTHENTICATION AND CIPHERING RESPONSE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Authentication and ciphering response message identity

GPRS message type 10.4

M V 1

A&C reference number A&C reference number 10.5.5.19

M V 1/2


M V 1/2

22 Authentication parameter Response

Authentication Response parameter 10.5.3.2

O TV 5

23 IMEISV Mobile identity 10.5.1.4

O TLV 11

29 Authentication Response parameter (extension)

Authentication Response parameter 10.5.3.2.1

O TLV 3-14

9.4.10.1 Authentication Response Parameter

対応する authentication and ciphering request メッセージ内で認証が要求された場合には、認証チャレンジが

GMS 用の場合には SRES が、UMTS 用の場合には RES（の全オクテットまたは上位オクテット 4 つ）が本 IE に

含められる（セクション 9.4.10.2 も参照）。

9.4.10.2 IMEISV

対応する authentication and ciphering request メッセージ内で要求された場合、本 IE が含まれる。

9.4.10.3 Authentication Response Parameter (extension)

認証チャレンジが UMTS 認証チャレンジであり、かつ RES パラメータが 4 オクテット長以上の場合に限り、本 IE が

含まれること。本 IE には、RES の下位残りビットが含まれること（上位オクテット 4 つは Authentication Response Parameter IE 内に含まれること（セクション 9.2.3.1 参照））。

9.4.10a Authentication and Ciphering Failure ネットワークの認証が失敗したことを通知するために、MS はネットワークに本メッセージを送信する。表 9.4.10a/TS 24.008 参照。

メッセージタイプ： AUTHENTICATION AND CIPHERING FAILURE



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 273

表表表表 9.4.10a/TS 24.008: AUTHENTICATION AND CIPHERING FAILURE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

IEI Information element Type / Reference Presence Format Length Mobility management Protocol discriminator M V 1/2 Protocol discriminator 10.2 Skip Indicator Skip Indicator M V 1/2 10.3.1 Authentication and Ciphering

Failure Message type M V 1

Message type 10.4 GMM Cause

GMM Cause 10.5.5.14

M V 1

30 Authentication Failure parameter Authentication Failure parameter O TLV 16 10.5.3.2.2

9.4.10a.1 Authentication Failure parameter

GMM 理由が'Synch failure' の場合に限り、本 IE が含まれること。本 IE には、SIM カードからの認証チャレンジに

対する応答（AUTS パラメータから構成される）が含まれること（TS 33.102 参照）。

9.4.11 Authentication and ciphering reject 認証が失敗したことを通知するために、ネットワークは MS に本メッセージを送信する（そしてメッセージを受信した

MS は全ての活動を中断すること）。表 9.4.11/TS 24.008 参照。

メッセージタイプ： AUTHENTICATION AND CIPHERING REJECT



表表表表 9.4.11/TS 24.008: AUTHENTICATION AND CIPHERING REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Authentication and ciphering reject message identity

Message type 10.4

M V 1

9.4.12 Identity request 指定された ID のタイプに従った MS の ID の提出を要求するために、ネットワークは MS に対して本メッセージを送

信する。表 9.4.12/TS 24.008 参照。

メッセージタイプ： IDENTITY REQUEST



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 274

表表表表 9.4.12/TS 24.008: IDENTITY REQUEST メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Identity request message identity Message type 10.4

M V 1

Identity type Identity type 2 10.5.5.9

M V 1/2


M V 1/2

9.4.13 Identity response 要求された ID を提供する identity request メッセージに対する応答内で、MS はネットワークに対して本メッセージを

送信する。表 9.4.13/TS 24.008 参照。

メッセージタイプ： IDENTITY RESPONSE



表表表表 9.4.13/TS 24.008: IDENTITY RESPONSE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Identity response message identity

Message type 10.4

M V 1

Mobile identity Mobile identity 10.5.1.4

M LV 4 - 10

9.4.14 Routing area update request MS のロケーションファイル更新を要求するため、または非 GPRS サービス用 IMSI アタッチを要求するために、MSはネットワークに対して本メッセージを送信する。表 9.4.14/TS 24.008 参照。

メッセージタイプ： ROUTING AREA UPDATE REQUEST



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 275

表表表表 9.4.14/TS 24.008: ROUTING AREA UPDATE REQUEST メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Routing area update request message identity

Message type 10.4

M V 1

Update type Update type 10.5.5.18

M V 1/2

GPRS ciphering key sequence number


M V 1/2

Old routing area identification Routing area identification 10.5.5.15

M V 6

MS Radio Access capability MS Radio Access capability 10.5.5.12a

M LV 6 - 52

19 Old P-TMSI signature P-TMSI signature 10.5.5.8

O TV 4

17 Requested READY timer value GPRS Timer 10.5.7.3

O TV 2

27 DRX parameter DRX parameter 10.5.5.6

O TV 3

9- TMSI status TMSI status 10.5.5.4

O TV 1

18 P-TMSI Mobile identity 10.5.1.4

O TLV 7

31 MS network capability MS network capability 10.5.5.12

O TLV 4-10

9.4.14.1 Old P-TMSI signature

MS はネットワークから ATTACH ACCEPT または ROUTING AREA UPDATE ACCEPT メッセージ内で本 IE を

受信したならば、それを含めること。

9.4.14.2 Requested READY timer value

MS が READY タイマの希望値の通知を希望する場合に、本 IE を含めることができる。

9.4.14.3 DRX parameter

MSがアクセスネットワークをGSMからUMTSへ変更する場合、またはMSが新しいDRXパラメータをネットワークに対して通知することを希望した場合に、本IEが含まれること。

9.4.14.4 TMSI status

MS が結合 RA 更を実行し、かつ有効な TMSI が利用可能でない場合に、本 IE が含まれること。

9.4.14.5 P-TMSI (UMTS only)

MS は本 IE を含めること。

9.4.14.6 MS network capability

MS は自身のケーパビリティをネットワークに対して通知するために、本 IE を含めること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 276

9.4.15 Routing area update accept routing area update request メッセージに対する応答内で、MS に GPRS のモビリティ管理関連のデータを提供す

るために、ネットワークは MS に本メッセージを送信する。表 9.4.15/TS 24.008 参照。

メッセージタイプ： ROUTING AREA UPDATE ACCEPT



表表表表 9.4.15/TS 24.008: ROUTING AREA UPDATE ACCEPT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Routing area update accept message identity

Message type 10.4

M V 1


M V 1/2

Update result Update result 10.5.5.17

M V 1/2

Periodic RA update timer GPRS Timer 10.5.7.3

M V 1


M V 6


O TV 4

18 Allocated P-TMSI Mobile identity 10.5.1.4

O TLV 7

23 MS identity Mobile identity 10.5.1.4

O TLV 7

26 List of Receive N-PDU Numbers Receive N-PDU Number list 10.5.5.11

O TLV 4 - 19

17 Negotiated READY timer value GPRS Timer 10.5.7.3

O TV 2


O TV 2


O TLV 3

8C Cell Notification Cell Notification 10.5.5.21

O T 1



9.4.15.2 Allocated P-TMSI

GPRS または複合 RA 更新処理の場合に、MS に P-TMSI を割当てるために、本 IE を含めることができる。

9.4.15.3 MS identity

複合 RA 更新処理の場合に、MS に TMSI を割当てる／割当てを解除するために、本 IE を含めることができる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 277

9.4.15.4 List of Receive N-PDU Numbers

SGSN 間 RA 更新の場合、送達確認送信モードで PDP コンテキストが既に活性化されているならば、本 IE が含ま

れること。

9.4.15.5 Negotiated READY timer value

READY タイマの値を通知するために、本 IE を含めることができる。

9.4.15.6 GMM cause

複合 GPRS RA 更新処理の間に、非 GPRS サービス用の IMSI アタッチが正常終了しなかった場合に、本 IE が含

まれること。

9.4.15.7 T3302 value


9.4.15.8 Cell Notification (GSM only)

GSM では、セル通知（Cell Notification）のサポート能力を通知するために、SGSN は本 IE を含めること。

9.4.16 Routing area update complete P-TMSI および／または TMSI が割当てられている場合、および／または確立された LLC コネクションが存在する

場合に、routing area update accept メッセージに対する応答内で、MS はネットワークに対して本メッセージを送信

すること。

メッセージタイプ： ROUTING AREA UPDATE COMPLETE



表表表表 9.4.16/TS 24.008: ROUTING AREA UPDATE COMPLETE メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Routing area update complete message identity

Message type 10.4

M V 1

26 List of Receive N-PDU Numbers Receive N-PDU Number list 10.5.5.11

O TLV 4 - 19

9.4.16.1 List of Receive N-PDU Numbers

routing area update accept メッセージ内に本 IE が含まれている場合には、本 IE が含まれること。

9.4.17 Routing area update reject ネットワークが RA 更新処理を拒否するために、ネットワークは MS に対して本メッセージを送信する。表 9.4.17/TS 24.008 参照。

メッセージタイプ： ROUTING AREA UPDATE REJECT


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 278


表表表表 9.4.17/TS 24.008: ROUTING AREA UPDATE REJECT メメメメッセージッセージッセージッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Routing area update reject message identity

Message type 10.4

M V 1


M V 1


M V 1/2


M V 1/2


O TLV 3

9.4.17.1 T3302 value


9.4.18 GMM Status 第 8 章にリストアップされた特定のエラー条件をレポートするために、MS またはネットワークはいつでも本メッセージ

を送信できる。表 9.4.18/TS 24.008 参照。

メッセージタイプ： GMM STATUS


方向：両方

表表表表 9.4.18/TS 24.008: GMM STATUS メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

GMM Status message identity Message type 10.4

M V 1


M V 1

9.4.19 GMM Information 特定の情報を MS に対して送信するために、ネットワークはいつでも本メッセージを送信できる。表 9.4.19/TS 24.008 参照。

メッセージタイプ： GMM INFORMATION



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 279

表表表表 9.4.19/TS 24.008: GMM INFORMATION メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

GMM Information message identity

Message type 10.4

M V 1

43 Full name for network Network name 10.5.3.5a

O TLV 3 - ?

45 Short name for network Network name 10.5.3.5a

O TLV 3 - ?

46 Local time zone Time zone 10.5.3.8

O TV 2

47 Universal time and local time zone

Time zone and time 10.5.3.9

O TV 8

48 LSA Identity LSA Identifier 10.5.3.11

O TLV 2-5

49 Network Daylight Saving Time Daylight Saving Time 10.5.3.12

O TLV 3

9.4.19.1 Full name for network

本 IE はネットワークによって送信される。本 IE が送信される場合には、本 IE のコンテンツは、"full length name of the network"を通知し、ネットワークが MS に対して、現行セルの RAI 内に含まれる MCC と MNC を関連付けるこ

とを希望していることを通知する。

9.4.19.2 Short name for network

本 IE はネットワークによって送信される。本 IE が送信される場合には、本 IE のコンテンツは"abbreviated name of the network"を通知し、ネットワークが MS に対して、MS が現在在圏しているセルの RAI 内に含まれる MCC と MNC を関連付けることを希望していることを通知する。

9.4.19.3 Local time zone

本 IE はネットワークによって送信される。MS は、本タイムゾーンが、MS が現在在圏しているセルの RA に適用さ

れているものと仮定すること。

ローカルタイムゾーンが Daylight Saving Time（夏時間）用に調整されている場合には、ネットワークはそのことを

Network Daylight Saving Time IE を含めることによって通知すること。

9.4.19.4 Universal time and local time zone

本 IE はネットワークによって送信される。MS は、このタイムゾーンが、MS が現在在圏しているセルの RA に適用さ

れているものと仮定すること。MS は時刻情報が正確であると仮定してはならない。

ローカルタイムゾーンが Daylight Saving Time（夏時間）用に調整されている場合には、ネットワークはそのことを

Network Daylight Saving Time IE を含めることによって通知すること。

9.4.19.5 LSA Identity

本 IE はネットワークによって送信される。本 IE のコンテンツは、サービスセルの LSA アイデンティティを通知する。

9.4.19.6 Network Daylight Saving Time

本 IE はネットワークによって送信される。本 IE が送信される場合には、本 IE のコンテンツは、ローカルタイムゾーン

補正用に使用された値を通知すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 280

9.4.20 Service Request (UMTS only) MS とネットワーク間で論理的関係を確立するために、MS は本メッセージを送信する。表 9.4.20/TS 24.008 参照。

メッセージタイプ： Service Request



表表表表 9.4.20/TS 24.008: Contents of Service Request メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Service Request Message type 10.4

M V 1

Ciphering key sequence number Ciphering key sequence number 10.5.1.2

M V 1/2

Service type Service type 10.5.5.20

M V 1/2

P-TMSI Mobile station identity 10.5.1.4

M LV 6

9.4.20.1 Void

9.4.21 Service Accept (UMTS only) ネットワークは Service Request メッセージに対する応答内で本メッセージを送信する。表 9.4.21/TS 24.008 参照。

メッセージタイプ： Service Accept



表表表表 9.4.21/TS 24.008: Contents of Service Accept メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ


10.2 M V 1/2


M V 1/2

Service Accept Message type 10.4

M V 1

9.4.22 Service Reject (UMTS only) サービス要求処理を拒否するために、ネットワークは UE に対して本メッセージを送信する。表 9.4.22/TS 24.008 参

照。

メッセージタイプ： Service Reject



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 281

表表表表 9.4.22/TS 24.008: Contents of Service Reject メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2

Service Reject Message type 10.4

M V 1


M V 1

9.5 GPRS Session Management Messages（GPRS SMメッセージ）

9.5.1 Activate PDP context request 本メッセージは PDP コンテキスト活性化を要求するために、MS がネットワークに対して送信する。表 9.5.1/TS 24.008 参照。

メッセージタイプ： ACTIVATE PDP CONTEXT REQUEST



表表表表 9.5.1/TS 24.008: ACTIVATE PDP CONTEXT REQUEST メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2

Transaction identifier

Transaction identifier 10.3.2

M V 1/2– 3/2

Activate PDP context request message identity

Message type 10.4

M V 1

Requested NSAPI Network service access point identifier 10.5.6.2

M V 1

Requested LLC SAPI LLC service access point identifier 10.5.6.9

M V 1

Requested QoS Quality of service 10.5.6.5

M LV 12

Requested PDP address Packet data protocol address 10.5.6.4

M LV 3 - 19

28 Access point name Access point name 10.5.6.1

O TLV 3 - 102

27 Protocol configuration options Protocol configuration options 10.5.6.3

O TLV 3 - 253

9.5.1.1 Access point name

MS が接続先として特定の外部ネットワークを選択した場合に、メッセージ内に本 IE が含まれる。

9.5.1.2 Protocol configuration options

MS が外部 PDN 用プロトコルコンフィギュレーションオプションを提供する場合に、メッセージ内に本 IE が含まれる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 282

9.5.2 Activate PDP context accept ＰＤＰコンテキストの活性化を送達確認するために、ネットワークが MS に対して本メッセージを送信する。表 9.5.2/TS 24.008 参照。

メッセージタイプ： ACTIVATE PDP CONTEXT ACCEPT



表表表表 9.5.2/TS 24.008: ACTIVATE PDP CONTEXT ACCEPT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2



M V 1/2– 3/2

Activate PDP context accept message identity

Message type 10.4

M V 1

Negotiated LLC SAPI LLC service access point identifier 10.5.6.9

M V 1

Negotiated QoS Quality of service 10.5.6.5

M LV 12

Radio priority Radio priority 10.5.7.2

M V 1/2


M V 1/2

2B PDP address Packet data protocol address 10.5.6.4

O TLV 4 - 20


O TLV 3 - 253

34 Packet Flow Identifier Packet Flow Identifier 10.5.6.11

O TLV 3

9.5.2.1 PDP address

MS が関連する ACTIVATE PDP CONTEXT REQUEST メッセージ内で静的なアドレスを要求しなかった場合には、

ネットワークは ACTIVATE PDP CONTEXT ACCEPT メッセージ内に PDP address IE を入れること。

MS が関連する ACTIVATE PDP CONTEXT REQUEST メッセージ内で静的なアドレスを要求した場合には、ネッ

トワークは ACTIVATE PDP CONTEXT ACCEPT メッセージ内に PDP address IE を入れてはならない。


ネットワークが外部 PDN 用プロトコルコンフィギュレーションオプションの送信を希望した場合に、本 IE がメッセージ

内に含まれる。

9.5.2.3 Packet Flow Identifier

ネットワークが関連する Packet Flow Identifier を PDP コンテキストに関連付けることを希望した場合に、本 IE を含

めることができる。

9.5.3 Activate PDP context reject PDP コンテキスト活性化を拒否するために、ネットワークは MS に対して本メッセージを送信する。表 9.5.3/TS 24.008 参照。

メッセージタイプ： ACTIVATE PDP CONTEXT REJECT

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 283



表表表表 9.5.3/TS 24.008: ACTIVATE PDP CONTEXT REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2



M V 1/2– 3/2

Activate PDP context reject message identity

Message type 10.4

M V 1

SM cause SM Cause 10.5.6.6

M V 1


O TLV 3 - 253


SM Cause が"activation rejected by GGSN"を通知した場合に、ネットワークだけが protocol configuration options IE を挿入することができる。

9.5.4 Activate Secondary PDP Context Request 既にアクティブな PDP コンテキストと同じ PDP アドレスと APN に関連付けられた追加 PDP コンテキストの活性化

を要求するために、MS はネットワークに対して本メッセージを送信する。

メッセージタイプ： ACTIVATE SECONDARY PDP CONTEXT REQUEST



表表表表 9.5.4/TS 24.008: Activate SECONDARY PDP context request メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V ½



M V ½– 3/2

Activate secondary PDP context request message identity

Message type 10.4

M V 1

Requested NSAPI Network service access point identifier 10.5.6.2

M V 1


M V 1

Requested QoS Quality of service 10.5.6.5

M LV 12

Linked TI Linked TI 10.5.6.7

M LV 2-3

36 TFT Traffic Flow Template 10.5.6.12

O TLV 257

9.5.4.1 TFT

TFT のない PDP コンテキストが既にアクティブになっている場合には、本 IE が含まれること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 284

9.5.5 Activate Secondary PDP Context Accept 既にアクティブな PDP コンテキストと同じ PDP アドレスと APN に関連付けられた追加 PDP コンテキストの活性化

を送達確認するために、ネットワークは MS に対して本メッセージを送信する。表 9.5.5/TS 24.008 参照。

メッセージタイプ： ACTIVATE SECONDARY PDP CONTEXT ACCEPT



表表表表 9.5.5/TS 24.008: ACTIVATE SECONDARY PDP CONTEXT ACCEPT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2

Transaction identifier Transaction identifier 10.3.2

M V 1/2– 3/2

Activate secondary PDP context accept message identity

Message type 10.4

M V 1

Negotiated LLC SAPI LLC service access point identifier 10.5.6.9

M V 1

Negotiated QoS Quality of service 10.5.6.5

M LV 12

Radio priority Radio priority M V 1/2 Spare half octet Spare half octet

10.5.1.8 M V 1/2


O TLV 3


ネットワークが PDP コンテキストに関連付けられた Packet Flow Identifier の通知を希望する場合には、本 IE を含


9.5.6 Activate Secondary PDP Context Reject 既にアクティブな PDP コンテキストと同じ PDP アドレスと APN に関連付けられた追加 PDP コンテキストの活性化

を拒否するために、ネットワークは UE に対して本メッセージを送信する。表 9.5.6/TS 24.008 参照。

メッセージタイプ： ACTIVATE SECONDARY PDP CONTEXT REJECT



表表表表 9.5.6/TS 24.008: ACTIVATE SECONDARY PDP CONTEXT REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2– 3/2

Activate secondary PDP context reject message identity

Message type 10.4

M V 1


M V 1

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 285

9.5.7 Request PDP context activation PDP コンテキストの活性化を開始するために、ネットワークは MS に対して本メッセージを送信する。表 9.5.7/TS 24.008 参照。

メッセージタイプ： REQUEST PDP CONTEXT ACTIVATION



表表表表 9.5.7/TS 24.008: REQUEST PDP CONTEXT ACTIVATION メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2– 3/2

Request PDP context activation message identity

Message type 10.4

M V 1

Offered PDP address Packet data protocol address 10.5.6.4

M LV 3 - 19

28 Access point name Access point name 10.5.6.1

O TLV 3 – 102

9.5.8 Request PDP context activation reject PDP コンテキストの活性化開始を拒否するために、MS はネットワークに対して本メッセージを送信する。表

9.5.8/TS 24.008 参照。

メッセージタイプ： REQUEST PDP CONTEXT ACTIVATION REJECT



表表表表 9.5.8/TS 24.008: REQUEST PDP CONTEXT ACTIVATION REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2– 3/2

Request PDP context act. reject message identity

Message type 10.4

M V 1

SM cause SM cause 10.5.6.6

M V 1

9.5.9 Modify PDP context request (Network to MS direction) アクティブな PDP コンテキストの修正を要求するために、ネットワークは本メッセージを送信する。9.5.9/TS 24.008参照。

メッセージタイプ： MODIFY PDP CONTEXT REQUEST (NETWORK TO MS DIRECTION)



3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 286

表表表表 9.5.9/TS 24.008: MODIFY PDP CONTEXT REQUEST (NETWORK TO MS DIRECTION) メッセージメッセージメッセージメッセージののののコンコンコンコン

テンツテンツテンツテンツ


10.2 M V 1/2


M V 1/2– 3/2

Modify PDP context request message identity

Message type 10.4

M V 1

Radio priority Radio priority 10.5.7.2

M V 1/2


M V 1/2


M V 1

New QoS Quality of service 10.5.6.5

M LV 12

2B PDP address Packet data protocol address 10.5.6.4

O TLV 4-20


O TLV 3

9.5.9.1 PDP address

MS が PDP コンテキスト活性化時に、APN 経由で外部 PDN アドレスの割当てを要求し、そのことが ACTIVATE PDP CONTEXT ACCEPT メッセージ内でネットワークによって確認されたならば、MS 内の PDP コンテキストを更

新するために、ネットワークはアドレスが実際に割当てられたときに MODIFY PDP CONTEXT REQUEST 内に

PDP address IE を含めること。


ネットワークが PDP コンテキストに関連付けられた Packet Flow Identifier の通知を希望する場合には、本 IE を含


9.5.10 Modify PDP context request (MS to network direction) アクティブな PDP コンテキストの修正を要求するために、MS はネットワークに対して本メッセージを送信する。表

9.5.10/TS 24.008 参照。

メッセージタイプ： MODIFY PDP CONTEXT REQUEST (MS TO NETWORK DIRECTION)



表表表表 9.5.10/TS 24.008: modify PDP context request (MS to network direction) メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 287


10.2 M V 1/2


M V 1/2– 3/2

Modify PDP context request message identity

Message type 10.4

M V 1

32 Requested LLC SAPI LLC service access point identifier 10.5.6.9

O TV 2

30 Requested new QoS Quality of service 10.5.6.5

O TLV 13

31 New TFT Traffic Flow Template 10.5.6.12

O TLV 257

9.5.10.1 Requested LLC SAPI

新しい QoS が要求された場合に、新しい LLC SAPI を要求するために、本 IE を含めることができる。

9.5.10.2 Requested new QoS

QoS の修正を要求するために、メッセージ内に本 IE を含めることができる。

9.5.10.3 New TFT

同一の PDP アドレスと APN に対して複数の PDP コンテキストがアクティブな場合に、TFT の修正を要求するため

に、メッセージ内に本 IE を含めることができる。

9.5.11 Modify PDP context accept (MS to network direction) アクティブな PDP コンテキストの修正を確認するために、MS はネットワークに対して本メッセージを送信する。表

9.5.11/TS 24.008 参照。

メッセージタイプ： MODIFY PDP CONTEXT ACCEPT (MS TO NETWORK DIRECTION)



表表表表 9.5.11/TS 24.008: MODIFY PDP CONTEXT ACCEPT (MS TO NETWORK DIRECTION) メッセージメッセージメッセージメッセージののののコンコンコンコン

テンツテンツテンツテンツ


10.2 M V 1/2


M V 1/2– 3/2

Modify PDP context accept message identity

Message type 10.4

M V 1

9.5.12 Modify PDP context accept (Network to MS direction) アクティブな PDP コンテキストの修正を確認するために、ネットワークは MS に対して本メッセージを送信する。表

9.5.12/TS 24.008 参照。

メッセージタイプ： MODIFY PDP CONTEXT ACCEPT (NETWORK TO MS DIRECTION)


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 288


表表表表 9.5.12/TS 24.008: modify PDP context accept (NETWORK to ms direction) メッセージコンテンツメッセージコンテンツメッセージコンテンツメッセージコンテンツ


10.2 M V ½


M V ½– 3/2

Modify PDP context accept message identity

Message type 10.4

M V 1

30 Negotiated QoS Quality of service 10.5.6.5

O TLV 13

32 Negotiated LLC SAPI LLC service access point identifier 10.5.6.9

O TV 2

8 New radio priority Radio priority 10.5.7.2

O TV 1


O TLV 3

9.5.12.1 Negotiated QoS

ネットワークが新しい QoS を割当てる場合に、メッセージ内に含まれる。

9.5.12.2 Negotiated LLC SAPI

ネットワークが新しい LLC SAPI を割当てる場合に、メッセージ内に含まれる。

9.5.12.3 New radio priority

ネットワークが無線優先度を修正する場合に、メッセージ内に含まれる。


ネットワークが PDP コンテキストに対して関連付けられた Packet Flow Identifier の通知を希望した場合、メッセー

ジ内に含まれる。

9.5.13 Modify PDP Context Reject 要求された TFT の修正を拒否するために、ネットワークは本メッセージを送信する。要求された QoS が利用不可能

な場合に限っては、ネットワークは MODIFY PDP CONTEXT REJECT メッセージを送信してはならない。TFT の修

正が要求され、かつ要求された TFT が利用可能でない場合には、MODIFY PDP CONTEXT REJECT メッセージ

を送信すること。表 9.5.13/TS 24.008 参照。

メッセージタイプ： MODIFY PDP CONTEXT REJECT



表表表表 9.5.13/TS 24.008: MODIFY PDP CONTEXT REJECT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 289


10.2 M V 1/2


M V 1/2– 3/2

Modify PDP Context Reject Message type 10.4

M V 1


M V 1

9.5.14 Deactivate PDP context request アクティブな PDP コンテキストの不活性化を要求するために、本メッセージを送信する。表 9.5.8/TS 24.008 参照。

メッセージタイプ： DEACTIVATE PDP CONTEXT REQUEST


方向：双方向

表表表表 9.5.14/TS 24.008: DEACTIVATE PDP CONTEXT REQUEST メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2– 3/2

Deactivate PDP context request message identity

Message type 10.4

M V 1

SM cause SM cause 10.5.6.6

M V 1

9- Tear down indicator Tear down indicator 10.5.6.10

O TV 1

9.5.14.1 Tear down indicator

特定の TI に関連付けられた PDP コンテキストだけ、またはこの特定の TI に関連付けられた PDP アドレスと同じア

ドレスを共有する全てのアクティブな PDP コンテキストを不活性化すべきか否かを通知するために、メッセージ内に


9.5.15 Deactivate PDP context accept 関連する Deactivate PDP context request メッセージ内で要求された PDP コンテキストの不活性化を槌するため

に、本メッセージが送信される。表 9.5.15/TS 24.008 参照。

メッセージタイプ： DEACTIVATE PDP CONTEXT ACCEPT


方向：双方向

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 290

表表表表 9.5.15/TS 24.008: DEACTIVATE PDP CONTEXT ACCEPT メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2– 3/2

Deactivate PDP context accept message identity

Message type 10.4

M V 1

9.5.16 Void

9.5.17 Void

9.5.18 Void

9.5.19 Void

9.5.20 Void

9.5.21 SM Status 通知されたコンテキストのステータスに関する情報をパスして、（例えば第 8 章にリストアップされたような）特定のエ

ラー条件をレポートするために、ネットワークまたは MS は本メッセージを送信する。表 9.5.21/TS 24.008 参照。

メッセージタイプ： SM Status


方向：双方向

表表表表 9.5.21/TS 24.008: SM STATUS メッセージメッセージメッセージメッセージののののコンテンツコンテンツコンテンツコンテンツ


10.2 M V 1/2


M V 1/2– 3/2

SM Status message identity Message type 10.4

M V 1

SM Cause SM Cause 10.5.6.6

M V 1

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 291

10 General message format and information elements coding （一般的なメッセージのフォーマットと IEのコーディング）

本セクションの図とテキストは、IE のコンテンツを示す。

10.1 Overview GSM 24.108 で定義される L3 プロトコル内では、全てのメッセージは TS 24.007 で定義される通りの標準的な L3メッセージである[20]。つまり、メッセージは以下のパートから構成される。

a) PD(protocol discriminator)

b) TI（transaction identifier）

c) message type

d) その他の IE、必要に応じて（other information elements, as required）

この構成は、図 10.1/TS 24.008 に示す例のようにイラスト化される。

図図図図 10.1/TS 24.008 一般的なメッセージ構成の例一般的なメッセージ構成の例一般的なメッセージ構成の例一般的なメッセージ構成の例

第 9 章のメッセージ記述で他の方法で規定されない場合、特定の IE があるメッセージ内に複数回存在してはならな

い。

「デフォルト」という用語は、割当てられた値がない場合にこの値を使用すべきであること、またはこの値が 2 つのピ

アエンティティ間で代替値のネゴシエーションを許容することを意味する。

フィールドが 2 オクテット以上に拡張された場合、オクテット番号の値が増えるとビット値のオーダは次第に減少する。

フィールドの LSB とは、フィールド内の上位番号のオクテット中の下位番号のビットを表わす。

10.2 PD（Protocol Discriminator） PD（Protocol Discriminator）とその使用方法は、TS 24.007 [20]で定義される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 292

10.3 Skip indicator and transaction identifier （スキップインジケータと TI）

10.3.1 Skip indicator（スキップインジケータ）全ての MM メッセージおよび GPRS MM メッセージの第 1 オクテットのビット 5～8 には、スキップインジケータが含

まれる。 0000 以外の値のスキップインジケータを持つメッセージは無視すること。スキップインジケータが 0000 で

エンコードされたメッセージを無視してはならない（その他の理由で無視された場合を除く）。 MM メッセージまたは

GPRS MM メッセージを送信するプロトコルエンティティは、スキップインジケータを 0000 でエンコードすること。

10.3.2 Transaction identifier（TI）プロトコル"Call Control; call related SS messages" および "Session Management"に属するメッセージの第 1 オ

クテットのビット 5～8 には、トランザクション識別子(TI)が含まれること。TI とその使用方法は、TS 24.007[20]中で

定義される。

SM プロトコル用に、拡張 TI メカニズムを使用することもできる（24.007 参照）。

CC プロトコル用に、セクション 8.3.1 で定義されるプロトコルエラー処理のために、拡張 TI メカニズムを使用すること。

10.4 Message Type message type IE とその使用方法は、TS 24.007 [20]で定義される。表 10.3/TS 24.008、表 10.4/TS 24.008、そし

て表 10.4a/TS 24.008 で、MM プロトコル、CC プロトコル、そして SM プロトコルとして使用される message type IEの値部分について定義する。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 293

表表表表 10.2/TS 24.008: MM 用用用用 Message type

8 7 6 5 4 3 2 1 x x 0 0 - - - - Registration messages: 0 0 0 1 - IMSI DETACH INDICATION 0 0 1 0 - LOCATION UPDATING ACCEPT 0 1 0 0 - LOCATION UPDATING REJECT 1 0 0 0 - LOCATION UPDATING REQUEST x x 0 1 - - - - Security messages: 0 0 0 1 - AUTHENTICATION REJECT 0 0 1 0 - AUTHENTICATION REQUEST 0 1 0 0 - AUTHENTICATION RESPONSE 1 1 0 0 - AUTHENTICATION FAILURE………….. 1 0 0 0 - IDENTITY REQUEST 1 0 0 1 - IDENTITY RESPONSE 1 0 1 0 - TMSI REALLOCATION COMMAND 1 0 1 1 - TMSI REALLOCATION COMPLETE x x 1 0 - - - - Connection management messages: 0 0 0 1 - CM SERVICE ACCEPT 0 0 1 0 - CM SERVICE REJECT 0 0 1 1 - CM SERVICE ABORT 0 1 0 0 - CM SERVICE REQUEST 0 1 0 1 - CM SERVICE PROMPT 0 1 1 0 - Reserved (see NOTE) 1 0 0 0 - CM RE-ESTABLISHMENT REQUEST 1 0 0 1 - ABORT x x 1 1 - - - - Miscellaneous messages: 0 0 0 0 - MM NULL 0 0 0 1 - MM STATUS 0 0 1 0 - MM INFORMATION

NOTE: この値は割当てられるが、プロトコルの前のフェーズでは決して使用されない。

無線コネクションが R99 よりも古い CN ノードで開始された場合、ビット 8 は 0 にセットし、ビット 7 は MS から送信さ

れるメッセージ内のシーケンス番号を送信するために reserve すること。ネットワークが送信するメッセージ内では、

ビット 7 および 8 は " 0 "にコードされる。TS 24.007 参照。

無線コネクションが、R'99 またはそれ以降の CN ノードで開始された場合、ビット 7 および 8 は、MS から送信される

メッセージ内のシーケンス番号を送信するために reserve される。ネットワークが送信するメッセージ内では、ビット 7および 8 は " 0 "にコードされる。TS 24.007 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 294

表表表表 10.3/TS 24.008: CC メッセージおよび呼に関連するメッセージおよび呼に関連するメッセージおよび呼に関連するメッセージおよび呼に関連する SS メッセージ用のメッセージ用のメッセージ用のメッセージ用の Message type

8 7 6 5 4 3 2 1 x x 0 0 0 0 0 0 escape to nationally specific message types ; see 1) below x x 0 0 - - - - Call establishment messages: 0 0 0 1 - ALERTING 1 0 0 0 - CALL CONFIRMED 0 0 1 0 - CALL PROCEEDING 0 1 1 1 - CONNECT 1 1 1 1 - CONNECT ACKNOWLEDGE 1 1 1 0 - EMERGENCY SETUP 0 0 1 1 - PROGRESS 0 1 0 0 - CC-ESTABLISHMENT 0 1 1 0 - CC-ESTABLISHMENT CONFIRMED 1 0 1 1 - RECALL 1 0 0 1 - START CC 0 1 0 1 - SETUP x x 0 1 - - - - Call information phase messages: 0 1 1 1 - MODIFY 1 1 1 1 - MODIFY COMPLETE 0 0 1 1 - MODIFY REJECT 0 0 0 0 - USER INFORMATION 1 0 0 0 - HOLD 1 0 0 1 - HOLD ACKNOWLEDGE 1 0 1 0 - HOLD REJECT 1 1 0 0 - RETRIEVE 1 1 0 1 - RETRIEVE ACKNOWLEDGE 1 1 1 0 - RETRIEVE REJECT x x 1 0 - - - - Call clearing messages: 0 1 0 1 - DISCONNECT 1 1 0 1 - RELEASE 1 0 1 0 - RELEASE COMPLETE x x 1 1 - - - - Miscellaneous messages: 1 0 0 1 - CONGESTION CONTROL 1 1 1 0 - NOTIFY 1 1 0 1 - STATUS 0 1 0 0 - STATUS ENQUIRY 0 1 0 1 - START DTMF 0 0 0 1 - STOP DTMF 0 0 1 0 - STOP DTMF ACKNOWLEDGE 0 1 1 0 - START DTMF ACKNOWLEDGE 0 1 1 1 - START DTMF REJECT 1 0 1 0 - FACILITY

1): 使用される場合、message type は各国の仕様に従って、後のオクテットによって規定される。無線コネクションが R99 よりも古い CN ノードで開始された場合、ビット 8 は 0 にセットし、ビット 7 は MS から送信さ

れるメッセージ内のシーケンス番号を送信するために reserve すること。ネットワークが送信するメッセージ内では、

ビット 7 および 8 は " 0 "にコードされる。TS 24.007 参照。

無線コネクションが、R'99 またはそれ以降の CN ノードで開始された場合、ビット 7 および 8 は、MS から送信される

メッセージ内のシーケンス番号を送信するために reserve される。ネットワークが送信するメッセージ内では、ビット 7および 8 は " 0 "にコードされる。TS 24.007 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 295

表表表表 10.4/TS 24.008: GPRS MM メッセージ用メッセージ用メッセージ用メッセージ用 Message type

Bits 8 7 6 5 4 3 2 1 0 0 - - - - - - Mobility management messages 0 0 0 0 0 0 0 1 Attach request 0 0 0 0 0 0 1 0 Attach accept 0 0 0 0 0 0 1 1 Attach complete 0 0 0 0 0 1 0 0 Attach reject 0 0 0 0 0 1 0 1 Detach request 0 0 0 0 0 1 1 0 Detach accept 0 0 0 0 1 0 0 0 Routing area update request 0 0 0 0 1 0 0 1 Routing area update accept 0 0 0 0 1 0 1 0 Routing area update complete 0 0 0 0 1 0 1 1 Routing area update reject 0 0 0 0 1 1 0 0 Service Request 0 0 0 0 1 1 0 1 Service Accept 0 0 0 0 1 1 1 0 Service Reject 0 0 0 1 0 0 0 0 P-TMSI reallocation command 0 0 0 1 0 0 0 1 P-TMSI reallocation complete 0 0 0 1 0 0 1 0 Authentication and ciphering req 0 0 0 1 0 0 1 1 Authentication and ciphering resp 0 0 0 1 0 1 0 0 Authentication and ciphering rej 0 0 0 1 1 1 0 0 Authentication and ciphering failure 0 0 0 1 0 1 0 1 Identity request 0 0 0 1 0 1 1 0 Identity response 0 0 1 0 0 0 0 0 GMM status 0 0 1 0 0 0 0 1 GMM information

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 296

表表表表 10.4a/TS 24.008: GPRS SM メッセージ用メッセージ用メッセージ用メッセージ用 Message type

Bits 8 7 6 5 4 3 2 1 0 1 - - - - - - Session management messages 0 1 0 0 0 0 0 1 Activate PDP context request 0 1 0 0 0 0 1 0 Activate PDP context accept 0 1 0 0 0 0 1 1 Activate PDP context reject 0 1 0 0 0 1 0 0 Request PDP context activation 0 1 0 0 0 1 0 1 Request PDP context activation rej. 0 1 0 0 0 1 1 0 Deactivate PDP context request 0 1 0 0 0 1 1 1 Deactivate PDP context accept 0 1 0 0 1 0 0 0 Modify PDP context request(Network to MS direction) 0 1 0 0 1 0 0 1 Modify PDP context accept (MS to network direction) 0 1 0 0 1 0 1 0 Modify PDP context request(MS to network direction) 0 1 0 0 1 0 1 1 Modify PDP context accept (Network to MS direction) 0 1 0 0 1 1 0 0 Modify PDP context reject 0 1 0 0 1 1 0 1 Activate secondary PDP context request 0 1 0 0 1 1 1 0 Activate secondary PDP context accept 0 1 0 0 1 1 1 1 Activate secondary PDP context reject 0 1 0 1 0 0 0 0 Reserved: was allocated in earlier phases of the protocol 0 1 0 1 0 0 0 1 Reserved: was allocated in earlier phases of the protocol 0 1 0 1 0 0 1 0 Reserved: was allocated in earlier phases of the protocol 0 1 0 1 0 0 1 1 Reserved: was allocated in earlier phases of the protocol 0 1 0 1 0 1 0 0 Reserved: was allocated in earlier phases of the protocol 0 1 0 1 0 1 0 1 SM Status

10.5 Other information elements（その他の IE） TS 24.007 では、4 つの異なるフォーマット(V, LV, T, TV, TLV)と 4 つの IE のカテゴリ(type 1, 2, 3, 4)が定義されて

いる。

非強制的パート内の IE の第 1 オクテットは、IE の IEI を含んでいる。このオクテットがメッセージの中で既知の IEIに対応しない場合、受信側ではこの IE が、type 1 あるいは 2（すなわち、1 オクテット長の IE）であるか、または

Type 4(すなわち、次のオクテットは IE の残り部分の長さを示す長さインディケータである)であるかを特定すること (TS 24.007 参照) 。

そうすることによって、受信側は未知の IE をスキップして、その後の IE を解析できるようになる。

RR 管理、MM、そして CC、以上 3 つのプロトコルのうち、少なくとも 2 つに共通な IE を、セクション 10.5.1 にリスト

アップした。

MM プロトコル用 IE をセクション 10.5.3 に、CC プロトコル用 IE をセクション 10.5.4 にリストアップした。デフォルト

IEI は付録 K にリストアップした。

NOTE: 異なるプロトコルに属する場合、異なる IE が同じデフォルト IEI を持つこともある。

セクション 10.5.1、10.5.3 および 10.5.4 では、IE のタイプの説明は、IE タイプのアルファベットの順で組織される。

各 IE タイプを 1 つのサブセクションに記述される。

サブセクションは、イントロダクションがある場合もある。

- もしあれば、IE の目的の説明

- もしあれば、IE が type 1, 2, 3, 4 , 5 のどれに属しているか

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 297

- もしあれば、IE が type 5 であるか否か、またはそれがフォーマット TV (type 1 および 3) または TLV (type 4)で使用されるか否かを示す長さ

サブセクションの図は、IE インジケーションの構造を定義する。

- もしあれば、IEI のポジションと長さ（ただし、IE に IEI が含まれるか否かは、IE が発生するメッセージによって

決まる）

- IE の値パートを構成するフィールド

- もしあれば、長さインジケータのポジションと長さ（ただし、長さインジケータの有無は、IE のタイプによって決

まる）

- もしあれば、IE を構成するオクテットのオクテット数（以下の理由 a）参照）。

後に、サブセクションには、IE の value part を構成するフィールドの構造および値範囲を定義する表を含んでいる。メッセージ中の IE の発生順序については、第 9 章で定義される。

コンテンツがハーフオクテットの IE が連続するように、メッセージの強制的パート内の IE の順序が選ばれる。例えば、

初の type 1 IE はオクテット N のビット 1～4 を、第 2 の type 1 IE はオクテット N のビット 5～8 を、第 3 の type 1 IE は N + 1 ののビット 1～4 を使用する。type 1 IE の数が奇数の場合、これらの IE が使用する後のオクテットの

ビット 5～8 には、format V 内のスペアハーフオクテット IE が含まれる。

本技術仕様書中の IE の説明においては、「スペアビット」として定義されるこれらのビットは、送信側では指示値(0または 1)に設定され、これらの値は受信側では無視される。少数の例外を除いて、TS 24.008 ではスペアビット" 0 "に設定される。

type 4 IE をコーディングするに際しては、以下の規則が適用される。

a) 1 オクテットのオクテット番号(それはサブセクションの図中で定義される)は、正の整数、もしあれば追加文字

列、そしてもしあれば追加アスタリスクから構成される。節 f)参照。正の整数は、1 オクテットまたは複数オクテ

ットのグループを特定する。

b) 各オクテットグループは、自分自身のエンティティを含む。オクテットグループの内部構造は他の方法で定義

することもできる。

c) オクテットグループはいくつかの拡張メカニズムを使用して構成される。優先拡張メカニズムとは、拡張ビット

である各オクテット内のビット 8 を使用して、次のオクテット（Na, Nb 等）までオクテットを拡張するためのもの

である。

ビット値 " 0 "は、オクテット・グループが次のオクテットまで継続することを示す。ビット値 " 1 " は、このオクテ

ットがグループの後のオクテットであることを示す。 1 オクテット(Nb)が存在する場合、前のオクテット(N と

Na)も必ず存在する。

セクション 10.5.1～10.5.4 内でのフォーマルな記述方法では、他のオクテットが続く場合には、ビット 8 は"0/1 ext"としてマークされる。拡張ドメイン内の終オクテットの場合には、ビット 8 が"1 ext"としてマークされる。

プロトコルの後のバージョンにおいては、追加オクテットを定義 ("1 ext" は"0/1 ext"に変更)し、そのような追

加オクテットを受信するために望ましい装置を定義することもできる。これらのオクテットの内容は無視するこ

と。ただし、第 9 章と第 10 章で示された長さだけは、プロトコルのこのバージョンを考慮する。

d) 上のように定義された拡張メカニズムに加えて、（オクテット N の）ビット 7～1 で示すことによって、次のオクテ

ット(N+1, N+2 等)までオクテット(N)を拡張することもできる。

e) メカニズム c) と d)を組み合わせることもできる。

f) オプションオクテットはアスタリスク(*)でマークされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 298

10.5.1 Common information elements（共通 IE）

10.5.1.1 Cell identity

Cell Identity IE の目的は、LA 内のセルを特定することである。

Cell Identity IE は、図 10.5.1/TS 24.008 および表 10.5.1/TS 24.008 に示されるようにエンコードされる。

Cell Identity IE は、3 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 Cell Identity IEI octet 1

CI value

octet 2

CI value (continued)

octet 3

図図図図 10.5.1/TS 24.008 Cell Identity information element

表表表表 10.5.1/TS 24.008: Cell Identity information element

CI value, Cell identity value (octet 2 and 3) In the CI value field bit 8 of octet 2 is the most significant bit and bit 1 of octet 3 the least significant bit. The coding of the cell identity is the responsibility of each administration. Coding using full hexadecimal representation may be used. The cell identity consists of 2 octets.

10.5.1.2 Ciphering Key Sequence Number

GSM 認証チャレンジにおいては、Ciphering Key Sequence Number IE の目的は、ネットワークが認証処理を起動

せずに MS 内に保存された暗号鍵 Kc を特定することを可能にすることにある。

ciphering key sequence number はネットワークによって割当てられて、AUTHENTICATION REQUEST メッセー

ジといっしょに MS に送信され、算出された暗号鍵 Kc といっしょに保存される。

Ciphering Key Sequence Number IE は、図 10.5.2/TS 24.008 および表 10.5.2/TS 24.008 に示されるようにエン

コードされる。

UMTS 認証チャレンジにおいては、Ciphering Key Sequence Number IE の目的は、ネットワークが認証処理を起

動せずに MS 内に保存された暗号鍵 CK と完全鍵 IK を特定することを可能にすることにある。CK と IK は KSI（Key Set Identifier、TS 33.102 参照）を構成し、CKSN と同様にエンコードされ、それゆえ CKSN フィールド内に含

まれる。

ciphering key sequence number IE は type 1 IE である。

8 7 6 5 4 3 2 1 Ciphering Key .

Sequence Number . IEI .

0

spare

key sequence octet 1

図図図図 10.5.2/TS 24.008 Ciphering Key Sequence Number information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 299

表表表表 10.5.2/TS 24.008: Ciphering Key Sequence Number information element

Key sequence (octet 1) Bits 3 2 1 0 0 0 through Possible values for the ciphering key 1 1 0 sequence number 1 1 1 No key is available (MS to network); Reserved (network to MS)

10.5.1.3 Location Area Identification

Location Area Identification IE の目的は、GSM システムがカバーするエリア内で LA を明示的に提供することにあ

る。

Location Area Identification IE は、図 10.5.3/TS 24.008 および表 10.5.3/TS 24.008 内に示されるようにエンコー

ドされる。

Location Area Identification IE は、6 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 Location Area Identification IEI octet 1

MCC digit 2

MCC digit 1

octet 2

MNC digit 3

MCC digit 3

octet 3

MNC digit 2

MNC digit 1

octet 4

LAC

octet 5

LAC (continued)

octet 6

図図図図 10.5.3/TS 24.008 Location Area Identification information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 300

表表表表 10.5.3/TS 24.008: Location Area Identification information element

MCC, Mobile country code (octet 2 and 3) The MCC field is coded as in ITU-T Rec. E212, Annex A. If the LAI is deleted the MCC and MNC shall take the value from the deleted LAI. In abnormal cases, the MCC stored in the mobile station can contain elements not in the set {0, 1 ... 9}. In such cases the mobile station should transmit the stored values using full hexadecimal encoding. When receiving such an MCC, the network shall treat the LAI as deleted. MNC, Mobile network code (octet 3 bits 5 to 8, octet 4) The coding of this field is the responsibility of each administration but BCD coding shall be used. The MNC shall consist of 2 or 3 digits. For PCS 1900 for NA, Federal regulation mandates that a 3-digit MNC shall be used. However a network operator may decide to use only two digits in the MNC in the LAI over the radio interface. In this case, bits 5 to 8 of octet 3 shall be coded as "1111". Mobile equipment shall accept LAI coded in such a way. Note 1: In earlier versions of this protocol, the possibility to use a one digit MNC

in LAI was provided on the radio interface. However as this was not used this possibility has been deleted.

Note 2: In earlier versions of this protocol, bits 5 to 8 of octet 3 were coded as

"1111". Mobile equipment compliant with these earlier versions of the protocol may be unable to understand the 3-digit MNC format of the LAI, and therefore unable to register on a network broadcasting the LAI in this format.

In abnormal cases, the MNC stored in the mobile station can have: - digit 1 or 2 not in the set {0, 1 ... 9}, or - digit 3 not in the set {0, 1 ...9, F} hex. In such cases the mobile station shall transmit the stored values using full hexadecimal encoding. When receiving such an MNC, the network shall treat the LAI as deleted. The same handling shall apply for the network, if a 3-digit MNC is sent by the mobile station to a network using only a 2-digit MNC. LAC, Location area code (octet 5 and 6) In the LAC field bit 8 of octet 5 is the most significant bit and bit 1 of octet 6 the least significant bit. The coding of the location area code is the responsibility of each administration except that two values are used to mark the LAC, and hence the LAI, as deleted. Coding using full hexadecimal representation may be used. The location area code consists of 2 octets. If a LAI has to be deleted then all bits of the location area code shall be set to one with the exception of the least significant bit which shall be set to zero. If a SIM is inserted in a Mobile Equipment with the location area code containing all zeros, then the Mobile Equipment shall recognise this LAC as part of a deleted LAI

10.5.1.4 Mobile Identity

Mobile Identity IE の目的は、IMSI、TMSI/P-TMSI、IMEI/IMEISV（international mobile equipment identity together with the software version number）のいずれかを提供することにある。

それぞれの長さは、IMSI は 15 桁、TMSI/P-TMSI は 4 オクテット長、IMEI は 15 桁、IMEISV は 16 桁を超えないこ

と（TS 23.003 参照）。

パケットページング用に、ネットワークは以下の優先度にしたがって mobile identity type を選択すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 301

1- P-TMSI: 可能ならば P-TMSI を使用すること。

2- IMSI: P-TMSI が利用可能でない場合、IMSI を使用すること。

緊急呼の確立、緊急呼の再確立、モバイル着信呼の確立、識別処理、GMM 識別処理、GMM 認証と暗号化処理、

そして暗号化モード設定処理を除くすべてのトランザクションについて、MS およびネットワークは、次のプライオリテ

ィ mobile identity type を選択すること:

1- TMSI: 可能ならば TMSI を使用すること。

2- IMSI: TMSI が利用可能でない場合、IMSI を使用すること。

モバイル着信呼確立の場合、MS は PAGING REQUEST メッセージ内でネットワークから受信したのと同じ mobile identity type を選択すること。

緊急呼確立と再確立の場合、MS は以下のプライオリティで mobile identity type を選択すること。

1- TMSI: 可能ならば TMSI を使用すること。

2- IMSI: TMSI が利用可能でない場合、IMSI を使用すること。

3- SIM カードが利用可能でない場合、もしくは MS が SIM カードを無効と判定した場合、もしくは、IMSI もTMSI も利用可能でない場合、IMEI を使用すること。

識別処理と GMM 識別処理のなかで、MS はネットワークから要求された mobile identity type を選択すること。

暗号化モード設定処理および GMM 認証および暗号化処理の中では、MS は IMEISV を選択すること。

Mobile Identity IE は、図 10.5.4/TS 24.008 および表 10.5.4/TS 24.008 中で示されるようにエンコードされる。

Mobile Identity IE は、type 4 IE であり、少長 3 オクテット、台長 11 オクテットである。さらに例えばナンバリン

グプランなどによって、長さが制限されることもある。

8 7 6 5 4 3 2 1 Mobile Identity IEI octet 1

Length of mobile identity contents

octet 2

Identity digit 1

odd/evenindic

Type of identity

octet 3

Identity digit p+1

Identity digit p

octet 4*

図図図図 10.5.4/TS 24.008 Mobile Identity information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 302

表表表表 10.5.4/TS 24.008: Mobile Identity information element

Type of identity (octet 3) Bits 3 2 1 0 0 1 IMSI 0 1 0 IMEI 0 1 1 IMEISV 1 0 0 TMSI/P-TMSI 0 0 0 No Identity note 1) All other values are reserved. Odd/even indication (octet 3) Bit 4 0 even number of identity digits and also when the TMSI/P-TMSI is used 1 odd number of identity digits Identity digits (octet 3 etc) For the IMSI, IMEI and IMEISV this field is coded using BCD coding. If the number of identity digits is even then bits 5 to 8 of the last octet shall be filled with an end mark coded as "1111". If the mobile identity is the TMSI/P-TMSI then bits 5 to 8 of octet 3 are coded as "1111" and bit 8 of octet4 is the most significant bit and bit 1 of the last octet the least significant bit. The coding of the TMSI/P-TMSI is left open for each administration.

NOTE: 任意の有効な ID なしでページングメッセージを構成して、ページングサブチャネル上で送信する場合

に使用することができる。

10.5.1.5 Mobile Station Classmark 1

Mobile Station Classmark 1 IE の目的は、ネットワークに対して MS 装置の高い優先度という見地から関連する情

報を提供することにある。これは、ネットワークが MS のオペレーションを扱う方法に影響する。 Mobile Station Classmark の情報は、一般的な MS の特性を通知するので、フィールドで明示的に通知した場合を除き、それが送

信されるチャネルの周波数帯とは無関係である。

Mobile Station Classmark 1 IE は、図 10.5.5/TS 24.008 および表 10.5.5/TS 24.008 に示すようにエンコードされ

る。

The Mobile Station Classmark 1 is a type 3 information element with 2 octets length. Mobile Station Classmark 1 は type 3 IE であり、2 オクテット長である。

8 7 6 5 4 3 2 1 Mobile Station Classmark 1 IEI octet 1

0 spare

Revision level

ES IND

A5/1 RF power Capability

octet 2

図図図図 10.5.5/TS 24.008 Mobile Station Classmark 1 information element

GSM をサポートする MS は、たとえ UMTS 無線アクセス技術にアクセスしている場合でも、GSM 無線アクセス技術

と関係する全てのフィールドをエンコードすること。GSM をサポートしない UMTS MS は、プロトコルのそのバージョ

ンで定義され、reserve されていない任意の値を使用して GSM 無線アクセス技術にだけ関係すフィールドをエンコ

ードすること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 303

表表表表 10.5.5/TS 24.008: Mobile Station Classmark 1 information element

Revision level (octet 2) Required for MS supporting GSM and UMTS. Bits 7 6 0 0 Reserved for GSM phase 1 0 1 Used by GSM phase 2 mobile stations 1 0 Used by mobile stations supporting this version of the protocol 1 1 Reserved for future use ES IND (octet 2, bit 5) "Controlled Early Classmark Sending" option implementation Required for MS supporting GSM. 0 "Controlled Early Classmark Sending" option is not implemented in the MS 1 "Controlled Early Classmark Sending" option is implemented in the MS NOTE: The value of the ES IND gives the implementation in the MS. It's value is

not dependent on the broadcast SI 3 Rest Octet <Early Classmark Sending Control> value.

A5/1 algorithm supported (octet 2, bit4) Required for mobile station supporting GSM. 0 encryption algorithm A5/1 available 1 encryption algorithm A5/1 not available RF power capability (octet 2) Required for mobile stations supporting GSM. Bits 3 2 1 0 0 0 class 1 0 0 1 class 2 0 1 0 class 3 0 1 1 class 4 1 0 0 class 5 All other values are reserved. When the DCS 1800 or PCS 1900 band is used (for exceptions see 3.4.18): Bits 3 2 1 0 0 0 class 1 0 0 1 class 2 0 1 0 class 3 All other values are reserved.


Mobile Station Classmark 2 IE の目的は、ネットワークに対して MS 装置の高い優先度および低い優先度という双

方の見地から関連する情報を提供することにある。これは、ネットワークが MS のオペレーションを扱う方法に影響

する。 Mobile Station Classmark の情報は、一般的な MS の特性を通知するので、フィールドで明示的に通知した

場合を除き、それが送信されるチャネルの周波数帯とは無関係である。

Mobile Station Classmark 2 IE は、図 10.5.6/TS 24.008、表 10.5.6a/TS 24.008、および表 10.5.6b/TS 24.008に示すようにエンコードされる。

Mobile Station Classmark 2 は type 4 IE であり、5 オクテット長である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 304

8 7 6 5 4 3 2 1 Mobile station classmark 2 IEI octet 1

Length of mobile station classmark 2 contents

octet 2

0 spare

Revision level

ES IND

A5/1

RF power capability

octet 3

0 spare

PS capa.

SS Screen. Indicator

SM capabi.

VBS

VGCS

FC

octet 4

CM3

0 spare

LCSVA CAP

UCS2

SoLSA

CMSP

A5/3

A5/2

octet 5

NOTE: バックワード互換性上の問題から、オクテット 4 のビット 8 は、オクテット 3 のビット 8,7,6 が"0 0 0"でない限り、使

用してはならない。


表表表表 10.5.6a/TS 24.008: Mobile Station Classmark 2 information element

Revision level (octet 3) Required for MS supporting GSM and UMTS. Bits 7 6 0 0 Reserved for GSM phase 1 0 1 Used by GSM phase 2 mobile stations 1 0 Used by mobile stations supporting this version of the protocol 1 1 Reserved for future use ES IND (octet 3, bit 5) "Controlled Early Classmark Sending" option implementation Required for MS supporting GSM. 0 "Controlled Early Classmark Sending" option is not implemented in the MS 1 "Controlled Early Classmark Sending" option is implemented in the MS NOTE: The value of the ES IND gives the implementation in the MS. It's value is not

dependent on the broadcast SI 3 Rest Octet <Early Classmark Sending Control> value A5/1 algorithm supported (octet 3, bit 4) Required for MS supporting GSM. 0 encryption algorithm A5/1 available 1 encryption algorithm A5/1 not available RF Power Capability (Octet 3) Required for MS supporting GSM. When GSM 450, GSM 480, GSM 850, GSM 900 P, E [or R] band is used (for exceptions see GSM 04.18): Bits 3 2 1 0 0 0 class 1 0 0 1 class 2 0 1 0 class 3 0 1 1 class 4 1 0 0 class 5 All other values are reserved. When the DCS 1800 or PCS 1900 band is used (for exceptions see 3): Bits 3 2 1 0 0 0 class 1 0 0 1 class 2 0 1 0 class 3 All other values are reserved.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 305


PS capability (pseudo-synchronization capability) (octet 4) Required for MS supporting GSM Bit 7 0 PS capability not present 1 PS capability present SS Screening Indicator (octet 4) Required for MS supporting GSM and UMTS Bits 6 5 0 0 defined in TS 24.080 0 1 defined in TS 24.080 1 0 defined in TS 24.080 1 1 defined in TS 24.080 SM capability (MT SMS pt to pt capability) (octet 4) Required for MS supporting GSM. Bit 4 0 Mobile station does not support mobile terminated point to point SMS 1 Mobile station supports mobile terminated point to point SMS 表 10.5.6a/TS 24.008: Mobile Station Classmark 2 information element VBS notification reception (octet 4) Required for MS supporting GSM. Bit 3 0 no VBS capability or no notifications wanted 1 VBS capability and notifications wanted VGCS notification reception (octet 4) Required for MS supporting GSM. Bit 2 0 no VGCS capability or no notifications wanted 1 VGCS capability and notifications wanted FC Frequency Capability (octet 4) Required for MS supporting GSM. When GSM 400 band is used (for exceptions see GSM 04.18): Bit 1 0 Reserved for future use (for definition of frequency bands see GSM 05.05) Note: This bit conveys no information about support or non support of the E-GSM or R-GSM

band when transmitted on a GSM 400 channel. When GSM 850 band is used (for exceptions see GSM 04.18): Bit 1 0 Reserved for future use (for definition of frequency bands see GSM 05.05) Note: This bit conveys no information about support or non support of the E-GSM or R-GSM

band when transmitted on a GSM 850 channel.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 306


When a GSM 900 band is used (for exceptions see GSM 04.18): Bit 1 0 The MS does not support the E-GSM or R-GSM band (For definition of frequency

bands see GSM 05.05) 1 The MS does support the E-GSM or R-GSM (For definition of frequency bands see

GSM 05.05) Note: For mobile station supporting the R-GSM band further information can be found in MS

Classmark 3. When the DCS 1800 band is used (for exceptions see GSM 04.18): Bit 1 0 Reserved for future use (for definition of frequency bands see GSM 05.05) Note: This bit conveys no information about support or non support of the E-GSM or R-GSM

band when transmitted on a DCS 1800 channel. When the PCS 1900 band is used (for exceptions see GSM 04.18): Bit 1 0 Reserved for future use (for definition of frequency bands see GSM 05.05) Note: This bit conveys no information about support or non support of the E-GSM or R-GSM

band when transmitted on a PCS 1900 channel. CM3 (octet 5, bit 8) Required for MS supporting GSM. 0 The MS does not support any options that are indicated in CM3 1 The MS supports options that are indicated in classmark 3 IE LCS VA capability (LCS value added location request notification capability) (octet 5,bit 6) Required for MS supporting GSM. 0 LCS value added location request notification capability not supported 1 LCS value added location request notification capability supported UCS2 treatment (octet 5, bit 5) Required for MS suppporting UMTS. This information field indicates the likely treatment by the mobile station of UCS2 encoded character strings. If not included, the value 0 shall be assumed by the receiver. 0 the ME has a preference for the default alphabet (defined in GSM 03.38) over UCS2. 1 the ME has no preference between the use of the default alphabet and the use of

UCS2. SoLSA (octet 5, bit 4) Required for MS supporting GSM. 0 The ME does not support SoLSA. 1 The ME supports SoLSA. CMSP: CM Service Prompt (octet 5, bit 3) $(CCBS)$ Required for MS supporting GSM and UMTS. 0 "Network initiated MO CM connection request" not supported. 1 "Network initiated MO CM connection request" supported for at least one CM protocol. A5/3 algorithm supported (octet 5, bit 2) Required for MS supporting GSM. 0 encryption algorithm A5/3 not available 1 encryption algorithm A5/3 available A5/2 algorithm supported (octet 5, bit 1) Required for MS supporting GSM. 0 encryption algorithm A5/2 not available 1 encryption algorithm A5/2 available

GSM をサポートする MS は、たとえ UMTS 無線アクセス技術にアクセスしている場合でも、GSM 無線アクセス技術

と関係する全てのフィールドをエンコードすること。GSM をサポートしない UMTS MS は、プロトコルのそのバージョ

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 307

ンで定義され、reserve されていない任意の値を使用して GSM 無線アクセス技術にだけ関係すフィールドをエンコ

ードすること。

NOTE: MS が GSM 無線アクセス技術にアクセスする場合、クラスマーク問合せ処理を起動して、追加的 MSケーパビリティ情報を獲得することもできる。


Mobile Station Classmark 3 IE の目的は、ネットワークに対して MS 装置の見地から関連する情報を提供すること

にある。これは、ネットワークが MS のオペレーションを扱う方法に影響する。 Mobile Station Classmark の情報は、

一般的な MS の特性を通知するので、フィールドで明示的に通知した場合を除き、それが送信されるチャネルの周

波数帯とは無関係である。

Mobile Station Classmark 3 は type 4 IE であり、14 オクテット長である。

Mobile Station Classmark 3 IE は、図 10.5.7/TS 24.008 および表 10.5.7/TS 24.008 に示すようにエンコードされ

る。

NOTE: 長さに関して 14 オクテットの制限を設けることにより、CLASSMARK CHANGE メッセージが L2 の１

フレーム内に収まる。

意味的規則：マルチバンド MS は、自身がサポートする全ての周波数帯に関する情報を提供すること。シングルバン

ド MS は、MS Classmark 3 内のフィールド Multiband Supported, GSM 400 Bands Supported, GSM 850 Associated Radio Capability または PCS 1900 Associated Radio Capability 内で自身がサポートする周波数帯

を通知してはならない。DCS 1800 と PCS 1900 でいくつかの無線周波数チャネルが共有されるので、MS は DCS 1800 帯または PCS 1900 帯のどちらをサポートするのか通知すること。

意味的規則：Multi Slot Class フィールドに 19 以上の値が含まれる場合には、MS は MS Measurement Capability フィールドを含むこと（GSM 05.02 参照）。

通常、終的なスペアビットの数はオクテット境界に届く少数である。受信側では、正しくデコードするために必要

ならば、受信文字列の後に値"0"のビットをいくつか追加してもよい。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 308

<Classmark 3 Value part> ::= < spare bit > { < Multiband supported : { 000 } > < A5 bits > < Multiband supported : { 101 | 110 } > < A5 bits > < Associated Radio Capability 2 : bit(4) > < Associated Radio Capability 1 : bit(4) > < Multiband supported : { 001 | 010 | 100 } > < A5 bits > < spare bit >(4) < Associated Radio Capability 1 : bit(4) > } { 0 | 1 < R Support > } { 0 | 1 < Multi Slot Capability > } < UCS2 treatment: bit > < Extended Measurement Capability : bit > { 0 | 1 < MS measurement capability > } { 0 | 1 < MS Positioning Method Capability > } { 0 | 1 < EDGE Multi Slot Capability > } { 0 | 1 < EDGE Struct > } { 0 | 1 < GSM 400 Bands Supported : { 01 | 10 | 11 } > < GSM 400 Associated Radio Capability: bit(4) > } { 0 | 1 <GSM 850 Associated Radio Capability : bit(4) > } { 0 | 1 <PCS 1900 Associated Radio Capability : bit(4) > } < UMTS FDD Radio Access Technology Capability : bit > < UMTS TDD Radio Access Technology Capability : bit > < CDMA 2000 Radio Access Technology Capability : bit > { 0 | 1 < DTM Multi Slot Sub-Class : bit(2) > < MAC Mode Support : bit > < EGPRS Support : bit > } < spare bit > ; < A5 bits > ::= < A5/7 : bit > < A5/6 : bit > < A5/5 : bit > < A5/4 : bit > ; <R Support>::= < R-GSM band Associated Radio Capability : bit(3) > ; < Multi Slot Capability > ::= < Multi Slot Class : bit(5) > ; < MS Measurement capability > ::= < SMS_VALUE : bit (4) > < SM_VALUE : bit (4) > ; < MS Positioning Method Capability > ::= < MS Positioning Method : bit(5) > ; < EDGE Multi Slot Capability > ::= < EDGE Multi Slot Class : bit(5) > ; <EDGE Struct> : := < Modulation Capability : bit > { 0 | 1 < EDGE RF Power Capability 1: bit(2) > } { 0 | 1 < EDGE RF Power Capability 2: bit(2) > }


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 309

表表表表 10.5.7/TS 24.008: Mobile Station Classmark 3 information element

Multiband Supported (3 bit field) Band 1 supported (third bit of the field) Bit 3 0 P-GSM not supported 1 P-GSM supported Band 2 supported (second bit of the field) BIT 2 0 E-GSM or R-GSM not supported 1 E-GSM or R-GSM supported Band 3 supported (first bit of the field) Bit 1 0 DCS 1800 not supported 1 DCS 1800 supported The indication of support of P-GSM band or E-GSM or R-GSM band is mutually exclusive. When the 'Band 2 supported' bit indicates support of E-GSM or R-GSM, the presence of the <R Support> field, see below, indicates if the E-GSM or R-GSM band is supported. In this version of the protocol, the sender indicates in this field either none, one or two of these 3 bands supported. If only one band is indicated, the receiver shall ignore the Associated Radio Capability 2. For single band mobile station all bits are set to 0. A5/4 Bit 1 0 Encryption algorithm A5/4 not available 1 Encryption algorithm A5/4 available A5/5 Bit 1 0 Encryption algorithm A5/5 not available 1 Encryption algorithm A5/5 available A5/6 Bit 1 0 Encryption algorithm A5/6 not available 1 Encryption algorithm A5/6 available A5/7 0 Encryption algorithm A5/7 not available 1 Encryption algorithm A5/7 available Associated Radio capability 1 and 2 (4 bit fields) If either of P-GSM or E-GSM or R-GSM is supported, the radio capability 1 field indicates the radio capability for P-GSM, E-GSM or R-GSM, and the radio capability 2 field indicates the radio capability for DCS1800 if supported, and is spare otherwise. If none of P-GSM or E-GSM or R-GSM are supported, the radio capability 1 field indicates the radio capability for DCS1800, and the radio capability 2 field is spare. The radio capability contains the binary coding of the power class associated with the band indicated in multiband support bits (see GSMß05.05).

(continued...)

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 310

表表表表 10.5.1.7/TS 24.008 (continued): MS Classmark 3 information element

R Support In case where the R-GSM band is supported the R-GSM band associated radio capability field contains the binary coding of the power class associated (see GSM 05.05). A mobile station supporting the R-GSM band shall also when appropriate, (see 10.5.1.6) indicate its support in the 'FC' bit in the Mobile Station Classmark 2 information element. Note: the coding of the power class for P-GSM, E-GSM, R-GSM and DCS 1800 in radio capability 1 and/or 2 is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements. Multi Slot Class (5 bit field) In case the MS supports the use of multiple timeslots then the Multi Slot Class field is coded as the binary representation of the multislot class defined in TS GSM 05.02. UCS2 treatment (1 bit field) This information field indicates the likely treatment by the mobile station of UCS2 encoded character strings. If not included, the value 0 shall be assumed by the receiver. Bit 1 0 the ME has a preference for the default alphabet (defined in GSM 03.38) over UCS2. 1 the ME has no preference between the use of the default alphabet and the use of UCS2. Extended Measurement Capability (1 bit field) This bit indicates whether the mobile station supports 'Extended Measurements' or not Bit 1 0 the MS does not support Extended Measurements 1 the MS supports Extended Measurements SMS_VALUE (Switch-Measure-Switch) (4 bit field) The SMS field indicates the time needed for the mobile station to switch from one radio channel to another, perform a neighbour cell power measurement, and the switch from that radio channel to another radio channel.Bits 4 3 2 1 0 0 0 0 1/4 timeslot (~144 microseconds) 0 0 0 1 2/4 timeslot (~288 microseconds) 0 0 1 0 3/4 timeslot (~433 microseconds) . . . 1 1 1 1 16/4 timeslot (~2307 microseconds) SM_VALUE (Switch-Measure) (4 bit field) The SM field indicates the time needed for the mobile station to switch from one radio channel to another and perform a neighbour cell power measurement. Bits 4 3 2 1 0 0 0 0 1/4 timeslot (~144 microseconds) 0 0 0 1 2/4 timeslot (~288 microseconds) 0 0 1 0 3/4 timeslot (~433 microseconds) . . . 1 1 1 1 16/4 timeslot (~2307 microseconds) MS Positioning Method Capability (1 bit field) This bit indicates whether the MS supports Positioning Method or not for the provision of Location Services. MS Positioning Method (5 bit field) This field indicates the Positioning Method(s) supported by the mobile station. MS assisted E-OTD Bit 5 0 MS assisted E-OTD not supported 1 MS assisted E-OTD supported

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 311


MS based E-OTD Bit 4 0 MS based E-OTD not supported 1 MS based E-OTD supported MS assisted GPS Bit 3 0 MS assisted GPS not supported 1 MS assisted GPS supported MS based GPS Bit 2 0 MS based GPS not supported 1 MS based GPS supported MS conventional GPS Bit 1 0 conventional GPS not supported 1 conventional GPS supported EDGE Multi Slot class (5 bit field) In case the EDGE MS supports the use of multiple timeslots and the number of supported time slots is different from number of time slots supported for GMSK then the EDGE Multi Slot class field is included and is coded as the binary representation of the multislot class defined in TS GSM 05.02. Modulation Capability Modulation Capability field indicates the supported modulation scheme by MS in addition to GMSK Bit 1 0 8-PSK supported for downlink reception only 1 8-PSK supported for uplink transmission and downlink reception EDGE RF Power Capability 1 (2 bit field) If 8-PSK is supported for both uplink and downlink, the EDGE RF Power Capability 1 field indicates the radio capability for GSM900. The radio capability contains the binary coding of the EDGE power class(see GSMß05.05). EDGE RF Power Capability 2 (2 bit field) If 8-PSK is supported for both uplink and downlink, the EDGE RF Power Capability 2 field indicates the radio capability for DCS1800 or PCS1900 if supported, and is not included otherwise. The radio capability contains the binary coding of the EDGE power class (see GSM 05.05).

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 312


GSM 400 Bands Supported (2 bit field) Bits 2 1 0 1 GSM 480 supported, GSM 450 not supported 1 0 GSM 450 supported, GSM 480 not supported 1 1 GSM 450 supported, GSM 480 supported GSM 400 Associated Radio Capability (4 bit field) If either GSM 450 or GSM 480 or both is supported, the GSM 400 Associated Radio Capability field indicates the radio capability for GSM 450 and/or GSM 480. The radio capability contains the binary coding of the power class associated with the band indicated in GSM 400 Bands Supported bits (see GSM 05.05). Note: the coding of the power class for GSM 450 and GSM 480 in GSM 400 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements. GSM 850 Associated Radio Capability (4 bit field) This field indicates whether GSM 850 band is supported and its associated radio capability. The radio capability contains the binary coding of the power class associated with the GSM 850 band (see GSM 05.05). Note: the coding of the power class for GSM 850 in GSM 850 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements. PCS 1900 Associated Radio Capability (4 bit field) This field indicates whether PCS 1900 band is supported and its associated radio capability. The radio capability contains the binary coding of the power class associated with the PCS 1900 band (see GSM 05.05). Note: the coding of the power class for PCS 1900 in PCS 1900 Associated Radio Capability is different to that used in the Mobile Station Classmark 1 and Mobile Station Classmark 2 information elements.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 313


UMTS FDD Radio Access Technology Capability (1 bit field) Bit 1 0 UMTS FDD not supported 1 UMTS FDD supported UMTS TDD Radio Access Technology Capability (1 bit field)

Bit 1 0 UMTS TDD not supported 1 UMTS TDD supported CDMA 2000 Radio Access Technology Capability (1 bit field)

Bit 1 0 CDMA2000 not supported 1 CDMA2000 supported

DTM Multi Slot Sub-Class (2 bit field) This field indicates the DTM capabilities of the MS. The DTM Multi Slot Sub-Class is independent from the Multi Slot Capabilities field. It is coded as follows:

Bit 2 1 0 0 Sub-Class 1 supported 0 1 Sub-Class 5 supported 1 0 Sub-Class 9 supported 1 1 Reserved for future extension. If received, the network shall interpret this as ‘00’ MAC Mode Support (1 bit field) This field indicates whether the MS supports Dynamic and Fixed Allocation or only supports Exclusive Allocation. It is coded as follows:

Bit 1 0 Dynamic and Fixed Allocation not supported 1 Dynamic and Fixed allocation supported

EGPRS Support (1 bit field) This field indicates whether or not the MS supports EGPRS. It is coded as follows:

Bit 1 0 EGPRS not supported 1 EGPRS supported

10.5.1.8 Spare Half Octet

奇数個の half octet type 1 IE が使用される場合に、本エレメントが第 9 章のメッセージの記述中で使用される。本

エレメントは 0 にセットされたスペアビットで満たされ、特に規定されない限りオクテットのビット 5～8 に置かれる。

10.5.1.9 Descriptive group or broadcast call reference

Descriptive Group or Broadcast Call Reference の目的は、音声グループ呼またはブロードキャスト呼を説明する

情報を提供することにある。Descriptive Group or Broadcast Call Reference の IE は、サービスフラグ、

acknowledgement フラグ、呼優先度、およびグループ暗号鍵番号といっしょに、グループ／ブロードキャスト呼リファ

レンスから構成される。

Descriptive Group or Broadcast Call Reference IE は、図 10.5.8/TS 24.008 および表 10.5.8/TS 24.008 に示

すようにエンコードされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 314

Descriptive Group or Broadcast Call Reference IE は、type 3 IE であり、6 オクテット長である。

8 7 6 5 4 3 2 1 Group or broadcast call reference IEI octet 1

Binary coding of the group or broadcast call reference

octet 2

octet 3

octet 4

SF

AF

call priority

octet 5

Spare Ciphering information 0 0 0 0 octet 6

図図図図 10.5.8/TS 24.008 Descriptive Group or Broadcast Call Reference

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 315

表表表表 10.5.8/TS 24.008 Descriptive Group or Broadcast Call Reference

Binary code of the group or broadcast call reference The length of the binary code has 27 bits which is encoded in the octet 2, 3, 4 and Bits 8,7,6 (octet 5). The highest bit of the BC is the bit 8 in the octet 2 and the lowest bit is allocated in the bit 6 in the octet 5. (see also GSMß03.03) SF Service flag (octet 5) Bit 5 0 VBS (broadcast call reference) 1 VGCS (group call reference) AF Acknowledgement flag (octet 5) Bit 4 0 acknowledgement is not required 1 acknowledgement is required Call priority (octet 5) Bit 3 2 1 0 0 0 no priority applied 0 0 1 call priority level 4 0 1 0 call priority level 3 0 1 1 call priority level 2 1 0 0 call priority level 1 1 0 1 call priority level 0 1 1 0 call priority level B 1 1 1 call priority level A Ciphering information (octet 6) Bit 8 7 6 5 0 0 0 0 no ciphering 0 0 0 1 ciphering with cipher key number 1 0 0 1 0 ciphering with cipher key number 2 0 0 1 1 ciphering with cipher key number 3 0 1 0 0 ciphering with cipher key number 4 0 1 0 1 ciphering with cipher key number 5 0 1 1 0 ciphering with cipher key number 6 0 1 1 1 ciphering with cipher key number 7 1 0 0 0 ciphering with cipher key number 8 1 0 0 1 ciphering with cipher key number 9 1 0 1 0 ciphering with cipher key number A 1 0 1 1 ciphering with cipher key number B 1 1 0 0 ciphering with cipher key number C 1 1 0 1 ciphering with cipher key number D 1 1 1 0 ciphering with cipher key number E 1 1 1 1 ciphering with cipher key number F

10.5.1.10 Group Cipher Key Number

Group Cipher Key Number の目的は、MS が暗号／解読する際に使用するグループ暗号鍵に関する情報を提供

することにある。

Group Cipher Key Number IE は、図 10.5.9/TS 24.008 および表 10.5.9/TS 24.008 に示すようにエンコードされ

る。

Group Cipher Key Number IE は type 1 IE であり、1 オクテット長である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 316

8 7 6 5 4 3 2 1 Group cipher key number

IEI

Group cipher key number

図図図図 10.5.9/TS 24.008 Group Cipher Key Number

表表表表 10.5.9/TS 24.008 Group Cipher Key Number

Group cipher key number Bit 4 3 2 1 0 0 0 0 Spare 0 0 0 1 cipher key number 1 0 0 1 0 cipher key number 2 0 0 1 1 cipher key number 3 0 1 0 0 cipher key number 4 0 1 0 1 cipher key number 5 0 1 1 0 cipher key number 6 0 1 1 1 cipher key number 7 1 0 0 0 cipher key number 8 1 0 0 1 cipher key number 9 1 0 1 0 cipher key number A 1 0 1 1 cipher key number B 1 1 0 0 cipher key number C 1 1 0 1 cipher key number D 1 1 1 0 cipher key number E 1 1 1 1 cipher key number F

10.5.1.10a PD and SAPI $(CCBS)$

PD and SAPI IE の目的は、PD および SAPI（Service Access Point Identifier）に関する情報を提供することにある。

PD and SAPI IE は、図 10.5.10/TS 24.008 および表 10.5.10/TS 24.008 に示すようにエンコードされる。

PD and SAPI IE は type 3 IE であり、2 オクテット長である。

8 7 6 5 4 3 2 1 PD and SAPI IEI octet 1

0 spare

0 spare

SAPI PD octet 2

図図図図 10.5.10/TS 24.008 PD and SAPI information element

表表表表 10.5.1.10/TS 24.008: PD and SAPI information element

SAPI: Service Access Point Identifier (octet 2) Bits 6 5 0 0 SAPI 0 0 1 Reserved 1 0 Reserved 1 1 SAPI 3 PD: Protocol Discriminator (octet 2) bits 4-1 Encoded as specified in section 11.2.1 of 04.07.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 317

10.5.1.11 Priority Level

Priority Level の目的は、要求された／適用された優先度を定義する情報を提供することにある。Priority Level IEは、CM_SERVICE_REQUEST メッセージ、CALL_PROCEEDING メッセージ、および SETUP メッセージ内に含


Priority Level IE は、図 10.5.11/TS 24.008 および表 10.5.11/TS 24.008 に示すようにエンコードされる。

Priority Level IE は、type 1 IE であり、1 オクテット長である。

8 7 6 5 4 3 2 1 Priority Level

IEI 0

sparecall priority

octet 1

図図図図 10.5.11/TS 24.008 Priority Level

表表表表 10.5.11/TS 24.008 Priority Level

Call priority (octet 1) Bit 3 2 1 0 0 0 no priority applied 0 0 1 call priority level 4 0 1 0 call priority level 3 0 1 1 call priority level 2 1 0 0 call priority level 1 1 0 1 call priority level 0 1 1 0 call priority level B 1 1 1 call priority level A

10.5.1.12 Core Network System Information (UMTS only)

Core Network System Information の目的は、MS に対して MM および GMM 機能を制御するシステム情報パラメ

ータを設定する実際のパラメータを提供することにある。Core Network System Information は、いくつかの RRC メ

ッセージ内の特定の IE といっしょに MS に対して送信される。TS 25.331 参照。

NOTE: これらの IE は、IEI または長さインジケータを持たない。なぜならば、これらの IE は L3 メッセージ内に

は現れないからである。であるから、これらの IE は 24.007 で定義される一般的な IE 規則に従わない。

10.5.1.12.1 CN Common GSM-MAP NAS system information

CN Common GSM-MAP NAS system information エレメントの目的は、MS に対して MM および GMM 機能を制

御するシステム情報パラメータを設定する実際のパラメータを提供することにある。IEI と長さ情報のコーディングに

ついては TS 25.331 で定義されるので、本仕様書ではコンテンツのコーディングについてのみ規定する。

CN Common GSM-MAP NAS system information エレメントのコンテンツは、図 10.5.1.xx.1/TS 24.008 および表

10.5.1.12.1/TS 24.008 内で示すようにエンコードされる。

本エレメントのコンテンツの長さは 2 オクテット。MS は受信した追加オクテットを無視すること。

8 7 6 5 4 3 2 1 LAC octet 1

octet 2

図図図図 10.5.1.12.1/TS 24.008 Common system information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 318

表表表表 10.5.1.12.1/TS 24.008: Common system information element

LAC, Location Area Code (2 octet field) This field is the binary representation of the Location Area Code, see TS 23.003. The LAC field consists of 16 bits. Bit 8 in octet 1 is the most significant bit and bit 1 in octet 2 is the least significant bit.

10.5.1.12.2 CS domain specific system information

CN domain specific GSM-MAP NAS system information エレメントは CS ドメイン内で使用されるが、MS に対し

て MM 機能だけに関係するパラメータを設定する実際のパラメータを提供する。IEI と長さ情報のコーディングについ

ては TS 25.331 で定義されるので、本仕様書ではコンテンツのコーディングについてのみ規定する。

CS ドメインの場合、CN domain specific GSM-MAP NAS system information エレメントのコンテンツは、図

10.5.1.12.2/TS 24.008 および表 10.5.1.12.2/TS 24.008 に示すようにエンコードされる。本エレメントコンテンツの

長さは 2 オクテットである。MS は受信した追加オクテットを全て無視すること。

8 7 6 5 4 3 2 1 T3212 octet 1

Spare ATT octet 2

図図図図 10.5.1.xx.2/TS 24.008 CS domain specific system information element

表表表表 10.5.1.xx.2/TS 24.008: CS domain specific system information element

T3212 timeout value (1 octet field) The T3212 timeout field is coded as the binary representation of the timeout value for periodic updating in decihours. Bit 8 in octet 3 is the most significant bit and bit 1 in octet 3 is the least significant bit. Range: 1 to 255 The value 0 is used for infinite timeout value i.e. periodic updating shall not be used ATT, Attach-detach allowed (1 bit field): Bit 1 0 MSs shall not apply IMSI attach and detach procedure. 1 MSs shall apply IMSI attach and detach procedure The bits 2 – 8 of octet 1 are spare and shall be coded all zeros.

10.5.1.12.3 PS domain specific system information

PS domain specific GSM-MAP NAS system information エレメントは PS ドメイン内で使用されるが、MS に対し

て MM 機能だけに関係するパラメータを設定する実際のパラメータを提供する。IEI と長さ情報のコーディングについ

ては TS 25.331 で定義されるので、本仕様書ではコンテンツのコーディングについてのみ規定する。

PS ドメインの場合、PS domain specific GSM-MAP NAS system information エレメントのコンテンツは、図

10.5.1.12.3/TS 24.008 および表 10.5.1.12.3/TS 24.008 に示すようにエンコードされる。本エレメントコンテンツの

長さは 2 オクテットである。MS は受信した追加オクテットを全て無視すること。

8 7 6 5 4 3 2 1 RAC octet 1

Spare NMO octet 2

図図図図 10.5.1.12.3/TS 24.008 PS domain specific system information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 319

表表表表 10.5.1.12.3/TS 24.008: PS domain specific system information element

RAC, Routing Area Code (8 bit field) This field is the binary representation of the Routing Area Code, see TS 23.003. Bit 8 in octet 1 is the most significant bit and bit 1 in octet 1 is the least significant bit. NMO, Network Mode of Operation (1 bit field) This field is the binary representation of the Network Mode of Operation, see TS 23.060 Bit 1 0 Network Mode of Operation I 1 Network Mode of Operation II The bits 2 – 8 of octet 2 are spare and shall be coded all zeros.

10.5.2 Radio Resource management information elements. See 04.18 04.18 を参照。

10.5.3 Mobility management information elements.

10.5.3.1 Authentication parameter RAND

Authentication Parameter RAND IE の目的は、認証応答署名 SRES および暗号鍵 Kc(GSM 認証チャレンジ用)、または応答 RES と暗号鍵 CK と完全鍵 IK の双方（UMTS 認証チャレンジ用）を算出するために使用される、予測

不可能な乱数を MS に対して提供することにある。

Authentication Parameter RAND IE は、図 10.5.75/TS 24.008 および表 10.5.89/TS 24.008 に示すようにエンコ

ードされる。

Authentication Parameter RAND IE は type 3 IE であり、17 オクテット長である。

8 7 6 5 4 3 2 1 Authentication parameter RAND IEI octet 1

RAND value

octet 2

octet 17

図図図図 10.5.75/TS 24.008 Authentication Parameter RAND information element

表表表表 10.5.89/TS 24.008: Authentication Parameter RAND information element

RAND value (octet 2, 3,... and 17) The RAND value consists of 128 bits. Bit 8 of octet 2 is the most significant bit while bit 1 of octet 17 is the least significant bit.

10.5.3.1.1 Authentication Parameter AUTN (UMTS authentication challenge only)

Authentication Parameter AUTN IE の目的は、MS に対してネットワークを認証する手段を提供することにある。

Authentication Parameter AUTN IE は、図 10.5.75.1/TS 24.008 および表 10.5.89.1/TS 24.008 に示すようにエ

ンコードされる。

Authentication Parameter AUTN IE は type 4 IE であり、18 オクテット長。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 320

8 7 6 5 4 3 2 1 Authentication Parameter AUTN IEI octet 1

Length of AUTN contents octet 2 octet 3

AUTN

octet 18

図図図図 10.5.75.1/TS 24.008 Authentication Parameter AUTN information element (UMTS 認証チャレンジのみ認証チャレンジのみ認証チャレンジのみ認証チャレンジのみ)

表表表表 10.5.89.1/TS 24.008 Authentication Parameter AUTN information element (UMTS 認証チャレンジのみ認証チャレンジのみ認証チャレンジのみ認証チャレンジのみ)

AUTN value (octets 3 to 18) The AUTN consists of (SQN xor AK)||AMF||MAC =48+16+64 bits (see TS 33.102)

10.5.3.2 Authentication Response parameter

authentication response parameter IE の目的は、ネットワークに SIM カード内で算出された認証応答を提供する

ことにある。

authentication response parameter IE は、図 10.5.76/TS 24.008 および表 10.5.90 a & b /TS 24.008 に示すよう

にエンコードされる。

Authentication Response Parameter IE は 5 オクテット長の type 3 IE である。GSM 認証チャレンジでは、SIM カ

ード内で算出される応答（SRES）は 4 バイト長であり、authentication response parameter IE で設定される。

UMTS 認証チャレンジでは、SIM カード内で算出される応答（SRES）は大 16 オクテット長である。4 つの上位

オクテットに Authentication Response Parameter IE が含まれること。RES の残り部分は、Authentication Response Parameter (extension) IE 中に含まれること（10.5.3.2.1 参照）。

8 7 6 5 4 3 2 1 Authentication Response parameter IEI octet 1

SRES value or most significant

4 octets of RES :

octet 2

: octet 5

図図図図 10.5.76/TS 24.008 Authentication Response Parameter information element

表表表表 10.5.90a/TS 24.008: Authentication Response Parameter information element (SRES) (GSM のみのみのみのみ)

SRES value (octet 2, 3, 4 and 5) The SRES value consists of 32 bits. Bit 8 of octet 2 is the most significant bit while bit 1 of octet 5 is the least significant bit.

表表表表 10.5.90b/TS 24.008: Authentication Response Parameter information element (RES) (UMTS のみのみのみのみ)

RES value (octet 2, 3, 4 and 5) This contains the most significant 4 octets of RES If RES>4 octets, the remaining octets of RES shall appear in the Authentication Response Parameter (extension) IE (see 10.5.3.2.1)

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 321

10.5.3.2.1 Authentication Response Parameter (extension) (UMTS authentication challenge only)

認証応答パラメータ RES が 4 オクテットよりも長く（UMTS のみ）、そのために Authentication Response Parameter パラメータ内に収まらない場合に、本 IE が含まれる。

Authentication Response Parameter (extension) IE は、図 10.5.76.1/TS 24.008 および表 10.5.90.1/TS 24.008に示されるようにエンコードされる。

Authentication Response Parameter (extension) IE は、少長 3 オクテット、大長 14 オクテットの type 4 IE で

ある。

8 7 6 5 4 3 2 1 Authentication Response (extension) IEI octet 1

Length of Authentication Response contents octet 2 RES (all but 4 most significant octets)

: octet 3

: octet 14

図図図図 10.5.76.1/TS 24.008 Authentication Response Parameter (extension) information element (UMTS のののの

みみみみ)

表表表表 10.5.90.1/TS 24.008: Authentication Response Parameter (extension) information element (RES)

RES (extension) value (octet 3 to 14) This contains all but the 4 most significant octets of RES

10.5.3.2.2 Authentication Failure parameter (UMTS authentication challenge only)

Authentication Failure parameter IE の目的は、ネットワークに対して UMTS 認証チャレンジの後の'Synch failure'の場合に、再認証処理（TS 33.102 参照）を開始するために必要な情報を提供することにある。

Authentication Failure parameter IE は、図 10.5.76.2/TS 24.008 および表 10.5.90.2/TS 24.008 に示すようにエ


Authentication Failure parameter IE は、16 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Authentication Failure parameter IEI octet 1

Length ofAuthentication Failure parameter contents octet 2 Authentication Failure parameter

: octet 3

: octet 16

図図図図 10.5.76.2/TS 24.008 Authentication Failure parameter information element (UMTS 認証チャレンジの認証チャレンジの認証チャレンジの認証チャレンジの

みみみみ)

表表表表 10.5.90.2/TS 24.008: Authentication Failure parameter information element

Authentication Failure parameter value (octet 3 to 16) This contains AUTS (see TS 33.102)

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 322

10.5.3.3 CM service type

CM Service Type IE の目的は、ネットワークからどのサービスが要求されたかを指定することにある。

CM Service Type IE は、図 10.5.77/TS 24.008 および表 10.5.91/TS 24.008 に示すようにエンコードされる。

CM Service Type IE は type 1 IE である。

8 7 6 5 4 3 2 1 CM service type IEI service type octet 1

図図図図 10.5.77/TS 24.008 CM Service Type information element

表表表表 10.5.91/TS 24.008: CM Service Type information element

Service type (octet 1) Bits 4 3 2 1 0 0 0 1 Mobile originating call establishment or packet mode connection

establishment 0 0 1 0 Emergency call establishment 0 1 0 0 Short message service 1 0 0 0 Supplementary service activation 1 0 0 1 Voice group call establishment 1 0 1 0 Voice broadcast call establishment 1 0 1 1 Location Services All other values are reserved.

10.5.3.4 Identity type

Identity Type IE の目的は、どの識別が要求されたかを特定することにある。

Identity Type IE は、図 10.5.78/TS 24.008 および表 10.5.92/TS 24.008 に示すようにエンコードされる。

The Identity Type is a type 1 information element. Identity Type IE は type 1 IE である。

8 7 6 5 4 3 2 1 Identity type IEI 0

sparetype of identity octet 1

図図図図 10.5.78/TS 24.008 Identity Type information element

表表表表 10.5.92/TS 24.008: Identity Type information element

Type of identity (octet 1) Bits 3 2 1 0 0 1 IMSI 0 1 0 IMEI 0 1 1 IMEISV 1 0 0 TMSI All other values are reserved.

10.5.3.5 Location updating type

Location Updating Type IE の目的は、通常の更新、定期的更新、または IMSI アタッチのうちどれが希望されてい

るかを通知することにある。本 IE は、MS から受信した follow-on 要求を CM レイヤに通知することもできる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 323

Location Updating Type IE は、図 10.5.79/TS 24.008 および表 10.5.93/TS 24.008 に示すようにエンコードされる。

Location Updating Type IE は type 1 IE である。

8 7 6 5 4 3 2 1 Location updating

type IEI FOR 0

spareLUT octet 1

図図図図 10.5.79/TS 24.008 Location Updating Type information element

表表表表 10.5.93/TS 24.008: Location Updating Type information element

LUT (octet 1) Bits 2 1 0 0 Normal location updating 0 1 Periodic updating 1 0 IMSI attach 1 1 Reserved FOR (octet 1) The Follow-On Request bit (FOR) is coded as follows: Bits 4 0 No follow-on request pending 1 Follow-on request pending

10.5.3.5a Network Name

本 IE の目的は、文字列を MS にパスすることである。

Network Name IE は、図 10.5.80/TS 24.008 および表 10.5.94/TS 24.008 に示すようにエンコードされる。

Network Name IE は、少長 3 オクテットの type 4 IE である。L3 メッセージのオクテット数大長の制限を除き、

大長は規定されない（GSM 04.06 参照）。

8 7 6 5 4 3 2 1 Network Name IEI octet 1

Length of Network Name contents

octet 2

ext 1

coding scheme Add CI

Number of spare bits in last octet

octet 3

octet 4

Text String

octet n

図図図図 10.5.80/TS 24.008 Network Name information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 324

表表表表 10.5.94/TS 24.008 Network Name information element

Number of spare bits in last octet (octet 3, bits 1 to 3) 2 1 0 0 1 bit 8 is spare and set to "0" in octet n 0 1 0 bits 7 and 8 are spare and set to "0" in octet n 0 1 1 bits 6 to 8(inclusive) are spare and set to "0" in octet n 1 0 0 bits 5 to 8(inclusive) are spare and set to "0" in octet n 1 0 1 bits 4 to 8(inclusive) are spare and set to "0" in octet n 1 1 0 bits 3 to 8(inclusive) are spare and set to "0" in octet n 1 1 1 bits 2 to 8(inclusive) are spare and set to "0" in octet n 0 0 0 this field carries no information about the number of spare bits in octet n Add CI (octet 3, bit 4) 0 The MS should not add the letters for the Country's Initials to the text string 1 The MS should add the letters for the Country's Initials and a separator (e.g. a space) to the text string Coding Scheme (octet 3, bits 5-7) 0 0 0 Cell Broadcast data coding scheme, GSM default alphabet, language unspecified, defined in GSM 03.38 0 0 1 UCS2 (16 bit) [72] 0 1 0 to Reserved 1 1 1 Text String (octet 4 to octet n, inclusive) Encoded according to the Coding Scheme defined by octet 3, bits 5-7

10.5.3.6 Reject cause

Reject Cause IE の目的は、MS からの要求がなぜネットワークに拒否されたのか、その理由を通知することにある。

Reject Cause IE は、図 10.5.81/TS 24.008 および表 10.5.95/TS 24.008 に示すようにエンコードされる。

Reject Cause IE は、2 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 Reject cause IEI octet 1

reject cause value

octet 2

図図図図 10.5.81/TS 24.008 Reject Cause information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 325

表表表表 10.5.95/TS 24.008: Reject Cause information element

Reject cause value (octet 2) Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 1 0 IMSI unknown in HLR 0 0 0 0 0 0 1 1 Illegal MS 0 0 0 0 0 1 0 0 IMSI unknown in VLR 0 0 0 0 0 1 0 1 IMEI not accepted 0 0 0 0 0 1 1 0 Illegal ME 0 0 0 0 1 0 1 1 PLMN not allowed 0 0 0 0 1 1 0 0 Location Area not allowed 0 0 0 0 1 1 0 1 Roaming not allowed in this location area 0 0 0 1 0 0 0 1 Network failure 0 0 0 1 0 1 0 0 MAC failure 0 0 0 1 0 1 0 1 Synch failure 0 0 0 1 0 1 1 0 Congestion 0 0 1 0 0 0 0 0 Service option not supported 0 0 1 0 0 0 0 1 Requested service option not subscribed 0 0 1 0 0 0 1 0 Service option temporarily out of order 0 0 1 0 0 1 1 0 Call cannot be identified 0 0 1 1 0 0 0 0 } to } retry upon entry into a new cell 0 0 1 1 1 1 1 1 } 0 1 0 1 1 1 1 1 Semantically incorrect message 0 1 1 0 0 0 0 0 Invalid mandatory information 0 1 1 0 0 0 0 1 Message type non-existent or not implemented 0 1 1 0 0 0 1 0 Message type not compatible with the protocol state 0 1 1 0 0 0 1 1 Information element non-existent or not

implemented 0 1 1 0 0 1 0 0 Conditional IE error 0 1 1 0 0 1 0 1 Message not compatible with the protocol state 0 1 1 0 1 1 1 1 Protocol error, unspecified Any other value received by the mobile station shall be treated as 0010 0010, 'Service option temporarily out of order'. Any other value received by the network shall be treated as 0110 1111, 'Protocol error, unspecified'. NOTE: The listed reject cause values are defined in Annex G.

10.5.3.7 Follow-on Proceed

Follow-on Proceed IE の目的は、既存の RR コネクション上で MM コネクションを確立できることを通知することに

ある。

Follow-on Proceed IE は、図 10.5.82/TS 24.008 に示すようにエンコードされる。

Follow-on Proceed IE は type 2 IE である。

8 7 6 5 4 3 2 1 Follow-on Proceed IEI octet 1

図図図図 10.5.82/TS 24.008 Follow-on Proceed information element

10.5.3.8 Time Zone

本 IE の目的は、ユニバーサル時間とローカル時間とのオフセットを 15 分単位でエンコードすることにある。

Time Zone IE は、図 10.5.83/TS 24.008 および表 10.5.96/TS 24.008 に示すようにエンコードされる。

Time Zone IE は 2 オクテット長の type 3 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 326

8 7 6 5 4 3 2 1 Time Zone IEI octet 1

Time Zone octet 2

図図図図 10.5.83/TS 24.008 Time Zone information element

表表表表 10.5.96/TS 24.008 Time Zone information element

Time Zone (octet 2, bits 1-8) This field uses the same format as the Timezone field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42

10.5.3.9 Time Zone and Time

本 IE の timezone パートの目的は、ユニバーサル時間とローカル時間とのオフセットを 15 分単位でエンコードする

ことにある。

本 IE の time パートの目的は、本 IE をネットワークが送信したユニバーサル時間をエンコードすることにある。

Time Zone and Time IE は、図 10.5.84/TS 24.008 および表 10.5.97/TS 24.008 に示すようにエンコードされる。

Time Zone and Time IE は、8 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 Time Zone and Time IEI octet 1

Year octet 2

Month octet 3

Day octet 4

Hour octet 5

Minute octet 6

Second octet 7

Time zone octet 8

図図図図 10.5.84/TS 24.008 Time Zone and Time information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 327

表表表表 10.5.97/TS 24.008 Timezone and Time information element

Year (octet 2, bits 1-8) This field uses the same format as the Year field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42 Month (octet 3, bits 1-8) This field uses the same format as the Month field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42. Day (octet 4, bits 1-8) This field uses the same format as the Day field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42. Hour (octet 5, bits 1-8) This field uses the same format as the Hour field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42. Minute (octet 6, bits 1-8) This field uses the same format as the Minute field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42. Second (octet 7, bits 1-8) This field uses the same format as the Second field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42. Time Zone (octet 8, bits 1-8) This field uses the same format as the Time Zone field used in the TP-Service-Centre-Time-Stamp, which is defined in GSM 03.40, and its value shall be set as defined in GSM 02.42

NOTE: プロトコル仕様の以前のバージョンが曖昧だったので、MS によっては受信した NITZ 時刻をローカル

時刻として解釈する場合もある。これは MS 内の時間が不正に設定される原因となりうる。

10.5.3.10 CTS permission

CTS permission IE の目的は、LA 内で MS が GSM-Cordless Telephony System の使用を許可されていることを

通知することにある。CTS permission IE は、図 10.5.84a/TS 24.008 に示すようにエンコードされる。

CTS permission IE は type 2 IE である。

8 7 6 5 4 3 2 1 CTS Permission IEI octet 1

図図図図 10.5.84a/TS 24.008 CTS permission information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 328

10.5.3.11 LSA Identifier

本エレメントは、LSA をユニークに特定する。

LSA Identifier IE は、図 10.68c/TS 24.008 に示すようにエンコードされる。

LSA Identifier IE は、2 または 5 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 LSA Identifier IEI octet 1

Length of LSA Identifier contents octet 2

LSA ID octet 3

LSA ID cont. octet 4

LSA ID cont. octet 5

図図図図 10.68c/TS 24.008 LSA Identifier information element

Length = 0 ならば、LSA ID は含まれない。これは MS が利用可能な LSA がないエリアから外に移動したことを通

知するために使用される。

オクテット 3～5 は TS 23.003 内で規定されるように、'Identification of Localised Service Area'としてエンコードさ

れる。オクテット 3 のビット 8 が上位ビット（most significant bit）である。

10.5.3.12 Daylight Saving Time

本 IE の目的は、Daylight Saving Time（夏時間）を 1 時間単位でエンコードすることにある。

Daylight Saving Time IE は、図 10.5.84b/TS 24.008 および表 10.5.97a/TS 24.008 に示すようにエンコードされる。

Daylight Saving Time IE は、3 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Daylight Saving Time IEI octet 1

Length of Daylight Saving Time contents

octet 2

Spare value 0 0 0 0 0 0 octet 3

図図図図 10.5.84b/TS 24.008 Daylight Saving Time information element

表表表表 10.5.97a/TS 24.008: Daylight Saving Time information element

Daylight Saving Time value (octet 3) Bits 2 1 0 0 No adjustment for Daylight Saving Time 0 1 +1 hour adjustment for Daylight Saving Time 1 0 +2 hours adjustment for Daylight Saving Time 1 1 Reserved

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 329

10.5.4 Call control information elements

10.5.4.1 Extensions of codesets

取りうる IEI の値のうち幾つかは、セクション 10.5 で説明されるフォーマット規則を使用する。すなわち、type 3 & 4 の IE フォーマットからは 128 が、type 1 & 2 の IE フォーマットからは低 8 つである。

下記に説明されるシフトオペレーション用に、type 1 フォーマット中 1 つの値が仕様化されている。type 3 & 4 と

type 1 フォーマットの両方で、もう 1 つ別の値が reserve されている。IEI の値として割当て可能な値は、133 残され

ている。

133 の IEI の値それぞれの 8 つのコードセットに対して、本構造を拡張することは可能である。あるコードセットから

別のコードセットにシフトすることを容易にするために、type 1 フォーマット内の 1 つの共通の値を各コードセットに採

用する。本 shift IE のコンテンツは、次の IE またはエレメント用に使用されるコードセットを特定する。特定の時刻

に使用中のコードセットを「アクティブコードセット」（"active codeset"）と呼ぶ。慣例により、コードセット 0 は初にア

クティブなコードセットである。

2 つのコードセットシフト処理がサポートされる。すなわち、ロックシフトと非ロックシフトである。

コードセット 5 は、国内用に reserve された IE 用に reserve されている。

コードセット 6 は、（パブリックまたはプライベート）ローカルネットワーク固有の IE 用に reserve されている。

コードセット 7 は、特定ユーザ用 IE 用に reserve されている。

セクション 10.5 に規定されるコーディング規則は、任意のアクティブなコードセットに属する IE に対して適用されるこ

と。

ある 1 つのアクティブなコードセットから他のコードセットへの遷移（つまりロックシフト処理を使用して）は、遷移前の

コードセットの絶対値よりも遷移後の絶対値が高い場合のみ、可能である。

非ロックシフト処理を使用することによって、コードセット 5,6,7 に属する IE がコードセット 0 に属する IE といっしょに

使うことも可能である（セクション 10.5.4.3 参照）。

ユーザ端末またはネットワーク端末は、shift IE を識別子、その後に続く IE の長さを特定するケーパビリティを持つこ

と。ただし、これらの端末が IE のコンテンツを解釈してアクションを取れる必要はない。そうすることによって、端末は

後続の IE の開始を決定することができるようになる。

10.5.4.2 Locking shift procedure

ロックシフト処理は、新しいアクティブなコードセットを示すために IE を使用する。他のコードセットの使用を指定する

別のロックシフト IE に遭遇するまで、指定されたコードセットはアクティブである。例えば、コードセット 0 はメッセージ

コンテンツ解析の開始時点においてアクティブである。コードセット 5 へのロックシフトに遭遇した場合、次の IE は別

の shift IE に遭遇するまで、コードセット 5 中で割り当てられた IEI に従って解釈される。本処理は、シフト前の順序

コードセットよりシフト後のコードセットの方が高い場合のみ、使用される。ロックシフトは、locking shift IE を含む該

当メッセージ内でのみ有効である。各メッセージコンテンツ解析の開始時点では、アクティブなコードセットはコードセ

ット 0 である。

locking shift IE は type 1 IE フォーマットを使用し、図 10.5.85/TS 24.008 および表 10.5.98/TS 24.008 に示される

ようにコーディングされる。

8 7 6 5 4 3 2 1

Shift identifier 0 New codeset

identification octet 1

"0" in this position indicates locking shift

図図図図 10.5.85/TS 24.008 Locking shift element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 330

表表表表 10.5.98/TS 24.008: Locking shift element

Codeset identification (octet 1): Bits 3 2 1 0 0 0 not applicable 0 0 1 } To } reserved 1 0 0 } 1 0 1 codeset 5: information elements for national use 1 1 0 codeset 6: information elements specific to the local network

(either public or private) 1 1 1 codeset 7: user-specific information elements

10.5.4.3 Non-locking shift procedure

非ロックシフト処理は、指定されたコードセットよりも低い／高いコードセットに一時的なシフトを提供する。非ロックシ

フト処理は、次の IE を解釈するために使用されるコードセットを示すために type 1 IE を使用する。次の IE を解釈し

た後に、アクティブなコードセットを再び使用して、後続 IE を解釈する。例えば、コードセット 0 はメッセージコンテン

ツ解析の開始時点でアクティブである。コードセット 6 への非ロックシフトに遭遇した場合、次の IE だけがコードセッ

ト 6 の中で割り当てられた IEI に従って解釈される。この IE が解釈された後、後続 IE を解釈するためにコードセット

0 が再び使用される。現在のコードセットを示す非ロックシフト IE を、エラーと見なしてはならない。

locking shift IE は、non-locking shift IE の直後に続いてはならない。もし non-locking shift IE の直後に locking shift IE を受信した場合、locking shift IE を受信した場合と同様に解釈すること。

non-locking shift IE は type 1 information format を使用し、図 10.5.86/TS 24.008 および表 10.5.99/TS 24.008に示されるようにコーディングされる。

8 7 6 5 4 3 2 1

Shift identifier 1 Temporary codeset

identification octet 1

"1" in this position indicates non-locking shift

図図図図 10.5.86/TS 24.008 Non-locking shift element

表表表表 10.5.99/TS 24.008: Non-locking shift element

Codeset identification (octet 1): Bits 3 2 1 0 0 0 codeset 0 (initially active):

GSM 24.008 information elements 0 0 1 } to } reserved 1 0 0 } 1 0 1 codeset 5: information elements for national use 1 1 0 codeset 6: information elements specific to the local network

(either public or private) 1 1 1 codeset 7: user-specific information elements

10.5.4.4 Auxiliary states

auxiliary states IE の目的は、呼制御ステート"active" および"mobile originating modify"にある呼の現在の補助ス

テートを説明するために使用される（TS 24.083 および 04.84 参照）。

auxiliary states IE は、図 10.5.87/TS 24.008、表 10.5.100/TS 24.008 および表 10.5.101/TS 24.008 に示される

ようにエンコードされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 331

補助ステートは 3 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Auxiliary states IEI octet 1

Length of auxiliary states contents

octet 2

1 0 0 0 hold aux. MPTY aux. ext Spare state state octet 3

図図図図 10.5.87/TS 24.008 Auxiliary states information element

表表表表 10.5.100/TS 24.008: Auxiliary states information element

Hold auxiliary state (octet 3) Bits 4 3 0 0 idle Note 1 0 1 hold request Note 1 1 0 call held Note 1 1 1 retrieve request Note 1 Note 1: These states are defined in Rec GSM 04.83.

表表表表 10.5.101/TS 24.008: Auxiliary states information element

Multi party auxiliary state (octet 3) Bits 2 1 0 0 idle Note 2 0 1 MPTY request Note 2 1 0 call in MPTY Note 2 1 1 split request Note 2 Note 2: These states are defined in Rec GSM 04.84.

10.5.4.5 Bearer capability

bearer capability IE の目的は、ベアラサービスを説明することにある。互換性チェックとの関係における bearer capability IE の使用については、annex B で説明する。

bearer capability IE は、図 10.5.88/TS 24.008 、表 10.5.102/TS 24.008 ～ 10.5.115/TS 24.008 に示されるよう


bearer capability IE は少長 3 オクテット、大長 16 オクテットの type 4 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 332

8 7 6 5 4 3 2 1 Bearer capability IEI octet 1

Length of the bearer capability contents

octet 2

0/1 ext

radio channel

requirement

coding std

trans fer

mode

information transfer

capability

octet 3

0/1 0 0 0 ext co-

ding spare speech version

indication octet 3a etc*

1 ext

comp-ress.

structure

dupl. mode

configur.

NIRR esta-bli.

octet 4*

0/1 0 0 rate Signalling ext access id. adaption access protocol octet 5* 0/1 Other rate 0 0 0 ext Other ITC adaption Spare octet 5a* 1

ext Hdr/

noHdrMulti frame

Mode LLI Assignor/e

Inb. neg

0 Spare

octet 5b*

0/1 0 1 User information sync/ ext layer 1 id. layer 1 protocol Async octet 6* 0/1 ext

numb.stop bits

nego- tia- tion

numb.data bits

user rate

octet 6a*

0/1 ext

intermed. rate

NIC on TX

NIC on RX

Parity

octet 6b*

0/1 ext

connection element

modem type

octet 6c*

0/1 ext

Other modem type

Fixed network user rate

octet 6d*

0/1 ext

Acceptable channel codings

Maximum number of traffic channels

octet 6e*

0/1 ext

UIMI Wanted air interface user rate

octet 6f*

1 ext

Acceptable channel codings

Asymmetry

0 0

extended Indication Spare octet 6g* 1 1 0 User information

ext layer 2 id. layer 2 protocol octet 7*

図図図図 10.5.88/TS 24.008 Bearer capability information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 333

NOTEs: bearer capability IE のオクテットのコーディングは、ITU Q.931 に適合しない。

MS は、GSM 呼制御要求条件に従って bearer capability IE をエンコードすること。また、UMTS サー

ビスについて要求されたならば同様にエンコードすること。

UTRAN アクセスについては、以下のパラメータは不適切である。なぜならば、マルチトラフィックチャネ

ル（マルチスロット）は実施されない[TS 23.034]からである。しかし、マルチスロットパラメータは MSC内に保存し、ハンドオーバ時に転送すること。 - トラフィックチャネルの大数（オクテット 6e、ビット 1～3） - 許容できるチャネルコーディング（オクテット 6e、ビット 4,5,7） - UIMI（User initiated modification indication）（オクテット 6f、ビット 5～7） - 許容できるチャネルコード拡張（オクテット 6g、ビット 5～7） GSM をサポートしない MS は、これらのパラメータを値"0"に設定すること。

表表表表 10.5.102/TS 24.008: Bearer capability information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 334

Radio channel requirement (octet 3), network to MS direction In GSM, i.e. not applicable for UMTS data services. Bits 6 and 7 are spare bits. The sending side (i.e. the network) shall set bit 7 to value 0 and bit 6 to value 1. Radio channel requirement (octet 3) MS to network direction When information transfer capability (octet 3) indicates other values than speech: Bits 7 6 0 0 reserved 0 1 full rate support only MS 1 0 dual rate support MS/half rate preferred 1 1 dual rate support MS/full rate preferred When information transfer capability (octet 3) indicates the value speech and no speech version indication is present in octet 3a etc.: Bits 7 6 0 0 reserved 0 1 full rate support only MS/fullrate speech version 1 supported

1 0 dual rate support MS/half rate speech version 1 preferred, full rate speech version 1 also supported

1 1 dual rate support MS/full rate speech version 1 preferred, half rate speech version 1 also supported

When information transfer capability (octet 3) indicates the value speech and speech version indication(s) is(are) present in octet 3a etc.: Bits 7 6 0 0 reserved

0 1 the mobile station supports at least full rate speech version 1 but does not support half rate speech version 1. The complete voice codec preference is specified in octet(s) 3a etc.

1 0 The mobile station supports at least full rate speech version 1 and half rate speech version 1. The mobile station has a greater preference for half rate speech version 1 than for full rate speech version 1. The complete voice codec preference is specified in octet(s) 3a etc.

1 1 The mobile station supports at least full rate speech version 1 and half rate speech version 1. The mobile station has a greater preference for full rate speech version 1 than for half rate speech version 1. The complete voice codec preference is specified in octet(s) 3a etc.

(continued...)

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 335

表表表表 10.5.102/TS 24.008: Bearer capability information element (continued)

Coding standard (octet 3) Bit 5 0 GSM standardized coding as described below 1 reserved Transfer mode (octet 3) Bit 4 0 circuit mode 1 packet mode Information transfer capability (octet 3) Bits 3 2 1 0 0 0 speech 0 0 1 unrestricted digital information 0 1 0 3.1 kHz audio, ex PLMN 0 1 1 facsimile group 3 1 0 1 Other ITC (See Octet 5a) 1 1 1 reserved, to be used in the network. The meaning is: alternate speech/facsimile group 3 - starting with speech. All other values are reserved

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 336

表表表表 10.5.103/TS 24.008 Bearer capability information element

Octet(s) 3a etc. MS to network direction Octet(s) 3a etc. shall only be used to convey speech coding information belonging to a GSM Radio Access. When included for a UMTS call establishment they shall be used for handover to a GSM Radio Acess. Coding Bit 7 0 octet used for extension of information transfer capability 1 octet used for other extension of octet 3 When information transfer capability (octet 3) indicates speech and coding (bit 7 in octet 3a etc.) is coded as 0, bits 1 through 6 are coded: Bits 5 and 6 are spare. Speech version indication (octet(s) 3a etc.) Bits 4 3 2 1 0 0 0 0 GSM full rate speech version 1 0 0 1 0 GSM full rate speech version 2 0 1 0 0GSM full rate speech version 3 0 0 0 1 GSM half rate speech version 1 0 1 0 1GSM half rate speech version 3 All other values have the meaning "speech version tbd" and shall be ignored when received. If octet 3 is extended with speech version indication(s) (octets 3a etc.), all speech versions supported shall be indicated and be included in order of preference (the first octet (3a) has the highest preference and so on). If information transfer capability (octet 3) indicates speech and coding (bit 7 in octet 3a etc.) is coded as 1, or the information transfer capability does not indicate speech, then the extension octet shall be ignored. Octet(s) 3a etc. network to MS direction The octet(s) 3a etc. shall be ignored by the MS.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 337


Compression (octet 4), network to MS direction: Bit 7 0 data compression not possible 1 data compression possible Compression (octet 4), MS to network direction: Bit 7 0 data compression not allowed 1 data compression allowed Structure (octet 4) Bits 6 5 0 0 service data unit integrity 1 1 unstructured All other values are reserved. Duplex mode (octet 4) Bit 4 0 half duplex 1 full duplex Configuration (octet 4) Bit 3 0 point-to-point All other values are reserved. NIRR (octet 4) (Negotiation of Intermediate Rate Requested) In GSM, i.e. not applicable for UMTS data services. Bit 2 0 No meaning is associated with this value. 1 Data up to and including 4.8 kb/s, full rate, non-transparent, 6 kb/s radio interface rate is requested. Establishment (octet 4) Bit 1 0 demand All other values are reserved

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 338


Access identity (octet 5) Bits 7 6 0 0 octet identifier All other values are reserved Rate adaption (octet 5) Bits 5 4 0 0 no rate adaption 0 1 V.110, I.460/X.30 rate adaptation 1 0 ITU-T X.31 flag stuffing 1 1 Other rate adaption (see octet 5a) Signalling access protocol (octet 5) Bits 3 2 1 0 0 1 I.440/450 0 1 0 X.21 0 1 1 reserved: was allocated in earlier phases of the protocol 1 0 0 reserved: was allocated in earlier phases of the protocol. 1 0 1 X.28 - non dedicated PAD 1 1 0 X.32 All other values are reserved.


Other ITC (octet 5a) If the value "Other ITC" is not signalled in the field "ITC" then the contents of this field shall be ignored. Bit 7 6 0 0 restricted digital information All other values are reserved Other rate adaption (octet 5a) If the value " Other rate adaption" is not signalled in the field "Rate adaption" then the contents of this field shall be ignored. In UMTS, PIAFS shall be considered. In GSM, call shall be rejected if PIAFS requested. Bit 5 4 0 0 V.120 0 1 H.223 & H.245 1 0 PIAFS All other values are reserved.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 339


Rate adaption header/no header (octet 5b) Bit 7 0 Rate adaption header not included 1 Rate adaption header included Multiple frame establishment support in data link (octet 5b) Bit 6 0 Multiple frame establishment not supported, only UI frames allowed 1 Multiple frame establishment supported Mode of operation (octet 5b) Bit 5 0 Bit transparent mode of operation 1 Protocol sensitive mode of operation Logical link identifier negotiation (octet 5b) Bit 4 0 Default, LLI=256 only 1 Full protocol negotiation, (note: A connection over which protocol negotiation will be executed is indicated in bit 2 of octet 5b) Assignor/Assignee (octet 5b) Bit 3 0 Message originator is "default assignee" 1 Message originator is "assignor only" In band/Out of band negotiation (octet 5b) Bit 2 0 Negotiation is done in-band using logical link zero 1 Negotiation is done with USER INFORMATION messages on a temporary signalling connection Bit 1 is spare and set to the value "0"

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 340


Layer 1 identity (octet 6) Bits 7 6 0 1 octet identifier All other values are reserved User information layer 1 protocol (octet 6) Bits 5 4 3 2 0 0 0 0 default layer 1 protocol All other values reserved. Synchronous/asynchronous (octet 6) Bit 1 0 synchronous 1 asynchronous


Number of Stop Bits (octet 6a) Bit 7 0 1 bit (This value is also used in the case of synchronous mode) 1 2 bits Negotiation (octet 6a) Bit 6 0 in-band negotiation not possible NOTE: See Rec. V.110 and X.30 All other values are reserved Number of data bits excluding parity bit if present (octet 6a) Bit 5 0 7 bits 1 8 bits (this value is also used in the case of bit oriented protocols) User rate (octet 6a) In GSM only. Bits 4 3 2 1 0 0 0 1 0.3 kbit/s Recommendation X.1 and V.110 0 0 1 0 1.2 kbit/s Recommendation X.1 and V.110 0 0 1 1 2.4 kbit/s Recommendation X.1 and V.110 0 1 0 0 4.8 kbit/s Recommendation X.1 and V.110 0 1 0 1 9.6 kbit/s Recommendation X.1 and V.110 0 1 1 0 12.0 kbit/s transparent (non compliance with X.1 and V.110) 0 1 1 1 reserved: was allocated in earlier phases of the protocol. All other values are reserved. For facsimile group 3 calls the user rate indicates the first and maximum speed the mobile station is using.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 341


Octet 6b for V.110/X.30 rate adaptation Intermediate rate (octet 6b) In GSM only. Bits 7 6 0 0 reserved 0 1 reserved 1 0 8 kbit/s 1 1 16 kbit/s Network independent clock (NIC) on transmission (Tx) (octet 6b) (See Rec. V.110 and X.30). in GSM only. Bit 5 0 does not require to send data with network independent clock 1 requires to send data with network independent clock Network independent clock (NIC) on reception (Rx) (octet 6b) (See Rec. V.110 and X.30) In GSM only. Bit 4 0 cannot accept data with network independent clock (i.e. sender does not support this optional procedure) 1 can accept data with network independent clock (i.e. sender does support this optional procedure) Parity information (octet 6b) Bits 3 2 1 0 0 0 odd 0 1 0 even 0 1 1 none 1 0 0 forced to 0 1 0 1 forced to 1 All other values are reserved.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 342


Connection element (octet 6c) Bit 7 6 0 0 transparent 0 1 non transparent (RLP) 1 0 both, transparent preferred 1 1 both, non transparent preferred The requesting end (e.g. the one sending the SETUP message) should use the 4 values depending on its capabilities to support the different modes. The answering party shall only use the codings 00 or 01, based on its own capabilities and the proposed choice if any. If both MS and network support both transparent and non transparent, priority should be given to the MS preference. Modem type (octet 6c) Bits 5 4 3 2 1 0 0 0 0 0 none 0 0 0 0 1 V.21 (note 1) 0 0 0 1 0 V.22 (note 1) 0 0 0 1 1 V.22 bis (note 1) 0 0 1 0 0 reserved: was allocated in earlier phases of the protocol 0 0 1 0 1 V.26 ter (note 1) 0 0 1 1 0 V.32 0 0 1 1 1 modem for undefined interface 0 1 0 0 0 autobauding type 1 All other values are reserved. Note 1: In GSM only.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 343


Other modem type (octet 6d) Bits 7 6 0 0 no other modem type specified in this field 1 0 V.34 All other values are reserved. Fixed network user rate (octet 6d) Bit 5 4 3 2 1 0 0 0 0 0 Fixed network user rate not applicable/No meaning is associated with this value. 0 0 0 0 1 9.6 kbit/s Recommendation X.1 and V.110 0 0 0 1 0 14.4 kbit/s Recommendation X.1 and V.110 0 0 0 1 1 19.2 kbit/s Recommendation X.1 and V.110 0 0 1 0 0 28.8 kbit/s Recommendation X.1 and V.110 0 0 1 0 1 38.4 kbit/s Recommendation X.1 and V.110 0 0 1 1 0 48.0 kbit/s Recommendation X.1 and V.110(synch) (note 1) 0 0 1 1 1 56.0 kbit/s Recommendation X.1 and V.110(synch) /bit transparent 0 1 0 0 0 64.0 kbit/s bit transparent 0 1 0 0 1 33.6 kbit/s bit transparent (note 2) 0 1 0 1 0 32.0 kbit/s Recommendation I.460 (note 2) 0 1 0 1 1 31.2 kbit/s Recommendation V.34 (note 2) The value 31.2 kbit/s Recommendation V.34 shall be used only by the network to inform the MS about FNUR modification due to negotiation between the modems in a 3.1 kHz multimedia call. All other values are reserved. Note 1: In GSM only. Note 2: In UMTS only

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 344


Acceptable channel codings (octet 6e), MS→Network Direction: Bit 7 0 TCH/F14.4 not acceptable 1 TCH/F14.4 acceptable Bit 6 0 Spare Bit 5 0 TCH/F9.6 not acceptable 1 TCH/F9.6 acceptable Bit 4 0 TCH/F4.8 not acceptable 1 TCH/F4.8 acceptable Acceptable channel codings (octet 6e), network to MS direction: Bits 4 to 7 are spare and shall be set to "0". Maximum number of traffic channels (octet 6e), MS to network direction: Bits 3 2 1 0 0 0 1 TCH 0 0 1 2 TCH 0 1 0 3 TCH 0 1 1 4 TCH 1 0 0 5 TCH 1 0 1 6 TCH 1 1 0 7 TCH 1 1 1 8 TCH Maximum number of traffic channels (octet 6e), network to MS direction: Bits 1 to 3 are spare and shall be set to "0".

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 345


UIMI, User initiated modification indication (octet 6f), 7 6 5 0 0 0 User initiated modification not allowed/required/applicable 0 0 1 User initiated modification up to 1 TCH/F allowed/may be requested 0 1 0 User initiated modification up to 2 TCH/F allowed/may be requested 0 1 1 User initiated modification up to 3 TCH/F allowed/may be requested 1 0 0 User initiated modification up to 4 TCH/F allowed/may be requested All other values shall be interpreted as "User initiated modification up to 4 TCH/F may be requested". User initiated modification indication is not applicable for transparent connection. Wanted air interface user rate (octet 6f), MS to network direction: Bits 4 3 2 1 0 0 0 0 Air interface user rate not applicable/No meaning associated with this value 0 0 0 1 9.6 kbit/s 0 0 1 0 14.4 kbit/s 0 0 1 1 19.2 kbit/s 0 1 0 1 28.8 kbit/s 0 1 1 0 38.4 kbit/s 0 1 1 1 43.2 kbit/s 1 0 0 0 57.6 kbit/s 1 0 0 1 interpreted by the network as 38.4 kbit/s in this version of the protocol 1 0 1 0 interpreted by the network as 38.4 kbit/s in this version of the protocol 1 0 1 1 interpreted by the network as 38.4 kbit/s in this version of the protocol 1 1 0 0 interpreted by the network as 38.4 kbit/s in this version of the protocol All other values are reserved. Wanted air interface user rate (octet 6f), network to MS direction: Bits 1 to 4 are spare and shall be set to "0".

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 346


Layer 2 identity (octet 7) Bits 7 6 1 0 octet identifier All other values are reserved User information layer 2 protocol (octet 7) Bits 5 4 3 2 1 0 0 1 1 0 recommendation X.25, link level 0 1 0 0 0 ISO 6429, codeset 0 (DC1/DC3) 0 1 0 0 1 reserved: was allocated but never used in earlier phases of the protocol 0 1 0 1 0 videotex profile 1 0 1 1 0 0 COPnoFlCt (Character oriented Protocol with no Flow Control mechanism) 0 1 1 0 1 X.75 layer 2 modified (CAPI) All other values are reserved.

表表表表 10.5.115a/TS 24.008: Bearer capability information element

Acceptable Channel Codings extended (octet 6g) MS→Network direction: Bit 7 0 TCH/F28.8 not acceptable 1 TCH/F28.8 acceptable Bit 6 0 TCH/F32.0 not acceptable 1 TCH/F32.0 acceptable Bit 5 0 TCH/F43.2 not acceptable 1 TCH/F43.2 acceptable Channel Coding Asymmetry Indication Bits 4 3 0 0 Channel coding symmetry preferred 1 0 Downlink biased channel coding asymmetry is preferred 0 1 Uplink biased channel coding asymmetry is preferred 1 1 Unused, if received it shall be interpreted as "Channel coding symmetry preferred" EDGE Channel Codings (octet 6g), network to MS direction: Bits 3 to 7 are spare and shall be set to "0". Bits 2 and 1 are spare.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 347

10.5.4.5.1 Static conditions for the bearer capability IE contents

GSM の場合、information transfer capability フィールド（オクテット 3）が"speech"を示していたならば、オクテット 4, 5, 5a, 5b, 6, 6a, 6b, 6c, 6d, 6e, 6f, 6g および 7 が含まれてはならない。

information transfer capability フィールド（オクテット 3）が"speech"を示していたならば、オクテット 3a などは、MSが下記の音声バージョン以外に低 1 つの音声バージョンをサポートしている場合に限り含まれる。

- GSM フルレートバージョン 1、または

- GSM ハーフレートバージョン 1

information transfer capability フィールド(オクテット 3)が"speech"以外の値を示していた場合、オクテット 4, 5, 6, 6a, 6b, および 6c は必ず含まれること。オクテット 6d、6e、6f および 6g はオプションである。ネットワーク→MS の

方向で、オクテット 6d が含まれている場合には、オクテット 6e が必ず含まれること。6f および 6g はどちらでもよい。 MS->NW の場合 6d が含まれる場合、6e は必ず含まれる。6f と 6g はどちらでも良い。

information transfer capability フィールド(オクテット 3)が"facsimile group 3"を示していた場合には、modem type フィールド(オクテット 6c)は、"none"であること。

information transfer capability フィールド(オクテット 3)が"other ITC"を示していた場合、または rate adaption フィ

ールド(オクテット 5)が"other rate adaption"を示していた場合には、オクテット 5a が含まれること。

rate adaption フィールド(オクテット 5)が"other rate adaption"を示しており、かつ other rate adaption フィールド

(オクテット 5a)が"V.120"を示している場合には、オクテット 5b が含まれること。

modem type フィールド（オクテット 6c）は、connection element フィールド(オクテット 6c)が"non transparent"を示

している場合を除いて、"autobauding type 1"を示してはならない。

10.5.4.5a Call Control Capabilities

Call Control Capabilities IE の目的は、MS の呼制御ケーパビリティを特定することにある。

Call Control Capabilities IE は、図 10.5.89/TS 24.008 および表 10.5.116/TS 24.008 に示されるようにエンコード

される。

Call Control Capabilities IE は 4 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Call Control Capabilities IEI octet 1

Length of Call Control Capabilities contents

octet 2

Maximum number of 0 0 supported bearers Spare PCP DTMF octet 3

0 0 0 0 Maximum number of spare speech bearers octet 4

図図図図 10.5.89/TS 24.008 Call Control Capabilities information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 348

表表表表 10.5.116/TS 24.008: Call Control Capabilities

DTMF (octet 3, bit 1) 0 This value is reserved for earlier versions of the protocol. 1 This value indicates that the mobile station supports DTMF as specified

in section 5.5.7 of this specification. PCP (octet 3, bit 2) 0 This value indicates that the mobile station does not support the

Prolonged Clearing Procedure 1 This value indicates that the mobile station supports the Prolonged

Clearing Procedure. Maximum number of supported bearers (octet 3, bit 5 to bit 8) 0 0 0 0 1 bearer supported All values are interpreted as the binary representation of the number of bearers supported. Bit 5 of octet 3 is the least significant bit and bit 8 of octet 3 is the most significant bit. Maximum number of speech bearers (octet 4, bit 1 to bit 4) All values are interpreted as the binary representation of the number of bearers supported. Bit 1 of octet 4 is the least significant bit and bit 4 of octet 4 is the most significant bit. Note: In this version of the protocol, the MS should not indicate more than one

speech bearer.

10.5.4.6 Call state

call state IE の目的は、呼の現在のステートを説明することである（セクション 5.1 参照）。

call state IE は、図 10.5.90/TS 24.008 および表 10.5.117/TS 24.008 に示されるようにエンコードされる。

call state IE は 2 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 call state IEI octet 1 coding

standard

call state value (coded in binary) octet 2

図図図図 10.5.90/TS 24.008 Call state information element

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 349

表表表表 10.5.117/TS 24.008: Call state information element

Coding standard (octet 2) Bits 8 7 0 0 standardized coding as described in ITU-T Rec. Q.931 0 1 reserved for other international standards 1 0 national standard 1 1 standard defined for the GSM PLMNS as described below Coding standards other than "1 1 - Standard defined for the GSM PLMNS" shall not be used if the call state can be represented with the GSM standardized coding. The mobile station or network need not support any other coding standard than "1 1 - Standard defined for the GSM PLMNS". If a call state IE indicating a coding standard not supported by the receiver is received, call state "active" shall be assumed. Call state value (octet 2) Bits 6 5 4 3 2 1 0 0 0 0 0 0 UO – null NO - null 0 0 0 0 1 0 U0.1- MM connection pending N0.1- MM connection pending 1 0 0 0 1 0 U0.2- CC prompt present N0.2- CC connection pending 1 0 0 0 1 1 U0.3- Wait for network

information N0.3- Network answer pending

1 0 0 1 0 0 U0.4- CC-Establishment present

N0.4- CC-Establishment present

1 0 0 1 0 1 U0.5- CC-Establishment confirmed

N0.5- CC-Establishment confirmed

1 0 0 1 1 0 U0.6- Recall present N0.6- Recall present 0 0 0 0 0 1 U1 - call initiated N1 - call initiated 0 0 0 0 1 1 U3 - mobile originating call

proceeding N3 - mobile originating call proceeding

0 0 0 1 0 0 U4 - call delivered N4 - call delivered 0 0 0 1 1 0 U6 - call present N6 - call present 0 0 0 1 1 1 U7 - call received N7 - call received 0 0 1 0 0 0 U8 - connect request N8 - connect request 0 0 1 0 0 1 U9 - mobile terminating call

confirmed N9 - mobile terminating call confirmed

0 0 1 0 1 0 U10- active N10- active 0 0 1 0 1 1 U11- disconnect request 0 0 1 1 0 0 U12- disconnect indication N12-disconnect indication 0 1 0 0 1 1 U19- release request N19- release request 0 1 1 0 1 0 U26- mobile originating modify N26- mobile originating modify 0 1 1 0 1 1 U27- mobile terminating

modify N27- mobile terminating modify

0 1 1 1 0 0 N28- connect indication

10.5.4.7 Called party BCD number

called party BCD number IE の目的は、着呼パーティを特定することにある。

called party BCD number IE は、図 10.5.91/TS 24.008 および表 10.5.118/TS 24.008 に示されるようにエンコー

ドされる。

called party BCD number IE は、少長 3 オクテット、大長 43 オクテットの type 4 IE である。PCS 1900 の場

合、大長は 19 オクテットである。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 350

8 7 6 5 4 3 2 1 Called party BCD number IEI octet 1

Length of called party BCD number contents

octet 2

1 ext

type of number

Numbering plan identification

octet 3

Number digit 2

Number digit 1

octet 4*

Number digit 4

Number digit 3

octet 5*

: 2) :

図図図図 10.5.91/TS 24.008 Called party BCD number information element

NOTE 1: オクテット 4 内の number digit は、オクテット 5 などの number digit よりも前にくる。初に入力される

number digit は、オクテット 4 のビット 1～4 に置くこと。

NOTE 2: called party BCD number に奇数の桁番号が含まれる場合には、後のオクテットのビット 5～8 を

"1111"にエンコードされたエンドマークでうめること。

IE には complete called party BCD number が含まれるので、追加的 complete 通知の必要はない。

表表表表 10.5.118/TS 24.008: Called party BCD number

Type of number (octet 3) (Note 1) Bits 7 6 5 0 0 0 unknown (Note 2) 0 0 1 international number (Note 3, Note 5) 0 1 0 national number (Note 3) 0 1 1 network specific number (Note 4) 1 0 0 dedicated access, short code 1 0 1 Reserved 1 1 0 Reserved 1 1 1 reserved for extension

NOTE 1: "number"の定義については、ITU-T Recommendation I.330 および TS 23.003 参照。

NOTE 2: 国際番号や国番号などの type of number の知識をユーザもしくはネットワークが持たない場合に、

type of number "unknown"が使用される。number digit フィールドはネットワークダイヤリングプラン

に従って構成される。例えば prefix または escape digit が存在してもよい。

NOTE 3: prefix または escape digit が含まれてはならない。

NOTE 4: サービスネットワークに固有の管理用／サービス番号を通知するために、type of number "network specific number"が使用される。

NOTE 5: 呼の宛先が MSC と同一国である場合には、MSC によって international format が受理されること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 351

表表表表 10.5.118/TS 24.008: Called party BCD number (continued)

Numbering plan identification (octet 3) Number plan (applies for type of number = 000, 001, 010 and 100) Bits 4 3 2 1 0 0 0 0 Unknown 0 0 0 1 ISDN/telephony numbering plan (Rec. E.164/E.163) 0 0 1 1 data numbering plan (Recommendation X.121) 0 1 0 0 telex numbering plan (Recommendation F.69) 1 0 0 0 national numbering plan 1 0 0 1 private numbering plan 1 0 1 1 reserved for CTS (see GSM 04.56) 1 1 1 1 reserved for extension All other values are reserved.

MS がネットワークから番号情報を受信する場合、number digit と number plan identification の間の

非互換性は全て無視すること。また、STATUS メッセージをネットワークに送信してはならない。

numbering plan "unknown"の場合には、number digit フィールドはネットワークダイヤリングプランに

従って構成される。例えば prefix または escape digit が存在してもよい。

表表表表 10.5.118/TS 24.008: Called party BCD number (continued)

Number digits (octets 4, etc.) Bits Number digit value 4 3 2 1 or 8 7 6 5 0 0 0 0 0 0 0 0 1 1 0 0 1 0 2 0 0 1 1 3 0 1 0 0 4 0 1 0 1 5 0 1 1 0 6 0 1 1 1 7 1 0 0 0 8 1 0 0 1 9 1 0 1 0 * 1 0 1 1 # 1 1 0 0 A 1 1 0 1 B 1 1 1 0 C 1 1 1 1 used as an endmark in the case of an odd number of

number digits

10.5.4.8 Called party subaddress

Called party subaddress IE の目的は、呼の着信パーティのサブアドレスを特定することにある。サブアドレスの定

義については、Rec. ITU-T I.330 参照。

Called party subaddress IE は、図 10.5.92/TS 24.008 および表 10.5.119/TS 24.008 に示すようにエンコードされ

る。

Called party subaddress IE は、少長 2 オクテット、大長 23 オクテットの type 4 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 352

8 7 6 5 4 3 2 1 Called party Subaddress IEI octet 1

Length of called party subaddress contents

octet 2

1 type of odd/ev 0 0 0 ext Subaddress Indica Spare octet 3*

Subaddress information octet 4*

: : etc.

図図図図 10.5.92/TS 24.008 Called party subaddress

表表表表 10.5.119/TS 24.008: Called party subaddress

Type of subaddress (octet 3) Bits 7 6 5 0 0 0 NSAP (X.213/ISO 8348 AD2) 0 1 0 User specified All other values are reserved Odd/even indicator (octet 3) Bit 4 0 even number of address signals 1 odd number of address signals NOTE: The odd/even indicator is used when the type of subaddress is "user

specified" and the coding is BCD. Subaddress information (octet 4, etc...) The NSAP X.213/ISO8348AD2 address shall be formatted as specified by octet 4 which contains the Authority and Format Identifier (AFI). The encoding is made according to the "preferred binary encoding" as defined in X.213/ISO8348AD2. For the definition of this type of subaddress, see Rec. ITU-T I.334. A coding example is given in ANNEX A. For User-specific subaddress, this field is encoded according to the user specification, subject to a maximum length of 20 octets. When interworking with X.25 networks BCD coding should be applied. NOTE: It is recommended that users apply NSAP subaddress type since this

subaddress type allows the use of decimal, binary and IA5 characters in a standardised manner.

10.5.4.9 Calling party BCD number

calling party BCD number IE の目的は、呼の発信元を特定することにある。

calling party BCD number IE は、図 10.5.93/TS 24.008 および表 10.5.120/TS 24.008 に示すようにエンコードさ

れる。

calling party BCD number IE は type 4 の IE である。ネットワーク→MS 方向での少長は 3 オクテット、大長は

14 オクテットである（本 IE は MS→ネットワーク方向では使用されない）。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 353

8 7 6 5 4 3 2 1 Calling party BCD number IEI octet 1

Length of calling party BCD number contents

octet 2

0/1 ext

type of number

Numbering plan identification

octet 3

1 presentat. 0 0 0 screening ext indicator spare indicator octet 3a*

Number digit 2

Number digit 1

octet 4*

Number digit 4

Number digit 3

octet 5*

: :

図図図図 10.5.93/TS 24.008 Calling party BCD number information element

オクテット 3,4 などのコンテンツは表 10.5.118 に示すようにエンコードされる。オクテット 3a のコーディングは下表

10.5.120 に定義される。

calling party BCD number IE が奇数桁の場合、終オクテットのビット 5～8 は"1111"としてエンドマークコードされ

て充填されること。

表表表表 10.5.120/TS 24.008: Calling party BCD number

Presentation indicator (octet 3a) Bits 7 6 0 0 Presentation allowed 0 1 Presentation restricted 1 0 Number not available due to interworking 1 1 Reserved If octet 3a is omitted the value "00 - Presentation allowed" is assumed. Screening indicator (octet 3a) Bits 2 1 0 0 User-provided, not screened 0 1 User-provided, verified and passed 1 0 User-provided, verified and failed 1 1 Network provided If octet 3a is omitted the value "0 0 - User provided, not screened" is assumed.

10.5.4.10 Calling party subaddress

Calling party subaddress の目的は、呼の発信元のサブアドレスを特定することにある。サブアドレスの定義につい

ては、Rec. ITU-T I.330 参照。

Calling party subaddress information IE は、図 0.5.94/TS 24.008 および表 10.5.121/TS 24.008 に示すようにエ


Calling party subaddress information IE は、少長 2 オクテット、大長 23 オクテットの type 4 の IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 354

8 7 6 5 4 3 2 1 Calling party Subaddress IEI octet 1

Length of calling party subaddress contents

octet 2

1 type of odd/ev 0 0 0 ext subaddress Indica octet 3*

Subaddress information octet 4*

: :

etc.

図図図図 10.5.94/TS 24.008 Calling party subaddress

表表表表 10.5.121/TS 24.008: Calling party subaddress

Type of subaddress (octet 3) Bits 7 6 5 0 0 0 NSAP (X.213/ISO 8348 AD2) 0 1 0 User specified All other values are reserved Odd/even indicator (octet 3) Bit 4 0 even number of address signals 1 odd number of address signals The odd/even indicator is used when the type of subaddress is "user specified" and the coding is BCD Subaddress information (octet 4, etc...) The NSAP X.213/ISO8348AD2 address shall be formatted as specified by octet 4 which contains the Authority and Format Identifier (AFI). The encoding is made according to the "preferred binary encoding" as defined in X.213/ISO8348AD2. For the definition of this type of this type of subaddress, see Rec. ITU-T I.332. A coding example is given in ANNEX A. For User-specific subaddress, this field is encoded according to the user specification, subject to a maximum length of 20 octets. When interworking with X.25 networks BCD coding should be applied. NOTE: It is recommended that users apply NSAP subad dress type since this

subaddress type allows the use of decimal, binary and IA5 characters in a standardised manner.

10.5.4.11 Cause

cause IE の目的は、特定のメッセージを生成するための理由を説明し、処理エラーのイベント内の diagnostic（診断）情報を提供し、cause originator の位置を通知することにある。

cause IE は、図 10.5.95/TS 24.008 および表 10.5.122 と表 10.5.123/TS 24.008 に示すようにエンコードされる。

cause IE は少長 4 オクテット、大長 32 オクテットの type 4 IE である。

cause IE をメッセージ内で反復することもできる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 355

8 7 6 5 4 3 2 1 Cause IEI octet 1

Length of cause contents

octet 2

0/1 ext

coding standard

0 spare

Location

octet 3

1 ext

Recommendation

octet 3a*

1 ext

cause value

octet 4

diagnostic(s) if any octet 5*

octet N*

図図図図 10.5.95/TS 24.008 Cause information element

recommendation フィールド用にデフォルト値が適用される場合には、オクテット 3a は省略すること。

表表表表 10.5.122/TS 24.008: Cause IE

Coding standard (octet 3) Bits 7 6 0 0 Coding as specified in ITU-T Rec. Q.931 0 1 Reserved for other international standards 1 0 National standard 1 1 Standard defined for the GSMßPLMNS as described below and in table

10.86/GSM 24.008 Coding standards other than "1 1 - Standard defined for the GSM PLMNS" shall not be used if the cause can be represented with the GSM standardized coding. The mobile station or network need not support any other coding standard than "1 1 - Standard defined for the GSM PLMNS". If a cause IE indicating a coding standard not supported by the receiver is received, cause "interworking, unspecified" shall be assumed. Location (octet 3) Bits 4 3 2 1 0 0 0 0 User 0 0 0 1 private network serving the local user 0 0 1 0 public network serving the local user 0 0 1 1 transit network 0 1 0 0 public network serving the remote user 0 1 0 1 private network serving the remote user 0 1 1 1 international network 1 0 1 0 network beyond interworking point All other values are reserved. Recommendation (octet 3a) Octet 3a shall not be included if the coding standard is coded as "1 1 - Standard defined for GSM PLMNS". If the coding standard is different from "1 1 - Standard defined for GSM PLMNS", the coding of octet 3a, if included, and octets 4 to N is according to that coding standard.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 356

表表表表 10.5.122/TS 24.008: Cause IE (続き続き続き続き)

Cause value (octet 4) The cause value is divided in two fields: a class (bits 5 through 7) and a value within the class (bits 1 through 4). The class indicates the general nature of the event. Class (000): normal event Class (001): normal event Class (010): resource unavailable Class (011): service or option not available Class (100): service or option not implemented Class (101): invalid message (e.g. parameter out of range) Class (110): protocol error (e.g. unknown message) Class (111): Interworking The cause values are listed in 表 10.86/GSMß24.008 below and defined in Annex H. Diagnostic(s) (octet 5) Diagnostic information is not available for every cause, see 表 10.86/GSM 24.008 below. When available, the diagnostic(s) is coded in the same way as the corresponding information element in section 10. The inclusion of diagnostic(s) is optional.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 357

表表表表 10.5.123/TS 24.008: Cause IE の値の値の値の値

Cause value Cause Cause Diag- Remarks Class Value num. nostic

7 6 5 4 3 2 1 0 0 0 0 0 0 1 1. Unassigned (unallocated) number Note 9 0 0 0 0 0 1 1 3. No route to destination Note 9 0 0 0 0 1 1 0 6. Channel unacceptable - 0 0 0 1 0 0 0 8. Operator determined barring - 0 0 1 0 0 0 0 16. Normal call clearing Note 9 0 0 1 0 0 0 1 17. User busy Note 1 0 0 1 0 0 1 0 18. No user responding - 0 0 1 0 0 1 1 19. User alerting, no answer - 0 0 1 0 1 0 1 21. Call rejected Note 9 - user supplied

diagnostic (note 4) 0 0 1 0 1 1 0 22. Number changed New destination(note 5) 0 0 1 1 0 0 1 25. Pre-emption 0 0 1 1 0 1 0 26. Non selected user clearing - 0 0 1 1 0 1 1 27. Destination out of order - 0 0 1 1 1 0 0 28. Invalid number format (incomplete

number) -

0 0 1 1 1 0 1 29. Facility rejected Note 1 0 0 1 1 1 1 0 30. Response to STATUS ENQUIRY - 0 0 1 1 1 1 1 31. Normal, unspecified - 0 1 0 0 0 1 0 34. No circuit/channel available Note 1 0 1 0 0 1 1 0 38. Network out of order - 0 1 0 1 0 0 1 41. Temporary failure - 0 1 0 1 0 1 0 42. Switching equipment congestion - 0 1 0 1 0 1 1 43. Access information discarded Discarded information

element identifiers (note 6)

0 1 0 1 1 0 0 44. requested circuit/channel not available - 0 1 0 1 1 1 1 47. Resources unavailable, unspecified - 0 1 1 0 0 0 1 49. Quality of service unavailable Note 9 0 1 1 0 0 1 0 50. Requested facility not subscribed Note 1 0 1 1 0 1 1 1 55. Incoming calls barred within the CUG Note 1 0 1 1 1 0 0 1 57. Bearer capability not authorized Note 3 0 1 1 1 0 1 0 58. Bearer capability not presently available Note 3 0 1 1 1 1 1 1 63. Service or option not available,

unspecified -

1 0 0 0 0 0 1 65. Bearer service not implemented Note 3

(continued)

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 358

表表表表 10.5.123/TS 24.008 (続き続き続き続き): Cause IE の値の値の値の値

Cause value Cause Cause Diag- Remarks Class Value num. nostic

7 6 5 4 3 2 1 1 0 0 0 1 0 0 68. ACM equal to or greater than ACMmax 1 0 0 0 1 0 1 69. Requested facility not implemented Note 1 1 0 0 0 1 1 0 70. Only restricted digital information

bearer capability is available

1 0 0 1 1 1 1 79. Service or option not implemented, unspecified

-

1 0 1 0 0 0 1 81. Invalid transaction identifier value - 1 0 1 0 1 1 1 87. User not member of CUG Note 1 1 0 1 1 0 0 0 88. Incompatible destination Incompatible parameter

(Note 2) 1 0 1 1 0 1 1 91. Invalid transit network selection - 1 0 1 1 1 1 1 95. Semantically incorrect message - 1 1 0 0 0 0 0 96. Invalid mandatory information Information element

identifier(s) 1 1 0 0 0 0 1 97. Message type non-existent or not

implemented Message type

1 1 0 0 0 1 0 98. Message type not compatible with protocol state

Message type

1 1 0 0 0 1 1 99. Information element non-existent or not implemented

Information element identifier(s) (notes 6,7)

1 1 0 0 1 0 0 100. Conditional IE error Information element identifier(s) (note 6)

1 1 0 0 1 0 1 101. Message not compatible with protocol state

Message type

1 1 0 0 1 1 0 102. Recovery on timer expiry Timer number (note 8) 1 1 0 1 1 1 1 111. Protocol error, unspecified - 1 1 1 1 1 1 1 127. Interworking, unspecified -

0～31 までの範囲の値は全て、理由値 31 として扱うこと。







注 1: 付加サービス用の Diagnostic は以下のように処理される：

オクテット 5, ビット 8:

セクション 10.5 の前置きに定義された拡張ビットである。本プロトコルの本バージョンでは、本ビットは

1 に設定すること。この値が 0 に設定された場合、以下のオクテットのコンテンツは無視すること。

オクテット 5, ビット 7～1:

0000001 - Outgoing calls barred within CUG

0000010 - No CUG selected

0000011 - Unknown CUG index

0000100 - CUG index incompatible with requested basic service

0000101 - CUG call failure, unspecified

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 359

0000110 - CLIR not subscribed

0000111 - CCBS possible

0001000 - CCBS not possible

上記以外の全ての値は無視すること。

NOTE 2: 互換性のないパラメータは、incompatible IEI から構成される。

NOTE 3: cause 番号 57, 58 ,65 用の diagnostic フィールドのフォーマットを、図 10.5.88/TS 24.008 および表 10.5.102/TS 24.008 ～10.5.115/TS 24.008 に示す。

NOTE 4: ユーザ供給 diagnostics フィールドは、ユーザ仕様に従ってエンコードされ、cause IE の大長に支配

される。ユーザ供給 diagnostics のコーディングは、下記の注 9 に説明されるコーディング方法と矛盾

しない方法であること。

NOTE 5: new destination は、called party BCD number IE としてフォーマットされ、IEI を含む。

NOTE 6: セクション 10.5.4.2、 10.5.4.3 で説明されるロックシフト処理および非ロックシフト処理が適用される。

原則的には、IEI の順番は受信したメッセージ内の IEI の順番と同一である。

NOTE 7: locking shift IE だけが含まれ、IEI がその後に続かない場合、ロックシフト自身のコードセットが実装さ

れていないことを意味する。

NOTE 8: タイマ番号は IA5 文字でコーディングされる。例えば、T308 は"3" "0" "8"としてコーディングされる。各

オクテット内では以下のコーディングが使用される。

ビット 8：スペア"0" ビット 7～1：IA5 キャラクタ

オクテット 5 は"3"、オクテット 5a は"0"を伝送する、など。

NOTE 9: 以下のコードはオクテット 5 を使用してコーディングされる。

ビット 8:1

ビット 7～3：00000

ビット 2～1：以下の条件

00－未知

01－一定

10－短期的

10.5.4.11a CLIR suppression

CLIR suppression IE は、MS がネットワークに対して SETUP メッセージ内で送信することができる。使用方法につ

いては、TS 24.081 内で規定される。

CLIR suppression IE は、図 10.5.96/TS 24.008 内で示すようにエンコードされる。

CLIR suppression IE は type 2 の IE である。

8 7 6 5 4 3 2 1 CLIR suppression IEI octet 1

図図図図 10.5.96/TS 24.008 CLIR suppression IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 360

10.5.4.11b CLIR invocation

CLIR s invocation IE は、MS がネットワークに対して SETUP メッセージ内で送信することができる。使用方法につ

いては、TS 24.081 内で規定される。

CLIR s invocation IE は、図 10.5.97/TS 24.008 内で示すようにエンコードされる。

CLIR s invocation IE は type 2 の IE である。

8 7 6 5 4 3 2 1 CLIR invocation IEI octet 1

図図図図 10.5.97/TS 24.008 CLIR invocation IE

10.5.4.12 Congestion level

congestion level IE の目的は、呼の輻輳ステータスを説明することである。

congestion level IE は、図 10.5.98/TS 24.008 および表 10.5.124/TS 24.008 に示すようにエンコードされる。

congestion level IE は type 1 の IE である。

8 7 6 5 4 3 2 1 Congestion level

IEI octet 1

図図図図 10.5.98/TS 24.008 Congestion level IE

表表表表 10.5.124/TS 24.008: Congestion level IE

Congestion level (octet 1) Bits 4 3 2 1 0 0 0 0 receiver ready 1 1 1 1 receiver not ready All other values are reserved.

10.5.4.13 Connected number

connected number IE の目的は、呼の接続先パーティを特定することである。

connected number IE は、図 10.5.99/TS 24.008 内に示すようにエンコードされる。

connected number IE は type 4 の IE であり、少長 3 オクテット、大長 14 オクテットである。

8 7 6 5 4 3 2 1 Connected number IEI octet 1

Length of connected number contents octet 2 0/1 ext

Type of number

Number plan Identification

octet 3 note 1)

1 Presentation 0 0 0 Screening octet 3a* ext indicator Spare Indicator note 1)

Number digit 2 Number digit 1 octet 4* note 1)

Number digit 4 Number digit 3 octet 5* note 1)

note 2) : :

図図図図 10.5.99/TS 24.008

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 361

オクテット 3,4,5,等のコンテンツは、図 10.5.118/TS 24.008 に示すようにエンコードされる。オクテット 3a のコーディ

ング方法は表 10.5.120/TS 24.008 に定義される。

connected number が奇数桁の場合、終オクテットのビット 5～8 は、"1111"としてエンドマークコードして充填する

こと。

10.5.4.14 Connected subaddress

connected subaddress IE の目的は、呼の接続先パーティのサブアドレスを特定することにある。

connected subaddress IE は、図 10.5.100/TS 24.008 に示すようにエンコードされる。

connected subaddress IE は、少長 2 オクテット、大長 23 オクテットの type 4 の IE である。

8 7 6 5 4 3 2 1 Connected subaddress IEI octet 1

Length of connected subaddress contents octet 2 Type of odd/even 0 0 0 octet 3* subaddress indicator Spare

Subaddress information octet 4* : : etc.

図図図図 10.5.100/TS 24.008

Type of subaddress、odd/even indicator、および subaddress information のコーディングについては、表

10.5.119/TS 24.008 参照。

10.5.4.15 Facility

facility IE の目的は、付加サービスに関係する情報を送信することにある。TS 24.008 のスコープ内では、Facility information フィールドのコンテンツは多数のオクテットである。この送信メカニズムの使用方法については、

TS 24.080 内で説明される。

facility IE は、図 10.5.101/TS 24.008 に示すようにエンコードされる。

facility IE は、少長 2 オクテットの type 4 IE である。L3 メッセージの大オクテット数による制限（GSM 04.06 参

照）を除き、大長は規定されない。

8 7 6 5 4 3 2 1 Facility IEI octet 1

Length of facility contents octet 2 Facility information (see GSM 04.80) octet 3-?*

図図図図 10.5.101/TS 24.008


high layer compatibility IE の目的は、リモートユーザが互換性チェックを行なうための手段を提供することにある。

annex B 参照。

high layer compatibility IE は、図 10.5.102/TS 24.008 および表 10.5.125/TS 24.008 に示されるようにエンコード

される。

high layer compatibility IE は、少長 2 オクテット、大長 5 オクテットの type 4 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 362

NOTE: high layer compatibility IE は、呼発信エンティティ（発呼ユーザなど）と、指定されたエンティティ（例え

ば発呼ユーザによって指定された、リモートユーザまたは high layer function network node）との間

で、PLMN によってトランスペアレントに伝送される。ただし、ユーザによって明示的に要求された場合

（加入時など）には、電話サービスを実現するためのいくつかのケーパビリティを提供するネットワーク

は、本 IE を解釈して特定サービスに提供してもよい。

8 7 6 5 4 3 2 1 High layer compatibility IEI octet 1

Length of high layer compatibility contents

octet 2

1 ext

coding standard

interpretation

presentat. method of protocol profile

octet 3*

0/1 ext

High layer characteristics identification

octet 4*

1 ext

Extended high layer characteristics Identification

octet 4a* (note)

図図図図 10.5.102/TS 24.008 High layer compatibility IE

IE の値パートが空の場合には、IE は"not applicable"であることを通知する。

NOTE: 例えばオクテット 4 が Maintenance または Management、または audio visual の場合には、オクテッ

ト 4a が存在することもある。

表表表表 10.5.125/TS 24.008: High layer compatibility IE

Coding standard (octet 3) see ITU Recommendation Q.931. Interpretation (octet 3) see ITU Recommendation Q.931. Presentation method of protocol profile (octet 3) see ITU Recommendation Q.931. High layer characteristics identification (octet 4) see ITU Recommendation Q.931. Extended high layer characteristics identification (octet 4a) see ITU Recommendation Q.931.

10.5.4.16.1 Static conditions for the high layer compatibility IE contents （high layer compatibility IEのコンテンツ用の定常条件）

IE の値パートは、空であるか、または低オクテット 3 と 4 を含む。

10.5.4.17 Keypad facility

keypad facility IE の目的は、例えば端末のキーパッドを使用して入力された IA5 キャラクタを伝送することである

（注）。

keypad facility IE は、図 10.5.103/TS 24.008 に示すようにエンコードされる。

keypad facility IE は 2 オクテット長の type 3 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 363

8 7 6 5 4 3 2 1 Keypad facility IEI octet 1

Spare 0

Keypad information (IA5 character)

octet 2

図図図図 10.5.103/TS 24.008 Keypad facility information element

NOTE: GSM システムでは、本 IE は、IA5 キャラクタの 1 つである、1 つの DTMF 桁(0, 1, ... , 9, A, B, C, D, *, #)を伝送するために使用される。


low layer compatibility IE の目的は、指定されたエンティティ（例えば発呼ユーザによって指定された、リモートユー

ザまたはインターワーキングユニット、または high layer function network node）が互換性チェックするために使用

すべき手段を提供することにある。low layer compatibility IE は、呼発信エンティティ（発呼ユーザなど）と、指定され

たエンティティとの間で、PLMN によってトランスペアレントに伝送される。

IEI を除き、low layer compatibility IE は ITU 勧告 Q.931 のようにエンコードされる。

バックワード互換性上の理由から、ETS 300 102-1 (12-90)に従った modem type フィールドのコーディングもサポ

ートすること。

low layer compatibility IE は少長 2 オクテット、大長 18 オクテットの type 4 IE である。

8 7 6 5 4 3 2 1 Low layer compatibility IEI octet 1

Length of the low layer compatibility contents octet 2

The following octets are coded as described in

ITU Recommendation Q.931 (Coding of the modem type according to both Q.931 and

ETS 300 102-1 (12-90) shall be accepted)

octet 3* : : :

図図図図 10.5.104/TS 24.008 Low layer compatibility IE

IE の値パートが空の場合、IE は"not applicable"であることを示す。

10.5.4.19 More data

more data IE は、MS からネットワークに対して、またはネットワークから MS に対して、USER INFORMATION メ

ッセージ内で送信される。more data IE の存在は、宛先リモートユーザ／MS に対して、同一ブロックに属する情報

を含む他の USER INFORMATION メッセージがその後に続くことを通知する。

more data IE の使用は、ネットワークによって監視されない。

more data IE は図 10.5.105/TS 24.008 に示すようにエンコードされる。

more data IE は type 2 IE である。

8 7 6 5 4 3 2 1 More data IEI octet 1

図図図図 10.5.105/TS 24.008 More data IE

10.5.4.20 Notification indicator

notification indicator IE の目的は、呼に関する情報を通知することにある。

notification indicator IE は、図 10.5.106/TS 24.008 および表 10.5.126/ TS 24.008 に示すようにエンコードされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 364

notification indicator IE は、2 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 Notification indicator IEI octet 1

1 ext

Notification description

octet 2

図図図図 10.5.106/TS 24.008 Notification indicator IE

表表表表 10.5.126/TS 24.008: Notification indicator IE

Notification description (octet 2) Bits 7 6 5 4 3 2 1 0 0 0 0 0 0 0 User suspended 0 0 0 0 0 0 1 User resumed 0 0 0 0 0 1 0 Bearer change All other values are reserved.

10.5.4.21 Progress indicator

progress indicator IE の目的は、呼が有効である間に発生したイベントを説明することにある。

progress indicator IE は、図 10.5.107/TS 24.008 および表 10.5.127/TS 24.008 中で示されるようにエンコードさ

れる。

progress indicator IE は、4 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Progress indicator IEI octet 1

Length of progress indicator contents

octet 2

1 ext

coding standard

0 spare

Location

octet 3

1 ext

progress description

octet 4

図図図図 10.5.107/TS 24.008 Progress indicator IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 365

表表表表 10.5.127/TS 24.008: Progress indicator IE

Coding standard (octet 3) Bits 7 6 0 0 Standardized coding, as described in ITU-T Rec. Q.931 0 1 Reserved for other international standards 1 0 National standard 1 1 Standard defined for the GSMßPLMNS as described below Coding standards other than "1 1 - Standard defined for the GSM PLMNS" shall not be used if the progress description can be represented with the GSMßstandardized coding. The mobile station or network need not support any other coding standard than "1 1 - Standard defined for the GSM PLMNS". If a progress indicator IE indicating a coding standard not supported by the receiver is received, progress description "Unspecific" shall be assumed. Location (octet 3) Bits 4 3 2 1 0 0 0 0 User 0 0 0 1 Private network serving the local user 0 0 1 0 Public network serving the local user 0 1 0 0 Public network serving the remote user 0 1 0 1 Private network serving the remote user 1 0 1 0 Network beyond interworking point All other values are reserved. Note: Depending on the location of the users, the local public network and remote

public network may be the same network. Progress description (octet 4) Bits 7 6 5 4 3 2 1 No. 0 0 0 0 0 0 1 1. Call is not end-to-end PLMN/ISDN, further call

progress information may be available in-band 0 0 0 0 0 1 0 2. Destination address in non-PLMN/ISDN 0 0 0 0 0 1 1 3. Origination address in non-PLMN/ISDN 0 0 0 0 1 0 0 4. Call has returned to the PLMN/ISDN 0 0 0 1 0 0 0 8. In-band information or appropriate pattern now

available 0 1 0 0 0 0 0 32. Call is end-to-end PLMN/ISDN 1 0 0 0 0 0 0 64. Queueing All other values Unspecific

10.5.4.21a Recall type $(CCBS)$

recall type IE の目的は、再発呼理由を説明することである。

recall type IE は、図 10.5.108/TS 24.008 および表 10.5.128/TS 24.008 に示すようにエンコードされる。

recall type IE は、2 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 recall type IEI octet 1

Spare recall type 0 0 0 0 0 octet 2

図図図図 10.5.108/TS 24.008 Recall type IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 366

表表表表 10.5.128/TS 24.008: Recall type IE

recall type (octet 2, bits 1 to 4) Bits 3 2 1 0 0 0 - CCBS 0 0 1 }

to } - shall be treated as CCBS (intended for other similar types of Recall) 1 1 0 } 1 1 1 - reserved

10.5.4.21b Redirecting party BCD number

redirecting party BCD number IE の目的は、リダイレクトパーティを特定することにある。

redirecting party BCD number IE は、図 10.88a に示すようにエンコードされる。

redirecting party BCD number IE は type 4 IE である。ネットワーク→MS 方向では、少長 3 オクテット、大長

19 オクテットである。

8 7 6 5 4 3 2 1 Redirecting party BCD number IEI octet 1

Length of redirecting party BCD number contents

octet 2

0/1 ext

type of number

Numbering plan Identification

octet 3 (note 1)

1 presentat. 0 0 0 Screening octet 3a* ext indicator spare indicator (note 1)

Number digit 2

Number digit 1

octet 4* (note 1)

Number digit 4

Number digit 3

octet 5* (note 1)

:

Note 2) :

図図図図 10.88a/TS 24.008 Redirecting party BCD number IE

Note 1: オクテット3,4,などのコンテンツは、表 10.81に示されるようにエンコードされる。オクテット3aのコーディングについては、表 10.83で定義される。

Note 2: redirecting party BCD number IEが奇数桁の場合、最終オクテットのビット5～8は、"1111"としてエンドマークコードして充填すること。

10.5.4.21c Redirecting party subaddress

Redirecting party subaddress IE の目的は、リダイレクトパーティのサブアドレスを特定することである。サブアドレ

スの定義については、勧告 ITU-T I.330 を参照。

Redirecting party subaddress IE は、図 10.88b および表 10.84 に示すようにエンコードされる。

Redirecting party subaddress IE は、少長 2 オクテット、大長 23 オクテットの type 4 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 367

8 7 6 5 4 3 2 1 Redirecting party Subaddress IEI octet 1

Length of redirecting party subaddress contents

octet 2

1 ext

type of subaddress

odd/evIndica

0 0 0 octet 3*

Subaddress information

:

octet 4*

: etc.

図図図図 10.88b/TS 24.008 Redirecting party subaddress IE


repeat indicator IE の目的は、反復 IE がメッセージ内に含まれている場合、関連する反復 IE をどのように解釈する

べきかを通知することにある。repeat indicator IE は、メッセージ内で反復される関連する IE が初に発生する直

前に含まれる。"Mode 1"は、該当 IE がメッセージ内で初に発生することを示し、"mode 2"は同一メッセージ内で 2回目に発生することを示す。

repeat indicator IE は、図 10.5.109/TS 24.008 および表 10.5.129/TS 24.008 に示すようにエンコードされる。

repeat indicator IE は type 1 の IE である。

8 7 6 5 4 3 2 1 repeat indicator

IEI repeat indication octet 1

図図図図 10.5.109/TS 24.008 Repeat indicator IE

表表表表 10.5.129/TS 24.008: Repeat indicator IE

Repeat indication (octet 1) Bits 4 3 2 1 0 0 0 1 Circular for successive selection

"mode 1 alternate mode 2" 0 0 1 0 Support of fallback – mode 1 preferred, mode 2 selected if setup of

mode 1 fails 0 0 1 1 reserved: was allocated in earlier phases of the protocol

10.5.4.22a Reverse call setup direction

本 IE は、MODIFY メッセージおよび MODIFY COMPLETE メッセージ内に含まれ、MODIFY メッセージと関係する

データ呼の方向が、呼のセットアップ方向の反対であることを示す。

reverse call setup direction IE は、図 10.5.110/TS 24.008 に示すようにエンコードされる。

reverse call setup direction IE は type 2 の IE である。

8 7 6 5 4 3 2 1 reverse call setup direction IEI octet 1

図図図図 10.5.110/TS 24.008 Reverse call setup direction IE

10.5.4.22b SETUP Container $(CCBS)$

本 IE には、SETUP メッセージ（MS→ネットワーク）のコンテンツが含まれる。このことは、Call Control protocol discriminator IE、 Transaction Identifier IE、そして Setup message type IE が含まれないことを示す。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 368

SETUP Container IE は、図 10.5.111/TS 24.008 に示すようにエンコードされる。

SETUP Container IE は type 4 の IE である。L3 メッセージの大オクテット数による制限（GSM 04.06 参照）を除

き、大長は規定されない。

8 7 6 5 4 3 2 1 SETUP Container IEI octet 1

Length of SETUP container contents octet 2

SETUP message

octet 3-n

図図図図 10.5.111/TS 24.008 Octet j (j = 3, 4 ... n) is the unchanged octet j of the SETUP message.

10.5.4.23 Signal

signal IE の目的は、ネットワークがユーザに、リガ－ディングトーンとアラートシグナルを送信することを可能にする

ことにある。

signal IE は、図 10.5.112/TS 24.008 および表 10.5.130/TS 24.008 に示すようにエンコードされる。

signal IE は 2 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 Signal IEI octet 1

Signal value

octet 2

図図図図 10.5.112/TS 24.008 Signal IE

表表表表 10.5.130/TS 24.008: Signal IE

Signal value (octet 2) Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 dial tone on 0 0 0 0 0 0 0 1 ring back tone on 0 0 0 0 0 0 1 0 intercept tone on 0 0 0 0 0 0 1 1 network congestion tone on 0 0 0 0 0 1 0 0 busy tone on 0 0 0 0 0 1 0 1 confirm tone on 0 0 0 0 0 1 1 0 answer tone on 0 0 0 0 0 1 1 1 call waiting tone on 0 0 0 0 1 0 0 0 off-hook warning tone on 0 0 1 1 1 1 1 1 tones off 0 1 0 0 1 1 1 1 alerting off All other values are reserved.

10.5.4.24 SS Version Indicator

SS version indicator IE の目的は、TS 24.010 内で説明される Facility IE のデコートを助けることにある。TS 24.008 によれば、SS Version IE のコンテンツは、1 つまたは複数のオクテットである。SS version indicator IE の

使用方法は TS 24.080 で定義される。

SS version indicator IE は、図 10.5.113/TS 24.008 に示すようにエンコードされる。

SS version indicator IE は少長 2 オクテットの type 4 IE である。L3 メッセージの大オクテット数による制限

（GSM 04.06 参照）を除き、大長は規定されない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 369

8 7 6 5 4 3 2 1 SS version indicator IEI octet 1

Length of SS version indicator contents octet 2 SS version information (see GSM 04.80)

octet 3* : * : *

図図図図 10.5.113/TS 24.008

NOTE: Usually, this information element has only one octet of content.

10.5.4.25 User-user

user-user IE の目的は、MS とリモート ISDN ユーザ間で情報を伝送することにある。

user-user IE は、図 10.5.114/TS 24.008 および表 10.5.131/ TS 24.008 に示すようにエンコードされる。user-user IE のコンテンツについては、制限はない。

user-user IE は少長 3 オクテット、大長 35 オクテットまたは 131 オクテットの type 4 IE である。GSM PLMNの場合、SETUP メッセージ内での user-user IE の大長は 35 オクテットである。GSM PLMN の場合、USER INFORMATION, ALERTING, CONNECT, DISCONNECT, PROGRESS, RELEASE および RELEASE COMPLETE メッセージ内での user-user IE の大長は 131 オクテットである。

GSM PLMN 以外のネットワーク内においては、上記メッセージ内の user-user IE の大長は 35 または 131 オク

テットである。大長を 1 つの値に統一することは、長期的な課題である。つまり、正確な大長の値は FFS である。

NOTE: 注：user-user IE は、GSM PLMN 内でトランスペアレントに伝送される。

8 7 6 5 4 3 2 1 User-user IEI octet 1

Length of user-user contents

octet 2

User-user protocol discriminator

octet 3

User-user information octet 4* octet N*

図図図図 10.5.114/TS 24.008 User-user IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 370

表表表表 10.5.131/TS 24.008: User-user IE

User-user protocol discriminator (octet 3) Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 User specific protocol (Note 1) 0 0 0 0 0 0 0 1 OSI high layer protocols 0 0 0 0 0 0 1 0 X.244 (Note 2) 0 0 0 0 0 0 1 1 Reserved for system management convergence

function 0 0 0 0 0 1 0 0 IA5 characters (Note 3) 0 0 0 0 0 1 1 1 Rec.V.120 rate adaption 0 0 0 0 1 0 0 0 Q.931 (I.451) user-network call control

messages 0 0 0 1 0 0 0 0 Reserved for other network layer or through layer 3 protocols including Rec.X.25 0 0 1 1 1 1 1 1 (Note 4) 0 1 0 0 0 0 0 0 through National use 1 1 0 0 1 1 1 1 0 1 0 1 0 0 0 0 Reserved for other network through layer or layer 3 protocols 1 1 1 1 1 1 1 0 including Rec.X.25 (Note 4) All other values are reserved. Note 1: The user information is structured according to user needs. Note 2: The user information is structured according to Rec.X.244 which specifies

the structure of X.25 call user data. Note 3: The user information consists of IA5 characters. Note 4: These values are reserved to discriminate these protocol discriminators

from the first octet of a X.25 packet including general format identifier.

10.5.4.26 Alerting Pattern $(NIA)$

Alerting Pattern IE の目的は、ネットワークが、MS が使用するアラートに関する情報を伝送できるようにすることに

ある（GSM 02.07 参照）。

Alerting Pattern IE は、図 10.5.115/TS 24.008 および表 10.5.132/TS 24.008 に示されるようにエンコードされる。

Alerting Pattern IE は 3 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Alerting Pattern IEI octet 1

length of alerting pattern content octet 2 0 0 0 0 Alerting Pattern

spare value octet 3

図図図図 10.5.115/TS 24.008 Alerting Pattern IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 371

表表表表 10.5.132/TS 24.008: Alerting Pattern IE

Alerting Pattern value (octet 3) Bits 4 3 2 1 0 0 0 0 alerting pattern 1 0 0 0 1 alerting pattern 2 0 0 1 0 alerting pattern 3 0 1 0 0 alerting pattern 5 0 1 0 1 alerting pattern 6 0 1 1 0 alerting pattern 7 0 1 1 1 alerting pattern 8 1 0 0 0 alerting pattern 9 all other values are reserved

アラートパターン 1,2,3 はアラートレベル 0,1,2 を示す。

アラートパターン 5～9 はアラートカテゴリ 1～5 を示す。

10.5.4.27 Allowed actions $(CCBS)$

Allowed actions IE の目的は、それ以上許容された処理に関する情報を MS に対して提供することにある。

Allowed actions IE は、図 10.5.116/TS 24.008 および表 10.5.133/TS 24.008 に示すようにエンコードされる。

Allowed actions IE は 3 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Allowed Actions IEI octet 1

Length of allowed actions contents

octet 2

CCBS 0 0 0 0 0 0 0 act. Spare octet 3

図図図図 10.5.116/TS 24.008 Allowed actions IE

表表表表 10.5.133/TS 24.008: Allowed actions IE

CCBS activation (octet 3) Bits 8 0 Activation of CCBS not possible 1 Activation of CCBS possible


stream identifier (SI) IE の目的は、呼と RAB（Radio Access Bearer）とを関連付け、これらのシグナリング処理に

よって制御されるインタフェース内で新たなトラフィックチャネルを割当てるべきか否かを特定することにある。CC プ

ロトコル中に通知される SI の値は、RAB setup メッセージ内で送信されること。また、MS に対して、呼と RAB との

関係が通知される。

stream identifier (SI) IE は、図 10.5.117/TS 24.008 および表 10.5.134/TS 24.008 に示すようにエンコードされる。

stream identifier (SI) IE は、3 オクテット長の type 4 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 372

8 7 6 5 4 3 2 1 Stream Identifier IEI octet 1

Length of Stream Identifier contents

octet 2

Stream Identifier Value

octet 3

図図図図 10.5.117/TS 24.008: Stream Identifier IE

表表表表 10.5.134/TS 24.008: Stream Identifier IE

Stream Identifier value(octet 3) Bit 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 No bearer 0 0 0 0 0 0 0 1 1 : : 1 1 1 1 1 1 1 1 255

10.5.4.29 Network Call Control Capabilities

Network Call Control Capabilities IE の目的は、ネットワークの呼制御ケーパビリティを特定することにある。そのコ

ンテンツは、MS の呼処理方法に影響を与えることがある。

Network Call Control Capabilities IE は、図 10.5.118/TS 24.008 および表 10.5.135/TS 24.008 に示すようにエン


Network Call Control Capabilities IE は、3 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Network Call Control Capabilities IEI octet 1

Length of NW Call Control Cap. Contents

octet 2

0 0 0 0 0 0 0 Spare MCS octet 3

図図図図 10.5.118/TS 24.008 Network Call Control Capabilities IE

表表表表 10.5.135/TS 24.008: Network Call Control Capabilities IE

MCS (octet 3, bit 1) 0 This value indicates that the network does not support the multicall. 1 This value indicates that the network supports the multicall.

10.5.4.30 Cause of No CLI

Cause of No CLI IE は、MS に対して、SETUP メッセージ内に Calling party BCD number 桁が含まれていない場

合に、Calling party BCD number が通知されない詳細な理由を提供する。

Cause of No CLI IE は、図 10.5.118a/TS 24.008 および表 10.5.135a/TS 24.008 に示されるようにエンコードされ

る。

Cause of No CLI IE は 3 オクテット長の type 4 IE である。

8 7 6 5 4 3 2 1 Cause of No CLI IEI octet 1

Length of Cause of No CLI contents octet 2 Cause of No CLI octet 3

図図図図 10.5.118a/TS 24.008 Cause of No CLI IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 373

表表表表 10.5.135a/TS 24.008: Cause of No CLI IE

Cause of No CLI (octet 3) Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 Unavailable 0 0 0 0 0 0 0 1 Reject by user 0 0 0 0 0 0 1 0 Interaction with other service 0 0 0 0 0 0 1 1 Coin line/payphone Other values shall be interpreted as “Unavailable”.

10.5.4.31 Immediate modification indicator

本 IE は、チャネルコンフィギュレーションを変更しない、即時インコール修正（immediate in-call modification）を通

知するために使用される。

Immediate modification indicator IE は、図 10.5. 118b/TS 24.008 に示されるようにエンコードされる。

Immediate modification indicator IE は type 2 IE である。

8 7 6 5 4 3 2 1 Immediate modification indicator IEI octet 1

図図図図 10.5. 118b/TS 24.008 Immediate modification indicator IE

10.5.5 GPRS mobility management information elements

10.5.5.1 Attach result

attach result IE の目的は、GPRS アタッチ処理の結果を特定することである。

attach result IE は type 1 IE である。

attach result IE は図 10.5.117a/TS 24.008 および表 10.5.134a/TS 24.008 に示されるようにエンコードされる。

8 7 6 5 4 3 2 1 Attach result

IEI 0

spareResult of

attach octet 1

図図図図 10.5.117a/TS 24.008: Attach result IE

表表表表 10.5.134a/TS 24.008: Attach result IE

Result of attach (octet 1) Bits 3 2 1 0 0 1 GPRS only attached 0 1 1 Combined GPRS/IMSI attached All other values are reserved.

10.5.5.2 Attach type

attach type IE の目的は、要求されたアタッチのタイプを通知する、つまり MS が GPRS アタッチを希望しているの

か、それとも複合 GPRS アタッチを希望しているのかを通知することにある。

attach type IE は type 1 IE である。

attach type IE は、図 10.5.118b/TS 24.008 および表 10.5.135b/TS 24.008 に示されるようにエンコードされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 374

8 7 6 5 4 3 2 1 Attach type

IEI FOR Type of attach octet 1

図図図図 10.5.118b/TS 24.008: Attach type IE

表表表表 10.5.135b/TS 24.008: Attach type IE

Type of attach (octet 1, bit 1 to 3) Bits 3 2 1 0 0 1 GPRS attach 0 1 0 GPRS attach while IMSI attached 0 1 1 Combined GPRS/IMSI attach All other values are interpreted as GPRS attach in this version of the protocol. Follow-on request (octet 1, bit 4) Bits 4 0 No follow-on request pending 1 Follow-on request pending Follow-on request pending is applicable only in UMTS.

10.5.5.3 Ciphering algorithm

ciphering algorithm IE の目的は、どの暗号化アルゴリズムを使用すべきかを特定することにある。

ciphering algorithm IE は type 1 IE である。

ciphering algorithm IE は図 10.5.119/TS 24.008 および表 10.5.136/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Ciphering algorithm

IEI 0

spareType of

Algorithm octet 1

図図図図 10.5.119/TS 24.008: Ciphering algorithm IE

表表表表 10.5.136/TS 24.008: Ciphering algorithm IE

Type of ciphering algorithm (octet 1) Bits 3 2 1 0 0 0 ciphering not used 0 0 1 GPRS Encryption Algorithm GEA/1 0 1 0 GPRS Encryption Algorithm GEA/2 0 1 1 GPRS Encryption Algorithm GEA/3 1 0 0 GPRS Encryption Algorithm GEA/4 1 0 1 GPRS Encryption Algorithm GEA/5 1 1 0 GPRS Encryption Algorithm GEA/6 1 1 1 GPRS Encryption Algorithm GEA/7

10.5.5.4 TMSI status

TMSI status IE の目的は、MS 内で有効な TMSI が利用可能か否かを通知することにある。

TMSI status IE は type 1 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 375

TMSI status IE は図 10.5.120/GSM 04.08 および表 10.5.137/GSM 04.08 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 TMSI status 0 0 0 TMSI octet 1

IEI spare Flag

図図図図 10.5.120/GSM 04.08: TMSI status IE

表表表表 10.5.137/GSM 04.08: TMSI status IE

TMSI flag (octet 1) Bit 1 0 no valid TMSI available 1 valid TMSI available

10.5.5.5 Detach type

detach type IE の目的は、MS がどのタイプのデタッチを要求しているのかを通知することにある。ネットワーク→

MS の方向では、detach type IE はデタッチ要求が送信された理由を通知するために使用される。

detach type IE は type 1 IE である。

detach type IE は図 10.5.121/TS 24.008 および表 10.5.138/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Detach type

IEI Power

off Type of detach

octet 1

図図図図 10.5.121/TS 24.008: Detach type IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 376

表表表表 10.5.138/TS 24.008: Detach type IE

Type of detach (octet 1) In the MS to network direction: Bits 3 2 1 0 0 1 GPRS detach 0 1 0 IMSI detach 0 1 1 Combined GPRS/IMSI detach All other values are interpreted as Combined GPRS/IMSI detach by this version of the protocol. In the network to MS direction: Bits 3 2 1 0 0 1 re-attach required 0 1 0 re-attach not required 0 1 1 IMSI detach (after VLR failure) All other values are interpreted as re-attach not required by this version of the protocol. Power off (octet 1) In the MS to network direction: Bit 4 0 normal detach 1 power switched off In the network to MS direction the Power off bit shall be spare and set to zero.

10.5.5.6 DRX parameter

DRX parameter IE の目的は、MS が DRX モードを使用するか否かを通知することにある。

DRX parameter IE は 3 オクテット長の type 3 IE である。

DRX parameter IE の値パートは、表 10.5.139/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 DRX parameter IEI octet 1

SPLIT PG CYCLE CODE octet 2 CN Specific DRX cycle length

coefficient SPLIT

on CCCH

non-DRX timer

octet 3

図図図図 10.5.122/TS 24.008: DRX parameter IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 377

表表表表 10.5.139/TS 24.008: DRX parameter IE

SPLIT PG CYCLE CODE, octet 2 The octet contains the binary coded value of the SPLIT PG CYCLE CODE. The SPLIT PG CYCLE value is derived from the SPLIT PG CYCLE CODE as follows: 0 704 (equivalent to no DRX) 1 to 64 1 to 64, respectively 65 71 66 72 67 74 68 75 69 77 70 79 71 80 72 83 73 86 74 88 75 90 76 92 77 96 78 101 79 103 80 107 81 112 82 116 83 118 84 128 85 141 86 144 87 150 88 160 89 171 90 176 91 192 92 214 93 224 94 235 95 256 96 288 97 320 98 352 All other values are reserved and shall be interpreted as 1 by this version of the protocol. SPLIT on CCCH, octet 3 (bit 4) 0 Split pg cycle on CCCH is not supported by the mobile station 1 Split pg cycle on CCCH is supported by the mobile station non-DRX timer, octet 3 bit 3 2 1 0 0 0 no non-DRX mode after transfer state 0 0 1 max. 1 sec non-DRX mode after transfer state 0 1 0 max. 2 sec non-DRX mode after transfer state 0 1 1 max. 4 sec non-DRX mode after transfer state 1 0 0 max. 8 sec non-DRX mode after transfer state 1 0 1 max. 16 sec non-DRX mode after transfer state 1 1 0 max. 32 sec non-DRX mode after transfer state 1 1 1 max. 64 sec non-DRX mode after transfer state

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 378

CN Specific DRX cycle length coefficient, octet 3 bit 8 7 6 5 UMTS specific 0 0 0 0 CN Specific DRX cycle length coefficient not specified by the MS, ie.

the system information value 'CN domain specific DRX cycle length' is used. (Ref TS 25.331)

0 0 1 0 CN Specific DRX cycle length coefficient 2 0 0 1 1 CN Specific DRX cycle length coefficient 3 0 1 0 0 CN Specific DRX cycle length coefficient 4 0 1 0 1 CN Specific DRX cycle length coefficient 5 0 1 1 0 CN Specific DRX cycle length coefficient 6 0 1 1 1 CN Specific DRX cycle length coefficient 7 1 0 0 0 CN Specific DRX cycle length coefficient 8 1 0 0 1 CN Specific DRX cycle length coefficient 9 1 0 1 0 CN Specific DRX cycle length coefficient 10 1 0 1 1 CN Specific DRX cycle length coefficient 11 1 1 0 0 CN Specific DRX cycle length coefficient 12 All other values shall be interpreted as "CN Specific DRX cycle length coefficient not specified by the MS " by this version of the protocol. Note: In UMTS this field (octet 3 bits 8 to 5) is used, but was spare in earlier

versions of this protocol.

10.5.5.7 Force to standby

force to standby IE の目的は、MS のセル更新実行を停止させるために、MS の READY タイマを強制的に停止さ

せることにある。

UMTS では、ネットワークは常に force to standby IE 内で force to standby not indicated を通知すること。

force to standby IE は type 1 IE である。

force to standby IE は図 10.5.123/TS 24.008 および表 10.5.140/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Force to standby

IEI 0

spareForce to

standby value octet 1

図図図図 10.5.123/TS 24.008: Force to standby IE

表表表表 10.5.140/TS 24.008: Force to standby IE

Force to standby value (octet 1) Bits 3 2 1 0 0 0 Force to standby not indicated 0 0 1 Force to standby indicated All other values are interpreted as force to standby not indicated by this version of the protocol.


P-TMSI signature IE の目的は、MS の GMM コンテキストを特定することにある。

P-TMSI signature IE は 4 オクテット長の type 3 IE である。

P-TMSI signature IE は図 10.5.124/TS 24.008 および表 10.5.141/TS 24.008 に示すようにエンコードされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 379

8 7 6 5 4 3 2 1 P-TMSI signature IEI octet 1

P-TMSI signature value

octet 2 octet 4

図図図図 10.5.124/TS 24.008: P-TMSI signature IE

表表表表 10.5.141/TS 24.008: P-TMSI signature IE

P-TMSI signature value Octets 2, 3 and 4 contain the binary representation of the P-TMSI signature. Bit 1 of octet 4 is the least significant bit and bit 8 of octet 2 is the most significant bit.

10.5.5.9 Identity type 2

identity type 2 IE の目的は、要求されているアイデンティティを特定することにある。

identity type 2 IE は type 1 IE である。

identity type 2 IE は図 10.5.125/TS 24.008 および表 10.5.142/TS 24.008 にに示すようにエンコードされる。

8 7 6 5 4 3 2 1 Identity type 2

IEI 0

spareType of Identity

octet 1

図図図図 10.5.125/TS 24.008: Identity type 2 IE

表表表表 10.5.142/TS 24.008: Identity type 2 IE

Type of identity (octet 1) Bits 3 2 1 0 0 1 IMSI 0 1 0 IMEI 0 1 1 IMEISV 1 0 0 TMSI All other values are interpreted as IMSI by this version of the protocol.

10.5.5.10 IMEISV request

IMEISV request IE の目的は、MS が認証応答および暗号化応答メッセージ内に IMEISV を含めるべきか否かを通

知することにある。

IMEISV request IE は type 1 IE である。

IMEISV request IE は、図 10.5.126/TS 24.008 および表 10.5.143/TS 24.008 に示されるようにエンコードされる。

8 7 6 5 4 3 2 1 IMEISV request

IEI 0

spareIMEISV request

Value octet 1

図図図図 10.5.126/TS 24.008: IMEISV request IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 380

表表表表 10.5.143/TS 24.008: IMEISV request IE

IMEISV request value (octet 1) Bits 3 2 1 0 0 0 IMEISV not requested 0 0 1 IMEISV requested All other values are interpreted as IMEISV not requested by this version of the protocol.

10.5.5.11 Receive N-PDU Numbers list

Receive N-PDU Numbers list IE の目的は、現行の SNDCP Receive N-PDU Number の値を指定することにある。

Receive N-PDU Numbers list IE は、4～19 オクテット長の type 4 IE である。

Receive N-PDU Numbers list IE は、図 10.5.127/TS 24.008 および表 10.5.144/TS 24.008 に示されるようにエン


8 7 6 5 4 3 2 1 Receive N-PDU Number list IEI octet 1

Length of Receive N-PDU Number list contents

Receive N-PDU Number-list

octet 3 octet 4 octet n*

図図図図 10.5.127/TS 24.008: Receive N-PDU Number list IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 381

表表表表 10.5.144/TS 24.008: Receive N-PDU Number list IE

Receive N-PDU Number -list value ::=

{ < Receive N-PDU Number -list > < Padding bits> } ;

< Receive N-PDU Number-list > ::= < sapi : bit-string(4) > < Receive N-PDU Number-value : bit-string(8) > { < Receive N-PDU Number-list> | < null > } ;

< nsapi > ::= { 0101 }; | -- NSAPI 5 { 0110 }; | -- NSAPI 6 { 0111 }; | -- NSAPI 7 { 1000 }; | -- NSAPI 8 { 1001 }; | -- NSAPI 9 { 1010 }; | -- NSAPI 10 { 1011 }; | -- NSAPI 11 { 1100 }; | -- NSAPI 12 { 1101 }; | -- NSAPI 13 { 1110 }; | -- NSAPI 14 { 1111 }; -- NSAPI 15

< Receive N-PDU Number-value > ::= { 0 | 1} (8) ; -- Contains the binary coded representation of the receive N-PDU Number value. -- The first bit in transmission order is the most significant bit.

<Padding bits> ::= null | 0000;

10.5.5.12 MS network capability

MS network capability IE の目的は、MS と GPRS との関係という観点からの情報をネットワークに対して提供する

ことにある。IE のコンテンツが、ネットワークが MS のオペレーションを処理する方法に影響を与えることがある。MS network capability IE は一般的な MS の特性を通知するものであり、それゆえに明示的に通知されたフィールド以

外は送信されるチャネルの周波数帯とは無関係である。

MS network capability IE は大 10 オクテット長の type 4 IE である。

MS network capability IE の値パートは、図 10.5.128/TS 24.008 および表 10.5.145/TS 24.008 に示すようにエン


8 7 6 5 4 3 2 1 MS network capability IEI octet 1

Length of MS network capability contents octet 2 MS network capability value octet 3-10

図図図図 10.5.128/TS 24.008 MS network capability IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 382

表表表表 10.5.145/TS 24.008 MS network capability IE

<MS network capability value part> ::= <GEA1 bits> <SM capabilities via dedicated channels: bit> <SM capabilities via GPRS channels: bit> <UCS2 support: bit> <SS Screening Indicator: bit string(2)> <SoLSA Capability : bit> <Revision level indicator: bit> <PFC feature mode: bit> <Extended GEA bits> <Spare bits>;

<GEA1 bits> ::= < GEA/1 :bit>; <Extended GEA bits> ::= <GEA/2:bit><GEA/3:bit>< GEA/4:bit >< GEA/5:bit >< GEA/6:bit ><GEA/7:bit>; <Spare bits> ::= null | {<spare bit> < Spare bits >};

SS Screening Indicator 0 0 defined in TS 24.080

0 1 defined in TS 24.080 1 0 defined in TS 24.080 1 1 defined in TS 24.080 SM capabilities via dedicated channels 0 Mobile station does not support mobile terminated point to point SMS via dedicated signalling channels 1 Mobile station supports mobile terminated point to point SMS via dedicated signalling channels SM capabilities via GPRS channels 0 Mobile station does not support mobile terminated point to point SMS via GPRS packet data channels 1 Mobile station supports mobile terminated point to point SMS via GPRS packet data channels

UCS2 support This information field indicates the likely treatment by the mobile station of UCS2 encoded character strings. 0 the ME has a preference for the default alphabet (defined in GSM 03.38) over UCS2. 1 the ME has no preference between the use of the default alphabet and the use of UCS2.

GPRS Encryption Algorithm GEA/1 0 encryption algorithm GEA/1not available 1 encryption algorithm GEA/1 available

SoLSA Capability 0 The ME does not support SoLSA. 1 The ME supports SoLSA. Revision level indicator 0 used by a mobile station supporting earlier versions of the protocol 1 used by a mobile station supporting this version of the protocol

PFC feature mode 0 Mobile station does not support BSS packet flow procedures 1 Mobile station does support BSS packet flow procedures

GEA/2

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 383

0 encryption algorithm GEA/2 not available 1 encryption algorithm GEA/2 available

GEA/3 0 encryption algorithm GEA/3 not available 1 encryption algorithm GEA/3 available




GEA/7

0 encryption algorithm GEA/7 not available 1 encryption algorithm GEA/7 available

10.5.5.12a MS Radio Access capability

MS RA capability IE の目的は、MS の無線関係の情報を、ネットワークの無線部分に対して提供することにある。

IE のコンテンツは、ネットワークが MS のオペレーションを処理する方法に影響を与えることがある。

MS RA capability IE は、大長 52 オクテットの type 4 IE である。

MS RA capability IE は表 10.5.146/TS 24.008 に示すようにエンコードされる。

意味的規則： 3 つの Access Technology Type、GSM 900-P, GSM 900-E および GSM 900-R のうち 1 つ

だけが存在すること。

MS は、1 回の MM 処理の間に、サポートする Access Technology Type（[450, 480, 900, 1800, UMTS] または[850, 1900] MHz 帯）を通知すること。

エラー処理：受信した Access Technology Type が未知の値であった場合、関連する全てのフィールドを無

視すること。

If within a known Access Technology Type a receiver recognizes an unknown field it shall ignore it. 既知の Access Technology Type の中で、受信者にとって未知のフィールドがあった場合にはそれを無視す

ること。

See more details about error handling of MS radio access capability in TS GSM 08.18. MS 無線アクセスケーパビリティの詳細については、TS GSM 08.18 を参照。

- 1800Mhz と 1900Mhz 帯で無線周波数チャネル番号が共有されるので、MS は 1800Mhz と 1900Mhz のう

ちいずれかの無線アクセスケーパビリティを提供すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 384

表表表表 10.5.146/TS 24.008 : Mobile Station Radio Access Capability IE

< MS Radio Access capability IE > ::= <MS Radio Access capability IEI : 00100100 > <Length of MS RA capability: <octet>> -- length in octets of MS RA capability value part and spare bits <MS RA capability value part : < MS RA capability value part struct >> <spare bits>**; -- may be used for future enhancements <MS RA capability value part struct >::= --recursive structure allows any number of Access technologies < Access Technology Type: bit (4) > < Access capabilities : <Access capabilities struct> > { 0 | 1 <MS RA capability value part struct> } ; < Access capabilities struct > ::= < Length : bit (7) > -- length in bits of Content and spare bits <Access capabilities : <Content>> <spare bits>** ; -- expands to the indicated length -- may be used for future enhancements < Content > ::= < RF Power Capability : bit (3) > { 0 | 1 <A5 bits : <A5 bits> > } -- zero means that the same values apply for parameters as in the immediately preceeding Access capabilities field within this IE

-- The presence of the A5 bits is mandatory in the 1st Access capabilities struct within this IE. < ES IND : bit > < PS : bit > < VGCS : bit > < VBS : bit > { 0 | 1 < Multislot capability : Multislot capability struct > } ; -- zero means that the same values for multislot parameters as given in an earlier Access capabilities field within this IE apply also here { 0 | 1 < 8PSK Power Capability : bit(2) >} – '1' also means 8PSK modulation capability in uplink. < COMPACT Interference Measurement Capability : bit > < Revision Level Indicator : bit > < UMTS FDD Radio Access Technology Capability : bit > -- 3G RAT < UMTS TDD Radio Access Technology Capability : bit > -- 3G RAT < CDMA 2000 Radio Access Technology Capability : bit > -- 3G RAT -- error: struct too short, assume features do not exist

-- error: struct too long, ignore data and jump to next Access technolgy

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 385

表表表表 10.5.146/TS 24.008 (continued): Mobile Station Radio Access Capability IE

< Multislot capability struct > ::= { 0 | 1 < HSCSD multislot class : bit (5) > } { 0 | 1 < GPRS multislot class : bit (5) > < GPRS Extended Dynamic Allocation Capability : bit > } { 0 | 1 < SMS_VALUE : bit (4) > < SM_VALUE : bit (4) > } ; { 0 | 1 < ECSD multislot class : bit (5) > } { 0 | 1 < EGPRS multislot class : bit (5) > < EGPRS Extended Dynamic Allocation Capability : bit > } ; {0 | 1 <DTM Multi Slot Sub-Class : bit(2)> <MAC Mode Support : bit> <EGPRS Support : bit>} ; <A5 bits> ::= < A5/1 : bit> <A5/2 : bit> <A5/3 : bit> <A5/4 : bit> <A5/5 : bit> <A5/6 : bit> <A5/7 : bit>; -- bits for circuit mode ciphering algorithms Access Technology Type This field indicates the access technology type to be associated with the following access capabilities. Bits 4 3 2 1 0 0 0 0 GSM P 0 0 0 1 GSM E --note that GSM E covers GSM P 0 0 1 0 GSM R --note that GSM R covers GSM E and GSM P 0 0 1 1 GSM 1800 0 1 0 0 GSM 1900 0 1 0 1 GSM 450 0 1 1 0 GSM 480 0 1 1 1 GSM 850 All other values are treated as unknown by the receiver. RF Power Capability This field is coded as radio capability in Classmark 3 for the indicated band: it contains the binary coding of he power class associated (see GSM 05.05 paragraph 4.1 output power and paragraph 4.1.1 Mobile Station). 8PSK Power Capability This field is coded according to the definition in GSM 05.05. The presence of this field indicates also 8PSK modulation capability in uplink. A5/1 0 encryption algorithm A5/1 not available 1 encryption algorithm A5/1 available A5/2 0 encryption algorithm A5/2 not available 1 encryption algorithm A5/2 available A5/3 0 encryption algorithm A5/3 not available 1 encryption algorithm A5/3 available A5/4 0 encryption algorithm A5/4 not available 1 encryption algorithm A5/4 available A5/5 0 encryption algorithm A5/5 not available 1 encryption algorithm A5/5 available A5/6 0 encryption algorithm A5/6 not available 1 encryption algorithm A5/6 available A5/7 0 encryption algorithm A5/7 not available 1 encryption algorithm A5/7 available ES IND – (Controlled early Classmark Sending) 0 "controlled early Classmark Sending" option is not implemented 1 "controlled early Classmark Sending" option is implemented

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 386

表表表表 10.5.146/TS 24.008 (concluded): Mobile Station Radio Access Capability IE

PS – (Pseudo Synchronisation) 0 PS capability not present 1 PS capability present VGCS – (Voice Group Call Service) 0 no VGCS capability or no notifications wanted 1 VGCS capability and notifications wanted. VBS – (Voice Broadcast Service) 0 no VBS capability or no notifications wanted 1 VBS capability and notifications wanted

HSCSD Multi Slot Class The Multi Slot Class field is coded as the binary representation of the multislot class defined in TS GSM 05.02. Range 1 to 18, all other values are reserved.

GPRS Multi Slot Class The GPRS Multi Slot Class field is coded as the binary representation of the multislot class defined in TS GSM 05.02.

ECSD Multi Slot Class The presence of this field indicates ECSD capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the presence of 8-PSK Power Capability field. The Multi Slot Class field is coded as the binary representation of the multislot class defined in TS GSM 05.02. Range 1 to 18, all other values are reserved.

EGPRS Multi Slot Class The presence of this field indicates EGPRS capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the presence of 8-PSK Power Capability field. The EGPRS Multi Slot Class field is coded as the binary representation of the multislot class defined in TS GSM 05.02. GPRS Extended Dynamic Allocation Capability 0 Extended Dynamic Allocation Capability for GPRS is not implemented 1 Extended Dynamic Allocation Capability for GPRS is implemented EGPRS Extended Dynamic Allocation Capability 0 Extended Dynamic Allocation Capability for EGPRS is not implemented 1 Extended Dynamic Allocation Capability for EGPRS is implemented SMS_VALUE (Switch-Measure-Switch) (4 bit field) The SMS field indicates the time needed for the mobile station to switch from one radio channel to another, perform a neighbor cell power measurement, and the switch from that radio channel to another radio channel. Bits 4 3 2 1 0 0 0 0 1/4 timeslot (~144 microseconds) 0 0 0 1 2/4 timeslot (~288 microseconds) 0 0 1 0 3/4 timeslot (~433 microseconds) . . . 1 1 1 1 16/4 timeslot (~2307 microseconds) (SM_VALUE) Switch-Measure (4 bit field) The SM field indicates the time needed for the mobile station to switch from one radio channel to another and perform a neighbour cell power measurement. Bits 4 3 2 1 0 0 0 0 1/4 timeslot (~144 microseconds) 0 0 0 1 2/4 timeslot (~288 microseconds) 0 0 1 0 3/4 timeslot (~433 microseconds) . . . 1 1 1 1 16/4 timeslot (~2307 microseconds)

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 387

DTM Multi Slot Sub-Class (2 bit field) This field indicates the DTM capabilities of the MS. The DTM Multi Slot Sub-Class is independent from the Multi Slot Capabilities field. Bits 2 1 0 0 Sub-Class 1 supported 0 1 Sub-Class 5 supported 1 0 Sub-Class 9 supported 1 1 Reserved for future extension. If received, the network shall interpret this as ‘00’ MAC Mode Support (1 bit field) This field indicates whether the MS supports Dynamic and Fixed Allocation or only supports Exclusive Allocation Bits 1 0 Dynamic and Fixed Allocation not supported 1 Dynamic and Fixed allocation supported EGPRS Support (1 bit field) This field indicates whether or not the MS supports EGPRS Bit 1 0 EGPRS not supported 1 EGPRS supported COMPACT Interference Measurement Capability 0 COMPACT Interference Measurement Capability is not implemented 1 COMPACT Interference Measurement Capability is implemented Revision Level Indicator(1 bit field) Bit 0 The ME is Release ’98 or older 1 The ME is Release ’99 onwards UMTS FDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS FDD not supported 1 UMTS FDD supported UMTS TDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS TDD not supported 1 UMTS TDD supported CDMA 2000 Radio Access Technology Capability (1 bit field) Bit 0 CDMA2000 not supported 1 CDMA2000 supported

10.5.5.13 Spare

本セクションは意図的にスペアとして残されている。

10.5.5.14 GMM cause

GMM cause IE の目的は、MS からの GMM 要求がネットワークに拒否された理由を通知するものである。

GMM cause IE は、図 10.5.129/TS 24.008 および表 10.5.147/TS 24.008 に示すようにエンコードされる。

GMM cause IE は 2 オクテット長の type 3 IE である。

8 7 6 5 4 3 2 1 GMM cause IEI octet 1

Cause value octet 2

図図図図 10.5.129/TS 24.008: GMM cause IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 388

表表表表 10.5.147/TS 24.008: GMM cause IE

Cause value (octet 2) Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 1 0 IMSI unknown in HLR 0 0 0 0 0 0 1 1 Illegal MS 0 0 0 0 0 1 1 0 Illegal ME 0 0 0 0 0 1 1 1 GPRS services not allowed 0 0 0 0 1 0 0 0 GPRS services and non-GPRS services not

allowed 0 0 0 0 1 0 0 1 MS identity cannot be derived by the network 0 0 0 0 1 0 1 0 Implicitly detached 0 0 0 0 1 0 1 1 PLMN not allowed 0 0 0 0 1 1 0 0 Location Area not allowed 0 0 0 0 1 1 0 1 Roaming not allowed in this location area 0 0 0 1 0 0 0 0 MSC temporarily not reachable 0 0 0 1 0 0 0 1 Network failure 0 0 0 1 0 1 0 0 MAC failure 0 0 0 1 0 1 0 1 Synch failure 0 0 0 1 0 1 1 0 Congestion 0 0 1 0 1 0 0 0 No PDP context activated 0 0 1 1 0 0 0 0 }

to } retry upon entry into a new cell 0 0 1 1 1 1 1 1 } 0 1 0 1 1 1 1 1 Semantically incorrect message 0 1 1 0 0 0 0 0 Invalid mandatory information 0 1 1 0 0 0 0 1 Message type non-existent or not implemented 0 1 1 0 0 0 1 0 Message type not compatible with the protocol

state 0 1 1 0 0 0 1 1 Information element non-existent or not

implemented 0 1 1 0 0 1 0 0 Conditional IE error 0 1 1 0 0 1 0 1 Message not compatible with the protocol state 0 1 1 0 1 1 1 1 Protocol error, unspecified Any other value received by the mobile station shall be treated as 0110 1111, 'Protocol error, unspecified'. Any other value received by the network shall be treated as 0110 1111, 'Protocol error, unspecified'. NOTE: The listed reject cause values are defined in Annex G.

10.5.5.15 Routing area identification

routing area identification IE の目的は、GPRS カバレッジエリア内の RA を明確に識別することである。

routing area identification IE は、7 オクテット長の type 3 IE である。

routing area identification IE は、図 10.5.130/TS 24.008 および表 10.5.148/TS 24.008 に示すようにエンコードさ

れる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 389

8 7 6 5 4 3 2 1 Routing Area Identification IEI octet 1

MCC digit 2 MCC digit 1 octet 2 MNC digit 3 MCC digit 3 octet 3 MNC digit 2 MNC digit 1 octet 4

LAC octet 5 LAC cont'd octet 6

RAC octet 7

図図図図 10.5.130/TS 24.008: Routing area identification IE

表表表表 10.5.148/TS 24.008: Routing area identification IE

MCC, Mobile country code (octet 2 and 3) The MCC field is coded as in ITU-T Rec. E212, Annex A. If the RAI is deleted, the MCC and MNC shall take the value from the deleted RAI. In abnormal cases, the MCC stored in the mobile station can contain elements not in the set {0, 1 ... 9}. In such cases the mobile station should transmit the stored values using full hexadecimal encoding. When receiving such an MCC, the network shall treat the RAI as deleted. MNC, Mobile network code (octet 4) The coding of this field is the responsibility of each administration but BCD coding shall be used. If an administration decides to include only one digit in the MNC, then bits 5 to 8 of octet 4 are coded as "1111". Note: TS 23.003 defines that a 2 digit MNC shall be used, however the possibility to use a one digit MNC in LAI is provided on the radio interface In abnormal cases, the MNC stored in the mobile station can have digit 1 not in the set {0, 1 ... 9} and/or digit 2 not in the set {0, 1 ...9, F} hex. In such cases the mobile station should transmit the stored values using full hexadecimal encoding. When receiving such an MNC, the network shall treat the RAI as deleted. LAC, Location area code (octet 5 and 6) In the LAC field bit 8 of octet 5 is the most significant bit and bit 1 of octet 6 the least significant bit. The coding of the location area code is the responsibility of each administration except that two values are used to mark the LAC, and hence the RAI, as deleted. Coding using full hexadecimal representation may be used. The location area code consists of 2 octets. If a RAI has to be deleted then all bits of the location area code shall be set to one with the exception of the least significant bit which shall be set to zero. If a SIM is inserted in a Mobile Equipment with the location area code containing all zeros, then the Mobile Equipment shall recognise this LAC as part of a deleted RAI. RAC, Routing area code (octet 7) In the RAC field bit 8 of octet 7 is the most significant. The coding of the routing area code is the responsibility of each administration. Coding using full hexadecimal representation may be used. The routing area code consists 1 octet.

10.5.5.16 Spare

本セクションは意図的にスペアとして残されている。

10.5.5.17 Update result

update result IE の目的は、対応する更新処理の結果を特定することにある。

update result IE は type 1 IE である。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 390

update result IE は、図 10.5.131/TS 24.008 および表 10.5.149/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Update result

IEI 0

spareUpdate result

value octet 1

図図図図 10.5.131/TS 24.008: Update result IE

表表表表 10.5.149/TS 24.008: Update result IE

Update result value (octet 1) Bits 3 2 1 0 0 0 RA updated 0 0 1 combined RA/LA updated All other values are reserved.

10.5.5.18 Update type

update type IE の目的は、更新処理に対応するエリアを特定することにある。

update type IE は type 1 IE である。

update type IE は、図 10.5.132/TS 24.008 および表 10.5.150/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Update type

IEI FOR Update type

value octet 1

図図図図 10.5.132/TS 24.008: Update type IE

表表表表 10.5.150/TS 24.008: Update type IE

Update type value (octet 1, bit 1 to 3) Bits 3 2 1 0 0 0 RA updating 0 0 1 combined RA/LA updating 0 1 0 combined RA/LA updating with IMSI attach 0 1 1 Periodic updating All other values are reserved. Follow-on request (octet 1, bit 4) Bit 4 0 No follow-on request pending 1 Follow-on request pending Follow-on request pending is applicable only in UMTS.

10.5.5.19 A&C reference number

A&C reference number IE の目的は、どの AUTHENTICATION AND CIPHERING REQUEST に対して MS が

応答すべきか、AUTHENTICATION AND CIPHERING RESPONSE メッセージ内でネットワークに対して通知する

ことにある。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 391

A&C reference number IE は type 1 IE である。

A&C reference number IE は図 10.5.123/TS 24.008 および表 10.5.140/TS 24.008 に示すようにエンコードされ

る。

8 7 6 5 4 3 2 1 A&C reference number

IEI A&C reference number

value octet 1

図図図図 10.5.134/TS 24.008: A&C reference number IE

表表表表 10.5.152/TS 24.008: A&C reference number IE

A&C reference number value (octet 1) Unformatted 4 bit field

10.5.5.20 Service type

service type IE の目的は、サービス要求処理の目的を特定することにある。

service type IE は type 1 IE である。

service type IE は、図 10.5.135/TS 24.008 および表 10.5.153/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Service type

IEI 0

spareService type octet 1

図図図図 10.5.135/TS 24.008: Service type IE

表表表表 10.5.153/TS 24.008: Service type IE

Service type value (octet 1) Bits 3 2 1 0 0 0 Signalling 0 0 1 Data 0 1 0 Paging Response All other values are reserved.

10.5.5.21 Cell Notification

Cell Notification IE の目的は、ネットワークがサポートし、MS が使用すべき Cell Notification を通知することにある。

Cell Notification IE は、図 10.5.135a/GSM 24.008 に示すようにエンコードされる。

Cell Notification IE は type 2 IE である。

8 7 6 5 4 3 2 1 Cell Notification IEI octet 1

図図図図 10.5.135a/GSM 24.008: Cell Notification IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 392

10.5.6 Session management information elements

10.5.6.1 Access Point Name

access point name IE の目的は、GPRS ユーザが接続を希望するパケットデータネットワークを特定し、パケットデ

ータネットワークのアクセスポイントに対して MS が接続を希望していることを通知することにある。

access point name IE は、DNS ネーミング規則に従った、ラベルまたは完全な省略ドメイン名である（TS 23.003 [10]参照）。

access point name IE は、少長 3 オクテット、大長 102 オクテットの type 4 IE である。

access point name IE は、図 10.5.134/TS 24.008 および表 10.5.152/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Access point name IEI octet 1

Length of access point name contents octet 2 Access point name value octet 3

octet n*

図図図図 10.5.134/TS 24.008: Access point name IE

値パートは 03.03 [10]で定義される。

10.5.6.2 Network service access point identifier

network service access point identifier IE の目的は、L3 の GPRS データ送信用に使用される SAP（service access point）を特定することにある。

network service access point identifier IE は 2 オクテット長の type 3 IE である。

network service access point identifier IE は、図 10.5.135/TS 24.008 および表 10.5.153/TS 24.008 に示すよう


8 7 6 5 4 3 2 1 NSAPI IEI octet 1

0 0 0 0 NSAPI octet 2 Spare Value

図図図図 10.5.135/TS 24.008: Network service access point identifier IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 393

表表表表 10.5.153/TS 24.008: Network service access point identifier IE

NSAPI value (octet 2) Bits 4 3 2 1 0 0 0 0 reserved 0 0 0 1 reserved 0 0 1 0 reserved 0 0 1 1 reserved 0 1 0 0 reserved 0 1 0 1 NSAPI 5 0 1 1 0 NSAPI 6 0 1 1 1 NSAPI 7 1 0 0 0 NSAPI 8 1 0 0 1 NSAPI 9 1 0 1 0 NSAPI 10 1 0 1 1 NSAPI 11 1 1 0 0 NSAPI 12 1 1 0 1 NSAPI 13 1 1 1 0 NSAPI 14 1 1 1 1 NSAPI 15


protocol configuration options IE の目的は、PDP コンテキスト活性化に関係する外部ネットワークプロトコルオプシ

ョンを転送することにある。

protocol configuration options IE は、少長 2 オクテット、大長 253 オクテットの type 4 IE である。

protocol configuration options IE は、図 10.5.136/TS 24.008 および表 10.5.154/TS 24.008 に示すようにエンコ

ードされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 394

8 7 6 5 4 3 2 1 Protocol configuration options IEI octet 1

Length of protocol config. options contents octet 2 1

ext 0 0 0 0

Spare Configuration

protocol octet 3

Protocol ID 1

octet 4 octet 5

Length of protocol ID 1 contents octet 6

Protocol ID 1 contents octet 7 octet m

Protocol ID 2

octet m+1 octet m+2

Protocol ID 2 contents

octet m+4 octet n

. . .

octet n+1 octet x

Protocol ID n-1

octet x+1 octet x+2

Length of protocol ID n-1 contents octet x+3

Protocol ID n-1 contents octet x+4 octet y

Protocol ID n

octet y+1 octet y+2

Length of protocol ID n contents octet y+3

Protocol ID n contents octet y+4 octet z

図図図図 10.5.136/TS 24.008: Protocol configuration options IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 395

表表表表 10.5.154/TS 24.008: Protocol configuration options IE

Configuration protocol (octet 3) Bits 3 2 1 0 0 0 PPP for use with IP PDP type

All other values are interpreted as PPP in this version of the protocol.

Configuration protocol options list (octets 4 to z)

The configuration protocol options list contains a variable number of logical units, the may occur in an arbitrary order within the configuration protocol options list.

Each unit is of variable length and consists of a

- protocol identifier (2 octets); - the length of the protocol identifier contents of the unit (1 octet); and - the protocol identifier contents itself ( n octets).

The protocol identifier field contains the hexadecimal coding of the configuration protocol identifier. Bit 8 of the first octet of the protocol identifier field contains the most significant bit and bit 1 of the second octet of the protocol identifier field contains the least significant bit.

If the configuration protocol options list contains a protocol identifier that is not supported by the receiving entity the corresponding unit shall be discarded.

The length of the protocol identifier contents field contains the binary coded representation of the length of the protocol identifier contents field of a unit. The first bit in transmission order is the most significant bit.

The protocol identifier contents field of each unit contains information specific to the configuration protocol specified by the protocol identifier.

PPP

At least the following protocol identifiers (as defined in RFC 1700) shall be supported in this version of the protocol:

- C021H (LCP; - C023H (PAP); - C223H (CHAP);and - 8021H (IPCP).

The support of other protocol identifiers is implementation dependent and outside the scope of this specification.

The protocol identifier contents field of each unit corresponds to a 'Packet' as defined in RFC 1661 that is stripped off the 'Protocol' and the 'Padding' octets.

The detailed coding of the protocol identifier contents field is specified in the RFC that is associated with the protocol identifier of that unit.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 396

10.5.6.4 Packet data protocol address

packet data protocol address IE の目的は、PDP に対応付けられたアドレスを特定することにある。

packet data protocol address IE は、少長 4 オクテット、大長 20 オクテットの type 4 IE である。

packet data protocol address IE は、図 10.5.137/TS 24.008 および表 10.5.155/TS 24.008 に示すようにエンコー

ドされる。

8 7 6 5 4 3 2 1 Packet data protocol address IEI octet 1 Length of PDP address contents octet 2

0 0 0 0 spare

PDP type organisation octet 3

PDP type number octet 4

Address information

octet 5 octet n

図図図図 10.5.137/TS 24.008: Packet data protocol address IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 397

表表表表 10.5.155/TS 24.008: Packet data protocol address IE

Length of PDP address contents (octet 2) If the value of octet 2 equals 0000 0010, then :

- No PDP address is included in this information element; and

- If the PDP type is IP, dynamic addressing is applicable.

NOTE : For PPP no address is required in this information element.

PDP type organisation (octet 3) Bits 4 3 2 1 In MS to network direction : 0 0 0 0 ETSI allocated address 0 0 0 1 IETF allocated address 1 1 1 1 Empty PDP type

All other values are reserved.

In network to MS direction : 0 0 0 0 ETSI allocated address 0 0 0 1 IETF allocated address

All other values are reserved.

If bits 4,3,2,1 of octet 3 are coded 0 0 0 0 PDP type number value (octet 4) Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 Reserved, used in earlier version of this protocol 0 0 0 0 0 0 0 1 PDP-type PPP All other values are reserved in this version of the protocol.

If bits 4,3,2,1 of octet 3 are coded 0 0 0 1 PDP type number value (octet 4) Bits 8 7 6 5 4 3 2 1 0 0 1 0 0 0 0 1 IPv4 address 0 1 0 1 0 1 1 1 IPv6 address

All other values shall be interpreted as IPv4 address in this version of the protocol.

In MS to network direction: If bits 4,3,2,1 of octet 3 are coded 1 1 1 1 PDP type number value (octet 4) bits 8 to 1 are spare and shall be coded all 0.

Octet 3, bits 8, 7, 6, and 5 are spare and shall be coded all 0.

PDP type number が IPv4 の場合、オクテット 5～8 の Address information は IPv4 の IP アドレスを示す。オクテ

ット 5 のビット 8 は IP アドレスの上位ビットを、オクテット 8 のビット 1 は下位ビットをあらわす。

PDP type number が Ipv6 の場合、オクテット 5～20 の Address information は IPv4 の IP アドレスを示す。オクテ

ット 5 のビット 8 は IP アドレスの上位ビットを、オクテット 20 のビット 1 は下位ビットをあらわす。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 398

10.5.6.5 Quality of service

quality of service IE の目的は、PDP コンテキスト用の QoS パラメータを特定することにある。

quality of service IE は、SM プロトコルの旧バージョンとのバックワード互換性を確保するために定義される。

quality of service IE は 13 オクテット長の type 4 IE である。

quality of service IE は、図 10.5.138/TS 24.008 および表 10.5.156/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Quality of service IEI octet 1

Length of quality of service IE Octet 2 0 0 spare

Delay class

Reliability class

octet 3

Peak throughput

0 spare

Precedence class

octet 4

0 0 0 spare

Mean throughput

octet 5

Traffic Class Delivery order Delivery of erroneous SDU

Octet 6

Maximum SDU size Octet 7 Maximum bit rate for uplink Octet 8

Maximum bit rate for downlink Octet 9 Residual BER SDU error ratio Octet 10

Transfer delay Traffic Handling priority

Octet 11

Guaranteed bit rate for uplink

Octet 12

Guaranteed bit rate for downlink Octet 13

図図図図 10.5.138/TS 24.008: Quality of service IE

表表表表 10.5.156/TS 24.008: Quality of service IE

Reliability class, octet 3 (see TS 23.107) Bits 3 2 1 In MS to network direction: 0 0 0 Subscribed reliability class In network to MS direction: 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 1 Acknowledged GTP, LLC, and RLC; Protected data 0 1 0 Unacknowledged GTP; Acknowledged LLC and RLC, Protected data 0 1 1 Unacknowledged GTP and LLC; Acknowledged RLC, Protected data 1 0 0 Unacknowledged GTP, LLC, and RLC, Protected data 1 0 1 Unacknowledged GTP, LLC, and RLC, Unprotected data 1 1 1 Reserved All other values are interpreted as Unacknowledged GTP and LLC; Acknowledged RLC, Protected data in this version of the protocol. Delay class, octet 3 (see TS 22.060 and TS 23.107) Bits 6 5 4 In MS to network direction: 0 0 0 Subscribed delay class In network to MS direction: 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 1 Delay class 1 0 1 0 Delay class 2 0 1 1 Delay class 3 1 0 0 Delay class 4 (best effort) 1 1 1 Reserved

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 399

All other values are interpreted as Delay class 4 (best effort) in this version of the protocol. Bit 7 and 8 of octet 3 are spare and shall be coded all 0. Precedence class, octet 4 (see TS 23.107) Bits 3 2 1 In MS to network direction: 0 0 0 Subscribed precedence In network to MS direction: 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 1 High priority 0 1 0 Normal priority 0 1 1 Low priority 1 1 1 Reserved All other values are interpreted as Normal priority in this version of the protocol. Bit 4 of octet 4 is spare and shall be coded as 0. Peak throughput, octet 4 (see TS 23.107) Bits 8 7 6 5 In MS to network direction: 0 0 0 0 Subscribed peak throughput In network to MS direction: 0 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 0 1 Up to 1 000 octet/s 0 0 1 0 Up to 2 000 octet/s 0 0 1 1 Up to 4 000 octet/s 0 1 0 0 Up to 8 000 octet/s 0 1 0 1 Up to 16 000 octet/s 0 1 1 0 Up to 32 000 octet/s 0 1 1 1 Up to 64 000 octet/s 1 0 0 0 Up to 128 000 octet/s 1 0 0 1 Up to 256 000 octet/s 1 1 1 1 Reserved All other values are interpreted as Up to 1 000 octet/s in this version of the protocol. Mean throughput, octet 5 (see TS 23.107) Bits 5 4 3 2 1

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 400

In MS to network direction: 0 0 0 0 0 Subscribed mean throughput In network to MS direction: 0 0 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 0 0 1 100 octet/h 0 0 0 1 0 200 octet/h 0 0 0 1 1 500 octet/h 0 0 1 0 0 1 000 octet/h 0 0 1 0 1 2 000 octet/h 0 0 1 1 0 5 000 octet/h 0 0 1 1 1 10 000 octet/h 0 1 0 0 0 20 000 octet/h 0 1 0 0 1 50 000 octet/h 0 1 0 1 0 100 000 octet/h 0 1 0 1 1 200 000 octet/h 0 1 1 0 0 500 000 octet/h 0 1 1 0 1 1 000 000 octet/h 0 1 1 1 0 2 000 000 octet/h 0 1 1 1 1 5 000 000 octet/h 1 0 0 0 0 10 000 000 octet/h 1 0 0 0 1 20 000 000 octet/h 1 0 0 1 0 50 000 000 octet/h 1 1 1 1 0 Reserved 1 1 1 1 1 Best effort The value Best effort indicates that throughput shall be made available to the MS on a per need and availability basis. All other values are interpreted as Best effort in this version of the protocol. Bits 8 to 6 of octet 5 are spare and shall be coded all 0. Delivery of erroneous SDUs, octet 6 (see TS 23.107) Bits 3 2 1 In MS to network direction: 0 0 0 Subscribed delivery of erroneous SDUs In network to MS direction: 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 1 No detect ('-') 0 1 0 Erroneous SDUs are delivered ('yes') 0 1 1 Erroneous SDUs are not delivered ('no') 1 1 1 Reserved The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol. The MS shall consider all other values as reserved. Delivery order, octet 6 (see TS 23.107) Bits 5 4 3 In MS to network direction: 0 0 Subscribed delivery order In network to MS direction: 0 0 Reserved In MS to network direction and in network to MS direction : 0 1 With delivery order ('yes') 1 0 Without delivery order ('no') 1 1 Reserved

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 401

Traffic class, octet 6 (see TS 23.107) Bits 8 7 6 In MS to network direction: 0 0 0 Subscribed traffic class In network to MS direction: 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 1 Conversational class 0 1 0 Streaming class 0 1 1 Interactive class 1 0 0 Background class 1 1 1 Reserved The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol. The MS shall consider all other values as reserved. Maximum SDU size, octet 7 (see TS 23.107) In MS to network direction: 0 0 0 0 0 0 0 0 Subscribed maximum SDU size 1 1 1 1 1 1 1 1 Reserved In network to MS direction: 0 0 0 0 0 0 0 0 Reserved 1 1 1 1 1 1 1 1 Reserved In MS to network direction and in network to MS direction : For values in the range 00000001 to 10010110 the Maximum SDU size value is binary coded in 8 bits, using a granularity of 10 octets, giving a range of values from 10 octets to 1500 octets. Values above 10010110 are as below: 1 0 0 1 0 1 1 1 1502 octets 1 0 0 1 1 0 0 0 1510 octets 1 0 0 1 1 0 0 1 1520 octets The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of this protocol. The MS shall consider all other values as reserved. Maximum bit rate for uplink, octet 8 Bits 8 7 6 5 4 3 2 1 In MS to network direction: 0 0 0 0 0 0 0 0 Subscribed maximum bit rate for uplink In network to MS direction: 0 0 0 0 0 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 0 0 0 0 0 1 The maximum bit rate is binary coded in 8 bits, using a granularity of 1 kbps 0 0 1 1 1 1 1 1 giving a range of values from 1 kbps to 63 kbps in 1 kbps increments. 0 1 0 0 0 0 0 0 The maximum bit rate is 64 kbps + ((the binary coded value in 8 bits –01000000) * 8 kbps) 0 1 1 1 1 1 1 1 giving a range of values from 64 kbps to 568 kbps in 8 kbps increments. 1 0 0 0 0 0 0 0 The maximum bit rate is 576 kbps + ((the binary coded value in 8 bits –10000000) * 64 kbps) 1 1 1 1 1 1 1 0 giving a range of values from 576 kbps to 8640 kbps in 64 kbps increments. 1 1 1 1 1 1 1 1 0kbps Maximum bit rate for downlink, octet 9 (see TS 23.107) Coding is identical to that of Maximum bit rate for uplink.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 402

Residual Bit Error Rate (BER), octet 10 (see TS 23.107) Bits 8 7 6 5 In MS to network direction: 0 0 0 0 Subscribed residual BER In network to MS direction: 0 0 0 0 Reserved In MS to network direction and in network to MS direction : The Residual BER value consists of 4 bits. The range is from 5*10-2 to 6*10-8. 0 0 0 1 5*10-2 0 0 1 0 1*10-2 0 0 1 1 5*10-3 0 1 0 0 4*10-3 0 1 0 1 1*10-3 0 1 1 0 1*10-4 0 1 1 1 1*10-5 1 0 0 0 1*10-6 1 0 0 1 6*10-8 1 1 1 1 Reserved The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol. The MS shall consider all other values as reserved. SDU error ratio, octet 10 (see TS 23.107) Bits 4 3 2 1 In MS to network direction: 0 0 0 0 Subscribed SDU error ratio In network to MS direction: 0 0 0 0 Reserved In MS to network direction and in network to MS direction : The SDU error ratio value consists of 4 bits. The range is is from 1*10-1 to 1*10-6. 0 0 0 1 1*10-2 0 0 1 0 7*10-3 0 0 1 1 1*10-3 0 1 0 0 1*10-4 0 1 0 1 1*10-5 0 1 1 0 1*10-6 0 1 1 1 1*10-1 1 1 1 1 Reserved The network shall map all other values not explicitly defined onto one of the values defined in this version of the protocol. The network shall return a negotiated value which is explicitly defined in this version of the protocol. The MS shall consider all other values as reserved. Traffic handling priority, octet 11 (see TS 23.107) Bits 2 1 In MS to network direction: 0 0 Subscribed traffic handling priority In network to MS direction: 0 0 Reserved In MS to network direction and in network to MS direction : 0 1 Priority level 1 1 0 Priority level 2 1 1 Priority level 3 The Traffic handling priority value is ignored if the Traffic Class is Conversation class, Streaming class or Background class. Transfer delay, octet 11 (See TS 23.107) Bits 8 7 6 5 4 3

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 403

In MS to network direction: 0 0 0 0 0 0 Subscribed transfer delay In network to MS direction: 0 0 0 0 0 0 Reserved In MS to network direction and in network to MS direction : 0 0 0 0 0 1 The Transfer delay is binary coded in 6 bits, using a granularity of 10 ms 0 0 1 1 1 1 giving a range of values from 10 ms to 150 ms in 10 ms increments 0 1 0 0 0 0 The transfer delay is 200 ms + ((the binary coded value in 6 bits – 010000) * 50 ms) 0 1 1 1 1 1 giving a range of values from 200 ms to 950 ms in 50ms increments 1 0 0 0 0 0 The transfer delay is 1000 ms + ((the binary coded value in 6 bits – 100000) * 100 ms) 1 1 1 1 1 0 giving a range of values from 1000 ms to 4100 ms in 100ms increments 1 1 1 1 1 1 Reserved . The Transfer delay value is ignored if the Traffic Class is Interactive class or Background class. Guaranteed bit rate for uplink, octet 12 (See TS 23.107) Coding is identical to that of Maximum bit rate for uplink. The Guaranteed bit rate for uplink value is ignored if the Traffic Class is Interactive class or Background class, or Maximum bit rate for uplink is set to 0 kbps. Guaranteed bit rate for downlink, octet 13(See TS 23.107) Coding is identical to that of Maximum bit rate for uplink. The Guaranteed bit rate for downlink value is ignored if the Traffic Class is Interactive class or Background class, or Maximum bit rate for downlink is set to 0 kbps.

10.5.6.6 SM cause

SM cause IE の目的は、セッション管理要求が拒否された理由を通知することにある。

SM cause IE e は 2 オクテット長の type 3 IE である。

SM cause IE は図 10.5.139/TS 24.008 および表 10.5.157/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 SM cause IEI octet 1 Cause value octet 2

図図図図 10.5.139/TS 24.008: SM cause IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 404

表表表表 10.5.157/TS 24.008: SM cause IE

Cause value (octet 2) Bits 8 7 6 5 4 3 2 1 0 0 0 1 1 0 0 1 LLC or SNDCP failure(GSM only) 0 0 0 1 1 0 1 0 Insufficient resources 0 0 0 1 1 0 1 1 Missing or unknown APN 0 0 0 1 1 1 0 0 Unknown PDP address or PDP type 0 0 0 1 1 1 0 1 User Aauthentication failed 0 0 0 1 1 1 1 0 Activation rejected by GGSN 0 0 0 1 1 1 1 1 Activation rejected, unspecified 0 0 1 0 0 0 0 0 Service option not supported 0 0 1 0 0 0 0 1 Requested service option not subscribed 0 0 1 0 0 0 1 0 Service option temporarily out of order 0 0 1 0 0 0 1 1 NSAPI already used (not sent) 0 0 1 0 0 1 0 0 Regular deactivation 0 0 1 0 0 1 0 1 QoS not accepted 0 0 1 0 0 1 1 0 Network failure 0 0 1 0 0 1 1 1 Reactivation required 0 0 1 0 1 0 0 1 Semantic error in the TFT operation 0 0 1 0 1 0 1 0 Syntactical error in the TFT operation 0 0 1 0 1 0 1 1 Unknown PDP context 0 0 1 0 1 1 1 0 PDP context without TFT already activated 0 0 1 0 1 1 0 0 Semantic errors in packet filter(s) 0 0 1 0 1 1 0 1 Syntactical errors in packet filter(s) 0 1 0 1 0 0 0 1 Invalid transaction identifier value 0 1 0 1 1 1 1 1 Semantically incorrect message 0 1 1 0 0 0 0 0 Invalid mandatory information 0 1 1 0 0 0 0 1 Message type non-existent or not implemented 0 1 1 0 0 0 1 0 Message type not compatible with the protocol state 0 1 1 0 0 0 1 1 Information element non-existent or not implemented 0 1 1 0 0 1 0 0 Conditional IE error 0 1 1 0 0 1 0 1 Message not compatible with the protocol state 0 1 1 0 1 1 1 1 Protocol error, unspecified Any other value received by the mobile station shall be treated as 0010 0010, 'Service option temporarily out of order'. Any other value received by the network shall be treated as 0110 1111, 'Protocol error, unspecified'. NOTE: The listed cause values are defined in Annex I

10.5.6.7 Linked TI

Linked TI IE の目的は、ネットワークが新しい PDP コンテキストを得られるように、PDP アドレスからアクティブな

PDP コンテキストを特定することにある。

Linked TI IE は、少長 3 オクテット、大長 4 オクテットの type 4 IE である。

Linked TI IE は、図 10.5.140/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Linked TI IEI octet 1 Length of Linked TI IE octet 2 TI flag TI value 0 0 0 0

Spare octet 3

1 EXT TI value octet 4

図図図図 10.5.140/TS 24.008: Linked TI IE

TI フラグ、TI の値、いよび EXT ビットのコーディングについては、TS 24.007[20]で定義される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 405

10.5.6.8 Spare

10.5.6.9 LLC service access point identifier

LLC service access point identifier IE の目的は、LLC レイヤにおいて GPRS データ送信用に使用される SAP を

指定することにある。

LLC service access point identifier は、2 オクテット長の type 3 IE である。

LLC service access point identifier IE は、図 10.5.141/TS 24.008 および表 10.5.159/TS 24.008 に示すようにエ


8 7 6 5 4 3 2 1 LLC SAPI IEI octet 1

0 0 0 0 Spare

LLC SAPI value

octet 2

図図図図 10.5.141/TS 24.008: LLC service access point identifier IE

表表表表 10.5.159/TS 24.008: LLC service access point identifier IE

LLC SAPI value (octet 2) Bit 4 3 2 1 0 0 0 0 LLC SAPI not assigned 0 0 1 1 SAPI 3 0 1 0 1 SAPI 5 1 0 0 1 SAPI 9 1 0 1 1 SAPI 11 All other values are reserved.

10.5.6.10 Tear down indicator

tear down indicator IE の目的は、特定の TI に関連付けられた PDP コンテキストだけを不活性化すべきか、または

その特定の TI に関連付けられた PDP コンテキストと同じ PDP アドレスを共有する全てのアクティブな PDP コンテ

キストを不活性化すべきかを通知することにある。

tear down indicator IE は type 1 IE である。

tear down indicator IE は、図 10.5.142/TS 24.008 および表 10.5.160/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 Tear down indicator

IEI 0 0 0

spare TDI flag

octet 1

図図図図 10.5.142/TS 24.008: Tear down indicator IE

表表表表 10.5.160/GSM 04.08: Tear down indicator IE

Tear down indicator(TDI) flag (octet 1) Bit 1 0 tear down not requested 1 tear down requested

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 406


Packet Flow Identifier (PFI) IE は、Packet Flow Context 用の Packet Flow Identifier を示す。

Packet Flow Identifier (PFI) IE は、3 オクテット長の type 4 IE である。

Packet Flow Identifier (PFI) IE は、図 10.5.143/TS 24.008 および表 10.5.161/TS 24.008 に示すようにエンコード

される。

8 7 6 5 4 3 2 1 Packet Flow Identifier IEI octet 1 Length of Packet Flow Identifier IE octet 2 Spare

0

Packet Flow Identifier value

octet 3

図図図図 10.5.143/TS 24.008: Packet Flow Identifier IE

表表表表 10.5.161/TS 24.008: Packet Flow Identifier IE

Packet Flow Identifier value (octet 3) Bits 7 6 5 4 3 2 1 0 0 0 0 0 0 0 Best Effort 0 0 0 0 0 0 1 Signaling 0 0 0 0 0 1 0 SMS 0 0 0 0 0 1 1 } to } reserved 0 0 0 0 1 1 1 } 0 0 0 1 0 0 0 } to } dynamically assigned 1 1 1 1 1 1 1 }

10.5.6.12 Traffic Flow Template

traffic flow template IE の目的は、TFT パラメータと PDP コンテキスト用のオペレーションを特定することにある。

traffic flow template IE は、少長 3 オクテット、大長 257 オクテットの type 4 IE である。

NOTE: IE の長さ制限は、単一オクテット内にエンコードできる大長によるものである。

NOTE: IPv4 パケットフィルタの大長は 32 バイトである。それゆえに、7 つの大サイズの IPv4 パケットフィ

ルタと、大 30 オクテットを含む終パケットフィルタを足したものが、1 つの TFT 上にフィットできる。

つまり、必要ならば一部のパケットフィルタコンポーネントを 1 メッセージとして定義することができる。

大サイズの Ipv6 パケットフィルタは 60 バイトであるから、大サイズの Ipv6 パケットフィルタは 4つまでしか 1TFT 上にフィットしない。しかし、"Add packet filters to existing TFT"を使用することによ

って、大サイズの IPv4／Ipv6 パケットフィルタを 8 つまで含む TFT を生成することができる。

traffic flow template IE は、図 10.5.144/TS 24.008 および表 10.5.162/TS 24.008 に示すようにエンコードされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 407

8 7 6 5 4 3 2 1 Traffic flow template IEI Octet 1 Length of traffic flow template IE Octet 2 TFT operation code Spare

0 Number of packet filters Octet 3

Packet filter list

Octet 4 Octet z

図図図図 10.5.144/TS 24.008: Traffic flow template IE

8 7 6 5 4 3 2 1 Packet filter identifier 1 Octet 4 Packet filter identifier 2 Octet 5 … Packet filter identifier N Octet N+3

図図図図 10.5.144a/TS 24.008: Packet filter list when the TFT operation is "delete packet filters from existing

TFT" (z=N+3)

8 7 6 5 4 3 2 1 Packet filter identifier 1 Octet 4 Packet filter evaluation precedence 1 Octet 5 Length of Packet filter contents 1 Octet 6 Packet filter contents 1 Octet 7

Octet m Packet filter identifier 2 Octet m+1 Packet filter evaluation precedence 2 Octet m+2 Length of Packet filter contents 2 Octet m+3 Packet filter contents 2 Octet m+4

Octet n … Octet n+1

Octet y Packet filter identifier N Octet y+1 Packet filter evaluation precedence N Octet y+2 Length of Packet filter contents N Octet y+3 Packet filter contents N Octet y+4

Octet z 図図図図 10.5.144b/TS 24.008: Packet filter list when the TFT operation is "create new TFT", or "add packet

filters to existing TFT" or "replace packet filters in existing TFT"

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 408

表表表表 10.5.162/TS 24.008: Traffic flow template IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 409

TFT operation code (octet 3) Bits 8 7 6

0 0 0 Spare 0 0 1 Create new TFT

0 1 0 Delete existing TFT 0 1 1 Add packet filters to existing TFT

1 0 0 Replace packet filters in existing TFT

1 0 1 Delete packet filters from existing TFT 1 1 0 Reserved

1 1 1 Reserved

Number of packet filters (octet 3)

The number of packet filters contains the binary coding for the number of packet filters in the packet filter list. The number of packet filters field is encoded in bits 4 through 1 of octet 3 where bit 4 is the most significant and bit 1 is the least significant bit. For the "delete existing TFT" operation, the number of packet filters shall be coded as 0. For all other operations, the number of packet filters shall be greater than 0 and less than or equal to 8.

Packet filter list (octets 4 to z)

The packet filter list contains a variable number of packet filters. For the "delete existing TFT" operation, the packet filter list shall be empty.

For the "delete packet filters from existing TFT" operation, the packet filter list shall contain a variable number of packet filter identifiers. This number shall be derived from the coding of the number of packet filters field in octet 3.

For the "create new TFT", "add packet filters to existing TFT" and "replace packet filters in existing TFT" operations, the packet filter list shall contain a variable number of packet filters. This number shall be derived from the coding of the number of packet filters field in octet 3.

Each packet filter is of variable length and consists of

- a packet filter identifier (1 octet); - a packet filter evaluation precedence (1 octet); - the length of the packet filter contents (1 octet); and - the packet filter contents itself (v octets).

The packet filter identifier field is used to identify each packet filter in a TFT. Since the maximum number of packet filters in a TFT is 8, only the least significant 3 bits are used. Bits 8 through 4 are spare bits.

The packet filter evaluation precedence field is used to specify the precedence for the packet filter among all packet filters in all TFTs associated with this PDP address. Higher the value of the packet filter evaluation precedence field, lower the precedence of that packet filter is. The first bit in transmission order is the most significant bit.

The length of the packet filter contents field contains the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order is the most significant bit.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 410

表表表表 10.5.162/TS 24.008 (continued): Traffic flow template IE

The packet filter contents field is of variable size and contains a variable number (at least one) of packet filter components. Each packet filter component shall be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier shall be transmitted first. In each packet filter, there shall not be more than one occurrence of each packet filter component type. Among the "IPv4 source address type" and "IPv6 source address type" packet filter components, only one shall be present in one packet filter. Among the "single destination port type" and "destination port range type" packet filter components, only one shall be present in one packet filter. Among the "single source port type" and "source port range type" packet filter components, only one shall be present in one packet filter. Packet filter component type identifier Bits 8 7 6 5 4 3 2 1 0 0 0 1 0 0 0 0 IPv4 source address type 0 0 1 0 0 0 0 0 IPv6 source address type 0 0 1 1 0 0 0 0 Protocol identifier/Next header type 0 1 0 0 0 0 0 0 Single destination port type 0 1 0 0 0 0 0 1 Destination port range type 0 1 0 1 0 0 0 0 Single source port type 0 1 0 1 0 0 0 1 Source port range type 0 1 1 0 0 0 0 0 Security parameter index type 0 1 1 1 0 0 0 0 Type of service/Traffic class type 1 0 0 0 0 0 0 0 Flow label type All other values are reserved. For "IPv4 source address type", the packet filter component value field shall be encoded as a sequence of a four octet IPv4 address field and a four octet IPv4 address mask field. The IPv4 address field shall be transmitted first. For "IPv6 source address type", the packet filter component value field shall be encoded as a sequence of a sixteen octet IPv6 address field and a sixteen octet IPv6 address mask field. The IPv6 address field shall be transmitted first. For "Protocol identifier/Next header type", the packet filter component value field shall be encoded as one octet which specifies the IPv4 protocol identifier or IPv6 next header. For "Single destination port type" and "Single source port type", the packet filter component value field shall be encoded as two octet which specifies a port number. For "Destination port range type" and "Source port range type", the packet filter component value field shall be encoded as a sequence of a two octet port range low limit field and a two octet port range high limit field. The port range low limit field shall be transmitted first. For "Security parameter index", the packet filter component value field shall be encoded as four octet which specifies the IPSec security parameter index. For "Type of service/Traffic class type", the packet filter component value field shall be encoded as a sequence of a one octet Type-of-Service/Traffic Class field and a one octet Type-of-Service/Traffic Class mask field. The Type-of-Service/Traffic Class field shall be transmitted first. For "Flow label type", the packet filter component value field shall be encoded as three octet which specifies the IPv6 flow label. The bits 8 through 5 of the first octet shall be spare whereas the remaining 20 bits shall contain the IPv6 flow label.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 411

10.5.7 GPRS Common information elements

10.5.7.1 Void

10.5.7.2 Radio priority

radio priority IE の目的は、MS が PDP コンテキストまたはモバイル発 SMS 送信に関係するデータの送信用に、下

位レイヤで使用すべき優先度レベルを指定することにある。

radio priority IE は、図 10.5.145/TS 24.008 および表 10.5.161/TS 24.008 に示すようにエンコードされる。

radio priority IE は type 1 IE である。

8 7 6 5 4 3 2 1 Radio priority IEI

0

spareRadio priority

level value octet 1

図図図図 10.5.145/TS 24.008: Radio priority IE

表表表表 10.5.161/TS 24.008: Radio priority IE

Radio priority level value (octet 1) Bits 3 2 1 0 0 1 priority level 1 (highest) 0 1 0 priority level 2 0 1 1 priority level 3 1 0 0 priority level 4 (lowest) All other values are interpreted as priority level 4 by this version of the protocol.

10.5.7.3 GPRS Timer

GPRS timer IE は、GPRS 固有のタイマ、例えば READY タイマなどの値を指定するために使用される。

GPRS timer IE は、2 オクテット長の type 3 IE である。

GPRS timer IE は、図 10.5.146/TS 24.008 および表 10.5.162/TS 24.008 に示すようにエンコードされる。

8 7 6 5 4 3 2 1 GPRS Timer IEI octet 1 Unit Timer value octet 2

図図図図 10.5.146/TS 24.008: GPRS Timer value IE

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 412

表表表表 10.5.162/TS 24.008: GPRS Timer value IE

Timer value (octet 2) Bits 5 to 1 represent the binary coded timer value. Bits 6 to 8 defines the timer value unit for the GPRS timer as follows: Bits 8 7 6 0 0 0 value is incremented in multiples of 2 seconds 0 0 1 value is incremented in multiples of 1 minute 0 1 0 value is incremented in multiples of decihours 1 1 1 value indicates that the timer is deactivated. Other values shall be interpreted as multiples of 1 minute in this version of the protocol.

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 413

11 List of system parameters（システムパラメータのリスト）

以下の表中のタイマに関する説明は、簡単な要約として見なすこと。正確な詳細は第 3 章～第 6 章に記載されてお

り、それらが終的な説明である。

11.1 Timers and counters for radio resource management （RR管理用タイマとカウンタ）

04.18 参照。

11.2 Timers of mobility management（MM用タイマ）表表表表 11.1/TS 24.008: Mobility management timers - MS-side

TIMER NUM.

MM STAT

TIME OUT VAL.

CAUSE FOR START

NORMAL STOP AT THE EXPIRY

T3210 3 20s - LOC_UPD_REQ sent

- LOC_UPD_ACC - LOC_UPD_REJ - AUTH_REJ - Lower layer

failure

Start T3211

T3211 1 2

15s - LOC_UPD_REJ with cause#17 netw. failure

- lower layer failure or RR conn. released after RR conn. abort during loc. updating

- Time out - cell change - request for MM

connection establishment

- change of LA

Restart the Location update proc.

T3212 1, 2

Note 1

- termination of MM service or MM signalling

- initiation of MM service or MM signalling

initiate periodic updating

T3213 1 2

11

4s - location updating failure

- expiry - change of BCCH

parameter

new random attempt

T3214 3 5 7

20s AUTHENT FAILURE

Cause = MAC failure sent

AUTHENT REQ - received

Consider the network as ’false’ (see 4.3.2.6.1)

T3216 3 5 7

15s AUTHENT FAILURE

Cause = Synch failure sent

AUTHENT REQ received

Consider the network as ’false’ (see 4.3.2.6.1)

T3220 7 5s - IMSI DETACH - release from RM-sublayer

enter Null or Idle, ATTEMPTING TO UPDATE

T3230 5 15s - CM SERV REQ CM REEST REQ

- Cipher mode setting

- CM SERV REJ - CM SERV ACC

provide release ind.

T3240 9 10

10s see section 11.2.1 see section 11.2.1 abort the RR connection

NOTE 1: タイムアウト値は SYSTEM INFORMATION メッセージ内でブロードキャストされる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 414

表表表表 11.2/TS 24.008: Mobility management timers - network-side

TIMER NUM.

MM ST AT

TIMEOUTVAL.

CAUSE FOR START

NORMAL STOP AT THE EXPIRY

AT THE SECOND EXPIRY

T3250 6 12s TMSI-REAL-CMD or LOC UPD ACC with new TMSI sent

TMSI-REALL-COM received

Optionally Release RR connection

T3255 Note LOC UPD ACC sent with"Follow on Proceed"

CM SERVICE REQUEST

Release RR Connection or use for mobile station terminating call

T3260 5 12s AUTHENT-REQUEST sent

AUTHENT-RESPONSE received

AUTHENT-

FAILURE received


T3270 4 12s IDENTITY REQUEST sent

IDENTITY RESPONSE received


NOTE 2: 本タイマの値は本勧告では規定されない。

11.2.1 Timer T3240 MS が以下の状態になったとき、タイマ T3240 が起動する：

- セクション 4.4.4.6 および 4.4.4.8 で規定されるケースで位置登録更新処理が完了し、MS が LOCATION UPDATING ACCEPT メッセージを受信したとき

- セクション 4.4.4.7 で規定されるケースで、MS が LOCATION UPDATING REJECT メッセージを受信したと

き

- セクション 4.5.1.7 で規定されるケースで、MS が CM SERVICE ABORT メッセージを送信したとき

- セクション 4.3.2.5, 4.3.5.2, 4.5.1.1 および 4.5.3.1 で規定されるケースで、MS が全ての MM コネクションを

開放または中断したとき

MM メッセージ受信時に、タイマ T3240 は停止し、リセットされ、再開される。

CM コネクション確立を開始するタイマ CM メッセージ（TS 24.008, TS 24.010 または GSM 04.11 で定義される適

切な SETUP, REGISTER, または CP-DATA メッセージ）受信時に、タイマ T3240 は停止し、リセットされる（しかし

再開はされない）。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 415

11.2.2 Timers of GPRS mobility management （GPRSモビリティ管理のタイマ）

表表表表 11.3/TS 24.008: GPRS Mobility management timers - MS side

TIMER NUM.

TIMER VALUE

STATE CAUSE OF START NORMAL STOP ON THE 1st , 2nd, 3rd , 4th

EXPIRY Note 3 T3310 15s GMM-

REG-INIT ATTACH REQ sent ATTACH ACCEPT

received ATTACH REJECT received

Retransmission of ATTACH REQ

T3311 15s GMM-DEREG ATTEMPTING TO ATTACH or

GMM-REG ATTEMPTING TO UPDATE

ATTACH REJ with other cause values as described in chapter 'GPRS Attach' ROUTING AREA UPDATE REJ with other cause values as described in chapter 'Routing Area Update' Low layer failure

Change of the routing area

Restart of the Attach or the RAU procedure with updating of the relevant attempt counter

T3318 20s GMM- REG-INIT

GMM-REG GMM-DEREG-

INIT GMM-RA-

UPDATING-INT GMM-SERV-

REQ-INIT (UMTS only)

AUTHENTICATION & CIPHERING FAILURE (cause=MAC failure) sent

AUTHENTICATION & CIPHERING REQUEST received

On first expiry, the MS should consider the network as false (see 4.7.7.6.1)

T3320 15s GMM- REG-INIT

GMM-REG GMM-DEREG-

INIT GMM-RA-

UPDATING-INT GMM-SERV-

REQ-INIT (UMTS only)

AUTHENTICATION & CIPHERING FAILURE (cause=synch failure) sent

AUTHENTICATION & CIPHERING REQUEST received

On first expiry, the MS should consider the network as false (see 4.7.7.6.1)

T3321 15s GMM- DEREG-INIT

DETACH REQ sent DETACH ACCEPT received

Retransmission of the DETACH REQ

T3330 15s GMM-ROUTING-

UPDATING-INITIATED

ROUTING AREA UPDATE REQUEST sent

ROUTING AREA UPDATE ACC received ROUTING AREA UPDATE REJ received

Retransmission of the ROUTING AREA UPDATE REQUEST message

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 416

表表表表 11.3a/TS 24.008: GPRS Mobility management timers – MS side

TIMER NUM.

TIMER VALUE

STATE CAUSE OF START NORMAL STOP ON EXPIRY

T3302 Default 12 min Note 1

GMM-DEREG or

GMM-REG

At attach failure and the attempt counter is greater than or equal to 5. At routing area updating failure and the attempt counter is greater than or equal to 5.

At successful attach At successful routing area updating

On every expiry, initiation of the GPRS attach procedure or RAU procedure

T3312 Default 54 min Note1

GMM-REG In GSM, when READY state is left.In UMTS, when PMM-CONNECTED mode is left.

When entering state GMM-DEREG

Initiation of the Periodic RAU procedure

T3314 READY

(GSM only)

Default 44 sec Note 2

All except GMM-DEREG

Transmission of a PTP PDU Forced to Standby No cell-updates are performed

T3317 (UMTS only)

10s GMM-SERVICE-REQUEST-INITIATED

SERVICE REQ sent Security mode control procedure is completed, SERVICE ACCEPT received, or SERVICE REJECT received

Abort the procedure

NOTE 1: 本タイマの値は、ネットワークが GMM シグナリング処理の中で他の値を通知しなかった場合に使用さ

れる。

NOTE 2: 本タイマのデフォルト値は、MS もネットワークは他の値を送信しなかった場合、またはネットワーク側

がこの値をシグナリング処理の中で送信した場合に、使用される。

NOTE 3: 通常、関連するタイマが 5 回目に満了時に処理は中断される。例外ケースについては、対応する処理

の説明の箇所に説明される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 417

表表表表 11.4/TS 24.008: GPRS Mobility management timers - network side

TIMER NUM.

TIMER VALUE


EXPIRY Note 3 T3322 6s GMM-

DEREG-INIT DETACH REQ sent DETACH ACCEPT

received Retransmission of DETACH REQUEST

T3350 6s GMM-COMMON-PROC-INIT

ATTACH ACCEPT sent with P-TMSI and/or TMSI RAU ACCEPT sent with P-TMSI and/or TMSI P-TMSI REALLOC COMMAND sent

ATTACH COMPLETE received RAU COMPLETE received P-TMSI REALLOC COMPLETE received

Retransmission of the same message type, i.e. ATTACH ACCEPT, RAU ACCEPT or REALLOC COMMAND

T3360 6s GMM- COMMON-PROC-INIT

AUTH AND CIPH REQUEST sent

AUTH AND CIPH RESPONSE received AUTHENT- AND CIPHER- FAILURE received

Retransmission of AUTH AND CIPH REQUEST

T3370 6s GMM-COMMON-PROC-INIT

IDENTITY REQUEST sent IDENTITY RESPONSE received

Retransmission of IDENTITY REQUEST

表表表表 11.4a/TS 24.008: GPRS Mobility management timers - network side

TIMER NUM.

TIMER VALUE

STATE CAUSE OF START NORMAL STOP ON EXPIRY

T3313 Note1 GMM_REG Paging procedure initiated Paging procedure completed

Network dependent

T3314 READY

(GSM only)

Default 44 sec Note 2


Receipt of a PTP PDU Forced to Standby The network shall page the MS if a

PTP PDU has to be sent to the MS

Mobile Reachable

Default 4 min greater than T3312


In GSM, change from READY to STANDBY state

In UMTS, change from PMM-CONNECTED mode to PMM-IDLE

mode.

PTP PDU received Network dependent but typically paging

is halted on 1st expiry

NOTE 1: 本タイマの値はネットワーク依存。

NOTE 2: 本タイマのデフォルト値は、MS もネットワークは他の値を送信しなかった場合、またはネットワーク側

がこの値をシグナリング処理の中で送信した場合に、使用される。本タイマの値は、MS 側よりもネット

ワーク側のほうが若干短いこと。これはネットワーク実装上の問題。

NOTE 3: 通常、関連するタイマが 5 回目に満了時に処理は中断される。例外ケースについては、対応する処理

の説明の箇所に説明される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 418

11.2.3 Timers of session management(SM用タイマ)

表表表表 11.2c/TS 24.008: Session management timers - MS side

TIMER NUM.

TIMER VALUE


EXPIRY T3380 30s PDP-

ACTIVE-PEND ACTIVATE PDP CONTEXT REQUEST or ACTIVATE SECONDARY PDP CONTEXT REQUEST sent

ACTIVATE PDP CONTEXT ACCEPT or ACTIVATE SECONDARY PDP CONTEXT ACCEPT received ACTIVATE PDP CONTEXT REJECT or ACTIVATE SECONDARY PDP CONTEXT REJECT received

Retransmission of ACTIVATE PDP CONTEXT REQ or ACTIVATE SECONDARY PDP CONTEXT REQUEST

T3381 8s PDP-MODIFY-PENDING

MODIFY PDP CONTEXT REQUEST sent

MODIFY PDP CONTEXT ACCEPT received

Retransmission of MODIFY PDP CONTEXT REQUEST

T3390 8s PDP- INACT-PEND

DEACTIVATE PDP CONTEXT REQUEST sent

DEACTIVATE PDP CONTEXT ACC received

Retransmission of DEACTIVATE PDP CONTEXT REQUEST

NOTE: 通常、関連するタイマが5回目に満了時に処理は中断される。例外ケースについては、対応する処理の説明の箇所に説明される。

表表表表 11.2d/TS 24.008: Session management timers - network side

TIMER NUM.

TIMER VALUE


EXPIRY T3385 8s PDP-

ACT-PEND REQUEST PDP CONTEXT ACTIVATION sent

ACTIVATE PDP CONTEXT REQ received

Retransmission of REQUEST PDP CONTEXT ACTIVATION

T3386 8s PDP- MOD-PEND

MODIFY PDP CONTEXT REQUEST sent

MODIFY PDP CONTEXT ACC received

Retransmission of MODIFY PDP CONTEXT REQ

T3395 8s PDP- INACT-PEND

DEACTIVATE PDP CONTEXT REQUEST sent

DEACTIVATE PDP CONTEXT ACC received

Retransmission of DEACTIVATE PDP CONTEXT REQ

NOTE: 通常、関連するタイマが 5 回目に満了時に処理は中断される。例外ケースについては、対応する処理の説明の箇所

に説明される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 419

11.3 Timers of circuit-switched call control （CS呼制御用タイマ）

表表表表 11.3/TS 24.008: Call control timers - MS side

TIM NUM

.

TIM VAL

STATE OF CALL

CAUSE OF START

NORMAL STOP

AT FIRST EXPIRY

AT SECOND EXPIRY

T303 30s Call initiated

CM SER RQ sent

CALL PROC, or REL COMP received

Clear the call Timer is not restarted

T305 30s Disconnect Request

DISC sent REL or DISC received

REL sent. Timer is not restarted

T308 30s Release request

REL sent REL COMP or REL received

Retrans. RELEASE restart T308

Call ref. release

T310 Note

1

30s Outgoing call

Proceeding

CALL PROC received

ALERT,CONN, DISC or PROG rec.

Send DISC Timer is not restarted

T313 30s Connect Request

CONN sent CONNect ACKnowledge received

Send DISC Timer is not restarted

T323 30s Modify Request

MOD sent MOD COMP or MOD REJ received


T332 30s Wait for network

info

START_CC sent

CC-EST. received


T335 30s CC-Est. Confirmed

CC-EST CONF.sent

RECALL received


T336 10s START DTMF sent

START DTMF ACK or START DTMF REJECT received

Timer is not restarted

The MS considers the DTMF Procedure (for the digit) to be terminated

T337 10s STOP DTMF sent

STOP DTMF ACK received

The MS considers the DTMF procedure (for the current digit) to be terminated


NOTE 1: CALL PROCEEDING メッセージ内、またはその前の PROGRESS メッセージ内で progress indicator #1, #2 また

は #64 が配送された場合には、T310 は起動しない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 420

表表表表 11.4/TS 24.008: Call control timers - network side

TIM NUM

.

DFT TIM VAL

STATE OF CALL

CAUSE FOR START

NORMAL STOP

AT FIRST EXPIRY

AT SECOND EXPIRY

T301 Note

1

Min180s

Call received

ALERT received

CONN received


T303 Note 2

Call present

SETUP sent CALL CONF or REL COMP received


T305 30s Disconnect Indication

DISC without progress indic. #8 sent or CCBS Possible

REL or DISC received

Network sends RELEASE


T306 30s Disconnect Indication

DISC with progress indic. #8 sent but no CCBS possible


Stop the tone/ announc. Send REL


T308 Note 2

Release request

REL sent REL COMP or REL received

Retrans. RELEASE restart T308

Release call reference

T310 Note 2

Incoming call

proceeding

CALL CONF received

ALERT, CONN or DISC received


T313 Note 2

Connect Indication

CON sent CON ACK received


T323 30s Modify request

MOD sent MOD COMP or MOD REJ received


T331 Note 2

CC Connec. Pending

CM-SERV PROMPT sent

START CC received


T333 Note 2

CC-Est. Present

START CC received

CC-EST.CONF or REL COMP received


T334 Note

3

Min 15s

CC-Est. Confirmed

RECALL sent SETUP received


T338 Note 2

Disconnect indication

DISC with CCBS possible


stop any tone/ announc. Send REL


NOTE 1: 例えば呼制御に組み込むことによって、ネットワークは事前に内部アラート監視機能を適用することも

できる。そのような機能が呼でオペレーションされているｋとが分かっている場合には、タイマ T301 は

使用されない。

NOTE 2: これらのタイマの値は、ネットワークオペレータによって設定される。

NOTE 3: 付加サービス CCBS に対して適用される場合には、タイマ T334 は、再開タイマ T4 または通知タイマ

T10 のいずれかを表すことができる（GSM 03.93 参照）。このように、タイマ T334 は 2 つの異なる値

をとることができる。これらの値の範囲については、GSM 03.93 で定義される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 421

Annex A (informative): Example of subaddress information element coding （subaddress IEのコーディング例）

本 Annex は informative である。

本 Annex は、IA5 キャラクタを使用したサブアドレスの桁を伝送するための、Called Party Subaddress IE のエンコ

ード例について説明する。本例は、Calling Party Subaddress IE についても適用可能である。

8 7 6 5 4 3 2 1 octet 0 1 1 0 1 1 0 1 1 called party subaddress IEI

0 0 0 0 0 1 1 1 2 Length

1 0 0 0 X 0 0 0 3 not ext

NSAP (X.213/ISO 8348 AD2)

odd/evnote 1

note 2

0 1 0 1 0 0 0 0 4 AFI (note 3)

IA5 Character (note 4) 5 IA5 Character (note 4) 6

IA5 Character (note 4) 9

NOTE 1: subaddress のタイプが"NSAP"の場合、本ビットの値は意味を持たない

NOTE 2: これらのビットはスペア

NOTE 3: （BCD 内の）Authority and Format Identifier code 50 は、subaddress が IA5 キャラクタから構成さ

れていることを示す（ISO 標準 8348 AD2 参照）

NOTE 4: IA5 キャラクタは ITU-T 勧告 T.50/ISO 646 で定義されており、X.213/ISO 8348 AD2 で定義される"preferred binary encoding"に従って、2 つのセミオクテットにエンコードされる（各キャラクタは、0 パリティで

MSP（most significant position）内にパリティビットが置かれ、ISO 646 エンコードを使用して 32～127 の

範囲内の数にコンバートされる。その数は次に 32 を引かれて、0～95 までの新しい値になる。新しい

値は次に、1 セミオクテット内にエンコードされた各桁の値といっしょに、10 進数のペアとして扱われる）。

NOTE 5: subaddress 内の IA5 キャラクタの数値は異なる場合がある。19 の IA5 キャラクタの上限に制約され

る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 422

Annex B (normative): Compatibility checking（互換性チェック）

本 Annex は normative である。

B.1 Introduction（導入）本 Annex は、MS とネットワークのケーパビリティが PLMN と ISDN 間の呼として適化されるために実行される各

種の互換性チェックについて説明する。

互換性チェックでは、以下の 3 つのプロセスが実行されること。

i) ユーザ→ネットワークのインタフェース、発呼側（B.2 参照）

ii) ネットワーク→ユーザのインタフェース、着呼側（B.3.2 参照）

iii) ユーザ→ユーザ（B.3 参照）

NOTE: 本コンテンツと本 Annex 内で使用される用語、「着信ユーザ」（"called user"）とは、明示的に指定される

エンドポイントエンティティである。

互換性チェック用に要求される情報のコーディング詳細については、annex C 参照。

B.2 Calling side compatibility checking （発呼側の互換性チェック）

B.2.1 Compatibility checking of the CM SERVICE REQUEST message （CM SERVICE REQUESTメッセージの互換性チェック）

ネットワークは、CM SERVICE REQUEST メッセージ内で要求されたサービスが、該当加入者に対して許容されて

いることをチェックすること。

B.2.2 Compatibility/Subscription checking of the SETUP message （SETUPメッセージの互換性／加入者チェック）

発信側では、ネットワークは発呼中 MS が Bearer Capability IE 内で要求する基本サービスが、PLMN が該当加入

者に提供する基本サービスにマッチしていることをチェックする。 SETUP メッセージに含まれる bearer capability IEのうちたとえ 1 つでもミスマッチが検出されたならば、ネットワークは以下の処理を進めること。

- SETUP メッセージに 2 つの bearer capability IE が含まれ、そのうち 1 つだけにミスマッチが検出された場

合には、ネットワークは以下のいずれかの処理を行なうこと。

- TS 27.001 内で規定される条件下(例えば TS 61 と TS 62)では、ミスマッチが検出されなかった方の

bearer capability IE を含む CALL PROCEEDING メッセージを持って、SETUP メッセージを受け付ける。

ネゴシエーションも可能。

- annex H にリストアップされた理由の 1 つを使用して、呼を拒否する。

- 上記以外の場合には、annex H にリストアップされた理由の 1 つを使用して、ネットワークは呼を拒否するこ

と。

ネットワークサービスについては、TS 22.002 および GSM 02.03 内でそれぞれベアラサービスとテレサービスにつ

いて説明されている。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 423

B.3 Called side compatibility checking （着信側の互換性チェック）

本セクションでは、「チェック」（"check"）という言葉は、MS が特定の IE のコンテンツの内容を調べることを意味する。

B.3.1 Compatibility checking with addressing information （アドレス情報との互換性チェック）

着信 SETUP メッセージが、アドレス情報（つまり、サブアドレスまたは着信パーティ番号）といっしょに MS に提供さ

れた場合には、以下のようにすること。

a) MS が DDI 番号またはサブアドレスを持つ場合には、着信 SETUP メッセージの Called Party BCD Number IE のいずれか、または Called Party subaddress IE のいずれかの中の情報が、ユーザに対して割当てられ

た番号（DDI など）の関連パート、またはユーザ自身のサブアドレスと矛盾しないか、MS はチェックすること。

ミスマッチが検出された場合には、MS は呼を開放すること。マッチした場合には、B.3.2 および B.3.3 内で説

明された互換性チェックを実行すること。

b) MS が DDI 番号もサブアドレスも持たない場合には、Called Party BCD Number と Called Party Sub-address を互換性チェックの対象から外すこと。B.3.2 および B.3.3 で説明される互換性チェックを実行するこ

と。

NOTE: ユーザの要求に基づき、互換性チェックは実行順序およびチェックすべき情報という観点から、さまざ

まな方法で実行することが可能である。例えば、初に DDI 番号／サブアドレスをチェックし、その後

にベアラケーパビリティをチェックしたり、その逆にするなど。

B.3.2 Network-to-MS compatibility checking （ネットワーク→MSの互換性チェック）

着信側でネットワークが基本サービスを提供する際、MS は Bearer Capability IE 内でネットワークから提示された

基本サービスが、MS がサポートできる基本サービスとマッチするかをチェックすること。ミスマッチが検出されたなら

ば、MS は以下の処理を進めること。

- SETUP メッセージに 2 つの bearer capability IE が含まれ、そのうち 1 つだけにミスマッチが検出された場

合には、MS は以下のいずれかの処理を行なうこと。

- TS 27.001 内で規定される条件下(例えば TS 61 と TS 62)では、ミスマッチが検出されなかった方の

bearer capability IE を含む CALL CONFIRMED メッセージを持って、SETUP メッセージを受け付ける。

ネゴシエーションも可能。

- cause No. 88 "incompatible destination"を使用して呼を拒否する。

- 上記以外の場合には、cause No. 88 "incompatible destination"といっしょにを RELEASE COMPLETE メッ

セージを使用して、MS は呼を拒否すること。

既存ネットワークとのインターワーキング時、ネットワークまたは遠隔ユーザシグナリング内の制限（PSTN またはア

ナログ端末から着信した場合など）により、着呼 MS が利用可能な情報が制限されることがある（例えば Bearer Capability IE または High Layer Compatibility IE の欠落など）。そのような呼の互換性チェック時の処理について

は、TS 27.001 参照。

B.3.3 User-to-User compatibility checking （ユーザ→ユーザ互換性チェック）

TS 27.001 参照

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 424

B.4 High layer compatibility checking （上位レイヤ互換性チェック）

TS 27.001 参照

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 425

Annex C (normative): Low layer information coding principles （下位レイヤ情報コーディングの原則）

本 Annex は normative である。

C.1 Purpose（目的）本 Annex では、発信 MS が、ネットワークまたは着信端末において要求される下位レイヤ互換性の観点から、呼セ

ットアップ中に情報を規定する場合に使用されること。TS 27.001 も併せて参照のこと。

NOTE: 本コンテキストおよび本 Annex を通じて、用語「着信ユーザ」（"called user"）とは、明示的に指定されるエ

ンドポイントエンティティを指す。本用語は、明示的に指定された IWU（interworking unit）を指すこともある

（ITU-T I.500 シリーズ勧告および ITU-T 勧告 X.31 case a を参照）。

C.2 Principles（原則）

C.2.1 Definition of types of information（情報のタイプの定義）ネットワーク内および着信端末内で必要とされる下位レイヤケーパビリティを指定するために、呼セットアップ中に発

信側 PLMN ユーザが指定できる情報としては、次の異なる 3 つのタイプがある。

a) type I 情報は発信端末に関する情報であり、端末互換性を判定するために着信側エンドでのみ使用される。

その一例が、ユーザ情報 L3 プロトコルである。Type I 情報は、low layer compatibility IE の 5～7 オクテット

内にエンコードされる。

b) type II 情報は、発呼ユーザが接続するネットワーク（PLMN）だけが、PLMN 固有のネットワークリソース（チャ

ネルタイプやインターワーキング機能内の固有の機能（IWF、TS 09.07 参照））を選択するために使用する。

本情報タイプは常に存在する。その一例が connection element である。Type II の情報は、次の場所にコー

ディングされる。

i) 発信ユーザが要求する情報転送ケーパビリティが音声であった場合には、bearer capability IE のオクテ

ット 3

ii) 発信ユーザが要求する情報転送ケーパビリティが音声以外であった場合には、bearer capability IE のオ

クテット 3, 4, 5、そしてオプションとしてオクテット 7

c) type III 情報は、ネットワークが提供する基本サービスから基本サービスを選択するために要求される。着信

端末における端末互換性チェックと同様に適切なインターワーキング機能（IWF、TS 09.07 参照）を選択する

ための type II 情報といっしょに使用される。その一例が、情報転送ケーパビリティである。Type II の情報は

常に存在し、次の場所にコーディングされる。

i) 発信ユーザが要求する情報転送ケーパビリティが音声であった場合には、bearer capability IE のオクテ

ット 3

ii) 発信ユーザが要求する情報転送ケーパビリティが音声以外であった場合には、bearer capability IE のオ

クテット 3, 5, 6, 6a, 6b および 6c

C.2.2 Examination by network（ネットワークによる検証） Type I の情報はユーザ→ユーザである（つまり、発呼側ではネットワークによる検証は実行されない）。一方、type II および III の情報は、着信ユーザおよびネットワークによる検証が可能であること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 426

NOTE: MS 着信呼の場合、もし type II および III の情報が適切なインターワーキング機能を選択するために

は不十分であったならば、ネットワークは Type I の情報も検証する。

C.2.3 Location of type I information（Type Iの情報の位置） Type I の情報（つまり着信ユーザにとってのみ有意な情報）は、使用される場合には、low layer compatibility IE 内

に含まれること。

C.2.4 Location of types II and III information （type II および IIIの情報の位置）

Type II の情報は、bearer capability IE 内に含まれる。Type III の情報もまた、bearer capability IE 内に含まれる。

ネットワークは、（例えばインターワーキング機能を提供するために）Type III の情報を使用し修正することができる。

bearer capability IE の変更は ISDN などの固定網 NW に対してインターワーキングが必要となる。その場合無線インタフェースのシグナリングを固定網ネットワークシグナリングにマッピングすべきである（例え

ば GSM BCIE → ISDN BCIE へのマッピング、TS 29.007 参照）。

C.2.5 Relationship between bearer capability and low layer compatibility information elements （bearer capability IEと low layer compatibility IEの関係）

発信側では、bearer capability IE と low layer compatibility IE の間に情報の矛盾があってはならない。ただし、呼

が転送される過程でいくつかのベアラケーパビリティコードポイント（bearer capability code point）が修正される可

能性もあるので、本原則は bearer capability IE と low layer compatibility IE とで重複する情報を小限に留める

べきであることを意味する。

NOTE: 重複の結果、着信側で bearer capability IE と low layer compatibility IE の間に情報の矛盾が発生し

た場合、受信側エンティティは low layer compatibility IE 内の矛盾する情報を無視すること。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 427

Annex D (informative): Examples of bearer capability information element coding （bearer capability IEのエンコード例）


本 Annex は、各種テレコミニュケーションサービス用の bearer capability IE ののエンコード例を示す。本 Annex は、

あくまで informative である。本 Annex と TS 27.001 の記載の間で矛盾があった場合には、TS 27.001 の記載が

本 Annex よりも優先する。

D.1 Coding for speech for a full rate support only mobile station （フルレートの音声コーディングだけをサポートするMS）

D.1.1 Mobile station to network direction（MS→ネットワーク方向） 8 7 6 5 4 3 2 1 0 0 0 0 0 1 0 0 octet 1 Bearer capability IEI

0 0 0 0 0 0 0 1 Length of the bearer capability contents octet 2

1 0 1 0 0 0 0 0 not ext

full rate only

GSM circ. mode

speech octet 3

D.1.2 Network to mobile station direction（ネットワーク→MS方向） 8 7 6 5 4 3 2 1 0 0 0 0 0 1 0 0 octet 1 Bearer capability IEI


1 0 1 0 0 0 0 0 not ext

spare spare GSM circ. mode

speech octet 3

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 428

D.2 An example of a coding for modem access with V22-bis, 2.4 kbit/s, 8 bit no parity （V22-bis, 2.4 kbit/s, 8ビットノンパリティのモデムアクセス用エンコード例）

D.2.1 Mobile station to network direction, data compression allowed （MS→ネットワーク方向、データ圧縮許可）

8 7 6 5 4 3 2 1 0 0 0 0 0 1 0 0 octet 1 Bearer capability IEI


1 1 0 0 0 0 1 0 not ext

dual, half preferred

GSM circ. mode

3.1 kHz audio ex PLMN

octet 3

1 1 0 0 1 0 0 0 not ext

comp-ress.

SDU integrity

full dupl.

pt to pt

no NIRR

de- mand

octet 4

1 0 0 0 0 0 0 1 not ext

access id. no rate adaption

I.440/450 octet 5

0 0 1 0 0 0 0 1 ext layer 1 default layer 1 async octet 6 0 0 0 1 0 0 1 1

ext 1 bit no neg

8 bits

2.4 kbit/s octet 6a

0 1 1 0 0 0 1 1 ext 16 kbit/s

inter. rate no

NICtxno

NICrx(parity) none octet 6b

1 0 1 0 0 0 1 1 not ext

non trans RLP)

V.22 bis octet 6c

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 429

D.2.2 Network to mobile station direction, data compression possible （ネットワーク→MS方向、データ圧縮可能）

8 7 6 5 4 3 2 1 0 0 0 0 0 1 0 0 octet 1 Bearer capability IEI


1 0 1 0 0 0 1 0 not ext



octet 3

1 1 0 0 1 0 0 0 not ext

comp-ress.

SDU integrity

full dupl.

pt to pt

no NIRR

de-mand

octet 4

1 0 0 0 0 0 0 1 not ext


I.440/450 octet 5

0 0 1 0 0 0 0 1 ext layer 1 default layer 1 async octet 6 0 0 0 1 0 0 1 1

ext 1 bit no neg

8 bits 2.4 kbit/s octet 6a

0 1 1 0 0 0 1 1 ext 16 kbit/s

inter. rate no

NICtxno


1 0 1 0 0 0 1 1 not ext

non trans (RLP)

V.22 bis octet 6c

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 430

D.3 An example of a coding for group 3 facsimile (9.6 kbit/s, transparent) （G3FAX用のコーディング例（9.6 kbit/s、トランスペアレント））

D.3.1 Mobile station to network direction（MS→ネットワーク方向） 8 7 6 5 4 3 2 1 0 0 0 0 0 1 0 0 octet 1 Bearer capability IEI


1 0 1 0 0 0 1 1 not ext

full rate only MS

GSM circ. mode

facsimile group 3

octet 3

1 0 1 1 1 0 0 0 not ext

comp-ress.

unstructured full dupl.

pt topt

no NIRR

de-mand

octet 4

1 0 0 0 0 0 0 1 not ext


I.440/450 octet 5

0 0 1 0 0 0 0 0 ext layer 1 default layer 1 sync octet 6 0 0 0 1 0 1 0 1

ext (syn) no neg

(syn) 9.6 kbit/s octet 6a

0 1 1 0 0 0 1 1 ext 16 kbit/s

inter. rate no

NICtxno


1 0 0 0 0 0 1 1 not ext

transparent none (modem type)

octet 6c

D.3.2 Network to mobile station direction（ネットワーク→MS方向） 8 7 6 5 4 3 2 1 0 0 0 0 0 1 0 0 octet 1 Bearer capability IEI


1 0 1 0 0 0 1 0 not ext



octet 3

1 0 1 1 1 0 0 0 not ext

comp-ress.

unstructured full dupl.

pt topt

no NIRR

de-mand

octet 4

1 0 0 0 0 0 0 1 not ext


I.440/450 octet 5

0 0 1 0 0 0 0 0 ext layer 1 default layer 1 sync octet 6 0 0 0 1 0 1 0 1

ext (syn) no neg

(syn) 9.6 kbit/s octet 6a

0 1 1 0 0 0 1 1 ext 16 kbit/s

inter. rate no

NICtxno


1 0 0 0 0 0 0 0 not ext

transparent none (modem type)

octet 6c

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 431

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 432

Annex E (informative): Comparison between call control procedures specified in TS 24.008 and ITU-T Recommendation Q.931 （TS 24.008と ITU-T 勧告 Q.931との呼制御処理との比較）


本 Annex は、ITU-T 勧告 Q.931（ブルーブック）で規定される呼制御処理と TS 24.008 で規定される呼制御処理と

を比較して要約したものである。

コメントがない場合には、ITU-T 勧告 Q.931 の仕様と TS 24.008 の仕様が類似していることを表す。しかし、そのよ

うな場合でも、処理の記述が 2 つのドキュメントでは若干異なることもあることに注意すること。

表表表表 E.1/TS 24.008: CS 呼制御処理（呼制御処理（呼制御処理（呼制御処理（Circuit-switched call control procedures））））

Procedure Q.931 GSM 24.008 Call establishment at the originating interface

5.1 5.2.1

- call request 5.1.1 5.2.1.1.1

en-bloc sending only - B-channel selection originating 5.1.2 not applicable - overlap sending 5.1.3 not supported - invalid call information 5.1.4 5.2.1.1.2 - call proceeding, en-bloc sending

5.1.5.1 5.2.1.1.3

- call proceeding, overlap sending

5.1.5.2 not supported

- notification of interworking at the originating interf.

5.1.6 5.2.1.1.4

- call confirmation indication 5.1.7 5.2.1.1.5 - call connected 5.1.8 5.2.1.1.6 - call rejection 5.1.9 5.2.1.1.7 - transit network selection 5.1.10 5.2.1.1.8

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 433

表表表表 E.1/TS 24.008: CS 呼制御処理（呼制御処理（呼制御処理（呼制御処理（Circuit-switched call control procedures）））） (続き続き続き続き)

Procedure Q.931 GSM 24.008 Call establishment at the destination interface

5.2 5.2.2

- call indication 5.2.1 5.2.2.1

procedure for multiple terminal configuration not required, i.e. delivery of SETUP messages on broadcast data links is not supported

- compatibility checking 5.2.2 5.2.2.2

equivalent, except that delivery of SETUP messages on broadcast data links is not supported

- B-channel selection destination 5.2.3 not applicable - overlap receiving 5.2.4 not supported - call confirmation information 5.2.5 5.2.2.3

equivalent, except that delivery of SETUP messages on broadcast data links is not supported

- notification of interworking at the terminating interf.

5.2.6 5.2.2.4

- call accept indication 5.2.7 5.2.2.5 - active indication 5.2.8 5.2.2.6

equivalent, except that SETUP messages are not sent on broadcast data links

- non-selected user clearing 5.2.9 not applicable

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 434

表表表表 E.1/TS 24.008: Circuit-switched call control procedures (continued)

Procedure Q.931 GSM 24.008 Call clearing 5.3 5.4 - terminology 5.3.1 5.4.1

terminology adapted to GSM applications

- exception conditions 5.3.2 5.4.2

only case a) of section 5.3.2 of Rec. Q.931 applies. All other exceptions apply to functions which are not relevant to GSM

- clearing initiated by the user/MS

5.3.3 5.4.3

- clearing initiated by the network

5.3.4 5.4.4

- clearing when tones/announcements are provided

5.3.4.1 5.4.4.1.1 and 5.4.4.2.1 exception: if not already connected, the traffic channel is connected in order to provide the tone/announcement

- clearing when tones/announcements are not provided

5.3.4.2 5.4.4.1.2 and 5.4.4.2.3

- completion of clearing 5.3.4.3 5.4.4.1.3 and 5.4.4.2.5 Clear collision 5.3.5 5.4.5

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 435

表表表表 E.1/TS 24.008: CS 呼制御処理（呼制御処理（呼制御処理（呼制御処理（Circuit-switched call control procedures））））(続き続き続き続き)

Procedure Q.931 GSM 24.008 In-band tones and announcements

5.4 5.5.1

Restart procedure 5.5 not supported Call rearrangements 5.6 5.3.4

call suspension/call re-establishment not supported on the radio path. The functions, if required, are to be supported locally in the MS. On the radio interface, the notification procedure of Rec. Q.931 (section5.6.7) applies

Call collisions 5.7 5.5.2

call collisions cannot occur Emergency call establishment at the originating interface

not specified not supported

5.2.1.2

In-call modification Annex O

Rec. Q.931 is incomplete with regard to in-call modification procedures

5.3.4

DTMF protocol control procedures

not specified not supported

5.3.3

Call re-establishment not specified

not supported 5.5.4

Status enquiry procedure 5.8.10, 5.8.11 5.5.3 User-to-user signalling 7 GSM 04.10 User notification procedure 5.9 5.3.1

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 436

Annex F (informative): GSM specific cause values for radio resource management （GSM固有の RR管理用理由値）

04.18 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 437

Annex G (informative): UMTS specific cause values for mobility management （UMTS固有の MM用理由値）

本 Annex は informative である。ここでは、非 GPRS サービス（MM）用および GPRS サービス用（GMM）の MM管理処理用の理由値について説明する。セクション G.1～G.5 は、MM と GMM の双方について有効である。ただし、

以下のコードは非 GPRS サービスについてのみ適用される。

#38 Call cannot be identified

セクション G.6 は GMM 処理についてのみ適用される。

G.1 Causes related to MS identification （MS識別に関係する理由値）

Cause value = 2 IMSI unknown in HLR

MS が HLR 内で未知の（登録されていない）場合に、本理由値が MS に対して送信される。本理由コードは、

GMM 処理が使用することもできるが、GPRS サービスのオペレーションには影響を及ぼさない。

Cause value = 3 Illegal MS

ネットワークが MS の ID を受理できない、または MS が認証チェックをパスしない（つまり MS から受信した

SRES がネットワークが生成した値と異なる場合）ために、ネットワークネットワークが MS に対するサービス

提供を拒否した場合に、本理由値が MS に対して送信される。

Cause value = 4 IMSI unknown in VLR

ある IMSI が VLR において未知の場合に、本理由値が MS に対して送信される。

Cause value = 5 IMEI not accepted

IMEI を使用した緊急呼の確立をネットワークが受理しない場合に、本理由値が MS に対して送信される。

Cause value = 6 Illegal ME

使用された ME がネットワークで受理されなかった場合（ブラックリストに登録されている、など）に、本理由値

が MS に対して送信される。

G.2 Cause related to subscription options （加入者オプションに関する理由値）

Cause value = 11 PLMN not allowed

予約またはオペレータが決定したバーリング（barring）によって、MS のオペレーションが許可されない PLMN内で、MS が位置登録更新を要求した場合に、本理由値が MS に対して送信される。

Cause value = 12 Location Area not allowed

予約によって MS のオペレーションが許可されない LA 内で、MS が位置登録更新を要求した場合に、本理由

値が MS に対して送信される。

Cause value = 13 Roaming not allowed in this location area

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 438

予約によって該当 LA 内の MS に対してローミングを提供する PLMN の LA 内で、位置登録更新を要求した

MS に対して送信される。

G.3 Causes related to PLMN specific network failures and congestion / Authentication Failures （PLMN固有のネットワークエラーおよび輻輳／認証エラーに関する理由値）

Cause value = 20 MAC failure

認証要求メッセージ内の MAC が新鮮でないことを SIM カードが検出した場合に、本理由値がネットワークに

対して送信される（TS 33.102 参照）。

Cause value = 21 Synch failure

認証要求メッセージ内の SQN が範囲外の値であることを SIM カードが検出した場合に、本理由値がネットワ

ークに対して送信される（TS 33.102 参照）。

Cause value = 17 Network failure

PLMN のエラー（MAP の問題など）により、MS が生成した要求を MSC がサービスできない場合に、本理由

値が MS に対して送信される。

Cause value = 22 Congestion

輻輳（チャネル不足、装置のビジー／輻輳など）により、要求されたサービスを起動できない場合に、本理由

値が送信される。

G.4 Causes related to nature of request Cause value = 32 Service option not supported

CM SERVICE REQUEST メッセージ内で、PLMN がサポートできないサービス／設備を MS が要求した場

合に、本理由値が送信される。

Cause value = 33 Requested service option not subscribed

MS が加入していないサービスオプションを要求した場合に、本理由値が送信される。

Cause value = 34 Service option temporarily out of order

サービスを提供するために必要な機能のうち、1 つまたは複数が一時的にサービス断となっているために、

MSC がサービスを提供できない場合に、本理由値が送信される。

Cause value = 38 Call cannot be identified

ネットワークが呼再確立要求と関連する呼を特定できない場合に、本理由値が送信される。

G.5 Causes related to invalid messages Cause value = 95 Semantically incorrect message.

annex H, セクション H.5.10 参照。

Cause value = 96 Invalid mandatory information.


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 439

Cause value = 97 Message type non-existent or not implemented.


Cause value = 98 Message not compatible with protocol state.


Cause value = 99 Information element non-existent or not implemented


Cause value = 100 Conditional IE error.


Cause value = 101 Message not compatible with protocol state


Cause value = 111 Protocol error, unspecified


G.6 Additional cause codes for GMM Cause value = 7 GPRS services not allowed

MS が GPRS 用 IMSI アタッチを要求したが、GPRS サービスのオペレーションが許可されない場合に、本理

由値が MS に対して送信される。

Cause value = 8 GPRS services and non-GPRS services not allowed

MS が GPRS サービスおよび非 GPRS サービス用の複合 IMSI アタッチを要求したが、そのどちらかのオペ

レーションが許可されない場合に、本理由値が MS に対して送信される。

Cause value = 9 MS identity cannot be derived by the network

SGSN 間 RA 更新の場合、ネットワークが P-TMSI から MS の ID を誘導できなかった場合に、本理由値が

MS に対して送信される。

Cause value = 10 Implicitly detached

ネットワークが非明示的に MS をデタッチした場合（例えばモバイルが到達可能なタイマが満了した後）、また

は（例えば SGSN の再開などによって）加入者に関する GMM コンテキストデータが SGSN 内に存在しない

場合に、本理由値が MS に対して送信される。

Cause value = 16 MSC temporarily not reachable

一時的に MSC が GSM ネットワークの GPRS 部分を経由して到達不可能になった PLMN 内で、MS が複合

GPRS アタッチまたは RA 更新を要求した場合、本理由値が MS に対して送信される。

Cause value = 40 No PDP context activated

MS が "data" を通知する SERVICE REQUEST メッセージをネットワークに対して送信し、全てのアクティブ

な PDP コンテキストに関する RAB の確立を要求したが、SGSN がアクティブな PDP コンテキストを持ってい

ない場合に、本理由値が MS に対して送信される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 440

Annex H (informative): UMTS specific cause values for call control （UMTS固有の呼制御に関する理由値）


H.1 Normal class（ノーマルクラス）

H.1.1 Cause No. 1 "unassigned (unallocated) number" 番号は有効なフォーマットだが、現在アサインされていない（割当てられていない）ために、MS が要求した着信先に

呼が到達できないことを示す。

H.1.2 Cause No. 3 "no route to destination" 呼をルーチングすべきネットワークが、希望する着信先に対するサービスを提供しないために、着信ユーザまで呼が

到達できないことを示す。

H.1.3 Cause No. 6 "channel unacceptable" その呼の中で使用される送信エンティティが、一番近に特定されたチャネルを受け付けられないことを示す。

H.1.4 Cause No. 8 "operator determined barring" MS のネットワークオペレータまたはサービスプロバイダが未だ提供していないサービスを、MS が試行したことを示

す。

H.1.5 Cause No.16 "normal call clearing" 呼に関係する 1 人または複数のユーザが呼のクリアを要求したために、呼がクリアされたことを示す。

通常条件下では、本理由値の発信元はネットワークではない。

H.1.6 Cause No.17 "user busy" 着信ユーザが他の呼を受理できないことを示す場合に使用される。

ユーザ装置が、呼と互換性があることに注意。

H.1.7 Cause No. 18 "no user responding" ユーザが呼確立メッセージに対して、（タイマ T303 または T310 の満了によって規定される）所定割当時間内に、ア

ラートもしくは接続通知で応答しなかった場合に使用される。

H.1.8 Cause No. 19 "user alerting, no answer" ユーザがアラート通知を提示したが、所定時間内に接続通知を提示しなかった場合に使用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 441

H.1.9 Cause No. 21 "call rejected" 本理由値を送信している装置が、呼を受理できるにもかかわらず（なぜならば本理由値を送信している装置

はビジーでも非互換でもないから）、呼の拒否を希望していることを示す。

H.1.10 Cause No. 22 "number changed" 発呼 MS によって通知された着呼パーティ番号が、既に割当てれていない場合に、本理由値が MS に返される。着

呼パーティ番号は、オプションとして diagnostic フィールド内に含めることができる。ネットワークが本ケーパビリティ

をサポートしない場合、理由値 No. 1 "unassigned (unallocated) number"を使用すること。

H.1.11 Cause No. 25 "pre-emption" 他のより高い順位の呼が先取したアクティブな呼を MS がクリアした場合、、本理由値がネットワークに返される。

H.1.12 Cause No. 26 "non-selected user clearing" サポート外。理由値 no. 31 として扱われる。

H.1.13 Cause No. 27 "destination out of order" MS が通知した宛先に対するインタフェースが正しく機能していないために、呼が到達できないことを通知するために

使用される。「正しく機能しない」（"not functioning correctly"）という用語は、例えばリモートユーザ側の物理レイヤまたは

データリンクのエラーやユーザ装置のオフラインなどによって、リモートユーザにシグナリングメッセージを配送できないことを示す。

H.1.14 Cause No. 28 "invalid number format (incomplete number)" 着信パーティ番号のフォーマットが無効、または不完全であるために、着呼ユーザまで呼が到達しないことを示す。

H.1.15 Cause No. 29 "facility rejected" ユーザによって要求された設備がネットワークによって提供されない場合に、本理由値が返される。

H.1.16 Cause No. 30 "response to STATUS ENQUIRY" 本理由値は、STATUS ENQUIRY メッセージに対する応答として STATUS メッセージが送信された場合に、

STATUS メッセージ内に含められる。セクション 5.5.3 参照。

H.1.17 Cause No. 31 "normal, unspecified" ノーマルクラスの他の理由値が適用できないノーマルイベントをレポートするために、本理由値が使用される。

H.2 Resource unavailable class（リソース利用不可能クラス）

H.2.1 Cause No. 34 "no circuit/channel available" 呼を処理するために、利用可能な適切な回線／チャネルがないことを示す。

H.2.2 Cause No. 38 "network out of order" ネットワークが正しく機能せず、またその状況が比較的長い間続きそうなこと（例えば直ちに呼を再試行しても成功し

そうもない場合など）を示す。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 442

H.2.3 Cause No. 41 "temporary failure" ネットワークが正しく機能せず、その状況はそれほど長く続かないようなこと（例えば MS が直ちに再発呼を試行する

ことができそうな場合など）を示す。

H.2.4 Cause No. 42 "switching equipment congestion" 本理由値を生成する回線交換装置の負荷が高いことを示す。

H.2.5 Cause No. 43 "access information discarded" ネットワークが要求されたとおりに、リモートユーザに対してアクセス情報（例えばユーザ→ユーザ情報、下位レイヤ

互換性、上位レイヤ互換性、diagnostic 内で通知されたサブアドレスなど）を配送できないことを示す。

廃棄されたアクセス情報のタイプは通常オプションとして diagnostic 内に含まれることに注意。

H.2.6 Cause No. 44 "requested circuit/channel not available" エンティティに要求された回線またはチャネルがインタフェースの反対側で提供できない場合に、本理由値が返され

る。

H.2.7 Cause No. 47 "resource unavailable, unspecified" リソース利用不可能クラスの他の理由値が適用できないリソース利用不可能イベントをレポートするために、本理由

値が使用される。

H.3 Service or option not available class （サービス／オプション利用不可能クラス）

H.3.1 Cause No. 49 "quality of service unavailable"

TU-T 勧告 X.213 で規定された要求されたサービス品質が提供できない場合に、MS に対して本理由値が示される。

H.3.2 Cause No. 50 "Requested facility not subscribed"

ユーザがサポートネットワークに対して必要な管理処理を完了していないために、ネットワークが要求された付加サ

ービスを提供できないことを示す。

H.3.3 Cause No. 55 "Incoming calls barred within the CUG"

着信パーティが着信 CUG 呼用の CUG のメンバであるにもかかわらず、着信呼がその CUG 内で許可されなかっ

たことを示す。

H.3.4 Cause No. 57 "bearer capability not authorized"

本理由値を生成した装置が実装するベアラケーパビリティを MS が要求したが、MS がそれを使用する権限を持た

ないことを示す。

H.3.5 Cause No. 58 "bearer capability not presently available"

本理由値を生成した装置が実装するベアラケーパビリティを MS が要求したが、そのケーパビリティが現在利用不

可能であることを示す。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 443

H.3.6 Cause No. 63 "service or option not available, unspecified"

サービスまたはオプション利用可能クラスが適用される他の理由値がない、サービスまたはオプション利用可能イベ

ントをレポートするために使用される。

H.3.7 Cause No. 68 "ACM equal to or greater than ACMmax"

呼のクリア理由が、ACM が ACMmax 以上になったためであることを通知するために、MS は本理由値を使用する。

H.4 Service or option not implemented class （サービス／オプション非実装クラス）

H.4.1 Cause No. 65 "bearer service not implemented" 本理由値を送信している装置が、要求されたベアラケーパビリティをサポートしないことを示す。

H.4.2 Cause No. 69 "Requested facility not implemented"

本理由値を送信している装置が、要求された付加サービスをサポートしないことを示す。

H.4.3 Cause No. 70 "only restricted digital information bearer capability is available"

1 つの装置が制限されていないベアラサービスを要求したが、本理由値を送信している装置が要求されたベアラ

ケーパビリティの制限付バージョンだけしかサポートしていないことを示す。

H.4.4 Cause No. 79 "service or option not implemented, unspecified" 他のサービス／オプション非実装クラスが適用されない、サービス／オプション非実装イベントをレポートするた

めに使用される。

H.5 Invalid message (e.g., parameter out of range) class

H5.1 Cause No. 81 "invalid transaction identifier value" 本理由値を送信している装置が、MS～ネットワークのインタフェース上で現在使用されていない TI（transaction

identifier）を持つメッセージを受信したことを示す。

H.5.2 Cause No. 87 "user not member of CUG" 着信 CUG 呼の着呼ユーザが、特定の CUG のメンバでないことを示す。

H.5.3 Cause No. 88 "incompatible destination" 本理由値を送信している装置が、下位レイヤ互換性、上位レイヤ互換性、またはその他の互換性属性（例え

ばデータレートなど）のある呼の確立要求を受信したが、それらを提供できないことを示す。

H.5.4 Cause No. 91 "invalid transit network selection" FFS。理由値 no. 95 として扱われる。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 444

H.5.5 Cause No. 95 "semantically incorrect message" 意味的に間違ったコンテンツを持つメッセージを受信したことをレポートするために使用される（セクション 8.8

参照）。

H.6 Protocol error (e.g., unknown message) class （プロトコルエラー（未知のメッセージなど）クラス）

H.6.1 Cause No. 96 "invalid mandatory information" 本理由値を送信している装置が、意味的でない必須 IE のエラーを持つメッセージを受信したことを示す（セク

ション 8.5 参照）。

H.6.2 Cause No. 97 "message type non-existent or not implemented" メッセージが未定義、または定義されていても本理由値を送信している装置が実装していないメッセージであ

るために、本理由値を送信している装置がメッセージタイプを識別できないメッセージを受信したことを示す。

H.6.3 Cause No. 98 "message type not compatible with protocol state" 本理由値を送信している装置が、プロトコルステートと両立しないメッセージを受信したことを示す（セクション

8.4 参照）。

H.6.4 Cause No. 99 "information element non-existent or not implemented" IEI が定義されていない、または定義されていても本理由値を送信している装置が実装していない IEI である

ために、認識できない IE を含むメッセージを本理由値を送信している装置が受信したことを示す。ただし、メッ

セージを処理するために、理由値を送信している装置のためにメッセージ内に IE が現れることを要求するわ

けではない。

H.6.5 Cause No. 100 "conditional IE error" 本理由値を送信している装置が、条件付 IE エラー（セクション 8.7.2 参照）を持つメッセージを受信したことを

示す。

H.6.6 Cause No. 101 "message not compatible with protocol state" プロトコルステートと互換性のないメッセージを受信した、または受信した STATUS メッセージが非互換呼ス

テートを示していることを通知する。

H.6.7 Cause No. 102 "recovery on timer expiry" タイマの満了によって、TS 24.008 のエラー処理手順に関係する処理が開始されたことを示す。

H.6.8 Cause No. 111 "protocol error, unspecified" 他のプロトコルエラークラスの理由値が適用されないプロトコルエラーイベントをレポートするために使用され

る。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 445

H.7 Interworking class（インターワーキングクラス）

H.7.1 Cause No. 127 "interworking, unspecified"

ネットワークが取るべきアクションのための理由値を提供しないネットワークとのインターワーキングが開始された

ことを示す。従って、送信されるメッセージ用の正確な理由値は確認できない。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 446

Annex I (informative): GPRS specific cause values for session management （GPRS固有の SM用理由値）


I.1 Causes related to nature of request （要求の性質に関する理由値）

Cause value = 25 LLC or SNDCP failure (GSM only)

LLC または SNDCP のエラーによって、PDP コンテキストが不活性化されたことを MS が通知するために使

用する（例えば、SM が理由値"DM received " または" invalid XID response "の SNSM-STATUS.request メッセージを受信した場合など、GSM 04.65 [78]参照）。

Cause value = 26 Insufficient resources

リソース不足により、PDP コンテキスト活性化要求、セカンダリ PDP コンテキスト活性化要求、または PDP コ

ンテキスト修正要求が受理できないことを示すために、MS またはネットワークによって使用される。

Cause value = 27 Unknown or missing access point name

アクセスポイント名が含まれていないため、またはアクセスポイント名が解決できないために、要求されたサー

ビスが外部パケットデータネットワークによって拒否されたことを示すために、ネットワークによって使用される。

Cause value = 28 Unknown PDP address or PDP type

PDP アドレスまたは PDP タイプが識別できないために、要求されたサービスが外部パケットデータネットワー

クによって拒否されたことを示すために、ネットワークによって使用される。

Cause value = 29 User authentication failed

ユーザ認証が失敗したために、要求されたサービスが外部パケットデータネットワークによって拒否されたこと

を示すために、ネットワークによって使用される。

Cause value = 30 Activation rejected by GGSN

要求されたサービスが GGSN によって拒否されたことを示すために、ネットワークによって使用される。

Cause value = 31 Activation rejected, unspecified

特定できない理由によって要求されたサービスが拒否されたことを示すために、ネットワークによって使用さ

れる。

Cause value = 32 Service option not supported

MS が PLMN がサポートしないサービスを要求したことを示すために、ネットワークによって使用される。

Cause value = 33 Requested service option not subscribed

Annex G、第 4 章参照。

Cause value = 34 Service option temporarily out of order

Annex G、第 4 章参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 447

Cause value = 35 NSAPI already used

MS が PDP コンテキスト活性化要求の中で要求した NSAPI が、その MS の既にアクティブになっている他の

PDP コンテキストによって既に使用されていることを示すために、ネットワークによって使用される。

PDP コンテキスト活性化時には、送信してはならないが、R97/R98 ネットワークから受信することはできる。

Cause value = 36 Regular PDP context deactivation

レギュラーMS またはネットワークが PDP コンテキスト不活性化を開始したことを通知するために使用される。

Cause value = 37 QoS not accepted

PDP コンテキスト修正処理の中でネットワークから通知された新しい QoS が受理できない場合、MS が本理

由値を使用する。

Cause value = 38 Network failure

PDP コンテキスト不活性化が、ネットワーク内のエラー状況によるものであることを通知するために、ネットワ

ークが使用する。

Cause value = 39 Reactivation requested

GGSN 再開後、PDP コンテキスト活性化を要求するために、ネットワークが使用する。

Cause value = 40 Feature not supported

ネットワークが開始した PDP コンテキスト活性化が、MS がサポートしないことを示すために、MS は本理由

値を使用する。

Cause value = 41 semantic error in the TFT operation.

セカンダリ PDP コンテキスト活性化要求、または MS が開始した PDP コンテキスト修正に含まれる TFT オ

ペレーション内に、意味的エラーがあることを示すために、ネットワークによって使用される。

Cause value = 42 syntactical error in the TFT operation.

セカンダリ PDP コンテキスト活性化要求、または MS が開始した PDP コンテキスト修正に含まれる TFT オ

ペレーション内に、構文的エラーがあることを示すために、ネットワークによって使用される。

Cause value = 43 unknown PDP context

Linked TI IE によって特定された PDP コンテキストの PDP コンテキスト活性化要求がアクティブでないことを

通知するために、ネットワークによって使用される。

Cause value = 44 semantic errors in packet filter(s)

セカンダリ PDP コンテキスト活性化要求、または MS が開始した PDP コンテキスト修正に含まれる TFT の

パケットフィルタ内に、1 つまたは複数の意味的エラーがあることを示すために、ネットワークによって使用され

る。

Cause value = 45 syntactical error in packet filter(s)

セカンダリ PDP コンテキスト活性化要求、または MS が開始した PDP コンテキスト修正に含まれる TFT の

パケットフィルタ内に、1 つまたは複数の構文的エラーがあることを示すために、ネットワークによって使用され

る。

Cause value = 46 PDP context without TFT already activated

ネットワークが既に TFT のない活性化された PDP コンテキストを持っていることを示すために、ネットワーク

によって使用される。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 448

I.2 Causes related to invalid messages （無効なメッセージに関する理由値）

Cause value = 81 Invalid transaction identifier value.

Annex H、セクション H.5.1 参照。

Cause value = 95 Semantically incorrect message.


Cause value = 96 Invalid mandatory information.


Cause value = 97 Message type non-existent or not implemented.


Cause value = 98 Message not compatible with protocol state.


Cause value = 99 Information element non-existent or not implemented


Cause value = 100 Conditional IE error.


Cause value = 101 Message not compatible with protocol state


Cause value = 111 Protocol error, unspecified


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 449

Annex J (informative): Algorithm to encode frequency list information elements （frequency list IEのエンコードアルゴリズム）

04.18 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 450

Annex K (informative): Default Codings of Information Elements （IEのデフォルトコーディング）


本 Annex 内の情報は、特定のメッセージ用の IEI の値を定義するものではない。本 Annex は、に phase 1 の MSとのバックワード互換性を考慮した上で、新しいメッセージの設計を助けるためのものである。

K.1 Common information elements （共通 IE）

表 K.1/TS 24.008 に、下記にリストアップされた共通 IE のタイプについて、IEI ビットのデフォルトコーディングをまと

めた。

表表表表 K.1/TS 24.008: Default information element identifier coding for common information elements

Reference section

8 7 6 5 4 3 2 1 1 : : : - - - - Type 1 info elements 1 1 1 1 - - - - Note 1 0 : : : : : : : Type 3 & 4 info elements 0 0 0 1 0 0 0 1 Note 1 0 0 0 1 0 0 1 1 Location Area Identification 10.5.1.3 0 0 0 1 0 1 1 1 Mobile Identity 10.5.1.4 0 0 0 1 1 0 0 0 Note 1 0 0 0 1 1 1 1 1 Note 1 0 0 1 0 0 0 0 0 Mobile Station 10.5.1.7 classmark 3 Spare Half Octet 10.5.1.8 All other values are reserved

NOTE 1: これらの値は、プロトコルの前の phase では割当てられていたが未使用。

NOTE 2: GPRS 共通 IE 用には、デフォルト値は定義されない。

K.2 Radio Resource management information elements （RR管理 IE）

04.18 Annex K 参照。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 451

K.3 Mobility management information elements （MM IE）

下記に列挙した MM IE について、IEI ビットのデフォルトコーディングについては K.3/TS 24.008 にまとめた。

表表表表 K.3/TS 24.008: Default information element identifier coding for mobility management information elements

Reference Section 8 7 6 5 4 3 2 1 Type 1 info elements 1 0 0 1 - - - - Note 1 1 0 0 - - - - Note 1 1 1 0 - - - - Note 1 0 1 0 - - - - Type 2 info elements 0 0 0 1 Follow-on Proceed 10.5.3.7 0 0 1 0 CTS Permission 10.5.3.10 Type 3 & 4 info elements 0 1 0 0 0 0 0 1 Note 0 1 0 0 0 0 1 0 Note 0 1 0 0 0 1 0 0 Note All other values are reserved NOTE: These values were allocated but never used in earlier versions of the protocol

K.4 Call control information elements（CC IE）下記にリストアップされた CC IE について、IEI ビットのデフォルトコーディングは表 K.4/TS 24.008 にまとめた。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 452

表表表表 K.4/TS 24.008: Default information element identifier coding for call control information elements

Reference section

8 7 6 5 4 3 2 1 1 : : : - - - - Type 1 info elements 0 0 1 - - - - Shift 10.5.4.2

and .3 0 1 1 - - - - Note 1 0 1 - - - - Repeat indicator 10.5.4.22 1 0 1 0 : : : : Type 2 information elements 0 0 0 0 More data 10.5.4.19 0 0 0 1 CLIR Suppression 10.5.4.11a 0 0 1 0 CLIR Invocation 10.5.4.11b 0 0 1 1 Reverse call setup direction 10.5.4.22a 0 : : : : : : : Type 3 & 4 info elements 0 0 0 0 1 0 0 Bearer capability 10.5.4.5 0 0 0 1 0 0 0 Cause 10.5.4.11 0 0 1 0 1 0 0 Note 0 0 1 0 1 0 1 Call Control Capabilities 10.5.4.5a 0 0 1 1 1 0 0 Facility 10.5.4.15 0 0 1 1 1 1 0 Progress indicator 10.5.4.21 0 1 0 0 1 0 0 Auxiliary states 10.5.4.4 0 1 0 0 1 1 1 Note 0 1 0 1 1 0 0 Keypad facility 10.5.4.17 0 1 1 0 1 0 0 Signal 10.5.4.23 1 0 0 1 1 0 0 Connected number 10.5.4.13 1 0 0 1 1 0 1 Connected subaddress 10.5.4.14 1 0 1 1 1 0 0 Calling party BCD number 10.5.4.9 1 0 1 1 1 0 1 Calling party subaddress 10.5.4.10 1 0 1 1 1 1 0 Called party BCD number 10.5.4.7 1 1 0 1 1 0 1 Called party subaddress 10.5.4.8 1 1 1 0 1 0 0 Redirecting Party BCD 10.5.4.21a 1 1 1 1 1 0 1 Redirecting Party subaddress 10.5.4.21b 1 1 1 1 1 0 0 Low layer compatib. 10.5.4.18 1 1 1 1 1 0 1 High layer compatib. 10.5.4.16 1 1 1 1 1 1 0 User-user 10.5.4.25 1 1 1 1 1 1 1 SS version indicator 10.5.4.24

+------これらの値は、プロトコルの前の phase では割当てられていたが未使用。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 453

Annex M (normative): Additional Requirements for backward compatibility with PCS 1900 for NA revision 0 ME （PCS 1900とのバックワード互換性のための追加要求条件、NA revision 0 の ME用）

本 Annex は normative であり、NA revision 0 の ME(1998 年 7 月 1 日まで適用可能)用に、PCS 1900 とのバック

ワード互換性のためのサポートネットワークに対する追加要求条件をするものである。

NA revision 0 の ME 用 PCS 1900 は、2 桁までの MNC （Mobile Network Code）を理解すると規定される。しか

し連邦規則では、ネットワークオペレータの管理によって、3 桁の MNC が必須となっている。したがって、ネットワー

クオペレータは、3 桁の MCC（Mobile Country Code）と 3 桁の MNC（Mobile Network Code）によって識別される。 NA 用に PCS 1900 のために指定された割当て原則に適合した NC（Network Code）を持つオペレータは、移行期

間内に NA revision 0 の ME 用の PCS 1900 とのバックワード互換性を達成するために、以下の規則を適用するこ

と。

- ネットワークはエアインターフェース上で 3 桁の MCC と、MNC の上 2 桁だけを送信すること（3 桁目の数字

の代わりに送信すべき数字の値については TS 24.008 のセクション 10.5.1.3 で規定される）（注参照）。

（revision が 0 より大きい）NA の ME 用の PCS 1900 が、エア上で現在の IMSI の HPLMN コードとして MCCと MNC の上 2 桁を認識したならば、ME は SIM カードから読み出した IMSI の 6 桁目の値を考慮に入れる

こと。その値が、NA 用の PCS 1900 用に番号割当機関から割当てられた MNC の終桁の値として設定さ

れた限界にマッチするならば、以下の手順が ME に対して適用される。

- LAI(コーディング用、TS 24.008 のセクション 10.5.1.3 を参照)中の MNC の 3 桁目の数字の代わりに、エア

上に送信された値を、SIM カードから読み出した IMSI の 6 桁目の値をして解釈すること。

NOTE:

1998 年 7 月 1 日以降も、本要求条件はネットワークオペレータのオプションである。しかしその場合、

以下のことを考慮すること。

1. 重複するネットワーク用のネットワーク選択を考慮すること

- 無線インタフェース上で同一のコンビネーション MCC1 MCC2 MCC3 MNC1 MNC2 で識別される

HPLMN がオーバーラップするネットワーク（1998 年 7 月 1 日以降発生する可能性がある）は、NA ME revision 0 の ME によって、HPLMN または HPLMN と同様にユーザに提示された値と同じ優

先度で選択されることがある。

2 ローミングの考慮

- 同一のコンビネーション MCC1 MCC2 MCC3 MNC1 MNC2 で識別されるネットワーク（1998 年 7月 1 日以降発生する可能性がある）からのローミングユーザ（SIM）は、NA ME revision 0 の ME用 PCS 1900 のオペレータネットワークにローミングする場合、これらの機器が予測できない動作

を引き起こす可能性がある（例えば HPLMN 選択および登録処理における重複など）。

- 同一のコンビネーション MCC1 MCC2 MCC3 MNC1 MNC2 によって識別されるネットワーク

(1998 年 7 月 1 日以降発生する可能性がある)内へ、ホーム加入者（SIM）が NA ME revision 0 の ME 用 PCS 1900 でローミングした場合、HPLMN にアタッチされることを考慮することも可能。

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 454

Annex N (informative): Change Record（改版履歴）

本仕様書は、04.08 version 7.1.0 に基づき、以下の CR を含む。

Tdoc Spec CR Rev Vers Subject Cat New Vers

P-99-510 24.008 A371 2 7.1.0 BCIE modifications due to EDGE B 3.0.0P-99-523 24.008 A515 1 7.1.0 Split of 24.008 in RR and CN parts (Section 7, "L3 stage2") F 3.0.0P-99-388 24.008 A562 7.1.0 CR to 24.008 due to EDGE SMG2 EDGE WS B 3.0.0P-99-523 24.008 A567 1 7.1.0 Split of 24.008 in RR and CN parts F 3.0.0P-99-390 24.008 A592 1 7.1.0 GSM 400 and Mobile Station Classmark B 3.0.0P-99-523 24.008 A611 1 7.1.0 Split of 24.008 in RR and CN parts F 3.0.0P-99-523 24.008 A613 1 7.1.0 Split of 24.008 in RR and CN parts F 3.0.0P-99-512 24.008 A621 2 7.1.0 IE Daylight saving time B 3.0.0P-99-461 24.008 A687 7.1.0 Transfer of the LSA Information to the MS B 3.0.0NP-99268 24.008 002 3.0.1 GPRS phase 1 for PCS 1900 A 3.1.0NP-99268 24.008 004 3.0.1 GMM attempt counters A 3.1.0NP-99268 24.008 005 3.0.1 Cell Change during GPRS Detach procedure A 3.1.0NP-99268 24.008 006 3.0.1 RA change in GMM-ROUTING-AREA-UPDATE-INITIATED A 3.1.0NP-99268 24.008 007 3.0.1 Non power down caused Detach during Attach A 3.1.0NP-99268 24.008 008 3.0.1 "Receive N-PDU Number list" IE padding bits A 3.1.0NP-99268 24.008 009 3.0.1 PDP context deactivation caused by LLC failure A 3.1.0NP-99268 24.008 010 1 3.0.1 CM request and combined GMM procedures A 3.1.0NP-99268 24.008 013 1 3.0.1 TMSI status indication A 3.1.0NP-99269 24.008 014 1 3.0.1 BCIE modifications due to ECSD asymmetry B 3.1.0NP-99268 24.008 015 3.0.1 RAU Complete not returned for TMSI deallocation. Some alignments

and editorials. F 3.1.0

NP-99268 24.008 016 3.0.1 Clarification of the Detach Type "re-attach required" or "re-attach not required" in the network initiated Detach procedure

F 3.1.0

NP-99268 24.008 018 3.0.1 Addition of Access Point Name in Request PDP Context Activation message

B 3.1.0

NP-99268 24.008 019 1 3.0.1 CR clash in sec. 4.7.3.2.6 A 3.1.0NP-99268 24.008 020 3.0.1 CR clash in sec. 4.7.3.2.3.2 and 4.7.5.2.3.2 A 3.1.0NP-99268 24.008 021 1 3.0.1 T3212 restart after RAU reject A 3.1.0NP-99268 24.008 022 3.0.1 New State GMM-REGISTERED.IMSI-DETACH-INITIATED A 3.1.0NP-99268 24.008 023 3.0.1 Deactivate AA PDP context request message A 3.1.0NP-99268 24.008 024 2 3.0.1 Coding Scheme in Network Name IE A 3.1.0NP-99269 24.008 028 1 3.0.1 MS Radio Access Capability IE B 3.1.0NP-99268 24.008 011 1 3.0.1 T3212 restart after GPRS detach A 3.1.0NP-99452 24.008 003 3 3.1.0 Clarification of DTMF procedure C 3.2.0NP-99441 24.008 026 2 3.1.0 Extended Transaction Identifier Reject C 3.2.0NP-99445 24.008 033 5 3.1.0 Updating Session Management (SM) for R99 C 3.2.0NP-99447 24.008 034 1 3.1.0 Mobile Station Classmark 3 Clarification F 3.2.0NP-99447 24.008 036 1 3.1.0 Proposal of Classmark 2 for UMTS B 3.2.0NP-99449 24.008 037 1 3.1.0 Proposal of UMTS/GSM bearer capability B 3.2.0NP-99443 24.008 039 4 3.1.0 Service Request B 3.2.0NP-99443 24.008 040 3 3.1.0 Introduction of Follow-on mechanism for PS B 3.2.0NP-99445 24.008 041 1 3.1.0 Uplink L3 Message Sequencing C 3.2.0NP-99451 24.008 042 4 3.1.0 Adaptation of MM and GMM messages to incorporate UMTS security

parameters C 3.2.0

NP-99443 24.008 043 2 3.1.0 Network Requested PDP Context Activation C 3.2.0NP-99443 24.008 047 3.1.0 Clarification of DRX A 3.2.0NP-99442 24.008 051 2 3.1.0 Emergency Call handling in Packet only networks B 3.2.0NP-99447 24.008 052 1 3.1.0 Addition of MS Classmark 2 in Location Updating Request B 3.2.0NP-99445 24.008 053 2 3.1.0 GMM State Model for UMTS B 3.2.0NP-99445 24.008 054 3 3.1.0 READY timer not applicable for UMTS B 3.2.0NP-99445 24.008 056 1 3.1.0 Periodic RA Update Timer function and Mobile Reachable Timer function

for UMTS and clarification that the substate SUSPENDED is applicable for GSM only.

B 3.2.0

NP-99445 24.008 057 1 3.1.0 P-TMSI reallocation procedure B 3.2.0NP-99445 24.008 058 1 3.1.0 Detach procedure B 3.2.0NP-99445 24.008 059 2 3.1.0 UMTS <-> GPRS Intersystem change (handover) B 3.2.0NP-99445 24.008 060 1 3.1.0 Change of Network Mode of operation B 3.2.0NP-99445 24.008 061 1 3.1.0 MS modes of operation in UMTS B 3.2.0NP-99444 24.008 063 2 3.1.0 Mobile Station Classmark 850 and 1900 band included B 3.2.0NP-99443 24.008 064 4 3.1.0 UMTS adaptation to section 4.7.1 B 3.2.0NP-99445 24.008 069 1 3.1.0 24.008 Vocabulary F 3.2.0NP-99506 24.008 071 1 3.1.0 Mirror R99 LCS CR to GSM 04.08 A 3.2.0

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 455


NP-99450 24.008 072 2 3.1.0 Parallel handling of multiple user application flows B 3.2.0NP-99452 24.008 074 1 3.1.0 GSM cleanup C 3.2.0NP-99452 24.008 075 2 3.1.0 UMTS cleanup C 3.2.0NP-99445 24.008 080 3.1.0 Identity procedure B 3.2.0NP-99445 24.008 081 1 3.1.0 Alignment of MM for R99 B 3.2.0NP-99445 24.008 082 1 3.1.0 Attach procedure for R99 B 3.2.0NP-99445 24.008 083 1 3.1.0 Routing Area updating procedure for R99 B 3.2.0NP-99445 24.008 085 3.1.0 Paging for R99 B 3.2.0NP-99450 24.008 086 1 3.1.0 QoS enhancements C 3.2.0NP-99445 24.008 089 1 3.1.0 Transaction Identifier Extension C 3.2.0NP-000186 24.008 097 1 3.2.1 Changes to support a Circuit switched multimedia call ( related to CR

97r3 where the revision marks were not shown) B 3.3.0

NP-000097 24.008 097 3 3.2.1 Changes to support a Circuit switched multimedia call B 3.3.0NP-000094 24.008 152 2 3.2.1 Modification of MS CM1 and CM2 F 3.3.0NP-000095 24.008 032 10 3.2.1 Addition of the Stream Identifier Information Element B 3.3.0NP-000090 24.008 049 4 3.2.1 Support of 400 and 850 MHz band B 3.3.0NP-000091 24.008 091 1 3.2.1 Timer control for GPRS detach A 3.3.0NP-000100 24.008 093 3.2.1 UMTS security parameters, Handling of Ciphering algorithm IE in UMTS C 3.3.0NP-000100 24.008 094 3.2.1 UMTS security parameters, Correction of format for IE "Response from

SIM" F 3.3.0

NP-000100 24.008 095 1 3.2.1 UMTS security parameters, Combined reject causes for CS and PS C 3.3.0NP-000097 24.008 096 1 3.2.1 Clarification of NITZ time stamp coding A 3.3.0NP-000100 24.008 099 1 3.2.1 Authentication Reject from MS C 3.3.0NP-000092 24.008 107 1 3.2.1 Abnormal cases in Service Request procedure B 3.3.0NP-000093 24.008 109 3.2.1 Service Request procedure in the chapter 4.1.1 B 3.3.0NP-000093 24.008 111 3.2.1 Removal of Anonymous access C 3.3.0NP-000099 24.008 113 1 3.2.1 Abnormal cases for TFT handling, TFT IE maximum length C 3.3.0NP-000099 24.008 114 3 3.2.1 Compact coding of QoS IE C 3.3.0NP-00093 24.008 116 1 3.2.1 Paging response in 4.7.9 F 3.3.0NP-000091 24.008 117 3.2.1 Removal of APN from REQUEST PDP CONTEXT ACTIVATION

REJECT message A 3.3.0

NP-000157 24.008 118 4 3.2.1 Integrity checking of MM and GMM messages C 3.3.0NP-000091 24.008 119 1 3.2.1 Corrections to SN-PDU IE length in GMM messages A 3.3.0NP-000091 24.008 120 1 3.2.1 Interpretation of CM service reject in MS supporting GPRS services A 3.3.0NP-000101 24.008 123 3.2.1 GSM Cleanup – Removal of V.23 C 3.3.0NP-000100 24.008 125 1 3.2.1 Alignment of the procedure "Authentication not accepted by the MS" in

MM and GMM C 3.3.0

NP-000092 24.008 127 3.2.1 Clarification to the MS handling when receiving detach type 'IMSI detach'.

F 3.3.0

NP-000094 24.008 129 2 3.2.1 Proposal of Classmark 1 and 2 for UMTS F 3.3.0NP-000094 24.008 130 1 3.2.1 Proposal of MS network capability for UMTS F 3.3.0NP-000101 24.008 131 1 3.2.1 Extended Transaction Identifier F 3.3.0NP-000089 24.008 133 1 3.2.1 Marking of ASCI descriptions D 3.3.0NP-000094 24.008 134 1 3.2.1 Clarifying the presence of the Classmark 2 IE in the LOCATION

UPDATE REQUEST message. C 3.3.0

NP-000092 24.008 135 1 3.2.1 Support of high speed data in UMTS/UTRAN C 3.3.0NP-000091 24.008 139 1 3.2.1 Collision of network initiated Detach with the attach and RAU procedure A 3.3.0NP-000091 24.008 140 3.2.1 Conditions when to start the GMM timer T3321 A 3.3.0NP-000093 24.008 141 3.2.1 SM IEI value F 3.3.0NP-000092 24.008 142 1 3.2.1 Initial value for T3302 F 3.3.0NP-000093 24.008 144 3.2.1 NAS System Information with T3312 included in the CS domain specific

part C 3.3.0

NP-000092 24.008 145 1 3.2.1 Intersystem change GSM <-> UMTS C 3.3.0NP-000093 24.008 146 1 3.2.1 Paging response in UMTS C 3.3.0NP-000092 24.008 147 3.2.1 Corrections to Service Request procedure C 3.3.0NP-000100 24.008 155 1 3.2.1 Alignment of the AUTN and Authentication Failure Parameter length C 3.3.0NP-000095 24.008 157 2 3.2.1 Multicall Information in Call Control Capability IE C 3.3.0NP-000092 24.008 158 1 3.2.1 Duplicated PDP context activation C 3.3.0NP-000093 24.008 159 1 3.2.1 Presence of TFT IE in Activate Secondary PDP Context Request C 3.3.0NP-000092 24.008 160 3.2.1 Correction of length of TI D 3.3.0NP-000099 24.008 162 1 3.2.1 Deletion/modification of primary PDP context F 3.3.0NP-000100 24.008 163 1 3.2.1 Clarifications on the GMM Authentication procedure F 3.3.0NP-000100 24.008 164 3.2.1 Handling of GPRS keys at intersystem change F 3.3.0NP-000100 24.008 165 3.2.1 Handling of CS keys at intersystem change F 3.3.0NP-000092 24.008 168 2 3.2.1 DRX parameter for UMTS C 3.3.0NP-000101 24.008 170 3.2.1 Correction of static conditions for BC IE contents F 3.3.0NP-000100 24.008 171 2 3.2.1 Clarifications on the MM Authentication procedure F 3.3.0NP-000089 24.008 177 3.2.1 Addition of cause value # 25 'Pre-emption' A 3.3.0NP-000095 24.008 178 2 3.2.1 Introduction of NW CC Capability for Multicall B 3.3.0

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 456


NP-000092 24.008 179 3.2.1 Correction of Service request procedure after the collision with Detach procedure

F 3.3.0

NP-000098 24.008 180 1 3.2.1 Introduction of UMTS AMR B 3.3.0NP-000101 24.008 181 3.2.1 Removal of X.25 for packet domain services C 3.3.0NP-000091 24.008 182 2 3.2.1 Usage of cause code IE in network initiated detach A 3.3.0NP-000130 24.008 183 3.2.1 Moving NOTIFICATION RESPONSE from MM to GSM RR A 3.3.0- - - - 3.3.0 Editorial corrections - 3.3.1

3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 457

TSG # TSG Tdoc N1-Tdoc Spec CR Rev

Rel Cat

Old Vers

New Vers

Subject WI

NP-08 NP-000273 24.008 137 1 R99 C 3.3.1 3.4.0 MS behaviour when detecting a ‘bad’ network from an authentication challenge

NP-08 NP-000274 24.008 176 2 R99 C 3.3.1 3.4.0 Clarification of reference to Q.931 for LLC IE NP-08 NP-000270 24.008 184 1 R99 C 3.3.1 3.4.0 Introduction of 3G MS capabilities in MS

Classmark 3 (Introduction of 3G MS capabilities in MS Classmark 3)

NP-08 NP-000268 24.008 185 R99 F 3.3.1 3.4.0 Alignment on ISDN BC Coding NP-08 NP-000272 24.008 187 1 R99 F 3.3.1 3.4.0 Additional SDU error rate value NP-08 NP-000272 24.008 188 R99 F 3.3.1 3.4.0 TFT IE length and editorials NP-08 NP-000270 24.008 189 1 R99 F 3.3.1 3.4.0 DRX value 0000 clarification and R97

compatibility issue

NP-08 NP-000270 24.008 190 1 R99 F 3.3.1 3.4.0 Compatibility issue due to deletion of SM cause #35

NP-08 NP-000274 24.008 191 R99 F 3.3.1 3.4.0 References and editorial corrections to 24.008

NP-08 NP-000269 24.008 193 1 R99 F 3.3.1 3.4.0 MODIFY PDP CONTEXT REJECT –message definition

NP-08 NP-000270 24.008 194 1 R99 F 3.3.1 3.4.0 Clarifications on GSM – UMTS interoperability

NP-08 NP-000270 24.008 195 2 R99 F 3.3.1 3.4.0 MS behavior if RAU attempt counter is greater than or equal to 5

NP-08 NP-000271 24.008 196 R99 C 3.3.1 3.4.0 Applicability of CS Multimedia to GSM NP-08 NP-000279 24.008 201 1 R99 F 3.3.1 3.4.0 COMPACT Mobile Station Interference

Measurements Capability

NP-08 NP-000270 24.008 203 R99 F 3.3.1 3.4.0 Editorial corrections to MM and GMM in 24.008

NP-08 NP-000266 24.008 204 R99 F 3.3.1 3.4.0 Removal of P-TMSI signature in Service Request message

NP-08 NP-000273 24.008 207 1 R99 F 3.3.1 3.4.0 Integrity checking of MM/GMM messages and integrity protection during emergency call

NP-08 NP-000269 24.008 208 3 R99 F 3.3.1 3.4.0 Change of the GMM Ready Timer behaviour NP-08 NP-000269 24.008 209 R99 F 3.3.1 3.4.0 Network behaviour, abnormal cases detach NP-08 NP-000269 24.008 210 R99 F 3.3.1 3.4.0 IEI value of the 'Tear down indicator' IE NP-08 NP-000267 24.008 211 1 R99 F 3.3.1 3.4.0 Addition of PFC Feature and Extended GEA

in MS Network Capability IE R99 for NP-000303(R98) and NP-000392 (R97)

NP-08 NP-000272 24.008 212 R99 F 3.3.1 3.4.0 Reserve one bit in PFI NP-08 NP-000273 24.008 213 1 R99 C 3.3.1 3.4.0 Alignment of CC and SM protocols with

current MM/GMM integrity protection rules

NP-08 NP-000269 24.008 214 R99 C 3.3.1 3.4.0 Modification of MS Classmark 3 and modification of MS RA Capabilities, for DTM mobile stations.

NP-08 NP-000270 24.008 215 R99 F 3.3.1 3.4.0 Correction of references in protocol error handling for SM

NP-08 NP-000273 24.008 216 2 R99 F 3.3.1 3.4.0 Correction of the MM Authentication procedure

NP-08 NP-000273 24.008 217 1 R99 F 3.3.1 3.4.0 Correction of the GMM Authentication and ciphering procedure

NP-08 NP-000274 24.008 218 3 R99 B 3.3.1 3.4.0 Addition of “Cause of No CLI” IE in SETUP message

NP-08 NP-000270 24.008 220 1 R99 F 3.3.1 3.4.0 Modification of QoS to support max 0kbps NP-08 NP-000270 24.008 221 2 R99 F 3.3.1 3.4.0 Recovery from PDP context inconsistency NP-08 NP-000269 24.008 222 1 R99 A 3.3.1 3.4.0 Clarification on local and foreign TLLI

management

- - - - - - - - 3.4.0 3.4.1 Editorial changes -

NP-9 NP-000443 N1-001012 24.008 229 1 R99 F 3.4.1 3.5.0 P-TMSI signature handling GSM/UMTS Interworking

NP-9 NP-000445 N1-000996 24.008 230 1 R99 F 3.4.1 3.5.0 Network Authentication Failure Security NP-9 NP-000443 N1-000988 24.008 233 1 R99 F 3.4.1 3.5.0 DRX IE as mandatory IE for RAU GSM/UMTS

interworkingNP-9 NP-000443 N1-000895 24.008 235 R99 F 3.4.1 3.5.0 New cause for Modify PDP Context

Reject GSM/UMTS Interworking

NP-9 NP-000443 N1-001042 24.008 236 2 R99 F 3.4.1 3.5.0 Reaction to duplicated PDP context activation

GSM/UMTS Interworking

NP-9 NP-000443 N1-001014 24.008 238 1 R99 F 3.4.1 3.5.0 Editorial Modification on SM state transition model


3GPP

3GPP TS 24.008 V3.5.0 (2000-09)Release 1999 458

TSG # TSG Tdoc N1-Tdoc Spec CR Rev

Rel Cat

Old Vers

New Vers

Subject WI

NP-9 NP-000440 N1-000912 24.008 242 R99 F 3.4.1 3.5.0 Wrong reference after 04.08 split TEI NP-9 NP-000443 N1-000905 24.008 243 R99 F 3.4.1 3.5.0 Editorial correction of figure in QoS IE GSM/UMTS

InterworkingNP-09 NP-000436 N1-001001 24.008 244 2 R99 F 3.4.1 3.5.0 Clarification to Service Request

procedure GSM/ UMTS Interworking

NP-09 NP-000438 N1-000929 24.008 247 R99 A 3.4.1 3.5.0 Deletion of references to OSP:IHOSS for R99


NP-9 NP-000443 N1-001016 24.008 248 1 R99 F 3.4.1 3.5.0 Editorial corrections GSM/UMTS Interworking

NP-9 NP-000439 N1-000936 24.008 249 R99 A 3.4.1 3.5.0 Missing P-TMSI reallocation after Attach or RAU

GPRS

NP-9 NP-000443 N1-001034 24.008 251 2 R99 F 3.4.1 3.5.0 Introduction of 3G Radio Access Technology capabilities in the MS Radio Access Capability IE


NP-9 NP-000445 N1-000948 24.008 252 R99 F 3.4.1 3.5.0 Modifications to the authentication failure procedure

Security

NP-9 NP-000442

N1-001021 24.008 254 1 R99 F 3.4.1 3.5.0 3.1 kHz multimedia calls at 33.6 kbit/s data rate

Multimedia

NP-9 NP-000443 N1-001033 24.008 255 3 R99 F 3.4.1 3.5.0 Duplicated PDP context activation and clarification of TI related issues.

GSM/ UMTS Interworking

NP-9 NP-000446 N1-000968 24.008 260 R99 F 3.4.1 3.5.0 MS Classsmark 3 Tidy-up MS Classmark

NP-9 NP-000445 N1-000993 24.008 261 R99 F 3.4.1 3.5.0 Correction of the storage of the ciphering key

Security

Documents

3GPP TS 24.008 V3.5 - 株式会社QT Packet services in UMTS (UMTS only) UMTS内でのパケットサービス（UMTS のみ）.....29 2 Normative references..... 29 2.1 2.1.1 Random