2016 International Conference on Selected Topics in Mobile & Wireless Networking (MoWNeT)
VOLTE Deployment Scenarios: Perspectives and
Performance Assessments
M. ELWakiel
Faculty of Engineering, Ain Shams University
Cairo, Egypt
7410@eng.asu.edu.eg
H. EL Hennawy
Faculty of Engineering, Ain Shams University
Cairo, Egypt
hadia.elhenawy@eng.asu.edu.eg
Abstract— The LTE “Long Term Evolution” technology was
introduced to reduces the DATA network latency, in addition to
provide higher data throughput. But the nature of LTE prohibits
the transmission of voice related services. VoLTE “Voice over
LTE” is a solution to transfer voice packets with special
treatment over the LTE network, and get benefits from its low
latency and quality of services capabilities to have voice services
jointly provided by the EPC “Evolved LTE packet core” and the
IMS “IP Multimedia Subsystem”. As VoLTE is a new technology
for both network and devices providers, it has some limitations in
providing all voice related services over LTE. Network initiated
and user initiated USSD “Unstructured Supplementary Service
Data” are not supported directly over VoLTE. CSFB “Circuit
Switched Fall Back” is a temporary solution used to instruct the
VoLTE device to fall back to CS “Circuit Switching” network to
receive such USSD, then returning back again to VoLTE after
completing the reception of the USSD. If the VoLTE network
tried to push a USSD notification to a VoLTE subscriber who is
engaged in one or more voice calls “conference call”, the
commercial network settings will make that subscriber to release
all the LTE bearers to fall back to the CS network which causes
the drop of all active calls owned by that VoLTE user, which
affects negatively on one of the most important VoLTE QoS
“Quality of service” parameters which is service availability.
A novel solution will be introduced to overcome such limitations
and prevents any active voice call from being dropped when
receiving a USSD from the VoLTE network. This will be
achieved by using SRVCC “Single Radio Voice Call Continuity”
instead of CSFB when receiving USSD while being engaged in a
voice call.
To verify such novel method, a real pilot VoLTE network is used
to get practical traces and measurements to validate that novel
solution to achieve such important QoS parameter. The
performance of that solution is evaluated by measuring the call
drop rate improvements achieved by that novel technique.
Keywords— VoLTE; QoS; QoE; IP USSD; CSFB; SRVCC;
I. NTRODUCTION
With the fast deployment of LTE networks and the high
penetration rate of smart phones, the mobile networks operators
are facing the challenge of continuous huge increase of data
throughput generated by their LTE subscribers. Another
challenge faced by mobile operators is the pure IP based
structure of the LTE network which couldn’t support
transferring of the traditional voice services. The expected
increase of data services revenue shares, compared to the voice
services forecasted trend is showing that the traditional voice
services will have slight degradation in the revenue shares, but it
will not be killed completely, as it will be kept as the main
demand for many mobile subscribers.
978-1-5090-1743-0/16/$31.00 ©2016 IEEE
H. El Badawy
National Telecommunication Institute
Cairo, Egypt
heshamelbadawy@ieee.org
However the VoLTE technology still has some limitations in
providing all voice related services directly over LTE whether
due to network nodes or VoLTE devices capabilities. For
example, supplementary services activation and deactivation is
not supported over VoLTE, also USSD services are not
supported directly over VoLTE, in addition to emergency calls
over IMS. To speed up the deployment of VoLTE networks the
previously mentioned services were temporary achieved by
using CSFB “circuit switched fall back” technique when sending
or receiving USSD, or activating/deactivating different
supplementary services like “call waiting, or call forwarding
conditions”. All commercial VoLTE networks are concentrating
on testing the supplementary service management using a new
approach which is considered as the only way to manage
supplementary services directly over VoLTE without falling
back to CS [2]. That new approach is based on deployment of a
new interface named Ut interface.
Up to date there are no user terminals support the reception of
USSD directly over VoLTE, and the same for VoLTE core
nodes as well. Current work is introducing a novel method to
enable the VoLTE subscriber to receive any USSD from
network while being engaged in any active voice calls without
dropping these calls. This will be achieved by using SRVCC
when receiving USSD instead of using CSFB. The basic
principle of that novel method depends on triggering the SRVCC
procedure only if the network detects that the VoLTE subscriber
is receiving a USSD while being engaged in another voice
service has a dedicated bearer with a QCI “quality of service
indicator” equals 1, while using normal CSFB procedure if it is
in idle state. Further, the effectiveness of such novel method is
evaluated by capturing real traces of live VoLTE calls traffic
which were analyzed to calculate the VoLTE call drop rate due
to receive a USSD notification while being engaged in another
VoLTE call, and compared that call drop rate when using the
existing CSFB mechanism to show the enhancements achieved
using such novel mechanism compared to existing technique.
The rest of this paper is organized as follows: Section II briefly
describes implementation steps for USSD over VoLTE. Section
III describes the limitations of USSD services over IMS and
solutions for it. Disadvantages of using such solutions and
another new solution were highlighted on section IV. The pilot
network structure and parameters were discussed on section V.
Section VI explained the testing scenarios and signaling
analysis. Section VII provides evaluation for the testing results,
discussions about testing results were highlighted in section VIII
and finally, this work was concluded in Section IX.
 II. IMPLEMENTATION OF USSD OVER VOLTE
The USSD “unstructured supplementary service data” using
VoLTE service enables subscribers to initiate specified service
requests to network and enables the network operators to provide
new value-added services, such as those providing information
related to stocks, lottery, weather forecast, and airline schedules.
USSD service can be used to buy lottery tickets, pay for utilities
such as electricity and water, book tickets, buy and sell stocks,
and deal with foreign-exchange transactions; also USSD is used
to inform subscribers about their voice services charges and
available balance. To implement USSD over VoLTE, according
to the latest 3GPP standard [3], there are three steps required;
these steps are shown on below Fig. 4
Fig. 4. USSD over VoLTE networking & requirements based on [3]
1) First of all, there will be a new application server
required to process the USSD services over IMS, which
is called USSD over IMS Application server “USSI-
AS”.
2) It is required to integrate the USSI-AS to the HSS via
MAP interface, and then the HSS need to transfer the
USSD using IMS request to the USSD center.
3) Also the VoLTE device should be capable to support
origination and reception of USSD over IMS.
III. LIMITATIONS FOR “USSD OVER VOLTE” DEPLOYEMENT
The latest 3GPP standard documents related to USSD over
VoLTE [3] assumed that the whole VoLTE subscribers are
always served by IMS domain and assumed that there is a
VoLTE device supports the MO/MT USSD over IMS, and the
network nodes supports these scenarios as well. Even if there are
plans to implement originating USSD over IMS, which require
some network nodes to be upgraded and customized “as
mentioned in section II” still the reception of USSD over IMS is
not planned yet for the existing commercial VoLTE networks “as
per our knowledge”. Due to these reasons and for fast VoLTE
deployment, these limitations could be overcome by changing the
flow of originating or terminating USSD to use CSFB procedures
instead of performing them directly over VoLTE network,
meaning that originating or receiving USSD will make the
VoLTE device to fall back from LTE / IMS domain to the
traditional CS domain while handling that USSD service, and
then register again to the IMS domain after performing such
service. This technique already implemented by all VoLTE
devices vendors and the VoLTE network equipment providers.
IV. DISADVANTAGES OF PROVIDING “USSD USING CSFB” AND
PROPOSED SOLUTION
VoLTE network providers are facing a big challenge affecting
their network QoS levels, as their VoLTE subscribers will suffer
from many dropped calls when receiving any USSD notifications
while being on another active calls, as the devices will release the
dedicated LTE resources and fall back automatically to CS
domain to receive that USSD, after that they will attach to LTE
network again, and then register on IMS domain again after
USSD reception done. This will affect badly on customers QoE
“Quality of Experience” and keeping them unreachable for long
times during these transitions from access domain to another. So,
there should be a way to prevent these VoLTE subscribers who
are engaged in voice calls from using CSFB when receiving
USSD notifications from network side.
SRVCC is one of the key factors to provide a high level of QoS
for VoLTE subscribers by guaranteeing the continuity of the
active VoLTE call and handover the VoLTE call from LTE to the
CS domain if there is degradation happened on the LTE
coverage. Fig. 6 shows the high level description of SRVCC
procedure .In that procedure and based on measuring reports
processed by the eNodeB, the eNodeB initiates the SRVCC
procedure by sending handover request to MME, and the MME
initiate a request to the MSC server in CS network to prepare for
voice service and reserve resources for the call transfer from LTE
domain to 3G “CS” domain without dropping that call [7].
Fig. 6. High level concepts for SRVCC from LTE to UTRAN/GERAN [7]
From the flow mechanism of CSFB and SRVCC procedures, it
could be found that the eNodeB starts the CSFB procedure based
on instructions from the MME; also the eNodeB starts the
SRVCC procedure based on coverage measurement reports from
the VoLTE device. So, the eNodeB is the triggering network
entity whether for CSFB or SRVCC. Also form the basic QoS
settings for VoLTE networks that the dedicated bearer created for
the VoLTE voice call has the highest priority with QCI=1 [8],
And that QCI value is reported from PCRF to P-GW and eNodeB
to assign the proper resources with GBR “guaranteed bit rate”
Meaning that, the eNodeB also knows whether the VoLTE
subscriber is performing a voice call or other service from the
QCI value. The previous descriptions are leading to the below
novel logic:-
1) If the eNodeB received instructions from the MME to
start CSFB procedure for a specific VoLTE subscriber
“which is triggered to receive a USSD”.
 2) And eNodeB found that VoLTE subscriber is engaged
in a service with QCI value equals 1 “Voice call”.
Then the eNodeB starts the SRVCC procedure. If the previous
two conditions are not met, the eNodeB will continue performing
the CSFB procedure. Fig. 7 shows the flow of that algorithm.
The flow starts when the eNodeB receives instruction from MME
to perform CSFB.
The Blue colored signaling flow indicating the SRVCC flow
when the VoLTE subscriber is engaged in a voice call with
QCI=1, while the black colored signaling flow is the normal
CSFB flow.
Fig. 7. Algorithm for receiving USSD during active call
A. When receiving the CSFB request from the MME , the
eNodeB checks the VoLTE subscriber status if engaged
in a QCI=1 voice service , then the eNodeB starts the
eSRVCC with the UE by sending “RRC connection
Reconfiguration” message , then the UE confirm it and
sends the neighbors 3G cells measurement report to
eNodeB .
B. The eNodeB sends “HAND OVER REQUIRED”
message to MME , and MME knows the MSC location
which reported during the combined attached request
performed by the UE in the attach procedure over SGs
interface
It is important to highlight that the MME should send the
SRVCC request message to the same MSC ID reported during
the combined location update done during the initial attach to the
LTE network, that condition is required to guarantee the
successful delivery of the MT USSD, if the MME sends the
“SRVCC PS to CS request” to different MSC, then the USSD
delivery will be failed, so the MME should use that specific MSC
reported via SGs interface. After the SRVCC performed
successfully the subscriber will receive the USSD on CS domain
while being on a call which is handed over to the 3G network.
If these previously mentioned two conditions are not met and
subscriber in idle stat and network is pushing any USSD to it, so
the eNodeB will start CSFB flow by sending “RRC connection
Release” message to UE to start releasing the traffic bearers and
moves the UE directly to CS network.
V. PILOT NETWORK ENVIRONMENT STRUCTURE AND PARAMTERS
Testing of the MT USSD using eSRVCC procedure was
conducted on an actual VoLTE system with a system model
consisting of the following components:-
1. VoLTE enabled User Equipment (UE) “Beta
Terminals with VoLTE software”
2. An LTE eNodeB.
3. MME “Mobility Management Entity” integrated with
CS network’s MSC supporting SGs interface for
CSFB and Sv interface for SRVCC.
4. S-GW “Serving Gateway”.
5. P-GW “Packet Data Network Gateway”.
6. PCRF “Policy and Charging Rules Function”.
7. IMS nodes “P-CSCF, S-CSCF,I-CSCF,SCC-AS,TAS.
8. Mirroring optical splitting probes to collect all
important node traces.
9. LAN Switches to collect all tabbed interfaces mirror
messages.
10. Probe server to collect and process the traffic mirrors
11. PC server to collect the VoLTE and CS real traces.
The tap or optical splitter copies data from the SGs and Sv,
S1-MME, S1-U, Gx, and S6a interfaces, and reports the collected
data to the probe server. The collected data includes S1-MME
interface control-plane data, S1-u user plan data, S1AP signaling
S6a interface control-plane data, and Diameter signaling in binary
format. These binary data are generated based on a trace
loopback task created on a PC client integrated to the probe
servers using any of the common user identities such as MSISDN
or IMSI. The traced messages are saved in a real time trace log
files in a compressed format during the trace sessions, these trace
sessions are configured, controlled and displayed in a readable
format by using a “Trace Viewer” [14] software package, which
can start, stop or filter traced messages via a flexible graphic user
interface and also can convert trace messages into text format.
The traced messages is created as TMF “Traced Message
Format” files which is a structured text file that contains
instructions for parsing and formatting the binary trace.
Fig. 8 shows the pilot VoLTE network structure used for testing
real USSD traffic scenario. The pilot network is configured in the
following manner: - the eNodeB, S-GW “Serving Gateway”,
P-GW “Packet Data Network Gateway”, MEE “Mobility
Management Entity” and PCRF “Policy and Charging Rules
Function” which represents the LTE domain, e-MSC represents
the 3G CS domain, which enhanced to act as “SRVCC-IWF”
when SRVCC required. These two domains were connected to
IMS domain via Edge routers of IPBB cloud. Each eNodeB is
integrated to the Evolved Packet Core (EPC) with Giga links of
1Gbps bandwidth. With 15 MHz BW, the eNodeB throughput is
90 Mbps for good coverage conditions, while it is 30Mbpbs for
poor coverage conditions. The signaling and traffic paths between
the EPC “Evolved Packet Core” and eNodeBs were separated
using different Virtual Local Area Network (VLAN) subnets. The
IMS domain is divided into several zones for network security,
the access zone which includes the P-CSCF is isolated in a
separate VLAN subnet to allow the access of the VoLTE devices
to the IMS network, while the services processing IMS servers
“I-CSCF, S-CSCF and ATS” are assigned to another VLAN
subnet.

Fig. 8. Pilot VoLTE Network testing environment
Signaling and user plan interfaces are taped with mirroring
probes to collect all traffic messages to a lane switch which
collects these traffic flows and sends them to a probe server for
processing and formatting to be easy for user interface collection
via a separate PC client to collect these traces in a ’TMF’ format.
The Signaling between EPC and eNodeB is carried through GTP
“GPRS Tunneling Protocol”. GTP tunneling is located at both
nodes (EPC, eNodeB) and it is dynamically established between
them to carry the EPS required bearers. In the eNodeB there is
threshold value called “In Active set “which saves the eNodeB
radio resources, if there is no activity within that period the bearer
is released until next action.
For QoS guarantee, the PCRF configured to provide full GBR
“guaranteed bit Rate” bandwidth requirements provided form the
P-CSCF via the Rx interface for the VoLTE voice calls dedicated
bearer with QCI=1 , to be delivered to the P-GW via the Gx
interface . For VoLTE signaling default bearer, the HSS is
configured to provide uplink and downlink bandwidths of 1024
kbps for the “ims” APN-AMBR “Access Point Name -Aggregate
Maximum Bit Rate”, all these bandwidths should be guaranteed
while being transferred via the IPBB cloud.
On the IPBB cloud transport network, each service traffic type is
assigned a specific bandwidth based on priority settings on the
edge router to give the Signal/Voice services PQ “Priority
Queue” scheduling strategy, so bandwidth is absolutely
guaranteed for voice services. Bandwidth shaping value for each
service is estimated based on existing network usage. WFQ
“Weighted fair scheduling” with weight 1/5 factor will be
assigned of remaining data services which will utilize the rest
free bandwidth of PQ queue. So there is no affect base on WFQ
small weight value. Other pilot network testing environments
settings are shown below on table I:-
TABLE I. TESTING PARAMETERS
Parameter Value
Duplex Scheme FDD
LTE System Bandwidth 15 MHz
LTE Coverage threshold to start SRVCC ” -108 dBm
Target 3G cell threshold to accept SRVCC • -99 dBm
WB-AMR VoLTE CODECs 23.85Kbps
Frame Size 20 ms
eNodeB In Active User Set “threshold” 10 sec
BHSA/Sub “Busy Hour Session Attempt/ subscriber” 1.3
VoLTE session MHT “Mean Holding Time” 60 seconds
VI. TESTING SCENARIOS AND SIGNALING ANALYSIS
In the pilot Testing network, one of the eNodeBs “eNodeB 1”will
enable the new mechanism for receiving USSD using SRVCC,
while remaining eNodeBs will keep using the normal CSFB
mechanism when receiving USSD, a neighbor congested
“eNodeB 2” is selected to compare its behavior with the
performance of “eNodeB 1 “ . All traffic scenarios were enabled
for 5000 VoLTE users registered to the whole VoLTE network
and distributed randomly on different eNodeBs, the average
number of LTE subscribers served by eNodeB1 and eNodeB 2 is
103 subscribers, while it is 170 LTE subscribers on the busy
hours. To be sure from the occurring of USSD notifications from
network side, random conference calls were established by a
testing prepaid numbers with 3 parties, or configure a call
forward while busy for a prepaid subscriber “A” to another user
“B”, and then a USSD will be sent to user “A” after the
forwarded call ended. Testing is performed at BH “Busy Hour”.
Traces of random traffic and for the previously mentioned
specific scenarios under these two eNodeBs were collected and
analyzed. As performance metrics, the call drop rates in case of
CSFB requested under eNodeB 2 coverage, and call drop rate in
case of SRVCC required due to receiving a USSD while being
served by eNodeB 1 is calculated. A conference call scenario was
selected to be analyzed when performed under the coverage of
eNodeB 1 ”where the SRVCC mechanism was enabled” , and
the same scenario was analyzed when performed under the
coverage of other eNodeB 2.The test started with a prepaid
VoLTE subscriber ”UE-1” on a conference call, with 2
participants “UE-2 and UE-3”, then “UE-3” left the conference ,
so the “UE-1” should receive a USSD from network charging
node to inform him about the call charges with UE-3. That testing
scenario will be performed using the default method using the
CSFB procedures, and then it will be performed again using the
novel method of receiving USSD initiated by the VoLTE
network using the SRVCC procedures. A real VoLTE network,
and traditional CS network traces will be used for analyzing and
highlighting the difference between the two scenarios.
1) UE-1 is receiving the USSD using CSFB procedures:-
Fig. 9. MSC trace for NI-USSD using CSFB
Fig. 9 shows the real MSC traces for CS domain in “TMF”
format for network initiated USSD”NI-USSD” informing the
UE-1 about cost of the call to UE-3 who left the conference. The
charging system in the VoLTE network will trigger the initiation
of sending end of call notification USSD to the VoLTE
subscriber “UE-1” via the HSS.
On step 3: HSS will send the USSD notification “MAP
Unstructured SS notify indicator” message to MSC ID
“registered in HSS during initial combined LUP”. Fig. 11. Extended Service Request Message contents

On step 4: MSC sends a CS Paging request message to MME via

SGs interface informing UE-1 about receiving such USSD
service, at 02:27:49.
Fig. 10 is showing the same call related trace on the VoLTE
network domain.
In Fig. 10, step 1: the same paging message sent from the MSC
Fig. 12. Request from MME to eNodeB for CSFB
via the SGs interface will be sent to the MME at 2:27:49 as a
“SGsAP-PAGING-REQUEST” message.

Fig. 13. The eNodeB started the CSFB

Fig. 10. VoLTE nodes trace for NI-USSD using CSFB
Step 4: The UE sends an Extended Service Request message to
the MME, and the value of the IE CSFB response indicates that
the UE accepts the CSFB request “CS fall back accepted by
UE(1)”, as shown in Fig. 11.
Step 5: The MME sends an S1-AP “UE Context Modification
Request “message containing the IE CS Fallback Indicator to the
eNodeB2 , informing the eNodeB 2 that the UE needs to fall
back to the UMTS or GSM network because of CS services as
per Fig. 12.
Step 6: The eNodeB 2 confirmed reception of the MME request.
Step 7: The eNodeB 2 informed the MME that the CSFB
triggering started as shown in Fig.13.
Step 10: The MME will command the eNodeB 2 to release the
bearers of the UE-1 and instruct it to fall back to CS domain at
02:27:49, at that time the “UE-1” left the LTE domain and fall
back to CS domain, also all the conference calls were dropped
due to releasing all the VoLTE dedicated bearers.
Returning back to the CS domain traces in Fig. 9: -
Starting form step 6, the “UE-1”, replied with the paging
response and latched to CS domain then received the USSD
notification starting form step 15.
Step 18: after receiving the USSD notification, the CS domain
informing “UE-1” to return back to LTE domain.
Step 20: “UE-1” is sending a location update request to the
MME via the SGs interface at 02:27:58, which is received
by the MME in LTE domain as shown in step 13 in Fig. 10.
After that the returning back to LTE is completed by the
tracking area serving “UE-1” is updated.
After latching to LTE domain, the UE-1 will start
registration on the IMS domain again by sending “Register”
message and passing the challenging processes until final
registration as shown in Fig. 14. But this will be done after
dropping all the voice calls owned by UE-1.
 Fig. 14. VoLTE device Registration to IMS domain

2) Receiving the USSD using SRVCC procedures:-

The traces of the novel method using the SRVCC procedures

will be analyzed starting from the point of initiating the USSD
from network side. Fig. 15 shows the CS domain trace where the
USSD request is received from the charging node via the HSS.

Referring to the existing mechanism of receiving USSD using

CSFB in Fig. 9, it can be noticed that in step 4 the Paging
Request is sent to the LTE domain, then the device fall back to
CS domain and sent Paging Response message as per step 6 in
Fig. 9.
Fig. 15. MSC trace for NI-USSD using SRVCC
In Fig.15, it can be seen that after sending the paging request to
the LTE domain as per step 2, the MSC is receiving a request for
SRVCC from the MME in the LTE domain via the message
“SRVCC_PS_TO_CS_REQ” instead of receiving the paging
response as per normal CSFB flow.

Then the SRVCC flow will start from step 4 to step 18 , where
the MSC will prepare for the resources to receive the handed
over calls, then sends INVITE message to the IMS domain to
negotiate the CODEC which will be used among the call
participants after the handover. Then the MSC “which is
working as SRVCC-IWF node” confirms back to MME the
success of SRVCC. More details about SRVCC signaling flow
could be found in [7].

Fig. 16 shows the VoLTE core nodes traces for receiving the
network initiated USSD using the SRVCC in LTE domain.

In Fig. 16, starting from step 1 to step 6 are the same steps
showed in Fig. 11 for the CSFB case, the critical point here is
the step number 7 where the eNodeB starts the handover process
instead of releasing the LTE resources and performing the CSFB
as done in step 7 of Fig. 10.

After successful handover from VoLTE to CS, the calls which Fig. 16. VoLTE nodes trace for NI-USSD using SRVCC
were active before handover will not be dropped, and the UE-1
latch to CS domain to receive the USSD as per step 32 in Fig. VII. TESTING RESULTS ANALYSIS
15.
A VoLTE call drop occurs when the VoLTE E-RAB is
abnormally released. Each E-RAB is associated with QoS
information. As per standard, the QCI of VoLTE voice
services equals to 1 [8]. An E-RAB consists of a radio
bearer between the VoLTE device and the eNodeB and a
corresponding S1 bearer from eNodeB to VoLTE EPC
core. Any abnormal release of any of these two bearers
causes a call drop. Abnormal E-RAB releases can be
 counted when the eNodeB sends a “UE Context Release
Request” message to the MME as per step 7 in Fig. 10, the
abnormal E-RAB release counter is incremented if the
bearer to be released and the release cause is not "Normal
Release”. When using CSFB, all the E-RAB release will
not be Normal release, but the cause value for the abnormal
release will be “cs-fallback-Triggered (23)” as per Fig. 13.
And that will happen for all VoLTE users receiving a
USSD notification while being on active calls and served
by eNodeB not implementing the SRVCC while receiving
that USSD. In that case we can consider the VoLTE call
drop rate in case of using CSFB = 100%, as the calculation
formula for call drop rate due to performing CSFB will be
as in (1).
Call Drop Rate =
Fig. 18. Handover Request reason in case of receiving USSD using SRVCC
Release Requests for ൌͳbearers with ̶CSFB triggered̶ cause
X 100
Release Response with cause̶ ”‹‰‰‡”‡†̶…ƒ—•‡
Fig. 17 shows the call drop rate under “eNodeB 2” during the
busy hour, where the traditional way of using CSFB to receive
USSD is deployed. According to (1), any usage of CSFB to
receive a USSD will result in dropping all active VoLTE calls as
this is the standard nature of CSFB to release all dedicated
bearers before falling back to CS domain [4].
Fig. 17. Call drop rate due to receiving USSD using CSFB
The situation in the new method using the SRVCC is different
than the existing behavior, as there will be NO Bearer release
request sent by eNodeB to the MME , but the eNodeB’ s new
algorithm will initiate the SRVCC “event handover “ process to
CS when finding a CSFB request is coming for a user has a
bearer with QCI=1 value , in that case the eNodeB will send a
“HANDOVER_REQUIRED” message to the MME as per step 7
in Fig. 16, and the handover cause value in that case will be “cs-
fallback-Triggered (23)” as per Fig. 18, which is different than
the handover cause in the normal SRVCC flow due to LTE
coverage issues.
(1)
By counting the “Handover required” messages with cause value
= 23 “ cs-fallback-Triggered” , which indicating that the network
is performing SRVCC for a user in active call , and that SRVCC
to enable that user to receive USSD, that number of SRVCC
requests for receiving USSD is considered as a request for
receiving a USSD , if that request associated with a “UE
CONTEXT RELEASE COMMAND” message sent from the
MME , at that time the caller is considered succeeded to be
handed over to CS domain and received the USSD successfully
as per step 16 in Fig.16, otherwise the call will be considered as
a dropped call as in that case the MME will cancel the handover
process and will not send to the eNodeB asking for releasing the
bearers .The calculation formula for the call drop rate in case of
using the new event SRVCC mechanism will be as in (2).
Call Drop Rate =
Hand Over Requests with "CSFB Triggered"
1- X 100 (2)
Number of Context Release command
According to (2), Fig. 19 shows the call drop rate under
“eNodeB 1” coverage during busy hour.
Fig. 19. Call drop rate due to receiving USSD using SRVCC
 VIII. DISCUSSION [6] T. Koshimizu, I. Tanaka, and K.Nishida, “ Improvement on the VoLTE
Differently from previously published works as [10], [11], (Voice over LTE) Domain Handover with operator’s vision” ,2012
[12] and [13]. The current paper focused on the practical [7] 3GPP TS 23.216, “Single Radio Voice Call Continuity (SRVCC)”
testing and real time monitoring for the newly proposed Stage 2 ; V13.1.0 (Release 13), December 2015.
algorithm. The presented results showed an improvement [8] 3GPP TS 23.203, “Policy and charging control architecture” V13.6.0,
for the call drop rate as in Fig. (19). (Release 13), December 2015.
The testing results showed the comparison of call drop rate [9] 3GPP TR 23.856, Single Radio Voice Call Continuity
happened when using both the novel SRVCC mechanism (SRVCC) enhancement; Stage2” V10.0.0. Release 10, Sep. 2010.
and the existing CSFB mechanism to receive USSD while [10] K. Andersson, S.Al Mahmud Mostafa, and R. UI-Islam
being on a call. These results clearly showed and verified “Mobile VoIP User Experience in LTE”,2011
the improvement happened to the call drop rate for VoLTE [11] R.Sanyal Challenges in Interoperability and Roaming between LTE -
users, who were triggered to receive a USSD notification Legacy core for Mobility Management, Routing, Real Time Charging
from the VoLTE network while being in active call and [12] Md. Showket Hossen “QoS Performance Evaluation of Video Conferencing
served by the eNodeB which deployed the novel SRVCC over LTE”, Master Thesis submitted to the School of Computing at
mechanism which is 10%, compared to the call drop rate Blekinge Institute of Technology.March 2012.
happened due to using the CSFB mechanism to receive such [13]Y.Ouyang; T.YanandG.Wang,” CrowdMi: Scalable and Diagnosable Mobile
USSD which was 100% under another eNodeB coverage Voice Quality Assessment Through Wireless Analytics”, Internet of things
IEEE Magn., , Vol. 2, pp. 287 – 294, 2015
deployed CSFB to receive USSD. It could be noticed also
that when there will be more VoLTE subscribers on current [14] Huawei tech.”eLTE2.3 eCNS600 Feature Description, tracing function “
commercial LTE networks , the probability of receiving
notifications from network while being on a call will
increase, and the call drop rate will be high due to the
increase in the number of hits to trigger CSFB . So the new
mechanism of using SRVCC will be clearly useful when the
number of VoLTE subscribers base increases due to the
rapid penetration of VoLTE services. Also these 10 % of the
call drop rate could be related to Handback due 3G coverage
conditions or any other normal reason happened causing the
handover process failure, which is being accepted as there
are no 100% wireless coverage conditions.
IX. CONCLUSION
As a new technology, VoLTE has a big challenge to provide
high QoS level to the VoLTE subscribers; at the same time
for fast VoLTE deployment, CSFB procedure is used to
achieve traditional tele services by falling back to CS
network, then returning back to IMS after performing such
services, up to date the only way to receive or originate a
USSD is the CSFB procedure. Performing CSFB to receive
USSD while being on another call will result in dropping
that call, which is affecting VoLTE network QoS and
VoLTE subscriber QoE. A new solution was proposed to
trigger SRVCC by the eNodeB when receiving USSD under
specific conditions instead of using normal CSFB. This
novel solution is verified using a real VoLTE pilot network.
And the real statistics for call drop rate using the new
method showed very high performance by reducing the call
drop rate form 100% due to using CSFB mechanism to be
around 10% when using SRVCC for receiving USSD.

ACKNOWLEDGMENT
This work done with the support of HUAWEI Technologies

REFERENCES
[1] Ovum webinar, “Monetizing and charging VoLTE to achieve
Service Profitability”, June, 2015.
[2] GSMA PRD IR.92 V9.0 "IMS Profile for Voice and SMS",
April. 2015.
[3] 3GPP TS 24.390, “Unstructured Supplementary Service Data
(USSD) using IP Multimedia (IM) Core Network (CN) subsystem.
[4] 3GPP TS 23.272, “Circuit Switched (CS) fallback in Evolved
Packet System (EPS) Stage 2'; version 13.2.0 Release 13; December
2015.
[5] M. Chewe, “VoLTE by IP Multimedia Subsystem: Programmatic
Implementing of Voice Service on LTE” , Helsinki Metropolia University of
Applied Sciences, 2015.