Patent Application
20230053430
The present description generally relates to wireless communication systems and more specifically to enhance Physical Uplink Control Channel (PUCCH) handling in the context of multiple PUCCH configurations.
NR uses Cyclic Prefix Orthogonal Frequency Division Multiplexing (CP-OFDM) in both downlink (DL) (i.e. from a network node (e.g. gNB or base station) to a user equipment (UE)) and uplink (UL) (i.e. from UE to gNB). Discrete Fourier Transform (DFT) spread OFDM is also supported in the uplink. In the time domain, NR downlink and uplink are organized into equally sized subframes of 1 ms each. A subframe is further divided into multiple slots of equal duration. The slot length depends on subcarrier spacing. For subcarrier spacing of Δf=15 kHz, there is only one slot per subframe, and each slot consists of 14 OFDM symbols.
Data scheduling in NR is typically in slot basis, an example is shown in
Different subcarrier spacing values are supported in NR. The supported subcarrier spacing values (also referred to as different numerologies) are given by Δf=(15×2μ) kHz where μ∈{0,1,2,3,4}. Δf=15 kHz is the basic subcarrier spacing. The slot durations at different subcarrier spacings is given by
In the frequency domain, a system bandwidth is divided into resource blocks (RBs), each corresponds to 12 contiguous subcarriers. The RBs are numbered starting with 0 from one end of the system bandwidth. The basic NR physical time-frequency resource grid is illustrated in
Downlink transmissions are dynamically scheduled, i.e., in each slot the gNB transmits downlink control information (DCI) over Physical Downlink Control Channel (PDCCH) about which UE data is to be transmitted to and which RBs in the current downlink slot the data is transmitted on. The UE data are carried on PDSCH.
There are three DCI formats defined for scheduling PDSCH in NR, i.e., DCI format 1_0 and DCI format 1_1 which were introduced in NR Rel-15, and DCI format 1_2 which was introduced in NR Rel-16. Typically, DCI format 1_0 has a smaller size than DCI 1_1 and can be used when a UE is not fully connected to the network, while DCI format 1_1 can be used for scheduling Multiple-Input-Multiple-Output (MIMO) transmissions with multiple MIMO layers.
In NR Rel-16, DCI format 1_2 was introduced for downlink scheduling. One of the main motivations for having the new DCI format is to be able to configure a very small DCI size which can provide some reliability improvement without losing much flexibility. The main design target of the new DCI format is thus to have a DCI with highly configurable sizes for more fields, as compared to DCI format 1_1, with a minimum DCI size targeting a reduction of 10-16 bits relative to Rel-15 DCI format 1_0.
PUCCH Resources
In Rel-15 NR, up to four PUCCH resource sets can be configured to a UE. A PUCCH resource set with pucch-ResourceSetId=0 can have up to 32 PUCCH resources while for PUCCH resource sets with pucch-ResourceSetId=1 to 3, each set can have up to 8 PUCCH resources. A UE determines the PUCCH resource set in a slot based on the number of aggregated Uplink Control Information (UCI) bits to be sent in the slot. The UCI bits consists of Hybrid Automatic Repeat request (HARQ) ACK/NACK, scheduling request (SR), and channel state information (CSI) bits.
For a PUCCH transmission with HARQ-ACK information, a UE determines a PUCCH resource after determining a PUCCH resource set. The PUCCH resource determination is based on a 3-bit PUCCH resource indicator (PRI) field in DCI format 1_0 or DCI format 1_1. In the case of DCI format 1_2, the PUCCH resource determination is based on a configurable PRI field with the field size configurable between 0 and 3 bits.
If more than one DCI formats 1_0, 1_1 or 1_2 are received in the case of Carrier Aggregation (CA) and/or Time Division Duplex (TDD), the PUCCH resource determination is based on a PRI field in the last DCI format 1_0, 1_1 or 1_2 among the multiple received DCI format 1_0, 1_1 or 1_2 that the UE detects. In this case, the multiple received DCI format 1_0, 1_1 or 1_2 have a value of a PDSCH-to-HARQ_feedback timing indicator field indicating the slot (or sub-slot, if configured) for the PUCCH transmission. For PUCCH resource determination in this case, detected DCI formats are first indexed in an ascending order across serving cells indexed for a same PDCCH monitoring occasion and are then indexed in an ascending order across PDCCH monitoring occasion indexes.
Spatial Relation Definition
Spatial relation is used in NR to refer to a relationship between an UL reference signal (RS) such as PUCCH/PUSCH demodulation reference signal (DMRS) and another RS, which can be either a DL RS (e.g. channel state information RS (CSI-RS) or synchronization signal block (SSB)) or an UL RS (e.g. sounding reference signal (SRS)). This is defined from a UE perspective.
If an UL RS is spatially related to a DL RS, it means that the UE should transmit the UL RS in the opposite (reciprocal) direction from which it received the DL RS previously. More precisely, the UE should apply the “same” transmit (Tx) spatial filtering configuration for the transmission of the UL RS as the receive (Rx) spatial filtering configuration it used to receive the spatially related DL RS previously. Here, the terminology ‘spatial filtering configuration’ may refer to the antenna weights that are applied at either the transmitter or the receiver for data/control transmission/reception. The DL RS is also referred to as the spatial filter reference signal.
If a first UL RS is spatially related to a second UL RS, then the UE should apply the same Tx spatial filtering configuration for the transmission of the first UL RS as the Tx spatial filtering configuration it used to transmit the second UL RS.
An example of using spatial relation for PUCCH is shown in
Spatial Relation Indication for PUCCH
NR Rel-15 Spatial Relation Indication for PUCCH
For NR Rel-15, 3GPP TS 38.213 and 3GPP TS 38.331 specify that a UE can be Radio Resource Control (RRC) configured with a list of up to 8 spatial relations for PUCCH. This list is given by the RRC parameter PUCCH_SpatialRelationInfo. For example, the list would typically contain the identities/identifiers (IDs) of a number of SSBs and/or CSI-RS resources. Alternatively, the list may also contain the IDs of a number of SRS resources.
Based on the DL (or UL) beam management measurements performed by the UE (or gNB), the gNB selects one of the RS IDs from the list of configured ones in PUCCH_SpatialRelationInfo. The selected spatial relation is then activated via a Media Access Control (MAC)-Control Element (CE) message signaled to the UE for a given PUCCH resource. The UE then uses the signaled spatial relation for the purposes of adjusting the Tx spatial filtering configuration for the transmission on that PUCCH resource.
The MAC CE for activation/deactivation for PUCCH spatial relation is shown in
In addition to providing the spatial relation for PUCCH, each PUCCH_SpatialRelationInfo (as shown below) also provides some PUCCH power control parameters including a Reference RS ID (i.e., pucch-PathlossReferenceRS-Id) for path loss estimation, p0-PUCCH-Id for open loop power control, and closedLoopindex for closed loop power control. The pucch-PathlossReferenceRS can be either an CSI-RS or SSB.
NR Rel-16 Spatial Relation Indication for PUCCH
One enhancement made in NR Rel-16 is to increase the maximum number of RRC configured spatial relations for PUCCH. As per this enhancement, an NR Rel-16 UE can be RRC configured with a list of up to 64 spatial relations for PUCCH.
For NR Rel-15, the spatial relation is updated per PUCCH resource. In NR Rel-16, to achieve signaling overhead reduction, simultaneous spatial relation update/indication for a group of PUCCH resources is introduced. In Rel-16, explicit higher layer signaling is used to indicate to the UE a group of PUCCH resources, and MAC CE is used to simultaneously update/indicate a single spatial relation per group of PUCCH resources. When the MAC CE simultaneously updates/indicates a single spatial relation for a group of PUCCH resources, the indicated spatial relation is applied to all the PUCCH resources in the group of PUCCH resources. In NR Rel-16, up to 4 PUCCH groups are supported per BWP.
Configuration of PUCCHConfigList in UL Dedicated BWP in Rel-16
The Ultra Reliable and Low Latency Communication (URLLC) Rel-16 Work Item (WI) will introduce a list of PUCCH configurations per UL BWP as can be seen from the running Change Request (CR) excerpt (i.e. R1-1913675, which can be found at https://www.3gpp.org/ftp.tsg_ran/WG2_RL2/TSGR2_109_e/Docs/R2-2001356.zip). Tis results in doubling the PUCCH resources in the UL BWP and also reusing the PUCCH resource IDs. Thus, after adding the PUCCHConfigList, the PUCCH resource ID is not unambiguous in the UL BWP anymore. In the text below, the text in bold represents new additions of Rel-16 and the text underlined shows the PUCCH resource configurations in the PUCCHConfig.
indicates data missing or illegible when filed
indicates data missing or illegible when filed
indicates data missing or illegible when filed
(end of the IE omitted)
Currently there exists some challenges. The section entitled “Configuration of PUCCHConfigList in UL dedicated BWP in Rel-16” of the background section means that the current MAC CE in Rel-15, or the PUCCH MAC CEs described in R1-1907966 LS on MIMO enhancement for NR, cannot address the single PUCCH resource unambiguously if PUCCHConfigList is configured as an ID space of PUCCH resource sets and is reused within the BWP.
Further, it has been disclosed that more than one spatial relation can be associated with a PUCCH resource. However, the need to indicate spatial relations for PUCCH resource ID or PUCCH resource ID set or group per PUCCHConfig has not been addressed. The PUCCH resource ID set exists in Rel-15 and additionally in Rel-16, the PUCCH resource group is specified. That is, each PUCCHConfig may have one or two PUCCH groups configured through RRC.
Embodiments of this disclosure address these challenges. For example, the embodiments propose modifying the discussed MAC CEs to include PUCCHConfig ID in order to unambiguously address a PUCCH resource ID when a PUCCHConfig list is configured. Furthermore, the PUCCHConfig ID can unambiguously address a PUCCH resource set or resource group or PUCCH resource configuration group. Additionally, solutions are provided to handle the ID space of PUCCH resource IDs such that unambiguous pointing is possible.
According to one aspect, some embodiments include methods performed by a wireless device. For example, a method for handling spatial relations for PUCCH resources belonging to different PUCCH resource configuration groups (or PUCCH groups) may comprise: receiving, from a network node, a command to activate or deactivate a spatial relation for a PUCCH resource, wherein each PUCCH of the different PUCCH groups is uniquely identified in the command; and performing one of activating and deactivating the spatial relation for the PUCCH resource identified in the command.
According to another aspect, some embodiments include a wireless device configured, or operable, to perform one or more functionalities (e.g. actions, operations, steps, etc.) as described herein.
In some embodiments, the wireless device may comprise one or more communication interfaces configured to communicate with one or more other radio nodes and/or with one or more network nodes, and processing circuitry operatively connected to the communication interface, the processing circuitry being configured to perform one or more functionalities as described herein. In some embodiments, the processing circuitry may comprise at least one processor and at least one memory storing instructions which, upon being executed by the processor, configure the at least one processor to perform one or more functionalities as described herein.
According to another aspect, some embodiments include methods performed by a network node. For example, a method for indicating spatial relations for PUCCH resources belonging to different PUCCH resource configuration groups (or PUCCH groups) may comprise: determining a PUCCH group to which a PUCCH resource belongs; and sending, to a wireless device, a command to activate or deactivate a spatial relation for the PUCCH resource, wherein each PUCCH resource of the different PUCCH groups is uniquely identified in the command.
According to yet another aspect, some embodiments include a network node configured, or operable, to perform one or more functionalities (e.g. actions, operations, steps, etc.) as described herein.
In some embodiments, the network node may comprise one or more communication interfaces configured to communicate with one or more other radio nodes and/or with one or more network nodes, and processing circuitry operatively connected to the communication interface, the processing circuitry being configured to perform one or more functionalities as described herein. In some embodiments, the processing circuitry may comprise at least one processor and at least one memory storing instructions which, upon being executed by the processor, configure the at least one processor to perform one or more functionalities as described herein.
In some embodiments, the network node and the wireless device may comprise one or more functional modules configured to perform one or more functionalities as described herein.
According to yet another aspect, some embodiments include a non-transitory computer-readable medium storing a computer program product comprising instructions which, upon being executed by processing circuitry (e.g., at least one processor) of the network node or wireless device, configure the processing circuitry to perform one or more functionalities as described herein.
The advantages/technical benefits of the embodiments of the present disclosure are to enable PUCCH spatial relation indication when PUCCHConfigList (indicating different PUCCH resource configuration groups) is configured.
This summary is not an extensive overview of all contemplated embodiments and is not intended to identify key or critical aspects or features of any or all embodiments or to delineate the scope of any or all embodiments. In that sense, other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.
Exemplary embodiments will be described in more detail with reference to the following figures, in which:
The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.
In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.
References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
In a first example, more than one PUCCHConfigs can be constructed because more than one HARQ-ACK codebooks are applied. For example, when two HARQ-ACK codebooks are simultaneously constructed, PUCCH Config ID=0 (or, alternatively, 1) refers to the PUCCH-Config used by the first HARQ-ACK codebook, and PUCCH Config ID=1 (or, alternatively, 0) refers to the PUCCH-Config used by the second HARQ-ACK codebook.
An issue in this case is that after adding PUCCHConfigList, the ID space is extended and the current way of coding reuses the ID space. Generally stated, in order to solve this issue, an indication, such as the PUCCHConfig ID, is added to the MAC CEs that are being designed in Rel-16. To do so, the PUCCH spatial relation Activation/Deactivation MAC CE is extended. The extended PUCCH spatial relation Activation/Deactivation MAC CE 100 is illustrated in
The Extended PUCCH spatial relation Activation/Deactivation MAC CE 100 of
More specifically, the extended PUCCH spatial relation Activation/Deactivation MAC CE 100 can have an indication of PUCCH Configuration ID, as illustrated in
It should be noted that the PUCCHConfigList can indicate several or a plurality of PUCCHConfigurations (referred to as PUCCH Configs) or a plurality of PUCCH resource configuration groups. Each PUCCH configuration is identified by a PUCCH Config ID. Each PUCCH configuration may comprise a plurality of PUCCH resources. In this case, the plurality of PUCCH configurations can be indicated by several bits. For example, if there are N PUCCH configs, then log_2(N) bits are needed to indicate the PUCCH configs.
The relevant RRC configurations corresponding to the above example are illustrated below, with the definition in bold:
Due to the new format of the MAC CE for PUCCH spatial relation Activation/Deactivation, an LCID needs to be allocated to it, separate from the existing LCID for “PUCCH spatial relation Activation/Deactivation”. One example is shown in the table below.
Enhanced Table 6.2.1-1 of 3GPP TS 38.213, Values of LCID for DL-SCH is illustrated below:
In a second example, a Group-based PUCCH spatial relation Activation/Deactivation MAC CE is considered.
The Group-based PUCCH spatial relation Activation/Deactivation MAC CE 300 is identified by a MAC subheader with LCID as specified in Table 6.2.1-1 of 3GPP TS 38.321. It has a fixed size of 16 bits with the following fields:
In another example, the MAC CEs of the previous examples are combined such that the MAC CE can indicate either single PUCCH resource, or a list of PUCCH resources and/or a group of PUCCH resources.
The relevant RRC configurations corresponding to the PUCCH-Config-ID of the example just above are illustrated below, with the new definitions in bold:
In one example, the grouping of the PUCCH resources is extended from only the PUCCH resource ID to both the PUCCH resource ID and PUCCH config ID. For example, the grouping of PUCCH resource was (PUCCH resource 1, PUCCH resource 2) and now the grouping is extended to be (PUCCH resource 1-PUCCH Config 1, PUCCH resource 1-PUCCH Config 2, PUCCH Resource 2-PUCCH Config 1, PUCCH Resource 2-PUCCH Config 2).
In a third example, the Rel-15 MAC CE format is kept, however, one reserved bit is used to indicate the PUCCH Config ID.
The PUCCH spatial relation Activation/Deactivation MAC CE 400 is identified by a MAC subheader with LCID as specified in Table 6.2.1-1 of 3GPP 38.321. It has a fixed size of 24 bits with the following fields:
In a fourth example, the Rel-15 MAC CE format is kept, however, there is an implicit grouping of the same PUCCH resource ID from two different PUCCH configurations, as such the different PUCCH configurations are indirectly indicated.
The PUCCH spatial relation Activation/Deactivation MAC CE 500 is identified by a MAC subheader with LCID as specified in Table 6.2.1-1 of 3GPP 38.321. It has a fixed size of 24 bits with the following fields:
In another example, the Rel-15 MAC CE format is kept, or the Rel-16 MAC CE format is kept (e.g. without the PUCCHConfig ID addition), however, an implicit indication of the PUCCH configuration ID a PUCCH resource belongs to can be provided. For example, the two lists of PUCCH resources in each PUCCH-config can be concatenated and numbered starting with the first element of the list of PUCCH resources in the first PUCCH configuration. Following the last element of the list of PUCCH resources in the first PUCCH configuration comes the first element of the list of PUCCH resources in the second PUCCH configuration. The last element of the concatenated list is the last element of the list of PUCCH resources in the second PUCCH configuration.
As each PUCCH resource can be uniquely indicated by the MAC CE, the PUCCH resource implicitly indicates the PUCCH configuration group to which it belongs.
The PUCCH spatial relation Activation/Deactivation MAC CE 600 is identified by a MAC subheader with LCID as specified in Table 6.2.1-1 of 3GPP 38.321. It has a fixed size of 24 bits with following fields:
In the disclosure above, a MAC CE has been used to indicate the PUCCH Config ID. It should be noted that the present teachings are not limited to a MAC CE and may apply to other messages as well, as will be appreciated by a person skilled in the art.
Now turning to
Step 710: receiving, from a network node, a command to activate or deactivate a spatial relation for a PUCCH resource, the command comprising an indication of a PUCCH group to which the PUCCH resource belongs;
Step 720: performing one of activating and deactivating the spatial relation for the PUCCH resource.
Step 810: determining a PUCCH group to which a PUCCH resource belongs.
Step 820: sending, to the wireless device, a command to activate or deactivate a spatial relation for the PUCCH resource, the command comprising an indication of the PUCCH group to which the PUCCH resource belongs.
Turning to
Step 1310: receiving, from a network node, a command to activate or deactivate a spatial relation for a PUCCH resource, wherein each PUCCH of the different PUCCH groups is uniquely identified in the command; and
Step 1320: performing one of activating and deactivating a spatial relation for the PUCCH resource identified in the command.
In some examples, the method may receive a Medium Access Control (MAC) Control Element (CE), such as an enhanced 3GPP TS 38.321 Release 15 MAC CE or a Release 16 MAC CE.
In some examples, the PUCCH resources of a first PUCCH group can be concatenated with PUCCH resources of a second PUCCH group.
In some examples, each PUCCH resource can be uniquely identified by using a PUCCH resource Identifier (ID) and a PUCCH group ID. For example, the PUCCH group ID can be a PUCCH Config ID.
In some examples, each PUCCH resource can be uniquely identified by using a PUCCH resource Identifier (ID) that is different for each PUCCH group. For example, the PUCCH resources for the different PUCCH groups can be concatenated. However, the PUCCH resources don't have to be in order, since they are uniquely identified.
In some examples, the command can comprise a PUCCH spatial relation for a plurality of PUCCH resources. For example, the plurality of PUCCH resources can belong to different PUCCH groups (or PUCCH resource configuration groups).
In some examples, the command may comprise a group ID, the group ID identifying the plurality of PUCCH resources to which the same PUCCH spatial relation is applied.
Now, turning to
Step 1360: determining a PUCCH group to which a PUCCH resource belongs.
Step 1370: sending, to the wireless device, a command to activate or deactivate a spatial relation for the PUCCH resource, wherein each PUCCH resource of the different PUCCH groups is uniquely identified in the command.
In some examples, the method may send a Medium Access Control (MAC) Control Element (CE), such as an enhanced 3GPP TS 38.321 Release 15 MAC CE or a Release 16 MAC CE.
In some examples, the PUCCH resources of a first PUCCH group can be concatenated with PUCCH resources of a second PUCCH group.
In some examples, each PUCCH resource can be uniquely identified by using a PUCCH resource Identifier (ID) and a PUCCH group ID. For example, the PUCCH group ID can be a PUCCH Config ID.
In some examples, each PUCCH resource can be uniquely identified by using a PUCCH resource Identifier (ID) that is different for each PUCCH group. For example, the PUCCH resources for the different PUCCH groups can be concatenated. However, the PUCCH resources don't have to be in order, since they are uniquely identified.
In some examples, the command can comprise a PUCCH spatial relation for a plurality of PUCCH resources.
In some examples, the plurality of PUCCH resources can belong to different PUCCH groups.
In some examples, the command can comprise a group ID, the group ID identifying the plurality of PUCCH resources to which the same PUCCH spatial relation is applied.
As an example, UE 910 may communicate with radio network node 920 over a wireless interface. That is, UE 910 may transmit wireless signals to and/or receive wireless signals from radio network node 920. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage associated with a radio network node 920 may be referred to as a cell.
It should be noted that a UE may be a wireless device, a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iPAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Universal Serial Bus (USB) dongles, Customer Premises Equipment (CPE) etc.
In some embodiments, the “network node” can be any kind of network node which may comprise of a radio network node such as a radio access node (which can include a base station, radio base station, base transceiver station, base station controller, network controller, gNB, NR BS, evolved Node B (eNB), Node B, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU), Remote Radio Head (RRH), a multi-standard BS (also known as MSR BS), etc.), a core network node (e.g., MME, SON node, a coordinating node, positioning node, MDT node, etc.), or even an external node (e.g., 3rd party node, a node external to the current network), etc. The network node may also comprise a test equipment.
In certain embodiments, network nodes 920 may interface with a radio network controller (not shown). The radio network controller may control network nodes 920 and may provide certain radio resource management functions, mobility management functions, and/or other suitable functions. In certain embodiments, the functions of the radio network controller may be included in the network node 920. The radio network controller may interface with the core network node 940. In certain embodiments, the radio network controller may interface with the core network node 940 via the interconnecting network 930.
The interconnecting network 930 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. The interconnecting network 930 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.
In some embodiments, the core network node 940 may manage the establishment of communication sessions and various other functionalities for wireless devices 910. Examples of core network node 940 may include MSC, MME, SGW, PGW, O&M, OSS, SON, positioning node (e.g. E-SMLC), MDT node, etc. Wireless devices 110 may exchange certain signals with the core network node 940 using the non-access stratum layer. In non-access stratum signaling, signals between wireless devices 910 and the core network node 940 may be transparently passed through the radio access network. In certain embodiments, network nodes 920 may interface with one or more other network nodes over an internode interface. For example, network nodes 920 may interface each other over an X2 interface.
Although
In some embodiments, the functionality of the wireless device 910 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1020 and executed by the processor(s) 1010. For example, the processor 1010 is configured to perform method 700 of
In some embodiments, a computer program including instructions which, when executed by the at least one processor 1010, causes the at least one processor 1010 to carry out the functionality of the wireless device 910 according to any of the embodiments described herein is provided (e.g. method 700 of
The cloud computing environment 1200 comprises one or more general-purpose network devices including hardware 1230 comprising a set of one or more processor(s) or processing circuits 1260, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or special purpose processors, and network interface controller(s) (NICs) 1270, also known as network interface cards, which include physical Network Interface 1280. The general-purpose network device also includes non-transitory machine readable storage media 1290-2 having stored therein software and/or instructions 1295 executable by the processor 1260. During operation, the processor(s)/processing circuits 1260 execute the software/instructions 1295 to instantiate a hypervisor 1250, sometimes referred to as a virtual machine monitor (VMM), and one or more virtual machines 1240 that are run by the hypervisor 1250.
A virtual machine 1240 is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine; and applications generally do not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, though some systems provide para-virtualization which allows an operating system or application to be aware of the presence of virtualization for optimization purposes. Each of the virtual machines 1240, and that part of the hardware 1230 that executes that virtual machine 1240, be it hardware 1230 dedicated to that virtual machine 1240 and/or time slices of hardware 1230 temporally shared by that virtual machine 1240 with others of the virtual machine(s) 1240, forms a separate virtual network element(s) (VNE).
The hypervisor 1250 may present a virtual operating platform that appears like networking hardware to virtual machine 1240, and the virtual machine 1240 may be used to implement functionality such as control communication and configuration module(s) and forwarding table(s), this virtualization of the hardware is sometimes referred to as network function virtualization (NFV). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in Data centers, and customer premise equipment (CPE). Different embodiments of the instance or virtual application 1220 may be implemented on one or more of the virtual machine(s) 1240, and the implementations may be made differently.
In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier can be a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
Some embodiments may be represented as a non-transitory software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein). The machine-readable medium may be a compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to the described embodiments. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine-readable medium. Software running from the machine-readable medium may interface with circuitry to perform the described tasks.
The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description, which is defined solely by the appended claims.
The application claims the benefits of priority of U.S. Provisional Patent Application No. 62/972,429, entitled “PUCCH Enhancements with Multiple PUCCH Configs” and filed at the United States Patent and Trademark Office on Feb. 10, 2020, the content of which is incorporated herein by reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2020/061987 | 12/15/2020 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 62972429 | Feb 2020 | US |
