Tdoc SMG 379/ 97 ETSI TC SMG # 22 Plenary Meeting Kristiansand, Norway 9th - 13th June 1997 Source: SMG3 Agenda Item: 6.3 ≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡ Change Requests to GSM 09.02 Clarification and Modification of SMS handling ≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡ Introduction: The following CRs to GSM 09.02 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 STC_DOC ‘strat egic’ 09.02 4.16.0 A076 1 2 F Clarify handling of result of ReportSMDeliveryStatus 97C251 Yes 09.02 5.5.0 A083 1 2+ A Clarify handling of result of ReportSMDeliveryStatus 97C252 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 09.02 A063 only in the other direction, creating misalignment to GSM 03.40). 09.02 5.5.0 A082 2 2+ F Modifications due to SMS inconsistencies with GSM 03.40 97C264 Yes Other Comments: Number of Pages: _____
The following CRs to GSM 09.02 phase 2 and phase 2+ remove some inconsistencies betweenthe textual description, ASN.1 and the SDL diagrams for theMAP_REPORT_SM_DELIVERY_STATUS operation. The changes are meant to be neutral toexisting implementations.
SPEC VERS CR REV
PHASE
CAT
SUBJECT STC_DOC ‘strategic’
09.02 4.16.0 A076 1 2 F Clarify handling of result ofReportSMDeliveryStatus
97C251 Yes
09.02 5.5.0 A083 1 2+ A Clarify handling of result ofReportSMDeliveryStatus
97C252 Yes
The following CR provides for the capability to convey SMS user data in RP-ACK also in thenetwork to user direction for MO SMS. (Due to a misunderstanding this was introduced by theearlier CR 09.02 A063 only in the other direction, creating misalignment to GSM 03.40).
09.02 5.5.0 A082 2 2+ F Modifications due to SMS inconsistencies withGSM 03.40
97C264 Yes
Other Comments:Number of Pages: _____
Blank Page
CHANGE REQUEST No. _A076r1_ Technical Specification GSM 09.02 version 4.15.0
Submitted to SMG for approval without presentation ("non-strategic") [ ]
with presentation ("strategic") [ X ]
Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ]
Subject: Clarify 09.02 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 thetext in the detailed procedure handling section and 1) the service description, 2) the ASN.1 descriptionof 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 631-632.
If other core Specifications are affected, necessary (and attached) Joint CRs:Affects (possibly): MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ]Attached CRs?:
The text of Section 20.6.1, “The macro Report_SM_Delivery_Stat_HLR”, gives the detailed proceduresin the HLR for the handling of the ReportSM-DeliveryStatus operation. The section contains a textdescription of the handling of the ReportSM-DeliveryStatus Result (i.e., the storedMSISDNparameter). One item states under which conditions the result will contain the storedMSISDNparameter, and reads as follows:
“- if the SM Delivery Outcome reports unsuccessful delivery and the message waiting list is notfull, 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 responseprimitive 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-DeliveryStatusinvoke.
Only if all three conditions are met will the MSISDN-Alert value stored in the MWD data for thesubscriber be sent in the storedMSISDN parameter of the ReportSM-DeliveryStatus result.
The corresponding GMSC section, 20.5.2, “Procedures in the gateway MSC” specifies the proceduresfor sending, from the GMSC, the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR andreceiving 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 responsethe GMSC will receive the MAP_REPORT_SM_DELIVERY_STATUS confirmation reporting:
- successful outcome of the procedure. The acknowledge primitive may contain the MSISDN-Alertnumber 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 insection 20.6.1 which states that this parameter is sent optionally under the conditions previouslymentioned.
There are three sections that need to be aligned with the text sections just cited.
1. 09.02, section 10.3.3, contains the MAP-REPORT-SM-DELIVERY-STATUS service description,and states that the MSIsdn-Alert parameter is mandatory in the response for successfulcompletion of the operation. This clearly is not consistent with the procedures section in Chapter20 and needs to be aligned.
2. Section 14.6.5, 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 typeISDN-AddressString. The notes for this operation state that the storedMSISDN parameter must beabsent for version 1 and must be present for versions greater than 1. These notes state that forversion 2, the storedMSISDN parameter must always be present in the ReportSM-DeliveryStatusresult (i.e., unconditionally). This section also needs to be modified to align it with the proceduressection.
3. Figure 20.6/1 contains the macro Report_SM_Delivery_Stat_HLR. This SDL performs the first twochecks listed above, i.e., checks for unsuccessful delivery of short message and message waitinglist not full, but does not make the third check – i.e., checking if the MSISDN-Alert in subscriberdata is the same as that received in the ReportSM-DeliveryStatus. The SDL, based on the first twochecks always sets the storedMSISDN parameter of the result. As just noted, the text specifies athird 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.
From 09.02, Section 10.3, page 159:
10.3 MAP-REPORT-SM-DELIVERY-STATUS service
10.3.1 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 ofsuccessful 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 serviceprimitives given in table 10.3/1.
10.3.2 Service primitives
The service primitives are shown in table 10.3/1.
Parameter name Request Indication Response ConfirmInvoke 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
Table 10.3/1: MAP-REPORT-SM-DELIVERY-STATUS
10.3.3 Parameter use
Invoke id:
See definition in subclause 5.6.1.
MSISDN:
See definition in subclause 5.6.2.
Service Centre Address:
See definition in subclause 5.6.2.
SM Delivery Outcome:
See definition in subclause 5.6.8. This parameter indicates the status of the mobile terminated SMdelivery.
MSIsdn-Alert:
See definition in subclause 5.6.2. The presence of tThis parameter is mandatoryshall be present incase of unsuccessful delivery, outcome of the service when the MSISDN received in the operation isdifferent from the stored MSIsdn-Alert; the stored MSIsdn-Alert is the value that is returned to thegateway MSC..
storedMSISDN ISDN-AddressString-- optional-- storedMSISDN must be absent in version 1
-- storedMSISDN must be present in version greater 1ERRORS {
DataMissing,-- DataMissing must not be used in version 1UnexpectedDataValue,UnknownSubscriber,MessageWaitingListFull}
From Section 20.6.1, pages 631-632:
20.6.1 The macro Report_SM_Delivery_Stat_HLR
This macro is used when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indicationfrom 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 isreturned to the GMSC;
- if the MSISDN number provided is not recognized by the HLR, an unknown subscriber error isreturned to the GMSC;
- if the MAP_REPORT_SM_DELIVERY_STATUS indication reports a successful SM delivery, theService 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 inthe 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. Ifthe MSISDN-Alert stored in the subscriber data is not the same as that received in theMAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a responseprimitive to the GMSC;
- if the SM Delivery Outcome is MS memory capacity exceeded the HLR sets the memorycapacity 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 reachableflag in the subscriber data.
The short message delivery status report macro in the HLR is shown in figure 20.6/1.
Figure 20.6/1
Check_Indication
MAP-REPORT_SMDELIVERY_STATUS_rspMAP_CLOSE_req
Error
'Subscriberknown'
DeliveryOutcome
'Clear MCEFand MNRF'
Alert_Service_
Centre_HLR
OK
MAP_REPORT_SM_DELIVERY_STATUS_rspMAP_CLOSE_req
'UpdateMessageWaitingData'
'Storingsuccessful'
'SET UE =MESSAGEWAITING
LIST FULL'
DeliveryOutcome
'SetMCEF'
MAP_REPORT_SM_DELIVERY_STATUS_rspMAP_CLOSE_req
'SetMNRF'
'SET UE =UNKNOWN
SUBSCRIBER'
ErrorOK
Yes
SuccessfulTransfer
Unsuccessfultransfer
No
Yes
MS memorycapacityexceeded
AbsentSubscriber
No
‘MSISDN =MSISDN Alert?’
Yes
No
'SetMSISDN-
Alert
Parameter’
Attached Original Pages:
For reference, the following sections include unmodified excerpts from 09.02 version 4.15.0,November 1996.
SystemFailure,DataMissing,-- DataMissing must not be used in version 1UnexpectedDataValue,FacilityNotSupported,UnidentifiedSubscriber,IllegalSubscriber,IllegalEquipment,-- IllegalEquipment must not be used in version 1AbsentSubscriber,SubscriberBusyForMT-SMS,-- SubscriberBusyForMT-SMS must not be used in version 1SM-DeliveryFailure}
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...}
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 1serviceCentreAddressDA [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.
20.5.2 Procedures in the gateway MSC
The GMSC invokes the short message delivery status report procedure if an absent subscriberindication or unidentified subscriber indication or SM delivery failure error indicating MS memorycapacity exceeded is received from the servicing MSC during a mobile terminated short messagetransfer, and the HLR has not indicated that the SC address is included in the MWD. The unidentifiedsubscriber 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 setand the SM delivery was successful.
The reason for unsuccessful or successful delivery of the short message is included in the SM DeliveryOutcome in the MAP_REPORT_SM_DELIVERY_STATUS request.
The GMSC sends the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR. As a responsethe GMSC will receive the MAP_REPORT_SM_DELIVERY_STATUS confirmation reporting:
- successful outcome of the procedure. The acknowledge primitive may contain the MSISDN-Alertnumber which is stored in the MWD List in the HLR;
- unsuccessful outcome of the procedure. The system failure indication is forwarded to the SC.
09.02, pages 630-631
20.6.1 The macro Report_SM_Delivery_Stat_HLR
This macro is used when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indicationfrom 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 isreturned to the GMSC;
- if the MSISDN number provided is not recognized by the HLR, an unknown subscriber error isreturned to the GMSC;
- if the MAP_REPORT_SM_DELIVERY_STATUS indication reports a successful SM delivery, theService 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 inthe 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. Ifthe MSISDN-Alert stored in the subscriber data is not the same as that received in theMAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a responseprimitive to the GMSC;
- if the SM Delivery Outcome is MS memory capacity exceeded the HLR sets the memorycapacity 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 reachableflag in the subscriber data.
The short message delivery status report macro in the HLR is shown in figure 20.6/1.
CHANGE REQUEST No. A082r2 Technical Specification GSM 09.02 version 5.5.0
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 enhancementsOther phase(s) affected [ ] If yes, linked CR(s):Proposed change affects: SIM [ ] ME [ ] Network [X]Source: SMG3 WPC Date: 1997-05-01Subject: Modifications of 09.02 due to SMS inconsistencies with TS GSM 03.40Category: 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 09.02 on the Short MessageServices as defined in the TS GSM 03.40.
Sections affected, and additional explanation of details of change (if needed):Modified sections: 13.2.2.4, 14.1.6, 14.2.2.22, 14.2.2.24, 14.3.2.22, 14.3.2.26, 14.3.3, 14.5, 14.6.5, 14.7.6, 20.3.4,20.5.2
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 09.90 attached:Change affects operation of: Phase 1 SIM in Phase 2(+) ME[ ]
CR to 09.91 attached:Phase 2(+) SIM in Phase 1 ME [ ]CR to 09.91 attached:
Other comments:
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
"Sequence guaranteed" shall be used when a segmented result is to be transferred (e.g. subscriber data inresponse to SendParameters). It may also be appropriate to use Sequence guaranteed when a series ofInsertSubscriberData, ProcessAccessSignalling or ForwardAccessSignalling operations is used.
TC P-Abort cause MAP provider-reasonunrecognized message type provider malfunctionunrecognized transaction Id supporting dialogue releasedbadlyFormattedTransactionPortion provider malfunctionincorrectTransactionPortion provider malfunction (note)resourceLimitation resource limitationabnormalDialogue provider malfunctionnoCommonDialoguePortion 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 proceduresSpecific services are mapped to TC component handling services.
13.2.1 Directly mapped parametersThe Invoke Id parameter of the MAP request and indication primitive is directly mapped on to the Invoke Idparameter of the component handling primitives.
13.2.2 Use of other parameters of component handling primitives
13.2.2.1 Dialogue IdThe value of this parameter is associated with the MAP PM invocation in an implementation dependent manner.
13.2.2.2 ClassThe value of this parameter is set by the MAP PM according to the type of the operation to be invoked.
13.2.2.3 Linked IdWhen a service response is mapped to a class 4 operation, the value of this parameter is set by the MAP PM andcorresponds to the value assigned by the user to the initial service request (i.e. the value of the invoke ID parameterof the request primitive). Otherwise if such a parameter is included in MAP request/indication primitives it is directlymapped to the linked ID parameter of the associated TC-INVOKE request/indication primitives.
13.2.2.4 OperationWhen mapping a request primitive on to a Remote Operations PDU (invoke), the MAP PM shall set the operationcode 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 ofthe TC-RESULT-L/NL primitive (if required) to the same value as the one received at invocation time.
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
Table 13.2/1: Mapping of MAP specific services on to MAP operations
13.2.2.5 ErrorThe error parameter in a TC-U-ERROR indication primitive is mapped to the user error parameter in the MAPconfirm 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 requestprimitive, except for "initiating-release" and "resource-limitation" which are mapped to the problem code parameterof the TC-U-REJECT request primitive.
13.2.2.6 ParametersThe 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:
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
2. MAP-ApplicationContexts.
The module containing the data types for the Abstract Syntax to be used for TCAPMessages.DialoguePortion forMAP 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 specificationMobile Services Domain and technical specification Transaction Capability respectively:
14.1.6 Application ContextsThe following informative table lists the latest versions of the Application Contexts used in this specification, withthe operations used by them and, where applicable, whether or not the operation description is exactly the same asfor previous versions. Information in sections 14.6 & 14.7 relates only to the ACs in this table.
Note (*): The syntax of the operations is not the same in previous versions unless explicitly stated
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
14.2.2.22 MO Short message relay services1
This operation package includes the operations required for short message relay service procedures between IWMSC2and VMSC or between GMSC and MSC.3MOShortMsgRelayPackage-v3 ::= OPERATION-PACKAGE4 -- Supplier is IWMSC if Consumer is MSC5 -- Supplier is MSC if Consumer is GMSC6 CONSUMER INVOKES {7 MO-forwardSM}8
9The v2-equivalent package is defined as follows:10ShortMsgRelayPackage-v2 ::= OPERATION-PACKAGE11
-- Supplier is IWMSC if Consumer is MSC12-- Supplier is MSC if Consumer is GMSC13CONSUMER INVOKES {14
forwardSM}1516
The v1-equivalent package can be determined according to the rules described in subclause 14.2.1.17
14.2.2.23 Short message gateway services18
This operation package includes the operations required for short message service gateway procedures between MSC19and HLR.20ShortMsgGatewayPackage-v3 ::= OPERATION-PACKAGE21
-- Supplier is HLR if Consumer is GMSC22CONSUMER INVOKES {23
sendRoutingInfoForSM,24reportSM-DeliveryStatus}25
SUPPLIER INVOKES {26informServiceCentre}27
28The v2-equivalent package can be determined according to the rules described in subclause 14.2.129The v1-equivalent package is defined as follows:30ShortMsgGatewayPackage-v1 ::= OPERATION-PACKAGE31
-- Supplier is HLR if Consumer is GMSC32CONSUMER INVOKES {33
sendRoutingInfoForSM34reportSMDeliveryStatus}35
36
14.2.2.24 MT Short message relay services37
This operation package includes the operations required for short message relay service procedures between GMSC38and MSC.39MTShortMsgRelGatewayPackage-v3 ::= OPERATION-PACKAGE40
-- Supplier is MSC if Consumer is GMSC41CONSUMER INVOKES {42
MT-forwardSM}4344
The v2-equivalent package is: ShortMsgRelayPackage-v245
14.2.2.25 [spare]46
14.2.2.26 Message waiting data management47
This operation package includes the operations required for short message waiting data procedures between HLR48and VLR.49MwdMngtPackage-v2 ::= OPERATION-PACKAGE50
-- Supplier is HLR if Consumer is VLR51CONSUMER INVOKES {52
readyForSM}5354
The v1-equivalent package is defined as follows:55MwdMngtPackage-v1 ::= OPERATION-PACKAGE56
-- Supplier is HLR if Consumer is VLR57CONSUMER INVOKES {58
noteSubscriberPresent}59
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
14.3.2.21 Short Message Gateway60
This application context is used for short message gateway procedures.61shortMsgGatewayContext-v3 APPLICATION-CONTEXT62
-- Responder is HLR if Initiator is GMSC63INITIATOR CONSUMER OF {64
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
20.5.2 Procedures in the gateway MSCThe GMSC invokes the short message delivery status report procedure if an absent subscriber_SM indication orunidentified subscriber indication or SM delivery failure error indicating MS memory capacity exceeded is receivedfrom the servicing MSC during a mobile terminated short message transfer, and the HLR has not indicated that theSC address is included in the MWD. The unidentified subscriber indication is however processed as the absentsubscriber_SM indication.The service is invoked also when the HLR has indicated that either of the flags MCEF or MNRF is set and the SMdelivery 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 inthe MAP_REPORT_SM_DELIVERY_STATUS request. In the case of an unsuccessful delivery due to thesubscriber being absent the absent subscriber diagnostic indiciation (if available) is also included in theMAP_REPORT_SM_DELIVERY_STATUS request.The GMSC sends the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR. As a response the GMSCwill 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.
CHANGE REQUEST No. _A083r1_ Technical Specification GSM 09.02 version 5.5.0
Submitted to SMG for approval without presentation ("non-strategic") [ ]
with presentation ("strategic") [ X ]
Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ]
Subject: Clarify 09.02 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 thetext in the detailed procedure handling section and 1) the service description, 2) the ASN.1 descriptionof 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): 140-141, 242, 273-274 and 573-574.
If other core Specifications are affected, necessary (and attached) Joint CRs:Affects (possibly): MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ]Attached CRs?:
The text of Section 20.6.1, “The macro Report_SM_Delivery_Stat_HLR”, gives the detailed proceduresin the HLR for the handling of the ReportSM-DeliveryStatus operation. The section contains a textdescription of the handling of the ReportSM-DeliveryStatus Result (i.e., the storedMSISDNparameter). One item states under which conditions the result will contain the storedMSISDNparameter, 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. Ifthe MSISDN-Alert stored in the subscriber data is not the same as that received in theMAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a responseprimitive to the GMSC;
This section provides for 3 conditions under which the storedMSISDN parameter is populated:
1) Unsuccessful delivery of a short message2) Message waiting list is not full3) 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 thesubscriber be sent in the storedMSISDN parameter of the ReportSM-DeliveryStatus result.
The corresponding GMSC section, 20.5.2, “Procedures in the gateway MSC” specifies the proceduresfor sending, from the GMSC, the MAP_REPORT_SM_DELIVERY_STATUS request to the HLR andreceiving 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 responsethe 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 insection 20.6.1 which states that this parameter is sent optionally under the conditions previouslymentioned.There are three areas that need to be aligned with the text sections just cited.1. 09.02, section 10.3.3, contains the MAP-REPORT-SM-DELIVERY-STATUS service description,
and states that the MSIsdn-Alert parameter is mandatory in the response for successfulcompletion of the operation. This clearly is not consistent with the procedures section in Chapter20 and needs to be aligned with it.
2. Sections 14.6.5, Short message service operations, and 14.7.6, Short message data types,contain the ASN.1 definitions of the ReportSM-DeliveryStatus operation and its parameters. The Resultof this operation is the reportSM-DeliveryStatusRes, which in turn contains the storedMSISDN. Theresult is indicated to be mandatory, and the storedMSISDN parameter within the result is alsoindicated to be mandatory. Since the detailed procedures in sections 20.5.2 and 20.6.1 indicatethat this parameter is sent conditionally, these sections need to be modified to align them with theprocedures section.
3. Figure 20.6/1 contains the macro Report_SM_Delivery_Stat_HLR. This SDL performs the first twochecks listed above, i.e., checks for unsuccessful delivery of short message and message waitinglist not full, but does not make the third check – i.e., checking if the MSISDN-Alert in subscriberdata is the same as that received in the ReportSM-DeliveryStatus. The SDL, based on the first twochecks always sets the storedMSISDN parameter of the result. As just noted, the text specifies athird 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.
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 ofsuccessful 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 serviceprimitives given in table 10.3/1.10.3.2 Service primitives
The service primitives are shown in table 10.3/1.Parameter name Request Indication Response ConfirmInvoke 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
Table 10.3/1: MAP-REPORT-SM-DELIVERY-STATUS
10.3.3 Parameter use
Invoke id:See definition in subclause 5.6.1.MSISDN:See definition in subclause 5.6.2.Service Centre Address:See definition in subclause 5.6.2.SM Delivery Outcome:See definition in subclause 5.6.8. This parameter indicates the status of the mobile terminated SMdelivery.MSIsdn-Alert:See definition in subclause 5.6.2. The presence of tThis parameter is mandatoryshall be present incase of unsuccessful delivery, outcome of the service when the MSISDN received in the operation isdifferent from the stored MSIsdn-Alert; the stored MSIsdn-Alert is the value that is returned to thegateway MSC..
This macro is used when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indicationfrom 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 isreturned to the GMSC;
- if the MAP_REPORT_SM_DELIVERY_STATUS indication reports a successful SM delivery, theService 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 inthe 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. Ifthe MSISDN-Alert stored in the subscriber data is not the same as that received in theMAP_REPORT_SM_DELIVERY_STATUS indication, the MSISDN-Alert is sent in a responseprimitive to the GMSC;
- if the SM Delivery Outcome is MS memory capacity exceeded the HLR sets the memorycapacity 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 reachableflag in the subscriber data. If a reason for absence is provided by the GMSC then this is storedin the mobile station not reachable reason (MNRR) in the subscriber data.
The short message delivery status report macro in the HLR is shown in figure 20.6/1.
Figure 20.6/1: Macro Report_SM_Delivery_Stat_HLR
Figure 20.6/1:The report SM delivery status macroin the HLR
