GB2620675A - Telecommunications network - Google Patents

Telecommunications network Download PDF

Info

Publication number
GB2620675A
GB2620675A GB2308041.9A GB202308041A GB2620675A GB 2620675 A GB2620675 A GB 2620675A GB 202308041 A GB202308041 A GB 202308041A GB 2620675 A GB2620675 A GB 2620675A
Authority
GB
United Kingdom
Prior art keywords
residential gateway
network
policy
traffic
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
GB2308041.9A
Other versions
GB202308041D0 (en
Inventor
Johnson Stephen
Scahill Francis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Priority to GB2308041.9A priority Critical patent/GB2620675A/en
Priority claimed from GB2019986.5A external-priority patent/GB2602075B/en
Publication of GB202308041D0 publication Critical patent/GB202308041D0/en
Publication of GB2620675A publication Critical patent/GB2620675A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/22Manipulation of transport tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/085Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0894Policy-based network configuration management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/20Traffic policing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/08Load balancing or load distribution
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • H04W76/16Involving different core network technologies, e.g. a packet-switched [PS] bearer in combination with a circuit-switched [CS] bearer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/18Selecting a network or a communication service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/06Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16Gateway arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/04Interfaces between hierarchically different network devices
    • H04W92/06Interfaces between hierarchically different network devices between gateways and public network devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A telecommunications network 100 having a Residential Gateway (RG) 121 and User Equipment (UE) 110, wherein UE 110 has a UE cellular access connection and a UE non-cellular access connection connecting to the Residential Gateway 121. If it is determined that the Residential Gateway 121 utilises a Residential Gateway cellular access connection for traffic for the UE 110 and that a traffic policy for the UE 110 and/or a traffic policy for the Residential Gateway 121 satisfies a traffic policy modification rule based on a network operator's goal of addressing a performance problem should traffic for the UE 110 be delivered by both the UE cellular access connection and the Residential Gateway cellular access connection, then the traffic policy is modified for the UE 110 and/or the Residential Gateway 121 relating to at least one of the UE cellular access connection and the Residential Gateway cellular access connection, wherein the modification is to meet the network operator's goal. Enforcement of the modified traffic policy is then initiated for the UE 110 and/or the modified traffic policy for the Residential Gateway 121.

Description

TELECOMMUNICATIONS NETWORK
Field of the Invention
The present invention relates to a telecommunications network.
Background
The 3'd Generation Partnership Project (3GPP) define a set of standards that relate to the 511' Generation (5G) cellular telecommunications network. 5G cellular networks are designed so that the 5G core network may be accessed by multiple forms of access network (that is, they are "agnostic" to the access network). Accordingly, User Equipment (UE) may connect to the 5G core network via cellular or non-cellular access networks using the same signalling mechanisms defined in the set of 5G standards. Any access network that is used to connect to the 5G core network that is not standardised by the 3GPP is known as a non-3GPP network (a common example being Wireless Local Area Networks, WLANs).
Furthermore, UE may connect to the 5G core network via more than one access network, such as both a cellular and non-cellular access network, in a mode commonly known as "hybrid access". An example of hybrid access includes a first access connection via a cellular access network and a second access connection via a wired access network. A wired access network may be, for example, a Digital Subscriber Line, DSL, access network, or a Fibre To The Premises, FTTP, access network. In hybrid access mode, the two network accesses may be bonded together so that data traffic for the UE is split and delivered on a packet-by-packet basis across the plurality of access networks. The hybrid access function in the 3GPP 5G standards is realised in the Mutli-Access Packet Data Unit (MA-PDU) Session capability. For any IP flow that is mapped to a MA-PDU Session, the 5G System ensures that an application running on the UE and its associated application server running in the Data Network (DN) see a single IP address for the UE regardless of which access the traffic is delivered over.
A residential gateway is a form of customer premises equipment that typically resides in the user's home or office and provides an access connection between the UE and the 5G core network. The residential gateway supports both wireless access networks to the 5G core network and wired access networks to the 5G core network.
The present inventors have identified at least one problem when a UE uses hybrid access mode in which a first access connection is via a cellular access network and a second access connection is via a residential gateway, in which the residential gateway further utilises an access connection via a cellular access network (that is, either the residential gateway uses only a single access connection that is via a cellular access network, or when the residential gateway is also in hybrid access mode and one of these access connections is via the cellular access network). These problems include: * the UE receiving an unfair allocation of resources of the cellular access network (that is, by having an unwarranted overconsumption of resources to the detriment of other UEs) by having two access connections via the cellular access network; and * in a scenario in which both the UE and residential gateway use the hybrid access mode (known as "nested" hybrid access) and traffic is delivered by the cellular access connections of both the UE and residential gateway, application performance may be impacted by excessive jitter and significant differences in latency between each cellular access connection.
The present invention alleviates some or all of the above problems.
Summary of the Invention
According to a first aspect of the invention, there is provided a method in a telecommunications network having a residential gateway, and a User Equipment, UE, wherein the UE has a UE cellular access connection and a UE non-cellular access connection, the UE non-cellular access connection connecting to the residential gateway, and the residential gateway has a residential gateway cellular access connection, the method comprising the steps of: determining that the residential gateway utilises the residential gateway cellular access connection for traffic for the UE; determining that a traffic policy for the UE and/or a traffic policy for the residential gateway satisfies a traffic policy modification rule, wherein the traffic policy modification rule is based on a network operator's goal of addressing a performance problem should traffic for the UE be delivered by both the UE cellular access connection and the residential gateway cellular access connection; and, in response, modifying the traffic policy for the UE and/or residential gateway relating to at least one of the UE cellular access connection and the residential gateway cellular access connection, wherein the modification is to meet the network operator's goal; and initiating enforcement of the modified traffic policy for the UE and/or the modified traffic policy for the residential gateway.
Modification of the traffic policy for the UE and/or modification of the traffic policy for the S residential gateway may include modification of at least one of a group comprising: access type preference, non-seamless offload indication, and an Access Traffic Steering, Switching and Splitting, ATSSS, policy. A traffic policy relating to a non-cellular access connection of the residential gateway may be unchanged.
The method may further comprise the initial steps of: receiving an identifier for the residential gateway; and retrieving the residential gateway traffic policy based on the identifier for the residential gateway.
The identifier for the residential gateway may be received from a Non-3GPP- 1 5 InterWorking Function, N3IWF. The N3IWF may receive the identifier for the residential gateway following a request for establishment of an NWu tunnel between the UE and N3IWF.
The identifier for the residential gateway may be received from a Trusted Network Gateway Function, TNGF. The TNGF may receive the identifier for the residential gateway from a Trusted Network Access Point, TNAP, in an Extensible Authentication Protocol, EAP, authentication message.
The method may further comprise the steps of: determining that the UE and residential gateway disconnect; and restoring the traffic policy for the UE and or the traffic policy for the residential gateway.
According to a second aspect of the invention, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the first aspect of the invention. The computer program may be stored on a computer readable carrier medium.
According to a third aspect of the invention, there is provided a device for a telecommunications network, the device including a processor adapted to carry out the steps of the first aspect of the invention.
Brief Description of the Figures
In order that the present invention may be better understood, embodiments thereof will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic diagram of a telecommunications network, illustrating untrusted non-3GPP access; Figure 2 is a schematic diagram of a telecommunications network, illustrating trusted non-3GPP access; Figure 3 is a schematic diagram of a telecommunications network having a residential gateway, illustrating hybrid access for the residential gateway; Figure 4 is a schematic diagram of a telecommunications network implementing Access Traffic Steering, Switching and Splitting (ATSSS); Figure 5 is a schematic diagram of a telecommunications network, illustrating a User Equipment (UE) in hybrid access mode and a residential gateway in hybrid access mode, wherein the UE uses untrusted non-3GPP access; Figure 6 is a schematic diagram of a telecommunications network, illustrating a User Equipment (UE) in hybrid access mode and a residential gateway in hybrid access mode, wherein the UE uses trusted non-3GPP access; Figure 7 is a schematic diagram of a first embodiment of a telecommunications network of the present invention, illustrating a UE in hybrid access mode and a residential gateway in hybrid access mode, wherein the UE uses untrusted non-3GPP access; Figure 8 is a flow diagram of a first process of a first embodiment of a method of the present invention; Figure 9 is a flow diagram of a second process of the first embodiment of the method of the present invention; Figure 10 is a flow diagram of a third process of the first embodiment of the method of the present invention; Figure 11 is a schematic diagram of a second embodiment of a telecommunications network of the present invention, illustrating a UE in hybrid access mode and a residential gateway in hybrid access mode, wherein the UE uses trusted non-3GPP access; Figure 12 is a flow diagram of a first process of a second embodiment of a method of the present invention; Figure 13 is a flow diagram of a second process of the second embodiment of the method of the present invention; and Figure 14 is a flow diagram of a third process of the second embodiment of the method of the present invention.
Detailed Description of Embodiments
An overview of the various access connections of 53 systems will now be described. As noted in the Background section, a UE may connect to a 5G core network via a non3GPP access network. The 3GPP defines two ways a UE may connect via a non-3GPP access network -untrusted and trusted access. Trusted access is where the access point is known to the 53 core network, and untrusted access is where the access point is not known to the 5G core network.
An example of untrusted access between a UE and a data network via the 53 core network is shown in Figure 1. The UE connects to an access point of the untrusted non- 3GPP network using any suitable mechanism defined for that type of network. Once this connection between the UE and the access point is complete, the UE establishes an IP Security (IPSec) tunnel with an interworking function, Non-3GPP Interworking Function (N3IWF), at the edge of the 53 core network using its SIM credentials to authenticate with the N3IWF. Control and user plane data is delivered to the UE via this IPSec tunnel.
The interfaces between the various entities shown in Figure 1 are: * Ni -the signalling interface between the UE and the Access Management Function, AMF * N2 -the signalling interface(s) between the AMF and each access network (3GPP Access, and N3IWF) * N3 -User plane traffic encapsulated in Generic Tunnelling Protocol (GTP) messages between each access network and the User Plane Function (UPF) * N4 -signalling interface between the Session Management Function (SMF) and the UPF * N6 -User plane traffic between the UPF and the data network (e.g. the internet) -this is usually IP, but could be Ethernet * N11 -Signalling interface between the AMF and SMF * NWu -IPSec tunnel that carries Ni signalling and user plane traffic between the UE and N3IWF * Y1 (a non-3GPP defined interface) -Radio interface between the UE and Access Point e.g. WLAN * Y2 (a non-3GPP defined interface) -Backhaul interface between the non-3GPP access network and the N3IWF (typically IP i.e. the internet).
In Figure 1, the dashed line separates the network components based on their ownership -such that all components above the dashed line are owned by the Home Public Land Mobile Network, HPLMN, operator whilst all components below the dashed line are owned by the non-3GPP network operator. Where interfaces pass through nodes without termination in the above diagram, they are being tunnelled through the node by other interfaces. For example, the Ni interface between the UE and the AMF via the untrusted non-3GPP access is tunnelled over NWu between the UE and the N3IWF and N2 between the N3IWF and the AMF.
Figure 2 illustrates an example of trusted access between a UE and data network via the 5G core network. The trusted non-3GPP access point, known as a Trusted Network Access Point (TNAP) is known to the 5G core network and authenticates the UE using its SIM credentials at the Trusted Network Gateway Function (TNGF). Control and user plane data is delivered to the UE through an NVVt tunnel (an IPSec tunnel without encryption) between the UE and TNGF. The following interfaces that are not defined above for the untrusted access example and are shown in Figure 2 are: * NWt-unencrypted IPSec tunnel (that is, an IPSec tunnel using NULL encryption) that carries Ni signalling and user plane traffic between the UE and TNGF * Ta -interface that carries Extensible Authentication Protocol (EAP) 5G signalling from the TNAP to the AMF for authentication of the UE with the TNAP * Tn -Interface between TNGFs to support UE roaming between TNAPs and TNGFs. There may be a plurality of TNGFs in a network, each one supporting an area containing multiple TNAPs * Yt (a non-3GPP defined interface) -Radio interface between the UE and Access Point e.g. WLAN. This must support a high level of security such as Wi-Fi Protected Access version 2 -Enterprise (WPA2-Enterprise).
Figure 3 illustrates a residential gateway connected in hybrid access mode. The residential gateway is connected to the 5G core network via both a wireless connection and a wired connection. In the context of residential gateways, the wired connection to the 53 core network is known as the Wireline 53 Access Network (W-5GAN), in which a Wireline Access Gateway Function (W-AGF) terminates the wired connection and relays 3GPP signalling and data to the residential gateway over the wired connection (via a Y4 interface).
S
33PP Release 16 introduces a policy driven framework called Access Traffic Steering, Switching and Splitting (ATSSS). ATSSS defines how traffic should be delivered to a UE or residential gateway, on a per user per application basis, for all different accesses available to that UE or residential gateway. Any traffic flow that is eligible to be delivered using the ATSSS framework will be mapped to a MA-PDU Session. In ATSSS, a new traffic flow for the UE or residential gateway may be steered to use a specific access for a MA-PDU Session. If network conditions change, the traffic flow may be switched to an alternative access. Furthermore, the traffic flow may be split and delivered on a packet by packet basis across the plural accesses (in which scheduling of the traffic flow will be based on measured round-trip times or congestion of each access). The ATSSS policy is implemented by the UE or residential gateway, and the UPF. The UE, residential gateway and UPF therefore contains proxies that can split and reassemble traffic flows depending on the traffic direction (that is, uplink or downlink). Figure 4 illustrates the relevant functions for implementing ATSSS, through which the UE/residential gateway supports by using MA-PDU Sessions. The following additional terminology used in Figure 4 is defined below: * MPTCP -MulfiPath Transmission Control Protocol * PM F -Performance Measurement Function * ATSSS-LL -ATSSS Low Layer -a mechanism for delivering Layer 2 traffic such as Ethernet, and Layer 3 traffic such as IPv4 or IPv6 Use of the ATSSS capability is defined by operator policy. The PCF (Policy Control Function) stores a set of ATSSS rules for each UE/residential gateway that control which applications can use the ATSSS capability as well as the specific ATSSS configuration for the application. These rule sets are delivered by the PCF to the UE/residential gateway (over Ni) for uplink traffic as well as a matching set of rules to the UPF (over N4) for the downlink traffic.
Figure 5 illustrates a UE that supports MA-PDU Sessions, in which a first access connection is via a cellular access connection (signalling not shown) and the second access connection is via a residential gateway (which also supports MA-PDU Sessions). The boundaries of the residential gateway's network and of the UE network are illustrated by dotted line enclosures. In the example of Figure 5, the residential gateway is not known by the UE network and the UE therefore utilises untrusted non-3GPP access to S the UE network (via an N3IWF). The residential gateway is therefore treated as a separate entity to the UE network, even if both networks are owned by the same operator. The UE network is connected to a data network.
The PCF of the residential gateway's network defines one or more ATSSS policies for the residential gateway's network. These policies are delivered to the residential gateway and UPF of the residential gateway's network. Similarly, the PCF of the UE network defines one or more ATSSS policies for the UE network. These policies are delivered to the UE and UPF of the UE network.
Figure 6 also illustrates a UE that supports MA-PDU Sessions, in which a first access connection is via a cellular access connection (signalling not shown) and the second access connection is via a residential gateway. However, in this scenario, the residential gateway is known by the UE network and the UE can therefore utilise trusted non-3GPP access to the UE network (via a TNGF). Again, the PCF of the residential gateway's network defines one or more ATSSS policies for the residential gateway's network.
These policies are delivered to the residential gateway and UPF of the residential gateway's network. Similarly, the PCF of the UE network defines one or more ATSSS policies for the UE network. These policies are delivered to the UE and UPF of the UE network.
A first example policy that may be implemented by the UE and UPF of the UE network (in both the arrangement of Figure 5 and of Figure 6) will now be described. This first example policy is for an HD video streaming service to use the ATSSS priority mode where the preferred access is the fixed access (i.e. the residential gateway's NWu or NVVt connection). Priority mode means that the UE should use its preferred access only, unless it is congested, at which point the secondary access may also be used. This ATSSS policy is triggered in the UE or UPF by a flow's application ID or 5-tuple (UE IP address + port, App Server IP address + port, protocol type). This is a typical bonded use case.
Furthermore, the residential gateway and UPF in the residential gateway's network have the same priority mode policy for any traffic which includes the IPSec tunnel of the UE's untrusted access.
In this first example, a video streaming client on the UE requests content to be delivered at a maximum data rate until its internal buffer is full. It then plays content from its buffer and, when the buffer has emptied by a certain amount, it requests the content to be delivered again at the maximum data rate (to fill its buffer as fast as possible). This burstiness in demand may cause congestion on the residential gateway's wired access connection, and so the residential gateway will also use its cellular access connection to provide additional capacity. However, the residential gateway's cellular access connection may also become congested. The UE will then detect its non-3GPP access (the residential gateway NWt or NWu connection) as congested and so use its cellular access connection to provide additional capacity. The UE is therefore effectively using the cellular access twice which may be unfair in areas where there is competition for radio resources.
A second example policy that may be implemented by the UE and UPF of the UE network (in both the arrangement of Figure 5 and of Figure 6) will now be described. This second example is similar to the first example but uses a constant rate video communication (which differs from the first example in that the traffic is substantially constant instead of bursty) and is relatively sensitive to jitter. If the required data rate for the video exceeds the capacity of the UE's fixed access connection (i.e. both 3GPP and non-3GPP accesses of the residential gateway are fully utilised, possibly due to other traffic on the local network passing through the residential gateway), the UE will also use its own cellular access connection to provide additional capacity. In this scenario, there are 3 different paths delivering packets to the UE and most likely each will have a different latency. The UE will experience these different latencies as jitter and this will be additional to the jitter introduced on each path. There will be additional latency added over the fixed access through the process of splitting and reassembling IF flows in addition to the latency added by using IPSec which is likely to exacerbate the jitter experienced by the UE.
A first embodiment of a telecommunications network 100 of the present invention will now be described with reference to Figure 7. The telecommunications network 100 includes a UE 110, residential gateway network 120, a UE network 130 and a hybrid access management function 140. This first embodiment relates to the UE 110 in hybrid access mode, in which a first access connection is via a cellular access node 131 of the UE network 130 and the second access connection is via a non-3GPP access S connection to a residential gateway 121 of the residential gateway network 120. In this embodiment, a single operator owns both the UE network 130 and the residential gateway network 120. However, the residential gateway 121 is not known by the UE network and the residential gateway therefore utilises untrusted non-3GPP access to the UE network.
As shown in Figure 7, the residential gateway 121 is also configured in hybrid access mode, in which a first access connection is via a cellular access node 123 and a second access connection is via a W-5GAN 124. The residential gateway network 120 includes an AMF 125, UPF 126, SMF 127, and PCF 128, which generally operate in a manner known in the art and as described above. The UPF 126 of the residential gateway network 120 is connected to a first data network.
Furthermore, the UE network 130 includes an AM F 132, SMF 133, N3IWF 134, UPF 135 and PCF 136, which generally operate in a manner known in the art and as described above. The UPF 135 of the UE network is connected to a second data network.
The SMF 127 of the residential gateway network 120 and the N3IWF1 34 and PCF 136 of the UE network 130 are each connected to the hybrid access management function 140 The hybrid access management function 140 is used to manipulate an ATSSS policy of the UE 110 when operating in hybrid access mode. In this embodiment, the hybrid access management node 140 includes a configuration function 141, a cache 143, a metrics function 145, a policy builder 147 and a session manager 149.
The configuration function 141 includes a set of ATSSS policy modification rules indicating how an ATSSS policy should be modified in order to meet the UE network operator's goals (such as, for example, improving user experience or achieving network fairness). These modification rules can modify the following aspects of the ATSSS policy of the UE: * Access type preference, such as cellular access only, non-cellular access only, or hybrid access mode; * Non-seamless offload preference, such as to prefer non-seamless offload to the residential gateway network 120, * Other ATSSS rules, such as to use a preferred access connection only unless it is congested (and then use the non-preferred access connection to provide additional capacity) or fails (i.e. active standby), to use the access connection with the lowest latency, and/or to balance load between the access connections by a particular split of traffic across each access connection.
The cache 143 is a memory module for storing ATSSS policies, session identifies and device identities. These policies, session identities and device identities are stored with an associated fimestamp (representing the time the data was received at the cache 143). The relevance of this data will become clear upon review of the following description of embodiments of a method of the present invention.
The metrics function 145 is configured to store information on each UE and residential gateway in the network, the information being relevant to the creation and/or modification of an ATSSS policy. This information includes, for example, * Historical time of day-based hybrid access performance measurements for each residential gateway, e.g. link speed/throughput, latency, jitter, cell id; * Historical time of day-based hybrid access performance measurements for each UE, e.g. link speed/throughput, latency, jitter; and * Cell tower/sector live and historical time of day loading.
This information may be collected by the session manager 149 and stored as both real-time information and historical information in the metrics function 145. Information for the residential gateway 121 may be obtained from the N3IWF 134 and/or UPF 126 (with the exception of the cell id, which is obtained from the AMF 125). Information for the UE can be obtained by UPF 135 (again, with the exception of the cell id, which is obtained from the AMF 132).
The policy builder 147 is adapted to create a new ATSSS policy (or a new set of ATSSS policies) based on the information stored in the metrics function 145 and information stored in the cache 143. The relevance of the policy builder 147 will also become clear upon review of the following description of the embodiments of the method of the present invention.
The session manager 149 is configured to coordinate the ATSSS policy modification S process by cooperation with the configuration function 141, cache 143, metrics function and policy builder 147. This will also become clear upon review of the following description of the embodiments of the method of the present invention.
A first embodiment of the method of the present invention will now be described with reference to the network of Figure 7 and the flow diagrams of Figures 8 to 10. A first process of this first embodiment relates to the UE 110 associating with the residential gateway and is illustrated by the flow diagram of Figure 8. In a first step S1101, the UE 110 associates with the residential gateway 121 in the residential gateway network 120 and obtains an IP address on the residential gateway network 120. The residential gateway 121 has its own IP address and is configured to perform Network And Port Translation (NAPT) between its own IP address and the IP address of the UE 110 in the residential gateway network 120 for any traffic for the UE 110.
Subsequently, in step 51103, the UE 110 initiates a request to the N3IWF 134 to establish a connection to the UE network 130. This request includes the IP address of the residential gateway 121. Following acceptance of this request, an NWu connection (as noted above, an IPSec tunnel) is set up between the UE 110 and the N3IWF 134 and the UE 110 is connected to the UE network 130.
On successful setup of the NWu connection between the UE 110 and the N3IWF 134, in step 51104, the N3IWF 134 sends an update message to the HAMF 140 to inform the HAMF 40 of the new NWu connection between the UE 110 and N3IWF 134. This update message includes the UE's identity, such as an International Mobile Subscriber Identity (IMSI), Temporary IMSI (TIMSI) or Globally Unique Temporary UE Identity (Gull), and the residential gateway's IF address (received at the N3IWF 134 in step 51103).
The HAMF 140 receives this update message at the session manager 149. In response, the session manager 149 retrieves an ATSSS policy (or policies) for the residential gateway 121. This is achieved by initially, in step S1105, retrieving the residential gateway's identity, such as an IMSI, TIMSI or GUTI, from cache 143 based on a stored mapping with the residential gateway's IP address. If there is no stored mapping in cache 143, or the timestamp associated with the stored mapping indicates that the data is too old, then the session manager 149 sends a request message to the SMF 127 of the residential gateway's network 120 for the residential gateway's identity, the request S message including the residential gateway's IP address. The response message from the SMF 127 then includes the residential gateway's identity, which may be stored in the cache 143 with a new timestamp.
Once the residential gateway's identity has been retrieved, the session manager 149, in step S1107, obtains the ATSSS policy or policies for the residential gateway 121. These may also be retrieved from cache 143 based on a stored mapping between the residential gateway's identity and the ATSSS policy/policies. If there is no stored mapping in cache 143, or again if the timestamp associated with the stored mapping indicates that the data is too old, then the session manager 149 sends a request message to the PCF 128 of the residential gateway's network 120 for the residential gateway's ATSSS policy or policies, the request message including the residential gateway's identity. The response message from the PCF 128 includes the ATSSS policy or policies, which may be stored in cache 143 with a new timestamp.
In step S1109, the session manager 149 determines whether the ATSSS policy/policies indicate that the NWu connection between the UE 110 and N3IVVF 34 will be delivered over hybrid access. If not, then the process ends. However, if this determination is positive, then, in step S1111, the session manager 1149 retrieves the UE's ATSSS policy or policies. This similarly achieved by consulting the cache 143 or sending a request message to the PCF 136 of the UE network 130. Any policies received from the PCF 136 are also similarly stored in cache 143 with a new timestamp.
In step 51113, the policy builder 147 reviews each UE ATSSS policy and determines whether a modification should be made. These determinations are based on the ATSSS policy re-write rules stored in the configuration function 141 and may also be based on any performance metric data available for the residential gateway 121 (as stored in the metric function 145). If so, then the corresponding modification prepares a new UE ATSSS policy, in which the new ATSSS policy is a modification of the input UE ATSSS policy. In this example, these policy re-write rules include: * If the UE 110 and residential gateway 121 are owned by the same operator and are located in an area where there is a significant amount of cellular traffic (that is, the one or more base stations that the UE 110 and residential gateway 121 are connected to have a load above a threshold), then the ATSSS policy should be modified so that the UE 110 may only use one access connection (that is, either the cellular access connection or the non-cellular access connection) so that only a single cellular access connection is used between the UE 110 and residential gateway 121; * If the UE 110 may connect via a non-cellular access connection to the residential gateway 121 via a WLAN protocol, and the residential gateway 121 uses a cellular access connection (only or as part of a hybrid access mode), then the ATSSS policy should be modified so that the UE 110 may operate in cellular access only mode. This may help ease congestion on the residential gateway's WLAN for other UE, which may have an inferior cellular access connection to the UE 110 and residential gateway 121. This may be particularly suitable in areas of congestion, such as entertainment venues, sports stadia and transport hubs; * If the UE 110 and residential gateway 121 are both able to use hybrid access (a "nested" hybrid access scenario), then the ATSSS policy may be modified to address any latency/jitter problems that may occur. For example, an application of the UE (having its own unique ATSSS policy) may be for the UE to use noncellular access only so as to meet certain latency/jitter requirements. However, if this would be split between cellular and non-cellular access at the residential gateway and the performance metrics for one or both of these connections are below the application requirements, the ATSSS policy may be modified so that the UE uses its cellular access connection instead. Furthermore, the UE may run a plurality of applications (each having their own ATSSS policy), which may have a unique solution so as to select one or more access connections (that is, the UE's cellular and non-cellular access connection and/or the residential gateway's cellular and non-cellular access connection) based on the application's requirements, the network operator's goals, and the performance metrics of those access connections.
Once complete, the policy builder 147 sends these one or more new UE ATSSS policies to the session manager 149, in which each new UE ATSSS policy either matches the original UE ATSSS policy or is a modification of the original UE ATSSS policy.
S In step S1115, the session manager 149 stores the new ATSSS policy or policies in cache 143 together with a stored mapping to the residential gateway's IF address, the UE's identity, and a timestamp. This is marked as an active session entry. The original ATSSS policy or policies remain stored in the cache 143.
In step S1117, the session manager 149 sends a first update message to the PCF 136 of the UE network 130 and a second update message to the UE 110 and UPF 135, the first and second update messages including the new ATSSS policy or policies. This may result in session modification procedures being initiated by the SMF 133 in the UE network 130. Once the PCF 136, UE 110 and UPF 135 have been updated according to the new ATSSS policy or policies, then any future traffic for the UE 110 is routed according to this new ATSSS policy/policies.
A second process of this first embodiment will now be described with reference to Figure 9. This second process is performed periodically whilst there is an active connection between the UE 110 and the residential gateway 121. In a first step S1201, the session manager 149 sends a request message to the UPF 135 of the UE network 130. This request message requests data on the performance of the connection for UE traffic over the residential gateway's network 120. These statistics may include, for example, uplink average throughput, downlink average throughput, maximum speed, latency and/or jitter.
In step S1203, on receipt of the requested performance metric data from the UPF 135, the session manager 149 sends the performance metric data to the metric function 145 together with the residential gateway identifier. In step S1205, the metric function 145 stores the performance metric data together with a mapping to the residential gateway identifier. In step S1207, the metric function 145 updates its statistics model for the residential gateway 121. As noted above, this performance metric data and/or statistical model for the residential gateway may be used by the policy builder 147 in modifying a UE ATSSS policy.
A third process of this first embodiment will now be described with reference to Figure 10. This third process relates to the UE 110 disassociating with the residential gateway 121. In a first step 51301, the UE 110 disassociates from the residential gateway 121. In step 51303, the UE network 30 detects the disassociation, for example, by a) a "dead peer detection" mechanism in Internet Key Exchange (IKE) version 2 (as defined in Internet Engineering Task Force (I ETF) Request For Comments (RFC) 7296), or b) an ATSSS Performance Management Function (PMF) in the UE 110 signalling to UPF 135 that an access has stopped. Following detection, in step 31305, the N3IWF 134 (in the case of the dead peer detection) or UPF 135 (in the case of the PMF notification) sends an update message to the session manager 149 of the disassociation, wherein the update message includes the UE identifier and the UE IP address (the public IP address of the UE 110, as identified in step 31103).
On receipt of this update message, in step 31307, the session manager 149 inspects cache 143 to determine if there's a stored active session entry for the UE (based on the UE's IP address and/or UE's identity). If not, then the third process ends. If this determination is positive, in step S1309, the session manager 149 sends a request message to UPF 135 of the UE network 130. This request message requests data on the performance of the connection for UE traffic over the residential gateway's network 120. These statistics may include, for example, uplink average throughput, downlink average throughput, maximum speed, latency and/or jitter. In step S1311, on receipt of the requested performance metric data from the UPF 135, the session manager 149 sends the performance metric data to the metric function 145 together with the residential gateway identifier. In step S1313, the metric function 145 stores the performance metric data together with a mapping to the residential gateway identifier, and updates its statistics model for the residential gateway 121. The purpose of updating the statistics model at this time is such that it is based on the last known performance data (and also in case the session duration ended before the second process was implemented).
In step 31315, the session manager 149 deletes the active session entry from cache 143. In step 31317, the session manager 149 retrieves the original ATSSS policy or policies from cache 145. In step 31319, the session manager 149 sends a first update message to the PCF 136 of the UE network 130 and a second update message to the UE 110 and UPF 135, the first and second update messages including the original ATSSS policy or policies. This may result in session modification procedures being initiated by the SMF 133 in the UE network 130. Once the PCF 136, UE 110 and UPF 135 have been updated according to the original ATSSS policy or policies, then any future traffic for the UE 110 is routed according to this original ATSSS policy/policies.
A second embodiment of a telecommunications network 200 of the present invention will now be described with reference to Figure 11. The telecommunications network 200 includes a UE 210, residential gateway network 220, a UE network 230 and a hybrid access management function 240. This second embodiment relates to the UE 210 in hybrid access mode, in which a first access connection is via a cellular access node 231 of the UE network 230 and the second access connection is via a residential gateway 221 of the residential gateway network 220. The residential gateway is known by the UE network and the UE and residential gateway therefore utilise trusted non-3GPP access to the UE network.
As shown in Figure 11, the residential gateway 221 is also configured in hybrid access mode, in which a first access connection is via a cellular access node 223 and a second access connection is via a W-5GAN 224. The residential gateway network 220 includes an AMF 225, UPF 226, SMF 227, and PCF 228, which generally operate in a manner known in the art and as described above. The UPF 226 of the residential gateway network 220 is connected to a first data network.
Furthermore, the UE network 230 further includes an AMF 232, SMF 233, TNGF 234, UPF 235 and PCF 236, which generally operate in a manner known in the art and as described above. The UPF 235 of the UE network is connected to a second data network.
The SMF 227 of the residential gateway network 220 and the TNGW 234 and PCF 236 of the UE network are each connected to the hybrid access management function 240. The hybrid access management function 240 is similar to that of the first embodiment above, but includes a connection to the TNGF 234 of the UE network (instead of a connection to the N3IWF in the first embodiment).
A second embodiment of a method of the present invention will now be described with reference to the network of Figure 11 and the flow diagrams of Figures 12 to 14. This second embodiment is very similar to the first embodiment but differs in that the residential gateway 221 is known to the UE network 230 such that it may use trusted non-3GPP access via the TNGF 234 of the UE network 230. In this example, the residential gateway network 220 and the UE network 230 are owned by the same operator, but this is non-essential. This second embodiment also includes a first, second S and third process. A first process will now be described with reference to Figure 12.
In a first step S1401, the UE 210 associates with the residential gateway 221 (the TNAP in this example), such as to the residential gateway's WLAN. In this trusted non-3GPP access scenario, this requires SIM based authentication (EAP-5G) of the UE 210 against its credentials stored in the UE network 230. Accordingly, the residential gateway 221 sends an EAP-5G authentication request message to the TNGF 234 in the UE network 230, including a UE identifier and a residential gateway identifier, in order to set up a new NW connection between the UE 210 and TNGF 234. The residential gateway identifier may be augmented to this authentication message using an EAP Expanded Request Type.
In step 51403, the TNGF 234 sends an update message to the HAMF 240 to inform the HAMF 240 of the new NVVt connection between the UE 210 and TNGF 234. This update message includes the UE's identity, such as an IMSI, TIMSI or GUTI, the residential gateway's identifier, and the residential gateway's IP address.
On receipt of this update message, in step S1405, the session manager 249 of the HAMF 240 retrieves an ATSSS policy or policies for the residential gateway 221. This is achieved by checking the cache 243 for a stored ATSSS policy or policies based on a mapping between the residential gateway identifier and the stored ATSSS policy or policies. If there are no ATSSS policies stored in cache 243 for the residential gateway identifier, or the ATSSS policies are too old, then the session manager 249 sends a request message to the PCF 228 of the residential gateway network 220, including the residential gateway identifier. On receipt of the ATSSS policy or policies from the PCF 228, the session manager 249 stores them in cache 243 together with a timestamp.
The remaining steps of this first process of this second embodiment mirror the corresponding steps of the first process of the first embodiment. Accordingly, in step S1409, the session manager 249 determines whether the ATSSS policy or policies indicate that the NWt connection between the UE 210 and TNGF 234 will be delivered over hybrid access. If not, then the process ends. However, if this determination is positive, then, in step S1411, the session manager 249 retrieves the UE's ATSSS policy or policies. This is similarly achieved by consulting the cache 243 or sending a request message to the PCF 236 of the UE network 230. Any policies received from the PCF S 236 are also similarly stored in cache 243 with a new timestamp.
In step S1413, the policy builder 247 reviews each UE ATSSS policy and determines whether a modification should be made. These determinations are based on the ATSSS policy re-write rules stored in the configuration function 241 and may also be based on any performance metric data available for the residential gateway 221 (as stored in the metric function 245). If so, then the corresponding modification prepares a new UE ATSSS policy, in which the new ATSSS policy is a modification of the input UE ATSSS policy. These policy re-write rules may be the same as the examples in the first embodiment.
Once complete, the policy builder 247 sends these one or more new UE ATSSS policies to the session manager 249, in which each new UE ATSSS policy either matches the original UE ATSSS policy or is a modification of the original UE ATSSS policy.
In step 51415, the session manager 249 stores the new ATSSS policy or policies in cache 243 together with a stored mapping to the residential gateway's IP address, the UE's identity, and a timestamp. This is marked as an active session entry. The original ATSSS policy/policies remain stored in the cache 243.
In step S1417, the session manager 249 sends a first update message to the PCF 236 of the UE network 230 and a second update message to the UE 210 and UPF 235, the first and second update messages including the new ATSSS policy or policies. This may result in session modification procedures being initiated by the SMF 233 in the UE network 230. Once the PCF 236, UE 210 and UPF 235 have been updated according to the new ATSSS policy/policies, then any future traffic for the UE 210 is routed according to this new ATSSS policy/policies.
In the above first process of this second embodiment, the residential gateway network 220 and UE network 230 were owned by the same network operator. However, this is non-essential and different network operators may own the networks. In such a scenario, the operator of the residential gateway network 220 must expose some of its control plane interfaces to the operator of the UE network 230 using, for example, the capabilities defined in 3GPP Technical Specification 23.501.
A second process of this second embodiment will now be described with reference to Figure 13. This second process is performed periodically whilst there is an active connection between the UE 210 and the residential gateway 221. In a first step 51501, the session manager 249 sends a request message to the UPF 235 of the UE network 230. This request message requests data on the performance of the connection for UE traffic over the residential gateway's network 220. These statistics may include, for example, uplink average throughput, downlink average throughput, maximum speed, latency and/or jitter.
In step 51503, on receipt of the requested performance metric data from the UPF 235, the session manager 249 sends the performance metric data to the metric function 245 together with the residential gateway identifier. In step S1505, the metric function 245 stores the performance metric data together with a mapping to the residential gateway identifier. In step 51507, the metric function 245 updates its statistics model for the residential gateway 221. As noted above, this performance metric data and/or statistical model for the residential gateway 221 may be used by the policy builder 247 in modifying a UE ATSSS policy.
A third process of this second embodiment will now be described with reference to Figure 14. This third process relates to the UE 210 disassociating with the residential gateway 221. In a first step S1601, the UE 210 disassociates from the residential gateway 221.
In step 51603, the UE network 230 detects the disassociation, for example, by a) a "dead peer detection" mechanism in IKEv2, b) an ATSSS PMF in the UE 210 signalling to UPF 235 that an access has stopped, or c) a RADIUS Accounting stop message from the residential gateway 221 over the Ta interface. Following detection, in step S1605, the TNGF 234 (in the case of dead peer detection), the residential gateway 221 (acting as the TNAP in the case of PMF signalling), or UPF 235 (in the case of a RADIUS accounting stop message) sends an update message to the session manager 249 of the disassociation, wherein the update message includes the UE identifier and the UE IP address (the public I P address of the UE 110, as seen by the N3IVVF 134 in step S1403).
The remaining steps of this third process of this second embodiment mirror the corresponding steps of the third process of the first embodiment. Accordingly, on receipt of this update message, in step 31607, the session manager 249 inspects cache 243 to determine if there's a stored active session entry for the UE (based on the UE's IP address and/or the UE's identity). If not, then the third process ends. If this determination is positive, in step 31609, the session manager 249 sends a request message to UPF 235 of the UE network 230. This request message requests data on the performance of the connection for UE traffic over the residential gateway's network 2120. These statistics may include, for example, uplink average throughput, downlink average throughput, maximum speed, latency and/or jitter. In step 31611, on receipt of the requested performance metric data from the UPF 235, the session manager 249 sends the performance metric data to the metric function 245 together with the residential gateway identifier. In step S1613, the metric function 245 stores the performance metric data, together with a mapping to the residential gateway identifier, and updates its statistics model for the residential gateway 221. The purpose of updating the statistics model at this time is such that it is based on the last known performance data (and also in case the session duration ended before the second process was implemented).
In step 31615, the session manager 249 deletes the active session entry from cache 243. In step 31617, the session manager 249 retrieves the original ATSSS policy or policies from cache 243. In step S1619, the session manager 249 sends a first update message to the PCF 236 of the UE network 230 and a second update message to the UE 210 and UPF 235, the first and second update messages including the original ATSSS policy/policies. This may result in session modification procedures being initiated by the SMF 233 in the UE network 230. Once the PCF 236, UE 210 and UPF 235 have been updated according to the original ATSSS policy or policies, then any future traffic for the UE 210 is routed according to this original ATSSS policy or policies.
These embodiments of the present invention provide a mechanism for managing how application traffic is delivered to the UE when the UE is connected to a residential gateway and both the UE and residential gateway utilise respective cellular access connections. This involves a process for detecting that this scenario has occurred and, in response, retrieving and modifying the relevant traffic policies to avoid undesirable behaviour. The mechanism also involves a process for detecting when the UE has disconnected from the residential gateway and, in response, restoring the original traffic policy. Furthermore, this mechanism is implemented as a network only solution (that is, there is no modification of standardised UE behaviour), and may therefore be implemented with only the UE functionality defined in the 3GPP Release 16 standard.
S In the first and second embodiments above, the operator owns both networks. Where the operator owns both networks, the residential gateway network and UE network may be separate networks (as described above), or instead be the same network or separate network slices through the same network.
In the embodiments above, the HAMF manipulates an ATSSS policy of the UE.
However, the skilled person will understand that this is non-essential and that an ATSSS policy of the residential gateway may be manipulated instead. In this case, the most likely modification is to ensure that traffic for the UE is not split in the residential gateway network. Furthermore, it is non-essential that the traffic policy being modified by the HAMF is an ATSSS policy. Additionally or alternatively, the traffic policy may be a UE Route Selection Policy (USRP). The USRP may be stored in the PCF and maps application traffic to one of: * Single Access PDU Session, where the traffic is only ever delivered over one access connection This rule will specify whether 3GPP or non-3GPP is preferred. If the access changes, the UE IP address may also change (depending on the Service and Session Continuity (SSC) mode); * Multi Access PDU Session, where traffic is controlled by ATSSS policy. IP address always the same regardless of access; and * Non seamless offload: traffic is routed over the non-3GPP access connection directly to the data network and thus not passing through the 5G core network.
The skilled person will understand that any combination of features is possible within the scope of the invention, as claimed.
The invention may be defined by the following clauses: 1. A method in a telecommunications network having a residential gateway, and a User Equipment, UE, wherein the UE has a UE cellular access connection and a UE non-cellular access connection, the UE non-cellular access connection connecting to the residential gateway, and the residential gateway has a residential gateway cellular access connection, the method comprising the steps of: determining that the residential gateway utilises the residential gateway cellular access connection for traffic for the UE; determining that a traffic policy for the UE and/or a traffic policy for the residential gateway satisfies a traffic policy modification rule, wherein the traffic policy modification rule is based on a network operator's goal; and, in response, modifying the traffic policy for the UE and/or residential gateway relating to at least one of the UE cellular access connection and the residential gateway cellular access connection, wherein the modification is to meet the network operator's goal; and initiating enforcement of the modified traffic policy for the UE and/or the modified traffic policy for the residential gateway.
2. A method as claimed in clause 1, wherein modification of the traffic policy for the UE and/or modification of the traffic policy for the residential gateway includes modification of at least one of a group comprising: access type preference, non-seamless offload indication, and an Access Traffic Steering, Switching and Splitting, ATSSS, policy.
3. A method as claimed in either clause 1 or clause 2, further comprising the initial steps of: receiving an identifier for the residential gateway; retrieving the residential gateway traffic policy based on the identifier for the residential gateway.
4. A method as claimed in clause 3, wherein the identifier for the residential gateway is received from a Non-3GPP-InterVVorking Function, N3IWF.
5. A method as claimed in clause 4, wherein the N3IWF receives the identifier for the residential gateway following a request for establishment of an NWu tunnel between the UE and N3IWF.
6. A method as claimed in clause 3, wherein the identifier for the residential gateway is received from a Trusted Network Gateway Function, TNGF.
7. A method as claimed in clause 6, wherein the TNGF receives the identifier for the residential gateway from a Trusted Network Access Point, TNAP, in an Extensible Authentication Protocol, EAP, authentication message.
8. A method as claimed in any one of the preceding clauses, further comprising the steps of: determining that the UE and residential gateway disconnect; and in response to said determination, reverting from the modified traffic policy for the UE to the traffic policy for the UE and/or reverting from the modified traffic policy for the residential gateway to the traffic policy for the residential gateway.
9. A method as claimed in any one of the preceding clauses, wherein the network operator's goal is one of a network fairness goal and a performance goal.
10. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of any one of clauses 1 to 9.
11. A computer readable carrier medium comprising the computer program of clause 10.
12. A device for a telecommunications network, the device including a processor adapted to carry out the steps of any one of clauses 1 to 9.

Claims (11)

  1. CLAIMS1. A method in a telecommunications network having a residential gateway, and a User Equipment, UE, wherein the UE has a UE cellular access connection and a UE non-cellular access connection, the UE non-cellular access connection connecting to the residential gateway, and the residential gateway has a residential gateway cellular access connection, the method comprising the steps of: determining that the residential gateway utilises the residential gateway cellular access connection for traffic for the UE; determining that a traffic policy for the UE and/or a traffic policy for the residential gateway satisfies a traffic policy modification rule, wherein the traffic policy modification rule is based on a network operator's goal of addressing a performance problem should traffic for the UE be delivered by both the UE cellular access connection and the residential gateway cellular access connection; and, in response, modifying the traffic policy for the UE and/or residential gateway relating to at least one of the UE cellular access connection and the residential gateway cellular access connection, wherein the modification is to meet the network operator's goal; and initiating enforcement of the modified traffic policy for the UE and/or the modified traffic policy for the residential gateway.
  2. 2. A method as claimed in Claim 1, wherein modification of the traffic policy for the UE and/or modification of the traffic policy for the residential gateway includes modification of at least one of a group comprising: access type preference, non-seamless offload indication, and an Access Traffic Steering, Switching and Splitting, ATSSS, policy.
  3. 3. A method as claimed in either Claim 1 or Claim 2, further comprising the initial steps of: receiving an identifier for the residential gateway; retrieving the residential gateway traffic policy based on the identifier for the residential gateway.
  4. 4. A method as claimed in Claim 3, wherein the identifier for the residential gateway is received from a Non-3GPP-InterWorking Function, N3IWF.
  5. 5. A method as claimed in Claim 4, wherein the N3IWF receives the identifier for the residential gateway following a request for establishment of an NWu tunnel between the UE and N3IWF.S
  6. 6. A method as claimed in Claim 3, wherein the identifier for the residential gateway is received from a Trusted Network Gateway Function, TNGF.
  7. 7. A method as claimed in Claim 6, wherein the TNGF receives the identifier for the residential gateway from a Trusted Network Access Point, TNAP, in an Extensible Authentication Protocol, EAP, authentication message.
  8. 8. A method as claimed in any one of the preceding claims, further comprising the steps of: determining that the UE and residential gateway disconnect; and in response to said determination, reverting from the modified traffic policy for the UE to the traffic policy for the UE and/or reverting from the modified traffic policy for the residential gateway to the traffic policy for the residential gateway.
  9. 9. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of any one of Claims 1 to 8.
  10. 10. A computer readable carrier medium comprising the computer program of Claim 9.
  11. 11. A device for a telecommunications network, the device including a processor adapted to carry out the steps of any one of Claims 1 to 8.
GB2308041.9A 2020-12-17 2020-12-17 Telecommunications network Pending GB2620675A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB2308041.9A GB2620675A (en) 2020-12-17 2020-12-17 Telecommunications network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB2308041.9A GB2620675A (en) 2020-12-17 2020-12-17 Telecommunications network
GB2019986.5A GB2602075B (en) 2020-12-17 2020-12-17 Telecommunications network

Publications (2)

Publication Number Publication Date
GB202308041D0 GB202308041D0 (en) 2023-07-12
GB2620675A true GB2620675A (en) 2024-01-17

Family

ID=89321373

Family Applications (1)

Application Number Title Priority Date Filing Date
GB2308041.9A Pending GB2620675A (en) 2020-12-17 2020-12-17 Telecommunications network

Country Status (1)

Country Link
GB (1) GB2620675A (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021163590A1 (en) * 2020-02-14 2021-08-19 Charter Communications Operating, Llc Apparatus and methods for generating and distributing policy in wireless networks
WO2022098696A1 (en) * 2020-11-03 2022-05-12 Convida Wireless LLC Communication of adaptive traffic steering

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021163590A1 (en) * 2020-02-14 2021-08-19 Charter Communications Operating, Llc Apparatus and methods for generating and distributing policy in wireless networks
WO2022098696A1 (en) * 2020-11-03 2022-05-12 Convida Wireless LLC Communication of adaptive traffic steering

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
3GPP TR 23.716 v16.0.0 (2018-12) *
3GPP TR 23.793 V16.0.0 (2018-12) *

Also Published As

Publication number Publication date
GB202308041D0 (en) 2023-07-12

Similar Documents

Publication Publication Date Title
EP3864810B1 (en) Policy control for multiple accesses
US11825335B2 (en) Always-on packet data unit session indication
US11510127B2 (en) Network failure
US11330648B2 (en) Charging aggregation control for network slices
CN109417554B (en) Method and apparatus for controlling access of mobile device to voice service, and memory
US20220408333A1 (en) Session Management for Edge Computing
US10064096B2 (en) Traffic distribution in heterogenous network environment
US20230015916A1 (en) Session Management for Processing Offload
EP2840815A1 (en) Method and system for acquiring traffic distribution information applicable to wlan
EP3879796B1 (en) Selection of edge application server
US11102696B1 (en) Systems and methods for handover with dynamic quality of service (QoS) in a 5th generation (5G) network
GB2620675A (en) Telecommunications network
WO2022128345A1 (en) Method in a telecommunications network having a residential gateway, computer program, computer readable carrier medium and device
WO2022128300A1 (en) Method in a telecommunications network, computer program, computer readable carrier medium and device
GB2625169A (en) Telecommunications network