Direct to Cell Satellite Communication Fundamentals

5.1 Resource Allocation Principles for Shared Satellite Spectrum

Shared satellite spectrum means multiple users and services must share the same radio resources without stepping on each other. The core job of resource allocation is to decide who transmits, when they transmit, and at what rate, while keeping interference under control and meeting service requirements. Think of it as traffic control on a single-lane bridge: you can let more cars through only if you manage spacing, speed, and lane discipline.

Foundational Concepts for Shared Spectrum

Start with three constraints that shape every decision.

1. Interference is the limiting factor. In direct-to-cell satellite access, users in the same beam and frequency region can interfere. Allocation must reduce overlap in time, frequency, or power.
2. Propagation and scheduling latency matter. Round-trip time is longer than in terrestrial networks, so the system benefits from allocations that remain valid for a scheduling window.
3. User demand is uneven. Some users send small messages; others stream data. Allocation must avoid wasting capacity on low-need users while still serving them reliably.

A practical way to reason about allocation is to separate resource dimensions (time, frequency, code, power) from goals (throughput, latency, fairness, reliability). Each allocation policy chooses a trade-off.

Resource Dimensions and What They Control

• Time division (slotting): Limits how many users transmit simultaneously. It is simple and effective when interference dominates.
• Frequency division (subcarriers or channels): Reduces interference by separating users across frequency. It works well when channel conditions differ across users.
• Code division (if applicable): Uses different spreading or coding structures. It can improve spectral efficiency but increases receiver complexity.
• Power control: Adjusts transmit power to meet link quality while limiting interference. It is often constrained by terminal capability and regulatory limits.

In practice, systems combine these dimensions. For example, a scheduler may assign a time slot and frequency block, then apply power control within that assignment.

Allocation Inputs That Actually Matter

Resource allocation is only as good as its inputs. For direct-to-cell, the most useful inputs are:

• Queue state: How much data is waiting per user and per service class.
• Channel quality indicators: A proxy for expected SINR on candidate resources.
• Geometry and beam context: Users near beam edges often have worse link quality and different interference patterns.
• Service requirements: Latency tolerance and reliability targets determine whether the scheduler should spend resources on robust settings or higher rates.

A common mistake is to allocate purely on instantaneous channel quality. That can starve users with consistently poor conditions. A good scheduler uses channel quality but also accounts for waiting time and service class.

Core Principles for Systematic Allocation

Start with Interference Management

The first principle is to limit harmful overlap. If two users are likely to interfere strongly, the scheduler should avoid assigning them the same time-frequency region. This can be done through:

• Orthogonalization: Separate users in time or frequency when their interference coupling is high.
• Reuse planning: Use frequency reuse patterns across beams so that co-channel beams are sufficiently separated.

Match Modulation and Coding to the Assignment

Once a time-frequency region is chosen, select the modulation and coding scheme (MCS) based on expected SINR. The scheduler should prefer robust MCS for users with uncertain or low SINR, especially for latency-sensitive messaging.

Example: If User A reports stable SINR and User B reports fluctuating SINR, the scheduler can assign both the same time slot but choose different MCS levels. User B gets a lower rate with higher reliability, preventing repeated retransmissions that would otherwise consume shared resources.

Use Fairness That Respects Service Classes

Fairness should not mean “everyone gets the same.” Instead, fairness should be service-aware:

• For best-effort data, proportional fairness can balance throughput and waiting time.
• For urgent messages, priority scheduling can reserve a small fraction of resources.

A practical rule: allocate a baseline share to each active user or service class, then distribute remaining capacity based on channel quality and backlog.

Keep Scheduling Decisions Stable over the Validity Window

Because of longer propagation, the scheduler should avoid overly fine-grained decisions that become stale before they take effect. Use a scheduling window where channel estimates remain meaningful, and keep grant sizes aligned with expected traffic bursts.

Example: For periodic status updates, allocate recurring resources or semi-static grants. For sporadic traffic, use dynamic grants but keep them within a window that matches the system’s measurement-to-transmission timing.

Worked Example: Simple Beam Scheduler

Assume one beam with 12 resource blocks (RBs) per frame and three users:

• User 1: high SINR, large backlog, best-effort
• User 2: medium SINR, small backlog, best-effort
• User 3: low SINR, urgent message, latency sensitive

A systematic allocation could be:

1. Reserve 2 RBs for User 3 using robust MCS to meet latency.
2. Allocate the remaining 10 RBs using proportional fairness between Users 1 and 2.
3. Apply higher MCS to User 1 and a more conservative MCS to User 2.

Result: User 3 gets predictable delivery without forcing repeated retransmissions that would reduce overall throughput. Users 1 and 2 share the rest based on backlog and channel quality, so neither user is ignored.

Practical Checklist for Implementing Allocation

• Identify interference-prone user pairs and avoid co-channel overlap.
• Reserve a small, reliable resource slice for latency-sensitive traffic.
• Choose MCS per assignment using expected SINR, not optimism.
• Combine fairness with service class so waiting time is handled intentionally.
• Ensure grants remain valid for the scheduling window given measurement timing.

5.2 Beam Management and Coverage Partitioning for Mobile Users

Beam management is the practical art of deciding which users share which satellite resources, and when. Coverage partitioning is the planning side of that art: how the service area is split into manageable regions that align with beams, scheduling, and terminal behavior. Together, they keep link quality predictable enough to run a network without constant firefighting.

Foundational Concepts for Partitioning

Start with three inputs: user distribution, beam footprint geometry, and link budget margins. User distribution can be uneven even within a small area, such as a roadside corridor or a stadium. Beam footprints overlap, and overlap is not a bug; it is a tool for continuity. Link budget margins determine how much overlap you can afford before edge users become unreliable.

A useful mental model is to treat each beam as a “resource container” with a coverage region and a capacity budget. Partitioning assigns users to containers based on where they are likely to be during the next scheduling interval.

Coverage Partitioning Strategies

Single-beam assignment assigns each user to one beam at a time. It is simple and reduces cross-beam complexity, but it can cause abrupt changes near beam edges.

Multi-beam assignment allows a user to be served by more than one beam, either simultaneously or in a make-before-break sequence. This improves continuity but increases coordination needs and can raise interference or resource duplication if not controlled.

Overlapping-region partitioning explicitly defines overlap zones where the network expects handover activity. Instead of reacting only after quality drops, you predefine where decisions should occur.

A practical rule: choose partition boundaries so that the expected signal quality stays above the minimum threshold for at least one scheduling cycle after a boundary crossing. That prevents “ping-pong” behavior where a user flips beams every few seconds.

Beam Management Control Loop

Beam management typically runs as a loop:

1. Measure: the terminal reports reference signal quality and timing-related measurements.
2. Classify: the network maps measurements to candidate beams and determines whether the current beam remains acceptable.
3. Decide: the network selects the serving beam(s) and updates scheduling grants.
4. Execute: the radio layer applies the change with timing and buffering rules.

The key detail is that measurement-to-decision latency must be accounted for. If the terminal reports quality that is already outdated, the network may assign a user to a beam that is no longer the best choice.

Handover-Friendly Partition Boundaries

Partition boundaries should be defined using quality margins, not just geometry. Geometry tells you where beams overlap; quality tells you how usable that overlap is.

To make this concrete, consider a highway scenario. If the terminal moves quickly along the corridor, the network should use wider overlap zones along the corridor direction and narrower zones elsewhere. That reduces the number of handovers while keeping edge users above the minimum modulation and coding capability.

Scheduling Implications of Partitioning

Once users are assigned to beams, scheduling can be beam-local. Beam-local scheduling reduces coordination overhead and makes capacity planning easier. However, it can create unfairness if one beam becomes crowded while adjacent beams are underutilized.

A common mitigation is load-aware beam selection: when multiple beams are acceptable, the network prefers the beam with more available resource blocks. This is not about “fairness for its own sake”; it directly reduces packet delay and retransmissions.

Example: Partitioning for a Mixed Urban Corridor

Assume a satellite system with three overlapping beams covering an urban corridor and surrounding blocks. The corridor has higher user density because of offices and transit stops.

A workable partition plan:

• Define overlap zones primarily along the corridor direction.
• Use single-beam assignment in the outer blocks where density is low.
• Use multi-beam make-before-break only inside the corridor overlap zones to smooth transitions at beam edges.

Operationally, the network keeps a user on the current beam until the reported quality drops below a threshold that accounts for measurement latency. If two beams are both acceptable, it selects the beam with lower load to reduce queue buildup. The result is fewer handovers during stop-and-go movement and more stable throughput when users cluster near transit hubs.

Example: Avoiding Ping-Pong at Beam Edges

Ping-pong happens when a user repeatedly crosses a boundary faster than the system can settle. The fix is to combine three controls:

• Hysteresis: require a quality improvement before switching back.
• Time-to-trigger: wait a short duration before executing the change.
• Boundary placement: ensure the overlap zone covers the expected movement during the measurement-to-decision delay.

If you implement only hysteresis, a fast-moving terminal can still trigger repeated switches. If you implement only time-to-trigger, a slow terminal may stay on a degrading beam too long. Using all three makes the behavior stable and predictable, which is exactly what mobile users notice when they stop thinking about beams and start thinking about their app working.

5.3 Scheduling and Grant Strategies Under Variable Propagation Conditions

Direct to cell scheduling has a simple enemy: the radio channel changes while you’re trying to decide who transmits. In NTN, that change is driven by geometry (satellite motion), atmosphere, and beam edge effects. The scheduler’s job is to turn those variations into predictable service by combining three ideas: measure channel state, choose a grant that fits the moment, and adapt retransmissions when the moment was unlucky.

Foundational Inputs the Scheduler Needs

A practical scheduler starts with a small set of per-user measurements and constraints:

• Channel quality indicators such as SINR or an equivalent metric derived from reference signals.
• Timing and frequency uncertainty indicators, since Doppler and offset can reduce effective demodulation quality.
• Queue state for each logical flow, including how long packets have waited.
• Terminal capability such as maximum modulation and coding supported, and whether the terminal can handle higher HARQ rounds.
• Resource limits including available bandwidth per beam and any configured priority rules.

A useful mental model is to treat each grant as a bet: the scheduler chooses modulation/coding and allocation size based on what it believes the channel will support for that user during the grant’s effective time window.

Variable Propagation and Why It Breaks Naive Scheduling

If you schedule purely by “best current SINR,” you can starve users near beam edges. If you schedule purely by fairness, you may waste resources on low-probability decodes. Variable propagation creates both problems at once because the ranking of users changes quickly.

So the scheduler needs a policy that balances:

• Throughput efficiency (use resources where decoding is likely)
• Reliability (avoid repeated failures that burn HARQ budget)
• Fairness (prevent persistent disadvantage for edge users)
• Latency (avoid letting small packets wait behind large ones)

Grant Strategy: Choose Size, MCS, and Retransmission Behavior Together

A grant is more than “who gets time.” It includes how aggressively you transmit.

1. Initial transmission aggressiveness: pick modulation and coding based on the user’s estimated channel quality.
2. Grant size: allocate enough symbols to carry the payload without forcing excessive segmentation when the channel is poor.
3. HARQ coupling: if the system supports HARQ, the scheduler should reserve or prioritize resources for retransmissions so that failures don’t cascade into queue growth.

A simple rule that works well in practice: when propagation conditions worsen, reduce the payload per grant rather than only lowering MCS. Smaller payloads shorten the time the receiver needs to accumulate enough reliable information, which helps keep latency stable.

Scheduling Policy Under Changing Conditions

A common approach is to compute a priority score per user each scheduling interval. The score can combine:

• Expected spectral efficiency from the channel estimate
• Probability of successful decode for the chosen MCS
• Head-of-line delay for queued packets
• Service class weight (for example, messaging vs. bulk data)

Then the scheduler allocates resources to maximize a weighted objective. The key is that the “expected decode probability” must be tied to the propagation state, not just the raw SINR.

Beam-Aware and Time-Aware Allocation

Because direct to cell uses beams, treat the scheduler as having two layers:

• Beam layer: decide how much total resource each beam gets.
• User layer: within a beam, decide which users get grants.

Time awareness matters because the channel estimate is only valid for a short interval. If the scheduler’s interval is long relative to channel variation, it should be more conservative: use lower MCS and smaller grants to reduce the chance of HARQ-heavy outcomes.

Example: Two Users at Different Beam Positions

Assume one beam with 10 ms scheduling intervals. User A is near beam center, user B near the edge.

• At interval 1, A estimates SINR high enough for MCS 12 with high decode probability. B estimates low SINR; MCS 6 would decode with moderate probability.
• A naive “best SINR first” scheduler gives most resources to A. B’s small packets wait.
• A balanced scheduler computes priority including head-of-line delay. It gives B a smaller grant using MCS 6, enough to carry one message segment.

In interval 2, geometry shifts slightly and B’s SINR improves. The scheduler then increases B’s grant size and MCS, while A’s priority drops because its queue is already served. The result is that B experiences fewer long waits without forcing the system into repeated retransmissions.

Practical Checklist for Robust Scheduling

• Update channel-based priority frequently enough that grants match the estimate’s validity window.
• Tie MCS selection to decode probability, not just SINR ranking.
• When conditions degrade, prefer smaller payload grants plus lower MCS rather than only lowering MCS.
• Ensure retransmissions have a clear resource path so failures don’t turn into unbounded latency.
• Use beam-aware allocation so edge users are not permanently disadvantaged by center-heavy scheduling.

With these pieces aligned, the scheduler behaves like a careful dispatcher: it doesn’t try to guess the future perfectly, but it does make decisions that remain sensible when the channel refuses to stay still.

5.4 Handling Contention and Congestion in Direct to Cell Scenarios

Direct to Cell links share spectrum across many users and beams, so contention shows up as collisions, retransmissions, and queue buildup. Congestion shows up when the system can’t drain buffers fast enough, even if individual transmissions are “correct.” The practical goal is to keep the system stable: reduce wasted airtime, protect latency-sensitive traffic, and prevent buffer growth from turning into a reliability problem.

Core Concepts That Drive Contention

Contention begins at the moment multiple UEs try to transmit in overlapping resources. In a satellite direct-to-cell setting, the round-trip time is longer than in terrestrial networks, so feedback arrives later and retransmissions cost more airtime. Congestion then compounds the issue: if scheduling keeps granting resources to already-backlogged flows, the backlog grows and the channel spends more time on retries than on new successful deliveries.

A useful mental model is “airtime accounting.” Every failed attempt consumes airtime and increases waiting time for everyone else. If the scheduler keeps trying the same approach under load, the system becomes self-defeating.

Stepwise Strategy from Foundations to Advanced Details

1) Measure Load Where It Matters

Start by distinguishing “many users with little traffic” from “few users with heavy traffic.” Use beam-level load indicators (active UE count, grant utilization, retransmission rate) and queue indicators (pending bytes per bearer, HARQ occupancy). If you only look at throughput, you may miss rising latency caused by retries.

Easy example: In a beam where average SINR looks acceptable, but retransmissions jump from 5% to 25%, the system is already spending airtime on recovery. Throughput might still look okay for a moment, but latency will climb and congestion will follow.

2) Control Contention at the Entry Point

Random access and initial transmissions are where collisions are most expensive. Use contention-aware backoff so that when the system detects high collision probability, new attempts spread out instead of synchronizing.

Easy example: Suppose 200 UEs attempt to send a short status message after a power restoration event. Without tuned backoff, they pick similar timing windows and collide repeatedly. With adaptive backoff, the same 200 UEs spread their attempts across more frames, reducing collisions and lowering total airtime wasted.

3) Make Scheduling Load-Aware, Not Just Fair

Fairness alone can be harmful under congestion. If every UE gets a small slice, none of the slices are large enough to clear queues, especially for users at the edge of coverage. A better approach is “priority-aware fairness”: protect latency-sensitive flows while granting enough resources to clear at least some backlog per scheduling interval.

Concrete rule of thumb: if retransmission rate is rising, temporarily bias grants toward users with stable link quality and toward flows that can complete quickly. This increases successful deliveries per unit airtime and reduces the retry pile.

4) Use Link Adaptation to Prevent Retry Spirals

When link quality is variable, aggressive modulation and coding can increase error probability, which increases retransmissions, which increases congestion. Under load, choose a more conservative operating point so that the system spends less airtime on failed attempts.

Easy example: Two UEs have similar average SNR, but one has frequent fades due to movement. If both are scheduled with the same high-rate configuration, the moving UE triggers more HARQ failures. Reducing its rate slightly can improve overall beam efficiency because it stops generating repeated failures.

5) Bound Queues with Admission and Shaping

Congestion management is partly about preventing infinite waiting. Apply admission control for non-critical traffic and shape or cap per-flow queues so that one heavy sender can’t consume all scheduling opportunities.

Easy example: If background telemetry is allowed to queue indefinitely, it can occupy buffer space and delay emergency messaging. A simple per-bearer quota ensures that emergency traffic always has room to be scheduled and transmitted.

6) Manage Retransmissions with Practical Limits

HARQ can help, but it can also saturate. If too many retransmissions are pending, the scheduler keeps serving “old” packets while new packets wait. Use limits such as maximum retransmission attempts and fallback behavior that either reduces rate or switches to a more robust configuration.

Easy example: For short messages, after a small number of failed attempts, switching to a more robust configuration can be better than repeating the same configuration. The goal is to avoid spending multiple frames on a packet that is unlikely to succeed.

Example: A Beam Under Sudden Load

Assume a beam receives a burst of 1,000 short messages over a few seconds. The system observes rising grant utilization, increasing retransmissions, and growing UE queues.

1. Collision control: increase contention backoff for new access attempts.
2. Scheduling: prioritize flows that can complete quickly and reserve resources for priority messaging.
3. Link adaptation: reduce MCS for users with unstable measurements to lower error probability.
4. Queue management: cap background traffic queues and admit only a limited number of new background flows.
5. Retransmission limits: after a small number of failures, switch to a more robust configuration.

The expected outcome is not “maximum throughput at any cost,” but stable delivery: fewer retries, bounded latency for priority traffic, and queues that stop growing.

Quick Checklist for Operators and Engineers

• Track collision rate, retransmission rate, and queue growth separately.
• Tune contention backoff when collision probability rises.
• Use priority-aware fairness so edge users don’t starve, but the system also doesn’t stall.
• Choose conservative link adaptation under high load to avoid retry spirals.
• Bound queues with admission control and per-flow quotas.
• Apply retransmission limits with fallback behavior.

5.5 Practical Example: Designing a Resource Plan for a Given Coverage Footprint

You’re given a direct to cell coverage footprint shaped like an irregular polygon on the ground, plus a target service mix: small messages for IoT-like users and occasional larger data bursts for field staff. The goal of a resource plan is simple to state and tricky to execute: allocate radio resources so that most users meet their latency and reliability needs while the system stays stable when users cluster.

Step 1: Translate Coverage into Beam and Cell Geometry

Start by converting the ground footprint into the satellite’s beam layout. For each beam, compute which portion of the footprint it covers and how the beam edge affects link quality. A practical rule is to treat the beam edge as a “quality gradient” zone rather than a hard boundary.

Example: Suppose the footprint spans three beams: Beam A covers 45%, Beam B covers 40%, Beam C covers 15%. If Beam C is mostly edge-of-beam, assume its effective throughput is lower even if the geometry says it covers users. You’ll reflect that later in scheduling weights.

Step 2: Define Traffic Classes and Their Resource Demands

Create traffic classes with clear radio implications. For instance:

• Class M: small messages, strict latency, low payload.
• Class D: data bursts, moderate latency, higher payload.
• Class S: signaling and keep-alives, very small payload, frequent.

Assign each class a target performance profile: maximum acceptable delay, minimum reliability, and typical packet size. Then translate those into required link adaptation margin. If Class M must succeed quickly, it needs more robust modulation and coding or more retransmission budget.

Step 3: Choose a Scheduling Strategy That Matches the Footprint

Resource planning depends on how you share resources among users within a beam. A common approach is time-frequency scheduling with per-user grants, but you must decide how to handle contention.

A workable baseline:

• Reserve a small fraction of resources for Class S so control traffic doesn’t get stuck behind user data.
• Use priority-aware scheduling for Class M to protect latency.
• Allow Class D to use remaining capacity with a cap on how much it can consume per scheduling interval.

Example: If the beam has 100 resource units per frame, allocate 10 units to Class S, 50 to Class M, and 40 to Class D. If Class M demand drops, unused units can be borrowed by Class D, but only up to a defined limit to prevent starvation.

Step 4: Build a Link Quality Map and Convert It to Weights

For each beam, estimate expected signal quality distribution across the footprint. Use a link-quality metric such as expected SINR bins. Then convert those bins into scheduling weights.

Example: In Beam B, assume 60% of users are in a “good” bin, 30% in “fair,” and 10% in “edge.” If edge users require roughly 2× more robust coding to meet reliability, you can reflect that by giving edge users a larger share of grants per successful message attempt. The exact factor comes from your link adaptation curves, but the planning method stays the same.

Step 5: Apply a Load Model and Check Stability

Now combine geometry, traffic demand, and weights into a load estimate per beam. You’re checking whether the system can serve the offered load without persistent queue growth.

A simple stability check:

1. For each class, compute expected resource consumption per user per interval.
2. Multiply by expected active users in each quality bin.
3. Sum across bins and classes.
4. Ensure the total expected consumption stays below available resources, with headroom for variability.

Example: Beam A has 200 active users, mostly in good quality. Beam C has 60 active users but mostly edge quality. Even with fewer users, Beam C may consume more resources per successful delivery, so you might increase its reserved share or reduce its Class D cap.

Step 6: Produce the Resource Allocation Plan

The output should be operational, not theoretical: per beam, per class, per quality bin. Keep it explicit so you can test it.

Example Resource Plan Table (illustrative numbers):

Interpretation: Beam C gets a slightly higher signaling reserve and a larger share for latency-sensitive messages, while Class D is constrained to prevent edge users from being overwhelmed.

Step 7: Validate with Two Concrete Scenarios

Scenario 1: Uniform user distribution across the footprint.

• Expect Beam A and B to carry most Class D.
• Confirm Class M meets delay targets without excessive retransmissions.

Scenario 2: Clustered users in the beam edge zone.

• Expect increased resource use in edge bins.
• Confirm the plan’s caps prevent queue buildup for Class M and signaling.

If either scenario fails, adjust one lever at a time: class shares first, then borrowing rules, then quality-bin weights. This keeps the debugging process sane—like using a map instead of guessing which way “feels right.”

6.1 Physical Layer to MAC Layer Responsibilities in Satellite Links

Satellite links behave like a long, moving hallway: signals travel far, arrive late, and shift in frequency as the spacecraft moves. Because of that, the physical layer and MAC layer must cooperate tightly, with each layer owning specific jobs and exposing the right knobs to the next layer.

Physical Layer Responsibilities

The physical layer turns bits into radio wave behavior and back again. In satellite direct-to-cell links, its responsibilities include:

• Modulation and Demodulation: Choose a modulation scheme that matches the expected signal quality. For example, if the link margin is tight, the system may use a more robust modulation so the receiver can still recover symbols.
• Forward Error Correction: Apply coding that can correct errors without waiting for retransmissions. A practical example is using a code rate that trades throughput for reliability when the channel is harsh.
• Channel Estimation and Equalization: Estimate how the channel distorts the signal. In satellite links, this includes coping with time-varying effects caused by motion and propagation.
• Timing and Frequency Recovery: Estimate and correct timing offset and carrier frequency offset. Doppler causes frequency drift, so the receiver must track it continuously.
• Power and Beam Awareness Hooks: Provide measurements such as received signal strength, error vector magnitude, or block error indicators. These metrics become inputs to MAC decisions.

A useful way to think about the physical layer is: it produces reliable “deliverability signals”. Not just bits, but also quality indicators that tell MAC whether it should schedule more aggressively, back off, or request retransmission.

MAC Layer Responsibilities

The MAC layer decides who transmits, when they transmit, and how transmissions are packaged for the physical layer. In satellite links, its responsibilities include:

• Channel Access and Scheduling: Coordinate multiple users sharing the same satellite resources. For a simple example, if two users transmit simultaneously in the same time-frequency slot, their signals collide; MAC prevents that by assigning distinct resources.
• Transport Unit Framing: Map higher-layer packets into MAC transport blocks sized for the physical layer. This includes respecting constraints like maximum payload size and coding block structure.
• Link Adaptation Control: Select modulation and coding parameters based on physical-layer feedback. Example: if the receiver reports rising block error rates, MAC can request a more robust configuration.
• Retransmission Strategy: Manage retransmissions when errors remain after coding. Because satellite round-trip time is long, MAC must avoid overly chatty retransmission loops.
• HARQ Coordination: Coordinate hybrid automatic repeat request behavior, including what constitutes an acknowledgment, negative acknowledgment, or implicit success.
• Buffering and Queueing: Handle variable arrival rates from the core network and variable service opportunities due to scheduling.

In short, MAC owns resource discipline. It keeps the shared channel from turning into a group project where everyone talks at once.

The Handoff Between Physical and MAC

The boundary between layers is where most practical bugs live, so it helps to be explicit about the interface:

1. Physical Layer → MAC: Quality and outcome metrics.
   • Example metrics: block success/failure, estimated SNR, timing error magnitude, and frequency offset estimates.
2. MAC → Physical Layer: Transmission configuration and transport block parameters.
   • Example parameters: modulation and coding selection, transmit power targets, and transport block size.

A systematic workflow for one transmission opportunity looks like this:

• MAC schedules a user and chooses a transport block size.
• MAC requests a physical-layer configuration (modulation/coding) consistent with expected channel quality.
• The physical layer transmits and later reports whether blocks were decoded successfully.
• MAC uses the outcome to update scheduling priorities and decide whether to retransmit.

Example: Scheduling with Physical Feedback

Assume a direct-to-cell system assigns a user a downlink slot. The physical layer decodes the received transport block and reports a block error indicator plus an estimated quality metric.

• If decoding succeeds consistently, MAC can schedule the user more frequently or allocate larger transport blocks.
• If decoding fails intermittently, MAC can reduce transport block size and request a more robust modulation/coding configuration.
• If failures persist, MAC can trigger retransmission behavior while also lowering the user’s priority to protect overall throughput.

This example shows why both layers must be precise: physical-layer metrics must be trustworthy enough for MAC to act, and MAC must translate those actions into valid physical-layer configurations.

Example: Why Retransmission Timing Matters

Satellite round-trip time is long, so MAC cannot treat retransmissions like a fast local link. If MAC retransmits too aggressively, it can waste resources on transmissions that would have succeeded with a slightly different physical configuration. If it retransmits too conservatively, queues build up and latency grows. The practical balance comes from physical-layer feedback: MAC uses decoding outcomes and quality trends to decide whether to retransmit, adapt, or reschedule.

6.2 HARQ Concepts and Retransmission Behavior Under Latency Constraints

HARQ—Hybrid Automatic Repeat reQuest—combines forward error correction with selective retransmissions. In direct-to-cell satellite links, the “hybrid” part matters because you often have enough redundancy to recover many corrupted packets immediately, but not all of them. The “repeat” part matters because retransmissions are expensive when round-trip time is long.

Core Idea of HARQ in One Pass

A typical HARQ flow sends a transport block (TB) with coding redundancy. The receiver attempts decoding right away. If decoding succeeds, it sends an acknowledgment. If decoding fails, it requests retransmission, usually using incremental redundancy so the second transmission adds useful information rather than repeating the same bits.

The key design tension is simple: retransmissions improve reliability, but they consume time and radio resources. Under satellite latency, waiting for a negative acknowledgment can stall the pipeline, so the system must be careful about when it decides to retransmit and how many times it does.

Timing Constraints That Shape Retransmission

In terrestrial systems, HARQ can often react quickly enough to keep the scheduler busy. In satellite direct-to-cell scenarios, the feedback loop is slower. That means:

• The transmitter may have already scheduled subsequent transmissions before it knows whether earlier ones succeeded.
• The receiver’s feedback arrives late, so the transmitter must buffer state for multiple in-flight HARQ processes.
• Retransmission decisions must be made with limited knowledge of what will succeed, so the protocol relies on explicit feedback and strict process identifiers.

A practical consequence is that HARQ behaves like a pipeline with multiple “slots.” Each slot corresponds to a HARQ process, and each process tracks redundancy versions, acknowledgments, and whether the maximum number of attempts has been reached.

HARQ Process Structure and Redundancy Versions

HARQ processes prevent confusion when multiple packets are in flight. Each process is associated with a specific transport block and a sequence of redundancy versions (RVs). A common pattern is:

1. Send RV0.
2. If decoding fails, send RV1 or RV2 that reuses the same code structure but with different parity contributions.
3. Continue until success or until the attempt limit is reached.

Incremental redundancy is efficient because the second transmission is not wasted even if the first attempt failed. It also reduces the probability that a retransmission is “all or nothing” compared to repeating identical bits.

A Mind Map of HARQ Behavior Under Latency

Retransmission Outcomes and Their System-Level Effects

When HARQ succeeds on the first attempt, latency is minimal and radio resources are used efficiently. When it succeeds after one or more retransmissions, latency increases roughly by the feedback and retransmission timing, and the scheduler must allocate additional grants.

If decoding fails after the maximum number of attempts, the transport block is dropped. The higher layers then decide what to do next—often by retransmitting at a different layer or by accepting loss for certain message types. This separation is important: HARQ is tuned for radio reliability, while upper layers handle end-to-end delivery semantics.

Example: Messaging with Tight Latency Budget

Assume a messaging service where each user message should be delivered quickly, but occasional loss is acceptable only if it doesn’t cause long waits.

• The system configures HARQ with a small attempt limit to avoid long stalls.
• The receiver uses decoding results to send feedback as soon as possible.
• The transmitter schedules new transmissions in other HARQ processes while waiting for feedback.

Concrete behavior:

• If the first transmission decodes successfully, the message is delivered with one transmission grant.
• If it fails, the message is delivered after a retransmission grant, but only for the affected HARQ process.
• If it fails repeatedly until the attempt limit, the message is dropped at the radio layer, and the application layer can decide whether to retry immediately or report failure.

This setup prevents a single bad link moment from locking the entire scheduling pipeline.

Example: Incremental Redundancy vs Repetition

Consider two strategies for a failed TB:

• Repetition: retransmit the exact same coded bits.
• Incremental redundancy: retransmit additional parity that complements the first attempt.

With incremental redundancy, the receiver’s second decoding attempt has more independent information, so the probability of success increases more smoothly. With repetition, the receiver may gain less new information, which can lead to either quick success or repeated failure depending on the channel realization.

In latency-constrained satellite links, incremental redundancy is usually the more predictable choice because it maximizes the value of each retransmission grant.

Practical Design Rules for Latency-Constrained HARQ

1. Keep the number of HARQ attempts bounded so NACK storms do not dominate time.
2. Use multiple HARQ processes to maintain a pipeline even when feedback is delayed.
3. Prefer incremental redundancy so each retransmission has measurable decoding benefit.
4. Ensure strict process identification so ACK/NACK feedback updates the correct transport block.
5. Align HARQ behavior with upper-layer expectations so dropped TBs do not cause silent, long delays.

When these rules are followed, HARQ becomes a controlled trade: it improves reliability without turning latency into a hostage situation.

6.3 RLC and PDCP Functions Including Segmentation and Reordering

RLC and PDCP sit between the radio bearer and the IP layer, translating “what the radio can deliver” into “what higher layers expect.” In direct-to-cell satellite links, the translation has to handle two realities at once: variable delay and occasional out-of-order delivery caused by propagation changes and scheduling.

Foundational Roles of RLC and PDCP

PDCP (Packet Data Convergence Protocol) focuses on functions that are mostly independent of the exact radio scheduling, such as header compression, ciphering, and sequence-number-based delivery control. RLC (Radio Link Control) focuses on reliable transfer over a bearer, including segmentation, reassembly, and retransmission behavior.

A useful mental model: PDCP is the “session-aware translator,” while RLC is the “radio-aware courier.” PDCP assigns sequence numbers to PDUs so the receiver can place them in order. RLC then breaks large PDUs into smaller pieces that fit the transport blocks and reassembles them at the receiver.

Segmentation: Making Big Packets Fit Small Radio Pieces

Segmentation happens when a PDCP PDU is larger than what the MAC can carry in a single transmission. RLC splits the payload into multiple RLC data segments, each mapped to a radio transmission opportunity.

Key detail: segmentation is not just slicing bytes. RLC must preserve enough information to reassemble the original PDCP PDU correctly. That means each segment carries identifiers and offsets so the receiver can reconstruct the exact byte sequence.

Example: Suppose PDCP produces a 1200-byte PDU, but the radio can carry 400 bytes per transmission. RLC segments it into three parts: 400 + 400 + 400. If the second segment arrives first, the receiver buffers it until the first and third segments arrive, then reassembles the full 1200-byte unit.

In satellite NTN, segmentation also interacts with latency. More segments mean more opportunities for scheduling delays and more buffering at the receiver. That’s why RLC configuration should align with expected transport block sizes and typical scheduling granularity.

Reordering: Putting Pieces Back in the Right Sequence

Reordering occurs when segments or PDCP PDUs arrive out of order. This can happen when different transmissions experience different effective delays, or when retransmissions are scheduled later than the original attempt.

RLC reordering is primarily about reassembling segments into the correct PDCP PDU. PDCP reordering is about ordering PDCP PDUs for delivery to upper layers.

Example: Two PDCP PDUs, A and B, are sent in sequence. Due to link dynamics, B’s segments arrive before A’s. PDCP uses sequence numbers to hold B until A is available, ensuring the application sees A then B.

This “hold until missing data arrives” is not free. It trades ordering correctness for buffering and potential delay. In practice, the system uses timers and thresholds to decide when to release what it has.

How RLC and PDCP Work Together

RLC and PDCP coordinate through sequence numbering boundaries. PDCP sequence numbers identify PDCP PDUs. RLC segmentation identifiers identify how a PDCP PDU is split across radio transmissions.

When RLC reassembles a complete PDCP PDU, it passes it upward to PDCP. PDCP then decides whether it can deliver it immediately or must wait for earlier sequence numbers.

The result is a two-stage pipeline:

1. RLC stage: ensure bytes for each PDCP PDU are complete and correctly ordered within that PDU.
2. PDCP stage: ensure PDCP PDUs are delivered to upper layers in sequence.

Practical Walkthrough with a Timing Twist

Consider a direct-to-cell scenario where the UE transmits two PDCP PDUs, A then B. RLC segments each PDCP PDU into multiple radio-sized pieces.

1. Transmit: RLC sends A1, A2, A3 and then B1, B2, B3.
2. Receive: Due to scheduling and propagation changes, B2 arrives early.
3. RLC action: RLC buffers B2 until B1 and B3 (or the missing parts) arrive, then reassembles B.
4. PDCP action: PDCP sees that A is still incomplete or not yet delivered, so it holds B until A is ready.
5. Release: Once A is reassembled and delivered in order, PDCP releases A then B to the upper layer.

This sequence shows why segmentation and reordering must be treated as a coordinated system. RLC can be “perfect” at reassembly while PDCP still delays delivery to preserve ordering.

Configuration Implications for Satellite NTN Links

Segmentation granularity affects buffering pressure at the receiver. Reordering behavior affects how long PDCP waits for missing sequence numbers. Together, these choices influence user-perceived latency and reliability.

A practical rule of thumb: if your link frequently produces out-of-order arrivals, you should expect PDCP buffering to matter more than raw retransmission counts. If your transport block sizes are small relative to typical PDCP PDU sizes, segmentation overhead and reassembly delay will dominate.

In short, RLC and PDCP turn an imperfect radio delivery pattern into a consistent byte stream for applications—by splitting large units, reassembling them correctly, and enforcing delivery order with sequence numbers.

6.4 Packet Loss and Out of Order Delivery Handling Strategies

Packet loss and out of order delivery are normal side effects of satellite access links: propagation delay is large, retransmissions take time, and mobility plus Doppler can cause occasional decoding failures. The goal is not to “avoid” loss entirely, but to handle it predictably so upper layers see stable service behavior.

Foundational View of What Goes Wrong

At the receiver, a packet can be lost for several reasons: the radio frame fails decoding, the MAC grant is missed, or the link layer discards due to buffer limits. Out of order delivery happens when later packets arrive successfully while earlier ones are delayed or retransmitted. In direct-to-cell scenarios, this is especially noticeable during beam edge transitions or when the terminal’s timing and frequency estimates briefly drift.

A practical way to reason about this is to separate three layers of responsibility:

• Radio and link reliability: decide whether to retransmit and how many times.
• In-order delivery mechanisms: decide whether to reorder or tolerate gaps.
• End-to-end transport behavior: decide how to react to missing data.

Link Layer Tactics for Loss

HARQ behavior is the first line of defense. When a transport block fails CRC, the receiver sends a negative acknowledgment (or equivalent status) and the transmitter schedules a retransmission. The key is to treat HARQ as a bounded reliability mechanism: too many retries waste time and can worsen perceived latency.

A concrete example: suppose a messaging packet is segmented into two transport blocks. The first block fails CRC, the second succeeds. With HARQ, only the failed block is retransmitted. If the receiver’s reassembly waits for the missing block, the message delivery is delayed but still correct. If the system instead delivers partial data immediately, the application might see corrupted or incomplete content. So the link layer should align with the segmentation model used by the higher layers.

Duplicate handling matters because retransmissions can arrive after the original packet was already accepted by the receiver. Sequence numbers and HARQ process identifiers allow the receiver to recognize duplicates and discard them without confusing reordering logic.

Reordering Strategies for Out of Order Delivery

Out of order delivery is best handled with a small reordering buffer and a clear policy for when to release data.

A typical policy:

1. Maintain an expected sequence number.
2. Store successfully received packets that are ahead of the expected number.
3. When the missing packet arrives, release the contiguous run.
4. If the buffer fills or a timer expires, release what you have and mark gaps.

Example: packets 10, 11, 13 arrive, but 12 is lost. The receiver buffers 13 while waiting for 12. If 12 is recovered via retransmission, packets 10–13 are released in order. If 12 never arrives within the timer window, the receiver releases 10–11 and then 13 with a gap indication so upper layers can decide whether to request retransmission or tolerate the loss.

This is where “gap-tolerant” behavior becomes important. For some services, missing data can be handled by higher layers using their own retransmission or error recovery. For others, the link layer must ensure completeness before delivery.

Coordinating with Segmentation and Reassembly

Satellite links often use segmentation to fit payloads into radio transport blocks. That means a single application packet may map to multiple link-layer units. If one segment is lost, reassembly cannot complete.

A systematic approach is:

• Use sequence numbers at the segment level so the receiver can detect missing segments.
• Use reassembly timers that match the expected round-trip time plus scheduling variability.
• Apply discard rules when reassembly buffers overflow, so stale partial data does not block newer traffic.

Example: an application message is split into segments A, B, C. A and C arrive, B is lost. The receiver starts a reassembly timer when A arrives. If B is recovered before the timer expires, the message is delivered once. If not, the receiver discards the partial message and signals loss upward, preventing the application from waiting indefinitely.

Practical Parameter Choices Without Guesswork

Parameter selection should be driven by measurable constraints:

• Latency budget: how long you can wait for missing data before it becomes useless.
• Buffer size: how many out-of-order packets you can store.
• Retransmission budget: how many HARQ attempts you allow before giving up.

A simple tuning exercise: start with a conservative reordering timer that covers typical retransmission delay under normal mobility. Then verify behavior at beam edge by checking whether gaps frequently trigger timer expiry. If they do, increase timer slightly or reduce how aggressively you buffer ahead-of-expected packets.

End-to-End Interaction with Transport Behavior

Even with link-layer reliability, some losses will remain. Upper layers must interpret them correctly. If the transport protocol expects in-order delivery, frequent out-of-order releases can trigger unnecessary retransmissions or congestion responses.

So the receiver should ensure that reordering and gap signaling are consistent: either deliver in order whenever possible, or deliver with explicit gap handling so the transport layer can react based on real missing data rather than timing artifacts.

In practice, the best results come from aligning three decisions: HARQ retry limits, reordering buffer policy, and reassembly timers. When those are consistent, packet loss looks like “missing data” rather than “random chaos,” and the system behaves like a predictable machine instead of a guessing game.

6.5 Practical Example: Selecting Coding and Retransmission Parameters for Messaging

You’re designing a direct-to-cell messaging service where small packets (text, status updates, or sensor readings) must arrive reliably even when the satellite link is noisy and latency is non-trivial. The goal is to pick coding and retransmission settings that match the link’s behavior without wasting airtime.

Step 1: Start with What You Can Measure

Before choosing parameters, define three inputs:

• Packet size and payload structure: e.g., 200-byte payload plus headers.
• Latency budget: e.g., “deliver within 10 seconds” for user-visible messages.
• Channel variability: e.g., you expect frequent fades near beam edges and occasional deep fades.

A practical way to estimate variability is to collect SNR or BLER vs. time from test logs or field measurements. If you don’t have that yet, use a conservative assumption: BLER will be higher at beam edges and during mobility.

Step 2: Choose Coding Strategy Based on Error Patterns

For messaging, you typically want strong forward error correction (FEC) so that most packets succeed without retransmission. The trade is that stronger coding reduces throughput but increases success probability.

Use this rule of thumb:

• If your latency budget is tight, prefer more FEC and fewer retransmissions.
• If airtime is scarce but latency is flexible, prefer moderate FEC and retransmissions.

Concrete example assumptions:

• Payload: 200 bytes
• Target: high delivery probability
• Expected BLER at chosen modulation: around 0.2 in good conditions and 0.6 in bad conditions

If BLER is already high, coding must do more work. You can model the effect of coding by thinking in terms of “effective BLER after FEC.” For instance, moving to a stronger code might reduce BLER from 0.6 to 0.2 in bad conditions.

Step 3: Compute Retransmission Budget from Latency

Retransmission adds time. In a satellite link, the round-trip time is dominated by propagation plus scheduling delays. So you should cap the number of retransmissions.

Example timing:

• One-way propagation plus processing: ~1.5 seconds
• Scheduling and processing overhead per attempt: ~0.2 seconds
• Round-trip per retransmission opportunity: ~3.4 seconds

If your latency budget is 10 seconds, then:

• Initial transmission: attempt 1
• Retransmissions: at most 2 (attempts 2 and 3)

So you might set max retransmissions = 2 (meaning up to 3 total transmissions).

Step 4: Pick Parameters Using a Simple Success Probability Model

Let p be the probability a packet succeeds on one transmission attempt. If BLER is the failure probability, then p = 1 − BLER.

In good conditions:

• BLER = 0.2 → p = 0.8
• With max retransmissions = 2, success probability is:
  • P(success) = 1 − (1 − p)^3 = 1 − (0.2)^3 = 0.992

In bad conditions:

• Suppose stronger coding reduces BLER from 0.6 to 0.2 → p = 0.8 again
• You get the same 0.992 success probability.

If stronger coding is not enough and BLER stays at 0.4 → p = 0.6:

• P(success) = 1 − (0.4)^3 = 0.936

This is the key decision point: if you can afford stronger coding, it often beats relying on retransmissions that may not fit the latency budget.

Step 5: Validate with Airtime Efficiency

Retransmissions consume resources. If you choose parameters that cause frequent retransmissions, you’ll see congestion and queueing, which then increases latency further.

A practical check is to estimate expected transmissions:

• Expected number of attempts ≈ 1 + failure probability + failure probability squared
• In good conditions with BLER 0.2: 1 + 0.2 + 0.04 = 1.24 attempts
• In bad conditions with BLER 0.2 after stronger coding: also 1.24 attempts

That’s a manageable overhead. If BLER were 0.4: 1 + 0.4 + 0.16 = 1.56 attempts, which can start to strain scheduling.

Step 6: Mind Map of the Decision Flow

Step 7: Final Parameter Set for the Messaging Example

A reasonable integrated choice for the scenario above:

• Coding: select a stronger FEC mode that targets post-FEC BLER ≈ 0.2 in both good and bad conditions.
• Retransmissions: set max retransmissions = 2, allowing up to 3 total transmissions.
• Scheduling behavior: keep retransmission grants predictable so the second and third attempts actually occur before the latency budget expires.

If your measurements show that post-FEC BLER cannot be pushed near 0.2 in bad conditions, then you should either reduce the modulation/coding rate (to lower BLER) or reduce the payload size (to reduce the probability of failure per packet). The model stays the same; only the knobs change.

Step 8: Quick Worked Summary

• Latency budget: 10 seconds
• RTT per attempt: ~3.4 seconds
• Max retransmissions: 2
• Target BLER after coding: ~0.2
• Success probability: 1 − (0.2)^3 = 0.992
• Expected attempts: 1 + 0.2 + 0.04 = 1.24

That combination gives high delivery probability without relying on too many retransmissions that would arrive late or overload the scheduler.

7.1 Timing Advance and Synchronization Requirements for NTN

Direct-to-cell NTN links behave like terrestrial links that forgot to stay still. The satellite moves, the propagation delay changes, and the user terminal can be anywhere from a few meters to a few hundred kilometers of slant range away. Timing advance (TA) and synchronization are the tools that keep uplink transmissions aligned enough for the network to decode them reliably.

Core Timing Concepts for NTN

Timing advance is the network’s way of compensating for variable propagation delay so that the terminal’s uplink arrives near the expected time at the receiver. In practice, the receiver does not “wait for the signal”; it correlates and demodulates within a timing window. If the window is missed, the signal energy spreads across symbols and the error rate rises.

Synchronization in NTN has two layers. First is time and frequency alignment so that demodulation reference signals line up. Second is link-specific timing control so that scheduling grants map to the correct physical resources. TA mainly addresses the first layer’s time component, while frequency offset handling and reference signal tracking support the second.

Why Timing Advance Is Harder in Space

In terrestrial networks, propagation delay changes slowly with mobility. In NTN, delay changes continuously because the satellite’s position relative to the user changes. Even if the terminal is stationary, the slant range changes, so TA must track the dynamics.

A second complication is that the network may not have perfect knowledge of the terminal’s position. TA computation depends on estimated range and timing reference assumptions. If the terminal location estimate is off, TA will be biased, and the residual timing error will remain.

Timing Advance Workflow

A practical NTN TA workflow looks like this:

1. The terminal acquires downlink timing and frequency using synchronization signals and reference signals.
2. The terminal measures timing-related quantities needed to infer the uplink arrival time at the gateway or gNB receiver.
3. The network provides TA commands or TA parameters tied to the current timing reference and scheduling context.
4. The terminal applies TA to its uplink transmission timing so that the uplink lands in the receiver’s expected window.
5. The terminal continues tracking and updates TA as the satellite geometry changes.

The key is that TA is not a one-time setting. It is a control loop with measurement, computation, and application.

Example: TA Calculation with Residual Error

Assume the network expects the uplink to arrive after a nominal propagation delay \( T_{nom} \). The terminal estimates the actual delay as \( T_{est} \) and applies TA to shift its transmit time by

\[ TA = T_{est} - T_{nom}. \]

If the estimate is imperfect by \(\Delta T = T_{actual} - T_{est}\), then the residual timing error at the receiver is \(T_{actual} - (T_{nom} + TA) = \Delta T\). If \(\Delta T\) is small relative to the receiver’s timing tolerance, decoding works. If \(\Delta T\) grows, the receiver’s correlation peak broadens and the demodulator sees effectively lower signal-to-noise.

A concrete way to think about tolerance is to compare \(\Delta T\) to a fraction of the OFDM symbol duration. When residual timing error approaches a significant fraction of the cyclic prefix budget, inter-symbol interference and loss of orthogonality start to dominate.

Synchronization Requirements Beyond TA

Even with perfect TA, frequency mismatch can ruin coherent demodulation. Doppler shifts change the carrier frequency as the satellite moves, and the terminal oscillator adds additional offset. The receiver relies on reference signals to estimate and correct frequency. If reference signal quality is poor, TA updates may be technically correct but practically ineffective because the terminal’s timing measurements are noisy.

Practical Implementation Checks

A stable NTN TA system usually shows three observable behaviors during operation:

• Timing error distribution stays centered near zero with limited spread, indicating that TA bias is controlled.
• Uplink demodulation success rate improves when TA updates are applied, showing that the control loop is doing useful work.
• Reference signal quality remains sufficient during TA updates, preventing noisy measurements from feeding the loop.

When these conditions fail, the first suspect is often not the TA formula but the measurement chain: reference signal reception, beam association context, and the freshness of the timing reference used for TA computation.

7.2 Frequency Offset Estimation and Correction Under Doppler Dynamics

Frequency offset in direct-to-cell satellite links is rarely a single, fixed number. Doppler shifts change with relative motion, and the user terminal’s oscillator adds its own drift. The receiver’s job is to estimate the instantaneous offset well enough to keep demodulation stable, then correct it in real time.

Core Ideas Before the Math

A Doppler shift moves the received carrier frequency away from what the receiver expects. If the offset is large, the demodulator’s local oscillator no longer matches the incoming signal, causing constellation rotation, degraded correlation, and ultimately higher error rates.

In practice, the receiver treats the total offset as:

• Doppler component that varies with time due to geometry and motion.
• Clock/oscillator component that varies more slowly but still drifts.
• Residual component after correction, which should be small enough for the chosen modulation and coding.

A useful mental model is a “tracking loop”: estimate offset from received pilots or reference signals, update a correction oscillator, and repeat often enough that the residual stays within tolerance.

Step 1: Separate Capture from Tracking

Most receivers use two stages.

Coarse acquisition finds an offset within a wide capture range. A common approach is to try a grid of candidate frequency hypotheses, correlate with known reference symbols, and pick the hypothesis that maximizes correlation magnitude. This stage is tolerant of noise but doesn’t need precision.

Fine tracking refines the estimate continuously. Here, the receiver uses the fact that a frequency offset produces a predictable phase change over time. If you observe the reference signal phase at two instants separated by \(\Delta t\), the phase difference \(\Delta\phi\) relates to frequency offset \(\Delta f\) by:

\[\Delta f \approx \frac{\Delta\phi}{2\pi\Delta t}\]

This is the “phase slope” idea: frequency offset becomes a slope in phase versus time.

Step 2: Estimate Doppler as a Time-Varying Quantity

Doppler dynamics are often smooth over short intervals. A practical receiver assumes the offset is approximately constant over a small window, then updates. If the window is too long, the assumption breaks and residual error grows.

A more robust method models the offset as piecewise linear over short segments. You estimate an initial offset and a rate term (how fast it changes). Even a simple linear model can reduce residual rotation during the segment.

A concrete example: suppose your reference symbols arrive every 1 ms. If the Doppler changes enough that the offset drifts by 50 Hz over 10 ms, then using a 10 ms window for fine estimation may leave a noticeable residual. Using 1–2 ms windows keeps the drift small, at the cost of more frequent updates.

Step 3: Correct Using a Numerically Controlled Oscillator

Correction is typically implemented by mixing the received signal with a complex exponential at the estimated offset. In digital form, an NCO advances phase by \(2\pi\hat{f} / f_s\) each sample.

The key design choice is loop bandwidth. If the loop updates too slowly, residual offset remains large and demodulation suffers. If it updates too quickly, it chases noise in the phase measurements, injecting jitter.

A simple rule of thumb is to set the update interval so that the expected Doppler change between updates is smaller than the receiver’s tolerable residual frequency error. For many modulation schemes, this tolerable residual is tied to how much constellation rotation you can accept over one symbol.

Example: Phase-Slope Estimation with Pilot Spacing

Assume:

• Pilot phase is measured at \(t_0\) and \(t_1\).
• \(\Delta t = 2\text{ ms}\).
• Measured phase difference \(\Delta\phi = 0.628\text{ rad}\).

Then: \[\Delta f \approx \frac{0.628}{2\pi\cdot 0.002} \approx 50\text{ Hz}\]

If your receiver corrects by mixing out 50 Hz, the remaining residual should be closer to zero. If you still see rotating constellations, the residual likely comes from either an incorrect window assumption (Doppler not constant) or timing misalignment that biases phase measurements.

Step 4: Guard Against Timing-Frequency Coupling

Timing errors can bias phase measurements because the receiver samples the reference at the wrong points in time. That bias can look like a frequency offset, especially when the receiver is already near acquisition.

A practical mitigation is to iterate: estimate timing first (or jointly with frequency), then estimate frequency using corrected timing. In systems where timing is already stable, you can keep frequency tracking running continuously and only re-check timing when pilot metrics degrade.

Validation Checklist

After correction, validate with three signals:

1. Residual frequency error: estimate again and confirm it clusters near zero.
2. Pilot phase consistency: the phase evolution should match the corrected model.
3. Demodulation quality: constellation rotation should reduce, and error rates should improve.

If residual estimates remain biased, revisit window length, loop bandwidth, and whether timing is sufficiently aligned. In Doppler-heavy conditions, the most common fix is not “more averaging,” but shorter estimation windows with stable tracking updates.

7.3 Reference Signals and Measurement Procedures for Mobile Terminals

Reference signals are the terminal’s way of asking, “Where am I in the link, and how good is it right now?” In direct to cell satellite communication, that question is harder because the channel changes quickly with motion, beam edges, and Doppler. A good measurement procedure turns those changes into stable estimates that the receiver can use for demodulation, timing alignment, and link adaptation.

What Mobile Terminals Measure and Why

A mobile terminal typically needs four categories of information:

• Timing: where the symbol boundaries are, so the receiver samples the right moments.
• Frequency: the residual offset after coarse acquisition, mainly driven by Doppler.
• Channel quality: signal strength and quality indicators used for scheduling decisions and link adaptation.
• Channel state: enough detail to equalize the received waveform, especially when the channel varies across time and frequency.

In practice, timing and frequency estimates are tightly coupled. If timing is off, frequency estimation becomes noisy; if frequency is off, channel estimates smear. That’s why reference signals are designed to support both estimation and tracking.

Reference Signal Types and Their Roles

Reference signals can be thought of as “known patterns” inserted into the transmission so the terminal can compare what it receives against what it expects.

• Synchronization reference signals help the terminal lock to the carrier and symbol timing. They are used early in the process and must be robust under low signal conditions.
• Channel state reference signals support estimation of the radio channel for demodulation. They are used repeatedly so the terminal can track changes.
• Measurement reference signals are used to derive metrics such as reference signal received power and quality indicators. These metrics feed higher-layer decisions.

A useful mental model is to separate “lock” from “track.” Locking gets you aligned; tracking keeps you aligned as the satellite and terminal move.

Measurement Workflow from Acquisition to Tracking

A systematic procedure keeps the terminal from mixing stale estimates with fresh ones.

1. Initial acquisition: perform coarse frequency and timing estimation using synchronization reference signals. The goal is to get within the receiver’s capture range.
2. Fine synchronization: refine timing and frequency using dedicated reference patterns. This step reduces residual Doppler error.
3. Channel estimation: compute channel coefficients using channel state reference signals. The receiver uses these coefficients for equalization and demodulation.
4. Metric computation: derive measurement metrics from measurement reference signals. Typical metrics include received power and quality indicators.
5. Tracking loop: periodically repeat fine synchronization and channel estimation. The update interval should match how fast the channel changes for the terminal’s expected motion.

The terminal should also maintain a small history buffer so that sudden metric jumps can be correlated with beam edge effects rather than treated as random noise.

Doppler and Mobility Effects on Reference Signal Measurements

Doppler causes frequency rotation across the observation window. If the terminal estimates frequency using reference signals but the channel changes faster than the estimation window, the estimate lags and equalization suffers.

To manage this:

• Use shorter coherent measurement windows when motion is high.
• Apply frequency tracking so the receiver corrects residual offset continuously rather than only at acquisition.
• Treat beam edge behavior carefully: signal quality can drop because of geometry, not because the terminal is broken.

A practical check is to compare frequency offset estimates across consecutive reference occasions. If timing is stable but frequency drifts rapidly, Doppler tracking is the likely issue.

Example Procedure for a Vehicle Mounted Terminal

Assume a terminal in a vehicle traveling through a satellite beam. The terminal performs:

• Coarse acquisition using synchronization reference signals.
• Fine synchronization every reference occasion.
• Channel estimation and equalization for each downlink burst.
• Metric reporting every few occasions to smooth short-term fluctuations.

If the vehicle approaches a beam edge, you may observe:

• Received power decreases gradually.
• Quality indicators degrade faster than power, because equalization becomes less effective.
• Frequency estimates remain consistent, indicating the issue is geometry rather than Doppler failure.

The terminal can then reduce modulation and coding aggressiveness based on the quality metrics, while continuing frequency tracking to avoid compounding errors.

Mind Map of Reference Signal Measurements

Practical Measurement Integrity Checks

To keep measurements trustworthy, the terminal should apply consistency checks:

• Timing consistency: if timing error grows while frequency error stays stable, the issue may be multipath or scheduling changes rather than Doppler.
• Frequency consistency: if frequency estimates jump abruptly, verify that the terminal is still aligned to the correct reference occasion.
• Metric sanity: if quality collapses while power remains steady, equalization may be failing due to incorrect channel estimation or insufficient tracking rate.

These checks prevent the terminal from reacting to measurement artifacts, which is especially important when the link is already operating near its practical limits.

7.4 Impact of Satellite Motion on Link Stability and Handover Triggers

Satellite motion changes the radio link in ways that matter for both stability and handover timing. Even when the satellite is “in view,” its movement continuously alters geometry, which shifts path loss, Doppler, and timing. The result is a link that behaves like a moving target: predictable in physics, but not static in measurements.

What Motion Changes in the Link

As the satellite moves relative to the user terminal, the slant range changes. That directly affects free-space loss and therefore received signal strength. Motion also changes the relative radial velocity, which creates Doppler shift. Doppler is not just a frequency offset; it also affects how well the receiver’s tracking loops can stay locked.

Timing is impacted too. Propagation delay varies with slant range, so the terminal’s timing reference must keep up. If timing and frequency tracking drift beyond tolerances, the link can degrade abruptly even though the satellite remains visible.

A useful mental model is to separate effects into three measurement streams:

• Signal strength trend from changing range and antenna patterns.
• Frequency trend from Doppler and oscillator offsets.
• Timing trend from changing propagation delay.

Each stream has its own “rate of change,” so a handover trigger based on only one measurement can be late or premature.

Link Stability Mechanisms Under Motion

Link stability depends on whether the receiver can maintain synchronization and decoding performance while measurements evolve. In practice, stability is governed by:

• Tracking loop margins for frequency and timing.
• Coding and retransmission behavior that tolerates short bursts of errors.
• Scheduling continuity so the terminal keeps getting resources when conditions fluctuate.

When Doppler changes quickly, the receiver’s frequency estimation can lag. That increases residual error, which raises demodulation error rates. If the error bursts exceed the link’s recovery capacity, higher layers experience packet loss or delays.

Timing drift can cause reference signal misalignment. Even small misalignment can reduce coherent combining gain, which shows up as a drop in effective SINR.

How Motion Drives Handover Triggers

Handover triggers are usually based on measured quality and availability. Motion changes those measurements continuously, so the trigger logic must avoid oscillation and avoid missing the moment when the target becomes better.

A stable handover strategy typically uses multiple guardrails:

• Thresholds that reflect decoding quality, not just raw signal strength.
• Hysteresis so the terminal does not bounce between beams or gateways when measurements hover near a boundary.
• Time-to-trigger so short dips caused by geometry or tracking transients do not cause immediate switching.

Motion also affects the rate at which measurements cross thresholds. If the terminal is moving fast or the beam boundary is steep, the measurement slope is high. In that case, a fixed time-to-trigger can be too long, causing the handover to occur after the link has already degraded.

Conversely, if the slope is low, a short time-to-trigger can cause unnecessary handovers. The trigger logic should therefore consider both the measurement value and how quickly it is changing.

Practical Example of Trigger Behavior

Consider a terminal moving across a beam edge. Early in the crossing, the received power decreases gradually. Doppler continues to change smoothly, so tracking remains stable. The quality metric might stay above the handover threshold for a while.

Near the edge, the antenna gain drops faster and the effective SINR falls. At the same time, the frequency tracking residual may increase slightly because the Doppler rate is higher for that geometry. The quality metric crosses the threshold.

If the system uses:

• a hysteresis of 2 dB,
• a time-to-trigger of 200 ms,
• and a minimum quality requirement for the target, then the handover will not trigger on the first brief dip. It will trigger when the target beam’s quality is consistently better and the current beam’s quality remains below threshold long enough to indicate a real boundary crossing.

If hysteresis is removed, the terminal can oscillate: one measurement moment favors the current beam, the next favors the target, and the handover repeats. If time-to-trigger is too short, tracking transients can masquerade as a boundary crossing.

Mind Map of Motion Effects and Trigger Controls

Summary of the Cause-and-Effect Chain

Satellite motion changes geometry, velocity, and delay. Those changes alter received power, Doppler behavior, and timing alignment. Link stability holds only while tracking and decoding remain within margins. Handover triggers must therefore use quality-based thresholds with hysteresis and time-to-trigger, and they should account for how quickly measurements move when the terminal crosses a beam boundary.

7.5 Practical Example: Building a Synchronization Workflow for a Direct to Cell UE

A Direct to Cell UE needs to lock onto timing and frequency well enough to decode control information, then keep that lock stable while the satellite moves and the user terminal changes orientation. The workflow below is written as a practical checklist you can implement in software or validate in a lab.

Step 1: Start with What You Can Measure

The UE begins in a “search” state and measures what the receiver can reliably estimate: coarse time, coarse frequency offset, and signal quality metrics. In practice, you treat the first pass as a rough map, not a final answer.

• Coarse frequency offset: estimate from a known reference structure (or a preamble) using a wide capture window.
• Coarse timing: find the strongest correlation peak across candidate delays.
• Signal quality: record RSRP-like and SINR-like metrics for later decision thresholds.

Example: If the UE sees multiple correlation peaks, pick the earliest peak that exceeds a minimum threshold. This reduces the chance of locking to a delayed echo.

Step 2: Apply Doppler-Aware Frequency Correction

Satellite motion creates a time-varying Doppler shift. Instead of assuming a constant offset, you estimate an initial correction and then refine it using ongoing measurements.

• Initial correction: apply the coarse frequency estimate immediately to bring the receiver into the right demodulation range.
• Refinement loop: after decoding any available reference or control symbols, update the frequency estimate.
• Rate limiting: constrain how fast the correction can change between updates to avoid chasing noise.

Example: If your update interval is 10 ms and the estimated offset jumps by 200 Hz due to a weak reference, clamp the change to a smaller step (for instance 50 Hz) until quality improves.

Step 3: Establish Timing Using Reference Signals

Once frequency is close, timing estimation becomes sharper. The UE uses reference signals to compute a timing offset and then aligns its receiver window.

• Fine timing estimation: compute the delay that maximizes correlation with the reference.
• Timing advance behavior: if the UE transmits, apply timing advance so the uplink arrives aligned at the gateway.
• Window selection: choose a receive window that covers expected residual timing error.

Example: If the fine estimate lands near the edge of your receive window, expand the window for the next attempt rather than forcing a lock that will fail intermittently.

Step 4: Validate Lock with Decode-Driven Checks

Synchronization is not “done” when you compute offsets; it’s done when decoding succeeds consistently.

• Control channel decode check: verify CRC on the first critical messages.
• Reference residuals: confirm that residual frequency error is small enough for demodulation.
• Stability window: require success across multiple consecutive frames or slots.

Example: If CRC fails once but reference residuals look good, retry with the last known good timing and a slightly adjusted frequency rather than restarting the full search.

Step 5: Maintain Synchronization During Mobility

As the UE moves, Doppler and timing drift. Maintenance should be incremental.

• Continuous measurement: periodically re-estimate frequency and timing offsets.
• Handover readiness: when beam or coverage changes, increase measurement frequency before the handover completes.
• Graceful degradation: if quality drops, keep the last good parameters and widen search only when decode checks fail.

Example: When SINR drops below a threshold, switch from “tight tracking” to “robust tracking” by relaxing update constraints and increasing the number of candidate timing hypotheses.

Step 6: Put It into a Workflow You Can Test

Use a state machine so behavior is predictable.

• States: Search → Coarse Lock → Fine Lock → Decode Verify → Track
• Transitions: driven by measurement thresholds and decode success counters

Example: Parameter Set for a Repeatable Test

• Coarse search window: cover expected delay spread plus margin.
• Frequency update interval: short enough to follow Doppler drift.
• Stability requirement: e.g., 3 consecutive successful decodes.
• Retry policy: 2 incremental retries before widening the search.

Example: In a lab replay, start with a known initial offset and inject a controlled Doppler ramp. Confirm that the UE transitions from Fine Lock to Decode Verify within a fixed number of frames and that it stays in Track without frequent resets.

Step 7: A Minimal Pseudocode Outline

state = SEARCH
last_good = {freq: 0, time: 0}
crc_passes = 0
fail_count = 0

while true:
  meas = measure_reference()

  if state == SEARCH:
    freq0, time0 = coarse_estimate(meas)
    apply(freq0)
    state = COARSE_LOCK

  elif state == COARSE_LOCK:
    time1 = fine_timing_estimate(meas)
    apply_timing(time1)
    state = FINE_LOCK

  elif state == FINE_LOCK:
    ok = decode_and_check_crc()
    if ok:
      crc_passes += 1
      last_good = current_params()
      if crc_passes >= 3:
        state = TRACK
    else:
      fail_count += 1
      if fail_count <= 2:
        restore(last_good)
      else:
        state = SEARCH

  elif state == TRACK:
    update = periodic_refinement(meas)
    apply(update)
    if decode_fails_repeatedly():
      state = SEARCH

This workflow keeps the UE from doing expensive full searches when it can recover with small corrections, while still guaranteeing that synchronization is only considered valid after decoding checks confirm it.

8.1 Mobility Models for Users Moving Through Satellite Beams

Mobility models describe how a user terminal’s position, velocity, and direction evolve over time, and how that motion translates into changes in satellite beam coverage, link quality, and timing. For direct to cell satellite communication, the key is that beam footprints are not static rectangles; they are shaped by antenna patterns, pointing, and satellite motion, so the user experiences entry, dwell, and exit events that drive scheduling, handover, and link adaptation.

Foundational Building Blocks

Start with a coordinate model. Represent the user position in a global frame (latitude, longitude, altitude) and convert to a satellite-centric view when computing angles of arrival and path geometry. Then define motion. A practical model uses a piecewise trajectory: constant velocity segments separated by turns or speed changes. Even if you don’t model every road detail, capturing direction changes matters because beam edges are angle-sensitive.

Next define the beam interaction. A beam can be treated as a region where a minimum reference signal quality is satisfied. In a simplified model, the beam boundary is a threshold on received power or on elevation angle. In a more realistic model, the boundary is a threshold on beam gain plus propagation loss, which makes the “edge” depend on both position and time.

Finally define time granularity. Mobility models can be continuous, but network decisions are discrete. Choose a step size that matches your control loop: for example, update position every few milliseconds for timing-related effects, but update beam membership and scheduling parameters every tens of milliseconds.

Common Mobility Models and What They Capture

1) Constant Velocity Model Use it for straight-line movement such as a vehicle traveling on a highway. The user enters a beam, stays for a predictable duration, and exits. This model is good for validating that your beam membership logic and timing tracking behave consistently.

2) Random Walk Model Use it for pedestrians or mixed indoor-outdoor movement where direction changes are frequent. The user may re-enter the same beam multiple times, which stresses session continuity and buffering behavior when link quality fluctuates.

3) Gauss–Markov Mobility Model This is a “random walk with memory.” Speed and direction are correlated over time, which better matches real movement than independent random steps. It’s useful when you want realistic dwell-time variability without simulating a full map.

4) Road-Constrained Mobility Model For vehicles, constrain motion to lanes or road segments. Even a coarse road graph improves realism because it reduces impossible turns and produces smoother angle evolution. This matters because beam edges can be crossed quickly if the direction changes abruptly.

Beam Crossing as the Core Event

Instead of focusing only on position, define beam crossing events. A beam crossing event occurs when the user’s computed beam membership changes from “in” to “out” or vice versa. For direct to cell, these events are the moments that typically trigger measurement updates, scheduling reconfiguration, and potential handover decisions.

A useful metric is dwell time: the duration the user remains above the beam threshold. Dwell time distributions help you test whether your system can handle short visits (frequent edge crossings) or long stays (stable links). Another metric is edge crossing speed, which is the rate of change of beam gain or reference signal quality near the boundary. High edge crossing speed increases the risk of abrupt quality drops between decision points.

Example: Comparing Two Mobility Models on the Same Beam

Assume a single beam with a threshold that the received reference signal must exceed. Consider a user starting outside the beam and moving through it.

• Constant Velocity Example: The user moves at 20 m/s in a straight line. The beam membership becomes true at time \( t_1 \), stays true until \( t_2 \), then becomes false. Because direction is fixed, the rate of change of beam gain near the edge is relatively steady, so scheduling decisions can be updated predictably.

• Random Walk Example: The user moves with the same average speed but changes direction every second. Even if the average dwell time is similar, the beam membership can toggle multiple times. That produces repeated edge crossings, which increases the number of measurement updates and can cause more frequent reconfiguration of link parameters.

The takeaway is not that one model is “better,” but that each model stresses different parts of the system: constant velocity tests stability, while random walk tests robustness to rapid membership changes.

Example: Choosing a Step Size Without Guesswork

Suppose your network updates beam-related parameters every 100 ms. If your mobility step is 1 ms, you may waste computation without improving decisions. If your mobility step is 200 ms, you can miss the exact moment the user crosses the threshold, leading to delayed or premature beam membership changes.

A practical rule is to make the mobility step small enough that the beam gain changes by only a modest fraction between steps near the boundary. You can estimate this by computing beam gain at consecutive steps along a representative trajectory and checking that the difference is within your acceptable tolerance.

Advanced Detail: Modeling Direction Changes at Beam Edges

Direction changes are especially important near beam edges because they alter the angle of arrival quickly. In a Gauss–Markov model, you can control how sharply direction can change by tuning the correlation time. A shorter correlation time produces more abrupt angle evolution, which increases edge crossing speed and makes measurement noise more consequential.

To keep the model systematic, separate two effects: (1) geometric motion that changes beam gain deterministically, and (2) measurement uncertainty that adds randomness to observed quality. This separation helps you determine whether handover or scheduling instability comes from the mobility pattern itself or from noisy measurements interacting with a fast-changing beam edge.

Summary of Modeling Choices

Use constant velocity to validate baseline beam entry and exit behavior, random walk to test frequent edge toggling, Gauss–Markov to represent correlated real movement, and road-constrained motion to improve vehicle realism. Define beam crossing events explicitly, measure dwell time and edge crossing speed, and choose time steps that align with your network decision cadence. When these pieces fit together, mobility modeling becomes a reliable tool for explaining observed behavior rather than a source of mysterious variability.

8.2 Handover Decision Criteria Including Signal Quality and Availability

A handover decision in direct-to-cell NTN is mostly about two questions: “Is the target beam likely to deliver usable service?” and “Will switching cause a service gap?” The criteria should be evaluated in a consistent order so the UE does not bounce between beams when signal quality is near the edge.

Core Inputs the UE Uses

Signal quality is the primary driver. In practice it is represented by measurements such as reference signal quality, demodulation metrics, or an estimated transport block success probability. For NTN, quality must be interpreted alongside Doppler and timing stability, because a beam can look “strong” while still being hard to decode.

Availability is the second driver. Availability includes whether the UE can access the target beam resources in time, whether timing and frequency can be acquired quickly, and whether the network indicates the target is currently schedulable for the UE’s service type.

Handover margin is the buffer that prevents ping-pong. It is the minimum advantage the target must have over the serving beam before a switch is allowed.

Decision Logic from Simple to Robust

Start with a baseline rule: the UE should prefer the beam whose predicted link performance is best for the current modulation and coding configuration. Then add guardrails.

1. Measure and filter: Use a time window to smooth measurements. For example, if the UE averages quality over 200–500 ms, a brief fade near the beam edge won’t trigger a switch.
2. Check target eligibility: Confirm the target beam is not barred for the UE, and that required synchronization and access procedures are feasible.
3. Apply hysteresis: Require the target quality to exceed the serving quality by a margin. A typical margin might be 3–6 dB in terms of quality metric, but the exact value should be tied to the observed error-rate curve.
4. Verify availability timing: Ensure the UE can complete the handover procedure before the serving beam quality drops below a minimum threshold.
5. Select the best candidate: If multiple beams qualify, pick the one with the highest predicted success probability, not just the strongest received power.

This order matters. If you pick the strongest beam first, you can end up switching to a beam that is measurable but not schedulable for the UE’s current traffic pattern.

Signal Quality Criteria That Actually Work

Use quality thresholds that map to service outcomes. A practical approach is to define two thresholds: Q_enter and Q_exit.

• Q_enter: the target must be above this to start handover evaluation.
• Q_exit: the serving beam must remain above this to avoid unnecessary switching.

For messaging services with small packets, Q_enter can be slightly lower because short transmissions tolerate brief degradation. For continuous data, Q_enter should be higher because retransmissions can accumulate and increase latency.

Also include a “decode stability” check. If the UE detects frequent demodulation failures or unstable timing estimates, it should treat quality as effectively worse even when received power is high.

Availability Criteria for NTN Beams

Availability is not just “beam exists.” It includes:

• Resource readiness: whether the target beam can grant uplink and downlink resources for the UE’s next transmission opportunity.
• Synchronization feasibility: whether the UE can reacquire timing and frequency within the handover timeline.
• Procedure budget: whether the handover signaling and access steps fit within the time the serving beam remains usable.

A simple way to operationalize this is to compute a handover deadline: the latest time the UE can start the handover such that the target is ready before serving quality falls below Q_exit.

Example: Beam Edge with Messaging Traffic

Assume the UE is sending short status messages every second. Measurements show serving beam quality is slowly decreasing as the UE approaches a beam boundary. The UE computes a filtered quality metric.

• Serving quality drops toward Q_exit.
• A neighboring beam’s filtered quality rises above Q_enter.
• The target is eligible and the network indicates it can schedule the next downlink opportunity.

The UE then checks hysteresis: the target must exceed the serving metric by the handover margin. If it does, the UE starts handover early enough that the handover deadline is not violated. If the target quality briefly spikes but does not stay above Q_enter for the filter window, the UE does not switch.

Result: the UE avoids switching during a short fade and still completes handover before the serving link becomes unreliable.

Example: Continuous Data with Tight Latency

Now consider a continuous data session where retransmissions directly increase latency. The UE uses a higher Q_enter and a stricter decode stability check. Even if the target beam is slightly better in received power, the UE may delay handover until the predicted success probability improves enough to justify the switching overhead.

If the target beam is eligible but resource readiness is uncertain, the UE may keep the serving beam until the next scheduling cycle confirms availability. This prevents a handover that technically “works” but causes a noticeable pause in throughput.

Practical Summary of the Criteria

A good handover decision combines: filtered signal quality, decode stability awareness, hysteresis margins, and an availability check tied to a handover deadline. When these criteria are evaluated in a consistent sequence, the UE switches beams when it is likely to improve delivery and avoids switching when it would mostly create extra work.

8.3 Session Continuity Mechanisms for Ongoing Data Transfers

When a user moves across satellite beams, the network must keep ongoing transfers usable even as radio conditions and routing paths change. “Session continuity” means the application keeps its logical session while the network quietly adjusts the radio and transport details underneath. In direct-to-cell satellite communication, continuity is harder because propagation delay is large and Doppler changes quickly as the satellite moves.

Core Idea of Continuity

A session is usually anchored in the core network, while the radio access path can change. Continuity mechanisms therefore focus on two things: (1) keeping the session context so the core knows the user is still the same logical entity, and (2) minimizing disruption during beam changes by coordinating radio handover and data forwarding.

A practical way to think about it is “make the user identity stable, make the path flexible.” The user equipment (UE) remains the same from the core’s perspective, while the access link may switch between beams or gateways.

Session Context Preservation

Session continuity starts with context preservation. The network stores enough state to resume data flow without forcing a full re-establishment. Typical context elements include security state, bearer identifiers, quality-of-service parameters, and sequence tracking for reliable delivery.

In a direct-to-cell setup, the UE may report measurements that trigger a beam change. The network then updates the radio-side mapping while keeping the same core-side session identifiers. If the UE must temporarily suspend transmission due to timing or scheduling changes, the network uses buffering so the application does not see a hard break.

Make Handover Predictable for Ongoing Transfers

Beam changes can be treated like handovers, but with satellite-specific constraints. The key is to coordinate three timelines: measurement reporting, radio resource availability in the target beam, and the moment the UE can transmit with correct timing and frequency.

To reduce gaps, the network can prepare the target resources before the UE fully switches. This preparation can include reserving scheduling opportunities and ensuring that the UE’s timing advance and frequency correction parameters are valid for the new beam.

A concrete example: a vehicle streams telemetry at a steady rate. As it approaches a beam edge, the UE reports rising reference-signal measurements for the next beam. The network schedules a short “make-before-break” window where the UE can send in the target beam while the source beam still carries earlier packets. The application sees continuous throughput because the receiver can reorder or absorb minor timing differences.

Buffering and In-Flight Data Handling

Even with careful coordination, some packets are in flight during the transition. Continuity mechanisms therefore rely on buffering and controlled retransmission.

At the radio protocol level, reliable mechanisms can retransmit lost segments, but satellite latency makes retransmission expensive. So the system often combines: (1) buffering at the network side to bridge the handover gap, and (2) limited retransmission for truly missing data.

At the transport level, continuity can also use sequence numbers so the receiver can reorder packets that arrive out of order due to path changes. The goal is not to eliminate every disorder event, but to keep the application from interpreting reordering as a session failure.

Security and Key Continuity

Security continuity prevents unnecessary re-authentication during mobility. If security context is preserved across the handover, the UE can continue using existing keys for integrity and encryption. That reduces signaling overhead and avoids delays that would otherwise stall data transfer.

A simple example: a messaging session uses protected signaling and user-plane data. During a beam switch, the UE should not need to restart the entire security procedure. Instead, the network updates only the radio routing while keeping the security context valid for the session.

QoS Continuity and Scheduling Behavior

Ongoing transfers often depend on QoS. Continuity therefore includes preserving QoS parameters so the target beam applies the same priority and scheduling treatment.

Consider a scenario with two concurrent flows: a low-rate control channel and a higher-rate file transfer. If the file transfer suddenly drops priority during beam change, it may starve and trigger application-level timeouts. QoS continuity avoids that by carrying the bearer’s QoS profile into the target scheduling context.

Example: Telemetry Stream Through Multiple Beam Edges

A telemetry stream uses a dedicated bearer with a fixed QoS profile. As the UE approaches the first beam edge, it reports measurements for the next beam. The network prepares target scheduling and updates the radio mapping while keeping the core session unchanged.

During the transition, the network buffers a small amount of data so the receiver can continue without a long pause. Any packets that arrive out of order are handled by sequence-aware reordering. The UE continues sending with updated timing and frequency correction parameters, and the bearer remains protected with the existing security context.

The result is a session that stays logically intact: the application keeps its session identifiers and does not need to restart, even though the radio path changed multiple times.

8.4 Managing Coverage Gaps and Beam Edge Behavior Without Speculation

Coverage gaps and beam edges are where direct to cell links stop behaving like a neat textbook diagram and start behaving like real radio. The goal is not to guess what will happen next, but to design behavior that stays correct when signal quality changes quickly.

Foundational Concepts for Beam Edges

A beam edge is not a cliff; it is a region where received power, interference, and timing stability change with user position. In practice, the edge region is shaped by antenna patterns, satellite pointing, polarization mismatch, and the user terminal’s own orientation. The same user can experience different link margins over short distances, especially when the terminal is moving and the satellite geometry changes.

A coverage gap is a location where the link cannot meet the minimum required performance for the chosen service. “Cannot” can mean insufficient signal-to-noise ratio, excessive block error rate, or inability to maintain synchronization and timing advance. Treat gaps as measurable outcomes, not surprises.

Deterministic Design Inputs

Start with three measurable inputs: link margin versus position, beam footprint geometry, and terminal capability limits. Link margin comes from the link budget and the expected propagation losses. Footprint geometry comes from the beam maps used by the network scheduler. Terminal capability limits include maximum supported modulation and coding, receiver sensitivity, and whether the terminal can reacquire timing quickly after degradation.

Then define what “good enough” means. For example, a messaging service might require a maximum block error rate and a maximum end-to-end delay. A voice-like service might require more consistent scheduling and tighter latency bounds. These thresholds drive the handover and fallback behavior.

Beam Edge Behavior Management

Beam edge management is mostly about controlling transitions.

1. Monitor the right measurements. Use measurements that reflect both quality and stability, such as reference signal quality and timing error indicators. If you only watch received power, you can miss cases where the channel is noisy but power is still high.
2. Use hysteresis and time-to-trigger. Without hysteresis, the system can oscillate between beams. Without time-to-trigger, it can react to short fades that would pass naturally.
3. Coordinate scheduling with mobility state. When the terminal is near the edge, allocate resources with a bias toward robustness. That can mean more conservative modulation and coding, or more retransmission budget at the link layer.
4. Keep the session behavior consistent. If the network changes bearers or service parameters during edge crossing, do it in a way that the user experience remains coherent. For packet services, this often means maintaining sequence handling and avoiding unnecessary resets.

Coverage Gap Handling Without Guessing

When a gap is unavoidable, the system should fail gracefully.

A practical approach is to define three states: Connected, Degrading, and Out of Coverage. Transitions are triggered by thresholds and timers.

• Connected: Measurements meet the service requirements.
• Degrading: Measurements fall below a “comfort” threshold but still allow successful delivery with the current configuration.
• Out of Coverage: Measurements indicate that successful delivery is unlikely or synchronization cannot be maintained.

In Degrading, the system should attempt to improve robustness using link adaptation and scheduling priority. In Out of Coverage, it should stop wasting resources on transmissions that are likely to fail and instead switch to a recovery procedure that is bounded in time.

Example: Messaging Session Crossing an Edge

Assume a direct to cell messaging service uses small packets with link-layer retransmissions.

• At first, the terminal is Connected and uses a higher modulation and coding for efficiency.
• As it approaches the beam edge, reference signal quality drops and timing error increases. The system enters Degrading after a time-to-trigger of, say, 200 ms.
• In Degrading, the scheduler grants more robust resources and the link layer increases retransmission allowance. The message still completes, but with higher airtime.
• If measurements remain below the out-of-coverage threshold for a bounded interval, the system transitions to Out of Coverage. It stops attempting new message transmissions and starts a recovery procedure that includes periodic synchronization attempts.

The key detail is that the system does not “predict” where the terminal will be. It reacts to observed measurements and uses bounded timers so behavior is repeatable.

Example: Vehicle Movement and Oscillation Prevention

A vehicle moving along a road can repeatedly skim the edge of two adjacent beams. Without hysteresis, the terminal can bounce between beams every few hundred milliseconds, causing repeated reconfiguration and failed deliveries.

With hysteresis, the terminal requires a stronger condition to switch beams than to stay in the current one. With time-to-trigger, it waits for the condition to persist before switching. The result is fewer transitions and more stable delivery, even if the vehicle’s position fluctuates around the edge.

Validation Checklist for Real Deployments

To ensure the behavior is correct, validate with logged measurements and outcomes.

• Confirm that each state transition aligns with measured thresholds.
• Verify that oscillation is reduced when hysteresis and time-to-trigger are enabled.
• Check that Out of Coverage behavior conserves resources and triggers recovery within the intended bounds.
• Ensure that session continuity mechanisms handle edge crossing without unnecessary resets.

Coverage gaps and beam edges are unavoidable. What matters is that the system’s response is measurable, bounded, and consistent with the service requirements—so the radio can be unpredictable while the behavior remains reliable.

8.5 Practical Example: Tracing a Handover Sequence With Logged Measurements

This example walks through a single handover for a direct-to-cell UE moving across satellite beams. The goal is to show how logged measurements map to decisions, and how those decisions show up later as user-visible behavior.

Scenario Setup

Assume a UE travels from Beam A toward Beam B. The network uses beam-specific reference signals, and the UE reports measurements every 200 ms. The logs include:

• UE measurements: RSRP/RSRQ-like metrics per beam, timing advance estimate, and frequency offset estimate.
• Network decisions: candidate beam selection, handover trigger, and target beam activation.
• Radio outcomes: grant success rate, HARQ retransmissions, and scheduling delays.

To keep the example concrete, use these thresholds:

• Handover trigger: target beam metric exceeds serving beam metric by 3 dB for at least 2 consecutive reports.
• Handover execution: target beam becomes active within 1 scheduling interval after trigger.
• Edge guard: if timing advance error exceeds a limit, delay execution by one interval.

Step 1: Align the Timeline

Start by choosing a common time base. In practice, logs often use different clocks, so you first align them using a known event such as “measurement report sent” or “grant received.” Once aligned, create a table of key timestamps:

• t0: last report where serving beam clearly dominates
• t1: first report where target beam surpasses serving by 3 dB
• t2: second consecutive report meeting the margin
• t3: handover trigger issued
• t4: target beam activation confirmed
• t5: first successful uplink grant on target beam

If your logs are messy, don’t panic. The trick is to anchor on events that must exist in both UE and network logs, like measurement report transmission and grant reception.

Step 2: Verify the Trigger Condition

At t0, Beam A metric is higher than Beam B by 2 dB. Over the next two reports, the UE moves closer to Beam B’s footprint. At t1, Beam B exceeds Beam A by 3.2 dB, but the trigger requires two consecutive reports. At t2, the margin is 3.6 dB again, so the trigger condition is satisfied.

A common mistake is to treat the first crossover as the trigger. In this example, the network waits for the second report, which reduces ping-pong when the UE is near the beam edge.

Step 3: Check Execution Gating with Timing Advance

Even when the trigger fires, execution can be delayed. At t3, the network issues the handover trigger, but it also checks the timing advance guard. Suppose the UE’s timing advance error spikes at t3 due to rapid geometry change. The network delays execution by one interval, so target activation shifts from t4 to t4+Δ.

This is where the logs become useful: you should see a gap where the target beam is “prepared” but not yet “active,” and you should see the UE’s timing advance estimate stabilize right before the first target grant.

Step 4: Confirm Radio Outcomes After Activation

At t4, the target beam becomes active. The first uplink grant on the target beam occurs at t5. Validate the handover by checking that radio outcomes improve or at least behave consistently:

• Grant success rate should recover after the activation.
• HARQ retransmissions should spike briefly during the transition, then settle.
• Scheduling delay should return to the baseline for that beam.

If grants fail repeatedly after activation, the handover may have executed but not fully synchronized. In that case, revisit timing advance and frequency offset logs around t4–t5.

Example: Correlated Log Snippet (Conceptual)

t1 UE report: BeamA=-92 dBm, BeamB=-88.8 dBm, margin=3.2 dB
t2 UE report: BeamA=-93 dBm, BeamB=-89.4 dBm, margin=3.6 dB
t3 Network: Handover trigger issued to BeamB
t3 UE TA error: 1.8 us exceeds guard 1.5 us
t4 Network: Execution delayed one interval
t4+Δ UE TA error: 1.1 us
t4+Δ Network: Target BeamB active
t5 UE: First uplink grant received on BeamB
t5+1 HARQ: retransmissions drop toward baseline

Step 5: Summarize the Handover in One Paragraph

In this trace, the UE crossed the beam edge at t1, met the two-report margin requirement by t2, and triggered handover at t3. Execution was delayed because timing advance error exceeded the guard, then proceeded once timing stabilized at t4+Δ. The first successful uplink grant on Beam B at t5 confirms that the radio path was usable again, and the brief HARQ retransmission increase matches the expected transition behavior.

Mind Map: Validation Checklist

11. Performance Engineering and Troubleshooting Workflows

12. Practical Implementation Guide for End to End Direct to Cell Services

Check 1: QoS profile IDs match across core and access
- Input: core-selected profile
- Output: radio bearer uses same profile

Check 2: Timing units match
- Input: reference timing update interval
- Output: UE timing advance update cadence

Check 3: Retransmission window alignment
- Input: HARQ retransmission settings
- Output: RLC/PDCP behavior does not assume instant delivery