When a Valid Message Crashes a Modem
The important question now is what the UE-side semantic model revealed when it was turned into controlled tests. This chapter examines how four kinds of RRC inconsistency mapped to failures in an open-source UE and commercial smartphones, and how the paper's measurements should be interpreted. The aim is not to collect dramatic crash reports, but to distinguish a reproducible implementation failure, a vendor-confirmed vulnerability, and a broader claim about affected devices or networks.
That distinction matters because the same visible symptom can arise from different causes. An assertion may identify a violated internal assumption, while a modem restart exposes only the fact that a black-box device stopped serving. A small test set may be more useful than a large enumeration because each input has a reason, but a measured reduction in test volume is not proof of complete coverage. The evidence becomes valuable when the path from semantic rule to observed outcome remains visible.
Four violations, four failure paths
The paper's case studies begin with the four constraint classes already established: value range, field presence, intra-IE dependency, and inter-IE dependency. Each asks a different part of the UE implementation to defend a different assumption. The cases are therefore not interchangeable examples of “bad packets.” They are examples of how a structurally acceptable RRC object can fail at different points after decoding.
A value-range case targets the boundary of an individual field. The paper describes changing startPosition outside its declared domain while leaving the rest of the message intact. The resulting object remained acceptable to the encoder and could be delivered as a structurally well-formed message, even though the modified field violated the specification's range. In the OAI UE, the message was decoded without effective post-decode range validation. The invalid value then propagated into later computation and caused a crash.
This path isolates a familiar but important engineering error: treating the decoder as the final guardian of every domain. The schema states what the value should be, but a downstream routine may still receive an unchecked integer if the relevant guard is inactive or absent. A robust consumer should validate before using the value in an index, length, or derived calculation, and should turn a failure into a controlled rejection or recovery. The case demonstrates an availability consequence in the tested OAI implementation; it does not show that every out-of-range field in every UE has the same result.
A presence case tests a different assumption: that the absence of an optional field has been interpreted according to its need-code semantics. The paper removed an optional field from an otherwise valid downlink RRC message and observed a reproducible OAI crash during later processing. The important semantic question was not simply whether the field could be omitted from the encoding. It was whether the UE should retain a prior configuration, remove it, or take another defined action after omission.
Presence errors are easy to misunderstand because “optional” sounds like “irrelevant.” In a stateful protocol, omission can be an instruction. A missing component may mean that an earlier value remains active, or that an earlier value must be cleared. If the decoder constructs a missing member but the consumer expects a configured object, the implementation can cross an interface with an incomplete state. The failure then appears later, perhaps in power control or another procedure, even though the message was accepted at the structural boundary.