User Equipment Activity Alignment for Power Conservation - Patent application

Abstract

In one aspect, the method includes determining, by the UE, that an alignment of a subsequent use of the resource is adjusted based on a current use of the resource, generating, by the UE, data indicative of a plurality of activity alignment parameters to be adjusted to cause the adjusted alignment of the subsequent use of the resource, encoding, by the UE, the generated data for transmission to a base station, and transmitting, by the UE, the encoded data to the base station.

Description

[Background technology]

[0001] UE data transmission activity may occur periodically over multiple periods of active data transmission and inactivity. Conventional systems may have related transactions spaced over multiple periods of active transmission and inactivity. Summary of the Invention

[0002] This disclosure generally relates to UE-assisted activity alignment to achieve power savings by user equipment (UE). NR network traffic may include periodic transmission of data across the network. The periodic nature of this data transmission can result in periods of activity and inactivity by the UE, which can be a power drain. In addition, the emergence of technologies such as augmented reality (XR) technology promises XR traffic, which may include multiple parallel traffic flows with synchronized data content between them. For example, video and audio traffic may need to be synchronized, while at the same time, other data, such as pose, sensor, or scene data, may pertain to picture frames. All of this data is highly dynamic and sensitive to latency / delay. Therefore, an extension to support traffic synchronization between flows is desirable. Furthermore, traffic flows scheduled for transmission in transport blocks distributed far from each other may place high demands on battery consumption for the UE.

[0003] During the RAN Rel-18 workshop, multiple companies indicated the need for enhancements to provide better synchronization between flows for 5G NR data transmission activity, including activity arising from XR and other immersive media.

[0004] According to one innovative aspect of the present disclosure, a method for synchronizing data transmission activity by user equipment (UE) is disclosed. In one aspect, the method may include the actions of: determining, by the UE, based on current use of the resource, that alignment of subsequent use of the resource be adjusted; generating, by the UE, data indicating a plurality of activity alignment parameters to be adjusted to cause the adjusted alignment of the subsequent use of the resource; encoding, by the UE, the generated data for transmission to a base station; and transmitting, by the UE, the encoded data to the base station.

[0005] Other aspects include systems, apparatus, and computer programs for performing the actions of the aforementioned methods.

[0006] The innovative method may include other optional features. For example, in some implementations, the method may further include receiving, by the UE, data from the base station that configures the UE to adjust subsequent use of the resource, and adjusting, by the UE, the subsequent use of the resource based on a plurality of network parameters.

[0007] In some implementations, the plurality of activity alignment parameters may include first data indicating the data transmission activity to be synchronized and second data indicating one or more of a transmission direction, a group synchronization tolerance, an individual synchronization tolerance, a synchronization point, a request for a single transport block, or a request for mapping a set of network traffic onto n transport blocks.

[0008] In some implementations, the resources include or are associated with one or more Data Radio Bearers (DRBs), one or more Logical Channels (LCHs), one or more Component Carriers (CCs), one or more Logical Channel Groups (LCGs), one or more Quality of Service (QOS) flows, or one or more Configured Grants (CGs), or one or more SPSs.

[0009] In some implementations, determining, by the UE, that alignment of subsequent use of the resources is adjusted based on current use of the resources may include determining, by the UE, that a plurality of resources are each associated with a packet arrival time that meets a threshold arrival time. In such implementations, generating, by the UE, data indicating a plurality of activity alignment parameters to be adjusted to cause adjusted alignment of subsequent use of the resources may include generating data indicating to the base station to aggregate a plurality of resources within a single period of transmission activity using the same component carrier (CC).

[0010] In some implementations, the plurality of activity alignment parameters includes at least one of the parameters identified in claim 4.

[0011] In some implementations, determining, by the UE, that alignment of subsequent use of the resources is adjusted based on current use of the resources may include determining, by the UE, that multiple configured grants each relate to data requiring synchronous transmission. In such implementations, generating, by the UE, data indicating multiple activity alignment parameters to be adjusted to result in adjusted alignment of subsequent use of the resources may include generating data indicating to the base station that the UE is requesting aggregation of multiple resources within a single period of transmission activity by the UE using the same component carrier (CC).

[0012] In some implementations, the activity alignment parameters include at least (i) data identifying a number of configured permissions and (ii) data identifying a group synchronization tolerance.

[0013] In some implementations, determining, by the UE, that alignment of subsequent use of the resources is adjusted based on current use of the resources may include determining, by the UE, that a plurality of resources are each associated with a packet arrival time that meets a threshold arrival time. In such implementations, generating, by the UE, data indicating a plurality of activity alignment parameters to be adjusted to cause the adjusted alignment of subsequent use of the resources may include generating data indicating to the base station to aggregate a plurality of resources within a single period of transmission activity and to use a different component carrier (CC) for each of the plurality of radio resources.

[0014] In some implementations, the plurality of activity alignment parameters include at least (i) data identifying a plurality of configured permissions, (ii) data identifying each of the different CCs, and (iii) data identifying a group synchronization tolerance.

[0015] In some implementations, determining, by the UE, that alignment of subsequent use of the resources is adjusted based on current use of the resources may include determining, by the UE, that multiple resources are each associated with data requiring synchronous transmission. In such implementations, generating, by the UE, data indicating multiple activity alignment parameters to be adjusted to result in adjusted alignment of subsequent use of the resources may include generating data indicating to the base station that the UE is requesting aggregation of multiple resources within a single period of transmission activity by the UE, and using a different component carrier (CC) for each of the multiple resources.

[0016] In some implementations, the plurality of activity alignment parameters include at least (i) data identifying a plurality of configured permissions, (ii) data identifying each of the different LCHs, and (iii) data identifying a group synchronization tolerance.

[0017] In some implementations, determining, by the UE, that alignment of subsequent use of the resources is adjusted based on current use of the resources may include determining, by the UE, a plurality of resources requiring synchronous transmission. In such implementations, generating, by the UE, data indicating a plurality of activity alignment parameters to be adjusted to cause the adjusted alignment of subsequent use of the resources may include generating data indicating to the base station that the UE requests aggregation of a plurality of resources using a single transport block within a single period of transmission activity by the UE.

[0018] In some implementations, the activity alignment parameters include at least (i) data identifying the configured grants and (ii) data including a request to transport the configured grants in a single transport block.

[0019] In some implementations, determining by the UE that alignment of subsequent use of the resources is adjusted based on current use of the resources may include determining by the UE that the sets of resources have different periodicities. In such implementations, generating by the UE data indicating a plurality of activity alignment parameters to be adjusted to result in adjusted alignment of subsequent use of the resources may include generating data indicating to the base station that the UE is requesting to aggregate a first set of resources having a first periodicity within a first period of transmission activity and aggregate a second set of resources having a second periodicity within a second period of transmission activity.

[0020] In some implementations, determining by the UE that subsequent use or resource alignment is adjusted based on current radio resource use may include identifying, by the UE, a particular radio resource of the plurality of resources as a synchronization point, and determining, by the UE, that remaining resources of the plurality of resources have a synchronization delay tolerance that is less than a threshold synchronization delay tolerance for the particular resource. In such implementations, generating by the UE data indicative of a plurality of activity alignment parameters to be adjusted to cause the adjusted alignment of subsequent use of the radio resources may include generating data that indicates to the base station that the UE requests to delay exercising the remaining resources using a single carrier until a period of transmission activity in which the particular radio resource is exercised.

[0021] In some implementations, the plurality of activity alignment parameters include at least (i) data identifying a plurality of UL grants or DL ​​assignments and (ii) data identifying an individual delay tolerance for each of the plurality of UL grants or DL ​​assignments. In some implementations, determining by the UE to adjust alignment of subsequent radio resource usage based on current radio resource usage may include identifying by the UE a particular radio resource of the plurality of resources as a synchronization point and determining by the UE that remaining resources of the plurality of resources have synchronization delay tolerances that are less than a threshold synchronization delay tolerance for the particular radio resource. In such implementations, generating by the UE data indicative of the plurality of activity alignment parameters to be adjusted to cause adjusted alignment of subsequent usage of the resources may include generating data indicating to the base station that the UE requests to delay exercising the remaining resources using multiple component carriers (CCs) until the period of transmission in which the particular radio resource is exercised.

[0022] In some implementations, the activity alignment parameters include at least (i) data identifying a plurality of UL grants or DL ​​assignments, (ii) data identifying each of a plurality of component carriers (CCs), and (iii) data identifying an individual delay tolerance for each of the plurality of UL grants or DL ​​assignments.

[0023] In some implementations, determining by the UE that alignment of subsequent use of the resources is adjusted based on the current radio usage may include identifying, by the UE, a particular radio resource of the plurality of resources as a synchronization point, and determining, by the UE, that remaining resources of the plurality of resources have a synchronization delay tolerance that is less than a threshold synchronization delay tolerance of the particular radio resource. In such implementations, generating by the UE data indicative of a plurality of activity alignment parameters to be adjusted to cause the adjusted alignment of subsequent use of the resources may include generating data indicating to the base station that the UE requests to delay exercising the remaining resources using a single transport block on a single component carrier until the period of transmission in which the particular radio resource is exercised.

[0024] In some implementations, the plurality of network parameters includes at least (i) data identifying a plurality of configured grants or SPSs, (ii) data identifying an individual delay tolerance for each of the plurality of configured grants / SPSs, and (iii) data identifying a request to transport the plurality of configured grants / SPSs in a single transport block.

[0025] The present disclosure provides several advantages over conventional systems. First, the present disclosure reduces power consumption by a UE because related network resources can be aggregated and communicated by the UE within a reduced number of active transmission periods. The present disclosure achieves this by utilizing the term locality for more efficient scheduling of network resources. Second, the present disclosure enables better synchronization between related traffic flows on lower network layers, which do not recognize the relationship between different traffic flows and do not have time-stamped data available. Third, the alignment of data transmission activity according to the present disclosure can reduce memory demands at the UE because data does not need to be buffered across multiple active transmission periods. However, the alignment of data transmission activity described herein can also reduce network buffer demands because the network may be less reliant on buffering packets across multiple periods of UE transmission activity.

[0026] These and other advantages are apparent from the description, drawings, and claims of this disclosure. [Brief explanation of the drawings]

[0027] [Figure 1] FIG. 1 is an example flow diagram illustrating communication between a gNB and a user equipment (UE) to facilitate UE-assisted activity alignment.

[0028] [Figure 2] 1 is a flowchart of a method for UE-assisted activity alignment.

[0029] [Figure 3] 1 is a comparative diagram between an example of unaligned data transmission activity and an example of the same transaction aligned on the same component carrier, according to the present disclosure.

[0030] [Figure 4] 1 is a comparative diagram between an example of unaligned data transmission activity and an example of the same transaction aligned on different component carriers, according to the present disclosure.

[0031] [Figure 5] 1 illustrates a comparison between an example of an unaligned network transaction and an example of the same transaction aligned on the same component carrier using delayed transmission, according to the present disclosure.

[0032] [Figure 6] 1 illustrates an example of a wireless communication system.

[0033] [Figure 7] 1 illustrates an exemplary architecture of the system.

[0034] [Figure 8] 1 shows the architecture of a system including a second CN.

[0035] [Figure 9] 1 illustrates an example of infrastructure equipment in accordance with various embodiments.

[0036] [Figure 10] FIG. 1 illustrates an example of a platform.

[0037] [Figure 11] 1 illustrates exemplary components of a baseband circuit and a radio front-end module (RFEM).

[0038] [Figure 12] 1 illustrates various protocol functions that may be implemented in wireless communications.

[0039] [Figure 13]1 shows the components of a core network.

[0040] [Figure 14] FIG. 1 is a block diagram illustrating components of a system that supports NFV.

[0041] [Figure 15] FIG. 1 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods described herein, according to some example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0042] The present disclosure generally relates to methods, systems, and apparatus for UE-assisted activity alignment to achieve power savings by a user equipment (UE). The present disclosure achieves these power savings by providing activity alignment parameters to a network (e.g., a gNB) in a request to align a particular data transmission activity. The periodic nature of this data transmission can result in periods of activity and inactivity by the UE, which can be a power drain. By employing one or more of a plurality of network resource alignment, network resource aggregation, or network resource delay strategies, the present disclosure can reduce the number of active transmission periods required for a UE to communicate over a network.

[0043] 1 is an example flow diagram 100 illustrating communications between a gNB 102 and a user equipment (UE) 104 to facilitate UE-assisted activity alignment. Flow diagram 100 describes a process that enables a UE to report traffic flow synchronization requirements to a gNB 102, which can then update the resource allocation of the UE 104 accordingly. In some implementations, this procedure may be combined with other methods for UE scheduling assistance information reporting or UE assistance information reporting, if applicable.

[0044] Flow 100 can begin with a gNB configuring a UE to provide 110 initial synchronization assistance information for traffic flow synchronization. The initial synchronization assistance information can be provided via different options on a selected protocol layer. Protocol layers used to convey UE synchronization assistance information can include radio resource control (RRC) signaling, service data application protocol (SDAP), or medium access control (MAC) elements. This process can be used to configure parameters separately for the uplink (UL) and downlink (DL). This step can be optional, or a fixed reporting method can be specified. In some implementations, the gNB can configure parameters, including a reporting frequency, an inhibit timer that prevents the UE from sending frequent synchronization assistance messages for a predetermined amount of time, or other parameters.

[0045] The UE 104 detects or identifies 110 the provided traffic flow synchronization requirements. The synchronization requirements may be based on application layer configuration or based on lower layer requirements. In some implementations, the UE 104 may take into account the current radio resource allocation (e.g., the CG / SPS configuration allocated to the UE 104).

[0046] The UE 104 can report synchronization assistance information to the network to request resource adjustment, alignment, or realignment, report the UE's preference for radio resource adjustment, alignment, or realignment, etc. The synchronization assistance information can be mapped to different Radio Access Network (RAN) layers. As examples, the synchronization assistance information can be provided using RRCUEAssistanceInformation (with an extended parameter set), a new MAC CE, or new parameters in an existing MAC CE (with an extended parameter set), a new SDAP control PDU, or new parameters in an existing SDAP control PDU (with an extended parameter set).

[0047] The synchronization assistance information generated by the UE 104 for inclusion in the synchronization assistance information may include at least two activity alignment parameters. The activity alignment parameters may include data identifying multiple resources for which the UE 104 is requesting adjustment, alignment, or realignment. The data identifying the multiple resources may include, for example, a list of resources, a bitmap of resources, etc. For purposes of this disclosure, resources may include, for example, one or more data radio bearers to be synchronized, one or more component carriers, one or more logical channels (LCHs), one or more logical channel groups (LCGs), one or more QoS flows, one or more configured grants, one or more semi-persistent (SPS) scheduling grants, etc. Additionally, the activity alignment parameters may also include a transmission direction, including uplink, downlink, or both, and one or more of the following: Group synchronization preference or common synchronization delay (or jitter) tolerance: the preferred maximum time interval for scheduling all flows in the group (e.g., for the set defined by the list or bitmap above), or ■ Individual synchronization delay (or jitter) tolerance for a particular traffic flow, i.e. per QFI / per LCH / per LCG / per CG, or ■ The priority of the synchronization point (or aggregation point / reference flow, e.g., an indication of which CG to use for CG aggregation or at what time a synchronization point is preferred), or ■ A request to map all flows to a single transport block, or ■ A request to map all flows onto multiple (n) multiplexed transport blocks. A UE configured to comply with the synchronization requirements should be configured with the capability to include single or multiple sets of lists or bitmaps.

[0048] As indicated above, in some implementations, the synchronization tolerance parameter may also be expressed as synchronization jitter (i.e., precision). The difference between synchronization delay and synchronization jitter / precision is that delay is only unidirectional relative to synchronization tolerance, while synchronization jitter can be a delay that is either too early or too late. Note that these parameters do not relate to simple packet arrival times. Instead, jitter can indicate the tolerable dispersion in the time domain for an otherwise fixed resource allocation, such as CG / SPS. Therefore, the tolerance parameter may be expressed as synchronization jitter / precision, even though it may be a preference value rather than a strict requirement.

[0049] The gNB 102 may receive synchronization assistance information provided 120 by the UE 104. The gNB 102 may determine whether to adjust, align, or realign resources based on the received synchronization assistance information provided 120 by the UE 104. The gNB 102 may provide 130 resource allocation alignment information to the UE that either (i) causes resource adjustment, alignment, or realignment according to the UE 104's provided 120 synchronization assistance information, or (ii) rejects or ignores the UE's request to adjust, align, or realign resources based on the UE's 104 request. The provided 130 resource allocation alignment information may be provided by the gNB 102, for example, using a grant or SPS signaling configured in proximity to the UE's 104 resource alignment request to see the synchronization assistance information. In some implementations, the provided (130) resource allocation alignment information may include data corresponding to values ​​of one or more of the activity alignment parameters described above and in step 220 of method 200 below.

[0050] This process may continue with the UE 104 monitoring radio resource usage and determining whether to request a subsequent synchronization requirement adjustment, alignment, or realignment. If a subsequent radio resource synchronization requirement change occurs, the UE 104 may submit another request to the gNB for updated synchronization assistance information 140 and receive a response from the gNB that either (i) causes resource adjustment, alignment, or realignment according to the UE's provided (120) synchronization assistance information or (ii) rejects the UE's request to adjust, align, or realign resources based on the UE's 104 request (150). The request for updated resources may generally be the same as the synchronization assistance information 120 and resource realignment 130, but represents constant monitoring of radio resource usage by the UE 104.

[0051] 2 is a flowchart of a method 200 for UE-assisted activity alignment. In one aspect, method 200 may involve a UE determining 210 that alignment of subsequent use of resources is to be adjusted based on current use of the resources. In some implementations, the UE may make the determination by analyzing the current resource use. For example, the UE may determine that subsequent use of resources is to be adjusted based on detecting that the resources have similar or shared activity alignment parameters that are spread among multiple different periods of active transmission by the UE.

[0052] The UE may continue execution of method 200 by generating 220 data indicating activity alignment parameters to be adjusted to cause coordinated alignment of subsequent use of resources. The data generated at 220 may include a request from the UE for resource adjustment, alignment, or realignment. The activity alignment parameters may include data identifying resources for which the UE 104 is requesting adjustment, alignment, or realignment. The data identifying resources may include, for example, a list of resources, a bitmap of resources, etc. For purposes of this disclosure, resources may include, for example, one or more data radio bearers to be synchronized, one or more component carriers, one or more logical channels, one or more QoS flows, one or more configured grants, one or more semi-persistent (SPS) scheduling grants, etc. Additionally, the activity alignment parameters may also include a transmission direction, including uplink, downlink, or both, and one or more of the following: Group synchronization priority or common synchronization delay (or jitter) tolerance: the preferred maximum time interval for scheduling all flows in the group (e.g., for the set defined by the list or bitmap above), or ■ Individual synchronization delay (or jitter) tolerance for a particular traffic flow, i.e. per QFI / per LCH / per LCG / per CG, or ■ The priority of the synchronization point (or aggregation point / reference flow, e.g., an indication of which CG to use for CG aggregation or at what time a synchronization point is preferred), or ■ A request to map all flows to a single transport block, or ■ A request to map all flows onto multiple (n) multiplexed transport blocks.

[0053] The UE may continue performing method 200 by encoding the generated data for transmission to the base station (230). The UE may complete the process by transmitting the encoded data to the base station (240).

[0054] In some implementations, method 200 may optionally include additional processes. For example, in some implementations, the UE may continue execution of process 200 by receiving data from a base station that configures the UE to adjust subsequent use of resources. In such implementations, the UE may process the data from the base station and configure itself to adjust subsequent use of resources based on the received data from the base station. The UE may continue the process by adjusting subsequent use of resources based on multiple network parameters. For purposes of this disclosure, resources should be understood to include at least one or more data radio bearers (DRBs), one or more logical channels (LCHs), one or more component carriers (CCs), one or more logical channel groups (LCGs), one or more quality of service (QOS) flows, or one or more configured grants (CGs), one or more SPSs, one or more application requirements of one or more applications, or any combination thereof.

[0055] The foregoing process generally describes a UE detecting that its resource usage should be adjusted, aligned, or realigned and then requesting such adjustment, alignment, or realignment of resources from the gNB. However, the present disclosure need not be so limited. Instead, other implementations of the present disclosure enable a network (e.g., a gNB) to detect the need to adjust, align, or realign resources and then generate resource allocation alignment data for transmitting to the UE that adjustment, alignment, or realignment of the UE's subsequent resource usage. For example, a gNB may be configured to allocate radio resource patterns for multiple QoS flows based on service-related information known to the network, such as QoS characteristics specific to particular 5QI / QoS flows. In such implementations, the network can then simply adjust, arrange, or re-arrange resources accordingly, i.e., in reasonable proximity (temporal locality). This option further assumes that the network has some level of traffic pattern awareness, including awareness of timing and / or associative relationships between traffic flows.

[0056] Aspects of the present disclosure may also be used to implement delayed MAC PDU transmission. In some implementations, synchronous transmission of traffic flows with multiple CG / SPS may be achieved by the option of delaying / ignoring a grant until a "synchronization point" or "aggregation point," e.g., delaying transmission until a defined moment when the network provides another grant (known in advance). For example, a device such as a UE or gNB may be enabled to use either the original CG / SPS resources or an additional grant / allocation at the "synchronization point." The additional grant / allocation is known in advance and typically occurs before the next periodic instance of the CG / SPS, i.e., in the middle of the periodicity.

[0057] In addition to using the synchronization delay / jitter tolerance as an activity alignment parameter, the gNB can configure the UE with a maximum "leap tolerance" for a group of resources or a single radio resource. The network may also enable / disable this mode using a parameter, and / or a UE capability may be defined. This allows the gNB to introduce new types of radio resources that can be delayed by a configurable amount of time. For example, by generating and transmitting a modified configuredGrantConfigIE and / or SPS-ConfigIE that includes a new parameter to describe the maximum allowable variation in the execution of the radio resource. However, this does not limit the present disclosure to delaying a radio resource to the next radio resource in the radio resource configuration or the next radio resource associated with an LCH. Instead, a radio resource can be delayed to any next radio resource mapped to the same LCH.

[0058] In the case of a delayed transmission opportunity where the UE has data available, the delay can be implemented as Tx skipping, i.e., the MAC can be modified to allow UL skipping even when the UE has data available for transmission (where the MAC entity is enabled to skip the UL transmission and / or not generate a MAC PDU). Other mechanisms for delaying transactions can also be used.

[0059] Thus, in some implementations, a UE or gNB can define a time-based concept of "aggregation" or "synchronization point" by employing a usage radio resource configuration information element and specifying the time at which data must be transmitted. In some implementations, this can be achieved using a new type of resource having parameters that allow a radio resource to be delayed by a configurable amount of time. In some implementations, resource delay can also be achieved by configuring a "synchronization point" that allows a radio resource to be delayed until a specific time. This can be achieved by the UE or gNB setting an activity alignment parameter for the resource to include the specific time at which it should be performed. In some implementations, a UE can be enabled to delay a MAC PDU based on the implicit requirements of a service (service-induced), based on its reported synchronization tolerance value, or according to service-related information known to the network, such as QoS characteristics specific to a particular 5QI / QoS flow.

[0060] In some implementations, the gNB may also enable PDB headroom-based delayed transmission as an optional feature. Such implementations assume that the UE has data available for transmission in a logical channel and that the delay budget is still large enough (below a threshold or below a synchronization tolerance). If the UE still has a CG that appears in the near future enough to meet the latency target associated with the service, the UE may skip the current CG and delay the transmission of UL data for up to a maximum time. Note that the next CG does not necessarily have to be from the same CG configuration. This feature becomes even more relevant for multiple CGs linked with an LCH (or even multiple LCHs).

[0061] FIG. 3 is a comparative diagram 300 between an example of an unaligned network transaction 310 and an example of the same transaction 320 aligned on the same component carrier, in accordance with the present disclosure.

[0062] In the example of FIG. 3, the UE can analyze current radio resource usage, such as those described in a set of network transactions 310 distributed across multiple active transmission periods 312, 314, 316, and determine that these transactions can be aligned within the same active transmission period 322. The UE can trigger a request for realignment based on detecting, for a set of resources, such as a configured grant, that the set of resources are (i) respectively associated with packet arrival times that meet a threshold arrival time or (ii) respectively associated with data requiring synchronous transmission. Based on detecting the occurrence of one of these triggers, the UE can generate synchronization assistance information including one or more activity alignment parameters to request that the gNB adjust, align, or realign network resources to satisfy the activity alignment parameter in the generated synchronization assistance information, such that each of the resources (e.g., CG1, GG2, CG3, CG4) is implemented on the same component carrier in a single period of transmission activity. In this example, the generated synchronization assistance information may include at least (i) data identifying the configured grants CG1, CG2, CG3, and CG4, and (ii) data identifying a group synchronization tolerance for the configured grants CG1, CG2, CG3, and CG4. The UE may transmit the generated synchronization assistance information to the gNB as a request to adjust resources CG1, CG2, CG3, and CG4 to run within the same active transmission period, as shown at 320 in FIG.

[0063] The example of Figure 3 provides an example where a UE generating synchronization assistance information that can request resource realignment may be performed within a single period of transmission activity. However, the present disclosure is not so limited. Instead, in some implementations, the generated synchronization assistance information may also include parameters requesting that a set of resources be exercised within a single transport block. This may be achieved using a single transport block parameter in the generated synchronization assistance information.

[0064] In yet other implementations, this may be achieved by the UE determining that the sets of resources have different periodicities. For example, a first set of resources has a first periodicity that requires the first set of resources to be exercised during a first period of transmission activity, and a second set of resources has a second periodicity that requires the second set of resources to be exercised during a second period of transmission activity. In such implementations, the UE may generate synchronization assistance information that requests aggregating the first set of resources with the first periodicity within the first period of transmission activity and aggregating the second set of resources with the second periodicity within the second period of transmission activity. In some implementations, this may be achieved using its synchronization delay / jitter tolerance requirements to help the network find a better middle ground for activity alignment. However, if the periodicities of the involved CGs are significantly different, the UE may still want to request alignment of a preferred subset of CGs and indicate this to the network. Such an indication may be made in a list or bitmap provided in the synchronization assistance information. Alternatively, this issue of different periodicities can also be addressed by signaling multiple smaller groups of CGs, for example, placing CG1 and CG2 in one group and CG3 and CG4 in another group. In yet another alternative, the UE can signal the entire group of CGs 1-4 while requesting that the allocation be split into two "merged CGs".

[0065] 4 illustrates a comparison diagram between an example of an unaligned network transaction and an example of the same transaction aligned on different component carriers according to the present disclosure. The UE can trigger a request for realignment based on detecting, for a set of resources, such as a configured grant, that the set of resources are (i) respectively associated with packet arrival times that meet a threshold arrival time or (ii) respectively associated with data requiring synchronous transmission. Based on detecting the occurrence of one of these triggers, the UE can generate synchronization assistance information including one or more activity alignment parameters to request that the gNB adjust, align, or realign network resources to satisfy the activity alignment parameters in the generated synchronization assistance information, such that each of the resources (e.g., CG1, GG2, CG3, CG4) is implemented by the UE in a single period of transmission activity and uses a different component carrier. Thus, the UE can generate synchronization assistance information that coordinates resources to exercise resources in parallel across multiple component carriers and within a single period of transmission activity. In this example, the generated synchronization assistance information may include at least (i) data identifying the plurality of configured grants CG1, CG2, CG3, CG4, (ii) data identifying each of the component carriers, and (iii) data identifying a group synchronization tolerance of the plurality of configured grants CG1, CG2, CG3, CG4.

[0066] FIG. 5 is a comparative diagram 500 between an example of an unaligned network transaction 510 and an example of the same transaction 520 aligned on the same component carrier using delayed transmission, in accordance with the present disclosure.

[0067] The previous examples of Figures 3 and 4 describe a UE detecting a need to adjust, align, or realign resources based on its current radio usage resources. However, the disclosure is not so limited. For example, with reference to Figure 5, a network (e.g., a gNB) generates resource allocation alignment information that may be transmitted to the UE to adjust, align, or realign the UE's radio resource usage. The resource allocation alignment information may include values ​​for one or more of the alignment activity parameters described herein.

[0068] In the example of FIG. 5, a network (e.g., a gNB) may identify a particular radio resource as a synchronization point. In this example, the network identifies configured grant 4 (CG4) as the synchronization point. The network may then determine that a set of resources, configured grants CG1, CG2, CG3, and CG4 in this example of FIG. 5, are each associated with a synchronization delay tolerance that is less than the threshold synchronization delay tolerance of the particular radio resource. Thus, the network may generate resource allocation alignment information having multiple activity alignment parameters configured to delay resources CG1, CG2, and CG3 such that resources CG1, CG2, and CG3 are not exercised until the same active transmission period as synchronization point radio resource CG4. In this scenario, the activity alignment parameters include at least (i) data identifying a plurality of resources (e.g., CG1, CG2, CG3, CG3), (ii) a radio resource (e.g., CG4) that is a synchronization point, and (iii) data identifying an individual delay tolerance for each of the configured grants CG1, CG2, CG3 that are delayed until the same active period of transmission as the synchronization point radio resource.

[0069] Thus, detecting the need to adjust, align, or realign resources and generating a request to adjust, align, or realign resources is not limited to the UE. Instead, the network (e.g., gNB) can also generate an information control element, such as a MAC PDU, that can perform such an operation and specify alignment activity parameters to configure the UE to adjust, align, or realign resources at the network's command.

[0070] FIG. 6 illustrates an example of a wireless communication system 600. For convenience, but not limitation, the exemplary system 100 is described in the context of Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards defined by the Third Generation Partnership Project (3GPP) technical specifications. More particularly, the wireless communication system 600 is described in the context of a non-standalone (NSA) network incorporating both LTE and NR, such as an Evolved Universal Terrestrial Radio Access (E-UTRA)-NR Dual Connectivity (EN-DC) network and an NE-DC network. However, the wireless communication system 600 may also be a standalone (SA) network incorporating only NR. Furthermore, other types of communication standards are possible, including future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc.

[0071] As shown by FIG. 6, system 600 includes UE 601a and UE 601b (collectively referred to as "UE 601" or "UE 601"). In this example, UE 601 is illustrated as a smartphone (e.g., a portable touchscreen mobile computing device capable of connecting to one or more cellular networks), but may include any mobile or non-mobile computing device, such as a consumer device, a mobile phone, a smartphone, a feature phone, a tablet computer, a wearable computing device, a personal digital assistant (PDA), a pager, a wireless handset, a desktop computer, a laptop computer, an in-vehicle infotainment (IVI), an in-vehicle entertainment (ICE) device, an instrument cluster (IC), a head-up display (HUD) device, an on-board diagnostics (OBD) device, a dash-top mobile equipment (DME), a mobile data terminal (MDT), an electronic engine management system (EEMS), an electronic / engine control unit (ECU), an electronic engine / engine control module (ECM), an embedded system, a microcontroller, a control module, an engine management system (EMS), a networked or "smart" appliance, an MTC device, an M2M, an IoT device, and / or the like.

[0072] In some embodiments, any of the UEs 601 may include an IoT UE, which may include a network access layer designed for low-power IoT applications utilizing short-term UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via PLMN, ProSe, or D2D communications, a sensor network, or an IoT network. M2M or MTC data exchanges may be machine-initiated data exchanges. An IoT network refers to IoT UEs connecting with each other, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) via short-lived connections. The IoT UE may run background applications (e.g., keep-alive messages, status updates, etc.) to facilitate IoT network connectivity.

[0073] The UE 601 may be configured to connect, e.g., be communicatively coupled, to the RAN 610. In an embodiment, the RAN 610 may be an NG RAN or a 5G RAN, an E-UTRAN, or a legacy RAN such as a UTRAN or a GERAN. As used herein, the term "NG RAN" or the like may refer to a RAN 610 operating in an NR or 5G system 600, and the term "E-UTRAN" or the like may refer to a RAN 610 operating in an LTE or 4G system 600. The UE 601 utilizes connection (or channel) 603 and connection 604, respectively, which each include a physical communication interface or layer (discussed in more detail below).

[0074] In this example, connections 603 and 604 are shown as air interfaces for enabling communication coupling and may correspond to a cellular communication protocol such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, an Advanced Long Term Evolution (LTE-A) protocol, an LTE-based access to unlicensed spectrum (LTE-U), a 5G protocol, an NR protocol, an NR-based access to unlicensed spectrum (NR-U) protocol, and / or any of the other communication protocols described herein. In this embodiment, UE 601 can further directly exchange communication data via a ProSe interface 605. The ProSe interface 605 may alternatively be referred to as an SL interface 605 and may comprise one or more logical channels, including, but not limited to, a PSCCH, a PSSCH, a PSDCH, and a PSBCH.

[0075] UE 601b is shown configured to access AP 606 (also referred to as "WLAN node 606," "WLAN 606," "WLAN terminal 606," "WT 606," etc.) via connection 607. Connection 607 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, and AP 606 may comprise a Wireless Fidelity (WiFi) router. In this example, AP 606 is connected to the Internet without connecting to a wireless system core network, as shown (described in further detail below). In various embodiments, UE 601b, RAN 610, and AP 606 may be configured to utilize LWA operation and / or LWIP operation. LWA operation may involve UE 601b, in RRC_CONNECTED, being configured by RAN nodes 611a-b to utilize LTE and WLAN resources. LWIP operations may involve UE 601b using WLAN resources (e.g., connection 607) via IPsec protocol tunneling to authenticate and encrypt packets sent over connection 607. IPsec tunneling may involve encapsulating the entire original IP packet and adding a new packet header, thereby protecting the IP packet's original header.

[0076] The RAN 610 may include one or more AN or RAN nodes 611a and 611b (collectively referred to as "RAN node 611" or "RAN node 611") that enable connections 603 and 604. As used herein, the terms "access node," "access point," etc. may refer to equipment that provides wireless baseband functionality for data and / or voice connectivity between a network and one or more users. These access nodes may be referred to as BSs, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs, TRPs, etc., and may include earth stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, terms such as "NG RAN node" may refer to a RAN node 611 operating in an NR or 5G system 600 (e.g., a gNB), and terms such as "E-UTRAN node" may refer to a RAN node 611 operating in an LTE or 4G system 600 (e.g., an eNB). According to various embodiments, the RAN node 611 may be implemented as one or more of a macrocell base station and / or a dedicated physical device such as a femtocell, picocell, or other similar cell having a smaller coverage area, lower user capacity, or higher bandwidth compared to a macrocell.

[0077] In some embodiments, all or part of the RAN node 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 CRAN and / or virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN function splitting such as PDCP splitting, where the RRC and PDCP layers are operated by the CRAN / vBBUP and other L2 protocol entities are operated by individual RAN nodes 611; MAC / PHY splitting, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP and the PHY layer is operated by individual RAN nodes 611; or "lower PHY" splitting, where the RRC, PDCP, RLC, MAC, and upper parts of the PHY layer are operated by the CRAN / vBBUP and lower parts of the PHY layer are operated by individual RAN nodes 611. This virtualized framework allows freed-up processor cores of the RAN node 611 to run other virtualized applications. In some implementations, individual RAN nodes 611 may represent individual gNB-DUs connected to a gNB-CU via individual F1 interfaces (not shown per FIG. 6). In these implementations, the gNB-DUs may include one or more remote radio heads or RFEMs (e.g., see FIG. 9), and the gNB-CUs may be operated by a server or by a server pool located within the RAN 610 (not shown), in a manner similar to a CRAN / vBBUP. Additionally or alternatively, one or more of the RAN nodes 611 may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations toward the UE 601 and are connected to a 5GC (e.g., the CN 820 in FIG. 8) via an NG interface (described below).

[0078] In a V2X scenario, one or more of the RAN nodes 611 may be or act as an RSU. The term “Road Side Unit” or “RSU” may refer to any transportation infrastructure entity used for V2X communications. The RSU may be implemented in or by an appropriate RAN node or a stationary (or relatively stationary) UE; an RSU implemented in or by a UE may be referred to as a “UE-type RSU,” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU,” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU,” etc. In one example, an RSU is a computing device coupled to radio frequency circuits located on the roadside that provides connectivity support to a passing vehicle UE 601 (vUE 601). The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for detecting and controlling ongoing vehicular and pedestrian traffic. The RSU may operate in the 5.9 GHz Direct Short Range Communication (DSRC) band to provide very low-latency communications necessary for high-speed events such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may operate in the cellular V2X band to provide the aforementioned low-latency communications as well as other cellular communication services. Additionally or alternatively, the RSU may 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 communications. Some or all of the computing device(s) and the radio frequency circuitry of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller for providing a wired connection (e.g., Ethernet) to a traffic signal controller and / or a backhaul network.

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

[0080] According to some embodiments, the UEs 601 may be configured to communicate with each other or with any of the RAN nodes 611 using OFDM communication signals over multi-carrier communication channels according to various communication technologies, such as, but not limited to, OFDMA communication technologies (e.g., for downlink communication) or SC-FDMA communication technologies (e.g., for uplink and ProSe or sidelink communication), and the scope of the embodiments is not limited in this respect. OFDM signals may include multiple orthogonal subcarriers.

[0081] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 611 to the UE 601, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, also called a resource grid or time-frequency resource grid, which represents the downlink physical resources within each slot. Such a time-frequency plane representation is common in OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit of the resource grid is denoted as a resource element. Each resource grid contains a number of resource blocks, which represent the mapping of a particular physical channel to resource elements. Each resource block contains a set of resource elements, which, in the frequency domain, can represent the smallest amount of resources that can currently be allocated. There are several different physical downlink channels conveyed using such resource blocks.

[0082] According to various embodiments, the UE 601 and the RAN node 611 communicate (e.g., transmit and receive) data over a licensed medium (also referred to as a "licensed spectrum" and / or a "licensed band") and an unlicensed shared medium (also referred to as an "unlicensed spectrum" and / or an "unlicensed band"). The licensed spectrum may include channels operating in a frequency range from about 400 MHz to about 3.8 GHz, and the unlicensed spectrum may include the 5 GHz band. NR in the unlicensed spectrum may be referred to as NR-U, and LTE in the unlicensed spectrum may be referred to as LTE-U, Licensed Assisted Access (LAA), or MultiFire.

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

[0084] LBT is a mechanism by which a device (e.g., UE 601, RAN node 611, etc.) senses the medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed idle (or a particular channel in the medium is sensed unoccupied). The medium sensing operation may include CCA, which utilizes at least ED to determine the presence or absence of other signals on the channel to determine whether the channel is occupied or free. This LBT mechanism enables cellular / LAA networks to coexist with current occupied systems and with other LAA networks in unlicensed spectrum. ED may include detecting RF energy over the intended transmission band for a period of time and comparing the detected RF energy to a predetermined or configured threshold.

[0085] Typically, the currently occupying system in the 5 GHz band is a WLAN based on IEEE 802.11 technology. WLAN employs a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as UE 601 or AP 606) intends to transmit, the WLAN node may first perform CCA before transmitting. Furthermore, a backoff mechanism is used to avoid collisions in situations where two or more WLAN nodes simultaneously sense the channel as idle and transmit. The backoff mechanism may be a randomly sampled counter within the CWS, which is exponentially incremented upon collision occurrence and reset to its minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA for WLAN. In some implementations, the LBT procedure for a DL or UL transmission burst containing a PDSCH or PUSCH transmission, respectively, can have an LAA contention window with a variable length between X and Y ECCA slots, where X and Y are the minimum and maximum values ​​of the CWS for LAA. In one example, the minimum CWS for an LAA transmission may be 9 microseconds (s). The size of the CWS and MCOT (e.g., transmission burst) may be based on government regulatory requirements.

[0086] The LAA mechanism is based on the CA technology of the LTE-Advanced system. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, resulting in a maximum aggregated bandwidth of 100 MHz. In FDD systems, the number of aggregated carriers can differ between DL and UL, and the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, individual CCs can have a different bandwidth from other CCs. In TDD systems, the number of CCs and the bandwidth of each CC are typically the same for DL ​​and UL.

[0087] CA also includes individual serving cells providing individual CCs. For example, CCs in different frequency bands may experience different path losses, so the coverage of the serving cells may differ. The primary serving cell, or PCell, may provide a PCC for both UL and DL and handle RRC and NAS-related activities. Other serving cells are called SCells, and each SCell may provide a separate SCC for both UL and DL. SCCs may be added and removed as needed, but changing the PCC may require the UE 601 to undergo handover. In LAA, eLAA, and feLAA, some or all of the SCells may operate in unlicensed bands (called "LAA SCells"), and the LAA SCells are backed by a PCell operating in licensed bands. When a UE is configured with two or more LAA SCells, the UE may receive UL grants on the configured LAA SCells indicating different PUSCH starting positions within the same subframe.

[0088] The PDSCH carries user data and higher layer signaling to the UEs 601. The PDCCH carries, among other things, information about the transport format and resource allocation associated with the PDSCH channel. It may also inform the UEs 601 about the transmission format, resource allocation, and HARQ information for the uplink shared channel. Typically, downlink scheduling (allocation of control and shared channel resource blocks to UEs 601b in a cell) may be performed by any of the RAN nodes 611 based on channel quality information fed back from any of the UEs 601. The downlink resource allocation information may be transmitted on the PDCCH used (e.g., assigned) for each of the UEs 601.

[0089] The PDCCH conveys control information using CCEs. Before being mapped to resource elements, PDCCH complex-valued symbols may first be organized into quadruplets and then shuffled using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, and each CCE may correspond to nine sets of four physical resource elements known as REGs. Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of the DCI and the channel conditions. There may 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).

[0090] Some embodiments may use a concept for resource allocation for control channel information that is an extension of the concept described above. For example, some embodiments may utilize an EPDCCH that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more ECCEs. As above, each ECCE may correspond to nine sets of four physical resource elements known as EREGs. An ECCE may have other numbers of EREGs in some situations.

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

[0092] In embodiments where the system 600 is a 5G or NR system (e.g., when the CN 620 is a 5G or NR system, as in FIG. 8 ), the interface 612 may be an Xn interface 612. The Xn interface is defined between two or more RAN nodes 611 (e.g., two or more gNBs) that connect to the 5GC 620, between a RAN node 611 (e.g., a gNB) and an eNB that connect to the 5GC 620, and / or between two eNBs that connect to the 5GC 620. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support / provide data transfer and flow control functions. The Xn-C may provide mobility support for the UE 601 in connected mode (e.g., CM-CONNECTED), including management and error handling functions, functions for managing the Xn-C interface, and functions for managing UE mobility for connected mode between one or more RAN nodes 611. Mobility support may include context transfer from the old (source) serving RAN node 611 to the new (target) serving RAN node 611 and control of user plane tunnels between the old (source) serving RAN node 611 and the new (target) serving RAN node 611. To carry user plane PDUs, the Xn-U protocol stack may include a transport network layer built on an Internet Protocol (IP) transport layer and a GTP-U layer on top of a UDP and / or IP layer(s). The Xn-C protocol stack may include an application layer signaling protocol (called the Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may sit on top of the IP layer and provide guaranteed delivery of application layer messages. At the transport IP layer, point-to-point transmission is used to deliver signaling PDUs.In other 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 stack(s) shown and described herein.

[0093] The RAN 610 is shown communicatively coupled to a core network, which in this embodiment is a core network (CN) 620. The CN 620 may comprise multiple network elements 622 configured to provide various data and telecommunication services to customers / subscribers (e.g., users of UEs 601) connected to the CN 620 via the RAN 610. The components of the CN 620 may be implemented in a single physical node or separate physical nodes, including 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 utilized to virtualize any or all of the above-described network node functions via executable instructions stored on one or more computer-readable storage media (described in further detail below). A logical instantiation of the CN 620 may be referred to as a network slice, and a logical instantiation of a portion of the CN 620 may be referred to as a network sub-slice. The NFV architecture and infrastructure may be used to virtualize one or more network functions on physical resources including a combination of industry-standard server hardware, storage hardware, or switches, or may be performed by dedicated hardware. In other words, an NFV system can be used to run a virtual or reconfigurable implementation of one or more EPC components / functions.

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

[0095] In an embodiment, the CN 620 may be a 5GC (referred to, for example, as "5GC 620"), and the RAN 610 may be connected to the CN 620 via an NG interface 613. In an embodiment, the NG interface 613 may be divided into two parts: an NG User Plane (NG-U) interface 614 that carries traffic data between the RAN node 611 and the UPF, and an S1 Control Plane (NG-C) interface 615 that is a signaling interface between the RAN node 611 and the AMF. An embodiment in which the CN 620 is a 5GC 620 is described in more detail with respect to FIG. 8.

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

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

[0098] The MME 721 may be similar in function to the control plane of a legacy SGSN and may implement MM functions to track the current location of the UE 701. The MME 721 may perform various MM procedures to manage mobility aspects of access, such as gateway selection and tracking area list management. MM (also referred to as "EPS MM" or "EMM" in E-UTRAN systems) may refer to all applicable procedures, methods, data storage, etc. used to maintain knowledge of the UE 701's current location, provide user identity confidentiality, and / or perform other similar services to a user / subscriber. Each UE 701 and MME 721 may include an MM or EMM sublayer, and an MM context may be established in the UE 701 and MME 721 upon successful completion of the attach procedure. The MM context may be a data structure or database object that stores MM-related information for the UE 701. The MME 721 may be coupled to the HSS 724 via an S6a reference point, may be coupled to the SGSN 725 via an S3 reference point, and may be coupled to the S-GW 722 via an S11 reference point.

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

[0100] The HSS 724 may comprise a database of network users, which contains subscription-related information to support the network entities' handling of communication sessions. The EPC 720 may comprise one or more HSSs 724, depending on the number of mobile subscribers, equipment capacity, network organization, etc. For example, the HSS 724 may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc. An S6a reference point between the HSS 724 and the MME 721 may 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.

[0101] The S-GW 722 may terminate the S1 interface 613 ("S1-U" in FIG. 7) toward the RAN 710 and route data packets between the RAN 710 and the EPC 720. In addition, the S-GW 722 may be a local mobility anchor point for inter-RAN node handovers and may also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement. An S11 reference point between the S-GW 722 and the MME 721 may provide the control plane between the MME 721 and the S-GW 722. The S-GW 722 may be coupled to the P-GW 723 via an S5 reference point.

[0102] The P-GW 723 may terminate an SGi interface to the PDN 730. The P-GW 723 may 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, e.g., FIG. 6). In an embodiment, the P-GW 723 may be communicatively coupled to an application server (the application server 630 in FIG. 6 or the PDN 730 in FIG. 7) via the IP communication interface 625 (see, e.g., FIG. 6). The S5 reference point between the P-GW 723 and the S-GW 722 may provide user plane tunneling and tunnel management between the P-GW 723 and the S-GW 722. The S5 reference point may also be used for relocation of the S-GW 722 when, due to the mobility of the UE 701, the S-GW 722 needs to connect to a non-collocated P-GW 723 for required PDN connectivity. The P-GW 723 may further include a node for policy enforcement and charging data collection (e.g., a PCEF (not shown)). In addition, the SGi reference point between the P-GW 723 and a packet data network (PDN) 730 may be an operator-external public, private PDN, or intra-operator packet data network, for example, for providing IMS services. The P-GW 723 may be coupled to the PCRF 726 via a Gx reference point.

[0103] 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 UE 701's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with the UE 701's IP-CAN session: a Home PCRF (H-PCRF) in the HPLMN and a Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). The PCRF 726 may be communicatively coupled to the application server 730 via the P-GW 723. The application server 730 may signal the PCRF 726 to direct a new service flow and select QoS and charging parameters. The PCRF 726 can provision this rule to a PCEF (not shown) with the appropriate TFT and QCI, which initiates the QoS and charging specified by the application server 730. The Gx reference point between the PCRF 726 and the P-GW 723 may enable the transfer of QoS policies and charging rules from the PCRF 726 to the PCEF of the P-GW 723. The Rx reference point may exist between the PDN 730 (or "AF 730") and the PCRF 726.

[0104] 8 illustrates the architecture of a system 800 including a second CN 820, according to various embodiments. The system 800 is shown to include a UE 801, which may be the same as or similar to the UEs 601 and 701 previously described, an (R)AN 810, which may be the same as or similar to the RANs 610 and 710 previously described and may include the RAN nodes 611 previously described, a DN 803, which may be, for example, an operator 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, an NEF 823, a PCF 826, an NRF 825, a UDM 827, an AF 828, a UPF 802, and an NSSF 829.

[0105] The UPF 802 may function as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to the DN 803, and a branch point supporting multi-homed PDU sessions. The UPF 802 may also perform packet routing and forwarding, packet inspection, enforce the user plane portion of policy rules, lawfully intercept packets (UP collection), traffic usage reporting, user plane QoS processing (e.g., packet filtering, gating, UL / DL rate enforcement), uplink traffic validation (e.g., SDF-to-QoS flow mapping), transport-level packet marking in the uplink and downlink, downlink packet buffering, and downlink data notification triggering. The UPF 802 may include an uplink classifier to support routing traffic flows to the 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 application server 630 discussed above. The UPF 802 can interact with the SMF 824 via the N4 reference point between the SMF 824 and the UPF 802.

[0106] The AUSF 822 may store data for authentication of the UE 801 and process authentication-related functions. The AUSF 822 may facilitate a general authentication framework for various access types. The AUSF 822 may communicate with the AMF 821 via the N12 reference point between the AMF 821 and the AUSF 822 and with the UDM 827 via the N13 reference point between the UDM 827 and the AUSF 822. Additionally, the AUSF 822 may exhibit a Nausf service-based interface.

[0107] The AMF 821 may be involved in registration management (e.g., to register the UE 801), connection management, reachability management, mobility management, and lawful interception of AMF-related events, as well as access authentication and authorization. The AMF 821 may be the termination point of the N11 reference point between the AMF 821 and the SMF 824. The AMF 821 provides transport for SM messages between the UE 801 and the SMF 824 and can function as a transparent proxy for routing SM messages. The AMF 821 may also provide transport for SMS messages between the UE 801 and the SMSF (not shown in FIG. 8). The AMF 821 may function as a Security Assistance Facility (SEAF), which may include interaction between the AUSF 822 and the UE 801 and receiving intermediate keys established as a result of the UE 801's authentication process. If USIM-based authentication is used, the AMF 821 may obtain security material from the AUSF 822. The AMF 821 may also include an SCM function that receives keys from the SEA to use to derive access network-specific keys. Furthermore, the AMF821 may be the termination point of the RAN CP interface, which may include or be the N2 reference point between the (R)AN810 and the AMF821, and the AMF821 may be the termination point of the NAS (N1) signaling and may perform NAS encryption and integrity protection.

[0108] The AMF 821 may also support NAS signaling with the UE 801 via the N3 IWF interface. The N3 IWF may be used to provide access to untrusted entities. The N3 IWF may be the termination point of the N2 interface between the (R)AN 810 and the AMF 821 in the control plane, and may be the termination point of the N3 reference point between the (R)AN 810 and the UPF 802 in the user plane. Thus, the AMF 821 may process N2 signaling from the SMF 824 and the AMF 821 for PDU sessions and QoS, encapsulate / decapsulate packets for IPSec and N3 tunneling, mark N3 user plane packets in the uplink, and enforce QoS corresponding to N3 packet markings taking into account QoS requirements associated with such markings received via the N2. The N3IWF may also relay uplink and downlink control plane NAS signaling between the UE 801 and the AMF 821 and may relay uplink and downlink user plane packets between the UE 801 and the UPF 802 via the N1 reference point between the UE 801 and the AMF 821. The N3IWF also provides a mechanism for IPsec tunnel establishment with the UE 801. The AMF 821 may present a Namf service-based interface and may be the termination point for the N14 reference point between two AMFs 821 and the N17 reference point between the AMF 821 and the 5G-EIR (not shown in FIG. 8).

[0109] The UE 801 may need to register with the AMF 821 to receive network services. The RM is used to register or deregister the UE 801 with a network (e.g., the AMF 821) and establish a UE context within the network (e.g., the AMF 821). The UE 801 may operate in an RM-REGISTERED state or an RM-DEREGISTERED state. In the RM-DEREGISTERED state, the UE 801 is not registered with the network, and the UE context within the AMF 821 does not hold valid location or routing information for the UE 801; therefore, the UE 801 is not reachable by the AMF 821. In the RM-REGISTERED state, the UE 801 is registered with the network, and the UE context within the AMF 821 may hold valid location or routing information for the UE 801 such that the UE 801 is reachable by the AMF 821. In the RM-registered state, the UE 801 may, among other things, 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.

[0110] The AMF 821 may store one or more RM contexts for the UE 801, each RM context being associated with a particular access to the network. An RM context may be a data structure, database object, etc., that indicates or stores, among other things, registration state and periodic update timers per access type. The AMF 821 may also store an 5G CMM context, which may be the same as or similar to the (E)MM context described above. In various embodiments, the AMF 821 may store the CE Mode B restriction parameters of the UE 801 in the associated MM context or RM context. The AMF 821 may also derive values, as needed, from the UE's usage configuration parameters already stored in the UE context (and / or MM / RM context).

[0111] The CM may 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 both a signaling connection between the UE and the AN (e.g., an RRC connection or a UE-N3IWF connection for non-3GPP access) and an N2 connection for the UE 801 between the AN (e.g., the RAN 810) and the AMF 821. The UE 801 may operate in one of two CM states: a CM-IDLE mode or a CM-CONNECTED mode. When the UE 801 is operating in the CM-IDLE state / mode, the UE 801 may not have an NAS signaling connection established with the AMF 821 via the N1 interface, and there may be an (R)AN 810 signaling connection (e.g., an N2 and / or N3 connection) for the UE 801. When UE 801 is operating in CM-CONNECTED state / mode, UE 801 may have an established NAS signaling connection with AMF 821 via the N1 interface, and there may be an (R)AN 810 signaling connection (e.g., N2 and / or N3 connection) for UE 801. Establishment of the N2 connection between (R)AN 810 and AMF 821 may transition UE 801 from CM-IDLE mode to CM-CONNECTED mode, and UE 801 may transition from CM-CONNECTED mode to CM-IDLE mode when the N2 signaling between (R)AN 810 and AMF 821 is released.

[0112] The SMF 824 is responsible for and may perform SM (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF and AN nodes), UE IP address allocation and management (including optional authorization), UP function selection and control, traffic steering configuration in the UPF to route traffic to the appropriate destination, interface termination to policy control functions, control of policy enforcement and parts of QoS, lawful interception (for SM events and interfaces to the LI system), termination of the SM portion of NAS messages, notification of downlink data, initiation of AN-specific SM information sent to the AN via the AMF over N2, and determination of the SSC mode of the session. SM may refer to the management of a PDU session, and a PDU session (or "session") may refer to a PDU connectivity service that performs or enables the exchange of PDUs between the UE 801 and a data network (DN) 803 identified by a data network name (DNN). PDU sessions may be established at the UE 801 request, modified at the UE 801 and 5GC 820 request, and released at the UE 801 and 5GC 820 request using NAS SM signaling exchanged over the N1 reference point between the UE 801 and the SMF 824. In response to a request from the application server, the 5GC 820 may trigger a specific application in the UE 801. In response to receiving the trigger message, the UE 801 may pass the trigger message (or relevant portions / information of the trigger message) to one or more identified applications in the UE 801. The identified application(s) in the UE 801 may establish a PDU session to a specific DNN. The SMF 824 may check whether the UE 801 request complies with the user subscription information associated with the UE 801. In this regard, the SMF 824 may request to obtain and / or receive update notifications for SMF 824-level subscription data from the UDM 827.

[0113] The SMF 824 may include the following roaming functions: local enforcement processing for applying QoS SLAs (VPLMN), collection of charging data and charging interface (VPLMN), lawful intercept (of SM events within the VPLMN and interface to the LI system), support for interworking with external DNs for carrying signaling for authorization / authentication of PDU sessions by the external DN. An N16 reference point between two SMFs 824 may be included in the system 800, which may be between another SMF 824 in a visited network and an SMF 824 in a home network in a roaming scenario. Additionally, the SMF 824 may present an Nsmf service-based interface.

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

[0115] The NRF 825 supports service discovery functionality and can receive NF discovery requests from NF instances and provide information about discovered NF instances to NF instances. The NRF 825 also maintains information about available NF instances and their supported services. As used herein, the terms "instantiate," "instantiation," etc., can refer to the creation of an instance, and an "instance" can refer to a specific occurrence of an object that may occur, for example, during the execution of program code. Additionally, the NRF 825 can present an Nnrf service-based interface.

[0116] The PCF 826 can provide policy rules to the control plane function(s) and enforce them, and can support a unified policy framework to govern network behavior. The PCF 826 may also implement a 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 an N15 reference point between the PCF 826 and the AMF 821, which in the case of a roaming scenario may include the PCF 826 and the AMF 821 in the visited network. The PCF 826 may communicate with the AF 828 via an N5 reference point between the PCF 826 and the AF 828 and may communicate with the SMF 824 via an N7 reference point between the PCF 826 and the SMF 824. The system 800 and / or the CN 820 may also include an N24 reference point between the PCF 826 (in the home network) and the PCF 826 in the visited network. Furthermore, the PCF 826 can present an Npcf service-based interface.

[0117] The UDM 827 may process subscription-related information to support processing of communication sessions for network entities and may store subscription data for the UE 801. For example, the subscription data may be communicated between the UDM 827 and the AMF 821 via the N8 reference point between the UDM 827 and the AMF 821. The UDM 827 may include two parts: an application FE and a UDR (FEs and UDRs are not shown in FIG. 8). The UDR may store structured data for subscription and policy data for the UDM 827 and the PCF 826, and / or exposure and application data for the NEF 823 (including PFDs for application discovery, application requirement information for multiple UEs, and 801). A Nudr service-based interface may be exposed by the UDR 221 to enable the UDM 827, PCF 826, and NEF 823 to access specific sets of stored data and to read, update (e.g., add, modify), delete, and subscribe to notifications of associated data changes in the UDR. The UDM may include a UDM-FE responsible for handling certificates, location management, subscription management, etc. Several different front ends can serve the same user in different transactions. 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, and the SMS-FE implements application logic similar to that described above. In addition, the UDM 827 may present a Nudm service-based interface.

[0118] The AF 828 can influence traffic routing for applications, provide access to the NCE, and interact with the policy framework for policy control. The NCE may be a mechanism that allows the 5GC 820 and AF 828 to provide information to each other via the NEF 823, which can be used in edge computing implementations. In such implementations, network operators and third-party services can be hosted near the UE 801 access point attachment point to achieve efficient service delivery through reduced end-to-end latency and load on the transport network. In edge computing implementations, the 5GC can select a UPF 802 close to the UE 801 and perform traffic steering from the UPF 802 to the DN 803 via the N6 interface. This may be based on UE subscription data, UE location, and information provided by the AF 828. In this way, the AF 828 can influence UPF (re)selection and traffic routing. Based on the operator's deployment, when the AF 828 is considered a trusted entity, the network operator can allow the AF 828 to interact directly with the associated NF. Furthermore, the AF 828 can present a NAF service-based interface.

[0119] The NSSF 829 can select a set of network slice instances to serve the UE 801. The NSSF 829 can also determine the mapping to the allowed NSSAIs and subscribed S-NSSAIs, if necessary. The NSSF 829 can also determine the AMF set or list of candidate AMF(s) 821 to be used to serve the UE 801 based on a preferred configuration and possibly by querying the NRF 825. The selection of a set of network slice instances for the UE 801 may be triggered by the AMF 821, to which the UE 801 is registered by interacting with the NSSF 829, which can lead to its 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 a visited network via the N31 reference point (not shown in FIG. 8). Furthermore, the NSSF 829 can present an Nnssf service-based interface.

[0120] As mentioned above, the CN 820 may include an SMSF that is involved in SMS subscription checks and validations and can relay SM messages between the UE 801 and other entities such as the SMS-GMSC / IWMSC / SMS Router, etc. The SMS may also interact with the AMF 821 and UDM 827 for notification procedures that the UE 801 is available for SMS forwarding (e.g., setting an unreachable flag for the UE and notifying the UDM 827 when the UE 801 is available for SMS).

[0121] The CN 120 may also include other elements not shown by FIG. 8 , such as a data storage system / architecture, a 5G-EIR, and a SEPP. The data storage system may include an SDSF, a UDSF, etc. Any NF can store and retrieve unstructured data (e.g., UE context) to and from a UDSF via an N18 reference point (not shown by FIG. 8 ) between any NF and the UDSF. Individual NFs may share a UDSF to store their respective unstructured data, or each individual NF may have its own UDSF at or near the individual NF. In addition, the UDSF may expose a Nudsf service-based interface (not shown by FIG. 8 ). The 5G-EIR may be an NF that checks the status of a PEI to determine whether a particular device / entity is blacklisted in the network, and the SEPP may be an opaque proxy that performs topology hiding, message filtering, and policing on the inter-PLMN control plane interface.

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

[0123] 9 illustrates an example of infrastructure equipment 900 according to various embodiments. The infrastructure equipment 900 (or "system 900") may be implemented as a base station, a radio head, a RAN node such as the RAN node 611 and / or AP 606 previously shown and described, an application server(s) 630, and / or any other element / device described herein. In other examples, the system 900 may be implemented within or by a UE.

[0124] System 900 includes application circuitry 905, baseband circuitry 910, one or more Radio Front End Modules (RFEM) 915, memory circuitry 920, Power Management Integrated Circuitry (PMIC) 925, power T circuitry 930, network controller circuitry 935, network interface connector 940, satellite positioning circuitry 945, and user interface 950. In some embodiments, device 900 may include additional elements, such as memory / storage, a display, a camera, sensors, or input / output (I / O) interfaces. In other embodiments, the components described below may be included in two or more devices. For example, the circuits may be included separately in two or more devices for a CRAN, vBBU, or other similar implementation.

[0125] The application circuitry 905 may include, but is not limited to, one or more circuits such as a low drop-out voltage regulator (LDO), an interrupt controller, a serial interface such as SPI, I2C, or a universal programmable serial interface module, a real time clock (RTC), a timer counter including an interval timer and a watchdog timer, a general purpose input / output (I / O or IO), a memory card controller such as a Secure Digital (SD) Multi Media Card (MMC), a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI), and a Joint Test Access Group (JTAG) test access port. The processors (or cores) of the application circuitry 905 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the system 900. In some implementations, the memory / storage elements may be on-chip memory circuits, which 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 as described herein.

[0126] The processor(s) of application circuitry 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 machine (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, application circuitry 905 may include or be a special-purpose processor / controller operating in accordance with various embodiments herein. By way of example, the processor(s) of application circuitry 905 may include one or more Apple A-series processors, Intel Pentium®, Core®, or Xeon® processor(s). The system 900 may include an Advanced Micro Devices (AMD) Ryzen® processor(s), an accelerated processing unit (APU), or an Epyc® processor, an ARM-based processor(s) licensed from ARM Holdings Ltd., such as the ARM Cortex-A family processors, and processors of MIPS-based designs offered by MIPS Technologies, Inc., such as the ThunderX2® offered by Cavium™, Inc., MIPS Warrior P-class processors, etc. In some embodiments, the system 900 may not utilize application circuitry 905 and instead may include a dedicated processor / controller for processing IP data received from, for example, the EPC or 5GC.

[0127] In some implementations, the application circuitry 905 may include one or more hardware accelerators, which may be a microprocessor, a programmable processing device, or the like. The one or more hardware accelerators may include, for example, a computer vision (CV) and / or a deep learning (DL) accelerator. By way of example, the programmable processing device may be one or more of a field programmable device (FPD) such as a field programmable gate array (FPGA), a programmable logic device (PLD) such as a complex PLD (CPLD), a high capacity PLD (HCPLD), an ASIC such as a structured ASIC, a programmable system on a chip (PSoC), or the like. In such implementations, the circuitry of the application circuitry 905 may include logic blocks or logic fabric and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, and functions of various embodiments described herein. In such an embodiment, the circuitry of application circuit 905 may include memory cells (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), anti-fuses, etc.)) used to store logic blocks, logic fabric, data, etc., in look-up tables (LUTs), etc.

[0128] The baseband circuitry 910 may be implemented, for example, as a soldered board containing one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. The various hardware electronic elements of the baseband circuitry 910 are described below with respect to FIG. 11.

[0129] User interface circuitry 950 may include one or more user interfaces designed to enable user interaction with system 900 or peripheral component interfaces designed to enable peripheral component interaction with system 900. User interfaces may include, but are not limited to, one or more physical or virtual buttons (e.g., a reset button), 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-light emitting device, a microphone, a printer, a scanner, a headset, a display screen or device, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power interface, etc.

[0130] The radio front-end module (RFEM) 915 may include a millimeter-wave (mm-wave) RFEM and one or more submillimeter-wave radio frequency integrated circuits (RFICs). In some implementations, the one or more submillimeter-wave RFICs may be physically separate from the mm-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays (e.g., see antenna array 1111 in FIG. 11 below), and the RFEM may be connected to multiple antennas. In alternative implementations, both mm-wave and submillimeter-wave radio functionality may be implemented within the same physical RFEM 915 that incorporates both mm-wave and submillimeter-wave antennas.

[0131] The memory circuitry 920 may include one or more of volatile memory, including dynamic random access memory (DRAM) and / or synchronous dynamic random access memory (SDRAM), and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may incorporate Intel® and Micron® three-dimensional (3D) cross point (XPOINT) memory. The memory circuitry 920 may be implemented as one or more of a solder-packaged integrated circuit, a socketed memory module, and a plug-in memory card.

[0132] 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 brownout (undervoltage) and surge (overvoltage) conditions. The power T-circuit 930 may supply power drawn from a network cable that provides both power and data connectivity to the infrastructure equipment 900 using a single cable.

[0133] The network controller circuitry 935 may provide connectivity to a network using a standard network interface protocol, such as Ethernet, Ethernet over a GRE tunnel, Ethernet over Multiprotocol Label Switching (MPLS), or some other suitable protocol. Network connectivity may be provided to / from the infrastructure equipment 900 via network interface connectors 940 using a physical connection that may be electrical (commonly referred to as “copper wiring”), optical, or wireless. The network controller circuitry 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 circuitry 935 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

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

[0135] The components shown in FIG. 9 can communicate with each other using interface circuitry that can 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, for example, a proprietary bus used in an SoC-based system. Other bus or IX systems include an I2C interface, an SPI interface, a point-to-point interface, and a power bus, among others.

[0136] FIG. 10 illustrates an example of a platform 1000 (or “device 1000”) according to various embodiments. In an embodiment, the computer platform 1000 may be suitable for use as a UE 601, 701, 801, an application server 630, and / or any other element / device described herein. The platform 1000 may include any combination of components shown in the example. The components of the platform 1000 may be implemented as an integrated circuit (IC) adapted to the computer platform 1000, as part thereof, as a separate electronic device, or as other modules, logic, hardware, software, firmware, or a combination thereof, or as components otherwise incorporated within the chassis of a larger system. The block diagram of FIG. 10 is intended to provide an overhead view of the components of the computer platform 1000. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0137] The application circuitry 1005 includes, but is not limited to, one or more processors (or processor cores), cache memory, and circuits such as one or more LDOs, an interrupt controller, a serial interface such as SPI, I2C, or a universal programmable serial interface module, a timer counter including an RTC, interval and watchdog timers, a general-purpose I / O, a memory card controller such as SD MMC, a USB interface, a MIPI interface, and a JTAG test access port. The processors (or cores) of the application circuitry 1005 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in the memory / storage elements to enable various applications or operating systems to run on the system 1000. In some implementations, the memory / storage elements may be on-chip memory circuits, which 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 as described herein.

[0138] The processor(s) 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, multi-threaded processors, very low voltage processors, embedded processors, some other known processing elements, or any suitable combination thereof. In some embodiments, application circuitry 905 may include or be a special-purpose processor / controller that operates in accordance with various embodiments herein.

[0139] By way of example, the processor(s) of application circuit 1005 may include an Apple A-series processor. The processor of application circuit 1005 may also include one or more of an Intel® architecture core-based processor, such as a Quark®, Atom®, i3, i5, i7, or MCU class processor, or another such processor available from Intel® Corporation of Santa Clara, California; an Advanced Micro Devices (AMD) Ryzen processor(s) or an Accelerated Processing Unit (APU); one or more Snapdragon™ processor(s) from Qualcomm® Technologies Inc.; one or more Open Multimedia Application Platform (OMAP)™ processor(s) from Texas Instruments®; or MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors; ARM-based designs licensed from ARM Holdings, Ltd., such as the ARM Cortex-A, Cortex-R, and Cortex-M family of processors. In some implementations, the application circuit 1005 may be part of a system-on-chip (SoC) in which the application circuit 1005 and other components are formed within a single integrated circuit.

[0140] Additionally or alternatively, application circuitry 1005 may include circuitry such as, but not limited to, one or more field programmable devices (FPDs) such as FPGAs, programmable logic devices (PLDs) such as composite PLDs (CPLDs) or high-performance PLDs (HCPLDs), ASICs such as structured ASICs, programmable system-on-chips (PSoCs), etc. In such embodiments, the circuitry of application circuitry 1005 may include logic blocks or logic fabric and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, and functions of various embodiments described herein. In such embodiments, the circuitry of application circuitry 1005 may include memory cells (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), antifuses, etc.) used to store logic blocks, logic fabric, data, etc., such as in look-up tables (LUTs).

[0141] The baseband circuit 1010 may be implemented, for example, as a soldered board containing one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits. The various hardware electronic elements of the baseband circuit 1010 are described below with respect to FIG. 11.

[0142] The RFEM 1015 may include a millimeter-wave (mm-wave) RFEM and one or more submillimeter-wave radio frequency integrated circuits (RFICs). In some implementations, the one or more submillimeter-wave RFICs may be physically separate from the mm-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays (e.g., see antenna array 1111 in FIG. 11 below), and the RFEM may be connected to multiple antennas. In alternative implementations, both mm-wave and submillimeter-wave radio functionality may be implemented within the same physical RFEM 1015 that incorporates both mm-wave antennas and submillimeter-wave.

[0143] The memory circuit 1020 may include any number and type of memory devices used to provide a given amount of system memory. By way of example, the memory circuit 1020 may include one or more of: volatile memory, including random access memory (RAM), dynamic RAM (DRAM) and / or synchronous dynamic RAM (SDRAM), and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase-change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc. The memory circuit 1020 may be developed according to a Joint Electron Devices Engineering Council (JEDEC) low-power double data rate (LPDDR)-based design, such as LPDDR2, LPDDR3, LPDDR4, etc. The memory circuit 1020 may be implemented as one or more of a solder 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 onto a motherboard via a ball grid array (BGA). In low-power implementations, the memory circuit 1020 may be on-die memory or registers associated with the application circuit 1005. To provide persistent storage of information such as data, applications, and operating systems, the memory circuit 1020 may include one or more mass storage devices, which may include, among others, a solid-state disk drive (SSDD), a hard disk drive (HDD), a micro HDD, a resistive memory, a phase-change memory, a holographic memory, or a chemical memory. For example, the computer platform 1000 may incorporate three-dimensional (3D) cross-point (XPOINT) memory from Intel® and Micron®.

[0144] Removable memory circuitry 1023 may include devices, circuits, enclosures, ports or receptacles, etc. used to couple portable data storage devices with platform 1000. These portable data storage devices may be used for mass storage purposes and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, microSD cards, xD image cards, etc.), USB flash drives, optical disks, external HDDs, etc.

[0145] Platform 1000 may also include interface circuitry (not shown) used to connect external devices with platform 1000. External devices connected to platform 1000 via the interface circuitry include sensor circuitry 1021 and electromechanical components (EMC) 1022, as well as a removable memory device coupled to removable memory circuitry 1023.

[0146] The sensor circuitry 1021 may include devices, modules, or subsystems intended to detect events or changes in the environment and transmit information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors may include, among others, an inertial measurement unit (IMU) including an accelerometer, gyroscope, and / or magnetometer, a microelectromechanical system (MEMS) or nanoelectromechanical system (NEMS) including a 3-axis accelerometer, a 3-axis gyroscope, and / or magnetometer, a level sensor, a flow sensor, a temperature sensor (e.g., a thermistor), a pressure sensor, a barometric pressure sensor, a gravity meter, an altimeter, an image capture device (e.g., a camera or lensless aperture), a light detection and ranging (LiDAR) sensor, a proximity sensor (e.g., an infrared detector, etc.), a depth sensor, an ambient light sensor, an ultrasonic transceiver, a microphone or other similar audio capture device, etc.

[0147] The EMC 1022 includes devices, modules, or subsystems intended to enable the platform 1000 to change its state, position, and / or orientation, or to move or control mechanisms or (sub)systems. Additionally, the EMC 1022 may be configured to generate 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 EMCs 1022 based on one or more captured events and / or commands or control signals received from service providers and / or various clients.

[0148] In some implementations, the interface circuitry may connect the platform 1000 to the positioning circuitry 1045. The positioning circuitry 1045 includes circuitry for receiving and decoding signals transmitted / broadcast by a GNSS positioning network. Examples of navigation satellite constellations (or GNSS) include the United States' GPS, Russia's GLONASS, the European Union's Galileo system, China's Beidou navigation satellite system, regional navigation systems or GNSS augmentation systems (e.g., NAVIC, Japan's QZSS, France's DORIS, etc.), etc. The positioning circuitry 1045 includes various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate over-the-air (OTA) communications) for communicating with components of the positioning network, such as navigation satellite constellation nodes. In some embodiments, the positioning circuitry 1045 may include a Micro-PNT IC for performing position tracking / estimation without GNSS assistance using a master timing clock. The positioning circuitry 1045 may also be part of or interact with the baseband circuitry 910 and / or RFEM 1015 to communicate with nodes and components of a positioning network. The positioning circuitry 1045 may also provide position and / or time data to the application circuitry 1005, which may use the data to synchronize operation with various infrastructures (e.g., wireless base stations), such as for turn-by-turn navigation applications.

[0149] In some implementations, the interface circuit may connect the platform 1000 with a near field communication (NFC) circuit 1040. The NFC circuit 1040 is configured to provide contactless, short-range communication based on the Radio Frequency Identification (RFID) standard, and magnetic field induction is used to enable communication between the NFC circuit 1040 and an NFC-enabled device (e.g., an “NFC touchpoint”) external to the platform 1000. 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 emit a near-field RF signal. The RF signal may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transmit stored data to the NFC circuitry 1040, or may initiate data transfer between the NFC circuitry 1040 and another active NFC device (e.g., a smartphone or NFC-enabled POS terminal) in proximity to the platform 1000.

[0150] The driver circuit 1046 may include software and hardware elements that operate to control particular devices embedded in, attached to, or otherwise communicatively coupled to the platform 1000. The driver circuit 1046 may include individual drivers that enable other components of the platform 1000 to interact with or control various input / output (I / O) devices that may be present in or connected to the platform 1000. For example, the driver 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 actuator positions 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 capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0151] A power management integrated circuit (PMIC) 1025 (also referred to as "power management circuit 1025") may manage the power supplied to various components of platform 1000. Specifically, with respect to baseband circuit 1010, PMIC 1025 may control power source selection, voltage scaling, battery charging, or DC-DC conversion. When platform 1000 can be powered by a battery 1030, for example, when the device is included in a UE 601, 701, 801, PMIC 1025 may often be included.

[0152] In some embodiments, the PMIC 1025 can control or otherwise be a part of various power-saving mechanisms of the platform 1000. For example, if the platform 1000 is in an RRC connected state and still connected to a RAN node because it expects to receive traffic soon, after a period of inactivity the platform can enter a state known as discontinuous reception mode (DRX). While in this state, the platform 1000 may power down for short intervals, thereby conserving power. If there is no data traffic activity for an extended period of time, the platform 1000 can transition to an RRC idle state, disconnecting from the network and not performing operations such as channel quality feedback, handover, etc. The platform 1000 enters a very low power state, performs paging, and then periodically wakes up to listen to the network, then powers down again. The platform 1000 cannot receive data in this state and must transition to the RRC connected state to receive data. In further power-saving modes, the device can be allowed to be unavailable from the network for longer periods than the paging interval (which can range from a few seconds to several hours). During this time, the device may not be able to reach the network at all and may be completely powered down. Any data sent during this time will be significantly delayed, but the delay is deemed acceptable.

[0153] The battery 1030 may power the platform 1000, although in some examples the platform 1000 may be deployed and mounted at a fixed location and have a power source coupled to a power grid. The battery 1030 may 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 implementations, such as for V2X applications, the battery 1030 may be a typical lead-acid automotive battery.

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

[0155] A power block, or other power source coupled to the electric grid, may be coupled to the BMS to charge the battery 1030. In some examples, the power block XS30 may be replaced with a wireless power receiver to obtain power wirelessly, for example, via a loop antenna within the computer platform 1000. In these examples, wireless battery charging circuitry may be included in the BMS. The particular charging circuitry selected may depend on the size of the battery 1030 and, therefore, the current required. Charging may be performed using, among other things, the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power.

[0156] User interface circuitry 1050 includes various input / output (I / O) devices present within or connected to platform 1000 and may include one or more user interfaces designed to enable user interaction with platform 1000 and / or peripheral component interfaces designed to enable peripheral component interaction with platform 1000. User interface circuitry 1050 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting input, including, among others, 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. Output device circuitry includes any physical or virtual means for displaying or otherwise communicating information, such as a sensor reading, an actuator position(s), or other similar information. The output device circuitry may include any number and / or combination of audio or visual displays, among others, one or more simple visual outputs / indicators, such as binary status indicators (e.g., light emitting diodes (LEDs)), and multi-character visual outputs or more complex outputs, such as a display device or touch screen (e.g., a liquid crystal display (LCD), an LED display, a quantum dot display, a projector, etc.), that can output characters, graphics, multimedia objects, etc., generated or created from operation of the platform 1000. The output device circuitry may also include a speaker or other audio emitting device, printer(s), and / or the like. In some embodiments, the sensor circuitry 1021 may be used as an input device circuit (e.g., an image capture device, a motion capture device, etc.), and one or more EMCs may be used as output device circuitry (e.g., an actuator for providing tactile feedback, etc.). In another example, an NFC circuit comprising an NFC controller coupled to an antenna element and a processing device may be included for reading electronic tags and / or connecting with another NFC-enabled device.Peripheral component interfaces include, but are not limited to, a non-volatile memory port, a USB port, an audio jack, a power interface, and the like.

[0157] Although not shown, the components of platform 1000 can communicate with each other using any suitable bus or interconnect (IX) technology, which may include any number of technologies including ISA, EISA, PCI, PCIx, PCIe, a time-triggered protocol (TTP) system, a FlexRay system, or any number of other technologies. The bus / IX may be, for example, a proprietary bus / IX used in an SoC-based system. Other bus or IX systems include an I2C interface, an SPI interface, a point-to-point interface, and a power bus.

[0158] Figure 11 shows exemplary components of a baseband circuit 1110 and a radio front-end module (RFEM) 1115, according to various embodiments. The baseband circuit 1110 corresponds to the baseband circuits 910 and 1010, respectively, of Figures 9 and 10. The RFEM 1115 corresponds to the RFEMs 915 and 1015, respectively, of Figures 9 and 10. As shown, the RFEM 1115 may include at least a radio frequency (RF) circuit 1106, a front-end module (FEM) circuit 1108, and an antenna array 1111 coupled together as shown.

[0159] The baseband circuitry 1110 includes circuitry and / or control logic configured to execute various wireless / network protocol and wireless control functions that enable communication with one or more wireless networks via the RF circuitry 1106. The wireless control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some embodiments, the modulation / demodulation circuitry of the baseband circuitry 1110 may include fast Fourier transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of the baseband circuitry 1110 may include convolutional, tail-biting convolutional, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functions. Embodiments of the modulation / demodulation and encoder / decoder functions are not limited to these examples, and other embodiments may include other suitable functions. The baseband circuitry 1110 is configured to process baseband signals received from the receive signal path of the RF circuitry 1106 and generate baseband signals for the transmit signal path of the RF circuitry 1106. The baseband circuitry 1110 is configured to interface with the application circuitry 905 / XS205 (see FIGS. 9 and 10) for generating and processing baseband signals and for controlling the operation of the RF circuitry 1106. The baseband circuitry 1110 can handle various radio control functions.

[0160] The aforementioned circuitry and / or control logic of the baseband circuitry 1110 may include one or more single- or multi-core processors. For example, the one or more processors may include a 3G baseband processor 1104A, a 4G / LTE baseband processor 1104B, a 5G / NR baseband processor 1104C, or some other baseband processor 1104D of another existing, developing, or future generation (e.g., sixth generation (6G)). In other embodiments, some or all of the functionality of the baseband processors 1104A-1104D may be included in modules stored in memory 1104G and executed via a central processing unit (CPU) 1104E. In other embodiments, some or all of the functionality of the baseband processors 1104A-1104D may be provided as hardware accelerators (e.g., FPGAs, ASICs, etc.) loaded with appropriate bitstreams or logic blocks stored in corresponding memory cells. In various embodiments, the memory 1104G may store program code of a real-time operating system (RTOS) that, when executed by the CPU 1104E (or other baseband processor), causes the CPU 1104E (or other baseband processor) to manage resources, schedule tasks, etc. of the baseband circuitry 1110. Examples of an RTOS may include Operating System Embedded (OSE)™ provided by Enea®, Nucleus RTOS™ provided by Mentor Graphics®, Versatile Real-Time Executive (VRTX) provided by Mentor Graphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OS provided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or any other suitable RTOS as described herein. Additionally, the baseband circuitry 1110 includes one or more audio digital signal processor(s) (DSP) 1104F.The audio DSP(s) 1104F include elements for compression / decompression and echo cancellation, and in other embodiments may include other suitable processing elements.

[0161] In some embodiments, each of the processors 1104A-1104E includes a respective memory interface for transmitting and receiving data to / from the memory 1104G. The baseband circuit 1110 further includes one or more interfaces for communicatively coupling to other circuits / devices, such as an interface for transmitting and receiving data to / from memory external to the baseband circuit 1110, an application circuit interface for transmitting and receiving data to / from the application circuit 905 / XS205 of FIGS. 9-XT, an RF circuit interface for transmitting / receiving data to / from the RF circuit 1106 of FIG. 11, a wireless hardware connectivity interface for transmitting / receiving data to / from one or more wireless hardware elements (e.g., a near field communication (NFC) component, a Bluetooth® / Bluetooth® Low Energy component, a Wi-Fi® component, etc.), and a power management interface for transmitting and receiving power or control signals to / from the PMIC 1025.

[0162] In an alternative embodiment (which may be combined with the above-described embodiments), the baseband circuitry 1110 comprises one or more digital baseband systems coupled to each other and to a CPU subsystem, an audio subsystem, and an interface subsystem via an interconnection subsystem. The digital baseband subsystem may also be coupled to a digital baseband interface and a mixed-signal baseband subsystem via another interconnection subsystem. Each of the interconnection subsystems may include a bus system, a point-to-point connection, a network-on-chip (NOC) structure, and / or some other suitable bus or interconnection technology such as those discussed herein. The audio subsystem may include DSP circuitry, buffer memory, program memory, audio processing accelerator circuitry, data conversion circuitry such as analog-to-digital and digital-to-analog conversion circuitry, analog circuitry including one or more amplifiers and filters, and / or other similar components. In one aspect of the present disclosure, the baseband circuitry 1110 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for the digital baseband circuitry and / or radio frequency circuitry (e.g., radio front-end module 1115).

[0163] Although not shown in FIG. 11 , in some embodiments, the baseband circuitry 1110 includes individual processing units (e.g., a “multi-protocol baseband processor” or “protocol processing circuitry”) for executing one or more wireless communication protocols (e.g., a “multi-protocol baseband processor” or “protocol processing circuitry”) and individual processing devices (e.g., a “multi-protocol baseband processor” or “protocol processing circuitry”) for implementing PHY layer functions. In these embodiments, the PHY layer functions include the radio control functions described above. In these embodiments, the protocol processing circuitry operates or implements various protocol layers / entities of one or more wireless communication protocols. In a first example, the protocol processing circuitry may operate LTE protocol entities and / or 5G / NR protocol entities when the baseband circuitry 1110 and / or the RF circuitry 1106 are part of a millimeter wave communication circuit or some other suitable cellular communication circuit. In a first example, the protocol processing circuitry operates MAC, RLC, PDCP, SDAP, RRC, and NAS functions. In a second example, the protocol processing circuitry may operate one or more IEEE-based protocols when the baseband circuitry 1110 and / or the RF circuitry 1106 are part of a Wi-Fi communication system. In a second embodiment, the protocol processing circuitry operates WiFi MAC and Logical Link Control (LLC) functions. The protocol processing circuitry may include one or more memory structures (e.g., 1104G) for storing program code and data for operating the protocol functions, and one or more processing cores for executing the program code and performing various operations using the data. The baseband circuitry 1110 may also support wireless communications for multiple radio protocols.

[0164] The various hardware elements of the baseband circuitry 1110 discussed herein may be implemented, for example, as a soldered substrate containing one or more integrated circuits (ICs), a single packaged IC soldered to a main circuit board, or a multi-chip module containing two or more ICs. In one example, the components of the baseband circuitry 1110 may be suitably combined within a single chip or chipset, or may be located on the same circuit board. In another example, some or all of the components of the baseband circuitry 1110 and the RF circuitry 1106 may be implemented together, for example, in a system-on-chip SoC or system-in-package (SiP). In another example, some or all of the components of the baseband circuitry 1110 may be implemented as a separate SoC communicatively coupled to the RF circuitry 1106 (or multiple instances of the RF circuitry 1106). In yet another example, some or all of the components of the baseband circuitry 1110 and the application circuitry 905 / XS205 may be implemented together as individual SoCs implemented on the same circuit board (e.g., a “multi-chip package”).

[0165] In some embodiments, the baseband circuitry 1110 may provide communications compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1110 may support communications with E-UTRAN or other WMAN, WLAN, or WPAN. Embodiments in which the baseband circuitry 1110 is configured to support wireless communications of more than one radio protocol may be referred to as multi-mode baseband circuitry.

[0166] The RF circuitry 1106 can enable communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1106 may include switches, filters, amplifiers, etc. to facilitate communication with the wireless network. The RF circuitry 1106 can include a receive signal path that can include circuitry for downconverting RF signals received from the FEM circuitry 1108 and providing a baseband signal to the baseband circuitry 1110. The RF circuitry 1106 can also include a transmit signal path that can include circuitry for upconverting baseband signals provided by the baseband circuitry 1110 and providing an RF output signal to the FEM circuitry 1108 for transmission.

[0167] In some embodiments, the receive signal path of the RF circuit 1106 may include a mixer circuit 1106a, an amplifier circuit 1106b, and a filter circuit 1106c. In some embodiments, the transmit signal path of the RF circuit 1106 may include a filter circuit 1106c and a mixer circuit 1106a. The RF circuit 1106 may also include a combiner circuit 1106d for combining frequencies used by the mixer circuit 1106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 1106a of the receive signal path may be configured to downconvert the RF signal received from the FEM circuit 1108 based on a combined frequency provided by the combiner circuit 1106d. The amplifier circuit 1106b may be configured to amplify the downconverted signal, and the filter circuit 1106c may be a low-pass filter (LPF) or a band-pass filter (BPF) configured to remove unwanted signals from the downconverted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 1110 for further processing. In some embodiments, the output baseband signal may be a zero-frequency baseband signal, although this is not required. In some embodiments, mixer circuitry 1106a of the receive signal path may include a passive mixer, although the scope of the embodiments is not limited in this respect.

[0168] In some embodiments, the mixer circuit 1106a in the transmit signal path may be configured to upconvert an input baseband signal based on a synthesis frequency provided by the synthesizer circuit 1106d to generate an RF output signal for the FEM circuit 1108. The baseband signal may be provided by the baseband circuit 1110 and may be filtered by the filter circuit 1106c.

[0169] In some embodiments, the mixer circuit 1106a in the receive signal path and the mixer circuit 1106a in the transmit signal path may include two or more mixers and may be configured for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuit 1106a in the receive signal path and the mixer circuit 1106a in the transmit signal path may include two or more mixers and may be configured for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit 1106a in the receive signal path and the mixer circuit 1106a in the transmit signal path may be configured for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuit 1106a in the receive signal path and the mixer circuit 1106a in the transmit signal path may be configured for superheterodyne operation.

[0170] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuitry 1106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 1110 may include a digital baseband interface for communicating with the RF circuitry 1106.

[0171] In some dual-mode embodiments, separate radio IC circuitry may be provided for processing signals in each spectrum, although the scope of the embodiments is not limited in this respect.

[0172] In some embodiments, the combiner circuit 1106d may be a fractional-N combiner or a fractional-N / N+1 combiner, although the scope of the embodiments is not limited in this respect as other types of frequency combiners may be suitable. For example, the combiner circuit 1106d may be a combiner comprising a delta-sigma combiner, a frequency multiplier, or a phase-locked loop with a frequency divider.

[0173] The combiner circuit 1106d may be configured to combine, based on the frequency input and the divider control input, the output frequency used by the mixer circuit 1106a of the RF circuit 1106. In some embodiments, the combiner circuit 1106d may be a fractional N / N+1 combiner.

[0174] In some embodiments, the frequency input may be provided by a voltage-controlled oscillator (VCO), but this is not required. The divider control input may be provided by either the baseband circuitry 1110 or the application circuitry 905 / XS205, depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by the application circuitry 905 / XS205.

[0175] The synthesizer circuit 1106d of the RF circuit 1106 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on the implementation) to provide a fractional division ratio. In some exemplary embodiments, the DLL may include a cascaded tunable delay element, a phase detector, a charge pump, and a set of D-type flip-flops. In these embodiments, the delay elements may be configured to divide the VCO period into Nd equal-phase packets, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0176] In some embodiments, the synthesizer circuit 1106d may be configured to generate the carrier frequency as the output frequency, while in other embodiments the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and may be used in conjunction with a quadrature generator and divider circuit to generate multiple signals at the carrier frequency with different phases relative to each other. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 1106 may include an IQ / polar converter.

[0177] The FEM circuitry 1108 may include a receive signal path that may include circuitry configured to operate on RF signals received from the antenna array 1111, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry 1106 for further processing. The FEM circuitry 1108 may also include a transmit signal path that may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1106 for transmission by one or more antenna elements of the antenna array 1111. In various embodiments, amplification throughout the transmit or receive signal path may occur only in the RF circuitry 1106, only in the FEM circuitry 1108, or in both the RF circuitry 1106 and the FEM circuitry 1108.

[0178] In some embodiments, the FEM circuitry 1108 may include a TX / RX switch for switching between transmit and receive mode operation. The FEM circuitry 1108 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 1108 may include an LNA for amplifying a received RF signal and providing the amplified received RF signal as an output (e.g., to the RF circuitry 1106). The transmit signal path of the FEM circuitry 1108 may include a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuitry 1106) and one or more filters for generating an RF signal for subsequent transmission by one or more antenna elements of the antenna array 1111.

[0179] The antenna array 1111 includes one or more antenna elements, each configured to convert electrical signals into radio waves as they travel through the air and to convert received radio waves into electrical signals. For example, a digital baseband signal provided by the baseband circuitry 1110 is converted into an analog RF signal (e.g., a modulated waveform) that is amplified and transmitted via one or more antenna elements (not shown) of the antenna array 1111. The antenna elements may be omnidirectional, directional, or a combination thereof. The antenna elements may be formed in multiple arrangements, as known and / or as described herein. The antenna array 1111 may include microstrip antennas or printed antennas fabricated on the surface of one or more printed circuit boards. The antenna array 1111 may be formed as patches of metal foil (e.g., patch antennas) of various shapes and may be coupled to the RF circuit 1106 and / or the FEM circuit 1108 using metal transmission lines, etc.

[0180] The processors of the application circuitry 905 / XS205 and the baseband circuitry 1110 may be used to execute elements of one or more instances of a protocol stack. For example, the processor of the baseband circuitry 1110 may be used, alone or in combination, to execute layer 3, layer 2, or layer 1 functions, while the processor of the application circuitry 905 / XS205 may utilize data (e.g., packet data) received from these layers and further execute layer 4 functions (e.g., TCP and UDP layers). As referred to herein, layer 3 may include the RRC layer, which is described in more detail below. As referred to herein, layer 2 may include the MAC layer, RLC layer, and PDCP layer, which are described in more detail below. As referred to herein, layer 1 may include the PHY layer of a UE / RAN node, which is described in more detail below.

[0181]

[0013] Figure 12 illustrates various protocol functions that may be implemented in a wireless communication device in accordance with various embodiments. In particular, Figure 12 includes configuration 1200 illustrating interconnections between various protocol layers / entities. The following description of Figure 12 is provided for various protocol layers / entities operating in conjunction with 5G / NR and LTE system standards, although some or all of the aspects of Figure 12 may also be applicable to other wireless communication network systems.

[0182] The protocol layers of 1200 may include one or more of PHY 1210, MAC 1220, RLC 1230, PDCP 1240, SDAP 1247, RRC 1255, and NAS layer 1257, in addition to other higher layer functions not shown. The protocol layers may include one or more service access points (e.g., items 1259, 1256, 1250, 1249, 1245, 1235, 1225, and 1215 in FIG. 12) that may provide communication between two or more protocol layers.

[0183] The PHY 1210 may transmit and receive physical layer signals 1205, which may be received from or transmitted to one or more other communication devices. The physical layer signals 1205 may include one or more physical channels, such as those described herein. The PHY 1210 may further 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, such as the RRC 1255. The PHY 1210 may also perform error detection on transport channels, forward error correction (FEC) coding / 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 1210 may process requests and provide instructions from an instance of the MAC 1220 via one or more PHY-SAPs 1215. According to some embodiments, requests and instructions communicated over PHY-SAP 1215 may include one or more transport channels.

[0184] An instance of MAC 1220 can process requests from and provide instructions to instances of RLC 1230 via one or more MAC-SAPs 1225. These requests and instructions communicated via MAC-SAPs 1225 can include one or more logical channels. MAC 1220 can perform mapping between logical channels and transport channels, multiplexing MAC SDUs from one or more logical channels onto TBs delivered to PHY 1210 via transport channels, demultiplexing MAC SDUs from TBs to one or more logical channels delivered to PHY 1210 via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction via HARQ, and logical channel prioritization.

[0185] An instance of the RLC 1230 can process requests from and provide instructions to instances of the PDCP 1240 via one or more Radio Link Control Service Access Points (RLC-SAPs) 1235. These requests and instructions communicated via the RLC-SAPs 1235 can include one or more RLC channels. The RLC 1230 can operate in multiple modes of operation, including Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC 1230 can perform higher layer protocol data unit (PDU) transfer, error correction via automatic repeat request (ARQ) for AM data transfer, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transfer. The RLC 1230 may also perform re-segmentation of RLC data PDUs for AM data transfer, reorder RLC data PDUs for UM and AM data transfer, detect duplicate data for UM and AM data transfer, discard RLC SDUs for UM and AM data transfer, detect protocol errors for AM data transfer, and perform RLC re-establishment.

[0186] An instance of PDCP 1240 can process requests and provide instructions to an instance of RRC 1255 and / or an instance of SDAP 1247 via one or more Packet Data Convergence Protocol Service Access Points (PDCP-SAPs) 1245. These requests and instructions communicated via PDCP-SAPs 1245 can comprise one or more radio bearers. PDCP 1240 can perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), perform in-sequence delivery of upper layer PDUs upon lower layer re-establishment, remove duplicates of lower layer SDUs upon lower layer re-establishment for radio bearers mapped onto RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discarding of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

[0187] An instance of the SDAP 1247 can process requests and provide instructions from one or more higher layer protocol entities via one or more SDAP-SAPs 1249. These requests and instructions communicated via the SDAP-SAPs 1249 can include one or more QoS flows. The SDAP 1247 can map QoS flows to DRBs and vice versa, and can also mark QFIs in DL and UL packets. A single SDAP entity 1247 may be configured for an individual PDU session. In the UL direction, the NG-RAN 610 can control the mapping of QoS flows to DRB(s) in two different ways: reflective mapping or explicit mapping. For reflective mapping, the SDAP 1247 of the UE 601 may monitor the QFI of DL packets for each DRB and apply the same mapping to packets flowing in the UL direction. For a DRB, the SDAP 1247 of the UE 601 can map UL packets belonging to the QoS flow(s) corresponding to the QoS flow ID(s) and PDU session(s) observed in the DL packets for that DRB. To enable reflective mapping, the NG-RAN 810 can mark DL packets on the Uu interface with the QoS flow ID. Explicit mapping may include the RRC 1255 configuring the SDAP 1247 with an explicit QoS flow to DRB mapping rule, which can be stored and followed by the SDAP 1247. In an embodiment, the SDAP 1247 may be used only in an NR implementation and not in an LTE implementation.

[0188] The RRC 1255 may configure aspects of one or more protocol layers, which may include one or more instances of PHY 1210, MAC 1220, RLC 1230, PDCP 1240, and SDAP 1247, via one or more Management Service Access Points (M-SAPs). In an embodiment, an instance of the RRC 1255 may process requests and provide instructions from one or more NAS entities 1257, via one or more RRC-SAPs 1256. The main services and functions of the RRC 1255 may include broadcasting system information (e.g., contained in MIBs or NAS-related SIBs) or System Information Blocks (SIBs), broadcasting system information related to the access stratum (AS), paging, establishment, maintenance, and release of RRC connections between the UE 601 and the RAN 610 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, RRC connection release), establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, inter-Radio Access Technology (RAT) mobility, and measurement configuration for UE measurement reporting. The MIBs and SIBs may each contain one or more IEs, which may contain individual data fields or data structures.

[0189] The NAS 1257 may form the highest layer of the control plane between the UE 601 and the AMF 821. The NAS 1257 may support mobility and session management procedures for the UE 601 to establish and maintain IP connectivity between the UE 601 and a P-GW in the LTE system.

[0190] According to various embodiments, one or more protocol entities of 1200 may be implemented in the UE 601, the RAN node 611, the AMF 821 in an NR implementation or the MME 721 in an LTE implementation, the UPF 802 in an NR implementation, or the S-GW 722 and P-GW 723 in an LTE implementation, etc., used for a control plane or user plane communication protocol stack between the aforementioned devices. In such embodiments, one or more protocol entities that may be implemented in one or more of the UE 601, the gNB 611, the AMF 821, etc., may communicate with a separate peer protocol entity that may be implemented in or on another device using the services of the respective lower layer protocol entity to perform such communication. In some embodiments, the gNB-CU of the gNB 611 may host the RRC 1255, SDAP 1247, and PDCP 1240 of the gNB, which control the operation of one or more gNB-DUs, and the gNB-DU of the gNB 611 may host the RLC 1230, MAC 1220, and PHY 1210 of the gNB 211, respectively.

[0191] In a first example, the control plane protocol stack may comprise, from top to bottom, NAS 1257, RRC 1255, PDCP 1240, RLC 1230, MAC 1220, and PHY 1210. In this example, upper layers 1260 may be built on top of NAS 1257, including an IP layer 1261, SCTP 1262, and an application layer signaling protocol (AP) 1263.

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

[0193] The NG-AP 1263 may support the functionality of the NG interface 613 and may include Elementary Procedures (EPs). The NG-AP EP may be the unit of interaction between the NG-RAN node 611 and the AMF 821. The NG-AP 1263 services may include two groups: UE-related services (e.g., services related to the UE 601) and non-UE-related services (e.g., services related to the entire NG interface instance between the NG-RAN node 611 and the AMF 821). These services include, but are not limited to, a paging function for sending paging requests to the NG-RAN node 611 responsible for a particular paging area; a UE context management function for enabling the AMF 821 to establish, modify, and / or release UE context in the AMF 821 and the NG-RAN node 611; a mobility function for the UE 601 in ECM-CONNECTED mode for intra-system HO for supporting mobility within the NG-RAN and inter-system HO for supporting mobility from / to the EPS system; and a mobility function for the UE 601 in ECM-CONNECTED mode for transporting or rerouting NAS messages between the UE 601 and the AMF 821. The functions may include a NAS signaling transport function, a NAS node selection function for determining association between the AMF821 and the UE601, an NG interface management function(s) for setting up the NG interface and monitoring errors on the NG interface, an alert message transmission function for forwarding alert messages over the NG interface or providing a means for canceling ongoing broadcast of alert messages, a configuration transfer function for requesting and transferring RAN configuration information (e.g., SON information, performance measurement (PM) data, etc.) between two RAN nodes 611 via the CN620, and / or other similar functions.

[0194] The XnAP 1263 may support the functionality of the Xn interface 612 and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may include procedures used to handle UE mobility within the NGRAN 611 (or E-UTRAN 710), such as handover preparation and cancellation procedures, SN status transfer procedures, UE context lookup and UE context release procedures, RAN paging procedures, and dual connectivity related procedures. The XnAP global procedures may include procedures not related to a specific UE 601, such as Xn interface setup and reset procedures, NG-RAN update procedures, and cell activation procedures.

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

[0196] The S1 Application Protocol Layer (S1-AP) 1263 can support the functionality of the S1 interface, and similar to the NG-AP described above, the S1-AP can include an S1-AP EP. The S1-AP EP can be the unit of interaction between the E-UTRAN node 611 and the MME 721 in the LTE CN 620. The S1-AP 1263 services may include two groups: UE-related services and non-UE-related services. These services perform functions including, but 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.

[0197] The X2AP 1263 may support the functionality of the X2 interface 612 and may include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures may include procedures used to handle 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, and dual connectivity related procedures. The X2AP global procedures may include procedures not related to a specific UE 601, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, and cell activation procedures.

[0198] The SCTP layer (also referred to as the SCTP / IP layer) 1262 may 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 1262 may ensure reliable delivery of signaling messages between the RAN node 611 and the AMF 821 / MME 721 based in part on the IP protocol supported by the IP 1261. The Internet Protocol layer (IP) 1261 may be used to perform packet addressing and routing functions. In some implementations, the IP layer 1261 may use point-to-point transmission to deliver and convey PDUs. In this regard, the RAN node 611 may include L2 and L1 layer communication links (e.g., wired or wireless) with the MME / AMF to exchange information.

[0199] In a second example, the user plane protocol stack may comprise, from highest layer to lowest layer, an SDAP 1247, a PDCP 1240, an RLC 1230, a MAC 1220, and a PHY 1210. The user plane protocol stack may be used for communication between the UE 601, the RAN node 611, and the UPF 802 in an LTE implementation, or may be used for communication between the S-GW 722 and the P-GW 723 in an LTE implementation. In this example, the upper layers 1251 may be built on top of the SDAP 1247 and may include a User Datagram Protocol (UDP) and IP Security Layer (UDP / IP) 1252, a General Packet Radio Service (GPRS) Tunneling Protocol for the User Plane Layer (GTP-U) 1253, and a User Plane PDU Layer (UP-PDU) 1263.

[0200] The transport network layer 1254 (also called the "transport layer") may be built on top of IP transport and may carry user plane PDUs (UP-PDUs) using GTP-U 1253 on top of the UDP / IP layer 1252 (which includes the UDP and IP layers). The IP layer (also called the "internet layer") may be used to perform packet addressing and routing functions. The IP layer may assign IP addresses to user data packets, for example, in either IPv4, IPv6, or PPP format.

[0201] The GTP-U 1253 may be used to carry user data within the GPRS core network and between the radio access network and the core network. The transmitted user data may be packets in either IPv4, IPv6, or PPP format, for example. The UDP / IP 1252 may provide checksums for data integrity, port numbers to accommodate different functions at the source and destination, and encryption and authentication on selected data flows. The RAN node 611 and the S-GW 722 may utilize the S1-U interface to exchange user plane data via a protocol stack including the L1 layer (e.g., PHY 1210), the L2 layer (e.g., MAC 1220, RLC 1230, PDCP 1240, and / or SDAP 1247), the UDP / IP layer 1252, and the GTP-U 1253. The S-GW 722 and the P-GW 723 can utilize the S5 / S8a interface to exchange user plane data via a protocol stack including the L1 layer, the L2 layer, the UDP layer / IP layer 1252, and the GTP-U 1253. As previously mentioned, the NAS protocol can support the mobility and session management procedures of the UE 601 to establish and maintain IP connectivity between the UE 601 and the P-GW 723.

[0202] Additionally, although not shown in FIG. 12 , an application layer may exist above the AP 1263 and / or transport network layer 1254. The application layer may be the layer where a user of the UE 601, RAN node 611, or other network element interacts with a software application being executed by, for example, application circuit 905 or application circuit 1005, respectively. The application layer may also provide one or more interfaces through which the software application interacts with a communication system of the UE 601 or RAN node 611, such as baseband circuit 1110. In some implementations, the IP layer and / or application layer may provide functionality the same as or similar to layers 5-7 or portions 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).

[0203] FIG. 13 illustrates components of a core network according to various embodiments. The components of the CN 720 may be implemented in a single physical node or separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In embodiments, the components of the CN 720 may be implemented in the same or similar manner as described herein with respect to the components of the CN 720. In some embodiments, NFV is utilized to virtualize any or all of the network node functions described above via executable instructions stored on one or more computer-readable storage media (described in further detail below). A logical instantiation of the CN 720 may be referred to as a network slice 1301, and individual logical instantiations of the CN 720 may provide particular network capabilities and characteristics. A logical instantiation of a portion of the CN 720 may be referred to as a network sub-slice 1302 (e.g., the network sub-slice 1302 is shown to include a P-GW 723 and a PCRF 726).

[0204] As used herein, the terms "instantiate," "instantiation," etc., can refer to the creation of an instance, and "instance" can refer to a specific occurrence of an object that may occur, for example, during the execution of program code. A network instance can refer to information identifying a domain that can be used for traffic detection and routing in the case of different IP domains or overlapping IP addresses. A network slice instance can refer to a set of network function (NF) instances and resources (e.g., compute, storage, and network resources) required to deploy a network slice.

[0205] For 5G systems (see, for example, FIG. 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 realize different network slices through scheduling and by providing different L1 / L2 configurations. The UE 801 provides assistance information for network slice selection in appropriate RRC messages, if provided by the NAS. The network can support multiple slices, but the UE does not need to support 8 slices simultaneously.

[0206] A network slice may include the CN820 control plane and user plane NFs, the NG-RAN810 in the serving PLMN, and the N3IWF function in the serving PLMN. Each network slice may have a different S-NSSAI and / or a different SST. An NSSAI includes one or more S-NSSAIs, and each network slice is uniquely identified by an S-NSSAI. Network slices may differ in supported features and network feature optimization, and / or multiple network slice instances may deliver the same service / function for different groups of UEs 801 (e.g., enterprise users). For example, each network slice may deliver different committed services and / or may be dedicated to a specific customer or enterprise. In this example, each network slice may have a different NSSAI with the same SST but different slice atomizers. Furthermore, a single UE may be served by more than one network slice instance simultaneously via a 5G AN and associated with eight different S-NSSAIs. Furthermore, the AMF821 instance serving an individual UE801 may belong to each of the network slice instances serving that UE.

[0207] Network slicing in the NG-RAN 810 includes RAN slice awareness, which involves differentiated handling of traffic for different preconfigured network slices. Slice awareness in the NG-RAN 810 is implemented at the PDU session level by indicating the S-NSSAI corresponding to the PDU session in all signaling containing PDU session resource information. How the NG-RAN 810 supports slice enablement from the perspective of NG-RAN functions (e.g., the set of network functions that comprise each slice) is implementation-dependent. The NG-RAN 810 selects the RAN portion of a network slice using assistance information provided by the UE 801 or 5GC 820, which uniquely identifies one or more of the preconfigured network slices within the PLMN. The NG-RAN 810 also supports inter-slice resource management and policy enforcement according to the SLA. A single NG-RAN node can support multiple slices, and the NG-RAN 810 may also apply appropriate RRM policies for each supported slice based on the SLA in effect. The NG-RAN 810 may also support QoS differentiation within a slice.

[0208] The NG-RAN 810 may also use the UE assistance information to select an AMF 821 during initial attach, if available. The NG-RAN 810 uses the assistance information to route the initial NAS to the AMF 821. If the NG-RAN 810 cannot select an AMF 821 using the assistance information, or if the UE 801 does not provide such information at all, the NG-RAN 810 sends NAS signaling to a default AMF 821, which may be in a pool of AMFs 821. For subsequent accesses, the UE 801 provides a temporary ID (temp ID) assigned to the UE 801 by the 5GC 820 to enable the NG-RAN 810 to route NAS messages to the appropriate AMF 821 as long as the temp ID is valid. The NG-RAN 810 recognizes and can reach the AMF 821 associated with the temp ID. Otherwise, the method for initial attach applies.

[0209] The NG-RAN 810 supports resource isolation between slices. NG-RAN 810 resource isolation can be achieved through RRM policies and protection mechanisms that should avoid starvation of shared resources if one slice violates the service level agreements of another slice. In some implementations, NG-RAN 810 resources can be fully dedicated to a specific slice. The manner in which the NG-RAN 810 supports resource isolation is implementation dependent.

[0210] Some slices may be available only in parts of the network. NG-RAN 810 knowledge of slices supported in its neighboring cells can be beneficial for inter-frequency mobility in connected mode. Slice availability can remain constant within the UE's registration area. 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 can depend on factors such as slice support, resource availability, and support of the requested service by NG-RAN 810.

[0211] The UE 801 may be simultaneously associated with multiple network slices. When the UE 801 is simultaneously associated with multiple slices, only one signaling connection is maintained, and for intra-frequency cell reselection, the UE 801 attempts to camp on the best cell. For inter-frequency cell reselection, a dedicated priority can be used to control the frequency on which the UE 801 is camped. 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, the NG-RAN 810 may be permitted to apply some interim / local policies based on its knowledge of the specific slice to which the UE 801 is requesting access. During the initial context setup, the NG-RAN 810 is informed of the slice for which resources are requested.

[0212] The NFV architecture and infrastructure may be used to virtualize one or more NFs, or alternatively, may be implemented on proprietary hardware and virtualized onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches. In other words, an NFV system can be used to run a virtual or reconfigurable implementation of one or more EPC components / functions.

[0213] 14 is a block diagram illustrating components according to some example embodiments of a system 1400 for supporting NFV. The system 1400 is shown as including a VIM 1402, an NFVI 1404, a VNFM 1406, a VNF 1408, an EM 1410, an NFVO 1412, and an NM 1414.

[0214] The VIM 1402 manages the resources of the NFVI 1404. The NFVI 1404 may include physical or virtual resources and applications (including a hypervisor) used to run the system 1400. The VIM 1402 may manage the lifecycle of virtual resources by the NFVI 1404 (e.g., the creation, maintenance, and destruction of VMs associated with one or more physical resources), track VM instances, track the performance, faults, and security of the VM instances and associated physical resources, and expose the VM instances and associated physical resources to other management systems.

[0215] The VNFM 1406 may manage the VNFs 1408. The VNFs 1408 may be used to execute EPC components / functions. The VNFM 1406 may manage the lifecycle of the VNFs 1408 and track performance, faults, and security of the virtual aspects of the VNFs 1408. The EM 1410 may track performance, faults, and security of the functional aspects of the VNFs 1408. Tracking data from the VNFM 1406 and EM 1410 may include performance measurement PM data used by, for example, the VIM 1402 or the NFVI 1404. Both the VNFM 1406 and EM 1410 may scale up / down the amount of VNFs in the system 1400.

[0216] The NFVO 1412 can coordinate, grant, release, and reserve resources of the NFVI 1404 to provide the requested service (e.g., to execute an EPC function, component, or slice). The NM 1414 can provide a package of end-user functions responsible for management of the network, which may include network elements with VNFs, non-virtualized network functions, or both (management of VNFs may be done via the EM 1410).

[0217] 15 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies described herein, according to some demonstrative embodiments. Specifically, FIG. 15 shows a diagrammatic representation of hardware resources 1500, including one or more processors (or processor cores) 1510, one or more memory / storage devices 1520, and one or more communication resources 1530, each of which may be communicatively coupled via a bus 1540. In embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1502 may execute to provide an execution environment for one or more network slices / sub-slices utilizing the hardware resources 1500.

[0218] Processor(s) 1510 may include, for example, processor 1512 and processor 1514. Processor(s) 1510 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, a baseband processor such as an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0219] Memory / storage 1520 may include main memory, disk storage, or any suitable combination thereof. Memory / storage 1520 may include any type of volatile or non-volatile memory, such as, but not limited to, 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, etc.

[0220] Communications resources 1530 may include interconnection or network interface components or other suitable devices for communicating with one or more peripherals 1504 or one or more databases 1506 over network 1508. For example, communications resources 1530 may include wired communications components (e.g., for coupling via USB), cellular communications components, NFC components, Bluetooth® or Bluetooth® Low Energy components, Wi-Fi® components, and other communications components.

[0221] The instructions 1550 may include software, programs, applications, applets, apps, or other executable code for causing at least one of the processors 1510 to perform any one or more of the methodologies discussed herein. The instructions 1550 may reside, completely or partially, within at least one of the processors 1510 (e.g., within a processor's cache memory), within the memory / storage 1520, or within any suitable combination thereof. Furthermore, any portion of the instructions 1550 may be transferred to the hardware resources 1500 from any combination of the peripherals 1504 or the database 1506. Thus, the memory of the processor 1510, the memory / storage 1520, the peripherals 1504, and the database 1506 are examples of computer-readable and machine-readable media.

[0222] It is understood that use of personally identifiable information should comply with generally recognized privacy policies and practices that meet or exceed industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of permitted uses should be clearly indicated to users.

Claims

1. A method for synchronizing multiple data transmission activities for network traffic, comprising: determining that an alignment of subsequent use of resources is adjusted based on current use of the allocated resources for the network traffic such that one or more periods of transmission activity and a plurality of resources for the network traffic are synchronized; generating data indicative of a plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, the data indicative of the plurality of activity alignment parameters comprising: first data indicating an individual transmission direction for each of the plurality of resources to be synchronized; second data indicating an individual synchronization delay tolerance indicating a preferred maximum time interval for scheduling each of the network traffic on each of the plurality of resources; and third data indicating a request to map network traffic associated with the plurality of resources onto n transport blocks, where n is a positive integer indicating a number of transport blocks; generating a encoding the generated data for transmission; and transmitting the encoded data.

2. The method comprises: receiving data that configures a user equipment unit (UE) to adjust alignment of subsequent use of the resource; The method of claim 1 , further comprising: adjusting alignment of subsequent use of the resource based on the plurality of activity alignment parameters.

3. 3. The method of claim 2, wherein adjusting the alignment of subsequent use of the resources comprises decreasing a time interval between two or more resources to decrease an active transmission period of the UE.

4. the plurality of resources include or are associated with one or more Quality of Service (QOS) flows, one or more Data Radio Bearers (DRBs), one or more Logical Channels (LCHs), one or more Component Carriers (CCs), or one or more Logical Channel Groups (LCGs) corresponding to the network traffic that is mapped to the n transport blocks for alignment of subsequent usage of the adjusted resources; the plurality of resources are related to one or more application requirements of one or more applications underlying the synchronization requirement; or The method of claim 1 , wherein the plurality of resources are associated with one or more configured grants (CGs) or one or more semi-persistently scheduled (SPS) resources.

5. The method of claim 4, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: determining that the plurality of resources for subsequent use of the resource are each associated with a packet arrival time that meets a threshold arrival time, thereby providing the plurality of resources with a sufficient time margin relative to the packet arrival time; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating data indicating aggregation of the plurality of resources within a single period of transmission activity using a same component carrier (CC); The method of claim 1.

6. The method of claim 5, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: determining that the plurality of resources for subsequent use of the resource each relate to data requiring synchronous transmission; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating a request to aggregate the plurality of resources within a single period of transmission activity using the same component carrier (CC). The method of claim 1.

7. 7. The method of claim 6, wherein the plurality of activity alignment parameters further comprises at least: (i) data identifying a plurality of configured grants corresponding to the plurality of resources; and (ii) data identifying a group synchronization delay tolerance representing a preferred maximum time interval for scheduling the network traffic on the plurality of resources in a group.

8. The method of claim 7, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: determining that the plurality of resources for subsequent use of the resource are each associated with a packet arrival time that meets a threshold arrival time, thereby providing the plurality of resources with a sufficient time margin relative to the packet arrival time; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating data indicating using different component carriers (CCs) for each of the plurality of resources and aggregating the plurality of resources within a single period of transmission activity; The method of claim 1.

9. 9. The method of claim 8, wherein the plurality of activity alignment parameters further include at least: (i) data identifying a plurality of configured grants corresponding to the plurality of resources; (ii) data identifying each of the different CCs; and (iii) data identifying a group synchronization delay tolerance representing a preferred maximum time interval for scheduling the network traffic on the plurality of resources in a group.

10. The method of claim 10, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: determining that each of the plurality of resources for subsequent use of the resource is associated with data requiring synchronous transmission; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating data indicative of a request to aggregate the plurality of resources within a single period of transmission activity using a different component carrier (CC) for each of the plurality of resources. The method of claim 1.

11. 11. The method of claim 10, wherein the plurality of activity alignment parameters further comprises at least: (i) data identifying a plurality of configured grants corresponding to the plurality of resources; (ii) data identifying each of a plurality of LCHs; or (iii) data identifying a group synchronization delay tolerance representing a preferred maximum time interval for scheduling the network traffic on the plurality of resources in a group.

12. The method of claim 11, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: determining that the plurality of resources for subsequent use of the resources require synchronous transmission; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating data indicative of a request to aggregate the plurality of resources within a single period of transmission activity using a single transport block. The method of claim 1.

13. 13. The method of claim 12, wherein the activity alignment parameters further comprise at least: (i) data identifying configured grants corresponding to the plurality of resources; and (ii) data comprising a request to transport the configured grants in a single transport block.

14. The method of claim 13, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: determining that sets of resources in the plurality of resources for subsequent use of the resources have different periodicities; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating data indicative of a request to aggregate a first set of resources in the plurality of resources having a first periodicity within a first period of transmission activity and to aggregate a second set of resources in the plurality of resources having a second periodicity within a second period of transmission activity. The method of claim 1.

15. The method of claim 14, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: identifying a particular radio resource of the plurality of resources for subsequent use of the resource as a synchronization point representing a time at which data must be transmitted; determining that each of the remaining resources of the plurality of resources has the individual synchronization delay tolerance less than the threshold synchronization delay tolerance of the particular radio resource; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of radio resources, generating data indicating a request to delay exercising the remaining resources using a single carrier until a period of transmission activity during which the particular radio resource is exercised. The method of claim 1.

16. 16. The method of claim 15, wherein the plurality of activity alignment parameters further comprises at least: (i) data identifying a plurality of uplink grants or downlink assignments corresponding to the plurality of resources; and (ii) data identifying the individual synchronization delay tolerance for each of the plurality of uplink grants or downlink assignments.

17. The method of claim 16, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: identifying a particular radio resource of the plurality of resources for subsequent use of the resource as a synchronization point representing a time at which data must be transmitted; determining that each of the remaining resources of the plurality of resources has the individual synchronization delay tolerance less than the threshold synchronization delay tolerance of the particular radio resource; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating data indicating a request to delay exercising the remaining resources using multiple component carriers (CCs) until a period of transmission activity during which the particular radio resource is exercised. The method of claim 1.

18. 18. The method of claim 17, wherein the plurality of activity alignment parameters further include at least: (i) data identifying a plurality of uplink grants or downlink assignments corresponding to the plurality of resources; (ii) data identifying each of the plurality of CCs; and (iii) data identifying the individual synchronization delay tolerance for each of the plurality of uplink grants or downlink assignments.

19. The method of claim 18, wherein determining that alignment of subsequent use of resources is adjusted based on current use of the resources allocated for the network traffic comprises: identifying a particular radio resource of the plurality of resources for subsequent use of the resource as a synchronization point representing a time at which data must be transmitted; determining that each of the remaining resources of the plurality of resources has the individual synchronization delay tolerance less than the threshold synchronization delay tolerance of the particular radio resource; generating data indicative of the plurality of activity alignment parameters to be adjusted to result in the adjusted alignment of subsequent use of resources, generating data indicating a request to delay exercising the remaining resources using a single transport block on a single component carrier until a period of transmission activity during which the particular radio resource is exercised. The method of claim 1.

20. 20. The method of claim 19, wherein the plurality of activity alignment parameters further comprises at least: (i) data identifying a plurality of configured grants (CGs) or semi-persistently scheduled (SPS) resources corresponding to the plurality of resources; (ii) data identifying the individual synchronization delay tolerance for each of the plurality of CGs or SPS resources; and (iii) data identifying a request to transport the plurality of CGs or SPS resources in a single transport block.

21. An apparatus comprising one or more processors and one or more memory devices storing instructions that, when executed, cause a user equipment (UE) to perform the operations of a method according to any one of claims 1 to 20.

22. A baseband processor connected to one or more memory devices storing instructions that, when executed, cause the UE to perform the operations of the method of any one of claims 1 to 20.

23. A computer readable medium storing instructions that, when executed by one or more computers, cause the one or more computers to perform the operations of the method of any one of claims 1 to 20.

Images