Satellite 5G phones will check for signal 8 times less often

Extending how rarely a phone needs to search for a satellite signal sounds like a small tweak, but it splits the room. Huawei, Apple, OPPO and TCL want the 160 ms period locked into the specification now; CMCC, Nokia, Ericsson and ZTE call that premature, with ZTE still pushing for 40 ms and 80 ms options CMCC and others haven't ruled out. The gap matters because satellites need the longer gap to spread power across more beams, but phones need clear rules for when to actually listen.

On the uplink side, satellite 5G will let 2 or 4 phones share the same resource block using orthogonal cover codes (OCC) — inter-slot coding using Hadamard sequences for the 4-user case. RAN1 explicitly rejected two more complex alternatives (intra-symbol pre-DFT OCC and a hybrid combination), keeping the design simple enough that network equipment, not the phone, handles grouping devices by frequency offset. The catch: what happens when a phone needs to send control information at the same moment it's using this shared uplink is unresolved. Nineteen companies including Ericsson, Huawei, Qualcomm and Apple want control data folded into the data channel across the whole OCC group — a fix that costs 0.1–0.4 dB in performance but keeps things running. Eight others, including MediaTek and Samsung, would rather drop the data transmission entirely and send control info separately. No vote settled it.

IoT devices over satellite get their own version of this capacity fight. 3GPP agreed OCC length 2 works for the 3.75 kHz and 15 kHz uplink channels using a fixed [1 1; 1 -1] sequence, but explicitly excluded the random-access channel (NPRACH) — the first connection attempt stays uncoded. A TDM reference-signal design for the narrower channel, transmitting in bursts over 4 slots with 2 slots blanked, is now waiting on RAN4 to confirm phones can hold stable phase through the gaps. Meanwhile Huawei, CATT, ZTE and eight others want multi-tone OCC support too, but InterDigital and Ericsson argue there's no time left this release, so RAN1 is prioritizing single-tone devices only.

A new TDD mode for satellite NB-IoT — sharing one frequency for both directions instead of the FDD split used today — got firmer footing. RAN1 fixed the guard period at 48–50 ms, matching the widest gap in the legacy Iridium system, and locked the downlink subframe pattern to a specific 8-of-9 arrangement. But the random-access method is still open: postpone transmissions that land in downlink slots, or invent new access periodicities aligned to the 90 ms TDD pattern. RAN1 also punted system-information scheduling conflicts to RAN2 entirely, since that's a protocol question, not a physical-layer one.

The random-access choice for satellite IoT TDD is due at RAN1#120bis; postponement versus new periodicities will decide how predictable — and how slow — a device's first connection attempt is. Separately, RAN2 is still waiting on RAN1 for a verdict on whether connected NB-IoT devices can receive earthquake and tsunami alerts over satellite at all, a question Huawei, Nokia, OPPO, Lenovo and Sony call infeasible for this release while ZTE, Xiaomi, Qualcomm and Viasat insist it's doable.