Mechanisms and Signaling on CORESET and PUCCH Resource Groupings for Multi-TRP Operations
By receiving and executing the PUCCH resource group configuration associated with multiple transmission and reception points (TRPs) in the user equipment (UE), the complex problem of PUCCH resource packet management in the prior art is solved, and efficient resource utilization and channel coordination are achieved.
Patent Information
- Application Number
- CN202080044602.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-05-03
- Filing Date
- 2020-05-01
- Publication Date
- 2025-06-27
- Estimated Expiration
- 2040-05-01
AI Technical Summary
In wireless communication systems, it is difficult for the prior art to effectively manage and coordinate the physical uplink control channel (PUCCH) resource packets between multiple transmission and reception points (TRPs), resulting in inefficient resource utilization and complex channel management.
The PUCCH resource group configuration associated with the TRP is received through the user equipment (UE), and PUCCH transmission is performed according to the configuration. The specific implementation includes configuring the first and second sets of PUCCH resources, utilizing time-division multiplexed and non-overlapping resource portions, and combining scheduling downlink control information (DCI) messages for PUCCH transmission.
It realizes more efficient PUCCH resource management and channel coordination, improves resource utilization efficiency, simplifies the channel management process, and supports the flexibility of multi-TRP operations.
Smart Images

Figure CN113994750B_ABST
Abstract
Description
[0001] Cross - Reference to Related Applications
[0002] This disclosure claims the benefit of priority of U.S. Provisional Patent Application No. 62 / 843,269, filed on May 3, 2019, entitled "MECHANISM AND SIGNALING ONCORESET AND PUCCH RESOURCE GROUPING FOR MULTI-TRP OPERATION". The entire patent application described above is incorporated herein by reference. TECHNICAL FIELD
[0003] This disclosure generally relates to wireless communication systems. BACKGROUND ART
[0004] Base stations, such as nodes of a radio access network (RAN), may communicate wirelessly with wireless devices, such as user equipment (UE). Downlink (DL) transmission refers to communication from a base station to a wireless device. Uplink (UL) transmission refers to communication from a wireless device to another device, such as a base station. A base station may transmit control signaling to control wireless devices operating within its network. SUMMARY OF THE INVENTION
[0005] This disclosure describes systems, apparatuses, and techniques for physical uplink control channel (PUCCH) resource grouping in a wireless communication system including transmission and reception points (TRP). The techniques performed by a user equipment (UE) described herein include receiving a PUCCH resource group configuration associated with a TRP, the TRP including a first TRP and a second TRP; and performing PUCCH transmission to the TRP according to the PUCCH resource group configuration. The PUCCH resource group configuration may include a configuration of a first set of PUCCH resources associated with the first TRP and a second set of PUCCH resources associated with the second TRP. Other specific embodiments include corresponding systems, devices, communication processors, and computer programs for performing the actions of a method defined by instructions encoded on a computer-readable storage device.
[0006] These specific implementations and other specific implementations may include one or more of the following features. In some specific implementations, the first part of the first set of PUCCH resources is time-division multiplexed with the first part of the second set of PUCCH resources. In some specific implementations, the second part of the first set of PUCCH resources is not time-division multiplexed with the second part of the second set of PUCCH resources. Receiving the PUCCH resource group configuration may include receiving a PRI configuration for a first PUCCH resource indication identifier (PRI) and a second PRI. The first part of the first set of PUCCH resources and the first part of the second set of PUCCH resources can be addressed by the first PRI. The second part of the first set of PUCCH resources and the second part of the second set of PUCCH resources can be addressed by the second PRI.
[0007] Specific implementations may include receiving a downlink control information (DCI) message that schedules PUCCH transmissions. In some specific implementations, the PUCCH transmission uses the resources indicated by the PRI included in the DCI message. Receiving the PUCCH resource group configuration may include receiving a serving cell identifier, a bandwidth part (BWP) identifier, a PUCCH resource identifier, and a PUCCH resource group identifier via radio resource control (RRC) signaling, medium access control (MAC) control element (CE) signaling, or both. The PUCCH resource group configuration may include a group association between the PUCCH resource group and a control resource set (CORESET) group. Specific implementations may include receiving a CORESET pool configuration, which may include a serving cell identifier, a bandwidth part (BWP) identifier, a CORESET identifier, and a CORESET pool identifier associated with the CORESET pool. In some specific implementations, the group association is signaled by information including a serving cell identifier, a BWP identifier, a CORESET identifier, and a PUCCH resource group identifier.
[0008] In some specific implementations, the first part of the first set of PUCCH resources is time-division multiplexed with the first part of the second set of PUCCH resources. In some specific implementations, the second part of the first set of PUCCH resources at least partially overlaps with the second part of the second set of PUCCH resources. Performing the PUCCH transmission may include transmitting a first hybrid automatic repeat request (HARQ) feedback to a first TRP using the first part of the first set of PUCCH resources; and transmitting a second HARQ feedback to a second TRP using the first part of the second set of PUCCH resources.
[0009] The UE may include one or more processors, a transceiver, and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations may include receiving PUCCH resource group configurations via the transceiver. The PUCCH resource group configurations may include configurations for a first set of PUCCH resources associated with a first TRP and a second set of PUCCH resources associated with a second TRP. The operations may include operating the transceiver to perform PUCCH transmissions to the TRP according to the PUCCH resource group configurations, where the TRP includes the first TRP and the second TRP.
[0010] The base station may include a transceiver; and one or more processors coupled to the transceiver. The one or more processors may be configured to provide PUCCH resource group configurations via the transceiver. The PUCCH resource group configurations may include configurations for a first set of PUCCH resources associated with a first TRP and a second set of PUCCH resources associated with a second TRP. The one or more processors can be configured to operate the transceiver to receive one or more PUCCH transmissions from one or more TRPs according to the PUCCH resource group configurations. The one or more processors can be configured to provide PRI configurations. The PUCCH resource group configurations may include a group association between a PUCCH resource group and a CORESET pool.
[0011] Details of one or more specific implementations are set forth in the following drawings and detailed description. Other features and advantages will be apparent from the detailed description, drawings, and claims. Description of the Drawings
[0012] Figure 1 An example of a wireless communication system is illustrated.
[0013] Figure 2 An exemplary architecture of a system including a core network is illustrated.
[0014] Figure 3 Another exemplary architecture of a system including a core network is illustrated.
[0015] Figure 4 An example of infrastructure equipment is shown.
[0016] Figure 5 An example of a platform or device is shown.
[0017] Figure 6 Exemplary components of a baseband circuit and a radio front-end circuit are illustrated.
[0018] Figure 7 Exemplary components of a cellular communication circuit are shown.
[0019] Figure 8Illustrates example protocol functions that can be implemented in a wireless communication system.
[0020] Figure 9 Illustrates an example of a computer system.
[0021] Figure 10 Shows a diagram illustrating an example of a wireless communication system including multiple RAN nodes configured for multi-TRP operation.
[0022] Figure 11 Shows an example of the relationship between PUCCH resource groups, TRPs, and CORESETs.
[0023] Figure 12 Shows an example of coordinating PUCCH transmissions between different PUCCH resource groups and TRPs.
[0024] Figure 13 Shows an example of the format for a PUCCH resource group update MAC CE.
[0025] Figure 14 Shows another example of the format for a PUCCH resource group update MAC CE.
[0026] Figure 15 Shows a flowchart of another example of a configuration and PUCCH transmission process performed by a UE.
[0027] Figure 16 Shows a flowchart of an example of a configuration and PUCCH reception process performed by one or more network components.
[0028] Like reference symbols in the various figures indicate like elements. Detailed Description
[0029] Figure 1 Illustrates an example of a wireless communication system 100. For purposes of convenience and not limitation, the exemplary system 100 is described in the context of LTE and 5G NR communication standards defined by the Third Generation Partnership Project (3GPP) technical specifications. However, other types of communication standards are also possible.
[0030] System 100 includes UEs 101a and 101b (collectively referred to as "UE 101"). In this example, UE 101 is shown as a smart phone (e.g., a handheld touchscreen mobile computing device that can be connected to one or more cellular networks). In other examples, any one of the multiple UEs 101 may include other mobile computing devices or non-mobile computing devices, such as consumer electronic devices, cellular phones, smart phones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument clusters (IC), head-up display (HUD) devices, on-board diagnostic (OBD) devices, on-board mobile equipment (DME), mobile data terminals (MDT), electronic engine management systems (EEMS), electronic / engine control units (ECU), electronic / engine control modules (ECM), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or "smart" home appliances, machine type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, or combinations thereof, etc.
[0031] In some specific implementations, any one of UEs 101 can be an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE can utilize technologies such as M2M or MTC to exchange data with an MTC server or device using, for example, a public land mobile network (PLMN), proximity services (ProSe), device-to-device (D2D) communication, sensor networks, IoT networks, or combinations thereof, etc. The M2M or MTC data exchange can be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE can execute background applications (e.g., keep-alive messages or status updates) to facilitate the connection to the IoT network.
[0032] UE 101 is configured to connect to (e.g., communicatively couple with) RAN 110. RAN 110 includes one or more RAN nodes 111a and 111b (collectively referred to as "RAN nodes 111"). In some embodiments, RAN 110 may be a Next Generation RAN (NGRAN), an evolved UMTS Terrestrial Radio Access Network (E-UTRAN), or a legacy RAN such as a UMTS Terrestrial Radio Access Network (UTRAN) or a GSM EDGE Radio Access Network (GERAN). As used herein, the term "NG RAN" may refer to RAN 110 operating in a 5G NR system 100, while the term "E-UTRAN" may refer to RAN 110 operating in an LTE or 4G system 100.
[0033] To connect to RAN 110, multiple UEs 101 utilize connections (or channels) 103 and 104 respectively, and each connection (or channel) may include a physical communication interface or layer as described below. In this example, connections 103 and 104 are shown as air interfaces to enable communicative coupling and may be compliant with cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Push-to-Talk over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP LTE protocol, 5G NR protocol, or a combination thereof, as well as other communication protocols.
[0034] RAN 110 may include one or more RAN nodes 111a and 111b (collectively referred to as "RAN nodes 111") that enable connections 103 and 104. As used herein, terms such as "access node", "access point", etc. may describe equipment that provides radio baseband functionality for a data or voice connection or both between a network and one or more users. These access nodes may be referred to as base stations (BS), gNodeB, gNB, eNodeB, eNB, NodeB, RAN nodes, roadside units (RSU), etc., and may include terrestrial stations (e.g., land access points) or satellite stations, etc. that provide coverage within a geographical area (e.g., a cell). As used herein, the term "NGRAN node" may refer to RAN node 111 (e.g., gNB) operating in a 5G NR system 100, while the term "E-UTRAN node" may refer to RAN node 111 (e.g., eNB) operating in an LTE or 4G system 100. In some embodiments, RAN node 111 may be implemented as one or more of a dedicated physical device such as a macrocell base station, or a low-power (LP) base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macrocell.
[0035] RAN node 111 and UE 101 can be configured for multi-input and multi-output (MIMO) communication, including single-beam or multi-beam communication. For example, UE 101 can receive transmissions from one RAN node 111 at a time, or receive transmissions from multiple RAN nodes 111 simultaneously. RAN node 111 and UE 101 can use beamforming for UL, DL, or both. For example, one or more RAN nodes 111 can transmit (Tx) beams to UE 101, and UE 101 can receive data simultaneously via one or more receive (Rx) beams. In some specific implementations, each of the RAN nodes 111 can be configured as a transmission and reception point (TRP). RAN 110 can provide high-layer signaling for configuring beamforming, such as by providing transmission configuration indication (TCI) state configuration information.
[0036] Any one of the RAN nodes 111 can be the endpoint of the air interface protocol and can be the first contact point for UE 101. In some specific implementations, any one of the RAN nodes 111 can perform various logical functions of RAN 110, including but not limited to the functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.
[0037] In some specific implementations, multiple UEs 101 can be configured to communicate with each other or with any one of the RAN nodes 111 over a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as but not limited to OFDMA communication technology (e.g., for downlink communication) or SC-FDMA communication technology (e.g., for uplink communication), but the scope of the technologies described here is not limited in this regard. The OFDM signal can include multiple orthogonal subcarriers.
[0038] In some specific implementations, the downlink resource grid can be used for downlink transmissions from any one of the RAN nodes 111 to the UE 101, and similar techniques can be utilized for uplink transmissions. The grid can be a frequency grid or a time-frequency grid, which are the physical resources in the downlink for each time slot. For OFDM systems, such time-frequency plane representations are common practice, which makes wireless resource allocation intuitive. Each column and each row of the resource grid correspond to an OFDM symbol and an OFDM subcarrier respectively. The duration of the resource grid in the time domain corresponds to one time slot in the radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element (RE). Each resource grid can include multiple resource blocks, which describe the mapping of certain physical channels to resource elements. A resource block (RB) can include a set of resource elements; in the frequency domain, this can represent the smallest amount of resources that can be allocated currently. Such resource blocks can be used to transmit physical downlink channels and uplink channels. In some cases, an RB can be referred to as a physical resource block (PRB).
[0039] The RAN node 111 can transmit to the UE 101 through one or more DL channels. Various examples of DL communication channels include the physical broadcast channel (PBCH), the physical downlink control channel (PDCCH), and the physical downlink shared channel (PDSCH). The PDSCH can carry user data and higher layer signaling to multiple UEs 101. Other types of downlink channels are possible. The UE 101 can transmit to the RAN node 111 through one or more UL channels. Various examples of UL communication channels include the physical uplink shared channel (PUSCH), the physical uplink control channel (PUCCH), and the physical random access channel (PRACH). Other types of uplink channels are possible. Devices such as the RAN node 111 and the UE 101 can transmit reference signals. Examples of reference signals include sounding reference signals (SRS), channel state information reference signals (CSI-RS), demodulation reference signals (DMRS or DM-RS), and phase tracking reference signals (PTRS). Other types of reference signals are possible.
[0040] A channel such as the PDCCH may transmit different types of scheduling information for one or more downlink channels and uplink channels. The scheduling information may include downlink resource scheduling, uplink power control instructions, uplink resource grants, and indications for paging or system information. The RAN node 111 may transmit one or more downlink control information (DCI) messages on the PDCCH to provide scheduling information, such as the allocation of one or more PRBs. In some embodiments, the DCI message transmits control information, such as a request for an aperiodic CQI report, a UL power control command for a channel, and a notification of the slot format for a group of UEs 101. Downlink scheduling may be performed at any of the RAN nodes 111 based on channel quality information fed back from any of the UEs 101 (e.g., allocating control and shared channel resource blocks to the UE 101b within the cell). Downlink resource allocation information may be sent on the PDCCH for each UE used (e.g., allocated to) the UE 101 or a group of UEs.
[0041] In some embodiments, among other information, the PDCCH carries information about the transmission format and resource allocation related to the PDSCH channel. The PDCCH may also receive notification from the PDSCH to inform the UE 101 about the transmission format, resource allocation, and hybrid automatic repeat request (HARQ) information for providing HARQ feedback on the uplink channel.
[0042] In some embodiments, the PDCCH uses control channel elements (CCEs) to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruples and then may be arranged using a sub-block interleaver for rate matching. In some embodiments, one or more of these CCEs may be used to transmit each PDCCH, where each CCE may correspond to a set of nine physical resource elements, collectively referred to as a resource element group (REG). Four quadrature phase shift keying (QPSK) symbols may be mapped to each REG. Depending on the size of the DCI and the channel conditions, one or more CCEs may be used to transmit the PDCCH. In some embodiments, there may be four or more different PDCCH formats defined with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8).
[0043] Downlink and uplink transmissions can occur in one or more component carriers (CCs). One or more bandwidth part (BWP) configurations can be configured for each component carrier. In some specific implementations, the DL BWP includes at least one control resource set (CORESET). In some specific implementations, the CORESET includes one or more physical resource blocks (PRBs) in the frequency domain and one or more OFDM symbols in the time domain. In some specific implementations, a channel such as the PDCCH can be transmitted via one or more CORESETs, where each CORESET corresponds to a set of time-frequency resources. CORESET information can be provided to the UE 101, and the UE 101 can monitor the time-frequency resources associated with one or more CORESETs to receive PDCCH transmissions.
[0044] RAN nodes 111 are configured to communicate with each other using interface 112. In an example, such as if system 100 is an LTE system (e.g., when the core network 120 is Figure 2 the evolved packet core (EPC) network as shown), interface 112 can be the X2 interface 112. The X2 interface can be defined between two or more RAN nodes 111 (e.g., two or more eNBs, etc.) connected to the EPC 120, or between two eNBs connected to the EPC 120, or both. In some specific implementations, the X2 interface can include the X2 user plane interface (X2-U) and the X2 control plane interface (X2-C). The X2-U can provide a flow control mechanism for user packets transmitted through the X2 interface and can be used to convey information about the delivery of user data between eNBs. For example, the X2-U can provide specific sequence number information about user data transmitted from the primary eNB to the secondary eNB; information about the successful in-sequence delivery of PDCP protocol data units (PDUs) from the secondary eNB to the UE 101 for user data; information about PDCP PDUs not delivered to the UE 101; information about the current minimum desired buffer size at the secondary eNB for transmitting user data to the UE; and so on. The X2-C can provide intra-LTE access mobility functions, including context transfer from the source eNB to the target eNB, or user plane transmission control; load management functions; inter-cell interference coordination functions; and so on.
[0045] In some specific implementations, such as if system 100 is a 5G NR system (e.g., when the core network 120 is Figure 3When referring to the 5G core network shown, interface 112 can be the Xn interface 112. The Xn interface can be defined between two or more RAN nodes 111 (e.g., two or more gNBs, etc.) connected to the 5G core network 120, between a RAN node 111 (e.g., gNB) connected to the 5G core network 120 and an eNB, or between two eNBs connected to the 5G core network 120, or a combination of the above. In some specific implementations, the Xn interface can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U can provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and traffic control functions. The Xn-C can provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for UEs 101 in the connected mode (e.g., CM-CONNECTED), including functions for managing UE mobility in the connected mode between one or more RAN nodes 111; and so on. Mobility support can include context transfer from an old (source) serving RAN node 111 to a new (target) serving RAN node 111, and control of the user plane tunnel between the old (source) serving RAN node 111 and the new (target) serving RAN node 111. The protocol stack of the Xn-U can include a transport network layer built on the Internet Protocol (IP) transport layer, and a GPRS tunneling protocol (GTP-U) layer of the user plane for carrying user plane PDUs on top of the User Datagram Protocol (UDP) or the IP layer or both. The Xn-C protocol stack can include an application layer signaling protocol (referred to as the Xn application protocol (Xn-AP or XnAP)) and a transport network layer built on the Stream Control Transmission Protocol (SCTP). The SCTP can be on top of the IP layer and can provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other specific implementations, the Xn-U protocol stack or the Xn-C protocol stack or both can be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.
[0046] RAN 110 is shown as communicatively coupled to a core network 120 (referred to as "CN 120"). CN 120 includes one or more network elements 122 that are configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 101) who are connected to CN 120 using RAN 110. The components of CN 120 may be implemented in one physical node or separate physical nodes and may include components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some specific implementations, network function virtualization (NFV) may be used to virtualize some or all of the network node functions described herein using executable instructions stored in one or more computer-readable storage media, as will be described further in detail below. A logical instance of CN 120 may be referred to as a network slice, and a logical instance of a part of CN 120 may be referred to as a network sub-slice. The NFV architecture and infrastructure may be used to virtualize one or more network functions onto physical resources that include a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, the NFV system may be used to perform virtual or reconfigurable implementations of one or more network components or functions, or both.
[0047] The application server 130 may be an element that provides applications that use IP bearer resources together with the core network (e.g., UMTS packet service (PS) domain, LTE PS data service, etc.). The application server 130 may also be configured to support one or more communication services for UE 101 using CN 120 (e.g., VoIP sessions, PTT sessions, group communication sessions, social network services, etc.). The application server 130 may communicate with one or more network elements 122 using an IP communication interface 125.
[0048] In some specific implementations, CN 120 may be a 5G core network (referred to as "5GC 120" or "5G core network 120"), and RAN 110 may be connected to CN 120 using a next-generation interface 113. In some specific implementations, the next-generation interface 113 may be divided into two parts: a next-generation user plane (NG-U) interface 114 that carries traffic data between RAN nodes 111 and the UPF (user plane function); and an S1 control plane (NG-C) interface 115 that is a signaling interface between RAN nodes 111 and the access and mobility management function (AMF). Refer to Figure 3 Examples where CN 120 is a 5G core network are discussed in more detail.
[0049] In some specific implementations, CN 120 can be an EPC (referred to as "EPC 120", etc.), and RAN 110 can be connected to CN 120 using the S1 interface 113. In some specific implementations, the S1 interface 113 can be divided into two parts: the S1 user plane (S1-U) interface 114, which carries traffic data between the RAN node 111 and the serving gateway (S-GW); and the S1-MME interface 115, which is a signaling interface between the RAN node 111 and the mobility management entity (MME).
[0050] In some specific implementations, some or all of the RAN nodes 111 can be implemented as one or more software entities running on a server computer and as part of a virtual network that can be referred to as cloud RAN (CRAN) and / or virtual baseband unit pool (vBBUP). CRAN or vBBUP can implement RAN function partitioning, such as packet data convergence protocol (PDCP) partitioning, where the radio resource control (RRC) and PDCP layers are operated by CRAN / vBBUP, and other layer 2 (e.g., data link layer) protocol entities are operated by the respective RAN nodes 111; medium access control (MAC) / physical layer (PHY) partitioning, where the RRC, PDCP, MAC, and radio link control (RLC) layers are operated by CRAN / vBBUP, and the PHY layer is operated by the respective RAN nodes 111; or "lower PHY" partitioning, where the RRC, PDCP, RLC, and MAC layers and the upper part of the PHY layer are operated by CRAN / vBBUP, and the lower part of the PHY layer is operated by the respective RAN nodes 111. This virtualization framework allows the idle processor cores of the RAN nodes 111 to execute, for example, other virtualized applications. In some specific implementations, a separate RAN node 111 can represent each gNB distributed unit (DU) connected to the gNB central unit (CU) using respective F1 interfaces ( Figure 1 not shown). In some specific implementations, the gNB-DU can include one or more remote radio heads or RFEMs (see, for example, Figure 4 ), and the gNB-CU can be operated by a server (not shown) located in the RAN 110 or by a server pool in a manner similar to CRAN / vBBUP. In addition or alternatively, one or more of the RAN nodes 111 can be a next-generation eNB (ng-eNB), including a RAN node that provides E-UTRA user plane and control plane protocol terminations to the UE101 and is connected to the 5G core network (e.g., core network 120) using next-generation interfaces.
[0051] In a vehicle-to-everything (V2X) scenario, one or more RAN nodes in RAN node 111 can be or act as an RSU. The term "roadside unit" or "RSU" refers to any transportation infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where the RSU implemented in or by the UE can be referred to as a "UE-type RSU", the RSU implemented in or by the eNB can be referred to as an "eNB-type RSU", the RSU implemented in or by the gNB can be referred to as a "gNB-type RSU", and so on. In some specific implementations, the RSU is a computing device coupled to a radio frequency circuit located on the roadside, and the computing device provides connectivity support to passing vehicle UEs 101 (vUE 101). The RSU can also include an internal data storage circuit for storing intersection map geometries, traffic statistics, media, and applications or other software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can operate on the 5.9 GHz direct short-range communication (DSRC) band to provide extremely low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. In addition or alternatively, the RSU can operate on the cellular V2X band to provide the aforementioned low-latency communication and other cellular communication services. In addition or alternatively, the RSU can operate as a Wi-Fi hotspot (2.4 GHz band) or provide connectivity to one or more cellular networks to provide uplink and downlink communication, or both. Some or all of the computing device and the radio frequency circuit of the RSU can be encapsulated in a weather-resistant package suitable for outdoor installation and can include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network, or both.
[0052] Figure 2 An exemplary architecture of system 200 including a first CN 220 is shown. In this example, system 200 can implement the LTE standard such that CN 220 is the EPC 220 corresponding to Figure 1 CN 120. Additionally, UE 201 can be the same as or similar to Figure 1 UE 101, and E-UTRAN 210 can be a RAN that is the same as or similar to Figure 1 RAN 110 and can include the RAN nodes 111 discussed previously. CN 220 can include MEE 221, S-GW 222, packet data network gateway (P-GW) 223, home subscriber server (HSS) function 224, and serving GPRS support node (SGSN) 225.
[0053] The MME 221 can be functionally similar to the control plane of a traditional SGSN and can implement mobility management (MM) functions to keep track of the current location of the UE 201. The MME 221 can perform various mobility management procedures to manage aspects of mobility in access, such as gateway selection and tracking area list management. Mobility management (also referred to as "EPSMM" or "EMM" in the E-UTRAN system) can refer to all applicable procedures, methods, data storage, etc. for maintaining knowledge of the current location of the UE 201, providing user identity confidentiality to the user / subscriber, performing other similar services, or a combination thereof, etc. Each UE 201 and MME 221 can include an EMM sublayer, and when the attachment process is successfully completed, a mobility management context can be established in the UE 201 and MME 221. The mobility management context can be a data structure or database object that stores mobility management-related information of the UE 201. The MME 221 can be coupled to the HSS 224 using the S6a reference point, to the SGSN 225 using the S3 reference point, and to the S-GW 222 using the S11 reference point.
[0054] The SGSN 225 can be a node that serves the UE 201 by tracking the location of the individual UE 201 and performing security functions. In addition, the SGSN 225 can perform inter-EPC node signaling for mobility between 2G / 3G and E-UTRAN 3GPP access networks; PDN and S-GW selection as specified by the MME 221; handling of the UE 201 time zone function as specified by the MME 221; and MME selection for handover to the E-UTRAN 3GPP access network, etc. The S3 reference point between the MME 221 and the SGSN 225 can enable the exchange of user and bearer information for 3GPP indirect access network mobility in the idle state or the active state or both.
[0055] The HSS 224 can include a database for network users, which includes subscription-related information for supporting network entity processing of communication sessions. The EPC 220 can include one or more HSS 224, depending on the number of mobile users, the capacity of the equipment, the organization of the network, or a combination thereof, etc. For example, the HSS 224 can provide support for routing, roaming, authentication, authorization, name / address resolution, location dependency, etc. The S6a reference point between the HSS 224 and the MEE 221 can enable the transmission of subscription and authentication data between the HSS 224 and the MEE 221 for authenticating or authorizing user access to the EPC 220.
[0056] The S-GW 222 can terminate the S1 interface 113 towards the RAN 210 ( Figure 2in “S1-U”), and can route data packets between the RAN 210 and the EPC 220. Additionally, the S-GW 222 can be a local mobility anchor for inter-RAN node handover and can also provide an anchor for inter-3GPP mobility. Other responsibilities can include lawful interception, charging, and enforcement of certain policies. The S11 reference point between the S-GW 222 and the MME 221 can provide a control plane between the MME 221 and the S-GW 222. The S-GW 222 can be coupled to the P-GW 223 using the S5 reference point.
[0057] The P-GW 223 can terminate the SGi interface towards the PDN 230. The P-GW 223 can route data packets between the EPC 220 and an external network such as a network including an application server 130 (sometimes referred to as “AF”) using the IP communication interface 125 (see, for example, Figure 1 ). In some specific implementations, the P-GW 223 can be communicatively coupled to the application server (e.g., Figure 1 ) using the IP communication interface 125 (see, for example, Figure 1 's application server 130 or Figure 2 's PDN 230 in
[0058] ). The S5 reference point between the P-GW 223 and the S-GW 222 can provide user plane tunneling and tunnel management between the P-GW 223 and the S-GW 222. Due to the mobility of the UE 201 and whether the S-GW 222 needs to connect to a non-collocated P-GW 223 for the required PDN connectivity, the S5 reference point can also be used for S-GW 222 relocation. The P-GW 223 can also include a node for policy enforcement and charging data collection (e.g., PCEF (not shown)). Additionally, the SGi reference point between the P-GW 223 and the packet data network (PDN) 230 can be an operator-external public, private PDN, or an internal operator packet data network, for example, to provide IMS services. The P-GW 223 can be coupled to the policy control and charging rules function (PCRF) 226 using the Gx reference point.The PCRF 226 is the policy and charging control element of the EPC 220. In a non-roaming scenario, there may be a single PCRF 226 in the home public land mobile network (HPLMN) associated with the Internet protocol connectivity access network (IP-CAN) session of the UE 201. In a roaming scenario with local traffic breakout, there may be two PCRFs associated with the IP-CAN session of the UE 201: the home PCRF (H-PCRF) in the HPLMN and the visited PCRF (V-PCRF) in the visited public land mobile network (VPLMN). The PCRF 226 can be communicatively coupled to the application server 230 by means of the P-GW 223. The application server 230 can signal the PCRF 226 to indicate a new service flow and select appropriate quality of service (QoS) and charging parameters. The PCRF 226 can configure the rules for a PCEF (not shown) with appropriate traffic flow templates (TFTs) and QoS class identifiers (QCIs) that initiate the QoS and charging specified by the application server 230. The Gx reference point between the PCRF 226 and the P-GW 223 can allow the transfer of QoS policies and charging rules from the PCRF 226 to the PCEF in the P-GW 223. The Rx reference point can reside between the PDN 230 (or "AF 230") and the PCRF 226.
[0059] Figure 3 The architecture of a system 300 including a second CN 320 is shown. The system 300 is shown as including a UE 301, which may be the same as or similar to the previously discussed UE 101 and UE 201; a RAN 310, which may be the same as or similar to the previously discussed RAN 110 and RAN 210 and which may include the previously discussed RAN node 111; and a data network (DN) 303, which may be, for example, a carrier service, Internet access, or a 3rd party service; and a 5GC 320. The 5GC 320 may include an authentication server function (AUSF) 322; an access and mobility management function (AMF) 321; a session management function (SMF) 324; a network exposure function (NEF) 323; a policy control function (PCF) 326; a network repository function (NRF) 325; a unified data management (UDM) function 327; an AF 328; a user plane function (UPF) 302; and a network slice selection function (NSSF) 329.
[0060] The UPF 302 can act as an anchor point for mobility within and between RATs, an external PDU session point interconnected with the DN 303, and a branching point for supporting multi-homed PDU sessions. The UPF 302 can also perform packet routing and forwarding, perform packet inspection, perform the user plane part of policy rules, legally intercept packets (UP collection), perform traffic usage reporting, perform QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), perform transport-level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 302 can include an uplink classifier to support routing traffic flows to data networks. The DN 303 can represent various network operator services, Internet access, or third-party services. The DN 303 can include or be similar to the application server 130 discussed previously. The UPF 302 can interact with the SMF 324 using the N4 reference point between the SMF 324 and the UPF 302.
[0061] The AUSF 322 stores the data for the authentication of the UE 301 and processes authentication-related functions. The AUSF 322 can facilitate a common authentication framework for various access types. The AUSF 322 can communicate with the AMF 321 using the N12 reference point between the AMF 321 and the AUSF 322, and can communicate with the UDM 327 using the N13 reference point between the UDM 327 and the AUSF 322. Additionally, the AUSF 322 can present an Nausf service-based interface.
[0062] The AMF 321 is responsible for registration management (e.g., responsible for registering the UE 301, etc.), connection management, reachability management, mobility management, and legal interception of AMF-related events, as well as access authentication and authorization. The AMF 321 can be the termination point of the N11 reference point between the AMF 321 and the SMF 324. The AMF 321 can provide the transmission of SM messages between the UE 301 and the SMF 324, and act as a transparent proxy for routing SM messages. The AMF 321 can also provide the transmission of SM messages between the UE 301 and the SMSF ( Figure 3The transmission of SMS messages between (not shown in the figure). The AMF 321 can act as a Security Anchor Function (SEAF), which can include interactions with the AUSF 322 and the UE 301 to receive, for example, the intermediate key established due to the UE 301 authentication process. In the case of using Universal Mobile Telecommunications System (UMTS)-based authentication, the AMF 321 can retrieve security material from the AUSF 322. The AMF 321 can also include a Security Context Management (SCM) function that receives keys from the SEAF to derive access network-specific keys. In addition, the AMF 321 can be a termination point of the RAN control plane interface, which can include or be the N2 reference point between the RAN 310 and the AMF 321. In some specific implementations, the AMF 321 can be a termination point of NAS (N1) signaling and perform NAS encryption and integrity protection.
[0063] The AMF 321 can also support NAS signaling with the UE 301 through the N3 Interworking Function (IWF) interface (referred to as "N3IWF"). The N3IWF can be used to provide access to untrusted entities. The N3IWF can be a termination point of the N2 interface between the RAN 310 of the control plane and the AMF 321, and can be a termination point of the N3 reference point between the RAN 310 of the user plane and the UPF 302. Therefore, the AMF 321 can handle N2 signaling for PDU sessions and QoS from the SMF 324 and the AMF 321, encapsulate / decapsulate packets for IPSec and N3 tunnels, mark N3 user plane packets on the uplink, and perform QoS corresponding to the N3 packet marking, taking into account the QoS requirements associated with such markings received through the N2. The N3IWF can also relay uplink and downlink control plane NAS signaling between the UE 301 and the AMF 321 using the N1 reference point between the UE 301 and the AMF 321, and relay uplink and downlink user plane packets between the UE 301 and the UPF 302. The N3IWF also provides a mechanism for establishing an IPsec tunnel with the UE 301. The AMF 321 can present a service-based interface based on Namf and can be a termination point of the N14 reference point between two AMF 321s and the N17 reference point between the AMF 321 and the 5G Equipment Identity Register (EIR) ( Figure 3 not shown).
[0064] The UE 301 can register with the AMF 321 to receive network services. Registration Management (RM) is used to register the UE 301 with the network (e.g., AMF 321) or deregister the UE 301, and establish a UE context in the network (e.g., AMF 321). The UE 301 can operate in the RM-REGISTERED state or the RM-DEREGISTERED state. In the RM DEREGISTERED state, the UE 301 is not registered with the network, and the UE context in the AMF 321 does not hold the valid location or routing information of the UE 301, so the AMF 321 cannot reach the UE 301. In the RM REGISTERED state, the UE 301 is registered with the network, and the UE context in the AMF 321 can hold the valid location or routing information of the UE 301, so the AMF 321 can reach the UE 301. In the RM-REGISTERED state, the UE 301 can execute a mobility registration update procedure, execute a periodic registration update procedure triggered by the expiration of a periodic update timer (e.g., to notify the network that the UE 301 is still active), and execute a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.
[0065] The AMF 321 can store one or more RM contexts for the UE 301, where each RM context is associated with a specific access to the network. The RM context can be, for example, a data structure or a database object, etc., which indicates or stores the registration status and periodic update timer for each access type. The AMF 321 can also store a 5GC Mobility Management (MM) context that can be the same as or similar to the previously discussed (E)MM context. In some specific implementations, the AMF 321 can store the coverage enhancement mode B restriction parameters of the UE 301 in the associated MM context or RM context. The AMF 321 can also derive values from the UE usage setting parameters that have been stored in the UE context (and / or MM / RM context) when needed.
[0066] Connection Management (CM) can be used to establish and release a signaling connection between the UE 301 and the AMF 321 over the N1 interface. The signaling connection is used to enable NAS signaling exchange between the UE 301 and the CN 320, and includes a signaling connection between the UE and the AN (e.g., an RRC connection for non-3GPP access or a UE-N3IWF connection) and an N2 connection of the UE 301 between the AN (e.g., the RAN 310) and the AMF 321. In some specific implementations, the UE 301 can operate under one of two CM modes (CM-IDLE mode or CM-CONNECTED mode). When the UE 301 operates in the CM-IDLE mode, the UE 301 may not have a NAS signaling connection established with the AMF 321 over the N1 interface, and there may be a RAN 310 signaling connection for the UE 301 (e.g., an N2 or N3 connection or both). When the UE 301 operates in the CM-CONNECTED mode, the UE 301 may have a NAS signaling connection established with the AMF 321 over the N1 interface, and there may be a RAN 310 signaling connection for the UE 301 (e.g., an N2 and / or N3 connection). Establishing an N2 connection between the RAN 310 and the AMF 321 may cause the UE 301 to transition from the CM-IDLE mode to the CM-CONNECTED mode, and when the N2 signaling between the RAN 310 and the AMF 321 is released, the UE 301 may transition from the CM-CONNECTED mode to the CM-IDLE mode.
[0067] The SMF 324 may be responsible for session management (SM), such as session establishment, modification, and release, including the maintenance of tunnels between the UPF and the AN node; UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuration of traffic steering at the UPF to route traffic to the correct destination; termination of the interface towards the policy control function; the policy enforcement and the control part of QoS; lawful interception (for SM events and the interface with the LI system); termination of the SM part of NAS messages; downlink data notification; initiating the sending of AN-specific SM information to the AN via N2 using the AMF; and determination of the SSC mode of the session. SM may refer to the management of PDU sessions, and a PDU session (or "session") may refer to a PDU connectivity service that provides or enables PDU exchange between the UE 301 and a data network (DN) 303 identified by a data network name (DNN). A PDU session may be established upon request by the UE 301 using NAS SM signaling exchanged between the UE 301 and the SMF 324 via the N1 reference point, modified upon request by the UE 301 and the 5GC 320, and released upon request by the UE 301 and the 5GC 320. When requested from an application server, the 5GC 320 may trigger a specific application in the UE 301. In response to receiving the trigger message, the UE 301 may deliver the trigger message (or relevant parts / information of the trigger message) to one or more identified applications in the UE 301. The identified applications in the UE 301 may establish a PDU session to a specific DNN. The SMF 324 may check whether the UE 301 request complies with the user subscription information associated with the UE 301. In this regard, the SMF 324 may retrieve and / or request to receive an update notification on the subscription data at the SMF 324 level from the UDM 327.
[0068] The SMF 324 may include some or all of the following roaming functions: handling local execution to apply the QoS service level agreement (SLA) (e.g., in the VPLMN); charging data collection and charging interface (e.g., in the VPLMN); lawful interception (e.g., SM events and the interface with the LI system in the VPLMN); and supporting interaction with an external DN to transmit signaling for PDU session authorization / authentication via the external DN. The N16 reference point between two SMF 324s may be included in the system 300, which may be between another SMF 324 in the visited network and the SMF 324 in the home network in a roaming scenario. Additionally, the SMF324 may present an Nsmf service-based interface.
[0069] The NEF 323 can provide components for securely exposing services and capabilities provided by 3GPP network functions to third parties, internal exposure / re-exposure, application functions (e.g., AF 328), edge computing or fog computing systems, etc. In some specific implementations, the NEF 323 can authenticate, authorize, and / or throttle the AF. The NEF 323 can also transform the information exchanged with the AF 328 and the information exchanged with internal network functions. For example, the NEF 323 can transform between an AF service identifier and internal 5GC information. The NEF 323 can also receive information from other network functions (NFs) based on the exposure capabilities of the other NFs. This information can be stored at the NEF 323 as structured data, or stored at a data storage NF using a standardized interface. Then, the stored information can be re-exposed by the NEF 323 to other NFs and AFs, or used for other purposes such as analysis, or both. Additionally, the NEF323 can present an interface based on Nnef services.
[0070] The NRF 325 can support service discovery functions, receive NF discovery requests from NF instances, and provide information about the discovered NF instances to the NF instances. The NRF 325 also maintains information about available NF instances and the services supported by these instances. As used herein, terms such as "instantiation" etc. can refer to the creation of an instance, and an "instance" can refer to a specific occurrence of an object, which can occur, for example, during the execution of program code. Additionally, the NRF 325 can present an interface based on Nnrf services.
[0071] The PCF 326 can provide control plane functions for executing their policy rules, and can also support a unified policy framework for managing network behavior. The PCF 326 can also implement a front end to access subscription information related to policy decisions in the unified data repository (UDR) of the UDM 327. The PCF 326 can communicate with the AMF 321 using the N15 reference point between the PCF 326 and the AMF 321, which can include the PCF 326 in a visited network and the AMF 321 in a roaming scenario. The PCF 326 can communicate with the AF 328 using the N5 reference point between the PCF 326 and the AF 328; and communicate with the SMF 324 using the N7 reference point between the PCF 326 and the SMF 324. The system 300 or the CN 320 or both can also include an N24 reference point between the PCF 326 (in the home network) and the PCF 326 (in a visited network). Additionally, the PCF 326 can present an interface based on Npcf services.
[0072] The UDM 327 can process subscription-related information to support the handling of communication sessions by network entities and can store the subscription data of the UE 301. For example, the subscription data can be transmitted between the UDM 327 and the AMF 321 using the N8 reference point between the UDM 327 and the AMF. The UDM 327 can include two parts: an application front end and a UDR ( Figure 3 The front end and the UDR are not shown). The UDR can store the subscription data and policy data of the UDM 327 and the PCF 326, or the structured data for exposure and application data of the NEF 323 (including the PFD for application detection, the application request information of multiple UEs 301), or both. The Nudr service-based interface can be presented by the UDR 221 to allow the UDM 327, the PCF 326, and the NEF 323 to access a specific set of the stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM can include a UDM front end, which is responsible for handling credentials, location management, subscription management, etc. In different transactions, several different front ends can serve the same user. The UDM front end 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 324 using the N10 reference point between the UDM 327 and the SMF 324. The UDM 327 can also support SMS management, where the SMS front end implements application logic similar to that discussed previously. Additionally, the UDM 327 can present a Nudm service-based interface.
[0073] The AF 328 can provide the impact of the application on traffic routing, provide access to network capability exposure (NCE), and interact with the policy framework for policy control. The NCE can be a mechanism that allows the 5GC 320 and the AF 328 to provide information to each other using the NEF 323, which can be used for edge computing implementations. In such implementations, the network operator and third-party services can be hosted near the attachment point of the UE 301 to achieve effective service delivery with reduced end-to-end latency and load on the transport network. For edge computing implementations, the 5GC can select a UPF 302 near the UE 301 and perform traffic steering from the UPF 302 to the DN 303 using the N6 interface. This can be based on the UE subscription data, the UE location, and the information provided by the AF 328. In this way, the AF 328 can affect the UPF (re)selection and traffic routing. Based on the operator deployment, when the AF 328 is considered a trusted entity, the network operator can allow the AF 328 to directly interact with the relevant NF. Additionally, the AF 328 can present a Naf service-based interface.
[0074] The NSSF 329 selects a set of network slice instances that can serve the UE 301. If needed, the NSSF 329 can also determine the allowed NSSAI and the mapping to the subscribed single network slice selection assistance information (S-NSSAI). The NSSF 329 can also determine, based on appropriate configuration and possibly by querying the NRF 325, a set of AMFs or a list of candidate AMFs 321 for serving the UE 301. The selection of a set of network slice instances for the UE 301 can be triggered by the AMF 321, where the UE 301 registers by interacting with the NSSF 329, which can cause a change in the AMF 321. The NSSF 329 can interact with the AMF 321 using the N22 reference point between the AMF 321 and the NSSF 329; and can communicate with another NSSF 329 in the visited network using the N31 reference point ( Figure 3 not shown). Additionally, the NSSF 329 can expose an Nnssf service-based interface.
[0075] As previously discussed, the CN 320 can include an SMSF, which can be responsible for SMS subscription checking and verification and relaying SM messages to or from the UE 301 to or from other entities such as SMS-GMSC / IWMSC / SMS routers. The SMS can also interact with the AMF 321 and the UDM 327 for a notification procedure that the UE 301 can use for SMS transmission (e.g., setting the UE unreachable flag and notifying the UDM 327 when the UE 301 is available for SMS).
[0076] In some embodiments, there can be additional or alternative reference points or service-based interfaces, or both, between network function services in the network functions. However, for clarity, Figure 3 these interfaces and reference points are omitted. In one example, the CN 320 can include an Nx interface, which is an inter-CN interface between an MME (e.g., MME 221) and the AMF 321 to enable interworking between the CN 320 and the CN 220. Other exemplary interfaces or reference points can include an N5g-EIR service-based interface exposed by the 5G-EIR, an N27 reference point between the NRF in the visited network and the NRF in the home network, or an N31 reference point between the NSSF in the visited network and the NSSF in the home network, etc.
[0077] In some specific implementations, the components of CN 220 can be implemented in one physical node or separate physical nodes and can include components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some specific implementations, the components of CN 320 can be implemented in the same or a similar manner as those discussed herein with respect to the components of CN 220. In some specific implementations, NFV is used to virtualize any one or all of the above network node functions using executable instructions stored in one or more computer-readable storage media, as described in further detail below. The logical instantiation of CN 220 can be referred to as a network slice, and each logical instantiation of CN 220 can provide specific network capabilities and network characteristics. A logical instantiation of a part of CN 220 can be referred to as a network sub-slice, which can include P-GW 223 and PCRF 226.
[0078] As used herein, terms such as "instantiation" can refer to the creation of an instance, and an "instance" can refer to a specific occurrence of an object, which can occur, for example, during the execution of program code. A network instance can refer to information identifying a domain, which can be used for service 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 the resources (e.g., computing, storage, and network resources) required to deploy a network slice.
[0079] Regarding the 5G system (see, for example Figure 3 ), a network slice can include a RAN part and a CN part. Support for network slices relies on the principle that traffic for different slices is handled by different PDU sessions. The network can implement different network slices by scheduling or by providing different L1 / L2 configurations or both. If provided by the NAS, UE 301 provides auxiliary information for network slice selection in an appropriate RRC message. Although the network can support a large number of slices, in some specific implementations, the UE does not need to support more than 8 slices simultaneously.
[0080] A network slice may include a CN 320 control plane and user plane NFs, an NG-RAN 310 in the serving PLMN, and an N3IWF function in the serving PLMN. Each network slice may have a different S-NSSAI or a different SST, or both. The NSSAI includes one or more S-NSSAIs, and each network slice is uniquely identified by an S-NSSAI. The network slices may differ in terms of supported features and network function optimizations. In some specific implementations, multiple network slice instances may deliver the same service or feature, but for different groups of UEs 301 (e.g., enterprise users). For example, each network slice may deliver different promised services or may be dedicated to a specific customer or enterprise, or both. In this example, each network slice may have a different S-NSSAI with the same SST but with different slice differentiators. Additionally, a single UE may be served simultaneously by one or more network slice instances using a 5G AN, and the UE may be associated with eight different S-NSSAIs. Furthermore, an AMF 321 instance serving a single UE 301 may belong to each network slice instance serving that UE.
[0081] Network slicing in the NG-RAN 310 involves RAN slice awareness. RAN slice awareness includes differentiated handling of traffic for different network slices that have been preconfigured. Slice awareness in the NG-RAN 310 is introduced at the PDU session level by indicating the S-NSSAI corresponding to the PDU session in all signaling including PDU session resource information. How the NG-RAN 310 supports enabling slicing in terms of NG-RAN functions (e.g., including a set of network functions for each slice) depends on the specific implementation. The NG-RAN 310 uses auxiliary information provided by the UE 301 or the 5GC 320 to select the RAN part of the network slice, and this auxiliary information uniquely identifies one or more network slices among the preconfigured network slices in the PLMN. The NG-RAN 310 also supports resource management and policy enforcement between slices according to the SLA. A single NG-RAN node may support multiple slices, and the NG-RAN 310 may also appropriately apply appropriate RRM policies for the SLA to each supported slice. The NG-RAN 310 also supports QoS differentiation within a slice.
[0082] The NG-RAN 310 may also use UE assistance information to select the AMF 321 (if available) during the initial attachment. The NG-RAN 310 uses the assistance information to route the initial NAS to the AMF 321. If the NG-RAN 310 cannot use the assistance information to select the AMF 321, or the UE 301 does not provide any such information, the NG-RAN 310 sends the NAS signaling to the default AMF 321, which may be in the AMF 321 pool. For subsequent accesses, the UE 301 provides the temporary ID assigned to the UE 301 by the 5GC 320 to enable the NG-RAN 310 to route the NAS message to the appropriate AMF 321, as long as the temporary ID is valid. The NG-RAN 310 knows and can reach the AMF 321 associated with the temporary ID. Otherwise, the method for initial attachment is applied.
[0083] The NG-RAN 310 supports resource isolation between slices. The NG-RAN 310 resource isolation can be achieved through RRM policies and protection mechanisms, which should avoid shared resource shortages in cases where the service-level agreement of one slice is interrupted in another slice. In some specific implementations, the NG-RAN 310 resources can be fully assigned to a certain slice. How the NG-RAN 310 supports resource isolation depends on the specific implementation.
[0084] Some slices may be only partially available in the network. The NG-RAN 310 knows that the slices supported in its neighboring cells may be beneficial for inter-frequency mobility in the connected mode. Within the registration area of the UE, the slice availability may not change. The NG-RAN 310 and the 5GC 320 are responsible for handling service requests for slices that may or may not be available in a given area. Permitting or denying access to a slice may depend on factors such as the support for the slice, the availability of resources, and the support of the NG-RAN 310 for the requested service.
[0085] The UE 301 may be associated with multiple network slices simultaneously. In the case where the UE 301 is associated with multiple slices simultaneously, only one signaling connection is maintained, and for intra-frequency cell reselection, the UE 301 attempts to pre-empt the best cell. For inter-frequency cell reselection, dedicated priorities can be used to control the frequencies pre-empted by the UE 301. The 5GC 320 will verify that the UE 301 has the right to access the network slices. Before receiving the initial context setup request message, based on knowing the specific slice that the UE 301 is requesting access to, the NG-RAN 310 may be allowed to apply some temporary or local policies. During the initial context setup, the slice that is requesting its resources is notified to the NG-RAN 310.
[0086] Figure 4 An example of infrastructure equipment 400 is shown. The infrastructure equipment 400 (or "system 400") can be implemented as a base station, a radio headend, a RAN node (such as the RAN node 111 shown and described previously), an application server 130, or any other component or device discussed herein. In other examples, the system 400 can be implemented in or by a UE.
[0087] The system 400 includes: an application circuit 405, a baseband circuit 410, one or more radio frequency front-end modules (RFEMs) 415, a memory circuit 420, a power management integrated circuit (PMIC) 425, a power triple circuit 430, a network controller circuit 435, a network interface connector 440, a satellite positioning circuit 445, and a user interface circuit 450. In some specific implementations, the system 400 can include additional elements, such as for example a memory, a storage device, a display, a camera, one or more sensors or input / output (I / O) interfaces, or a combination thereof, etc. In other examples, the components described with reference to the system 400 can be included in more than one device. For example, various circuits can be separately included in more than one device for CRAN, vBBU, or other specific implementations.
[0088] The application circuit 405 can include circuits, such as but not limited to one or more processors (or processor cores), a cache memory, one or more of the following: a low dropout regulator (LDO), an interrupt controller, a serial interface such as SPI, I2C, or a general-purpose programmable serial interface module, a real-time clock (RTC), a timer-counter including an interval timer and a watchdog timer, general-purpose input / output (I / O or IO), a memory card controller such as a secure digital (SD) multimedia card (MMC), a universal serial bus (USB) interface, a mobile industry processor interface (MIPI) interface, and a joint test access group (JTAG) test access port. The processor (or core) of the application circuit 405 can be coupled to or can include a memory or a storage element, and can be configured to execute instructions stored in the memory or the storage element to enable various application programs or operating systems to run on the system 400. In some specific implementations, the memory or the storage element can include an on-chip memory circuit, which can include any suitable volatile or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, or a combination thereof, and other types of memory.
[0089] The processor of application circuit 405 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 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 a combination thereof, etc. In some specific implementations, application circuit 405 may include or may be a dedicated processor or controller configured to execute the various techniques described herein. In some specific implementations, system 400 may not utilize application circuit 405, and instead may include a dedicated processor or controller to process, for example, IP data received from the EPC or 5GC.
[0090] In some specific implementations, application circuit 405 may include one or more hardware accelerators, which may be a microprocessor, a programmable processing device, etc. The one or more hardware accelerators may include, for example, a computer vision (CV) or deep learning (DL) accelerator or both. In some specific implementations, the programmable processing device may be: one or more field programmable devices (FPDs), such as field programmable gate arrays (FPGAs), etc.; programmable logic devices (PLDs), such as complex PLDs (CPLDs) or high-capacity PLDs (HCPLDs); ASICs, such as structured ASICs; programmable system-on-chips (PSoCs), or a combination thereof, etc. In such specific implementations, the circuit of application circuit 405 may include logic blocks or a logic architecture, and other interconnected resources that can be programmed to perform various functions such as the processes, methods, and functions described herein. In some specific implementations, the circuit of application circuit 405 may include memory units (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM) or antifuse)) for storing logic blocks, logic architectures, data, or other data in a look-up table (LUT), etc.
[0091] The user interface circuit 450 may include one or more user interfaces designed to enable a user to interact with the system 400 or a peripheral component interface, which is designed to enable a peripheral component to interact with the system 400. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., a light-emitting diode (LED)), a physical keyboard or keypad, a mouse, a touchpad, a touch screen, a speaker or other audio emitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, or a combination thereof, etc. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power interface, etc.
[0092] The radio front-end module (RFEM) 415 may include a millimeter-wave (mmWave) RFEM and one or more sub-mmWave radio frequency integrated circuits (RFICs). In some embodiments, the one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays (see, for example Figure 6 the antenna array 611), and the RFEM may be connected to multiple antennas. In some embodiments, the radio functions of both millimeter-wave and sub-millimeter-wave may be implemented in the same physical RFEM 415 that combines millimeter-wave antennas and sub-millimeter-wave. The baseband circuit 410 may be implemented as, for example, a soldered-in substrate, including one or more integrated circuits, a single-package integrated circuit soldered to the main circuit board, or a multi-chip module containing two or more integrated circuits.
[0093] The memory circuit 420 may include one or more of the following: volatile memory, such as dynamic random access memory (DRAM) or synchronous dynamic random access memory (SDRAM); and non-volatile memory (NVM), such as high-speed electrically erasable memory (commonly known as flash memory), phase change random access memory (PRAM), or magnetoresistive random access memory (MRAM), or a combination thereof, etc. For example, the memory circuit 420 may be implemented as one or more of the following: a soldered-in package integrated circuit, a socketed memory module, and a plug-in memory card.
[0094] The PMIC 425 may include voltage regulators, surge protectors, power alert detection circuits, and one or more backup power sources, such as batteries or capacitors. The power alert detection circuit may detect one or more of power-down (undervoltage) and surge (overvoltage) conditions. The power pass-through circuit 430 may provide power extracted from a network cable to provide both power and data connection to the infrastructure equipment 400 using a single cable.
[0095] The network controller circuit 435 may provide connectivity to the network using a standard network interface protocol such as Ethernet, Ethernet based on a GRE tunnel, Ethernet based on Multi-Protocol Label Switching (MPLS), or some other suitable protocol. Network connectivity may be provided to and from the infrastructure equipment 400 using a network interface connector 440 using a physical connection, which may be an electrical connection (commonly referred to as a "copper interconnect"), an optical connection, or a wireless connection. The network controller circuit 435 may include one or more dedicated processors or FPGAs, or both, for communicating using one or more of the aforementioned protocols. In some implementations, the network controller circuit 435 may include multiple controllers for providing connectivity to other networks using the same or different protocols.
[0096] The positioning circuit 445 includes circuits for receiving and decoding signals transmitted or broadcast by a positioning network of a global navigation satellite system (GNSS). Examples of GNSS include the United States' Global Positioning System (GPS), Russia's 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., using the Indian constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbit Chart and Satellite Integrated Radio Positioning (DORIS) for navigation), etc. The positioning circuit 445 may include various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. for facilitating OTA communications) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some specific implementations, the positioning circuit 445 may include a micro technology (micro PNT) IC for positioning, navigation, and timing that uses a master timing clock to perform position tracking and estimation without GNSS assistance. The positioning circuit 445 may also be part of or interact with the baseband circuit 410 or the RFEM 415 or both to communicate with nodes and components of the positioning network. The positioning circuit 445 may also provide data (e.g., location data, time data) to the application circuit 405, which may use the data to synchronize operations with various infrastructures (e.g., RAN node 111, etc.).
[0097] Figure 5An example of platform 500 (or "device 500") is shown. In some specific implementations, computer platform 500 may be adapted to be used as UE 101, 201, 301, application server 130, or any other component or device discussed herein. Platform 500 may include any combination of the components shown in the example. The components (or portions thereof) of platform 500 may be implemented as integrated circuits (ICs), discrete electronic devices, or other modules, logic, hardware, software, firmware, or combinations thereof adapted within computer platform 500, or as components otherwise incorporated within the chassis of a larger system. Figure 5 The block diagram of is intended to show a high-level view of the components of platform 500. However, in some specific implementations, platform 500 may include fewer, additional, or alternative components, or Figure 5 different arrangements of the components shown.
[0098] Application circuit 505 includes circuitry such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of an LDO, interrupt controller, serial interface (such as SPI), I2C or general programmable serial interface module, RTC, timer-counter (including interval timer and watchdog timer), general-purpose I / O, memory card controller (such as SD MMC or similar controller), USB interface, MIPI interface, and JTAG test access port. The processor (or core) of application circuit 505 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in memory or storage to enable various applications or operating systems to run on system 500. In some specific implementations, the memory or storage elements may be on-chip memory circuitry that may include any suitable volatile or non-volatile memory such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, or combinations thereof, and other types of memory.
[0099] The processor of application circuit 505 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, some other known processing elements, or any suitable combination thereof. In some specific embodiments, application circuit 405 may include or may be a dedicated processor / controller for performing the techniques described herein. In some specific embodiments, application circuit 505 may be part of a system-on-chip (SoC), where application circuit 505 and other components are formed as a single integrated circuit or a single package.
[0100] In some specific embodiments, application circuit 505 may include: circuitry such as, but not limited to, one or more field programmable devices (FPDs) such as FPGAs; PLDs such as CPLDs, HCPLDs; ASICs such as structured ASICs; PSoCs, or combinations thereof, etc. In some specific embodiments, application circuit 505 may include logic blocks or logic architectures, and other interconnected resources that can be programmed to perform various functions such as the processes, methods, functions described herein. In some specific embodiments, application circuit 505 may include memory units for storing logic blocks, logic structures, data, or other data in LUTs, etc., such as EPROMs, EEPROMs, flash memories, static memories (such as SRAM or antifuses).
[0101] Baseband circuit 510 may be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module that includes two or more integrated circuits. Refer to Figure 6 Discuss the various hardware electronic components of baseband circuit 510.
[0102] RFEM 515 may include a millimeter wave (mmWave) RFEM and one or more sub-millimeter wave RFICs. In some specific embodiments, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays (see, for example, Figure 6 antenna array 611), and the RFEM may be connected to multiple antennas. In some specific embodiments, the radio functions of both millimeter wave and sub-millimeter wave may be implemented in the same physical RFEM 515 that combines both millimeter wave antennas and sub-millimeter wave. In some specific embodiments, RFEM 515, baseband circuit 510, or both are included in the transceiver of platform 500.
[0103] Memory circuit 520 may include any number and type of memory devices for providing a given amount of system memory. For example, memory circuit 520 may include one or more of volatile memory (such as RAM, DRAM, or SDRAM) and NVM (such as high-speed electrically erasable memory (commonly referred to as flash memory), PRAM, or MRAM), or a combination thereof, etc. In a low-power implementation, memory circuit 520 may be on-chip memory or registers associated with application circuit 505. To provide persistent storage of information such as data, application programs, operating systems, etc., memory circuit 520 may include one or more mass storage devices, which may include, for example, solid-state drives (SSDs), hard disk drives (HDDs), micro-HDDs, resistive change memories, phase change memories, holographic memories, or chemical memories, etc.
[0104] Removable memory circuit 523 may include devices, circuits, enclosures, housings, ports, or sockets, etc. for coupling a portable data storage device to platform 500. These portable data storage devices may be used for mass storage and may include, for example, flash memory cards (such as Secure Digital (SD) cards, micro SD cards, xD Picture Cards), as well as USB flash drives, optical discs, or external HDDs, or a combination thereof, etc. Platform 500 may also include interface circuitry (not shown) for connecting external devices to platform 500. External devices connected to platform 500 using this interface circuitry include sensor circuit 521 and electromechanical components (EMC) 522, as well as removable memory devices coupled to removable memory circuit 523.
[0105] Sensor circuit 521 includes devices, modules, or subsystems intended to detect events or changes in its environment and send information about the detected events (such as sensor data) to one or more other devices, modules, or subsystems. Examples of such sensors include: inertial measurement units (IMUs), such as accelerometers, gyroscopes, or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including three-axis accelerometers, three-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (such as thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (such as cameras or lensless apertures); light detection and ranging (LiDAR) sensors; proximity sensors (such as infrared radiation detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers; microphones or other audio capture devices, or a combination thereof, etc.
[0106] The EMC 522 includes devices, modules, or subsystems that are intended to enable the platform 500 to change its state, position, or orientation, or to move or control mechanisms, systems, or subsystems. Additionally, the EMC 522 can be configured to generate messages or signaling and send messages or signaling to other components of the platform 500 to indicate the current state of the EMC 522. Examples of the EMC 522 include, among other electromechanical components, one or more power switches, relays (such as electromechanical relays (EMRs) or solid-state relays (SSRs)), actuators (e.g., valve actuators), audible sound generators, visual warning devices, motors (e.g., DC motors or stepper motors), wheels, thrusters, propellers, claws, clamps, hooks, or combinations thereof. In some particular implementations, the platform 500 is configured to operate one or more EMC 522s based on one or more capture events, instructions, or control signals received from a service provider or a client or both.
[0107] In some particular implementations, the interface circuit can connect the platform 500 to the positioning circuit 545. The positioning circuit 545 includes circuitry for receiving and decoding signals transmitted or broadcast by the positioning network of GNSS. The positioning circuit 545 includes various hardware elements (e.g., including hardware devices for facilitating OTA communication such as switches, filters, amplifiers, antenna elements, etc.) to communicate with components of the positioning network such as nodes of the navigation satellite constellation. In some particular implementations, the positioning circuit 545 can include a micro PNT IC that uses a primary timing clock to perform position tracking or estimation without GNSS assistance. The positioning circuit 545 can also be part of or interact with the baseband circuit 510 or the RFEM 515 or both to communicate with nodes and components of the positioning network. The positioning circuit 545 can also provide data (e.g., position data, time data) to the application circuit 505, which can use the data to synchronize operations with various infrastructure (e.g., radio base stations) for turn-by-turn navigation applications and the like.
[0108] In some embodiments, the interface circuit may connect the platform 500 to a Near Field Communication (NFC) circuit 540. The NFC circuit 540 is configured to provide contactless short-range communication based on Radio Frequency Identification (RFID) standards, where magnetic field sensing is used to enable communication between the NFC circuit 540 and an NFC-enabled device external to the platform 500 (e.g., an "NFC contact point"). The NFC circuit 540 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller may be a chip or IC that provides NFC functionality to the NFC circuit 540 by executing NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to transmit short-range RF signals. The RF signals may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transfer stored data to the NFC circuit 540, or initiate data transfer between the NFC circuit 540 and another active NFC device (e.g., a smart phone or an NFC-enabled POS terminal) near the platform 500.
[0109] The driver circuit 546 may include software and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the platform 500. The driver circuit 546 may include various drivers, thereby allowing other components of the platform 500 to interact with or control various input / output (I / O) devices that may be present within or connected to the platform 500. For example, the driver circuit 546 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 500, a sensor driver for obtaining sensor readings from the sensor circuit 521 and controlling and allowing access to the sensor circuit 521, an EMC driver for obtaining the actuator position of the EMC 522 or controlling and allowing access to the EMC 522, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.
[0110] A Power Management Integrated Circuit (PMIC) 525 (also referred to as "power management circuit 525") may manage the power provided to various components of the platform 500. Specifically, with respect to the baseband circuit 510, the PMIC 525 may control power selection, voltage scaling, battery charging, or DC-DC conversion. The PMIC 525 may be included when the platform 500 is capable of being powered by a battery 530, e.g., when the device is included in the UE 101, 201, 301.
[0111] In some specific implementations, the PMIC 525 can control or otherwise be part of various power-saving mechanisms of the platform 500. For example, if the platform 500 is in the RRC_CONNECTED state, in which the platform is still connected to the RAN node because it expects to receive traffic soon, then after a period of inactivity, the platform can enter a state called discontinuous reception mode (DRX). During this state, the platform 500 can power down at short intervals, thus saving power. If there is no data traffic activity for a relatively long period of time, the platform 500 can transition to the RRC_IDLE state, in which it is disconnected from the network and does not perform operations such as channel quality feedback or handover. This can allow the platform 500 to enter a very low-power state, in which it wakes up periodically to listen for the network and then powers down again. In some specific implementations, the platform 500 cannot receive data in the RRC_IDLE state but must transition back to the RRC_CONNECTED state to receive data. Additional power-saving modes can cause the device to be unable to use the network for longer than the paging interval (ranging from a few seconds to several hours). During this period, the device may not be able to connect to the network and may power down completely. Any data sent during this period may experience significant latency, and it is assumed that the latency is acceptable.
[0112] The battery 530 can power the platform 500, but in some specific implementations, the platform 500 can be deployed in a fixed location and can have a power source coupled to the power grid. The battery 530 can be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, or a lithium-air battery, etc. In some specific implementations, such as in V2X applications, the battery 530 can be a typical lead-acid automotive battery.
[0113] In some specific implementations, the battery 530 can be a "smart battery" that includes or is coupled to a battery management system (BMS) or a battery monitoring integrated circuit. The BMS can be included in the platform 500 to track the state of charge (SoCh) of the battery 530. The BMS can be used to monitor other parameters of the battery 530, such as the state of health (SoH) and the state of function (SoF) of the battery 530 to provide fault prediction. The BMS can transmit information about the battery 530 to the application circuit 505 or other components of the platform 500. The BMS can also include an analog-to-digital (ADC) converter that allows the application circuit 505 to directly monitor the voltage of the battery 530 or the current from the battery 530. Battery parameters can be used to determine actions that the platform 500 can perform, such as transmission frequency, network operation, sensing frequency, etc.
[0114] The user interface circuit 550 includes various input / output (I / O) devices that are present within or connected to the platform 500, and includes one or more user interfaces designed to implement user interaction with the platform 500 or a peripheral component interface designed to implement interaction with peripheral components of the platform 500. The user interface circuit 550 includes input device circuitry and output device circuitry. The input device circuitry includes any physical or virtual device for accepting input, including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, or a headset, or a combination thereof, etc. The output device circuitry includes any physical or virtual device for displaying information or otherwise communicating information (such as sensor readings, actuator positions, or other information). The output device circuitry may include any number or combination of audio or visual displays, including one or more simple visual outputs or indicators (e.g., binary state indicators (e.g., light-emitting diodes (LEDs))), multi-character visual outputs, or more complex outputs, such as a display device or a touch screen (e.g., a liquid crystal display (LCD), an LED display, a quantum dot display, or a projector), where the output of characters, graphics, or multimedia objects is generated or produced by the operation of the platform 500. The output device circuitry may also include a speaker or other audio emitting device, or a printer. In some specific implementations, the sensor circuit 521 may be used as input device circuitry (e.g., an image capture device, or a motion capture device) and one or more EMCs may be used as output device circuitry (e.g., an actuator for providing haptic feedback). In another example, an NFC circuit may be included to read an electronic tag or connect to another NFC-enabled device, and the NFC circuit includes an NFC controller and a processing device coupled to an antenna element. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a USB port, an audio jack, or a power interface.
[0115] Figure 6 Exemplary components of the baseband circuit 610 and the radio frequency front-end module (RFEM) 615 are shown. The baseband circuit 610 may correspond respectively to Figure 4 the baseband circuit 410 of Figure 5 and Figure 4 the RFEM 415 of Figure 5 and the RFEM 515 of
[0116] The baseband circuit 610 includes circuitry configured to perform various radio or network protocols and control functions that enable communication with one or more radio networks using the RF circuit 606. The radio control functions may include, but are not limited to, signal modulation and demodulation, encoding and decoding, and radio frequency shifting. In some embodiments, the modulation and demodulation circuitry of the baseband circuit 610 may include fast Fourier transform (FFT), precoding, or constellation mapping and demapping functions. In some embodiments, the encoding and decoding circuitry of the baseband circuit 610 may include convolutional, tail-biting convolutional, turbo, Viterbi, or low density parity check (LDPC) encoder and decoder functions. The modulation and demodulation and encoder and decoder functions are not limited to these examples and may include other suitable functions in other examples. The baseband circuit 610 is configured to process baseband signals received from the receive signal path of the RF circuit 606 and generate baseband signals for the transmit signal path of the RF circuit 606. The baseband circuit 610 is configured to interact with application circuitry (e.g., Figure 4 and Figure 5 the application circuitry 405, 505 shown in
[0117] to generate and process baseband signals and control the operation of the RF circuit 606. The baseband circuit 610 may process various radio control functions.
[0118] The foregoing circuitry and control logic components of the baseband circuit 610 may include one or more single-core or multi-core processors. For example, the one or more processors may include a 3G baseband processor 604A, a 4G or LTE baseband processor 604B, a 5G or NR baseband processor 604C, or some other baseband processor 604D for other existing, under development, or future generations (e.g., sixth generation (6G)). In some embodiments, some or all of the functions of the baseband processors 604A-D may be included in modules stored in the memory 604G and executed using one or more processors such as a central processing unit (CPU) 604E. In some embodiments, some or all of the functions of the baseband processors 604A-D may be provided as hardware accelerators (e.g., FPGA or ASIC) loaded with appropriate bitstreams or logic blocks stored in corresponding memory units. In some embodiments, the memory 604G may store program code for a real-time OS (RTOS) that, when executed by the CPU 604E (or other processor), causes the CPU 604E (or other processor) to manage the resources of the baseband circuit 610, schedule tasks, or perform other operations. In some embodiments, the baseband circuit 610 includes one or more audio digital signal processors (DSPs) 604F. The audio DSP 604F may include elements for compression and decompression and echo cancellation and may include other suitable processing elements in some embodiments.In some specific embodiments, each of the processors 604A - 604E includes a corresponding memory interface to send data to and receive data from the memory 604G. The baseband circuit 610 may also include one or more interfaces for communicatively coupling to other circuits or devices, such as an interface for sending data to and receiving data from a memory external to the baseband circuit 610; an application circuit interface for sending data to and receiving data from the application circuits 405, 505 of Figure 4 and Figure 5 ; an RF circuit interface for sending data to and receiving data from the RF circuit 606 of Figure 6 ; a wireless hardware connection interface for sending data to and receiving data from one or more wireless hardware elements (e.g., near - field communication (NFC) components, low - power components, Wi - Fi components, etc.); and a power management interface for sending power or control signals to and receiving power or control signals from the PMIC 525.
[0119] In some specific embodiments (which may be combined with the above examples), the baseband circuit 610 includes one or more digital baseband systems that are coupled to each other and to the CPU subsystem, audio subsystem, and interface subsystem using an interconnection subsystem. The digital baseband subsystems may also be coupled to the digital baseband interface and the mixed - signal baseband subsystem using another interconnection subsystem. Each of the interconnection subsystems may include a bus system, point - to - point connectors, a network - on - chip (NOC) architecture, or some other suitable bus or interconnection technology, such as those discussed herein. The audio subsystem may include DSP circuits, buffer memories, program memories, voice processing accelerator circuits, data converter circuits such as analog - to - digital converter circuits and digital - to - analog converter circuits, analog circuits including one or more of amplifiers and filters, etc. In some specific embodiments, the baseband circuit 610 may include protocol processing circuitry having one or more instances of control circuits (not shown) to provide control functions to the digital baseband circuit or radio frequency circuit (e.g., radio front - end module 615).
[0120] In some specific implementations, the baseband circuit 610 includes various processing devices for operating one or more wireless communication protocols (e.g., a "multi-protocol baseband processor" or "protocol processing circuit") and various processing devices for implementing PHY layer functions. In some specific implementations, the PHY layer functions include the aforementioned radio control functions. In some specific implementations, the protocol processing circuit operates or implements various protocol layers or entities of one or more wireless communication protocols. For example, when the baseband circuit 610 or the RF circuit 606 or both are part of a millimeter-wave communication circuit or some other suitable cellular communication circuit, the protocol processing circuit can operate LTE protocol entities or 5G NR protocol entities or both. In this example, the protocol processing circuit can operate MAC, RLC, PDCP, SDAP, RRC, and NAS functions. In some specific implementations, when the baseband circuit 610 or the RF circuit 606 or both are part of a Wi-Fi communication system, the protocol processing circuit can operate one or more IEEE-based protocols. In this example, the protocol processing circuit can operate Wi-Fi MAC and logical link control (LLC) functions. The protocol processing circuit can include one or more memory structures (e.g., 604G) for storing program code and data for operating protocol functions, and one or more processing cores for executing the program code and performing various operations using the data. The baseband circuit 610 can also support radio communication for more than one wireless protocol.
[0121] The various hardware elements of the baseband circuit 610 discussed herein can be implemented as, for example, a soldered-in substrate that includes one or more integrated circuits (ICs), a single-packaged integrated circuit soldered to the main circuit board, or a multi-chip module that contains two or more ICs. In some specific implementations, the components of the baseband circuit 610 can be appropriately combined in a single chip or a single chipset, or disposed on the same circuit board. In some specific implementations, some or all of the constituent components of the baseband circuit 610 and the RF circuit 606 can be implemented together, such as, for example, a system-on-chip (SoC) or a system-in-package (SiP). In some specific implementations, some or all of the constituent components of the baseband circuit 610 can be implemented as a separate SoC communicatively coupled to the RF circuit 606 (or multiple instances of the RF circuit 606). In some specific implementations, some or all of the constituent components of the baseband circuit 610 and the application circuits 405, 505 can be implemented together as separate SoCs (e.g., a "multi-chip package") mounted on the same circuit board.
[0122] In some specific embodiments, the baseband circuit 610 may provide communications compatible with one or more radio technologies. The RF circuit 606 may communicate with a wireless network using modulated electromagnetic radiation through a non-solid medium. In some specific embodiments, the RF circuit 606 may include switches, filters, or amplifiers, among other components, to facilitate communication with the wireless network. The RF circuit 606 may include a receive signal path that may include circuitry for downconverting an RF signal received from the FEM circuit 608 and providing a baseband signal to the baseband circuit 610. The RF circuit 606 may also include a transmit signal path that may include circuitry for upconverting a baseband signal provided by the baseband circuit 610 and providing an RF output signal for transmission to the FEM circuit 608.
[0123] The receive signal path of the RF circuit 606 includes a mixer circuit 606a, an amplifier circuit 606b, and a filter circuit 606c. In some specific embodiments, the transmit signal path of the RF circuit 606 may include the filter circuit 606c and the mixer circuit 606a. The RF circuit 606 also includes a synthesizer circuit 606d for synthesizing frequencies for use by the mixer circuit 606a of the receive signal path and the transmit signal path. In some specific embodiments, the mixer circuit 606a of the receive signal path may be configured to downconvert an RF signal received from the FEM circuit 608 based on the synthesized frequency provided by the synthesizer circuit 606d. The amplifier circuit 606b may be configured to amplify the downconverted signal, and the filter circuit 606c 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 the baseband circuit 610 for further processing. In some specific embodiments, the output baseband signal may be a zero-frequency baseband signal, but this is not required. In some specific embodiments, the mixer circuit 606a of the receive signal path may include a passive mixer.
[0124] In some specific embodiments, the mixer circuit 606a of the transmit signal path may be configured to upconvert an input baseband signal based on the synthesized frequency provided by the synthesizer circuit 606d to generate an RF output signal for the FEM circuit 608. The baseband signal may be provided by the baseband circuit 610 and may be filtered by the filter circuit 606c.
[0125] In some specific embodiments, the mixer circuit 606a of the receive signal path and the mixer circuit 606a of the transmit signal path may include two or more mixers and may be arranged for quadrature down-conversion and up-conversion respectively. In some specific embodiments, the mixer circuit 606a of the receive signal path and the mixer circuit 606a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some specific embodiments, the mixer circuit 606a of the receive signal path and the mixer circuit 606a of the transmit signal path may be arranged for direct down-conversion and direct up-conversion respectively. In some specific embodiments, the mixer circuit 606a of the receive signal path and the mixer circuit 606a of the transmit signal path may be configured for superheterodyne operation.
[0126] In some specific embodiments, the output baseband signal and the input baseband signal may be analog baseband signals. In some specific embodiments, the output baseband signal and the input baseband signal may be digital baseband signals, and the RF circuit 606 may include an analog-to-digital converter (ADC) and a digital-to-analog converter (DAC) circuit, and the baseband circuit 610 may include a digital baseband interface for communicating with the RF circuit 606. In some dual-mode examples, separate radio IC circuits may be provided to process signals of each spectrum, but the techniques described herein are not limited in this regard.
[0127] In some specific embodiments, the synthesizer circuit 606d may be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but other types of frequency synthesizers may also be used. For example, the synthesizer circuit 606d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider. The synthesizer circuit 606d may be configured to synthesize an output frequency based on a frequency input and a frequency divider control input for use by the mixer circuit 606a of the RF circuit 606. In some specific embodiments, the synthesizer circuit 606d may be a fractional-N / N+1 synthesizer.
[0128] In some specific embodiments, the frequency input may be provided by a voltage-controlled oscillator (VCO), although this is not necessary. The frequency divider control input may be provided by the baseband circuit 610 or the application circuit 405 / 505 according to the desired output frequency. In some specific embodiments, the frequency divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application circuits 405, 505.
[0129] The synthesizer circuit 606d of the RF circuit 606 may include a frequency divider, a delay locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency 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 an input signal by N or N+1 (e.g., based on a carry output) to provide a fractional division ratio. In some embodiments, the DLL may include cascaded, tunable, delay elements, a phase detector, a charge pump, and a set of D-type flip-flops. The delay elements may be configured to divide the VCO period into Nd equal phase bins, 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 period.
[0130] In some embodiments, the synthesizer circuit 606d may be configured to generate a carrier frequency as the output frequency, while in other examples, 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 with an orthogonal generator and a frequency divider circuit to generate multiple signals having multiple different phases relative to each other at that carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 606 may include an IQ or polar converter.
[0131] The FEM circuit 608 may include a receive signal path that may include circuitry configured to operate on RF signals received from the antenna array 611, amplify the received signals, and provide an amplified version of the received signals to the RF circuit 606 for further processing. The FEM circuit 608 may also include a transmit signal path that may include circuitry configured to amplify transmit signals provided by the RF circuit 606 for transmission by one or more antenna elements in the antenna array 611. Amplification through the transmit signal path or the receive signal path may be done only in the RF circuit 606, only in the FEM circuit 608, or in both the RF circuit 606 and the FEM circuit 608.
[0132] In some specific embodiments, the FEM circuit 608 may include a TX / RX switch to switch between operating in a transmit mode and a receive mode. The FEM circuit 608 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit 608 may include an LNA to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to the RF circuit 606). The transmit signal path of the FEM circuit 608 may include a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuit 606), and one or more filters for generating an RF signal for subsequent transmission by one or more antenna elements of the antenna array 611.
[0133] The antenna array 611 includes one or more antenna elements, each antenna element being configured to convert an electrical signal into a radio wave to travel through the air and convert the received radio wave into an electrical signal. For example, a digital baseband signal provided by the baseband circuit 610 is converted into an analog RF signal (e.g., a modulated waveform), which will be amplified and transmitted using the antenna elements of the antenna array 611 including one or more antenna elements (not shown). The antenna elements can be omnidirectional, directional, or a combination thereof. The antenna elements can form various arrangements as known and / or discussed herein. The antenna array 611 may include a microstrip antenna or a printed antenna fabricated on the surface of one or more printed circuit boards. The antenna array 611 may be formed as patches of metal foil in various shapes (e.g., patch antennas), and may be coupled to the RF circuit 606 and / or the FEM circuit 608 using metal transmission lines and the like.
[0134] The processors of the application circuit 405 / 505 and the baseband circuit 610 may be used to execute elements of one or more instances of a protocol stack. For example, the processor of the baseband circuit 610 may execute layer 3, layer 2, or layer 1 functions individually or in combination, while the processors of the application circuits 405, 505 may utilize the data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., TCP and UDP layers). As mentioned herein, layer 3 may include the RRC layer, which will be described in further detail below. As mentioned herein, layer 2 may include the MAC layer, the RLC layer, and the PDCP layer, which will be described in further detail below. As mentioned herein, layer 1 may include the PHY layer of the UE / RAN node, which will be described in further detail below.
[0135] Figure 7 Exemplary components of the communication circuit 700 are shown. In some specific embodiments, the communication circuit 700 may be implemented as Figure 4 and Figure 5Part of the illustrated system 400 or platform 500. The communication circuitry 700 may be communicatively coupled (e.g., directly or indirectly) to one or more antennas, such as antennas 711a, 711b, 711c, and 711d. In some embodiments, the communication circuitry 700 includes or is communicatively coupled to dedicated receive chains, processors, or radio components for multiple RATs, or combinations thereof (e.g., a first receive chain for LTE and a second receive chain for 5G NR). For example, as Figure 7 illustrated, the communication circuitry 700 includes a modem 710 and a modem 720, which may correspond to or be Figure 4 and Figure 5 part of the baseband circuitry 410 and 510 illustrated. The modem 710 may be configured to communicate according to a first RAT, such as LTE or LTE-A, and the modem 720 may be configured to communicate according to a second RAT, such as 5G NR. In some embodiments, a processor 705, such as an application processor, may interact with the modems 710, 720.
[0136] The modem 710 includes one or more processors 712 and a memory 716 communicatively coupled to the processors 712. The modem 710 communicates with a radio frequency (RF) front end 730, which may correspond to Figure 4 and Figure 5 the RFEMs 415 and 515 illustrated or be part thereof. The RF front end 730 may include circuitry for transmitting and receiving radio signals. For example, the RF front end 730 includes an RX circuit 732 and a TX circuit 734. In some embodiments, the receive circuit 732 communicates with a DL front end 752, which may include circuitry for receiving radio signals from one or more antennas 711a. The transmit circuit 734 communicates with a UL front end 754, which is coupled to one or more antennas 711b.
[0137] Similarly, the modem 720 includes one or more processors 722 and a memory 726 communicatively coupled to the one or more processors 722. The modem 720 communicates with an RF front end 740, which may correspond to Figure 4 and Figure 5The RFEM 415 and 515 shown or a part thereof. The RF front end 740 may include circuitry for transmitting and receiving radio signals. For example, the RF front end 740 includes a receiving circuit 742 and a transmitting circuit 744. In some specific embodiments, the receiving circuit 742 may communicate with the DL front end 760, which may include circuitry for receiving radio signals from one or more antennas 711c. The transmitting circuit 744 communicates with the UL front end 765, which is coupled to one or more antennas 711d. In some specific embodiments, one or more front ends may be combined. For example, an RF switch may selectively couple the modems 710, 720 to a single UL front end 772 for transmitting radio signals using one or more antennas.
[0138] The modem 710 may include hardware and software components for time division multiplexing UL data (e.g., for NSA NR operation) and various other techniques described herein. The processor 712 may include one or more processing elements configured to implement various features described herein, such as by executing program instructions stored in a memory 716 (e.g., a non-transitory computer-readable memory medium). In some specific embodiments, the processor 712 may be configured as a programmable hardware element, such as an FPGA or an ASIC. In some specific embodiments, the processor 712 may include one or more ICs configured to perform the functions of the processor 712. For example, each IC may include circuitry configured to perform the functions of the processor 712.
[0139] The modem 720 may include hardware and software components for time division multiplexing UL data (e.g., for NSA NR operation) and various other techniques described herein. The processor 722 may include one or more processing elements configured to implement various features described herein, such as by executing instructions stored in a memory 726 (e.g., a non-transitory computer-readable memory medium). In some specific embodiments, the processor 722 may be configured as a programmable hardware element, such as an FPGA or an ASIC. In some specific embodiments, the processor 722 may include one or more ICs configured to perform the functions of the processor 722.
[0140] Figure 8 Illustrates various protocol functions that may be implemented in a wireless communication device. Specifically, Figure 8 Includes an arrangement 800 showing the interconnection between various protocol layers / entities. The following description is provided for various protocol layers and entities operating in conjunction with the 5G NR system standard and the LTE system standard, but Figure 8 some or all aspects of Figure 8 may also be applicable to other wireless communication network systems.
[0141] In addition to other higher layer functions not shown, the protocol layer of arrangement 800 may further include one or more of PHY 810, MAC 820, RLC 830, PDCP 840, SDAP 847, RRC 855, and NAS layer 857. These protocol layers may include one or more service access points that may provide communication between two or more protocol layers (e.g., Figure 8 items 859, 856, 850, 849, 845, 835, 825, and 815 in
[0142] PHY 810 may transmit and receive physical layer signals 805, which may be received from or transmitted to one or more other communication devices. Physical layer signals 805 may include one or more physical channels, such as those discussed herein. PHY 810 may also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers (e.g., RRC 855). PHY 810 may further perform error detection on the transport channel, forward error correction (FEC) encoding and decoding of the transport channel, modulation and demodulation of the physical channel, interleaving, rate matching, mapping onto the physical channel, and MIMO antenna processing. In some specific embodiments, instances of PHY 810 may process requests from and provide indications to instances of MAC 820 using one or more PHY-SAP 815. According to some specific embodiments, requests and indications transmitted using PHY-SAP 815 may include one or more transport channels.
[0143] Instances of MAC 820 may process requests from and provide indications to instances of RLC 830 using one or more MAC-SAP 825. These requests and indications transmitted using MAC-SAP 825 may include one or more logical channels. MAC 820 may perform mapping between logical channels and transport channels, multiplex MAC SDUs from one or more logical channels onto transport blocks (TBs) to be delivered to PHY 810 using the transport channel, demultiplex MAC SDUs from TBs delivered from PHY 810 using the transport channel onto one or more logical channels, multiplex MAC SDUs onto TBs, scheduling information reporting, error correction via HARQ, and logical channel prioritization.
[0144] Examples of RLC 830 can utilize one or more radio link control service access points (RLC-SAPs) 835 to process requests from and provide indications to instances of PDCP 840. These requests and indications transmitted using RLC-SAP 835 can include one or more logical channels. RLC 830 can operate in multiple operation modes, including: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). RLC 830 can perform the transmission of upper layer protocol data units (PDUs), error correction by automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmission. RLC 830 can also perform re-segmentation of RLC data PDUs for AM data transmission, reordering of RLC data PDUs for UM and AM data transmission, detection of duplicate data for UM and AM data transmission, discarding of RLC SDUs for UM and AM data transmission, detection of protocol errors for AM data transmission, and perform RLC re-establishment.
[0145] Examples of PDCP 840 can utilize one or more packet data convergence protocol service access points (PDCP-SAPs) 845 to process requests from and provide indications to instances of RRC 855 or SDAP 847 or both. These requests and indications transmitted using PDCP-SAP 845 can include one or more radio bearers. PDCP 840 can perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), perform in-sequence delivery of higher layer PDUs upon re-establishment of the lower layer, eliminate duplication of lower layer SDUs upon re-establishment of the lower layer for radio bearers mapped to RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification on control plane data, control timer-based data discard, and perform security operations (e.g., encryption, decryption, integrity protection, or integrity verification).
[0146] Instances of SDAP 847 can utilize one or more SDAP-SAPs 849 to process requests from one or more higher layer protocol entities and provide indications to them. These requests and indications transmitted using SDAP-SAP 849 can include one or more QoS flows. SDAP 847 can map QoS flows to data radio bearers (DRBs) and vice versa, and can also mark QoS flow identifiers (QFIs) in DL packets and UL packets. A single SDAP entity 847 can be configured for a separate PDU session. In the UL direction, the NG-RAN 110 can control the mapping of QoS flows to DRBs in two different ways (reflection mapping or explicit mapping). For reflection mapping, the SDAP 847 of the UE 101 can monitor the QFI of DL packets of each DRB, and can apply the same mapping to the packets flowing in the UL direction. For a DRB, the SDAP 847 of the UE 101 can map UL packets belonging to a QoS flow that corresponds to the QoS flow ID and PDU session observed in the DL packets of that DRB. To implement reflection mapping, the NG-RAN 310 can mark DL packets with the QoS flow ID via the Uu interface. Explicit mapping can involve the RRC 855 configuring the SDAP 847 with explicit mapping rules for QoS flows to DRBs, which can be stored and followed by the SDAP 847. In some specific implementations, SDAP 847 can be used only in NR specific implementations and not in LTE specific implementations.
[0147] The RRC 855 can configure aspects of one or more protocol layers using one or more management service access points (M-SAPs), and the one or more protocol layers can include one or more instances of PHY 810, MAC 820, RLC 830, PDCP 840, and SDAP 847. In some specific implementations, instances of the RRC 855 can utilize one or more RRC-SAPs 856 to process requests from one or more NAS entities 857 and provide indications to them. The main services and functions of the RRC 855 can include the broadcast of system information (e.g., included in the master information block (MIB) or system information block (SIB) related to the NAS), the broadcast of system information related to the access stratum (AS), the paging, establishment, maintenance, and release of the RRC connection between the UE 101 and the RAN 110 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), the establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, mobility between RATs, and measurement configuration for UE measurement reports. These MIBs and SIBs can include one or more information elements (IEs), each of which can include individual data fields or data structures.
[0148] The NAS 857 can form the top layer of the control plane between the UE 101 and the AMF 321. The NAS 857 can support the mobility and session management procedures of the UE 101 to establish and maintain an IP connection between the UE 101 and the P-GW in the LTE system.
[0149] In some specific implementations, one or more protocol entities of the arrangement 800 can be implemented in the UE 101, the RAN node 111, the AMF 321 in the NR specific implementation or the MME 221 in the LTE specific implementation, the UPF 302 in the NR specific implementation or the S-GW 222 and the P-GW 223 in the LTE specific implementation, etc., for the control plane or user plane communication protocol stacks between the aforementioned devices. In some specific implementations, one or more protocol entities that can be implemented in one or more of the UE 101, the gNB 111, the AMF 321, etc. can communicate with the corresponding peer protocol entities that can be implemented in another device or on another device (using the services of the corresponding lower layer protocol entities to perform such communication). In some specific implementations, the gNB-CU of the gNB 111 can host the RRC 855, the SDAP 847, and the PDCP 840 of the gNB that control the operation of one or more gNB-DUs, and each gNB-DU of the gNB 111 can host the RLC 830, the MAC 820, and the PHY 810 of the gNB 111.
[0150] In some specific implementations, the control plane protocol stack can include, in order from the top layer to the bottom layer, the NAS 857, the RRC 855, the PDCP 840, the RLC 830, the MAC 820, and the PHY 810. In this example, the upper layer 860 can be built on top of the NAS 857, which includes the IP layer 861, the SCTP 862, and the application layer signaling protocol (AP) 863.
[0151] In some specific implementations such as the NR specific implementation, the AP 863 can be the NG application protocol layer (NGAP or NG-AP) 863 for the NG interface 113 defined between the NG-RAN node 111 and the AMF 321, or the AP 863 can be the Xn application protocol layer (XnAP or Xn-AP) 863 for the Xn interface 112 defined between two or more RAN nodes 111.
[0152] The NG-AP 863 can support the functions of the NG interface 113 and may include a primary procedure (EP). The NG-AP EP can be an interaction unit between the NG-RAN node 111 and the AMF 321. The NG-AP 863 services can include two groups: UE-associated services (e.g., services related to the UE 101) and non-UE-associated services (e.g., services related to the entire NG interface instance between the NG-RAN node 111 and the AMF 321). These services can include functions such as, but not limited to: a paging function for sending a paging request to the NG-RAN node 111 involved in a specific paging area; a UE context management function for allowing the AMF 321 to establish, modify, or release the UE context in the AMF 321 and the NG-RAN node 111; a mobility function for the UE 101 in the ECM-CONNECTED mode, for in-system HO to support mobility within the NG-RAN, and for inter-system HO to support mobility from / to the EPS system; a NAS signaling transmission function for transmitting or rerouting NAS messages between the UE 101 and the AMF 321; a NAS node selection function for determining the association between the AMF 321 and the UE 101; an NG interface management function for setting up the NG interface and monitoring errors through the NG interface; a warning message transmission function for providing means to transmit warning messages or cancel the ongoing broadcast of warning messages using the NG interface; a configuration transmission function for requesting and transmitting RAN configuration information (e.g., SON information, or performance measurement (PM) data) between two RAN nodes 111 using the CN 120; or a combination thereof, and so on.
[0153] The XnAP 863 can support the functions of the Xn interface 112 and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures can include procedures for handling UE mobility within the NG RAN111 (or E-UTRAN 210), such as handover preparation and cancellation procedures, SN status transmission procedures, UE context retrieval and UE context release procedures, RAN paging procedures, or procedures related to dual connectivity, etc. The XnAP global procedures can include procedures not related to a specific UE 101, such as Xn interface setup and reset procedures, NG-RAN update procedures, or cell activation procedures, etc.
[0154] In the LTE embodiment, the AP 863 can be the S1 application protocol layer (S1-AP) 863 for the S1 interface 113 defined between the E-UTRAN node 111 and the MME, or the AP 863 can be the X2 application protocol layer (X2AP or X2-AP) 863 for the X2 interface 112 defined between two or more E-UTRAN nodes 111.
[0155] The S1 Application Protocol Layer (S1-AP) 863 can support the functions of the S1 interface, and similar to the previously discussed NG-AP, the S1-AP can include S1-AP EPs. The S1-AP EP can be an interaction unit between the E-UTRAN node 111 and the MME 221 within the LTE CN 120. The S1-AP 863 services can include two groups: UE-associated services and non-UE-associated services. The functions performed by these services include, but are not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transmission, RAN Information Management (RIM), and configuration transfer.
[0156] The X2AP 863 can support the functions of the X2 interface 112, and can include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures can include procedures for handling UE mobility within the E-UTRAN 120, such as handover preparation and cancellation procedures, SN status transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, or procedures related to dual connectivity, etc. The X2AP global procedures can include procedures not related to a specific UE 101, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, or cell activation procedures, etc.
[0157] The SCTP layer (alternatively referred to as the SCTP / IP layer) 862 can provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in an NR implementation, or S1-AP or X2AP messages in an LTE implementation). The SCTP 862 can ensure reliable delivery of signaling messages between the RAN node 111 and the AMF 321 / MME 221, partially based on the IP protocol supported by the IP 861. The Internet Protocol layer (IP) 861 can be used to perform packet addressing and routing functions. In some implementations, the IP layer 861 can use point-to-point transmission to deliver and transfer PDUs. In this regard, the RAN node 111 can include communication links (e.g., wired or wireless) with the L2 and L1 layers of the MME / AMF to exchange information.
[0158] In some specific implementations, the user plane protocol stack may include SDAP 847, PDCP 840, RLC 830, MAC 820, and PHY 810 in order from the highest layer to the lowest layer. The user plane protocol stack may be used for communication between the UE 101, RAN node 111, and UPF 302 in an NR specific implementation, or for communication between the S-GW 222 and P-GW 223 in an LTE specific implementation. In this example, the upper layer 851 may be built on top of SDAP 847, and may include the User Datagram Protocol (UDP) and IP Security layer (UDP / IP) 852, the General Packet Radio Service (GPRS) Tunneling Protocol layer for the user plane (GTP-U) 853, and the User Plane PDU layer (UP PDU) 863.
[0159] The transport network layer 854 (also referred to as the "transport layer") may be built on top of IP transport, and GTP-U 853 may be used on top of the UDP / IP layer 852 (including the UDP layer and the IP layer) to carry the user plane PDU (UP-PDU). The IP layer (also referred to as the "internet layer") may be used to perform packet addressing and routing functions. The IP layer may assign IP addresses to user data packets in any one of, for example, IPv4, IPv6, or PPP formats.
[0160] GTP-U 853 may be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the transmitted user data may be packets in any one of IPv4, IPv6, or PPP formats. UDP / IP 852 may provide a checksum for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data streams. The RAN node 111 and S-GW 222 may utilize the S1-U interface to exchange user plane data using a protocol stack including the L1 layer (e.g., PHY 810), L2 layer (e.g., MAC 820, RLC 830, PDCP 840, and / or SDAP 847), UDP / IP layer 852, and GTP-U 853. The S-GW 222 and P-GW 223 may utilize the S5 / S8a interface to exchange user plane data using a protocol stack including the L1 layer, L2 layer, UDP / IP layer 852, and GTP-U 853. As previously discussed, the NAS protocol may support the mobility and session management processes of the UE 101 to establish and maintain an IP connection between the UE 101 and the P-GW 223.
[0161] In addition, although Figure 8Not shown, but the application layer may exist above the AP 863 and / or the transport network layer 854. The application layer may be a layer in which users of the UE 101, RAN node 111, or other network elements interact with software applications, for example, executed by the application circuit 405 or the application circuit 505, respectively. The application layer may also provide one or more interfaces for the software application to interact with the communication system (such as the baseband circuit 610) of the UE 101 or the RAN node 111. In some specific implementations, the IP layer or the application layer or both may provide functions the same as or similar to those of layers 5 to 7 of the Open Systems Interconnection (OSI) model or parts thereof (for example, OSI layer 7 - application layer, OSI layer 6 - presentation layer, and OSI layer 5 - session layer).
[0162] The NFV architecture and infrastructure can be used to virtualize one or more NFs onto physical resources that include a combination of industry-standard server hardware, storage hardware, or switches (alternatively, executed by proprietary hardware). In other words, the NFV system can be used to implement virtual or reconfigurable implementations of one or more EPC components and functions.
[0163] Figure 9 A block diagram of an example of a computer system including components for reading instructions from a machine-readable medium or a computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the techniques described herein is shown. In this example, Figure 9 A schematic diagram of hardware resources 900 is shown, including one or more processors (or processor cores) 910, one or more memories or storage devices 920, and one or more communication resources 930, each of which may be communicatively coupled using a bus 940. For implementations that utilize node virtualization (e.g., NFV), a hypervisor 902 may be executed to provide an execution environment for one or more network slices or sub-slices to utilize the hardware resources 900.
[0164] The processor 910 may include a processor 912 and a processor 914. The processor 910 may be, for example, a CPU, a RISC processor, a CISC processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof. The memory / storage device 920 may include a main memory, a disk storage device, or any suitable combination thereof. The memory / storage device 920 may include, but is not limited to, any type of volatile or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, or solid-state memory, or a combination thereof, and so on.
[0165] The communication resource 930 may include an interconnect device or a network interface component or other suitable devices to communicate with one or more peripheral devices 904 or one or more databases 906 using the network 908. For example, the communication resource 930 may include a wired communication component (e.g., for coupling using USB), a cellular communication component, an NFC component, (or low power) component, a Wi-Fi component, and other communication components.
[0166] The instructions 950 may include software, programs, applications, applets, applications, or other executable code for causing at least any one of the processors 910 to execute any one or more of the methods discussed herein. The instructions 950 may reside entirely or partially in at least one of the processors 910 (e.g., within the cache memory of the processor), the memory / storage device 920, or any suitable combination thereof. Additionally, any portion of the instructions 950 may be transferred from any combination of the peripheral devices 904 or the database 906 to the hardware resource 900. Thus, the memory of the processor 910, the memory / storage device 920, the peripheral devices 904, and the database 906 are examples of computer-readable media and machine-readable media.
[0167] A wireless communication system may use beamforming to transmit data between a device and a base station. Beamforming may provide increased bandwidth. Additionally, for high-frequency systems, the gain from beamforming may provide several advantages, including compensating for severe path loss caused by atmospheric attenuation, improving the signal-to-noise ratio (SNR), and expanding the coverage area. By aligning the transmission beam with the target UE, the radiated energy can be focused to achieve higher energy efficiency and mutual UE interference can be suppressed.
[0168] Figure 10 A diagram illustrating an example of a wireless communication system 1001 including multiple RAN nodes 1005a - 1005b configured for multi-TRP operation is shown. The system 1001 may be based on NR. The RAN nodes 1005a - b may individually or jointly send or receive control channels and data channels to or from the UE 1020. The nodes 1005a - 1005b can be configured as TRPs. In some embodiments, the RAN nodes 1005a - b may be equipped with antennas, such as two or more sub-arrays or panels. Each RAN node 1005a - b may be configured to direct one or more signals towards the UE 1020 using beamforming. In some embodiments, there may be multiple beams between the RAN nodes 1005a - b and the UE 1020. If beam failure occurs, the UE 1020 may, for example, use a beam failure recovery (BFR) procedure to cause the RAN nodes 1005a - b to switch to a different beam for subsequent communication.
[0169] In some specific implementations, the UE 1020 may be equipped with two or more sub-arrays or panels. In some specific implementations, the UE 1020 may use two or more panels to simultaneously transmit or receive control channels and data channels to improve the link budget. In this example, the UE 1020 is configured to form one or more Tx or Rx beams at the same or different times for the transmission or reception of physical channels, signals, or both. For example, the UE 1020 may simultaneously form two Tx or Rx beams for the transmission or reception of physical channels and / or signals. For example, in multi-TRP operation, the RAN nodes 1005a-b may simultaneously send data to the UE 1020.
[0170] In addition to transmitting user data, the base station may also provide control signaling to the user equipment. Various types of control signals include scheduling information and decoding information such as DCI messages. The user equipment may use the scheduling information and decoding information to receive and decode user data transmitted on a downlink channel such as the PDSCH. The user's data may be multiplexed in time, space, frequency, or a combination thereof. In some specific implementations, each base station corresponds to one or more TRPs. In multi-TRP operation, a channel such as the PDSCH may be transmitted from multiple TRPs, multiple panels of a TRP, or a combination thereof.
[0171] PDSCH transmission can be scheduled by one or more DCI messages, which may also schedule uplink transmissions, such as PUCCH transmissions that provide HARQ feedback for the PDSCH transmission. The DCI message may include, among other things, one or more time and frequency resource allocations for receiving the PDSCH transmission, a modulation and coding scheme indication identifier, a HARQ process number, and control information for the corresponding PUCCH transmission, such as power control, a PUCCH resource indication identifier (PRI), and a PDSCH-to-HARQ_feedback timing indication identifier.
[0172] Multiple PUCCH resource sets may be configured for the UE. The configuration of the PUCCH resource set may indicate the resources for PUCCH transmission. The configuration information may include one or more of the following: PUCCH format (PF), number of PRBs, number of symbols, starting symbol index, starting PRB, initial cyclic shift, etc. A wireless system based on NR may have different PUCCH formats (PFs), including short PFs with one to two symbols (such as PF0 and PF2) and long PFs with four or more symbols (such as PF1 and PF3). Some formats have a payload of one or two bits (PF0 and PF1), and other formats (such as PF2 and PF3) have a payload greater than two bits.
[0173] CORESET can be used for TRP differentiation. Once the CORESET is associated with the TRP, PDSCH transmissions from the same TRP can be considered to construct the HARQ-ACK codebook (for each TRP). Such construction can be based on existing 3GPP Rel-15 or subsequent procedures. In response to PDSCH reception from different TRPs, PUCCH resources carrying separate HARQ-ACK codebooks can be scheduled in the same time slot or different time slots.
[0174] In some specific embodiments, if such PUCCH resources are scheduled in the same time slot, the UE can be configured to use time-division multiplexing (TDM) to multiplex these PUCCH resources to avoid overlap in the time slot. In some specific embodiments, the PUCCH resources are divided into two groups, and these two groups are multiplexed in a TDM manner in the time slot. In some wireless systems, the longest duration of the PUCCH resources can be 7 symbols.
[0175] To improve the coverage of PUCCH transmissions in multi-TRP operations, the wireless system can use hybrid PUCCH resource grouping techniques. For example, some of the PUCCH resources within the PUCCH resource set can be multiplexed using TDM in the time slot, and some PUCCH resources can overlap and span more than 7 symbols in the time slot. In addition, the wireless communication system can use a signaling mechanism to allow for dynamic CORESET and PUCCH resource grouping for different traffic types. Among other things, the present disclosure describes mechanisms and signaling on CORESET and PUCCH resource grouping for multi-TRP operations, including mechanisms and signaling for PUCCH resource grouping, CORESET grouping based on higher-layer signaling, and the association of CORESET groups with PUCCH resource groups.
[0176] The wireless communication system can provide signaling to configure CORESET and PUCCH resource grouping for multi-TRP operations. In some specific embodiments, for PUCCH resource grouping, the first group of PUCCH resources is associated with the first TRP index or CORESET group, while the second group of PUCCH resources is associated with the second TRP index or CORESET group. Additionally, the first part of the first group of PUCCH resources can be multiplexed with the first part of the second group of PUCCH resources in a TDM manner, while the second part of the first group of PUCCH resources can overlap with the second part of the second group of PUCCH resources. The second parts of the first PUCCH resource group and the second PUCCH resource group can span more than 7 symbols, which can improve the coverage of PUCCH transmissions.
[0177] In the case of loose coordination between TRPs, the first PUCCH resource group and the first part of the second PUCCH resource group are used to carry HARQ-ACK feedback of different TRPs, which can ensure that PUCCH resources do not overlap in a time slot. In some specific implementations, the second part of the first PUCCH resource group and the second PUCCH resource group are used to carry HARQ-ACK of different TRPs, and these PUCCH resources can be scheduled in different time slots to ensure that the PUCCH resources do not overlap. In this case, dl-DataToUL-ACK can be configured separately for different TRPs. In some specific implementations, in order to ensure the scheduling of PUCCH resources for different TRPs in different time slots, the dl-DataToUL-ACK of two TRPs can be configured with disjoint sets for HARQ-ACK timing.
[0178] Figure 11 An example of the relationship 1101 between a PUCCH resource group, a TRP, and a CORESET is shown. A PUCCH resource group may include PUCCH resources belonging to different PUCCH resource sets. Each PUCCH resource group can be associated with a TRP. A TRP can be associated with a CORESET group. In some specific implementations, the CORESET group can be referred to as a CORESET pool and can be configured or referenced by a CORESET pool index. In this example, TRP-0 is associated with CORESET group 0, and TRP 1 is associated with CORESET group 1. A subset of PUCCH resources within each PUCCH resource group is selected such that they can be transmitted within a time slot in a TDM manner. In some specific implementations, if PRI = 0 is selected, the corresponding PUCCH resources are multiplexed in a TDM manner across PUCCH resource groups, while if PRI = 7 is selected, the corresponding PUCCH resources cannot be multiplexed in a TDM manner within a time slot.
[0179] Figure 12 An example of coordinating PUCCH transmissions between different PUCCH resource groups and TRPs (e.g., TRP-0 and TRP-1) is shown. The first group of PUCCH resources 1205 can be associated with the first TRP index (TRP-0) or a CORESET group. The second group of PUCCH resources 1207 can be associated with the second TRP index (TRP-1) or a CORESET group. The resources from the first group 1205 and the second group 1207 can be multiplexed in a TDM manner. Additionally, the third group of PUCCH resources 1209 can be associated with the first TPR index and the second TPR index or a CORESET group.
[0180] In some specific implementations, some uplink time slots are coordinated such that PUCCH is scheduled in those time slots from TRP-0 or TRP-1 rather than from both simultaneously. These uplink time slots can ensure large coverage by using PUCCH with 14OS, and PRI = 7 can be used for the scheduling conducted in these time slots. Some uplink time slots are uncoordinated, which means that PUCCH can be scheduled in these time slots from TRP-0 or TRP-1 or from both simultaneously. These uplink time slots can provide smaller coverage by using PUCCH with less than 14OS, and PRI = 0 can be used for the scheduling conducted in these time slots. One or more PUCCH resources in the third set of PUCCH resources 1209 can overlap with each other or span more than 7 symbols to improve the coverage of PUCCH transmission.
[0181] In some specific implementations, RRC signaling, MAC CE-based signaling, or a combination thereof can be used to indicate PUCCH resource regrouping or PUCCH resource group update. In one example, it is assumed that the PUCCH resource is associated with a first TRP index or CORESET group configured by UE-specific dedicated RRC signaling. To adjust PUCCH resource grouping in a more dynamic manner, MAC CE can be used to indicate that the PUCCH resource is then associated with a second TRP index or CORESET group. In some specific implementations, for MAC CE-based signaling, a logical channel ID (LCID) can be defined for PUCCH resource group update for MAC CE.
[0182] Figure 13 An example of format 1305 of the PUCCH resource group update MAC CE is shown. The format 1305 for the PUCCH resource group update MAC CE can include a serving cell ID field, a BWP ID field, a PUCCH resource ID field, an R field, and an S field. The serving cell ID field indicates the identity of the serving cell to which the MAC CE applies. The BWP ID field indicates the UL BWP that is the code point of the DCI bandwidth part indicator field to which the MAC CE applies, see for example 3GPP TS 38.212. The PUCCH resource ID field contains an identifier of the PUCCH resource ID identified by PUCCH-ResourceId, see for example 3GPP TS38.331. The R field can be a reserved bit, which can be set to zero. In some specific implementations, the S field can indicate the PUCCH resource group ID, the associated CORESET group ID, or the TRP ID.
[0183] Figure 14Another example of format 1405 for the PUCCH resource group update MAC CE is shown. The format 1405 for the PUCCH resource group update MAC CE may include a serving cell ID field, a BWP ID field, a PUCCH resource ID field, an R field, and an S field. In this example, the PUCCH spatial relation activation / deactivation MAC CE can be reused for the PUCCH resource group update, and one field can be reinterpreted to indicate that this format 1405 is for the PUCCH resource group update instead of the PUCCH spatial relation activation / deactivation MAC CE. For example, the "R" status before the PUCCH resource ID in Oct 2 can be reinterpreted to indicate the PUCCH resource group update. Another example is that one of the code points in the "S" status in Oct3 can be reinterpreted to indicate the PUCCH resource group update. For example, an "Si" status can be used to indicate a new PUCCH resource group.
[0184] In some specific implementations, to further reduce signaling overhead, the two "R" statuses in Oct1 and Oct2 can be jointly used to indicate which subset of the PUCCH resources has a PUCCH resource group update. For example, "00" can be used to indicate that the first subset (1 / 4) of the PUCCH groups in the PUCCH resource set has a PUCCH resource group update, and "01" can be used to indicate that the second subset (1 / 4) of the PUCCH groups in the PUCCH resource set has a PUCCH resource group update, and so on.
[0185] In some specific implementations, the TRP index or group index for the PUCCH resources can be configured in the spatial relation information element for the PUCCH. If the PUCCH spatial relation information is not configured, the PUCCH can be considered to be within the first group. For the PUSCH scheduled by DCI format 0_0, the PUSCH can follow the spatial relation information element for the dedicated PUCCH resource with the lowest resource ID within the PUCCH group, where the PUCCH group is associated with the CORESET group for this scheduled PDCCH.
[0186] The wireless communication system can provide a CORESET grouping signaling mechanism. Signaling such as RRC signaling, MAC CE-based signaling, or a combination thereof can be used to indicate CORESET grouping or CORESET group update. As an example of MAC CE signaling, the MAC CE may include a serving cell ID, a BWP ID, a CORESET index, and a CORESET group index. The system can also provide a CORESET group to the PUCCH resource group association signaling mechanism. In some specific implementations, the signaling via RRC or MAC CE can provide the association between the CORESET group identifier and the PUCCH resource group identifier.
[0187] In some specific implementations, CORESET group ID 0 is naturally associated with PUCCH resource group ID 0, and CORESET group ID 1 is naturally associated with PUCCH resource group ID 1. If the PUCCH resource group is not configured, it is assumed that all PUCCH resources belong to a single PUCCH resource group ID 0, and in this case, CORESET group IDs 0 and 1 are associated with PUCCH resource group ID 0.
[0188] In some specific implementations, CORESET group ID 0 or 1 is associated with PUCCH resource group 0 or 1 using MAC CE signaling. As an example of MAC CE signaling, the MAC CE may include a serving cell ID, a BWP ID, a PUCCH resource group ID, and a CORESET group ID. In some specific implementations, CORESET group ID 0 or 1 is associated with PUCCH resource group 0 or 1 using RRC signaling. As an example of RRC signaling, the PUCCH resource group is configured using RRC signaling, and the PUCCH resource group ID is associated with the CORESET group ID. In some specific implementations, the CORESET group ID can be referred to as the CORESET pool ID.
[0189] Figure 15 A flowchart showing an example of a configuration and PUCCH transmission process performed by a UE is shown. At 1505, the UE receives a PUCCH resource group configuration (e.g., a first set of PUCCH resources associated with a first TRP, a second set of PUCCH resources associated with a second TRP, a CORESET group association, a PRI mapping, etc.) via signaling such as RRC, MAC CE, or both. In some specific implementations, the PUCCH resource group configuration includes a configuration of a first set of PUCCH resources associated with a first TRP and a second set of PUCCH resources associated with a second TRP. A first part of the first set of PUCCH resources can be multiplexed with a first part of the second set of PUCCH resources using TDM. A second part of the first set of PUCCH resources is not multiplexed with a second part of the second set of PUCCH resources using TDM.
[0190] The PUCCH resource group configuration can provide information for PRI mapping. In some specific implementations, a first part of the first set of PUCCH resources and a first part of the second set of PUCCH resources can be addressed by a first PRI; and a second part of the first set of PUCCH resources and a second part of the second set of PUCCH resources can be addressed by a second PRI.
[0191] At 1505, receiving PUCCH resource group configuration may include receiving one or more parameters via a higher layer signaling such as RRC signaling. In some specific implementations, the PUCCH resource group configuration is signaled using a MAC CE. The MAC CE may include a serving cell ID, a BWP ID, a PUCCH resource ID, and a PUCCH resource group ID. The UE may receive a CORESET group configuration. In some specific implementations, the CORESET group configuration is signaled using a MAC CE, which may include a serving cell ID, a BWP ID, a CORESET ID, and a CORESET group ID.
[0192] In some specific implementations, the UE may receive configuration information about the group association between the PUCCH resource group and the CORESET group via signaling such as RRC signaling, MAC CE signaling, or both. Such configuration information may include a serving cell ID, a BWP ID, a CORESET ID, and a PUCCH resource group ID. In some specific implementations, the group association can be signaled using a MAC CE, which may include a serving cell ID, a BWP ID, a CORESET ID, and a PUCCH resource group ID.
[0193] At 1510, the UE receives one or more DCI messages containing a PRI to schedule PUCCH transmissions to different TRPs. The DCI message may include one or more time and frequency resource allocations for receiving the PDSCH, a modulation and coding scheme indication identifier, a HARQ process number, and control information for the corresponding PUCCH transmission, such as power control, PRI, and a PDSCH to HARQ_feedback timing indication identifier. Other different types of DCI parameters are also possible.
[0194] At 1515, the UE performs PUCCH transmissions to different TRPs according to one or more DCI messages using resources selected from the PRI and the PUCCH resource group configuration. In some specific implementations, the PUCCH transmission includes HARQ feedback.
[0195] The UE can be configured to perform techniques including the following operations: receive configuration information for a first set of PUCCH resources associated with a first TRP index or CORESET group and a second set of PUCCH resources associated with a second TRP index or CORESET group; and transmit on the first set of PUCCH resources and the second set of PUCCH resources using time division multiplexing. In some specific implementations, a first portion of the first set of PUCCH resources is time division multiplexed with a first portion of the second set of PUCCH resources. In some specific implementations, a second portion of the first set of PUCCH resources at least partially overlaps with a second portion of the second set of PUCCH resources. In some specific implementations, the transmission includes transmitting HARQ feedback on a first portion of the first set of PUCCH resources and a first portion of the second set of PUCCH resources.
[0196] Figure 16 A flowchart illustrating an example of a configuration and PUCCH reception process performed by one or more network components such as a gNB is shown. At 1605, the gNB provides PUCCH resource group configuration via signaling such as RRC, MAC CE, or both. The configuration may include one or more of the following: a first set of PUCCH resources associated with a first TRP, a second set of PUCCH resources associated with a second TRP, CORESET group association, and PRI mapping. At 1610, one or more gNBs transmit one or more DCI messages containing PRIs to schedule PUCCH transmissions to different TRPs. At 1615, the gNB receives PUCCH transmissions at different TRPs according to one or more DCI messages using resources selected from the PRIs and the PUCCH resource group configuration.
[0197] These and other techniques can be performed by devices implemented in or adopted by one or more types of network components, user equipment, or both. In some specific implementations, one or more non-transitory computer-readable media include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more of the techniques described herein. A device may include one or more processors and one or more computer-readable media, the computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more of the techniques.
[0198] In various specific implementations, the methods described herein can be implemented in software, hardware, or a combination thereof. Additionally, the order of the blocks of the methods can be changed, and various elements can be added, reordered, combined, omitted, modified, etc. Various modifications and changes will be apparent to those skilled in the art who benefit from this disclosure. The various specific implementations described herein are intended to be illustrative and not restrictive. Many variations, modifications, additions, and improvements are possible. Thus, multiple examples can be provided for components described herein as a single example. The boundaries between various components, operations, and data repositories are to some extent arbitrary, and specific operations are shown in the context of a particular exemplary configuration. Other allocations of functionality are anticipated and may fall within the scope of the appended claims. Finally, the structures and functions presented as discrete components in an exemplary configuration can be implemented as a combined structure or component.
[0199] The methods described herein can be implemented in circuitry such as one or more of the following: integrated circuits, logic circuits, processors (shared, dedicated, or groups), and / or memories (shared, dedicated, or groups), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable SoCs), digital signal processors (DSPs), or some combination thereof. Examples of processors can include Apple A-series processors, Architecture Core TM processors, ARM processors, AMD processors, and Qualcomm processors. Other types of processors are possible. In some specific implementations, the circuitry can execute one or more software or firmware programs to provide at least some of the functionality. The term "circuitry" can also refer to a combination of one or more hardware elements and program code for performing the functions of the program code (or a combination of circuits used in an electrical or electronic system). In these implementations, the combination of the hardware elements and the program code can be referred to as a particular type of circuitry. The circuitry can also include radio circuitry such as transmitters, receivers, or transceivers.
[0200] Multiple specific implementations have been described. However, it should be understood that various modifications can be made. Elements in one or more specific implementations can be combined, deleted, modified, or supplemented to form additional specific implementations. As another example, the logical flows shown in the figures do not require the particular order or sequential order shown to achieve the desired result. Additionally, other steps can be provided or steps can be eliminated from the flow, and other components can be added to or removed from the system. Thus, other specific implementations are within the scope of the following claims.
Claims
1. A method for wireless communication, comprising: Receiving a single Physical Uplink Control Channel (PUCCH) resource set configuration including information for a mapping of one or more Physical Uplink Control Channel (PUCCH) resource indication identities (PRIs), wherein the PUCCH resource set configuration includes configurations for a first set of PUCCH resources associated with a first Transmission and Reception Point (TRP) and a second set of PUCCH resources associated with a second TRP; Receiving a Downlink Control Information (DCI) message scheduling a PUCCH transmission, and the DCI message indicating resources at least partially based on the one or more PRI mappings; And Performing a PUCCH transmission to a TRP according to the PUCCH resource set configuration and at least partially based on the resources indicated in the DCI message, the TRP including the first TRP and the second TRP.
2. The method according to claim 1, wherein a first portion of the first set of PUCCH resources is time-division multiplexed with a first portion of the second set of PUCCH resources, and wherein a second portion of the first set of PUCCH resources is not time-division multiplexed with a second portion of the second set of PUCCH resources.
3. The method according to claim 1, wherein receiving the PUCCH resource set configuration includes receiving a PRI configuration for a first PRI and a second PRI, wherein a first portion of the first set of PUCCH resources and a first portion of the second set of PUCCH resources are addressed by the first PRI, and wherein a second portion of the first set of PUCCH resources and a second portion of the second set of PUCCH resources are addressed by the second PRI.
4. The method according to claim 1, wherein receiving the PUCCH resource set configuration includes receiving a serving cell identifier, a Bandwidth Part (BWP) identifier, a PUCCH resource identifier, and a PUCCH resource set identifier via Radio Resource Control (RRC) signaling, Medium Access Control (MAC) Control Element (CE) signaling, or both.
5. The method according to claim 1, wherein the PUCCH resource set configuration includes a group association between a PUCCH resource set and a Control Resource Set (CORESET) set.
6. The method according to claim 5, comprising: Receiving a CORESET pool configuration, the CORESET pool configuration including a serving cell identifier, a BWP identifier, a CORESET identifier, and a CORESET pool identifier associated with the CORESET pool.
7. The method according to claim 5, wherein the group association is signaled by information including a serving cell identifier, a BWP identifier, a CORESET identifier, and a PUCCH resource set identifier.
8. The method according to claim 1, wherein a first portion of the first set of PUCCH resources is time-division multiplexed with a first portion of the second set of PUCCH resources, and wherein a second portion of the first set of PUCCH resources at least partially overlaps with a second portion of the second set of PUCCH resources.
9. The method according to claim 8, wherein performing the PUCCH transmission comprises: transmitting a first hybrid automatic repeat request (HARQ) feedback to the first TRP using the first portion of the first set of PUCCH resources; and transmitting a second HARQ feedback to the second TRP using the first portion of the second set of PUCCH resources.
10. An apparatus for wireless communication, the apparatus comprising one or more processors configured to perform operations, the operations comprising: receiving a single PUCCH resource set configuration comprising information including a physical resource identifier (PRI) mapping for one or more physical uplink control channel (PUCCH) resources, wherein the PUCCH resource set configuration comprises a configuration of a first set of PUCCH resources associated with a first transmission and reception point (TRP) and a second set of PUCCH resources associated with a second TRP; receiving a downlink control information (DCI) message scheduling a PUCCH transmission, and the DCI message indicating resources at least in part based on the one or more PRI mappings; and performing a PUCCH transmission to a TRP, the TRP including the first TRP and the second TRP, according to the PUCCH resource set configuration and at least in part based on the resources indicated in the DCI message.
11. The apparatus according to claim 10, wherein a first portion of the first set of PUCCH resources is time-division multiplexed with a first portion of the second set of PUCCH resources, and wherein a second portion of the first set of PUCCH resources is not time-division multiplexed with a second portion of the second set of PUCCH resources.
12. The apparatus according to claim 10, wherein receiving the PUCCH resource set configuration comprises receiving a PRI configuration for a first PRI and a second PRI, wherein the first portion of the first set of PUCCH resources and the first portion of the second set of PUCCH resources are addressed by the first PRI, and wherein the second portion of the first set of PUCCH resources and the second portion of the second set of PUCCH resources are addressed by the second PRI.
13. The apparatus according to claim 10, wherein receiving the PUCCH resource set configuration comprises receiving a serving cell identifier, a bandwidth part (BWP) identifier, a PUCCH resource identifier, and a PUCCH resource set identifier via radio resource control (RRC) signaling, medium access control (MAC) control element (CE) signaling, or both.
14. The apparatus according to claim 10, wherein the PUCCH resource set configuration comprises a group association between a PUCCH resource set and a control resource set (CORESET) set.
15. The apparatus according to claim 14, wherein the operations comprise: receiving a CORESET pool configuration, the CORESET pool configuration comprising a serving cell identifier, a bandwidth part (BWP) identifier, a CORESET identifier, and a CORESET pool identifier associated with the CORESET pool.
16. The apparatus according to claim 14, wherein the group association is signaled by information including a serving cell identifier, a BWP identifier, a CORESET identifier, and a PUCCH resource group identifier.
17. The apparatus according to claim 10, wherein a first part of the first set of PUCCH resources is time-division multiplexed with a first part of the second set of PUCCH resources, and wherein a second part of the first set of PUCCH resources at least partially overlaps with a second part of the second set of PUCCH resources.
18. The apparatus according to claim 17, wherein performing the PUCCH transmission comprises: transmitting a first hybrid automatic repeat request (HARQ) feedback to the first TRP on the first part of the first set of PUCCH resources; and transmitting a second HARQ feedback to the second TRP on the first part of the second set of PUCCH resources.
19. An apparatus for wireless communication, the apparatus comprising one or more processors configured to perform operations, the operations including: sending a single physical uplink control channel (PUCCH) resource group configuration including information for a physical uplink control channel (PUCCH) resource indication identity (PRI) mapping for one or more PUCCH resources, wherein the PUCCH resource group configuration includes a configuration for a first set of PUCCH resources associated with a first transmission and reception point (TRP) and a second set of PUCCH resources associated with a second TRP; sending a downlink control information (DCI) message that schedules PUCCH transmission and indicates resources at least in part based on the one or more PRI mappings; and receiving one or more PUCCH transmissions from one or more TRPs according to the PUCCH resource group configuration and at least in part based on the resources indicated in the DCI message.
20. The apparatus according to claim 19, wherein a first part of the first set of PUCCH resources is time-division multiplexed with a first part of the second set of PUCCH resources, and wherein a second part of the first set of PUCCH resources is not time-division multiplexed with a second part of the second set of PUCCH resources.
21. The apparatus according to claim 20, wherein the one or more processors are configured to provide a PRI configuration for a first PRI and a second PRI, wherein the first part of the first set of PUCCH resources and the first part of the second set of PUCCH resources are addressed by the first PRI, and wherein the second part of the first set of PUCCH resources and the second part of the second set of PUCCH resources are addressed by the second PRI.
22. The apparatus according to claim 19, wherein the PUCCH resource group configuration includes a group association between a PUCCH resource group and a control resource set (CORESET) pool.