Where the Rules Hide: Four Kinds of RRC Constraint
The UE baseband cannot test semantic correctness with one generic “valid message” check. This chapter maps the four constraint classes that CONSET uses to make early Radio Resource Control (RRC) behavior precise: field ranges, field presence, dependencies within one information element (IE), and dependencies across IEs. The practical goal is to let the reader classify a suspected failure and identify whether its evidence comes from a formal schema, normative prose, or both.
The classification matters because the four cases fail for different reasons. A value can fall outside its allowed domain. An optional field can be missing even though its absence has a specified effect on prior state. Two fields in one IE can be individually legal but mutually inconsistent. Or a field in one IE can refer to the wrong object in another. All four can leave enough structure intact for the UE to decode the message and reach deeper implementation logic.
Four ways a message can be wrong while remaining well-formed
The first class is a field value range constraint. It limits an individual field to a numeric interval or enumerated set. The rule may seem elementary, but it is a meaningful boundary between an abstract message and the code that consumes it. A decoder can expose a number, and an encoder can sometimes reproduce a message containing that number, while a later routine assumes the value lies inside the domain described by the standard. If the assumption is not checked at the point of use, a calculation or table lookup can receive an impossible input.
Range constraints are usually the easiest to derive because the RRC ASN.1 schema states the type domain. That makes them suitable for deterministic extraction and boundary-oriented testing. The important qualification is that schema knowledge and implementation enforcement are different things. The fact that a standard declares a range does not demonstrate that every decoder, re-encoder, or downstream consumer enforces it on every path. A test that preserves the surrounding structure while challenging one boundary asks whether the implementation has supplied the missing check.
The second class is a field presence constraint. ASN.1 optionality answers whether a component may be absent from the encoded structure. It does not fully answer what the UE should do when that component is absent. In RRC specifications, need-code annotations describe behavior associated with optional fields. The paper highlights two primary cases: Need M, which requires the UE to maintain the last configured value, and Need R, which requires the UE to remove or clear the prior value.
This distinction makes presence a state problem. Suppose a configuration was received earlier and a later message omits an optional field. The correct result is not necessarily “there is no value.” It may be “reuse the previous value,” or it may be “discard the previous value.” A parser that constructs an object with a missing member may be behaving correctly at the structural level while leaving the implementation to apply the semantic rule later. If that later step assumes the member is present, or confuses retention with removal, the UE can enter a configuration state that the normal procedure did not anticipate.
The third class is an intra-IE dependency. An information element is a structured unit containing related fields. The fields may each have valid types and values, yet the combination can violate an ordering, bound, mapping, or conditional relation described by the specification. The receiver must therefore interpret the fields together. It is not enough to validate each leaf independently.
Intra-IE rules often express the local geometry of a configuration. One field may describe how many resources are used while another marks where they begin. One enumerated mode may require a particular value or range in a companion field. The specific examples vary across RRC elements, but the implementation pattern is stable: one value changes the meaning or permissible domain of another. A generic ASN.1 decoder sees siblings in a tree; it does not automatically know which sibling relationship is normative.
The fourth class is an inter-IE dependency. Here the relationship crosses the boundary between information elements, and may even connect different protocol sublayers. A reference field in one IE can be meaningful only if it identifies the corresponding object in another IE. A range or configuration in one structure may have to align with a value elsewhere. The two fields are separated in the message representation, so local validation cannot establish the relationship unless the implementation or testing system has an explicit model of it.
Inter-IE dependencies are especially revealing because they expose hidden state ownership. Each IE may be decoded correctly by the component that owns it, but a scheduler or control procedure may later combine them. If the link between the objects is not checked before that handoff, a downstream routine inherits two individually plausible values that describe different configurations. The resulting failure is not a malformed tree. It is a broken association between parts of a larger state model.
These four classes can be compared by asking two questions: where is the rule scoped, and where is its evidence expressed? A value-range rule is usually local to one field and visible in a schema domain. A presence rule is local to a field but extends into the UE's prior state. An intra-IE rule is local to one structured object but depends on multiple fields. An inter-IE rule crosses object boundaries and may require context from another specification or sublayer. The more a rule reaches beyond one field, the less likely a syntax-only tool is to enforce it automatically.
The taxonomy is a testing instrument, not a claim that these are the only forms of correctness in 5G. The paper notes that capability negotiation, protocol state, inter-message timing and ordering, broader procedures, and complex tables or mathematical expressions can impose additional requirements. Those cases may be important, but a message-local taxonomy is a useful starting point because it connects a concrete field relationship to a controlled edit and an observable UE outcome.
The standard is split across grammar and prose
The four classes do not draw their evidence from one uniform document. TS 38.331 is the authoritative source for the RRC ASN.1 structure and field domains. It supplies the names, types, optionality, extension structure, and need-code annotations that a deterministic extractor can map to decoded fields. This is the formal side of the problem: it tells a tool what a field is allowed to look like and where it sits in the message.
Behavioral requirements are distributed more widely. The paper uses normative material across the 3GPP 38.2xx family to find relationships that govern how fields work together. Physical-layer procedures may define a relationship inside an RRC configuration. MAC, RLC, or other specifications may describe how a reference, range, or resource is interpreted. The relevant text is often natural language, with conditions such as “if,” “only if,” or “shall,” rather than a machine-readable constraint attached directly to the ASN.1 declaration.
That distribution creates an evidence-joining problem. A sentence may use an alias instead of the schema's canonical field name. A release-specific extension may change which option is present. A cross-reference may point to another specification. A phrase that sounds restrictive may be advisory rather than normative. Even when two fields are mentioned in the same paragraph, their co-occurrence is only a candidate relationship until the wording and scope show what one field requires of the other.
CONSET addresses this by separating discovery from admission. Deterministic scanning looks for strong cues—mandatory language, conditional markers, dependency phrases, and reference words—and extracts a small context window around them. Field-matching logic accounts for naming variations, but ambiguous abbreviations are not accepted merely because they look familiar. The candidate must be tied to identifiable fields in the intended IE scope. This is an important design choice: text retrieval can be broad enough to find evidence, while rule admission remains conservative enough to reject uncertain mappings.
Two examples show why the distinction between local and cross-IE evidence matters. In an intra-IE case, the paper discusses an SRS configuration relationship between nrofSymbols and startPosition. The surrounding configuration is structurally valid, but a specification requirement constrains how the number of symbols and the starting position can coexist. The rule is meaningful only when both fields are interpreted together; checking each field's type separately would not find the problem.
In an inter-IE case, a SearchSpace identifies a ControlResourceSet through a shared control-resource-set identifier. The association described by the standard requires the reference in the search-space configuration to correspond to the identifier of the selected resource set. Each identifier can be an admissible integer on its own. The semantic failure appears when the two IEs describe different objects while a later scheduler assumes they refer to one.
The examples also show why schema-only and prose-only approaches fail in opposite ways. Without the schema, a sentence about an identifier or a numeric relationship is difficult to bind to an exact field, and a proposed test may use a value that cannot be encoded. Without the normative prose, a tool can enumerate domains and optional fields but cannot see the relation that makes two individually legal values inconsistent. The formal grammar anchors the candidate; the behavioral text explains why the candidate matters.
The paper's evidence ablation makes this division measurable. In its selected intra-IE experiment, full evidence combined the TS 38.331 schema and field descriptions with cross-document prose. That setting produced substantially more accepted, source-backed rules than a TS 38.331-only setting, while an ASN.1-only setting produced none under the citation requirement. The result is not that prose is always better than schemas. It is that the useful semantic rules in this task often require both: structure to bind and constrain the fields, and normative behavior to establish their relationship.
There is a second trade-off in how much of the standard to treat as evidence. A broad text search may improve recall but also produce more aliases, irrelevant co-mentions, and version conflicts. A narrow slice is easier to audit but can omit a condition expressed in a neighboring clause. CONSET's answer is not to pretend the ambiguity does not exist. It records a compact evidence package, requires clear normative wording or an explicit mathematical or tabular relation, checks field domains and satisfiability, and rejects unsupported candidates. The result is fewer rules than an unconstrained interpretation might produce, but each accepted rule has a clearer path back to the standard.
This is also why the taxonomy should not be mistaken for a list of message fields. The security value lies in the relationship between a rule and the implementation assumption it tests. A range rule challenges a boundary check. A presence rule challenges state retention or removal. An intra-IE rule challenges local configuration coherence. An inter-IE rule challenges reference integrity across components. The same field can participate in different kinds of rules depending on its context, and similar-looking names do not establish identical semantics.
For a defender or tester, the classification yields a disciplined question before any execution begins: what exact relationship is being challenged, and what evidence says that the relationship should hold? If the answer is only that a value looks unusual, the candidate is not yet a semantic test. If the answer names a schema domain but no behavioral relation, it may be a boundary probe rather than a dependency test. If it names a prose requirement but cannot bind the fields or produce an encodable assignment, it is not an executable case yet.
The payoff is a sharper understanding of the pre-authentication attack surface. The UE is not vulnerable merely because a message is early, nor safe merely because a parser accepts it. The meaningful question is whether the implementation can preserve the specification's relationships while moving from a decoded object to a live configuration. The next step is to see how a testing system turns that question into a bounded rule, a minimal edit, and evidence that can be interpreted rather than guessed.