Plan the right test
Confirm route, operator, RAT, direction, test case, access, vehicle, people, timing, and the latest customer-approved scope.
Hovah Yii
RAN field playbook
Huawei × MobiFone Vietnam · Hanoi · 2026
Hanoi drive test field guide
An intern-ready operating guide for moving from a tentative plan to a safe field run, complete logs, actionable analysis, and a customer-ready report.
Core tools: PHU · PHU Assistant Lite · OsmAnd · Tracklia
- VIP benchmark routes
- 9
- Operators compared
- 3
- LTE and NR
- 4G + 5G
- Core test scope
- UL · DL · MOS
KMZ route preview
“test path 1” · 14 points
Start: 21.0180095, 105.8296793
End: 21.0161248, 105.8321694
Browse this guide
Authorized project use
This page consolidates a project handover dated 1 September 2026. Group IDs, account IDs, test identifiers, routes, and issue counts are historical operational references. Verify them in WeLink before acting, follow Huawei and MobiFone information-security rules, and never forward logs, customer data, access photos, credentials, or restricted-site details outside approved channels.
01 · Mission and context
What an intern is expected to deliver
A drive test is complete only when the route is covered, the requested test cases are valid, the raw evidence is safe, the team can find it, and the report explains what should happen next.
Collect trustworthy evidence
Maintain GPS lock and continuous logging; capture RSRP, SINR, PCI, throughput, events, BasicInfo, screenshots, and trace IDs where required.
Close the loop
Upload promptly, state incomplete items visibly, request analysis, include root cause and optimization suggestions, and track every dependency to confirmation.
Project scope captured in the handover
Quick technical reference
DTDrive Test
A mobile field measurement along a planned road or indoor route.
CDTContinuous / walk drive test
A moving test that follows a route or floor map while the logger records continuously.
RSRPReference Signal Received Power
A primary LTE/NR coverage-strength KPI.
SINRSignal-to-Interference-plus-Noise Ratio
A quality KPI that helps distinguish weak coverage from interference.
PCIPhysical Cell ID
Identifies the serving or detected cell and helps reveal handover, overlap, and pollution behavior.
IBCIn-building coverage
The indoor coverage layer; compare IBC serving behavior with outdoor macro coverage.
BasicInfoRadio information screen
Capture LTE and NR serving-cell details at the same place and time as a static or speed test.
VUE TraceNetwork-side UE trace
A trace used when deeper analysis is required; record the trace ID and exact test window.
02 · Required tool stack
Know which tool owns each part of the job
PHU collects the field evidence, PHU Assistant Lite checks the logs, and OsmAnd or Tracklia keeps the team on the approved route. A navigation app never replaces the drive-test logger.
Primary field collection
PHU
Use the approved Huawei PHU project and task to run the assigned LTE/NR, FTP, idle, voice, or mobility test and record the radio/GPS log. Watch the task state and recording health throughout collection.
Post-test log verification
PHU Assistant Lite
Open the PHU log after the run to check route continuity, events, radio KPIs, service results, and invalid trials before upload. Preserve the untouched raw copy.
Offline route following
OsmAnd
Correct product spelling; sometimes written “OmsAnd” in team messages.
Import the approved KML/KMZ, download the Hanoi offline map, and use Follow track so the driver can follow the route without depending on mobile data. Never alter the original geometry without approval.
Route inspection and repair
Tracklia
Use Tracklia on Android to inspect GPX/KML/KMZ tracks and waypoints or prepare an approved corrected copy. It manages route data; it is not an RF logger.
PHU and PHU Assistant Lite are project-controlled Huawei tools. Screens, task names, permissions, and menus vary by build; use the current project APK/license/profile and the team’s approved SOP.
03 · Field runbook
One checklist, organized by field phase
Use this single phase-based checklist for benchmark routes, emergency-site tests, walk tests, store tests, and VIP complaint verification.
Before departure
- 1Confirm the latest route, operator × RAT × test-case matrix, direction, deadline, and report owner.
- 2Import the KML/KMZ into OsmAnd or Tracklia; verify start, end, direction, closures, and an alternate path.
- 3Secure restricted-area access, field partner, vehicle, driver, meeting point, and test window.
- 4Charge and label every phone; map each UE to its SIM, operator, RAT, and PHU task.
- 5Open PHU, sync the correct project/task, check GPS, storage, time, license, script, and log-size settings.
- 6Send the tentative plan and state that it may change.
During collection
- 1Run a short proof log, then confirm PHU is recording, GPS is stable, and the correct task is active.
- 2Follow the approved track in OsmAnd/Tracklia while watching PHU for gaps, crashes, heat, or storage errors.
- 3Record every deviation or anomaly with time, location, reason, impact, and retest need.
- 4Capture BasicInfo/screenshots at static points and repeat inconsistent trials two or three times.
- 5The driver drives; the tester operates the phones and logger.
Before close-out
- 1Before leaving, compare the PHU trace and task matrix with the planned route and confirm no log is truncated.
- 2Back up raw logs, then inspect them in PHU Assistant Lite for route continuity, KPI visibility, and valid trials.
- 3Upload to the approved dated folder, share the exact path, and identify incomplete or retest items.
- 4Notify analysis/report owners; include the issue, suspected cause, evidence, next action, owner, and due time.
- 5Recharge and hand over every phone, SIM, cable, power bank, and key.
SIM pre-flight
Correct operator
Enough balance/quota
4G/5G registers
VoLTE/MOS works
Correct phone/slot
Real traffic passes
28 Aug snapshot: two VNPT data + two voice SIMs; two Viettel data + two voice SIMs; MobiFone SIMs available at stores. Reconfirm current inventory.
Handover identifiers
- Log format
- .gen.zip
- DT phone reference
- 841212953022
- Recorded VUE trace
- 977718
Stop and escalate when validity or safety is at risk
Wrong SIM/task, no GPS, broken PHU logging, unknown RAT lock, expired access, unsafe traffic, missing permission, or an unapproved route change are stop conditions.
04 · Execution recipes
Benchmark, emergency-site, and field test recipes
Definitions and operating steps for FTP/MOS operator comparison, Yanyang’s emergency-site protocol, CQT, real-5G verification, and indoor spatial dotting.
What is a benchmark test?
A benchmark drive test is a controlled, route-by-route comparison of competing mobile networks. For this project, the same planned route and equivalent test conditions are used to compare MobiFone, Viettel, and VNPT/Vinaphone. The goal is to show relative coverage, data performance, stability, and voice quality—not merely to prove that one phone has service.
MobiFone
Project/customer network
Viettel
Benchmark competitor
VNPT / Vinaphone
Benchmark competitor
| Test case | What it does | What to compare | Completion evidence |
|---|---|---|---|
| FTP DL | Transfers data from the test server to the UE. | Downlink throughput, stability, radio coverage/quality, and failures. | Accepted PHU log for each required operator, RAT, and route. |
| FTP UL | Transfers data from the UE to the test server. | Uplink throughput, stability, radio coverage/quality, and failures. | Accepted PHU log for each required operator, RAT, and route. |
| MOS | Runs the planned VoLTE voice call and scores perceived speech quality. | MOC/MTC accessibility, retainability, two-way audio, and UL/DL MOS. | Accepted paired call logs with populated MOS results for each required operator and route. |
Keep the route, direction, planned time window, test duration/file/server, and RAT configuration as equivalent as practical.
Label every phone and map the correct MobiFone, Viettel, or VNPT SIM to the correct PHU task before recording.
Keep each operator result separate. Record detours, congestion, device differences, invalid trials, and other conditions that affect fairness.
Compare accepted trials only; never use a truncated log, missing MOS value, wrong operator/RAT, or unrecorded deviation as a valid result.
Emergency-site test
This is an urgent validation of the assigned site or service condition, not a three-operator benchmark. Luo Yanyang’s current prepared protocol is the controlling document for the scope, sequence, thresholds, route/points, and deliverables.
- 1Get the current protocol directly from Yanyang or the assigned task owner. Confirm its version, site ID/name, location, deadline, and whether the site is new, restored, temporary, or under incident investigation.
- 2Confirm the on-air status, permitted test area, access contact, safety restrictions, baseline/post-change condition, and exact cells, bands, RATs, points, or route required by the protocol.
- 3Prepare only the required phones, SIMs, PHU tasks, locks, KML/floor plan, call pair, server/profile, and screenshots. Run a short proof test before travel or before entering the site.
- 4At the site, synchronize time and record the starting condition. Capture PHU BasicInfo and run idle, FTP, voice, speed, or handover cases only in the order and duration specified by the protocol.
- 5Record site/cell identity, LTE PCI/EARFCN, NR PCI/NR-ARFCN, radio KPIs, test result, exact time/location, abnormalities, access limits, and any deviation approved by the task owner.
- 6Validate the trace in PHU Assistant Lite, preserve the raw logs, upload to the instructed path, and report pass, fail, or inconclusive against the protocol. Notify Yanyang of missing scope or urgent failures.
CQT call cycle: MOC, MTC, and MOS
A CQT voice test needs both call directions and a working audio path. “Call connected” is not enough when the task also requires speech quality.
MOC · Mobile Originated Call
The test UE starts the call to the configured called number. Verify attempt, setup, alerting, connection, speech period, MOS result, and normal release.
MTC · Mobile Terminated Call
The test UE receives the call. Verify paging/ringing, answer or auto-answer, two-way audio, call retainability, MOS result, and release.
Bluetooth MOS connection
- 1.Identify the approved Bluetooth MOS headset/audio accessory for each MOC and MTC phone; do not swap labels between UEs.
- 2.Enable Bluetooth on the phone, place the MOS accessory in pairing mode, select its device name, and complete the PIN/confirmation prompt.
- 3.In the paired-device settings, enable Calls or Phone audio. Disconnect old headsets, watches, or car audio that may take the call audio route.
- 4.Place one short manual call. Confirm ringing, answer, microphone, and speech in both directions; verify the call screen shows Bluetooth audio.
- 5.Keep the project-defined volume/gain unchanged, disable mute, keep the microphone unobstructed, and prevent the accessory from sleeping.
- 6.Open the matching PHU MOS tasks only after both Bluetooth links are stable. If either device reconnects, repeat the audio proof call.
Run the paired PHU tasks
- 1.Confirm both SIMs have call credit, correct phone numbers, LTE service, IMS/VoLTE registration, and normal manual calling.
- 2.Assign one phone as MOC and the other as MTC. Check that the MOC called number matches the MTC SIM and that MTC answer/auto-answer follows the project script.
- 3.Start log recording on both phones. Arm the MTC side so it is ready, then start the MOC dialing task; follow the current PHU task order if it differs.
- 4.Watch for call attempt → alerting → connected → speech sample/MOS → normal release. Record setup failure, no answer, drop, one-way audio, or missing MOS as separate failures.
- 5.Verify both uplink and downlink MOS results are populated. A connected call with blank MOS is an incomplete MOS trial.
- 6.Repeat the required cycles and reverse MOC/MTC roles only when the test plan requires both directions. Keep the failed attempts in the evidence set.
PHU: verify whether 5G is actually connected
LTE PCI and EARFCN identify the LTE serving/anchor cell. They do not, by themselves, prove that the UE has an active NR connection.
| PHU readout | Interpretation | Action |
|---|---|---|
| LTE PCI + LTE EARFCN only | LTE serving cell or NSA anchor is visible; NR is not yet proven. | Start active traffic and check the NR/SCG fields. |
| LTE anchor + EN-DC/SCG connected + NR PCI + NR-ARFCN | 5G NSA is active. | Capture LTE and NR radio KPIs during FTP/Speedtest. |
| Serving RAT = NR/5G SA + NR PCI + NR-ARFCN | 5G SA is active. | Capture NR serving-cell and registration details. |
| 5G icon, but no NR PCI/NR-ARFCN/NR measurements | “False 5G” or NR not active at that moment. | Do not report 5G as verified; generate traffic and retest. |
- 1.Open PHU BasicInfo/Parameter view and record RAT, LTE PCI, EARFCN, band, RSRP, RSRQ, and SINR.
- 2.Compare the LTE PCI/EARFCN with the latest engineering parameters to confirm the expected anchor/serving cell.
- 3.Start FTP DL/UL or Ookla traffic because NSA NR may be added only when data demand begins.
- 4.Look for EN-DC/SCG/NR serving status plus NR PCI, NR-ARFCN, NR RSRP/RSRQ/SINR, and NR throughput contribution.
- 5.Take one BasicInfo screenshot before traffic and one while traffic is active; include time and indoor/outdoor position.
- 6.If LTE fields change unexpectedly or NR disappears, annotate the location and time for handover/cross-coverage analysis.
Channel naming: EARFCN is the LTE channel number. The 5G channel is NR-ARFCN. Record both for NSA; record NR-ARFCN and NR PCI for SA.
Indoor spatial dotting · manual dot trace
GPS is unreliable indoors. Spatial dotting anchors the PHU samples to the floor plan so Assistant Lite can replay the walk in the correct location.
1
Load the correct floor plan
Verify building, floor, orientation, scale, public/restricted boundary, and planned start/end points.
2
Select indoor/manual dotting
Use the project indoor map and begin one log for one floor and one clearly named test case.
3
Place the first dot
Stand at a recognizable landmark, tap the exact position on the floor plan, then start moving.
4
Dot every geometry change
Tap at every corner, corridor junction, entrance, escalator/elevator, direction change, and route deviation.
5
Walk steadily between dots
PHU distributes/interpolates samples along the segment; irregular speed or late dots distort the plotted location.
6
Handle pauses correctly
Add a dot at the actual pause/static test point and annotate the reason; do not let stationary samples appear along a moving segment.
7
Separate floors
Stop or segment the log before changing floors, load the next floor plan, and restart dotting from a confirmed landmark.
8
Verify before leaving
Replay the floor trace in PHU Assistant Lite and check that lines do not cut through walls, jump floors, or miss tested areas.
Indoor/outdoor 5G store test
Run the project-required 5G Speedtest at both positions, prove NR in PHU during active traffic, capture BasicInfo, speed, latency, server, time, and compare conditions before escalating an indoor gap.
Minimum evidence package
Spatial
KML/floor map, trace, direction, start/end time, deviations, public/restricted coverage.
Radio and service
Operator, RAT, band/lock, RSRP, SINR, PCI, throughput, latency, drops, MOS, BasicInfo.
Traceability
UE/SIM mapping, test-case name, raw log, screenshot, VUE trace ID, event notes, valid-trial marker.
05 · Benchmark control
Nine-route benchmark matrix
All nine routes remain incomplete: no MOS test was completed on routes 1–9. The recorded FTP work is shown below, but an FTP result alone does not close a route.
Completion rule: mark a route complete only after every required FTP UL/DL and MOS combination has an accepted log. Route 9 is incomplete, and Route 8 also has an outstanding FTP DL retest.
| Route | Description | Overall status | Operational note |
|---|---|---|---|
| 1 | MobiFone Office → Government Office | Incomplete | FTP UL/DL recorded; MOS was not tested. |
| 2 | MobiFone Office → MPS Branch Office | Incomplete | FTP benchmark recorded; MOS was not tested. |
| 3 | MobiFone Office → MPS HQ | Incomplete | MOS was not tested. The handover also describes Route 3 as going to Government Office, so verify the latest route master. |
| 4 | MPS Branch Office → MPS HQ | Incomplete | FTP benchmark recorded; MOS was not tested. |
| 5 | MPS Branch Office → Government Office | Incomplete | FTP benchmark recorded; MOS was not tested. |
| 6 | MobiFone Office → Northern MobiFone Network Center | Incomplete | Separate FTP DL and UL runs were recorded; MOS was not tested. |
| 7 | MPS HQ → Government Office | Incomplete | Separate FTP DL and UL runs were recorded; MOS was not tested. |
| 8 | MPS HQ → Vinhomes Riverside | Incomplete | FTP DL still requires retest and MOS was not tested. |
| 9 | MPS HQ → National Data Center | Incomplete | MOS was not tested, so this route is not complete. It is the longest route at about 2.5 hours; confirm the remaining scope and consider splitting the run. |
06 · August 2026 lessons
Real cases and what they teach
Use these examples to recognize common failure patterns: false 5G, macro cross-coverage, interference, access constraints, incomplete reporting, and missing resource follow-up.
16 Aug
Noi Bai Airport T2 · Shop 1 / Shop 2 uplink
Shop 1 improved after optimization. Shop 2 remained below the >10 Mbps UL target. A nearby VNPT antenna was about 12–15 m horizontally from the referenced building floor; the team requested interference and load checks.
Intern takeaway
Do multiple static trials, preserve comparison points, and do not call the problem solved when one location improves.
13 & 19 Aug
MobiFone store · 21B Ba La
Indoor 5G was poor or absent while outdoor service was normal. One screenshot showed a 5G icon without a real NR connection.
Intern takeaway
Verify serving NR in BasicInfo. An icon is not proof of a 5G bearer. Compare indoor and outdoor under the same evidence package.
20 Aug
MobiFone store · 16 Dien Bien Phu
Indoor and outdoor 5G Speedtest plus FTP DL were collected at 21.0298, 105.8422 and combined with Ba La into one report.
Intern takeaway
Keep location identity and indoor/outdoor context clear when several stores share one deliverable.
25 Aug
Noi Bai Airport T1 · post-optimization walk test
Public areas on floors 1–3 were tested with 4G and 5G FTP DL. IBC improved, but some areas still handed over to macro. Restricted access had expired; Floor 3 public-area shape differed from the PPTX. 3G was not tested.
Intern takeaway
Report actual access and route coverage, state untested layers, and reconcile map mismatches before interpreting coverage.
26 Aug
VIP Cluster 21 · Riverside complaint
Immediate DT required a local MobiFone staff member because interns could not enter the VIP area.
Intern takeaway
Access is a test dependency. Coordinate through Phan Tuan Anh and never attempt unapproved entry.
27–28 Aug
VIP residential complaint report
The report showed poor 4G/5G coverage but initially lacked analysis and optimization suggestions. The suspected root cause was severe cross-coverage; post-DT optimization was pending and relocation/transmission work was needed first.
Intern takeaway
A customer report needs cause, evidence, proposed action, dependency, owner, and next verification—not screenshots alone.
07 · Communication and reporting
Make the result easy to scan and act on
The source notes use a fixed six-block email structure, an operator-by-RAT status table, explicit failure colors, and a report template aligned before customer output.
1
Greeting + overview
State whether this is a plan, result, or update. For plans: “This is just a plan (tentative) and may change.”
2
Change / precondition
Explain route, timing, access, SIM, vehicle, or scope changes before the table.
3
Test-plan/result table
Use No. · Route · Operator · RAT · Test case · Status · Remarks. Expand every route by operator and LTE/NR.
4
Reference images
Attach or CID-inline route maps, floor plans, BasicInfo, and screenshots with clear captions.
5
Vehicle / people / time
List driver, testers, field partner, start/end time, and access contact when relevant.
6
Notice + action + signature
State the one core request, owner, deadline, disclaimer, and fixed signature.
Result email pattern
Lead with the conclusion, then show the matrix
Subject: VIP 9 Road Benchmark Drive Test Result (29–31 Aug) – Viettel / MobiFone / Vinaphone
Opening: Please find below the benchmark drive test result for VIP 9 Road conducted from 29 to 31 Aug 2026, covering three operators: Viettel, MobiFone and Vinaphone.
Complete
Green ✓
Green ✓
Not tested
Red ✗
Red ✗
Incomplete
Reason in remarks
Reason in remarks
Action wording: Route 8 FTP DL could not be completed because the Viettel 4G and VNPT 4G SIM cards had insufficient balance. New SIM cards have been requested; arrange the retest when availability is confirmed.
Rule: The table carries the complete facts. The body carries the conclusion, risk, and one actionable request.
Report templates
- Primary: Standard Template for VIP T1 Assurance_20260810 V1.pptx
- Statistics reference: MBF RF Performance_20260808.pptx
- Both front-line and GSC teams produce reports. Confirm the latest version before editing.
- Customer output must include poor-area analysis and optimization suggestions.
Pre-send gate
- Correct subject and recipients
- Latest route and report template
- Status colors match facts
- Failure reason in remarks
- Analysis and optimization
- Owner and follow-up date
- Images render in Outlook
- Fixed signature and disclaimer
08 · Operational directory
Where work lives and who closes it
Use role-based escalation first, then confirm the current person and account in WeLink. Never assume a historical contact still owns the task.
DT Management
936714420879622473
Main coordination group for all drive-test activity.
10/08–16/08 Drive Test Record
997212977222389807
Noi Bai Airport T2 shop testing.
Hanoi Airport DT Assurance
994063112594419792
Airport T1 assurance and MobiFone store testing.
Approved log path
Group Space > DT Management > North > Benchmark DT Log > [date] > [location]Open the handover Onebox location | Name | Account | Role | Use this contact for |
|---|---|---|---|
| Miao Peiqian | m00907087 | RF Delivery Leader | Direct leader for DT tasks; interference, load, and RF follow-up. |
| Ouyang Changjun | o60125604 | Delivery Leader | Overall delivery, VIP complaints, MobiFone coordination, and SIM purchase arrangement. |
| Hoang Minh Thao | h00708566 | Local MobiFone RF | Approves DT plans and reviews reports before customer delivery. |
| Phan Tuan Anh | p60120025 | Local engineer | Coordinates MobiFone/VIP access and tracks cross-feeder updates. |
| Su Xiaobo | s00921749 | GSC engineer | Performs log analysis and report writing. |
| Nguyen Ha Phan | n50066043 | Local engineer | Field-testing partner. |
| Phan Truong Khang | p50065883 | Local engineer | Field-testing partner. |
| Luo Yanyang | l00947656 | RF engineer | VIP complaint testing, Riverside DT support, and the project protocol to follow for emergency-site tests. |
Open issue register · 27–28 Aug snapshot
ITC cross-feeder
64 issued · 40 resolved · historical counts do not fully reconcile; confirm current tracker.
MobiFone-S cross-feeder
75 issued · 66 resolved.
ITC hardware
93 issued · 36 resolved.
MobiFone-S hardware
51 issued · 27 resolved.
The handover totals 104 pending items. Phan Tuan Anh supplied ongoing updates.
Outstanding handover actions
CQT report retest
Installation-quality issues require a retest.
VIP residential analysis
Add optimization suggestions and address relocation/transmission dependencies.
Shop 2 uplink
Interference and load check requested; target was >10 Mbps.
Fast escalation map
VIP access
Phan Tuan Anh · send access documents only through approved channels.
Site on-air check
Nguyen Trong Giap · 00079600; also check [War Room] MBF 5G project – Ha Noi cutover.
More SIMs
Ouyang Changjun coordinates with Dang Hong Quan / Thai Huu Tuan Ha.
Interference / load
Miao Peiqian for RF checks; Su Xiaobo for log analysis.
09 · Original handover files
Download the working references
Use the live team workspace as the operational source of truth. These files are the dated references used to build this guide.
MarkdownDT handover documentDetailed August 2026 project history, groups, contacts, methods, storage, equipment, and open items.ExcelDrive test checklistThe before, during, and after field checklist in an editable workbook.WordVIP 9 road field notesChinese-language benchmark retrospective covering routes, SIM failures, email structure, MOS/CQT, and follow-up actions.KMZTest routeThe original KMZ route named “test path 1,” containing 14 coordinate points.
Before you leave for the field
If the route, SIM, access, logger, and owner are not confirmed, the test is not ready.
Scope confirmedSIM provenAccess approvedRoute openedLogger validatedUpload owner named