Methods and systems for policy exchange for atsss coverage

Abstract

A communication system including a policy entity for accessing traffic steering, switching, and splitting ATSSS coverage configured to provide multi-connectivity without ATSSS user plane functionality, a mobile core, a user equipment, UE, and a multi-connectivity provider with a multi-connectivity termination point, wherein the policy entity is configured to communicate rules specific to ATSSS coverage with the UE and / or to the multi-connectivity termination point.

Description

Technical Field

[0001] This invention relates to a method and system for policy switching for ATSSS coverage. Background Technology

[0002] Typically, internet network operators offer customers one or more access methods, such as fixed (e.g., xDSL), Wi-Fi (e.g., public hotspots), or cellular (e.g., 2G-5G). Even if those customers possess user equipment (UEs) (such as smartphones) that could potentially connect to multiple access points simultaneously, they do not utilize this capability due to the lack of multi-connectivity technologies. For smartphones, this is a common scenario with simultaneous availability of Wi-Fi and cellular networks, where applications are stuck with one access and cannot benefit from a second available access in terms of reliability and speed.

[0003] Network protocols that can leverage the potential of multiple access points (such as Multipath Transport Protocol (MPTCP), Multipath Fast UDP Internet Connection (MP-QUIC), Multipath Datagram Congestion Control Protocol (MPDCCP), and Flow Control Transport Protocol (SCTP)) are not widely adopted and typically require end-to-end implementation. Therefore, widespread and rapid availability is impractical.

[0004] Standardized multi-connectivity architectures (such as 3GPP Release 16 standard TS 23.501, Release 16.5.0, 3GPP Access Traffic-Guided Handover Split (ATSSS) part of July 9, 2020) promise to provide remedies and use such protocols between the UE and the mobile network operator (MNO). Furthermore, these architectures provide comprehensive traffic management capabilities for operators(s) using such architectures.

[0005] ATSSS manages simultaneous connectivity for the UE through cellular (3GPP access) and non-cellular access (e.g., untrusted non-3GPP access – third-party Wi-Fi), and Figure 1 It was described in the text.

[0006] Figure 1 An exemplary ATSSS architecture, as defined by 3GPP TS 23.501, is explained. Figure 1 In this context, ATSSS manages simultaneous connectivity for the UE through cellular (3GPP access) and non-cellular access (untrusted non-3GPP access, such as Wi-Fi). Figure 1 As shown, the UE uses the N3 interface of the ATSSS-UPF (User Plane Functions) portion facing the 5G core to connect to the data network (DN) via cellular (3GPP access) and Wi-Fi (untrusted non-3GPP access).

[0007] UPF can be understood as the interface between the UE and the data network (e.g., the Internet) responsible for traffic management. Figure 1 As shown, other entities / functions forming the core of 5G are: Access and Mobility Management Function (AMF), Session Management Function (SMF), and Policy Control Function (PCF). Furthermore, Figure 1 The names of the interfaces exposed by each of these entities are also shown.

[0008] A key feature of the ATSSS architecture is the accompanying policy framework, which leverages the 5G control plane to exchange traffic management rules. In the 5G core, the PCF is responsible for providing ATSSS-related policies to the ATSSS UPF via the N4 interface or to the UE via the NAS. PCF control:

[0009] • Boot mode used to boot / switch / split detected Service Data Stream (SDF).

[0010] • Boot functionality for detected SDFs, such as MPTCP functionality or ATSSS-LL functionality.

[0011] • Billing information depends on the access type used by the detected SDF.

[0012] • Usage monitoring information depends on the access type used by the detected SDF.

[0013] More detailed information about PCF can be found in 3GPP Release 16 Standard TS 23.501, Version 16.5.0, July 9, 2020, Section 6.1.3.20.

[0014] Furthermore, according to 3GPP TS 23.501, ATSSS requires 5GC and cannot be integrated into the 4G core (EPC). Additionally, due to the lack of proper Multi-Access Protocol Data Unit (MA PDU) handling, ATSSS interoperability between 4G and 5G is not supported. These limitations may lead to a delayed introduction of ATSSS.

[0015] The above limitations can be overcome by introducing partial integration of ATSSS, such as... Figure 2 The example shown herein is referred to as “ATSSS coverage”. The difference between ATSSS coverage and ATSSS as defined by 3GPP is that it provides multi-connectivity without ATSSS user plane functionality.

[0016] Figure 2The explanation describes User Equipment 1 (UE) (supporting ATSSS capability) connecting to Data Network 2 (DN) via multipath. One path uses the 4G / 5G Radio Access Network (RAN), while the other path uses WiFi / Fixed Core. Both paths connect to ATSSS coverage. The ATSSS coverage is characterized by utilizing multipath support from at least a new back-end entity, which is similar to the ATSSS UPF on the back-end side, without requiring the same level of integration.

[0017] In other words, this means that backend components can also be located in mobile virtual network operators (MVNOs), multi-connectivity providers with or without their own access resources, mobile network operators (MNOs) with EPCs, MNOs not coupled to basic core components (e.g., SMF, AMF, PCF), fixed network operators (FNOs), or public cloud environments.

[0018] Refer again Figure 2 The ATSSS coverage provides an alternative to 3GPP TS 23.501, supporting similar user plane mechanisms. However, the ATSSS coverage lacks support for the control plane incorporating ATSSS policy switching in 3GPP TS 23.501.

[0019] Technical issues

[0020] The established mechanism for exchanging tariff and subscription-based information between the MNO and UE is the Rights Server, disclosed in TS.43 Service Rights Configuration, version 5.0, April 3, 2020. This document specifies rights for Voice over Wi-Fi (VoWiFi), Voice over LTE (VoLTE), SMS over IP (SMSoIP), and On-Demand Service Activation (ODSA) (e.g., for eSIM). Multiple authentication schemes in the mentioned document support UE and / or customer identification, providing opportunities to offer highly specialized rights and even policies.

[0021] However, currently, the rights server does not support ATSSS overlay.

[0022] In view of the above, the object of the present invention is to provide a policy entity with a policy mechanism for ATSSS coverage. Preferably, the policy entity provides an out-of-band policy mechanism decoupled from user plane provisioning.

[0023] Another object of the present invention is to extend the rights server by utilizing support for ATSSS coverage.

[0024] Another object of the present invention is to define rules / policies that vary depending on ATSSS coverage, such as in 5GC PCF or EPC PCRF and / or in the rights server or in the interconnected BSS and / or in newly defined entities residing in the core.

[0025] Another objective of this invention is to provide the requesting UE with rules / policies that vary depending on ATSSS coverage. Summary of the Invention

[0026] The above objectives are achieved through the features of the independent claims.

[0027] According to one aspect of the invention, a communication system is provided, comprising a policy entity for accessing Traffic Guidance, Handover and Split (ATSSS) coverage, a mobile core, a user equipment (UE), and a multi-connectivity provider with a multi-connectivity endpoint, wherein the ATSSS coverage is configured to provide multi-connectivity without ATSSS user plane functionality, and wherein the policy entity is configured to communicate rules that differ due to the ATSSS coverage with the UE and / or to the multi-connectivity endpoint.

[0028] In other words, the aforementioned features regarding ATSSS coverage providing multiple connectivity without ATSSS user plane functionality mean that ATSSS coverage is independent of the 3GPP-defined ATSSS or the 3GPP-defined mobile core.

[0029] According to a preferred aspect, the policy entity is configured to use out-of-band communication to communicate with the UE and / or multiple connectivity termination points.

[0030] According to one preferred aspect, the rules that vary depending on ATSSS coverage include one or more of the following parameters: instructions on enabling or disabling ATSSS coverage; information about the ATSSS coverage core server, including IP address, port number, and / or fully qualified domain name (FQDN); ATSSS coverage traffic management rules for bootstrapping, switching, and splitting; and ATSSS coverage information, including application information, destination address information, location information, network protocol information, and environmental information.

[0031] According to a preferred aspect, the system further includes a policy entity for ATSSS as defined by 3GPP, such that the policy entity for ATSSS coverage and the policy entity for ATSSS as defined by 3GPP coexist in the communication system.

[0032] According to a preferred aspect, the policy entity for ATSSS coverage is further configured to communicate rules that differ due to ATSSS coverage to the policy entity for ATSSS.

[0033] According to a preferred aspect, the policy entity for ATSSS is configured to communicate ATSSS rules to the policy entity for ATSSS.

[0034] According to one preferred aspect, the mobile core is configured to notify the UE of the availability of ATSSS coverage.

[0035] According to one preferred aspect, the policy entity used for ATSSS coverage is the rights server.

[0036] According to another aspect of the invention, a method is provided for exchanging policies by a policy entity within an ATSSS coverage in a communication system, the communication system including a mobile core, a user equipment (UE), and a multi-connectivity provider with a multi-connectivity endpoint, wherein the ATSSS coverage provides multi-connectivity without ATSSS user plane functionality, the method comprising: communicating rules that vary due to the ATSSS coverage from the policy entity to the UE and / or to the multi-connectivity endpoint.

[0037] In other words, the aforementioned features regarding ATSSS coverage providing multiple connectivity without ATSSS user plane functionality mean that ATSSS coverage is independent of the 3GPP-defined ATSSS or the 3GPP-defined mobile core.

[0038] According to one preferred aspect, the strategy entity uses out-of-band communication to communicate with the UE and / or multiple connectivity termination points.

[0039] According to one preferred aspect, the rules that vary depending on the ATSSS coverage include one or more of the following parameters: instructions on enabling or disabling ATSSS coverage; information about the ATSSS coverage core server, including IP address, port number, and / or fully qualified domain name (FQDN); ATSSS coverage traffic management rules for bootstrapping, switching, and splitting; and ATSSS coverage information, including application information, destination address information, location information, network protocol information, and environmental information.

[0040] According to a preferred aspect, the system further includes a policy entity for ATSSS as defined by 3GPP, such that the policy entity for ATSSS coverage and the policy entity for ATSSS as defined by 3GPP coexist in the communication system.

[0041] According to a preferred aspect, the policy entity for ATSSS coverage communicates the rules that vary depending on the ATSSS coverage to the policy entity for ATSSS.

[0042] According to a preferred aspect, the policy entity for ATSSS communicates the ATSSS rules to the policy entity for ATSSS coverage.

[0043] According to one preferred aspect, the mobile core notifies the UE of the availability of ATSSS coverage.

[0044] According to one preferred aspect, the policy entity used for ATSSS coverage is the rights server.

[0045] Other aspects, features, and advantages will be apparent from the above overview and from the following description (including the drawings and claims).

[0046] Brief description of the attached figures

[0047] In the attached diagram:

[0048] Figure 1 The principles of the 3GPP ATSSS architecture based on existing technology were explained.

[0049] Figure 2 The principles of the ATSSS coverage architecture based on existing technology were explained.

[0050] Figure 3 An exemplary top-mounted ATSSS coverage independent of network operators, according to an embodiment of the present invention, is explained.

[0051] Figure 4 An exemplary ATSSS coverage with an MNO providing access, multipath traffic management, and a rights server, according to an embodiment of the present invention, is explained.

[0052] Detailed description of the invention

[0053] The following description and figures assume that the user equipment (UE) (such as, for example, a smartphone or a residential gateway (RG)) is equipped with Wi-Fi and cellular access interfaces or fixed (such as DSL) and cellular access interfaces. However, this can be adapted to any other multi-connectivity scenario with more or other access options.

[0054] Figure 3 An exemplary top-mounted ATSSS coverage independent of network operator has been described according to an embodiment of the present invention. In this context, the ATSSS coverage is provided by a multi-connectivity provider without access to assets within the operator's network.

[0055] Alternatively, ATSSS coverage can be combined with mobile network operators (MNOs) that provide access and multipath traffic management.

[0056] like Figure 3The less integrated multi-connectivity network shown is characterized by the utilization of multipath support from at least a new backend entity, also referred to in the following description as an ATSSS overlay core server, which is similar to ATSSSSUPF on the backend side without requiring the same level of integration. Specifically, this means that the new backend component can also reside in a mobile virtual network operator (MVNO), a multi-connectivity provider with or without its own access resources, a mobile network operator (MNO) with an EPC, an MNO not coupled to the underlying core components (e.g., SMF, AMF, PCF), a fixed network operator (FNO), or a public cloud environment.

[0057] Preferably, the new backend entity is compared with ATSSS UPF, which is a lightweight implementation with only some or different functionalities. The supported multipath protocol can be similar to ATSSS UPF MPTCP (such as MP-DCCP, MP-QUIC, QUIC, SCTP).

[0058] In any case, partial integration of ATSSS (hereinafter referred to as ATSSS coverage) does not require all access to be owned by the multi-connectivity provider.

[0059] Figure 4 An exemplary ATSSS coverage with a mobile network operator (MNO) providing access, multipath traffic management, and a rights server, according to an embodiment of the present invention, is explained.

[0060] Some possible rules / policies provided by the policy entity due to subscription information, which vary depending on ATSSS coverage, may include: 1) General: Enable / disable ATSSS coverage; 2) ATSSS coverage core server: IP address (:port) / FQDN; 3) ATSSS coverage traffic management rules: bootstrapping / switching / splitting; 4) ATSSS coverage scope: application (e.g., name), destination (IP address / port / AS), location (coordinates, connected base station, etc.), network protocol (e.g., TCP / UDP), environment (campus / public / roaming).

[0061] ATSSS coverage means that it applies to any traffic or selected traffic as given by the ATSSS coverage policy.

[0062] Rules 1)-4) can be combined arbitrarily and provided as a rule set. Detection of policy entities follows the rules in Chapter 2 of TS.43 Service Rights Configuration, version 5.0, April 3, 2020. Clients (i.e., UEs) can obtain the address of the rights configuration server by following the discovery procedure, which has an FQDN obtained based on the following format:

[0063] aes.mnc<mnc>.MCC <mcc>.pub.3gppnetwork.org.

[0064] The UE is configured to implement a method for interpreting ATSSS-related policies enforced by the policy entity.

[0065] Leveraging existing functionalities related to the policy framework PCRF / PCF in the 4G core and / or 5G core, it allows for the definition (in part) of ATSSS rules maintained in these entities. This also facilitates full ATSSS compatibility with 3GPP technical specification: 23.501, version 16.5.0, July 9, 2020.

[0066] In this context, the invention further requires information exchange from the PC(R)F to the policy entity and from the policy entity to the PC(R)F. This is particularly useful if ATSSS and ATSSS overlays coexist. In this scenario, it can be advantageous to maintain ATSSS-related policies or subsets thereof at one location instead of maintaining them at different locations (PC(R)F and policy entity). Linking different policy entities allows policies to be specified on one entity and copied to the other.

[0067] In situations where policies must be provided from a newly defined core entity that is not yet defined like a PC(R)F or a policy entity, the UE recognizes that the policy entity becomes crucial. The 3GPP, responsible for the 4G core and 5GC, and the GSMA, which designates the rights server, have established procedures, for example, [4] TS.43 Service Rights Configuration, version 5.0, April 3, 2020, Chapter 2. At least the latter proposes a simple method that is available under a designated fully qualified domain name (FQDN) that can be verified by the UE. Preferably, the same method can be adopted by the policy entity (which in some cases can be the same as the rights server). Another mechanism uses the MNO and the existing policy framework of the connected UE (e.g., PC(R)F) to convey the presence of the policy entity.

[0068] According to one embodiment, another approach could be to use (hidden) SMS to announce availability from the network.

[0069] Compared to PC(R)F or equity servers, the newly defined policy entity (potentially dedicated to out-of-band ATSSS coverage policy exchange) may be simpler and less complex. This is because PC(R)F and equity servers are relatively complex and cumbersome when only a few ATSSS coverage policies are needed. This can become crucial for small / restricted networks such as campuses / enterprises.

[0070] Although the invention has been described and illustrated in detail in the accompanying drawings and the foregoing description, such description and illustration are to be regarded as illustrative or exemplary, and not restrictive. It will be understood that changes and modifications can be made by those skilled in the art within the scope of the appended claims. Specifically, the invention covers further embodiments having any combination of features from the various embodiments described above and below.

[0071] Furthermore, in the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude the plural. A single unit can perform the function of several features recited in the claims. Specifically, terms related to attributes or values, such as "substantially," "about," and "approximately," precisely define the attribute or precisely define the value, respectively. Any reference numerals in the claims should not be construed as limiting the scope.< / mcc> < / mnc>

Claims

1. A communication system for switching strategies, comprising a strategy entity for access traffic guidance, handover, and splitting of ATSSS coverage, a mobile core, a user equipment (UE) (1), and a multi-connectivity provider with a multi-connectivity termination point, wherein the ATSSS coverage is configured to provide multi-connectivity without ATSSS user plane functionality. Its features are, The difference between the ATSSS overlay and ATSSS as defined by 3GPP is that it at least has multipath support utilizing a backend entity, which is the ATSSS overlay core server. This backend entity replaces the ATSSS user plane functionality and is similar to ATSSS UPF on the backend side. The backend entity is located at: Mobile Virtual Network Operator (MVNO) Multi-connectivity providers, whether or not they have their own access resources Mobile network operators (MNOs) with EPC (Engineering, Procurement, and Construction) An MNO that is not coupled to underlying core components, such as Session Management Function (SMF), Access and Mobility Management Function (AMF), and Policy Control Function (PCF). Fixed network operator (FNO), or Public cloud environment The policy entity is configured to communicate rules that vary depending on ATSSS coverage with the UE (1) and / or to the multi-connectivity termination point. The rules that vary depending on ATSSS coverage include one or more of the following parameters: Instructions regarding enabling or disabling ATSSS overlay; Information about the ATSSS overlay core server includes its IP address, port number, and / or fully qualified domain name (FQDN). ATSSS coverage traffic management rules used for bootstrapping, switching, and splitting; ATSSS coverage information includes application information, destination address information, location information, network protocol information, and environmental information.

2. The communication system of claim 1, wherein the policy entity is configured to communicate with the UE (1) using out-of-band communication.

3. The communication system of claim 1 or 2, wherein the policy entity is configured to use out-of-band communication to communicate with the multi-connectivity termination point.

4. The communication system as claimed in any of the preceding claims, wherein the system further comprises a policy entity for ATSSS as defined by 3GPP, such that the policy entity for ATSSS coverage and the policy entity for ATSSS as defined by 3GPP coexist in the communication system.

5. The communication system of claim 4, wherein the policy entity for ATSSS coverage is further configured to communicate rules that vary depending on the ATSSS coverage to the policy entity for ATSSS.

6. The communication system of claim 4, wherein the policy entity for the ATSSS is configured to communicate ATSSS rules toward the ATSSS coverage policy entity.

7. The communication system of any one of claims 4 to 6, wherein the mobile core is configured to notify the UE (1) of the availability of the ATSSS coverage.

8. The communication system as described in any one of claims 1 to 7, wherein the policy entity used for the ATSSS coverage is an equity server.

9. A method for exchanging policies by guiding, handing over, and splitting policy entities within an ATSSS coverage in a communication system, said communication system including a mobile core, a user equipment (UE), and a multi-connectivity provider with multi-connectivity termination points, wherein the ATSSS coverage provides multi-connectivity without requiring ATSSS user plane functionality. The difference between the ATSSS overlay and ATSSS as defined in 3GPP is that it at least has multipath support utilizing a backend entity, which is the ATSSS overlay core server. This backend entity replaces the ATSSS user plane functionality and is similar to ATSSS UPF on the backend side. The backend entity is located at: Mobile Virtual Network Operator (MVNO) Multi-connectivity providers, whether or not they have their own access resources Mobile network operators (MNOs) with EPC (Engineering, Procurement, and Construction) An MNO that is not coupled to underlying core components, such as Session Management Function (SMF), Access and Mobility Management Function (AMF), and Policy Control Function (PCF). Fixed network operator (FNO), or Public cloud environment The method includes: The policy entity communicates rules that vary depending on ATSSS coverage to the UE and / or to the multi-connectivity termination point. The rules that vary depending on ATSSS coverage include one or more of the following parameters: Instructions regarding enabling or disabling ATSSS overlay; Information about the ATSSS overlay core server includes its IP address, port number, and / or fully qualified domain name (FQDN). ATSSS coverage traffic management rules used for bootstrapping, switching, and splitting; ATSSS coverage information includes application information, destination address information, location information, network protocol information, and environmental information.

10. The method of claim 9, wherein the policy entity uses out-of-band communication to communicate with the UE.

11. The method of claim 9 or 10, wherein the strategy entity uses out-of-band communication to communicate with the multi-connectivity termination point.

12. The method of any one of claims 9 to 11, wherein the system further includes a policy entity for ATSSS as defined by 3GPP, such that the policy entity for ATSSS coverage and the policy entity for ATSSS as defined by 3GPP coexist in the communication system.

13. The method of claim 12, wherein the policy entity for ATSSS coverage communicates rules that vary depending on the ATSSS coverage to the policy entity for ATSSS.

14. The method of claim 12 or 13, wherein the policy entity for the ATSSS communicates the ATSSS rules to the policy entity for the ATSSS coverage.

15. The method of any one of claims 9 to 14, wherein the mobile core notifies the UE of the availability of the ATSSS coverage.

16. The method of any one of claims 9 to 15, wherein the policy entity used for the ATSSS coverage is an equity server.

Images