|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When I first studying on 5G Beam Management based on 3GPP, the image in my mind (whether it is correct or not) was that the beam management is mostly about Network activity, it is mostly passive in UE's perspective except the initial beam selection. My image was something like this i) Network informs the UE of the detailed information about all the beams it uses based on all the possible codebooks defined in 3GPP. ii) UE performs the measurement for each of the beam and send the report to NW. iii) Network explicitely direct UE to use a specific beam based on the measurement report. In this scenario, UE just have passive roles.. that is just perform the measurement and send it to network and tune its beam as directed by Network. But in reality (at least up to now, Mar 2022) I don't think this kind of fully network guided / closed loop type of beamforming happens at the full maturity. In most case (especially for FR2 where beam management is expected to play a crucial role), Network just provides UE with some guidence of the beam selection/change with relatively long interval (like every 20ms interval or longer) and UE should play active roles to adjust its own Rx beam at every slot to maintain the best radio link to network beam (TRP). In this note, I will try to explain how those active roles on UE side happens. Actually the algorithms and implementation is mainly up to each modem protocol stack implementation (not explicitely defined in 3GPP) and I am not supposed to mention about any specific implementation. I will just to try explain overall (generic) way of UE side beam management based on those materials available in public domain (check out the reference section).
Antenna Modules on the PhoneFor mmWave, most of UE (actually all of the UE as far as I know of) has multiple antenna module on the device (The exact number of antenna modules on the device is up to UE manufacturer. As far as I have observed, the minimum number was two and the max number is 4). Why multiple antenna ? As you know, it is not feasible to transmit the signal in omni direction from TRP (gNB transmittion antenna). It will transmit the signal in the form of beam (i.e, radiation in a certain restricted range of angles in spherical cordinate) and the direction and angular width of the beam varies very quickly depending on situation. In order to receive those varying beam in any condition, ideally the Rx antenna (UE antenna) should be omni directional, but implmenting omni antenna at mmWave on UE side is also not feasible. As an alternative, you may implement one big antenna array with wide range of weighting factors (codebook) that can cover very wide range. This may be possible but inefficient because user may change the angular position of UE often and even more seriously the antenna module can be blocked by user's hand or any other obstacle. If UE has only one antenna module, the connection would drop if that one antenna is blocked. Therefore, the most widely adopted solution is to put multiple antenna module on the UE and select the best module at a specific moment (e,g, at a specific slot). I think following placement of antenna module was the first generation of mmWave UE antenna (likely to be suggested by Modem manufacturer). Source : Qualcomm QTM052 mmWave Antenna Module Analysis (YouTube) For more specific information about Antenna placement and some characteristics open to public space, you may search in FCC document. As far as I observed, SamSung is most open for sharing the details in FCC document. I haven't seen any other manufacturer sharing as detailed information as SamSung. Following is one example. Source : FCC ID: A3LSMG977U (SamSung) - Test Setup Photos For the details of characterizations of each antenna modules and beam ID of the SamSung device shown above is described in details in this FCC document : Power Density Simulation Report - FCC ID : A3LSMG977U How do the multiple antenna work ?Usually each of the antenna modules on UE is an array antenna made up of multiple antenna elements (As far as I know, all the antenna module on current UE is 1D array antenna(Uniform Linear Array) and I haven't seen 2D array(Uniform Rectangular Array) as of yet). By changing the weighting factor for each antenna elements in a module (the set of weighting factors are called Codebook), each module can form beams with various direction and width as depicted below. At a specific moment of reception (at specific slots receiving DL signal), only one specific beam on a specific module gets active. So the big.. big... big... question is how UE can figure out the best module and best beam at each and every specific slot. This is completely upto modem algorithm and nothing to be shared in public. But you may get some general idea from various papers as explained in next section. a codeword is a set of analog phase shift values, or a set of magnitude plus phase shift values, applied to the antenna elements, in order to form an analog beam You may get some intuitive understanding on this mechanism acting in live can be seen in the YouTube video as linked below. You would get much better understanding just by watching this single video than reading my notes 10 times (a picture is worth of a thousand words :) Source : 5G Mobile mmWave OTA Test Network (YouTube) Optional Reading : This is direct quote from this paper : Beam Codebook Design for 5G mmWave Terminals. You may skip this if you are not specifically interested in this area or you think this is too much reading. This part is not essential to get the idea of this note. this is more for my person reading for future reference.
What do we have to know of the Antenna Characteristics ?According to Beam Codebook Design for 5G mmWave Terminals, the factors affecting the codebook design can be listed as follows
If you take all of these into consideration, you would have almost infinite permutations of factors which is impossible to implement. Even with much restricted set of factors assuming linear microstrip patch with 4 antenna elements within a module (L = 4), 2 bit resolution of phase shifter (b = 2) and codebook size = 4 (K=4), the exhastive search space for finding optimal codebook is 2^(b L K) = 2^(2*4*4) = 2^32 which is not feasible to implement. So modem manufacturer needs to come out with some special procedure to find much smaller set of permutations which are closer to optimal solution. Once you identify codebook, you may visualize the performance of each codeword as shown below to communicate about the characteristics of each beam created by each codeword. Only one of the beam is active at a specific Tx and Rx timing (usually in a slot). You may notice that each of the beam is pretty directional which covers only a small area in spherical coordinates and you need to consider the coverage of each beam when you are testing the UE performance in mmWave. Source : Beam Codebook Design for 5G mmWave Terminals Eventually what you need to get is heat map (e.g, heat map for Tx power, Rx power, Sensitivity etc) for every codebook elements, antenna module and the composite of all the codebook elements for varous scenario. Source : First 5G mmWave Antenna Module for Smartphones Testing in the LabPractically I think it is almost impossible to duplicate in the lab live-network environment for beam management, but still you may do a lot of testing for mmWave in the lab. I don't think you can easily perform such a test in the lab for fast sweeping beam or differetiation between Narrow beam and Widebeam and differentiation between with QCL and without QCL etc in the lab environment, but you can still perform many kinds of static / semi-static beam and just chaning power and direction of the beam among only a few different directions. First thing you need to do for lab testing is to find the proper chamber for the test. There are roughly three types of chambers availble in the market. Whitebox/line of sight Chamber, CATR Chamber and MPAC chamber. Ideally it would be the best to use MPAC to create an environment and beam variation close to live network, but there would be many technicall challenges to properly operate the chamber and cost issues as well. By the time you may need MPAC chamber, most people would take the device out in the field and do test in live. I think most common type of chamber being used in the lab is whitebox type of chamber as illustrated below. If your situation allows, you may have more versatile chamber as shown below and perform more diverse and realistic beam management test. Source : Edited from Introducing Keysights F9660A 3D MPAC OTA Chamber Once you got a chamber, you may perform various steps of test as listed below. Each of the test in the list would take a lot of time and effort until you reach a certain maturity level.
Snapshot of RRM TestFor a few years at early phase of 5G, Beam Related testing was mostly planned and performed by research and creativity of modem manufacturer, UE manufacturer and network infra vendor because there was no common specification for the test. In those period, everybody have done a little bit different set of tests. So passing the tests in one party (modem vendor or UE vendor or live network) does not guarantee working in other party. In those days, live network configuration played the role of ultimate reference, but in many cases it is hard to duplicate the live network configuration with lab test equipment and even those live network configuration varies widely depending on vendors and network operators. Now (as of Mar 2022) I see 3GPP RRM Test Specification (38.533) is pretty mature. Even though it seems much simpler than live network situation, at least now we have some common RRC configuration and Beam Setup that is expected to pass with every UE. What I am trying to do in this section is to put some key parameters and procedures based on FR2 RRM test. I am not trying to duplicate RRM specification as it is. I will just try to put some big picture of those RRM test with the reference to the original document so that you can find the corresponding specification more easily. SSB for FR2 CSC 120This is based on 38.533-Table A.3.2-1: SSB allocation for FR2
RACH Configuration for FR2
RACH-ConfigCommon ::= SEQUENCE { rach-ConfigGeneric RACH-ConfigGeneric, totalNumberOfRA-Preambles INTEGER (1..63) OPTIONAL, -- Need S ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE { oneEighth ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, oneFourth ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, oneHalf ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, one ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, two ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32}, four INTEGER (1..16), eight INTEGER (1..8), sixteen INTEGER (1..4) } OPTIONAL, -- Need M groupBconfigured SEQUENCE { ra-Msg3SizeGroupA ENUMERATED {b56, b144, b208, b256, b282, b480, b640, b800, b1000, b72, spare6, spare5,spare4, spare3, spare2, spare1}, messagePowerOffsetGroupB ENUMERATED { minusinfinity, dB0, dB5, dB8, dB10, dB12, dB15, dB18}, numberOfRA-PreamblesGroupA INTEGER (1..64) } OPTIONAL, -- Need R ra-ContentionResolutionTimer ENUMERATED { sf8, sf16, sf24, sf32, sf40, sf48, sf56, sf64}, rsrp-ThresholdSSB RSRP-Range OPTIONAL, -- Need R rsrp-ThresholdSSB-SUL RSRP-Range OPTIONAL, -- Cond SUL prach-RootSequenceIndex CHOICE { l839 INTEGER (0..837), l139 INTEGER (0..137) }, msg1-SubcarrierSpacing SubcarrierSpacing OPTIONAL, -- Cond L139 restrictedSetConfig ENUMERATED {unrestrictedSet, restrictedSetTypeA, restrictedSetTypeB}, msg3-transformPrecoder ENUMERATED {enabled} OPTIONAL, -- Need R ..., [[ ra-PrioritizationForAccessIdentity-r16 SEQUENCE { ra-Prioritization-r16 RA-Prioritization, ra-PrioritizationForAI-r16 BIT STRING (SIZE (2)) } OPTIONAL, -- Cond InitialBWP-Only prach-RootSequenceIndex-r16 CHOICE { l571 INTEGER (0..569), l1151 INTEGER (0..1149) } OPTIONAL -- Need R ]] }
RACH-ConfigDedicated ::= SEQUENCE { cfra CFRA OPTIONAL, -- Need S ra-Prioritization RA-Prioritization OPTIONAL, -- Need N ..., [[ ra-PrioritizationTwoStep-r16 RA-Prioritization OPTIONAL, -- Need N cfra-TwoStep-r16 CFRA-TwoStep-r16 OPTIONAL -- Need S ]] }
CFRA ::= SEQUENCE { occasions SEQUENCE { rach-ConfigGeneric RACH-ConfigGeneric, ssb-perRACH-Occasion ENUMERATED {oneEighth, oneFourth, oneHalf, one, two, four, eight, sixteen} OPTIONAL -- Cond Mandatory OPTIONAL, -- Need S } resources CHOICE { ssb SEQUENCE { ssb-ResourceList SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource, ra-ssb-OccasionMaskIndex INTEGER (0..15) }, csirs SEQUENCE { csirs-ResourceList SEQUENCE (SIZE(1..maxRA-CSIRS-Resources)) OF CFRA-CSIRS-Resource, rsrp-ThresholdCSI-RS RSRP-Range } }, ..., [[ totalNumberOfRA-Preambles INTEGER (1..63) OPTIONAL -- Cond Occasions ]] }
CFRA-TwoStep-r16 ::= SEQUENCE { occasionsTwoStepRA-r16 SEQUENCE { rach-ConfigGenericTwoStepRA-r16 RACH-ConfigGenericTwoStepRA-r16, ssb-PerRACH-OccasionTwoStepRA-r16 ENUMERATED {oneEighth, oneFourth, oneHalf, one, two, four, eight, sixteen} } OPTIONAL, -- Need S msgA-CFRA-PUSCH-r16 MsgA-PUSCH-Resource-r16, msgA-TransMax-r16 ENUMERATED {n1, n2, n4, n6, n8, n10, n20, n50, n100, n200} OPTIONAL, -- Need S resourcesTwoStep-r16 SEQUENCE { ssb-ResourceList SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource, ra-ssb-OccasionMaskIndex INTEGER (0..15) }, ... }
CFRA-SSB-Resource ::= SEQUENCE { ssb SSB-Index, ra-PreambleIndex INTEGER (0..63), ..., [[ msgA-PUSCH-Resource-Index-r16 INTEGER (0..3071) OPTIONAL -- Cond 2StepCFRA ]] }
CFRA-CSIRS-Resource ::= SEQUENCE { csi-RS CSI-RS-Index, ra-OccasionList SEQUENCE (SIZE(1..maxRA-OccasionsPerCSIRS)) OF INTEGER (0..maxRA-Occasions-1), ra-PreambleIndex INTEGER (0..63), }
RACH-ConfigGeneric ::= SEQUENCE { prach-ConfigurationIndex INTEGER (0..255), msg1-FDM ENUMERATED {one, two, four, eight}, msg1-FrequencyStart INTEGER (0..maxNrofPhysicalResourceBlocks-1), zeroCorrelationZoneConfig INTEGER(0..15), preambleReceivedTargetPower INTEGER (-202..-60), preambleTransMax ENUMERATED {n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200}, powerRampingStep ENUMERATED {dB0, dB2, dB4, dB6}, ra-ResponseWindow ENUMERATED {sl1, sl2, sl4, sl8, sl10, sl20, sl40, sl80}, ..., [[ prach-ConfigurationPeriodScaling-IAB-r16 ENUMERATED {scf1,scf2,scf4,scf8,scf16,scf32,scf64} OPTIONAL, -- Need R prach-ConfigurationFrameOffset-IAB-r16 INTEGER (0..63) OPTIONAL, -- Need R prach-ConfigurationSOffset-IAB-r16 INTEGER (0..39) OPTIONAL, -- Need R ra-ResponseWindow-v1610 ENUMERATED { sl60, sl160} OPTIONAL, -- Need R prach-ConfigurationIndex-v1610 INTEGER (256..262) OPTIONAL -- Need R ]] } CSI-RS Configuration for FR2< 38.533 v16,4-Table A.1.4.2-3: CSI-RS Reference Measurement Channels for SCS = 120 kHz for TDD >
CSI-RS Configuration for tracking for FR2
Reference : Paper / White Paper /Journels
Reference : YouTube / Webinar
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||