Bob joined Award Solutions in 2004, bringing his expertise in GSM and satellite technologies; and wireless and wireline network planning. He specializes in telecommunications systems, focusing in GSM, GPRS, and UMTS systems, wireless and Internet applications, and the convergence of communication technologies. Currently, he is working on UMTS, IP Multimedia Subsystem, IP telephony, and WiMAX Network Planning. He has over 16 years of experience in the wireless telecom industry.
Bob moved into the wireless telecommunication industry after the completion of his Ph.D. in Operations Research. He spent the first 7 years of his telecommunications carrier in the Wireless Systems Engineering department at Nortel Networks. As a Member of Scientific Staff, Bob worked on network planning, customer support, bid support, and capacity planning for satellite systems and Personal Communications Systems. As a Senior Advisor, he directed a multi-corporate study commissioned by the European Space Agency to forecast multimedia traffic for a satellite carrier over an 18-year period.
After his time at Nortel, Bob has helped to establish two startup companies and has worked as a professor at the University of Phoenix prior to joining Award solutions. Currently, Bob holds the position of Senior Consultant with Award solutions.
Bob currently focuses on IP-based wireless access and core network courses. He has developed and taught extensively both custom and public courses in the areas of IP, MPLS and Carrier Ethernet (CE) Backhaul. Included in the MPLS courses are descriptions of the various alternatives for supporting IPv6 in an MPLS network. The CE courses describe CE transport alternatives and key technical issues (e.g. timing and synchronization) in the successful deployment of Carrier Ethernet backhaul. Included as well are the description of numerous standards, tools and techniques enabling the smooth and economic migration from today’s voice centric wireless access networks to tomorrow’s data centric access networks.
Generally Bob’s focus is on emerging trends in data networking. These trends involve the convergence of various legacy networking solutions into a single IP-based networking environment capable of concurrently managing various traffic types and QoS requirements.
Bob holds a Ph.D. in Operations Research from the University of Texas at Dallas, a Masters degree in Management and Administrative Sciences from the University of Texas at Dallas, a Masters degree in Mathematics from Drexel University and a Bachelor’s degree in Mathematics from Bethany Nazarene College. Bob also holds 9 patents in the area of wireless and optical technology.
“Voice over Long Term Evolution” (VoLTE) is emerging as the preferred solution for the need to support real time voice traffic in the new world of all IP networks. LTE is designed to support massive volumes of traffic. Voice traffic is very low bandwidth. So why is VoLTE critical to the evolution toward an all-IP networking environment? The answer is this, until the service providers can support real time voice services (and meet voice QoS requirements) in the same packet switched domain as the high volume, best-efforts data, they will be burdened with the huge capital and operating expenses of two separate networks. For most carriers, VoLTE is the solution to this dilemma.
VoLTE is based on two separately introduces 3GPP standards; IP Multimedia Subsystems (IMS), first introduced in 3GPP UMTS Release 5, and Long Term Evolution (LTE) first introduced in the 3GPP UMTS Release 8. It should be noted that 3GPP2 (the CDMA folks) offered a solution called Multi-Media Domain (MMD) to compete with IMS. There was also 3GPP2 Revision C proposal a 4G proposal for CDMA. Most CDMA service providers have opted to move to IMS for their future network service solution, and to reject Rev C in favor of the 3GPP defined LTE. Therefore future 3GPP2 standards are merging into 3GPP standards. That said the description below applies equally to the historical UMTS-based providers and the historical CDMA2000-based providers.
IMS and LTE are defined independently. Therefore IMS does not depend on the existence of LTE nor does LTE rely upon IMS. VoLTE however is a process designed to couple IMS and LTE to create an environment capable of supporting voice traffic in a shared packet data network. We can view IMS is the “Boss” in the sense that it is IMS that recognized the need for special network conditions required to support voice traffic. LTE may then be considered the “employee” responsible for carrying out the Boss’s instructions. For VoLTE, IMS directs LTE to establish the desired QoS environment, then commence with the voice call. IMS also notifies LTE when the call has completed, and directs LTE to tear down the special voice environment.
Let’s take a quick look at how this works. The process starts with a wireless subscriber (“sub”) expressing the desire to the LTE network to make a Voice over IP (VoIP) call. LTE knows this means that it must make a connection with IMS. In preparation, LTE identifies a PDN Gateway (P-GW) that offers a connection to the IMS network and establishes a Default EPS bearer from the subscriber to the selected P-GW.
The language spoken by IMS is “Session Initiation Protocol” (SIP). The default EPS bearer is established with a QoS Class Indicator (QCI) value of 5 (the QCI value required for SIP signaling). It should be noted up front that this EPS bearer will not support the QoS required for voice traffic, so we can expect to need an additional EPS bearer.
Like the IMS network, the subscriber also speaks SIP. Therefore the subscriber registers with the IMS network then commences to make a VoIP request. Before we get too far ahead of ourselves let’s introduce a couple of the key players in the IMS network. The Serving Call Session Control Function (S-CSCF) is the node with which the subscriber registers for IMS service. The S-CSCF will authenticate the subscriber, then it assumes the responsibility of connecting the subscriber with the called party once a VoIP request is made. We can consider the Proxy Call Session Control Function (P-CSCF) as the “administrative assistant” of the S-CSCF. All IMS related requests made by the subscriber must be first received by the P-CSCF before being forwarded to the S-CSCF. The P-CSCF will open the SIP request and perform any necessary administrative tasks before sending the request on to the S-CSCF.
Now that we know the players let’s examine how they interact. We will assume that the subscriber is now authenticated both by the LTE network and the IMS network. A default EPS bearer has been established between the subscriber and the appropriate P-GW, and the subscriber is ready to request the establishment of a VoIP session.
The subscriber begins by sending a SIP “Invite” message toward the S-CSCF. Contained in the SIP message is a Session Description Protocol (SDP), that carries the QoS requirement. Note that this SIP message is carried through the LTE network, but the LTE network is unaware of the content of the message (nor the need for special QoS treatment). The first contact point in IMS is the P-CSCF. The P-CSCF opens the SIP message and extracts the QoS requirement. The SIP message is sent on to the S-CSCF, while QoS requirements are sent through the Rx interface (using the Diameter protocol) to the Policy and Charging Rules Function (PCRF). The PCRF creates actionable charging and QoS rules and forwards these across the Gx interface to the Policy and Charging Enforcement (PCEF) that lives with the P-GW in the LTE network. This is the first time that LTE is aware that it must support voice traffic.
The P-GW now takes charge forwarding a request to establish a separate “dedicated bearer” (with a QCI value of 1) toward the subscriber. The subscriber is the only one in the LTE network that communicates both in the LTE language and in SIP (the IMS language). After the subscriber acknowledges that LTE can support the new dedicated bearer in LTE, the subscriber sends a SIP “UPDATE” message to the IMS network. This is a signal for IMS to complete the setup process and establish the call. It should be noted that, though the VoIP call will flow through the LTE network to the P-GW, voice packets will not transit through the IMS network elements.
IMS only comes back into action when the VoIP call is completed. Termination of the call is reflected in another SIP message called the “BYE” message, which passes through the S-CSCF and the P-CSCF. The P-CSCF detects the fact that the call had ended and triggers actions to collect IMS billing records. The P-CSCF then notifies the PCRF of call termination which in turn tells the PCEF to close out the LTE billing, and tells the P-GW to tear down the dedicated EPS bearer which had been established solely for the purpose of supporting the VoIP call.
At this point the VoLTE call and all associated signaling and billing actions are through.
Nicey explained. Can you please explain in details regarding the path taken by voice packets and how & when MRFP comes into the voice path ....."It should be noted that, though the VoIP call will flow through the LTE network to the P-GW, voice packets will not transit through the IMS network elements."
@priyesh - Once call is established (i.e. PRACH is ACKED) IMS is out of the equation. VoLTE peers were introduced to each other and know each other "location" (IP Address) and can directly communicate with each other.
Can someone suggest (or better point a reference to) a generic TFT (Traffic Flow Filter) for VoLTE QCI1 bearer?
For example, I can easily determine TFT for QCI5 signalling part: SIP Proxy ports 5060 and 5061 are de-facto standard.
I thought of using RTP ports - but these are vendor-specific. Also thought of all UDPs with TOS 184 (0xB8) but this is too generic and may include non VoLTE as well, right?