Nokia SRA Composite common mistakes
Nokia SRA Composite · Understand the traps and how to avoid them.
Treating GPON and XGS-PON as interchangeable when answering upstream/downstream rate and split-ratio questions, quoting 2.5 Gbit/s downstream for an XGS-PON port or assuming a 1:128 split applies equally to both.
Candidates memorise a single 'PON = 2.5G/1.25G, 1:64' figure early in study and never re-anchor it per technology, so the asymmetric GPON numbers leak into XGS-PON (10G/10G symmetric, typically 1:128) and 10G-EPON answers.
What to do instead
Build a one-page comparison table for GPON, XGS-PON, 10G-EPON and NG-PON2 covering line rate per direction, split ratio, wavelength plan and typical reach, and recite it before every fixed-access practice set until the numbers are automatic.
Choosing the wrong VDSL2/vectoring or G.fast profile answer by ignoring loop length and crosstalk assumptions stated in the scenario, for example selecting 35b at full rate on a 600 m loop without accounting for vectoring gain limits.
The copper-access profiles are learned as a rate ladder rather than as rate-versus-reach-versus-crosstalk trade-offs, so candidates pick the highest-numbered profile whenever the question mentions speed.
What to do instead
Rehearse each profile (8b, 12b, 17a, 30a, 35b, 106a/212a) as a reach/rate pair with and without vectoring, and answer by matching the stated loop length and binder conditions rather than by picking the biggest number.
Mixing 5G NR numerologies and slot timing, such as claiming 30 kHz SCS gives 0.5 ms slots but then using the 15 kHz frame structure to compute scheduling or beam-sweep timing in the same question.
The 15 kHz LTE frame structure is over-learned and candidates carry its 1 ms subframe and 0.5 ms slot assumptions into NR, where slot length scales inversely with subcarrier spacing.
What to do instead
Drill the relation slot length = 1 ms / 2^mu for mu = 0..4 (15, 30, 60, 120, 240 kHz) and always write the SCS and resulting slot duration explicitly before computing any NR timing answer.
Confusing 5G SA and NSA architecture details, answering that NSA uses the NGC for control plane or that the gNB in NSA terminates all signalling, instead of recognising EPC anchoring via the LTE master node.
Study material covers both options together and candidates collapse them into one mental model, losing the split between master node (eNB), secondary node (gNB) and which core (EPC vs 5GC) carries control plane and user plane.
What to do instead
Draw the NSA and SA call flows side by side from memory: NSA has eNB as master over EPC with EN-DC split bearer, SA has gNB over 5GC with full NR control plane; redraw weekly until the anchor points are unambiguous.
Answering OTN mapping questions by putting client signals straight into an ODUk without the correct OPUk/ODUflex/OTU hierarchy, or misstating which OTU rate carries which ODUk payload.
The multiplexing hierarchy (client, OPU, ODU, OTU, OCh) is conceptually simple but has many similar-looking acronyms, so candidates skip the layering and jump to the answer that names the highest-rate container.
What to do instead
Practise a mapping ladder for 1GE, 10GE and 100GE clients through OPU/ODU/OTU at OTU1, OTU2, OTU2e, OTU4 and ODUflex, stating which level adds overhead and which is the transport unit, and verify each answer against the rate table.
Treating SDH/SONET protection switching as identical to packet protection, quoting 50 ms for MPLS fast reroute or assuming a 1+1 linear MSP is the same mechanism as SNCP/UPSR.
Candidates lump all 'protection' into one memory slot and apply the SDH 50 ms benchmark to any resilience question, without checking whether the question is about path, subnetwork, ring or packet-layer recovery.
What to do instead
Tabulate each protection scheme (1+1 MSP, 1:1 MSP, SNCP, MS-SPRing/BLSR, MPLS FRR, ERP/G.8032) with its layer, topology, switch trigger and typical recovery time, and answer only after identifying the layer the question describes.
Miscalculating subnet masks and usable host counts under VLSM, for example answering 62 usable hosts for a /26 or allocating overlapping ranges when summarising a multi-site addressing plan.
Candidates memorise the /24 to /30 table but do not consistently subtract network and broadcast addresses or re-derive the block size when subnets are further divided, and exam time pressure pushes them to estimate rather than compute.
What to do instead
Use a fixed method every time: block size = 256 minus the interesting octet mask value, usable hosts = 2^h minus 2, and always list the network, first host, last host and broadcast for each subnet before choosing an option.
Confusing IGP and BGP behaviour on convergence and path selection, such as assuming BGP selects the shortest AS path before weight/local preference, or expecting OSPF to carry external routes without checking the LSA type.
Both protocols are studied as 'routing', so their distinct decision processes blur; candidates remember that BGP uses AS path and forget the earlier tie-breakers, and they forget that OSPF external routes arrive as type 5 or type 7 LSAs.
What to do instead
Write the BGP best-path order from weight through router ID and the OSPF LSA types 1 to 7 with their scope and originator, then answer path-selection questions by walking the list in order rather than pattern-matching keywords.
Answering segmentation and zero-trust questions by placing all enforcement at the core firewall, ignoring identity-based policy at the access edge and the difference between micro-segmentation and traditional VLAN zoning.
Older perimeter-security mental models dominate, and candidates treat 'segmentation' as a synonym for VLANs, missing that modern designs enforce policy close to the workload or user with identity context.
What to do instead
Frame each security scenario by asking where policy is enforced, what identity signal is available and whether east-west traffic is inspected; practice mapping micro-segmentation, SASE and zero-trust principles to concrete enforcement points.
Confusing assurance and automation concepts, such as describing closed-loop automation as simple scripting or claiming telemetry-driven assurance requires manual thresholds rather than intent-based policy.
Automation and assurance are often taught as separate tool categories, so candidates miss the loop from telemetry to analytics to action, and they substitute familiar terms like 'script' or 'alarm' for the exam's model-based vocabulary.
What to do instead
Learn the closed-loop cycle explicitly (intent, telemetry, analytics, decision, action, verification) with one concrete example per stage, and practise distinguishing orchestration, configuration management, assurance and AI/ML-driven anomaly detection.