WO2023148124A1

WO2023148124A1 - Session management for redundant pdu sessions

Info

Publication number: WO2023148124A1
Application number: PCT/EP2023/052152
Authority: WO
Inventors: Fuencisla Garcia Azorero; Maria Belen PANCORBO MARCOS; Susana Fernandez Alonso
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-02-02
Filing date: 2023-01-30
Publication date: 2023-08-10

Abstract

There is provided a method for managing sessions for providing a service to a wireless device in a network. The method is performed by an application function. The method comprises initiating transmission (202) of a first message towards a network exposure function. The first message comprises information for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

Description

SESSION MANAGEMENT FOR REDUNDANT PDU SESSIONS

Technical Field

The disclosure relates to methods for managing sessions for providing a service to a wireless device in a network and functions configured to operate in accordance with those methods.

Background

Figure 1 illustrates a third generation partnership project (3GPP) network architecture for the fifth generation (5G) of wireless mobile telecommunications technology.

The 5G network architecture of Figure 1 comprises a network slice selection function (NSSF), a network exposure function (NEF), a network repository function (NRF), a policy control function (PCF), a unified data management (UDM), a user data repository (UDR), and an application function (AF), each having a reference point, namely Nnssf, Nnef, Nnrf, Npcf, Nudm, Nudr, and Naf respectively. Herein, a reference point may also be referred to as an interface. The 5G network architecture of Figure 1 also comprises an authentication server function (AUSF), an access and mobility management function (AMF), and a session management function (SMF), each having a reference point, namely Nausf, Namf, and Nsmf.

The 5G network architecture of Figure 1 further comprises at least one user equipment (UE), an access network (AN) such as a radio access network (RAN), a user plane function (UPF), and a data network (DN). There is a reference point N1 between the AMF and the at least one UE, a reference point N2 between the AMF and the (R)AN, a reference point N3 between the (R)AN and the UPF, a reference point N4 between the SMF and the UPF, a reference point N6 between the UPF and the DN, and a reference point N9 between two UPFs.

Ensuring adequate support for services in a (e.g. telecommunications) network, such as that illustrated in Figure 1 , is an important consideration for operators of the network. Indeed, according to the 3GPP technical standard (TS) 23.501 , in order to support certain highly reliable services (e.g. ultra-reliable low-latency communication (URLLC) services), a UE may set up two redundant protocol data unit (PDU) sessions over the 5G network, such that the 5G system (5GS) sets up the user plane paths of the two redundant PDU sessions to be disjoint.

In order to establish two disjoint redundant PDU sessions, a UE route selection policy (URSP) is commonly used. In more detail, when a URSP is used to establish two redundant PDU sessions, duplicated traffic from an application, associated to the redundant PDU sessions, is differentiated by two distinct traffic descriptors, each in a distinct URSP rule. These traffic descriptors need to have different data network names (DNNs), internet protocol (IP) descriptors or non-IP descriptors (e.g. a media access control (MAC) address, or virtual local area network identifier (VLAN ID)), so that the two redundant PDU sessions are matched to route selection descriptors of distinct URSP rules. The route selection descriptors of distinct URSP rules may include corresponding retransmission sequence numbers (RSNs) and PDU session pair identifiers (IDs). The route selection descriptors share the same PDU session pair ID, if included, to denote that the two streams of duplicated traffic are redundant with respect to each other. The manner in which a UE can determine a PDU session pair ID and/or an RSN from matched URSP rules is described in clause 6.6.2 of 3GPP TS 23.503 V17.3.0.

If an operator decides to allow a UE to use its own mechanisms to determine a PDU session pair ID and an RSN (where such UE capability is known based on local PCF configuration based on, for example, deployment, terminal implementation, or policies per group of UE(s)), then the PCF does not include the PDU session pair ID and RSN in the URSP rule. The UE may include a PDU Session Pair ID and/or RSN in each PDU session establishment request when it establishes redundant PDU sessions. The UE can determine the PDU session pair ID and/or RSN based on a local mechanism at the UE or matched URSP rules.

Therefore, as described in 3GPP TS 23.501 V17.3.0, there currently exists a mechanism for a PCF to decide to send URSP rules to a UE, where the URSP rules indicate that redundant PDU sessions need to be established for a particular application identified by different traffic descriptors. The criteria for the PCF to decide if such redundant PDU sessions are required considers local PCF configuration based on, for example, deployment, terminal implementation, or policies per group of UE(s). This existing technique, and other similar techniques, used in handling traffic have several issues that can make it difficult to manage (e.g. PDU) sessions for the traffic in a network in an effective and efficient manner.

Summary

As mentioned earlier, it can be difficult to effectively and efficiently manage (e.g. protocol data unit, PDU) sessions for handling traffic in a network using existing techniques.

In particular, according to 3GPP TS 23.501 V17.3.0, it is the role of the policy control function (PCF) to decide if redundant sessions are required based on local PCF configuration (e.g. deployment, terminal implementation, or policies per group of UE(s)). Also, a UE route selection policy (URSP) is locally configured in the PCF. A URSP may alternatively be provisioned by a network exposure function (NEF) but, in this case, there is no mechanism defined to indicate traffic redundancy. Redundant sessions can be defined to satisfy highly reliable services (e.g. ultra-reliable low-latency communication (URLLC) services), where the 5G core (5GC) network needs to ensure that the service is satisfactorily executed. Thus, the needs of the application are critical for making a decision on whether to apply redundancy to a session to be established.

However, information indicative of the needs of the application are not currently taken into consideration by the PCF when making this decision and this can be problematic. For example, failing to consider this information can lead to non-redundant sessions being used for ultra-reliable services (which can result in missing redundant sessions that can put service usage at risk, e.g. leading to service failure), and/or redundant sessions being used for applications with no critical demands (which can result in unnecessary redundant sessions consuming resources).

An application function (AF) can provide the (e.g. 5GC) network with information on guidance for URSP determination. The guidance can consist of a list of rules. The rules may associate an application traffic descriptor with requested features for candidate sessions that the application traffic may use. This information can be provided by the AF to a network exposure function (NEF) and then to a user data repository (UDR). The PCF can retrieve the information from the UDR and generate URSP rules according to the information. However, there does not currently exist a means for the AF to indicate an interest for the (e.g. 5GC) network to apply redundancy to a session for handling of a specific service (e.g. with demands of high reliability). It may be the case that the AF provisions information to the network about how a user equipment (UE) is to route traffic and the AF may perform redundancy at application level. However, the network is not aware of the redundancy relationship between traffic (e.g. traffic flows) and so redundant traffic can end up being transmitted via non-redundant sessions (or even the same session).

It is thus an object of the disclosure to obviate or eliminate at least some of the abovedescribed disadvantages.

Therefore, according to an aspect of the disclosure, there is provided a first method for managing sessions for providing a service to a wireless device in a network. The first method is performed by an application function. The method comprises initiating transmission of a first message towards a network exposure function. The first message comprises information for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

According to another aspect of the disclosure, there is provided an application function configured to operate in accordance with the first method described earlier. In some embodiments, the application function may comprise processing circuitry configured to operate in accordance with the first method described earlier. In some embodiments, the application function may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the application function to operate in accordance with the first method described earlier.

According to another aspect of the disclosure, there is provided a second method for managing sessions for providing a service to a wireless device in a network. The second method is performed by a network exposure function. The second method comprises, in response to receiving a first message comprising information from an application function, initiating transmission of a second message comprising the information towards a user data repository for storage. The information is for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

According to another aspect of the disclosure, there is provided a network exposure function configured to operate in accordance with the second method described earlier. In some embodiments, the network exposure function may comprise processing circuitry configured to operate in accordance with the second method described earlier. In some embodiments, the network exposure function may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the network exposure function to operate in accordance with the second method described earlier.

According to another aspect of the disclosure, there is provided a third method for managing sessions for providing a service to a wireless device in a network. The third method is performed by a user data repository. The third method comprises, in response to receiving a second message comprising information from a network exposure function, storing the information. The information is for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

According to another aspect of the disclosure, there is provided a user data repository configured to operate in accordance with the third method described earlier. In some embodiments, the user data repository may comprise processing circuitry configured to operate in accordance with the third method described earlier. In some embodiments, the user data repository may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the user data repository to operate in accordance with the third method described earlier.

According to another aspect of the disclosure, there is provided a fourth method for managing sessions for providing a service to a wireless device in a network. The fourth method is performed by a policy control function. The fourth method comprises generating a set of rules for handling traffic associated with the service. The set of rules is generated based on information acquired from a user data repository. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

According to another aspect of the disclosure, there is provided a policy control function configured to operate in accordance with the fourth method described earlier. In some embodiments, the policy control function may comprise processing circuitry configured to operate in accordance with the fourth method described earlier. In some embodiments, the policy control function may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the policy control function to operate in accordance with the fourth method described earlier.

According to another aspect of the disclosure, there is provided a method performed by a system. The method performed by the system comprises any two or more of the first method described earlier, the second method described earlier, the third method described earlier, and the fourth method described earlier.

According to another aspect of the disclosure, there is provided a system comprising any two or more of the application function described earlier, the network exposure function described earlier, the user data repository described earlier, and the policy control function described earlier.

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 the first method described earlier, the second method described earlier, the third method described earlier, and/or the fourth method described earlier.

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 first method described earlier, the second method described earlier, the third method described earlier, and/or the fourth method described earlier.

Therefore, there are provided advantageous techniques for managing sessions for providing a service to a wireless device in a network. In particular, the advantageous techniques provide a mechanism that allows an application function to explicitly indicate (e.g. to the 5GC network) its needs for the handling of sessions for providing a service to a wireless device in the network. Such advantageous techniques can be particularly beneficial when managing sessions for providing a service that requires high (or ultra- high) reliability. Moreover, the advantageous techniques allow the PCF to have access to accurate and trustable information about the demands of the application function. As such, particular session requirements (e.g. redundancy) can be implemented only when needed. This allows for an optimal use of resources in the network, e.g. in the (radio) access network and/or the core network.

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:

Figure 1 is a block diagram illustrating an existing network architecture;

Figure 2 is a block diagram illustrating an application function according to an embodiment;

Figure 3 is a block diagram illustrating a method performed by the application function according to an embodiment;

Figure 4 is a block diagram illustrating a network exposure function according to an embodiment;

Figure 5 is a block diagram illustrating a method performed by the network exposure function according to an embodiment;

Figure 6 is a block diagram illustrating a user data repository according to an embodiment;

Figure 7 is a block diagram illustrating a method performed by the user data repository according to an embodiment; Figure 8 is a block diagram illustrating a policy control function according to an embodiment;

Figure 9 is a block diagram illustrating a method performed by the policy control function according to an embodiment;

Figure 10 is a schematic illustration of a system according to an embodiment; and

Figure 11 is a signalling diagram illustrating an exchange of signals in a system according to an embodiment.

Detailed Description

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.

As mentioned earlier, there is described herein advantageous techniques for managing sessions for providing a service to a wireless device in a network.

Examples of a wireless device 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. The wireless device as referred to herein may support device-to-device (D2D) communication, for example, by implementing a third generation partnership project (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. As yet another specific example, in an Internet of Things (loT) scenario, the wireless device as referred to herein may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another wireless device and/or a network node. The wireless device as referred to herein may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine type communication (MTC) device. As one particular example, the wireless device as referred to herein may be a user equipment (UE), e.g. implementing the 3GPP narrow band internet of things (NB-loT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc), personal wearables (e.g. watches, fitness trackers, etc). In other scenarios, the wireless device as referred to herein may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. The wireless device as referred to herein may represent the endpoint of a wireless connection, in which case the wireless device as referred to herein may be referred to as a wireless terminal. Furthermore, the wireless device as referred to herein may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

The network referred to herein can be any type of network. For example, the network referred to herein can be a telecommunications network. In some embodiments, the network referred to herein can be a mobile network, such as 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 be a radio access network (RAN). In some embodiments, the network referred to herein can be a local network, such as a local area network (LAN). In some embodiments, the network referred to herein may be a content delivery network (CDN). In some embodiments, the network referred to herein may be a software defined network (SDN). In some embodiments, the network referred to herein can be a fog computing environment or an edge computing 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. The advantageous techniques described herein can be implemented by an application function (AF), a network exposure function (NEF), a user data repository (UDR), and/or a policy control function (PCF).

Figure 2 illustrates an application function (AF) 10 in accordance with an embodiment. The application function 10 is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the application function 10 referred to herein can refer to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with the network exposure function referred to herein, and/or with other nodes or equipment to enable and/or to perform the functionality described herein. The application function 10 referred to herein may be a node. For example, in some embodiments, the application function 10 may be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM). Thus, the application function 10 referred to herein may also be referred to as an application function node.

As illustrated in Figure 2, the application function 10 comprises processing circuitry (or logic) 12. The processing circuitry 12 controls the operation of the application function 10 and can implement the method described herein in respect of the application function 10. The processing circuitry 12 can be configured or programmed to control the application function 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 the application function 10. In some embodiments, the processing circuitry 12 can be configured to run software to perform the method described herein in respect of the application function 10. 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 the application function 10.

Briefly, the processing circuitry 12 of the application function 10 is configured to initiate transmission of a first message towards a network exposure function. The first message comprises information for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service.

The secondary traffic is a replica of the primary traffic.

As illustrated in Figure 2, in some embodiments, the application function 10 may optionally comprise a memory 14. The memory 14 of the application function 10 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 14 of the application function 10 may comprise a non-transitory media. Examples of the memory 14 of the application function 10 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.

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

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

Although the application function 10 is illustrated in Figure 2 as comprising a single memory 14, it will be appreciated that the application function 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 application function 10 is illustrated in Figure 2 as comprising a single communications interface 16, it will be appreciated that the application function 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 2 only shows the components required to illustrate an embodiment of the application function 10 and, in practical implementations, the application function 10 may comprise additional or alternative components to those shown.

Figure 3 illustrates a method performed by an application function in accordance with an embodiment. The method is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the application function 10 described earlier with reference to Figure 2 can be configured to operate in accordance with the method of Figure 3. For example, the method can be performed by or under the control of the processing circuitry 12 of the application function 10.

With reference to Figure 3, at block 202, transmission of a first message is initiated towards a network exposure function. More specifically, the application function 10 (e.g. the processing circuitry 12 of the application function 10) initiates transmission of the first message towards the network exposure function (e.g. via the communications interface 16 of the application function 10) according to some embodiments. Herein, the term “initiate” can mean, for example, cause or establish. Thus, the application function 10 (e.g. the processing circuitry 12 of the application function 10) can be configured to itself transmit the first message (e.g. via the communications interface 16 of the application function 10) or can be configured to cause another node to transmit the first message. The first message comprises information for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica (e.g. duplicate) of the primary traffic. Herein, the term “handling” can mean transmitting and/or receiving.

Herein, the primary session can be a primary session between the wireless device and another node of the network. For example, the primary session can be a primary session between the wireless device and a data network where the application function 10 resides, such as via a control plane (or, more specifically, a control plane function, e.g. an access and mobility management function, AMF) of the network. In some embodiments, the primary session can be a primary session between the wireless device and the application function 10. Similarly, herein, the secondary session can be a secondary session between the wireless device and another or the same data network. For example, the secondary session can be a secondary session between the wireless device and the data network where the application function 10 resides, such as via the control plane (or, more specifically, a control plane function, e.g. an AMF) of the network.. In some embodiments, the secondary session can be a secondary session between the wireless device and the application function 10.

As the secondary traffic is a replica of the primary traffic, the secondary traffic may also be referred to as redundant traffic. Similarly, the secondary session may also be referred to as a redundant session. For example, in some embodiments, the primary session can be the session that is primarily used for handling traffic associated with the service and the secondary session can be the session that is used for handling traffic associated with the service if the primary session is unable to handle traffic associated with the service. In this way, there is a back-up for handling traffic associated with the service. Although the techniques herein are described in terms of a primary session and a secondary session, it will be understood that the techniques herein can also make use of any other number of sessions (e.g. three or more sessions) to provide even more redundant sessions for handling redundant traffic associated with the service. In some embodiments, the primary session referred to herein may be a new session or an updated version of an existing session. Alternatively or in addition, in some embodiments, the secondary session referred to herein may be a new session or an updated version of an existing session. In some embodiments, the primary session referred to herein can be a primary protocol data unit (PDU) session. Alternatively or in addition, in some embodiments, the secondary session can be a secondary PDU session. Thus, any reference to “session” herein can be understood to mean a PDU session according to some embodiments. Generally, a PDU session is a session that provides end-to-end user plane connectivity between the wireless device and a data network (DN), e.g. through a user plane function (UPF). In 3GPP TS 23.501 V17.3.0, a PDU session is defined as an association between the wireless device and a data network that provides a PDU connectivity service.

In some embodiments, the first message referred to herein may comprise one or more first parameters for the service. The one or more first parameters for the service can be one or more parameters that are associated with, or specific to, the service. The one or more first parameters for the service referred to herein can thus also be referred to as one or more service parameters or one or more service specific parameters. For example, the one or more service parameters can comprise any one or more of the service parameters referred to in 3GPP TS 29.522 V17.4.0, such as any one or more of the vehicle to everything (V2X) service parameters referred to therein, any one or more of the 5G proximity services (5G ProSe) service parameters referred to therein, any one or more UE route selection policy (URSP) service parameters referred to therein, and/or any one or more other service parameters.

In some embodiments, the first message referred to herein may comprise a request to create the one or more first parameters for the service or update one or more existing second parameters for the service with the one or more first parameters. For example, the request can be the “Nnef_ServiceParameter_Create” service operation request referred to in 3GPP TS 29.513 V17.5.0 or the “Nnef_ServiceParameter_Update” service operation request referred to in 3GPP TS 29.513 V17.5.0.

In some embodiments, the first message referred to herein may be a hypertext transfer protocol (HTTP) message. For example, the HTTP message may be a HTTP POST request, such as in embodiments where the request is to create one or more service parameters. In another example, the HTTP message may be a HTTP PUT request or a HTTP PATCH request, such as in embodiments where the request is to update one or more existing second parameters for the service with the one or more first parameters.

In some embodiments, the information referred to herein can be indicative that a first rule and a second rule is to be generated for the service. In these embodiments, the first rule referred to herein can be that the primary session is to be established (e.g. by the wireless device) for handling primary traffic associated with the service and the second rule referred to herein can be that the secondary session is to be established (e.g. by the wireless device) for handling secondary traffic associated with the service.

In some embodiments, the first message referred to herein may comprise an identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule. The identifier (ID) referred to herein may also be referred to as a Service Pair ID. The identifier referred to herein can be a value according to some embodiments. In some embodiments, the identifier referred to herein can be unique to the application function 10. In some embodiments, the identifier referred to herein can comprise a combination of two or more identifiers. For example, the identifier referred to herein may comprise a combination of an identifier that identifies the application function 10 (namely, an application function ID) and a sequence number allocated by the application function 10. In this way, the identifier referred to herein can be unique in the scope of an application function. In some embodiments, the identifier referred to herein may replace a previous identifier assigned to one or more previous rules generated for the service.

In some embodiments, the first message referred to herein may comprise a request for the information to overwrite previous information indicative of one or more sessions required for handling traffic associated with the service.

In some embodiments, the set of rules referred to herein for handling traffic associated with the service can be a set of rules for selecting a session for routing traffic associated with the service. Thus, in some embodiments, the set of rules referred to herein can also be referred to as a set of route selection policy (RSP) rules. In embodiments where the wireless device is a user equipment (UE), the set of rules can be referred to as a set of UE route selection policy (URSP) rules. In some embodiments, the service referred to herein can be a reliable or ultra-reliable service, such as an ultra-reliable low-latency communication (LIRLLC) service, or any other type of service. Generally, a LIRLLC service is a service having a target reliability of 99.999% and a target latency of 1 millisecond. Examples of a LIRLLC service include, but are not limited to, a service associated with any one or more of public safety, remote diagnosis or surgery, an emergency response, autonomous driving, industrial automation, smart energy and the grid, and/or similar.

Figure 4 illustrates a network exposure function (NEF) 20 in accordance with an embodiment. The network exposure function 20 is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the network exposure function 20 referred to herein can refer to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with the application function 10 referred to herein, with the user data repository referred to herein, and/or with other nodes or equipment to enable and/or to perform the functionality described herein. The network exposure function 20 referred to herein may be a node. For example, in some embodiments, the application function 10 may be a physical node (e.g. a physical machine) or a virtual node (e.g. a virtual machine, VM). Thus, the network exposure function 20 referred to herein may also be referred to as a network exposure function node.

As illustrated in Figure 4, the network exposure function 20 comprises processing circuitry (or logic) 22. The processing circuitry 22 controls the operation of the network exposure function 20 and can implement the method described herein in respect of the network exposure function 20. The processing circuitry 22 can be configured or programmed to control the network exposure function 20 in the manner described herein. The processing circuitry 22 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 the network exposure function 20. In some embodiments, the processing circuitry 22 can be configured to run software to perform the method described herein in respect of the network exposure function 20. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 22 may be configured to run a container to perform the method described herein in respect of the network exposure function 20.

Briefly, the processing circuitry 22 of the network exposure function 20 is configured to, in response to receiving a first message comprising information from an application function 10, initiate transmission of a second message comprising the information towards a user data repository for storage. The information is for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

As illustrated in Figure 4, in some embodiments, the network exposure function 20 may optionally comprise a memory 24. The memory 24 of the network exposure function 20 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 24 of the network exposure function 20 may comprise a non-transitory media. Examples of the memory 24 of the network exposure function 20 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.

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

In some embodiments, as illustrated in Figure 4, the network exposure function 20 may optionally comprise a communications interface 26. The communications interface 26 of the network exposure function 20 can be communicatively coupled (e.g. connected) to the processing circuitry 22 of the network exposure function 20 and/or the memory 24 of the network exposure function 20. The communications interface 26 of the network exposure function 20 may be operable to allow the processing circuitry 22 of the network exposure function 20 to communicate with the memory 24 of the network exposure function 20 and/or vice versa. Similarly, the communications interface 26 of the network exposure function 20 may be operable to allow the processing circuitry 22 of the network exposure function 20 to communicate with any one or more nodes (e.g. the application function 10) referred to herein. The communications interface 26 of the network exposure function 20 can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 22 of the network exposure function 20 may be configured to control the communications interface 26 of the network exposure function 20 to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the network exposure function 20 is illustrated in Figure 4 as comprising a single memory 24, it will be appreciated that the network exposure function 20 may comprise at least one memory (i.e. a single memory or a plurality of memories) 24 that operate in the manner described herein. Similarly, although the network exposure function 20 is illustrated in Figure 4 as comprising a single communications interface 26, it will be appreciated that the network exposure function 20 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 26 that operate in the manner described herein. It will also be appreciated that Figure 4 only shows the components required to illustrate an embodiment of the network exposure function 20 and, in practical implementations, the network exposure function 20 may comprise additional or alternative components to those shown. Figure 5 illustrates a method performed by a network exposure function in accordance with an embodiment. The method is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the network exposure function 20 described earlier with reference to Figure 4 can be configured to operate in accordance with the method of Figure 5. For example, the method can be performed by or under the control of the processing circuitry 22 of the network exposure function 20.

With reference to Figure 5, at block 302, in response to receiving a first message comprising information from an application function 10, transmission of a second message comprising the information is initiated towards a user data repository for storage. More specifically, the network exposure function 20 (e.g. the processing circuitry 22 of the network exposure function 20) initiates transmission of the second message towards the user data repository (e.g. via the communications interface 26 of the network exposure function 20) according to some embodiments. For example, the network exposure function 20 (e.g. the processing circuitry 22 of the network exposure function 20) can be configured to itself transmit the second message (e.g. via the communications interface 26 of the network exposure function 20) or can be configured to cause another node to transmit the second message. In some embodiments, the network exposure function 20 (e.g. the processing circuitry 22 of the network exposure function 20) may be configured to receive the first message from the application function 10 (e.g. via the communications interface 26 of the network exposure function 20). Thus, although not illustrated in Figure 5, in some embodiments, the method may comprise receiving the first message from the application function 10. The information that the first and second messages comprise is for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

In some embodiments, the second message referred to herein may comprise the one or more first parameters for the service. The one or more first parameters can be as described earlier. In some embodiments, the second message referred to herein may comprise a request to create the one or more first parameters for the service or update one or more existing second parameters for the service with the one or more first parameters. For example, the request can be the “Nudr_DataRepository_Create” service operation request referred to in 3GPP TS 29.513 V17.5.0 or the “Nudr_DataRepository_Update” service operation request referred to in 3GPP TS 29.513 V17.5.0. In some embodiments, the second message can be a HTTP message, such as any of those (e.g. the HTTP POST request, HTTP PUT request, or HTTP PATCH request) described earlier in relation to the first message.

In some embodiments, the second message referred to herein may comprise the identifier (Service Pair ID) assigned to the first rule and the second rule for use in identifying the first rule and the second rule. The identifier can be as described earlier. In some embodiments, the second message referred to herein may comprise a request for the information to overwrite previous information indicative of one or more sessions required for handling traffic associated with the service.

Figure 6 illustrates a user data repository (UDR) 30 in accordance with an embodiment. The user data repository 30 is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the user data repository 30 referred to herein can refer to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with the network exposure function 20 referred to herein, with the policy control function referred to herein, and/or with other nodes or equipment to enable and/or to perform the functionality described herein. The user data repository 30 referred to herein may be a node. For example, in some embodiments, the user data repository 30 may be a physical node (e.g. a physical machine) or a virtual node (e.g. a virtual machine, VM). Thus, the user data repository 30 referred to herein may also be referred to as a user data repository node.

As illustrated in Figure 6, the user data repository 30 comprises processing circuitry (or logic) 32. The processing circuitry 32 controls the operation of the user data repository 30 and can implement the method described herein in respect of the user data repository 30. The processing circuitry 32 can be configured or programmed to control the user data repository 30 in the manner described herein. The processing circuitry 32 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 the user data repository 30. In some embodiments, the processing circuitry 32 can be configured to run software to perform the method described herein in respect of the user data repository 30. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 32 may be configured to run a container to perform the method described herein in respect of the user data repository 30.

Briefly, the processing circuitry 32 of the user data repository 30 is configured to, in response to receiving a second message comprising information from a network exposure function 20, store the information. The information is for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

As illustrated in Figure 6, in some embodiments, the user data repository 30 may optionally comprise a memory 34. The memory 34 of the user data repository 30 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 34 of the user data repository 30 may comprise a non-transitory media. Examples of the memory 34 of the user data repository 30 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.

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

In some embodiments, as illustrated in Figure 6, the user data repository 30 may optionally comprise a communications interface 36. The communications interface 36 of the user data repository 30 can be communicatively coupled (e.g. connected) to the processing circuitry 32 of the user data repository 30 and/or the memory 34 of the user data repository 30. The communications interface 36 of the user data repository 30 may be operable to allow the processing circuitry 32 of the user data repository 30 to communicate with the memory 34 of the user data repository 30 and/or vice versa. Similarly, the communications interface 36 of the user data repository 30 may be operable to allow the processing circuitry 32 of the user data repository 30 to communicate with any one or more of the nodes (e.g. the network exposure function 20 and/or the policy control function) referred to herein. The communications interface 36 of the user data repository 30 can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 32 of the user data repository 30 may be configured to control the communications interface 36 of the user data repository 30 to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the user data repository 30 is illustrated in Figure 6 as comprising a single memory 34, it will be appreciated that the user data repository 30 may comprise at least one memory (i.e. a single memory or a plurality of memories) 34 that operate in the manner described herein. Similarly, although the user data repository 30 is illustrated in Figure 6 as comprising a single communications interface 36, it will be appreciated that the user data repository 30 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 36 that operate in the manner described herein. It will also be appreciated that Figure 6 only shows the components required to illustrate an embodiment of the user data repository 30 and, in practical implementations, the user data repository 30 may comprise additional or alternative components to those shown.

Figure 7 illustrates a method performed by a user data repository in accordance with an embodiment. The method is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the user data repository 30 described earlier with reference to Figure 6 can be configured to operate in accordance with the method of Figure 7. For example, the method can be performed by or under the control of the processing circuitry 32 of the user data repository 30.

With reference to Figure 7, at block 402, in response to receiving a second message comprising information from a network exposure function 20, the information is stored. More specifically, the user data repository 30 (e.g. the processing circuitry 32 of the user data repository 30) stores the information in response to receiving the second message according to some embodiments. For example, the information may be stored in the memory 34 of the user data repository 30. In some embodiments, the user data repository 30 (e.g. the processing circuitry 32 of the user data repository 30) may be configured to receive the second message from the network exposure function 20 (e.g. via the communications interface 36 of the user data repository 30). Thus, although not illustrated in Figure 7, in some embodiments, the method may comprise receiving the second message from the network exposure function 20. The information that the second message comprises is for use by a policy control function in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

In embodiments where the second message comprises a request to create the one or more earlier described first parameters for the service, although not illustrated in Figure 7, the one or more first parameters may be stored. More specifically, the user data repository 30 (e.g. the processing circuitry 32 of the user data repository 30) may be configured to store the one or more first parameters (e.g. in the memory 34 of the user data repository 30) according to some embodiments. In embodiments where the second message comprises a request to update one or more existing second parameters for the service with the one or more earlier described first parameters for the service, although not illustrated in Figure 7, the one or more existing second parameters updated with the one or more first parameters may be stored. More specifically, the user data repository 30 (e.g. the processing circuitry 32 of the user data repository 30) may be configured to store the one or more existing second parameters updated with the one or more first parameters (e.g. in the memory 34 of the user data repository 30) according to some embodiments. In embodiments where the second message comprises the earlier described identifier assigned to the first rule and the second rule, although not illustrated in Figure 7, the identifier may be stored with the information. More specifically, the user data repository 30 (e.g. the processing circuitry 32 of the user data repository 30) may be configured to store the identifier with the information (e.g. in the memory 34 of the user data repository 30) according to some embodiments.

In embodiments where the second message comprises a request for the information to overwrite previous information indicative of one or more sessions required for handling traffic associated with the service, storing the information may comprise overwriting the previous information with the information. More specifically, the user data repository 30 (e.g. the processing circuitry 32 of the user data repository 30) may be configured to overwrite the previous information with the information according to some embodiments.

Figure 8 illustrates a policy control function (PCF) 40 in accordance with an embodiment. The policy control function 40 is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the policy control function 40 referred to herein can refer to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with the user data repository 30 referred to herein, the access mobile function (AMF) referred to herein, and/or with other nodes or equipment to enable and/or to perform the functionality described herein. The policy control function 40 referred to herein may be a node. For example, in some embodiments, the policy control function 40 may be a physical node (e.g. a physical machine) or a virtual node (e.g. a virtual machine, VM). Thus, the policy control function 40 referred to herein may also be referred to as a policy control function node.

As illustrated in Figure 8, the policy control function 40 comprises processing circuitry (or logic) 42. The processing circuitry 42 controls the operation of the policy control function 40 and can implement the method described herein in respect of the policy control function 40. The processing circuitry 42 can be configured or programmed to control the policy control function 40 in the manner described herein. The processing circuitry 42 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 the policy control function 40. In some embodiments, the processing circuitry 42 can be configured to run software to perform the method described herein in respect of the policy control function 40. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 42 may be configured to run a container to perform the method described herein in respect of the policy control function 40.

Briefly, the processing circuitry 42 of the policy control function 40 is configured to generate a set of rules for handling traffic associated with the service. The set of rules is generated based on information acquired from a user data repository 30. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

As illustrated in Figure 8, in some embodiments, the policy control function 40 may optionally comprise a memory 44. The memory 44 of the policy control function 40 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 44 of the policy control function 40 may comprise a non-transitory media. Examples of the memory 44 of the policy control function 40 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.

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

In some embodiments, as illustrated in Figure 8, the policy control function 40 may optionally comprise a communications interface 46. The communications interface 46 of the policy control function 40 can be communicatively coupled (e.g. connected) to the processing circuitry 42 of the policy control function 40 and/or the memory 44 of the policy control function 40. The communications interface 46 of the policy control function 40 may be operable to allow the processing circuitry 42 of the policy control function 40 to communicate with the memory 44 of the policy control function 40 and/or vice versa. Similarly, the communications interface 46 of the policy control function 40 may be operable to allow the processing circuitry 42 of the policy control function 40 to communicate with any one or more nodes (e.g. any one or more of the user data repository 30 and the access mobile function) referred to herein. The communications interface 46 of the policy control function 40 can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 42 of the policy control function 40 may be configured to control the communications interface 46 of the policy control function 40 to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the policy control function 40 is illustrated in Figure 8 as comprising a single memory 44, it will be appreciated that the policy control function 40 may comprise at least one memory (i.e. a single memory or a plurality of memories) 44 that operate in the manner described herein. Similarly, although the policy control function 40 is illustrated in Figure 8 as comprising a single communications interface 46, it will be appreciated that the policy control function 40 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 46 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 policy control function 40 and, in practical implementations, the policy control function 40 may comprise additional or alternative components to those shown.

Figure 9 illustrates a method performed by a policy control function in accordance with an embodiment. The method is for managing sessions for providing a service to a wireless device in a network. In some embodiments, the policy control function 40 described earlier with reference to Figure 8 can be configured to operate in accordance with the method of Figure 9. For example, the method can be performed by or under the control of the processing circuitry 42 of the policy control function 40.

With reference to Figure 9, at block 502, a set of rules is generated for handling traffic associated with the service. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) generates the set of rules according to some embodiments. The set of rules is generated based on information acquired from a user data repository 30. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic.

In embodiments where the information is indicative that a first rule and a second rule is to be generated for the service, generating the set of rules may comprise generating the first rule and the second rule. As mentioned earlier, in these embodiments, the first rule can be that the primary session is to be established for handling primary traffic associated with the service and the second rule can be that the secondary session is to be established for handling secondary traffic associated with the service.

Although not illustrated in Figure 9, in some embodiments, the method may comprise assigning a first traffic descriptor and a first session descriptor to the first rule. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to assign the first traffic descriptor and the first session descriptor according to some embodiments. The first traffic descriptor can identify the primary traffic and the first session descriptor can identify the primary session. Alternatively or in addition, in some embodiments, the method may comprise assigning a second traffic descriptor and a second session descriptor to the second rule. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to assign the second traffic descriptor and the second session descriptor according to some embodiments. The second traffic descriptor can identify the secondary traffic and the second session descriptor can identify the secondary session. In some embodiments, any one or more of the descriptors referred to herein can be a value. Although not illustrated in Figure 9, in some embodiments, the method may comprise acquiring the information from the user data repository 30. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to acquire the information according to some embodiments. In some of these embodiments, acquiring the information from the user data repository 30 may comprise receiving a third message from the user data repository 30. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to receive the third message (e.g. via the communications interface 46 of the policy control function 40) according to some embodiments. In these embodiments, the third message comprises the information. In some embodiments, in order for the policy control function 40 to receive the third message, the policy control function 40 may have previously subscribed in the user data repository 30 to receive it. In other embodiments, acquiring the information from the user data repository 30 may comprise remotely accessing the information at the user data repository 30. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to remotely access the information (e.g. via the communications interface 46 of the policy control function 40) according to some embodiments. In some embodiments, the policy control function 40 may always retrieve the information from the user data repository 30, e.g. as part of wireless device policy establishment procedure. In some embodiments, the policy control function 40 may receive the information by being notified of the information by the user data repository 30, e.g. as part of wireless device policy modification. In some embodiments, the policy control function 40 can be subscribed to be notified of updates to the information stored at the user data repository 30.

Although not illustrated in Figure 9, in some embodiments, the method may comprise acquiring, from the user data repository 30, the earlier described identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to acquire the identifier (e.g. via the communications interface 46 of the policy control function 40) according to some embodiments. In some of these embodiments, acquiring the identifier from the user data repository 30 may comprise receiving, from the user data repository 30, the earlier described third message (or another message) comprising the identifier. In other embodiments, acquiring the identifier from the user data repository 30 may comprise remotely accessing the identifier at the user data repository 30. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to remotely access the identifier (e.g. via the communications interface 46 of the policy control function 40) according to some embodiments. In some embodiments, the policy control function 40 can be subscribed to be notified of updates to the identifier stored at the user data repository 30.

Although not illustrated in Figure 9, in some embodiments, the method may comprise initiating transmission of the set of rules towards the wireless device for the wireless device to handle traffic associated with the service according to the set of rules. More specifically, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can initiate transmission of the set of rules towards the wireless device (e.g. via the communications interface 46 of the policy control function 40) according to some embodiments. For example, the policy control function 40 (e.g. the processing circuitry 42 of the policy control function 40) can be configured to itself transmit the set of rules (e.g. via the communications interface 46 of the policy control function 40) or can be configured to cause another node to transmit the set of rules.

Therefore, in the manner described, the application function 10 can inform the network about the requirements needed to provide the service to the wireless device. Specifically, the application function 10 can inform the network of the traffic (e.g. traffic flows) that is to be treated redundantly (due to being replicated) and the network is able to handle that traffic appropriately. In more detail, the transfer of the information described herein from the application function 10 to the policy control function 40 allows for the generation of a more appropriate and effective set of rules by the policy control function 40. The network is able to handle redundant traffic (e.g. traffic flows) appropriately through redundant sessions. For example, two lots of traffic (e.g. two traffic flows) with the same service pair ID can be transmitted through two redundant sessions. In some embodiments, the two redundant sessions can have (and thus can be identified by) the same session pair ID and may optionally also have (and can thus be distinguished from each other by) a different retransmission sequence number (RSN). However, it is noted that this means of session identification is only one example, and different session identification strategies may be used.

In order to indicate that each distinct (e.g. RSP or LIRSP) rule represents traffic that needs to be handled within redundant (e.g. and not only separate) sessions, each rule can be assigned an identifier. In an example, the identifier assigned to each rule can be a combination of a session pair ID and an RSN. The session pair ID referred to herein can be a value according to some embodiments. The session pair ID can identify a pair of sessions. In other words, the session pair ID can identify both the primary session and the secondary session referred to herein. The RSN can identify the session within the pair of sessions. In other words, the RSN can identify either the primary session or the secondary session referred to herein. For example, for purposes of illustration, the policy control function 40 may determine that the wireless device has four PDU sessions (PDU Session 1 , PDU Session 2, PDU Session 3, and PDU Session 4) with redundancy and each of those PDU sessions can be assigned an identifier in the following manner:

PDU Session 1 with PDU Session pair I D=1 , RSN=1

PDU Session 2 with PDU Session pair I D=1 , RSN=2 PDU Session 3 with PDU Session pair I D=2, RSN=1 PDU Session 4 with PDU Session pair I D=2, RSN=2

In this example, the policy control function 40 generates four rules, one for each of the sessions identified above. Thus, the wireless device can be provided with these four rules. It may be locally configured in the policy control function 40 whether or not a service requires redundancy and thus which (e.g. application) traffic is to be delivered in each session. However, advantageously, the application function 10 described herein can indicate whether the service requires redundancy. Additionally, in some embodiments, the application function 10 may indicate the traffic (associated with the service) that is to be paired, e.g. using the service pair ID referred to herein. In embodiments involving a service pair ID and a session pair ID, the service pair ID may be different from the session pair ID, since the policy control function 40 determines the session pair ID (e.g. based on a whole set of services that require redundancy).

Following on from the above example, when the policy control function 40 is generating the set of rules for handling traffic associated with a service, the policy control function 40 can determine if the traffic of the redundant session is going to be included in existing PDU session pairs (e.g. the traffic may be delivered in PDU session pair ID 2, RSN 1 and 2 respectively), or if a new PDU session pair ID is to be allocated (e.g. PDU session pair ID=4).

There is further provided a method performed by a system. The method performed by the system comprises the method described herein with respect to any two or more of the application function 10 described herein, the network exposure function 20 described herein, the user data repository 30 described herein, and the policy control function 40 described herein. There is also provided a system comprising any two or more of the application function 10 described herein, the network exposure function 20 described herein, the user data repository 30 described herein, and the policy control function 40 described herein.

Figure 10 illustrates an example system according to an embodiment. The system is for managing sessions for providing a service to a wireless device 60 in a network.

As illustrated in Figure 10, the system comprises the wireless device 60 (such as a user equipment) and a network node, such as a node of a data network, e.g. an application function 10 (e.g. a server). The application function 10 can be as described earlier. As illustrated in Figure 10, in order to provide the service to the wireless device 60, a primary session 602 is required for handling primary traffic 604 associated with the service and a secondary session 606 is required for handling secondary traffic 608 associated with the service. For the purpose of illustration, the traffic to be handled comprises a plurality of frames that flow in a predefined order (“16”, “15”, “14”). The secondary traffic 608 is a replica (e.g. a duplicate) of the primary traffic 604. As illustrated in Figure 10, it may be that an application running on the wireless device 60 replicates the primary traffic 604. For example, as illustrated in Figure 10, in some embodiments, the application running on the wireless device 60 may comprise an element for replicating traffic. The secondary traffic 608 can be referred to herein as redundant traffic. Similarly, the secondary session 606 can be referred to herein as a redundant session.

In the manner described herein, the application function 10 provides information to the network that is indicative that the primary session 602 is required for handling primary traffic 604 associated with the service and the secondary session 606 is required for handling secondary traffic 608 associated with the service. The policy control function 40 (which is not illustrated in Figure 10) can thus access this information and, in the manner described herein, use the information in generating a set of rules (e.g. RSP or LIRSP rules) for handling the traffic associated with the service. For example, the information can be indicative that a first rule and a second rule is to be generated for the service, where the first rule is that the primary session 602 is to be established for handling primary traffic 604 associated with the service and the second rule is that the secondary session 606 is to be established for handling secondary traffic 608 associated with the service. Thus, the policy control function 40 may generate first and second rules accordingly. The set of rules can be provided to the wireless device 60 by the policy control function 40.

The wireless device 60 can handle traffic associated with the service according to the set of rules. Thus, as illustrated in Figure 10, the wireless device 60 may establish the primary session 602 between itself and the application function 10 for handling primary traffic 604, and the wireless device 60 may also establish the secondary session 606 between itself and the application function 10 for handling secondary traffic 608. As illustrated in Figure 10, the primary session 602 and the secondary session 606 form two disjoint paths for handing traffic.

As also illustrated in Figure 10, the wireless device 60 can assign (e.g. match) the primary traffic 604 to the primary session 602 and can assign (e.g. match) the secondary traffic 608 (i.e. the replica of the primary traffic) to the secondary session 606 according to the set of rules. In some embodiments, for a service that requires redundancy, distinct traffic descriptors may be used, such as a distinct traffic descriptor for the primary traffic 604 and another distinct traffic descriptor for the secondary traffic 608. Thus, the primary traffic 604 and the secondary traffic 608 can be differentiated. If, as illustrated in Figure 10, both the primary traffic 604 and the secondary traffic 608 ends up at the same application function 10, the application function 10 may be configured to eliminate the secondary traffic 608. For example, as illustrated in Figure 10, in some embodiments, the application function 10 may comprise an element for eliminating replica traffic.

Figure 11 is a signalling diagram illustrating an exchange of signals in a system according to an embodiment. The system illustrated in Figure 11 comprises an application function (AF) 10, a network exposure function (NEF) 20, a user data repository (UDR) 30, a policy control function (PCF) 40, and an access and mobility management function (AMF) 50. The AF 10 can be as described earlier with reference to Figures 2 and 3, the NEF 20 can be as described earlier with reference to Figures 4 and 5, the UDR 30 can be as described earlier with reference to Figures 6 and 7, and the PCT 40 can be as described earlier with reference to Figures 8 and 9. Although not illustrated in Figure 11 , the system may also comprise a wireless device (e.g. UE). The system illustrated in Figure 11 is for managing (e.g. PDU) sessions for providing a service to a wireless device (e.g. UE). As illustrated by arrow 700 of Figure 11 , the AF 10 initiates transmission of a first message towards the NEF 20. The procedure illustrated in Figure 11 is related to AF requests to provide AF-based service parameter provisioning as defined in 3GPP TS 29.513 V17.5.0. Thus, the first message may comprise a request to create one or more first parameters for the service, such as a “Nnef_ServiceParameter_Create” service operation request. Alternatively, the first message may comprise a request to update one or more existing second parameters for the service with the one or more first parameters for the service, such as a “Nnef_ServiceParameter_Update” service operation request. The one or more first parameters for the service can be as described earlier and may also be referred to as one or more service specific parameters.

In more detail according to a first example, with reference to arrow 700 of Figure 11 , in order to provide one or more service specific parameters (e.g. for RSP/URSP influence, V2X, or 5G ProSe) to a wireless devices (or a group of wireless devices), the AF 10 may invoke the ”Nnef_ServiceParameter_Create” service operation to the NEF 20. The AF 10 may invoke the operation to the NEF 20 by sending the first message as a HTTP POST request. The first message may be sent to a service parameter subscriptions resource at the NEF 20.

The first message comprises information for use by the PCF 40 in generating a set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic. As mentioned earlier, as the secondary traffic is a replica of the primary traffic, the secondary traffic can be referred to as redundant traffic and the secondary session can be referred to as a redundant session. Thus, the AF 10 can provide redundancy requirements, e.g. as part of the service specific parameters, in order to request the handling of redundant (e.g. PDU) sessions for the service. In this way, the AF 10 can influence the generation of the set of rules for handling traffic associated with the service.

The information for use by the PCF 40 in generating the set of rules can be indicative that a first rule and a second rule is to be generated for the service. The first rule can be that the primary session is to be established for handling primary traffic associated with the service and the second rule can be that the secondary session is to be established for handling secondary traffic associated with the service. Therefore, the AF 10 can provide separate guidance for the generation of at least two rules that can imply the establishment of at least two sessions for handling traffic. For example, in embodiments where the wireless device is a UE, the at least two rules can be at least two URSP rules. In some embodiments, the two rules can imply the establishment of two redundant sessions.

In some embodiments, the first message may comprise an identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule. The identifier can be included in the service specific parameters. The identifier is referred to herein as the service pair ID. The service pair ID is provided for the generation of each rule of the set of rules and allows the identification of the rule related to each (e.g. redundant) session. For example, the service pair ID can allow the identification of the first rule and the second rule in relation to the primary session and the secondary session respectively.

In more detail according to a second example, in order to update one or more existing service specific parameters, the AF 10 may invoke the “Nnef_ServiceParameter_Update” service operation to the NEF 20. The AF 10 may invoke the operation to the NEF 20 by sending the first message as a HTTP PUT request or a HTTP PATCH request. The first message may be sent to a service parameter subscriptions resource at the NEF 20.

The first message comprises information for use by the PCF 40 in generating a new set of rules for handling traffic associated with the service. The information is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The secondary traffic is a replica of the primary traffic. As mentioned earlier, as the secondary traffic is a replica of the primary traffic, the secondary traffic can be referred to as redundant traffic and the secondary session can be referred to as a redundant session. The primary session can be a new session or an updated version of an existing session, and/or the secondary session can be a new session or an updated version of an existing session. Therefore, the AF 10 can provide new/updated redundancy requirements, e.g. as part of the service specific parameters, in order to request the handling of new redundant (e.g. PDU) sessions for the service or for the modification of existing redundant (e.g. PDU) sessions for the service. In this way, the AF 10 can influence the generation of the new set of rules for handling traffic associated with the service.

The information for use by the PCF 40 in generating the new set of rules can be indicative that a first rule and a second rule is to be generated for the service. The first rule can be that the primary session is to be established for handling primary traffic associated with the service and the second rule can be that the secondary session is to be established for handling secondary traffic associated with the service. Therefore, the AF 10 can provide separately new guidance for the generation of at least two new rules that can imply the establishment of at least two new sessions for handling traffic. For example, in embodiments where the wireless device is a UE, the at least two new rules can be at least two new URSP rules. In some embodiments, the two new rules can imply the establishment of two new redundant sessions.

In some embodiments, the first message may comprise a new identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule. The identifier can be included in the service specific parameters. The identifier is referred to herein as the service pair ID. The service pair ID is provided for the generation of each rule of the new set of rules and allows the identification of the rule related to each (e.g. redundant) session. For example, the service pair ID can allow the identification of the first rule and the second rule in relation to the primary session and the secondary session respectively.

In some embodiments, the AF 10 may request the removal of a redundancy requirement for a service. In such a scenario, the AF 10 may remove the earlier described information related to the primary session and the secondary session from the remaining service specific parameters. In some embodiments, the AF 10 may request the removal of a redundancy requirement by sending a HTTP PUT request or a HTTP PATCH request to the NEF 20. The HTTP PUT request or the HTTP PATCH request may be sent to an individual service parameter subscription resource at the NEF 20. The AF 10 may also remove the previously assigned service pair ID from the remaining service specific parameters. In some embodiments, to (e.g. completely) remove existing service specific parameters, the AF 10 may invoke a “Nnef_ServiceParameter_Delete” service operation to the NEF 20. The “Nnef_ServiceParameter_Delete” service operation may not delete the redundancy requirement for the service. For this, the HTTP PUT request or the HTTP PATCH request mentioned earlier may be used instead. The AF 10 may invoke the “Nnef_ServiceParameter_Delete” service operation to the NEF 20 by sending an HTTP DELETE request towards the NEF 20. The HTTP DELETE request may be sent to an individual service parameter subscription resource at the NEF 20. Further general details on the “Nnef_ServiceParameter_Create/Update/Delete” service operations can be found in 3GPP TS 29.522 V17.4.0.

As illustrated by block 702 of Figure 11 , in response to receiving the first message (or any request) from the AF 10, the NEF 20 may authorise it and then perform mapping of the information comprised in it. In some embodiments, the mapping may comprise mapping the information into associated information needed by the (e.g. 5GC) network. For example, where the information comprises a generic public subscription identifier (GPSI), the mapping may comprise mapping from this GPSI to a subscription permanent identifier (SUPI).

As illustrated by arrow 704 of Figure 11 , in response to receiving the first message comprising information from the application function 10, the NEF 20 initiates transmission of a second message comprising the information towards the UDR 30 for storage. For example, when receiving the “Nnef_ServiceParameter_Create” request, the NEF 20 may invoke the “Nudr_DataRepository_Create” service operation to store the received service parameters in the UDR 30, e.g. by sending an HTTP PUT request to an individual service parameter data resource at the UDR 30. In another example, when receiving the “Nnef_ServiceParameter_Update” request, the NEF 20 may invoke the “Nudr_DataRepository_Update” service operation to request the modification of the service parameters in the UDR 30, e.g. by sending an HTTP PUT request or a HTTP PATCH request to the concerned individual service parameter data resource at the UDR 30. In another example, when receiving the “Nnef_ServiceParameter_Delete” request, the NEF 20 may invoke the “Nudr_DataRepository_Delete” service operation to request the deletion of the service parameters from the UDR 30, e.g. by sending an HTTP DELETE request to the concerned individual service parameter data resource at the UDR 30.

As illustrated by arrow 706 of Figure 11 , the UDR 30 may initiate transmission of a response to the second message towards the NEF 20. For example, in response to receiving the “Nudr_DataRepository_Create” service operation from the NEF 20 as the second message, the UDR 30 may reply with a “201 Created” response (if the processing of the service operation is successful). In another example, in response to receiving the “Nudr_DataRepository_Update” service operation from the NEF 20 as the second message, the UDR 30 may reply with a “200 OK” or “204 No Content” response (if the processing of the service operation is successful). In another example, in response to receiving the “Nudr_DataRepository_Delete” service operation from the NEF 20, the UDR 30 may reply with a “204 No Content” response (if the processing of the service operation is successful).

As illustrated by arrow 708 of Figure 11 , the NEF 20 may initiate transmission of a response to the first message towards the AF 10. The response to the first message may be an HTTP response.

Although not illustrated in Figure 11 , in response to receiving the second message comprising the information from the NEF 20, the UDR 30 stores the information. As mentioned above, the second message may comprise one or more first parameters for the service. Although also not illustrated in Figure 11 , if the second message comprises a request to create the one or more first parameters for the service, the UDR 30 may store the one or more first parameters for the service. Alternatively, if the second message comprises a request to update one or more existing second parameters for the service with the one or more first parameters, the UDR 30 may store the one or more existing second parameters for the service updated with the one or more first parameters.

At block 710 of Figure 11 , a method is performed if the PCF 40 has previously subscribed to be notified of updates to the information (e.g. service parameters and other information) stored at the user data repository 30. For example, the PCF 40 may have subscribed to be notified of such updates during a wireless device (e.g. UE) policy association establishment procedure.

As illustrated by arrow 712 of Figure 11 , the PCF 40 can acquire information from the UDR 30. In more detail, as illustrated by arrow 712 of Figure 11 , the UDR 30 may initiate transmission of a third message towards the PCF 40. The third message can comprise the information comprised in the first message and the second message, which is the information that is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. In an example, the UDR 30 may invoke, as the third message, a “Nudr_DataRepository_Notify” service operation to the PCF 40. Further general details on the “Nudr_DataRepository_Create/Update/Delete/Notify” service operations can be found in 3GPP TS 29.504 V17.5.0 and 3GPP TS 29.519 V17.5.0. The UDR 30 may invoke the “Nudr_DataRepository_Notify” service operation by sending the third message as a HTTP POST request. The third message may be sent to one or more associated callback uniform resource identifiers (URIs), “{notificationUri}”. As illustrated by arrow 714 of Figure 11 , the PCF 40 can initiate transmission of a response to the third message towards the UDR 30. In some embodiments, the response is a “204 No Content response”.

As illustrated by block 716 of Figure 11 , the PCF 40 may derive one or more policies for the wireless device, such as an RSP for the wireless device (e.g. a URSP in embodiments where the wireless device is a UE) and optionally also a V2X policy, and/or a 5G ProSe policy. The one or more policies can be derived based on the service specific parameters received from the UDR 30, and/or any V2X policies and/or wireless device capabilities (e.g. V2X capabilities) previously received from the AMF 50.

In more detail, the derivation of the one or more policies at block 716 of Figure 11 comprises the PCF 40 generating a set of rules for handling traffic associated with the service. For example, this may be the case where the service specific parameters provided by the AF 10 indicate that the service requires handling of redundant sessions. The set of rules is generated based on information acquired from the UDR 30. The set of rules can also be referred to herein as a set of route selection policy (RSP) rules or, in embodiments where the wireless device is a UE, a set of UE route selection policy (URSP) rules.

In some embodiments, the information acquired from the UDR 30 may be indicative that a first rule and a second rule is to be generated for the service. In these embodiments, the PCF 40 can generate the first rule and the second rule. The first rule can be that the primary session is to be established for handling primary traffic associated with the service and the second rule can be that the secondary session is to be established for handling secondary traffic associated with the service.

Although not illustrated in block 710 of Figure 11 , in some embodiments, this method may comprise the PCF 40 assigning a first traffic descriptor and a first session descriptor to the first rule. The first traffic descriptor can identify the primary traffic and the first session descriptor can identify the primary session. Alternatively or in addition, in some embodiments, the PCF 40 may assign a second traffic descriptor and a second session descriptor to the second rule. The second traffic descriptor can identify the secondary traffic and the second session descriptor can identify the secondary session.

In an example, when the PCF 40 is deriving the one or more wireless device policies and the information (or the service specific parameters) provided by the AF 10 indicates that the service requires handling of a primary session and a secondary session (e.g. redundant sessions), the PCF 40 can generate a set of two distinct (e.g. RSP or LIRSP) rules. These rules can have distinct traffic descriptors and route selection descriptors, including an allocated session pair ID and an RSN.

Although not illustrated in block 710 of Figure 11 , in some embodiments, this method may comprise the PCF 40 acquiring, from the UDR 30, an identifier assigned to the set of rules for use in identifying the rules of that set. For example, in embodiments involving a first rule and a second rule, an identifier assigned to the first rule and the second rule can be acquired for use in identifying the first rule and the second rule. The identifier can be referred to herein as a service pair ID. The service pair ID can be included in the service specific parameters provided for the generation of each rule and allows the PCF 40 to identify the (e.g. redundant) sessions, e.g. the primary session and the secondary session. The service pair ID may be added to the “UrspRuleRequest” data type as defined in 3GPP TS 29.522 V17.4.0. In this case, two instances of the “UrspRuleRequest” data type sharing the same service pair ID can be understood as the generation of two (e.g. RSP or URSP) rules requiring the establishment of redundant sessions.

Although also not illustrated in block 710 of Figure 11 , in some embodiments, this method may comprise the PCF 40 delivering the one or more policies to the wireless device, e.g. by initiating a wireless device policy delivery. For example, the PCF 40 can initiate transmission of the set of generated rules towards the wireless device for the wireless device to handle traffic associated with the service according to the set of rules. Thus, the PCF 40 can deliver the set of rules to the wireless device.

At block 718 of Figure 11 , an alternative method to that described earlier with reference to block 710 of Figure 11 can be performed. For example, at block 718 of Figure 11 , a method is performed if the PCF 40 has not previously subscribed to be notified of updates to the information (e.g. service parameters and other information) stored at the user data repository 30. In this respect, as illustrated by block 720 of Figure 11 , in some embodiments, the PCF 40 may acquire information from the UDR 30. In more detail, as illustrated by arrow 720 of Figure 11 , the PCF 40 remotely accesses information at the UDR 30. For example, the PCF 40 may retrieve information in the UDR 30 by invoking a “Nudr_DataRepository_Query” service operation. The information can be that comprised in the first message and the second message, which is the information that is indicative that a primary session is required for handling primary traffic associated with the service and a secondary session is required for handling secondary traffic associated with the service. The information can optionally also be the one or more service specific parameters.

At block 718 of Figure 11 , the PCF 40 may also determine one or more policies for the wireless device, such as an RSP for the wireless device (e.g. a URSP in embodiments where the wireless device is a UE) and optionally also a V2X policy, and/or a 5G ProSe policy. The one or more policies can be derived based on the service specific parameters retrieved from the UDR 30, and/or any V2X policies, 5G ProSe policies, and/or wireless device capabilities (e.g. V2X capabilities and/or 5G ProSe capabilities) received from the AMF 50.

In more detail, the determination of the one or more policies at block 718 of Figure 11 comprises the PCF 40 generating a set of rules for handling traffic associated with the service. For example, this may be the case where the service specific parameters provided by the AF 10 indicate that the service requires handling of redundant sessions. The set of rules is generated based on information acquired from the UDR 30. The set of rules can also be referred to herein as a set of RSP rules or, in embodiments where the wireless device is a UE, a set of URSP rules.

Although not illustrated in block 718 of Figure 11 , in some embodiments, this method may comprise the PCF 40 assigning a first traffic descriptor and a first session descriptor to the first rule. The first traffic descriptor can identify the primary traffic and the first session descriptor can identify the primary session. Alternatively or in addition, in some embodiments, the PCF 40 may assign a second traffic descriptor and a second session descriptor to the second rule. The second traffic descriptor can identify the secondary traffic and the second session descriptor can identify the secondary session.

Although not illustrated in block 718 of Figure 11 , in some embodiments, this method may comprise the PCF 40 acquiring, from the UDR 30, an identifier assigned to the set of rules for use in identifying the rules of that set. For example, in embodiments involving a first rule and a second rule, an identifier assigned to the first rule and the second rule can be acquired for use in identifying the first rule and the second rule. The identifier can be referred to herein as a service pair ID. The service pair ID can be included in the service specific parameters provided for the generation of each rule and allows the PCF 40 to identify the (e.g. redundant) sessions, e.g. the primary session and the secondary session. The service pair ID may be added to the “UrspRuleRequest” data type as defined in 3GPP TS 29.522 V17.4.0. In this case, two instances of the “UrspRuleRequest” data type sharing the same service pair ID can be understood as the generation of two (e.g. RSP or URSP) rules requiring the establishment of redundant sessions.

Although also not illustrated in block 718 of Figure 11 , in some embodiments, this method may comprise the PCF 40 delivering the one or more policies to the wireless device, e.g. during a wireless device policy association establishment procedure. For example, the PCF 40 can initiate transmission of the set of generated rules towards the wireless device for the wireless device to handle traffic associated with the service according to the set of rules. Thus, the PCF 40 can deliver the set of rules to the wireless device. In some embodiments, delivering the one or more policies to the wireless device can comprise delivering the determined V2XP policy and/or 5G ProSe policy to the wireless device. In some embodiments, the method may also comprise the PCF 40 delivering a corresponding V2X N2 PC5 policy and/or ProSe N2 PC5 policy to an access network, such as a radio access network (RAN) or next generation radio access network (NG- RAN).

Thus, in the manner described herein, according to some embodiments, the AF 10 can request the handling of redundancy sessions for services, such as services with high or ultra-high reliability requirements or any other services. The NEF 20 of the 5GC network can store these demands of the application function 10 in the UDR 30. The PCF 40 can retrieve this information and optionally also install (e.g. RSP or LIRSP) rules with these demands in the wireless device 60. In some embodiments, the method described herein may be performed whenever a wireless device registers in the network and/or whenever new demands are received from an application function 10 for already registered wireless devices.

In the manner described herein, according to some embodiments, the AF 10 can indicate to the 5GC network (via the NEF 20) its interest in applying redundancy to a session used for handling traffic of a specific service (such as a service with demands of high or ultra-high reliability or any other service). In order to do so, in some embodiments, the AF 10 can use the service parameter provisioning functionality and (e.g. apply the corresponding procedures defined in 3GPP TS 23.501 V17.3.0 to) provide policy requirements that apply to one or more wireless devices, such as a single wireless device or a group of wireless devices. For example, the AF 10 can store in the UDR 30 (via the NEF 20) the redundancy requirements for a service and one or more wireless devices so that the PCF 40 can retrieve this information. In some embodiments, the PCF 40 may retrieve this information as part of a wireless device policy association establishment procedure and can subscribe in the UDR 30 to be notified of changes related to these requirements. In some embodiments, when the PCF 40 retrieves information that a redundant session is required, the PCF 40 may generate two or more (e.g. RSP or URSP) rules. In some embodiments, the rules may include the RSN and session pair ID in the corresponding route selection descriptor.

In some embodiments, redundant traffic (e.g. traffic flows) provisioned by the AF 10 can always be split between redundant sessions. In some embodiments, two rules may be generated by the PCF 40, one for traffic (namely, the primary traffic referred to herein) and another one for the replicated traffic (namely, the secondary traffic referred to herein). In some embodiments, there may be a correlation identifier (namely, the service pair ID) among these two rules. In some embodiments, the NEF 20 may include, in a request for a rule, a new field with the traffic descriptors for redundant traffic. In some of these embodiments, the PCF 40 may transform this request into two distinct rules, for the traffic and the replicated traffic.

There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry 12 of the application function 10 described herein, the processing circuitry 22 of the network exposure function 20 described herein, the processing circuitry 32 of the user data repository 30 described herein, and/or the processing circuitry 42 of the policy control function 40 described herein), 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 application function 10 described herein, the processing circuitry 22 of the network exposure function 20 described herein, the processing circuitry 32 of the user data repository 30 described herein, and/or the processing circuitry 42 of the policy control function 40 described herein) 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 application function 10 described herein, the processing circuitry 22 of the network exposure function 20 described herein, the processing circuitry 32 of the user data repository 30 described herein, and/or the processing circuitry 42 of the policy control function 40 described herein) 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.

In some embodiments, the functionality (e.g. of the application function 10, network exposure function 20, user data repository 30, and/or policy control function 40) described herein can be performed by hardware. Thus, in some embodiments, the application function 10 described herein, the network exposure function 20 described herein, the user data repository 30 described herein, and/or the policy control function 40 described herein can be hardware. However, it will also be understood that optionally at least part or all of the functionality (e.g. of the application function 10, network exposure function 20, user data repository 30, and/or policy control function 40) described herein can be virtualized. For example, the functions performed by the application function 10 described herein, the network exposure function 20 described herein, the user data repository 30 described herein, and/or the policy control function 40 described herein can be implemented in software running on generic hardware that is configured to orchestrate them. Thus, in some embodiments, the application function 10 described herein, the network exposure function 20 described herein, the user data repository 30 described herein, and/or the policy control function 40 described herein can be virtual. In some embodiments, at least part or all of the functionality (e.g. of the application function 10, network exposure function 20, user data repository 30, and/or policy control function 40) described herein may be performed in a network enabled cloud. Thus, the method described herein can be realised as a cloud implementation according to some embodiments. The functionality (e.g. of the application function 10, network exposure function 20, user data repository 30, and/or policy control function 40) described herein may all be at the same location or at least some of the functionality may be distributed.

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 methods described herein can be computer-implemented methods.

The techniques described herein include advantageous techniques for managing sessions for providing a service to a wireless device in a network. In particular, the advantageous techniques provide an improved mechanism for the indication of network requirements for handling traffic associated with the service. In particular, the advantageous techniques ensure that the network has access to accurate and trustable information about service demands. In this way, for example, sessions for handling replica (or redundant) traffic can be requested only when required and consequently the resources of the network can be utilised more efficiently.

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

1. A method for managing sessions for providing a service to a wireless device (60) in a network, wherein the method is performed by an application function (10), the method comprising: initiating transmission (202, 700) of a first message towards a network exposure function (20), wherein the first message comprises information for use by a policy control function (40) in generating a set of rules for handling traffic associated with the service; and wherein the information is indicative that a primary session (602) is required for handling primary traffic (604) associated with the service and a secondary session (606) is required for handling secondary traffic (608) associated with the service, wherein the secondary traffic (608) is a replica of the primary traffic (604).

2. A method as claimed in claim 1 , wherein: the first message comprises one or more first parameters for the service.

3. A method as claimed in claim 2, wherein: the first message comprises a request to: create the one or more first parameters for the service; or update one or more existing second parameters for the service with the one or more first parameters.

4. A method as claimed in any of the preceding claims, wherein: the first message is a hypertext transfer protocol, HTTP, message.

5. A method as claimed in any of the preceding claims, wherein: the information is indicative that a first rule and a second rule is to be generated for the service, wherein the first rule is that the primary session (602) is to be established for handling primary traffic (604) associated with the service and the second rule is that the secondary session (606) is to be established for handling secondary traffic (608) associated with the service.

6. A method as claimed in claim 5, wherein: the first message comprises an identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule. 7. A method as claimed in claim 6, wherein: the identifier is unique to the application function (10).

8. A method as claimed in claim 6 or 7, wherein: the identifier replaces a previous identifier assigned to one or more previous rules generated for the service.

9. A method as claimed in any of the preceding claims, wherein: the first message comprises a request for the information to overwrite previous information indicative of one or more sessions required for handling traffic associated with the service.

10. A method as claimed in any of the preceding claims, wherein: the set of rules for handling traffic associated with the service is a set of rules for selecting a session for routing traffic associated with the service.

11. A method as claimed in any of the preceding claims, wherein: the primary session (602) is a new session or an updated version of an existing session; and/or the secondary session (606) is a new session or an updated version of an existing session.

12. A method as claimed in any of the preceding claims, wherein: the primary session (602) is a primary protocol data unit, PDU, session; and the secondary session (606) is a secondary PDU session.

13. A method as claimed in any of the preceding claims, wherein: the service is an ultra-reliable low-latency communication, URLLC, service.

14. A method for managing sessions for providing a service to a wireless device (60) in a network, wherein the method is performed by a network exposure function (20), the method comprising: in response to receiving (700) a first message comprising information from an application function (10), initiating transmission (302, 704) of a second message comprising the information towards a user data repository (30) for storage, wherein the information is for use by a policy control function (40) in generating a set of rules for handling traffic associated with the service; and wherein the information is indicative that a primary session (602) is required for handling primary traffic (604) associated with the service and a secondary session (606) is required for handling secondary traffic (608) associated with the service, wherein the secondary traffic (608) is a replica of the primary traffic (604).

15. A method as claimed in claim 14, wherein: the first message and the second message comprise one or more first parameters for the service.

16. A method as claimed in claim 15, wherein: the first message and the second message comprise a request to: create the one or more first parameters for the service; or update one or more existing second parameters for the service with the one or more first parameters.

17. A method as claimed in any of claims 15 to 16, wherein: one or both of the first message and the second message is a hypertext transfer protocol, HTTP, message.

18. A method as claimed in any of claims 14 to 17, wherein: the information is indicative that a first rule and a second rule is to be generated for the service, wherein the first rule is that the primary session (602) is to be established for handling primary traffic (604) associated with the service and the second rule is that the secondary session (606) is to be established for handling secondary traffic (608) associated with the service.

19. A method as claimed in claim 18, wherein: the first message and the second message comprise an identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule.

20. A method as claimed in claim 19, wherein: the identifier is unique to the application function (10).

21. A method as claimed in claim 19 or 20, wherein: the identifier replaces a previous identifier assigned to one or more previous rules generated for the service.

22. A method as claimed in any of claims 14 to 21 , wherein: the first message and the second message comprise a request for the information to overwrite previous information indicative of one or more sessions required for handling traffic associated with the service.

23. A method as claimed in any of claims 14 to 22, wherein: the set of rules for handling traffic associated with the service is a set of rules for selecting a session for routing traffic associated with the service.

24. A method as claimed in any of claims 14 to 23, wherein: the primary session (602) is a new session or an updated version of an existing session; and/or the secondary session (606) is a new session or an updated version of an existing session.

25. A method as claimed in any of claims 14 to 24, wherein: the primary session (602) is a primary protocol data unit, PDU, session; and the secondary session (606) is a secondary PDU session.

26. A method as claimed in any of claims 14 to 25, wherein: the service is an ultra-reliable low-latency communication, URLLC, service.

27. A method for managing sessions for providing a service to a wireless device (60) in a network, wherein the method is performed by a user data repository (30), the method comprising: in response to receiving (704) a second message comprising information from a network exposure function (20), storing (402) the information, wherein the information is for use by a policy control function (40) in generating a set of rules for handling traffic associated with the service; and wherein the information is indicative that a primary session (602) is required for handling primary traffic (604) associated with the service and a secondary session (606) is required for handling secondary traffic (608) associated with the service, wherein the secondary traffic (608) is a replica of the primary traffic (604).

28. A method as claimed in claim 27, wherein: the second message comprises one or more first parameters for the service.

29. A method as claimed in claim 28, wherein: the second message comprises a request to create the one or more first parameters for the service and the method comprises storing the one or more first parameters for the service; or the second message comprises a request to update one or more existing second parameters for the service with the one or more first parameters and the method comprises storing the one or more existing second parameters for the service updated with the one or more first parameters.

30. A method as claimed in any of claims 27 to 29, wherein: the second message is a hypertext transfer protocol, HTTP, message.

31. A method as claimed in any of claims 27 to 30, wherein: the information is indicative that a first rule and a second rule is to be generated for the service, wherein the first rule is that the primary session (602) is to be established for handling primary traffic (604) associated with the service and the second rule is that the secondary session (606) is to be established for handling secondary traffic (608) associated with the service.

32. A method as claimed in claim 31 , wherein: the second message comprises an identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule; and the method comprises storing the identifier with the information.

33. A method as claimed in claim 32, wherein: the identifier is unique to an application function (10) that provided the information.

34. A method as claimed in claim 32 or 33, wherein: the identifier replaces a previous identifier assigned to one or more previous rules generated for the service.

35. A method as claimed in any of claims 27 to 34, wherein: the second message comprises a request for the information to overwrite previous information indicative of one or more sessions required for handling traffic associated with the service; and storing the information comprises overwriting the previous information with the information.

36. A method as claimed in any of claims 27 to 35, wherein: the set of rules for handling traffic associated with the service is a set of rules for selecting a session for routing traffic associated with the service.

37. A method as claimed in any of claims 27 to 36, wherein: the primary session (602) is a new session or an updated version of an existing session; and/or the secondary session (606) is a new session or an updated version of an existing session.

38. A method as claimed in any of claims 27 to 37, wherein: the primary session (602) is a primary protocol data unit, PDU, session; and the secondary session (606) is a secondary PDU session.

39. A method as claimed in any of claims 27 to 38, wherein: the service is an ultra-reliable low-latency communication, URLLC, service.

40. A method for managing sessions for providing a service to a wireless device (60) in a network, wherein the method is performed by a policy control function (40), the method comprising: generating (502, 716, 720) a set of rules for handling traffic associated with the service, wherein the set of rules is generated based on information acquired from a user data repository (30); and wherein the information is indicative that a primary session (602) is required for handling primary traffic (604) associated with the service and a secondary session (606) is required for handling secondary traffic (608) associated with the service, wherein the secondary traffic (608) is a replica of the primary traffic (604).

41. A method as claimed in claim 40, wherein: the information is indicative that a first rule and a second rule is to be generated for the service; and generating the set of rules comprises generating the first rule and the second rule, wherein the first rule is that the primary session (602) is to be established for handling primary traffic (604) associated with the service and the second rule is that the secondary session (606) is to be established for handling secondary traffic (608) associated with the service.

42. A method as claimed in claim 41, the method comprising: assigning a first traffic descriptor and a first session descriptor to the first rule, wherein the first traffic descriptor identifies the primary traffic (604) and the first session descriptor identifies the primary session (602); and/or assigning a second traffic descriptor and a second session descriptor to the second rule, wherein the second traffic descriptor identifies the secondary traffic (608) and the second session descriptor identifies the secondary session (606).

43. A method as claimed in any of claims 40 to 42, the method comprising: acquiring the information from the user data repository (30).

44. A method as claimed in claim 43, wherein: acquiring the information from the user data repository (30) comprises: receiving (712) a third message from the user data repository (30), wherein the third message comprises the information; or remotely (720) accessing the information at the user data repository (30).

45. A method as claimed in any of claims 40 to 44, wherein: the policy control function (40) is subscribed to be notified of updates to the information stored at the user data repository (30).

46. A method as claimed in any of claims 40 to 45, the method comprising: acquiring, from the user data repository (30), an identifier assigned to the first rule and the second rule for use in identifying the first rule and the second rule. 47. A method as claimed in claim 46, wherein: the identifier is unique to an application function (10) that provided the information.

48. A method as claimed in claim 46 or 47, wherein: the identifier replaces a previous identifier assigned to one or more previous rules generated for the service.

49. A method as claimed in any of claims 40 to 48, the method comprising: initiating transmission of the set of rules towards the wireless device (60) for the wireless device (60) to handle traffic associated with the service according to the set of rules.

50. A method as claimed in any of claims 40 to 49, wherein: the set of rules for handling traffic associated with the service is a set of rules for selecting a session for routing traffic associated with the service.

51. A method as claimed in any of claims 40 to 50, wherein: the primary session (602) is a new session or an updated version of an existing session; and/or the secondary session (606) is a new session or an updated version of an existing session.

52. A method as claimed in any of claims 40 to 51 , wherein: the primary session (602) is a primary protocol data unit, PDU, session; and the secondary session (606) is a secondary PDU session.

53. A method as claimed in any of claims 40 to 52, wherein: the service is an ultra-reliable low-latency communication, URLLC, service.

54. A method performed by a system, the method comprising any two or more of: the method as claimed in any of claims 1 to 13; the method as claimed in any of claims 14 to 26; the method as claimed in any of claims 27 to 39; and the method as claimed in any of claims 40 to 53. An application function (10) comprising: processing circuitry (12) configured to operate in accordance with any of claims 1 An application function (10) as claimed in claim 55, wherein: the application function (10) comprises: at least one memory (14) for storing instructions which, when executed by the processing circuitry (12), cause the application function (10) to operate in accordance with any of claims 1 to 13. A network exposure function (20) comprising: processing circuitry (22) configured to operate in accordance with any of claims 26. A network exposure function (20) as claimed in claim 57, wherein: the network exposure function (20) comprises: at least one memory (24) for storing instructions which, when executed by the processing circuitry (22), cause the network exposure function (20) to operate in accordance with any of claims 14 to 26. A user data repository (30) comprising: processing circuitry (32) configured to operate in accordance with any of claims 39. A user data repository (30) as claimed in claim 59, wherein: the user data repository (30) comprises: at least one memory (34) for storing instructions which, when executed by the processing circuitry (32), cause the user data repository (30) to operate in accordance with any of claims 27 to 39. A policy control function (40) comprising: processing circuitry (42) configured to operate in accordance with any of claims 53.

62. A policy control function (40) as claimed in claim 61, wherein: the policy control function (40) comprises: at least one memory (44) for storing instructions which, when executed by the processing circuitry (42), cause the policy control function (40) to operate in accordance with any of claims 40 to 53.

63. A system comprising any two or more of: the application function (10) as claimed in claim 55 or 56; the network exposure function (20) as claimed in claim 57 or 58; the user data repository (30) as claimed in claim 59 or 60; and the policy control function (40) as claimed in claim 61 or 62.

64. 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 54.

65. 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 54.