CHANGE REQUESTS TO. GSM 03.40, on Enhanced diagnostic Information for SM-MT GSM 04.11, 04.13, 07.08, on Introduction of RP-ACK User data

Transcription

1 Tdoc SMG 054/97 ETSI TC SMG Paris, France February 1997 Source: SMG4 CHANGE REQUESTS TO GSM 03.40, on Enhanced diagnostic Information for SM-MT GSM 04.11, 04.13, 07.08, on Introduction of RP-ACK User data Introduction : The CR A011 and A062r2 enable the diagnostic information for the absent subscriber being transported from the MSC to HLR and the SM-SC and its storage in the HLR. These CRs are joint and should only be approved or rejected together. The other Crs attached complete the specification of a data field in the acknowledgement message for mobile-terminated short messages. This capability was required for SIM Toolkit applications. The changes to and allow a time of more than 12 seconds. The corresponding change request to GSM had been approved at SMG#19. SPEC VERS CR RE PHA CA SUBJECT STC_DOC SMG_ V SE T PRES ENTA TION A B Absent subscriber diagnostic information and its storage in HLR 96P617 No A C Introduction of the diagnostic information for the absent subscriber error associated with SM-MT delivery attempts. 97P087 No A B RP Ack data unit 96A305 No A C time available to respond to an SMS 97P107 No A B Time response to RP-DATA with an RP-ACK 97P078 No A B GSM API RP-Ack PDU 96P688 No A B RP-Ack data 97P087 No Other Comments: The CRs to are based on v as modified by CR A053 (Extensibility), A055 (Alignment with GSM 03.18), CR A064 (Unknown Operations) and CR A067 (fallback from v3). Total number of pages Page 1

2 Page 2 Blank page

3 CHANGE REQUEST No. A011r3 Technical Specification GSM version Submitted to SMG for approval without presentation ("non-strategic") [ X ] with presentation ("strategic") [ ] 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: SMG4 Date: 26/09/96 Subject: Absent Subscriber diagnostic information and its storage in the HLR Category: F - Correction [ ] A - Corresponds to a Phase 2 correction [ ] B - Addition of Feature [ X ] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: The introduction of diagnostic information with the Absent subscriber error indication will enable the MSC and HLR to sent the reason for a subscriber s absence to the SC. An enhancement to this concept is the storage in the HLR of the the absent subscriber diagnostic information returned from the MSC. By this, when a subscriber is detached or not responding to paging in a network with more than one service center, the reason for the subscribers absence can be relayed to all the SC that attempt to send a SM. The SC are enabled to adjust any polling algorithm accordingly. Sections affected, and additional explanation of details of change (if needed): Subclause: 2.1.1, 3.2.6, 3.2.8, 3.3.2, Refer to Tdoc SMG4 96P617 for more explanations. 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 [ ] Change affects operation of: Phase 1 SIM in Phase 2(+) ME[ ] CR to attached: Other comments: CR to attached: Phase 2(+) SIM in Phase 1 ME [ ] CR to attached:

4 Page 2 CR to Draft prets (GSM Version 5.4.0): November Definitions active MS: A switched-on mobile station with a SIM module attached. alert-sc: Service element provided by a GSM PLMN to inform an SC which has previously initiated unsuccessful short message delivery attempt(s) to a specific MS, that the MS is now recognized by the PLMN to have recovered operation. status report: SC informing the originating MS of the outcome of a short message submitted to an SME. Gateway MSC For Short Message Service (SMS-GMSC): A function of an MSC capable of receiving a short message from an SC, interrogating an HLR for routing information and SMS info, and delivering the short message to the VMSC of the recipient MS. Interworking MSC For Short Message Service (SMS-IWMSC): A function of an MSC capable of receiving a short message from within the PLMN and submitting it to the recipient SC. Messages-Waiting (MW): Service element that makes a PLMN store information (Messages-Waiting-Indication), listing those SCs that have made unsuccessful short message delivery attempts to MSs in that PLMN. Messages-Waiting-Indication (MWI): Data to be stored in the HLR and VLR with which an MS is associated, indicating that there is one or more messages waiting in a set of SCs to be delivered to the MS (due to unsuccessful delivery attempt(s)). Messages-Waiting-Data (MWD): A part of the MWI to be stored in the HLR. MWD consists of an address list of the SCs which have messages waiting to be delivered to the MS. Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF): A part of the MWI to be stored in the HLR. MCEF is a Boolean parameter indicating if the address list of MWD contains one or more entries because an attempt to deliver a short message to an MS has failed with a cause of MS Memory Capacity Exceeded. Mobile-Station-Not-Reachable-Flag (MNRF): The part of the MWI to be stored in the VLR and the HLR. MNRF is a Boolean parameter indicating if the address list of MWD contains one or more entries because an attempt to deliver a short message to an MS has failed with a cause of Absent Subscriber. Mobile-Station-Not-Reachable-Reason (MNRR): The part of the MWI in the HLR which stores the reason for an MS being absent when an attempt to deliver a short message to an MS fails at the MSC with a cause of Absent Subscriber. More-Messages-To-Send (MMS): Information element offering an MS receiving a short message from an SC the information whether there are still more messages waiting to be sent from that SC to the MS. The TP-MMS element (conveyed in the Transfer layer) is copied into the RP-MMS element (conveyed in the Relay layer). It is possible with Phase 2 and later versions of MAP (GSM TS 09.02) for the RP-MMS element to keep an SM transaction open between the GMSC and the MS in the case where there are more-messages-to-send. Earlier versions of MAP will support the transport of the TP-MMS element. priority: Service element enabling the SC or SME to request a short message delivery attempt to an MS irrespective of whether or not the MS has been identified as temporarily absent. protocol-identifier: Information element by which the originator of a short message (either an SC or an MS) may refer to a higher layer protocol. reply path procedure: A mechanism which allows an SME to request that an SC should be permitted to handle a reply sent in response to a message previously sent from that SME to another SME. This may happen even though the SC may be unknown to the SME which received the initial message. report: Response from either the network or the recipient upon a short message being sent from either an SC or an MS. A report may be a delivery report, which confirms the delivery of the short message to the recipient, or it may be a failure report, which informs the originator that the short message was never delivered and the reason why.

5 Page 3 CR to Draft prets (GSM Version 5.4.0): November 1996 When issued by the Service Centre, the delivery report confirms the reception of the Short Message by the SC, and not the delivery of the Short Message to the SME. When issued by the Mobile Station, the delivery report confirms the reception of the Short Message by the Mobile Station, and not the delivery of the Short Message to the user. replace short message type: A range of values in the Protocol Identifier which allows an indication to be sent with a short message (MT or MO) that the short message is of a particular type allowing the receiving MS or the SC to replace an existing message of the same type held in the SC, the ME or on the SIM, provided it comes: - in MT cases: from the same SC and originating address; - in MO cases: from the same MS. Service Centre (SC): Function responsible for the relaying and store-and-forwarding of a short message between an SME and an MS. The SC is not a part of the GSM PLMN, however MSC and SC may be integrated. short message: Information that may be conveyed by means of the Short Message Service described in this specification. Short Message Entity (SME): An entity which may send or receive Short Messages. The SME may be located in a fixed network, an MS, or an SC. SMS-STATUS-REPORT: Short message transfer protocol data unit informing the receiving MS of the status of a mobile originated short message previously submitted by the MS, i.e. whether the SC was able to forward the message or not, or whether the message was stored in the SC for later delivery. SMS-COMMAND: Short message transfer protocol data unit which enables an MS to invoke an operation at the SC. An MS may then, for example, delete a short message, cancel a Status Report Request, enquire about the status of a short message or request another function to be performed by the SC. The type of operation is indicated by the TP-Command-Type and the particular SM to operate on is indicated by the TP-Message-Number and the TP-Destination-Address. Receipt of an SMS-COMMAND is confirmed by an RP-ACK or RP-ERROR. In the case of certain SMS-COMMANDs, an SMS-STATUS-REPORT may be sent, where the outcome of the SMS-COMMAND is passed in its TP-Status field. SMS-DELIVER: Short message transfer protocol data unit containing user data (the short message), being sent from an SC to an MS. SMS-SUBMIT: Short message transfer protocol data unit containing user data (the short message), being sent from an MS to an SC. Service-Centre-Time-Stamp (SCTS): Information element offering the recipient of a short message the information of when the message arrived at the SM-TL entity of the SC. The time of arrival comprises the year, month, day, hour, minute, second and time zone. Validity-Period (VP): Information element enabling the originator MS to indicate the time period during which the originator considers the short message to be valid. *** Next modified section *** Messages-Waiting The Messages-Waiting is the service element that enables the PLMN to provide the HLR and VLR with which the recipient MS is associated with the information that there is a message in the originating SC waiting to be delivered to the MS. The service element is only used in case of previous unsuccessful delivery attempt(s) due to temporarily absent mobile or MS memory capacity exceeded. This information,

6 Page 4 CR to Draft prets (GSM Version 5.4.0): November 1996 denoted the Messages-Waiting-Indication (MWI), consists of Messages-Waiting-Data (MWD), the Mobile-Station-Not-Reachable-Flag (MNRF), the Mobile-Not-Reachable-Reason (MNRR) and the Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF) located in the HLR, and the Mobile-Station-Not-Reachable-Flag (MNRF) located in the VLR. figure 03.40/3 shows an example. HLR; MWD: M SIsdn-Alert SC address 1 SC address 2 SC address n MNRF MNRR MCEF VLR; MNRF Figure 03.40/3: Example of how information on one MS can be put in relation to SC(s) in order to fulfil the requirement of Alert-SC mechanism The MWD shall contain a list of addresses (SC-Addr) of SCs which have made previous unsuccessful delivery attempts of a message (see section 5). In order to be able to send alert messages to every SC which has made unsuccessful delivery attempts to an MS, the HLR shall store the MSIsdn-Alert (see section 3.2.7) together with references to the SC addresses. The requirements placed upon the HLR are specified in GSM The description of how the HLR is provided with SC and MS address information is given in GSM The Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF) within the HLR is a Boolean parameter with the value TRUE when the list MWD contains one or more list elements because an attempt to deliver a short message to an MS has failed with a cause of MS Memory Capacity Exceeded, and with the value FALSE otherwise. The Mobile-Station-Not-Reachable-Flag (MNRF) within the HLR and the VLR is a Boolean parameter with the value TRUE when the list MWD contains one or more list elements because an attempt to deliver a short message to an MS has failed with a cause of Absent Subscriber, and with the value FALSE otherwise. The Mobile-Station-Not-Reachable-Reason (MNRR) within the HLR stores the reason for the MS being absent when an attempt to deliver a short message to an MS fails at the MSC with the cause Absent Subscriber. The HLR updates the MNRR with the reason for absence when an absent subscriber diagnostic information is received from the GMSC and the MNRF is set. The HLR clears the MNRR when the MNRF is cleared. If the MNRF is set due to a failure at the MSC with cause Absent Subscriber and information pertaining to the absence of the MS is not available from the GMSC, the MNRR will remain in a cleared state. The MNRR shall either be in a cleared state or contain one of the following reasons: No Paging Response IMSI Detached Note: When a short message delivery attempt fails at the HLR due to Roaming being Restricted, the MS being Deregistered in HLR or the MS being Purged the absent subscriber diagnostic reason is returned to the SC, however the reason is not stored in the MNRR.

7 Page 5 CR to Draft prets (GSM Version 5.4.0): November 1996 The MWD, MCEF, MNRR and MNRF are updated in the following way: 1a) When a mobile terminated short message delivery fails due to the MS being temporarily absent (i.e. either IMSI DETACH flag is set or there is no response from the MS to a paging request), the SC address is inserted into the MWD list (if it is not already present), and the MNRF is set (if it is not already set) and the MNRR is updated (if the information is available), as described in section 10. 1b) When a mobile terminated short message delivery fails due to the MS memory capacity being exceeded, the SC address is inserted into the MWD list (if it is not already present) and the MCEF is set (if it is not already set), as described in section 10. 1c) If the MSIsdn used by the SC to address the recipient MS for alerting purposes is different from the MSIsdn-Alert of the MS (see section 3.2.7), the HLR returns the MSIsdn-Alert to the SC within the failure report, see "1c Failure report" in figures 03.40/15 and /16. 2a) When either the HLR or VLR detects that the MS (with a non-empty MWD and the MCEF clear in the HLR and the MNRF set in the VLR) has recovered operation (e.g. has responded to a paging request), the HLR directly or on request of the VLR will invoke operations to alert the SCs within the MWD (see section and section 10). Once the Alert SC operations have been invoked, the MNRF and MNRR are is cleared. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. If the MCEF is set in the HLR, the HLR clears the MNRF and MNRR, but does not invoke operations to alert the SCs within the MWD and data are not cleared from the MWD. 2b) When the HLR receives (via the MSC and the VLR) a notification that the MS (with a non-empty MWD and the MCEF set in the HLR) has memory capacity available to receive one or more short messages, the HLR will invoke operations to alert the SCs within the MWD (see section and section 10). Once the Alert SC operations have been invoked, the MNRF is cleared in the VLR and the MCEF, and MNRF and MNRR are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. 2c) When the HLR receives from the SMS-GMSC a notification that a short message has been successfully delivered from an SC to an MS for which the MCEF is set and the MWD are not empty, the HLR will invoke operations to alert other SCs within the MWD (see section and section 10). Once the Alert SC operations have been invoked, the MCEF,and MNRF and MNRR are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. The SC which successfully delivered the message is also deleted from the MWD, if present. 2d) When the HLR receives (via the MSC and the VLR) a notification that the MS has memory capacity available to receive one or more short messages but the MCEF is not set and the MWD are empty, the HLR acknowledges the notification but does not alert any service centre. *** Next modified section *** Options concerning MNRF, MNRR, MCEF and MWD Setting the Mobile-Station-Not-Reachable-Flag (MNRF) in the VLR is mandatory. It is also mandatory for the VLR to send the "MS Present" message (see section 10) to the HLR when the MS has been detected as becoming active and then to clear MWF. The Messages-Waiting-Data (MWD, the Mobile-Station-Not-Reachable-Flag (MNRF), the Mobile-Station- Not-Reachable-Reason (MNRR) and the Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF)) within the HLR are optional, but if one is implemented all must be implemented. This is linked to the transmission of the "Alert SC" message. The following describes what happens when a delivery fails. Case 1: MWD, MNRF, MNRR and MCEF are implemented in the HLR

8 Page 6 CR to Draft prets (GSM Version 5.4.0): November 1996 In the case of a delivery failure (to an MS) with cause Absent Subscriber, the MSC requests the HLR to add, if needed, a new entry in the MWD with cause Absent Subscriber. This new entry contains the SC address. The HLR sets its copy of the MNRF and updates the MNRR (if the information is available). The SC is notified of the failure, the reason for the MS being absent and also of the MWD setting in the HLR within the Report message (see section 10). In the case of a delivery failure (to an MS) with cause Mobile Station Memory Capacity Exceeded, the MSC requests the HLR to add, if needed, a new entry in the MWD with cause Mobile Station Memory Capacity Exceeded. This new entry contains the SC address. The HLR sets the MCEF. The SC is notified of the failure and also of the MWD setting in the HLR within the Report message (see section 10). If the HLR indicates that it is able to store the SC address, then the SC will receive an Alert SC message when the MS becomes active. If the HLR indicates that it is unable to store the SC address (e.g. because MWD is full), then the only way to ensure delivery is for the SC to try to retransmit the message periodically. When the HLR receives the MS Present message, if the MCEF is clear it sends an Alert SC message to the concerned SC and updates MWD. When the HLR receives the MS Memory Capacity Available message, it sends an Alert SC message to the concerned SC, updates MWD and clears the MCEF. Case 2: MWD, MNRF, MNRR and MCEF are not implemented in the HLR In the case of a delivery failure, the SC is notified that the HLR is unable to store its address in the MWD. In case of a delivery failure (to a MS) with cause Absent Subscriber, the SC is notified of the reason for the MS being absent (if the information is available). The SC must retransmit the short message periodically in order to ensure delivery. The HLR discards the MS Present message received from the VLR without any failure or error report. The HLR discards the MS Memory Capacity Available message received from the MS via the MSC and the VLR without any failure or error report. *** Next modified section *** Errors occurring after TPDU arrives at MS These errors may occur due to the MS not supporting optional short message service features, or in connection with a short message application. An error indication shall be returned to the SC from the SMS-GMSC. Additionally, a TPDU (SMS-DELIVER-REPORT) containing diagnostic information may be conveyed from the MS to the originating SC, transparently through the PLMN, by means defined in GSM and GSM The sending of the diagnostic information is optional at the MS, but when it is sent, the PLMN shall convey the information to the SC, and the SC shall support reception of the information.

9 Page 7 CR to Draft prets (GSM Version 5.4.0): November 1996 Table 03.40/1: Error indications related to mobile terminated short message transfer which may be transferred to the originating SC. Error indication S1) Meaning Unknown subscriber P The PLMN rejects the short message TPDU because there is not allocated an IMSI or a directory number for the mobile subscriber in the HLR (see GSM 09.02). Teleservice not provisioned P The PLMN rejects the short message TPDU because the recipient MS has no SMS subscription (see GSM 09.02). Call barred T The PLMN rejects the short message TPDU due to barring of the MS (see GSM 09.02, description of the Barring supplementary service, GSM and 03.11), and description of Operator Determined Barring, GSM and 03.15). Facility not supported T The VPLMN rejects the short message TPDU due to no provision of the SMS in the VPLMN (see GSM 09.02). Absent subscriber T The PLMN rejects the short message TPDU because - there was no paging response, (see GSM & GMS 09.02) - the IMSI record is marked detached (see GSM 09.02), or - the MS is subject to roaming restrictions (see "Roaming not allowed", GSM 09.02). - deregistered in the HLR. The HLR does not have an MSC number stored for the target MS, (see GSM 09.02) - MS purged, (see GMS 09.02) (The reasons for absence are assigned interger values in table 03.40/1a. The appropriate integer value is sent with the absent subscriber error indication as defined in GSM 09.02) MS busy for MT SMS T The PLMN rejects the short message TPDU because of congestion encountered at the visited MSC. Possible reasons include any of the following events in progress: - short message delivery from another SC - IMSI detach - Location Update - paging - emergency call - call setup SMS lower layers capabilities not provisioned T The PLMN rejects the short message TPDU due to MS not being able to support the Short Message Service. The short message transfer attempt is rejected either due to information contained in the class-mark, or the MSC not being able to establish connection at SAPI = 3 (see GSM and GSM 09.02). Error in MS T The PLMN rejects the short message TPDU due to an error occurring within the MS at reception of a short message, e.g. lack of free memory capacity or protocol error. Illegal Subscriber P The PLMN rejects the short message TPDU because the MS failed authentication Illegal Equipment P The PLMN rejects the short message TPDU because the IMEI of the MS was black-listed in the EIR System failure T The PLMN rejects the short message TPDU due to network or protocol failure others than those listed above (see GSM 09.02) Memory Capacity Exceeded T The MS rejects the short message since it has no memory capacity available to store the message 1) : Status (Permanent or Temporary) The relation between the two sets of error indications is given in the table 03.40/1. Each error is classified as either "Temporary" or "Permanent". This classification gives an indication of whether or not it is probable that the MS becomes attainable within a reasonable period, and so provides the recommended action to be taken by the SC, i.e. either to store the message for later transfer, or to discard it.

10 Page 8 CR to Draft prets (GSM Version 5.4.0): November 1996 Integer value Reason for absence 0 - no paging response 1 - IMSI detached 2 - roaming restriction 3 - deregistered in the HLR 4 - MS purged All other integer values are reserved. Table 03.30/1a Assignment of integer values to reasons for absence (integer values must be in the range of 0 to 255, see GSM 09.02) *** Next modified section *** Functionality of the SMS-GMSC When receiving a short message TPDU from the SC, the SMS-GMSC is responsible for the following operations: - reception of the short message TPDU; - inspection of the parameters. NOTE: The SMS-GMSC may be identical to the MSC. if parameters are incorrect: - returning the appropriate error information to the SC in a failure report (see sections 9 and 10); if errors are not found within parameters: - interrogating the HLR ("sendroutinginfoforshortmsg", see section 10); retrieving routing information or possible error information; if HLR is returning error information: - returning the appropriate error information to the SC in a failure report (see sections 9 and 10); if no errors are indicated by the HLR: - transferring the short message TPDU to the MSC using the routing information obtained from the HLR ("forwardshortmessage", see section 10). When receiving the report associated with the short message from the MSC (positive or negative outcome of "forwardshortmessage", see section 10), the SMS-GMSC is responsible for the following operations: if the report indicates successful delivery: - notifying the HLR of the successful delivery, which will cause the HLR to alert any service centres whose addresses are stored in the MWD for the MS; if the report is a failure report indicating "absent subscriber" (see section 3.3): - requesting the HLR to insert the address of the originating SC into the MWD (if implemented) with cause Absent Subscriber ("setmessagewaitingdata", see sections 9 and 10); - informing the HLR of the reason for the MS being absent (if this information is available) - establishing, where necessary, a link with the addressed SC (see section 5); - creating and sending the report to the SC which should include the reason for the MS being absent (if this information is available) so that the SC may adjust any retry algorithm appropriately (see sections 9 and 10);

11 Page 9 CR to Draft prets (GSM Version 5.4.0): November 1996 if the report is a failure report indicating "MS memory capacity exceeded" (see section 3.3): - requesting the HLR to insert the address of the originating SC into the MWD (if implemented) with cause MS Memory Capacity Exceeded ("setmessagewaitingdata", see sections 9 and 10); - establishing, where necessary, a link with the addressed SC (see section 5); - creating and sending the report to the SC (see sections 9 and 10).

12 ETSI SMG3 Plenary - Bern Tdoc 96P217 (ETSI-SMG3 Working Party A Tdoc 96A305) 2-5/9/96, Sophia Antipolis CHANGE REQUEST No. A078 Technical Specification GSM 04.11, version Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Phase 1: [ ] Phase 2: [ ] Phase 2+: [X] Work item: TEI Other phase(s) affected [no] If yes, linked CR(s): Proposed change affects: SIM [ ] ME [X] Network [X] Source: Vodafone Date: 5/9/96 Subject: RP ACK data unit Category: F - Correction [ ] A - Corresponds to a phase 2 correction [ ] B - Addition of Feature [X] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: SMG 4 and SMG 9 have requested to have the ability to carry a TPDU in the RP-ACK message and SMG 4 has produced a CR to This CR provides the necessary change to Sections affected, and additional explanation of details of change (if needed): section 7.3. Attached revised pages: 34 If other core Specifications are affected, necessary (and attached) Joint CRs: CR??. Affects (possibly): MS Test Specs [?] BSS Test Specs [N] O&M Specs [N] Attached CRs?: Cross Phase Compatibility: Change affects operation of: Phase 1 MS in Phase 2(+) NW [N] Phase 2(+) MS in Phase 1 NW [?] CR to attached: phase 2 network needs to ignore extra type 4 IE in the RP-ACK. Change affects operation of: Phase 1 SIM in Phase 2(+) ME[N] CR to attached: Phase 2(+) SIM in Phase 1 ME [N] CR to attached: Other comments:

13 7.3 Messages for short message and notification transfer on SM-RL Page 33 GSM Version December 1995 This section describes the functional definition and content of the messages sent between two SMR entities. There are 4 messages defined: RP-DATA, RP-SMMA, RP-ACK and RP-ERROR RP-DATA A phase 2 entity shall not reject a RP-DATA message where both address elements have a length greater than RP-DATA (Network to Mobile Station) This message is sent in MSC -> MS direction. The message is used to relay the TPDUs. The information elements are in line with TS GSM See table 7.4/GSM Table 7.4/GSM 04.11: RP-DATA message content Information element Reference Presence Format Length RP-Message Type Section M V 3 bits RP-Message Reference Section M V 1 octet RP-Originator Address Section M LV 1-12 octets RP-Destination Address Section M LV 1 octet RP-User Data Section M LV 239 octets RP-DATA (Mobile Station to Network) This message is sent in MS -> MSC direction. The message is used to relay the TPDUs. The information elements are in line with TS GSM See table 7.5/GSM Table 7.5/GSM 04.11: RP-DATA message content Information element Reference Presence Format Length RP-Message Type Section M V 3 bits RP-Message Reference Section M V 1 octet RP-Originator Address Section M LV 1 octet RP-Destination Address Section M LV 1-12 octets RP-User Data Section M LV 239 octets RP-SMMA This message is sent by the mobile station to relay a notification to the network that the mobile has memory available to receive one or more short messages. The information elements are in line with TS GSM See table 7.6/GSM Table 7.6/GSM 04.11: RP-SMMA message content Information element Reference Presence Format Length RP-Message Type Section M V 3 bits RP-Message Reference Section M V 1 octet RP-ACK This message is sent between the MSC and the mobile station in both directions and used to relay the acknowledgement of a RP-DATA or RP-SMMA message reception. The information elements are in line with TS GSM See table 7.7/GSM

14 Page 34 GSM Version December 1995 Table 7.7/GSM 04.11: RP-ACK message content IEI Information element Reference Presence Format Length RP-Message Type Section M V 3 bits RP-Message Reference Section M V 1 octet 41 RP-User Data Section O TLV 240 octets RP-ERROR This message is sent between the MSC and the mobile station in both directions and used to relay an error cause from an erroneous short message or notification transfer attempt. The information elements are in line with TS GSM See table 7.8/GSM The contents of the cause field are given in Section Table 7.8/GSM 04.11: RP-ERROR message content IEI Information element Reference Presence Format Length RP-Message Type Section M V 3 bits RP-Message Reference Section M V 1 octet RP-Cause Section M LV 2-3 octets 41 RP-User Data Section O TLV 240 octets

15 CHANGE REQUEST No. A079 Technical Specification GSM 04.11, version "non - strategic Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Phase 1: [ ] Phase 2: [ ] Phase 2+: [X] Work item: TEI Other phase(s) affected [no] If yes, linked CR(s): Proposed change affects: SIM [X] ME [X] Network [X] Source: SMG3 Date: 28/1/97 Subject: Time available to respond to an SMS Category: F - Correction [ ] A - Corresponds to a phase 2 correction [ ] B - Addition of Feature [ ] C - Functional modification of Feature [X] D - Editorial modification [ ] Reason for change: Currently it is unclear how long a mobile station should wait for a response (to a mobile terminating SMS) from a SIM or TE before aborting the connection with the network. Such a specification is needed in order that SIM (and TE) applications can be designed safely. Sections affected, and additional explanation of details of change (if needed): section 10. Sections 5.3 and 6 are attached for information. Attached revised pages: If other core Specifications are affected, necessary (and attached) Joint CRs: none. Affects (possibly): MS Test Specs [?] BSS Test Specs [N] O&M Specs [N] Attached CRs?: Cross Phase Compatibility: Change affects operation of: Phase 1 MS in Phase 2(+) NW [N] Phase 2(+) MS in Phase 1 NW [N] CR to attached: Change affects operation of: Phase 1 SIM in Phase 2(+) ME[N] CR to attached: Phase 2(+) SIM in Phase 1 ME [N] CR to attached: Other comments:

16 5.3 Short message control procedures The procedures needed for short message control are: - - RP Data Unit (RPDU) transfer procedures; - connection release procedures; and - procedures for abnormal cases. connection establishment procedures; The procedures of section 5.3 are described with respect to one particular instance of an SMC entity. Different SMC entities are identified by their Transaction Identifier. Messages with Transaction Identifiers that do not correspond to this particular instance of the SMC entity are not treated by it MM-connection establishment When an SMC entity is in the Idle state and transfer of an RPDU is requested, the peer to peer connection between the MM-sublayers in the MS and the network (MSC) has to be established. The SMC entity on the originating side requests the MM-sublayer to establish an MM-connection, and enters the MM-Connection Pending state. After completion of the MM-connection establishment, a confirmation is given to the originating side to indicate that the MM sublayer is ready for RPDU transfer. The MM-connection establishment is indicated to the SMC entity at the destination side when the CP- DATA message has been received by the MM-sublayer (in line with TS GSM 04.08). The destination side SMC entity then sends a CP-ACK and enters the MM-Connection Established state RPDU transfer When an SMC entity in the MM-Connection Pending state is informed that an MM-connection has been established, the SMC entity forwards the CP-DATA message containing the RPDU, sets the timer TC1* and enters the Wait for CP-ACK state. The value of TC1* may vary with the length of the CP-DATA message and the channel type that is being used for its transmission. However, the value of TC1* shall be sufficiently great to allow the lower layers to transmit the CP-DATA and CP-ACK messages and to allow for some retransmissions of layer 2 frames, If an SMC entity in the Wait for CP-ACK state gets an indication that the CP-DATA message has probably been lost (e.g. due to dedicated channel assignment, handover, assignment failure, handover failure, or a SAPI 3 data link failure) then, as an implementation option, that SMC entity may reduce the time until expiry of TC1*. If the timer TC1* expires in the Wait for CP-ACK state, the CP-DATA message is retransmitted and the state Wait for CP-ACK is reentered. The maximum number of CP-DATA message retransmissions is an implementation option but shall be either 1, 2 or 3. If the timer TC1* expires after the maximum number of retransmission attempts, an error indication is passed to SM-RL and an MM-connection release request is passed to the MM-sublayer. The Idle state is then entered. On receipt of the CP-ACK message in the Wait for CP-ACK state, the SMC resets the timer TC1* and enters the MM-Connection Established state. When receiving a CP-DATA message in the MM-Connection Established state, the SMC entity checks the parameters relevant to the CP protocol. If these are valid, the RPDU is passed to the SM-RL, the CP-ACK message is sent and the state MM-Connection Established is reentered. If an SMC entity in the Idle state is unable to accept a CP-DATA message, it sends a CP-ERROR message followed by an MM-connection release request and then enters the Idle state. When receiving a MNSMS-DATA-Req primitive in the MM-Connection Established state, the SMC entity forwards a CP-DATA message containing the RPDU to the MM-sublayer, sets the timer TC1* and enters the Wait for CP-ACK state.

17 5.3.3 Release of MM and CM connections With the exception of error situations, release of the MM and CM connection is controlled by the SM-RL. When an SMC entity in the Wait for CP-ACK state receives a release request from SM-RL, this request is stored until the next state (either MM Connection Established or Idle) is entered. If the Idle state is entered, the request is discarded. If the MM Connection Established state is entered, or if the SMC entity receives a release request from SM-RL in this state, an MM-connection release request is sent to the MMsublayer and the SMC entity enters the Idle state Abnormal cases Abnormal cases that shall be handled by the SMC entity in any state can be classified into five cases: - Upper Layer Abort: Errors occurring in the SM-RL may cause the SM-RL to send an MNSMS- ABORT Request to the SMC entity. - CP-Layer Abort: Errors occurring within the SMC entity itself may require termination of all activities related to that transaction identifier. - Lower Layer Abort: Errors occurring within the layers beneath the CP-layer may cause an MMSM- ERROR Indication to be sent to the SMC entity. - CP-Layer Protocol Errors: Errors occurring within the protocol exchange between the SMC entities may result in the sending of a CP-ERROR message between the entities. - Lower Layer Release: Events occurring within the layers beneath the CP layer may cause an MMSM-REL Indication to be sent to the SMC entity. When the CM-sublayer in the network receives an Upper Layer Abort, it may form and send the CP- ERROR message to release the connection. Irrespective of whether or not the CP-ERROR message was sent, an MM-connection release request, without indication of release cause, is passed to the MMsublayer. The SMC entity in the network then enters the Idle state. When the CM-sublayer in the MS receives an Upper Layer Abort and if the MM connection exists, it shall form and send the CP-ERROR message. Irrespective of whether or not the CP-ERROR message was sent, an MM-connection release request, without indication of release cause, is passed to the MMsublayer. The SMC entity in the mobile station then enters the Idle state. In the case of a CP-Layer Abort, an error indication is passed to SM-RL. If possible, a CP-ERROR message is sent to the partner SMC entity to indicate the error situation. Then the SMC entity enters the Idle state. In the case of a Lower Layer Abort, the SMC entity passes an error indication to SM_RL, an MMconnection release request is passed to the MM-sublayer, and the SMC entity immediately enters the Idle state. In the case of the reception of a CP-ERROR message from the partner SMC entity, an error indication is passed to SM-RL, an MM-connection release request, without indication of release cause, is passed to the MM-sublayer, and the SMC entity enters the Idle state. In the case of a lower layer release, the SMC entity passes an MNSMS-ERROR Indication to SM-RL and then enters the Idle state. In all cases, if the timer TC1* is running, it is reset. Due to structure of message flow on SAPI 0 and 3 it is possible that the CP-ACK of a short message transfer might not be received (e.g. due to handover). If the first CP-ACK (acknowledging the CP-DATA that carried the first RPDU) is not received the reception of CP-DATA may be interpreted as the reception of the awaited CP-ACK and CP-DATA message.

18 5.4 Concatenating short message or notification transfers If an entity has more than one short message or notification to send, then it is useful to maintain the Radio Resource (RR) connection in between transfers. For mobile terminated short messages this is simple because the network decides when, and whether, to release the RR connection. However, for mobile originated transfers, the network does not know whether or not the mobile has more messages to transfer. If another short message or a memory available notification is to be sent, an originating SMR entity in the MS may choose to continue to use the same RR connection. When the MS chooses to use the same RR connection, then: - the MS shall transmit a CM SERVICE REQUEST for the new CM connection before the final CP- ACK (e.g. the one that acknowledges the CP-DATA that carried the RP-ACK) for the old MM connection is transmitted; - before transmission of the first CP-DATA on the new MM connection, the MS shall transmit the CP- ACK for the old MM connection; - the Transaction Identifier used on the new MM connection shall be different to that used on the old MM connection; and - the MS shall not initiate establishment of the new MM connection before the final CP-DATA (e.g. the one carrying the RP-ACK) has been received. NOTE: When an MS sends successive memory available notifications and/or mobile originated short messages on different RR connections, the MS is strongly recommended to use different Transaction Identifiers for the old and new MM connections. Due to the structure of message flow on SAPIs 0 and 3 it is possible that the final CP-ACK of a short message transfer may not be received (e.g. due to transmission errors and/or handovers). For mobile terminated transfers, if the CP-ACK is lost, the reception of a CP-DATA with a different transaction identifier and carrying an RPDU shall be interpreted as the implicit reception of the awaited CP-ACK followed by the reception of the new CP-DATA message. For mobile originated transfers, if the CP-ACK is lost, the reception of a CM SERVICE REQUEST followed by a CP-DATA with a different transaction identifier and carrying an RPDU shall be interpreted as the implicit reception of the awaited CP-ACK followed by the reception of the new CP-DATA message.

19 6 SM-RL-procedures 6.1 General This section describes the procedures used by the SMR entity for short message and notification support on the Short Message Relay Layer. An SMR entity communicates with a corresponding peer entity using a CM-connection. Multiple CM-connections may be established at the same time, allowing parallel transactions. There is a functional one to one relation between the SMR entity and the SMC entity of the CM-sublayer. The descriptions of the procedures are related to one single transaction. The RL-procedures described in this section can only be performed if a CM-connection has been established between the mobile station and the network. Detailed SDL-diagrams for short message control on SM-RL are contained in annex D. 6.2 Transition states of SMR entity The state transition diagram for the SMR entities on both MS-side and network side are contained in Annex D SMR-states at the MS-side of the radio interface The states described in this section are for a SMR entity in a MS, handling mobile originating- and mobile terminating short messages and notification transfer Idle (State 0) This state exists when the SMR entity is in idle mode, or when a short message or notification transfer ends in a normal or abnormal way Wait for RP-ACK (State 1) This state exists for mobile originating short message or notification transfer when the SMR has passed the RP-DATA or RP-SMMA to the SMC entity and set the timer TR1M Wait for RETRANS TIMER (State 4) This state exists for memory available notification when the SMR is waiting to retransmit the RP-SMMA message. Timer TRAM has been set. The possibility of an abort of the sending of the memory available notification by the SM-TL exists. No underlying connection exists SMR-states at the network side of the radio interface The states described in this section are for a SMR entity in a MSC, handling mobile originating- and mobile terminating short message and notification transfer Idle (State 0) This state exists when the SMR entity is in idle mode, or when a short message transfer or notification end in a normal or abnormal way Wait for RP-ACK (State 1) This state exists for a mobile terminating short message transfer when the SMR has passed the RP- DATA message to the SMC entity and set the timer TR1N Wait to send RP-ACK (State 3) The SMR entity will enter this state after passing a received RP-DATA or RP-SMMA message to RL and setting the timer TR2N.

20 6.3 Short Message Relay procedures The procedures needed for short message and notification relaying are: - TP Data Unit (TPDU) relay procedures; - notification relay procedures; - procedures for abnormal cases TPDU relaying When the SMR entity is in the Idle state and receives a request from SM-TL to relay a TPDU, it forms and transfers the RP-DATA message (containing the TPDU), sets the timer TR1* and enters the state Wait for RP-ACK. Retransmission of RP data units by the CM-sublayer is described in section 5. When the SMR entity is in the "Wait for RP-ACK" state, the following situations may occur: a) reception of an RP-ACK or RP-ERROR message (containing the same reference number as the transmitted RP-DATA message); b) reception of an error indication from the CM-sublayer; c) the timer TR1* expires. In case a) or b), the timer TR1* is reset, a report indication is passed to SM-TL, a request to release the CM-connection is passed to CM-sublayer, and the SMR entity enters the Idle state. In case c), a request to abort the CM-connection is passed to the CM-sublayer, a report indication is passed to SM-TL, and the SMR entity enters the Idle state. When the SMR entity is in the Idle state and receives an MNSMS-EST-Ind containing a valid RP-DATA message, it passes the SMS-TPDU to the SM-TL, starts timer TR2*, and enters the state "Wait to Send RP-ACK". When the SMR entity is in the state "Wait to Send RP-ACK" and the SMR entity receives the SM-RL- Report-Request, the timer TR2* is reset, the RP-message (RP-ACK or RP-ERROR) is generated and relayed to the peer entity, a CM-connection release request is passed to the CM-sublayer, and the SMR entity enters the Idle state. When the SMR entity is in the state "Wait to Send RP-ACK" and the SMR entity receives an error indication from the CM-sublayer, the timer TR2* is reset, a report indication is passed to the SM-TL and the SMR entity enters the Idle state. When the SMR entity is in the state "Wait to send RP-ACK" and the timer TR2* expires, the SMR entity passes a CM-connection abort request to the CM-sublayer, a report indication is passed to the SM-TL, and the SMR entity enters the Idle state [spare] Notification relaying MS side Idle state When the SMR entity in the MS in the Idle state receives a request from the SM-TL to relay a notification to the network, it forms and transfers the RP-SMMA message, starts timer TR1M, and enters the state Wait for RP-ACK Wait for RP-ACK state When the SMR entity in the MS is in the Wait for RP-ACK state and it receives either:

21 - an RP-ACK (containing the same reference number as the last transmitted RP-SMMA message); or - an RP-ERROR (containing the same reference number as the last transmitted RP-SMMA message) with a permanent failure indication; or - an error indication from the CP-sublayer; then the MS shall reset timer TR1M, pass a report indication to SM-TL, give a CM-connection release request to the CM-sublayer, and enter the Idle state. If set, timer TRAM and the RETRANS flag are also reset. When the SMR entity in the MS is in the Wait for RP-ACK state and either: - it receives an RP-ERROR (containing the same reference number as the last transmitted RP- SMMA message) with a temporary failure indication; or - timer TR1M expires; then the MS shall examine the RETRANS flag: - if the RETRANS flag is set (i.e. no more transmissions of the RP-SMMA message are permitted) then, - the MS shall pass a report indication to SM-TL, give a CM-connection release request to the CM-sublayer, reset the RETRANS flag, reset TR1M, and enter the Idle state. - If the RETRANS flag is not set (i.e. at least another transmission of the RP-SMMA message is currently permitted) then, - the MS shall give a CM-connection release request to the CM-sublayer, set the RETRANS flag, reset TR1M, start timer TRAM and enter the Wait for Retrans Timer state. When the SMR entity in the MS is in the Wait for RP-ACK state and it receives an SM-RL-MEMORY- AVAILABLE-Req (SMS-MEM-NOTIF-ABORT) primitive, then the MS shall set the RETRANS flag and reenter the Wait for RP-ACK state Wait for RETRANS Timer state When the SMR entity in the MS is in the Wait for Retrans Timer state and timer TRAM expires then, the MS shall form and transfer an RP-SMMA message, start timer TR1M, and enter the state Wait for RP- ACK. The RP-Message Reference in this RP-SMMA message shall be different from that in the previous RP-SMMA message. When the SMR entity in the MS is in the Wait for Retrans Timer state and it receives an SM-RL- MEMORY-AVAILABLE-Req (SMS-MEM-NOTIF-ABORT) primitive, then the MS shall reset the RETRANS flag, reset timer TRAM, pass a report indication to SM-TL, and enter the Idle state Network side Idle state When the SMR entity in the network is in the Idle state and receives an MNSMS-EST-Ind containing a valid RP-SMMA message, it passes the SMS-TPDU to the SM-TL, starts timer TR2N, and enters the state "Wait to send RP-ACK" Wait to Send RP-ACK state When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the SMR entity receives the SM-RL-Report-Request, timer TR2N is reset, the RP-message (RP-ACK or RP-ERROR) is generated and relayed to the MS, a CM-connection release request is passed to the CM-sublayer, and the SMR entity enters the Idle state. When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the SMR entity receives an error indication from the CM-sublayer, timer TR2N is reset, a report indication is passed to the SM-TL and the SMR entity enters the Idle state.

22 When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the timer TR2N expires, the SMR entity passes a CM-connection abort request to the CM-sublayer, a report indication is passed to the SM-TL, and the SMR entity enters the Idle state Abnormal cases Format errors etc.: If the SMR entity upon receipt of an RP-DATA or RP-SMMA message detects an erroneous condition which it can act on, (e.g. format errors, invalid parameters etc.) it shall return an RP- ERROR message with an appropriate cause value and possibly extended diagnostic information, release or abort the CM-connection, and enter the Idle state.