The Optimization Method — Loop, Verify, Prove

Optimization is not a guess — it is a loop run one variable at a time. This page is the operating method behind every deep-dive in this course: the Samsung single-variable trial loop (animated below), the answer-verification loop, the five KPI families with their counter Family IDs, the Samsung conventions you must speak (kebab-case parameters with MO path, FGR features, counter Family IDs), and a live self-audit checklist. Ground every change in a Samsung reference doc; prove every result on the counters; roll back if it degrades.

7Loop steps · 1 variable

48hSoak before verdict

5KPI families

FGR · Famthe Samsung language

7-boxself-audit gate

The Samsung optimization loop — single variable, always animated

Every optimization runs this cycle. One variable per turn — never stack changes. The highlight auto-rotates through the steps; hover to pause, click a step for the Samsung specifics. The last step is a fork: roll forward if the counters improved, roll back if they degraded — then back to Analyse.

SAMSUNGOptimization
Loop— rotating —

7 steps · one variable each · 48h soak · verify on Family IDs · roll back if degraded

The answer-verification loop — how every recommendation is checked

Before any recommendation leaves the room it passes this five-step verification — the discipline that keeps the answer Samsung-exact, doc-grounded and honest. The active step cycles; the loop returns to the start if the self-audit fails.

Never skip step 4. The self-audit (checklist further down) is the gate: if any box fails — a parameter in the wrong style, a feature without its FGR code, a KPI without its Family ID, a value not marked typical-vs-recommended, a missing rollback — the draft is fixed and re-run. Only a clean audit ships.

Classify first — the five KPI families & their counter Family IDs

Every question lands in one (or more) of five families. Classification decides which counters you pull and which levers apply. Accessibility Family IDs are exact (Samsung eNB/gNB Counter Description); other families' specific IDs are release-dependent and marked Need verification per the method's own tagging rule.

KPI families → what they measure → counter Family IDs

Family	Measures	Counter Family IDs	Primary levers
Accessibility	Can the UE get on?	`5213` RRC Est · `5214` Setup Time · `5217` Resume · `5203` Re-estab · `5223/5224` Init Ctx · `5136/5137` F1 · `5118/5218/5219/5222/5438` bearer · `5243` RACH · `5147/5148` CAC Certain	RACH/RRC timers · CAC · FGR-CC3102/0301-0303
Retainability	Does it stay up?	Call-drop & RLF families Need verification — confirm in the SVR25A/B Counter Description	`t310/t311/n310/n311` · preemption · FGR-BC1202 (SCG)
Mobility	Does handover work?	HO prep/exec families Need verification — per RAT (intra/X2/S1/Xn)	A3/A5 offsets · TTT · hysteresis · ANR
Integrity	Is the service good?	BLER · latency · MOS families Need verification	HARQ/RLC/PDCP · DRX · link adaptation
Throughput	How fast?	PRB · MCS · RI · CQI families Need verification	scheduler · CA/DSS · 256QAM · MU-MIMO

Speak Samsung — the conventions every answer must use

parameterkebab-case + MO path

Stylemanaged-element/gnb-du-function/gutran-du-cell/t300

Examplespreamble-trans-max, power-ramping-step, ra-contention-resolution-timer, msg1-fdm, ssb-per-rach-occasion

Never3GPP IE names, Ericsson MOM, Nokia LNCEL/NRCELL, Huawei MML

featureFGR / LTE-SW code

NRFGR-CC3102 access · CC0301/0302/0303 CAC · CC0102 re-estab · CC0103/0107/0108 Inactive · RS0121/0122 RACH · LC0303/0401 overload · CC6101 multi-PLMN

LTELTE-SW5001/5002 MOCN · SW4101-4106 CAC · SW0503 MME overload

counterFamily ID

StyleEvery KPI carries its Family ID — 5213, 5223, 5243…

SourceSamsung eNB / gNB (CU-CP/DU) Counter Description, per SVR release

tools · releases · HWthe environment

ToolsLSM · CognitiV SON/Analytics · Smart SON · Trial Tracker

ReleasesvRAN 3.0 · SVR25A / SVR25B · FSR 5.4.0 (femto)

HWMMU · RRU · CDU · CU-CP/CU-UP/DU · CB1000 · LTM · FRMM · femto

Answer formats — pick the shape for the question (click a card)

The self-audit checklist — the gate before any answer ships

Run this on every draft. Tick each box; a clean sheet is the only thing that ships. Try it — click the items to check them and watch the audit score.

Pre-response self-audit0 / 7

≡

Confidence tags — every claim ships with one: Certain (from a project doc or 3GPP standard behaviour) · Likely (strong Samsung-consistent reasoning) · Assumption (gap-filling, with the reason) · Need verification (Samsung-proprietary, unconfirmed by any doc — name the doc that would confirm it).

Ground it, tune one thing, soak, verify, prove.

The method is the product: classify into a KPI family, ground in a Samsung doc, change one kebab-case parameter, trial it, soak 48h, verify on the Family IDs, roll back if it degrades. Apply it on any KPI deep-dive.

Accessibility KPIs ›Feature catalog ›

Method & conventions per the Samsung RAN Optimization operating standard used throughout this course. Accessibility counter Family IDs are verbatim from the Samsung eNB / 5G NR Counter Descriptions; other families are marked for release-specific verification. Parameter MO paths follow the Samsung DU / CU-ACPF Parameter Descriptions (SVR22B/SVR25A). Features are Samsung FGR / LTE-SW codes. Every proprietary value should be confirmed against the applicable Samsung Recommended Configuration for your SVR release before deployment.