SUL stands for Supplimentary Uplink. Basic idea (or Use Case) on SUL is described/illustrated as shown below in 38.300. A cell has one downlink and normally one uplink. SUL gives that same cell a second uplink on a much lower band, and the UE uses one or the other at any moment. Two words in that description matter more than the rest. The first is same. 38.300 states it as two ULs for one DL of the same cell, so SUL adds a carrier and not a cell. The second is or. This is not uplink carrier aggregation, and the UE never transmits on both carriers at once.

That is the entire feature. Everything else on this page follows from it: which carrier the UE uses, how the network tells it to change, and why only one of the two can carry PUCCH. The drawing below states the same thing geometrically. One gNB serves three nested areas, and the normal uplink is the one that reaches the shortest distance. The frequency strip underneath places the SUL carrier far below the NR carrier, and draws it narrower. The band table further down this page confirms that the SUL bands really are the narrow ones.

< 38.300-Figure B.1-1: Example of Supplementary Uplink >

The basic idea behind this is as follows.

i) Usually cell coverage in UL direction is lower than DL direction because UE Tx Power(UL Power) is not as strong as gNB Tx Power(DL Power).

ii) The performance degradation on UL direction due to this difference gets very serious as the UE approaches to cell edge.

iii) As a possible solution, an idea to use very low frequency than the original UL frequency is proposed. As you know, cell coverage gets larger as frequency gets lower.

iv) this (to use a secondary UL at much lower frequency) is the idea behind SUL. When the channel condition is good, Network tell UE to use the original UL frequency and when channel condition gets poor than a certain criteria, Network directs UE to use the secondary(supplementary) UL frequency.

There are several NR bands dedicated for SUL which are n80, n81, n82, n83, n84, n86, n89, n97, n98 and n99, as listed in the table further down this page. As you see in this table, these are all under 2Ghz which is lower than commonly used NR frequency(e.g, over 3Ghz). However, one possible drawback of this approach is that these SUL bands are colliding with existing LTE bands. So it would cause NR-LTE Co Existance issues. You would need some researches on SUL and NR/LTE Coexistance issue before you make decision to deploy any SUL. See TR 37.872 and TR 37.716 for the details on SUL and NR/LTE CoExistance.

Would SUL be useful in real practice and widely deployed ? See this blog by Martin.

• Overall Procedures
• Where SUL is Configured
• Choosing Between the Two Uplinks
• Reference

Overall Procedures

Two questions have to be answered before any of this works. The UE has to learn that a second uplink exists at all, and then it has to know which one to transmit on. SIB1 answers the first. The second is answered three different ways depending on what is being sent, and the diagram below shows where each of them applies.

Overall procedure for SUL operation can be summarized in illustration shown below.

• Step 1 : SUL configuration is broadcast by SIB1 of Normal Cell
• Step 2 : UE trigger RACH to Normal Cell or SUL cell depending on signal condition it percieves and Completes the initial attach
• Step 3 : Once in Connection Mode. gNB can dynamically switching between Normal cell and SUL cell via DCI 0_1.

Example 01 >  Following example is from the test with Amarisoft Callbox and UEsim

Read the two screenshots below for one field each. The PRACH line carries sul_index, and the PDCCH lines carry sul_ind. Those two fields are the log’s view of the carrier decision, and the clips underneath repeat the same lines as text so the values can be copied.

Amarisoft Callbox and UEsim log, quoted as captured.

Message: sequence_index=0 ta=5 prb=3:3sul_index=0 snr=29.0

Amarisoft Callbox and UEsim log, quoted as captured.

Message: ss_id=2 cce_index=6 al=2 dci=0_1 k2=4

Data:
rb_alloc=0x12f
mcs=14
ndi=0
rv_idx=1
harq_process=3
dai=3
tpc_command=1
antenna_ports=0
srs_request=0
dmrs_seq_init=0
ul_sch_indicator=1
sul_ind=0

Amarisoft Callbox and UEsim log, quoted as captured.

Message: harq=3 prb=2:47 symb=0:14 CW0: tb_len=1985 mod=4 rv_idx=1 cr=0.54 retx=1 crc=KO snr=3.0 epre=-43.4 ta=0.6

Amarisoft Callbox and UEsim log, quoted as captured.

Message: ss_id=2 cce_index=6 al=2 dci=0_1 k2=4

Data:
rb_alloc=0x2
mcs=7
ndi=1
rv_idx=0
harq_process=4
dai=3
tpc_command=1
antenna_ports=0
srs_request=0
dmrs_seq_init=0
ul_sch_indicator=1
sul_ind=1

Amarisoft Callbox and UEsim log, quoted as captured.

Message: harq=4 prb=2 symb=0:14 CW0: tb_len=20 mod=2 rv_idx=0 cr=0.56 retx=0 crc=OK snr=5.2 epre=-24.6 ta=5.3sul=1

Operation Highlights

What I mentioned above is based on my intuitive understanding on SUL operation. In this section, I will quote some formal description from 3GPP specification for your (my) reference.

38.300 - 5.4.2 state as follows :

In conjunction with a UL/DL carrier pair (FDD band) or a bidirectional carrier (TDD band), a UE may be configured with additional, Supplementary Uplink (SUL). SUL differs from the aggregated uplink in that the UE may be scheduled to transmit either on the supplementary uplink or on the uplink of the carrier being supplemented, but not on both at the same time.

38.300 - 6.9 state as follows :

In case of Supplementary Uplink, the UE is configured with 2 ULs for one DL of the same cell, and uplink transmissions on those two ULs are controlled by the networkto avoid overlapping PUSCH/PUCCH transmissions in time. Overlapping transmissions on PUSCH are avoided through scheduling while overlapping transmissions on PUCCH are avoided through configuration(PUCCH can only be configured for only one of the 2 ULs of the cell).

38.300 - 9.2.6 state as follows :

For initial access in a cell configured with SUL,the UE selects the SUL carrier if and only if the measured quality of the DL is lower than a broadcast threshold. Once started, all uplink transmissions of the random access procedure remain on the selected carrier.

 

38.300 - 10.3 state as follows :

When CA is configured, at most one configured uplink grant can be signalled per serving cell.When BA(Bandwidth Adaptation) is configured,at most one configured uplink grant can be signalled per BWP. On each serving cell, there can be only one configured uplink grant active at a time. A configured uplink grant for one serving cell can either be of Type 1 or Type 2. For Type 2, activation and deactivation of configured uplink grants are independent amongthe serving cells.When SUL is configured, a configured uplink grant can only be signalled for one of the 2 ULs of the cell.,

38.213 - 8 states as follows :

If a UE is configured with two UL carriers for a serving cell and the UE detects a ,PDCCH order, the UE uses theUL/SUL indicator field value from the detected PDCCH order to determine the UL carrier for the corresponding PRACH transmission.

38.321 - 5.1.1 states as follows :

ifthe RSRP of the downlink pathloss reference is less than rsrp-ThresholdSSB-SUL:

   select the SUL carrier for performing Random Access procedure;

else:

   select the NUL carrier for performing Random Access procedure;

Band Combinations for SUL

SUL bands are not ordinary bands with an extra label. They are uplink-only entries, and the table below shows why: every one of them has N/A in the downlink column. A SUL band therefore cannot be deployed alone. It is always paired with the downlink of the cell it supplements.

Following is the frequency band assigned to SUL in 3GPP.

< 38.101-1 v17.5 - Table 5.2-1: NR operating bands in FR1 >

Followings are the table that I consolidated multiple tables from TR 37.872.NOTE that SUL Uplink Frequency is much lower than the uplink of Normal Cell.

Following is the table for SUL with ENDC. You would notice that all LTE is FDD and all NR is TDD, and NR SUL is in same frequency range in LTE UL range implying that NR UL and LTE UL would share the frequency range.NOTE that SUL Uplink Frequency is much lower than the uplink of Normal Cell.

Where SUL is Configured

Everything above shows SUL working. None of it shows where the second uplink is configured, and the answer is three places rather than one. A cell advertises SUL in SIB1 so that a UE which has not yet connected can use it for random access. A connected UE is given its own SUL configuration in dedicated signalling. The two are separate, and a UE can have the first without ever being given the second.

The cell side, broadcast in SIB1

SIB1 carries servingCellConfigCommon, and inside it the SUL carrier sits in a field of its own beside the ordinary uplink. Both are optional, and both hold the same type, which is what makes the second uplink a peer of the first rather than an appendix to it.

Following is based on 38.331 v19.3.0 (Release 19). Fields unrelated to SUL are omitted, and the omission is marked with a comment rather than with the extension marker.

ServingCellConfigCommonSIB ::=      SEQUENCE {
    downlinkConfigCommon                DownlinkConfigCommonSIB,
    uplinkConfigCommon                  UplinkConfigCommonSIB       OPTIONAL,   -- Need R
    supplementaryUplink                 UplinkConfigCommonSIB       OPTIONAL,   -- Need R
    -- remaining fields omitted
}

The dedicated form of the same information element uses a different field name for the same idea. That difference in name is easy to misread as a difference in meaning.

Following is based on 38.331 v19.3.0 (Release 19). Excerpt, marked the same way as the one above.

ServingCellConfigCommon ::=         SEQUENCE {
    physCellId                          PhysCellId                  OPTIONAL,   -- Cond HOAndServCellAdd,
    downlinkConfigCommon                DownlinkConfigCommon        OPTIONAL,   -- Cond HOAndServCellAdd
    uplinkConfigCommon                  UplinkConfigCommon          OPTIONAL,   -- Need M
    supplementaryUplinkConfig           UplinkConfigCommon          OPTIONAL,   -- Need S
    -- remaining fields omitted
}

So the broadcast version calls it supplementaryUplink and the dedicated common version calls it supplementaryUplinkConfig. There is no difference in meaning. 38.331 also ties the second field to the first. The network configures supplementaryUplinkConfig only if uplinkConfigCommon is configured. If that field is absent, the UE releases both the common SUL configuration and the dedicated one below.

The UE side, in dedicated signalling

A connected UE gets its own uplink configuration in ServingCellConfig, and the SUL carrier appears there once more as a field beside the ordinary one. The Release 16 extension group adds the way to take it away again.

Following is based on 38.331 v19.3.0 (Release 19). Excerpt, marked the same way as the one above.

ServingCellConfig ::=               SEQUENCE {
    -- earlier fields omitted
    uplinkConfig                        UplinkConfig                OPTIONAL,   -- Need M
    supplementaryUplink                 UplinkConfig                OPTIONAL,   -- Need M
    -- later fields omitted
    ...,
    [[
    supplementaryUplinkRelease-r16      ENUMERATED {true}           OPTIONAL,   -- Need N
    -- rest of this extension group omitted
    ]]
}

Two rules govern this pair. The network may configure supplementaryUplink here only when the cell already advertises SUL in one of the two common configurations above. And the network includes either supplementaryUplinkRelease-r16 or supplementaryUplink at a time, never both, because one adds the carrier and the other removes it.

The threshold that comes with it

A cell that offers SUL has to tell the UE when to use it, and that number lives in the random access configuration rather than in the uplink configuration.

Following is based on 38.331 v19.3.0 (Release 19). Excerpt, marked the same way as the one above.

RACH-ConfigCommon ::=               SEQUENCE {
    rach-ConfigGeneric                  RACH-ConfigGeneric,
    -- fields omitted
    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
    -- remaining fields omitted
}

• rsrp-ThresholdSSB-SUL : the UE selects the SUL carrier for random access based on this threshold. 38.331 states that the value applies to all the BWPs and all RACH configurations, so a UE does not get a different threshold on a different BWP.
• Cond SUL : the field is mandatory present in rach-ConfigCommon of the initial uplink BWP whenever SUL is configured, and absent otherwise. A cell therefore cannot advertise SUL and leave the threshold out.

One more information element is worth reading, because it explains why a SUL carrier needs more description than an ordinary TDD uplink does.

Following is based on 38.331 v19.3.0 (Release 19). Excerpt, marked the same way as the one above.

FrequencyInfoUL ::=                 SEQUENCE {
    frequencyBandList                   MultiFrequencyBandListNR    OPTIONAL,   -- Cond FDD-OrSUL-OrEarlyUL-Sync
    absoluteFrequencyPointA             ARFCN-ValueNR               OPTIONAL,   -- Cond FDD-OrSUL-OrEarlyUL-Sync
    scs-SpecificCarrierList             SEQUENCE (SIZE (1..maxSCSs)) OF SCS-SpecificCarrier,
    additionalSpectrumEmission          AdditionalSpectrumEmission  OPTIONAL,   -- Need S
    p-Max                               P-Max                       OPTIONAL,   -- Need S
    frequencyShift7p5khz                ENUMERATED {true}           OPTIONAL,   -- Cond FDD-TDD-OrSUL-Optional
    -- extension groups omitted
}

Look at the condition on the first two fields. Both frequencyBandList and absoluteFrequencyPointA are mandatory for a paired FDD uplink and for a SUL carrier, and both are absent for an unpaired TDD uplink. The reason is the same in both cases. A TDD uplink shares its frequency with the downlink, so the UE can derive it. A SUL carrier is somewhere else entirely, on a band the downlink never touches, so it has to be stated.

• The same idea carries three field names : supplementaryUplink in the SIB1 form, supplementaryUplinkConfig in the dedicated common form, and supplementaryUplink again in ServingCellConfig. Searching a log for one of them will miss the other two.
• Broadcast SUL and dedicated SUL are separate grants : the first lets an idle UE reach the cell on the low band. The second lets a connected UE be scheduled there, and a UE can be given the first and never the second.
• The threshold is not optional in practice : Cond SUL makes rsrp-ThresholdSSB-SUL mandatory in the initial uplink BWP whenever SUL is configured, so its absence in a decode means SUL is not configured either.
• Removal has its own field : supplementaryUplinkRelease-r16 takes the carrier away, and the network never sends it together with a new supplementaryUplink.
• A SUL carrier states its own frequency : absoluteFrequencyPointA and frequencyBandList are conditional-mandatory for SUL, exactly as they are for paired FDD. Nothing about the downlink implies where the SUL carrier is.

Choosing Between the Two Uplinks

The illustration near the top of this page gives one answer for random access and one for PUSCH. The full picture has four, and they do not all consult the same input. One reads a measurement, two read a field in a downlink message, and the fourth reads nothing at all because it was decided at configuration time. Mixing them up is the usual reason a SUL log does not match expectation.

The measurement decides only the first row. Once the network gives an explicit instruction, the threshold is no longer consulted.

Random access, when nothing was signalled

This is the case the quotation from 38.321 above describes, and it is worth reading the lines that come before the quoted ones. The carrier is not chosen by measurement first. It is chosen by measurement only when nothing else has already chosen it.

• If the carrier to use is explicitly signalled, the UE selects the signalled carrier.
• Otherwise, if the serving cell is configured with supplementary uplink and the RSRP of the downlink pathloss reference is less than rsrp-ThresholdSSB-SUL, the UE selects the SUL carrier.
• Otherwise the UE selects the NUL carrier.

One detail in the same clause is easy to miss. The UE also sets P_CMAX to the value for the selected carrier. The power ceiling follows the carrier, so the two uplinks do not share a budget, and a SUL transmission is not limited by what the NUL carrier was allowed.

Random access ordered by the network

A PDCCH order carries its own UL/SUL indicator field, and 38.213 clause 8 says the UE uses that field value to determine the carrier for the corresponding PRACH. The measurement is not consulted. The quotation from 38.213 further up this page describes this mechanism. It is also why a UE can be moved to the SUL carrier while its RSRP sits far above the threshold.

Scheduled uplink data

For PUSCH the carrier travels in the grant. 38.212 defines the UL/SUL indicator as one bit, and Table 7.3.1.1.1-1 gives it two values: 0 is the non-supplementary uplink and 1 is the supplementary uplink. That is the field the two PDCCH clips in Example 01 differ in, and they differ in nothing else.

Whether the bit is there at all is a separate question, and DCI format 0_0 answers it differently from DCI format 0_1. In format 0_1 the bit is absent when the UE has no supplementaryUplink configured. It is absent again when SUL is configured but only one carrier of the cell is configured for PUSCH. In format 0_0 the bit appears only when the format is being padded, because it sits in the last bit position after the padding bits. So a UE with SUL configured can still receive a format 0_0 grant that carries no indicator.

38.212 then says what happens in that case, and the fallback order is worth knowing.

• If the indicator is present but pusch-Config is not configured on both uplinks, the UE ignores the field and uses the uplink that carries pucch-Config.
• If the indicator is absent and pucch-Config is configured, the grant is for the uplink that carries pucch-Config.
• If the indicator is absent and pucch-Config is not configured, the grant is for the uplink on which the latest PRACH was transmitted.

Control signalling, decided once

PUCCH never chooses. 38.300 clause 6.9 states that overlapping PUCCH transmissions are avoided through configuration, and that PUCCH can only be configured for one of the two uplinks of the cell. The same restriction reaches further than PUCCH: 38.331 says that beam failure recovery, when SUL is present, is configured on one of the uplink carriers only.

That single fact is what makes the fallback rules above work. Because exactly one uplink carries pucch-Config, a UE that cannot read an indicator always has an unambiguous carrier to fall back to.

• The threshold governs one case only : it decides random access when no carrier was signalled. A PDCCH order and a scheduling grant both override it, and neither one looks at RSRP.
• One bit carries the whole decision for PUSCH : 0 for the non-supplementary uplink, 1 for the supplementary uplink. In the Example 01 clips that bit is sul_ind, and it is the only field that changes between the two grants.
• A missing indicator is not an error : format 0_1 omits the bit when only one carrier is configured for PUSCH, and format 0_0 carries it only when the format is padded. The fallback rules then decide.
• PUCCH anchors the fallback : because only one uplink can hold pucch-Config, the UE always has a defined carrier when the grant does not name one.
• The power ceiling travels with the carrier : the UE sets P_CMAX to the value of the carrier it selected, so the two uplinks are budgeted separately.
• A random access procedure does not change carriers midway : 38.300 clause 9.2.6 states that once started, all uplink transmissions of the procedure remain on the selected carrier.

Reference

• 2023 Switched Uplink in 5G-NR: Benefit & Deployment Consideration - Qualcomm
• 3GPP TS 38.331 V19.3.0 : NR; Radio Resource Control (RRC) protocol specification. Source for every ASN.1 excerpt on this page
• 3GPP TS 38.321 V19.3.0 : NR; Medium Access Control (MAC) protocol specification. Clause 5.1.1 holds the carrier selection for random access
• 3GPP TS 38.212 V19.4.0 : NR; Multiplexing and channel coding. Table 7.3.1.1.1-1 defines the UL/SUL indicator
• 3GPP TS 38.213 V19.4.0 : NR; Physical layer procedures for control. Clause 8 covers the PDCCH order
• 3GPP TS 38.300 : NR; Overall description. Source of the quotations in Operation Highlights
• 3GPP TS 38.101-1 : NR; UE radio transmission and reception, Part 1: Range 1 Standalone. Table 5.2-1 lists the SUL operating bands