WO2018224859A1

WO2018224859A1 - Communication session transfer upon data transmission restriction

Info

Publication number: WO2018224859A1
Application number: PCT/IB2017/053328
Authority: WO
Inventors: George Foti; Ankur DAUNERIA; Nipun Sharma
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-06-06
Filing date: 2017-06-06
Publication date: 2018-12-13

Abstract

A method and apparatus for transferring an IMS or an OTT communication session between a first user equipment and a second user equipment to a third user equipment based on the communication type and an indication enabling transfer due to data transmission restriction applied on the second user equipment is provided. A network entity (DPI or IMS CSCF) receives a first message for establishing a communication session from the first user equipment to a second user equipment. It obtains information indicating transfer due to data transmission restriction is enabled for the second user equipment and determines based on the information and the type of the communication session (e.g., voice, video, etc.) that the communication session should be transferred by sending a message to transfer the establishment of the communication session between the first user equipment and the transfer-to-destination equipment provided at an application server (OTT) or by the HSS (IMS).

Description

COMMUNICATION SESSION TRANSFER UPON DATA TRANSMISSION

RESTRICTION

Technical Field

[0001] This disclosure generally relates to transfer of communication

sessions.

Background

[0002] Communication sessions may be managed sessions established via Internet Protocol Multimedia Subsystem, IMS, or unmanaged communication sessions known as Over-the-Top, OTT, sessions established using OTT applications such as Skype, Facetime, Whatsapp, Google talk, and the like. Both managed and unmanaged sessions are carried over packet data networks. Each user equipment, UE, attach to a packet data network such as an Evolved packet core, EPC, network. Once attached, a user equipment can start receiving packet data services as well as IMS or OTT communication services. The user may initiate or receive a request to establish either a managed communication session such as an IMS session or an unmanaged communication session such as Skype call, whatsapp, viber call, and the like. OTT traffic is transported as user data over the EPC, i.e., EPC only provides a bit pipe over which the OTT traffic is transported. IMS cooperate with EPC to reserve appropriate resources and quality of service for the IMS

communication service. Figure 1 (prior art) illustrates managed and

OTT/unmanaged communication sessions over packet data network.

[0003] Both managed and unmanaged communication sessions support

session transfer services such as transfer on busy, unconditional transfer, transfer on unavailable. Users may be able to transfer incoming sessions to an alternative destination which may be another user equipment, UE, or a voice mail. The complete session is transferred to the alternative destination.

[0004] Users of communication services may be prepaid users or postpaid users. The packet data network may apply data transmission restriction which consists of blocking data transmission to and from the user, which is typically the case for a prepaid user that has reached a data limit. Blocking

transmission may also be applied to postpaid users when requesting unavailable resources for a communication service. Other data transmission restriction method consists of reducing data speed over the packet data network. This is generally referred to as applying Fair Usage Policy, FUP. FUP is used by broadband or packet data network operators to make sure that a few heavy users do not fill up the available bandwidth, thus negatively impacting the overall experience for the majority of the users of the same packet data network.

[0005] User equipments such as smartphones, tablets, personal computers, as used daily, consume a large amount of data, via social applications, streaming videos from YouTube, voice and video chatting, and gaming and the likes. For example, Skype is a wildly used application offering an over the top communication service. A Skype-to-Skype call for 60 seconds could take 3MB, so a 30 minutes Skype call could use 90MB of data. Browsing Web pages and social media websites may consume about another 100MB, while emailing and doing other work Web-based applications may use about 100MB more. Additionally, average users consume around 200 MB of data when streaming audio and video.

[0006] FUP could be applied by lowering the data speeds after a certain

determined bandwidth limit or threshold is reached. FUP may be applied differently by different operators. FUP could be applicable on all data plans. When FUP is applied, the data transfer continues, albeit at reduced speeds. As mentioned before, FUP limits are imposed to ensure that the best quality of broadband is available to the maximum number of internet users. For example, a user with unlimited data plan can be provided with unlimited data transfer at 100Mb/s, but after reaching a determined limit or threshold the data speed is reduced to 512 kb/s or 256 kb/s or other. For communication services such as conversational video, file sharing, white board, and any other media type, FUP could have an impact on the overall user experience and on the application performance.

Summary

[0007] Embodiments in this disclosure describe a solution where upon data transmission restriction (i.e., FUP, blocking due to data limit reached) is applied for a terminating UE connected to the packet data network and an originating UE is attempting to establish a communication session (OTT or IMS) towards the terminating UE, the network (DPI or CSCF) redirects or transfers the communication towards a third UE to which data transmission restriction does not apply. The third UE may be a communication device at home connected via WiFi, a PSTN phone, a computer and may support one or more OTT communication application and IMS. There may be more than one third UE configured in the network to which communication session are transferred to. The third UEs are selected on the basis of one or more of the following parameters: communication session type (video, voice, file sharing, whiteboard, etc.), the type of communication application supported (IMS, Viber, Skype, and the like), availability/presence status of the third UEs.

Therefore, the third UEs capability should be known when configured as transfer-to-destinations for terminating UEs in the network when the terminating UEs are under data transmission restriction by the packet data network to which they are attached.

08] In one aspect, a method of transferring a communication session executed at a DPI or S-CSCF network entity or function is provide. The method comprises receiving a first packet comprising a first message, where the first message is either an OTT message or an IMS message. The message indicates the communication type requested, such as video, voice, or any other media type. The method further comprises the step of

determining that the first message is an establishment request for a

communication session from the first user equipment to a second user equipment connected to a packet communication network. The first message may be an OTT message indication a session request or an IMS SIP INVITE message. The method further comprises the step of obtaining information where the information comprises

o an indication (or a flag) enabling transfer of the communication session due to data transmission restriction on the packet data network being enabled for the second user equipment and o a type of the communication session to transfer (i.e., voice, video, file sharing or other media type or simply all types of communication session). o It also includes the next forwarding entity which Is the AS for OTT session or destination UEs for IMS sessions.

[0009] If DPI, the information may be obtained from a PCRF. If S-CSCF, the information may be obtained from either HSS or l-CSCF. Finally, the method comprises the step of sending, based on the information, a second packet comprising a second message for establishment of the communication session between the first user equipment and a third user equipment. The second packet may comprise another OTT message or an IMS message.

[0010] In one embodiment, if the method is executed at a DPI, the step of determining that the first message is an establishment request for a communication session further comprises performing deep packet inspection of the packet to obtain further information that comprises comprising the protocol type of the first message, the first message port number, the first message type and/or the type of the communication session included within the message.

[0011] In one aspect, the first and second message are of the same protocol type (either using same OTT application or both are using SIP IMS). In another aspect, the first and the second message are of different protocol type.

[0012] In another aspect, when DPI is used to transfer the communication session to an Application server, the second packet comprises an

identification of the DPI indicating that the DPI should remain on a signaling path for all messages associated with the establishment and management of the communication session.

[0013] In one aspect, the data transmission restriction indicates data limit is reached for UEb, in which case, all types of communication session attempted to be delivered to UEb under data transmission restriction are expected to be transferred. In another aspect, the data transmission restriction indicates reduced network data speed for UEb, in which case the network may select communication session to be transferred based on the type of the

communication session (e.g., video).

[0014] In one aspect, a method of transferring a communication session from a first user equipment to a transfer-to destination equipment or UEc is provided. The method is executed by an application server and comprises the step of receiving a first message corresponding to an over the top, OTT, application, from an originating entity (i.e., DPI) where the first message indicates a request for establishment of the communication session between the first user equipment and a second user equipment. However, the second user is under data transmission restriction by the packet data network to which it is connected. The AS further executes the step of determining the transfer-to-destination equipment (UEc) configured for the second user equipment where the UEc is selected also based on the type of

communication session. The method finally comprises the step of sending a second message towards the UEc for establishment of the communication session between the first user equipment and the UEc/transfer-to-destination equipment.

[0015] In another aspect, the first message and the second message are of different protocol type, where the first message corresponds to an OTT application and the second message corresponds to a different OTT application or to a SIP IMS message. When the protocol are differents, the method further comprises the step of converting the first message to the second message as well as protocol converting all subsequent messages associated with the establishment and maintenance of the communication session between the first user and the UEc/transfer-to-destination.

Brief Description of the Drawings

[0016] Embodiments of the present invention will now be described, by way of example only, with reference to the attached Figures, wherein:

[0017] Figure 1 (Prior art) is a schematic illustration of an OTT call and an IMS call when UEa and UEb are attached to an LTE/EPC packet data network.

[0018] Figure 2 illustrates transfer to UEc of an OTT session establishment from UEa to UEb when data transmission restriction is applied on UEb and with the transfer initiated by a DPI network entity according to one

embodiment.

[0019] Figure 3 illustrates transfer to UEc of an IMS session establishment from UEa to UEb when data transmission restriction is applied on UEb with the transfer initiated by IMS according to another embodiment. [0020] Figure 4 illustrates a method for triggering the transfer of a communication session to a third UE (UEc) at a network entity (DPI or CSCF) according to an embodiment.

[0021] Figure 5 illustrates a method for handling a transferred OTT

communication session and executing the transfer to a third UE (UEc) according to an embodiment.

[0022] Figure 6 illustrates a schematic illustration of a network entity (DPI,

CSCF or AS), according to an embodiment.

[0023] Figure 7 illustrates a schematic illustration of a network entity (DPI entity or CSCF entity), according to another embodiment.

Detailed Description

[0024] The following acronyms are used throughout this disclosure.

5G 5^th Generation

3GPP 3^rd Generation Partnership Project

AS Application Server

CSCF Call session Control Function

DPI Deep Packet Inspection

EPC Evolved Packet Core

EPS Evolved Packet System

GPRS General Packet Radio System

HSS Home Subscriber Server

l-CSCF Interrogating CSCF

IMS Internet protocol Multimedia Subsystem

IMSI International Mobile Subscriber Identity

LTE Long Term Evolution

MSRP Message Session Relay Protocol

O&M Operation and Maintenance

OSI Open Systems Interconnection

OTT Over The Top

P2P Peer to Peer

PCRF Policy and Charging Rule Function

PGW Packet Data Gateway

RTP Real Time Protocol S-CSCF Serving CSCF

SDP Session Description Protocol

TDF Traffic Detection Function

TS Technical Specification

UE User Equipment

VoLTE Voice over LTE

WiFi Wireless Fidelity

[0025] The various features of the invention will now be described with

reference to the figures. These various aspects are described hereafter in greater detail in connection with exemplary embodiments and examples to facilitate an understanding of the invention, but should not be construed as limited to these embodiments. Rather, these embodiments are provided so that the disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0026] Many aspects of the invention are described in terms of sequences of actions or functions to be performed by elements of a computer system or other hardware capable of executing programmed instructions. It will be recognized that the various actions could be performed by specialized circuits, by program instructions being executed by one or more processors, or by a combination of both. Moreover, the invention can additionally be considered to be embodied entirely within any form of computer readable carrier or carrier wave containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0027] Managed communication sessions can be established using an

operator controlled network such as IMS in which the operator controls the establishment of the communication session and provides network services for the delivery and management of the communication session. Such network services include authentication, encryption, resource management, guaranteed quality of service as required for the communication session, charging and policy control. The UEs are equipped with an IMS client such as VoLTE client and communicate with the IMS in the network using protocols such as SIP for signaling and RTP or MSRP or the like for transporting the media associated with a communication session (e.g., voice, video, text, file sharing).

[0028] Communication sessions using OTT applications are unmanaged

communication sessions, in which case the UEs equipped with the specific application (e.g., Skype, Viber, Whatspp, Googtalk, and the like) communicate with each other over a bit pipe provided by the network. The bitpipe

transparently transports the OTT session signaling and media between the UEs. All signaling and data associated with the OTT session is treated as user data by the packet data network (e.g., LTE/EPC) and are sent and received to and from the internet or intranet without traversing IMS. Traffic associated with the unmanaged communication service is typically

transported with best effort end-to-end.

[0029] UEs connected to a packet data network, are associated to a

subscription in the HSS 180 of the packet data network. The subscription may be postpaid or prepaid. Postpaid users may be associated to an unlimited or limited data plan at a max data speed ds1 (e.g., 10Mb/s). However, Data transmission restriction may be applied by the packet data network to which the UEs are attached. If the bandwidth limit is reached for limited bandwidth data plans or in accordance with the operator policy for unlimited data plans, the network data speed may be reduced in order to prevent heavy users from overwhelming the packet data network. The speed may be reduced to

512kb/s or even 256 kb/s whenever required. This is referred to as FUP. When a postpaid user attempts to establish a communication session and resources are not available to satisfy the quality of service demands for the media, the communication session is aborted. When online charging methods for communication services are used for postpaid users, a communication session may also be rejected if a threshold for the requested resources is reached.

[0030] For prepaid users, communication sessions are typically terminated when the data limit is reached. The UE traffic is typically redirected to a replenishing server.

[0031] The packet data network may be an EPS comprising an EPC network and an LTE radio access network, or other cellular access network). The packet data network may also be a 5G packet network that includes the 5G packet core and the 5G radio access network. GPRS networks may also be used. Embodiments in this disclosure are described using EPS comprising EPC and an LTE radio access network.

[0032] Embodiments in this disclosure describe a solution where upon data transmission restriction (i.e., FUP, blocking due to data limit reached) is applied for a terminating UE connected to the packet data network and an originating UE is attempting to establish a communication session (OTT or IMS) towards the terminating UE, the network (DPI or CSCF) redirects or transfers the communication towards a third UE to which data transmission restriction does not apply. The third UE may be a communication device at home connected via WiFi, a PSTN phone, a computer and may support one or more OTT communication application and IMS. There may be more than one third UE configured in the network to which communication session are transferred to. The third UEs are selected on the basis of one or more of the following parameters: communication session type (video, voice, file sharing, whiteboard, etc.), the type of communication application supported (IMS, Viber, Skype, and the like), availability/presence status of the third UEs. Therefore, the third UEs capability should be known when configured as transfer-to-destinations for terminating UEs in the network when the terminating UEs are under data transmission restriction by the packet data network to which they are attached.

[0033] Figure 2 illustrates a transfer to UEc 120 of an OTT session

establishment from UEa 1 10 to UEb 100 when data transmission restriction is applied on UEb with the transfer initiated by a DPI network entity 140 according to one embodiment.

[0034] The DPI network entity 140 may be a standard TDF as specified in 3GPP TS 23. 203. It may be a standalone network entity in the network or it may be co-located with a GW, such as PGW in the EPC (PGW/PCRF 130). DPI may be natively implemented on a physical device or may be

implemented as a virtual function. The DPI provides an advanced method of packet filtering that functions at the Application layer of the OSI reference model. The use of DPI makes it possible to find, identify, classify, reroute or block packets with specific data or code payloads that conventional packet filtering, which examines only packet headers, cannot detect. DPI has also been used to throttle data transfer to prevent P2P abuse, improving network performance for most subscribers. Such P2P traffic includes the OTT applications mentioned above. The DPI 140 is preconfigured or is dynamically configured with application filter data or heuristics that will enable it to filter at the application level the type of OTT application used, and may detect the message type and the requested media type.

[0035] PGW and PCRF illustrated as EPC(PGVWPCRF) 130 are few of the elements of the Evolved Packet Core, EPC. Once UEb 100 is attached to a PGW, a bearer (bit pipe) is established for UEb 100 over an SGW, PGW and an eNB (not shown) for as long as UEb is attached to the EPC. The PCRF as specified in 3GPP TS 23.203 provides policy control. It provisions policy rules at the DPI and/or the PGW for applications and services used by UEb. One example of the policy rule that can be provisioned at the DPI is a rule to transfer any detected traffic for an application to a destination server.

According to 3GPP TS 23.203, the PCRF is connected to an online charging system that monitors the data limit. Additionally, the operator may configure network policies based on time of the day. The online charging system or network policy may trigger new rules to be provisioned at the PGW or the DPI. Furthermore, in accordance with an embodiment in this disclosure policy rules may be provisioned based on network load where data transmission restriction would be applied for some applications or for all traffic of UEb 100. More specifically, the PCRF may determine that a communication session involving video should be transferred, or a communication session involving transfer of large volume of data should be transferred. A more general policy could be to transfer all communication sessions, or to transfer only OTT communication sessions.

[0036] The AS 150 is an AS that performs transfer of communication session from the terminating UE, UEb 100 to a third UE, UEc 120. More specifically, AS 150 is used for OTT communication session transfer and supports OTT to OTT and OTT to IMS SIP protocol conversions as required in the proposed embodiments herein. Namely, if UEc 120 supports IMS and is identified as being IMS registered in the AS 150, the AS 150 converts OTT messages to SIP messages prior to transferring the communication session messages to UEc 120. The AS 150 may select a UEc 120 based on the supported application (e.g., same OTT application to prevent protocol conversion). Other criteria for selecting a UEc may include the media type required by the communication session and presence information. Therefore, if UEc 120 supports the same application as the application that triggered the

communication session establishment request at UEa 1 10, it may be selected on that basis.

[0037] At step 200 of Figure 2, UEb 100 is attached to EPC (PGW/PCRF) 130. The procedure for attaching to EPC are well known and are described in 3GPP TS 23.401 . Once attached, UEb 100 has at a minimum one EPS bearer (data bearer) established as a default bearer and is used to transport all data to and from the UEb 100 to the PGW in EPC. The PGW connects the UEb 100 to the internet or intranet. The DPI 140 may be located behind the PGW on the SGi interface and all traffic to and from the internet/intranet and the PGW pass through the DPI 140. The DPI 140 may also be collocated with the PGW of the EPC.

[0038] At step 210, the DPI 140 receives a packet containing an OTT

communication session request. At step 220, the DPI 140 uses the heuristics to analyze the data packet to detect the type of OTT application, the OTT message type or even the requested media type. Once the analyzed data packet indicates an OTT communication session establishment request to UEb 100, the DPI 140 determines that a policy rule for UEb 100 should be applied. The policy rule may be statically or dynamically provisioned by the PCRF in the DPI 140. The policy rule indicates that due to data transmission restriction, i.e., reduced network speed or data limit reached for UEb 100, packet data traffic for any OTT communication session establishment request should be transferred to an application server AS 150 for further transfer to a third UE, UEc 120. Note that other policy rule may dictate that transfer of traffic related to only video communication session requesting should be transferred due to reduced network speed in the packet data network, i.e., EPC. It is understood that other policy rules based on the media type and type of applied data restriction (e.g., FUP, data blocking) may be defined and provisioned. [0039] At step 230, the DPI 140 redirects, proxies or tunnels the message received at step 210 to AS 150. At step 240, the AS 150 receives the packet from the DPI 140 on a dedicated port number that enables the AS 150 to implicitly identify that the received packet is a trigger for initiating the transfer to UEc 120. Dedicated port number can be used if AS 150 performs other functions other than transfer to third UEs/UEcs 120). Each OTT application signaling related to a session will have a different port number hence implicitly identifying the OTT application to the AS 150. The AS 150 is configured with one or more UEc number for each UEb 100 , the supported OTT applications in the UEc 120, the UEc availability status and/or the media capability (video, voice, other media type). UEc 120 may be a mobile or a landline device. The AS 150 implements the signaling flow for various popular OTT applications to complete the communication session setup between the originator UEa 1 10 and the new target UEc 120. It may be required to perform protocol conversion between the first OTT application signalling and another OTT application signaling, or between the first OTT application signalling and IMS signalling as required. In the embodiment of figure 2, UEc 120 is a UE supporting IMS that has performed IMS registration. Therefore, the AS 150 performs protocol conversion between OTT application signalling and IMS signalling to complete the session establishment.

[0040] At step 250, AS 150 sends a SIP Invite message to UEc 120 to which UEc 120 responds at step 260. The AS 150 converts the response from UEc 120 to an OTT message at step 270 and the communication session between UEa 1 10 and UEc 120 via the AS 150 is established. At step 280, the media path is established between UEa 1 10 and UEc 120, either directly if both UEa 1 10 and UEc 120 support RTP and the same codec, or indirectly via the AS 150 or a media gateway selected by the AS 150 (not shown). Figure 2 illustrates a media plane established directly between the UEa 1 10 and the UEb 130.

[0041] Figure 3 illustrates transfer to UEc 120 of an IMS session

establishment from UEa 1 10 to UEb 100 when data transmission restriction is applied on UEb 100 with the transfer initiated by IMS according to another embodiment. Unlike Figure2, the communication session initiated by UEa 1 10 is an IMS session, i.e., a managed communication session. The IMS communication session establishment is received and handled by the CSCF in the IMS network. The following IMS functional entities are involved in IMS communication session establishment: S-CSCF 160, l-CSCF 170 and HSS 180.

[0042] The HSS 180 maintains subscriber data for UEb 100 (and any other UEs). Both packet data network subscription data (for Ueb 100 attaching to EPC) and IMS subscription data (for UEb 100 registering to IMS) are maintained at the HSS 180. Therefore, any UEc number (also refered to as C- number) to which an IMS communication session to UEb 100 should be transferred to, is configured in HSS 180 as part of the UEb 100 IMS

subscriber data. The UEb subscriber data may be updated in the HSS 180 by an O&M system or a policy node or a charging node in the EPC. Upon Data transmission restriction is applied on UEb 100, an indication of either a data threshold or a network speed reduction for UEb could be sent to the HSS 180. The IMSI of UEb 100 would be used to reference the correct record in HSS 180. Once the HSS record is updated and if UEb 100 is already registered in IMS 190, the HSS 180 provides (e.g., pushes) the profile update to S-CSCF 160. Otherwise, the subscriber profile will be downloaded at the S-CSCF 160 during UEb 100 IMS registration in IMS 190. The updated profile consists of providing C-number corresponding to UEc 120 indicating that any incoming IMS communication session for UEb 100 should be transferred to UEc 120. Alternatively, the profile update may indicate that only IMS communication session to UEb 100 with a video component or requiring file or whiteboard sharing should be transferred to UEc 120. Additionally, the HSS 180 may configure for each UEb 100 more than one C-number (UEc 120) based on the type of communication session. For example, a voice only communication session may be transferred to UEc1 while video communication session may be transferred to UEc2.

[0043] Step 200 of Figure 3 is the same as step 200 of Figure 2. UEb 100 is attached to EPC (PGW/PCRF) 130. The procedure for attaching to EPC are well known and are described in 3GPP TS 23.401 . Once attached, UEb 100 has at a minimum one EPS bearer (data bearer) established as a default bearer and is used to transport all data to and from the UEb 100 to the network beyond the PGW. The network beyond the PGW is an internet, or intranet or operator IMS network. At step 300, UEb 100 may use the default bearer or an additional bearer to send an IMS registration message to IMS (S- CSCF 160 via P-CSCF (not shown)). The UEb 100 is IMS registered to be able to receive IMS communication session establishment request. After the UEb 100 is IMS registered, data transmission restriction is triggered by the network, either due to FUP being applied or data limit is reached for the UEb 100. At step 310, the HSS 180 is updated that data transmission restriction for UEb 100 is applied and is provided with indication of the type of restriction: i.e., reducing data speed to a new lower limit and indicates the new speed limit or data transmission is blocked due to data transmission threshold reached. The data transmission restriction update indicates that incoming IMS communication session to UEb 100 have to be transferred to UEc 120. The transfer may apply to all IMS communication session or to only high

bandwidth communication sessions (such as video communication session) when network speed reduction is applied. At step 320, the HSS 180 updates the S-CSCF 180 as the UEb 100 has already IMS registered. The HSS 180 provides one or more C-number to which the transfer has to be made and may provide the type of communication session to be transferred. If the type of communication session indicates "all" type and only one C-number is provided, then all IMS communication session should be transferred to that C- number. If more than one C-number is provided, the HSS 180 may indicate which C-number to use based on the type of communication session (video, voice, whiteboard, etc.). The S-CSCF 160 is thus provided with a profile for UEb comprising one or more C-numbers (UEcs 120), the type of

communication session per UEc 120, and an indication (e.g., a flag) indicating transfer to C-number due to data transmission restriction is enabled. When data transmission restriction is lifted by the packet data network and the HSS 180 is updated, the HSS 180 updates the indication (by inactivating the flag) in the S-CSCF 160 accordingly. When the transfer due data transmission restriction is inactivated, the S-CSCF resumes normal call delivery to UEb 100.

44] At step 330, UEa 1 10 sends a SIP INVITE message to UEb 100. The I- CSCF 170 receives the message and at step 340 it queries the HSS 180 for the assigned S-CSCF 160 for the UEb 100 using a Location-Info-Request (LIR) diameter request. At step 350, the HSS 180 returns the assigned S- CSCF 160 in a Location-Info-Answer (LIA).

[0045] At step 360, the l-CSCF 170 forwards the INVITE message to the S- CSCF 160. At step 370, the S-CSCF 160 determines from the received profile (previously updated by the HSS 180 at step 320) that the call has to be transferred to a C-number. If the profile includes more than one C-number, the S-CSCF 160 examines the SDP in the INVITE message and if the SDP includes a video and audio component, the communication session is a video call. The S-CSCF 160 fetches a C-number that can handle video calls and at step 380, the S-CSCF 160 initiates a new INVITE to the UEc 120.

[0046] At step 390, the SIP final response, 200-OK, is sent by UEc 120 to the S-CSCF 160. This is typically generated when the UEc 120 has accepted the incoming session setup and the RTP media path is finally established at step 390b between UEa 1 10 and UEc 120.

[0047] In an alternative embodiment, when the data transmission restriction is applied for UEb 100 and the HSS 180 is updated as shown in step 310 of Figure 3, the HSS 180 does not push the profile update to S-CSCF 160.

Instead, when at step 330, a SIP INVITE message for UEb 100 is received at l-CSCF 170, the l-CSCF may receive the profile update at step 350 when querying the HSS 180 for the S-CSCF 160 assigned to UEb 100. The l-CSCF 170 would include the received updated profile in the SIP INVITE forwarded to the S-SCFC 160. In either case, the S-CSCF 160 receives the profile update for UEb 100. It may receive it either from the HSS 180 (as shown in Figure 3) or from the l-CSCF 170.

[0048] Figure 4 illustrates a method 40 for triggering the transfer of a

communication session to a third UE (UEc) at a network entity (DPI or CSCF) according to an embodiment. The method 40 applies to an OTT

communication session in which case, the method is executed at the DPI or to an IMS communication session in which case the method 40 is executed at the CSCF, namely the S-CSCF.

[0049] For OTT communication session:

[0050] At step 41 , the DPI receives a packet for UEb from UEa that contains an OTT message. At step 42, the DPI loaded with heuristics analyzes the packet and determines the application type (e.g., Skype, Viber and the like.) used and may determine, if the message is not encrypted, the media type requested and even the message type. The message type indicates that the message is a request for OTT communication session establishment.

[0051] At step 43, the DPI obtains information indicating transfer due to data transmission restriction on the packet data network is enabled for UEb and that messages corresponding to an OTT communication application should be redirected/transferred to a provided destination address. In the case of DPI the provided destination is the address of an AS that will take care of transferring the session to a third UE, UEc. The DPI obtains the information using one of the following methods:

- requesting the PCRF or

- statically preconfigured or

- previously configured from the PCRF.

[0052] The information obtained by the DPI may indicate that only transfer of some type of communication session should be done, for instance video, sessions or file sharing sessions or whiteboard, i.e., high bandwidth sessions. If all types of communication session should be transferred including voice, then "all" type should be indicated in the information. The DPI, at step 44 uses the obtained information i.e., transfer due to data transmission restriction enabled and the type of communication session to perform the sending step towards an application server for further transfer to a final destination being a third UE, UEc. If transfer due to data transmission restriction is enabled for UEb, and the type of communication session is video, the DPI should be able to analyze the packet to determine the type of communication session. If the DPI determined the type of the communication session from the analysis of the packet is a video communication session, it initiates the transfer by sending a second packet towards the AS. The second packet includes the DPI IP address as a source IP address, and may indicate to the AS that it should remain on the signalling path for all signalling messages towards the UEa. The second packet also includes the received OTT message in the second packet. The packet is sent to a specialized application server which function is to transfer communication sessions. The packet may also be sent to a dedicated port in an application server, where any incoming session request received on that dedidated port should be transferred.

[0053] If transfer due to data transmission restriction is enabled for UEb, and the type of communication session is "all" type, the DPI initiates the transfer of all OTT communication session messages regardless of its type to the AS. The DPI sends, proxies or tunnels the OTT message in a second packet towards the AS. The DPI may indicate that it remains in the signalling path for the communication session.

[0054] For IMS communication session:

[0055] At step 41 , the S-CSCF receives a packet containing an INVITE

message for UEb from UEa. At step 42, the S-CSCF checks the SDP included in the INVITE message to determine the requested media type. The INVITE message indicates that the message is a request for communication session establishment.

[0056] At step 43, the S-CSCF obtains profile information for UEb comprising one or more C-numbers (UEcs), the type of communication session per UEc, and an indication (e.g., a flag) indicating transfer to C-number due to data transmission restriction is enabled.

[0057] Based on the profile information, the messages corresponding to an IMS communication session should be redirected/transferred to the provided C-number (UEc) destination address. The S-CSCF obtains the profilr information using one of the following methods:

[0058] Pushed by HSS

[0059] Queried from HSS

[0060] Provided by l-CSCF in the INVITE message

[0061] The information obtained by the S-CSCF may indicate that only

transfer of some type of communication session should be done, for instance video, sessions or file sharing sessions or whiteboard, i.e., high bandwidth sessions. If all types of communication session should be transferred including voice, then "all" type should be indicated in the information. The S- CSCF, at step 44 uses the obtained information i.e., transfer due to data transmission restriction enabled and the type of communication session to perform the sending step towards the UEc. If transfer due to data transmission restriction is enabled for UEb, and the type of communication session is video, the S-CSCF determines the type of communication session from the SDP. If SDP indicates video, the S-CSCF initiates the transfer by sending a second packet containing an INVITE message towards the UEc.

[0062] If transfer due to data transmission restriction is enabled for UEb, and the type of communication session is "all", the S-CSCF initiates the transfer of all OTT communication session messages regardless of the type to the UEc.

[0063] When data transmission restriction is lifted by the packet data network and the profile information for UEb is updated to indicate the transfer is disabled, the S-CSCF obtains the indication (inactivating the flag). When the transfer due data transmission restriction is inactivated, the S-CSCF resumes normal call delivery to UEb.

[0064] Figure 5 illustrates a method 50 for handling a transferred OTT

communication session and executing the transfer to a third UE (UEc) according to an embodiment. The method is executed at an application server, AS. The AS should support all well known OTT applications such as Skype, Facetime, Viber, Googletalk, Whatsapp, and the like. The AS also supports IMS. The AS should be able to convert between OTT applications and between OTT application and IMS. In method 50, the AS receives an OTT communication session establishment request forwarded by a network entity such as DPI. The communication session was initially to be established between a first user equipment and a second user equipment, however due to data transmission restriction enabled for the second user equipment, the DPI entity forwarded the packet to the AS for further processing and establishment of the session with a third user equipment instead. The third user equipment number/UEc is preconfigured in the AS as part of the second user equipment profile. The AS may also obtain the second user equipment profile information from an external database (e.g., HSS).

[0065] At step 51 , the AS execute the step of receiving the first message in a packet, where the message corresponds to an over the top, OTT, application request (e.g., Facetime, Googletalk, skype, and the like.) to establish a session from the first user equipment to a second user equipment. The Application server may be a dedicated server dedicated to transfer of sessions to C-numbers /third party numbers/ third users equipments/UEcs. Alternatively, the AS may be a generic communication service AS but have a dedicated port which would be used to receive messages that require automatic transfer treatment.

[0066] At step 52, the AS performs the step of determining the transfer-to- destination equipment/the third user equipment /UEc associated with the second user equipment. There may be more than one UEc configured per type of communication session, where the type indicates video, voice, whiteboard, file sharing, and other media type. Other data configured with UEc comprises the type of communication the UEc supports (video, voice, whiteboard, or "all"). At step 53, the AS execute the step of sending a second message for establishment of the communication session between the first user equipment and the UEc/transfer-to-destination equipment. The AS completes the session establishment between the first user equipment and the UEc. Once the session is established, the AS may be used to provide the media path between the first user equipment and the UEc or the AS may assign a media gateway if transcoding is required. Alternatively, the media path may be established directly between the first user equipment and the UEc if both support RTP and the same media codec.

[0067] The AS may be configured with the following additional data for the UEc: the type of OTT application supported by the UEc, including non-OTT such as IMS and the availability status of the UEc. If UEc and the first user equipment support the same OTT application and UEc is available, the AS at step 53 initiates sending of a second message towards the UEc for

establishment of the communication session between the first user equipment and the UEc also transfer-to-destination equipment.

[0068] If UEc and the first user equipment support different OTT application or UEc supports only SIP IMS, the AS performs protocol conversion from OTT application 1 to OTT application 2 or from OTT application to IMS and sends a second message containing a request message corresponding to OTT application 2 or a SIP INVITE towards the UEc for establishment of the communication session between the first user equipment and the UEc.

[0069] In one embodiment illustrated in Figure 6, a network entity (DPI 140) comprises a circuitry 1000 which executes the method steps according to the embodiments as described in Figure 2 along with steps 210, 220, 230 and in Figure 4 in addition to other embodiments described herein. In one

embodiment, the circuitry 1000 may comprise a processor 1001 and a storage 1002 (also referred to as memory) containing instructions, which when executed, cause the processor 1001 to perform the steps in a method according to embodiments described herein. The circuitry 1000 may further comprise a communication interface 1003 to communicate with the AS 150 for transfer of the communication session.

[0070] The network entity (DPI 140) according to some other embodiments of the present disclosure includes one or more modules, each of which is implemented in software. The module(s) provide the functionality of the DPI described herein.

[0071] Figure 6 also applies to a S-CSCF 160. The network entity (S-CSCF 160) comprises a circuitry 1000 which executes the method steps according to the embodiments as described in Figure 3 along with steps 320, 360, 370, 380 and 390, in Figure 4 in addition to other embodiments described herein. In one embodiment, the circuitry 1000 may comprise a processor 1001 and a storage 1002 (also referred to as memory) containing instructions, which when executed, cause the processor 1001 to perform the steps in a method according to embodiments described herein. The circuitry 1000 may further comprise a communication interface 1003 to communicate with the UEc 120, l-CSCF 170 and HSS 180 for transfer of the communication session to UEc 120.

[0072] The network entity (S-CSCF 160) according to some other

embodiments of the present disclosure includes one or more modules, each of which is implemented in software. The module(s) provide the functionality of the S-CSCF described herein.

[0073] Figure 6 also applies to a AS 150. The AS 150 comprises a circuitry 1000 which executes the method steps according to the embodiments as described in Figure 3 along with steps 230, 240, 250, 260, 270, in Figure 5 in addition to other embodiments described herein. In one embodiment, the circuitry 1000 may comprise a processor 1001 and a storage 1002 (also referred to as memory) containing instructions, which when executed, cause the processor 1001 to perform the steps in a method according to

embodiments described herein. The circuitry 1000 may further comprise a communication interface 1003 to communicate with the UEc 120 and DPI 140 for transfer of the communication session to UEc 120.

[0074] The application server 150 according to some other embodiments of the present disclosure includes one or more modules, each of which is implemented in software. The module(s) provide the functionality of the AS described herein.

[0075] Figure 7 illustrates an embodiment of the network entity (DPI 140 or S- CSCF 160) comprising a processing module 1 101 configured to receive via a communication module 1 103 a first packet for a first message. The

processing module 1 101 determines that the first message is an

establishment request for a communication session from a first user equipment to a second user equipment connected to a packet communication network and obtains information from the memory module 1 102 or from the communication module 1 103, where the information comprises a type of the communication session to transfer and an indication to transfer the

communication session over the communication module 1 103 due to data transmission restriction on the packet data network being enabled for the second user equipment. The processing module 1 101 then sends via the communication module 1 103, based on the information, a second packet comprising a second message for establishment of the communication session between the first user equipment and a third user equipment.

[0076] In some embodiments, a computer program including instructions

which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network entity (DPI 140 or S- CSCF 160) according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0077] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

Claims

What is claimed is:

1. A method of transferring a communication session, the method executed by a network entity and comprising:

- receiving a first packet for a first message;

- determining that the first message is an establishment request for a communication sessio from the first user equipment to a second user equipment connected to a packet communication network;

- obtaining information comprising

o an indication to transfer the communication session due to data transmission restriction on the packet data network being enabled for the second user equipment and

o a type of the communication session to transfer; and

- sending, based on the information, a second packet comprising a second message for establishment of the communication session between the first user equipment and a third user equipment.

2. The method of claim 1 , wherein the step of determining that the first message is an establishment request for a communication session further comprises inspecting the first packet to obtain information comprising at least one of first message protocol type, first message port number, first message type and the type of the communication session.

3. The method of claim 2, wherein the type of communication session is any of voice, video, whiteboard, fi!e sharing or all communication session,

4. The method of claim 1, wherein the first message and the second message are Session Initiation Protocol, SIP, messages,

5. The method of claim 1, wherein the first message and the second message are the same message and correspond to session messages of an Over-The-Top, OTT, application.

8. The method of claim 5, wherein the OTT application corresponds to at least one of a skype application, a google talk application, or a facetime application.

7. The method of claim 5 or 6, wherein the second packet comprises an identificatfon of the network entity indicating that the network entity should remain on a signaling path for all messages associated with the establishment and management of the communication session,

8. The method of claim 1 , wherein the data transmission restriction comprises data limit is reached.

9. The method of claim 1 , wherein the data transmission restriction comprises reduced network data speed.

10. A method of transferring a communication session from a first user equipment to a transfer-to destination equipment, the method executed by an application server and comprising:

- receiving a first message corresponding to an over the top, OTT, application, from an originating entity indicating a request for establishment of the communication session between the first user equipment and a second user equipment;

- determining the transfer-to-destination equipment for the

second user equipment based on type of communication session;

- sending a second message for establishment of the

communication session between the first user equipment and the transfer-to-destination equipment.

11. The method of claim 10, wherein the first message and the second message are of different protocol type.

12. The method of claim 11 , wherein the method further comprises protocol converting of the first message to the second message and protocol converting of subsequent messages associated with the communication session between the first user and the transfer-to- destination.

13. The method of claim 11 , wherein first protocol type of the first message corresponds to a protocoi of an over-the-top communication application and second protocol type of the second message corresponds to Session initiation Protocol.

14. The method of claim 10, wherein the type of communication session is at least one of voice, video and text communication session.

15. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 to 14,

16. A carrier containing the computer program of claim 15, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

17. A network entity comprising a circuitry configured to:

- receive a first packet for a first message;

- determine that the first message is an establishment request for a communication session from a first user equipment to a second user equipment connected to a packet communication network;

- obtain information that comprises

o a type of the communication session to transfer; and

- send, based on the information, a second packet comprising a second message for establishment of the communication session between the first user equipment and a third user equipment.

18. The network entity of claim 17, wherein the circuitry comprises a processor, a communication interface and a memory, the memory containing instructions executable by the processor,

19. The network entity of claim 17_» wherein the circuitry is further configured to inspect the first packet to obtain information comprising at least one of first message protocoi type, first message port number, first message type and the type of the communication session.

20. The network entity of claim 19, wherein the first message protocol type and protocol type of the second message correspond to a protocoi of an over-the-top communication application.

21. The network entity of claim 20, wherein the over-the-top

communication application corresponds to at least one of a skype application, a google talk application, or a facet) me application.

22. The network entit of claim 17, wherein the network entity

corresponds to a deep packet inspection network entity.

23. The network entity of claim 17, wherein the network entity is an Internet protocol multimedia subsystem, IMS, entity implementing a Call Session Control function, CSCF.