WO2023087229A1

WO2023087229A1 - Proxy node, terminal and methods in a communications network

Info

Publication number: WO2023087229A1
Application number: PCT/CN2021/131603
Authority: WO
Inventors: Liang Ye; Erqun SUN; Weiyi Luo
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-11-19
Filing date: 2021-11-19
Publication date: 2023-05-25

Abstract

A method performed by a proxy node for maintaining a registration of a terminal to an Internet Protocol, IP, Multimedia Subsystem, IMS, network, in a communications network is provided. The terminal subscribes to a push notification service for receiving push notifications from a push server. Upon a successful registration procedure of the terminal to the IMS network, the proxy node establishes (301) a WebSocket connection to the terminal. The connection is established using a session identity obtained by the terminal during the registration procedure. Triggered by the establishing (301) of the WebSocket connection, the proxy node maintains (302) the registration of the terminal to the IMS network by periodically updating the registration also when the terminal is suspended. The proxy node receives (303) a service request related to the terminal from the IMS network. After instructing the push server to notify the terminal of the service request, the proxy node obtains (305) a notification comprising the session identity from the terminal. The notification notifies the proxy node that the terminal is no longer suspended. The notification is obtained over the WebSocket connection between the proxy node and the terminal. The notification reconnects the terminal to the IMS network. The proxy node send (306) the service request to the terminal, enabling the terminal to handle the service request without performing a new registration procedure to the IMS network.

Description

PROXY NODE, TERMINAL AND METHODS IN A COMMUNICATIONS NETWORK

TECHNICAL FIELD

Embodiments herein relate to a proxy node, a terminal and methods therein. In some aspects, they relate to maintaining a registration of the terminal to an Internet Protocol (IP) Multimedia Subsystem (IMS) network, in a communications network.

BACKGROUND

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 (5G) 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 3G, 4G, 5G and the future evolutions. Specifications for the Evolved Packet System (EPS) , also called a Fourth Generation (4G) network, have been completed within the 3rd Generation Partnership Project (3GPP) . As a continued network evolution, the new releases of 3GPP specifies a 5G network also referred to as 5G 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, 5G planning aims at higher capacity than current 4G, 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. 5G 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 4G equipment.

Mobile operating systems often suspend applications to save battery life when the applications are in a background mode. A Push Notification Service (PNS) may therefore be used to wake such applications.

For IMS services such as Voice over IP (VoIP) calls or online conferences, an installed application cannot be reached when the application is suspended. In this case, an IMS Proxy Call Session Control Function (P-CSCF) node stores the terminating request, and a Push Request is sent to PNS in order to trigger a push notification to wake up the application.

Upon receiving the push notification, the suspended application is wakened by an operating system and reconnects to the IMS network. The existing solution requires the application to send a binding-refresh register request to the IMS network. This registration procedure involves multiple IMS nodes such as P-CSCF, Interrogating CSCF (I-CSCF) , Serving CSCF (S-CSCF) , Home Subscriber Server (HSS) and Telephony Application Server (TAS) .

The procedure and conceptual sequence diagram using Session Initiation Protocol (SIP) protocol is described in Internet Engineering Taskforce (IETF) Request for Comments (RFC) 8599 -Push Notification with the Session Initiation Protocol (SIP) .

Figure 1 shows a sequence diagram according to the existing solution.

SUMMARY

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

A problem is that the IMS registration-based wake up mechanism requires a terminal to send a register request to an IMS network each time receiving a push notification, which in turn triggers an IMS registration procedure. This procedure comprises steps for IMS authentication and subscriber profile retrieval. Several IMS nodes are involved in the procedure. This may result in high latency in handling incoming service requests, high signaling load, and high energy consumption in in the terminal.

An object of embodiments herein is to improve the performance of a communications network by a more efficient handling of registrations to an IMS network in the communications network.

According to an aspect of embodiments herein, the object is achieved by a method performed by a proxy node for maintaining a registration of a terminal to an IMS network in a communications network. The terminal subscribes to a push notification service for receiving push notifications from a push server.

Upon a successful registration procedure of the terminal to the IMS network, the proxy node establishes a WebSocket connection to the terminal. The connection is established by using a session identity obtained by the terminal during the registration procedure.

Triggered by the establishing of the WebSocket connection, the proxy node maintains the registration of the terminal to the IMS network by periodically updating the registration also when the terminal is suspended.

The proxy node receives a service request related to the terminal from the IMS network.

After instructing the push server to notify the terminal of the service request, the proxy node obtains a notification comprising the session identity from the terminal. The notification notifies the proxy node that the terminal is no longer suspended. The notification is obtained over the WebSocket connection between the proxy node and the terminal. The notification reconnects the terminal to the IMS network.

The proxy node sends the service request to the terminal. This enables the terminal to handle the service request without performing a new registration procedure to the IMS network.

According to an another aspect of embodiments herein, the object is achieved by a method performed by a terminal for maintaining a registration of the terminal to an IMS network in a communications network. The terminal subscribes to a push notification service for receiving push notifications from a push server.

Upon a successful registration procedure of the terminal to the IMS network, the terminal establishes a WebSocket connection to a proxy node. The connection is established by using a session identity obtained by the terminal during the registration procedure. The establishing of the WebSocket connection triggers the proxy node to maintain the registration of the terminal to the IMS network, by periodically updating the registration, also when the terminal is suspended.

After receiving a push notification from the push server, which push notification notifies the terminal of a service request related to the terminal, the terminal provides a notification. The notification comprises the session identity to the proxy node. The notification notifies the proxy node that the terminal is no longer suspended. The notification is provided over the WebSocket connection between the proxy node and the terminal. The notification reconnects the terminal to the IMS network.

The terminal receives the service request from the proxy node. This enables the terminal to handle the service request without performing a new registration procedure to the IMS network.

According to an another aspect of embodiments herein, the object is achieved by a proxy node configured to maintain a registration of a terminal to an Internet Protocol, IP, Multimedia Subsystem, IMS, network, in a communications network. The terminal is adapted to subscribe to a push notification service for receiving push notifications from a push server. The proxy node is further configured to:

- Upon a successful registration procedure of the terminal to the IMS network, establish a WebSocket connection to the terminal, which connection is adapted to be established using a session identity obtained by the terminal during the registration procedure,

- triggered by the establishing of the WebSocket connection, maintain the registration of the terminal to the IMS network by periodically updating the registration also when the terminal is suspended,

- receive a service request adapted to be related to the terminal from the IMS network,

- after instructing the push server to notify the terminal of the service request, obtain a notification adapted to comprise the session identity from the terminal, the notification being adapted to notify the proxy node that the terminal is no longer suspended, the notification adapted to be obtained over the WebSocket connection between the proxy node and the terminal, which notification is adapted to reconnect the terminal to the IMS network, and

- send the service request to the terminal, enabling the terminal to handle the service request without performing a new registration procedure to the IMS network.

According to an another aspect of embodiments herein, the object is achieved by a terminal configured to maintaining a registration of the terminal to an Internet Protocol, IP, Multimedia Subsystem, IMS, network, in a communications network. The terminal is adapted to subscribe to a push notification service for receiving push notifications from a push server. The terminal is further configured to:

- Upon a successful registration procedure of the terminal to the IMS network, establish a WebSocket connection to a proxy node, which connection is adapted to be established using a session identity obtained by the terminal during the registration procedure, wherein the establishing of the WebSocket connection is adapted to trigger the proxy node to maintain the registration of the terminal to the IMS network, by periodically updating the registration, also when the terminal is suspended,

- after receiving a push notification from the push server, the push notification being adapted to notify the terminal of a service request related to the terminal, provide a notification adapted to comprise the session identity to the proxy node, the notification being adapted to notify the proxy node that the terminal is no longer suspended, the terminal further being configured to provide the notification over the WebSocket connection between the proxy node and the terminal, which notification is adapted to reconnect the terminal to the IMS network, and

receive the service request from the proxy node, enabling the terminal to handle the service request without performing a new registration procedure to the IMS network.

Thanks to that the proxy node, after a successful registration procedure of the terminal to the IMS network, maintains said registration also when the terminal is suspended, it is possible for the terminal to handle service requests without performing a new registration procedure. The proxy node is triggered to maintain the registration of the terminal to the IMS network by the establishing of the WebSocket connection between the terminal and the proxy node. The connection is established using the session identity obtained by the terminal during the registration procedure. After the proxy node has received a service request related to the terminal, and instructed the push server to notify the terminal of the service request, the terminal provides a notification to the proxy node. The notification comprises the session identity and notifies the proxy node that the terminal is no longer suspend. By sending the service request to the terminal, while maintaining the registration of the terminal to the IMS network, the terminal is enable to handle the service request without performing a new registration procedure. In this way, an efficient mechanism for handling registrations to the IMS network is achieved.

Embodiments herein brings the advantage of an efficient mechanism improving the performance in the communications network. This is achieved by making it possible to maintain a registration of the terminal also when suspended, enabling the terminal to handle service requests without performing a new registration procedure when no longer being suspended. this leads to a more efficient handling a registrations to the IMS network, and results in an improved performance in the communications network.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to attached drawings in which:

Figure 1 is a signaling diagram illustrating an example according to prior art.

Figure 2 is a schematic block diagram illustrating embodiments of a communications network.

Figure 3 is a flowchart depicting embodiments of a method in a proxy node.

Figure 4 is a flowchart depicting embodiments of a method in a terminal.

Figure 5 is a schematic block diagram depicting examples of embodiments herein.

Figure 6 is a schematic block diagram depicting examples of embodiments herein.

Figure 7a is a schematic block diagram depicting examples of embodiments herein.

Figure 7b is a signaling diagram depicting examples of embodiments herein.

Figures 8 a and b are schematic block diagrams illustrating embodiments of a proxy node.

Figures 9 a and b are schematic block diagrams illustrating embodiments of a terminal. Figure 10 schematically illustrates a telecommunication network connected via an intermediate network to a host computer.

Figure 11 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection.

Figures 12 to 15 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

DETAILED DESCRIPTION

Embodiments herein relate to a communications network and the maintaining of a registration of a terminal to an IMS network.

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

One problem with the existing solution is the latency added for the registration before the terminal responds to a delay-sensitive service request, e.g. a terminating Voice over IP (VoIP) call. The latency is caused by the message round trip delay between several nodes in the IMS network, as well as the processing time spent within each of these nodes.

Another problem is traffic generated due to the IMS registration when the terminal receives the push notification. The registration may happen frequently due to the mobile operating system, which will actively suspend an application running in the background to improve hardware performance as well as to optimize the terminals battery life. Considering the number of terminals on the communications network, the amount of IMS registration traffic may increase the load of the communications network.

Another problem is battery drain caused by frequent refreshing of the IMS registration. The refresh frequency is typically a few tens of minutes depending on the network configuration. However, the registration refresh is becoming not sustainable for a mobile application because the mobile operating system could actively suspend the application running in the background to save battery life. Consequently, the terminal needs to register to the IMS network again when awakened. This since the registration is terminated after the registration expiry when the terminal is suspended.

Besides, the registration procedure may also increase the risk of call failure by involving multiple nodes for a new registration on the terminating VoIP call.

This, as mentioned above, the object of embodiments herein is to improve the performance of a communications network by a more efficient handling of registrations to an IMS network in the communications network.

Embodiments herein may e.g. bring the advantage that they allows low-latency reconnection to the IMS network when a terminal is awakened from a suspended state, e.g. by a push notification. Further, embodiments herein may bring the advantage of a simplified procedure for the terminal to reconnect to the IMS network. Yet further, embodiments herein may bring the advantage of an improved battery life of the terminal.

The advantages may be achieved by maintaining the registration of the terminal to the IMS network also when the terminal is suspended. More specifically, the registration is maintained by a proxy node also when the terminal is suspended, and when awakened reconnecting to the IMS network may only involve the terminal and the proxy node.

Figure 2 is a schematic overview depicting a communications network 100 wherein embodiments herein may be implemented. The communications network 100 comprises one or more RANs and one or more CNs. The communications network 100 may use 5G NR but may further use a number of other different technologies, such as, 6G,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 Microwave Access (WiMax) , or Ultra Mobile Broadband (UMB) , just to mention a few possible implementations.

The communications network 100 further comprises an IMS network 105, in which IMS network 105 a proxy node, such as e. g. the proxy node 110, operates. According to embodiments herein the proxy node 110 may be a Proxy Call Session Control Function (P-CSCF) , an Session Border Controller (SBC) or be part of said P-CSCF or SBC. The IMS network 105 is an architecture for delivering media content over an IP packet switched transport.

One or more terminals operate in the communication network 100, such as e.g. the terminal 120. The terminal 120 may e.g. be 5G-RG, a UE, a remote UE, a wireless device, an NR device, a mobile station, a wireless terminal, an NB-IoT 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 a base station such as e.g. a base station 105, one or more Access Networks (AN) , e.g. a RAN, to one or more core network (CN) nodes, in one or more CNs, or one or more IMS nodes, such as e.g. the proxy node 110, in the IMS network 105. The terminal 120 may communicate with one or more CN nodes, or IMS nodes, such as the proxy node 110, by a fixed network connection, such as e.g. cable and/or optical fiber. It should be understood by the skilled in the art that “UE” is a non-limiting term which means any terminal, client, mobile client, IMS client, 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.

Push servers, such as e.g. a push server 130, may operate in the communications network 100. The push server 130 may e.g. operate in the IMS network 105, the CN, or be connected to said IMS network 105 or CN. The push server 130 provides push notification services for sending push notifications to terminals, such as e.g. the terminal 120.

Base stations such as the base station 101, operate in the wireless communications network 100. The base station 101 provides one or more cells such as a first cell 11. The base station 101 may be a transmission and reception point e.g. a radio access network node such as a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B) , an NR Node B (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, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA) , an access controller, or any other network unit capable of communicating with UEs, such as the terminal 120, within the first cell 11, served by the base station 101. The base station 101 may be referred to as a serving radio network node and communicates with the terminal 120 with Downlink (DL) transmissions to the terminal 120 and Uplink (UL) transmissions from the terminal 120.

Methods according to embodiments herein are performed by the proxy node 110, and the terminal 120. These nodes may be Distributed Nodes (DN) sand functionality, e.g. comprised in a cloud 150 as shown in Figure 2 may be used for performing or partly performing the methods.

Embodiments herein provide methods, e.g. for a Hyper Text Transfer Protocol (HTTP) based client, such as e.g. the terminal 120, to connect to the IMS network 120, by using a WebSocket. A WebSocket when used herein is a HTTP-based communication channel to convey control plane signaling messages between the terminal 120 and the proxy node 110. The WebSocket is established, also referred to as opened, right after an initial registration of the terminal 120 to the IMS network 105. The registration is maintained by a Web Access Service (WAS) , such as e.g. the proxy node 110. When wakened by a Push Notification Service (PNS) , such as e.g. the push server 130, the terminal 120 reuses the established WebSocket, e.g. if the Transmission Control Protocol (TCP) and/or Transport Layer Security (TLS) connection of the WebSocket is still open. Alternatively, if the WebSocket is closed, the terminal 120 may re-established the WebSocket connection towards the proxy node 110. The proxy node 110 continues to deliver pending service requests, such as service request received when the terminal 120 was suspended to the wakened terminal 120 on the WebSocket connection. The proxy node 110 refreshes the IMS registration on behalf of the terminal 120 when the terminal 120 is suspended. In addition the word “terminal” , such as the terminal 120, also extends to smart devices, Internet of Things (IoT) devices and mobile applications which use an HTTP (S) interface to access the IMS network 105.

A method according to embodiments will now be described from the view of the proxy node 110 together with Figure 3.

Example embodiments of a method performed by the proxy node 110 for maintaining a registration of the terminal 120 to the IMS network 105, in the communications network 100, will now be described with reference to a flowchart depicted in Figure 3. The terminal 120 subscribes to a push notification service for receiving push notifications from the push server 130. The proxy node 110 may be associated to the IMS network 105. The proxy node 110 may be a P-CSCF node, an SBC or be part of any one of said P-CSCF or SBC.

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 Figure 3.

Action 301

To communicate with the IMS network 105, the terminal 120 needs to be registered to the IMS network.

Upon a successful registration procedure of the terminal 120 to the IMS network 105, the proxy node 110 establishes a WebSocket connection to the terminal 120. The connection is established using the session identity obtained by the terminal 120 during the registration procedure.

The session identity may be referred to as a client session identity (CSID) . The session identity may e.g. be a unique identifier that identifies the terminal 120 and resources associated to the terminal 120 in the proxy node 110. The session identity may be used by the terminal 120 in any subsequent WebSocket communications in the established or re-established WebSocket connection between the terminal 120 and the proxy node 110.

In some embodiments, the establishing of the WebSocket connection further comprises that the proxy node 110 receives a request to establish the WebSocket connection from the terminal 120. The request comprises the session identity. The proxy node 110 may send a response, e.g. responding to the received request, to the terminal 120. The response indicates a successful establishing of the WebSocket connection.

In some embodiments, the registration procedure comprises that the proxy node 110 sends the session identity to the terminal 120. The session identity may be comprised in a message indicating a successful registration procedure. The proxy node 110 may generate the session identity upon the successful registration procedure.

Action 302

A registration to the IMS network 105, e.g. the registration of the terminal 120 to the IMS network 105, may be valid for certain period of time. In order to maintain the registration according to embodiments herein, it needs to be updated, such as refreshed, e.g. periodically.

Triggered by the establishing of the WebSocket connection, the proxy node 110 maintains the registration of the terminal 120 to the IMS network 105 by periodically updating the registration. According to embodiments herein, the proxy node 110 maintains the registration also when the terminal 120 is suspended. In other words, by periodically updating, or refreshing, the registration of the terminal 120 to the IMS network 105, the registration is maintained even if the terminal is suspended. Thus, the terminal 120 may not need to perform a registration procedure when wakened, such as transitioning from the suspended mode to an active mode.

The periodicity of the updating of the registration may e.g. be a few tens of minutes, e.g. 20 minutes. The value is no more than 80%of the IMS network registration validity time and may calculated from network dimension.

Updating the registration when used herein may e.g. mean to send a registration request message to nodes in the IMS network 105 involved in the registration procedure before the registration validity time expires.

The proxy node 110 may update the registration at a certain point in time during the validity of the registration, e.g. a certain period before the registration expires, in order to avoid performing an authentication procedure.

Action 303

According to an example scenario, at some point, after the successful registration procedure, a service request related to the terminal 120 may arrive in the IMS network 105.

The proxy node 110 receives the service request related to the terminal 120 from the IMS network 105.

In some embodiments, receiving the service request further comprises that the proxy node 110 stores the received service request. The service request may e.g. be stored in a memory in the proxy node 110, or in a memory accessible to the proxy node 110. The service request may be terminating service request, such as e.g. an incoming call session, such as a VoIP session, a media conference request, a 1-to1 chat message or group chat message.

A terminating service request when used herein may mean a control plane signaling message originated from another terminal to be received by the terminal 120, or originated from an IMS network element, e.g. a node in the IMS network, e.g. requesting the terminal 120 to perform IP multimedia service.

Action 304

The proxy node 110 may instruct the push server 130 to send a push notification to the terminal 120. The push notification notifies the terminal 120 of the service request. The push notification may trigger the terminal 120 to awake when suspended, in order to be able to receive the service request.

The proxy node 110 may instruct the push server 130 to send the push notification by sending a request to the push server 130. The request may comprise a push identity, such as e.g. a push resource identity, associated to the terminal 120. The push identity may have been obtained from the terminal 120 during the registration procedure. The push resource identity may be used to uniquely identify the terminal 120.

Action 305

To be able to send the service request to the terminal 120, the proxy node 110 may need to know that the terminal 120 is no longer suspended.

Thus, after instructing the push server 130 to notify the terminal 120 of the service request, the proxy node 110 obtains a notification comprising the session identity from the terminal 120. The notification notifies the proxy node 110 that the terminal 120 is no longer suspended. The notification is obtained over the WebSocket connection between the proxy node 110 and the terminal 120. The notification reconnects the terminal 120 to the IMS network 105.

The WebSocket connection may be closed, e.g. while the terminal 120 is suspended. Therefore, in some embodiments, the obtained notification is a request to re-establish the WebSocket connection, which request triggers the proxy node 110 to re-establish the WebSocket connection.

In some embodiments, the proxy node 110 may detect that the terminal 120 is not suspended, such as e.g. the terminal 120 is awake and/or online. The proxy node 110 may detect that the terminal in not suspended e.g. by detecting that a transport layer connection to the terminal is active. In this embodiment, the proxy node 110 may skip Action 304 and the previously described actions in Action 305. This may mean that when the proxy node 110 receives the service request in Action 303 and has detected that the terminal 120 is not suspended, such as that the terminal 120 does not need to be awakened, the proxy node 110 performs Action 306, as described below directly. This in order to accelerate handling of the service request, and thus e.g. reduce the latency.

Action 306

In order to for the service request to be handled by the terminal, the proxy node 110 needs to send it to the terminal 110.

The proxy node 110 sends the service request to the terminal 120. This enables the terminal 120 to handle the service request without performing a new registration procedure to the IMS network 105.

In some embodiments, sending the service request further comprises the proxy node 110 retrieving the stored service request. The service request may e.g. be retrieved from the memory in the proxy node 110, or in the memory accessible to the proxy node 110, where the service request was stored.

By maintaining the registration of the terminal 120 to the IMS network 105, the latency and signaling is reduced when handling service request related to the terminal 120. Further, energy consumption in the terminal 120 is decreased since the terminal 120 does not need to update the registration. This leads to an improved performance in the communications network.

A method according to some example embodiments will now be described from the view of the proxy node 110 will now be described with reference to a flowchart depicted in Figure 4. The method is performed by the terminal 120 and is for maintaining a registration of the terminal 120 to the IMS network 105 in a communications network 100. The terminal 120 subscribes to a push notification service for receiving push notifications from the push server 130.

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 Figure 4.

Action 401

Upon a successful registration procedure of the terminal 120 to the IMS network 105, the terminal 120 establishes a WebSocket connection to a proxy node 110. The connection is established using the session identity obtained by the terminal 120 during the registration procedure. The establishing of the WebSocket connection triggers the proxy node 110 to maintain the registration of the terminal 120 to the IMS network 105, by periodically updating the registration, also when the terminal is suspended,

The periodicity of the updating of the registration may e.g. be e.g. be a few tens of minutes, e.g. 20 minutes. The value is no more than 80%of the IMS network registration validity time and may calculated from network dimension. As mentioned above, the session identity may be referred to as a CSID. The session identity may e.g. be a unique identifier that identifies the terminal 120 and resources associated to the terminal 120 in the proxy node 110. The session identity may be used by the terminal 120 in any subsequent WebSocket communications in the established or re-established WebSocket connection between the terminal 120 and the proxy node 110.

In some embodiments, the establishing of the WebSocket connection further comprises that the terminal sends a request to establish the WebSocket connection to the proxy node 110. The request comprises the session identity. The terminal 120 may receive a response, e.g. a response to the sent request, from the proxy node 110. The response indicates a successful establishing of the WebSocket connection.

The registration procedure may comprise receiving the session identity from the proxy node 110. The session identity may be comprised in a message indicating a successful registration procedure. The proxy node 110 may generate the session identity upon the successful registration procedure.

Action 402

At some point, after the successful registration procedure, a service request related to the terminal 120 may arrive in the IMS network 105. The service request may be terminating service request, such as e.g. an incoming call session, such as a VoIP session, a media conference request, a 1-to1 chat message or group chat message.

The terminal 120 may receive a push notification from the push server 130. The push notification notifies the terminal 120 of the service request. The push notification may comprise the push resource identity. The push resource identity may be used by the to uniquely identify the terminal 120.

Action 403

The terminal 120 may need to inform the proxy node 120 that it is aware of the service request, and prepared to receive it.

Thus, after receiving the push notification from the push server 130, the push notification notifying the terminal of a service request related to the terminal 120, the terminal 120 provides a notification comprising the session identity to the proxy node 110. The notification notifies the proxy node 110 that the terminal 120 is no longer suspended. The notification is provided over the WebSocket connection between the proxy node 110 and the terminal 120. It may e.g. be provided by transmitting or sending the notification to the proxy node 110 The notification reconnects the terminal 120 to the IMS network 105.

The WebSocket connection between the terminal 120 and the proxy node 110 may be closed, e.g. while the terminal 120 is suspended.

Therefore, in some embodiments, the provided notification is a request to re-establish the WebSocket connection. The request triggers the proxy node 110 to re-establish the WebSocket connection.

In some embodiments, the terminal is not suspended, such as e.g. the terminal 120 is awake and/or online, when the proxy node 110 receives the service request related to the terminal 120. The proxy node 110 may detect that the terminal is not suspended e.g. by detecting that a transport layer connection to the terminal is active. In this embodiment, the terminal 120 may skip Action 402 and the previously described actions in Action 403. This may mean that when the proxy node 110 receives the service request in Action 303 and has detected that the terminal 120 is not suspended, such as that the terminal 120 does not need to be awakened, the terminal performs Action 404, as described below, directly. This in order to accelerate handling of the service request, and thus e.g. reduce the latency.

Action 404

The terminal 120 receives the service request from the proxy node 110, e.g. when the terminal 120 has been reconnected to the IMS network 105. This enables the terminal 120 to handle the service request without performing a new registration procedure to the IMS network 105.

By triggering the proxy node 110 to maintain the registration of the terminal 120 to the IMS network 105 also when the terminal 120 is suspended, the terminal 120 may be reconnected using the maintained registration instead of performing a new registration procedure to the IMS network 105. This results in that latency and signaling is reduced when handling a service request related to the terminal 120.

Further, energy consumption in the terminal 120 is decreased since the terminal 120 does not need to perform any new registration procedure to the IMS network 105. This leads to an improved performance in the communications network.

Embodiments mentioned above will now be further described and exemplified. The embodiments below is applicable to and may be combined with any suitable embodiment described above.

In the examples of Figure 5 and Figure 6 and Figures 7a and b, the proxy node 110 may be a, comprised in, or connected to, WAS, a P-CSCF or a SGC. The push server 130 may be a PNS or a push service. The terminal 120 may be a client, mobile client, HTTP-based client, IMS client.

Figure 5 shows an overview of the terminal 120 connected to the IMS network 105 according to an example of embodiments herein.

The proxy node 110, provides inter-working between Internet and the IMS network 105, allowing e.g. HTTP-based clients on the Internet, such as the terminal 120, to connect to an IMS network. The proxy node 110, may be positioned in front of the IMS network 105, e.g. as part of the SBC or P-CSCF. The proxy node 110 may receive HTTP/REST-based requests from the terminal 120 and sends these requests to the IMS network 105. The proxy node 110 may receive service request requests, e.g. SIP based requests, from the IMS network 105 and sends these requests over a WebSocket event channel, such as e.g. the WebSocket connection, to the terminal 120. The proxy node 110 may act as an HTTP/REST and WebSocket server for the terminal 120, and as the client, such as terminal, proxy for the IMS network 105.

The push server 130, provides a service that sends messages requested by other applications or nodes, e.g. in the IMS network 105, to the terminal 120.

In Figure 5, the terminal 120 connects to the IMS network 120 through the proxy node 110. The proxy node 110 uses the push server 130 to wake up the terminal 120 in case the terminal 120 suspended.

Figure 6 shows the proxy node 110 interfaces used by the terminal 120 to connect to the IMS network 105. The proxy node 110 may transfer HTTP-based operations from the terminal 120 to the IMS network 105 with one or more protocols such as e.g. SIP, MSRP, XCAP or BFCP. The proxy node 110 may offer REST/HTTP and WebSocket interfaces when communicating with the terminal 120.

Figure 7a shows an example according to embodiments herein.

In Step 1 and Step 2 the terminal 120 registers to the IMS network 105 with a Push Resource ID (PRID) which will be used in the future by the proxy node 110, such as e.g. the proxy node 110, for push notifications.

In Step 3 the proxy node 110 may respond with a CSID which is used for subsequent requests. The terminal 120 may open the WebSocket connection to the proxy node 110. The WebSocket connection is maintained by the proxy node 110 in front of the IMS network 105 as a WebSocket server. The proxy node 110 may maintain the registration of the terminal 110 to the IMS network 105 by periodically refreshing, such as updating, the registration.

In Steps 4, 5 and 6 the proxy node 110 may receive a service request, e.g. a SIP Invite message, related to the terminal. The terminal 120 may be awakened up by a push notification message from the push server 130.

In Step 7 the terminal may reconnect to IMS network 105 using the WebSocket connection if the TCP/TLS connection of WebSocket is still open. Alternatively, if the WebSocket connection is closed, the terminal 120 may open, such as establish, anew WebSocket connection.

In Steps 8 and 9 the proxy node 110 may transfer, such as send, the service request to the terminal 120 on WebSocket connection. This enables the terminal 120 to handle the service request without performing a new registration to the IMS network 105.

The WebSocket connection is established between the terminal 120 and the proxy node 110. No other IMS nodes will be involved to setup the connection. The registration and subscriber authentication of terminal 120 is maintained by the proxy node 110 after the initial registration of the terminal 120. Thus, no additional IMS authentication or registration is required when the terminal 120 connect to the IMS network upon receiving the push notification. This may reduce the signaling load, and thus result in an improved performance in the communications network

The proxy node 110 may act as a proxy of the terminal 120, responsible for maintaining and refreshing the user registration in the IMS network 105. The terminal 120 is not required to send frequent binding register for IMS registration refresh, or update, and may therefore improve battery life on the terminal 120.

The terminal 120 reconnects to the IMS network 105 using the WebSocket connection, and only the terminal 120 and proxy node 110 are involved. This may shortened the time for the terminal 120 to reconnect to the IMS network 105, and may thus improve the latency when reconnecting after being suspended.

Actions 701-713 of Figure 7b depicts detailed steps for an implementation example according to embodiments herein. The proxy node 110 may e.g. be referred to as WAS/P-CSCF 110. The terminal 120 may e.g. be referred to as client 120. The push server 130 may e.g. be referred to as push service 130. The actions may be taken in any suitable order.

Action 701. The terminal 120, which may be the terminal 120, may subscribe to a push notification service from the push server 130 , such as e.g. the push server 130, to receive push notifications for incoming terminating requests, such as e.g. the service request, from the IMS network 105 when the terminal 120 suspended. The terminal 120 may e.g. send a request to the push server 130 for subscribing to the push notification service.

This action may be related to, and combined with, Action 401 described above.

Action 702. The push server 130 may respond with successful push notification subscription and provide a PRID to the terminal 120.

This action may be related to, and combined with, Action 401 described above.

Action 703. The terminal 120 may send a the HTTP/REST Client Registration request towards the proxy node 110, which may be the proxy node 110, along with all the push notification parameters, e.g. the PRID, provided by the push server 130. These parameters may be used by the proxy node 110 in the future to invoke the push server 130. This to register the terminal 120 to the IMS network 105.

This action may be related to, and combined with, Actions 301 and 401 described above.

Action 704. The proxy node 110 may send a HTTP/REST 201 Created to the terminal 120, in response to the HTTP/REST Client Registration request, along with the CSID after the successful registration to the IMS network 105. The CSID is the unique identifier to the terminal 120 resource inside the proxy node 110 and may be used in subsequent requests.

Action 705. The terminal 120 sends HTTP/REST Open WebSocket Request, with the CSID to open, such as establish, anew WebSocket connection to the proxy node 110, such as between the terminal 120 and the proxy node 110.

Action 706. The proxy node 110 may respond to the terminal 120 with a 101 Switching Protocols to indicate that the WebSocket connection is open, such as established, and internally binds the WebSocket connection to the terminal 120 using the CSID. The HTTP connection is upgraded to a WebSocket connection and may be used in future communication with the terminal 120.

When the WebSocket connection is established, the proxy node 110 starts to refresh, such as maintain, the SIP registration on behalf of the terminal 120 to IMS network 105. The terminal 120 is not required to periodically refresh registration its registration to the IMS network 105, which may save battery life on the terminal 120 and reduce signaling load.

This may be related to, and combined with, Action 302 described above.

After some time, the terminal 120 may be suspended by the mobile device Operating System. On receiving a terminating IMS service request, e.g. a VoIP call, the proxy node 110 may wakeup the terminal 120 before forwarding the request. The proxy node 110 may store the request locally.

This may be related to, and combined with, Actions 303 and 304 described above.

Action 707. The proxy node 110 may send push request towards, such as instruct, the push server 130.

This action may be related to, and combined with, Action 304 described above.

Action 708. The push server 130 may respond with a 200OK after validation of the push request.

Action 709. The push server 130 may send the VoIP Push Notification to the terminal 120 to awaken the terminal 120. In some examples, the push notification is sent to the operating system of the terminal 120, and operating system awaken the terminal 120. This action may be related to, and combined with, Action 402 described above.

Alternative #1: In some examples the WebSocket connection is still open. In this example the terminal 120 may reuse the previous WebSocket. This may be checked against the WebSocket TCP/TLS connection status in the terminal 120. The terminal 120 may continue to use the same WebSocket connection to communicate with the proxy node 110.

Action 710a. the terminal 120 sends WebSocket PING to the proxy node 110 to indicate that the Client is wakened, such as the notification notifying the proxy node 110 that the terminal 120 is no longer suspended. This may reconnect the terminal 120 to the IMS network 105.

This action may be related to, and combined with, Actions 305 and 403 described above.

Action 711a. The proxy node 110 may respond with a WebSocket PONG to acknowledge the WebSocket connection is open.

The WebSocket PING/PONG control frames are used for smaller overhead. The other text/binary message can also be used as a WebSocket frame payload to inform WAS that the terminal 120 is back online.

Alternative #2. In some examples the WebSocket connection is closed. In this example the terminal 120 may open a new WebSocket, such as e.g. re-establish the WebSocket connection. This may also open a pinhole in a firewall if the terminal 120 is behind a Network Address Translator (NAT) , and may also be used if the WebSocket connection is open but the NAT prevents the proxy node 110 to reach the terminal 120. Below Actions 10B and 11B are identical to Actions 705 and 706.

Action 710b. The terminal 120 may send a HTTP/REST Open WebSocket Request, with the CSID to open, such as re-establish, a new WebSocket connection on the proxy node 110.

Action 711b. The proxy node 110 may respond to the terminal 120 with a 101 Switching Protocols to indicate that the WebSocket connection is open, such as established, and internally binds the WebSocket connection to the terminal 120 using the CSID. The HTTP connection is upgraded to a WebSocket connection and may be used in future communication with the terminal 120.

After the WebSocket is open, such as re-established, the proxy node 110 may check the local storage and find pending service request, such as the received service request. The proxy node 110 may fetch the stored pending service request to continue the multimedia service.

This action may be related to, and combined with, Action 303

Action 712. The proxy node 110 sends the pending service request to the terminal 120 via the WebSocket connection.

This action may be related to, and combined with,

Actions

306 and 404 described above.

Action 713. The terminal 120 may reject or accept, such as handle, the received service request.

This action may be related to, and combined with, Action 404 described above.

To perform the method actions, the proxy node 110 may comprise an arrangement depicted in Figure 8a and b. The proxy node 110 is configured to maintain a registration of the terminal 120 to the IMS network 105 in a communications network 100. The terminal 120 is adapted to subscribe to a push notification service for receiving push notifications from the push server 130.

The proxy node 110 may comprise an input and output interface 800 configured to communicate with e.g. the terminal 120, the push server 130 and with network nodes in the communications network 100.

The proxy node 110 is further configured to, e.g. by means of an establishing unit 810 in the proxy node 110, upon a successful registration procedure of the terminal 120 to the IMS network 105, establish the WebSocket connection to the terminal 120. The connection is adapted to be established using the session identity obtained by the terminal 120 during the registration procedure.

The registration procedure may be adapted to comprise sending the session identity to the terminal 120.

The proxy node 110 may further be configured to, e.g. by means of the establishing unit 810 in the proxy node 110, establish the WebSocket connection by further being configured to receive a request to establish the WebSocket connection from the terminal 120. The request is adapted to comprise the session identity. The proxy node 110 sends a response to the terminal 120, the response being adapted to indicate a successful establishing of the WebSocket connection.

The proxy node 110 is further configured to, e.g. by means of a maintaining unit 820 in the proxy node 110, triggered by the establishing of the WebSocket connection, maintain the registration of the terminal 120 to the IMS network 105 by periodically updating the registration also when the terminal 120 is suspended.

The proxy node 110 is further configured to, e.g. by means of a receiving unit 830 in the proxy node 110, receive the service request adapted to be related to the terminal 120 from the IMS network 105.

The proxy node 110 may be configured to receive the service request by further being configured to store the received service request.

The proxy node 110 is further configured to, e.g. by means of an obtaining unit 840 in the proxy node 110, after instructing the push server 130 to notify the terminal 120 of the service request, obtain a notification adapted to comprise the session identity from the terminal 120. The notification being adapted to notify the proxy node 110 that the terminal 120 is no longer suspended. The notification further being adapted to be obtained over the WebSocket connection between the proxy node 110 and the terminal 120. The notification is adapted to reconnect the terminal 120 to the IMS network 105.

The obtained notification may be adapted to be a request to re-establish the WebSocket connection. The request is adapted to trigger the proxy node 110 to re-establish the WebSocket connection.

The proxy node 110 is further configured to, e.g. by means of a sending unit 850 in the proxy node 110, send the service request to the terminal 120, enabling the terminal 120 to handle the service request without performing a new registration procedure to the IMS network 105.

The proxy node 110 may be configured to send the service request by further being configured to retrieve the stored service request.

The proxy node 110 may further be configured to, e.g. by means of an instructing unit 860 in the proxy node 110, instruct the push server 130 to send a push notification to the terminal 120. The push notification is adapted to notify the terminal 120 of the service request.

The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor 800 of a processing circuitry in the proxy node 110 depicted in Figure 8a, 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 proxy node 110. 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 proxy node 110.

The proxy node 110 may further comprise a memory 880 comprising one or more memory units. The memory proxy node 110 comprises instructions executable by the processor 870 in the proxy node 110. The memory 880 is arranged to be used to store e.g. information, messages, indications, notifications, service requests, connections, identities, communication data and applications to perform the methods herein when being executed in the proxy node 110.

In some embodiments, a computer program 890 comprises instructions, which when executed by the respective at least one processor 870, cause the at least one processor 870 of the proxy node 110 to perform the actions above.

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

Those skilled in the art will appreciate that the units in the proxy node 110 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 proxy node 110, 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 terminal 120 may comprise an arrangement depicted in Figure 9a and b. The terminal 120 is configured to maintain a registration of the terminal 120 to the IMS network 105 in a communications network 100. The terminal 120 is adapted to subscribe to a push notification service for receiving push notifications from a push server 130.

The terminal 120 may comprise an input and output interface 1300 configured to communicate with e.g. the proxy node 110 and with network nodes in the communications network 100.

The terminal 120 is further configured to, e.g. by means of an establishing unit 910 in the terminal 120, upon a successful registration procedure of the terminal 120 to the IMS network 105, establish a WebSocket connection to a proxy node 110. The connection is adapted to be established using the session identity obtained by the terminal 120 during the registration procedure. The establishing of the WebSocket connection is adapted to trigger the proxy node 110 to maintain the registration of the terminal 120 to the IMS network 105. The registration is maintained by periodically updating the registration, also when the terminal 120 is suspended.

The registration procedure may be adapted to comprise to receive the session identity from the proxy node 110.

The terminal 120 may further be configured to, e.g. by means of the establishing unit 910 in the terminal 120, establish the WebSocket connection by further being configured to send the request to establish the WebSocket connection to the proxy node 110. The request is adapted to comprise the session identity. The terminal 120 receives a response from the proxy node 110. The response may be adapted to indicate a successful establishing of the WebSocket connection.

The terminal 120 is further configured to, e.g. by means of a providing unit 920 in the terminal 120, after receiving the push notification from the push server 130, the push notification being adapted to notify the terminal of the service request related to the terminal 120, provide the notification adapted to comprise the session identity to the proxy node 110. The notification is adapted to notify the proxy node 110 that the terminal 120 is no longer suspended. The terminal 120 is further configured to provide the notification over the WebSocket connection between the proxy node 110 and the terminal 120. The notification is adapted to reconnect the terminal 120 to the IMS network 105.

The provided notification may be adapted to be the request to re-establish the WebSocket connection. The request is adapted to trigger the proxy node 110 to re-establish the WebSocket connection.

The terminal 120 is further configured to, e.g. by means of a receiving unit 930 in the terminal 120, receive the service request from the proxy node 110, enabling the terminal 120 to handle the service request without performing a new registration procedure to the IMS network 105.

The terminal 120 is further configured to, e.g. by means of the receiving unit 930 in the terminal 120, receive the push notification from the push server 130. The push notification is adapted to notify the terminal 120 of the service request.

The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor 940 of a processing circuitry in the terminal 120 depicted in Figure 9a, 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 terminal 120. 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 terminal 120.

The terminal 120 may further comprise a memory 950 comprising one or more memory units. The memory 950 comprises instructions executable by the processor 940 in the terminal 120. The memory 950 is arranged to be used to store e.g. information, messages, indications, notifications, service requests, connections, identities, communication data and applications to perform the methods herein when being executed in the terminal 120.

In some embodiments, a computer program 960 comprises instructions, which when executed by the respective at least one processor 940, cause the at least one processor 940 of the terminal 120 to perform the actions above.

In some embodiments, a respective carrier 970 comprises the respective computer program 960, wherein the carrier 970 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 terminal 120 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 terminal 120, 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) .

Further Extensions and Variations

With reference to Figure 10, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, which comprises an access network 3211, such as a radio access network, and a core network 3214. The core network 3214 may e.g. comprise the proxy node 110. The access network 3211 comprises a plurality of

base stations

3212a, 3212b, 3212c, e.g. the base station 105, 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 3214 over a wired or wireless connection 3215. A first user equipment (UE) such as the terminal 120 and/or a Non-AP STA 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 such as another terminal 120 and/or a Non-AP STA in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of

UEs

3291, 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The

connections

3221, 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown) .

The communication system of Figure 10 as a whole enables connectivity between one of the connected

UEs

3291, 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected

UEs

3291, 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211, the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Figure 11. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to setup and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311, which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Figure 11) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Figure 11) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to setup and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331, which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides. It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Figure 11 may be identical to the host computer 3230, one of the

base stations

3212a, 3212b, 3212c and one of the

UEs

3291, 3292 of Figure 10, respectively. This is to say, the inner workings of these entities may be as shown in Figure 11 and independently, the surrounding network topology may be that of Figure 10.

In Figure 11, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the use equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network) .

The wireless connection 3370 between the UE 3330 and the base station 3320 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 3330 using the OTT connection 3350, in which the wireless connection 3370 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] .

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which

software

3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc. ; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the

software

3311, 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Figure 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. 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 Figure 10 and Figure 11. For simplicity of the present disclosure, only drawing references to Figure 12 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional substep 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 3440, the UE executes a client application associated with the host application executed by the host computer.

Figure 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. 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 Figure 10 and Figure 11. For simplicity of the present disclosure, only drawing references to Figure 13 will be included in this section. In a first step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 3530, the UE receives the user data carried in the transmission.

Figure 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. 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 Figure 10 and Figure 11. For simplicity of the present disclosure, only drawing references to Figure 14 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally, or alternatively, in an optional second step 3620, the UE provides user data. In an optional substep 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional substep 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer. In a fourth step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Figure 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. 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 Figure 10 and Figure 11. For simplicity of the present disclosure, only drawing references to Figure 15 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.

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

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.

Claims

A method performed by a proxy node (110) for maintaining a registration of a terminal (120) to an Internet Protocol, IP, Multimedia Subsystem, IMS, network (105) , in a communications network (100) , the terminal (120) subscribing to a push notification service for receiving push notifications from a push server (130) , the method comprising:

upon a successful registration procedure of the terminal (120) to the IMS network (105) , establishing (301) a WebSocket connection to the terminal (120) , which connection is established using a session identity obtained by the terminal (120) during the registration procedure,

triggered by the establishing (301) of the WebSocket connection, maintaining (302) the registration of the terminal (120) to the IMS network (105) by periodically updating the registration also when the terminal (120) is suspended,

receiving (303) a service request related to the terminal (120) from the IMS network (105) ,

after instructing the push server (130) to notify the terminal (120) of the service request, obtaining (305) a notification comprising the session identity from the terminal (120) , the notification notifying the proxy node (110) that the terminal (120) is no longer suspended, the notification being obtained over the WebSocket connection between the proxy node (110) and the terminal (120) , which notification reconnects the terminal (120) to the IMS network (105) ,

sending (306) the service request to the terminal (120) , enabling the terminal (120) to handle the service request without performing a new registration procedure to the IMS network (105) .
The method according to claim 1, wherein the obtained (305) notification is a request to re-establish the WebSocket connection, which request triggers the proxy node (110) to re-establish the WebSocket connection.
The method according to any of claims 1-2, wherein receiving (303) the service request further comprises storing the received service request, and

wherein sending (306) the service request further comprises retrieving the stored service request.
The method according to any of claims 1-3, further comprising:

instructing (304) the push server (130) to send a push notification to the terminal (120) , which push notification notifies the terminal (120) of the service request.
The method according to any of claims 1-4, wherein the establishing of the WebSocket connection further comprises receiving a request to establish the WebSocket connection from the terminal (120) , which request comprises the session identity, and sending a response to the terminal (120) , the response indicating a successful establishing of the WebSocket connection.
The method according to any of claims 1-5, wherein the registration procedure comprises sending the session identity to the terminal (120) .
A computer program (890) comprising instructions, which when executed by a processor (870) , causes the processor (870) to perform actions according to any of the claims 1-6.
A carrier (895) comprising the computer program (890) of claim 7, wherein the carrier (895) 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.
A method performed by a terminal (120) for maintaining a registration of the terminal (120) to an Internet Protocol, IP, Multimedia Subsystem, IMS, network (105) , in a communications network (100) , the terminal (120) subscribing to a push notification service for receiving push notifications from a push server (130) , the method comprising:

upon a successful registration procedure of the terminal (120) to the IMS network (105) , establishing (401) a WebSocket connection to a proxy node (110) , which connection is established using a session identity obtained by the terminal (120) during the registration procedure, wherein the establishing (401) of the WebSocket connection triggers the proxy node (110) to maintain the registration of the terminal (120) to the IMS network (105) , by periodically updating the registration, also when the terminal is suspended,

after receiving a push notification from the push server (130) , the push notification notifying the terminal of a service request related to the terminal (120) , providing (403) a notification comprising the session identity to the proxy node (110) , the notification notifying the proxy node (110) that the terminal (120) is no longer suspended, the notification being provided over the WebSocket connection between the proxy node (110) and the terminal (120) , which notification reconnects the terminal (120) to the IMS network (105) ,

receiving (404) the service request from the proxy node (110) , enabling the terminal (120) to handle the service request without performing a new registration procedure to the IMS network (105) .
The method according to claim 9, wherein the provided (403) notification is a request to re-establish the WebSocket connection, which request triggers the proxy node (110) to re-establish the WebSocket connection.
The method according to any of claims 9-10, further comprising:

receiving (402) a push notification from the push server (130) , which push notification notifies the terminal (120) of the service request.
The method according to any of claims 9-11, wherein the establishing of the WebSocket connection further comprises sending a request to establish the WebSocket connection to the proxy node (110) , which request comprises the session identity, and receiving a response from the proxy node (110) , the response indicating a successful establishing of the WebSocket connection.
The method according to any of claims 9-12, wherein the registration procedure comprises receiving the session identity from the proxy node (110) .
A computer program (960) comprising instructions, which when executed by a processor (940) , causes the processor (940) to perform actions according to any of the claims 9-13.
A carrier (970) comprising the computer program (960) of claim 14, wherein the carrier (970) 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.
A proxy node (110) configured to maintain a registration of a terminal (120) to an Internet Protocol, IP, Multimedia Subsystem, IMS, network (105) , in a communications network (100) , the terminal (120) further being configured to subscribe to a push notification service for receiving push notifications from a push server (130) , the proxy node (110) further being configured to:

upon a successful registration procedure of the terminal (120) to the IMS network (105) , establish a WebSocket connection to the terminal (120) , which connection is adapted to be established using a session identity obtained by the terminal (120) during the registration procedure,

triggered by the establishing of the WebSocket connection, maintain the registration of the terminal (120) to the IMS network (105) by periodically updating the registration also when the terminal (120) is suspended,

receive a service request adapted to be related to the terminal (120) from the IMS network (105) ,

after instructing the push server (130) to notify the terminal (120) of the service request, obtain a notification adapted to comprise the session identity from the terminal (120) , the notification being adapted to notify the proxy node (110) that the terminal (120) is no longer suspended, the notification adapted to be obtained over the WebSocket connection between the proxy node (110) and the terminal (120) , which notification is adapted to reconnect the terminal (120) to the IMS network (105) ,

send the service request to the terminal (120) , enabling the terminal (120) to handle the service request without performing a new registration procedure to the IMS network (105) .
The proxy node (110) according to claim 16, wherein the obtained notification is adapted to be a request to re-establish the WebSocket connection, which request is adapted to trigger the proxy node (110) to re-establish the WebSocket connection.
The proxy node (110) according to any of claims 16-17, wherein the proxy node (110) is configured to receive the service request by further being configured to store the received service request, and

wherein the proxy node (110) is configured to send the service request by further being configured to retrieve the stored service request.
The proxy node (110) according to any of claims 16-18, further being configured to:

instruct the push server (130) to send a push notification to the terminal (120) , which push notification is adapted to notify the terminal (120) of the service request.
The proxy node (110) according to any of claims 16-19, wherein the proxy node (110) is configured to establish the WebSocket connection by further being configured to receive a request to establish the WebSocket connection from the terminal (120) , which request is adapted to comprise the session identity, and send a response to the terminal (120) , the response being adapted to indicate a successful establishing of the WebSocket connection.
The proxy node (110) according to any of claims 16-20, wherein the registration procedure is adapted to comprise sending the session identity to the terminal (120) .
A terminal (120) configured to maintaining a registration of the terminal (120) to an Internet Protocol, IP, Multimedia Subsystem, IMS, network (105) , in a communications network (100) , the terminal (120) further being configured to subscribe to a push notification service for receiving push notifications from a push server (130) , the terminal (120) further being configured:

upon a successful registration procedure of the terminal (120) to the IMS network (105) , establish a WebSocket connection to a proxy node (110) , which connection is adapted to be established using a session identity obtained by the terminal (120) during the registration procedure, wherein the establishing of the WebSocket connection is adapted to trigger the proxy node (110) to maintain the registration of the terminal (120) to the IMS network (105) , by periodically updating the registration, also when the terminal (120) is suspended,

after receiving a push notification from the push server (130) , the push notification being adapted to notify the terminal of a service request related to the terminal (120) , provide a notification adapted to comprise the session identity to the proxy node (110) , the notification being adapted to notify the proxy node (110) that the terminal (120) is no longer suspended, the terminal (120) further being configured to provide the notification over the WebSocket connection between the proxy node (110) and the terminal (120) , which notification is adapted to reconnect the terminal (120) to the IMS network (105) ,

receive the service request from the proxy node (110) , enabling the terminal (120) to handle the service request without performing a new registration procedure to the IMS network (105) .
The terminal (120) according to claim 22, wherein the provided notification is adapted to be a request to re-establish the WebSocket connection, which request is adapted to trigger the proxy node (110) to re-establish the WebSocket connection.
The terminal (120) according to any of claims 22-23, further comprising:

receive a push notification from the push server (130) , which push notification is adapted to notify the terminal (120) of the service request.
The terminal (120) according to any of claims 22-24, wherein the terminal (120) is configured to establish the WebSocket connection by further being configured to send a request to establish the WebSocket connection to the proxy node (110) , which request is adapted to comprise the session identity, and receive a response from the proxy node (110) , the response being adapted to indicate a successful establishing of the WebSocket connection.
The terminal (120) according to any of claims 22-25, wherein the registration procedure is adapted to comprise to receive the session identity from the proxy node (110) .