WO2015104425A1

WO2015104425A1 - Optimized media routing for a roaming webrtc ims client

Info

Publication number: WO2015104425A1
Application number: PCT/EP2015/050490
Authority: WO
Inventors: Andreas Kunz; Xiaowei Zhang; Anand Prasad
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2014-01-13
Filing date: 2015-01-13
Publication date: 2015-07-16
Anticipated expiration: 2016-07-13

Abstract

A method of providing optimized media routing for a roaming web RTC IMS client, is characterized in that a functional entity that controls access to the IMS for said webRTC IMS client or by an associated component performs the steps of detecting that said webRTC IMS client is roaming to a roaming network, in case of detecting roaming, determining a local signaling endpoint in the roaming network for a signaling connection from said webRTC IMS client, and providing information on said local signaling endpoint to said webRTC IMS client. Furthermore, a corresponding system for providing optimized media routing for a roaming webRTC IMS client, comprising a functional entity that controls access to the IMS for said webRTC IMS client, is described.

Description

OPTIMIZED MEDIA ROUTING FOR A

ROAMING WEBRTC IMS CLIENT

The present invention relates to a method of providing optinnized media routing for a roaming webRTC IMS client, as well as to a system for providing optimized media routing for a roaming webRTC IMS client, the system comprising a functional entity that controls access to the IMS for said webRTC IMS client.

Currently, the Internet Engineering Task Force, IETF, develops a new service that enables web browsers with real-time communications. At this time, this new service is known as webRTC (web Real-Time Communication). Real time communication services like, e.g., voice and video calls are then possible just with an add-in to the web browser. It is desirable that WebRTC can also interwork with other networks so that is not operating as an isolated standalone service, i.e. not only the communication between other webRTC users should be possible, but also communication to normal phones. In order to provide this functionality a study in 3GPP is being carried out on "Web Real Time Communication (WebRTC) access to IMS" in its Release 12 in the Technical Report TR 23.701.

In this context, one issue is the location dependency that results from the webRTC service provider selection of an IMS/mobile operator. Favorably, this would be done based on the own location of the webRTC service provider, and a reasonable choice would be an IMS/mobile operator in the same national country. For instance, a webRTC service provider located in the USA would not select an IMS/mobile operator from Europe; else it would not be possible to offer local country-wide calls to the normal phones in the USA without incurring additional international calling fees.

As long as the webRTC service provider and the IMS/mobile operator are located in the same country as well as the mobile originating device (User Equipment MO or sometimes briefly denoted UE MO hereinafter) and the mobile terminating device (User Equipment MT), further referred as non-roaming scenario, then there is no problem with the media routing as shown in Fig. 1.

However, as soon as the webRTC service subscriber moves away from the country where the webRTC service provider and the associated IMS/mobile operator are located, then the signaling is routed from the webRTC service subscriber to the WWSF (WebRTC web server function) and to the eP-CSCF of the associated IMS/mobile operator in this country, and the media is routed to the elMS-Access GateWay (elMS-AGW) in this country and from there towards the terminating party.

Depending on the physical distance and the internet and transit networks, the quality for the multimedia session might suffer due to the involved networks and distance. The above situation might even get worse in cases where both the webRTC subscriber and the IMS subscriber are roaming and in addition, the IMS subscriber is belonging to another operator than the webRTC service provider is interworking with. In these cases the media path may traverse several countries, which could cause severe delays, jitter and packet loss due to the traffic load situations in the traversing networks which results in a poor user experience.

In view of the above it is an objective of the present invention to improve and further develop a method and a system of providing optimized media routing for a roaming webRTC IMS client of the initially mentioned type in such a way that the user experience is improved by optimizing the media path in roaming scenarios, in particular in scenarios where not only the mobile originating device, but also the terminating party is not located in its home network anymore and is roaming too.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method is characterized in executing, by a functional entity that controls access to the IMS for said webRTC IMS client or by an associated component, the steps of detecting that said webRTC IMS client is roaming to a roaming network, in case of detecting roaming, determining a local signaling endpoint in the roaming network for a signaling connection from said webRTC IMS client, and providing information on said local signaling endpoint to said webRTC IMS client.

Furthermore, the above object is accomplished by a system comprising the features of claim 12. According to this claim such a system is characterized in that said functional entity is configured to detect that said webRTC IMS client is roaming to a roaming network, in case of detecting roaming, to determine a local signaling endpoint in the roaming network for a signaling connection from said webRTC IMS client, and to provide information on said local signaling endpoint to said webRTC IMS client.

According to the invention it has been recognized that the media path in roaming scenarios can be optimized by enabling the webRTC IMS client to perform IMS registration directly in the roaming network with preferably a local breakout in the roaming network. This is not possible to achieve with webRTC, since the client has just IP connectivity and the location of the IMS/mobile network is not bound to the current location of the webRTC client. In case of normal IMS this would be tightly coupled. To overcome this problem, in the solution architecture proposed in accordance with the present invention, a functional entity that controls access to the IMS for the webRTC IMS client (or any other component associated with such functional entity) is configured to detect roaming of the webRTC IMS client. If such roaming is detected, e.g. when it is detected that the webRTC IMS client is not located anymore within an area where the webRTC service provider has a service level agreement with an IMS/ mobile operator, an appropriate local signaling endpoint in the roaming network for a signaling connection from the webRTC IMS client is determined and information on this local signaling endpoint are provided to the webRTC IMS client. Therefore, by applying the present invention, roaming webRTC users experience a significant quality improvement of the multimedia session since the media data can be routed directly towards the terminating party.

Embodiments of the present invention may reuse the mechanisms provided for the IMS local breakout and optimal media routing. These procedures for originating and terminating sessions are described in 3GPP TS 23.228, Annex M (Informative): IMS Local Breakout and Annex Q (Normative): Optimal media routing. At this point it should be explicitly noted that webRTC is only one example technology for voice and/or video over internet telephony services. However, as will be appreciated by those skilled in the art, the solution described in connection with the present invention can be easily applied to any other voice/video over internet telephony service that desires interworking with IMS. The proposed solution can be suitably applied in all scenarios in which a client that uses such service is not located in the HPLMN anymore for enabling the client to route the respective media data directly towards a terminating party.

Further, it should be noted that, while there is no specific roaming concept in webRTC as currently defined, the term "roaming" as used in the context of the present invention generally refers to a situation in which the webRTC IMS client leaves an area (e.g. country, state, city etc.), where the webRTC service provider has a service level agreement with an IMS/mobile operator. As already indicated above, since these agreements will typically be established with IMS/mobile networks operated country-wide, the most prevalent roaming scenarios in the context of the present invention will be scenarios in which the webRTC IMS client is not located in the same country as the webRTC service provider and the IMS/mobile operator. According to preferred embodiment the functional entity that controls access to the IMS for said webRTC IMS client is a WebRTC Web Server Function, WWSF, in particular in accordance with the WWSF characteristics specified in 3GPP TR 23.701. In some embodiments, it may be provided that the WWSF is configured to provide the webRTC IMS client within the process of the webRTC IMS client download and initialization with a list of potential local signaling endpoints of IMS roaming partners. Regarding an efficient detection of roaming of the webRTC IMS client, it may be provided that the functional entity analyzes geographic information about the location of the webRTC IMS client. For instance, location information may be directly provided by the webRTC IMS client, e.g. in form of information transmitted as over-the-top information. Alternatively, if the webRTC IMS client does not provide any geographic information, the functional entity may infer location information from the IP address of the webRTC IMS client. To this end the functional entity may perform, for instance, a database lookup of the IP address used in the webRTC IMS client's registration request.

According to a preferred embodiment the functional entity may be pre-configured with a list of potential local signaling endpoints in the roaming network, from which the functional entity can simply select, as and when required, an appropriate one based on location information about the webRTC IMS client.

According to an alternative embodiment it may be provided that the functional entity, in order to determine a local signaling endpoint in the roaming network, queries its associated home IMS operator based on location information about the webRTC IMS client. Specifically, it may be provided that the home IMS operator, upon receiving such a query, seeks to retrieve respective information (i.e. information that is required for providing the functional entity an appropriate signaling endpoint in the roaming network) from the HSS, a trusted third party AAA server and/or from a database (which may be outside the IMS/mobile operator network). Additionally or alternatively, the respective information may be retrieved from other network nodes such as HPLMN eP-CSCF, l/S-CSCF, MME, or the like. It should be noted that the functional entity can send a request to provide an appropriate eP-CSCF in the roaming network directly to the respective component, e.g. to the HSS via the wh reference point (location information of the roaming webRTC IMS client can also be transported via this reference point).

According to a preferred embodiment the local signaling endpoint determined in the roaming network for a signaling connection from the webRTC client is an eP- CSCF in the roaming network, in particular in accordance with the eP-CSCF characteristics specified in 3GPP TR 23.701 (specifically in Annex A.1.3.3). In order to enable the webRTC IMS client to perform IMS local breakout very easily, the information that is provided to the webRTC IMS client may include at least the address of the eP-CSCF determined in the roaming network. With respect to facilitating the IMS registration process the information that is provided to the webRTC IMS client may further include information related to IMS identity, authentication, authorization and/or security. The webRTC IMS client may employ the provided information for local IMS registration via the roaming network.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to patent claims 1 and 12 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawing is a schematic view illustrating a non-roaming scenario in which webRTC service provider and IMS/ mobile operator are located in the same country, is a schematic view illustrating a scenario, in which webRTC IMS client and IMS UE are roaming, is a schematic view illustrating the roaming scenario of Fig. 2 with local breakout according to an embodiment of the invention, and is a diagram illustrating a signaling process of IMS registration with local breakout assignment according to an embodiment of the invention.

Although all embodiments of the present invention described hereinafter in connection with the drawings are related to webRTC, it is to be understood and once again explicitly noted that the present invention can be likewise applied to any other voice/video over internet telephony service that desires interworking with IMS.

Fig. 1 schematically illustrates a webRTC service provider and an IMS/mobile operator that are located in the same country. It is noted that this is a very likely constellation since, in order to be able to offer local country-wide calls to normal phones, a webRTC service provider located in a particular country will probably select an IMS/mobile operator located within the same country. In addition, in Fig. 1 a mobile originating device, briefly denoted UE MO, which is a webRTC service subscriber having downloaded a webRTC IMS client, WIC, and a mobile terminating device, UE MT, are also located in the same country. In this scenario, hereinafter referred as non-roaming scenario, the signaling is routed via the w1 reference point from the UE MO to the WWSF and via the w2 reference point from the UE MO to the eP-CSCF which, due to the SLA in place, is typically close to the WWSF. The media is directly routed via the elMS-AGW to the UE MT. Consequently, in this non-roaming scenario, since the data is routed directly towards the terminating party, there are no effects that would reduce the quality of the multimedia session, and user experience will therefore be usually very high. In contrast to the situation illustrated in Fig. 1 , Fig. 2 shows a worst case scenario where both the webRTC subscriber and the IMS subscriber are roaming and in addition, the IMS subscriber is belonging to another operator than the webRTC service provider is interworking with. For simplification reasons, not all IBCFs/TrGWs and other unrelated IMS components are shown.

In this scenario, the media path is traversing from the Country C (which is the current location of the webRTC subscriber) to Country A (which is the location of the webRTC service provider) to Country B (in which the home network of terminating IMS user UE MT is located) to the terminating party UE MT located in Country D. It should be noted that in the illustrated scenario, depending on the policy of the operator of IMS user UE MT, the user plane traffic may go from Country A directly to Country D (and not via Country B). However, in either case, compared with a direct path as it would be if native webRTC session setup between two webRTC clients is used, the media path is significantly longer. This long media path could cause severe delays, jitter and packet loss due to the traffic and load situations in the traversing networks which results in a poor user experience. Fig. 3 basically shows the same roaming scenario as shown in Fig. 2, however, this time not with conventional media routing in place, but with media routing in accordance with embodiments of the present invention. Fig. 4 is a diagram showing the pertaining signaling flows in accordance with embodiments of the present invention for realizing the media routing with local breakout shown in Fig. 3. In Figs. 3 and 4, same reference numerals denote same components as in Fig. 2.

The architecture shown in Fig. 3 assumes that the WWSF and the HSS (or e.g. a trusted AAA Server) can exchange messages via the wh reference point in order to transport information about the location of the roaming UE, the address of the local eP-CSCF as well as potential authentication/authorization and other security related information.

Furthermore, the architecture illustrated in Fig. 3 assumes that the WIC is the originating party and the IMS UE in country D is the terminating party. It should be noted that this does not need to be the case since, after performed IMS registration, the direction is interchangeable. The way of routing is usually controlled by the home operator, i.e. the routing of originating sessions is controlled by the IMS/mobile operator in country A, while originating sessions from the IMS UE MT would be controlled by the IMS/mobile network in country B.

The following description of the embodiment illustrated in Figs. 3 and 4 focuses on the IMS registration part in order to establish the local contact to IMS. The different ways of routing media and signaling towards the terminating party are described in 3GPP TS 23.228. In particular, the mechanisms provided for the IMS local breakout and optimal media routing for originating and terminating sessions as reused by embodiments of the present invention are described in detail in 3GPP TS 23.228, Annex M (Informative): IMS Local Breakout and Annex Q (Normative): Optimal media routing, which are incorporated herein by way of reference. The detailed call flow of the embodiment illustrated in Figs. 3 and 4 is as follows:

As illustrated in Step 1 , from within a WebRTC-enabled browser, a user may access a URI to the WWSF to initiate an HTTPS connection to the WWSF. The TLS connection may provide one-way authentication of the server based on the server certificate. The browser downloads and initializes the WIC from the WWSF. As an option the WWSF may already provide a list of eP-CSCFs (or of any other suitable endpoint for a signaling connection from the WIC) of the roaming partners of the HPLMN IMS/mobile operator for the different countries in this step. Optionally, also permanent authentication and/or authorization parameters for the IMS access can be provisioned and bound to the webRTC ID. In case that the eP- CSCF list of the roaming partners is known by the WWSF and provisioned to the UE, e.g. together with the WIC, the UE can perform eP-CSCF selection autonomously based on its own location (and may only request a token for IMS access when needed). For this it may need to perform an IP to location lookup, either also preconfigured in the UE or hosted by a server.

In Step 2, the WIC registers to the WWSF with its webRTC ID. WWSF can initiate authentication procedure if needed. If known, then the WIC can provide current geographic information (potentially with a time stamp) to the WWSF.

In Step 3, the WWSF analyzes the geographic information, if provided by the WIC. If the WIC does not provide any information, then the WWSF retrieves geographic information with a database lookup of the IP address used in the registration request. The WWSF determines whether the geographic information indicate that the WIC is still located in the area (e.g. country, state, city etc.), where the webRTC service provider has a service level agreement with an IMS/mobile operator (here referred to "non-roaming", HPLMN) or not (here referred to "roaming", VPLMN).

As illustrated in Step 4, in case the evaluation of the WWSF in the previous step results that the WIC is roaming, the WWSF queries the HPLMN IMS/mobile operator with the location information, the webRTC ID and potentially the IMS ID. The IMS/mobile operator can verify the binding or may generate a parameter for authentication and/or authorization use, for example a token. The IMS/mobile operator evaluates the geographic location and selects a roaming partner with webRTC interworking support, as well as an appropriate local signaling endpoint in the roaming network for a signaling connection from the WIC. Preferably, this local signaling endpoint is chosen to be the eP-CSCF of the roaming network. The IMS/mobile operator provides the VPLMN eP-CSCF address and if needed other information for authentication and/or authorization (e.g. token, binding information, or the like) or local network related information to the WWSF. The contact in the IMS/mobile operator for this message exchange can be either the HSS, or another network node such as HPLMN eP-CSCF, l/S-CSCF, MME. Alternatively, it can be a trusted third party AAA server, or a database (which may be outside the mobile operator network) containing the required information. In case the WWSF has already a list of IMS authentication/authorization parameters and/or a list of eP-CSCFs of the roaming partners, then the WWSF does not need to query the HPLMN IMS/mobile operator and the WWSF selects the appropriate authentication/authorization parameters and/or an appropriate eP- CSCF of a roaming partner of the IMS/mobile network based on the location information of the UE MO.

In Step 5, the WWSF selects an IMS ID or, in case of wildcarded IMPUs, generates an IMPU, e.g. based on the webRTC ID, or the WWSF may have a table of IMPUs per webRTC ID. The WWSF binds this IMS ID to the webRTC ID and, if available, binds the IMS ID to a password, to a VPLMN eP-CSCF address, to authentication information, etc.

The WWSF acknowledges the registration to the WIC and includes all relevant information, e.g. VPLMN eP-CSCF address, if needed IMD ID, password, authentication information, etc.

As shown in Step 6, the WIC stores the received information and sends a REGISTER message to the VPLMN eP-CSCF, using the IMS ID. This message may be preferably a SIP message, but could be based on any other protocol, like Diameter, Radius, XCAP, HTML, XML, WebSocket, JSON, etc.

In Step 7, if the VPLMN eP-CSCF has sufficient information, then the eP-CSCF can verify the binding of webRTC ID and IMS ID and authorize the REGISTER. The VPLMN eP-CSCF can include within the REGISTER an indicator, flag or other parameter, showing that the binding is verified and/or registration is authorized, so that it does not need to be challenged by the S-CSCF. In order to retrieve this information, the VPLMN eP-CSCF can exchange messages with the WWSF or with, e.g., a trusted AAA server.

If the VPLMN eP-CSCF does not have sufficient information to verify the binding, it may verify information from the Home IMS/mobile operator and the message destination.

In Step 8, the VPLMN eP-CSCF forwards the message towards the HPLMN S- CSCF via e.g. IBCFs, l-CSCFs, etc. This message may be preferably a SIP message, but could be based on any other protocol, like Diameter, Radius, XCAP, HTML, XML, WebSocket, JSON, etc.

In Step 9, if the HSS has already performed authentication and authorization of the IMS registration, it can provide the subscription profile to the S-CSCF with all service control related information. The HSS may exchange messages with a trusted AAA server or the WWSF for authentication/authorization of the registration request. Again, this message may be preferably a SIP message, but could be based on any other protocol, like Diameter, Radius, XCAP, HTML, XML, WebSocket, JSON, etc.

Finally, in Step 10, if the HSS indicated that further authentication and authorization is required, the S-CSCF answers towards the WIC with a 401 Unauthorized response and a challenge. Else, the S-CSCF acknowledges to the WIC the successful local IMS registration. To this end, the 200 OK or any other suitable message may be forwarded to the WIC. This message may be preferably a SIP message, but could be based on any other protocol, like Diameter, Radius, XCAP, HTML, XML, WebSocket, JSON, etc.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

List of Abbreviations:

CSCF Call Session Control Function

elMS-AGW IMS Access GateWay enhanced for WebRTC

eP-CSCF Proxy-Call Session Control Function enhanced for WebRTC

HPLMN Home Public Land Mobile Network

HSS Home Subscriber Server

l-CSCF Interrogating- CSCF

IMS IP Multimedia Subsystem

IMPU IP Multimedia Public Identity

MME Mobility Management Entity

S-CSCF Serving-CSCF

TLS Transport Layer Security

UE User Equipment

UE MO mobile originating UE

UE MT mobile terminating UE

VPLMN Visited Public Land Mobile Network

WebRTC Web Real-Time Communication

WIC WebRTC IMS Client

WWSF WebRTC Web Server Function

Claims

C l a i m s

1. Method of providing optimized media routing for a roaming webRTC IMS client,

c h a r a c t e r i z e d i n executing, by a functional entity that controls access to the IMS for said webRTC IMS client or by an associated component, the steps of

detecting that said webRTC IMS client is roaming to a roaming network, in case of detecting roaming, determining a local signaling endpoint in the roaming network for a signaling connection from said webRTC IMS client, and

providing information on said local signaling endpoint to said webRTC IMS client.

2. Method according to claim 1 , wherein said functional entity that controls access to the IMS for said webRTC IMS client is a WebRTC Web Server Function,

WWSF.

3. Method according to claim 1 or 2, wherein roaming of said webRTC IMS client is detected by said functional entity on the basis of geographic information about the location of said webRTC IMS client.

4. Method according to any of claims 1 to 3, wherein roaming of said webRTC IMS client is detected by said functional entity based on location information directly provided by said webRTC IMS client.

5. Method according to any of claims 1 to 4, wherein roaming of said webRTC IMS client is detected by said functional entity on the basis of the IP address of said webRTC IMS client.

6. Method according to any of claims 1 to 5, wherein said functional entity is pre-configured with a list of potential local signaling endpoints in the roaming network, from which said functional entity selects an appropriate one based on location information about said webRTC IMS client.

7. Method according to any of claims 1 to 5, wherein said functional entity, in order to determine a local signaling endpoint in the roaming network, queries its associated home IMS operator based on location information about said webRTC IMS client.

8. Method according to claim 7, wherein said home IMS operator retrieves information that are required for providing said functional entity an appropriate signaling endpoint in the roaming network from the HSS, a trusted third party AAA server and/or from an external database.

9. Method according to any of claims 1 to 8, wherein said determined local signaling endpoint is an eP-CSCF in the roaming network.

10. Method according to any of claims 1 to 9, wherein the information that is provided to said webRTC IMS client includes the address of said eP-CSCF determined in the roaming network, and/or

wherein the information that is provided to said webRTC IMS client includes information related to IMS identity, authentication, authorization and/or security.

1 1. Method according to any of claims 1 to 10, wherein said webRTC IMS client employs the provided information for local IMS registration via the roaming network.

12. Method according to any of claims 1 to 1 1 , wherein said eP-CSCF determined in the roaming network, upon receiving a registration request from said webRTC IMS client, performs verification and authorization of said registration request based on binding information said WWSF has generated between an ID of the roaming network and the webRTC ID.

13. System for providing optimized media routing for a roaming webRTC IMS client, in particular for executing a method according to any of claims 1 to 12, said system comprising

a functional entity that controls access to the IMS for said webRTC IMS client, c h a r a c t e r i z e d i n that said functional entity is configured

to detect that said webRTC IMS client is roanning to a roaming network, in case of detecting roaming, to determine a local signaling endpoint in the roaming network for a signaling connection from said webRTC IMS client, and to provide information on said local signaling endpoint to said webRTC IMS client.

14. System according to claim 13, wherein said functional entity is a WebRTC Web Server Function, WWSF.

15. System according to claim 14, wherein said WWSF is configured to provide said webRTC IMS client within the process of the webRTC IMS client download and initialization with a list of potential local signaling endpoints of IMS roaming partners.