Patent Description:
When a user establishes a packet data unit (PDU) session with the network, a user plane function (UPF) is selected by a session management function (SMF) or other network node based on various criteria including the dynamic load on the UPF, the UPF's location, the UPF's capabilities and the functionality required to support the PDU session, the PDU session type, the subscriber profile of the UE, the access network used by the UE, the radio access technology being used by the UE, the Data Network Name (DNN), the UPF's relative static capacity among UPFs supporting the same DNN, and local operator policies. This list of factors is not exclusive and other factors may be considered.

The UPF is responsible for the handling of user plane traffic. One of the functions performed by the UPF is classification of packet flows so that the packet flows can be assigned to Quality of Service (QoS) flows in the network. The classification of packet flows requires inspection of packets contained in the packet flow. The level of inspection needed to classify a packet flow can depend on numerous parameters. In some cases, a packet flow may be classified by examining only header information. In other cases, deep packet inspection of application layer data may be required. The level of inspection needed to classify packet flows can have a significant impact on the use of computational resources (e.g., central processing unit (CPU) and memory resources) needed to process the packet flow. Having per subscriber information about computational resource demand would be useful in UPF selection in order to distribute computational loads more evenly among the available UPFs, or to assign PDU session associated with large computational loads to specific UPFs. By making the distribution of computational loads more predictable, more accurate dimensioning of UPF resources is possible, which will improve resource utilization.

<CIT> describes a technique for enhancing regular expression search performance through cost-based optimization. An effective search node is configured based on splitting, regrouping, complexity calculation, and learning information, and perform high-performance regular expression search.

<CIT> describes a technique for managing network traffic in a wireless communication system. A method for creating an uplink classifier (UL CL) by an SMF comprises the steps of: transmitting, to a network data connection and analysis function (NWDAF), a request for providing UL CL-related information for controlling the flow of network traffic; receiving the UL CL-related information from the NWDAF; selecting at least one from a plurality of UPFs on the basis of the received UL CL-related information; and creating a UL CL for the selected UPF.

The present disclosure provides methods implemented by network nodes, a network node and a computer program as defined in the independent claims.

Referring now to the drawings, an exemplary embodiment of the disclosure will be described in the context of a Fifth Generation (<NUM>) communication network. Those skilled in the art will appreciate that the principles and techniques herein described are not limited to use in <NUM> networks but may also be used in communication networks operating according to other standards where UPF selection is performed.

<FIG> illustrates a communication network <NUM> according to one exemplary embodiment. The communication network <NUM> comprises a <NUM> radio access network (RAN) <NUM> and a core network <NUM> employing a service-based architecture. The RAN <NUM> comprises one or more base stations <NUM> that implement the Next Radio (NR) interface and provide radio access to UEs <NUM> operating in the communication network <NUM>. The base stations <NUM> implementing the NR interface are referred to in applicable standards as gNodeBs (gNBs). Those skilled in the art will appreciate that other types of RANs in addition to the <NUM> RAN <NUM> can connect to the 5GC <NUM>. For example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (EUTRA) base station in an Evolved UMTS Terrestrial Radio Access Network (EUTRAN) may also connect to the 5GC <NUM>. The UEs <NUM> may comprise cellular phones, smart phones, tablets, laptop computers, or other electronic devices with communication capabilities. The core network <NUM>, referred to herein as a <NUM> Core (5GC), provides a connection between the RAN <NUM> and other packet data networks, such as the Internet Protocol (IP) Multimedia Subsystem (IMS) or the Internet.

The 5GC <NUM> comprises a number of Network Function (NFs) as illustrated in <FIG>. The NFs in the 5GC <NUM> include a User Plane Function (UPF) <NUM>, an Access and Mobility Management Function (AMF) <NUM>, a Session Management Function (SMF) <NUM>, a Policy Control Function (PCF) <NUM>, a Unified Data Management (UDM) function <NUM>, a Authentication Server Function (AUSF) <NUM>, a Network Exposure Function (NEF) <NUM>, a Network Slice Selection Function (NSSF) <NUM>, a Network Repository Function (NRF) <NUM>, an Application Function (AF) <NUM> (which may be located in the core network <NUM> or be external to the core network <NUM>), a Unified Data Repository (UDR) <NUM> and a Network Data Analytics Function (NWDAF) <NUM>.

The NFs shown in <FIG> comprise logical entities that reside in one or more core network nodes, which may be implemented by one or more processors, hardware, firmware, or a combination thereof. The NFs may reside in a single core network node or may be distributed among two or more core network nodes. Further, the network <NUM> may include multiple instances of the NFs.

In conventional communication network, the various NFs (e.g., UPF <NUM>, SMF <NUM>, AMF <NUM>, PCF <NUM>, etc.) in the 5GC <NUM> communicate with one another over predefined interfaces. In the service-based architectures shown in <FIG>, the 5GC <NUM> uses a services model in which the NFs query the NRF <NUM> or other NF discovery node to discover and communicate with each other. The NFs can subscribe to receive notification services and data from other NFs. In this context, the NF providing the service or data is referred to as a service producer and the NF receiving the data and reports is referred to as a service consumer. In conventional <NUM> networks, the UPF <NUM> is an exception and uses a pre-defined interface denoted as the N4 interface to communicate with the SMF <NUM>. One aspect of the disclosure is the addition of new service based interface (SBI) for the UPF <NUM> denoted the Nupf interface to enable the UPF <NUM> to communicate with other NFs in the 5GC <NUM>.

This disclosure relates to selection of the UPF for a PDU session. The UPF <NUM> is responsible for the handling of user plane traffic. One of the functions performed by the UPF <NUM> is classification of packet flows and mapping of the packet flows to Quality of Service (QoS) flows in the communication network. Referring to <FIG>, data packets arriving at the UPF <NUM> from outside the network <NUM> are classified by the UPF <NUM>, assigned to a QoS flow and marked with a QoS Flow Identifier (QFI). Within the RAN <NUM>, the QoS flows are then mapped to radio bearers and transmitted to the UE <NUM>. In the opposite direction, the UE <NUM> maps uplink data packets to corresponding QoS flows, which are mapped to radio bears and transmitted to the base station <NUM>, which forwards the QoS flows to the UPF <NUM>.

To classify Internet Protocol (IP) packets arriving from outside the network, the UPF <NUM> is configured with a set of packet detection rules (PDRs). The PDRs are applied in sequence to data packets within a packet flow until the packet flow can be classified and assigned to a particular QoS flow within a Packet Data Unit (PDU) session. The classification of the packet flows may require the UPF <NUM> to inspect not only the packet headers, but also the application layer content in data packets, a process known as deep packet inspection (DPI). The header typically includes a <NUM> tuple comprising: the IP source address, the IP destination address, the source transport address, the destination transport address, and the transport protocol (e.g., Transport Control Protocol (TCP) or Uniform Datagram Protocol (UDP)). In some cases, it may be possible to classify a packet flow based only on header information. In other cases, DPI of application layer information carried by IP data packets is required.

When a user establishes a PDU session with the network <NUM>, a UPF <NUM> is selected by the SMF <NUM> based on various criteria including the dynamic load on the UPF <NUM>, the UPF's location; the UPF's capabilities and the functionality required to support the PDU session; the PDU session type; the subscriber profile of the UE <NUM>; the access network used by the UE <NUM>; the radio access technology being used by the UE <NUM>; the Data Network Name (DNN); the UPF's relative static capacity among UPFs <NUM> supporting the same DNN, and local operator policies. This list of factors is not exclusive and other factors may be considered. A more comprehensive listing of factors used in UPF selection can be found in Technical Speciation (TS) <NUM>, subclause <NUM>.

To aid in UPF selection, the NWDAF <NUM> may collect load information from the UPFs <NUM> and make this information available to the SMF <NUM> for UPF selection. For example, the NWDAF <NUM> can obtain information about load level and number of subscribers for the UPF <NUM>, from which it can compute aggregate statistics such as the average load on the UPF <NUM> per subscriber. However, information about the computational resource demand in terms of memory usage and central processing unit (CPU) usage per subscriber are not available.

Having per subscriber information about computational resource demand would be useful to the SMF <NUM> in UPF selection. Knowing the demand on CPU usage and memory usage for a PDU session for a particular subscriber would enable the SMF <NUM> to make UPF selection more efficiently. However, the computational resource demand can vary greatly from one subscriber to another and from one UPF <NUM> to another. For example, different packet flows for different subscribers may require different levels of packet inspection in order to classify the packet flows and map the packets to QoS flows. Thus, packet flows with the same volume of data packets may place widely different demands on computational resources. The packet inspection for one packet flow may require relatively few computational resources while the packet inspection for a different packet flow may require a far greater amount of computational resources due, for example, to the need to perform DPI or to the number of PDRs that need to be applied to classify the packet flow. Also, each UPF <NUM> may have its own set of PDRs and policies for performing packet inspection so that packet inspection for one UPF <NUM> may use more computational resources than another UPF <NUM>. Currently, there is no way for the SMF <NUM> to determine the demand on computational resources attributable to a PDU session.

According to one aspect of the disclosure, techniques are provided to enable the SMF <NUM> or other network node performing UPF selection to determine a computational resource demand, also referred to herein as the computational footprint, of PDU session. The computational footprint can then be used by the SMF <NUM> or other network node to inform the selection of the UPF <NUM> during PDU session establishment. For example, the SMF <NUM> may want to distribute PDU sessions associated with high computational demands (i.e., with large computational footprints) evenly among the available UPFs <NUM>. Distributing the PDU sessions with high demands more evenly can prevent overloading of a UPF <NUM> when there is a surge in the packet flows. As another example, the SMF <NUM> may want to assign PDU sessions associated with high computational demands to a UPF <NUM> in a preferred group of UPFs <NUM> based on the available processing resources at the UPFs <NUM> in the preferred group.

The techniques herein described provide a mechanism for selecting a UPF <NUM> for a PDU session based on historical CPU and memory usage associated with the subscriber. Generally, the NWDAF <NUM> collects information regarding packet inspection from multiple UPFs <NUM> and generates per subscriber models of the computational resource demand in terms of CPU footprint and memory footprint associated with each subscriber. The NWDAF <NUM> stores the models of the computational footprints for each subscriber in the UDR <NUM>. The models can be dynamically updated over time as additional data is collected. When a UE <NUM> establishes a PDU session, the SMF <NUM> retrieves the CPU footprint and/or memory footprint associated with the subscriber from the UDR <NUM> and selects the UPF <NUM> based at least in part on the computational footprint. For example, the SMF <NUM> may use the footprint information to distribute computational loads associated with PDU sessions more evenly among the available UPFs <NUM>, or to assign PDU sessions associated with large computational loads to specific UPFs <NUM>. These techniques enable more accurate dimensioning of subscribers and network resources and more efficient use of the resources at each UPF <NUM>.

In some embodiments, the UPF <NUM> collects information on a per subscriber basis and the NWDAF <NUM> generates per subscriber models of the computational footprint. The computational footprint for a PDU session in this case is specific to the UE <NUM> for which the PDU session is being established. In other embodiments, the UPF <NUM> collects information on a per subscriber type basis and the NWDAF <NUM> generates a model of the computational footprint for PDU sessions based on the subscriber type of the UE <NUM> for which the PDU session is being established.

In addition to per subscriber and per subscriber type models, the UPF <NUM> may provide more granular information based on services associated with the PDU session. The computational footprint for a PDU session in this case is determined based on the types of service associated with the PDU session. Thus, in one embodiment, the NWDAF <NUM> may generate a footprint model for each service for each subscriber for which the PDU session is being established.

To implement the techniques, the UPF <NUM> is configured with a SBI denoted Nupf, in addition to the N4 interface with the SMF <NUM>, to enable the UPF <NUM> to communicate with other NFs in the 5GC <NUM>. The UPF <NUM> collects information related to packet inspection and makes this information available to other NFs via the exposure service. Information collected by the UPF <NUM> may include, for example, the following:.

This information is referred to herein as packet inspection parameters (PIPs). As noted above, the PIPs may collected on a per subscriber or per subscriber type basis. Additionally, the UPF <NUM> may PIPs for each service type.

To make the information available to other NFs, the UPF <NUM> registers its service offering with the NRF <NUM>. <FIG> illustrates a general procedure implemented by a NF (e.g., UPF <NUM>) to register the capability of providing per subscriber PIPs, also referred to herein as footprint data. The NF sends a registration request (Nnrf_NFManagement NFRegister_Request) to the NPF <NUM> over the Nnrf interface to register the capability of providing per subscriber footprint data to other NFs (<NUM>). The registration request includes a NF identifier, NF-ID and a list of PIPs available per subscriber. The registration request may optionally include a list of PIPs available per service. The NRF <NUM> answers with <NUM> OK to confirm the successful registration (<NUM>).

<FIG> illustrates a more detailed example of UPF registration with the NRF <NUM>. In this example, the UPF <NUM> registers the capability of providing per subscriber footprint data to other NFs. The UPF <NUM> sends a registration request (Nnrf_NFManagement NFRegister_Request) to the NPF <NUM> over the Nnrf interface to register the capability of providing PIPs to other NFs. The registration request includes a UPF identifier, UPF-ID and a list of PIPs available per subscriber. In this example, the list of PIPs includes the number of packets needed to be inspected and the SFs involved for the subscriber. The registration request may optionally include a list of PIPs available per service. This list includes the number of packets needed to be inspected and the SFs involved for the subscriber. The NRF <NUM> answers with <NUM> OK to confirm the successful registration (<NUM>). Those skilled in the art will appreciate that the list of PIPs can include other PIPs as listed above.

Once the UPF <NUM> registers with the NRF <NUM>, the NWDAF <NUM> can discover the exposure service offered by the UPF <NUM> and subscribe to the exposure service using the new Nupf interface. Thus, the NWDAF <NUM> may subscribe to receive footprint data from multiple UPFs <NUM> within the communication network <NUM>. Additionally, the NWDAF <NUM> can request or collect information from other NFs relevant to the calculation of a computational footprint for a PDU session. For example, the NWDAF <NUM> may collect information about traffic volumes associated with packet flows from the PCF <NUM>. Based on the information collected from the UPFs <NUM> and other NFs, the NWDAF <NUM> generates a model for the computational footprint for each subscriber or subscriber type and stores the computed computational footprint for each subscriber or subscriber type in the UDR <NUM>. The computational footprint can be stored by the UDR <NUM> as part of the subscriber profile.

<FIG> illustrates an exemplary procedure implement by the NWDAF <NUM> to collect footprint data and generate a computational footprint model. The NWDAF <NUM> sends a subscription request (Nupf_EventExposureSubscribe_Request) to the UPF <NUM> over the Nupf interface to subscribe to the Event Exposure service offered by the UPF <NUM> (<NUM>). The subscription request indicates the type of data requested (e.g., "footprint data") and the event trigger (e.g., subscriber/service) for the subscription. The UPF <NUM> answers with a <NUM> OK to confirm the subscription (<NUM>) or with an immediate response (Nupf_EventExposureSubscribe_Response) containing the requested information. When the event trigger is "subscriber", the subscription response includes the PIPs for each subscriber. When the event trigger is "service", the subscription response includes the PIPs for each subscriber. In the example shown in <FIG>, the PIPs included in the subscription response include the number of packets, number of PDRs, PDR depth, number of SFs and packet inspection time for each subscriber or service. Following the initial response, the UPF <NUM> may send a notification message to the NWDAF <NUM> periodically or in response to a triggering event for each subscriber or service. For example, the UPF <NUM> may collect footprint data during each PDU session and send the footprint data for the subscriber and/or service to the NWDAF <NUM> at the end of each PDU session.

Based on the footprint data collected from the UPFs <NUM> and other relevant information collected from other NFs, the NWDAF <NUM> generates a model of the computational resource demand in terms of CPU usage and memory usage and calculates the CPU footprint and memory footprint for each subscriber (<NUM>). The applied model may be a generic model applied to all subscribers or a subscriber-specific model. In some embodiments, the NWDAF <NUM> may also calculate the CPU footprint and memory footprint for each service type for each subscriber. The NWDAF <NUM> then sends a request to the UDR <NUM> to store the computed CPU footprint and the computed memory footprint for each subscriber and/or service to the UDR <NUM> (<NUM>). In embodiments where a subscriber-specific model is used, the UDR <NUM> can also store the model and related state variables.

As new data arrives from the UPFs <NUM> or other NFs, the NWDAF <NUM>, the NWDAF <NUM> can dynamically update the CPU footprints and memory footprints based on the new information. If a subscriber-specific model is used to generate the footprints, the NWDAF <NUM> can retrieve the model and related state variables from the UDR <NUM> and compute revised CPU and memory footprints based on the new data.

Once the computational footprints are stored In the UDR <NUM>, the computational footprints are available to the SMF <NUM> for use in selecting the UPF <NUM> for a PDU session. After receiving a request to create a PDU session for a subscriber, the SMF <NUM> can retrieve the CPU footprint and/or memory footprint for the subscriber and/or service from the UDR <NUM>. The SMF <NUM> can use the subscriber footprint along with other information to select the UPF <NUM>. For example, the SMF <NUM> may employ a strategy of evenly distributing PDU sessions with large CPU and memory footprints among the available UPFs <NUM>. As another example, the SMF <NUM> may have a group of preferred UPFs <NUM> for PDU sessions associated with large computational footprints.

<FIG> illustrates UPF selection based on per subscriber inspection complexity metrics. The UE <NUM> sends a Session Establishment Request to the AMF <NUM> (<NUM>). The AMF (<NUM>) selects a SMF <NUM> for the PDU session and sends a PDU Session Create Request to the selected SMF <NUM> (<NUM>, <NUM>). The SMF <NUM> sends a registration request to the UDR <NUM> and receives a registration response (<NUM>, <NUM>). Then the SMF <NUM> requests the subscription profile for the subscriber and list of services from the UDR <NUM> (<NUM>). The UDR <NUM> answers with the subscription profile that includes the CPU footprint and memory footprint for the subscriber and/or services associated with the PDU session (<NUM>). The SMF <NUM> selects the PCF <NUM> and establishes a policy control session (<NUM>-<NUM>). To establish the policy control session, the SMF <NUM> sends a Policy Control Create Request to the PCF <NUM> (<NUM>). The PCF <NUM> answers with a Policy Control Create Response that includes, among other things, the PDRs to be applied for packet flow classification (<NUM>). After the policy control session is established, the SMF <NUM> selects the UPF <NUM> for the PDU session (<NUM>). As previously describe, the UPF selection is based at least in part on the CPU footprint and/or memory footprint received from the UDR <NUM>. After selecting the UPF <NUM>, the SMF <NUM> sends a Packet Forwarding Control Protocol (PFCP) Session Establishment Request to the UPF <NUM> (<NUM>). The UPF <NUM> answers with a PFCP Session Establishment Response (<NUM>). The SMF <NUM> then sends a PDU Session Create Response to the AMF <NUM> (<NUM>). The AMF <NUM> sends a PDU Session Establishment Request Response to the UE <NUM> (<NUM>).

<FIG> illustrates an exemplary method <NUM> implemented by a UPF <NUM> for providing inspection complexity indicators used to compute inspection complexity metrics for UPF selection. The UPF <NUM> optionally registers, with a service discovery function (e.g., NRF <NUM>), a capability to provide one or more inspection parameters for packet data inspection (block <NUM>). The UPF <NUM> collects one or more inspection parameters associated with packet inspection for a subscriber, a service, or both, for determining a computational footprint associated with the packet inspection (block <NUM>). The UPF <NUM> sends the inspection parameters to another network node (e.g., NWDAF <NUM>) (block <NUM>).

In some embodiments of the method <NUM>, sending the inspection parameters to another network node comprises receiving a request for the inspection parameters from a consumer node, and sending, responsive to the request, the inspection parameters to the consumer node. The consumer node may comprise, for example a NWDAF <NUM> or other data analytics function. The inspection parameters may comprise, for example, one or more of an average number of packets inspected to classify a traffic flow, a number of packet detection rules (PDR) to apply to the traffic flow, an average number of PDRs applied to classify a traffic flow, a number of service functions to be traversed according to a policy, an average time needed to classify a traffic flow, or a type of analysis used for classifying the traffic flow.

In some embodiments of the method <NUM>, the inspection parameters comprise per subscriber inspection parameters for one or more subscribers.

In some embodiments of the method <NUM>, the inspection parameters comprise per service inspection parameters for one or more services.

In some embodiments of the method <NUM>, the inspection parameters comprise per service inspection parameters for each service for each of one or more subscribers.

In some embodiments of the method <NUM>, the inspection parameters comprise per subscriber type inspection parameters for each of one or more subscriber types.

<FIG> illustrates an exemplary method <NUM> implemented by a NWDAF <NUM> or other network node for computing a computational footprint for use in UPF selection. The NWDAF <NUM> receives one or more inspection parameters associated with packet inspection for a subscriber, a service, or both (block <NUM>). The NWDAF <NUM> further computes a computational footprint associated with packet inspection for the subscriber, the service, or both, based on the received packet inspection parameters (block <NUM>). Finally, the NWDAF <NUM> makes the computational footprint for the subscriber, the service, or both, available to a session management function or other network node for use in UPF selection (block <NUM>).

In some embodiments of the method <NUM>, receiving one or more inspection parameters associated with packet inspection for a subscriber, a service, or both comprise sending a service request for the inspection parameters to a producer node, and receiving the inspection parameters from the producer node responsive to the request. The producer node may comprise, for example, a UPF <NUM>. The inspection parameters may comprise, for example, one or more of an average number of packets inspected to classify a traffic flow, a number of packet detection rules (PDR) to apply to the traffic flow, an average number of PDRs applied to classify a traffic flow, a number of service functions to be traversed according to a policy, an average time needed to classify a traffic flow, or a type of analysis used for classifying the traffic flow.

In some embodiments of the method <NUM>, making the computational footprint for the subscriber, the service, or both, available to a session management function for use in UPF selection comprises storing the computational footprint in a data repository, such as a UDR <NUM>.

<FIG> illustrates an exemplary method <NUM> implemented by a SMF for selecting a UPF <NUM> based on inspection complexity metrics. The SMF <NUM> receives a request to create a packet data session for UE <NUM> (block <NUM>). Responsive to the request to create a packet data session, the SMF <NUM> obtains session management subscription data including a computational footprint indicative of the computational resources needed to perform packet inspection for one or more traffic flows included in the packet data session (block <NUM>). The SMF <NUM> then selects a UPF <NUM> for the packet data session based at least in part on the computational footprint for packet inspection (block <NUM>).

In some embodiments of the method <NUM>, obtaining the session management data comprises retrieving the session management data from a subscriber database.

In some embodiments of the method <NUM>, the computational footprint comprises a CPU demand, a memory demand, or both, associated with the user equipment.

In some embodiments of the method <NUM>, the computational footprint comprises a CPU demand, a memory demand, or both, for each of one or more services associated with the packet data session.

In some embodiments of the method <NUM>, the computational footprint comprises a CPU demand, a memory demand, or both, for each of one or more services associated with the packet data session for the UE.

<FIG> illustrates an exemplary UPF400 configured to provide inspection parameters used to compute computational footprints of packet flows for UPF selection. The UPF400 comprises an optional registering unit <NUM>, a collecting unit <NUM>, and a sending unit <NUM>. The various units <NUM> - <NUM> can be implemented by hardware and/or by software code that is executed by a processor or processing circuit. The registering unit <NUM>, when present, is configured to register, with a service discovery function, a capability to provide the one or more inspection parameters as an offered service. The collecting unit <NUM> is configured to collect one or more inspection parameters associated with packet inspection for a subscriber, a service, or both, for determining a computational footprint associated with the packet inspection. The sending unit <NUM> is configured to sending the inspection parameters to another network node.

<FIG> illustrates an exemplary NWDAF <NUM> configured to provide inspection complexity metrics for UPF selection. The NWDAF <NUM> comprises a receiving unit <NUM>, a computing unit <NUM> and a providing unit <NUM>. The various units <NUM> - <NUM> can be implemented by hardware and/or by software code that is executed by a processor or processing circuit. The receiving unit <NUM> is configured to receive one or more inspection parameters associated with packet inspection for a subscriber, a service, or both. The computing unit <NUM> is configured to compute a computational footprint associated with packet inspection for the subscriber, the service, or both, based on the received packet inspection parameters. The providing unit <NUM> is configured to make the computational footprint for the subscriber, the service, or both, available to a session management function for use in UPF selection.

<FIG> illustrates an exemplary SMF <NUM> configured to select a UPF based on inspection complexity metrics. The SMF <NUM> comprises a receiving unit <NUM>, an obtaining unit <NUM> and a selecting unit <NUM>. The various units <NUM> - <NUM> can be implemented by hardware and/or by software code that is executed by a processor or processing circuit. The receiving unit <NUM> is configured to receive a request to create a packet data session for a UE <NUM>. The obtaining unit <NUM> is configured to, responsive to the request to create a packet data session, obtain session management subscription data including a computational footprint indicative of the computational resources needed to perform packet inspection for one or more traffic flows included in the packet data session. The selecting unit <NUM> is configured to selecting a user plane function for the packet data session based at least in part on the computational footprint for packet inspection.

<FIG> illustrates the main functional components of a network node that can be configured as an exposing network node <NUM>, a producer network node <NUM>, a consumer network node <NUM>, or some combination thereof. The network node <NUM> comprises communication circuitry <NUM>, processing circuitry <NUM>, and memory <NUM>.

The communication circuitry <NUM> comprises network interface circuitry for communicating with other core network nodes in the communication network over a communication network, such as an Internet Protocol (IP) network.

Processing circuitry <NUM> controls the overall operation of the network node <NUM> and is configured to perform one or more of the methods <NUM>, <NUM>, <NUM> and <NUM> shown in <FIG> respectively. The processing circuitry <NUM> may comprise one or more microprocessors, hardware, firmware, or a combination thereof.

Memory <NUM> comprises both volatile and non-volatile memory for storing computer program code and data needed by the processing circuitry <NUM> for operation. Memory <NUM> may comprise any tangible, non-transitory computer-readable storage medium for storing data including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. Memory <NUM> stores a computer program <NUM> comprising executable instructions that configure the processing circuitry <NUM> to implement one or more of the methods <NUM>, <NUM>, and <NUM> shown in <FIG> respectively. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above. In general, computer program instructions and configuration information are stored in a non-volatile memory, such as a ROM, erasable programmable read only memory (EPROM) or flash memory. Temporary data generated during operation may be stored in a volatile memory, such as a random access memory (RAM). In some embodiments, computer program <NUM> for configuring the processing circuitry <NUM> as herein described may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program <NUM> may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Claim 1:
A method (<NUM>) implemented by a network data analytics function, NWDAF" (<NUM>, <NUM>, <NUM>) in a wireless communication network (<NUM>) to support selection of a user plane function, UPF, (<NUM>) by a session management function, SMF (<NUM>), for a packet data session, wherein the packet data session is to be created for a user equipment, UE, for one or more services for one or more subscribers, the SMF creates the packet data session for the UE, and the selected UPF performs packet inspection for one or more traffic flows included in the packet data session, the method (<NUM>) comprising:
receiving (<NUM>) one or more inspection parameters associated with packet inspection performed by a UPF for a subscriber, a service, or both;
computing (<NUM>) a computational footprint associated with packet inspection performed by the UPF for the subscriber, the service, or both, based on the received packet inspection parameters, wherein the computational footprint is indicative of the computational resources needed to perform packet inspection for the one or more traffic flows included in the packet data session; and
making (<NUM>) the computational footprint for the subscriber, the service, or both, available to a session management function for use in UPF selection.