WO2025172459A1 - Architecture extension for multi-site upf - Google Patents

Abstract

A method performed by a control plane (CP) of a network for enabling packet processing site selection by a packet processing site selector associated with a User Plane Function (UPF). The method comprises at least one of: transmitting, to the packet processing site selector, information comprising at least one site selection requirement; and receiving, from the packet processing site selector, an indication of a site selected by the packet processing site selector for performing packet processing for a communication session.

Description

ARCHITECTURE EXTENSION FOR MULTI-SITE UPF

TECHNICAL FIELD

[001] Disclosed are embodiments related to selection of a packet processing site within a User Plane Function (UPF).

BACKGROUND

[002] Standardization work is ongoing on Next Generation-Radio Access Node (NG-RAN) and 5^th Generation Core (5GC) as new radio access and new packet core network. See, 3GPP TS 23.501 and 3GPP TS 23.502, for stage-2 descriptions.

[003] FIGURE 1 illustrates 5^th Generation (5G) System architecture using a service-based representation and corresponds to Figure 4.2.3-1 of TS 23.501 vl8.1.0. The main related parts for this disclosure are User Plane Function (UPF) residing in the 5GC and (R)AN. The UPF is controlled by a Session Management Function (SMF) over N4-interface. The UPF is also connected to (R)AN over N3 -interface.

[004] FIGURE 2 illustrates non-roaming 5G system architecture in reference point representation and corresponds to Figure 4.2.3-2 of 3GPP TS 23.501 vl8.1.0. Note the N9 interface between UPFs in both figures. This means that two or more UPFs can be chained in different ways.

[005] FIGURE 3 illustrates the internal architecture for a gNodeB (gNB), which refers to a base station supporting New Radio (NR) Radio Access Technology (RAT) in the (R)AN of FIGURE 1 and 2, and which is called a NG-RAN herein. See 3GPP TS 38.401 for stage-2 description of NG- RAN. FIGURE 3 assumes that both Higher Layer Split (HLS) and Control Plane and User Plane split (CP -UP split) have been adopted within the gNB. The NG-RAN may also contain Long Term Evolution (LTE) ng-eNodeBs and HLS may later be supported also for ng-eNBs.

[006] HLS means that the gNB is divided into a Central Unit (CU) and a Distributed Unit (DU). CP -UP split further divides the CU into a CU Control Plane (CU-CP) and a CU User Plane (CU- UP), and this part is currently being standardized in 3GPP. The related study report is 3GPP TR 38.806.

[007] CU-CP hosts the Radio Resource Control (RRC) protocol and the Packet Data Convergence Protocol (PDCP) used for the CP part. CU-UP hosts the Service Data Adaptation Protocol (SDAP) protocol and the PDCP used for user plane (UP) part. CU-CP is controlling CU-UP via an El interface. Although not shown in FIGURE 3, the CU-CP is the function that terminates the N2 interface from the Access and Mobility Management Function (AMF) in 5^th Generation Core (5GC), and CU-UP is the function terminating the N3 interface from the UPF in 5GC (e.g., in relation to FIGURES 1 and 2). Logically, a UE has one CU-UP per Protocol Data Unit (PDU) session. Other terms used for N2 and N3 interfaces in 3GPP are NG-C and NG-U, respectively.

[008] FIGURE 4 illustrates the baseline architectures with a single UPF. FIGURE 4 is a combined view of FIGURES 1, 2, and 3, but only shows the main functions in the 5GC for AMF, SMF and UPF(s). FIGURE 4 uses the reference point representation from 3GPP TS 23.501 for the interface between AMF and SMF as Ni l interface. The Ni l interface is used as an example only in the overall architecture figures. The Ni l interface can also be realized using service-based interfaces exhibited by AMF and SMF, which are Namf and Nsmf respectively.

[009] FIGURE 5 illustrates current techniques for PDU session establishment in 5G for performing UPF selection in 5GC and NG-RAN (i.e., 5GC UPF and NG-RAN CU-U selection). In the example of FIGURE 5, NG User Equipment (UE) requests PDU Session establishment. The signalling flow in FIGURE 5 is exemplary only and shows only the main parts related to the disclosure herein.

[0010] The main highlights of FIGURE 5 are that the UPF function is first selected by the SMF in 5GC (step 6). The SMF then provides information about the selected UPF (UPF Transport Address and TEID) to the CU-CP (steps 9-10) that performs CU-UP selection (step 11) and configures the selected CU-UP with the information received from SMF about the selected UPF (step 12). The CU-CP then provides information about the selected CU-UP (CU-UP Transport Address and TEID) to the SMF (steps 15-16) that configures the UPF with the received information (step 17) to finalize the N3 interface establishment for a PDU session (step 18).

[0011] The main characteristics shown in FIGURE 5 are that the UPF and CU-UP are selected independently of each other and that these functions are also configured using separate interfaces. For example, UPF is configured by the SMF using N4 interface, and CU-UP is configured by the CU-CP using the El interface. FIGURE 5 relates to the case of a single UPF function selected by the SMF. The SMF may also select multiple UPFs connected via N9 interface.

[0012] When a UE moves, a handover procedure is performed, which also allows to update the UP path towards the new RAN to which the UE is connected. FIGURES 6A-6B illustrate the case of Xn handover in 5G. Specifically, FIGURE 6A illustrates details on the interaction between source and target RAN nodes as related to 3GPP TS 38.300. FIGURE 6B illustrates details on the interaction between target RAN and CN NFs as related to 3GPP TS 23.502.

[0013] Update of user plane path is triggered by the target RAN sending a Path Switch Request to the AMF (containing also AN Tunnel Info for each PDU Session to be switched), which then triggers a PDU Session Update towards the SMF. As part of the PDU Session Update, the SMF communicates to the UPF the new AN Tunnel Info, which allows to update the downlink path from the UPF towards the target gNB.

[0014] One aspect to note is that, discussing about enhancements of system architecture towards 6G, there could be other approaches to update the user plane path when a UE changes RAN. For instance, discussions as in [1] for instance showed that target RAN could directly interact with a session-management Network Function to update the user plane path.

[0015] Another approach to update downlink routing is sending a direct “in-band” signalling message (or specially crafted packet) from the gNB to the UPF in order to reduce AMF/SMF load and path switch latency. It would also remove dependencies on the AMF/SMF - data plane relocations would work even if the AMF/SMF is temporarily unavailable. FIGURE 7 illustrates a signalling chart that depicts changes in the data path using in-band switch messages. It is noted that the AMF and SMF(s) are not involved. These alternatives are more revolutionary than legacy approaches, but it is expected that similar solutions are to be discussion in 6G standardization.

[0016] There currently exist certain challenge(s), however. For example, it is currently assumed that the UPF site selection is made by the SMF. This requires topology knowledge in the SMF. This is somewhat impractical as the routing topology could change based on network and routing re-configuration or due to link and node failures. Besides, the UPF selection could depend also on other, dynamic network information, like UPF load, edge-to-edge latencies, etc., and all of this information needs be conveyed to the selection logic in SMF in order to be considered. This could result in a large volume of information flow to the SMF for certain use cases such as, for example, when there is a need for fine-grained dynamic UP knowledge by the SMF. Even in that case, the selection may be based on outdated UP information.

[0017] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. SUMMARY

[0018] For example, methods and apparatus are provided for enabling site selection outside of the SMF, for example, enabling the UP to perform site selection.

[0019] In one aspect, there is provided a method performed by a control plane (CP) of a network for enabling packet processing site selection by a packet processing site selector associated with a User Plane Function (UPF). The method comprises at least one of: transmitting, to the packet processing site selector, information comprising at least one site selection requirement; and receiving, from the packet processing site selector, an indication of a site selected by the packet processing site selector for performing packet processing for a communication session.

[0020] The UPF may comprise the associated packet processing site selector. The packet processing site selector may be logically or geographically in the associated User Plane Function (UPF).

[0021] The packet processing site selector may be separated from and in communication with the associated User Plane Function (UPF).

[0022] The method may further comprise transmitting, to the base station, the indication of the site selected in order to establish a PDU Session.

[0023] The method may be performed by a Session Management Function (SMF) of the CP.

[0024] The at least one site selection requirement may be transmitted to the packet processing site selector in a PDU Session setup request. The at least one site selection requirement may be transmitted to the packet processing site selector in a N4 Session Establishment or Modification request. The at least one site selection requirement may be transmitted to the packet processing site selector via a N4 interface.

[0025] The UPF may be a multi-site UPF comprising a plurality of Packet Processors, PP, with at least one PP per PP site. The PPs may be for performing UPF packet processing. The packet processing site selector may be in communication with at least one of the plurality of PPs. The packet processing site selector may be in communication with each of the plurality of PP.

[0026] The SMF may have no knowledge of the plurality of PP for performing UPF packet processing.

[0027] The SMF may have different information than the packet processing site selector relating to user plane, UP, network topology. For example, the SMF may have less information than the packet processing site selector relating to UP network topology. The SMF may have coarse-grained topology information and the packet processing site selector may have fine-grained topology information.

[0028] The indication of the site selected by the packet processing site selector may comprise at least one of: an indication of a particular one of the plurality of PPs selected by the packet processing site selector for performing packet processing for the communication session, and tunnel endpoint information for the selected one of the plurality of PPs.

[0029] The method may further comprise obtaining capability information associated with the UPF and/or packet processing site selector. The capability information may indicate an ability of the packet processing site selector to perform the site selection.

[0030] The capability information may be pre-configured in the network Control Plane (CP). The capability information may be obtained and/or received from a Network Repository Function (NRF). The capability information may be obtained and/or received when the network CP establishes an association with the UPF and/or packet processing site selector.

[0031] The at least one site selection requirement may be transmitted to the packet processing site selector based on the capability information.

[0032] The at least one site selection requirement may comprise at least one of: at least one UPF2RAN latency requirement; at least one latency budget and/or RAN budget; at least one transport budget; and at least one UPF budget. The UPF2RAN latency requirement is the maximum time delay for transmissions between a UPF and the RAN, including any required N9 interfaces between UPFs. The latency budget is the maximum time delay for transmissions between the UE and the UPF (via the RAN), including any required N9 interfaces between UPFs. The RAN budget is the maximum time delay for transmissions between the UE and the RAN. The transport budget is the maximum time delay for transmissions over the N3 interface i.e. between RAN transmission and UPF reception. The UPF budget is the maximum time delay for transmissions over the N9 interface i.e. between transmission at a UPF and reception at a different UPF.

[0033] The method may further comprise transmitting, to the packet processing site selector, UE location information associated with the communication session.

[0034] The method may further comprise at least one of: receiving, from the packet processing site selector, an indication of a changed RAN UP (e.g., CU-UP), and transmitting, to the packet processing site selector, an indication of a changed RAN UP (e.g., CU-UP). [0035] The method may further comprise receiving, from the packet processing site selector, information indicating a violation of at least one site selection requirement.

[0036] The method may further comprise, based on the information indicating the violation of the at least one site selection requirement, initiating a PDU Session reestablishment with a UE for the communication session.

[0037] The SMF and the UPF may be associated with a core network and/or at least one core network node.

[0038] In another aspect there is provided a method performed by a packet processing site selector associated with a user plane function (UPF) of a network for enabling site selection. The method comprises at least one of: receiving, from a control plane (CP), information comprising at least one site selection requirement; selecting a site from a plurality of sites for performing packet processing for a communication session; and transmitting, to at least one of the CP and the selected site, an indication of the site selected for performing the packet processing for the communication session.

[0039] Corresponding embodiments for the previous aspect are also applicable to this aspect.

[0040] The transmission of the indication of the site selected may be for the CP to establish a PDU Session based on the selected site.

[0041] The site may be selected from the plurality of sites based on at least one of: the at least one site selection requirement received from the CP; a user plane (UP) network topology; dynamic information associated with the UP; at least one site selection policy; and load information indicating a respective load of each site in the plurality of sites.

[0042] The CP may comprise a Session Management Function (SMF). The at least one site selection requirement may be received from the SMF. The indication of the site selected for performing the packet processing may be sent to the SMF.

[0043] The at least one site selection requirement may be received in a PDU Session setup request. The at least one site selection requirement may be received in a N4 Session Establishment or Modification request. The at least one site selection requirement may be received via a N4 interface.

[0044] The SMF may have no knowledge of the network topology including the plurality of PPs for performing UPF packet processing. The SMF may have no knowledge of the plurality of PPs for performing UPF packet processing. [0045] The method may further comprise transmitting, to the CP, capability information associated with the UPF and/or packet processing site selector. The capability information may indicate an ability of the packet processing site selector to perform the site selection.

[0046] The capability information may be transmitted when the UPF and/or packet processing site selector establishes an association with the CP and/or the network.

[0047] The at least one site selection requirement may be received from the CP in response to and/or based on and/or after the capability information is transmitted to the CP.

[0048] The method may further comprise receiving, from the CP, UE location information associated with the communication session.

[0049] The method may further comprise at least one of: obtaining information indicating and/or determining a changed RAN UP (e.g., CU-UP); receiving, from the selected site, an indication of a changed RAN UP (e.g., CU-UP); transmitting, to the CP, an indication of a changed RAN UP (e.g., CU-UP), and receiving, from the CP, an indication of a changed RAN UP (e.g., CU-UP).

[0050] The method may further comprise at least one of: determining a violation of the at least one site selection requirement, obtaining information indicating a violation of the at least one site selection requirement, and receiving, from the selected site, information indicating a violation of the at least one site selection requirement.

[0051] The violation of the at least one site selection requirement may be based on at least one of: a changed RAN UP (e.g., CU-CP) and a handover of a UE associated with the communication session to a new CU-CP.

[0052] The method may further comprise transmitting, to the CP, information indicating the violation of the at least one site selection requirement.

[0053] In another aspect there is provided a network node comprising processing circuitry configured to perform any of the methods disclosed herein. For example, the network node may be a UPF or an SMF.

[0054] In another aspect there is provided a computer program comprising instructions which when executed on a computer perform any of the methods disclosed herein.

[0055] In another aspect there is provided a non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods disclosed herein.

[0056] For example, a large, multi-site UPF is proposed to include Packet Processors (PP) to perform UPF packet processing. In particular embodiments, the PPs may include server blades, Virtual Machines (VMs), and/or Containers with selection logic (as part of or separate to the UPF) to select PPs across a large (multi-site) topological domain based on available network topology and other dynamic user plane information. According to certain embodiments, this UPF capability (and the area it serves) is made known to the SMF. The SMF will convey the UPF2RAN latency requirement and other potential selection requirement to the multi-site UPF, enabling the UPF to select a proper PP to handle a PDU Session.

[0057] Certain embodiments may provide one or more of the following technical advantage(s). For example, certain embodiments may provide a technical advantage of providing multi-site UPFs with capability of performing site selection itself. This may make sense in some cases such as where the CN Packet Processing is otherwise very distributed.

[0058] As another example, certain embodiments may provide a technical advantage of enabling the UP to perform site selection based on network topology and other intrinsic dynamic information, resulting in a more efficient selection mechanism.

[0059] As still another example, certain embodiments may provide a technical advantage of potentially enabling offloading CN CP of certain parts of the network topology, and other dynamic UPF selection related information. The UP may have automated mechanisms to infer network topology (including dynamic topology changes), and thus have simpler and more up-to-date information than the CP. The interfaces to transfer topology information to CN CP are also spared. [0060] As yet another example, certain embodiments may provide a technical advantage of providing PP selection while enabling load balancing. For example, the UPF may have first-hand information about the load situation in the topology domain, based on which it can load balance across multiple sites using vendor-specific load distribution mechanisms, resulting in more efficient load balancing. Again, certain embodiments provide a technical advantage of sparing the load information transfer to the CP.

[0061] As yet another example, certain embodiments may provide a technical advantage of not requiring PPs to support the multi-vendor interface N4.

[0062] As still another example, certain embodiments may provide a technical advantage since the PP selection may be the first to be notified about UP changes (e.g., at handovers, if UP -based location update procedures are applied), and in this case, the UP may infer potential violation on the session requirements in the first place and notify the CP. [0063] Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

[0064] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0065] FIGURE 1 illustrates 5th Generation (5G) system architecture.

[0066] FIGURE 2 illustrates non-roaming 5G system architecture.

[0067] FIGURE 3 illustrates example internal architecture of a gNodeB (gNB).

[0068] FIGURE 4 illustrates a portion of the 5G system architecture.

[0069] FIGURE 5 is a signalling diagram illustrating an example PDU session establishment procedure in 5G.

[0070] FIGURE 6A-6B are signalling diagrams illustrating an example Xn handover in 5G.

[0071] FIGURE 7 is a signalling diagram illustrating example changes in the data path using in-band switch messages.

[0072] FIGURE 8A-8C illustrates changes in system architecture according to certain embodiments.

[0073] FIGURE 9 illustrates changes in network topology according to certain embodiments.

[0074] FIGURE 10 illustrates changes in the distribution of topology information according to certain embodiments.

[0075] FIGURE 11 is a signalling diagram illustrating example changes to the PDU session establishment procedure of FIGURE 5.

[0076] FIGURE 12 is a signalling diagram illustrating a UP Update notification according to certain embodiments.

[0077] FIGURE 13 is another signalling diagram illustrating a UP Update notification according to certain embodiments. [0078] FIGURE 14 shows an example of a communication system QQ100 in accordance with some embodiments.

[0079] FIGURE 15 shows a UE QQ200, which may be an embodiment of the UE 112 of FIGURE 13, in accordance with some embodiments.

[0080] FIGURE 16 shows a network node QQ300 in accordance with some embodiments.

[0081] FIGURE 17 is a block diagram illustrating a virtualization environment QQ500 in which functions implemented by some embodiments may be virtualized.

[0082] FIGURE 18 illustrates an example method by a CP of a network for enabling packet processing site selection by a UPF, according to certain embodiments.

[0083] FIGURE 19 illustrates an example method by a UPF of a network for enabling site selection, according to certain embodiments.

[0084] FIGURE 20 is a signalling diagram illustrating an Xn based inter NG-RAN handover with insertion of intermediate UPF as discussed in 3GPP TS 23.502 vl8.1.0.

[0085] FIGURE 21 is a signalling diagram illustrating a change of SSC mode 2 PSA for a Protocol Data Unit (PDU) Session as disclosed in 3GPP TS 23.502 vl8.1.0.

[0086] FIGURE 22 is a signalling diagram illustrating a change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions as discussed in 3GPP TS 23.502 vl8.1.0.

[0087] FIGURE 23 illustrates an example method according to certain embodiments.

[0088] FIGURE 24 is a signalling diagram illustrating an example UP -based mechanism for performing handover with I-PP insertion by the UPF, according to certain embodiments.

[0089] FIGURE 25 is a signalling diagram illustrating an example handover procedure with packet switch anchor changes by the UPF, according to certain embodiments.

[0090] FIGURE 26 illustrates an example method by a UPF for UP path change, according to certain embodiments.

[0091] FIGURE 27 illustrates an example method by a RAN for UP path change, according to certain embodiments. [0092] FIGURE 28 illustrates an example method for UP path change by a CN CP, according to certain embodiments.

DETAILED DESCRIPTION

[0093] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0094] As used herein, ‘node’ can be a network node or a UE. Examples of network nodes are NodeB, base station (BS), multi -standard radio (MSR) radio node such as MSR BS, eNodeB (eNB), gNodeB (gNB), Master eNB (MeNB), Secondary eNB (SeNB), integrated access backhaul (IAB) node, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), Central Unit (e.g. in a gNB), Distributed Unit (e.g. in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), core network node (e.g. Mobile Switching Center (MSC), Mobility Management Entity (MME), etc.), Operations & Maintenance (O&M), Operations Support System (OSS), Self Organizing Network (SON), positioning node (e.g. E- SMLC), etc. The terms network node and radio network node are used interchangeably herein.

[0095] Another example of a node is user equipment (UE), which is a non-limiting term and refers to any type of wireless device communicating with a network node and/or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, vehicular to vehicular (V2V), machine type UE, MTC UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), Tablet, mobile terminals, smart phone, laptop embedded equipment (LEE), laptop mounted equipment (LME), Unified Serial Bus (USB) dongles, etc.

[0096] The term radio access technology (RAT), may refer to any RAT such as, for example, Universal Terrestrial Radio Access Network (UTRA), Evolved Universal Terrestrial Radio Access Network (E-UTRA), narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT, NR, 4G, 5G, etc. Any of the equipment denoted by the terms node, network node or radio network node may be capable of supporting a single or multiple RATs. [0097] The term signal or radio signal used herein can be any physical signal or physical channel. Examples of downlink (DL) physical signals are reference signal (RS) such as Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), Channel State Information-Reference Signal (CSI-RS), Demodulation Reference Signal (DMRS) signals in SS/PBCH block (SSB), discovery reference signal (DRS), Cell Specific Reference Signal (CRS), Positioning Reference Signal (PRS), etc. RS may be periodic. For example, RS occasions carrying one or more RSs may occur with certain periodicity (e.g., 20 ms, 40 ms, etc.). The RS may also be aperiodic.

[0098] Each SSB carries New Radio-Primary Synchronization Signal (NR-PSS), New RadioSecondary Synchronization Signal (NR-SSS) and New Radio-Physical Broadcast Channel (NR- PBCH) in four successive symbols. One or multiple Synchronization Signal Blocks (SSBs) are transmitted in one SSB burst which is repeated with certain periodicity such as, for example, 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms. The UE is configured with information about SSB on cells of certain carrier frequency by one or more SS/PBCH block measurement timing configuration (SMTC) configurations. The SMTC configuration comprising parameters such as SMTC periodicity, SMTC occasion length in time or duration, SMTC time offset with regard to reference time (e.g., serving cell’s SFN) etc. Therefore, SMTC occasion may also occur with certain periodicity (e.g., 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms). Examples of uplink (UL) physical signals are reference signals such as Sounding Reference Signals (SRS), Demodulation Reference Signals (DMRS), etc. The term physical channel refers to any channel carrying higher layer information e.g. data, control etc. Examples of physical channels are Physical Broadcast Channel (PBCH), Physical Downlink Control Channel (PDCCH), Physical Downlink Shared Channel (PDSCH), Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel (PUCCH), Physical Uplink Shared Channel (PUSCH), Short PUSCH (sPUCCH), Short PDSCH (sPDSCH), Short PUCCH (sPUCCH), Short PUSCH (sPUSCH), MTC PDCCH (MPDCCH), Narrowband PBCH (NPBCH), Narrowband PDCCH (NPDCCH), Narrowband PDSCH (NPDSCH), Narrowband PUSCH (NPUSCH), Enhanced PDCCH (E-PDCCH), etc.

[0099] The term time resource used herein may correspond to any type of physical resource or radio resource expressed in terms of length of time. Examples of time resources are symbol, time slot, subframe, radio frame, transmission time interval (TTI), interleaving time, slot, sub-slot, minislot, system frame number (SFN) cycle, hyper-SFN (H-SFN) cycle, etc. [00100] According to certain embodiments, methods and systems are provided for enabling the UP to perform site selection. For example, in various particular embodiments, a large, multi-site UPF is proposed to include PP to perform UPF packet processing. In particular embodiments, the PPs may include server blades, VMs, and/or Containers with selection logic to select PPs across a large (multi-site) topological domain based on available network topology and other dynamic user plane information. According to certain embodiments, this UPF capability (and the area it serves) is made known to the SMF. The SMF will convey the UPF2RAN latency requirement and other potential selection requirement to the multi-site UPF, enabling the UPF to select a proper PP to handle a PDU Session.

[00101] The UPF may comprise multiple Packet Processors (PPs). The PPs may each be located in different sites or there may be multiple PPs per site. The PPs may be located in at least two sites. Each PPs may perform the functions of a UPF for its designated site, but the SMF may only see the UPF rather than the individual PPs. For example, the SMF may not receive the location of the PP sites, for example, only the UPF would know the location of the PP sites. This may also apply to other information of the PP, such as latency information.

[00102] In an example, according to certain embodiments, a method for enabling site selection by the UP may include at least one of:

1) obtaining, by the CN CP (i.e., SMF), an indication related to multi-site selection capability in the UPF;

2) based on the obtained indication, sending by the CN CP, site selection related requirements to the UPF at PDU Session (N4) Setup;

3) selecting, by the UPF, at PDU Session (N4) Setup, a PP function for handling the UP traffic for the PDU Session, based on the available topology and dynamic UP knowledge, received site selection related requirements and other, pre-configured PP selection policies;

4) receiving by the UPF, an indication of changed RAN UP (CU-UP); and

5) based on the indication, sending a notification to the CN CP.

[00103] In a particular embodiment, the indication is pre-configured in the CN CP.

[00104] In a particular embodiment, the indication is obtained from a Network Repository Function (NRF). [00105] In a particular embodiment, the indication is obtained by the CN CP when establishing an association with the UPF.

[00106] In a particular embodiment, where RAN2UPF latency is one of the site selection related requirements, the CN CP sends an indication about the UE location on the topology to the UPF.

[00107] In a particular embodiment, the indication of changed RAN UP may be initiated from either/both the CN CP (SMF) or the RAN UP itself, i.e., via an UP -internal location update message.

[00108] In a particular embodiment, the indication of changed RAN UP is conveyed by the PP function currently handling the traffic of the PDU Session.

[00109] In a particular embodiment, the notification to the CN CP includes information about the violation of at least one site selection requirement (such as, for example, RAN2UPF latency) that was previously received from the CN CP.

[00110] The UPF itself may perform the site selection, for example, it may comprise a selection entity or selection logic to perform the packet processing site selection and may communicate with the SMF.

[00111] Alternatively, a selection entity external to the UPF may perform the packet processing site selection and may communicate with the SMF. The selection entity may be logically or geographically external to the UPF. The selection entity may not be in the SMF. The selection entity may be associated with only one UPF or may be associated with a plurality of UPFs. For example, the selection entity may be in communication with the UPF(s). The selection entity may comprise selection logic. The selection entity may select a site for performing packet processing in the UPF. The selection entity may be in communication with the plurality of PPs in the associated UPF(s). The selection entity may receive information from the UPF or PPs, for example, location information, availability, policies, topology, latency, or any other dynamic UP related information or site selection related requirements. The SMF may communicate with the selection entity via the N4 interface or via a separate interface. The SMF may communicate with the UPF via the selection entity. The selection entity may direct the SMF to the correct PP or UPF. The SMF may communicate with the external PP site selector in the same way it communicates with the UPF. The SMF may have no knowledge that the external PP site selector is not the UPF. The SMF may still select a UPF but may communicate with the external selection entity associated with the selected UPF. Once a PP is selected, the SMF may communicate directly with the UPF or PP or may still communicate via the PP selector. Thus, where the PP selector or PP selection is mentioned throughout this application and is described as being a part of the UPF, the PP selector may instead be in an entity outside the UPF.

[00112] FIGURE 8A-8C illustrates an example illustration of certain proposed solutions, techniques, and embodiments disclosed herein as compared to the current solutions in the 3GPP 5GC architecture, according to certain embodiments. Specifically, FIGURE 8A shows the current 3GPP 5GC architecture solution, where the UP topology (e.g., site-level) is known by the SMF (i.e., all individual logical UP entities and site mappings). By contrast, FIGURE 8B shows an enhanced architecture that enables PP selection by the UPF, according to certain embodiments. More specifically, as proposed in FIGURE 8B, the CN CP (SMF) sees/has knowledge of large (multi-site) UPFs and makes the UPF selection based on a coarse-grained topology information. Site & packet processor selection is then made by a PP selection logic in this large UPF based on fine-grained topology, latency, and other dynamic UP related information. FIGURE 8C shows a similar architecture to FIGURE 8B, however the PP selection is outside of the UPF. The CN CP communicates with the PP Site Selector, which communicates with one or more UPF. In this architecture, the PP Selector may look like a UPF to the SMF i.e. the SMF may believe the PP Selector is a UPF. Moreover, the SMF may use the N4 interface, or an extended N4’ interface, to configure the PP Selector. The PP Selector may still look like an SMF to the UPF it is in communication with. The PP Selector may act like an SMF to select a UPF/PP Site to configure. The PP Selector may configure the UPF over an N4 interface.

[00113] FIGURE 9 illustrates an example network topology view of certain proposed solutions, techniques, and embodiments disclosed herein, as compared to the current network topology provided in the current 3GPP 5GC architecture, according to certain embodiments. More specifically, the left side of FIGURE 9 illustrates the current network topology provided in the current 3GPP 5GC architecture. The right side of FIGURE 9 illustrates an example network topology view of certain proposed solutions, techniques, and embodiments enabling PP selection by the UP, according to certain embodiments. The UPFs may serve separate areas or may serve partially overlapping areas. Where the UPFs serve separate areas, the CN CP (e.g. SMF) may not require any indication of coverage area/topology in order to select the UPF. Where the UPFs serve partially overlapping areas, the CN CP may select between the different UPFs covering the area where the UE is located. Hence the CN CP may have to have somewhat more detailed, still coarse- grained, knowledge of the topology. This knowledge could, e.g., be based on "pre-configuration" or obtained by the CN CP when establishing an association with the UPF. The CN CP may receive an indication related to multi-site selection capability which may be a multi-site selection indication and/or a coverage area indication. Based on the obtained coverage area indication, the CN CP may select one of the UPFs having multi-site selection capability serving the area where the UE is located. The CN CP may select the UPF where the UE can move the farthest away from its current location without having to change UPF. The CN CP may select the UPF that matches the necessary capability needed for the PDU Session, e.g., maximum RAN2UPF latency provided by the UPF. The maximum RAN2UPF latency provided by the UPF may be pre-configured in the CN CP. The maximum RAN2UPF latency provided by the UPF may be obtained from a Network Repository Function (NRF). The maximum RAN2UPF latency provided by the UPF may be obtained by the CN CP when establishing an association with the UPF.

[00114] The differences in the current and proposed network are further highlighted in FIGURE 10, which illustrates how latency enforcement and site selection happens, according to certain embodiments. In a particular embodiment, the assumption is that this is a PDU session for latencysensitive traffic, where the latency is specified. The left side of FIGURE 10 illustrates the assumption based on the current 3GPP 5GC architecture (i.e., the legacy case), in which the SMF calculates the latency budget (i.e., RAN, transport, UPF) and it informs CU-CP about the RAN budget and selects a UPF (site) that fits into the remaining budget. By contrast, the right side of FIGURE 10 illustrates the assumption based on certain proposed solutions, techniques, and embodiments disclosed herein, where the CN CP (e.g. SMF) sends the transport and UPF budget to the multi-site UPF, thus allowing and/or enabling and/or relying on the UPF (PP selecting) to select the proper PP.

[00115] Example embodiments are described below for updating the existing/current procedures to enable multi-site UPFs.

[00116] PDU Session Establishment

[00117] FIGURE 11 illustrates the proposed modifications for an example PDU Session establishment procedure with multi-site UPF, according to certain embodiments.

[00118] As compared with the current standards solutions (previously described with regard to FIGURE 5), the proposed modifications shown in FIGURE 11 are as follows: 1) Step 7: When the SMF infers that the UPF has multi-site capability (by one of the methods listed herein), in the N4 Session Establishment or Modification request, the SMF sends the DU site to the UPF (the PP Selector) and also the selection criteria, e.g., RAN2UPF latency.

2) Step 7a: Based on the received information, and also other available information, like the load of different PP, the PP Selector in the UPF selects the appropriate PP.

3) Step 8: The PP Selector sends back information related to the selected PP (like the tunnel endpoint information), and the PP Selector also informs the SMF whether the selection criteria are met.

[00119] UP Path Changes

[00120] UP path changes due to, e.g., handovers, could result in KPI degradations due to a longer or a congested UP path. In the multi-site UPF case, the SMF does not have fine-granular topology knowledge, so it should rely on a notification by the UPF if the session criteria are no longer fulfilled.

[00121] In a particular embodiment (i.e., special case), only the PP selection knows about UP changes such as, for example, if UP -internal location update procedures are applied, as shown in FIGURE 7 discussed above. In this scenario, it is only the UPF that can infer potential violation on the session requirements in the first place and notify the CP.

[00122] FIGURE 12 illustrates a proposed UP Update notification by the multi-site UPF, according to certain embodiments. The proposed UP update notification is for both scenarios. As illustrated, the PP currently serving the PDU session (source PP) sends a notification to the PP selector (Step 2), which checks the session requirements. The PP selector issues an UP update notification message to the CN CP (SMF, Step 4) in which it may specify the new RAN UP used for the session as well as whether some requirements (e.g., latency) are not fulfilled on the new path. Based on the received notification, the SMF decides whether to initiate a PDU Session reestablishment to the UE (Step 6). During the re-establishment of the session, the PP selector is able to select a new, more appropriate PP (Target PP), as described in FIGURE 11, to fulfil the PDU Session requirements.

[00123] FIGURE 13 illustrates another proposed UP Update notification by the multi-site UPF, according to certain embodiments. The proposed UP update notification is also for both scenarios. Steps 1 to 4 may be the same as described in FIGURE 12. Then, based on the received notification, the SMF may decide to

1) Modify the associated requirements in RAN (Step 6), e.g. modify certain QoS parameters.

2) Initiate a PDU Session re-establishment to the UE (Steps 7-8).

3) Alternatively, the SMF may decide to modify the PDU Session and thus initiates a N4 session modification procedure towards the UPF (Step 9). During the reestablishment or modification of the session, the PP selector would be able to select a new, more appropriate PP (Target PP) as described in FIGURE 11, to fulfil the PDU Session requirements. In the case of N4 session modification, the Target PP issues an UP internal location update towards the Target RAN UP to re-establish the connection (Step 11). The Target PP also provides a new IP address to the UE using a IPv6 Neighbor Discovery Protocol's (NDP, RFC 4861) Router Advertisement message (Step 12).

[00124] FIGURE 14 shows an example of a communication system QQ100 in accordance with some embodiments. In the example, the communication system QQ100 includes a telecommunication network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may be generally referred to as network nodes QQ110), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections.

[00125] Moreover, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunications network QQ102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a network node in the telecommunications network QQ102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other network nodes to implement one or more functionalities of any network node in the telecommunications network QQ102, including one or more access network nodes QQ110 and/or core network nodes QQ108.

[00126] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). An ORAN network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN network node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies.

[00127] Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system QQ100 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

[00128] The UEs QQ112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes QQ110 and other communication devices. Similarly, the network nodes QQ110 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs QQ112 and/or with other network nodes or equipment in the telecommunication network QQ102 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network QQ102.

[00129] In the depicted example, the core network QQ106 connects the network nodes QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one more core network nodes (e.g., core network node QQ108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node QQ108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

[00130] The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ104 and/or the telecommunication network QQ102, and may be operated by the service provider or on behalf of the service provider. The host QQ116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[00131] As a whole, the communication system QQ100 of FIGURE 14 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[00132] In some examples, the telecommunication network QQ102 is a cellular network that implements 3 GPP standardized features. Accordingly, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network QQ102. For example, the telecommunications network QQ102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs.

[00133] In some examples, the UEs QQ112 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. Additionally, a UE may be configured for operating in single- or multi -RAT or multi -standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[00134] In the example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and/or QQ112d) and network nodes (e.g., network node QQl lOb). In some examples, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes QQ110, or by executable code, script, process, or other instructions in the hub QQ114. As another example, the hub QQ114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub QQ114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub QQ114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub QQ114 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub QQ114 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

[00135] The hub QQ114 may have a constant/persistent or intermittent connection to the network node QQl lOb. The hub QQ114 may also allow for a different communication scheme and/or schedule between the hub QQ114 and UEs (e.g., UE QQ112c and/or QQ112d), and between the hub QQ114 and the core network QQ106. In other examples, the hub QQ114 is connected to the core network QQ106 and/or one or more UEs via a wired connection. Moreover, the hub QQ114 may be configured to connect to an M2M service provider over the access network QQ104 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes QQ110 while still connected via the hub QQ114 via a wired or wireless connection. In some embodiments, the hub QQ114 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node QQl lOb. In other embodiments, the hub QQ114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node QQ110b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

[00136] FIGURE 15 shows a UE QQ200, which may be an embodiment of the UE 112 of FIGURE 14, in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

[00137] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), orvehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and/or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[00138] The UE QQ200 includes processing circuitry QQ202 that is operatively coupled via a bus QQ204 to an input/output interface QQ206, a power source QQ208, a memory QQ210, a communication interface QQ212, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIGURE 15. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[00139] The processing circuitry QQ202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory QQ210. The processing circuitry QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry QQ202 may include multiple central processing units (CPUs).

[00140] In the example, the input/output interface QQ206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE QQ200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[00141] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source QQ208 may further include power circuitry for delivering power from the power source QQ208 itself, and/or an external power source, to the various parts of the UE QQ200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source QQ208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source QQ208 to make the power suitable for the respective components of the UE QQ200 to which power is supplied.

[00142] The memory QQ210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ216. The memory QQ210 may store, for use by the UE QQ200, any of a variety of various operating systems or combinations of operating systems.

[00143] The memory QQ210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and/or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory QQ210 may allow the UE QQ200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory QQ210, which may be or comprise a device-readable storage medium.

[00144] The processing circuitry QQ202 may be configured to communicate with an access network or other network using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter QQ218 and/or a receiver QQ220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[00145] In the illustrated embodiment, communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol/internet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth. [00146] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface QQ212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient). [00147] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[00148] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or itemtracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and/or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE QQ200 shown in FIGURE 15.

[00149] As yet another specific example, in an loT scenario, a UE 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 UE and/or a network node. The UE may in this case be an M2M device, which may in a 3 GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3 GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

[00150] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[00151] FIGURE 16 shows a network node QQ300, which may be an embodiment of the network node QQ110 of FIGURE 14, in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)).

[00152] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). [00153] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs).

[00154] The network node QQ300 includes a processing circuitry QQ302, a memory QQ304, a communication interface QQ306, and a power source QQ308. The network node QQ300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node QQ300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs) and some components may be reused (e.g., a same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node QQ300.

[00155] The processing circuitry QQ302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node QQ300 components, such as the memory QQ304, to provide network node QQ300 functionality. [00156] In some embodiments, the processing circuitry QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuitry QQ312 and baseband processing circuitry QQ314. In some embodiments, the radio frequency (RF) transceiver circuitry QQ312 and the baseband processing circuitry QQ314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ312 and baseband processing circuitry QQ314 may be on the same chip or set of chips, boards, or units.

[00157] The memory QQ304 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations made by the processing circuitry QQ302 and/or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and memory QQ304 is integrated. [00158] The communication interface QQ306 is used in wired or wireless communication of signalling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface QQ306 comprises port(s)/terminal(s) QQ316 to send and receive data, for example to and from a network over a wired connection. The communication interface QQ306 also includes radio front-end circuitry QQ318 that may be coupled to, or in certain embodiments a part of, the antenna QQ310. Radio front-end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. The radio front-end circuitry QQ318 may be connected to an antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. The radio frontend circuitry QQ318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry QQ318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and/or amplifiers QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when receiving data, the antenna QQ310 may collect radio signals which are then converted into digital data by the radio front-end circuitry QQ318. The digital data may be passed to the processing circuitry QQ302. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

[00159] In certain alternative embodiments, the network node QQ300 does not include separate radio front-end circuitry QQ318, instead, the processing circuitry QQ302 includes radio front-end circuitry and is connected to the antenna QQ310. Similarly, in some embodiments, all or some of the RF transceiver circuitry QQ312 is part of the communication interface QQ306. In still other embodiments, the communication interface QQ306 includes one or more ports or terminals QQ316, the radio front-end circuitry QQ318, and the RF transceiver circuitry QQ312, as part of a radio unit (not shown), and the communication interface QQ306 communicates with the baseband processing circuitry QQ314, which is part of a digital unit (not shown).

[00160] The antenna QQ310 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna QQ310 may be coupled to the radio front-end circuitry QQ318 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna QQ310 is separate from the network node QQ300 and connectable to the network node QQ300 through an interface or port.

[00161] The antenna QQ310, communication interface QQ306, and/or the processing circuitry QQ302 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and/or the processing circuitry QQ302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment.

[00162] The power source QQ308 provides power to the various components of network node QQ300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ300 with power for performing the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source QQ308. As a further example, the power source QQ308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[00163] Embodiments of the network node QQ300 may include additional components beyond those shown in FIGURE 16 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300.

[00164] FIGURE 17 is a block diagram illustrating a virtualization environment QQ500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments QQ500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

[00165] Applications QQ502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. [00166] Hardware QQ504 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers QQ506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs QQ508a and QQ508b (one or more of which may be generally referred to as VMs QQ508), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer QQ506 may present a virtual operating platform that appears like networking hardware to the VMs QQ508.

[00167] The VMs QQ508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer QQ506. Different embodiments of the instance of a virtual appliance QQ502 may be implemented on one or more of VMs QQ508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[00168] In the context of NFV, a VM QQ508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs QQ508, and that part of hardware QQ504 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs QQ508 on top of the hardware QQ504 and corresponds to the application QQ502.

[00169] Hardware QQ504 may be implemented in a standalone network node with generic or specific components. Hardware QQ504 may implement some functions via virtualization. Alternatively, hardware QQ504 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration QQ510, which, among others, oversees lifecycle management of applications QQ502. In some embodiments, hardware QQ504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signalling can be provided with the use of a control system QQ512 which may alternatively be used for communication between hardware nodes and radio units.

[00170] FIGURE 18 illustrates an example method by a CP of a network for enabling packet processing site selection by a packet processing site selector associated with a UPF, according to certain embodiments. In the illustrated embodiment, the method includes at least one of a transmitting step at QQ702 and a receiving step at QQ704. For example, at step QQ702, the CP may transmit, to a packet processing site selector associated with a UPF, information comprising at least one site selection requirement. For example, the CP may transmit, to a UPF, information comprising at least one site selection requirement. As another example, at step QQ704, the CP may receive, from the packet processing site selector, an indication of a site selected by the packet processing site selector for performing packet processing for a communication session. For example, the CP may receive, from the UPF, an indication of a site selected by the packet processing site selector for performing packet processing for a communication session.

[00171] FIGURE 19 illustrates an example method by a packet processing site selector associated with a UPF of a network for enabling site selection, according to certain embodiments. In the illustrated embodiment, the method includes at least one of a receiving step at QQ802, a selecting step at QQ804, and a transmitting step at QQ806. For example, at step QQ802, the packet processing site selector may receive, from a CP, information comprising at least one site selection requirement. At step QQ804, for example, the packet processing site selector may select a site from a plurality of sites for performing packet processing for a communication session. As another example, at step QQ806, the packet processing site selector may transmit, to at least one of the CP and the selected site, an indication of the site selected for performing the packet processing for the communication session.

[00172] UP Path Change Without Control Plane Intervention

[00173] 3GPP provides different procedures for session continuity at User Equipment (UE) mobility, involving changes in the User Plane (UP) such as, for example, adding, relocating, or removing UPFs. Some of these procedures are described below with regard to FIGURES 20, 21, and 22.

[00174] Specifically, FIGURE 20 illustrates an Xn based inter NG-RAN handover with insertion of intermediate UPF as discussed in 3GPP TS 23.502 vl8.1.0. FIGURE 21 illustrates a change of SSC mode 2 PSA for a Protocol Data Unit (PDU) Session as disclosed in 3GPP TS 23.502 vl 8.1.0. FIGURE 22 illustrates a change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions as discussed in 3GPP TS 23.502 vl8.1.0.

[00175] There currently exist certain challenge(s), however. For example, in the current 3GPP 5GC architecture, when any change of UP is required during a PDU Session (I-UPF insertion, relocation or removal, or PSA change), the decision is made by the CN CP (e.g., SMF). This results in a relatively long procedure for UP change, including the following phases:

1) Trigger to the SMF (e.g., handover notification coming from RAN or latency measurement from UPF, the former going through the AMF)

2) SMF decision on UP change, based on available information (e.g., NW topology, latencies, subscriber/network policies)

3) N4 (re-) configuration of the UPF(s), potentially involving PDU Session reestablishments (SSC Modes #2 and #3). This could also involve early and late notification to the service layer to allow potential relocation also of the Server.

[00176] During this time, the PDU Session may experience degraded latency. There are certain low latency use cases that may not tolerate a longer degradation period (e.g., drone with XR control). A faster means to change the UP is desirable.

[00177] Methods and systems are provided below for enabling a user plane (e.g., UPF), particularly a multi-site UPF, to autonomously change the packet processor (PP) associated with a PDU session.

[00178] According to certain embodiments, for example, a method by a UP (e.g.., multi-site UPF, in a particular embodiment) includes at least one of:

- receiving policies for UP path change,

- receiving a trigger related to the change of the conditions on the UP path, and

- based on the received trigger, performing a UP path change.

[00179] Certain embodiments may provide one or more of the following technical advantage(s). For example, certain embodiments may provide a technical advantage of providing a faster mechanism for UP path change at UE mobility in the 3GPP network. This may be complemented by a UP triggered mechanism to also change the Edge Application server (EAS) if needed.

[00180] As another example, certain embodiments may provide a technical advantage of enabling a more granular selection process such as, for example, by taking some parameters into account that are hard to get for the CP. This is especially useful in an edge compute deployment scenario where most of the traffic is local, so it is beneficial to have a distributed UPF with small packet processors on each edge site.

[00181] A solution has been proposed above for a multi-site UPF, having a fine-granular view on some part of the UP topology and enabled to select the site and/or packet processor (PP) based on this fine-grained topology information, in combination with PDU session requirements (e.g., latency) and other dynamic UP related information (e.g., load and congestion levels). In the multisite UPF case, the SMF may not have fine-granular topology knowledge. As such, a notification by the UPF to SMF is proposed to be issued/transmitted when the session criteria is/are no longer fulfilled, as previously described in relation to FIGURE 12.

[00182] According to certain embodiments, methods and systems are provided for enabling a user plane (e.g., UPF) to autonomously change the packet processor (PP) associated with a PDU session. Whether this functionality is allowed and under what conditions it is allowed is controlled (e.g., pre-configured or policy -based) by the CN CP (SMF), in a particular embodiment. In certain scenarios, it may be assumed that UPF gets fast notification of the change of the UP path conditions. Based on such notification, and its internal topology /latency knowledge as well as the pre-configured policies from the CN CP, the UPF in configured to modify the UP path by inserting, moving, and/or removing the PPs. In a particular embodiment, the UE may also be notified by the UPF on the new IP address to use for the new path.

[00183] For example, according to certain embodiments, a method by a UP (e.g.., multi-site UPF, in a particular embodiment) includes at least one of: receiving policies for UP path change, receiving a trigger related to the change of the conditions on the UP path, and based on the received trigger, performing a UP path change.

[00184] In a particular embodiment, the policies for UP path change may be pre-configured in the UPF. [00185] In a particular embodiment, the policies for UP path change are sent from the CN CP (SMF) at PDU Session Establishment or during the lifetime of a PDU Session via a N4 Session Modification from the SMF.

[00186] In a particular embodiment, the policies for UP path change include a “re-anchoring allowed” indicator to UP.

[00187] In, a particular embodiment, the policies for UP path change include a desired UP KPI (latency, BW) for specific traffic or all the traffic in the PDU Session.

[00188] In a particular embodiment, the policies for UP path change include a “session continuity mode” indicator.

[00189] In a particular embodiment, the trigger related to the change of the conditions on the UP path is a RAN UP endpoint change, due to a UE mobility event, or re-activation of a UE previously in a RAN inactive state, conveyed to the UPF via UP internal location updates from the RAN.

[00190] In a particular embodiment, the trigger related to the change of the conditions on the UP path relates to a change of the KPI on the UP path, e.g., provided by KPI measurements or routing updates.

[00191] In a particular embodiment, the UP path change includes adding, removing or moving PPs on the UP path.

[00192] In a particular embodiment, changes on the UP path are communicated to the RAN (using UP internal location updates) to establish connectivity over the changed UP path.

[00193] In a particular embodiment, changes on the UP path impacting the UE are communicated to the UE to allow proper routing on the new UP path.

[00194] In a particular embodiment, the change impacting the UE is a new UE IP address for some traffic and the means of communication is a IPv6 Neighbor Discovery Protocol's (NDP, RFC 4861) Router Advertisement message.

[00195] In a particular embodiment, CN CP is notified about the changes on the UP path.

[00196] In a further particular embodiment, the notification sent to the CN CP includes the new UE IP address and impacted traffic.

[00197] In a particular embodiment, the old UP path is maintained during the setup of the new UP path.

[00198] In a further particular embodiment, UP path change may also involve a trigger to change the EAS(s) for the applications on this PDU Session. [00199] These methods and systems of the UPF autonomously performing a change operation may be implemented in a satellite with a UPF onboard, known as a Satellite UPF (S-UPF). When there is a UE handover, and the S-UPF is currently not reachable from the CN CP, the in-band path switch as disclosed herein may be used to re-establish the UP path from the new gNB to the S- UPF.

[00200] FIGURE 23 illustrates a method and/or flowchart showing example decision logic for changing the UP path in/by the multi-site UPF, according to certain embodiments. It is recognized that FIGURE 23 is merely provided as an example and that certain steps may be omitted, that additional steps may be performed, and that the steps may be performed in any suitable order.

[00201] As illustrated, in Step 1, the UPF receives policies for UP path change from the CN CP (SMF). In a particular embodiment, the policies may be pre-configured in the UPF or sent by the CN CP (SMF). In further particular embodiments, the latter happens at the PDU Session Establishment or during the PDU session, via a N4 Session Modification request from the SMF (that may be triggered e.g., by a session policy modification).

[00202] In a particular embodiment, the policies include a “re-anchoring allowed” indicator to UPF, authorizing it to perform UP changes for specific traffic or all the traffic in the PDU Session. [00203] In a particular embodiment, the policies include a desired UP KPI (latency, BW) for specific traffic or all the traffic in the PDU Session.

[00204] In a particular embodiment, these policies include a session continuity mode indicator. If the session continuity mode indicator is set, the UPF maintains the old UP path during the setup of the new UP path to provide session continuity.

[00205] At step 2, the UPF receives a trigger related to the change of the conditions on the UP path. For example, in various particular embodiments, the trigger may include at least one of: a RAN UP endpoint change, due to a UE mobility event, or re-activation of a UE previously in a RAN inactive state, conveyed to the UPF via UP internal location updates from the RAN a change of the KPI on the UP path, e.g., provided by KPI measurements or routing updates.

[00206] At step 3, based on the received trigger, the UPF performs a UP path reconfiguration. For example, in various particular embodiments, the UPF adds, removes, or moves PPs on the UP path. Note that if the session continuity mode indicator is set, then the UPF should maintain the old UP path during the setup of the new UP path to provide session continuity, in a particular embodiment. [00207] At step 4, the UPF communicates the changes on the UP path to the RAN (using UP internal location updates) to establish connectivity over the changed UP path.

[00208] At step 5, the changes on the UP path impacting the UE are also communicated to the UE to allow proper routing on the new UP path. For example, the UE receives new UE IP address for the traffic directed to the new anchor and the means of communication can be a IPv6 Neighbor Discovery Protocol's (NDP, RFC 4861) Router Advertisement message.

[00209] At step 6, the CN CP is also notified about the changes on the UP path. In a particular embodiment, the notification includes the new UE IP address and impacted traffic. Based on this trigger, the CN CP may trigger a notification to an Application Function (AF) to change the EAS(s) for the applications on this PDU Session, in a particular embodiment.

[00210] Handover with I-PP Insertion

[00211] An example use case is when the UE handovers require inserting on a I-PP. The insertion of an I-UPF according to previous (legacy) methods, systems, and techniques is described above with regard to FIGURE 20. By contrast, FIGURE 24 illustrates an example UP -based mechanism for performing handover with I-PP insertion by the UPF, according to certain embodiments. It is recognized that FIGURE 24 is merely provided as an example and that certain steps may be omitted, that additional steps may be performed, and that the steps may be performed in any suitable order.

[00212] As illustrated, in Step 1, at PDU Session establishment, CN CP (SMF) pre-configures service requirement (e.g., required UE-to-anchor latency) for certain traffic/application descriptors including the “re-anchoring allowed” indicator for the given application/traffic descriptor. (Note: this could also happen after PDU Session establishment, as described above).

[00213] At step 2, a handover procedure takes place, without inserting I-UPF by the SMF. It is assumed that the handover uses UP internal location updates from the RAN (its Target UP), so the PP becomes aware of the handover.

[00214] At step 3, the serving PP sends an UP update to the PP selector, indicating the change of UP path, i.e., the new target RAN UP IP address. [00215] At step 4, the PP Selector determines whether UE mobility resulted in a service requirement violation. If it is determined that UE mobility resulted in a violation of a service requirement, then the UPF selects an I-PP that may fulfil the service requirement.

[00216] At step 5, the PP Selector configures the I-PP using UP internal mechanisms with information that is needed for it to be part of the new UP path and which traffic to be broken out. The I-PP may respond with the new IP address to be used for this traffic.

[00217] At step 6, the I-PP issues UP internal location updates towards the Target RAN UP as well as the PP to update their tunnel endpoints where to send the UP traffic.

[00218] At step 7, the PP Selector issues an UP update notification message to the CN CP (SMF) in which it may specify the new RAN UP used for the session as well as the new UE IP used for the traffic that is locally anchored at I-PP. Based on the received notification, the SMF may decide to issue a notification to some service application function (AF)

[00219] Handover with Re-Anchoring

[00220] Another example use case is when the UPF is authorized to change the packet switch anchor for the whole UE PDU Session. FIGURE 25 illustrates an example handover procedure with packet switch anchor changes by the UPF, according to certain embodiments. It is recognized that FIGURE 25 is merely provided as an example and that certain steps may be omitted, that additional steps may be performed, and that the steps may be performed in any suitable order.

[00221] At step 1, at PDU Session establishment, CN CP (SMF) pre-configures service requirement (e.g., required UE-to-anchor latency) for the PDU Session and it sends the “reanchoring allowed” indicator which means that re-anchoring with IP address change is allowed for this PDU Session.

[00222] At step 2, a Handover procedure takes place. It is assumed that the handover uses UP internal location updates from the RAN (its Target UP), so the PP becomes aware of the handover. [00223] At step 3, the Source (current serving) PP sends an UP update to the PP selector, indicating the change of UP path, i.e., the new target RAN UP IP address.

[00224] At step 4, the PP Selector determines whether UE mobility resulted in a service requirement violation. If it is determined that a service requirement is violated, the UPF selects new Target PP that may fulfil it. [00225] At step 5, the PP Selector configures the Target PP using UP internal mechanisms with information that is needed for it to anchor the PDU Session. The Target PP may respond with the new IP address to be used for this traffic. Note that if the “session continuity mode” indicator. If this is set, then the UPF should maintain the old UP path (with Source PP) during the setup of the new UP path to provide session continuity.

[00226] At step 8, the Target PP issues an UP internal location update towards the Target RAN UP.

[00227] At step 9, the Target PP provides a new IP address to the UE using a IPv6 Neighbor Discovery Protocol's (NDP, RFC 4861) Router Advertisement message.

[00228] At step 10, the Target PP informs the PP Selector about the completion of the UP change and the new UE IP address.

[00229] At step 11, the PP Selector issues an UP update notification message to the CN CP (SMF) in which it may specify the new RAN UP used for the session as well as the new UE IP used. Based on the received notification, the SMF may decide to issue a notification to some service application function (AF).

[00230] FIGURE 26 illustrates an example method by a UPF for UP path change, according to certain embodiments. In the illustrated embodiment, the method includes at least one of an obtaining step at QQ902, a detecting step at QQ904, and a performing step at QQ906. For example, at step QQ902, the UPF may obtain at least one policy for UP path change. As another example, at step QQ904, the UPF may detect a change in at least one condition related to a UP path used for a communication session. As still another example, at step QQ906, the UPF may perform a change operation with respect to the UP path for the communication session, and the change operation is performed based on the change in the at least one condition and/or the at least one policy for UP path change.

[00231] FIGURE 27 illustrates an example method by a RAN for UP path change, according to certain embodiments. In the illustrated embodiment, the method includes a receiving step at QQ1002. For example, at step QQ1002, the RAN may receive, from a UPF, information associated with a change operation performed by the UPF with respect to a UP path for a communication session.

[00232] FIGURE 28 illustrates an example method for UP path change by a CN CP, according to certain embodiments. In the illustrated embodiment, the method includes a receiving step at QQ1102. For example, at step QQ1102, CN CP may receive, from a UPF, information associated with a change operation performed by the UPF with respect to a UP path for a communication session.

[00233] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[00234] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

EXAMPLE EMBODIMENTS

Group A Example Embodiments

Example Embodiment Al. A method performed by a user equipment for enabling packet processing (PP) site selection by a User Plane Function (UPF), the method comprising:

- any of the user equipment steps, features, or functions described above, either alone or in combination with other steps, features, or functions described above.

Example Embodiment A2. The method of the previous embodiment, further comprising one or more additional user equipment steps, features or functions described above.

Example Embodiment A3. The method of any of the previous embodiments, further comprising:

- providing user data; and

- forwarding the user data to a host computer via the transmission to the network node.

Group B Example Embodiments

Example Embodiment Bl. A method performed by a network node for enabling packet processing (PP) site selection by a User Plane Function (UPF), the method comprising:

- any of the network node steps, features, or functions described above, either alone or in combination with other steps, features, or functions described above.

Example Embodiment B2. The method of the previous embodiment, further comprising one or more additional network node steps, features or functions described above.

Example Embodiment B3. The method of any of the previous embodiments, further comprising:

- obtaining user data; and

- forwarding the user data to a host or a user equipment. Group C Example Embodiments

Example Embodiment Cl. A method performed by a control plane (CP) of a network for enabling packet processing site selection by a User Plane Function (UPF), the method comprising at least one of: transmitting, to a UPF, information comprising at least one site selection requirement; and receiving, from the UPF, an indication of a site selected by the UPF for performing packet processing for a communication session.

Example Embodiment C2. The method of Example Embodiment Cl, wherein the method is performed by a Session Management Function (SMF) of the CP.

Example Embodiment C3. The method of any one of Example Embodiments C 1 to C2, wherein at least one of: the at least one site selection requirement is transmitted to the UPF in a PDU Session setup request, the at least one site selection requirement is transmitted to the UPF in a N4 Session Establishment or Modification request; and the at least one site selection requirement is transmitted to the UPF via a N4 interface.

Example Embodiment C4. The method of any one of Example Embodiments Cl to C3, wherein the UPF is a multi-site UPF comprising a plurality of Packet Processors (PP) for perform UPF packet processing,

Example Embodiment C5. The method of Example Embodiment C4, wherein the SMF has no knowledge of the plurality of PP for performing UPF packet processing.

Example Embodiment C6. The method of any one of Example Embodiments C4 to C5, wherein the SMF has coarse-grained topology information and the UPF has fine-grained topology information (e.g., the SMF has less information than the UPF relating to user plane (UP) network topology).

Example Embodiment C7. The method of any one of Example Embodiments C4 to C6, wherein the indication of the site selected by the UPF comprises at least one of: an indication of a particular one of the plurality of PPs selected by the UPF for performing packet processing for the communication session, and tunnel endpoint information for the selected one of the plurality of PPs.

Example Embodiment C8. The method of any one of Example Embodiments Cl to C7, wherein obtaining capability information associated with the UPF, wherein the capability information indicates an ability of the UPF to perform the site selection.

Example Embodiment C9. The method of Example Embodiment C8, wherein at least one of: the capability information is pre-configured in the network Control Plane (CP). the capability information is obtained and/or received from a Network Repository Function (NRF), and the capability information is obtained and/or received when the network CP establishes an associated with the UPF.

Example Embodiment CIO. The method of any one of Example Embodiments C8 to C9, wherein the at least one site selection requirement is transmitted to the UPF based on the capability information.

Example Embodiment Cl 1. The method of any one of Example Embodiments Cl to CIO, wherein the at least one site selection requirement comprises at least one of: at least one UPF2RAN latency requirement; at least one latency budget and/or RAN budget; at least one transport budget; and at least one UPF budget.

Example Embodiment C12. The method of any one of Example Embodiment Cl to Cl l, comprising transmitting, to the UPF, UE location information associated with the communication session.

Example Embodiment C13. The method of any one of Example Embodiments Cl to C12, comprising at least one of: receiving, from the UPF, an indication of a changed RAN UP (e.g., CU-UP), and transmitting, to the UPF, an indication of a changed RAN UP (e.g., CU-UP).

Example Embodiment C14. The method of any one of Example Embodiments Cl to C13, comprising receiving, from the UPF, information indicating a violation of at least one site selection requirement. Example Embodiment Cl 5. The method of Example Embodiment Cl 4, comprising, based on the information indicating the violation of the at least one site selection requirement, initiating a PDU Session reestablishment with a UE for the communication session.

Example Embodiment Cl 6. The method of any one of Example Embodiments Cl to C15, wherein the SMF and the UPF are associated with a core network and/or at least one core network node.

Example Embodiment C 17. The method of any one of Example Embodiments C 1 to C 16, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

Example Embodiment Cl 8. A network node comprising processing circuitry configured to perform any of the methods of Example Embodiments Cl to Cl 7.

Example Embodiment Cl 9. A network node configured to perform any of the methods of Example Embodiments DI to Cl 7.

Example Embodiment C20. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Cl to Cl 7.

Example Embodiment C21. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Cl to Cl 7.

Example Embodiment C22. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments Cl to C17.

Group D Example Embodiments

Example Embodiment DI. A method performed by a user plane function (UPF) of a network for enabling site selection, the method comprising at least one of: receiving, from a control plane (CP), information comprising at least one site selection requirement; selecting a site from a plurality of sites for performing packet processing for a communication session; and transmitting, to at least one of the CP and the selected site, an indication of the site selected for performing the packet processing for the communication session.

Example Embodiment D2. The method of Example Embodiment DI, wherein the site is selected from the plurality of sites based on at least one of: the at least one site selection requirement received from the CP; a user plane (UP) network topology; dynamic information associated with the UP; at least one site selection policy; and load information indicating a respective load of each site in the plurality of sites.

Example Embodiment D3. The method of any one of Example Embodiments D 1 to D2, wherein at least one of: the CP comprises a Session Management Function (SMF), the at least one site selection requirement is received from the SMF, and the indication of the site selected for performing the packet processing is sent to the SMF.

Example Embodiment D4. The method of any one of Example Embodiments DI to D3, wherein at least one of: the at least one site selection requirement is received in a PDU Session setup request, the at least one site selection requirement is received in a N4 Session Establishment or Modification request; and the at least one site selection requirement is received via a N4 interface.

Example Embodiment D5. The method of any one of Example Embodiments D 1 to D4, wherein the UPF is a multi-site UPF comprising a plurality of Packet Processors (PP) for perform UPF packet processing,

Example Embodiment D6. The method of Example Embodiment D5, wherein the SMF has no knowledge of the network topology including the plurality of PPs for performing UPF packet processing, and wherein SMF has no knowledge of the plurality of PPs for performing UPF packet processing. Example Embodiment D7. The method of any one of Example Embodiments D5 to D6, wherein the SMF has coarse-grained network topology information and the UPF has fine-grained network topology information (e.g., the SMF has less information than the UPF relating to user plane (UP) network topology).

Example Embodiment D8. The method of any one of Example Embodiments D5 to D7, wherein the indication of the site selected by the UPF comprises at least one of: an indication of a PP of the plurality of PPs selected by the UPF for performing packet processing for the communication session, and tunnel endpoint information for the selected PP of the plurality of PPs.

Example Embodiment D9. The method of any one of Example Embodiments DI to D8, comprising transmitting, to the CP, capability information associated with the UPF, wherein the capability information indicates an ability of the UPF to perform the site selection.

Example Embodiment DIO. The method of Example Embodiment D9, wherein the capability information is transmitted when the UPF establishes an association with the CP and/or the network.

Example Embodiment DI 1. The method of any one of Example Embodiments D9 to DIO, wherein the at least one site selection requirement is received from the CP in response to and/or based on and/or after the capability information is transmitted to the CP.

Example Embodiment D12. The method of any one of Example Embodiments DI to Dl l, wherein the at least one site selection requirement comprises at least one of: at least one UPF2RAN latency requirement; at least one latency budget and/or RAN budget; at least one transport budget; and at least one UPF budget.

Example Embodiment D13. The method of any one of Example Embodiment DI to D12, comprising receiving, from the CP, UE location information associated with the communication session.

Example Embodiment D14. The method of any one of Example Embodiments DI to D13, comprising at least one of: obtaining information indicating and/or determining a changed RAN UP (e.g., CU-UP); receiving, from the selected site, an indication of a changed RAN UP (e.g., CU-UP); transmitting, to the CP, an indication of a changed RAN UP (e.g., CU-UP), and receiving, from the CP, an indication of a changed RAN UP (e.g., CU-UP).

Example Embodiment DI 5. The method of any one of Example Embodiments DI to D14, comprising at least one of: determining a violation of the at least one site selection requirement, obtaining information indicating a violation of the at least one site selection requirement, and receiving, from the selected site, information indicating a violation of the at least one site selection requirement.

Example Embodiment DI 6. The method of Example Embodiment DI 5, wherein the violation of the at least one site selection requirement is based on at least one of: a changed RAN UP (e.g., CU-CP) and a handover of a UE associated with the communication session to a new CU-CP..

Example Embodiment DI 7. The method of any one of Example Embodiments DI 5 to DI 6, comprising transmitting, to the CP, information indicating the violation of the at least one site selection requirement.

Example Embodiment DI 8. The method of any one of Example Embodiments DI to D17, wherein the UPF and the SMF of the CP are associated with a core network and/or at least one core network node.

Example Embodiment D 19. The method of any one of Example Embodiments D 1 to D 18, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

Example Embodiment D20. A network node comprising processing circuitry configured to perform any of the methods of Example Embodiments DI to DI 9.

Example Embodiment D21. A network node configured to perform any of the methods of Example Embodiments DI to DI 9.

Example Embodiment D22. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments DI to DI 9. Example Embodiment D23. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments DI to DI 9.

Example Embodiment D24. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments DI to D19.

Group E Example Embodiments

Example Embodiment El . A user equipment for enabling packet processing (PP) site selection by a User Plane Function (UPF) the UE comprising: processing circuitry configured to perform any of the steps of any of the Group A Example Embodiments; and power supply circuitry configured to supply power to the processing circuitry.

Example Embodiment E2. A network node for enabling packet processing (PP) site selection by a User Plane Function (UPF), the network node comprising: processing circuitry configured to perform any of the steps of any of the Group B , C, and D Example Embodiments; power supply circuitry configured to supply power to the processing circuitry.

Example Embodiment E3. A user equipment (UE) for enabling packet processing (PP) site selection by a User Plane Function (UPF), the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A Example Embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE. Group F Example Embodiments

Example Embodiment Fl. A method performed by a user equipment for User Plane (UP) path change by a User Plane Function (UPF), the method comprising:

- any of the user equipment steps, features, or functions described above, either alone or in combination with other steps, features, or functions described above.

Example Embodiment F2. The method of the previous embodiment, further comprising one or more additional user equipment steps, features or functions described above.

Example Embodiment F3. The method of any of the previous embodiments, further comprising:

- providing user data; and

- forwarding the user data to a host computer via the transmission to the network node.

Group G Example Embodiments

Example Embodiment Gl. A method performed by a network node for User Plane (UP) path change by a User Plane Function (UPF), the method comprising:

- any of the network node steps, features, or functions described above, either alone or in combination with other steps, features, or functions described above.

Example Embodiment G2. The method of the previous embodiment, further comprising one or more additional network node steps, features or functions described above.

Example Embodiment G3. The method of any of the previous embodiments, further comprising:

- obtaining user data; and

- forwarding the user data to a host or a user equipment.

Group H Example Embodiments

Example Embodiment Hl . A method performed by a User Plane Function (UPF) for User Plane (UP) path change, the method comprising at least one of: obtaining at least one policy for UP path change; detecting a change in at least one condition related to a UP path used for a communication session; performing a change operation with respect to the UP path for the communication session, wherein the change operation is performed based on the change in the at least one condition and/or the at least one policy for UP path change.

Example Embodiment H2. The method of Example Embodiment Hl, wherein obtaining the at least one policy for UP path change comprises at least one of: determining the at least one policy based on a configuration and/or specification; receiving the at least one policy from the Control Network-Control Plane; receiving the at least one policy from a SMF; receiving the at least one policy at PDU Session Establishment; and receiving the at least one policy during a PDU session via a N4 Session Modification.

Example Embodiment H3. The method of any one of Example Embodiments Hl to H2, wherein the at least one policy for UP path change comprises at least one of: an indication that re-anchoring is allowed; a desired UP KPI for all traffic in the communication session; a desired UP KPI for at least a portion of traffic in the communication session; and an indication that session continuity mode is enabled.

Example Embodiment H4. The method of Example Embodiment H3, comprising: when session continuity mode is enabled, maintain an old UP path during a set of the new UP path to provide communication session continuity.

Example Embodiment H5. The method of any one of Example Embodiments Hl to H4, wherein detecting the change in the at least one condition related to the UP path comprises identifying and/or receiving information indicating at least one of: a RAN UP endpoint change; a mobility event; a re-activation of a UE previously in an inactive state; a change in a KPI on/associated with the UP path. Example Embodiment H6. The method of Example Embodiment H5, wherein the information indicating the change in the at least one condition related to the UP path is received via an UP internal location update received from a RAN.

Example Embodiment H7. The method of Example Embodiment H5, wherein the information indicating the change in the at least one condition related to the UP path is received via KPI measurement and/or a routing update.

Example Embodiment H8. The method of any one of Example Embodiments Hl to H7, wherein performing the change operation comprises at least one of: adding a PP on the UP path. removing at least one PP on the UP path, and moving at least one PP on the UP path.

Example Embodiment H9. The method of any one of Example Embodiments Hl to H8, comprising transmitting an indication of the change operation to the RAN to establish connectivity over the changed UP path.

Example Embodiment H10. The method of Example Embodiment H9, wherein the indication of the change operation is transmitted to the RAN via an UP internal location update.

Example Embodiment Hl 1. The method of any one of Example Embodiments Hl to H10, comprising transmitting to a UE associated with the communication session at least one of: an indication of the change operation to a UE associated with the communication session, and a new UE IP address for at least a portion of the traffic.

Example Embodiment H12. The method of Example Embodiment Hl 1, wherein the indication of the change is transmitted to the UE via a IPv6 Neighbor Discovery Protocol Router Advertisement message.

Example Embodiment Hl 3. The method of any one of Example Embodiment Hl to H12, comprising transmitting information associated with the change operation to a Control Network- Control Plane (CN CP).

Example Embodiment H14. The method of Example Embodiment H13, wherein the information associated with the change operation that is transmitted to the CN CP comprises at least one of: a new UE IP address, information indicating impacted traffic.

Example Embodiment Hl 5. The method of any one of Example Embodiments H13 to H14, wherein the CN CP comprises a SME

Example Embodiment Hl 6. The method of any one of Example Embodiments Hl to H15, wherein performing the change operation with respect to the UP path for the communication session comprises setting up a new UP path for the communication session.

Example Embodiment Hl 7. The method of Example Embodiment Hl 6, comprising maintaining the UP path for the communication session while the new UP path is set up.

Example Embodiment Hl 8. The method of any one of Example Embodiments Hl to H17, wherein the UP path change triggers a change of EAS for at least one application associated with the communication session.

Example Embodiment Hl 9. The method of any one of Example Embodiments Hl to Hl 8, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

Example Embodiment H20. A network node comprising processing circuitry configured to perform any of the methods of Example Embodiments Hl to Hl 9.

Example Embodiment H21. A network node configured to perform any of the methods of Example Embodiments Hl to Hl 9.

Example Embodiment H22. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Hl to Hl 9.

Example Embodiment H23. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Hl to Hl 9.

Example Embodiment H24. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments Hl to H19. Group I Example Embodiments

Example Embodiment II. A method performed by a RAN for User Plane (UP) path change, the method comprising at least one of: receiving, from a UPF, information associated with a change operation performed by the UPF with respect to a UP path for a communication session.

Example Embodiment 12. The method of Example Embodiment II, wherein the change operation is performed based on a change in at least one condition for UP path.

Example Embodiment 13. The method of any one of Example Embodiments II to 12, comprising transmitting, to the UPF, information indicating the change in the at least one condition.

Example Embodiment 14. The method of Example Embodiment 13, wherein the information indicating the change in at least one condition related to the UP path comprises at least one of: a RAN UP endpoint change; a mobility event; a re-activation of a UE previously in an inactive state; a change in a KPI on/associated with the UP path.

Example Embodiment 15. The method of Example Embodiment 14, wherein the information indicating the change in the at least one condition related to the UP path is transmitted to the UPF via an UP internal location update.

Example Embodiment 16. The method of any one of Example Embodiments 14 to 15, wherein the information indicating the change in the at least one condition related to the UP path is received from a UE via a KPI measurement and/or a routing update.

Example Embodiment 17. The method of any one of Example Embodiments II to 17, wherein the change operation is performed based at least in part on at least one policy for UP path change, and wherein the at least one policy for UP path change comprises at least one of: an indication that re-anchoring is allowed; a desired UP KPI for all traffic in the communication session; a desired UP KPI for at least a portion of traffic in the communication session; and an indication that session continuity mode is enabled.

Example Embodiment 18. The method of Example Embodiment 17, wherein when session continuity mode is enabled, the UP path is maintained during a set of a new UP path to provide communication session continuity.

Example Embodiment 19. The method of any one of Example Embodiments II to 18, wherein information associated with the change operation comprises at least one of: an indication of at least one PP being added to the UP path, an indication of at least one PP being removed from the UP path, and an indication of moving at least one PP on the UP path.

Example Embodiment 110. The method of any one of Example Embodiments II to 19, wherein the information associated with the change operation is received with a request to establish connectivity over the changed UP path.

Example Embodiment Il l. The method of Example Embodiment 19, wherein the information associated with the change operation is received from the UPF via an UP internal location update. Example Embodiment 112. The method of any one of Example Embodiments II to Il l, comprising transmitting to a UE associated with the communication session at least one of: an indication of the change operation associated with the communication session, and a new UE IP address for at least a portion of the traffic.

Example Embodiment 113. The method of Example Embodiment 112, wherein the indication of the change operation is transmitted to the UE via a IPv6 Neighbor Discovery Protocol Router Advertisement message.

Example Embodiment 114. The method of any one of Example Embodiments II to 113, wherein the information associated with the change operation indicates that a UP path has been or is being set up for the communication session.

Example Embodiment 115. The method of Example Embodiment 114, wherein the UP path is maintained for the communication while the new UP path is set up.

Example Embodiment 116. The method of any one of Example Embodiments II to 115, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

Example Embodiment 117. A network node comprising processing circuitry configured to perform any of the methods of Example Embodiments II to 116.

Example Embodiment 118. A network node configured to perform any of the methods of Example Embodiments II to 116.

Example Embodiment 119. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments II to 116.

Example Embodiment 120. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments II to 116.

Example Embodiment 121. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments II to 116.

Group J Example Embodiments

Example Embodiment JI. A method for User Plane (UP) path change by a Control Network Control Plane (CN CP), the method comprising at least one of: receiving, from a UPF, information associated with a change operation performed by the UPF with respect to a UP path for a communication session.

Example Embodiment J2. The method of Example Embodiment JI, wherein the change operation is performed based on at least one policy for UP path change, and the method comprises transmitting the at least one policy to the UPF.

Example Embodiment J3. The method of Example Embodiment J2, wherein the at least one policy for UP path change is transmitted by a SMF of the SN CP.

Example Embodiment J4. The method of any one of Example Embodiments J2 to J3, wherein the at least one policy for UP path change is transmitted to the UPF at PDU Session Establishment.

Example Embodiment J5. The method of any one of Example Embodiments J2 to J4, wherein the at least one policy for UP path change is transmitted to the UPF via a N4 Session Modification. Example Embodiment J6. The method of any one of Example Embodiments J2 to J5, wherein the at least one policy for UP path change comprises at least one of: an indication that re-anchoring is allowed; a desired UP KPI for all traffic in the communication session; a desired UP KPI for at least a portion of traffic in the communication session; and an indication that session continuity mode is enabled.

Example Embodiment J7. The method of Example Embodiment J6, wherein when session continuity mode is enabled, the UP path is maintained during a set of a new UP path to provide communication session continuity.

Example Embodiment J8. The method of any one of Example Embodiments JI to J7, wherein the change operation is performed based on at least one change in at least one condition related to the UP path.

Example Embodiment J9. The method of Example Embodiment J8, wherein the change in the at least one condition related to the UP path comprises at least one of: a RAN UP endpoint change; a mobility event; a re-activation of a UE previously in an inactive state; a change in a KPI on/associated with the UP path.

Example Embodiment JI 0. The method of any one of Example Embodiments JI to J9, wherein the information associated with the change operation comprises at least one of: an indication of at least one PP being added to the UP path, an indication of at least one PP being removed from the UP path, and an indication of moving at least one PP on the UP path.

Example Embodiment JI 1. The method of any one of Example Embodiments JI to JI 0, wherein the information associated with the change operation comprises at least one of: a new UE IP address, information indicating impacted traffic.

Example Embodiment J12. The method of any one of Example Embodiments JI to JI 1, wherein the CN CP comprises a SMF. Example Embodiment JI 3. The method of any one of Example Embodiments JI to J 12, wherein information associated with the change operation indicates that a new UP path has been or is being set up for the communication session.

Example Embodiment J14. The method of Example Embodiment J13, wherein the UP path is maintained for the communication session while the new UP path is set up.

Example Embodiment JI 5. The method of any one of Example Embodiments JI to J14, wherein information associated with the change operation triggers a change of EAS for at least one application associated with the communication session.

Example Embodiment JI 6. The method of any one of Example Embodiments JI to J15, comprising transmitting, to an Application Function (AF), a notification to change an EAS for the at least one application associated with the communication session.

Example Embodiment JI 7. The method of any one of Example Embodiments JI to JI 6, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

Example Embodiment JI 8. A network node comprising processing circuitry configured to perform any of the methods of Example Embodiments JI to JI 7.

Example Embodiment J21. A network node configured to perform any of the methods of Example Embodiments JI to JI 7.

Example Embodiment J22. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments JI to JI 7.

Example Embodiment J23. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments JI to JI 7.

Example Embodiment J24. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments JI to J17. Group K Example Embodiments

Example Embodiment KI . A user equipment comprising: processing circuitry configured to perform any of the steps of any of the Group F Example Embodiments; and power supply circuitry configured to supply power to the processing circuitry.

Example Embodiment K2. A network node comprising: processing circuitry configured to perform any of the steps of any of the Group G , H, I, and J Example Embodiments; power supply circuitry configured to supply power to the processing circuitry.

Example Embodiment K3. A user equipment (UE) for enabling packet processing (PP) site selection by a User Plane Function (UPF), the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group F Example Embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.

ABBREVIATIONS

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s). lx RTT CDMA2000 lx Radio Transmission Technology

3 GPP 3rd Generation Partnership Project

5G 5th Generation

5G-AN 5G Access Network

5GC 5G Core

5GS 5G System

5QI 5G QoS Identifier

6G 6th Generation

ABS Almost Blank Subframe

ACK Acknowledgement

AGC Automatic Gain Control AM Acknowledged Mode

AMD AM Mode Data

AN Access Network

AN Access Node

ANR Automatic Neighbor Relations

AP Access Point

AR Augmented Reality

ARQ Automatic Repeat Request

AS Access Stratum

ASN.l Abstract Syntax Notation One

AWGN Additive White Gaussian Noise

BCCH Broadcast Control Channel BCH Broadcast Channel BLER Block Error Rate bps Bits per second BS Base Station BSC Base Station Controller BSR Buffer Status Report BTS Base Transceiver Station BWP Bandwidth Part CA Carrier Aggregation CB Contention-Based CBRA Contention-Based Random Access CC Carrier Component CCA Clear Channel Assessment CCCH Common Control Channel

CCCH SDU Common Control Channel SDU CDM Code Division Multiplexing CDMA Code Division Multiplexing Access CE Control Element/Coverage Enhancement CF Contention-Free CFRA Contention-Free Random Access CG Cell Group or Configured Grant CGI Cell Global Identifier/Identity CHO Conditional Handover CIR Channel Impulse Response CN Core Network CORESET Control Resource Set COT Channel Occupancy Time CP Cyclic Prefix CPICH Common Pilot Channel CPICH Ec/No CPICH Received energy per chip divided by the power density in the band

CPT Control PDU Type CQI Channel Quality information C-RNTI Cell RNTI CRC Cyclic Redundancy Check CRM Contention Resolution Message C-RNTI Cell RNTI CSI Channel State Information CSLRS Channel State Information Reference Signal CSS Common Search Space CU-UP Centralized Unit-User Plane D/C Data/Control DCCH Dedicated Control Channel DCI Downlink Control Information DG Dynamic Grant DL Downlink DL-SCH Downlink Shared Channel DM Demodulation DMRS Demodulation Reference Signal DRB Dedicated Radio Bearer DRX Discontinuous Reception DTX Discontinuous Transmission DTCH Dedicated Traffic Channel DU Distributed Unit DUT Device Under Test EARFCN Evolved Absolute Radio Frequency Channel Number E-CID Enhanced Cell-ID (positioning method) ECGI Evolved CGI E-SMLC Evolved-Serving Mobile Location Centre ECGI Evolved CGI eDRX Enhanced DRX EDT Early Data Transmission eMBB Enhanced Mobile Broadband eMBMS evolved Multimedia Broadcast Multicast Services eMTC Enhanced Machine Type Communication eNB E-UTRAN NodeB/eNodeB ePDCCH enhanced Physical Downlink Control Channel EPC Evolved Packet Core EPS Evolved Packet System eRedCap Enhanced Reduced Capacity NR Device E-UTRA Evolved UTRA E-UTRAN Evolved Universal Terrestrial Radio Access Network EVT Ephemeris data Validity Timer / Ephemeris Validity Timer FDD Frequency Division Duplex FDM Frequency Division Multiplexing FFS For Further Study Fps Frames per second FR Frequency Range GBR Guaranteed Bit Rate GERAN GSM EDGE Radio Access Network GEO Geostationary Earth Orbit GFBR Guaranteed Flow Bit Rate GHz Gigahertz GLONASS Global Navigation Satellite System gNB gNode B (a base station in NR; a Node B supporting NR and connectivity to NGC)

GNSS Global Navigation Satellite System GP Guard Period GPS Global Positioning System GSM Global System for Mobile communication GW Gateway HAPS High Altitude Platform System/ High Altitude Platform Station HARQ Hybrid Automatic Repeat Request HIBS HAPS as IMT Base Station HO Handover HSPA High Speed Packet Access HRPD High Rate Packet Data Hz Hertz ID Identity /Identifier IE Information Element loT Internet of Things IMT International Mobile Telecommunications IP Internet Protocol LRNTI Inactive RNTI KB Kilobytes kHz Kilohertz LBT Listen Before Talk LCH Logical Channel LCID Logical Channel ID LEO Low Earth Orbit

LOS Line of Sight

LPP LTE Positioning Protocol

LPWA Low Power Wide Area

LTE Long-Term Evolution

LTE-M LTE-Machine Type Communication

LSB Least Significant Bit

M2M Machine to Machine

MAC Medium Access Control

MAC CE MAC Control Element

MBB Mobile Broadband

MBMS Multimedia Broadcast Multicast Services

Mbps Megabits per second

MBSFN Multimedia Broadcast multicast service Single Frequency Network

MBSFN ABS MBSFN Almost Blank Subframe

MCS Modulation and Coding Scheme

MCSt Multi Consecutive Slot Transmission

MDBV Maximum Data Burst Volume

MDT Minimization of Drive Tests

MEO Medium Earth Orbit ps Microsecond

MIB Master Information Block

MICO Mobile Originated Communication Only

MIMO Multiple Input Multiple Output

MME Mobility Management Entity mMTC Massive Machine Type Communication

MR Mixed Reality

MRTD Maximum Receive Timing Difference ms Millisecond

MSB Most Significant Bit

MSC Mobile Switching Center

Msg Message

Msgl Message 1 of 4-step Random Access procedure

Msg2 Message 2 of 4-step Random Access procedure

Msg3 Message 3 of 4-step Random Access procedure

Msg4 Message 4 of 4-step Random Access procedure

Msg5 Message 5 of 4-step Random Access procedure

MsgA Message A of 2-step Random Access procedure

MsgB Message B of 2-step Random Access procedure

MTC Machine Type Communication

MT-SDT Mobile Terminated Small Data Transmission

NACK Negative Acknowledgement

NB-IoT Narrowband Internet of Things

NG The interface between the RAN and the core network in 5G/NR

NGC Next Generation Core

NGc The control plane part of NG NGu The user plane part of NG NPDCCH Narrowband Physical Downlink Control Channel NPRACH NB-IoT Physical Random Access Channel NR New Radio NTN Non-Terrestrial Network NUL Normal Uplink NW Network OCNG OFDMA Channel Noise Generator OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OSI Other System Information OSS Operations Support System OTDOA Observed Time Difference of Arrival O&M Operation and Maintenance P Poll-bit PBCH Physical Broadcast Channel PC Power Control P-CCPCH Primary Common Control Physical Channel PCell Primary Cell PCFICH Physical Control Format Indicator Channel PCH Paging Channel PCI Physical Cell Identity/Identifier PDB Packet Delay Budget PDCCH Physical Downlink Control Channel PDCP Packet Data Convergence Protocol PDP Profile Delay Profile PDSCH Physical Downlink Shared Channel PDU Protocol Data Unit PER Packet Error Rate PGW Packet Gateway PHICH Physical Hybrid-ARQ Indicator Channel PHY Physical Layer PLMN Public Land Mobile Network PMI Precoder Matrix Indicator PO PUSCH Occasion PRACH Physical Random Access Channel PRB Physical Resource Block PRS Positioning Reference Signal PS Packet Switched PSBCH Physical Sidelink Broadcast Channel PSCCH Physical Sidelink Control Channel PSSCH Physical Sidelink Shared Channel PSCell Primary Secondary Cell PSC Primary serving Cell PSM Power Saving Mode PSS Primary Synchronization Signal PUCCH Physical Uplink Control Channel PUR Pre-configured Uplink Resources PUSCH Physical Uplink Shared Channel QAM Quadrature Amplitude Modulation QoE Quality of Experience QoS Quality of Service R Reserved RA Random Access RACH Random Access Channel RAB Radio Access Bearer RAI Release Assistance Information RAN Radio Access Network RANAP Radio Access Network Application Part RAPID Random Access Preamble Identifier RAR Random Access Response RA-RNTI Random Access-Radio Network Temporary Identifier RAT Radio Access Technology RB Resource Block RE Resource Element RF Radio Frequency RLC Radio Link Control RUM Radio Link Monitoring RMSI Remaining Minimum System Information RMTC RSSI Measurement Timing Configuration RNC Radio Network Controller RNTI Radio Network Temporary Identifier RO RACH Occasion (equivalent to PRACH occasion) RRC Radio Resource Control RRM Radio Resource Management RRH Remote Radio Head RRU Remote Radio Unit RS Reference Signal RSCP Received Signal Code Power RSRP Reference Signal Received Power RSRQ Reference Signal Received Quality RSSI Received Signal Strength Indicator RSTD Reference Signal Time Difference RTT Roundtrip Time RU Resource Unit RV Redundancy Version RX Receiver RWR Release with Redirect SCC Secondary Component Carrier SCH Synchronization Channel SCI Sidelink Control Information SCell Secondary Cell SCG Secondary Cell Group scs Subcarrier Spacing SDAP Service Data Adaptation Protocol SDT Small Data Transmission SDU Service Data Unit SeNB Secondary eNodeB SFN System Frame Number SFTD SFN and Frame Timing Difference SGW Serving Gateway SI System Information or Study Item SIB System Information Block SIB I System Information Block Type 1 SID Study Item Description SINR Signal to Interference and Noise Ratio SL Sidelink SL-U Sidelink Unlicensed SMTC SSB Measurement Timing Configuration SN Sequence Number SNR Signal to Noise Ratio S-NSSAI Single Network Slice Selection Assistance Information SO Segment Offset SON Self Organizing Network SRI SRS Resource Indicator SRS Sounding Reference Signal ss Synchronization Signal SSB Synchronization Signal Block S-SSB Sidelink Synchronization Signal Block ssc Secondary Serving Cell sss Secondary Synchronization Signal SUL Supplementary Uplink TA Timing Advance TAT Time Alignment Timer TB Transport Block TBS Transport Block Size TC-RNTI Temporary Cell RNTI TDD Time Division Duplex TDOA Time Difference of Arrival TDM Time Division Multiplexing TLE Two-Line Element Set/Two-Line Element TM Transparent Mode TOA Time of Arrival TR Technical Report TS Technical Specification TSS Tertiary Synchronization Signal TTI Transmission Time Interval TX Transmitter UAI UE Assistance Information

UARFCN UTMS Absolute Radio Frequency Channel Number

UCI Uplink Control Information

UE User Equipment

UL Uplink

UL-SCH Uplink Shared Channel

UM Unacknowledged Mode

UMTS Universal Mobile Telecommunication System

UPF User Plane Function

URLLC Ultra-Reliable Low-Latency Communication

USIM Universal Subscriber Identity Module

UTC Coordinated Universal Time

UTDOA Uplink Time Difference of Arrival

UTRA Universal Terrestrial Radio Access

UTRAN Universal Terrestrial Radio Access Network

VoIP Voice over IP

VR Virtual Reality WCDMA Wide CDMA WI Work Item

WLAN Wide Local Area Network XR Extended Reality

REFERENCES

1) Hexa-X, Deliverable D5.3, Final 6G architectural enablers and technological solutions https://hexa-x.eu/wp-content/uploads/2023/05/Hexa-X_D5.3_vL0.pdf

2) http ://pr ofesore s. fi -b. unarm mx/j avi erg/ pub s/W CN C 99. p df

Claims

1. A method performed by a control plane, CP, of a network for enabling packet processing site selection by a packet processing site selector associated with a User Plane Function, UPF, the method comprising at least one of: transmitting (QQ702), to the packet processing site selector, information comprising at least one site selection requirement; and receiving (QQ704), from the packet processing site selector, an indication of a site selected by the packet processing site selector for performing packet processing for a communication session.

2. The method of claim 1, wherein the UPF comprises the associated packet processing site selector.

3. The method of claim 1, wherein the packet processing site selector is separated from and in communication with the associated UPF.

4. The method of any of claims 1 to 3, further comprising transmitting, to the base station, the indication of the site selected in order to establish a PDU Session.

5. The method of any of claims 1 to 4, wherein the method is performed by a Session Management Function, SMF, of the CP.

6. The method of any of claims 1 to 5, wherein at least one of: the at least one site selection requirement is transmitted to the packet processing site selector in a PDU Session setup request, the at least one site selection requirement is transmitted to the packet processing site selector in a N4 Session Establishment or Modification request; and the at least one site selection requirement is transmitted to the packet processing site selector via a N4 interface.

7. The method of any one of claims 1 to 6, wherein the UPF is a multi-site UPF comprising a plurality of Packet Processors, PP, with at least one PP per site, the PPs for performing UPF packet processing.

8. The method of claim 7, wherein the SMF has no knowledge of the plurality of PPs for performing UPF packet processing.

9. The method of claim 7 or claim 8, wherein the SMF has different information than the packet processing site selector relating to user plane, UP, network topology, optionally wherein the SMF has less information than the packet processing site selector relating to UP network topology.

10. The method of claim 9, wherein the SMF has coarse-grained network topology information and the packet processing site selector has fine-grained network topology information.

11. The method of any one of claims 7 to 10, wherein the indication of the site selected by the packet processing site selector comprises at least one of: an indication of a particular one of the plurality of PPs selected by the packet processing site selector for performing packet processing for the communication session, and tunnel endpoint information for the selected one of the plurality of PPs.

12. The method of any one of claims 1 to 11, further comprising obtaining capability information associated with the UPF and/or packet processing site selector, wherein the capability information indicates an ability of the packet processing site selector to perform the site selection.

13. The method of claim 12, wherein at least one of: the capability information is pre-configured in the network Control Plane, CP. the capability information is obtained and/or received from a Network Repository Function, NRF, and the capability information is obtained and/or received when the network CP establishes an association with the UPF and/or packet processing site selector.

14. The method of claim 12 or claim 13, wherein the at least one site selection requirement is transmitted to the packet processing site selector based on the capability information.

15. The method of any one of claims 1 to 14, wherein the at least one site selection requirement comprises at least one of: at least one UPF2RAN latency requirement; at least one latency budget and/or RAN budget; at least one transport budget; and at least one UPF budget.

16. The method of any one of claims 1 to 15, comprising transmitting, to the packet processing site selector, UE location information associated with the communication session.

17. The method of any one of claims 1 to 16, comprising at least one of: receiving, from the packet processing site selector, an indication of a changed RAN UP, for example, a CU-UP, and transmitting, to the packet processing site selector, an indication of a changed RAN UP, for example, a CU-UP.

18. The method of any one of claims 1 to 17, comprising receiving, from the packet processing site selector, information indicating a violation of at least one site selection requirement and, optionally, based on the information indicating the violation of the at least one site selection requirement, initiating a PDU Session reestablishment with a UE for the communication session.

19. A method performed by a packet processing site selector associated with a user plane function, UPF, of a network for enabling site selection, the method comprising at least one of: receiving (QQ802), from a control plane, CP, information comprising at least one site selection requirement; selecting (QQ804) a site from a plurality of sites for performing packet processing for a communication session; and transmitting (QQ806), to at least one of the CP and the selected site, an indication of the site selected for performing the packet processing for the communication session.

20. The method of claim 19, wherein the UPF comprises the associated packet processing site selector.

21. The method of claim 19, wherein the packet processing site selector is separated from and in communication with the associated UPF.

22. The method of any of claims 19 to 21, wherein the site is selected from the plurality of sites based on at least one of: the at least one site selection requirement received from the CP; a user plane, UP, network topology; dynamic information associated with the UP; at least one site selection policy; and load information indicating a respective load of each site in the plurality of sites.

23. The method of any one of claims 19 to 22, wherein at least one of: the CP comprises a Session Management Function, SMF, the at least one site selection requirement is received from the SMF, and the indication of the site selected for performing the packet processing is sent to the SMF.

24. The method of any one of claims 19 to 23, wherein at least one of: the at least one site selection requirement is received in a PDU Session setup request, the at least one site selection requirement is received in a N4 Session Establishment or Modification request; and the at least one site selection requirement is received via a N4 interface.

25. The method of any one of claims 19 to 24, wherein the UPF is a multi-site UPF comprising a plurality of Packet Processors, PP, with at least one PP per site, the PPs for performing UPF packet processing.

26. The method of claim 25, wherein the SMF has no knowledge of the network topology including the plurality of PPs for performing UPF packet processing, and wherein the SMF has no knowledge of the plurality of PPs for performing UPF packet processing.

27. The method of claim 25 or claim 26, wherein the SMF has different information than the packet processing site selector relating to user plane, UP, network topology, optionally wherein the SMF has less information than the packet processing site selector relating to UP network topology.

28. The method of claim 27, wherein the SMF has coarse-grained network topology information, and the packet processing site selector has fine-grained network topology information.

29. The method of any one of claims 25 to 28, wherein the indication of the site selected by the packet processing site selector comprises at least one of: an indication of a PP of the plurality of PPs selected by the packet processing site selector for performing packet processing for the communication session, and tunnel endpoint information for the selected PP of the plurality of PPs.

30. The method of any one of claims 19 to 29, comprising transmitting, to the CP, capability information associated with the UPF and/or packet processing site selector, wherein the capability information indicates an ability of the packet processing site selector to perform the site selection.

31. The method of claim 30, wherein the at least one site selection requirement is received from the CP in response to and/or based on and/or after the capability information is transmitted to the CP.

32. The method of any one of claims 19 to 31, wherein the at least one site selection requirement comprises at least one of: at least one UPF2RAN latency requirement; at least one latency budget and/or RAN budget; at least one transport budget; and at least one UPF budget.

33. The method of any one of claims 19 to 32, comprising receiving, from the CP, UE location information associated with the communication session.

34. The method of any one of claims 19 to 33, comprising at least one of: obtaining information indicating and/or determining a changed RAN UP, for example, a CU-UP; receiving, from the selected site, an indication of a changed RAN UP, for example, a CU- UP; transmitting, to the CP, an indication of a changed RAN UP, for example, a CU-UP, and receiving, from the CP, an indication of a changed RAN UP, for example, a CU-UP.

35. The method of any one of claims 19 to 34, comprising at least one of: determining a violation of the at least one site selection requirement, obtaining information indicating a violation of the at least one site selection requirement, and receiving, from the selected site, information indicating a violation of the at least one site selection requirement transmitting, to the CP, information indicating the violation of the at least one site selection requirement.

36. The method of claim 35, wherein the violation of the at least one site selection requirement is based on at least one of: a changed RAN UP, for example, a CU-CP, and a handover of a UE associated with the communication session to a new CU-CP.

37. A network node comprising processing circuitry configured to perform any of the methods of claims 1 to 18.

38. A network node comprising processing circuitry configured to perform any of the methods of claims 19 to 36.

39. A computer program comprising instructions which when executed on a computer perform any of the methods of claims 1 to 36.

40. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of claims 1 to 36.