5. Traffic in Next-Generation Networks

What Does Network Traffic Mean?

Traffic is the sequence of data units offered to a network over time. A traffic flow is not described only by how many bits it carries. The network also needs to know how quickly those bits arrive, which direction they travel, how long they may wait, how much loss is tolerable, and how many devices compete for resources.

Useful traffic dimensions include:

• direction: downlink, uplink, or strongly bidirectional;
• rate: average and peak bit rate;
• burstiness: continuous stream, periodic report, or sudden burst;
• packet size: many small control packets or fewer large data units;
• latency and jitter: deadline and variation in delivery time;
• reliability: acceptable packet or block failure probability;
• connection density: number of simultaneously active or registered devices;
• mobility: fixed sensor, pedestrian, vehicle, drone, or satellite-connected user;
• duration: short transaction, session, or always-on flow;
• energy constraint: mains-powered terminal or battery-limited device.

Two applications with the same average rate can therefore create very different scheduling problems.

Traffic Types Used Today

The familiar 5G families—eMBB, URLLC, and mMTC—are requirement/use-case groupings rather than three literal packet formats. An application can combine them. For example, a remotely operated machine can carry high-rate video resembling eMBB and urgent control resembling URLLC at the same time.

How Traffic Travels from an Application to the UE

A simplified downlink path is

The uplink follows the reverse direction, but the UE first needs an uplink opportunity or configured/grant-free resource under the applicable system design.

What Happens at Each Stage?

1. Application: generates packets, frames, sensor reports, commands, model data, or media segments.
2. Core/edge path: routes data through a PDU session toward the radio access network. Edge placement can reduce transport distance and processing delay.
3. QoS classification: packets are associated with a QoS flow whose treatment can include resource type, priority, packet-delay budget, error-rate target, and flow-rate parameters.
4. Radio bearer and queueing: the access network maps traffic onto radio resources and maintains buffers for active users.
5. Scheduling: the gNB decides which UE receives which physical resource blocks, time intervals, modulation/coding, HARQ process, beam, and direction opportunity.
6. Transmission and recovery: the receiver demodulates, decodes, reorders, and passes data upward; failed blocks may trigger retransmission.

Why the Base Station Needs a Scheduler

Radio resources are finite and the channel changes across users. Let $A_i[t]$ be new traffic entering queue $i$ during interval $t$, $Q_i[t]$ the queued data, and $\mu_i[t]$ the data served by the scheduler. A simplified queue evolution is

Where:

• $Q_i[t]$ is the queued data for flow or UE $i$ at interval $t$;

• $\mu_i[t]$ is the amount of queued data served during that interval;

• $A_i[t]$ is the new traffic arriving during that interval;

• $\max(\cdot,0)$ prevents the mathematical queue length from becoming negative;

• $Q_i[t+1]$ is the queue carried into the next interval.

• If arrivals repeatedly exceed service, the queue grows and delay rises.

• A high-rate user may need many resource blocks.

• An urgent control packet may need few bits but must be scheduled before its deadline.

• A battery sensor may prefer a short, efficient access opportunity and then return to sleep.

The scheduler therefore balances radio quality, queue size, priority, delay budget, reliability, fairness, retransmissions, beam availability, UL/DL direction, and operator policy.

The end-to-end delay can be separated conceptually as

Where:

• $D_{\mathrm{E2E}}$ is total end-to-end delay;
• $D_{\mathrm{queue}}$ is waiting time in buffers;
• $D_{\mathrm{schedule}}$ is the wait for a valid radio allocation;
• $D_{\mathrm{transmission}}$ is the time used to send the data;
• $D_{\mathrm{propagation}}$ is physical signal travel time;
• $D_{\mathrm{processing}}$ is coding, decoding, protocol, and application-processing time;
• $D_{\mathrm{transport}}$ is delay across fronthaul, backhaul, core, edge, or external networks.

A faster air interface cannot by itself meet a deadline when the packet waits too long in an application server, core path, or scheduler queue.

Current Wireless Traffic in Practical Scenarios

Smartphone During a Video Call

• DL: remote video, audio, signalling, and background downloads.
• UL: local camera, microphone, acknowledgements, and channel reports.
• Behaviour: sustained bidirectional media with bursty control.
• Network action: maintain latency and jitter while adapting video rate to radio conditions.

Smart Meter Fleet

• Mostly tiny periodic UL reports.
• Devices may be inactive for long intervals.
• A power-restoration event can synchronize thousands of reports and create an access surge.
• Network action: energy-efficient access, overload control, and fair contention handling.

Cloud Gaming

• DL: rendered frames at high sustained rate.
• UL: frequent controller and pose updates.
• Network action: protect short interactive packets from waiting behind bulk traffic and place compute near the user where useful.

Factory Vision and Robot Control

• UL: large camera or sensor streams toward an edge processor.
• DL: short control commands toward the robot.
• Network action: isolate and prioritize control while still transporting high-rate vision data.

6G Traffic: Use Scenarios, Not Fixed Packet Types

As of the IMT-2030 framework, ITU identifies six usage scenarios. They describe expected service directions and capability needs; they do not prescribe six universal packet formats. Actual 6G radio and core standards continue to evolve.

1. Immersive Communication

This extends mobile broadband toward rich interactive media.

Possible traffic includes:

• multi-view XR or holographic scene data;
• spatial audio and haptic feedback;
• frequent pose and interaction updates;
• edge-rendered video with strict motion-to-photon timing;
• adaptive point clouds or scene representations.

The traffic may be DL-heavy in raw bit volume but strongly bidirectional in timing: a small delayed head-pose update can make a large downlink scene frame useless.

2. Hyper-Reliable and Low-Latency Communication

HRLLC extends the goals associated with 5G URLLC toward specialized cases with more stringent reliability and latency needs.

Possible traffic includes:

• robot coordination and emergency stop commands;
• cooperative vehicle manoeuvre messages;
• grid protection and industrial safety loops;
• remote control with state feedback;
• deterministic machine-to-machine transactions.

These flows are often small in bit volume. Their difficulty comes from deadlines, reliability, synchronization, and the need to remain dependable during mobility, interference, or partial network failure.

3. Massive Communication

This extends massive machine-type communication to very large populations of devices and sensors.

Possible traffic includes:

• environmental, agricultural, utility, logistics, and infrastructure sensing;
• asset tags and condition monitoring;
• sparse periodic reports mixed with correlated event bursts;
• device software/configuration updates in the downlink.

The network must avoid spending more signalling energy and spectrum than the payload itself requires.

4. Ubiquitous Connectivity

This aims to extend useful connectivity across rural, remote, indoor, maritime, aerial, or otherwise underserved locations, potentially through terrestrial and non-terrestrial interworking.

Traffic may include:

• delay-tolerant store-and-forward telemetry;
• ordinary voice/data with variable round-trip delay;
• public-safety or emergency messaging;
• remote education, health, and community broadband;
• satellite or high-altitude-platform backhauled access.

The design must adapt to long propagation delay, intermittent visibility, limited power, handover across heterogeneous systems, and unequal UL/DL capacity.

5. Artificial Intelligence and Communication

AI can generate traffic for inference, training, coordination, and network operation.

Possible traffic includes:

• sensor features or embeddings uploaded to an edge model;
• model updates, gradients, or selected parameters;
• inference requests and generated results;
• distributed-agent state and coordination messages;
• model downloads and personalized updates;
• semantic or task-oriented representations where usefulness matters more than reproducing every source bit.

AI traffic can be highly variable. A tiny inference request may trigger a large result, while federated learning may send repeated uplink updates from many devices. Model freshness, privacy, compute location, and energy can matter alongside rate and latency.

6. Integrated Sensing and Communication

ISAC reuses or coordinates radio resources for data delivery and sensing.

Traffic may include:

• scheduled sensing waveforms and reference signals;
• raw or processed echo observations;
• range, angle, Doppler, occupancy, or object-track reports;
• cooperative sensing data from several nodes;
• sensing-task control and feedback;
• ordinary user data sharing time, frequency, beams, and hardware with sensing.

The challenge is broader than packet transport. The scheduler may need to preserve waveform, beam, timing, and observation geometry while meeting communication QoS.

One 6G Session May Mix Several Traffic Families

Consider a remotely supervised autonomous vehicle:

1. high-rate cameras and lidar-derived features travel uplink to an edge service;
2. cooperative perception messages arrive from nearby vehicles or infrastructure;
3. small control corrections have strict deadlines;
4. a passenger uses immersive media;
5. the radio performs sensing for unconnected objects;
6. an AI model receives periodic updates.

Treating all packets as one FIFO stream can make short urgent messages wait behind large media or model transfers. A next-generation network needs classification, admission control, scheduling, edge placement, congestion management, and isolation across these interacting flows.

Traffic Engineering Quantities

For a flow observed over interval $T$, offered average rate is

Where:

• $R_{\mathrm{offered}}$ is the average rate presented to the network;
• $L_p$ is the size in bits of packet $p$;
• $N$ is the number of offered packets observed;
• $T$ is the measurement interval;
• $\sum_{p=1}^{N}L_p$ is the total number of offered bits.

Delivered goodput counts only useful application bits arriving within the measurement rules:

Where:

• $G_{\mathrm{delivered}}$ is application goodput;
• $B_{\mathrm{useful,on\ time}}$ counts useful payload bits delivered within the required timing rule;
• $T$ is the same observation interval;
• retransmitted, duplicate, protocol-overhead, corrupted, or late bits are excluded according to the selected measurement definition.

Two flows can have equal $R_{\mathrm{offered}}$ but different peak rate, queueing delay, deadline-miss probability, or energy cost.

Useful measurements include:

• offered load and delivered goodput;
• packet-size and inter-arrival-time distributions;
• mean, percentile, and deadline-miss latency;
• jitter and burst duration;
• packet/block error and retransmission rate;
• queue length and buffer overflow;
• resource utilization and scheduling fairness;
• device energy per delivered useful bit;
• performance during synchronized event bursts, not only steady averages.

How Duplexing Interacts With Traffic

Traffic direction matters to FDD/TDD planning:

• an FDD layer provides separate persistent UL and DL carriers, though their bandwidths may be asymmetric;
• a TDD layer can change its DL:UL time ratio within supported configurations;
• a downlink-heavy pattern may increase waiting time for urgent uplink packets;
• uncoordinated neighbouring TDD patterns can create cross-link interference;
• mixed FDD–TDD carrier aggregation can combine coverage and capacity when supported.

Continue with FDD and TDD for the complete duplexing explanation.

A Practical Analysis Workflow

1. Identify each application flow and its direction.
2. Measure packet sizes, inter-arrival times, bursts, and session duration.
3. State latency, reliability, goodput, and energy requirements separately.
4. Map flows to appropriate QoS treatment and admission policy.
5. Test scheduler behaviour during overload and correlated event bursts.
6. Include radio variation, mobility, retransmissions, and UL/DL constraints.
7. Report distributions and deadline misses, not only average throughput.
8. For proposed 6G services, distinguish standardized IMT-2030 scenarios from implementation assumptions still under research.

Takeaway

Modern wireless traffic ranges from continuous media to tiny sensor reports and deadline-critical control. Packets travel through application, core, QoS, queueing, scheduling, and radio stages before reaching the UE. IMT-2030 expands the design space through immersive communication, HRLLC, massive communication, ubiquitous connectivity, AI and communication, and ISAC. These scenarios produce mixed traffic whose rate, timing, reliability, direction, compute, sensing, and energy needs must be scheduled together.