This amendment A1 modifies the European Telecommunication Standard ETS (February 1995)

Transcription

1 AMENDMENT ETS A1 July 1995 Source: ETSI TC-SMG Reference: RE/SMG P ICS: Key words: European digital cellular telecommunications system, Global System for Mobile communications (GSM) This amendment A1 modifies the European Telecommunication Standard ETS (February 1995) European digital cellular telecommunications system (Phase 2); Mobile Application Part (MAP) specification (GSM 09.02) ETSI European Telecommunications Standards Institute ETSI Secretariat New presentation - see History box Postal address: F Sophia Antipolis CEDEX - FRANCE Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.fr Tel.: Fax: 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. European Telecommunications Standards Institute All rights reserved.

2 Page 2 Whilst every care has been taken in the preparation and publication of this document, errors in content, typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to "ETSI Editing and Committee Support Dept." at the address shown on the title page.

3 Page 3 Foreword This Amendment to ETS (February 1995) has been produced by the Special Mobile Group (SMG) Technical Committee of the European Telecommunications Standards Institute (ETSI). This Amendment to ETS (February 1995) corresponds to the changes to GSM Technical Specification (GSM-TS) from version to version , as approved by TC-SMG. This Amendment modifies pages 42, 44, 46, 179, 185, 195, 207, 208, 209, 210, 213, 652 and 654 of ETS (February 1995). Amendments Page 42, subclause Replace the first sentence of the second paragraph after the "2), b) Calling Party Address" bullet points, with the following new sentence: "In the case of intra-plmn addressing, it may be necessary to complement the Calling Party Address received in the dialogue initiating SCCP UNITDATA message by the associated Originating Point Code taken from the MTP-TRANSFER-INDICATION primitive as indicated above." Page 44, subclause Replace the existing first paragraph with the following: "When a mobile station registers for the first time in a VLR, the VLR has to initiate the update location dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if the authentication information must be retrieved from the HLR. When initiating either of these dialogues, the only data for addressing the HLR that the VLR has available is contained in the IMSI, and addressing information for SCCP must be derived from it. When continuing the established update location dialogue (as with any other dialogue), the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. This means that the VLR must be able to address the HLR based: - on an E.214 Mobile Global Title originally derived by the VLR from the IMSI; - or on an E.164 HLR address; - or, in the case of intra-plmn signalling, on an SPC.

4 Page 4 Page 46, subclause Replace the existing table 4.1/1, legend and te with the following: to fixed HLR VLR MSC EIR from network fixed - E:GT network T:MSISDN home I:SPC/GT location - - E:GT - - register T:VLR NUMBER I:SPC/GT I:SPC/GT visitor - E:GT E:GT - - location T:MGT/ T:VLR register MSISDN/ HLR NUMBER/ NUMBER (Note) mobile-services I:SPC/GT I:SPC/GT I:SPC/GT I:SPC/GT switching - E:GT E:GT E:GT E:GT centre T:MSISDN T:VLR T:MSC T:EIR NUMBER NUMBER NUMBER I: Intra-PLMN E: Extra(Inter)-PLMN T: Address Type GT: Global Title MGT: E.214 Mobile Global Title SPC: Signalling Point Code NOTE: For initiating the location updating procedure and an authentication information retrieval from the HLR preceding it, the VLR has to derive the HLR address from the IMSI of the MS. The result can be an SPC or an E.214 Mobile Global Title. When continuing the established update location dialogue (as with any other dialogue), the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. For transactions invoked by the VLR after update location completion, the VLR may derive the information for addressing the HLR from addresses received in the course of the update location procedure (MSISDN or HLR number) or from the IMSI. When invoking the Restore Data procedure and an authentication information retrieval from the HLR preceding it, the VLR must derive the information for addressing the HLR from the address information received in association with the roaming number request. This may be either the IMSI received as a parameter of the MAP message requesting the Roaming Number or the Calling Party Address associated with the MAP message requesting the Roaming Number. Table 4.1/1

5 Page 5 Page 179, subclause Replace the existing final paragraph with the following: "The requesting MAP PM waits for a TC indication primitive and does t accept any other primitive from its user, except a MAP-U-ABORT request or a MAP-CLOSE request." Page 185, subclause Replace the existing text of subclause with the following: "On receipt of a MAP-CLOSE request primitive, the MAP PM shall issue a TC-END request primitive and, if applicable, return to idle the associated active SSMs. Note that if the release method parameter of the MAP-CLOSE request indicates "rmal" the TC-END request primitive will trigger the transmission of components associated with any user specific request or response primitives which may have been issued after the last MAP-DELIMITER request. Page 195, subclause Replace the existing text of subclause with the following: "The value of this parameter of the TC-END request primitive is set by the MAP PM on the basis of the release method parameter of the MAP-CLOSE request primitive, except when the dialogue state machine is in a state DIALOGUE INITIATED, in which case the Termination parameter shall always indicate "prearranged end". "

6 Page 6 Pages 207, figure 13.2/3 (sheet 2 of 11). Replace figure 13.2/3 (sheet 2 of 11) with the following figure: Figure 13.2/3 (sheet 2 of 11): Process MAP_DSM Process MAP_DSM 132_32(11) Figure 13.2/3 (sheet 2 of 11) INIT_DATA WAIT_LOAD_ CHECK_ RESULT2 TC_INVOKE_ IND (OP_CODE) TC_L_REJECT IND ANY_OTHER_ IND LOAD_OK OVERLOAD operation _exists Derive_ V1_AC operation _code ELSE begin_ subscriber _activity CHECK_LOAD_ VIA_LOAD1 TC_U_ ABORT_REQ _VIA_TC1 last_ component WAIT_LOAD_ CHECK_ RESULT2 Build_ MAP-OPEN_Ind _primitive TC-U-ABORT _REQ_VIA_ TC1 MAP-OPEN _IND_VIA_ USER2 Perform_ version_1_ protocol

7 Page 7 Pages 208, figure 13.2/3 (sheet 3 of 11). Replace figure 13.2/3 (sheet 3 of 11) with the following figure: Figure 13.2/3 (sheet 3 of 11): Process MAP_DSM Process MAP_DSM Figure 13.2/3 (sheet 3 of 11) IDLE LOAD_CHECK_ RESULT1 132_33(11) TC_BEGIN _Ind LOAD_OK OVERLOAD AC_ included User_ information included Extract user information AC of version_1 AC_ supported AC_name := Received_AC _name Alternative_ name_exists MAP-OPEN dialoguepdu invalid_ parameter Set_ user_data AC_name := Received_AC _name Set_AC_name := Alternative_name CHECK_LOAD _VIA_LOAD1 MAP_OPEN_IND _VIA_USER2 LOAD_CHECK_ RESULT1 Components _present User_info _required_ for_ac MAP-Provider_ AbortReason := abrmaldialogue Set User_info := MAP-Provider _AbortInfo PROCESS_ COMPONENTS Abort_reason := AC_t_ suppported Set Abort_reason := User_specific TC_U_ABORT _REQ_VIA_TC1 Components _present MAP_ DELIMITER_ IND_VIA_USER2 MAP_ DELIMITER_ IND_VIA_USER2 CHECK_LOAD _VIA_LOAD1 TC_U_ABORT _REQ_VIA_TC1 LOAD_CHECK_ RESULT1 INIT_DATA DIALOGUE_ PENDING

8 Page 8 Pages 209, figure 13.2/3 (sheet 4 of 11). Replace figure 13.2/3 (sheet 4 of 11) with the following figure: Figure 13.2/3 (sheet 4 of 11): Process MAP_DSM Process MAP_DSM 132_34(11) Figure 13.2/3 (sheet 4 of 11) USER_REQUESTS any MAP specific request primitive MAP_REQ MAP_ DELIMITER_ REQ MAP_U_ ABORT_ REQ REQUESTING_MAP_ SSM Set_Abort_ reason=user_ specific Set_user_info= map_user_ Abort_PDU SERVICE_ INVOKED_VIA INTERN2 TC_BEGIN_REQ VIA_TC1 TC_U_ABORT_ REQ_VIA_TCI TERMINATED_ VIA_INTERN2 to all RSMs USER_REQUESTS DIALOGUE_ INITIATED

9 Page 9 Pages 210, figure 13.2/3 (sheet 5 of 11). Replace figure 13.2/3 (sheet 5 of 11) with the following figure: Figure 13.2/3 (sheet 5 of 11): Process MAP_DSM Process MAP_DSM 132_35(11) DIALOGUE_ INITIATED Figure 13.2/3 (sheet 5 of 11) TC_END_ IND AC name unchanged? User_info= MAP_Refuse PDU Result := Dialogue_ Refused Result := Dialogue_ Accepted Provider_reason := Abrmal_ MAP_Dialogue MAP_OPEN_ CNF_VIA _USER2 MAP_OPEN_ CNF_ VIA_USER2 MAP_P_ABORT_ IND_VIA_USER2 Components_ present PROCESS_ COMPONENTS MAP_CLOSE_ IND_ VIA_USER2 1 TERMINATED_ VIA_INTERN1 all active PSM TERMINATED_ VIA_INTERN2 all active RSM

10 Page 10 Pages 213, figure 13.2/3 (sheet 8 of 11). Replace figure 13.2/3 (sheets 8 of 11) with the following figure: Figure 13.2/3 (sheet 8 of 11): Process MAP_DSM Process MAP_DSM 132_38(11) Figure 13.2/3 (sheet 8 of 11) DIALOGUE_ INITIATED MAP_ CLOSE_ REQ TC_L_ CANCEL_ IND TC_END_ REQ_ VIA_TC1 pre-arranged MAP_OPEN_ CNF_ VIA_USER2 Accepted.The dialogue is considered implicitly accepted when something is received 1 INVOKEID_ ACTIVE FALSE TRUE 2 TIMER_ EXPIRY_ VIA_INTERN2 Set_Result := Dialogue_ Refused DIALOGUE_ INITIATED invalid_destination_ reference MAP_ Refuse_PDU error invalid_origination_ reference _reason_ given Set_Refuse_Reason := invalid_destination_ reference Set_Refuse_Reason := _reason_ given Set_Refuse_Reason := invalid_origination_ reference 3

11 Page 11 Page 652, subclause Replace the existing first paragraph with the following two new paragraphs: "If the confirmation contains a provider error the macro issues a MAP-CLOSE request and takes the provider error exit. Otherwise, if the confirmation contains a user error the macro takes the user error exit."

12 Page 12 Pages 654, figure 21.2/2. Replace figure 21.2/2 with the following figure: Figure 21.2/2 Macro Check_Confirmation 212_2(1) Figure 21.2/2: Macro to check the parameters of a confirmation primitive Provider error? Yes No MAP_CLOSE_ Req User error? Yes No Provider error Data missing? Yes No User error Unexpected data? Yes No Unexpected value? Yes No OK Data error

13 Page 13 History Document history February 1995 First Edition of ETS March 1995 Unified Approval Procedure UAP 26: to July 1995 Amendment 1 to First Edition of ETS (February 1995) January 1996 Note Converted into Adobe Acrobat Portable Document Format (PDF) The references to the changed pages in the standard refer to an old presentation. See history box at the end of the standard itself. The new presentation format, applied from 1 December 1995, might have different page numbering. The clause numbering has t changed. ISBN Amendement 1 Dépôt légal : Juillet 1995