Systems and methods for configuring communication with iab mec

Abstract

Disclosed herein are systems and methods for using an integrated access and backhaul (IAB) node configured to provide multi-access edge computing (MEC) functionality. The IAB node can include a MEC functionality that includes an instance of an application configured for MEC. A UE using the application connects to the network over an access link with the IAB node and establishes a PDU session for traffic of the application with a core network (CN). The CN can determine that the traffic corresponds to the application and that an instance of the application exists on the IAB node. Accordingly, the CN can instruct the IAB donor to instantiate a remote packet data convergence protocol (PDCP) layer and, in some cases, a remote service data application (SDAP) layer configured to route traffic from the UE of the application to the instance of the application on the IAB node.

Description

Technical Field

[0001] This application generally relates to wireless communication systems, including systems and methods for using integrated access and backhaul (IAB) nodes configured to provide multi-access edge computing (MEC) functionality at the IAB node. Background Technology

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless communication devices. Wireless communication system standards and protocols can include, for example, 3GPP Long Term Evolution (LTE) (such as 4G), 3GPP New Radio (NR) (such as 5G), and the IEEE 802.11 standard for Wireless Local Area Networks (WLANs) (often referred to within industry organizations as...). ).

[0003] As envisioned by 3GPP, different wireless communication system standards and protocols can use various radio access networks (RANs) to enable RAN base stations (which are sometimes also called RAN nodes, network nodes, or simply nodes) to communicate with wireless communication equipment called user equipment (UEs). 3GPP RANs may include, for example, Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and / or Next Generation Radio Access Network (NG-RAN).

[0004] Each RAN can use one or more Radio Access Technologies (RATs) for communication between the base station and the UE. For example, GERAN implements the GSM and / or EDGE RAT, UTRAN implements the Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RATs, E-UTRAN implements the LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements the NR RAT (sometimes also referred to herein as the 5G RAT, 5G NR RAT, or simply NR). In some deployments, E-UTRAN may also implement the NR RAT. In some deployments, NG-RAN may also implement the LTE RAT.

[0005] The base stations used by a RAN can correspond to that RAN. An example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB). An example of an NG-RAN base station is a Next Generation Node B (sometimes also called gNodeB or gNB).

[0006] The RAN provides communication services to external entities through its connection with the core network (CN). For example, E-UTRAN can utilize the evolved packet core network (EPC), while NG-RAN can utilize the 5G core network (5GC). Attached Figure Description

[0007] To facilitate identification of any particular element or action being discussed, one or more of the most significant digits in the reference numerals refer to the drawing number in which the element was first introduced.

[0008] Figure 1 An IAB network according to one implementation scheme is shown.

[0009] Figure 2 A user plane protocol architecture for IAB according to one implementation is shown.

[0010] Figure 3 An IAB network according to one implementation scheme is shown.

[0011] Figure 4 An IAB network according to one implementation scheme is shown.

[0012] Figure 5 An IAB MEC according to one implementation is shown.

[0013] Figures 6A to 6C A flowchart for establishing a PDU session between a UE and an IAB MEC is shown according to one implementation scheme.

[0014] Figure 7 A method for providing an IAB node for MEC is shown according to one implementation.

[0015] Figure 8 A method for operating a CN with an IAB node configured to provide MEC is shown according to one embodiment.

[0016] Figure 9 A method for operating an IAB node configured to provide MEC is shown according to one embodiment.

[0017] Figure 10 An exemplary architecture of a wireless communication system according to an embodiment disclosed herein is shown.

[0018] Figure 11 A system for performing signaling between a wireless device and a network device according to an embodiment disclosed herein is shown.

[0019] Figure 12 An exemplary service-based architecture according to certain implementation schemes is shown.

[0020] Figure 13 The PDU session establishment process according to one implementation is shown.

[0021] Figure 14 A service-based representation of the overall architecture for a policy and billing control framework, according to one implementation scheme, is shown.

[0022] Figure 15 A reference point representation of the overall architecture for a policy and billing control framework according to one implementation is shown. Detailed Implementation

[0023] Various embodiments are described with respect to the UE. However, references to the UE are provided for illustrative purposes only. Exemplary embodiments may be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE described herein is used to represent any suitable electronic component.

[0024] Millimeter-wave (mmWave) deployments of wireless networks can utilize fiber backhaul to carry traffic at NR speeds. However, providing fiber backhaul for the numerous nodes used for mmWave coverage can be difficult or costly. In some systems, integrated access and backhaul (IAB) can be used to overcome the deployment costs of ultra-dense NR mmWave networks by implementing wireless backhaul links to relay access traffic.

[0025] The IAB architecture enables multi-hop routing, where each of the hierarchical IAB nodes acts as an access node to the UE and provides radio backhaul links to other IAB nodes and / or IAB providers connected to the CN. On the radio backhaul, the Backhaul Adaptive Protocol (BAP) layer enables multiple hop routing through the system. BAP allows IAB nodes and / or IAB providers to communicate with each other and provides several functions, including, for example, mapping of next-hop radio link control (RLC) channels, traffic-based routing to next-hop IAB nodes / IAB providers, indication of network events (e.g., radio link failure (RLF)), data transmission, and / or flow control feedback signaling.

[0026] Figure 1 An IAB network 100 according to one embodiment is shown. The IAB network 100 includes an IAB donor 102, which is communicatively connected to a 5GC 104 via a fiber optic backhaul 116. This connection may include an NG interface.

[0027] IAB donor 102 includes a control unit (CU) 118 and one or more distributed units (DUs) (e.g., DU 1 120 and DU 2 122).

[0028] IAB network 100 also includes IAB nodes 106 (shown as IAB node 1-1), 108 (shown as IAB node 2-1), 110 (shown as IAB node 1-2), 112 (shown as IAB node 2-2), and 114 (shown as IAB node 2-3). IAB nodes may include Mobile Terminal Functions (MT) and Duties Units (DUs). Figure 1 As shown, IAB node 106 includes MT 124 and DU 126, IAB node 108 includes MT 128 and DU 130, IAB node 110 includes MT 132 and DU 134, IAB node 112 includes MT 136 and DU 138, and IAB node 114 includes MT 140 and DU 142.

[0029] Within the IAB network 100, IAB nodes 106 to 114 and IAB donor 102 can be connected to other IAB nodes and / or IAB donors in IAB nodes 106 to 114 and / or IAB donor 102 via one or more wireless backhauls between DU and MT. For example, IAB donor 102 and IAB node 106 are connected via a first wireless backhaul 144 between DU 1 120 of IAB donor 102 and MT 124 of IAB node 106, and IAB donor 102 and IAB node 110 are connected via a second wireless backhaul 146 between DU 2 122 of IAB donor 102 and MT 132 of IAB node 110. IAB node 106 and IAB node 108 are connected via a third wireless backhaul 148 between DU 126 of IAB node 106 and MT 128 of IAB node 108. IAB nodes 110 and 112 are connected via a fourth wireless backhaul 150 between DU 134 of IAB node 110 and MT 136 of IAB node 112. IAB nodes 112 and 114 are connected via a fifth wireless backhaul 152 between DU 138 of IAB node 112 and MT 140 of IAB node 114.

[0030] Finally, the IAB network 100 includes a UE 156 connected to a DU 142 of IAB node 114. DU 142 can provide an access link 154 for this connection. Therefore, UE 156 operates with 5GC 104 via a communication relay through IAB nodes 114, 112, 110, and IAB donor 102. Those skilled in the art will recognize from the disclosure herein that any of IAB nodes 106 through 114 and / or IAB donor 102 can also provide access to one or more other UEs via an access link with a corresponding DU.

[0031] The CU 118 of IAB donor 102 can provide basic control plane functionality throughout the IAB network 100. In some embodiments, the CU 118 of IAB donor 102 includes a CU control plane (CU-CP), a CU-user plane (CU-UP), and / or other functions.

[0032] DUs (e.g., DU 1 120, DU 2 122, DU 126, DU 130, DU 134, DU 138 and / or DU 142) can be configured to communicate with other entities within the IAB network 100 (e.g., communicate with sub-IAB nodes via wireless backhaul, and / or communicate with one or more UEs in the manner described above on the access link).

[0033] The MTs of IAB nodes (e.g., MT 124 of IAB node 106, MT 128 of IAB node 108, MT 132 of IAB node 110, MT 136 of IAB node 112, and / or MT 140 of IAB node 114) include components that configure the IAB node to behave similarly to a conventional UE. For example, in MTs with additional enhancements discussed in 3GPP Releases 16 and 17, protocols typically used by UEs to connect to the RAN are supported. For example, the MT in an IAB node allows the IAB node to establish a Signaling Radio Bearer (SRB) and / or a Data Radio Bearer (DRB) with its parent node. The MT can also perform cell selection to identify which parent entity to join and establish and utilize one or more protocol layers (e.g., including a BAP layer) that provide functionality for carrying routed data for different UEs across the network on different routes.

[0034] IAB nodes 106 to 114 can each act as a "parent" and / or "child" of one or more other IAB nodes connected to them. An IAB node that is closer to the route to IAB donor 102 (in hops on the wireless backhaul) than another IAB node it is connected to can be considered the "parent" node of that other IAB node. For example, in Figure 1 In this context, IAB node 106 is the parent node of IAB node 108. An IAB node located further along the route from IAB donor 102 (in hops over the wireless backhaul) than the other IAB node it is connected to can be considered a "child" node of that other IAB node. For example, IAB node 112 is a child node of IAB node 110. Similarly, IAB donor 102 can be understood as the parent node of both IAB node 106 and IAB node 110 (which are each child node of IAB donor 102).

[0035] Using one or more of IAB donor 102 and IAB nodes 106 to 114, instead of a single transmit / receive point in a geographic area, can improve the overall coverage of the UE in the geographic area covered by IAB network 100. For example, in development areas, the use of IAB nodes 106 to 114 can improve line-of-sight (LoS) coverage around corners. Furthermore, the location of IAB nodes 106 to 114 away from IAB donor 102 can generally increase the coverage of IAB network 100.

[0036] Figure 2 A user plane protocol architecture for IAB 200 according to one embodiment is illustrated. The user plane protocol architecture for IAB 200 shows the various protocol layers of UE 202, first IAB node 208 (IAB node 1), second IAB node 204 (IAB node 2), and IAB provider 206. As shown, each layer may correspond to an MT, DU, or CU-UP entity. The DU and CU-UP of IAB provider 206 can communicate via the F1-U interface 210 within the provider. In this example, UE 202 wirelessly communicates with second IAB node 204 via a dedicated DRB on access link 216. Second IAB node 204 wirelessly relays uplink traffic to first IAB node 208 via first radio backhaul 214, and first IAB node 208 wirelessly relays uplink traffic to IAB provider 206 via second radio backhaul 212. Protocol layers include, for example, Media Access Control (MAC), RLC, Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), Internet Protocol (IP), User Datagram Protocol (UDP), and General Packet Radio Service (GPRS) Tunneling Protocol User Plane (GTP-U).

[0037] The user plane protocol architecture for IAB 200 also includes a BAP layer, which provides functionality for routing data for different UEs across different routes over the network. This is accomplished via an adaptation layer header that includes information for identifying the bearer. The routing involves mapping incoming data to outgoing links based on the bearer identifier.

[0038] Figure 3 An IAB network 300 according to one embodiment is shown. The IAB network 300 may include Figure 1 The IAB donors 102, 5GC 104, IAB node 106, IAB node 108, IAB node 110, IAB node 112, and IAB node 114 (together with their components and connections to each other, in order to Figure 1 (the method described).

[0039] exist Figure 3In one implementation, 5GC 104 may include a Multi-Access Edge Computing (MEC) function 302. MEC function 302 may provide one or more instances of one or more network communication-related applications used by a UE of IAB network 300 (e.g., application #1 instance 308 and application #2 instance 310, but fewer or more application instances may be provided in alternative implementations). Each of application #1 instance 308 and application #2 instance 310 may communicate with the UE of IAB network 300 via the user plane function (UPF) of 5GC 104, respectively. According to MEC function 302, once established, each of application #1 instance 308 and / or application #2 instance 310 may be updated and / or sent to other external instances of the application (e.g., via 5GC 104 and via the Internet) to keep the various instances of the application consistent across the scale of IAB network 100. Then, due to the proximity of application #1 instance 308 / application #2 instance 310 (within MEC function 302 of 5GC 104), the corresponding application can operate with the UE of IAB network 300 much faster than if instances of the applications the UE communicates with were only available outside of 5GC 104 (e.g., via the Internet). This acceleration is likely due to reduced latency caused by information not being propagated as "far" (e.g., back to 5GC 104 via a related hop from IAB network 300).

[0040] Furthermore, the IAB network 300 includes a first non-public network (NPN) / standalone non-public network (SNPN) 304 and a second NPN / SNPN 306. Each of these may include one or more UEs (not shown), which are configured for dedicated communication according to the configuration of the respective NPN / SNPN. The UE of the first NPN / SNPN 304 is connected to DU 142 of the IAB node 114 via a first plurality of access links 312, and the UE of the second NPN / SNPN 306 is connected to DU 142 of the IAB node 114 via a second plurality of access links 314.

[0041] Using NPN / SNPN allows for better network management and the ability to build private networks using additional features such as network slicing. For example, application #1 instance 308 can be configured to serve a UE of the first NPN / SNPN 304 on the first network slice, and application #2 instance 310 can be configured to serve a UE of the second NPN / SNPN 306 on the second network slice.

[0042] In some cases, depending on the application and the network slice of the NPN / SNPN, it may be designed to enable the corresponding application to be transmitted over the IAB network 300 to meet certain Quality of Service (QoS) requirements. For example, an application may be configured to use Ultra Reliable Low Latency Communication (URLLC) with its UE, which means, for example, that the application's data is delivered between the UE and the 5GC of the corresponding NPN / SNPN within a certain amount of time and / or with a certain level of reliability.

[0043] However, these QoS requirements for applications may not be guaranteed in IAB network 300 (even when the relevant application #1 instance 308 and / or application #2 instance 310 are located in 5GC 104 according to MEC function 302). This may be due to the IAB nature of IAB network 300. For example, the number of hops from IAB node 114 back to IAB donor 102 and 5GC 104 (which includes application #1 instance 308 and application #2 instance 310) can introduce latency to the extent that the QoS requirements of the application data are not met. It should be further noted that in at least some networks, there is no upper limit on the number of IAB nodes / hops that may exist in the network, meaning that such latency due to hops is theoretically relatively high for UEs connected to 5GC 104 via routes using many IAB nodes. Furthermore, in some IAB architectures, IAB nodes can freely choose to access different parent IAB nodes based on network conditions (e.g., IAB node 114, which provides access to UEs for first NPN / SNPN 304 and / or second NPN / SNPN 306, can be reselected as a child node of IAB node 108 instead of IAB node 112). In such cases, the potential speed on the new route to 5GC (e.g., via IAB node 108, IAB node 106, and IAB donor 102) may not guarantee the fulfillment of the application's QoS requirements. Finally, each hop through the network represents a potential point of failure in information transmission, making routes with a large number of hops across various IAB nodes potentially have lower overall reliability.

[0044] Figure 4 An IAB network 400 according to one embodiment is shown. The IAB network 400 may include... Figure 1 The IAB donors 102, 5GC 104, IAB node 106, IAB node 108, IAB node 110, IAB node 112, and IAB node 114 (together with their components and connections to each other, in order to Figure 1(as described above). Furthermore, the IAB network 400 may also include a first NPN / SNPN 304 having a UE with a DU 142 connected to the IAB node 114 via a first plurality of access links 312, and a second NPN / SNPN 306 having a UE with a DU 142 connected to the IAB node 114 via a second plurality of access links 314, as per [the above description]. Figure 3 As described.

[0045] exist Figure 4 In the middle, MEC function 302 is already located on IAB node 114 (instead of as...). Figure 3 In 5GC 104). MEC function 302 includes application #1 instance 308 and application #2 instance 310, as these instances are also relative to Figure 3 Description. IAB nodes that can act as MEC edge nodes can be described as IAB MECs in this paper.

[0046] The location of MEC function 302 within IAB node 114 (e.g., the use of IAB MEC) allows for relatively low latency and high reliability communication between the UEs of the first NPN / SNPN 304 and / or the second NPN / SNPN 306 and their corresponding application #1 instance 308 and / or application #2 instance 310 (due to the elimination of the need for hop traversals back to 5GC 104 via IAB node 114 and IAB node 112, IAB node 112 and IAB node 110, and IAB node 110 and IAB donor 102). Furthermore, by using IAB MECs with application #1 instance 308 and application #2 instance 310, the applications can continue to function with the UEs of the first NPN / SNPN 304 and the second NPN / SNPN 306 even if the route back to 5GC 104 from IAB node 114 is congested or non-functional. The use of IAB MEC also allows for more finely tuned device (UE) and network (corresponding NPN / SNPN) management, while still ensuring that accounting and other centralized management capabilities from the operator's perspective are maintained. Finally, IAB MEC can enable new service models. For example, third-party IAB MECs can be developed, customized for use with certain applications (e.g., configured to provide certain application instances).

[0047] It is also conceivable that positioning MEC function 302 at IAB node 114 could be advantageous for UE applications that connect to IAB node 114 and correspond to, for example, application #1 instance 308 or application #2 instance 310, but not (must) be used on the corresponding NPN / SNPN. In other words, in Figure 4 The use of the first NPN / SNPN 304 and the second NPN / SNPN 306 in the implementation shown herein is given by way of example, and it is conceivable that the benefits of positioning MEC functionality on IAB nodes as described herein do not inherently require the NPN / SNPN to be established in this way.

[0048] Various potential use cases for IAB MEC are envisioned. For example, IAB MEC can be used to host application instances of applications to utilize augmented reality (AR), virtual reality (VR) and / or vehicle-to-everything (V2X) communications, industrial Internet of Things (IIOT) applications, or any other situation that may benefit from the ability to meet relatively stringent QoS requirements (e.g., low latency and / or high reliability) in an IAB network environment.

[0049] It is conceivable that in some cases, multiple IAB MECs can be used in repeater configurations. It is also conceivable that in some cases, multiple IAB MECs can be used to form a local network including IAB MECs. For each of these options, at least two operating modes are envisioned. In the first mode, each IAB MEC can operate in a sidelink relay mode. In the second mode, each IAB MEC is centrally controlled by a macro node, depending on the required capacity.

[0050] To practically and commercially implement IAB MEC, various considerations may need to be taken into account. The first category of these considerations relates to core 3GPP functionalities. Firstly, the enabling of third-party equipment that is not involved in the original equipment manufacturer (OEM) integration process within the operator network can be considered. Therefore, a framework for integrating third-party IAB MEC into existing bearer networks may be beneficial.

[0051] Secondly, the IAB MEC will need to implement content caching technology that retrieves appropriate content (e.g., for updating application instances at IABMEC) via the CU. Since IAB nodes may not provide direct contact between the IAB node and the 5GC, the CU of the IAB provider may have to implement this operation. Therefore, existing mechanisms of the IAB network can be updated accordingly within the RAN and CN domains to take this into account.

[0052] Third, in some cases, it may be necessary to move the UPF to the IAB MEC. Therefore, the mechanism of a distributed UPF architecture may be beneficial.

[0053] Fourth, security with third-party relays may be an issue, especially in the segmented PDCP architecture to be discussed. Relatedly, frameworks for solutions to interoperability issues can be developed (in the case of different vendors for IAB MEC and UE).

[0054] The second category of these considerations relates to 3GPP usage. Situations are anticipated where, due to backhaul failures on the IAB MEC and / or backhaul, or other failures from the parent node to the IAB MEC, some services of an application will operate while other services are offline (e.g., services that allow the application to access the internet via a failed route may be offline). For example, in the event of a backhaul and / or node failure between the IAB MEC and the corresponding CU on the IAB provider, the UE can still be provided with the local content of the application available at the application instance at the IAB MEC. However, services requiring a real-time connection to the internet may not function. If this situation is not handled properly, this combination could provide a confusing user experience. Therefore, applications can be implemented to ensure a uniform experience across these instances (or to take appropriate actions to ensure the user understands the reasons for the differences in experience).

[0055] The third category of these considerations relates to the 3GPP RAN. First, in some IAB nodes, there may not be a PDCP layer capable of connecting the IAB node to the MEC functionality present on the 5GC. For example, in some cases, the IAB node terminates at the RLC layer, while the MEC functionality (currently possibly within the 3GPP core) communicates using the IP layer. Furthermore, alternatively positioning the MEC at the CU of the IAB provider (which can communicate via IP) might defeat the purpose of positioning the MEC, as the UEs requiring service might still be subject to multiple hops from the IAB provider (and thus still be limited by QoS issues originating from hop requirements).

[0056] Secondly, in some cases (e.g., commercial deployments), IAB nodes and the IAB supplier's CU communicate using an F1 interface. It's possible that the relevant F1AP standard is vendor-driven and extends to the implementation by the network operator and / or network node vendor. Therefore, there may not be a simple way to create an F1 interface between the IAB supplier's CU and the third-party IAB node. Thus, in the case of IAB MEC, it may be necessary to consider an alternative to the F1-C interface to ensure proper control of the IABMEC through the IAB supplier's CU.

[0057] The systems and methods described herein can describe mechanisms that can be used to securely and seamlessly integrate IAB MECs (including third-party IAB MECs) into operator networks. These can take into account the architectural impact on such systems, describe the CN functions available from the IAB provider for accessing and managing IAB MEC functions, modifications required to the protocol stack in the IAB MEC and / or other nodes, and / or modifications to the scheduling and authorization request procedures executed on the IAB MEC, among other possibilities.

[0058] Figure 5 An IAB MEC 502 according to one embodiment is shown. The IAB MEC 502 includes a Building Radio Access Station (PRAS) 504 and an Enhanced Residential Gateway (eRG) 506. The PRAS 504 includes a PHY layer 508, a MAC layer 510, an RLC layer 512, and a BAP layer 514, which can be used for IAB communication using IAB nodes in some embodiments, such as regarding, for example... Figure 2 The second IAB node 204 is described. PRAS 504 may also include NAS and RRC layers 516, which may be associated with the IAB UE functionality of IAB MEC 502 (as shown in the figure).

[0059] eRG 506 may include a PDCP layer 518 and (in some embodiments) an SDAP layer 520. As shown, these may be associated with the IAB gNB functionality of IAB MEC 502. eRG 506 may also include an IAB UPF 522 associated with a Data Network Access Identifier (DNAI) 524. The IAB UPF 522 can be used for application instances provided by IAB MEC 502 in the manner described above. As shown, DNAI 524 may be provided to PRAS 504 to allow UPF registration with the CN, as will be described.

[0060] The functional division between PRAS 504 and eRG 506 in IAB MEC 502 is given by way of example rather than limitation. In other words, IAB MEC can have... Figure 5 The functions described do not need to be formally distinguished between PRAS and eRG.

[0061] The IAB MEC 502 can receive instructions to send certain QoS flows to the IAB UPF 522 (e.g., based on the system mapping between the QoS flows and instances of applications on the IAB UPF 522). Therefore, the PDCP layer 518 of the IAB MEC 502 can be configured to route those QoS flows to the IAB UPF 522.

[0062] In some implementations (e.g., where there is no SDAP layer 520 in IAB MEC 502), there may be a one-to-one correspondence between the DRBs of the UE and IAB MEC 502 and the QoS flows indicated therein. In this case, PDCP layer 518 can route QoS flows to IAB UPF 522 by routing their associated DRBs to IAB UPF 522.

[0063] In other implementations (e.g., where an SDAP layer 520 is present in IAB MEC 502), one or more indicated QoS flows can be mapped to the same DRB via / through the SDAP layer 520.

[0064] In other implementations (e.g., where the IAB MEC 502 and SDAP layer 520 are present), there may be no restrictions on the mapping of indicated QoS flows to specific DRBs. In such cases, SDAP layer 520 may route PDCP PDUs belonging to indicated QoS flows to IAB UPF 522 and further reroute PDCP PDUs belonging to non-indicated QoS flows to the upstream IAB provider for reception at the CN. In such cases, the PDCP layer for the same DRB is locally instantiated at both the UE and the IAB MEC node. Plane signaling between these instances can be controlled along the E1' interface to provide coherence between the UE's protocol layer and the IAB MEC 502.

[0065] Figures 6A to 6C A flowchart 600 is shown for establishing a PDU session between UE 602 and IAB MEC 604 according to one embodiment. The PDU session between UE 602 and IAB MEC 604 allows applications operating on UE 602 to function together with instances of applications existing on the MEC function of the IAB MEC, as described above.

[0066] Flowchart 600 also illustrates IAB donor 606 and CN 608. In flowchart 600, UE 602 may have already established an access link with IAB MEC 604. IAB MEC 604 can communicate with IAB donor 606 via its radio backhaul (directly or indirectly through another IAB node (not shown)). IAB donor 606 can be connected to CN 608 via fiber optic backhaul. CN 608 may be, for example, a 5GC, as shown in the figure.

[0067] IAB MEC 604 includes IAB gNB function 610, IAB UPF 612, and IAB UE function 614. IAB gNB function 610 may include functionality for operating IAB MEC 604 within a gNB context (e.g., as an access node for UE 602). IAB UPF 612 may include instances of applications for which a PDU session is set up (which may operate together with applications on UE 602). IAB UE function 614 may include functionality for operating IAB MEC 604 within a UE context (e.g., as a child of IAB donor 606). IAB MEC 604 may instantiate IAB UPF 612 (including application instances) based on its previously programmed / configured state, or CN 608 may provide IAB UPF 612 instructions for instantiating IAB UPF 612 and / or the included application instances.

[0068] CN 608 includes Access and Mobility Management Function (AMF) 616, Session Management Function (SMF) 618, UPF 620, Network Repository Function (NRF) 622, Policy Control Function (PCF) 624, and Application Function (AF) 626.

[0069] Flowchart 600 includes authorization and configuration 628 for the CU of IAB UPF 612 and IAB provider 606. Authorization and configuration 628 can be performed through the Operations, Administration and Maintenance (OAM) aspects set up by the Mobile Network Operator (MNO) of CN 608. Parameters provided to IAB UPF 612 as part of authorization and configuration 628 include DNAI to identify IAB UPF 612, access information (e.g., Fully Qualified Domain Name (FQDN) and / or IP address), and credentials for accessing NRF 622.

[0070] Flowchart 600 includes communication 630 between IAB MEC 604 and AF 626 of CN 608 to provide AF 626 with the DNAI of IAB UPF 612, as well as information about / identifying the application that IAB UPF 612 is targeting its managed instance. Communication 630 can be an application-level interaction that can occur multiple times. For example, communication 630 can occur when IAB MEC 604 registers at CN 608. Communication 630 can also occur whenever a new application instance is instantiated in IAB UPF 612.

[0071] Flowchart 600 includes creating a traffic routing rule 632 at AF 626 using traffic filtering information corresponding to the DNAI information of an application (e.g., as provided in communication 630). Creation 632 can be an application-level interaction that can occur multiple times (e.g., whenever information about the DNAI information is received from the application at IAB MEC 604 according to communication 630).

[0072] Flowchart 600 includes registering the IAB UE functionality 614 of IAB MEC 604 with the AMF 616 of CN 608. This registration 634 can provide the AMF 616 of CN 608 with capability information of IAB MEC 604. For example, it can provide an indication that IAB MEC 604 is capable of providing access to a local service hosting environment. In such cases, the indication can indicate that IAB MEC 604 is capable of operating the IAB UPF 612 functionality and the PDCP layer of IAB provider 606. In some cases, the indication can also indicate that IAB MEC 604 is capable of operating the SDAP layer of IAB provider 606.

[0073] Flowchart 600 includes the establishment of a PDU session 636 between the IAB UE function 614 of IAB MEC 604 and the UPF 620 of CN 608.

[0074] Although registration 634 and creation 636 have been shown to occur simultaneously with creation 632, it should be understood that creation 632 may occur before or after either registration 634 or creation 636.

[0075] Flowchart 600 includes entries for the capabilities of IAB UPF 612 of IAB MEC 604 registered with NRF 622 of CN 608 (638). As part of registration 638, IAB MEC 604 contacts NRF 622 and registers the Network Function (NF) profile of IAB UPF 612 with NRF 622. This NF profile may include the IAB node identifier of IAB MEC 604 and the IP address corresponding to the PDU session between IAB UE function 614 of IAB MEC 604 and UPF 620 of CN 608. This NF profile may also specify the capabilities of the UPF (e.g., whether it communicates via Internet Protocol (IP)v4 and / or IPv6, etc.).

[0076] Flowchart 600 includes the capabilities of IAB UPF 612, the IP address of the PDU session between IAB UE function 614 and UPF 620, and the storage 640 of the IAB node identifier at NRF 622 for IAB MEC 604. This information will later enable CN 608 to reach IAB UPF 612 within IAB MEC 604.

[0077] Flowchart 600 includes the provision of information from NRF 622 to SMF 618 on IAB UPF 612, denoted by 642. For example, in CN 608, one or more SMFs (including SMF 618) may have subscribed to receiving information about a new UPF NF profile via NRF 622. Therefore, NRF 622 can notify SMF 618 about the NF profile of IAB UPF 612. SMF 618 can determine that IAB UPF 612 exists on IAB MEC 604 by locating the IAB node identifier of IAB MEC 604 in the NF function of IAB UPF 612 on NRF 622. In some implementations, provision 642 is optional. Alternatively, without performing provision 642, the SMF can determine that IAB UPF 612 exists on IAB MEC 604 via another configuration method (e.g., via proprietary OAM signaling).

[0078] Flowchart 600 includes UE 602's registration to / with CN 608 and PDU session establishment 644. UE 602 can communicate with CN 608's PCF 624 to establish a PDU session between UE 602 and the core network's UPF 620. This can occur as part of a session management (SM) procedure. It should be noted that in flowchart 600, the communication shown between UE 602 and CN 608 occurs via IAB MEC 604 (with which UE 602 has a direct access link) and IAB provider 606 (and via any intermediate IAB nodes (not shown) between IAB MEC 604 and IAB provider 606).

[0079] As part of the registration and PDU session establishment 644, SMF 618 queries PCF 624 to obtain SM Policy and Charging Control (PCC) rules. PCF 624 can provide SM PCC rules associated with the PDU session between UE 602 and CN 608, such as those received from AF 626, generated by PCF 624 based on DNAI information and the identification of the application being hosted by IAB UPF 612 for its managed instance. SMF 618 uses these SM PCC rules to create traffic detection rules for this traffic at UPF 620.

[0080] Flowchart 600 includes the provision of user location information for UE 602 from AMF 616 to SMF 618, 646. The user location information for UE 602 may have already been determined by AMF 616 as part of registration and PDU session establishment 644. As part of the user location information, the IAB node identifier of IAB MEC 604 (with which UE 602 has an access link) can be provided. This information can be included in the Nsmf_PDUSession_CreateSMContext information element passed from AMF 616 to SMF 618 as part of the SM context establishment at SMF 618. This informs SMF 618 to provide (most directly) network access to UE 602 via IAB MEC 604 (e.g., the access link used by UE 602 for network communication is with IAB MEC 604). Provision 646 can occur (as part) during registration and PDU session establishment 644.

[0081] Flowchart 600 includes a start 648 corresponding to user plane traffic for an application that can be routed to local access in a service-hosted environment (e.g., an application instance of IAB UPF 612) between UE 602 and CN 608's UPF 620.

[0082] Flowchart 600 includes a notification 650 from UPF 620 to SMF 618 that traffic corresponding to a previously configured traffic filter of AF 626 exists between UE 602 and UPF 620 (e.g., the traffic satisfies the conditions of IAB UPF 612 corresponding to the SM PCC rule associated with the PDU session between UE 602 and CN 608 for routing the traffic). Notification 650 may occur in response to UPF 620 determining that the SM PCC rule applies to the traffic, wherein, for this purpose, UPF 620 uses the traffic detection rule configured to UPF 620 by SMF 618 during registration and PDU session establishment 644.

[0083] Flowchart 600 includes selecting 652 at SMF 618 to use IAB UPF 612 based on the identified SM PCC rules that allow traffic to be routed to IAB UPF 612, the IAB node identifier of IABMEC 604, and information about the known IAB UPF of AMF 616. For example, due to the detection and subsequent notification 650 of UPF 620 as described above, SMF 618 can determine, based on the SM PCC rules, that traffic can be routed to IAB UPF 612.

[0084] Furthermore, SMF 618 can know that IAB UPF 612 exists on IAB MEC 604 due to the NF profile information (including the IAB node identifier of IAB MEC 604) provided to SMF 618. SMF 618 can also know that UE 602 (which provides the traffic in question) is connected to IAB MEC 604 due to the provision of user location information 646, which includes the IAB node identifier of UE 602 through which it connects to IAB MEC 604 of SMF 618. Therefore, SMF 618 can determine that UE 602 communicates with the network via the same IAB MEC 604 having IAB UPF 612 by matching the IAB node identifier from the user location information of UE 602 with the IAB node identifier from the NF profile of IAB UPF 612.

[0085] Therefore, based on the determination that the traffic between the network and the UE 602 corresponds to the SM PCC rule, and the determination that each of the NF profile of the IAB UPF 612 and the user location information of the UE 602 includes the (same) IAB node identifier of the IAB MEC 604, the SMF 618 determines that the traffic can (and should, for example, be) routed to the IAB UPF 612 of the IAB MEC 604 (instead of, for example, UPF 620 of CN 608). The SMF 618 can utilize the new QoS identifier to route the traffic to the IAB UPF 612.

[0086] Flowchart 600 includes an N4 establishment procedure 654 between SMF 618 and IAB UPF 612. For example, an N3 tunnel establishment can be performed, and IAB UPF 612 can be enabled to handle traffic from UE 602 within the network. The N4 establishment procedure 654 can be based on the IP address of the current PDU session between IAB UE function 614 of IAB MEC 604 and UPF 620 of CN 608. This IP address can be used as the IP address of IAB UPF 612 from the perspective of upstream elements (e.g., IAB donor 606 and / or CN 608).

[0087] Flowchart 600 includes NG-RAN configuration 656 between SMF 618 and IAB provider 606. SMF 618 can notify IAB provider 606 about the new QoS identifier. As part of NG-RAN configuration 656, SMF 618 can also notify IAB provider 606 of the IAB node identifier of the IAB MEC 604 to which the identified QoS flows should be routed.

[0088] Flowchart 600 includes instantiation 658 of the PDCP layer and (optionally) the SDAP layer in the IAB MEC 604 by IAB provider 606. This can occur according to instructions provided to the IAB MEC 604 by IAB provider 606 as part of instantiation 658. Reflecting their presence within the IAB node (IAB MEC 604) rather than, for example, within IAB provider 606, these layers can be understood as “remote” layers (e.g., remote PDCP layer and remote SDAP layer). Instructions from IAB provider 606 can configure the remote PDCP layer (and any remote SDAP layer) to route traffic associated with identified QoS flows (e.g., as per [reference to...]). Figure 5 As described, this relates to IAB UPF 612. In some cases, remote PDCP layers (and any remote SDAP layers) can be instantiated in the eRG of IAB MEC604 (e.g., Figure 5 (As shown).

[0089] Flowchart 600 includes PDU session modification 660 between SMF 618 and UE 602. As part of PDU session modification 660, SMF 618 may instruct UE 602 to allocate traffic to be routed to IAB UPF 612 to new QoS flows. These instructions may also include the IAB node identifier of IAB MEC 604.

[0090] Figure 7 A method 700 for providing an IAB node for MEC according to one embodiment is shown. Method 700 includes instantiating an IAB UPF 702 at the IAB node.

[0091] Method 700 also includes providing the CN with instructions that the 704IAB node is capable of operating the remote PDCP layer of the IAB UPF and the IAB donor.

[0092] Method 700 further includes instantiating the remote PDCP layer 706 according to an instruction received from the IAB donor, wherein the instruction includes an identifier for a QoS flow, and wherein the remote PDCP layer is configured to route the QoS flow to the IAB UPF.

[0093] Method 700 also optionally includes instantiating a 708 remote SDAP layer according to instructions received from an IAB provider, wherein the remote PDCP layer is configured to route QoS flows to the IAB UPF.

[0094] Method 700 also includes routing the QoS flow 710 to the IAB UPF via a remote PDCP layer.

[0095] Method 700 may also optionally include routing the QoS flow 712 to the IABUPPF via the remote SDAP layer.

[0096] In some implementations of method 700, the DRB of the QoS flow is established by a UE connected to the IAB node.

[0097] In some implementations, method 700 further includes registering the NF profile of the IAB UPF with the NRF of the CN, the NF profile including the IP address corresponding to the PDU session between the IAB node and the CN and the identifier of the IAB node.

[0098] In some implementations, method 700 also includes performing N4 establishment of IAB UPF and CN.

[0099] In some implementations, method 700 also includes sending the DNAI of the IAB UPF and the identification of the application associated with the IAB UPF to the CN.

[0100] In some implementations, method 700 also includes receiving DNAI from IAB UPF.

[0101] In some implementations, method 700 also includes receiving credentials for accessing the CN via an NRF.

[0102] The embodiments envisioned herein include an apparatus comprising means for performing one or more elements of method 700. This apparatus may be, for example, an IAB node (such as network device 1116 as an IAB node, as described herein).

[0103] The embodiments envisioned herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 700. The non-transitory computer-readable medium may be, for example, the memory of an IAB node (such as the memory 1120 of network device 1116 as an IAB node, as described herein).

[0104] The embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry for performing one or more elements of method 700. This apparatus may be, for example, an IAB node (such as network device 1116 as an IAB node, as described herein).

[0105] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media, the computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 700. This apparatus may be, for example, an IAB node (such as network device 1116 as an IAB node, as described herein).

[0106] The implementation scheme envisioned herein includes a signal as described in or in connection with one or more elements of method 700.

[0107] The embodiments envisioned herein include a computer program or computer program product comprising instructions, wherein the execution of the program by a processing element causes the processing element to perform one or more elements of method 700. The processor may be a processor of an IAB node (such as processor 1118 of network device 1116 as an IAB node, as described herein). For example, these instructions may reside in the processor and / or in the memory of the IAB node (such as memory 1120 of network device 1116 as an IAB node, as described herein).

[0108] Figure 8 A method 800 for operating a CN with an IAB node configured to provide MEC is illustrated according to one embodiment. Method 800 includes receiving, 802, an indication from the IAB node that the IAB node is capable of operating the IAB UPF and a remote PDCP layer of the IAB donor.

[0109] Method 800 also includes receiving, 804, an NF configuration file of the IAB UPF containing the identifier of the IAB node from the IAB node.

[0110] Method 800 also includes determining, for the UE, user location information including the identifier of the IAB node in step 806.

[0111] Method 800 further includes determining, based on PCC rules associated with the PDU session between the CN and the UE and determining that each of the NF profile of the IAB UPF and the user location information of the UE includes the identifier of the IAB node, that the traffic of the UE is directed to the IAB UPF.

[0112] Method 800 also includes identifying QoS flows used for traffic 810.

[0113] Method 800 also includes sending an indication to the IAB provider that the QoS flow described in 812 will be routed to the IAB UPF.

[0114] Method 800 further includes sending an instruction 814 to the UE to allocate the traffic to the QoS flow.

[0115] In some implementations of method 800, the indication that the QoS flow will be routed to the IAB UPF includes the identifier of the QoS flow and the identifier of the IAB node.

[0116] In some embodiments of method 800, the user location information is determined during the establishment of a PDU session between the CN and the UE.

[0117] In some implementations of method 800, the NF profile of the IAB UPF also includes the IP address corresponding to the PDU session between the IAB node and the CN.

[0118] In some implementations, method 800 further includes performing an N4 establishment between the IAB UPF and the IAB node based on the IP address corresponding to the PDU session between the IAB node and the CN.

[0119] In some implementations, method 800 further includes receiving the DNAI of the IAB node and the identification of the application associated with the IAB UPF from the IAB node, and generating PCC rules based on the DNAI and the identification of the application associated with the IAB UPF.

[0120] In some implementations of method 800, the CN's NRF notifies the CN's SMF about the NF profile of the IAB UPF.

[0121] In some implementations of method 800, the UPF of the CN determines that the PCC rule applies to the traffic.

[0122] In some embodiments of method 800, the SMF of the CN determines that each of the NF profile of the IAB UPF and the user location information from the UE includes the identifier of the IAB node.

[0123] The embodiments contemplated herein include an apparatus comprising means for performing one or more elements of method 800. This apparatus may be, for example, a CN-type apparatus.

[0124] The embodiments envisioned herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 800. Such non-transitory computer-readable media may be, for example, a memory (or an element thereof) of a CN.

[0125] The embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry for performing one or more elements of method 800. This apparatus may be, for example, a CN-type apparatus.

[0126] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media, the computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 800. The apparatus may be, for example, a CN-type apparatus.

[0127] The implementation scheme envisioned herein includes a signal as described in or in connection with one or more elements of method 800.

[0128] The embodiments envisioned herein include a computer program or computer program product comprising instructions, wherein the program is executed by a processing element to cause the processing element to perform one or more elements of method 800. The processor may be a processor (or an element thereof) of CN. These instructions may, for example, be located in / on a processor and / or memory (or an element thereof) of CN.

[0129] Figure 9 A method 900 for operating an IAB provider with an IAB node configured to provide MEC, according to one embodiment, is shown. Method 900 includes receiving an indication from a CN that a 902 QoS flow will be routed to an IAB UPF of the IAB node.

[0130] Method 900 further includes sending a first instruction to the IAB node 904 to instantiate a remote PDCP layer of the IAB provider at the IAB node, wherein the remote PDCP layer is configured to route QoS flows to the IAB UPF.

[0131] Method 900 also optionally includes sending a second instruction 906 to the IAB node to instantiate a remote SDAP layer of the IAB provider at the IAB node, wherein the remote SDAP layer is configured to route QoS flows to the IAB UPF.

[0132] In some embodiments of method 900, the indication includes an identifier for the QoS flow and an identifier for the IAB node.

[0133] In some implementations of method 900, the first instruction includes an identifier for the QoS flow.

[0134] The embodiments envisioned herein include an apparatus comprising means for performing one or more elements of method 900. This apparatus may be, for example, an IAB donor apparatus.

[0135] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 900. The non-transitory computer-readable medium may be, for example, memory provided by an IAB donor.

[0136] The embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry for performing one or more elements of method 900. This apparatus may be, for example, an IAB donor apparatus.

[0137] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 900. The apparatus may be, for example, an IAB donor.

[0138] The implementation scheme envisioned herein includes a signal as described in or in connection with one or more elements of method 900.

[0139] The embodiments envisioned herein include a computer program or computer program product comprising instructions, wherein the program is executed by a processing element to cause the processing element to perform one or more elements of method 900. The processor may be an IAB-provided processor. These instructions may, for example, reside in the IAB-provided processor and / or in memory.

[0140] Figure 10 An exemplary architecture of a wireless communication system 1000 according to an embodiment disclosed herein is shown. The description provided below is for an exemplary wireless communication system 1000 operating in conjunction with LTE system standards and / or 5G or NR system standards provided by 3GPP technical specifications.

[0141] like Figure 10As shown, the wireless communication system 1000 includes UE 1002 and UE 1004 (however, any number of UEs may be used). In this example, UE 1002 and UE 1004 are shown as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device configured for wireless communication.

[0142] UE 1002 and UE 1004 can be configured to communicate with RAN 1006. In this implementation, RAN 1006 can be NG-RAN, E-UTRAN, etc. UE 1002 and UE 1004 utilize connections (or channels) with RAN 1006 (shown as connection 1008 and connection 1010, respectively), where each connection (or channel) includes a physical communication interface. RAN 1006 may include one or more base stations, such as base station 1012 and base station 1014, that implement connection 1008 and connection 1010.

[0143] In this example, Connection 1008 and Connection 1010 are air interfaces that enable this type of communication coupling and can conform to the RAT used by RAN1006, such as LTE and / or NR.

[0144] In some implementations, UE 1002 and UE 1004 may also exchange communication data directly via sidelink interface 1016. UE 1004 is shown configured to access an access point (shown as AP 1018) via connection 1020. By way of example, connection 1020 may include a local wireless connection, such as a connection conforming to any IEEE 1102.11 protocol, wherein AP 1018 may include... Router. In this example, AP 1018 can connect to another network (e.g., the Internet) without going through CN 1024.

[0145] In the implementation scheme, UE 1002 and UE 1004 may be configured to communicate with each other or with base station 1012 and / or base station 1014 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals, based on various communication technologies, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), although the scope of the implementation scheme is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0146] In some implementations, all or part of base station 1012 or base station 1014 may be implemented as one or more software entities running on a server computer as part of a virtual network. Furthermore, or in other implementations, base station 1012 or base station 1014 may be configured to communicate with each other via interface 1022. In implementations where the wireless communication system 1000 is an LTE system (e.g., when CN 1024 is an EPC), interface 1022 may be an X2 interface. This X2 interface may be defined between two or more base stations (e.g., two or more eNBs, etc.) connected to the EPC and / or between two eNBs connected to the EPC. In implementations where the wireless communication system 1000 is an NR system (e.g., when CN 1024 is a 5GC), interface 1022 may be an Xn interface. This Xn interface is defined between two or more base stations (e.g., two or more gNBs, etc.) connected to the 5GC, between base station 1012 (e.g., a gNB) connected to the 5GC and an eNB, and / or between two eNBs connected to the 5GC (e.g., CN 1024).

[0147] RAN 1006 is shown communicatively coupled to CN 1024. CN 1024 may include one or more network elements 1026 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 1002 and UE 1004) connected to CN 1024 via RAN 1006. Components of CN 1024 may be implemented in a single physical device or in separate physical devices, including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media).

[0148] In the implementation scheme, CN 1024 may be an EPC, and RAN 1006 may be connected to CN 1024 via S1 interface 1028. In the implementation scheme, S1 interface 1028 may be divided into two parts: an S1 user plane (S1-U) interface, which carries traffic data between base station 1012 or base station 1014 and the serving gateway (S-GW); and an S1-MME interface, which is the signaling interface between base station 1012 or base station 1014 and the mobility management entity (MME).

[0149] In this implementation, CN 1024 may be a 5GC, and RAN 1006 may be connected to CN 1024 via NG interface 1028. In this implementation, NG interface 1028 may be divided into two parts: an NG User Plane (NG-U) interface, which carries traffic data between base station 1012 or 1014 and the User Plane Function (UPF); and an S1 Control Plane (NG-C) interface, which is the signaling interface between base station 1012 or 1014 and the Access and Mobility Management Function (AMF).

[0150] Generally, application server 1030 can be an element providing Internet Protocol (IP) bearer resources (e.g., packet-switched data services) for use with CN 1024. Application server 1030 can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for UE 1002 and UE 1004 via CN 1024. Application server 1030 can communicate with CN 1024 via IP communication interface 1032.

[0151] Figure 11 A system 1100 for performing signaling 1132 between a wireless device 1102 and a network device 1116, according to an embodiment disclosed herein, is illustrated. System 1100 may be part of a wireless communication system as described herein. Wireless device 1102 may be, for example, a UE (User Equipment) of the wireless communication system. Network device 1116 may be, for example, an IAB node or IAB donor of the wireless communication system.

[0152] Wireless device 1102 may include one or more processors 1104. Processor 1104 may execute instructions to perform various operations of wireless device 1102 as described herein. Processor 1104 may include one or more baseband processors implemented using, for example, a central processing unit (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a controller, a field-programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof for performing the operations described herein.

[0153] Wireless device 1102 may include memory 1106. Memory 1106 may be a non-transitory computer-readable storage medium that stores instructions 1108 (which may include, for example, instructions executed by processor 1104). Instructions 1108 may also be referred to as program code or a computer program. Memory 1106 may also store data used by processor 1104 and results calculated by the processor.

[0154] Wireless device 1102 may include one or more transceivers 1110, which may include radio frequency (RF) transmitter and / or receiver circuitry that uses antenna 1112 of wireless device 1102 to facilitate the transmission and / or reception of signaling (e.g., signaling 1132) between wireless device 1102 and other devices (e.g., network device 1116) in accordance with a corresponding RAT.

[0155] Wireless device 1102 may include one or more antennas 1112 (e.g., one, two, four, or more). For implementations with multiple antennas 1112, wireless device 1102 can fully utilize the spatial diversity of these multiple antennas 1112 to transmit and / or receive multiple different data streams on the same time-frequency resource. This practice may be referred to, for example, as a multiple-input multiple-output (MIMO) approach (referring to multiple antennas used separately on the transmitting and receiving sides to achieve this). MIMO transmissions performed by wireless device 1102 can be achieved according to precoding (or digital beamforming) applied to wireless device 1102, which multiplexes data streams among antennas 1112 based on known or assumed channel characteristics, such that each data stream is received with appropriate signal strength relative to the others at a desired location in the spatial domain (e.g., the location of the receiver associated with that data stream). Some implementations may use a single-user MIMO (SU-MIMO) method (where the entire data stream is directed to a single receiver) and / or a multi-user MIMO (MU-MIMO) method (where individual data streams may be directed to individual (different) receivers at different locations in the airspace).

[0156] In some implementations with multiple antennas, wireless device 1102 may implement analog beamforming technology, whereby the phase of the signal transmitted by antenna 1112 is relatively adjusted, making the (joint) transmission of antenna 1112 directional (this is sometimes referred to as beam control).

[0157] Wireless device 1102 may include one or more interfaces 1114. Interfaces 1114 can be used to provide input or output to wireless device 1102. For example, wireless device 1102 as a UE may include interfaces 1114, such as a microphone, speaker, touchscreen, buttons, etc., to allow users of the UE to input and / or output to the UE. Other interfaces of such UEs may consist of transmitters, receivers, and other circuitry (e.g., in addition to the transceiver 1110 / antenna 1112 already described), allowing the UE to communicate with other devices and according to known protocols (e.g., ...). (etc.) to perform the operation.

[0158] Network device 1116 may include one or more processors 1118. Processor 1118 may execute instructions to perform various operations of network device 1116 as described herein. Processor 1104 may include one or more baseband processors, which are implemented using, for example, a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof for performing the operations described herein.

[0159] Network device 1116 may include memory 1120. Memory 1120 may be a non-transitory computer-readable storage medium that stores instructions 1122 (which may include, for example, instructions executed by processor 1118). Instructions 1122 may also be referred to as program code or a computer program. Memory 1120 may also store data used by processor 1118 and results calculated by the processor.

[0160] Network device 1116 may include one or more transceivers 1124, which may include RF transmitter and / or receiver circuitry that uses the antenna 1126 of network device 1116 to facilitate the transmission and / or reception of signaling (e.g., signaling 1132) between network device 1116 and other devices (e.g., wireless device 1102) in accordance with the corresponding RAT.

[0161] Network device 1116 may include one or more antennas 1126 (e.g., one, two, four or more). In embodiments with multiple antennas 1126, network device 1116 may perform MIMO, digital beamforming, analog beamforming, beam control, etc., as described above.

[0162] Network device 1116 may include one or more interfaces 1128. Interface 1128 can be used to provide input or output to network device 1116. For example, network device 1116 as a base station may include interface 1128 consisting of transmitters, receivers and other circuitry (e.g., in addition to the transceiver 1124 / antenna 1126 described), enabling the base station to communicate with other equipment in the core network, and / or enabling the base station to communicate with external networks, computers, databases, etc., for the purpose of performing operations, management and maintenance of the base station or other equipment operablely connected to it.

[0163] Network device 1116 may include IAB MEC module 1130. IAB MEC module 1130 may be implemented in hardware, software, or a combination thereof. For example, IAB MEC module 1130 may be implemented as a processor, circuitry, and / or instructions 1122 stored in memory 1120 and executed by processor 1118. In some examples, IAB MEC module 1130 may be integrated within processor 1118 and / or transceiver 1124. For example, IAB MEC module 1130 may be implemented using a combination of software and hardware components (e.g., logic gates and circuitry systems) within processor 1118 or transceiver 1124, executed by a DSP or general-purpose processor.

[0164] The IAB MEC module 1130 can be used in various aspects of this disclosure, for example, Figures 7 to 9 In various aspects. For example, for network device 1116 acting as an IAB node for MEC (IAB MEC), IAB MEC module 1130 can be configured to host an IAB UPF with one or more application instances, instantiate a remote PDCP layer and / or a remote SDAP layer for application traffic, and route traffic from wireless device 1102 to the IAB UPF via the remote PDCP layer and / or remote SDAP layer according to the QoS flow associated with the application instances on the IAB UPF. As another example, for network device 1116 acting as an IAB donor, IAB MEC module 1130 can receive instructions from the CN to instantiate a remote PDCP layer and / or a remote SDAP layer on one of its child IAB nodes, the remote PDCP layer and / or remote SDAP layer being configured to be used with application-enabled traffic of the MEC having instances on the IAB node, and thus causing instantiation on the child IAB node. In addition, the IAB MEC module 1130 can identify one or more QoS flows to the sub-IAB node. When used by a PDU session at the UE, the QoS flow should be routed by the sub-IAB node to the application instance on the IAB sub-node via a remote PDCP layer and / or a remote SDAP layer.

[0165] In some implementations, the 5G system architecture supports data connectivity and services, enabling deployment using technologies such as network function virtualization and software-defined networking. The 5G system architecture can leverage service-based interactions between control plane network functions. Separating user plane functions from control plane functions allows for independent scalability, evolution, and flexible deployment (e.g., centralized or distributed (remote) locations). Modular function design allows for function reuse and enables flexible and efficient network slicing. Network functions and their network function services can interact directly or indirectly with another NF and its network function services via a service communication broker. Another intermediate function helps route control plane messages. This architecture minimizes dependencies between the AN and CN. The architecture may include an aggregated core network with a common AN-CN interface integrating different access types (e.g., 3GPP access and non-3GPP access). The architecture also supports a unified authentication framework, stateless NFs that decouple compute and storage resources, capability exposure, concurrent access to local and centralized services (to support low-latency services and access to local data networks, with user plane functions deployed near the AN), and / or roaming in the visited PLMN using both home-routed traffic and local breakout traffic.

[0166] A 5G architecture can be defined as service-based, and interactions between network functions can include service-based representations, where a network function within the control plane (e.g., an AMF) enables other authorized network functions to access its services. Service-based representations can also include point-to-point reference points. Reference point representations can also be used to illustrate interactions between NF services within network functions described by point-to-point reference points (e.g., N11) between any two network functions (e.g., AMF and SMF).

[0167] Figure 12 A service-based architecture 1200 in 5GS according to one implementation is shown. As described in 3GPP TS23.501, the service-based architecture 1200 includes NFs such as NSSF 1208, NEF 1210, NRF 1214, PCF 1212, UDM 1226, AUSF 1218, AMF 1220, and SMF 1222 for communicating with UE 1216, (R)AN 1206, UPF 1202, and DN 1204. NFs and NF services can communicate directly (referred to as direct communication) or indirectly via SCP 1224 (referred to as indirect communication). Figure 12 It also shows the corresponding service-based interfaces including Nutm, Naf, Nudm, Npcf, Nsmf, Nnrf, Namf, Nnef, Nnssf, and Nausf, as well as reference points N1, N2, N3, N4, and N6. The following describes the interfaces provided by... Figure 12Some exemplary functions provided by NF are shown in the figure.

[0168] NSSF 1208 supports functions such as: selecting the set of network slice instances serving the UE; determining the allowed NSSAIs and, if necessary, the mapping to subscribed S-NSSAIs; determining the configured NSSAIs and, if necessary, the mapping to subscribed S-NSSAIs; and / or determining the set of AMFs to be used to serve the UE, or, based on the configuration, possibly by querying the NRF to determine a list of candidate AMFs.

[0169] The NEF 1210 supports the exposure of capabilities and events. NF capabilities and events can be securely exposed by the NEF 1210 (e.g., for third parties, application functions, and / or edge computing). The NEF 1210 can use a standardized interface (Nudr) to the UDR to store / retrieve information as structured data. The NEF 1210 can also securely provide information from external applications to the 3GPP network and can provide application functions to securely provide information to the 3GPP network (e.g., anticipated UE behavior, 5GLAN group information, and service-specific information), where the NEF 1210 can authenticate and authorize and help restrict application functions. The NEF 1210 can provide internal-external information translation by translating information exchanged with the AF 1228 and information exchanged with internal network functions. For example, the NEF 1210 translates between the AF service identifier and internal 5G core information (such as DNN and S-NSSAI). The NEF 1210 can handle the masking of network and user-sensitive information to external AFs according to network policies. The NEF 1210 can receive information from other network functions (based on the exposure capabilities of those functions) and store the received information as structured data using a standardized interface to the UDR. The stored information can then be accessed by the NEF 1210 and re-exposed to other network and application functions for purposes such as analysis. For external exposure of services related to a specific UE, the NEF 1210 can reside in the HPLMN. Depending on the operator agreement, the NEF 1210 in the HPLMN can have an interface with the NF in the VPLMN. When the UE is able to switch between EPC and 5GC, SCEF+NEF can be used for service exposure.

[0170] NRF 1214 supports service discovery by receiving NF discovery requests from NF instances or SCPs and providing information about discovered NF instances to the NF instances or SCPs. NRF 1214 also supports P-CSCF discovery (a special case of SMF discovery AF), maintaining NF profiles of available NF instances and their supported services, and / or notifying subscribed NF service consumers or SCPs of newly registered / updated / deregistered NF instances along with their NF services. In the context of network slicing, multiple NRFs can be deployed at different levels depending on the network implementation, such as PLMN level (NRFs configured with information for the entire PLMN), shared slice level (NRFs configured with information for a set of network slices), and / or slice-specific level (NRFs configured with information for S-NSSAI). In the context of roaming, multiple NRFs can be deployed in different networks, where the NRF in the visited PLMN (referred to as vNRF) is configured with information about the visited PLMN, and the NRF in the home PLMN (referred to as hNRF) is configured with information about the home PLMN, referenced by the vNRF via the N27 interface.

[0171] PCF 1212 supports a unified policy framework for managing network behavior. PCF 1212 provides policy rules for control plane functions to enforce them. PCF 1212 accesses subscription information related to policy decisions in the Unified Data Repository (UDR). PCF 1212 can access the UDR located in the same PLMN as PCF.

[0172] UDM 1226 supports the generation of 3GPP AKA authentication credentials, user identification processing (e.g., storage and management of SUPI for each subscriber in a 5G system), de-hiding of privacy-preserving subscription identifiers (SUCI), access authorization based on subscription data (e.g., roaming restrictions), UE service NF registration management (e.g., storing AMF for UE storage services, storing SMF for UE PDU sessions), service / session continuity (e.g., maintaining SMF / DNN allocation for ongoing sessions), MT-SMS delivery, lawful interception functionality (especially in outbound roaming scenarios where the UDM is the only contact point for the LI), subscription management, SMS management, 5G LAN group management processing, and / or external parameter configuration (expected UE behavior parameters or network configuration parameters). To provide such functionality, UDM 1226 uses subscription data (including authentication data) that can be stored in the UDR. In this case, the UDM implements application logic and may not require internal user data storage, and several different UDMs can provide services to the same user in different transactions. UDM 1226 can reside in the HPLMN of its service subscribers and can access information about UDRs located in the same PLMN.

[0173] AUSF 1218 supports authentication for 3GPP access and untrusted non-3GPP access. AUSF 1218 also provides support for network slicing-specific authentication and authorization.

[0174] The AMF 1220 supports the termination of the RAN CP interface (N2), the termination of the NAS (N1) for NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (for AMF events and interfaces to the LI system), transmission of SM messages between the UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization, transmission of SMS messages between the UE and SMSF, SEAF, location service management for regulated services, transmission of location service messages between the UE and LMF and between the RAN and LMF, EPS bearer ID allocation for interoperability with EPS, UE mobility event notification, control plane CIoT 5GS optimization, user plane CIoT 5GS optimization, configuration of external parameters (expected UE behavior parameters or network configuration parameters) and / or network slice-specific authentication and authorization. Some or all of the AMF functions can be supported in a single instance of the AMF 1220. Regardless of the number of network functions, in some implementations, only one NAS interface instance per access network between the UE and the CN terminates with one of the network functions that implements at least NAS security and mobility management. The AMF 1220 may also include policy-related functions.

[0175] In addition to the functions described above, the AMF 1220 may also include the following functions supporting non-3GPP access networks: support for the N2 interface with N3IWF / TNGF, on which some information (e.g., 3GPP cell identifier) ​​and procedures (e.g., handover related) defined on 3GPP access may not be applicable, and non-3GPP access-specific information that is not applicable to 3GPP access can be applied; support for NAS signaling for UEs via N3IWF / TNGF, where some procedures supported by NAS signaling on 3GPP access may not be applicable to untrusted non-3GPP (e.g., paging) access; support for authentication of UEs connected via N3IWF / TNGF; management of mobility, authentication, and separate security context states for UEs connected via non-3GPP access or simultaneously via 3GPP access or non-3GPP access; support for effective coordination of RM management contexts on both 3GPP and non-3GPP access; and / or support for dedicated CM management contexts for UEs connecting via non-3GPP access. In network slicing instances, support for all of the above functions may not be required.

[0176] The SMF 1222 supports session management (e.g., session establishment, modification, and publication, including tunnel maintenance between UPF and AN nodes), UE IP address allocation and management (including optional authorization) (where UE IP addresses can be received from the UPF or from an external data network), DHCPv4 (server and client) and DHCPv6 (server and client) functions, the ability to respond to Address Resolution Protocol (ARP) requests and / or IPv6 neighbor request requests with local cached information based on Ethernet PDUs (e.g., the SMF responds to ARP and / or IPv6 neighbor request requests by providing the MAC address corresponding to the IP address sent in the request), selection and control of user plane functions (including controlling the UPF to proxy ARP or IPv6 neighbor discovery or forwarding all ARP / IPv6 neighbor request traffic to the SMF for Ethernet PDU sessions), traffic-directing configuration at the UPF to route traffic to the appropriate destination, and 5G VN group management (e.g., maintaining the topology of the involved PSA UPF, in the PSA...). Establish and publish N19 tunnels between UPFs, configure traffic forwarding at the UPF to apply local handover, and / or N6-based or N19-based forwarding, terminate the interface for policy control functions, lawful interception (for SM events and interfaces to LI systems), charge for data collection and support the billing interface, control and coordinate billing data collection at the UPF, terminate the SM portion of NAS messages, downlink data notification, initiator of AN-specific SM information sent to the AN via N2 through the AMF, determination of the SSC mode of the session, control plane CIoT 5GS optimization, header compression, act as I-SMF in the deployment of pluggable / removable / repositionable I-SMFs, configure external parameters (expected UE behavior parameters or network configuration parameters), P-CSCF discovery for IMS services, roaming functions (e.g., handling local implementation to apply QoS SLA (VPLMN), billing data collection and billing interface (VPLMN) and / or lawful interception (for SM events and interfaces to LI systems), and / or terminate the interface for policy control functions, lawful interception (for SM events and interfaces to LI systems), charge for data collection and support the billing interface, control and coordinate billing data collection at the UPF, terminate the SM portion of NAS messages, downlink data notification, initiator of AN-specific SM information sent to the AN via the AMF through N2, determination of the SSC mode of the session, control plane CIoT 5GS optimization, header compression, act as I-SMF in the deployment of pluggable / removable / repositionable I-SMFs, configure external parameters (expected UE behavior parameters or network configuration parameters), P-CSCF discovery for IMS services, roaming functions (e.g., handling local implementation to apply QoS SLA (VPLMN), billing data collection and billing interface (VPLMN) and / or lawful interception (for SM events and interfaces to LI systems), and / or terminate the interface for policy control functions, lawful interception (for SM events and interfaces to LI), lawful intercept The system interfaces within the VPLMN and interact with external DNs to transmit signaling for PDU session authentication / authorization and / or instruct the UPF and NG-RAN to perform redundant transmissions on the N3 / N9 interfaces. Some or all of the SMF functions may be supported in a single instance of the SMF. However, in some implementations, not all functions need to be supported in instances of network slices. In addition to functionality, SMF 1222 may include policy-related functions.

[0177] SCP 1224 includes one or more of the following functions: indirect communication; delegated discovery; message forwarding and routing to the destination NF / NF service; communication security (e.g., authorization for NF service consumers to access NF service manufacturer APIs), load balancing, monitoring, overload control, etc.; and / or optionally interacting with a UDR to resolve UDM group ID / UDR group ID / AUSF group ID / PCF group ID / CHF group ID / HSS group ID based on UE identity (e.g., SUPI or IMPI / IMPU). Some or all of the SCP functions may be supported in a single instance of the SCP. In some implementations, SCP 1224 may be deployed in a distributed manner and / or more than one SCP may exist in the communication path between NF services. SCPs may be deployed at the PLMN level, shared slice level, and slice-specific level. Carrier deployments may be left to ensure that the SCP can communicate with the relevant NRF.

[0178] UE 1216 may include devices with radio communication capabilities. For example, UE 1216 may include a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks). UE 1216 may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), pager, laptop computer, desktop computer, wireless handheld device, or any computing device that includes a wireless communication interface. UE is also referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. UE 1216 may include an IoT UE, which may include a network access layer designed to utilize low-power IoT applications with short-lived UE connections. The IoT UE may exchange data with an MTC server or device via a PLMN, other UEs using ProSe or D2D communication, a sensor network, or an IoT network using technologies such as M2M, MTC, or mMTC. M2M or MTC data exchange may be machine-initiated data exchange. An IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure). IoT UEs may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0179] UE 1216 can be configured to connect or communicatively couple with (R)AN 1206 via radio interface 1230. This radio interface can be a physical communication interface or layer configured to operate using cellular communication protocols such as GSM, CDMA network protocols, push-to-talk (PTT), cellular PTT (POC), UMTS, 3GPP LTE, 5G, NR, etc. For example, UE 1216 and (R)AN 1206 can use a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack including PHY, MAC, RLC, PDCP, and RRC layers. DL transmissions can be made from (R)AN 1206 to UE 1216, and UL transmissions can be made from UE 1216 to (R)AN 1206. UE 1216 can also use a sidelink to communicate directly with another UE (not shown) for D2D, P2P, and / or ProSe communication. For example, the ProSe interface may include one or more logical channels, including but not limited to the Physical Side Link Control Channel (PSCCH), Physical Side Link Shared Channel (PSSCH), Physical Side Link Discovery Channel (PSDCH), and Physical Side Link Broadcast Channel (PSBCH).

[0180] (R)AN 1206 may include one or more access nodes, which may be referred to as a base station (BS), node B, evolved Node B (eNB), next-generation Node B (gNB), RAN node, controller, transport receiving point (TRP), etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). (R)AN 1206 may include one or more RAN nodes for providing coverage of macrocells, picocells, femtocells, or other types of cells. Macrocells may cover a relatively large geographic area (e.g., with a radius of several kilometers) and may allow UEs to have unrestricted access with a service subscription. Picocells may cover a relatively small geographic area and may allow UEs to have unrestricted access with a service subscription. Femtocells may cover a relatively small geographic area (e.g., a home) and may allow restricted access for UEs associated with a femtocell (e.g., a UE in a closed subscriber group (CSG), a UE of a user in a home, etc.).

[0181] Although not shown, multiple RAN nodes (such as (R)AN 1206) may be used, with Xn interfaces defined between two or more nodes. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U provides non-guaranteed delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C provides management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 1216 in connected modes (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected modes between one or more (R)AN nodes. This mobility support may include context transfer from the old (source) serving (R)AN node to the new (destination) serving (R)AN node; and control of user plane tunnels between the old (source) serving (R)AN node and the new (destination) serving (R)AN node.

[0182] The UPF 1202 can serve as an anchor point for mobility within and between RATs, an external PDU session point interconnected with the DN 1204, and a branch point supporting multi-donor PDU sessions. The UPF 1202 can also perform packet routing and forwarding, packet inspection, enforcement of policy rules in the user plane portion, lawful packet interception (UP collection), traffic usage reporting, QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), uplink traffic authentication (e.g., SDF-to-QoS flow mapping), transport-level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 1202 may include an uplink classifier to support routing traffic flows to the data network. The DN 1204 may represent various network operator services, Internet access, or third-party services. The DN 1204 may include, for example, an application server.

[0183] Some of the implementation schemes disclosed herein can be implemented during the PDU session establishment process. PDU session establishment may correspond to, for example, a UE-initiated PDU session establishment process, a UE-initiated PDU session handover between 3GPP and non-3GPP systems, a UE-initiated PDU session handover from EPS to 5G system (5GS), or a network-triggered PDU session establishment process.

[0184] For example, Figure 13 The PDU session establishment procedure 1300 requested by the UE is shown. Figure 13The PDU session establishment procedure 1300 shown includes messages between the UE 1302, the (radio) access network (shown as (R)AN 1304), the access and mobility management function (shown as AMF 1306), the user plane function (shown as UPF 1308), the session management function (shown as SMF 1310), the policy control function (shown as PCF 1312), the unified data management function (shown as UDM 1314), and the data network (shown as DN 1316). In this example, the call flow in Clause 4.3.2.2 (PDU Session Establishment) of TS 23.502 is used as the basis, and those skilled in the art will understand that the following description is only an overview, and further details can be found in TS 23.502.

[0185] refer to Figure 13 Operation 1, from UE to AMF: NAS message (Single Network Slice Selection Identifier (S-NSSAI), Data Network Name (DNN), PDU Session ID, Request Type, Old PDU Session ID, N1 SM Container (PDU Session Establishment Request)). To establish a new PDU session, the UE generates a new PDU session ID. The UE initiates the PDU session establishment procedure by transmitting a NAS message containing the PDU session establishment request within the N1 SM container. The PDU session establishment request includes the PDU session ID, the requested PDU session type, the requested SSC mode, the 5GSM Capability PCO, the SM PDU DN request container, and the number of packet filters. The request type indicates "Initial Request" when the PDU session establishment is a request to establish a new PDU session, and "Existing PDU Session" when the request refers to a handover of an existing PDU session between 3GPP access and non-3GPP access or a handover of a PDU session from an existing PDN connection in the EPC. If the request refers to an existing PDN connection in the EPC, then S-NSSAI is set up as described in Clause 5.15.7.2 of TS 23.501.

[0186] 5GSM core network capabilities are provided by the UE and processed by the SMF, as defined in Clause 5.4.4b of TS 23.501[2]. 5GSM capabilities also include UE integrity protection maximum data rate. In addition, the UE may indicate to the SMF in the 5GSM capability IE of the PDU session establishment request message that the UE supports the feature “Flexible range of packet filters for RQoS”.

[0187] The number of packet filters indicates the number of packet filters supported by the QoS rules used for signaling the establishment of the PDU session. The number of packet filters indicated by the UE is valid for the duration of the PDU session. For the existence conditions, see TS 24.501.

[0188] refer to Figure 13 In operation 2, the AMF determines that the message corresponds to a request for a new PDU session based on the request type indication "Initial Request," and determines that the PDU session ID is not used for any existing PDU sessions of the UE. If the NAS message does not contain an S-NSSAI, the AMF determines the default S-NSSAI of the requested PDU session based on the UE subscription (if it contains only one default S-NSSAI) or based on operator policy. When the NAS message contains an S-NSSAI but not a DNN, if a default DNN exists in the UE's subscription information, the AMF determines the DNN of the requested PDU session by selecting a default DNN for that S-NSSAI; otherwise, the serving AMF selects a locally configured DNN for that S-NSSAI. If, based on operator policy, the DNN provided by the UE is not supported by the network and the AMF cannot select an SMF by querying the NRF, the AMF rejects the NAS message from the UE containing a PDU session establishment request for an appropriate reason.

[0189] refer to Figure 13Operation 3, from AMF to SMF: Nsmf_PDUSession_CreateSMContext request (Subscription Permanent Identifier (SUPI), DNN, S-NSSAI, PDU Session ID, AMF ID, Request Type, PCF ID, Priority Access, N1SM Container (PDU Session Establishment Request), User Location Information, Access Type, Permanent Device Identifier (PEI), General Public Subscription Identifier (GPSI), UE Presence in Local Area Data Network (LADN) Service Area, Subscription to PDU Session State Notification, DNN Selection Mode) or Nsmf_PDUSession_UpdateSMContext request (SUPI, DNN, S-NSSAI, PDU Session ID, AMF ID, Request Type, N1SM Container (PDU Session Establishment Request), User Location Information, Access Type, RAT Type, PEI). If the AMF does not have an association with an SMF for the PDU session ID provided by the UE (e.g., when the request type indicates "Initial Request"), the AMF invokes the Nsmf_PDUSession_CreateSMContext request. However, if the AMF already has an association with an SMF for the PDU session ID provided by the UE (e.g., when the request type indicates "Existing PDU Session"), the AMF invokes the Nsmf_PDUSession_UpdateSMContext request. The AMF sends the S-NSSAI from the allowed NSSAI to the SMF. For roaming scenarios, the AMF also sends the corresponding S-NSSAI mapped from the allowed NSSAI to the SMF. The AMF may include the PCF ID in the Nsmf_PDU Session_CreateSMContext request. This PCF ID identifies the H-PCF in non-roaming situations and the V-PCF in locally interrupted roaming situations. In some embodiments herein, the AMF may include a value of the 5GSM Capability IE of the PDU Session Establishment Request message, which indicates that the UE supports the feature "Flexible Range of Packet Filters for RQoS".

[0190] refer to Figure 13 Operations 4a to 4b, the process includes registering / subscribing to retrieve / update subscriptions.

[0191] refer to Figure 13 Operation 5, from SMF to AMF: Nsmf_PDU session_create SM context response (reason, SM context ID or N1 SM container (PDU session rejected (reason))) or Nsmf_PDU session_update SM context response, depending on the request received in operation 3.

[0192] Figure 13Operation 6 includes optional PDU session authentication / authorization.

[0193] Figure 13 Operations 7a and 7b include PCF selection and SM policy association establishment or SMF-initiated SM policy association modification.

[0194] Figure 13 Operation 8, UPF selection.

[0195] Figure 13 Operation 9 in the text includes SMF-initiated SM policy association modification.

[0196] Figure 13 Operations 10a and 10b include N4 session establishment / modification requests and N4 session establishment / modification responses.

[0197] refer to Figure 13 Operation 11, SMF to AMF: Namf_Communication_N1N2 Message Transmission (PDU Session ID, N2 SM Information (PDU Session ID, QFI, QoS Profile, CN Tunnel Information, S-NSSAI from Allowed NSSAI, Session-AMBR, PDU Session Type, User Plane Security Execution Information, UE Integrity Protection Maximum Data Rate), N1 SM Container (PDU Session Establishment Acceptance (QoS Rules and QoS Flow Level QoS Parameters (if a QoS flow is required associated with the QoS rule), Selected SSC Mode, S-NSSAI, DNN, Assigned IPv4 Address, Interface Identifier, Session-AMBR, Selected PDU Session Type, Reflection QoS Timer (if available), Reflection QoS Rule Range, P-CSCF Address))). If multiple UPFs are used for a PDU session, the CN tunnel information includes tunnel information associated with the UPF terminating N3. In some implementations of this document, the scope of the reflected QoS rule indicates the following: for IP-type PDU sessions, whether the RQoS scope includes both the source / destination IP address pair and the source / destination port number, or only the former; and for Ethernet-type PDU sessions, whether the RQoS scope includes both the source / destination MAC address pair and the IEEE 802.1Q tag, or only the former.

[0198] The N2 SM information carries information that the AMF should forward to the (R)AN, including: CN tunnel information corresponding to the core network address of the N3 tunnel corresponding to the PDU session; one or more QoS profiles and corresponding QFIs may be provided to the (R)AN. This is further described in Clause 5.7 of TS 23.501; the PDU session ID may be used by AN signaling with the UE to indicate to the UE the association between (R)AN resources and the PDU session for the UE; the PDU session is associated with S-NSSAI and DNN, wherein the S-NSSAI provided to the (R)AN is an S-NSSAI with a value for the serving PLMN; user plane security enforcement information is determined by the SMF as described in Clause 5.10.3 of TS 23.501; and if the user plane security enforcement information indicates that integrity protection is "preferred" or "required", the SMF also includes the UE integrity protection maximum data rate as received in 5GSM capabilities.

[0199] The N1 SM container contains the PDU session establishment acceptance that the AMF should provide to the UE. If the UE requests P-CSCF discovery, this message should also include the P-CSCF IP address determined by the SMF. The PDU session establishment acceptance includes the S-NSSAI from the allowed NSSAI. For roaming scenarios, the PDU session establishment acceptance also includes the corresponding S-NSSAI from the mapping of the allowed NSSAI received by the SMF in Operation 3. Multiple QoS rules, QoS flow level QoS parameters (if necessary, QoS flows associated with those QoS rules), and QoS profiles may be included in the PDU session establishment acceptance within the N1 SM and in the N2 SM information. The Namf_Communications_N1N2 message transmission contains the PDU session ID, which allows the AMF to know which access to the UE to use.

[0200] refer to Figure 13 Operation 12, AMF to (R)AN: N2 PDU Session Request (N2 SM Information, NAS Message (PDU Session ID, N1 SM Container (PDU Session Establishment Acceptance))). The AMF sends a NAS message to the (R)AN containing the PDU Session ID and PDU Session Establishment Acceptance for the UE, as well as the N2 SM Information received from the SMF within the N2 PDU Session Request.

[0201] refer to Figure 13 Operation 13, (R)AN to UE: The (R)AN may issue AN-specific signaling exchanges with the UE in relation to information received from the SMF. For example, in the case of NG-RAN, RRC connection reconfiguration may occur when the UE establishes the necessary NG-RAN resources related to the QoS rules requested by the PDU session received in Operation 12.

[0202] (R)AN also assigns (R)AN N3 t tunnel information to PDU sessions. In dual-connectivity scenarios, the primary RAN node may assign some (zero or more) QFIs to be configured to the primary RAN node and other QFIs to the secondary RAN node. The AN tunnel information includes the tunnel endpoints of each involved (R)AN node, and the QFIs assigned to each tunnel endpoint. QFIs may be assigned to either the primary or secondary RAN node, but not both simultaneously.

[0203] (R)AN will forward the NAS message (PDU session ID, N1 SM container (PDU session establishment acceptance)) provided in step 12 to the UE. (R)AN will only provide the NAS message to the UE if the necessary (R)AN resources are established and the (R)AN tunnel information is successfully allocated.

[0204] Figure 13 Operation 14 in the text includes N2 PDU session request confirmation.

[0205] After the first uplink data, Figure 13 Operation 15 in the middle includes AMF to SMF: Nsmf_PDU session_update SM conversion (N2 SM information, request type).

[0206] refer to Figure 13 In operation 16a, the SMF initiates the N4 session modification procedure using the UPF. The SMF provides the UPF with AN tunnel information and corresponding forwarding rules. Note that if the PDU session establishment request is due to mobility between 3GPP and non-3GPP access points or mobility from the EPC, the downlink data path is switched to the target access point in this step. In some embodiments described herein, the SMF may inform the UPF that RQoS applies to the PDU session for which the PDU session establishment request is made. When the SMF informs the UPF that RQoS applies to a particular PDU session, it also indicates whether the UPF should apply a “reduced” scope of packet filtering to RQoS for that specific PDU session (i.e., whether to use only source / destination IP address pairs as packet filters for IP-type PDU sessions, or only source / destination MAC address pairs for Ethernet-type PDU sessions). For this indication, the SMF may consider support indications received from the UE. The UPF can use this information to: adapt the scope for UL packet inspection; and determine which DL packets need to be labeled with RQI.

[0207] refer to Figure 13In operation 16b, the UPF provides the SMF with an N4 session modification response. If multiple UPFs are used in a PDU session, the UPF in step 16 refers to UPF termination N3. After this step, the UPF will deliver any downlink packets (first downlink data) that may have been buffered for that PDU session to the UE.

[0208] Figure 13 Operation 17 in the context includes SMF to AMF: Nsmf_PDU session_update SM context response.

[0209] Figure 13 Operation 18 in the context includes SMF to AMF: Nsmf_PDU session_SM context state notification.

[0210] Figure 13 Operation 19 in the example includes SMF to UE via UPF: In the case of PDU session type IPv6 or IPv4v6, SMF generates IPv6 router advertisements and sends them to UE via N4 and UPF.

[0211] Figure 13 Operation 20 in the process includes, if the PDU session establishment fails after step 4, the SMF performs unsubscription or deregistration.

[0212] In the above process according to certain implementation schemes, these implementation schemes may be reflected in the content of the PDU session establishment accept message (see, for example, operations 11 to 13). At operation 11, the Namf_communication_N1N2 message transmission operation is performed by the SMF to the AMF. The Namf_communication_N1N2 message transmission indicates or includes the scope of the reflection QoS rules, as well as the PDU session ID, N2 SM information (PDU session ID, QFI, QoS profile, CN tunnel information, S-NSSAI from the allowed NSSAI, session-AMBR, PDU session type, user plane security enforcement information, UE integrity protection maximum data rate), and N1 SM container (PDU session establishment accept (QoS rules and QoS flow level QoS parameters (if a QoS flow is required to be associated with the QoS rules), selected SSC mode, S-NSSAI, DNN, assigned IPv4 address, interface identifier, session-AMBR, selected PDU session type, reflection QoS timer (if available), P-CSCF address))). If multiple UPFs are used for a PDU session, the CN tunnel information includes tunnel information related to the UPF that terminates N3.

[0213] According to some implementation schemes, for IP-type PDU sessions, the reflected QoS rule range indicates to the UE whether the RQoS range includes both the source / destination IP address pair and the source / destination port number, or only the former. For Ethernet-type PDU sessions, the reflected QoS rule range indicates to the UE whether the RQoS range includes both the source / destination MAC address pair and the IEEE 802.1Q tag, or only the former.

[0214] Additionally, in operations 1 and 3, the UE may indicate to the SMF in the PDU session establishment request message (e.g., in the 5GSM capability information element) that the UE supports the feature "flexible range of packet filters for RQoS".

[0215] Furthermore, when the SMF informs the UPF that RQoS applies to a particular PDU session (see, for example, Operation 16a), it also instructs the UPF whether, for that specific PDU session, the UPF should apply a “reduced” scope of the packet filter to RQoS (e.g., for IP-type PDU sessions, whether only source / destination IP address pairs are used as packet filters, or for Ethernet-type PDU sessions, whether only source / destination MAC address pairs are used). The SMF may consider support instructions received from the UE for this instruction. In some implementations, the UPF uses this information to: adapt the scope for UL packet inspection; and / or determine which DL packets need to be labeled with RQI.

[0216] Regarding the UPF's adaptation range for checking UL packets, the UPF examines UL packets sent by the UE to verify that the UE is behaving in a compatible manner, for example, whether it includes the QFI applicable to RQoS Service Data Flow (SDF) only in those UL packets that match the corresponding packet filter. For this task, the UPF may need to know whether the check is performed based on a reduced or full range of the packet filter. If the UE is using a QFI for other packets, the UPF may discard the corresponding packet.

[0217] Regarding the UPF's determination of which DL packets need to be labeled with RQI, as mentioned above, the SDF occurring during a communication session between the UE and some servers in the network can be described by a narrowed single packet filter (e.g., only source / destination IP address pairs) or by a full range of packet filters (e.g., including source / destination IP address pairs and source / destination port numbers). In the full-range case, the UPF may need to ensure that for each of the different source / destination port number pairs used during the communication session, the UPF labels one or more DL packets with RQI, such that the UE creates a corresponding UL packet filter for each of these pairs. However, in the narrowed-range case, labeling one or more DL packets according to the source / destination address pairs may be sufficient for the UPF.

[0218] One exemplary implementation includes a method for controlling the export of QoS rules in a UE by flexibly defining the range of packet header fields exported by performing packet filtering. In some such implementations, the range of packet header fields for exporting QoS rules may be provided to the UE by the network when the PDU session is established or modified. For IP-type PDU sessions, the network indicates to the UE whether the RQoS range includes both the source / destination IP address pair and the source / destination port number, or only the former. For Ethernet-type PDU sessions, the network indicates to the UE whether the RQoS range includes both the source / destination MAC address pair and the IEEE 802.1Q tag, or only the former. In some implementations, the UE indicates to the network whether it supports a flexible range of packet filters for RQoS for the PDU session, whereby the network determines whether to use a flexible range of packet filters for RQoS for the PDU session based at least in part on receiving a support indication from the UE.

[0219] Figure 14 A service-based representation 1400 of the overall architecture of a policy and charging control framework for a 5G system (5GS) according to one implementation is shown. As described in 3GPP TS 23.503, the service-based representation 1400 includes the following functions: policy control functions (shown as PCF 1408), session management functions (shown as SMF 1416), user plane functions (shown as UPF 1402), access and mobility management functions (shown as AMF 1414), network openness functions (shown as NEF 1406), network data analytics functions (shown as NWDAF 1412), charging functions (shown as CHF 1410), application functions (shown as AF 1418), and a unified data store (shown as UDR 1404). Figure 14The corresponding interfaces for Nudr, Nnef, Nnwdaf, Naf, Npcf, Nchf, Namf, and Nsmf are also shown. The N4 reference point may not be part of the 5G policy framework, but it is shown for completeness.

[0220] Figure 15 Reference point representation 1500 is shown, illustrating the overall architecture of a policy and charging control framework for 5GS according to one implementation scheme. As described in 3GPP TS 23.503, reference point representation 1500 includes the following functions: PCF 1408, SMF 1416, UPF 1402, AMF 1414, NEF 1406, NWDAF 1412, CHF 1410, AF 1418, and UDR 1404. Figure 15 The corresponding reference points N5, N23, N36, N30, N29, N28, N40, N15, N7, and N4 are also shown. Reference point N4 may not be part of the 5G strategy framework, but it is shown for completeness.

[0221] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, the baseband processor described herein in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples of the examples described herein. Similarly, the circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples of the examples shown herein.

[0222] Unless otherwise expressly stated, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice of various embodiments.

[0223] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical components for performing the operations, or may include a combination of hardware, software, and / or firmware.

[0224] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is conceivable to use parameters, attributes, aspects, etc., of one implementation in another implementation. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that unless specifically stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.

[0225] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0226] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that many alternative ways exist to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope of the appended claims and their equivalents.

Claims

1. A method for providing an integrated access and backhaul (IAB) node for multi-access edge computing (MEC), comprising: Instantiate the IAB User Plane Function (UPF) at the IAB node; Provide the core network (CN) with instructions that the IAB node is capable of operating the remote packet data convergence protocol (PDCP) layer of the IAB UPF and the IAB donor; The remote PDCP layer is instantiated according to instructions received from the IAB provider, wherein the instructions include an identifier for a Quality of Service (QoS) flow, and wherein the remote PDCP layer is configured to route the QoS flow to the IAB UPF.

2. The method according to claim 1, further comprising: The QoS flow is routed to the IAB UPF via the remote PDCP layer.

3. The method according to claim 2, further comprising: The Remote Service Data Adaptation Protocol (SDAP) layer is instantiated at the IAB node according to the instruction received from the IAB provider, wherein the remote SDAP layer is configured to route the QoS flow to the IAB UPF; as well as The QoS flow is routed to the IAB UPF via the remote SDAP layer.

4. The method of claim 2, wherein the DRB of the QoS flow is established by a UE connected to the IAB node.

5. The method according to claim 1, further comprising: Register the network function (NF) profile of the IAB UPF using the Network Repository Function (NRF) of the CN. The NF profile includes the IP address corresponding to the Protocol Data Unit (PDU) session between the IAB node and the CN and the identifier of the IAB node.

6. The method according to claim 1, further comprising: The IAB UPF is executed to establish N4 with the CN.

7. The method according to claim 1, further comprising: Send the IAB UPF's Data Network Access Identifier (DNAI) and the identification of the application associated with the IAB UPF to the CN.

8. The method according to claim 1, further comprising: Receive the IAB UPF Data Network Access Identifier (DNAI).

9. The method according to claim 1, further comprising: Receive credentials for accessing the Network Repository Function (NRF) of the CN.

10. A method for operating a core network (CN) using integrated access and backhaul (IAB) nodes configured to provide multi-access edge computing (MEC), comprising: Receive from the IAB node a first instruction that the IAB node is capable of operating the IAB User Plane Function (UPF) and the Remote Packet Data Convergence Protocol (PDCP) layer of the IAB donor; Receive the IAB UPF network function (NF) profile, which includes the identifier of the IAB node, from the IAB node; For user equipment (UE), determine user location information including the identifier of the IAB node; Based on the policy and charging control (PCC) rules associated with the PDU session between the CN and the UE, and determining that each of the NF profile of the IAB UPF and the user location information of the UE includes the identifier of the IAB node, it is determined that the UE's traffic is directed to the IAB UPF. Identify the Quality of Service (QoS) flow of the traffic; Send a second indication to the IAB provider that the QoS flow will be routed to the IAB UPF; as well as Send an instruction to the UE to allocate the traffic to the QoS flow.

11. The method of claim 10, wherein the indication that the QoS flow will be routed to the IAB UPF includes the identifier of the QoS flow and the identifier of the IAB node.

12. The method of claim 10, wherein the user location information is determined during the establishment of a PDU session between the CN and the UE.

13. The method of claim 10, wherein the NF configuration file of the IAB UPF further includes an IP address corresponding to the PDU session between the IAB node and the CN.

14. The method of claim 13, further comprising: Based on the IP address corresponding to the PDU session between the IAB node and the CN, the IABBUPF and the IAB node's N4 are established.

15. The method of claim 10, further comprising: Receive the IAB node's Data Network Access Identifier (DNAI) and the identification of the application associated with the IAB UPF from the IAB node; as well as The PCC rule is generated based on the DNAI and the identification of the application associated with the IAB UPF.

16. The method of claim 10, wherein the Network Storage Function (NRF) of the CN notifies the Session Management Function (SMF) of the CN of the NF profile for the IAB UPF.

17. The method of claim 10, wherein the UPF of the CN determines that the PCC rule applies to the traffic.

18. The method of claim 10, wherein the Session Management Function (SMF) of the CN determines that each of the NF profile of the IAB UPF and the user location information from the UE includes the identifier of the IAB node.

19. A method for operating an Integrated Access and Backhaul (IAB) provider using an IAB node configured to provide multi-access edge computing (MEC), comprising: The IAB User Plane Function (UPF) indicates that the Quality of Service (QoS) flow received from the core network (CN) will be routed to the IAB node; as well as Send a first instruction to the IAB node to instantiate the Remote Packet Data Convergence Protocol (PDCP) layer of the IAB provider, wherein the remote PDCP layer is configured to route the QoS flow to the IAB UPF.

20. The method of claim 19, further comprising: Send a second instruction to the IAB node to instantiate the Remote Service Data Adaptation Protocol (SDAP) layer of the IAB provider, wherein the remote SDAP layer is configured to route the QoS flow to the IAB UPF.

21. The method of claim 19, wherein the indication includes an identifier of the QoS flow and an identifier of the IAB node.

22. The method of claim 19, wherein the first instruction includes an identifier of the QoS flow.

23. A computer program product comprising instructions that, when executed by a processor, perform the steps of the method according to any one of claims 1 to 22.

24. An apparatus comprising means for carrying out the steps of the method according to any one of claims 1 to 22.

Images