|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
According to R1-1700771, QCL is defined as follows : Two antenna ports are said to be quasi co-located if properties of the channel over which a symbol on one antenna port is conveyed can be inferred from the channel over which a symbol on the other antenna port is conveyed Don't get disappointed if this does not sound clear to you. It is same to me as well. I may not understand the detailed physics and mathematics behind this forever, but I think I need to know at least some high level parameters about this. It will take long time to get real / practical meaning of this statement. If you are familiar with the definition of Antenna port in LTE, you would noticed that the definition shown here is very similar to Antenna Port in LTE except a couple of words. Simply put you may think that Antenna port defines the correlation between symbols within a same antenna port and QCL defines the correlation between symbols from different antenna ports.
QCL TypesQCL types in 5G NR define how one signal can serve as a reference for another in terms of their physical layer behavior. NR uses many beams and reference signals, so the UE must know which parameters can be safely inherited when decoding a target channel. QCL types describe this inheritance. Each type specifies which characteristics—such as Doppler shift, Doppler spread, average delay, delay spread, or spatial receive parameters—are assumed to be similar between two signals. By defining these relations, the network can let the UE reuse channel estimation and spatial filtering from a known reference signal, which reduces processing load and enables fast beam switching for both control and data channels. 38.214 - 5.1.5 Antenna ports quasi co-location" defines four difference types of QCL as listed below.
What does it really mean ?I wrote about the formal definition of QCL and the types of QCL. What does it really mean ? When somebody says 'A signal (A) is QCLed (Quasi Colacated) with another signal (B)', do you really understand what this mean ? I would say in my own words as follows. i) The two signal (A) and (B) has gone through very similar channel condition. ii) In order for (A) and (B) to go through the similar channel, it is highly likely that they are from the same location(i.e, same place and same antenna). ==> More specifically, it implies that the signal (A) and (B) are transmitted from the same TRP(Antenna Array) that applies the same Spatial Filter. iii) Since the two signal reaches the reciever through similar channel, if the reciever can detect one of the signal (e.g, Signal A) and figure out the channel properties of the signal, it will greatly help to detect the other signal (e.g, Signal B). Let me give you more concrete example using NR terminology. What would it mean if I say 'the PDCCH from a gNB is QCLed with SSB'. What would this mean ? I would mean that the PDCCH went through the similar channel condition as SSB. The channel information estimated to detect SSB can help detect PDCCH as well. Now let's get into just a little bit deeper. When you say 'channel condition', what does it exactly mean ? There can be a lot of factors that defines the channel condition, but current 3GPP defines several parameters to define the channel condition as listed below.
One or more of these factors would form a property of the channel that two signal shares and the predefined group of these factors are labeled as QCL type that is mentioned in previous section. Putting all these togother, we can define the relationship of two related signal like ... 'The PDCCH signal from the gNB is QCLed with SSB via Type C'. This mean that the PDCCH and the SSB went through the similar radio channel sharing the similar properties in terms of Average Delay and Doppler Shift. What is TCI ?In 5G NR, TCI in 5G NR is an index that tells the UE which downlink transmission beam the gNB will use. TCI works as a mechanism that lets the UE know which beam it should use when receiving downlink control or data. NR relies on highly directional beams, especially in mmWave, so the UE cannot monitor every direction at once. It must know the exact spatial relation between the beam used for reference measurements and the beam used for actual transmission. TCI provides this link. A TCI state points to a known signal such as an SSB or CSI-RS. The UE has already measured these signals, so it can align its receiver based on that reference. The technical foundation of TCI is the QCL relation. A TCI state defines how a target channel, like PDCCH or PDSCH, relates to the reference signal. When the network activates a TCI state, it is telling the UE that the physical characteristics of the target channel are similar to those of the reference. These characteristics include Doppler components, timing parameters, delay spread, and spatial direction. The UE can reuse the estimation it made for the reference signal and apply it to the actual data, which greatly reduces overhead and allows the gNB to switch beams quickly. Among the QCL relations, QCL-TypeD plays a major role for beamforming. This type tells the UE that the spatial receive parameters of the actual data channel are the same as those of the reference. In simple terms, the UE should use the same receive beam or receive filter for the PDSCH/PDCCH as it used for the CSI-RS or SSB that the TCI state points to. Without this indication, the UE would not know which direction to steer its antenna array. For lower-frequency bands, other QCL types like TypeA help the UE match timing and frequency parameters by inheriting delay and Doppler information from the reference. TCI signaling follows a multi-step structure to keep the system flexible without creating huge overhead. The gNB first configures a large set of potential TCI states through RRC. This set can be very large because the UE may support many beams. Using all of these directly in DCI would be too costly, so the next step uses a MAC-CE to select a small active subset. Then the DCI references only the small active subset using a few bits. This design lets the gNB change beams quickly for a mobile UE without sending heavy RRC signaling every time. In Release 17, NR introduced the Unified TCI concept. Earlier versions required separate TCI states for each channel or direction. Unified TCI allows a single TCI indication to apply to multiple downlink channels, multiple serving cells, and even uplink transmission beams. This creates a common beam relation between uplink and downlink. It also reduces the amount of signaling needed for beam pair management and keeps the transmit and receive beams aligned with the network’s intended spatial strategy.
Triggering TCITriggering TCI in 5G NR is a step-by-step process that links higher-layer beam configuration with real downlink transmission. The gNB first provides the UE with all possible TCI states through RRC so the UE knows the beam candidates and their QCL relations. Later, the network activates one of these states dynamically using a MAC-CE, which is carried on a PDSCH scheduling. After receiving this activation command, the UE completes the normal HARQ process for that PDSCH. Once the HARQ timing boundary is passed, the TCI indicated by DCI becomes effective. This sequence allows the network to switch beams quickly without sending heavy reconfiguration messages each time, keeping mobility and beam tracking efficient even under fast channel variation. This process is summarized in a table shown below. I wrote this table based on the descriptions in "38.214 - 5.1.5 Antenna ports quasi co-location"
Mapping between QCL-Type configurations and TCI-RS-Set / DMRSWhich QCL-Type is applied is determined by TCI-RS-Set and DMRS. "38.214 - 5.1.5 Antenna ports quasi co-location" states about the mapping between QCL-Type and TCI-RS-Set as follows. The statement in this specification is not so clear (actually confusing) to me. I am not 100% confident on whether I interpreted correctly or not. Feel free to let me know if you have any different interpretation. < QCL for CSI Resource >This section shows how QCL is applied to CSI resources through the TCI-RS-Set configuration. In NR, a TCI state can point either to SSB or to an NZP-CSI-RS resource, and the actual QCL type depends on how the CSI resource set is configured, such as periodic vs aperiodic, trs-Info on/off, and repetition settings. The table summarizes, for each CSI-RS configuration, which QCL type (A, C, or D) the TCI state is allowed to indicate and which signal becomes the QCL reference (SS/PBCH block or NZP-CSI-RS resource). The examples in each row illustrate the concrete RRC structure with tci-StateId, referenceSignal and qcl-Type fields, so you can map a specific configuration in the spec to the actual QCL relation used for beam and timing inheritance. When configuring the Quasi-Co-Location (QCL) relationships for CSI-RS resources, the valid QCL types and reference signals are strictly dictated by the specific setup of the NZP-CSI-RS-ResourceSet, particularly depending on whether the resource is designated as a Tracking Reference Signal via trs-Info or configured for beam sweeping via the repetition parameter. For example, when a periodic resource set is configured with trs-Info set to true, implying it is used for fine time/frequency tracking, the TCI state typically maps to an SS/PBCH block using QCL-TypeC for synchronization properties, often combined with QCL-TypeD for spatial reception if applicable. Conversely, for aperiodic resources or standard configurations where trs-Info and repetition are absent, the structure is more flexible, allowing the TCI state to reference either a parent CSI-RS or an SSB using QCL-TypeA or QCL-TypeB, ensuring the User Equipment correctly inherits Doppler, delay, and spatial parameters from the appropriate source signal in the hierarchy. The following table summarizes severl use cases of TCI configuration described as below :
< QCL for CSI DMRS >QCL for CSI DMRS defines how the UE should interpret the downlink DMRS for PDCCH and PDSCH when the gNB indicates a TCI state. Since DMRS decoding depends heavily on correct timing, Doppler, and spatial alignment, the TCI state must point to a CSI-RS resource whose physical properties can be inherited by the DMRS. The mapping depends on how the CSI-RS resource set is configured—specifically whether it has trs-Info, whether it is part of an NZP-CSI-RS-ResourceSet with repetition, and whether QCL-TypeD can be applied. The table summarizes the allowed QCL-TypeA and TypeD combinations for both PDCCH DMRS and PDSCH DMRS, showing which CSI-RS resources can serve as the QCL reference for DMRS estimation under each configuration. This allows the UE to reuse CSI-RS-based channel estimation to correctly demodulate downlink signals with minimal overhead.
How UE figure out TCI-State for PDCCH for each specific moment ?Figuring out which TCI-State the UE should use for PDCCH at any specific moment is a multi-stage filtering process. The network first defines a large pool of possible TCI-States in the tci-StatesToAddModList inside PDSCH-Config. From this pool, the gNB selects a smaller, PDCCH-specific subset and places it into the tci-StatesPDCCH-ToAddList of the ControlResourceSet. Only these selected states are candidates for actual PDCCH operation. Finally, at runtime, the gNB activates one of these states through a UE-specific PDCCH MAC CE, telling the UE exactly which beam and QCL relationship to use for decoding the control channel at that moment. This staged approach lets the network preconfigure many beam options while switching dynamically with minimal signaling. The process of applying TCI for this case is summarized as follows. Step 1 : A TCI State table called 'tci-StatesToAddModList' is defined in PDSCH-Config. The max size of the table is 128. Step 2 : Select a subset of the tables from tci-StatesToAddModList and put them into ControlResourceSet.tci-StatesPDCCH-ToAddList. The max size of this table is 64. Step 3 : Apply a specific tci-States defined in Step 2 via TCI State Indication for UE-specific PDCCH MAC CE. How UE figure out TCI-State for downlink data PDSCH for each specific moment ?Understanding how the UE figures out the correct TCI-State for PDSCH is tricky because the specification spreads the logic across several conditions and signaling paths. The core idea is that the UE must map a small runtime indicator—either inherited from the PDCCH configuration or explicitly sent in DCI—into a fully defined TCI-State that tells the UE which beam and QCL relation to use for decoding downlink data. When DCI does not explicitly carry a TCI field, the UE simply reuses the TCI-State that was already applied for the CORESET/PDCCH. When DCI does include a TCI field, the UE must interpret a small codepoint value and map it back to one of the preconfigured TCI-States. This mapping requires a two-stage setup: first building a large list of all possible TCI-States defined in PDSCH-Config, and then selecting a much smaller active subset using a MAC CE. At scheduling time, the value in DCI 1_1 points to one entry in this reduced table. This layered process allows the network to predefine many beam options while signaling only a few bits per transmission, but it also explains why the procedure feels complicated when first reading the specification. There are roughly two cases we can think of configuring TCI-State on UE side. This process is described in very complicated way (at least to me) in 38.214 and it was hard for me to get some big picture. Followings are what I interpret the specification. In this case, UE used TCI state for CORESET/PDCCH as the TCI state for PDSCH. it means TCI state for PDSCH = TCI state for CORESET/PDCCH In this case, UE used TCI specified in DCI 1_1. Sound simple ? It may look simple, but the problem is that TCI field in DCI 1_1 is just a number ranging 0 through 7. It does not have any details in it. This is where the complication /confusion comes in. Following is what I understand (but some possibility of errors. please let me know if you don't agree with my understanding). It goes in a few steps as follows. Step 1 : A TCI State table called 'tci-StatesToAddModList' is defined in PDSCH-Config. The max size of the table is 128. Step 2 : Select a subset of the tables from tci-StatesToAddModList and put them into a smaller table 'codepoint'. This is done by the 'TCI States Activation/Deactivation for UE-specific PDSCH MAC CE'. The max size of this table is 8. Step 3 : For each PDSCH scheduling, the TCI field(Transmission Configuration Indication) field in DCI 1_1 indicate a specific index of the table defined in Step 2. Examples of TCI configuration in RRCOne of the realities behind QCL is that it is extremely difficult to grasp the actual meaning of the relationships it defines. Even harder than understanding the concept itself is understanding how those relationships are encoded inside the RRC signaling messages. The specification distributes these definitions across several sections, so it becomes challenging to visualize how a TCI configuration in RRC eventually connects to the physical-layer behavior you see on the air. The purpose of the example shown here is to give a broader picture of how these pieces fit together, especially for the PDSCH case where TCI interacts directly with CSI measurement configurations. In PDSCH configuration, the TCI index is tied to the CSI measurement setup, so the reference signal used in a TCI-State must correspond to a CSI-RS resource that is already defined under csi-MeasConfig. This linkage ensures that the UE can rely on measured CSI-RS resources when interpreting the QCL parameters included in each TCI-State. Conceptually, the flow looks like this: the tci-StatesToAddModList inside PDSCH-Config creates a pool of TCI-States, each containing a QCL-Info structure pointing to a specific reference signal. That reference signal, in turn, must correspond to an entry within nzp-CSI-RS-ResourceToAddModList under csi-MeasConfig, because only those CSI-RS resources have meaningful channel measurements for the UE to reuse. By connecting the TCI-State’s referenceSignal field to the CSI-RS resource index, RRC ensures that every beam configuration indicated by TCI has a valid measurement anchor. This linkage is what eventually enables the UE to apply QCL rules and interpret the beam direction, timing, or spatial characteristics correctly during PDSCH reception. TCI index in PDSCH is associated with csi-MeasureConfig as below. PDSCH-Config. --> CSI-MeasConfig.
Example 1 > PDCCH QCLed with SSBIn this example, the PDCCH beam is directly tied to specific SSBs through QCL, and each TCI-state in the ControlResourceSet is mapped to one of the TCI-states defined in the PDSCH configuration. Each of these TCI-states carries QCL-Info that points to a particular SSB index, meaning the UE interprets the PDCCH beam as being quasi-co-located with that SSB. This creates a simple and intuitive structure: the TCI-state IDs used by the PDCCH are effectively aliases for TCI-states in the PDSCH-Config, and those states, in turn, inherit their spatial and timing characteristics from the corresponding SSB. As a result, the UE can receive PDCCH with the same beam direction and QCL properties that were already established through SSB measurements, keeping the control-channel decoding aligned with the broadcast synchronization beams.
Following is the bulletized description of the illustration
Example 2 > PDCCH QCLed with CSI-RSIn this example, the PDCCH beam is tied not to SSBs but to specific NZP-CSI-RS resources, and the mapping is performed through TCI states defined in PDSCH-Config. Each TCI-state used by the PDCCH points to a TCI-state in the tci-StateToAddModList, and that TCI-state contains QCL-Info referencing a CSI-RS resource ID. The CSI-RS resources themselves are defined in nzp-CSI-RS-ResourceAddModList under MeasureConfig, so the UE has already measured these CSI-RS beams. As a result, the PDCCH beam is considered quasi-co-located with the selected CSI-RS resource, allowing the UE to decode PDCCH using the spatial and timing properties associated with that CSI-RS. This creates a clean linkage: PDCCH → TCI-state → QCL-Info → CSI-RS, ensuring that control-channel beamforming follows the same structure the UE has already learned from CSI measurements.
Following is the bulletized description of the illustration
Example 3 > PDCCH QCLed with SSB and CSI-RSIn this example, the PDCCH beam is allowed to reference both SSB-based and CSI-RS-based QCL sources, giving the network greater flexibility in how it aligns the control-channel beam with the UE’s measurement framework. Each PDCCH TCI-state maps to a corresponding entry in the PDSCH TCI-StateToAddModList, but those entries do not all point to the same type of reference signal. One TCI-state may use an SSB as its QCL reference while another uses an NZP-CSI-RS resource defined in the measurement configuration. Because the UE already measures both SSBs and CSI-RS resources, it can apply the correct timing and spatial parameters based on whichever reference is selected. As a result, PDCCH can switch between SSB-anchored beams and CSI-RS-anchored beams depending on coverage, mobility, or beam-management strategy, while still maintaining consistent QCL behavior for decoding.
Following is the bulletized description of the illustration
Example 4 > CSI-RS beam QCLed with SSB beamIn this example, the network aligns a large set of narrow CSI-RS beams with a smaller set of wide SSB beams, creating a structured beam-pairing relationship through TCI and QCL signaling. Each CSI-RS resource in the measurement configuration is assigned a periodicity index that ties it to a specific SSB, and the TCI-StatesToAddModList reflects this mapping by giving each CSI-RS resource a corresponding TCI-state whose referenceSignal points back to the associated SSB. As a result, even though the network transmits many finely focused CSI-RS beams for accurate beam refinement, the UE can still interpret them using the broader SSB beams as spatial anchors. This allows the UE to move smoothly from wide-beam discovery (SSB) to narrow-beam tracking (CSI-RS), while maintaining consistent QCL behavior in timing and spatial domains.
Following is an example showing the colocating a narrow beam(beam 64) with a widebeam(ssb 0). Follow the color coding for the connection as shown above. nzp-CSI-RS-ResourceToAddModList { nzp-CSI-RS-ResourceId reourceMapping { frequencyDomainAllocation row1 = '0010' nrofPorts = p1, firstOFDMSymbolInTimeDomain = 4, cdm-Type = noCDM, density = three, freqBand { startingRB = 0, nrofRBs = 68 } }, powerControlOffset = 0, powerControlOffsetSS = db0, scramblingID = 0, periodicityAndOffset = slots160:40, qcl-InfoPeriodicCSI-RS = } }
tci-StatesToAddModList { .... { tci-StateId = 12, qcl-Type1 { bwp-Id = 0, referenceSignal ssb : qcl-Type = TypeC } qcl-Type2 { bwp-Id = 0, referenceSignal ssb : qcl-Type = TypeD } } ..... }
ssb-PositionInBurst longBitmap = Following is the bulletized description of the illustration
RRC Messages on QCITCI configuration in NR is built across several RRC structures, each defining a different part of the beam-selection and QCL signaling chain. ControlResourceSet configures how PDCCH is transmitted, including the list of TCI states that the UE may use when receiving control channels. PDSCH-Config extends this concept by defining a larger pool of TCI states, each carrying QCL information that links the downlink data channel to a specific reference signal such as an SSB or CSI-RS resource. The TCI-State and QCL-Info structures provide the fundamental mapping between the target channel and its QCL source, specifying timing, frequency, or spatial equivalence through typeA, typeB, typeC, or typeD relations. NZP-CSI-RS-ResourceSet and CSI-MeasConfig define how CSI-RS resources are grouped, repeated, and tied to the UE’s measurement configuration, including the ability to associate each periodic CSI-RS with a TCI-State. These RRC elements work together to form a hierarchical signaling mechanism that allows the gNB to control beam association for PDCCH, PDSCH, and CSI-RS with minimal overhead while ensuring that the UE always knows which spatial filter and timing estimation to apply for each transmission opportunity.
ControlResourceSet ::= SEQUENCE { controlResourceSetId ControlResourceSetId, frequencyDomainResources BIT STRING (SIZE (45)), duration INTEGER (1..maxCoReSetDuration), //maxCoReSetDuration = 3 cce-REG-MappingType CHOICE { interleaved SEQUENCE { reg-BundleSize ENUMERATED {n2, n3, n6}, interleaverSize ENUMERATED {n2, n3, n6}, shiftIndex INTEGER(0..maxNrofPhysicalResourceBlocks-1) }, nonInterleaved NULL },, precoderGranularity ENUMERATED {sameAsREG-bundle, allContiguousRBs}, pdcch-DMRS-ScramblingID BIT STRING (SIZE (16)) OPTIONAL }
PDSCH-Config ::= SEQUENCE { dataScramblingIdentityPDSCH INTEGER (0..1007) OPTIONAL, dmrs-DownlinkForPDSCH-MappingTypeA SetupRelease { DMRS-DownlinkConfig } OPTIONAL, dmrs-DownlinkForPDSCH-MappingTypeB SetupRelease { DMRS-DownlinkConfig } OPTIONAL, tci-StatesToAddModList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-State OPTIONAL, -- Need N tci-StatesToReleaseList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-StateId OPTIONAL, -- Need N vrb-ToPRB-Interleaver ENUMERATED {n2, n4}, resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch}, pdsch-AllocationList SEQUENCE (SIZE(1..maxNrofDL-Allocations)) OF PDSCH-TimeDomainResourceAllocation , pdsch-AggregationFactor ENUMERATED { n2, n4, n8 } OPTIONAL, rateMatchPatternToAddModList SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPattern OPTIONAL, -- Need N rateMatchPatternToReleaseList SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPatternId OPTIONAL, -- Need N rateMatchPatternGroup1 SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPatternId OPTIONAL, -- Need R rateMatchPatternGroup2 SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPatternId OPTIONAL, -- Need R rbg-Size ENUMERATED {config1, config2}, mcs-Table ENUMERATED {qam64, qam256}, maxNrofCodeWordsScheduledByDCI ENUMERATED {n1, n2} OPTIONAL, -- Need R prb-BundlingType CHOICE { static SEQUENCE { bundleSize ENUMERATED { n4, wideband } OPTIONAL }, dynamic SEQUENCE { bundleSizeSet1 ENUMERATED { n4, wideband, n2-wideband, n4-wideband } OPTIONAL, -- Need S bundleSizeSet2 ENUMERATED { n4, wideband } OPTIONAL -- Need S } }, zp-CSI-RS-ResourceToAddModList SEQUENCE (SIZE (1..maxNrofZP-CSI-RS-Resources)) OF ZP-CSI-RS-Resource OPTIONAL, -- Need N zp-CSI-RS-ResourceToReleaseList SEQUENCE (SIZE (1..maxNrofZP-CSI-RS-Resources)) OF ZP-CSI-RS-ResourceId OPTIONAL, -- Need M aperiodic-ZP-CSI-RS-ResourceSetsToAddModList SEQUENCE (SIZE (1..maxNrofZP-CSI-RS-Sets)) OF ZP-CSI-RS-ResourceSet OPTIONAL, -- Need N aperiodic-ZP-CSI-RS-ResourceSetsToReleaseList SEQUENCE (SIZE (1..maxNrofZP-CSI-RS-Sets)) OF ZP-CSI-RS-ResourceSetId OPTIONAL, -- Need N sp-ZP-CSI-RS-ResourceSetsToAddModList SEQUENCE (SIZE (1..maxNrofZP-CSI-RS-Sets)) OF ZP-CSI-RS-ResourceSet OPTIONAL, -- Need N sp-ZP-CSI-RS-ResourceSetsToReleaseList SEQUENCE (SIZE (1..maxNrofZP-CSI-RS-Sets)) OF ZP-CSI-RS-ResourceSetId OPTIONAL, -- Need N
... }
TCI-State ::= SEQUENCE { tci-StateId TCI-StateId, ... }
QCL-Info ::= SEQUENCE { cell ServCellIndex OPTIONAL, -- Need R bwp-Id BWPId OPTIONAL, -- Cond CSI-RS-Indicated ... }
NZP-CSI-RS-ResourceSet ::= SEQUENCE { nzp-CSI-ResourceSetId NZP-CSI-RS-ResourceSetId, nzp-CSI-RS-Resources SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-ResourcesPerSet)) OF NZP-CSI-RS-ResourceId, aperiodicTriggeringOffset INTEGER(0..4) OPTIONAL, -- Need S ... }
CSI-MeasConfig ::= SEQUENCE { nzp-CSI-RS-ResourceToAddModList SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-Resources)) OF NZP-CSI-RS-Resource OPTIONAL, .. }
NZP-CSI-RS-Resource ::= SEQUENCE { nzp-CSI-RS-ResourceId NZP-CSI-RS-ResourceId, resourceMapping CSI-RS-ResourceMapping, powerControlOffset INTEGER (-8..15), powerControlOffsetSS ENUMERATED{db-3, db0, db3, db6} OPTIONAL, -- Need R scramblingID ScramblingId, periodicityAndOffset CSI-ResourcePeriodicityAndOffset OPTIONAL,- qcl-InfoPeriodicCSI-RS TCI-StateId OPTIONAL, -- Cond Periodic ... }
CSI-RS-ResourceMapping ::= SEQUENCE { frequencyDomainAllocation CHOICE { row1 BIT STRING (SIZE (4)), row2 BIT STRING (SIZE (12)), row4 BIT STRING (SIZE (3)), other BIT STRING (SIZE (6)) }, nrofPorts ENUMERATED {p1,p2,p4,p8,p12,p16,p24,p32}, firstOFDMSymbolInTimeDomain INTEGER (0..13), firstOFDMSymbolInTimeDomain2 INTEGER (2..12) OPTIONAL, -- Need R cdm-Type ENUMERATED {noCDM, fd-CDM2, cdm4-FD2-TD2, cdm8-FD2-TD4}, density CHOICE { dot5 ENUMERATED {evenPRBs, oddPRBs}, one NULL, three NULL, spare NULL }, freqBand CSI-FrequencyOccupation, ... }
CSI-ResourcePeriodicityAndOffset ::= CHOICE { slots4 INTEGER (0..3), slots5 INTEGER (0..4), slots8 INTEGER (0..7), slots10 INTEGER (0..9), slots16 INTEGER (0..15), slots20 INTEGER (0..19), slots32 INTEGER (0..31), slots40 INTEGER (0..39), slots64 INTEGER (0..63), slots80 INTEGER (0..79), slots160 INTEGER (0..159), slots320 INTEGER (0..319), slots640 INTEGER (0..639) }
Reference
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
