WO2023148124A1 - Gestion de session pour sessions pdu redondantes - Google Patents

Gestion de session pour sessions pdu redondantes Download PDF

Info

Publication number
WO2023148124A1
WO2023148124A1 PCT/EP2023/052152 EP2023052152W WO2023148124A1 WO 2023148124 A1 WO2023148124 A1 WO 2023148124A1 EP 2023052152 W EP2023052152 W EP 2023052152W WO 2023148124 A1 WO2023148124 A1 WO 2023148124A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
session
traffic
rule
information
Prior art date
Application number
PCT/EP2023/052152
Other languages
English (en)
Inventor
Fuencisla Garcia Azorero
Maria Belen PANCORBO MARCOS
Susana Fernandez Alonso
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2023148124A1 publication Critical patent/WO2023148124A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels

Definitions

  • 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.
  • Figure 1 illustrates a third generation partnership project (3GPP) network architecture for the fifth generation (5G) of wireless mobile telecommunications technology.
  • 3GPP third generation partnership project
  • 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.
  • 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.
  • AUSF authentication server function
  • AMF access and mobility management function
  • SMF session management function
  • 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).
  • UE user equipment
  • AN access network
  • RAN radio access network
  • UPF user plane function
  • DN data network
  • 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.
  • PDU protocol data unit
  • a UE route selection policy In order to establish two disjoint redundant PDU sessions, a UE route selection policy (URSP) is commonly used.
  • URSP UE route selection policy
  • 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.
  • DNNs data network names
  • IP descriptors e.g. a media access control (MAC) address, or virtual local area network identifier (VLAN ID)
  • 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.
  • 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.
  • PDU protocol data unit
  • PCF policy control function
  • URSP UE route selection policy
  • NEF network exposure function
  • 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.
  • URLLC ultra-reliable low-latency communication
  • An application function 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.
  • NEF network exposure function
  • UDR user data repository
  • the PCF can retrieve the information from the UDR and generate URSP rules according to the information.
  • the AF 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).
  • 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.
  • 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).
  • a first method for managing sessions for providing a service to a wireless device in a network 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.
  • an application function configured to operate in accordance with the first method described earlier.
  • the application function may comprise processing circuitry configured to operate in accordance with the first method described earlier.
  • 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.
  • a second method for managing sessions for providing a service to a wireless device in a network 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.
  • a network exposure function configured to operate in accordance with the second method described earlier.
  • the network exposure function may comprise processing circuitry configured to operate in accordance with the second method described earlier.
  • 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.
  • a third method for managing sessions for providing a service to a wireless device in a network 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.
  • a user data repository configured to operate in accordance with the third method described earlier.
  • the user data repository may comprise processing circuitry configured to operate in accordance with the third method described earlier.
  • 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.
  • a fourth method for managing sessions for providing a service to a wireless device in a network 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.
  • a policy control function configured to operate in accordance with the fourth method described earlier.
  • the policy control function may comprise processing circuitry configured to operate in accordance with the fourth method described earlier.
  • 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.
  • a method performed by a 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 11 is a signalling diagram illustrating an exchange of signals in a system according to an embodiment.
  • 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.
  • VoIP voice over IP
  • PDA personal digital assistant
  • LOE laptop-embedded equipment
  • LME laptop-mounted equipment
  • 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.
  • D2D device-to-device
  • 3GPP third generation partnership project
  • V2V vehicle-to-vehicle
  • V2I vehicle- to-infrastructure
  • V2X vehicle-to-everything
  • 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.
  • M2M machine-to-machine
  • MTC machine type communication
  • 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.
  • UE user equipment
  • NB-loT narrow band internet of things
  • 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).
  • 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.
  • 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.
  • the network referred to herein can be a telecommunications network.
  • 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.
  • the network referred to herein can be a radio access network (RAN).
  • the network referred to herein can be a local network, such as a local area network (LAN).
  • the network referred to herein may be a content delivery network (CDN).
  • the network referred to herein may be a software defined network (SDN).
  • 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).
  • AF application function
  • NEF network exposure function
  • UDR user data repository
  • PCF policy control function
  • FIG. 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.
  • 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.
  • 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).
  • the application function 10 referred to herein may also be referred to as an application function node.
  • 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.
  • 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.
  • 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.
  • the processing circuitry 12 may be configured to run a container to perform the method described herein in respect of the application function 10.
  • 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.
  • 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.
  • 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.
  • RAM random access memory
  • ROM read only memory
  • CD compact disk
  • DVD digital versatile disk
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the application function 10 described earlier with reference to Figure 2 can be configured to operate in accordance with the method of Figure 3.
  • the method can be performed by or under the control of the processing circuitry 12 of the application function 10.
  • transmission of a first message is initiated towards a network exposure function.
  • 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.
  • the term “initiate” can mean, for example, cause or establish.
  • 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.
  • the term “handling” can mean transmitting and/or receiving.
  • the primary session can be a primary session between the wireless device and another node of the network.
  • 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.
  • the primary session can be a primary session between the wireless device and the application function 10.
  • the secondary session can be a secondary session between the wireless device and another or the same data network.
  • 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.
  • the secondary session can be a secondary session between the wireless device and the application function 10.
  • the secondary traffic may also be referred to as redundant traffic.
  • the secondary session may also be referred to as a redundant session.
  • 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.
  • 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.
  • the primary session referred to herein may be a new session or an updated version of an existing session.
  • the secondary session referred to herein may be a new session or an updated version of an existing session.
  • the primary session referred to herein can be a primary protocol data unit (PDU) session.
  • the secondary session can be a secondary PDU session.
  • 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).
  • DN data network
  • UPF user plane function
  • a PDU session is defined as an association between the wireless device and a data network that provides a PDU connectivity service.
  • 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.
  • 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.
  • V2X vehicle to everything
  • 5G ProSe 5G proximity services
  • URSP UE route selection policy
  • 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.
  • 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.
  • the first message referred to herein may be a hypertext transfer protocol (HTTP) message.
  • HTTP hypertext transfer protocol
  • the HTTP message may be a HTTP POST request, such as in embodiments where the request is to create one or more service parameters.
  • 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.
  • the information referred to herein can be indicative that a first rule and a second rule is to be generated for the service.
  • 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.
  • 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.
  • the identifier referred to herein can be unique to the application function 10.
  • the identifier referred to herein can comprise a combination of two or more identifiers.
  • 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.
  • the identifier referred to herein may replace a previous identifier assigned to one or more previous rules generated for the service.
  • 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.
  • 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.
  • the set of rules referred to herein can also be referred to as a set of route selection policy (RSP) rules.
  • RSP route selection policy
  • 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.
  • 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.
  • LIRLLC ultra-reliable low-latency communication
  • 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.
  • FIG. 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.
  • 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.
  • the application function 10 may be a physical node (e.g. a physical machine) or a virtual node (e.g. a virtual machine, VM).
  • the network exposure function 20 referred to herein may also be referred to as a network exposure function node.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • RAM random access memory
  • ROM read only memory
  • CD compact disk
  • DVD digital versatile disk
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method can be performed by or under the control of the processing circuitry 22 of the network exposure function 20.
  • 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.
  • 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
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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).
  • the user data repository 30 referred to herein may also be referred to as a user data repository node.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • RAM random access memory
  • ROM read only memory
  • CD compact disk
  • DVD digital versatile disk
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method can be performed by or under the control of the processing circuitry 32 of the user data repository 30.
  • 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.
  • the information may be stored in the memory 34 of the user data repository 30.
  • 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).
  • 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.
  • the one or more first parameters may be stored.
  • the user data repository 30 e.g. the processing circuitry 32 of the user data repository 30
  • 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.
  • 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.
  • 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.
  • 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.
  • the user data repository 30 e.g. the processing circuitry 32 of the user data repository 30
  • 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.
  • storing the information may comprise overwriting the previous information with the information.
  • the user data repository 30 e.g. the processing circuitry 32 of the user data repository 30
  • the user data repository 30 may be configured to overwrite the previous information with the information according to some embodiments.
  • FIG. 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.
  • 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.
  • 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).
  • the policy control function 40 referred to herein may also be referred to as a policy control function node.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • RAM random access memory
  • ROM read only memory
  • CD compact disk
  • DVD digital versatile disk
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method can be performed by or under the control of the processing circuitry 42 of the policy control function 40.
  • 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.
  • generating the set of rules may comprise generating 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.
  • the method may comprise assigning a first traffic descriptor and a first session descriptor to the first rule.
  • the policy control function 40 e.g. the processing circuitry 42 of the policy control function 40
  • the method can comprise assigning a second traffic descriptor and a second session descriptor to the second rule.
  • the policy control function 40 e.g. the processing circuitry 42 of the policy control function 40
  • 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.
  • any one or more of the descriptors referred to herein can be a value.
  • the method may comprise acquiring the information from the user data repository 30.
  • the policy control function 40 e.g. the processing circuitry 42 of the policy control function 40
  • acquiring the information from the user data repository 30 may comprise receiving a third message from the user data repository 30.
  • 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.
  • the third message comprises the information.
  • the policy control function 40 in order for the policy control function 40 to receive the third message, may have previously subscribed in the user data repository 30 to receive it.
  • acquiring the information from the user data repository 30 may comprise remotely accessing the information at the user data repository 30.
  • 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.
  • 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.
  • 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.
  • the policy control function 40 e.g. the processing circuitry 42 of the policy control function 40
  • 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.
  • 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.
  • acquiring the identifier from the user data repository 30 may comprise remotely accessing the identifier at the user data repository 30.
  • 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.
  • the policy control function 40 can be subscribed to be notified of updates to the identifier stored at the user data repository 30.
  • 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.
  • the policy control function 40 e.g. the processing circuitry 42 of the policy control function 40
  • the policy control function 40 e.g. the processing circuitry 42 of the policy control function 40
  • 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.
  • 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.
  • 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).
  • RSN retransmission sequence number
  • each rule can be assigned an identifier.
  • 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.
  • 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:
  • the policy control function 40 generates four rules, one for each of the sessions identified above.
  • 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.
  • the application function 10 described herein can indicate whether the service requires redundancy.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an application running on the wireless device 60 replicates the primary traffic 604.
  • 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.
  • the secondary session 606 can be referred to herein as a redundant session.
  • 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.
  • 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.
  • 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.
  • 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.
  • the primary session 602 and the secondary session 606 form two disjoint paths for handing traffic.
  • 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.
  • 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.
  • the primary traffic 604 and the secondary traffic 608 can be differentiated.
  • the application function 10 may be configured to eliminate the secondary traffic 608.
  • the application function 10 may comprise an element for eliminating replica traffic.
  • FIG 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
  • the PCT 40 can be as described earlier with reference to Figures 8 and 9.
  • the system may also comprise a wireless device (e.g. UE).
  • the system illustrated in Figure 11 is for managing (e.g.
  • 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.
  • 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.
  • 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.
  • 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.
  • the secondary traffic can be referred to as redundant traffic and the secondary session can be referred to as a redundant session.
  • 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.
  • the at least two rules can be at least two URSP rules.
  • the two rules can imply the establishment of two redundant sessions.
  • 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.
  • 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.
  • 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.
  • 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.
  • the AF 10 can influence the generation of the new set of rules for handling traffic associated with the service.
  • new redundant e.g. PDU
  • modification of existing redundant e.g. PDU
  • 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.
  • the at least two new rules can be at least two new URSP rules.
  • the two new rules can imply the establishment of two new redundant sessions.
  • 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.
  • 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.
  • the AF 10 may request the removal of a redundancy requirement for a service.
  • the AF 10 may remove the earlier described information related to the primary session and the secondary session from the remaining service specific parameters.
  • 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.
  • to e.g.
  • 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.
  • 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.
  • the NEF 20 may authorise it and then perform mapping of the information comprised in it.
  • the mapping may comprise mapping the information into associated information needed by the (e.g. 5GC) network.
  • the mapping may comprise mapping from this GPSI to a subscription permanent identifier (SUPI).
  • GPSI generic public subscription identifier
  • SUPI subscription permanent identifier
  • the NEF 20 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the UDR 30 in response to receiving the second message comprising the information from the NEF 20, the UDR 30 stores the information.
  • the second message may comprise one or more first parameters for the service.
  • the UDR 30 may store the one or more first parameters for the service.
  • 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.
  • 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.
  • the PCF 40 may have subscribed to be notified of such updates during a wireless device (e.g. UE) policy association establishment procedure.
  • the PCF 40 can acquire information from the UDR 30.
  • 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.
  • the UDR 30 may invoke, as the third message, a “Nudr_DataRepository_Notify” service operation to the PCF 40.
  • 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 ⁇ ”.
  • URIs uniform resource identifiers
  • the PCF 40 can initiate transmission of a response to the third message towards the UDR 30.
  • the response is a “204 No Content response”.
  • 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.
  • 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.
  • 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.
  • RSP route selection policy
  • URSP UE route selection policy
  • 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.
  • 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.
  • 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.
  • 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.
  • the PCF 40 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the PCF 40 can deliver the set of rules to the wireless device.
  • an alternative method to that described earlier with reference to block 710 of Figure 11 can be performed.
  • 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.
  • the PCF 40 may acquire information from the UDR 30.
  • the PCF 40 remotely accesses information at the UDR 30.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the PCF 40 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the PCF 40 can deliver the set of rules to the wireless device.
  • 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.
  • 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).
  • an access network such as a radio access network (RAN) or next generation radio access network (NG- RAN).
  • RAN radio access network
  • NG- RAN next generation radio access network
  • 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.
  • 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.
  • 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).
  • a specific service such as a service with demands of high or ultra-high reliability or any other service.
  • 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.
  • 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.
  • 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.
  • the PCF 40 may generate two or more (e.g. RSP or URSP) rules.
  • the rules may include the RSN and session pair ID in the corresponding route selection descriptor.
  • redundant traffic e.g. traffic flows
  • 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).
  • the NEF 20 may include, in a request for a rule, a new field with the traffic descriptors for redundant traffic.
  • the PCF 40 may transform this request into two distinct rules, for the traffic and the replicated traffic.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the functionality e.g. of the application function 10, network exposure function 20, user data repository 30, and/or policy control function 40
  • 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.
  • the functionality e.g. of the application function 10, network exposure function 20, user data repository 30, and/or policy control function 40
  • the functionality can be virtualized.
  • 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.
  • 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.
  • 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.
  • 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.
  • the techniques described herein include advantageous techniques for managing sessions for providing a service to a wireless device in a network.
  • the advantageous techniques provide an improved mechanism for the indication of network requirements for handling traffic associated with the service.
  • 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.

Landscapes

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

Abstract

L'invention concerne un procédé de gestion de sessions destiné à fournir un service à un dispositif sans fil dans un réseau. Le procédé est mis en œuvre par une fonction d'application. Le procédé comprend l'initiation de la transmission (202) d'un premier message vers une fonction d'exposition de réseau. Le premier message comprend des informations destinées à être utilisées par une fonction de contrôle de politique dans la génération d'un ensemble de règles pour gérer le trafic associé au service. Les informations indiquent qu'une session primaire est nécessaire pour gérer un trafic primaire associé au service et qu'une session secondaire est nécessaire pour gérer un trafic secondaire associé au service. Le trafic secondaire représente une réplique du trafic primaire.
PCT/EP2023/052152 2022-02-02 2023-01-30 Gestion de session pour sessions pdu redondantes WO2023148124A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP22382089.5 2022-02-02
EP22382089 2022-02-02

Publications (1)

Publication Number Publication Date
WO2023148124A1 true WO2023148124A1 (fr) 2023-08-10

Family

ID=80447279

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/052152 WO2023148124A1 (fr) 2022-02-02 2023-01-30 Gestion de session pour sessions pdu redondantes

Country Status (1)

Country Link
WO (1) WO2023148124A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020254987A1 (fr) * 2019-06-17 2020-12-24 Telefonaktiebolaget Lm Ericsson (Publ) Indication de réseau central d'une action de réseau d'accès radio lorsque la redondance n'est pas disponible

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020254987A1 (fr) * 2019-06-17 2020-12-24 Telefonaktiebolaget Lm Ericsson (Publ) Indication de réseau central d'une action de réseau d'accès radio lorsque la redondance n'est pas disponible

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3 (Release 17)", vol. CT WG3, no. V17.4.0, 23 September 2021 (2021-09-23), pages 1 - 170, XP052056628, Retrieved from the Internet <URL:https://ftp.3gpp.org/Specs/archive/29_series/29.513/29513-h40.zip 29513-h40.docx> [retrieved on 20210923] *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17)", vol. SA WG2, no. V17.3.0, 23 December 2021 (2021-12-23), pages 1 - 559, XP052083263, Retrieved from the Internet <URL:https://ftp.3gpp.org/Specs/archive/23_series/23.501/23501-h30.zip 23501-h30.docx> [retrieved on 20211223] *

Similar Documents

Publication Publication Date Title
CN111955031B (zh) 在移动通信系统中使用网络切片的方法和设备
JP7272736B2 (ja) サービス加入方法、当該方法を実行するためのチップ、情報伝達装置およびプログラム、並びにネットワーク機能ネットワーク要素
CN116057924B (zh) 用于提供网络功能发现服务增强的方法、系统和计算机可读介质
US10637794B2 (en) Resource subscription method, resource subscription apparatus, and resource subscription system
EP3496432B1 (fr) Transmission multicast efficace
JP2024521821A (ja) コアネットワークにおいてネットワーク機能（ｎｆ）高可用性（ｈａ）トポロジ情報を配布するための方法、システム、およびコンピュータ可読媒体
JP2019525604A (ja) ネットワーク機能ｎｆ管理方法及びｎｆ管理装置
CN115152320A (zh) 无线通信系统中用于增强网络选择准确性的方法和装置
CN112533177A (zh) 一种提供、发现移动边缘计算的方法及设备、装置、介质
US20220014903A1 (en) Retrieving a core network or access network assigned user equipment identifier
JP7246379B2 (ja) 通信ネットワークにおけるサービス層メッセージテンプレート
JP2023537154A (ja) セッション更新方法、端末及びネットワーク側機器
KR102423812B1 (ko) 안정적인 분산형 M2M/IoT 서비스들의 가능화
JP2024081633A (ja) サービス要求の処理
US9888001B2 (en) Methods, systems, and computer readable media for negotiating diameter capabilities
WO2023124635A1 (fr) Procédé de traitement d&#39;informations, élément réseau, support de stockage et produit-programme
US20230102122A1 (en) Methods, systems, and computer readable media for identifying alternate delivery endpoints for mobile originated data and monitoring reports in a communications network
US11924294B2 (en) Service request handling
WO2023148124A1 (fr) Gestion de session pour sessions pdu redondantes
WO2019061400A1 (fr) Découverte de service améliorée pour l&#39;association de fonctions de réseau
WO2019242459A1 (fr) Procédé de commutation de nœud, nœud de réseau, système de réseau et support d&#39;informations
US20190312929A1 (en) Information synchronization method and device
US11709725B1 (en) Methods, systems, and computer readable media for health checking involving common application programming interface framework
EP4366344A1 (fr) Procédé et appareil de sélection d&#39;entité de service d&#39;adresse, et dispositif électronique et support de stockage lisible
RU2783811C2 (ru) Способ подписки на услуги и устройство

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23702018

Country of ref document: EP

Kind code of ref document: A1