# Non-Terrestrial and Mobile Networks In these notes, I collect some information about Non-Terrestrial Networks and at the bottom I entertain some thoughts about designing and simulating a non-terrestrial network realized by a satellite constellation flying in a ring to provide connectivity services to ground-based sensors. All satellites in the ring connect utilizing inter-satellite [[Physical Layer#Free Space Optical Communication|links]]. ## A Quick Review on 4G/LTE The architecture of 4G/LTE (Long-Term Evolution) follows a flat, IP-based network model. The key components of the LTE architecture are: 1. **User Equipment (UE):** This includes devices like smartphones and IoT sensors. UEs connect to the network through the radio access network (RAN), exchanging data and control signals with base stations. 2. **Evolved Universal Terrestrial Radio Access Network (E-UTRAN):** The E-UTRAN consists of **eNodeBs** (evolved Node B), which are base stations that handle radio communication with UEs. eNodeBs manage tasks like radio resource management, scheduling, handovers, and encryption. Note that there can also be **ng-eNodeBs** (Next Generation Evolved Node B) which is a type of base station that operates in 5G networks while being compatible with the radio air interface of LTE. It is part of the 5G Non-Standalone (NSA) architecture, where 5G is deployed alongside an existing LTE infrastructure to enable faster rollouts and provide enhanced mobile broadband capabilities. 3. **Evolved Packet Core (EPC):** The EPC is the core network responsible for managing data and control plane traffic. It consists of: - **Mobility Management Entity (MME):** Handles signaling, mobility management, and authentication. - **Serving Gateway (SGW):** Routes and forwards user data between the E-UTRAN and the core network. - **Packet Data Network Gateway (PDN GW):** Connects to external data networks (e.g., the internet) and handles IP address allocation. - **Home Subscriber Server (HSS):** A database containing user subscription information and authentication credentials. 4. **IMS (IP Multimedia Subsystem):** Supports voice and multimedia services over IP, including VoLTE (Voice over LTE). LTE's flat architecture relies entirely on packet-switched data. This structure enables simpler handovers, efficient resource utilization, and support for advanced applications like HD video streaming and IoT. ### LTE Reference Points In LTE, the entities described above are connected through defined reference points (or interfaces). These reference points facilitate communication between network nodes. The main reference points in LTE are: 1. **Uu**: The interface between the User Equipment (UE) and the eNodeB (Evolved Node B). It is the radio interface responsible for transmitting user and control data over the air. 2. **S1**: The interface between the eNodeB and the Evolved Packet Core (EPC). It is divided into: - **S1-U**: The user plane interface connecting the eNodeB to the Serving Gateway (SGW) for user data transfer. - **S1-MME** or **S1-C**: The control plane interface connecting the eNodeB to the Mobility Management Entity (MME) for signaling and control. 3. **X2**: The interface between eNodeBs. It is used for signaling, user data forwarding during handovers, and inter-eNodeB coordination for load balancing and interference management. 4. **S6a**: The interface between the MME and the Home Subscriber Server (HSS). It is used for subscriber authentication, authorization, and access to subscription data. 5. **S11**: The interface between the MME and the SGW. It is used for control signaling, such as creating and managing bearer paths for user traffic. 6. **S5/S8**: The interface between the SGW and the Packet Data Network Gateway (PDN GW). It is used for user plane and control signaling. - **S5** is used within the same operator's network. - **S8** is used between different operators in a roaming scenario. 7. **SGi**: The interface between the PDN GW and external Packet Data Networks (PDNs), such as the internet, corporate intranets, or IMS (IP Multimedia Subsystem) networks. 8. **Gx**: The interface between the PDN GW and the Policy and Charging Rules Function (PCRF). It is used to manage policy control and charging rules for user sessions. 9. **Rx**: The interface between the PCRF and the application function (AF), which may reside in an IMS or another service network, for conveying policy requirements related to applications. 10. **S3**: The interface between the MME and the SGSN (Serving GPRS Support Node). It is used to support interoperation between LTE and 2G/3G networks during mobility. 11. **S4**: The interface between the SGSN and the SGW, facilitating interworking between LTE and legacy networks. 12. **S10**: The interface between MMEs. It supports signaling for inter-MME mobility management and handover. ![[Pasted image 20250114223221.png]] > [!Figure] > Interfaces in LTE (also shown with interworking with 3G. Also, the interface between UE and the E-UTRAN is called Uu, which is not shown in the figure) (source: #ref/Lescuyer ) ### LTE Air Interface The air interface is the radio link between the user equipment (UE) and the eNodeB. It is based on advanced radio access technologies designed to provide high data rates, low latency, and efficient spectrum utilization. The air interface relies on two key multiple access techniques: orthogonal frequency-division multiple access (OFDMA) for the downlink and single-carrier frequency-division multiple access (SC-FDMA) for the uplink. OFDMA in the downlink divides the available spectrum into multiple narrowband subcarriers that are orthogonal to each other, enabling simultaneous data transmission to multiple subscribers without interference. Each user is allocated a subset of these subcarriers, ensuring efficient spectrum usage. In contrast, the uplink uses SC-FDMA, which is a variation of OFDMA with an added single-carrier structure. SC-FDMA minimizes the peak-to-average power ratio (PAPR), reducing power consumption in the UE. This is critical for battery-powered devices, as it improves power efficiency while maintaining high data throughput. The LTE air interface operates in a time-division duplex (TDD) or frequency-division duplex (FDD) mode, depending on the deployment. In FDD, uplink and downlink transmissions occur on separate frequency bands, while in TDD, they share the same frequency band but are separated in time. The choice of duplexing depends on the operator's spectrum resources and deployment scenario. The physical layer of the air interface uses resource blocks (RB) as the fundamental unit for scheduling. Each resource block consists of a set of subcarriers over a defined time period, typically one millisecond. The eNodeB dynamically assigns these resource blocks to users based on their requirements and the network's traffic load. > [!warning] > This section is under #development ### LTE Protocols and CUPS (Control-User Plane Separation) CUPS, which stands for Control and User Plane Separation, is a network architecture concept adopted in LTE networks where network functions are traditionally divided into two primary planes: the control plane and the user plane. The control plane handles signaling and management tasks, such as authentication, mobility management, and session control, while the user plane is responsible for forwarding user data packets. CUPS separates these two planes, allowing them to operate independently. In the LTE architecture, this separation is most evident in the Evolved Packet Core (EPC), particularly between the Serving Gateway (SGW) and Packet Data Network Gateway (PDN GW). With CUPS, the control plane functions of the SGW and PDN GW are handled by dedicated control plane nodes, while the user plane functions are managed by separate user plane nodes. This separation provides several advantages. It enhances scalability because the control plane and user plane resources can be scaled independently based on demand. For example, if there is a sudden increase in user traffic but not in signaling, only the user plane resources need to be scaled. CUPS also improves network flexibility by allowing operators to deploy the control and user plane nodes in different locations. This is particularly useful for edge computing scenarios, where the user plane nodes can be positioned closer to the end users to reduce latency, while the control plane nodes remain centralized for easier management. Additionally, CUPS facilitates the deployment of virtualized network functions and supports the transition to cloud-native architectures. By decoupling the control and user planes, network functions can be implemented as software modules running on general-purpose hardware, enabling more dynamic and cost-effective network management. ![[Pasted image 20250114173316.png]] > [!Figure] > LTE Control Plane Protocols (source: #ref/Lescuyer ) Starting from the top of the picture above, the RRC layer (Radio Resource Control) supports all the signalling procedures between the terminal and the eNodeB. This includes mobility procedures as well as terminal connection management. The signaling from the EPC Control plane (e.g. for terminal registration or authentication) is transferred to the terminal through the RRC protocol, hence the link between the RRC and upper layers. The PDCP layer (whose main role consists of header compression and implementation of security such as encryption and integrity) is offered to Radio Bearers by E-UTRAN lower layers. Each of these bearers corresponds to a specific information flow such as User plane data (e.g. voice frames, streaming data, IMS signaling) or Control plane signalling (such as RRC or NAS signlling issued by the EPC). Due to their specific purpose and handling, information flows generated by System Information Broadcast and Paging functions are transparent to the PDCP layer. The RLC layer provides to the PDCP layer basic OSI-like Layer 2 services such as packet data segmentation and ARQ (Automatic Repeat Request) as an error-correction mechanism. There is one-to-one mapping between each RLC input flow and Logical channels provided by RLC to the MAC layer. The MAC layer’s main task is to map and multiplex the logical channels onto the transport channels after having performed priority handling on the data flows received from the RLC layer. The flows being multiplexed on a single transport channel may be originated by a single user or multiple users. The MAC also supports HARQ (Hybrid ARQ), which is a fast repetition process. Finally, the MAC delivers the transport flows to the PHY layer, which will apply the channel coding and modulation before transmission over the radio interface. ![[Pasted image 20250115141520.png]] >[!Figure] >Protocol layered structure in eNodeB for downlink channels (source: #ref/Lescuyer ) > [!info] > One of the architecture decisions made in 3GPP was to exclude ARQ functionality from the Core Network Serving Gateway and to terminate ARQ in UE and eNodeB. This leads to the question of whether E-UTRAN should use only a single (H)ARQ protocol or a two-layer approach with HARQ and ARQ located at the RLC layer on top. It can be shown that achieving the required reliability with a single HARQ layer can be very costly in terms of resources needed for HARQ feedback. Thus, it has been decided that a two-layered ARQ/HARQ approach was the best way of achieving both high reliability and low resource cost for the ARQ/HARQ feedback. > [!info] > In LTE, paging is required to locate a UE in the network when it is in an Idle state, making its exact location in the network unknown. Paging procedures are used by the network to: > >- Request establishment of a non-access stratum (NAS) signaling connection between the MME and the UE to support a network service request. > >- Prompt the UE to reattach itself to the network after a network failure. > >- Initiate a mobile Circuit Switched Fallback (CSFB) procedure. The user plane protocols are depicted in the figure below. ![[Pasted image 20250114173143.png]] > [!Figure] > LTE User Plane Protocols (source: #ref/Lescuyer ) ### LTE Radio Channels We spoke about control plane and user plane in the previous sections. But how are those planes traveling through the air interface in LTE? Is the control plane in some different frequency than user plane? It wouldn't be cost-effective to have control and user plane on different frequencies or channels, so LTE finds a way of sending/receiving both over the same channel[^121]. This hardly anything too revolutionary, and a mechanism used in general in wireless communications for transferring data with different QoS (Quality of Service, mostly priority and latency in this case) requirements over the same radio channel, which allows one physical channel to be divided into multiple separate logical data channels, sometimes also called virtual channels. Each virtual/logical channel carries a separate sequence of data units, which may have different QoS requirements from those carried on the other virtual channels. In general, it is critical that signaling messages are transmitted as fast as possible, using the best error-protection scheme. On the other hand, the user plane (voice or data streaming applications) can accept a reasonable frame loss due to radio transmission. Interactive connection-oriented applications (such as Web browsing) are also different, as the end-to-end retransmission can help to recover from radio propagation issues. In order to be flexible and allow different schemes for data transmission, the E-UTRAN specifications introduce several types of channels: - The logical channels – what is transmitted. - The transport channels – how it is transmitted. - The physical channels. The logical channels correspond to data-transfer services offered by the radio interface protocols to upper layers. Basically, there are only two types of logical channels: the control channels (for the transfer of Control plane information) and the traffic channels (for the transfer of User plane information). Each of the channels of these two categories corresponds to a certain type of information flow. The E-UTRAN logical control channels are: - The BCCH (Broadcast Control Channel): this channel is a downlink common channel, used by the network to broadcast E-UTRAN system information to the terminals presents in the radio cell. This information is used by the terminal, e.g. to know serving cell network operator, to get information about the configuration of the cell common channels, how to access to the network, etc. - The PCCH (Paging Control Channel): the PCCH is a downlink common channel which transfers paging information to terminals presents in the cell, e.g. in case of mobile-terminated communication session. - The CCCH (Common Control Channel): the CCCH is a special kind of transport channel, used for communication between the terminal and E-UTRAN when no RRC connection is available. Typically, this channel is used in the very early phase of a communication establishment. - The MCCH (Multicast Control Channel): this channel is used for the transmission of MBMS (Multimedia Broadcast and Multicast Service) information from the network to one or several terminals. - The DCCH (Dedicated Control Channel): the DCCH is a point-to-point bi-directional channel supporting control information between a given terminal and the network. In the DCCH context, the control information only includes the RRC and the NAS signalling. The spplication-level signalling (such as SIP of RTCP) is not handled by the DCCH. The E-UTRAN logical traffic channels are: - The DTCH (Dedicated Traffic Channel): the DCCH, the DTCH is a point-to-point bidirectional channel, used between a given terminal and the network. It can support the transmission of user data, which include the data themselves as well as application-level signaling associated to the data flow. - The MTCH (Multicast Traffic Channel): a point-to-multipoint data channel for the transmission of traffic data from the network to one or several terminals. As for the MCCH, this channel is associated to the MBMS service (Multimedia Broadcast and Multicast Service). The transport channels describe how and with what characteristics data are transferred over the radio interface. For example, the transport channels describe how the data are protected against transmission errors, the type of channel coding, CRC protection or interleaving which is being used, the size of data packets sent over the radio interface, etc. All this set of information is known as the "Transport Format". As in the specification, the transport channels are classified into two categories: the downlink transport channels (from the network to the terminal) and the uplink transport channels (from the terminal to the network). The E-UTRAN downlink transport channels are: - The BCH (Broadcast Channel), associated to the BCCH logical channel. The BCH has a fixed and predefined Transport Format, and shall cover the whole cell area. - The PCH (Paging Channel), associated to the BCCH. - The DL-SCH (Downlink Shared Channel), which is used to transport user control or traffic data. - The MCH (Multicast Channel), which is associated to MBMS user of control information transport. The E-UTRAN uplink transport channels are: - The UL-SCH (Uplink Shared Channel), which is the uplink equivalent of the DL-SCH. - The RACH (Random Access Channel), which is a specific transport channel supporting limited control information, e.g. during the early phases of communication establishment or in case of RRC state change. The physical channels are the actual implementation of the transport channel over the radio interface. They are only known to the physical layer of E-UTRAN and their structure is tightly dependent on physical interface [[Non-Terrestrial and Mobile Networks#A Quick Review on 5G#OFDM|OFDM]] characteristics. The physical channels defined in the downlink are the: - Physical Downlink Shared Channel (PDSCH) – which carries user data and higher-layer signaling. - Physical Downlink Control Channel (PDCCH) – this channel carries scheduling assignments for the uplink. - Physical Multicast Channel (PMCH) – which carries Multicast/Broadcast information. - Physical Broadcast Channel (PBCH) – which carries System Information. - Physical Control Format Indicator Channel (PCFICH) – which informs the UE about the number of OFDM symbols used for the PDCCH. - Physical Hybrid ARQ Indicator Channel (PHICH) – which carries ACK and NACK eNodeB responses to uplink transmission, relative to the HARQ mechanism. The physical channels defined in the uplink are the: - Physical Uplink Shared Channel (PUSCH) – which carries user data and higher-layer signaling. - Physical Uplink Control Channel (PUCCH) – this channel carries uplink control information, including ACK and NACK responses from the terminal to downlink transmission, relative to the HARQ mechanism. - Physical Random Access Channel (PRACH) – which carries the random access preamble sent by terminals to access to the network. ![[Pasted image 20250115140202.png]] > [!Figure] > E-UTRAN mapping between channel types (source: #ref/Lescuyer ) > [!warning] > This section is under #development ## A Quick Review on 5G > [!Note] > This is only a brief review of 5G, which is kind of a monstrous stack of technologies, encompassing radio technology, hardware, software, cloud technologies and virtualization. For more details, check the [[site/Resources/Software-Defined Comms/References|references]]. 5G, the fifth generation of cellular network technology, sits on the shoulders of historical cellular networks, a journey that spans several decades and technological milestones. The first generation (1G), introduced in the 1980s, marked the transition from analog to digital communications with 2G in the 1990s. This era saw the proliferation of mobile phones and the introduction of SMS and basic data services. The early 2000s witnessed the advent of 3G, which brought improved data connectivity, enabling more complex applications like mobile internet and video calls. The subsequent emergence of [[Non-Terrestrial and Mobile Networks#A Quick Review on 4G/LTE|4G]] in the 2010s further revolutionized the landscape with faster data speeds and support for high-definition mobile video and advanced gaming. The arrival of 5G, beginning around 2019, marked a significant improvement with higher speeds, lower latency, and greater capacity compared to its predecessors. 5G technology utilizes a broader spectrum of frequencies, including millimeter waves, which are higher frequency bands previously unused in mobile communications. This allows for faster data transmission rates, potentially up to 100 times faster than 4G. One of the key features of 5G is its low latency, which is the time it takes for a signal to travel from the source to the destination and back. This is particularly relevant for applications requiring real-time responses, such as autonomous vehicles, remote surgery, and advanced gaming. The reduced latency of 5G enhances the responsiveness of these applications, making them more efficient and reliable. 5G also addresses the challenge of network congestion. With an increasing number of devices connecting to the Internet, including not only phones and computers but also a myriad of IoT (Internet of Things) devices, 4G networks have struggled to keep up with the demand. 5G's greater bandwidth and advanced antenna technology enable it to handle many more devices simultaneously, making it an ideal solution for urban areas and crowded events. In terms of deployment, 5G networks initially rolled out in major cities and are gradually expanding to cover more areas. The infrastructure for 5G is distinct from previous generations, requiring the installation of new cell towers and small cell sites to accommodate its higher-frequency signals. This has led to a staggered rollout, with full global coverage still a work in progress. The potential applications of 5G extend beyond smartphones. It is poised to play a critical role in the development of smart cities, where it can support advanced public services, traffic management, and energy distribution. In industry, 5G is expected to enable more efficient factory automation, real-time monitoring, and predictive maintenance. ### 5G Architecture ==The 5G architecture heavily inherits from its predecessor 4G, and is also based on two distinct but interconnected parts: the Radio Access Network (RAN) and the core network (5GC). In this apparent simplicity, ironically, a great deal of complexity is hidden. Although these two "sides" of 5G are intimately related, in fact, the core network has been designed to be RAN-independent, which marked a fundamental shift in the design compared to previous generations.== This means that a 5GC could talk to an E-UTRAN, creating attractive interworking architectures. The RAN is responsible for all radio-related functionality of the overall network, including modulation and demodulation, coding, retransmission protocols, and multi-antenna schemes. The 5G core network is responsible for functions not related to the radio access but needed for providing a complete network. This includes: - Data Routing and Switching: It routes data to and from the internet and other networks. - Session Management: 5GC handles the creation, modification, and release of sessions for user devices. - Mobility Management: It manages the registration of devices in the network and tracks their location for seamless connectivity. - Policy Enforcement: The core network enforces rules related to user data rates, access priorities, and charging. - Network Slicing: A significant feature of 5GC is the ability to create multiple virtual networks (network slices) over the same physical infrastructure, each optimized for specific services or types of traffic. The 5G Core can be visualized and described in two different ways. The first visualization shows the way a collection of "network functions" (NF) are connected. The major difference compared to previous architectures in this visualization is the concept of Service-Based interfaces (SBI, or SBA for [[Software#Service-Oriented|service-based architecture]]). It means that the network functions that include logic and functionality for processing of signaling flows are not interconnected through point-to-point interfaces but instead expose and make available services to the other network functions. For each interaction between network functions, one of these acts as a "Service Consumer", and the other as a "Service Producer". This representation of the architecture is shown in the figures below. Note that there are way more network functions and reference points compared to LTE/4G, showcasing a strong orientation to [[Software#Microservices|microservices]].  > [!Figure] > _Network functions using Service-Based interfaces and APIs_ The other visualization of the architecture illustrates how network functions interact with other network functions represented by traditional point-to-point interfaces. Showing these interfaces can be useful to illustrate which of the network functions utilize, or consume, the services of which other network functions. Even if all the network functions in theory could be connected in a full connectivity mesh, the actual call flows define which service combinations that apply in real operations. These combinations are visualized as logical interfaces, or more correctly, reference points, in the view shown in the two figures below.  > [!Figure] > _5G Core architecture visualized with Service-Based interfaces_  > [!Figure] > _5G core visualized with point-to-point interfaces_ The communication method defined for building blocks in the 5G Core relies on RESTful interfaces using HTTP requests. Being a widely adopted scheme in networking applications today, it allows for tighter integration between the mobile networks and underlying IT infrastructure, as well as allowing for shorter and simplified service development efforts. The expectation is that the network capabilities shall be easier to extend when using the relatively lightweight Service Based Interface (SBI) concept, than if using a more traditional point-to-point architecture that relies on detailed and extensive protocol specification efforts. Using Service-based interfaces and APIs can also be seen as a logical choice by 3GPP when specifying the 5G Core Network, as the 5GC software applications that implement the Network Functions are assumed to be executing in an IT-like or even shared IT environment, typically in a cloud data center. A harmonization of both software technologies and IT architecture across the mobile network solution and supporting IT applications is to some extent possible with this approach. The core network functions utilize HTTP REST requests for service-based communication. They are logically interconnected to a common networking infrastructure. HTTP REST uses message syntax from the widely used HTTP web protocol and relies on the concept of Resource Modeling, which means that a distributed software application can be addressed through Uniform Resource Identifiers (URIs), in practice a web address pointing at a resource or set of resources. An important aspect of REST is that all communication must include the full set of information needed for a specific processing action. It must not rely on previous messages, and hence it can be considered as stateless. Utilizing this principle for software design allows for excellent scalability and distribution capabilities for the system. > [!Note] > HTTP is a request-response protocol that runs between a client and a server. The protocol is carried over TCP to ensure reliable transmission. HTTP 1.1 could also be carried over other transport protocols but HTTP/2 is specified to be carried only over TCP. 3GPP has discussed using HTTP with [[Security#Securing Lower Layers|QUIC transport]] (HTTP over QUIC is also referred to as HTTP/3) but it was left out since it was not mature enough for rel-15. The use of HTTP over QUIC is however being studied and will potentially be specified in a future 3GPP release. >[!Info] >5G uses a much higher bandwidth than LTE/4G: 100MHz for frequency bands below 6GHz, and up to 400MHz for frequency bands over 6 GHz. #### Network Functions In a 5G network, each Network Function (NF) plays a specific role. Here's a description of each key NF with a brief explanation of their roles: - User Equipment (UE): These are the devices used by end-users to connect to the network, such as smartphones, and IoT devices like sensors. UEs are the starting point for communications and are responsible for initiating connection requests and data transmission. - ==gNodeB (gNB): The gNB is the base station in 5G networks, responsible for managing radio communications with UEs. It handles radio resource management, signal transmission and reception, and the initial connection to the network core.== - Access and Mobility Management Function (AMF): AMF manages access to the network and the mobility of UEs. It handles registration, authentication, session management, and handovers as UEs move across different gNBs, ensuring continuous connectivity. - Session Management Function (SMF): SMF is responsible for establishing, maintaining, and terminating data sessions. It manages IP address allocation, session context, and ensures that data flows are properly routed within the network. - ==User Plane Function (UPF): UPF handles the routing and forwarding of user data. It is a critical component in the data plane, directing traffic from the 5G network to external networks and vice versa.== - Authentication Server Function (AUSF): AUSF is key for network security, handling the authentication of UEs. It verifies user credentials and generates security keys for encrypted communications. - Unified Data Management (UDM): UDM centralizes subscriber data management, storing and managing user profiles, subscription data, and service authorizations. It supports various network functions by providing necessary user information. - Unified Data Repository (UDR): UDR serves as a centralized database for storing user and session data. It is accessed by various NFs for retrieving and updating information, which is important for session management and personalized services. - Policy Control Function (PCF): PCF provides policy rules for network resource usage and service quality. It manages and applies policies for traffic handling, resource allocation, and charging. - Network Slice Selection Function (NSSF): NSSF is responsible for selecting the appropriate network slice based on the service requirements and UE subscription data. - Network Exposure Function (NEF): NEF provides a secure interface for external applications to access network capabilities. It acts as a gateway for third-party services, exposing network functionalities while maintaining security and privacy. - Network Repository Function (NRF): NRF acts like a directory service for the 5G network, managing the discovery and registration of NFs. It helps NFs find each other and establish communication, ensuring efficient operation of the network. - Application Function (AF): AF represents external applications that require communication with the core network. It interacts with the core network to influence traffic routing and QoS (Quality of Service) for specific applications or services. > [!Note] > In 5G jargon, a network _slice_ is a logical network serving a defined business purpose or customer, consisting of all required network resources configured together. These interactions are designed to be flexible and scalable, using API-based communication in the Service-Based framework. This setup allows the 5G network to handle diverse services, from high-speed internet access to low-latency applications for IoT and industrial uses. The modular nature of these interactions also enables the network to adapt to future technological advancements and service requirements. Following the reference points perspective of 5GC, the interfaces between different network functions (NFs) specify the protocols and data that can be exchanged between them. Here's an overview of some key reference points in the 5G Core network: - N1 Interface: - Connects User Equipment (UE) to the Access and Mobility Management Function (AMF). - Being purely a logical connection (between UE and AMF there's the gNodeB), it is responsible for signaling related to NAS (Non-Access Stratum), which includes mobility management, session management, and security control. ==N1 needs a working RRC and NGAP connection in place.== - N2 Interface: - Links the gNodeB (gNB) with the AMF. - Handles the control plane signaling for setting up the user and control plane connections. This includes PDU session management, UE mobility management, and more. - N3 Interface: - Connects the gNB with the User Plane Function (UPF). - Used for user plane data transfer, carrying the traffic between the radio network and the 5GC. - N4 Interface: - Connects the Session Management Function (SMF) with the UPF. - Facilitates the management and control of user plane tunnels and traffic forwarding. - N6 Interface: - Connects the UPF to data networks, such as the internet or operator services. - Responsible for the transfer of user data between the 5GC and external data networks. - It can use IP or even Ethernet for carrying traffic to/from the Data Network - N7 Interface: - Links the SMF with the Policy Control Function (PCF). - Used for policy control signaling, allowing the SMF to request policy rules and decisions from the PCF. - N8 Interface: - Connects the AMF with the UDM (Unified Data Management). - Used for accessing subscription information and authentication credentials stored in the UDM. - N9 Interface: - Connects UPFs within the 5G Core. - Used for the transfer of user data when UPFs are chained or when traffic needs to be forwarded between different UPFs. - N10/N11 Interface: - Connects the AMF and SMF. - Used for signaling related to session management, such as session establishment, modification, and release. In the 5GC architecture, network functions can be clients or servers. An NF producing a service (i.e., acting as an HTTP server) can register itself, including its IP address and port for the service in NRF. The consumer NF (i.e., the entity acting as HTTP client) can then discover from the NRF what IP address and optionally port number to connect to for a specific NF service. If a producer NF does not register any port number in NRF then the default port numbers for HTTP and HTTPS will be used. Once the TCP connection is established the client can send a HTTP request to the server via that TCP connection. Multiple outstanding HTTP requests can be sent on a single TCP connection. This is one of the key benefits of HTTP/2 as it improves the possibility for multiplexing HTTP request/response pairs over a single TCP connection, allowing a fewer number of TCP connections to be used compared to HTTP 1.1. It can be mentioned that HTTP 1.1 includes a feature called pipelining that allows some level of multiplexing, but it has severe limitations and is not as capable as HTTP/2. In 3GPP 5GC, a resource can, e.g., be a PDU Session (for services produced by SMF), a policy session (for services produced by PCF), or subscription data (for services produced by UDM). Each resource is identified by a Uniform Resource Identifier (URI). A very common form of the URI is the Uniform Resource Locator (URL), which is a special type of URI that both identifies a resource and also provides information on how to access that resource, e.g., using a protocol such as HTTP. In 5GC, the URI in the request message uniquely identifies the resource in the producer NF. An absolute URI for a Service-Based interface 5G core has the following structure: `{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart} ` The `apiRoot` is a concatenation of several parts: - scheme (“http” or “https”) - a fixed string “://” - host and optional port (so-called “authority”) - an optional deployment-specific string (API prefix) that starts with a “/” character. The `apiName` defines the name of the API and the `apiVersion` indicates the version of the API. The `apiRoot`, `apiName` and `apiVersion` together define the base URI of the API, and then each `apiSpecificResourceUriPart` defines a resource URI relative to this base URI. The structure and content of the `apiSpecificResourceUriPart` differs depending on the type of service. E.g. UDM the client NF sends requests for “provisioned” resources such as subscription data, with a URI that includes, e.g., SUPI. An example could look like "https://udm1.operatorX.com/nudm-sdm/v1/imsi1234567890/sm-data", where the IMSI in this example is “1234567890”. For SMF and AMF the resources are instead dynamically created at run-time, for instance, when the UE registers or a PDU Session is established. The URI can thus not be as static as in the UDM example. Instead, the producer NF (server) returns a resource reference to the consumer NF (client) in the first reply message. Later when the consumer wants to address that specific resource (e.g., PDU Session in SMF), a URI including that resource reference is used. An example could be "https://smf3.operatorY.com/nsmfpdusession/v1/sm-contexts/347c3edf-129a-276e-e4c7-c48e7b515605", where the last part is the resource reference. After receiving an HTTP request, the server, which has access to the resource, parses the request and may perform functions on behalf of the client, and then returns a response message to the client. The response includes status information about the transaction and typically contains the requested content (a representation of the requested resource). #### Service-Based Interfaces In the 5G Core (5GC) network, Service-Based Interfaces (SBIs) are used to facilitate communication between different Network Functions (NFs). These interfaces are part of the Service-Based Architecture (SBA) that 5G adopts, which emphasizes modular design and uses modern web-based communication protocols, primarily HTTP/2. Each SBI is defined for specific interactions between network functions. Here are some of the key SBIs in the 5G Core: - Nnrf Interface: - Between Network Functions (NFs) and the Network Repository Function (NRF). - Used for service discovery and NF registration. NFs use this interface to register their services with the NRF and to find other NFs in the network. - Nsmf Interface: - Between the Session Management Function (SMF) and other NFs. - Used for session management-related communication, including session establishment, modification, and release. - Namf Interface: - Between the Access and Mobility Management Function (AMF) and other NFs. - Handles mobility management, connection management, and reachability aspects of communication. - Nausf Interface: - Between the Authentication Server Function (AUSF) and other NFs. - Used for authentication and authorization services, ensuring secure access to network resources. - Nudm Interface: - Between the Unified Data Management (UDM) and other NFs. - Used for accessing subscription data, authentication credentials, and other user-related information. - Npcf Interface: - Between the Policy Control Function (PCF) and other NFs. - Handles policy control decision-making and provides policy rules for other NFs. - Nnef Interface: - Between the Network Exposure Function (NEF) and other NFs. - Provides a controlled and secure way for external applications to access network capabilities and events. - Naf Interface: - Between Application Functions (AFs) and the 5G Core network. - Used for application-related communication, allowing AFs to influence traffic routing, Quality of Service (QoS), and other network behaviors. These SBIs are characterized by their flexibility, scalability, and adherence to modern IT practices. They allow for a more dynamic and programmable network environment, which is essential for the diverse range of services and applications supported by 5G. The use of HTTP/2 as the foundational protocol for these interfaces also aligns 5G networks with the broader trends in cloud computing and service-oriented architectures.  > [!Figure] > _Essential 5G core: these are the Network Functions that cannot be excluded from any 5G Core deployment ("the core of the core")_  > [!Figure] > _Essential 5G core (with interface names. ==Errata: where it reads N5 between UPF and DN, it should be N6==)_ ### OFDM Orthogonal Frequency Division Multiplexing (OFDM) is a method used in many wireless communication systems, including LTE and 5G, to transmit data efficiently in tight spectrums. In OFDM, the data is divided into multiple subcarriers, each modulated by a separate carrier frequency. The subcarriers are orthogonal to each other, which means their spectra overlap but do not interfere with each other. In the OFDM process, the original data bits are mapped onto symbols of a constellation using a modulation scheme like QPSK, QAM, etc. These symbols are then assigned to subcarriers. This step can be thought of as moving the data into the frequency domain because each symbol is associated with a specific frequency (subcarrier). After mapping, we have a set of symbols that represent the amplitude and phase of each subcarrier. This is essentially a frequency domain representation where each subcarrier has a specific frequency and corresponding complex symbol. The Inverse Fast Fourier Transform (IFFT) is then used to convert this frequency domain representation (symbols on subcarriers) back into the time domain. The IFFT takes the complex symbols (frequency domain) and transforms them into a time-domain OFDM signal. >[!info] >Consider the case of one subcarrier and 16-QAM. The subcarrier takes one of 16 possible quadrature amplitudes and transmits four bits per symbol. Now extend it to two subcarriers: each of them takes one of 16 amplitudes, independently. Then, one OFDM symbol transmits eight bits (four per subcarrier). This process can be extended to any number of subcarriers. Let's delve deeper into the concept of orthogonality in OFDM and how it relates to subcarrier spacing and symbol duration #### Orthogonality in OFDM In OFDM, subcarriers must be orthogonal to each other. But what does it mean when signals are orthogonal? This orthogonality means that even though subcarriers overlap in the frequency domain, they do not interfere with each other. Orthogonality means ensuring that each subcarrier is a sinusoid that completes an integer number of cycles over the symbol duration. Despite the presence of sidebands (remember subcarriers are modulated either in amplitude or phase), the primary frequency components of subcarriers remain orthogonal if the subcarrier spacing is maintained as $\large \Delta f = \frac{1}{T_{\text{useful}}}$. #### Sinusoids and Orthogonality 1. **Sinusoidal Waves**: Each subcarrier is represented by a sinusoidal wave in the time domain. $\large \text{Subcarrier}_k(t) = e^{j 2\pi f_k t}$ where $f_k$ is the frequency of the k-th subcarrier. 2. **Integer Number of Cycles**: ==For the subcarriers to be orthogonal, each subcarrier must complete an integer number of cycles within the symbol duration $T_{\text{useful}}$.== #### Mathematical Basis Consider two subcarriers with frequencies $f_k$ and $f_m$. The orthogonality condition is given by: $\large \int_0^{T_{\text{useful}}} e^{j 2\pi f_k t} e^{-j 2\pi f_m t} dt = 0 \quad \text{for} \quad k \neq m$ This integral evaluates to zero if and only if the frequencies are spaced such that each subcarrier completes an integer number of cycles within $T_{\text{useful}}$. We explained this orthogonality thing in more detail in the [[Semiconductors#Digital Signal Processing|DSP]] section since it's actually an essential feature of how the Fourier transform works. We will see how OFDM takes advantage of orthogonality and Fourier Transform soon. #### Subcarrier Spacing and Symbol Duration ##### Inverse Relationship The subcarrier spacing $\Delta f$ and the useful symbol duration $T_{\text{useful}}$ are inversely related: $\large \Delta f = \frac{1}{T_{\text{useful}}}$ This equation ensures that each subcarrier completes an integer number of cycles within the symbol duration, maintaining orthogonality. #### Explanation 1. **Frequency Domain**: - Subcarriers are evenly spaced in the frequency domain by $\Delta f$. - For example, if the subcarrier spacing is 312.5 kHz, the subcarriers are at 0, 312.5 kHz, 625 kHz, and so on. 2. **Time Domain**: - Each subcarrier corresponds to a sinusoidal wave in the time domain. - ==The useful symbol duration $T_{\text{useful}}$ must be long enough for these sinusoids to complete an integer number of cycles.== 3. **Orthogonality Condition**: - If $T_{\text{useful}}$ is the reciprocal of $\Delta f$, then each subcarrier completes an integer number of cycles within $T_{\text{useful}}$. - This integer cycle completion ensures that when the signal is demodulated (using FFT), the subcarriers do not interfere with each other. #### Example - **Subcarrier Spacing ($\Delta f$)**: 312.5 kHz - **Useful Symbol Duration $(T_{\text{useful}})$**: $\large \frac{1}{312.5 \times 10^3} = 3.2 \mu\text{s}$ Suppose we have 4 subcarriers: 1. **Subcarrier Frequencies**: 0, 312.5 kHz, 625 kHz, 937.5 kHz 2. **Time Domain Representation**: - Subcarrier 1 (0 Hz): Completes 0 cycles in \(3.2 \mu\text{s}\). - Subcarrier 2 (312.5 kHz): Completes 1 cycle in \(3.2 \mu\text{s}\). - Subcarrier 3 (625 kHz): Completes 2 cycles in \(3.2 \mu\text{s}\). - Subcarrier 4 (937.5 kHz): Completes 3 cycles in \(3.2 \mu\text{s}\). These integer cycles ensure that when the signal is sampled over $T_{\text{useful}}$, the sinusoids are orthogonal, leading to no interference between subcarriers. #### Impact on Symbol Rate 1. **Symbol Duration**: - The total symbol duration $T_{\text{symbol}}$ includes $T_{\text{useful}}$ and $T_{\text{cp}}$. - For a given subcarrier spacing, $T_{\text{useful}}$ is fixed, and $T_{\text{symbol}}$ is slightly longer due to $T_{\text{cp}}$. 2. **Symbol Rate**: - The symbol rate is the inverse of $T_{\text{symbol}}$. - With wider subcarrier spacing (larger $\Delta f$), $T_{\text{useful}}$ is shorter, leading to a higher symbol rate. #### Data Rate The data rate depends on: - The number of subcarriers $N$. - The modulation scheme (bits per subcarrier). - The symbol rate (determined by $T_{\text{symbol}}$). $\large \text{Data Rate} = \left( N \times \text{Bits per Subcarrier} \right) \times \text{Symbol Rate}$ #### Example code The code below demonstrates in a rather naive way the process of encoding, OFDM modulation, transmission, reception, demodulation, and verification of the data streams using the ASCII code for "hello world": ```python import numpy as np import matplotlib.pyplot as plt # Convert a string to its binary representation def string_to_binary(data): return ''.join(format(ord(c), '08b') for c in data) # Convert binary data to a string def binary_to_string(data): chars = [chr(int(data[i:i+8], 2)) for i in range(0, len(data), 8)] return ''.join(chars) # OFDM modulation def ofdm_modulate(data_bits, carriers, fft_size): symbols = np.array([int(bit) for bit in data_bits]) if len(symbols) % carriers != 0: symbols = np.append(symbols, [0] * (carriers - len(symbols) % carriers)) symbols = symbols.reshape(-1, carriers) ifft_data = np.fft.ifft(symbols, n=fft_size) return ifft_data.flatten() # OFDM demodulation def ofdm_demodulate(ofdm_signal, carriers, fft_size): symbols = ofdm_signal.reshape(-1, fft_size) fft_data = np.fft.fft(symbols, n=fft_size) return np.round(fft_data[:, :carriers].real).flatten().astype(int) # Parameters data = "hello world" carriers = 8 fft_size = 16 # Encode the data binary_data = string_to_binary(data) # OFDM Modulate ofdm_signal = ofdm_modulate(binary_data, carriers, fft_size) # Simulate transmission and reception (ideal conditions) received_signal = ofdm_signal # OFDM Demodulate demodulated_bits = ofdm_demodulate(received_signal, carriers, fft_size) # Decode the data demodulated_bits_str = ''.join(map(str, demodulated_bits)) received_data = binary_to_string(demodulated_bits_str[:len(binary_data)]) # Display results print(f"Original data: {data}") print(f"Received data: {received_data}") # Convert binary strings to list of integers for plotting transmitted_bits = [int(bit) for bit in binary_data] received_bits = [int(bit) for bit in demodulated_bits_str[:len(binary_data)]] # Create a time axis for the bit streams time_axis = np.arange(len(transmitted_bits)) # Plot the transmitted and received bit streams plt.figure(figsize=(14, 6)) # Plot transmitted bit stream plt.subplot(2, 1, 1) plt.step(time_axis, transmitted_bits, where='mid', label='Transmitted Bits') plt.title('Transmitted Bit Stream') plt.xlabel('Bit Index') plt.ylabel('Bit Value') plt.ylim(-0.2, 1.2) plt.legend() plt.grid(True) # Plot received bit stream plt.subplot(2, 1, 2) plt.step(time_axis, received_bits, where='mid', color='orange', label='Received Bits') plt.title('Received Bit Stream') plt.xlabel('Bit Index') plt.ylabel('Bit Value') plt.ylim(-0.2, 1.2) plt.legend() plt.grid(True) # Show the plots plt.tight_layout() plt.show() ``` Whose output is: ![[Pasted image 20240712071248.png]] ### 5G Protocol Stack A general overview of the NR user-plane protocol architecture for the downlink is illustrated in the figure below. Note that 5G splits the network stack into the User Plane (UP) and Control Plane (CP).  > [!Figure] > _User-plane and control-plane protocol stack between UE and AMF._ Many of the protocol layers are similar to those in 4G(LTE), although there are some differences as well. One of the differences is the QoS handling in NR when connected to a 5G core network, where the SDAP protocol layer accepts one or more QoS flows carrying IP packets according to their QoS requirements.  > [!Figure] > _NR downlink user-plane protocol architecture as seen from the device._ The uplink protocol structure is similar to the downlink structure in the figure above, although there are some differences with respect to, for example, transport-format selection and the control of logical-channel multiplexing. The different protocol entities of the radio-access network (User Plane) are summarized below. - Service Data Application Protocol (SDAP) is responsible for mapping QoS bearers to radio bearers according to their quality-of-service requirements. This protocol layer is not present in LTE but is introduced in NR when connecting to the 5G core network due to the new quality-of-service handling. - Packet Data Convergence Protocol (PDCP) performs IP header compression, ciphering, and integrity protection. It also handles retransmissions, in-sequence delivery, and duplicate removal in the case of handover. For dual connectivity with split bearers, PDCP can provide routing and duplication. Duplication and transmission from different cells can be used to provide diversity for services requiring very high reliability. There is one PDCP entity per radio bearer configured for a device. - Radio-Link Control (RLC) is responsible for segmentation and retransmission handling. The RLC provides services to the PDCP in the form of RLC channels. There is one RLC entity per RLC channel (and hence per radio bearer) configured for a device. Compared to LTE, the NR RLC does not support in-sequence delivery of data to higher protocol layers, a change motivated by the reduced delays as discussed below. - Medium-Access Control (MAC) handles the multiplexing of logical channels, hybrid-ARQ retransmissions, and scheduling and scheduling-related functions. The scheduling functionality is located in the gNB for both uplink and downlink. The MAC provides services to the RLC in the form of logical channels. The header structure in the MAC layer has been changed in NR to allow for more efficient support of low-latency processing than in LTE. - Physical Layer (PHY) handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical-layer functions. The physical layer offers services to the MAC layer in the form of transport channels On the Control Plane, the RRC protocol transparently carries the NAS signaling packets between the Core Network and the devices through the N1 interface. ==The gNodeB does not read NAS signaling==. User data is transferred between the base stations and the UPF using IP networking (N3 interface). The protocol stack is shown below.  >[!Figure] >_The 5G network protocol stack for user data transfer (user plane)_ The user data, typically IP packets, is encapsulated and transported using the 3GPP GTP-U protocol. GTP-U is well proven as it has been used in all previous generations of mobile network systems and provides a reliable data communication service. GTP-U is carried over a standard UDP/IP stack, executing on top of available networking layer 2 protocols, typically Ethernet. 3GPP does however not define the lower-level details of the IP networking solution. The signaling between base stations within the radio network and between the base stations in the radio network and the AMFs in the core network also relies on IP transport, but the upper layers of the protocol stack are different. Both stacks rely on the usage of SCTP instead of UDP as is the case for the user data transfer. SCTP is an IETF protocol that provides guaranteed delivery of messages as well as improved security compared to the standard TCP protocol. It is important to note that many subscribers are sending their data through N3, therefore the GTP-U is in charge of creating as many tunneling sessions as subscribers requiring PDU sessions there are. > [!Info] > In 5G, a _radio bearer_ refers to a logical channel that carries user data between a device (UE) and the base station (gNB). It's established and managed by the radio access network (RAN) to ensure efficient and reliable communication. Radio bearers are categorized based on their quality of service requirements and are dynamically adjusted to optimize network performance and resource utilization. > [!Info] > Yes, you read it right. The 5GC User Plane ==is largely based on UDP, which is a protocol that does not guarantee delivery==. Are all our calls and our video sessions based on an unreliable protocol as they traverse through the 5GC? The short answer is: yes. However, this is done strategically because the 5G architecture incorporates many layers of reliability mechanisms to ensure that data delivery is reliable and meets the necessary quality of service (QoS) requirements, for instance, PDCP in the RAN. UDP is chosen—and this strictly applies when data is going through the 5G network—because it is lightweight, introducing minimal overhead and latency compared to TCP. For instance, when using a video streaming service such as Netflix, the Netflix server sends video data as TCP segments encapsulated in IP packets over the internet (Netflix uses HTTP Adaptive Streaming). When these IP packets ("User Data" in the figure right above) reach the 5G network (e.g., at the gNodeB), they are wrapped in GTP-U packets for transport within the 5G network. GTP-U packets are carried on top of UDP and IP for routing within the 5G core network. Thus, the GTP-U packets carry the user data through various network functions (e.g., from gNodeB to UPF). At the User Plane Function (UPF), the GTP-U packets are then decapsulated to retrieve the original IP packets. The IP packets are then routed to the internet gateway, where they continue to their final destination using standard IP routing. > [!warning] > This section is under #development ### Connecting the core network to mobile devices and radio networks The sections above describe the key parts of the core network architecture. The connections to the radio network and the devices are shown in the figure below. N2 is a key reference point in the 5G network architecture. All signaling between the radio networks and the core network (fronted by the AMF) is carried across this reference point. > [!Note] > It should be noted that there is a naming inconsistency in the 3GPP set of Release15 specifications here, as the specifications developed by the RAN working groups use the term “NG-C interface” while the Architecture and Core teams use the term “N2 reference point” in their specifications. For consistency, N2 shall be used. It is interesting to see that even inside the same standardization efforts there are these naming discrepancies... The signaling carried across N2 is based on the NGAP protocol. There are multiple types of signaling procedures supported over N2. - Procedures supporting management of N2 such as configuration of the interface itself. One gNB (the base station) can be connected to multiple AMFs, for load sharing, resiliency and network slicing purposes. - Procedures related to signaling for a specific UE/device. Each UE/device is always only associated with a single AMF (except for some special cases). This signaling can be divided into three different types of procedures: - Signaling related to forwarding of messages between the device and the core network. This is based on the NAS protocol, short for “Non-Access Stratum”. In the 5GC architecture, individual NAS messages are either managed by the AMF or the SMF. The SMF manages NAS messages related to Session Management, and in that case, messages are passed between the SMF and the device with the help of the AMF, as there is no direct connection between the SMF and the radio network. The AMF manages all other NAS messages without involving the SMF. It shall be noted that NAS can also be used to transparently carry some messages to and from other Network Functions. - Signaling related to modification of the stored data for a specific device, the “UE context” - Signaling related to the management of events like handovers between radio cells or access networks and paging of devices that are in idle mode. It should be noted that one device is always served by one single AMF, but the same device can be utilizing data sessions managed by more than one SMF. This gives additional flexibility as it allows for simultaneous connections to multiple logical networks with different treatments, policies, and rules being applied for the routing of user data. User data is handled in the UPF, the “User Plane Function”, in the Core Network. Data is transported between the radio access network and the UPF over the N3 reference point. Data is tunneled across N3, meaning that IP routing is done on the tunnel header IP address instead of the end user IP address. This allows for maintaining a stable IP anchor point even though the device is moving in the network. It also allows the same mechanisms and transport routing to be used independently of the type of data that is carried. Besides IP packets, the 5G architecture specifications also include support for Ethernet frames and so-called “unstructured data”.  >[!Figure] >_Multiple service connections with individual SMFs and UPFs._ To summarize, here's a brief overview of the sequence of operations from the moment a User Equipment (UE) becomes active until it is ready to send traffic to the Internet in the context of 5G: 1. **Attachment Procedure:** - When a UE is powered on or moves into a new coverage area, it initiates the attachment procedure to connect to the 5G network. Before that, the device will actively search for its "home network" (PLMN, Public Land Mobile Network, which is stored in the SIM), and for its home RAN technology (5G, LTE). If it can't find its home network, this might mean a national or international roaming scenario, and the UE will have to perform some frequency scanning to find a cell. - Once a cell is found, the UE sends an initial connection request to the nearest base station, known as the gNB or gNodeB. - The gNB forwards the connection request to the Access and Mobility Management Function (AMF). - A device cannot stay in a connected state for long because it could be an IoT sensor and that would require power. Therefore, there are timeouts in place that put the UE in an IDLE state if there is no data to be sent. 1. **Authentication and Security Setup:** - The AMF authenticates the UE by verifying its identity and credentials using the Authentication Server Function (AUSF). - Upon successful authentication, the AMF establishes security associations with the UE, ensuring encrypted communication. 2. **Registration and Session Establishment:** - After authentication and security setup, the UE registers with the network by providing its identity and capabilities to the AMF. - The AMF assigns temporary identifiers and establishes a session context for the UE. - The AMF may also initiate mobility management procedures to optimize the UE's connection based on its location and mobility patterns. 3. **IP Address Allocation:** - The AMF, in coordination with the Session Management Function (SMF), allocates an IP address to the UE for communication in the 5G network. - The SMF is responsible for managing the UE's IP connectivity and session establishment. 4. **Policy and Quality of Service (QoS) Setup:** - The SMF configures network policies and Quality of Service (QoS) parameters based on the UE's subscription profile and service requirements. - This involves establishing QoS flows and policies to ensure appropriate handling of traffic based on its characteristics (e.g., latency, throughput). 5. **Data Path Establishment:** - Once the necessary setup is complete, the data path between the UE and the Internet is established. The UPF is responsible for handling the user plane traffic, which includes the actual data packets transmitted between the User Equipment (UE) and external networks such as the Internet. UPF oversees ingress and egress of data between the Data Network and the UPF. - The UE can now start sending traffic to the Internet through the network, with traffic routed through the appropriate network functions and interfaces. Communication between these network functions occurs through defined interfaces, such as N1 (between UE and gNB), N2 (between gNBs), N3 (between gNB and UPF), N4 (between UPFs), and N5 (between SMF and UPF), among others. ### Open RAN Open RAN, or Open Radio Access Network, is a consortium of several organizations that aims to open up the Radio Access Network technology stack in 5G, enabling more flexibility and interoperability in network deployments. The Open RAN (O RAN) architecture can be divided in to three key components: cloudification/and virtualization of the RAN hardware and software, intelligent management and open interfaces between the different parts of the RAN including fronthaul to the physical radio unit (RU). Open RAN provides operators with enhanced flexibility and scalability, reduced costs, increased efficiency, and improved service quality. Its open interfaces allow for mixing and matching components from different vendors, streamlined network management, and quicker deployment of new services. The O-RAN Architecture and specifications build on common standards and care about alignment with other industry bodies to ensure compatibility and to avoid duplication of work. The core idea behind O-RAN is to decouple the hardware and software components of the RAN. Traditionally, these components have been tightly integrated and supplied by a single vendor, limiting flexibility and driving up costs. O-RAN introduces the concept of functional separation, where the RAN is divided into modular components such as the radio unit (RU), distributed unit (DU), and centralized unit (CU). These components communicate via standardized open interfaces, enabling interoperability and competition among vendors. One of the key enablers of O-RAN is its use of virtualization and cloud-native technologies. By implementing RAN functions in software, operators can deploy these functions on generic, off-the-shelf hardware rather than relying on proprietary equipment. This approach reduces costs, increases scalability, and facilitates the deployment of new services. Virtualized RAN (vRAN), a subset of O-RAN, exemplifies this transformation by running RAN functions on virtual machines or containers. Interoperability is a cornerstone of O-RAN. By adhering to open interfaces such as those defined by the O-RAN Alliance, operators can integrate equipment and software from multiple vendors without compatibility issues. This reduces vendor lock-in and fosters innovation by enabling smaller companies to compete in the RAN market. Furthermore, the open nature of O-RAN paves the way for a broader ecosystem of contributors, including traditional network vendors, software developers, and cloud service providers. From a deployment perspective, O-RAN is particularly well-suited for 5G networks and beyond. The modularity and flexibility of O-RAN make it easier to deploy 5G's diverse use cases, ranging from enhanced mobile broadband to ultra-reliable low-latency communication and massive IoT. Operators can tailor their RAN configurations to meet specific requirements, whether it's achieving ultra-low latency for industrial applications or maximizing coverage in rural areas. In summary, O-RAN represents a paradigm shift in how mobile networks are designed, deployed, and managed. By embracing openness, interoperability, and software-defined principles, it aims to reduce costs, increase innovation, and create more adaptable networks that can meet the evolving demands of the digital age. This approach has garnered significant attention and support from operators, vendors, and governments worldwide. > [!info] > The key concept of Open RAN is opening the protocols and interfaces between the network building blocks (radios, hardware, and software) in the RAN. The O-RAN ALLIANCE has defined different interfaces within the RAN including those for: > - Fronthaul between the Radio Unit and the Distributed Unit > - Midhaul between the Distributed Unit and the Centralised Unit > > This is better explained in the sections below The architecture of **O-RAN (Open Radio Access Network)** is designed to disaggregate traditional Radio Access Network (RAN) components, enabling flexibility, scalability, and interoperability through open interfaces and standards. It aims to separate hardware from software, allowing operators to mix and match components from multiple vendors and optimize the network using software-defined intelligence. Here's a detailed description of the O-RAN architecture: #### **Key Functional Components** The O-RAN architecture divides the traditional RAN into modular and interoperable components, which include: ##### **Radio Unit (RU)** The RU handles the **radio frequency (RF)** processing, such as signal transmission and reception. It includes: - Functions for digital beamforming. - Analog-to-digital and digital-to-analog conversion. - RF front-end functionalities like amplification and filtering. The RU connects to the Distributed Unit (DU) via an open interface called the fronthaul interface (e.g., eCPRI or O-RAN’s own 7.2x specification). ##### **Distributed Unit (DU)** The DU performs **real-time processing** of the lower layer protocol stack. Key responsibilities include: - Medium Access Control (MAC) layer processing. - Parts of the Physical (PHY) layer processing. - Scheduling of resources for radio communication. It is typically virtualized and runs on generic hardware, enhancing scalability and cost efficiency. ##### **Centralized Unit (CU)** The CU is responsible for **non-real-time processing** and higher-layer protocol stack functions, such as: - Radio Resource Control (RRC). - Packet Data Convergence Protocol (PDCP). - Service and session management. The CU connects to the DU using the **midhaul interface** and can manage multiple DUs, enabling centralized control. ##### **Service Management and Orchestration (SMO)** The SMO is a management platform that oversees the entire O-RAN architecture. It integrates with both network infrastructure and external services, providing: - Fault management. - Configuration management. - Performance monitoring. - Software updates and life cycle management. SMO utilizes open interfaces like O1 for configuration and management tasks. ##### **RAN Intelligent Controller (RIC)** The RIC is a key differentiator in O-RAN, introducing programmability. It comes in two forms: 1. **Near-Real-Time RIC (Near-RT RIC)**: - Operates with low latency (10ms–1s). - Manages functions like dynamic resource allocation, interference management, and beamforming optimization. - Allows third-party applications, called **xApps**, to run for customized optimizations. 2. **Non-Real-Time RIC (Non-RT RIC)**: - Operates with higher latency (greater than 1s). - Handles network-level policies, long-term optimization, and AI/ML training for the near-RT RIC. - Runs **rApps** for broader management tasks. The RIC uses open interfaces like **E2** to communicate with DUs and CUs, enabling seamless integration of intelligent applications. #### **Interfaces** A fundamental principle of O-RAN is the use of **open interfaces** to ensure interoperability between components. Key interfaces include: 1. **Fronthaul Interface (7.2x)**: - Connects the RU to the DU. - Ensures high-speed data transfer and supports time-critical functions like beamforming. 2. **Midhaul Interface**: - Connects the DU to the CU. - Handles protocol communication for higher-layer processing. 3. **E2 Interface**: - Connects the Near-RT RIC to DUs and CUs. - Allows real-time control and optimization. 4. **O1 Interface**: - Connects the SMO to all RAN components. - Manages configuration, monitoring, and software updates. 5. **A1 Interface**: - Connects the Non-RT RIC to the Near-RT RIC. - Transfers policies and AI/ML models to guide near-real-time optimization. #### **Cloud-Native and Virtualization** O-RAN leverages **virtualization** and **cloud-native principles**, enabling functions to run on generic hardware instead of proprietary equipment. This is achieved through: - Containerization of software functions for portability and scalability. - Deployment on commercial off-the-shelf (COTS) hardware in data centers or edge locations. - Dynamic resource allocation to optimize performance and costs. #### **Disaggregation and Modularity** O-RAN's disaggregated approach ensures: - Operators can procure components from different vendors. - Upgrades and scaling can occur independently for each module. - Flexibility in adapting to specific use cases, such as urban environments requiring high density or rural areas needing wide coverage. ![[Pasted image 20250106220210.png]] It is important to note that the O-RAN architecture does not include the 5G Core (5GC). O-RAN specifically focuses on the disaggregation and redefinition of the Radio Access Network (RAN) layer, which is responsible for handling communication between user devices and the core network. ### 5G RAN Chipsets > [!attention] > This section is under #development ### The Role of Virtualization and Cloud Services in 5G Traditionally Mobile core network designs are distributed applications that scale horizontally and run on dedicated hardware such as server blades in a chassis. The network element architecture is distributed internally onto specific types of blades that perform specific tasks. For example, blades that execute software that is responsible for the overall management of the network element versus blades that perform the actual work of managing mobile core subscribers. Scale is achieved primarily by internal horizontal scaling of working blades. The first major step of virtualization was to migrate those application-specific blades to virtualized resources such as virtual machines ([[Semiconductors#Emulation and Virtualization|VMs]]) and later [[Semiconductors#Containers|containers]]. The network core could then be realized as an application that is distributed among several virtual hosts. Because the application was no longer constrained by the resources and capacity of a physical chassis, this step allows much greater flexibility of deployment and harmonization of the installed hardware. For example, the operator can deploy much larger (or much smaller) instances of the network element. This first step was also mainly for proving that a virtualized host environment could scale appropriately to meet the subscriber and capacity demands of today’s mobile core. The next step in the mobile core architecture evolution is to a cloud-native design to take advantage of the flexibility offered in using cloud technology and capabilities. In this step, the mobile core network element design that was tightly integrated together in pre-defined units and ratios is now decoupled both logically and physically to provide greater flexibility and independent scalability. For example, this step sees further separation of the control plane and user plane of a network function. Also, in this cloud evolution, mobile core functions begin to implement the network architecture of web applications. Cloud Native architectures have gained a lot of interest over the past years and service operators' attempt to emulate the efficiencies captured by so-called hyperscalers (e.g., Facebook, Google, Amazon) has led to much heightened interest in this area. Simply put, the architectures and technologies (service-based interfaces, microservices, containers, etc.) used in web-scale applications bring benefits to networking infrastructure in elasticity, robustness, and deployment flexibility. Cloud-native applications and infrastructure should not be viewed as another level of complexity on top of a cloud transformation that still is not fully up and running; rather, it should be viewed as a natural evolution of the cloud transformation that is already in progress in the telecom industry today. A cloud-native strategy therefore allows service providers to accelerate both the development and deployment of new services by enabling practices such as DevOps, while the ability to rapidly scale up or scale down services allows for resource utilization to be optimized in real-time, in response to traffic spikes and one-time events. There are several cloud-native design principles that hold for all installations, including: - Infrastructure Agnostic: Cloud-native applications are independent and agnostic of any underlying infrastructure and resources. - Software decomposition and life cycle management: Software is decomposed into smaller, more manageable pieces, utilizing microservice architectures. Each piece can be individually deployed, scaled, and upgraded using a CaaS (Container as a Service) environment. - Resiliency: In legacy applications, the MTBF (Mean Time Between Failures) of hardware has been the base metric for resiliency. In the cloud, we instead rely on the distribution and independence of software components that utilize auto-scaling and healing. This means that failures within an application should cause only temporary capacity loss and never escalate to a full restart and loss of service. - State-optimized design: How we manage state depends on the type of state/data and the context of the state. Therefore, there is no “one size fits all” way of handling state and data, but there should be a balance between performance, resiliency, and flexibility. - Orchestration and automation: A significant benefit of cloud-native applications is increased automation through the use of tools like the Kubernetes-based CaaS layer. A CaaS enables auto-scaling of microservices, auto-healing of failing containers, and software upgrades including canary testing (small-scale testing) before larger deployments. ### REDCAP The demand for 5G devices with reduced capability is growing at pace. The 3GPP RedCap NR feature reduces UE complexity through fewer RX/TX antennas, reduced UE use of bandwidth, lower UE power consumption, relaxed data rates, relaxed UE processing time and processing capability to help enable some innovative use cases, primarily around Industrial wireless sensors, Video surveillance and Wearables. > [!warning] > This section is under #development ### A Review on 5G Non-Terrestrial Networks (NTN) Mobile communications have evolved from generation to generation, adding better capabilities and the trend is far from being over. Initially, the first two mobile comms generations aimed to ensure the efficient transmission of voice information. Newer generations added more digital technologies, bandwidth-efficient modulation schemes, and smarter use of an increasingly contested spectrum, allowing faster data rates, more secure radio access technology, and a breadth of protocol layers ready to carry internet protocol (IP) datagrams. This, in turn, unlocked the possibility of merging mobile and global networks seamlessly, giving the end users the possibility of enjoying the same services and applications they used on their computers now from their smartphones, without compromising on quality.  > [!Figure] > _Different types of non-terrestrial networks_ The last generation of deployed mobile communications incorporates capabilities that were unheard of in previous generations. To exploit the potential, a new radio-access technology known as NR (New Radio) was devised. The key innovative factor of defining a brand-new radio access technology meant that NR, unlike previous evolutions, was not restricted by a need to retain backward compatibility. This permitted rolling out a set of key use cases: - ==Enhanced mobile broadband (eMBB)==, which appears as the most straightforward evolution from previous generations, enables larger data volumes and further enhanced user experience. - ==Massive machine-type communication (mMTC)==, provides services that are characterized by a massive number of devices, such as remote sensors, actuators, and monitoring equipment. Key requirements for such services include ultra-low device cost and ultra-low power consumption, allowing for extended device battery life of up to at least several years. Typically, each device consumes and generates only a relatively small amount of data, thus, support for high data rates is of less importance. - ==Ultra-reliable and low-latency communication (URLLC)==, with services targeted to ensure very low latency and extremely high reliability. Examples hereof are traffic safety, smart cities, automatic control, power grid, and factory automation. Although 5G was deployed several years ago (Release 15), it keeps evolving. The newest evolution of 5G (Release 18>), is called 5G Advanced and it will add support for new applications and use cases. 5G Advanced is expected to bring significant enhancements around smarter network management by incorporating AI/ML techniques for beam management, load balancing, channel state information feedback enhancement, improvements in positioning accuracy, and user equipment network slicing. 5G Advanced is envisioning to incorporate low-latency audio and video streaming services aimed at Extended reality (XR), along with a more energy-efficient use of network resources, and [[High-Speed Standard Serial Interfaces#Deterministic Networking|Deterministic Networking]] capabilities to ensure deterministic data paths for real-time applications with extremely low data loss rates and packet delay variation. More importantly, recent releases of 5G have been progressing in integrating satellite communications with 5G NR techniques called "non-terrestrial networks", or NTN. The study of non-terrestrial networks includes identifying NTN scenarios, architectures, and use cases by considering the integration of satellite access in the 5G network including roaming, broadcast/multicast, secure private networks, etc. The synergy between 5G and satellites is neither mere speculation nor hype, but tangible technical traction towards integrating space technology and mobile communications together. Whilst 5G Advanced is about adapting the already established generation for new incremental use cases, 6G (Release 20>) is natively designed for the human digital needs of the next decade. The sixth generation is already in the making, coordinated by the 3rd Generation Partnership Project (3GPP), the standards development organization behind the 6G initial research of enabling technologies, the definition of the requirements, the technical steering, and the identification of use cases. An activity that is already ongoing and will span for the next half-decade or so, refining the architecture and commencing implementation. The work on Non-Terrestrial Networks (NTN) started in 3GPP in 2017, with a Study Item in Release-15 in 3GPP RAN WG1 [RP-1714501 ]that focused on deployment scenarios and channel models for NTN. After this initial study, the 3GPP SA (Systems Aspects) workgroup started to discuss the use cases for Satellite-based NTN as part of the Study Item on Satellite Access in 5G [SP-170788]. The study identified three main categories of use cases for satellite-based NTN: - Service Continuity: Use cases where 5G services cannot be offered by terrestrial networks alone, and how a combination of terrestrial and non-terrestrial networks combined provides service continuity for such cases. Some examples are airborne platforms (e.g., a commercial or a private jet) and maritime platforms (e.g., a maritime vessel). - Service Ubiquity: Use cases address unserved or under-served geographical areas, where terrestrial networks may not be available. Examples of ubiquity use cases are IoT (e.g., agriculture, asset tracking, metering), public safety (i.e., emergency networks), and home access. - Service Scalability: Use cases that leverage the large coverage area of satellites and use multicasting or broadcasting similar content over a large area. An example of such a use case is the distribution of rich TV content. Non-terrestrial networks are expected to be an integral part of 5G service deployment by: - Enabling ubiquitous 5G service to User Equipment (UE), especially IoT/MTC, public safety/critical communications by extending the reach of terrestrial-based 5G networks to areas that cannot be optimally covered by terrestrial 5G networks. - Enabling 5G service reliability and resiliency due to reduced vulnerability of air/spaceborne vehicles to physical attacks and natural disasters. This is especially of interest to public safety or railway communication systems - Enabling connectivity of 5G-RAN elements to allow ubiquitous deployment of 5G terrestrial network - Enabling connectivity and delivery of 5G services to UE onboard airborne vehicles (e.g. air flight passengers, UASs/drones, etc.) - Enabling connectivity and delivery of 5G services to UE on board other moving platforms such as vessels and trains - Enabling efficient multicast/broadcast delivery of services such as A/V content, group communications, IoT broadcast services, software downloads (e.g. to autonomous, connected cars), and emergency messaging - Enabling flexibility in traffic engineering of 5G services between terrestrial and non-terrestrial networks Note that NTN has become an umbrella term for any network that involves non-terrestrial flying objects. The NTN family includes satellite communication networks, high-altitude platform systems (HAPS), and air-to-ground networks (see figure several paragraphs above). 5G New Radio (NR) based NTN has been the main focus in 3GPP. NR was designed for forward compatibility, support for low latency, advanced antenna technologies, and spectrum flexibility including operation in low, mid, and high-frequency bands. This provides a solid foundation for adapting NR to support NTNs. There is growing interest in NTN-based massive Internet of Things (IoT) use cases using narrowband IoT (NB-IoT) and Long-Term Evolution (LTE) for machine-type communication (LTE-M). As a result, 3GPP is studying the feasibility of adapting NB-IoT and LTE-M to support NTN 3GPP work on NR NTN started in 2017, with a Rel-15 study focused on deployment scenarios and channel models. The study was documented in 3GPP TR 38.811[^113]. The first main objective of the study was to select a few reference deployment scenarios of NTN and agree on key parameters such as architecture, orbital altitude, frequency bands, etc. The key scenarios and models include: - Two frequency ranges, S-band and Ka-band - GEO satellites, LEO satellites, as well as HAPS (High Altitude Pseudo Satellites) - Earth-fixed beams (i.e., beams that are steered towards an area of Earth as long as possible) and moving beams (i.e., beams that move over the Earth's surface following the motion of the satellite) - Typical footprint sizes and minimum elevation angles for GEO, LEO, and HAPS deployments - Two types of NTN terminals: handheld terminals and Very Small Aperture Terminals (VSAT) (equipped with parabolic antennas and typically mounted on buildings or vehicles) - Antenna models for the satellite and HAPS antennas The second main objective of the study was to develop NTN channel models based on the terrestrial 3GPP channel models. Next-generation RAN (NG-RAN) supports splitting a 5G base station (gNB) into a central unit (CU) and a distributed unit (DU). A multitude of NTN-based NG-RAN architecture options were explored. It was concluded that there are no showstoppers to support the identified architecture options. The NR higher-layer protocol stack is divided into a user [[High-Speed Standard Serial Interfaces#Network Planes Control Plane, Data Plane, Utility Plane, Timing Plane|plane]] (UP), which manages data transmission, and a control plane (CP), which is responsible for signaling. For the UP, the main impact comes from the long propagation delays in NTN. Accordingly, the impact of long delays on medium access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and service data adaptation protocol (SDAP) were studied. It was concluded that MAC enhancements would be needed for random access, discontinuous reception (DRX), scheduling requests, and hybrid automatic repeat requests (HARQ). It was recommended to focus on status reporting and sequence numbers on the RLC layer, and service data unit discard and sequence numbers on the PDCP layer. For the SDAP, it was found that it is not necessary to introduce any modification to support NTN. For the CP, the focus of the study was on mobility management procedures, due to the movements of NTN platforms, especially LEO satellites. For idle mode, introducing NTN-specific system information would be needed. Earth-fixed tracking area can be used to avoid frequent tracking area updates. Defining additional assistance information for cell selection and re-selection can be beneficial. For connected mode, handover enhancements were discussed to tackle the frequent handover due to the fast satellite movement. From a physical layer perspective, extensive link level and system level evaluations were conducted in two nominal frequency bands: S-band and Ka-band. Based on the evaluation results, it was concluded that with appropriate satellite beam ### Roles of Satellites in 5G #### NTN Transparent Payload An NTN as specified by 3GPP in Rel-17 is shown in the figure below. Non-terrestrial NR access to the User Equipment (UE) is provided using an NTN payload and an NTN Gateway: the service link is between the NTN payload and the UE (Uu interface), and the feeder link is between the NTN Gateway and the NTN payload, handling N2 and N3 interfaces. The gNodeB, therefore, includes the NTN payload and the NTN gateway. ![[Pasted image 20240708100312.png]] > [!Figure] > _NTN Payload_ (source: #ref/Vanelli ) Why this architecture is called "transparent"? It's because the NTN payload transparently forwards the radio signal received from the UE via the Uu interface to the NTN Gateway via the feeder link, and vice versa. Because of this, a gNB may serve multiple NTN payloads and an NTN payload may be served by multiple gNBs. The service link and the feeder link may operate on different frequencies, so the NTN payload is allowed to change carrier frequency before re-transmitting the signals between the two links. The standard per se does not preclude deploying Xn between NTN gNodeBs. From a geographical point of view, Xn would run between sites where NTN Gateways are located. But these sites may be located hundreds or thousands of kilometers apart, and they typically do not require tight coordination for their operation, unlike terrestrial gNBs. Then inter-gNB mobility or dual connectivity via Xn between NTN GWs, while not precluded by the 3GPP standard, would not be very relevant, for at least two reasons. First, because it would be unlikely that two gNBs so far apart would be connected to the same core network; second, because the advantage of Xn-based mobility with respect to NG-based mobility when source and target gNBs are so far apart, would be nonexistent. ![[Pasted image 20240708101112.png]] > [!Figure] > _NTN Payload_ (source: #ref/Vanelli ) The figure below shows the logical links of an NTN, showing the relationship among Radio Bearers, NG-U Tunnels, PDU sessions, and Quality of Service (QoS) Flows, with the end-to-end mapping of QoS flows in evidence. This follows the same principles and rules for traffic handling in the NG-RAN and the 5GC. The satellite and the NTN gateway (the blue boxes in the figure) make up the gNB in the logical architecture view. PDU sessions and QoS flows are terminated in the UE and the UPF. The control plane and user plane stacks for NTN do not change with respect to the terrestrial case. ![[Pasted image 20240708101634.png]] > [!Figure] > _NTN based on a transparent satellite, showing an end-to-end mapping of QoS flows_ (source: #ref/Vanelli ) ##### Control Plane The control plane stack is shown in the figure below. Both the satellite payload and the NTN gateway are transparent with respect to the Control Plane protocols, so the termination points for Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and PHYsical layer (PHY) are on the UE and the gNB. NAS messages are terminated by the AMF in the core network and by the UE, as usual. ![[Pasted image 20240708102921.png]] > [!Figure] > _Control plane stack for NTN_ ##### User Plane The user plane stack is shown in the figure below. Both the satellite payload and the NTN gateway are transparent with respect to the UP protocols, so the termination points for Service Data Adaptation Protocol (SDAP), PDCP, RLC, MAC, and PHY are on the UE and the gNB. UP PDUs are terminated by the UPF in the core network and by the UE. ![[Pasted image 20240708105827.png]] > [!Figure] > _User plane stack for NTN_ #### NTN Regenerative Payload > [!warning] This section is under #development ## A Quick Review on Satellites Having discussed non-terrestrial networks, we will focus now on satellites as nodes in these networks. Satellites are put in orbit using different kinds of launchers. The most popular type of launcher is a vertical rocket in a launchpad at ground level in which vertical speed gained by its engines' thrust ensures departure from the thickest layers of the atmosphere, only to then maneuver to imprint the right tangential velocity in the higher atmosphere to achieve the required orbital velocity. It sounds simple, but it is extremely complicated: rockets have hectic dynamics, and engines are complex, so an incredible variety of situations are experienced by a spacecraft while attached to a rocket on its way to space. Other launcher technologies besides vertical launchers exist, which are less popular and less cost-effective, such as aircraft-based, balloon-based, and even slingshot-based launchers exist to disparate levels of maturity. We will refer to vertical launch as the baseline for this text, due to its popularity among all available options as of today. The launch generates high stresses on the spacecraft. From a satellite perspective, launch starts when the boosters' engines ignite (the launcher lifts off from the pad) and ends with the spacecraft separation when it is finally allowed to float alone in space. Mind you, it is a wild ride. Launchers are generally designed in stages that discretize the flight in a set of events where different parts of the rocket are separated and jettisoned in a complex sequence that involves stopping and starting rocket engines, creating several accelerations and shocks in the process. Rockets undergo different aerodynamic scenarios and can suffer from turbulence just as commercial airliners do, adding to the overall hecticness of the ride. Needless to say, electronics on board a satellite must withstand all these conditions so it must be designed accordingly. There are several structural loads present during rocket flight, both in the lateral and longitudinal (i.e., axial, or along the rocket long body) directions. Some loads are predicted as a function of time and others can only be estimated statistically as random loads. In the mechanical environment, we find: - Steady-state accelerations - Low-frequency vibrations - Broadband vibrations, such as: - Random vibrations - Acoustic vibrations - Shock vibrations Loads are transmitted from the launch vehicle to the payload—the satellite—through the mechanical interface that bonds the rocket and spacecraft together, which is usually a ring with bolts. During lift-off and early phases of the launch, a high level of vibrations transfer from the vehicle to the payload through their common interface. The principal sources of vibrations are the rocket engines thrusting, aerodynamic turbulence, and acoustic noise as pressure waves impinging on lightweight appendages which can be excited beyond safe margins. Everything is so hectic that bolts may simply come off, as well as cables, boards, or brackets on board the satellite if not properly secured. As you may imagine, assembling a spacecraft requires adding a good amount of glue. In summary, the design process must consider all these factors and include the necessary measures to ensure launch survivability, considering that the satellite will be violently shaken and hit several times before it can even start thinking of providing its service. Satellites can be primary payloads, that is, first-class passengers on rockets. Such tickets are worth tens of millions. A more cost-effective option is to share the space with other fellow satellites, which is called, no surprise there, a 'rideshare'. Rideshares are ways the launch providers can make better use of their available launch volume and make a profit in the process. For this, rocket companies provide adapters such as the EELV Secondary Payload Adapter (ESPA ) which can accommodate several secondary payloads attached to the available rings. Launch vehicles can stack several ESPA rings together. Once they deliver the primary payload, launch providers begin to deliver the different secondary payloads sequentially. One rocket may contain hundreds of secondary payloads. Broker companies can also do business by attaching dispensers to ESPA ports and exploiting the space for dispensing smaller satellites. Even further, companies may attach Orbital Transfer Vehicles (OTVs) which are satellite dispensers with their own propulsion, computers, and attitude control—motherships of sorts—which can carry several payloads and insert them into customer-specific target orbits that rocket launchers cannot (or do not want to) go for. Once deployed, satellites fly describing a path called an orbit, so let's discuss what those are. ### Orbits Kepler's laws describe the motion of planets around the Sun, which also describe the way an artificial satellite orbits around a celestial body. The first law states that planets move in elliptical orbits with the Sun at one of the focal points, diverging from the prior belief in perfectly circular orbits. The second law, known as the law of equal areas, indicates that a line segment joining a planet and the Sun sweeps out equal areas during equal intervals of time, implying that planets move faster when they are closer to the Sun and slower when they are farther away. The third law establishes a precise relationship between the time a planet takes to complete its orbit (its orbital period) and its average distance from the Sun, revealing that the square of a planet's orbital period is proportional to the cube of its average distance from the Sun. These laws not only explained planetary motions with unprecedented accuracy but also laid the groundwork for Newton's theory of gravitation. Orbits are geometrically described by Keplerian orbit elements, graphically depicted in the figure below. Orbital elements are a set of parameters that analytically define the shape and size of the ellipse, along with its orientation in space.  > [!Figure] > _Elements of the ellipse (CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=57497218)_ There are different ways of mathematically describing an orbit, being orbit elements the most common, whose parameters are: - Eccentricity ($e$): describes the shape of the ellipse, describing how much it is elongated compared to a circle. Graphically, it is the ratio of the distance from the center to the foci (F) and the distance from the center to the vertices. As the distance between the center and the foci approaches zero, the ratio approaches zero and the shape approaches a circle. - Semimajor axis ($a$): defines the sum of the periapsis and apoapsis distances divided by two. For classic two-body orbits, the semimajor axis is the distance between the centers of the bodies, not the distance of the bodies from the center of mass. Two elements define the orientation of the orbital plane in which the ellipse is embedded: - Inclination ($i$): It represents the vertical tilt of the ellipse with respect to the reference plane, measured at the ascending node (where the orbit passes upward through the reference plane, the green angle *i* in the diagram). The tilt angle is measured perpendicular to the line of intersection between the orbital plane and the reference plane. The reference plane for Earth-orbiting crafts is the Equator. Any three points on an ellipse will define the ellipse orbital plane. The plane and the ellipse are both two-dimensional objects defined in three-dimensional space. - Longitude of the ascending node ($\Omega$): It horizontally orients the ascending node of the ellipse (where the orbit passes upward through the reference plane, symbolized by *☊*) with respect to the reference frame's vernal point. This is measured in the reference plane and is shown as the green angle $\Omega$ in the diagram below. The remaining two elements are as follows: - Argument of periapsis (*ω*): which defines the orientation of the ellipse in the orbital plane, as an angle measured from the ascending node to the periapsis (the closest point the satellite object comes to the primary object around which it orbits, the blue angle *ω* in the figure). - True anomaly (*ν*) at epoch: defines the position of the orbiting body along the ellipse at a specific time (the "epoch").  > [!Figure] > _Orbit elements (credit: Lasunncty at the English Wikipedia / CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/)_ If the orbit is known, at least roughly, it provides the designer with a good deal of information to drive initial analyses on things such as geometric configuration and power generation. The orbit geometry, and more specifically its orientation in inertial space defines how the Sun behaves with respect to the spacecraft's orbital plane, the same way the Sun behaves differently in the sky depending on what point we sit on the Earth. The way the Sun vector projects into the orbit plane will influence the way the spacecraft will scavenge energy from sunlight. The projection will be largely governed by the orbit inclination and by the inclination of the ecliptic plane with respect to the Equator.  > [!Figure] > _Sun's apparent motion in a plane with respect to the Equator_ The apparent motion of the Sun is constrained to the Ecliptic Plane and is governed by two parameters: $\Gamma$ and $\large \epsilon$.  > [!Figure] > _The Sun's apparent motion can be described by the angles $\epsilon$ and $\Gamma$_ Where $\large \epsilon$ is the obliquity of the Ecliptic and, for Earth, is 23.45°; $\Gamma$ is the Ecliptic True Solar Longitude and changes with date. $\Gamma$ is 0° when the Sun is at the Vernal Equinox.  > [!Figure] > _Orbit plane geometry with respect to an inertial frame of reference and vector normal to the orbit plane_ From the figure above, $i$ is the test orbit inclination, i.e. the orbit's angular tilt from the equatorial plane; $\Omega$ is the Right Ascension of the Ascending Node, which is an angular measure between the inertial x-axis at the point where the orbit crosses the equatorial plane going from South to North.  > [!Figure] > _Orbit plane (blue), orbit normal (vector o), and ecliptic plane (red)._  > [!Figure] > _The projection of the sun vector in the orbital plane is important for satellite design_ The beta angle is not static and varies constantly. Two factors that affect beta variation the most: 1. The change of seasons (variation in $\Gamma$) 2. Perturbation of the orbit due to the oblateness of the planet (variation in Ω, and rotation of apsides). The angle is constrained by the angle of the ecliptic and the inclination of the orbit. $\large \beta = \pm \left( \epsilon + \left| i \right| \right)$ The variation that concerns the most design engineers is the variation due to the precession of the orbit. Earth is not a perfect sphere; hence the Equatorial bulge produces a torque on the orbit. The effect is a precession of the orbit ascending node (meaning a change of orientation in space of the orbital plane). Precession is a function of orbit altitude and inclination.  > [!Figure] > _Orbit precession_ This variation is called the Ascending Node Angular Rate or precession rate, $\omega_{p}$, and is given by: $\large \omega_{p} = - \frac{3}{2}.\frac{{R_{E}}^{2}}{{(a\left( 1 - e^{2} \right))}^{2}}J_{2}\text{\ ω}\cos i$ Where: - $\omega_{p}$ is the precession rate (in rad/s) - $R_{E}$ is the body's equatorial radius (6378137 m for Earth) - $a$ is the semi-major axis of the satellite's orbit - $e$ is the eccentricity of the satellite's orbit - ω is the angular velocity of the satellite's motion (2π radians divided by its period in seconds) - $i$ is its inclination (in degrees) - $J_{2}$ is the body's "second dynamic form factor" = 1.08262668×10^−3^ for Earth). Rotation of the apsides is the other perturbation to consider. The rotation of apsides is an orbit perturbation also due to the Earth's bulge and is similar to the regression of nodes. Rotation of apsides is caused by a greater than normal acceleration near the equator and subsequent overshoot at periapsis. A rotation of periapsis results. This motion occurs only in elliptical orbits. As the 𝛽 changes, there are two consequences of interest to engineers: 1) The time spent in an eclipse (i.e., planet shadow) varies. 2) The intensity and direction of heating incident on spacecraft's surfaces changes. Orbit orientation will influence the duration of the daytime and nighttime on board (i.e. sunlight and eclipse times). This factor will impact not only power generation and storage but also thermal behavior since things can get quite cold during eclipses. Physical configuration and subsystem design are greatly impacted by the beta angle behavior with respect to the body reference of reference. It does not only affect the dimensioning of the power-generating surfaces but also defines the location of sensors that can be perturbed by the Sun. This can directly affect orbit capacity and payload availability: a suite of sensors being frequently affected by sunlight can reduce the readiness for the spacecraft to perform its mission. ### Physical Configuration and Power Spacecraft must generate more power than they consume for sustained operations. Sounds obvious, but it is not such a trivial task to analyze all the potential scenarios during the mission to guarantee a consistent positive margin. Estimating margins at very early stages can be challenging since many things such as on-board equipment have not been defined. For generating power, typically spacecraft are equipped with solar panels (some deep space probes[^114] use Radioisotope Thermal Generators or RTGs). The need to define as precise as possible margins at the early stages is because power margins impact solar panel size, physical configuration, mass, and reliability. If later in the process the team discovers the power margins were insufficient, the overall impact on the project is major since it will require a general physical redesign. For maximum energy generation, solar panels need to present their surface as perpendicular to the Sun as possible, and this is a factor that can impact the overall physical configuration. Solar panels are very ineffective devices, converting to electrical energy approximately 15%-20% of the incident energy. The remainder of the solar energy that is not converted to electrical power is either reflected or converted into heat. The heat in turn is reradiated into space (if properly thermally isolated from the rest of the bus); the net effect is to raise the solar panel temperature. Then, making the solar panels point as straight to the Sun is of paramount importance. Different approaches can be used as we shall see. If the satellite payload requires constant pointing to Earth (for example for comms applications, or remote sensing), then mechanically moving (slewing) the satellite body to track the Sun (assuming panels are fixed to the bus) is a no-go, otherwise you will stop pointing to where the payload needs to point. This requires some decision-making: either you acquiesce to the fact you cannot make your panels look straight to the Sun and therefore you dimension the power system to deal with that power generation downside (by choosing low-power subsystems, decreasing redundancy, etc.), or you try to find some other way of looking to the Sun with the best angle possible while keeping your payload looking to the ground. It can happen that the on-board power consumption will not allow you to accept panels not perpendicular to the Sun, and you will be invited (read: forced) to choose an option that will guarantee enough power generation, no matter what. There are some alternatives. One variable to consider when it comes to power generation is the total area your solar panels will be exposed to the Sun. The number of solar cells and how you arrange and connect them will impact their power output. Individual solar cells generate small power, voltage, and current levels on their own. A solar array connects cells in series to increase voltages to required levels, which are called strings. Strings, then, are connected in parallel to produce the required current levels. The series-parallel arrangement of cells and strings is also designed to provide redundancy or string failure protection. The design challenge is how to distribute strings of solar cells around the spacecraft body. Assuming the body is a square box of, say, 1 meter each face, designers cannot count on being able to completely cover all sides with solar cells. Usually, only some sides from the theoretical total of six a box has can be counted. The other faces will be taken by different objects, such as sensors, actuators, TTC comms antennae, payload, separation mechanism/ring, other deployables, and propulsion (see sketch below). Also, since the faces of the square will present different angles to the solar beta angle, this can be suboptimal for power generation reasons. Often, it can be more convenient to have all the panels in a coplanar arrangement.  > [!Figure] > _Solar cells' available area for a box-shaped spacecraft. Angles to the Sun can be suboptimal for power generation in this geometry_ To present all the panel area surfaces in a coplanar way, the option is to mechanically fold out the panels, as shown in the sketch below. The layout shown still depends on the panels being able to be folded in their "home" positions.  > [!Figure] > _Solar panels folding out in a coplanar manner for better Sun angle geometry_ If this is not a possibility, one other layout approach is to stack the panels on one face and fold them out accordingly, as shown in the figure below.  > [!Figure] > _Stacked configuration for coplanar folded solar panels_ Solar panels that fold out impact system complexity and reliability. The key factor in these mechanisms is to keep the panels secured during launch, and this is usually done utilizing Hold-Down Release Mechanism (HDR) which may include either release nuts (also known as separation nuts), explosive bolts, pyrotechnic cutters, or similar. In any case, the mission profile greatly shapes what path to take. For Earth-pointing missions, the options shown in the previous figures are great for Polar missions and Sun-Synchronous orbits, where the beta angle appears consistently on one side of the orbit plane. For other orbits such as low inclination missions, the Sun traverses high and at times along the orbital plane, hence the optimal solar panel layout is one where the panels' point upwards (see sketch below, the sketch assumes spacecraft flight to the right of the screen).  > [!Figure] > _Solar panels for Sun angles along the orbital plane_ In some types of orbits, for example equatorial (0 deg inclination) orbits, the Sun will lay almost in the orbital plane (plus minus the ecliptic angle of 23.45 degrees). This means the Sun will describe a trajectory from very low angles to very high angles, which no "fixed" configuration can fulfill. An alternative for that is to use a mechanism that will tilt the solar arrays as the Sun traverses during the orbit. These devices are typically called Solar Array Driver Motors (SADM, even though naming varies depending on the manufacturer), which will make the panels spin on one axis as the Sun moves (see sketch below). This adds mass, complexity, and a source of mechanical vibrations on the platform, which can be problematic for applications that require low mechanical jitter. Again, the payload will define what's the best course of action. Always seeking simplicity, it is a good call to always choose the option that will minimize complexity. Regardless of the configuration chosen to create enough solar panel area for power generation, every decision must be communicated to the rest of the design team. Attitude control, for example, must be aware of how the mass distribution of the different options (fixed vs deployable) will look like, for control reasons. The mechanical teams need to understand how the physical envelope of the spacecraft will be for launcher interfacing reasons. This is multidisciplinary design in a nutshell: move a screw and we are surely screwing something (and someone) up.  > [!Figure] > _Spacecraft sketch with rotating solar panels option_ The process of finding the right physical configuration that fulfills power generation and other subsystems' requirements is highly iterative and rife with trade-off analyses. However, these iterations can also be eventually automated if there is a solid understanding of the most relevant input parameters and the way those parameters impact the architecture. For example, it would not be impossible to come up with a programmatic or computational way of defining the optimal solar-panel locations versus beta angle, or star tracker orientation considering beta angle and payload attitude profiles. For automated solar panels and battery sizing, factors such as avionics and payload power consumption would be must-haves. Power subsystem design requires an understanding of the energy balance of the spacecraft. Both the solar panel specifications and the battery capacity requirement can be determined from such analysis. Diving a bit in more details, the energy to be supplied from the solar panels consists of four parts: - The energy required to supply the daytime loads. - The energy required to charge the battery for the nighttime loads. - All the energy losses involved in the system including - power losses of solar panels to the daytime loads. - power losses of solar panels to the battery. - battery charging losses. - power losses of battery to the nighttime loads. - All energy reserves, day and night. Aging and degradation are factors that must take part in power design. Solar panels' performance degrades with time. Batteries degrade with time. The source and rate of degradation depend on the orbit chosen and the mission type. Missions with very high altitudes like Medium Earth Orbits (MEO) will present accelerated degradation scenarios compared to LEO (Low Earth Orbits). The power system must be designed in a way its end-of-life (EOL) performance is adequate for the mission. Degradation in solar cells comes from radiation. The battery must be dimensioned accordingly. Batteries are required during eclipse periods, peak load periods, and during launch operations. There are different technologies of batteries available, being the most popular Li-Ion. The traditional definition of battery capacity is the current that can be supplied by the battery multiplied by the time from fully charged to depletion in ampere-hours (Ah). Battery ampere-hour capacity and energy capacity are proportional. It is convenient to define battery energy capacity from the energy balance and convert energy capacity to ampere-hours. The battery energy capacity is the average nighttime power multiplied by the maximum eclipse time divided by the transmission efficiency battery to loads. Batteries are thermally sensitive equipment, imposing strict requirements on the thermal management subsystem. As with any other subsystem on board, the power subsystem design cannot be done in an isolated manner. Many decisions taken in this subsystem impact other areas, such as mechanics, attitude control, software, payload, thermal, and the like. The physical configuration design provides important documents and analyses. Notably, a preliminary physical depiction of the spacecraft with a good initial understanding of what type of structure will be used and preliminary location of equipment. #### The Structure Once a preliminary configuration is found, it is time to define the satellite structures. Satellites need housing that must endure the launch environment. Schematically, spacecraft structures can be thought of as a distributed network of springs, masses, and dampers. The "spring" part in a structure comes from the incapacity of the materials of being perfectly rigid, as all materials distort under load. Up to certain loads, materials show a linear relationship between load and displacement (just like a linear spring). Within this region, the material or component will return to its original shape should the load be removed. If we continue loading it, the material will not be linear anymore, it will show permanent deformation and rupture will be reached. The stiffness and strength depend on the cross-sectional area, length, and material. Stiffness is defined as a measure of the load required to cause a certain amount of deflection in the material. Strength-to-weight ratio is a critical factor in choosing structural materials for spacecraft. Static and dynamic loads must be considered, along with thermal performance, corrosion protection, manufacturability, reparability, and cost. Static loads are those loads that remain constant in time whereas dynamic loads vary with time. Examples of static loads are the weight of computers and units on board (load is present when a steady acceleration is applied). Examples of dynamic loads are engine thrust, sound pressure, and gusts of wind during launch. A structure's stiffness and mass are distributed as a result of the material's elasticity and density. When subjected to time-varying forces, a structure's total response is the sum of the responses of its mode of vibration. Fortunately, only a small number of modes (typically those with the lowest frequency) are of interest. The displacement associated with higher-order modes isn't enough to produce significant stress. The frequency band over which vibration is a concern depends on the structure's parameters, such as size, material, geometry, and the excitation environment. Every structure has an infinite number of natural frequencies corresponding to different mode shapes of vibration. For a long highway bridge, for example, excited by wind gusts, only the modes with frequencies less than one or two Hz might be significant. For a spacecraft's primary structure during launch, one might need to consider modes up to 50Hz. For smaller structures like unit boxes and electronic components, their frequency responses can be at several hundred Hertz. One of the main requirements driving spacecraft structures is to withstand the wild ride on top of the rockets without degradation to ensure correct performance of the mission once in orbit, because, well, that's when the actual work starts. Structures provide housing to the spacecraft's key components in specific locations and orientations, considering thermal management, field of view, orientation, etc. But structures also: - Protect the spacecraft's components from the environment during ground operations, launch, deployment, and mission operations. - Ensure that structural vibration will not interfere with the launch vehicle's control system. Similarly, the spacecraft's structural vibration in its deployed configuration must not interfere with its own control system. - Ensure on-board vibrations will not affect payload performance - Ensure that the materials used will survive ground, launch, and on-orbit environments (pressure, humidity, radiation, contamination, thermal cycling, and atomic particles) without rupturing, collapsing, excessively distorting, or contaminating critical components. The primary structure is the skeleton of the spacecraft and the main vessel of the loads transferred between the spacecraft's components and the launch vehicle. The primary structure provides the mechanical interface not only with the launch vehicle but also with all the mechanical ground support equipment (MGSE) needed during the design and development phase, notably during integration activities. One of the most important design decisions in space projects is the definition of the primary structure. But secondary structures are important as well. Secondary structures include support beams, booms, trusses, and solar panels. Smaller structures, such as units, boxes, and brackets that support harnesses are called tertiary structures. The primary structure is designed for stiffness (or natural frequency) and to survive steady-state accelerations and transient loading. Secondary structures are also designed for stiffness, but they are also affected by on-orbit thermal cycling, acoustic pressure, and the high-frequency environment. Structure design complexity is constrained by cost and by the requirement that all its elements should be producible, and testable. A producible design is one that the engineers can build using affordable raw materials, established and simple processes, and available equipment and tooling. A testable product is one that can be handled and verified on the ground without the need for overly complex infrastructure and procedures, and with measurable success criteria. Most materials expand when heated and contract when cooled. In space, the Sun ensures that an orbiting spacecraft's temperatures are neither uniform nor constant. As a result, spacecraft structures distort. The various materials that make up a spacecraft expand or contract different amounts as temperatures change. Thus, they push and pull on each other, resulting in stresses that can cause them to yield or rupture. Most spacecraft require accurate predictions of thermal deformations to verify pointing and alignment requirements for sensors or communication antennas. Thermo-elastic forces are usually the ones that drive the joint design in structures with dissimilar materials regarding CTE (coefficient of thermal expansion) thus causing high shear loads in fasteners that joint dissimilar materials. There are guidelines and practices to help to reduce the effects of thermal deformation and stresses: - One shall contain critical members and assemblies in multilayer insulation (MLI) to keep temperature changes and gradients as low as possible. - When possible, one must design structures and their interfaces with isostatic mount designs to avoid thermally induced boundary loads. - Design structural members from materials with low CTE to minimize thermal deformations. - For structures with large temperature excursions, it's recommended to use materials with similar CTEs. When attaching members of different materials, one must design the joints to allow the expected differences in thermal expansion.  > [!Figure] > _A satellite's types of structures_ Factors impacting structural design are: - Launch Vehicle Selection: Structural impacts of launch vehicle specs, fairing sizes, and launch environments. - Spacecraft Configuration: Locate and arrange the payload and subsystems into stowed and deployed configuration. - Establish operating concepts for deployable payloads, solar arrays, and antennas. - Establish general load paths for the primary and secondary structures. - Estimate mass properties - Confirm that the spacecraft stowed envelope, mass, and center of gravity satisfy launch vehicle requirements. - Primary Structure: - Idealize the spacecraft as an "equivalent beam" with concentrated masses to represent key components and derive design loads and required stiffness. Compare different materials, types of structure, and methods of attachment. - Arrange and size the structural members for strength and stiffness. - Subsystems: - Demonstrate that payloads, solar arrays, and antennas have their required field-of-view. - Derive stiffness requirement for secondary structures to ensure adequate dynamic decoupling. - Derive design loads. - Derive requirements for mechanisms and develop conceptual designs. In terms of structural loading, mechanical loads can be static or dynamic. Static loads are constant and dynamic loads vary with time. Examples: - Static: the weight of units (mass loading when applied steady acceleration) - Dynamic: launch vehicle engine thrust, sound pressure, and gusts of wind during launch ### Data Links Radio links have been, for obvious reasons, the choice for transferring data from satellites to the ground and back. There are different levels of complexity when it comes to radio links in satellites. On SATCOM missions, the spectrum exploitation level of sophistication is very high, using advanced frequency-division multiplexing or time-division multiplexing techniques to squeeze as many customers as possible into a single communications satellite. This technique is called multiple access, and it allows several carriers from several earth stations to access a satellite's antenna. To serve its customers, the payload of a SATCOM satellite incorporates a repeater that consists of one or more channels, called transponders, operating at all times in parallel on different sub-bands of the total bandwidth used. SATCOM networks can be based on a single-beam antenna payload or multibeam antenna payload. In the context of a single-beam payload, the carriers transmitted by earth stations access the same satellite receiving antenna beam, and these same earth stations can receive all the carriers retransmitted by the same antenna. The number of users that can be served with a single SATCOM satellite and with only one parabolic antenna is mesmerizing. On some other missions, for instance in Earth Observation applications, the level of sophistication in terms of spectrum use is lower. Earth observation satellites predominantly use single carrier channels and techniques, more "classic" modulation schemes and protocols, and limited or no beam forming or beam scanning capabilities. In Earth Observation missions in LEO, the wireless links are mechanically steered with the satellite moving its body-mounted antenna to track a ground-based, big antenna and the ground station antenna, in turn, tracking the satellite. An important value to compute at the design stage of radio links is an estimate of the signal-to-noise ratio (SNR) at both uplink (from ground to satellite, also called forward link) and downlink (from satellite to ground, also called return link), to understand how reliable the transmission and reception of data will be amid the noise. SNR is computed considering output power, antenna gain, and losses), atmospheric losses, free-space loss (FSL), and receiver sensitivity. After computing SNR and considering factors such as channel coding and symbol rates, other important derivative parameters are obtained such as Energy per Symbol, Energy per coded bit, and Energy Per Bit to Noise Energy (Eb/N0). Required Eb/N0 in decibels for a desired bit error rate (BER) range is usually specified by the equipment manufacturers based on the modulation type. Historically, space link bandwidths and data rates have been limited, hence information has been carefully packed between space segment and ground segment, minimizing overhead and ensuring that literally every bit transmitted and received had an explicit meaning, usually by means of defining lightweight ad-hoc bit stream protocols. With higher data rates, wider bandwidths, and richer on-board computing resources, and with the adoption of on-board operating systems capable of running complex networking stacks, the use of standard protocol stacks such as IP has become common practice. With this approach, the more meaningful data is carried as payload on top of several standard protocol layers, meaning that not every bit modulated in the channels is so important anymore. In other words, some overhead in the link is accepted as a reasonable price to pay for the advantage of using proven services like the IP stack provides. For example, to transfer a file from ground to spacecraft, a file-transfer ad-hoc protocol must be devised by the engineering team. In an IP-based link, the ground and space segment can send files using SFTP (Secure File Transfer Protocol). Other services such as `SSH` (secure shell), `rsync` (file system sync), and `netcat` facilitate the administration tasks of the remote spacecraft. With an IP-based link, a great deal of the concept of operations boils down to something very similar to operating a server across a network; i.e., operating a spacecraft becomes more of a sysadmin task. This also enables the use of sysadmin automation tools and methods, which eases the operation of multi-satellite constellations in an automated manner. Needless to say, IP datagrams cannot be directly modulated on a noisy radio link since it lacks the underlying layers to deal for example with the physical layer and data link (layer 2). Typically, IP datagrams are encapsulated in lower protocols that are better prepared for dealing with noisy space links, typically CCSDS SDLPs (Space-Data-Link protocols^[https://public.ccsds.org/Pubs/130x2g3.pdf]): Telecommand (TC), Telemetry (TM), Advanced Orbiting Systems (AOS). IP datagrams are transferred by encapsulating them, one-for-one, within CCSDS Encapsulation Packets. The Encapsulation Packets are transferred directly within one or more CCSDS SDLP Transfer Frames. CCSDS SDLPs are widely supported by ground station providers. ### Flight Software Satellites are software-intensive systems. There is no chance a spacecraft can be launched today without copious amounts of software on it. Satellites are becoming more and more software-driven and nothing indicates this trend will stop anytime soon. Then, let's discuss what's so special about making and running software for space missions. Needless to say, satellites need microprocessors and memory for running their software. This is hardly surprising. The main difference is that the computing resources spacecraft use tend to be more specialized compared to the resources consumer electronics such as laptops have. For example, spacecraft may use microprocessor architectures that consider reliability by design by adding voting capabilities in their internal registers. Other techniques include adding memory scrubbing, which consists of reading from each memory location, correcting bit errors with an [[Fault-Tolerant Design Techniques#Error Correcting Codes|error-correcting code (ECC)]], and writing the corrected data back to the same location. Parity bits, checksums, cyclic redundancy checks ([[Fault-Tolerant Design Techniques#Error Correcting Codes#Cyclic Redundancy Check (CRC)|CRC]]), and other error detection and correction schemes are also used. Computing resources on spacecraft have been historically more modest than resources on ground-based computers, although this is a gap that has been shrinking fast in recent years. On-board computers are advancing rapidly, with more resources than ever before: more storage, more floating-point operations per unit of time (FLOPS), and more millions of instructions per second (MIPS) executed. Still, on-board computers remain closer to what are called embedded systems, which are computers with specific roles and functionalities. Unlike a laptop—which is sold without really knowing or caring for what the laptop will be finally used for, whether it's accounting, graphic design, or music production—spacecraft computers tend to be optimized for the specific function they ought to perform: attitude control, thermal control, command and data handling, star trackers, protocols encoding and decoding, payload data acquisition, etc. Each one of these requires specific interfaces, specific libraries, sensors, actuators, etc. For example, attitude control needs to perform intricate calculations about rotations, matrix operations, sensor data fusion, and a lot more. And it has to talk to a variety of sensors with different characteristics, such as sun sensors, star trackers, gyros, magnetometers, and so forth. Microprocessors used in attitude control are typically optimized with several ALUs and data paths to perform many of these computations in a few CPU cycles. Software onboard spacecraft can be updated post-launch as many times as needed. Spacecraft computers are typically equipped with [[Printed Circuit Boards#Embedded Software#Bootloader|bootloaders]] for loading new versions of the flight software. In terms of programming languages, in theory, any language can be used for coding flight software. Languages seldom make it to orbit, only compiled, machine code does (unless the compilation happens in orbit, which is rare, although technically possible). In summary, any programming language is possible as long there is a compiler for the processor used. Because flight software has historically stayed quite "embedded" and close to the hardware, compiled languages have been more popular, notably assembly and C. These languages offer the programmer the tightest control of what's happening as the software runs while paying the penalty of lower code readability and reuse. On the other hand, interpreted languages such as Python are possible in spacecraft. Provided the on-board computer is capable of running an interpreter, all the rest comes reasonably easy. Interpreted languages tend to be relatively slower and sit on higher abstraction layers; don't ask an interpreted language to handle hardware interrupts or hard real-time deadlines. But interpreted languages are highly flexible for scripting and automating non-critical things on board like daily maintenance tasks. Flight software design is incremental work. If you take two satellites from two different operators and you somehow reverse engineer the machine code into source code, more or less those two different flight software will show similarities. Every flight software needs some of these modules or building blocks: telemetry handling, telecommand handling, FDIR ([[Fault-Tolerant Design Techniques#Failure Detection, Isolation, and Correction|failure detection, isolation, and correction]]), thermal control, power control, scheduling, etc. Flight software can be designed and developed from scratch—and software engineers will always try to convince you it's the only way to go—or it can rely on existing software frameworks that already contain some of the typical building blocks. Some of these frameworks are even flight-proven and open source, which makes them very attractive for low-budget missions or University projects with very tight schedules. ### Attitude Control A spacecraft randomly tumbling in space is of very little use. A great deal of why satellites are so useful and ubiquitous is not only because they can sweep and revisit spots on the Earth very quickly, but also because when they do, they can point their on-board resources in very precise manners to perform different types of tasks. This can be a camera, a radar, a directional antenna, etcetera. Precise orientation is not only related to Earth-pointing needs. A space telescope or a data relay system are cases where very precise pointing is needed but the target might not be the Earth. The Attitude and Orbit Control Subsystem (AOCS, even though it can also be found as ADCS when orbit control is not part of it or not present) is probably the most complex subsystem in a spacecraft, and perhaps the most exotic; it easily captures a lot of attention from all directions. It is because of that complexity and its highly specialized purpose and functionality that it is the hardest subsystem to grasp in NewSpace companies. There is not an incredibly high amount of people with experience in attitude control and its multidisciplinary mixture of electronics, control theory, physics, algebra, math, and of course software does not make it any simpler. But, more importantly, the AOCS subsystem interacts with every single other subsystem on board. The motion of a rigid spacecraft is specified by its position, velocity, attitude, and the way the attitude changes over time. The first two quantities (position and velocity) describe the way the center of mass of the spacecraft translates in three-dimensional space and are the subject of celestial mechanics, orbit determination, or space navigation, depending on the aspect of the problem that is emphasized. The latter two quantities (attitude and its time evolution) describe the rotational motion of the body of the spacecraft about its center of mass. In general, orbit and attitude are coupled with each other. For example, in a low-altitude Earth orbit (LEO), the attitude will impact on the atmospheric drag which will affect the orbit. On the other hand, the orbit determines both the atmospheric density and the magnetic field strength at that location, which will, in turn, affect the attitude. However, the dynamical coupling between orbit and attitude will be normally ignored and it will be assumed that the time history of the spacecraft position is known and has been supplied by some process external to the attitude determination and control system. Attitude management (or analysis) may be divided into determination, estimation, and control functionalities. Attitude determination is the process of computing the orientation in three axes of the spacecraft with respect to either an inertial reference or some object of interest, such as the Earth. Attitude determination typically involves several types of sensors on each spacecraft and sophisticated data processing procedures. The accuracy limit is usually determined by a combination of processing activities and on-board spacecraft hardware. Typical sensors used for attitude determination are: star trackers, magnetometers, Earth Sensors, Inertial Measurement Units, Gyros, and Sun sensors. Many of these sensors are complex and contain computing resources on their own. This means they are subject to any issues found in any computer-based systems operating in space such as bit-flips, resets, and of course bugs. The onboard fault-handling capabilities must deal with this accordingly and prevent faulty sensors from affecting the overall mission reliability by isolating and correcting (if possible) the fault. Attitude estimation is the process of forecasting the future orientation of the spacecraft by using dynamic models to extrapolate the attitude history. Here the limiting features are the knowledge of the applied and environmental torques and the accuracy of the mathematical model of spacecraft dynamics and hardware. Attitude control is the process of orienting the spacecraft in a specified, predetermined direction. It consists of two areas; attitude stabilization, which is the process of maintaining an existing orientation, and attitude maneuver control, which is the process of controlling the reorientation of the spacecraft from one attitude to another. The two areas are not totally distinct, however. For example, we speak of stabilizing a spacecraft with one axis toward the Earth, which implies a continuous change in its inertial orientation. The limiting factor for attitude control is typically the performance of the maneuver hardware and the control electronics, although, with autonomous control systems, it may be the accuracy of orbit or attitude information. Some form of attitude determination and control is required for nearly all spacecraft. For engineering or flight-related functions, attitude determination is required only to provide a reference for control. Attitude control is required to avoid solar or atmospheric damage to sensitive components, to control heat dissipation, to point directional antennas and solar panels (for power generation), and to orient rockets used for orbit maneuvers. Typically, the attitude control accuracy necessary for engineering functions is on the order of fractions of degrees. Attitude requirements for the spacecraft payload are more varied and often more stringent than the engineering requirements. Payload requirements, such as telescope or antenna orientations, may involve attitude determination, attitude control, or both. Attitude constraints are most severe when they are the limiting factor in experimental accuracy or when it is desired to reduce the attitude uncertainty to a level such that it is not a factor in payload operation. Typical actuators used for attitude control are reaction wheels, magnetorquers, thrusters, and control-moment gyroscopes, among others. The attitude control functionalities described above are realized by a combination of hardware and software. The hardware is composed of the sensors and actuators described in the previous paragraphs. The software is in charge of reading the data from the sensors suite and running the determination, estimation, and control routines which will compute the torque needed to orient the spacecraft according to a desired set point and apply the computed torque by means of the actuators suite, all in a stepwise manner. ### Thermal Control We are very familiar with using electronics in our everyday lives. Laptops, smartphones, TVs are all around us. We pay little attention to the fact that electronics are designed to work within narrow thermal ranges. For example, Helsinki winters remind me of this every year when my phone (a phone that might not be from the highest end but also not the cheapest either) starts rebooting or turns off when I am outside walking with the dog at -18 degrees Celsius outside. Electronics need a specific thermal environment for it to work as intended. Spacecraft electronics is no exception. It is the role of the thermal control subsystem to make sure all subsystems operate within their allowable flight temperatures (AFT). The thermal design engineer needs to consider all heat sources the spacecraft will have, typically the Sun, the Earth, and the onboard electronics and subsystems. All these sources or inputs are not steady but vary with the position in the orbit or seasonally. Thermal control manages the spacecraft temperatures by thermally isolating the spacecraft from the environment, except in specific parts where radiators are purposely placed. Thermal control engineering relies on specialized software tools that provide simulations and numerical computations to have a good understanding of the thermal scenarios the satellite will experience during its mission long time before the spacecraft is brought to environmental testing to verify the thermal design. In space projects, thermal control engineering runs for quite a long time based solely on theoretical models and calculations until the chance to verify them in a controlled environment comes. As expected, the thermal subsystem interacts with many other subsystems, particularly with the power subsystem. This results from the need to account for all dissipated electrical energy from the equipment around and transfer this energy to a radiator for rejection into space. Also, batteries generally present a narrow temperature operating range and thus require special attention from thermal control engineers. The thermal subsystem interacts closely with on-board software since the software to measure and control zones and rooms is typically executed on one the main computers. Thermal engineers must work closely with their mechanical and structure colleagues since fixations of heaters, thermostats, and insulation blankets must be agreed upon, which also impacts the mass and power budgets. Multidisciplinary engineering is at its best. Heat in space does not transfer by convection but only by conduction and radiation. This means that heat produced by onboard electronics needs to be guided internally by means of conducting it through the proper physical channels toward radiators so that it can be radiated away to space. In the same way, spacecraft can (and will) absorb radiation from the external environment, namely from the Sun and the Earth. This radiation can be either absorbed for practical purposes (for heating things up) or reflected, to avoid overheating critical components. Thermal control design internally discretizes the spacecraft volume in 'zones' or 'rooms' and makes sure all the equipment inside such areas will stay within their allowable flight temperature (AFT) margins, which are specified by equipment suppliers. Heaters are located in places where the thermal balance changes over the mission lifetime. The causes of such changes are: - Units' dissipation changes. For example, an important heat load being turned on or off varies greatly over time. - External heat fluxes change: spacecraft attitude is changed, eclipses. - Radiator efficiency changes: changes in optical properties of radiators due to radiation, etc. Thermal control techniques can be: - Passive: supported by fixed area radiators, thermal blankets, etc. - Active: supported by electrical heaters controlled by thermostats and software. Thermal control typically relies on the next set of devices to accomplish its task: - Electrical heaters - Thermistors - Bimetallic thermostats - Radiator surfaces - Thermal blankets (MLI) - Insulation materials - Thermal fillers - Paints - Heat pipes Desired orbits and payloads define which approach (passive, active) is more feasible or what type of hardware and devices to use to thermally control the spacecraft. Active thermal control strategies increase the overall complexity of the architecture, as they require more hardware to collect the necessary thermal telemetry and run the software routines to execute the bang-bang control[^115] to keep the thermal zones under safe margins. Said software executes in either a dedicated CPU for thermal control—which is rarely the case—or in the main on-board computer. An active and redundant thermal control system may severely impact the overall power consumption of the bus and increase the mass. ### Avionics Different mission requirements will drive the need for certain data interfaces, computing power, and data storage, and the avionics must be designed and aligned with those needs. A very generic avionics architecture for a spacecraft looks as depicted in the figure below.  > [!Figure] > _A generic bused avionics block diagram_ The green boxes are different *functional chains* or units that provide certain essential functionalities on board. Irrespective of what type of application or mission the spacecraft is supposed to perform, these functional units are always present. The payload yellow box encloses the functionality that gives a purpose to the mission. What stands out from the figure above, is that spacecraft avionics need a great deal of interconnection. This means: that the different functional chains must exchange data with each other to couple their functionalities for the global function of the spacecraft to emerge. That data is in the form of commands, telemetry, or generic data streams such as files, firmware binaries, payload data, etc. The architecture is recursive in the sense that the functional chains have their own internal composition as well which will, in most cases, also require interconnection. For example, for the attitude control subsystem, the internal composition is exploded and depicted in the figure below.  > [!Figure] > _AOCS Functional Chain as a member of the avionics architecture_ As the picture shows, spacecraft avionics is an aggregation of data [[Physical Layer#Bussed Interconnects|buses]]. A spacecraft with poor interconnection between units will see its performance and operations greatly affected. With high-speed serial interfaces, feature-rich processors, and System-on-chips becoming more accessible and gaining flight heritage, there is no real reason why not designing the avionics to be an interconnection matrix exploiting high-speed serial point-to-point connections. Historically, spacecraft avionics have used hybrid interconnect approaches. Most typically, ad-hoc, daisy-chained topologies, where cables come out from a unit and go inside the next one, only to go again out to the neighbor. Legacy spacecraft avionics feature a fair deal of "private" buses; i.e., buses that are only accessible by some subsystems and not from the rest of the architecture. When discussing avionics interconnection, there are two different levels to discuss: - Subsystem level: how a subsystem chooses to connect with its own internal components. For example, how an attitude control subsystem talks to its sensors and actuators. - System level: how different subsystems connect with each other to materialize the "global" function. At either level, the approach chosen has been hybrid. Typically: - Star topology: the subsystem main unit (which usually hosts its main CPU) resides in a box of customized form factor and this box is the central "concentrator" of the subsystem. Everything flows towards it. The box exposes a set of connectors. Then, different harnesses and cables come in and out from those connectors, towards external peripherals. These peripherals can be either point-to-point or connected through a bus, or both (figure below). In this type of design, the mechanical coupling between different parts of the subsystem is likely different for the different peripherals; i.e., different types of connectors, pinouts, harnesses, etc.  > [!Figure] > A subsystem's federated architecture with a star topology - [[Backplanes and Standard Form Factors|Backplane]]: In this approach, the computing unit and the peripherals share a mechanical interface that allows them to perpendicularly connect to a common board called the backplane acting as the mechanical foundation. The peripherals connect by sliding in through slot connectors and mating orthogonally to the backplane. The backplane not only provides mechanical coupling but also routes signal and power lines between all the different modules connected to it. ### Payload All the complexity we explored in the previous sections meets its main purpose here. The payload is the component on board the satellite which gives meaning to it all; it is the VIP passenger on board. But it all starts with the mission. The mission means: what is the spacecraft intended for. The reason why you happen to need a metallic box flying at unholy velocities, far from the ground. Because there are simpler ways of doing things than having to launch something into space, so there must be a good reason one must choose to go for that, and that's what's called the mission. The mission defines the application: be it communications, earth observation, surveillance, science, astronomy, or deep space exploration. There are multiple different ways to use satellites, and the mission must clearly state what it aims for. With this information in the bag—which tends to take time to figure out and refine—then comes the part of understanding which sensor or equipment can materialize the freshly captured mission requirements. Zooming out, the mapping appears rather simple: the mission drives the payload and the orbit, which in turn drives the overall spacecraft design, or the tailoring of the design in the case of a multi-mission bus. Here is a slightly expanded list of spacecraft payload types (the list is only notional and not exhaustive): - Earth Observation: These payloads are used to monitor, track, and study the Earth's surface, atmosphere, and oceans. They typically include sensors, cameras, radars, and other instruments that can capture data in different wavelengths of the electromagnetic spectrum. Earth observation payloads can be used for a wide range of applications, including surveillance, weather forecasting, environmental monitoring, and disaster response. - Communication Payloads: These payloads are used to ensure the flow of data between the spacecraft and ground stations (including end-user terminals) or another spacecraft. They typically include antennas, transmitters, processors, and receivers that can manipulate and process signals in different frequency bands. - Scientific Payloads: These payloads are used to conduct scientific experiments and research in space. They can include telescopes, spectrometers, particle detectors, and other instruments that can measure and analyze various phenomena in space. Scientific payloads can be used for a wide range of research areas, including astronomy, astrophysics, and planetary science. - Navigation Payloads: These payloads are used for precise determination of the position of assets. They typically include hardware that can determine the spacecraft's position and velocity relative to other objects in space, which in turn may be transmitted to the ground for user terminals to determine their own positioning. - Technology Demonstration Payloads: These payloads are used to test new technologies in space. They can include new materials, subsystems, biological experiments, and other technologies that can be tested in the space environment. Technology demonstration payloads are essential for advancing the state-of-the-art in space technology and enabling future space missions. ### Assembly, Integration, and Test As space projects mature, a situation starts to build up as the different elements, equipment, and subassemblies begin to materialize: it must be all put together. This activity is called assembly, integration, and test (AIT), or assembly, integration, and verification (AIV)[^116]. Acronyms vary in bibliography or from organization to organization, but they tend to refer to the same: the act of putting the system together carefully, step by step, verifying that everything works according to the plan while stressing the system under controlled test conditions. To verify that the system can withstand the space environment, a set of system-level tests shall be performed which will replicate, to a certain extent, the conditions the spacecraft will face during launch and operations. The facilities needed for these tests are somewhat special, such as test rigs, shakers, and vacuum chambers, and are seldom owned by the system designers. #### Software Verification Besides shaking and cooking the satellite like there's no tomorrow, the onboard software must be thoroughly verified before launch. For verifying the software, the satellite is connected to a set of simulators that feed the software with the right stimulus to make it believe it's flying. A variety of procedures will be run to ensure the attitude control, command and data handling and other parts of the software are working as designed. More about simulating spacecraft can be found in bibliography[^117][^118]. The test environments to verify software might be purely digital, or a combination of real on-board equipment connected to simulators and stimulators. These setups are usually called "Flatsat", engineering models, or [[System Level Simulation#Hardware-in-the-loop|Hardware-in-the-loop]], depending on who you ask. #### Shipping The AIT phase ends with a pre-ship review (PSR) which assesses the acceptability of the spacecraft in the light of test data. A non-trivial task in space projects is related to shipping the satellites to the launch site. Shipping complex goods, and goods that may contain hazardous materials (such as large Lithium-Ion batteries) can be cumbersome. There is an amount of paperwork and compliance involved, and the regulations for moving such things around the world are strict and intricate. ## Challenges With In-Space Networks Connectivity on the ground relies on a complex combination of wireless and wired links. Wired links are continuously connected in end-to-end, low-delay paths between sources and destinations. They show low error rates and relatively symmetric bidirectional data rates.  > [!Figure] > _ Internet established infrastructure (credit: NASA)_ Communication outside of the Internet—for instance where low-power wireless devices are used—is done on independent networks, each supporting specialized communication protocols. Most of these networks are mutually incompatible; each is designed for passing messages within its network, but not able to exchange messages between networks. Interoperability is low. The nodes of each network communicate among themselves using the same set of communication protocols. Unlike wired networks, evolving wireless networks experience long and variable delays, arbitrarily long periods of link disconnection, higher error rates, and larger data-rate asymmetries. Interconnecting two networks requires a protocol agent—a gateway—that can translate between network protocols and act as a buffer for mismatched network delays. Now we will discuss networks where delays and disruptions are abundant.  > [!Figure] > _Wireless networks (credit: NASA)_ #### Optical Space Networks The Space Development Agency (SDA) released the Optical Communication Terminal (OCT) Standard. From the website: "Version 3.0.0 of the OCT Standard is designed to ensure interoperability, enable a strong marketplace, and provide advanced communication capabilities to terrestrial, maritime, and airborne warfighting elements". The SDA specification is spearheading the protocol definition efforts across the OISL industry. Interestingly, this standard only addresses Layer 1 (physical) and Layer 2 (data link). In short, the standard addresses a protocol to carry chunks of data from node to node, in the same tone as Ethernet. In fact, the OCT standard envisions the encapsulation of actual Ethernet frames in Free Space Optical (FSO) frames. Illustratively, the standard seeks to ensure that LCT providers become like modern equivalents of an Ethernet NIC (Network Interface Controller) from back in the day. That is, the optical terminals are network interfaces. But somewhat more complex NICs, because LCTs must ensure the acquisition of the channel by means of a joint spatial choreography between the two distant endpoints to establish the link and allow the transfer of data from satellite A to satellite B. As of the time of writing, the standard makes no mention of encryption or security. It appears to be left up to the upper layers. One option is to couple an LCT to a network stack (for instance, an IP stack) on both ends of the channel. The existing protocol stacks were designed for the low-latency, ample-MTU networks we find here on the ground. Are optical inter-satellite links so well behaved that we could assume a ground-based protocol such as the delay-sensitive TCP will just work in space? Not really. ==Space optical links depend on satellites keeping their three-axis attitudes under control for the data to keep flowing. In case of a star tracker reset, a faulty reaction wheel or a safe mode triggered, there is no link anymore. A slowly spinning satellite will provide an intermittently working link, like an artificial pulsar.== Therefore, OISLs call for delay and disruption-tolerant protocols, where line of sight and optical connection are never assured, and data integrity is always at stake. We are talking about protocols that must ensure determinism and reliability despite all the challenges. The risk of not having an [[The OSI Model|OSI model]] for space networks is a lack of interoperability, which will impact the network effect. The situation could be as bad as two satellites having standard compliant LCTs while being unable to send a file to each other. #### Delay and Disruption-Tolerant Networks (DTN) A delay and disruption tolerant network, or DTN, is an overlay on top of special-purpose networks. DTNs support interoperability of other networks by accommodating long disruptions and delays between and within those networks, and by translating between the communication protocols of those networks. In providing these functions, DTNs accommodate the mobility and limited power of evolving wireless communication devices. DTNs were originally developed for interplanetary use, where the speed of light can seem slow (light would take roughly 13 minutes to travel from Mars to Earth), and delay tolerance is the greatest need. However, DTNs may have far more diverse applications on Earth, where disruption tolerance is also in great demand. The potential Earth applications span a broad range of commercial, scientific, and military. DTNs can accommodate many kinds of wireless technologies, including radio frequency (RF) and free-space optical (FSO) technologies. We will focus on [[Physical Layer#Optical Channels#Free Space Optical Communication|FSO]] in this design example.  > [!Figure] > _Delay and Disruption Tolerant Networks (credit: NASA)_ Communication on the Internet is based on packet-switching. Routers switch the direction in which the packets move. The source, destination, and routers are collectively called nodes. Each packet that makes up a message can take a different path through the network of routers. If one link is disconnected, routers redirect the packets to use an alternate link. Packets contain both application-program user data (the payload part) and a header (the control part). The header contains a destination address and other information that determines how the packet is switched from one router to another. The packets in a given message may arrive out of order, but the destination's transport mechanism reassembles them in the correct order. The usability of the Internet depends on some important assumptions: - Continuous, Bidirectional End-to-End Path: A continuously available bidirectional connection between source and destination to support end-to-end interaction. - Short Roundtrips: Small and relatively consistent network delay---milliseconds, not hours or days---in sending data packets and receiving the corresponding acknowledgment packets. - ==Symmetric Data Rates==: Relatively consistent data rates in both directions between source and destination. - Low Error Rates: Relatively little loss or corruption of data on each link.  > [!Figure] > _Packet switching network. Credit: NASA_ Many communication environments do not conform to the Internet's underlying assumptions of constant connectivity and low errors. These not-so-well-behaved environments are characterized by: - Intermittent Connectivity: The absence of an end-to-end path between source and destination is called network partitioning. In such cases, communication using the TCP/IP protocols does not work. - Long or Variable Delay: In addition to intermittent connectivity, long propagation delays between nodes and variable queuing delays at nodes contribute to end-to-end path delays that can defeat Internet protocols and applications that rely on the quick return of acknowledgments or data. - Asymmetric Data Rates: The Internet supports moderate asymmetries of bidirectional data rates for users with cable TV or asymmetric DSL service. However, if asymmetries are large, they defeat conversational protocols. - High Error Rates: Bit errors on links require correction (which requires more bits and more processing) or retransmission of the entire packet (which results in more network traffic). For a given link-error rate, fewer retransmissions are needed for hop-by-hop retransmission than for Internet-type end-to-end retransmission (linear increase vs. exponential increase, per hop).  > [!Figure] > _Delays, asymmetric data rates, high error rates, and intermittent connectivity are typical in wireless networks (credit: NASA)_ DTNs overcome the problems associated with intermittent connectivity, long or variable delay, asymmetric data rates, and high error rates by using store-and-forward message switching. This is an old method, used by pony-express and postal systems since ancient times. Whole messages (entire blocks of application-program user data) or pieces (fragments) of such messages are moved (forwarded) from a storage place on one node (switch intersection) to a storage place on another node, along a path that eventually reaches the destination.  > [!Figure] > _Store and forward architecture (credit: NASA)_ Store-and-forwarding methods are also used in today's email systems, but these systems are not node-to-node relays (as shown above) but rather star relays; both the source and destination independently contact a central storage device at the center of the links. The storage places (such as hard disks) can hold messages indefinitely. They are called persistent storage, as opposed to very short-term storage provided by memory chips and buffers. Internet routers use memory chips and buffers to store (queue) incoming packets for a few milliseconds while they are waiting for their next-hop routing table lookup and an available outgoing router port. DTN routers need persistent storage of their queues for one or more of the following reasons: - A communication link to the next hop may not be available for a long time. - One node in a communicating pair may send or receive data much faster or more reliably than the other node. - A message, once transmitted, may need to be retransmitted if an error occurs at an upstream (toward the source) node, or if an upstream node declines acceptance of a forwarded message. By moving whole messages or fragments thereof in a single transfer, the message-switching technique provides network nodes with immediate knowledge of the size of messages or fragments, and therefore the requirements for intermediate storage space and retransmission bandwidth. A growing number of communicating devices are in motion and operate on limited power. This is especially true in mobile wireless communication devices, such as cell phones. When communicating nodes are in motion, links can be obstructed by intervening bodies. When nodes must conserve power or preserve secrecy, links may be shut down. These events cause intermittent connectivity. When no path exists to connect a source with a destination, a network partition is said to occur. On the Internet, intermittent connectivity causes loss of data. Packets that cannot be immediately forwarded are usually dropped (discarded), and the TCP protocol may retransmit them with slower retransmission timing. If packet dropping is too severe, TCP eventually ends the session, which can cause applications to fail. DTNs, by contrast, support communication between intermittently connected nodes by isolating delays and disruptions with the store-and-forward technique. The intermittent connectivity may be opportunistic or scheduled. Network nodes may need to communicate during opportunistic contacts, in which a sender and receiver make contact at an unscheduled time. Moving people, vehicles, aircraft, or satellites may make contact and exchange information when they happen to be within line-of-sight and close enough to communicate using their available (often limited) power. Unlike mobile networks, when users and devices move randomly around the geography, in space, nodes move along predictable orbital paths, so they can predict or receive time schedules of their future positions and thereby arrange their future communication sessions. Scheduled contacts may involve message-sending between nodes that are not in direct contact. They may also involve storing information until it can be forwarded, or until the receiving application can catch up with the sender's data rate. Scheduled contacts require time synchronization throughout the DTN. #### Bundle Protocol The DTN architecture implements store-and-forward message switching by overlaying a new transmission protocol—called the bundle protocol—on top of lower-layer protocols such as the Internet protocols. The bundle protocol ties together the lower-layer protocols so that application programs can communicate across the same or different sets of lower-layer protocols, under conditions that involve long network delays or disruptions. A bundle-protocol agent stores and forwards entire bundles (or bundle fragments) between nodes. A single bundle protocol is used throughout a DTN. By contrast, the lower-layer protocols below the bundle protocol are chosen to suit the characteristics of each communication environment. The figure below (figure below, top) illustrates the bundle-protocol overlay and (bottom) compares the Internet protocol stack (left) with a DTN protocol stack (right).  > [!Figure] > _Bundle Protocol (credit: NASA)_ Bundles consist of three things: - A bundle header consisting of one or more DTN blocks inserted by the bundle-protocol agent, - A sourced application's user data, including control information provided by the source application for the destination application, describes how to process, store, dispose of, and otherwise handle the user data. - An optional bundle trailer, consisting of zero or more DTN blocks, and inserted by the bundle-protocol agent (not shown in the figure below). Like application-program user data, bundles can be arbitrarily long. Bundles extend the hierarchy of data-object encapsulation performed by the Internet protocols. The example below shows how bundle encapsulation works in the context of the lower-layer TCP/IP protocols. The bundle protocol does not alter the Internet protocol data; it merely encapsulates the application protocol data. A bundle-protocol agent may break whole bundles into fragments (not shown in the figure below), just as the IP protocol may break whole datagrams into fragments. If bundles are fragmented, the bundle-protocol agent at the destination reassembles them.  > [!Figure] > _Bundle encapsulation (credit: NASA)_ On intermittently connected links with long delays, conversational protocols such as TCP (that involve many end-to-end roundtrips may take impractical amounts of time or they may fail. For this reason, DTN nodes communicate between themselves using simple sessions with minimal or no roundtrips. Any acknowledgment from the receiving node is optional, depending on the class of service selected. The bundle protocol sits on top of the convergence layer protocol stack, which supports bundle exchanges. The boundary between the bundle protocol and the lower-layer protocols is called the convergence layer interface. The convergence layer protocol stack may be conversational, like TCP, but on intermittently connected links with long delays, non-conversational or minimally conversational lower-layer protocols may be more practical.  > [!Figure] > _Bundle convergence layer (credit: NASA)_ ##### Bundle Nodes In a DTN, a _node_ is an entity with a bundle-protocol agent overlaid on lower-layer communication protocols. At any moment, a given node may act as a source, destination, or forwarder of bundles: - Source or Destination Function (figure below, left)—As a source or destination, a node sends or receives bundles to or from another node, but it does not forward bundles received from other nodes. If the node operates over long-delay links, its bundle protocol requires persistent storage in which to queue bundles until outbound links are available. The node may optionally support custody transfers. - Forwarding Function—A DTN node can forward bundles between two or more other nodes in one of two situations: - Routing-Equivalent Forwarding (figure below, middle): The node forwards bundles between two or more other nodes, each of which implements the same lower-layer protocols as the forwarding node (the figure below, middle, shows these lower-layer protocols as type "A"). If a forwarding node operates over long-delay links, its bundle protocol requires persistent storage in which to queue bundles until outbound links are available. The node may optionally support custody transfers. - Gateway-Equivalent Forwarding (figure below, right): The node forwards bundles between two or more other nodes, each of which implements different lower-layer protocols while the forwarding node implements all such protocols (the figure below, right, shows these lower-layer protocols as types "A" and "B"). The node must have persistent storage; support for custody transfers is optional but typically advisable.  > [!Figure] > _DTN Nodes and Roles_ On the regular Internet, the TCP protocol provides end-to-end (source-to-destination) reliability by retransmitting any segment that is not acknowledged by the destination. The network, link, and physical protocols provide other types of data-integrity services. In a DTN, the bundle protocol relies on these lower-layer protocols to ensure the reliability of communication. However, all DTN nodes terminate lower-layer transport protocols. The bundle protocol agents thus act as surrogates for end-to-end sources and destinations. The beneficial side-effect is that conversational lower-layer protocols are isolated by the bundle protocol from long delays elsewhere in the end-to-end path. The bundle protocol alone supports end-to-end data exchange. Bundles are typically delivered atomically, from one node to the next, independent of other bundles except for optional responses, although a bundle-protocol agent may break a single bundle into multiple bundle fragments.  > [!Figure] > _DTN and transport-protocol termination_ ##### Custody Transfers DTNs support node-to-node retransmission of lost or corrupt data at both the transport and the bundle layers. However, because no single transport protocol (the primary means of reliable transfer) typically operates end-to-end across a DTN, end-to-end reliability can only be implemented at the bundle layer, or above. The bundle protocol supports node-to-node retransmission by means of custody transfers. Such transfers are arranged between the bundle-protocol agents of successive nodes, at the initial request of the source application. When the current bundle custodian sends a bundle to the next custodian (not necessarily the next node in the path), it requests a custody transfer and starts a time-to-acknowledge retransmission timer. If the next bundle-protocol agent accepts custody, it returns an acknowledgment to the sender. If no acknowledgment is returned before the sender's time-to-acknowledge expires, the sender retransmits the bundle. The value assigned to the time-to-acknowledge retransmission timer can either be distributed to nodes with routing information or computed locally, based on past experience with a particular node. A bundle custodian must store a bundle until either (1) another node accepts custody, or (2) the expiration of the bundle's time-to-live, which is intended to be much longer than a custodian's time-to-acknowledge. However, the time to acknowledge should be large enough to give the underlying transport protocols every opportunity to complete reliable transmission. Custody transfers enhance end-to-end reliability, but they do not guarantee it. Further enhancement can be achieved by using both custody transfer and return-receipt services.  > [!Figure] > _DTN custody transfer mechanism_ On the Internet traffic, the TCP and IP protocols are used throughout the network. TCP operates at the endpoints of a path, where it manages reliable end-to-end delivery of TCP segments. IP operates at all nodes on the path, where it routes IP datagrams. In a DTN, all nodes implement both the bundle protocol and a lower-layer transport protocol. Nodes that forward bundles can implement either the same or different lower-layer protocols on either side of the forwarding; in this respect, their functions are comparable to Internet routers or gateways, respectively.  > [!Figure] > _Internet-like transfers vs Bundle transfers (credit: NASA)_ ##### Bundle Protocol Services The bundle protocol provides the following classes of service for a bundle: - Custody Transfer: Delegation of retransmission responsibility by one node to another accepting node, so that the first node can recover its retransmission resources. The accepting node returns a custodial-acceptance acknowledgment to the previous custodian. - Return Receipt: Confirmation by the destination to the source, or to its report-to endpoint, that the bundle has been received by the destination application. Reception by the source, or its report-to endpoint, of the return receipt, provides end-to-end assurance of delivery. - Priority of Delivery: Bulk, Normal, or Expedited (not shown in the figure below). - Time-to-Live: (not shown in the figure below). Congestion control is the main purpose of this function. The concept comes from the Internet, but unlike Internet congestion in which packets are lost because there is insufficient transmission bandwidth to forward them all, DTN congestion consists of packets that are lost because there is insufficient memory to store them all while awaiting a transmission opportunity. Storage is the main DTN resource that needs to be conserved. A good value to use for Time-to-Live is the greater of two values: (1) the longest time that the packet must live to achieve its purpose, and (2) the estimated transit time to the destination, plus some margin of error.  > [!Figure] > _Bundle services (credit: NASA)_ ##### Security The Bundle Security Protocol (BSP) provides data integrity, authentication, and confidentiality. Only security-aware (SA) nodes with the capacity to originate and process BSP security blocks provide these services. Processing may require some action on a bundle—which may include discarding it—to conform with that node's security policy. The BSP defines four types of security blocks: - Bundle Authentication Block (BAB): Ensures bundle authenticity and integrity along the path from the forwarding SA node to the next receiving SA node. If a BAB is used, its header must be the last header applied to a bundle. - Payload Integrity Block (PIB): Ensures integrity of payload by verifying the signer. - Payload Confidentiality Block (PCB): Encrypts bundle payload. - Extension Security Block (ESB): Provides security for non-payload blocks. The default security policy for SA nodes requires a BAB. If an SA node has no security policy, only a BAB is required. By default, a BAB policy violation at an SA receiving node requires the deletion of the bundle. This default BAB requirement is intended to protect the DTN from DDoS attacks by ensuring the maintenance of trusted relationships between adjacent SA nodes. See RFC 6257 for details. The figure below shows the path of a PIB block. If a PIB policy violation occurs at an SA receiving node (the green X), the policy determines the node's actions, which may include the sending of a bundle status report to the originating node, as shown in the figure below.  > [!Figure] > _Bundle Security Protocol_ ## Design Example: A Ring Space Network ### Constellation Geometry It's time to design the geometry of the ring network. Of course, this will be a simplified process and it will not consider a plethora of factors that must be considered when designing a constellation of this kind, such as launcher-cost effectiveness, space traffic management matters, and many, many other aspects. The requirement is that the ring is located around the equator. Note that this is a fully optical constellation therefore, there shouldn't be interference risks with the geostationary belt. To design a ring network, we need to ensure each, and every node will have line-of-sight with a neighboring node. Otherwise, there would be no ring whatsoever (we will see soon that ground stations will play a role in this). And here the granularity of the ring in terms of the number of nodes used enters the picture. We could, of course, launch hundreds of satellites in the same plane, and then our ring would always stay connected because there would be no possibility of the Earth blocking the line of sight (we will see that soon that there might be other factors to interrupt connectivity). Of course, launch costs would be prohibitive. But what would be the minimum number of satellites to achieve this? To determine the minimum number of satellites required to be placed around the equator such that each satellite has a line of sight with at least two neighboring satellites, we need to consider the curvature of the Earth and the orbital altitude of the satellites. For satellites in a circular orbit around the Earth's equator, they must be spaced in such a way that the line of sight from one satellite to its neighbor just grazes the Earth's surface. This condition is known as having a geometric horizon. The actual number depends on the altitude of the satellites since higher altitudes allow for a greater distance between satellites. From the figure below, the `Node0` position vector is described by vector `v`. The vector b connects `Node0` with `Node1`, and this vector must always stay above the surface of the Earth for `Node0` and `Node1` to have mutual visibility. The same applies to the node "behind" `Node0`.  > [!Figure] > _Node geometry for the ring network constellation (as viewed from the poles)_ We will call $r$ the Earth's radius (approximately 6,371km). Vector $v\ = \ r + h$, that is, `Node0` position is the sum of the Earth's radius plus its altitude $h$. The distance from a `Node0` to the horizon we will call $d\ = \frac{\left| \overrightarrow{b} \right|}{2}$ (remember $b$ is the vector that connects `Node0` and `Node1` in the figure above. Then, there's a right triangle described by vector v (remember that it's equal to r+h) by Earth radius a by d. To calculate d (which is important to understand the sizing of the ring constellation), we simply apply the Pythagorean theorem: $\large c^{2} = a^{2} + b^{2}$ In our case, $\large {(r + h)}^{2} = d^{2} + r^{2}$ And solving for $d$, it gives: $\large d = \sqrt{2rh + h^{2}}$ Let's calculate the minimum number of satellites required for a given altitude. Since we want each satellite to have a line of sight to two neighboring satellites, the distance between satellites along the orbit will be $2d$. The circumference of the Earth's orbit at the satellite's altitude is $C = 2\pi\left( r + h \right)$. The minimum number of satellites, $n$, is then given by: $\large n = \frac{C}{2d} = \frac{\pi\left( r + h \right)}{\sqrt{2rh + h^{2}}}$ Let's calculate this for a typical Low Earth Orbit (LEO) altitude, say 500 kilometers. ```Python import math # Constants radius_earth_km = 6371 # Radius of the Earth in kilometers altitude_km = 500 # Altitude of the satellite in kilometers # Calculate the distance to the horizon from the satellite distance_horizon_km = math.sqrt(2 * radius_earth_km * altitude_km + altitude_km**2) # Calculate the circumference of the Earth's orbit at the satellite's altitude circumference_orbit_km = 2 * math.pi * (radius_earth_km + altitude_km) # Calculate the minimum number of satellites required min_satellites = circumference_orbit_km / (2 * distance_horizon_km) ``` For satellites in a Low Earth Orbit (LEO) at an altitude of 500 kilometers, the minimum number of satellites required to be placed around the equator, ensuring that each satellite has a line of sight with at least two neighboring satellites, is approximately 8.39. Rounding up, this means at least 9 satellites are required for this configuration. A ring constellation with 9 satellites will require a separation of 40 degrees in true anomaly between the nodes (see figure below).  > [!Figure] > _A 9-satellite ring constellation (as viewed from the poles)_ This design has one particularity we might need to address. If one satellite in the ring would not be able to perform (due to some off-nominal situation), then the ring would be disrupted. For instance, if `Node1` or `Node8` became inoperative, `Node0` would have no way of reaching `Node7` nor `Node2`, due to the fact they would not have a mutual line of sight. Another factor is that we have considered inter-satellite communication in the ring, but what about the links to the ground? The constellation would not be very useful if the satellites were only communicating with each other. We must consider the location of ground stations under the ring.  > [!Figure] > _A 9-satellite constellation shows single points of failure if a node is down (red lines mark lack of line of sight between two nodes adjacent to a failed node)_ The fact the constellation is equatorial adds some complexity to the ground segment matte, considering that a substantial portion of the area under the equator line is water. But how much is actually water? To determine the percentage of land and water along the Earth's equator, we need to consider the total length of the equator and the lengths of the sections that pass over land and water. The Earth's equator is approximately 40,075 kilometers (24,901 miles) long. To find the percentages of land and water along this line, we need to know the lengths of the equator that cross over landmasses and those that cross over bodies of water. However, exact calculations can be complex due to the irregular shapes of coastlines and the presence of islands along the equator. The most accurate method to determine this would be to use detailed geographical data and mapping software, which can account for these complexities. That said, a rough estimate based on major landmasses crossed by the equator includes: - South America (Ecuador, Colombia, Brazil) - Africa (Gabon, Republic of the Congo, Democratic Republic of the Congo, Uganda, Kenya, Somalia) - Asia (Indonesia) To give a basic estimation: 1. South America: The equator crosses about 4,200 kilometers in South America. 2. Africa: The equator spans about 7,300 kilometers across Africa. 3. Asia (Indonesia): This is the most complex section due to the archipelagic nature of Indonesia, but a rough estimate might be about 3,000 kilometers. Adding these together gives an approximate total land distance of 14,500 kilometers. This is a very rough estimate and could be off due to the complexities mentioned earlier. Based on the rough estimates: - Approximately 36.18% of the equator passes over land. - Approximately 63.82% of the equator crosses over water. Therefore, right under the constellation, there is more water than land. To determine the best locations for ground stations for an equatorial constellation, we should consider major cities situated close to the equator. These cities should be distributed as evenly as possible around the equator to maximize coverage and ensure continuous communication with the satellites. Given the requirement for an equatorial orbit and the presence of 9 satellites, we should ideally place ground stations at roughly equal intervals along the equator. This would mean placing them approximately 40° apart longitudinally (360°/9 satellites). We can identify some major cities near the equator and then select the most appropriate ones based on their geographic distribution: 1. Quito, Ecuador 2. Nairobi, Kenya 3. Kampala, Uganda 4. Singapore 5. Jakarta, Indonesia 6. Brazzaville, Republic of the Congo 7. Libreville, Gabon 8. São Tomé, São Tomé and Príncipe 9. Manaus, Brazil 10. Kisangani, Democratic Republic of the Congo From this list, we need to select cities that are distributed approximately 40° apart along the equator. It's also important to consider practical aspects such as political stability, existing infrastructure, and accessibility. Based on these criteria, a potential selection of ground stations could be: - Quito, Ecuador - Latitude: 0.1807° S - Longitude: 78.4678° W - Altitude: 2,850 meters (9,350 feet) - Libreville, Gabon - Latitude: 0.4162° N - Longitude: 9.4672° E - Altitude: 13 meters (43 feet) - Kampala, Uganda - Latitude: 0.3476° N - Longitude: 32.5825° E - Altitude: 1,189 meters (3,900 feet) - Jakarta, Indonesia - Latitude: 6.2088° S - Longitude: 106.8456° E - Altitude: 8 meters (26 feet) - Singapore - Latitude: 1.3521° N - Longitude: 103.8198° E - Altitude: 15 meters (49 feet) - Manaus, Brazil - Latitude: 3.1190° S - Longitude: 60.0217° W - Altitude: 72 meters (236 feet) - Kisangani, Democratic Republic of the Congo - Latitude: 0.5167° N - Longitude: 25.2000° E - Altitude: 419 meters (1,375 feet) - São Tomé, São Tomé and Príncipe - Latitude: 0.3300° N - Longitude: 6.7333° E - Altitude: 8 meters (26 feet) This distribution aims to cover various regions along the equator, taking into account the presence of major cities and the practicalities of establishing and maintaining ground stations. ### Satellite Configuration The satellite nodes in the ring must be able to stay within safe margins and in high availability as long as possible. This means they will need to generate enough power to stay in nominal mode. One of the first things to evaluate is how the Sun will behave for the orbit selected, and what would be the best solar panel configuration for effective power generation. Equatorial orbits are rather inconvenient for power scavenging using solar panels as opposed to other orbits like Sun-synchronous where the Sun describes more deterministic trajectories. Assuming the satellite is in an Earth-pointing orientation, the Sun describes a sunrise, noon, and sunset at every orbit (see figure below).  > [!Figure] > _Sun angle with respect to -Z axis (1 day, roughly 15 orbits)_ For a full year, we see a slightly worsening situation toward equinoxes in March and September:  > [!Figure] > _Sun angle with respect to -Z axis (1 year)_ Of course, there will also be eclipses involved, which are not shown in the figures above. For the intended ring network configuration, there will be two faces of the satellites that must be allocated for placing laser comm terminals, given that each node must be able to establish a link with two neighboring nodes: forward and rear. But it must also connect with a ground-based node (a telescope). Therefore, the +X and -X sides of the satellite will be allocated to host the inter-satellite LCTs whereas the +Z face will be allocated to host the laser comm terminal to the ground (see figure below for the axes convention and direction of flight).  > [!Figure] > _Satellite body axes and direction of flight_ The locations of the optical terminals are shown in the figure below.  > [!Figure] > _Directions of forward, rear, and ground FSO terminals._ If we defined a vector normal to the "roof" of the satellite (-Z axis, assuming Earth pointing), the angle the Sun will describe with respect to this vector will show that there is a considerable amount of time the solar panels would not be illuminated by the Sun, affecting power generation (see figure below).  > [!Figure] > _For an equatorial orbit, the Sun describes wide angles with respect to a fixed solar panel_ Is this a real problem? Design requirements can only tell. A power budget that includes the power consumption of the laser terminals, and the avionics will provide the insight to help engineers decide what to do. A network of the kind we are pursuing will require the onboard comms equipment to be in a powered-on state for very long times (practically at all times), therefore it all hints that fixed solar panels in the -Z direction will be a suboptimal solution. The alternative would be using articulated solar panels which can track the Sun as it moves across the orbital plane. The articulated panels will need stepper motors for rotating the assembly, increasing complexity and thus decreasing the reliability of the design.  > [!Figure] > _Solar panel plane showing 0-degree rotation_  > [!Figure] > _Solar panel plane with 90 degrees of rotation_ With these two positions (see figures above), we measure the angle to the Sun as the plane rotates and tracks the projection of the Sun along the orbit plane. For that, we define a vector normal to the rotating plane (called "SP_Normal" in the figure below), and we gauge the angle between said normal vector and the Sun vector as seen from body coordinates.  > [!Figure] > _Solar panel rotating plane_ We see that the angle is now better behaved, reaching zero degrees during equinoxes (that is, fully perpendicular to the normal, providing maximum power) and reaching a maximum of 23.45 degrees at solstices in June and December. The reason for this is nothing but the geometry we discussed before when we described the geometry of [[Non-Terrestrial and Mobile Networks#Orbits|orbits]] and the role of the ecliptic plane and the apparent movement of the Sun.  > [!Figure] > _Solar angle considering a rotating solar panel (1 full year)_ With all this, we can start to identify a candidate physical configuration (see figure below for a rudimentary sketch).  > [!Figure] > _A first iteration of physical configuration (top image is a top view, as seen from zenith; bottom image is as seen from +X direction)_ There are still many factors that may affect the physical configuration chosen, for instance (the list is not exhaustive): - Separation ring location: satellites are attached to rockets employing a mechanical interface that is usually a ring with loaded springs that push the satellite into orbit. This ring is a volume-consuming but necessary device on-board so there must be a place for it in the configuration. In the current configuration, there are not many options left with two faces taken by solar panels and three phases taken by terminals. That leaves the top side as the candidate face for the ring, which can be suboptimal from a thermal perspective and also because the top face is typically taken by optical sensors and antennae. An option would be to have just one but bigger solar panel wing and use one of the faces in the Y direction. Longer panels will be less rigid and introduce challenges in attitude control. Moreover, having only one wing will also introduce mass imbalances that must be addressed. - GNSS antennae location: satellites in low-Earth orbits determine their position by the same navigation services used on the ground. Because GNSS constellations fly higher than LEO, GNSS antennas tend to be put on the "roof" of satellites. In some cases, mechanical booms are used for GNSS antennas to avoid interference from the satellite to affect the capability of the GNSS receiver to track positioning satellites. - Star sensor location: star sensors are cameras that must have a clear view of the sky for tracking stars and inferring orientation from those stars. Star sensors tend to carry voluminous baffles and satellites must place at least two of these sensors for redundancy. An important factor to consider is to orient these sensors to avoid interference from sunlight and obscuration with Earth, therefore, designers must run extensive field-of-view analyses to choose the right location for them. Star sensors placed in the wrong location may lead to satellites losing the possibility of keeping a 3-axis attitude, affecting connectivity in the ring if the laser terminals lose their pointing. - Propulsion: most satellites require propulsion for orbit correction, trimming, and disposal. Thruster nozzles are bulky and require cutouts in the body. The first iteration of the configuration does not leave a lot of room for propulsion, being another reason to reconsider it. The second iteration proposes the propulsion to be located in the face -Y of the satellite. This will require a yaw maneuver for propulsion and will affect the ring connectivity since the forward and rear LCTs will not have a line of sight with neighboring nodes. - Thermal considerations: orbit geometry, and in particular Sun's apparent move as seen from the satellite, may overheat some equipment which may require relocation. In extreme cases, the satellites need to perform preventive maneuvers to keep equipment within thermal limits, which may impact service availability (terminals may lose pointing). - Launcher envelope constraints: rockets specify maximum volumes for satellite accommodation, and said volumes are not always perfectly cube-shaped. In fact, envelopes tend to be frustum-shaped. - And many other factors.  > [!Figure] > _Second iteration for accommodating separation ring and propulsion._ We will assume the design issues highlighted in the list above will be incrementally solved by the design team as the project matures without disrupting the location of the relevant elements for the network design (namely, laser terminals' locations). The spirit of this section was to highlight the iterative nature of the early stages of geometric and physical configuration discovery and what are the factors that feed and shape the process. ### Constellation Simulation It's time now to make our constellation fly. For this, we will simulate the behavior of one satellite and replicate it for as many satellites as our constellation will be composed of. We will then create a software object (a small numerical backend) that will simulate a spacecraft at a reasonably coarse level, including the [[Modeling The Environment|environment]]. The functionalities to include in the simulation are: - Perturbed orbit propagation from input Keplerian orbit elements - Initial date and time - Body-fixed frame of reference, inertial frame of reference (J2000), Earth-centered, Earth-fixed frame of reference (ECEF). - Basic vectors: sun vector, body angular velocity, line-of-sight vectors to ground stations and neighboring satellites - Basic satellite state variables: pointing mode, control torque - Basic attitude profiles (Sun pointing, Earth pointing) - Export of position and attitude files for 3d viewing in an external tool. With the simulation environment in place, we will then create a batch of 9 instances of satellites on the same orbit but with different anomalies, separated by 40 degrees as per the constellation geometry analysis done before. A simulated satellite exports its ephemeris file in a format we can import into the analysis tool.  As well as attitude data:   > [!Figure] > _Constellation geometry as per the conceptual design_ We can now measure the phasing between two nodes, to ensure they match the 40-degree separation our design requires.  > [!Figure] > _Measuring the phasing between constellation nodes_ As per the ground station locations defined before, there is a big arc of the equator without ground stations, since this area is just water. We will run simulations to analyze the effect of this. One factor to consider next is how will nodes orient their data terminals in the direction of neighboring nodes. Laser comms terminals work by knowing the host's and the target's position in a given frame of reference. In general, terminals use inertial frames of reference; in our case, we will use J2000. Then, our onboard laser terminal will need to be fed with the inertial position of the forward, rear, and ground nodes. In complex constellations, the inertial positions would need to be uploaded to every node to have up-to-date orbital positions of target nodes and then the avionics would need to send to the terminals this positional data at regular intervals. Because the constellation design pursued in this example is a regular polygon (a nonagon in our case), we can use this to our advantage and simplify the situation substantially. For a nonagonal orbit, if we draw a tangential, locally horizontal line at each node (that means, perpendicular to the imaginary line that connects a node with the center of the polygon), we will see that every neighboring node will appear at 20 degrees lower in elevation. Therefore, we could command the LCTs to point 20 degrees down in elevation along the rear and forward direction, and we would be pointing in the direction of the near and forward nodes (see sketch below).  > [!Figure] > _A nonagonal orbit shows regular angles between nodes which can be used to orient laser terminals_ Of course, this simplistic method assumes each node will manage to keep the 40-degree phasing of the nonagonal ring reasonably constant. A decent station-keeping capability shall be added to the node avionics. We will now create these rear and forward vectors in our simulation environment. We will use the orbit frame of reference and simply define two vectors in the +X and -X direction, and then rotate them -20 and 20 degrees along the Y axis in that frame of reference. Then, we will transform these two vectors into the inertial frame (J2000), which are the coordinates the LCTs will use. The figure shows the geometry of said vectors.  > [!Figure] > _LCTs' pointing vectors to the rear and forward nodes_ To evaluate how good this approach is, we can measure the difference between the Node_Rear and Node_Forward vectors with respect to the theoretical vectors pointing to the near and forward nodes as per ephemeris data. The measurement is plotted in the figure below, which shows that is quite satisfactory.  > [!Figure] > _Error angles between LCT vectors and node vectors as defined in the ephemeris data_ For our space network, we choose a hypothetical laser comms terminal with the following specs: - Wavelength: 1550 nm - Data Rate: Up to 10Gbps - Max Range: 5000 km - Azimuth: +/- 160° - Elevation: -65° to +80° - Data Communication Interface: 10GBASE-T - Telemetry and Telecommand Interface: RS-422 ### Concept of Operations Each node in the ring will have its body oriented to Earth at all times. That means, every node will point its +Z axis to the center of the Earth. ### Network Simulation We will now simulate our little ring space network. For this, we will try to replicate the topology in a minimalistic way to have an environment where we can see the data moving and understand the implications of our design decisions. Creating networks for testing and experimentation purposes can be done in different ways. One way is to use network simulation tools such as GNS3[^119] or similar, which typically include a user interface to connect nodes with switches and hubs. Another alternative would be to use virtual machines which could be eventually demanding in terms of computing power and storage. We will take a lean path. We will create our own small, simulated network by using [[Semiconductors#Containers|containers]]. Containers appear as a lightweight approach compared to virtual machines, while still providing all the means to experiment with networking and protocol stacks.  > [!Figure] > _Simulated ring network using containers_ Another advantage of containers is the possibility of easily sharing memory with the host. This is, surprisingly, bizarrely more complicated with virtual machines (with the exception of QEMU which offers the `ivshmem`[^120] mechanism, although not the most straightforward mechanism ever). Why is shared memory relevant? We will employ shared memory as the "physical" medium by means of which nodes will exchange frames, simulating the optical links at least at a high level. The architecture of our simulated network is depicted in the figure above. The shared memory segments will act as transmit and receive FIFOs. Then, we will write a small application called "node app" that will encapsulate IP datagrams in an ethernet-like frame, and then push encapsulated frames into said FIFOs for another node app on the other side of the channel which will decapsulate the frame and pass the IP datagrams into the TCP/IP stack inside the operating system using a tunnel interface. Using these FIFOs, we can then chain nodes together and simulate the network ring: the receive FIFO of one node will be hooked to the transmit FIFO of the neighboring node, and vice versa. The Dockerfile of our network node is as follows: ```Dockerfile # Use Ubuntu as the base image FROM ubuntu:latest # Update the package repository and install necessary packages RUN apt-get update && \ apt-get install -y net-tools iputils-ping iproute2 telnet netcat traceroute && \ apt-get clean # Any additional commands or environment setup can go here # Copy the startup script into the container COPY setup-tun.sh /setup-tun.sh # Give execution rights to the startup script RUN chmod +x /setup-tun.sh # The default command to run when starting the container CMD ["bash"] ``` The `setup-tun.sh` is a shell script to allow nodes to create tunnel interfaces: ```Shell #!/bin/bash # Use the first argument as the IP address IP_ADDRESS=$1 IF_NAME=$2 # Setup TUN device (this script needs to be run in a container started in privileged mode) ip tuntap add mode tun dev $IF_NAME ip addr add $IP_ADDRESS/24 dev $IF_NAME ip link set dev $IF_NAME up ``` We will first create two nodes for testing: `NODE0` and `NODE1`. For this, we will first build the containers using the Dockerfile we described above: ```Shell docker build -t my-net-tools-image . ``` We will then run the two containers with: ```Shell docker run -v /home/ignacio/workspace_node/node/Debug/:/shareData/ --cap-add=NET_ADMIN --device /dev/net/tun:/dev/net/tun -it --privileged --ipc=host my-net-tools-image ``` With this last command, we are telling our container to share data with the host (both with a shared folder and also shared memory) and also to create the tun interface. Mind that many of these features require running the container in privileged mode. With all this in place, `NODE0` and `NODE1` containers, representing two satellite nodes in our network, can be executed. Once running, we configure two tun interfaces in the NODE0: ```Shell ./setup-tun.sh 10.0.3.1 tun0 ./setup-tun.sh 10.0.3.2 tun1 ```  Additionally, we run our tiny node application for handling the tx and the rx: ``` ./node 8482 8483 tun0 & ``` Where: - 8482 is the shared memory key ID of the receive FIFO - 8483 is the shared memory key ID of the transmit FIFO - `tun0` is the name of the tunnel interface our program must be attached to But every node has two interfaces: a rear and a forward one. Therefore, we must run another node program for the rear interface: `./node 8480 8481 tun1 &`  With all this, `NODE0` is having forward and rear interfaces up, connected to transmit and receive FIFOs. And now we do the same in `NODE1`: ``` ./setup-tun.sh 10.0.3.3 tun0 ./setup-tun.sh 10.0.3.4 tun1 ./node 8481 8480 tun0 0 & ./node 8466 8455 tun1 0 & ``` Note how `NODE1`'s receive and transmit FIFOs are "crossed" with respect to NODE0's FIFOs, as expected (`NODE0`'s transmission needs to hit NODE1's reception, and vice versa).  With everything in place and running, we can then try to ping `NODE1` from `NODE0`, and vice versa.  You will note a significant dispersion in the round trip time of the ping commands. This is somewhat expected considering we are using simple buffers as the medium for frames to traverse from node to node. The scheme is not necessarily deterministic. However, this is good for the overall simulation of the ring network; we should expect similar delays and dispersion when dealing with real optical links. We will add now a third node; `NODE2`. We will do the same steps as before, launching the container and configuring the interfaces, with IPs and shared memory keys.  > [!Figure] > _Adding a third node to the ring_ And now a key factor appears: routing. In our ring network, when `NODE0` wants to reach `NODE1`, the connection is rather direct; these two nodes share a channel. But when `NODE0` wants to reach `NODE2`, it has to go through `NODE1`. Therefore, we must equip our network with routing capabilities. And now a valid question appears: how do we do this routing? Or, more specifically, which layer will be in charge of doing this routing? Remember our node app is encapsulating IP frames in some fake Ethernet frame. But you remember from previous sections that data link frames (like Ethernet) are not supposed to do routing but are supposed to strictly deliver frames from source to destination. Our fake Ethernet frames lack the information to understand who the final destination of a frame is. What is more, our data link layer lacks the means to have routing tables; those tables just don't exist. Then, the correct way out of this is to push this responsibility to the layer which is, unsurprisingly, in charge of these things: the network layer, or layer 3. Let's add a fourth node to the exercise, and let's play with routing tables. With four nodes, the concept is practically described in its entirety, and thus reaching the final configuration of eight nodes is a matter of extending this example.  > [!Figure] > _Half of the ring network_ The goal is to route traffic to the correct next hop based on the destination IP address. Here are the routing tables for each node: To route traffic from Node0: - To reach Node1 (10.0.3.3 or 10.0.3.4), use interface 10.0.3.2. - To reach Node2 (10.0.3.5 or 10.0.3.6), use interface 10.0.3.2. - To reach Node3 (10.0.3.7 or 10.0.3.8), use interface 10.0.3.2. To route traffic from Node1: - To reach Node1 (10.0.3.1 or 10.0.3.2), use interface 10.0.3.3. - To reach Node2 (10.0.3.5 or 10.0.3.6), use interface 10.0.3.4. - To reach Node3 (10.0.3.7 or 10.0.3.8), use interface 10.0.3.3. To route traffic from Node2: - To reach Node0 (10.0.3.1 or 10.0.3.2), use interface 10.0.3.5. - To reach Node1 (10.0.3.3 or 10.0.3.4), use interface 10.0.3.5. - To reach Node3 (10.0.3.7 or 10.0.3.8), use interface 10.0.3.6. To route traffic from Node3: - To reach Node0 (10.0.3.1 or 10.0.3.2), use interface 10.0.3.8. - To reach Node1 (10.0.3.3 or 10.0.3.4), use interface 10.0.3.7. - To reach Node2 (10.0.3.5 or 10.0.3.6), use interface 10.0.3.7. In a real-world scenario, we would set up these routes using commands on each node's operating system. Because our containers run Linux, we can use `ip route add` commands. For example, on `Node0` to add a route to `Node1`, you would use: ``` ip route add 10.0.3.3/32 via 10.0.3.2 ip route add 10.0.3.4/32 via 10.0.3.2 ip route add 10.0.3.5/32 via 10.0.3.2 ip route add 10.0.3.6/32 via 10.0.3.2 ip route add 10.0.3.7/32 via 10.0.3.2 ip route add 10.0.3.8/32 via 10.0.3.2 ``` Issuing an `ip route` command shows the configuration:  For NODE1: ``` ip route add 10.0.3.5/32 via 10.0.3.4 ip route add 10.0.3.6/32 via 10.0.3.4 ip route add 10.0.3.7/32 via 10.0.3.4 ip route add 10.0.3.8/32 via 10.0.3.4 ``` We verify the configuration with ip route:  For `NODE2`: ``` ip route add 10.0.3.7/32 via 10.0.3.6 ip route add 10.0.3.8/32 via 10.0.3.6 ``` Again, we double-check with `ip route`:  With all this, we should have in place the routing scheme for our rudimentary ring network simulator made with tiny containers. We will then try to reach `NODE3` from `NODE0` with a ping command:  It can be seen how the round trip time (rtt) of the ping command increases accordingly (and the TTL decreases as expected), taking into account the double hop needed for reaching `NODE3`. We can use `traceroute` to see these hops and the times involved:  We can try something else than just a ping command. We can open a TCP port in listening mode in `NODE0` and connect `NODE3` to it and have a conversation. We will use `netcat` for it:  Which `NODE0`receives as expected:  We will profile now the network connections. > [!to do] > Next, we will add more fidelity to the network simulation where nodes will go offline as satellites suffer off-anomaly situations and lose pointing, and we will implement the [[Non-Terrestrial and Mobile Networks#Bundle Protocol|Bundle Protocol]] to see the works of delay-tolerant networks and store-and-forward schemes. Also, experimentation with a simple 5GC and a simulated RAN will be tried. Security will also be added by incorporating encryption in the communication between nodes. #### Securing our Network Thus far, our network has been working unencrypted. It is time now to add encryption and for that, we will use TLS. First, we will do again an unencrypted `netcat` between nodes and we will sniff the conversation simulating an external attacker and observe the plaintext coming and going. > [!Warning] > This section is under #development #### Traffic Shaping Traffic shaping is a network management technique used to control the flow and volume of data transmission to ensure efficient use of bandwidth and improve network performance. This technique involves regulating the data transfer rate for certain types of data or specific users. The primary goal is to prevent network congestion, maintain quality of service, and ensure that no single user or application monopolizes the bandwidth. At its core, traffic shaping involves delaying some or all of the packets to bring the data flow into compliance with a desired traffic profile. This is often done by using tools or devices that can limit the bandwidth for certain types of traffic or traffic heading to specific destinations. For instance, a network administrator might limit the bandwidth for streaming video during business hours to ensure that critical business applications get priority. In practice, traffic shaping is achieved through a combination of limiting data transfer rates (bandwidth throttling), prioritizing certain types of traffic (such as VoIP over file downloads), and using queuing disciplines that determine how packets are processed and transmitted. This process not only helps in managing the network efficiently but also in reducing latency and packet loss for important traffic. The need for traffic shaping arises in various scenarios, especially in enterprise networks, Internet service providers, and data centers where the demand for bandwidth can exceed the available capacity. By controlling how the bandwidth is allocated and used, organizations can optimize their network resources, improve user experience, and maintain control over their network traffic patterns. To play with traffic shaping in our simulated constellation network, we will use the tc command. The tc command in Linux, which stands for "traffic control," is a powerful tool used for network traffic management. It allows you to configure the Linux kernel packet scheduler, which is responsible for controlling the rate of traffic sent out on a network interface. This is often referred to as traffic shaping, and it can be convenient for managing bandwidth, reducing network congestion, prioritizing certain types of traffic, and ensuring quality of service (QoS). Basic Concepts of tc are: - Queuing Disciplines (qdiscs): These are rules that determine how packets are enqueued for transmission. There are several types of qdiscs, each serving different purposes, like FIFO (First In, First Out), Stochastic Fairness Queueing (SFQ), and Token Bucket Filter (TBF). - Classes: Some qdiscs support creating classes, which are essentially buckets of traffic that can be treated differently. You can assign different bandwidth limits to different classes. - Filters: Filters are rules that classify packets into different classes. They can be based on various packet attributes like source/destination IP, port numbers, protocol, etc. ##### 1. Adding a Queuing Discipline Suppose we want to limit the outgoing bandwidth on an interface (tun1) to 1Mbps. One could use the Token Bucket Filter (TBF) for this: ```bash tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms ``` This command breaks down as follows: - `add dev eth0`: Specifies the network interface, `eth0`. - `root`: Indicates that this qdisc is attached to the root of the interface. - `tbf`: Specifies the Token Bucket Filter. - `rate 1mbit`: Limits the bandwidth to 1 Megabit per second. - `burst 32kbit`: Allows bursts of data up to 32 Kilobits. - `latency 400ms`: Specifies the maximum time packets can be buffered before being sent. ##### 2. Viewing the Configuration To see the details of your traffic control settings, use: ```bash sudo tc qdisc show dev eth0 ``` ##### 3. Deleting a Queuing Discipline To remove the configuration, you would use: ```bash tc qdisc del dev eth0 root ``` ##### Advanced Usage For more complex scenarios, like prioritizing certain types of traffic (e.g., VoIP over web browsing), you'd create multiple classes within a `qdisc`, each with its own rate limit, and then use filters to direct traffic to the appropriate class. ##### Things to Keep in Mind - **Complexity**: `tc` can be complex, especially as you get into more advanced configurations. It's important to thoroughly understand the network requirements and how different qdiscs and classes interact. - **Testing**: Always test your configurations in a controlled environment before applying them to a production network. - **Documentation**: The `man` pages (`man tc`) and many online resources provide valuable information for deeper understanding and more complex scenarios. A few considerations: - Routing Efficiency: This setup provides a basic routing path. In real scenarios, especially if the network is larger or more complex, one might want to implement dynamic routing protocols. - Redundancy and Failover: In a ring topology, if one link goes down, the network can still function by rerouting traffic the other way around the ring. Dynamic routing protocols can handle such scenarios automatically. - Subnetting: In a more complex network, you might need to consider subnetting and more advanced routing strategies. > [!Note] > If anything, this experiment with our network simulation should shed light on the value of leaving higher layers doing the routing heavy lifting. If we force networking responsibilities on lower layers (like the data link layer) we must create all those functionalities **by hand**. > [!Warning] > This section is under #development [^113]: TR 38.811, "Study on New Radio (NR) to support non-terrestrial networks," V15.4.0, October 2020. [^114]: Voyager I and II are powered by RTGs. They have been working since 1977, even though power output has decreased considerably. [^116]: The word 'verification' is more general than 'test'. According to the bibliography, there are several ways of verifying things, and testing is just one of them. [^117]: <https://link.springer.com/chapter/10.1007/978-3-030-66898-3_6> [^118]: <https://link.springer.com/book/10.1007/978-3-642-01276-1> [^119]: https://www.gns3.com/ [^120]: https://www.qemu.org/docs/master/system/devices/ivshmem.html [^121]: Uplink and downlink might use different frequencies (if using FDD), the same (TDD) or a combo of the two.