Nokia Services Architecture common mistakes
Nokia Services Architecture · Understand the traps and how to avoid them.
Treating GPON and XGS-PON as interchangeable during capacity and split-ratio questions, ignoring that XGS-PON carries 10G downstream/2.5G or 10G upstream while GPON is 2.5G/1.25G, and that coexistence on the same ODN depends on wavelength and power-budget planning.
Candidates memorize headline line rates but never connect them to split-ratio limits, reach, and the coexistence filters/prisms needed when GPON and XGS-PON share fiber; marketing shorthand ('10G PON') blurs the standards.
What to do instead
Build a one-page table of GPON, XGS-PON, and 25G/50G PON variants with downstream/upstream rates, split ratios, typical reach, and coexistence method. For each practice question, state the access technology and split ratio before computing bandwidth per subscriber.
Answering 5G RAN architecture questions by assuming all gNB functions are co-located, instead of splitting CU (RRC/SDAP/PDCP) and DU (RLC/MAC/PHY-high) and placing them correctly relative to F1, E1, and the fronthaul/midhaul boundary.
Legacy LTE thinking (eNB as one node) dominates; the CU/DU split and its transport implications are recent and easy to skip in study.
What to do instead
Draw the gNB split from memory: RU to DU over fronthaul (eCPRI), DU to CU over F1 (midhaul), CU to core over backhaul; mark E1 between CU-CP and CU-UP. Then explain how split choice changes latency and transport requirements.
Describing 5G core as '4G core plus slicing' and missing that the SBA replaces point-to-point interfaces with HTTP/2-based service APIs (Nnrf, Namf, Nsmf), and that SMF handles session management while UPF handles user-plane forwarding.
Candidates study from high-level diagrams that show boxes but not interfaces; the service-based architecture's API model and the CP/UP separation are abstract.
What to do instead
List the key NFs (AMF, SMF, UPF, AUSF, UDM, NRF, NSSF, PCF) with one-line roles and the services they expose. Practice tracing a PDU session setup as a sequence of service calls, not as interface names.
Choosing a transport technology by raw capacity alone, ignoring latency, jitter, synchronization, and protection requirements that differ for fronthaul, midhaul, and backhaul.
Capacity numbers are easy to compare; timing and protection constraints are subtle and often omitted from summaries.
What to do instead
For each transport scenario, write the requirement set first (bandwidth, one-way latency, jitter, sync class, protection target), then eliminate options that fail any single requirement before comparing the rest.
Treating network security as a list of appliances rather than a layered model, so candidates cannot say which control (segmentation, encryption in transit, identity, DDoS scrubbing) addresses a given threat in a given domain.
Security appears across all domains and is often revised by memorizing product names instead of threat-to-control mapping.
What to do instead
Practice a threat-model table: threat, affected domain, preventive control, detective control. For each answer, justify why the chosen control fits the threat's layer and attack path.
Equating 'autonomous networks' with full automation and skipping the levels framework, closed-loop concept, and the role of intent, telemetry, and assurance in moving between levels.
The topic is new and terminology-heavy; candidates conflate orchestration, automation, and autonomy.
What to do instead
Memorize the autonomy levels with one concrete example per level, and for each describe the closed loop (intent, observe, analyze, decide, act) and what human intervention remains.
Confusing network API exposure with internal APIs: candidates answer that any OSS/BSS API is a 'network API' and miss that exposure requires consent, authentication, SLA, and standardized CAMARA-style interfaces.
API is a generic term; the distinction between internal integration and external monetized exposure is rarely studied explicitly.
What to do instead
Write the exposure chain: developer portal, identity and consent, API gateway, policy and QoS enforcement, charging. For each question, ask whether the consumer is internal or external before choosing an answer.
Answering data center network questions with a single 'spine-leaf is best' reflex, without matching the fabric to workload: east-west vs north-south, oversubscription ratio, EVPN-VXLAN vs routed leaf, and lossless requirements for storage or AI traffic.
Spine-leaf is over-learned as a slogan; the design trade-offs behind it are not practiced.
What to do instead
For each scenario, state traffic pattern, oversubscription target, and whether lossless transport is required; then justify fabric choice and overlay technology against those three criteria.
Treating IP routing as protocol trivia (memorizing OSPF or BGP timers) instead of explaining convergence behavior, route selection order, and how IGP and BGP interact at a domain edge.
Protocol details are easy to drill; the operational reasoning that exam scenarios test is harder to self-check.
What to do instead
Practice 'what happens next' walkthroughs: link failure, IGP reconvergence, BGP withdrawal, best-path recomputation. Write the decision order explicitly before selecting an answer.
Designing microwave links on distance alone, ignoring rain fade margin, modulation and adaptive coding, channel bandwidth, and availability targets that set the required fade margin.
Link budget math is perceived as physics-heavy and is often skipped in favor of product feature lists.
What to do instead
Work three full link budgets by hand: distance, rain zone, availability target, required fade margin, then choose modulation and bandwidth. Check that the chosen modulation can actually meet the availability target.