3GPP TS 29.010 V3.10.0 (2002-12)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network;
Information element mapping between Mobile Station - Base
Station System (MS - BSS) and Base Station System - Mobileservices Switching Centre (BSS - MSC);
Signalling procedures and the Mobile Application Part (MAP)
(Release 1999)
R
GLOBAL SYSTEM FOR
MOBILE COMMUNICATIONS
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.
Release 1999
2
3GPP TS 29.010 V3.10.0 (2002-12)
Keywords
UMTS, GSM, network, MAP, SS7, protocol
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.
© 2003, 3GPP Organizational Partners (ARIB, CWTS, ETSI, T1, TTA, TTC).
All rights reserved.
3GPP
Release 1999
3
3GPP TS 29.010 V3.10.0 (2002-12)
Contents
Foreword ............................................................................................................................................................5
1
Scope ........................................................................................................................................................6
1.1
1.2
References ............................................................................................................................................................... 6
Abbreviations .......................................................................................................................................................... 7
2
Classification of interworking cases ........................................................................................................7
2.1
2.2
Transparent procedures ........................................................................................................................................... 7
Non-transparent procedures..................................................................................................................................... 7
3
Interworking in the MSC, Transparent case.............................................................................................8
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
General .................................................................................................................................................................... 8
Routeing area updating.......................................................................................................................................... 10
Authentication ....................................................................................................................................................... 11
Retrieval of the IMSI from the MS ....................................................................................................................... 12
Reallocation of TMSI ............................................................................................................................................ 12
Retrieval of the IMEI from the MS ....................................................................................................................... 13
Tracing subscriber activity .................................................................................................................................... 13
Location update ..................................................................................................................................................... 14
4
Non-transparent cases ............................................................................................................................15
4.1
General .................................................................................................................................................................. 15
4.2
Outgoing call set-up (MS originating call)............................................................................................................ 15
4.3
Incoming call set-up (MS terminating call)........................................................................................................... 19
4.4
Cipher mode setting............................................................................................................................................... 20
4.5
Inter-MSC Handover ............................................................................................................................................. 21
4.5.1
Basic Inter-MSC Handover.............................................................................................................................. 21
4.5.2
Subsequent Inter-MSC Handover back to MSC-A.......................................................................................... 27
4.5.3
Subsequent Inter-MSC Handover to third MSC .............................................................................................. 31
4.5.4
BSSAP Messages transfer on E-Interface........................................................................................................ 35
4.5.5
Processing in MSC-B, and information transfer on E-interface ...................................................................... 36
4.5.5.1
Encryption Information.................................................................................................................................... 37
4.5.5.2
Channel Type................................................................................................................................................... 37
4.5.5.3
Classmark ........................................................................................................................................................ 38
4.5.5.4
Downlink DTX-Flag........................................................................................................................................ 38
4.5.5.5
Priority ............................................................................................................................................................. 39
4.5.5.6
MSC/BSC-Invoke Trace Information Elements .............................................................................................. 39
4.5.5.7
LSA Identifier List........................................................................................................................................... 39
4.5.5.8
Selected UMTS Algorithm .............................................................................................................................. 39
4.5.5.9
Allowed UMTS Algorithms ............................................................................................................................ 39
4.5.5.10
BSSMAP Service Handover ...................................................................................................................... 40
4.5.5.11
RANAP Service Handover......................................................................................................................... 40
4.5.6
Overview of the Technical Specifications GSM interworking for the Inter-MSC Handover .......................... 41
4.6
Inter-MSC Handover (UMTS to GSM)................................................................................................................. 42
4.6.1
Basic Inter-MSC Handover.............................................................................................................................. 42
4.6.2
Subsequent Inter-MSC Handover from 3G-MSC-B back to MSC-A........................................................... 48
4.6.3
Subsequent Inter-MSC Handover to third MSC .............................................................................................. 52
4.6.4
BSSAP Messages transfer on E-Interface........................................................................................................ 56
4.6.5
Processing in MSC-B, and information transfer on E-interface ...................................................................... 56
4.6.6
Cause Code Mapping....................................................................................................................................... 57
4.7
Inter-MSC Handover (GSM to UMTS)................................................................................................................. 58
4.7.1
Basic Inter-MSC Handover.............................................................................................................................. 59
4.7.2
Subsequent Inter-MSC Handover from MSC-B back to 3G_MSC-A ............................................................. 65
4.7.3
Subsequent Inter-MSC Handover to third MSC .............................................................................................. 69
4.7.4
BSSAP Messages transfer on E-Interface........................................................................................................ 72
4.7.4.1
Assignment ...................................................................................................................................................... 73
4.7.4.2
Cipher Mode Control ....................................................................................................................................... 74
4.7.4.3
Location Reporting Control ............................................................................................................................. 75
4.7.5
Processing in 3G_MSC-B, and information transfer on E-interface................................................................ 75
3GPP
Release 1999
4
3GPP TS 29.010 V3.10.0 (2002-12)
4.7.5.1
Encryption Information.................................................................................................................................... 75
4.7.5.2
Channel Type................................................................................................................................................... 75
4.7.5.3
Classmark ........................................................................................................................................................ 76
4.7.5.4
Priority ............................................................................................................................................................. 76
4.7.5.5
MSC-Invoke Trace Information Elements....................................................................................................... 76
4.7.5.6
Selected UMTS Algorithm .............................................................................................................................. 76
4.7.5.7
Allowed UMTS Algorithms ............................................................................................................................ 77
4.7.5.8
BSSMAP Service Handover ............................................................................................................................ 77
4.7.5.9
RANAP Service Handover .............................................................................................................................. 77
4.7.6
Cause Code Mapping....................................................................................................................................... 78
4.8
Inter-MSC Relocation ........................................................................................................................................... 81
4.8.1
Basic Inter-MSC Relocation ............................................................................................................................ 81
4.8.2
Subsequent Inter-MSC Relocation back to 3G_MSC-A.................................................................................. 86
4.8.3
Subsequent Inter-MSC Relocation to third MSC............................................................................................. 90
4.8.4
RANAP Messages transfer on E-Interface ...................................................................................................... 93
4.8.5
Processing in 3G_MSC-B, and information transfer on E-interface................................................................ 94
4.8.5.1
Integrity Protection Information ...................................................................................................................... 94
4.8.5.2
Encryption Information.................................................................................................................................... 95
4.8.5.3
RAB Parameters .............................................................................................................................................. 95
4.8.5.4
Channel Type................................................................................................................................................... 95
4.8.5.5
Selected GSM Algorithm................................................................................................................................. 95
4.8.5.6
Allowed GSM Algorithms............................................................................................................................... 96
4.8.5.7
Chosen Channel ............................................................................................................................................... 96
4.8.5.8
BSSMAP Service Handover ............................................................................................................................ 97
4.8.5.9
RANAP Service Handover .............................................................................................................................. 97
4.8.6
Overview of the Technical Specifications 3GPP interworking for the Inter-MSC Relocation........................ 98
4.9
Location Services .................................................................................................................................................. 99
4.9.1
Completed Location Acquisition ..................................................................................................................... 99
4.9.1.1
Inter-MSC Handover (GSM to GSM) ............................................................................................................. 99
4.9.1.2
Inter-MSC Handover (GSM to UMTS) ......................................................................................................... 100
4.9.1.3
Inter-MSC Handover (UMTS to GSM) ......................................................................................................... 102
4.9.1.4
Inter-MSC SRNS Relocation......................................................................................................................... 103
4.9.2
Cause Code Mapping..................................................................................................................................... 106
4.9.2.1
Inter-MSC Handover(GSM to GSM) ............................................................................................................ 106
4.9.2.2
Inter-MSC Handover (GSM to UMTS) ......................................................................................................... 107
4.9.2.3
Inter-MSC Handover (UMTS to GSM) ......................................................................................................... 107
4.9.2.4
Inter-MSC SRNS Relocation......................................................................................................................... 107
4.9.3
Aborted Location Acquisition........................................................................................................................ 109
4.9.3.1
Inter-MSC Handover (GSM to GSM) ........................................................................................................... 109
4.9.3.2
Inter-MSC Handover (GSM to UMTS) ......................................................................................................... 110
4.9.3.3
Inter-MSC Handover (UMTS to GSM) ......................................................................................................... 111
4.9.6.4 Inter-MSC SRNS Relocation.............................................................................................................................. 111
Annex A (informative):
Change history .............................................................................................112
3GPP
Release 1999
5
3GPP TS 29.010 V3.10.0 (2002-12)
Foreword（はじめに）
This Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP).
本技術仕様書（TS）は、3GPP（the 3rd Generation Partnership Project）によって作成された。
The present document specifies Information element mapping between Mobile Station - Base Station System
(MS - BSS) and Base Station System - Mobile-services Switching Centre (BSS - MSC) Signalling procedures and the
Mobile Application Part (MAP) within the digital cellular telecommunications system.
本ドキュメントは、ディジタルセルラ通信システム内において、MS(Mobile Station)-BSS(Base Station System)間のシ
グナリング処理およびMAP（Mobile Application Part）と、BSS-MSC(Mobile-services Switching Centre)間のそれらと
の間の、情報エレメント（IE）のマッピングについて規定する。
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 the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
本ドキュメントの内容は、TSG内で現在継続中の作業の対象であり、正式なTSGの承認手続きに従って変更されるこ
とがある。本ドキュメントの内容が変更された場合には、TSGによって再リリースが行なわれ、リリース日の変更によ
って識別されると共に、以下のように版数が増やされる：
Version x.y.z
where:
x the first digit:
x 1桁目
1 presented to TSG for information;
1はinformationとしてTSGに提出されたドキュメントであることを示す
2 presented to TSG for approval;
2はapproval（承認）のためにTSGに提出されたドキュメントであることを示す
3 or greater indicates TSG approved document under change control.
3以上はTSGにおいて承認済であり、そこで改版管理が行なわれているドキュメントであることを示す
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
y 2桁目はあらゆる内容の修正、すなわち技術的強化、修正、改版などがあった場合に漸増される
z the third digit is incremented when editorial only changes have been incorporated in the document.
z 3桁目は編集上の修正だけがドキュメントに反映された場合に漸増される
3GPP
Release 1999
1
6
3GPP TS 29.010 V3.10.0 (2002-12)
Scope（本ドキュメントのスコープ）
The scope of the present document is:
本ドキュメントのスコープは以下の通り：
i) to provide a detailed specification for the interworking between information elements contained in layer 3
messages sent on the MS-MSC interface (Call Control and Mobility Management parts of 3GPP TS 24.008) and
parameters contained in MAP services sent over the MSC-VLR interface (3GPP TS 29.002) where the MSC acts
as a transparent relay of information;
MSCが情報を透過的にリレーする場合に、MS-MSC間インタフェース上で送信されるL3のメッセージ中に含ま
れる情報エレメント（3GPP TS 24.008内のCall ControlおよびMobility Managementのパート参照）と、MSCVLR間インタフェース上で送信されるMAPサービス中に含まれるパラメータ（3GPP TS 29.002参照）との間の
インターワーキングに関する詳細な仕様を提供すること
ii) to provide a detailed specification for the interworking between information elements contained in BSSMAP
messages sent on the BSC-MSC interface (3GPP TS 48.008) and parameters contained in MAP services sent
over the MSC-VLR interface (3GPP TS 29.002) where the MSC acts as a transparent relay of information;
MSCが情報を透過的にリレーする場合に、BSC-MSCインタフェース上で送信されるBSSMAPメッセージ中に
含まれる情報エレメント（3GPP TS 48.008参照）と、MSC-VLR間インタフェース上で送信されるMAPサービス
中に含まれるパラメータとの間のインターワーキングに関する詳細な仕様を提供すること
iii) to provide a detailed specification for the interworking between information elements contained in BSSMAP
messages (3GPP TS 48.008) and RANAP (25.413)
BSSMAPメッセージ（3GPP TS 48.008参照）とRANAPメッセージ（25.413参照）中に含まれる情報エレメント間
のインターワーキングに関する詳細な仕様を提供すること
iv) to provide a detailed specification for the interworking as in i) and ii) above when the MSC also processes the
information.
MSCが情報を処理する場合に関しても、上記のi) およびii) のようなインターワーキングに関する詳細な仕様
を提供すること
Interworking for supplementary services is given in 3GPP TS 29.011. Interworking for the short message service is
given in 3GPP TS 23.040 and 3GPP TS 24.011. Interworking between the call control signalling of 3GPP TS 24.008
and the PSTN/ISDN is given in GSM 09.03, 3GPP TS 29.007 and 3GPP TS 49.008. Interworking between the 'A' and
'E' interfaces for inter-MSC handover signalling is given in 3GPP TS 29.007 and 3GPP TS 49.008.
付加サービスのインターワーキングについては、3GPP TS 29.011で与えられる。ショートメッセージサービスのインタ
ーワーキングについては、3GPP TS 23.040 および3GPP TS 24.011で与えられる。3GPP TS 24.008の呼制御シグナ
リングとPSTN/ISDNとの間のインターワーキングについては、GSM 09.03、3GPP TS 29.007、そして3GPP TS 49.008
で与えられる。MSC間ハンドオーバシグナリングのための、AインタフェースとEインタフェース間のインターワーキン
グについては、3GPP TS 29.007および3GPP TS 49.008で与えられる。
1.1
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. In the case of a reference to a 3GPP document
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document in
the same Release as the present document.
3GPP
Release 1999
7
3GPP TS 29.010 V3.10.0 (2002-12)
特定できないリファレンスについては、最新版を適用する。3GPPのドキュメント（GSMのドキュメントを含む）を
参照する場合には、非特定のリファレンスは暗黙の了解として、本ドキュメントと同一リリースの、最新版を参
照する
[1]
3GPP TS 21.905: "3G Vocabulary".
[2]
3GPP TS 23.009: "Handover procedures".
[3]
3GPP TS 23.040: "Technical realization of the Short Message Service (SMS) Point to Point (PP)".
[4]
3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols-Stage
3".
[5]
3GPP TS 24.010: "Mobile radio interface layer 3 Supplementary services specification - General
aspects".
[6]
3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio
interface".
[7]
3GPP TS 25.413: "Iu interface RANAP signalling".
[8]
3GPP TS 27.001: " General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)".
[9]
3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[10]
3GPP TS 29.007: "General requirements on interworking between the Public Land Mobile
Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched
Telephone Network (PSTN)".
[11]
3GPP TS 29.011: "Digital cellular telecommunications system (Phase 2+); Signalling interworking
for supplementary services".
[12]
3GPP TS 48.008: " Mobile Switching Centre - Base Station System (MSC - BSS) interface
Layer 3 specification".
[13]
GSM 09.03: "Digital cellular telecommunications system (Phase 2+); Signalling requirements on
interworking between the Integrated Services Digital Network (ISDN) or Public Switched
Telephone Network (PSTN) and the Public Land Mobile Network (PLMN)".
[14]
3GPP TS 49.008: " Application of the Base Station System Application Part (BSSAP) on the Einterface".
[15]
3GPP TS 29.108: "Application of the Radio Access Network Application Part (RANAP) on the
E-interface"
[16]
3GPP TS 23.071: " Location Services (LCS); (Functional description) – Stage 2"
[17]
3GPP TS 23.171: "Functional stage 2 description of location services in UMTS"
1.2
Abbreviations（略語）
Abbreviations used in the present document are listed in 3GPP TS 21.905.
本ドキュメント内で使用される略語は、3GPP TS 21.905にリストアップされる。
3GPP
Release 1999
8
2
Classification of interworking cases
（インターワーキングの場合分け）
2.1
Transparent procedures（透過型処理）
3GPP TS 29.010 V3.10.0 (2002-12)
The following MSC procedures require transparent mapping of access protocol information elements into MAP
parameters and vice versa (see 3GPP TS 29.002 for definitions and the use of the procedures):
次に挙げるMSCでの処理は、アクセスプロトコルの情報エレメント（以下、IEと略）からMAPのパラメータへのマッピン
グが必要であり、またその逆も真である（これらの処理の定義および使用方法については3GPP TS 29.002参照）。
-
location update;
ロケーションのアップデート
-
forward new TMSI;
新しいTMSIの転送
-
provide IMSI;
IMSIの提供
-
obtain IMEI;
IMSIの取得
-
check IMEI;
IMSIのチェック
-
authenticate;
認証
-
trace subscriber activity.
加入者アクティビティのトレース
2.2
Non-transparent procedures（非透過型処理）
Procedures in this class require processing in the MSC and information element mapping. These procedures include
those related to:
本クラスに属する処理は、MSC内での処理と、IEのマッピングを必要とする。次の処理に関連する処理が含まれる：
-
outgoing call set-up;
発信呼のセットアップ
-
incoming call set-up;
着信呼のセットアップ
-
handover;
ハンドオーバ
-
cipher mode setting;
暗号モードの設定
-
location services.
ロケーションサービス
3GPP
Release 1999
9
3GPP TS 29.010 V3.10.0 (2002-12)
3
Interworking in the MSC, Transparent case
（MSC内のインターワーキング、透過型処理）
3.1
General（概要）
When the MSC receives a forward message from the BSS (possibly forwarded transparently from the MS), it will
invoke the desired MAP service and establish a cross reference between the BSSAP procedure and the MAP procedure
in order to return the result of the operation to the BSS (which may forward it transparently to the MS. The cross
reference is deleted when the MSC terminates the MAP procedure.
BSSからの転送メッセージ（MSから透過的に転送される可能性もある）を受信したMSCは、要求されたMAPサービス
を起動して、BSSにオペレーション結果を返す（MSに透過的に転送される可能性もある）ためにBSSAP処理とMAP処
理の間でクロスリファレンスを確立する。MSCがMAP処理を終了すると、クロスリファレンスは削除される。
Positive or negative results of the MAP procedure are returned in the appropriate BSSAP message.
MAP処理のポジティブまたはネガティブな結果は、適切なBSSAPメッセージ内に入れて返される。
The parameters of the forward BSSAP message are mapped by a one-to-one mapping into the parameters of the MAP
service. However, in some cases parameters received on the radio path may be suppressed at the MSC because they are
related to another protocol entity, e.g. information related to RR-management may be included in MM-management
messages. Similarly, parameters received in the (positive) MAP service response are mapped one-to-one into
parameters of the corresponding backward BSSAP message.
forward BSSAPメッセージのパラメータは、MAPサービスのパラメータに、１対１でマッピングされる。ただし、いくつか
のケースでは、無線回線上で受信したパラメータは、他のプロトコルエンティティに関連するものであるために、MSC
で削除される場合がある。例えばRR管理関連の情報は、MM管理メッセージ内に含めることができる。同様に、（ポ
ジティブな）MAP応答中で受信したパラメータは、対応するbackward BSSAPメッセージのパラメータに、１対１でマッ
ピングされる。
A negative outcome, as carried in various MAP services (MAP specific service response, MAP_U_ABORT,
MAP_P_ABORT, MAP_NOTICE and premature MAP_CLOSE, see 3GPP TS 29.002 for definitions) is mapped into a
cause value in the required backward BSSAP message. In this case several negative results of MAP may be mapped
into the same BSSAP cause value, i.e. without discrimination between these negative results.
ネガティブな結果は、多種多様なMAPサービス（MAP固有のサービス応答、MAP_U_ABORT、MAP_P_ABORT、
MAP_NOTICE、およびpremature MAP_CLOSE。定義については3GPP TS 29.002参照）で運ばれるので、要求され
たbackward BSSAPメッセージ中の理由値にマッピングされる。この場合、複数のネガティブなMAP結果を、同一の
BSSAP理由値にマッピングすることもできる。すなわち、これらのネガティブな結果は区別されない。
NOTE:
For O & M purposes, the MAP procedure entity in the MSC may require a more detailed overview of
negative results than the MS.
O&Mの観点からは、MSC内のMAP処理エンティティはMSが要求するよりも詳細な、ネガティブな結果
の概要を要求することもできる。
3GPP
Release 1999
10
3GPP TS 29.010 V3.10.0 (2002-12)
These principles are illustrated in figure 1.
これらの原則をイラスト化したものが図1である。
24.008 (08.08)
MAP service
forward message
request
------------>
----------->
+-----------+
+---------+
|information|
|parameter|
| element |
|
|
+-----------+
one-to-one
+---------+
+----->-------------------------------->----+
mapping
MAP service
positive ack
response
<-----------<----------+-----------+
+---------+
|information|
|parameter|
| element |
|
|
+-----------+
one-to-one
+---------+
+-----<--------------------------------<----+
mapping
negative
negative cause
response
<-----------<----------+-----------+
+---------+
|
cause
|
| cause |
+-----------+
one-to-one or many-to-one
+---------+
+-----<--------------------------------<----+
mapping
Figure 1: Illustration of mapping principles in the MSC
図１：MSC内におけるマッピング原則のイラスト
For each of the transparent operations listed in subclause 2.1, the following format is used to show the mapping.
2.1節でリストアップされた個々の透過型オペレーションについては、以下のフォーマットを使用してマッピング方法を
示す。
---------------------------------------------------------------| 24.008 or 08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | MS/BSS to MSC
MSC to VLR
|
message |
message name
MAP service request |
| information element 1 <---> parameter 1
|
| information element 2 <---> parameter 2
|
--------┼-------------------------------------------------┼----Positive| MSC to MS/BSS
VLR to MSC
|
result |
message name
positive response |
| information element 1 <---> parameter 1
|
| information element 2 <---> parameter 2
|
--------┼-------------------------------------------------┼----Negative| MSC to MS/BSS
VLR to MSC
|
result |
message name
negative response |
|
cause 1
<--->
cause 1
|
|
cause 2
<--->
cause 2
|
|
cause 3
<---> MAP_U/P_ABORT
|
|
cause 3
<---> MAP_NOTICE
|
|
cause 3
<--->
MAP_CLOSE
|
--------┴-------------------------------------------------┴-----
Equivalent mapping principles apply for operations invoked by the VLR towards the BSS/MS. However, negative
results are generally not received from the BSS/MS but are generated in the MSC. Therefore, for such operations the
interworking for negative results is not normally shown.
VLRがBSSまたはMSに対してオペレーションを起動する場合でも、同じマッピングの原則が適用される。ただし、ネ
ガティブな結果は、通常はBSSまたはMSから受信されることはなく、MSC内で生成される。であるから、そのようなオ
ペレーションについては、ネガティブな結果用のインターワーキングは通常、示されることはない。
3GPP
Release 1999
3.2
11
3GPP TS 29.010 V3.10.0 (2002-12)
Routeing area updating（ルーチングエリアの更新）
--------------------------------------------------------------|
24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | GMM (ROUTEING AREA
MAP_UPDATE_GPRS
_ |
message |
UPDATE REQUEST)
LOCATION request
|
|
|
|
MS classmark 1
|
|
MS classmark 4
|
|
GPRS Ciphering
|
|
key seq number
|
|
Mobile station
IMSI
|
|
identity
|
|
Old routeing area
|
|
identification
|
--------┼------------------------------------------------┼----Positive| GMM (ROUTEING AREA
MAP_UPDATE_GPRS
|
results |
UPDATE ACCEPT)
LOCATION response |
|
|
|
Routeing area
|
|
identification
|
|
Mobile station
| 1
|
identity
|
| C Mobile station
|2
| C Reject: IMSI unknown
| 3
|
in HLR
|
| C Reject: MSC temporarily
| 4
|
not reacheable
|
--------┼------------------------------------------------┼----Negative| GMM (ROUTEING AREA
MAP_UPDATE_GPRS
|
results |
UPDATE REJECT)
LOCATION response |
|
|
|
Network failure
| 5
|
GPRS services
Unknown HLR
|
|
not allowed in
|
|
this PLMN
|
|
GPRS services
Unknown subscriber
| 6
|
not allowed
(no GPRS subscription) |
|
GPRS services and
Unknown subscriber
| 7
|
non GPRS services
(IMSI unknown)
|
|
not allowed
|
| C GPRS services
Unknown subscriber
| 8
|
not allowed
(no GPRS subscription) |
| C GPRS services and
Unknown subscriber
| 9
|
non-GPRS services
(IMSI unknown)
|
|
not allowed
|
|
MS identity cannot
| 10
|
be derived by
|
|
the network
|
|
Roaming not allowed: |
|
GPRS services not
PLMN not allowed |
│
allowed in this
│
│
PLMN
│
|
LA not allowed
|
|
Roaming not allowed
|
|
in this LA
|
|
No Suitable cells in
| 11
|
location area
|
|
GPRS services not
Operator
|
|
allowed in this
determined barring|
│
PLMN
│
|
Illegal MS
|
|
Illegal ME
|
|
Network failure
System Failure
|
|
Network failure
Unexpected data value|
|
Network failure
MAP_U/P_ABORT
|
|
Network failure
MAP_NOTICE
|
|
Network failure
MAP_CLOSE
|
--------┴------------------------------------------------┴-----
3GPP
Release 1999
12
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 1: The mobile station identity is inserted by the SGSN if the SGSN wants to deallocate or re-allocate a PTMSI. If the SGSN wants to deallocate the P-TMSI it shall include the IMSI. If the SGSN wants to reallocate the P-TMSI it shall include the new P-TMSI. If a P-TMSI is included, the MS shall respond with
a ROUTEING AREA UPDATE COMPLETE message.
SGSNがP-TMSIの割当取消または再割当を希望した場合、SGSNがMSのID（mobile station identity）
を挿入する。SGSNがP-TMSIの割当取消を希望した場合には、SGSNはIMSIを含めること。SGSNがPTMSIの再割当を希望した場合には、SGSNは新しいP-TMSIを含めること。P-TMSIが含まれていた場
合、MSはROUTEING AREA UPDATE COMPLETEメッセージで応答すること。
NOTE 2: The mobile station identity is inserted by the SGSN if it is received in a BSSAP+ LOCATION UPDATE
ACCEPT message from the VLR. If a TMSI is included, the MS shall respond with a ROUTEING AREA
UPDATE COMPLETE message. Only used in the Combined Routeing and Location Area procedure.
VLRからBSSAP+ LOCATION UPDATE ACCEPTメッセージ中でMSのIDを受信した場合、SGSNは
MSのIDを挿入する。TMSIが挿入された場合には、MSはROUTEING AREA UPDATE COMPLETE
メッセージで応答すること。Combined Routeing処理とLocation Area処理においてのみ使用される。
NOTE 3: This reject cause is inserted on the positive response by the SGSN if the SGSN receives a BSSAP+
LOCATION UPDATE REJECT message from the VLR indicating in the reject cause IMSI unknown in
HLR. Only used in the Combined Routeing and Location Area procedure.
HLR内でIMSI値が未知であるという拒否理由を示すBSSAP+ LOCATION UPDATE REJECTメッセー
ジを、SGSNがVLRから受信した場合、SGSNはこの否決理由をポジティブな応答上に挿入する。
Combined Routeing処理とLocation Area処理においてのみ使用される。
NOTE 4: This reject cause is inserted on the positive response by the SGSN if the SGSN does not receive any
response from the VLR to a previous BSSAP+ LOCATION UPDATE REQUEST message. Only used in
the Combined Routeing and Location Area procedure.
直前のBSSAP+ LOCATION UPDATE REQUESTメッセージに対する応答をSGSNがVLRから受信し
なかった場合には、SGSNはこの拒否理由をポジティブな応答上に挿入する。Combined Routeing処理
とLocation Area処理においてのみ使用される。
NOTE 5: The Unknown RA error is only generated as a result of incorrect information being inserted by the BSS.
Unknown RAエラーは、BSSによって不正な情報が挿入された場合にのみ、生成される。
NOTE 6: The HLR shall send Unknown subscriber with diagnostic value No GPRS subscription if the HLR
indicates that there is an error in the type of subscription (i.e. SGSN requests service for a non-GPRS only
subscriber).
HLRによって、加入者のタイプに誤りがあることが通知された（つまりSGSNが非GPRS限定加入者に対
するサービスを要求した）場合には、HLRは診断値No GPRS subscription といっしょに、Unknown
subscriberを送信すること。
NOTE 7: The HLR shall send Unknown subscriber with diagnostic value IMSI unknown if the HLR indicates that
the IMSI provided by the SGSN is unknown.
HLRによって、SGSNが提供してIMSI値が未知であることが通知された場合には、HLRは診断値IMSI
unknownといっしょにUnknown subscriberを送信すること。
NOTE 8: The HLR shall send Unknown subscriber with diagnostic value No GPRS subscription if the HLR
indicates that there is an error in the type of subscription (i.e. SGSN requests service for a non-GPRS only
subscriber). Used in the Combined Routeing and Location Area procedure.
HLRによって、加入者のタイプに誤りがあることが通知された（つまりSGSNが非GPRS限定加入者に対
するサービスを要求した）場合には、HLRは診断値No GPRS subscriptionといっしょにUnknown
subscriberを送信すること。Combined Routeing処理とLocation Area処理においてのみ使用される。
NOTE 9: This reject cause is inserted if the SGSN receives a MAP GPRS UPDATE LOCATION negative response
message indicating IMSI unknown. Used in the Combined Routeing and Location Area procedure.
未知のIMSIであることを示すネガティブな応答メッセージMAP GPRS UPDATE LOCATIONをSGSNが
受信した場合には、この拒否理由が挿入されCombined Routeing処理とLocation Area処理においての
み使用される。
3GPP
Release 1999
13
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 10: This reject cause is inserted if the SGSN does not receive any response from the old SGSN to a previous
SGSN CONTEXT REQUEST message.
旧SGSNから送信された直前のSGSN CONTEXT REQUESTメッセージに対する応答をSGSNが受信し
なかった場合には、この拒否理由が挿入される。
NOTE 11 The ‘No Suitable cells in location area’ error is generated when the MS has access to only part of the
PLMN, but where there may also be suitable location areas available. The MS retries on another location
area.
MSがPLMNの一部のみに対するアクセスを有するが、PLMNに利用可能な適切なロケーションエリア
がない場合には、‘No Suitable cells in location area’ エラーが生成される。MSは他のロケーションエリ
ア上で再試行する。
3.3
Authentication（認証）
The message flow for the authentication procedure is shown in figure 2.
認証処理用のメッセージフローを図2に示す。
MS
MSC
AUTHENTICATION REQUEST
<-----------------------
VLR
MAP_AUTHENTICATE request
<----------------------------------
AUTHENTICATION RESPONSE
----------------------->
MAP_AUTHENTICATE response
---------------------------------->
or
MAP_U/P_ABORT
---------------------------------->
Figure 2: Authentication operation
図2：認証処理
The MSC can only act on a MAP_AUTHENTICATE request if an RR connection exists with the MS. If such a
connection does not exist, the MSC shall terminate the MAP procedure with a MAP_U_ABORT. The same applies if
the MS does not respond to an AUTHENTICATION REQUEST message.
MSとの間にRRコネクションが存在する場合には、MSCはMAP_AUTHENTICATE要求の中でだけ、実行することが
できる。そのようなコネクションが存在しない場合には、MSCはMAP_U_ABORTといっしょにMAP処理を終了するこ
と。MSがAUTHENTICATION REQUESTメッセージに対して応答しない場合でも、同じ規則が適用される。
--------------------------------------------------------------| 24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | AUTHENTICATION REQUEST
MAP_AUTHENTICATE
|
message |
request
|
|
|
| RAND
RAND
|
|
|
| Ciphering key seq
CKSN
|
| number
|
--------┼------------------------------------------------┼----Backward| AUTHENTICATION REQUEST
MAP_AUTHENTICATE
|
result |
response
|
|
|
| SRES
SRES
|
--------┴------------------------------------------------┴-----
If the SRES parameter does not match the value stored in the VLR, then the ongoing MAP procedure shall be
terminated with a cause 'illegal subscriber'. This shall cause the MSC to send an AUTHENTICATION REJECT
message.
SRESパラメータがVLR内に保存されている値と一致しない場合、現在進行中のMAP処理を理由値'illegal
3GPP
Release 1999
14
3GPP TS 29.010 V3.10.0 (2002-12)
subscriber'で終了させること。MSCがこの理由値を受信した場合には、AUTHENTICATION REJECTメッセージを送
信すること。
3.4
Retrieval of the IMSI from the MS（MSへのIMSI再問合せ）
The VLR may request open identification of an MS with a MAP_PROVIDE_IMSI request.
VLRは、MAP_PROVIDE_IMSI要求によって、MSのIDの開示を要求することができる。
The mapping of information elements is as follows:
IEのマッピングを以下に示す：
--------------------------------------------------------------| 24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | IDENTITY REQUEST
MAP_PROVIDE_IMSI
|
message |
request
|
|
Identity type
|
|
set to: IMSI
| 1
--------┼------------------------------------------------┼----Backward| IDENTITY RESPONSE
MAP_PROVIDE_IMSI
|
result | Mobile Identity (IMSI)
response
|
--------┴------------------------------------------------┴-----
NOTE 1: The INVOKE does not carry any parameters. The identity type is inferred from the invoke name.
INVOKE中には何もパラメータが含まれない。IDのタイプは起動名称から類推される。
The MSC shall return a MAP_PROVIDE_IMSI response with user error "absent subscriber" if:
次の場合には、MSCはユーザエラー値"absent subscriber" といっしょにMAP_PROVIDE_IMSI応答を返すこと。
-
there is no RR connection with the MS when the MAP service request is received;
MAPサービス要求受信時に、MSとのRRコネクションが存在しない場合
-
there is no response from the MS.
MSからの応答が無い場合
3.5
Reallocation of TMSI（TMSIの再割当）
This operation is invoked by the VLR. The MAP_FORWARD_NEW_TMSI request contains the new TMSI which is
forwarded to the MS in the TMSI REALLOCATION COMMAND. When the MS acknowledges the receipt of the new
TMSI, the MSC will return a MAP_FORWARD_NEW_TMSI response to the VLR.
本オペレーションはVLRによって起動される。MAP_FORWARD_NEW_TMSI要求中には、新しいTMSIが含まれて
おり、それはTMSI REALLOCATION COMMAND中でMSに転送される。新しいIMSIを受信したMSがACKを返し
たならば、その後MSCはMAP_FORWARD_NEW_TMSI応答をVLRに返す。
If there is no radio connection to the MS when the MSC receives the MAP service request, the MSC shall ignore the
message.
MSCがMAP要求受信時に無線コネクションが存在しなかった場合には、MSCはメッセージを無視すること。
3GPP
Release 1999
15
3GPP TS 29.010 V3.10.0 (2002-12)
--------------------------------------------------------------| 24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | TMSI REALLOCATION
MAP_FORWARD_NEW_TMSI
|
message |
COMMAND
request
|
|
|
| Mobile identity
TMSI
|
|
|
| Location area
|
| identification
|
--------┼------------------------------------------------┼----Backward| TMSI REALLOCATION
MAP_FORWARD_NEW_TMSI
|
result | COMPLETE
response
|
--------┴------------------------------------------------┴-----
3.6
Retrieval of the IMEI from the MS（MSへのIMEI再問合せ）
The VLR may use the MAP_OBTAIN_IMEI service to request the MS to supply its IMEI , or may use the
MAP_CHECK_IMEI service to request the MSC to check the MS's IMEI. For either MAP service the BSSAP
signalling is the same.
VLRは、MAP_OBTAIN_IMEIサービスを使用してMSに対してIMEIを開示するよう要求することもできるし、
MAP_CHECK_IMEIサービスを使用してMSCに対してMSのIMEIのチェックをを要求することもできる。どちらの
MAPサービスにおいても、BSSAPシグナリングは同一である。
The mapping of information elements is as follows:
IEのマッピングは、以下のとおり：
--------------------------------------------------------------| 24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward |
(MAP_CHECK_IMEI request
|
message | IDENTITY REQUEST
(
or
|
|
(MAP_OBTAIN_IMEI request |
|
Identity type
|
|
set to: IMEI
| 1
--------┼------------------------------------------------┼----Backward|
(MAP_CHECK_IMEI response |
result | IDENTITY RESPONSE
(
or
|
|
(MAP_OBTAIN_IMEI response |
|
|
| Mobile Identity
IMEI
| 2
|
(IMEI)
|
--------┴------------------------------------------------┴-----
NOTE 1: The MAP service request does not carry any parameters. The identity type is inferred from the service
name.
MAPサービス要求中には何もパラメータが含まれない。IDのタイプはサービス名称から類推される。
NOTE 2: If the MAP_CHECK_IMEI service was used, the MSC also returns the equipment status to the VLR in
the MAP_CHECK_IMEI response, after a successful dialogue with the EIR using the IMEI received from
the MS.
MAP_CHECK_IMEIサービスが使用された場合、MSCはMSから受信したIMEIを使用して、EIRとのダ
イヤログが正常終了した後に、MAP_CHECK_IMEI応答内でVLRへ装置のステータスも返す。
The MSC shall terminate the MAP dialogue with the VLR using a MAP_U_ABORT if:
次の場合には、MSCはMAP_U_ABORTを使用して、VLRとのMAPダイヤログを終了させること：
-
there is no RR connection with the MS when the MAP service request is received;
MAPサービス要求受信時に、MSとのRRコネクションが存在しない場合
3GPP
Release 1999
-
3GPP TS 29.010 V3.10.0 (2002-12)
there is no response from the MS.
MSからの応答が無い場合
NOTE:
3.7
16
The MSC can also obtain the IMEI from a phase 2 MS by including appropriate information in the
BSSMAP Cipher Mode Command.
Phase 2のMSに対しては、BSSMAP Cipher Mode Command中に適切な情報を含めることによって、
MSCがIMEIを取得することもできる。
Tracing subscriber activity（加入者アクティビティのトレース）
The VLR may request the MSC and/or BSS to record data about the current transaction with an MS.
VLRは、MSC および／または BSSに対して、MSとの現在のトランザクションに関するデータの記録を要求すること
ができる。
--------------------------------------------------------------| 08.08
29.002
|Notes
--------┼------------------------------------------------┼----Forward | MSC INVOKE TRACE
MAP_TRACE_SUBSCRIBER_
|
message |
ACTIVITY request
|
|
|
| Trace type
Trace type
|
| TriggerId
|
| Trace reference
Trace reference
|
| TransactionId
|
| Mobile identity(IMSI)
IMSI
| 1
| Mobile identity(IMEI)
IMEI
| 1
| OMCId
OMCId
|
--------┼------------------------------------------------┼----Backward| none
none
|
result |
|
--------┴------------------------------------------------┴-----
NOTE 1: The VLR may provide either an IMSI or IMEI, but not both.
VLRはIMSIまたはIMEIのいずれか1つだけを提供することができる。
3GPP
Release 1999
3.8
17
3GPP TS 29.010 V3.10.0 (2002-12)
Location update（ロケーションアップデート）
--------------------------------------------------------------|
24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | MM (LOCATION UPDATING
MAP_UPDATE_LOCATION_ |
message | REQUEST)
request
|
|
|
|
Location area id
|
|
Mobile identity
IMSI
|
|
Mobile station
|
|
classmark 1
|
|
Mobile station
|
|
classmark 2
|
|
Ciphering key
|
|
seq number
|
|
Location update
|
|
type
|
--------┼------------------------------------------------┼----Positive| MM (LOCATION
MAP_UPDATE_LOCATION |
results | UPDATING ACCEPT)
response
|
|
|
|
Location area identity
|
|
Mobile identity
|
|
Follow on proceed
|
--------┼------------------------------------------------┼----Negative| MM (LOCATION
MAP_UPDATE_LOCATION |
results | UPDATING REJECT)
response
|
|
|
|
IMSI unknown in HLR
Unknown subscriber | 1
|
Roaming not allowed: |
|
PLMN not allowed
PLMN not allowed |
|
LA not allowed
|
|
Roaming not
|
|
allowed in this LA
|
|
No Suitable cells in
|
|
location area
|
|
PLMN not allowed
Operator
|
|
determined barring|
|
Illegal MS
|
|
Illegal ME
|
|
Network failure
System Failure
|
|
Network failure
Unexpected data value|
|
Network failure
MAP_U/P_ABORT
|
|
Network failure
MAP_NOTICE
|
|
Network failure
MAP_CLOSE
|
--------┴------------------------------------------------┴----NOTE 1 The HLR shall also send this error if there is an error in the type of subscription (i.e. VLR requests
service for a GPRS only subscriber).
加入者のタイプにエラーがある場合（つまりVLRがGPRS限定加入者用サービスを要求した場合）、
HLRは本エラーも送信すること。
4
Non-transparent cases（非透過型）
4.1
General（概要）
For interworking other than the mapping of information fields, see 3GPP TS 49.008.
情報フィールドのマッピング以外のインターワーキングについては、3GPP TS 49.008参照。
3GPP
Release 1999
4.2
18
3GPP TS 29.010 V3.10.0 (2002-12)
Outgoing call set-up (MS originating call)
（発信呼のセットアップ（MS発信呼））
Figure 3 shows those elements of a call set-up sequence which require interworking between BSSAP and MAP. BSSAP
messages which do not require interworking with MAP are not shown.
図3に、BSSAPとMAP間のインターワーキングを要求する呼セットアップシーケンスのエレメントを示す。MAPとのイ
ンターワーキングを要求しないBSSAPメッセージは記載されていない。
MS
MSC
VLR
CM SERVICE REQUEST
----------------------->
MAP_PROCESS_ACCESS_REQUEST request
---------------------------------->
+--------------------------+
|
Possibly
|
| identification procedure/|
| authentication procedure |
+--------------------------+
MAP_SET_CIPHERING_MODE request
<---------------------------------(Note 1)
MAP_PROCESS_ACCESS_REQUEST response
CM SERVICE ACCEPT
<--------------------------------<----------------------positive result (Note 1)
(Note 2)
CIPHER MODE COMMAND
<----------------------(Note 2)
CIPHER MODE COMPLETE
----------------------->
MAP_FORWARD_NEW_TMSI request
TMSI REALLOCATION COMMAND <---------------------------------<----------------------(Note 3)
TMSI REALLOCATION COMPLETE
----------------------->
MAP_FORWARD_NEW_TMSI response
---------------------------------->
MAP_PROCESS_ACCESS_REQUEST response
CM SERVICE REJECT
<--------------------------------<----------------------negative result, MAP_U/P_ABORT,
(Note 4)
MAP_NOTICE, MAP_CLOSE
SETUP (Note 5)
----------------------->
MAP_SEND_INFO_FOR_OUTGOING_CALL
---------------------------------->
request
MAP_COMPLETE_CALL request
CALL PROCEEDING
<---------------------------------<----------------------MAP_SEND_INFO_FOR_OUTGOING_CALL
RELEASE COMPLETE
<---------------------------------<----------------------response, MAP_U/P_ABORT,
(Note 6)
MAP_NOTICE, MAP_CLOSE
Figure 3: Part of outgoing call set-up sequence
図3：発信呼セットアップシーケンスの一部
NOTE 1: If the MSC received a MAP_SET_CIPHERING_MODE request, it stores it until it receives the
MAP_PROCESS_ACCESS_ REQUEST response.
MSCはMAP_SET_CIPHERING_MODE要求を受信したならば、MAP_PROCESS_ACCESS_
REQUEST応答を受信するまで要求を保持する。
NOTE 2: CM SERVICE ACCEPT is sent only if the ciphering procedure is not invoked.
暗号化処理が起動されない場合のみ、CM SERVICE ACCEPTが送信される。
3GPP
Release 1999
19
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 3: TMSI reallocation need not be sequenced with other messages, but should be sent after ciphering.
TMSI再割当と他のメッセージとの順序は不問だが、暗号化後に送信されること。
NOTE 4: CM SERVICE REJECT is sent as a result of a user error parameter in the
MAP_PROCESS_ACCESS_REQUEST response, or termination of the MAP dialogue.
CM SERVICE REJECT
CM SERVICE REJECTは、MAP_PROCESS_ACCESS_REQUEST応答内のuser errorパラメータの結
果、もしくはMAPダイヤログの終了として送信される。
NOTE 5: The SETUP message is sent after the MS has either received a CM SERVICE ACCEPT or sent a
CIPHER MODE COMPLETE.
SETUPメッセージは、MSがCM SERVICE ACCEPTを受信するか、CIPHER MODE COMPLETEを送
信した後に送信される。
NOTE 6: RELEASE COMPLETE is sent as a result of a user error parameter in the
MAP_SEND_INFO_FOR_OUTGOING_CALL response, or termination of the MAP dialogue.
RELEASE COMPLETEは、MAP_SEND_INFO_FOR_OUTGOING_CALL応答中のuser errorパラメー
タの結果、またはMAPダイヤログの終了として送信される。
The procedure can be considered in two parts: the handling of the CM SERVICE REQUEST and the handling of the
SETUP request.
処理を2つの部分に分けて考えることができる：ひとつがCM SERVICE REQUESTメッセージの処理であり、もうひと
つがSETUP要求の処理である。
The procedure is initiated by the MS sending a CM SERVICE REQUEST message. The MSC will forward the service
request to the VLR in the MAP_PROCESS_ACCESS_REQUEST request. The VLR may then invoke other operations,
e.g. authentication and identification. These operations are defined in subclauses 3.4 and 3.5.
MSがCM SERVICE REQUESTメッセージを送信することによって処理が開始される。MSCはそのサービス要求を
MAP_PROCESS_ACCESS_REQUEST要求中に入れてVLRに転送する。VLRは認証または端末識別など、他のオ
ペレーションを起動することもできる。これらのオペレーションについては、3.4節および3.5節で定義される。
If there is a positive outcome for the CM SERVICE REQUEST procedure, the VLR always sends a
MAP_PROCESS_ACCESS_REQUEST response. If the request is for a first MM-connection and ciphering is required,
the MAP_PROCESS_ACCESS_REQUEST response is preceded by a MAP_SET_CIPHERING_MODE request. In
this case the MSC sends a CIPHER MODE COMMAND towards the MS. The interworking for cipher mode setting is
described in subclause 4.4. If the request is for an additional MM-connection or for a first MM-connection where
ciphering is not required, then the positive MAP_PROCESS_ACCESS_ REQUEST response causes the MSC to send a
CM SERVICE ACCEPT message to the MS. After cipher mode setting has been completed or the CM SERVICE
ACCEPT message has been returned, the MS will send the SETUP (or EMERGENCY SETUP) message and
information retrieval takes place as shown.
CM SERVICE REQUEST処理が成功した場合は常に、VLRはMAP_PROCESS_ACCESS_REQUEST 応答を送信
する。要求が初回MMコネクションの要求であり、かつ暗号化が要求された場合には、
MAP_PROCESS_ACCESS_REQUEST応答の前にMAP_SET_CIPHERING_MODE要求がくる。この場合、MSCは
MSに対してCIPHER MODE COMMANDを送信する。暗号化モード設定のためのインターワーキングについては、
4．4節で説明する。要求が追加MMコネクションの要求であるか、または初回MMコネクションの要求であっても暗号
化が要求されない場合には、ポジティブなMAP_PROCESS_ACCESS_ REQUEST応答を受信したMSCは、MSに対
してCM SERVICE ACCEPTメッセージを送信する。暗号化モード設定完了後、またはCM SERVICE ACCEPTメッセ
ージが返された後に、MSはSETUP (またはEMERGENCY SETUP)メッセージを送信し、図に示すように情報を取得
する。
A negative outcome for the MAP_PROCESS_ACCESS_REQUEST procedure can be signalled by a
MAP_PROCESS_ACCESS_REQUEST response containing a user error parameter, or by terminating the MAP
dialogue between the MSC and the VLR.
MAP_PROCESS_ACCESS_REQUEST処理の失敗は、user errorパラメータを含む
MAP_PROCESS_ACCESS_REQUEST応答、もしくはMSCとVLR間のMAPダイヤログを終了させることによって、シ
グナリングすることができる。
A positive outcome for the call setup procedure is indicated by a MAP_COMPLETE_CALL request from the VLR to
the MSC, which causes the MSC to send a CALL PROCEEDING message towards the MS.
3GPP
Release 1999
20
3GPP TS 29.010 V3.10.0 (2002-12)
呼セットアップ処理の成功は、VLRからMSCへのMAP_COMPLETE_CALL要求によって通知され、その結果MSC
はMSに対してCALL PROCEEDINGメッセージを送信する。
A negative outcome for the call setup procedure can be signalled by a MAP_SEND_INFO_FOR_INCOMING_CALL
response or by terminating the dialogue between the MSC and the VLR.
呼セットアップ処理の失敗は、MAP_SEND_INFO_FOR_INCOMING_CALL応答、またはMSCとVLR間のダイヤロ
グの終了によってシグナリングすることができる。
Information element mapping is required between the messages:
メッセージ間でIEのマッピングが必要：
-
CM SERVICE REQUEST to MAP_PROCESS_ACCESS_REQUEST request;
CM SERVICE REQUEST → MAP_PROCESS_ACCESS_REQUEST要求
-
SETUP to MAP_SEND_INFO_FOR_OUTGOING CALL request;
SETUP → MAP_SEND_INFO_FOR_OUTGOING CALL要求
-
MAP_SEND_INFO_FOR_OUTGOING_CALL response, MAP_U/P_ABORT, MAP_NOTICE or premature
MAP_CLOSE to RELEASE COMPLETE or CM SERVICE REJECT.
MAP_SEND_INFO_FOR_OUTGOING_CALL応答、MAP_U/P_ABORT、MAP_NOTICE またはpremature
MAP_CLOSE → RELEASE COMPLETE または CM SERVICE REJECT
The information contained in the MAP_COMPLETE_CALL request is not transmitted on the radio interface but is used
in the MSC for connecting the call.
MAP_COMPLETE_CALL要求中に含まれる情報は、無線インタフェース上では送信されないが、MSC内で呼接続
用に使用される。
The conversion of information elements is as follows:
IEの変換は以下のとおり：
3GPP
Release 1999
21
3GPP TS 29.010 V3.10.0 (2002-12)
--------------------------------------------------------------| 08.08/24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | COMPLETE LAYER 3 INFO
MAP_PROCESS_ACCESS_
|
| (CM SERVICE REQUEST)
REQUEST request
|
|
|
|
CM Service type
CM Service type
| 1
|
Ciphering key
CKSN
|
|
sequence number
|
|
Mobile identity
TMSI or IMSI or IMEI
|
|
Mobile station
|
|
Classmark 2
|
|
|
| Cell identifier
Current LA Id
| 4
| Chosen channel
|
|
Access Connection
|
|
Status
| 3
--------┼------------------------------------------------┼----Positive| DTAP(CM SERVICE ACCEPT) MAP_PROCESS_ACCESS_
|
result |
REQUEST response
| 2
--------┼------------------------------------------------┼----Negative| DTAP(CM SERVICE REJECT) MAP_PROCESS_ACCESS_
|
result |
REQUEST response
|
|
|
|
IMSI unknown in VLR
Unidentified
|
|
Subscriber
|
[
|
Requested service
???????
|
|
option not
|
|
subscribed
|]
|
Illegal ME
Illegal equipment
|
|
Network failure
System failure
|
|
Network failure
MAP_U/P_ABORT
|
|
Network failure
MAP_NOTICE
|
|
Network failure
MAP_CLOSE
|
--------┼------------------------------------------------┼----| DTAP(AUTHENTICATION
MAP_PROCESS_ACCESS_
|
|
REJECT)
REQUEST response
|
|
|
|
Illegal subscriber |
--------┴------------------------------------------------┴-----
NOTE 1: Indicates, in this case, a mobile originating call establishment or an emergency call establishment.
本ケースでは、モバイル発信呼の確立、または緊急呼の確立を示す
NOTE 2: The CM SERVICE ACCEPT is sent when the ciphering procedure is not invoked.
CM SERVICE ACCEPTは暗号化処理が起動されなかった場合に送信される
NOTE 3: Indicates whether or not an RR-connection exists and whether or not ciphering has been started.
RRコネクションの有無、暗号化が開始されたか否かを示す
NOTE 4: The Current LA Id parameter is derived by the MSC from the Cell identifier information element.
Current LA Idパラメータは、MSCがCell identifier IEから取得する
3GPP
Release 1999
22
3GPP TS 29.010 V3.10.0 (2002-12)
--------------------------------------------------------------| 24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | SETUP
MAP_SEND_INFO_FOR_
|
message |
OUTGOING_CALL request |
|
|
| BC repeat indicator
|
| Bearer capability 1
| 3
| Bearer capability 2
| 3
| Calling party subaddress
|
| Called party BCD number
Called Number
|
| Called party subaddress
|
| LLC repeat indicator
|
| Low layer compatibility I
|
| Low layer compatibility II
|
| HLC repeat indicator
|
| High layer compatibility i
|
| High layer compatibility ii
|
|
Bearer service
| 3
|
Teleservice
| 3
| Facility
| 1
|
CUG index
| 4
|
Suppress pref CUG | 4
|
Suppress CUG OA
| 4
| User-user
|
| SS version
|
| CLIRO flag
|
--------┼------------------------------------------------┼----Positive|
|
result |
| 2
--------┼------------------------------------------------┼----Negative| RELEASE COMPLETE
MAP_SEND_INFO_FOR_
|
result |
OUTGOING_CALL response|
|
|
| 3GPP TS 24.010
Call Barred
|
|
Barring Service
|
|
Active
|
| Operator determined
Call Barred
|
|
barring
Operator Determined|
|
Barring
|
| Network out of order
Data Missing
|
| Network out of order
Unexpected Data Value |
| Network out of order
System Failure
|
| Bearer capability
Bearer service not
|
|
not authorized
provisioned
|
| Bearer capability
Teleservice not
|
|
not authorized
provisioned
|
| [User not member of CUG] CUG reject
|
|
|
| Network out of order
MAP_U/P_ABORT
|
| Network out of order
MAP_NOTICE
|
| Network out of order
MAP_CLOSE
|
--------┴------------------------------------------------┴-----
NOTE 1: If the Facility IE contains CUG information, the CUG information is transferred to the VLR in the
MAP_SEND_INFO_FOR_OUTGOING_CALL service; any other information contained in a Facility IE
is transferred to the VLR in a MAP Supplementary Services related service.
Facility IEにCUG情報が含まれる場合には、MAP_SEND_INFO_FOR_OUTGOING_CALL サービス
中でCUG情報がVLRに送信される。Facility IE内に含まれるそれ以外の情報は、MAP Supplementary
Service関連サービス中でVLRに送信される。
NOTE 2: The call setup parameters retrieved from the VLR are not sent to the MS. The parameters are carried in
the MAP_COMPLETE_CALL service.
VLRから取得したcall setupパラメータはMSに送信されない。パラメータはMAP_COMPLETE_CALLサ
ービス中で伝送される。
NOTE 3: The bearer capabilities can be used to derive the bearer/tele service.
ベアラサービス／テレサービスを誘導するために、ベアラケーパビリティを使用することができる。
NOTE 4: CUG information is derived from the contents of the Facility IE.
CUG情報は、Facility IEのコンテンツから取得される。
3GPP
Release 1999
4.3
23
3GPP TS 29.010 V3.10.0 (2002-12)
Incoming call set-up (MS terminating call)
（着信呼のセットアップ（MS着信呼））
Figure 4 shows those elements of the procedure which require interworking between MAP and 3GPP TS 24.008
procedures.
図4に、MAPと3GPP TS 24.008の処理の間のインターワーキングに必要な処理のエレメントを示す。
MS
MSC
VLR
+--------------------------+
|
Info retrieval
|
+--------------------------+
MAP_PAGE request or
PAGE REQUEST
<---------------------------------<----------------------MAP_SEARCH_FOR_MS request
(Note 1)
PAGING RESPONSE
----------------------->
MAP_SEARCH_FOR_MS response (Note 2)
---------------------------------->
MAP_PROCESS_ACCESS_REQUEST request
---------------------------------->
+--------------------------+
|
Possibly
|
| authentication procedure |
+--------------------------+
MAP_SET_CIPHERING_MODE request
<---------------------------------(Note 3)
MAP_PROCESS_ACCESS_REQUEST response
CIPHER MODE COMMAND
<--------------------------------<----------------------positive result (Note 4)
(Note 3)
CIPHER MODE COMPLETE
----------------------->
TMSI REALLOCATION COMMAND
<-----------------------
MAP_FORWARD_NEW_TMSI request
<---------------------------------(Note 5)
TMSI REALLOCATION COMPLETE
----------------------->
MAP_FORWARD_NEW_TMSI response
---------------------------------->
MAP_COMPLETE_CALL request
SETUP
<---------------------------------<----------------------MAP_SEND_INFO_FOR_INCOMING_CALL
RELEASE COMPLETE
<--------------------------------<----------------------response negative result,
(Note 6)
MAP_U/P_ABORT,MAP_NOTICE, MAP_CLOSE
Figure 4: Incoming call set-up
図4：着信呼のセットアップ
NOTE 1: If an MM connection already exists, the PAGE REQUEST is not sent. If the call can be accepted, the
MSC sends a MAP_PROCESS_ACCESS_REQUEST request in response to the MAP_PAGE request. If
the call cannot be accepted the MSC sends a MAP_PAGE response containing the error 'busy subscriber'.
MMコネクションが既に存在する場合にはPAGE REQUESTは送信されない。呼が受け付けられる場
合には、MSCはMAP_PAGE要求に対する応答中でMAP_PROCESS_ACCESS_REQUEST要求を送
信する。MSCが呼を受け付けられない場合には、エラー'busy subscriber'を含むMAP_PAGE応答を送
信する。
NOTE 2: Sent only if MAP_SEARCH_FOR_MS was used.
MAP_SEARCH_FOR_MSが使用された場合のみ送信。
3GPP
Release 1999
24
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 3: Needed only if a ciphered MM-connection does not exist already.
暗号化されたMMコネクションが存在しない場合のみ必要。
NOTE 4: If the MSC received a MAP_SET_CIPHERING_MODE request, it stores it until it receives the
MAP_PROCESS_ACCESS_ REQUEST response.
MSCはMAP_SET_CIPHERING_MODE要求を受信したならば、MAP_PROCESS_ACCESS_
REQUEST応答を受信するまでそれを保存する。
NOTE 5: TMSI reallocation need not be sequenced with other messages, but should be sent after ciphering.
TMSI再割当とその他のメッセージとの順序は不問だが、暗号化後に送信すること。
NOTE 6: RELEASE COMPLETE is sent as a result of a user error parameter in the
MAP_SEND_INFO_FOR_OUTGOING_CALL response, or termination of the MAP dialogue.
RELEASE COMPLETEは、MAP_SEND_INFO_FOR_OUTGOING_CALL応答中のuser errorパラメー
タの結果、またはMAPダイヤログの終了として送信される。
The paging procedure is controlled by the VLR. It may be followed by authentication (subclause 3.4), ciphering
(subclause 4.4) and reallocation of TMSI(subclause 3.6). The SETUP message is sent when the
MAP_COMPLETE_CALL request is received.
ページング処理はVLRが制御する。ページング処理の後、認証処理（3．4節）、暗号化処理（4．4節）、そしてTMSI再
割当処理（3．6節）が続く。SETUPメッセージはMAP_COMPLETE_CALL要求受信時に送信される。
Normally there is no interworking between the MAP_COMPLETE_CALL request and the SETUP message. However,
the MAP_COMPLETE_CALL request may contain a bearer service indication which will be used to establish the
bearer capabilities at the MSC. The interworking between the MAP_PAGE request or MAP_SEARCH_FOR_MS
request and the BSSMAP PAGING REQUEST message is as follows:
普通、MAP_COMPLETE_CALL要求とSETUPメッセージとの間のインターワーキングはない。ただし、
MAP_COMPLETE_CALL要求中にベアラサービス通知を入れて、MSCでベアラケーパビリティを確立するために使
用することができる。MAP_PAGE要求またはMAP_SEARCH_FOR_MS要求と、BSSMAP PAGING REQUESTメッ
セージとの間のインターワーキングは以下の通り：
--------------------------------------------------------------| 08.08/24.008
29.002
|Notes
--------┼------------------------------------------------┼----Forward | PAGING REQUEST
MAP_PAGE request or
|
message |
MAP_SEARCH_FOR_MS request |
|
|
| IMSI
IMSI
|
| TMSI
TMSI
| 1
| Cell identifier
Stored LA Id
|
|
list
|
--------┼------------------------------------------------┼----Backward| COMPLETE LAYER 3 INFO
MAP_PROCESS_ACCESS_
|
message | (PAGING RESPONSE)
REQUEST request
|
|
|
|
CM service type
| 2
|
Ciphering key
CKSN
|
|
sequence number
|
|
Mobile identity
TMSI or IMSI
|
|
Mobile station
|
|
classmark 2
|
| Cell Identifier
Current LA Id
| 3
|
Access connection |
|
status
|
| Chosen channel
|
--------┴------------------------------------------------┴-----
NOTE 1: If TMSI is included, the TMSI is used as the mobile identity in the 3GPP TS 24.008 PAGE REQUEST
message, otherwise the IMSI is used as the mobile identity.
TMSIが含まれる場合には、それを3GPP TS 24.008中のPAGE REQUESTメッセージ中のモバイルIDと
して使用することができる。それ以外の場合には、モバイルIDとしてIMSIを使用する。
NOTE 2: In this case the MAP CM service type is set to 'mobile terminating call'.
このケースでは、MAP CMサービスタイプは'mobile terminating call'に設定される。
3GPP
Release 1999
25
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 3: The Target LA Id parameter is derived by the MSC from the Cell identifier information element.
Target LA Idパラメータは、MSCがCell identifier IEから取得する。
4.4
Cipher mode setting（暗号化モード設定）
The interworking is as follows:
インターワーキングを以下に示す。
--------------------------------------------------------------| 08.08
29.002
|Notes
--------┼------------------------------------------------┼----Forward | CIPHER MODE COMMAND
MAP_SET_CIPHERING_MODE |
|
request
|
|
|
| Cipher mode setting
Ciphering mode
|
| Encryption information
Kc
| 1
--------┼------------------------------------------------┼----Positive| CIPHER MODE COMPLETE
None
|
result |
|
--------┼------------------------------------------------┼----Negative| CIPHER MODE REJECT
None
|
result |
|
--------┴------------------------------------------------┴-----
NOTE 1: The key Kc is passed through the BSS to the BTS, but is not passed to the MS.
キー Kcは、BSSを経由してBTSにパスされるが、MSにはパスされない。
4.5
Inter-MSC Handover（MSC間ハンドオーバ）
The general principles of the handover procedures are given in 3GPP TS 23.009. 3GPP TS 29.010 gives the necessary
information for interworking between the 3GPP TS 48.008 handover protocol and the 3GPP TS 29.002 MAP protocol.
ハンドオーバ処理の原則については、3GPP TS 23.009に記載される。 3GPP TS 29.010では、3GPP TS 48.008で定
義されるハンドオーバプロトコルと、3GPP TS 29.002で定義されるMAPプロトコル間のインターワーキングに必要な
情報が提供される。
4.5.1
Basic Inter-MSC Handover（基本的なMSC間ハンドオーバ）
When a Mobile Station is handed over between two MSCs, the establishment of a connection between them
(described in 3GPP TS 23.009) requires interworking between A-Interface and E-Interface.
MSが2つのMSC間でハンドオーバされる場合、2つのMSC間のコネクション（3GPP TS 23.009に記載される）を確立
するために、AインタフェースとEインタフェースの間のインターワーキングが要求される。
The signalling at initiation, execution, completion of the Basic Inter-MSC handover procedure is shown in figures 5 to
10 with both possible positive or negative outcomes.
基本的なMSC間ハンドオーバ処理の、開始・実行・完了のシグナリングを、成功した場合と失敗した場合のぞれぞれ
について、図5から図7に示す。
Additionally figures 5b and 5c show the possible interworking when trace related messages are transparently transferred
on the E-Interface at Basic Inter-MSC Handover initiation.
さらに図5bおよび図5cに、基本的なMSC間ハンドオーバ処理開始時に、Eインタフェース上でトレース関連のメッセー
ジが透過的に送信される場合に発生する可能性のあるインターワーキングを示す。
3GPP
Release 1999
26
3GPP TS 29.010 V3.10.0 (2002-12)
BSS-A
MSC-A
MSC-B
|
|
|
|HANDOVER
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request
| |Possible Alloc. |
|
|
| |of a handover
|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|------------------>|
Figure 5a: Signalling for Basic Inter-MSC Handover initiation (no trace related messages transferred)
図5a：基本的MSC間ハンドオーバ開始のシグナリングフロー（トレース関連メッセージが送信されない場合）
BSS-A
MSC-A
MSC-B
|BSC INVOKE TRACE
|
|-------------->|
|
|
|
|
|HANDOVER
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request(*)
| |Possible Alloc. |
|
|
| |of a handover
|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|------------------>|
|
|
|
|
|
|
|BSC INVOKE TRACE
|
|
|
|---------------->(**)
Figure 5b: Signalling for Basic Inter-MSC Handover initiation (BSC invoke trace message transferred)
図5b：基本的MSC間ハンドオーバ開始のシグナリングフロー（BSC invoke trace メッセージが送信される場合）
(*):
In that case, HANDOVER REQUEST and BSC INVOKE TRACE messages are included within the ANAPDU parameter.
このケースでは、パラメータAN-APDU内にHANDOVER REQUESTおよびBSC INVOKE TRACEメッ
セージが含まれる。
(**):
BSC INVOKE TRACE is forwarded to BSS-B if supported by MSC-B.
MSC-Bがサポートすれば、BSC INVOKE TRACEはBSS-Bに転送される。
3GPP
Release 1999
27
3GPP TS 29.010 V3.10.0 (2002-12)
BSS-A
MSC-A
MSC-B
|
(*)
|
|HANDOVER
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request(**)
| |Possible Alloc. |
|
|
| |of a handover
|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|------------------>|
|
|
|
|
|
|
|MSC INVOKE TRACE
|
|
|
|--------------->(***)
Figure 5c: Signalling for Basic Inter-MSC Handover initiation (MSC invoke trace message transferred)
図5c：基本的MSC間ハンドオーバ開始のシグナリングフロー（MSC invoke trace メッセージが送信される場合）
(*):
Tracing invocation has been received from VLR.
VLRからTracing invocationを受信
(**):
In that case, HANDOVER REQUEST and MSC INVOKE TRACE messages are included within the
AN-APDU parameter.
このケースでは、パラメータAN-APDU中にHANDOVER REQUESTおよびMSC INVOKE TRACEメッ
セージが含まれる。
(***):
MSC INVOKE TRACE is forwarded to BSS-B if supported by MSC-B.
MSC-Bがサポートすれば、MSC INVOKE TRACEはBSS-Bに転送される。
Possible Positive outcomes:
想定される成功シーケンスは以下のとおり：
a)
successful radio resources allocation and handover number allocation (if performed):
無線リソース割当と、ハンドオーバ番号割当（もし実行されれば）が成功した場合：
BSS-A
MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|HANDOVER COMMAND
|
|
|<--------------|
|
|
b) radio resources allocation queued and successful handover number allocation (if performed). Later successful
radio resources allocation indication:
無線リソース割当がキューイングされ、ハンドオーバ番号割当（もし実行されれば）が成功した場合。その後、
無線リソース割当通知に成功
3GPP
Release 1999
28
3GPP TS 29.010 V3.10.0 (2002-12)
BSS-A
MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
|MAP PROCESS ACCESS
|
|
|
|<------------------------|
|
HANDOVER COMMAND| SIGNALLING request
|
|
|<--------------|
|
|
|
|
|
|
Figure 6: Signalling for Basic Inter-MSC Handover execution (Positive outcomes)
図 6：基本的MSC間ハンドオーバ実行のシグナリングフロー（成功シーケンス）
Possible Negative outcomes:
想定される失敗シーケンスは以下のとおり：
c)
user error detected, or handover number allocation unsuccessful (if performed), or component rejection or
dialogue abortion performed by MSC-B:
ユーザエラーが検出されるか、ハンドオーバ番号割当（もし実行されれば）が失敗した場合、またはMSC-Bに
よってコンポーネント拒否またはダイヤログ中断が実行された場合：
BSS-A
MSC-A
MSC-B
|
|
|
|
|MAP PREPARE HANDOVER response
|
|negative result, MAP CLOSE
|
|<------------------------|
|
|MAP U/P-ABORT
|
|HANDOVER REQUIRED
|
|<--------------|
|
|REJECT (Note 1)|
|
|
|
|
BSS-B
|
|
|
|
|
|
|
|
|
d) radio resources allocation failure:
無線リソース割当の失敗
BSS-A
MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|HANDOVER FAILURE
|
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|HANDOVER REQUIRED
|
|
|<--------------|
|
|
|REJECT (Note 1)|
|
|
|
|
|
|
e)
radio resources allocation queued and successful handover number allocation (if performed). Later unsuccessful
radio resources allocation:
無線リソース割当がキューイングされ、ハンドオーバ番号割当（もし実行されれば）が成功。その後、無線リソ
ース割当処理が失敗
3GPP
Release 1999
29
3GPP TS 29.010 V3.10.0 (2002-12)
BSS-A
MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|
|
|HANDOVER FAILURE
|
|
|
|<------------------|
|
|MAP PROCESS ACCESS
|
|
|
|<------------------------|
|
|
| SIGNALLING request
|
|
|HANDOVER REQUIRED
|
|
|<--------------|
|
|
|REJECT (Note 1)|
|
|
f)
unsuccessful handover execution (Reversion to the old channel):
ハンドオーバ実行が失敗（旧チャネルへ切戻し）
BSS-A
MSC-A
MSC-B
BSS-B
|
|
|
|
|HANDOVER
|
|
|
|-------------->|
|
|
|FAILURE
|
|
|
|
|MAP U -ABORT
|
|
|
|------------------------>|
|
|
|
|CLEAR COMMAND
|
|
|
|------------------>|
|
|
|
|
Figure 7: Signalling for Basic Inter-MSC Handover execution (Negative outcomes)
図 7：基本MSC間ハンドオーバ実行のシグナリングフロー（失敗シーケンス）
NOTE:
Possible rejection of the handover because of the negative outcome of MAP or BSSMAP procedure.
MAP処理またはBSSMAP処理の失敗により、ハンドオーバが拒否される場合もある。
BSS-A
MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|HANDOVER COMPLETE |
|
|
|<------------------|
|
|MAP SEND END SIGNAL request
|
|
|<------------------------|
|
|CLEAR sCOMMAND |
|
|
|<--------------|
|
|
|
|
|
|
Figure 8: Signalling for Basic Inter-MSC Handover completion
図8:基本MSC間ハンドオーバ完了のシグナリングフロー
3GPP
Release 1999
30
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome
成功シーケンス：
BSS-A
|
|
|
|
|
|
MSC-A
MSC-B
BSS-B
|
|
|
|MAP SEND END SIGNAL
|
|
|------------------------>|
|
| response
|CLEAR COMMAND
|
|
|------------------>|
|
| (Note 1)
|
Figure 9: Signalling for Basic Inter-MSC Handover completion (Positive outcome)
図9：基本MSC間ハンドオーバ完了のシグナリングフロー（成功シーケンス）
Negative outcome
失敗シーケンス：
BSS-A
|
|
|
|
|
|
MSC-A
MSC-B
BSS-B
|
|
|
| MAP U/P -ABORT
|
|
|------------------------>|
|
|
|CLEAR COMMAND
|
|
|------------------>|
|
|
|
Figure 10: Signalling for Basic Inter-MSC Handover completion (Negative outcome)
図10：基本MSC間ハンドオーバ完了のシグナリングフロー（失敗シーケンス）
NOTE:
From interworking between MAP and BSSMAP point of view.
MAP処理とBSSMAP処理との間のインターワーキングという観点から
The handover procedure is normally triggered by BSS-A by sending a HANDOVER REQUIRED message on
A-Interface to MSC-A. The invocation of the Basic Inter-MSC handover procedure is performed and controlled by
MSC-A. The sending of the MAP Prepare-Handover request to MSC-B is triggered in MSC-A upon receipt of the
HANDOVER REQUIRED message. For compatibility reason, the cell identity of the cell where the call is to be handed
over in MSC-B area, provided in the HANDOVER REQUIRED message, is mapped into targetCellId MAP parameter
and the HANDOVER REQUEST message is encapsulated in the AN-APDU MAP parameter of the Prepare-Handover
MAP request. MSC-B can invoke another operation towards the VLR-B (allocation of the handover number described
in 3GPP TS 29.002).
ハンドオーバ処理は通常、BSS-AがAインタフェース上でMSC-AにHANDOVER REQUIREDメッセージを送信して
開始される。基本MSC間ハンドオーバ処理は、MSC-Aによって起動され制御される。MSC-AでHANDOVER
REQUIREDメッセージを受信すると、それがトリガとなってMSC-BにMAP Prepare-Handover要求を送信する。互換性
上の理由から、呼のハンドオーバであるMSC-Bの配下セルのIDは、HANDOVER REQUIREDメッセージ内で提供さ
れるが、targetCellId MAPパラメータ中にマッピングされ、HANDOVER REQUESTメッセージはPrepare-Handover
MAP要求のパラメータAN-APDU MAPパラメータ中にカプセル化される。MSC-Bは、その他のオペレーションを
VLR-Bに対して起動することができる（3GPP TS 29.002に記載されるハンドオーバ番号割当など）。
Additionally, if tracing activity has been invoked, the trace related messages can be transferred on the E-Interface
encapsulated in the AN-APDU MAP parameter of the Prepare-Handover Request. If transferred, one complete trace
related message at a time shall be included in the AN-APDU MAP parameter after the HANDOVER REQUEST
message.
さらに、トレースアクティビティが起動されている場合には、トレース関連のメッセージをPrepare-Handover Requestの
AN-APDU MAPパラメータ中にカプセル化して、Eインタフェース上で送信することができる。送信された場合には、
HANDOVER REQUESTメッセージの後に、1つの完全なトレース関連メッセージをAN-APDU MAP内に同時に入れ
ること。
3GPP
Release 1999
31
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Prepare Handover and HANDOVER REQUIRED is as follows:
Prepare Handover とHANDOVER REQUIRED間のインターワーキングを以下に示す：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER REQUIRED
MAP PREPARE HANDOVER request|
message |
|
|
-ho-NumberNotRequired| 1
| BSSMAP information
-targetCellId
|
|
elements
-AN-APDU(
|
2
|
HANDOVER REQUEST,
|
|
BSC INVOKE TRACE
|
3
|
or MSC INVOKE TRACE)
|
--------┼-------------------------------------------------┼----Positive|
MAP PREPARE HANDOVER response|
result |
|
4
|
-handover number
|
|
-AN-APDU(
|
|
QUEUING INDICATION |
|
or HANDOVER REQUEST|
|
ACKNOWLEDGE or
|
|
HANDOVER FAILURE) |
--------┼-------------------------------------------------┼----Negative| HANDOVER REQUIRED REJECT
MAP PREPARE HANDOVER|
5
result |
|
| equipment failure
System Failure
|
| equipment failure
No Handover Number |
|
available
|
| equipment failure
UnexpectedDataValue|
| equipment failure
Data Missing
|
|
|
| equipment failure
MAP CLOSE
|
| equipment failure
MAP U/P -ABORT
|
|
|
NOTE 1: The ho-NumberNotRequired parameter is included by MSC-A, when MSC-A decides not to use any
circuit connection with MSC-B. No handover number shall be present in the positive result. Any negative
response from MSC-B shall not be due to handover number allocation problem.
MSC-AがMSC-Bと回線交換コネクションを使用しないことを決定したならば、MSC-AはパラメータhoNumberNotRequiredを入れる。ポジティブな結果の中にハンドオーバ番号を入れてはならない。MSC-B
からのネガティブな応答は全て、ハンドオーバ番号割当問題に起因するものであってはならない。
NOTE 2: The process performed on the BSSMAP information elements received in the HANDOVER REQUIRED
message is described in the GSM Recommendation 48.008.
HANDOVER REQUIREDメッセージ中で受信したBSSMAP IE上で実行される処理については、GSM
Recommendation 48.008内で説明される。
NOTE 3: The process performed on the BSSMAP information elements received in the MSC or BSC INVOKE
TRACE message is described in subclause 4.5.6.6.
MSCメッセージ内で受信したBSSMAP IE、またはBSC INVOKE TRACEメッセージ上で実行される処
理については、4.5.6.6節で説明される。
NOTE 4: The response to the Prepare-Handover request can include in its AN-APDU parameter, identifying the
GSM-08.06 protocol, either a BSSMAP QUEUING INDICATION, or a BSSMAP HANDOVER
REQUEST ACKNOWLEDGE or a BSSMAP HANDOVER FAILURE.
Prepare-Handover要求に対する応答を、そのAN-APDUパラメータ中に入れて、GSM-08.06プロトコルが
BSSMAP QUEUING INDICATION、BSSMAP HANDOVER REQUEST ACKNOWLEDGE、
BSSMAP HANDOVER FAILUREのいずれかであることを識別することもできる。
In the first case, MSC-A shall wait for the radio resources allocation response from MSC-B, transmitted
to MSC-A as described in subclause 4.5.4.
一番目のケースではMSC-Aは、4.5.4節で述べる手順でMSC-BからMSC-Aに送信される、無線リソー
ス割当応答を待つこと。
3GPP
Release 1999
32
3GPP TS 29.010 V3.10.0 (2002-12)
In the second case, the positive result triggers in MSC-A the sending on A-Interface of the HANDOVER
COMMAND.
二番目のケースでは、処理が成功すると、MSC-A内でAインタフェース上のHANDOVER COMMAND
送信がトリガされる。
In the third case, the positive result triggers in MSC-A one of the following:
三番目のケースでは、処理が成功すると、MSC-A内で次のいずれかの処理がトリガされる：
-
another handover attempt is initiated by MSC-A;
MSC-Aが別のハンドオーバ試行を開始
-
optionally the sending of the HANDOVER REQUIRED REJECT.
オプションとして、HANDOVER REQUIRED REJECTを送信
(The possible sending of the HANDOVER REQUIRED REJECT message upon receipt of the
HANDOVER FAILURE is out of the scope of 3GPP TS 29.010 and lies in 3GPP TS 48.008).
（HANDOVER FAILUREを受信することによってHANDOVER REQUIRED REJECTメッセージが送信
される可能性もあるが、それについては3GPP TS 29.010のスコープ外であり、3GPP TS 48.008に記載
される）
NOTE 5: The possible sending of the HANDOVER REQUIRED REJECT message is described in 3GPP TS
48.008.
HANDOVER REQUIRED REJECTメッセージが送信される可能性もあるが、それについては3GPP TS
48.008に記載される。
The interworking between Send End Signal and HANDOVER COMPLETE in MSC-B is as follows:
MSC-B内での、Send End SignalとHANDOVER COMPLETE間のインターワーキングは以下の通り：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER COMPLETE
MAP SEND END SIGNAL request |
message |
|
|
-AN-APDU(
|
|
HANDOVER COMPLETE)|
|
|
--------┼-------------------------------------------------┼----Positive| CLEAR COMMAND
MAP SEND END SIGNAL response|
result | -Call Control release
| 1
--------┼-------------------------------------------------┼----Negative| CLEAR COMMAND
|
result | -Call Control release
MAP CLOSE
| 2
| -Call Control release
MAP U/P -ABORT
|
|
|
NOTE 1: The positive empty result triggers the clearing of the Radio Resources on the A-Interface and the release
of the SCCP connection between MSC-B and BSS-B. If a circuit connection is used between MSC-A and
MSC-B, the 'Call Control release' clearing cause shall only be given to BSS-B when MSC-B has received
a clearing indication on its circuit connection with MSC-A.
空の結果を伴う処理の成功によって、Aインタフェース上の無線リソースのクリアと、MSC-BとBSS-Bと
の間のSSCPコネクションの開放がトリガされる。MSC-AとMSC-Bとの間で回線交換コネクションが使用
される場合、MSC-Aとの回線交換コネクション上でMSC-Bがクリア通知を受信したならば、BSS-Bに対
して'Call Control release' クリア理由だけを送信すること。
NOTE 2: The abortion of the dialogue or the rejection of the component triggers in MSC-B the clearing of its
circuit connection with MSC-A, if any, of the Radio Resources on the A-Interface and the release of the
SCCP connection between MSC-B and BSS-B.
ダイヤログの中断、またはコンポーネントの拒否は、MSC-B内で、MSC-Aとの回線交換コネクションの
クリアと、もしあればAインタフェース上の全無線リソースのクリアと、MSC-BとBSS-Bとの間のSSCPコ
ネクションの開放がトリガされる。
The interworking between Send End Signal and CLEAR COMMAND in MSC-A is as follows:
MSC-A内での、Send End SignalとCLEAR COMMAND間のインターワーキングは以下の通り：
3GPP
Release 1999
33
3GPP TS 29.010 V3.10.0 (2002-12)
---------------------------------------------------------------|
29.002
08.08
|Notes
--------┼-------------------------------------------------┼----Forward | MAP SEND END SIGNAL
CLEAR COMMAND
|
message | response
|
|
-AN-APDU(
- Handover
|
|
HANDOVER COMPLETE)
Successful
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
The interworking between HANDOVER FAILURE in case of reversion to old channel of the MS and User Abort in
MSC-A is as follows:
MSが旧チャネルへ切戻しされる場合のHANDOVER FAILUREと、MSC-A内のUser Abort間のインターワーキング
は以下の通り：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER FAILURE
MAP U -ABORT
|
message |
|
| - Reversion to old
|
|
channel
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
4.5.2
Subsequent Inter-MSC Handover back to MSC-A
（MSC-Aへの後続MSC間ハンドオーババック）
When a Mobile Station is being handed over back to MSC-A, the procedure (described in 3GPP TS 23.009) requires
interworking between A-Interface and E-Interface.
MSがMSC-Aにハンドオーババックされた場合、（3GPP TS 23.009に説明される）処理はAインタフェースとEインタフェ
ース間のインターワーキングを必要とする。
The signalling at initiation, execution and completion of the Subsequent Inter-MSC handover procedure is shown in
figures 11 to 15.
後続MSC間ハンドオーバ処理の開始・実行・完了のシグナリングを、図11から15に示す。
BSS-A
MSC-B
MSC-A
|
|
|
|HANDOVER
|
|
|-------------->|MAP PREPARE SUBSEQUENT
|
|REQUIRED
|------------------------>|
|
|HANDOVER request
|
|
|
|
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|------------------>|
Figure 11: Signalling for Subsequent Inter-MSC Handover back to MSC-A initiation
図11：MSC-Aへの後続MSC間ハンドオーババック開始のシグナリング
3GPP
Release 1999
34
3GPP TS 29.010 V3.10.0 (2002-12)
Possible Positive outcomes:
考えられる処理の成功：
a)
successful radio resources allocation:
無線リソース割当の成功
BSS-A
MSC-B
MSC-A
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
| HANDOVER response
|
|
|HANDOVER COMMAND
|
|
|<--------------|
|
|
b) radio resources allocation queued. Later successful radio resources allocation indication:
無線リソース割当がキューイング。その後、無線リソース割当成功を通知
BSS-A
MSC-B
MSC-A
BSS-B
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
| HANDOVER response
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP FORWARD ACCESS
|
|
|
|<------------------------|
|
|
| SIGNALLING request
|
|
|HANDOVER COMMAND
|
|
|<--------------|
|
|
Figure 12: Signalling for Subsequent Inter-MSC Handover back to MSC-A execution (Positive
outcome)
図12：MSC-Aへの後続MSC間ハンドオーババック実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
c)
user error detected, or component rejection or dialogue abortion performed by MSC-A:
ユーザエラーの検出、またはMSC-Aがコンポーネントを拒否、またはダイヤログを中断：
BSS-A
MSC-B
MSC-A
|
|MAP PREPARE SUBSEQUENT HANDOVER
|
|<------------------------|
|HANDOVER REQUIRED response negative result
|<--------------|
|
|REJECT (Note 1)|
|
|
|
|
3GPP
BSS-B
|
|
|
|
|
|
Release 1999
35
3GPP TS 29.010 V3.10.0 (2002-12)
d) component rejection or dialogue abortion performed by MSC-A:
MSC-Aがコンポーネントを拒否、またはダイヤログを中断：
BSS-A
MSC-B
MSC-A
|
|MAP CLOSE, MAP U/P ABORT |
|
|<------------------------|
|CLEAR COMMAND |
|
|<--------------|
|
|
|
|
e)
BSS-B
|
|
|
|
|
radio resources allocation failure:
無線リソース割当の失敗：
BSS-A
MSC-B
MSC-A
BSS-B
|
|
| HANDOVER FAILURE |
|
|
|<------------------|
|
|MAP PREPARE SUBSEQUENT
|
|
|
|<------------------------|
|
|HANDOVER REQUIRED
HANDOVER response
|
|
|<--------------|
|
|
|REJECT (Note 1)|
|
|
f)
radio resources allocation queued. Later unsuccessful radio resources allocation:
無線リソース割当のキューイング。その後、無線リソース割当に失敗：
BSS-A
MSC-B
MSC-A
BSS-B
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
|
HANDOVER response
|
|
|
|
|HANDOVER FAILURE
|
|
|
|<------------------|
|
| MAP FORWARD ACCESS
|
|
|
|<------------------------|
|
|HANDOVER REQUIRED
SIGNALLING request
|
|
|<--------------|
|
|
|REJECT (Note 1)|
|
|
Figure 13: Signalling for Subsequent Inter-MSC Handover back to MSC-A execution
(Negative outcome)
図13：MSC-Aへの後続MSC間ハンドオーババック実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or BSSMAP procedure.
MAPまたはBSSMAP処理の失敗により、ハンドオーバが拒否された場合などが想定される。
BSS-B
MSC-A
MSC-B
BSS-A
|
|
|
|
|HANDOVER
|
|
|
|-------------->|MAP SEND END SIGNAL
|
|
|COMPLETE
|------------------------>|
|
|
| response
|
|
|
|
|CLEAR COMMAND
|
|
|
|------------------>|
Figure 14: Signalling for Subsequent Inter-MSC Handover back to MSC-A completion
(Successful completion of the procedure)
図14：MSC-Aへの後続MSC間ハンドオーババック完了のシグナリング（処理の成功による完了）
3GPP
Release 1999
NOTE:
36
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome case shown in figure 9.
想定される結果のケースを、図9に示す。
BSS-B
MSC-A
MSC-B
BSS-A
|
|
|
|
|HANDOVER
|
|
|
|-------------->|MAP SEND END SIGNAL
|
|
|COMPLETE
|------------------------>|
|
|
| response
|
|
|
|
|
|
|
|MAP U/P -ABORT
|
|
|
|<------------------------|
|
|
|
|CLEAR COMMAND
|
|
|
|------------------>|
|
|
|(Note 1)
|
Figure 15: Signalling for Subsequent Inter-MSC Handover back to MSC-A completion (Unsuccessful
completion of the procedure)
図15：MSC-Aへの後続MSC間ハンドオーババック完了のシグナリング（処理の失敗による完了）
NOTE 1: Abnormal end of the procedure which triggers the clearing of all resources in MSC-B.
処理が異常終了すると、MSC-B内の全リソースのクリアがトリガされる。
The interworking between Prepare Subsequent Handover and HANDOVER REQUIRED is as follows:
Prepare Subsequent Handover とHANDOVER REQUIRED間のインターワーキングを以下に示す：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward |HANDOVER REQUIRED MAP PREPARE SUBSEQUENT HANDOVER|
message |
request
| 1
|
|
|
-target MSC number |
| BSSMAP information
-targetCellId
|
|
elements
-AN-APDU(
|
|
HANDOVER REQUEST) |
--------┼-------------------------------------------------┼----Positive|HANDOVER REQUIRED MAP PREPARE SUBSEQUENT HANDOVER|
result |
response
| 2
|
-AN-APDU(
|
|
QUEUING INDICATION |
|
or HANDOVER REQUEST|
|
ACKNOWLEDGE or
|
|
HANDOVER FAILURE) |
--------┼-------------------------------------------------┼----Negative| HANDOVER REQUIRED REJECT MAP PREPARE SUBSEQUENT| 3
result |
HANDOVER response
|
| equipment failure
Unknown MSC
|
| equipment failure
Subsequent Handover|
|
Failure |
| equipment failure
UnexpectedDataValue|
| equipment failure
Data Missing
|
|
|
| CLEAR COMMAND
|
|
|
| equipment failure
MAP CLOSE
|
| equipment failure
MAP U/P -ABORT
|
|
|
NOTE 1: The processing performed on the BSSMAP information elements received in the HANDOVER
REQUIRED message is out of the scope of the present document. The target MSC number is provided to
MSC-A by MSC-B based on the information received from BSS-B.
HANDOVER REQUIREDメッセージ中で受信したBSSMAP IE上で実行される処理については、本ドキ
ュメントの範囲外である。target MSCの番号は、MSC-BがBSS-Bから受信した情報に基づいて、MSCAに提供される。
3GPP
Release 1999
37
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 2: The response to the Prepare-Subsequent-Handover request can include in its AN-APDU parameter,
identifying the GSM-0806 protocol, either a BSSMAP QUEUING INDICATION, or a BSSMAP
HANDOVER REQUEST ACKNOWLEDGE or a BSSMAP HANDOVER FAILURE.
Prepare-Subsequent-Handover要求に対する応答は、GSM-0806プロトコルを識別するためのそのANAPDUパラメータ、BSSMAP QUEUING INDICATION、BSSMAP HANDOVER REQUEST
ACKNOWLEDGE、またはBSSMAP HANDOVER FAILURE中に含めることができる。
In the first case, MSC-B shall wait for the radio resources allocation response from MSC-A, transmitted
to MSC-B as described in subclause 4.5.4.
一番目のケースではMSC-Bは、4.5.4節で述べる手順でMSC-AからMSC-Bに送信される、無線リソー
ス割当応答を待つこと。
In the second case, the positive result triggers in MSC-B the sending on A-Interface of the HANDOVER
COMMAND.
二番目のケースでは、処理が成功すると、MSC-B内でAインタフェース上のHANDOVER COMMAND
送信がトリガされる。
In the third case, the positive result triggers in MSC-B one of the following:
三番目のケースでは、処理が成功すると、MSC-B内で次のいずれかの処理がトリガされる：
-
another handover attempt is initiated by MSC-B;
MSC-Bが別のハンドオーバ試行を開始
-
optionally the sending of the HANDOVER REQUIRED REJECT.
オプションとして、HANDOVER REQUIRED REJECTを送信
(The possible sending of the HANDOVER REQUIRED REJECT message upon receipt of the
HANDOVER FAILURE is out of the scope of 3GPP TS 29.010 and lies in 3GPP TS 48.008).
（HANDOVER FAILUREを受信することによってHANDOVER REQUIRED REJECTメッセージが送信
される可能性もあるが、それについては3GPP TS 29.010のスコープ外であり、3GPP TS 48.008に記載
される）
NOTE 3: The possible sending of the HANDOVER REQUIRED REJECT message is described in 3GPP TS
48.008.
HANDOVER REQUIRED REJECTメッセージが送信される可能性もあるが、それについては3GPP TS
48.008に記載される。
The interworking between Send End Signal Result and HANDOVER COMPLETE in MSC-A is as follows:
MSC-A内での、Send End Signal Result とHANDOVER COMPLETE間のインターワーキングは以下の通り：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER COMPLETE
MAP SEND END SIGNAL
|
message |
response
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT
| 1
|
|
NOTE 1: The abortion of the dialogue ends the handover procedure with MSC-B.
ダイヤログの中断によって、MSC-Bとのハンドオーバ処理は終了する。
3GPP
Release 1999
4.5.3
38
3GPP TS 29.010 V3.10.0 (2002-12)
Subsequent Inter-MSC Handover to third MSC
(第３のMSCへの後続MSC間ハンドオーバ)
When a Mobile Station is being handed over to a third MSC, the procedure (described in 3GPP TS 23.009) does require
one specific interworking case in MSC-A (figure 20) between E-Interface from MSC-B and E-Interface from MSC-B'
other than the combination of the ones described in the subclause 4.5.1 and 4.5.2.
MSが第3のMSCにハンドオーバされた場合、（3GPP TS 23.009に記載される）処理は、4.5.1節および4.5.2節に記載
された処理の組合せではなく、MSC-BからのEインタフェースとMSC-B'からのEインタフェース間で、MSC-A内で特別
なインターワーキングのケースを要求する（図20）。
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|HANDOVER
|
|
|
|----------->|MAP PREPARE SUSEQUENT |
|
|REQUIRED
|--------------------->|
|
|
|HANDOVER request
|MAP PREPARE
|
|
|
|--------------->|
|
|
|HANDOVER request|
|
|
|
|+-------+
|
|
|
||Possib.|
|
|
|
||Alloc. |
|
|
|
||of ho. |
|
|
|
||number |
|
|
|
|| VLR-B |
|
|
|
|+-------+
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|-------->|
|
|
|
|REQUEST |
|
|
|
|
Figure 16: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') initiation
図16：第3のMSC（MSC-B'）への後続MSC間ハンドオーバ開始のシグナリング
Possible Positive outcomes:
考えられる処理の成功：
a)
successful radio resources allocation:
無線リソース割当の成功
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|REQUEST |
|
|
|
ACKNOWLEDGE
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT|
response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| HANDOVER
|
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
|
|
|
|
|
3GPP
Release 1999
39
3GPP TS 29.010 V3.10.0 (2002-12)
b) radio resources allocation queued and successful handover number allocation, if performed. Later successful
radio resources allocation indication:
無線リソース割当がキューイングされ、ハンドオーバ番号割当が実行されたならばそれに成功した場合。そ
の後、無線リソース割当成功を通知
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
| QUEUING |
|
|
|
|<--------|
|
|
|
|INDICAT. |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT|
response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|REQUEST |
|
|
|
ACKNOWLEDGE
|
|
|
|
|
|
|
|MAP PROCESS ACCESS
|
|
|
|<---------------|
|
|
|MAP FORWARD ACCESS
|SIGNALLING request
|
|
|<---------------------|
|
|
|
|SIGNALLING request
|
|
|
| HANDOVER
|
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
Figure 17: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') execution
(Positive outcome)
図17：第3のMSC（MSC-B'）への後続MSC間ハンドオーバ実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
c)
user error detected, or component rejection or dialogue abortion performed by MSC-B':
ユーザエラーの検出、またはMSC-B'がコンポーネントを拒否、またはダイヤログを中断：
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|MAP PREPARE HANDOVER
|
|
|
|response negative result |
|
|
|MAP CLOSE
|
|
|
|
|<---------------|
|
|
|
|MAP U/P -ABORT |
|
|
|MAP PREPARE SUBSEQUENT|
|
|
|
|<---------------------|
|
|
|
|HANDOVER response negative
|
|
| HANDOVER
|result
|
|
|
|<-----------|
|
|
|
| REQUIRED
|
|
|
|
| REJECT
|
|
|
|
| (Note 1)
|
|
|
|
3GPP
Release 1999
40
3GPP TS 29.010 V3.10.0 (2002-12)
d) radio resources allocation failure:
無線リソース割当の失敗：
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|FAILURE |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT| response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| HANDOVER
|
|
|
|
|<-----------|
|
|
|
| REQUIRED
|
|
|
|
| REJECT
|
|
|
|
| (Note 1)
|
|
|
|
e)
radio resources allocation queued and successful handover number allocation (if performed). Later unsuccessful
radio resources allocation:
無線リソース割当がキューイングされ、（もし実行されれば）ハンドオーバ番号割当てが成功。その後、無線リ
ソース割当が失敗：
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
| QUEUING |
|
|
|
|<--------|
|
|
|
|INDICAT. |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT| response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|FAILURE |
|
|
|
|
|
|
|
|MAP PROCESS ACCESS
|
|
|
|<---------------|
|
|
|
|SIGNALLING request
|
|
|MAP FORWARD ACCESS
|
|
|
|
|<---------------------|
|
|
|
|SIGNALLING request
|
|
|
| HANDOVER
|
|
|
|
|<-----------|
|
|
|
| REQUIRED
|
|
|
|
| REJECT
|
|
|
|
| (Note 1)
|
|
|
|
Figure 18: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') execution (Negative
outcome)
図18：第3のMSC（MSC-B'）への後続MSC間ハンドオーバ実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or BSSMAP procedure.
MAPまたはBSSMAP処理の失敗により、ハンドオーバが拒否された場合などが想定される。
3GPP
Release 1999
41
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome:
処理の成功：
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|COMPLETE |
|
|
|
|
|
|
|
|MAP SEND END SIGNAL
|
|
|
|<---------------|
|
|
| MAP SEND END SIGNAL |
|
|
|
|<---------------------|
|
|
|
| response
|
|
|
| CLEAR
|
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
Figure 19: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') completion
(Successful completion of the procedure)
図19：第3のMSC(MSC-B') への後続MSC間ハンドオーバ完了のシグナリング（処理の成功による完了）
Negative outcome:
処理の失敗：
BSS-A
MSC-B
MSC-A
MSC-B'
|
|
|
|
|HANDOVER
|
|
|
BSS-B'
|----------->|
|
|
|
|FAILURE
|MAP PROCESS ACCESS
|
|
|
|
|--------------------->|
|
|
|
|SIGNALLING request (Note 1)
|
|
|
|
|
|
|
|
|
|MAP U -ABORT
|
|
|
|
|--------------->|
|
|
|
|
|CLEAR
|
|
|
|
|-------->|
|
|
|
|COMMAND |
|
|
|
|
|
Figure 20: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') completion
(Unsuccessful completion of the procedure)
図20：第3のMSC(MSC-B') への後続MSC間ハンドオーバ完了のシグナリング（処理の失敗による完了）
NOTE 1: Specific interworking case detailed below.
特定のインターワーキングのケースについて、以下に詳述する：
3GPP
Release 1999
42
3GPP TS 29.010 V3.10.0 (2002-12)
The specific interworking case in MSC-A compared to the subclauses 4.5.1 and 4.5.2 occurs between HANDOVER
FAILURE encapsulated in a Process Access Signalling from MSC-B and the abortion of the dialogue with MSC-B' in
the case of a reversion to old channel of the MS:
4.5.1節および4.5.2節に記載されるケースと異なり、MSが旧チャネルに復帰する場合には、MSC-BからのProcess
Access Signalling中にカプセル化されたHANDOVER FAILUREとMSC-B' とのダイヤログ中断との間に特別なイン
ターワーキングのケースが発生する。
---------------------------------------------------------------|
29.002
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PROCESS-SIGNALLING
|
message |
request
|
|
|
|
-AN-APDU(
MAP U -ABORT
| 1
|
HANDOVER FAILURE)
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT | 2
|
|
NOTE 1: The abortion of the dialogue triggers in MSC-B' the clearing of the circuit connection with MSC-A, if
any, and of the Resources between MSC-B' and BSS-B'.The abortion of the dialogue ends the handover
procedure with MSC-B'.
ダイヤログの中断は、MSC-B'内で、MSC-Aとの回線交換コネクションと、存在する場合にはMSC-B'と
BSS-B'間のリソースのクリアをトリガする。ダイヤログの中断によって、MSC-B'とのハンドオーバ処理
は終了する。
NOTE 2: The abortion of the dialogue ends the handover procedure with MSC-B.
ダイヤログの中断によって、MSC-Bとのハンドオーバ処理は終了する。
4.5.4
BSSAP Messages transfer on E-Interface
（BSSAPメッセージのEインタフェース上の送信）
The following mapping applies to the encapsulation performed in MSC-A.
MSC-A内で実行されるカプセル化には、次のマッピングが適用される。
---------------------------------------------------------------|
24.008/08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | BSSAP messages
MAP FORWARD ACCESS SIGNALLING|
message |
request
| 1
|
|
|
-AN-APDU (BSSAP messages)|
--------┼-------------------------------------------------┼----Positive|
|
result |
| 2
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP CLOSE
|
|
MAP U/P -ABORT
|
|
|
NOTE 1: Complete BSSAP messages to be sent on MSC-B - BSS-B interface (BSSMAP or DTAP messages) are
embedded into the AN-APDU parameter (see Annex A of 3GPP TS 48.008 for the description of the set of
BSSMAP messages).
MSC-B～BSS-B間インタフェース上で送信すべきComplete BSSAPメッセージ(BSSMAPまたはDTAP
メッセージ) は、 AN-APDUパラメータに内蔵される（BSSMAPメッセージの組合せの詳細については、
3GPP TS 48.008のAnnex A参照）。
3GPP
Release 1999
43
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 2: The Return Result does not apply. If MSC-B returns a message, this message will arrive in an Invoke:
Process Access Signalling.
Return Result は適用されない。MSC-Bがメッセージを返す場合、そのメッセージはInvoke：Process
Access Signallingに到達する。
The following mapping applies to the encapsulation performed in MSC-B.
MSC-B内で実行されるカプセル化には、次のマッピングが適用される。
---------------------------------------------------------------|
24.008/08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | BSSAP messages
MAP PROCESS ACCESS SIGNALLING|
message |
request
| 1
|
|
|
-AN-APDU (BSSAP messages)|
--------┼-------------------------------------------------┼----Positive|
|
result |
| 2
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP CLOSE
|
| CLEAR COMMAND
|
|
|
| equipment failure
MAP U/P -ABORT
| 3
|
|
NOTE 1: Complete BSSAP messages to be sent to MSC-A (BSSMAP or DTAP messages) are embedded into the
AN-APDU parameter (see 3GPP TS 49.008 for the description of the set of BSSMAP messages).
MSC-A に送信すべきComplete BSSAPメッセージ（BSSMAPまたはDTAPメッセージ）は、AN-APDU
パラメータに内蔵される（BSSMAPメッセージの組合せの詳細については、3GPP TS 48.008参照）。
NOTE 2: The Return Result does not apply. If MSC-A returns a message, this message will arrive in an Invoke:
Forward Access Signalling.
Return Result は適用されない。MSC-Aがメッセージを返す場合、そのメッセージはInvoke：Forward
Access Signallingに到達する。
NOTE 3: The abortion of the dialogue triggers the clearing of the circuit connection with MSC-A, if any, of the
Radio Resources on the A-Interface and the release of the SCCP connection between MSC-B and BSS-B.
The clearing of the Radio Resources (the clearing indication received from BSS-B is transmitted to
MSC-A) or the loss of the SCCP connection between MSC-B and BSS-B, triggers in MSC-B the abortion
of the dialogue on the E-Interface and the clearing of the circuit connection with MSC-A, if any.
ダイヤログの中断は、MSC-Aとの回線交換コネクションのクリアと、存在する場合にはAインタフェース
上の無線リソースのクリアと、MSC-B とBSS-B間のSCCPコネクションの開放をトリガする。無線リソー
スのクリア（BSS-Bから受信したクリア通知はMSC-Aに送信される）、またはMSC-BとBSS-B間のSCCP
コネクションの消失は、MSC-B内でEインタフェース上でのダイヤログの中断と、もしあればMSC-Aとの
回線交換コネクションのクリアをトリガする。
4.5.5
Processing in MSC-B, and information transfer on E-interface
（MSC-B内の処理と、Eインタフェース上の情報送信）
The following parameters require processing (e.g. to store the parameter, to internally generate the parameter) in
MSC-B. The relevant BSSMAP procedures are mentioned to ease the comprehension, their detailed description is the
scope of 3GPP TS 48.008. Each BSSMAP message listed in 3GPP TS 49.008 being transferred on E-interface shall use
the mechanisms given in subclause 4.5.4 and is described in 3GPP TS 48.008.
次のパラメータは、（例えばパラメータを保存したり、内部パラメータを生成するために）MSC-B内の処理を必要とす
る。関連するBSSMAP処理については、理解を容易にするために、その詳細については3GPP TS 48.008で記載す
る。3GPP TS 49.008内でリストアップされた、Eインタフェース上で送信される各BSSMAPメッセージは、本ドキュメント
の4.5.4節で与えられ3GPP TS 48.008に記載されるメカニズムを使用すること。
For intra-MSC-B handover/relocation and security interworking , after inter-MSC handover from GSM to GSM, the
3G_MSC-B needs additional information to be able to perform security mode and integrity protection procedures.
These RANAP informations are transferred between MSC-A and 3G-MSC-B in MAP messages, defined in 3GPP TS
29.002.
3GPP
Release 1999
44
3GPP TS 29.010 V3.10.0 (2002-12)
GSMからGSMへのMSC内ハンドオーバ後の、MSC-B内ハンドオーバ／リロケーションに関しては、セキュリティモー
ドと完全性保護処理を実行することができるように、3G_MSC-Bは追加的情報を必要とする。これらのRANAP情報
は、MSC-Aと3G-MSC-B間の3GPP TS 29.002で定義されるMAPメッセージ中で送信される。
For subsequent handover/relocation, after inter-MSC handover from GSM to GSM, the 3G_MSC-B needs additional
information to be able to perform service handover procedures. The relevant information is transferred between MSC-A
and 3G-MSC-B in MAP messages, defined in 3GPP TS 29.002.
GSMからGSMへのMSC内ハンドオーバ後の、後続MSC-B内ハンドオーバ／リロケーションに関しては、サービスハ
ンドオーバ処理を実現するために、3G_MSC-Bは追加的情報を必要とする。関連する情報は、MSC-A と3G-MSC-B
間の3GPP TS 29.002で定義されるMAPメッセージ中で送信される。
4.5.5.1
Encryption Information（暗号化情報）
A sequence of possible encryption algorithms can be sent to a BSS in Cipher Mode Command or Handover Request.
The BSS chooses one of the listed algorithms and reports this back to the MSC in Cipher Mode Complete or Handover
Request Acknowledge respectively.
想定される暗号化アルゴリズムのシーケンスは、Cipher Mode Command またはHandover Request中に入れてBSS
に送信することができる。BSSはリストアップされたアルゴリズムの中から1つを選択し、それをCipher Mode Complete
またはHandover Request Acknowledgeのいずれかの中に入れてMSCに報告する。
The list of algorithms, the ciphering key and the chosen algorithm shall be stored by MSC-B, and the chosen value sent
to MSC-A.
MSC-Bは、アルゴリズムのリスト、暗号鍵、そして選択されたアルゴリズムを保存し、選択された値をMSC-Aに送信
する。
Transfer of Information:
情報の送信：
If ciphering has not been performed before Inter-MSC Handover, this will be controlled by MSC-A after the
completion of Inter-MSC Handover.
MSC間ハンドオーバ実行前に暗号化が実行されなかった場合には、MSC間ハンドオーバ完了後にMSC-Aに
よって暗号化が制御される。
Ciphering control towards MSC-B:
MSC-Bに対する暗号化の制御：
If Ciphering has been performed before Inter-MSC Handover:
MSC間ハンドオーバ実行前にハンドオーバ前に既に暗号化が実行されている場合：
-
in the Handover Request BSSMAP message (information included).
Handover Request BSSMAPメッセージの中（に情報が含まれる）
The Handover Request Acknowledge should in this case contain the indication of the chosen algorithm.
この場合、Handover Request Acknowledge中に選択されたアルゴリズムの通知が含まれること。
If Ciphering has NOT been performed before Inter-MSC Handover:
MSC間ハンドオーバ実行前にハンドオーバ前に暗号化が実行されなかった場合：
-
in the Cipher Mode Command procedure between MSC-A and MSC-B.
MSC-A とMSC-B間のCipher Mode Command処理の中
If the encryption algorithm is changed at an intra-BSS handover in BSS-B this must be reported to MSC-A
in:
BSS-B内のBSS内ハンドオーバ時に暗号化アルゴリズムが変更された場合、このことを次の処理内で
MSC-Aにレポートする必要がある：
-
the BSSMAP Handover Performed procedure.
BSSMAP Handover Performed処理
If the encryption algorithm is changed at an intra-MSC handover in MSC-B this must be reported to MSC-A
in:
3GPP
Release 1999
45
3GPP TS 29.010 V3.10.0 (2002-12)
MSC間ハンドオーバ実行時にMSC-B内で暗号化アルゴリズムが変更された場合、ここのことを次の処理
内でMSC-Aにレポートする必要がある：
-
the BSSMAP Handover Performed procedure which shall be initiated by MSC-B on reception from BSSB of the Handover Complete message (the information being previously received in the Handover
Request Acknowledge message).
BSSMAP Handover Performed処理。本処理は、MSC-BがBSS-BからHandover Completeメッセージ受
信時に、MSC-Bが開始すること（それまでにHandover Request Acknowledgeメッセージ内で受信してい
る情報）
Note also that the chosen encryption value may be contained in the BSSMAP Assignment Complete
message. This may happen if the encryption value changes e.g. at a second assignment during a call (e.g.
from TCH to SDCCH).
選択された暗号化値は、BSSMAP Assignment Completeメッセージ中に入れることもできることに注
意。このケースは、例えば1回の呼接続中に暗号化値が2回割当てられて変更された場合（例えばTCH
からSDCCH）になどに起こりうる。
4.5.5.2
Channel Type （チャネルタイプ）
Assignment Request and Handover Request (BSSMAP) may give the BSS a choice, in the same way as the Encryption
Algorithm above. Depending on the Channel Type Info, the chosen channel may have impact on subsequent handovers,
internal in MSC-B and inter-MSC controlled by MSC-A. Some values in channel Type Info indicate that if a particular
channel once has been chosen, the same type must be used for the rest of the call.
Assignment Request および Handover Request (BSSMAP) は、BSSに上述の暗号化アルゴリズムの選択の場合と
同じような選択肢を与えることがある。Channel Type Infoに基づいて、選択されたチャネルは、その後のハンドオー
バ、MSC-B内ハンドオーバやMSC-Aによって制御されるMSC間ハンドオーバにインパクトを与える場合がある。
channel Type Info内のいくつかの値は、特定のチャネルが既に一度選択されたか否か、呼の後半でも同じタイプの
チャネルを使用すべきか否かを通知する。
The Channel Type, and the characteristics of the chosen channel shall be stored by MSC-B, and the Chosen Channel
and/or Speech Version information elements transferred to MSC-A.
MSC-Bは、Channel Type、選択されたチャネルのキャラクタ、そしてMSC-Aに送信されたChosen Channel および／
または Speech Versionを保存すること。
Transfer of Information:
送信される情報：
Independently of the type of resource (Signalling only (e.g. SDCCH) or TCH) assigned to the MS, the Channel
Type Information is transferred to MSC-B in:
MSに割当てられたリソースのタイプと無関係な情報（Signallingのみ（例えばSDCCH）か、TCHか）、Channel
Type Information は次のメッセージ中に入れられてMSC-Bに送信される：
-
the Handover Request BSSMAP message, and the Chosen Channel and/or Speech Version should be
reported back to MSC-A in the Handover Request Acknowledge.
Handover Request BSSMAPメッセージ、Chosen Channel および／または Speech Versionは、Handover
Request Acknowledge中でMSC-Aに対してレポートバックすること。
If a new type of resource is to be assigned after Inter-MSC Handover, this can be made with:
MSC間ハンドオーバ後に新しいタイプのリソースを割当てるべき場合､リソースを次のようにして作ることがで
きる：
-
the BSSMAP Assignment procedure between MSC-A and MSC-B (Chosen Channel and/or Speech Version
in Assignment Complete).
MSC-AとMSC-Bの間のBSSMAP Assignment処理（Assignment Complete内のChosen Channel および／
または Speech Version）
If the Channel Type (the chosen channel and/or chosen speech version) is changed at an intra-BSS handover in
BSS-B this must be reported to MSC-A in:
BSS-B内のBSS内ハンドオーバ時にChannel Type（選択されたチャネル および／または 選択されたスピーチ
バージョン）が変更された場合、このことをMSC-Aに対して次の処理内でレポートする必要がある：
3GPP
Release 1999
-
46
3GPP TS 29.010 V3.10.0 (2002-12)
the BSSMAP Handover Performed procedure.
BSSMAP Handover Performed処理
If the Channel Type (the chosen channel or chosen speech version) is changed at an intra-MSC handover in
MSC-B this must be reported to MSC-A in:
MSC-B内のMSC内ハンドオーバ時にChannel Type（選択されたチャネル および／または 選択されたスピー
チバージョン）が変更された場合には、このことをMSC-Aに対して次の処理内でレポートする必要がある：
-
4.5.5.3
the BSSMAP Handover Performed procedure which shall be initiated by MSC-B on reception from BSS-B
of the Handover Complete message (the information being previously received in the Handover Request
Acknowledge message).
Handover Complete メッセージをBSS-Bから受信したMSC-Bは、BSSMAP Handover Performed処理を開
始すること（情報は既にHandover Request Acknowledgeメッセージ内で受信している）
Classmark（クラスマーク）
This information shall be stored by MSC-B and might be received either from MSC-A, or from the MS when the MS
initiates a Classmark Update.
MSC-Bは、MSC-Aから、またはMSがClassmark Updateを開始したときにはMSから、本情報を受信したならばそれを
保存すること。
Transfer of Information due to Classmark received from MSC-A:
MSC-Aから受信したClassmarkに起因する情報の送信：
This information shall be stored by MSC-B and is received:
MSC-Bは以下のメッセージ内で受信した本情報を保存すること：
-
in the Handover Request BSSMAP message.
Handover Request BSSMAPメッセージ
If a new type of resource is to be assigned after Inter-MSC Handover, Classmark Information MAY be included:
MSC間ハンドオーバ後に新しいタイプのリソースの割当てるべき場合には、次の処理中にClassmark
Information が含まれることもある：
-
in the BSSMAP Assignment procedure.
BSSMAP Assignment 処理
Transfer of Information, due to "Classmark Signalling Procedures".
"Classmark Signalling Procedures"に起因する情報の送信
This information shall be stored by MSC-B and can be received:
MSC-Bは以下のメッセージ内で受信できる本情報を保存すること：
-
Due to a classmark update, either requested from MSC-A (Classmark Request, Classmark Update), or an
MS-Initiated Classmark Update.
MSC-Aからの要求（Classmark Request, Classmark Update）、またはMSが開始したClassmark Updateのい
ずれかによって要求された、クラスマークの更新に起因
This can be carried out either with:
本情報は、次処理と一緒に処理することができる：
-
the BSSMAP Classmark procedure(s).
（1つまたは複数の）BSSMAP Classmark処理
Apart from these cases there is the "odd" case where a Classmark Update can be received during an Inter-MSC
Handover by MSC-B, i.e. before the MS has moved to the new channel controlled by MSC-B. This can be made
with transparent transfer of BSSMAP Classmark Update.
これらのケースを除き、MSC間ハンドオーバの間、すなわちMSがMSC-Bによって制御される新しいチャネル
に移動する前に、MSC-BがClassmark Updateを受信する、という「まれな」ケースが存在する。このようなケー
スは、BSSMAP Classmark Updateの透過的送信によって引き起こされる。
3GPP
Release 1999
4.5.5.4
47
3GPP TS 29.010 V3.10.0 (2002-12)
Downlink DTX-Flag（下りリンクDTXフラグ）
The parameter shall be stored by MSC-B to be used at internal Handover in MSC-B.
MSC-Bは本パラメータを保存して、MSC-B内ハンドオーバ時に使用すること。
Transfer of Information:
情報の送信
Received by MSC-B from MSC-A in either:
次のいずれかのケースによって、MSC-BがMSC-Aから受信：
If the MS has already been assigned to a TCH for speech before the Inter-MSC Handover, the DTX-flag
should be sent in:
MSC間ハンドオーバ前に、MSに対して既に音声用にTCHが割当てられている場合には、DTX-flagは次
のメッセージ内で送信すること：
-
the Handover Request BSSMAP message;
Handover Request BSSMAPメッセージ
(if the type of resource is not TCH for speech, the DTX-flag shall not be included).
（リソースのタイプが音声用TCHでない場合には、DTX-flagを含めてはならない）
If a new assignment to a TCH for speech after an Inter-MSC Handover is to be performed, this can be made
with:
MSC間ハンドオーバ後に音声用に新たにTCHを割当てるべき場合には、次の処理と一緒に行なわれる：
-
4.5.5.5
the BSSMAP Assignment procedure.
BSSMAP Assignment 処理
Priority（優先度）
The parameter shall be stored by MSC-B and is received according to below:
MSC-Bはパラメータを保存し、以下の情報に従って受信する：
Transfer of Information:
情報の送信
Received by MSC-B from MSC-A in:
MSC-BがMSC-Aから次のメッセージ内で受信
-
the Handover Request BSSMAP message.
Handover Request BSSMAPメッセージ
If a change is needed after an Inter-MSC Handover with:
MSC間ハンドオーバ後に変更が必要な場合には、次の処理と一緒に行なわれる：
-
4.5.5.6
the BSSMAP Assignment procedure.
BSSMAP Assignment 処理
MSC/BSC-Invoke Trace Information Elements（MSC/BSC-Invoke Trace IE）
The process to be performed by MSC-B on the information elements of the MSC or BSC Invoke Trace BSSMAP
messages is left for further study.
MSC or BSC Invoke Trace BSSMAPメッセージのIE上で、MSC-Bが実行すべき処理についてはFFSとする。
4.5.5.7
LSA Identifier List （LSA Identifier List）
The parameter shall be stored by MSC-B and is received according to below:
MSC-Bはパラメータを保存すること。以下の情報に従って受信する：
3GPP
Release 1999
48
3GPP TS 29.010 V3.10.0 (2002-12)
Transfer of Information:
情報の送信
Received by MSC-B from MSC-A in:
次のメッセージ内でMSC-BがMSC-Aから受信
-
the Handover Request BSSMAP message.
Handover Request BSSMAPメッセージ
If a change is needed after an Inter-MSC Handover with:
MSC間ハンドオーバ後に変更が必要な場合には、次の処理と一緒に行なわれる：
-
4.5.5.8
the LSA Information BSSMAP message.
LSA Information BSSMAP メッセージ
Selected UMTS Algorithm（選択されたUMTSアルゴリズム）
After inter-MSC handover, the 3G_MSC-B can perform intra-MSC GSM to UMTS handover. A sequence of possible
encryption and integrity protection algorithms, received from the 3G_MSC-A, can be sent to an RNS in Relocation
Request or in Security Mode Command in case of cipher mode setting after intra.MSC-B handover from GSM to
UMTS. The RNS chooses one of the listed algorithms and reports this back to the 3G_MSC in Relocation Request
Acknowledge or Security Mode Complete respectively. The MSC-B provides the Selected UMTS algorithm
information to the MSC-A. The Selected UMTS algorithms IE in the MAP Process Access Signalling Request message
refers to the Chosen Integrity Protection Algorithm and Chosen Encryption Algorithm, defined in RANAP
specification 3GPP TS 25.413
MSC間ハンドオーバ後に、3G_MSC-BはGSMからUMTSへのMSC内ハンドオーバを実行することができる。
3G_MSC-Aから受信した、暗号化と完全性保護アルゴリズムの想定されるシーケンスは、Relocation Request また
はSecurity Mode Command（GSMからUMTSへのMSC-B内ハンドオーバ後に暗号化モードが設定された場合）中
に入れて、RNSに送信することができる。RNSはリストアップされたアルゴリズムの中から1つを選択して、選択したア
ルゴリズムをRelocation Request Acknowledge または Security Mode Complete のいずれかに入れて、3G_MSCに
レポートバックする。MSC-BはSelected UMTS algorithm情報をMSC-Aに提供する。MAP Process Access Signalling
Requestメッセージ中のSelected UMTS algorithms IEは、RANAP仕様書3GPP TS 25.413に定義されるChosen
Integrity Protection AlgorithmおよびChosen Encryption Algorithmを参照する。
The selected algorithm shall be stored by 3G_MSC-B, and sent to 3G_MSC-A.
3G_MSC-Bは選択されたアルゴリズムを保存し、3G_MSC-Aに対して送信すること。
Transfer of Information:
情報の送信：
If ciphering has not been performed before Inter-MSC Handover, this will be controlled by 3G_MSC-A after the
completion of Inter-MSC Handover and possibly after intra-MSC-B handover from GSM to UMTS. In both
cases Selected UMTS algorithm information is received by 3G_MSC-A from 3G_MSC-B in:
MSC間ハンドオーバ前に暗号化が実行されなかった場合には、MSC間ハンドオーバの完了後、あるいはもし
かするとGSMからUMTSへのMSC-B内ハンドオーバ後に、3G_MSC-Aが暗号化を制御する。いずれの場合
でも、3G_MSC-Aは、次のメッセージ中で3G_MSC-BからSelected UMTS algorithm情報を受信する：
−
The Process Access Signalling Request MAP message.
Process Access Signalling Request MAPメッセージ
4.5.5.9
Allowed UMTS Algorithms（許容されたUMTSアルゴリズム）
In case of GSM-subscriber, the Integrity Protection Information and UMTS Encryption Information are not transferred
to the MSC-B during inter-MSC handover. Allowed UMTS algorithms is UMTS information that is required in
RANAP Relocation Request and RANAP Security Mode Command, and shall be provided by 3G_MSC-A. 3G_MSC-B
needs this information in case of an intra-MSC GSM to UMTS handover and in subsequent security mode setting,
after an inter-MSC handover. Therefore 3G_MSC-A must provide this information in case of an inter-MSC GSM to
GSM handover. The Allowed UMTS algorithms IE in the MAP Prepare Handover and in the MAP Forward Access
Signalling Request messages refers to the Permitted Integrity Protection Algorithms in Integrity Protection
Information and Permitted Encryption Algorithms in Encryption Information, defined in RANAP specification 3GPP
3GPP
Release 1999
49
3GPP TS 29.010 V3.10.0 (2002-12)
TS 25.413.
GSM加入者の場合には、Integrity Protection Information（完全性保護情報）およびUMTS Encryption Information
（UMTS暗号化情報）は、MSC間ハンドオーバ時にMSC-Bに送信されることはない。Allowed UMTS algorithmsは
UMTSの情報であり、RANAP Relocation Request およびRANAP Security Mode Command中で要求され、
3G_MSC-Aによって提供される。GSMからUMTSへのMSC内ハンドオーバの場合と、MSC間ハンドオーバ後のセキ
ュリティモード設定の場合に、3G_MSC-Bが本情報を必要とする。であるから、GSMからGSMへのMSC間ハンドオー
バの場合、3G_MSC-Aが本情報を提供する必要がある。MAP Prepare HandoverおよびMAP Forward Access
Signalling Requestメッセージ内のAllowed UMTS algorithms IEは、Integrity Protection Information中のPermitted
Integrity Protection AlgorithmsおよびEncryption Information中のPermitted Encryption Algorithmsを参照する。これら
については、RANAP仕様書3GPP TS 25.413に定義される。
Allowed UMTS algorithms shall be stored by 3G_MSC-B.
3G_MSC-Bは、Allowed UMTS algorithmsを保存すること。
Transfer of information:
情報の送信：
If ciphering has not been performed before Inter-MSC Handover, this will be controlled by 3G_MSC-A after the
completion of Inter-MSC Handover.
MSC間ハンドオーバ前に暗号化が実行されなかった場合、MSC間ハンドオーバ完了後に3G_MSC-Aが暗号
化を制御する。
Ciphering control towards 3G_MSC-B:
3G_MSC-Bに対する暗号化制御：
If Ciphering has been performed before Inter-MSC Handover:
MSC間ハンドオーバ前に暗号化が実行された場合：
−
The Prepare Handover Request MAP message.
Prepare Handover Request MAPメッセージ
If Ciphering has NOT been performed before Inter-MSC Handover:
MSC間ハンドオーバ前に暗号化が実行されなかったならば：
The Forward Access Signalling Request MAP message.
Forward Access Signalling Request MAPメッセージ
4.5.5.10
BSSMAP Service Handover（BSSMAP Service Handover）
This information shall be stored by 3G_MSC-B and sent to a BSS in Handover Request, when 3G_MSC-B performs
handover to GSM.
本情報は3G_MSC-Bによって保存され、3G_MSC-BがGSMへのハンドオーバを実行する時に、Handover Request中
でBSSに送信すること。
Transfer of information:
情報の送信：
The BSSMAP Service Handover information is transferred to 3G_MSC-B in:
BSSMAP Service Handover情報は、次のメッセージ中で3G_MSC-Bに対して送信される：
− the Handover Request BSSMAP message.
Handover Request BSSMAP メッセージ
If a new assignment of a TCH after an inter-MSC handover is to be performed, the BSSMAP Service Handover
information is transferred to 3G_MSC-B in:
MSC間ハンドオーバ後に新たにTCH割当を実行すべき場合には、次の処理中でBSSMAP Service Handover
情報が3G_MSC-Bに送信される：
3GPP
Release 1999
50
3GPP TS 29.010 V3.10.0 (2002-12)
− the BSSMAP Assignment procedure.
BSSMAP Assignment処理
4.5.5.11
RANAP Service Handover（RANAP Service Handover）
This information shall be stored by 3G_MSC-B and sent to an RNS in Relocation Request, when 3G_MSC-B performs
relocation or handover to UMTS.
本情報は3G_MSC-Bによって保存され、3G_MSC-BがUMTSに対してリロケーションまたはハンドオーバを実行する
際に、RNSに送信すること。
Transfer of information:
情報の送信：
The RANAP Service Handover information is transferred to 3G_MSC-B in:
RANAP Service Handover情報は、次のメッセージ中で3G_MSC-Bに送信される：
− the Prepare Handover Request MAP message.
Prepare Handover Request MAP メッセージ
If a new assignment of a Radio Access Bearer after an inter-MSC handover is to be performed, the information
is transferred to 3G_MSC-B in:
MSC間ハンドオーバ後に新たにRAB（Radio Access Bearer）を割当てるべき場合には、情報は次のメッセージ
中で3G_MSC-Bに送信される：
− the Forward Access Signalling Request MAP message
Forward Access Signalling Request MAP メッセージ
and sent by 3G_MSC-B to the RNS in RAB Assignment Request.
そして、3G_MSC-BはRAB Assignment Request中でRNSに送信する。
3GPP
Release 1999
4.5.6
51
3GPP TS 29.010 V3.10.0 (2002-12)
Overview of the Technical Specifications GSM interworking for the Inter-MSC Handover
（MSC間ハンドオーバのためのGSMインターワーキング技術仕様書一覧）
╔══════════════════════════════════════════════════════════════════════════════════════════════════╗
║ PSTN/ISDN
║
║
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
║
║
▒
+---------------+
▒
║
║ ==============▒====== | ============= | ===============
▒
║
║ PLMN
▒
|
|
▒
║
║
▒
V
V
▒
║
║ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒
║
║ ▒ BSS-A
MSC-A
MSC-B
BSS-B
▒
MS
║
║ ▒
▒
║
║ ▒
+-------+
▒ +-------+
║
║ ▒
| C M |
24.008 (Note)
▒ | C M |
║
║ ▒
+-------|<------------------------------------>+-------|
║
║ ▒ ░░░░░░░░░░░░░░░ | M M | ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒ | M M |
║
║ ▒ ░+------+ 08.08 +-------| 08.08'+-------+ 08.08 +-------+ ░▒ +-------|
║
║ ▒ ░| R R |<----->| R R |<=====>| R R |<----->| R R | ░▒ | R R |
║
║ ▒ ░+------+
+-------+ (Note)+-------+
+-------+ ░▒ +-------+
║
║ ▒ ░
Λ Λ
Λ Λ
░▒
║
║ ▒ ░
|
|
29.010 | |
░▒ Note: Subset of 08.08
║
║ ▒ ░
|
V
V |
░▒
procedures as described ║
║ ▒ ░
|+-----+ 29.002+-----+|
░▒
in the TS 3GPP TS 48.008. ║
║ ▒ ░
||MAP/E|<----->|MAP/E||
░▒
║
║ ▒ ░
|+-----+
+-----+|
23.009░▒
║
║ ▒ ░░░░░░░░░░░░░░░░ | ░░░░░░░░░░░░░░░░░░░ | ░░░░░░░░░░░░░░░░░░░▒ Remark: The A-bis interface and ║
║ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ V ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ V ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
the link layer
║
║
+-----------------------+
protocols being out of ║
║
|
T C A P
|
the scope of this
║
║
+-----------------------+
Specification are not ║
║
+------------------------------------------------------+
shown here.
║
║
|
S C C P
|
║
║
+------------------------------------------------------+
║
║
+------------------------------------------------------+
║
║
|
M T P
|
║
║
+------------------------------------------------------+
║
╚══════════════════════════════════════════════════════════════════════════════════════════════════╝
3GPP
Release 1999
4.6
52
3GPP TS 29.010 V3.10.0 (2002-12)
Inter-MSC Handover (UMTS to GSM)
（MSC間ハンドオーバ（UMTSからGSMへ））
The general principles of the handover procedures are given in 3GPP TS 23.009. 3GPP TS 29.010 gives the necessary
information for interworking between the 3GPP TS 25.413 RANAP protocol, GSM handover procedures and the 3GPP
TS 29.002 MAP protocol. The RANAP protocol is used between the RNS and the 3G-MSC.
ハンドオーバ処理の原則については、3GPP TS 23.009で与えられる。3GPP TS 29.010では、3GPP TS 25.413 に記
載されるRANAPプロトコル、GSMのハンドオーバ処理、そして3GPP TS 29.002に記載されるMAPプロトコル間のイン
ターワーキングに必要な情報を与える。RANAPプロトコルは、RNSと3G-MSC間で使用される。
The following three principles apply for the Inter-MSC handover UMTS to GSM:
UMTSからGSMへのMSC間ハンドオーバに関しては、次の3つの原則が適用される：
The BSSMAP parameters required for Inter-MSC handover UMTS to GSM are generated as in GSM.
UMTSからGSMへのMSC間ハンドオーバに必要なBSSMAPパラメータは、GSM側で生成されること。
Received BSSMAP parameters, e.g. cause code or Handover command, are mapped to the appropriate RANAP
parameters, e.g. cause code transparent container to source RNS.
理由コードまたはHandoverコマンドなど、受信したBSSMAPパラメータは、source RNSに対するcause code transparent
container等の適切なRANAPパラメータにマッピングされること。
4.6.1 Basic Inter-MSC Handover（基本的MSC間ハンドオーバ）
When a Mobile Station is handed over between two MSCs, the establishment of a connection between them (described
in 3GPP TS 23.009) requires interworking between A-Interface and E-Interface.
MSが2つのMSC間でハンドオーバされる場合、（3GPP TS 23.009に説明されるように）両者の間でコネクションを確立
するために、AインタフェースとEインタフェース間のインターワーキングが要求される。
The signalling at initiation, execution, completion of the Basic Inter-MSC handover procedure is shown in figures 21 to
26 with both possible positive or negative outcomes.
基本的MSC間ハンドオーバ処理の開始、実行、完了のシグナリングを、処理が成功した場合と失敗した場合のそれ
ぞれについて、図21から図26に示す。
Additionally figure 21b shows the possible interworking when the trace related message is transparently transferred on
the E-Interface at Basic Inter-MSC Handover initiation.
さらに図21bに、基本的MSC間ハンドオーバ開始時にEインタフェース上でトレース関連メッセージを透過的に送信す
る場合に想定されるインターワーキングを示す。
RNS-A
3G-MSC-A
MSC-B
|
|
|
|RELOCATION
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request
| |Possible Alloc. |
|
|
| |of a handover
|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|------------------>|
Figure 21a: Signalling for Basic Inter-MSC Handover initiation (no trace related messages
transferred)
図21a：基本的MSC間ハンドオーバ開始のシグナリング（トレース関連メッセージが送信されない場合）
3GPP
Release 1999
53
3GPP TS 29.010 V3.10.0 (2002-12)
RNS-A
3G-MSC-A
MSC-B
|
(*)
|
|RELOCATION
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request(**)
| |Possible Alloc. |
|
|
| |of a handover
|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|------------------>|
|
|
|
|
|
|
|MSC INVOKE TRACE
|
|
|
|--------------->(***)
Figure 21b: Signalling for Basic Inter-MSC Handover initiation (MSC invoke trace message
transferred)
図21b：基本的MSC間ハンドオーバ開始のシグナリング（MSC invoke traceメッセージが送信される場合）
(*):
Tracing invocation has been received from VLR.
トレースの起動はVLRから既に受信している。
(**):
In that case, HANDOVER REQUEST and MSC INVOKE TRACE messages are included within the
AN-APDU parameter.
このケースでは、AN-APDUパラメータ中にHANDOVER REQUESTおよびMSC INVOKE TRACEメッ
セージが含まれる。
(***):
MSC INVOKE TRACE is forwarded to BSS-B if supported by MSC-B.
MSC-Bがサポートする場合、MSC INVOKE TRACEはBSS-Bに転送される。
Possible Positive outcomes:
想定される処理の成功：
a)
successful radio resources allocation and handover number allocation (if performed):
無線リソース割当とハンドオーバ番号割当（実行される場合）に成功した場合：
RNS-A
3G-MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|RELOCATION COMMAND
|
|
|<--------------|
|
|
3GPP
Release 1999
54
3GPP TS 29.010 V3.10.0 (2002-12)
b) radio resources allocation queued and successful handover number allocation (if performed). Later successful
radio resources allocation indication:
無線リソース割当がキューイングされ、ハンドオーバ番号割当（もし実行されれば）に成功。その後無線リソ
ース割当成功が通知される：
RNS-A
3G-MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
|MAP PROCESS ACCESS
|
|
|
|<------------------------|
| RELOCATION COMMAND
SIGNALLING request |
|
|<--------------|
|
|
|
|
|
|
Figure 22: Signalling for Basic Inter-MSC Handover execution (Positive outcomes)
図22：基本的MSC間ハンドオーバ実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
c)
user error detected, or handover number allocation unsuccessful (if performed), or component rejection or
dialogue abortion performed by MSC-B:
ユーザエラーの検出、またはハンドオーバ番号割当（もし実行されれば）に失敗、またはMSC-Bがコンポーネ
ントを拒否、またはダイヤログの中断を実行：
RNS-A
3G-MSC-A
MSC-B
|
|
|
|
|MAP PREPARE HANDOVER response
|
|negative result, MAP CLOSE
|
|<------------------------|
|
|MAP U/P-ABORT
|
|
|
|
|RELOCATION PREPARATION
|
|<--------------|
|
|FAILURE(Note 1)|
|
|
|
|
BSS-B
|
|
|
|
|
|
|
|
|
|
d) radio resources allocation failure:
無線リソース割当の失敗：
RNS-A
3G-MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|HANDOVER FAILURE
|
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|RELOCATION PREPARATION
|
|
|<--------------|
|
|
|FAILURE(Note 1)|
|
|
|
|
|
|
3GPP
Release 1999
e)
55
3GPP TS 29.010 V3.10.0 (2002-12)
radio resources allocation queued and successful handover number allocation (if performed). Later unsuccessful
radio resources allocation:
無線リソース割当がキューイングされ、（もし実行されれば）ハンドオーバ番号割当てが成功。その後、無線リ
ソース割当が失敗：
RNS-A
3G-MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|
|
|HANDOVER FAILURE
|
|
|
|<------------------|
|
|MAP PROCESS ACCESS
|
|
|
|<------------------------|
|
|
| SIGNALLING request
|
|
|
|
|
|
|RELOCATION PREPARATION
|
|
|<--------------|
|
|
|FAILURE(Note 1)|
|
|
f)
unsuccessful handover execution (Reversion to the old radio resources):
ハンドオーバ実行が失敗（旧無線リソースへの復帰）
RNS-A
3G-MSC-A
MSC-B
BSS-B
|
|
|
|
|RELOCATION
|
|
|
|-------------->|
|
|
|CANCEL
|
|
|
|
|MAP U -ABORT
|
|
|
|------------------------>|
|
|
|
|CLEAR COMMAND
|
|
|
|------------------>|
|RELOCATION
|
|
|
|<--------------|
|
|
|CANCEL ACK
|
|
|
Figure 23: Signalling for Basic Inter-MSC Handover execution (Negative outcomes)
図23：基本的MSC間ハンドオーバ実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or RANAP procedure.
MAPまたはRANAP処理が失敗したためにハンドオーバが拒否された場合などが想定される。
RNS-A
3G-MSC-A
MSC-B
BSS-B
|
|
|
|
|
|
|HANDOVER COMPLETE |
|
|
|<------------------|
|
|MAP SEND END SIGNAL request
|
|
|<------------------------|
|
|IU RELEASE COMMAND
|
|
|<--------------|
|
|
|
|
|
|
Figure 24: Signalling for Basic Inter-MSC Handover completion
図24：基本的MSC間ハンドオーバ完了のシグナリング
3GPP
Release 1999
56
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome:
処理の成功：
RNS-A
|
|
|
|
|
|
3G-MSC-A
MSC-B
BSS-B
|
|
|
|MAP SEND END SIGNAL
|
|
|------------------------>|
|
| response
|CLEAR COMMAND
|
|
|------------------>|
|
| (Note 2)
|
Figure 25: Signalling for Basic Inter-MSC Handover completion (Positive outcome)
図25：基本的MSC間ハンドオーバ完了のシグナリング（処理の成功）
Negative outcome:
処理の失敗：
RNS-A
|
|
|
|
|
|
3G-MSC-A
MSC-B
BSS-B
|
|
|
| MAP U/P -ABORT
|
|
|------------------------>|
|
|
|CLEAR COMMAND
|
|
|------------------>|
|
|
|
Figure 26: Signalling for Basic Inter-MSC Handover completion (Negative outcome)
図26：基本的MSC間ハンドオーバ完了のシグナリング（処理の失敗）
NOTE 2: From interworking between MAP and BSSMAP point of view, when the call is released.
MAPとBSSMAP間のインターワーキングという観点から見ると、呼が開放されたとき。
The handover procedure is normally triggered by RNS-A by sending a RELOCATION REQUIRED message on IuInterface to 3G-MSC-A. The invocation of the Basic Inter-MSC handover procedure is performed and controlled by
3G-MSC-A. The sending of the MAP Prepare-Handover request to MSC-B is triggered in 3G-MSC-A upon receipt of
the RELOCATION REQUIRED message. For compatibility reason, the cell identity of the cell where the call is to be
handed over in MSC-B area, provided in the RELOCATION REQUIRED message, is mapped into targetCellId MAP
parameter and the HANDOVER REQUEST message is encapsulated in the AN-APDU MAP parameter of the
Prepare-Handover MAP request. MSC-B can invoke another operation towards the VLR-B (allocation of the handover
number described in 3GPP TS 29.002).
ハンドオーバ処理は通常、RNS-AがIuインタフェース上で3G-MSC-AにRELOCATION REQUIREDを送信すること
によってトリガされる。基本的MSC間ハンドオーバ処理の起動は、3G-MSC-Aによって実行・制御される。
RELOCATION REQUIREDメッセージを受信すると、3G-MSC-A内でMSC-BへのMAP Prepare-Handover要求の送
信がトリガされる。互換性上の理由から、MSC-Bのエリア内の呼のハンドオーバ先のセルのセルIDは、
RELOCATION REQUIREDメッセージ中で提供されるが、セルIDはtargetCellId MAPパラメータ中にマッピングさ
れ、HANDOVER REQUESTメッセージはPrepare-Handover MAP要求のAN-APDU MAPパラメータ中にカプセル化
される。MSC-Bはそれ以外のオペレーションをVLR-Bに対して起動することができる（ハンドオーバ番号の割当につ
いては3GPP TS 29.002中で説明される）。
Additionally, if tracing activity has been invoked, the trace related message can be transferred on the E-Interface
encapsulated in the AN-APDU MAP parameter of the Prepare-Handover Request. If transferred, one complete trace
related message at a time shall be included in the AN-APDU MAP parameter after the HANDOVER REQUEST
message.
さらに、トレースアクティビティが既に起動されている場合には、トレース関連メッセージをPrepare-Handover Request
のAN-APDU MAPパラメータ中にカプセル化してEインタフェース上で送信することもできる。トレース関連メッセージ
を送信する場合には、HANDOVER REQUEST の後に、一連の完全なトレース関連のメッセージを同じAN-APDU
MAPパラメータ中に含めること。
3GPP
Release 1999
57
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Prepare Handover and RELOCATION REQUIRED is as follows:
Prepare HandoverとRELOCATION REQUIRED間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION REQUIRED MAP PREPARE HANDOVER request|
message |
|
|
-ho-NumberNotRequired|
1
| RANAP information
-targetCellId
|
|
elements
-AN-APDU(
|
2
|
HANDOVER REQUEST,
|
| |
| MSC INVOKE TRACE)
|
--------┼-------------------------------------------------┼----Positive| RELOCATION CMD
MAP PREPARE HANDOVER response|
result |
|
3
|
-handover number
|
|
-AN-APDU(
|
|
QUEUING INDICATION |
|
or HANDOVER REQUEST|
|
ACKNOWLEDGE)
|
|
|
--------┼-------------------------------------------------┼----Negative| RELOCATION PREP FAILURE
MAP PREPARE HANDOVER|
4
result |
|
| Relocation failure in
System Failure
|
| target RNC/CN or target system|
|”
No Handover Number |
|
available
|
|”
UnexpectedDataValue|
|”
Data Missing
|
|
|
|”
MAP CLOSE
|
|”
MAP U/P -ABORT
|
|
|
NOTE 1: The BSSMAP information elements are already stored in 3G-MSC.
BSSMAP IEは既に3G-MSC内に保存されている。
The ho-NumberNotRequired parameter is included by 3G-MSC-A, when 3G-MSC-A decides not to use
any circuit connection with MSC-B. No handover number shall be present in the positive result. Any
negative response from MSC-B shall not be due to handover number allocation problem.
3G-MSC-AがMSC-Bとの回線交換コネクションを使用しないことを決めた場合には、3G-MSC-AはhoNumberNotRequired パラメータを含める。ポジティブな結果中には、ハンドオーバ番号が含まれてはな
らない。MSC-Bからのネガティブな応答は全て、ハンドオーバ番号割当問題に起因するものであって
はならない。
NOTE 2: The process performed on the RANAP information elements received in the RELOCATION REQUIRED
message is described in the 3GPP TS 25.413.
RELOCATION REQUIREDメッセージ中で受信したRANAPのIE上で実行される処理については、
3GPP TS 25.413で説明される。
NOTE 3: The response to the Prepare-Handover request can include in its AN-APDU parameter, identifying the
GSM 08.06 protocol, either a BSSMAP QUEUING INDICATION, or a BSSMAP HANDOVER
REQUEST ACKNOWLEDGE.
Prepare-Subsequent-Handover要求に対する応答をそのAN-APDUパラメータ中に入れて、GSM 08.06
プロトコルがBSSMAP QUEUING INDICATION、またはBSSMAP HANDOVER REQUEST
ACKNOWLEDGEのいずれかであることを識別することもできる。
In the first case, 3G-MSC-A shall wait for the radio resources allocation response from MSC-B,
transmitted to 3G-MSC-A as described in subclause 4.5.4.
一番目のケースでは3G-MSC-Aは、4.5.4節で述べる手順でMSC-Bから3G-MSC-Aに送信される、無
線リソース割当応答を待つこと。
3GPP
Release 1999
58
3GPP TS 29.010 V3.10.0 (2002-12)
In the second case, the positive result triggers in 3G-MSC-A the sending on Iu-Interface of the
RELOCATION CMD.
二番目のケースでは、処理が成功すると、3G-MSC-A内でIuインタフェース上のRELOCATION CMD
送信がトリガされる。
In the third case, the positive result triggers in 3G-MSC-A.
三番目のケースでは、処理が成功すると、MSC-A内でトリガされる。
NOTE 4: The possible sending of the RELOCATION PREP FAILURE message is described in the 3G 25.413.
RELOCATION PREP FAILUREメッセージの送信の可能性については、3G 25.413中で説明される。
(The possible sending of the RELOCATION PREP FAILURE message upon receipt of the HANDOVER
FAILURE is out of the scope of the 3GPP TS 29.010 and lies in the 3GPP TS 25.413).
（HANDOVER FAILUREの受信によるRELOCATION PREP FAILUREメッセージの送信の可能性に
ついては3GPP TS 29.010のスコープ外であり、3GPP TS 25.413に記載される）
The interworking between Send End Signal and HANDOVER COMPLETE in MSC-B is as follows:
MSC-B内でのSend End Signal とHANDOVER COMPLETE間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER COMPLETE
MAP SEND END SIGNAL request |
message |
|
|
-AN-APDU(
|
|
HANDOVER COMPLETE)|
|
|
--------┼-------------------------------------------------┼----Positive| CLEAR COMMAND
MAP SEND END SIGNAL response|
result | -Call Control release
| 1
--------┼-------------------------------------------------┼----Negative| CLEAR COMMAND
|
result | -Call Control release
MAP CLOSE
| 2
| -Call Control release
MAP U/P -ABORT
|
|
|
NOTE 1: The positive empty result triggers the clearing of the Radio Resources on the A-Interface and the release
of the SCCP connection between MSC-B and BSS-B. If a circuit connection is used between 3G_MSC-A
and MSC-B, the 'Call Control release' clearing cause shall only be given to BSS-B when MSC-B has
received a clearing indication on its circuit connection with 3G_MSC-A.
ポジティブなエンプティな結果は、Aインタフェース上での無線リソースのクリアと、MSC-BとBSS-B間の
SCCPコネクションの開放をトリガする。3G_MSC-AとMSC-B間で回線交換コネクションが使用される場
合には、MSC-Bが3G_MSC-Aとの回線交換コネクション上でクリア通知を受信したならば、BSS-B に
対して'Call Control release' クリア理由だけを与えること。
NOTE 2: The abortion of the dialogue or the rejection of the component triggers in MSC-B the clearing of its
circuit connection with 3G_MSC-A, if any, of the Radio Resources on the A-Interface and the release of
the SCCP connection between MSC-B and BSS-B.
ダイヤログの中断またはコンポーネントの拒否が起きた場合、MSC-B内で3G_MSC-Aとの回線交換コ
ネクションの開放と、もしあればAインタフェース上での無線リソースの開放と、MSC-B とBSS-B間の
SCCPコネクションの開放がトリガされる。
3GPP
Release 1999
59
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Send End Signal and IU RELEASE COMMAND in 3G_MSC-A is as follows:
3G_MSC-A内の、Send End Signal とIU RELEASE COMMAND間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP SEND END SIGNAL
IU RELEASE COMMAND |
message | response
|
|
-AN-APDU(
|
|
HANDOVER COMPLETE)
|
|
Successful Relocation
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
The interworking between RELOCATION CANCEL in case of reversion to old channel of the UE and User Abort in
3G-MSC-A is as follows:
UEが旧チャネルへ復帰する場合のRELOCATION CANCELと、3G-MSC-A内のUser Abort間のインターワーキング
について、以下に示す。
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION CANCEL
MAP U -ABORT
|
message |
|
| -Relocation cancelled
|
--------┼-------------------------------------------------┼----Positive| RELOCATION CANCEL ACKNOWLEDGEMENT
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
4.6.2 Subsequent Inter-MSC Handover from 3G-MSC-B back to MSC-A
（3G-MSC-BからMSC-Aへの後続MSC間ハンドオーババック）
When a Mobile Station is being handed over back to MSC-A, the procedure (described in TS 23.009) requires
interworking between A-Interface, Iu-interface and E-Interface.
MSがMSC-Aにハンドオーババックされた場合、（TS 23.009中で説明される）処理は、Aインタフェース、Iuインタフェ
ース、そしてEインタフェース間のインターワーキングを必要とする。
The signalling at initiation, execution and completion of the Subsequent Inter-MSC handover procedure is shown in
figures 27 to 31.
後続MSC間ハンドオーバ処理の開始・実行・完了時のシグナリングについて、図27から図31に示す。
RNS-A
3G-MSC-B
MSC-A
|
|
|
|RELOCATION
|
|
|-------------->|MAP PREPARE SUBSEQUENT
|
|REQUIRED
|------------------------>|
|
|HANDOVER request
|
|
|
|
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|------------------>|
Figure 27: Signalling for Subsequent Inter-MSC Handover back to MSC-A initiation
図27：MSC-Aへの後続MSC間ハンドオーババック開始のシグナリング
3GPP
Release 1999
60
3GPP TS 29.010 V3.10.0 (2002-12)
Possible Positive outcomes:
想定される処理の成功：
a)
successful radio resources allocation:
無線リソース割当に成功：
RNS-A
3G-MSC-B
MSC-A
BSS-B
|
|
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
| HANDOVER response
|
|
|RELOCATION CMD |
|
|
|<--------------|
|
|
b) radio resources allocation queued. Later successful radio resources allocation indication:
無線リソース割当がキューイング。その後無線リソース割当成功が通知される：
RNS-A
3G-MSC-B
MSC-A
BSS-B
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
| HANDOVER response
|
|
|
|
|HANDOVER REQUEST
|
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP FORWARD ACCESS
|
|
|
|<------------------------|
|
|
| SIGNALLING request
|
|
|RELOCATION CMD |
|
|
|<--------------|
|
|
Figure 28: Signalling for Subsequent Inter-MSC Handover back to MSC-A execution (Positive
outcome)
図28：MSC-Aへの後続MSC間ハンドオーババック実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
c)
user error detected, or component rejection or dialogue abortion performed by MSC-A:
ユーザエラーの検出、またはMSC-Aがコンポーネント拒否、またはダイヤログ中断を実行：
RNS-A
3G-MSC-B
MSC-A
|
|MAP PREPARE SUBSEQUENT HANDOVER
|
|<------------------------|
|RELOCATION PREP| response negative result|
|<--------------|
|
|FAILURE(Note 1)|
|
|
|
|
3GPP
BSS-B
|
|
|
|
|
|
Release 1999
61
3GPP TS 29.010 V3.10.0 (2002-12)
d) component rejection or dialogue abortion performed by MSC-A:
MSC-Aがコンポーネント拒否、またはダイヤログ中断を実行：
RNS-A
3G-MSC-B
MSC-A
|
|MAP CLOSE, MAP U/P ABORT |
|
|<------------------------|
|IU RELEASE
|
|
|<--------------|
|
|
COMMAND
|
|
e)
BSS-B
|
|
|
|
|
radio resources allocation failure:
無線リソース割当の失敗：
RNS-A
3G-MSC-B
MSC-A
BSS-B
|
|
| HANDOVER FAILURE |
|
|
|<------------------|
|
|MAP PREPARE SUBSEQUENT
|
|
|
|<------------------------|
|
|RELOCATION PREP|
HANDOVER response
|
|
|<--------------|
|
|
|FAILURE(Note 1)|
|
|
f)
radio resources allocation queued. Later unsuccessful radio resources allocation:
無線リソース割当がキューイング。その後無線リソース割当が失敗：
RNS-A
3G-MSC-B
MSC-A
BSS-B
|
|
|QUEUING INDICATION |
|
|
|<------------------|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
|
HANDOVER response
|
|
|
|
|HANDOVER FAILURE
|
|
|
|<------------------|
|
| MAP FORWARD ACCESS
|
|
|
|<------------------------|
|
|RELOCATION PREP|
SIGNALLING request
|
|
|<--------------|
|
|
|FAILURE(Note 1)|
|
|
Figure 29: Signalling for Subsequent Inter-MSC Handover back to MSC-A execution
(Negative outcome)
図29：MSC-Aへの後続MSC間ハンドオーババック実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or BSSMAP procedure.
MAPまたはRANAP処理が失敗したためにハンドオーバが拒否された場合などが想定される。
BSS-B
MSC-A
3G-MSC-B
RNS-A
|
|
|
|
|HANDOVER
|
|
|
|-------------->|MAP SEND END SIGNAL
|
|
|COMPLETE
|------------------------>|
|
|
| response
|
|
|
|
|Iu RELEASE COMMAND |
|
|
|------------------>|
Figure 30: Signalling for Subsequent Inter-MSC Handover back to MSC-A completion
(Successful completion of the procedure)
図30：MSC-Aへの後続MSC間ハンドオーババックの完了シグナリング（処理の成功による完了）
3GPP
Release 1999
NOTE:
62
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome case shown in figure 9.
処理が成功したケースは図9に示す。
BSS-B
MSC-A
3G-MSC-B
RNS-A
|
|
|
|
|HANDOVER
|
|
|
|-------------->|MAP SEND END SIGNAL
|
|
|COMPLETE
|------------------------>|
|
|
| response
|
|
|
|
|
|
|
|MAP U/P -ABORT
|
|
|
|<------------------------|
|
|
|
|Iu RELEASE COMMAND |
|
|
|------------------>|
|
|
|(Note 1)
|
Figure 31: Signalling for Subsequent Inter-MSC Handover back to MSC-A completion (Unsuccessful
completion of the procedure)
図31：MSC-Aへの後続MSC間ハンドオーババック完了のシグナリング（処理の失敗による完了）
NOTE 1: Abnormal end of the procedure which triggers the clearing of all resources in 3G-MSC-B.
処理の異常終了は、3G-MSC-B内の全リソースのクリアをトリガする。
3GPP
Release 1999
63
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Prepare Subsequent Handover and RELOCATION REQUIRED is as follows:
Prepare Subsequent HandoverとRELOCATION REQUIRED間のインターワーキングについて以下に示す：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward |REL. REQUIRED
MAP PREPARE SUBSEQUENT HANDOVER|
message |
request
|
|
|
|
-target MSC number |
|
-targetCellId
|
|
-AN-APDU(
|
|
HANDOVER REQUEST) |
|
|
|
|
| RANAP information
BSSMAP information |
|
elements:
elements:
|
|
|
| MS Classmark 2
CM2
|
| Source Id
Cell Id (serving) |
| Target Id
Cell Id (target) |
| Cause
Cause
|1
| MS Classmark 3
CM3
|
|
|
|
info stored/generated |
|
in/by 3G-MSC-B:
|
|
Message Type
|
|
Channel Type
|
|
Speech version
|
|
Priority
|
|
Interference Band |
|
to be used
|
|
|
--------┼-------------------------------------------------┼----Positive|RELOCATION CMD.
MAP PREPARE SUBSEQUENT HANDOVER|
result |
response
| 2
|
-AN-APDU(
|
|
QUEUING INDICATION |
|
or HANDOVER REQUEST|
|
ACKNOWLEDGE or
|
|
HANDOVER FAILURE) |
|
|
| RANAP information
BSSMAP information |
|
elements:
elements:
|
| L3 information
L3 information
|
|
|
|
|
|
|
--------┼-------------------------------------------------┼----Negative| REL. PREP. FAILURE
MAP PREPARE SUBSEQUENT| 3
result |
HANDOVER response
|
| Relocation Failure in Target CN/RNC or Target System
Unknown MSC
|
| Relocation Failure in Target CN/RNC or Target System
Subsequent Handover
|
|
Failure |
| Relocation Failure in Target CN/RNC or Target System
|
|
UnexpectedDataValue
|
| Relocation Failure in Target CN/RNC or Target System
Data Missing
|
|
|
| Iu RELEASE COMMAND
|
|
|
| Relocation Cancelled MAP CLOSE
|
| Relocation Cancelled MAP U/P -ABORT
|
|
|
NOTE 1: The mapping of cause code values between BSSMAP and RANAP is FFS.
BSSMAPとRANAP間の理由コード値のマッピングについてはFFS。
3GPP
Release 1999
64
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 2: The response to the Prepare-Subsequent-Handover request can include in its AN-APDU parameter,
identifying the GSM 08.06 protocol, a BSSMAP QUEUING INDICATION, or a BSSMAP HANDOVER
REQUEST ACKNOWLEDGE or a BSSMAP HANDOVER FAILURE.
Prepare-Subsequent-Handover要求に対する応答をそのAN-APDUパラメータ中に含めて、GSM 08.06プ
ロトコルがBSSMAP QUEUING INDICATION、BSSMAP HANDOVER REQUEST
ACKNOWLEDGE、BSSMAP HANDOVER FAILUREのいずれかであるかを識別させることができ
る。
In the first case, 3G-MSC-B shall wait for the radio resources allocation response from MSC-A,
transmitted to 3G-MSC-B as described in subclause 4.5.4.
一番目のケースでは3G-MSC-Bは、4.5.4節で述べる手順でMSC-Bから3G-MSC-Aに送信される、無
線リソース割当応答を待つこと。
In the second case, the positive result triggers in 3GMSC-B the sending on Iu-Interface of the
RELOCATION COMMAND.
二番目のケースでは、処理が成功すると、3G-MSC-B内でIuインタフェース上のRELOCATION
COMMAND送信がトリガされる。
In the third case, the positive result triggers in 3G-MSC-B the sending of the RELOCATION
PREPARATION FAILURE.
三番目のケースでは、処理が成功すると、3G_MSC-BでRELOCATION PREPARATION FAILUREの
送信がトリガされる。
NOTE 3: The possible sending of the RELOCATION PREPARATION FAILURE message is described in 3GPP
TS 25.413.
RELOCATION PREPARATION FAILUREメッセージの送信の可能性については、3G 25.413中で説
明される。
The interworking between Send End Signal Result and HANDOVER COMPLETE in MSC-A is as follows:
MSC-A内での、Send End Signal ResultとHANDOVER COMPLETE間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER COMPLETE
MAP SEND END SIGNAL
|
message |
response
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT
| 1
|
|
NOTE:
The abortion of the dialogue ends the handover procedure with 3G-MSC-B.
ダイヤログの中断によって、3G-MSC-Bとのハンドオーバ処理が終了する。
3GPP
Release 1999
65
3GPP TS 29.010 V3.10.0 (2002-12)
4.6.3 Subsequent Inter-MSC Handover to third MSC
（第3のMSCに対する後続MSC間ハンドオーバ）
When a Mobile Station is being handed over to a third MSC, the procedure (described in 3GPP TS 23.009) does require
one specific interworking case in MSC-A between E-Interface from 3G-MSC-B and E-Interface from MSC-B' other
than the combination of the ones described in subclauses 4.6.1 and 4.6.2.
MSが第3のMSCにハンドオーバされた場合、（TS 23.009中で説明される）処理は、4.6.1節および4.6.2節中に説明さ
れたケースの組合せを除いて、MSC-A内で3G-MSC-BからのEインタフェースと、MSC-B'からのEインタフェース間で
ある特別なインターワーキングのケースを必要とする。
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|RELOCATION |
|
|
|----------->|MAP PREPARE SUBSEQUENT|
|
|REQUIRED
|--------------------->|
|
|
|HANDOVER request
|MAP PREPARE
|
|
|
|--------------->|
|
|
|HANDOVER request|
|
|
|
|+-------+
|
|
|
||Possib.|
|
|
|
||Alloc. |
|
|
|
||of ho. |
|
|
|
||number |
|
|
|
|| VLR-B |
|
|
|
|+-------+
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|-------->|
|
|
|
|REQUEST |
|
|
|
|
Figure 32: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') initiation
図32：第3のMSC(MSC-B') に対する後続MSC間ハンドオーバ開始のシグナリング
Possible Positive outcomes:
想定される処理の成功：
a)
successful radio resources allocation:
無線リソース割当に成功：
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|REQUEST |
|
|
|
ACKNOWLEDGE
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT|
response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| RELOCATION |
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
|
|
|
|
|
3GPP
Release 1999
66
3GPP TS 29.010 V3.10.0 (2002-12)
b) radio resources allocation queued and successful handover number allocation, if performed. Later successful
radio resources allocation indication:
無線リソース割当がキューイングされ、もし実行されればハンドオーバ番号割当が成功。その後無線リソー
ス割当の成功が通知される：
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
| QUEUING |
|
|
|
|<--------|
|
|
|
|INDICAT. |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT|
response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|REQUEST |
|
|
|
ACKNOWLEDGE
|
|
|
|
|
|
|
|MAP PROCESS ACCESS
|
|
|
|<---------------|
|
|
|MAP FORWARD ACCESS
|SIGNALLING request
|
|
|<---------------------|
|
|
|
|SIGNALLING request
|
|
|
| RELOCATION |
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
Figure 33: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') execution
(Positive outcome)
図33：第3のMSC(MSC-B') に対する後続MSC間ハンドオーバ実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
c)
user error detected, or component rejection or dialogue abortion performed by MSC-B':
ユーザエラーの検出、またはMSC-Bがコンポーネント拒否、またはダイヤログ中断を実行：
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|MAP PREPARE HANDOVER
|
|
|
|response negative result |
|
|
|MAP CLOSE
|
|
|
|
|<---------------|
|
|
|
|MAP U/P -ABORT |
|
|
|MAP PREPARE SUBSEQUENT|
|
|
|
|<---------------------|
|
|
|
|HANDOVER response negative
|
|
| RELOCATION |result
|
|
|
|<-----------|
|
|
|
| PREPARATION|
|
|
|
| FAILURE
|
|
|
|
| (Note 1)
|
|
|
|
3GPP
Release 1999
67
3GPP TS 29.010 V3.10.0 (2002-12)
d) radio resources allocation failure:
無線リソース割当の失敗：
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|FAILURE |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT| response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| RELOCATION |
|
|
|
|<-----------|
|
|
|
| PREPARATION|
|
|
|
| FAILURE
|
|
|
|
| (Note 1)
|
|
|
|
e)
radio resources allocation queued and successful handover number allocation (if performed). Later unsuccessful
radio resources allocation:
無線リソース割当がキューイングされ、（もし実行されれば）ハンドオーバ番号割当が成功。その後無線リソ
ース割当が失敗：
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
| QUEUING |
|
|
|
|<--------|
|
|
|
|INDICAT. |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT| response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|FAILURE |
|
|
|
|
|
|
|
|MAP PROCESS ACCESS
|
|
|
|<---------------|
|
|
|
|SIGNALLING request
|
|
|MAP FORWARD ACCESS
|
|
|
|
|<---------------------|
|
|
|
|SIGNALLING request
|
|
|
| RELOCATION |
|
|
|
|<-----------|
|
|
|
| PREPARATION|
|
|
|
| FAILURE
|
|
|
|
| (Note 1)
|
|
|
|
Figure 34: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') execution (Negative
outcome)
図34：第3のMSC(MSC-B') への後続MSC間ハンドオーバ実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or BSSMAP procedure.
MAPまたはRANAP処理が失敗したためにハンドオーバが拒否された場合などが想定される。
3GPP
Release 1999
68
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome:
処理の成功：
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|
|
|
|
BSS-B'
|
|
|
|
|
|
|
|
|HANDOVER |
|
|
|
|<--------|
|
|
|
|COMPLETE |
|
|
|
|
|
|
|
|MAP SEND END SIGNAL
|
|
|
|<---------------|
|
|
| MAP SEND END SIGNAL |
|
|
|
|<---------------------|
|
|
|
| response
|
|
|
| IU-RELEASE |
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
Figure 35: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') completion
(Successful completion of the procedure)
図35：第3のMSC(MSC-B') への後続MSC間ハンドオーバ完了のシグナリング（処理の成功による完了）
Negative outcome:
処理の失敗：
RNS-A
3G-MSC-B
MSC-A
MSC-B'
|
|
|
|
|RELOCATION |
|
|
BSS-B'
|----------->|
|
|
|
|CANCEL
|MAP PROCESS ACCESS
|
|
|
|
|--------------------->|
|
|
|
|SIGNALLING request (Note 1)
|
|
|
|
|
|
|
|
|
|MAP U -ABORT
|
|
|
|
|--------------->|
|
|
|
|
|CLEAR
|
|
|
|
|-------->|
|
|
|
|COMMAND |
|RELOCATION |
|
|
|
|<-----------|
|
|
|
|CANCEL ACK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 36: Signalling for Subsequent Inter-MSC Handover to third MSC (MSC-B') completion
(Unsuccessful completion of the procedure)
図36：第3のMSC(MSC-B') への後続MSC間ハンドオーバ完了のシグナリング（処理の失敗による完了）
NOTE 1: Specific interworking case detailed below.
特別なインターワーキングのケースについて、以下に詳述する。
3GPP
Release 1999
69
3GPP TS 29.010 V3.10.0 (2002-12)
The specific interworking case in MSC-A compared to the subclauses 4.5.1 and 4.5.2 occurs between HANDOVER
FAILURE encapsulated in a Process Access Signalling from 3G-MSC-B and the abortion of the dialogue with MSC-B'
in the case of a reversion to old channel of the MS:
MSが旧チャネルへ復帰する場合、 4.5.1節および4.5.2節中に説明されたケースとは異なり、3G-MSC-Bからの
Process Access Signalling中にカプセル化されたHANDOVER FAILUREと、MSC-B'とのダイヤログの中断の間に、
MSC-A内で特別なインターワーキングが起きるケースがある。
---------------------------------------------------------------|
29.002
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PROCESS-SIGNALLING
|
message |
request
|
|
|
|
-AN-APDU(
MAP U -ABORT
| 1
|
HANDOVER FAILURE)
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT | 2
|
|
NOTE 1: The abortion of the dialogue triggers in MSC-B' the clearing of the circuit connection with MSC-A, if
any, and of the Resources between MSC-B' and BSS-B'.The abortion of the dialogue ends the handover
procedure with MSC-B'.
ダイヤログの中断はMSC-B' 内で、MSC-Aとの回線交換コネクションが存在する場合にはそのクリア
と、MSC-B' とBSS-B'間のリソースのクリアをトリガする。ダイヤログの中断によって、MSC-B'とのハン
ドオーバ処理は中断する。
NOTE 2: The abortion of the dialogue ends the handover procedure with 3G-MSC-B.
ダイヤログの中断により、3G-MSC-Bとのハンドオーバ処理は終了する。
4.6.4 BSSAP Messages transfer on E-Interface
（Eインタフェース上でのBSSAPメッセージの送信）
The handling is described in chapter 4.5.4.
処理については4.5.4節で説明。
4.6.5 Processing in MSC-B, and information transfer on E-interface
（MSC-B内の処理と、Eインタフェース上での情報の送信）
The handling is described in chapter 4.5.5.
処理については4.5.5節で説明。
4.6.6 Cause Code Mapping（理由コードのマッピング）
When a Mobile Station is handed over between UMTS and GSM, a mapping of the cause codes used in the RANAP
and the BSSMAP protocols is needed. The mapping described here is applicable to the BSSMAP protocol even when
used inside MAP in the E-interface.
MSがUMTSとGSM間でハンドオーバされる場合、RANAPプロトコルで使用される理由コードとBSSMAPプロトコルで
使用される理由コード間のマッピングが必要となる。ここで説明するマッピングは、Eインタフェース上でMAP内部で
使用される場合でも、BSSMAPプロトコルに対して適用可能である。
3GPP
Release 1999
70
3GPP TS 29.010 V3.10.0 (2002-12)
The mapping between the cause codes received in RANAP Relocation Required and the cause codes sent in BSSMAP
Handover Request is as follows:
RANAP Relocation Required 中で受信する理由コードと、BSSMAP Handover Request中で送信する理由コード間の
マッピングについて以下に述べる：
---------------------------------------------------------------25.413
08.08
|Notes
-------------------------------------------------------┼-------RELOCATION REQUIRED
HANDOVER REQUEST
|
|
-Time critical relocation
-Better cell
|
-Resource optimisation
| 1
relocation
|
-Relocation desirable for
-Better cell
|
radio reasons
|
-Directed retry
-Directed retry
|
-Any other value
-Better cell
|
NOTE 1: Cause code not used at inter-system handover.
システム間ハンドオーバの場合、理由コードは使用されない。
The mapping between the cause codes received in RANAP Relocation Cancel and the cause codes sent in BSSMAP
Clear Command is as follows:
RANAP Relocation Cancel中で受信する理由コードと、BSSMAP Clear Command中で送信する理由コード間のマッピ
ングについて以下に述べる：
---------------------------------------------------------------25.413
08.08
|Notes
-------------------------------------------------------┼-------RELOCATION CANCEL
CLEAR COMMAND
|
|
-Trelocprepexpiry
-Radio interface
|
failure, reversion to |
old channel
|
-Interaction with other
-Radio interface
|
procedure
failure, reversion to |
old channel
|
-Any other value
-Radio interface
|
failure, reversion to |
old channel
|
3GPP
Release 1999
71
3GPP TS 29.010 V3.10.0 (2002-12)
The mapping between the cause codes received in BSSMAP Handover Failure and the cause codes sent in RANAP
Relocation Preparation Failure is as follows:
BSSMAP Handover Failure中で受信する理由コードと、RANAP Relocation Preparation Failure中で送信する理由コ
ード間のマッピングについて、以下に述べる：
---------------------------------------------------------------08.08
25.413
|Notes
-------------------------------------------------------┼-------HANDOVER FAILURE
RELOCATION PREP. FAILURE|
|
-Ciphering algorithm not
-Requested ciphering
|
supported
and/or integrity
|
protection is not
|
supported
|
-Circuit pool mismatch
| 1
-Equipment failure
-Relocation failure in |
Target CN/RNC or
|
target system
|
-Invalid message contents
- Abstract Syntax Error|
-No radio resource available
-Relocation failure in |
Target CN/RNC or
|
target system
|
-O and M intervention
-O and M intervention |
-Radio interface failure,
| 2
reversion to old channel
|
-Radio interface message
-Relocation failure in |
failure
Target CN/RNC or
|
target system
|
-Requested speech version
-Relocation failure in |
unavailable
Target CN/RNC or
|
target system
|
-Requested terrestrial
-Relocation failure in |
resource unavailable
Target CN/RNC or
|
target system
|
-Requested transcoding/rate
-Relocation failure in |
adaption unavailable
Target CN/RNC or
|
target system
|
-Switch circuit pool
|
1
-Terrestrial circuit already
-Relocation failure in |
allocated
Target CN/RNC or
|
target system
|
-Any other value
-Relocation failure in |
Target CN/RNC or
|
target system
|
NOTE 1: Cause code not used at inter-system handover.
システム間ハンドオーバの場合、理由コードは使用されない。
NOTE 2: Cause code not applicable to this traffic case.
このトラフィックのケースについては、理由コードは適用できない。
4.7
Inter-MSC Handover (GSM to UMTS)
（MSC間ハンドオーバ（GSMからUMTSへ））
The general principles of the handover procedures are given in 3GPP TS 23.009. 3GPP TS 29.010 gives the necessary
information for interworking between the 3GPP TS 25.413 RANAP protocol, GSM handover procedures and the 3GPP
TS 29.002 MAP protocol. The RANAP protocol is used between the RNS and the 3G_MSC.
ハンドオーバ処理の原則については、3GPP TS 23.009で与えられる。3GPP TS 29.010では、3GPP TS 25.413の
RANAPプロトコル、GSMのハンドオーバ処理、そして3GPP TS 29.002のMAPプロトコル間のインターワーキングに
必要な情報を与える。RANAPプロトコルは、RNSと3G_MSC間で使用される。
The following four principles apply for the Inter-MSC handover GSM to UMTS:
GSMからUMTSへのMSC間ハンドオーバに関しては、次の4つの原則が適用される：
3GPP
Release 1999
72
3GPP TS 29.010 V3.10.0 (2002-12)
The BSSMAP parameters required for Inter-MSC handover GSM to UMTS are generated as in GSM.
GSMからUMTSへのMSC間ハンドオーバに必要なBSSMAPパラメータは、GSM側で生成されること。
Received RANAP parameters, e.g. cause code or transparent container, are mapped to the appropriate BSSMAP
parameters, e.g. cause code or Handover command.
理由コードまたは透過型コンテナなど、受信したRANAPパラメータは、理由コードやHandoverコマンドなどの適切な
BSSMAPパラメータにマッピングされること。
The RANAP parameters required for Inter-MSC handover GSM to UMTS are generated from received or stored GSM
parameters.
GSMからUMTSへのMSC間ハンドオーバに必要なRANAPパラメータは、受信した、あるいは保存されているGSM
パラメータから生成されること。
4.7.1
Basic Inter-MSC Handover（基本的MSC間ハンドオーバ）
When a Mobile Station is handed over between two MSCs, the establishment of a connection between them (described
in 3GPP TS 23.009) requires interworking between A-Interface, Iu-Interface and E-Interface.
MSが2つのMSC間でハンドオーバされる場合、（3GPP TS 23.009に説明されるように）両者の間でコネクションを確立
するために、Aインタフェース、Iuインタフェース、そしてEインタフェース間のインターワーキングが要求される。
The signalling at initiation, execution and completion of the Basic Inter-MSC handover procedure is shown in figures
37 to 42 with both possible positive or negative outcomes.
基本的MSC間ハンドオーバ処理の開始、実行、完了のシグナリングを、処理が成功した場合と失敗した場合のそれ
ぞれについて、図37から図42に示す。
Additionally figure 37b shows the possible interworking when the trace related message is transparently transferred on
the E-Interface at Basic Inter-MSC Handover initiation.
さらに図37bに、基本的MSC間ハンドオーバ開始時に、Eインタフェース上でトレース関連メッセージを透過的に送信
する場合に想定されるインターワーキングを示す。
BSS-A
MSC-A
3G-MSC-B
|
|
|
|HANDOVER
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request
| |Possible Alloc. |
|
|
| |of a handover
|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|------------------>|
Figure 37a: Signalling for Basic Inter-MSC Handover initiation (no trace related messages
transferred)
図37a：基本的MSC間ハンドオーバ開始のシグナリング（トレース関連メッセージが送信されない場合）
3GPP
Release 1999
73
3GPP TS 29.010 V3.10.0 (2002-12)
BSS-A
MSC-A
3G-MSC-B
|
(*)
|
|HANDOVER
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request (**)
| |Possible Alloc. |
|
|
| |of a handover
|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|------------------>|
|
|
|
|
|
|
|CN INVOKE TRACE
|
|
|
|--------------->(***)
Figure 37b: Signalling for Basic Inter-MSC Handover initiation (CN invoke trace message transferred)
図37b：基本的MSC間ハンドオーバ開始のシグナリング（CN invoke traceメッセージが送信される場合）
(*):
Tracing invocation has been received from VLR.
トレースの起動はVLRから既に受信している。
(**):
In that case, HANDOVER REQUEST and MSC INVOKE TRACE messages are included within the
AN-apdu parameter.
このケースでは、AN-apduパラメータ中にHANDOVER REQUESTおよびHANDOVER REQUESTメッ
セージが含まれる。
(***):
CN INVOKE TRACE is forwarded to RNS-B if supported by 3G_MSC-B.
3G_MSC-Bがサポートする場合、CN INVOKE TRACEはRNS-Bに転送される。
Possible Positive outcomes: successful radio resources allocation and handover number allocation (if performed):
想定される処理の成功：無線リソース割当とハンドオーバ番号割当（実行される場合）に成功した場合
BSS-A
MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
|
|LOCATION REPORTING |
|
|
|------------------>|
|
|
|CONTROL
|
|
| MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|HANDOVER COMMAND
|
|
|<--------------|
|
|
Figure 38: Signalling for Basic Inter-MSC Handover execution (Positive outcome)
図38：基本的MSC間ハンドオーバ実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
a)
user error detected, or handover number allocation unsuccessful (if performed), or component rejection or
dialogue abortion performed by 3G_MSC-B:
ユーザエラーの検出、またはハンドオーバ番号割当（もし実行されれば）に失敗、または3G_MSC-Bがコンポ
ーネントを拒否、またはダイヤログの中断を実行：
BSS-A
|
MSC-A
|
3G-MSC-B
|
3GPP
RNS-B
|
Release 1999
74
|
|MAP PREPARE HANDOVER response
|
|negative result, MAP CLOSE
|
|<------------------------|
|
|MAP U/P-ABORT
|
|
|
|
|HANDOVER REQUIRED
|
|<--------------|
|
|REJECT (Note 1)|
|
|
|
|
3GPP TS 29.010 V3.10.0 (2002-12)
|
|
|
|
|
|
|
|
|
b) radio resources allocation failure:
無線リソース割当の失敗：
BSS-A
MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|
|
|RELOCATION FAILURE |
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|HANDOVER REQUIRED
|
|
|<--------------|
|
|
|REJECT (Note 1)|
|
|
|
|
|
|
c)
unsuccessful handover execution (Reversion to the old radio resources):
ハンドオーバ実行の失敗（旧無線リソースへの復帰）
BSS-A
MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|HANDOVER
|
|
|
|-------------->|
|
|
|FAILURE
|
|
|
|
|MAP U -ABORT
|
|
|
|------------------------>|
|
|
|
|IU RELEASE COMMAND |
|
|
|------------------>|
Figure 39: Signalling for Basic Inter-MSC Handover execution (Negative outcomes)
図39：基本的MSC間ハンドオーバ実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or RANAP procedure.
MAPまたはRANAP処理が失敗したためにハンドオーバが拒否された場合などが想定される。
BSS-A
MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|
|
|RELOCATION COMPLETE|
|
|
|<------------------|
|
|MAP SEND END SIGNAL request
|
|
|<------------------------|
|
|CLEAR COMMAND |
|
|
|<--------------|
|
|
|
|
|
|
Figure 40: Signalling for Basic Inter-MSC Handover completion
図40：基本的MSC間ハンドオーバ完了のシグナリング
3GPP
Release 1999
75
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome:
処理の成功：
BSS-A
|
|
|
|
|
|
MSC-A
3G-MSC-B
RNS-B
|
|
|
|MAP SEND END SIGNAL
|
|
|------------------------>|
|
| response
|IU RELEASE COMMAND |
|
|------------------>|
|
| (Note 2)
|
Figure 41: Signalling for Basic Inter-MSC Handover completion (Positive outcome)
図41：基本的MSC間ハンドオーバ完了のシグナリング（処理の成功）
Negative outcome:
処理の失敗：
BSS-A
|
|
|
|
|
|
MSC-A
3G-MSC-B
RNS-B
|
|
|
| MAP U/P -ABORT
|
|
|------------------------>|
|
|
|IU RELEASE COMMAND |
|
|------------------>|
|
|
|
Figure 42: Signalling for Basic Inter-MSC Handover completion (Negative outcome)
図42：基本的MSC間ハンドオーバ完了のシグナリング（処理の失敗）
NOTE 2: From interworking between MAP and RANAP point of view, when the call is released.
MAPとBSSMAP間のインターワーキングという観点から見ると、呼が開放されたとき。
BSS-A
|
|
|
|
|
|
MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|LOCATION REPORT
|
|
|<------------------|
|MAP PROCESS ACCESS
|
|
|<------------------------|
|
|SIGNALLING
|
|
Figure 42a: Signalling for updating of anchor MSC after change of location in RNS
図42a：RNS内ロケーション変更後のanchor MSC更新のシグナリング
The handover procedure is normally triggered by BSS-A by sending a HANDOVER REQUIRED message on
A-Interface to MSC-A. The invocation of the Basic Inter-MSC handover procedure is performed and controlled by
MSC-A. The sending of the MAP Prepare-Handover request to 3G_MSC-B is triggered in MSC-A upon receipt of the
HANDOVER REQUIRED message. The identity of the target RNC where the call is to be handed over in 3G_MSC-B
area, provided in the HANDOVER REQUIRED message in the information element Cell Identifier List (Preferred), is
mapped to the target RNC Id MAP parameter and the HANDOVER REQUEST message is encapsulated in the anAPDU MAP parameter of the Prepare-Handover MAP request. 3G_MSC-B can invoke another operation towards the
VLR-B (allocation of the handover number described in 3GPP TS 29.002).
ハンドオーバ処理は通常、BSS-AがAインタフェース上でMSC-Aに対してHANDOVER REQUIREDメッセージを送
信することによってトリガされる。基本的MSC間ハンドオーバ処理の起動は、MSC-Aによって実行・制御される。
HANDOVER REQUIREDメッセージを受信するとMSC-A内で、3G_MSC-BへのMAP Prepare-Handover要求の送信
がトリガされる。MSC-Bのエリア内の呼のハンドオーバ先のtarget RNCのIDは、IE Cell Identifier List (Preferred)中
のHANDOVER REQUIREDメッセージ中で提供されるが、target RNC Id MAPパラメータ中にマッピングされ、
HANDOVER REQUESTメッセージはPrepare-Handover MAP要求のan-APDU MAPパラメータ中にカプセル化され
る。3G_MSC-Bはそれ以外のオペレーションを、VLR-Bに対して起動することができる（ハンドオーバ番号の割当に
ついては、3GPP TS 29.002中で説明される）。
3GPP
Release 1999
76
3GPP TS 29.010 V3.10.0 (2002-12)
Additionally, if tracing activity has been invoked, the trace related message can be transferred on the E-Interface
encapsulated in the an-APDU MAP parameter of the Prepare-Handover Request. If transferred, one complete trace
related message at a time shall be included in the an-APDU MAP parameter after the HANDOVER REQUEST
message. Note: UMTS supports only CN initiated tracing.
さらに、トレースアクティビティが既に起動されている場合には、トレース関連メッセージをPrepare-Handover Request
のan-APDU MAPパラメータ中にカプセル化してEインタフェース上で送信することもできる。トレース関連メッセージを
送信する場合には、HANDOVER REQUESTメッセージの後に、一連の完全なトレース関連のメッセージを同じanAPDU MAPパラメータ中に含めること。注：UMTSはCNが起動した呼のトレースだけをサポートする。
The interworking between Prepare Handover and HANDOVER REQUIRED is as follows:
Prepare HandoverとHANDOVER REQUIRED間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER REQUIRED
MAP PREPARE HANDOVER request|
message |
|
|
-ho-NumberNotRequired| 1
| BSSMAP information
-target RNC Id
|
|
elements
-IMSI
|
|
-Integrity protection|
2
|
info
|
|
-Encryption info
|
|
-an-APDU(
| 3
|
HANDOVER REQUEST,
|
|
MSC INVOKE TRACE)
| 4
--------┼-------------------------------------------------┼----Positive|
MAP PREPARE HANDOVER response|
result |
| 5
|
-handover number
|
|
-an-APDU(
|
|
HANDOVER REQUEST
|
|
ACKNOWLEDGE or
|
|
HANDOVER FAILURE) |
--------┼-------------------------------------------------┼----Negative| HANDOVER REQUIRED REJECT
MAP PREPARE HANDOVER| 6
result |
|
| equipment failure
System Failure
|
| equipment failure
No Handover Number |
|
available
|
| equipment failure
UnexpectedDataValue|
| equipment failure
Data Missing
|
|
|
| equipment failure
MAP CLOSE
|
| equipment failure
MAP U/P -ABORT
|
|
|
NOTE 1: The ho-NumberNotRequired parameter is included by MSC-A, when MSC-A decides not to use any
circuit connection with 3G_MSC-B. No handover number shall be present in the positive result. Any
negative response from 3G_MSC-B shall not be due to handover number allocation problem.
MSC-Aが3G_MSC-Bと回線交換コネクションを使用しないことを決めた場合には、MSC-AはhoNumberNotRequired パラメータを含める。ポジティブな結果には、ハンドオーバ番号が含まれてはなら
ない。3G_MSC-Bからのネガティブな応答は全て、ハンドオーバ番号割当問題に起因するものであって
はならない。
NOTE 2: Integrity protection information, encryption information and IMSI parameters are included by MSC-A,
only when the MSC-A uses 29.002 as per release 99. These IEs are not included if the MSC-A is R98 or
earlier.
R99によってMSC-Aが29.002を使用する場合のみ、MSC-Aは完全性保護情報、暗号化情報、そして
IMSIパラメータを含める。これらのIEは、R98またはそれ以前のMSC-Aの場合には含まれない。
NOTE 3: The process performed on the BSSMAP information elements received in the HANDOVER REQUIRED
message is described in the GSM Recommendation 08.08.
HANDOVER REQUIRED メッセージ中で受信したBSSMAPのIE上で実行される処理については、
GSM Recommendation 08.08で説明される。
3GPP
Release 1999
77
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 4: The process performed on the BSSMAP information elements received in the MSC INVOKE TRACE
message is described in subclause 4.5.5.6.
MSC INVOKE TRACE メッセージ中で受信したBSSMAPのIE上で実行される処理については、
4.5.5.6節で説明される。
NOTE 5: The response to the Prepare-Handover request can include in its an-APDU parameter, identifying the
GSM 08.06 protocol, either a BSSMAP HANDOVER REQUEST ACKNOWLEDGE or a BSSMAP
HANDOVER FAILURE.
Prepare-Handover要求に対する応答をそのan-APDUパラメータ中に入れて、GSM 08.06プロトコルが
BSSMAP HANDOVER REQUEST ACKNOWLEDGE、またはBSSMAP HANDOVER FAILUREのい
ずれかであることを識別することもできる。
In the first case, the positive result triggers in MSC-A the sending on A-Interface of the HANDOVER
COMMAND.
一番目のケースでは処理が成功すると、MSC-A内でHANDOVER COMMANDのAインタフェース上
での送信がトリガされる。
In the second case, the positive result triggers in MSC-A optionally the sending of the HANDOVER
REQUIRED REJECT.
二番目のケースでは処理が成功すると、MSC-A内でオプションとしてHANDOVER REQUIRED
REJECTの送信がトリガされる。
(The possible sending of the HANDOVER REQUIRED REJECT message upon receipt of the
HANDOVER FAILURE is out of the scope of 3GPP TS 29.010 and lies in 3GPP TS 48.008).
（HANDOVER FAILUREの受信によるHANDOVER REQUIRED REJECTメッセージ送信の可能性に
ついては3GPP TS 29.010のスコープ外であり、3GPP TS 48.008に記載される）
NOTE 6: The possible sending of the HANDOVER REQUIRED REJECT message is described in 3GPP TS
48.008.
HANDOVER REQUIRED REJECTメッセージ送信の可能性については、3GPP TS 48.008中で説明さ
れる。
3GPP
Release 1999
78
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Prepare Handover and RELOCATION REQUEST in 3G_MSC-B is as follows:
3G_MSC-B内でのPrepare HandoverとRELOCATION REQUEST間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PREPARE HANDOVER
RELOCATION REQUEST
|
message | request
|
| -ho-NumberNotRequired
|
| -target RNC Id
|
| -IMSI
|
| -Integrity protection info
| 1
| -Encryption info
|
| -RANAP service handover
|
| -an-APDU(
|
| HANDOVER REQUEST,
|
| MSC INVOKE TRACE)
|
|
|
| BSSMAP information
RANAP information
|
|
elements:
elements:
|
|
|
|
Channel Type
RAB parameters
|
|
Cause
Cause
|
|
sRNC to tRNC container sRNC to tRNC container|
|
|
|
info stored/generated
|
|
in/by 3G_MSC-B:
|
|
CN domain indicator
|
|
|
--------┼-------------------------------------------------┼----Positive| MAP PREPARE HANDOVER
RELOCATION REQUEST ACK |
result | response
|
| -an-APDU(
|
| HANDOVER REQUEST ACK)
|
|
|
| BSSMAP information
RANAP information
|
|
elements:
elements:
|
|
|
|
Layer 3 info
tRNC to sRNC container|
|
|
--------┼-------------------------------------------------┼----Negative| MAP PREPARE HANDOVER
RELOCATION FAILURE
|
result | response
|
| -an-APDU(
|
| HANDOVER FAILURE)
|
|
|
NOTE 1: Integrity protection information, encryption information, IMSI and RANAP service handover parameters
are included by MSC-A, only when the MSC-A uses 29.002 as per release 99. These IEs are not included
if the MSC-A is R98 or earlier.
R99によってMSC-Aが29.002を使用する場合に限り、MSC-Aは完全性保護情報、暗号化情報、IMSIと
RANAPのサービスハンドオーバパラメータをめる。これらのIEは、R98またはそれ以前のMSC-Aの場
合には含まれない。
3GPP
Release 1999
79
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Send End Signal and RELOCATION COMPLETE in 3G_MSC-B is as follows:
3G_MSC-B内の、Send End SignalとRELOCATION COMPLETE間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION COMPLETE MAP SEND END SIGNAL request |
message |
|
|
-an-APDU(
|
|
HANDOVER COMPLETE)|
|
|
--------┼-------------------------------------------------┼----Positive| IU RELEASE COMMAND MAP SEND END SIGNAL response|
result | -Normal release
| 1
--------┼-------------------------------------------------┼----Negative| IU RELEASE COMMAND
|
result | -Normal release
MAP CLOSE
| 2
| -Normal release
MAP U/P -ABORT|
|
|
NOTE 1: The positive empty result triggers the clearing of the Radio Resources on the Iu-Interface and the release
of the SCCP connection between 3G_MSC-B and RNS-B. If a circuit connection is used between MSC-A
and 3G_MSC-B, the 'Normal release' clearing cause shall only be given to RNS-B when 3G_MSC-B has
received a clearing indication on its circuit connection with MSC-A.
ポジティブなエンプティな結果は、Iuインタフェース上での無線リソースのクリアと、3G_MSC-BとRNS-B
間のSCCPコネクションの開放をトリガする。MSC-Aと3G_MSC-B間で回線交換コネクションが使用され
る場合には、3G_MSC-BがMSC-Aとの回線交換コネクション上でクリア通知を受信したならば、RNS-B
に'Normal release' クリア理由だけを与えること。
NOTE 2: The abortion of the dialogue or the rejection of the component triggers in 3G_MSC-B the clearing of its
circuit connection with MSC-A, if any, of the Radio Resources on the Iu-Interface and the release of the
SCCP connection between 3G_MSC-B and RNS-B.
ダイヤログの中断またはコンポーネントの拒否が起きた場合、3G_MSC-B内でMSC-Aとの回線交換コ
ネクションの開放と、もしあればIuインタフェース上での無線リソースの開放と、3G_MSC-B とRNS-B
間のSCCPコネクションの開放がトリガされる。
The interworking between Send End Signal and CLEAR COMMAND in MSC-A is as follows:
MSC-A内の、Send End SignalとCLEAR COMMAND間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
29.002
08.08
|Notes
--------┼-------------------------------------------------┼----Forward | MAP SEND END SIGNAL
CLEAR COMMAND
|
message | request
|
|
-an-APDU(
- Handover
|
|
HANDOVER COMPLETE)
Successful
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
3GPP
Release 1999
80
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between HANDOVER FAILURE in case of reversion to old channel of the MS and User Abort in
MSC-A is as follows:
MSが旧チャネルへ復帰する場合のHANDOVER FAILUREと、MSC-A内のUser Abort間のインターワーキングにつ
いて、以下に示す。
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER FAILURE
MAP U -ABORT
|
message |
|
| - Reversion to old
|
|
channel
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
4.7.2
Subsequent Inter-MSC Handover from MSC-B back to 3G_MSC-A
（MSC-Bから3G_MSC-Aへの後続MSC間ハンドオーババック）
When a Mobile Station is being handed over back to 3G_MSC-A, the procedure (described in 3GPP TS 23.009)
requires interworking between A-Interface, Iu-Interface and E-Interface.
MSが3G_MSC-Aにハンドオーババックされた場合、（TS 23.009中で説明される）処理は、Aインタフェース、Iuインタ
フェース、そしてEインタフェース間のインターワーキングを必要とする。
The signalling at initiation, execution and completion of the Subsequent Inter-MSC handover procedure is shown in
figures 43 to 47.
後続MSC間ハンドオーバ処理の開始・実行・完了時のシグナリングについて、図43から図47に示す。
BSS-A
MSC-B
3G-MSC-A
|
|
|
|HANDOVER
|
|
|-------------->|MAP PREPARE SUBSEQUENT
|
|REQUIRED
|------------------------>|
|
|HANDOVER request
|
|
|
|
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|------------------>|
Figure 43: Signalling for Subsequent Inter-MSC Handover back to 3G_MSC-A initiation
図43：3G_MSC-Aへの後続MSC間ハンドオーババック開始のシグナリング
3GPP
Release 1999
81
3GPP TS 29.010 V3.10.0 (2002-12)
Possible Positive outcomes: successful radio resources allocation:
想定される処理の成功：無線リソース割当に成功
BSS-A
MSC-B
3G-MSC-A
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
| HANDOVER response
|
|
|HANDOVER COMMAND
|
|
|<--------------|
|
|
Figure 44: Signalling for Subsequent Inter-MSC Handover back to 3G_MSC-A execution (Positive
outcome)
図44：3G_MSC-Aへの後続MSC間ハンドオーババック実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
a)
user error detected, or component rejection or dialogue abortion performed by 3G_MSC-A:
ユーザエラーの検出、または3G_MSC-Aがコンポーネント拒否、またはダイヤログ中断を実行：
BSS-A
MSC-B
3G-MSC-A
|
|MAP PREPARE SUBSEQUENT HANDOVER
|
|<------------------------|
|HANDOVER REQUIRED response negative result
|<--------------|
|
|REJECT (Note 1)|
|
|
|
|
RNS-B
|
|
|
|
|
|
b) component rejection or dialogue abortion performed by 3G_MSC-A:
3G_MSC-Aがコンポーネント拒否、またはダイヤログ中断を実行：
BSS-A
MSC-B
3G-MSC-A
|
|MAP CLOSE, MAP U/P ABORT |
|
|<------------------------|
|CLEAR COMMAND |
|
|<--------------|
|
|
|
|
c)
RNS-B
|
|
|
|
|
radio resources allocation failure:
無線リソース割当の失敗：
BSS-A
MSC-B
3G-MSC-A
RNS-B
|
|
| RELOCATION FAILURE|
|
|
|<------------------|
|
|MAP PREPARE SUBSEQUENT
|
|
|
|<------------------------|
|
|HANDOVER REQUIRED
HANDOVER response
|
|
|<--------------|
|
|
|REJECT (Note 1)|
|
|
3GPP
Release 1999
82
3GPP TS 29.010 V3.10.0 (2002-12)
d) unsuccessful relocation execution (reversion to the old radio resources):
リロケーション実行の失敗（旧無線リソースへの復帰）：
BSS-A
MSC-B
3G-MSC-A
RNS-B
|HANDOVER
|
|
|
|-------------->|
|
|
|FAILURE
|MAP PROCESS ACCESS
|
|
|
|------------------------>|
|
|
|
SIGNALLING request
|IU RELEASE COMMAND |
|
|
|------------------>|
|
|
|
|
Figure 45: Signalling for Subsequent Inter-MSC Handover back to 3G_MSC-A execution
(Negative outcome)
図45：3G_MSC-Aへの後続MSC間ハンドオーババック実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or BSSMAP procedure.
MAPまたはBSSMAP処理が失敗したためにハンドオーバが拒否された場合などが想定される。
RNS-B
3G-MSC-A
MSC-B
BSS-A
|
|
|
|
|RELOCATION
|
|
|
|-------------->|MAP SEND END SIGNAL
|
|
|COMPLETE
|------------------------>|
|
|
| response
|
|
|
|
|CLEAR COMMAND
|
|
|
|------------------>|
Figure 46: Signalling for Subsequent Inter-MSC Handover back to 3G_MSC-A completion
(Successful completion of the procedure)
図46：3G_MSC-Aへの後続MSC間ハンドオーババック完了のシグナリング（処理の成功による完了）
NOTE:
Positive outcome case shown in figure 41.
処理が成功したケースは図41に示す。
RNS-B
|
|
|
|
|
|
3G-MSC-A
MSC-B
BSS-A
|
|
|
|MAP U/P -ABORT
|
|
|<------------------------|
|
|
|CLEAR COMMAND
|
|
|------------------>|
|
|(Note 1)
|
Figure 47: Signalling for Subsequent Inter-MSC Handover back to 3G_MSC-A completion
(Unsuccessful completion of the procedure)
図47：3G_MSC-Aへの後続MSC間ハンドオーババック完了のシグナリング（処理の失敗による完了）
NOTE 1: Abnormal end of the procedure that triggers the clearing of all resources in MSC-B.
処理の異常終了は、MSC-B内の全リソースのクリアをトリガする。
3GPP
Release 1999
83
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Prepare Subsequent Handover and HANDOVER REQUIRED is as follows:
Prepare Subsequent Handover とHANDOVER REQUIRED 間のインターワーキングについて以下に示す：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward |HANDOVER REQUIRED MAP PREPARE SUBSEQUENT HANDOVER|
message |
request
| 1
|
|
|
-target MSC number |
| BSSMAP information
-target RNC Id
|
|
elements
-an-APDU(
|
|
HANDOVER REQUEST) |
--------┼-------------------------------------------------┼----Positive|HANDOVER REQUIRED MAP PREPARE SUBSEQUENT HANDOVER|
result |
response
| 2
|
-an-APDU(
|
|
HANDOVER REQUEST
|
|
ACKNOWLEDGE or
|
|
HANDOVER FAILURE) |
--------┼-------------------------------------------------┼----Negative| HANDOVER REQUIRED REJECT MAP PREPARE SUBSEQUENT| 3
result |
HANDOVER response
|
| equipment failure
Unknown MSC
|
| equipment failure
Subsequent Handover|
|
Failure |
| equipment failure
UnexpectedDataValue|
| equipment failure
Data Missing
|
|
|
| CLEAR COMMAND
|
|
|
| equipment failure
MAP CLOSE
|
| equipment failure
MAP U/P -ABORT
|
|
|
NOTE 1: The processing performed on the BSSMAP information elements received in the HANDOVER
REQUIRED message is out of the scope of the present document. The target MSC number is provided to
3G_MSC-A by MSC-B based on the information received from RNS-B.
HANDOVER REQUIREDメッセージ中で受信したBSSMAP IE上で実行されるプロセスについては、本
仕様書のスコープ外である。target MSC番号は、RNS-Bから受信した情報に基づいて、MSC-Bが
3G_MSC-Aに対して提供する。
NOTE 2: The response to the Prepare-Subsequent-Handover request can include in its an-APDU parameter,
identifying the GSM 08.06 protocol, either a BSSMAP HANDOVER REQUEST ACKNOWLEDGE or a
BSSMAP HANDOVER FAILURE.
Prepare-Subsequent-Handover request に対する応答をan-APDU パラメータ中に含めて、GSM 08.06プ
ロトコルがBSSMAP HANDOVER REQUEST ACKNOWLEDGE、またはBSSMAP HANDOVER
FAILUREのいずれかであるかを識別させることができる。
In the first case, the positive result triggers in MSC-B the sending on A-Interface of the HANDOVER
COMMAND.
一番目のケースでは、処理が成功すると、MSC-B内でAインタフェース上のHANDOVER COMMAND
送信がトリガされる。
In the second case, the positive result triggers in MSC-B optionally the sending of the HANDOVER
REQUIRED REJECT.
二番目のケースでは、処理が成功すると、オプションとしてMSC-B内でHANDOVER REQUIRED
REJECT送信がトリガされる。
(The possible sending of the HANDOVER REQUIRED REJECT message upon receipt of the
HANDOVER FAILURE is out of the scope of 3GPP TS 29.010 and lies in 3GPP TS 48.008).
（HANDOVER FAILUREの受信によるHANDOVER REQUIRED REJECTメッセージ送信の可能性に
ついては、3GPP TS 29.010のスコープ外であり、3GPP TS 48.008内に記載される）
3GPP
Release 1999
84
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 3: The possible sending of the HANDOVER REQUIRED REJECT message is described in 3GPP TS
48.008.
HANDOVER REQUIRED REJECTメッセージの送信の可能性については、3GPP TS 48.008で説明さ
れる。
The interworking between Prepare Subsequent Handover and RELOCATION REQUEST in 3G_MSC-A is as follows:
3G_MSC-A内での、Prepare Subsequent Handover とRELOCATION REQUEST間のインターワーキングについて、
以下に示す：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PREPARE SUB HANDOVER
RELOCATION REQUEST
|
message | request
|
| -ho-NumberNotRequired
|
| -target RNC ID
|
| -an-APDU(
|
| HANDOVER REQUEST,
|
| MSC INVOKE TRACE)
|
|
|
| BSSMAP information
RANAP information
|
|
elements:
elements:
|
|
|
|
Cause
Cause
|
|
sRNC to tRNC container sRNC to tRNC container|
|
|
|
info stored/generated
|
|
in/by 3G_MSC-A:
|
|
CN domain indicator
|
|
RAB parameters
|
|
Permanent NAS UE id
|
|
Encryption info
|
|
Integrity protection |
|
info
|
|
|
--------┼-------------------------------------------------┼----Positive| MAP PREPARE SUB HANDOVER RELOCATION REQUEST ACK|
result | response
|
| -an-APDU(
|
| HANDOVER REQUEST ACK)
|
|
|
| BSSMAP information
RANAP information
|
|
elements:
elements:
|
|
|
|
Layer 3 info
tRNC to sRNC container|
|
|
--------┼-------------------------------------------------┼----Negative| MAP SUB PREPARE HANDOVER RELOCATION FAILURE
|
result | response
|
| -an-APDU(
|
| HANDOVER FAILURE)
|
|
|
3GPP
Release 1999
85
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between HANDOVER FAILURE and MAP Process Signalling Request in 3G_MSC-B is as
follows:
3G_MSC-B内での、HANDOVER FAILUREとMAP Process Signalling Request間のインターワーキングは以下の通
り：
---------------------------------------------------------------|
08.08
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | HANDOVER FAILURE
MAP PROCESS-SIGNALLING |
message |
request
|
|
-an-APDU(
|
|
HANDOVER FAILURE)
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
|
|
The interworking between Send End Signal Response and RELOCATION COMPLETE in 3G_MSC-A is as follows:
3G_MSC-A内での、Send End Signal ResponseとRELOCATION COMPLETE間のインターワーキングは以下の通
り：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION COMPLETE MAP SEND END SIGNAL
|
message |
response
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT
| 1
|
|
NOTE 1: The abortion of the dialogue ends the handover procedure with MSC-B.
ダイヤログの中断によって、MSC-Bとのハンドオーバ処理が終了する。
3GPP
Release 1999
4.7.3
86
3GPP TS 29.010 V3.10.0 (2002-12)
Subsequent Inter-MSC Handover to third MSC
（第3のMSCに対する後続MSC間ハンドオーバ）
When a Mobile Station is being handed over to a third MSC, the procedure (described in 3GPP TS 23.009) does require
one specific interworking case in MSC-A (figure 49) between E-Interface from MSC-B and E-Interface from
3G_MSC-B' other than the combination of the ones described in the subclause 4.5.1 and 4.7.2.
MSが第3のMSCにハンドオーバされた場合、（TS 23.009中で説明される）処理は、4.5.1 節および4.7.2節中に説明さ
れたケースの組合せを除いて、MSC-A内で3G_MSC-B'からのEインタフェースと、MSC-BからのEインタフェース間で
ある特別なインターワーキングのケースを必要とする（図49）。
BSS-A
MSC-B
MSC-A
3G-MSC-B'
|
|
|
|
|HANDOVER
|
|
|
|----------->|MAP PREPARE SUBSEQUENT|
|
|REQUIRED
|--------------------->|
|
|
|HANDOVER request
|MAP PREPARE
|
|
|
|--------------->|
|
|
|HANDOVER request|
|
|
|
|+-------+
|
|
|
||Possib.|
|
|
|
||Alloc. |
|
|
|
||of ho. |
|
|
|
||number |
|
|
|
|| VLR-B |
|
|
|
|+-------+
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|-------->|
|
|
|
|REQUEST |
|
|
|
|
Figure 45: Signalling for Subsequent Inter-MSC Handover to third MSC (3G_MSC-B') initiation
図45：第3のMSC(3G_MSC-B') への後続MSC間ハンドオーバ開始のシグナリング
Possible Positive outcomes: successful radio resources allocation:
想定される処理の成功：無線リソース割当に成功：
BSS-A
MSC-B
MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|<--------|
|
|
|
|REQUEST |
|
|
|
ACKNOWLEDGE
|
|
|
|
|
|
|
|
|LOCATION |
|
|
|
|-------->|
|
|
|
|REPORTING|
|
|
|
|CONTROL |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT|
response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| HANDOVER
|
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
|
|
|
|
|
Figure 46: Signalling for Subsequent Inter-MSC Handover to third MSC (3G_MSC-B') execution
(Positive outcome)
図46：第3のMSC(3G_MSC-B') への後続MSC間ハンドオーバ実行のシグナリング（処理の成功）
3GPP
Release 1999
87
3GPP TS 29.010 V3.10.0 (2002-12)
Possible Negative outcomes:
想定される処理の失敗：
a)
user error detected, or component rejection or dialogue abortion performed by MSC-B':
ユーザエラーの検出、またはMSC-B'がコンポーネント拒否、またはダイヤログ中断を実行：
BSS-A
MSC-B
MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|MAP PREPARE HANDOVER
|
|
|
|response negative result |
|
|
|MAP CLOSE
|
|
|
|
|<---------------|
|
|
|
|MAP U/P -ABORT |
|
|
|MAP PREPARE SUBSEQUENT|
|
|
|
|<---------------------|
|
|
|
|HANDOVER response negative
|
|
| HANDOVER
|result
|
|
|
|<-----------|
|
|
|
| REQUIRED
|
|
|
|
| REJECT
|
|
|
|
| (Note 1)
|
|
|
|
b) radio resources allocation failure:
無線リソース割当の失敗：
BSS-A
MSC-B
MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|<--------|
|
|
|
|FAILURE |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT| response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| HANDOVER
|
|
|
|
|<-----------|
|
|
|
| REQUIRED
|
|
|
|
| REJECT
|
|
|
|
| (Note 1)
|
|
|
|
Figure 47: Signalling for Subsequent Inter-MSC Handover to third MSC (3G_MSC-B') execution
(Negative outcome)
図47：第3のMSC(3G_MSC-B') への後続MSC間ハンドオーバ実行のシグナリング（処理の失敗）
NOTE 1: Possible rejection of the handover because of the negative outcome of MAP or BSSMAP procedure.
MAPまたはRANAP処理が失敗したためにハンドオーバが拒否された場合などが想定される。
3GPP
Release 1999
88
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome:
処理の成功：
BSS-A
MSC-B
MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|<--------|
|
|
|
|COMPLETE |
|
|
|
|
|
|
|
|MAP SEND END SIGNAL
|
|
|
|<---------------|
|
|
| MAP SEND END SIGNAL |request
|
|
|
|<---------------------|
|
|
|
| response
|
|
|
| CLEAR
|
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
Figure 48: Signalling for Subsequent Inter-MSC Handover to third MSC (3G_MSC-B') completion
(Successful completion of the procedure)
図48：第3のMSC(3G_MSC-B') への後続MSC間ハンドオーバ完了のシグナリング（処理の成功による完了）
Negative outcome:
処理の失敗：
BSS-A
MSC-B
MSC-A
3G-MSC-B'
|
|
|
|
|HANDOVER
|
|
|
RNS-B'
|----------->|
|
|
|
|FAILURE
|MAP PROCESS ACCESS
|
|
|
|
|--------------------->|
|
|
|
|SIGNALLING request (Note 1)
|
|
|
|
|
|
|
|
|
|MAP U -ABORT
|
|
|
|
|--------------->|
|
|
|
|
|IU RELEASE
|
|
|
|-------->|
|
|
|
|COMMAND |
|
|
|
|
|
Figure 49: Signalling for Subsequent Inter-MSC Handover to third MSC (3G_MSC-B') completion
(Unsuccessful completion of the procedure)
図49：第3のMSC(3G_MSC-B') への後続MSC間ハンドオーバ完了のシグナリング（処理の失敗による完了）
NOTE:
Specific interworking case detailed below.
特別なインターワーキングのケースについて、以下に詳述する。
BSS-A
|
|
|
|
|
|
MSC-A
3G-MSC-B'
RNS-B'
|
|
|
|
|LOCATION REPORT
|
|
|<------------------|
|MAP PROCESS ACCESS
|
|
|<------------------------|
|
|SIGNALLING
|
|
Figure yy: Signalling for updating of anchor MSC after change of location in RNS
図yy：RNS内のロケーション変更後のanchor MSC更新のシグナリング
The specific interworking case in MSC-A compared to the subclauses 4.5.1 and 4.7.2 occurs between HANDOVER
FAILURE encapsulated in a Process Access Signalling from MSC-B and the abortion of the dialogue with 3G_MSC-B'
in the case of a reversion to old channel of the MS:
MSが旧チャネルへ復帰する場合、 4.5.1節および4.5.2節中に説明されたケースとは異なり、MSC-BからのProcess
3GPP
Release 1999
89
3GPP TS 29.010 V3.10.0 (2002-12)
Access Signalling中にカプセル化されたHANDOVER FAILUREと、3G_MSC-B'とのダイヤログの中断の間に、
MSC-A内で特別なインターワーキングが起きるケースがある。
---------------------------------------------------------------|
29.002
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PROCESS-SIGNALLING
|
message |
request
|
|
|
|
-an-APDU(
MAP U -ABORT
| 1
|
HANDOVER FAILURE)
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT | 2
|
|
NOTE 1: The abortion of the dialogue triggers in 3G_MSC-B' the clearing of the circuit connection with MSC-A, if
any, and of the Resources between 3G_MSC-B' and RNS-B'. The abortion of the dialogue ends the
handover procedure with 3G_MSC-B'.
ダイヤログの中断は3G_MSC-B' 内で、MSC-Aとの回線交換コネクションが存在する場合にはそのク
リアと、3G_MSC-B' とRNS-B'間のリソースのクリアをトリガする。ダイヤログの中断によって、
3G_MSC-B'とのハンドオーバ処理は中断する。
NOTE 2: The abortion of the dialogue ends the handover procedure with MSC-B.
ダイヤログの中断により、MSC-Bとのハンドオーバ処理は終了する。
4.7.4
BSSAP Messages transfer on E-Interface
（Eインタフェース上でのBSSAPメッセージの送信）
The handling is described in chapter 4.5.4, additional cases are described in this chapter.
処理については4.5.4節で説明したので、追加的なケースについて以下の節で説明する。
3GPP
Release 1999
4.7.4.1
90
3GPP TS 29.010 V3.10.0 (2002-12)
Assignment（割当て）
The interworking between the BSSMAP assignment messages in MAP and the RANAP RAB assignment messages is
as follows:
MAP内の、BSSMAP assignmentメッセージとRANAP RAB assignmentメッセージ間のインターワーキングは以下の
通り：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PREPARE HANDOVER
RAB ASSIGNMENT REQ|
message |
request
|
|
-RANAP service
Service handover |
|
handover
|
|
-an-APDU(
|
|
ASSIGNMENT REQUEST)
|
|
|
| BSSMAP information
RANAP information |
|
elements:
elements:
|
|
|
| Channel Type
RAB parameters
|
|
|
--------┼-------------------------------------------------┼----Positive| MAP PREPARE HANDOVER
|
result |
request
|
|
-an-APDU(
|
|
ASSIGNMENT COMPLETE
RAB ASSIGNMENT
|
|
RESPONSE
|
|
or
(positive result)|
|
ASSIGNMENT FAILURE)
RAB ASSIGNMENT
|
|
RESPONSE
|
|
(negative result)|
|
|
| BSSMAP information
RANAP information |
|
elements:
elements:
|
|
|
| Cause
Cause
| 1
|
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P –ABORT
|
|
|
3GPP
Release 1999
4.7.4.2
91
3GPP TS 29.010 V3.10.0 (2002-12)
Cipher Mode Control（暗号化モード制御）
The interworking between the BSSMAP cipher mode messages in MAP and the RANAP security mode messages is as
follows:
MAP内の、BSSMAP cipher modeメッセージとRANAP security modeメッセージ間のインターワーキングは以下の通
り：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP FORWARD ACCESS SIGN.
SECURITY MODE CMD |
message |
request
|
|
-an-APDU(
|
|
CIPHER MODE CMD)
|
|
|
| BSSMAP information
RANAP information |
|
elements:
elements:
|
|
|
| Encryption information
Integrity
|
|
protection info|
|
Encryption info
|
|
|
--------┼-------------------------------------------------┼----Positive| MAP PROCESS ACCESS SIGN.
|
result |
request
|
|
-an-APDU(
|
|
CIPHER MODE COMPLETE SECURITY MODE
|
|
or
COMPLETE
|
|
CIPHER MODE REJECT)
SECURITY MODE
|
|
REJECT
|
|
|
| BSSMAP information
RANAP information |
|
elements:
elements:
|
|
|
| Encryption information
Integrity
|
|
protection info|
|
Encryption info
|
| Cause
Cause
| 1
|
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P –ABORT
|
|
|
3GPP
Release 1999
4.7.4.3
92
3GPP TS 29.010 V3.10.0 (2002-12)
Location Reporting Control（ロケーションレポート制御）
The interworking between the RANAP location report message and the BSSMAP handover performed message in
MAP is as follows:
MAP内の、RANAP location reportメッセージとBSSMAP handover performedメッセージ間のインターワーキングは以
下のとおり：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | LOCATION REPORT
MAP PROC. ACC. SIGNALLING
|
message |
|
|
-an-APDU(
|
|
HANDOVER PERFORMED)|
|
|
| RANAP information
BSSMAP information |
|
elements:
elements:
|
|
|
| Area identity (SAI)
Cell identifier
|
| Cause
Cause
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
4.7.5
Processing in 3G_MSC-B, and information transfer on E-interface
（3G_MSC-B内の処理と、Eインタフェース上での情報の送信）
The following parameters require processing (e.g. to store the parameter, to internally generate the parameter) in
MSC-B. The relevant BSSMAP procedures are mentioned to ease the comprehension, their detailed description is the
scope of 3GPP TS 48.008. Each BSSMAP message listed in 3GPP TS 49.008 being transferred on E-interface shall use
the mechanisms given in subclause 4.5.4 and is described in 3GPP TS 48.008.
以下のパラメータは、（例えばパラメータを保存したり、あるいは内部でパラメータを生成するために）MSC-B内での
プロセスを必要とする。関連するBSSMAP処理の詳細な説明については、理解を容易にするために、3GPP TS
48.008のスコープとする。3GPP TS 49.008中でリストアップされる、Eインタフェース上で送信される各BSSMAPメッセ
ージは、4.5.4節で与えられるメカニズムを使用すること。それについては、3GPP TS 48.008に記載されている。
4.7.5.1
Encryption Information（暗号化情報）
The list of GSM algorithms, the ciphering key and the chosen algorithm shall be stored by 3G_MSC-B and used for
generating the UMTS parameters Encryption Information and Integrity Protection Information if they are not received
in MAP Prepare Handover Request (the generation of the UMTS parameters from the GSM parameters is described in
TS 33.102).
3G_MSC-Bは、GSMのアルゴリズムのリスト、暗号鍵、そして選択されたアルゴリズムを保存すること。そしてそれら
をMAP Prepare Handover Request中で受信しなかった場合には、保存された値を使用して、UMTS parameters
Encryption InformationとIntegrity Protection Informationを生成すること（GSMのパラメータからUMTSのパラメータを
生成する手順については、TS 33.102内で述べる）。
Transfer of Information:
情報の送信
If ciphering has not been performed before Inter-MSC Handover, this will be controlled by MSC-A after the
completion of Inter-MSC Handover.
MSC間ハンドオーバ実行前に暗号化が実行されなかった場合には、MSC間ハンドオーバ完了後にMSC-Aに
よって暗号化が制御される：
3GPP
Release 1999
93
3GPP TS 29.010 V3.10.0 (2002-12)
Ciphering control towards 3G_MSC-B:
3G_MSC-Bに対する暗号化の制御：
If Ciphering has been performed before Inter-MSC Handover:
MSC間ハンドオーバ実行前にハンドオーバ前に既に暗号化が実行されている場合：
-
in the Handover Request BSSMAP message (information included).
Handover Request BSSMAPメッセージの中（に情報が含まれる）
The Handover Request Acknowledge should in this case NOT contain the indication of the chosen
algorithm.
この場合、Handover Request Acknowledge中に選択されたアルゴリズムの通知が含まれてはならな
い。
If Ciphering has NOT been performed before Inter-MSC Handover:
MSC間ハンドオーバ実行前にハンドオーバ前に暗号化が実行されなかった場合：
-
4.7.5.2
in the Cipher Mode Command procedure between MSC-A and 3G_MSC-B.
MSC-Aと3G_MSC-B間のCipher Mode Command処理の中
Channel Type（チャネルタイプ）
The Channel Type shall be stored by 3G_MSC-B and used for generating RAB parameters.
3G_MSC-Bは、Channel Typeを保存し、RABパラメータを生成するために使用すること。
Transfer of Information:
情報の送信：
Independently of the type of resource (Signalling only or traffic channel) assigned to the MS, the Channel Type
Information is transferred to 3G_MSC-B in:
MSに割当てられたリソースのタイプと無関係な情報（シグナリングのみか、トラフィックチャネルか）、Channel
Type Information は次のメッセージ中に入れられて3G_MSC-Bに送信される：
-
the Handover Request BSSMAP message.
Handover Request BSSMAPメッセージ
Chosen Channel and/or Speech Version shall NOT be reported back to MSC-A in the Handover Request
Acknowledge
Chosen Channel および／または Speech Versionを、Handover Request Acknowledge中でMSC-Aに対して
レポートバックしてはならない。
If a new type of resource is to be assigned after Inter-MSC Handover, this can be made with:
MSC間ハンドオーバ後に新しいタイプのリソースを割当てるべき場合、次の処理と一緒に行なうことができる：
-
4.7.5.3
the BSSMAP Assignment procedure between MSC-A and 3G_MSC-B.
MSC-Aと3G_MSC-B間のBSSMAP Assignment 処理
Classmark（クラスマーク）
This information shall be stored by 3G_MSC-B and might be received from MSC-A.
本情報は、3G_MSC-Bによって保存されること。MSC-Aから受信することもある。
Transfer of Information due to Classmark received from MSC-A:
MSC-Aから受信したClassmarkに起因する情報の送信：
This information shall be stored by 3G_MSC-B and is received:
3G_MSC-Bは以下のメッセージ内で受信した本情報を保存すること：
-
in the Handover Request BSSMAP message.
Handover Request BSSMAP メッセージ
3GPP
Release 1999
94
3GPP TS 29.010 V3.10.0 (2002-12)
If a new type of resource is to be assigned after Inter-MSC Handover, Classmark Information MAY be included:
MSC間ハンドオーバ後に新しいタイプのリソースの割当てるべき場合には、次の処理中にClassmark
Information が含まれることもある：
-
4.7.5.4
in the BSSMAP Assignment procedure.
BSSMAP Assignment 処理
Priority（優先度）
The parameter shall be stored by 3G_MSC-B and used for generating RAB parameters. It is received as detailed below:
3G_MSC-Bは、本パラメータを保存し、RABパラメータを生成するために使用すること。本パラメータは次のようにし
て受信される：
Transfer of Information:
情報の送信：
Received by 3G_MSC-B from MSC-A in:
次のメッセージ内でMSC-Aから3G_MSC-Bが受信：
-
the Handover Request BSSMAP message.
Handover Request BSSMAPメッセージ
If a change is needed after an Inter-MSC Handover with:
MSC間ハンドオーバ実行後、変更が必要な場合には、次の処理と一緒に行なわれる：
-
4.7.5.5
the BSSMAP Assignment procedure.
BSSMAP Assignment処理
MSC-Invoke Trace Information Elements（MSC-Invoke Trace IE）
The process to be performed by 3G_MSC-B on the information elements of the MSC Invoke Trace BSSMAP messages
is left for further study.
MSC Invoke Trace BSSMAPメッセージのIE上で、3G_MSC-Bが実行すべき処理についてはFFSとする。
Note that MSC-A does not forward BSC Invoke Trace in case of GSM to UMTS handover.
GSMからUMTSへのハンドオーバ場合、MSC-AはBSC Invoke Traceを転送しないことに注意。
4.7.5.6
Selected UMTS Algorithm（選択されたUMTSアルゴリズム）
A sequence of possible encryption and integrity protection algorithms, received from the 3G_MSC-A, can be sent to an
RNS in Relocation Request or in Security Mode Command in case of cipher mode setting after inter-MSC handover
from GSM to UMTS. The RNS chooses one of the listed algorithms and reports this back to the 3G_MSC in Relocation
Request Acknowledge or Security Mode Complete respectively. The MSC-B provides the Selected UMTS algorithm
information to the MSC-A. The Selected UMTS algorithms IE in the MAP Process Access Signalling Request and
MAP Prepare Handover Response messages refers to the Chosen Integrity Protection Algorithm and Chosen Encryption
Algorithm, defined in RANAP specification 3GPP TS 25.413
3G_MSC-Aから受信した、暗号化と完全性保護アルゴリズムの想定されるシーケンスは、Relocation Request中、ま
たはGSMからUMTSへのMSC間のハンドオーバ後に暗号化モードが設定された場合にはSecurity Mode Command
中に入れて、RNSに送信することができる。RNSはリストアップされたアルゴリズムの中から1つを選択して、選択した
アルゴリズムをRelocation Request AcknowledgeまたはSecurity Mode Completeの中で、3G_MSCに対してレポート
バックする。MSC-Bは、Selected UMTS algorithm情報をMSC-Aに提供する。MAP Process Access Signalling Request
メッセージ中のSelected UMTS algorithms IEは、RANAP仕様書3GPP TS 25.413に定義されるChosen Integrity
Protection AlgorithmおよびChosen Encryption Algorithmを参照する。
The selected algorithm shall be stored by 3G_MSC-B, and sent to 3G_MSC-A.
3G_MSC-Bは選択されたアルゴリズムを保存し、3G_MSC-Aに対して送信すること。
Transfer of Information:
情報の送信：
3GPP
Release 1999
95
3GPP TS 29.010 V3.10.0 (2002-12)
If ciphering has not been performed before Inter-MSC Handover, this will be controlled by 3G_MSC-A after the
completion of Inter-MSC Handover.
MSC間ハンドオーバ前に暗号化が実行されなかった場合には、MSC間ハンドオーバの完了後に、3G_MSCAが暗号化を制御する。
If Ciphering has been performed before Inter-MSC Handover, Selected UMTS algorithm information is received
by 3G_MSC-A from 3G_MSC-B in:
MSC間ハンドオーバ前に暗号化が実行された場合には、3G_MSC-Aは次のメッセージ中で3G_MSC-Bから
Selected UMTS algorithm情報を受信する。
−
The Prepare Handover Response MAP message.
Prepare Handover Response MAPメッセージ
If Ciphering has NOT been performed before Inter-MSC Handover, Selected UMTS algorithm information is
received by 3G_MSC-A from 3G_MSC-B in:
MSC間ハンドオーバ前に暗号化が実行されなかった場合には、3G_MSC-Aは次のメッセージ中で3G_MSCBからSelected UMTS algorithm情報を受信する。
−
The Process Access Signalling Request MAP message.
Process Access Signalling Request MAPメッセージ
4.7.5.7
Allowed UMTS Algorithms（許容されたUMTSアルゴリズム）
In case of GSM-subscriber, the Integrity Protection Information and UMTS Encryption Information are not transferred
to the MSC-B during inter-MSC handover from GSM to UMTS. Allowed UMTS algorithms is UMTS information that
is required in RANAP Relocation Request and RANAP Security Mode Command, and shall be provided by 3G_MSCA. 3G_MSC-B needs this information in case of an inter-MSC GSM to UMTS handover and in subsequent security
mode setting, after an inter-MSC GSM to UMTS handover. Therefore 3G_MSC-A must provide this information in
case of an inter-MSC GSM to UMTS handover. The Allowed UMTS algorithms IE in the MAP Prepare Handover and
in the MAP Forward Access Signalling Request messages refers to the Permitted Integrity Protection Algorithms in
Integrity Protection Information and Permitted Encryption Algorithms in Encryption Information, defined in
RANAP specification 3GPP TS 25.413.
GSM加入者の場合には、GSMからUMTSへのMSC間ハンドオーバの間にIntegrity Protection Information（完全性
保護情報）とUMTS Encryption Information（UMTS暗号化情報）がMSC-Bに対して送信されることはない。Allowed
UMTS algorithmsは、RANAP Relocation Request およびRANAP Security Mode Command内で要求されるUMTSの
情報であり、3G_MSC-Aが提供すること。GSMからUMTSへのMSC間ハンドオーバの場合と、GSMからUMTSへの
MSC間ハンドオーバ後に続くセキュリティモードの場合に、3G_MSC-Bが本情報を必要とする。であるから、GSMか
らUMTSへのMSC間ハンドオーバの場合には3G_MSC-Aが本情報を提供する必要がある。MAP Prepare Handover
メッセージとMAP Forward Access Signalling Request メッセージ中のAllowed UMTS algorithms IE は、Integrity
Protection Information中のPermitted Integrity Protection Algorithms と、Encryption Information中のPermitted
Encryption Algorithmsを参照する。これらについては、仕様書3GPP TS 25.413に定義される。
Allowed UMTS algorithms shall be stored by 3G_MSC-B.
3G_MSC-Bは、Allowed UMTS algorithmsを保存すること。
Transfer of information:
情報の送信：
If ciphering has not been performed before Inter-MSC Handover, this will be controlled by 3G_MSC-A after the
completion of Inter-MSC Handover.
MSC間ハンドオーバ前に暗号化が実行されなかった場合には、MSC間ハンドオーバ完了後に3G_MSC-Aが
暗号化を制御する。
Ciphering control towards 3G_MSC-B:
3G_MSC-Bに対する暗号化制御：
If Ciphering has been performed before Inter-MSC Handover:
MSC間ハンドオーバ前に暗号化が実行された場合：
3GPP
Release 1999
−
96
3GPP TS 29.010 V3.10.0 (2002-12)
The Prepare Handover Request MAP message.
Prepare Handover Request MAPメッセージ
If Ciphering has NOT been performed before Inter-MSC Handover:
MSC間ハンドオーバ前に暗号化が実行されなかったならば：
−
The Forward Access Signalling Request MAP message.
Forward Access Signalling Request MAPメッセージ
4.7.5.8
BSSMAP Service Handover（BSSMAP Service Handover）
This information shall be stored by 3G_MSC-B and sent to a BSS in Handover Request, when 3G_MSC-B performs
handover to GSM.
本情報は3G_MSC-Bによって保存され、3G_MSC-BがGSMへのハンドオーバを実行する時に、Handover Request中
でBSSに送信すること。
Transfer of information:
情報の送信：
The BSSMAP Service Handover information is transferred to 3G_MSC-B in:
BSSMAP Service Handover information は、次のメッセージ中で3G_MSC-Bに対して送信される：
− the Handover Request BSSMAP message.
Handover Request BSSMAP メッセージ
If a new assignment of a TCH after an inter-MSC handover is to be performed, the BSSMAP Service Handover
information is transferred to 3G_MSC-B in:
MSC間ハンドオーバ後に新たにTCH割当を実行すべき場合には、次の処理中でBSSMAP Service Handover
情報が3G_MSC-Bに送信される：
− the BSSMAP Assignment procedure.
BSSMAP Assignment 処理
4.7.5.9
RANAP Service Handover（RANAP Service Handover）
This information shall be stored by 3G_MSC-B and sent to an RNS in Relocation Request during the basic inter-MSC
handover or when 3G_MSC-B performs a subsequent relocation or handover to UMTS.
本情報は、3G_MSC-Bによって保存され、3G_MSC-BがUMTSに対して後続リロケーションまたはハンドオーバを実
行する際に、RNSに送信すること。
Transfer of information:
情報の送信：
The RANAP Service Handover information is transferred to 3G_MSC-B in:
RANAP Service Handover情報は、次のメッセージ中で3G_MSC-Bに送信される：
− the Prepare Handover Request MAP message.
Prepare Handover Request MAP メッセージ
If a new assignment of a Radio Access Bearer after an inter-MSC handover is to be performed, the information
is transferred to 3G_MSC-B in:
MSC間ハンドオーバ後に新たにRAB（Radio Access Bearer）割当を実行すべき場合には、情報は次のメッセ
ージ中で3G_MSC-Bに送信される：
− the Forward Access Signalling Request MAP message
Forward Access Signalling Request MAP メッセージ
and sent by 3G_MSC-B to the RNS in RAB Assignment Request.
そして、3G_MSC-BはRAB Assignment Request中でRNSに送信する。
3GPP
Release 1999
97
3GPP TS 29.010 V3.10.0 (2002-12)
4.7.6 Cause Code Mapping（理由コードのマッピング）
When a Mobile Station is handed over between GSM and UMTS, a mapping of the cause codes used in the BSSMAP
and the RANAP protocols is needed. The mapping described here is applicable to the BSSMAP protocol even when
used inside MAP in the E-interface.
MSがGSMとUMTS間でハンドオーバされる場合、BSSMAPプロトコルで使用される理由コードとRANAPプロトコルで
使用される理由コード間のマッピングが必要となる。ここで説明するマッピングは、Eインタフェース上でMAP内部で
使用される場合でも、BSSMAPプロトコルに対して適用可能である
The mapping between the cause codes received in BSSMAP Handover Required and the cause codes sent in RANAP
Relocation Request is as follows:
BSSMAP Handover Required 中で受信する理由コードと、RANAP Relocation Request 中で送信する理由コード間
のマッピングについて以下に述べる：
---------------------------------------------------------------08.08
25.413
|Notes
-------------------------------------------------------┼-------HANDOVER REQUIRED
RELOCATION REQUEST
|
|
-Better Cell
-Time critical reloc. |
-Directed retry
-Directed retry
|
-Distance
-Time critical reloc. |
-Downlink quality
-Time critical reloc. |
-Downlink strength
-Time critical reloc. |
-O and M intervention
-O and M intervention |
-Preemption
-RAB pre-empted
|
-Response to MSC invocation
-Time critical reloc. |
-Switch circuit pool
|
1
-Traffic
-Time critical reloc. |
-Uplink quality
-Time critical reloc. |
-Uplink strength
-Time critical reloc. |
-Any other value
-Time critical reloc. |
NOTE 1: Cause code not used at inter-system handover.
システム間ハンドオーバの場合、理由コードは使用しない。
The mapping between the cause codes received in BSSMAP Handover Request and the cause codes sent in RANAP
Relocation Request is as follows (the mapping is only used for the MAP-E interface):
BSSMAP Handover Request 中で受信する理由コードとRANAP Relocation Request 中で送信する理由コード間のマ
ッピングについて、以下に述べる（マッピングはMAP-Eインタフェースに対してのみ使用される）：
---------------------------------------------------------------08.08
25.413
|Notes
-------------------------------------------------------┼-------HANDOVER REQUEST
RELOCATION REQUEST
|
|
-Better Cell
-Time critical reloc. |
-Directed retry
- Directed retry
|
-Distance
-Time critical reloc. |
-Downlink quality
-Time critical reloc. |
-Downlink strength
-Time critical reloc. |
-O and M intervention
-O and M intervention |
-Preemption
-RAB pre-empted
|
-Response to MSC invocation
-Time critical reloc. |
-Switch circuit pool
|
1
-Traffic
-Time critical reloc. |
-Uplink quality
-Time critical reloc. |
-Uplink strength
-Time critical reloc. |
-Any other value
-Time critical reloc. |
NOTE 1: Cause code not used at inter-system handover.
システム間ハンドオーバの場合、理由コードは使用されない。
3GPP
Release 1999
98
3GPP TS 29.010 V3.10.0 (2002-12)
The mapping between the cause codes received in BSSMAP Handover Failure and the cause codes sent in RANAP Iu
Release Command is as follows:
BSSMAP Handover Failure 中で受信する理由コードと、RANAP Iu Release Command 中で送信する理由コードの
間のマッピングを以下に示す：
---------------------------------------------------------------08.08
25.413
|Notes
-------------------------------------------------------┼-------HANDOVER FAILURE
IU RELEASE COMMAND
|
|
-Ciphering algorithm not
| 2
supported
|
-Circuit pool mismatch
| 1
-Equipment failure
-Relocation cancelled |
-Invalid message contents
-Abstract Syntax Error |
-No radio resource available
| 2
-O and M intervention
-O and M intervention |
-Radio interface failure,
-Relocation cancelled |
reversion to old channel
|
-Radio interface message
-Relocation cancelled |
failure
|
-Requested speech version
| 2
unavailable
|
-Requested terrestrial
| 2
resource unavailable
|
-Requested transcoding/rate
| 2
adaption unavailable
|
-Switch circuit pool
|
1
-Terrestrial circuit already
-Relocation cancelled |
allocated
|
-Any other value
-Relocation cancelled |
NOTE 1: Cause code not used at inter-system handover.
システム間ハンドオーバの場合、理由コードは使用されない。
NOTE 2: Cause code not applicable to this traffic case.
このトラフィックのケースに対しては、理由コードは適用できない。
The mapping between the cause codes received in RANAP Relocation Failure and the cause codes sent in BSSMAP
Handover Failure is as follows (this mapping is only used for the MAP-E interface):
RANAP Relocation Failure 中で受信する理由コードと、BSSMAP Handover Failure 中で送信する理由コードの間の
マッピングを以下に示す（本マッピングはMAP-Eインタフェースに対してのみ使用される）：
---------------------------------------------------------------25.413
08.08
|Notes
-------------------------------------------------------┼-------RELOCATION FAILURE
HANDOVER FAILURE
|
|
-Any value
-No radio resource
|
available
|
3GPP
Release 1999
99
3GPP TS 29.010 V3.10.0 (2002-12)
The mapping between the cause codes received in RANAP Relocation Failure and the cause codes sent in BSSMAP
Handover Request Reject is as follows:
RANAP Relocation Failure 中で受信する理由コードと、BSSMAP Handover Request Reject中で送信する理由コード
間のマッピングを以下に示す：
---------------------------------------------------------------25.413
08.08
|Notes
-------------------------------------------------------┼-------RELOCATION FAILURE
HANDOVER REQUIRED REJECT
|
|
-Any value
-No radio resource
|
available
|
3GPP
Release 1999
100
3GPP TS 29.010 V3.10.0 (2002-12)
The mapping between the RANAP and the BSSMAP assignment messages is used in the MAP-E interface. RANAP
RAB Assignment Response with successful result is mapped to BSSMAP Assignment Complete; RANAP RAB
Assignment Response with unsuccessful result is mapped to BSSMAP Assignment Failure. The mapping between the
cause codes received in RANAP RAB Assignment Response and the cause codes sent in BSSMAP Assignment Failure
is as follows (this mapping is only used for the MAP-E interface):
RANAPとBSSMAPの割当メッセージ間のマッピングは、MAP-Eインタフェース上で使用される。RANAP RAB
Assignment Responseは、処理が成功した場合BSSMAP Assignment Completeに、処理が失敗した場合RANAP
BSSMAP Assignment Failureにマッピングされる。RANAP RAB Assignment Response 中で受信する理由コードと、
BSSMAP Assignment Failure中で送信する理由コード間のマッピングについて、以下に示す（本マッピングはMAP-E
インタフェースに対してのみ使用される）：
---------------------------------------------------------------25.413
08.08
|Notes
-------------------------------------------------------┼-------RAB ASSIGNMENT RESPONSE
ASSIGNMENT FAILURE
|
|
-Requested traffic class not
–No radio resource
|
available
available
|
-Invalid RAB parameters value –Invalid msg. contents |
-Requested max bit rate not
–No radio resource
|
available
available
|
-Requested max bit rate for DL –No radio resource
|
not available
available
|
-Requested max bit rate for UL –No radio resource
|
not available
available
|
-Requested guaranteed bit rate –No radio resource
|
not available
available
|
-Requested guaranteed bit rate –No radio resource
|
for DL not available
available
|
-Requested guaranteed bit rate –No radio resource
|
for UL not available
available
|
-Requested transfer delay not –No radio resource
|
achievable
available
|
-Invalid RAB param. combination–Invalid msg. contents |
-Condition violation for SDU
–Invalid msg. contents |
parameters
|
-Condition violation for
–Invalid msg. contents |
traffic handling priority
|
-Condition violation for
–Invalid msg. contents |
guaranteed bit rate
|
-User plane not supported
–No radio resource
|
available
|
-Iu UP failure
–Equipment failure
|
-Tqueuing expiry
–Radio interface message|
failure
|
-Invalid RAB id
–Invalid msg. contents |
-Request superseeded
–No radio resource
|
available
|
-Relocation triggered
-No radio resource
|
available
|
-Any other value
–Radio interface message|
failure
|
3GPP
Release 1999
101
3GPP TS 29.010 V3.10.0 (2002-12)
The mapping between the cause codes received in RANAP Location Report and the cause codes sent in BSSMAP
Handover Performed is as follows (this mapping is only used for the MAP-E interface):
RANAP Location Report中で受信する理由コードと、BSSMAP Handover Performed中で送信する理由コードの間の
マッピングを以下に示す（本マッピングはMAP-Eインタフェースに対してのみ使用される）：
---------------------------------------------------------------25.413
08.08
|Notes
-------------------------------------------------------┼-------LOCATION REPORT
HANDOVER PERFORMED
|
|
-User restriction start ind.
–O&M intervention
|
-User restriction start ind.
–O&M intervention
|
-Requested report type not
| 1
supported
|
-Any other value
-Better cell
|
NOTE 1: In this case, no Handover Performed is sent.
このケースではHandover Performed は送信されない。
4.8
Inter-MSC Relocation（MSC間リロケーション）
The general principles of the relocation procedures are given in Technical Specification TS 23.009. TS 29.010 gives the
necessary information for interworking between the TS 25.413 relocation protocol and the TS 29.002 MAP protocol.
リロケーション処理の原則については、技術仕様書TS 23.009で与えられる。TS 23.009は、TS 25.413で規定されるリ
ロケーションプロトコルと、TS 29.002で規定されるMAPプロトコル間のインターワーキングに必要な情報を与える。
For intra UMTS handovers, RANAP is carried over the MAP-E interface instead of BSSAP. Please refer to 3GPP TS
29.108.
UMTS内ハンドオーバに関しては、BSSAPの代わりにRANAPがMAP-Eインタフェース上で持ち越される。3GPP TS
29.108を参照。
4.8.1
Basic Inter-MSC Relocation（基本的MSC間リロケーション）
When a Mobile Station is relocated between two MSCs, the establishment of a connection between them (described in
TS 23.009) requires interworking between Iu-Interface and E-Interface.
MSが2つのMSC間でリロケーションされた場合、（3GPP TS 23.009に説明されるように）両者の間でコネクションを確
立するために、IuインタフェースとEインタフェース間のインターワーキングが要求される。
The signalling at initiation, execution and completion of the Basic Inter-MSC relocation procedure is shown in figures
50 to 54 with both possible positive or negative outcomes.
基本的MSC内リロケーション処理の開始、実行、完了のシグナリングを、処理が成功した場合と失敗した場合のそ
れぞれについて、図50から図54に示す。
3GPP
Release 1999
102
3GPP TS 29.010 V3.10.0 (2002-12)
Additionally figure 50b shows the possible interworking when trace related messages are transparently transferred on
the E-Interface at Basic Inter-MSC Relocation initiation.
さらに図50bに、基本的MSC間リロケーション開始時にEインタフェース上でトレース関連メッセージを透過的に送信
する場合に想定されるインターワーキングを示す。
RNS-A
3G-MSC-A
3G-MSC-B
|
|
|
|RELOCATION
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request
| |Possible Alloc. |
|
|
| |of a relocation|
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|------------------>|
Figure 50a: Signalling for Basic Inter-MSC Relocation initiation (no trace related messages
transferred)
図50a：基本的MSC間リロケーション開始のシグナリング（トレース関連メッセージが送信されない場合）
RNS-A
3G-MSC-A
3G-MSC-B
|
(*)
|
|RELOCATION
|
|
|-------------->|MAP PREPARE HANDOVER
|
|REQUIRED
|------------------------>| +----------------+
|
|request (**)
| |Possible Alloc. |
|
|
| |of a relocation |
|
|
| |no. in the VLR-B|
|
|
| +----------------+
|
|
|
|
|
|
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|------------------>|
|
|
|
|
|
|
|CN INVOKE TRACE
|
|
|
|--------------->(***)
Figure 50b: Signalling for Basic Inter-MSC Relocation initiation (CN invoke trace message
transferred)
図50b：基本的MSC間リロケーション開始のシグナリング（CN invoke traceメッセージが送信される場合）
(*):
Tracing invocation has been received from VLR.
トレースの起動はVLRから既に受信している。
(**):
In that case, RELOCATION REQUEST and CN INVOKE TRACE messages are included within the
AN-apdu parameter.
このケースでは、AN-apduパラメータ中にRELOCATION REQUESTおよびCN INVOKE TRACEメッセ
ージが含まれる。
(***):
CN INVOKE TRACE is forwarded to RNS-B if supported by 3G_MSC-B.
3G_MSC-Bがサポートする場合、CN INVOKE TRACEはRNS-Bに転送される。
3GPP
Release 1999
103
3GPP TS 29.010 V3.10.0 (2002-12)
Possible Positive outcomes: successful radio resources allocation and relocation numbers allocation (if performed):
想定される処理の成功：無線リソース割当とリロケーション番号割当（実行される場合）に成功した場合：
RNS-A
3G-MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|
|
|
|
|RELOCATION COMMAND
|
|
|<--------------|
|
|
Possible Negative outcomes:
想定される処理の失敗：
a)
user error detected, or relocation numbers allocation unsuccessful (if performed), or component rejection or
dialogue abortion performed by 3G_MSC-B:
ユーザエラーの検出、またはリロケーション番号割当（もし実行されれば）に失敗、または3G_MSC-Bがコン
ポーネントを拒否、またはダイヤログの中断を実行：
RNS-A
3G-MSC-A
3G-MSC-B
|
|
|
|
|MAP PREPARE HANDOVER response
|
|negative result, MAP CLOSE
|
|<------------------------|
|
|MAP U/P-ABORT
|
|RELOCATION PREPARATION
|
|<--------------|
|
|FAILURE
|
MAP CLOSE
|
|
|------------------------>|
|
|
|
RNS-B
|
|
|
|
|
|
|
|
|
|
b) radio resources allocation failure:
無線リソース割当の失敗：
RNS-A
3G-MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|
|
|RELOCATION FAILURE |
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
|
|
|<------------------------|
|
|
| response
|
|
|RELOCATION PREPARATION
|
|
|<--------------|
|
|
|FAILURE
|
|
|
|
|
|
|
3GPP
Release 1999
c)
104
3GPP TS 29.010 V3.10.0 (2002-12)
radio resources allocation partial failure (3G_MSC-A decides to reject the relocation):
無線リソース割当の部分的失敗（3G_MSC-Aがリロケーションの拒否を決定した場合）：
RNS-A
3G-MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|<------------------|
|
|MAP PREPARE HANDOVER
|
ACK
|
|
|<------------------------|
|
|
| response
|
|
|RELOCATION PREPARATION
|
|
|<--------------|
|
|
|FAILURE
|
|
|
|
|
|
|
d) unsuccessful relocation execution (relocation cancelled):
リロケーション実行の失敗（リロケーションはキャンセルされる）：
RNS-A
3G-MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|RELOCATION
|
|
|
|-------------->|
|
|
|CANCEL
|
|
|
|
|MAP U -ABORT
|
|
|
|------------------------>|
|
|
|
|IU RELEASE COMMAND |
|RELOCATION
|
|------------------>|
|<--------------|
|
|
|CANCEL ACK
|
|
|
|
|
|
|
Figure 51: Signalling for Basic Inter-MSC Relocation execution (Negative outcomes)
図51：基本的MSC間リロケーション実行のシグナリング（処理の失敗）
RNS-A
3G-MSC-A
3G-MSC-B
RNS-B
|
|
|
|
|
|
|RELOCATION COMPLETE|
|
|
|<------------------|
|
|MAP SEND END SIGNAL request
|
|
|<------------------------|
|
|IU RELEASE COMMAND
|
|
|<--------------|
|
|
|
|
|
|
Figure 52: Signalling for Basic Inter-MSC Relocation completion
図50：基本的MSC間リロケーション完了のシグナリング
Positive outcome
処理の成功：
RNS-A
|
|
|
|
|
|
3G-MSC-A
3G-MSC-B
RNS-B
|
|
|
|MAP SEND END SIGNAL
|
|
|------------------------>|
|
| response
|IU RELEASE COMMAND |
|
|------------------>|
|
| (Note 1)
|
Figure 53: Signalling for Basic Inter-MSC Relocation completion (Positive outcome)
図53：基本的MSC間リロケーション完了のシグナリング（処理の成功）
3GPP
Release 1999
NOTE:
105
3GPP TS 29.010 V3.10.0 (2002-12)
From interworking between MAP and RANAP point of view.
MAPとRANAP間のインターワーキングという観点から。
Negative outcome:
処理の失敗：
RNS-A
|
|
|
|
|
|
3G-MSC-A
3G-MSC-B
RNS-B
|
|
|
| MAP U/P -ABORT
|
|
|------------------------>|
|
|
|IU RELEASE COMMAND |
|
|------------------>|
|
|
|
Figure 54: Signalling for Basic Inter-MSC Relocation completion (Negative outcome)
図54：基本的MSC間リロケーション完了のシグナリング（処理の失敗）
The relocation procedure is normally triggered by RNS-A by sending a RELOCATION REQUIRED message on IuInterface to 3G_MSC-A. The invocation of the Basic Inter-MSC relocation procedure is performed and controlled by
3G_MSC-A. The sending of the MAP Prepare-Handover request to 3G_MSC-B is triggered in 3G_MSC-A upon
receipt of the RELOCATION REQUIRED message. The identity of the target RNC where the call is to be handed over
in 3G_MSC-B area, provided in the RELOCATION REQUIRED message, is mapped to the target RNC Id MAP
parameter and the RELOCATION REQUEST message is encapsulated in the an-APDU MAP parameter of the PrepareHandover MAP request. 3G_MSC-B can invoke another operation towards the VLR-B (allocation of the relocation
numbers described in 3GPP TS 29.002).
リロケーション処理は通常、RNS-AがIuインタフェース上で3G_MSC-AにRELOCATION REQUIRED を送信するこ
とによってトリガされる。基本的MSC間リロケーション処理の起動は、3G_MSC-Aによって実行され制御される。
RELOCATION REQUIREDメッセージを受信すると3G_MSC-A内で、3G_MSC-BへのMAP Prepare-Handover要求
の送信がトリガされる。3G_MSC-Bのエリア内の呼のハンドオーバ先のtarget RNCのIDは、RELOCATION
REQUIREDメッセージ中で提供されるが、target RNCのIDはtarget RNC Id MAPパラメータ中にマッピングされ、
RELOCATION REQUESTメッセージはPrepare-Handover MAP要求のan-APDU MAPパラメータ中にカプセル化され
る。3G_MSC-Bはそれ以外のオペレーションをVLR-Bに対して起動することができる（リロケーション番号の割当につ
いては3GPP TS 29.002中で説明される）。
Additionally, if tracing activity has been invoked, the trace related messages can be transferred on the E-Interface
encapsulated in the an-APDU MAP parameter of the Prepare-Handover Request. If transferred, one complete trace
related message at a time shall be included in the an-APDU MAP parameter after the RELOCATION REQUEST
message.
さらに、トレースアクティビティが既に起動されている場合には、トレース関連メッセージをPrepare-Handover Request
のan-APDU MAPパラメータ中にカプセル化してEインタフェース上で送信することもできる。トレース関連メッセージを
送信する場合には、RELOCATION REQUESTの後に、一連の完全なトレース関連のメッセージを同じan-APDU
MAPパラメータ中に含めること。
3GPP
Release 1999
106
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Prepare Handover and RELOCATION REQUIRED is as follows:
Prepare HandoverとRELOCATION REQUIRED間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION REQUIRED MAP PREPARE HANDOVER request|
message |
|
|
-ho-NumberNotRequired|
1
|
-target RNC Id
|
| RANAP information
-Radio Resource Info |
|
elements
-an-APDU(
|
|
RELOCATION REQUEST, |
2
|
CN INVOKE TRACE)
|
--------┼-------------------------------------------------┼----Positive|
MAP PREPARE HANDOVER response
|
result |
|
3
|
-relocation numbers |
|
-an-APDU(
|
| RELOCATION COMMAND
RELOCATION REQUEST |
|
ACKNOWLEDGE
|
|
or
|
| RELOCATION PREP FAILURE
RELOCATION FAILURE)|
|
|
--------┼-------------------------------------------------┼----Negative| RELOCATION PREP FAILURE
MAP PREPARE HANDOVER|
result |
|
| Unspecified failure
System Failure
|
| Unspecified failure
No Handover Number |
|
available
|
| Unspecified failure
UnexpectedDataValue|
| Unspecified failure
Data Missing
|
|
|
| Unspecified failure
MAP CLOSE
|
| Unspecified failure
MAP U/P -ABORT
|
|
|
NOTE 1: The RANAP information elements are already stored in 3G_MSC.
RANAP IEは既に3GのMSC内に保存されている。
The ho-NumberNotRequired parameter is included by 3G_MSC-A, when 3G_MSC-A decides not to use
any circuit connection with 3G_MSC-B. No relocation numbers shall be present in the positive result.
Any negative response from 3G_MSC-B shall not be due to relocation number allocation problem.
3G_MSC-Aが3G_MSC-Bと回線交換コネクションを使用しないことを決めた場合には、3G_MSC-Aは
ho-NumberNotRequired パラメータを含める。ポジティブな結果には、リロケーション番号が含まれては
ならない。3G_MSC-Bからの全てのネガティブな応答は、リロケーション番号割当問題に起因するもの
であってはならない。
NOTE 2: The process performed on the RANAP information elements received in the RELOCATION REQUIRED
message is described in the 3GPP TS 25.413.
RELOCATION REQUIREDメッセージ中で受信したRANAPのIE上で実行されるプロセスについては、
3GPP TS 25.413で説明される。
NOTE 3: The response to the Prepare-Handover request can include in its an-APDU parameter, identifying the
3GPP TS 25.413 protocol, either a RANAP RELOCATION REQUEST ACKNOWLEDGE or a RANAP
RELOCATION FAILURE.
Prepare-Handover request に対する応答をそのan-APDUパラメータ中に入れて、3GPP TS 25.413 プロ
トコルがRANAP RELOCATION REQUEST ACKNOWLEDGE またはRANAP RELOCATION
FAILUREのいずれかであることを識別することもできる。
In the first case, the positive result triggers in 3G_MSC-A the sending on Iu-Interface of the
RELOCATION CMD.
一番目のケースでは、処理が成功すると、3G_MSC-A内でRELOCATION CMDのIuインタフェース上
での送信がトリガされる。
3GPP
Release 1999
107
3GPP TS 29.010 V3.10.0 (2002-12)
In the second case, the positive result triggers in 3G_MSC-A the sending of the RELOCATION PREP
FAILURE.
二番目のケースでは、処理が成功すると、3G_MSC-A内でRELOCATION PREP FAILUREの送信が
トリガされる。
The interworking between Send End Signal and RELOCATION COMPLETE in 3G_MSC-B is as follows:
3G_MSC-B内でのSend End Signal とRELOCATION COMPLETE間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION COMPLETE MAP SEND END SIGNAL request |
message |
|
|
-an-APDU(
|
|
RELOCATION COMPL) |
|
|
--------┼-------------------------------------------------┼----Positive| IU RELEASE COMMAND MAP SEND END SIGNAL response|
result | -Normal release
| 1
--------┼-------------------------------------------------┼----Negative| IU RELEASE COMMAND
|
result | -Normal release
MAP CLOSE
| 2
| -Normal release
MAP U/P -ABORT
|
|
|
NOTE 1: The positive empty result triggers the clearing of the Radio Resources on the Iu-Interface and the release
of the SCCP connection between 3G_MSC-B and RNS-B. If a circuit connection is used between
3G_MSC-A and 3G_MSC-B, the 'Normal release' clearing cause shall only be given to RNS-B when
3G_MSC-B has received a clearing indication on its circuit connection with 3G_MSC-A.
ポジティブなエンプティな結果は、Iuインタフェース上での無線リソースのクリアと、3G_MSC-BとRNS-B
間のSCCPコネクションの開放をトリガする。3G_MSC-Aと3G_MSC-B間で回線交換コネクションが使用
される場合には、3G_MSC-Bが3G_MSC-Aとの回線交換コネクション上でクリア通知を受信したなら
ば、RNS-B に対して'Normal release' クリア理由だけを与えること。
NOTE 2: The abortion of the dialogue or the rejection of the component triggers in 3G_MSC-B the clearing of its
circuit connection with 3G_MSC-A, if any, of the Radio Resources on the Iu-Interface and the release of
the SCCP connection between 3G_MSC-B and RNS-B.
ダイヤログの中断またはコンポーネントの拒否が起きた場合、3G_MSC-B内で3G_MSC-Aとの回線交
換コネクションの開放と、もしあればIuインタフェース上での無線リソースの開放と、3G_MSC-B と
RNS-B間のSCCPコネクションの開放がトリガされる。
The interworking between Send End Signal and IU RELEASE COMMAND in 3G_MSC-A is as follows:
3G_MSC-A内の、Send End Signal とIU RELEASE COMMAND 間のインターワーキングについて、以下に示す：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP SEND END SIGNAL
IU RELEASE COMMAND |
message | request
|
|
-an-APDU(
- Successful
|
|
RELOCATION COMPLETE)
Relocation
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
3GPP
Release 1999
108
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between RELOCATION CANCEL in case of relocation cancelled and User Abort in 3G-MSC-A is
as follows:
リロケーションがキャンセルされた場合の3G-MSC-A内における、RELOCATION CANCELとUser Abort間のインタ
ーワーキングを以下に示す：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION CANCEL
MAP U -ABORT
|
message |
|
| - Relocation
|
|
cancelled
|
--------┼-------------------------------------------------┼----Positive| RELOCATION CANCEL ACKNOWLEDGEMENT
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
4.8.2
Subsequent Inter-MSC Relocation back to 3G_MSC-A
（3G_MSC-Aへの後続MSC間リロケーションバック）
When a Mobile Station is being relocated back to 3G_MSC-A, the procedure (described in TS 23.009) requires
interworking between Iu-Interface and E-Interface.
MSが3G_MSC-Aにリロケーションバックされた場合、（TS 23.009中で説明される）処理は、IuインタフェースとEインタ
フェース間のインターワーキングを必要とする。
The signalling at initiation, execution and completion of the Subsequent Inter-MSC relocation procedure is shown in
figures 55 to 59.
後続MSC間リロケーション処理の開始・実行・完了時のシグナリングについて、図55から図59に示す。
RNS-A
3G-MSC-B
3G-MSC-A
|
|
|
|RELOCATION
|
|
|-------------->|MAP PREPARE SUBSEQUENT
|
|REQUIRED
|------------------------>|
|
|HANDOVER request
|
|
|
|
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|------------------>|
Figure 55: Signalling for Subsequent Inter-MSC Relocation back to 3G_MSC-A initiation
図55：3G_MSC-Aへの後続MSC間リロケーションバック開始のシグナリング
3GPP
Release 1999
109
3GPP TS 29.010 V3.10.0 (2002-12)
Possible Positive outcomes: successful radio resources allocation:
想定される処理の成功：無線リソース割当に成功
RNS-A
3G-MSC-B
3G-MSC-A
RNS-B
|
|
|
|
|
|
|RELOCATION REQUEST |
|
|
|<------------------|
|
|
|ACKNOWLEDGE
|
|
| MAP PREPARE SUBSEQUENT |
|
|
|<------------------------|
|
|
| HANDOVER response
|
|
|RELOCATION COMMAND
|
|
|<--------------|
|
|
Figure 56: Signalling for Subsequent Inter-MSC Relocation back to 3G_MSC-A execution (Positive
outcome)
図56：3G_MSC-Aへの後続MSC間リロケーションバック実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
a)
user error detected, or component rejection or dialogue abortion performed by 3G_MSC-A:
ユーザエラーの検出、または3G_MSC-Aがコンポーネント拒否、またはダイヤログ中断を実行：
RNS-A
3G-MSC-B
3G-MSC-A
|
|MAP PREPARE SUBSEQUENT HANDOVER
|
|<------------------------|
|RELOCATION PREP|
response negative result
|<--------------|
|
|FAILURE (Note 1)
|
|
|
|
RNS-B
|
|
|
|
|
|
b) component rejection or dialogue abortion performed by 3G_MSC-A:
3G_MSC-Aがコンポーネント拒否、またはダイヤログ中断を実行：
RNS-A
3G-MSC-B
3G-MSC-A
|
|MAP CLOSE, MAP U/P ABORT |
|
|<------------------------|
|IU RELEASE COMMAND
|
|<--------------|
|
|
|
|
c)
RNS-B
|
|
|
|
|
radio resources allocation failure:
無線リソース割当の失敗：
RNS-A
3G-MSC-B
3G-MSC-A
RNS-B
|
|
| RELOCATION FAILURE|
|
|
|<------------------|
|
|MAP PREPARE SUBSEQUENT
|
|
|
|<------------------------|
|
|RELOCATION PREP|
HANDOVER response
|
|
|<--------------|
|
|
|FAILURE
|
|
|
3GPP
Release 1999
110
3GPP TS 29.010 V3.10.0 (2002-12)
d) radio resources allocation partial failure (3G_MSC-A decides to reject the relocation):
無線リソース配置実行の部分的失敗（3G_MSC-Aがリロケーション拒否を決定）：
RNS-A
3G-MSC-B
3G-MSC-A
RNS-B
|
|
| RELOCATION REQUEST|
|
|
|<------------------|
|
|MAP PREPARE SUBSEQUENT
|
ACK
|
|
|<------------------------|
|
|RELOCATION PREP|
HANDOVER response
|
|
|<--------------|
|
|
|FAILURE
|
|
|
e)
unsuccessful relocation execution (relocation cancelled):
リロケーション実行の失敗（リロケーションのキャンセル）：
RNS-A
3G-MSC-B
3G-MSC-A
RNS-B
|RELOCATION
|
|
|
|-------------->|
|
|
|CANCEL
|MAP PROCESS ACCESS
|
|
|
|------------------------>|
|
|
|
SIGNALLING request
|IU RELEASE COMMAND |
|
|
|------------------>|
|
|
|IU RELEASE COMPLETE|
|
|
|<------------------|
|
|MAP FORWARD ACCESS
|
|
|
|<------------------------|
|
| RELOCATION
|
SIGNALLING request
|
|
|<--------------|
|
|
|CANCEL ACK
|
|
|
Figure 57: Signalling for Subsequent Inter-MSC Relocation back to 3G_MSC-A execution
(Negative outcome)
図57：3G_MSC-Aへの後続MSC間リロケーションバック実行のシグナリング（処理の失敗）
RNS-A
3G-MSC-B
3G-MSC-A
RNS-B
|
|
|
|
|
|
|RELOCATION
|
|
|MAP SEND END SIGNAL
|<------------------|
|
|<------------------------|COMPLETE
|
|
| response
|
|
|IU RELEASE CMD |
|
|
|<--------------|
|
|
Figure 58: Signalling for Subsequent Inter-MSC Relocation back to 3G_MSC-A completion
(Successful completion of the procedure)
図58：3G_MSC-Aへの後続MSC間リロケーションバック完了のシグナリング（処理の成功による完了）
NOTE:
Positive outcome case shown in figure 53.
処理が成功した場合については図53に示される。
RNS-A
|
|
|
|
|
|
3G-MSC-B
3G-MSC-A
RNS-B
|
|
|
|MAP U/P -ABORT
|
|
|<------------------------|
|
|
|IU RELEASE COMMAND |
|
|------------------>|
|
|(Note 1)
|
Figure 59: Signalling for Subsequent Inter-MSC Relocation back to 3G_MSC-A completion
(Unsuccessful completion of the procedure)
図59：3G_MSC-Aへの後続MSC間リロケーションバック完了のシグナリング（処理の失敗による完了）
3GPP
Release 1999
NOTE:
111
3GPP TS 29.010 V3.10.0 (2002-12)
Abnormal end of the procedure that triggers the clearing of all resources in 3G_MSC-B.
処理の異常終了は、3G_MSC-B内の全リソースのクリアをトリガする。
The interworking between Prepare Subsequent Handover and RELOCATION REQUIRED is as follows:
Prepare Subsequent Handover とRELOCATION REQUIRED 間のインターワーキングについて以下に示す：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward |REL. REQUIRED
MAP PREPARE SUBSEQUENT HANDOVER|
message |
request
|
|
|
|
-target MSC number |
|
-target RNC Id
|
| RANAP information
-an-APDU(
| 1
|
elements
RELOCATION REQ)
|
|
|
|
|
--------┼-------------------------------------------------┼----Positive|
MAP PREPARE SUBSEQUENT HANDOVER|
result |
response
| 2
|
-an-APDU(
|
|RELOCATION CMD.
RELOCATION REQUEST |
|
ACKNOWLEDGE
|
|
or
|
|RELOCATION PREP FAILURE
RELOCATION FAILURE)|
|
|
--------┼-------------------------------------------------┼----Negative| REL. PREP. FAILURE
MAP PREPARE SUBSEQUENT|
result |
HANDOVER response
|
| Unspecified failure
Unknown MSC
|
| Unspecified failure
Subsequent Handover|
|
Failure |
| Unspecified failure
UnexpectedDataValue|
| Unspecified failure
Data Missing
|
|
|
| Iu RELEASE COMMAND
MAP CLOSE
|
|
MAP U/P –ABORT
|
| Unspecified failure
|
| Unspecified failure
|
|
|
NOTE 1: The processing performed on the RANAP information elements received in the RELOCATION
REQUIRED message is out of the scope of the present document. The target MSC number is provided to
3G_MSC-A by 3G_MSB-B based on the information received from RNS-B.
RELOCATION REQUIREDメッセージ中で受信したRANAP IE上で実行される処理については、本仕
様書のスコープ外である。target MSC番号は、RNS-Bから受信した情報に基づいて、3G_MSC-Bが
3G_MSC-Aに対して提供する。
NOTE 2: The response to the Prepare-Subsequent-Handover request can include in its an-APDU parameter,
identifying the 3GPP TS 25.413 protocol, a RANAP RELOCATION REQUEST ACKNOWLEDGE or a
RANAP RELOCATION FAILURE.
Prepare-Subsequent-Handover request に対する応答をそのan-APDU パラメータ中に含めて、3GPP TS
25.413 プロトコルがRANAP RELOCATION REQUEST ACKNOWLEDGE、RANAP RELOCATION
FAILUREのいずれかであるかを識別させることができる。
In the first case, the positive result triggers in 3G_MSC-B the sending on Iu-Interface of the
RELOCATION COMMAND.
一番目のケースでは、処理が成功すると、3G-MSC-B内でIuインタフェース上のRELOCATION
COMMAND送信がトリガされる。
3GPP
Release 1999
112
3GPP TS 29.010 V3.10.0 (2002-12)
In the second case, the positive result triggers in 3G_MSC-B the sending of the RELOCATION
PREPARATION FAILURE.
二番目のケースでは、処理が成功すると、3G_MSC-B内でRELOCATION PREPARATION FAILURE
の送信がトリガされる。
The interworking between RELOCATION CANCEL and MAP Process Signalling Request in 3G_MSC-A is as
follows:
3G_MSC-A内での、RELOCATION CANCELとMAP Process Signalling Request間のインターワーキングについて、
以下に示す：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PROCESS-SIGNALLING
IU RELEASE COMMAND |
message |
request
|
| -an-APDU(
|
| RELOCATION CANCEL)
|
|
|
--------┼-------------------------------------------------┼----Positive| MAP FORWARD-SIGNALLING
IU RELEASE COMPLETE|
result |
request
|
| -an-APDU(
|
| RELOCATION CANCEL ACK)
|
|
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
|
|
The interworking between RELOCATION CANCEL and MAP Process Signalling Request in 3G_MSC-B is as
follows:
3G_MSC-B内での、RELOCATION CANCELとMAP Process Signalling Request 間のインターワーキングは以下の
通り：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION CANCEL
MAP PROCESS-SIGNALLING |
message |
request
|
|
-an-APDU(
|
|
RELOCATION CANCEL)
|
|
|
--------┼-------------------------------------------------┼----Positive| RELOCATION CANCEL ACK
MAP FORWARD-SIGNALLING |
result |
request
|
|
-an-APDU(
|
|
RELOCATION CANCEL ACK)|
|
|
--------┼-------------------------------------------------┼----Negative|
|
result |
|
|
|
3GPP
Release 1999
113
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between Send End Signal Result and RELOCATION COMPLETE in 3G_MSC-A is as follows:
3G_MSC-A内での、Send End Signal ResultとRELOCATION COMPLETE間のインターワーキングは以下の通り：
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RELOCATION COMPLETE MAP SEND END SIGNAL
|
message |
response
|
|
|
--------┼-------------------------------------------------┼----Positive|
|
result |
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT
| 1
NOTE:
4.8.3
The abortion of the dialogue ends the relocation procedure with 3G_MSC-B.
ダイヤログの中断によって、3G_MSC-Bとのリロケーション処理が終了する。
Subsequent Inter-MSC Relocation to third MSC
（第3のMSCに対する後続MSC間リロケーション）
When a Mobile Station is being relocated to a third MSC, the procedure (described in 3GPP TS 23.009) does require
one specific interworking case in 3G_MSC-A (figure 64) between E-Interface from 3G_MSC-B and E-Interface from
3G_MSC-B' other than the combination of the ones described in the subclause 4.8.1 and 4.8.2.
MSが第3のMSCにリロケーションされた場合、（TS 23.009中で説明される）処理は、4.8.1 節および4.8.2節中に説明
されたケースの組合せを除いて、3G_MSC-A内で3G_MSC-BからのEインタフェースと3G_MSC-B'からのEインタフェ
ース間である特別なインターワーキングのケースを必要とする（図64）。
RNS-A
3G-MSC-B
3G-MSC-A
3G-MSC-B'
|
|
|
|
|RELOCATION |
|
|
|----------->|MAP PREPARE SUBSEQUENT|
|
|REQUIRED
|--------------------->|
|
|
|HANDOVER request
|MAP PREPARE
|
|
|
|--------------->|
|
|
|HANDOVER request|
|
|
|
|+-------+
|
|
|
||Possib.|
|
|
|
||Alloc. |
|
|
|
||of relo|
|
|
|
||number |
|
|
|
|| VLR-B |
|
|
|
|+-------+
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|-------->|
|
|
|
|REQUEST |
|
|
|
|
|
Figure 60: Signalling for Subsequent Inter-MSC Relocation to third MSC (3G_MSC-B') initiation
図60：第3のMSC(3G_MSC-B') に対する後続MSC間リロケーション開始のシグナリング
3GPP
Release 1999
114
3GPP TS 29.010 V3.10.0 (2002-12)
Possible Positive outcomes: successful radio resources allocation:
想定される処理の成功：無線リソース割当に成功：
RNS-A
3G-MSC-B
3G-MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|<--------|
|
|
|
|REQUEST |
|
|
|
ACKNOWLEDGE
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT|
response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| RELOCATION |
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
|
|
|
|
|
Figure 61: Signalling for Subsequent Inter-MSC Relocation to third MSC (3G_MSC-B') execution
(Positive outcome)
図61：第3のMSC(3G_MSC-B') に対する後続MSC間リロケーション実行のシグナリング（処理の成功）
Possible Negative outcomes:
想定される処理の失敗：
a)
user error detected, or component rejection or dialogue abortion performed by 3G_MSC-B':
ユーザエラーの検出、またはMSC-Bがコンポーネント拒否、またはダイヤログ中断を実行：
RNS-A
3G-MSC-B
3G-MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|MAP PREPARE HANDOVER
|
|
|
|response negative result |
|
|
|MAP CLOSE
|
|
|
|
|<---------------|
|
|
|
|MAP U/P -ABORT |
|
|
|MAP PREPARE SUBSEQUENT|
|
|
|
|<---------------------|
|
|
|
|HANDOVER response negative
|
|
| RELOCATION |result
|
|
|
|<-----------|
|
|
|
| PREPARATION|
|
|
|
| FAILURE
|
|
|
|
|
|
|
|
|
3GPP
Release 1999
115
3GPP TS 29.010 V3.10.0 (2002-12)
b) radio resources allocation failure:
無線リソース割当の失敗：
RNS-A
3G-MSC-B
3G-MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|<--------|
|
|
|
|FAILURE |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT| response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| RELOCATION |
|
|
|
|<-----------|
|
|
|
| PREPARATION|
|
|
|
| FAILURE
|
|
|
|
|
|
|
|
|
c)
radio resources allocation partial failure (3G_MSC-A decides to reject the relocation):
無線リソース割当の部分的失敗（3G_MSC-A がリロケーションの拒否を決定）：
RNS-A
3G-MSC-B
3G-MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|<--------|
|
|
|
|REQ ACK |
|
|
|
|
|
|
|
|MAP PREPARE HANDOVER
|
|
|
|<---------------|
|
|
|MAP PREPARE SUBSEQUENT| response
|
|
|
|<---------------------|
|
|
|
|HANDOVER response
|
|
|
| RELOCATION |
|
|
|
|<-----------|
|
|
|
| PREPARATION|
|
|
|
| FAILURE
|
|
|
|
|
|
|
|
|
Figure 62: Signalling for Subsequent Inter-MSC Relocation to third MSC (3G_MSC-B') execution
(Negative outcome)
図62：第3のMSC(3G_MSC-B') への後続MSC間リロケーション実行のシグナリング（処理の失敗）
3GPP
Release 1999
116
3GPP TS 29.010 V3.10.0 (2002-12)
Positive outcome:
処理の成功：
RNS-A
3G-MSC-B
3G-MSC-A
3G-MSC-B'
|
|
|
|
|
|
|
|
RNS-B'
|
|
|
|
|
|
|
|
|RELOCATION
|
|
|
|<--------|
|
|
|
|COMPLETE |
|
|
|
|
|
|
|
|MAP SEND END SIGNAL
|
|
|
|<---------------|
|
|
| MAP SEND END SIGNAL |request
|
|
|
|<---------------------|
|
|
|
| response
|
|
|
| IU RELEASE |
|
|
|
|<-----------|
|
|
|
| COMMAND
|
|
|
|
Figure 63: Signalling for Subsequent Inter-MSC Relocation to third MSC (3G_MSC-B') completion
(Successful completion of the procedure)
図63：第3のMSC(3G_MSC-B') への後続MSC間リロケーション完了のシグナリング（処理の成功による完了）
Negative outcome:
処理の失敗：
RNS-A
3G-MSC-B
3G-MSC-A
3G-MSC-B'
|
|
|
|
|RELOCATION |
|
|
RNS-B'
|----------->|
|
|
|
|CANCEL
|MAP PROCESS ACCESS
|
|
|
|
|--------------------->|
|
|
|
|SIGNALLING request (Note 1)
|
|
|
|
|
|
|
|
|
|MAP U -ABORT
|
|
|
|
|--------------->|
|
|
|MAP FORWARD ACCESS
|
|IU RELEASE
|
|<---------------------|
|-------->|
|RELOCATION | SIGNALLING request
|
|COMMAND |
|<-----------|
|
|
|
|CANCEL ACK |
|
|
|
|
|
|
|
|
Figure 64: Signalling for Subsequent Inter-MSC Relocation to third MSC (3G_MSC-B') completion
(Unsuccessful completion of the procedure)
図64：第3のMSC(3G_MSC-B') への後続MSC間リロケーション完了のシグナリング（処理の失敗による完了）
NOTE:
Specific interworking case detailed below.
特定のインターワーキングのケースについて、以下に述べる。
3GPP
Release 1999
117
3GPP TS 29.010 V3.10.0 (2002-12)
The specific interworking case in 3G_MSC-A compared to the subclauses 4.8.1 and 4.8.2 occurs between
RELOCATION FAILURE encapsulated in a Process Access Signalling from 3G_MSC-B and the abortion of the
dialogue with 3G_MSC-B' in the case of relocation cancelled:
リロケーションがキャンセルされた場合、4.8.1節および4.8.2節中に説明されたケースとは異なり、3G_MSC-Bからの
Process Access Signalling 内にカプセル化されたRELOCATION FAILURE と、3G_MSC-B' とのダイヤログの中断
の間に、3G_MSC-A内で特別なインターワーキングが起きるケースがある。
---------------------------------------------------------------|
29.002
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | MAP PROCESS-SIGNALLING
|
message |
request
|
|
|
|
-an-APDU(
MAP U -ABORT
| 1
|
RELOCATION CANCEL)
|
|
|
--------┼-------------------------------------------------┼----Positive| MAP FORWARD-SIGNALLING
|
result |
request
|
|
-an-APDU(
|
|
RELOCATION CANCEL ACK)
|
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP U/P -ABORT | 2
|
|
NOTE 1: The abortion of the dialogue triggers in 3G_MSC-B' the clearing of the circuit connection with 3G_MSCA, if any, and of the Resources between 3G_MSC-B' and RNS-B'. The abortion of the dialogue ends the
relocation procedure with 3G_MSC-B'.
ダイヤログの中断は3G_MSC-B' 内で、3G_MSC-Aとの回線交換コネクションが存在する場合にはそ
のクリアと、3G_MSC-B' とRNS-B'間のリソースのクリアをトリガする。ダイヤログの中断によって、
3G_MSC-B'とのリロケーション処理は中断する
NOTE 2: The abortion of the dialogue ends the relocation procedure with 3G_MSC-B.
ダイヤログの中断により、3G_MSC-Bとのリロケーション処理は終了する。
4.8.4
RANAP Messages transfer on E-Interface
（Eインタフェース上でのRANAPメッセージの送信）
The following mapping applies to the encapsulation performed in 3G_MSC-A.
3G_MSC-A内で実行されるカプセル化に関しては、以下のマッピングが適用される。
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RANAP messages
MAP FORWARD ACCESS SIGNALLING|
message |
request
| 1
|
|
|
-an-APDU (RANAP messages) |
--------┼-------------------------------------------------┼----Positive|
|
result |
| 2
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP CLOSE
|
|
MAP U/P -ABORT
|
|
|
NOTE 1: Complete RANAP messages to be sent on 3G_MSC-B - RNS-B interface are embedded into the anAPDU parameter.
3G_MSC-B～RNS-B間インタフェース上で送信すべきComplete RANAPメッセージは、an-APDUパラメ
ータにエンベッドされる。
3GPP
Release 1999
118
3GPP TS 29.010 V3.10.0 (2002-12)
NOTE 2: The Return Result does not apply. If 3G_MSC-B returns a message, this message will arrive in an Invoke:
Process Access Signalling.
Return Result は適用されない。3G_MSC-Bがメッセージを返す場合、本メッセージはInvoke: Process
Access Signalling中に到達する。
The following mapping applies to the encapsulation performed in 3G_MSC-B.
3G_MSC-B内で実行されるカプセル化に関しては、以下のマッピングが適用される
---------------------------------------------------------------|
25.413
29.002
|Notes
--------┼-------------------------------------------------┼----Forward | RANAP messages
MAP PROCESS ACCESS SIGNALLING|
message |
request
| 1
|
|
|
-an-APDU (RANAP messages) |
--------┼-------------------------------------------------┼----Positive|
|
result |
| 2
--------┼-------------------------------------------------┼----Negative|
|
result |
MAP CLOSE
|
| IU RELEASE COMMAND
|
|
|
| Unspecified failure
MAP U/P -ABORT
| 3
|
|
NOTE 1: Complete RANAP messages to be sent to 3G_MSC-A are embedded into the an-APDU parameter.
3G_MSC-Aに送信すべきComplete RANAPメッセージは、an-APDUパラメータにエンベッドされる。
NOTE 2: The Return Result does not apply. If 3G_MSC-A returns a message, this message will arrive in an
Invoke: Forward Access Signalling.
Return Result は適用されない。3G_MSC-Aがメッセージを返す場合、本メッセージはInvoke: Forward
Access Signalling中に到達する。
NOTE 3: The abortion of the dialogue triggers the clearing of the circuit connection with 3G_MSC-A, if any, of the
Radio Resources on the Iu-Interface and the release of the SCCP connection between 3G_MSC-B and
RNS-B. The clearing of the Radio Resources (the clearing indication received from RNS-B is transmitted
to 3G_MSC-A) or the loss of the SCCP connection between 3G_MSC-B and RNS-B, triggers in
3G_MSC-B the abortion of the dialogue on the E-Interface and the clearing of the circuit connection with
3G_MSC-A, if any.
ダイヤログが中断された場合、3G_MSC-Aとの回線交換コネクションの開放と、もしあればIuインタフェ
ース上での無線リソースの開放と、3G_MSC-B とRNS-B間のSCCPコネクションの開放がトリガされ
る。無線リソースのクリア（RNS-Bから受信したクリア通知は3G_MSC-Aに送信される）、または
3G_MSC-B～RNS-B間のSCCPコネクションの消失によって、3G_MSC-B内で、Eインタフェース上での
ダイヤログの中断と、もしあれば3G_MSC-Aとの回線交換コネクションのクリアがトリガされる。
4.8.5
Processing in 3G_MSC-B, and information transfer on E-interface
（3G_MSC-B内のプロセスと、Eインタフェース上の情報の送信）
The following parameters require processing (e.g. to store the parameter, to internally generate the parameter) in
3G_MSC-B. The relevant RANAP procedures are mentioned to ease the comprehension, their detailed description is
the scope of the TS 25.413. Each RANAP message being transferred on E-interface shall use the mechanisms given in
subclause 4.8.4 and is described in TS 25.413.
以下のパラメータは、3G_MSC-B内の処理（例えばパラメータの保存や、パラメータの内部生成）を要求する。関連す
るRANAP処理の詳細な説明については、理解を容易にするために、TS 25.413のスコープとする。Eインタフェース上
で送信される各RANAPメッセージは、4.8.4節で与えられるメカニズムを使用すること。それらについては、TS 25.413
に記載されている。
3GPP
Release 1999
4.8.5.1
119
3GPP TS 29.010 V3.10.0 (2002-12)
Integrity Protection Information（完全性保護情報）
A sequence of possible integrity protection algorithms can be sent to an RNS in Security Mode Command or Relocation
Request. The RNS chooses one of the listed algorithms and reports this back to the 3G_MSC in Security Mode
Complete or Relocation Request Acknowledge respectively.
想定される完全性保護アルゴリズムのシーケンスは、Security Mode CommandまたはRelocation Request中に入れて
RNSに送信することができる。RNSはアルゴリズムのリストから1つを選択し、それをSecurity Mode Complete または
Relocation Request Acknowledgeの中に入れて3G_MSCにレポートバックする。
The list of algorithms, the integrity protection key and the chosen algorithm shall be stored by 3G_MSC-B.
3G_MSC-Bは、アルゴリズムのリスト、完全性保護鍵、そして選択されたアルゴリズムを保存すること。
Transfer of Information:
情報の送信：
If integrity protection has not been performed before Inter-MSC Relocation, this will be controlled by 3G_MSCA after the completion of Inter-MSC Relocation.
MSC間リロケーション前に完全性保護が実行されなかった場合、完全性保護はMSC間リロケーション完了後
に3G_MSC-Aによって制御される：
Integrity protection control towards 3G_MSC-B:
3G_MSC-Bに対する完全性保護の制御：
If Integrity protection has been performed before Inter-MSC Relocation:
MSC間リロケーション前に完全性保護が実行された場合：
-
in the Relocation Request RANAP message (information included).
（情報が含まれる）Relocation Request RANAPメッセージ中
The Relocation Request Acknowledge should in this case contain the indication of the chosen algorithm.
本ケースにおけるRelocation Request Acknowledgeは、選択されたアルゴリズムの通知を含むこと。
If Integrity protection has NOT been performed before Inter-MSC Relocation:
完全性保護がMSC間リロケーション前に実行されなかった場合：
-
4.8.5.2
in the Security Mode Command procedure between 3G_MSC-A and 3G_MSC-B.
3G_MSC-Aと3G_MSC-B間のSecurity Mode Command 処理中
Encryption Information
A sequence of possible encryption algorithms can be sent to an RNS in Security Mode Command or Relocation
Request. The RNS chooses one of the listed algorithms and reports this back to the 3G_MSC in Security Mode
Complete or Relocation Request Acknowledge respectively.
想定される暗号化アルゴリズムのシーケンスは、Security Mode CommandまたはRelocation Request中でRNSに対し
て送信することができる。RNSはアルゴリズムのリストから1つを選択し、それをin Security Mode Complete または
Relocation Request Acknowledge 中に入れて3GのMSCにレポートバックする。
The list of algorithms, the ciphering key and the chosen algorithm shall be stored by 3G_MSC-B, and the chosen value
sent to 3G_MSC-A.
3G_MSC-Bは、アルゴリズムと暗号鍵のリストと選択されたアルゴリズムを保存し、選択された値を3G_MSC-Aに対
して送信する。
Transfer of Information:
情報の送信：
If ciphering has not been performed before Inter-MSC Relocation, this will be controlled by 3G_MSC-A after
the completion of Inter-MSC Relocation.
MSC間リロケーション前に暗号化が実行されなかった場合、MSC間リロケーション完了後に3G_MSC-Aが暗
号化を制御する：
3GPP
Release 1999
120
3GPP TS 29.010 V3.10.0 (2002-12)
Ciphering control towards 3G_MSC-B:
3G_MSC-Bに対する暗号化制御：
If Ciphering has been performed before Inter-MSC Relocation:
MSC間リロケーション前に暗号化が実行された場合：
-
in the Relocation Request RANAP message (information included).
（情報が含まれる）Relocation Request RANAPメッセージ中
The Relocation Request Acknowledge should in this case contain the indication of the chosen algorithm.
本ケースにおけるRelocation Request Acknowledgeは、選択されたアルゴリズムの通知を含むこと。
If Ciphering has NOT been performed before Inter-MSC Relocation:
暗号化がMSC間リロケーション前に実行されなかった場合：
-
4.8.5.3
in the Security Mode Command procedure between 3G_MSC-A and 3G_MSC-B.
3G_MSC-Aと3G_MSC-Bとの間のSecurity Mode Command処理中
RAB Parameters（RABパラメータ）
The parameters shall be stored by 3G_MSC-B to be used at internal Relocation in 3G_MSC-B.
3G_MSC-Bは、内部でリロケーションを行なう際に使用するために、パラメータを保存すること。
Transfer of information:
情報の送信：
Received by 3G_MSC-B from 3G_MSC-A in:
3G_MSC-B は、3G_MSC-A から次のメッセージ内で受信する：
−
The Relocation Request RANAP message.
Relocation Request RANAPメッセージ
If a new type of resource is to be assigned after Inter-MSC Relocation, this can be made with:
MSC間リロケーション後に新たなタイプのリソースを割当てるべき場合には、次のメッセージと一緒に受信す
ることも可能：
−
4.8.5.4
The RAB Assignment Request RANAP message.
RAB Assignment Request RANAPメッセージ
Channel Type（チャネルタイプ）
Channel Type is GSM information that is required in BSSMAP Handover Request and BSSMAP Assignment Request,
and it shall be provided by 3G_MSC-A. 3G_MSC-B needs this information in case of an intra-MSC UMTS to GSM
handover after an inter-MSC relocation and subsequent assignment procedures. The Channel Type derived from the
Bearer Capability that is available in 3G_MSC-A. This mapping is described in 3GPP TS 27.001. Therefore 3G_MSCA must provide this information in case of an inter-MSC relocation. The Radio Resource Information IE in the MAP
Prepare Handover message refers to the Channel Type GSM information.
Channel TypeはGSMの情報であり、BSSMAP Handover Request およびBSSMAP Assignment Request中で要求さ
れ、3G_MSC-Aが提供すること。MSC間リロケーション処理と後続割当処理が行われた後に、UMTSからGSMへの
MSC間ハンドオーバが行なわれる場合に、3G_MSC-Bは本情報を必要とする。Bearer Capability から取得した
Channel Typeは、3G_MSC-A内で有効である。本マッピングについては、3GPP TS 27.001に記載される。それゆえ
に、MSC間リロケーションの場合には、3G_MSC-Aが本情報を提供する必要がある。MAP Prepare Handoverメッセ
ージ中のRadio Resource Information IE は、Channel Type GSM情報を参照する。
3GPP
Release 1999
121
3GPP TS 29.010 V3.10.0 (2002-12)
Channel Type shall be stored by 3G_MSC-B.
3G_MSC-BはChannel Type を保存すること。
Transfer of information:
情報の送信：
Received by 3G_MSC-B from 3G_MSC-A in:
3G_MSC-Bは、3G_MSC-A から以下のメッセージ中で情報を受信する：
−
The Prepare Handover Request MAP message
Prepare Handover Request MAPメッセージ
−
The Forward Access Signalling Request message.
Forward Access Signalling Requestメッセージ
4.8.5.5
Selected GSM Algorithm（選択されたGSMアルゴリズム）
After inter-MSC relocation, the 3G_MSC-B can perform intra-MSC UMTS to GSM handover. A sequence of possible
encryption algorithms, received from the 3G_MSC-A, can be sent to an BSS in Handover Request or in Cipher Mode
Command in case of cipher mode setting after intra.MSC-B handover from UMTS to GSM. The BSS chooses one of
the listed algorithms and reports this back to the 3G_MSC in Handover Request Acknowledge or Cipher Mode
Complete respectively. The MSC-B provides the Selected GSM algorithm information to the MSC-A. The Selected
GSM algorithms IE in the MAP Process Access Signalling Request message refers to the Algorithm identifier octet in
the Chosen Encryption Algorithm GSM information.
MSC間リロケーション後に、3G_MSC-BはUMTSからGSMへのMSC内ハンドオーバを実行することができる。UMTS
からGSMへのMSC-B内ハンドオーバ後に暗号化モードを設定する場合には、3G_MSC-Aから受信した想定される
暗号化アルゴリズムのシーケンスを、Handover Request またはCipher Mode Command 中でBSSに送信することが
できる。BSSはアルゴリズムのリストから1つを選択し、それをHandover Request Acknowledge または Cipher Mode
Completeの中に入れて3GのMSCに対してレポートバックする。MSC-B はSelected GSM algorithm情報を、MSC-A
に対して提供する。MAP Process Access Signalling Request メッセージ中のSelected GSM algorithms IEは、Chosen
Encryption Algorithm GSM情報中のアルゴリズム識別オクテット（Algorithm identifier octet）を参照する。
The chosen algorithm shall be stored by 3G_MSC-B, and sent to 3G_MSC-A.
3G_MSC-Bは選択されたアルゴリズムを保存し、3G_MSC-Aに送信する。
Transfer of Information:
情報の送信：
If ciphering has not been performed before Inter-MSC Relocation, this will be controlled by 3G_MSC-A after
the completion of Inter-MSC Relocation.
MSC間リロケーション前に暗号化が実行されなかった場合、MSC間リロケーション完了後に3G_MSC-Aが暗
号化を制御する：
If Ciphering has been performed before Inter-MSC Relocation, Selected GSM algorithm information is received
by 3G_MSC-A from 3G_MSC-B in:
MSC間リロケーション前に暗号化が実行された場合、3G_MSC-Aは3G_MSC-Bから、次のメッセージ内で
Selected GSM algorithm informationを受信する：
−
The Handover Performed BSSMAP message.
Handover Performed BSSMAP メッセージ
If Ciphering has NOT been performed before Intra-MSC-B handover from UMTS to GSM after Inter-MSC
Relocation, Selected GSM algorithm information is received by 3G_MSC-A from 3G_MSC-B in:
MSC間リロケーション後、UMTSからGSMへのMSC-B内ハンドオーバ前に暗号化が実行されなかった場
合には、3G_MSC-Aは3G_MSC-Bから、次のメッセージ中でSelected GSM algorithm information を受信
する：
3GPP
Release 1999
−
122
3GPP TS 29.010 V3.10.0 (2002-12)
The Process Access Signalling Request MAP message.
Process Access Signalling Request MAP メッセージ
4.8.5.6
Allowed GSM Algorithms（許容されたGSMアルゴリズム）
Allowed GSM algorithms is GSM information that is required in BSSMAP Handover Request and BSSMAP Cipher
Mode Command, and shall be provided by 3G_MSC-A. 3G_MSC-B needs this information in case of an intra-MSC
UMTS to GSM handover and in subsequent ciphering mode setting, after an inter-MSC relocation. Therefore 3G_MSCA must provide this information in case of an inter-MSC relocation. The Allowed GSM algorithms IE in the MAP
Prepare Handover and in the MAP Forward Access Signalling Request messages refers to the Algorithm identifier octet
in the Permitted Algorithms GSM information.
Allowed GSM algorithmsはGMSの情報であり、BSSMAP Handover RequestとBSSMAP Cipher Mode Command中で
要求され、3G_MSC-Aが提供すること。UMTSからGSMへのMSC内ハンドオーバと、それに続く暗号化モードの設定
において、3G_MSC-Bは本情報を必要とする。であるから、MSC間リロケーションの場合には、3G_MSC-Aが本情報
を提供する必要がある。MAP Prepare HandoverおよびMAP Forward Access Signalling Request メッセージ中の
Allowed GSM algorithmsは、Permitted Algorithms GSM情報中のアルゴリズム識別オクテット（Algorithm identifier
octet）を参照する。
Allowed GSM algorithms shall be stored by 3G_MSC-B.
3G_MSC-Bは、Allowed GSM algorithms を保存すること。
Transfer of information:
情報の送信：
If ciphering has not been performed before Inter-MSC Relocation, this will be controlled by 3G_MSC-A after
the completion of Inter-MSC Relocation.
MSC間リロケーション前に暗号化が実行されなかった場合、MSC間リロケーション完了後に3G_MSC-Aが暗
号化を制御する：
Ciphering control towards 3G_MSC-B:
3G_MSC-Bに対する暗号化の制御：
If Ciphering has been performed before Inter-MSC Relocation:
MSC間リロケーション前に暗号化が実行された場合：
−
The Prepare Handover Request MAP message.
Prepare Handover Request MAPメッセージ
If Ciphering has NOT been performed before Inter-MSC Relocation:
MSC間リロケーション前に暗号化が実行されなかった場合：
−
The Forward Access Signalling Request MAP message.
Forward Access Signalling Request MAP メッセージ
4.8.5.7
Chosen Channel（選択されたチャネル）
BSSMAP Assignment Request may give the BSS some freedom in the selection of radio resource (for instance channel
rate selection, speech version selection etc.). Chosen Channel and/or Speech Version is reported back to 3G_MSC-B in
BSSMAP Assignment Complete. The Chosen Radio Resource Information IE in the MAP Prepare Handover Response
and Process Access Signalling Request messages refers to the Chosen Channel and/or Speech Version GSM
information.
BSSMAP Assignment Requestを使用することによって、無線リソース（例えばチャネルレートの選択、スピーチバージ
ョンの選択など）の選択に関してBSSに、ある程度の自由を与えることもできる。選択されたチャネル および／また
は スピーチバージョンは、BSSMAP Assignment Complete中で3G_MSC-Bに対してレポートバックされる。MAP
Prepare Handover ResponseメッセージおよびProcess Access Signalling Requestメッセージ中のChosen Radio Resource
Information IEは、Chosen Channel および／または Speech Version GSM情報を参照する。
3GPP
Release 1999
123
3GPP TS 29.010 V3.10.0 (2002-12)
The Channel Type and the characteristics of the chosen channel shall be stored by 3G_MSC-B, and the Chosen Channel
and/or Speech Version information elements shall be transferred to MSC-A or 3G_MSC-A.
Channel Type および選択されたチャネルのキャラクタは、3G_MSC-Bによって保存され、Chosen Channel および／
または Speech Version は、MSC-A または 3G_MSC-Aに対して送信されること。
Transfer of information:
情報の送信：
Received by MSC-A or 3G_MSC-A from 3G_MSC-B in:
MSC-A または 3G_MSC-Aは、3G_MSC-Bから次のメッセージ内で情報を受信する：
−
The Prepare Handover Response MAP message
Prepare Handover Response MAP メッセージ
−
The Process Access Signalling request MAP message
Process Access Signalling request MAPメッセージ
4.8.5.8
BSSMAP Service Handover（BSSMAP Service Handover）
This information shall be stored by 3G_MSC-B and sent to a BSS in Handover Request, when 3G_MSC-B performs
handover to GSM.
本情報は、3G_MSC-Bによって保存され、3G_MSC-BがGSMへのハンドオーバを実行する際にHandover Request中
に入れてBSSに送信すること。
Transfer of information:
情報の送信：
The BSSMAP Service Handover information is transferred to 3G_MSC-B in:
BSSMAP Service Handover情報は、次のメッセージ中で3G_MSC-B に対して送信される。
− the Prepare Handover Request MAP message.
Prepare Handover Request MAPメッセージ
If a new assignment of a TCH after an inter-MSC relocation is to be performed, the BSSMAP Service Handover
information is transferred to 3G_MSC-B in:
MSC間リロケーション後に新たにTCH割当てを実行すべき場合には、BSSMAP Service Handover情報は次の
メッセージ中で3G_MSC-B に送信される：
− the Forward Access Signalling Request MAP message
Forward Access Signalling Request MAPメッセージ
and sent by 3G_MSC-B to the BSS in the Assignment Request BSSMAP message.
本情報は、3G_MSC-BがAssignment Request BSSMAPメッセージ中でBSSに対して送信する。
4.8.5.9
RANAP Service Handover（RANAP Service Handover）
This information shall be stored by 3G_MSC-B and sent to an RNS in Relocation Request during the basic inter-MSC
relocation or when 3G_MSC-B performs a subsequent intra-MSC relocation or handover to UMTS.
本情報は3G_MSC-B によって保存され、基本MSC間リロケーションの間、あるいは3G_MSC-Bが後続MSC間リロケ
ーションまたはUMTSへのハンドオーバを実行した際に、Relocation Request 中でRNSに送信される。
Transfer of information:
情報の送信：
The RANAP Service Handover information is transferred to 3G_MSC-B in:
RANAP Service Handover情報は、次のメッセージ中で3G_MSC-B に送信される：
3GPP
Release 1999
124
3GPP TS 29.010 V3.10.0 (2002-12)
− the Relocation Request RANAP message.
Relocation Request RANAPメッセージ
If a new assignment of a Radio Access Bearer after an inter-MSC relocation is to be performed, the information
is transferred to 3G_MSC-B in:
MSC間リロケーション後に新たにRAB（Radio Access Bearer）割当を実行すべき場合には、情報は次の処理
中で3G_MSC-Bに送信される：
− the RANAP RAB Assignment procedure.
RANAP RAB Assignment 処理
−
3GPP
Release 1999
4.8.6
125
3GPP TS 29.010 V3.10.0 (2002-12)
Overview of the Technical Specifications 3GPP interworking for the Inter-MSC Relocation
（MSC間リロケーションに関する3GPP技術仕様書のインターワーキングの概要）
╔══════════════════════════════════════════════════════════════════════════════════════════════════╗
║ PSTN/ISDN
║
║
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
║
║
▒
+---------------+
▒
║
║ ==============▒====== | ============= | ===============
▒
║
║ UMTS
▒
|
|
▒
║
║
▒
V
V
▒
║
║ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒
║
║ ▒ RNS-A
3G-MSC-A
3G-MSC-B
RNS-B
▒
MS
║
║ ▒
▒
║
║ ▒
+-------+
▒ +-------+
║
║ ▒
| C M |
24.008
▒ | C M |
║
║ ▒
+-------|<------------------------------------>+-------|
║
║ ▒ ░░░░░░░░░░░░░░░ | M M | ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒ | M M |
║
║ ▒ ░+------+25.413 +-------| 25.413+-------+ 25.413+-------+ ░▒ +-------|
║
║ ▒ ░| R R |<----->| R R |<=====>| R R |<----->| R R | ░▒ | R R |
║
║ ▒ ░+------+
+-------+
+-------+
+-------+ ░▒ +-------+
║
║ ▒ ░
Λ Λ
Λ Λ
░▒
║
║ ▒ ░
|
|
29.010 | |
░▒
║
║ ▒ ░
|
V
V |
░▒
║
║ ▒ ░
|+-----+ 29.002+-----+|
░▒
║
║ ▒ ░
||MAP/E|<----->|MAP/E||
░▒
║
║ ▒ ░
|+-----+
+-----+|
23.009░▒
║
║ ▒ ░░░░░░░░░░░░░░░░ | ░░░░░░░░░░░░░░░░░░░ | ░░░░░░░░░░░░░░░░░░░▒ Remark: The RRC interface and ║
║ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ V ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ V ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
the link layer
║
║
+-----------------------+
protocols being out of ║
║
|
T C A P
|
the scope of this
║
║
+-----------------------+
Specification are not ║
║
+------------------------------------------------------+
shown here.
║
║
|
S C C P
|
║
║
+------------------------------------------------------+
║
║
+------------------------------------------------------+
║
║
|
M T P
|
║
║
+------------------------------------------------------+
║
╚══════════════════════════════════════════════════════════════════════════════════════════════════╝
3GPP
Release 1999
127
3GPP TS 29.010 V3.10.0 (2002-12)
4.9 Location Services（位置情報サービス）
The general principles of the location services procedures are given in Technical Specification 3GPP TS 23.071 and 3GPP
TS 23.171.
位置情報サービスの原則については、技術仕様書3GPP TS 23.071 および3GPP TS 23.171に記載される。
3GPP TS 29.010 gives the necessary information for interworking between the 3GPP TS 25.413 RANAP protocol and the
GSM 08.08 BSSMAP protocol. The interworking is necessary for positioning requests issued after a completed GSM to
UMTS inter system handover. BSSMAP messages carried by MAP over the E-interface must be mapped by the non-anchor
3G-MSC into the corresponding RANAP messages to be sent over the Iu-interface and vice versa. For Inter-MSC GSM to
GSM Handover and Inter-MSC UMTS to UMTS SRNS Relocation no mapping between the 3GPP TS 25.413 RANAP
protocol and the GSM 08.08 BSSMAP protocol is necessary, but only the interworking with the MAP protocol over the Einterface needs to be described.
3GPP TS 29.010は、3GPP TS 25.413のRANAPプロトコルとGSM 08.08のBSSMAPプロトコル間のインターワーキングに
必要な情報を提供する。GSMからUMTSへのシステム間ハンドオーバ完了後に位置情報取得が要求された場合に、イ
ンターワーキングが必要となる。MAPがEインタフェース上で伝送するBSSMAPメッセージは、非アンカー3G-MSCによっ
て対応するRANAPメッセージ上にマッピングされ、Iuインタフェース上で送信される必要があり、その逆もまた真である。
GSMからGSMへのMSC間ハンドオーバと、UMTSからUMTSへのMSC間SRNSリロケーションに関しては、3GPP TS
25.413のRANAPプロトコルとGSM 08.08のBSSMAPプロトコル間のインターワーキングは必要でないが、Eインタフェー
ス上でのMAPプロトコルとのインターワーキングについてのみ、説明が必要である。
4.9.1
4.9.1.1
Completed Location Acquisition（位置情報取得の完了）
Inter-MSC Handover (GSM to GSM)（MSC間ハンドオーバ（GSMからGSMへ））
After a successful Inter-MSC handover, any positioning request received by the anchor MSC via the MAP message Provide
Subscriber Location triggers the BSSMAP procedure Location Acquisition described in GSM 08.08. For handover this
procedure is executed according to 3GPP TS 29.108 with the anchor MSC playing the role of the MSC and the non anchor
MSC playing the role of the BSS.
MSC間ハンドオーバ完了後に、アンカーMSCがMAPメッセージProvide Subscriber Location によってなんらかの位置情
報取得要求を受信したならば、それはGSM 08.08で説明されるBSSMAP処理Location Acquisitionをトリガする。ハンド
オーバについては、MSCの役割を果たすアンカーMSCとBSSの役割を果たす非アンカーMSCとの間で、3GPP TS
29.108に従って本処理が実行される。
The needed BSSMAP signalling is sent over the E-interface encapsulated in the MAP messages Process Access Signalling
and Forward Access Signalling.
必要とされるBSSMAPのシグナリングは、Eインタフェース上でMAPメッセージProcess Access Signalling および
Forward Access Signalling中にカプセル化される。
At the non anchor MSC the BSSMAP messages received from the anchor MSC are forwarded to the BSS, and the
BSSMAP messages received from the BSS are sent over the E-interface to the anchor MSC.
非アンカーMSCでは、アンカーMSCから受信したBSSMAPメッセージがBSSに転送され、BSSから受信したBSSMAPメッ
セージはEインタフェース上でアンカーMSCに送信される。
The signalling for a completed Location Acquisition procedure is shown in figures 65a.
Location Acquisition処理完了シグナリングを、図65aに示す。
3GPP
Release 1999
128
3GPP TS 29.010 V3.10.0 (2002-12)
GMLC
MSC-A
MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
REQUEST)
|
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|
|
|
|
|------------------>|
|
|
|
|
|
|
| PERFORM LOCATION |
|
|
|
REQUEST |
|
|
|
|
|
|
|
|
|
|
|
+-----------+
|
|
|
|Positioning|
|
|
|
|
is
|
|
|
|
| performed |
|
|
|
+-----------+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|<------------------|
|
|
|
|
|
| PERFORM LOCATION
|
|
|
RESPONSE
|
|
|
|
|
MAP PROCESS ACCESS
|
|
|
SIGNALLING
|
|
|<------------------------|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
RESPONSE)
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION res
|
|
|<--------------|
|
|
|
|
Figure 65a: Signalling for a completed Location Acquisition procedure
図65a：Location Acquisition処理完了のシグナリング
After the inter-MSC handover, the MSC-B can perform intra-MSC GSM to UMTS handover. Any positioning request
received by the anchor MSC after completion of the intra-MSC GSM to UMTS handover is handled as for Inter-MSC
Handover GSM to UMTS (see section 4.9.1.2).
MSC間ハンドオーバ後に、MSC-BはGSMからUMTSへのMSC内ハンドオーバを実行することができる。GSMから
UMTSへのMSC内ハンドオーバ後に、アンカーMSCが任意の位置情報取得要求を受信したならば、それらはGSMから
UMTSへのMSC間ハンドオーバとして処理される。
4.9.1.2
Inter-MSC Handover (GSM to UMTS)（MSC間ハンドオーバ（GSMからUMTSへ）
After a successful Inter-MSC GSM to UMTS inter system handover, any positioning request received by the anchor MSC
via the MAP message Provide Subscriber Location triggers the BSSMAP procedure Location Acquisition described in
GSM 08.08. For handover this procedure is executed according to 3GPP TS 29.108 with the anchor MSC playing the role
of the MSC and the non anchor 3G MSC playing the role of the BSS.
GSMからUMTSへのシステム間MSC間システム間ハンドオーバが正常に終了した後、MAPメッセージProvide
Subscriber Location を介してアンカーMSCが何らかの位置情報取得要求を受信した場合には、GSM 08.08で説明され
るBSSMAPの処理Location Acquisitionがトリガされる。ハンドオーバについては、MSCの役割を果たすアンカーMSCと
BSSの役割を果たす非アンカー3G MSCとの間で、3GPP TS 29.108に従って本処理が実行される。
3GPP
Release 1999
129
3GPP TS 29.010 V3.10.0 (2002-12)
The needed BSSMAP signalling is sent over the E-interface encapsulated in the MAP messages Process Access Signalling
and Forward Access Signalling.
必要とされるBSSMAPシグナリングは、Eインタフェース上でMAPメッセージProcess Access Signalling およびForward
Access Signalling中にカプセル化されて送信される。
At the non anchor 3G MSC the BSSMAP messages received from the anchor MSC are mapped into the corresponding
RANAP messages to be sent to the RNS, and the received RANAP messages are mapped into the corresponding BSSMAP
messages to be sent over the E-interface to the anchor MSC.
非アンカー3G MSCでは、アンカーMSCから受信したBSSMAPメッセージは対応するRANAPメッセージにマッピングされ
てRNPに送信され、受信したRANAPメッセージは対応するBSSMAPメッセージにマッピングされてEインタフェース上で
アンカーMSCに送信される。
The signalling for a completed Location Acquisition procedure is shown in figures 65b.
Location Acquisition処理完了のシグナリングを、図65bに示す。
GMLC
MSC-A
3G-MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
REQUEST)
|
|
|
|
|
|
|
RNS-B
|
|
|
|
|
|
|LOCATION REPORTING |
|
|
| CONTROL
|
|
|
|------------------>|
|
|
|
|
|
|
|
+-----------+
|
|
|
|Positioning|
|
|
|
|
is
|
|
|
|
| performed |
|
|
|
+-----------+
|
|
|
|
|
|
|LOCATION REPORT
|
|
|
|<------------------|
|
|MAP PROCESS ACCESS
|
|
|
SIGNALLING
|
|
|<------------------------|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
RESPONSE)
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION res
|
|
|<--------------|
|
|
|
|
Figure 65b: Signalling for a completed Location Acquisition procedure
図65b：Location Acquisition処理完了のシグナリング
3GPP
Release 1999
130
3GPP TS 29.010 V3.10.0 (2002-12)
The interworking between the BSSMAP location aquisition messages in MAP and the RANAP location reporting messages
is as follows:
MAP内のBSSMAP location aquisition メッセージと、RANAP location reporting メッセージ間のインターワーキングを下
図に示す：
---------------------------------------------------------------|
29.002
25.413
|Notes
--------┼-------------------------------------------------┼----Forward | MAP FORWARD ACCESS SIG.
LOCATION REPORTING
|
message |
request
CONTROL
|
|
|
| -an-APDU(
|
| PERFORM LOCATION REQUEST)
|
|
|
| BSSMAP information
RANAP information
|
|
elements:
elements:
|
|
|
|
Location Type
Request Type
| 1
|
>Current Geographic
>Event = Direct
|
|
Location
>Report Area =
|
|
Geo. Coord.
|
|
|
|
Cell Identifier
---|
|
Classmark Inf. Type3
---|
|
LCS Client Type
---|
|
Chosen Channel
---|
|
LCS Priority
---|
|
LCS QoS
Request Type
|
|
>Horizontal Accuracy
>Accuracy Code
|
|
|
|
GPS Assistance Data
---|
|
APDU
---|
|
|
--------┼-------------------------------------------------┼----Result | MAP PROCESS ACCESS SIG.
LOCATION REPORT
|
|
request
|
| -an-APDU(
|
| PERFORM LOCATION RESPONSE)
|
|
|
| BSSMAP information
RANAP information
|
|
elements:
elements:
|
|
|
|
|
|
Location Estimate
Area Identity
|
|
>Geographical Area
|
|
Positioning Data
---|
|
Deciphering Keys
---|
|
LCS Cause
Cause
|
|
---Request Type
|
|
|
|
|
NOTE 1: All other Location Type possibilities are not supported by UMTS positioning,
他の全てのLocation Typeの可能性については、UMTSの位置情報サービスがサポートしない。
After the inter-MSC GSM to UMTS handover, the 3G MSC-B can perform intra-MSC UMTS to GSM handover. Any
positioning request received by the anchor MSC after completion of the intra-MSC UMTS to GSM handover is handled as
for Inter-MSC Handover GSM to GSM (see section 4.9.1.1).
GSMからUMTSへのMSC間ハンドオーバ後に、3G_MSC-BはUMTSからGSMへのMSC間ハンドオーバを実行すること
ができる。UMTSからGSMへのMSC内ハンドオーバ完了後に、アンカーMSCが受信した任意のポジショニング要求は、
GSMからGSMへのMSC間ハンドオーバとして処理される（4.9.1.1節参照）。
4.9.1.3
Inter-MSC Handover (UMTS to GSM)（MSC間ハンドオーバ（UMTSからGSMへ））
After a successful Inter-MSC UMTS to GSM inter system handover, any positioning request received by the anchor 3GMSC via the MAP message Provide Subscriber Location triggers the BSSMAP procedure Location Acquisition described
in GSM 08.08. For handover this procedure is executed according to 3GPP TS 29.008 with the anchor 3G-MSC playing the
role of the 3G-MSC and the non anchor MSC playing the role of the BSS.
3GPP
Release 1999
131
3GPP TS 29.010 V3.10.0 (2002-12)
UMTSからGSMへのシステム間MSC間システム間ハンドオーバが正常に終了した後、MAPメッセージProvide
Subscriber Location を介してアンカー3G-MSCが何らかの位置情報取得要求を受信した場合には、GSM 08.08で説明さ
れるBSSMAPの処理Location Acquisitionがトリガされる。ハンドオーバについては、3G-MSCの役割を果たすアンカー
3G-MSCとBSSの役割を果たす非アンカーMSCとの間で、3GPP TS 29.008に従って本処理が実行される。
The needed BSSMAP signalling is sent over the E-interface encapsulated in the MAP messages Process Access Signalling
and Forward Access Signalling.
必要とされるBSSMAPシグナリングは、Eインタフェース上でMAPメッセージProcess Access Signalling およびForward
Access Signalling中にカプセル化されて送信される。
At the non anchor MSC the BSSMAP messages received from the anchor 3G-MSC are forwarded to the BSS, and the
BSSMAP messages received from the BSS are sent over the E-interface to the anchor 3G-MSC.
非アンカーMSCでは、アンカー3G-MSCから受信したBSSMAPメッセージはBSSに転送され、BSSから受信したBSSMAP
メッセージはEインタフェース上でアンカー3G-MSCに送信される。
The signalling for a completed Location Acquisition procedure is shown in figures 65c.
Location Acquisition処理完了のシグナリングを、図65cに示す。
GMLC
3G-MSC-A
MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
REQUEST)
|
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|
|
|
|
|------------------>|
|
|
|
|
|
|
| PERFORM LOCATION |
|
|
|
REQUEST |
|
|
|
|
|
|
|
|
|
|
|
+-----------+
|
|
|
|Positioning|
|
|
|
|
is
|
|
|
|
| performed |
|
|
|
+-----------+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|<------------------|
|
|
|
|
|
| PERFORM LOCATION
|
|
|
RESPONSE
|
|
|
|
|
MAP PROCESS ACCESS
|
|
|
SIGNALLING
|
|
|<------------------------|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
RESPONSE)
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION res
|
|
|<--------------|
|
|
|
|
Figure 65c: Signalling for a completed Location Acquisition procedure
図65c：Location Acquisition処理完了のシグナリング
3GPP
Release 1999
132
3GPP TS 29.010 V3.10.0 (2002-12)
After the inter-MSC UMTS to GSM handover, the 3G MSC-B can perform intra-MSC GSM to UMTS handover. Any
positioning request received by the anchor 3G MSC after completion of the intra-MSC GSM to UMTS handover is handled
as for Inter-MSC Handover GSM to UMTS (see section 4.9.1.2).
UMTSからGSMへのMSC間ハンドオーバ後に、3G MSC-BはGSMからUMTSへのMSC内ハンドオーバを実行すること
ができる。GSMからUMTSへのMSC内ハンドオーバ完了後にアンカー3G MSCが受信した全てのポジショニング要求
は、GSMからUMTSへのMSC間ハンドオーバとして処理される（4.9.1.2節参照）。
4.9.1.4
Inter-MSC SRNS Relocation（MSC間SRNSリロケーション）
After a successful Inter-MSC SRNS Relocation, any positioning request received by the anchor 3G-MSC via the MAP
message Provide Subscriber Location triggers the RANAP procedure Location Reporting Control described in TS 25.413.
For handover this procedure is executed according to 23.009 with the anchor 3G-MSC playing the role of the 3G-MSC and
the non anchor 3G-MSC playing the role of the RNS.
MSC間SRNSリロケーションが正常終了後、MAPメッセージProvide Subscriber Location を介してアンカー3G-MSCが何
らかの位置情報取得要求を受信した場合には、TS 25.413で説明されるRANAP の処理Location Reporting Control が
トリガされる。ハンドオーバのために、ハンドオーバについては、3G-MSCの役割を果たすアンカー3G-MSCとRNSの役
割を果たす非アンカー3G-MSCとの間で、3GPP TS 23.009に従って本処理が実行される。
The needed RANAP signalling is sent over the E-interface encapsulated in the MAP messages Process Access Signalling
and Forward Access Signalling.
必要とされるRANAPシグナリングは、Eインタフェース上でMAPメッセージProcess Access Signalling およびForward
Access Signalling中にカプセル化されて送信される。
At the non anchor 3G-MSC the RANAP messages received from the anchor 3G-MSC are forwarded to the RNS, and the
RANAPmessages received from the RNS are sent over the E-interface to the anchor 3G-MSC.
非アンカー3G-MSCでは、アンカー3G-MSCから受信したRANAPメッセージはRNSに転送され、RNSから受信した
RANAPメッセージはEインタフェース上でアンカー3G-MSCに送信される。
The signalling for a completed Location Acquisition procedure is shown in figures 65d.
Location Acquisition処理完了のシグナリングを、図65dに示す。
3GPP
Release 1999
133
3GPP TS 29.010 V3.10.0 (2002-12)
GMLC
3G-MSC-A
3G-MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| LOCATION REPORTING
|
|
|
CONTROL)
|
|
|
|
|
|
|
RNS-B
|
|
|
|
|
|
|
|
|
|
|------------------>|
|
|
|
|
|
|
|LOCATION REPORTING |
|
|
| CONTROL
|
|
|
|
|
|
|
|
|
|
|
|
+-----------+
|
|
|
|Positioning|
|
|
|
|
is
|
|
|
|
| performed |
|
|
|
+-----------+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|<------------------|
|
|
|
|
|
|LOCATION REPORT
|
|
|
|
|
|
|
|
MAP PROCESS ACCESS
|
|
|
SIGNALLING
|
|
|<------------------------|
|
| -an-APDU(
|
|
| LOCATION REPORT)
|
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION res
|
|
|<--------------|
|
|
|
|
Figure 65d: Signalling for a completed Location Acquisition procedure
図65d：Location Acquisition処理完了のシグナリング
After the inter-MSC SRNS Relocation, the 3G MSC-B can perform intra-MSC UMTS to GSM handover. Any positioning
request received by the anchor 3G MSC after completion of the intra-MSC UMTS to GSM requires that at the non anchor
3G MSC the received RANAP messages are mapped into the corresponding BSSMAP messages to be sent to the BSS, and
the received BSSMAP messages are mapped into the corresponding RANAP messages to be sent over the E-interface to
the anchor 3G-MSC.
MSC間SRNSリロケーション後に、3G MSC-BはUMTSからGSMへのMSC内ハンドオーバを実行することができる。
UMTSからGSMへのMSC内ハンドオーバ完了後に、アンカー3G MSC が受信した全てのポジショニング要求に関して
は、非アンカー3G MSC内で受信したRANAPメッセージを対応するBSSMAPメッセージにマッピングしてBSSに送信し、
受信したBSSMAPメッセージを対応するRANAPメッセージにマッピングしてEインタフェース上でアンカー3G-MSCに送信
することが必要である。
The signalling for a completed Location Acquisition procedure is shown in figures 65e.
Location Acquisition 処理完了のシグナリングを、図65eに示す。
3GPP
Release 1999
134
3GPP TS 29.010 V3.10.0 (2002-12)
GMLC
3G-MSC-A
3G-MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| LOCATION REPORTING
|
|
|
CONTROL)
|
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|
|
|
|
|------------------>|
|
|
|
|
|
|
|PERFORM LOCATION
|
|
|
| REQUEST
|
|
|
|
|
|
|
|
|
|
|
|
+-----------+
|
|
|
|Positioning|
|
|
|
|
is
|
|
|
|
| performed |
|
|
|
+-----------+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|<------------------|
|
|
|
|
|
|PERFORM LOCATION
|
|
| RESPONSE
|
|
|
|
|
MAP PROCESS ACCESS
|
|
|
SIGNALLING
|
|
|<------------------------|
|
| -an-APDU(
|
|
| LOCATION REPORT)
|
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION res
|
|
|<--------------|
|
|
|
|
Figure 65e: Signalling for a completed Location Acquisition procedure
図65e：Location Acquisition処理完了のシグナリング
the interworking between the RANAP messages encapsulated in MAP and the BSSMAP messages is as follows:
MAP内でカプセル化されたRANAPメッセージと、BSSMAP内でカプセル化されたRANAPメッセージとのインターワーキ
ングを、以下に示す：
3GPP
Release 1999
135
3GPP TS 29.010 V3.10.0 (2002-12)
---------------------------------------------------------------|
29.002
08.08
|Notes
--------┼-------------------------------------------------┼----Forward | MAP FORWARD ACCESS SIG.
PERFORM LOCATION
|
message |
request
REQUEST
|
|
|
| -an-APDU(
|
| LOCATION REPORTING CONTROL)
|
|
|
| RANAP information
BSSMAP information
|
|
elements:
elements:
|
|
|
|
Request Type
Location Type
|
|
>Event = Direct
>Current Geographic |
|
>Report Area =
Location
|
|
Geo. Coord.
|
|
|
|
Request Type
LCS QoS
|
|
>Accuracy Code
>Horizontal Accuracy |
|
|
--------┼-------------------------------------------------┼----Result | MAP PROCESS ACCESS SIG.
PERFORM LOCATION
|
|
request
RESPONSE
|
| -an-APDU(
|
| LOCATION REPORT)
|
|
|
| RANAP information
BSSMAP information
|
|
elements:
elements:
|
|
|
|
Area Identity
Location Estimate
|
|
>Geographical Area
|
|
|
|
Cause
LCS Cause
|
|
Request Type
---|
|
|
4.9.2
4.9.2.1
Cause Code Mapping（理由コードのマッピング）
Inter-MSC Handover(GSM to GSM) （MSC間ハンドオーバ（GSMからGSMへ））
When a mobile station is handed over from GSM to GSM, no mapping of cause codes is required. The MSC shall use the
cause codes specified in GSM 08.08.
MSがGSMからGSMへハンドオーバされる場合、理由コードのマッピングは必要ない。MSCは、GSM 08.08中で規定さ
れる理由コードを使用すること。
After the inter-MSC handover, the MSC-B can perform intra-MSC GSM to UMTS handover. A mapping of the cause
codes used in the RANAP and the BSSMAP protocols is needed after completion of the intra-MSC GSM to UMTS
handover and is the same as for Inter-MSC Handover GSM to UMTS (see section 4.9.2.2).
MSC間ハンドオーバ後に、MSC-BはGSMからUMTSへのMSC内ハンドオーバを実行することができる。GSMから
UMTSへのMSC内ハンドオーバ完了後に、RANAPプロトコル内で使用される理由コードとBSSMAPプロトコル内で使用
される理由コード間のマッピングが必要となる。GSMからUMTSへのMSC間ハンドオーバの場合も同様（4.9.2.2節参
照）。
3GPP
Release 1999
4.9.2.2
136
3GPP TS 29.010 V3.10.0 (2002-12)
Inter-MSC Handover (GSM to UMTS)（ＭＳＣ間ハンドオーバ（GSMからUMTSへ））
When a Mobile Station is handed over between GSM and UMTS, a mapping of the cause codes used in the RANAP and
the BSSMAP protocols is needed. The mapping described here is applicable to the BSSMAP protocol even when used
inside MAP in the E-interface.
MSがGSMとUMTS間でハンドオーバされる場合、RANAPプロトコル内で使用される理由コードとBSSMAPプロトコル内
で使用される理由コード間のマッピングが必要となる。ここで説明されるマッピングは、MAP内部のEインタフェース上で
使用される場合でも、BSSMAPプロトコルに対して適用可能である。
The mapping between the cause codes received in RANAP Location Report and the LCS cause codes sent in BSSMAP
Perform Location Response is as follows:
RANAP Location Report 内で受信した理由コードと、BSSMAP Perform Location Response 内で送信されるLCS理由コ
ード間のインターワーキングについて、以下に示す：
---------------------------------------------------------------25.413
08.08
|Notes
-------------------------------------------------------┼-------LOCATION REPORT
PERFORM LOCATION RESPONSE |
|
- Requested Report Type
- Position method failure|
not Supported
|
- Requested Information
- System Failure
|
not Available
|
- all other cause codes
- System Failure
|
After the inter-MSC GSM to UMTS handover, the 3G MSC-B can perform intra-MSC UMTS to GSM handover. No
mapping of cause codes is required after completion of the intra-MSC UMTS to GSM handover as for Inter-MSC
Handover GSM to GSM (see section 4.9.2.1).
GSMからUMTSへのMSC間ハンドオーバ後に、3G MSC-BはUMTSからGSMへのMSC内ハンドオーバを実行すること
ができる。GSMからGSMへのMSC間ハンドオーバ（4.9.2.1節参照）のとき同様、UMTSからGSMへのMSC内ハンドオー
バの完了後に、理由コードのマッピングは必要ない。
4.9.2.3
Inter-MSC Handover (UMTS to GSM)（MSC間ハンドオーバ（UMTSからGSMへ））
When a mobile station is handed over from UMTS to GSM, no mapping of cause codes is required. The 3G-MSC shall
use the cause codes specified in GSM 08.08.
MSがUMTからGSMへハンドオーバされる場合、理由コードのマッピングは必要ない。3G-MSCは、GSM 08.08中で規定
される理由コードを使用すること。
After the inter-MSC UMTS to GSM handover, the 3G MSC-B can perform intra-MSC GSM to UMTS handover. A
mapping of the cause codes used in the RANAP and the BSSMAP protocols is needed after completion of the intra-MSC
GSM to UMTS handover and is the same as for Inter-MSC Handover GSM to UMTS (see section 4.9.2.2).
UMTSからGSMへのMSC間ハンドオーバ後に、3G MSC-BはGSMからUMTSへのMSC内ハンドオーバを実行すること
ができる。GSMからUMTSへのMSC内ハンドオーバ完了後に、GSMからUMTSへのMSC内ハンドオーバ同様、RANAP
プロトコル中で使用される理由コードとBSSMAPプロトコル中で使用される理由コードの間のマッピングが必要である
（4.9.2.2節参照）。
4.9.2.4
Inter-MSC SRNS Relocation（MSC間SRNSリロケーション）
When a mobile station is handed over from UMTS to UMTS, no mapping of cause codes is required. Both 3G-MSCs
shall use the cause codes specified in TS 25.413.
MSがUMTSからUMTSへハンドオーバされる場合、理由コードのマッピングは必要ない。双方の3G-MSCは、TS 25.413
中で規定される理由コードを使用すること。
After the inter-MSC SRNS Relocation, the 3G MSC-B can perform intra-MSC UMTS to GSM handover. A mapping of the
cause codes used in the RANAP and the BSSMAP protocols is needed after completion of the intra-MSC UMTS to GSM
handover.
MSC間SRNSリロケーション後に、3G MSC-BはUMTSからGSMへのMSC内ハンドオーバを実行することができる。
3GPP
Release 1999
137
3GPP TS 29.010 V3.10.0 (2002-12)
UMTSからGSMへのMSC内ハンドオーバ完了後に、RANAPプロトコル中で使用される理由コードと、BSSMAPプロトコ
ル中で使用される理由コード間のマッピングが必要である。
The mapping between the cause codes received in BSSMAP Perform Location Response and the LCS cause codes sent in
RANAP Location Report is as follows:
BSSMAPのメッセージPerform Location Response中で受信する理由コードと、RANAP Location Report 中で送信される
LCS（Location Service）理由コード間のマッピングは、以下のとおりである：
---------------------------------------------------------------08.08
25.413
|Notes
-------------------------------------------------------┼-------PERFORM LOCATION RESPONSE
LOCATION REPORT
|
|
- Position method failure
- Requested Report Type |
not Supported
|
- System Failure
- Unspecified Failure
|
- Protocol Error
- Unspecified Failure
|
- Data missing
- Unspecified Failure
|
in position request
|
- Unexpected data value
- Unspecified Failure
|
in position request
|
- Target MS Unreachable
- Unspecified Failure
|
- Location request aborted
- Unspecified Failure
|
- Facility not supported
- Requested Report Type |
not Supported
|
- Inter-BSC Handover Ongoing - Unspecified Failure
|
- Intra-BSC
- Unspecified Failure
|
Handover Complete
|
- Congestion
- Unspecified Failure
|
- Unspecified
- Unspecified Failure
|
3GPP
Release 1999
4.9.3
4.9.3.1
138
3GPP TS 29.010 V3.10.0 (2002-12)
Aborted Location Acquisition（位置情報取得の中断）
Inter-MSC Handover (GSM to GSM)（MSC間ハンドオーバ（GSMからGSMへ））
When for any reason the on going location acquisition procedure needs to be aborted, the anchor MSC sends the BSSMAP
message Perform Location Abort over the E-interface.
何らかの理由により、現在進行中の位置情報取得処理を中断する必要が発生した場合、アンカーMSCはEインタフェー
ス上でBSSMAPメッセージPerform Location Abort を送信する。
Figure 66a shows the signalling for an aborted Location Acquisition procedure.
図66aに、位置情報取得処理が中断された場合のシグナリングを示す。
GMLC
MSC-A
MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
REQUEST)
|
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-------------------->|
|
|
|
|
|
|
|
PERFORM LOCATION |
|
|
|
REQUEST)|
|
|
|
|
|
|
|
|
|
|
|
|
|
|MAP FORWARD ACCESS
|
|
|
|
SIGNALLING
|
|
|
|------------------------>|
|
|
| -an-APDU(
|
|
|
| PERFORM LOCATION ABORT)|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-------------------->|
|
|
|
|
|
|
|
PERFORM LOCATION |
|
|
|
ABORT
|
|
|
|
|
|
|
|<--------------------|
|
|
|
|
|
|
|
PERFORM LOCATION |
|
|
|
RESPONSE|
|
|
|
|
|
|MAP PROCESS ACCESS
|
|
|
|
SIGNALLING
|
|
|
|<------------------------|
|
|
| -an-APDU(
|
|
|
| PERFORM LOCATION
|
|
|
|
RESPONSE)
|
|
Figure 66a: Signalling for an aborted Location Acquisition procedure
図66a：位置情報取得処理が中断された場合のシグナリング
After the inter-MSC handover, the MSC-B can perform intra-MSC GSM to UMTS handover. A positioning request that
needs to be aborted by the anchor MSC after completion of the intra-MSC GSM to UMTS handover is handled as for InterMSC Handover GSM to UMTS (see section 4.9.3.2).
MSC内ハンドオーバ後に、MSC-BはGSMからUMTSへのMSC内ハンドオーバを実行することができる。GSMから
3GPP
Release 1999
139
3GPP TS 29.010 V3.10.0 (2002-12)
UMTSへのMSC内ハンドオーバ完了後に、アンカーMSCが位置情報取得要求を中断する必要が発生したならば、その
要求はGSM からUMTSへのMSC間ハンドオーバとして処理される（4.9.3.2節参照）。
4.9.3.2
Inter-MSC Handover (GSM to UMTS)（MSC間ハンドオーバ（GSMからUMTSへ））
When for any reason the on going location acquisition procedure needs to be aborted, the anchor MSC sends the BSSMAP
message Perform Location Abort over the E-interface.
何らかの理由により、現在進行中の位置情報取得処理を中断する必要が発生した場合、アンカーMSCはEインタフェー
ス上でBSSMAPメッセージPerform Location Abort を送信する。
Figure 66b shows the signalling for an aborted Location Acquisition procedure.
図66bに、位置情報取得処理が中断された場合のシグナリングを示す。
GMLC
MSC-A
3G-MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
REQUEST)
|
|
|
|
|
|
|
RNS-B
|
|
|
|
|
|
|LOCATION REPORTING |
|
|
| CONTROL
|
|
|
|------------------>|
|
|
|
|
|
|
|
|
|
|MAP FORWARD ACCESS
|
|
|
|
SIGNALLING
|
|
|
|------------------------>|
|
|
| -an-APDU(
|
|
|
| PERFORM LOCATION ABORT)|
|
|
|
|
|
|
|
|
|
|
|MAP PROCESS ACCESS
|
|
|
|
SIGNALLING
|
|
|
|<------------------------|
|
|
| -an-APDU(
|
|
|
| PERFORM LOCATION
|
|
|
|
RESPONSE)
|
|
Figure 66b: Signalling for an aborted Location Acquisition procedure
図66b：位置情報取得処理が中断された場合のシグナリング
Since RANAP does not support abortion of a positioning request, non-anchor 3G-MSC shall generate a BSSMAP Perform
Location Response with LCS Cause “Location request aborted” to be sent over the E-interface to the anchor MSC, and then
shall discard any message from the RNS related to the aborted positioning request.
RANAPは位置情報取得要求の中断をサポートしないので、非アンカー3G-MSCはLCS理由コード“Location request
aborted” といっしょにBSSMAPメッセージPerform Location Responseを生成し、Eインタフェース上でアンカーMSCに送信
すること。そして中断されたポジショニング要求と関連するメッセージをRNSから受信したらばそれらを全て廃棄するこ
と。
After the inter-MSC GSM to UMTS handover, the 3G MSC-B can perform intra-MSC UMTS to GSM handover. A
positioning request that needs to be aborted by the anchor MSC after completion of the intra-MSC UMTS to GSM
handover is handled as for Inter-MSC Handover GSM to GSM (see section 4.9.3.1).
GSMからUMTSへのMSC間ハンドオーバ後、3G MSC-BはUMTS からGSMへのMSC内ハンドオーバを実行すること
ができる。UMTSからGSMへのMSC内ハンドオーバ完了後に、アンカーMSCが位置情報取得要求を中断する必要が発
生したならば、その要求はGSMからGSMへのMSC間ハンドオーバとして処理される（4.9.3.1節参照）。
3GPP
Release 1999
4.9.3.3
140
3GPP TS 29.010 V3.10.0 (2002-12)
Inter-MSC Handover (UMTS to GSM)（MSC間ハンドオーバ（UMTSからGSMへ））
When for any reason the on going location acquisition procedure needs to be aborted, the anchor 3G-MSC sends the
BSSMAP message Perform Location Abort over the E-interface.
何らかの理由により、現在進行中の位置情報取得処理を中断する必要が発生した場合、アンカー3G-MSC はEインタ
フェース上でBSSMAPメッセージPerform Location Abort を送信する。
Figure 66c shows the signalling for an aborted Location Acquisition procedure.
図66cに、位置情報取得処理が中断された場合のシグナリングを示す。
GMLC
3G-MSC-A
MSC-B
|
|
|
|MAP PROVIDE
|
|
|SUBSCRIBER
|
|
|LOCATION
|
|
|-------------->|MAP FORWARD ACCESS
|
|
|
SIGNALLING
|
|
|------------------------>|
|
| -an-APDU(
|
|
| PERFORM LOCATION
|
|
|
REQUEST)
|
|
|
|
|
|
|
BSS-B
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-------------------->|
|
|
|
|
|
|
|
PERFORM LOCATION |
|
|
|
REQUEST)|
|
|
|
|
|
|
|
|
|
|MAP FORWARD ACCESS
|
|
|
|
SIGNALLING
|
|
|
|------------------------>|
|
|
| -an-APDU(
|
|
|
| PERFORM LOCATION ABORT)|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-------------------->|
|
|
|
|
|
|
|
PERFORM LOCATION |
|
|
|
ABORT
|
|
|
|
|
|
|
|<--------------------|
|
|
|
|
|
|
| PERFORM LOCATION |
|
|
|
RESPONSE
|
|
|MAP PROCESS ACCESS
|
|
|
|
SIGNALLING
|
|
|
|<------------------------|
|
|
| -an-APDU(
|
|
|
| PERFORM LOCATION
|
|
|
|
RESPONSE)
|
|
Figure 66c: Signalling for an aborted Location Acquisition procedure
図66c：位置情報取得処理が中断された場合のシグナリング
After the inter-MSC UMTS to GSM handover, the 3G MSC-B can perform intra-MSC GSM to UMTS handover. A
positioning request that needs to be aborted by the anchor 3G MSC after completion of the intra-MSC GSM to UMTS
handover is handled as for Inter-MSC Handover GSM to UMTS (see section 4.9.3.2).
UMTSからGSMへのMSC間ハンドオーバ後に、3G MSC-B はGSMからUMTSへのMSC内ハンドオーバを実行すること
ができる。GSMからUMTSへのMSC内ハンドオーバ完了後に、アンカー3G MSC が位置情報取得要求を中断する必要
が発生したならば、その要求はGSM からUMTSへのMSC間ハンドオーバとして処理される（4.9.3.2節参照）。
3GPP
Release 1999
141
3GPP TS 29.010 V3.10.0 (2002-12)
4.9.6.4 Inter-MSC SRNS Relocation（MSC間SRNSリロケーション）
After a successful Inter-MSC SRNS Relocation a positioning request cannot be aborted by the 3G anchor MSC since
RANAP does not support abortion of a positioning request.
RANAPは位置情報取得要求の中断をサポートしないので、MSC間SRNSリロケーション正常完了後は、3Gのアンカー
MSCは位置情報取得要求を中断できない。
3GPP
Release 1999
142
3GPP TS 29.010 V3.10.0 (2002-12)
Annex A (informative):
Change history（改版履歴）
TSG CN#
Sept 1999
CN#04
CN#06
CN#06
CN#07
CN#07
CN#07
CN#09
Spec
GSM 09.10
29.010
29.010
29.010
29.010
29.010
29.010
29.010
Version
7.0.0
CR
Change history
<Phase> New Version
3.0.0
3.0.0
3.1.0
3.1.0
3.1.0
3.2.0
001
002
003r1
004r1
005
006r1
R99
R99
R99
R99
R99
R99
R99
3.0.0
3.1.0
3.1.0
3.2.0
3.2.0
3.2.0
3.3.0
CN#09
29.010
3.2.0
007r1
R99
3.3.0
CN#10
29.010
3.3.0
008
R99
3.4.0
CN#10
29.010
3.3.0
009
R99
3.4.0
CN#10
29.010
3.3.0
010
R99
3.4.0
CN#10
29.010
3.3.0
011r1
R99
3.4.0
CN#11
29.010
3.4.0
012
R99
3.5.0
CN#11
29.010
3.4.0
013
R99
3.5.0
CN#11
CN#11
29.010
29.010
3.4.0
3.4.0
014
015
R99
R99
3.5.0
3.5.0
CN#11
29.010
3.4.0
016
R99
3.5.0
CN#11
29.010
3.4.0
017
R99
3.5.0
CN#12
29.010
3.5.0
019r1
R99
3.6.0
CN#12
29.010
3.5.0
021r1
R99
3.6.0
CN#12
29.010
3.5.0
023r1
R99
3.6.0
CN#12
29.010
3.5.0
025r1
R99
3.6.0
CN#12
29.010
3.5.0
027r1
R99
3.6.0
CN#12
CN#12
29.010
29.010
3.5.0
3.5.0
029
032
R99
R99
3.6.0
3.6.0
CN#12
29.010
3.5.0
033r1
R99
3.6.0
CN#14
29.010
3.6.0
035r2
R99
3.7.0
CN#14
CN#14
CN#14
CN#16
29.010
29.010
29.010
29.010
3.6.0
3.6.0
3.6.0
3.7.0
039
042r1
046
050r1
R99
R99
R99
R99
3.7.0
3.7.0
3.7.0
3.8.0
CN#16
29.010
3.7.0
053r1
R99
3.8.0
3GPP
Subject/Comment
Transferred to 3GPP CN
Approved by mail exploder at CN#04
UMTS / GSM Interworking
Addition of LSA Information message
UMTS / GSM Interworking
GSM / UMTS Interworking
UMTS/UMTS Handover
Clarification of use of Radio Resource
Information
Corrections and updates to align with current
R99 specs
GSM to 3G Handover: Location Reporting in
3G_MSC-B
GSM to 3G Handover: Chosen IEs in
Handover Request Ack
GSM to 3G Handover: MAP parameter Target
Cell ID
GSM/UMTS Interworking: Mapping of cause
codes
GSM to UMTS handover: addition of MAP
parameter Target RNC ID
Inter MSC relocation: addition of MAP
parameter Target RNC ID
Roaming restrictions for GPRS service
Alignment of cause mapping for 08.08 and
25.413 (Directed Retry)
UMTS to GSM Directed Retry cause code
mapping
Mapping of unknown HLR error to access
interface cause code
Addition of selected UMTS algorithm
indication to the handover procedures
Addition of selected GSM algorithm indication
to the handover procedures
Addition of allowed UMTS algorithms
indication to the handover procedures
Addition of allowed GSM algorithms indication
to the handover procedures
Addition of GSM channel type and GSM
chosen channel indications to handover
procedures
Partial Roaming – restriction by Location area
Mapping between RANAP and BSSMAP for
Location Services
Mapping between RANAP and BSSMAP for
Location Services
LCS/HO Location Reporting – GSM to GSM,
UMTS to GSM and UMTS to UMTS
Global replace of BSS-APDU with AN-APDU
Alignment of 29.010 to 25.413 for LCS
Removal of deleted MAP operations
LCS: clarification of mapping for Location
Acquisition
Addition of Service Handover parameters to
MAP Handover messages
Release 1999
143
TSG CN#
CN#17
Spec
29.010
Version
3.8.0
CR
057r2
Change history
<Phase> New Version
R99
3.9.0
CN#18
29.010
3.9.0
082r3
R99
3.10.0
3GPP
3GPP TS 29.010 V3.10.0 (2002-12)
Subject/Comment
Addition of an error mapping table for MAP
Update Location operation
Correction to the Service Handover
parameters

“貼って知～る”（防災マップシール）;pdf

こちら！ - 杵築市観光協会

Map.A M ap.B

こちら - ARecX6

統計におけるオープンデータの高度化

6 采女屋 11 かわとみ 7 旨屋 12 KYO-YA 8 太田焼そば 寿屋

Liaison Vol.63