Skip to main content

SMS-SG on LTE/ MTC networks

SMS with LTE (SG-SMS)
SMS (Short Messaging Service) was quite popular among people during 2G/3G, but now with the advent of 4G losing the shine/ attraction. With 4G people are moving to always-on kind of data connectivity and thus market rising with many application options to provide the messaging capabilities. The examples are such as whatsapp, snapchat etc
Now here we are going to discuss, “can an SMS possible in LTE technology ?” and if so “how?”
One possibility of using IMS framework and delivering SMS to/from UE. IMS provides the data (e.g. data, media-voice/video) usage overlaid on LTE technology. The bigger question and climax is on market pace in adapting and deployment of the IMS.
To address the feature availability, an interim solution (SG interfaces) are suggested in specs. (its similar on the lines on how CS fallback option before LTE supporting Voice calls)
Lets revisit the past (2G) on how SMS are delivered.
SMS is delivered over signaling channel. This means there will be no data path (channels) established (allocated in radio) to deliver or receive SMS. Exactly for this reason, SMS delivery or reception doesn’t need UE to fall back to CS network. Once the UE is attached to both MSC and EUTRAN and if MSC wants to deliver a SMS to UE, it will simply send a downlink unit data to MME with SMS content. MME will dump this message in NAS message and send it to UE. In the same way if UE wants to send a SMS it will dump the message in NAS message and send it to MME. MME will extract SMS content and send it to MSC over SGs interface. This operation doesn’t need UE to fall back to CS network thus ensuring smooth delivery of SMS. MME should remember the mapping of Tracking Area and Location Area. This is required because MME would know which MSC the UE signaling message communicated to. When UE is attaching to EUTRAN (LTE), UE will perform a combined attached (to register itself with TAC, LAC information with HSS and MSC)
How is SMS delivered to UE – Network triggers an Paging to UE, using Paging channels (signaling channels on radio). They are kind of always channels, and used to notify the UE to get radio connectivity with network for the purpose of initiating or delivering the signaling messages. Paging channels are slots which are assigned to UE’s based on their IMSI, IMSI’s value are modulo with total no# of paging channels, to map all IMSI’s into one of such common paging slots. Paging message contains an IMSI/ T-IMSI identifier to identify the UE destined for paging message. Upon receiving the paging message by all UE’s listening to that particular paging slot, specific UE to whom the paging message belongs will detect the message is for him and act by initiating network attachment.
In SMS-SG, the SMS is embedded into NAS packets by MME and sent to UE. The MME uses Downlink NAS Transport message to contain SMS data. This followed with Uplink NAS Transport message reporting CP-ACK for delivering the message to MME, optionally UE may also send “Delivery Reports” in another Uplink NAS Transport message to MME. Which gets acknowledged by MME to UE, by sending CP-ACK using Downlink NAS Transport message.
This SMS delivery mechanism is available with LTE network (SGW/PGW) as well as MTC network (SCEF) and can be utilized to transport IP and Non-IP Data to/from UE and MME.
Reference from Spec 3GPP TS 23401 , 
///////// Section - Support for Non-IP Data Delivery (NIDD)
The support of Non-IP data is part of the CIoT EPS optimisations. A PDN Type "Non-IP" is used for Non-IP data. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:
- Delivery using SCEF
- Delivery using a Point-to-Point (PtP) SGi tunnel
For uplink direction – MME sending Data to PGW and PGW forwarding it to AS
For downlink direction – AS sending to PGW, PGW sending to SGW, SGW forwarding it to UE.

Non-IP data in-sequence delivery cannot be guaranteed and data PDUs may be lost requiring higher protocol layers to ensure guaranteed delivery when needed.
                The SMS service may also be used to deliver data without use of the IP protocol. The SMS service is always supported for CIoT EPS optimization, i.e. can be used simultaneously with Non-IP and IP data. When only the SMS service is needed, a attach without PDN connection establishment can be used, see clause 5.3.2.
Dedicated bearers are not supported for the Non-IP data.
///// end of section

References

Comments

Popular posts from this blog

NSSF - an 5G network function to support the network slicing

NSSF - Network Slice Selector Function The 5G System architecture (3GPP TS 23.501: 5G SA; Stage 2) consists of the following network functions (NF). - Authentication Server Function (AUSF) - Core Access and Mobility Management Function (AMF) - Data network (DN), e.g. operator services, Internet access or 3rd party services - Structured Data Storage network function (SDSF) - Unstructured Data Storage network function (UDSF) - Network Exposure Function (NEF) - NF Repository Function (NRF) - Network Slice Selection Function (NSSF) ======>>> our focus - Policy Control function (PCF) - Session Management Function (SMF) - Unified Data Management (UDM) - Unified Data Repository (UDR) - User plane Function (UPF) - Application Function (AF) - User Equipment (UE) - (Radio) Access Network ((R)AN)

Cloud based Frameworks/ Kubernetes environment

Cloud based microservice frameworks Some of open source platforms available are Swarm (Docker), Kubernetes (google), mesos, The most popular in communities and internet industry seems to be kubernetes and picking steam in telecom front as well for upcoming 5G Service based architecture. The kubernetes has the default container solution based on Rket ? but the most popular combinations are using Docker as container. Kubernetes/ an Cloud orachastrator !! Deployment automation of scaling in (zooming in/ increasing) and out (zooming out, decreasing) Network plugin available such as flannel (popular, support only IPv4), calico (support IPv4, IPv6), weavenet Kubernetes currently does not support dual stack IPv4, IPv6 inter-working etc capabilities till version 1.13 (dec 2018). Another limitation, it does not recognize the multiple interfaces in case enable to POD's for configuring services exposure and external communication till version 1.13 (dec 2018) Will be adding more