NR DSS
This tutorial is about how to configure for DSS (Dynamic Spectrum Sharing) and verify it works. DSS is a mechanism by which LTE and NR share a same spectrum dynamically. Theoretically there are many different options of impementing DSS as summarized in a diagrame below. In reality, it seems that Option 2 and Option 3 are most common choice of the implementation.
Image Source : Sharetechnote
Even though Option 2 and 3 would be simpler to implement comparing to other options, there are still several factors to be considered / planned carefully to guarantee the co-operation of both LTE and NR in the same spectrum. Followings are some of these factors.
- Shifting NR CORESET
- Rate Matching around LTE CRS
- Rate Maching Around LTE PSS,SSS,PBCH
- Scheduling Symbols not cliding with any of LTE Reference Signal
Table of Contents
Introduction
Dynamic Spectrum Sharing (DSS) is a pivotal technology that enables the simultaneous deployment of LTE (Long-Term Evolution) and NR (New Radio, 5G) within the same frequency spectrum, thereby maximizing spectral efficiency and facilitating smooth network evolution. By leveraging DSS, mobile network operators can dynamically allocate spectrum resources between LTE and 5G NR users based on real-time traffic demand, device capability, and network configuration. This mechanism is especially significant in the early stages of 5G rollout, where spectrum resources are often limited and network operators must support a diverse mix of legacy and next-generation devices. Architecturally, DSS involves intricate coordination at the radio access network (RAN) level, including dynamic scheduling, control channel alignment, and interference mitigation to ensure optimal coexistence and performance for both technologies. The most widely adopted DSS implementations are based on non-MBSFN (Multicast-Broadcast Single Frequency Network) and MBSFN configurations, which allow flexible multiplexing of LTE and NR signals in time and frequency domains. The adoption of DSS accelerates 5G deployment, reduces the need for exclusive spectrum re-farming, and ensures a seamless user experience as networks transition from LTE to 5G NR. Understanding DSS, its configuration, and verification processes is crucial for network engineers, system integrators, and anyone involved in contemporary cellular network deployment and optimization.
-
Context of Dynamic Spectrum Sharing (DSS)
- DSS enables LTE and 5G NR to dynamically share the same spectrum resources, improving network flexibility and spectral efficiency.
- It is a key enabler for operators to expedite 5G rollout without waiting for dedicated spectrum allocations.
- The technology is particularly relevant in scenarios where spectrum bands are scarce or where legacy devices must continue to be supported.
-
Relevance and Importance of the Tutorial
- This tutorial provides detailed guidance on configuring DSS and verifying its operational effectiveness in a test environment.
- It addresses real-world deployment challenges, including coexistence factors such as NR CORESET shifting, LTE reference signal protection, and scheduling alignment.
- Understanding the practical aspects of DSS implementation is essential for ensuring robust network performance and seamless transition between LTE and 5G NR services.
-
Learning Outcomes
- Comprehend the underlying principles and architecture of DSS, including the most common deployment options.
- Acquire hands-on skills to configure DSS using industry-standard tools and configurations (e.g., Amarisoft callbox with gnb-dss.cfg).
- Identify and address key technical factors necessary for successful DSS operation, such as rate matching, reference signal protection, and scheduling considerations.
- Develop proficiency in verifying DSS functionality and troubleshooting common interoperability issues between LTE and NR.
-
Prerequisite Knowledge
- Familiarity with LTE and NR radio access network architecture and basic protocol operations.
- Understanding of spectrum management concepts and cellular network deployment strategies.
- Experience with network test equipment (such as Amarisoft callbox) and configuration file management.
- Basic skills in analyzing radio signal scheduling and interference scenarios.
Summary of the Tutorial
This tutorial demonstrates the test procedures for configuring, executing, and analyzing a Dynamic Spectrum Sharing (DSS) test using Amarisoft systems, with a focus on low-layer LTE and NR coexistence. The following is a structured summary of the methodology and key steps involved:
-
Test Setup:
- Utilize a single SDR card to simultaneously operate both LTE and NR cells, exploiting the DSS feature where both technologies share the same center frequency and bandwidth.
- Use the default SIM card provided by the system.
- No complicated IP layer setup is required; focus remains on the lower layers.
-
Key Configuration Parameters:
- Configure critical parameters such as ul_frequency_shift_7p5_khz, lte_crs, en_dc_scg_cell_list, dmrs_type_a_pos, and pdsch related settings.
- Set MBMS subframes and related allocation parameters for resource sharing and collision avoidance.
- Align channel bandwidth and subcarrier spacing between LTE and NR (e.g., 10 MHz, 15 kHz SCS).
-
Configuration Procedures:
- Edit and use configuration files for gNB/eNB (gnb-dss.cfg) and UEsim (ue-nr-dss.cfg), ensuring:
- ALLOW_SA is set to 1, enabling both LTE and NR initial attach.
- Both LTE and NR cells use the same RF port and spectrum.
- NR SSB is mapped into the MBSFN subframe to reduce collision.
- Measurement reporting is enabled to detect the NR cell before addition.
- DMRS Type-A position is set for NR PDSCH to avoid LTE control region overlap.
- NR PRACH subframe aligns with LTE PRACH subframe.
- NR PDSCH start symbol is set to OFDM symbol 2 or later, and x_overhead is configured to accommodate LTE CRS.
- For UEsim, configure two separate RF ports for LTE and NR connections due to its limitation.
-
Test Execution Steps:
- Verify the cell configuration, ensuring LTE and NR operate with the same bandwidth.
- Check RF information to confirm both cells are running on the same SDR card and spectrum.
- Power on the UE and perform attach procedures.
- Using command-line tools (e.g., t command), confirm both LTE and NR cells are connected on the UE.
- Generate high-rate IP data to visually confirm resource allocation between LTE and NR in the WebGUI.
-
Log Analysis:
- Verify UE capability for DSS support.
- Check MBSFN configuration in LTE SIB messages.
- Ensure NR monitoring symbols and PDSCH allocation do not overlap LTE control channel regions.
- Confirm NR SIB1 settings for frequencyShift7p5khz and PRACH configuration match configuration files.
- After LTE attach, verify UE receives measurement report for NR, enabling NR cell addition.
- Monitor physical traffic channels (PDCCH, PHICH, PUCCH, PDSCH, PUSCH) for both LTE and NR to ensure correct operation.
- Use RB map analysis for visualizing physical channel operation over time.
-
Spectrum Analysis:
- Use Amarisoft’s built-in spectrum analyzer or any suitable spectrum analyzer supporting spectrograms.
- Interpret spectrograms in conjunction with knowledge of signal structure (as color coding is power-based).
- Observe full spectrum utilization and time-domain scheduling for both LTE and NR.
This step-by-step procedure ensures proper DSS configuration, execution, and verification of concurrent LTE and NR operation on shared spectrum. The emphasis is on configuration alignment, collision avoidance, and practical validation using logs and spectrum analysis tools, with all critical steps and test methodologies preserved as described in the tutorial.
Test Setup
Test setup for this tutorial is as shown below. This is just for low layer testing, you may not need any complicated IP layer setup.
- SIM Card used in this tutorial is the one delivered with the system as it is.
- If you want to change the configuration, The tutorial Configuration Guide would help
Key Configuration Parameters
Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.
- ul_frequency_shift_7p5_khz
- lte_crs
- en_dc_scg_cell_list
- en_dc_support
- reserved_mbms_subframes : In this link, you will get the descriptions for all the items listed below
- sf_alloc
- radio_frame_allocation_period
- radio_frame_allocation_offset
- subframe_allocation
- n_symb_cch
- dmrs_type_a_pos
- n_timing_advance_offset
- ssb_pos_bitmap
- prach
- pdsch
- start_symb
- x_overhead
Configuration
I have used gnb-dss.cfg with minor change and sib2_3_nosrs.asn without any changes.
I am using the default mme, ims config as shown below.
I used ue-nr-dss.cfg which is copied and modifed from ue-nr-nsa.cfg on UEsim.
Following is the configuration in gnb-dss.cfg. In this configuration, I used SISO for simplicity and set ALLOW_SA 1 since we need to allow initial attach for both LTE and NR.
These are the two #define at the top of the file. N_ANTENNA_DL is set to 1 for SISO, and the other allowed values are 2 for MIMO 2x2 and 4 for MIMO 4x4. This define is used in more than one place in the file. It feeds n_antenna_dl of both cell_default and nr_cell_default, and it also selects the x_overhead value of the NR pdsch block described later, so changing it to 2 or 4 changes the number of resource elements reserved for LTE CRS as well.
ALLOW_SA is set to 1, which means SA and NSA NR. Setting it to 0 would keep NSA NR only. With 1, the gnb_id and the amf_list are compiled in, the NR cell gets its own plmn_list, and the NR cell broadcasts cell_barred, q_rx_lev_min and q_qual_min so that a UE can camp on it directly.
One important thing to notice in rf_driver configuration is that only one sdr card is enabled even when the two difference cell (a LTE cell and a NR cell) will be used in this test. It is because the two cell uses the exactly same rf spectrum (center frequency and bandwidth) and the scheduling in time and frequency domain over the two cell do not collide against each other.
The single device is declared with args "dev0=/dev/sdr0" and dev0 is the master. rx_antenna is set to "rx" to force the RX antenna onto the RX connector, and the sync line is left commented out so the card runs on its own clock. tx_gain is 90.0 dB and rx_gain is 60.0 dB, and both gains apply to LTE and NR at the same time because the two cells go out through the same chain.
The whole block sits under #if 1, and the #else branch would pull the gains and the device list from rf_driver/config.cfg instead. If you run this test on a system where the SDR is already described in that file, you can flip the condition and drop this block.
In this test, rf_ports for LTE is not configured.
The rf_ports array still has one entry, but the entry is empty and carries only the comment saying it is the RF port for the LTE cell. Keeping one empty entry is enough to declare rf_port 0 with its default settings, and both the LTE cell and the NR cell refer to that same port later.
en_dc_support is set to true. This is what allows the NR cell to be added to the LTE connection as a secondary cell group, and it has to be true for the EN-DC addition that we check in the log later.
Another important thing to note is that the rf_port of LTE cell (i.e, rf_port in cell_list) and the rf_port of NR cell (i.e, rf_port in nr_cell_list) are same meaning that the two cells are utilizing the same spectrum. This is understandable because the fundamental concept of DSS is to let LTE and NR cell use(share) the same spectrum.
The LTE cell is on rf_port 0 and broadcasts the PLMN 00101. dl_earfcn is 2525, which is 881.5 MHz in band 5, and this is the value that the NR cell has to match through its own dl_nr_arfcn. n_id_cell is 1, cell_id is 0x01 and tac is 0x0001. The PRACH root sequence index of the LTE cell is 28.
en_dc_scg_cell_list is set to cell_id 0x02, which is the cell_id of the NR cell defined in nr_cell_list below. This list is what tells the eNB which NR cell it may add as the secondary cell group once the UE reports it, so it has to point at the NR cell that shares the spectrum. If you add more NR cells and want a different one to be used for EN-DC, this is the entry to change.
Following is configuration for nr cell. What you need to pay attention is that rf_port in NR cell is same as the rf_port in LTE, which implies that LTE and NR shares the same RF chain.
The NR cell is on band 5 with dl_nr_arfcn 176300, which is 881.5 MHz, the same center frequency as the dl_earfcn 2525 of the LTE cell. cell_id is 0x02 and this is the cell_id that the LTE cell refers to in en_dc_scg_cell_list. The PRACH root sequence index is 1, which is different from the 28 used by LTE, so the two cells do not generate the same preamble sequences even though they share the subframe.
The plmn_list of the NR cell is inside the #if ALLOW_SA block with tac 100, plmn 00101 and reserved false. Since I set ALLOW_SA to 1, this block is compiled in and the NR cell is usable for a standalone attach as well as for the EN-DC addition.
In this test, I set the LTE channel BW to 10 Mhz by setting n_rb_dl to 50. (
n_rb_dl 50 sits in cell_default together with n_antenna_dl and n_antenna_ul, so it applies to every LTE cell in the file. The bandwidth of the NR cell is set separately in nr_cell_default and has to be brought to the same 10 MHz by hand.
Two other values in this block matter for DSS. prach_config_index is 3, which places the LTE PRACH in subframe 1 of every 10 ms, and this is the position that the NR PRACH is aligned to later. sib_sched_list points at sib2_3_nosrs.asn with si_periodicity 16 frames, which is the SIB file I left unchanged.
In this test, I configured and enabled measurement report to check the detection of NR cell betore the attempt to add NR cell.
The whole meas_config_desc block is the measurement condition for the NR cell. The UE has to detect the NR cell and send a measurement report to the eNB before the eNB can trigger the NR addition, so this block is what gates the EN-DC step of the test.
The NR part of it is the nr_b1 group. nr_b1_report_type is rsrp with nr_b1_rsrp -100, nr_b1_hysteresis 0 and nr_b1_time_to_trigger 100, and nr_rsrp_filter_coeff is 3. The LTE events are kept at the usual values, a1_rsrp -70 with a1_hysteresis 10 and a1_time_to_trigger 320, a2_rsrp -110 with a2_time_to_trigger 640, and a3_offset 6 with a3_time_to_trigger 256. meas_gap_config is "gp0".
If the NR cell is never reported in your setup, nr_b1_rsrp is the value to relax, since it is the RSRP that the NR cell has to reach before the B1 event fires.
This is important configuration since NR SSB is supposed to be transmitted in this MBSFN slot.
The reservation is done in reserved_mbms_subframes with a single sf_alloc entry. The values I use are radio_frame_allocation_period 2, which is 20 ms, radio_frame_allocation_offset 0, and subframe_allocation "100000", which reserves subframe 1. The 20 ms period matches the ssb_period of 20 ms set in nr_cell_default, and the reserved subframe 1 matches the SSB position selected by ssb_pos_bitmap, so every SSB burst lands in a reserved subframe.
n_symb_cch is 1, so the LTE control region inside the reserved subframe is kept to a single OFDM symbol and the rest of the subframe is left free for NR.
The other branch of the sf_alloc is under #ifdef MBMS_ONLY and is not used here, because the MBMS_ONLY define is commented out at the top of the file. It would reserve subframes 1 and 6 every 10 ms and schedule NR only in the MBMS subframes.
Following is the default configuration of NR cell (nr_cell_default). I set the subcarrier_spacing of NR cell to be same as LTE subcarrier spacing for easy test. Also you should notice that I set the bandwidth to 10Mhz which is the same bandwidth I set for the LTE cell. Another thing to notice is that I set the ssb_pos_bitmap so that the SSB falls into MBSFN subframe.
subcarrier_spacing is 15 kHz and bandwidth is 10 MHz, which are the two values that have to follow the LTE side. With 15 kHz the NR slot is 1 ms long and lines up with the LTE subframe, and with 10 MHz the NR carrier covers the same 50 RB as n_rb_dl 50 on LTE.
ssb_pos_bitmap is "0001" and ssb_period is 20 ms. That bitmap enables the last SSB position of the burst, which puts the burst in subframe 1, and subframe 1 is exactly the subframe reserved through reserved_mbms_subframes. n_id_cell is 500, and this is the physical cell id that shows up in the measurement report and in the NR cell addition later.
The block under #if ALLOW_SA carries the parameters needed for a standalone attach on the NR cell, cell_barred false, intra_freq_reselection true, q_rx_lev_min -70, q_qual_min -20, inactivity_timer 10000 and si_window_length 40.
Another import thing to notice is to set dmrs_type_a_pos (the first OFDM symbole of type A dmrs symbol) to be symbol 3. This is to allow mapping type A PDSCH to start from the third symbol and this is to avoid to allocate NR PDSCH overlapping with any possible control channel region of LTE. I also enabled ul_frequency_shift_7p5_khz to align NR UL/DL shift with LTE UL/DL shift.
dmrs_type_a_pos 3 keeps the gNB from putting anything into the LTE control region of the downlink subframe. In DSS the gNB should not transmit any signal there, and moving the first type A DMRS symbol to symbol 3 is what makes that possible for the PDSCH that carries the DMRS.
Two more parameters in this block are there for the same alignment purpose. n_timing_advance_offset is 0 to align with LTE, and ul_frequency_shift_7p5_khz is true so that the NR resource grid lines up exactly with the LTE resource grid in the uplink. lte_crs is set to "auto" so that the NR scheduler rate matches around the LTE cell specific reference signals, and it is inside an #ifndef MBMS_ONLY block, which is active here because MBMS_ONLY is not defined. sr_period is 40 slots and is not specific to DSS.
Configure NR PRACH subframe to be in the same subframe as LTE PRACH subframe.
prach_config_index is 16, which gives subframe 1 in every frame. The LTE side uses prach_config_index 3, which also gives subframe 1 every 10 ms, so the two PRACH occasions sit in the same subframe and the uplink of the two technologies does not fight for a different part of the frame.
The rest of the prach block is left at the values that come with the file. msg1_fdm is 1 and msg1_frequency_start is 4, zero_correlation_zone_config is 11, preamble_received_target_power is -110 dBm, preamble_trans_max is 7 and power_ramping_step is 4 dB, ra_response_window is 10 slots and ra_contention_resolution_timer is 64 ms, restricted_set_config is unrestricted_set, ssb_per_prach_occasion is 1 and cb_preambles_per_ssb is 8.
It is important to set the start symbole of NR PDSCH to be OFDM symbol 2 (or greather than symbol 2 is OK) to avoid possible collistion between LTE control channel and NR PDSCH. It is also important to configure the proper x_overhead to give enough rooms for LTE CRS to be allocated in NR PDSCH regions.
start_symb is 2 with mapping_type typeA, and n_symb is 12, so the PDSCH occupies symbols 2 to 13 and leaves the first two symbols of the slot to the LTE control region. This is the setting that keeps the NR downlink signal from colliding with that region.
x_overhead is written twice with a condition on N_ANTENNA_DL. With N_ANTENNA_DL greater than or equal to 2 it is 12, and otherwise it is 6. This test runs SISO, so the value in effect is 6, meaning 6 resource elements per RB are reserved for the LTE CRS. If you move the test to MIMO 2x2 or 4x4 the other branch takes over and 12 resource elements are reserved instead, because a CRS with more ports takes more room out of the NR PDSCH.
The rest of the block is left as delivered, dmrs_add_pos 1 with dmrs_type 1 and dmrs_max_len 1, mcs_table qam256, rar_mcs 2, and si_mcs 6 inside the #if ALLOW_SA branch. The mcs line is commented out, so the PDSCH MCS is computed from the downlink channel quality instead of being forced.
No specific configuration is required for NR PUSCH. You can use the default settings for PUSCH.
The block stays at mapping_type typeA with n_symb 14, so the PUSCH covers the whole slot, and the mcs line is left commented out so the uplink MCS follows the last received PUSCH.
Following is the configuration in ue-nr-dss.cfg in UEsim. (
Configure the UEsim channel bandwidth for both NR and LTE to be same as the NR/LTE bandwidth of gNB/eNB.
LTE_BANDWIDTH and NR_BANDWIDTH are both 10, and the bandwidth of NR and LTE should be the same. N_CELL is 2 for the LTE cell and the NR cell, and N_ANTENNA_DL is 1 to follow the SISO setting on the gNB side.
NR_TDD and TDD are both 0, so both cell groups are built as FDD. For now, the Amari Callbox supports DSS only in FDD, so these two defines have to stay at 0 for this test.
UEsim does not allow to share the same rf port, so you need to configure two different rf_port between lte connection and NR connection.
The lte cell group is on rf_port 0 with bandwidth LTE_BANDWIDTH and dl_earfcn 2525 in band 5, which is the same EARFCN as the LTE cell of the gNB. The nr cell group is on rf_port 1 with bandwidth NR_BANDWIDTH, band 5, dl_nr_arfcn 176300 at 881.5 MHz and ssb_nr_arfcn 176210, and subcarrier_spacing 15 to match the gNB. The two rf_port numbers are the only place where this file differs from the single spectrum picture on the gNB side.
The dl_earfcn 40620 in the TDD branch and the band 78 block under NR_TDD are not used here, since TDD and NR_TDD are both 0.
Perform the Test
Check the cell configuration and see if it is configured as intended. Make it sure that same bandwidth are configured for both LTE and NR.
The cell phy command prints one line per cell. Cell 0x001 is the LTE cell with RAT LTE, band 5 and BW 10, and cell 0x002 is the NR cell with RAT NR, band n5 and BW 10, so the bandwidth column carries the same 10 MHz on both rows.
The frequency columns show the same picture. The LTE cell has DL ARFCN 2525 and UL ARFCN 20525, the NR cell has DL ARFCN 176300 and UL ARFCN 167300, and these two DL values are the same 881.5 MHz expressed in the LTE and the NR numbering. Both cells run with ANT 1 and NL 1 from the SISO setting and with SCS 15, and the SSB columns are filled only for the NR row with ARFCN 176210 and SCS 15. The eNB is identified as enb1a2d0 with eNB_ID 0x1a2d0 and the gNB as gnb0012345 with gNB_ID 0x12345, both on PLMN 00101.
Check RF information with rf_info command. As you see here, only one sdr card is used for the two cells. The frequency shown here are the center frequency of both LTE cell and NR cell.
There is a single TX0 and a single RX0 entry, both on port 0. TX0 sits at 881.500000 MHz with 89.8 dB of gain and RX0 at 836.500000 MHz with 60.0 dB, and the 45 MHz between them is the FDD duplex spacing of band 5. Only one PCIe RFIC is listed, /dev/sdr0, with hardware ID 0x4b01 and FPGA revision 2021-12-21.
The counters on the same output are worth a look while the test runs. TX underflows and RX overflows are both 0 and the DMA buffer usage stays near 0 percent, which means the single card is keeping up with the two cells.
Power on UE and get it attached.
power_on is issued on the UEsim console and it answers with Cell 0: SIB found. Cell 0 is the LTE cell group, so this line only says that the LTE cell has been acquired. The NR cell is not attached at this point, it comes later through the measurement report and the EN-DC addition.
With t command, confirm that both LTE and NR cell are connected.
The trace opens with two PRACH lines, one for cell=01 with seq=19, ta=1 and snr=29.0 dB, and one for cell=02 with seq=2, ta=2 and snr=29.2 dB. Random access has run on the LTE cell and on the NR cell, which is the first sign that both are up.
After that the trace keeps two rows per period. UE_ID 1 with CL 001 and RNTI 003d is the LTE connection, UE_ID 2 with CL 002 and RNTI 4601 is the NR connection, and both rows carry cqi, mcs and brate of their own. This is what you want to see, two live rows rather than one, and the CL column is the quickest way to tell which cell a row belongs to.
Generate the high rate of IP data so that you can easily verify the resource allocation between LTE and NR in WebGUI
I use the ltesim_server that comes in the mme directory. Starting it with ./ltesim_server gives a (sim) prompt with cbr_recv and cbr_send available, and the traffic itself is started with cbr_send 192.168.2.2 100M 60, which sends a constant bit rate flow of 100 Mbps to the UE address for 60 seconds. The console then reports the running count of sent bytes.
The rate has to be high enough that the scheduler has something to place in every subframe on both cells, otherwise the RB map later shows mostly empty subframes. If your UE gets a different IP address, that is the argument to change.
Log Analysis
Confirm that UE support capability for DSS. The IE rateMatchingLTE-CRS indicates whether the UE supports DSS or Not.
The IE is reported in the UE capability information message on the LTE side, inside rf-Parameters and supportedBandListNR for bandNR 5. rateMatchingLTE-CRS supported sits at the end of that band entry, next to bwp-WithoutRestriction supported, bwp-SameNumerology upto4 and pusch-256QAM supported. If this line is missing for the band you are testing, the UE cannot rate match around the LTE CRS and there is no point in going further with DSS on that band.
The log list is filtered on the RRC layer, and the message to open is UE capability information, which arrives after security mode complete and after the EUTRA band combinations and MRDC band combinations entries.
Then check if mbsfn is configured with IE mbsfn-SubframeConfigList in LTE SIB message. (MBSFN itself is not mandatory requirement for DSS, but we configured and used MBSFN as a part of DSS configuration in this tutorial).
The IE carries radioframeAllocationPeriod n2, radioframeAllocationOffset 0 and subframeAllocation oneFrame '100000'B. This is the same reservation that I set with radio_frame_allocation_period 2, radio_frame_allocation_offset 0 and subframe_allocation "100000" in reserved_mbms_subframes, so the eNB is broadcasting subframe 1 of every second radio frame as an MBSFN subframe. The IE is inside the SIB on BCCH, and it sits right after freqInfo in the same message.
check monitoringSymbolswithinSlot and pdsch SLIV(startSymbolAndLength) and make it sure that they are not overlapping with LTE control channel region.
monitoringSymbolsWithinSlot is '01000000000000'B, so the PDCCH is monitored on symbol 1 only. startSymbolAndLength in pdsch-TimeDomainAllocationList is 53 with mappingType typeA, which decodes to start symbol 2 and length 12 and matches start_symb 2 and n_symb 12 in the pdsch block of the configuration file. Neither of the two reaches into symbol 0, which is where the LTE control region lives with n_symb_cch 1.
The same SIB1 also shows carrierBandwidth 52 with subcarrierSpacing kHz15 and offsetToPointA 13, and the initial downlink BWP with locationAndBandwidth 14025, all of which describe the 10 MHz NR carrier that shares the LTE spectrum. Both values are read out of the SIB1 of cell 2, which is the BCCH-NR row in the message list.
Check NR SIB1 message and see if frequencyShift7p5khz and prach-ConfigurationIndex are configured as set in the configuration file.
frequencyShift7p5khz is true and it is broadcast inside the uplink part of the SIB1, next to absoluteFrequencyPointA 166364 and p-Max 10. prach-ConfigurationIndex is 16 in rach-ConfigGeneric, which is the value I set in the prach block, and the neighbouring values follow the same file, msg1-FDM one, msg1-FrequencyStart 4, zeroCorrelationZoneConfig 11, preambleReceivedTargetPower -110, preambleTransMax n7, powerRampingStep dB4, ra-ResponseWindow sl10 and ra-ContentionResolutionTimer sf64. prach-RootSequenceIndex is l839: 1, which is the root sequence index of the NR cell and is deliberately different from the LTE one.
The pusch-ConfigCommon in the same message gives k2 4 with mappingType typeA and startSymbolAndLength 27, which decodes to start symbol 0 and length 14 and matches n_symb 14 of the pusch block.
After UE power on and the completion of LTE initial attach, it is expected to get Measurement report for NR cell. If the measurement report for NR cell is recieved, it proceed to the next step.
The report to look for is the one carrying measResultNeighCellListNR-r15, because that is the NR part of it. It reports pci-r15 500, which is the n_id_cell of the NR cell, with rsrpResult-r15 78, rsrqResult-r15 87 and rs-sinr-Result-r15 64. The serving LTE cell is reported in the same message as measResultPCell with rsrpResult 65 and rsrqResult 30.
measId is 1 and the message arrives at 12:09:59.807, right after the UE capability exchange and before the RRC connection reconfiguration that adds the NR cell. If the NR neighbour list is empty here, the nr_b1 threshold in meas_config_desc is the thing to revisit.
now you see NR cell gets added as shown in spCellConfig IE in RRC Connection Reconfiguration message.
Check monitoringSymbolswithinSlot IE and make it sure that it is not overlapping with LTE control channel region.
The spCellConfig comes with servCellIndex 1 and a reconfigurationWithSync, and the NR cell it describes is physCellId 500 with absoluteFrequencySSB 176210 and frequencyBandList 5. absoluteFrequencyPointA is 175364 for the downlink, carrierBandwidth is 52 with subcarrierSpacing kHz15, and the initial downlink BWP has locationAndBandwidth 14025, all the same figures the NR cell broadcasts in its own SIB1.
monitoringSymbolsWithinSlot in the common search space of this message is again the bit string with only the second bit set, so the dedicated configuration keeps the PDCCH on symbol 1 exactly as the SIB1 did. controlResourceSetZero is 6 and searchSpaceZero is 1.
Check if frequencyShift7p5khz and prach-ConfigurationIndex are configured as set in the configuration file.
Both are carried in the uplinkConfigCommon of the same reconfiguration message, frequencyShift7p5khz true with absoluteFrequencyPointA 166364 and p-Max 10, and prach-ConfigurationIndex 16 with msg1-FDM one, msg1-FrequencyStart 4, zeroCorrelationZoneConfig 11 and prach-RootSequenceIndex l839: 1. These are the same values the NR cell put in its SIB1, so the UE gets the same alignment whether it reads the broadcast or the dedicated configuration.
pusch-ConfigCommon in this message repeats k2 4 with startSymbolAndLength 27 and p0-NominalWithGrant -84, and pucch-ConfigCommon gives pucch-ResourceCommon 11 with p0-nominal -90.
You see mbsfn is configured in lte-CRS-ToMatchAround IE.
The IE describes the LTE carrier that the NR PDSCH has to rate match around. carrierFreqDL is 312 and carrierBandwidthDL is n50, which is the 50 RB of the LTE cell, nrofCRS-Ports is n1 for the single antenna port of this SISO setup, and v-Shift is n1. The mbsfn-SubframeConfigList inside it repeats radioframeAllocationPeriod n2, radioframeAllocationOffset 0 and subframeAllocation1 oneFrame '100000'B, the same reservation the LTE SIB broadcasts.
A little above it, pdsch-ServingCellConfig shows xOverhead xOh6, which is the x_overhead 6 of the SISO branch of the pdsch block arriving at the UE. Seeing xOh6 and nrofCRS-Ports n1 together is the confirmation that the UE and the gNB agree on how much of the NR PDSCH is left out for the LTE CRS.
Now let's check on phy traffic. To check this more easily, let's filter out only the relative log info. I want to display LTE/NR control channel (PDCCH, PHICH, PUCCH) and traffic channels (PDSCH, PUSCH) only.
The filtering is done in two places. The Layer selector is switched from RRC to PHY, and the Info selector is opened and PDCCH, PDSCH, PHICH, PUCCH and PUSCH are picked out of the list, leaving the RRC channels such as CCCH, DCCH, DRB1 and SRB1 unselected. The UL/DL selector next to it is set to DL for this pass.
Now make it sure that you see control and traffic channel for both LTE and NR are going through.
The rows with UE_ID 1 and RNTI 0x3d are the LTE allocations and the rows with UE_ID 2 and RNTI 0x4601 are the NR ones, and the two sets alternate through the same stretch of time. The Cell column carries 1 and 2 for the same split, so you can follow either column.
The NR PDSCH lines read harq=0 prb=0:51 symb=2:12 with tb_len=18 and cr=0.63, and the symb=2:12 part is the start_symb 2 and n_symb 12 of the configuration showing up in the actual grants. The LTE PDSCH lines on the same span show prb=42 or prb=49 with tx=port0 and tb_len=7 or 18. Both technologies are getting PDCCH and PDSCH in the same window, which is what the test is meant to demonstrate.
If you check RB map, you can check physical channel operation more easily and across wider time span.
The Ressource Block Allocation window is opened at a chosen time, 12:10:53.815 here, and the cells to plot are ticked on the left as ENB/#1 and ENB/#2 with their DL and UL. The LTE DL plot and the NR DL plot then sit one under the other on the same time axis, and the legend gives the colour and pattern for PDSCH, Retx, ACK and SIB, RA and Paging.
Read across the two DL plots. Both are filled with bursts that span the full height of the plot, meaning the whole 50 RB of the carrier, and the bursts of one appear in the gaps of the other rather than at the same instant. That is the time domain sharing between LTE and NR that the configuration was built for, and it is much easier to see here than in the per line PHY log.
Spectrum Analysis
If you use the spectrum analyzer built into Amarisoft system, you can confirm on signal flow on physical layer/RF. Of course, you can use any other spectrum analyzer that support spectrogram. One tricky thing is that in most case the spectrogram show color coding based on signal power only, it does not provide any color coding based on the nature of the signal (e.g, PDCCH, PDSCH, SSB etc). So you should have detailed knowledge about the nature of the physical signal and exact positioning of those signals on the spectrogram.
Amarisoft spectrogram(waterfall) allows zooming in time domain so that you can check the contents in more detail.
Following image shows the spectrogram for the case where full spectrum is scheduled for user data flow. It is hard (almost impossible) to know which part is LTE traffic or which part is NR traffic just looking at the spectrogram, but you can confirm on the overall utilization of the spectrum.
RRC / NAS Signaling
UE Capability Information (LTE)
: This is the UE Capability Information message sent by UE indicating the supportability of DSS. (
{
message c1: ueCapabilityInformation: {
rrc-TransactionIdentifier 0,
criticalExtensions c1: ueCapabilityInformation-r8: {
ue-CapabilityRAT-ContainerList {
{
rat-Type nr,
ueCapabilityRAT-Container {
accessStratumRelease rel15,
pdcp-Parameters {
...
},
rlc-Parameters {
...
},
mac-Parameters {
...
},
phy-Parameters {
phy-ParametersCommon {
...
},
phy-ParametersFRX-Diff {
...
},
phy-ParametersFR1 {
...
}
},
rf-Parameters {
supportedBandListNR {
{
bandNR 5,
mimo-ParametersPerBand {
codebookParameters {
type1 {
...
},
csi-RS-IM-ReceptionForFeedback {
...
},
csi-ReportFramework {
...
}
},
bwp-WithoutRestriction supported,
bwp-SameNumerology upto4,
pusch-256QAM supported,
rateMatchingLTE-CRS supported
}
}
},
measAndMobParameters {
...
},
featureSets {
...
}
},
...
SIB2 (LTE)
: This is the SIB2 message sent by eNB to support DSS. (
{
message c1: systemInformation: {
criticalExtensions systemInformation-r8: {
sib-TypeAndInfo {
sib2: {
radioResourceConfigCommon {
rach-ConfigCommon {
preambleInfo {
...
},
powerRampingParameters {
...
},
ra-SupervisionInfo {
...
},
...
},
bcch-Config {
...
},
pcch-Config {
...
},
prach-Config {
...
},
pdsch-ConfigCommon {
...
},
pusch-ConfigCommon {
...
},
pucch-ConfigCommon {
...
},
soundingRS-UL-ConfigCommon release: NULL,
uplinkPowerControlCommon {
...
},
ul-CyclicPrefixLength len1
},
ue-TimersAndConstants {
...
},
freqInfo {
...
},
mbsfn-SubframeConfigList {
{
radioframeAllocationPeriod n2,
radioframeAllocationOffset 0,
subframeAllocation oneFrame: '100000'B
}
},
...
plmn-InfoList-r15 {
{
upperLayerIndication-r15 true
}
}
},
,,
}
SIB1 (NR)
: This is the SIB1 message sent by gNB to support DSS. (
{
message c1: systemInformationBlockType1: {
cellSelectionInfo {
...
},
cellAccessRelatedInfo {
...
},
connEstFailureControl {
...
},
servingCellConfigCommon {
downlinkConfigCommon {
frequencyInfoDL {
frequencyBandList {
{
freqBandIndicatorNR 5
}
},
offsetToPointA 13,
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz15,
carrierBandwidth 52
}
}
},
initialDownlinkBWP {
genericParameters {
locationAndBandwidth 14025,
subcarrierSpacing kHz15
},
pdcch-ConfigCommon setup: {
commonSearchSpaceList {
{
searchSpaceId 1,
controlResourceSetId 0,
monitoringSlotPeriodicityAndOffset sl1: NULL,
monitoringSymbolsWithinSlot '01000000000000'B,
nrofCandidates {
aggregationLevel1 n0,
aggregationLevel2 n0,
aggregationLevel4 n4,
aggregationLevel8 n0,
aggregationLevel16 n0
},
searchSpaceType common: {
dci-Format0-0-AndFormat1-0 {
}
}
}
},
...
},
pdsch-ConfigCommon setup: {
pdsch-TimeDomainAllocationList {
{
mappingType typeA,
startSymbolAndLength 53
}
}
}
},
bcch-Config {
...
},
pcch-Config {
...
}
},
uplinkConfigCommon {
frequencyInfoUL {
frequencyBandList {
{
freqBandIndicatorNR 5
}
},
absoluteFrequencyPointA 166364,
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz15,
carrierBandwidth 52
}
},
p-Max 10,
frequencyShift7p5khz true
},
initialUplinkBWP {
genericParameters {
locationAndBandwidth 14025,
subcarrierSpacing kHz15
},
rach-ConfigCommon setup: {
rach-ConfigGeneric {
prach-ConfigurationIndex 16,
...
},
...
},
pusch-ConfigCommon setup: {
pusch-TimeDomainAllocationList {
{
k2 4,
mappingType typeA,
startSymbolAndLength 27
}
},
p0-NominalWithGrant -84
},
pucch-ConfigCommon setup: {
...
}
},
timeAlignmentTimerCommon infinity
},
n-TimingAdvanceOffset n0,
ssb-PositionsInBurst {
inOneGroup '10'H
},
...
},
ue-TimersAndConstants {
...
}
}
}
RrcConnectionReconfiguration (LTE)
: This is the RrcConnectionReconfiguration message sent by eNB to add NR1 with DSS capability. (
{
message c1: rrcConnectionReconfiguration: {
rrc-TransactionIdentifier 0,
criticalExtensions c1: rrcConnectionReconfiguration-r8: {
...
radioResourceConfigDedicated {
...
},
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nr-Config-r15 setup: {
endc-ReleaseAndAdd-r15 FALSE,
nr-SecondaryCellGroupConfig-r15 {
rrc-TransactionIdentifier 0,
criticalExtensions rrcReconfiguration: {
secondaryCellGroup {
cellGroupId 1,
rlc-BearerToAddModList {
...
},
mac-CellGroupConfig {
...
},
physicalCellGroupConfig {
...
},
spCellConfig {
servCellIndex 1,
reconfigurationWithSync {
spCellConfigCommon {
physCellId 500,
downlinkConfigCommon {
frequencyInfoDL {
absoluteFrequencySSB 176210,
frequencyBandList {
5
},
absoluteFrequencyPointA 175364,
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz15,
carrierBandwidth 52
}
}
},
initialDownlinkBWP {
genericParameters {
locationAndBandwidth 14025,
subcarrierSpacing kHz15
},
pdcch-ConfigCommon setup: {
controlResourceSetZero 6,
searchSpaceZero 1,
commonSearchSpaceList {
{
searchSpaceId 1,
controlResourceSetId 0,
monitoringSlotPeriodicityAndOffset sl1: NULL,
monitoringSymbolsWithinSlot '01000000000000'B,
nrofCandidates {
aggregationLevel1 n0,
aggregationLevel2 n0,
aggregationLevel4 n4,
aggregationLevel8 n0,
aggregationLevel16 n0
},
searchSpaceType common: {
dci-Format0-0-AndFormat1-0 {
}
}
}
},
searchSpaceSIB1 0,
searchSpaceOtherSystemInformation 1,
pagingSearchSpace 1,
ra-SearchSpace 1
},
pdsch-ConfigCommon setup: {
pdsch-TimeDomainAllocationList {
{
mappingType typeA,
startSymbolAndLength 53
}
}
}
}
},
uplinkConfigCommon {
frequencyInfoUL {
frequencyBandList {
5
},
absoluteFrequencyPointA 166364,
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz15,
carrierBandwidth 52
}
},
p-Max 10,
frequencyShift7p5khz true
},
initialUplinkBWP {
genericParameters {
locationAndBandwidth 14025,
subcarrierSpacing kHz15
},
rach-ConfigCommon setup: {
rach-ConfigGeneric {
prach-ConfigurationIndex 16,
msg1-FDM one,
msg1-FrequencyStart 4,
zeroCorrelationZoneConfig 11,
preambleReceivedTargetPower -110,
preambleTransMax n7,
powerRampingStep dB4,
ra-ResponseWindow sl10
},
ssb-perRACH-OccasionAndCB-PreamblesPerSSB one: n8,
ra-ContentionResolutionTimer sf64,
prach-RootSequenceIndex l839: 1,
restrictedSetConfig unrestrictedSet
},
pusch-ConfigCommon setup: {
pusch-TimeDomainAllocationList {
{
k2 4,
mappingType typeA,
startSymbolAndLength 27
}
},
...
},
pucch-ConfigCommon setup: {
...
}
},
...
},
n-TimingAdvanceOffset n0,
ssb-PositionsInBurst shortBitmap: '1'H,
ssb-periodicityServingCell ms20,
dmrs-TypeA-Position pos3,
ssbSubcarrierSpacing kHz15,
ss-PBCH-BlockPower -25
},
...
},
rlf-TimersAndConstants setup: {
...
},
spCellConfigDedicated {
initialDownlinkBWP {
pdcch-Config setup: {
controlResourceSetToAddModList {
{
controlResourceSetId 2,
frequencyDomainResources '111111110000000000000000000000000000000000000'B,
duration 1,
cce-REG-MappingType nonInterleaved: NULL,
precoderGranularity sameAsREG-bundle
}
},
searchSpacesToAddModList {
{
searchSpaceId 2,
controlResourceSetId 2,
monitoringSlotPeriodicityAndOffset sl1: NULL,
monitoringSymbolsWithinSlot '01000000000000'B,
nrofCandidates {
aggregationLevel1 n4,
aggregationLevel2 n2,
aggregationLevel4 n1,
aggregationLevel8 n0,
aggregationLevel16 n0
},
searchSpaceType ue-Specific: {
dci-Formats formats0-1-And-1-1
}
}
}
},
pdsch-Config setup: {
dmrs-DownlinkForPDSCH-MappingTypeA setup: {
dmrs-AdditionalPosition pos1
},
...
}
},
firstActiveDownlinkBWP-Id 0,
uplinkConfig {
initialUplinkBWP {
pucch-Config setup: {
...
},
pusch-Config setup: {
...
},
srs-Config setup: {
...
}
},
firstActiveUplinkBWP-Id 0,
pusch-ServingCellConfig setup: {
}
},
pdcch-ServingCellConfig setup: {
},
pdsch-ServingCellConfig setup: {
xOverhead xOh6,
nrofHARQ-ProcessesForPDSCH n16
},
tag-Id 0,
lte-CRS-ToMatchAround setup: {
carrierFreqDL 312,
carrierBandwidthDL n50,
mbsfn-SubframeConfigList {
{
radioframeAllocationPeriod n2,
radioframeAllocationOffset 0,
subframeAllocation1 oneFrame: '100000'B
}
},
nrofCRS-Ports n1,
v-Shift n1
}
}
}
}
}
}
},
sk-Counter-r15 0,
nr-RadioBearerConfig1-r15 {
...
}