Satellite Networks, Protocols and Constellation OperationsIntroduction and ContextSatellite communication has evolved from isolated geostationary links into complex networks containing gateways, user terminals, inter-satellite links (ISLs), network-control systems, and satellites in geostationary Earth orbit (GEO), medium Earth orbit (MEO), and low Earth orbit (LEO). The satellite is no longer merely a transparent repeater. In many systems it participates in routing, packet processing, resource allocation, mobility management, cybersecurity, and service orchestration. A satellite network must address problems that are less prominent in terrestrial networks: long and variable propagation delay, intermittent visibility, rapidly changing topology, limited spectrum and power, Doppler shift, constrained feeder links, beam hopping, and the need to coordinate thousands of moving spacecraft. These conditions affect the choice of architecture and protocol. A protocol optimized for a fibre network cannot automatically be assumed to perform well over a satellite path. This chapter examines bent-pipe and regenerative architectures, ISLs, routing, gateways, TCP/IP performance, mobility and handover, quality of service (QoS), and integrated multi-orbit systems. The emphasis is on engineering analysis: how architectural decisions influence latency, capacity, reliability, operational complexity, and user experience. Learning ObjectivesAfter studying this chapter, the reader should be able to: 1. Distinguish bent-pipe, regenerative, and hybrid satellite networks. 2. Explain the functions of gateways, user terminals, network-control centres, and ISLs. 3. Analyze satellite routing and topology-management approaches. 4. Evaluate TCP/IP performance over high-delay, variable-delay, and intermittent links. 5. Explain mobility management, beam handover, gateway handover, and inter-orbit handover. 6. Apply latency and link-capacity concepts to network design. 7. Compare GEO, MEO, LEO, and integrated multi-orbit architectures. 8. Identify operational, regulatory, security, and sustainability challenges. 1. Satellite Network Architectures1.1 Bent-pipe networksIn a bent-pipe, or transparent, satellite, the payload receives an uplink signal, filters and frequency-translates it, amplifies it, and retransmits it on the downlink. Demodulation, switching, routing, and most protocol processing remain at gateways or terrestrial network nodes. A simplified path is: User terminal → access link → satellite transponder → feeder link → gateway → terrestrial core network. The principal advantages are architectural simplicity, long payload life, technology independence, and comparatively straightforward satellite control. A transponder can support different waveforms or services without changing an onboard processor. Bent-pipe systems are especially effective for broadcast, fixed satellite services, trunking, and networks in which gateways have good connectivity. The major limitations are dependence on gateways and feeder-link capacity. Traffic between two terminals may travel up to a gateway even when the terminals are geographically close. The satellite cannot easily make local routing decisions, and a gateway outage can affect a large coverage region. The radio-frequency signal is also retransmitted without inherently understanding packet priority, congestion, or application requirements. 1.2 Regenerative networksA regenerative satellite demodulates and decodes received traffic, performs onboard processing, and retransmits a newly generated signal. Depending on payload capability, it may switch cells, route packets, regenerate protocol frames, perform coding, or implement network functions. A regenerative payload can provide: - onboard beam-to-beam switching;
- packet routing and traffic aggregation;
- improved link budgets through decoding and re-encoding;
- reduced dependence on gateways;
- support for direct satellite-to-satellite forwarding; and
- more efficient use of spectrum through traffic-aware scheduling.
These benefits require processors, memory, software, precise timing, fault management, and radiation-tolerant electronics. Onboard routing software also creates configuration and cybersecurity risks. Payload technology may become obsolete before the spacecraft reaches the end of its operational life. 1.3 Hybrid architecturesMany contemporary systems are hybrid. A satellite may transparently relay ordinary traffic while using regenerative processing for selected beams, control channels, inter-satellite traffic, or high-priority services. Hybrid designs permit gradual introduction of onboard intelligence without requiring every service to use the same processing chain. The architectural choice should be based on traffic pattern, gateway availability, latency objectives, service continuity, payload cost, and upgrade strategy. Regeneration is not automatically superior: if all traffic must ultimately pass through a terrestrial gateway, onboard routing may add complexity without proportionate benefit. 2. Network Elements and Control Planes2.1 User terminals and access networksUser terminals provide modulation, coding, antenna pointing, synchronization, authentication, and adaptation to changing link conditions. Fixed terminals may use mechanically or electronically steered antennas. Mobile terminals require tracking, Doppler compensation, beam discovery, and rapid handover support. The access network commonly includes a return link from terminal to satellite and a forward link from satellite to terminal. Multiple-access methods can include time-division multiple access, frequency-division multiple access, code-division methods, or scheduled broadband waveforms. Adaptive coding and modulation changes the modulation order and forward-error-correction rate in response to channel quality. 2.2 GatewaysA gateway connects the satellite access system to terrestrial networks. Its functions can include traffic aggregation, authentication, policy enforcement, Internet peering, encryption, timing distribution, network-address management, and service monitoring. Gateway diversity uses geographically separated sites so that rain attenuation, power failure, or a local disaster at one site does not interrupt service. Gateway placement is a multi-objective problem. A site should have favourable weather, regulatory authorization, terrestrial backhaul, power, physical security, and a suitable look angle to the satellite. In high-frequency systems, site diversity is particularly valuable because precipitation attenuation can be highly localized. 2.3 Network-control and operations centresThe network-control centre manages spectrum, capacity, routing policy, authentication, topology, and fault response. The satellite-control centre performs telemetry, tracking, and command (TT&C), including orbit control, attitude control, payload configuration, and anomaly recovery. These functions may be co-located but are logically distinct. A modern network-management system maintains a digital representation of satellite position, beam status, gateway reachability, terminal state, link quality, and service policy. Closed-loop automation can reallocate capacity or reroute traffic, but safety-critical commands require authorization, validation, and rollback mechanisms. 2.4 Data, control, and management planesThe data plane carries user traffic. The control plane establishes paths, manages mobility, and distributes routing information. The management plane supervises configuration, performance, accounting, fault management, and security. Separating these functions improves fault isolation and allows high-priority control traffic to remain available during congestion. 3. Inter-Satellite Links and Onboard RoutingISLs connect satellites directly, reducing dependence on gateways and enabling traffic to remain in space over oceanic or remote regions. They may use radio frequency or optical terminals. Optical ISLs offer high capacity and narrow beams but require accurate pointing, acquisition, and tracking. RF ISLs generally offer wider beams and more tolerant pointing requirements but may face spectrum and antenna constraints. An ISL network may be arranged as a mesh, ring, or structured lattice. A LEO constellation can use links to satellites in the same orbital plane and cross-links to adjacent planes. The topology changes because satellites move relative to the Earth and because links may be blocked, scheduled, or unavailable during acquisition. 3.1 Routing metricsConventional terrestrial routing often minimizes hop count. In satellite networks, a useful path metric may combine propagation delay, queueing delay, link reliability, available capacity, energy cost, and handover risk. A conceptual additive cost is C(P) = Σ over links i in P [w_d d_i + w_q q_i + w_r r_i + w_e e_i], where P is a candidate path; d_i is propagation delay; q_i is a queueing or congestion measure; r_i is a reliability penalty; e_i is an energy or operational cost; and the w terms are policy weights. This is a design framework rather than a universal mandatory formula. Its validity depends on metrics being normalized or expressed in compatible cost units. Routing can be centralized, distributed, or hierarchical. Centralized routing offers a global view and can optimize constellation-wide objectives, but it depends on timely topology information and a reliable control channel. Distributed routing is more resilient and scalable but may produce suboptimal paths or transient loops. Hierarchical schemes divide decisions among satellite, regional gateway, and terrestrial controllers. 3.2 Predictive and contact-plan routingBecause satellite orbits are predictable, future connectivity can often be calculated in advance. Predictive routing uses planned visibility windows, orbital state, and scheduled capacity. In disruption-tolerant applications, contact-plan routing stores packets until a future link becomes available. This approach is suitable for intermittent deep-space or remote sensing communications, but it is less suitable for interactive applications requiring continuous low delay. Routing updates must balance accuracy against signalling overhead. If updates are too infrequent, routes become stale; if too frequent, control traffic consumes scarce capacity and causes instability during topology changes. 4. Latency, Capacity and TCP/IP Performance4.1 Propagation delayFor a signal travelling a path of length d through free space, one-way propagation delay is t_p = d/c, where c is the speed of light, approximately 3 × 10^8 m/s, and d is the total path length in metres. This equation accounts only for propagation. Processing, queuing, transmission, and switching delays must be added for an end-to-end estimate. For a GEO bent-pipe connection with two user-to-satellite legs and two gateway-related legs, the physical path can be approximately 72,000 km or more, depending on terminal and gateway geometry. The propagation component alone is therefore about 240 ms one way, while a practical round-trip time (RTT) is commonly substantially higher because of processing and terrestrial paths. GEO delay is not merely a performance inconvenience; it affects transport protocols, interactive control, voice conversation, and application timeout design. A LEO path generally has much shorter individual propagation distances, but the end-to-end route may include several satellite hops, gateways, and handovers. Consequently, a LEO network has lower typical latency than GEO but more variable latency. 4.2 Link capacity and bandwidth-delay productThe bandwidth-delay product (BDP) is BDP = R × RTT, where R is the bottleneck data rate in bits per second and RTT is the round-trip time in seconds. BDP indicates the amount of unacknowledged data required to keep a path continuously busy under ideal conditions. It is not the capacity of the link and does not guarantee throughput. For example, if a satellite path has R = 100 Mbit/s and RTT = 600 ms, then BDP = 100 × 10^6 × 0.6 = 60 × 10^6 bits = 7.5 MB, using 8 bits per byte. A TCP sender with a congestion window much smaller than 7.5 MB may not fully utilize the path, assuming no loss or receiver limitation. 4.3 TCP challengesTraditional TCP interprets packet loss as a sign of congestion. Satellite losses may instead result from rain fade, beam blockage, handover, terminal reacquisition, or link outages. TCP may then reduce its congestion window unnecessarily. Long RTT also slows additive-increase feedback and makes loss recovery expensive. Relevant techniques include: - selective acknowledgements, which identify missing segments efficiently;
- window scaling, which permits large congestion windows;
- performance-enhancing proxies, which split a connection near the satellite gateway;
- transport protocols designed for disruption-tolerant networking;
- application-layer forward error correction and retransmission control; and
- multipath transport, which can combine satellite and terrestrial paths.
A proxy can improve performance but breaks end-to-end transport transparency and complicates encryption, diagnostics, and policy compliance. Modern encrypted protocols reduce the feasibility of inspecting or splitting traffic, so performance improvement increasingly relies on endpoint support and network assistance that preserves security. 4.4 UDP and real-time trafficUDP avoids TCP congestion control and retransmission overhead, but it provides no reliability, ordering, or congestion protection by itself. It can be suitable for carefully engineered voice, video, telemetry, and interactive applications when the application supplies sequencing, rate control, concealment, or forward-error correction. Uncontrolled UDP flows can harm other users; therefore, QoS enforcement and admission control remain essential. 5. Mobility, Handover and Service ContinuityMobility occurs at several levels: 1. Beam handover: a terminal moves from one spot beam to another. 2. Satellite handover: the serving satellite changes as a LEO satellite sets. 3. Gateway handover: feeder-link service transfers between gateways. 4. Inter-orbit handover: service moves between GEO, MEO, and LEO layers. 5. Access-network mobility: the user changes terrestrial attachment while retaining satellite service. A handover consists of measurement, decision, preparation, execution, and confirmation. Measurements may include received signal quality, elevation angle, predicted visibility duration, available capacity, Doppler, and gateway condition. A purely signal-strength-based decision can cause ping-pong handovers when adjacent beams have similar quality. Hysteresis, time-to-trigger, predicted geometry, and load awareness reduce unnecessary transitions. Make-before-break handover establishes the new path before releasing the old one. It reduces interruption but requires additional radio and network resources. Break-before-make is simpler but can cause packet loss and session disruption. Multi-connectivity, packet duplication, buffering, and sequence-number continuity can improve resilience. Mobility management also raises addressing questions. If a terminal changes its point of attachment, preserving its IP address supports session continuity but may create routing inefficiency. Changing the address is topologically efficient but may disrupt sessions. Locator/identifier separation, mobility anchors, tunnelling, and multipath protocols are possible solutions, each adding signalling or state. 6. Quality of Service and Traffic EngineeringQoS is the ability to provide differentiated and measurable service performance. Relevant parameters include throughput, delay, jitter, packet loss, availability, outage duration, and service restoration time. A useful service specification should define measurement points and time intervals; “low latency” without a percentile or boundary is operationally ambiguous. Satellite networks commonly classify traffic into categories such as emergency control, conversational voice, interactive video, transactional data, bulk transfer, and delay-tolerant telemetry. Priority alone is insufficient. A high-priority flow can still fail if its route lacks capacity or if a gateway is unavailable. Traffic-engineering mechanisms include admission control, weighted scheduling, bandwidth reservation, beam hopping, dynamic bandwidth allocation, route diversity, caching, multicast, and demand-based gateway selection. Fairness must be considered: allocating all capacity to high-paying or high-priority traffic can make essential public-service traffic unavailable. Operators therefore need explicit policies, service-level agreements, and regulatory obligations. Capacity planning must account for busy-hour demand, geographic demand variation, gateway weather, satellite failures, and growth. Statistical multiplexing improves utilization but requires protection against correlated demand surges. Beam hopping can follow demand geographically, while spot-beam frequency reuse increases capacity but requires interference coordination. 7. Integrated GEO–MEO–LEO Architectures7.1 Orbit-layer characteristicsGEO satellites remain fixed relative to a point on the equator and provide broad, stable coverage. They are valuable for broadcast, wide-area control, and services requiring stable beam footprints, but have high propagation delay. MEO systems offer an intermediate compromise between coverage, latency, constellation size, and handover frequency. They can support navigation, trunking, and broadband services, depending on design. LEO systems provide lower propagation delay and strong link budgets due to shorter range, but require many satellites for continuity. They face frequent handovers, Doppler, atmospheric drag, constellation coordination, and complex collision-avoidance operations. 7.2 Multi-orbit coordinationAn integrated architecture may use LEO for interactive access, MEO for regional aggregation, and GEO for broadcast, control, or resilient wide-area backhaul. A policy engine selects an orbit based on application delay, availability, cost, terminal capability, weather, congestion, and regulatory constraints. The architecture should not treat orbit selection as a simple “fastest is best” decision. A low-latency LEO route may be congested or unavailable, whereas a GEO route may provide dependable multicast. Multi-orbit terminals require electronically steerable antennas, multiple protocol stacks or a converged adaptation layer, synchronized authentication, and mechanisms for session continuity. A practical design often uses an abstraction layer that exposes common services—connectivity, QoS, security, and mobility—while hiding orbit-specific radio details. However, excessive abstraction can conceal important performance variation. Applications that require strict timing should receive explicit path information or measurable service guarantees. 8. Constellation OperationsConstellation operations combine spacecraft control with network operations. Essential activities include orbit determination, station keeping, collision avoidance, payload scheduling, frequency coordination, software updates, anomaly response, and end-of-life disposal. Operational autonomy is increasingly important because thousands of satellites cannot be managed manually at every decision point. Automation can detect degraded links, predict conjunctions, schedule handovers, and redistribute traffic. Artificial intelligence and machine learning may assist in demand forecasting, anomaly detection, and predictive maintenance. Their outputs must be explainable enough for operators to validate, and safety limits must prevent an unverified model from issuing irreversible commands. Operations require accurate time and position information. Errors in ephemeris or clock synchronization can cause failed handovers, incorrect pointing, routing errors, or collision-risk miscalculations. Independent monitoring, redundant sensors, cross-checks, and controlled software deployment are therefore essential. 9. Security, Regulation and SustainabilitySatellite networks are exposed to jamming, spoofing, unauthorized access, malware, supply-chain compromise, denial-of-service attacks, and attacks on gateways or control centres. Security should include mutual authentication, encryption, secure boot, signed software, key rotation, role-based access, network segmentation, intrusion detection, and resilient command paths. Control traffic should be separated from user traffic and protected against replay. Regulatory coordination is necessary for spectrum licensing, orbital slots, inter-satellite frequencies, earth-station authorization, lawful access requirements, cross-border data handling, and interference resolution. International filings and coordination can affect constellation design and deployment schedules. Space sustainability is a network-engineering issue as well as an environmental concern. Operators must plan collision avoidance, conjunction data sharing, post-mission disposal, passivation, and responsible de-orbiting. Large constellations can increase optical brightness and radio-frequency interference, affecting astronomy and other space users. Sustainability requirements should be included in procurement and architecture decisions rather than treated as an end-of-life afterthought. 10. Illustrative Case: Hybrid Emergency-Response NetworkBackgroundConsider a fictional national emergency-response agency serving coastal and mountainous regions. Terrestrial fibre is available in major cities but is frequently disrupted by floods and earthquakes. The agency requires voice, encrypted video, sensor telemetry, and command messaging. ProblemA GEO-only design provides broad coverage and reliable broadcast but introduces noticeable conversational delay. A LEO-only design offers lower latency but may experience gateway congestion, handover interruptions, and loss of service during terminal or constellation outages. Emergency traffic must also remain available when commercial demand peaks. AnalysisThe agency identifies four service classes: emergency command, voice, video, and non-urgent sensor data. Command traffic requires high availability and strong authentication; video requires sustained capacity; sensor data can tolerate delay. It also identifies gateway weather risk in coastal regions and the need for operation when terrestrial backhaul is unavailable. Approach and solutionThe proposed architecture uses LEO access for interactive voice and video, GEO multicast for common situational-awareness maps and emergency broadcasts, and store-and-forward transmission for non-urgent sensor data. Two geographically separated gateways are deployed, with terrestrial fibre and microwave backhaul where possible. Terminals support make-before-break handover and maintain a small protected control channel. Traffic is classified at the edge. Emergency command packets receive reserved capacity and are replicated over diverse paths when the risk of interruption is high. Video uses adaptive coding and rate control. Sensor data is queued locally during outages and transmitted when a contact window becomes available. Network-control traffic is cryptographically separated from user payload traffic. OutcomeThe design avoids relying on a single orbit or gateway. GEO supports dependable broadcast, LEO supports interactive services, and delay-tolerant operation prevents sensor data loss. The principal trade-off is greater terminal and operational complexity, including multi-orbit antenna requirements, policy coordination, and more demanding monitoring. Learning pointsThe case demonstrates that architecture should be driven by service requirements rather than by orbit preference. Diversity improves resilience only when routing, authentication, capacity reservation, and operational procedures are coordinated. A technically capable constellation can still fail if gateway power, terrestrial backhaul, or control-plane security is neglected. 11. Design Best Practices and LimitationsEffective satellite-network design begins with explicit requirements for latency, availability, geographic coverage, mobility, throughput, security, and regulatory compliance. Engineers should model worst-case and percentile performance rather than relying only on nominal values. Link budgets, gateway outages, rain attenuation, conjunction restrictions, software faults, and demand surges should be included in simulation. Protocol testing should use realistic delay, jitter, loss bursts, reordering, Doppler, and handover traces. Field trials are necessary because laboratory results may not capture antenna blockage, human operation, or gateway weather. Monitoring should collect both network metrics and user-perceived application metrics. Important limitations remain. A multi-orbit architecture increases integration cost and may create complex failure interactions. Onboard processing improves flexibility but increases radiation, software, and cybersecurity exposure. ISLs reduce gateway dependence but introduce pointing, acquisition, routing, and collision-related operational requirements. AI may improve prediction but cannot replace engineering validation and accountable decision-making. Chapter SummarySatellite networks range from transparent bent-pipe systems to regenerative, software-defined constellations with onboard switching and routing. Bent-pipe architectures are simpler and flexible, whereas regenerative systems can reduce gateway dependence and support advanced traffic engineering at the cost of payload and software complexity. Gateways, user terminals, control centres, and management systems collectively determine service performance. ISLs enable space-based forwarding and improve geographic resilience, but routing must account for predictable yet changing topology, delay, congestion, reliability, and handover risk. Satellite paths challenge TCP because of large RTT, variable delay, non-congestion losses, and intermittent connectivity. BDP, selective acknowledgement, window scaling, multipath, application adaptation, and carefully evaluated proxies are relevant tools. Mobility includes beam, satellite, gateway, and inter-orbit handover. Make-before-break, hysteresis, predictive geometry, buffering, and multi-connectivity improve continuity. QoS requires measurable service classes, admission control, scheduling, capacity reservation, and route diversity. GEO, MEO, and LEO have complementary properties, and integrated architectures can match orbit selection to application needs. Finally, constellation operations must integrate routing, spacecraft control, cybersecurity, regulation, autonomy, collision avoidance, and sustainability. The best architecture is not necessarily the one with the lowest nominal latency; it is the one that meets service objectives reliably under realistic operational constraints. Key TermsBent-pipe satellite: A transparent satellite that frequency-translates, amplifies, and retransmits signals without full demodulation and routing. Regenerative payload: A satellite payload that demodulates, processes, and retransmits regenerated signals. Gateway: An earth station connecting a satellite access network to terrestrial networks. Inter-satellite link: A communication link directly connecting two satellites. Feeder link: The link between a gateway and a satellite. Spot beam: A geographically focused satellite coverage beam. Beam handover: Transfer of a terminal between satellite spot beams. Satellite handover: Transfer of service between satellites. Gateway diversity: Use of geographically separated gateways for resilience. Bandwidth-delay product: Data rate multiplied by round-trip time. Round-trip time: Time required for a signal and its response to travel between endpoints. Adaptive coding and modulation: Adjustment of coding and modulation according to link conditions. Quality of service: Managed performance characteristics such as delay, loss, throughput, and availability. Contact-plan routing: Routing based on predicted future communication opportunities. Doppler shift: Frequency change caused by relative motion between transmitter and receiver. Network-control centre: Facility managing network configuration, capacity, routing, and performance. Telemetry, tracking, and command: Functions used to monitor and control spacecraft. Multi-orbit architecture: Network combining GEO, MEO, LEO, or other orbital layers. Performance-enhancing proxy: An intermediary that improves transport performance, often by splitting a connection. Review QuestionsShort Answer Questions1. What is the principal difference between a bent-pipe and a regenerative satellite? 2. Why are gateways important in satellite networks? 3. Define bandwidth-delay product and state its significance. 4. What is make-before-break handover? 5. Name two factors that should be included in a satellite-routing metric. Long Answer Questions1. Compare bent-pipe, regenerative, and hybrid satellite architectures in terms of performance, complexity, gateway dependence, and upgradeability. 2. Explain how ISLs affect routing, latency, resilience, and constellation operations. 3. Discuss the effects of satellite delay and non-congestion losses on TCP/IP performance and evaluate possible mitigation techniques. 4. Explain beam, satellite, gateway, and inter-orbit handover, including the role of hysteresis and predictive mobility management. 5. Compare GEO, MEO, and LEO systems and develop a rationale for an integrated multi-orbit architecture. Analytical / Application Questions1. A path has a bottleneck rate of 50 Mbit/s and an RTT of 800 ms. Calculate its BDP in megabits and megabytes, and explain the implication for TCP window sizing. 2. Design a QoS policy for emergency command, voice, video, and delay-tolerant sensor traffic in a disaster-response satellite network. Justify scheduling, redundancy, and admission-control decisions. 3. A LEO constellation experiences frequent handovers and intermittent gateway outages, while a GEO system has stable coverage but high delay. Propose a routing and service-continuity strategy for interactive and broadcast applications. Multiple Choice Questions with AnswersQuestion 1Which function is characteristic of a regenerative satellite payload? A. Only amplifying and frequency-translating the received waveform B. Demodulating and processing traffic before retransmission C. Providing terrestrial fibre backhaul D. Performing spacecraft collision avoidance exclusively Correct Answer: B. Demodulating and processing traffic before retransmission Question 2What does the bandwidth-delay product indicate? A. The minimum satellite antenna diameter B. The amount of data needed to keep a path busy during one RTT C. The probability of packet loss D. The number of gateways required Correct Answer: B. The amount of data needed to keep a path busy during one RTT Question 3A path rate is 100 Mbit/s and its RTT is 0.6 s. What is its BDP? A. 6 Mbit B. 60 Mbit C. 600 Mbit D. 1.67 Mbit Correct Answer: B. 60 Mbit Question 4Why can conventional TCP reduce its sending rate unnecessarily on satellite links? A. It interprets every long packet as encrypted B. It may interpret non-congestion losses as congestion C. It cannot use acknowledgements D. It always disables window scaling Correct Answer: B. It may interpret non-congestion losses as congestion Question 5Which handover approach establishes the new path before releasing the old path? A. Break-before-make B. Store-and-forward C. Make-before-break D. Contact-plan routing Correct Answer: C. Make-before-break Question 6What is a major advantage of an inter-satellite link? A. It eliminates all propagation delay B. It can reduce dependence on terrestrial gateways C. It prevents Doppler shift D. It removes the need for routing Correct Answer: B. It can reduce dependence on terrestrial gateways Question 7Which orbit generally provides the lowest typical propagation delay? A. GEO B. MEO C. LEO D. Highly elliptical orbit in every case Correct Answer: C. LEO Question 8Which metric is least appropriate as the sole routing criterion in a dynamic satellite network? A. Propagation delay B. Available capacity C. Link reliability D. Satellite colour Correct Answer: D. Satellite colour Question 9What is the main purpose of gateway diversity? A. To increase spacecraft mass B. To provide resilience against localized gateway failures or weather C. To eliminate authentication D. To prevent all satellite handovers Correct Answer: B. To provide resilience against localized gateway failures or weather Question 10Which application is most naturally suited to store-and-forward operation? A. Delay-sensitive conversational voice B. Interactive remote control requiring immediate feedback C. Non-urgent sensor data tolerant of delay D. Real-time collision avoidance commands Correct Answer: C. Non-urgent sensor data tolerant of delay
|