Network Operations, Analytics and Emerging TrendsIntroduction and ContextModern networks are no longer operated only by configuring routers and switches manually. They are distributed, software-controlled, security-sensitive systems that support cloud services, industrial processes, mobile communication, online education and critical infrastructure. Their scale and complexity require continuous observation, evidence-based diagnosis, automation and carefully governed change. Network operations is the discipline of keeping communication systems available, performant, secure and maintainable. It combines monitoring, event management, incident response, capacity planning, configuration management, security operations and service-level management. Network analytics transforms operational data into information that supports decisions, such as whether a link is congested, whether a failure is developing, or whether an application is being affected by excessive latency. This chapter examines practical methods for operating networks and introduces major developments including software-defined networking (SDN), network functions virtualisation (NFV), intent-based networking, AI-assisted operations, edge computing, 5G/6G and zero-trust networking. Learning ObjectivesAfter studying this chapter, a learner should be able to: - Explain the role of logs, packet analysis, SNMP and telemetry in network operations.
- Select meaningful performance metrics and construct a network baseline.
- Apply a structured troubleshooting process using evidence and hypotheses.
- Interpret common availability, latency, utilisation and error measurements.
- Describe automation, SDN, NFV and intent-based networking.
- Explain the operational uses and limitations of AI-assisted networking.
- Discuss edge computing, 5G/6G and zero-trust networking.
- Evaluate governance, security, ethical and professional issues in automated operations.
1. The Operational View of a NetworkA network can be viewed through three related planes: - Data plane: forwards user packets.
- Control plane: calculates routes and maintains forwarding decisions.
- Management plane: configures devices, collects information and coordinates operation.
Traditional devices combine these functions in individual appliances. Contemporary architectures increasingly separate them logically or physically. For example, an SDN controller may provide centralised control while switches perform data-plane forwarding. A network operations team normally performs the following activities: | Activity | Purpose | Typical evidence |
|---|
| Fault management | Detect and restore service failures | Alarms, logs, reachability tests | | Performance management | Maintain acceptable service quality | Latency, loss, utilisation | | Configuration management | Control intended device state | Backups, version control, change records | | Security operations | Identify and contain threats | Authentication logs, flow records, alerts | | Capacity planning | Prepare for future demand | Growth trends, peak utilisation | | Availability management | Meet service commitments | Uptime and incident statistics |
A useful operational principle is observe before changing. An apparently reasonable configuration change can remove evidence, create a second fault or increase service disruption. Operators should record the symptom, affected scope, time, recent changes and available evidence before intervention. 2. Network Data Sources2.1 Logs and EventsA log is a time-stamped record of an event. Sources include routers, switches, firewalls, servers, wireless controllers, authentication systems, cloud platforms and applications. Logs may record interface transitions, routing changes, denied connections, configuration changes, authentication attempts and system resource exhaustion. A central log platform commonly performs four functions: - Collection: receives records using mechanisms such as syslog, an agent or an API.
- Normalisation: converts different formats into common fields.
- Correlation: relates events from several devices or services.
- Retention and search: supports investigation, compliance and trend analysis.
Important fields include timestamp, hostname, device identity, severity, event type, source and destination addresses, interface, user identity and change reference. Time synchronisation is essential. If devices have inconsistent clocks, the apparent sequence of events may be false. Network Time Protocol (NTP), or a suitably controlled time service, should therefore be monitored as an operational dependency. Log severity is not the same as business impact. A warning may be harmless in one context but critical when repeated across many devices. Conversely, a single high-severity message may have no effect on a customer-facing service. Effective operations correlate technical events with service impact. 2.2 Simple Network Management ProtocolSNMP is a management protocol used to read or modify structured management information. A managed device exposes objects identified by object identifiers (OIDs), commonly organised in a Management Information Base (MIB). A manager can poll counters such as interface octets, packet errors and operational state. Devices may also send unsolicited notifications, traditionally called traps or informs. SNMP polling is useful for periodic measurement, inventory and trend analysis. Its limitations include polling delay, overhead, incomplete vendor instrumentation and the possibility that a short event occurs between polling intervals. SNMPv3 should be preferred where available because it supports authentication and message protection. Older community-string-based approaches should not be treated as strong security controls. Counter interpretation requires care. An interface-octet counter is cumulative and may wrap or reset. A rate must be calculated from two readings: Rate = (C₂ − C₁) ÷ (t₂ − t₁) Here, C₁ and C₂ are counter values in octets or bits, and t₁ and t₂ are measurement times in seconds. If the counter resets, wraps, or is sampled inconsistently, the calculation is invalid unless the discontinuity is corrected. To convert octets per second to bits per second, multiply by 8. 2.3 Flow RecordsFlow technologies summarise conversations rather than capturing every packet. A record may contain source and destination addresses, source and destination ports, protocol, packet count, byte count and start and end times. Flow data helps identify top users, unusual destinations, asymmetric traffic, application categories and possible attacks. It normally does not reveal packet payloads and therefore complements, rather than replaces, packet capture. 2.4 Packet AnalysisA packet capture contains frames or packets observed at a monitoring point. Tools such as Wireshark can display protocol fields, retransmissions, sequence numbers, flags, DNS exchanges, TCP handshakes and timing relationships. A disciplined packet-analysis method is: - Define the question: for example, “Is the delay caused by the client, network or server?”
- Identify the observation point and capture limits.
- Establish a time window and filter irrelevant traffic.
- Follow a transaction or conversation across protocol layers.
- Compare timestamps, acknowledgements, retransmissions, resets and responses.
- Correlate the result with logs and device counters.
Packet capture has limitations. It may miss traffic on another path, fail to see encrypted payloads, introduce storage and privacy concerns, or capture symptoms rather than causes. A packet trace must therefore be interpreted in context. 2.5 Streaming TelemetryStreaming telemetry moves measurements from a device to a collector continuously or at short intervals. It can provide more timely and granular data than traditional polling. Common implementations use structured data models and publish-subscribe or model-driven interfaces. Telemetry is particularly useful for rapidly changing environments, congestion analysis and automated control. Telemetry does not eliminate design decisions. Excessive collection increases storage, processing and network costs. Poorly defined schemas make cross-vendor analysis difficult. Operators should identify the decisions that data must support, then collect the minimum sufficient measurements at appropriate frequencies. 3. Metrics, Baselines and Service Quality3.1 Core MetricsImportant network measures include: - Availability: proportion of required time that a service is usable.
- Latency: time taken for a packet or transaction to travel between defined points.
- Jitter: variation in packet delay, especially important for voice and video.
- Packet loss: packets not successfully delivered.
- Throughput: successfully delivered data per unit time.
- Utilisation: fraction of available capacity being consumed.
- Error rate: proportion of transmissions affected by errors.
- Control-plane health: route stability, CPU use, memory use and protocol state.
A metric is meaningful only with a measurement point, interval, population and definition. “Latency is 20 ms” is incomplete unless the path, direction, packet type and time window are known. For N observations, mean latency is: x̄ = (1 ÷ N) ∑ᵢ₌₁ᴺ xᵢ where xᵢ is the i-th measurement and x̄ is the arithmetic mean. The mean can hide occasional severe delay, so median and percentiles are often more useful. The 95th percentile is the value at or below which approximately 95% of observations fall, subject to the chosen estimation method. Packet-loss percentage can be expressed as: Loss% = [(Nsent − Nreceived) ÷ Nsent] × 100 This assumes that sent and received packets are counted for the same test, sequence and observation period, and that N_sent is greater than zero. For a service observed over a period T, measured availability is: Availability% = [(T − D) ÷ T] × 100 where D is unplanned unavailable time. Planned maintenance, partial degradation and the service-level agreement may require separate treatment. Availability percentages can be misleading for short measurement periods; the observation window must be stated. 3.2 BaselinesA performance baseline describes normal behaviour for a defined system and context. It should include time-of-day patterns, weekdays versus weekends, application workloads, routing conditions, wireless conditions and expected maintenance periods. A baseline is not a single universal number. For example, a branch office may normally use 15% of a link during the day, while a data-centre backup window may normally use 85% at night. Baseline construction involves: - Selecting reliable measurements.
- Collecting data over representative periods.
- Separating normal operational modes.
- Describing central tendency and variability.
- Recording known events and changes.
- Defining thresholds and escalation actions.
Static thresholds are simple but may produce false alarms when demand is seasonal. Dynamic thresholds compare current behaviour with an appropriate historical pattern. Both require validation by an operator. 3.3 Service-Level Indicators and ObjectivesA service-level indicator (SLI) is a measured quantity, such as successful connection rate or 95th-percentile latency. A service-level objective (SLO) is a target for that indicator. A service-level agreement (SLA) is a formal commitment that may include remedies. These terms should not be confused. A technically excellent metric is not necessarily a useful SLI if it does not represent user experience. 4. A Structured Troubleshooting ProcessTroubleshooting is a process of reducing uncertainty, not merely trying commands. A practical sequence is: Step 1: Establish the symptomDetermine what is failing, for whom, where and when. Distinguish complete failure from slowness, intermittent loss, authentication failure or application-specific failure. Step 2: Define scopeCompare affected and unaffected users, paths, sites, protocols, address families and devices. Scope often reveals whether the issue is local, shared or service-specific. Step 3: Check recent changeReview approved configuration, software, routing, security-policy and cabling changes. Correlation with a change is evidence, not proof; rollback should follow change-control procedures. Step 4: Test from the correct layersCheck physical status and errors, link and VLAN state, addressing and neighbour resolution, routing, transport behaviour and application response. Ping alone cannot prove that an application is healthy. Step 5: Form and test hypothesesExamples include a failed interface, MTU mismatch, route asymmetry, DNS delay, overloaded firewall or server-side bottleneck. Each test should distinguish among hypotheses and have a defined expected result. Step 6: Contain and restoreApply the least disruptive effective action. Preserve evidence, document commands and obtain approval where required. Step 7: Verify and learnConfirm recovery from the user or service perspective, monitor for recurrence, identify the root or contributing causes, and update documentation, monitoring or design. A useful distinction is between symptom, proximate cause and root cause. “Users cannot reach the database” is a symptom. “The firewall dropped sessions” is a proximate cause. “A policy deployment lacked validation and incorrectly classified the database subnet” may be a root organisational or technical cause. 5. Automation and Programmable OperationsNetwork automation uses software to perform discovery, configuration, validation, remediation or reporting. It may use APIs, structured data, command-line interfaces, infrastructure-as-code tools and event-driven workflows. Good automation has the following properties: - Idempotence: applying the same desired state repeatedly does not create unintended changes.
- Validation: syntax, policy, reachability and resource checks occur before deployment.
- Small scope: changes can be staged and rolled back.
- Authentication and authorisation: credentials are protected and permissions are limited.
- Auditability: the requester, code version, time, target and result are recorded.
- Human control: high-impact actions require approval or an explicit safety policy.
A typical workflow is: discover state → compare with intended state → generate a change → validate in a test environment → deploy to a limited group → observe → expand or roll back. Automation reduces repetitive work and configuration inconsistency, but it can also amplify an error. A defective script may change thousands of devices quickly. Testing, peer review, version control, backups and staged deployment are therefore operational safeguards, not optional conveniences. 6. SDN, NFV and Intent-Based Networking6.1 Software-Defined NetworkingSDN separates the decision-making control function from packet-forwarding devices and exposes programmable interfaces. A logically central controller maintains a network-wide view and communicates with forwarding devices through southbound mechanisms. Applications and orchestration systems may communicate with the controller through northbound interfaces. The controller is logically centralised but should not automatically be physically single or without redundancy. Controllers require high availability, secure communication, access control and protection against incorrect policies. SDN can simplify consistent policy and traffic engineering, yet it introduces controller dependency, interoperability questions and a larger software attack surface. 6.2 Network Functions VirtualisationNFV implements functions such as firewalls, routers, load balancers and intrusion-detection systems as software running on virtualised or cloud infrastructure. A virtual network function (VNF) may be deployed, scaled or relocated more flexibly than a dedicated appliance. Cloud-native network functions increasingly use containers and microservices. NFV changes operational priorities. Teams must manage compute, storage, virtual switching, orchestration, service chains, licensing, image security and performance isolation. Virtualisation does not remove physical limitations: CPU capacity, memory, link bandwidth and failure domains still matter. 6.3 Intent-Based NetworkingIntent-based networking translates a high-level business or service requirement into validated network policy. An operator might specify that a particular application must be reachable only by authorised users with a latency objective. The system translates intent into configuration, continuously verifies observed state and alerts or remediates deviations. Intent is not magic. It must be unambiguous, feasible and measurable. Conflicting intents need priority rules. The translation logic must be tested, and operators must be able to inspect why a particular configuration was generated. 7. AI-Assisted Network OperationsAI and machine learning can assist with anomaly detection, event correlation, capacity forecasting, root-cause ranking, configuration generation and natural-language querying. Supervised models learn from labelled examples; unsupervised or semi-supervised methods identify patterns without complete labels. Time-series methods forecast expected demand, while graph-based methods can reason about dependencies among devices and services. AI assistance should be treated as decision support unless its safety has been demonstrated for a specific action. Important risks include: - noisy or biased historical data;
- concept drift when topology or workloads change;
- false positives and false negatives;
- opaque explanations;
- data leakage through prompts or training sets;
- automation of a wrong recommendation;
- adversarial or manipulated telemetry.
A responsible operational design records the input data, model version, recommendation, confidence, human decision and outcome. Models should be evaluated using operationally relevant measures, not accuracy alone. For rare failures, a model that always predicts “normal” may appear accurate while being useless. Generative AI can help summarise incidents or draft commands, but generated commands must be reviewed, tested and constrained by least privilege. Confidential configurations, credentials and personal data must not be sent to unauthorised services. 8. Edge Computing, 5G and 6GEdge computing places computation and storage near users, sensors or machines rather than exclusively in a distant central cloud. Benefits include reduced round-trip delay, local resilience, lower backhaul use and support for location-sensitive applications. Costs include distributed management, physical exposure, limited resources, inconsistent software versions and more complex troubleshooting. 5G networks introduce capabilities such as enhanced mobile broadband, support for large numbers of devices and low-latency service classes. Network slicing can provide logically separated services over shared infrastructure, but isolation, orchestration and assurance must be demonstrated rather than assumed. Mobile operations also require radio measurements, mobility analysis, core-network visibility and coordination among infrastructure providers. 6G is a developing research and standardisation area rather than a single universally deployed technology. Proposed directions include more integrated sensing and communication, advanced programmability, artificial intelligence, extreme densification and new spectrum use. Claims about 6G should therefore be distinguished from established specifications and commercial deployments. 9. Zero-Trust NetworkingZero trust is a security approach in which access is not automatically trusted merely because a user or device is inside a network boundary. Access decisions should consider identity, device state, resource, context and policy, and should be continuously evaluated where appropriate. Core practices include strong identity, multi-factor authentication, least privilege, segmentation, encrypted communication, device inventory, policy enforcement near resources, continuous monitoring and rapid revocation. Zero trust is not a single product and does not mean that every packet must be inspected identically. It is an architectural and governance approach. Operations teams must integrate identity logs, endpoint posture, network flows, application telemetry and policy records. A failure in identity infrastructure can therefore become a network availability incident. Careful design is needed to avoid excessive complexity, inaccessible services during outages and surveillance beyond legitimate purposes. 10. Governance, Ethics and Professional PracticeNetwork data can contain addresses, usernames, location information, browsing patterns and security-sensitive content. Collection should have a legitimate purpose, defined retention, access controls and appropriate protection. Packet capture is especially sensitive because payloads may contain personal or confidential information. Professional operations should follow separation of duties, change approval, incident documentation, secure credential handling, vulnerability management and tested recovery plans. Regulatory requirements vary by jurisdiction and sector, but common obligations include protecting personal data, preserving evidence appropriately and reporting certain incidents. Automation and AI create accountability questions. An organisation should be able to identify who authorised a policy, which system generated it, what evidence supported it and how it can be reversed. Efficiency is not a justification for eliminating human review of high-risk actions. 11. Illustrative Case Study: Intermittent Voice Quality at a Regional CollegeBackgroundA regional college operates voice-over-IP phones across a campus. Users report that calls become unintelligible for several minutes during afternoon teaching changes. Web access appears normal. Problem and analysisThe operations team first defines the symptom: voice quality degradation affects several buildings between 13:45 and 14:15, but not every day. They compare wireless users, wired phones and unaffected buildings. Switch telemetry shows that an uplink reaches 92% utilisation during the interval, while the normal baseline is below 55%. Interface error counters remain normal. Flow records show large backup transfers from a storage server to a remote site. Packet captures from an affected voice VLAN show increased delay variation and occasional late packets, but no evidence of a damaged cable or failed voice server. The time pattern correlates with a scheduled backup job. Approach and solutionThe team confirms that voice and backup traffic share a constrained path. Rather than immediately increasing bandwidth, they apply a controlled change: classify voice traffic correctly, verify queue behaviour, limit the backup schedule during teaching hours and monitor the uplink. They validate markings at the access switch, distribution switch and WAN edge because a marking can be lost or rewritten at any point. OutcomeVoice-quality reports cease during the next observation period. Utilisation remains high during the backup, but voice packets receive appropriate treatment and the backup is shifted partly outside teaching hours. The team documents the baseline, adds an alert for sustained queue drops and includes quality-of-service verification in future change testing. Learning pointsThe case illustrates that normal web access does not prove that real-time traffic is healthy. It also demonstrates the value of combining user reports, baselines, telemetry, flow records and packet analysis. The least disruptive solution addressed both policy and workload timing rather than assuming that more bandwidth was the only answer. 12. Best-Practice Operational Checklist- Synchronise device clocks and monitor time-service health.
- Define metrics with measurement points, intervals and units.
- Establish baselines for normal operating modes.
- Centralise logs while preserving source identity and integrity.
- Use SNMP, flow records, telemetry and packet capture as complementary sources.
- Protect management interfaces with strong authentication and least privilege.
- Use version control, peer review, testing and staged rollout for automation.
- Maintain current topology, dependency and configuration documentation.
- Test backups, rollback procedures and disaster-recovery plans.
- Review AI recommendations and keep a human-controlled path for high-impact actions.
- Minimise sensitive data collection and define retention and access rules.
- Convert repeated incidents into permanent improvements in design, monitoring or process.
Chapter SummaryNetwork operations combines observation, diagnosis, controlled change and continuous improvement. Logs provide event history; SNMP supplies structured management data; flow records summarise conversations; packet analysis exposes protocol behaviour; and streaming telemetry provides timely, granular measurements. These sources become useful when aligned with accurate time, clear definitions and a representative performance baseline. Metrics such as latency, loss, utilisation and availability must be interpreted with their units, observation windows and measurement points. Structured troubleshooting begins with scope and evidence, tests hypotheses across protocol layers, restores service safely and captures learning. Automation improves consistency but requires validation, least privilege, auditability and rollback. SDN separates programmable control from forwarding, NFV implements network functions in virtualised infrastructure, and intent-based networking translates high-level requirements into verified policy. AI can support anomaly detection and operational analysis but introduces risks involving data quality, explainability, privacy and unsafe automation. Edge computing, 5G/6G and zero-trust networking extend the operational problem into distributed, mobile, identity-aware environments. Effective professionals combine technical skill with governance, security, ethics and disciplined change management. Key TermsNetwork operations: The practice of monitoring, maintaining, securing and improving communication networks. Log: A time-stamped record of an event generated by a device, service or application. SNMP: A protocol for exchanging structured management information with network devices. MIB: A structured collection of managed objects that can be accessed through management protocols. Telemetry: Continuous or frequent publication of measurements from a system to a collector. Flow record: A summary of communication between endpoints, usually without packet payloads. Packet capture: A recorded sequence of frames or packets used for protocol analysis. Baseline: A description of normal system behaviour under defined conditions. Latency: The time taken for data or a transaction to travel between specified points. Jitter: Variation in packet delay. Availability: The proportion of required service time during which a service is usable. SLO: A target for a measured service-level indicator. Automation: Use of software to perform repeatable operational tasks. SDN: An architecture that separates programmable control functions from packet forwarding. NFV: Implementation of network functions as software on virtualised infrastructure. Intent-based networking: Translation and verification of high-level requirements into network policy. Edge computing: Placement of computation near data sources or users. Zero trust: A security approach that does not grant implicit trust based solely on network location. Network slicing: Logical separation of services over shared network infrastructure. Root cause: The underlying condition whose removal prevents recurrence of an incident. Review QuestionsShort Answer Questions- What are the main purposes of logs in network operations?
- Why must time synchronisation be monitored across network devices?
- Distinguish between a baseline and a threshold.
- What is the difference between a flow record and a packet capture?
- Why is staged deployment important in network automation?
Long Answer Questions- Explain how SNMP, streaming telemetry, flow records and packet analysis complement one another.
- Describe a structured troubleshooting process from initial symptom to post-incident improvement.
- Explain the architecture, advantages and risks of software-defined networking.
- Compare NFV and intent-based networking, including their operational implications.
- Discuss the benefits and limitations of AI-assisted network operations.
Analytical / Application Questions- A campus link shows high utilisation every afternoon, but users report problems only with video meetings. Design an investigation using baselines, flow data, telemetry and packet analysis.
- An automation system proposes changing firewall policy on 2,000 devices after detecting a suspected attack. Specify the validation, governance, safety and rollback controls required before approval.
- A hospital plans to deploy edge computing and zero-trust access for medical devices. Analyse the likely operational benefits, dependencies, privacy risks and failure scenarios.
Multiple Choice Questions with AnswersQuestion 1Which data source summarises conversations without normally recording packet payloads? A. Flow records B. Full packet capture C. Device configuration backup D. Optical power measurement Correct Answer: A. Flow records Question 2In the expression Rate = (C₂ − C₁) ÷ (t₂ − t₁), what do C₁ and C₂ represent? A. Two device temperatures B. Two cumulative counter readings C. Two routing protocols D. Two packet-loss percentages Correct Answer: B. Two cumulative counter readings Question 3Why is a performance baseline usually collected over representative time periods? A. To remove the need for monitoring B. To identify normal variation and operating patterns C. To guarantee zero packet loss D. To replace configuration management Correct Answer: B. To identify normal variation and operating patterns Question 4Which practice best reduces the risk of an automation error affecting an entire network? A. Using one untested script on all devices B. Disabling audit logs C. Staged deployment with validation and rollback D. Sharing administrator passwords Correct Answer: C. Staged deployment with validation and rollback Question 5What is a principal characteristic of SDN? A. It prohibits software control of networks B. It separates programmable control functions from forwarding C. It requires every device to operate without a control plane D. It replaces all physical links with wireless links Correct Answer: B. It separates programmable control functions from forwarding Question 6NFV primarily refers to which capability? A. Running network functions as software on virtualised infrastructure B. Encrypting every packet with the same key C. Measuring only radio signal strength D. Removing the need for network monitoring Correct Answer: A. Running network functions as software on virtualised infrastructure Question 7Which statement best describes zero-trust networking? A. All internal users are trusted automatically B. Access decisions consider identity, context and policy rather than location alone C. Only perimeter firewalls are required D. Encryption is unnecessary inside an organisation Correct Answer: B. Access decisions consider identity, context and policy rather than location alone Question 8A packet-loss test sends 1,000 packets and receives 970. What is the loss percentage? A. 0.3% B. 3% C. 30% D. 97% Correct Answer: B. 3% Question 9Which is a significant limitation of AI-assisted network operations? A. AI can never process telemetry B. Models may produce false positives, false negatives or unsafe recommendations C. AI removes the need for human accountability D. AI prevents all configuration changes Correct Answer: B. Models may produce false positives, false negatives or unsafe recommendations Question 10What is a major operational challenge introduced by edge computing? A. It eliminates distributed systems B. It makes all applications physically centralised C. It increases the number of distributed sites and software states to manage D. It prevents local processing Correct Answer: C. It increases the number of distributed sites and software states to manage
|