The biggest advantage of mobile operators – comparing to OTT applications – is that they are interconnected. No matter what country we are in we can connect into the network, we can place the calls, receive the calls, all under our own identity. We also don’t care in which network is our counterpart if he/she is now present in his/her home network or not. To achieve this operators need to support roaming and interworking. The IMS Roaming and Interworking Guidelines can be found in the GSMA IR.65 and LTE Roaming Guidelines in GSMA IR.88.
We’ve mentioned the roaming when we discussed the SBC. In this post we’ll take a look on what options we have. So what can be the flows when one of the participants is not physically present in the home network and needs to be connected via some other infrastructure – the visited network.
Just recently the GSMA announced the first commercial interconnected VoLTE service in South Korea. This just illustrates how far we’re still from the real IMS-based roaming.
Update: GSMA Next-generation Interconnection and Roaming Analysis for Mobile Services
In general there are 3 options how we can implement roaming nowadays:
Firstly the roaming can be done in the packet core. The P-CSCF is in the home network. But that requires a mechanism which obtains the IP address of the A-SBC. This solution called S8 (reference point) Home Routing (S8HR) is very easy and maybe a bit preferred by operators these days because that’s a standard way for data roaming. However there are many open questions here related to Lawful Intercept, Emergency Calls, SRVCC, etc. GSMA works on a new variant of S8HR which is a part of the GSMA Network 2020 Programme and was recently as agreed as VoLTE Roaming candidate.
This time the roaming operator is responsible for all the core services. Again the P-CSCF is in the home network.
The last option is what you can find in every IMS text book – the P-CSCF is in the visited network and based on the DNS response the P-CSCF will send the message into the home network. The A-SBC (P-CSCF) interacts with the PCRF and also anchors the session for eSRVCC (ATCF/ATGW/EATF). This model is referred also as Roaming Architecture for Voice over LTE with Local Breakout (RAVEL) or just Local Brakeout (LBO). This variant was suggested as a final and ultimate solution for IMS roaming.
Based on the service, commercial considerations and regulatory obligations we have two options here how to route the data.
LBO VPMN Routing (LBO-VR)
In case that we don’t need to intercept media (e.g. lawful interception) we can use Loopback Routing with the Optimal Media Routing (OMR) and bypass the home network:
The above use of LBO-VR requires to apply OMR along the signalling from VPMN A to HPMN A, and then the HPMN A can decide, e.g. based on the destination:
- To send the signalling back to the VPMN – and then, as described above, OMR is applied from HPMN A to VPMN A as well or
- To bring media to the HPMN A and send both the control and user plane from the HPMN A to the destination – in this case OMR is terminated in HPMN A. The routing decision is performed by the HPMN A in the S-CSCF (or the BGCF).
Note we have a new network function called Transit and Roaming Function (TRF). The Loopback routing is indicated in the Feature-Caps of the SIP INVITE request via +g.3gpp.trf tag. The home S-CSCF will remove this capability indicator and add +g.3gpp.loopback and will set the +g.3gpp.home-visited to the to the identifier of the visited network received in the P-Visited-Network-ID header field in the original invite/registration request. More in the 3GPP TS 24.229.
This architecture can be interesting especially for national or internal roaming. More details along with the detail flows can be found in the 3GPP TS 29.079.
LBO Home Routing – LBO-HR
When the media traffic needs go to through the home network (lawful intercept, conferencing, tones&announcements, etc.) we need to do the ‘home routing’:
Although the Ravel Model is a bit more complex comparing to S8HR due to extra signaling in case of roaming from the purely IMS point-of-view it is a more standard approach. It is more secure, all the interworking goes through I-SBC hence there is a minimal integration effort, standard bearer management, standard charging, supports both national and international roaming, no issues with anchoring for access transfer, emergency calls, LI, … I always believe that the easier/simpler technology is the better one – let’s see what will be the final solution in case of VoLTE roaming in 2020 🙂
GSMA has mandated AMR / AMR-WB codecs to be used for VoLTE. These codecs have to be implemented by all equipment manufactures to ensure a good voice quality as well as facilitating inter-operability and avoiding transcoding. In roaming scenarios we should keep that in mind. Special NNI requirements are:
- The NNI must support the AMR and the AMR-WB for both roaming and interworking between PMNs
- If super-wideband or full band voice interworking is offered then the EVS codec must be supported
More information about VoLTE codecs can be found in VoLTE Close Encounters post.
Would you be interested in more details, you can check the GSMA Network 2020 Programme Summary.
Interested in 5G roaming? Check out post IMS and 5G.
Other related posts:
Thank you for the high level explanation and your effort to describe these VoLTE roaming architectures. However, I believe that the terms RAVEL and LBO should not be used interchangeably. That is due to the fact that LBO offers three options: LBO-HR, LBO-VR and LBO-OMR. Therefore, RAVEL would rather mentioned as being the same as LBO-VR than simply LBO.
thank you for pointing this out. I admit that it is a bit misleading. I believe RAVEL is an older term for what we should call currently LBO. If I’m not mistaken, the requirements on RAVEL from beginning allowed both types of media routing (see 23.850). If not, could you please point us to some resources?