voice over IP
There’s a lot of publicity about mobile VoIP — but how might call handover actually work in a standardised IMS environment? These extracts from a whitepaper by BridgePort Networks show how an IMS convergence server can support possible future iterations of the service, and leverage existing signalling for service support.
“MobileVoIP handover is the process of continuing a voice call as a user moves between Wi-Fi and cellular networks. By 2009, it is estimated there will be over 66 million cellular/Wi-Fi dual-mode handsets in operation. MobileVoIP service is promising improved reception and fewer dropped calls via Wi-Fi. If handover is not reliably implemented and calls are dropped, customer satisfaction statistics suggest it could inhibit customer adoption. Therefore, it is critical that handover occurs quickly, seamlessly and reliably.”
“MobileVoIP handover specifically refers to voice call continuity from a SIP and RTP-based VoIP call moving from Wi-Fi to cellular, or vice-versa (as distinct from non-SIP voice standards like UMA, the Unlicensed Mobile access). SIP-based VoIP over Wi-Fi is the industry direction for convergence voice services given the trend towards IMS and the established presence of SIP in wireline, enterprise, cable and ISP domains.”
Standards development
“At both the 3GPP and 3GPP2 organizations, a number of handover control methods were evaluated. They ranged from methods that placed handover control in the handset versus the network. Also, alternative methods incorporated a single call leg versus two call legs. After debate, the industry has settled upon similar approaches in both the GSM and CDMA realms. 3GPP is working to adopt the IMS Control Model (ICM) MobileVoIP handover method, and 3GPP2 has adopted the Call Transfer Model (CTM) MobileVoIP handover method.”
“Both standards anchor control for MobileVoIP handover in IMS network elements and establish multiple call legs during the handover process.”
A model call
“A subscriber wants to communicate wirelessly via Wi-Fi while inside a building
, and via the cellular network (CDMA or GSM) when outside the building. Starting
in the Wi-Fi domain, the subscriber’s dual-mode MobileVoIP device switches from Wi-Fi to cellular when it senses that the Wi-Fi network signal is getting weaker as he or she leaves the building. When the signal quality degrades to a pre-defined threshold, the dual-mode MobileVoIP device interacts with the IMS Convergence Server (ICS) to setup a separate call leg via the cellular air interface, at which time the handset turns on the cellular radio.
“The ICS then works with the network to establish a separate cellular network call via the dualmode MobileVoIP device’s cellular radio, once this second call leg is established, the dual-mode MobileVoIP device radio then shuts off its Wi-Fi radio. At that point, the screen changes color or a beep notifies the user that the network connectivity has been switched from the Wi-Fi to the cellular network.”
Handover control
“As described above, the actual handover between the Wi-Fi and cellular network is controlled via the ICS, implementing the 3GPP-defined IMS Control Model (ICM) for GSM networks. Alternatively, handover between the IMS and CDMA-based networks is controlled via the 3GPP2-defined Call Transfer Model (CTM).”
“The ICS will implement both the Call Continuity Control Function (CCCF) and Network Domain Selection (NeDS) functionality specified by 3GPP. In essence the CCCF portion of the NomadicONE ICS is a new IMS Application Server network element. It resides in the home IMS network and tracks all call sessions and related MobileVoIP bearer traffic.”
“The NeDS portion of the NomadicONE ICS is also an application server location in the IMS network that performs registration/de-registration management between the IMS and circuit switched (i.e. GSM or CDMA) networks. Although potentially separate functions, both the CCCF and NeDS could be implemented into a single IMS-compatible network element.”
HLR interface for supplementary services
“The 3GPP2 requirements are defined such that the CCCF/NeDS MUST interface with the legacy Home Location Register (HLR) to perform MobileVoIP handover and support existing supplementary services (i.e. user efined call forwarding).”
“Conversely, the 3GPP requirements are defined such that the CCCF/NeDS is specified NOT to interact with the HLR. As a result, service providers will be required to re-implement supplementary service capabilities in their IMS networks.”
To minimise service provider cost, it is possible to provide an optional configuration for the ICS that will utilise a service provider’s existing SS7-based MAP infrastructure to supply supplementary services. The configuration remains compliant with 3GPP IMS standards and will ensure faster and more reliable handovers. Under this configuration, the ICS will interact with the GSM operators’ HLR via their existing SS7-based MAP signaling network.”
“This HLR interaction allows handovers to occur faster — in about 5 seconds — than handovers in networks without SS7-based MAP capabilities. This shorter total handover time will reduce the window of opportunity for problems to occur and should improve handover reliability. It should be noted the second handover time period occurs only on the signaling stream. Users will continue to have an uninterrupted conversation until the very moment the handover occurs. At handover there will be a short 250ms delay, which isconsistent with current cellular network handovers.”
“The optional GSM HLR access capabilities will have no impact on compatibility with handsets and how they interact under the ICM method.”