Vendor ticket escalation: building a structured field evidence pack

A vendor ticket is only as good as the evidence attached to it. In telecom network operations, the gap between “I reported the issue” and “the vendor actually reproduced and fixed it” is almost always an evidence gap. Incomplete, unstructured, or ambiguous field data leads to ticket ping-pong, delayed resolution, and frustrated engineering teams on both sides.

This guide presents a systematic approach to building field evidence packs that vendors can actually act on — structured, complete, and exportable in machine-readable formats.

Why most vendor tickets fail on first submission

Before diving into the solution, it is worth understanding why the current process fails so consistently. Based on common patterns across operator field teams:

The top 5 evidence failures

#	Failure Mode	Consequence	Frequency
1	Screenshots instead of structured data	Vendor cannot filter, search, or programmatically analyze	Very common
2	Missing UE capabilities	Vendor cannot determine if the device supports the expected feature	Common
3	No radio context	Issue reported without PCI, frequency, RSRP, SINR at time of failure	Common
4	Timestamp mismatch	Field logs and network traces cannot be correlated	Frequent
5	Partial capture	Only the symptom is captured, not the preceding events (setup, handover)	Frequent

Each of these failures triggers a vendor response of “please provide additional information” — which costs days or weeks of round-trip time.

The cost of ticket ping-pong

Consider the timeline of a typical under-documented ticket:

1. Day 0: Field engineer reports issue with screenshot and text description
2. Day 2: Vendor L1 support requests UE capabilities and radio context
3. Day 5: Field engineer re-visits site, captures partial additional data
4. Day 8: Vendor L2 escalation requests Layer 3 traces with RRC/NAS messages
5. Day 12: Field engineer captures Layer 3 but in a format the vendor cannot parse
6. Day 15: Vendor requests raw QMDL or structured export
7. Day 20: Issue finally reaches the right engineering team with usable data

A complete evidence pack submitted on Day 0 could have resolved this in 5 days instead of 20. The engineering effort is the same — the difference is organization and completeness.

Anatomy of a complete field evidence pack

A complete evidence pack answers every question a vendor engineer will ask when investigating the ticket. The structure below covers the essential components.

1. UE capabilities (RRC and NAS)

The device capabilities define what the network can configure. Without this information, the vendor cannot determine whether the observed behavior is a device limitation or a network issue.

RRC UE Capability Information (3GPP TS 38.331 / TS 36.331):

• UE Category — determines maximum throughput class
• Supported bands — which frequency bands the UE supports
• CA combinations — which Carrier Aggregation combinations are supported (bandCombinationList)
• MIMO layers — maximum supported MIMO layers per band
• Feature groups — supported optional features (e.g., 256QAM DL/UL, SUL, EN-DC)

NAS UE Capability (TS 24.501 / TS 24.301):

• 5GMM capability — 5G NAS features
• UE network capability — EPS security algorithms, emergency bearer support
• UE security capability — supported integrity and ciphering algorithms
• Voice domain preference — IMS voice, CS fallback, VoNR support

Why this matters: A vendor investigating a throughput issue needs to know whether the UE supports the CA combination and MIMO configuration deployed on the cell. A vendor investigating a VoLTE failure needs to confirm IMS voice support in the NAS capability. Without these messages decoded and included, the ticket is incomplete.

2. MRDC and EN-DC combination support

For 5G NSA (Non-Standalone) issues, the evidence pack must include the UE’s Multi-RAT Dual Connectivity (MRDC) capabilities:

• Supported EN-DC band combinations — which LTE + NR combinations the UE supports
• Maximum aggregated bandwidth — per combination
• Power class — UE power class per band (PC2 vs PC3)
• Feature set combinations — which DL/UL feature sets apply per band combination

This data comes from UE-MRDC-Capability in RRC. It is essential for any ticket involving:

• 5G not activating (SCG addition failure)
• Lower-than-expected 5G throughput
• Frequent 5G dropouts (SCG failure)
• Missing carrier aggregation components

3. Radio context at time of failure

Every evidence pack must include the complete radio context at the exact moment the issue occurred:

Parameter	Source	Purpose
Serving PCI	L1 measurement	Identifies the exact cell
EARFCN / NR-ARFCN	L1 measurement	Identifies the exact frequency
Band	Derived from ARFCN	Confirms frequency band
RSRP	L1 measurement	Signal power at UE
RSRQ	L1 measurement	Signal quality indicator
SINR	L1 measurement	Interference + noise context
TA (Timing Advance)	L1 measurement	Distance from cell site
MCS DL/UL	L1 measurement	Channel quality perception by scheduler
BLER DL/UL	L1 measurement	Error rate indicating quality
Rank Indicator	L1 measurement	Active MIMO rank
CA state	L1/RRC	Active carrier aggregation components

Timestamp precision: All measurements must use the same time reference (UTC preferred) with sub-second precision. The vendor will correlate field evidence with network-side traces (OSS counters, eNB/gNB logs), and timestamp alignment is critical.

4. Layer 3 protocol messages

The Layer 3 message sequence provides the protocol-level narrative of the issue. Essential messages to capture:

For RRC-level issues:

• RRCSetup / RRCSetupComplete — initial connection
• RRCReconfiguration — bearer setup, CA activation, handover commands
• RRCReconfigurationComplete — UE confirmation of reconfiguration
• MeasurementReport — what the UE measured and reported to the network
• RRCRelease — connection release (with cause if abnormal)
• RRCReestablishmentRequest — radio link failure recovery attempt

For NAS-level issues:

• RegistrationRequest / RegistrationAccept — 5G registration
• AttachRequest / AttachAccept — LTE attach
• PDU Session Establishment — data bearer setup
• Service Request — transition from idle to connected
• Deregistration — UE or network-initiated detach

For IMS/VoLTE issues:

• SIP REGISTER / 200 OK — IMS registration
• SIP INVITE / 100 Trying / 180 Ringing / 200 OK — call setup
• SIP BYE — call termination
• SDP negotiation — codec and media parameters

5. Event timeline

The evidence pack must include a chronological event timeline that connects the measured KPIs with the protocol messages:

[T+0.000s] Serving cell: PCI 124, EARFCN 1300, RSRP -82 dBm, SINR 18 dB
[T+0.500s] RRCReconfiguration received (adding NR SCG, PCI 501, SSB 3)
[T+0.800s] RRCReconfigurationComplete sent
[T+1.200s] NR SCG activated: NR-ARFCN 627264, RSRP -91 dBm, SINR 8 dB
[T+3.500s] NR RSRP degrades to -108 dBm, SINR drops to -2 dB
[T+4.000s] SCG Failure Information sent (cause: t310-Expiry)
[T+4.200s] NR SCG released, fallback to LTE only

This timeline tells the vendor exactly what happened, when, and in what sequence — eliminating ambiguity.

Common mistakes and how to avoid them

Mistake 1: Sending screenshots of a measurement app

Problem: Screenshots are not searchable, filterable, or parseable. A vendor engineer receiving 15 screenshots must manually read each one and transcribe values into their analysis tool.

Solution: Export structured data in machine-readable formats: PCAP, CSV, or the vendor’s preferred format (many accept QMDL). HiCellTek exports all captured data — L1 measurements, Layer 3 messages, and event timelines — in structured formats with a single tap.

Mistake 2: Omitting UE capabilities

Problem: The field engineer assumes the vendor knows what device is being used. But the same device model can have different modem firmware versions, different CA capability lists, and different feature support depending on region and carrier customization.

Solution: Always capture and include the actual UECapabilityInformation and UE-MRDC-Capability messages as decoded by the modem. These messages reflect the real capability of the specific device in its current configuration — not what a spec sheet says.

Mistake 3: Capturing only the failure moment

Problem: A dropped call evidence pack that starts at the moment of drop is missing the 30-60 seconds of context leading up to it. Was there a handover? Was SINR degrading? Was the UE at cell edge?

Solution: Configure continuous logging and extract a window of data centered on the failure event. A good rule of thumb: include 60 seconds before the failure and 30 seconds after (to capture recovery behavior).

Mistake 4: Inconsistent timestamps

Problem: The field log uses local device time, the network trace uses UTC, and the OSS counters use the operator’s NMS time. Correlating events across these sources becomes impossible.

Solution: Synchronize the measurement device to NTP/GPS time before the test. HiCellTek uses GPS-derived timestamps for all logged events, ensuring alignment with network-side traces.

Mistake 5: No reproducibility information

Problem: The vendor asks “can you reproduce this?” but the evidence pack does not include location, time, route, or conditions.

Solution: Include GPS coordinates (or indoor floor plan position), date and time, weather conditions (relevant for mmWave), and a description of the test methodology. If the issue is reproducible on a specific route, include the route coordinates.

Building the evidence pack with HiCellTek

HiCellTek is designed to produce vendor-ready evidence packs as a standard output of any field measurement session. The workflow is:

During the field test

1. Start a measurement session — HiCellTek automatically captures L1 KPIs, Layer 3 messages, and UE capabilities from the Qualcomm diagnostic interface
2. Mark events — when an issue occurs, the engineer taps a marker button to flag the timestamp. This creates an event bookmark in the continuous log.
3. Continuous logging — all data is recorded to the device storage with GPS timestamps

After the field test

4. Select the event window — choose the time range around the marked event (e.g., 60 seconds before, 30 seconds after)

5. Export the evidence pack — HiCellTek generates a structured export containing:

   • Decoded UE capabilities (RRC + NAS)
   • MRDC/EN-DC capability information
   • Radio context (RSRP, RSRQ, SINR, PCI, ARFCN, TA, MCS, BLER, RI)
   • Layer 3 message sequence (decoded and timestamped)
   • Event timeline with correlated KPIs
   • GPS location data

6. Choose export format:

   • JSON — structured, machine-readable, ideal for automated analysis
   • CSV — tabular, importable into spreadsheets and BI tools
   • HLOG — proprietary encrypted format for full replay in the desktop companion
   • QMDL — raw diagnostic log compatible with standard vendor tools
   • TXT — human-readable decoded output for email attachment

Attaching to the vendor ticket

The exported evidence pack can be attached directly to the vendor ticketing system (JIRA, ServiceNow, Remedy, or email). Because the data is structured and complete, the vendor can begin analysis immediately without requesting additional information.

Evidence pack checklist

Use this checklist before submitting any vendor ticket:

• UE Capabilities — RRC UECapabilityInformation decoded and included
• MRDC Capabilities — UE-MRDC-Capability included (for 5G NSA issues)
• Radio context — PCI, ARFCN, RSRP, RSRQ, SINR, TA, MCS, BLER at time of failure
• Layer 3 messages — full RRC/NAS message sequence for the event window
• Event timeline — chronological narrative with timestamps
• Timestamps synchronized — UTC or GPS-derived, sub-second precision
• Pre-event context — at least 60 seconds of data before the failure
• Location data — GPS coordinates or indoor floor plan position
• Structured format — PCAP, CSV, or QMDL (not screenshots)
• Issue description — clear statement of expected vs observed behavior

From evidence to resolution

A complete evidence pack transforms the vendor interaction:

• No ping-pong — the vendor has everything needed on first submission
• Faster escalation — L1 support can immediately escalate to L2/L3 with complete context
• Reproducibility — the vendor can attempt to reproduce using the exact radio conditions
• Root cause identification — the protocol sequence reveals whether the issue is UE-side, network-side, or a specification interpretation difference

For detailed guidance on drive test methodology that produces clean evidence data, see our LTE and 5G drive test methodology guide. For understanding the 5G NR KPIs that form the radio context, refer to our 5G NR optimization RF engineer guide. The Android drive test tool page covers the full field evidence workflow on a single Android device.

Conclusion

Building a structured field evidence pack is a discipline, not an afterthought. The investment of 5 additional minutes during a field test — to properly mark events, verify completeness, and export in a structured format — saves weeks of ticket escalation time and significantly improves resolution rates.

HiCellTek automates the most labor-intensive parts of this process: UE capability extraction, Layer 3 decoding, radio context logging, and structured export are all integrated into a single measurement workflow on a standard Android smartphone. The result is a vendor-ready evidence pack produced in one tap, not assembled manually from multiple tools.

Ready to streamline your vendor escalation process? Contact us at sales@hicelltek.com or visit hicelltek.com to see how HiCellTek transforms field evidence collection.