Turning Standards into Tests: How CONSET Constrains the LLM

CONSET's central engineering problem is not simply generating unusual 5G messages. It is turning a specification relationship into a test that remains structurally acceptable, violates one meaningful condition, and produces evidence that can be interpreted. This chapter follows that path from the RRC schema and normative text to an admitted rule, a controlled edit, and an execution oracle. The reader should come away able to explain why the language model is useful in one part of the pipeline, why it must be constrained, and how the design preserves attribution.

The distinction matters because automation can fail in two opposite directions. A syntax-only system can generate many inputs that never reach the semantic logic under study. An unconstrained language model can suggest relationships that sound plausible but are not supported by the cited standard or cannot be encoded. CONSET treats both problems as engineering boundaries: evidence must be assembled before inference, and every inferred rule must pass deterministic checks before it can drive a test.

From two incomplete standards views to an admitted rule

The pipeline begins with two complementary views of RRC. TS 38.331 provides the ASN.1 structure: field names, types, domains, optional components, extension markers, and need-code annotations. That schema is authoritative for what a message can represent. It is not a complete description of how every field must relate to every other field during UE behavior.

The second view comes from normative prose across the 3GPP specifications. The paper draws on the 38.2xx family for relations involving physical-layer, MAC, RLC, and related behavior. Those requirements may say that one field depends on another, that a reference must correspond to an object elsewhere, or that a condition applies only in a particular mode. The statements are often distributed across documents and expressed in ordinary technical language rather than attached to a machine-readable schema constraint.

Neither view is enough alone. A schema can tell a tool that an identifier is an integer and that a field has a permissible domain, but it may not say which other identifier it must match. A prose sentence can state that two values are associated, but without the ASN.1 block it may be unclear which canonical fields are meant, whether an alias is ambiguous, or whether the proposed values can be re-encoded. The first design choice, then, is to join the views without pretending they have the same authority or structure.

CONSET uses deterministic selection to build a small evidence package for a candidate field or field pair. Scanning looks for strong cues such as “shall,” “must,” “required,” “if,” “when,” “only if,” “depends on,” “correspond,” “match,” or “associate.” A context window around the cue is retained so the condition and its effect remain together. Field-matching logic accounts for variations in how a specification names the same concept, but abbreviations alone are not treated as reliable identity. An abbreviation is accepted only when the target fields are uniquely identifiable in the same relevant context and scope.

This stage is deliberately more conservative than a general document search. A nearby mention is a lead, not a rule. The text might be describing an alternative release, an advisory recommendation, a different procedure, or a condition whose antecedent is outside the selected window. The candidate must retain enough wording to show a normative constraint, and it must bind to the intended fields.