Patent Description:
The invention is within the context of fixed mobile convergence (FMC). FMC means that a <NUM> core network controls the usage of fixed access lines, such as DSL or optical fiber, in such a way that user authentication, session management and user data transfer is done by the <NUM> core network according to 3GPP standards. This is especially advantageous in hybrid access scenarios in which a user equipment connects to <NUM> network by using a mobile data path and a fixed line data path. A so-called <NUM> residential gateway (<NUM>-RG) is needed at the edge of the home network in order to interact with the <NUM> core of the data network and to provide data connectivity to user equipment within the home network. This user equipment is typically connected to the <NUM>-RG via Wi-Fi or LAN.

"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on the support for 5WWC, Phase <NUM> (Release <NUM>)" discloses a method for selecting and applying a dedicated QoS class for a user equipment within a home network that communicates with a <NUM> core network.

Today's <NUM>-RG devices only provide a default QoS class to a user equipment so that is currently not possible to tailor the PDU sessions to the actual demands of an application running on the user equipment and/or to the user equipment itself.

Therefore, it is the task of the invention to provide techniques to overcome the usage of only a default QoS class within a home network when communicating with a <NUM> core network.

According to a first aspect of the invention, the invention provides a method for selecting and applying a dedicated QoS class for a user equipment within a home network, wherein the user equipment communicates with a data network via the home network. The data network is in particular a <NUM> core network.

This enables the advantage that dedicated QoS classes can be applied when the user equipment communicates with the data network via the home network. This enables the user, the user equipment and/or the network provider to dynamically control QoS mapping via the <NUM> core across available pipes (user/app -> 5GC NEF -> URSP -> 5GRG). A further advantage is that the <NUM> core network can be used very efficiently as the QoS classes are tailored to the technical requirements of the UE. The solution enables to dynamically change or adapt the QoS of a given data connection within the home network and towards the external data network (DN) in a consistent way.

In an embodiment, the dedicated QoS class is selected based on a static table that assigns the dedicated QoS classes to a corresponding traffic descriptor. This enables a selection from a unique assignment between multiple QoS classes with the corresponding traffic descriptor.

In an embodiment, the table is stored within a server of the data network or within the RG.

If the table is stored within a server of the data network, in particular within the network entity, this provides the advantage that the assignment between the multiple QoS classes and the traffic descriptors can be easily and efficiently updated by the network provider. Information from the network can be used to identify an application that is running on the UE and to identify the dedicated QoS class. The necessary information can be provided by so-called QFI parameters. On the other hand, storing the table within the RG provides the advantage that the dedicated QoS can be selected without using computational resources of the network provider as it is known in the context of the so-called edge computing principles.

In an embodiment, the traffic descriptor is designed in such a way that a minimum requirement for a QoS class can be determined from it.

This provides the advantage that the dedicated QoS class provides sufficient resources to run the communication of the user equipment with the data network.

In an embodiment, possible traffic descriptors are:.

This provides the advantage that these traffic descriptors can be extracted from communication protocols that are already in use. Already one of the traffic descriptors, in particular the physical port on the <NUM>-LG, the Wi-Fi SSID or the MAC source, is in principal sufficient to select the dedicated QoS class for the communication. A combination of these traffic descriptors enables a further differentiation to find dedicated QoS classes that are tailored even better for the respective communication.

In an embodiment, the dedicated QoS class is selected based by a user assignment of the UE to the dedicated QoS.

As already mentioned above, this enables the user to assign a desired QoS class to his UE. For example, if the user is in a home office and awaits an important video conference call it might be desirable to assign the highest available QoS class to the user equipment. This is enabled by the user assignment even if the automatic selection process based on the traffic descriptors would not have selected the highest available QoS class to the user equipment. The user assignment can be done directly at the <NUM>-RG and/or by means of a companion app, in particular if the network entity performs the selection.

In an embodiment, the user assignment is automatically reset after a certain time or manually reset by the user.

This provides the advantage that the assignment is automatically cleared so that the UE does not stay within a desired QoS class to which it actually does not belong based on the traffic descriptors. It is possible to run applications with various demands regarding quality of service on a single user equipment. Without resetting the assignment, the user assignment would lead to the situation that the UE communicates with an QoS class that is not tailored to its actual needs. In reality, this might lead to the situation that all UEs will communicate with the highest QoS class.

In an embodiment, the UE measures levels of at least one key performance indicator (KPI) and changes to other traffic descriptors if the key performance indicator is outside a pre-defined key performance window.

In an embodiment, the UE changes to traffic descriptors that correspond to a better QoS class if the KPIs are worse than needed for running a current application or that the UE changes to traffic descriptors that correspond to a less better QoS class if the KPIs are better than needed for running the current application.

The measurement can be performed periodically, wherein the frequency of the measurement can depend on the UE and/or on the application that is running on the UE. KPIs can be latency, packet loss, bandwidth and/or jitter values. For example, for a certain running application and/or a UE an acceptable key performance window for the latency can be predefined to be <NUM> to <NUM>. If the measurement yields a latency of <NUM>, then a better QoS class is needed in order to obtain latency value between <NUM> to <NUM>. In this case, an algorithm within the UE will choose a set or single traffic descriptor that corresponds to a better QoS class and to transmit this adjusted traffic descriptor with the communication. On the other hand, if the measured latency will you use a latency of <NUM> it might be possible to switch to a less better QoS class because a less better QoS class will in general consume fewer resources than the better QoS class. Instead of using predefined KPI windows it is also possible to use predefined KPI threshold values.

In an embodiment, the UE measures levels of at least one KPI, in particular regarding a running application, wherein a customized QoS class is created and applied as the first QoS class for the UE if the measured KPIs exceed pre-defined KPI threshold values. The customized QoS class can be created and applied on the first and/or on the second communication link. In that context, the customized QoS class can be described as being a special kind of dedicated QoS class. The different wording is mainly used to distinguish between the fact, that the QoS class can already exist or that they can be created on request.

Creating a customized QoS class provides the advantage that there is no need to create multiple QoS classes in advance and learn to choose one of these multiple QoS classes as the dedicated QoS class. Within the context of <NUM> and it is easily possible to create such QoS class on the fly which has the additional advantage that they can exactly be tailored to the needs of the UE and/or the running application. This also covers use cases that are a kind of unexpected so that currently no QoS class exists that is tailored to this use case.

In an embodiment, the first QoS class and the second QoS class are identical. For that purpose, it is possible that the data network adjusts its QoS class along the second communication link accordingly. It is possible that the data network does this automatically based on the received identification and the received traffic descriptor as described above are that the information about which quality of service shall be applied to the second QoS class is being shared between the UE, the RG and/or the data network. For example, a respective application can invoke an API to the <NUM> core network which can trigger appropriate changes of the QoS settings within the <NUM> core, the aggregation and the access. Depending on theses changings the <NUM>-RG can modify the corresponding settings with the internal home network for the respective application. This provides means to dynamically change and mapping the QoS settings along the whole data path of the communication.

This provides the advantage that the UE and/or the running application can be provided with a uniform QoS class across the whole communication path between the user equipment and the data network, in particular with a service within the data network. Typically, if the first QoS class and the second QoS class do not match this leads to a performance degradation or to a waste of computational resources as follows: if the first QoS class is better than the second QoS class, then is likely to happen that the quality of service cannot be maintained if the data packets travel through the second QoS class. On the other hand, if first QoS class is worse than the second QoS class, then the quality of service for the data packets traveling through the second QoS class can be maintained but this would also be the case if the second QoS class would be identical to the first QoS class.

According to a second aspect, a user equipment is provided that is designed to send traffic descriptors when communicating with the data network, and/or the RG. The user equipment can be a computer, a smart phone, a tablet, a server or the like. Typically, the user component comprises a processing unit to run algorithms, in particular to run a selection algorithm that can select the dedicated QoS class or that can change the traffic descriptors as described above. In particular, the UE is configured to measures levels of KPIs and to change to other descriptors as described above. The UE comprises at least a communication interface that is configured to communicate over the first communication link.

According to a third aspect, a Residential Gateway is provided that is configured to perform the steps according to the method described above. The RG can be a <NUM>-RG or a FN-RG. The RG comprises a processing unit to run algorithms, in particular to run a selection algorithm that can select the dedicated QoS class or that can change the traffic descriptors as described above. In particular, the RG is configured to measures levels of KPIs and to change to other descriptors as described above. The RG comprises at least a communication interface that is configured to communicate over the first communication link and over the second communication link. The RG is configured to adapt the QoS class of the first communication link.

According to a fourth aspect, a Communication System comprising a User equipment as described above, a Residential Gateway "RG" as described above, and a data network, wherein the UE communicates with the data network over a communication path, wherein the communication path comprises a first communication link of a first QoS class between the UE and the RG, in particular a <NUM>-RG or a FN-RG, and a second communication link of a second QoS class between the RG and the data network, wherein the Communication System is configured to perform the steps according to the method described above.

A computer program comprising instructions which, when the program is executed by a network entity of a data network or a RG, cause the computer to carry out the method described above.

In the following detailed description, reference is made to the accompanying drawings, which form part of the disclosure, and in which are shown, by way of illustration, specific aspects in which the present invention may be placed. It is understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, as the scope of the present invention is defined by the appended claims.

The <NUM> communication standard promises a significant improvement for its users in terms of stability, the provision of network frame conditions tailored to the customer, reduced latency, etc. In order to make the best possible use of the <NUM> communication standard, efforts are being made to operate both mobile communication and communication via wired lines together within the <NUM> standard.

Since the <NUM> communications standard has its origins in mobile communications and its core network is designed accordingly, the obvious effort is to adapt wireline communications with regard to the already existing mobile infrastructure. Hence, in the following some concepts of <NUM> communication will be described in the context of how it is currently done in the <NUM> cellular environment.

The approaches to "unify" the wired and the mobile world is often called fixed mobile convergence (FMC), where a <NUM> core network also controls the usage of fixed access lines such as DSL or optical fiber or cable in a way that user authentication, session management and the user data transfer is done by the <NUM> core network according to 3GPP standards.

In <NUM>, a "PDU Session" is used to provide end-to-end user plane connectivity between the UE and a specific Data Network (DN) through the User Plane Function (UPF). A PDU Session supports one or more QoS Flows. There is a one-to-one mapping between QoS Flow and QoS profile, i.e. all packets belonging to a specific QoS Flow have the same "<NUM> Quality of Service Identifier" (5QI).

Existing standards for FMC are: BBF TR-<NUM>, BBF TR-<NUM> and 3GPP TS <NUM>.

A generic <NUM> core network is shown in <FIG>.

Typically, (in mobile networks) a UE (user equipment) is a smartphone and the (R)AN is a radio access network. In FMC, the UE is replaced by a <NUM>-RG or a FN-RG and the (R)AN by an Access Gateway Function (AGF) as can be seen for example in <FIG> that shows an exemplary architectural framework of the communication system.

Differentiation between <NUM>-RG and FN-RG:.

In the following, three different use cases are discussed:.

<FIG> shows a communication system <NUM> comprising of a user equipment <NUM> and a <NUM>-RG <NUM>, wherein a first communication link <NUM> is established between the user equipment <NUM> and to the <NUM>-RG <NUM>.

The user equipment <NUM> comprises of an application client <NUM> that communicates with an operating system <NUM> of the user equipment <NUM>.

The <NUM>-RG <NUM> comprises a modem <NUM> with a URPS, a handler <NUM> and a mapping table <NUM>. The <NUM>-RG <NUM> also comprises communication interfaces <NUM>, <NUM> for a dedicated PDU session and a default PDU session. The dedicated PDU session and the default PDU session are technically realized over the second communication link <NUM>. The PDU sessions provide the QoS classes that means that the dedicated PDU session provides the dedicated QoS class and the default PDU session provides the default QoS class. The handler <NUM> can comprise a data link to a AMF and a PCF of the <NUM> core network, wherein that data link is used to set or update the URSP mapping table, for example after registration of the <NUM>-RG <NUM> for the use case <NUM>. These PDU sessions are used to communicate with the data network, in particular a <NUM> core network. Finally, the user equipment <NUM> can communicate with an application server (AS) <NUM>.

The <NUM>-RG <NUM> initially selects a default QoS class as the first QoS class for the UE <NUM>. The communication comprises an identification of the UE <NUM> and a traffic descriptor that is received by the <NUM>-RG <NUM>. The left column 123a of the mapping table <NUM> shows that in this exemplary case the traffic descriptors SSID, MAC, IP, and/or Port are received. The right column 123b of the mapping table <NUM> shows the dedicated QoS class that is selected based on the will use of the received traffic descriptors. The right column 123b is named "route selection descriptor" and describes the properties of the dedicated QoS class. In the next step, the <NUM>-RG <NUM> applies the dedicated QoS class as the first QoS class for the communication over the first communication link <NUM> so that the communication is being tailored to the needs of the user equipment <NUM>.

In the following, the different use cases will be discussed in detail:.

All three use cases provide the advantage that dedicated QoS classes can be applied when the user equipment communicates with the data network via the home network. This enables the user, the user equipment and/or the network provider to dynamically control QoS mapping via the <NUM> core across available pipes (user/app -> 5GC NEF -> URSP -> 5GRG). A further advantage is that the <NUM> core network can be used very efficiently as the QoS classes are tailored to the technical requirements of the UE. The solution enables to dynamically change or adapt the QoS of a given data connection within the home network and towards the external data network (DN) in a consistent way.

<FIG> shows the flow chart of the inventive method that can be implemented as an algorithm on a computer product.

Step <NUM>: Initially selecting a default QoS class for the first QoS class for the UE, wherein the communication comprises an identification of the UE and/or a traffic descriptor;.

Step <NUM>: Receiving the traffic descriptor by the <NUM>-RG <NUM>;.

Step <NUM>: Selecting a dedicated QoS class based on a user input and on the received identification, or wherein the <NUM>-RG <NUM> selects the dedicated QoS class based on the received identification and the received traffic descriptor by the <NUM>-RG.

Step <NUM>: Applying the dedicated QoS class as the first QoS class by the <NUM>-RG <NUM>.

Claim 1:
A method for selecting and applying a dedicated quality-of-service, QoS, class for a user
equipment (<NUM>) within a home network (<NUM>) that communicates with a data network (<NUM>),
wherein the UE (<NUM>) communicates with the data network (<NUM>) over a communication path, wherein the communication path comprises a first communication link (<NUM>) of a first QoS class between the UE (<NUM>) and a Residential Gateway, RG, (<NUM>) and a second communication link (<NUM>) of a second QoS class between the RG and the data network (<NUM>),
wherein the RG (<NUM>) initially selects a default QoS class (<NUM>) for the first QoS class for the UE (<NUM>),
wherein the communication comprises an identification of the UE (<NUM>) and a traffic descriptor that is received by the RG (<NUM>),
wherein the RG (<NUM>) selects a dedicated QoS class based on the received identification and the received traffic descriptor, and wherein the RG (<NUM>) applies the dedicated QoS class (<NUM>) as the first QoS class.