IMS, Log, SiP


SIP Call Flow (Eg)

  1. SIP Message (Eg) INVITE


 Registration:- 


D/RILC ( 262): RIL onRequestComplete: Command channel closed 


D/RIL_ImsSms( 986): IMS is registered!

 MO SMS D/RIL_ImsSms( 986): sendText 

D/CDMA ( 986): sendSms: isIms()=true mRetryCount=0 mImsRetry=0 mMessageRef=0 SS=0 


D/RILC ( 262): dispatchImsSms 

D/RILC ( 262): dispatchImsCdmaSms: retry=0, messageRef=0 

D/RILC ( 262): RIL onRequestComplete: Command channel closed 

D/RILJ ( 986): [0266]< RIL_REQUEST_IMS_SEND_SMS { messageRef = 6, errorCode = -1, ackPdu = null} 


Will collect the Logs and update


 MO Call 

05-24 15:46:47.226 1108 1108 D IMSCallTracker: dialphone is Handler (com.qualcomm.ims.ImsPhone) {41ed15f8}call details 3 2 

05-24 15:46:47.856 1108 1108 D IMSCallTracker: [ dc ] number:22222 index: 1 incoming: false state: DIALINGcallDetails 3 2 

05-24 15:46:47.856 1108 1108 D IMSCallTracker: [ImsCallTracker] poll: conn[i=0]=null, dc=id=1,DIALING,toa=129,norm,mo,0,nonvoc,noevp,,cli=1,,0Call Details = 3 2 

 MT Call 


D/RILJ ( 986): [0275]> GET_CURRENT_CALLS 

D/RILJ ( 986): [0275]< GET_CURRENT_CALLS [id=1,INCOMING,toa=129,norm,mt,0,voc,noevp,,cli=1,,0] 

D/RILJ ( 986): [0277]> ANSWER D/RILJ ( 986): [0277]< ANSWER 

D/RILJ ( 986): [0278]> GET_CURRENT_CALLS 

D/RILJ ( 986): [0279]< GET_CURRENT_CALLS [id=1,ACTIVE,toa=129,norm,mt,0,voc,noevp,,cli=1,,0]



UE configuration for VOLTE 

 Set the NV items as per go/atel 

 ims/E2E_IMS_Setup/VoLTE_Device_Config/8960WTR_Lab_testing  adb shell setprop true 

 adb shell setprop 1 

 adb shell setprop 1 

 Add an IMS account by following the instructions below. 

 Click on phone icon and then press the menu button on the phone. 

 Select the setting menu and then scroll to the bottom of the screen to find the IMS Account menu. 

 Set the type of call (voice). 

 Set the check box "Use IMS Always" to tell Android to always place an IMS call  Hit save button or back button to save the settings.

MS servers with APT 

 Agilent IMS server 

 ICE 

 HCL 

 SER 

 Radvision


 RFC 3261 :

 VOLTE Doc 

 GSMA IR-92

'Japan > Work As Tester' 카테고리의 다른 글

자주쓰는 Secret code_Sony  (0) 2016.04.17
자주쓰는 Secret code_Samsung  (0) 2016.04.17
ims-volte-sip  (0) 2016.03.19
로그 보면서 파일로 저장하기  (0) 2016.03.18
로그, 속성 관련  (0) 2016.03.18
adb shell 명령어  (0) 2016.03.18

VoLTE를 이해해가 위한 용어정리

IMS:  IP Multimedia Subsystem

SIP: Session Initiation Protocol

SDP: Session Description Protocol

CSCF: Call Session Control Function

HSS: Home Subscriber Server

AS: Application Server

VoLTE: Voice Over LTE


I-CSCF: Interrogationg CSCF

S-CSCF: Serving CSCF

AKA: Authetication and Key Agreement

AM: Acknowledged Mode

TM: Transparent Mode

EMM: EPS Mobility Management

ESM: EPS Session Management

EPC: Evolved Packet Core

IMPU: IP Multimedia Public Identity

PCRF: Policy and Charging Rules Function

PRACK: Provisional(일시적인) Response ACK

RoHC: Robust Header Compression

URI: Uniform Resource Identifer

'Japan > Work As Tester' 카테고리의 다른 글

DUT  (0) 2016.03.09
IMS/SIP - Message List  (0) 2016.03.09
VoLTE용어정리  (0) 2016.03.09
자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09

SRVCC의 종류 

aSRVCC: Packet switched to Circuit Switched call transfer during Alerting Phase

bSRVCC: SRVCC before ringing

vSRVCC: SRVCC for video call

rSRVCC:r everse SRVCC HO from CS call to PS IMS

eSRVCC: enhanced SRVCC           

   Support of mid-call feature during SRVCC handover (eSRVCC)

   Support of SRVCC PS-CS transfer of a call in alerting phase (aSRVCC)



  →Protocol Sequence Example 도 있음!

  →SRVCC,eSRVCC관련 강의

'Japan > Work As Tester' 카테고리의 다른 글

VoLTE용어정리  (0) 2016.03.09
자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09
[설정]ADB 코멘드 사용 설정  (0) 2016.03.05
EVS란  (2) 2016.02.26

SRVCC(Single Radio Voice Call Continuity), 

즉 단일무선음성통화연속 기술은,

LTE의 패킷 스위치 도메인(PS)에서 

2G와 3G에서 운영되는 회로 스위치 방식(CS) 음성 네트워크로 이동하는 경우,

통화 세션을 유지시켜 주는 기술이다. 

상세 내용은 하기 참조! 


SRVCC - Single Radio Voice call Continuity is a level of functionality that is required within VoLTE systems to enable the packet domain calls on LTE to be handed over to legacy circuit switched voice systems like GSM, UMTS and CDMA 1x in a seamless manner.

As LTE systems deploy VoLTE coverage will be limited and it is anticipated that it will be many years before complete LTE coverage will be available.

As a result it is necessary for operators to have a system whereby this complicated handover can be accommodated in a seamless fashion. This scheme needs to be in place as soon as they start to deploy VoLTE.

What is SRVCC?

SRVCC, Single radio Voice Call Continuity, is a scheme that enables Inter Radio Access Technology, Inter RAT handover as well as a handover from packet data to circuit switched data voice calls.

By using SRVCC operators are able to make the handovers while maintaining existing quality of service, QoS and also ensuring that call continuity meets the critical requirements for emergency calls.

Some ideas for handover require that the handset has two active radios to facilitate handover. This is not ideal because it requires additional circuitry to enable the two radios to be active simultaneously and it also adds considerably to battery drain.

The SRVCC requires only a single active radio in the handset and requires some upgrades to the supporting network infrastructure.

SRVCC network architecture

The concept for SRVCC was originally included in the 3GPP specification Release 8. Since then it has evolved to take account of the various issues and changing requirements. As a result GSMA recommends that 3GPP Rel 10 or later is implemented as this ensures a considerably lower level of voice interruption and dropped calls.

The network upgrades required to the cellular network are needed in both the LTE network and that of the legacy network or networks. SRVCC requires that software upgrades are required to the MSS - Mobile SoftSwitch subsystem in the legacy MSC - Mobile Switching Centre, the IMS subsystem and the LTE/EPC subsystem. No upgrades are required for the radio access network of the legacy system, meaning that the majority of the legacy system remains unaffected.

The upgrades required for the MSC are normally relatively easy to manage. The MSC is normally centrally located and not dispersed around the network, and this makes upgrades easier to manage. If they are not easily accessible then a new dedicated MSC can be used that has been upgraded to handles the SRVCC requirements.

How SRVCC works

The SRVCC implementation controls the transfer of calls in both directions.

LTE to legacy network handover
Handover from LTE to the legacy network is required when the user moves out of the LTE coverage area. Using SRVCC, the handover is undertaken in two stages.

  • Radio Access Technology transfer:   The handover for the radio access network and this is a well-established protocol that is in use for transfers from 3G to 2G for example.
  • Session transfer:   The session transfer is the new element that is required for SRVCC. It is required to move the access control and voice media anchoring from the Evolved Packet Core, EPC of the packet switched LTE network to the legacy circuit switched network.

During the handover process the CSCF(Call Session Control Function) within the IMS architecture maintains the control of the whole operation.

Diagram showing how SRVCC operates in VoLTE handovers
Voice handover using SRVCC on LTE

The SRVCC handover process takes place in a number of steps:

  1. The handover process is initiated by a request for session transfer from the IMS CSCF.
  2. The IMS CSCF responds simultaneously with two commands, one to the LTE network, and the other to the legacy network.
  3. the LTE network receives a radio Access Network handover execution command through the MME and LTE RAN. This instructs the user device to prepare to move to a circuit switched network for the voice call.
  4. The destination legacy circuit switched network receives a session transfer response preparing it to accept the call from the LTE network.
  5. After all the commands have been executed and acknowledged the call is switched to the legacy network with the IMS CSCF still in control of the call.

Legacy network to LTE

When returning a call to the LTE network much of the same functionality is again used.

To ensure the VoLTE device is able to return to the LTE RAN from the legacy RAN, there are two options the legacy RAN can implement to provide a swift and effective return:

  • Allow LTE information to be broadcast on the legacy RAN so the LTE device is able to perform the cell reselection more easily.
  • Simultaneously release the connection to the user device and redirect it to the LTE RAN.

SRVCC interruption performance

One of the key issues with VoLTE and SRVCC is the interruption time when handing over from an LTE RAN to a legacy RAN.

The key methodology behind reducing he time is to simultaneous perform the redirections of RAN and session. In this way the user experience is maintained and the actual interruption time is not unduly noticeable.

It has been found that the session redirection is the faster of the two handovers, and therefore it is necessary for the overall handover methodology to accommodate the fact that there are difference between the two.


'Japan > Work As Tester' 카테고리의 다른 글

자주 등장하는 프로토콜 정리  (0) 2016.03.09
SRVCC의 종류  (0) 2016.03.09
SRVCC  (0) 2016.03.09
[설정]ADB 코멘드 사용 설정  (0) 2016.03.05
EVS란  (2) 2016.02.26
3GPP_Network 참고 사이트  (0) 2016.02.26

+ Recent posts