SMS Call flows for MAP-Interface..

Following picture depicts SMS call flow for both Mobile orginated and mobile termanted short message attempts.

There is another set of potocol messages that are exchanged over RNS/BSS interface. I will cover that in the subsequent posts on SMS call flow on Iu/A interface.

What is the future of SMS ?

Short Message Service.

SMS has been an interesting and basic feature for any mobile. Since its introduction in 1991, it has become a basic element for a mobile handset. The reason for having this service back in pre GPRS era, was for provding mini data/text services to the user on top of voice calls.

Back then we had E1/T1 links for layer1 transport, each E1 or link capable of carrying 64 Kbps of data.
SS7 signalling stack that was used extensively on these transport layers for transferring signalling information across telecom nodes. The Layer2 message being MTP2, had a limitation of 272 bytes on the payload that it carries. This payload contains the MTP3 headers, SCCP headers, TCAP headers, MAP headers, SMS headers and finally SMS Userdata.

According to me this was the reason that SMS designers at that time had to limit the SMS size to 160 bytes, in order to avoid any kind of segmentation at lower layers.

Now with world moving towards 3G/4G/LTE and probable 5G there are alternative high speed data services on the mobile. So the question remain what is the future of SMS ?

Lets consider an example where in a user is about to receive a message(100 bytes ) in two modes
1. through traditional SMS delivery.
2. through 3G's packet delivery procedures.

The protocol messages that are exchanged between network nodes in SMS is less then that are needed in case 2.

On radio/BSS/RNS side for delivery of SMS there is no need for dedicated access bearer. The SMS is exchanged over NAS/BSSAP signalling messages.

Whereas case 2 requires a dedicated bearer to be established.  On top of that, these radio resources will not be released for quite some time. Considering the size of text message, this procedure is wastage of radio resources. As operators want to save on every bit of radio resources this may not go down well with them.

So I guess, SMS is here to stay for some more time.

Post is open for debate..

Though there are many call flows available for SMS on the net,  I am not able to resist myself from adding one more. In the subsequent blogs I will try to cover the call flow from client/server point of view as well as from radio interface perspective ( SGSN/MSC <-> RNC/BSC).

GPRS Activate PDP Context Request

  Here in this chapter I have tried to depict how a MS establishes PDP connection with CoreNetwork in order to use PacketServices of the 3G network.
Courtesy :- 3G specifications and past experience.

  For PDP connection to be established a MS has to first get attached to the network. Refer Attach Procedure for more details.

   MS sends Activate PDP context request to the SGSN. On receiving this request SGSN checks subscriber information (via ISD from HLR) stored in MM context( created during attachProcedure). After passing subscription checking SGSN initiates DNS query to resolves the APN ( Access point name ) received in APCR. This resolved IP is nothing but address of GGSN or PGW(LTE).

   Every APCR has QOS parameter which indicates BitRate for uplink and downlink connections. SGSN checks these parameters with the SusbcriberInfo QOS and comes to negotiable value for QOS.
After these checks and getting the address of GGSN, SGSN constructs a GTP-C messages of createPDPcotextRequest and sends it to the GGSN.

Some main parameters in this request are

• TEID:
• QOS Negotiated
• APN:
• MSISDN:
• NSAPI:
• And other charging information

In response to this, GGSN sends createPDPContextAccept to SGSN with TEIDs, PDPAddress.
Refer 23.060 page 187-189

SGSN now initiates RABAssigment procedure and instructs RNS to allocate a radioresource for this UE. This response contains UTEID, DTEID, RAB ID etc.

After successful allocation of RAB, SGSN sends ActivatePDPContextAccept message with NSAPI, PDPAddress, GGSN address, QOS Negotiated to the MS over RANAP DirectTransfer Message

Following diagram depicts the APCR ( acticatePdpContextRequest) procedure..

• NAS : Non-Access-Stratum
• DT1 : SCCP’s DataForm1 message
• DT : RANAP’s Direct Transfer message
• APCR:  ActicatePdpContextRequest
• APCA: ActivatePdpContextAccept
• NSAPI : Network Service Access Point Identifier
• NSAPI in MS is PDP Sap. MS uses RAB-ID and NSAPI to uniquely identify a PDPContext.

GPRS AttachRequest

This procedure is initiated when MS is powered on.
On powering on, MS receives location information (RAI, LAC, RAC) from the radio channel.
MS contructs NAS AttachRequest and send it to SGSN.Main parameters of AttReq are IMSI/P-TMSI, DRX, Ciphering key sequence, RAI, Network capabilities.


If SGSN does not have authentication vector for the given UE then it initiates SendAuthenticationInfo towards HLR, which responds with authentication parameters ( triplets, quintlets) in SendAuthenticationResponse. SGSN then sends the AuthenticationAndCiphering request to UE. UE computes the authentication vector and send back in AuthenticationAndCiphering response. SGSN then validates these vectors.
Once validation is through, SGSN sends Update location to HLR over Gr (MAP) interface. HLR sends cancel location(imsi) to previous SGSN/MSC/VLR. old vlr responds with cancel location Ack.


HLR then sends insertSubscriberData(ISD) to SGSN. SGSN does basic validation (for MS’s presence, allowed sevices, roaming allowed etc etc) using data received in ISD. If validated, SGSN creates MM context for MS and responds with ISDAck to the HLR.
SGSN then sends AttachAccept( with p-tmsi, signature, and other parameters) to the MS. If SGSN’s assigned P-TMSI is different than MS’s orinigal p-tmsi, then MS replaces it with new p-tmsi allocated by SGSN and sends AttachComplete message to SGSN.


RANAP and SCCP’s involvement
The above mentioned NAS procedure happens over IU Signalling protocol called RANAP. AttachReq from UE is carried forward by RNC over RANAP’s InitialUE message.
Initial UE inturn initiates creation of dedicated transport using SCCP’s CR towards SGSN for this particular UE. Once dedicated signalling connection is established for the UE, all subsequent NAS messages are carried on RANAP’s Direct transfer messages. So in above call flow AttachReq goes on RANAP’s Initial UE piggy backed on SCCP’s CR. All other NAS transactions happens over RANAP’s Direct transfer over SCCP’s DT1 messages.

Cell States

• Before Attach Req MS is in detached state. At this point SGSN doesn’t have information about MS in other words MS is not reachable.
• After Attach complete MS moves into PMM-Connected state and SGSN has correct location information of the MS till RNC level.MM context is created at both MS and SGSN. MS periodically checks the RAI in its MM context with the RAI receveid in radio signal and if there is any change MS initiates NAS-RoutingAreaUpdate procedure towards SGSN.
• Once MS is inactive for certain amount of time, radio resources are relesed by RNC and IU connection by SGSN(thus SCCP connection is released ). At this moment MS moves in PMM-Idle state. SGSN knows the presence of MS is in its boundaries and can trace it till last RAI received ( stored in MM context that it created during attach/RAU procedure).Paging is needed in order to wake up the MS.

Following diagram shows AttachReq with some sample StateMachine and few important parameters