I reconstructed this case from a timestamped failed-path trace, before-and-after radio samples and contemporaneous engineering notes for the later test path.
I did not personally execute the archived commands. Device identifiers, operator details, exact carrier values, PCIs and proprietary control messages are withheld.
The question was operationally simple: could the test setup restrict an LTE UE to a chosen target cell and then release that restriction safely?
The answer could not be taken from the command response.
It had to be read from the active serving state.
Real case reconstructed and analysed by Takwa Sebai. The laboratory scene is illustrative, not a raw evidence image.
Direct answer
A response from a modem service proves only the part of the transaction that the response actually describes.
It may prove that:
- the service was reachable;
- the request and response matched;
- the message was decoded;
- a write was accepted;
- a refresh was requested.
It does not automatically prove that the UE changed to the intended serving cell.
For this test, acceptance required five separate proofs:
- the requested restriction was configured;
- the target PCI became the active serving PCI;
- the target was different from the initial serving PCI;
- registration remained available;
- rollback restored unrestricted cell selection.
The second proof was the decisive one.
The test was made discriminating before the useful run
A cell-control test can look successful while proving almost nothing.
If the requested target is already serving, the radio observation may remain unchanged whether the restriction is active or not. If the target is not observable, a failed camp can be caused by the restriction, radio conditions or the selection environment.
The archive identifies a better test condition:
- the target cell was observable;
- it was on the same carrier as the serving cell;
- its PCI differed from the serving PCI;
- the expected post-action observation was therefore visible and specific.
That turns a configuration action into a falsifiable radio test.
The expected state was written down before the run:
| Checkpoint | Expected observation |
|---|---|
| Before | Serving PCI-S; target PCI-T observable |
| Restriction active | PCI-T becomes the serving PCI |
| Service guard | Registration remains available |
| Diagnostic recovery | Required logging application remains alive |
| Rollback | UE returns to unrestricted selection |
The symbols PCI-S and PCI-T are anonymised roles, not public cell identifiers.
First path: the service answered, the function was rejected
The initial method reached a modem-facing service and received a structured response. The transaction matched the request. This was positive control-path evidence.
The requested function was nevertheless rejected before any radio mutation was attempted.
The correct action was to stop.
No storage write was performed. No rollback was needed. The UE remained registered.
This is a small but important reporting distinction:
| Evidence | Defensible statement |
|---|---|
| Matching response | The control service answered the transaction |
| Explicit functional rejection | The requested function was not accepted |
| No write attempted | No configuration mutation was established |
| Registration observed | The UE remained registered during the check |
None of those lines supports “the lock worked”.
The radio changed anyway
During the same short window, the UE changed serving PCI naturally while remaining on the same carrier. RSRP stayed unchanged at the precision recorded in the archive.
That event is the trap in this case.
A reviewer who compared only the PCI before the request and the PCI after the request could have credited a rejected command with a real network event.
The timestamped control response closes that false explanation. The function was rejected before mutation, so the later PCI change cannot be signed off as the intended control effect.
The radio observation was real. The proposed cause was not.
This is why I separate:
- event order;
- control acceptance;
- configured state;
- active serving state;
- service continuity.
They answer different questions.
Second path: a stored restriction was still not enough
The archive then records a pivot to another control mechanism. A restriction was written and a refresh was performed.
That created stronger configuration evidence, but the active result still had to be checked.
With the diagnostic logging stack left active during the refresh window, successive outcomes differed:
- one run exposed the target in the observed cell list while the serving state remained on the previous PCI;
- another run also remained on the previous serving PCI.
The control state existed. The intended serving state was not repeatable enough to accept.
A storage write answers “what was requested or retained”. It does not answer “what is serving now”.
The controlled refresh
The two diagnostic processes present in the archived procedure were paused only for the refresh window and then resumed.
The contemporaneous notebook records the expected sequence:
| Checkpoint | Recorded result | What it proves |
|---|---|---|
| Initial state | Target observable and not serving | The test can discriminate |
| Controlled refresh | Target PCI becomes serving | Intended active state observed |
| Registration check | IN_SERVICE recorded |
Registration available at that checkpoint |
| Resume diagnostics | Required application alive | Test tooling recovered |
| Rollback | Free selection restored | Restriction no longer active |
The process change and the radio result moved together in the recorded run. That supports a bounded operating procedure for the tested stack.
It does not prove an internal modem root cause.
Two processes were paused together. The evidence does not isolate which process, timing interaction or internal resource produced the earlier variation. Claiming one of them as the cause would go beyond the archive.
IN_SERVICE is a narrow service proof
The registration check is useful, but its scope must remain narrow.
IN_SERVICE supports the statement that the UE was registered at the observed
checkpoint. It does not establish:
- successful application traffic;
- expected downlink or uplink goodput;
- latency;
- packet loss;
- IMS service;
- bearer stability over a defined interval;
- performance after the diagnostic processes resumed.
If application continuity matters, add an application-level transaction to the test contract. Do not stretch a registration state into an end-to-end service claim.
Rollback did not mean “return to the original PCI”
After the restriction was removed, the live network remained responsible for cell selection.
The UE was therefore not required to return to the identical PCI observed before the test. The correct rollback criterion was:
the restriction is no longer active and the UE can select a valid cell without the test constraint.
This matters in a live radio environment. A rollback can be correct even when mobility, reselection or load conditions lead the UE to another valid cell.
What I would sign off
For the tested stack, I would use this wording:
The requested LTE target state was observed after the controlled refresh, and unrestricted selection was observed after rollback. Registration remained available in the recorded checks.
I would not sign off:
- that the internal modem mechanism is known;
- that either diagnostic process individually caused the earlier variation;
- that the method is portable across modem families;
- that application performance was preserved;
- that a same-state carrier or band check independently proved enforcement;
- that every repetition has a preserved raw trace.
The failed branch has timestamped raw evidence. The positive branch is backed by contemporaneous structured notes, not a raw trace for every repetition. That limitation belongs in the result, not in a hidden audit file.
The five-proof field method
Before accepting a RAN test control, define these five items.
1. Configured state
What exactly was requested, written or retained?
Record the control path, request, response, storage state and refresh action separately.
2. Active state
Which serving-cell, carrier, band, BWP, beam or mobility state must be visible after the action?
Choose an observation point that can actually prove it.
3. Discriminating control
Could the expected observation be different if the control were inactive?
If not, redesign the test before interpreting it.
4. Service guard
What must remain available during and after the state change?
Registration may be enough for one lab objective. A throughput or voice test requires stronger service evidence.
5. Rollback proof
Which observation demonstrates that the restriction has been removed?
Define rollback semantically. “Unrestricted selection restored” is different from “the UE returned to the starting PCI”.
A compact acceptance record
Use this table before writing the conclusion:
| Evidence layer | Required record | Stop condition |
|---|---|---|
| Request | Exact intended state | Request is ambiguous |
| Response | Accepted, rejected or unknown | Function rejected or status unclear |
| Active radio | Time-aligned serving state | Intended state not observed |
| Service | Named service checkpoint | Service condition not measured |
| Rollback | Observable release condition | Restriction may still be active |
| Limitation | Missing evidence and scope | Conclusion exceeds the record |
The report should stop at the first missing proof.
Why this LTE case belongs in a 5G field method
This case is not presented as an NR procedure. The commands and storage mechanism are implementation-specific and intentionally withheld.
The validation problem is broader:
- an RRC configuration does not prove the active BWP at the measurement instant;
- a mobility command does not prove successful target access;
- a scheduler configuration does not prove resource delivery;
- a policy record does not prove the observed user-plane ceiling.
Across LTE and NR, the engineering discipline is the same: connect the requested state to a discriminating active-state observation, then protect the service and prove rollback.
Field stop rule
When the requested state and the active state disagree, stop at that boundary. Do not promote control-path activity into radio proof.
For a case review, bring the request, the matching response, the time-aligned active radio state, the service guard and the rollback observation. That is enough to challenge the conclusion without exposing customer identifiers.
© Takwa Sebai · takwasebai.com · Reuse with attribution
KEEP THE EVIDENCE PATH