Delivery of Voice and Text Messages

over LTE
• 1. The Market for Voice and SMS!
• 2. Third Party Voice over IP!
• 3. The IP Multimedia Subsystem!
• 4. Circuit Switched Fallback!
• 5. VoLGA
• LTE was designed as a data pipe that would
deliver information to and from the user !
• For most data services, such as web browsing
and emails!
✓ The applications are separate from the delivery
system and are supplied by third parties !
• For voice and text messages!
✓ The applications have previously been
supplied by network operator and have been
tightly integrated into the delivery system
• Two main approaches to the delivery of voice over
LTE, both of which can be implemented in two
ways!
✓ The first approach!
- Treat voice like any other data service!
- Deliver it using a voice over IP server that lies
outside the LTE network!
- Can be implemented by !
‣ A third party service provider!
‣ A separate IP Multimedia Subsystem (IMS)
 ✓ The second approach!
- Connect LTE to the circuit switched (CS)
domains of 2G and 3G, and to use their existing
capabilities for placing voice calls !
- Can be implemented using two other
techniques!
‣ Circuit switched fallback [備⽤用系統]!
‣ Voice over LTE via generic access!
• Each of these four techniques can be adapted for the
delivery of text messages, using either SMS or a
proprietary messaging application
1. The Market for Voice and SMS
• Figure 1.5 !
✓ Measurements of voice and data traffic in worldwide mobile
telecommunication networks, in the period from January
2007 to July 2011!
• Figure 1.6 !
✓ Forecasts of voice and data traffic in worldwide mobile
telecommunication networks, in the period from 2011 to 2016!
• Figure 16.1 !
✓ Revenue earned by network operators in Western Europe
from voice, messaging such as SMS and other data services,
with operators’ data up to 2011 and forecasts thereafter
 Figure 1.5 Measurements of voice and data traffic in worldwide mobile
telecommunication networks, in the period from January 2007 to July 2011.
Figure 1.6 Forecasts of voice and data traffic in worldwide mobile
telecommunication networks, in the period from 2011 to 2016.
Figure 16.1 Revenue earned by network operators in Western Europe from voice, messaging
and other data services, with operators’ data up to 2011 and forecasts thereafter.
• Data applications supply most of the operators’
traffic, but voice supplies most of their revenue !
• The imbalance between voice and data traffic is
even more extreme in Western Europe than
elsewhere, e.g.!
✓ Data comprised about 90% of Western
European traffic in 2011, compared with about
70% worldwide
• Voice data rates are low (usually 64 kbps in the CS domains of 2G and
3G) and now only make up a small percentage of the total network
traffic!
• Voice applications provide many valuable features to the user!
✓ Notably supplementary services such as voicemail and call
forwarding!
✓ Communication with fixed phones on PSTN!
✓ The ability to place emergency calls!
• Because of this, operators can still charge a large premium [額外費⽤用] for
voice services!
✓ This premium is falling, but, voice still makes a disproportionate [不成
比例] contribution to operator revenue!

• A similar but more extreme situation applies in the case of messaging

services, which make a negligible contribution to network traffic
• 1. The Market for Voice and SMS!
• 2. Third Party Voice over IP!
• 3. The IP Multimedia Subsystem!
• 4. Circuit Switched Fallback!
• 5. VoLGA
2. Third Party Voice over IP
• The simplest technique is to
provide a voice over IP
(VoIP) service through a
third party supplier such as
Skype!
• The following figure shows
the generic architecture that
might typically be used for a
voice service !
• A similar approach can be
used for text messages
Figure 16.2 Architecture of a generic third party
VoIP system.
• The user sets up a call by!
✓ Exchanging VoIP
signaling messages
with an external VoIP
server, and ultimately
with another fixed or
mobile phone!
• During call setup!
✓ VoIP server can send
LTE signaling
messages to the Policy
and Charging Rules
Function (PCRF), so as
to request a dedicated
EPS bearer to transport
the call
• By doing this, the system
can ensure a good QoS for
the user, at least over the
path between mobile and
P-GW!
• Using media gateways
(MGW)!
✓ The VoIP system can
also convert IP packets
to and from the data
streams that are used
by traditional CS
networks!
✓ This allows the user to
make a call from a VoIP
device to a 2G or 3G
phone, or to a land line
• Some technical issues !
✓ If the user moves outside the region of LTE
coverage, then the system may be able to handle
the call using the 2G or 3G PS domains, or may
be able to convert it to a traditional CS call!
- If it does not support either of these
approaches, then the call will have to be
dropped!
✓ Skype does not support emergency calls, so
cannot yet be used to replace a traditional voice
service
• 1. The Market for Voice and SMS!
• 2. Third Party Voice over IP!
• 3. The IP Multimedia Subsystem!
• 4. Circuit Switched Fallback!
• 5. VoLGA
3. The IP Multimedia Subsystem
• 3.1 IMS Architecture!
• 3.2 IMS Procedures!
• 3.3 SMS over IMS
 3.1 IMS Architecture
• IP Multimedia Subsystem (IMS)!
✓ A separate 3GPP network,
which communicates with EPC
and with the PS domains of
UMTS and GSM so as to
control real time IP multimedia
services such as voice over IP!
• IMS was originally specified in
3GPP Release 5, which was
frozen in 2002
• Few 3G operators ever introduced because it is a
complex system that requires significant investment
from network operator!
• IMS is, however, very suitable for the delivery of voice
and SMS over LTE and can be viewed as a sophisticated
3GPP version of the third party VoIP system!
• The use of IMS is being promoted by the Voice over LTE
(VoLTE) initiative of the GSM Association (GSMA),
based on earlier work by an industrial collaboration
known as One Voice !
• It is likely to be the main long term solution for the
delivery of voice over LTE
• A simplified version of IMS and its
relationship with LTE!
✓ The most important components are Call
Session Control Functions (CSCFs), of
which there are three types!
✓ Proxy CSCF (P-CSCF)!
- The mobile’s first point of contact with
IMS!
- Compresses the signaling messages
that the mobile exchanges with the
IMS so as to reduce their load on the
LTE transport network!
- Secures those messages by encryption
and integrity protection !
- Communicates with PCRF over the Rx
interface, so as to guarantee the QoS
of the IP multimedia streams
✓ Serving CSCF (S-CSCF)!
- Controls the mobile, in a
similar way to an MME!
- Every mobile is registered
with a S-CSCF, which sets up
calls with other devices on
the mobile’s behalf and
which contacts the mobile if
an incoming call arrives!
✓ Interrogating CSCF (I-CSCF)!
- The first point of contact for
signaling messages that
arrive from another IMS
Figure 16.3 Basic architecture of the IP multimedia
subsystem.
• IMS Media Gateway (IM-MGW) and
Media Gateway Control Function (MGCF)!
✓ Allow IMS to communicate with
traditional CS networks such as PSTN !
✓ IM-MGW converts VoIP streams to CS
streams and back again!
✓ MGCF carries out the same role for
signaling messages, controls the IM-
MGW and is itself controlled by S-CSCF!
• Application Servers (ASs)!
✓ Provide the user with supplementary
services such as voicemail!
• Home Subscriber Server (HSS)!
✓ A central database that is shared with
EPC
• Session Initiation Protocol (SIP)!
✓ The main IMS signaling protocol!
✓ An IETF protocol widely used by other VoIP systems!
✓ IMS network elements use SIP to !
- Communicate with each other and with the mobile!
- Carry out tasks such as registering the mobile and
setting up a call!
✓ SIP messages can contain embedded information
written using Session Description Protocol (SDP) , !
- SDP defines the properties of the media such as the
requested data rate and the supported codecs
• The mobile!
✓ Identifies itself to IMS using a private identity,
which acts in a similar way to the IMSI!
✓ Identifies itself to the outside world using one
or more public identities, which act like phone
numbers or email addresses!
• These identities are stored in the IP multimedia
services identity module (ISIM), which is a UICC
(Universal Integrated Circuit Card) application
similar to the USIM
 3.2 IMS Procedures
• The two most important IMS procedures are
registration and call setup!
• If a mobile supports IMS, then it registers with
the IMS after it has completed the attach
procedure !
• Network operators typically use a separate
Access Point Name (APN) for IMS, so the mobile
begins by connecting to that APN using the UE
requested PDN connectivity procedure
• The network responds by setting up a default
EPS bearer for signaling communications with
the IMS, most likely using QoS class identifier
5
• Using this bearer, the mobile
sends a SIP registration
request to the P-CSCF,
which forwards it to a
suitable S-CSCF!
• In the registration procedure
that follows, the mobile and
S-CSCF authenticate each
other, and the mobile
registers its public identities
with S-CSCF
 ECM：EPS Connection Management
SDP：Session Description Protocol

• If an incoming call arrives, then the S-CSCF contacts the

mobile by sending it a SIP signaling message over the EPS
bearer!
✓ If the mobile is in ECM-IDLE state, then the message
triggers the LTE paging procedure!
✓ The mobile moves back to ECM-CONNECTED by means
of a service request and responds
 ECM：EPS Connection Management
SDP：Session Description Protocol

• During call setup!

✓ The two mobiles exchange SIP signaling messages
with embedded SDP session descriptions, so as to set
up the call and negotiate the voice codec that they
will use!
• At the same time, the two IMSs negotiate the QoS
 PCRF：Policy and Charging Rules Function
• In each IMS!
✓ P-CSCF asks PCRF to supply
a QoS that is appropriate for
the selected codec!
• In response!
✓ The P-GW sets up a
dedicated EPS bearer that
will carry the call !
• The IMS can also set up a call
to a traditional CS network,
using the media and signaling
conversion functions provided
by IM-MGW and MGCF
• Single Radio Voice Call Continuity (SRVCC)!
✓ If a mobile moves outside the coverage area of LTE, then the
network can use SRVCC technique to transfer the mobile from VoIP
communications over IMS to traditional CS communications over
GSM, UMTS or cdma2000 1xRTT!
✓ SRVCC technique is based on inter-system handover procedures,
but with extra steps to transfer the call without loss of service!
• IMS offers full support for emergency calls over LTE from Release 9,
using features such as null integrity protection algorithm!
✓ Integrity protection allows a device to detect modifications to the
signaling messages that it receives, as a protection against problems
such as man-in-the-middle attacks!
✓ From Release 9, mobiles can use a null integrity protection
algorithm for the sole purpose of making emergency voice calls
without a UICC (Universal Integrated Circuit Card)
 3.3 SMS over IMS
• IMS can also deliver SMS messages using SMS over
generic IP access technique!
• The only new component is the IP short message gateway
(IP-SM-GW), which acts as an interface between IMS and
the network elements that handle SMS messages
Figure 16.4 Architecture used to deliver SMS messages
over the IP multimedia subsystem.
• To transmit an SMS message!
✓ The mobile embeds it into a SIP signaling message and sends it to
IMS !
✓ The IP-SM-GW extracts the embedded SMS message and sends it
to SMS interworking MSC (SMS-IWMSC)!
✓ This device then forwards the message to the SMS service centre
(SC), which stores the message for delivery to its destination!
• The same sequence is used in reverse to deliver a message, except
that the SMS-IWMSC is replaced by SMS gateway MSC (SMS-GMSC)
• 1. The Market for Voice and SMS!
• 2. Third Party Voice over IP!
• 3. The IP Multimedia Subsystem!
• 4. Circuit Switched Fallback!
• 5. VoLGA
4. Circuit Switched Fallback
• 4.1 Architecture!
• 4.2 Combined EPS/IMSI Attach Procedure!
• 4.3 Voice Call Setup!
• 4.4 SMS over SGs!
• 4.5 Circuit Switched Fallback to cdma2000
1xRTT
 4.1 Architecture
• Many network operators are rolling out [推出] LTE
before they roll out IMS !
• Because of this, users may wish to place voice
calls from LTE devices in the absence of IMS !
• To deal with this possibility, 3GPP has
standardized circuit switched (CS) fallback as a
possible interim approach
• Using CS fallback, a user can make voice calls by
reverting [回復] to traditional CS communications
over UMTS or GSM!
• The architecture builds on the architecture for
inter-operation with the 2G/3G PS domain, by
supporting the CS domain as well
Figure 16.5 Circuit switched fallback architecture.
• In this architecture!
✓ An MME can communicate with a MSC server that supports CS fallback,
across SGs interface !
✓ The signaling messages are written using the SGs application protocol
(SGsAP)!
✓ Using these messages, a mobile can!
- Register with an MSC server!
- Set up a CS voice call!
- Send or receive an SMS message using SMS over SGs technique
 4.2 Combined EPS/IMSI Attach
Procedure
• When a mobile switches on!
✓ It registers with a serving MME using the attach procedure !
✓ This procedure is modified for mobiles that support CS
fallback, so as to register the mobile with an MSC server as well
Figure 11.4 Overview of the attach procedure.
Figure 16.6 Combined EPS/IMSI attach procedure.
• Step (1)!
✓ In its attach request, the mobile uses EPS attach type to
request a combined EPS/IMSI attach!
✓ This indicates that it is configured for CS fallback and/or
SMS over SGs and would like to register with an MSC
server
• Step (2)!
✓ The MME runs steps 3 to 16 of the attach procedure,
which cover the steps required for identification and
security, location updates and default bearer creation!
• Step (3)!
✓ The MME then identifies a suitable MSC server and
sends it an SGsAP Location Update Request
• Step (4)!
✓ In response, MSC server creates an association between mobile and
MME and runs a location update procedure, in which it registers the
mobile and updates the CS domain’s copy of the mobile’s location!
• Step (5-6)!
✓ The MSC server then acknowledges the original request from the
MME and the MME runs the remaining steps of the attach procedure!
✓ In its attach accept, the MME indicates whether the result was a
combined EPS/IMSI attach, or an EPS only attach
 4.3 Voice Call Setup
• The figure shows the procedure
for a mobile originated voice call
using CS fallback!
• Assumptions!
✓ The mobile has previously
registered with the CS domain
using the combined EPS/IMSI
attach and that the mobile is
starting in RRC_IDLE state !
✓ The network can hand over
the mobile’s PS services to the
2G/3G PS domain
Figure 16.7 Procedure for mobile
originated call setup using circuit
switched fallback, with the
packet switched services handed
over.
• The mobile starts with the usual
procedures for random access and
RRC connection establishment, and
then writes an Extended Service
Request!
✓ This indicates that the mobile
would like to place a voice call
using CS fallback and includes
the reason for the request, namely !
- Mobile originated call!
- Mobile terminated call!
- Emergency call!
• Step (1-2)!
✓ The mobile sends the message to
BS as part of its RRC Connection
Setup Complete!
✓ The BS forwards the message to
MME
• Step (3)!
✓ The MME tells the BS to set
up a signaling connection for
the mobile in the usual way,
but also sets a CS fallback
indicator that requests a
handover to the CS domain!
• Step (4-5)!
✓ The BS activates Access
Stratum (AS) security and
tells the mobile to move into
ECM_CONNECTED state !
• Step (6-7)!
✓ The mobile’s response
triggers an acknowledgement
from BS to MME
• Step (8)!
✓ As part of step 5, the BS
also tells the mobile to
measure the signals that it
can receive from nearby
UMTS and GSM cells !
✓ The mobile makes the
measurements and
transmits a measurement
report!
• Step (9)!
✓ Using the measurement
report, the BS starts the
procedure for handover
from LTE to UMTS or
GSM
• Step (10)!
✓ Once the mobile is communicating
with the target radio access network,
it can contact the MSC server using a
Connection Management (CM)
Service Request that is written using
the CS domain’s mobility
management (MM) protocol!
• Step (11)!
✓ The mobile can then initiate the 2G/
3G procedure for establishing a CS
voice call !
• Step (12)!
✓ At the same time, the network can
complete the handover by
transferring the mobile’s EPS bearers
to the 2G/3G PS domain, so that the
user can continue any previous data
sessions!
✓ On completion of the call, the
network can hand the mobile back to
LTE
• If the network or mobile does not support PS handovers,
then CS fallback is implemented using a different procedure,
in which the BS releases the mobile’s S1 connection and tells
the mobile to carry out a cell reselection to 2G or 3G!
• As a result, the mobile’s PS services are suspended for the
duration of the call
• If a mobile terminated call arrives for
the mobile, then the incoming
signaling message arrives at the MSC
server!
✓ This notices that the mobile is
registered with an MME and sends
the MME an SGsAP paging request!
✓ The MME runs the paging
procedure and the mobile responds
with an extended service request as
before!
✓ The call setup procedure then
continues in a similar way
 • If a mobile terminated call arrives while
idle mode signaling reduction (ISR) is
active, then the MSC server sends an
SGsAP paging request to the MME in the
same manner as before!
✓ The MME contacts the SGSN, both
devices page the mobile and the
mobile responds in the usual way!
✓ There are no direct communications
between MSC server and SGSN, so
the MSC server remains unaware of
the use of ISR
Idle Mode Signaling Reduction (ISR)
* If the mobile is near the edge of the LTE coverage area, then it can easily bounce back and forth between cells that are using
LTE and cells that are using UMTS or GSM.
There is then a risk that the mobile will execute a large number of routing and tracking area updates, leading to excessive
signaling.
* ISR technique behaves very like the registration of a mobile in multiple tracking areas. When using ISR, the network can
simultaneously register the mobile in a routing area that is served by an S3-based SGSN and in one or more tracking areas that
are served by an MME. The mobile can then freely reselect between cells that are using the three radio access technologies and
only has to inform the network if it moves into a routing or tracking area in which it is not currently registered.
• CS fallback only requires a few enhancements to the system and is
likely to be the main interim [過渡時期] solution for the delivery of voice
over LTE!
• Several drawbacks!
✓ Firstly, the mobile can only use the technique if it is
simultaneously in the coverage area of LTE and a 2G or 3G cell!
✓ Secondly, the procedure involves delays of a few seconds while
the mobile makes its measurements and the network hands it over!
✓ Thirdly, inter-system handovers have traditionally been one of the
least reliable aspects of a mobile telecommunication system!
- If this unreliability is repeated in the case of LTE, then CS
fallback will result in many dropped calls!
• Overall, the resulting service degradation makes it doubtful whether
CS fallback is actually an acceptable solution
 4.4 SMS over SGs
• Similar ideas for the delivery of SMS messages!
• The mobile does not have to hand over to a 2G or 3G
network before sending or receiving a message!
• Instead, the network uses SMS over SGs technique to
deliver SMS messages by embedding them into signaling
messages between MME and MSC server

SGs
Figure 16.8 Architecture for SMS over SGs.
 • SMS over SGs technique!
✓ The mobile registers with the CS domain using the combined
EPS/IMSI attach procedure!
✓ It can then send an SMS message to MME, by embedding it
into an Uplink NAS transport message!
✓ The MME can then forward the SMS message to the MSC
server, by embedding it into an SGsAP Uplink Unitdata
message!
✓ From there, the SMS message is passed to the SMS
interworking MSC and the service center in the usual way

NAS：Non Access Stratum

 • If a mobile terminated SMS reaches the MSC server
while the mobile is in ECM-IDLE state!
✓ Then the MSC server alerts the MME using an
SGsAP Paging Request!
✓ This triggers the paging procedure and the mobile
replies by initiating a service request!
✓ MME can then retrieve the SMS message from the
MSC server and can deliver it to the mobile

ECM：EPS Connection Management

SGsAP：SGs Application Protocol
 4.5 Circuit Switched Fallback to
cdma2000 1xRTT
• The 3GPP specifications also support CS fallback
to cdma2000 1xRTT networks
Figure 16.9 Architecture for circuit switched
fallback to cdma2000 1xRTT.
• After attaching to LTE!
✓ The mobile preregisters with a cdma2000
1xRTT MSC, using 1xRTT signaling
messages that are transported across the
S102 interface!
• If the user wishes to place a voice call later on!
✓ The mobile sends an extended service
request to the MME!
✓ MME tells the BS to initiate a handover to
cdma2000 1xRTT!
• If an incoming call arrives for the mobile!
✓ The 1xRTT MSC sends the mobile a paging
message across the S102 interface!
✓ This triggers an extended service request
from the mobile and the call setup
procedure !
✓ The mobile can also send and receive SMS
messages, by tunneling them to and from
the 1xRTT MSC over S102
• 1. The Market for Voice and SMS!
• 2. Third Party Voice over IP!
• 3. The IP Multimedia Subsystem!
• 4. Circuit Switched Fallback!
• 5. VoLGA
 5. VoLGA
• Voice over LTE via generic access (VoLGA)!
✓ Another technique for delivering voice calls to LTE devices using the
existing capabilities of the 2G/3G CS domain!
✓ Through VoLGA, a mobile can reach the 2G/3G core network through a
generic access network such as a WLAN!
• VoLGA architecture connects P-GW to 2G/3G CS domain through a VoLGA
Access Network Controller (VANC)
• From the viewpoint of P-GW, VANC looks like any other server in the
outside world!
• From the viewpoint of CS domain, VANC looks like a generic radio
access network!
• As a result, LTE system can impersonate [模仿] the behavior of a generic
radio access network and can give the mobile access to the services of
the 2G/3G CS domain!
• VoLGA has found less support from the industry than the other
approaches, and appears unlikely to be widely adopted
Figure 16.10 VoLGA architecture.