5G/NR

 

 

 

RAN Slicing

 

A network slice always has a RAN part and a core part. The core part, with S-NSSAI, NSSAI types and who decides which slice a UE gets, is described in the Network Slicing page. This page looks at the other half. What does the gNB know about slices, and what can it do with that knowledge ? In Release 15 the answer was "quite a lot in the connected state, almost nothing before that". Release 17 changed the second part with two features: slice-based cell reselection and slice-based RACH.

Both Release 17 features use the same new idea, the NSAG (Network Slice AS Group). An NSAG is a small ID for a group of slices, so the radio side can talk about slices without carrying full S-NSSAIs in system information. The page follows the history in order: what Release 15 already did, why that was not enough for idle and inactive UEs, how the two Release 17 features work, and what came after.

What does the RAN know about a slice ?

Let's start from a basic question. If a slice is a logical network, what does it mean for a gNB, which has only one set of radio resources ? The gNB does not run a separate air interface per slice. TS 38.300 says that the network can realize different slices by scheduling and by giving different L1/L2 configurations. So in the RAN, a slice is mostly a label that changes how the gNB treats a PDU session: its admission, its priority in the scheduler and the RRM policy behind it.

The label is the S-NSSAI. It has a mandatory 8 bit SST (Slice/Service Type) and an optional 24 bit SD (Slice Differentiator). A UE can use up to 8 slices at the same time, although the network can support hundreds. The identification and the different NSSAI lists are explained in Identification of Network Slice on the Network Slicing page.

  • Slice awareness is per PDU session: every NGAP message that carries PDU session resources also carries the S-NSSAI of that session. Traffic of different slices is handled by different PDU sessions.
  • The core validates, the RAN applies: the 5GC checks whether the UE may use a slice. The RAN only applies its configured policy for the slice, and before Initial Context Setup it can apply a provisional local policy.
  • Resource isolation is implementation: the RAN can give a slice shared, prioritized or dedicated resources through RRM policies configured by OAM (TS 28.541). How it does this in the scheduler is not specified.
  • Only one signalling connection: a UE using several slices still has one RRC connection. Slicing does not multiply the control plane.

Day 1 - Release 15 RAN slicing

Release 15 already gave the RAN everything it needs in RRC_CONNECTED. The gNB learns which slices a TA supports, which slices a UE is allowed to use, and which slice each PDU session belongs to. Figure 1 shows where this information enters the RAN during a normal registration and PDU session setup. Note that the UE itself says almost nothing about slices on the radio, except once in RRCSetupComplete.

UE gNB AMF 1. NG SETUP REQUEST : slice support list per TA 2. NG SETUP RESPONSE : S-NSSAIs per AMF 3. RRCSetupComplete : s-NSSAI-List 4. select AMF by Temp ID or NSSAI 5. INITIAL UE MESSAGE (Registration Request) 6. INITIAL CONTEXT SETUP REQUEST : Allowed NSSAI 7. PDU SESSION RESOURCE SETUP : S-NSSAI per session 8. slice-aware admission, RRM

Figure 1. Where slice information enters the RAN in Release 15. Almost all of it comes from the core over NG. The UE gives its NSSAI only once, for AMF selection.

  • Steps 1 and 2: in NG Setup the gNB tells the AMF which slices are supported in each TA, and the AMF tells the gNB which S-NSSAIs it supports. The AMF Configuration Update can change the AMF list later.
  • Steps 3 and 4: the UE includes s-NSSAI-List in RRCSetupComplete when NAS provides it. The gNB uses it only to choose an AMF when there is no valid Temp ID. With a valid Temp ID, the AMF is chosen from the Temp ID. With neither, the gNB uses a default AMF configured by OAM.
  • Step 6: Initial Context Setup gives the gNB the Allowed NSSAI of the UE. This is the list of slices the UE may use in this registration area.
  • Steps 7 and 8: each PDU session comes with its S-NSSAI. Now the gNB can apply slice policies to that session, while still applying normal 5QI based QoS inside the slice.
  • Mobility: the S-NSSAI travels with each PDU session in handover signalling. An Xn handover is allowed only when the target supports at least one of the slices with active PDU sessions. An NG handover is allowed regardless of the target's slice support.

There is one more Release 15 tool that often appears in slicing discussions: unified access control. Operator-defined access categories can be linked to slices, and the gNB can broadcast barring parameters for those categories. So a congested slice can be barred without barring everything else. The mechanism is described in the UAC page.

Why Release 17 needed more ?

Look at Figure 1 again and ask: what does an idle UE know about slices on the radio ? Nothing. It camps on cells with the normal cell reselection priorities, which are per frequency and do not care about slices. It does random access with the same preambles as every other UE. The gNB learns about the UE's slices only after RRC setup, and sometimes only after Initial Context Setup.

This causes two problems. The first is camping. An operator may deploy a slice only on some frequencies, for example an industrial slice on one band. If the UE camps on another frequency, it has to connect and then be handed over, which costs time and signalling. The second is access. If one slice has a burst of access attempts, all slices suffer RACH congestion together, because there is no way to separate them before the UE is identified.

Then why not put S-NSSAIs into system information ? Because an S-NSSAI is up to 32 bits, a UE can have up to 8, and broadcasting them per frequency would be large. It would also expose the slice structure of the operator in clear text. Release 17 introduced the NSAG to solve both issues.

  • NSAG: Network Slice AS Group, an 8 bit ID (NSAG-ID-r17). It stands for a group of slices, and the mapping between slices and NSAG is defined in the core (TS 23.501).
  • NAS gives the UE its NSAGs: the UE gets the NSAG information from NAS, with a priority for each NSAG and its validity. The UE AS uses only the NSAGs of slices that NAS indicates for cell reselection or for random access.
  • TA scope: an NSAG can be valid only in some TAs, which is why NSAG-IdentityInfo-r17 can carry a tracking area code together with the NSAG ID.
  • OAM configures the RAN side: the supported NSAGs, their reselection priorities and their RACH resources are configured in the gNB by OAM. The gNB tells the AMF the NSAG information per TA over NG.

Slice-based cell reselection

The first Release 17 feature lets the network steer idle and inactive UEs to frequencies where their slices are available. The question is how to combine three priorities: the normal frequency priority from SIB4 or RRCRelease, the priority that NAS gave to each NSAG, and the per-NSAG priority that the network broadcasts for each frequency. TS 38.304 clause 5.2.4.11 defines the order, and it is worth reading slowly because the order is not what most people guess.

The network side information comes in SIB16, or in dedicated signalling in RRCRelease. Valid dedicated information in RRCRelease always has priority over SIB16. For each frequency, the network lists the NSAGs supported on that frequency, each with an optional NSAG-specific reselection priority, and optionally a list of cells where the NSAG is or is not supported.

Following is based on 38.331 v19.4.0 (Release 19)

SIB16-r17 ::=                    SEQUENCE {
    freqPriorityListSlicing-r17      FreqPriorityListSlicing-r17              OPTIONAL,  -- Need R
    lateNonCriticalExtension         OCTET STRING                             OPTIONAL,
    ...
}

FreqPriorityListSlicing-r17 ::= SEQUENCE (SIZE (1..maxFreqPlus1)) OF FreqPrioritySlicing-r17

FreqPrioritySlicing-r17 ::=     SEQUENCE {
     dl-ImplicitCarrierFreq-r17            INTEGER (0..maxFreq),
    sliceInfoList-r17                     SliceInfoList-r17                                               OPTIONAL  -- Cond Mandatory
}

SliceInfoList-r17 ::=             SEQUENCE (SIZE (1..maxSliceInfo-r17)) OF SliceInfo-r17

SliceInfo-r17 ::=                 SEQUENCE {
    nsag-IdentityInfo-r17             NSAG-IdentityInfo-r17,
    nsag-CellReselectionPriority-r17  CellReselectionPriority                                             OPTIONAL,  -- Need R
    nsag-CellReselectionSubPriority-r17 CellReselectionSubPriority                                        OPTIONAL,  -- Need R
    sliceCellListNR-r17               CHOICE {
        sliceAllowedCellListNR-r17        SliceCellListNR-r17,
        sliceExcludedCellListNR-r17       SliceCellListNR-r17
    }                                                                                                     OPTIONAL  -- Need R
}

SliceCellListNR-r17 ::=           SEQUENCE (SIZE (1..maxCellSlice-r17)) OF PCI-Range

NSAG-IdentityInfo-r17 ::=            SEQUENCE {
    nsag-ID-r17                          NSAG-ID-r17,
    trackingAreaCode-r17                 TrackingAreaCode               OPTIONAL      -- Need R
}

NSAG-ID-r17 ::=                      BIT STRING (SIZE (8))

CellReselectionPriorities ::=       SEQUENCE {
    freqPriorityListEUTRA               FreqPriorityListEUTRA                                               OPTIONAL,       -- Need M
    freqPriorityListNR                  FreqPriorityListNR                                                  OPTIONAL,       -- Need M
    t320                                ENUMERATED {min5, min10, min20, min30, min60, min120, min180, spare1} OPTIONAL,     -- Need R
    ...,
    [[
    freqPriorityListDedicatedSlicing-r17 FreqPriorityListDedicatedSlicing-r17                               OPTIONAL        -- Need M
    ]]
}

FreqPriorityDedicatedSlicing-r17 ::=     SEQUENCE {
     dl-ExplicitCarrierFreq-r17               ARFCN-ValueNR,
    sliceInfoListDedicated-r17               SliceInfoListDedicated-r17                                    OPTIONAL  -- Cond Mandatory
}

SliceInfoListDedicated-r17 ::=           SEQUENCE (SIZE (1..maxSliceInfo-r17)) OF SliceInfoDedicated-r17

SliceInfoDedicated-r17 ::=               SEQUENCE {
    nsag-IdentityInfo-r17                    NSAG-IdentityInfo-r17,
    nsag-CellReselectionPriority-r17         CellReselectionPriority                                       OPTIONAL,  -- Need R
    nsag-CellReselectionSubPriority-r17      CellReselectionSubPriority                                    OPTIONAL   -- Need R
}
  • dl-ImplicitCarrierFreq-r17: in SIB16 the frequency is an index, 0 for the serving frequency and otherwise a position in the frequency list of SIB4. In RRCRelease the frequency is explicit (dl-ExplicitCarrierFreq-r17).
  • sliceInfoList-r17: up to 8 NSAGs per frequency (maxSliceInfo-r17).
  • nsag-CellReselectionPriority / SubPriority: the priority of this frequency when this NSAG is used to set the frequency priority. The UE uses it only to break ties, as explained below.
  • sliceAllowedCellListNR / sliceExcludedCellListNR: up to 16 PCI ranges (maxCellSlice-r17). An allowed list means only those cells support the NSAG on this frequency. An excluded list means all cells except those support it. These lists exist only in SIB16, not in the dedicated version.
  • UE capability: sliceInfoforCellReselection-r17. A UE without it ignores all this and uses normal reselection.

Figure 2 shows the priority rules. The key point is the order of the first two rules. The NAS priority of the NSAG decides first, and the network broadcast NSAG priority only orders frequencies that support the same top NSAG. The normal cellReselectionPriority is used only for frequencies that support none of the UE's NSAGs.

Rule 1 Frequencies that support at least one NAS-provided NSAG are above all frequencies that support none. An NR frequency supports an NSAG if its nsag-ID and TA match the NAS-provided NSAG information. Rule 2 Among them, order by the NAS-provided priority of the highest-priority NSAG supported on the frequency. The UE's own slice preference comes first, from NAS. Rule 3 Ties on the same top NSAG are ordered by nsag-CellReselectionPriority from SIB16 or RRCRelease. No nsag-CellReselectionPriority given : lower than any configured value. Rule 4 Frequencies that support none of the NSAGs are ordered by their normal cellReselectionPriority. This is the Release 15 rule, kept as the bottom layer. If the best cell on a chosen frequency does not support the NSAG (allowed or excluded cell list), the UE re-derives the priority with that cell's NSAGs, and uses the re-derived priority for up to 300 seconds or until NAS gives new slice or NSAG information.

Figure 2. Priority rules of slice-based cell reselection (38.304 clause 5.2.4.11). The UE's NAS-provided NSAG priority dominates, the network's NSAG priority breaks ties, and the normal frequency priority applies only where none of the UE's NSAGs is supported.

  • The network cannot override the UE's slice order: a frequency with the UE's top NSAG always beats a frequency with a lower NSAG, whatever the broadcast priorities say.
  • Cell lists make it per cell: a frequency may support an NSAG only in part of the coverage. The allowed and excluded lists handle that, and the 300 second re-derivation prevents the UE from trying the same wrong cell again and again.
  • Fallback is the old behavior: if no slice-based information exists for any of the UE's NSAGs, the UE uses the normal reselection without NSAGs.
  • Intra-frequency is unchanged: slices change frequency priorities only. On one frequency, the UE still ranks cells by the normal R criterion, as described in the Cell Selection Criterion page.

Slice-based RACH and feature combinations

The second Release 17 feature separates random access by slice. The goal is RA isolation and prioritization: a burst from one slice should not block access for another, and an important slice should get through faster. But slicing was not the only Release 17 feature that wanted its own RACH. RedCap UEs, SDT and Msg3 repetition for coverage enhancement wanted their own RACH resources too. Release 18 then added Msg1 repetition and eRedCap. So 3GPP made one general framework for all of them, the feature combination.

The idea is that the network can define additional RACH resources, and label each set of resources with a combination of features. A UE that triggers RA with some features applicable looks for a set labelled with those features. The NSAG is one of the features. The basic RACH procedure itself is unchanged, and it is described in the RACH page.

Following is based on 38.331 v19.4.0 (Release 19)

FeatureCombination-r17 ::= SEQUENCE {
    redCap-r17                 ENUMERATED {true}                                    OPTIONAL,  -- Need R
    smallData-r17              ENUMERATED {true}                                    OPTIONAL,  -- Need R
    nsag-r17                   NSAG-List-r17                                        OPTIONAL,  -- Need R
    msg3-Repetitions-r17       ENUMERATED {true}                                    OPTIONAL,  -- Need R
    msg1-Repetitions-r18       ENUMERATED {true}                                    OPTIONAL,  -- Need R
    eRedCap-r18                ENUMERATED {true}                                    OPTIONAL,  -- Need R
    spare2                     ENUMERATED {true}                                    OPTIONAL,  -- Need R
    spare1                     ENUMERATED {true}                                    OPTIONAL   -- Need R
}

NSAG-List-r17 ::= SEQUENCE (SIZE (1.. maxSliceInfo-r17)) OF NSAG-ID-r17

FeatureCombinationPreambles-r17 ::=   SEQUENCE {
    featureCombination-r17                FeatureCombination-r17,
    startPreambleForThisPartition-r17     INTEGER (0..63),
    numberOfPreamblesPerSSB-ForThisPartition-r17 INTEGER (1..64),
    ssb-SharedRO-MaskIndex-r17            INTEGER (1..15)                                           OPTIONAL, -- Need S
    groupBconfigured-r17                  SEQUENCE {
        ra-SizeGroupA-r17                     ENUMERATED {b56, b144, b208, b256, b282, b480, b640,
                                                        b800, b1000, b72, spare6, spare5,spare4, spare3, spare2, spare1},
        messagePowerOffsetGroupB-r17          ENUMERATED { minusinfinity, dB0, dB5, dB8, dB10, dB12, dB15, dB18},
        numberOfRA-PreamblesGroupA-r17        INTEGER (1..64)
    }                                                                                               OPTIONAL, -- Need R
    separateMsgA-PUSCH-Config-r17         MsgA-PUSCH-Config-r16                                     OPTIONAL, -- Cond MsgAConfigCommon
    msgA-RSRP-Threshold-r17               RSRP-Range                                                OPTIONAL, -- Need R
    rsrp-ThresholdSSB-r17                 RSRP-Range                                                OPTIONAL, -- Need R
    deltaPreamble-r17                     INTEGER (-1..6)                                           OPTIONAL, -- Need R
    ...,
    [[
    msg1-RepetitionNum-r18                ENUMERATED {n2, n4, n8, spare1}                                   OPTIONAL, -- Cond Msg1Rep2
    msg1-RepetitionTimeOffsetROGroup-r18  ENUMERATED {n4, n8, n16, spare1}                             OPTIONAL  -- Cond Msg1Rep3
    ]]
}

AdditionalRACH-Config-r17 ::=       SEQUENCE {
    rach-ConfigCommon-r17               RACH-ConfigCommon                                                   OPTIONAL,  -- Need R
    msgA-ConfigCommon-r17               MsgA-ConfigCommon-r16                                               OPTIONAL,  -- Need R
    ...,
    [[
    sbfd-RACH-DualConfig-r19            SBFD-RACH-DualConfig-r19                                     OPTIONAL  -- Cond NoSingleConfig
    ]]
}

RA-PrioritizationForSlicing-r17 ::=    SEQUENCE {
    ra-PrioritizationSliceInfoList-r17     RA-PrioritizationSliceInfoList-r17,
    ...
}

RA-PrioritizationSliceInfo-r17 ::=     SEQUENCE {
    nsag-ID-List-r17                       SEQUENCE (SIZE (1..maxSliceInfo-r17)) OF NSAG-ID-r17,
    ra-Prioritization-r17                  RA-Prioritization,
    ...
}
  • FeatureCombination-r17: the label. Each field that is present is one feature of the combination. For slicing, nsag-r17 lists the NSAGs that may use these resources.
  • FeatureCombinationPreambles-r17: one preamble partition with its label. It gives the start preamble and the number of preambles per SSB for this partition, and can have its own group B, MsgA PUSCH, RSRP thresholds and deltaPreamble.
  • featureCombinationPreamblesList-r17: in RACH-ConfigCommon and in the 2-step version, a list of up to 16 such partitions (38.331 field description). These share the RACH occasions of that RACH configuration and split its preambles.
  • additionalRACH-ConfigList-r17: in BWP-UplinkCommon, up to 16 additional RACH configurations in practice. Each one is a full RACH-ConfigCommon and/or MsgA-ConfigCommon, with its own RACH occasions, and all its preambles are associated to features.
  • RA-PrioritizationForSlicing-r17: separate from the partitions. It gives NSAG-specific RA prioritization parameters (RA-Prioritization, which carries a higher power ramping step and a backoff scaling factor). It applies in the initial BWP only.

Figure 3 shows the two ways to separate access. Preamble partitioning keeps one set of RACH occasions and splits the preambles. A separate RACH configuration gives the features their own occasions. The first costs nothing in time and frequency resources but reduces the preambles per group. The second isolates fully but needs more PRACH resources.

Preamble partitions in one RACH configuration CB preambles of one SSB on one RACH occasion no feature nsag {5} partition redCap partition startPreambleForThisPartition, numberOfPreamblesPerSSB-ForThisPartition Additional RACH configuration rach-ConfigCommon : RACH occasions A AdditionalRACH-Config : RACH occasions B all preambles associated to nsag {7} additionalRACH-ConfigList-r17 in BWP-UplinkCommon How the UE chooses (38.321 clause 5.1.1b) 1. No set for any applicable feature : use the resources without feature indication. 2. One set covers all applicable features : use it. 3. Only sets for a subset of the features : choose by featurePriorities in SIB1 (lower value is higher priority). Only for CBRA without dedicated resources. With Msg1 repetition, the set with the highest repetition number wins among full matches.

Figure 3. Two ways to give an NSAG its own random access. A preamble partition shares the RACH occasions, while an additional RACH configuration has its own occasions. Either way, the UE picks the set whose feature label matches the features of the current RA.

  • Who says the NSAG applies: the upper layers, when the RA is initiated. If the UE AS receives no NSAG information from NAS for random access, it does not use slice-based RACH at all.
  • Not for every RA: the feature selection applies when neither contention free resources nor SI request resources are provided. A handover with dedicated preambles does not use it.
  • featurePriorities-r17 in SIB1: redCapPriority, slicingPriority, msg3-Repetitions-Priority and sdt-Priority, plus the Release 18 msg1-Repetitions-Priority and eRedCapPriority. A RedCap UE that also triggers slicing, and finds only a RedCap set and a slicing set, uses these to choose.
  • Unmatched NSAG: if no slice-based RACH configuration is provided for an NSAG, the UE does not consider that NSAG when selecting RACH resources.

One thing I want to point out is what the gNB learns from this. When a preamble arrives in an NSAG partition, the gNB knows the access belongs to that slice group before it knows who the UE is. That is the real value of the feature for admission and overload control. The same information comes back later in the RA report, where Release 18 added triggeredFeatureCombination and usedFeatureCombination, as described in RA-InformationCommon on the SON page. SDT is one of the other features in the same framework, and it is described in the SDT page.

Release 18 and later

After Release 17, RAN slicing work moved from idle mode to service continuity and to areas where a slice is only partly available. Most of this is in the core and in RAN3 procedures rather than in RRC, so the UE side changes little. The items below are taken from the latest TS 38.300 clause 16.3. I have matched them to releases from the field suffixes and my own reading, so treat the release tags in this section as approximate.

  • More features in the same RACH framework: msg1-Repetitions-r18 and eRedCap-r18 were added to FeatureCombination, with their priorities in featurePriorities-v1800. The NSAG part is unchanged.
  • Slice service continuity: when a slice runs short of resources, the gNB can use Multi-Carrier Resource Sharing, which sets up CA or DC on another frequency where the same slice is available. It can also use Resource Repartitioning, which lets the slice use the shared or prioritized pool when the RRM policy allows it.
  • Partially Allowed NSSAI: the AMF can signal to the gNB slices that are allowed only in part of the registration area, and the gNB may use this for mobility decisions.
  • Zero resources and Network Slice Area of Service: cells outside the area of service of a slice can be configured with zero resources for it, and this can be exchanged with neighbours for mobility.
  • Network slice replacement: the gNB may support replacing the slice of a PDU session with an alternative S-NSSAI.
  • SON and MDT: the RA report carries feature combination information (Release 18), and Release 19 adds NSAG related logging to Logged MDT with nsag-ID-r19, as described in What does UE log ? on the MDT page.

So the overall line is this. Release 15 made the connected RAN slice-aware. Release 17 made the idle and inactive UE slice-aware, through NSAG based reselection and RACH. Later releases mostly improve what the network does when a slice is congested or not available everywhere.

Reference

  • 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 16.3 (Network Slicing)
  • 3GPP TS 38.304 V19.3.0 : NR; User Equipment (UE) procedures in Idle mode and RRC Inactive state. Clauses 5.2.4.7.2 and 5.2.4.11
  • 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. SIB16, CellReselectionPriorities, RACH-ConfigCommon, FeatureCombination
  • 3GPP TS 38.321 V19.4.0 : NR; Medium Access Control (MAC) protocol specification. Clause 5.1.1b
  • Network Slicing, RACH, UAC, SDT (ShareTechnote)