Technical Field

The present invention relates a method and apparatus for ensuring an appropriate Quality of Service for a user in a Public Land Mobile Network, and in particular in a 5G network.

Background

5G is intended to provide the next generation of cellular networks, promising greatly increased capacity and data transfer speeds. 3GPP TS 23.501 (current version V1.4.0) defines a 5G system architecture and is an evolving document.

Section 5.7 of TS 23.501 specifies a Quality of Service (QoS) model which supports QoS flows that require a guaranteed flow bit rate and QoS flows that do not require such a guaranteed flow bit rate. A QoS Flow ID (QFI) is used to identify a QoS flow in the 5G system. User Plane traffic is assigned to radio bearers appropriate to the QoS as identified by the QFI. User Plane traffic with the same QFI within a given Protocol Data Unit (PDU) session receives the same traffic forwarding treatment over the radio interface (e.g. scheduling, admission threshold). The QFI is carried in an encapsulation header and can be applied to PDUs with different types of payload, i.e. IP packets, unstructured PDUs and Ethernet frames. The QFI is unique within a PDU session.

At a User Equipment (UE), the UE performs the classification and marking of uplink (UL) User plane traffic, i.e. the association of uplink traffic to QoS flows, based on QoS rules. A QoS rule contains a QoS rule identifier which is unique within the PDU session, the QFI of the associated QoS flow, one or more packet filters and a precedence value. A default QoS rule is required for every PDU session. The default QoS rule is the only QoS rule of a PDU session that may contain no packet filter (in this case, the highest precedence value (i.e. lowest priority) has to be used). If the default QoS rule does not contain a packet filter, the default QoS rule defines the treatment of packets that do not match any other QoS rule in a PDU session.

The 5G QoS model makes provision for so-called“reflective QoS” according to which the UE creates a derived QoS rule, this rule being derived from a DL packet, i.e. from the header of that packet. The UE uses the derived QoS rules to determine mapping between UL traffic and QoS flow. The QFI of the UE derived QoS rule is set according to the QFI identified in the DL packet. The UE indicates support for reflective QoS to the network during the PDU session establishment. A User Plane Function (UPF) may include in an encapsulation header of the DL packet an indication that reflective QoS should be activated for the corresponding UL flow.

If reflective QoS applies, the UE creates a new derived QoS rule when a DL packet is received containing a QFI for which no UL QoS rule exists. The packet filter in the derived QoS rule is derived from the (i.e. the header of the) DL packet, and the QFI of the UE derived QoS rule is set according to the QFI of the DL packet. Specifically, the UE uses the source IP address and port number contained in the DL packet as the destination IP address and port number for the derived QoS rule and vice versa.

The QoS model further specifies that, for a UE derived QoS rule, the UE shall start a timer set to a Reflective QoS (RQ) Timer value. This value is either signalled to the UE upon PDU Session establishment or set to a default value. Upon RQ timer expiry the UE deletes the corresponding UE derived QoS rule. For any subsequent UL packets including the corresponding QFI, the UE will either reject the packet or apply a default QoS rule. For each DL packet containing the QFI, the UE will either restart the timer if the previous RQ timer has not expired, or start a new RQ timer if it has expired.

For TCP sessions involving a UE, in some cases there can be relatively long periods of inactivity during which no packets are exchanged and specifically during which no DL packets are received by the UE. This is true, for example, with chat sessions where several minutes or longer may elapse between messages. For such TCP sessions the RQ timer at the UE may expire such that no QoS rule is present when a packet is next received by the UE, or only a default QoS rule is applied. This can lead to either no service being provided or an inappropriate service being provided.

Summary

According to a first aspect of the present invention there is provided a method, carried out at a User Equipment, UE, for maintaining a reflective Quality of Service, QoS, rule for an uplink QoS flow associated with a Transport Control protocol, TCP, session. The method comprises receiving on a downlink bearer a TCP packet accompanied by a QoS Flow ID, QFI, and reacting to receipt of said TCP packet by establishing a reflective Quality of Service, QoS, rule for a corresponding uplink QoS flow. The method further comprises binding the reflective QoS rule to the TCP session so that the rule is maintained as long as the session exists and is invalidated when the TCP session is terminated.

The UE may implement a 5G stack providing QoS handling including reflective QoS, the 5G stack being configured to inspect TCP packets to determine when the TCP session is terminated.

According to a second aspect of the present invention there is provided a User Equipment comprising a processor, memory and a cellular radio transceiver and being configured to maintain a reflective Quality of Service, QoS, rule for an uplink QoS flow associated with a Transport Control protocol, TCP, session. The User Equipment is further configured to receive on a downlink bearer a TCP packet accompanied by a QoS Flow ID, QFI, react to receipt of said TCP packet by establishing a reflective Quality of Service, QoS, rule for a corresponding uplink QoS flow, and bind the reflective QoS rule to the TCP session so that the rule is maintained as long as the session exists and is invalidated when the TCP session is terminated. The cellular radio transceiver may be a 5G cellular radio transceiver with the User Equipment implementing a 5G stack.

According to a third aspect of the present invention there is provided a method, carried out at a User Equipment, UE, for maintaining a reflective Quality of Service, QoS, rule for an uplink QoS flow associated with a Transport Control protocol, TCP, session. The method comprises receiving on a downlink bearer a TCP packet accompanied by a QoS Flow ID, QFI, reacting to receipt of said TCP packet by establishing a reflective Quality of Service, QoS, rule for a corresponding uplink QoS flow and starting an associated reflective QoS, RQ, timer, the rule being invalidated when the timer expires, and configuring a TCP keepalive function including setting a keepalive message interval to a value less than the RQ timer value such that, during periods of session inactivity, keepalive messages are sent to a peer TCP session endpoint and acknowledgements received therefrom prior to expiry of the RQ timer causing the RQ timer to be restarted.

According to a fourth aspect of the present invention there is provided a User Equipment comprising a processor, memory and a cellular radio transceiver and being configured to maintain a reflective Quality of Service, QoS, rule for an uplink QoS flow associated with a Transport Control protocol, TCP, session. The User Equipment is further configured to receive on a downlink bearer a TCP packet accompanied by a QoS Flow ID, QFI, and react to receipt of said TCP packet by establishing a reflective Quality of Service, QoS, rule for a corresponding uplink QoS flow and starting an associated reflective QoS, RQ, timer, the rule being invalidated when the timer expires. The User Equipment is still further configured to configure a TCP keepalive function including setting a keepalive message interval to a value less than the RQ timer value such that, during periods of session inactivity, keepalive messages are sent to a peer TCP session endpoint and acknowledgements received therefrom prior to expiry of the RQ timer causing the RQ timer to be restarted.

According to a further aspect of the invention there is a provided a method implemented in a communication system including a host computer, a base station and a user equipment (UE), the method comprising:

at the host computer, receiving user data transmitted to the base station from the UE, wherein the UE is configured to maintain a reflective Quality of Service, QoS, rule for an uplink QoS flow associated with a Transport Control protocol, TCP, session. The User Equipment is further configured to receive on a downlink bearer a TCP packet accompanied by a QoS Flow ID, QFI, react to receipt of said TCP packet by establishing a reflective Quality of Service, QoS, rule for a corresponding uplink QoS flow, and bind the reflective QoS rule to the TCP session so that the rule is maintained as long as the session exists and is invalidated when the TCP session is terminated. The cellular radio transceiver may be a 5G cellular radio transceiver with the User Equipment implementing a 5G stack.

The method may further comprise, at the UE, providing the user data to the base station.

The method may further comprise, at the UE, executing a client application, thereby providing the user data to be transmitted, and, at the host computer, executing a host application associated with the client application.

The method may further comprise, at the UE, executing a client application and receiving input data to the client application, the input data being provided at the host computer by executing a host application associated with the client application, wherein the user data to be transmitted is provided by the client application in response to the input data.

Brief Description of the Drawings

Figure 1 illustrates schematically a 5G User Equipment with a QoS flow established between it and an application server via a radio access network and a 5G core network with a modification to configure a TCP keepalive procedure in the User Equipment; Figure 2 illustrates signalling and functionality associated with various components illustrated in Figure 1 ;

Figure 3 illustrates signalling and functionality associated for associating a reflective QoS rule with a TCP/IP session to prevent premature removal of the rule;

Figure 4 is a flow diagram illustrating a first method for avoiding premature removal of a Reflective QoS rule;

Figure 5 is a flow diagram illustrating a second method for avoiding premature removal of a Reflective QoS rule;

Figure 6 illustrates a 3GPP-type network comprising an access network and a core network facilitating Over the Top (OTT) services provided over a connection with endpoints at a host computer and a UE;

Figure 7 illustrates example implementations of a host computer, a base station and a UE involved in an OTT connection;

Figure 8 is a flowchart illustrating a transmitting-side method in a communication system including a host computer, a base station and a UE; and

Figure 9 is a flowchart illustrating a receiving-side method in a communication system including a host computer, a base station and a UE.

Detailed Description

The following discussion assumes a 5G system architecture consistent with 3GPP TS 23.501 , or with future developments of that system which still provide for reflective QoS as a mechanism for defining a QoS rule to be applied to packets of an uplink (UL) QoS flow associated with a DL QoS flow.

Embodiments of the present invention are implemented principally at the User Equipment which is a computer device with a wireless transceiver capability and implementing amongst other things a 5G stack. The UE comprises appropriate hardware including one or more processors, memory, user interfaces etc. The memory stores appropriate software code for implementing the 5G stack and other software systems including a TCP/IP stack and one or more applications. Examples of applications (apps) include web browsers, voice and video calling apps, messaging and chat apps, etc.

Figure 1 illustrates schematically a 5G UE 1 which may be, for example, a smartphone with hardware and software configured to implement a plurality of applications 2, a TCP/IP stack 3, and a 5G stack 4. The 5G stack is in turn configured to make use of one or more Data Radio Bearers (DRB) 5 provisioned in a radio access network illustrated by base station 6. QoS flows are transmitted over the DRB between the UE and a 5G core (5GC) network 7. Figure 1 illustrates as an end point for one of the QoS flows an application server 8. In the case of a chat service, the application server 8 may be a server, accessed via the Internet, operated by a chat service provider, with the relevant application 2 in the UE being a chat application provided by the service provider and installed by a user on the UE. Figure 1 illustrates application data, e.g. chat message traffic, being passed from the application 2 to the TCP/IP stack with corresponding TCP/IP datagrams being passed between the TCP/IP stack and the 5G stack.

As discussed above, User Plane traffic is assigned to radio bearers appropriate to the QoS as identified by the QFI. User Plane traffic with the same QFI within a given Protocol Data Unit (PDU) session receives the same traffic forwarding treatment over the radio interface (e.g. scheduling, admission threshold).

Reflective QoS (RQ) is used in order to derive a QoS rule for an UL flow corresponding to a given DL flow. According to the currently defined 5G system architecture, when an RQ QoS rule is derived and installed, a reflective QoS (RQ) timer is started. The timer value is either signalled to the UE upon PDU Session establishment or set to a default value. Upon RQ timer expiry the UE deletes the corresponding UE derived QoS rule.

In order to prevent removal of an RQ QoS rule for certain long-lived sessions which may have relatively long periods of inactivity (during which no TCP/IP datagrams are transmitted), it is proposed here to enable the 5G stack, upon establishment of an RQ QoS rule, to configure the TCP/IP stack to implement TCP keepalive (this assumes of course that the TCP/IP stack implements the otherwise optional TCP keepalive function). This TCP/IP keepalive configuration procedure is illustrated in Figure 1 and utilises an API of the operating system for the TCP/IP stack. Specifically, the 5G stack will set the TCP keepalive interval to a (time) value that is less than the value of the RQ timer by an amount sufficient to ensure that a keepalive TCP/IP datagram can be sent to the peer entity (the application server in Figure 1 ) and an acknowledgement received before the RQ timer expires. Receipt of the acknowledgement will cause the RQ timer to be restarted (as would be the case with any received TCP/IP packet for the QoS flow).

It may be the case that the TCP/IP stack allows only a single, default, keepalive interval value to be set in which case the interval value, once set by the 5G stack, will apply to all QoS flows. Alternatively the interval value may be set on a per TCP/IP flow basis allowing different interval values to be set for different QoS flows.

Figure 2 is a diagram illustrating signalling and functionality associated with this approach. The Figure illustrates the following signalling points: TCP/IP stack and 5G stack present in the terminal (UE); a 5GS network (i.e. including both radio and core networks) where an endpoint for a PDU session with the UE may be a User Plane Function (UPF); a TCP/IP application present at the peer node (e.g. application server).

Signalling first establishes a PDU session between the (5G stack of the) UE and the 5G core network. The core network establishes a QoS rule for downlink traffic (towards the UE) and installs this in the radio access network. The core network also signals to the 5G stack the requirement for RQ. When the 5G stack of the UE receives a first DL packet for the PDU session, containing the appropriate QFI, it will create and install a new RQ rule associated with the same QFI. The RQ timer will be started with a value set to a default value or possibly a value provided to it by the network. The 5G stack immediately configures the TCP/IP stack to implement TCP keepalive with an appropriate interval value as discussed above. TCP/IP packets are exchanged between the peers periodically. Flowever, following an interval during which no packets are received by the terminal on the UL, the TCP keepalive timer times out. This causes the TCP/IP stack to send to the peer entity a TCP keepalive message, causing the peer entity to respond with an acknowledgement. When the 5G stack in the UE receives this acknowledgment, it restarts the RQ timer. Of course, after sending the TCP keepalive message, the TCP/IP stack will have restarted its own keepalive timer.

This method for avoiding premature removal of a Reflective QoS rule is further illustrated in the flow diagram of Figure 4. Figure 3 illustrates signalling and functionality associated with an alternative solution for the problem of early RQ timer timeout. Rather than implementing an RQ timer within the 5G stack at the terminal, when the RQ QoS rule is established and installed, that rule is bound to the corresponding TCP session. As long as the session remains alive, the RQ QoS rule remains installed. The 5G stack may detect the end of the session by examining TPC/IP packets. For example, it might identify when a packet has the FIN (finish) bit set, and/or when an acknowledgement for such a packet is sent or received.

It is noted that, for the UL, a QoS filter corresponding to the QoS rule may also be present within the 5G network. This filter is installed in the network at the same time as the RQ QoS rule is installed in the UE. The network may similarly examine TCP/IP packets of the session to identify when the session ends and take action to remove the filter.

This method for avoiding premature removal of a Reflective QoS rule is further illustrated in the flow diagram of Figure 5.

With reference to FIGURE 6, 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 access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as 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) 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 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 6 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 7. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up 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 7) 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 7) 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 set up 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 6 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 6, respectively. This is to say, the inner workings of these entities may be as shown in Figure 7 and independently, the surrounding network topology may be that of Figure 6.

In Figure 7, 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. [If the radio-related invention has not yet been formulated at the time of drafting a provisional application, the expression“embodiments described throughout this disclosure” is meant to refer to the radio-related embodiments disclosed elsewhere in the application.] 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 8 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 and a UE which may be those described with reference to Figures 6 and 7. For simplicity of the present disclosure, only drawing references to Figure 8 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 9 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 and a UE which may be those described with reference to Figures 6 and 7. For simplicity of the present disclosure, only drawing references to Figure 9 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.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention.