Patent Description:
In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or User Equipments (UE), communicate via a Wide Area Network or a Local Area Network such as a Wi-Fi network or a cellular network comprising a Radio Access Network (RAN) part and a Core Network (CN) part. The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in Fifth Generation (<NUM>) telecommunications. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.

3GPP is the standardization body for specify the standards for the cellular system evolution, e.g., including <NUM>, <NUM>, <NUM> and the future evolutions. Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (<NUM>) network, have been completed within the 3rd Generation Partnership Project (3GPP). As a continued network evolution, the new releases of 3GPP specifies a <NUM> network also referred to as <NUM> New Radio (NR).

Multi-antenna techniques can significantly increase the data rates and reliability of a wireless communication system. The performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. Such systems and/or related techniques are commonly referred to as MIMO.

In addition to faster peak Internet connection speeds, <NUM> planning aims at higher capacity than current <NUM>, allowing higher number of mobile broadband users per area unit, and allowing consumption of higher or unlimited data quantities in gigabyte per month and user. This would make it feasible for a large portion of the population to stream high-definition media many hours per day with their mobile devices, when out of reach of Wi-Fi hotspots. <NUM> research and development also aims at improved support of machine to machine communication, also known as the Internet of things, aiming at lower cost, lower battery consumption and lower latency than <NUM> equipment.

A legacy Private Branch Exchange (PBX) system is a centralized node in many company networks that deals with communication control logic from within the company and beyond. The PBX is responsible for all the call logic, such as call-waiting, forwarding, routing, etc., for both legs of a typical incoming business call: The call-waiting and subsequent routing to an available agent. A leg when used herein means the communication link between a user, e.g. customer or customer agent, and the PBX. More recent systems have adapted the Session Initiation Protocol (SIP) protocol for Voice over IP (VoIP) capability, allowing it to accept calls from any soft SIP client, e.g. referred to as SIP clients.

More specifically, a PBX acts as a SIP back-to-back user agent (B2BUA), segmenting calls between customers and customer agents, i.e. individuals within a business' branch exchange, into two call legs, a first call leg from the customer to the PBX and a second call leg from the PBX to the customer agent. A customer when used herein means the user calling the company. A customer agent when used herein e.g. means the company employee that will serve the customer. Typically, prior to routing a call to an agent, customers interact with an interactive voice responder by means of Dual-Tone Multi-Frequency (DTMF) tones. Routing decisions are often made after the customer has provided a set of options and some means of identification. Routing and queueing are based on logic residing within a PBX. After customers have responded to an Interactive Voice Response (IVR), they are either typically routed to a customer agent, or some form of automated service. This is when the second call leg is initiated. Once the customer agent has answered, the first call leg and the second call leg are merged by some logic within the PBX. This may e.g. be logic that transcodes voice, mixes media codecs etc. A subsequent interaction with either a customer agent or an automated service is performed over voice, as well as DTMF for the transfer of data from customer to business.

Most of the widely used PBX distributions, provide a Representational State Transfer (REST) interface in order to programmatically control the PBX functions, and allow for creation of customer applications. Such applications may play announcements on an incoming customer call leg, respond to DTMF choices made by an endpoint, merge multiple call legs into a conferencing bridge etc. A REST interface in the context of a PBX therefore enables developers to create custom communication application logic as per their requirements. An example of such a REST interface is the Asterisk Rest Interface (ARI), which provides access and control over all primitive Asterisk objects including channels, bridges, endpoints, and extensions. In fact, of all the PBX distributions available, Asterisk provides a most comprehensive API to create custom applications.

It is also worth noting that this API also allow a PBX to report events to a connected client, typically over WebSocket. A WebSocket is a communication protocol widely supported that allows a peer-to-peer exchange of text or binary data. It is also widely used in conjunction with the HTTP protocol to allow a Web server to send asynchronous data to the connected client. Therefore, as opposed to polling the REST interface for changes in state, the PBX is capable of reporting them as and when they happen.

Additionally, non-standard PBX solutions, also provide multi-language programming interfaces in Java, Perl etc. These APIs act very much like a REST API, providing total control over routing logic and call handling.

It should be noted that while most PBX distributions have a REST interface, it is by no means standardized across these distributions. Hence, the availability of functionality is dictated by how a given distribution implements its core features and abstracts objects. WP2016/<NUM> A1 discloses a method for establishing a data channel between a first communication terminal and a second communication terminal in the context of WebRTC.

As part of developing embodiments herein a problem was identified by the inventor and will first be discussed.

A recent adoption of a data channel in the Internet Protocol Multimedia Subsystem (IMS) media handling and interaction in the 3GPP specification <NUM> allows two UE users to use a UE application during a voice and/or video call. This opens new call interaction possibilities beyond voice and video. Playing games, sharing screen content etc. are now possible.

A problem is that legacy PBXs are lacking crucial functionality to provide enhanced calling features to UEs, both internally and externally. This since they do not support the peer-to-peer application media type used in a typical SIP Session Description Protocol (SDP), only audio and/or video. Even if data channels were to be supported, particular applications that the UEs choose would be very hard to implement within core PBX functionality. This may lead to more complex system implementations, resulting in a decreased flexibility of the wireless communications network.

An object of embodiments herein is to improve the flexibility of a communications network.

According to an aspect of embodiments herein, the object is achieved by a method performed by a gateway node arranged between an IMS network and a PBX node for enhancing a call session between a first User Equipment, UE, and a second UE in a communications network comprising the IMS network. The second UE is associated to a Private Branch Exchange, PBX, node.

When a call session has been established between the first UE and the second UE via the PBX node and via an Internet Protocol Multimedia Subsystem, IMS, network, the gateway node receives a request from any one out of the first UE and the second UE. The request is for establishing a data channel to enhance the call session.

After negotiating one or more parameters to be used in the requested data channel between the first UE and the second UE, the gateway node establishes the data channel according to the negotiation, to enhance the call session between the first UE and the second UE.

According to an another aspect of embodiments herein, the object is achieved by a method performed by a User Equipment, UE, for enhancing a call session between a first UE and a second UE in a communications network comprising an IMS network.

The second UE is associated to a Private Branch Exchange, PBX, node.

When a call session has been established between the first UE and the second UE via the PBX node and via an Internet Protocol Multimedia Subsystem, IMS, network, the UE sends a request to a gateway node, arranged between the IMS network and the PBX node. The request is for establishing a data channel to enhance the call session between the first UE and the second UE.

After negotiating one or more parameters to be used in the requested data channel, the UE establishes the requested data channel to enhance the call session between the first UE and the second UE. This is performed by using the negotiated one or more parameters.

According to an another aspect of embodiments herein, the object is achieved by a gateway node node, arranged between an IMS network and a PBX node and configured to enhance a call session between a first User Equipment, UE and a second UE in a communications network. network comprising the IMS network.

The second UE is adapted to be associated to a Private Branch Exchange, PBX, node. The gateway node is further configured to:.

According to an another aspect of embodiments herein, the object is achieved by a User Equipment, UE, configured to enhance a call session between a first UE and a second UE in a communications network comprising an IMS network.

The second UE is associated to a Private Branch Exchange, PBX, node. The UE is further configured to:.

Thanks to that the gateway node receives the request to establish the data channel when the call session between the first UE and the second UE has been established, it is possible for the gateway node to negotiate one or more parameter related to the requested data channel. The gateway node then establishes the data channel according to the negotiation. In this way an efficient mechanism for enhancing call sessions is achieved.

Embodiments herein bring the advantage of an efficient mechanism for enhancing a call sessions between a first UE and a second UE, where the second UE is associated to a PBX node. This is achieved by making it possible to establish a data channel to, e.g. by negotiating one or more parameters related to the data channel, and enhancing the call session by establishing the data channel according to the negotiation. This results in an improved flexibility in a communications network.

As a part of developing embodiments herein a problem was identified by the inventor and will be further discussed below.

Legacy PBXs are lacking crucial functionality to provide enriched calling features to UEs both internally and externally. They do not support the peer-to-peer application media type used in a typical SIP SDP; only audio and/or video. Also, legacy PBX call flows do not support the connection logic between the UE and Data Channel Server (DCS) for providing the application while most of the calls made to businesses must be transferred through an IVR menu to the final UE. Legacy PBXs do not have the flexibility to handle the retrieving and managing of more specific business applications either.

Even if data channels were to be supported, particular business applications that the consumer decides to choose would be very hard to implement within core PBX functionality. Even though applications like queuing are presently available, other company specific applications to be run in e.g. a browser would not be easily implementable within core PBX functionality, as these would need to be fetched from the DCS.

The data channel media types cannot be handled the same way as audio and video, which is done with the PBX acting as a SIP B2B UA, when external UEs are connected to UEs associated to the PBX. Instead, a peer-to-peer data channel connection need to be established directly between UE peers.

<FIG> shows a typical scenario when a caller <NUM> also referred to as customer <NUM> calls a business, such as a company. An IMS <NUM> relays the call from the caller <NUM>, to the business' PBX <NUM> that is SIP-compliant. The PBX <NUM> answers the call and provides the caller <NUM> with an IVR menu allowing the caller <NUM> to make a choice based on the services offered by the company. Based on the caller's <NUM> choice on the IVR menu, the PBX <NUM> then relays, or forwards, the call to one of the available agents <NUM>.

In this scenario, the call may either be voice-only or voice and video depending on the customer's <NUM> UE, the PBX <NUM> capabilities and the Agent's <NUM> equipment, e.g. normal phone or PC-based phone with Webcam. The Business WebApp the Agents use is separate from the voice call.

It is also desirable to use such interactivity between external UEs connected to UEs associated to the PBX. However, the new media type, i.e. the IMS data channel media type, used to establish the required connection is not supported in legacy equipment such as PBX, typically used in businesses.

According to some embodiments herein, in the context of Customer to Business Interactive calling, a gateway node such as a Data Channel Server Gateway (DCS GW), allows legacy PBXs to be compliant with Data Channel Media specifications from <NPL>".

It is possible to deploy embodiments of the gateway node in a remote server, so it doesn't need to be collocated with PBX.

Examples of embodiments herein provide PBXs with enriched, or enhanced, call-waiting and calling features by implementing a gateway node for data channel negotiation between a customer and customer agent, such as a first UE and a second UE.

Examples of embodiments herein enhances the legacy PBX with software that negotiates data channels as received in an SDP offer and/or answer. This software may also be able to fetch and/or run application logic relevant to the given customer, and exchange data over a peer-to-peer data channel with a customer. It is also capable of using data received from a customer to inform how to route and queue the customer in line to the appropriate customer agent. It is also able to exchange and/or forward portions of an SDP relevant to a given customer agent so that peer-to-peer data channels also may be established between a customer and a customer agent, such as the first UE and the second UE.

The data channel may then be used with a browser-based client application to provide the enriched call features.

Some embodiments herein also interact with a PBX by means of a REST interface, in order to control call function, play announcements on a given customer call leg, establish how many business endpoints are available to accept customer calls, subsequently manage how incoming customer calls are queued, create a second call leg between the PBX and the next available agent endpoint, and bridge the two call legs.

The REST interface may also have an event notification channel, typically over WebSocket, thereby notifying the gateway node when a new call has been established with a customer. This allows for the gateway node to associate a given call instance with the PBX's own record of this call instance. Other event notification messages may also point out when a given call instance is hung up, thereby allowing for a graceful hang up on any remaining call legs associated with a call instance. Also, the knowing of when a given endpoint hangs up may assist the gateway node and/or the PBX in maintaining a queue of customers waiting to be connected to the next available agent endpoint.

Given that the different PBX distributions have unique APIs/REST interfaces, interoperability between different distributions will be ensured by implementing a wrapper interface within the gateway node, with plugins for various PBX distributions. The wrapper will therefore provide common functionality between different distributions by calling on a plugin relevant to the distribution's programmable interface.

Embodiments herein may provide at least some of the below advantages:
Costly legacy PBX may still be used with modern enriched or enhanced calling, thus providing them a longer lifespan. The gateway node, along with the proper internal Web infrastructure, are all that is required to add enriched or enhanced calling features to a business', such as a company's, call handling system according to embodiments herein. There will not be any need to upgrade the PBX to support the data channel, also referred to as the IMS data channel. Any type of data may be securely exchanged in real time during the call.

The customer experience is improved by allowing enriched interactivity with a company during a call. This means that the customer may interact with a company in more ways than just voice and video. This opens the possibility for a whole host of applications that can be provided during a call.

Also, the addition of a data channel to an interactive voice responder and legacy PBX, as well as to a customer agent, will allow for a more focused and centralized support experience. Additionally, more sophisticated queuing and/or routing decisions can be made as more sophisticated data may be provided to the company's in an encrypted way.

Low latency requirements are also supported allowing, instead of sending a document over email, a customer to transfer a file within a call.

The company will also benefit from an improved customer support experience, increasing monetization and quality of service.

<FIG> shows a PBX, also referred to as PBX node <NUM> as shown in <FIG> but upgraded according to embodiments herein, to support enriched, or enhanced, calling by adding a gateway node <NUM> such as a DCS GW in the call path.

In an enriched or enhanced call to a business, such as a company, the caller, referred to as a first UE <NUM>, is presented with an Automatic Landing Page (ALP), such as an ALP application, where the first UE <NUM> may answer to some questions, such as provide data relevant to a call session, that will allow the transfer to a proper agent. Then, when transferred to an agent, referred to as a second UE <NUM>, a data channel established between the first UE <NUM> and the second UE <NUM> may be used to enhance the call, e.g. by enabling the first UE <NUM> and the second UE <NUM> exchange data in real-time, such as e.g. by an application running on the first UE <NUM> and the second UE <NUM>. Note that an application, unlike an IVR, may also be used to enhance calls in the reverse direction when an agent such as the second UE <NUM> calls a customer such as the first UE <NUM>.

, by placing the gateway node <NUM> such as the DCS GW between the IMS, referred to as IMS network <NUM>, and the PBX node <NUM>, the gateway node <NUM> terminates the data channel while allowing the PBX to continue receiving audio and/or video SIP signaling. By positioning the gateway node <NUM> in this manner, it is also capable of controlling how the PBX node <NUM> responds to incoming calls, and receives event notifications whenever there is a change of state from the PBX's node <NUM> perspective.

<FIG> is a schematic overview depicting a communications network <NUM> wherein embodiments herein may be implemented. The communications network <NUM> comprises one or more RANs and one or more CNs. The communications network <NUM> may use <NUM> NR but may further use a number of other different technologies, such as, Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

The communications network <NUM> further comprises an Internet Protocol (IP) Multimedia Subsystem (IMS) network <NUM>. The IMS network <NUM> is an architecture for delivering media content over an IP packet switched transport.

A number of network nodes operate in the communications network <NUM> such as e.g. a network node <NUM>. The network node <NUM> provides radio coverage in a number of cells which may also be referred to as a beam or a beam group of beams, such as a cell <NUM> provided by the network node <NUM>.

The network node <NUM> may be any of a NG-RAN node, a transmission and reception point e.g. a base station, a radio access network node such as a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), a gNB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of communicating with a wireless device within the service area served by the network node <NUM> depending e.g. on the first radio access technology and terminology used. The network node <NUM> may be referred to as a serving network node and communicates with UEs such as a UE <NUM>, <NUM>, <NUM>, a first UE <NUM> and a second UE <NUM>, with Downlink (DL) transmissions to the UEs <NUM>, <NUM>, <NUM> and in Uplink (UL) transmissions from the UEs <NUM>, <NUM>, <NUM>.

One or more UEs such as e.g. UEs <NUM>, <NUM>, <NUM>, operate in the communications network <NUM>. According to example scenarios herein, the UE <NUM> may be referred to as the first UE <NUM>, and the UE <NUM> may be referred to as the second UE <NUM>. The UEs <NUM>, <NUM>, <NUM> may e.g. each be a wireless device, an NR device, a mobile station, a wireless terminal, an NB-loT device, an MTC device, an eMTC device, a CAT-M device, a WiFi device, an LTE device and an a non-access point (non-AP) STA, a STA, that communicates via one or more Access Networks (AN), e.g. a RAN, to one or more core networks (CN). It should be understood by the skilled in the art that "UE" is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a car or any small base station communicating within a cell.

The gateway node <NUM> operates in the communications network <NUM>. The gateway node <NUM> may be a DCS GW. The gateway node <NUM> may be used for negotiating and establishing data channels for enhancing call sessions between e.g. the first UE <NUM> and the second UE <NUM>.

The communications network <NUM> may further comprise a PBX node <NUM>. The PBX node <NUM> may be a PBX, and may be used for providing functions such as switching, queuing and managing incoming and outgoing call sessions.

Methods according to embodiments herein are performed by the gateway node <NUM> and the UE <NUM>, <NUM>, <NUM>. These nodes may be Distributed Nodes (DN)s and functionality, e.g. comprised in a cloud <NUM> as shown in <FIG> may be used for performing or partly performing the methods.

<FIG> shows a schematic overview of a communications network according to an example scenario wherein embodiments herein may be applied. Communication is performed over different protocols, such as SIP, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol (IP), Real Time Protocol (RTP) and WebSocket. The communications network comprises one or more nodes, such as the gateway node <NUM>. The communications network further comprises the PBX node <NUM> and the IMS network <NUM>. The gateway node <NUM> may communicate with the PBX node <NUM>. The gateway node <NUM> may further communicate with the first UE <NUM> through the IMS network <NUM>, and with the second UE <NUM>. SIP signals when establishing a call session between the first UE <NUM> and the second UE <NUM>, may pass through the gateway node <NUM> and the PBX node <NUM> that the second UE <NUM> is associated to. In order to enhance the call session between the first UE <NUM> and the second UE <NUM>, the gateway node <NUM> needs to establish a data channel that enhances the call session, and to negotiate parameters related to the data channel.

A number of embodiments will now be described, some of which may be seen as alternatives, while some may be used in combination.

The method according to embodiments will now be described from the view of the gateway node <NUM> together with <FIG> depicts example embodiments of a method performed by the gateway node <NUM> for enhancing a call session between the first UE <NUM> and the second UE <NUM> in the communications network <NUM>. The second UE <NUM> is associated to the PBX, node <NUM>. This may mean that incoming and outgoing call session for the second UE <NUM>, pass through, and is controlled by, the PBX node <NUM>.

The first UE <NUM> may e.g. be a customer, and the second UE <NUM> may e.g. be an agent. In the method, a call session, a first data channel and a data channel, e.g. an IMS data channel, will be set up. The first UE <NUM> may support a data channel e.g. an IMS data channel which will be used for enhancing the call session. An IMS data channel when used herein may mean a data channel, such as a transport medium, established between two peers, such as two UEs, e.g. the first UE <NUM> and the second UE <NUM>, in order to allow for full duplex exchange of arbitrary data. The data channel's characteristics, such as e.g. quality of service and bandwidth, are requested for by either UE, such as e.g. the first UE <NUM> and/or the second UE <NUM>, and provisioned by the IMS network <NUM>. An IMS data channel when used herein may further mean an application type media entry in an SDP that is used to transport the data channel. The IMS data channel may be according to Data Channel Media specifications from 3GPP TS26. <NUM> "IP Multimedia Subsystem (IMS);Multimedia telephony; Media handling and interaction". Any one out of the first UE <NUM> and the second UE <NUM>, may be compliant with, such as support, Data Channel Media specifications from <NPL>".

Enhancing the call session may e.g. be referred to as enriching the call session. The method comprises the following actions, which actions may be taken in any suitable order. Actions that are optional are presented in dashed boxes in <FIG>.

In some embodiments, the gateway node <NUM> receives a request from any one out of the first UE <NUM> and the second UE <NUM>. The request requests to establish the call session between the first UE <NUM> and the second UE <NUM>. The request to establish the call session between the first UE <NUM> and the second UE <NUM> may be a SIP message, such as e.g. a SIP invite message, and may be received via the IMS network <NUM>.

When the request to establish the call session is received from the first UE <NUM>, the gateway node <NUM> may send, such as e.g. forward, the request to the PBX node <NUM>. When receiving an accept message from the PBX node <NUM>, the gateway node <NUM> may in some embodiments, send such as e.g. forward, the received accept message to the first UE <NUM>. This may be in order to establish the first call session between the first UE <NUM> and the PBX node <NUM>. The accept message may be a SIP message, such as e.g. a SIP <NUM> OK message, and may be sent, such as forwarded to the first UE <NUM> via the IMS network <NUM>. The first call session may be referred to as a first call leg. A SIP <NUM> OK message is a response message to a SIP request message, such as e.g. a SIP invite message. A SIP <NUM> OK message indicates acceptance of the received SIP request message.

When the first call session between the first UE <NUM> and the PBX node <NUM>, has been established, the gateway node <NUM> may receive an indication from the first UE <NUM> indicating that the first UE <NUM> accepts the requested call session to be enhanced.

In some embodiments, the indication indicating the that the first UE <NUM> accepts the requested call session to be enhanced, is received by the gateway node <NUM> in response to an indication sent by the gateway node <NUM> to the first UE <NUM>. The indication instructs the first UE <NUM> to indicate to the gateway node <NUM> whether or not the first UE <NUM> accepts the requested call session between the first UE <NUM> and the second UE <NUM> to be enhanced.

Enhancing the call session when used herein, may mean that the call session is enhanced by the establishment of a data channel between the first UE <NUM> and the second UE <NUM>. The data channel may allow the first UE <NUM> and the second UE <NUM> to exchange, such as e.g. send and receive, data related to the call session in real-time during the call session.

A first data channel between the gateway node <NUM> and the first UE <NUM> may allow the gateway node <NUM> to communicate and exchange data related to a call session requested to be established.

In some embodiments, the gateway node <NUM> has received the request for establishing the call session between the first UE <NUM> and the second UE <NUM> from the first UE <NUM>. When receiving from the first UE <NUM>, a request to establish a first data channel between the first UE <NUM> and gateway node <NUM>, the gateway node <NUM> establishes the first data channel between the first UE <NUM> and the gateway node <NUM>.

In some embodiments, the gateway node <NUM> establishes the first data channel between the gateway node <NUM> and the first UE <NUM> by receiving the request, from the first UE <NUM>, to establish a the first data channel between the gateway node <NUM> and the first UE <NUM>. The request may be a SIP message, such as e.g. a SIP invite message or an SIP re-invite message, and may be received via the IMS network <NUM>. In response to the received request, the gateway node <NUM> may send an accept message associated to the received request to the first UE <NUM> to establish the first data channel. The accept message indicates to the first UE <NUM> that the gateway node <NUM> accepts the request to establish the first data channel. The accept message may be SIP message, such as e.g. a SIP <NUM> OK message, and may be sent via the IMS network <NUM>.

In some embodiments, the gateway node <NUM> obtains data related to the call session between the first UE <NUM> and the second UE <NUM> using the first data channel. The obtained data may e.g. comprise any one or more out of: subscription data, such as subscription type, an identity of the first UE <NUM>, personal information, any data pertaining to the reason of the call session.

The obtained data may be used by the gateway node <NUM> when establishing the call session between the first UE <NUM> and the second UE <NUM>.

For the call session to be established, the second UE <NUM> need to be available.

So, in some embodiments, upon the second UE <NUM> becoming available, the gateway node <NUM> establishes the call session between the first UE <NUM> and the second UE <NUM>. The gateway node <NUM> may establish the call session by instructing the PBX node <NUM> to connect the first call session between the first UE <NUM> and the PBX node <NUM> with a second call session established between the second UE <NUM> and the PBX node <NUM>. The second call session may be referred to as a second call leg. The gateway node <NUM> may become aware, such as e.g. be informed, that the second UE <NUM> is available by receiving an indication from the PBX node <NUM>. The indication may indicate that the second UE <NUM> is available. The call session, when established, may enable, also referred to as support, transmissions, such as sending and/or receiving audio and/or video between the first UE <NUM> and the second UE <NUM>. This may mean that first UE <NUM> and the second UE <NUM> are able to exchange audio and/or video media.

In some embodiments, the gateway node <NUM> indicates to the first UE <NUM> that the second UE <NUM> has become available. The PBX node <NUM> may be instructed when the gateway node <NUM> receives a request from the first UE <NUM> to be connected to the second UE <NUM>. The request to be connected to the second UE <NUM> may be received from the first UE <NUM> in response to the indication that the second UE <NUM> has become available. The gateway node <NUM> may indicate the availability of the second UE <NUM> to the first UE <NUM> by using the established first data channel.

The established call session between the first UE <NUM> and the second UE <NUM> may be based on the obtained data related to the call session between the first UE <NUM> and the second UE <NUM>.

The established call session between the first UE <NUM> and the second UE <NUM> supports audio and/or video transmissions. In order to enhance the call session, a data channel according to embodiments herein will be established.

When the call session has been established between the first UE <NUM> and the second UE <NUM> via the PBX node <NUM> and via the IMS network <NUM>, the gateway node <NUM> receives a request from any one out of the first UE <NUM> and the second UE <NUM>. The request is for establishing a data channel between the first UE <NUM> and the second UE <NUM> to enhance the call session. The data channel may enhance the call session by supporting, such as e.g. enabling, transmissions of data between the first UE <NUM> and the second UE <NUM>. The data may be may be a kind of data that is different from transmissions supported by a call session, such as the established call session, when it is not enhanced. The kind of data transmitted over the data channel when established may e.g. be data such as exchanging a digital file and the associated messages required to control such exchange, screen sharing between the first UE <NUM> and the second UE <NUM> or data enabling the second <NUM> to remotely control the first UE <NUM>.

The received request may be a SIP message, such as e.g. an invite message or a re-invite message. The request to establish the data connection may comprise one or more first parameters related to the data channel to enhance the call session. The data channel may be an IMS data channel.

To enhance the established call session between the first UE <NUM> and the second UE <NUM>, a second data channel according to embodiments herein will be established. The second data channel is referred to as the data channel when described herein.

To establish the data channel to enhance the established call session between the first UE <NUM> and the second UE <NUM>, one or more parameters related to the data channel will be negotiated and accepted.

The gateway node <NUM> negotiates the one or more parameters to be used in the requested data channel between the first UE <NUM> and the second UE <NUM>.

In some embodiments, the gateway node <NUM> negotiates the parameters to be used in the requested data channel by sending, to the second UE <NUM>, one or more first parameters related to the requested data channel. The one or more first parameters are accepted by the first UE <NUM> and are obtained from the received request for establishing the data channel.

As mentioned above, the request to establish the data channel may comprise the one or more first parameters. Thus, the gateway node <NUM> may obtain, e.g. extract, the one or more first parameters from the received request. The one or more first parameters may be comprised in a message such as an SDP message, wherein the one or more first parameters are data channel media entries in the SDP message. The SDP message may be an SDP offer. The one or more first parameters may be sent to the second UE <NUM> via a connection established between the gateway node <NUM> and the second UE <NUM>. The connection may be a WebSocket connection.

To conclude the negotiation, the gateway node <NUM> may receive one or more second parameters related to the requested data channel from the second UE <NUM>. The one or more second parameters are referred to as the one or more parameters when described herein The one or more parameters may be received via the established connection between the gateway node <NUM> and the second UE <NUM>, e.g. the third data channel. Therefore, in some embodiments, when receiving, from the second UE <NUM>, the one or more parameters related to the requested data channel, which one or more parameters are accepted by the second UE <NUM> based on the one or more first parameters accepted by the first UE <NUM>, the gateway node <NUM> sends an accept message to the first UE <NUM>. The accept message indicates that the second UE <NUM> accepts the request to establish the data channel. The accept message comprises the one or more parameters. The accept message may be a SIP message, such as e.g. a <NUM> OK message. Similarly as for the one or more first parameters, the one or more parameters may be comprised in a SDP message, wherein the one or more parameters are data channel media entries in the SDP message. The SDP message may be an SDP answer that is sent to the first UE <NUM> in the accept message.

In some embodiments, responsive to receiving the one or more parameters from the second UE <NUM>, the gateway node <NUM> sends the obtained data related to the call session to the second UE <NUM>. The obtained data may be sent via a connection established between the gateway node <NUM> and the second UE <NUM>, such as e.g. a WebSocket connection.

When the one or more parameters related to the data channel has been negotiated, the gateway node <NUM> assists in establishes the data channel.

The gateway node <NUM> establishes the data channel according to the negotiation, to enhance the call session between the first UE <NUM> and the second UE <NUM>. The call session is enhanced by the establishment of the data channel between the first UE <NUM> and the second UE <NUM>, allowing the first UE <NUM> and the second UE <NUM> to exchange, such as e.g. send and receive, data related to the call session. Establishing the data channel when used herein, may mean that the gateway node <NUM> assists in establishing the data channel.

In other words, the call session between two UEs, where one of the UEs <NUM>, <NUM> is associated to the PBX node <NUM>, is enhanced by establishing the data channel. The data channel allows transmissions such as e.g. exchanging, sending and/or receiving, of data related to the call session between the two UEs. This is an advantage since it improves the flexibility of the communications network. further, the gateway node <NUM> is not involved in the data channel content, such as the data transmitted using the data channel, rather the gateway node <NUM> is only involved in, such as being part of, the establishment of the data channel. This, reduces the latency of the data channel communications.

The data channel to enhance the call session is established based on the one or more parameters.

In some embodiments, the data channel between the first UE <NUM> and the second UE <NUM> is represented by a peer-to-peer data channel bypassing the PBX node <NUM>.

The method according to embodiments will now be described from the view of the UE <NUM>, <NUM>, <NUM> together with <FIG> depicts example embodiments of a method performed by a UE <NUM>, <NUM>, <NUM> for enhancing a call session between a first UE <NUM> and a second UE <NUM> in a communications network <NUM>. In the method, a call session, a first data channel and a data channel, e.g. an IMS data channel, will be set up. As mentioned above, the first UE <NUM> may e.g. be a customer, and the second UE <NUM> may e.g. be an agent. Enhancing the call session may e.g. be referred to as enriching the call session.

The second UE <NUM> is associated to a PBX <NUM>. This may mean that incoming and outgoing call session for the second UE <NUM>, pass through, and is controlled by, the PBX node <NUM>.

The UE <NUM>, <NUM>, <NUM> may be represented by any one out of the first UE <NUM> and the second UE <NUM>. The first UE <NUM> supports a data channel e.g. an IMS data channel, which will be used for enhancing the call session. An IMS data channel when used herein may mean An IMS data channel when used herein may mean a data channel, such as a transport medium, established between two peers, such as two UEs, e.g. the first UE <NUM> and the second UE <NUM>, in order to allow for full duplex exchange of arbitrary data. The data channel's characteristics, such as e.g. quality of service and bandwidth, are requested for by either UE, such as e.g. the first UE <NUM> and/or the second UE <NUM>, and provisioned by the IMS network <NUM>. An IMS data channel when used herein may further mean an application type media entry in an SDP that is used to transport the data channel. The IMS data channel may be according to Data Channel Media specifications from <NPL>". Enhancing the call session may e.g. be referred to as enriching the call session. The UE <NUM>, <NUM>, <NUM>, such as e.g. any one out of the first UE <NUM> and the second UE <NUM>, may be compliant with, such as support, Data Channel Media specifications from <NPL>".

The method comprises the following actions, which actions may be taken in any suitable order. Actions that are optional are presented in dashed boxes in <FIG>.

In some embodiments, the UE <NUM>, <NUM>, <NUM> sends a request to the gateway node <NUM>. The request is to establish the call session between the first UE <NUM> and the second UE <NUM>.

When the UE <NUM>, <NUM>, <NUM> is represented by the first UE <NUM>, the first UE <NUM> may receive an accept message from the gateway node <NUM>, in order to establish the first call session between the first UE <NUM> and the PBX node <NUM>. The accept message may be a SIP message, such as e.g. a <NUM> OK message, and may be sent, such as forwarded to the first UE <NUM> via the IMS network <NUM>. The first call session may be referred to as a first call leg.

When the UE <NUM>, <NUM>, <NUM> is represented by the first UE <NUM>, and when the first call session between the first UE <NUM> and the PBX node <NUM> has been established, the first UE <NUM> may send, to the gateway node <NUM>, an indication indicating that the first UE <NUM> accepts the call session to be enhanced.

In some embodiments, the indication indicating that the first UE <NUM> accepts the call session to be enhanced, is sent to the gateway node <NUM> in response to receiving an indication from the gateway node <NUM>. The indication instructs the first UE <NUM> to indicate to the gateway node <NUM> whether or not the first UE <NUM> accepts the call session between the first UE <NUM> and the second UE <NUM> to be enhanced. The first UE <NUM>.

As mentioned above, enhancing, such as enriching, the call session when used herein, may mean that the call session is enhanced by the establishment of a data channel between the first UE <NUM> and the second UE <NUM>. The data channel may allow the first UE <NUM> and the second UE <NUM> to exchange, such as e.g. send and receive, data related to the call session.

A first data channel between the gateway node <NUM> and the first UE <NUM> allows the gateway node <NUM> to communicate and exchange data related to the call session requested to be established.

Therefore, in some embodiment, when the UE <NUM>, <NUM>, <NUM> is represented by the first UE <NUM>, the first UE <NUM> sends to the gateway node <NUM>, a request to establish a first data channel between the first UE <NUM> and gateway node <NUM>. The request may be a SIP message, such as e.g. an SIP invite message or an SIP re-invite message, and may be sent via the IMS network <NUM>.

In response to the sent request, the first UE <NUM> may receive an accept message from the gateway node <NUM>. The accept message is associated with the sent request to establish the first data channel. The accept message indicates to the first UE <NUM> that the gateway node <NUM> accepts the request to establish the first data channel. The accept message may be SIP message, such as e.g. a SIP <NUM> OK message, and may be sent via the IMS network <NUM>.

In some embodiment, when the first data channel between the first UE <NUM> and the gateway node <NUM> has been established, the first UE <NUM> provides data related to the call session between the first UE <NUM> and the second UE <NUM> using the first data channel.

The provided data may e.g. comprise subscription data, such as subscription type, an identity of the first UE <NUM>, personal information, any data pertaining to the reason of the call session. The provided data related to the call session may be used by the gateway node <NUM> when establishing the call session between the first UE <NUM> and the second UE <NUM>.

To establish the call session, when the first UE <NUM> has requested the call session, the second UE <NUM> needs to be available.

In some embodiments, when the UE <NUM>, <NUM>, <NUM> is represented by the first UE <NUM>, the establishing of the call session comprises that the first UE <NUM> receives an indication from the gateway node <NUM>. The indication indicates that the second UE <NUM> has become available. The first UE <NUM> may then send a request to the gateway node <NUM>. The request is to be connected to the second UE <NUM>. The first UE <NUM> may receive the indication from the gateway node <NUM>, that the call session between the first UE <NUM> and the second UE <NUM> is requested to be established.

According to an example scenario, while waiting for the second UE <NUM> to become available, the first UE <NUM> may have been placed in a queue. The queue may e.g. be managed by any one out the gateway node <NUM> and the PBX node <NUM>.

The established call session between the first UE <NUM> and the second UE <NUM> may be based on the provided data related to the call session between the first UE <NUM> and the second UE <NUM>.

The established call session between the first UE <NUM> and the second UE <NUM> supports audio and/or video transmissions. In order to enhance the call session, a second data channel according to embodiments herein will be established. The second data channel is referred to as the data channel when described herein.

When the call session has been established between the first UE <NUM> and the second UE <NUM> via the PBX node <NUM> and via the IMS network <NUM>, the UE <NUM>, <NUM>, <NUM> sends a request to the gateway node <NUM>. The request is for establishing a data channel to enhance the call session between the first UE <NUM> and the second UE <NUM>. The data channel may enhance the call session by supporting, such as e.g. enabling, transmissions of data between the first UE <NUM> and the second UE <NUM>. The data may be a kind of data that is different from transmissions supported by the established call session when not being enhanced. The kind of data transmitted over the data channel when established may e.g. be data such as exchanging a digital file and the associated messages required to control such exchange, screen sharing between the first UE <NUM> and the second UE <NUM> or data enabling the second <NUM> to remotely control the first UE <NUM>. The data channel may be an IMS data channel. The sent request may be a SIP message, such as e.g. an invite message or a re-invite message.

In some embodiments, the request to establish the data channel comprises one or more first parameters related to the requested data channel. The one or more first parameters may be accepted by the first UE <NUM>.

As mentioned above, the one or more first parameters may be comprised in a SDP message, wherein the one or more first parameters are data channel media entries in the SDP message. The SDP message may be an SDP offer.

To establish a data channel to enhance the established call session between the first UE <NUM> and the second UE <NUM>, parameters related to the data channel will be negotiated and accepted.

The UE <NUM>, <NUM>, <NUM> negotiates one or more parameters to be used in the requested data channel.

In some embodiments, the negotiating of the one or more parameters to be used in the requested data channel comprises, i.e. is performed by, the first UE <NUM> receiving an accept message from the gateway node <NUM>. The accept message indicates that the second UE <NUM> accepts the request to establish the data channel. The accept message comprises the one or more parameters related to the requested data channel. The one or more parameters are accepted by the second UE <NUM> based on the one or more first parameters accepted by the first UE <NUM> These one or more parameters based on the one or more first parameters, are also referred to as the one or more second parameters when described herein. The accept message may be a SIP message, such as e.g. a <NUM> OK message. Similarly as for the one or more first parameters, the one or more parameters may be comprised in an SDP message, wherein the one or more parameters are data channel media entries in the SDP message. The SDP message may be an SDP answer that is sent to the first UE <NUM> in the accept message.

In some embodiments, the one or more first parameters may be one or first parameters accepted by the second UE <NUM>. when the one or more first parameters are one or more first parameters accepted by the second UE <NUM>, the negotiating of the one or more parameters to be used in the requested data channel comprises second UE <NUM> receiving, from the gateway node <NUM>, an accept message. The accept message indicates that the first UE <NUM> accepts the request to establish the data channel. The accept message comprises one or more parameters related to the requested data channel. The one or more parameters are accepted by the first UE <NUM> based on the one or more first parameters accepted by the second UE <NUM>. The one or more parameters may be sent to the second UE <NUM> via the connection established between the gateway node <NUM> and the second UE <NUM>. The connection may be a WebSocket connection.

When the one or more parameters related to the data channel has been negotiated, the UE <NUM>, <NUM>, <NUM> establishes the data channel.

The UE <NUM>, <NUM>, <NUM> establishes the requested data channel to enhance the call session between the first UE <NUM> and the second UE <NUM>, using the negotiated one or more parameters.

In other words, a call session between two UEs, where one of the UEs is associated to a PBX, is enhanced by establishing a data channel. The data channel allows transmissions such as e.g. exchanging, sending and/or receiving, of data related to the call session between the two UEs. This is an advantage since it improves the flexibility of the communications network. further, the gateway node <NUM> is not involved in the data channel content, such as the data transmitted using the data channel, rather the gateway node <NUM> is only involved in, such as being part of, the establishment of the data channel. This, reduces the latency of the data channel communications.

The data channel to enhance the call session is may be established based on the one or more parameters.

Actions S501-S508 are related to an initial call establishment depicted in <FIG>,.

Actions S509-S514 are related to establishment of a data channel depicted in <FIG>,.

Actions S515-S523 are related to establishing the call session depicted in <FIG>,.

Actions S524-S534 are related to establishing the data channel to enhance the call session depicted in <FIG>.

Actions S535-S541 are related to establishing the call session, when the call session is requested by the second UE <NUM> depicted in <FIG>.

These methods depict examples of detailed actions according to embodiments herein. In the <FIG> the gateway node <NUM> is referred to as DCS GW <NUM>, the PBX node <NUM> is referred to as PBX <NUM>, the first UE <NUM> is referred to as UE <NUM> and the second UE <NUM> is referred to as UE <NUM>.

The actions may be taken in any suitable order. Some actions are new according to embodiments herein and are marked so, and some steps are performed according prior art.

Actions S1a-S8a are related to an example of an initial call establishment and will be described below.

The DCS GW <NUM>, such as e.g. the gateway node <NUM>, may receive a SIP invite message, such as e.g. the request to establish the call session between the first UE <NUM> and the second UE <NUM>, wherein the second UE <NUM> is associated to the PBX node <NUM>, from the UE <NUM>, such as e.g. the first UE <NUM>.

This step is associated to Actions <NUM> and <NUM> described above.

The DCS GW <NUM> may extract data channel media entries from the incoming message before passing it to the PBX <NUM>, such as e.g. the PBX node <NUM>.

This step is associated to Action <NUM> described above.

While the PBX <NUM> handles the SIP invite message and answers the call, the DCS GW <NUM> may initiate a data channel connection to the DCS using the extracted data channel media entries.

At the same time, the PBX <NUM> may inform the DCS GW <NUM> of a newly established call leg, such as the first call session, allowing for association of the call instance in the DCS GW <NUM> with that of the PBX <NUM>.

The DCS GW <NUM> may then requests the PBX <NUM> to play a welcome message on the newly established call leg, such as e.g. the first call session, via an interface between the DCS GW <NUM> and the PBX <NUM>.

The PBX <NUM> may respond to the SIP invite message with a SIP <NUM> OK message.

The DCS GW <NUM> may add an SDP answer, e.g. data channel media entries accepted by the DCS GW <NUM> for the data channel, to the received SIP <NUM> OK.

The DCS GW <NUM> may forward the response, such as the SIP <NUM> OK, back to the IMS, such as the IMS network <NUM>, and in the end the UE <NUM> so that the call, such as the first call session, can be established. When the call, such as e.g. the first call session, is established, the UE <NUM> may receive an indication instructing the UE <NUM> to indicate whether or not the UE <NUM> accepts the requested call session to be enhanced, such as enriched. If the UE <NUM> declines, legacy procedures for a call session with a UE <NUM>, such as e.g. the second UE <NUM>, associated to the PBX <NUM> may be used. If the UE <NUM> accepts, procedures to enhance the requested call session may be initiated.

This step is associated to Actions <NUM>-<NUM> and <NUM>-<NUM> described above.

Actions <NUM>-<NUM> are related to an example of an establishment of a data channel and will be described below.

When the call, such as e.g. the first call session between the first UE <NUM> and the PBX node <NUM>, is established and the UE <NUM>, such as e.g. the first UE <NUM>, has accepted an enhanced call session, the UE <NUM> may fetch, such as obtain, an application providing ALP from the DCS.

The UE <NUM> may send a SIP re-invite message, such as e.g. the request to establish the first data channel, to the IMS, such as e.g. the IMS network <NUM>, to establish the connection, such as e.g. the first data channel, between the UE <NUM> ALP application and the DCS GW <NUM>, such as e.g. the gateway node <NUM>. The DCS GW <NUM> receives may receive the SIP re-invite message from the IMS <NUM>. In another example scenario, DCS GW <NUM> may initiate establishing the first data channel by sending the SIP re-invite message, such as e.g. the request to establish the first data channel, to the UE <NUM> via the IMS <NUM>.

At the same time, the DCS GW <NUM> may receive, such as obtain, the corresponding ALP data based on the PBX <NUM> profile in the IMS and the DCS repository. The data may contain any type of data, such as e.g. information about the UE <NUM> or customized codes.

The DCS GW <NUM> may intercept the SIP message, such as e.g. the request to establish the first data channel, and extract data channel media entries related to the first data channel from the incoming message before passing it to the PBX <NUM>. The DCS GW <NUM> may receive a response, e.g. a SIP <NUM> OK, from the PBX <NUM>.

The DCS GW <NUM> may create the data channel, such as the first data channel, for the ALP and may respond to the UE <NUM> with a SIP <NUM> OK so the connection can be established between the two applications, such as the gateway node <NUM> and the first UE <NUM>. The DCS GW <NUM> may add an SDP answer, e.g. data channel media entries accepted by the DCS GW <NUM>, for the first data channel to the SIP <NUM> OK. In the example scenario mentioned above where the DCS GW <NUM> initiates the first data channel, the DCS GW <NUM> may create the data channel, such as the first data channel, for the ALP when receiving a response, such as a SIP <NUM> OK, from the UE <NUM>.

The UE <NUM> may provide data related to the requested call session using established data channel, such as e.g. the first data channel. The data may be provided through the obtained ALP application. The DCS GW <NUM> may obtain the provided data. The UE <NUM> may be placed in a queue until the UE <NUM>, such as the second UE <NUM>, is available. The queue may be managed by the DCS GW <NUM> based on events reported by the PBX <NUM>. The events may be e.g. that the UE <NUM> has become available. The UE <NUM> may be indicated a priority in the waiting queue, and the queue may be updated as and when the PBX <NUM> reports changes in state with respect to e.g. previous call sessions.

This step is associated to Actions <NUM> and <NUM> described above.

Actions S515-S523 are related to establishing the call session and will be described below.

When the UE <NUM>, such as e.g. the second UE <NUM>, has become available, the PBX <NUM>, such as e.g. the PBX node <NUM>, may inform, such as indicate to, the DCS GW <NUM>, such as e.g. the gateway node <NUM>, of the event.

The DCS GW <NUM> may indicate to the UE <NUM>, such as e.g. the first UE <NUM>, that the UE <NUM> has become available.

The UE <NUM> may send a request to be connected to the UE <NUM>.

The DCS GW <NUM> may send a request to the PBX <NUM> to establish a connection, such as e.g. the second call session, to the UE <NUM>. The second call session may be referred to as the second call leg.

The PBX <NUM> may establish the connection, or second call leg, such as e.g. the second call session, between the UE <NUM> and the PBX <NUM>.

The PBX <NUM> may report an identity associated to the connection, or second call leg, such as the second call session, to the DCS GW <NUM>.

The PBX <NUM> may be instructed by the DCS GW <NUM> to establish the call session between the UE <NUM> and the UE <NUM> by e.g. connecting the first call session with the second call session. The instructing may be sent to the PBX <NUM> via the interface between the DCS GW <NUM> and the PBX <NUM>. Upon receiving the instruction, the PBX <NUM> may connect, such as establish the second call session, to the UE <NUM>. The PBX <NUM> may bridge, such as connect, the first call leg, such as the first call session with the second call leg, such as the second call session.

The UE <NUM> may establish a connection to the DCS GW <NUM>. The connection may be a WebSocket comprising a third data channel. The UE <NUM> may register with an identity, such as e.g. an agent identity.

The DCS GW <NUM> may inform, such as indicate, to the UE <NUM> that call session with the UE <NUM> is established.

Actions S524-S534 are related to establishing the data channel to enhance the call session and will be described below.

The UE <NUM>, such as e.g. the first UE <NUM>, may fetch, such as obtain, an application from the DCS. The application may be related to the PBX <NUM>, such as e.g. the PBX node <NUM>.

The UE <NUM> may sends a SIP re-invite message, such as e.g. the request to establish the data channel to enhance the call session between the first UE <NUM> and the second UE <NUM>, such as e.g. the second UE <NUM>, to the DCS GW <NUM> such as e.g. the gateway node <NUM>. The SIP re-invite message requests the data channel to enhance the call session to be established.

The DCS GW <NUM> may receive, such as obtain, the application from the DCS. The DCS GW <NUM> may update a Web server that hosts the UE <NUM> application, such as e.g. browser page, in order for it be customizable.

Upon receiving the SIP re-invite, such as e.g. the request to establish the data channel, the DCS GW <NUM> may extract, such as obtain, the data channel media entry, such as e.g. the one or more first parameters related to the requested data channel, from an SDP offer comprised in the received SIP re-invite.

The DCS GW <NUM> may forward the SIP re-invite to the PBX <NUM> without the extracted data channel media entries.

The DCS GW <NUM> may receive a SIP <NUM> OK message, such as an accept message, from the PBX <NUM>.

The DCS GW <NUM> may send the extracted data channel media entries, such as e.g. the one or more first parameters, to the UE <NUM>. The extracted data channel media entries may be an SDP offer.

The UE <NUM> may respond with an SDP answer, comprising data channel media entries, such as the one or more parameters related to the requested data channel that is accepted by the second UE <NUM>. The UE <NUM> may apply the data channel media entries to the requested data channel.

The DCS GW <NUM> may send the obtained data related to the call session to the UE <NUM>.

The DCS GW <NUM> may send the SDP answer, such as e.g. the one or more parameters related requested data channel, to the UE <NUM>. The SDP answer may be sent in an accept message, such as e.g. a SIP <NUM> OK message.

Upon receiving the accept message, UE <NUM> may apply the incoming SDP answer, such as e.g. the one or more parameters related to the requested data channel, and the data channel is established between the UE <NUM> and UE <NUM>.

Actions S535-S541 are related to establishing the call session, when the call session is requested by the second UE <NUM> and will be described below.

In this scenario, the UE <NUM>, such as the second UE <NUM>, may request the call session to be established between the UE <NUM>, such as the first UE <NUM>, and the UE <NUM>. The request, such as a SIP invite message, may be sent to the PBX <NUM>, such as the PBX node <NUM>.

The PBX <NUM> may send the received request. Such as the SIP invite message, to the DCS GW <NUM>, such as the gateway node <NUM>.

The DCS GW <NUM> may create the data channel to the DCS, fetch, such as obtain, its SDP offer and insert it in the SIP invite message before forwarding it to the IMS, such as the IMS network <NUM>, and in the end the UE <NUM>. The SDP offer may comprise data channel media entries.

When receiving the SIP invite message, the UE <NUM> may create, such as establish, a connection, such a data channel, with the DCS, using, such as applying, the received SDP offer. The UE <NUM> may send a SIP <NUM> OK, such as e.g. an accept message, to the DSC GW <NUM>. The SIP <NUM> OK message may comprise an SDP answer. The SDP answer may comprise data channel media entries.

Upon receiving the SIP <NUM> OK from the IMS, or the UE <NUM>, the DCS GW <NUM> may extract the SDP answer for the data channel with the DCS and forward the response to the PBX.

The DCS GW <NUM> applies the received SDP answer to the data channel while waiting for the connection to be established.

The UE <NUM> may establish a connection to the DCS GW <NUM>. The connection may be a WebSocket comprising a third data channel. The UE <NUM> may register with an identity, such as e.g. an agent identity.

This approach allows a separation of the PBX <NUM>, the ALP application and the company applications. The ALP application decides which company application to download and execute. At the end of the call session all the resources are released ready for the next call session.

<FIG> shows how the gateway node <NUM> may be integrated in a cloud environment.

Since the gateway node <NUM> is capable of handling each incoming/outgoing call between the first UE <NUM> to the second UE <NUM> as distinct objects instantiated at arrival of the initial invite from the IMS network <NUM> or the PBX node <NUM>, the ability to make use of the cloud to handle resources required for higher volumes of calls may be possible. The resources may in such a scenario be deployed instantly.

One way may be to create one gateway node <NUM> for each PBX node <NUM>. This may allow a static connection for all the nodes, but it does not allow any elasticity.

Another way may be to allocate a series of gateway nodes <NUM> instances and split them on a per-call basis.

A challenge may be to have the right balancer for each of the connections, such as e.g. SIP, PBX control, UE and the application control, the gateway node <NUM> needs to handle.

An orchestration may be configured to spawn a new gateway node instance, such as a gateway node <NUM> instance, when the currently running instances have reached their maximum number of calls. Because the gateway node <NUM> is not actively involved after the call session is established, this may have minimal impact on the load of the cloud infrastructure. The active data channels are directly established between the first UE <NUM> and the second UE <NUM>.

To perform the method actions, the gateway node <NUM>, may comprise an arrangement depicted in <FIG> and b. The gateway node <NUM> is configured to enhance a call session between a first UE <NUM> and a second UE <NUM> in a communications network <NUM>. The second UE <NUM> is adapted to be associated to a PBX node <NUM>.

The gateway node <NUM> may comprise an input and output interface <NUM> configured to communicate with e.g. the first UE <NUM>, the second UE <NUM>, the PBX node <NUM> and with network nodes in the communications network <NUM>.

The gateway node <NUM> is further configured to, e.g. by means of a receiving unit <NUM> in the gateway node <NUM>, when a call session has been established between the first UE <NUM> and the second UE <NUM> via the PBX node <NUM> and via an IMS network <NUM>, receive, from any one out of the first UE <NUM> and the second UE <NUM>, a request for establishing a data channel to enhance the call session.

The gateway node <NUM> may further be configured to, e.g. by means of the receiving unit <NUM> in the gateway node <NUM>, receive, from any one out of the first UE <NUM> and the second UE <NUM>, a request to establish the call session between the first UE <NUM> and the second UE <NUM>.

The gateway node <NUM> is further configured to, e.g. by means of a negotiating unit <NUM> in the gateway node <NUM>, negotiate one or more parameters adapted to be used in the requested data channel between the first UE <NUM> and the second UE <NUM>.

The gateway node <NUM> may further by configured to, e.g. by means of the negotiating unit <NUM> in the gateway node <NUM>, negotiate the one or more parameters adapted to be used in the requested data channel by: Sending, to the second UE <NUM> one or more first parameters adapted to be related to the requested data channel. The one or more first parameters are adapted to be accepted by the first UE <NUM> and are adapted to be obtained from the received request for establishing the data channel. When receiving, from the second UE <NUM>, one or more parameters adapted to be related to the requested data channel, which one or more parameters are adapted to be accepted by the second UE <NUM> based on the one or more first parameters adapted to be accepted by the first UE <NUM>, the gateway node <NUM> may send an accept message to the first UE <NUM>. The accept message is adapted to indicate that the second UE <NUM> accepts the request to establish the data channel. The accept message is adapted to comprise the one or more parameters.

The gateway node <NUM> is further configured to, e.g. by means of an establishing unit <NUM> in the gateway node <NUM>, establish the data channel according to the negotiation, to enhance the call session between the first UE <NUM> and the second UE <NUM>.

The data channel to enhance the call session may be adapted to be established based on the one or more parameters.

The data channel between the first UE <NUM> and the second UE <NUM> may be adapted to be represented by a peer-to-peer data channel adapted to bypass the PBX node <NUM>.

The gateway node <NUM> may further be configured to, e.g. by means of the establishing unit <NUM> in the gateway node <NUM>, when receiving from the first UE <NUM>, a request to establish the first data channel between the first UE <NUM> and gateway node <NUM>, establish the first data channel between the first UE <NUM> and the gateway node <NUM>.

The gateway node <NUM> may further be configured to, e.g. by means of the establishing unit <NUM> in the gateway node <NUM>, upon the second UE <NUM> becoming available, establish the call session between the first UE <NUM> and the second UE <NUM> by instructing the PBX node <NUM> to connect a first call session between the first UE <NUM> and the PBX node <NUM> with a second call session between the second UE <NUM> and the PBX node <NUM>.

The gateway node <NUM> may further be configured to, e.g. by means of the establishing unit <NUM> in the gateway node <NUM>, establish the call session by indicating to the first UE <NUM> that the second UE <NUM> has become available, and instruct the PBX node <NUM> when receiving a request from the first UE <NUM> to be connected to the second UE <NUM>.

The call session between the first UE <NUM> and the second UE <NUM> may adapted to be based on the obtained data.

The gateway node <NUM> may further be configured to, e.g. by means of an obtaining unit <NUM> in the gateway node <NUM>, obtain data adapted to be related to the call session between the first UE <NUM> and the second UE <NUM> by using the first data channel.

The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor <NUM> of a processing circuitry in the gateway node <NUM> depicted in <FIG>, together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the gateway node <NUM>. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the gateway node <NUM>.

The gateway node 110may further comprise a memory <NUM> comprising one or more memory units. The memory <NUM> comprises instructions executable by the processor <NUM> in the gateway node <NUM>. The memory <NUM> is arranged to be used to store e.g. information, messages, indications, configurations, thresholds, timer values, reports, locations, tracking areas, timing advance values, communication data and applications to perform the methods herein when being executed in the gateway node <NUM>.

In some embodiments, a computer program <NUM> comprises instructions, which when executed by the respective at least one processor <NUM>, cause the at least one processor <NUM> of the gateway node <NUM> to perform the actions above.

In some embodiments, a respective carrier <NUM> comprises the respective computer program <NUM>, wherein the carrier <NUM> is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

Those skilled in the art will appreciate that the units in the gateway node <NUM> described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the gateway node <NUM>, that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

To perform the method actions, the UE <NUM>, <NUM>, <NUM>, may comprise an arrangement depicted in <FIG> and b. The UE <NUM>, <NUM>, <NUM> is configured to enhance a call session between a first UE <NUM> and a second UE <NUM> in a communications network <NUM>. The second UE <NUM>) is adapted to be associated to a PBX, node <NUM>.

The UE <NUM>, <NUM>, <NUM> may be adapted to be represented by any one out of the first UE <NUM> and the second UE <NUM>.

The UE <NUM>, <NUM>, <NUM> may comprise an input and output interface <NUM> configured to communicate with e.g. the gateway node <NUM>, the PBX node <NUM>, the first UE <NUM>, the second UE <NUM> and with network nodes in the communications network <NUM>.

The UE <NUM>, <NUM>, <NUM> is further configured to, e.g. by means of a sending unit <NUM> in the UE <NUM>, <NUM>, <NUM>, when a call session has been established between the first UE <NUM> and the second UE <NUM> via the PBX node <NUM> and via the IMS network <NUM>, send to the gateway node <NUM>, a request for establishing a data channel to enhance the call session between the first UE <NUM> and the second UE <NUM>.

The request to establish the data channel may be adapted to comprise one or more first parameters related to the requested data channel. The one or more first parameters may be adapted to be accepted by the first UE <NUM>.

The UE <NUM>, <NUM>, <NUM> may further be configured to, e.g. by means of the sending unit <NUM> in the UE <NUM>, <NUM>, <NUM>, send to the gateway node <NUM>, a request to establish the first data channel between the first UE <NUM> and gateway node <NUM>.

The UE <NUM>, <NUM>, <NUM> is further configured to, e.g. by means of a negotiating unit <NUM> in the UE <NUM>, <NUM>, <NUM>, negotiate one or more parameters adapted to be used in the requested data channel.

The UE <NUM>, <NUM>, <NUM> may further be configured to, e.g. by means of the negotiating unit <NUM> in the UE <NUM>, <NUM>, <NUM>, negotiate the one or more parameters adapted to be used in the requested data channel by: Receiving, from the gateway node <NUM>, an accept message adapted to indicate that the second UE <NUM> accepts the request to establish the data channel. The accept message is adapted to comprises one or more parameters related to the requested data channel. The one or more parameters are adapted to be accepted by the second UE <NUM> based on the one or more first parameters adapted to be accepted by the first UE <NUM>.

The UE <NUM>, <NUM>, <NUM> is further configured to, e.g. by means of an establishing unit <NUM> in the UE <NUM>, <NUM>, <NUM>, establish the requested data channel to enhance the call session between the first UE <NUM> and the second UE <NUM>, by using the negotiated one or more parameters.

The data channel between the first UE <NUM> and the second UE <NUM> is adapted to be represented by a peer-to-peer data channel adapted to bypass the PBX node <NUM>.

The UE <NUM>, <NUM>, <NUM> may further be configured to, e.g. by means of the establishing unit <NUM> in the UE <NUM>, <NUM>, <NUM>, establish the call session by receiving an indication from the gateway node <NUM>. The indication is adapted to indicate that the second UE <NUM> has become available, and sending to the gateway node <NUM> a request to be connected to the second UE <NUM>.

The established call session between the first UE <NUM> and the second UE <NUM> may be adapted to be based on the provided data.

The UE <NUM>, <NUM>, <NUM> may further be configured to, e.g. by means of an providing unit <NUM> in the UE <NUM>, <NUM>, <NUM>, when the first data channel between the first UE <NUM> and the gateway node <NUM> has been established, provide data adapted to be related to the call session between the first UE <NUM> and the second UE <NUM>. The data adapted to be related the call session is provided by using the first data channel.

The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor <NUM> of a processing circuitry in the UE <NUM>, <NUM>, <NUM> depicted in <FIG>, together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the UE <NUM>, <NUM>, <NUM>. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the UE <NUM>, <NUM>, <NUM>.

The gateway node 110may further comprise a memory <NUM> comprising one or more memory units. The memory <NUM> comprises instructions executable by the processor <NUM> in the UE <NUM>, <NUM>, <NUM>. The memory <NUM> is arranged to be used to store e.g. information, messages, indications, configurations, thresholds, timer values, reports, locations, tracking areas, timing advance values, communication data and applications to perform the methods herein when being executed in the UE <NUM>, <NUM>, <NUM>.

In some embodiments, a computer program <NUM> comprises instructions, which when executed by the respective at least one processor <NUM>, cause the at least one processor <NUM> of the UE <NUM>, <NUM>, <NUM> to perform the actions above.

Those skilled in the art will appreciate that the units in the UE <NUM>, <NUM>, <NUM> described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the UE <NUM>, <NUM>, <NUM>, that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a radio access network, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 3212a, 3212b, 3212c, such as AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network <NUM> e.g. the gateway node <NUM>, over a wired or wireless connection <NUM>. A first user equipment (UE) such as the UE <NUM> and/or a Non-AP STA <NUM> located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE <NUM> such as the second UE <NUM> and/or a Non-AP STA in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a.

In a communication system <NUM>, a host computer <NUM> comprises hardware <NUM> including a communication interface <NUM> configured to setup and maintain a wired or wireless connection with an interface of a different communication device of the communication system <NUM>.

Its hardware <NUM> may include a radio interface <NUM> configured to setup and maintain a wireless connection <NUM> with a base station serving a coverage area in which the UE <NUM> is currently located.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the [select the applicable RAN effect: data rate, latency, power consumption] and thereby provide benefits such as [select the applicable corresponding effect on the OTT service: reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime].

The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>.

The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>.

The communication system includes a host computer, a base station such as a AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>. Additionally, or alternatively, in an optional second step <NUM>, the UE provides user data.

The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to <FIG> and <FIG>.

When using the word "comprise" or "comprising" it shall be interpreted as non-limiting, i.e. meaning "consist at least of".

Claim 1:
A method performed by a gateway node (<NUM>), arranged between an Internet Protocol (IP) Multimedia Subsystem (IMS) network (<NUM>) and a Private Branch Exchange, PBX, node (<NUM>), for enhancing a call session between a first User Equipment, UE, (<NUM>) and a second UE (<NUM>) in a communications network (<NUM>) comprising the IMS network (<NUM>), which second UE (<NUM>) is associated to the PBX node (<NUM>), the method comprising:
when a call session has been established (<NUM>) between the first UE (<NUM>) and the second UE (<NUM>) via the PBX node (<NUM>) and via the IMS network (<NUM>), receiving (<NUM>), from any one out of the first UE (<NUM>) and the second UE (<NUM>), a request for establishing a data channel between the first UE (<NUM>) and the second UE (<NUM>) to enhance the call session,
negotiating (<NUM>) one or more parameters to be used in the requested data channel between the first UE (<NUM>) and the second UE (<NUM>), and
establishing (<NUM>) the data channel according to the negotiation, to enhance the call session between the first UE (<NUM>) and the second UE (<NUM>).