Change Requests to GSM Clarification and Modification of SMS handling

Transcription

1 ETSI TC SMG # 22 Plenary Meeting Kristiansand, Norway 9th - 13th June 1997 Tdoc SMG 379/ 97 Source: SMG3 Agenda Item: 6.3 Change Requests to GSM Clarification and Modification of SMS handling Introduction: The following CRs to GSM phase 2 and phase 2+ remove some inconsistencies between the textual description, ASN.1 and the SDL diagrams for the MAP_REPORT_SM_DELIVERY_STATUS operation. The changes are meant to be neutral to existing implementations. SPEC VERS CR R E V PHAS E CA T SUBJECT A F Clarify handling of result of ReportSMDeliveryStatus A A Clarify handling of result of ReportSMDeliveryStatus STC_DOC strat egic 97C251 97C252 Yes Yes The following CR provides for the capability to convey SMS user data in RP-ACK also in the network to user direction for MO SMS. (Due to a misunderstanding this was introduced by the earlier CR A063 only in the other direction, creating misalignment to GSM 03.40) A F Modifications due to SMS inconsistencies with GSM C264 Yes Other Comments: Number of Pages:

2 Blank Page

3 CHANGE REQUEST No. _A076r1_ Technical Specification GSM version Submitted to SMG for approval without presentation ("non-strategic") [ ] with presentation ("strategic") [ X ] Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Phase 1: [ ] Phase 2: [x ] Phase 2+: [ ] Work item: Other phase(s) affected: [ ] If yes, linked CR(s): Proposed change affects: SIM [ ] ME [ ] Network [x] Source: SMG3 WPC Date: 29 April 1997 Subject: Clarify handling of result of ReportSMDeliveryStatus Category: F - Correction [x] A - Corresponds to a Phase 2 correction [ ] B - Addition of Feature [ ] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: For the MAP_REPORT_SM_DELIVERY_STATUS operation, there are inconsistencies between the text in the detailed procedure handling section and 1) the service description, 2) the ASN.1 description of the operation and 3) the handling of the operation in the SDLs. Sections affected, and additional explanation of details of change (if needed): See other comments. Attached revised pages: Page(s): 159, 265 and If other core Specifications are affected, necessary (and attached) Joint CRs: Affects (possibly): MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ] Attached CRs?: Cross Phase Compatibility: Change affects operation of: Change affects operation of: Other comments: The text of Section , The macro Report_SM_Delivery_Stat_HLR, gives the detailed procedures in the HLR for the handling of the ReportSM-DeliveryStatus operation. The section contains a text description of the handling of the ReportSM-DeliveryStatus Result (i.e., the storedmsisdn parameter). One item states under which conditions the result will contain the storedmsisdn parameter, and reads as follows: - if the SM Delivery Outcome reports unsuccessful delivery and the message waiting list is not full, the given Service Centre address is inserted and an acknowledgement is sent to the GMSC. If the MSISDN-Alert stored in the subscriber data is not the same as that received in the

4 MAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a response primitive to the GMSC; This section provides for 3 conditions under which the storedmsisdn parameter is populated: 1) Unsuccessful delivery of a short message 2) Message waiting list is not full 3) MSISDN-Alert in subscriber data not equal to that received in ReportSM-DeliveryStatus invoke. Only if all three conditions are met will the MSISDN-Alert value stored in the MWD data for the subscriber be sent in the storedmsisdn parameter of the ReportSM-DeliveryStatus result. The corresponding GMSC section, , Procedures in the gateway MSC specifies the procedures for sending, from the GMSC, the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR and receiving the result. A portion of the text reads as follows: The GMSC sends the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR. As a response the GMSC will receive the MAP_REPORT_SM_DELIVERY_STATUS confirmation reporting: - successful outcome of the procedure. The acknowledge primitive may contain the MSISDN-Alert number which is stored in the MWD List in the HLR; The GMSC, according to the text may receive the MSISDN-Alert, and thus is aligned with the text in section which states that this parameter is sent optionally under the conditions previously mentioned. There are three sections that need to be aligned with the text sections just cited , section , contains the MAP-REPORT-SM-DELIVERY-STATUS service description, and states that the MSIsdn-Alert parameter is mandatory in the response for successful completion of the operation. This clearly is not consistent with the procedures section in Chapter 20 and needs to be aligned. 2. Section , Short message service operations, contains the ASN.1 definition of the ReportSM- DeliveryStatus operation. The Result of this operation is the storedmsisdn parameter, which is of type ISDN-AddressString. The notes for this operation state that the storedmsisdn parameter must be absent for version 1 and must be present for versions greater than 1. These notes state that for version 2, the storedmsisdn parameter must always be present in the ReportSM-DeliveryStatus result (i.e., unconditionally). This section also needs to be modified to align it with the procedures section. 3. Figure 20.6/1 contains the macro Report_SM_Delivery_Stat_HLR. This SDL performs the first two checks listed above, i.e., checks for unsuccessful delivery of short message and message waiting list not full, but does not make the third check i.e., checking if the MSISDN-Alert in subscriber data is the same as that received in the ReportSM-DeliveryStatus. The SDL, based on the first two checks always sets the storedmsisdn parameter of the result. As just noted, the text specifies a third condition which must be met before the storedmsisdn parameter is included in the result, and this check should be added to the SDL to align the SDL with the text. All of the original sections for the above 3 cases are included in the Attached original pages section. The modified sections are shown in the following pages.

5 From 09.02, Section 10.3, page 159: 10.3 MAP-REPORT-SM-DELIVERY-STATUS service Definition This service is used between the gateway MSC and the HLR. The MAP-REPORT-SM-DELIVERY- STATUS service is used to set the Message Waiting Data into the HLR or to inform the HLR of successful SM transfer after polling. This service is invoked by the gateway MSC. The MAP-REPORT-SM-DELIVERY-STATUS service is a confirmed service using the service primitives given in table 10.3/ Service primitives The service primitives are shown in table 10.3/1. Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) Service Centre Address M M(=) SM Delivery Outcome M M(=) MSIsdn-Alert C C(=) User error C C(=) Provider error O Parameter use Invoke id: See definition in subclause MSISDN: See definition in subclause Service Centre Address: See definition in subclause SM Delivery Outcome: Table 10.3/1: MAP-REPORT-SM-DELIVERY-STATUS See definition in subclause This parameter indicates the status of the mobile terminated SM delivery. MSIsdn-Alert: See definition in subclause The presence of tthis parameter is mandatoryshall be present in case of unsuccessful delivery, outcome of the service when the MSISDN received in the operation is different from the stored MSIsdn-Alert; the stored MSIsdn-Alert is the value that is returned to the gateway MSC..

6 From Section , page 265: ReportSM-DeliveryStatus ::= OPERATION ARGUMENT reportsm-deliverystatusarg ReportSM-DeliveryStatusArg RESULT storedmsisdn ISDN-AddressString -- optional -- storedmsisdn must be absent in version 1 -- storedmsisdn must be present in version greater 1 ERRORS { DataMissing, -- DataMissing must not be used in version 1 UnexpectedDataValue, UnknownSubscriber, MessageWaitingListFull} --Timer s From Section , pages : The macro Report_SM_Delivery_Stat_HLR This macro is used when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication from the GMSC. The HLR responses to the indication as follows: - if invalid data content is detected, an unexpected data value error or a data missing error is returned to the GMSC; - if the MSISDN number provided is not recognized by the HLR, an unknown subscriber error is returned to the GMSC; - if the MAP_REPORT_SM_DELIVERY_STATUS indication reports a successful SM delivery, the Service Centres in the Message Waiting list are alerted as described in the subclause 21.10; - if the SM Delivery Outcome reports unsuccessful delivery and the inclusion of the SC address in the MWD is not possible, a message waiting list full error is returned to the GMSC; - if the SM Delivery Outcome reports unsuccessful delivery and the message waiting list is not full, the given Service Centre address is inserted and an acknowledgement is sent to the GMSC. If the MSISDN-Alert stored in the subscriber data is not the same as that received in the MAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a response primitive to the GMSC; - if the SM Delivery Outcome is MS memory capacity exceeded the HLR sets the memory capacity exceeded flag in the subscriber data and resets the MRNF; - if the SM Delivery Outcome is absent subscriber the HLR sets the mobile station not reachable flag in the subscriber data. The short message delivery status report macro in the HLR is shown in figure 20.6/1.

7 Figure 20.6/1 Check_ Indication OK Error 'Subscriber known' No Yes Successful Transfer Delivery Outcome 'SET UE = UNKNOWN SUBSCRIBER' 'Clear MCEF and MNRF' Unsuccessful transfer 'Update Message Waiting Data' MAP_REPORT_SM_ DELIVERY_STATUS_rsp MAP_CLOSE_req No MSISDN = MSISDN Alert? Yes 'Storing successful' Yes No Alert_ Service_ Centre_HLR 'Set MSISDN- Alert Parameter 'SET UE = MESSAGE WAITING LIST FULL' Delivery Outcome MAP-REPORT_SM DELIVERY_STATUS_rsp MAP_CLOSE_req Absent Subscriber MS memory capacity exceeded 'Set MNRF' 'Set MCEF' Error MAP_REPORT_SM_ DELIVERY_STATUS_rsp MAP_CLOSE_req OK

8 Attached Original Pages: For reference, the following sections include unmodified excerpts from version , November From 09.02, pages Short message service operations MAP-ShortMessageServiceOperations { gsm-network (1) modules (3) map-shortmessageserviceoperations (9) version2 (2)} DEFINITIONS ::= BEGIN EXPORTS SendRoutingInfoForSM, ForwardSM, ReportSM-DeliveryStatus, NoteSubscriberPresent, AlertServiceCentreWithoutResult, AlertServiceCentre, InformServiceCentre, ReadyForSM ; IMPORTS OPERATION FROM TCAPMessages { ccitt recommendation q 773 modules (2) messages (1) version2 (2)} SystemFailure, DataMissing, UnexpectedDataValue, FacilityNotSupported, UnknownSubscriber, UnidentifiedSubscriber, IllegalSubscriber, IllegalEquipment, TeleserviceNotProvisioned, AbsentSubscriber, CallBarred, SubscriberBusyForMT-SMS, SM-DeliveryFailure, MessageWaitingListFull FROM MAP-Errors { gsm-network (1) modules (3) map-errors (10) version2 (2)} RoutingInfoForSM-Arg, RoutingInfoForSM-Res, ForwardSM-Arg, ReportSM-DeliveryStatusArg, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg FROM MAP-SM-DataTypes { gsm-network (1) modules (3) map-sm-datatypes (16) version2 (2)} ISDN-AddressString, IMSI FROM MAP-CommonDataTypes { gsm-network (1) modules (3) map-commondatatypes (18) version2 (2)} ;

9 SendRoutingInfoForSM ::= OPERATION ARGUMENT routinginfoforsm-arg RESULT routinginfoforsm-res ERRORS { SystemFailure, DataMissing, UnexpectedDataValue, FacilityNotSupported, UnknownSubscriber, TeleserviceNotProvisioned, AbsentSubscriber, CallBarred} RoutingInfoForSM-Arg RoutingInfoForSM-Res --Timer m ForwardSM ::= OPERATION --Timer ml ARGUMENT forwardsm-arg ForwardSM-Arg RESULT ERRORS { SystemFailure, DataMissing, -- DataMissing must not be used in version 1 UnexpectedDataValue, FacilityNotSupported, UnidentifiedSubscriber, IllegalSubscriber, IllegalEquipment, -- IllegalEquipment must not be used in version 1 AbsentSubscriber, SubscriberBusyForMT-SMS, -- SubscriberBusyForMT-SMS must not be used in version 1 SM-DeliveryFailure} ReportSM-DeliveryStatus ::= OPERATION ARGUMENT reportsm-deliverystatusarg ReportSM-DeliveryStatusArg RESULT storedmsisdn ISDN-AddressString -- optional -- storedmsisdn must be absent in version 1 -- storedmsisdn must be present in version greater 1 ERRORS { DataMissing, -- DataMissing must not be used in version 1 UnexpectedDataValue, UnknownSubscriber, MessageWaitingListFull} --Timer s (Note: the rest of the section has been omitted.) From 09.02, page Short message data types MAP-SM-DataTypes { gsm-network (1) modules (3) map-sm-datatypes (16) version2 (2)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoutingInfoForSM-Arg, RoutingInfoForSM-Res, ForwardSM-Arg, ReportSM-DeliveryStatusArg, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg,

10 ; SM-DeliveryOutcome, AlertReason IMPORTS AddressString, ISDN-AddressString, SignalInfo, IMSI, LocationInfo, LMSI FROM MAP-CommonDataTypes { gsm-network (1) modules (3) map-commondatatypes (18) version2 (2)} TeleserviceCode FROM MAP-TS-Code { gsm-network (1) modules (3) map-ts-code (19) version2 (2)} ; RoutingInfoForSM-Arg ::= SEQUENCE { msisdn [0] ISDN-AddressString, sm-rp-pri [1] BOOLEAN, servicecentreaddress [2] AddressString, teleservice [5] TeleserviceCode OPTIONAL, -- teleservice must be absent in version greater 1...} RoutingInfoForSM-Res::= SEQUENCE { imsi IMSI, locationinfowithlmsi [0] LocationInfoWithLMSI, mwd-set [2] BOOLEAN OPTIONAL, -- mwd-set must be absent in version greater 1...} LocationInfoWithLMSI ::= SEQUENCE { locationinfo LocationInfo, lmsi LMSI OPTIONAL,...} ForwardSM-Arg ::= SEQUENCE { sm-rp-da SM-RP-DA, sm-rp-oa SM-RP-OA, sm-rp-ui SignalInfo, moremessagestosend NULL OPTIONAL, -- moremessagestosend must be absent in version 1...} SM-RP-DA ::= CHOICE { imsi [0] IMSI, lmsi [1] LMSI, roamingnumber [3] ISDN-AddressString, -- roaming number must not be used in version greater 1 servicecentreaddressda [4] AddressString, nosm-rp-da [5] NULL} -- nosm-rp-da must not be used in version 1 SM-RP-OA ::= CHOICE { msisdn [2] ISDN-AddressString, servicecentreaddressoa [4] AddressString, nosm-rp-oa [5] NULL} -- nosm-rp-oa must not be used in version 1 ReportSM-DeliveryStatusArg ::= SEQUENCE { msisdn ISDN-AddressString, servicecentreaddress AddressString, sm-deliveryoutcome SM-DeliveryOutcome OPTIONAL, -- sm-deliveryoutcome must be absent in version 1 -- sm-deliveryoutcome must be present in version greater 1...} (Note: the rest of the section has been omitted.) From 09.02, page 628.

11 Procedures in the gateway MSC The GMSC invokes the short message delivery status report procedure if an absent subscriber indication or unidentified subscriber indication or SM delivery failure error indicating MS memory capacity exceeded is received from the servicing MSC during a mobile terminated short message transfer, and the HLR has not indicated that the SC address is included in the MWD. The unidentified subscriber indication is however processed as the absent subscriber indication. The service is invoked also when the HLR has indicated that either of the flags MCEF or MNRF is set and the SM delivery was successful. The reason for unsuccessful or successful delivery of the short message is included in the SM Delivery Outcome in the MAP_REPORT_SM_DELIVERY_STATUS request. The GMSC sends the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR. As a response the GMSC will receive the MAP_REPORT_SM_DELIVERY_STATUS confirmation reporting: - successful outcome of the procedure. The acknowledge primitive may contain the MSISDN-Alert number which is stored in the MWD List in the HLR; - unsuccessful outcome of the procedure. The system failure indication is forwarded to the SC , pages The macro Report_SM_Delivery_Stat_HLR This macro is used when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication from the GMSC. The HLR responses to the indication as follows: - if invalid data content is detected, an unexpected data value error or a data missing error is returned to the GMSC; - if the MSISDN number provided is not recognized by the HLR, an unknown subscriber error is returned to the GMSC; - if the MAP_REPORT_SM_DELIVERY_STATUS indication reports a successful SM delivery, the Service Centres in the Message Waiting list are alerted as described in the subclause 21.10; - if the SM Delivery Outcome reports unsuccessful delivery and the inclusion of the SC address in the MWD is not possible, a message waiting list full error is returned to the GMSC; - if the SM Delivery Outcome reports unsuccessful delivery and the message waiting list is not full, the given Service Centre address is inserted and an acknowledgement is sent to the GMSC. If the MSISDN-Alert stored in the subscriber data is not the same as that received in the MAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a response primitive to the GMSC; - if the SM Delivery Outcome is MS memory capacity exceeded the HLR sets the memory capacity exceeded flag in the subscriber data and resets the MRNF; - if the SM Delivery Outcome is absent subscriber the HLR sets the mobile station not reachable flag in the subscriber data. The short message delivery status report macro in the HLR is shown in figure 20.6/1.

12 Figure 20.6/1 Check_ Indication OK Error 'Subscriber known' No Yes Successful Transfer Delivery Outcome 'SET UE = UNKNOWN SUBSCRIBER' 'Clear MCEF and MNRF' Unsuccessful transfer 'Update Message Waiting Data' MAP_REPORT_SM_ DELIVERY_STATUS_rsp MAP_CLOSE_req Yes 'Storing successful' No Alert_ Service_ Centre_HLR 'Set MSISDN- Alert' 'SET UE = MESSAGE WAITING LIST FULL' Delivery Outcome MAP-REPORT_SM DELIVERY_STATUS_rsp MAP_CLOSE_req Absent Subscriber MS memory capacity exceeded 'Set MNRF' 'Set MCEF' Error MAP_REPORT_SM_ DELIVERY_STATUS_rsp MAP_CLOSE_req OK

13 ETSI/STC/SMG3 WPC Tdoc SMG3 97C 264 Bath, UK April 28th-May 2nd, 1997 CHANGE REQUEST No. A082r2 Technical Specification GSM version Submitted to SMG for approval without presentation ("non-strategic") [ ] with presentation ("strategic") [X] Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Phase 1: [ ] Phase 2: [ ] Phase 2+: [X] Work item: SMS enhancements Other phase(s) affected [ ] If yes, linked CR(s): Proposed change affects: SIM [ ] ME [ ] Network [X] Source: SMG3 WPC Date: Subject: Modifications of due to SMS inconsistencies with TS GSM Category: F - Correction [X] A - Corresponds to a Phase 2 correction [ ] B - Addition of Feature [ ] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: This CR resolves inconsistencies and errors in the TS GSM on the Short Message Services as defined in the TS GSM Sections affected, and additional explanation of details of change (if needed): Modified sections: , , , , , , , 14.5, , , , Attached revised pages: If other core Specifications are affected, necessary (and attached) Joint CRs: Affects (possibly): MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ] Attached CRs?: Cross Phase Compatibility: Change affects operation of: Phase 1 MS in Phase 2(+) NW [ ] Phase 2(+) MS in Phase 1 NW [ ] CR to attached: Change affects operation of: Phase 1 SIM in Phase 2(+) ME[ ] CR to attached: Other comments: Phase 2(+) SIM in Phase 1 ME [ ] CR to attached:

14 Draft prets (GSM Version 5.5.0): March 1997 "Sequence guaranteed" shall be used when a segmented result is to be transferred (e.g. subscriber data in response to SendParameters). It may also be appropriate to use Sequence guaranteed when a series of InsertSubscriberData, ProcessAccessSignalling or ForwardAccessSignalling operations is used. TC P-Abort cause unrecognized message type unrecognized transaction Id badlyformattedtransactionportion incorrecttransactionportion resourcelimitation abnormaldialogue nocommondialogueportion MAP provider-reason provider malfunction supporting dialogue released provider malfunction provider malfunction (note) resource limitation provider malfunction version incompatibility NOTE: Or version incompatibility in the dialogue initiated phase. Table 13.1/1: Mapping of P-Abort cause in TC-P-ABORT indication on to provider-reason in MAP-P- ABORT indication 13.2 Service specific procedures Specific services are mapped to TC component handling services Directly mapped parameters The Invoke Id parameter of the MAP request and indication primitive is directly mapped on to the Invoke Id parameter of the component handling primitives Use of other parameters of component handling primitives Dialogue Id The value of this parameter is associated with the MAP PM invocation in an implementation dependent manner Class The value of this parameter is set by the MAP PM according to the type of the operation to be invoked Linked Id When a service response is mapped to a class 4 operation, the value of this parameter is set by the MAP PM and corresponds to the value assigned by the user to the initial service request (i.e. the value of the invoke ID parameter of the request primitive). Otherwise if such a parameter is included in MAP request/indication primitives it is directly mapped to the linked ID parameter of the associated TC-INVOKE request/indication primitives Operation When mapping a request primitive on to a Remote Operations PDU (invoke), the MAP PM shall set the operation code according to the mapping described in table 13.2/1. When mapping a response primitive on to a Remote Operations service, the MAP PM shall set the operation code of the TC-RESULT-L/NL primitive (if required) to the same value as the one received at invocation time.

15 Draft prets (GSM Version 5.5.0): March 1997 MAP-SERVICE MAP-ACTIVATE-SS MAP-ACTIVATE-TRACE-MODE MAP-ALERT-SERVICE-CENTRE MAP-ANY-TIME-INTERROGATION MAP-CANCEL-LOCATION MAP-CHECK-IMEI MAP-DEACTIVATE-SS MAP-DEACTIVATE-TRACE-MODE MAP-DELETE-SUBSCRIBER-DATA MAP-ERASE-SS MAP-FORWARD-ACCESS-SIGNALLING MAP-FORWARD-CHECK-SS-INDICATION MAP-MT-FORWARD-SHORT-MESSAGE MAP-MO-FORWARD-SHORT-MESSAGE MAP-GET-PASSWORD MAP-INFORM-SERVICE-CENTRE MAP-INSERT-SUBSCRIBER-DATA MAP-INTERROGATE-SS MAP-PREPARE-HANDOVER MAP-PREPARE-SUBSEQUENT-HANDOVER MAP-PROCESS-ACCESS-SIGNALLING MAP-PROCESS-UNSTRUCTURED-SS-REQUEST MAP-PROVIDE-ROAMING-NUMBER MAP-PROVIDE-SUBSCRIBER-INFO MAP-PURGE-MS MAP-READY-FOR-SM MAP-REGISTER-PASSWORD MAP-REGISTER-SS MAP-REPORT-SM-DELIVERY-STATUS MAP-RESET MAP-RESTORE-DATA MAP-SEND-END-SIGNAL MAP-SEND-AUTHENTICATION-INFO MAP-SEND-IMSI MAP-SEND-IDENTIFICATION MAP-SEND-ROUTING-INFO-FOR-SM MAP-SEND-ROUTING-INFORMATION MAP-UNSTRUCTURED-SS-NOTIFY MAP-UNSTRUCTURED-SS-REQUEST MAP-UPDATE-LOCATION operation activatess activatetracemode alertservicecentre anytimeinterrogaton cancellocation checkimei deactivatess deactivatetracemode deletesubscriberdata erasess forwardaccesssignalling forwardcheckssindication mt-forwardsm mo-forwardsm getpassword informservicecentre insertsubscriberdata interrogatess preparehandover preparesubsequenthandover processaccesssignalling processunstructuredss-request provideroamingnumber providesubscriberinfo purgems readyforsm registerpassword registerss reportsmdeliverystatus reset restoredata sendendsignal sendauthenticationinfo sendimsi sendidentification sendroutinginfoforsm sendroutinginfo unstructuredss-notify unstructuredss-request updatelocation Error Table 13.2/1: Mapping of MAP specific services on to MAP operations The error parameter in a TC-U-ERROR indication primitive is mapped to the user error parameter in the MAP confirm primitive of the service associated with the operation to which the error is attached. The user error parameter in MAP response primitives is mapped to the error parameter of the TC-U-ERROR request primitive, except for "initiating-release" and "resource-limitation" which are mapped to the problem code parameter of the TC-U-REJECT request primitive Parameters The parameters of MAP specific request and indication primitives are mapped to the argument parameter of TC- INVOKE primitives. The module containing the definition of the operation packages for MAP is: 1. MAP-OperationPackages. The module containing the definition of the application contexts for MAP is:

16 Draft prets (GSM Version 5.5.0): March MAP-ApplicationContexts. The module containing the data types for the Abstract Syntax to be used for TCAPMessages.DialoguePortion for MAP is: 3. MAP-DialogueInformation. The module containing the operation codes and error codes for MAP is: 4. MAP-Protocol. The modules containing all operation type definitions for MAP are: 5. MAP-MobileServiceOperations; 6. MAP-OperationAndMaintenanceOperations; 7. MAP-CallHandlingOperations; 8. MAP-SupplementaryServiceOperations; 9. MAP-ShortMessageServiceOperations. The module containing all error type definitions for MAP is: 10. MAP-Errors. Modules containing all data type definitions for MAP are: 11. MAP-MS-DataTypes; 12. MAP-OM-DataTypes; 13. MAP-CH-DataTypes; 14. MAP-SS-DataTypes; 15. MAP-SS-Code; 16. MAP-SM-DataTypes; 17. MAP-ER-DataTypes; 18. MAP-CommonDataTypes; 19. MAP-TS-Code; 20. MAP-BS-Code; 21. MAP-ExtensionDataTypes. References are made also to modules defined outside of this ETS. They are defined in the technical specification Mobile Services Domain and technical specification Transaction Capability respectively: MobileDomainDefinitions; TCAPMessages; DialoguePDUs Application Contexts The following informative table lists the latest versions of the Application Contexts used in this specification, with the operations used by them and, where applicable, whether or not the operation description is exactly the same as for previous versions. Information in sections 14.6 & 14.7 relates only to the ACs in this table. AC Name AC Operations Used Comments * Version locationcancellationcontext v2 cancellocation equipmentmngtcontext v2 checkimei imsiretrievalcontext v2 sendimsi inforetrievalcontext v2 sendauthenticationinfo intervlrinforetrievalcontext v2 sendidentification handovercontrolcontext v2 preparehandover forwardaccesssignalling sendendsignal processaccesssignalling preparesubsequenthandover mwdmngtcontext v2 readyforsm mspurgingcontext v2 purgems shortmsgalertcontext v2 alertservicecentre shortmsgmo-relaycontext v2 forwardsm resetcontext v2 reset networkunstructuredsscontext v2 processunstructuredss-request unstructuredss-request

17 Draft prets (GSM Version 5.5.0): March 1997 unstructuredss-notify tracingcontext v3 activatetracemode deactivatetracemode networkfunctionalsscontext v2 registerss erasess activatess deactivatess registerpassword interrogatess getpassword shortmsgmo-relaycontext v3 mo-forwardsm shortmsgmt-relaycontext v3 mt-forwardsm shortmsggatewaycontext v3 sendroutinginfoforsm reportsm-deliverystatus InformServiceCentre networklocupcontext v3 updatelocation forwardcheckss-indication restoredata insertsubscriberdata activatetracemode subscriberdatamngtcontext v3 insertsubscriberdata deletesubscriberdata roamingnumberenquirycontext v3 provideroamingnumber locationinforetrievalcontext v3 sendroutinginfo the syntax is the same in v1 & v2 Note (*): The syntax of the operations is not the same in previous versions unless explicitly stated

18 Draft prets (GSM Version 5.5.0): March MO Short message relay services This operation package includes the operations required for short message relay service procedures between IWMSC and VMSC or between GMSC and MSC. MOShortMsgRelayPackage-v3 ::= OPERATION-PACKAGE -- Supplier is IWMSC if Consumer is MSC -- Supplier is MSC if Consumer is GMSC CONSUMER INVOKES { MO-forwardSM} 9 10 The v2-equivalent package is defined as follows: 11 ShortMsgRelayPackage-v2 ::= OPERATION-PACKAGE Supplier is IWMSC if Consumer is MSC Supplier is MSC if Consumer is GMSC 14 CONSUMER INVOKES { 15 forwardsm} The v1-equivalent package can be determined according to the rules described in subclause Short message gateway services 19 This operation package includes the operations required for short message service gateway procedures between MSC 20 and HLR. 21 ShortMsgGatewayPackage-v3 ::= OPERATION-PACKAGE Supplier is HLR if Consumer is GMSC 23 CONSUMER INVOKES { 24 sendroutinginfoforsm, 25 reportsm-deliverystatus} 26 SUPPLIER INVOKES { 27 informservicecentre} The v2-equivalent package can be determined according to the rules described in subclause The v1-equivalent package is defined as follows: 31 ShortMsgGatewayPackage-v1 ::= OPERATION-PACKAGE Supplier is HLR if Consumer is GMSC 33 CONSUMER INVOKES { 34 sendroutinginfoforsm 35 reportsmdeliverystatus} MT Short message relay services This operation package includes the operations required for short message relay service procedures between GMSC and MSC. MTShortMsgRelGatewayPackage-v3 ::= OPERATION-PACKAGE -- Supplier is MSC if Consumer is GMSC CONSUMER INVOKES { MT-forwardSM} The v2-equivalent package is: ShortMsgRelayPackage-v [spare] Message waiting data management 48 This operation package includes the operations required for short message waiting data procedures between HLR 49 and VLR. 50 MwdMngtPackage-v2 ::= OPERATION-PACKAGE Supplier is HLR if Consumer is VLR 52 CONSUMER INVOKES { 53 readyforsm} The v1-equivalent package is defined as follows: 56 MwdMngtPackage-v1 ::= OPERATION-PACKAGE Supplier is HLR if Consumer is VLR 58 CONSUMER INVOKES { 59 notesubscriberpresent}

19 Short Message Gateway Draft prets (GSM Version 5.5.0): March This application context is used for short message gateway procedures. 62 shortmsggatewaycontext-v3 APPLICATION-CONTEXT Responder is HLR if Initiator is GMSC 64 INITIATOR CONSUMER OF { 65 ShortMsgGatewayPackage-v3} 66 ::= {map-ac shortmsggateway(20) version3(3)} The following application-context-name is assigned to the v2-equivalent application-context: 69 {map-ac shortmsggateway(20) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: 72 {map-ac shortmsggateway(20) version1(1)} Mobile originating Short Message Relay This application context is used for mobile originating short message relay procedures. 76 shortmsgmo-relaycontext-v32 APPLICATION-CONTEXT Responder is IWMSC if Initiator is MSC 78 INITIATOR CONSUMER OF { 79 MOShortMsgRelayPackage-v32} 80 ::= {map-ac shortmsgmo-relay(21) version32(32)} The following application-context-name is assigned to the v2-equivalent application-context: 83 {map-ac shortmsgmo-relay(21) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: 86 {map-ac shortmsgmo-relay(21) version1(1)} [spare] Short message alert This application context is used for short message alerting procedures. 91 shortmsgalertcontext-v2 APPLICATION-CONTEXT Responder is IWMSC if Initiator is HLR 93 INITIATOR CONSUMER OF { 94 AlertingPackage-v2} 95 ::= {map-ac shortmsgalert(23) version2(2)} The following application-context-name is symbolically assigned to the v1-equivalent application-context: 98 {map-ac shortmsgalert(23) version1(1)} Short message waiting data management This application context is used for short message waiting data management procedures. 102 mwdmngtcontext-v2 APPLICATION-CONTEXT Responder is HLR if Initiator is VLR 104 INITIATOR CONSUMER OF { 105 MwdMngtPackage-v2} 106 ::= {map-ac mwdmngt(24) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: 109 {map-ac mwdmngt(24) version1(1)} Mobile terminating Short Message Relay This application context is used for mobile terminating short message relay procedures. 113 shortmsgmt-relaycontext-v3 APPLICATION-CONTEXT Responder is MSC if Initiator is GMSC 115 INITIATOR CONSUMER OF { 116 MTShortMsgRelayPackage-v3} 117 ::= {map-ac shortmsgmt-relay(25) version3(3)} The following application-context-name is assigned to the v2-equivalent application-context: 120 {map-ac shortmsgmt-relay(25) version2(2)}

20 Draft prets (GSM Version 5.5.0): March The following application-context-name is assigned to the v1-equivalent application-context: 123 {map-ac shortmsgmo-relay(21) version1(1)} The v1-equivalent application-context is: shortmsgrelaycontext_v1.

21 ASN.1 Module for application-context-names Draft prets (GSM Version 5.5.0): March 1997 The following ASN.1 module summarizes the application-context-name assigned to MAP application-contexts. MAP-ApplicationContexts { gsm-network (1) modules (3) map-applicationcontexts (2) version3 (3)} DEFINITIONS ::= BEGIN -- EXPORTS everything IMPORTS gsm-networkid, ac-id FROM MobileDomainDefinitions { ccitt (0) identified-organization (4) etsi (0) mobiledomain (0) mobiledomaindefinitions (0) version1 (1)} ; -- application-context-names map-ac OBJECT IDENTIFIER ::= {gsm-networkid ac-id} networklocupcontext-v3 OBJECT IDENTIFIER ::= {map-ac networklocup(1) version3(3)} locationcancellationcontext-v2 OBJECT IDENTIFIER ::= {map-ac locationcancel(2) version2(2)} roamingnumberenquirycontext-v3 OBJECT IDENTIFIER ::= {map-ac roamingnbenquiry(3) version3(3)} locationinforetrievalcontext-v3 OBJECT IDENTIFIER ::= {map-ac locinforetrieval(5) version3(3)} resetcontext-v2 OBJECT IDENTIFIER ::= {map-ac reset(10) version2(2)} handovercontrolcontext-v2 OBJECT IDENTIFIER ::= {map-ac handovercontrol(11) version2(2)} equipmentmngtcontext-v2 OBJECT IDENTIFIER ::= {map-ac equipmentmngt(13) version2(2)} inforetrievalcontext-v2 OBJECT IDENTIFIER ::= {map-ac inforetrieval(14) version2(2)} intervlrinforetrievalcontext-v2 OBJECT IDENTIFIER ::= {map-ac intervlrinforetrieval(15) version2(2)} subscriberdatamngtcontext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberdatamngt(16) version3(3)} tracingcontext-v3 OBJECT IDENTIFIER ::= {map-ac tracing(17) version3(3)} networkfunctionalsscontext-v2 OBJECT IDENTIFIER ::= {map-ac networkfunctionalss(18) version2(2)} networkunstructuredsscontext-v2 OBJECT IDENTIFIER ::= {map-ac networkunstructuredss(19) version2(2)} shortmsggatewaycontext-v3 OBJECT IDENTIFIER ::= {map-ac shortmsggateway(20) version3(3)} shortmsgmo-relaycontext-v32 OBJECT IDENTIFIER ::= {map-ac shortmsgmo-relay(21) version32(32)} shortmsgalertcontext-v2 OBJECT IDENTIFIER ::= {map-ac shortmsgalert(23) version2(2)}

22 Draft prets (GSM Version 5.5.0): March 1997 mwdmngtcontext-v2 OBJECT IDENTIFIER ::= {map-ac mwdmngt(24) version2(2)} shortmsgmt-relaycontext-v3 OBJECT IDENTIFIER ::= {map-ac shortmsgmt-relay(25) version3(3)} imsiretrievalcontext-v2 OBJECT IDENTIFIER ::= {map-ac imsiretrieval(26) version2(2)} mspurgingcontext-v2 OBJECT IDENTIFIER ::= {map-ac mspurging(27) version2(2)} subscriberinfoenquirycontext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberinfoenquiry(28) version3(3)} anytimeinfoenquirycontext-v3 OBJECT IDENTIFIER ::= {map-ac anytimeinfoenquiry(29) version3(3)} callcontroltransfercontext-v3 OBJECT IDENTIFIER ::= {map-ac callcontroltransfer(6) version3(3)}

23 Draft prets (GSM Version 5.5.0): March MAP operation and error codes MAP-Protocol { gsm-network (1) modules (3) map-protocol (4) version3 (3)} DEFINITIONS ::= BEGIN IMPORTS UpdateLocation, CancelLocation, PurgeMS, SendIdentification, PrepareHandover, SendEndSignal, ProcessAccessSignalling, ForwardAccessSignalling, PrepareSubsequentHandover, SendAuthenticationInfo, CheckIMEI, InsertSubscriberData, DeleteSubscriberData, Reset, ForwardCheckSS-Indication, RestoreData, ProvideSubscriberInfo, AnyTimeInterrogation FROM MAP-MobileServiceOperations { gsm-network (1) modules (3) map-mobileserviceoperations (5) version3 (3)} ActivateTraceMode, DeactivateTraceMode, SendIMSI FROM MAP-OperationAndMaintenanceOperations { gsm-network (1) modules (3) map-operationandmaintenanceoperations (6) version3 (3)} SendRoutingInfo, ProvideRoamingNumber, ResumeCallHandling FROM MAP-CallHandlingOperations { gsm-network (1) modules (3) map-callhandlingoperations (7) version3 (3)} RegisterSS, EraseSS, ActivateSS, DeactivateSS, InterrogateSS, ProcessUnstructuredSS-Request, UnstructuredSS-Request, UnstructuredSS-Notify, RegisterPassword, GetPassword FROM MAP-SupplementaryServiceOperations { gsm-network (1) modules (3) map-supplementaryserviceoperations (8) version3 (3)} SendRoutingInfoForSM, MO-ForwardSM, MT-ForwardSM, ReportSM-DeliveryStatus, AlertServiceCentre, InformServiceCentre, Short message service operations MAP-ShortMessageServiceOperations {

24 Draft prets (GSM Version 5.5.0): March 1997 gsm-network (1) modules (3) map-shortmessageserviceoperations (9) version3 (3)} DEFINITIONS ::= BEGIN EXPORTS SendRoutingInfoForSM, MO-ForwardSM, MT-ForwardSM, ReportSM-DeliveryStatus, AlertServiceCentre, InformServiceCentre, ReadyForSM ; IMPORTS OPERATION FROM TCAPMessages { ccitt recommendation q 773 modules (2) messages (1) version2 (2)} SystemFailure, DataMissing, UnexpectedDataValue, FacilityNotSupported, UnknownSubscriber, UnidentifiedSubscriber, IllegalSubscriber, IllegalEquipment, TeleserviceNotProvisioned, AbsentSubscriber, CallBarred, SubscriberBusyForMT-SMS, SM-DeliveryFailure, MessageWaitingListFull, AbsentSubscriberSM FROM MAP-Errors { gsm-network (1) modules (3) map-errors (10) version3 (3)} RoutingInfoForSM-Arg, RoutingInfoForSM-Res, MO-ForwardSM-Arg, MO-ForwardSM-Res, MT-ForwardSM-Arg, MT-ForwardSM-Res, ReportSM-DeliveryStatusArg, ReportSM-DeliveryStatusRes, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg FROM MAP-SM-DataTypes { gsm-network (1) modules (3) map-sm-datatypes (16) version3 (3)} ; SendRoutingInfoForSM ::= OPERATION ARGUMENT routinginfoforsm-arg RESULT routinginfoforsm-res ERRORS { SystemFailure, DataMissing, UnexpectedDataValue, FacilityNotSupported, UnknownSubscriber, TeleserviceNotProvisioned, CallBarred, AbsentSubscriberSM} RoutingInfoForSM-Arg RoutingInfoForSM-Res --Timer m

25 Draft prets (GSM Version 5.5.0): March 1997 MO-ForwardSM ::= OPERATION ARGUMENT mo-forwardsm-arg RESULT mo-forwardsm-res -- optional ERRORS { SystemFailure, DataMissing, UnexpectedDataValue, FacilityNotSupported, UnidentifiedSubscriber, IllegalSubscriber, IllegalEquipment, AbsentSubscriber, SubscriberBusyForMT-SMS, SM-DeliveryFailure} MT-ForwardSM ::= OPERATION ARGUMENT mt-forwardsm-arg RESULT mt-forwardsm-res -- optional ERRORS { SystemFailure, DataMissing, UnexpectedDataValue, FacilityNotSupported, UnidentifiedSubscriber, IllegalSubscriber, IllegalEquipment, SubscriberBusyForMT-SMS, SM-DeliveryFailure, AbsentSubscriberSM} MO-ForwardSM-Arg MO-ForwardSM-Res MT-ForwardSM-Arg MT-ForwardSM-Res --Timer ml --Timer ml ReportSM-DeliveryStatus ::= OPERATION ARGUMENT reportsm-deliverystatusarg ReportSM-DeliveryStatusArg RESULT reportsm-deliverystatusres ReportSM-DeliveryStatusRes ERRORS { DataMissing, UnexpectedDataValue, UnknownSubscriber, MessageWaitingListFull} --Timer s

26 Draft prets (GSM Version 5.5.0): March Short message data types MAP-SM-DataTypes { gsm-network (1) modules (3) map-sm-datatypes (16) version3 (3)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoutingInfoForSM-Arg, RoutingInfoForSM-Res, MO-ForwardSM-Arg, MO-ForwardSM-Res, MT-ForwardSM-Arg, MT-ForwardSM-Res, ReportSM-DeliveryStatusArg, ReportSM-DeliveryStatusRes, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg, SM-DeliveryOutcome, AlertReason ; IMPORTS AddressString, ISDN-AddressString, SignalInfo, IMSI, LMSI FROM MAP-CommonDataTypes { gsm-network (1) modules (3) map-commondatatypes (18) version3 (3)} AbsentSubscriberDiagnosticSM FROM MAP-ER-DataTypes { gsm-network (1) modules (3) map-er-datatypes (17) version3 (3)} ExtensionContainer FROM MAP-ExtensionDataTypes { gsm-network (1) modules (3) map-extensiondatatypes (21) version3 (3)} ; RoutingInfoForSM-Arg ::= SEQUENCE { msisdn [0] ISDN-AddressString, sm-rp-pri [1] BOOLEAN, servicecentreaddress [2] AddressString, extensioncontainer [6] ExtensionContainer OPTIONAL,...} RoutingInfoForSM-Res::= SEQUENCE { imsi IMSI, locationinfowithlmsi [0] LocationInfoWithLMSI, extensioncontainer [4] ExtensionContainer OPTIONAL,...} LocationInfoWithLMSI ::= SEQUENCE { msc-number [1] ISDN-AddressString, lmsi LMSI OPTIONAL, extensioncontainer ExtensionContainer OPTIONAL,...}

27 Draft prets (GSM Version 5.5.0): March 1997 MO-ForwardSM-Arg ::= SEQUENCE { sm-rp-da SM-RP-DA, sm-rp-oa SM-RP-OA, sm-rp-ui SignalInfo, moremessagestosend NULL OPTIONAL, extensioncontainer ExtensionContainer OPTIONAL,...} MO-ForwardSM-Res ::= SEQUENCE { sm-rp-ui SignalInfo OPTIONAL, extensioncontainer ExtensionContainer OPTIONAL,...} MT-ForwardSM-Arg ::= SEQUENCE { sm-rp-da SM-RP-DA, sm-rp-oa SM-RP-OA, sm-rp-ui SignalInfo, moremessagestosend NULL OPTIONAL, extensioncontainer ExtensionContainer OPTIONAL,...} MT-ForwardSM-Res ::= SEQUENCE { sm-rp-ui SignalInfo OPTIONAL, extensioncontainer ExtensionContainer OPTIONAL,...} SM-RP-DA ::= CHOICE { imsi lmsi servicecentreaddressda nosm-rp-da SM-RP-OA ::= CHOICE { msisdn servicecentreaddressoa nosm-rp-oa [0] IMSI, [1] LMSI, [4] AddressString, [5] NULL} [2] ISDN-AddressString, [4] AddressString, [5] NULL} ReportSM-DeliveryStatusArg ::= SEQUENCE { msisdn ISDN-AddressString, servicecentreaddress AddressString, sm-deliveryoutcome SM-DeliveryOutcome, absentsubscriberdiagnosticsm [0] AbsentSubscriberDiagnosticSM OPTIONAL, extensioncontainer [1] ExtensionContainer OPTIONAL,...} SM-DeliveryOutcome ::= ENUMERATED { memorycapacityexceeded (0), absentsubscriber (1), successfultransfer (2)} ReportSM-DeliveryStatusRes ::= SEQUENCE { storedmsisdn ISDN-AddressString, extensioncontainer ExtensionContainer OPTIONAL,...} AlertServiceCentreArg ::= SEQUENCE { msisdn servicecentreaddress...} ISDN-AddressString, AddressString, InformServiceCentreArg ::= SEQUENCE { storedmsisdn ISDN-AddressString OPTIONAL, mw-status MW-Status OPTIONAL, extensioncontainer ExtensionContainer OPTIONAL,...}

28 Draft prets (GSM Version 5.5.0): March Procedures in the gateway MSC Process MT_SM_GMSC 203_73(5) Figure 20.3/7: The mobile terminated short message service process in the GMSC WAIT_FOR_ MT_SMS_ CONFIRM Check_ Confirmation Fig 21.2/2 MAP_FORWARD_SHORT_ MESSAGE_Cnf OK User Error 2 Page 4 Provider Error, Data Error 3 Page 2 Unidentified Subscriber? Yes No MT_SM_ Transfer_ MSC Fig 20.3/3 SET UE= ABSENT SUBSCRIBER Absent subscriber? No Abort NULL OK Error Yes Yes MS memory capacity exceeded? No Yes More messages to send? No MWD already set? No Yes No MCEF or MNRF set in HLR? Report_SM Delivery_ Stat_GMSC Fig 20.5/2 Yes OK Error Report_SM Delivery_ Stat_GMSC Set RP_ERROR OK Error SC_RP_ ACK_Req SC_RP_ ACK_Req SC_RP_ ERROR_Req WAIT_FOR_ MORE_ MESSAGES NULL

29 Draft prets (GSM Version 5.5.0): March 1997 Process MT_SM_GMSC 203_75(5) Figure 20.3/7: The mobile terminated short message service process in the GMSC WAIT_FOR_MT_SMS_CONFIRM, WAIT_FOR_A_SM_CONFIRM SC_ ABORT_Ind MAP_U_ABORT_Ind, MAP_P_ABORT_Ind, A_ABORT_Ind MAP_ NOTICE_ Ind MAP_ CLOSE_ Req Yes GMSC= VMSC? No SET RP_ERROR =SYSTEM FAILURE A_ABORT_ Req MAP_U_ ABORT_Ind SC_RP_ ERROR_Req NULL

30 Draft prets (GSM Version 5.5.0): March 1997 Process MT_SM_GMSC 203_76(6) Figure 20.3/7: The mobile terminated short message service process in the GMSC WAUT_FOR_MORE_MESSAGES SC_ABORT_Ind MAP_U_ABORT_Ind MAP_P_ABORT_Ind A_ABORT_Ind MAP_NOTICE_ind yes GMSC = VMSC? NO MAP_CLOSE_Req A_ABORT_Req MAP_U_ABORT_Ind SC_ABORT_Req NULL

31 Procedures in the gateway MSC Draft prets (GSM Version 5.5.0): March 1997 The GMSC invokes the short message delivery status report procedure if an absent subscriber_sm indication or unidentified subscriber indication or SM delivery failure error indicating MS memory capacity exceeded is received from the servicing MSC during a mobile terminated short message transfer, and the HLR has not indicated that the SC address is included in the MWD. The unidentified subscriber indication is however processed as the absent subscriber_sm indication. The service is invoked also when the HLR has indicated that either of the flags MCEF or MNRF is set and the SM delivery was successful or, in case of subsequent SM, the last SM delivery was successful. The reason for unsuccessful or successful delivery of the short message is included in the SM Delivery Outcome in the MAP_REPORT_SM_DELIVERY_STATUS request. In the case of an unsuccessful delivery due to the subscriber being absent the absent subscriber diagnostic indiciation (if available) is also included in the MAP_REPORT_SM_DELIVERY_STATUS request. The GMSC sends the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR. As a response the GMSC will receive the MAP_REPORT_SM_DELIVERY_STATUS confirmation reporting: - successful outcome of the procedure. The acknowledge primitive may contain the MSISDN-Alert number which is stored in the MWD List in the HLR; - unsuccessful outcome of the procedure. The system failure indication is forwarded to the SC. A provider error is indicated as a system failure to the SC. The procedure towards the Service Centre may also be aborted. If so the operation towards the HLR is also aborted. The short message delivery status report procedure in the GMSC is shown in figure 20.5/3.

32 CHANGE REQUEST No. _A083r1_ Technical Specification GSM version Submitted to SMG for approval without presentation ("non-strategic") [ ] with presentation ("strategic") [ X ] Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Phase 1: [ ] Phase 2: [ ] Phase 2+: [x] Work item: Other phase(s) affected: [ ] If yes, linked CR(s): Proposed change affects: SIM [ ] ME [ ] Network [x] Source: SMG3 WPC Date: 29 April 1997 Subject: Clarify handling of result of ReportSMDeliveryStatus for MAP Phase 2+ Category: F - Correction [ ] A - Corresponds to a Phase 2 correction [ x ] B - Addition of Feature [ ] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: For the MAP_REPORT_SM_DELIVERY_STATUS operation, there are inconsistencies between the text in the detailed procedure handling section and 1) the service description, 2) the ASN.1 description of the operation and 3) the handling of the operation in the SDLs. Sections affected, and additional explanation of details of change (if needed): See other comments. Attached revised pages: Page(s): , 242, and If other core Specifications are affected, necessary (and attached) Joint CRs: Affects (possibly): MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ] Attached CRs?: Cross Phase Compatibility: Change affects operation of: Change affects operation of: Other comments: The text of Section , The macro Report_SM_Delivery_Stat_HLR, gives the detailed procedures in the HLR for the handling of the ReportSM-DeliveryStatus operation. The section contains a text description of the handling of the ReportSM-DeliveryStatus Result (i.e., the storedmsisdn parameter). One item states under which conditions the result will contain the storedmsisdn parameter, and reads as follows: - if the SM Delivery Outcome reports unsuccessful delivery and the message waiting list is not full, the given Service Centre address is inserted and an acknowledgement is sent to the GMSC. If the MSISDN-Alert stored in the subscriber data is not the same as that received in the MAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a response primitive to the GMSC; This section provides for 3 conditions under which the storedmsisdn parameter is populated:

33 1) Unsuccessful delivery of a short message 2) Message waiting list is not full 3) MSISDN-Alert in subscriber data not equal to that received in ReportSM-DeliveryStatus invoke. Only if all three conditions are met will the MSISDN-Alert value stored in the MWD data for the subscriber be sent in the storedmsisdn parameter of the ReportSM-DeliveryStatus result. The corresponding GMSC section, , Procedures in the gateway MSC specifies the procedures for sending, from the GMSC, the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR and receiving the result. A portion of the text reads as follows: The GMSC sends the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR. As a response the GMSC will receive the MAP_REPORT_SM_DELIVERY_STATUS confirmation reporting: - successful outcome of the procedure. The acknowledge primitive may contain the MSISDN-Alert number which is stored in the MWD List in the HLR; The GMSC, according to the text may receive the MSISDN-Alert, and thus is aligned with the text in section which states that this parameter is sent optionally under the conditions previously mentioned. There are three areas that need to be aligned with the text sections just cited , section , contains the MAP-REPORT-SM-DELIVERY-STATUS service description, and states that the MSIsdn-Alert parameter is mandatory in the response for successful completion of the operation. This clearly is not consistent with the procedures section in Chapter 20 and needs to be aligned with it. 2. Sections , Short message service operations, and , Short message data types, contain the ASN.1 definitions of the ReportSM-DeliveryStatus operation and its parameters. The Result of this operation is the reportsm-deliverystatusres, which in turn contains the storedmsisdn. The result is indicated to be mandatory, and the storedmsisdn parameter within the result is also indicated to be mandatory. Since the detailed procedures in sections and indicate that this parameter is sent conditionally, these sections need to be modified to align them with the procedures section. 3. Figure 20.6/1 contains the macro Report_SM_Delivery_Stat_HLR. This SDL performs the first two checks listed above, i.e., checks for unsuccessful delivery of short message and message waiting list not full, but does not make the third check i.e., checking if the MSISDN-Alert in subscriber data is the same as that received in the ReportSM-DeliveryStatus. The SDL, based on the first two checks always sets the storedmsisdn parameter of the result. As just noted, the text specifies a third condition which must be met before the storedmsisdn parameter is included in the result, and this check should be added to the SDL to align the SDL with the text. The modified sections are shown in the following pages.