Patent Description:
Existing functionality on some User Equipment (UE) devices of cellular networks allows the UE to act as a Wireless Local Area Network (WLAN) hotspot to provide Internet access via the cellular connection of the UE. Where the UE device is a user client terminal, this is commonly known as tethering, but alternatively the UE device may be designed for the specific purpose of providing a WLAN hotspot. For the purposes of the present disclosure, the UE device providing a WLAN hotspot is termed a host device. An application may be provided on the host device to provide appropriate functionality, for example.

Referring to <FIG>, there is a schematically shown a known configuration for communicating between a client device and a network via a host device. This may be termed WLAN "offload". The client device <NUM> communicates with the host device <NUM> over a WLAN interface <NUM> (for example using IEEE <NUM>. 11ac protocol). The host device <NUM> communicates with a base station <NUM> of the network using a cellular interface <NUM>. The cellular interface <NUM> may be based on a Long Term Evolution (LTE) or <NUM> protocol. The host device <NUM> uses a best effort bearer to communicate data to, from or for the client device <NUM>. Optionally, the client device <NUM> may also communicate directly with the network via the base station <NUM> (or via another base station) using cellular interface <NUM>.

In such systems, the host device <NUM> only makes itself available to act as a WLAN access point if it has a connection to the base station <NUM> over the cellular interface <NUM> meeting Quality of Service (QoS) criteria, for example as discussed in <CIT>. The client device <NUM> may also use algorithms to decide whether to communicate via the host device <NUM> over WLAN interface <NUM> or directly to the network over cellular interface <NUM>.

Cellular interfaces are improving, for example with the introduction of New Radio (NR) or <NUM>. These benefits are not necessarily gained when communicating between client devices and the network via a host device. Improving such communication, to realize potential advantages, is therefore desirable.

<CIT> concerns configuring route selection policies. A user device may send, to a computing device, a route selection policy request to update route selection policy rules for applications and/or services of the user device. The computing device may determine the route selection policy rules for the applications and/or services based on various criteria. The computing device may send the determined route selection policy rules to the user device. If the user device does not accept the determined route selection policy rules, the user device may send, to the computing device, a negotiation request to obtain other route selection policy rules for the applications and/or services. Additional background art is represented by <CIT> and <CIT>.

Against this background, the present disclosure provides a method for configuring communication between a client device and a host device using a first Radio Access Technology (RAT) according to claim <NUM>, a computer program as defined by claim <NUM> and a host device for operating with a network in line with claim <NUM>. Other preferred features are disclosed with reference to the claims and in the description below.

In specific embodiments, the host device communicates with a base station of a network using a second RAT, to provide services of the network to or from the client device. Where the term "communicate" is used herein, this may include transmission and/or reception of signals, information or both. In the preferred embodiment, the first RAT may be a Wireless Local Area Network (WLAN) RAT or a Personal Area Network (PAN) RAT (for instance, based on Bluetooth (RTM)) or even a different Wide Area Network (WAN) RAT (for example, <NUM>) and the second RAT may be a WAN RAT, such as a cellular network RAT (for example, based on <NUM> technology). In communication between the host device and the base station (over the second RAT), data traffic is distinguished in accordance with a set of network traffic rules (for example, network slicing rules). Information relating to the set of network traffic rules, comprising a UE Route Selection Policy (URSP), information derived from the URSP or a network slicing configuration, is communicated from the host device to the client device. Then, the communication between the client device and the host device using the first RAT is configured according to a set of client traffic rules. The client traffic rules are based on the information about the network traffic rules communicated from the host device. This may be implemented as a method, a computer program and/or or in hardware, for example, in or as the host device.

The approach of the disclosure may be put into practice in various ways, one of which will now be described by way of example only and with reference to the accompanying drawings in which:.

Where a drawing indicates a feature also shown in another drawing, identical reference numerals have been used.

Reference is again made to <FIG>, in which there is a schematically shown a configuration for communicating between a client device and a network via a host device. An analysis of a 3GPP Traffic Flow Template (TFT) is performed to create a mapping between an Internet Protocol (IP) <NUM>-tuple (including: source IP address, destination IP address, source port number, destination port number, and protocol type) and a desired bearer for use over the cellular interface <NUM>, for example as defined in 3GPP TS <NUM>, section <NUM>. <NUM> (and/or other standards and specifications).

For uplink, a mapping between data communicated over the WLAN interface <NUM> and a QoS Class Identifier (QCI) to be used by the host device <NUM> over the cellular interface <NUM> is performed. Conversely for downlink, a mapping between data to be communicated over the WLAN interface <NUM> and a QoS Class Identifier (QCI) used by the host device <NUM> over the cellular interface <NUM> is performed.

The host device <NUM> communicates with the base station <NUM> over the cellular interface <NUM> using a best effort bearer. Also, low latency features may be used, if supported by the host device <NUM>. This approach allows a certain amount of network slicing to be carried over the WLAN interface <NUM>. However, developments to improve network slicing over cellular interfaces, particularly in <NUM> technology mean that this approach will not allow full benefit over network slicing to be obtained when a client device communicates with a network through a host device.

<NUM> network slicing allows greater customisation and better differentiation of traffic than is possible in <NUM> (LTE). To allow network slicing to be extended to client devices communicating through a host device, a number of desiderata can be considered: slice information to distributed to client devices, even outside of the normal coverage footprint of the cellular network; creation of a link between the client device and host device that offers an extended enhanced performance, to enable slicing over this link; activation of slice capabilities on the host device, even if it is not normally subscribed to the capability, allowing it to carry the sliced traffic of the client; and enhanced behaviour in the case that the <NUM> network tries to prevent WLAN offloading for traffic of a particular application.

Referring now to <FIG>, there is schematically depicted a configuration and first method for communicating between a client device and a network via a host device according to the disclosure. As in the previous drawing, the configuration comprises: a client device <NUM>; a host device <NUM>; and a base station of the network <NUM>. The client device <NUM> communicates with the host device <NUM> via a WLAN interface <NUM> and the host device <NUM> communicates with the base station <NUM> via a cellular network RAT interface <NUM> (which may be a <NUM> or NR RAT interface, for instance). As part of the communication via the cellular network RAT interface <NUM>, the host device <NUM> is subscribed to one or more network slices (as defined in 3GPP TS <NUM> and/or other standards and specifications). Optionally, the client device <NUM> also communicates with the base station <NUM> (or another base station) via a cellular network RAT interface (not shown).

In a method according to the disclosure, the client device <NUM> makes a request <NUM> for URSP support information from the host device <NUM>. The request <NUM> may be a simple request for any information or it may provide details about the services and/or applications using data traffic at the client device <NUM>. Optionally, the request can indicate URSP information already present at the client device <NUM>. The URSP provides a mapping between IP traffic characteristics and network slices, for example as defined in 3GPP TS <NUM> and TS <NUM> (see for example, section <NUM>. <NUM> of v. <NUM>) and/or other standards and specifications. In response to the request <NUM>, the host device <NUM> provides URSP information <NUM> (for example, the URSP or information based on the URSP) to the client device <NUM>. The URSP information is provided from the base station <NUM> to the host device <NUM> using standard communication <NUM> of the cellular network RAT interface <NUM>.

The host device <NUM> may then create, select or otherwise define a mapping <NUM> between data traffic for communication over the WLAN interface <NUM> (in particular based on the URSP network slicing information) and one or more parameters of the WLAN interface <NUM>. These may use scheduling or prioritisation and/or segregation of transmissions on the WLAN interface <NUM> (for example, based on a frequency band and/or channel, bandwidth, QoS or other identifier). Prioritisation can be use one or more of an internal scheduler-defined prioritisation, mapping to DSCP priorities for the link (for instance), channel queue and channel segregation. In this way, the client device <NUM> and host device <NUM> may recreate equivalent slice prioritisations across the WLAN interface <NUM> to those between the host device <NUM> and the base station <NUM>.

The mapping <NUM> may correspond with a set of client traffic rules, applied at the client device <NUM> and/or the host device <NUM> for traffic over the WLAN interface <NUM>. The host device <NUM> typically determines the mapping <NUM> and communicates the mapping <NUM> to the client device <NUM>, but the client device <NUM> could determine the mapping <NUM> and communicate the mapping <NUM> to the host device <NUM> or the mapping <NUM> could be agreed in a distributed way. The mapping <NUM> may be set by a selection of pre-stored mappings and the communication of this selection from the client device <NUM> to the host device <NUM>. The mapping <NUM> is advantageously stored at both the client device <NUM> and the host device <NUM>.

The client device <NUM> can then map any application usage requests for the appropriate slice to the host device <NUM> using the mapping <NUM>, which then maps to the network defined standard slice over the cellular network RAT interface <NUM>, using a URSP mapping <NUM>.

The data traffic is then communicated <NUM> between the client device <NUM> and the host device <NUM> over the WLAN interface <NUM> using the mapping <NUM> and communicated <NUM> between the host device <NUM> and the base station <NUM> over the cellular network RAT interface <NUM> using the URSP mapping <NUM>. The network slicing over the cellular network RAT interface <NUM> is implemented by additional identifiers indicating a logic for processing the data traffic at the network.

In this way, the client device <NUM> and/or host device <NUM> can determine the mapping <NUM> between network slicing of the cellular network RAT interface <NUM> and parameters of the WLAN interface <NUM> based on the URSP information received from the host device <NUM>. Optionally, the client device <NUM> may receive URSP information <NUM> directly from the base station <NUM> (or another base station of the cellular network) and the mapping <NUM> can be determined using this received URSP information <NUM>. In such cases, the received URSP information <NUM> from the host device <NUM> and/or the received URSP information <NUM> from the network may be used to update existing stored URSP information at the client device <NUM> or the client device <NUM> may store multiple sets of URSP information (for either or both of the routes from the host device <NUM> and the network) and when new URSP information is received, this may be stored in addition to the existing stored information. The client device <NUM> may also conduct a best candidate evaluation process, to determine whether to communicate data traffic with the network via the host device <NUM> or directly without the need for the host device <NUM> (for instance, via the base station <NUM>).

In general terms, there may be considered an approach (for example a method) for configuring communication between a client device and a host device using a first RAT (for instance, WLAN). The host device communicates with a base station of a network using a second RAT (for instance a cellular network RAT, for example, NR or <NUM>), to provide services of the network to or from the client device. The second RAT is different from the first RAT. The communication between the host device and the base station distinguishes data traffic in accordance with a set of network traffic rules (for example, a URSP or network slicing configuration). The approach comprises: communicating, from the host device to the client device, information relating to the set of network traffic rules, comprising the URSP, data based on the URSP or a network slicing configuration; and configuring the communication between the client device and the host device using the first RAT, according to a set of client traffic rules (for example, rules for differentiating traffic over the first RAT) that are based on the communicated information about the network traffic rules. Approaches in accordance with the disclosure may be implemented as a method, a computer program (which may be embodied on a computer readable medium), for example configured when operated by a processor to perform an approach according to the disclosure and/or as a device for operating with a network (for instance a client device or a host device). The device may be configured to communicate using a first RAT and/or a second RAT, different from the first RAT and may be arranged to operate in accordance with an approach according to the disclosure. As noted above, the term "communicate" as used herein may include transmission and/or reception of the relevant signals and/or information.

The set of network traffic rules typically comprises a mapping between at least one characteristic of the data traffic and a plurality of traffic types. For instance (and in accordance with a URSP as defined in 3GPP TS <NUM> and/or other standards and specifications), the at least one characteristic of the data traffic comprises one or more of : an application-related information for the data traffic; a traffic descriptor for the data traffic; a destination address and/or domain for the data traffic; an origin address and/or domain for the data traffic; a port number for the data traffic; a protocol information for the data traffic; a connection capability; a route selection descriptor; a route precedence; a session and service continuity mode information; a network slice information; a data network name; a protocol data unit session type; a time characteristic or criterion; and a location characteristic or criterion. The information relating to the set of network traffic rules may comprise one or both of: the set of network traffic rules (for example, the host device may communicate the URSP to the client device); and the set of client traffic rules, which are based on the set of network traffic rules (for instance, the host device may work out the parameters of the first RAT based on the URSP and transmits just those and not necessarily the URSP).

The set of client traffic rules (which may be considered as the client or host device telling the other which parameters of the first RAT to use) may differentiate at least one parameter of the communication using the first RAT between different data traffic, to distinguish the data traffic thereby. Additionally or alternatively, the set of client traffic rules may identify at least one parameter of the communication using the first RAT. In either or both cases, each of the at least one parameter may comprise one of: a frequency band and/or channel; a bandwidth; a scheduling; a priority; and a Quality of Service, QoS.

Preferably, the information relating to the set of network traffic rules received from the host device is stored at the client device. Additionally or alternatively, information relating to the set of network traffic rules is received from the base station (or another base station) using the second RAT at the client device and this is optionally stored at the client device.

The approach may further comprise communicating, from the client device to the host device, a request for information relating to the set of network traffic rules. The step of communicating information relating to the set of network traffic rules from the host device to the client device may then be made in response to the request.

Configuring may comprise communicating between the client device and the host device one or both of: the set of client traffic rules; and a selection of the set of client traffic rules from a stored plurality of sets of client traffic rules.

In some embodiments, the client device has at least one stored set of client traffic rules prior to the step of communicating information relating to the set of network traffic rules from the host device to the client device. For instance, the client may be preprogrammed with these rules (for example, WLAN parameters) or the client device may have received the rules from somewhere else previously. In embodiments, the stored set of client traffic rules at the client device may be updated, based on the information relating to the set of network traffic rules communicated from the host device. Alternatively, the set of client traffic rules that are based on the communicated information relating to the set of network traffic rules may be stored in addition to the at least one set of client traffic rules stored prior to the step of communicating information relating to the set of traffic rules from the host device to the client device.

In embodiments, the client device stores a plurality of sets of client traffic rules. Then, configuring may comprise selecting a set of client traffic rules from the stored plurality of sets of client traffic rules. Advantageously, the communication between the client device and the host device using the first RAT is configured according to the selected set of client traffic rules. As noted above, Information relating to the set of network traffic rules may be communicated from a base station of the network to the client device using the second RAT. In that case, at least one set of client traffic rules of the plurality of sets of client traffic rules may be based on the communicated information about the network traffic rules from the base station.

Next, reference is made to <FIG>, in which there is schematically illustrated a configuration and second method for communicating between a client device and a network via a host device according to the disclosure. The configuration of the client device <NUM>, the host device <NUM> and the base station of the network <NUM> is the same as shown in <FIG>, but the procedure implemented between the client device <NUM>, the host device <NUM> and the base station <NUM> may vary. Initially, a network slice information request <NUM> is communicated from the client device <NUM> to the host device <NUM>. The network slice information request <NUM> indicates a network slice for use by data traffic between the client device <NUM> and the network and/or one or more parameters of the data traffic that would allow the host device <NUM> to determine an appropriate network slice.

The host device <NUM> identifies that it not subscribed to the required network slice. It is therefore triggered to communicate a network slice temporary access request <NUM> to the base station <NUM>. The base station <NUM> responds with a slice enablement response <NUM>. The slice enablement response <NUM> can authorise or reject the temporary access request <NUM>. To determine the slice enablement response <NUM>, the network slice temporary access request <NUM> is reviewed by the network (for example, checking that the host device <NUM> is trusted and/or if satisfactory performance can be assured based on the host device <NUM>). If the review indicates a positive result, the authorisation of the requested slice is made on the network and the host device <NUM> is notified in the slice enablement response <NUM>.

Based on the slice enablement response <NUM>, the host device <NUM> then provides URSP information or slice support information <NUM> to the client device <NUM>. In this way, the support is then relayed to the client device <NUM> for inclusion in its best candidate evaluation process. The procedure discussed above (with reference to <FIG>) is then followed, for: determining the mapping <NUM>; communicating <NUM> the data traffic between the client device <NUM> and the host device <NUM> over the WLAN interface <NUM> using the mapping <NUM>; and communicating <NUM> the data traffic <NUM> between the host device <NUM> and the base station <NUM> over the cellular network RAT interface <NUM> using the URSP mapping <NUM>.

A brief description of uplink and downlink traffic flow between applications on the client and the network service will now be provided. Referring to <FIG>, there is schematically shown an example of uplink traffic flow from a client device <NUM> to a network via a host device <NUM>. With the client device <NUM>, there is provided: an application <NUM>, using higher layers of the communication protocol stack; and a communications interface <NUM>, using lower layers of the communication protocol stack. The application <NUM> generates data traffic <NUM>, which is sent to the communications interface <NUM>. The communications interface <NUM> uses standard URSP metrics to understand the desired slice type or profile. The communications interface <NUM> may choose to send the data traffic <NUM> to the network directly or to send the data traffic <NUM> to the network via the host device <NUM>. The communications interface <NUM> uses the determined mapping <NUM> to send the data traffic <NUM> to the host device <NUM> using the WLAN interface <NUM>. The host device <NUM> receives the data traffic <NUM> and relays the data traffic <NUM> to the base station <NUM>, over the cellular network RAT interface <NUM>, using the slice type defined in the URSP equivalent to the mapping <NUM>.

Now referring to <FIG>, there is schematically shown an example of downlink traffic flow to a client device <NUM> from a network via a host device <NUM>. Data traffic <NUM> is mapped to a network slice at the base station <NUM>. The mapping infers parameters for relaying the data traffic <NUM> from the host device <NUM> to the client device <NUM>, such as low latency. The host device <NUM> receives the data traffic <NUM> and relays the data traffic <NUM> to the client device <NUM> over the WLAN interface <NUM>. This uses the mapping <NUM> between the slice type defined in the URSP and one or more parameters of the WLAN interface <NUM>. The communications interface <NUM> of the client device <NUM> receives the data traffic <NUM> and sends the relayed data traffic <NUM> to the application <NUM>.

The network may indicate a restriction in the URSP for certain applications or certain traffic flows not to use a WLAN "offload", that is not to communicate with the client device <NUM> via the host device <NUM>. For the purposes of approaches according to the present disclosure, the mapping <NUM> does not implement such a restriction, but rather treats the WLAN interface <NUM> between the client device <NUM> and the host device <NUM> as a normal connection and not as a WLAN connection.

Returning to the general terms of the approach according to the disclosure discussed above, in embodiments, the request may indicate at least one characteristic of data traffic used to provide the services of the network to or from the client device via the host device using the first RAT. In that case, an incompatibility between the set of network traffic rules and the at least one characteristic of data traffic indicated by the request may be identified at the host device. An adjustment to the communication between the host device and the base station and/or the set of network traffic rules may then be requested from the host device to the base station. The adjustment may be based on the identified incompatibility. In particular, the incompatibility may comprise a lack of access by the host device to a network slice of the network, for example when the network slice corresponds with the at least one characteristic of data traffic indicated by the request.

Although specific embodiments have now been described, the skilled person will understand that various modifications and variations are possible. Also, combinations of any specific features shown with reference to one embodiment or with reference to multiple embodiments are also provided, even if that combination has not been explicitly detailed herein.

Specific modifications and variations in alternative embodiments will now be discussed. For example, although a WLAN interface has been considered above, the skilled person would understand that alternative Local Area Network (LAN), Personal Area Network (PAN) or similar RATs may be considered, such as Bluetooth (RTM). In addition, the WLAN interface could be replaced by a Wide Area Network (WAN) interface, such as a cellular network architecture, for instance, a <NUM> (or LTE) interface. In particular, this interface (termed the first RAT above) will typically not have the same traffic differentiation (for instance, slice information) as the <NUM> interface (or more generally, the second RAT), but a mapping corresponding to that differentiation can be provided according to the present disclosure.

Similarly, whilst a <NUM> cellular network RAT has been considered above, other possibilities may be considered based on other wireless network architectures, for example using network slicing. Network slicing has been discussed herein as a preferred approach for traffic differentiation, but it will be understood that other types of traffic differentiation may be employed and a mapping provided over the first RAT of the host device accordingly, in particular for alternative second RAT architectures.

Whilst the first and second RATs are different, examples not according to the claims, in which the first and second RATs are the same may be conceived. This may result in a more intelligent repeater, offering different capabilities for different client devices at the same time.

Claim 1:
A method for configuring communication between a client device (<NUM>) and a host device (<NUM>) using a first Radio Access Technology, RAT (<NUM>), the host device (<NUM>) communicating with a base station (<NUM>) of a network using a second RAT (<NUM>), different from the first RAT (<NUM>), to provide services of the network to or from the client device (<NUM>), the communication between the host device and the base station distinguishing data traffic in accordance with a set of network traffic rules, the method comprising:
communicating (<NUM>, <NUM>), from the host device (<NUM>) to the client device (<NUM>), information relating to the set of network traffic rules, the information relating to the set of network traffic rules comprising a User Equipment Route Selection Policy, URSP, data based on a URSP or a network slicing configuration;
configuring, at the client device (<NUM>) and the host device (<NUM>), the communication between the client device (<NUM>) and the host device (<NUM>) using the first RAT (<NUM>), according to a set of client traffic rules (<NUM>) that are based on the communicated information about the network traffic rules; communicating the data traffic between the host device (<NUM>) and the client device (<NUM>) using the first RAT (<NUM>); and communicating the data traffic between the host device (<NUM>) and the base station (<NUM>) using the second RAT (<NUM>).