UAC is a set of mechanism (algorithm) to determine whether to allow the UE for a specific services or state changes. UAC is a pretty complicated algorithm that get many factors involved at each point of decision making process. Overall concept similar to LTE Access Control, but I think the related parameters are more dispersed here and there... causing more confusion -:).  In LTE, Access control is mainy controlled by RRC(SIBs) but it seems NAS has more control ever Access Control in NR seems.

The word "Unified" in the name is not decoration. LTE did not have one access control mechanism. It collected several of them over the years. The list is access class barring, ACB skip, SSAC for MMTel, EAB for delay tolerant devices, and ACDC for specific applications. Each one arrived with its own parameters, its own timers, and sometimes its own SIB. UAC replaced all of them with a single framework, a single parameter structure and a single timer. On the RRC side, NR is genuinely simpler than LTE.

Then why does it feel harder ? I had this backwards for a while. The mechanism got simpler and the reading got harder, and those are two different things. In LTE, RRC decided everything. 36.331 branches on whether the connection is for mobile originating data, signalling, CS fallback or an emergency call. It picks the barring parameter for each branch, and it reads the access classes off the USIM itself. In NR that first half has left RRC. NAS decides what kind of attempt this is. It passes an access category and one or more access identities down to RRC. RRC then runs the check on what it was given, and nothing more.

That is why the parameters look scattered. Following one decision in LTE meant staying inside 36.331 and glancing at the USIM. Following the same decision in NR means three documents. 24.501 holds the access category and access identity tables. 31.102 holds the USIM files. 38.331 holds the barring check itself. Nothing here was made more complicated. The work was moved, and the reader has to move with it.

One habit is worth dropping before going further. In LTE the RRC establishment cause is close to the whole story, so it is tempting to read NR the same way. In NR the establishment cause is the last step rather than the first. It is derived from the access category and the access identity, after the barring check has already allowed the attempt. Starting from the cause means reading the algorithm backwards.

• Factors for UAC mechanism
• Triggers for Checking UAC
• RRC Information for UAC
• USIM Information for UAC
• How to determine Access Identity ?
• What kind of service can be provided for a access category ?
• Mapping between access categories/access identities and RRC establishment cause
• Validation Examples
• Reference

Factors for UAC mechanism

Access control exists for two reasons. The first is that a cell can admit only so many UEs at once. The second is that an operator sometimes needs to protect the core network rather than the radio. Barring is how the network refuses an attempt before that attempt costs anything. UAC is the mechanism that decides which attempts get refused, and the first question is where its inputs come from.

The rough categories of factors affecting UAC is illustarated below and main framework is specified in 24.501-4.5, but you may refer to additional specification like 38.331 and USIM specification for further details.

Figure 1. The three inputs to a UAC decision. None of them is enough on its own, which is why the parameters for a single access attempt have to be collected from three different places.

The table lists where the parameters live. What it does not show is the order they are used in, and that order is the thing worth learning first.

UAC runs in two stages, and the stages sit in different layers. In the first stage NAS decides what kind of access this is. It produces one access category from 24.501 Table 4.5.2.2, and one or more access identities from 24.501 Table 4.5.2.1. In the second stage RRC decides whether that combination is allowed right now. It reads uac-BarringInfo from SIB1 and runs the barring check of 38.331 5.3.14.

So the USIM and the NAS state feed the first stage, and the broadcast feeds the second. The same UE gets a different answer in a different cell, because only the second stage changed. The same UE in the same cell gets a different answer for a voice call than for background data, because only the first stage changed.

The rest of this note follows that split. RRC Information for UAC covers the second stage. USIM Information, How to determine Access Identity and What kind of service cover the first.

• UAC is two decisions, not one : NAS picks the access category and the access identities, and RRC decides whether that pair is barred. Neither layer can answer alone.
• The USIM only feeds the first stage : EF_UAC_AIC and EF_ACC set access identities. They have no effect on the barring parameters the cell broadcasts.
• The broadcast only feeds the second stage : uac-BarringInfo says how a category is treated. It never says which category an attempt belongs to.
• Two UEs in one cell can get different answers : same broadcast, different access identities, and the exemption bitmap separates them before any random draw happens.

Triggers for Checking UAC

A UAC check does not run continuously. It runs at named moments, and the list of those moments is short. Knowing which moment applies matters, because the same UE can pass a check for one attempt and fail the next one seconds later in the same cell.

The list itself lives in NAS rather than in RRC. 24.501-4.5.1 names the moments, and RRC is only asked to answer at each one. That division is the first place where an LTE habit misleads you, because in LTE the equivalent list sits inside 36.331.

Triggers for UAC check is specified in 24.501-4.5.1 and can be summarized as follows.

Two groups sit in that table, and they answer different questions.

The first group is one row. A UE moving from 5GMM-IDLE to 5GMM-CONNECTED runs the check, because a new NAS signalling connection is being built. This is the case most people picture when they hear access barring.

The second group is everything else, and every row in it happens while the UE is already in 5GMM-CONNECTED. A connected UE that starts an MMTel voice call runs a fresh check. So does one that sends an SMS, one that establishes or modifies a PDU session, and one that has uplink data for a session whose user-plane resources are suspended.

That second group is the part worth remembering. Being connected is not a pass. Each new attempt is checked on its own, with its own access category. A cell can therefore carry a data session for a UE while barring the same UE from starting a voice call.

• The check is per attempt, not per connection : a UE already in 5GMM-CONNECTED runs a new check for each new kind of access it starts.
• The trigger decides the access category : an MMTel voice call and a PDU session modification are different rows, so they take different categories and can be barred separately.
• Suspended user-plane resources count as a trigger : an uplink packet for such a PDU session runs the check before the resources are re-established.
• NAS asks, RRC answers : the rows here are upper layer requests, and 38.331 5.3.14 is what returns allowed or barred for each one.

RRC Information for UAC

Everything the network contributes to a UAC decision arrives in one optional field of SIB1. That field is uac-BarringInfo, and it is a small structure with a large amount of indirection inside it. The listings in this section are the part of 38.331 that matters here. The indirection is worth following once before reading them.

This is also the only part of UAC the network can change while the UE is camped. Neither the USIM files nor the NAS mapping tables can be changed from the cell. A cell that starts barring did not reconfigure any UE. It changed one broadcast.

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

SIB1 ::=        SEQUENCE {
    cellSelectionInfo                   SEQUENCE {
        q-RxLevMin                          Q-RxLevMin,
        q-RxLevMinOffset                    INTEGER (1..8)                     OPTIONAL,   -- Need S
        q-RxLevMinSUL                       Q-RxLevMin                         OPTIONAL,   -- Need R
        q-QualMin                           Q-QualMin                          OPTIONAL,   -- Need S
        q-QualMinOffset                     INTEGER (1..8)                     OPTIONAL    -- Need S
    }                                                                          OPTIONAL,   -- Cond Standalone
    cellAccessRelatedInfo               CellAccessRelatedInfo,
    connEstFailureControl               ConnEstFailureControl                  OPTIONAL,   -- Need R
    si-SchedulingInfo                   SI-SchedulingInfo                      OPTIONAL,   -- Need R
    servingCellConfigCommon             ServingCellConfigCommonSIB             OPTIONAL,   -- Need R
    ims-EmergencySupport                ENUMERATED {true}                      OPTIONAL,   -- Need R
    eCallOverIMS-Support                ENUMERATED {true}                      OPTIONAL,   -- Need R
    ue-TimersAndConstants               UE-TimersAndConstants                  OPTIONAL,   -- Need R

    uac-BarringInfo                     SEQUENCE {
        uac-BarringForCommon                UAC-BarringPerCatList              OPTIONAL,   -- Need S
        uac-BarringPerPLMN-List             UAC-BarringPerPLMN-List            OPTIONAL,   -- Need S
        uac-BarringInfoSetList              UAC-BarringInfoSetList,
        uac-AccessCategory1-SelectionAssistanceInfo CHOICE {
            plmnCommon                          UAC-AccessCategory1-SelectionAssistanceInfo,
            individualPLMNList                  SEQUENCE (SIZE (2..maxPLMN)) OF UAC-AccessCategory1-SelectionAssistanceInfo
        }                                                                      OPTIONAL    -- Need S
    }                                                                          OPTIONAL,   -- Need R

    useFullResumeID                     ENUMERATED {true}                      OPTIONAL,   -- Need R
    lateNonCriticalExtension            OCTET STRING                           OPTIONAL,
    nonCriticalExtension                SIB1-v1610-IEs                         OPTIONAL
}

SIB1-v1610-IEs ::=              SEQUENCE {
    ...                                                                        -- the idle mode measurement and positioning SI fields are not UAC related
    nonCriticalExtension                SIB1-v1630-IEs                         OPTIONAL
}

SIB1-v1630-IEs ::=              SEQUENCE {
    uac-BarringInfo-v1630               SEQUENCE {
        uac-AC1-SelectAssistInfo-r16        SEQUENCE (SIZE (2..maxPLMN)) OF UAC-AC1-SelectAssistInfo-r16
    }                                                                          OPTIONAL,   -- Need R
    nonCriticalExtension                SIB1-v1700-IEs                         OPTIONAL
}

SIB1-v1700-IEs ::=              SEQUENCE {
    ...                                                                        -- hsdn-Cell, SDT, RedCap, eDRX and NTN fields are not UAC related
    uac-BarringInfo-v1700               SEQUENCE {
        uac-BarringInfoSetList-v1700        UAC-BarringInfoSetList-v1700
    }                                                                          OPTIONAL,   -- Cond MINT
    ...
    nonCriticalExtension                SIB1-v1740-IEs                         OPTIONAL
}

SIB1-v1740-IEs ::=              SEQUENCE {
    si-SchedulingInfo-v1740             SI-SchedulingInfo-v1740                OPTIONAL,   -- Need R
    nonCriticalExtension                SIB1-v1800-IEs                         OPTIONAL
}

SIB1-v1800-IEs ::=              SEQUENCE {
    ...                                                                        -- the Rel-18 NCR, MUSIM, SDT and feature priority fields are not UAC related
    barringExemptEmergencyCall-r18      ENUMERATED {true}                      OPTIONAL,   -- Cond EM-Barring
    ...                                                                        -- the remaining Rel-18 cell barring fields are not UAC related
    nonCriticalExtension                SEQUENCE {}                            OPTIONAL
}

Three things decide which barring parameters apply to one access attempt. The first is the PLMN. If uac-BarringPerPLMN-List holds an entry for the selected PLMN, that entry is used and uac-BarringForCommon is ignored completely. The second is the access category, which selects one UAC-BarringPerCat entry. The third is uac-barringInfoSetIndex inside that entry, which points at one UAC-BarringInfoSet in the list.

At every step of that chain, a missing entry means the access attempt is allowed. A cell that broadcasts no uac-BarringInfo bars nothing at all. That is the default, and it is why a healthy network shows no barring in a log.

One field in the listing is a trap worth naming. The name barringExemptEmergencyCall-r18 sounds like it belongs to UAC, and it does not. Its field description ties it to cell barring in 38.304, for UEs that would otherwise treat the cell as barred. Cond EM-Barring then places it only in cells serving (e)RedCap or 2Rx XR UEs. It is kept in the listing so that a reader who meets it while searching for emergency barring can rule it out.

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

UAC-BarringPerCatList ::=           SEQUENCE (SIZE (1..maxAccessCat-1)) OF UAC-BarringPerCat

UAC-BarringPerCat ::=               SEQUENCE {
   accessCategory                       INTEGER (1..maxAccessCat-1),
   uac-barringInfoSetIndex              UAC-BarringInfoSetIndex
}

UAC-BarringPerPLMN-List ::=         SEQUENCE (SIZE (1.. maxPLMN)) OF UAC-BarringPerPLMN

UAC-BarringPerPLMN ::=              SEQUENCE {
    plmn-IdentityIndex                  INTEGER (1..maxPLMN),
    uac-ACBarringListType               CHOICE{
        uac-ImplicitACBarringList           SEQUENCE (SIZE(maxAccessCat-1)) OF UAC-BarringInfoSetIndex,
        uac-ExplicitACBarringList           UAC-BarringPerCatList
    }                                                                          OPTIONAL     -- Need S
}

UAC-BarringInfoSetIndex ::=         INTEGER (1..maxBarringInfoSet)

UAC-BarringInfoSetList ::=          SEQUENCE (SIZE(1..maxBarringInfoSet)) OF UAC-BarringInfoSet

UAC-BarringInfoSet ::=              SEQUENCE {
    uac-BarringFactor                   ENUMERATED {p00, p05, p10, p15, p20, p25, p30, p40,
                                                    p50, p60, p70, p75, p80, p85, p90, p95},
    uac-BarringTime                     ENUMERATED {s4, s8, s16, s32, s64, s128, s256, s512},
    uac-BarringForAccessIdentity        BIT STRING (SIZE(7))
}

UAC-BarringInfoSetList-v1700 ::=    SEQUENCE (SIZE(1..maxBarringInfoSet)) OF UAC-BarringInfoSet-v1700

UAC-BarringInfoSet-v1700 ::=        SEQUENCE {
    uac-BarringFactorForAI3-r17         ENUMERATED {p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75, p80, p85, p90, p95}
                                                                               OPTIONAL    -- Need S
}

UAC-AccessCategory1-SelectionAssistanceInfo ::=    ENUMERATED {a, b, c}

UAC-AC1-SelectAssistInfo-r16 ::=    ENUMERATED {a, b, c, notConfigured}

maxBarringInfoSet                       INTEGER ::= 8       -- Maximum number of access control parameter sets
maxAccessCat-1                          INTEGER ::= 63      -- Maximum number of Access Categories minus 1

The set at the end of the chain holds three fields, and each does a different job. Taking them in the order the UE applies them makes the algorithm easier to follow than reading the SEQUENCE from the top.

uac-BarringForAccessIdentity is a bitmap of seven bits, one for each of the access identities 1, 2, 11, 12, 13, 14 and 15. A bit set to zero means that identity is not barred. The polarity is the opposite of what the field name suggests, so it is worth reading twice. A UE holding any one of those identities with its bit at zero is allowed, and no random draw happens at all.

uac-BarringFactor is the probability that a UE without such an exemption is allowed. The UE draws a random number in the range 0 to 1 and compares it with the factor. Lower than the factor means allowed. So p00 bars everything, and p95 allows almost everything.

uac-BarringTime sets how long a barred UE waits, but the wait is not the configured value itself. The UE draws a second random number and starts T390 with (0.7 + 0.6 * rand) * uac-BarringTime. The result is spread over 70% to 130% of the broadcast value. That spread is what stops every barred UE in the cell retrying in the same instant.

Access identity 3 is handled outside the bitmap. Release 17 added uac-BarringFactorForAI3-r17 in a separate extension, conditional on MINT. A UE indicating access identity 3 is checked against that factor rather than against a bit. If the field is absent, the attempt is allowed.

Figure 2 puts the whole check in one picture. The two timer tests at the top run before any broadcast parameter is read, and access category 0 is settled before that too. Everything after those three tests is the parameter selection chain, and the random draw only happens if the chain produced a set and the UE had no exemption.

Figure 2. The access barring check of 38.331 5.3.14. Six of the eight tests can only end in allowed, so a UE is barred either by a timer that is already running or by losing one random draw.

One field carries the result of all of this onto the air. When the check allows the attempt, the UE sends RRCSetupRequest, and establishmentCause tells the gNB what kind of access this is. The value is not chosen freely. 24.501 fixes it from the access identity and the access category, and that mapping is the last section of this note.

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

RRCSetupRequest ::=                 SEQUENCE {
    rrcSetupRequest                     RRCSetupRequest-IEs
}

RRCSetupRequest-IEs ::=             SEQUENCE {
    ue-Identity                         InitialUE-Identity,
    establishmentCause                  EstablishmentCause,
    spare                               BIT STRING (SIZE (1))
}

InitialUE-Identity ::=              CHOICE {
    ng-5G-S-TMSI-Part1                  BIT STRING (SIZE (39)),
    randomValue                         BIT STRING (SIZE (39))
}

EstablishmentCause ::=              ENUMERATED {
                                        emergency, highPriorityAccess, mt-Access, mo-Signalling,
                                        mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, mps-PriorityAccess, mcs-PriorityAccess,
                                        spare6, spare5, spare4, spare3, spare2, spare1}

• A cell that broadcasts no uac-BarringInfo bars nothing : every missing step in the selection chain resolves to allowed. Absence is the permissive default, not a fault.
• Access category 0 is never barred here : it is settled before the broadcast parameters are read at all, which is what lets a paging response reach a barred cell.
• A zero bit means not barred : uac-BarringForAccessIdentity is an exemption map rather than a barring map. Reading it the other way round inverts every conclusion drawn from it.
• The barring time is randomised, not fixed : T390 runs for 0.7 to 1.3 times uac-BarringTime, so two UEs barred by the same broadcast come back at different moments.
• A cell has at most eight parameter sets : maxBarringInfoSet is 8, and up to 63 access categories share them through uac-barringInfoSetIndex. Categories therefore reuse each other's settings.
• establishmentCause is derived, not chosen : the access identity and the access category settle it through the 24.501 mapping tables. A value that looks wrong in a log usually means the access category was wrong.

USIM Information for UAC

The USIM contributes exactly one thing to UAC, and that is the access identity. Two files carry it, and they cover different identity numbers. Neither file has any effect on the barring parameters themselves, which always arrive from the cell.

These values are also the part of UAC that changes slowly. They are set when the subscription is provisioned, not when the network is congested. So a UE barred today will be barred the same way tomorrow, unless the cell changed what it broadcasts.

EFUAC_AIC (UAC Access Identities Configuration) : 31.102-4.4.11.7

Only the two lowest bits of this file are defined. They say whether the subscription is configured for the two priority services that get an access identity of their own. Everything above them is reserved, so the file is one byte carrying two flags.

The two configured priority services. A UE can carry both flags, one, or neither, and neither flag has any meaning outside the home country.

• b1 = 1 : the UE is configured for Multimedia Priority Service in the HPLMN, the EHPLMN or a visited PLMN of the home country. That is access identity 1.
• b2 = 1 : the same statement for Mission Critical Services. That is access identity 2.
• b3 to b8 : RFU.

EFACC (Access Control Class) : 31.102-4.2.15

This is the file LTE has always used, and 5G reuses it unchanged. Each access class the subscription holds is one bit across two bytes. The mapping from bit position to class number runs downwards rather than upwards, and one position in it is not a class at all.

Two bytes, sixteen bit positions, and only five of them reach UAC. The ordinary access classes are still stored here, and 24.501 gives them no access identity.

• Byte 1 : access classes 15 down to 08, across b8 down to b1.
• Byte 2 : access classes 07 down to 00, across b8 down to b1.
• The exception on b3 of byte 1 : the note excepts that bit from the class numbering. It is the position where class 10 would sit, and 24.501 Table 4.5.2.1 gives no access identity to class 10 either.
• Classes 00 to 09 : stored in byte 2 and in the low bits of byte 1, and unused by UAC. Only classes 11 to 15 become access identities.

• The USIM sets identities, never barring : both files decide which access identities the UE may claim, and neither touches uac-BarringInfo.
• EF_UAC_AIC is two bits : b1 for MPS and b2 for MCS, giving access identities 1 and 2. Everything above b2 is reserved.
• Only access classes 11 to 15 matter for UAC : the ordinary classes 00 to 09 sit in EF_ACC and map to no access identity at all.
• The USIM is not the only source : the network can grant access identity 1 or 2 through the 5GS network feature support IE. The How to determine Access Identity section covers that route.

How to determine Access Identity ?

An access identity is a claim about who the subscriber is, not about what the UE is doing. A UE can hold several of them at once, or none. Holding none is the normal case, and it is written as access identity 0 rather than as an absence.

The identity also has more effect than any other input to the check. It is read before the random draw, so a UE with the right identity never meets the barring factor at all. That is the whole point of having priority subscriptions.

Basically Access Identity is determined by a few parameters in UICC as described in the following table.

< 24.501-Table 4.5.2.1: Access identities >

Access identity 0 is the ordinary case, and everything else has to be configured. The NOTEs are where the real conditions are, because a configured identity is not valid in every PLMN.

The table has three blocks. Identity 0 covers every UE with none of the special configurations. Identities 1 and 2 come from the two bits of EF_UAC_AIC. Identities 11 to 15 come from the access class bits of EF_ACC.

The NOTEs matter as much as the rows do. A configured UE does not carry its identity everywhere. Identities 1 and 2 are valid in the HPLMN, an EHPLMN, or a visited PLMN of the home country. Identities 11 and 15 are valid in the HPLMN or an EHPLMN. Identities 12, 13 and 14 are valid in the home country only. The same USIM therefore produces a different set of access identities when the UE roams.

The USIM is also not the only source. NOTE 1 and NOTE 2 give a second route. The RPLMN can send the 5GS network feature support IE with the MPS or the MCS indicator bit set. The UE then holds identity 1 or 2 in that PLMN, with no USIM change. A network can grant priority access to a UE it was never provisioned for.

One row of the table is out of date. It marks 3 to 10 as reserved for future use, and identity 3 is no longer reserved. 38.331 v19.3.0 carries uac-BarringFactorForAI3-r17, and its clause 5.3.14.5 has an explicit branch for Access Identity 3. Both are conditional on MINT. The image is quoted from an earlier release of 24.501, so read that one row against the release you are working in.

• Identity 0 is a value, not an absence : an ordinary UE holds access identity 0, and that is the identity the mapping tables use for it.
• Access identities are PLMN dependent : the NOTEs restrict every non-zero identity to the HPLMN, an EHPLMN or the home country, so roaming changes the set.
• The network can grant identities 1 and 2 : the MPS and MCS indicator bits of the 5GS network feature support IE do it without touching the USIM.
• The quoted table predates access identity 3 : Release 17 assigned it under MINT, and 38.331 5.3.14.5 checks it against uac-BarringFactorForAI3 rather than against a bit in uac-BarringForAccessIdentity.
• Holding more than one identity can only help : the barring check passes as soon as any held identity has its bit set to zero.

What kind of service can be provided for a access category ?

An access category answers a different question from an access identity. The identity says who the subscriber is. The category says what the UE is trying to do right now. 24.501 Table 4.5.2.2 turns the attempt into a number, and that number is what the barring parameters are indexed by.

Everything after this stage sees only the number. Once the category is chosen, the barring check cannot tell a voice call from a software update. That is deliberate. It is what lets an operator bar a class of traffic without knowing what the traffic actually is.

< 24.501-Table 4.5.2.2: Mapping table for access categories >

The same content in access category order. The barring parameters are indexed by the number in the first column, so this is the order that matters once the category has been chosen.

The table is written as a rule list rather than a category list, and the two orders do not match. Rule 1 gives category 0, rule 4 gives category 1, and rule 2 gives category 2. Reading down the Access Category column therefore gives the numbers in no order. The table below carries the same content sorted by category number.

Two details are easy to miss. Category 7 has two rules behind it, so ordinary MO data and an uplink packet on a suspended PDU session share one set of barring parameters and cannot be barred separately. And category 1 is the only one the broadcast helps to select, through uac-AccessCategory1-SelectionAssistanceInfo in SIB1.

The quoted table is also not the current release. 38.331 v19.3.0 acts on an access category 8 in its barring alleviation clause, and no row of this table produces one.

• Category and identity answer different questions : the category describes the attempt and the identity describes the subscriber. The barring check needs both.
• The rule number is not the category number : the table is ordered by matching rule, so reading it as a category list gives the wrong impression of the numbering.
• Category 7 covers two rules : ordinary MO data and an uplink packet on a suspended PDU session take the same category, so they cannot be barred separately.
• Category 1 is the one the broadcast helps select : uac-AccessCategory1-SelectionAssistanceInfo carries a, b or c in SIB1. Rule 4 matches only a UE that is a member of the broadcast one.
• The two ranges are separate : the standardised categories start at 0 and the operator-defined range is 32 to 63, chosen from definitions valid in the current PLMN.

Mapping between access categories/access identities and RRC establishment cause

I read these two tables as duplicates of each other for a long time. They are not. Both cover the same access identities and the same access categories, and they disagree in four places. Which table applies depends on the radio the UE is using to reach the 5G core, and not on anything about the UE itself.

< 24.501 - Table 4.5.6.1: Mapping table for access identities/access categories and RRC establishment cause when establishing N1 NAS signalling connection via NR connected to 5GCN >

< 24.501 - Table 4.5.6.2: Mapping table for access identities/access categories and RRC establishment cause when establishing N1 NAS signalling connection via E-UTRA connected to 5GCN >

The two tables look identical at a glance, and they are not. Four rows differ, and in every one of them the NR table uses a more specific establishment cause than the E-UTRA table does.

The pattern is the same in all four rows. A UE configured for MPS raises mps-PriorityAccess on NR and highPriorityAccess on E-UTRA. A video call raises mo-VideoCall on NR and mo-VoiceCall on E-UTRA. An SMS raises mo-SMS on NR and mo-Data on E-UTRA.

So the same UE, in the same state, with the same access category, puts a different cause on the air depending on which radio it uses to reach the 5G core. Reading an E-UTRA log against the NR table makes correct behaviour look wrong.

One row is not a cause at all. Access category 1, delay tolerant, is marked Not applicable in both tables. NOTE 1 explains it. A UE that used category 1 for the barring check then determines a second access category in the range 3 to 7. That second category is what produces the establishment cause.

• The two tables differ in exactly four rows : access identities 1 and 2, and access categories 5 and 6. Everything else maps the same way on both radios.
• E-UTRA loses the specific causes : mps-PriorityAccess, mcs-PriorityAccess, mo-VideoCall and mo-SMS appear only in the NR table.
• Access identities 11 to 15 all give highPriorityAccess : the five access classes all produce the same cause on both radios, so the cause cannot tell them apart.
• Category 1 produces no cause of its own : a delay tolerant attempt determines a second category in the range 3 to 7, and that one supplies the cause.
• The cause is the only part the gNB sees : the access category and the access identities stay inside the UE. The whole of what reaches the network is establishmentCause in RRCSetupRequest.

Validation Examples

Validating UAC is harder than validating most RRC features, and the reason is not the algorithm. The algorithm is short. The difficulty is that the configuration is spread across SIB1, the USIM and the NAS mapping tables, and that a correct barring decision produces no message at all. There is nothing on the air to point at.

Almost every misconfiguration also fails open rather than closed. A test that shows no barring is therefore consistent with a working UE and with a configuration that never reached it, in equal measure. The examples here are ordered to remove that ambiguity one step at a time. They start with the only setting that gives a yes or no answer from a single trial.

Example 01 : what a barred attempt looks like

Start with what the measurement actually is, because it is not what most RRC test cases measure. A barred attempt produces no RRCSetupRequest. There is no reject, no failure message and no timer that the network can see. The cell observes exactly what it would observe if the UE were not there.

Two consequences follow. A network side trace cannot validate UAC on its own, because barred and out of coverage are the same observable from the cell. And every example below needs either a UE log or a UE that reports its own barring state, so arrange that access before configuring anything.

Example 02 : a deterministic barring check

A barring factor is a probability, so almost any setting makes a single trial meaningless. There is one exception. A factor of p00 means the UE draws a number that can never be lower than it. Every attempt without an exemption is therefore barred. That turns a statistical test into a yes or no test, which is where a bring-up should start.

Expect no RRCSetupRequest for that access category, on every attempt, with no exception. If an attempt does get through, the configuration is probably fine and the access category is wrong. The UE selected a different category from the one you configured, so check the trigger against 24.501 Table 4.5.2.2 before touching the barring parameters again.

Example 03 : the access identity exemption and its polarity

This is the field most often configured backwards, and with p00 already in place its effect is unambiguous. A bit set to zero allows that identity through. A bit set to one leaves it subject to the barring factor. The field name suggests the opposite of what it does, and reading it the wrong way inverts the whole test.

Keep the configuration of Example 02 and provision access class 11 in EF_ACC, so the UE holds access identity 11. Set bit 2 to zero and leave the other six at one. Every attempt should now be allowed, and no T390 should start. Set bit 2 back to one and every attempt should be barred again.

Two failures are worth separating here. If flipping bit 2 changes nothing but flipping a different bit does, the bit order in the configuration is wrong. If flipping any bit changes nothing at all, the UE is not holding access identity 11, and the PLMN is the first thing to check rather than the bitmap.

Example 04 : measuring uac-BarringFactor

Once the deterministic path works, the probability itself can be measured. This example needs more discipline than the others, because a factor of p50 does not mean every second attempt succeeds. Each attempt is an independent draw, and a run of ten successes in a row is ordinary rather than a defect.

One setup detail decides whether the measurement means anything. T390 has to expire between trials. An attempt made while T390 is still running is barred by the timer, before the factor is ever consulted. Retrying too quickly therefore drives the observed pass rate towards zero, whatever the factor says.

A result inside those ranges tells you nothing is wrong. A result of exactly zero or exactly the trial count tells you the draw is not happening at all, and that something earlier in the chain decided the outcome. Repeat the run with p95 and with p05 before trusting the middle of the range. A UE that ignores the factor entirely still passes a single p50 measurement about as often as it fails one.

Example 05 : measuring T390 against its randomised window

The barring timer is randomised as well, so one measurement cannot confirm it either. 38.331 describes uac-BarringTime as the average time before a new access attempt, and the UE spreads the value it actually uses around that average. A wait that does not equal the configured number is the correct behaviour, not a defect.

The UE draws a second random number and starts T390 with (0.7 + 0.6 * rand) * uac-BarringTime. So every wait falls between 0.7 and 1.3 times the broadcast value, and the mean over many trials converges on the value itself.

Two results are defects. A wait outside the window means the UE is not using the parameter set you configured, so go back to the selection chain. A set of waits that are all identical means the randomisation is missing. That one matters in the field rather than in the lab. It is what makes every barred UE in a cell retry together.

Example 06 : the ways a UAC test fails open

Every step of the parameter selection chain resolves to allowed when it finds nothing. That is deliberate in the specification, and it is also why a test showing no barring is so hard to interpret. Four different mistakes produce exactly the same observation, and not one of them appears as an error in any log.

The way to separate them is to go back one step. Return the cell to the deterministic configuration of Example 02, for an access category you can trigger on demand. If that bars, the selection chain is intact and the fault is in the specific configuration under test. If it does not bar, the configuration is not reaching the UE at all, and nothing measured after this point would have meant anything.

Example 07 : triggering each access category on demand

Every example so far configured the cell and then waited for an attempt. Running the table of access categories in reverse is harder. Each category needs a different action on the UE, and some of them are difficult to produce deliberately. This is the list to build a test plan from.

Example 08 : proving which access category an attempt actually used

This is the measurement the whole feature is short of. The access category never appears on the air. The only visible projection of it is establishmentCause, and that projection loses information. Access identities 11 to 15 all produce highPriorityAccess, and access category 1 produces no cause of its own at all.

So the category cannot be read from a trace. It can be probed, and the deterministic setup of Example 02 is what makes the probe binary. A category with no UAC-BarringPerCat entry is always allowed, so configuring exactly one entry puts exactly one category under test and leaves every other category as a control.

One trap is worth preparing for. Moving from 5GMM-IDLE to 5GMM-CONNECTED is itself a trigger, so an action started from idle causes two checks rather than one. If you are probing an SMS and the state change is barred first, the SMS category is never reached. Run the probe from 5GMM-CONNECTED, or accept that the first barred result belongs to the state change.

Example 09 : the two triggers that share access category 7

Rules 9 and 10 of 24.501 Table 4.5.2.2 both produce access category 7. That is the only row of the summary table with two rules behind it, and it has a consequence an operator cannot configure away. Ordinary MO data and the resumption of a suspended PDU session cannot be barred separately, because barring is indexed by category and they share one.

A UE that bars one and allows the other has invented a distinction the specification does not make, and that is a defect worth reporting. The result also matters outside the lab. An operator shedding background traffic in congestion is also blocking sessions that are already established, and there is no parameter that separates the two.

Example 10 : emergency, and what can still bar it

Access category 2 is protected from two mechanisms and not from a third, and the difference is easy to get wrong in both directions. Only access category 0 skips the parameter selection chain. Category 2 goes through it like any other category, which means an explicit configuration can bar an emergency attempt.

So the test has two halves. Configure a barring entry for category 2 deliberately and confirm the UE honours it, because that path has to work. Then read the configuration a live network actually broadcasts and confirm nothing bars category 2 by accident, because the same mechanism works whether or not anyone intended it.

Example 11 : operator-defined categories 32 to 63

These are the only categories whose definition does not come from the radio. SIB1 can carry barring parameters for any category from 1 to 63, because accessCategory is INTEGER (1..maxAccessCat-1) and maxAccessCat-1 is 63. What the category means is not in 38.331 at all, and searching that specification for an operator-defined access category returns nothing.

Two independent configurations therefore have to be right at the same time, and a failure in either one produces the same observation.

The probe of Example 08 separates them in two runs. Bar category 7 alone and send the traffic that is supposed to be operator-defined. If it is barred, the definition never reached the UE and the traffic was categorised as MO_data instead. Then bar category N alone. If that bars it, both halves are working.

One more property is shared with access identities. The definitions are valid in the current PLMN only, so a roaming UE loses them, and traffic that was category 40 at home becomes category 7 abroad.

• A network side trace cannot validate UAC : a barred attempt puts nothing on the air, so barred and out of coverage are identical from the cell. A UE log is not optional here.
• Start deterministic : p00 with every exemption bit at one is the only configuration that gives a yes or no answer from a single trial. Everything else needs repetition.
• Let T390 expire between trials : an attempt made while the timer runs is barred by the timer rather than by the factor, and it corrupts any measurement of the factor.
• Misconfiguration fails open : a dangling uac-barringInfoSetIndex is valid configuration that means no barring. A typo and a deliberate exemption are the same observable.
• Check the PLMN before blaming the bitmap : access identities 11 and 15 are valid in the HPLMN or an EHPLMN only. A roaming UE holds fewer identities than the USIM suggests.
• Randomised values need distributions, not readings : both uac-BarringFactor and uac-BarringTime are verified over many trials, and a single sample of either proves nothing.
• The access category can only be probed, never read : it never reaches the air, and establishmentCause is a lossy projection of it. One barred category at a time is the only reliable measurement.
• Emergency is not exempt from UAC : access category 2 skips T302 and RRCReject barring, but it goes through the parameter selection chain like any other category.

Reference

One specification was read directly for this note, and it is listed below. The 24.501 tables on this page are quoted as images from an earlier release, and they were not compared line by line against the current one. Where those images and 38.331 v19.3.0 disagree, the disagreement is called out in the section that shows the image.

• 38.331 v19.3.0 : NR - Radio Resource Control (RRC) protocol specification. Clause 5.3.14 and the UAC information elements.

[1]