5 NB-IoT Channel Access

5.1 Follow One Scheduled Scheduled uplink

Read Figure 5.1 from the channel-access device’s access attempt through access network response, grant, scheduled scheduled uplink, and acknowledgement or retry. Each labelled exchange answers a different question: can the channel-access device reach the cell, did the access network recognize the request, which resources were assigned, and did the data transfer finish? A registration icon alone cannot prove the final packet was accepted.

Figure 5.2 then shows how scheduled uplink resources can use single-tone or multi-tone arrangements. Follow the labelled frequency positions and time slots. More assigned tones can shorten a transfer when coverage and channel-access device capability allow, while a narrow single-tone allocation supports robust operation at a different rate. The access network schedules the actual resource; the application does not select a throughput from a brochure.

Use a trace with timestamps. The meter wakes at 12:00:00.000, detects cell information, starts random access at 12:00:00.400, receives its response at 12:00:00.780, obtains an scheduled uplink grant at 12:00:01.050, and finishes its scheduled transmission at 12:00:01.420. The observed access-to-finish time is (1.420-0.400=1.020\ \mathrm{s}). Keep retransmissions and repetitions visible because they change both delay and energy.

Two devices can choose the same random-access opportunity and collide. Backoff spreads their next attempts. In weak coverage, repetitions can improve decoding but occupy resources longer. Congestion, coverage, configuration, and access network policy therefore produce different access delays even for identical payloads.

Build the release record around the grant. Store radio conditions, band, cell, modem firmware, access attempts, granted tone mode, repetitions, payload size, completion result, and timestamps. A speed claim without those conditions is not portable evidence.

Predict three trials. In good coverage, expect one access attempt and the configured test payload to complete. Add attenuation and expect changed repetitions or retries rather than assuming the same schedule. Start several devices together and expect a wider delay distribution caused by contention and backoff. Compare the captured control trace with application acknowledgements before declaring loss.

NB-IoT scheduling is controlled by the deployed access network and modem implementation. Re-measure channel access with the target operator, band, firmware, antenna, and coverage conditions.

Separate radio access from application delivery. A completed scheduled scheduled uplink can still be rejected by the service or wait behind a access network fault. Correlate modem events, packet identity, and application acknowledgement so a missing reading is assigned to the right stage.

Battery tests should include unsuccessful attempts. Measure charge from wake through final sleep for one clean access, one backoff, and the configured failure ceiling. That comparison connects channel contention to channel-access device lifetime.

Keep payload size fixed while comparing radio conditions, then vary size separately. Changing both at once makes delay and charge evidence hard to attribute. Include a rejected or timed-out transfer in the accounting.

5.2 Overview: Channel Access Makes NB-IoT Scheduled

Measure the Wait Before the Small Message

Picture a basement meter that wakes to send one short leak report. The report itself is small, yet the device may spend most of its energy finding the cell, requesting a turn, waiting, repeating, and recovering from failure. The access record must show that full awake period.

Modulation means changing a radio signal so it can carry information. A payload means the useful content inside a message. Mark when the meter begins searching, finds the cell, requests access, receives its assigned time and radio setting, sends the report, receives the result, and returns to sleep.

Try a cold start, weak placement, a busy cell, a rejected request, repeated sending, and a lost reply. Check total awake time, number of attempts, final service delivery, and the power state after each case. A sent radio burst is not proof that the application received the report.

This trace does not predict every network or battery. The deeper sections name the physical channels, grants, repetitions, coverage changes, and field records needed to defend the access and energy claim.

NB-IoT does not let a low-power device transmit whenever it wants at whatever rate it chooses. The device first finds an NB-IoT cell, reads broadcast information, requests access, waits for a grant, sends a scheduled uplink, and then returns to its approved power state.

That sequence is why channel access belongs in the architecture review. A product can have a small payload and still waste battery if cell search, random access, grant waiting, repetitions, or retries keep the modem awake for too long.

Figure 5.1 is the checkpoint for overview: channel access makes nb-iot scheduled; its purpose is to show NB-IoT access flow from synchronization and broadcast information through NPRACH, NPDCCH scheduling, NPUSCH uplink, and NPDSCH response before a field claim is accepted. Inspect cell timing beside NPBCH / SIB before the next claim.

Figure 5.1 opens with Search, makes cell timing the intermediate check, and reaches NPBCH / SIB only after that check succeeds. This is the practical meaning of NB-IoT access flow from synchronization and broadcast information through NPRACH, NPDCCH scheduling, NPUSCH uplink, and NPDSCH response. It turns overview: channel access makes nb-iot scheduled into a sequence of reviewable records rather than one end-to-end assumption.

5.3 Practitioner: Approve the Grant You Measure

A deployment review should focus on what the serving network actually grants in representative locations. Firmware settings, module capability, and operator marketing claims are inputs; they are not enough to approve a fleet rollout.

The practical workflow is to separate access evidence from payload evidence, then join both to the current trace. That exposes whether the bottleneck is cell discovery, random access, grant latency, repetitions, retries, application acknowledgement, or return-to-sleep behavior.

5.3.1 Uplink Tone Modes

The learner-facing trade-off is straightforward: fewer tones can support more coverage-oriented operation, more tones can shorten a transfer when the link and cell allow it, and repetitions improve decodability at the cost of airtime and active current.

Bring Figure 5.2 into the review before uplink tone modes. The diagram identifies NB-IoT uplink tone modes showing 15 kHz multi-tone allocations, 15 kHz single-tone operation, 3.75 kHz single-tone operation, and hopping across the narrowband carrier, which the decision record must preserve.

Read 15 kHz multi-tone together with shorter airtime, needs adequate signal and grant in Figure 5.2, then use One scheduled tone concentrates to test the interpretation. The visual is establishing NB-IoT uplink tone modes showing 15 kHz multi-tone allocations, 15 kHz single-tone operation, 3.75 kHz single-tone operation, and hopping across the narrowband carrier. That test is the connection to uplink tone modes: evidence, limits, and retest triggers travel with the decision.

Mode

Role

Question

Evidence

15 kHz multi-tone

Higher-throughput uplink when the link and cell capacity allow it.

Does faster transmission reduce total active time, or does it cause too many retries?

Granted tones, repetition count, failed grants, and measured transfer current.

15 kHz single-tone

Coverage-oriented uplink while retaining LTE-compatible subcarrier spacing.

Does the narrower allocation improve delivery enough to offset longer airtime?

Packet delivery, grant latency, retries, and current trace in weak-signal locations.

3.75 kHz single-tone

Very narrow uplink operation for deeper coverage where supported.

Does the operator and device support it, and is the added airtime acceptable?

Support confirmation, granted spacing, repetitions, and timeout behavior.

Frequency hopping

Diversity against narrowband interference and fading.

Is packet loss caused by weak signal, interference, congestion, or sleep timing?

Interference survey, retransmission pattern, channel logs, and time-of-day failures.

Do not treat tone choice as a firmware toggle.

A product team may prefer single-tone operation for weak-signal devices or multi-tone operation for stronger links, but the final uplink resource is scheduled by the network. The field log should record the granted behavior, not just the intended configuration.

5.4 Under the Hood: Narrowband Gains Cost Time Awake

NB-IoT gains coverage by narrowing the radio resource and allowing repeated transmissions. That helps a weak receiver decode a message, but it also stretches the time a device spends searching, listening, transmitting, waiting, and retrying.

For a power budget, the main question is not the theoretical peak rate. The main question is how long the modem remains in high-current states for the complete transaction under the network behavior the device actually receives.