In this note, I will implement a python script to construct and visualize NR Downlink Resource Grid which includes very basic components : CORESET, PDSCH, PDSCH DMRS. I might have included more components like SSB, CSI-RS, PTRS etc but I wanted to make it simple at first.

This script leverages NVIDIA's Sionna library for OFDM resource grid creation and mapping, providing a comprehensive visualization framework using Tkinter-based tabbed GUI.

Followings are brief descriptions on each procedure with the focus on sionna api

• Inputs: Channel BW, subcarrier spacing, RB allocation (START_RB, NUM_RBS), CORESET bitmap/duration/start symbol, DMRS config.
• ResourceGrid (sionna.phy.ofdm.ResourceGrid): Constructs the OFDM grid (FFT size, guards, symbols, pilots placeholder).
• PilotPattern / DMRS masks: Builds DMRS positions per Type A rules; CORESET masks derived from bitmap.
• ResourceGridMapper (sionna.phy.ofdm.ResourceGridMapper): Maps data/pilot symbols into the grid using masks.
• Visualization: Multiple Tkinter tabs render full grid, zoomed view, resource pattern (PDSCH/DMRS/CORESET), spectrum (PSD/spectrogram), and CORESET detail.

Toolkits for the script

I didn't write the code myself. What I did was just prompting for AI tool and did basic check up for the output. Followings are the tool kits that I used for this script

• Scripting IDE : Cursor
• Version: 2.1.50 (system setup)
• VSCode Version: 1.105.1
• Commit: 56f0a83df8e9eb48585fcc4858a9440db4cc7770
• Date: 2025-12-06T23:39:52.834Z
• Electron: 37.7.0
• Chromium: 138.0.7204.251
• Node.js: 22.20.0
• V8: 13.8.258.32-electron.0
• OS: Windows_NT x64 10.0.26100
• AI Model : Opus 4.5 (as of Dec 7, 2025)
• Python Info : Check out this note for the detailed installation proces that I went through

==== Python Version ==== 3.12.3 (main, Nov  6 2025, 13:44:16) [GCC 13.3.0]   ==== Python Executable ==== /home/jaeku/nvidia/venv-sionna/bin/python3   ==== Platform Info ==== Linux-6.6.87.2-microsoft-standard-WSL2-x86_64-with-glibc2.39 ('main', 'Nov  6 2025 13:44:16')   ==== Site-Packages Directories ==== ['/home/jaeku/nvidia/venv-sionna/lib/python3.12/site-packages', '/home/jaeku/nvidia/venv-sionna/local/lib/python3.12/dist-packages', '/home/jaeku/nvidia/venv-sionna/lib/python3/dist-packages', '/home/jaeku/nvidia/venv-sionna/lib/python3.12/dist-packages']   ==== sys.path ====   /home/jaeku/nvidia   /usr/lib/python312.zip   /usr/lib/python3.12   /usr/lib/python3.12/lib-dynload   /home/jaeku/nvidia/venv-sionna/lib/python3.12/site-packages   ==== Installed Packages ==== absl-py == 2.3.1 asttokens == 3.0.1 astunparse == 1.6.3 certifi == 2025.11.12 charset-normalizer == 3.4.4 comm == 0.2.3 contourpy == 1.3.3 cycler == 0.12.1 decorator == 5.2.1 drjit == 1.2.0 executing == 2.2.1 flatbuffers == 25.9.23 fonttools == 4.61.0 gast == 0.7.0 google-pasta == 0.2.0 grpcio == 1.76.0 h5py == 3.15.1 idna == 3.11 importlib_resources == 6.5.2 ipydatawidgets == 4.3.5 ipython == 9.8.0 ipython_pygments_lexers == 1.1.1 ipywidgets == 8.1.8 jedi == 0.19.2 jupyterlab_widgets == 3.0.16 keras == 3.12.0 kiwisolver == 1.4.9 libclang == 18.1.1 Markdown == 3.10 markdown-it-py == 4.0.0 MarkupSafe == 3.0.3 matplotlib == 3.10.7 matplotlib-inline == 0.2.1 mdurl == 0.1.2 mitsuba == 3.7.1 ml_dtypes == 0.5.4 namex == 0.1.0 numpy == 1.26.4 opt_einsum == 3.4.0 optree == 0.18.0 packaging == 25.0 parso == 0.8.5 pexpect == 4.9.0 pillow == 12.0.0 pip == 25.3 prompt_toolkit == 3.0.52 protobuf == 6.33.2 ptyprocess == 0.7.0 pure_eval == 0.2.3 Pygments == 2.19.2 pyparsing == 3.2.5 python-dateutil == 2.9.0.post0 pythreejs == 2.4.2 requests == 2.32.5 rich == 14.2.0 scipy == 1.16.3 setuptools == 80.9.0 sionna == 1.2.1 sionna-rt == 1.2.1 six == 1.17.0 stack-data == 0.6.3 tensorboard == 2.20.0 tensorboard-data-server == 0.7.2 tensorflow == 2.20.0 termcolor == 3.2.0 traitlets == 5.14.3 traittypes == 0.2.3 typing_extensions == 4.15.0 urllib3 == 2.6.0 wcwidth == 0.2.14 Werkzeug == 3.1.4 wheel == 0.45.1 widgetsnbextension == 4.0.15 wrapt == 2.0.1

Source Code and Output

You can get the source code for this note here.  I would not describe / explain on every single line of the code since AI (e.g, chatGPT, Gemini etc) will explain better than I do.

Disclaimer !!!

I have checked and fixed some obvious issues of the script while I am prompting the script, but I haven't verified all the details of the implementation. So there likely to be bugs / errors that I missed.  So take this purely as an educational purpose for getting some high level idea on how 3GPP NR Phy specification can be implemented

The script output some part of the result in text and some part in graphics.

Followings are the output of the code in text

Followings are the snapshots of graphical output (NOTE : If you want to get images for better resolution, I would suggest you to install the sionna on your PC and run the script that I shared).

Full Resource Grid

The screenshot shows the final constructed NR resource grid after applying all configuration steps in the script. The carrier configuration is 20 MHz bandwidth with 30 kHz subcarrier spacing, resulting in 51 RBs = 612 subcarriers across the full channel.

Followings are brief description of each components in this view :

• Only a subset of RBs is allocated for transmission.
• Active RBs appear as a colored vertical block in the middle of the grid.
• Unallocated RBs on both sides remain empty (dark), confirming correct RB masking.
• The left panel displays magnitude of the resource grid.
• Data symbols occupy most REs in the allocated RB range.
• DMRS symbols are visible with distinct magnitude patterns.
• Reserved regions (e.g., CORESET) are clearly excluded from data mapping.
• The right panel displays phase of the same grid.
• Data symbols show random-looking phase distribution, consistent with QAM modulation.
• DMRS symbols show structured phase behavior, reflecting deterministic reference sequences.
• DMRS Type A placement is correctly applied.
• DMRS symbols appear only at expected OFDM symbol indices.
• No collision between data and DMRS is observed.
• The CORESET region is clearly carved out.
• Control resources are confined to the configured frequency and symbol range.
• Data symbols do not leak into CORESET-reserved REs.
• Dashed horizontal lines mark OFDM symbol indices of interest, helping verify
• symbol-domain configurations such as DMRS positions and CORESET duration.
• The visualization confirms the correct order of operations in the script:
• configuration → grid creation → DMRS masking → resource mapping → symbol placement.
• This full-grid view acts as a sanity and debugging check.
• Any mistake in RB allocation, DMRS configuration, or CORESET bitmap would be immediately visible as misplaced energy or symbol collisions.

Defailed View

This view provides a maginified view of only a small portions of the full resource allocation area to provide more detailed aspect of the resource grid.

Followings are brief description of each components in this view :

• This view zooms into a small RB subset (RB10 to RB15) taken from the full allocated bandwidth.
• Only 6 RBs are shown here, even though more RBs are allocated overall.
• This makes individual RE-level behavior clearly visible.
• The x-axis represents subcarrier indices within the allocated region.
• Each RB spans 12 subcarriers, and vertical separators mark RB boundaries.
• RB labels at the top (RB10–RB15) confirm correct frequency-domain indexing.
• The y-axis represents OFDM symbol indices within a slot.
• Each horizontal row corresponds to one OFDM symbol.
• This allows direct verification of symbol-based configurations such as DMRS positions.
• DMRS Type A symbols are explicitly highlighted.
• They appear at specific OFDM symbols only.
• The DMRS locations match the configured Type-A mapping rules.
• No data symbols are placed on DMRS REs, confirming correct masking.
• Data symbols fill all remaining non-reserved REs.
• Their color variation reflects symbol magnitude differences from modulation and mapping.
• The random-looking pattern confirms normal QAM data placement.
• The bottom OFDM symbols are empty or reserved.
• This typically corresponds to control, guard, or intentionally unused regions.
• It confirms that data mapping starts only after reserved symbols are excluded.
• The color bar on the right shows normalized magnitude.
• DMRS symbols often show more uniform magnitude compared to data symbols.
• This helps visually distinguish pilots from data.
• This detailed view is primarily a validation tool.
• It confirms RE-level correctness of RB allocation.
• It verifies DMRS symbol timing and frequency placement.
• It ensures there is no collision between data, pilots, and reserved regions.
• Compared to the full-grid view, this plot answers “what exactly is happening inside one RB group”,
• while the full-grid view answers “where things are placed in the entire carrier.”

Resource Pattern

This view shows the logical resource pattern of the entire channel, rather than symbol magnitude or phase. The carrier is 20 MHz, 30 kHz SCS, covering 51 RBs across the full frequency span.

Followings are brief description of each components in this view :

• Frequency-domain allocation is clearly separated:
• The allocated RB range (RB10–RB33) is highlighted with white vertical borders.
• RBs outside this range are shown as unallocated (grey).
• Different resource types are color-coded for clarity:
• PDSCH Data occupies most REs in the allocated RB region.
• PDSCH DMRS appears as horizontal bands at specific OFDM symbol indices.
• CORESET Data and DMRS are shown in the lower OFDM symbols.
• Unallocated regions remain uniformly grey.
• DMRS Type A structure is easy to verify:
• DMRS symbols repeat periodically across frequency within the allocated RBs.
• DMRS appears only on the configured OFDM symbols.
• No DMRS appears outside the allocated PDSCH region.
• The CORESET region is explicitly carved out:
• CORESET occupies RB0–RB23 and OFDM symbols 0–1, marked with red dashed borders.
• Control resources are isolated from PDSCH resources both in time and frequency.
• The time-domain separation is visually clear:
• Lower OFDM symbols are dominated by CORESET.
• Higher OFDM symbols are used for PDSCH data and DMRS.
• No overlap exists between control and data regions.
• This pattern view confirms correct masking and prioritization rules:
• CORESET takes precedence over PDSCH.
• DMRS masks are applied before data mapping.
• Unallocated RBs never carry data or pilots.
• Compared to the full-grid magnitude/phase views, this plot focuses on “what type of signal is placed where”, rather than “what complex values those signals carry.”
• This visualization is especially useful for:
• Verifying RB allocation logic
• Checking CORESET frequency and symbol spans
• Confirming DMRS placement rules
• Explaining NR resource mapping concepts in a tutorial context

Spectrum

This view connects the time–frequency resource grid to the actual RF spectrum seen after OFDM modulation. The carrier configuration is 20 MHz bandwidth with 30 kHz SCS, and only RB10–RB33 (24 RBs) are allocated.

Followings are brief description of each components in this view :

• The top plot shows the power spectral density (PSD) computed using Welch’s method.
• The blue region corresponds to the occupied bandwidth of the allocated RBs.
• The red dashed vertical lines mark the edges of the allocated RB region.
• The green vertical lines indicate the full channel bandwidth limits.
• Energy is confined strictly within the allocated RB bandwidth.
• There is no unintended spectral leakage into unallocated RBs.
• The roll-off at the allocation edges matches expectations for OFDM with rectangular windowing.
• The grey area represents out-of-band spectrum.
• Its lower power level confirms that inactive RBs are not transmitting symbols.
• The bottom plot is a spectrogram, showing spectrum versus OFDM symbol index.
• The allocated RB region appears as a vertical band of higher power.
• Unallocated frequencies remain dark across all symbols.
• DMRS symbol locations are visible in the spectrogram.
• Horizontal lines highlight OFDM symbols carrying DMRS.
• These symbols often show slightly different spectral characteristics due to pilot structure.
• The spectrum view verifies several critical aspects simultaneously:
• RB allocation is correctly reflected in the frequency domain.
• DMRS placement in time aligns with symbol-domain configuration.
• No transmission occurs outside the configured channel bandwidth.
• This plot is especially useful as a final validation step.
• Grid-level decisions are translated into correct spectral occupancy.
• Any RB misalignment or incorrect FFT mapping would be immediately visible as spectral shifts or leakage.
• Conceptually, this view answers the question: “Does the resource grid we built produce the spectrum we expect?”

CORESET Details

This view focuses specifically on the CORESET configuration and its internal structure, separated from the PDSCH grid.

Followings are brief description of each components in this view :

• The top panel shows the CCE–REG mapping structure of the CORESET.
• The CORESET spans 48 REGs, corresponding to 8 CCEs.
• Interleaved mapping is used.
• REG bundle size is 6, which determines how REGs are grouped before interleaving.
• The color-coded blocks in the top panel represent CCE indices.
• REGs belonging to the same CCE share the same color.
• This visualizes how REGs are distributed across frequency within the CORESET.
• The x-axis of the top panel shows subcarrier indices within the CORESET bandwidth.
• RB-level segmentation is visible, confirming correct frequency-domain mapping.
• The y-axis of the top panel represents OFDM symbols used by the CORESET.
• Only the configured CORESET symbols are active.
• No PDSCH symbols appear in this region.
• The bottom panel places the CORESET back into the full resource grid context.
• The CORESET is confined to the lower OFDM symbols.
• Its frequency span is limited to RB0–RB23, marked with dashed red borders.
• PDSCH and CORESET regions are clearly separated.
• CORESET resources do not overlap with PDSCH data or DMRS.
• This confirms correct prioritization of control over data.
• CORESET DMRS and data REs are both visible.
• DMRS appears in a structured pattern within the CORESET region.
• Data REs fill the remaining allowed REGs.
• This view is especially useful for validating:
• CORESET frequency and symbol duration
• CCE count and REG bundling
• Interleaving behavior
• Control–data isolation at the RE level
• Conceptually, this plot answers the question:“How exactly is PDCCH control information packed into the resource grid?”

Source Code Overview

Even though I no longer need to describe every single line of code in the age of AI, I still think it is valuable to write down some key points. This is not to show off the code itself. It is to record the intention behind the script. I want to clarify what I was trying to do, what kind of idea I had in mind, and what kind of problems this script is designed to solve. This allows the reader to connect the final result with the original design goal. It also helps me later when I come back to this code after a long time and forget my own thinking process.

You may not need all of these details if your only goal is to understand the output of the script. For simple usage, you can often treat the script as a black box. You run it. You look at the result. You move on. In many cases this is enough. However, if you want to modify, revise, or extend the script for your own purpose, the situation changes. You would need to know which part of the code is doing what. You would need to know which parameters control which behavior. You would also need to know what kind of assumptions I made when I first wrote the code. In that case, a clear description of the code is not a luxury. It becomes a kind of map.

One of the best ways to learn anything related to programming is still very old-fashioned. You break it and then you fix it. You change a small part of the script and see what goes wrong. You check the error. You adjust. You run it again. This loop may look inefficient at first, but it forces your brain to connect cause and effect inside the code. So my intention with these explanations is not just to document the script. It is to give you enough context so that you can safely break it, understand why it broke, and then fix it in a way that matches your own idea. This process is painful sometimes, but it is also the part that makes the knowledge stick to your brain.

Key Features

• NR Resource Grid Generation: Creates a 5G NR downlink resource grid with configurable bandwidth, subcarrier spacing, and RB allocation
• 3GPP-Compliant DMRS: Implements DMRS Type A with support for multiple positions, CDM groups, delta shift, and OCC
• CORESET Support: Configurable CORESET regions using 3GPP-compliant 45-bit frequency domain bitmap
• PDSCH RE Mapping Verification: Validates that PDSCH data follows 3GPP TS 38.214 mapping rules
• Multi-Tab Visualization: Interactive GUI with 5 tabs showing resource grid, detailed view, pattern, spectrum, and CORESET details

What is Implemented ?

Followings are the features that I fully implemented (hopefully :)

What is Partially Implemented ?

What is NOT Implemented ?

Description of Parameters (Global Variables)

Debug Configuration

Channel Bandwidth Configuration

PRB Allocation Configuration

Lookup Tables

DMRS Time Domain Configuration

DMRS Frequency Domain Configuration

DMRS OCC Configuration Tables

PTRS Configuration

CSI-RS Configuration

CORESET Configuration

Antenna Configuration

Derived Parameters (Calculated at Runtime)

Description of Functions

validate_rb_allocation(start_rb, num_rbs, max_rbs, channel_bw, scs_khz)

Validates RB allocation parameters and adjusts invalid values.

Parameters:

Returns: tuple(valid_start_rb, valid_num_rbs, error_messages)

Validation Rules:

• num_rbs must be > 0
• num_rbs must not exceed max_rbs
• start_rb must be >= 0 and < max_rbs
• start_rb + num_rbs must not exceed max_rbs

validate_coreset_config(bitmap_info, duration, start_symbol, reg_bundle_size)

Validates CORESET configuration parameters according to 3GPP specifications.

Parameters:

Returns: tuple(valid_duration, valid_start_sym, valid_reg_bundle, errors)

Validation Rules:

• Duration must be 1, 2, or 3
• Start symbol + duration must not exceed 14
• REG bundle size must be valid for the duration (Duration 1,2: {2,6}; Duration 3: {3,6})

parse_coreset_bitmap(bitmap_str, max_rbs)

Parses the 45-bit CORESET frequency domain bitmap according to 3GPP TS 38.331.

Parameters:

Returns: Dictionary containing:

Example:

create_coreset_mask(num_symbols, num_subcarriers, coreset_rb_list, coreset_duration, coreset_start_symbol, bwp_start_rb, bwp_num_rbs)

Creates boolean masks for CORESET data and DMRS positions.

Parameters:

Returns: tuple(coreset_mask, coreset_dmrs_mask, overlap_info)

• coreset_mask: Boolean array of shape (num_symbols, num_subcarriers) for CORESET data REs
• coreset_dmrs_mask: Boolean array for PDCCH DMRS positions (subcarriers 1, 5, 9 in each RB)
• overlap_info: Dict with has_overlap, overlap_rbs, overlap_num_rbs

get_dmrs_symbols(l0=2, add_pos=0, num_symbols=14)

Gets DMRS symbol positions based on 3GPP TS 38.211 Table 7.4.1.1.2-3.

Parameters:

Returns: list[int] - DMRS symbol indices

DMRS Symbol Positions (14 symbols, l0=2):

get_dmrs_subcarrier_positions(config_type, cdm_group, delta_shift, num_rbs)

Gets DMRS subcarrier positions based on 3GPP TS 38.211 Table 7.4.1.1.2-1.

Parameters:

Returns: list[int] - Sorted list of subcarrier indices

Type 1 CDM Groups (within each RB):

get_port_cdm_group(port, config_type)

Returns the CDM group for a given DMRS port.

Parameters:

Returns: int - CDM group number

Type 1 Port-to-CDM Mapping:

apply_occ(base_sequence, port, dmrs_length, config_type)

Applies Orthogonal Cover Code (OCC) to DMRS sequence.

Parameters:

Returns: np.array - OCC-applied DMRS sequence

OCC Patterns (Type 1, Single Symbol):

create_nr_dmrs_type_a_pilot_pattern(...)

Creates a complete NR DMRS Type A pilot pattern (3GPP TS 38.211 compliant).

Full Signature:

Parameters:

Returns: tuple(pilot_pattern, mask, pilots, dmrs_info)

• pilot_pattern: Sionna PilotPattern object
• mask: Boolean array [num_tx, num_streams, num_symbols, num_sc]
• pilots: Complex array [num_tx, num_streams, num_pilots]
• dmrs_info: Dictionary with configuration summary

Sionna API Used:

create_reserved_re_mask(...)

Creates a combined mask of all reserved REs according to 3GPP TS 38.214 Section 5.1.4.

Full Signature:

Reserved REs (PDSCH should NOT be mapped here):

• REs assigned for DMRS associated with the PDSCH
• REs assigned for DMRS intended for other co-scheduled UEs
• REs for non-zero-power CSI-RS
• REs for PTRS
• REs declared as 'not available for PDSCH' (CORESET, etc.)

Returns: tuple(reserved_mask, ptrs_mask, re_stats)

• reserved_mask: Boolean array [num_symbols, num_subcarriers]
• ptrs_mask: Boolean array for PTRS positions only
• re_stats: Dictionary with RE statistics (total, DMRS, CORESET, PTRS, overhead %)

verify_pdsch_mapping_order(...)

Verifies PDSCH RE mapping follows 3GPP TS 38.214 rules.

Full Signature:

Verification Rules (3GPP TS 38.214 Section 5.1.4):

1. Frequency-first mapping: Fill REs from lowest to highest frequency, then next symbol
2. No data mapped to reserved REs (DMRS, CORESET, PTRS)

Returns: Dictionary with:

ResourceGrid(sionna.phy.ofdm)

Creates an OFDM resource grid with specified parameters.

Key Properties:

• resource_grid.fft_size: FFT size
• resource_grid.num_ofdm_symbols: Number of OFDM symbols
• resource_grid.num_effective_subcarriers: Subcarriers excluding guards
• resource_grid.num_data_symbols: Number of data symbols (excluding pilots)

ResourceGridMapper(sionna.phy.ofdm)

Maps data and pilot symbols to the resource grid.

Input: data_symbols - Complex tensor of shape [batch, num_tx, num_streams, num_data_symbols]

Output: x_rg - Complex tensor of shape [batch, num_tx, num_streams, num_ofdm_symbols, fft_size]

PilotPattern(sionna.phy.ofdm)

Defines the pilot pattern (DMRS positions and values).

BinarySource(sionna.phy.mapping)

Generates random binary data.

Mapper (sionna.phy.mapping)

Maps bits to constellation symbols.

Modulation Options:

• num_bits_per_symbol=2: QPSK
• num_bits_per_symbol=4: 16QAM
• num_bits_per_symbol=6: 64QAM
• num_bits_per_symbol=8: 256QAM

ResourceGridViewer

A Tkinter-based GUI class for visualizing the NR resource grid.

Constructor:

Parameters:

Methods:

Tab Descriptions:

1. Full Resource Grid: Shows entire channel bandwidth as gray background with allocated RBs overlaid in color. Magnitude (left) and Phase (right) plots. CORESET shown as orange rectangle.
2. Detailed View: Zoomed view of first 6 allocated RBs showing individual subcarriers and symbols. DMRS symbols highlighted in cyan.
3. Resource Pattern: Color-coded pattern showing:
   • Blue: PDSCH Data
   • Green: PDSCH DMRS
   • Gray: Unallocated
   • Orange: CORESET Data
   • Yellow: CORESET DMRS
4. Spectrum:
   • Upper plot: Welch Power Spectral Density (dB/Hz)
   • Lower plot: Spectrogram per OFDM symbol
   • Red dashed lines: Allocated bandwidth edges
   • Green solid lines: Channel bandwidth edges
5. CORESET Detail (if enabled):
   • Upper plot: CCE/REG structure with color-coded CCE assignments
   • Lower plot: Full channel view showing BWP and CORESET positions