Infrastructure and management of cellular core networks and radio access networks in space

Abstract

The present invention provides a network management computer system and method that operates to provide communications in conjunction with a terrestrial mobile cellular network. [Solution] The network management computer system calculates future state-space predictions of the network using assumptions about attitude and orbital control laws for the orbital infrastructure, and predicts satellite trajectories in lower orbits (LEO) with considerable accuracy for many hours, days, or even weeks into the future using gravity models, atmospheric models, and numerical integration schemes. The orbital network infrastructure uses its data to gain insights into future inertial state vectors to future network connectivity states, predicts optimal future network operation, and pre-adjusts with ground network deployments.

Description

Technical Field

[0001] The present disclosure relates to a space communication network operable to provide communication with a terrestrial mobile cellular network. [Cross-reference to Priority Claiming Applications and Related Applications]

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 728,015, filed on September 6, 2018, entitled "Network Management and Resource Allocation in a Communication Network Having Both Orbital Nodes and Terrestrial Nodes in a Common Network" and U.S. Provisional Patent Application No. 62 / 727,972, filed on September 6, 2018, entitled "Orbital-Based Cellular Network Infrastructure Management System", and is a non-provisional application thereof.

[0003] The following patents / applications may be referenced herein.

[0004] 1) U.S. Patent Application No. 15 / 857,073, filed on December 28, 2017, entitled "Method and Apparatus for Handling Communications between Spacecraft Operating in an Orbital Environment and Terrestrial Telecommunications Devices That Use Terrestrial Base Station Communications" (hereinafter, "Speidel I").

[0005] 2) U.S. Provisional Patent Application No. 62 / 465,945 (hereinafter, "Speidel II"), filed on March 2, 2017, entitled "Method for Low-Cost and Low-Complexity Inter-Satellite Link Communications within a Satellite Constellation Network for Near Real-Time, Continuous, and Global Connectivity".

[0006] 3) U.S. Provisional Patent Application No. 62 / 490,298, entitled "Method for Communications between Base Stations Operating in an Orbital Environment and Ground-Based Telecommunications Devices" (hereinafter, "Speidel III"), filed on April 26, 2017.

[0007] The entirety of the above-mentioned patent / application disclosure is incorporated herein by reference for all purposes as if it were fully described herein. [Background technology]

[0008] In a typical terrestrial cellular telecommunications network, multiple mobile devices communicate with multiple telecommunications infrastructure elements. This telecommunications infrastructure may include, but is not limited to, hardware such as towers, antennas, radio waves, transceivers, digital signals, processors, electrical cabinets, servers, and computers. This telecommunications infrastructure is typically organized as an integrated system for managing the amount of telecommunications traffic from various mobile devices being served, both functionally and in terms of connectivity. This integrated system may comprise one or more networks. These networks themselves are typically also designed to connect with each other through various interfaces and protocols. Some of these protocols and interfaces may include, but are not limited to, TCP / IP, ISDN®, SS7, etc. Terrestrial cellular networks and their functions can be used in the context of a typical LTE cellular network. However, inferior structures and functions to this type of network may be used for other terrestrial cellular networks, such as GSM®, CDMA, EDGE, and UMTS.

[0009] Figure 1 shows a high-level architecture of a typical LTE terrestrial cellular network. Each node in Figure 1 represents an operational “node” in the network. In some embodiments, nodes are implemented by software that runs and is hosted by electronic hardware. Each node may serve a specific function or set of functions, may be responsible for signaling the control plane and / or routing traffic in the user plane, and may have interfaces to other nodes in the network for routing control traffic or user traffic. A visitor network 102 may host a radio access network (RAN) 106 and a core network 108. The visitor network may interact with a home network 104. The home network 104 also hosts the same or similar types of radio access network and core network as the visitor network. For brevity, not all elements may be shown. The network may be a home network or a visitor network, depending on the subscriber end-user.

[0010] The wireless access network may be E-UTRAN, and the core network may be EPC. E-UTRAN may include base stations 110 that enable communication with UEs 112 via an air interface (Uu). The base stations may be base stations for an LTE network. Such base stations may be “evolutionary node B” base stations or “UTRAN node B” base stations. These are often referred to as “eNodeB” or “base station,” respectively. The base stations include hardware for wirelessly connecting the cellular network and mobile handsets (UEs).

[0011] Base stations can operate control signaling and user signaling by maintaining connectivity with each other via the X2 interface. Base stations connect to the EPC via the control plane and user plane, i.e., S1-CP and S1-UP. The control plane interfaces with MME114, and the user plane interface interfaces with S-GW116. MMEs may connect to S-GWs via other control interfaces, i.e., via the S11 interface, via other MMEs via the S10 interface, and via the S6a interface to the HSS database 122. The EPC also hosts P-GW118. P-GWs have control plane and user plane connections to S-GWs via the S5 interface in the home network. A similar connection may exist between the S-GW of the visiting network and the P-GW of the home network 120. This connection is the S8 interface and also includes the control plane and user plane. P-GWs maintain a control interface at PCRF124. The P-GW maintains a connection to the PDN server 126 via the SGi interface.

[0012] Figure 2 shows the control plane protocol stack for each interface in the LTE network. This illustrates how each node connection for passing control traffic is implemented. The control plane interface may be wired or wireless. The UE stack 202 communicates with the base station stack 204 via the LTE-Uu interface 212, operating the application layer, IP layer, PDCP layer, RLC layer, MAC layer, and PHY layer. The base station stack relays application layer packets and IP layer protocol packets, but encodes requirements such as HARQ, ARQ, etc. by coordinating the modulation scheme of air interface interactions and channel allocation using the PDCP, RLC, MAC, and PHY layers. The base station stack routes traffic from the UE to the core network via the S1-U interface 214 to the S-GW stack 206. A tunneling protocol, i.e., GTP-U, is used to pass IP-based data packets between the base station and the S-GW. The S5 and S8 interfaces 216 are nearly identical to the S1 interface. However, the S-GW stack relays IP packets, and the P-GW stack 208 receives IP data packets. The P-GW functions as a serving node for routed IP traffic using the SGi interface 218 between the UE and the Packet Data Network (PDN) stack 210, which provides backend IP services for the end UE. The application layer compatible with the application layer on the UE resides on the PDN, which provides application layer services (e.g., smartphone applications). The base station stacks 204 communicate with each other via the X2-U interface 220. The X2-U interface routes IP data packets for the end UE during handover between base stations, etc., using the tunneling protocol GTP-U and SCTP transport layer.

[0013] Figure 3 shows the user plane protocol stack for each interface in the LTE network. This illustrates how each node connection for passing user traffic can be implemented. The user plane interface may be wired or wireless. The UE stack 302 communicates with the base station stack 304 via the LTE-Uu interface 316. The Non-Access Layer (NAS) is a functional layer in the LTE radio far-field communication protocol stack between the MME stack 306 and the UE stack. The NAS layer operates across the network and is used to manage the establishment of communication sessions and to maintain continuous communication with user equipment. The base station stack relays this layer between the MME and the UE and uses PDCP to transport radio resource control messages to the UE. The MME stack communicates with the base station stack via the S1-C interface 318. The MME uses SCTP to transport S1-AP protocol sessions based on NAS signaling. The MME communicates with the S-GW stack 308 via the S11 interface 320. This interface transports IP packets using the tunneling protocol and UDP. The S-GW stack also communicates with the P-GW stack 310 via the S5 / S8 control plane interface 322, using a structure similar to the S11 interface. Further interfaces exist, such as the X2-C interface 324 between UE stacks 304, which transports X2-AP messages using UDP. This is used for control signaling between base stations during UE handover. The MME stack 306 communicates via the S10 interface 326, which transports tunneling protocol messages using UDP. The MME stack also communicates with the HSS database 312 via the S6a interface 328, which transports diameter messages using SCTP. The same stack is used on the S7 interface 330, which connects the P-GW stack 310 to the PCRF database 314. [Mobile Handset / Device]

[0014] Generally, individual users carry mobile devices that operate on a network. These mobile devices are typically cell phones or cellular phones, and are often referred to as user equipment (UE) or mobile stations (MS) among more technical experts. Mobile devices may also include machine-to-machine (M2M) or Internet of Things (IoT) cellular devices or cellular modules. In this description, the network cell phones or end-user devices described may be referred to as UEs.

[0015] A UE may comprise hardware and a SIM card. Hardware may include the physical phone or the device itself. Actual hardware may include a set of numbers known as the device's International Mobile Equipment Identity (IMEI). This number is unique to the exact part of the hardware used to check whether the physical device is on and marked as stolen on the network, and for other purposes. The physical device typically includes a transmitter and receiver so that it can interface with a cellular network via an air interface or RF interface. Along with the transmitter and receiver, there may be digital interfaces such as a screen / keyboard, or electrical interfaces such as GPIO pins. These interfaces may be used to control how the device accesses the network and transmits and receives voice, text, or data payloads / data packets.

[0016] Furthermore, the UE is typically loaded with firmware and application layer software that allows the user to access specific functions. These functions may include voice calls, sending SMS messages, browsing the internet, or using other applications (e.g., messaging, games, streaming, etc.). The UE may require specific signal levels or QoS to achieve certain data rates over the air interface with the mobile network. For example, SMS texting can function fine at relatively weak link levels (and therefore with low-order modulation schemes at high coding overhead rates and therefore with low data rates), while video streaming may require higher data rates (and therefore with high-order modulation schemes at low coding overhead rates and therefore with higher data rates) for a reasonable number of downloads and quality of video streams. Typically, the UE is designed to access cellular networks with a variety of possible bandwidths (e.g., frequencies) and protocols (e.g., GSM, LTE, UMTS, CDMA, etc.). Some smartphones may be referred to as "world phones." This is because they are designed to accommodate bandwidth and protocols that allow end users to travel the world and remain connected to local cellular networks in various locations around the globe, regardless of the differences in cellular protocols being used. This is because typical cellular bandwidth allocations for protocols such as LTE, GSM, and CDMA are well established, and licenses are allocated to specific MNOs in specific countries around the world.

[0017] A subscriber identification module, or SIM, contains subscriber identification information for a user to use a network. One of the various numbers and pieces of information stored on a SIM is the International Mobile Telephone Subscriber Identification Number (IMSI), a unique number corresponding to a specific subscriber on a network. Some phones allow for multiple SIM cards, meaning a single device can have multiple IMSIs. This allows end-users to have local plans in multiple countries, or even within the same country, if they wish to be a "home" user on multiple networks. Furthermore, SIM cards can be swapped internally and externally within a device to change subscriber identification information and connect to different networks as a "home" subscriber. This technology can be advantageous for users who travel frequently and do not wish to pay roaming charges each time they travel. [Wireless access network]

[0018] To access the network, the UE uses an air interface with the cellular network's Radio Access Network (RAN). As the name suggests, the RAN can be a network that enables access using radio frequency communications. The RAN acts as an interface between mobile devices on the network and the core network of the telecommunications infrastructure itself.

[0019] In LTE architecture, the RAN is often referred to as the Evolutionary UMTS Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN typically comprises multiple base stations, which are functional elements implementing a physical interface or Uu along with the UE. The physical interface is suspended within time and frequency as time slots and resource blocks (RBs). RBs are allocated to the UE by the base station's scheduler, which can be driven by one of several algorithms that optimize traffic flow depending on location, deployment configuration, coverage requirements, etc. Base stations in the network interface with each other via X2 interfaces. This enables the forwarding and signaling of call / text / data packets, primarily to support base station-to-base station handovers when the UE operates in a mobile manner over the network. Base stations also connect the UE to the core network, or the Evolutionary Packet Core (EPC) within the LTE network, via S1 interfaces. [Core Network]

[0020] The core network, often referred to as the Evolutionary Packet Core (EPC) within the LTE architecture, holds most of the authorization functions within the cellular network, acting as an interface between a UE and the network, the internet, and other UEs on other networks / devices, where the UE may need to communicate. Access to other networks and the internet allows subscribers to communicate with users not on their home network and upload / download data to and from the internet for specific applications / servers. Even if a UE wants to communicate with other UEs on the same home network, the EPC enables the UE's access by handling authentication.

[0021] When using the LTE protocol, the core network typically comprises a Mobility Management Entity (MME), a Serving Gateway (S-GW), a Packet Data Network (PDN) Gateway (P-GW), and a Home Subscriber Server (HSS). In LTE, the MME hosts the Visitor Location Register (VLR), while the HSS hosts the Home Location Register (HLR), Equipment Identification Information Register (EIR), and Authentication Center (AuC). The HLR, VLR, EIR, and AuC are databases managed by the EPC and will be described in more detail later. [Mobility Management Entity (MME)]

[0022] Within the EPC, there are several control plane interfaces and user plane interfaces. E-UTRAN interfaces with the EPC via a control plane with an MME called the S1-CP interface. The S1-CP interface uses the Non-Access Layer (NAS) to manage the establishment of communication sessions and maintain continuous communication with user equipment when user equipment is in operation. The LTE S1-CP interface is responsible for distributing the signaling protocol between the base station and the MME. The S1-CP interface features the Stream Controlled Transmission Protocol (SCTP) over IP and supports multiple UEs through a single SCTP association. It also provides guaranteed data distribution. The application signaling protocol is the S1-AP (Application) protocol. The LTE S1-CP is responsible for the Evolutionary Packet System (EPS) bearer setup / release procedure, handover signaling procedure, paging procedure, and NAS transport procedure.

[0023] Furthermore, the MME has a control plane interface with other MMEs via the S10 interface, an S-GW via the S11 interface, and an HSS via the S6a interface.

[0024] The S11 interface between the MME and the S-GW is typically a many-to-many interface. This means that a single MME can handle multiple S-GWs each having its own S11 interface. These connections can be used to coordinate the establishment of SAE bearers within the EPC. The SAE bearer setup can be initiated by the MME (default SAE bearer) or the P-GW. By using the S11 interface, the MME node can create or delete IP sessions, create or delete default bearers, create or delete dedicated bearers, add rules for creating or modifying / updating dedicated bearers, perform UE handovers, perform X2-based UE handovers in S-GW relocation, and perform S1-based UE handovers in S-GW relocation. [Serving Gateway (S-GW)]

[0025] The E-UTRAN interfaces with the EPC via the user plane having an S-GW called the S1-UP interface. The S1-UP interface provides unassured data delivery of LTE user plane protocol data units (PDUs) between the base station and the S-GW. The transport network layer is built on IP transport and GTP-U. UDP / IP holds the user plane PDUs between the base station and the S-GW. A GTP tunnel per radio bearer holds the user traffic. The S1-UP interface is responsible for delivering user data between the base station and the S-GW. IP differentiated services code point (DSCP) marking is supported for QoS per radio bearer.

[0026] The S-GW provides an IP routing service for packets between the UE and the core network using the GPRS Tunneling Protocol (GTP) by connecting to the P-GW via the S5 interface or the S8 interface. The S5 interface is used within a single (home) network, and in principle, S5 and S8 are the same interface, except that the S8 interface is used when roaming between different operators. In the case of non-roaming, the functions of the S-GW and the P-GW can be executed within one physical node.

[0027] S5 / S8 is a many-to-many interface that provides user plane tunneling and tunnel management between the serving GW and the PDN GW. The S8 interface is used for relocation of the serving GW due to UE mobility and when the serving GW needs to be connected to a non-collocated PDN GW for the required PDN connection. The S5 interface is an inter-PLMN reference point that provides the user plane and control plane between the serving GW within the VPLMN and the PDN GW within the HPLMN. S8 is an inter-PLMN variant of S5. [Packet Data Network Gateway (P-GW)]

[0028] A P-GW is a node that terminates the SGi interface toward the PDN. If a UE accesses multiple PDNs, there may be more than one P-GW for that UE. The P-GW provides the UE with connectivity to the external packet data network by being the exit and entry point for that UE's traffic. A UE may have simultaneous connections to more than one P-GW to access multiple PDNs. The P-GW performs policy enforcement, packet filtering for each user, charge support, and legitimate interception and packet screening. This reference point provides connectivity between the P-GW and the packet data network. The SGi interface can provide access to various network types, including external public or private PDNs and / or internal IMS service provision networks. [Cellular Network Database]

[0029] An LTE network may manage a set of databases used not only for operational queries to manage UE mobility, but also for authentication, billing, policy management, etc. The HSS is the home of the HLR, which is a database containing administrative level information about each subscriber who can use the network. The HLR also includes a field that tracks the last confirmed location of a subscriber within the network. This information may be used to position a device when calls, messages, or data need to be routed. When a user switches cellular or mobile devices, or when they move to a different Location Area Code (LAC) within the network, or perhaps over some regular periodicity, mobile devices may update their location so that the HLR always knows their most up-to-date location. Typically, a device's location is maintained in the context of the network (e.g., which base station the device is camped on), rather than the device's actual latitude / longitude location. Typically, there is only one master HLR in any given network. However, copies of it may be distributed across various core network nodes for improved operational efficiency.

[0030] HSS is a combination of HLR and AuC, with two functions already present within pre-IMS 2G / GSM and 3G / UMTS networks. The HLR portion of HSS is responsible for storing and updating a database containing user subscription information, including user identification and addressing (corresponding to IMSI (International Mobile Subscriber Identification Number) and MSISDN (Mobile Subscriber ISDN Number) or mobile phone number) and user profile information (including service subscription status and user subscription quality of service information (such as maximum allowable bitrate or maximum allowable traffic class)) (the enumeration is not exhaustive), as needed.

[0031] The AuC portion of HSS is responsible for generating security information from the user identification key. This security information is provided to the HLR and further communicated to other entities within the network. The security information can be used for network-terminal mutual authentication to ensure that data and signaling transmitted between the network and terminals are not intercepted or altered, as well as for encryption and integrity protection of the wireless path.

[0032] A VLR is a smaller, temporary version of a HLR in some forms, containing selective information from the HLR. Any “visitor,” or UE roaming on a base station controlled by an EPC that is not part of the home network, is placed on the VLR of the visited network. A UE can typically only exist in one VLR at a time. This can be crucial for network routing of traffic to that UE. Data stored in the VLR is collected from the user’s home network HLR or directly from the UE itself via the base station. The VLR is used to inform the HLR of the subscriber’s updated location’s home HSS so that traffic routing can be completed across separate networks. Users are typically removed from the VLR when they become inactive for a set period (a period configured / can be configured for each network), when the UE roams to a new VLR domain location area, or when the user moves back onto the home network.

[0033] The VLR may include a portion of the field values ​​of each IMSI, including the TMSI, which effectively functions as temporary subscriber identification information during roaming operations outside the home network.

[0034] The EIR (Enterprise Information Record) is a database that holds information about specific handsets, mobile devices, or other devices that can connect to or attempt to connect to a network. This database uses the IMEI (International Mobile Equipment Identity) to determine whether a device has the authority to access the network. Typically, if a phone is reported stolen, the device's IMEI will be placed in a list within the EIR that associates it with the stolen device. In this way, if a device attempts to register with the network, the network can deny access to prevent misuse by potential phone thieves.

[0035] Ultimately, the AuC is a database containing information related to device authentication to the network. The AuC is typically interfaced to the HLR and holds critical keys for specific IMSIs on the network. These keys also reside on the UE SIM. Matching these keys enables both device authentication and encryption (or decryption) over the air interface channel. In roaming scenarios, this authentication key / information is queried from the home HLR. [Network Operations Center]

[0036] The components described above operate autonomously on a terrestrial cellular network, but typically, some level of human interaction is also implemented. The Network Operations Center, or NOC (sometimes also known as the Operations Management Center, or OMC), is a network component that enables the control and monitoring of the operation and status of the network infrastructure. This node in the network, not shown in Figure 1, will maintain connectivity to each element in the network. For example, this node may even be used to control the traffic load in the base station / E-UTRAN subsystem. The NOC typically has connectivity to each base station, MME node, S-GW node, and P-GW node in the LTE network. [A. Example of network procedure]

[0037] A network can implement a long list of procedures, but certain specific procedures are used in most cases and may be important for network functions such as mobility management and spectrum utilization. [A.1 Authentication Procedure]

[0038] Authentication procedures within an LTE network are used for both authenticating user identification numbers (e.g., verifying their subscriber numbers) and granting or denying access to the network. Authentication leverages a unique key stored in the HSS and performs operations on the UE and MME sides of the network to calculate a value, compare the results, and verify authentication. Similar procedures are used for encryption and ciphering of non-access spectrum (NAS) (e.g., signals / packets on the network route) and access spectrum (AS) (e.g., signals / packets on the RF interface between the UE and the base station).

[0039] Figure 4 shows a typical process for UE authentication within an LTE network. This process involves UE 402, base station 404, MME 406, and HSS 408. The UE sends a request to the MME to attach to the network 410. In this request, the UE sends the IMSI and other information about the UE handset capabilities that the network may require for authentication and management of the air interface with the UE. The MME makes an authentication data request 412 to the home network HSS. This message may include a list of IMSIs that require authentication, along with some other information that the HSS may need for a response. The HSS provides a response to the MME 414, along with what is called an authentication vector.

[0040] Each authentication vector includes AUTN, XRE, KSAME, and RAND values ​​related to the output obtained from executing an algorithm called the EPS AKA algorithm. The MME passes the RAND and AUTN values ​​to the UE through base station 416. The UE uses this information to execute the EPS AKA algorithm and then provides a response to MME 418, which includes the RES value. The RES value should be equal to the XRE value calculated by HSS and provided to the MME. The MME checks this in 420, and if it is true, the UE is authenticated to the network.

[0041] Next, the MME and UE may perform a further step 422 to achieve ciphering and encryption of the AS (RF Interface) and NAS (Network Control Interface) sessions between the UE and the network. These steps are similar in nature to authentication, in that the UE node and / or base station node may perform an algorithm to compute a unique key that is checked and verified before being used to encrypt traffic between nodes. After these steps are completed, the MME may accept the original attach request from the UE 424 and be formally attached to the network, enabling it to move traffic.

[0042] Authentication is triggered when the UE first requests access to the network. [A.2 Location Update Procedure]

[0043] In classic mobile networks, the location of each device can be tracked so that the network understands how it interacts with UEs (User Entities) that need to deliver or receive information. The various tracking parameters used by the network are described elsewhere in this specification. The location of the UE on the network is tracked from a master database in the HSS (Hands-Service Server). If the UE's location changes, it is reflected in the HSS. If the UE is connected to a network that is not its own home network, the UE's location is tracked by both the HSS and the VLR (Virtual Listing Repository). The VLR temporarily stores subscriber authentication information and the UE's location within its network. If the UE's location changes, the VLR can request a location update from the HSS so that the HSS can manage the location change for the UE.

[0044] Under certain roaming conditions, the physical locations of the MME and VLR where the subscriber is located may be far from the HSS, which holds critical management information required by the device for authentication. Authentication may take several minutes if queries can be routed through SS7 or another medium interfacing various terrestrial networks. These inter-network interactions can be slowed down, especially for network procedures, if the traffic load is high and the database is located far away. As a result, initial access to the external network may be delayed. However, once access is provided, typical speeds associated with cellular services typically resume.

[0045] Table 1 lists examples of triggers that may initiate a location update procedure for the UE. [Table 1]

[0046] Figure 5 shows a typical location update or tracking area update procedure. The associated nodes shown are UE502, base station 504, new MME (e.g., new tracking area) 506, old MME (e.g., old tracking area) 508, S-GW510, and HSS512. After the RRC connection setup is completed between the base station and the UE, the UE may initiate a tracking update request (514). The base station may route the request to the new MME (516). The new MME may request information via a context request from the old MME, which it uses to perform authentication / security procedures with the UE (518). The old MME may respond to the new MME with the information it requested (520). The new MME then authenticates the UE (522). After successful authentication, the new MME may acknowledge the request context from the old MME (524). The new MME then may request a bearer correction from the S-GW (526). A bearer modification request from the new MME is responded to (528), and the new MME immediately requests a position update from the HSS (530). The HSS cancels the current position held on the old MME (532). After the cancellation is acknowledged by the old MME (534), the HSS acknowledges the position update request from the new MME in 536. The new MME then accepts the UE's TAU request 538, and the UE acknowledges the completion of the position update procedure (540). [A.3 Handover Procedure]

[0047] During UE mobility, there are unavoidable instances where a UE needs to transition from one cell to another within the network. Each cell may be serviced by one eNB, and multiple eNBs may be serviced by a single S-GW and / or MME. There are scenarios where only an eNB handover is necessary, and other scenarios where an S-GW handover is necessary. In some cases, even a P-GW handover may be required.

[0048] Figure 6 illustrates how a handover can conventionally occur between the eNB and the S-GW. The elements involved in the handover procedure are the UE602, source eNB604, target eNB606, MME608, source S-GW610, target S-GW612, and P-GW614. The handover can occur after an IP session has already been established between the UE and the P-GW via the source eNB and source S-GW (616). A measurement control message from the UE to the source eNB can trigger preparation for a handover between it and the target eNB (618). The target eNB and source eNB can perform the handover via the X2 interface (620). The source eNB begins transferring data to the target eNB so that the data can be downlinked to the UE (624) (622). At this point, the uplink data has passed through the target eNB, through the source S-GW, and back to the P-GW (626). The downlink is provided to the target eNB (via the X2 interface) through the source eNB, but via the same S-GW, before reaching the UE. The target eNB requests a rerouting request (628) from the MME to reroute the IP packets to the target S-GW.

[0049] The MME requests the target S-GW to create a session (630). The target S-GW requests the P-GW to modify the bearer for the UE (632). The P-GW provides a modified bearer response and modifies the bearer to the target S-GW (634). The target S-GW responds to the MME with a session creation response to indicate that it is ready to carry IP traffic from the UE through the target eNB (646). The MME acknowledges the original route switching request from the target eNB (638), and the uplink and downlink data flows from the UE to the target eNB, to the target S-GW, and to the P-GW (640). This indicates the completion of the S-GW handover, and the link on which the downlink data will be used to be forwarded from the source eNB is released (642). The MME deletes the session provided by the original source S-GW (644), and the source S-GW responds after closing the session (646). After an S-GW handover, the UE may need to update the tracking area, and does so in conjunction with the MME (648). [A.4 Transmission Procedure for Master Information Blocks (MIB) and System Information Blocks (SIB)]

[0050] An MIB, or Master Information Block, is a message or information broadcast by an LTE base station regardless of whether any user is present. The MIB is the first of several System Information Blocks (SIBs) that are also broadcast by the base station.

[0051] MIBs are transmitted using a physical layer channel called the PBCH, or Physical Broadcast Channel, on the downlink. MIBs are 24-bit values ​​encoded as shown in Table 2. [Table 2]

[0052] In addition to the information in the payload, the MIB CRC also conveys the number of transmission antennas used by the base station. The MIB CRC is scrambled or XORed using an antenna-specific mask.

[0053] There may be multiple system information blocks, each transmitted at a certain period and containing important information about network access. For example, an SIB1 block may contain one or more of the variables listed in Table 3. [Table 3] [B. IP Address Assignment in LTE]

[0054] LTE networks are often entirely IP networks in that they deliver all user traffic within IP packets and provide users with "always-on IP connectivity." When a UE joins an LTE network, a Packet Data Network (PDN) address (i.e., one that can be used within a PDN) is assigned to the UE for connection to the PDN, and a default bearer is established within the LTE network (i.e., between the UE and the P-GW). This default bearer remains connected until the UE detaches from the LTE network (i.e., the IP address assigned to the UE during the initial attachment remains valid). A default bearer is established for each APN (Access Point Name) that the user has, and therefore a unique IP address is assigned to each APN. The IP address may be of IPv4 type, IPv6 type, or IPv4 / IPv6 type.

[0055] When the UE first attaches to the LTE network, it requests a PDN connection. The P-GW then assigns the UE an IP address to be used for the PDN (i.e., the PDN address) and forwards these two to the UE while the connecting default bearer is established. With this IP address, the UE can access the services provided through the PDN.

[0056] IP addresses can be assigned statically or dynamically within an LTE architecture. Typically, IP addresses are assigned dynamically due to the limited IP pool within each P-GW. Limited IP address availability is typically associated with IPv4 systems but is less of an issue in IPv6 systems.

[0057] In dynamic IP assignment, the network (e.g., P-GW) automatically selects an IP address for the UE. The network operator has a pre-supplied IP pool at the P-GW. Then, the next time the UE first attaches to the LTE network, the P-GW dynamically assigns an IP address to the UE. Therefore, a new dynamic IP address is typically assigned to the same UE each time it first attaches to the network.

[0058] In the case of static IP assignment, the network operator assigns a permanent IP address to each UE when it joins the network. The operator has the assigned static IP address supplied for the UE within the network (HSS), along with other subscription information. Then, the next time the UE first attaches to the LTE network, the P-GW retrieves the static IP address from the HSS and forwards it to the UE. Thus, each time the UE first attaches thereafter, this particular IP address is assigned to the UE. [C. Cellular network numbering and addressing]

[0059] Mobile networks typically manage mobile devices and therefore may implement different types of geographical areas and addresses to function properly when UEs attach to and detach from base stations within a network managed by different network EPC nodes. [C.1 Geographic Area]

[0060] The MME pool area is a geographical area controlled or serviced by a specific MME or a set of MMEs. The MME area is the physical region in which a mobile device can operate before the MME providing service to that mobile device is changed. The S-GW tracking area is a geographical area controlled or serviced by a specific S-GW or a set of S-GWs. Within this geographical area, the UE can operate without changing the S-GW providing service.

[0061] A tracking area refers to the smallest geographical area used by the network. The MME pool area includes the S-GW tracking area. The S-GW tracking area itself includes these smaller tracking areas. A tracking area can be as small as a particular cell tower cell or group of cell tower cells (perhaps a geographical area that can be precisely represented by a circle of some radius ranging from a few kilometers to a maximum of 100 kilometers). These tracking areas are similar to the Location Area Codes (LACs) used in GSM or the tracking areas used in UMTS, and as the name suggests, are used to track the location of mobile devices on the network that are on standby (e.g., connected to the network and ready to move or receive traffic).

[0062] Therefore, the LTE network includes many MME areas, even more S-GW tracking areas, and even more tracking areas. [C.2 Network Identification]

[0063] Furthermore, the network manages hosts whose numerical identifiers are used as network-level addresses. The network ID is used to define the network itself. The network is identified using a Public Land Mobile Network (PLMN) code, which is a combination or concatenation of two unique identifiers: the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Since the MCC is a three-digit code and the MNC is a two- or three-digit code, when these two are concatenated, the PLMN is a five- or six-digit code.

[0064] Each MME in the network is assigned a unique identifier known as an MME code, or MMEC. This identifier identifies a specific MME within each of the network's MME pools. MMEs grouped within the same MME tracking area are assigned a group-level code called MME group identification information, or MMEGI. For each MME in the network, another identifier is used to generate an MME identifier, or MMEI, by concatenating the MMEC and MMEGI. This identifier identifies a specific MME across the entire network. Finally, the PLMN and MMEI are concatenated to generate a globally unique MME identifier, or GUMMEI. This identifier identifies a specific MME anywhere in the world.

[0065] Tracking areas are also identified using a similar code. The Tracking Area Code, or TAC, is used to identify a specific tracking area within a particular network. This number is concatenated to the PLMN to generate a Globally Unique Tracking Area Identifier, or TAI. This identification identifies a unique tracking area across the globe.

[0066] Furthermore, each cell in the network is provided with a cell ID so that specific towers that need to communicate with the UE can be identified and tracked. This cell ID is often referred to as the E-UTRAN cell identifier, or ECI. This value uniquely identifies a cell within a particular network. There is also an E-UTRAN cell global identifier, or ECGI. This identifier uniquely identifies a cell anywhere on the planet. Typically a number between 0 and 503, there is also a physical cell ID for towers, which is used to distinguish itself from neighboring cells in a nearby region.

[0067] There are mobile device identifiers for tracking specific UE hardware as it operates on the network. As previously mentioned, each UE has two unique identifiers, one for the hardware and one for the SIM. The International Mobile Device Identification Number (i.e., IMEI) is used to identify a unique handset hardware. The International Mobile Telephone Subscriber Identification Number (i.e., IMSI) is used to identify a unique subscriber (e.g., SIM) on the network. There is also a Type M Temporary Mobile Subscriber Identification (i.e., M-TMSI) used to identify a specific UE to a serving MME. By concatenating the M-TMSI code to the MMEC, the network generates a Type S Temporary Mobile Subscriber Identification (i.e., S-TMSI) used to identify a specific UE to a serving MME pool tracking area. Finally, by concatenating the PLMN, MMEGI, and S-TMSI, a Globally Unique Temporary Identification (GUTI) is generated. The GUTI identifies a UE and its temporary address that is unique anywhere on this planet. [D. Wireless Protocol Architecture]

[0068] A wireless protocol architecture can be defined by two distinct planes: the control plane and the user plane. Each node interface in the network can implement the control plane, the user plane, or both. The control plane is where network signaling is packaged and transported between the various nodes in the network. In the control plane, typically the Radio Resource Control (i.e., RRC) protocol generates signaling messages that control how information is passed between the UE and the cellular network. These signaling messages are transported using appropriate signaling bearers.

[0069] The user plane is where the actual data or telecommunications payload is transported between UEs and across the network. Typically, applications generate data packets that are processed by protocols such as TCP, UDP, or IP. For both the control plane and the user plane, information or signaling packets are processed by packet data convergence protocols, i.e., PDCP, radio link control protocols, i.e., RLC, and medium access control protocols, i.e., MAC, before they are ultimately passed to the physical layer, i.e., the RF layer, for radio transmission to UEs connected to the network.

[0070] Figure 7 shows the base station radio protocol stack architecture. Base station 706 maintains interfaces with MME 704 and S-GW 702 to move the required control traffic and user traffic, respectively. Base station 706 has a radio resource control function (RRC) 708 that handles communication with the MME. The radio resource control function may include a support scheduling function used to provide further information related to control messages sent to lower layers in the protocol stack. PDCP 710, RLC 712, MAC 714, and PHY 716 together transport user traffic and control traffic between UEs in the network and the appropriate control plane and user plane. The PDCP acts as the transport layer, receiving user and control messages and generating a common transport channel. The radio link control layer packets user and control information into packets.

[0071] The PHY716 holds information from the MAC transport channel via the air interface and handles link-matching AMC, power control, cell lookup for initial synchronization and handover, and other measurements within the LTE system and between systems for the RRC layer.

[0072] The MAC714 layer is responsible for mapping between logical channels and transport channels, multiplexing MAC SDUs from one or different logical channels to transport block TBs delivered to the physical layer on the transport channels, demultiplexing MAC SDUs from one or different logical channels to transport block TBs delivered from the physical layer on the transport channels, scheduling of information reporting, error correction via HARQ, prioritization processing between UEs by dynamic scheduling, prioritization processing between logical channels of a single UE, and prioritization of logical channels.

[0073] The RLC712 operates in three operating modes: Transparent Mode (TM), Unacknowledged Response Mode (UM), and Acknowledged Response Mode (AM). The RLC layer is responsible for forwarding upper layer PDUs, error correction via ARQ (for AM data forwarding only), and concatenation, segmentation, and reassembly of RLC SDUs (for UM and AM data forwarding only). The RLC layer is responsible for resegmentation of RLC data PDUs (for AM data forwarding only), reordering of RLC data PDUs (for UM and AM data forwarding only), duplicate detection (for UM and AM data forwarding only), discarding of RLC SDUs (for UM and AM data forwarding only), re-establishment of the RLC, and protocol error detection (for AM data forwarding only).

[0074] The PDCP710 layer is responsible for compressing and decompressing IP data headers, data transfer (user plane or control plane), maintaining the PDCP sequence number SN, intra-sequence distribution of upper-layer PDUs during lower-layer re-establishment, removal of duplicate lower-layer SDUs during lower-layer re-establishment for radio bearers mapped with RLC AM, encryption and decryption of user plane and control plane data, protection and verification of control plane data integrity, and timer-based discard and duplicate removal. PDCP is used for SRBs and DRBs mapped on DCCH and DTCH type logical channels.

[0075] The sub-layer services and functions of the Wireless Resource Control (RRC) 708 include broadcasting system information related to non-access layer NAS, broadcasting system information related to access layer AS, paging, establishing, maintaining, and releasing RRC connections between the UE and E-UTRAN, and security functions including managing, establishing, configuring, maintaining, and releasing key points for point-to-point wireless bearers.

[0076] The non-access layer NAS protocol used by the MME704 and UE forms the control plane layer between the user equipment UE and the MME. The NAS protocol supports UE mobility and session management procedures to establish and maintain IP connectivity between the UE and the P-GW. [D.1 User Plane]

[0077] The protocol stack between the base station and the UE includes the PDCP, RLC, MAC, and PHY layers. Within the user plane, packets are packaged within the core network using a specific EPC protocol and tunneled between the S-GW and base station, and between the P-GW and the UE. This protocol may, for example, be the IP protocol. [D.2 Control Plane]

[0078] The control plane includes each of the layers within the user plane, in addition to the Radio Resource Control (i.e., RRC) layer. The RRC layer is responsible for configuring and controlling the lower layers of the protocol (PDCP, RLC, and MAC layers). Unlike the user plane, the control plane handles air interface-specific functions between UEs and RANs in a cellular network. Base stations typically use RRC and scheduler algorithms that drive how the base station allocates RB, time slots, MCS, etc., for each UE under its control. Typically, these scheduler algorithms are only known from control traffic feedback from the PDCP layer to the RRC. These algorithms typically attempt to optimize throughput across a given base station cell.

[0079] Depending on the state of a particular UE, the cellular network may interact with the UE in a specific mode, such as idle mode or connected mode.

[0080] Idle mode is when a UE is instructed to "camp" on to a cell. The UE can camp on to a cell after selecting it. The UE selects a cell based on several factors, including radio link quality, cell status, and radio access technology. While camped on to a cell in idle mode, the UE may monitor the paging or control channel to detect incoming calls and obtain critical system information. In this mode, the control plane protocol includes procedures for cell selection and re-selection.

[0081] The connection mode is when the UE is actively moving traffic between itself and the cellular network (e.g., during a call or while an internet connection session is running). During this mode, the UE may report the quality of the downlink channel to the RAN (e.g., E-UTRAN) for information on the currently selected cell and neighboring cells. This allows the RAN to select the most appropriate cell for the UE to use. In this case, the control protocol includes the RLC protocol, which ultimately handles handover and mobile cell selectivity management on the mobile network side.

[0082] Figure 8 shows a typical cell search procedure that can be used when a mobile device is operating on and between networks. [D.3 Cell Synchronization and Selection Procedure]

[0083] Cell synchronization is the very first step when a UE wants to camp on any cell. From this, the UE obtains the physical cell ID (PCI), time slot, and frame synchronization. This allows the UE to potentially read system information blocks from a specific network.

[0084] A UE can adjust its radio waves by tuning to different frequency channels depending on which bands it supports. Assuming the UE is currently tuned to a particular band / channel, it first finds the Primary Synchronization Signal (PSS). The PSS is located within the last OFDM symbol of the first time slot of the first subframe (subframe 0) of the radio frame. This allows the UE to synchronize at a certain subframe level. The PSS is repeated in subframe 5. Since each subframe is 1 ms, this means the UE is synchronized on a 5 ms basis. From the PSS, the UE can also obtain physical layer identification information (0 to 2).

[0085] In the next stage, the UE finds the Secondary Synchronization Signal (SSS). The SSS symbol is located within the same subframe as the PSS, but within the symbol preceding the PSS. From the SSS, the UE can obtain the physical layer cell identification group number (0 to 167).

[0086] By using physical layer identification information and cell identification group numbers, the UE determines the PCI of its own cell. In LTE504, physical layer cell identification information (PCI) is allowed and divided into 168 unique cell layer identification information groups. Each group contains three physical layer identification information entries. As mentioned above, the UE detects physical layer identification information from the PSS and physical layer cell identification information groups from the SSS. Assuming that physical layer identification information = 1 and cell identification group = 2, the PCI of a given cell is PCI = 3 × (physical layer cell identification information group) + physical layer identification information = 3 × 2 + 1 = 7.

[0087] Once the UE (Unified Element) determines the PCI (Peripheral Interconnection) of a given cell, it also determines the location of the cell reference signal. The reference signal is used in channel estimation, cell selection / re-selection, and handover procedures.

[0088] As a result of PCI, the UE can identify the target base station from other base stations using the same spectral block deployment. This enables a single network frequency reuse scheme in most cases. After the cell synchronization procedure, the UE can proceed to read the Master Information Block (MIB) and System Information Block (SIB). The MIB and SIB are information blocks transmitted over the downlink control channel. These information blocks contain the information necessary for the UE to properly access the network via the air interface. [E. Cellular Network Wireless Access Technology (PHY)]

[0089] As explained, cellular networks use RANs to implement air or RF interfaces for connecting UEs on the network to the Internet or other networks. Assuming that the air interface link requirements and membership requirements are met, and that the UE has identified itself to the network in such a way that the network, or the services used by the network, determines that the UE is a member of an authoritative group, or otherwise has the authority to use the services provided by the network, then the protocols for communication between the UE and the RAN may be such that they are standardized so that any standard UE can communicate with any RAN. Air interfaces typically implement specific protocols, often referred to as specific radio access technologies (RATs).

[0090] Some exemplary RAT protocols include the GSM protocol, sometimes referred to as 2G or “second-generation” network protocols. Other examples include the GPR (General-Purpose Packet Radio Service) protocol, the EDGE (GSM Evolutionary High-Speed ​​Data Rate or EGPRS) protocol, the 3G (third-generation 3G UMTS standard developed by the 3GPP® organization) protocol, or the fourth-generation (4G) LTE Advanced protocol.

[0091] These protocols have rules regarding the use of spectral bandwidth, timing, coding, and conflict resolution. Because a base station may need to communicate with many UEs simultaneously, available radio paths are divided according to the protocol. A given protocol may have available radio paths that are divided by frequency, time, code, or more than one of these. This allows multiple users to share the same radio path. [F. RF Air Interface Link Budget]

[0092] The RF air interface between the UE and the RAN can drive the quality of the connection between the UE and the mobile network. As the signal quality of the RF air interface connection improves, the data rate at which this link can be maintained with a sufficient bit error rate also increases. The UE and base station can exchange information about the quality of the link connection using the control plane of the LTE protocol. Using this information, the base station can ensure that the bit error rate does not exceed a certain threshold by managing link conditions such as the modulation and coding scheme (MCS) and device transmission power. Depending on the type of service desired, the bit error rate threshold can vary anywhere between 10^-2 and 10^-8 or better. Applications such as SMS messaging, SMS broadcasting, or control channel signaling may operate at the highest bit error threshold, while applications such as high-definition video streaming may operate at the lowest bit error threshold. To maintain a specific bit error rate (BER), the base station may manage which modulation and coding scheme (MCS) is used for each UE with which it communicates via the air interface.

[0093] Each MCS provides a specific data rate via the air interface, but MCSs enabling higher data rates have different requirements regarding the quality of the RF signal received via the air interface. A waveform clearly represented via an air interface using a given modulation and coding scheme can have different bit error rates as a function of the signal-to-interference-to-noise ratio (SINR) of the target signal. SINR is a measure, expressed in dB, of the difference between the energy of the target signal and the combined energy of the noise and interference. Certain modulation schemes, such as QPSK, provide good bit error rates at low SINR levels. However, QPSK modulation uses only 2 bits per modulated symbol and a lower data rate than higher-order modulation schemes. Higher-order modulation schemes, such as 64QAM, provide good bit error rates only at very high SINR levels. However, 64QAM uses 6 bits per modulated symbol and a higher data rate compared to lower-order modulation schemes.

[0094] Higher-order modulation schemes utilize amplitude modulation in addition to phase modulation to increase the number of bits per symbol. However, this drives the requirement for more precise signal demodulation, resulting in increased signal energy required for adequate demodulation at a given bit error rate.

[0095] Table 4 illustrates how signal energy versus noise requirements can vary with modulation scheme and coding rate. [Table 4] [G. Other Considerations]

[0096] In terrestrial mobile communications networks, base station deployment drives network coverage area. In most cases, base station radio equipment is placed on towers to cover densely populated geographical areas where revenue can be generated. A typical tower hosting base station equipment can cost a certain amount to install and to operate as a function of each square mile it covers. Costs may include power, utilities, backhaul, maintenance, security, etc., and can vary as a function of site, area, etc. For a base station deployment to be worthwhile, it should generate at least more revenue per square mile than it costs to operate per square mile of coverage.

[0097] In rural and remote areas of the world, where population density is decreasing and therefore the potential revenue density for mobile network operators is also decreasing, base stations are often not deployed. To provide beneficial service to these remote and rural areas, it is necessary to spread the spectrum over a sufficient population. Base stations can be deployed on high-altitude platforms that operate in the air. However, these solutions are subject to technical challenges and are often subject to harsh atmospheric conditions that make platform control difficult and result in inefficient and inconsistent operation. In addition, high-altitude platforms still cannot provide a truly global coverage solution on their own because the cost of coverage of that magnitude would be prohibitively high. [Overview of the project]

[0098] This document describes how to operate a mobile network with orbital base stations that can be deployed for use in terrestrial systems as a mobile or cellular network. A typical terrestrial RAN and core network may consist of software, radio waves, modems, computers, racks, cables, servers, etc., deployed on top of or inside ground infrastructure such as buildings and towers. In a variation of the mobile network, the RAN and core network equipment / software is deployed on an orbital satellite, supported by ground equipment to interface with existing terrestrial RAN and core network counterparts as well as the internet. Placing specific network elements in LEO, MEO, or GEO orbits can facilitate appropriate networking links and deployments across strategic locations on Earth where specific ground infrastructure such as UE, G-MSC, and P-GW can operate, from home to space networks or other classic terrestrial networks.

[0099] Space networks can implement a series of extensions on a typical LTE architecture. Both EPC and E-UTRAN are extended with features used by the base station stack, MME stack, P-GW stack, and HSS stack, among others. The extensions of LTE, EPC, and E-UTRAN could enable a continuum of functionality for a standard LTE-Uu interface, so that a standard UE handset would be compatible with both terrestrial and space networks.

[0100] Furthermore, the embodiments can facilitate more optimal use of space-based cellular networks, particularly in phases where coverage is intermittent and non-continuous, by implementing extensions to the UE stack. These UE extensions can be fixed in the application layer of the user plane on the UE stack or in the non-access layer of the control plane on the UE stack.

[0101] In addition to extensions to EPC and E-UTRAN, further databases may be included to support extensions within the core network. These databases may be stored once or multiple times on the ground, in orbit, or both, and may support extensions to MME (with respect to position, velocity, attitude, IP connectivity, coverage area, etc.) that enable predictions of the future state of the network. This future state-space prediction function may be a function of known physics and network hardware characteristics and their operating constraints for determining the future inertial state vectors of the orbital network infrastructure. The inertial state vectors may be position, velocity, acceleration, attitude, and attitude rate. Other state vectors or matrices / tensors may be included, such as heat, power, inertia, or mass. The calculation of such vectors may be performed by the network management computer system, and the results may be distributed to base stations and UEs.

[0102] The network management computer system can calculate future state-space predictions of the network using assumptions about attitude and orbital control laws for the orbital infrastructure. This information may be stored in a database and may be spacecraft-specific depending on the capabilities of each orbiting satellite, the actuators it hosts onboard, and its intended on-orbit operation. Therefore, different spacecraft with different actuators, capabilities, designs, etc., may exist within the same network. Using gravity models, atmospheric models, and numerical integration schemes, the network management computer system can predict satellite trajectories in LEO with considerable accuracy for many hours, days, or even weeks into the future. The orbital network infrastructure may use its data to gain insights into future inertial state vectors to future network connectivity states, predict optimal future network operation, and coordinate in advance with ground network deployments. This may include radio resource control (RRC) functions for things like handovers, non-accessible layer (NAS) layer functions, network IP routing tables, mobility management functions, and signaling triggers / timers, etc.

[0103] Based on the inertial state vector for the entire orbital network, various network node connections may be possible. Each orbiting satellite may have a finite number of beams to allocate for communication with ground-based UEs, other satellites in the network, or ground-based ground station gateways. Depending on the number of available beams, as well as the relative positions, velocities, and attitudes of the nodes in the network, a set of connection scenarios may be generated for each individual point in time. A set of operating rules, constraints, and / or service requirements may be imposed as a filter to evaluate a set of connection scenarios to derive one or more of the most ideal ones, and thus generate an ideal concept of operation for network connectivity. This operation concept may include not only the orbital operation / maintenance process, but also a network map timeline showing what node connections are expected to exist for a certain period of time at some point in the future, and what the characteristics of those connections (e.g., latency, data rate, frequency, modulation scheme, coding, etc.) may be. The network processor may generate predicted routing tables based on the network map predictions and network node connections, and distribute these predicted routing tables as data structures to some or all of the nodes in the network. Given a database of their positions and velocities, the behavior in the MAC or PHY layer can be predicted based on the expected number of overpasses of the UE.

[0104] The services described from the orbiting mobile infrastructure may be deployed in cells around a planet, which are either dynamic (e.g., moving relative to the Earth's surface) or static (e.g., not moving). Technologies may be implemented to manage a database of points representing the locations of various target points within the network. For example, the locations of satellite base stations, ground base stations, satellite ground stations or gateways, UEs, a database of several mesh points on the ground, and a database of points representing the edges, centers, or both of geospatial polygons on Earth may be among the list of target points maintained in a central database. Link budgets may be modeled over time for links between satellites and these target points that use similar or the same frequencies to facilitate the optimal future use of spectrum, optimal coverage statistics, control transmissions from satellites, and coordinate the spectrum shared between the orbiting infrastructure and the ground infrastructure.

[0105] Since future link budget characteristics can be predicted at these various points, optimal network routes and paths can also be predicted in order to serve these points, specifically which satellites will be able to provide service at what point in time, and when handovers, if any, will be planned between two satellites to exchange control of service provision to specific locations on the ground. This will enable anticipation of core network signaling requirements and routing to optimize traffic flow.

[0106] State-space prediction functions can be embedded in space or ground-based hardware / software as extensions of classical functions from which typical ground-based cellular infrastructure such as MME, S-GW, P-GW, HSS, and PCRF take values. The results of the state-space prediction functions can be used to generate intelligence about the future state of the network. This intelligence can be distributed to each node in the network to inform future requirements regarding radio resource management, mobility management, tracking area management, load balancing between S-GWs, etc., which can be used to optimize the use of user planes and control planes used within the mobile network.

[0107] Space networks can implement RF interfaces similar to those specified by 3GPP standards for mobile protocols, such as GSM, LTE, EDGE, and CDMA, as described in Speidel I. Speidel I details how to handle Doppler shift and propagation delay associated with orbital links between satellites and devices such as UEs on the Earth's surface. By implementing this method, various types of space networks, where building infrastructure for mobile communication networks would be too costly or simply not beneficial, could solve connectivity challenges around planets in remote and local areas of the world.

[0108] The following detailed description, along with the attached drawings, will provide a better understanding of the nature and advantages of the present invention. [Brief explanation of the drawing]

[0109] Various embodiments of this disclosure can be described with reference to the figures.

[0110] [Figure 1] This is a diagram of a conventional LTE architecture.

[0111] [Figure 2]This shows the user plane interface between network elements in the LTE architecture.

[0112] [Figure 3] This shows the control plane interface between network elements in the LTE architecture.

[0113] [Figure 4] This document describes the authentication procedure for UEs on an LTE network.

[0114] [Figure 5] This document describes the Tracking Area Update (TAU) procedure for UEs on an LTE network.

[0115] [Figure 6] This document describes the handover procedures for UEs on an LTE network when base station handover is required and when S-GW handover is required.

[0116] [Figure 7] This shows the base station protocol stack architecture for existing base stations.

[0117] [Figure 8] This describes the process that the UE uses to search for and select cells that should be camped on.

[0118] [Figure 9] This document describes an extended LTE network architecture that may be used in conjunction with the embodiments of this disclosure.

[0119] [Figure 10] This demonstrates how space-based LTE network architecture nodes can manifest themselves to satellites and ground stations and interconnect through inter-satellite links (ISLs) and ground station links (GSLs) that operate as IP tunnels.

[0120] [Figure 11]This document describes components added to MME to extend it and enable MME to manage mobility between M coverage areas (and corresponding UE subscribers on Earth) described on Earth.

[0121] [Figure 12] This shows a historical network state space database.

[0122] [Figure 13] This demonstrates how a network of nodes can manage the infrastructure of various state-space configurations to produce unique position vectors, velocity vectors, acceleration vectors, and orientation state vectors.

[0123] [Figure 14] This shows a network model database.

[0124] [Figure 15] This demonstrates how the spacecraft coordinate system for beams used in inter-satellite links, ground station links, and base station links can be managed and stored.

[0125] [Figure 16] This shows the constellation location register.

[0126] [Figure 17] This shows the mesh points and polygons that can be used by the network state space predictor.

[0127] [Figure 18] This indicates satellites in orbit that provide coverage for static and dynamic base station polygons, separate from ground base station polygons.

[0128] [Figure 19] This shows the constellation policy database.

[0129] [Figure 20] This demonstrates a network state space prediction engine.

[0130] [Figure 21] This demonstrates how link budget geometry can be established between ground stations, satellites, other satellites, and UEs.

[0131] [Figure 22] This document outlines a procedure that may be used to determine the coverage provided by beamforming base station satellites within a network.

[0132] [Figure 23] This document outlines a procedure that may be used to determine the coverage provided by non-beamforming base station satellites (and the remaining beamforming base station satellites) within a space-based network.

[0133] [Figure 24] A simplified portion of the link state space matrix that can be generated to evaluate the link budget from the transmission satellite across the entire Earth mesh is shown.

[0134] [Figure 25] This demonstrates how spectral slicing between satellites and ground station cells within a space network can occur dynamically during satellite operation.

[0135] [Figure 26] This shows how the network can determine which ISLs and GSLs should be activated at each point in time.

[0136] [Figure 27] This document presents a simplified portion of the link state space matrix that describes the properties of link budgets between links (including ISLs and GSLs) within a network, along with hypothetical scenarios for how the network can generate links.

[0137] [Figure 28] Figure 27 shows how the network described by the link state space matrix can appear in inertia space.

[0138] [Figure 29] This describes a network state space database containing processes that are stored and distributed to network nodes to notify them of future actions.

[0139] [Figure 30] This shows an inter-satellite handover between base stations equipped with beamforming antennas.

[0140] [Figure 31] This shows an inter-satellite handover from a base station with a beamforming antenna to a base station with a non-beamforming antenna, and an inter-satellite handover returning to a base station with a beamforming antenna.

[0141] [Figure 32] This paper demonstrates how satellite base stations can implement modified forms of transmission power to avoid cross-border interference of spot beams based on regulatory requirements.

[0142] [Figure 33] This indicates an expanded base station. [Modes for carrying out the invention]

[0143] In the embodiments described herein, the space communications network operates to provide communications in conjunction with a terrestrial mobile cellular network. Similar to the terrestrial mobile cellular network, the space network operates RAN and core network functions as a complementary space component to the terrestrial network. As an extension or complement to the terrestrial network, the space component uses core network and RAN functions that enable proper authentication and handoff of mobile devices between the space mobile RAN and the terrestrial mobile RAN.

[0144] The following description will explain various embodiments. For the purpose of explanation, specific configurations and details will be described to provide a complete understanding of the embodiments. However, it will also be apparent to those skilled in the art that embodiments may be carried out without specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the embodiments described.

[0145] In rural and remote areas of the world, where population density is low and therefore the potential revenue density for mobile network operators is reduced, base stations are often not deployed. A space-based mobile communications platform can be a solution to eliminate the need for specialized client equipment by closing links to standard UE devices across large terrestrial zones. A standard Uu interface for space-based LTE networks can be used in conjunction with the disclosures described in Speidel I. Speidel I describes how base stations can be extended to accommodate the Doppler shift and propagation delay of the orbital link between the base station and the UE on the LTE-Uu interface by operating base stations, particularly eNBs. In doing so, space-based infrastructure can be used for telecommunications networks that support existing UEs using terrestrial mobile networks.

[0146] There are several challenges in operating base station space-based mobile networks and other classically terrestrial mobile network infrastructures. These challenges primarily stem from the need to use low Earth orbit for base station radio interface links within the network. One challenge is bringing the link between the transmitter and receiver close together. Closing the link involves transmitting the signal from the transmitter with sufficient power so that it traverses the distance between the transmitter and receiver and reaches the receiver at a distance with a sufficient signal energy level above the noise floor, so that the propagated signal can be successfully demodulated at the receiver with a sufficient bit error rate.

[0147] Depending on the desired data rate for the service connection between the orbiting base station and the UE, specific signal-to-noise ratio requirements may exist. The uplink budget can be driven primarily by the transmission power of the ground UE. For the LTE protocol, this may be 200mW (23dBm), and for the GSM protocol, it may be 2W (33dBm).

[0148] To close the link budget using a 200mW device on the Earth's surface, and to avoid excessive traffic influx into a single satellite cell / beam, satellites with base station transmitters / base station receivers can operate in low Earth orbit using directional antenna technology. Large antenna technology allows orbital base stations to reach altitudes of 1000km or similar. The use of sub-1GHz cellular spectra can be advantageous in terms of propagation characteristics and may be used in more favorable embodiments. However, smaller antenna arrays could allow several satellites to be located as low as 300km (if the orbit can be maintained by a thruster system onboard the spacecraft hosting the base station), reducing network costs.

[0149] Due to the need for low Earth orbit, achieving ubiquitous coverage of a planet with orbital base stations may involve thousands of satellites, which is still fewer than the number of ground base stations required for similar coverage. Nevertheless, fully deploying thousands of satellites can take some time, and in some embodiments envisioned herein, a satellite constellation operator may use an early-stage network design that can begin generating revenue and provide meaningful ground services, including smaller satellite populations that, while not providing continuous coverage across the entire planet, can provide intermittent base station overpasses across the planet. It may be advantageous to be able to create a first satellite population using a simpler design so that they can be developed inexpensively and deployed more quickly. For example, antenna selection may be an imminent design consideration for a satellite. One consideration may be a single antenna with a limited range that can only be directed based on the attitude of the spacecraft. This option may be simpler to design, develop, build, and test than alternative embodiments such as phased array antennas with beamforming capabilities, as the beam can be directed in any direction regardless of the spacecraft's attitude. If simpler antenna technology is used, each base station may have opportunities for rapid overpass / session (e.g., 2 minutes of connection every 30-60 minutes), depending on the elevation angle of the link budget.

[0150] In addition to antenna considerations, mass and power considerations may also exist. Initial use cases and markets may be deliberately selected to reduce power requirements for the initial satellite population. For example, intermittent cellular services for simple SMS messaging applications, among others, in remote IoT / M2M devices and mobile phones in a select number of countries worldwide may provide a relaxation of the spacecraft's technical requirements. For example, if the initial intermittent service is provided in countries such as Australia, New Zealand, and the Philippines, this may only require the satellite to transmit beams for 5-10% of its time in orbit. As a result, the highest power mode for the spacecraft's operation may be a 5-10% duty cycle. By serving low data-rate applications (e.g., SMS for relatively sparse users compared to densely populated urban areas for telecommunications services), orbiting base stations may only need to transmit over a single LTE resource block for data traffic, or even over a single 200kHz wide GSM carrier. The transmission power for each carrier may only need to be 20-30W. Power amplifiers for payloads may drive the spacecraft's power budget. By using readily available Class A or AB power amplifiers, efficiencies of 40-50% can be achieved at P1dB (the power output at which the amplifier's linearity drops by 1dB). As a result, the power consumption from the amplifier may be 75W or less at peak power. Therefore, the spacecraft's "payload" may have a peak power consumption of 100-125W (after power is allocated to radio, computer processing, etc.) and an orbital average power of 10-12.5W or less. This range of orbital average power is well-sized for a bus of the nanosatellite class, and the form factor may be several tens of centimeters in length, width, and depth (for example, a 6U nanosatellite would be approximately 20cm x 30cm x 10cm). A satellite of this size can sufficiently generate 50-60W of orbital average power from its deployed solar array and store that energy in a battery that can be discharged while high-power modes are required.

[0151] As additional use cases and service areas are added to the service set / product line for the base station orbiting constellation, larger, more powerful, and capable expanded spacecraft may be placed in place to serve a wider spectrum, more users, higher data rates, and more applications, etc. These expanded spacecraft may coexist with the initial, more limited group of spacecraft that may remain commercially viable. In some embodiments, the base station constellation may comprise different spacecraft. The different capabilities and services they can serve (and perhaps any time-based or specific country) may simply be sized to provide coverage for limited time-based volumes, taking operational constraints into account.

[0152] Another consequence of operation in low Earth orbit is that cells are small relative to Earth (and therefore require many satellites) but considerably larger relative to ground-based cellular networks. A typical ground cell may have a radius of 20-30 km or less, while orbiting satellites may have beam radii exceeding 300 km. As a result, hundreds of base station cells can exist on the ground that can operate simultaneously with orbiting base stations. In a scenario where the spectrum is allocated solely to the space network, this does not present any challenges, because interference is prevented by the different frequency bands between the space network and the ground network. However, there may be several embodiments in which the space network functions as an extension of an existing ground network, using a similar or the same spectrum. This can be preferable in some cases where there are financial and business difficulties in acquiring a dedicated spectrum for telecommunications services. Using sublicensing of a spectrum owned and operated by an existing ground network operator may be simpler. This embodiment may employ several spectrum management techniques in addition to those used by existing cellular networks to eliminate potential inter-cell interference.

[0153] However, alternative embodiments may exist for sharing spectrum between space base stations and ground base stations, which do not involve dynamic modification of existing ground networks, and embodiments that do not use extensions of existing MNO network infrastructure. As the satellite moves relative to the ground network, this management technique may have a temporal characteristic in which the deployment of the spectrum is dynamically managed over time.

[0154] For satellites providing coverage to the UE while moving in low Earth orbit, they move considerably faster (~7-7.8 km / s) than ground-based UEs. As a result, the network infrastructure can be considered effectively mobile, while ground-based UEs can be considered static (even if they are moving slowly). From the perspective of space networks, the movement of a UE in a given minute, hour, or even day is relatively insignificant in terms of when and what kind of coverage a satellite might be providing at a given time, provided the satellite does not already have coverage from ground cells. This characteristic can be advantageously utilized in several networking solutions.

[0155] This disclosure describes embodiments for managing a set of orbital infrastructure hosting base station, S-GW, MME, and / or P-GW functions. While the dynamic movement of orbital constellations complicates mobility management, the predictability of orbital dynamics can be leveraged to inform the network of future state spaces, and as a result, the operation of the control plane can be informed / anticipated for many functions, if there are more unique requirements. At the network level, understanding latency, routing, and ideal coverage patterns / operations is a far more complex computation because these are typically static or constant in terrestrial mobile network deployments. Network IP traffic routing may be dynamic and may intermittently connect and disconnect as the orbital and terrestrial infrastructures move relative to each other.

[0156] In addition to mobility management challenges, base stations also face RAN deployment challenges. Apart from the typical challenges faced by ground RAN deployments, the movement of each satellite inherently means that each satellite may be covering every point on Earth at any given time. As a result, base stations can operate as extensions of different ground networks at different points in orbit. Specific frequencies may be licensed differently around the Earth, and MCC, MNC, master information block, and system information block may be modified. Specific technologies used (2G, 4G, etc.) may also be modified. Consequently, there may also be records of these requirements and controllers to dynamically reconfigure base station settings to correspond to specific locations where the base station is providing service.

[0157] Other challenges related to networking signaling latency arise for space-based telecommunications networks, such as the fact that any given satellite or available radio interface may become available just minutes before a user leaves, and another different air interface may become available.

[0158] A good example is the challenge of authentication. Any device attempting to connect to a network would ideally want to authenticate to the network within a timeframe shorter than satellite overpath time. Otherwise, the device may never be able to authenticate to the network. Typically, authentication on a roaming network, or on a network operating far from a home network authentication database (such as a network in space), can take a time that exceeds the amount of satellite overpath time. While networks can be designed to increase overpath time, when considering networks of orbiting telecommunications infrastructure, it becomes crucial to enable rapid authentication procedures or accommodate slow authentication.

[0159] Another example could be the interaction between a space network (as a roaming provider) and a terrestrial network (as a home network). As satellites orbit every few minutes, the network may need to manage how each satellite's tracking area code is transmitted, because UEs may automatically update their position each time they undergo a TAC change or are serviced by a different VLR / MME. This could necessitate HSS updates on the home network, and if all users need to update their positions every few minutes, and the number of users on the global network represents the typical total number of telecommunications subscribers across most of the world (hundreds of millions or possibly billions of subscribers), this can result in substantial network overhead.

[0160] Ultimately, the handover of telecommunications traffic can be complex within space-based telecommunications networks. Since each satellite may only have an overpass over a given area for a few minutes to ten minutes, depending on the deployed orbit and antenna, permanent handover signaling may be required within the satellite network to allow each satellite to adapt to changes in coverage. In addition to handovers between UEs, challenges may arise with handovers within inter-satellite links based on changes in satellite positional states and therefore variations in network latency, as well as routes from orbital infrastructure and ground infrastructure acting as gateways to terrestrial mobile networks, the internet, etc. These can be addressed using the methods and apparatus described herein. [Considerations / Concepts for Network Design]

[0161] Depending on the level of service required by the spacecraft cellular network to enable this, and the number of users it targets, the RF front-end of the space network RAN ​​can be designed with different configurations. For service applications related to devices such as IoT devices or M2M devices, where data rate requirements are low and devices can be sparsely distributed in remote areas, the EIRP requirements for the desired amount of service spectrum can be reduced. The amount of service spectrum can be driven by how many users the satellite network needs to serve. In particular, the spectrum needs to be sized to match the number of users simultaneously present in a single spot beam that needs to use the satellite network.

[0162] Satellite-based mobile networks can be configured / designed to work in conjunction with the underlying ground mobile network, and therefore to deploy only sufficient spectrum to fill gaps in the ground mobile network described herein. In this configuration, a small spectrum sliver may be allocated to the space network for coverage in low-population-density areas where coverage is still lacking, while the majority may be allocated to the ground network (which has smaller ground cells), allowing for more dense reuse of spectrum for coverage in high-population-density areas. Such configurations may be employed for services for inexpensively purchased remote cellular-based IoT devices (e.g., GSM-based or LTE-based). In IoT use cases, lower signal level requirements allow for lower EIRP at the satellite end of the link to close the downlink at the desired data rate. Lower EIRP allows for some reduction in the trade-off between satellite Tx power requirements and antenna size. Antenna size can drive other design factors in the network, such as antenna directivity and beamwidth, and therefore spot beam size. This also drives how often the spectrum can be reused by the space network. This is due to trading more satellites, or more spot beams per satellite providing coverage from orbit, in order to achieve ubiquitous and continuous coverage of the planet. Each satellite equipped with multiple spot beams provides coverage, referred to as the coverage area or coverage footprint, relative to the total area of ​​the Earth defined by the spot beams. [A.1 Determining the Optimal Number of Satellites]

[0163] A satellite network can be designed with multiple satellites, each having a coverage footprint, and multiple potential spot beams for each satellite. If the number of satellites is limited, coverage footprints will not overlap, and ground service can be intermittent. This can be useful for certain use cases in remote areas of the world where ground coverage does not exist. Depending on the satellite orbits and footprint sizes (and how the beams within the footprints are operated), coverage times of 1 to 15 minutes from a given satellite in the network can exist anywhere. Depending on the number of satellites and the number of orbits they are in, this level of connectivity can occur once every 12 hours, every 6 hours, every hour, every 30 minutes, every 10 minutes, every minute, etc. As more satellites are added to the network, the intermittence of connectivity can decrease.

[0164] As an example, Table 5 below can illustrate how the number of overpasses, connection time, and time between overpasses can be estimated as a function of the number of satellites. In this particular example, we analyze satellites in a circular orbit 503 km around the Earth, tilted 51.6 degrees relative to the equator. The satellites will be equally spaced around the Earth within three unique repeating ground trackings. In this analysis, satellite base stations are assumed to have a minimum elevation angle of approximately 45 degrees, representing the satellite footprint. The ranges of values ​​in each row and column in Table 5 can correspond to variations in service at and above the equator (or lower latitudes). In particular, in this case, better service numbers (more overpasses, longer connection times, and shorter intermittent intervals) correspond to all longitudes at approximately 51.6 degrees North or 51.6 degrees South latitude. The two worse numbers correspond to all longitudes relative to the equator. [Table 5] [A.2 Orbit configuration]

[0165] Space-based infrastructure can potentially be located in various different orbits, such as GEO, MEO, or LEO orbits. A GEO orbit may be circular and can operate at an altitude of approximately 35,786 km above the Earth's surface. Depending on the desired coverage dynamics of Earth or other orbiting spacecraft below it, a GEO orbit may be located on the equator and may be inclined. An MEO orbit may also be circular and may be inclined several times relative to the equator at altitudes between the upper edge of an LEO (approximately 2,000 km altitude) and the upper edge of a GEO (approximately 35,000 km altitude). An LEO orbit may also be inclined depending on coverage requirements and can operate at altitudes between approximately 250 km and 2,000 km. Below an altitude of 450 km, atmospheric drag is a significant factor in spacecraft thrust requirements.

[0166] Generally, the inclination angle corresponds to the desired latitude coverage. A polar (90-degree inclination) orbit can provide coverage to all longitudes between 90 degrees north and south latitude (e.g., the entire planet). A moderately inclined orbit, such as the inclination of the International Space Station (51.6 degrees), provides coverage to all longitudes between 51.6 degrees north and south latitude (plus the angular radius or "half-Earth angle" of its coverage footprint). An equatorial orbit provides coverage to all longitudes between 1 / 2 of the Earth angle of the coverage footprint in degrees of north and south latitude.

[0167] Very eccentric orbits can be used to provide iterative but extended coverage of specific regions or lower orbits within a network. Very eccentric orbits provide slower velocity in the higher altitude portions of the orbit (providing extended or longer-lasting coverage) and faster velocity in the lower altitude portions of the orbit. The position of the higher altitude portion of the Earth in an eccentric orbit may move relative to the Earth or the desired coverage area. Very eccentric orbits are affected by the precession of the perigee argument. However, this secular precession disappears when the orbit is tilted only 63.4 degrees from the equator. Such orbits are often known as Molniya orbits and can be used to cover specific regions on Earth or to fix orbital residence times in lower orbits (such as LEOs).

[0168] In a constellation where GEO, MEO, and LEO, or some combination thereof, host various network elements through ISLs and ground stations for a space network that serve the same UE subscriber pool and communicate with the ground network while providing mobility management, various orbits may be used. [A.3 Phases / Styles of Space Network Deployment]

[0169] Space-based RANs can be deployed as their own networks with their own spectral assets. This makes the deployment of their RAN frequency licenses relatively simple, especially when using a small number of satellites.

[0170] Alternatively, space-based RANs could be deployed as a global shared roaming network with a sublicense for the use of existing terrestrial MNO spectra, in agreement with the MNO. In this case, when spectra are not strictly allocated to the space component, the deployment of spectra may require dynamic coordination with the terrestrial MNO network. This may be undesirable in the case of intermittent constellations where coverage from the space component may only be available by LEO base stations every few minutes, e.g., every 15, 30, 60, 120, or 360 minutes.

[0171] During times when the space network is not operational, the ground network may be able to utilize the spectrum, but otherwise, it will be operational while above orbit. As a result, it is sometimes desirable to know when a particular satellite is on and can provide coverage that overlaps with existing ground cells in the lower network.

[0172] In addition to the advancements in phase alignment of base station constellations described herein, novel methods may be employed to calculate the ideal operating procedure / process for a satellite network that may include satellite base stations without beamforming antennas and satellite base stations with beamforming antennas. Satellites are typically constrained to comply with requirements imposed by ground regulations and to avoid interference with each other and with other ground cells. Furthermore, each satellite in a constellation (or perhaps even further, a selection of satellites "group" or "production operation") may have different technical capabilities. Examples may include maximum power consumption requirements, orbit-averaged power intake, battery capacity, the spectral bandwidth it can deploy, payload / base station duty cycle requirements, thrust, attitude control, memory, processing power, etc.

[0173] Variations in technical capabilities among spacecraft within a shared communication network can be handled using these technologies. This can be useful when a constellation is in the construction phase. Launching a constellation of thousands of satellites can take several years, during which time developing small groups of satellites and providing initial services for specific use cases can be a revenue-generating venture. Specific examples may include IoT / M2M use cases that benefit from intermittent and inconsistent connectivity in remote areas. Other use cases for intermittent services could include storing and forwarding messages from a handset via SMS.

[0174] In early use cases, fewer and less capable satellites may be desirable because this can reduce the cost of investment. A beamforming array, which can be time-consuming and expensive to develop effectively, might be one such example. As a result, the initial constellation, consisting of 12 or 24 non-beamforming satellites, could be deployed to the LEO for initial service. While new satellites may be developed and launched over time, older designs may continue to operate. Design considerations may be incorporated to ensure software compatibility (or upgradeability) for the initial new satellites, ensuring their software can operate symbiotically.

[0175] As new satellites are introduced and decommissioned in stages over time, their capabilities can be individually recorded in a database utilized and described later in this disclosure. This information is added and updated so that the calculations performed as described herein can adapt to changes in operation. [A.4 Examples of Network Architectures]

[0176] Space networks have a similar structure to terrestrial LTE networks, but with several extensions, and may use an architecture that primarily incorporates additional internal elements of EPC and E-UTRAN. These extensions enable optimal functionality for space-based cellular networks, while maintaining the ability to communicate with standard terrestrial networks on Earth without necessarily requiring any modifications. However, there may be embodiments, for example, in which terrestrial mobile networks are also extended to be compatible with more sophisticated spectrum-sharing technologies, similar to space-based networks. Furthermore, in another embodiment, extended UEs may exist where end-user handsets are modified with space-based cellular network extensions in mind. For example, they may be provided through EPC (either terrestrial or space). Using a control plane or user plane (e.g., handset application), the predictable overpass opportunities by the space network can be advantageous for optimizing network scanning procedures to facilitate connectivity to the space network, provided the UE is aware of its potential availability.

[0177] An extension of the network architecture in one embodiment may include MMEs, base stations, HSSs, and possibly UEs. The space network architecture in this embodiment may include additional elements that directly affect, or are affected by, the operation of network nodes within the space-based infrastructure. These additional elements may include a network database (NetDB), network telemetry, tracking, control, command, and data processing (TTCC&DH) functions, and spacecraft flight software systems. These additional elements within the space network may interface with the extended MME. This interface connection may be done in software.

[0178] A space network can operate as a set of distributed infrastructure components on satellites and ground stations orbiting the Earth. Each spacecraft may host a flight computer or a set of computers that can interface to network switches accessible to the intersatellite link radio on the satellite and the ground station radio, if available. Each flight computer may be assigned to a specific network node function (e.g., extended MME, S-GW, P-GW, etc.), or a single flight computer may use those functions as a single package, a “network inbox.” A single computer may operate hypothetical examples such as base stations (possibly multiple base stations), extended MME, extended HSS, S-GW, P-GW, etc. Another computer may host TTCC&DH software and flight software for functions such as guide, navigation, and control (GNC), etc.

[0179] The LTE architecture extensions described herein may be implemented as software running on several nodes of the network, and in particular, as APIs or software libraries. This may involve the use of existing manufactured / commercial-quality LTE stack software. Instead of directly modifying well-tested existing manufactured code, the extension may operate within a separate software application, software library, or code repository that can be used to implement the desired extension by configuring, controlling, or communicating with an existing interface to the manufactured LTE stack implementation. Thus, while this disclosure describes extensions to LTE stack nodes, it should be understood that this may be done using several existing components or entirely new components. Some implementations may not require literal modification of each software node or function within the existing LTE stack. This also applies to any 3GPP stack (e.g., 2G GSM / GPR, 3G CDMA / UMTS, etc.).

[0180] The network could operate as an IPv6 network, enabling static IP addresses for each computer on each satellite and ground station within the network. Intersatellite links (ISLs) and ground station links (GSLs) could operate as continuously linked IP tunnels between the physical infrastructure in orbit and the physical infrastructure on the ground. On the ground, an example of a telecommunications network inbox would interface with the Internet and other telecommunications networks via IPv4 / IPv6.

[0181] Each ISL and each GSL tunnel may, in practice, have multiple bearers. One or more of these may be dedicated to network control plane traffic, network user plane traffic, flight computer telemetry, tracking, command, etc. Bearers may be established in a priority-weighted manner and may be given available bandwidth so that any data rate link can be established for the air interface. As a satellite orbit around the Earth, moving relative to ground stations and other satellites in the network, the tunnel can be handed over between re-established nodes and bearers. Each spacecraft may have some memory buffer to accommodate incomplete handovers in gaps in the complete tunnel connection to a Serving Access Point Name (APN) to the Internet, for example.

[0182] Figure 9 shows an exemplary network architecture. The extended LTE network 902 may operate a set of functional nodes that maintain compatibility with the standard terrestrial network 904 and the standard terrestrial network UE924. The extended network may operate an extended E-UTRAN 914 with an extended base station 926. The extended EPC 906 may host elements similar to a terrestrial EPC, but may use an extended MME 916, an extended HSS 910, a state-space database (SSDB) 928, an extended S-GW 932, an extended P-GW 934, a PCRF 936, a TTCC&DH system 918, and spacecraft flight software 908. The extended EPC may maintain its own connection to the PDN server 938, which may differ from the connection that a standard EPC has to the PDN server 930. The extended MME may maintain an S6a connection to a standard HSS 920 within the home terrestrial network. The extended S-GW will maintain a standard S8 interface with the standard P-GW940, which can manage a standard interface with the home network PCRF database 922. The extended UE912 can also be used within the network.

[0183] Figure 10 shows a space network architecture relating to hardware. The hardware may be hosting the space network architecture. Satellites 1012 and 1014 and a ground station 1016 may exist in the network. The satellites may be connected to each other through ISL 1002, which in one embodiment may be an IPv6 bearer tunnel. These tunnels may be allocated specific bandwidths that are divided across bearers for different functions. There may be bearers in each inter-satellite link tunnel for each interface, which would otherwise be handled within a conventional ground network. In particular, there may be bearers for the network control plane 1006 (equipped with X2-CP, S11, S10, S6a, S5, and further control interfaces, etc.), the network user plane 1008 (equipped with X2-UP, S1-UP, S5, and further control interfaces, etc.), and the TTCC&DH plane 1010 (equipped with one or more network interfaces). The satellites may be connected to the ground station through GSL 1004.

[0184] These GSLs may be IPv6 bearer tunnels and may be divided by bearers for specific network planes. Each satellite is equipped with radio and other equipment to generate connections and establish these tunnels. The ISL radio 1018 and GSL radio 1044 are used to communicate with other satellites and ground stations, respectively, and to implement the PHY protocol or L1 protocol for the ISL and GSL. Each satellite may include other computers, such as a network computer 1022 or a flight computer 1038, running software that implements specific functions. For example, the network computer may implement a state-space database 1024, an extended HSS database 1026, extended S-GW and P-GW 1028, an extended MME 1030, and an extended base station 1032. The extended base station 1032 will implement the PHY for the LTE-Uu interface link 1034 and control radio waves compatible with the existing standard UE 1036. The flight computer may implement TTCC&DH functions 1040 and flight software 1042 to control various subsystems hosted on the spacecraft (e.g., attitude control, thruster control, actuator control, power system control, thermal control, etc.). Each computer in the space segment satellite may interface with a network switch 1020, which in one embodiment may be an IPv6 switch. Ground stations may implement network computers and flight computers that do not natively provide base station functions and, in some cases, do not host the entire flight software package hosted on the spacecraft. In some embodiments, ground stations may implement flight software. [A.5 Satellite platform for hosting mobile network infrastructure]

[0185] The orbiting spacecraft providing the infrastructure for the mobile network described may comprise several structures housing electronics such as computers, radio waves, processors, memory, wires, cables, and actuators. The spacecraft may use an onboard computer for processing and memory, running on an operating system. The operating system may host software programs intended to operate various functions on the satellite. One of these software programs may be a virtualized telecommunications software stack (for implementing the RAN and / or core network) that controls the radio interface connected to the computer. The operating system may also host software that collects telemetry and data from sensors or calculated in the software, and simultaneously controls a command and data processing system on the spacecraft that processes commands either autonomously based on an internal feedback control loop (or an external feedback control loop that may be operated on the ground) or manually from a ground control center. The spacecraft software may be used to control actuators that manage its attitude (reaction wheels, magnetic torque, etc.) and actuators that manage its velocity / trajectory in orbit (e.g., thrusters). Actuators may also be used to extend or retract deployable structures on the spacecraft.

[0186] The spacecraft may have solar panels. These panels collect solar power to charge batteries and distribute the energy needed for various components within the spacecraft that the spacecraft needs to operate. The spacecraft may have a processor that runs software to monitor and track various telemetry readings and store them in memory. These telemetry readings may include position, velocity, acceleration, orientation, battery capacity, power from arrays, mass, fuel mass, inertia matrix, component health / telemetry readings, etc.

[0187] A spacecraft may host an onboard GPS receiver to track and calculate its velocity, position, and acceleration. If GPS is unavailable (e.g., when satellites are over GEO or, in some cases, too high over MEO), other techniques may be implemented to provide the spacecraft's internal computer with position and velocity data, such as signal ranging and Doppler measurements at a known ground station at a specific location. Onboard sensors such as star trackers, IMUs, cameras, horizontal sensors, and gyroscopes may be used to calculate the spacecraft's orientation in a given coordinate system, such as Earth-centered inertia. Additionally, these onboard sensors may be able to calculate the spacecraft's angular velocity as it rotates within inertial space.

[0188] The spacecraft may be equipped with a control system that can be programmed to perform specific pointing-related tasks, such as rotation, maintaining inertia (e.g., maintaining a constant orientation in inertial space), and maintaining nadir / zenith pointing. Additionally, this control system may implement orbital position and maintenance control, possibly based on the output of a state-space prediction engine to determine the optimal operation during flight. This control system may implement a Kalman filter to improve state measurement and may perform specific operations over specific periods based on a control method, such as that implemented by a PID controller.

[0189] A spacecraft has its Poynting vector in the spacecraft's coordinate system.

number

number

[0190] A spacecraft platform may have numerous systems where the operator may wish to store telemetry or health data. Spacecraft telemetry may be stored as precise measurements of the spacecraft, such as voltage measurements, current measurements, temperature readings, power indicators, battery charge, solar power intake, power consumption, operating mode, and software application status. Telemetry from the spacecraft may be processed to determine the satellite's functionality and any operational constraints resulting from failures. In particular, a satellite or ground system may use telemetry intelligence to negate or hinder the spacecraft's ability to generate connections with other satellites, ground gateways, or UEs. This can be used to generate logic that automatically toggles node connection opportunities on and off in a network state prediction engine based on telemetry downlinks from the satellite. [B. Extended Mobility Management Entity (MME)]

[0191] In a cellular network, a coverage area where UEs can expect to connect to the cellular network infrastructure may be a coverage area divided into cells, some of which overlap with other cells and coverage areas, and in some cases enclose some areas that have no cell coverage at all. Typically, a cell within a coverage area may be considered static if the cell's coverage stems from the presence of a fixed tower or fixed transceiver with fixed location and fixed capacity. Such transceivers are typically placed where coverage is expected and / or where it is cost-effective to assume that a large number of UEs are expected to be present within those cells.

[0192] In a radio network serviced by orbital stations, the coverage area can be expected to change over short periods of time as satellites closer to the Earth's surface than GEOs move relative to the surface. The differing characteristics of ground-based cellular network nodes and orbital-based cellular network nodes are not a concern if they use separate protocols and communication standards, as the two networks can coexist by avoiding interference overlap through the use of different frequency bands, different coding, etc. However, if ground-based and orbital network nodes use the same protocols and communication standards as the UEs use to close links with ground network nodes, coordination and coexistence become partially more complex due to the movement of the orbital network nodes. As described herein, this can be resolved through coordination between network nodes.

[0193] A coverage area for an air network, which provides radio coverage for UEs located within that coverage area, may be logically represented by a plurality of polygons. While references are made to polygons, it should be understood that the methods and apparatus described herein will work equally well with closed shapes that are not strictly polygons, such as ellipses, circles, and irregular shapes having some curved boundaries and some straight boundaries. In some examples, some polygons of a coverage area correspond to terrestrial cellular network cells. Covering a coverage area or at least a portion of a coverage area with polygons may be a function of anticipated use, applicable jurisdiction for specific polygons (e.g., polygons covering a portion of a particular country, polygons covering the open ocean where there is no legal jurisdiction itself, etc.), and / or feasibility of coverage.

[0194] In some embodiments, a coverage area is first characterized by a set of mesh points, which are aggregated into a polygon. In other embodiments, however, a polygon is defined without necessarily referring to mesh points. In a database representing a set of polygons, the polygon-based record may include details about the polygon's boundaries, the applicable legal jurisdiction within the polygon, the protocols and standards used to establish wireless links within that polygon, and other information about the polygon. The mesh may consist of a grid or some other method that virtually represents the Earth or a finite element model of a set of polygons. The coverage database may consist of mesh points and polygon coverage areas. A polygon coverage area is referenced in the coverage database for each base station, and each base station includes at least some static coverage ground base stations, at least some static coverage orbital base stations using beamforming, and at least some dynamic coverage orbital base stations that use dynamic beams that move across the coverage area as at least some dynamic coverage orbital base stations move along their respective orbits.

[0195] If a coverage area is supported by both ground network nodes and orbital network nodes, these nodes may be coordinated. In an example, a ground network node is a transceiver that is part of a cellular network broadcast tower, and an orbital network node is a transceiver that is part of a satellite. A tower may support multiple nodes, and a satellite may support multiple nodes. Coordination may be performed by a mobility management entity. A mobility management entity may take the form of a computer system that runs software and has communication channels that enable the mobility management entity to retrieve information from nodes and transmit information to nodes. In one approach, the mobility management entity (MME) can compute a set of polygons for a coverage area over a specific period of time, and can do so before that period. This allows sufficient time for the details of the set of polygons to be propagated to nodes that will use the information before they need it.

[0196] A set of polygons may be calculated according to the processes described elsewhere in this specification, but may take into account the predicted state of the nodes on the satellite (e.g., position, power, orientation, and whether the nodes can maintain a constant beam within the coverage area as the nodes themselves move through space). As nodes move as described herein, a set of polygons may change, and the nodes assigned to cover the link needs within a particular polygon may also change. If a first node is assigned to cover the link needs within a polygon, and a second node is not assigned in the same way, but the second node can transmit using the same protocols, channels, and standards as the first node, the second node may be programmed to postpone and not use those protocols, channels, and standards during the period when the first node is assigned to cover those link needs.

[0197] A node may be scheduled to operate in a set of polygons and other data available to the MME, taking into account a certain period within a time-division multiplexed frame, a certain frequency channel, a certain time slot, etc. If a node is an orbital node (and possibly a ground node as well), it may be scheduled to be inactive for a certain period of time, based on the power available to the node or its lack thereof, the heat generated at the node, and other considerations that take into account the operational status of the node available for the coverage area.

[0198] Some orbital nodes may have beamforming antennas that allow a beam to remain over a certain area of ​​the Earth's surface for a period of time. Other orbital nodes, on the other hand, may be limited to beams that are constant relative to the satellite. Thus, the beam moves over the Earth's surface rather than remaining over a certain area. If an orbital node's beam covers or approaches the coverage of a particular polygon, the orbital node may be assigned to handle the linking needs of UEs within that particular polygon, but any ground nodes that can reach that particular polygon are instructed to defer and not use the air resources used by the orbital node. In addition to completing the deferral, some coordination may be made between nodes so that adjacent nodes with overlapping coverage operate simultaneously but on separate frequencies, codes, time slots, etc., so that they do not interfere with each other in a completely destructive manner.

[0199] By having the MME acquire state information, calculate assignments, and pre-communicate those assignments, the cellular network can operate efficiently even when some of the network nodes are in orbit, overlapping with ground nodes, while some of the ground nodes are moving rapidly relative to ground nodes, some of which may be much closer to the UE than the orbital nodes. In some cases, for example, there may be several moving ground nodes, such as drones or balloons, but these can be treated as stationary relative to the orbital nodes.

[0200] More specific extensions to MME are described here.

[0201] To generate actionable intelligence regarding the future state of the network, the MME extension includes a state-space prediction engine that uses a set of databases to inform virtual simulations of orbital dynamics, as well as satellite navigation, guidance, and control, payload behavior, RF link budgets between separate network nodes, etc. This actionable intelligence can be inferred from simulations and packaged into something like commands stored on a time basis. These commands can trigger or initiate network signaling events within the MME, base stations, or even within the UE. This can optimize network routing, network node connectivity, network infrastructure power consumption, spectral resource allocation, base station operation, spacecraft operation, etc. Desired optimization algorithms can be stored as a database. This database can be changeable over time and may be readable and writable so that it can be accessed and reconfigured (e.g., by the NOC) in response to external changes / impacts such as emergencies / disasters.

[0202] MME extensions can take the form of peripheral applications running on the same computer as MME, or possibly on a separate processor. The extensions utilize four, possibly separate, databases. These databases may be notified by NOC or TTCC&DH systems within the space network.

[0203] The Historical Network State Space (HNSS) database may contain historical data including satellite position, velocity, attitude, attitude rate, network operation / state, and network log files. The HNSS database is notified by the TTCC&DH system when a satellite downlinks its telemetry data or when satellite telemetry data is collected.

[0204] The Network Model (NM) database may contain data characterizing the environment to be simulated and the operational capabilities / characteristics of each satellite in the network. When satellites are added to the network, or when satellites malfunction or fail, anomaly telemetry from the NOC or TTCC&DH system may change the status of each spacecraft's operational characteristics.

[0205] The Constellation Location Register (CLR) database is a space-based correspondence with HLR features, storing location information for UEs and network-related target points. UE location information can be updated by recorded tracking data for each UE. Tracking data is stored for transmission to both the CLR and HSS. The NOC can update, delete, or add target points related to network operation.

[0206] The Constellation Policy and Rules (CPR) database stores information about flight behavior rules for network space hardware, as well as policies and QoS requirements for related virtual target points for the network. The CPR can be updated by the NOC (Network Operations Center).

[0207] These four databases contain information used by the network state-space prediction engine. The network state-space prediction engine accurately simulates and predicts the state of space-based networks in the future using orbital dynamics processing, spacecraft attitude dynamics / control processing, and link budget / RF system processing. The network state-space prediction engine can leverage several optimization processes to optimize network behavior based on policies, rules, etc., within the databases.

[0208] The network state-space prediction engine can generate a set of paths for various elements within the space network. In one embodiment, there may be three distinct sets of paths. One may be spacecraft paths intended for use by flight software within the space network. Another may be core network paths intended for distribution to extended MME functions within each satellite. Finally, there may be RAN paths intended for use by base stations within the satellite network. Since each spacecraft is an EPC and / or base station host, these paths can be packaged into a common database called a state-space (SS) database. This database can be distributed across the entire network for use by each spacecraft.

[0209] Figure 11 shows a flowchart illustrating the procedures that may be implemented as further features used by the extended MME. The extended MME can manage mobility using a process that predicts the future state space of the network. To do this, the extended MME may utilize four databases: a historical network state space database 1102, a network model database 1104, a constellation location register 1106, and a constellation policy and rule database 1108. These MMEs may receive information from either the TTCC&DH system or the NOC and store that information in their databases. These MMEs may supply information to the network state space prediction engine 1110. The network state space prediction engine 1110 will analyze possible network connectivity scenarios (for base stations, ISLs, GSLs, etc.) using orbital mechanics and attitude dynamics, as well as link budget prediction software. From this analysis, the network state space prediction engine will generate journeys, namely the spacecraft journey 1112, the E-UTRAN journey 1114, and the EPC journey 1116. These processes may include relevant information on how to manage / operate them in the TTCC&DH control plane, EPC control plane, and E-UTRAN control plane (e.g., time-based control plane signaling commands). These processes may be combined into a single common state-space database 1118, which will be built to support the extended MME, because it will include network operation information for space-based infrastructure for some time in the future. [B.1 Historical Network State Space (HNSS) Database]

[0210] Figure 12 shows an example of a historical network state-space database 1202. The database 1202 may include recorded positions 1204 of network satellites, recorded velocities 1206 of network satellites, recorded attitudes / orientations 1208 of network satellites, recorded attitude rates 1210 of network satellites, recorded network state-space data 1212, and recorded network log files 1214. [B2. Database of location and speed of base stations, UEs, and GSs]

[0211] Figure 13 illustrates various platform scenarios within a network that may be tracked and whose state spaces may be stored. An orbiting base station 1302 may orbit the Earth at an orbital altitude 1324 using a communication system (e.g., antenna and RF frontend) that can close a communication link to a standard UE 1330 utilizing certain 3GPP protocols such as GSM, EDGE, CDMA, and LTE. The orbiting base station may maintain connectivity to the ground via a ground station IP switch 1328 for access to the Internet and other MNO provider networks. The orbiting base station is located

number

number

number

number

[0212] A network computer or orbiting base station may maintain a representation of the position of an orbiting object in inertial space, which may be represented as a 3x1 vector to represent the satellite's position in a three-dimensional coordinate system, as shown in Equation 1.

number

[0213] A network computer or orbiting base station may maintain a display of the orbiting object's velocity, and acceleration may be stored in a manner similar to that shown in Equations 2 and 3.

number

number

[0214] Various components can store information such as position, velocity, and acceleration. One method of storage is to store the orientation of a rigid body in a three-dimensional coordinate system. One representation uses Euler angles, which are three angles stored as a 3x1 vector representing rotations in degrees around three axes represented in a rotating or fixed reference coordinate system. Another representation uses roll, pitch, and yaw (often expressed as z-y'-x'' rotation) representing the rotation around the z axis in the aircraft coordinate system, then the y axis and finally the x axis in the aircraft coordinate system. Another representation uses nutation, precession, and spin representing rotations around the z axis, then the x axis, and then again around the z axis (zxz) in the fixed coordinate system. Yet another representation stores orientation or attitude information as a quaternion, which is a 4x1 vector representing the axis of rotation and angles. The orientation vector of an orbiting object stored as Euler angles can take the form shown in Equation 4.

number

[0215] An orbiting object can typically host an attitude determination and control system (ADCS) that determines its orientation in three-dimensional space and can then control it (using actuators to provide torque to the spacecraft's rigid body). Using this system, attitude reorientation operations may be planned, and the base station's angular velocity

number

[0216] An orbiting base station may provide coverage to a ground-based UE within a coverage footprint of 1326. This coverage footprint may include single or multiple spot beams utilizing technologies such as multiple apertures and phased arrays to provide sufficient RF coverage.

[0217] Below the orbiting base station, there may be other base stations operating on drone 1308, balloon 1306, or tower 1304, each having a position, velocity, acceleration, and orientation in inertial space or possibly in an Earth-fixed coordinate system. Similar to the orbiting base station, these would also have a coverage footprint, likely including a coverage area generated by multiple antennas or arrays. In addition to the base stations, there may also be UE 1330s, each having a position, velocity, acceleration, and orientation in a coordinate system.

[0218] Since the position and velocity of each base station are known, calculations can be performed for vectors that define the relative position and velocity of each base station in the network. Similarly, knowing the position and velocity of each UE makes it possible to calculate vectors that represent the relative position and relative velocity of the UE with respect to the orbiting base station. For example, these vectors representing the relationship between the orbiting eNB and the UE could be relative position 1318, relative velocity 1320, and relative acceleration 1322.

[0219] In current cellular architectures, the GPS position of a transmitter tower is often recorded and stored so that a specific position result based on a known coordinate system can be generated through relative positioning via triangulation. The UE's position is tracked at some network level, but is less precise than the network position code and network position ID that identify a specific serving tower, serving transmitter, or serving base station. Tracking may be limited to the serving MME only, in which case only a specific region or area covered by any base station under the control of that MME may be specified. As a result, a typical ground network has no knowledge of the UE's position and velocity via the RF air interface and control plane. Some applications may log GPS position and enable backend tracking via a server. However, in these scenarios, tracking is only possible if the user has a connection to the appropriate IP server tracking GPS readings about the device.

[0220] As described in Speidel I, the proposed orbital mobile network can maintain a database of state vectors that can be stored accurately, measuring position and velocity with sufficient precision, and which can be used for mobility management, by implementing air interface measurements based on RF signals from UEs on RACH (e.g., handset GPS is not required). This will be described in more detail in this specification.

[0221] The proposed architecture using orbiting base stations presents the challenge of managing network communications and traffic routing with a constantly and very rapidly changing network infrastructure. However, with sufficient modeling of orbital mechanics and combined with telemetry measurements, it may be possible to accurately predict future state vectors for the entire orbiting base station population.

[0222] A database of network element locations and speeds may also include the locations and addresses of many ground stations serving the satellite network. The database may even store the orientation of gateways in a given coordinate system, relating the direction an antenna is pointing to the coordinate system in which the satellite is being tracked. [C. Description of the Network Model (NM) Database]

[0223] Figure 14 shows the network model database 1402. The database may include a model of Earth's gravity 1404, a model of Earth's atmospheric density 1406, a model of Earth's magnetic field 1408, a model of the spacecraft bus system 1410, a model of spacecraft actuators such as thrusters and attitude control 1412, a model of each antenna in the network on each spacecraft, mainly the antenna radiation pattern of the link budget 1414, and a model of the solar system 1416, which includes the positions of the sun, moon, planets, etc. [C.1 Earth's Gravity Model]

[0224] A database of Earth's gravity field models can be used to calculate the force from Earth's gravity on a satellite based on the satellite's presence and future position. Earth's gravity models can take various forms, some of which offer a trade-off between computational accuracy and timeliness. For example, a simple spherical gravity model of Earth may be implemented, a WGS-84 elliptic gravity model of Earth may be implemented, or a n-th order sum of terms using coefficients describing Earth's band-harmonic gravity field may be implemented (e.g., harmonics through J4 may be sufficiently accurate). Various options offer varying degrees of fidelity and timeliness in acceleration calculations. Many models can be stored so that a function can be called to calculate acceleration as a function of the satellite's position relative to the ECEF coordinate system.

[0225] The torque resulting from the gravitational gradient force on the satellite may be equivalent to the cross product of the gravitational force acting on the satellite and the vector representing the position of the satellite's center of mass relative to the satellite's center of gravity. As shown in Equation 5, gravity acts through the satellite's center of gravity, and the satellite rotates around its center of mass.

number

[0226] To support the calculation of orbital and attitude perturbations caused by drag, an atmospheric model of the Earth may also be stored. For example, one or more atmospheric models may be implemented, such as NRLMSISE-00, Jacchia, or JB2008. The outputs of these models to support state-space prediction may be density and temperature. These are atmospheric properties that drive atmospheric drag on the satellite. In addition to atmospheric density, the satellite's ballistic coefficient also drives the calculation of atmospheric drag.

[0227] As shown in Equation 6, the drag force on the satellite can be calculated as a function of the satellite's orbital position, orbital velocity, day / hour (depending on the model), the atmospheric model used, and the satellite's orientation.

number

[0228] The torque resulting from atmospheric resistance on a satellite may be equivalent to the cross product of the drag force acting on the satellite and the vector representing the position of the satellite's center of mass relative to the satellite's center of pressure. As shown in Equation 7, the drag force acts through the satellite's center of pressure, and the satellite rotates around its center of mass.

number

[0229] The Earth's magnetic field can also be modeled. This model can be useful when magnetism is used for attitude determination and control of a spacecraft. This is particularly useful in LEO orbits. In LEO orbits, the Earth's magnetic field is of an absolute value that facilitates both measurement and pressing using on-board magnetic torque. A magnetic field model, like the Earth's gravity model, can take various forms. This model enables calculation or lookup of the field at the satellite's position as a function of the satellite's position and the date and time of the desired measurement. As in Equation 8, examples of magnetic field models are the International Geomagnetic Reference Field (IGRF), the World Magnetic Model (WMM), or the Extended Magnetic Model (EMM2105), etc. [Number] The torque resulting from the magnetic force on the satellite can be equivalent to the cross product of the satellite's magnetic dipole (intentionally induced by a magnetic actuator but also unintentionally induced by electronic devices etc. mounted on the satellite) and the magnetic field around the satellite at that point, as in Equation 9. [Number]

[0230] As in Equation 9, the torque resulting from the magnetic force on the satellite can be equivalent to the cross product of the magnetic field around the satellite at that time and the satellite's magnetic dipole (intentionally induced by a magnetic actuator but also unintentionally induced by electronic devices etc. mounted on the satellite). [Number] [C.4 Spacecraft Bus Model]

[0231] The spacecraft bus model can include data regarding the specifications of the spacecraft's subsystems. The amount of data that can be stored regarding the technical characteristics and performance of the spacecraft is enormous, but below, an enumeration of some data that can be useful in applicable embodiments will be described. The spacecraft bus model will receive notifications from the TTCC&DH system. This is because telemetry is obtained from the spacecraft during operation. However, at the start of the service life, this model can be established, for example, based on the initial performance after ground tests.

[0232] Structural / mass information about the spacecraft may exist in the database. The spacecraft bus model may store the spacecraft's dry mass, wet mass, current mass, moment of inertia matrix, etc. This may also include the current mass of fuel available on the spacecraft. This data may be from telemetry readings on the spacecraft and may be updated over time. The inertia state matrix may be improved by onboard measurements on the spacecraft, as it measures attitude rate values ​​from known torques applied to the bus. Errors may be measured for modeled changes in the satellite's angular rotation velocity (which may be used to measure disturbance torques) and / or changes in the inertia state matrix, as operations are performed. In addition to mass values, the spacecraft's inertia tensor may also be stored. This may be a 3x3 array representing the spacecraft's moment of inertia. Further structural information may exist regarding the spacecraft's thickness and structural size and its associated items. If the power and thermal simulations in the extended MME were intended to utilize Parasolid in finite element analysis simulations, even a Parasolid model for each spacecraft may be stored.

[0233] In relation to mass information, drag properties such as the satellite's ballistic coefficient may also be stored. The satellite's drag coefficient can vary as a function of the angle of attack or orientation relative to the satellite's velocity vector. The database of drag coefficients can be stored as a matrix where rows and columns represent angular offsets (elevation and azimuth) from velocity. Similarly, the satellite's solar reflectance can vary as a function of orientation (unless in this case, orientation relative to the position of the sun relative to the satellite). As in Equation 10, the ballistic coefficient can be calibrated and / or improved over time with respect to the orbit based on errors measured on the modeled trajectory from the state-space prediction function.

number

[0234] In a similar manner, the database could also store how the satellite's pressure center and gravity center change as a function of the spacecraft's orientation (relative to Earth and its velocity vector).

[0235] The database may also store thermal information about the spacecraft. This could be a simple vector representing each surface of the spacecraft, holding its absorptivity and emissivity values. Other vectors may also exist representing the thermal conductivity paths throughout the entire spacecraft.

[0236] The power system can also be modeled. Here, the spacecraft's power consumption is quantified as a function of which components receive power distribution, or when operating in a specific mode. The battery can also be modeled. Here, the charge and discharge rates and curves during testing are recorded (and updated from telemetry after on-orbit operation). This information can be used in power simulations to ensure that the network state-space predictor does not command the satellite to operate outside of power consumption and memory capacity limits. [C.5 Spacecraft Actuator Model]

[0237] A database storing actuator models can quantify thruster performance, actuator attitude control, and other parameters. It may also contain data on actuators for deployment in other systems, such as antennas and solar arrays.

[0238] In a propulsion system, the database may contain mechanical information about the initiation of vectors provided by the thrusters. These may be vectors in the spacecraft's body coordinate system. The propulsion system may also have performance characteristics such as thrust, Isp, and mass flow rate, which may be functions of the operating regime (e.g., pressure, temperature, power input, etc.). Fuel levels will be monitored during flight, and the model will be notified / updated based on measured changes in thrust, power, etc., from the initial performance.

[0239] In an attitude control system, the database may be a series of vectors representing the mechanical layout of the attitude control system. In a reaction wheel, these vectors may be normal vectors relative to the wheel in the spacecraft's body coordinate system. In a torque coil, this may be the surface of the coil. Other information about the system may be stored, such as torque that can be applied as a function of the operating regime (e.g., current applied to the actuator). [C.6 Database of Network Antenna Orientation]

[0240] Spacecraft used for space networks may host a set of antennas for communication between ground base stations and UEs, communication between orbiting base stations via ISLs (ISLs) and other base stations (or possibly orbiting MMEs), and / or communication between orbiting base stations / MMEs and further MMEs, ground gateway antennas acting as P-GWs or S-GWs. When a spacecraft is designed, the selection of the locations of these antennas is usually known, documented, and can be stored in a database where individual spacecraft design characteristics will be preserved.

[0241] The antennas on the spacecraft may be of various types or of one type. With analog antenna technology, by physically orienting the antenna in a specific direction, it becomes possible to generate an RF radiation pattern representing directivity or gain as a function of the orientation / angle with respect to the boresight of the antenna (typically, its direction / orientation). Antennas that behave in this way may be parabolic antennas, horn antennas, helical antennas, four-wound antennas or patch antennas. Antenna arrays steered in a digital manner may also be used. An antenna steered in a digital manner, i.e., a phased array, may comprise a plurality of analog elements such as helices, patches, dipoles, etc., arranged in an array. This enables spacing for corresponding to specific gain requirements for a specific use bandwidth. The phased array may have a mechanically fixed orientation defining the boresight, but the beam may be steered digitally off that boresight vector by offsetting the phase of the signals transmitted through each element within the phased array. Thus, the phased array may have one

Number

Number

Number

[0242] The performance characteristics of the antennas mounted on the spacecraft can be measured and calibrated on the ground before flight. The gain, directivity, VSWR, etc. of the antennas

Number

number

[0243] In certain embodiments, the payload antenna may communicate with the UE in the sub-1 GHz range of the cellular band. A single antenna and an RF front-end filter / LNA bank may be designed to accommodate many cellular bands between 600 MHz and 960 MHz. Intersatellite link antennas and ground station link antennas may utilize higher frequencies, such as the S-band, X-band, Ku-band, Ka-band, V-band, or W-band. The abundance of hardware, RF components, and ground stations compatible with the S-band, X-band, Ku-band, and Ka-band may drive design decisions for these transmission links.

[0244] Figure 15 illustrates how spacecraft 1502 can host various antenna beams to generate ISL, GSL, or UE connections. The spacecraft's body reference coordinate system 1506 may be oriented to some other reference coordinate system 1504, such as the Earth-centered coordinate system or the Earth-fixed (ECEF) coordinate system. Antennas supporting various communication paths may have a physical orientation on the spacecraft body. These antennas, when oriented in a particular direction, for example,

number

number

number

number

number

number

[0245] The relationship between the antenna Poynting vector and the beam vector can be defined as a rotation matrix corresponding to a certain axis and angle with respect to the spacecraft's coordinate system. This would also correspond to a certain phase shift in the RF network behind the antenna. This enables beamforming. The relationship between the phase shift from the antenna aperture vector and the beam offset can be stored in a database.

[0246] Each beam and each antenna has a unique directivity, gain, VSWR, etc., as a function of orientation relative to the link budget geometry (for example,

number

number

[0247] This information can be numerically stored in a database as the gain radiation pattern of an antenna flying over a spacecraft. This may be a matrix of dB values ​​represented by rows and columns, where the rows represent the angular offsets in the E and H fields. The database may also include information about the antenna's position and orientation in the spacecraft's coordinate system. This allows the antenna's orientation to be calculated in inertial space, assuming any attitude.

[0248] In the case of a phased array antenna, the radiation pattern can be stored as a three-dimensional matrix of dB values, represented by rows, columns, and lanes. Here, the rows and columns represent the angular offset in the E and H fields with respect to the direction of the beam formed by the array, and the lanes represent the radiation pattern at a given phase offset for beamforming at a specific angle from the boresite.

[0249] As shown in Equation 11, the gain provided by a beam in a specific direction, for example, toward the UE, can be modeled by the previously described three-dimensional matrix, such that a function can be called using the orientation of the satellite, the orientation of the antenna, the orientation of the beam, and a vector representing the position of the UE relative to the antenna.

number

[0250] Further databases may be stored to support the calculation of orbital perturbations that do not necessarily drive the orbital dynamics of satellites but can generate measurable trajectory deviations that should be modeled for the accuracy of state-space predictions. An example of this type of database may be a map of the positions of planets in the solar system (including the Sun and Earth's Moon). As in Equation 12, the positions of planets in their orbits around the Sun can be modeled using a simple polynomial that can calculate the future positions of planets based on a desired date and time.

number

[0251] The constellation location register is a database that holds a lot of information needed for the state-space prediction engine to analyze the coverage dynamics of network base station transmitters. This database can be implemented as a list of locations relative to the ground surface that are targeted by the network.

[0252] Figure 16 shows the constellation location register 1602. This database may include mesh points around the Earth 1604, the locations of space-based base stations 1606, the locations of ground base station coverage polygons 1608, the locations of "static" coverage polygons for space network base stations 1610, the locations of dynamic coverage polygons from the space network 1612, and UE locations (e.g., GPS coordinates) 1614. [D.1 Meshpoint Database]

[0253] Components of a space-based network develop a model of the Earth. This may be done as a mesh of points. These components may store this in a database. This mesh of points may be generated randomly, perhaps once or repeatedly. Alternatively, this mesh may represent a structured grid around the Earth. For example, a mesh of one million points equally spaced around the Earth may provide geospatial fidelity to a grid of approximately 500 square kilometers (approximately 22 km x 22 km square).

[0254] In certain embodiments, the mesh may be weighted based on population density, where cells are smaller and more tightly packed. Alternatively, the mesh may be created to improve the analysis of network performance at specific geographic locations, and therefore, the mesh may be denser in certain areas.

[0255] In another embodiment, many meshes may be created and filtered based on type (e.g., sea routes only, specific countries only, specific states only, etc.).

[0256] For each mesh point in the database at any given time, there may be a list of rules or policies for that point in the mesh. Each particular point in the mesh may not have any rules, but may have many rules, such as which frequencies can be used there, or how much signal energy can be radiated to that point in the mesh over a specific bandwidth at a given frequency. Each of these rules may be defined by a polygon, and each point in the mesh may have multiple rules as a result of being covered by multiple polygons. This data, along with other policies / operational requirements or constraints, may be stored in a separate database called the Constellation Policy and Rules (CPR) database. [D.2 Base Station Polygon Database]

[0257] In one embodiment, there may be a database of polygons representing ground cells, described by a central point representing the edge of a ground base station cell. Further information about the polygons may also be stored, such as cell ID, MCC, MNC, S-GW, P-GW, and possibly coverage information such as the coverage protocol (e.g., GSM, LTE), frequency, antenna gain, and RSSI from the cell and neighboring cells at each point inside / above the polygon.

[0258] Further polygons representing target coverage cells for space networks may be stored in this database (for example, a specific geographical area agreed upon by the network provider may be deployed within that area because no other towers are deploying spectrum there). These coverage cells may be static on the Earth's surface, and their diameter may correspond to the size (e.g., orbital height, gain, and beamwidth) that a set of antennas on an orbiting base station can cover at that frequency. These polygons may be stored along with a center point and edge points having specific latitude, longitude, and altitude coordinates, as well as a series of further data points. For each of these data points, there may be information such as which frequencies can be licensed for use by the space network at that location, bandwidth requirements for that location (e.g., MCS, bandwidth, data rate, etc.), approximate subscriber density, minimum RSSI from the space network, maximum RSSI from the space network, neighboring cells, RSSI of neighboring cells, MCC, MNC, LAC, etc. Common coverage requirements (e.g., frequency) may be met by specific polygons in the database that indicate coverage areas, which may be geographical areas. Each polygon may be described by a center point and edge points to define which points within the mesh it covers or includes. Stored data for center points may differ from data stored for points at the edges of the polygon (e.g., the RSSI at the center may differ from the RSSI at the edges).

[0259] Figure 17 shows how a point mesh database may be implemented. Shown are a set of points that may be points in a mesh. Each point may be stored as a vector having three values ​​that represent its position vector in the ECEF coordinate system. There may be several satellites 1722 in orbit that have beam steering capabilities. There may also be other satellites 1724 that do not have beam steering capabilities. A beam steering array may be directed towards a static polygon base station cell 1710 on the ground, which can be described as a set of points in the mesh contained within a polygon 1712 and on its edge 1708. An array without beam steering may use a spot beam for a moving Earth. These may be described in the database as dynamic polygon base station cells. Similarly, static cells may have points in the mesh contained within a dynamic cell 1714, some of which are contained on the edge of cell 1716. Ground base station polygons may be stored 1706, and they too may have mesh points inside them 1704 and on their edge 1702. In some embodiments, the location of UE1720 may also be included in the mesh. The mesh may cover the entire surface of the planet, and some mesh points 1718 may be included outside of existing polygons (ground or otherwise). [D.3 Database of Polygon Position and Velocity]

[0260] An orbiting mobile network may utilize a database containing information about certain polygons or service areas on the Earth's surface that are of some importance. For example, static polygons on the Earth's surface might represent licensed areas for specific frequencies used by an orbiting satellite network. Alternatively, there might be polygons defining specific service areas that require a certain level of service (e.g., data rate, data rate per square kilometer, etc.) to provide meaningful service to that region from orbiting transmitters. Some polygons in the database may be moving, and therefore their position and velocity change over time. This could be, for example, another satellite coverage footprint. [D.4 Static Cell Coverage Zones]

[0261] The coverage area for a satellite can be predefined as specific latitude-longitude polygons on the Earth's surface. These polygons may be large or small, based on several requirements, including the available spectrum from the satellite and the population density of the desired coverage area. Ideally, the polygons should be shaped based on several known radiation patterns of the aperture at various attitudes while in orbit, so that the beam can be well matched to the polygons defined on the ground. The polygons may or may not overlap. If interference mitigation control between adjacent cells is sufficient, small errors of about 1 dB or 2 dB in the signal energy radiation to the Earth's surface should not indicate network problems. Alternatively, the aperture may utilize a phased array, which would allow the spot beam to be clearly represented offset from the boresight by a certain angle relative to the antenna's normal vector. These polygons may also be driven by regulatory requirements, radio transmission license boundaries, service area requirements, and / or satellite constellation design. Polygons can be as small as individual spot beams with certain characteristics (e.g., a peak signal followed by a decrease towards the cell edge), or as small as the borders of a country, or as small as a large region / band across a planet where the signal requirements from a space network are constant (broadly dispersed) and minimal (low signal energy).

[0262] Each static cell coverage zone may be defined as a polygon in a database containing some information, such as its location center, location shape (e.g., a circle of a certain radius, a rectangle of a certain length or width, etc.), and / or vectors representing the polygon's boundaries in a coordinate system such as geodetic latitude, longitude, and altitude. Polygon information may also be stored along with the service specifications within that cell. This may include peak power, minimum power, or some other signal energy or quality of service characteristic to indicate the cell's target coverage statistics, and how the satellite may behave during an overpass (from the perspective of attitude or Tx power and beamforming). Since static cells are predefined for the network, they may be stored in a database either within the satellite network or the ground network and can be accessed by the satellite network. Each static cell coverage zone may be assigned a specific satellite in the network for coverage. Satellites covering a static coverage zone may be stored in a timeline where a specific satellite number is stored for a given timestamp if it can provide coverage to the static cell. A given static cell may be covered by two satellites at a time. Software may be run to calculate, either on a ground network or within a space network, which satellites (which the software can use to provide coverage and resolve possible conflicts) should transmit and cover the static cellular zone during an overpass. This software may use predicted link budget conditions at each center of each polygon on the planet for each satellite. Whichever satellite has the best link budget to the cell at that time may maintain coverage for that cell. This software may also provide data on which satellites are providing coverage based on power consumption. Perhaps a specific battery capacity is desired for each satellite, with those having more battery capacity taking precedence.

[0263] Since coverage zones are defined in the database as specific shapes with a particular center point, this can be used at the satellite end of a link to inform how coverage should be optimized. Each coverage zone can receive a defined level of service (e.g., at least what signal level is desired in its cell for satellite service). Due to the defined service levels and the coverage areas defined by polygons, each satellite in the network may not be equipped to provide coverage to a polygon and will instead provide coverage to other areas that are intended (and designed) to provide coverage, ignoring the polygon. Satellites capable of providing coverage to a polygon may be documented in the database, and perhaps even further, the configuration that the satellite needs to provide the desired minimum coverage requirements (e.g., the number of beams required for coverage). In particular, the precise location where the spot beam should be centered can be specified in the database (for example, to cover polygon Y, the first spot beam may be directed to a specific coordinate, and the second spot beam may be directed to a different coordinate).

[0264] If an attitude determination system is used to rotate and change the orientation of an antenna at a specific location on the ground, the rotation angle relative to the cell coverage will expand the area of ​​coverage for the satellite footprint or coverage area. Depending on the coverage polygon defined on Earth, the coverage may correspond to this expansion and therefore may take the form of an ellipse on the surface. [D.5 Dynamic Cell Coverage Zones]

[0265] Satellites without beamforming capabilities may not be able to easily direct their beams to static polygons on the Earth's surface. Instead, such satellites can transmit beams from their apertures that are always oriented in the same direction relative to the spacecraft's coordinate system. In a scenario where the satellite is controlled to point its antenna towards the nadir, this would result in a spot beam traversing the surface in a passing motion. Therefore, over time, the position of polygons covered by the satellite transmitter is dynamic relative to the mesh representing the Earth, and the edges and centers of polygons may be at different mesh positions in the database at different points in time.

[0266] As dynamic cells move relative to the Earth, dynamic polygons will be moving above mesh points on the Earth's surface, subject to variable policy requirements, etc. For example, there may be a large mesh zone defining the total area between the central Atlantic and central Pacific Oceans, and the mesh points within those polygons may have the same policy requirements for a single spectral sliver that dynamic cells can use as they pass through the Earth's large zone. In other words, network spectral allocation can be distributed with looser rules across a wide zone to accommodate dynamic cells passing through the Earth and to more precisely allocate more spectrum to static polygons. If a static polygon is unavailable, the mesh containing it can still be served using dynamic cells that happen to be passing through it at a particular point in time.

[0267] An orbiting base station may be configured as a spacecraft with software-defined radio capabilities to transmit in any LTE band within a range that can be adequately handled by the antenna selected for the link budget conditions defined by the satellite coverage area. In this way, the orbiting base station may be treated by the UE as functionally equivalent to a ground base station.

[0268] If a coverage cell is transiting Earth, a database containing propagation data can be used to predict when cellular coverage from a satellite may become available at a given location. In this way, the locations of ground cells adjacent to the space network, which need to coordinate spectral utilization with the network, can be stored in the database, as well as static cell coverage zones.

[0269] Using the tower's position, the incident signal energy that recedes into the tower's cells can be calculated. A specific time can be calculated to determine when the tower signals between the ground cells and the satellite might conflict and cause interference if the towers share the same spectral channel for communication with the UE. At this point, the network may be programmed to automatically release control of specific frequency bands, channels, etc., used by the satellite during space network overhead that would coincidentally constitute an airspace infringement. In doing so, the spectrum may be shared temporally and, assuming optimized coverage conditions, can be used more effectively. Therefore, control or priority over a given channel may change over time based on the location of the orbital base station.

[0270] Several polygons may be added to a database containing service indicators such as priority levels, and these may be added dynamically in the case of emergencies where communication is primarily required by those geographical areas. Priorities may even be set as a function of time. Thus, the network can prepare in advance for impending emergencies. If priorities exist for the future, the network may be able to reserve power to allocate more spectrum utilization to polygons affected by weather or other emergencies that may result in increased polygon / network usage. In some embodiments, polygons may not be strictly polygons and may have some curved boundaries, but generally they can be treated as closed shapes with a finite area.

[0271] Figure 18 shows what the dynamic and static polygon schemes might look like. The satellite operates on orbit 1802 with some ground tracking 1820. Figure 18 shows the satellite without the beamforming antenna S1 at an initial time point t01804 and a later time point t11806. S1 may provide coverage to the dynamic polygon 1822 at the initial time point t0. After moving in orbit, S1 may continue to provide coverage to the Earth and provide coverage to the dynamic polygon 1812 at time point t1.

[0272] This figure shows another satellite with a beamforming antenna S2 at an initial time point t01808 and a later time point t11810. S2 may provide coverage to static polygon 1816 at the initial time point t0, and after moving in orbit, S2 may continue to provide coverage to Earth, and at time point t1, it may provide coverage to the same static polygon 1816. As shown, a beamforming satellite may provide coverage to multiple static polygons.

[0273] Other static polygons 1818 may exist in the database and may occasionally fail to obtain coverage. This may depend on the timing and results of the state-space prediction engine within the extended MME. Not shown in this figure for the sake of visibility is a fine mesh that may be shown across the ground surface. Each polygon may cover several mesh points, some of which are the center and edges of the polygon being depicted. Other polygons 1814 may also exist, although they are static, but are coverage polygons from existing ground base stations. [E. Constellation Policies and Rules (CPR) Database]

[0274] As mentioned above, CPR may include a set of data describing rules, regulations, policies, etc., for operating space-based cellular network transmitters across locations or for operating polygons to which these rules are mapped. These rules for a mesh representing a target location within the network may be regulation-related (e.g., frequency, power level, etc.) and quality-of-service-related (e.g., data rate, technical requirements, etc.).

[0275] Additionally, CPR may maintain a database of information regarding the orbital, attitude, thermal, and power constraints that govern the operation of each individual spacecraft in orbit.

[0276] Figure 19 shows the constellation policy database 1902 and its contents. The database may include a database of operational flight rules 1904 for the attitude and orbit control systems of the spacecraft, a database of operational flight rules 1906 for the thermal requirements / constraints of the spacecraft, a database of operational flight rules 1908 for the power / battery requirements / constraints of the spacecraft, a database of rules 1910 for positions / polygons / mesh points in the network, a database of quality of service rules 1912 for positions / polygons / mesh points in the network, and a database 1914 for spectral analysis / interference data acquired from orbit. [E.1 Database of Attitude and Trajectory Control Flight Rules]

[0277] Attitude and trajectory control flight rules may be stored in databases in various forms, which are described here.

[0278] To support a predictive engine using force models and spacecraft characteristics, a database may exist that stores planned future thruster operations as either thrust strokes or delta-V strokes. These planned operations may be stored as vectors. Each vector element represents a thrust state in time. The vectors may even be for voltage or current values, indicating which control levels are used for the thruster's possible actuators. Future thrust and delta-V calculations may be predicted based on the satellite's trajectory and the corrections required to maintain the satellite's behavior in a particular orbit or within an orbital control box. For example, this control box may be dynamic and change based on commands from a network-controlled NOC. This may result in a recalculation of the delta-V operation to achieve the correct orbital position per NOC command. At that point, the database for flight operations would be updated.

[0279] Similar to delta-V operations, CONOP requirements may exist for utilizing the spacecraft attitude control system. The spacecraft may store in a database vectors representing the torque vectors that need to be executed, or Poynting vectors for future alignment in inertial space along the satellite's trajectory. An example might be that the satellite requests a specific face of its body to face the Earth, another face to face a satellite in front of it, and yet another face to face perpendicular to those two vectors. Just as delta-V requirements can be predicted in the future, attitude control methods can also be predicted. This may be done using rigid body dynamics simulations, which may be performed iteratively to correct the results when telemetry is reported regarding the spacecraft attitude and control system.

[0280] Attitude dynamics simulations are typically far more difficult to simulate over long timescales than orbital mechanisms, and can consequently become a bottleneck for state-space predictors. Techniques can be implemented to simply assume attitudes based on eligible "attitude modes" (e.g., pointing to the nadir, pointing to the zenith, etc.). Thus, future attitudes can be inferred without requiring computation (or numerical integration), and the spacecraft's state-space positions (e.g., position, velocity, orbital angle momentum vectors, etc.) from orbital mechanics simulations can be used to infer the Poynting vector for the spacecraft itself. [E.2 Thermal Requirements Database]

[0281] A database of thermal requirements can be maintained simply as a list of thermal operating thresholds for each component within each spacecraft. Based on a set of data representing the mechanical / conductive properties of each spacecraft (in the spacecraft bus database), along with orbital mechanics simulations, attitude simulations, and operational regimes (e.g., which components are powered on at each point in orbit), components of the space-based network can simulate the thermal properties of the spacecraft over time and ensure that there is no overheating (or excessive cold) in orbit.

[0282] There may be further thermal management requirements that can be stored in this database and used to notify its state-space prediction engine. [E.3 Database of Power Management Requirements]

[0283] Similar to thermal requirements, power management requirements can manifest as a list of thresholds for specific battery capacity thresholds. These thresholds may be assigned to specific modes (perhaps multiple modes each) indicating which operating modes are acceptable to the spacecraft when the battery is operating at a particular capacity, presumably to maintain a healthy power system in orbit.

[0284] There may be further power management requirements that can be stored in this database and used to notify its state-space prediction engine. [E.4 Database of rules regarding meshes / polygons]

[0285] As explained earlier, a database of meshes or polygons may exist that define virtual locations and regions on the Earth's surface in order to determine coverage statistics for a target area or location.

[0286] These polygons and locations may, of course, exist around the Earth and may have different regulatory requirements. For example, only certain polygons may be able to be serviced using certain bandwidths. This may be stored as a list of resource blocks, ARFCN, etc., which can be assigned to the space network (and perhaps also store which spectra are assigned only to the ground network). In addition to frequency requirements, there may be transmission power requirements. Each point in the mesh may have transmission power requirements (e.g., RSSI, power flux density, power spectral density, etc.) for both resource blocks that the space network is permitted to use to provide its services and resource blocks that the space network is not permitted to provide services for. Thus, when a spacecraft transmits to a location on a resource block assigned to one polygon, adjacent polygons (and corresponding mesh locations) may be evaluated to ensure that transmissions to other polygons do not violate the regulatory requirements for adjacent polygons / meshes.

[0287] In addition to transmission power and frequency requirements, other priority requirements may exist for specific polygons. For example, some polygons stored in the database may be existing ground base station polygons. In the event of a disaster or when a disaster is anticipated (e.g., a hurricane), polygons associated with towers that have fallen or are expected to fall may be provided with indicators that allow the space network to know in advance or in real time that it needs to support coverage of these polygons during the required time. Since these coverage areas may be small relative to the satellite beam, they may be aggregated into larger polygons. This would ensure that if all of them fall, the satellite covers the polygons that define all of their combined coverage areas. The regulatory database may include specific first responder IMSIs for which priority should be provided in such cases, and how much spectrum the satellite may need to use during its cell coverage.

[0288] In the event of a disaster or other emergency, updating or relaxing power and thermal limitations / constraints may allow satellites to operate for short periods of time while they still need to provide coverage to the areas they require.

[0289] There may be further rules / requirements that can be stored in this database and used to inform its state-space prediction engine. [E.5 Database of QoS Rules for Meshes / Polygons]

[0290] Similar to regulatory requirements for each mesh / polygon, QoS requirements may also exist. These requirements may be driven by market demands in a particular region, population density within a particular polygon, and may vary depending on the time of day, etc. As a result, each mesh / polygon may contain "censuses" such as data indicating population or subscriber density within a particular area of ​​the globe. Based on countries, and possibly their price data, the revenue density for each polygon may also be calculated.

[0291] Quality of service requirements may include the amount of bandwidth required for deployment, the required net throughput (possibly on uplink and downlink), the minimum MCS required within the cell, the required latency to the terrestrial PDN or APN, and what types of radio access technologies (e.g., GSM, LTE, etc.) may be used to service the cell, and if there are multiple, which is preferred.

[0292] From a commercial standpoint, each polygon may also have a priority rating. This can be used within the state-space prediction engine to reconcile conflicts, for example, if a beam steering satellite can adequately provide coverage to more than one polygon but can only provide coverage to one, and can select which one polygon. This can be done when the satellite constellation is partially filled and provides intermittent coverage. In the case of coupling for priority ratings, coupling can be interrupted by internal coupling breakers in the network to select which polygons receive service for its overpass (e.g., all polygons receive the best service). This database may include values ​​indicating the amount of coverage received by a polygon in the last 24, 48, 72 hours, etc. This database may also include values ​​indicating the time since the last overpass, which can be useful information for evaluating coupling breakers when determining network coverage. Commercial drivers, such as revenue density, may be used in the algorithm for determining coverage.

[0293] There may be further QoS requirements that can be stored in this database and used to notify its state-space prediction engine. [E.6 Spectral Analysis / Interference Data Database]

[0294] The base station stack extension may utilize spectral analysis capabilities, the implementation of which can be described in more detail elsewhere in this specification. The output of this spectral analysis capability may be a matrix or vector of signal analysis results from raw data collected from the extended base station stack. The spectral analyzer may listen to a specific RF band while in orbit and record raw I and Q data from the receiver. Using Fourier transforms (FFTs) and possibly other digital signal processing techniques, the network can determine which resource blocks, ARFCNs, etc., are more likely to interfere as a function of their orbital position. This information may be useful in predicting interference margin requirements in the projected link budget for future base stations.

[0295] The complexity of the interference database may vary depending on the embodiment of this disclosure. In some cases, static, occasionally updated interference levels may be stored for each mesh or polygon based on the orbital position of the satellite providing the service. In more complex embodiments, interference information may be stored as a function of space, frequency, and time (for example, this may allow for predictions of link budget performance variability and interference over days, and possibly over weeks). The interference environment may be stored as dB values ​​above the expected noise floor.

[0296] Further RF signal intelligence, processing, and other data may exist that can be stored in this database and used to notify its state-space prediction engine. [F. Network State Space Prediction Engine]

[0297] The Network State-Space Prediction Engine is part of the Mobility Management Entity (MME) extension. The Network State-Space Prediction Engine performs a series of steps to compute simulations of future satellite orbital dynamics. These simulations are a reliable part because they fairly frequently predicate the spacecraft's position, velocity, and mass (e.g., ballistic coefficients) with relatively consistent values ​​throughout the flight. After the orbital dynamics are resolved, this can be complemented with attitude dynamics and control simulations. The orientation over time can be calculated based on a set of several predefined constraints for attitude maintenance for each satellite.

[0298] Based on position, velocity, orientation, and several assumptions about transceiver / antenna operation, the link budget between assumed links in the network can be calculated via link budget prediction. Based on the link budget prediction results, the network state-space prediction engine can predict the optimal network state-space. This may involve checks on power and thermal requirements or constraints in the CPR database for each satellite, so that feedback is provided and the analysis can be run again if a choice is made to use satellites that exceed their operating temperature or power limits. The output of the network state-space prediction engine is a network state-space prediction table, which can be represented by a matrix of selected radio interfaces that can be implemented between satellites, ground stations, and UEs (e.g., which base stations are active, which ISLs are active, and which GSLs are active).

[0299] Figure 20 shows the components of a network state-space prediction engine 2002 in one embodiment. First, the network state-space prediction engine may implement an orbit propagation function 2004 that can be used to accurately predict the motion (and relative motion) of satellites in the network based on information from the database described above. Next, an attitude propagation function 2006 may be executed, which can also be used to calculate the attitude and attitude rate of each satellite in the constellation over time based on information from the supporting database described above. This function may be computationally intensive and, in some embodiments, may be simplified using a “supposed” attitude CONOP (based on the result from the orbit propagation function as an example). This would allow for a reduction in computational intensity while maintaining model accuracy.

[0300] After the orbit and attitude of the space network have been propagated, a network link budget prediction function 2008 may be implemented. This function can take the results of the orbit and attitude simulations and generate analysis results of possible ISL transmission links, GSL transmission links, and base station transmission links that the network may be able to use at all times. The results of the link budget prediction can be passed to a network state-space prediction function 2010. The network state-space prediction function 2010 may utilize algorithms or algorithms to select which links (for base stations, ISL, and GSL) should be created within the network. These algorithms may utilize data stored in the databases described above regarding rules, policies, constraints, etc., and meshes, polygons, satellites, etc. The results of these processes may provide a network state-space prediction matrix 2012 that can be used to formulate decisions about which links will be created and which will not. This state-space prediction matrix can be used to generate a state-space prediction database of paths used to inform network operation. [F.1 Orbital propagation function: Propagation of position and velocity]

[0301] Each spacecraft is equipped to determine its own position and velocity, and this information can be used on its internal computer and / or reported to a ground network for tracking, history logging, or use by ground computers.

[0302] Given the position, velocity, and orientation of a spacecraft at a given point in time, this can be used to accurately predict the spacecraft's future position. Orbital mechanics control the spacecraft's motion in orbit, and given the initial conditions of position and velocity, acceleration can be calculated, and numerical integration can propagate future position and velocity over a time span. The previously described database can be used to generate more accurate state-space predictions for the network.

[0303] The acceleration of an orbiting object in space can be defined as the sum of the forces acting on the object divided by its mass. Equation 13 can accurately describe the acceleration of an orbiting object at a specific position and velocity at a specific point in time.

number

[0304] Since the database stores information about gravity models, atmospheric models, planetary models, and spacecraft drag properties, Equation 13 can be numerically integrated using techniques such as the Runge-Kutta method or a symplectic integrator to obtain the spacecraft's position and velocity calculated over time. Depending on the fidelity of the model used, this element of the state-space predictor can accurately predict the spacecraft's position and velocity over time, days, or weeks with a considerable degree of accuracy.

[0305] If a spacecraft provides thrust, a torque may also exist as a result of that thrust. This torque can be valuable for the model in the attitude propagation function. Given a given thrust, the torque applied to the spacecraft may be the cross product of the thrust and a vector representing the position of the spacecraft's center of mass relative to the point where the thrust vector presses against the spacecraft (e.g., the position of the thrust nozzle itself). This is explained in Equation 14.

number

[0306] Since the fuel is taken from the thruster, this is item

number

number

[0307] Orientation or angular position and angular velocity can be measured by the spacecraft and used to calculate the future orientation state vector of the spacecraft. The future orientation of the spacecraft can be predicted using knowledge of the spacecraft's inertial state vector and how it may change over time with fuel use, etc., as well as planned torque operations based on control laws or a desired Poynting vector.

[0308] The laws governing rigid body dynamics can be modeled as shown in Equation 15.

number

[0309] It may be more appropriate to calculate the desired vector for the torque law term in Equation 15. (Spacecraft rotational angular velocity)

number

number

number

number

[0310] In one embodiment, if attitude dynamics are assumed to orient the spacecraft's body coordinate system in a specific direction relative to its orbit and the Earth, then attitude dynamics can be modeled more rapidly. For example, a satellite may be assumed to fly with one body axis pointed downward to the nadir, or with another body axis pointed in the direction of its velocity, perhaps at a known angular offset from the nadir, and possibly in the same plane as a potential nearby satellite. A third axis would be perpendicular to the first two in inertial space to generate an orthogonal body axis coordinate system. [F.3 Link Budget Prediction: Link budget between the position of the spacecraft and the position of the ground station]

[0311] Based on the position, velocity, and orientation of an orbiting base station in inertial space, link budgets (uplink and downlink) between the base station and any location in inertial space (e.g., on the ground or in orbit) can be calculated. Furthermore, link budgets can also be calculated for potential links between satellites and links between ground stations and satellites.

[0312] In one embodiment, link budget prediction can implement link budget calculation for all links using the same format. As an example, equations 16 and 17 describe the link budget representing the connection between the base station and the UE.

number

number

[0313] In equations 16 and 17, EIRP refers to the decibel representation of the signal's antenna gain and transmission power. For a base station, this may be a function of the frequency used in the link and the transmission power of that particular base station space platform. This may be similar for an UE, but in one embodiment, this can again be modeled fairly accurately as a assumed constant for a particular device with respect to a particular protocol (e.g., GSM limits MS uplink power to 2W per 200kHz bandwidth, and LTE limits UE uplink power to 200mW per 180kHz bandwidth). In equations 16 and 17, G is the gain of the receiving antenna at the end of the link. This may, likewise, be a function of frequency or a constant.

[0314] The remaining terms are loss, noise, and interference within the link. Pointing loss

number

[0315]

number

number

number

number

number

number

[0316] air loss

number

number

number

number

[0317] The remaining terms in Equations 16 and 17 are the thermal noise floor, the receiver noise figure, and in-link interference. The thermal noise floor can be estimated based on the link bandwidth and the temperature of what the receiving antenna is "seeing." In one embodiment, this value may be assumed to be constant somewhere between 290 and 300K. The receiver noise figure may vary per frequency or may be expressed as a constant. Typical specifications for a UE device require a noise figure of 7 dB at worst. A well-designed satellite receiver in the sub-1 GHz band may have a noise figure of 2 dB. In-link interference may be a function of the link frequency as well as the receiver's position and orientation. This value may be more important in uplink calculations and may be informed by spectral analysis data provided by an extended base station. On the downlink, interference may or may not be informed by in-situ measurements, and may or may not be a value stored in a database for signals from known ground eNBs (where satellite and ground coverage cells overlap). In either case, the interference may be modeled as constant or not modeled at all. The interference in this equation would be multiple decibels representing the number of decibels above the thermal noise floor at which interference occurs in the link.

[0318] Equations 16 and 17 can be used to calculate the SINR of a given link. Further link budget parameters can also be calculated. Since the bit rates of the LTE and GSM protocols are specified based on the protocol modulation and coding scheme tables, the EbN0 and the predicted bit error rate can also be calculated accordingly. Further physical layer qualities such as Doppler shift and propagation delay can be predicted and utilized to inform PHY layer control.

[0319] The ability to predict the position, velocity, and orientation of future space infrastructure can be used to calculate possible future link budgets between specific nodes in orbit and on the ground. This presents an opportunity to accurately predict and optimize the operation of the entire network based on a set of operational constraints (e.g., maximum link distance), rules (e.g., maximum Doppler shift), etc.

[0320] Figure 21 shows the link budget geometries for possible base station links 2122, GSL2116, and ISL2104. Base station link 2122 is evaluated based on base station satellite 2114 and UE2138. The satellite base station antenna boresight 2120 may differ from the antenna beam direction 2118 by a certain angle 2124 from the boresight. The link geometry may generate a pointing offset 2112 which can be used to calculate the antenna gain and EIRP of the corresponding point or target UE. The UE may also have a beam direction 2128 based on its orientation. Evaluating the base station link across a ground mesh may result in a computable contour of a spot beam 2130 and other mesh points outside of that beam 2134. Some ground towers 2132 may be within the beam energy, and interference may be evaluated in a mesh 2136 representing ground base station polygons.

[0321] An intersatellite link 2104 can be evaluated between two base station satellites 2114 and 2108. A GSL 2116 can be evaluated between base station satellite 2108 and ground station 2140, having vectors 2126 and 2110 representing the orientation of those antenna beams for communication on that link, using the beam directions of ISL antennas 2106 and 2102 (which, like the base station array, may also be oriented off-center from the boresight, but for brevity this is not shown).

[0322] Although not shown in Figure 21, losses within the link can be calculated based on frequency, path loss, Poynting offset, polarization offset, line loss, body loss, etc., based on the geometry previously described in this disclosure. [F.4 Procedures for Link Budget Predictors and Network State Space Predictors]

[0323] The link budget engine is used to predict both RAN (e.g., base station) coverage deployment and core network tunneling connectivity. To do this, the link budget engine can calculate possible (reasonable) link budgets for various possible satellite beams at various points within each target polygon and at each point in a global mesh. In one embodiment, the entire mesh or multiple meshes may be the target polygon (e.g., the link budget is calculated over the points to be stored). Furthermore, beams for ISL and GS link beams may undergo a similar procedure. The results of this analysis generate a set of link budget scenarios that can be considered a kind of Monte Carlo simulation. The Monte Carlo simulation generates a set of scenarios that may be mutually exclusive (e.g., each beam can serve only one polygon at a time) and that can be evaluated by software. [F.5 Network State Space Prediction for Beamforming Satellites and Static Polygons]

[0324] Link budget predictors and state-space predictors may be implemented sequentially in iterative stages performed by network components in some embodiments. In the embodiments described, this procedure may have an initial iterative stage that evaluates scenarios for base station coverage of static coverage areas by beamforming satellites. The link budget may be calculated for each beam at each time step in the orbit / attitude simulation for each polygon within the distance of the beam transmitter. The assumed beam direction of each beam may be made to provide optimized coverage for the static polygon under evaluation. This procedure may be vectorized so that it can be calculated rapidly. Once the base station link budget has been calculated for the beamforming satellites for static polygons within range at various time steps, a specific polygon for which each beam in the satellite set can provide coverage is selected at each point in time.

[0325] Figure 22 shows a procedure that may be implemented by the first iterative stage described in the disclosed embodiment. The procedure may be implemented as software, and the procedure flow will be described in that context. The procedure includes for loops and iterative computations. However, the software may be compiled into a program that executes instructions in a vectorized manner to rapidly perform computations on a hardware deployment.

[0326] Step 1 2202 may be the initiation of a for loop to a satellite in a network having base stations and beamforming antenna technology.

[0327] Step 2 2204 may be the initiation of a for loop for available beams on the loop-through satellite.

[0328] Step 3, 2206, may be the start of a for loop for static polygons in the CLR.

[0329] Step 4 2208 may be the start of a for loop to step through the simulation of the satellite's orbital dynamics and attitude dynamics.

[0330] Step 5 2210 may be a software check to ensure that the selected beam and the selected static polygon are within a reasonable distance from each other at the selected time point. This distance threshold may be set dynamically and may be used to avoid excessive calculations. If the distance check is not met, the software may exit the loop and proceed to the next time step.

[0331] Step 6 2212 may involve determining the beam direction of the beam to correspond to the static polygon at that time step. This could be a vector in inertial space or in the spacecraft's body coordinate system, which signals a command on how the beam may be directed.

[0332] Step 7 2214 may initiate a for loop to step through the available resource blocks for the static polygon being served.

[0333] Step 8 2216 can determine the signal power across the entire mesh in the CLR database within the satellite distance threshold at that time step by calculating the link budget in the uplink and downlink directions (for example, the link budget can be calculated across the entire mesh, not just polygons, after assuming a beam direction). The link budget can calculate various variables, including SINR, SNR, EbN0, Doppler shift, latency / delay, etc. Many of these variables can be used not only to assess the performance of the base station but also to evaluate its potential interference within the mesh area that should not be interfered with. Several assumptions may need to be made about the satellite's transmission power in order to calculate the link budget. Each satellite may have a default transmission power.

[0334] Step 9 2218 retrieves the link budget results and may check or analyze them against rules in the policy database. If the analysis results suggest a violation of a particular policy, the transmission scheme may be corrected by re-evaluating the link budget with a lower EIRP on the downlink channel. This reduces footprint bleed-over and may resolve possible regulatory violations from the previous link transmission scheme. If the rules cannot be met, the loop may be exited and the next resource block is iterated over.

[0335] Stage 10 2220 may obtain a Link Budget result indicating that it has passed regulatory requirements and checks against service quality requirements for polygons.

[0336] In stage 11 2222, transmissions are saved if QoS is met. If they are not met and the QoS requirements are not robust (e.g., if any coverage is not better than others), they may be saved anyway. In scenarios where QoS requirements are strict, link budgets may be discarded if they cannot provide the desired data rate, MCS, etc. (which are functions of SNR, SINR, EbN0, etc.).

[0337] Stages 12 through 16 (2224, 2226, 2228, 2230, and 2232) close the loop through each satellite, each beam, each polygon, and each time step.

[0338] Step 17 2234 activates the static polygon coverage optimizer. The static polygon coverage optimizer is a state-space predictor for static polygons and beamforming base stations, and may be a software function that uses the results of steps 1 through 16 to determine which beams from the beamforming satellite can provide coverage to the static polygon. This software function may step through each time step incrementally and check whether the number of available beams for any static polygon at each time step is greater than 1. If so, this software function may select one of these beams that can cover a polygon that satisfies certain optimal conditions (e.g., each cell will provide the longest coverage using the satellite going forward and will continue to provide coverage until it can no longer do so). If no beams exist for a polygon over a given time step, the polygon will not receive coverage. There may be policy considerations that prioritize certain polygons over others. Furthermore, policy considerations may fluctuate over time based on traffic estimates for that polygon, or perhaps the polygon has recently been added for service by the space network, because a ground tower has collapsed on the ground and is attempting to recover, requiring satellites to back up its service. Step-through time identifies which satellites can provide coverage to which polygon and indicates multiple backup satellites (in case of satellite failure between the present and future). This may also make it possible to understand which handover satellites could ultimately resume service to the static polygon if other satellites are unable to provide sufficient service. In some cases, static polygons and beams may not be assigned to each other during a particular time step. These time steps may be noted for subsequent iterations of the procedure between the link budget predictor and the state space predictor. [F.6 Network state space prediction for remaining beamforming satellites and remaining static polygons, as well as non-beamforming satellites and remaining mesh / dynamic polygons]

[0339] In the second iteration stage, the network state-space predictor can assess scenarios for the remaining base station coverage for both the remaining static coverage areas (with respect to static coverage areas to which no service was assigned at a particular point in time in the previously described iteration) and the dynamic coverage areas. In this iteration, both beamforming and non-beamforming satellite beams are assessed for coverage. The second iteration is similar to the first in that iterates the satellite beam diachronically. However, in this case, the beam is not guided by known static polygons (static polygons that could be covered by the beamforming satellite at each time step are considered in the previous iteration). As a result, the beam is assumed to have a certain pointing direction, which may be driven by the satellite's attitude or by several other facilitators, such as population density in the remote area in the case of the remaining beamforming beam.

[0340] After the assumed beam direction is established, the link budget may be calculated, and similar checks for policy and QoS requirements are performed before the iterations regarding the link configuration (and in this case, presumably the beam direction, if possible), and then the link budget is either preserved or not. At the end of the iterative loop, the remaining beam that can be transmitted is determined for each time step. After it is determined that the beam is being transmitted at a particular point in time, it may be necessary to harmonize the spectrum being utilized. Functions may be used to determine which frequency bands or resource blocks within the same frequency band are allocated to each base station. Once this is established, further base station operational requirements for each base station at each time step, such as which MIBs, SIBs, TACs, etc., they may need to implement as base station controls, can be determined.

[0341] Figure 23 shows a procedure that may be implemented by the second iterative stage described in the disclosed embodiment. The procedure may be implemented as software, and therefore the procedure flow is described in that context. The procedure may be implemented as software and includes for loops and iterative computation. However, the software may be compiled into a program that executes instructions in a vectorized manner and rapidly performs computation on a hardware deployment.

[0342] Step 1 2302 may be the initiation of a for loop for all satellites in the network that have base stations without beamforming beams, as well as for satellites in the network that each have a base station with a beamforming beam that has not been allocated or has not yet been allocated.

[0343] Step 2 2304 may be the initiation of a for loop for beams available on the loop-through satellite.

[0344] Step 3 2306 may be the start of a for loop to step through the time steps in the simulation of the orbital dynamics and attitude dynamics of each satellite.

[0345] Stage 4 2308 may implement a software function to determine the direction of the beam being evaluated. If this is for a beam steering beam, the direction may be determined based on the nearest part of the static polygon, or perhaps on remote mesh points with high population density of subscribers not connected by ground base stations. If the beam is not steering, the direction may simply be derived from the attitude of the spacecraft at that time.

[0346] Step 5 2310 may initiate a for loop to step through the available resource blocks of the mesh that are within the satellite's field of view at that time step.

[0347] Step 6 2312 can determine the signal power across the entire mesh in the CLR database within the satellite distance threshold at that time step by calculating the link budget in the uplink and downlink directions (for example, the link budget can be calculated across the entire mesh, not just polygons, after assuming a beam direction). Calculating the link budget may involve calculating various variables, including SINR, SNR, EbN0, Doppler shift, latency / delay, etc. Many of these variables can be used not only for evaluating the performance of the base station but also for evaluating its potential interference within the mesh area that should not be interfered with. Several assumptions may need to be made about the satellite's transmission power in order to calculate the link budget. Each satellite may have a default transmission power.

[0348] Step 7 2314 retrieves the link budget results and may check or analyze them against rules in the policy database. If the analysis results suggest a violation of a particular policy, the transmission scheme may be corrected by re-evaluating the link budget with a lower EIRP on the downlink channel. This reduces footprint bleed-over and may resolve any possible regulatory violations from the previous link transmission scheme. If reducing the transmission power still does not satisfy the rules, the software may iterate (if possible) with respect to the beam direction and repeat the process for link budget calculation. If this still fails, the loop may be exited and the next resource block may be iterated over. Iterations with respect to the beam direction may be limited to those intended to conserve computation time.

[0349] Stage 8 2316 may yield a link budget result indicating that it has passed regulatory requirements and checks against quality of service requirements for the lower ground mesh points. This stage may be skipped, and QoS requirements for non-beamforming arrays may be reduced.

[0350] In step 9 2318, transmissions are saved if QoS is met. If they are not met and the QoS requirements are not robust (e.g., if any coverage is not better than others), they may be saved anyway. In scenarios where QoS requirements are strict, link budgets may be discarded if they cannot provide the desired data rate, MCS, etc. (which are functions of SNR, SINR, EbN0, etc.). If link budgets are saved, transmission results may be used to determine the edges of the coverage polygons (which may differ per frequency). This may be used to calculate the edges of the dynamic polygon coverage area. In one embodiment, this may be the signal levels used for the terrestrial cell edges for the respective technologies, i.e., GSM (e.g., -105 dBm per 200 kHz) and LTE (e.g., -115 dBm per 180 kHz). Points in the mesh at the cell edges or cell centers may be shown at each time step.

[0351] Stages 10 through 13 (2320, 2322, 2324, and 2326) close the loop through each satellite, each beam, time step, and each resource block.

[0352] Step 11 2328 operates the dynamic polygon coverage optimizer. The dynamic polygon coverage optimizer is a state-space predictor for dynamic polygons implemented through the remaining beamforming and non-beamforming base stations. This function may be software that uses the results from steps 1 through 10 to determine which beams from the remaining beamforming and non-beamforming satellites can provide coverage to the Earth (over those particular dynamic polygons). This software may, as an example, implement a global optimization algorithm that includes calculating possible sortings of coverage scenarios at each time step and determining which satellites require transmission to maximize coverage while minimizing power consumption. Another embodiment may ensure minimization of cell overlap to avoid interference challenges associated with spectrum allocation. Different variables may be selected for optimization.

[0353] Step 12 2330 may implement a spectrum usage predictor, which may be a software function used to determine which resource blocks are allocated to each satellite base station and also possible ground base stations in the network. This software may evaluate the link budget for non-beamforming satellites in each static cell (both the locations of static polygon base stations served on the ground and the locations of static polygon base stations served in orbit). This software may also determine the link budget from beamforming satellites to static cells that consist only of ground base stations. Sharing may be required if the signal levels from the orbital radio infrastructure are equal to or higher than those used by ground towers, resource blocks, or frequency carriers.

[0354] Since it is known when the signal level from the satellite may become too high, and precisely which RB this may occur at, the space network can communicate this to the MME in the ground network using any affected ground cells. Based on this, the ground cells may temporarily increase their transmission power or temporarily eliminate the use of some of their spectral deployments. After the transmitters (and possibly a set of backups for each time step) are established for each time step, the network can determine which resource blocks should be allocated to which transmitters. Based on the allocation table and the RB rules for transmission in each base station beam, an appropriate RB partitioning can be implemented. This can be optimized by population density coverage, known remote UE coverage, expected traffic models, etc., to allocate an appropriate ratio of RBs to each transmitting base station in the satellite network. Technically, satellite downlinks will be weaker than most ground tower downlinks. The calculation results for the link budget at each base station can be calculated to determine whether the link budget was appropriate for sharing resource blocks. Technically, ground base stations would need to be able to generate downlink signals with a SINR greater than 0 dB relative to satellite downlinks within their coverage cells. This would enable at least the lowest order LTE MCS table configuration, MCS-1, using QPSK at a coding rate of 0.33.

[0355] Step 13 2332. The final step in the procedure may complete the base station control requirements for the satellite. Once the frequency domains for each transmitter are known, each future predicted base station may also be provided with a set of information regarding its domain-based network characteristics, including how it constitutes itself (e.g., which MCC, MNC, TAC, etc.), which it should transmit on its information resource block (e.g., MIB, SIB, etc.) if required.

[0356] Figure 24 shows a data structure 2428. The data structure 2428 may be a matrix, a cell array of matrices, or a matrix of matrices representing link budget predictors and selection procedures that satellite base stations are instructed to transmit as targets at each point in time. The mesh 2402 is decomposed into individual mesh points 2414. Each mesh point may represent a triaxial coordinate on Earth. A polygon may consist of multiple mesh points, and a polygon may represent base station coverage from a ground static base station 2408, a space static base station 2406, or a space dynamic base station 2404. The link budget is the mesh points as well as base station beamforming beams 2410 (e.g., b1, 2412) and base station non-beamforming beams 2424 (e.g., b 10 The link budget is evaluated for 2422). The link budget can be evaluated at individual time points 2416 where the position, velocity, and orientation of the base station satellites are known. The link budget 2426 for each mesh point at each time point can be evaluated over resource blocks 2432 for a desired list of performance variables 2430. As a result of these calculations, the network state-space predictor can determine not only which beamforming satellites are providing coverage to static space base stations at each time step 2418, but also which non-beamforming satellites are providing coverage to dynamic space base stations 2420.

[0357] A typical LTE base station may use 1MHz, 4MHz, 5MHz, 10MHz, or 20MHz blocks. Each of these blocks may contain multiple resource blocks (RBs) that themselves contain 12 orthogonal subcarriers with a bandwidth of 15kHz, each with a bandwidth of 180kHz. In the downlink portion of a link, the base station may communicate across many RBs at any given time. However, each mobile device may only be allocated a single RB for that specific device. As a result, a device transmits only a single 180kHz uplink RB to the base station.

[0358] When operating a space-based LTE communication system, allocating entire blocks of 10 MHz, 5 MHz, or even 1.4 MHz to the space network can be inconvenient. Most telecommunications traffic can pass through ground-based base stations. Consequently, the amount of spectrum allocated to the space network should be proportional to the traffic it is expected to carry.

[0359] Terrestrial and space networks can decide which implementations utilize which specific resource blocks within the LTE carrier band. For example, a terrestrial cellular tower may use the 5MHz LTE carrier band, but it knows that the uplink resource blocks within that carrier bandwidth should not be allocated to any of its mobile devices, for example, 1, 2, or 3, because the complementary space network will require those resource blocks. These RBs can be dynamically allocated to the space network in terms of frequency, quantity, and time. There may be more resource blocks (RBs) available when the space network is decommissioned across a specific area of ​​the world. Also, there may only be specific time slots across these resource blocks reserved for the space network.

[0360] This implementation could be done within software as a “spectral table,” which is software defined to block the allocation of specific resource blocks or time slots at specific locations based on a telecommunications traffic model (or possibly something else) for ground networks. Using ephemeris from its own orbital trajectory, a space network could reconfigure software-defined radio and flight computers to manage communications traffic over RBs or time slots that know which parts of the world it has access to. This could be stored in memory as an internal map onboard the satellite. This map would be designed to be updatable and reconfigurable because ground telecommunications traffic decays and flows over days, months, years, or decades, etc.

[0361] Figure 25 illustrates how the scenario described in Figure 24 could manifest itself in a real-world coordinate system, and how resource blocks could be dynamically allocated to the space network over its time step, in a manner in which LTE blocks are "sliced" to enable a specific spectral slice to a particular base station, possibly at a specific point in time (or, in another embodiment, permanently). In Figure 25, each base station coverage polygon may be shown as an "eNB," but in the following description, they will simply be referred to as "base stations" (e.g., base station 5 is eNB5). Each satellite 2502 may be equipped with one beam 2518. Base stations 5 through 8, covered in space, are shown transmitting to each other, as are base stations 1 through 4, covered on the ground. Each base station coverage polygon is provided with coverage by a certain beam (e.g., beam b1 is used to provide coverage to static polygon base station 5).

[0362] Within each base station coverage polygon, there may be corresponding mesh points (for example, the coverage polygon of base station 1 contains mesh points m1 and m2, and the coverage polygon of base station 5 contains mesh point m10 ~m 13 and m 28 ~m 39 (including). Block 2510 of the spectrum may require time-series partitioning and allocation of non-interfering traffic channels within a 5 MHz LTE block (for example, but the blocks may be of a width that LTE allows). Orbiting base stations and ground base stations may share the six central resource blocks for control channels, and dynamic allocation of PCI code may be used for distinguishable use of downlink control channels. Dynamic allocation of the number of PRACH preambles between the space network and the ground network may be performed. The allocated resources between the space network and the ground network are the used resource block 2512, the control resource block 2514, and the unused resource block 2516. These resource blocks may be allocated in various ways, but in such a way that there are no overlapping resource blocks between base stations having overlapping coverage zones, beams, etc. Frequency resources may even be allocated as a function of time, where a specific resource block and time slot are allocated somewhere. The space network may be implemented using GPS and therefore may be synchronized to understand when the time slots are included for each base station time-division multiple access implementation. This means that overlapping satellite coverage zones can simultaneously share the same resource block by allocating specific time slots on that resource block between satellites. [F.7 Network State Space Prediction for ISL and GSL]

[0363] The network state-space prediction function can evaluate link budgets for ISL and GSL. Based on the link budget results for ISL and GSL, the network can determine which connection is best to run at each time step. Some satellites may be designed to support multiple links via ISL or even GS. Depending on which network has priority, network connections may be selected based on various criteria (e.g., longest possible link data rate, latency, etc.). Network links are likely selected to reduce the root mean square of network latency for each UE expected to be connected to the network at each point in time. Once the most ideal links and link alternatives are determined for a given time, the network can determine which tunneling / routing links are available to power IP signaling and network control signaling. Additionally, to avoid disconnections of IP traffic connections within the network, the network can use this to predict when tunneling routes need to be handed over.

[0364] Figure 26 shows how a network state-space prediction engine can evaluate ISLs and GSLs.

[0365] Step 1 2602 may be the initiation of a for loop for satellites in the network.

[0366] Stage 2 2604 may be the initiation of a for loop not only to ground stations in the network, but also to other satellites in the network that were not looped or were looped through in Stage 1.

[0367] Step 3 2606 may be the start of a for loop to step through the time step in the simulation of the satellite's orbital dynamics and attitude dynamics.

[0368] Stage 4 2608 may implement distance checks to ensure that multiple satellites or one satellite and ground stations are within a reasonable and sufficient distance to warrant link budget calculations.

[0369] Stage 5 2610. If the link distance is deemed worthwhile for calculation, the beam directions of one satellite or multiple satellites and multiple ground stations can be determined. Ground stations may use dish or phased array beam steering techniques. Satellites may use beam steering arrays, mechanically steered apertures, or static mechanically mounted antenna apertures for ISL.

[0370] Step 6 2612 can calculate the link budget in the uplink and downlink directions for ISLs and GSLs. Assuming link budget geometry and transmission power, the link budget can be evaluated in both directions for many satellites and ground stations in the network. Links can be evaluated across individual frequency channels assigned to each link. This may be similar to how base station link budgets are evaluated across resource blocks. This information can be used to determine what level of interference may exist within a particular ISL. This may trigger a reduction in transmission power, appropriate dynamic allocation of bandwidth / spectral division, or complete refusal to use links with interference.

[0371] Stage 7 2614 may obtain the results of the link budget and check or analyze them for interference with other satellites that may be unacceptable and may require link reconfiguration (possibly including changes in geometry or power). If necessary, the stage returns to link calculations based on the reconfigured link parameters.

[0372] Step 8 2616 stores the link budget in the link state space, similar to that shown in Figure 24.

[0373] Stages 9 through 11 (2618, 2620, 2622) close the loop through each transmitting satellite, each receiving satellite and / or each local station and time step.

[0374] Step 12 2624 uses the link state space matrix results to determine which link should be used based on a network routing optimization algorithm. The network may, for example, desire to minimize root mean square time / latency to move packets from a remote UE to a ground station. For each selected link, a given frequency bandwidth should be determined based on proximity to other links, using similar or neighboring frequencies. A spectral strategy describing each satellite's frequency capabilities and which frequencies to share with other satellites may be implemented in the database. Alternatively, frequencies shared on the plane may be unique in the satellite constellation design (e.g., all other ISLs repeat frequency usage).

[0375] Step 13 2626 can determine what bandwidth allocation exists for each tunnel for IP bearers carrying control traffic, user traffic, and TTCC&DH traffic between nodes in the network. This may be constant or dynamic, based on predicted load.

[0376] Figure 27 shows a graphical embodiment of the link state space matrix for determining base stations and ISL and GS links. In this figure, each base station coverage polygon may be shown as “eNB”, but in the following description, it will simply be referred to as “base station” (for example, base station 5 is eNB5). As described above, mesh 2704 may have points 2718 that constitute static base stations 2770 and dynamic base stations 2706 (for simplicity, in Figure 27, they are simplified to either ground-based or space-based base stations). The mesh may also have points 2720 that represent the on-earth location of a particular UE that is a subscriber to network 2712. Similar to the mesh of points on Earth, there may be a set of network nodes 2702 that have other points 2716 representing the location of a ground station 2708 and point 2714 representing the location of a satellite 2710. This state space would represent a link budget scenario between satellites 2744, which can be divided into two groups: beamforming satellites 2742 and non-beamforming satellites 2756. In this particular embodiment, for the sake of brevity of the description of this disclosure, each satellite may have only one beam. Each beamforming satellite may be selected (2746) to provide coverage to a static polygon on Earth. As shown here, satellite S4 provides coverage to base station 3, which may be a static coverage polygon. A non-beamforming satellite is also selected to provide coverage 2748 to a dynamic base station. As shown here, satellite S5 is selected at time step t0 2740 to serve base station 5. Similarly, each ground station may communicate with satellites and their links 2754 may be selected. As shown there, S9 is communicating with both GS1 and GS3 at time step t0. Similarly, ISLs may also be selected (2752) for each time slot. UEs that provide coverage to 2750 can also be calculated in the link state space matrix. In Figure 27, for example, UE1 and UE2 are provided with coverage by S1, which is a beamforming satellite within base station 1, which is a static polygon.For each mesh 2758, the base station link budget forecast is from resource block RB12760 to RB. n It can extend to any bandwidth up to 2768. Similarly, the ISL and GS link budget 2762 can extend to the possible frequencies for each link 2764 through 2766. The ISL, GSL, and base station links can be evaluated for SINR, RSSI, data rate, latency, Doppler shift, etc.

[0377] Figure 28 shows how the link state space matrix from Figure 27 may appear in a space network in Earth's coordinate system. In this figure, each base station coverage polygon may be denoted as "eNB," but in the following description, it will simply be referred to as "base station" (for example, base station 5 is eNB5). 10 2804 may be located on GEO orbit 2802, and S92814 may be located on MEO orbit 2806. A base station providing coverage to UE may be located on LEO orbit 2822. S12816 may be a beamforming satellite providing coverage to Hawaii Island via base station 1, which is serving UE12818 and UE2. S52808 may be a non-beamforming satellite providing coverage to UE3 and UE4 via base station 5 in Western Canada. ISLs 2810 and 2820 and GSL 2812 may be located between LEO, MEO and GEO and GS 2824. As a result, in this scenario, traffic is from UE1 to S1, then to S2, then to S3, then to S4, then to S5, and S 10 It can then be routed to GS2, then to GS1 via the internet, then to S9, then to S8, and finally to UE5. [G. State-Space Database]

[0378] The network state space prediction engine generates a three-dimensional cell array or logical equivalent of matrices / vectors that effectively defines which transmitters and receivers are talking to each other on the primary route at each future point in time, and which transmitters and receivers will be talking to each other as backups to the primary route at each future point in time. Based on this result, the IP routing table generation process can be used to route traffic from one node to another in the network at each point in time. As the connections between transmitters and receivers across base station links, ISLs, and GSLs are handed over and change, the IP routing table process can generate updated, optimal routing.

[0379] To realize the desired network state space generated by the network state space prediction engine, in addition to the simulation, another cell array of matrices / vectors may be generated that defines the commands or time-based operational paths that each individual satellite can acquire in time, in order to properly launch an optimized state space. This new 3D cell array can be stored as a state space database.

[0380] The state-space (SS) database includes a set of processes that reflect the operation or intelligence about network states / operating conditions. The first of these processes may be a spacecraft process. This may be a three-dimensional cell array of vectors or matrices representing the operation of the spacecraft beam (e.g., beamforming direction), thruster utilization (e.g., thruster operation for orbit maintenance), attitude control and pointing (e.g., time-dependent control or operation of the spacecraft orientation) and / or operating power modes. Processes may also exist for the core network and base stations on each spacecraft. These processes may include a network dynamic IP routing table, network-level handovers for IP bearers established through tunnels between satellites and ground stations, base station front-end configurations (e.g., which bandwidths are being used), power control (e.g., which EIRP limits are being used), dynamic master information block and system information block information configurations, base station handovers, spectral analyzer control, and digital signal processing analysis.

[0381] The state-space database can be distributed across the network via inter-satellite link tunnels and ground station link tunnels on specific bearers for network distribution of the state-space database. This bearer may be part of the TTCC&DH tunnel bearer. As an IPv6 network, each static IP address assigned to a satellite can be used to transmit a unique packet containing the necessary information from the state-space database. This may be only its own state-space database sliver, and a satellite state-space database sliver intended to link with it in the future, or to back up (perhaps even a backup of the backup) for future links in the event of an anomaly or failure of a network satellite between the predicted time and the actual time. To provide automatic feedback for the state-space prediction engine, telemetry monitoring of spacecraft health and operability is implemented in the TTCC&DH system. As new information about satellite position, velocity, and attitude comes in, other essential system function information (e.g., thrusters, batteries, transmitters, computers, etc.) comes down from the space network to the ground nodes performing many calculations. The predictor can update the future network state space and send out new state-space vectors.

[0382] In real time, each satellite attempting to perform a planned connection or handover during its journey and failing can be programmed to check the second-highest priority link in the network if the first one is not functioning. Thus, there may be some delay in updating the state-space database before the network is negatively affected.

[0383] Figure 29 shows a network state space database that may contain three sets of paths. Spacecraft path 2902 may include spacecraft beam operation 2904, thruster utilization / operation 2906, attitude CONOP and control 2908, and operating power mode 2910. Core path 2912 may also exist. Core path may include network dynamic IP routing table 2914, spot beam, satellite, ground gateway, and UE handover 2916. Additionally, radio access network path 2918 may exist. These may include base station frontend / power configuration 2920, base station radio resource control 2922, downlink control channel configuration 2924, base station handover 2926, and spectrum analyzer control 2928.

[0384] The paths generated by the state-space prediction engine can be generated over any feasible timeline that the simulation environment can accurately model. In particular, modeling of orbital mechanics and attitude dynamics can drive the fidelity of network state-space predictions (e.g., with respect to position, velocity, attitude, and attitude rate), which is as precise as when more precise force models (e.g., gravity, atmosphere, magnetism, etc.) are used in the simulation. Low Earth orbit trajectories may be a limiter, but they can still be accurately predicted for the next hour, 12 hours, 24 hours, days, or even a week. This means that the network state space can also be predicted for this much longer into the future.

[0385] In a world where rapid, low-cost launches and access to space are the norm, there may be applications for implementing controllers that analyze rocket launch opportunities and the following weeks based on network state-space prediction results, for example, to support the launch of additional space assets into orbit to meet growing demands. [H. Network Handover]

[0386] The network state-space prediction engine can generate handover paths for each orbiting object in the network. These handover paths can be triggered by timers signaling the transfer of ownership of both ISL and GS tunnels, as well as base station coverage polygons. The timing of the handover can be determined by a link state-space predictor in the extended MME. The handover may be specified at a particular time and may be accompanied by paths to slowly build up or slowly degrade the beam's transmission power.

[0387] The network can implement several handovers in a somewhat conventional manner. This may be application-specific when individual satellites operate as a set of base stations, and therefore rapid and seamless handovers between beams shared on the same satellite can be performed by internally providing coverage to the same UE. These handovers can be performed within software on the same computer, or between two computers on the same satellite running the base station software. However, handovers between satellites can be more complex. If satellites without beamforming arrays have overlapping beams, they can use the overlapping portion as the area to which the UE is handed over. This may be done with typical UE signal measurement reports returned to the base station, or it may be done automatically based on known network movement over time and the known position of the UE in GPS coordinates at the time of handover.

[0388] Figure 30 illustrates how the network may hand over coverage of static base station polygons represented by a mesh within the CLR. A first satellite 3004 may be providing coverage to UE1, UE2, and UE3 (3010, 3012, and 3014). Coverage may, in some cases, be provided by beam-covered static base station polygon 3016. There may be a second trailing or nearby satellite 3002 orbiting toward the static base station polygon. After some time, the first satellite may need to hand over the cell to the second satellite. Perhaps through the ISL or some other network tunnel route (e.g., through the GS), the second satellite may begin transmitting through the static cell covered by the first satellite. This second satellite may generate beam 3006, but the first satellite begins reducing the transmission power of its beam 3008. The first satellite reduces its beam size 3022 so that it can start with the UE furthest from the center of the static polygon (e.g., UE1 in Figure 30) and progressively hand over each UE in its spot beam to the second satellite beam 3020. This allows the first satellite to hand over the UEs to the second satellite in a manner that may result in a smoother transition / handover, potentially reducing network signaling traffic challenges. A third satellite 3018 may be present following the second satellite, ready to perform another handover of the static base station cell. Finally, the second satellite no longer needs to have a coverage beam and resumes control of the static base station coverage cell 3024. The second satellite also prepares to perform a handover.

[0389] The embodiment described in Figure 30 may be particularly useful when S1, S2, and S3 all utilize the same six central RBs for the downlink control channel, and when the UE distinguishes satellite base stations based on cell ID. When the UE detects a change in the relative signal energy level from one base station that is operating at a lower signal energy level than another base station, it reports this to the base station it is currently communicating with. This then sends a handover to the next base station with a better signal. This process may also be initiated automatically by the first satellite that needs to hand over. The power reduction of the first satellite on the static polygon may not be due to active power control at the transmitter on the satellite, but rather a natural result of moving further away from the static polygon.

[0390] Figure 31 illustrates how a handover can occur between a satellite with beamforming base station antenna technology and a satellite without beamforming base station antenna technology. This technology would be beneficial because space networks are progressively upgraded from satellites with non-beamforming satellites to those with beamforming arrays. As a result, both exist. The first beamforming satellite 3104 can provide coverage to UE1, UE2, and UE3 (3110, 3112, 3114) using beam 3108. The second non-beamforming satellite 3102 may be following the first satellite and moving towards its static base station coverage polygon transmitting beam 3106. After some time, the beam 3116 of the second satellite may begin to overlap with the static base station coverage polygon 3120. The first satellite can perceive this from its ISL connection or state-space predictor, and reduces its own transmission power, shifting beam 3118 to the front edge away from the second satellite beam (which it would know due to its state-space database). As the first satellite remains above static base station polygon 3128, it slowly reduces beam power 3126, handing over the UE to the second satellite beam 3124. In this diagram, UE3 is the first to be handed over. As the beam is reduced, it can maintain the required UE coverage until the handover occurs by continuing to shift incrementally.

[0391] Additionally, a third satellite 3122 (beamforming type) may be present behind the second satellite. Ultimately, the beam of the first beamforming satellite will be depleted, and the second satellite will have nearly complete coverage of the static polygon 3132 using the dynamic beam 3134. However, the third satellite may begin transmitting beam 3130. The transmission is planned to begin at the backend of the second satellite beam, slowly increase into the static base station polygon coverage zone, and take over control of the UE's coverage.

[0392] Figure 32 illustrates how the network may transition the use of the spectrum in a given licensed area. These non-beamforming satellites 3202 may generate a beam 3204 that covers dynamic polygons. There may be an approaching boundary 3206 over which the satellite cannot transmit on a particular frequency. Eventually, the satellite spot beam reaches boundary 3208. As the satellite continues to move, it reduces the transmission power of beam 3212 to ensure that it does not radiate interference energy across the boundary. If radiating normal power, the beam may provide coverage beyond boundary 3210. As the satellite moves further closer to the boundary, the spot beam 3214 is further reduced until the proximity of the boundary completely prevents transmission by the satellite.

[0393] In another embodiment, the satellite may rotate its attitude to return and to continue providing coverage on the correct side of the boundary. Any embodiment in which the spot beam is modified to correspond to the boundary edge via attitude, transmission power, or some other method is related to the present invention. [I. Expandable Base Station]

[0394] Enhanced base stations can offer several improvements over standard base stations, enabling more optimal operation in space as part of a space network.

[0395] Figure 33 shows an embodiment of the extended base station 3306. The extended MME 3304 may interface with the base station through a standard S1-CP interface. However, the base station may operate additional functions called a base station state-space controller 3308. The state-space controller may receive commands and process operations from the extended MME to properly operate the base station stack. In particular, the base station state-space controller may pass specific MAC and PHY control signals 3334 to the RRC. The RRC may be extended to enable extended MAC control 3322 and extended PHY control 3324 so that the air interface can manage Doppler shift and propagation delay over the base station LTE-Uu link to the UE. The extended base station stack may include an extended PHY 3318 for receiving extended commands, an extended MAC 3316, a radio link control layer 3314, a packet data convergence control layer 3312, and a connection to the user plane to a standard S-GW 3302. The base station state-space controller may be programmed to dynamically control the RF front-end / beamformer 3320 (3330). This may involve steering the beam during overpass and / or switching to various filter banks, LNA stages and amplifier stages so that the base station can transmit and receive in the desired frequency band over its location in the world.

[0396] Furthermore, the base station state-space controller may control DSP functions (3326). The extended MME base station may include a receiver-dedicated front-end 3332 to support spectral analysis functions. A layer 1 signal processing block 3328 may also be present, used to filter or sample desired RF. The sampling results may generate I and Q from the RF sample, which can be passed to the DSP block 3310. The DSP block may be controlled by the base station state-space controller, and the analysis results may be returned from the DSP block to it. This information may be returned to the extended MME for network mobility management functions (such as tracking UEs based on Doppler shift and delay measurements). The base station state-space controller may also function as a stand-in scheduler for the base station, effectively implementing the dynamic control required for the amount of spectral slice and spectral sharing of satellite and ground cells based on the output of the state-space prediction engine. [I.1 Enhanced MAC and Enhanced PHY]

[0397] Extended MAC and PHY layers modifying a typical 3GPP base station protocol may be as described in Speidel I. While the extensions described there may be common to the operation of a satellite platform, they may have configurational differences depending on which portion of the satellite's field of view is provided for coverage. Dynamic changes in frequency (and therefore different Doppler cell contours depending on the operating region) and beamforming antenna (and therefore dynamic ranging between the nearest and farthest targets, as well as absolute Doppler shift across the spot beam) may be implemented for extensions to MAC and PHY control.

[0398] Based on state-space predictions and paths arising from the extended MME, the base station can accept dynamic control as described in Speidel I. This dynamic configuration can be controlled by a base station state-space controller that effectively functions as a base station scheduler.

[0399] As defined in Speidel I, the Doppler shift of signals from the UE to the orbiting base station can be monitored for Doppler shift and propagation delay without specific implementation of the UE's functionality. The Doppler shift and propagation delay can be measured in the PHY and fed back to the base station state-space controller. This allows the satellite to position the UE inside one of two smaller grids inside the entire satellite footprint. The positions of these grids may be symmetrical with respect to a vector defining the satellite's velocity vector. As measurements of Doppler shift and propagation delay become increasingly accurate, the size of this grid may converge to two single points. If the satellite footprint contains more than one spot beam, the spot beam used to communicate with the device can be used as information to break the connection of where the UE is located at its approximate GPS position. This can be calculated because the GPS position of the base station in orbit may be known, and the vector representing the user's position relative to the satellite velocity vector is known. Using this information, the GPS position of the device can be calculated. This GPS position can be stored as a further element within the VLR or HSS used by the MME within the space-based network.

[0400] If the satellite footprint includes one spot beam, the precise position can be calculated based on a second Doppler propagation delay sample from another satellite orbiting above the UE in a slightly different geometry, as described herein. [I.2 Spectral Analysis Function]

[0401] The spectral analysis function on the extended base station includes further elements: DSP3310, layer 1 signal processing 3328, and receiver front-end 3332. Together, these elements may be configured to generate a dataset that can be returned to the extended MME via the base station state-space controller to inform the extended MME of an interference table 1914 for link budget calculation. The receiver front-end may be configured to focus on a specific target band and may be similar to the front-end used by the base station PHY. The front-end may be responsible for filtering and low-noise amplification of signals across several target resource blocks. Layer 1 signal processing may perform A / D conversion and digital filtering of signals. This may involve an FPGA that can be reprogrammed or reconfigured by the base station state-space controller.

[0402] The digitally filtered signal may be I and Q from an RF sample obtained from Layer 1 signal processing, which can be returned to a DSP block for further processing. If a spectrum analyzer front-end is used to digitally sample I and Q from a spectrum reaching a 20 MHz block of spectrum at 16-bit resolution, the spectrum analyzer front-end may need to sample at a rate of at least twice the bandwidth or higher (e.g., 40 MHz). Since the data does not necessarily need to be demodulated at a certain bit rate, the sampling rate can be reduced in some embodiments when performing spectrum analysis. At this rate, a 10 ms sample of a 20 MHz LTE uplink block (e.g., 1 LTE radio time frame) would generate 1.6 megabytes (MB) before any packet overhead or packet compression procedures. If left to sample continuously, the spectrum analyzer could generate data at a rate of 1.28 gigabits. This may or may not exceed the spacecraft's ability to downlink raw data at a rate faster than it can sample and record the data before filling memory, data buffers, etc. As a result, especially in the early stages of constellation deployment, digital signal processing and compression algorithms may be desired, or even necessary, to manage the size of spectral analysis data. This is the reason for the DSP block.

[0403] This block may implement algorithms for reducing the size of collected data by computationally or computationally intensively generating a smaller numerical dataset to be used as a viable intelligence within a state-space prediction engine. For example, a DSP block may perform an FFT over time slots on a particular resource block to evaluate the interference margin (expressed in dB) above the expected noise floor on a 180 kHz resource block. The interference may be evaluated over time windows and resource blocks and may be time-tagged so that it can be returned as a matrix of numbers representing the interference environment on a particular frequency channel at a given time point.

[0404] The spectral analysis function can also be used as a support function for the placement of UEs on the network. During the operation of the state-space prediction engine, there may be processes generated for base stations that require beam direction and to function as receivers only for static polygons covered by another base station (either beamforming or non-beamforming).

[0405] The first base station may be scheduled to provide coverage to a static polygon. During this coverage, the first base station will communicate with the UE via the LTE-Uu interface as part of its normal orbital base station capabilities. The second base station may be scheduled to perform a receive-only operation for the static polygon. The first and second receive-only base stations may operate in different orbits, or possibly behind each other in the same orbital plane. These two base stations may be connected to each other via the ISL or the GSL. These links may be used by the first base station to transmit framing / timing information to the second base station so that the second base station knows where to scan frequencies and when to receive control channels or traffic channels, signals from the UE intended for the first base station. If no intersatellite or ground station links exist, the second receive-only base station may have a path. In this process, the RF spectrum is received over a certain time frame, and the raw I and Q timestamps are recorded at the first base station so that they can be post-processed later after the timestamp of the uplink signal from the UE (e.g., from a log file stored in a historical network state space database) has been obtained. Based on the RF from the UE received at both satellites, the Doppler shift, propagation delay (or variability between them), and GPS position of each base station at each measurement point may be used to calculate the position of the UE in GPS coordinates. [I.3 Base Station State Space Controller]

[0406] The base station state-space controller is a central orchestrator for base station expansion. The base station state-space controller receives information about RAN paths from the expanded MME and uses this information to coordinate operations between base station eNBs. This may include base station front-end / power control and configuration, base station radio resource control, downlink control channel configuration, handover between eNBs on satellites and eNBs on other satellites, and spectrum analyzer control. In addition to receiving path data, the base station state-space controller also reports back to the expanded MME data on Doppler shift and UE propagation delay measurements so that their positions can be calculated. The base station state-space controller also reports back the results of DSP analysis for notification to the interference database 1914. [I.3.a PSS, SSS, and Cell ID]

[0407] The UE's initial access to the base station begins with synchronization to the downlink base station's slot and frame timing using a synchronization signal transmitted by the base station over the downlink control channel. The primary radio frame synchronization channel (P-SCH) and secondary symbol synchronization channel (S-SCH) use six central resource blocks every 5ms within a frequency band (1.08MHz) dedicated to the transmission of the primary synchronization signal (PSS) and secondary synchronization signal (SSS). The PSS is one of a set of three length-62 Zadoff-Chu sequences known to the UE (one of which is the zero subcarrier in DC). At only one point in time, the UE cell lookup / synchronization signal correlator indicates that the periodically shifted sequence is correctly synchronized with the PSS timing reference signal. The SSS is generated from a pair of m known sequence offsets according to cell group IDs [0,...,167] and sector IDs [0,1,2] that logically and correctly form a physical cell ID together. As a result, there can be a total of 168 × 3 = 504 unique cell IDs. Furthermore, these synchronization signals help the UE identify a particular cell from among other cells that share these six central RBs within the frequency band. In 4G LTE terminology, the 9-bit cell ID is encoded within a code sequence that identifies cells in the radio network and forms the synchronization signal.

[0408] The UE ultimately decodes the information provided to the UE on other downlink control channels, such as the Physical Broadcast Control Channel (PBCCH), by using a reference signal to determine downlink control information and CRC checks. This decoded information consists of the Master Information Block (MIB), SIB1, and SIB2. SIB1 is identical to SIB2 in terms of decoding. This informs the UE of the location of the initial uplink transmission (e.g., frequency block and timing).

[0409] One or more UEs transmit a preamble over a physical random access channel (PRACH) after synchronizing with the downlink channel. The PRACH procedure includes a conflict resolution procedure in case of conflicts between transmissions of the same preamble by UEs within the same time slot.

[0410] The space station shares the spectrum with the ground network but uses the same six central RBs or 1.08 MHz frequencies as the ground eNB tower cells. The space station may have existing knowledge of which resource blocks are treated as control blocks and which other resource blocks cannot be used as control blocks. Furthermore, since there are 504 cell ID options in the network, the space network can be allocated only a finite number of them, ideally greater than 4. This allows frequency reuse patterns to be used between non-beamforming satellite coverage areas. If there are fewer satellites where overlap is less common, fewer cell IDs can be allocated to the space network. These cell IDs may, in some cases, be dynamic over time in orbit, and the process will be implemented by a state-space controller within the station.

[0411] Additionally, the network will allocate only specific resource blocks based on the spectral slice between the satellite network and the ground network. Thus, satellite base stations will be allocated specific resource blocks, time slots, or zones of resource blocks and time slots, and ground towers will be programmed / controlled to share them if the use of those resource blocks or zones of resource blocks is hindered or if the space base stations are operating them within a distance that would cause interference with ground eNBs.

[0412] The space-based communication systems described in this disclosure are best implemented as extensions of existing mobile terrestrial networks. Examples of their core and RAN elements are hosted on space-based infrastructure to extend their terrestrial coverage, but using the same spectrum as their terrestrial coverage for the same devices, thereby enabling them to behave appropriately with existing terrestrial spectrum / waveform deployments. In this scenario, these n resource blocks and PSS / SSS signals or cell IDs may need to be coordinated with the terrestrial MNO. They may be coordinated dynamically. The MNO can digitally notify the space network NOC of changes in requirements such as policies, QoS, etc., for polygons that may be part of the mesh. As a result, this would be implemented in the extended MME for future state-space predictions and path generations. Accordingly, base stations would communicate via air interfaces using state-space controllers within the base stations. [I.3.b Tracking Area Code]

[0413] One of the most important elements of the RAN process is the downlink control channel configuration, because it can be used to trigger specific behaviors in the UE, which the network may want to control in a particular manner. A specific example of an important downlink control channel configuration is the tracking area code.

[0414] In a space network, base stations may operate on LEOs and via rapid overpass windows between satellites and UEs. Typically, in a cellular network, the location of an UE is tracked based on a tracking area logged to the HSS. Generally, a location logged to the HSS is an address within a specific tracking area, with coverage provided by a specific base station or a set of base stations. Therefore, a cellular network, when operating within the network, will only track the specific cell in which a user resides and will not have a precise location (a user could be anywhere within a large 35km cell or a group of 35km cells). A cellular network may not be able to place a user within a fidelity better than that of a state or county.

[0415] A satellite network may have satellites that overpass the UE every few minutes (perhaps every 1, 5, 10, 30, or 60 minutes) depending on the relative positions of the satellites in their orbits. If all satellites in the network are operated as network inboxes and hosted by their own MMEs and S-GWs, the UE will sense a change in the network tracking area each time a new satellite provides an overpass. As a result, the UE will update its position relative to the HSS with each single overpass (e.g., every few minutes). This will generate a lot of relatively useless control signaling overhead for the network, because from the network's perspective, the devices are really moving very little, or even not moving at all.

[0416] As a result, satellites may need to maintain a network-consistent appearance relative to the ground. Since the ground users are not moving, the space network would inform the users that it has not changed its position so that update requests are not made if it is redundant.

[0417] When a base station transmits on a downlink control channel, it transmits a tracking area code in SIB1, which the UE uses to determine whether it has received the data and whether its tracking area has changed, and whether a tracking area update is necessary. Other triggers mentioned earlier exist that trigger the tracking area update procedure on the network. This can be used to spoof the UE into believing that it has not changed its tracking area on the network, even if it is communicating with a new MME each time a new satellite flies low to serve the UE.

[0418] As explained above, within an extended MME, there may be software that predicts network conditions and develops network operation routes based on those predicted conditions. This network, as an IPv6 network, could cause each flight computer and each satellite within the network to operate with its own (possibly even static) IP address. As a result, it can distinguish differences within the MME and which MME (or satellite) is providing coverage to each UE at any given time. Depending on the satellite's position (and potentially which static polygon it is providing coverage to at any given time), the MIB and SIB information may differ. This can be stored in the CLR, where the mesh is notified, along with the SIB and MIB information that aligns with the tracking area design implementation around the Earth.

[0419] In one embodiment, all satellites, together with base stations in the satellite constellation network, may transmit the same 16-bit tracking area code for the SIB-1 block over the downlink control channel. Each satellite base station may have a different cell ID and other downlink control information, but in this way, the UE would not sense a change in position with each satellite overpass, nor would it use spectrum on the uplink (on the ground or on the satellite or another satellite) to access the network and perform tracking area updates with the HSS. From the perspective of the ground HSS, and possibly from the perspective of the UE home network, the device's location can be sensed as "on the space network," so if access to the UE is needed, there is no need to manage which satellite should transmit the traffic. Instead, it is only necessary to know that the UE is on an MME that is sensed as the "space network," and the traffic will be routed to the MME in the space network corresponding to the central / home ground station. This node may have an extended HSS and an extended MME. Together, these can predict, manage, and store the actual location of the UE in the network (e.g., which satellites are expected to provide coverage to it) both now and in the future. As a result, the space network can intelligently determine which satellite base stations are suitable for delivering traffic and which routes are optimal for getting traffic to them (e.g., the fastest routes around the network, the most balanced traffic load, etc.). [I.3.c Mobile Country Code and Mobile Network Code]

[0420] The space network could be implemented to broadcast the mobile country codes or mobile network codes of its partner operators. Alternatively, the space network could be assigned its own unique mobile country codes and mobile network codes for use across the globe. [J. Extended HSS]

[0421] The procedures and functions of database management within a space network can be particularly important when the network is configured to operate in orbit. For example, the HSS is used for user placement, user authentication, user billing, and service provision, and is classically located away from the BTS and BSC functions in the ground network. Often, the presence of the HLR is limited to only a few locations within the network because the validity of its "state" is crucial for proper network functionality. While service provision and billing can be completed in orbit, these functions are not always necessary and may remain on the ground in classical implementations. However, since space networks may include LEO satellites, the interaction time between a mobile device and a specific base station it communicates with within the space network can be limited to a very short window (perhaps a few minutes or less depending on the satellite orbit configuration, link budget, and coverage footprint design, with UEs included in spot beams, etc.).

[0422] As defined in Speidel I and briefly described herein, signals from the UE to the orbiting base station may be monitored for Doppler shift and propagation delay to determine the GPS position of the UE. As a result, the state-space prediction engine can easily determine exactly which beams of exactly which satellites are planned to provide coverage to the UE in the future. This information may be stored in the HSS as an extension of the state-space database. A standard HSS may be stored so that queries can be made to it as a matter of course. However, there may be a separate function that checks the clock and the latest state-space database for the network and updates the fields in the HSS of each IMSI under its provision. This HSS database may reside within the space network and may be treated not as a master, but simply as a “check” for an example, when the network needs to access its UE in particular. A master HSS for a UE may be maintained on the ground and may be treated as the master HSS to which each query of that UE is first directed. When the “space network” is determined to be currently serving or has last served a UE, traffic may be routed to ground nodes within the “space network”. Next, it can determine which satellite routes network traffic based on this internal network mapping of tracking area codes over time. [J.1 Authentication Strategy]

[0423] If authentication and network access permission procedures are performed via the ISL and can then be returned to the ground to bounce queries to the HSS on the ground home network, the process can extend beyond any single overpass time. If the constellation is designed for ubiquitous coverage, the response procedure can be returned to the ground user via the next satellite overpassing it. If authentication takes longer than the overpass period, the network can complete the authentication procedure by calculating which satellite in the network might be the next available satellite. This can allow for an authentication handover to manage the authentication procedure using a device while it moves from one connection session to another with a different satellite before the procedure is completed. [J.1.a On-orbit repeater for centralized ISL to support rapid authentication]

[0424] In the case of a fully ubiquitous system, and also in the case of a small group of distributed cellular nodes, the following techniques can be used. [J.1.a(i) GEO repeaters, MEO repeaters, and LEO repeaters as P-GW extensions]

[0425] Orbital transponders can be used as "always unidirectional" intersatellite links from satellites on LEO (or by providing an air interface to ground-based UEs) to P-GWs in the ground network. Each satellite "network inbox" is communicated with an orbital transponder P-GW (or simply a bent pipe or transponder to a ground-based P-GW). In this case, the P-GW may operate in higher orbits, possibly LEO, MEO, or GEO or further away. The use of additional satellite transponders allows for greater ground visibility and fewer ground stations may be required for the transponder's global coverage. Using this technique, all satellites in the LEO network would have access to ground station gateways and from there to the ground cellular network via communication links with latency of up to 250ms (250ms is the speed of light latency for downlink from LEO satellites to GEO satellites and to ground stations).

[0426] The unidirectional voice latency requirement of 200-300ms may be compromised by this relay link because this calculation does not include processing or latency through the ground network after hitting the ground station and before transmission to the ground core network. However, these latency requirements are more than satisfactory for messaging and data services.

[0427] In a continuous connection to the ground using GEO, the orbital transponder can utilize four P-GW nodes, i.e., P-GW transponders, in the GEO orbit. [J.1.a(ii) Repeater as MME / S-GW for network]

[0428] Alternatively, the orbital transponder may house the entire core network and function as an MME / S-GW node (holding VLR and HSS) for the entire LEO system, in which case it would have base station satellites. This could reduce the complexity of many satellites within the LEO, and allow heavier core network functions to be shifted to fewer, more capable, and longer-lived satellites in higher orbits.

[0429] In both cases using orbital repeaters, the ground station locations may be selected to be in very close proximity to, or at the same location as, the HSS databases of various roaming partner networks. Specifically, the HSS databases of various roaming partners may be stored in high-orbit satellites so that they can be easily stored and accessed from any satellite. This may even be offered as a service to allow MNOs to have more optimal service from space-based networks to subscribers in remote areas that are not reachable by those ground networks. For relay links, a downlink location closer to the ground allows authentication queries to be completed more quickly, and links through slower connections such as SS7 may be avoided. [J.1.b HSS Authentication Cache]

[0430] The following is general regarding orbital configurations. In other words, this implementation can be used via a single LEO network or within a network with further relay satellites. A space-based cellular network with on-orbit HSS and / or VLR may be involved.

[0431] Typical roaming authentication involves a visiting network that queries the home network HSS to gather the necessary authentication information each time the UE can authenticate. Generally, this happens each time a visiting subscriber roams onto a network that is not their own. Theoretically, the visiting network can cache the query results in the home HSS and store the authentication information for its IMSI in a database. Since the authentication information is cached, after the initial successful authentication procedure against the home network HSS, authentication can then occur in orbit via the stored satellite HSS. Thus, handover technology can be used first to obtain the IMSI through the initial authentication procedure via the ground. Subsequent attempts may rely on the on-orbit database for rapid authentication.

[0432] If an IMSI authorized to use the satellite network is known in advance or over time, the authentication procedure can be spoofed against the home network HSS before the initial query from the device. Thus, the query result ("authentication vector") can be cached and stored in the on-orbit HSS and AuC database before the initial authentication procedure is performed. In this way, all authentication procedures can be performed on-orbit via the HSS-AuC containing the necessary AuC information. [J.1.c Certified Spoofing]

[0433] If the entire connection session to the ground is avoided, the network may also spoof the authentication process. In other words, many users attempting to authenticate to the network complete the authentication procedure with the base station. However, the space network may use computed or stored "dummy" authentication vector values ​​(as if queried from the HSS) and pass them to the UE. The result of the authentication procedure using these authentication vector values ​​may enable device authentication to the network, and the network only needs to know to enable user authentication based on the IMSI. [J.1.d On-orbit Authentication]

[0434] The space network may use a complete HSS database for users supplied with services to be used by each satellite. In this configuration, the space network may actually be the home network and may actually store the UE keys. Thus, when a user attempts to authenticate to the network, the satellite does not have to use an inter-satellite link or a feeder link to the ground, but can simply query the on-orbit database to gather the necessary authentication vectors (from AuC) and complete the authentication in a rapid manner (less than a few seconds) and within a given overpass time for the user. [K. Application server / IMS core to be installed on the satellite]

[0435] A description of how to operate an example of an application server on a satellite to function as a rapid IP bearer generator for storing and forwarding IP packets between two examples of application layers within a PDN server.

[0436] Intermittent connectivity may exist in some phases of the constellation configuration described earlier. In this connectivity, a remote UE has access to communicate with a satellite base station, but that satellite base station does not yet have access to the ground network, which is where the application server or IMS server can be accessed. As a result, the possibility of using applications that require internet access or backend support may be eliminated, as it becomes difficult or impossible to move IP traffic between the application server and the mobile device. Even in scenarios where the satellite does not have access to the ground, it may require latency between the UE and the target PDN server, which may be momentary or insufficient for useful data transmission between the UE and the PDN server.

[0437] A possible solution to this problem would be satellites within a constellation network, hosting a light version of the server-side code, allowing communications to be handled in a temporarily sufficient state for the UE to load the application, and enabling data to be requested from the server without timeouts or application loading failures. The satellite constellation could host computers and memory for use as virtualized copies, caches, or mirrors of "popular" servers that users access on the internet. The computers and memory may even be dedicated solely to this function and may be sold or leased to companies that manage websites or applications and wish to promote the use or access of those services or websites to users worldwide. For example, a popular website running a server in one country may see increasing demand in other countries. This is so true that more local examples of the server are needed to alleviate network bottlenecks and reduce DNS traffic on home servers. By placing cached copies of them in orbit, their physical propagation around the world would enable more readily available access to the data needed by remote users far from the original server. These cached or mirrored copies of the original server can function as "slave" copies, with the original server acting as the "master" and pushing updates to its "slave" copies. As a result, the server in orbit may be slightly "delayed" or have outdated data.

[0438] Furthermore, a light version of the application server or website server may be used on a trajectory capable of handling the acceptance of IP packets from the device (e.g., as WhatsApp messages from a remote UE). The IP packets may be stored and forwarded to a suitable ground application server where the data packets are received and the messages are unpacked for the intended recipients. Once the messages reach the server, they may be routed to the appropriate recipient UEs, just as they might be in a normal ground scenario. By running a light version of the server, it may be possible to virtualize it on hardware that is as small and low-power (compared to a real server hosting a "master" copy) as a single-board computer with a relatively simple processor and a small amount of memory.

[0439] When similar technology is used with the IMS core, it could enable IMS-based services such as RCS to operate at a state-of-the-art rate with an extended write architecture. [L. Extended User Equipment (UE)] [L.1 Extended Network Overpath Prediction]

[0440] To support functionality in a space-based cellular network, user devices can benefit from minor enhancements. The UE (User Environment) may, in some cases, be a point within a mesh of link state space calculated by an enhanced MME (Mechanism of Multi-State Engineering). As a result, the path of the handset on the network may also be generated.

[0441] Primarily based on a single GPS location, the UE can be programmed to calculate the next set of overpasses from a satellite using its own state-space prediction engine. Similarly, the paths of spacecraft, radio access, and core network developed by ground-based extended MMEs can define a set of coverages for which the UE will calculate an example of coverage for the current UE's GPS location. A state-space database for the space network (or its components based on device location) can be pushed to the UE for storage and use when outside of internet / server connectivity and access. The UE can also host network state-space propagation functions on its handset to perform calculations at the edges. When outside the coverage of a typical ground cell, the UE can modify its cell search criteria and simply know that an overpassing satellite may have passed it and provided coverage for the next 5 seconds, 10 minutes, 30 minutes, etc.

[0442] Satellite overpath prediction can be implemented at the application layer on the user interface side (e.g., a smartphone app). This would allow the application to predict satellite overpaths and facilitate the storage and transfer of data / messages / SMS sent between phones in a messaging application. The application would know to attempt to send that message at a specific time, and the software application could command the phone to do so. Additionally, the software application could toggle the smartphone's airplane mode. This would cause the phone to immediately enter scanning mode (e.g., effectively turning the device on and off) to find available networks.

[0443] Satellite overpath predictions can be provided by a process that also notifies the control plane between the UE and the network. For example, a typical search process for a mobile device UE may be modified to include a timer that checks the time for a provided process for the overpath. Based on the timer, the UE may implement a process to scan for PLMN codes and / or cell ID codes from orbiting base stations for a particular LTE ARFCN bandwidth, for example, if no other ground or orbiting base stations are available at that time. This can easily conserve battery power on the device, typically when outside of ground coverage, because it knows exactly when to start scanning for newly available network access from orbiting base stations. Furthermore, after connecting to an orbiting base station, there may be existing knowledge about how long the UE will have access to that satellite. Based on this period, the UE may determine which bidirectional communications are feasible and, perhaps, what priorities should be given to a given overpath. Furthermore, by this point, the itinerary may include information about the service level for a given overpass regarding wireless access technology (e.g., GSM or LTE), expected data rates, etc. This information can drive a device's decision on which applications / data to request / transmit to and from the network (for example, over GSM, SMS / low data-rate traffic that the device requests might be advantageous, while over LTE, applications with higher data-rate requirements might be advantageous).

[0444] The process provided by the enhanced MME may include specific timestamps indicating when a UE should request access to the space station network when it needs to establish a connection session with the network or backend server / PDN server. The timing described above may be provided to UEs so that planned network access request signals from UEs are time-duplexed and separated from each other, mitigating the potential issue of contention between UEs during immediate PRACH activity. The process may include which PRACH channels are available to a particular UE or even a set of UEs. Further control channel signaling may also be anticipated or automated for UE and tracking area updates, authentication, etc. [L.2 Extended Transmission Power]

[0445] The UE may also be extended to include increased transmission power for uplinks to base stations. The benefit of this disclosure is that while the UE may use standard transmission power at typical ground cell locations, it may be able to uplink to satellites at higher power than 200mW for LTE (and 2W for GSM) in remote areas without interfering towers.

[0446] Uplink transmission power can be triggered to be higher based on specific criteria such as the network's MCC and MNC codes (for example, if the network is a space-based network, to allow higher transmission power to support uplink closure). SIB and MIB blocks are often used to indicate to the UE what maximum transmission power is permitted for that cell. Space network base stations may be allowed higher transmission values ​​than ground cells, which can be scaled to the UE's understanding and response.

[0447] Existing UEs may be compatible with both GSM and LTE protocols. Thus, existing configurations may exist that can utilize the 2W peak transmission power allowed in GSM, which is used in LTE communications.

[0448] This could allow for link closure in high-attenuation environments. During disasters, when a device may experience a temporary power surge and require support for closing the link to an upper satellite, there may be a need for this in the protocol. [L.3 Antenna Expansion]

[0449] In addition to improving link budget conditions on satellites, circularly polarized antennas can be used in extended UEs. By using circularly polarized satellite signals, circularly polarized antennas can enable a 3dB increase in link margin (a reduction in polarization loss from 3dB to 0dB). This can be achieved by leveraging (ring-polarized) GPS antennas. Existing GPS antennas in mobile devices may not be tuned or matched well outside of GPS L-band frequencies, but new antennas compatible with both GPS L-band channels and near-band cellular frequencies (e.g., 700MHz, 800MHz, 900MHz, 1.8GHz, 1.9GHz, etc.) can be installed.

[0450] The addition of circular polarization antenna features can function despite the fact that ring-polarized signals can be degraded by multipath effects, as a single reflection may occur due to signal bounce that no longer yields the same polarization as the receiving antenna. As a result, the communication can become a significant link inhibitor because a single reflection is not easily received and the line of sight is lost. Multipath in terrestrial communications may rely on linearly polarized signals at multiple linearization angles to support the reception of one of these signals with off-angle polarization.

[0451] In ground systems, the horizontal geometry of the link relative to the tower typically prevents the line of sight from being available to the link; therefore, the link can be modeled as a link using Rayleigh fading (where bounce signals are dominant over the link). In satellite communications, the line of sight is often dominant over the link, and circularly polarized antennas can be particularly useful. In one embodiment, a circularly polarized antenna within the UE may be enabled for communication with the satellite and otherwise disabled. However, this antenna may be capable of receiving linear signals. [L.4 UE-Base Station Air Interface Protocol Extension]

[0452] Further extensions of UEs used on cellular networks may exist where more favorable link budget protocols can be used to support increased communication coverage between ground-based UEs and satellite base stations in orbit. This may also be done to support communication between satellites and UEs located inside buildings or under roofs, inside metal containers, etc. This may also be used to increase the communication distance with ground towers. At the heart of these protocols would be extended or modified waveforms, used between the UE and satellite base station to increase the power spectral density of the signal on the uplink, leverage some element of transmission diversity (e.g., frequency diversity or code diversity), or perhaps leverage further signal processing gains to capture signals from the UE and base station from the noise floor.

[0453] In orbiting base stations, using NB-IoT between the UE and the orbiting base station can provide a 20dB increase in the link budget by allowing the UE to transmit 200mW of signal power over only a single 15kHz subcarrier on the LTE protocol. By utilizing the existing LTE resource block structure, modifications to existing UE hardware that implement baseband waveforms can be implemented to support NB-IoT from the UE.

[0454] Embodiments may exist in which the NB-IoT protocol is used only on satellite networks. Alternatively, embodiments may exist in which the NB-IoT protocol is used only on the uplink to the satellite, but a different RF interface such as LTE is used for communication on the downlink (and sufficiently more power is used on the downlink to close the link only in that direction).

[0455] Further embodiments may exist in which a UE is extended by a protocol that leverages either an existing cellular band, a WiFi band (2.4 GHz), or an ISM band (902-928 MHz) to communicate using some coded or frequency-hopped signal to provide a mechanism for communicating with an UE under a fairly limited communication link (e.g., underground, inside a building, or in an area with significant RF interference) by spreading a low data rate signal over a certain bandwidth. [M. Explanation of alternative extensions]

[0456] There may be extended embodiments of the network described above. In this embodiment, the UE is equipped to communicate at higher frequencies, which are allocated in the Ka or Ku band for the 5G NR air interface. At these frequencies, antennas can be very small, especially when using satellite communications from orbit to the ground, but path loss can become too large.

[0457] In such scenarios, if transmission power is limited and antenna gain on the device is reduced, the UE may not be able to close the link on the uplink. However, the satellite may be large enough to communicate in the Ku or Ka band descending from orbit to the UE (without substantially more transmission power and possibly beamforming capabilities on the UE) rather than in other directions.

[0458] In this example, the communication network in this disclosure may implement asynchronous frequency communication operations. Low-frequency cellular bandwidth enables low data-rate uplinks for direct access from the UE to the orbiting eNB. On the uplink, devices may request access to high data-rate downlink services (such as seamless movie streaming or large datasets downloaded from the Internet). While eNBs in a satellite network may communicate bidirectionally with UEs in low-frequency cellular bandwidths, they can also be extended to provide the high data-rate requirements demanded by services by allocating a set of downlink resource blocks, carriers, time slots, etc., within orthogonal frequency bands (such as Ka-band or Ku-band) using their ability to provide high power and, in some cases, beamforming downlink signals to the UE.

[0459] The downlink satellite may even be a different spacecraft from the satellite base station that received the UE uplink signal. Depending on the characteristics of the link budget and the requirements for closure at the desired data rate, the downlink spacecraft may be deployed in a LEO, MEO, or GEO.

[0460] Embodiments of cellular space networks may exist for use cases where thin uplink channels are required to enable large downlink channels. For example, there may be a device on a vehicle, such as a car, that can receive high-throughput satellite downlink data (for entertainment) from a GEO. However, the vehicle may not have the means to transmit backups to the GEO satellite and control the downlink. A cellular modem may be used to connect the car to a thin uplink and send commands to perform a specific high-throughput downlink from the GEO.

[0461] According to one embodiment, the technology described herein is implemented by one or a generalized computing system programmed to execute the technology according to program instructions in firmware, memory, other storage, or a combination thereof. Dedicated computing devices may be used, such as desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices that integrate hardwired logic and / or program logic to implement the technology on an Earth-based platform or orbital platform. Various forms of media may be used to transport one or more sequences of one or more instructions to a processor for execution. For example, instructions may first be transported on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and transmit the instructions over a network connection.

[0462] Unless otherwise stated herein, or unless otherwise clearly contradicted by the context, the operations of the processes described herein may be performed in any suitable order. The processes described herein (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors by hardware or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program containing multiple instructions that can be executed by one or more processors. The computer-readable storage medium may be non-temporary.

[0463] Unless otherwise stated, or unless the context clearly contradicts it, connecting phrases such as “at least one of A, B, and C” or “at least one of A, B, and C” are generally understood in contexts where they would otherwise indicate that an item, term, etc., may be A, B, or C, and may be any non-empty subset of the set A, B, and C. For example, in the example of a set having three members, the connecting phrases “at least one of A, B, and C” and “at least one of A, B, and C” refer to any of the sets {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such connecting phrases are generally not intended to imply any particular embodiment that requires the presence of at least one of A, at least one of B, and at least one of C.

[0464] The use of any examples or illustrative language provided herein (e.g., "etc.") is intended solely to better illustrate embodiments of the invention and, unless otherwise asserted, does not impose any limitation on the scope of the invention. The language herein should not be construed as indicating that any non-claimed element is essential to the practice of the invention.

[0465] The embodiments of the present invention were described in the aforementioned specification with reference to numerous specific details that may vary from implementation to implementation. Therefore, this specification and the drawings should be considered illustrative rather than restrictive. The sole and exclusive indicator of the scope of the present invention, and what the applicant intends to be within the scope of the present invention, is the literal and equivalent scope of a set of claims arising from this application in any particular form that would result in such claims, including any subsequent amendments.

[0466] Those skilled in the art may envision further embodiments after reading this disclosure. In other embodiments, combinations or partial combinations of the inventions disclosed above may be advantageous. The exemplary arrangements of components are shown for illustrative purposes only, and it should be understood that combinations, additions, and rearrangements, etc., are envisioned in alternative embodiments of the invention. Thus, although the invention has been described in terms of exemplary embodiments, those skilled in the art will recognize that numerous modifications are possible.

[0467] For example, the processes described herein may be implemented using hardware components, software components, and / or any combination thereof. Therefore, this specification and the drawings should be considered illustrative, not restrictive. However, various modifications and alterations may be made to them without departing from the broader spirit and scope of the invention as described in the claims, and it will become clear that the invention is intended to encompass all modifications and equivalents of the following claims. [Example items]

[0468] Embodiments of this disclosure may be described with consideration to the following items.

[0469] [Item 1] A cellular network management system comprising: a first database table of first node records, wherein the first node record represents a ground base station and the first node record includes operational details of the ground base station; a second database table of second node records, wherein the second node record represents an orbital base station and the second node record includes operational details of the orbital base station; a state-space prediction computer that calculates link budgets for connections between base stations represented in the first database table and base stations represented in the second database table to form a network usage dataset; and a state-space database having a plurality of state-space records, at least some of which are derived from the network usage dataset, wherein some of the plurality of state-space records indicate, for a plurality of mesh points in a coverage area, which active base stations are providing link services in the coverage area and which deferred base stations are suspending their use of the shared protocol and the shared frequency band shared by the active base stations.

[0470] [Item 2] A cellular network management system as described in Item 1, wherein the deferred base stations suspend their use of the shared protocol based on the allocation of network resources, and the allocation of network resources is allocated to orbital base stations, thereby suspending their use without requiring the deferred base stations to be programmed to recognize the suspension request by excluding the allocated network resources.

[0471] [Item 3] A cellular network management system according to item 1 or 2, wherein the active base station includes at least one active orbit base station, the deferred base station includes at least one passive ground base station, and the at least one passive ground base station is in a passive state based on the network usage dataset when the at least one active orbit base station is expected to provide coverage for the coverage area.

[0472] [Item 4] The spatial prediction computer described above has logic for considering an Earth gravity model, an Earth atmospheric density model, a magnetic field model, a spacecraft function model, and / or an antenna radiation pattern model in predicting the future coverage of the above orbital base station, as described in any of items 1 to 3 of the cellular network management system.

[0473] [Item 5] A cellular network management system according to any one of items 1 to 4, further comprising a coverage database having mesh points and polygon coverage areas, wherein the polygon coverage areas are referenced in the coverage database for each base station, and each of the base stations includes at least some static coverage ground base stations, at least some static coverage orbit base stations using beamforming, and at least some dynamic coverage orbit base stations using dynamic beams that move across the coverage areas as the at least some dynamic coverage orbit base stations move along their respective orbits.

[0474] [Item 6] The above state-space database is a cellular network management system described in any of items 1 through 5, which takes into account coverage dynamics including emergencies, where coverage by orbital base stations would change based on the above emergency.

[0475] [Item 7] The above emergency includes a predicted natural disaster, and the above coverage dynamics include an increase in capacity within the area affected by the above predicted natural disaster, as described in Item 6 of the cellular network management system.

[0476] [Item 8] The above-mentioned emergencies include anticipated natural disasters, and the above-mentioned coverage dynamics include increased capacity within the area based on input data provided by the first responder, as described in item 6 of the cellular network management system.

[0477] [Item 9] A cellular network management system as described in any of items 1 through 8, further comprising handover logic for signaling an imminent handover of a link from a first orbital base station to a second orbital base station to user equipment using signals consistent with a terrestrial network handover protocol.

[0478] [Item 10] A cellular network management system according to any one of items 1 to 9, further comprising handover logic to maintain a tunneling data link between user equipment and a computer system located away from the cellular network managed by the cellular network management system, by signaling to user equipment an imminent handover of the connection to the tunneling link from a first orbital base station to a second orbital base station using signals consistent with a terrestrial network handover protocol.

[0479] [Item 11] A cellular network management system according to any one of items 1 to 10, further comprising authentication logic for authenticating a user equipment (UE) device to a cellular network using signals consistent with a terrestrial network handover protocol, and for maintaining the authentication of the UE device over a handover of a link from a first orbital base station to a second orbital base station.

[0480] [Item 12] The authentication logic described above is implemented in the authentication orbital base station, and the authentication is cached for use in the first orbital base station and / or the second orbital base station, according to the cellular network management system described in item 11.

[0481] [Item 13] A journey generator for use in a cellular network having multiple base stations, at least one of which is a ground base station and at least one of which is an orbital base station, comprising: a first generator for generating spacecraft journeys; a second generator for generating satellite function journeys; a state-space database for storing the spacecraft journeys and the satellite function journeys; a network planner computer that stores the static positions of base stations and outputs a coverage display indicating which orbital base stations provide coverage to which areas within a coverage area based on the state-space database; and a database distributor for distributing copies of the state-space database to each of the multiple spacecraft network nodes.

[0482] [Item 14] The journey generator according to item 13, further comprising a command and control system having logic for managing the state of orbital base stations, which communicates with the above-mentioned network planner computer and can be used to adjust the above-mentioned state space database in response to changes in state.

[0483] [Item 15] The above-mentioned orbital base station status includes one or more of temperature, power level, fuel level, processor health, and / or radio health, and the journey is adjusted based on the above-mentioned status, as described in item 14, for the journey generator.

[0484] [Item 16] The state space database described above has at least one backup path for use when the state conditions exclude the use of previously generated satellite function paths, as described in any of items 13 to 15 of the path generator.

[0485] [Item 17] The state-space database described above is a process generator described in any of items 13 to 16, having a process optimized based on one or more of a set of rules or quality of service requirements.

[0486] [Item 18] The above state-space database is a path generator according to any one of items 13 to 17, having paths calculated for ground stations or orbital elements within the above network.

[0487] [Item 19] A method for determining coverage for a cellular network, comprising the steps of: storing a database of a plurality of mesh points, each having a location within a coverage area and metadata about the services at that mesh point; storing a database of a plurality of coverage areas, each having a finite area and at least a number of polygon boundaries; allocating the plurality of mesh points to a coverage area over an allocated time, the coverage area changing over time based on the orbits of orbiting base stations; and controlling base stations to provide coverage to the allocated coverage area over the allocated time.

[0488] [Item 20] A method for controlling a mobility management entity, comprising the steps of: performing physical simulations of orbital mechanics, attitude dynamics and link budget to derive a set of future link states of a network managed by the mobility management entity; and determining a path for spacecraft operation, radio access network operation and core network operation based on the set of future link states.

[0489] [Item 21] A method for managing a plurality of orbital base stations communicating with a user equipment (UE) device of a cellular network, comprising the steps of: determining a first coverage area for a first orbital base station among the plurality of orbital base stations; determining a second coverage area for a second orbital base station among the plurality of orbital base stations; and determining a modification of a signal from the second orbital base station in the case where the first coverage area and the second coverage area overlap, wherein the modification includes a change in the signal which is programmed to trigger a handoff request to the first orbital base station by being interpreted as a loss of signal strength between fixed base stations.

[0490] [Item 22] The method according to item 21, further comprising the steps of:...

Claims

1. A network management computer system for use in a cellular network having a plurality of base stations, at least one of which is a ground base station and at least one is an orbital base station, wherein the network management computer system is A process generator for generating a plurality of processes used between the cellular network, wherein the process among the plurality of processes reflects information about operations performed over a period of time and / or the state of the network over the period of time, and the process is one or more of spacecraft processes related to a spacecraft having the orbital base station thereon, network processes related to the operation of the cellular network, and / or orbital base station processes related to the operation and / or state of the orbital base station, A state space database storing the aforementioned multiple processes, A network planner computer that stores the location of base stations based on the state-space database and outputs a coverage display showing which orbital base stations provide coverage to which areas within the coverage area, A database distributor that distributes copies of the state-space database to multiple spacecraft network nodes. A network management computer system equipped with the following features.

2. The network management computer system according to claim 1, wherein the location of the base station includes the location of an orbital base station and / or the location of a ground base station.

3. The network management computer system according to claim 1 or 2, wherein the base station's location has a static location and a dynamic location, the static location of an orbital base station indicates a location where a beam on the Earth's surface has a stationary footprint on the Earth's surface relative to the movement of the orbital base station in orbit, at least due to beam pointing, and the static location of a ground base station indicates a location where the ground base station is operating on the Earth's surface.

4. The network management computer system according to claim 3, wherein the static location of the base station indicates, based on the state-space database, which orbital base station is providing coverage to which region within the coverage area.

5. The aforementioned spacecraft process includes the operation of the spacecraft beam, the use / operation of thrusters, attitude control and control operations, and / or operating power modes. The aforementioned network process includes a network dynamic IP routing table and / or handover data representing one or more of the following: spot beam handover, satellite handover, ground gateway handover, and UE handover. The aforementioned orbital base station process represents one or more of the following: base station front-end / power configuration, base station radio resource control, downlink control channel configuration, base station handover schedule, and / or spectrum analyzer control. A network management computer system according to any one of claims 1 to 4.

6. The network management computer system according to any one of claims 1 to 5, further comprising a command and control system that communicates with the network planner computer, and includes logic for managing the state of orbital base stations which can be used to adjust the state space database in response to changes in state.

7. The network management computer system according to any one of claims 1 to 6, wherein the status of the orbital base station includes one or more of temperature, power level, fuel level, processor health and / or radio health, and the journey is adjusted based on the said status.

8. The aforementioned plurality of base stations have a plurality of orbital base stations, and the network management computer system is Determine the first coverage area for the first orbital base station among the plurality of orbital base stations, Determine the second coverage area for the second orbital base station among the aforementioned plurality of orbital base stations. Determine the correction of the signal from the second orbit base station when the first coverage area and the second coverage area overlap. A network management computer system according to any one of claims 1 to 7, configured such that the modification includes a change in the signal, and a user equipment (UE) device is programmed to trigger a request for a handoff to the first orbiting base station by interpreting the change in the signal as a loss of signal strength between stationary base stations.

9. The network management computer system according to claim 8, further configured to modify its signaling and issue commands to the second orbital base station to use the modified signals.

10. The aforementioned network management computer system is Generate multiple mesh points, each representing a location within the entire coverage area. Multiple polygons covering the aforementioned multiple mesh points are generated, The link budget is determined for a given mesh point among the aforementioned plurality of mesh points. A set of applicable wireless communication constraints is determined for the given mesh point. For each of a plurality of base station beams that coincide with a specific polygon having coverage of the given mesh points, the beam parameters are determined based on the set of applicable radio communication constraints for the given mesh points within the specific polygon. A network management computer system according to claim 8 or 9, further configured as follows.

11. The aforementioned network management computer system is Physical simulations are performed on the orbital mechanics, attitude dynamics, and link budget to derive a set of future link states for a network managed by the network management computer system. Based on the aforementioned set of future link states, determine at least some of the plurality of steps. A network management computer system according to any one of claims 1 to 10, configured as described above.

12. The network management computer system according to claim 11, further comprising a future state-space prediction function for performing the physical simulation which derives a set of future link states and determines the plurality of steps based on the set of future link states.

13. The network management computer system according to any one of claims 1 to 12, wherein the state space database includes at least one backup path for use when the state conditions exclude the use of a previously generated satellite function path.

14. The network management computer system according to any one of claims 1 to 13, wherein the state-space database includes a process optimized based on one or more of a set of rules or quality of service requirements.

15. The state-space database includes a process that takes into account orbital operation and satellite maintenance, according to any one of claims 1 to 14.

16. The network management computer system according to any one of claims 1 to 15, comprising the step of considering whether the state-space database includes a beamforming antenna capable of providing a coverage footprint that is relatively stationary.

17. A method for managing multiple orbital base stations that communicate with user equipment (UE) devices of a cellular network using a network management computer system, wherein the method is: The steps include determining a first coverage area for a first orbital base station among the plurality of orbital base stations, The steps include determining a second coverage area for a second orbital base station among the plurality of orbital base stations, A step of determining a modification of the signal from the second orbital base station in the case where the first coverage area and the second coverage area overlap, wherein the modification includes a change in the signal which is programmed to trigger a handoff request to the first orbital base station by being interpreted as a loss of signal strength between geostationary base stations. A method that includes [a certain feature].

18. The process involves generating multiple mesh points, each representing a location within the entire coverage area, The steps include generating multiple polygons that cover the multiple mesh points, The steps include determining the link budget for a given mesh point among the aforementioned plurality of mesh points, The steps include determining a set of applicable wireless communication constraints for the given mesh point, A step of determining beam parameters for each of a plurality of base station beams that coincide with a specific polygon having coverage of the given mesh points, based on a set of applicable radio communication constraints for the given mesh points within the specific polygon. The method according to claim 17, further comprising:

19. A method for managing mobility management entities, The steps include: performing physical simulations on orbital mechanics, attitude dynamics, and link budget to derive a set of future link states for a network managed by the mobility management entity; A step of determining the processes for spacecraft operation, radio access network operation, and core network operation based on the aforementioned set of future link states. A method that includes [a certain feature].

Images