Network management

Abstract

There is provided a method for managing binding information in a network. The method is performed by a first network node of the network. The method comprises initiating transmission (902) of a first message towards a second network node of the network. The first message comprises binding information. The binding information comprises information indicative of an internet protocol (IP) address of a first user equipment (UE) involved in a first session and information indicative of an IP address of a first application involved in the first session.

Description

[0001] NETWORK MANAGEMENT

[0002] Technical Field

[0003] The disclosure relates to methods for network management and network nodes configured to operate in accordance with those methods.

[0004] Background

[0005] Achieving reliable communication in wireless networks can be complex. Wireless networks are primarily built for mobile broandband applications, where best effort communication is typically sufficient. Thus, all the different components and procedures in a network (e.g. on packet processing, packet transmission, etc.) are built for best effort communication, and adding techniques for enhanced reliability to such networks is not trivial. Generally, the applications using the network have to address the additional challenges and increased complexity.

[0006] Summary

[0007] It is an object of the disclosure to obviate or eliminate at least some of the abovedescribed disadvantages associated with existing techniques.

[0008] Therefore, according to an aspect of the disclosure, there is provided a first method for managing binding information in a network. The first method is performed by a first network node of the network. The first method comprises initiating transmission of a first message towards a second network node of the network. The first message comprises binding information. The binding information comprises information indicative of an internet protocol (IP) address of a first user equipment (UE) involved in a first session and information indicative of an IP address of a first application involved in the first session. The binding information enables the session binding by associating the binding information to the first session.

[0009] According to another aspect of the disclosure, there is provided a second method for managing binding information in a network. The second method is performed by a second network node of the network. The second method comprises performing session binding in response to receiving a first message from a first network node of the network. The first message comprises binding information. The binding information comprises information indicative of an IP address of a first UE involved in a first session and information indicative of an IP address of a first application involved in the first session. The session binding is performed by associating the binding information to the first session.

[0010] The first and second aspect enables the session binding process for the scenario, same IP address reachable over multiple PDU Sessions during SSC mode 3 UPF relocation, which would not be possible with the state of the art.

[0011] According to another aspect of the disclosure, there is provided a third method for managing path selection in a network. The third method is performed by a third network node of the network. The third method comprises selecting, from a plurality of paths, a path via which to route a packet received at the third network node. The plurality of paths are between the third network node and a destination of the packet. The path is selected based on one or more characteristics of the path meeting a policy comprising one or more path selection criteria.

[0012] According to another aspect of the disclosure, there is provided a fourth method for managing path selection in a network. The fourth method is performed by a fourth network node of the network. The fourth method comprises setting a policy comprising one or more path selection criteria on the basis of which a path is to be selected, from a plurality of paths, for routing a packet received at the fourth network node. The fourth network node is associated with an origin of the packet. The plurality of paths are between a third network node of the network and a destination of the packet. The path is to be selected based on one or more characteristics of the path meeting the one or more path selection criteria.

[0013] The above 2 aspects allow the use of multiple paths to devices behind the UEs for sessions associated with binding information.

[0014] According to another aspect of the disclosure, there is provided a fifth method for managing path selection in a network. The fifth method is performed by a sixth network node of the network. The fifth method comprises selecting, from a plurality of paths, a path via which to route a packet received at the sixth network node. The plurality of paths are between the sixth network node and a destination of the packet. The path is selected based on a flow descriptor of the path matching a flow descriptor assigned to the packet.

[0015] According to another aspect of the disclosure, there is provided a sixth method for managing path selection in a network. The sixth method is performed by a seventh network node of the network. The sixth method comprises assigning, to a packet received at the seventh network node, a flow descriptor on the basis of which a path is to be selected, from a plurality of paths, for routing the packet. The seventh network node is associated with an origin of the packet. The plurality of paths are between a sixth network node of the network and a destination of the packet. The path is to be selected based on a flow descriptor of the path matching the flow descriptor assigned to the packet.

[0016] The above 2 aspects allow the routing of packets via multiple paths by the sixth network node on basis of flow descriptors assigned by the seventh network node to packets received at the seventh network node belonging to sessions associated with binding information.

[0017] According to another aspect of the disclosure, there is provided a seventh method for managing path selection in a network. The seventh method is performed by a tenth network node of the network. The seventh method comprises selecting, from a plurality of paths, a path via which to route a packet received at the tenth network node. The plurality of paths are between the tenth network node and a destination of the packet. The path is selected based on a border gateway protocol (BGP) update comprising information about the path.

[0018] According to another aspect of the disclosure, there is provided a eighth method for managing path selection in a network. The eighth method is performed by an eleventh network node of the network. The eighth method comprises generating a BGP update on the basis of which a path is to be selected, from a plurality of paths, for routing a packet received at a tenth network node. The eleventh network node is associated with a destination of the packet. The plurality of paths are between the tenth network node and the destination of the packet. The BGP update comprises information about the path.

[0019] The above 2 aspects allow the routing of packets via multiple paths by the tenth network node, controlled by the eleventh network node using BGP, the packets belonging to sessions associated with binding information.

[0020] According to another aspect of the disclosure, there is provided a method performed by a system. The method performed by the system comprises the first method described earlier and the second method described earlier, and / or the third method described earlier and the fourth method described earlier, and / or the fifth method described earlier and the sixth method described earlier, and / or the seventh method described earlier and the eighth method described earlier.

[0021] According to another aspect of the disclosure, there is provided a first network node comprising processing circuitry configured to cause the first network node to initiate transmission of a first message towards a second network node of the network. The first message comprises binding information. The binding information comprises information indicative of an IP address of a first UE involved in a first session and information indicative of an IP address of a first application involved in the first session.

[0022] According to another aspect of the disclosure, there is provided a second network node comprising processing circuitry configured to cause the second network node to perform session binding in response to receiving a first message from a first network node of the network. The first message comprises binding information. The binding information comprises information indicative of an IP address of a first UE involved in a first session and information indicative of an IP address of a first application involved in the first session. The session binding is performed by associating the binding information to the first session.

[0023] According to another aspect of the disclosure, there is provided a third network node comprising processing circuitry configured to cause the third network node to select, from a plurality of paths, a path via which to route a packet received at the third network node. The plurality of paths are between the third network node and a destination of the packet. The path is selected based on one or more characteristics of the path meeting a policy comprising one or more path selection criteria.

[0024] According to another aspect of the disclosure, there is provided a fourth network node comprising processing circuitry configured to cause the fourth network node to set a policy comprising one or more path selection criteria on the basis of which a path is to be selected, from a plurality of paths, for routing a packet received at the fourth network node. The fourth network node is associated with an origin of the packet. The plurality of paths are between a third network node of the network and a destination of the packet. The path is to be selected based on one or more characteristics of the path meeting the one or more path selection criteria.

[0025] According to another aspect of the disclosure, there is provided a sixth network node comprising processing circuitry configured to cause the sixth network node to select, from a plurality of paths, a path via which to route a packet received at the sixth network node. The plurality of paths are between the sixth network node and a destination of the packet. The path is selected based on a flow descriptor of the path matching a flow descriptor assigned to the packet.

[0026] According to another aspect of the disclosure, there is provided a seventh network node comprising processing circuitry configured to cause the seventh network node to assign, to a packet received at the seventh network node, a flow descriptor on the basis of which a path is to be selected, from a plurality of paths, for routing the packet. The seventh network node is associated with an origin of the packet. The plurality of paths are between a sixth network node of the network and a destination of the packet. The path is to be selected based on a flow descriptor of the path matching the flow descriptor assigned to the packet.

[0027] According to another aspect of the disclosure, there is provided a tenth network node comprising processing circuitry configured to cause the tenth network node to select, from a plurality of paths, a path via which to route a packet received at the tenth network node. The plurality of paths are between the tenth network node and a destination of the packet. The path is selected based on a BGP update comprising information about the path. According to another aspect of the disclosure, there is provided an eleventh network node comprising processing circuitry configured to cause the eleventh network node to generate a BGP update on the basis of which a path is to be selected, from a plurality of paths, for routing a packet received at a tenth network node. The eleventh network node is associated with a destination of the packet. The plurality of paths are between the tenth network node and the destination of the packet. The BGP update comprises information about the path.

[0028] According to another aspect of the disclosure, there is provided a system. The system comprises the first network node described earlier and the second network node described earlier, and / or the third network node described earlier and the fourth network node described earlier, and / or the sixth network node described earlier and the seventh network node described earlier, and / or the tenth network node described earlier and the eleventh network node described earlier.

[0029] According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform any one or more of the first method, the second method, the third method, the fourth method, the fifth method, the sixth method, the seventh method, and the eighth method.

[0030] According to another aspect of the disclosure, there is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the any one or more of the first method, the second method, the third method, the fourth method, the fifth method, the sixth method, the seventh method, and the eighth method.

[0031] Thus, in the manner described above, enhancements for network procedures are provided. The advantageous way in which binding information is handled and path selection is managed enables a more reliable network without impacting applications using the network, and overall keeping the additional complexity low.

[0032] Brief description of the drawings For a better understanding of the techniques, and to show how they may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

[0033] Figure 1 is a schematic diagram illustrating a network node;

[0034] Figures 2 to 7 are schematic diagrams illustrating systems;

[0035] Figure 8 is a block diagram illustrating a network node according to some embodiments;

[0036] Figures 9 and 10 are block diagrams illustrating methods according to some embodiments;

[0037] Figure 11 is a schematic diagram illustrating a system according to some embodiments;

[0038] Figure 12 is a schematic diagram illustrating a method according to some embodiments;

[0039] Figures 13 and 14 are block diagrams illustrating methods according to some embodiments;

[0040] Figure 15 is a schematic diagram illustrating a network node according to some embodiments;

[0041] Figure 16 is a schematic diagram illustrating a system according to some embodiments;

[0042] Figures 17 and 18 are block diagrams illustrating methods according to some embodiments;

[0043] Figures 19 and 20 are schematic diagrams illustrating systems according to some embodiments; Figures 21 and 22 are block diagrams illustrating methods according to some embodiments;

[0044] Figure 23 is a schematic diagram illustrating a system according to some embodiments;

[0045] Figure 24 is a schematic diagram illustrating a network node according to some embodiments; and

[0046] Figures 25 and 26 are schematic diagrams illustrating systems according to some embodiments.

[0047] Detailed Description

[0048] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0049] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject-matter disclosed herein, the disclosed subject-matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject-matter to those skilled in the art. The third generation partnership project (3GPP) assumes a single handheld device as a user equipment (UE). Several enhancements exist to also connect networks behind a UE, such as framed routing, internet protocol version 6 (IPv6) prefix delegation, network address translation (NAT), or network prefix translation (NPT). NAT is a functionality or entity that translates between internet protocol version 4 (IPv4) addresses. For example, NAT may translate between a private and a public address, such as in a gateway between a private network and the internet. NPT is basically a NAT for IPv6. In all cases, the packets may be treated in the manner shown in Figure 1.

[0050] Figure 1 illustrates an example of a packet processing flow in a user plane (UP) network node in a network or, more specifically, in a user plane function (UPF) node 102 of a fifth generation core (5GC) network. Generally, in a 5GC network, a UPF node can be a node through which all user plane traffic needs to pass and optionally also the node at which a packet data unit (PDU) session is anchored.

[0051] Although a UPF node 102 of a 5GC is illustrated in Figure 1 , it will be understood that the same packet processing flow may occur in a packet data network gateway (PGW, e.g. a user plane PGW (PGW-U)) of an evolved packet core (EPC) network. The packet 104 that is processed can be referred to as an incoming packet and the resulting processed packet 106 can be referred to as an outgoing packet. The packet is a downlink (DL) packet. The packet can be an internet protocol (IP) packet.

[0052] Figure 1 corresponds to Figure 5.2.1-1 of the 3GPP technical standard (TS) 29.244 Version (V) 18.3.0. In the example illustrated in Figure 1 , it is assumed that there is a protocol between the UPF node 102 and a session management function (SMF) node (which is not illustrated in Figure 1). The SMF node is a node of the 5GC network that configures the UPF node 102, such as with respect to how to treat and / or forward traffic. The functionality performed by the SMF node of the 5GC network can be performed by a PGW (e.g. a control plane PGW (PGW-C)) of the EPC network. The protocol between the UPF node 102 and the SMF node is referred to as a packet forwarding control protocol (PFCP).

[0053] In the example illustrated in Figure 1 , at block 108, a PFCP session look-up is performed and, at block 110, a packet detection rule (PDR) look-up is performed. In more detail, with regard to the PFCP session look-up at block 108, the PFCP session (which has a one to one relation to a PDU session) for the packet is identified by matching information in the packet (e.g. an address, such as an IP address, of a destination of the packet) with one or more configured PDRs. The one or more PDRs are one or more (e.g. a set of) rules for which one or more other rules are configured, e.g. for which one or more multi-access rules (MARs), one or more forwarding action rules (FARs), one or more quality of service (QoS) enforcement rules (QERs), and / or one or more usage report rules (URRs) are configured. The one or more PDRs can, for example, comprise an address (such as an IP address) of a UE for which one or more other rules are configured. Generally, as illustrated in Figure 1 , any incoming packet 104 must only match the PDR(s) of a single PFCP session.

[0054] With regard to the PDR look-up at block 110, one or more PDRs for the PFCP session are identified. In this case, there can be multiple matches. That is, multiple PDRs may be identified for the PFCP session. It may be that the PDR 112 with the highest precedence is selected. In the example illustrated in Figure 1 , at block 114, the instructions set in the selected PDR 112 are applied. For example, the selected PDR 112 may comprise a FAR and a QER, which are applied at block 114.

[0055] The remote authentication dial-in user service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. Framed routing, in particular, is a concept from RADIUS and “normal” IP networks, where it is basically a static IP route installed on a router by a RADIUS server. In a fifth generation system (5GS), framed routing can be used to configure the UPF to forward data (e.g. IP data) to an address (e.g. IP address, which is the framed route) via the PDU session. Similarly, in an evolved packet system (EPS), framed routing can be used to configure a PGW (e.g. PGW-U) in this way.

[0056] Figure 2 illustrates an example of framed routing in a 5GS 200. The 5GS 200 comprises an application function (AF) node 201 , a UPF node 202, an SMF node 214, a policy control function (PCF) node 216, an application 230, a UE 232, a base station (e.g. a gNodeB (gNB)) 234, an access and mobility function (AMF) node 236, a data network (DN) 238, and a DN AAA management node 240. The PCF node 216 is a network node of the 5GC network. The PCF node 216 manages policies, such as for QoS policies, charging policies, and / or other policies. The PCF node 216 can offer one or more interfaces to the AF 201 for providing the policies and optionally also for (e.g. dynamically) activating and / or modifying the policies.

[0057] As illustrated by arrow 242, the DN 238 transmits a packet (e.g. IP packet) to a destination. The destination can, for example, be indicated by an address (e.g. an IP address). As also illustrated by arrow 242, the packet is received at the UPF node 202. Optionally, as illustrated by arrow 244, the DN AAA management node 240 may provision framed routes at the SMF node 214, such as during or after PDU session establishment. In this case, as illustrated by arrow 246, the SMF node 214 may install rules (e.g. forwarding and / or packet detection rules) with framed routes at the UPF node 202.

[0058] As illustrated by arrow 248, the UPF node 202 identifies a PDU session. The UPF node 202 may identify the PDU session by matching the address (e.g. IP address) of the destination of the packet with addresses (e.g. IP addresses) of UEs and framed routes, such as in all configured packet detection rules. As illustrated by arrow 250, the UPF node 202 may transmit the packet in the identified PDU session towards the UE 232 via the base station 234 and the UE 232 can thus receive the packet. As illustrated by arrow 252, the UE 232 can forward the packet to the destination of the packet, which in this example is the application 230.

[0059] Figure 3 illustrates an example of IPv6 prefix delegation in a 5GS 300. The 5GS 300 comprises the same nodes described earlier with reference to Figure 2, namely an AF node 301 , a UPF node 302, an SMF node 314, a PCF node 316, an application 330, a UE 332, a base station (e.g. gNB) 334, an AMF node 336, a DN 338, and a DN AAA management node 340. The PCF node 316 can be as described earlier with reference to the PCF node 216 of Figure 2.

[0060] When using IPv6 prefix delegation, the UPF node 302 can be configured to forward the packet (e.g. IP packet) via a PDU session in the same way, while the other mechanisms are different. That is, arrows 342, 344, 346, 350, and 352 of Figure 3 can be as described with reference to arrows 242, 244, 246, 250, and 252 respectively of Figure 2. However, at arrow 348 of Figure 3, the UPF node 302 may identify the PDU session by matching the address (e.g. IP address) of the destination of the packet with IPv6 prefixes of UEs and delegated prefixes, such as in all configured packet detection rules.

[0061] The UE 332 is provided with a delegated IPv6 prefix that it can further assign to other devices. The delegated IPv6 prefix can be provided to the UE 332 either during PDU session establishment or afterwards such as using a dynamic host configuration protocol (DHCP). DHCP is the most common way to dynamically configure IP addresses within a subnet. As illustrated by arrow 358, the UE 332 may consult an external DHCPv6 server 360 to acquire the IPv6 prefix(es) that are to be delegated to a UE. For example, a DHCPv6 client 362 of the UE 332 may acquire the IPv6 prefix(es) from the DHCPv6 server 360.

[0062] Existing techniques that connect networks behind a UE are built for networks using only a single UE and a single IP path. However, various scenarios (e.g. connected vehicles, such as connected trains) can benefit from using multiple UEs, and potentially multiple (co re-) networks. That is, various scenarios can benefit from using multiple paths (e.g. IP paths). However, 3GPP has several limitations with regard to enabling multiple paths and / or that prevent devices from connecting via different UEs using the same address (e.g. IP address). Also, 3GPP currently specifies framed routing and IPv6 prefix delegation to allow routing of a packet to IP addresses behind a UE, both of which have several limitations in how they are currently used in a core (e.g. 5GC or EPC) network. For example, these limitations prevent devices from connecting via different UEs using the same address (e.g. IP address) and, correspondingly, the same framed route or delegated prefix.

[0063] Figure 4 illustrates an example scenario where a non-3GPP device 402 can be connected via multiple paths (e.g. multiple IP paths). In the example scenario, the non- 3GPP device 402 is on a connected train 404. The non-3GPP device 402 can be one of a plurality of non-3GPP devices on the connected train 404. Although a connected train 404 is illustrated for the purpose of this example, any other connected vehicle is equally possible. The connected train 404 comprises two UEs 406, 408 to which the non-3GPP device 402 can connect. Although two UEs 406, 408 are illustrated, it will be understood that any other number of UEs are possible. The UEs 406, 408 communicate with one or more server nodes 410 via one or more UPF nodes 412, 414 of a 5GC network 416. The one or more UPF nodes 412, 414 can communicate via a control plane (CP) of the 5GC network 416.

[0064] There are three scenarios illustrated in Figure 4. In a first scenario (“Constellation A”), there are multiple PDU sessions from one UPF node 412 to different UEs 406, 408. In a second scenario (“Constellation B”), there are multiple PDU sessions between one UE 406 and one UPF node 412. In this second scenario, there may be a different data network name (DNN) and / or single network slice selection assistance information (S- NSSAI) per session. A DNN can be a name of a data network (DN) to which a PDU session is providing connectivity. Many policies can be configured per DNN. When using different DNNs, one PDU session may be needed per DNN. S-NSSAI can be used to select an intended network slice for a PDU session. Many policies can be configured per network slice. When using different network slices, one PDU session may be needed per network slice. In a third scenario (“Constellation C”), there are multiple PDU sessions between one UE 408 and multiple UPF nodes 412, 414. In this third scenario, the multiple PDU sessions may have the same DNN and S-NSSAI during UPF node relocation, such as with session and service continuity (SSC) mode 3. However, some challenges may arise in the core network.

[0065] A first challenge relates to session binding in a PCF node (which is not illustrated in Figure 4). For example, when a quality of service (QoS) is configured via the PCF node, such as over the N5 or Rx interface, the PCF node needs to perform session binding. Specifically, the PCF node needs to identify the correct PDU session for which to configure the QoS. A second challenge relates to packet forwarding in a UPF node 412, 414. For example, from the limited information in the packet (e.g. IP packet) arriving at a UPF node 412, 414, the UPF node 412, 414 needs to take a forwarding decision. These challenges are illustrated in Figure 5.

[0066] Figure 5 illustrates another example scenario where a non-3GPP device 502 can be connected via multiple paths (e.g. multiple IP paths). In the example scenario, the non- 3GPP device 502 is on a connected train 504. The non-3GPP device 502 can be one of a plurality of non-3GPP devices on the connected train 504. Although a connected train 504 is illustrated for the purpose of this example, any other connected vehicle is equally possible. The connected train 504 comprises two UEs 506, 508 to which the non-3GPP device 502 can connect. Although two UEs 506, 508 are illustrated, it will be understood that any other number of UEs are possible. The UEs 506, 508 have different subscriber permanent identifiers (SLIPIs). The SLIPIs are identifiers of a subscriber identity module (SIM) of the respective UEs. In an equivalent 4G scenario, the SUPIs are international mobile subscriber identities (IMSIs). The UEs 506, 508 communicate with one or more UPF nodes 512, 514 of a 5GC network. Each UPF node 512, 514 communicates with a respective SMF node 518, 520. Each SMF node 518, 520 communicates with a PCF node 522.

[0067] As illustrated by arrow 524, the PCF node 522 receives a QoS request. As illustrated by arrow 526, the PCF node 522 performs session binding. This is the first challenge mentioned earlier. Specifically, it is not apparent to the PCF node 522 for which PDU session the requested QoS needs to be configured.

[0068] As illustrated by arrow 530, the UPF node 512 receives a packet. The packet has a destination indicated by an address (e.g. an IP address). In the example, the destination is the non-3GPP device 502. As illustrated by arrow 528, the UPF node 512 performs packet forwarding. This is the second challenge mentioned earlier. Specifically, it is not apparent to the UPF node 512 via which UE 506, 508 to forward the packet to the non- 3GPP device 502.

[0069] Therefore, as illustrated in Figure 5, the UPF node 512 forwards the packet to non-3GPP device 502 via both of the UEs 506, 508. For example, the UPF node 512 may forward the packet to the non-3GPP device 502 via two paths 532, 534 to the first UE 506. This can introduce unnecessary overhead. Each of these path 532, 534 can have a different DNN (e.g. “DNN A” and “DNN B”). The UPF node 512 may also forward the packet to the non-3GPP device 502 via a single path 536 to the second UE 508. This path 536 can have the same DNN (e.g. “DNN B”) as one of the paths 534 to the first UE 506.

[0070] As user plane traffic is typically encrypted, it may be that only the IP header information can be used to process the packet. The IP header information can comprise any one or more of: a source or origin address (e.g. IP address), a destination address (e.g. IP address), a source or origin port, a destination port, a differentiated services code point (DSCP) in the case of IPv4 or a traffic class in the case of IPv6, and a flow label in the case of IPv6. A DSCP may be a field in an IPv4 header. A DSCP can be used to mark the packet, e.g. for specific treatment. A corresponding field in an IPv6 header is the traffic class field.

[0071] Typically, the destination address of the packet can be used for the forwarding decision at arrow 528. However, it is identical for all possible paths 532, 534, 536 in this scenario. In fact, both addresses and ports are the same for all paths 532, 534, 536. DSCP or traffic class and flow label can be used to influence the path decision. However, it is not trivial to align this with the PDR configuration in the UPF(s) 512, 514.

[0072] Figure 6 illustrates an example of session binding in a 5GS 600. The 5GS 600 comprises an application function (AF) node 601 , a UPF node 602, an SMF node 614, a PCF node 616, an application 630, a UE 632, a base station (e.g. a gNB) 634, an AMF node 636, a DN 638, and a DN AAA management node 640.

[0073] As illustrated by arrow 622, the SMF node 614 may transmit PDU session information (e.g. framed routes and / or delegated prefixes) to the PCF node 616 and thus the PCF node 616 can receive the PDU session information from the SMF node 614. As illustrated by arrow 620, the AF node 601 transmits a request to the PCF node 616 for a certain QoS to a destination address (e.g. IP address) and thus the PCF node 616 can receive this request from the AF node 601 , e.g. at any time after PDU session establishment.

[0074] As illustrated by arrow 624, the PCF node 616 performs session binding. Session binding is performed to identify the PDU session to which the QoS is to be applied. As illustrated by arrow 626, the PCF node 616 transmits policy and charging control (PCC) rules with the QoS for the destination address to the SMF node 614 and thus the SMF node 614 can receive these PCC rules from the PCF node 616. As illustrated by arrow 628, the SMF node 614 installs, at the UPF node 602, the PDR and QER for the QoS for the destination address.

[0075] Based on 3GPP TS 29.513 V18.3.0, Section 6.2, session binding can be performed based on any one or more of the following parameters: the UE IPv4 address, the UE IPv6 address, the UE identity (of the same kind e.g. SUPI) if available, the information about the DN (e.g. the DNN) the user is accessing if available, the IPv4 address domain identity if available (e.g. in the “ipDomain” attribute), and the S-NSSAI if available. The UE IP address support or management is specified in 3GPP TS 29.512 V18.3.0, Section 4.2.8. The differences and additions in wireline and wireless convergence scenarios are specified in 3GPP TS 23.512 V18.3.0, Section C.2.1.6. For IPv6 prefix delegation, the IPv6 network prefix of the PDU session is shorter than / 64. The UE IPv4 address or IPv6 address received by the PCF node from the AF node can comprise an address (e.g. an IP address) that belongs to the framed routes that apply to a PDU session. In this case, the association with the PDU session needs to be based on comparing the received UE address with the one or more framed routes of the PDU session.

[0076] While the session binding based on one or more of the earlier mentioned parameters is sufficient for performing unambiguous session binding for Constellations A and B described earlier with reference to Figure 4, all of the mentioned parameters would be identical for Constellation C described earlier with reference to Figure 4 and thus session binding cannot be performed as specified.

[0077] A border gateway protocol (BGP) is a routing protocol. This routing protocol can be completely decentralized. It can run within an autonomous system (AS). In this case, it can be called an internal BGP (i-BGP or IGP). The BGP can be the only protocol used to interconnect ASs. In this case, it can be called an external BGP (e-BGP). For example, it can be used between networks of different internet service providers (ISPs) to communicate how to reach IP addresses. A BGP may run between established peers. A BGP session can be established over a transmission control protocol (TCP) session (e.g. port 179) on a direct connection (e.g. direct IP connection) between two routers. Peers can be configured manually between the routers.

[0078] Figure 7 illustrates an example of BGP sessions in a 5GS 700. The 5GS 700 comprises three ASs 740, 750, 758. A first AS 740 of the 5GS comprises a first UPF node 702 and a second AS 750 comprises a second UPF node 752. A third AS 758 comprises one or more server nodes 718. The 5GS also comprises a gateway 746. The gateway comprises a client multipath (MP) function node 708 and two UEs 710, 712. The 5GS also comprises one or more applications 706. Although certain numbers of components are illustrated for the purpose of the example, it will be understood that any other number of each of the components is equally possible. A first path 720 and a second path 721 are established between the first UPF node 702 and an application 706 via a first UE 710. A third path 722 is established between the first UPF node 702 and the application 706 via a second UE 712. A fourth path 723 is established between the second UPF node 752 and the application 706 via the second UE 712. In the example illustrated in Figure 7, a first BGP session is established between the first AS 740 and the third AS 758, and a second BGP session is established between the second AS 750 and the third AS 758.

[0079] The BGP can share information during the BGP sessions. The BGP may only share the prefixes and / or addresses that the operator of an AS allows it to share (and thus it can be referred to as a “selective protocol”). For example, private prefixes within an AS may typically be kept private. This can be for security and / or privacy reasons, and / or to avoid impact on the overall performance of the BGP (e.g. worldwide). An operator of an AS may need to configure which routes are advertised by gateway routers to its peers outside the AS, e.g. using “network statements” in their BGP routing tables. The routes that are advertised may, for example, comprise one or more static routes and / or one or more semi-dynamic routes. The one or more static routes may be for ASs with a single gateway (GW) towards the internet. The one or more semi-dynamic routes may only be advertised when they are available within the AS. For example, the routing table can be checked before advertising.

[0080] “Redistribute statements” can be used to expose the whole IGP table via BGP. This can usually be combined with a filter list to exclude certain prefixes. Summarization may be used to stabilise the internet and / or reduce the amount of route entries in the global BGP table. Any one or more of the following criteria may impact the path selection: next-hop, weight, local preference, routes origin in router, AS path (“AS_Path”), origin, Multi Exit Discriminator (MED), external / internal, closest IGP neighbour, and lowest router identifier (ID). Some criteria may be standardised, while other criteria (e.g. weight) may be proprietary. With regard to the above-mentioned criteria, AS_Path is the only criteria available that can influence the best path selection of a BGP peer.

[0081] In mobile networks, all UE addresses (e.g. IP addresses), framed routes, and delegated prefixes are typically part of the same IP range, and are organised as being part of the same AS. There is BGP peering with other ASs on the N6 reference point in the 5GS, but not towards networks behind the UE.

[0082] As mentioned earlier, there are described herein improved techniques for managing a network. The network referred to herein can be any type of network. For example, the network referred to herein may be a communications or telecommunications network, e.g. a cellular network. In some embodiments, the network referred to herein can be a mobile network, such as a fourth generation (4G) mobile network, a fifth generation (5G) mobile network, a sixth generation (6G) mobile network, or any other generation mobile network. In some embodiments, the network referred to herein can comprise a core network, such as an evolved packet core (EPC) network or a 5G core (5GC) network. In some embodiments, the network referred to herein can be a fog computing environment or an edge computing environment. Thus, the network may also be referred to generally as an environment. In some embodiments, the network referred to herein can be a virtual network or an at least partially virtual network. Although some examples have been provided for the type of network referred to herein, it will be understood that the network referred to herein can be any other type of network.

[0083] Moreover, the techniques are mostly described herein in respect of a fifth generation system (5GS) or, more specifically, a fifth generation core (5GC) network. However, it will be understood that the techniques described herein are equally applicable to an evolved packet system (EPS) or, more specifically, an evolved packet core (EPC) network. Similarly, it will be understood that the techniques described herein are equally applicable to a sixth generation (6G) network or any other generation of network.

[0084] Herein, the term “initiate” can mean cause or establish. Thus, any reference to a network node “initiating transmission” will be understood to mean that the network node (e.g. processing circuitry of the network node) can be configured to itself transmit (e.g. via a communications interface of the network node) or can be configured to cause another network node to transmit.

[0085] Herein, the term “multipath” can refer to multiple paths for packets between two network nodes in a network. For example, the term may refer to the simultaneous (or managed) use of multiple transport paths of IP traffic between two communication endpoints. Some embodiments described herein can involve a user equipment (UE). As used herein, the term UE can refer to a device capable, configured, arranged and / or operable to communicate wirelessly with one or more network nodes and / or one or more other UEs. Communicating wirelessly may involve transmitting and / or receiving wireless signals, such as by using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information through air. Thus, unless otherwise noted, the term UE can be used interchangeably herein with the term wireless device. In some embodiments, a UE may be configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information on a predetermined schedule, when triggered by an internal or external event, or in response to requests. In some embodiments, a UE may be registered to and / or operated by a user or an end user (EU). Thus, unless otherwise noted, the term UE can be used interchangeably herein with user device or EU device.

[0086] Examples of a UE as referred to herein include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE), a vehicle-mounted wireless terminal device, etc. A wireless device as referred to herein may support device-to-device (D2D) communication, for example, by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to- everything (V2X) and may in this case be referred to as a D2D communication device.

[0087] A UE as referred to herein may represent the endpoint of a wireless connection, in which case the UE may be referred to as a wireless terminal. Furthermore, a UE as referred to herein may be mobile, in which case it may be referred to as a mobile device or a mobile terminal.

[0088] The techniques described herein can be implemented by one or more network nodes. Figure 8 illustrates a network node 10 of a network in accordance with an embodiment. The network node 10 is for managing the network, such as managing binding information in a network and / or managing path selection in a network.

[0089] In some embodiments, the network node 10 can refer to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with another network node referred to herein and / or with other nodes or equipment to enable and / or to perform the functionality described herein. In some embodiments, the network node 10 can, for example, be a physical node (e.g. a physical machine) or a virtual node (e.g. a virtual machine, VM). Herein, a variety of network nodes are described. Any one or more of the network nodes described herein can be configured in the manner described with reference to Figure 8.

[0090] As illustrated in Figure 8, the network node 10 comprises processing circuitry (or logic) 12. The processing circuitry 12 controls the operation of the network node 10 and can implement the method described herein in respect of any one or more of the network nodes referred to herein. The processing circuitry 12 can be configured or programmed to control the network node 10 in the manner described herein. The processing circuitry 12 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of any one or more of the network nodes referred to herein. In some embodiments, the processing circuitry 12 can be configured to run software to perform the method described herein in respect of any one or more of the network nodes referred to herein. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 12 may be configured to run a container to perform the method described herein in respect of any one or more of the network nodes referred to herein.

[0091] Briefly, with regard to a first network node of a network referred to herein, the processing circuitry 12 is configured to initiate transmission of a first message towards a second network node of the network. The first message comprises binding information. The binding information comprises information indicative of an internet protocol (IP) address of a first user equipment (UE) involved in a first session and information indicative of an IP address of a first application involved in the first session.

[0092] With regard to a second network node of the network referred to herein, the processing circuitry 12 is configured to perform session binding in response to receiving the first message from the first network node of the network. The first message comprises the binding information. The binding information comprises the information indicative of the IP address of the first UE involved in the first session and the information indicative of the IP address of the first application involved in the first session. The session binding is performed by associating the binding information to the first session.

[0093] With regard to a third network node of a network referred to herein, the processing circuitry 12 is configured to select, from a plurality of paths, a path via which to route a packet received at the third network node. The plurality of paths are between the third network node and a destination of the packet. The path is selected based on one or more characteristics of the path meeting a policy comprising one or more path selection criteria.

[0094] With regard to a fourth network node of the network referred to herein, the processing circuitry 12 is configured to set the policy comprising one or more path selection criteria on the basis of which the path is to be selected, from the plurality of paths, for routing the packet received at the fourth network node. The fourth network node is associated with an origin of the packet (e.g. a server, a data network such as a server of the data network, or any other origin of the packet). The plurality of paths are between the third network node of the network and the destination of the packet. The path is to be selected based on one or more characteristics of the path meeting the one or more path selection criteria.

[0095] With regard to a sixth network node of a network referred to herein, the processing circuitry 12 is configured to select, from a plurality of paths, a path via which to route a packet received at the sixth network node. The plurality of paths are between the sixth network node and a destination of the packet. The path is selected based on a flow descriptor of the path matching a flow descriptor assigned to the packet. The flow descriptor referred to herein can be a value or any other type of flow descriptor. In some embodiments, the flow descriptor referred to herein can be unique (e.g. unique to a path). With regard to a seventh network node of the network referred to herein, the processing circuitry 12 is configured to assign, to the packet received at the seventh network node, the flow descriptor on the basis of which a path is to be selected, from a plurality of path, for routing the packet. The seventh network node is associated with an origin of the packet (e.g. a server, a data network such as a server of the data network, or any other origin of the packet). The plurality of paths are between the sixth network node of the network and the destination of the packet. The path is to be selected based on the flow descriptor of the path matching the flow descriptor assigned to the packet.

[0096] With regard to a tenth network node of a network referred to herein, the processing circuitry 12 is configured to select, from a plurality of paths, a path via which to route a packet received at the tenth network node. The plurality of paths are between the tenth network node and a destination of the packet. The path is selected based on a border gateway protocol (BGP) update comprising information about the path.

[0097] With regard to an eleventh network node of the network referred to herein, the processing circuitry 12 is configured to generate the BGP update on the basis of which the path is to be selected, from the plurality of paths, for routing the packet received at the tenth network node. The eleventh network node is associated with a destination of the packet. The plurality of paths are between the tenth network node and the destination of the packet. The BGP update comprises information about the path.

[0098] As illustrated in Figure 8, in some embodiments, the network node 10 may optionally comprise a memory 14. The memory 14 can comprise a volatile memory or a nonvolatile memory. In some embodiments, the memory 14 may comprise a non-transitory media. Examples of the memory 14 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0099] The processing circuitry 12 can be communicatively coupled (e.g. connected) to the memory 14. In some embodiments, the memory 14 may be for storing program code or instructions which, when executed by the processing circuitry 12, cause the network node 10 to operate in the manner described herein in respect of the relevant network node. For example, in some embodiments, the memory 14 may be configured to store program code or instructions that can be executed by the processing circuitry 12 to cause the network node 10 to operate in accordance with the method described herein in respect of the relevant network node. Alternatively or in addition, the memory 14 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 12 may be configured to control the memory 14 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0100] In some embodiments, as illustrated in Figure 8, the network node 10 may optionally comprise a communications interface 16. The communications interface 16 can be communicatively coupled (e.g. connected) to the processing circuitry 12 and / or the memory 14. The communications interface 16 may be operable to allow the processing circuitry 12 to communicate with the memory 14 and / or vice versa. Similarly, the communications interface 16 may be operable to allow the processing circuitry 12 to communicate with any one or more of the other network nodes referred to herein and / or any other node. The communications interface 16 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 12 may be configured to control the communications interface 16 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0101] Although the network node 10 is illustrated in Figure 8 as comprising a single memory 14, it will be appreciated that the network node 10 may comprise at least one memory (i.e. a single memory or a plurality of memories) 14 that operate in the manner described herein. Similarly, although the network node 10 is illustrated in Figure 8 as comprising a single communications interface 16, it will be appreciated that the network node 10 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 16 that operate in the manner described herein. It will also be appreciated that Figure 8 only shows the components required to illustrate an embodiment of the network node 10 and, in practical implementations, the network node 10 may comprise additional or alternative components to those shown. A first technique will now be described with reference to Figures 9 to 12.

[0102] Figure 9 illustrates a first method performed by a first network node of a network in accordance with an embodiment. The first method is for managing binding information in the network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the first method of Figure 9. The first method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments.

[0103] With reference to Figure 9, as illustrated at block 902, the first method comprises initiating transmission of a first message towards a second network node of the network. More specifically, the first network node (e.g. the processing circuitry of the first network node) initiates transmission of the first message (e.g. causes another node to transmit the first message or itself transmits the first message, such as via its communications interface). The first message comprises binding information. The binding information comprises information indicative of an internet protocol (IP) address of a first user equipment (UE) involved in a first session and information indicative of an IP address of a first application involved in the first session. Herein, the IP address of the first UE can also be referred to as the “first UE IP address” and the IP address of the first application can also be referred to as the “first application IP address”.

[0104] In some embodiments, the first message may be transmitted using a service operation, such as an Npcf_PolicyAuthorization_Create service operation. The Npcf_PolicyAuthorization_Create service operation can be a service operation that creates, in the second network node, a context for the first session. The context for the first session can, for example, be information about the first session (e.g. an identifier (ID) identifying the first application that the first session involves, an ID (e.g. IMSI, SUPI, etc.) identifying the first UE that the first session relates to, a type of media for the first session, the IP address of the first application, and / or a port number to be used for the first session).

[0105] In some embodiments, the first message may comprise quality of service (QoS) information indicative of a QoS requested for the first UE. In some embodiments, an information element (IE) of the first message can comprise an attribute that indicates the information indicative of the IP address of the first UE. In some embodiments, the IE may be extended to comprise an additional attribute that indicates the information indicative of the IP address of the first application. In some of these embodiments, the IE may be an AppSessionContextReqData IE. The AppSessionContextReqData IE can be an IE that identifies service requirements of a context for the first session.

[0106] In some embodiments, the IP address of the first UE may be an internet protocol version 4 (IPv4) address of the first UE. In other embodiments, the IP address of the first UE may be an internet protocol version 6 (IPv6) address of the first UE. The IPv6 address can comprise a network-assigned prefix and optionally also a self-assigned interface identifier. Herein, the network-assigned prefix can, for example, be used in functionality (e.g. including session binding) relating to packet forwarding. Also, herein, the full IPv6 address can, for example, be used in functionality relating to QoS.

[0107] In some embodiments, the information indicative of the first UE IP address may be the first UE IP address (i.e. the first UE IP address itself). In other embodiments, the information indicative of the first UE IP address may be a first IP address range and the first IP address range can comprise the first UE IP address. In some of these embodiments, the first IP address range may also comprise an IP address of one or more second UEs involved in one or more respective second sessions. Thus, in some embodiments, the binding information can indicate a UE IP address range instead of an individual UE IP address.

[0108] In some embodiments, the information indicative of the first application IP address may be the first application IP address (i.e. the first application IP address itself). In other embodiments, the information indicative of the first application IP address may be a second IP address range and the second IP address range can comprise the first application IP address. In some of these embodiments, the second IP address range may also comprise an IP address of one or more second applications involved in one or more respective third sessions. Thus, in some embodiments, the binding information can indicate an application IP address range instead of an individual application IP address. The one or more respective second sessions and the one or more respective third sessions may be the same or different. For example, any of the one or more second UEs and any of the one or more second applications can be involved in the same session. Similarly, for example, any of the one or more second UEs and any of the one or more second applications can be involved in a different session.

[0109] In some embodiments, the first session can be a first packet data unit (PDU) session. In some embodiments, the one or more respective second sessions can be one or more respective second PDU sessions. In some embodiments, the one or more respective third sessions can be one or more respective third PDU sessions.

[0110] In some embodiments where the network is a fifth generation core (5GC) network, the first network node can be an application function (AF) node and the second network node can be a policy control function (PCF) node. In other embodiments where the network is an evolved packet core (EPC) network, the first network node may be an AF node (e.g. an application server node) and the second network node may be a policy charging rules function (PCRF) node.

[0111] Figure 10 illustrates a second method performed by a second network node of the network in accordance with an embodiment. The second method is for managing binding information in the network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the second method of Figure 10. The second method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments.

[0112] With reference to Figure 10, as illustrated at block 1002, the second method comprises performing session binding in response to receiving the first message from the first network node of the network. More specifically, the second network node (e.g. the processing circuitry of the second network node) performs the session binding. The first message comprises binding information. The binding information comprises information indicative of an IP address of a first UE involved in a first session and information indicative of an IP address of a first application involved in the first session. The session binding is performed by associating the binding information to the first session. In some embodiments, the first message may be received using a service operation, such as the Npcf_PolicyAuthorization_Create service operation mentioned earlier.

[0113] In some embodiments, the first message may comprise QoS information indicative of a QoS requested for the first UE. Thus, the first message can comprise a QoS request.

[0114] In some embodiments, an information element (IE) of the first message can comprise an attribute that indicates the information indicative of the IP address of the first UE. In some embodiments, the IE may be extended to comprise an additional attribute that indicates the information indicative of the IP address of the first application. In some of these embodiments, the IE may be an AppSessionContextReqData IE. The AppSessionContextReqData IE can be an IE that identifies service requirements of a context for the first session.

[0115] In some embodiments, the IP address of the first UE may be an IPv4 address of the first UE. In other embodiments, the IP address of the first UE may be an IPv6 address of the first UE.

[0116] In some embodiments, the information indicative of the first UE IP address may be the first UE IP address (i.e. the first UE IP address itself). In other embodiments, the information indicative of the first UE IP address may be a first IP address range and the first IP address range can comprise the first UE IP address. In some of these embodiments, the first IP address range may also comprise an IP address of one or more second UEs involved in one or more respective second sessions. In some of these embodiments, the session binding may be performed by associating the binding information to the first session and the one or more respective second sessions.

[0117] In some embodiments, the information indicative of the first application IP address may be the first application IP address (i.e. the first application IP address itself). In other embodiments, the information indicative of the first application IP address may be a second IP address range and the second IP address range can comprise the first application IP address. In some of these embodiments, the second IP address range may also comprise an IP address of one or more second applications involved in one or more respective third sessions. In some of these embodiments, the session binding may be performed by associating the binding information to the first session and the one or more respective third sessions.

[0118] The one or more respective second sessions and the one or more respective third sessions may be the same or different. For example, any of the one or more second UEs and any of the one or more second applications can be involved in the same session. Similarly, for example, any of the one or more second UEs and any of the one or more second applications can be involved in a different session.

[0119] In some embodiments involving one or both of the first and second IP address ranges, session binding may be performed by associating the binding information to all sessions matching the IP address range(s) expressed in the binding information.

[0120] In some embodiments, the first session can be a first PDU session. In some embodiments, the one or more respective second sessions can be one or more respective second PDU sessions. In some embodiments, the one or more respective third sessions can be one or more respective third PDU sessions.

[0121] In some embodiments where the network is a 5GC network, the first network node can be an AF node and the second network node can be a PCF node. In other embodiments where the network is an EPC network, the first network node may be an AF node (e.g. an application server node) and the second network node may be a PCRF node.

[0122] There is also provided a system comprising the first network node described herein and the second network node described herein. A method performed by this system comprises the method described herein in respect of the first network node and the method described herein in respect of the second network node.

[0123] Figure 11 illustrates a system (or network) 1100 according to an embodiment in relation to the first technique. The system 1100 comprises a first network node 1101 and a second network node 1116. In the embodiment illustrated in Figure 11 , the first network node is an AF node 1101 and the second network node is a PCF node 1116. The system 1100 illustrated in Figure 11 comprises a session management function (SMF) node 1114. Thus, the system 1100 illustrated in Figure 11 is a fifth generation system (5GS). However, it will be understood that the method described with reference to Figure 11 can equally be performed in other systems. For example, in the case of an evolved packet system (EPS), the method performed by the AF node 1101 of the 5GS can be performed by an AF node (e.g. an AS) node of the EPS, the method performed by the PCF node 1116 can be performed by a PCRF node, and the method performed by the SMF node 1114 can be performed by a packet data network gateway (PGW), such as a control plane PGW (PGW-C).

[0124] As illustrated by arrow 1120, the AF node 1101 transmits a first message towards the PCF node 1116 and thus the PCF node 1116 receives the first message from the AF node 1101. As illustrated by arrow 1124, the PCF node 1116 performs session binding in response to receiving the first message.

[0125] In some embodiments, the first message may comprise a QoS request. For example, when a QoS is configured via the PCF node 1116 (e.g. over the N5 or Rx interface), the PCF node 1116 needs to perform session binding. In some embodiments, the first message may be transmitted and received using a service operation, such as the Npcf_PolicyAuthorization_Create service operation mentioned earlier. For example, the first message may comprise a Npcf_PolicyAuthorization_Create request. The PCF node 1116 can receive application session context information as part of the Npcf_PolicyAuthorization_Create service operation. The application session context information can comprise information used for session binding in the PCF node 1116, for which an enhancement is required.

[0126] The first message comprises binding information. Advantageously, the binding information comprises information indicative of an IP address of a first UE involved in a first session and information indicative of an I P address of a first application (which is not illustrated in Figure 11) involved in the first session. The session binding is performed by associating the binding information to the first session. In some embodiments involving one or both of the first and second IP address ranges described earlier, session binding may be performed by associating the binding information to all sessions matching the IP address range(s) expressed in the binding information.

[0127] The PCF node 1116 may identify one or more sessions by matching information about one or more sessions (i.e. session information) with the body of the first message or, more specifically, the binding information of the first message. In the example mentioned earlier where a QoS is configured via the PCF node 1116, the PCF node 1116 may identify one or more sessions for which to configure the QoS. The sessions referred to herein can be PDU sessions and the session information can be PDU session information according to some embodiments.

[0128] As illustrated by arrow 1122, the SMF node 1114 may provide the PCF node 1116 with information for use in the session binding. The information can comprise the earlier mentioned session information. The session information can, for example, comprise one or more framed routes and / or one or more delegated prefixes. The one or more delegated prefixes referred to herein can, for example, comprise one or more delegated IPv4 addresses and / or one or more delegated IPv6 prefixes. The PCF node 1116 may receive all the required information about established session(s) from the SMF 1114. In embodiments where the PCF node 1116 receives information sets from the SMF node 1114 as well as the AF node 1101 , the PCF node 1116 may perform session binding using both information sets (e.g. to associate AF sessions and PDU sessions).

[0129] Thus, multi-session steering can be performed using session binding according to the first technique described herein. More specifically, for example, session binding for multiple sessions can be performed using the same session information (e.g. framed routes and / or delegated prefixes). Multiple bindings are allowed, such as where an AF session is bound to all matching PDU sessions. A distinction of the UE IP address and application IP address (e.g. framed route and / or delegated prefix) into session binding parameters can be included, such as by enhancing the Npcf_PolicyAuthorizationCreate service operation and the session binding itself. The session binding can be performed in the context of connecting a local network via multiple sessions, or in any other context.

[0130] The possible session binding parameters in 3GPP TS 29.513 V18.3.0, Section 6.2, can be extended to include the application IP address (e.g. framed route and / or delegated prefix), in addition to the UE IP address. The AF node 1101 can include a distinction of the UE IP address and the application IP address into the session binding parameters. The PCF node 1116 may already receive sufficient information from the SMF node 1114 (at arrow 1122) to perform more distinct session binding. However, if the AF node 1101 also includes the UE IP address plus the application IP address, an even more distinct session binding can be performed. The application IP address may also be referred to herein as an “additional IP address” or a “policy and charging control (PCC) rule IP address”. In general, in a 5GS (and previous generations), PCC can be used to manage the flow and treatment of data, as well as the charging of customers for using network services.

[0131] 3GPP TS 29.513 V18.3.0, Section 6.2, states the following:

[0132] The session binding is the association of the AF session information to one and only one PDU session.

[0133] However, in the manner described herein in respect of the first technique, it is possible to wildcard certain parameters and support a session binding to multiple sessions, such as multiple sessions of a UE. The first technique described herein enables the session binding process for a scenario where the same IP address is reachable over multiple sessions (e.g. during session and service continuity (SSC) mode 3 UPF relocation). This has not previously been possible and thus the PCF node 1116 instead simply rejects requests (e.g. QoS requests), such as via Npcf_PolicyAuthorization.

[0134] Advantageously, the AF node 1101 provides the PCF node 1116 with enhanced binding information that comprises the IP address of the UE involved in the session and also the IP address of the application. In a more detailed example, a QoS request transmitted from the AF node 1101 to the PCF node 1116 using the Npcf_PolicyAuthorization Create service operation can be enhanced in one or both of the following ways to enable session binding for the described scenario:

[0135] • Use the “uelpv4” or “uelpv6” attribute (in AppSessionContextReqData IE) to indicate the UE IP address, and match the IP addresses in the FlowDescriptions with framed routes and / or delegated prefixes; and / or

[0136] • Extend the AppSessionContextReqData IE by a parameter or multiple parameters to explicitly indicate additional IPv4 or IPv6 addresses bound to the application session.

[0137] Figure 12 illustrates some examples of the use and enhancement of the data model for two different approaches, namely “Approach 1” and “Approach 2”. For Approach 1 , if the AppSessionContextReqData attribute comprises multiple media components and / or submedia components with different IP addresses in the flow descriptions corresponding to the application IP addresses, then the AF session is bound to all these PDU sessions. If there is no successful session binding in the described way, the PCF node 1116 can decide to match uelPv4 and uelPv6 with framed routes and delegated prefixes of established PDU sessions. If neither uelpv4 nor uelpv6 (nor a ueMac attribute) is present, the PCF node 1116 may bind the AF session to all matching established PDU sessions. To avoid excessive matches, a subscriber permanent identifier (SUPI) or a generic public subscription identifier (GPSI) can be made mandatory, such as in a case where neither uelpv4 nor uelpv6 (nor ueMac) is present.

[0138] For Approach 2, if no applpv4 and no applpv6 is indicated, and there is no successful session binding in the described way, the PCF node 1116 can decide to match uelpv4 and uelpv6 with framed routes and delegated prefixes of established PDU sessions. If neither uelpv4 nor uelpv6 (nor a ueMac attribute) is present, the PCF node 1116 may bind the AF session to all matching established PDU sessions. In this case, applpv4 or applpv6 may be present. To avoid excessive matches, a SUPI or GPSI can be made mandatory, such as in a case where neither uelpv4 nor uelpv6 (nor ueMac) is present.

[0139] As mentioned earlier, some embodiments can involve an IP address range. In this respect, for expressing an IPv4 address range, an IPv4 address mask can be added as another parameter (such as type “lpv4AddrMask”, e.g. as used in different context on the same interface and specified in TS 29.571). An IPv4 address mask can be used in relation to the uelPv4 field for both Approach 1 and Approach 2. Similarly, an IPv4 address mask can be used in relation to the applpv4 field in Approach 2. For Approach 1 , a range of application IPv4 addresses can already be included using multiple MediaSubComponent lEs.

[0140] On the other hand, for expressing an IPv6 address range, an IPv6 prefix length can be added as another parameter (e.g. a simple integer value, such as an integer value in the range from 1 to 128). An IPv6 prefix length can be used in relation to the uelPv6 field for both Approach 1 and Approach 2. Similarly, an IPv6 prefix length can be used in relation to the applpv6 field in Approach 2. For Approach 1 , a range of application IPv6 addresses can already be included using multiple MediaSubComponent lEs.

[0141] The first technique described herein can be used for session binding in each PCF node 1116 individually, when multiple PCF nodes are used. Multiple SMF nodes 1122 using the same PCF node 1116 is supported. The first technique described herein can provide enhancements to 3GPP TS 29.513 V18.3.0, Section 6.2, to allow for the described session binding modifications. Moreover, first technique described herein can provide enhancements to 3GPP TS 29.514 V18.3.0, Sections 4.2.2.2 and 5.6.2.3, and other sections. Although the first technique is mostly described for framed routing, it will be understood that it is equally applicable for prefix delegation (e.g. IPv6 prefix delegation).

[0142] A second technique will now be described with reference to Figures 13 to 16.

[0143] Figure 13 illustrates a third method performed by a third network node of a network in accordance with an embodiment. The third method is for managing path selection in the network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the third method of Figure 13. The third method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments.

[0144] With reference to Figure 13, as illustrated at block 1302, the third method comprises selecting, from a plurality of paths, a path via which to route a packet received at the third network node. More specifically, the third network node (e.g. the processing circuitry of the third network node) performs the selection. The plurality of paths are between the third network node and a destination of the packet (e.g. a UE, a client node, an application, or any other destination of the packet). The path is selected based on one or more characteristics of the path meeting a policy comprising one or more path selection criteria. Herein, a packet can be a packet of data (i.e. a data packet) or any other type of packet.

[0145] In some embodiments, the one or more characteristics of the path may comprise a characteristic that the path is active and the one or more path selection criteria may comprise a criterion that requires the selected path to be active. Alternatively or in addition, in some embodiments, the one or more characteristics of the path may comprise a characteristic that the path has the lowest latency out of the plurality of paths and the one or more path selection criteria may comprise a criterion that requires the selected path to have the lowest latency out of the plurality of paths.

[0146] Although not illustrated in Figure 13, in some embodiments, the third method may comprise acquiring the policy from a fourth network node associated with an origin of the packet (e.g. a server, a data network such as a server of the data network, or any other origin of the packet) or acquiring the policy from a fifth network node that is responsible for providing policies in the network. More specifically, the third network node (e.g. the processing circuitry of the third network node) can acquire the policy.

[0147] Although also not illustrated in Figure 13, in some embodiments, the third method may comprise discovering the plurality of paths. More specifically, the third network node (e.g. the processing circuitry of the third network node) can discover the plurality of paths.

[0148] Although also not illustrated in Figure 13, in some embodiments, the third method may comprise routing the packet to the destination via the selected path. More specifically, the third network node (e.g. the processing circuitry of the third network node) can route the packet in this way.

[0149] In some embodiments, the plurality of paths may be identified during a packet forwarding control protocol (PFCP) session look-up. Alternatively or in addition, in some embodiments, the plurality of paths may be a plurality of sessions, such as a plurality of packet data unit (PDU) sessions.

[0150] In some embodiments where the network is a 5GC network, the third network node can be a UPF node. In some embodiments where the network is an EPC network, the third network node can be a PGW (e.g. a PGW-ll).

[0151] Figure 14 illustrates a fourth method performed by a fourth network node of the network in accordance with an embodiment. The fourth method is for managing path selection in the network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the fourth method of Figure 14. The fourth method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments. With reference to Figure 14, as illustrated at block 1402, the fourth method comprises setting the policy comprising one or more path selection criteria on the basis of which the path is to be selected, from the plurality of paths, for routing the packet received at the fourth network node. More specifically, the fourth network node (e.g. the processing circuitry of the fourth network node) sets the policy. The fourth network node is associated with an origin of the packet (e.g. a server, a data network such as a server of the data network, or any other origin of the packet). The plurality of paths are between the third network node of the network and the destination of the packet (e.g. a UE, a client node, an application, or any other destination of the packet). The path is to be selected based on one or more characteristics of the path meeting the one or more path selection criteria.

[0152] Although not illustrated in Figure 14, in some embodiments, the fourth method may comprise one or both of providing the policy to the third network node and providing the policy to a fifth network node that is responsible for providing policies in the network. More specifically, the fourth network node (e.g. the processing circuitry of the fourth network node) can provide the policy.

[0153] Although also not illustrated in Figure 14, in some embodiments, the fourth method may comprise updating the policy to comprise one or more updated path selection criteria in response to a change to the plurality of paths. More specifically, the fourth network node (e.g. the processing circuitry of the fourth network node) can update the policy.

[0154] Although also not illustrated in Figure 14, in some embodiments, the fourth method may comprise configuring the policy in the network. More specifically, the fourth network node (e.g. the processing circuitry of the fourth network node) can configure the policy. In some embodiments, configuring the policy in the network may comprise configuring the policy at a fifth network node of the network via a control interface. In these embodiments, the fifth network node can be responsible for providing policies in the network.

[0155] In some embodiments, the one or more characteristics of the path may comprise a characteristic that the path is active and the one or more path selection criteria may comprise a criterion that requires the selected path to be active. Alternatively or in addition, in some embodiments, the one or more characteristics of the path may comprise a characteristic that the path has the lowest latency out of the plurality of paths and the one or more path selection criteria may comprise a criterion that requires the selected path to have the lowest latency out of the plurality of paths.

[0156] In some embodiments, the plurality of paths may be a plurality of session, such as a plurality of PDU sessions.

[0157] In some embodiments where the network is a 5GC network, the third network node can be a UPF node. In some embodiments where the network is an EPC network, the third network node can be a PGW (e.g. a PGW-ll).

[0158] Figure 15 illustrates an example of a packet processing flow in a third network node 1502 according to an embodiment. The third network node 1502 can be as described with reference to the UPF node 102 of Figure 1 , with the incoming packet 1504 in Figure 15 corresponding to the incoming packet 104 in Figure 1 , the outgoing packet 1506 in Figure 15 corresponding to the outgoing packet 106 in Figure 1 , block 1506 in Figure 15 corresponding to block 106 in Figure 1 , block 1508 in Figure 15 corresponding to block 108 in Figure 1 , the selected PDR 1510 in Figure 15 corresponding to the selected PDR 110 in Figure 1 , and block 1512 in Figure 15 corresponding to block 112 in Figure 1. However, the difference between Figures 1 and 15 is that, in Figure 15, the PFCP session look-up can advantageously have multiple matches. That is, in Figure 15, any incoming packet 1504 can match the PDR(s) of multiple PFCP sessions.

[0159] There is also provided a system comprising the third network node described herein and the fourth network node described herein. A method performed by this system comprises the method described herein in respect of the third network node and the method described herein in respect of the fourth network node.

[0160] Figure 16 illustrates a system (or network) 1600 according to an embodiment in relation to the second technique. The system 1600 comprises a third network node 1602 and a fourth network node 1604. In the embodiment illustrated in Figure 16, the third network node is a UPF node 1602 and the fourth network node is a server multipath (MP) function node 1604. The server MP function node 1604 can also be referred to as a gateway (GW) at the server side of the system. The system 1600 can comprise a fifth network node 1616 that is responsible for providing policies in the system 1600. In the embodiment illustrated in Figure 16, the fifth network node is a PCF node 1616. The system 1600 can also comprise an SMF node 1614, a client node 1606, a client MP function node 1608, UEs 1610, 1612, and a server node 1618. A DN may comprise the server node 1618 and optionally also the server MP function node 1604. The client MP function node 1608 can also be referred to as a GW at the client side of the system. The client node 1606 can, for example, be a non-3GPP device.

[0161] The system 1600 illustrated in Figure 16 is a 5GS. However, it will be understood that the method described with reference to Figure 16 can equally be performed in other systems. For example, in the case of an EPS, the method performed by the UPF node 1602 can be performed by a PGW (such as a PGW-ll), the method performed by the PCF node 1616 can be performed by a PCRF node, and the method performed by the SMF node 1614 can be performed by a PGW (such as a PGW-C).

[0162] As illustrated in Figure 16, there are a plurality of paths 1620, 1622 established between the UPF node 1602 and the client node 1606. The server MP function node 1628 is aware of the status of the paths 1620, 1622 and can decide which of the paths 1620, 1622 is to be used at a given time.

[0163] As illustrated in Figure 16, a control interface 1630 may be defined (e.g. via the PCF node 1616). The MP function node 1628 can inform the 5GC, using the control interface 1630, about the current available paths 1620, 1622 and the policy (or steering method) that is to be used to select a path. That is, the control interface 1630 may be defined (e.g. via the PCF node 1616) to specify the policy to control path selection. In particular, as mentioned earlier, in some embodiments, the policy on which the path selection is based may be configured at the PCF node 1616 via such a control interface 1630. The control interface 1630 can be used by an MP function (e.g. the server MP function node 1604) that is aware of the status of the multiple paths 1620, 1622 and is able to influence the selection of a path at that time.

[0164] As illustrated by arrow 1624, the server node 1618 transmits a packet (e.g. IP packet) to a destination 1606. The destination 1606 can, for example, be indicated by an address (e.g. an IP address). In the embodiment illustrated in Figure 16, the destination 1606 is the client node 1606. As also illustrated by arrow 1624, the packet is received at the UPF node 1602 via the server MP function node 1604. The server MP function node 1604 is associated with the origin of the packet, which is the server node 1618 in this illustrated embodiment.

[0165] The UPF node 1602 selects, from the plurality of paths 1620, 1622, a path 1622 via which to route the packet. The path 1622 is selected based on one or more characteristics of the path meeting a policy comprising one or more path selection criteria. In some embodiments, the UPF node 1602 may perform PDR matching and multiple matches can be found due to the multiple paths 1620, 1622. The UPF node 1602 can then select a path 1622 based on the policy (or selected steering method). As illustrated by arrow 1628, the UPF node 1602 may acquire the policy from the server MP function node 1628. Thus, the server MP function node 1628 can provide the policy to the UPF node 1602. However, in other embodiments, the UPF node 1602 may acquire the policy from the PCF node 1616. Thus, the PCF node 1616 may provide the policy to the UPF node 1602 in other embodiments.

[0166] As illustrated by arrow 1626, the UPF node 1602 routes the packet to the destination 1606 via the selected path 1622.

[0167] Thus, multi-session steering can be performed according to the second technique described herein, where path decisions are based on policies. More specifically, a steering functionality can be added to the packet processing that is performed in the UPF node 1602 to enable multiple paths when forwarding packets to a UE 1610, 1612 or a client node (e.g. a device) 1606 behind a UE 1610, 1612. With regard to packet forwarding in the UPF node 1602, from the limited information in the packet (e.g. IP packet) arriving at the UPF node 1602, the UPF node 1602 must take a forwarding decision. Multiple PDR matches are allowed in the UPF node 1602 and the steering modes (e.g. active / standby, lowest latency, etc.) can be specified based on which forwarding decision is taken. More specifically, multiple matches are allowed during the PFCP session look-up in the UPF node 1602 and the ability to specify steering methods (e.g. active / standby, lowest latency, etc.) is added so that the UPF node 1602 can select one of the resulting matches. For uplink traffic, a corresponding functionality may be present in a gateway (e.g. client MP function node 1608) behind the UEs 1610, 1612. Currently, 3GPP standards assume and require that there is always only a single active path, i.e. a UPF node cannot be configured with multiple PDRs that match the same packet with the exact same parameters. However, the second technique described herein advantageously lifts this restriction and allows multiple paths. An additional path decision step is taken in the packet processing in the UPF node 1602, based on a traffic steering method.

[0168] The second technique described herein allows the use of multiple paths to client nodes (e.g. devices) behind the UEs 1610, 1612. By allowing multiple matches during a PCFP session look-up, the UPF node 1602 can have multiple available paths (e.g. PDU sessions) to forward a downlink packet, and a specific path can be selected by a steering method chosen based on influence from the server MP function node 1604. The server MP function node 1604 can configure this influence in the 5GC through a control interface 1630, e.g. on the N5 interface to the PCF node 1616 or via a network exposure function (NEF) node. This influence can operate in a similar manner to AF traffic influence or access traffic steering, switching and splitting (ATSSS) functionalities.

[0169] In some embodiments, multiple policies (or steering methods) can be introduced. These policies may be inspired by steering methods introduced in the ATSSS feature.

[0170] Examples of policies (or steering methods) that can be used include (but are not limited to) one or both of the following:

[0171] • Active-standby: One path is to be the main active path for packet forwarding. The other paths are to be on standby, e.g. to be used if the main path becomes unavailable.

[0172] • Smallest delay: The delay along the path may be measured when the path is established and the delay may be reported. The path with the lowest delay is to be used as the main path for packet forwarding.

[0173] In contrast to ATSSS, this allows the UPF node 1602 to select a path for packet forwarding when multiple sessions (e.g. PDU sessions) are established towards one endpoint, while in ATSSS only one session is established of type Multi-Access, which allows a simultaneous connection through 3GPP access and non-3GPP access. The server MP function node 1604 can communicate the preferred policy (or steering method) as paths 1620, 1622 are established and / or can update the policy (or steering method) selection dynamically, e.g. if needed. In the uplink, as the paths 1620, 1622 are established between the MP functions 1608, 1604, the client MP function node 1608 will be aware of the selected policy, either from negotiation with the server MP function node 1604 or from the 5GC (e.g. via an AMF), and thus the client MP function node 1608 can forward uplink packets in the appropriate path 1620, 1622.

[0174] In order to reduce performance issues or slowing down due to allowing multiple PFCP sessions during the look-up, a logical check can be introduced (e.g. a special flag in the subscriber profile, or during the PDU session setup) to allow multiple PFCP sessions to be matched. This can prevent conducting further unneeded PFCP session match lookups during packet processing at the UPF node 1602 and eliminate unnecessary performance penalties.

[0175] The server MP function node 1604 can be centralized (e.g. per country or geographical region) or it may be distributed. In the latter case, the state of the paths 1620, 1622 can be communicated between the distributed nodes of the server MP function node 1604.

[0176] The second technique described herein can provide enhancements to the packet processing flow in the UPF node described in 3GPP TS 29.244 V18.3.0. The second technique described herein can also provide enhancements to the European Telecommunications Standards Institute’s Rail Telecommunications TS (ETSI RT TS) 103 765-1.

[0177] A third technique will now be described with reference to Figures 17 to 20.

[0178] Figure 17 illustrates a fifth method performed by a sixth network node of the network in accordance with an embodiment. The fifth method is for managing path selection in a network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the fifth method of Figure 17. The fifth method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments. With reference to Figure 17, as illustrated at block 1702, the fifth method comprises selecting, from a plurality of paths, a path via which to route a packet received at the sixth network node. More specifically, the sixth network node (e.g. the processing circuitry of the sixth network node) performs the selection. The plurality of paths are between the sixth network node and a destination of the packet. The path is selected based on a flow descriptor of the path matching a flow descriptor assigned to the packet.

[0179] Although not illustrated in Figure 17, in some embodiments, the fifth method may comprise acquiring the flow descriptor assigned to the packet in a header of the packet. More specifically, the sixth network node (e.g. the processing circuitry of the sixth network node) can acquire the flow descriptor assigned to the packet.

[0180] Although also not illustrated in Figure 17, in some embodiments, the fifth method may comprise acquiring the flow descriptor of the path. More specifically, the sixth network node (e.g. the processing circuitry of the sixth network node) can acquire the flow descriptor of the path. For example, the fifth method may comprise acquiring the flow descriptor of the path from a seventh network node of the network associated with an origin of the packet (e.g. a server, a data network such as a server of the data network, or any other origin of the packet), acquiring the flow descriptor of the path from an eighth network node that is responsible for providing policies in the network, or acquiring the flow descriptor of the path from a packet (an uplink packet) received by the sixth network node via the path.

[0181] In some embodiments, the flow descriptor of the path may comprise one or more of a differentiated services code point (DSCP) of the path, a traffic class of the path, and a flow label of the path (e.g. a flow info IP header field for the path). In some embodiments, the flow descriptor assigned to the packet may comprise one or more of a DSCP assigned to the packet, a traffic class assigned to the packet, and a flow label assigned to the packet (e.g. a flow info IP header field assigned to the packet).

[0182] Although not illustrated in Figure 17, in some embodiments, the fifth method may comprise discovering the plurality of paths. More specifically, the sixth network node (e.g. the processing circuitry of the sixth network node) can discover the plurality of paths. Although also not illustrated in Figure 17, in some embodiments, the fifth method may comprise routing the packet to the destination via the selected path. More specifically, the sixth network node (e.g. the processing circuitry of the sixth network node) can route the packet in this way.

[0183] In some embodiments, the plurality of paths may be identified during a PFCP session look-up. Alternatively or in addition, in some embodiments, the plurality of paths may be a plurality of sessions, such as a plurality of PDU sessions.

[0184] In some embodiments where the network is a 5GC network, the sixth network node can be a UPF node. In some embodiments where the network is an EPC network, the sixth network node can be a PGW (e.g. a PGW-ll).

[0185] Figure 18 illustrates a sixth method performed by a seventh network node of the network in accordance with an embodiment. The sixth method is for managing path selection in a network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the sixth method of Figure 18. The sixth method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments.

[0186] With reference to Figure 18, as illustrated at block 1802, the sixth method comprises assigning, to the packet received at the seventh network node, the flow descriptor on the basis of which a path is to be selected, from a plurality of path, for routing the packet. More specifically, the seventh network node (e.g. the processing circuitry of the seventh network node) assigns the flow descriptor to the packet. The seventh network node is associated with an origin of the packet (e.g. a server, a data network such as a server of the data network, or any other origin of the packet). The plurality of paths are between the sixth network node of the network and the destination of the packet (e.g. a UE, a client node, an application, or any other destination of the packet). The path is to be selected based on the flow descriptor of the path matching the flow descriptor assigned to the packet.

[0187] Although not illustrated in Figure 18, in some embodiments, the sixth method may comprise receiving the flow descriptor from a ninth network node associated with the destination of the packet. More specifically, the seventh network node (e.g. the processing circuitry of the sixth network node) can receive the flow descriptor.

[0188] Although also not illustrated in Figure 18, in some embodiments, the sixth method may comprise setting the flow descriptor. More specifically, the seventh network node (e.g. the processing circuitry of the sixth network node) can set the flow descriptor.

[0189] Although also not illustrated in Figure 18, in some embodiments, the sixth method may comprise communicating with a ninth network node associated with the destination of the packet to set the flow descriptor to assign to the packet. More specifically, the seventh network node (e.g. the processing circuitry of the sixth network node) can communicate with the ninth network node. In some embodiments, the sixth method may comprise establishing a path to communicate with the ninth network node. More specifically, the seventh network node (e.g. the processing circuitry of the sixth network node) can establish this path.

[0190] Although also not illustrated in Figure 18, in some embodiments, the sixth method may comprise providing the flow descriptor assigned to the packet in a header of the packet. More specifically, the seventh network node (e.g. the processing circuitry of the sixth network node) can provide the flow descriptor in this way.

[0191] Although also not illustrated in Figure 18, in some embodiments, the sixth method may comprise one or both of providing the flow descriptor of the path to the sixth network node and providing the flow descriptor of the path to an eighth network node that is responsible for providing policies in the network. More specifically, the seventh network node (e.g. the processing circuitry of the sixth network node) can provide the flow descriptor in this way.

[0192] In some embodiments, the flow descriptor of the path may comprise one or more of a DSCP of the path, a traffic class of the path, and a flow label of the path (e.g. a flow info IP header field for the path). In some embodiments, the flow descriptor assigned to the packet may comprise one or more of a DSCP assigned to the packet, a traffic class assigned to the packet, and a flow label assigned to the packet (e.g. a flow info IP header field assigned to the packet). In some embodiments, the plurality of paths may be a plurality of sessions, such as a plurality of PDU sessions.

[0193] In some embodiments where the network is a 5GC network, the sixth network node can be a UPF node. In some embodiments where the network is an EPC network, the sixth network node can be a PGW (e.g. a PGW-ll).

[0194] There is also provided a system comprising the sixth network node described herein and the seventh network node described herein. A method performed by this system comprises the method described herein in respect of the sixth network node and the method described herein in respect of the seventh network node.

[0195] Figure 19 illustrates a system (or network) 1900 according to an embodiment in relation to the third technique. The system 1900 comprises a sixth network node 1902 and a seventh network node 1904. In the embodiment illustrated in Figure 19, the sixth network node is a UPF node 1902 and the seventh network node is a server multipath (MP) function node 1904. The server MP function node 1904 can also be referred to as a GW at the server side of the system. The system 1900 can also comprise a client node 1906, a client MP function node 1908, UEs 1910, 1912, and a server node 1918. A DN may comprise the server node 1918 and optionally also the server MP function node 1904. The client MP function node 1908 can also be referred to as a GW at the client side of the system. The client node 1906 can, for example, be a non-3GPP device.

[0196] The system 1900 illustrated in Figure 19 is a 5GS. However, it will be understood that the method described with reference to Figure 19 can equally be performed in other systems. For example, in the case of an EPS, the method performed by the UPF node 1902 can be performed by a PGW (such as a PGW-U).

[0197] As illustrated in Figure 19, there are a plurality of paths 1920, 1922 established between the UPF node 1902 and the client node 1906. When a new path 1920 is established between the UPF node 1902 and the client node 1906, the server MP function node 1904 may set a flow descriptor for the path 1920.

[0198] As illustrated by arrow 1932, the client MP function node 1908 may provide a flow descriptor of a path 1920 to the server MP function node 1904. Thus, the server MP function node 1904 can acquire the flow descriptor of the path 1920 from the client MP function node 1908. For example, the client MP function node 1908 may mark a (uplink) packet, that it transmits to the server MP function node 1904 via the path 1920, with the flow descriptor of the path 1920. Thus, the server MP function node 1904 may acquire the flow descriptor of the path 1920 from a (uplink) packet that the server MP function node 1904 receives from the client MP function node 1908 via the path 1920. The server MP function node 1904 may communicate (e.g. negotiate) with the client MP function node 1908 in order to set the flow descriptor of the path 1920. In some embodiments, the server MP function node 1904 may provide the flow descriptor of the path 1920 to the PCF node 1916.

[0199] The UPF node 1902 can learn about the path 1920 from the flow descriptor in the (uplink) packet transmitted from the client MP function node 1908 to the server MP function node 1904. For example, the (uplink) packet may be transmitted via the UPF node 1902. Thus, the UPF node 1902 can acquire the flow descriptor of the path 1920 from the client MP function node 1908. In some embodiments, the UPF node 1902 may update a routing table based on the information received from the client MP function node 1908.

[0200] A (downlink) packet can be received at the server MP function node 1904 from the server node 1918. The server MP function node 1904 is associated with the origin of the packet, which is the server node 1918 in this illustrated embodiment. The destination 1906 of the packet may be indicated by an address (e.g. an IP address). In the embodiment illustrated in Figure 19, the destination 1906 is the client node 1906. The client MP function node 1908 is associated with the destination 1906 of the packet. The server MP function node 1904 assigns the flow descriptor to the packet and it is on the basis of the flow descriptor that a path is to be selected for routing the packet.

[0201] As illustrated by arrow 1928, the server MP function node 1908 provides the flow descriptor, assigned to the packet, to the UPF node 1902. Thus, the UPF node 1902 can acquire the flow descriptor, assigned to the packet, from the server MP function node 1628. For example, when forwarding the packet to the UPF node 1902, the server MP function node 1628 may mark the packet with the flow descriptor that is assigned to the packet. The UPF node 1602 selects, from the plurality of paths 1920, 1922, a path 1922 via which to route the packet. The path 1622 is selected based on the flow descriptor of the path 1920 matching the flow descriptor assigned to the packet.

[0202] As illustrated by arrow 1926, the UPF node 1902 may route (or forward) the packet to the destination 1906 via the selected path 1920. Thus, the UPF node 1902 can route (or forward) the packet to the destination 1906 based on the flow descriptor.

[0203] Figure 20 illustrates a system (or network) 2000 according to another embodiment in relation to the third technique. The system 2000 of Figure 20 is as described earlier with respect to the system 1900 of Figure 19 with a few exceptions that will now be described. In particular, the system 2000 also comprises an eighth network node 1916 that is responsible for providing policies in the system 2000. In the embodiment illustrated in Figure 20, the eighth network node is a PCF node 1916. With regard to the EPS equivalent, the method performed by the PCF node 1916 can be performed by a PCRF node.

[0204] In Figure 19, the client MP function node 1908 provides a flow descriptor of a path 1920 to the server MP function node 1904. In contrast, in Figure 20, the server MP function node 1904 sets the flow descriptor of the path 1920 and informs the 5GC (e.g. via the PCF node 1916) which path 1920 the flow descriptor indicates. For example, the server MP function node 1904 may provide the flow descriptor of the path 1920 to the PCF node 1916. Thus, the PCF node 1916 can receive the flow descriptor of the path 1920 from the server MP function node 1904.

[0205] In Figure 19, the UPF node 1902 can acquire the flow descriptor of the path 1920 from the client MP function node 1908. In contrast, in Figure 20, as illustrated by 1934, the UPF node 1902 can acquire the flow descriptor of the path 1920 from the PCF node 1916. Thus, the PCF node 1916 may provide the flow descriptor of the path 1920 to the UPF node 1902. In some embodiments, the UPF node 1902 may update a routing table based on the information received from the server MP function node 1904 (e.g. via the PCF node 1916).

[0206] Thus, multi-session steering can be performed according to the third technique disclosed herein, where path decisions are based on flow (or traffic) descriptors. With regard to packet forwarding in the UPF node 1902, from the limited information in the packet (e.g. IP packet) arriving at the UPF node 1902, the UPF node 1602 must take a forwarding decision. In this respect, flow descriptors can be used to mark downlink packets (or traffic) and corresponding packet detection rules can be installed in the UPF node 1902. The MP functions in the system can, for example, mark the packets (or traffic) in each path with a flow descriptor. The UPF node 1902 can update its packet forwarding rules to specific destinations based on a matching flow descriptor. The flow descriptors can be used in packet headers in PFCP session matching in the UPF node 1902 to enable the forwarding of packets along multiple paths to UEs 1910, 1912 or client nodes (e.g. devices) 1906 behind the UEs 1910, 1912.

[0207] In some embodiments, the flow descriptor can comprise one or more of a DSCP, traffic class, and flow label. A flow descriptor can be a value or any other type of flow descriptor. A flow descriptor may be unique to a specific path. The mapping between a flow descriptor and a specific path can, for example, be performed by self-learning or using instructions from an external node. When a downlink packet arrives at the UPF node 1902, the UPF node 1902 can utilise the flow descriptor from the packet (e.g. from the packet header and / or from the UE) to identify the path via which the packet is to be forwarded.

[0208] Currently, 3GPP standards assume and require that there is always only a single active path, i.e. a UPF node cannot be configured with multiple PDRs that exactly match the same packet. According to the current 3GPP standards, the UPF node allows PFCP session look-up using multiple criteria, such as (but not limited to) the traffic 4-tuple and the DSCP value. However, in situations where client nodes (e.g. devices) behind UEs use the same IP address regardless of which path (e.g. UE or PDU session) is being used, relying only on the 4-tuple to look-up a matching PFCP session is not enough and therefore the client nodes cannot utilise the multiple available paths. In particular, relying only on the 4-tuple when multiple paths are simultaneously used for traffic can result in ambiguous PFCP and PDR matches.

[0209] The third technique described herein provides a mechanism of using a flow descriptor (e.g. a DSCP, traffic class, and / or flow label) to resolve this ambiguity. This allows a single accurate PFCP (and then an appropriate PDR) match to be made. For example, the flow descriptor (e.g. in the packet header) can be used in addition to the 4-tuple to designate a (unique) path during the PFCP session look-up. This can allow the UPF node 1902 to forward packets to one of multiple available paths, for example, to a UE and thus devices behind the UE can utilise the multiple available paths.

[0210] As mentioned earlier, there are multiple ways a flow descriptor can be specified to designate a (single) path. For example, the specific flow descriptors for the different paths can be negotiated between the client MP function and the server MP function (e.g. as described with reference to Figure 19) or simply reflected or mirrored at the server MP function (e.g. as described with reference to Figure 20).

[0211] In more detail, in an example, the client MP function node 1908 and the server MP function node 1904 can negotiate a specific flow descriptor for a (unique) path between them when that path is established. The packets in the uplink direction and / or the downlink direction can then be marked with the negotiated flow descriptor. In another example, the server MP function node 1904 can simply reflect the flow descriptor that it receives from the client node 1906, without previously negotiating it.

[0212] After a flow descriptor is chosen by the MP function(s) to specify a (unique) path, there are different possible implementations that can be used to allow the UPF node 1902 to learn which path a flow descriptor in a received packet indicates.

[0213] In a first implementation, the server MP function node 1904 can interact with the 5GC (e.g. through the PCF node 1916) to instruct it which path the flow descriptor indicates. The flow descriptor may be different in downlink and uplink for the same path (e.g. if necessary). The server MP function node 1904 can be a part of the UPF node 1902, a combination of the SMF node and UPF node 1902, a part of the server node 1918, or another entity. The client MP function node 1908 can be a part of a UE (e.g. a UE acting as a master UE that controls other UEs), a part of the client node 1906, an orchestrator for the paths, or another entity.

[0214] In a second implementation, the UPF node 1902 can use the flow descriptor from an uplink packet to learn the path (e.g. a general packet radio service (GPRS) tunnelling protocol (GTP)) via which the uplink packet is received. The UPF node 1902 can use the learned path to forward a downlink packet that carries the same flow descriptor. The flow descriptor can also be set in a “reversed” reflective behaviour, where the client MP function 1908 reflects the value from downlink packets for uplink packets.

[0215] The server MP function node 1904 can be centralized (e.g. per country or geographical region) or it may be distributed. In the latter case, the state of the paths 1620, 1622 (and their corresponding flow descriptors) can be communicated between the distributed nodes of the server MP function node 1904.

[0216] The third technique described herein can provide enhancements to ETSI RT TS 103 765-1. The third technique described herein can also provide enhancements to 3GPP TS 29.244 (e.g. in terms of packet processing in the UPF node and / or configuration of reflective behaviour by the SMF node), such as in the case where the UPF node 1902 applies reflective behaviour (to select a path for the traffic descriptor in downlink traffic based on a traffic descriptor seen in the uplink traffic).

[0217] A fourth technique will now be described with reference to Figures 21 to 26.

[0218] Figure 21 illustrates a seventh method performed by a tenth network node of the network in accordance with an embodiment. The seventh method is for managing path selection in a network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the seventh method of Figure 21. The seventh method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments.

[0219] With reference to Figure 21 , as illustrated at block 2102, the seventh method comprises selecting, from a plurality of paths, a path via which to route a packet received at the tenth network node. More specifically, the tenth network node (e.g. the processing circuitry of the tenth network node) performs the selection. The plurality of paths are between the tenth network node and a destination of the packet (e.g. a UE, a client node, an application, or any other destination of the packet). The path is selected based on a border gateway protocol (BGP) update comprising information about the path.

[0220] In some embodiments, the information about the path may comprise a path length of the path. In some of these embodiments, the path may be selected based on the path length of the path being the shortest path length out of the path lengths of the plurality of paths. Although not illustrated in Figure 21 , in some embodiments, the seventh method may comprise acquiring the BGP update from an eleventh network node associated with a destination of the packet or acquiring the BGP update from a UE in the path. More specifically, the tenth network node (e.g. the processing circuitry of the tenth network node) can acquire the BGP update.

[0221] Although also not illustrated in Figure 21 , in some embodiments, the seventh method may comprise discovering the plurality of paths. More specifically, the tenth network node (e.g. the processing circuitry of the tenth network node) can discover the plurality of paths.

[0222] Although also not illustrated in Figure 21 , in some embodiments, the seventh method may comprise routing the packet to the destination via the selected path. More specifically, the tenth network node (e.g. the processing circuitry of the tenth network node) can route the packet in this way.

[0223] In some embodiments, the plurality of paths may be identified during a PFCP session look-up. Alternatively or in addition, in some embodiments, the plurality of paths may be a plurality of sessions, such as a plurality of PDU sessions.

[0224] In some embodiments where the network is a 5GC network, the tenth network node can be a II PF node. In some embodiments where the network is an EPC network, the tenth network node can be a PGW (e.g. a PGW-ll).

[0225] Figure 22 illustrates an eighth method performed by an eleventh network node of the network in accordance with an embodiment. The eighth method is for managing path selection in a network. The network node 10 described earlier with reference to Figure 8 can be configured to operate in accordance with the eighth method of Figure 22. The eighth method can be performed by or under the control of the processing circuitry 12 of the network node 10 according to some embodiments.

[0226] With reference to Figure 22, as illustrated at block 2202, the eighth method comprises generating the BGP update on the basis of which the path is to be selected, from the plurality of paths, for routing the packet received at the tenth network node. More specifically, the eleventh network node (e.g. the processing circuitry of the eleventh network node) generates the BGP update. The eleventh network node is associated with a destination of the packet. The plurality of paths are between the tenth network node and the destination of the packet (e.g. a UE, a client node, an application, or any other destination of the packet). The BGP update comprises information about the path.

[0227] In some embodiments, the information about the path may comprise a path length of the path. In some of these embodiments, it may be that the path is to be selected based on the path length of the path being the shortest path length out of the path lengths of the plurality of paths.

[0228] Although not illustrated in Figure 22, in some embodiments, the eighth method may comprise providing the BGP update to the tenth network node. More specifically, the eleventh network node (e.g. the processing circuitry of the eleventh network node) can provide the BGP update.

[0229] In some embodiments, the plurality of paths may be a plurality of sessions, such as a plurality of PDU sessions.

[0230] In some embodiments where the network is a 5GC network, the tenth network node can be a II PF node. In some embodiments where the network is an EPC network, the tenth network node can be a PGW (e.g. a PGW-ll).

[0231] There is also provided a system comprising the tenth network node described herein and the eleventh network node described herein. A method performed by this system comprises the method described herein in respect of the tenth network node and the method described herein in respect of the eleventh network node.

[0232] Figure 23 illustrates a system (or network) 1400 according to an embodiment in relation to the fourth technique. The system 2300 comprises a tenth network node 2302 and an eleventh network node 2308. In the embodiment illustrated in Figure 23, the tenth network node is a first UPF node 2302 and the eleventh network node is a client multipath (MP) function node 2308. The client MP function node 2308 can also be referred to as a GW at the client side of the system. The system 2300 can also comprise an application 2306, UEs 2310, 2312, a second UPF node 2352, and a server node 2318. A DN may comprise the server node 2318.

[0233] In the embodiment illustrated in Figure 23, a first AS 2340 comprises the first UPF node 2302, a second AS 2350 comprises the second UPF node 2352, a third AS 2358 comprises the server node 2318, and a fourth AS 2348 comprises the application 2306, client MP function node 2308, and UEs 2310, 2312. The fourth AS 2348 can comprise a GW 2346 comprising the client MP function node 2308 and UEs 2310, 2312.

[0234] Although certain numbers of components are illustrated for the purpose of the example, it will be understood that any other number of each of the components is equally possible.

[0235] The system 2300 illustrated in Figure 23 is a 5GS. However, it will be understood that the method described with reference to Figure 23 can equally be performed in other systems. For example, in the case of an EPS, the method performed by the UPF node 2302 can be performed by a PGW (such as a PGW-U).

[0236] A first path 2320 and a second path 2321 are established between the first UPF node 2302 and the application 2306 via a first UE 2310. A third path 2322 is established between the first UPF node 2302 and the application 2306 via a second UE 2312. A fourth path 2323 is established between the second UPF node 2352 and the application 2306 via the second UE 2312.

[0237] In the example illustrated in Figure 23, a first BGP session is established between the first AS 2340 and the fourth AS 2348 along the first path 2320, a second BGP session is established between the first AS 2340 and the fourth AS 2348 along the second path 2321 , a third BGP session is established between the first AS 2340 and the fourth AS 2348 along the third path 2322, and a fourth BGP session is established between the second AS 2350 and the fourth AS 2348 along the fourth path 2323. Also, a fifth BGP session is established between the first AS 2340 and the third AS 2358, and a sixth BGP session is established between the second AS 2350 and the third AS 2358.

[0238] With reference to Figure 23, the first UPF node 2302 selects, from the plurality of paths 2320, 2321 , 2322, a path 2320 via which to route a packet that it receives, e.g. from the server node 2318. The path 2320 is selected based on a BGP update comprising information about the path 2320. The client MP function node 2308 generates the BGP update. The client MP function node 2308 may provide the BGP update to the first UPF node 2302 via the BGP session that is established along the corresponding path 2320.

[0239] Figure 24 illustrates an example of a packet processing flow in a tenth network node 2402 according to an embodiment. The tenth network node 2402 can be as described with reference to the UPF node 102 of Figure 1 , with the incoming packet 2404 in Figure 24 corresponding to the incoming packet 104 in Figure 1 , the outgoing packet 2406 in Figure 24 corresponding to the outgoing packet 106 in Figure 1 , block 2406 in Figure 24 corresponding to block 106 in Figure 1 , block 2408 in Figure 24 corresponding to block 108 in Figure 1 , the selected PDR 2410 in Figure 24 corresponding to the selected PDR 110 in Figure 1 , and block 2412 in Figure 24 corresponding to block 112 in Figure 1. However, a difference between Figures 1 and 24 is that, in Figure 24, the PFCP session look-up can advantageously have multiple matches. That is, in Figure 24, any incoming packet 2404 can match the PDR(s) of multiple PFCP sessions. Another difference between Figures 1 and 24 is that, in Figure 24, a path 2320 is advantageously selected based on the BGP update comprising information about the path 2320.

[0240] Functionally, an SMF node may configure the UPF node 2402. However, at least some proprietary alternatives are equally possible (e.g. self-configuration of the UPF 2402 based on BGP information). The PDR configuration may be performed by any one or more of the following:

[0241] • Configuring framed routes in the UPF node 2402 for routes advertised via the BGP;

[0242] • Configuring delegated (e.g. IPv6) prefixes in the UPF node 2402 for routes advertised via the BGP; and

[0243] • Using proprietary ways to configure packet detection and / or forwarding.

[0244] The UPF node 2402 can establish a BGP session with a router behind a UE, e.g. one BGP session per PDU Session. Each PDU session may be an IP path that connects two ASs and carries the respective BGP packets in both directions. Both endpoints of the BGP session can be mutually addressable. Figure 25 illustrates a system (or network) 1600 according to another embodiment in relation to the fourth technique. The system 2500 can be as described earlier with reference to Figure 23, with the application 2506 in Figure 25 corresponding to the application 2306 in Figure 23, the MP function node 2508 in Figure 25 corresponding to MP function node 2308 in Figure 23, the first UE 2610 in Figure 25 corresponding to the first UE 2310 in Figure 23, the second UE 2512 in Figure 25 corresponding to the second UE 2312 in Figure 23, the first UPF node 2502 in Figure 25 corresponding to the first UPF node 2302 in Figure 23, the second UPF node 2552 in Figure 25 corresponding to the second UPF node 2352 in Figure 23, and the server node 2518 in Figure 25 corresponding to the server node 2318 in Figure 23.

[0245] In the embodiment illustrated in Figure 25, a first AS 2540 comprises the first UPF node 2502, a second AS 2550 comprises the second UPF node 2552, a third AS 2558 comprises the server node 2518, and a fourth AS 2548 comprises the application 2506, and the MP function node 2508. A GW 2546 comprises the MP function node 2508 and the UEs 2510, 2512. The GW 2546 is established between the ASs 2540, 2550 comprising the UPF nodes 2502, 2552 and the AS comprising the MP function node 2508. The first UE 2510 can be connected to the first AS 1640 and the second UE 2312 can be connected to the second AS 1650.

[0246] Although certain numbers of components are illustrated for the purpose of the example, it will be understood that any other number of each of the components is equally possible.

[0247] The system 2500 illustrated in Figure 25 is a 5GS. However, it will be understood that the method described with reference to Figure 25 can equally be performed in other systems. For example, in the case of an EPS, the method performed by the first UPF node 2502 can be performed by a PGW (such as a PGW-U).

[0248] A first path 2520 and a second path 2521 are established between the first UPF node 2502 and the application 2506 via a first UE 2510. A third path 2522 is established between the first UPF node 2502 and the application 2306 via a second UE 2512. A fourth path 2523 is established between the second UPF node 2552 and the application 2506 via the second UE 2512. As illustrated in Figure 25, part of the paths 2520, 2521 , 2522, 2523 (specifically, the part between the UEs 2510, 2512 and the UPF nodes 2502, 2552) comprise a PDU session. In the example illustrated in Figure 25, a first BGP session and a second BGP session is established between the MP function node 2508 and the first UPF node 2502 via the first UE 2510, a third BGP session is established between the MP function node 2508 and the first UPF node 2502 via the second UE 2512, and a fourth BGP session is established between the MP function node 2508 and the second UPF node 2552 via the second UE 2512.

[0249] With reference to Figure 25, the first UPF node 2502 selects, from the plurality of paths 2520, 2521 , 2522, a path 2520 via which to route a packet that it receives, e.g. from the server node 2518. The path 2520 is selected based on a BGP update comprising information about the path 2520. The MP function node 2508 generates the BGP update. The MP function node 2508 may provide the BGP update to the first UPF node 2502 via the BGP session that is established along the corresponding path 2520.

[0250] Figure 26 illustrates a system (or network) 2600 according to another embodiment in relation to the fourth technique. The system is that illustrated in Figure 25 and thus all the entities are as described with reference to Figure 25. However, in the system 2600 illustrated in 26, the entities are cascaded in a cloud implementation. Specifically, more centralised entities are used to aggregate more distributed entities.

[0251] Thus, multi-session steering can be performed according to the fourth technique, where path decisions are based on BGP. With regard to packet forwarding in the UPF node 2302, 2502, from the limited information in the packet (e.g. IP packet) arriving at the UPF node 2302, 2502, the UPF node 2302, 2502 must take a forwarding decision. Multiple PDR matches are allowed in the UPF node 2302, 2502 and BGP updates (e.g. from the UE 2310, 2510 to the UPF node 2302, 2502) can be used to influence the forwarding decision. For uplink traffic, a corresponding functionality can be present in a GW behind the UEs 2310, 2510, 2312, 2512. In more detail, multiple PDR matches can be allowed in the UPF node 2302, 2502 for a downlink packet, a BGP between the MP function node 2308, 2508 and the UPF node 2302, 2502 can be used to indicate a reachability of IP addresses over a path, and BGP mechanisms can be used to influence the path decision. A target of enabling a set of devices to connect via multiple paths using the same IP address can be fulfilled. Moreover, any impact on applications to handle IP address changes can be avoided. The fourth technique descried herein, in particular, integrates well with a normal IP routing infrastructure and ecosystem. That is, minimal changes are needed to existing architecture in order to implement the fourth technique descried herein.

[0252] Currently, 3GPP standards assume and require that there is always only a single active path, i.e. the UPF node cannot be configured with multiple PDRs that exactly match the same packet. However, the fourth technique described herein advantageously lifts this restriction and allows multiple paths. An additional path decision step is taken in the packet processing in the UPF node 2302, 2502, based on BGP information.

[0253] While the packet detection described herein and the forwarding decision described herein can functionally be performed by the UPF node 2302, 2502, the BGP session management described herein can be performed by any one or more of the following entities:

[0254] • a router, which may be co-located with the UPF node 2302, 2502;

[0255] • the same router that has BGP sessions to other ASs not connected using PDU sessions;

[0256] • an SMF node; and

[0257] • an independently functioning (or dedicated) network node, which may not be a router.

[0258] An entity that performs the BGP session management can ensure that routes advertised by the MP function node 2308, 2508 are further advertised to other ASs. The entity can modify the information about the path 2320, 2520 (e.g. the path length between ASs, “AS_path”) in the BGP updates sent to any other AS to influence the path decision. The MP function can use the different information about the path 2320, 2520 in the BGP updates sent over different BGP sessions to influence the path decision. For example, the fourth AS 2348, 2548 may indicate that AS_path “4” over one PDU session is to be prioritised, and that AS_path “4, 4, 4, 4” over other PDU sessions are to be used as backup. The fourth technique described herein can be combined with traffic steering methods to control more distinct, simultaneous use of multiple (valid) paths, e.g. IP paths.

[0259] The fourth technique described herein can provide enhancements to ETSI RT TS 103 765-1 and may also provide enhancements to 3GPP TS 29.244.

[0260] Herein, various techniques are described and the features of any one or more of those techniques may be combined. For example, any one of the first technique described herein, the second technique described herein, the third technique described herein, and the fourth technique described herein can be performed alone or any two or more of these techniques can be performed in combination (e.g. the first technique described herein can be performed in combination with any one or more of the second technique described herein, the third technique described herein, and the fourth technique described herein).

[0261] Any one or more of the following features alone or in combination is possible:

[0262] • Allow multiple bindings, such as where an AF session is bound to all matching PDU sessions.

[0263] • Implement one PCF node per SMF node or UPF node.

[0264] • Include a distinction of UE IP address and application IP address (e.g. framed route and / or delegated prefix (e.g. IPv4 delegated prefix and / or IPv6 delegated prefix) into session binding parameters, such as by enhancing the Npcf_PolicyAuthorization_Create service operation and / or the session binding itself.

[0265] • Use a single PDU session, e.g. with an uplink classifier (ULCL) and / or prefix delegation (e.g. IPv4 delegated prefix and / or IPv6 delegated prefix).

[0266] • Implement a single requesting router behind multiple UEs.

[0267] • Use a flow descriptor (e.g. DSCP, traffic class, flow label, and / or any other flow descriptor) to mark downlink traffic and install corresponding packet detection rules in the UPF node.

[0268] • Allow multiple PDR matches in the UPF node and use BGP updates (e.g. from the UE to the UPF node) to influence the packet forwarding decision. For uplink traffic, a corresponding functionality may be present in a gateway behind the UEs. • Allow multiple PDR matches in the UPF node and specify steering modes (e.g. active / standby, lowest latency, and / or any other steering modes) based on which a forwarding decision can be performed. For uplink traffic, a corresponding functionality may be present in a gateway behind the UEs.

[0269] Therefore, in the manner described herein, there are provided advantageous techniques that can be used to improve network management.

[0270] There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry 12 of the network node 10), cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry (such as the processing circuitry 12 of the network node 10) to cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product comprising a carrier containing instructions for causing processing circuitry (such as the processing circuitry 12 of the network node 10) to perform at least part of the method described herein. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0271] In some embodiments, the functionality described herein can be performed by hardware. Thus, in some embodiments, any one or more of the network nodes described herein can be a hardware node. However, it will also be understood that optionally at least part or all of the functionality described herein can be virtualized. For example, the functions performed by any one or more of the network nodes described herein can be implemented in software running on generic hardware that is configured to orchestrate the functionality. Thus, in some embodiments, any one or more of the network nodes described herein can be a virtual node. In some embodiments, at least part of the functionality described herein is performed in a network enabled cloud. At least some of the functionality is distributed.

[0272] It will be understood that at least some or all of the method steps described herein can be automated in some embodiments. That is, in some embodiments, at least some or all of the method steps described herein can be performed automatically. The method described herein can be a computer-implemented method.

[0273] It should be noted that the above-mentioned embodiments illustrate rather than limit the idea, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1. A method for managing binding information in a network, wherein the method is performed by a first network node (1101) of the network (1100), the method comprising:• initiating transmission (1120) of a first message towards a second network node (1116) of the network (1100), wherein: the first message comprises binding information, the binding information comprises information indicative of an internet protocol, IP, address of a first user equipment, UE, involved in a first session and information indicative of an IP address of a first application involved in the first session, the binding information enabling the session binding by associating the binding information to the first session.

2. A method as claimed in claim 1, wherein the first message is transmitted (1120) using an Npcf_PolicyAuthorization_Create service operation.

3. A method as claimed in claim 1 or 2, wherein the first message comprises quality of service, QoS, information indicative of a QoS requested for the first UE.

4. A method as claimed in any of the preceding claims, wherein an AppSessionContextReqData information element, IE, of the first message comprises an attribute that indicates the information indicative of the IP address of the first UE.

5. A method as claimed in claim 4, wherein the AppSessionContextReqData IE is extended to comprise an additional attribute that indicates the IP address of the first application.

6. A method as claimed in any of the preceding claims, wherein: the IP address of the first UE is an IPv4 address of the first UE; or the IP address of the first UE is an IPv6 address of the first UE.

7. A method as claimed in any of the preceding claims, wherein the information indicative of the IP address of the first UE is: the IP address of the first UE; or a first IP address range comprising the IP address of the first UE.

8. A method as claimed in claim 7, wherein: the information indicative of the IP address of the first UE is the first IP address range comprising the IP address of the first UE; and the first IP address range comprises an IP address of one or more second UEs involved in one or more respective second sessions.

9. A method as claimed in any of the preceding claims, wherein the information indicative of the IP address of the first application is: the IP address of the first application; or a second IP address range comprising the IP address of the first application.

10. A method as claimed in claim 9, wherein: the information indicative of the IP address of the first application is the second IP address range comprising the IP address of the first application; and the second IP address range comprises an IP address of one or more second applications involved in one or more respective third sessions.

11. A method as claimed in any of the preceding claims, wherein: the network (1100) is a fifth-generation core, 5GC, network, the first network node (1101) is an application function, AF, node, and the second network node (1116) is a policy control function, PCF, node; or the network (1100) is an evolved packet core, EPC, network, the first network node (1101) is an AF node, and the second network node (1116) is a policy charging rules function, PCRF, node.

12. A method for managing binding information in a network, wherein the method is performed by a second network node (1116) of the network (1100), the method comprising:• performing (1124) session binding in response to receiving (1120) a first message from a first network node (1101) of the network (1100), wherein: the first message comprises binding information, the binding information comprises information indicative of an internet protocol, IP, address of a first user equipment, UE, involved in a first session and information indicative of an IP address of a first application involved in the first session, and the session binding is performed by associating the binding information to the first session.

13. A method as claimed in claim 12, wherein the first message is received (1120) using an Npcf_PolicyAuthorization_Create service operation.

14. A method as claimed in claim 12 or 13, wherein the first message comprises quality of service, QoS, information indicative of a QoS requested for the first UE.

15. A method as claimed in any of claims 12 to 14, wherein an AppSessionContextReqData information element, IE, of the first message comprises an attribute that indicates the IP address of the first UE.

16. A method as claimed in claim 15, wherein the AppSessionContextReqData IE is extended to comprise an additional attribute that indicates the IP address of the application.

17. A method as claimed in any of claims 12 to 16, wherein: the IP address of the first UE is an IPv4 address of the first UE; or the IP address of the first UE is an IPv6 address of the first UE.

18. A method as claimed in any of claims 12 to 17, wherein: the information indicative of the IP address of the first UE is: the IP address of the first UE; or a first IP address range comprising the IP address of the first UE.

19. A method as claimed in claim 18, wherein: the information indicative of the IP address of the first UE is the first IP address range comprising the IP address of the first UE; and the first IP address range comprises an IP address of one or more second UEs involved in one or more respective second sessions.

20. A method as claimed in claim 19, wherein the session binding is performed by associating the binding information to the first session and the one or more respective second sessions.

21. A method as claimed in any of claims 12 to 20, wherein the information indicative of the IP address of the first application is: the IP address of the first application; or a second IP address range comprising the IP address of the first application.

22. A method as claimed in claim 21, wherein: the information indicative of the IP address of the first application is the second IP address range comprising the IP address of the first application; and the second IP address range comprises an IP address of one or more second applications involved in one or more respective third sessions.

23. A method as claimed in claim 22, wherein the session binding is performed by associating the binding information to the first session and the one or more respective third sessions.

24. A method as claimed in any of claims 12 to 23, wherein: the network (1100) is a fifth-generation core, 5GC, network, the first network node (1101) is an application function, AF, node, and the second network node (1116) is a policy control function, PCF, node; or the network (1100) is an evolved packet core, EPC, network, the first network node (1101) is an AF node, and the second network node (1116) is a policy charging rules function, PCRF, node.

25. A method for managing path selection in a network (1600), wherein the method is performed by a third network node (1602) of the network (1600), the method comprising:• selecting, from a plurality of paths (1620, 1622), a path (1622) via which to route (1626) a packet received (1624) at the third network node (1602), wherein: the plurality of paths (1620, 1622) are between the third network node (1602) and a destination (1606) of the packet, the path (1622) is selected based on one or more characteristics of the path meeting a policy comprising one or more path selection criteria, and the packet belongs to a session associated with binding information according to claim 12.

26. A method as claimed in claim 25, wherein: the one or more characteristics of the path (1622) comprise a characteristic that the path (1622) is active, and the one or more path selection criteria comprise a criterion that requires the selected path to be active; and / or the one or more characteristics of the path (1622) comprise a characteristic that the path (1622) has the lowest latency out of the plurality of paths and the one or more path selection criteria comprise a criterion that requires the selected path to have the lowest latency out of the plurality of paths.

27. A method as claimed in claim 25 or 26, the method comprising:• acquiring (1628) the policy from a fourth network node (1604) associated with an origin (1618) of the packet; or• acquiring the policy from a fifth network node (1616) that is responsible for providing policies in the network (1600).

28. A method as claimed in any of claims 25 to 27, the method comprising: discovering the plurality of paths (1620, 1622).

29. A method as claimed in any of claims 25 to 28, the method comprising:• routing (1626) the packet to the destination (1606) via the selected path (1622).

30. A method as claimed in any of claims 25 to 29, wherein: the plurality of paths (1620, 1622) are identified during a packet forwarding control protocol, PFCP, session look-up; and / or the plurality of paths (1620, 1622) are a plurality of packet data unit, PDU, sessions.

31. A method as claimed in any of claims 25 to 30, wherein: the network (1600) is a fifth-generation core, 5GC, network, and the third network node (1602) is a user plane function, UPF, node; or the network (1600) is an evolved packet core, EPC, network, and the third network node (1602) is a packet data network gateway, PGW.

32. A method for managing path selection in a network (1600), wherein the method is performed by a fourth network node (1604) of the network (1600), the method comprising:• setting a policy comprising one or more path selection criteria on the basis of which a path (1622) is to be selected, from a plurality of paths (1620, 1622), for routing (1626) a packet received (1624) at the fourth network node (1604), wherein: the fourth network node (1604) is associated with an origin (1618) of the packet, the plurality of paths (1620, 1622) are between a third network node (1602) of the network (1600) and a destination (1606) of the packet, the path (1622) is to be selected based on one or more characteristics of the path (1622) meeting the one or more path selection criteria, and the packet belongs to a session associated with binding information according to claim 12.

33. A method as claimed in claim 32, the method comprising one or both of:• providing (1628) the policy to the third network node (1602); and• providing the policy to a fifth network node (1616) that is responsible for providing policies in the network (1600).

34. A method as claimed in claim 32 or 33, the method comprising:• in response to a change to the plurality of paths (1620, 1622), updating the policy to comprise one or more updated path selection criteria.

35. A method as claimed in any of claims 32 to 34, the method comprising:• configuring the policy in the network (1600).

36. A method as claimed in claim 35, wherein configuring the policy in the network (1600) comprises:• configuring the policy at a fifth network node (1616) of the network (1600) via a control interface (1630), wherein the fifth network node (1616) is responsible for providing policies in the network (1600).

37. A method as claimed in any of claims 32 to 36, wherein: the one or more characteristics of the path (1622) comprise a characteristic that the path (1622) is active, and the one or more path selection criteria comprise a criterion that requires the selected path to be active; and / or the one or more characteristics of the path (1622) comprise a characteristic that the path (1622) has the lowest latency out of the plurality of paths and the one or more path selection criteria comprise a criterion that requires the selected path to have the lowest latency out of the plurality of paths.

38. A method as claimed in any of claims 32 to 37, wherein the plurality of paths (1620, 1622) are a plurality of packet data unit, PDU, sessions.

39. A method as claimed in any of claims 32 to 38, wherein: the network (1600) is a fifth-generation core, 5GC, network, and the third network node (1602) is a user plane function, UPF, node; or the network (1600) is an evolved packet core, EPC, network, and the third network node (1602) is a packet data network gateway, PGW.

40. A method for managing path selection in a network (1900, 2000), wherein the method is performed by a sixth network node (1902) of the network (1900, 2000), the method comprising:• selecting, from a plurality of paths (1920, 1922), a path (1920) via which to route (1926) a packet received (1924) at the sixth network node (1902), wherein: the plurality of paths (1920, 1922) are between the sixth network node (1902) and a destination (1906) of the packet, the path (1920) is selected based on a flow descriptor of the path (1920) matching a flow descriptor assigned to the packet, and the packet belongs to a session associated with binding information according to claim 12.41 . A method as claimed in claim 40, the method comprising:• acquiring the flow descriptor assigned to the packet in a header of the packet.

42. A method as claimed in claim 40 or 41 , the method comprising:• acquiring (1928) the flow descriptor of the path (1920) from a seventh network node (1904) of the network (1900) associated with an origin (1918) of the packet;• acquiring (1934) the flow descriptor of the path (1920) from an eighth network node (1916) that is responsible for providing policies in the network (2000); or acquiring the flow descriptor of the path (1920) from a packet received by the sixth network node (1902) via the path (1920).

43. A method as claimed in any of claims 40 to 42, wherein the flow descriptor of the path (1920) comprises one or more of: a differentiated services code point, DSCP, of the path (1920), a traffic class of the path (1920), and a flow label of the path (1920).

44. A method as claimed in any of claims 40 to 43, wherein the flow descriptor assigned to the packet comprises one or more of: a differentiated services code point, DSCP, assigned to the packet, a traffic class assigned to the packet, and a flow label assigned to the packet.

45. A method as claimed in any of claims 40 to 44, the method comprising:• discovering the plurality of paths (1920, 1922).

46. A method as claimed in any of claims 40 to 45, the method comprising:• routing (1926) the packet to the destination (1906) via the selected path (1922).

47. A method as claimed in any of claims 40 to 46, wherein: the plurality of paths (1920, 1922) are identified during a packet forwarding control protocol, PFCP, session look-up; and / or the plurality of paths (1920, 1922) are a plurality of packet data unit, PDU, sessions.

48. A method as claimed in any of claims 40 to 47, wherein: the network (1900, 2000) is a fifth generation core, 5GC, network, and the sixth network node (1902) is a user plane function, UPF, node; or the network (1900, 2000) is an evolved packet core, EPC, network, and the sixth network node (1902) is a packet data network gateway, PGW.

49. A method for managing path selection in a network (1900, 2000), wherein the method is performed by a seventh network node (1904) of the network (1900, 2000), the method comprising:• assigning, to a packet received at the seventh network node (1904), a flow descriptor on the basis of which a path (1920) is to be selected, from a plurality of paths (1920, 1922), for routing (1926) the packet, wherein: the seventh network node (1904) is associated with an origin (1618) of the packet, the plurality of paths (1920, 1922) are between a sixth network node (1902) of the network (1900, 2000) and a destination (1906) of the packet, the path (1920) is to be selected based on a flow descriptor of the path (1920) matching the flow descriptor assigned to the packet, and the packet belongs to a session associated with binding information according to claim 12.

50. A method as claimed in any of claims 49, the method comprising:• receiving (1932) the flow descriptor from a ninth network node (1908) associated with the destination (1906) of the packet.

51. A method as claimed in claim 49, the method comprising:• setting the flow descriptor.

52. A method as claimed in claim 51, the method comprising:• communicating (1932) with a ninth network node (1908) associated with the destination (1906) of the packet to set the flow descriptor to assign to the packet.

53. A method as claimed in claim 52, the method comprising:• establishing a path to communicate with the ninth network node (1908).

54. A method as claimed in any of claims 49 to 53, the method comprising:• providing the flow descriptor assigned to the packet in a header of the packet.

55. A method as claimed in any of claims 49 to 54, the method comprising one or both of:• providing (1928) the flow descriptor of the path (1920) to the sixth network node (1902); and• providing the flow descriptor of the path (1920) to an eighth network node (1916) that is responsible for providing policies in the network (2000).

56. A method as claimed in any of claims 49 to 55, wherein the flow descriptor of the path (1920) comprises one or more of: a differentiated services code point, DSCP, of the path (1920), a traffic class of the path (1920), and a flow label of the path (1920).

57. A method as claimed in any of claims 49 to 56, wherein the flow descriptor assigned to the packet comprises one or more of: a differentiated services code point, DSCP, assigned to the packet, a traffic class assigned to the packet, and a flow label assigned to the packet.

58. A method as claimed in any of claims 49 to 57, wherein the plurality of paths (1920, 1922) are a plurality of packet data unit, PDU, sessions.

59. A method as claimed in any of claims 49 to 58, wherein: the network (1900, 2000) is a fifth-generation core, 5GC, network, and the sixth network node (1902) is a user plane function, UPF, node, or the network (1900, 2000) is an evolved packet core, EPC, network, and the sixth network node (1902) is a packet data network gateway, PGW.

60. A method for managing path selection in a network (2500), wherein the method is performed by a tenth network node (2502) of the network (2500), the method comprising:• selecting, from a plurality of paths (2520, 2521 , 2522), a path (2520) via which to route a packet received at the tenth network node (2502), wherein: the plurality of paths (2520, 2521, 2522) are between the tenth network node (2502) and a destination (2506) of the packet, wherein the path (2520) is selected based on a border gateway protocol, BGP, update comprising information about the path (2520), and the packet belongs to a session associated with binding information according to claim 12.

61. A method as claimed in claim 60, wherein the information about the path (2520) comprises a path length of the path (2520).

62. A method as claimed in claim 61, wherein the path (2520) is selected based on the path length of the path (2520) being the shortest path length out of the path lengths of the plurality of paths (2520, 2521, 2522).

63. A method as claimed in any of claims 60 to 62, the method comprising:• acquiring the BGP update from an eleventh network node (2508) associated with a destination (2506) of the packet, or• acquiring the BGP update from a user equipment, UE, in the path (2520).

64. A method as claimed in any of claims 60 to 63, the method comprising: discovering the plurality of paths (2520, 2521 , 2522).

65. A method as claimed in any of claims 60 to 64, the method comprising:• routing the packet to the destination (2506) via the selected path (2520).

66. A method as claimed in any of claims 60 to 65, wherein: the plurality of paths (2520, 2521, 2522) are identified during a packet forwarding control protocol, PFCP, session look-up, and / or the plurality of paths (2520, 2521, 2522) are a plurality of packet data unit, PDU, sessions.

67. A method as claimed in any of claims 60 to 66, wherein: the network (2500) is a fifth-generation core, 5GC, network, and the tenth network node (2502) is a user plane function, UPF, node, or the network (2500) is an evolved packet core, EPC, network, and the tenth network node (2502) is a packet data network gateway, PGW.

68. A method for managing path selection in a network (2500), wherein the method is performed by an eleventh network node (2508) of the network (2500), the method comprising:• generating a border gateway protocol, BGP, update on the basis of which a path (2520) is to be selected, from a plurality of paths (2520, 2521, 2522), for routing a packet received at a tenth network node (2502), wherein: the eleventh network node (2508) is associated with a destination (2506) of the packet, the plurality of paths (2520, 2521, 2522) are between the tenth network node (2502) and the destination (2506) of the packet, the BGP update comprises information about the path (2520), and the packet belongs to a session associated with binding information according to claim 12.

69. A method as claimed in claim 68, wherein the information about the path (2520) comprises a path length of the path (2520).

70. A method as claimed in claim 69, wherein the path (2520) is to be selected based on the path length of the path (2520) being the shortest path length out of the path lengths of the plurality of paths (2520, 2521, 2522).

71. A method as claimed in any of claims 68 to 70, the method comprising:• providing the BGP update to the tenth network node (2502).

72. A method as claimed in any of claims 68 to 71 , wherein the plurality of paths(2520, 2521, 2522) are a plurality of packet data unit, PDU, sessions.

73. A method as claimed in any of claims 68 to 72, wherein: the network (2500) is a fifth-generation core, 5GC, network, and the tenth network node (2502) is a user plane function, UPF, node, or the network (2500) is an evolved packet core, EPC, network, and the tenth network node (2502) is a packet data network gateway, PGW.

74. A method performed by a system, the method comprising:• the method as claimed in any of claims 1 to 11 and the method as claimed in any of claims 12 to 24,• the method as claimed in any of claims 25 to 31 and the method as claimed in any of claims 32 to 39,• the method as claimed in any of claims 40 to 48 and the method as claimed in any of claims 49 to 59, and / or the method as claimed in any of claims 60 to 67 and the method as claimed in any of claims 68 to 73.

75. A first network node (10) comprising processing circuitry (12) configured to cause the first network node (10) to:• initiate transmission of a first message towards a second network node of the network, wherein the first message comprises binding information, wherein the binding information comprises information indicative of an internet protocol, IP, address of a first user equipment, UE, involved in a first session and information indicative of an IP address of a first application involved in the first session.

76. A first network node (10) as claimed in claim 75, wherein the processing circuitry (12) is configured to cause the first network node (10) to perform the method according to any of claims 2 to 11.

77. A second network node (10) comprising processing circuitry (12) configured to cause the second network node (10) to:• perform session binding in response to receiving a first message from a first network node of the network, wherein: the first message comprises binding information, the binding information comprises information indicative of an internet protocol, IP, address of a first user equipment, UE, involved in a first session and information indicative of an IP address of a first application involved in the first session, and session binding is performed by associating the binding information to the first session.

78. A second network node (10) as claimed in claim 77, wherein the processing circuitry (12) is configured to cause the second network node (10) to perform the method according to any of claims 13 to 24.

79. A third network node (10) comprising processing circuitry (12) configured to cause the third network node (10) to:• select, from a plurality of paths, a path via which to route a packet received at the third network node, wherein: the plurality of paths are between the third network node and a destination of the packet, and the path is selected based on one or more characteristics of the path meeting a policy comprising one or more path selection criteria.

80. A third network node (10) as claimed in claim 79, wherein the processing circuitry (12) is configured to cause the third network node (10) to perform the method according to any of claims 26 to 31.

81. A fourth network node (10) comprising processing circuitry (12) configured to cause the fourth network node (10) to:• set a policy comprising one or more path selection criteria on the basis of which a path is to be selected, from a plurality of paths, for routing a packet received at the fourth network node, wherein: the fourth network node is associated with an origin of the packet, the plurality of paths are between a third network node of the network and a destination of the packet, and the path is to be selected based on one or more characteristics of the path meeting the one or more path selection criteria.

82. A fourth network node (10) as claimed in claim 81 , wherein the processing circuitry (12) is configured to cause the fourth network node (10) to perform the method according to any of claims 33 to 39.

83. A sixth network node (10) comprising processing circuitry (12) configured to cause the sixth network node (10) to:• select, from a plurality of paths, a path via which to route a packet received at the sixth network node, wherein: the plurality of paths are between the sixth network node and a destination of the packet, and the path is selected based on a flow descriptor of the path matching a flow descriptor assigned to the packet.

84. A sixth network node (10) as claimed in claim 83, wherein the processing circuitry (12) is configured to cause the sixth network node (10) to perform the method according to any of claims 41 to 48.

85. A seventh network node (10) comprising processing circuitry (12) configured to cause the seventh network node (10) to:• assign, to a packet received at the seventh network node, a flow descriptor on the basis of which a path is to be selected, from a plurality of paths, for routing the packet, wherein: the seventh network node is associated with an origin of the packet, the plurality of paths are between a sixth network node of the network and a destination of the packet, and the path is to be selected is based on a flow descriptor of the path matching the flow descriptor assigned to the packet.

86. A seventh network node (10) as claimed in claim 85, wherein the processing circuitry (12) is configured to cause the seventh network node (10) to perform the method according to any of claims 50 to 59.

87. A tenth network node (10) comprising processing circuitry (12) configured to cause the tenth network node (10) to:• select, from a plurality of paths, a path via which to route a packet received at the tenth network node, wherein: the plurality of paths are between the tenth network node and a destination of the packet, and the path (2520) is selected based on a border gateway protocol, BGP, update comprising information about the path (2520).

88. A tenth network node (10) as claimed in claim 87, wherein the processing circuitry (12) is configured to cause the tenth network node (10) to perform the method according to any of claims 61 to 67.

89. An eleventh network node (10) comprising processing circuitry (12) configured to cause the eleventh network node (10) to:• generate a border gateway protocol, BGP, update based on which a path is to be selected, from a plurality of paths, for routing a packet received at a tenth network node, wherein: the eleventh network node is associated with a destination of the packet, the plurality of paths are between the tenth network node and the destination of the packet, and the BGP update comprises information about the path.

90. An eleventh network node (10) as claimed in claim 89, wherein the processing circuitry (12) is configured to cause the eleventh network node (10) to perform the method according to any of claims 69 to 73.

91. A system comprising: o the first network node as claimed in claim 75 or 76 and the second network node as claimed in claim 77 or 78, o the third network node as claimed in claim 79 or 80 and the fourth network node as claimed in claim 81 or 82, o the sixth network node as claimed in claim 83 or 84 and the seventh network node as claimed in claim 85 or 86, and / or o the tenth network node as claimed in claim 87 or 88 and the eleventh network node as claimed in claim 89 or 90.

92. A computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any of claims 1 to 11 , any of claims 12 to 24, any of claims 25 to 31 , any of claims 32 to 39, any of claims 40 to 48, any of claims 49 to 59, any of claims 60 to 67, and / or any of claims 68 to 73.

93. A computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method according to any of claims 1 to 11 , any of claims 12 to 24, any of claims 25 to 31 , any of claims 32 to 39, any of claims 40 to 48, any of claims 49 to 59, any of claims 60 to 67, and / or any of claims 68 to 73.

Images