Method, computer-readable storage device, and system for dynamic soft resource signaling

Abstract

The present invention discloses a method, system, device, and computer program for determining available soft resources of an integrated access and backhaul (IAB) node in a new radio (NR) integrated access and backhaul (IAB) system. In one aspect, a method includes determining, by a mobile terminal (MT) of an IAB node, a time-domain soft resource configuration of a distributed unit (DU) of the IAB node. The method further includes transmitting the time-domain soft resource configuration to the DU.

Description

[0001] Priority Claim

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 855,494, filed on May 31, 2019, entitled "DYNAMIC SOFT RESOURCE SIGNALING IN RELAY NETWORKS", the entire disclosure of which is incorporated herein by reference. BACKGROUND OF THE DISCLOSURE

[0003] A user equipment (UE) may wirelessly transmit data using a wireless communication network. To wirelessly transmit data, the UE connects to a node of a radio access network (RAN) and synchronizes with the network. SUMMARY OF THE DISCLOSURE

[0004] The present disclosure relates to a method, system, apparatus, computer program, or combination thereof for determining available soft resources of an integrated access and backhaul (IAB) node in a new radio (NR) IAB system.

[0005] According to one aspect of the present disclosure, a method includes determining, by a mobile terminal (MT) of an IAB node, a time-domain soft resource configuration of a distributed unit (DU) of the IAB node. The method further includes transmitting the time-domain soft resource configuration to the DU.

[0006] Other versions include corresponding systems, apparatuses, and computer programs for performing the actions of the methods defined by instructions encoded on a computer-readable storage device. These versions and other versions may optionally include one or more of the following features.

[0007] In some embodiments, the control channel (CCH) allocations of the MT and the DU are configured such that the DU CCH is allocated in a symbol after the resources allocated for the MT CCH.

[0008] In some embodiments, determining, by the MT of the IAB node, the soft resource configuration of the DU of the IAB node includes: determining that the resources allocated for the MT CCH do not include the MT CCH; in response to the determination, determining that the MT does not use the data resources corresponding to the resources allocated for the MT CCH; and generating a soft resource configuration to indicate the available soft resources available for the DU, where the available soft resources include the data resources not used by the MT.

[0009] In some embodiments, upon receiving the soft resource configuration, the DU is configured to initiate a sub-link using the DU CCH allocated in the DU CCH region indicated by the soft resource configuration.

[0010] In some specific embodiments, the gap time is scheduled between the end of the MT CCH and the start of the DU CCH, where the gap time is a time period for accommodating at least one of the MT CCH decoding delay or the DU data channel preparation time.

[0011] In some specific embodiments, determining the soft resource configuration of the DU of the IAB node by the MT of the IAB node includes: receiving a sleep (GTS) downlink control information (DCI); in response to receiving the GTS DCI, pausing the MT control channel (CCH) monitoring for a plurality of time slots indicated by the GTS DCI; and indicating to the DU the available soft resources for the MT GTS duration.

[0012] In some specific embodiments, the pausing includes not scheduling the time slots in the parent link corresponding to the plurality of time slots indicated by the GTS DCI.

[0013] In some specific embodiments, determining the configuration includes determining one or more rate matching (RM) modes, where the one or more RM modes include RM resource allocation for MT data transmission.

[0014] In some specific embodiments, the process further includes: the MT receiving downlink control information (DCI) scheduling the MT data transmission, where the DCI is used to dynamically select one of the one or more RM modes for rate matching for the data transmission.

[0015] In some specific embodiments, the process further includes, in response to receiving the DCI, determining the corresponding available soft resources for the DU, where the corresponding available soft resources are resources rate-matched according to the selected RM mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 Shows an example of IAB DU CCH allocation for soft resource scheduling according to some specific embodiments of the present disclosure.

[0017] Figure 2 Shows an example of MT sleep entry downlink control signaling assisted DU soft resource indication according to some specific embodiments of the present disclosure.

[0018] Figure 3 Shows an example of dynamic signaling of reserved resources for the MT parent link according to some specific embodiments of the present disclosure.

[0019] Figure 4 Shows a flowchart of an exemplary process according to some specific embodiments of the present disclosure.

[0020] Figure 5Shows an exemplary integrated access and backhaul (IAB) architecture according to some specific implementations of the present disclosure.

[0021] Figure 6 Shows an exemplary architecture of a system of a network according to some specific implementations of the present disclosure.

[0022] Figure 7 Shows an exemplary architecture of a system including a first CN according to some specific implementations of the present disclosure.

[0023] Figure 8 Shows the architecture of a system including a second CN according to some specific implementations of the present disclosure.

[0024] Figure 9 Shows an example of infrastructure equipment according to some specific implementations of the present disclosure.

[0025] Figure 10 Shows an example of a platform according to some specific implementations of the present disclosure.

[0026] Figure 11 Shows various protocol functions that can be implemented in a wireless communication device according to some specific implementations of the present disclosure.

[0027] Figure 12 Shows a block diagram of components capable of reading instructions from a machine-readable medium or a computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods described herein.

[0028] Like reference numerals and names in the various figures indicate like elements. Detailed Description

[0029] The present disclosure relates to an integrated access and backhaul (IAB) network, which implements multi-hop routing features in a cellular network (e.g., as described in 3GPP Release 16). Generally speaking, the IAB network includes an IAB donor (e.g., a base station), which serves multiple IAB nodes operating as repeaters. Additionally, the IAB network implements a central unit - distributed unit (CU - DU) split. In this architecture, the IAB nodes terminate the DU, and the IAB donor terminates the CU. Further, each IAB node may include a mobile terminal (MT) function. The IAB node can communicate with the parent IAB node and / or the IAB donor via the MT (e.g., using a parent link between the MT and the parent node / IAB donor). And the IAB node can communicate with the user equipment (UE) and / or the MT of the child IAB node via the DU (e.g., using a child link between the DU and the UE or the child IAB node). The signaling between the MT of the IAB node and the CU of the IAB donor can use the radio resource control (RRC) protocol. And the signaling between the DU of the IAB node and the CU of the IAB donor can use the F1 - AP protocol. Figure 3 The architecture of the IAB network is explained in more detail below (discussed below).

[0030] In the IAB network, the time - domain resource allocation has the following properties. Generally speaking, time - domain resources (e.g., symbols within a time slot) can be configured as downlink ("DL" or "D") resources, uplink ("UL" or "U") resources, or flexible (F) resources. For example, the time - domain resources can include the time - division duplex (TDD) structure of time slots or groups of time slots in a radio frame. The configuration of a specific time - domain resource can specify the potential transmission direction of the resource (e.g., DL, UL, or F). From the perspective of the MT, the parent link can use D / U / F time - domain resources, and from the perspective of the DU, the child link can use D / U / F time - domain resources. Additionally, the D / U / F time - domain resources of the DU (e.g., for the child link) can be configured as hard (H), soft (S), or unavailable (NA). These configurations indicate the resource availability of the configured D / U / F resources as unconditionally available (H), conditionally available (S), or unavailable (NA).

[0031] In addition, according to 3GPP, a parent IAB node has the ability to know the semi-static DU resource configuration of its child IAB nodes. If the complete DU resource configuration information of the child nodes is not required, only the necessary configuration information is signaled to the parent IAB node. Thus, an IAB CU (e.g., of an IAB donor) can configure the semi-static resource configuration of the parent IAB DU in a centralized manner. Specifically, the resource configuration may include DU D / U / F configuration and DU H / S / NA configuration. In some examples, soft resources may be used by the parent IAB node to make resources available to the child nodes, regardless of any implicitly determined result of the availability at the child nodes. Thus, the parent IAB node does not need to know the implicitly determined result of the availability of the DU soft resources at the child nodes.

[0032] In some examples, the DU H / S / NA configuration (also referred to as "resource availability") is explicitly indicated according to the resource type (D / U / F) in each time slot of the time domain resources. However, in such examples, a misalignment of the times of the DU resources and the MT resources may occur. To avoid such potential misalignment (e.g., when determining the validity of H / S / NA at the DU), three methods are considered. In the first method, H / S / NA is applied with respect to the DU resource configuration time slot timing, regardless of the MT resource configuration or timing. In the second method, H / S / NA is applied with respect to the MT resource configuration time slot timing. In the third method, H is applied with respect to the DU resource configuration time slot timing, and S is implicitly determined by the DU based on whether the corresponding MT configuration indicates that the MT resource is F (DU-S), and the remaining resources at the child DU are assumed to be NA.

[0033] The present disclosure describes methods and systems for applying H / S / NA with respect to the MT resource configuration time slot timing (i.e., the second method). The methods and systems enable the CU to obtain information on the required guard symbols for a given DU configuration (if needed). Additionally, the disclosed methods and systems effectively and dynamically signal the available soft resources to the DU such that the DU can correctly determine the available soft resources for data transmission in a sub-link (e.g., an access link). Signaling the available soft resources to the DU dynamically allows for the efficient sharing of radio resources by the backhaul link and the access link. Thus, according to the corresponding instantaneous traffic needs, the radio resources can be optimally shared by the backhaul link and the access link, which is an improvement over existing and conventional solutions.

[0034] In a first embodiment, complementary resource availability is signaled between the MT and the DU. In this embodiment, the H / S / NA resources in the MT respectively correspond to the NA / S / H resources of the DU. Thus, when the MT does not use soft MT resources (e.g., D / U / F symbols), they can be conditionally used for the DU. In a first implementation of the first embodiment, a time-shifted allocation of the MT control channel resources and the DU control channel resources is signaled. In this implementation, in order to determine whether the soft resources are available for the DU (e.g., to schedule sub-link transmissions), after the resources allocated for the MT CCH, one or more symbols are allocated for the control channel (CCH) allocation of the DU. Thus, the detection result of the MT CCH can be used to signal the availability of the corresponding soft resources to the DU.

[0035] In a second implementation, downlink control information (DCI) signals entry into a sleep (GTS) to pause MT CCH monitoring for multiple time slots. Once the MT receives the GTS DCI, the MT stops CCH monitoring in the parent link and indicates to the DU the corresponding available soft resources for the MT GTS duration. A third implementation relates to the dynamic signaling of reserved resources in the MT parent link. In this implementation, one or more sets of rate matching (RM) mode groups including specific RM resource allocations are configured for MT downlink and / or uplink data transmission. The DCI scheduling DL / UL data transmission can dynamically select one or more of the configured RM modes to perform rate matching for the scheduled data transmission in the parent link. The resources for rate matching can be indicated as available DU soft resources.

[0036] In a second embodiment, the DU soft resource determination is made in an implicit manner. In this embodiment, only hard resources and unavailable resources are configured to the MT. The unavailable MT resources are configured as hard resources of the DU. Among the MT hard resources, some of these always-on MT resources in the parent link that require the MT to continuously (or periodically at a rate greater than a threshold) receive or transmit can be set as unavailable DU resources. The remaining other hard resources can be configured as DU soft resources.

[0037] In the following discussion, based on the transmission direction (e.g., D / U / F) relative to the MT time slot timing in each time slot, the resource availability (e.g., H / S / NA) is explicitly configured according to the resource type. Thus, if multiple resource types are configured within a time slot, the granularity of the resource availability configuration is at the level of the resource type or at the time slot level. The following embodiments can be used to determine the IAB-DU resource availability (e.g., H / S / NA).

[0038] Complementary Resource Availability between DU and MT

[0039] In this embodiment, the hard resources, soft resources, and unavailable resources in the MT respectively correspond to the unavailable resources, soft resources, and hard resources of the DU. Therefore, when the MT does not use soft MT resources that can only be DL symbols, UL symbols, or flexible symbols, they can be conditionally used by the DU. In the example, the following dynamic signaling embodiments can be used to signal available soft resources to the DU of the IAB node. In the following embodiments, it is assumed that the IAB node has established a sub-link via the DU and a parent link via the MT.

[0040] Specific Implementation 1.1: Time Shift Allocation of MT Control Channel and DU Control Channel

[0041] In a first embodiment, to determine whether soft resources are available for the DU (e.g., to schedule sub-link transmissions), the control channel (CCH) allocations for the MT and the DU can be configured such that one or more symbols are allocated for the DU CCH after one or more resources allocated for the MT CCH.

[0042] Figure 1 Example 100 of IAB DU CCH allocation for soft resource scheduling according to some embodiments is shown. As Figure 1 shown, the IAB-MT monitors MT CCH transmissions according to the MT soft resource time slot scheduling timing 102. If the MT determines that there is no MT CCH transmission in the current time slot (e.g., unused MT soft CCH 106a or unused MT soft CCH 106b), the parent link (e.g., the backhaul link) does not use the corresponding data resources. In this case, the MT indicates the available soft time slots to the DU, where the available soft resources include the data resources not used by the MT.

[0043] After being notified of the available soft resources, the DU can schedule sub-link (e.g., access link) traffic by allocating the DU CCH in the "DU CCH" area. For example, as shown by the DU soft resource time slot scheduling timing 104, the DU can schedule traffic in the available DU soft CCH 108a and / or the available DU soft CCH 108b. Then the sub-link traffic can be carried via the scheduled resources (e.g., resources 110a, 110b). As Figure 1 shown, a gap time 114 is reserved between the end of the MT CCH and the start of the DU CCH (e.g., between the unused MT soft CCH 106a and the available DU soft CCH 108a). This gap time accommodates the MT control channel decoding delay and / or the potential DU data channel preparation time. Also as Figure 1 shown, due to the MT CCH monitoring and the gap time, the DU schedules shorter time slot transmissions for the access link (e.g., compared to the length of the MT data resources such as resource 116).

[0044] Specific Implementation 1.2: DU Soft Resource Indication Assisted by MT Entering Sleep Downlink Control Signaling

[0045] In a second specific implementation, downlink control information (DCI) notifies, via a signaling message, that entering sleep (GTS) can be used to pause MT CCH monitoring for a specified number of time slots. Once the MT receives the GTS DCI, the MT stops CCH monitoring in the parent link. Then, the MT indicates to the DU the soft resources corresponding to the unmonitored parent link resources as available soft resources. In this case, the DU can schedule the entire soft time slot for data transmission (different from specific implementation 1.1 that schedules shortened time slots).

[0046] Figure 2 Example 200 of MT entering sleep downlink control signaling-assisted DU soft resource indication according to some specific implementations is shown. In Figure 2 , the MT can receive DCI GTS indicating pausing MT CCH monitoring for four time slots. Therefore, the MT does not schedule data transmission in the next four time slots. For example, in Figure 2 , the MT may not monitor MT CCH 204a, MT CCH 204b, MT CCH 204c, and MT CCH 204d. Therefore, these time slots can be used for DU sub-link transmission (e.g., access link transmission). When receiving the GTS DCI, the MT notifies the DU of the resulting soft resource availability. At this time, the DU can schedule sub-link traffic with these available soft resources. For example, in Figure 2 , the DU can schedule access link traffic in the available DU soft CCHs 206a, 206b, 206c, and / or 206d. In addition, compared with the first specific implementation where the DU uses shortened time slots, since the MT can skip control channel monitoring during the sleep period, the full soft time slot duration can be used by the DU.

[0047] Specific Implementation 1.3: Dynamic Signaling of Reserved Resources on MT Parent Link

[0048] In a third specific implementation, one or more rate matching (RM) modes can be configured for parent link data transmission, and each RM mode includes a corresponding RM resource allocation. The DCI for scheduling data transmission can dynamically select one or more RM modes to perform rate matching for data transmission. The resources for rate matching can be used as available DU soft resources.

[0049] Figure 3 Example 300 of dynamic signaling of reserved resources for the MT parent link according to some specific implementations is shown. As Figure 3As shown, the MT DCI can signal the RM mode for the scheduled parent link data transmission in the CCH channel. For example, the MT DCI can schedule the RM mode for the parent link data transmission in the MT CCH 302a. The resource mode may include the RM resource allocation 304a configured for the parent link data transmission. Additionally, the RM mode may include the resources 306a (or "RM1") for rate matching that can be used as available DU soft resources. Thus, when the MT receives the DCI signaling the RM mode, the MT indicates to the DU that the corresponding available soft resources are the rate-matching resources 306a (which are the resources 308a). In this way, the DU can use the resources 308a for sub-link data transmission by scheduling a transmission in the corresponding DU CCH 310a. Similarly, the MT can receive the respective DCIs indicating the respective RM modes in one or more of the MT CCHs 302b, 302c, 302d, and the respective RM modes respectively include the resource allocations 304b, 304c, 304d and the rate-matching resources 306b, 306c, 306d. The DU can use the resources 308b, 308c, 308d corresponding to the rate-matching resources 306b, 306c, 306d respectively. The DU CCHs 310b, 310c, 310d can schedule the transmissions in the resources 308b, 308c, 308d respectively.

[0050] Similarly as Figure 3 shown, different RM resource modes can be signaled in different time slots of the parent link. For example, the first RM mode is scheduled in time slots 312 and 314, the second RM mode is scheduled in time slot 316, and the third RM mode is scheduled in time slot 318. As Figure 3 shown, each RM mode may have a different length. Thus, different amounts of soft resources can be used for the DU access link in different time slots. To utilize the various available amounts of soft resources, different control channel resource allocations can be configured for the DU according to different RM resource modes. When the MT receives the DCI signaling the RM mode, it indicates the corresponding available soft resources to the DU. Then, the DU can use the associated CCH to schedule the access link data transmission.

[0051] Implicit DU Soft Resource Determination

[0052] In one embodiment, DU soft resources are determined implicitly. In this embodiment, only hard resources and unavailable resources are configured to the MT, and the unavailable MT resources can be configured as hard resources for the DU. Among the MT hard resources, some MT resources (e.g., Synchronization Signal Block (SSB) resources, Channel State Information Reference Signal (CSI-RS), or Sounding Reference Signal (SRS)) in the always-on MT resources in the parent link that require the MT to continuously receive / transmit and / or control channel resources can be set as unavailable DU resources. The remaining hard resources can be configured as DU soft resources.

[0053] To determine whether the soft DU resources are available for DU sub-link transmission or reception, the specific implementations 1.1, 1.2, and 1.3 discussed above can be used to identify the availability of the soft resources.

[0054] Figure 4 A flowchart of an exemplary process 400 according to some specific implementations is shown. For clarity of presentation, the following description generally describes the process in the context of other figures in this specification. For example, the process can be performed by an IAB node or its entity (e.g., as Figure 5 shown). However, it should be understood that these processes can be performed, for example, by any suitable system, environment, software, and hardware or a combination of system, environment, software, and hardware, as the case may be. In some specific implementations, the various steps of the process can be run in parallel, combined, looped, or run in any order.

[0055] Figure 4 is a flowchart of an exemplary process 400 for determining the available soft resources of an IAB node in an IAB system. At step 402, the process involves determining the time-domain soft resource configuration of the distributed unit (DU) of the IAB node by the mobile terminal (MT) of the IAB node. At step 404, the process involves transmitting the time-domain soft resource configuration to the DU.

[0056] In some specific implementations, the control channel (CCH) allocation of the MT and the DU is configured such that the DU CCH is allocated in the symbols after the resources allocated for the MT CCH.

[0057] In some specific implementations, determining the soft resource configuration of the DU of the IAB node by the MT of the IAB node includes: determining that the resources allocated for the MT CCH do not include the MT CCH; in response to this determination, determining that the MT does not use the data resources corresponding to the resources allocated for the MT CCH; and generating a soft resource configuration to indicate the available soft resources available for the DU, where the available soft resources include the data resources not used by the MT.

[0058] In some specific implementations, upon receiving the soft resource configuration, the DU is configured to initiate a sub-link using the DU CCH, which is allocated in the DU CCH region indicated by the soft resource configuration.

[0059] In some specific implementations, the gap time is scheduled between the end of the MT CCH and the start of the DU CCH, where the gap time is a time period for accommodating at least one of the MT CCH decoding delay or the DU data channel preparation time.

[0060] In some specific implementations, determining the soft resource configuration of the DU of the IAB node by the MT includes: receiving the incoming sleep (GTS) downlink control information (DCI); in response to receiving the GTS DCI, pausing the MT control channel (CCH) monitoring for a plurality of time slots indicated by the GTS DCI; and indicating to the DU the available soft resources for the MT GTS duration.

[0061] In some specific implementations, the pausing includes not scheduling the time slots in the parent link corresponding to the plurality of time slots indicated by the GTS DCI.

[0062] In some specific implementations, determining the configuration includes determining one or more rate matching (RM) modes, where the one or more RM modes include RM resource allocation for MT data transmission.

[0063] In some specific implementations, the process further includes: the MT receiving the downlink control information (DCI) scheduling the MT data transmission, where the DCI is used to dynamically select one of the one or more RM modes for rate matching for the data transmission.

[0064] In some specific implementations, the process further includes, in response to receiving the DCI, determining the corresponding available soft resources for the DU, where the corresponding available soft resources are the resources rate-matched according to the selected RM mode.

[0065] Figure 4 The exemplary process shown can be modified or reconfigured to include additional, fewer, or different steps ( Figure 4 not shown), and these steps can be executed in the order shown or in a different order.

[0066] Figure 5 An exemplary integrated access and backhaul (IAB) architecture according to various embodiments is shown. Specifically, Figure 5 the IAB architecture in the stand-alone (SA) mode is shown. Figure 5 The IAB architecture of Figure 5FIG. 0 shows a reference diagram of IAB in stand-alone mode, which includes an IAB donor 504 (also referred to as an "anchoring node", etc.) and a plurality of IAB nodes such as IAB nodes 506a, 506b (also referred to as IAB relay nodes (RNs), relay transmission / reception points (rTRPs), etc.). The IAB donor 504 is regarded as a single logical node including a set of functions such as gNB-DU 508a, gNB-CU-CP 508b, gNB-CU-UP 508c, and possibly other functions. In some specific implementations, the IAB donor 504 can be split according to the foregoing functions, and these functions can be arranged all collocated or non-collocated as allowed by the 3GPP NG-RAN architecture. Some functions currently associated with the IAB donor 504 can be moved outside the IAB donor.

[0067] In Figure 5 , various UEs (e.g., UEs 510, 601, 701, and 801 in Figure 6 , Figure 7 and Figure 8 discussed below) access the IAB nodes. An IAB node is a network node in an IAB deployment that has the functions of a UE and at least part of a gNB. As Figure 5 shown, some IAB nodes access other IAB nodes, and some IAB nodes access the IAB donor. An IAB donor is a network node that terminates the NG interface via a wired connection in an IAB deployment. An IAB donor is a RAN node that provides an interface for UEs to the core network 502 (e.g., 5GC in Figure 5 discussed below and Figure 8 CN 820 in

[0068] IAB endeavors to reuse existing functions and interfaces defined for access. Specifically, the mobile terminal (MT), gNB-DU, gNB-CU, UPF, AMF, and SMF, and the corresponding interfaces NR Uu (between the MT and the gNB), F1, NG, X2, and N4 are used as the baseline of the IAB architecture. Modifications or enhancements to these functions and interfaces to support IAB will be explained in the context of the architecture discussion. The mobile terminal (MT) function (such as 520) has been defined as part of the mobile equipment. In the context of IAB, the MT is referred to as a function residing on an IAB node that terminates the radio interface layer of the backhaul Uu interface to the IAB donor or other IAB nodes. Additional functions such as multi-hop forwarding are included in the architecture.

[0069] The IAB node can operate in SA or NSA mode. When operating in NSA, the IAB node only uses the NR link for backhaul. The UE connected to the IAB node (e.g., Figure 6 UE 601) can select an operation mode different from that of the IAB node. The UE can also be connected to a core network of a different type from the IAB node to which it is connected. In this case, adornment or slicing can be used for CN selection. The IAB node operating in NSA mode can be connected to the same or different eNBs. The UEs also operating in NSA mode can be connected to the same or different RAN nodes (e.g., Figure 6 RAN node 611) as the IAB nodes to which they are connected.

[0070] Examples of operations in SA and NSA modes include: (1) the UE and the IAB node operate in SA for the NGC; (2) the UE operates in NSA with the EPC, while the IAB node operates in SA with the NGC; and (3) the UE and the IAB node operate in NSA with the EPC (or for NR implementations, the 5GC). For the third example, the UE and the IAB node operate in NSA with the EPC (or for NR implementations, the 5GC), and the IAB node can use the LTE branch (or for NR implementations, the NR branch) for IAB node initial access and configuration, topology management, routing, and resource partitioning.

[0071] In an implementation supporting multi-hop and topology adaptation, the IAB node includes a topology management mechanism and a routing and optimization (RSO) mechanism. The topology management mechanism includes a protocol stack, an interface between rTRPs or IAB nodes, controls and user plane programs for identifying one or more hops in the IAB network, forwarding traffic via one or more wireless backhaul links (e.g., wireless backhaul 512) in the IAB network, handling of QoS, etc. The RSO mechanism includes a mechanism for discovering and managing the backhaul link of the TRP with integrated backhaul and access functions; a RAN-based mechanism for supporting dynamic routing (possibly without core network participation) to adapt to short-term blockages and transmissions of delay-sensitive traffic across the entire backhaul link; and a mechanism for evaluating different resource allocations / routings across multiple nodes for end-to-end RSO.

[0072] Operations on different links can be performed at the same frequency (“in-band”) or different frequencies (“out-of-band”). In-band backhaul includes scenarios where the access link and the backhaul link at least partially overlap in frequency, resulting in a half-duplex or interference constraint, which may mean that the IAB node may not transmit and receive simultaneously on both links. In contrast, out-of-band scenarios may not have such constraints. In an implementation, one or more of the IAB nodes include a mechanism for dynamically allocating resources between the backhaul link and the access link, the mechanism including a mechanism for efficiently multiplexing the access link and the backhaul link (for both the DL direction and the UL direction) in time, frequency, or space under per-link half-duplex constraints on one or more backhaul link jumps for both TDD and FDD operations; and cross-link interference (CLI) measurement, coordination, and suppression between the rTRP and the UE.

[0073] Architecture Groups and Types

[0074] There are five different types of IAB architectures, which are divided into two architecture groups. Architecture group 1 includes architectures 1a and 1b, which include a CU / DU split architecture. Architecture 1a includes the use of an adaptive layer or GTP-U combined with an adaptive layer for the backhaul of F1-U, and hop-by-hop forwarding across intermediate nodes using an adaptive layer to operate with the NGC or using PDN connection layer routing to operate with the EPC. Architecture 1b includes the use of GTP-U / UDP / IP for the backhaul of F1-U on the access node, and hop-by-hop forwarding across intermediate nodes using an adaptive layer.

[0075] Architecture group 2 includes architectures 2a, 2b, and 2c. Architecture 2a includes the use of GTP-U / UDP / IP for the backhaul of F1-U or NG-U on the access node, and hop-by-hop forwarding across intermediate nodes using PDU session layer routing. Architecture 2b includes the use of GTP-U / UDP / IP for the backhaul of F1-U or NG-U on the access node, and hop-by-hop forwarding across intermediate nodes using GTP-U / UDP / IP nested tunnels. Architecture 2c includes the use of GTP-U / UDP / IP for the backhaul of F1-U or NG-U on the access node, and hop-by-hop forwarding across intermediate nodes using GTP-U / UDP / IP / PDCP nested tunnels.

[0076] Architecture Group 1

[0077] Architecture 1a utilizes a CU / DU split architecture. In this architecture, each IAB node maintains a DU (e.g., DU 522) and an MT (e.g., MT 520). Via the MT, the IAB node is connected to an upstream IAB node or an IAB donor. Via the DU, the IAB node establishes an RLC channel to the UE and to the MT of a downstream IAB node. For the MT, this RLC channel may refer to a modified RLC*. The IAB node can be connected to more than one upstream IAB node or IAB donor DU. The IAB node may contain multiple DUs, but each DU part of the IAB node has an F1-C connection only to one IAB donor CU-CP.

[0078] The donor also maintains a DU to support the MTs of the UE and downstream IAB nodes. The IAB donor maintains a CU for all the DUs of the IAB nodes and its own DU. This is used to further study whether different CUs can serve the DUs of the IAB nodes. Each DU on the IAB node is connected to the CU in the IAB donor using a modified form of F1 called F1*. F1*-U operates on the RLC channel over the wireless backhaul between the MT on the serving IAB node and the DU on the donor. The F1*-U transmissions between the MT and DU on the serving IAB node and between the DU and CU on the donor are to be further studied. An adaptive layer is added, which holds routing information to enable hop-by-hop forwarding. This adaptive layer replaces the IP function of the standard F1 stack. F1*-U may carry a GTP-U header for end-to-end association between the CU and DU. In a further enhancement, the information carried within the GTP-U header can be included in the adaptation layer. Additionally, optimization of the RLC can be considered, such as applying ARQ only to the end-to-end connection as opposed to hop-by-hop. The F1*-U protocol stack of this architecture includes an enhancement of the RLC (referred to as RLC*). The MT of each IAB node further maintains an NAS connection to the NGC (e.g., for authentication of the IAB node and, via the NGC, maintains a PDU session (e.g., to provide a connection to the OAM to the IAB node.

[0079] For NSA operation using the EPC, the MT uses EN-DC to dual connect to the network. The MT of the IAB node maintains a PDN connection to the EPC (e.g., to provide a connection to the OAM to the IAB node.

[0080] Architecture 1b also utilizes a CU / DU split architecture. In this architecture, the IAB donor only maintains one logical CU. The IAB node can be connected to more than one upstream IAB node or IAB donor DU. The IAB node may contain multiple DUs, but each DU part of the IAB node has an F1-C connection only to one IAB donor CU-CP.

[0081] In this architecture, each IAB node and IAB donor maintain the same functions as in Architecture 1a. Additionally, as in Architecture 1a, each backhaul link establishes an RLC channel and inserts an adaptation layer to achieve hop-by-hop forwarding of F1*.

[0082] Contrary to Architecture 1a, the MT on each IAB node establishes a PDU session with the UPF residing on the donor. The PDU session of the MT carries the co-located DU's F1*. In this way, the PDU session provides a point-to-point link between the CU and the DU. On intermediate hops, the PDCP-PDUs of F1* are forwarded via the adaptation layer in the same way as described for Architecture 1a.

[0083] For NSA operation using EPC, the MT of the IAB node uses EN-DC to dual connect to the network. In this case, the MT of the IAB node maintains a PDN connection with the L-GW residing on the donor.

[0084] Adaptation layer: As described above, an adaptation layer is inserted to enable hop-by-hop forwarding of F1*. In these embodiments, the UE establishes RLC channels to the DU on the access IAB node of the UE in accordance with 3GPP TS 38.300. Each of these RLC channels extends between the access DU of the UE and the IAB donor via a potentially modified form of F1-U called F1*-U. The information embedded in F1*-U is carried across the backhaul link via the RLC channel. Transmission of F1*-U over the wireless backhaul is enabled by the adaptation layer integrated with the RLC channel. Inside the IAB donor (referred to as fronthaul), the baseline will use the native F1-U stack (see section 9 of 3GPP TR 38.874). The IAB donor DU relays between F1-U on the fronthaul and F1*-U on the wireless backhaul.

[0085] In Architecture 1a, the information carried on the adaptation layer supports the following functions: identification of UE bearers for PDUs; routing across the wireless backhaul topology; QoS enforcement of schedulers on the DL and UL of the wireless backhaul link; mapping of UE user plane PDUs to the backhaul RLC channel; and other suitable functions.

[0086] In Architecture 1b, the information carried on the adaptation layer supports the following functions: routing across the wireless backhaul topology; QoS enforcement of schedulers on the DL and UL of the wireless backhaul link; mapping of UE user plane PDUs to the backhaul RLC channel; and other suitable functions.

[0087] In the case where the IAB node is connected via multiple paths, different identifiers in the adaptive layer (e.g., UE bearer-specific Id; UE-specific Id; routing Id, IAB node, or IAB donor address; QoS information, etc.) will be associated with different paths, enabling adaptive layer routing on different paths. Different paths can be associated with different backhaul RLC channels.

[0088] The content carried in the adaptive layer header can include, for example, UE bearer-specific Id; UE-specific Id; routing Id, IAB node, or IAB donor address; QoS information; and / or other similar information. The IAB node uses the identifier carried via Adapt to ensure the required QoS handling and to determine which hop the packet should be sent to. The UE bearer-specific Id can be used by the IAB node and the IAB donor to identify the UE bearer of the PDU. Then, the access IAB node of the UE will map the Adapt information (e.g., UE-specific ID, UE bearer-specific ID) to the corresponding C-RNTI and LCID. The IAB donor DU may also need to map the Adapt information to the F1-U GTP-U TEID used between the donor DU and the donor CU. The UE bearer-specific Id, UE-specific Id, routing Id, or IAB node / IAB donor address can be (combined or individually) used to route the PDU across the radio backhaul topology. The UE bearer-specific Id, UE-specific Id, the access node IAB ID of the UE, or QoS information can be (combined or individually) used at each hop to identify the QoS handling of the PDU. The QoS handling of the PDU can also be based on the LCID.

[0089] In some embodiments, the adaptive layer can include one or more sub-layers, and thus, the adaptive header can have different structures in different embodiments. For example, the GTP-U header can become part of the adaptive layer. It is also possible that the GTP-U header is carried on top of the adaptive layer to carry the end-to-end association between the IAB node DU and the CU. Alternatively, the IP header can be part of the adaptive layer or carried on top of the adaptive layer. In one example, the IAB donor DU maintains the IP routing function to extend the fronthaul IP routing plane to the IP layer carried via adapt over the radio backhaul. This allows the native F1-U to be established e2e (e.g., between the IAB node DU and the IAB donor CU-UP). This scenario means that each IAB node maintains an IP address that can be routed from the fronthaul via the IAB donor DU. The IP address of the IAB node can also be used for routing over the radio backhaul. Note that the IP layer on top of Adapt does not represent a PDU session. Therefore, the first-hop router of the MT on this IP layer does not have to maintain a UPF.

[0090] Architecture Group 2

[0091] In architecture 2a, the UE and the IAB node use the SA mode for the NGC. In this architecture, the IAB node keeps the MT to establish an NR Uu link with the gNB on the parent IAB node or the IAB donor. Via this NR-Uu link, the MT maintains a PDU session with the UPF collocated with the gNB. In this way, an independent PDU session is created on each backhaul link. Each IAB node also supports a routing function to forward data between the PDU sessions of adjacent links. This creates a forwarding plane across the wireless backhaul. Based on the PDU session type, this forwarding plane supports IP or Ethernet. In the case where the PDU session type is Ethernet, an IP layer can be established on top. In this way, each IAB node obtains an IP connection to the wired backhaul network. The IAB node can be connected to more than one upstream IAB node or IAB donor.

[0092] All IP-based interfaces such as NG, Xn, F1, N4, etc. are carried on this forwarding plane. In terms of F1, in addition to the UPF of the gNB and the backhaul link, the UE serving IAB node will also include the DU for the access link. The CU for the access link will reside in the IAB donor or beyond the IAB donor. The NG-U protocol stack for IP-based and Ethernet-based PDU session types can be used for this architecture.

[0093] In the case where the IAB node keeps the DU for UE access, since the end-user data will have been protected using the end-to-end PDCP between the UE and the CU, it may not be necessary to support PDCP-based protection at each hop. Details are to be further studied.

[0094] For NSA operation using the EPC, the MT uses EN-DC to dual connect with the network. In this case, the MT of the IAB node maintains a PDN connection with the L-GW residing on the parent IAB node or the IAB donor. All IP-based interfaces such as S1, S5, X2, etc. are carried on this forwarding plane.

[0095] In architecture 2b, the IAB node keeps the MT to establish an NR Uu link with the gNB on the parent IAB node or the IAB donor. Via this NR-Uu link, the MT maintains a PDU session with the UPF. Contrary to architecture 2a, this UPF is located at the IAB donor. Additionally, forwarding of PDUs across upstream IAB nodes is achieved via tunnels. Therefore, the forwarding across multiple hops creates a stack of nested tunnels. As in architecture 2a, each IAB node obtains an IP connection to the wired backhaul network. All IP-based interfaces such as NG, Xn, F1, N4, etc. are carried on this forwarding IP plane. The IAB node can be connected to more than one upstream IAB node or IAB donor.

[0096] For NSA operation using EPC, the MT uses EN-DC for dual connectivity with the network. In this case, the MT of the IAB node maintains a PDN connection with the L-GW residing on the IAB donor.

[0097] Architecture 2c utilizes DU-CU split. The IAB node hosts the MT, which maintains an RLC channel with the DU on the parent IAB node or IAB donor. The IAB donor maintains the CU and UPF for the DU of each IAB node. The MT on each IAB node maintains an NR-Uu link with the CU and a PDU session with the UPF on the donor. Forwarding on the intermediate nodes is achieved via tunnels. Forwarding across multiple hops creates a stack of nested tunnels. As in architectures 2a and 2b, each IAB node obtains an IP connection to the wired backhaul network. However, contrary to architecture 2b, each tunnel includes the SDAP / PDCP layer. All IP-based interfaces such as NG, Xn, F1, N4, etc. are carried on this forwarding plane. The IAB node can be connected to more than one upstream IAB node or IAB donor.

[0098] For NSA operation using EPC, the MT uses EN-DC for dual connectivity with the network. In this case, the MT of the IAB node maintains a PDN connection with the L-GW residing on the IAB donor.

[0099] Multi-hop Backhaul

[0100] In an embodiment, the IAB system architecture supports multi-hop backhaul. The IAB multi-hop backhaul provides a greater range of expansion than a single-hop system. The multi-hop backhaul also enables backhaul around obstacles (e.g., buildings deployed haphazardly in an urban environment). The maximum number of hops in a deployment can depend on many factors such as frequency, cell density, propagation environment, traffic load, various KPIs, and / or other similar factors. Additionally, the weight assigned to each of these factors can change dynamically over time. As the number of hops increases, scalability issues may arise and limit performance or increase the signal load to an unacceptable level; thus, the scalability of the hop count can be considered an important KPI for planning and deployment (e.g., SON) purposes. In some specific implementations, there may be no limit on the number of backhaul hops.

[0101] Topology Adaptation

[0102] The IAB system architecture also supports topology adaptation. Topology adaptation refers to the process of autonomously reconfiguring the backhaul network in situations such as blockage or local congestion without interrupting the service to the UE and / or mitigating the service interruption to the UE. For example, due to mobile objects such as vehicles, weather-related events (e.g., seasonal changes (leaves), infrastructure changes (e.g., new buildings), etc.), wireless backhaul links may be vulnerable to blockage. These vulnerabilities can apply to physically stationary IAB nodes and / or mobile IAB nodes. Additionally, traffic variations can create uneven load distributions on wireless backhaul links, leading to local link or node congestion. In various specific implementations, topology adaptation for physically fixed IAB nodes is supported to achieve robust operation to mitigate blockage and load variations on the backhaul link.

[0103] Physical Layer Enhancement of IAB

[0104] The IAB system architecture can also support the following physical layer features: mechanisms for the discovery of IAB nodes and the management of backhaul links in both SA and NSA deployments, taking into account the half-duplex constraints at IAB nodes and multi-hop topologies, including: solutions for reusing the same set of SSBs for accessing UEs and solutions for using SSBs orthogonal (TDM and / or FDM) to the SSBs used for accessing UEs, CSI-RS-based IAB node discovery in synchronous deployments, SSB- and CSI-RS-based backhaul link RSRP / RSRQ RRM measurements; and the configuration of backhaul RACH resources to support additional preamble formats with different timings, longer RACH periodicities, and allowing longer RTTs compared to access RACH resources without affecting the enhancements for Rel-15 UEs; enhancements to the beam failure recovery and radio link failure processes, including solutions to avoid RLF at sub-IAB nodes due to parent backhaul link failures; mechanisms for supporting both in-band and out-of-band relaying by multiplexing access links and backhaul links in time (TDM), frequency (FDM), or space (SDM) under per-link half-duplex constraints at IAB nodes and across multiple backhaul hops, including: semi-static configuration of IAB node DU resources, dynamic indication to IAB nodes of the availability of soft resources of IAB node DUs, and power control / coordination of FDM / SDM of access links and backhaul links; OTA timing alignment across multiple backhaul hops, including: mechanisms for DL timing alignment across IAB nodes, alignment of UL transmission timing and DL transmission timing of IAB nodes, and alignment of UL reception timing and DL reception timing of IAB nodes; inter-IAB node cross-link interference (CLI) measurements and measurement coordination / configuration; and support for up to 1024QAM for backhaul links.

[0105] IAB Node RACH: The ability of IAB to support network flexibility to configure backhaul RACH resources with different timing, longer RACH periodicity, and additional preamble formats allowing longer RTT compared to access RACH resources, without affecting the enhancements for Rel-15 UEs. Based on the Rel-15 PRACH configuration, the network is allowed to configure an offset for the PRACH timing of the MT of the IAB node to perform TDM on the backhaul RACH resources across adjacent hops.

[0106] Backhaul Link Management: The IAB node supports mechanisms for detecting backhaul link failures / recovering from backhaul link failures based on Rel-15 mechanisms. Enhancements to the beam failure recovery and radio link failure procedures may also include enhancements to support the interaction between the beam failure recovery success indication and RLF; and for IAB nodes, enhancements to the existing beam management procedures for faster beam switching / coordination / recovery to avoid backhaul link interruptions should be considered. It may include an additional backhaul link condition notification mechanism from the parent IAB node DU to the child IAB node (e.g., if the backhaul link of the parent IAB node fails), and the corresponding IAB node behavior.

[0107] Figure 6 An exemplary architecture of a network system 600 according to various embodiments is shown. The following description is provided for an example system 600 operating in conjunction with the LTE system standard and the 5G or NR system standard provided in the 3GPP technical specifications. However, the exemplary embodiments are not limited in this regard, and the embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.).

[0108] As Figure 6As shown, system 600 includes UE 601a and UE 601b (collectively referred to as "UE 601"). In this example, UE 601 is shown as a smart phone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronic devices, mobile phones, smart phones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument clusters (IC), head-up display (HUD) devices, on-board diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDT), electronic engine management systems (EEMS), electronic / engine electronic control units (ECU), electronic / engine electronic control modules (ECM), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or "smart" home appliances, MTC devices, M2M, IoT devices, etc.

[0109] In some embodiments, any of the UEs 601 can be an IoT UE, which can include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE can utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a PLMN, ProSe, or D2D communication, a sensor network, or an IoT network. The M2M or MTC data exchange can be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which can include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE can execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connection to the IoT network.

[0110] UE 601 can be configured to connect to RAN 610, e.g., communicatively coupled. In an embodiment, RAN 610 can be an NG RAN or 5G RAN, E-UTRAN, or a legacy RAN, such as UTRAN or GERAN. As used herein, the term "NG RAN", etc., can refer to RAN 610 operating in an NR or 5G system 600, while the term "E-UTRAN", etc., can refer to RAN 610 operating in an LTE or 4G system 600. UE 601 utilizes connections (or channels) 603 and 604, respectively, each connection including a physical communication interface or layer (discussed further below in detail).

[0111] In this example, the connections 603 and 604 are shown as air interfaces to achieve communication coupling and may be consistent with cellular communication protocols such as GSM protocol, CDMA network protocol, PTT protocol, POC protocol, UMTS protocol, 3GPP LTE protocol, 5G protocol, NR protocol, and / or any other communication protocol discussed herein. In an embodiment, the UE 601 may directly exchange communication data via the ProSe interface 605. The ProSe interface 605 may alternatively be referred to as the SL interface 605 and may include one or more logical channels including, but not limited to, PSCCH, PSSCH, PSDCH, and PSBCH.

[0112] UE 601b is shown as being configured to access an AP 606 (also referred to as a "WLAN node 606", "WLAN 606", "WLAN terminal 606", "WT 606", etc.) via a connection 607. The connection 607 may include a local wireless connection such as a connection consistent with any IEEE802.11 protocol, where the AP 606 will include a wireless fidelity router. In this example, the AP 606 is shown connected to the Internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, the UE 601b, RAN 610, and AP 606 may be configured to utilize LWA operations and / or LWIP operations. LWA operations may involve the RAN nodes 611a-b configuring the UE 601b in the RRC_CONNECTED state to utilize the radio resources of LTE and WLAN. LWIP operations may involve the UE 601b using the WLAN radio resources (e.g., connection 607) via an IPsec protocol tunnel to authenticate and encrypt the packets (e.g., IP packets) sent through the connection 607. The IPsec tunnel transport may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0113] The RAN 610 includes one or more AN nodes or RAN nodes 611a and 611b (collectively referred to as "RAN nodes 611") that enable connections 603 and 604. As used herein, terms such as "access node", "access point", etc. may describe equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, TRxP, or TRP, etc., and may include a terrestrial station (e.g., a land access point) or a satellite station that provides coverage within a geographic area (e.g., a cell). As used herein, terms such as "NG RAN node" etc. may refer to a RAN node 611 (e.g., gNB) operating in an NR or 5G system 600, while terms such as "E-UTRAN node" etc. may refer to a RAN node 611 (e.g., eNB) operating in an LTE or 4G system 600. According to various embodiments, the RAN nodes 611 may be implemented as one or more of dedicated physical devices such as macrocell base stations and / or low-power (LP) base stations for providing femtocells, picocells, or other similar cells with a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to macrocells.

[0114] In some embodiments, all or part of the RAN nodes 611 may be implemented as one or more software entities running on a server computer, as part of a virtual network that may be referred to as a Cloud RAN (CRAN) and / or a virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN functional splits, such as, a PDCP split, where the RRC and PDCP layers are operated by the CRAN / vBBUP, and other L2 protocol entities are operated by the respective RAN nodes 611; a MAC / PHY split, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by the respective RAN nodes 611; or a "lower PHY" split, where the RRC, PDCP, RLC, MAC layers, and the upper part of the PHY layer are operated by the CRAN / vBBUP, and the lower part of the PHY layer is operated by the respective RAN nodes 611. This virtualization framework allows the idle processor cores of the RAN nodes 611 to execute other virtualized applications. In some specific implementations, each RAN node 611 may represent a respective gNB-DU connected to a gNB-CU via a respective F1 interface ( Figure 6 not shown). In these specific implementations, the gNB-DU may include one or more remote radio heads or RFEMs (see, for example, Figure 9), and the gNB-CU can be operated by a server (not shown) located in the RAN 610 or by a server pool in a manner similar to CRAN / vBBUP. In addition or alternatively, one or more of the RAN nodes in the RAN node 611 can be a next-generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol terminations to the UE 601 and is connected to the 5GC via the NG interface (discussed below) (e.g., Figure 8 the CN 820).

[0115] In a V2X scenario, one or more of the RAN nodes in the RAN node 611 can be or act as an RSU. The term "roadside unit" or "RSU" can refer to any traffic infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where the RSU implemented in or by the UE can be referred to as a "UE-type RSU", the RSU implemented in or by the eNB can be referred to as an "eNB-type RSU", the RSU implemented in or by the gNB can be referred to as a "gNB-type RSU", and so on. In one example, the RSU is a computing device coupled to a radio frequency circuit located on the roadside, which provides connectivity support to passing vehicle UEs 601 (vUE 601). The RSU can also include an internal data storage circuit for storing intersection map geometries, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can operate on the 5.9 GHz direct short-range communication (DSRC) band to provide extremely low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. In addition or alternatively, the RSU can operate on the cellular V2X band to provide the aforementioned low-latency communication and other cellular communication services. In addition or alternatively, the RSU can operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communication. Some or all of the computing device and the radio frequency circuit of the RSU can be encapsulated in a weather-resistant package suitable for outdoor installation and can include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or a backhaul network.

[0116] Any one of the RAN nodes in the RAN node 611 can terminate the air interface protocol and can be the first point of contact for the UE 601. In some embodiments, any one of the RAN nodes in the RAN node 611 can fulfill various logical functions of the RAN 610, including but not limited to the functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0117] In an embodiment, the UE 601 may be configured to communicate with each other or with any one of the RAN nodes 611 over a multi-carrier communication channel using OFDM communication signals according to various communication technologies, such as but not limited to OFDMA communication technology (e.g., for downlink communication) or SC-FDMA communication technology (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiment is not limited in this regard. The OFDM signal may include a plurality of orthogonal sub-carriers.

[0118] In some embodiments, a downlink resource grid may be used for downlink transmission from any one of the RAN nodes 611 to the UE 601, and uplink transmission may utilize a similar technique. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is the physical resource in the downlink in each time slot. For an OFDM system, such a time-frequency plane representation is a common practice, which makes wireless resource allocation intuitive. Each column and each row of the resource grid correspond to an OFDM symbol and an OFDM sub-carrier, respectively. The duration of the resource grid in the time domain corresponds to one time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the smallest amount of resources that can be currently allocated. Such resource blocks are used to transmit several different physical downlink channels.

[0119] According to various embodiments, the UE 601 and the RAN node 611 transmit data (e.g., transmit data and receive data) via a licensed medium (also referred to as "licensed spectrum" and / or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum" and / or "unlicensed band"). The licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum may include the 5 GHz band.

[0120] To operate in the unlicensed spectrum, the UE 601 and the RAN node 611 may use LAA, eLAA, and / or feLAA mechanisms to operate. In these specific implementations, the UE 601 and the RAN node 611 may perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to the listen-before-talk (LBT) protocol.

[0121] LBT is a mechanism by which devices (e.g., UE 601, RAN node 611, etc.) sense the medium (e.g., channel or carrier frequency) and transmit when the medium is sensed as idle (or when a specific channel in the medium is sensed as unoccupied). The medium sensing operation may include CCA, which uses at least ED to determine whether there are other signals on the channel to determine whether the channel is occupied or idle. The LBT mechanism allows the cellular / LAA network to coexist with existing systems in the unlicensed spectrum and with other LAA networks. ED may include sensing RF energy on the expected transmission band for a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0122] Generally, existing systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs adopt a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as UE 601, AP 606, etc.) intends to transmit, the WLAN node may first perform CCA before transmission. Additionally, in the case where more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. The backoff mechanism may be a counter randomly introduced within the CWS, which exponentially increases in the event of a collision and is reset to the minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to WLAN's CSMA / CA. In some specific implementations, the LBT process for DL or UL transmission bursts (including PDSCH or PUSCH transmissions) may have a variable-length LAA contention window between X and Y ECCA time slots, where X and Y are the minimum and maximum values of the LAA's CWS. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μs); however, the size of the CWS and the MCOT (e.g., transmission burst) may be based on government regulatory requirements.

[0123] The LAA mechanism is built on the CA technology of the LTE-Advanced system. In CA, each aggregated carrier is called a CC. A CC may have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, so the maximum aggregated bandwidth is 100 MHz. In an FDD system, for DL and UL, the number of aggregated carriers can be different, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, individual CCs may have different bandwidths from other CCs. In a TDD system, the number of CCs and the bandwidth of each CC are generally the same for DL and UL.

[0124] CA also includes respective serving cells to provide respective CCs. The coverage of the serving cells may vary, e.g., because the CCs on different frequency bands will experience different path losses. The primary serving cell or PCell may provide the PCC for both UL and DL and may handle activities related to RRC and NAS. The other serving cells are called SCell, and each SCell may provide respective SCCs for both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require the UE 601 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells may operate in the unlicensed spectrum (referred to as "LAA SCell"), and the LAA SCell is assisted by the PCell operating in the licensed spectrum. When the UE is configured with more than one LAA SCell, the UE may receive UL grants on the configured LAA SCells, indicating different PUSCH starting positions within the same subframe.

[0125] The PDSCH carries user data and higher layer signaling to the UE 601. Among other information, the PDCCH carries information about the transport format and resource allocation related to the PDSCH channel. It can also notify the UE 601 about the transport format, resource allocation, and HARQ information related to the uplink shared channel. Generally, downlink scheduling (allocating control and shared channel resource blocks to the UE 601b within the cell) can be performed at any of the RAN nodes 611 based on the channel quality information fed back from any of the UE 601s. Downlink resource allocation information can be sent on the PDCCH for each UE used (e.g., allocated to) in the UE 601.

[0126] The PDCCH uses CCEs to carry control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruples and then arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets of four physical resource elements, called REGs. Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the DCI and the channel conditions, one or more CCEs can be used to transmit the PDCCH. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8).

[0127] Some embodiments may use the concept of resource allocation for controlling channel information, which is an extension of the above concept. For example, some embodiments may utilize the EPDCCH that uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit the EPDCCH. Similar to the above, each ECCE may correspond to nine sets of four physical resource elements, called EREGs. In some cases, an ECCE may have other numbers of EREGs.

[0128] RAN nodes 611 may be configured to communicate with each other via interface 612. In an embodiment where system 600 is an LTE system (e.g., when CN 620 is an EPC 720 as in Figure 7 ), interface 612 may be an X2 interface 612. The X2 interface may be defined between two or more RAN nodes 611 (e.g., two or more eNBs, etc.) connected to the EPC 620, and / or between two eNBs connected to the EPC 620. In some specific implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user packets transmitted through the X2 interface and may be used to convey information about the delivery of user data between eNBs. For example, the X2-U may provide specific sequence number information about user data transmitted from the MeNB to the SeNB; information about the successful in-sequence delivery of PDCP PDUs from the SeNB to the UE 601 for user data; information about PDCP PDUs not delivered to the UE 601; information about the current minimum expected buffer size at the SeNB for transmitting user data to the UE; and so on. The X2-C may provide intra-LTE access mobility functions, including context transfer from the source eNB to the target eNB, user plane transmission control, etc.; load management functions; and inter-cell interference coordination functions.

[0129] In an embodiment where system 600 is a 5G or NR system (e.g., when CN 620 is as in Figure 8In an implementation of 5GC 820, interface 612 may be the Xn interface 612. The Xn interface is defined between two or more RAN nodes 611 (e.g., two or more gNBs, etc.) connected to 5GC 620, between a RAN node 611 (e.g., gNB) connected to 5GC 620 and an eNB, and / or between two eNBs connected to 5GC 620. 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 may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and traffic control functions. Xn-C may provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for UE 601 in the connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in the connected mode between one or more RAN nodes 611. This mobility support may include context transfer from an old (source) serving RAN node 611 to a new (target) serving RAN node 611; and control of the user plane tunnel between the old (source) serving RAN node 611 and the new (target) serving RAN node 611. The protocol stack of Xn-U may include a transport network layer built on the Internet Protocol (IP) transport layer, and a GTP-U layer for carrying user plane PDUs on top of the UDP and / or IP layer. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn application protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may be on top of the IP layer and may provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other specific implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0130] RAN 610 is shown as communicatively coupled to a core network (in this embodiment, communicatively coupled to core network (CN) 620). CN 620 may include a plurality of network elements 622 configured to provide various data and telecommunication services to customers / users (e.g., users of UE 601) connected to CN 620 via RAN 610. Components of CN 620 may be implemented in one physical node or separate physical nodes and include components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV may be used to virtualize any or all of the above-described network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instance of CN620 may be referred to as a network slice, and a logical instance of a portion of CN 620 may be referred to as a network sub-slice. NFV architectures and infrastructure may be used to virtualize one or more network functions onto physical resources that include a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, an NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0131] In general, application server 630 may be an element that provides an application that uses IP bearer resources in conjunction with the core network (e.g., UMTS PS domain, LTE PS data services, etc.). Application server 630 may also be configured to support one or more communication services for UE 601 via EPC 620 (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.).

[0132] In an embodiment, CN 620 may be a 5GC (referred to as "5GC 620", etc.), and RAN 610 may be connected to CN 620 via NG interface 613. In an embodiment, NG interface 613 may be divided into two parts: an NG user plane (NG-U) interface 614 that carries traffic data between RAN node 611 and UPF; and an S1 control plane (NG-C) interface 615 that is a signaling interface between RAN node 611 and AMF. Refer to Figure 8 Embodiments where CN 620 is 5GC 620 are discussed in more detail.

[0133] In an embodiment, the CN 620 may be a 5G CN (referred to as "5GC 620", etc.), while in other embodiments, the CN 620 may be an EPC. In the case where the CN 620 is an EPC (referred to as "EPC 620", etc.), the RAN 610 may be connected to the CN 620 via the S1 interface 613. In an embodiment, the S1 interface 613 may be divided into two parts: the S1 user plane (S1-U) interface 614, which carries traffic data between the RAN node 611 and the S-GW; and the S1-MME interface 615, which is a signaling interface between the RAN node 611 and the MME.

[0134] Figure 7 An exemplary architecture of a system 700 including a first CN 720 is shown according to various embodiments. In this example, the system 700 may implement the LTE standard, where the CN 720 is the EPC 720 corresponding to Figure 6 the CN 620. Additionally, the UE 701 may be the same as or similar to Figure 6 the UE 601, and the E-UTRAN 710 may be a RAN that is the same as or similar to Figure 6 the RAN 610, and it may include the RAN node 611 discussed previously. The CN 720 may include an MME 721, an S-GW 722, a P-GW 723, an HSS 724, and an SGSN 725.

[0135] The MME 721 may functionally be similar to the control plane of a traditional SGSN and may implement MM functions to keep track of the current location of the UE 701. The MME 721 may perform various MM procedures to manage aspects of mobility in access, such as gateway selection and tracking area list management. MM (also referred to as "EPS MM" or "EMM" in the E-UTRAN system) may refer to all applicable procedures, methods, data storage, etc. for maintaining knowledge of the current location of the UE 701, providing user identity confidentiality to the user / subscriber, and / or performing other similar services. Each UE 701 and the MME 721 may include an MM or EMM sublayer, and when the attachment process is successfully completed, an MM context may be established in the UE 701 and the MME 721. The MM context may be a data structure or database object that stores MM-related information of the UE 701. The MME 721 may be coupled to the HSS 724 via the S6a reference point, to the SGSN 725 via the S3 reference point, and to the S-GW 722 via the S11 reference point.

[0136] The SGSN 725 can be a node that serves the UE 701 by tracking the location of the individual UE 701 and performing security functions. Additionally, the SGSN 725 can perform inter-EPC node signaling for mobility between 2G / 3G and E-UTRAN 3GPP access networks; PDN and S-GW selection as specified by the MME 721; handling of the UE 701 time zone function as specified by the MME 721; and MME selection for handover to the E-UTRAN 3GPP access network. The S3 reference point between the MME 721 and the SGSN 725 can be enabled for user and bearer information exchange for 3GPP indirect access network mobility in the idle state and / or the active state.

[0137] The HSS 724 can include a database for network users that includes subscription-related information to support network entity handling of communication sessions. The EPC 720 can include one or several HSS 724s, depending on the number of mobile subscribers, the capacity of the equipment, the organization of the network, etc. For example, the HSS 724 can provide support for routing / roaming, authentication, authorization, naming / addressing solutions, location dependency, etc. The S6a reference point between the HSS 724 and the MME 721 can enable the transfer of subscription and authentication data for authenticating / authorizing user access to the EPC 720 between the HSS 724 and the MME 721.

[0138] The S-GW 722 can terminate the S1 interface 613 towards the RAN 710 (referred to as "S1-U" in Figure 7 ), and route data packets between the RAN 710 and the EPC 720. Additionally, the S-GW 722 can be a local mobility anchor for inter-RAN node handover, and can also provide an anchor for inter-3GPP mobility. Other responsibilities can include lawful interception, charging, and enforcement of certain policies. The S11 reference point between the S-GW722 and the MME 721 can provide a control plane between the MME 721 and the S-GW 722. The S-GW 722 can be coupled to the P-GW 723 via the S5 reference point.

[0139] The P-GW 723 can terminate the SGi interface towards the PDN 730. The P-GW 723 can route data packets between the EPC 720 and an external network such as a network including an application server 630 (alternatively referred to as "AF") via an IP interface 625 (see for example, Figure 6 ). In an embodiment, the P-GW 723 can be communicatively coupled to the application server ( Figure 6 ) via an IP communication interface 625 (see for example, Figure 6 the application server 630 of Figure 7in the PDN 730). The S5 reference point between the P-GW 723 and the S-GW 722 can provide user plane tunneling and tunnel management between the P-GW 723 and the S-GW 722. Due to the mobility of the UE 701 and whether the S-GW 722 needs to be connected to a non-collocated P-GW 723 for the required PDN connectivity, the S5 reference point can also be used for S-GW 722 relocation. The P-GW 723 may also include a node for policy enforcement and charging data collection (e.g., PCEF (not shown)). Additionally, the SGi reference point between the P-GW 723 and the packet data network (PDN) 730 can be an external public, private PDN of the operator or an internal operator packet data network, for example, for providing IMS services. The P-GW 723 can be coupled to the PCRF 726 via the Gx reference point.

[0140] The PCRF 726 is the policy and charging control element of the EPC 720. In a non-roaming scenario, there may be a single PCRF 726 in the home public land mobile network (HPLMN) associated with the Internet protocol connection access network (IP-CAN) session of the UE 701. In a roaming scenario with local traffic breakout, there may be two PCRFs associated with the IP-CAN session of the UE 701: the home PCRF (H-PCRF) in the HPLMN and the visited PCRF (V-PCRF) in the visited public land mobile network (VPLMN). The PCRF 726 can be communicatively coupled to the application server 730 via the P-GW 723. The application server 730 can signal the PCRF 726 to indicate a new service flow and select appropriate QoS and charging parameters. The PCRF 726 can configure the rule as a PCEF (not shown) with appropriate TFT and QCI, and start QoS and charging as specified by the application server 730. The Gx reference point between the PCRF 726 and the P-GW 723 can allow the transmission of QoS policies and charging rules from the PCRF 726 to the PCEF in the P-GW 723. The Rx reference point can reside between the PDN 730 (or "AF 730") and the PCRF 726.

[0141] Figure 8FIG. 0 shows the architecture of a system 800 including a second CN 820, according to various embodiments. The system 800 is shown including a UE 801, which may be the same as or similar to the previously discussed UE 601 and UE 701; a (R)AN 810, which may be the same as or similar to the previously discussed RAN 610 and RAN 710, and which may include the previously discussed RAN node 611; and a DN 803, which may be, for example, a carrier service, Internet access, or a third-party service; and a 5GC 820. The 5GC 820 may include an AUSF 822; an AMF 821; an SMF 824; a NEF 823; a PCF 826; an NRF 825; a UDM 827; an AF 828; a UPF 802; and an NSSF 829.

[0142] The UPF 802 may act as an anchor point for mobility within and between RATs, an external PDU session point of interconnection with the DN 803, and a branching point for supporting multi-homed PDU sessions. The UPF 802 may also perform packet routing and forwarding, perform packet inspection, perform the user plane part of policy rules, lawful intercept of packets (UP collection), perform traffic usage reporting, perform QoS handling for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 802 may include an uplink classifier for supporting routing of traffic flows to a data network. The DN 803 may represent various network operator services, Internet access, or third-party services. The DN 803 may include or be similar to the previously discussed application server 630. The UPF 802 may interact with the SMF 824 via an N4 reference point between the SMF 824 and the UPF 802.

[0143] The AUSF 822 may store data for authentication of the UE 801 and handle authentication-related functions. The AUSF 822 may facilitate a common authentication framework for various access types. The AUSF 822 may communicate with the AMF 821 via an N12 reference point between the AMF 821 and the AUSF 822; and may communicate with the UDM 827 via an N13 reference point between the UDM 827 and the AUSF 822. Additionally, the AUSF 822 may expose an interface based on the Nausf service.

[0144] The AMF 821 can be responsible for registration management (e.g., responsible for registering the UE 801, etc.), connection management, reachability management, mobility management, and lawful interception of AMF-related events, and access authentication and authorization. The AMF 821 can be the termination point of the N11 reference point between the AMF 821 and the SMF824. The AMF 821 can provide transmission for the SM messages between the UE 801 and the SMF 824 and act as a transparent proxy for routing the SM messages. The AMF 821 can also provide transmission for the SMS messages between the UE 801 and the SMSF ( Figure 8 not shown in the figure). The AMF 821 can act as the SEAF, which can include interactions with the AUSF 822 and the UE 801 and receive the intermediate key established due to the UE 801 authentication process. In the case of using USIM-based authentication, the AMF 821 can retrieve the security material from the AUSF822. The AMF 821 can also include the SCM function, which receives the key for deriving the access network-specific key from the SEA. In addition, the AMF 821 can be the termination point of the RAN CP interface, which can include or be the N2 reference point between the (R)AN 810 and the AMF821; and the AMF 821 can be the termination point of the NAS (N1) signaling and perform NAS encryption and integrity protection.

[0145] The AMF 821 can also support NAS signaling with the UE 801 through the N3 IWF interface. The N3IWF can be used to provide access to untrusted entities. The N3IWF can be the termination point of the N2 interface between the (R)AN 810 of the control plane and the AMF 821, and can be the termination point of the N3 reference point between the (R)AN 810 of the user plane and the UPF 802. Therefore, the AMF 821 can process the N2 signaling for the PDU session and QoS from the SMF 824 and the AMF 821, encapsulate / de-encapsulate packets for the IPSec and N3 tunnels, mark the N3 user plane packets on the uplink, and perform the QoS corresponding to the N3 packet marking, taking into account the QoS requirements associated with such markings received through the N2. The N3IWF can also relay the uplink and downlink control plane NAS signaling between the UE 801 and the AMF 821 via the N1 reference point between the UE 801 and the AMF 821, and relay the uplink and downlink user plane packets between the UE 801 and the UPF 802. The N3IWF also provides a mechanism for establishing an IPsec tunnel with the UE 801. The AMF 821 can present an interface based on the Namf service and can be the termination point of the N14 reference point between two AMF 821s and the N17 reference point between the AMF 821 and the 5G-EIR ( Figure 8 not shown).

[0146] The UE 801 may need to register with the AMF 821 to receive network services. The RM is used to register the UE 801 with the network (e.g., the AMF 821) or deregister the UE, and establish a UE context in the network (e.g., the AMF 821). The UE 801 can operate in the RM-REGISTERED state or the RM-DEREGISTERED state. In the RM DEREGISTERED state, the UE 801 is not registered with the network, and the UE context in the AMF 821 does not hold the valid location or routing information of the UE 801, so the AMF 821 cannot reach the UE 801. In the RM REGISTERED state, the UE 801 is registered with the network, and the UE context in the AMF 821 can hold the valid location or routing information of the UE 801, so the AMF 821 can reach the UE 801. In the RM-REGISTERED state, the UE 801 can perform a mobility registration update procedure, perform a periodic registration update procedure triggered by the expiration of a periodic update timer (e.g., to notify the network that the UE 801 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.

[0147] The AMF 821 can store one or more RM contexts for the UE 801, where each RM context is associated with a specific access to the network. The RM context can be a data structure, a database object, etc., which indicates or stores, in particular, the registration status and the periodic update timer for each access type. The AMF 821 can also store a 5GC MM context that can be the same as or similar to the previously discussed (E)MM context. In various embodiments, the AMF 821 can store the CE mode B restriction parameters of the UE 801 in the associated MM context or RM context. The AMF 821 can also derive values from the UE usage setting parameters that have been stored in the UE context (and / or MM / RM context) when needed.

[0148] CM can be used to establish and release a signaling connection between the UE 801 and the AMF 821 via the N1 interface. The signaling connection is used to enable NAS signaling exchange between the UE 801 and the CN 820, and includes a signaling connection between the UE and the AN (e.g., an RRC connection for non-3GPP access or a UE-N3IWF connection) and an N2 connection of the UE 801 between the AN (e.g., the RAN 810) and the AMF 821. The UE 801 can operate in one of two CM states (CM-IDLE mode or CM-CONNECTED mode). When the UE 801 operates in the CM-IDLE state / mode, the UE 801 may not have a NAS signaling connection established with the AMF 821 via the N1 interface, and there may be an (R)AN 810 signaling connection for the UE 801 (e.g., an N2 and / or N3 connection). When the UE 801 operates in the CM-CONNECTED state / mode, the UE 801 may have a NAS signaling connection established with the AMF 821 via the N1 interface, and there may be an (R)AN 810 signaling connection for the UE 801 (e.g., an N2 and / or N3 connection). Establishing an N2 connection between the (R)AN 810 and the AMF 821 may cause the UE 801 to transition from the CM-IDLE mode to the CM-CONNECTED mode, and when the N2 signaling between the (R)AN 810 and the AMF 821 is released, the UE 801 may transition from the CM-CONNECTED mode to the CM-IDLE mode.

[0149] The SMF 824 can be responsible for session management (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF and the AN node); UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuration of UPF traffic steering to route traffic to the correct destination; termination of the interface towards the policy control function; the policy enforcement and the control part of QoS; lawful interception (for SM events and the interface with the LI system); termination of the SM part of NAS messages; downlink data notification; initiation of AN-specific SM information sent to the AN via the AMF over N2; and determination of the SSC mode of the session. Session management can refer to the management of PDU sessions, and a PDU session or "session" can refer to a PDU connectivity service that provides or enables PDU exchange between the UE 801 identified by a data network name (DNN) and a data network (DN) 803. A PDU session can be established upon request by the UE 801, modified upon request by the UE 801 and the 5GC 820, and released using NAS SM signaling exchanged between the UE 801 and the SMF 824 over the N1 reference point upon request by the UE 801 and the 5GC 820. When requested from an application server, the 5GC 820 can trigger a specific application in the UE 801. In response to receiving the trigger message, the UE 801 can deliver the trigger message (or relevant parts / information of the trigger message) to one or more identified applications in the UE 801. The identified applications in the UE 801 can establish a PDU session to a specific DNN. The SMF 824 can check whether the UE 801 request complies with the user subscription information associated with the UE 801. In this regard, the SMF 824 can retrieve and / or request to receive an update notification on the subscription data at the SMF 824 level from the UDM 827.

[0150] The SMF 824 can include the following roaming functions: handling local enforcement to apply QoS SLA (VPLMN); charging data collection and charging interface (VPLMN); lawful interception (for SM events and the interface with the LI system, in the VPLMN); and support for interaction with an external DN to transmit signaling for PDU session authorization / authentication over the external DN. In a roaming scenario, the N16 reference point between two SMF 824s can be included in the system 800, which can be between the SMF 824 in the visited network and another SMF 824 in the home network. Additionally, the SMF 824 can present an interface based on the Nsmf service.

[0151] The NEF 823 can provide means for securely exposing the services and capabilities provided by 3GPP network functions for third parties, internal exposure / re-exposure, application functions (e.g., AF 828), edge computing or fog computing systems, etc. In such embodiments, the NEF 823 can authenticate, authorize, and / or restrict the AF. The NEF 823 can also transform the information exchanged with the AF 828 and the information exchanged with internal network functions. For example, the NEF 823 can transform between AF service identifiers and internal 5GC information. The NEF 823 can also receive information from other network functions (NFs) based on the exposure capabilities of other network functions. This information can be stored at the NEF 823 as structured data, or stored at a data storage NF using a standardized interface. Then, the stored information can be re-exposed by the NEF 823 to other NFs and AFs, and / or used for other purposes such as analysis. Additionally, the NEF 823 can present an interface based on the Nnef service.

[0152] The NRF 825 can support a service discovery function, receive NF discovery requests from NF instances, and provide information on the discovered NF instances to the NF instances. The NRF 825 also maintains information on available NF instances and the services they support. As used herein, terms such as "instantiation" can refer to the creation of an instance, and an "instance" can refer to a specific occurrence of an object, which can occur, for example, during the execution of program code. Additionally, the NRF 825 can present an interface based on the Nnrf service.

[0153] The PCF 826 can provide means for control plane functions to execute their policy rules, and can also support a unified policy framework for managing network behavior. The PCF 826 can also implement an FE to access subscription information related to policy decisions in the UDR of the UDM 827. The PCF 826 can communicate with the AMF 821 via the N15 reference point between the PCF 826 and the AMF 821, which can include the PCF 826 in a visited network and the AMF 821 in a roaming scenario. The PCF 826 can communicate with the AF 828 via the N5 reference point between the PCF 826 and the AF 828; and communicate with the SMF 824 via the N7 reference point between the PCF 826 and the SMF 824. The system 800 and / or the CN 820 can also include an N24 reference point between the PCF 826 (in a home network) and the PCF 826 (in a visited network). Additionally, the PCF 826 can present an interface based on the Npcf service.

[0154] The UDM 827 can process subscription-related information to support the handling of communication sessions by network entities and can store the subscription data of the UE 801. For example, subscription data can be transmitted between the UDM 827 and the AMF via the N8 reference point between the UDM 827 and the AMF 821. The UDM 827 can include two parts: the Application FE and the UDR ( Figure 8 The FE and the UDR are not shown). The UDR can store the subscription data and policy data of the UDM 827 and the PCF 826, and / or the structured data for exposure and application data of the NEF 823 (including the PFD for application detection, the application request information of multiple UEs 801). The Nudr service-based interface can be presented by the UDR 221 to allow the UDM 827, the PCF 826, and the NEF 823 to access a specific set of the stored data, and to read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM can include the UDM-FE, which is responsible for handling credentials, location management, subscription management, etc. In different transactions, several different front-ends can serve the same user. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management. The UDR can interact with the SMF 824 via the N10 reference point between the UDM 827 and the SMF 824. The UDM 827 can also support SMS management, where the SMS-FE implements similar application logic as described above. Additionally, the UDM 827 can present a Nudm service-based interface.

[0155] The AF 828 can provide the impact of the application on traffic routing, provide access to the NCE, and interact with the policy framework for policy control. The NCE can be a mechanism that allows the 5GC 820 and the AF 828 to provide information to each other via the NEF 823, and this mechanism can be used for edge computing implementations. In such implementations, the network operator and third-party services can be hosted near the attachment point of the UE 801 to achieve efficient service delivery by reducing the end-to-end latency and the load on the transport network. For edge computing implementations, the 5GC can select the UPF 802 near the UE 801 and perform traffic steering from the UPF 802 to the DN 803 via the N6 interface. This can be based on the UE subscription data, the UE location, and the information provided by the AF 828. In this way, the AF 828 can affect the UPF (re)selection and traffic routing. Based on the operator deployment, when the AF 828 is considered a trusted entity, the network operator can allow the AF 828 to directly interact with the relevant NF. Additionally, the AF 828 can present a Naf service-based interface.

[0156] The NSSF 829 selects a set of network slice instances that can serve the UE 801. If needed, the NSSF 829 can also determine the allowed NSSAI and the mapping to the subscribed S-NSSAI. The NSSF 829 can also determine, based on appropriate configuration and possibly by querying the NRF 825, a set of AMFs or a list of candidate AMFs 821 for serving the UE 801. The selection of a set of network slice instances for the UE 801 can be triggered by the AMF 821, where the UE 801 registers by interacting with the NSSF 829, which can cause the AMF 821 to change. The NSSF 829 can interact with the AMF 821 via the N22 reference point between the AMF 821 and the NSSF 829; and can communicate with another NSSF 829 in the visited network via the N31 reference point ( Figure 8 not shown). Additionally, the NSSF 829 can expose an interface based on the Nnssf service.

[0157] As previously discussed, the CN 820 can include an SMSF, which can be responsible for SMS subscription checking and verification and relaying SM messages to / from the UE 801 to / from other entities such as SMS-GMSC / IWMSC / SMS routers. The SMS can also interact with the AMF 821 and the UDM 827 for a notification procedure for which the UE 801 can be used for SMS transmission (e.g., setting the UE unreachable flag and notifying the UDM 827 when the UE 801 is available for SMS).

[0158] The CN 120 can also include Figure 8 other elements not shown, such as a data storage system / architecture, 5G-EIR, SEPP, etc. The data storage system can include SDSF, UDSF, etc. Any NF can store unstructured data into or retrieve it from the UDSF (e.g., UE context) via the N18 reference point between any NF and the UDSF ( Figure 8 not shown). A single NF can share the UDSF for storing its corresponding unstructured data, or each NF can have its own UDSF located at or near the single NF. Additionally, the UDSF can expose an interface based on the Nudsf service ( Figure 8 not shown). The 5G-EIR can be an NF that checks the status of the PEI to determine whether to blacklist a specific piece of equipment / entity from the network; and the SEPP can be a non-transparent proxy that performs topology hiding, message filtering, and policing on the PLMN-interworking control plane interface.

[0159] Additionally, there can be more reference points and / or service-based interfaces between NF services in the NF; however, for clarity, Figure 8These interfaces and reference points are omitted. In one example, CN 820 may include an Nx interface, which is an inter-CN interface between an MME (e.g., MME 721) and an AMF 821 to enable interworking between CN 820 and CN 720. Other example interfaces / reference points may include an interface based on the N5g-EIR service presented by the 5G-EIR, an N27 reference point between an NRF in a visited network and an NRF in a home network; and an N31 reference point between an NSSF in a visited network and an NSSF in a home network.

[0160] Figure 9 An example of infrastructure equipment 900 according to various embodiments is shown. Infrastructure equipment 900 (or "system 900") may be implemented as a base station, a radio headend, a RAN node (such as the RAN nodes 611 and / or AP 606 shown and described previously), an application server 630, and / or any other element / device discussed herein. In other examples, system 900 may be implemented in or by a UE.

[0161] System 900 includes an application circuit 905, a baseband circuit 910, one or more radio front-end modules 915, a memory circuit 920, a power management integrated circuit (PMIC) 925, a power splitter circuit 930, a network controller circuit 935, a network interface connector 940, a satellite positioning circuit 945, and a user interface 950. In some embodiments, device 900 may include additional elements, such as, for example, a memory / storage device, a display, a camera, a sensor, or an input / output (I / O) interface. In other embodiments, these components may be included in more than one device. For example, the circuits may be separately included in more than one device for CRAN, vBBU, or other similar implementations.

[0162] The application circuit 905 may include circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: low dropout regulator (LDO), interrupt controller, serial interfaces such as SPI, I2C, or general purpose programmable serial interface module, real-time clock (RTC), timer-counter (including interval timer and watchdog timer), general purpose input / output (I / O or IO), memory card controller such as Secure Digital (SD) multimedia card (MMC) or the like, Universal Serial Bus (USB) interface, Mobile Industry Processor Interface (MIPI) interface, and Joint Test Action Group (JTAG) test access port. The processor (or core) of the application circuit 905 may be coupled to or may include the memory / storage element and may be configured to execute instructions stored in the memory / storage element to enable various applications or operating systems to run on the system 900. In some embodiments, the memory / storage element may be an on-chip memory circuit that may include any suitable volatile and / or non-volatile memory such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid state memory, and / or any other type of memory device technology such as those discussed herein.

[0163] The processor of the application circuit 905 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC machines (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more digital signal processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, the application circuit 905 may include or may be a dedicated processor / controller for operating according to the various embodiments herein. As an example, the processor of the application circuit 905 may include one or more Apple A-series processors, Intel or processors; Advanced Micro Devices (AMD) processors, accelerated processing units (APUs), or processors; ARM-based processors licensed by ARM Holdings, Ltd., such as the ARM Cortex-A series processors provided by Cavium (TM), Inc., and MIPS-based designs from MIPS Technologies, Inc., such as MIPS Warrior P-class processors; and so on. In some embodiments, system 900 may not utilize application circuitry 905 and, instead, may include a dedicated processor / controller to process, for example, IP data received from an EPC or 5GC.

[0164] In some embodiments, application circuitry 905 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, and so on. The one or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. For example, the programmable processing device may be one or more field programmable devices (FPDs), such as field programmable gate arrays (FPGAs) and so on; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), and so on; ASICs, such as structured ASICs; programmable system-on-chips (PSoCs); and so on. In such embodiments, the circuitry of application circuitry 905 may include logic blocks or logic architectures, as well as other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, functions, and so on, of the various embodiments discussed herein. In such embodiments, the circuitry of application circuitry 905 may include memory units (e.g., erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, static memories (e.g., static random access memories (SRAMs), antifuse, and so on)) for storing logic blocks, logic architectures, data, and so on in look-up tables (LUTs) and so on.

[0165] Baseband circuitry 910 may be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits, a single-packaged integrated circuit soldered to a main circuit board, or a multi-chip module that includes two or more integrated circuits.

[0166] User interface circuitry 950 may include one or more user interfaces designed to enable a user to interact with system 900 or a peripheral component interface designed to enable peripheral components to interact with system 900. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., reset buttons), one or more indicators (e.g., light-emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, a speaker or other audio-emitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, and so on. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power interface, and so on.

[0167] The radio front end module (RFEM) 915 may include a millimeter wave (mmWave) RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separated from the mmWave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both mmWave and sub-millimeter wave radio functionality may be implemented in the same physical RFEM 915 incorporating both mmWave antennas and sub-millimeter waves.

[0168] The memory circuit 920 may include one or more of the following: a volatile memory including a dynamic random access memory (DRAM) and / or a synchronous dynamic random access memory (SDRAM), and a non-volatile memory (NVM) including a high-speed electrically erasable memory (commonly referred to as a "flash memory"), a phase change random access memory (PRAM), a magnetoresistive random access memory (MRAM), etc., and may be combined with and The memory circuit 920 may be implemented as one or more of: a solder-in package integrated circuit, a socket memory module, and a plug-in memory card.

[0169] The PMIC 925 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources, such as a battery or capacitor. The power alarm detection circuit may detect one or more of a brownout (undervoltage) and a surge (overvoltage) condition. The power tee circuit 930 may provide power extracted from a network cable to provide both power and data connections for the infrastructure equipment 900 using a single cable.

[0170] The network controller circuit 935 may provide connectivity to the network using a standard network interface protocol such as Ethernet, Ethernet based on a GRE tunnel, Ethernet based on a multi-protocol label switching (MPLS), or some other suitable protocol. A physical connection may be used to provide a network connection to / from the infrastructure equipment 900 via a network interface connector 940, which may be an electrical connection (commonly referred to as a "copper interconnect"), an optical connection, or a wireless connection. The network controller circuit 935 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the network controller circuit 935 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0171] The positioning circuit 945 includes circuitry for receiving and decoding signals transmitted / broadcast by a positioning network of a Global Navigation Satellite System (GNSS). Examples of navigation satellite constellations (or GNSS) include the Global Positioning System (GPS) of the United States, the Global Navigation System (GLONASS) of Russia, the Galileo system of the European Union, the Beidou Navigation Satellite System of China, regional navigation systems, or GNSS augmentation systems (e.g., for navigation using the Indian Constellation (NAVIC), the Quasi-Zenith Satellite System (QZSS) of Japan, the Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS) of France, etc.). The positioning circuit 945 includes various hardware elements (e.g., including hardware devices for facilitating OTA communication such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some embodiments, the positioning circuit 945 may include a Microtechnology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a primary timing clock to perform position tracking / estimation in the absence of GNSS assistance. The positioning circuit 945 may also be part of or interact with the baseband circuit 910 and / or the RFEM 915 to communicate with nodes and components of the positioning network. The positioning circuit 945 may also provide position data and / or time data to the application circuit 905, which may use this data to synchronize operations with various infrastructure (e.g., RAN node 611, etc.).

[0172] Figure 9 The components shown may communicate with each other using an interface circuit, which may include any number of bus and / or interconnect (IX) technologies such as Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), or any number of other technologies. The bus / IX may be a proprietary bus, e.g., used in an SoC-based system. Other bus / IX systems may be included, such as I2C interface, SPI interface, point-to-point interface, and power bus, etc.

[0173] Figure 10 An example of a platform 1000 (or “device 1000”) is shown according to various embodiments. In an embodiment, the computer platform 1000 may be adapted to be used as a UE 601, UE 701, UE 801, an application server 630, and / or any other element / device discussed herein. The platform 1000 may include any combination of the components shown in the example. The components of the platform 1000 may be implemented as integrated circuits (ICs), parts of ICs, discrete electronic devices, or other modules, logic, hardware, software, firmware, or combinations thereof adapted within the computer platform 1000, or as components otherwise incorporated within the chassis of a larger system. Figure 10The block diagram is intended to show a high-level view of the components of computer platform 1000. However, some of the components shown may be omitted, additional components may exist, and different arrangements of the components shown may occur in other specific implementations.

[0174] Application circuitry 1005 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of an LDO, an interrupt controller, a serial interface (such as SPI), an I2C or a general programmable serial interface module, an RTC, a timer-counter (including interval timer and watchdog timer), general-purpose I / O, a memory card controller (such as SDMMC or a similar controller), a USB interface, a MIPI interface, and a JTAG test access port. The processor (or core) of application circuitry 1005 may be coupled to the memory / storage element or may include the memory / storage element, and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on system 1000. In some specific implementations, the memory / storage element may be an on-chip memory circuit that may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0175] The processor of application circuitry 905 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, some other known processing elements, or any suitable combination thereof. In some embodiments, application circuitry 905 may include or may be a dedicated processor / controller for operating according to the various embodiments herein.

[0176] As an example, the processor of application circuitry 1005 may include an Apple A series processor. The processor of application circuitry 1005 may also be one or more of the following: a processor based on Architecture Core TM such as Quark TM 、Atom TM 、i3, i5, i7 or MCU-class processors, or may be available from Corporation ( Another such processor from Corporation, Santa Clara, CA); Advanced Micro Devices (AMD) A processor or an accelerated processing unit (APU); from Snapdragon from Technologies, Inc. TM Processors, Texas Instruments, Open Multimedia Applications Platform (OMAP) TM Processors; MIPS-based designs from MIPS Technologies, Inc., such as MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, Ltd., such as ARM Cortex-A, Cortex-R, and Cortex-M series processors; etc. In some specific implementations, the application circuitry 1005 can be part of a system-on-chip (SoC), where the application circuitry 1005 and other components are formed as a single integrated circuit.

[0177] In addition or alternatively, the application circuitry 1005 can include circuitry such as, but not limited to, one or more field programmable devices (FPDs) such as FPGAs, etc.; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), etc.; ASICs, such as structured ASICs, etc.; programmable SoCs (PSoCs); etc. In such embodiments, the circuitry of the application circuitry 1005 can include logic blocks or logic architectures, and other interconnect resources that can be programmed to perform various functions such as the processes, methods, functions, etc. discussed in various embodiments herein. In such embodiments, the circuitry of the application circuitry 1005 can include memory units (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.)) for storing logic blocks, logic architectures, data, etc. in look-up tables (LUTs), etc.

[0178] The baseband circuitry 1010 can be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits, a single packaged integrated circuit soldered to the main circuit board, or a multi-chip module that includes two or more integrated circuits.

[0179] RFEM 1015 may include a millimeter-wave (mmWave) RFEM and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some embodiments, the one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In an alternative embodiment, the radio functions of both millimeter-wave and sub-millimeter-wave may be implemented in the same physical RFEM 1015 that combines millimeter-wave antennas and sub-millimeter-waves.

[0180] Memory circuit 1020 may include any number and type of memory devices for providing a given amount of system memory. For example, memory circuit 1020 may include one or more of the following: volatile memory, which includes random access memory (RAM), dynamic RAM (DRAM), and / or synchronous dynamic RAM (SDRAM); and non-volatile memory (NVM), which includes high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc. Memory circuit 1020 may be developed according to JEDEC low-power double data rate (LPDDR)-based designs such as LPDDR2, LPDDR3, LPDDR4, etc. Memory circuit 1020 may be implemented as one or more of the following: a soldered-in package integrated circuit, a single-die package (SDP), a dual-die package (DDP), or a quad-die package (Q17P), a socketed memory module, a dual in-line memory module (DIMM) including a micro-DIMM or a mini-DIMM, and / or soldered to a motherboard via a ball grid array (BGA). In low-power embodiments, memory circuit 1020 may be on-chip memory or registers associated with application circuit 1005. To provide persistent storage of information such as data, applications, operating systems, etc., memory circuit 1020 may include one or more mass storage devices, which may particularly include solid-state disk drives (SSDDs), hard disk drives (HDDs), micro-HDDs, resistive change memories, phase change memories, holographic memories, or chemical memories, etc. For example, computer platform 1000 may incorporate 3D cross-point (XPOINT) memory obtained from and of.

[0181] The removable memory circuit 1023 may include devices, circuits, enclosures / cases, ports, or sockets, etc., for coupling a portable data storage device to the platform 1000. These portable data storage devices may be used for mass storage and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, micro SD cards, xD Picture cards, etc.), as well as USB flash drives, optical discs, external HDDs, etc.

[0182] The platform 1000 may also include interface circuitry (not shown) for connecting external devices to the platform 1000. External devices connected to the platform 1000 via this interface circuitry include sensor circuit 1021 and electromechanical components (EMC) 1022, as well as a removable memory device coupled to the removable memory circuit 1023.

[0183] The sensor circuit 1021 includes devices, modules, or subsystems aimed at detecting events or changes in its environment and sending information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors particularly include: Inertial Measurement Units (IMUs) including accelerometers, gyroscopes, and / or magnetometers; Micro-Electro-Mechanical Systems (MEMS) or Nano-Electro-Mechanical Systems (NEMS) including three-axis accelerometers, three-axis gyroscopes, and / or magnetometers; liquid level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless apertures); Light Detection and Ranging (LiDAR) sensors; proximity sensors (e.g., infrared radiation detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers; microphones or other similar audio capture devices; etc.

[0184] The EMC 1022 includes devices, modules, or subsystems aimed at enabling the platform 1000 to change its state, position, and / or orientation or move or control mechanisms or (sub)systems. Additionally, the EMC 1022 may be configured to generate messages / signaling and send messages / signaling to other components of the platform 1000 to indicate the current state of the EMC 1022. Examples of the EMC 1022 include one or more power switches, relays (including electromechanical relays (EMRs) and / or solid-state relays (SSRs)), actuators (e.g., valve actuators, etc.), audible sound generators, visual warning devices, motors (e.g., DC motors, stepper motors, etc.), wheels, thrusters, propellers, claws, clamps, hooks, and / or other similar electromechanical components. In an embodiment, the platform 1000 is configured to operate one or more EMC 1022 based on one or more captured events and / or instructions or control signals received from a service provider and / or various clients.

[0185] In some specific implementations, the interface circuit may connect the platform 1000 to the positioning circuit 1045. The positioning circuit 1045 includes circuitry for receiving and decoding signals transmitted / broadcast by the positioning network of GNSS. Examples of navigation satellite constellations (or GNSS) may include GPS of the United States, GLONASS of Russia, Galileo system of the European Union, Beidou Navigation Satellite System of China, regional navigation systems, or GNSS augmentation systems (e.g., NAVIC, QZSS of Japan, DORIS of France, etc.). The positioning circuit 1045 includes various hardware components (e.g., including hardware devices for facilitating OTA communication such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some embodiments, the positioning circuit 1045 may include a micro PNT IC that uses the primary timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit 1045 may also be part of or interact with the baseband circuit 910 and / or the RFEM 1015 to communicate with nodes and components of the positioning network. The positioning circuit 1045 may also provide position data and / or time data to the application circuit 1005, which may use this data to synchronize operations with various infrastructures (e.g., radio base stations) for turn-by-turn navigation applications, etc.

[0186] In some specific implementations, the interface circuit may connect the platform 1000 to the near field communication (NFC) circuit 1040. The NFC circuit 1040 is configured to provide non-contact short-range communication based on radio frequency identification (RFID) standards, where magnetic field sensing is used to enable communication between the NFC circuit 1040 and NFC-enabled devices external to the platform 1000 (e.g., "NFC touch points"). The NFC circuit 1040 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller may be a chip / IC that provides NFC functionality to the NFC circuit 1040 by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to transmit short-range RF signals. The RF signals may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transfer stored data to the NFC circuit 1040, or initiate data transfer between the NFC circuit 1040 and another active NFC device (e.g., a smart phone or an NFC-enabled POS terminal) near the platform 1000.

[0187] The drive circuit 1046 may include software elements and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled with the platform 1000. The drive circuit 1046 may include individual drivers, thereby allowing other components of the platform 1000 to interact with or control various input / output (I / O) devices that may be present within or connected to the platform 1000. For example, the drive circuit 1046 may include: a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to a touchscreen interface of the platform 1000, a sensor driver for obtaining sensor readings of the sensor circuit 1021 and controlling and allowing access to the sensor circuit 1021, an EMC driver for obtaining the actuator position of the EMC 1022 and / or controlling and allowing access to the EMC 1022, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0188] A power management integrated circuit (PMIC) 1025 (also referred to as “power management circuit 1025”) may manage the power provided to various components of the platform 1000. Specifically, relative to the baseband circuit 1010, the PMIC 1025 may control power selection, voltage regulation, battery charging, or DC-DC conversion. When the platform 1000 is capable of being powered by a battery 1030, for example, when the device is included in the UE601, UE701, and UE801, the PMIC 1025 may typically be included.

[0189] In some embodiments, the PMIC 1025 can control or otherwise be part of various power saving mechanisms of the platform 1000. For example, if the platform 1000 is in the RRC_Connected state, in which the platform remains connected to the RAN node because it expects to receive traffic soon, after a period of inactivity, the platform can enter a state called discontinuous reception mode (DRX). During this state, the platform 1000 can power down for short intervals, thus saving power. If there is no data traffic activity for an extended period, the platform 1000 can transition to the RRC_Idle state, in which the device is disconnected from the network and does not perform operations such as channel quality feedback, handover, etc. The platform 1000 enters a very low power state and performs paging, in which the device wakes up periodically again to listen for the network and then powers down again. The platform 1000 may not receive data in this state; to receive data, the platform must transition back to the RRC_Connected state. Additional power saving modes can make the device unavailable to the network for longer than the paging interval (ranging from seconds to hours). During this period, the device is completely unable to connect to the network and can be completely powered down. Any data sent during this period will incur a significant delay, and it is assumed that the delay is acceptable.

[0190] The battery 1030 can power the platform 1000, but in some examples, the platform 1000 can be installed in a fixed location and can have a power source coupled to the power grid. The battery 1030 can be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in V2X applications, the battery 1030 can be a typical lead-acid automotive battery.

[0191] In some specific implementations, the battery 1030 can be a "smart battery" that includes or is coupled to a battery management system (BMS) or a battery monitoring integrated circuit. The BMS can be included in the platform 1000 to track the state of charge (SoCh) of the battery 1030. The BMS can be used to monitor other parameters of the battery 1030, such as the state of health (SoH) and state of function (SoF) of the battery 1030, to provide fault prediction. The BMS can communicate information about the battery 1030 to the application circuit 1005 or other components of the platform 1000. The BMS can also include an analog-to-digital (ADC) converter that allows the application circuit 1005 to directly monitor the voltage of the battery 1030 or the current from the battery 1030. The battery parameters can be used to determine actions that the platform 1000 can perform, such as transmission frequency, network operation, sensing frequency, etc.

[0192] A power block or other power source coupled to the power grid can be coupled to the BMS to charge the battery 1030. In some examples, the power block XS30 can be replaced with a wireless power receiver to wirelessly obtain power, for example, through a loop antenna in the computer platform 1000. In these examples, the wireless battery charging circuit can be included in the BMS. The specific charging circuit selected can depend on the size of the battery 1030 and thus on the required current. Charging can be performed using the aviation fuel standards published by the Aviation Fuel Alliance, the Qi wireless charging standards published by the Wireless Power Consortium, or the Rezence charging standards published by the Wireless Power Consortium.

[0193] The user interface circuit 1050 includes various input / output (I / O) devices present within or connected to the platform 1000 and includes one or more user interfaces designed to enable interaction with the user of the platform 1000 and / or a peripheral component interface designed to enable interaction with peripheral components of the platform 1000. The user interface circuit 1050 includes input device circuitry and output device circuitry. The input device circuitry includes any physical or virtual means for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. The output device circuitry includes any physical or virtual means for displaying information or otherwise communicating information (such as sensor readings, actuator positions, or other similar information). The output device circuitry can include any number and / or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary state indicators (e.g., light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as a display device or a touchscreen (e.g., a liquid crystal display (LCD), an LED display, a quantum dot display, a projector, etc.), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the platform 1000. The output device circuitry can also include speakers or other audio emitting devices, printers, etc. In some embodiments, the sensor circuit 1021 can be used as input device circuitry (e.g., an image capture device, a motion capture device, etc.), and one or more EMCs can be used as output device circuitry (e.g., an actuator for providing haptic feedback, etc.). In another example, an NFC circuit can be included to read an electronic tag and / or connect to another NFC-enabled device, and the NFC circuit includes an NFC controller and a processing device coupled to an antenna element. The peripheral component interface can include, but is not limited to, a non-volatile memory port, a USB port, an audio jack, a power interface, etc.

[0194] Although not shown, components of platform 1000 may communicate with each other using suitable bus or interconnect (IX) technology, which may include any number of technologies, including ISA, EISA, PCI, PCIx, PCIe, Time-Triggered Protocol (TTP) systems, FlexRay systems, or any number of other technologies. The bus / IX may be a proprietary bus / IX, for example, used in an SoC-based system. Other bus / IX systems may be included, such as I2C interfaces, SPI interfaces, point-to-point interfaces, and power buses, among others.

[0195] Figure 11 Illustrated are various protocol functions that may be implemented in a wireless communication device. Specifically, Figure 11 includes arrangement 1100 showing the interconnections between various protocol layers / entities. The following description is provided for various protocol layers / entities operating in conjunction with 5G / NR system standards and LTE system standards, but Figure 11 some or all aspects of Figure 11 may also be applicable to other wireless communication network systems.

[0196] In addition to other higher layer functions not shown, the protocol layers of arrangement 1100 may include one or more of PHY 1110, MAC 1120, RLC 1130, PDCP 1140, SDAP 1147, RRC 1155, and NAS layer 1157. These protocol layers may include one or more service access points capable of providing communication between two or more protocol layers (e.g., Figure 11 items 1159, 1156, 1150, 1149, 1145, 1135, 1125, and 1115 in

[0197] The PHY 1110 can transmit and receive physical layer signals 1105, which can be received from or transmitted to one or more other communication devices. The physical layer signals 1105 can include one or more physical channels, such as those discussed herein. The PHY 1110 can also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers (e.g., RRC 1155). The PHY 1110 can further perform error detection on transport channels, forward error correction (FEC) encoding / decoding of transport channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping to physical channels, and MIMO antenna processing. In an embodiment, an instance of the PHY 1110 can process requests from an instance of the MAC 1120 via one or more PHY-SAPs 1115 and provide indications thereto. According to some embodiments, the requests and indications transmitted via the PHY-SAP 1115 can include one or more transport channels.

[0198] An instance of the MAC 1120 can process requests from an instance of the RLC 1130 via one or more MAC-SAPs 1125 and provide indications thereto. These requests and indications transmitted via the MAC-SAP 1125 can include one or more logical channels. The MAC 1120 can perform mapping between logical channels and transport channels, multiplex MAC SDUs from one or more logical channels onto a TB to be delivered to the PHY 1110 via the transport channel, demultiplex MAC SDUs from a TB delivered from the PHY 1110 via the transport channel onto one or more logical channels, multiplex MAC SDUs onto a TB, schedule information reporting, error correction via HARQ, and logical channel prioritization.

[0199] An instance of RLC 1130 can process requests from an instance of PDCP 1140 and provide indications thereto via one or more radio link control service access points (RLC-SAPs) 1135. These requests and indications transmitted via RLC-SAP 1135 can include one or more RLC channels. RLC 1130 can operate in multiple operation modes, including: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). RLC 1130 can perform the transmission of upper layer protocol data units (PDUs), error correction by automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmission. RLC 1130 can also perform resegmentation of RLC data PDUs for AM data transmission, reordering of RLC data PDUs for UM and AM data transmission, detection of duplicate data for UM and AM data transmission, discarding of RLC SDUs for UM and AM data transmission, detection of protocol errors for AM data transmission, and perform RLC re-establishment.

[0200] An instance of PDCP 1140 can process requests from an instance of RRC 1155 and / or an instance of SDAP 1147 and provide indications thereto via one or more packet data convergence protocol service access points (PDCP-SAPs) 1145. These requests and indications transmitted via PDCP-SAP 1145 can include one or more radio bearers. PDCP 1140 can perform header compression and decompression of IP data, maintain a PDCP sequence number (SN), perform in-sequence delivery of upper layer PDUs upon lower layer re-establishment, eliminate duplication of lower layer SDUs upon re-establishment of the lower layer for radio bearers mapped to RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification on control plane data, control timer-based data discarding, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

[0201] Instances of SDAP 1147 can process requests from one or more higher layer protocol entities via one or more SDAP-SAPs 1149 and provide indications thereto. These requests and indications transmitted via SDAP-SAP 1149 can include one or more QoS flows. SDAP 1147 can map QoS flows to DRBs and vice versa, and can also mark the QFI in DL packets and UL packets. A single SDAP entity 1147 can be configured for a separate PDU session. In the UL direction, NG-RAN 610 can control the mapping of QoS flows to DRBs in two different ways (reflection mapping or explicit mapping). For reflection mapping, the SDAP 1147 of UE 601 can monitor the QFI of DL packets of each DRB, and can apply the same mapping to the packets flowing in the UL direction. For a DRB, the SDAP 1147 of UE 601 can map UL packets belonging to a QoS flow that corresponds to the QoS flow ID and PDU session observed in the DL packets of that DRB. To implement reflection mapping, NG-RAN 810 can mark DL packets with the QoS flow ID via the Uu interface. Explicit mapping can involve RRC 1155 configuring SDAP 1147 with an explicit mapping rule of QoS flows to DRBs, which can be stored and followed by SDAP 1147. In an implementation, SDAP 1147 can be used only in NR implementations and not in LTE implementations.

[0202] RRC 1155 can configure aspects of one or more protocol layers via one or more management service access points (M-SAPs), and the one or more protocol layers can include one or more instances of PHY 1110, MAC 1120, RLC 1130, PDCP 1140, and SDAP 1147. In an implementation, an instance of RRC 1155 can process requests from one or more NAS entities 1157 and provide indications thereto via one or more RRC-SAPs 1156. The main services and functions of RRC 1155 can include broadcasting of system information (e.g., included in an MIB or SIB related to NAS), broadcasting of system information related to the access stratum (AS), paging, establishment, maintenance, and release of an RRC connection between UE 601 and RAN 610 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, mobility between RATs, and measurement configuration for UE measurement reporting. These MIBs and SIBs can include one or more IEs, each of which can include separate data fields or data structures.

[0203] NAS 1157 can form the top layer of the control plane between the UE 601 and the AMF 821. NAS 1157 can support the mobility and session management procedures of the UE 601 to establish and maintain an IP connection between the UE 601 and the P-GW in an LTE system.

[0204] According to various embodiments, one or more protocol entities of the arrangement 1100 can be implemented in the UE 601, the RAN node 611, the AMF 821 in the NR implementation or the MME 721 in the LTE implementation, the UPF 802 in the NR implementation or the S-GW 722 and the P-GW 723 in the LTE implementation, etc., for the control plane or user plane communication protocol stacks between the aforementioned devices. In such embodiments, one or more protocol entities that can be implemented in one or more of the UE 601, the gNB 611, the AMF 821, etc. can communicate with the corresponding peer protocol entities that can be implemented in another device or on another device (performing such communication using the services of the corresponding lower layer protocol entities). In some embodiments, the gNB-CU of the gNB 611 can host the RRC 1155, the SDAP 1147, and the PDCP 1140 that control one or more gNB-DU operations of the gNB, and each gNB-DU of the gNB 611 can host the RLC 1130, the MAC 1120, and the PHY 1110 of the gNB 611.

[0205] In a first example, the control plane protocol stack can include, in order from the top layer to the bottom layer, NAS 1157, RRC 1155, PDCP 1140, RLC 1130, MAC 1120, and PHY 1110. In this example, the upper layer 1160 can be built on top of NAS 1157, which includes an IP layer 1161, an SCTP 1162, and an application layer signaling protocol (AP) 1163.

[0206] In the NR implementation, the AP 1163 can be the NG application protocol layer (NGAP or NG-AP) 1163 for the NG interface 613 defined between the NG-RAN node 611 and the AMF 821, or the AP 1163 can be the Xn application protocol layer (XnAP or Xn-AP) 1163 for the Xn interface 612 defined between two or more RAN nodes 611.

[0207] The NG-AP 1163 can support the functions of the NG interface 613 and may include a basic procedure (EP). The NG-AP EP can be an interaction unit between the NG-RAN node 611 and the AMF 821. The NG-AP 1163 services can include two groups: UE-associated services (e.g., services related to the UE 601) and non-UE-associated services (e.g., services related to the entire NG interface instance between the NG-RAN node 611 and the AMF 821). These services can include functions, including but not limited to: a paging function for sending a paging request to the NG-RAN node 611 involved in a specific paging area; a UE context management function for allowing the AMF 821 to establish, modify, and / or release the UE context in the AMF 821 and the NG-RAN node 611; a mobility function for the UE 601 in the ECM-CONNECTED mode, for in-system HO to support mobility within the NG-RAN, and for inter-system HO to support mobility from / to the EPS system; a NAS signaling transmission function for transmitting or rerouting NAS messages between the UE 601 and the AMF 821; a NAS node selection function for determining the association between the AMF 821 and the UE 601; an NG interface management function for setting the NG interface and monitoring errors through the NG interface; a warning message sending function for providing a means to transmit a warning message via the NG interface or cancel the ongoing broadcast of a warning message; a configuration transmission function for requesting and transmitting RAN configuration information (e.g., SON information, performance measurement (PM) data, etc.) between two RAN nodes 611 via the CN 620; and / or other similar functions.

[0208] The XnAP 1163 can support the functions of the Xn interface 612 and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures can include procedures for handling UE mobility within the NG RAN 611 (or E-UTRAN 710), such as handover preparation and cancellation procedures, SN status transmission procedures, UE context retrieval and UE context release procedures, RAN paging procedures, procedures related to dual connectivity, etc. The XnAP global procedures can include procedures that are not related to a specific UE 601, such as Xn interface setup and reset procedures, NG-RAN update procedures, cell activation procedures, etc.

[0209] In the LTE embodiment, the AP 1163 can be the S1 application protocol layer (S1-AP) 1163 for the S1 interface 613 defined between the E-UTRAN node 611 and the MME, or the AP 1163 can be the X2 application protocol layer (X2AP or X2-AP) 1163 for the X2 interface 612 defined between two or more E-UTRAN nodes 611.

[0210] The S1 Application Protocol Layer (S1-AP) 1163 can support the functions of the S1 interface, and similar to the previously discussed NG-AP, the S1-AP can include S1-AP EPs. The S1-AP EP can be an interaction unit between the E-UTRAN node 611 and the MME 721 within the LTE CN 620. The services provided by the S1-AP 1163 can be divided into two groups: UE-associated services and non-UE-associated services. The functions performed by these services include, but are not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transmission, RAN Information Management (RIM), and configuration transfer.

[0211] The X2AP 1163 can support the functions of the X2 interface 612, and can include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures can include procedures for handling UE mobility within the E-UTRAN 620, such as handover preparation and cancellation procedures, SN status transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, procedures related to dual connectivity, etc. The X2AP global procedures can include procedures that are not related to a specific UE 601, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, cell activation procedures, etc.

[0212] The SCTP layer (alternatively referred to as the SCTP / IP layer) 1162 can provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in an NR implementation, or S1-AP or X2AP messages in an LTE implementation). The SCTP 1162 can ensure reliable delivery of signaling messages between the RAN node 611 and the AMF 821 / MME 721, partially based on the IP protocol supported by the IP 1161. The Internet Protocol layer (IP) 1161 can be used to perform packet addressing and routing functions. In some implementations, the IP layer 1161 can use point-to-point transmission to deliver and transfer PDUs. In this regard, the RAN node 611 can include communication links (e.g., wired or wireless) with the L2 and L1 layers of the MME / AMF to exchange information.

[0213] In a second example, the user plane protocol stack may include, in order from the highest layer to the lowest layer, SDAP 1147, PDCP 1140, RLC 1130, MAC 1120, and PHY 1110. The user plane protocol stack may be used for communication between UE 601, RAN node 611, and UPF 802 in an NR implementation, or between S-GW 722 and P-GW 723 in an LTE implementation. In this example, upper layer 1151 may be built on top of SDAP 1147 and may include User Datagram Protocol (UDP) and Internet Protocol Security layer (UDP / IP) 1152, General Packet Radio Service (GPRS) Tunneling Protocol for the user plane layer (GTP-U) 1153, and User Plane PDU layer (UPPDU) 1163.

[0214] The transport network layer 1154 (also referred to as the "transport layer") may be built on top of IP transport, and GTP-U 1153 may be used on top of the UDP / IP layer 1152 (including the UDP layer and the IP layer) to carry user plane PDUs (UP-PDUs). The IP layer (also referred to as the "Internet layer") may be used to perform packet addressing and routing functions. The IP layer may assign IP addresses to user data packets in, for example, any one of the IPv4, IPv6, or PPP formats.

[0215] GTP-U 1153 may be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the user data being transmitted may be packets in any one of the IPv4, IPv6, or PPP formats. UDP / IP 1152 may provide a checksum for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data flows. RAN node 611 and S-GW 722 may exchange user plane data via a protocol stack including L1 layer (e.g., PHY 1110), L2 layer (e.g., MAC 1120, RLC 1130, PDCP 1140, and / or SDAP 1147), UDP / IP layer 1152, and GTP-U 1153 using the S1-U interface. S-GW 722 and P-GW 723 may exchange user plane data via a protocol stack including L1 layer, L2 layer, UDP / IP layer 1152, and GTP-U 1153 using the S5 / S8a interface. As previously discussed, the NAS protocol may support the mobility and session management procedures of UE 601 to establish and maintain an IP connection between UE 601 and P-GW 723.

[0216] In addition, although Figure 11Not shown, but the application layer may exist above the AP 1163 and / or the transport network layer 1154. The application layer may be a layer where users of the UE 601, RAN node 611, or other network elements interact with software applications executed by, for example, the application circuit 905 or the application circuit 1005, respectively. The application layer may also provide one or more interfaces for the software applications to interact with the communication system (such as the baseband circuit XT110) of the UE 601 or the RAN node 611. In some specific implementations, the IP layer and / or the application layer may provide the same or similar functions as layers 5 to 7 or parts thereof of the Open Systems Interconnection (OSI) model (e.g., OSI layer 7 - application layer, OSI layer 6 - presentation layer, and OSI layer 5 - session layer).

[0217] With respect to a 5G system (see, for example, Figure 8 ), a network slice always includes a RAN part and a CN part. Support for network slicing relies on the principle that traffic for different slices is handled by different PDU sessions. The network can implement different network slices by scheduling and also by providing different L1 / L2 configurations. If the NAS has provided an RRC message, the UE 801 provides assistance information for network slice selection in an appropriate RRC message. Although the network may support a large number of slices, the UE does not need to support more than eight slices simultaneously.

[0218] A network slice may include the CN 820 control plane and user plane NFs, the NG-RAN 810 in the serving PLMN, and the N3IWF function in the serving PLMN. Each network slice may have a different S-NSSAI and / or may have a different SST. The NSSAI includes one or more S-NSSAIs, and each network slice is uniquely identified by the S-NSSAI. Network slices may differ in terms of the supported features and network function optimizations, and / or multiple network slice instances may deliver the same service / features but differ for different groups of UEs 801 (e.g., enterprise users). For example, each network slice may deliver different promised services and / or may be dedicated to a specific customer or enterprise. In this example, each network slice may have a different S-NSSAI with the same SST but with different slice differentiators. Additionally, a single UE may be served simultaneously by one or more network slice instances via the 5G AN and be associated with eight different S-NSSAIs. Furthermore, the AMF 821 instance serving a single UE 801 may belong to each network slice instance serving that UE.

[0219] Network slicing in NG-RAN 810 involves RAN slice awareness. RAN slice awareness includes differentiated handling of traffic for different network slices that have been pre-configured. Slice awareness in NG-RAN 810 is introduced at the PDU session level by indicating the S-NSSAI corresponding to the PDU session in all signaling that includes PDU session resource information. How NG-RAN 810 supports enabling slices in terms of NG-RAN functions (e.g., a set of network functions per slice) depends on the specific implementation. NG-RAN 810 uses the auxiliary information provided by UE 801 or 5GC 820 to select the RAN part of the network slice, and this auxiliary information explicitly identifies one or more network slices among the pre-configured network slices in the PLMN. NG-RAN 810 also supports resource management and policy enforcement between slices according to the SLA. A single NG-RAN node can support multiple slices, and NG-RAN 810 can also appropriately apply the appropriate RRM policies for the SLA to each supported slice. NG-RAN 810 can also support QoS differentiation within a slice.

[0220] NG-RAN 810 can also use UE auxiliary information to select the AMF 821 (if available) during initial attachment. NG-RAN 810 uses the auxiliary information to route the initial NAS to the AMF 821. If NG-RAN 810 cannot use the auxiliary information to select the AMF 821, or if UE 801 does not provide any such information, then NG-RAN 810 sends the NAS signaling to the default AMF 821, and this default AMF can be in the AMF 821 pool. For subsequent accesses, UE 801 provides the temporary ID assigned to UE 801 by 5GC 820 to enable NG-RAN 810 to route the NAS message to the appropriate AMF 821, as long as this temporary ID is valid. NG-RAN 810 knows and can reach the AMF 821 associated with the temporary ID. Otherwise, the method used for initial attachment is applied.

[0221] NG-RAN 810 supports resource isolation between slices. NG-RAN 810 resource isolation can be achieved by means of RRM policies and protection mechanisms, and these RRM policies and protection mechanisms should avoid a lack of shared resources if one slice breaks the service level agreement for another slice. In some specific implementations, the resources of NG-RAN 810 can be fully assigned to a certain slice. How NG-RAN 810 supports resource isolation depends on the specific implementation.

[0222] Some slices may be only partially available in the network. Awareness of the slices supported in its neighboring cells in the NG-RAN 810 may be beneficial for inter-frequency mobility in the connected mode. Within the registration area of the UE, the slice availability may not change. The NG-RAN 810 and 5GC 820 are responsible for handling service requests for slices that may or may not be available in a given area. Granting or denying access to a slice may depend on factors such as support for the slice, availability of resources, and support of the NG-RAN 810 for the requested service.

[0223] The UE 801 may be associated with multiple network slices simultaneously. In the case where the UE 801 is associated with multiple slices simultaneously, only one signaling connection is maintained, and for intra-frequency cell reselection, the UE 801 attempts to pre-empt the best cell. For inter-frequency cell reselection, dedicated priorities may be used to control the frequency pre-empted by the UE 801. The 5GC 820 will verify that the UE 801 has the right to access the network slice. Before receiving the initial context setup request message, based on the awareness of the specific slice that the UE 801 is requesting access to, the NG-RAN 810 may be allowed to apply some temporary / local policies. During the initial context setup, the slice that is requesting its resources is notified to the NG-RAN 810.

[0224] The NFV architecture and infrastructure can be used to virtualize one or more NFs onto physical resources that include a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, the NFV system can be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0225] Figure 12 is a block diagram showing components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of performing any one or more of the methods discussed herein. Specifically, Figure 12 shows a schematic diagram of a hardware resource 1200 that includes one or more processors (or processor cores) 1210, one or more memory / storage devices 1220, and one or more communication resources 1230, each of which may be communicatively coupled via a bus 1240. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1202 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resource 1200.

[0226] Processor 1210 may include, for example, processor 1212 and processor 1214. Processor 1210 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0227] Memory / storage device 1220 may include main memory, disk memory, or any suitable combination thereof. Memory / storage device 1220 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state storage devices, and the like.

[0228] Communication resources 1230 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 1204 or one or more databases 1206 via network 1208. For example, communication resources 1230 may include a wired communication component (e.g., for coupling via USB), a cellular communication component, an NFC component, (or low power) components, components, and other communication components.

[0229] Instructions 1250 may include software, programs, applications, applets, applications, or other executable code for causing at least any one of the processors 1210 to execute any one or more of the method sets discussed herein. Instructions 1250 may reside, in whole or in part, in at least one of processor 1210 (e.g., within the cache memory of the processor), memory / storage device 1220, or any suitable combination thereof. Additionally, any portion of instructions 1250 may be transferred from any combination of peripheral devices 1204 or databases 1206 to hardware resources 1200. Accordingly, the memory of processor 1210, memory / storage device 1220, peripheral devices 1204, and databases 1206 are examples of computer-readable and machine-readable media.

Claims

1. A method for communication in an IAB network including integrated access and backhaul IAB nodes, the method comprising: Determining a time-domain soft resource configuration for a distributed unit DU of the IAB node, wherein determining the soft resource configuration includes: Receiving a sleep entry GTS downlink control information DCI; In response to receiving the GTS DCI, pausing mobile terminal MT control channel CCH monitoring for a number of time slots indicated by the GTS DCI; and Indicating to the DU available soft resources for the MT GTS duration.

2. The method according to claim 1, wherein the time-domain soft resource configuration is a first time-domain soft resource configuration, and the method further comprises: Configuring the CCH allocation for the MT and the DU such that the DU CCH is allocated in a symbol after the resources allocated for the MT CCH.

3. The method according to claim 2 further comprises: Determining a second time-domain soft resource configuration for the DU, wherein determining the second time-domain soft resource configuration includes: Determining that the resources allocated for the MT CCH do not include the MT CCH; In response to the determination, determining that the MT does not use data resources corresponding to the resources allocated for the MT CCH; and Generating the second time-domain soft resource configuration to indicate second available soft resources for use by the DU, wherein the second available soft resources include the data resources not used by the MT.

4. The method according to claim 3, wherein the DU is configured to initiate a sub-link using the DU CCH, and the DU CCH is allocated in a DU CCH region indicated by the second time-domain soft resource configuration.

5. The method according to claim 2, further comprising: Scheduling a gap time between the end of the MT CCH and the start of the DU CCH, wherein the gap time is a time period for accommodating at least one of an MT CCH decoding delay or a DU data channel preparation time.

6. The method according to claim 1, wherein the pausing includes not scheduling transmissions in the parent link of the IAB node in time slots corresponding to the number of time slots indicated by the GTS DCI.

7. The method according to claim 1, wherein the time-domain soft resource configuration is a first time-domain soft resource configuration, and determining a second time-domain soft resource configuration includes: Determining one or more rate matching RM modes, the one or more RM modes including RM resource allocation for MT data transmission.

8. The method according to claim 7, further comprising: Receiving DCI scheduling MT data transmission, wherein the DCI is used to dynamically select one of the one or more RM modes for rate matching for the data transmission.

9. The method according to claim 8, further comprising: In response to receiving the DCI, determining corresponding second available soft resources for the DU, wherein the corresponding second available soft resources are resources rate-matched according to the selected RM mode.

10. A non-transitory computer-readable storage device in an integrated access and backhaul IAB network, the IAB network including IAB nodes, instructions being stored on the non-transitory computer-readable storage device, which when executed by a data processing device cause the data processing device to perform operations including the following: Determine a time-domain soft resource configuration for a distributed unit DU of the IAB node, wherein determining the soft resource configuration includes: Determine one or more rate matching RM modes, the one or more RM modes including RM resource allocation for mobile terminal MT data transmission; Receive downlink control information DCI scheduling MT data transmission, wherein the DCI is used to dynamically select one of the one or more RM modes for rate matching for the data transmission; and Indicate the time-domain soft resource configuration to the DU.

11. The non-transitory computer-readable storage device according to claim 10, wherein the control channel CCH allocation for the MT and the DU is configured such that the DU CCH is allocated in a symbol after the resources allocated for the MT CCH.

12. The non-transitory computer-readable storage device according to claim 11, wherein the time-domain soft resource configuration is a first time-domain soft resource configuration, and wherein determining a second time-domain soft resource configuration for the DU of the IAB node includes: Determine that the resources allocated for the MT CCH do not include the MT CCH; In response to the determination, determine that the MT does not use data resources corresponding to the resources allocated for the MT CCH; And Generate the second time-domain soft resource configuration to indicate available soft resources for use by the DU, wherein the available soft resources include the data resources not used by the MT.

13. The non-transitory computer-readable storage device according to claim 12, wherein upon receiving the second time-domain soft resource configuration, the DU is configured to initiate a sub-link using the DU CCH, the DU CCH being allocated in a DUCCH region indicated by the second time-domain soft resource configuration.

14. The non-transitory computer-readable storage device according to claim 11, wherein the operations further include: Schedule a gap time between the end of the MT CCH and the start of the DU CCH, wherein the gap time is a time period for accommodating at least one of MT CCH decoding delay or DU data channel preparation time.

15. The non-transitory computer-readable storage device according to claim 10, wherein the time-domain soft resource configuration is a first time-domain soft resource configuration, wherein determining a second time-domain soft resource configuration for the DU of the IAB node includes: Receive sleep GTS downlink control information DCI; In response to receiving the GTS DCI, pause MT control channel CCH monitoring for a number of time slots indicated by the GTS DCI; And Indicate available soft resources for the MT GTS duration to the DU.

16. The non-transitory computer-readable storage device according to claim 15, wherein the suspension includes not scheduling transmissions in the parent link of the IAB node in time slots corresponding to the number of time slots indicated by the GTSDCI.

17. A system for communication, comprising: one or more processors and one or more storage devices storing operable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including the following: determine a time-domain soft resource configuration for a distributed unit DU of an integrated access and backhaul IAB node, wherein determining the soft resource configuration includes: receiving a sleep GTS downlink control information DCI; in response to receiving the GTSDCI, suspending a mobile terminal MT control channel CCH monitoring for a number of time slots indicated by the GTSDCI; and indicating to the DU available soft resources for an MT GTS duration.

18. The system according to claim 17, wherein the time-domain soft resource configuration is a first time-domain soft resource configuration, and the operations further include: configuring a CCH allocation for the MT and the DU such that a DU CCH is allocated in a symbol after a resource allocated for an MT CCH.

19. The system according to claim 18, wherein the operation further comprises: determine a second time-domain soft resource configuration for the DU, wherein determining the second time-domain soft resource configuration includes: determining that the resource allocated for the MT CCH does not include the MT CCH; in response to the determination, determining that the MT does not use data resources corresponding to the resource allocated for the MT CCH; and generating the second time-domain soft resource configuration to indicate second available soft resources for use by the DU, wherein the second available soft resources include the data resources not used by the MT.

20. The system according to claim 19, wherein the DU is configured to initiate a sub-link using the DUCCH, and the DU CCH is allocated in a DU CCH area indicated by the second time-domain soft resource configuration.

Images