Definition
Traffic Scheduling is the process by which the base station MAC layer scheduler allocates time-frequency resources (RB/PRB, time slots) to multiple users and services according to priority and strategy in a shared wireless channel. It aims to achieve QoS assurance, multi-user fairness, and maximum system throughput. The scheduling period in LTE is 1ms TTI, while 5G NR supports more flexible slot and mini-slot scheduling to accommodate differentiated service requirements such as eMBB, URLLC, and mMTC. Scheduling decisions rely on inputs such as CQI feedback, QoS levels (QCI/5QI), buffer status (BSR), and delay budget.
Typical Scheduling Algorithms
Round Robin (RR)
Resources are allocated to users in turn, ensuring absolute fairness but lower throughput, suitable for services that are not sensitive to rate.
Maximum C/I (Max C/I)
Prioritizes allocating resources to users with the best channel quality, achieving the highest throughput but edge users may starve; suitable for scenarios with large channel quality differences.
Proportional Fair (PF)
Balances between throughput and fairness, schedules based on the ratio of a user's instantaneous rate to average rate, considering both system capacity and multi-user fairness; it is the most commonly used algorithm in LTE.
Delay-sensitive scheduling
For URLLC, voice, and other low-latency services, Earliest Deadline First (EDF) or priority scheduling based on the remaining delay budget is adopted to guarantee critical service latency.
Relationship with Related Mechanisms
Traffic scheduling works in coordination with rate control and congestion control: the scheduler determines "who gets how much resource when," while rate control constrains "how fast to send." Priority QoS is mapped to scheduling weights via QCI/5QI, and differentiated services rely on scheduling strategies to achieve service isolation.
When SimtoLink IoT devices access the cellular network, their uplink data is allocated PRBs by the base station scheduler using algorithms like PF. Narrowband services such as NB-IoT and Cat.1 typically adopt coverage enhancement modes and long TTI scheduling, sacrificing some latency in exchange for coverage and power optimization. In solution design, SimtoLink selects the appropriate standard and QoS configuration according to service latency requirements to ensure that critical commands and bulk data obtain reasonable priority at the scheduling level.
Proportional Fair Compares Instant Rate with the Recent Average
In each transmission interval the scheduler decides which resource blocks go to which users. Round-robin hands them out in order. Everyone gets a share, and total cell throughput stays low. Maximum carrier-to-interference always serves the user with the best channel first. Total throughput is highest, and an edge user may go a long time without a block. Proportional fair divides the rate the user can reach right now by its own recent average rate. Whoever is “more worth serving relative to its own normal state” goes first. A nearby user does not hold the channel forever, and an edge user can be compensated when its channel occasionally improves. Delay-sensitive scheduling then puts the remaining delay budget into the priority, so a control packet close to its deadline can move to the front.
The inputs are channel quality, how much data is in the buffer, the bearer priority, and how many resources are left in this frame. If the device has not reported buffer status, the scheduler does not know it should grant uplink resources. If the reported quality is stale, blocks are given to a user that has already faded. After a block error they are retransmitted, which means the resource was given out twice.
Low-Latency Traffic Needs Its Own Weight
Ordinary reports can accept proportional fair. If an emergency stop, a remote control, or voice shares one priority with a large file download, the file transfer occupies the channel continuously while the channel is good, and the control packet waits for the next round. Map the low-latency bearer to a higher scheduling weight, and limit how many blocks one user may take in a frame. A 5G mini-slot can shrink one schedule to fewer symbols, but only a service recognized as the matching QoS flow gets that treatment. The default data flow still queues on an ordinary slot.
Narrowband IoT often uses longer repetition and a longer scheduling interval. What coverage buys is a longer occupation by each user, and the number of devices the cell can schedule at once falls. Staggering the second at which devices report is then more effective than changing the scheduling algorithm. Scheduling also does not solve an idle wake-up. Until the device has been paged into connected mode, it is not in the scheduling queue. A device that stays connected for a long time with no data still holds context, which reduces the scheduling entries available to others. A congestion drop happens after the queue, where it meets the packet drop policy. Do not record “never scheduled” and “already dropped” as the same failure.
Tuning Only for Maximum Cell Throughput
A common mistake is to push the cell throughput figure up with maximum carrier-to-interference. Success for edge meters and basement gateways falls, and the average-rate report looks better. Another case is every bearer on the same weight, with the application then sending the alarm several extra times. The alarm and the bulk data raise the queue together. If firmware throttles buffer-status reports until they are too rare, uplink resources always arrive late. The application sees a send buffer piling up and misreads it as a server rate limit.
Acceptance should separate near-site throughput, edge success rate, and the queuing delay of high-priority packets. The schedule is reasonable only when all three improve. If only the first improves, the other two were probably sacrificed. Also watch the share of resources taken by retransmission. When retransmission is high, raising the modulation of the first transmission further makes the scheduler give blocks to users who cannot receive them.
With no uplink buffer-status report, the scheduler does not know the device has data to send, and resources go first to users that report more promptly. If firmware stretches the report interval too far, the application only sees the send buffer piling up and easily misreads that as a server rate limit. If a low-latency packet and a large packet have the same weight, a large transfer on a good channel fills several frames in a row. Limit how many resources one user may take in a frame, and weight control packets that are close to their deadline on their own. When the retransmission share is already high, raising the modulation of the first transmission further only makes more of the assigned blocks land on users who cannot receive them.