CRs to GSM 03.03, 03.16, 09.02, 09.60, on GPRS

Transcription

1 SMG#28 Plenary Meeting Sophia Antipolis January, 1999 Tdoc SMG P Source : SMG3 Title : CRs to GSM 03.03, 03.16, 09.02, 09.60, on GPRS Proposed Agenda Item : Presented for : Approval Introduction : SPEC CR REV PHASE VERS SUBJECT CAT A014 1 R Alignment of GSM with GSM F A018 R Correction on ODB applicability for GPRS ph1 F A159 R ASN.1 Corrections F A171 2 R Inclusion of Check Indication macro in GPRS SDLs F A172 R Editorial corrections of the GPRS enhancement of MAP D A173 1 R Alignment of the FailureReport-Arg message with GSM F A174 R Correction on ODB applicability for GPRS ph1 F A179 1 R Alignment of the GSN-Address GSM ASN.1 definition F with the IPv4 or IPv6 view A185 R Clarification for MNRR F A188 1 R Correction of ASN.1 definition of PDP address F A195 R ASN.1 coding for Access Point name F A032 6 R GPRS Charging enhancements to GTP B A034 1 R Correction of used cipher IE F A035 2 R Improving restoration procedure between SGSN and GGSN C A036 1 R Addition of IMSI to SGSN Context Request F A037 1 R Corrections and clarifications of the GSM specification F A038 1 R Addition of IMSI to SGSN Context Request F A039 2 R Alignment of the GSM with GSM F A040 1 R Correction of the value of parameter LLC Frame number F within GTP header A041 R PDP context establishment and restoration F A042 R PDP Context IE F A043 R Removal of not defined cause TLLI Signature mismatch F A044 1 R Introduction of the PDP-type PPP B A045 1 R GTP/GTP Protocol Type bit B A048 R Introduction of the PDP type OSH:IHOSS B A002 R Reflection of new MAP chapters in the MAP handbook F

2 ETSI SMG3 WPC Tdoc 3C Austin, U.S.A January, 1999 Tdoc SMG3 3C CHANGE REQUEST No : A014r1 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS Source: SMG3 WPC Date: 15 January 1999 Subject: Alignment of GSM with GSM Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: This change request proposes the alignment of GSM with GSM 09.02, which defines the GSN-address as either IPv4 or IPv6. Currently, GSM specifies the SGSN address and GGSN address as IP addresses and ASN.1 defines the GSN-address as an OCTET STRING (SIZE (4..16)). GSM refers the reader to GSM for the encoding of the GSN Address. However, in GSM Section 5 states: The GSN Address is composed of the following elements: - The Address Type which is a fixed length code (of 2 bits) identifying the type of address that is used in the Address field. - Address Length which is a fixed length code (of 6 bits) identifying the length of the Address field. - Address is a variable length field with an IPv4 address, an IPv6 address or a logical name. Address Type 0 and Address Length 4 are used when Address is an IPv4 address. Address Type 1 and Address Length 16 are used when Address is an IPv6 address. Address Type 2 is used when Address is a logical name. The logical name can be up to 63 octets. A logical name may be converted to an IP address by using DNS. Further confusion is provided by GSM in which the GSN-address is defined as being an IP address of between 2 and 5 octets in length and the GSN address shown in Section (Figure 14) is an IPv4 address only. Clauses affected: 5.1 Other specs Other releases of same spec List of CRs: affected: Other core specifications X List of CRs: A014r1, A039r1 MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs:

3 ETSI SMG3 WPC Tdoc 3C Austin, U.S.A January, 1999 Other comments:

4 ETSI SMG3 WPC Tdoc 3C Austin, U.S.A January, Identification for routing purpose MSCs, GSNs and location registers are identified by international PSTN/ISDN numbers and/or Signalling Point Codes ("entity number", i.e., "HLR number", "VLR number", "MSC number", SGSN number and GGSN number ) in each GSM PLMN. Additionally SGSN, GGSN are identified by GSN Addresses. These are the SGSN Address and the GGSN Address. Domain Name System (DNS), which is a distributed database, can be used by external clients that need to identify and reach a GGSN. A GSN Address shall be composed as shown in figure 7a. GSN Address Address Type Address Length Address 2 bits 6 bits Up 4 to 163 octets Figure 7a: Structure of GSN Address The GSN Address is composed of the following elements: - The Address Type which is a fixed length code (of 2 bits) identifying the type of address that is used in the Address field. - Address Length which is a fixed length code (of 6 bits) identifying the length of the Address field. - Address is a variable length field with either an IPv4 address or, an IPv6 address or a logical name. Address Type 0 and Address Length 4 are used when Address is an IPv4 address. Address Type 1 and Address Length 16 are used when Address is an IPv6 address. Address Type 2 is used when Address is a logical name. The logical name can be up to 63 octets. A logical name may be converted to an IP address by using DNS. The IP v4 address structure is defined in RFC 791. The IP v6 address structure is defined in RFC The logical name structure is defined in GSM

5 ETSI SMG3 WPC Hungerford, United Kingdom 9 13 November Tdoc SMG3 WPC 98C618 CHANGE REQUEST No : A018 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS ph1 Source: SMG3 WPC Date: 13 November 98 Subject: Correction on ODB applicability for GPRS ph1 Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: ODBs applicability in GPRS was not completely covered in The CR completes the applicability of ODB data for GPRS services. Clauses affected: Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs: Other comments: 4.5.4

6 Consistency of supplementary service data In some cases, the protocol used between the HLR and VLR encodes some data that is not EBSGrelated SS data with an EBSG qualifier. In this case, the HLR shall ensure that when this data is sent it is always the same for all EBSGs. If this data is modified, the HLR must send the supplementary service data to the VLR for all EBSGs which meet all the following criteria: - at least one basic service in the EBSG is supported; and - the supplementary service is applicable to at least one (possibly different) basic service in the EBSG; and - the subscriber has a subscription to at least one (possibly different) basic service in the EBSG. Subscriber Status all OG-Calls Barred international OG-Calls Barred international OG-Calls Not To HPLMN Country Barred inter-zonal OG-Calls Barred inter-zonal OG-Calls Not To HPLMN Country Barred international OG-Calls Not To HPLMN Country AND inter-zonal OG-Calls Barred Premium Rate Information OG-Calls Barred Premium Rate Entertainment OG-Calls Barred SS Access Barred all call transfers Barred chargeable call transfers Barred international call transfers Barred inter-zonal call transfers Barred doubly chargeable call transfers Barred multiple call transfers Barred PLMN-Specific Barring Type 1 PLMN-Specific Barring Type 2 PLMN-Specific Barring Type 3 PLMN-Specific Barring Type 4 NOTE: For detailed information see GSM and GSM Figure 7: ODB Data for non-gprs services Subscriber Status all OG-Calls Barred international OG-Calls Barred international OG-Calls Not To HPLMN Country Barred inter-zonal OG-Calls Barred inter-zonal OG-Calls Not To HPLMN Country Barred international OG-Calls Not To HPLMN Country AND inter-zonal OG-Calls Barred PLMN-Specific Barring Type 1 PLMN-Specific Barring Type 2 PLMN-Specific Barring Type 3 PLMN-Specific Barring Type 4 NOTE: For detailed information see GSM and GSM Figure 7a: ODB Data for GPRS services

7 ETSI SMG3 WPC Hungerford 9-13 November 1998 A159 Tdoc SMG3 98C600 CHANGE REQUEST No : A159 Technical Specification GSM Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") Proposed change affects: SIM ME Network X (at least one should be marked with an X) Source: SMG3 WPC Work Item: GPRS Date: 13 November 98 Subject: ASN.1 Corrections Category: F Correction X Release: phase 2 A Corresponds to a correction in an earlier release release 96 (one category B Addition of feature release 97 X and one release C Functional modification of feature release 98 shall be marked D Editorial modification release 99 with an X) Reason for change: To correct errors from editing process. Clauses affected: , Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: (One or more may BSS test specifications List of CRs: be marked with an X) O&M specifications List of CRs: Other comments:

8 2 GSM V6.1.0 (1998) Location Cancellation This application context is used between HLR and VLR or between HLR and SGSN for location cancellation procedures. locationcancellationcontext-v3 APPLICATION-CONTEXT -- Responder is VLR or SGSN if Initiator is HLR INITIATOR CONSUMER OF { LocationCancellationPackage-v3} ::= {map-ac locationcancel(23) version3(3)} The following application-context-name is assigned to the v2-equivalent application-context: map-ac locationcancel(2) version2(2) 15 The following application-context-name is assigned to the v1-equivalent application-context: map-ac locationcancel(2) version1(1) Mobile Service Operations PurgeMS ::= OPERATION 23 ARGUMENT 24 purgems-arg 25 RESULT 26 purgems-res optional 28 ERRORS{ 29 DataMissing, 30 UnexpectedDataValue, 31 UnknownSubscriber} PurgeMS-Arg PurgeMS-Res --Timer m

9 ETSI SMG3 WPC Tdoc SMG3 3C Austin, U.S.A January, 1999 CHANGE REQUEST No : A171r2 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS Source: SMG3 WPC Date: 15 January 1999 Subject: Inclusion of Check Indication macro in GPRS SDLs Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: This change request adds the use of the Check Indication macros to the GPRS procedures SRIforGPRS, NoteMSPresentforGPRS and FailureReport. The purpose is to align the treatment of the MAP-indications with other GPRS SDLs. Clauses affected: , , Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs: Other comments:

10 Process in the HLR for Send Routing Information for GPRS The MAP process in the HLR to provide routing information for a network-requested PDP context activation is shown in figure 24.1/1. The MAP process invokes a macro not defined in this subclause; the definition of this macro can be found as follows: Receive_Open_Ind see subclause ; Check_Indication see subclause Successful outcome When the MAP process receives a MAP_OPEN indication with the application context gprslocationinforetrieval, it checks it by invoking the macro Receive_Open_Ind. If the macro takes the OK exit, the MAP process waits for a service indication. If a MAP_SEND_ROUTING_INFO_FOR_GPRS service indication is received, the HLR sends a Send Routing Info For Gprs request to the GPRS application process in the HLR, and wait for a response. The Send Routing Info For Gprs request contains the parameter received in the MAP_SEND_ROUTING_INFO_FOR_GPRS service indication If the GPRS application process in the HLR returns a positive response containing the routing information, the MAP process constructs a MAP_SEND_ROUTING_INFO_FOR_GPRS service response containing the routing info, constructs a MAP_CLOSE service request, sends them to the GGSN and returns to the idle state. Negative response from HLR GPRS application process If the GPRS application process in the HLR returns a negative response, the MAP process constructs a MAP_SEND_ROUTING_INFO_FOR_GPRS service response containing the appropriate error, constructs a MAP_CLOSE service request, sends them to the GGSN and returns to the idle state. Failure of dialogue opening with the GGSN If the macro Receive_Open_Ind takes the Vr exit or the Error exit, the MAP process returns to the idle state. If the MAP provider sends a MAP_P_ABORT while the MAP process is waiting for a service indication, the MAP process returns to the idle state. If the MAP provider sends a MAP_NOTICE while the MAP process is waiting for a service indication, the MAP process sends a MAP_CLOSE request to terminate the dialogue and returns to the idle state.

11 Process Send_Routing_Info_For_Gprs_HLR Figure 24.1/1: The Send Routing Info For Gprs process in the HLR Signals to/from the right are to/from the G PRS application process 24.1_1(1) Idle Receive_ Open_Ind Section 25.1 OK Wait_For_ Service_ Indication Idle Vr, Error MAP_P_ ABORT_ind MAP_SEND_ROUTING_INFO_ FOR_GPRS_ind MAP_ NOTICE_ind Idle Send Routing Info For Gprs Wait for Routing Info MAP_ CLOSE_req Idle Send Routing Info For Gprs negative res ponse Send Routing Info For Gprs Ack Set UE Set Routing Info MAP_SEND_ROUTING_INFO_FOR_GPRS_rsp, MAP_CLOSE_req Idle

12 Process Send_Routing_Info_For_Gprs_HLR 24.1_1(1) Fig ure 24.1/1: The Se nd Rou tin g In fo Fo r GP RS pro ce ss in th e HL R Sig na ls to /from th e righ t are to /from the GPRS application process Id le Receive_ Open_Ind Section 25.1 OK Vr, Error Wait_For_ Service_ Indication Idle MAP_P_ ABORT_ind MAP_SEND_ROUTING_ INFO_FOR_GPRS_ind MA P_ NOTICE_ind Idle Check Indication Section 25.2 MA P_ CL OSE _req OK Error Send Routing Info For Gprs Idle Wait for Routing Info Send Routing In fo For Gp rs negative response Send Routing Info For Gprs Ack Set UE Set Routing In fo MAP_SEND_ROUTING_INFO_FO R_GPRS_rsp, MAP_CLOSE _req Id le Figure 24.1/1: Process Send Routing Info For Gprs_HLR

13 Process in the HLR for Failure Report The MAP process in the HLR to set the MNRG (Mobile station Not Reachable for GPRS) flag for the subcriber is shown in figure 24.2/1. The MAP process invokes a macro not defined in this subclause; the definition of this macro can be found as follows: Receive_Open_Ind see subclause ; Check_Indication see subclause Successful outcome When the MAP process receives a MAP_OPEN indication with the application context failurereport, it checks it by invoking the macro Receive_Open_Ind. If the macro takes the OK exit, the MAP process waits for a service indication. If a MAP_FAILURE_REPORT service indication is received, the HLR sends a Failure Report request to the GPRS application process in the HLR, and wait for a response. The Failure Report request contains the parameter received in the MAP_FAILURE_REPORT service indication. If a positive response is received, the MAP process constructs a MAP_FAILURE_REPORT service response, constructs a MAP_CLOSE service request, sends them to the GGSN and returns to the idle state. Negative response from HLR GPRS application process If the GPRS application process in the HLR returns a negative response, the MAP process constructs a MAP_FAILURE_REPORT service response containing the appropriate error, constructs a MAP_CLOSE service request, sends them to the GGSN and returns to the idle state. Failure of dialogue opening with the GGSN If the macro Receive_Open_Ind takes the Vr exit or the Error exit, the MAP process returns to the idle state. If the MAP provider sends a MAP_P_ABORT while the MAP process is waiting for a service indication, the MAP process returns to the idle state. If the MAP provider sends a MAP_NOTICE while the MAP process is waiting for a service indication, the MAP process sends a MAP_CLOSE request to terminate the dialogue and returns to the idle state.

14 Pro ces s Failure_Repo rt_hlr 24.2_1(1) Figure 24.2/1: The Failure Report process in the HLR Signals to/from the right are to/from the G PRS application process Idle Receive_ Open_Ind Section 25.1 OK Vr, Error Wait_For_ Service_ Indication Idle MAP_P_ ABORT_ind MAP_FAILURE_ REPORT_ind MAP_ NOTICE_ind Idle Failure Report Wait for response MAP_ CLOSE_req Idle Failure Report negative res ponse Failure Report Ack Set UE MAP_FAILURE_REPORT_rsp, MAP_CLOSE_req Idle

15 Process Failure_Report_HLR 24.2_1(1) Figure 24.2/1: The Failure Report process in the HLR Sig na ls to /from th e righ t are to/from the GPRS application process Id le Receive_ Open_Ind Section 25.1 OK Vr, Error Wait_For_ Service_ Indication Idle MAP _P _ ABORT_ind MAP_FAILURE_ REPORT_ind MA P_ NOTICE_ind Idle Check Indication Section 25.2 MA P_ CL OSE _req OK Error Failure Report Idle Wait for response Failure Report ne gative response Failure Report Ack Set UE MAP_FAILURE_REPORT_rsp, MAP_CLOSE _req Id le Figure 24.2/1: Process Failure_Report_HLR

16 Process in the GGSN for Note Ms Present For Gprs The MAP process in the GGSN to inform that the subscriber is present for GPRS again is shown in figure 24.3/1. The MAP process invokes a macro not defined in this subclause; the definition of this macro can be found as follows: Receive_Open_Ind see subclause ; Check_Indication see subclause Successful outcome When the MAP process receives a MAP_OPEN indication with the application context gprsnotify, it checks it by invoking the macro Receive_Open_Ind. If the macro takes the OK exit, the MAP process waits for a service indication. If a MAP_NOTE_MS_PRESENT_FOR_GPRS service indication is received, the GGSN sends a Note Ms Present For Gprs request to the GPRS application process in the GGSN, and wait for a response. The Note Ms Present For Gprs request contains the parameter received in the MAP_NOTE_MS_PRESENT_FOR_GPRS service indication. If the GPRS application process in the GGSN returns a positive response, the MAP process constructs a MAP_NOTE_MS_PRESENT_FOR_GPRS service response, constructs a MAP_CLOSE service request, sends them to the HLR and returns to the idle state. Negative response from GGSN GPRS application process If the GPRS application process in the GGSN returns a negative response, the MAP process constructs a MAP_NOTE_MS_PRESENT_FOR_GPRS service response containing the appropriate error, constructs a MAP_CLOSE service request, sends them to the HLR and returns to the idle state. Failure of dialogue opening with the HLR If the macro Receive_Open_Ind takes the Vr exit or the Error exit, the MAP process returns to the idle state. If the MAP provider sends a MAP_P_ABORT while the MAP process is waiting for a service indication, the MAP process returns to the idle state. If the MAP provider sends a MAP_NOTICE while the MAP process is waiting for a service indication, the MAP process sends a MAP_CLOSE request to terminate the dialogue and returns to the idle state.

17 Process Note_Ms_Present_For_Gprs_GGSN 24.3_1(1) Figure 24.3/1: The Note Ms Present For Gprs process in the HLR Signals to/from the right are to/from the G PRS application process Idle Receive_ Open_Ind Section 25.1 OK Wait_For_ Service_ Indication Idle Vr, Error MAP_P_ ABORT_ind MAP_NOTE_MS_PRESENT_ FOR_GPRS_ind MAP_ NOTICE_ind Idle Note Ms P resent For Gprs Wait for response MAP_ CLOSE_req Idle Note Ms Present For G prs negative response Note Ms Present For Gprs Ack Set UE MAP_NOTE_MS_PRESENT_FOR_GPRS_rsp, MAP_CLOSE_req Idle

18 Process Note_Ms_Present_For_Gprs_GGSN 24.3_1(1) Fig ure 24.3/1: The No te Ms Pre sent Fo r G prs p ro cess in the HLR Sig nal s to /from th e righ t are to/from the GPRS application process Id le Receive_ Open_Ind Section 25.1 OK Vr, Error Wait_For_ Service_ Indication Idle MAP _P _ ABORT_ind MAP_NO TE_MS_PRES ENT_ FOR_GPRS_ind MA P_ NOTICE_ind Idle Check Indication Section 25.2 MA P_ CL OSE _req OK Error Note Ms Present For Gprs Idle Wait for response Note Ms Present For G prs negative response Note Ms Present For Gprs Ack Set UE MAP_NO TE_MS_PRES ENT_FOR_GPRS_rsp, MAP_CLOSE _req Id le Figure 24.3/1: Process Note_Ms_Present_For_Gprs_GGSN

19 ETSI SMG3 WPC Hungerford, U.K November, 1998 Tdoc SMG3 98C682 CHANGE REQUEST No : A172 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS Source: SMG3 WPC Date: 9 November 98 Subject: Editorial corrections of the GPRS enhancement of MAP Category: F Correction Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification X Release 99 marked with an X) UMTS Reason for change: This change request presents two editorial corrections. The first modification is to recognise that PURGE-MS is defined at MAP version 2 and version 3 in GSM 97. The second modification concerns the decision box in the SDL in figure 20.3/10. Clauses affected: , Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs: Other comments:

20 Detailed procedure in the HLR Opening of the dialogue is described in the macro Receive_Open_Ind in subclause The possible outcomes are: - termination of the procedure if the AC indicates a version 1 dialogue, as this procedure is not defined only for version 12; - termination of the procedure if there is an error; - dialogue acceptance, in which case the procedure is as described below. If the HLR receives a MAP_NOTICE indication, it terminates the dialogue by sending a MAP_CLOSE request. If the HLR receives a MAP_PURGE_MS indication (see figure /3), it first checks the indication data (macro Check_Indication, see subclause 25.2). If there is a parameter error the HLR terminates the dialogue by sending a MAP_CLOSE request (local termination). If there is no parameter error the HLR then checks whether the subscriber is known. - if the subscriber is unknown, the HLR reports an error to the O&M interface, and terminates the dialogue by sending a MAP_CLOSE request (local termination); - if the subscriber is known, the HLR checks whether the purging notification came from the VLR or SGSN where the MS was last registered: - if the received VLR number and the stored VLR number match, the HLR sets the "MS purged for non-gprs" flag for the subscriber and sends a MAP_PURGE_MS response containing a freeze TMSI indicator to indicate successful outcome; - if the received VLR number and the stored VLR number do not match, the HLR sends a MAP_PURGE_MS response containing an empty result to indicate successful outcome. Since the MS is known by the HLR to be in a different VLR area, it is not appropriate to block mobile terminated calls or short messages to the MS, but the VLR which initiated the purging procedure can safely purge its record for the MS without freezing the TMSI. - if the received SGSN number and the stored SGSN number match, the HLR sets the "MS purged for GPRS" flag for the subscriber and sends a MAP_PURGE_MS response containing a freeze P-TMSI indicator to indicate successful outcome; - if the received SGSN number and the stored SGSN number do not match, the HLR sends a MAP_PURGE_MS response containing an empty result to indicate successful outcome. Since the MS is known by the HLR to be in a different SGSN area, it is not appropriate to block short messages to the MS, but the SGSN which initiated the purging procedure can safely purge its record for the MS without freezing the P-TMSI. In either cases of successful termination the HLR terminates the dialogue by sending a MAP_CLOSE request.

21 NEXT SECTION TO BE MODIFIED: Macrodefinition Delete_GPRS_Subscriber_Data_HLR 20.3_10(1) Figure 20.3/10: The delete GPRS subscriber data macro in the HLR MAP_OPEN_req MAP_DELETE_SUBSCRIBER_DATA_req MAP_DELIMITER Receive_ Open_Cnf OK Vr, Error Wait_For Confirm MAP_DELETE SUBSCRIBER DATA_cnf MAP_NOTICE ind MAP_U_ABORT_ind, MAP_P_ABORT_ind, MAP_CLOSE_ind MAP_CLOSE req Error yes no no yes MSCSGSN_Area_Restricted_receive dor "Roaming_Restricted_In_SSGN_Due_To_Unsupported_Feature" SGSN_Area Restricted_Flag = not_restricted SGSN_Area Restricted_Flag = restricted OK Error Figure 20.3/10: Macro Delete_GPRS_Subscriber_Data_HLR

22 ETSI SMG3 WPC Tdoc SMG3 3C Austin, U.S.A January, 1999 CHANGE REQUEST No : A173r1 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS Source: SMG3 WPC Date: 15 January 1999 Subject: Alignment of the FailureReport-Arg message with GSM Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: This change request proposes to make the GGSN Number information element in the MAP-FAILURE-REPORT argument mandatory, which is implicit in GSM v Without the optional information elements, the Failure Report message ONLY services to inform the HLR that an attempt to perform Network Requested PDP Context activation towards a particular IMSI failed. The receipt of the Failure Report message causes the update of the MNRG flag at the HLR but since no GGSN number was supplied the GGSN concerned cannot be alerted when the MS becomes reachable again. Clauses affected: , Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs: Other comments:

23 *** Next modified section *** GGSN number This parameter refers to the ISDN number of a GGSN or the ISDN number of the protocol-converter if a protocol-converting GSN is used between the GGSN and the HLR. *** Next modified section *** 13.2 MAP_FAILURE_REPORT service Definition This service is used by the GGSN to inform the HLR that network requested PDP-context activation has failed Service primitives Table 13.2/1: MAP_FAILURE_REPORT Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) GGSN address C C(=) GGSN number CM CM(=) User error C C(=) Provider error O Parameter definition and use Invoke Id See definition in subclause IMSI See definition in subclause GGSN address This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR. GGSN number See definition in subclause User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Data Missing; - Unexpected Data Value; - UnknownSubscriber. Provider error These are defined in subclause failure report types *** Next modified section : *** FailureReportArg ::= SEQUENCE { imsi ggsn-number OPTIONAL, ggsn-address OPTIONAL, extensioncontainer OPTIONAL,...} [0] IMSI, [1] ISDN-AddressString [2] GSN-Address [3] ExtensionContainer

24 FailureReportRes ::= SEQUENCE { extensioncontainer OPTIONAL,...} [0] ExtensionContainer -- gprs notification types

25 ETSI SMG3 WPC Hungerford, United Kingdom 9 13 November Tdoc SMG3 98C619 CHANGE REQUEST No : A174 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") X PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS ph1 Source: SMG3 WPC Date: Subject: Correction on ODB applicability for GPRS ph1 Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: ODB of International outgoing calls except to HPLMN barred is also applicable to GPRS ph1 functionality, and it was not included in Clauses affected: Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs: Other comments:

26 Operator Determined Barring General Data This parameter refers to the set of subscribers features that the network operator or the service provider can regulate. This set only includes those limitations that can be controlled in the VLR or in the SGSN: - All outgoing calls barred; (*) - International outgoing calls barred; (*) - International outgoing calls except those to the home PLMN country barred; (*) - Interzonal outgoing calls barred; (*) - Interzonal outgoing calls except those to the home PLMN country barred; (*) - Interzonal outgoing calls AND intenational outgoing calls except those directed to the home PLMN country barred; (*) - Premium rate (information) outgoing calls barred; - Premium rate (entertainment) outgoing calls barred; - Supplementary service access barred; - Invocation of call transfer barred; - Invocation of chargeable call transfer barred; - Invocation of internationally chargeable call transfer barred; - Invocation of interzonally chargeable call transfer barred; - Invocation of call transfer where both legs are chargeable barred. (*) Only these ODBs are supported by the SGSN. The SGSN applies them only for short message transfer.

27 ETSI SMG3 WPC Tdoc 3C Austin, U.S.A January, 1999 Tdoc SMG3 3C CHANGE REQUEST No : A179r1 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS Source: SMG3 WPC Date: 15 January 1999 Subject: Alignment of the GSN-Address GSM ASN.1 definition with the IPv4 or IPv6 view. Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: This change request proposes the alignment of the GSN-Address GSM ASN.1 definition with the description that the GSN-address is either IPv4 or IPv6. Currently, GSM specifies the SGSN address and GGSN address as IP addresses and ASN.1 defines the GSN-address as an OCTET STRING (SIZE (4..16)). GSM refers the reader to GSM for the encoding of the GSN Address. However, in GSM 03.03, Section 5 states: The GSN Address is composed of the following elements: - The Address Type which is a fixed length code (of 2 bits) identifying the type of address that is used in the Address field. - Address Length which is a fixed length code (of 6 bits) identifying the length of the Address field. - Address is a variable length field with an IPv4 address, an IPv6 address or a logical name. Address Type 0 and Address Length 4 are used when Address is an IPv4 address. Address Type 1 and Address Length 16 are used when Address is an IPv6 address. Address Type 2 is used when Address is a logical name. The logical name can be up to 63 octets. A logical name may be converted to an IP address by using DNS. Further confusion is provided by GSM in which the GSN-address is defined as being an IP address of between 2 and 5 octets in length and the GSN address shown in Section (Figure 14) is an IPv4 address only. Clauses affected: Other specs Other releases of same spec List of CRs: affected: Other core specifications X List of CRs: A039r1, A014r1 MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs:

28 ETSI SMG3 WPC Tdoc 3C Austin, U.S.A January, 1999 Other comments: **** Modified Section: **** GSN-Address ::= OCTET STRING (SIZE ( )) -- Octets are coded according to TS GSM 03.03

29 ETSI SMG3 WPC Tdoc SMG3 3C Austin, Texas, USA January 1999 CHANGE REQUEST No : A185 Technical Specification GSM Version Submitted to SMG 3 for approval X Without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS Source: SMG3 WPC Date: 15 January 1999 Subject: Clarification for MNRR Category: F Correction X Release: phase 2 A Corresponds to a correction in an earlier release release 96 (one category B Addition of feature release 97 X and one release C Functional modification of feature release 98 shall be marked D Editorial modification release 99 with an X) G Addition of new test (only for test specifications) Reason for change: MNRR includes also non-gprs information in GSM but only the GPRSinformation is described currently in GSM This CR aligns GSM and GSM Clauses affected: , Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: (One or more may BSS test specifications List of CRs: be marked with an X) O&M specifications List of CRs: Other comments:

30 QoS-Subscribed This parameter indicates the quality of service subscribed for a certain service. It is defined in GSM VPLMN address allowed This parameter specifies whether the MS is allowed to used a dynamic address allocated in the VPLMN. It is defined in GSM Roaming Restricted In SGSN Due To Unsupported Feature This parameter defines that a subscriber is not allowed to roam in the current SGSN area. It may be used by the HLR if a feature or service is indicated as unsupported by the SGSN Network Access Mode This parameter is defined in GSM Mobile Not Reachable Reason This parameter stores the reason for the MS being absent when an attempt to deliver a short message to an MS fails at the MSC, SGSN or both. It is defined in TS GSM indicates the reason for the setting of the MNRG flag stored in the MNRR. The parameter contains the following information described in GSM 03.40: - No Paging Response - Mobile Station detached - Unidentified Subscriber Cancellation Type This parameter indicates the reason of location cancellation. It is defined in TS GSM All GPRS Data This parameter indicates to the SGSN that all GPRS Subscription Data shall be deleted for the subscriber Complete Data List Included This parameter indicates to the SGSN that the complete GPRS Subscription Data stored for the Subscriber shall be replaced with the GPRS Subscription Data received PDP Context Identifier This parameter is used to identify a PDP context for the subscriber.

31 12 Short message service management services 12.1 MAP-SEND-ROUTING-INFO-FOR-SM service Definition This service is used between the gateway MSC and the HLR to retrieve the routing information needed for routing the short message to the servicing MSC. The MAP-SEND-ROUTING-INFO-FOR-SM is a confirmed service using the primitives from table 12.1/ Service primitives The service primitives are shown in table 12.1/1. Table 12.1/1: MAP-SEND-ROUTING-INFO-FOR-SM Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) SM-RP-PRI M M(=) Service Centre Address M M(=) SM-RP-MTI C C(=) SM-RP-SMEA C C(=) GPRS Support Indicator C C(=) IMSI C C(=) Network Node Number C C(=) LMSI C C(=) GPRS Node Indicator C C(=) Additional Number C C(=) User error C C(=) Provider error O Parameter use Invoke id: See definition in subclause MSISDN: See definition in subclause SM-RP-PRI: See definition in subclause Service Centre Address: See definition in subclause SM-RP-MTI : See definition in subclause This parameter shall be present when the feature «SM filtering by the HPLMN» is supported by the SMS-GMSC and when the equivalent parameter is received from the short message service relay sublayer protocol. SM-RP-SMEA: See definition in subclause This parameter shall be present when the feature «SM filtering by the HPLMN» is supported by the SMS-GMSC and when the equivalent parameter is received from the the short message service relay sub-layer protocol. GPRS Support Indicator: See definition in subclause The presence of this parameter is mandatory if the SMS-GMSC supports receiving of the two numbers from the HLR. IMSI: See definition in subclause The presence of this parameter is mandatory in a successful case. Network Node Number: See definition in subclause This parameter is provided in a successful response. LMSI: See definition in subclause It is an operator option to provide this parameter from the VLR; it is mandatory for the HLR to include the LMSI in a successful response, if the VLR has used the LMSI. GPRS Node Indicator: See definition in subclause The presence of this parameter is mandatory if only the SGSN number is sent in the Network Node Number. Additional Number: See definition in subclause This parameter is provided in a successful response. User error: The following errors defined in subclause may be used, depending on the nature of the fault: - Unknown subscriber;

32 - Call Barred; - Teleservice Not Provisioned; - Absent Subscriber_SM; - Facility Not Supported; - System failure; - Unexpected Data Value; - Data missing. Provider error: For definition of provider errors see subclause

33 ETSI SMG3 WPC Tdoc SMG3 3C Texas, USA January CHANGE REQUEST No : A188r1. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") X PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS ph1 Source: SMG3 WPC Date: 15 January 1999 Subject: Correction of ASN.1 definition of PDP address Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: Corrections to clarify how PDP-Address shall be coded. The minimum size of PDP- Address parameter is changed to 1, instead of 4, to support all possible X.25 addresses according to GSM Clauses affected: Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs: Other comments:

34 Mobile Service data types PDP-Address ::= OCTET STRING (SIZE (14..16)) -- Octets are coded according to TS GSM The possible size values are: octets X.25 address type -- 4 octets IPv4 address type octets Ipv6 address type

35 ETSI SMG3 WPC Tdoc SMG3 3C Sophia Antipolis, January 1999 CHANGE REQUEST No : A195 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") X PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS ph1 Source: SMG3 WPC Date: 26 January 1999 Subject: ASN.1 coding for Access Point name Category: F Correction X Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature Release 97 X and one release C Functional modification of feature Release 98 only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: This CR proposes the following ASN.1 coding for the APN to align to the definition of APN in Since the DNS name contains binary data in the label length octets, it is suggested to use OCTET STRING rather than IA5String. The information that the labels themselves are coded in ASCII is specified in TS Clauses affected: Other specs Other releases of same spec List of CRs: affected: Other core specifications List of CRs: MS test specifications / TBRs List of CRs: BSS test specifications List of CRs: O&M specifications List of CRs: Other comments:

36 Mobile Service data types PDP-Context ::= SEQUENCE { pdp-contextid ContextId, pdp-type [16] PDP-Type, pdp-address [17] PDP-Address OPTIONAL, qos-subscribed [18] QoS-Subscribed, vplmnaddressallowed [19] NULL OPTIONAL, apn [20] APN, extensioncontainer [21] ExtensionContainer OPTIONAL,...} APN ::= IA5String (SIZE (1..63)) OCTET STRING (SIZE (2..63)) -- Octets are coded according to TS GSM }

37 ETSI SMG3 WPC Tdoc SMG3 3C Austin, U.S.A January 1999 CHANGE REQUEST No : A032r6 Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly. Technical Specification GSM / UMTS: Version Submitted to SMG 3 for approval X without presentation ("non-strategic") list plenary meeting or STC here for information with presentation ("strategic") PT SMG CR cover form. Filename: crf26_3.doc Proposed change affects: SIM ME Network X (at least one should be marked with an X) Work item: GPRS Source: SMG3 WPC Date: 15 January 1999 Subject: GPRS Charging enhancements to GTP Category: F Correction Release: Phase 2 A Corresponds to a correction in an earlier release Release 96 (one category B Addition of feature X Release 97 and one release C Functional modification of feature Release 98 X only shall be D Editorial modification Release 99 marked with an X) UMTS Reason for change: To specify the optional parameter Charging Gateway Address, to be used for accumulating the charging records. To assist the specification of the charging protocol interface between a CDR generating node and the Charging Gateway Functionality. Clauses affected: Section 4 General: Fig. 1, and the related text, has been updated to cover charging protocol issues as well. Section 7.2 Signalling Message Formats: 6 new message types (Node Alive Request, Node Alive Response, Redirection Request, Redirection Response, Data Record Transfer Request and Data Record Transfer Response). Section Create PDP Context Response: One new information element is added to the message type: the Charging Gateway Address (optional). Section Update PDP Context Response: One new information element is added to the message type: the Charging Gateway Address (optional). Section Create AA PDP Context Response: One new information element is added to the message type: the Charging Gateway Address (optional). Section 7.9 Information elements: The TLV/TV Information Element number ranges reserved for GPRS charging are allocated. Section Cause: The Cause value number ranges reserved for GPRS charging are allocated. Section Charging Gateway Address: New section that defines the format of the Charging Gateway Address information element. Other specs Other releases of same spec List of CRs: affected: Other core specifications X List of CRs: GSM 12.15

38 MS test specifications / TBRs BSS test specifications O&M specifications List of CRs: List of CRs: List of CRs: Other comments: Changes from release 4 of this CR: -Linkage to GSM shown in the cover page. -Section 4, second paragraph, last sentence, and GTP removed. -GSN-CGF interface naming (Gn )

39 4 General This document defines the GPRS Tunnelling Protocol (GTP), i.e. the protocol between GSN nodes in the GPRS backbone network. It includes both the GTP signalling and data transfer procedures. It also lists the messages and information elements used by the GTP based charging protocol GTP, which is described in GSM GTP is defined both for the Gn interface, i.e. the interface between GSNs within a PLMN, and the Gp interface between GSNs in different PLMNs. GTP is defined for the interface between CDR generating functional network elements and Charging Gateway(s) within a PLMN. Charging Gateway(s) and GTP protocol are optional, as the Charging Gateway Functionalities may either be located in separate network elements (Charging Gateways), or alternatively be embedded into the CDR generating network elements (GSNs) when the GSN-CGF interface is not necessarily visible outside the network element. These interfaces relevant to GTP are between the grey boxes shown in the figure below. Charging Gateway Functionality GTP-MAP protocol converting GSN Gr or Gc HLR Gn SGSN Gn Gn Gc R Um TE MT BSS Gb SGSN Gn Gn GGSN Gp Gi PDN TE R Um TE MT BSS Gb SGSN Other PLMN Signalling Interface Signalling and Data Transfer Interface Figure 1: GPRS Logical Architecture with interface name denotations GTP allows multiprotocol packets to be tunnelled through the GPRS Backbone between GPRS Support Nodes (GSNs). In the signalling plane, GTP specifies a tunnel control and management protocol which allows the SGSN to provide GPRS network access for a MS. Signalling is used to create, modify and delete tunnels. In the transmission plane, GTP uses a tunnelling mechanism to provide a service for carrying user data packets. The choice of path is dependent on whether the user data to be tunnelled requires a reliable link or not. The GTP protocol is implemented only by SGSNs and GGSNs. No other systems need to be aware of GTP. GPRS MSs are connected to a SGSN without being aware of GTP. It is assumed that there will be a many-to-many relationship between SGSNs and GGSNs. A SGSN may provide service to many GGSNs. A single GGSN may associate with many SGSNs to deliver traffic to a large number of geographically diverse mobile stations.

40 7.2 Signalling Message Formats GTP defines a set of signalling messages between two associated GSNs. The signalling messages to be used are defined in the table below.