The Short Message Service is realised by the use of the Mobile Application Part (MAP) of the SS#7 protocol, with Short Message protocol elements being transported across the network as fields within the MAP messages. These MAP messages may be transported using 'traditional' TDM based signalling, or over IP using SIGTRAN and an appropriate adaptation layer. The Short Message protocol itself is defined by 3GPP TS 23.040 for the Short Message Service - Point to Point (SMS-PP), and 3GPP TS 23.041 for the Cell Broadcast Service (CBS).
Four MAP procedures are defined for the control of the Short Message Service:
Mobile Originated (MO) short message service transfer;
Mobile Terminated (MT) short message service transfer;
Short message alert procedure;
Short message waiting data set procedure.
MO short message service transfer
Call flow for the Mobile Originated short message service
The diagram to the right depicts a simplified call flow for a successful submission of a mobile originated short message.
When the subscriber sends a short message, the handset sends the text message over the air interface to the VMSC/SGSN. Along with the actual text of the short message, the destination address of the SM and the address of the Short Message Service Centre (SMSC) are included, the latter taken from the handset's configuration stored on the SIM card.
Regardless of the air interface technology, the VMSC/SGSN invokes the MAP service package MAP_MO_FORWARD_SHORT_MESSAGE to send the text to the Interworking MSC of the Service Centre whose address was provided by the handset. This service sends the mo-ForwardSMa[›] MAP operation to the SMSC identified in the SM Submission from the handset, embedded within a Transaction Capabilities Application Part (TCAP) message, and transported over the core network using the Signalling Connection Control Part (SCCP).
The Interworking MSC of the SMSC, on receipt of the MAP mo-ForwardSM message, passes the SMS-PP Application Protocol Data Unit (APDU) containing the text message to the actual Service Centre (SC) of the SMSC for storing, and subsequent 'forwarding' (delivery) to the destination address and the SC returns an acknowledgement indicating success or failure. On receipt of this submission status from the Service Centre, the Interworking MSC will send an appropriate indication back to the VMSC/SGSN of the sending subscriber. The message submission status is then forwarded, over the air interface, to the subscriber's handset.
MT short message service transfer
Call flow for the Mobile Terminated short message service
The figure to the right depicts a call flow for Mobile Terminated short message delivery.For the sake of simplicity, some of the interactions between the VMSC and VLR, and VMSC and Handset, have been omitted.
When the SMSC determines it needs to attempt to deliver a short message to its destination, it will send the SMS-PP APDU containing the text message, the 'B-Party' (destination phone number) and other details to the Gateway MSC (GMSC) logical component on the SMSC. The GMSC, on receipt of this short message, needs to discover the location of the B-Party in order to be able to correctly deliver the text to the recipient (the term Gateway MSC, in this context, indicating an MSC that is obtaining routing information from the Home Location Register (HLR)). To do this, the GMSC invokes the MAP service package MAP_SEND_ROUTING_INFO_FOR_SM, which sends a sendRoutingInfoForSM (SRI-for-SM) MAP message to the destination number's HLR, requesting their present location. This SRI-for-SM message may be sent to an HLR in the same network as the SMSC, or via an interconnect to an HLR in a foreign PLMN, depending on which network the destination subscriber belongs to.
The HLR performs a database lookup to retrieve the B-Party's current location, and returns it in an acknowledgement message to the SMSC's GMSC entity. The current location may be the MSC address the subscriber is currently roaming on, the SGSN address, or both. The HLR may also return a failure, if it considers the destination to be unavailable for short messaging; see the Failed short message delivery section below.
Having obtained the routing information from the HLR, the GMSC will attempt to deliver the short message to its recipient. This is done by invoking the MAP_MT_FORWARD_SHORT_MESSAGE service, which sends a MAP mt-ForwardSMc message to the address returned by the HLR, regardless of whether it is an MSC (Circuit Switched SMS delivery) or an SGSN (Packet Switched SMS delivery).
The VMSC will request the information needed for it to deliver the Short Message to its recipient by sending a Send_Info_for_MT_SMS message to the VLR. The VLR will then instigate a page request, or subscriber search, for the destination subscriber's Mobile Subscriber ISDN Number (MSISDN), and return the result to the VMSC. Since a typical deployment sees the VLR being co-located with the MSC, this message flow is usually internal to the platform.d[›] Should the page or search for the subscriber fail, the VLR will indicate the failure cause to the VMSC which will abort the Short Message delivery procedure and return the failure to the SMSC (see the Failed short message delivery section below). If the page of the handset was successful, the VMSC will then send to the SMSC indicating successful delivery. The GMSC component of the SMSC passes the result of the delivery attempt to the Service Centre. In the case of successful delivery, the delivered text message will be removed from the Store and Forward Engine (SFE) and, if requested, a delivery report sent to the text originator. If the delivery failed, the SMSC invokes a retry procedure to periodically make further attempts at delivery; additionally, it may register with the HLR to receive a notification when the B-Party becomes available for short message delivery in the future (see the Failed short message delivery section below).
Failed short message delivery
When the VMSC/SGSN indicates a short message delivery failure, the SMSC may send a message to the HLR, using the MAP_REPORT_SM_DELIVERY_STATUS procedure, indicating the reason for the delivery failure and requesting that the SMSC be put on a list of service centres wanting to be notified when the destination party becomes available again. The HLR will set a flag against the destination account, indicating that it is unavailable for short message delivery, and store the SMSC's address in the Message Waiting Data (MWD) list for the destination party. Valid flags are Mobile Not Reachable Flag (MNRF), Memory Capacity Exceeded Flag (MCEF) and Mobile Not Reachable for GPRS (MNRG). The HLR will now start responding to SRI-for-SM requests with a failure, indicating the failure reason, and will automatically add the requesting SMSC's address to the MWD list for the destination party. (However if the SRI-for-SM message has priority flag set then the HLR will reply with VLR address if available)
The HLR may be informed of a subscriber becoming available for short message delivery in several ways:
Where the subscriber has been detached from the network, a reattach will trigger a Location Update to the HLR.
Where the subscriber has been out of coverage, but not fully detached from the network, on coming back into coverage it will respond to page requests from the Visitor Location Register (VLR). The VLR will then send a Ready-for-SM (mobile present) message to the HLR.
Where the MS has had its memory full, and the subscriber deletes some texts, a Ready-for-SM (memory available) message is sent from the VMSC/VLR to the HLR.
Upon receipt of an indication that the destination party is now ready to receive short messages, the HLR sends an AlertSC MAP message to each of the SMSCs registered in the MWD list for the subscriber, causing the SMSC to start the Short Message delivery process again, from the beginning.
Additionally, the SMSC will go into a retry schedule, attempting to periodically deliver the SM without getting an alert. The retry schedule interval will depend on the original failure cause - transient network failures will result in short retry schedule, whereas out of coverage will typically result in a longer schedule.-
MAP Transport Protocols
While the MAP 3GPP specifications make some effort to divorce MAP from the layer that transports it, the typical transport is via TCAP which in turn is via SCCP/MTP[1-3] and/or SIGTRAN protocols (SUA, M3UA etc).
A MAP_OPEN construct therefore is directly related to a TCAP_BEGIN with a MAP application context, a MAP_CLOSE is a TCAP_END.
If a message is being delivered using MAP phase 2 or higher, and over MTP rather than SIGTRAN then the maximum MTP PDU size may cause the sender to instigate segmented message sending. This process is not related to concatenation, but simply means that the transaction with the MSC/SMSC/SGSN involves more steps than usual. The recommended way is an empty TCAP_BEGIN, followed by the MAP content within a TCAP_CONTINUE, and completing with a TCAP_END. The TCAP_BEGIN has TCAP related information that would otherwise cause the limit to be exceeded due to the additional fields added by MAP phase 2. The exact point that segmentation is required is dependent on factors such as the length of the addresses but is mainly dependent on the message length itself. 7 bit alphabet messages that are 140 characters or greater are typically subject to the MAP segmentation procedure.
This segmentation procedure is also increasingly followed, and optionally enforced, by carriers to avoid SMS spoofing impacting their customers. This works because the sending party must receive the responses in order to send a message and so their originating address must be correct.
Notes
^ a: In MAP Phase 1, there was no segregation of operation code for Mobile Originated and Mobile Terminated SMS messages, just a generic ForwardSM operation.
^ b: A success indication in these contexts is only a notification that the SM has been submitted to the Service Centre, and does not mean successful delivery to the ultimate destination of the text message.
^ c: Although MAP (phase 2 onwards) specifies a separate operation for mobile terminated short message delivery, often the mo-ForwardSM operation is used instead. Where this is the case, mobile originated and terminated messages are distinguished by the inclusion, in the TCAP dialogue portion, of an appropriate Application Context (AC). The relevant ACs are shortMessageMO-RelayContext and shortMessageMT-RelayContext. This use of a single operation code enables simple backwards compatibility with MAP phase 1 networks, which do not have separate operations for MO and MT short messages.
^ d: These messages are not used by an SGSN.
(source:wikipdia)
No comments:
Post a Comment