change requests to gsm 09.02 clarification and ... · subscriberbusyformt-sms, sm-deliveryfailure,...
TRANSCRIPT
Tdoc SMG 379/ 97ETSI TC SMG # 22 Plenary MeetingKristiansand, Norway9th - 13th June 1997
Source: SMG3
Agenda Item: 6.3≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
Change Requests to GSM 09.02Clarification and Modification of SMS handling
≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
Introduction:
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 [ ]
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 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?:
Cross Phase Compatibility:Change affects operation of:Change affects operation of:
Other comments:
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..
From Section 14.6.5, page 265:
ReportSM-DeliveryStatus ::= OPERATION --Timer sARGUMENT
reportSM-DeliveryStatusArg ReportSM-DeliveryStatusArgRESULT
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.
From 09.02, pages 264-265
14.6.5 Short message service operations
MAP-ShortMessageServiceOperations { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9) version2 (2)}
DEFINITIONS
::=
BEGIN
EXPORTSSendRoutingInfoForSM,ForwardSM,ReportSM-DeliveryStatus,NoteSubscriberPresent,AlertServiceCentreWithoutResult,AlertServiceCentre,InformServiceCentre,ReadyForSM
;
IMPORTSOPERATION
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 { ccitt identified-organization (4) etsi (0) mobileDomain (0) 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 { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version2 (2)}
ISDN-AddressString,IMSI
FROM MAP-CommonDataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version2 (2)};
SendRoutingInfoForSM ::= OPERATION --Timer mARGUMENT
routingInfoForSM-Arg RoutingInfoForSM-ArgRESULT
routingInfoForSM-Res RoutingInfoForSM-ResERRORS {
SystemFailure,DataMissing,UnexpectedDataValue,FacilityNotSupported,UnknownSubscriber,TeleserviceNotProvisioned,AbsentSubscriber,CallBarred}
ForwardSM ::= OPERATION --Timer mlARGUMENT
forwardSM-Arg ForwardSM-ArgRESULTERRORS {
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}
ReportSM-DeliveryStatus ::= OPERATION --Timer sARGUMENT
reportSM-DeliveryStatusArg ReportSM-DeliveryStatusArgRESULT
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 1UnexpectedDataValue,UnknownSubscriber,MessageWaitingListFull}
(Note: the rest of the section has been omitted.)
From 09.02, page 289-290
14.7.6 Short message data types
MAP-SM-DataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version2 (2)}
DEFINITIONS
IMPLICIT TAGS
::=
BEGIN
EXPORTSRoutingInfoForSM-Arg,RoutingInfoForSM-Res,ForwardSM-Arg,ReportSM-DeliveryStatusArg,AlertServiceCentreArg,InformServiceCentreArg,ReadyForSM-Arg,
SM-DeliveryOutcome,AlertReason
;
IMPORTSAddressString,ISDN-AddressString,SignalInfo,IMSI,LocationInfo,LMSI
FROM MAP-CommonDataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version2 (2)}
TeleserviceCodeFROM MAP-TS-Code { ccitt identified-organization (4) etsi (0) mobileDomain (0) 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 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.
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
'UpdateMessageWaiting
Data'
'Storingsuccessful'
'SET UE =MESSAGEWAITING
LIST FULL'
'SetMSISDN-
Alert'
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
ETSI/STC/SMG3 WPC Tdoc SMG3 97C 264Bath, UKApril 28th-May 2nd, 1997
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
MAP-SERVICE operationMAP-ACTIVATE-SS activateSSMAP-ACTIVATE-TRACE-MODE activateTraceModeMAP-ALERT-SERVICE-CENTRE alertServiceCentreMAP-ANY-TIME-INTERROGATION anyTimeInterrogatonMAP-CANCEL-LOCATION cancelLocationMAP-CHECK-IMEI checkIMEIMAP-DEACTIVATE-SS deactivateSSMAP-DEACTIVATE-TRACE-MODE deactivateTraceModeMAP-DELETE-SUBSCRIBER-DATA deleteSubscriberDataMAP-ERASE-SS eraseSSMAP-FORWARD-ACCESS-SIGNALLING forwardAccessSignallingMAP-FORWARD-CHECK-SS-INDICATION forwardCheckSsIndicationMAP-MT-FORWARD-SHORT-MESSAGE mt-forwardSMMAP-MO-FORWARD-SHORT-MESSAGE mo-forwardSMMAP-GET-PASSWORD getPasswordMAP-INFORM-SERVICE-CENTRE informServiceCentreMAP-INSERT-SUBSCRIBER-DATA insertSubscriberDataMAP-INTERROGATE-SS interrogateSsMAP-PREPARE-HANDOVER prepareHandoverMAP-PREPARE-SUBSEQUENT-HANDOVER prepareSubsequentHandoverMAP-PROCESS-ACCESS-SIGNALLING processAccessSignallingMAP-PROCESS-UNSTRUCTURED-SS-REQUEST processUnstructuredSS-RequestMAP-PROVIDE-ROAMING-NUMBER provideRoamingNumberMAP-PROVIDE-SUBSCRIBER-INFO provideSubscriberInfoMAP-PURGE-MS purgeMSMAP-READY-FOR-SM readyForSMMAP-REGISTER-PASSWORD registerPasswordMAP-REGISTER-SS registerSSMAP-REPORT-SM-DELIVERY-STATUS reportSmDeliveryStatusMAP-RESET resetMAP-RESTORE-DATA restoreDataMAP-SEND-END-SIGNAL sendEndSignalMAP-SEND-AUTHENTICATION-INFO sendAuthenticationInfoMAP-SEND-IMSI sendIMSIMAP-SEND-IDENTIFICATION sendIdentificationMAP-SEND-ROUTING-INFO-FOR-SM sendRoutingInfoForSMMAP-SEND-ROUTING-INFORMATION sendRoutingInfoMAP-UNSTRUCTURED-SS-NOTIFY unstructuredSS-NotifyMAP-UNSTRUCTURED-SS-REQUEST unstructuredSS-RequestMAP-UPDATE-LOCATION updateLocation
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:
MobileDomainDefinitions;TCAPMessages;DialoguePDUs.
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.
AC Name ACVersion
Operations Used Comments *
locationCancellationContext v2 cancelLocationequipmentMngtContext v2 checkIMEIimsiRetrievalContext v2 sendIMSIinfoRetrievalContext v2 sendAuthenticationInfointerVlrInfoRetrievalContext v2 sendIdentificationhandoverControlContext v2 prepareHandover
forwardAccessSignallingsendEndSignalprocessAccessSignallingprepareSubsequentHandover
mwdMngtContext v2 readyForSMmsPurgingContext v2 purgeMSshortMsgAlertContext v2 alertServiceCentreshortMsgMO-RelayContext v2 forwardSMresetContext v2 resetnetworkUnstructuredSsContext v2 processUnstructuredSS-Request
unstructuredSS-Request
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
unstructuredSS-NotifytracingContext v3 activateTraceMode
deactivateTraceModenetworkFunctionalSsContext v2 registerSS
eraseSSactivateSSdeactivateSSregisterPasswordinterrogateSSgetPassword
shortMsgMO-RelayContext v3 mo-forwardSMshortMsgMT-RelayContext v3 mt-forwardSMshortMsgGatewayContext v3 sendRoutingInfoForSM
reportSM-DeliveryStatusInformServiceCentre
networkLocUpContext v3 updateLocationforwardCheckSs-IndicationrestoreDatainsertSubscriberDataactivateTraceMode
the syntax is the same in v1 & v2
subscriberDataMngtContext v3 insertSubscriberDatadeleteSubscriberData
roamingNumberEnquiryContext v3 provideRoamingNumberlocationInfoRetrievalContext v3 sendRoutingInfo
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
ShortMsgGatewayPackage-v3}65::= {map-ac shortMsgGateway(20) version3(3)}66
67The following application-context-name is assigned to the v2-equivalent application-context:68{map-ac shortMsgGateway(20) version2(2)}69
70The following application-context-name is assigned to the v1-equivalent application-context:71{map-ac shortMsgGateway(20) version1(1)}72
73
14.3.2.22 Mobile originating Short Message Relay74
This application context is used for mobile originating short message relay procedures.75shortMsgMO-RelayContext-v32 APPLICATION-CONTEXT76
-- Responder is IWMSC if Initiator is MSC77INITIATOR CONSUMER OF {78
MOShortMsgRelayPackage-v32}79::= {map-ac shortMsgMO-Relay(21) version32(32)}80
81The following application-context-name is assigned to the v2-equivalent application-context:82{map-ac shortMsgMO-Relay(21) version2(2)}83
84The following application-context-name is assigned to the v1-equivalent application-context:85{map-ac shortMsgMO-Relay(21) version1(1)}86
87
14.3.2.23 [spare]88
14.3.2.24 Short message alert89
This application context is used for short message alerting procedures.90shortMsgAlertContext-v2 APPLICATION-CONTEXT91
-- Responder is IWMSC if Initiator is HLR92INITIATOR CONSUMER OF {93
AlertingPackage-v2}94::= {map-ac shortMsgAlert(23) version2(2)}95
96The following application-context-name is symbolically assigned to the v1-equivalent application-context:97{map-ac shortMsgAlert(23) version1(1)}98
99
14.3.2.25 Short message waiting data management100
This application context is used for short message waiting data management procedures.101mwdMngtContext-v2 APPLICATION-CONTEXT102
-- Responder is HLR if Initiator is VLR103INITIATOR CONSUMER OF {104
MwdMngtPackage-v2}105::= {map-ac mwdMngt(24) version2(2)}106
107The following application-context-name is assigned to the v1-equivalent application-context:108{map-ac mwdMngt(24) version1(1)}109
110
14.3.2.26 Mobile terminating Short Message Relay111
This application context is used for mobile terminating short message relay procedures.112shortMsgMT-RelayContext-v3 APPLICATION-CONTEXT113
-- Responder is MSC if Initiator is GMSC114INITIATOR CONSUMER OF {115
MTShortMsgRelayPackage-v3}116::= {map-ac shortMsgMT-Relay(25) version3(3)}117
118The following application-context-name is assigned to the v2-equivalent application-context:119{map-ac shortMsgMT-Relay(25) version2(2)}120
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
121The following application-context-name is assigned to the v1-equivalent application-context:122{map-ac shortMsgMO-Relay(21) version1(1)}123
124125
The v1-equivalent application-context is: shortMsgRelayContext_v1.126
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
14.3.3 ASN.1 Module for application-context-namesThe following ASN.1 module summarizes the application-context-name assigned to MAP application-contexts.MAP-ApplicationContexts { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ApplicationContexts (2) version3 (3)}
DEFINITIONS
::=
BEGIN
-- EXPORTS everything
IMPORTSgsm-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)}
Draft prETS 300 974 (GSM 09.02 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)}
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
14.5 MAP operation and error codesMAP-Protocol { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Protocol (4) version3 (3)}
DEFINITIONS
::=
BEGIN
IMPORTSUpdateLocation,CancelLocation,PurgeMS,SendIdentification,PrepareHandover,SendEndSignal,ProcessAccessSignalling,ForwardAccessSignalling,PrepareSubsequentHandover,SendAuthenticationInfo,CheckIMEI,InsertSubscriberData,DeleteSubscriberData,Reset,ForwardCheckSS-Indication,RestoreData,ProvideSubscriberInfo,AnyTimeInterrogation
FROM MAP-MobileServiceOperations { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MobileServiceOperations (5) version3 (3)}
ActivateTraceMode,DeactivateTraceMode,SendIMSI
FROM MAP-OperationAndMaintenanceOperations { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OperationAndMaintenanceOperations (6) version3 (3)}
SendRoutingInfo,ProvideRoamingNumber,ResumeCallHandling
FROM MAP-CallHandlingOperations { ccitt identified-organization (4) etsi (0) mobileDomain (0) 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 { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SupplementaryServiceOperations (8) version3 (3)}
SendRoutingInfoForSM, MO-ForwardSM,
MT-ForwardSM,ReportSM-DeliveryStatus,AlertServiceCentre,InformServiceCentre,
14.6.5 Short message service operationsMAP-ShortMessageServiceOperations {
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9) version3 (3)}
DEFINITIONS
::=
BEGIN
EXPORTSSendRoutingInfoForSM,MO-ForwardSM,MT-ForwardSM,ReportSM-DeliveryStatus,AlertServiceCentre,InformServiceCentre,ReadyForSM
;
IMPORTSOPERATION
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 { ccitt identified-organization (4) etsi (0) mobileDomain (0) 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 { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version3 (3)}
;
SendRoutingInfoForSM ::= OPERATION --Timer mARGUMENT
routingInfoForSM-Arg RoutingInfoForSM-ArgRESULT
routingInfoForSM-Res RoutingInfoForSM-ResERRORS {
SystemFailure,DataMissing,UnexpectedDataValue,FacilityNotSupported,UnknownSubscriber,TeleserviceNotProvisioned,CallBarred,AbsentSubscriberSM}
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
MO-ForwardSM ::= OPERATION --Timer mlARGUMENT
mo-forwardSM-Arg MO-ForwardSM-ArgRESULT
mo-forwardSM-Res MO-ForwardSM-Res -- optional
ERRORS {SystemFailure,
DataMissing,UnexpectedDataValue,FacilityNotSupported,
UnidentifiedSubscriber, IllegalSubscriber, IllegalEquipment, AbsentSubscriber, SubscriberBusyForMT-SMS,
SM-DeliveryFailure}
MT-ForwardSM ::= OPERATION --Timer mlARGUMENT
mt-forwardSM-Arg MT-ForwardSM-ArgRESULT
mt-forwardSM-Res MT-ForwardSM-Res-- optional
ERRORS {SystemFailure,DataMissing,UnexpectedDataValue,FacilityNotSupported,UnidentifiedSubscriber,IllegalSubscriber,IllegalEquipment,SubscriberBusyForMT-SMS,SM-DeliveryFailure,AbsentSubscriberSM}
ReportSM-DeliveryStatus ::= OPERATION --Timer sARGUMENT
reportSM-DeliveryStatusArg ReportSM-DeliveryStatusArgRESULT
reportSM-DeliveryStatusRes ReportSM-DeliveryStatusResERRORS {
DataMissing,UnexpectedDataValue,UnknownSubscriber,MessageWaitingListFull}
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
14.7.6 Short message data typesMAP-SM-DataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version3 (3)}
DEFINITIONS
IMPLICIT TAGS
::=
BEGIN
EXPORTSRoutingInfoForSM-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
;
IMPORTSAddressString,ISDN-AddressString,SignalInfo,IMSI,LMSI
FROM MAP-CommonDataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version3 (3)}
AbsentSubscriberDiagnosticSMFROM MAP-ER-DataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version3 (3)}
ExtensionContainerFROM MAP-ExtensionDataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) 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,...}
Draft prETS 300 974 (GSM 09.02 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 [0] IMSI,lmsi [1] LMSI,serviceCentreAddressDA [4] AddressString,noSM-RP-DA [5] NULL}
SM-RP-OA ::= CHOICE {msisdn [2] ISDN-AddressString,serviceCentreAddressOA [4] AddressString,noSM-RP-OA [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 ISDN-AddressString,serviceCentreAddress AddressString,...}
InformServiceCentreArg ::= SEQUENCE {storedMSISDN ISDN-AddressString OPTIONAL,mw-Status MW-Status OPTIONAL,extensionContainer ExtensionContainer OPTIONAL,...}
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
20.3.4 Procedures in the gateway MSC
Figure 20.3/7: The mobile terminatedshort message service process in the GMSC
Process MT_SM_GMSC 203_73(5)
WAIT_FOR_MT_SMS_CONFIRM
MAP_FORWARD_SHORT_ MESSAGE_Cnf
Check_Confirmation Fig 21.2/2
UnidentifiedSubscriber?
Absentsubscriber?
MS memorycapacity
exceeded?
MWDalready
set?
Report_SMDelivery_
Stat_GMSCFig 20.5/2
Set RP_ERROR
SC_RP_ERROR_Req
NULL
SET UE=ABSENT
SUBSCRIBER
Moremessagesto send?
MCEF orMNRF setin HLR?
SC_RP_ACK_Req
Report_SMDelivery_
Stat_GMSC
SC_RP_ACK_Req
WAIT_FOR_MORE_
MESSAGES
2Page 4
3Page 2
MT_SM_Transfer_
MSCFig 20.3/3
NULL
User Error
No
No
Yes
No
OKError
Yes
No
Yes
Yes
OK
No
No
Yes
OKError
Yes
Provider Error,Data Error
ErrorAbort
OK
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
Figure 20.3/7: The mobile terminatedshort message service process in the GMSC
Process MT_SM_GMSC 203_75(5)
WAIT_FOR_MT_SMS_CONFIRM,WAIT_FOR_A_SM_CONFIRM
SC_ABORT_Ind
GMSC=VMSC?
A_ABORT_Req
NULL
MAP_U_ABORT_Ind
MAP_U_ABORT_Ind,MAP_P_ABORT_Ind,A_ABORT_Ind
SET RP_ERROR=SYSTEMFAILURE
SC_RP_ERROR_Req
MAP_NOTICE_Ind
MAP_CLOSE_Req
Yes
No
Draft prETS 300 974 (GSM 09.02 Version 5.5.0): March 1997
Figure 20.3/7: The mobile terminatedshort message service process in the GMSC
Process MT_SM_GMSC 203_76(6)
WAUT_FOR_MORE_MESSAGES
MAP_NOTICE_indSC_ABORT_IndMAP_U_ABORT_IndMAP_P_ABORT_IndA_ABORT_Ind
MAP_CLOSE_Req
SC_ABORT_ReqMAP_U_ABORT_IndA_ABORT_Req
NULL
GMSC = VMSC ?
NO
yES
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 [ ]
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 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?:
Cross Phase Compatibility:Change affects operation of:Change affects operation of:
Other comments:
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.
From 09.02, Section 10.3, page 140-141:
10.3 MAP-REPORT-SM-DELIVERY-STATUS service10.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..
From Section 14.6.5, page 242:
14.6.5 Short message service operations
MAP-ShortMessageServiceOperations { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9) version3 (3)}
DEFINITIONS
::=
BEGIN
... Some text has been omitted.
ReportSM-DeliveryStatus ::= OPERATION --Timer sARGUMENT
reportSM-DeliveryStatusArg ReportSM-DeliveryStatusArgRESULT
reportSM-DeliveryStatusRes ReportSM-DeliveryStatusRes -- optional
ERRORS {DataMissing,UnexpectedDataValue,UnknownSubscriber,MessageWaitingListFull}
From Section 14.7.6, page 273-274:
14.7.6 Short message data types
MAP-SM-DataTypes { ccitt identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version3 (3)}
DEFINITIONS
IMPLICIT TAGS
::=
BEGIN
... Some text has been omitted.
ReportSM-DeliveryStatusRes ::= SEQUENCE {storedMSISDN ISDN-AddressString OPTIONAL,extensionContainer ExtensionContainer OPTIONAL,...}
From Section 20.6.1, pages 573-574:
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 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
Macrodefinition Report_SM_Delivery_Stat_HLR 206_1(1)
Check_Indication
'Subscriberknown'
DeliveryOutcome
'Clear MCEFand MNRF'
MAP_REPORT_SM_DELIVERY_STATUS_rspMAP_CLOSE_req
Alert_Service_
Centre_HLR
OK
'UpdateMessageWaitingData'
'Storingsuccessful'
'SetMSISDN-
Alert'
DeliveryOutcome
'SetMNRF'
Reason for absence available?
Store reason in subscriber Datain MNRR
MAP_REPORT_SM_DELIVERY_STATUS_rspMAP_CLOSE_req
'SetMCEF'
'SET UE =MESSAGEWAITING
LIST FULL'
MAP-REPORT_SMDELIVERY_STATUS_rspMAP_CLOSE_req
Error
'SET UE =UNKNOWN
SUBSCRIBER'
OK
Yes
SuccessfulTransfer
Unsuccessfultransfer
Yes
AbsentSubscriber
yes
No
MS memorycapacityexceeded
No
No
Error
‘MSISDN =MSISDN Alert?’
Yes
No
Attached Original Pages:In order to save trees, for reference, please refer to the corresponding section in TDOC 97c251.