Cellular core network and radio access network infrastructure and management in space

Abstract

To provide a network management computer system that manages terrestrial base station communications and orbital base station communications with user equipment in order to provide wireless service and allocate links among terrestrial base stations and orbital base stations according to base station availability determined from state space predictions.SOLUTION: A network management computer system is configured to: compute future state space predictions for a network by using an assumption for attitude and orbit control laws for orbiting infrastructure; store them in a database; and, with gravitational models, atmospheric models and numerical integration schemes, make quite accurate predictions of satellite trajectories in LEO many hours, days or even weeks, into the future. The orbiting network infrastructure can use that data for obtaining insight about future inertial state vectors into future network connectivity states, predict optimal network operations in the future, and coordinate with terrestrial network deployments in advance.SELECTED DRAWING: Figure 25

Description

[Technical field]

[0001] The present disclosure relates to space communications networks that are operable to provide communications in conjunction with terrestrial mobile cellular networks. [CROSS REFERENCE TO PRIORITY AND RELATED APPLICATIONS]

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

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

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

[0005] 2) U.S. Provisional Patent Application No. 62 / 465,945, 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,” filed March 2, 2017 (hereinafter, “Speidel II”).

[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,” filed on April 26, 2017 (hereinafter, “Speidel III”).

[0007] The entire disclosures of the above patents / applications are hereby incorporated by reference for all purposes as if fully set forth herein. [Background technology]

[0008] In a typical terrestrial cellular telecommunications network, multiple mobile devices communicate with multiple telecommunications infrastructure elements. This telecommunications infrastructure may comprise hardware that may include, but is not limited to, towers, antennas, radio waves, transceivers, digital signals, processors, electrical cabinets, servers, computers, etc. This telecommunications infrastructure is typically organized as an integrated system for managing the telecommunications traffic volume of the various mobile devices served together by functions and connections. This integrated system may comprise one or more networks. These networks themselves are also typically designed to connect to 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. The terrestrial cellular networks and their functions may be used in the context of a typical LTE cellular network. However, lesser structures and functions of this type of network may be used for other terrestrial cellular networks, such as GSM, CDMA, EDGE, UMTS, etc. networks.

[0009] FIG. 1 illustrates a high-level architecture of a typical LTE terrestrial cellular network. Each node in FIG. 1 represents an operational "node" in the network. The nodes are implemented in some embodiments by software executed and hosted by electronic hardware. Each node may service a specific function or set of functions, may be responsible for control plane signaling and / or user plane traffic routing, and has interfaces to other nodes in the network for routing control or user traffic. A visited network 102 may host a radio access network (RAN) 106 and a core network 108. The visited network may interact with a home network 104. The home network 104 also hosts the same or similar type of radio access network and core network as the visited network. For simplicity, not all elements may be shown. A network may be a home network or a visited network depending on the subscriber end user.

[0010] The radio access network may be an E-UTRAN and the core network may be an EPC. The E-UTRAN may comprise base stations 110 that enable communication with UEs 112 over an air interface (Uu). The base stations may be base stations for an LTE network. Such base stations may be "Evolved Node B" base stations or "UTRAN Node B" base stations, which are often referred to as "eNodeB" or "base station", respectively. The base stations include hardware for wirelessly connecting a cellular network to a mobile handset (UE).

[0011] The base stations may maintain connections with each other over the X2 interface to run control and user signaling. The base stations connect to the EPC over the control and user planes, i.e., S1-CP and S1-UP. The control plane interfaces to the MME 114 and the user plane interface to the S-GW 116. The MME may connect to the S-GW over another control interface, i.e., the S11 interface, to other MMEs over the S10 interface, and to the HSS database 122 over the S6a interface. The EPC also hosts the P-GW 118. The P-GW has control and user plane connections to the S-GW over the S5 interface in the home network. A similar connection may exist between the S-GW of the visited network and the P-GW of the home network 120. This connection is an S8 interface and also includes the control and user planes. The P-GW maintains a control interface with the PCRF 124. The P-GW maintains a connection to the PDN server 126 through the SGi interface.

[0012] FIG. 2 shows the control plane protocol stack for each interface in the LTE network. It describes how each node connection is implemented to pass control traffic. The control plane interface may be wired or wireless. The UE stack 202 operates the application layer, IP layer, PDCP layer, RLC layer, MAC layer and PHY layer to communicate with the base station stack 204 via the LTE-Uu interface 212. The base station stack relays the application layer packets and the IP layer protocol packets, but encodes the requirements such as HARQ, ARQ, etc. by coordinating the modulation scheme of the air interface interaction and channel allocation with the PDCP, RLC, MAC and PHY layers. The base station stack routes the 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 interface and the S8 interface 216 are almost 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 acts as a serving node for routing IP traffic using the SGi interface 218 between the UE and a Packet Data Network (PDN) stack 210 providing back-end IP services for the end UE. An application layer compatible with the application layer on the UE exists on the PDN providing 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 uses tunneling protocols GTP-U and SCTP transport layer to route IP data packets for the end UE during handover between base stations, etc.

[0013] FIG. 3 shows the user plane protocol stack for each interface in an LTE network. It describes how each node connection for passing user traffic can be implemented. The user plane interface can be wired or wireless. The UE stack 302 communicates with the base station stack 304 via the LTE-Uu interface 316. The non-access stratum (NAS) is a functional layer in the LTE wireless long distance communication protocol stack between the MME stack 306 and the UE stack. The NAS layer is used to manage the establishment of communication sessions and to maintain continuous communication with the user equipment as it moves through the network. The base station stack relays this layer between the MME and the UE and transports radio resource control messages to the UE using PDCP. The MME stack communicates with the base station stack via the S1-C interface 318. The MME transports S1-AP protocol sessions based on NAS signaling using SCTP. The MME communicates with the S-GW stack 308 via the S11 interface 320. This interface transports IP packets using tunneling protocols and UDP. The S-GW stack also communicates with the P-GW stack 310 over an S5 / S8 control plane interface 322, using a similar structure to the S11 interface. There are further interfaces, such as the X2-C interface 324 between the 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 over an S10 interface 326, which transports tunneling protocol messages using UDP. The MME stack also communicates with the HSS database 312 over an 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 handsets / devices]

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

[0015] The UE may comprise hardware and a SIM card. The hardware may include the physical phone or the device itself. The actual hardware may include a set of numbers known as the device's International Mobile Equipment Identity, or IMEI. This number is unique to the exact piece of hardware that is on and is used to check if the physical device has been marked as stolen on the network, and for other purposes. The physical device typically includes a transmitter and a receiver so that it can interface with the cellular network over an air 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] Also, the UE is typically loaded with firmware and application layer software that allows the user to access certain functions. These functions may be voice calling, sending SMS messages, browsing the Internet or using other applications (e.g., messaging, gaming, streaming, etc.). The UE may require a certain signal level or QoS to achieve a certain data rate over the air interface with the mobile network. As an example, SMS texting may work fine with a relatively weak link level (and therefore with a low order modulation scheme at a high coding overhead rate and therefore with a low data rate), while video streaming may require a higher data rate (and therefore with a high order modulation scheme at a low coding overhead rate and therefore with a higher data rate) for a video stream with reasonable download times and quality. Typically, the UE is designed to access cellular networks with a variety of possible bands (e.g., frequencies) and protocols (e.g., GSM, LTE, UMTS, CDMA, etc.). Some smartphones may be referred to as "world phones". Because they are designed to accommodate bands and protocols that allow end users to travel the world and remain connected to local cellular networks in various locations around the world regardless of the different cellular protocols being used, the reason for this is that typical cellular band allocations for protocols such as LTE, GSM, CDMA, etc. are well established and licenses are assigned to specific MNOs in specific countries around the globe.

[0017] The Subscriber Identity Module, or SIM, contains the subscriber identity for a user to use the network. One of the various numbers and information stored on the SIM is the International Mobile Subscriber Identity (IMSI), which is a unique number that corresponds to a particular subscriber of the network. Some phones allow multiple SIM cards. This means that a single device can have multiple IMSIs. This allows an end user to have local plans in multiple countries or even in the same country if they wish to be a "home" user on multiple networks. Also, SIM cards can be swapped in and out of the device to change the subscriber identity and connect to different networks as a "home" subscriber. This technology can be advantageous for users who travel a lot and do not want to pay roaming charges every time they travel. [Radio Access Network]

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

[0019] In the LTE architecture, the RAN is often referred to as the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN typically comprises multiple base stations, which are the functional elements that implement the physical interface or Uu with the UE. The physical interface is broken down in time and frequency as time slots and resource blocks (RBs). The RBs are assigned to the UE by a scheduler in the base station. This may be driven by one of a variety of algorithms that optimize traffic flow depending on location, deployment configuration, coverage requirements, etc. The base stations in the network interface with each other through the X2 interface. This allows for transfer of calls / text / data packets and signaling primarily to support handover from base station to base station when the UE operates in a mobile manner with respect to the network. The base stations also connect the UE to the core network, or the Evolved Packet Core (EPC) in the LTE network, through the S1 interface. [Core Network]

[0020] The core network, often referred to as the Evolved Packet Core (EPC) in the LTE architecture, holds most of the authorization functions in the cellular network acting as an interface between the UE and other UEs on the network, the Internet and other networks / devices with which 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 to upload / download data to / from the Internet for specific applications / servers. Even if the UE wants to communicate with other UEs on the same home network, the EPC allows the UE access by handling the authentication.

[0021] With LTE protocols, 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) and the HSS hosts the Home Location Register (HLR), the Equipment Identity Register (EIR) and the Authentication Center (AuC). The HLR, VLR, EIR and AuC are databases managed by the EPC and are described in more detail below. [Mobility Management Entity (MME)]

[0022] Within the EPC there are several control and user plane interfaces. The E-UTRAN interfaces with the EPC via a control plane with the MME called the S1-CP interface. The S1-CP interface manages the establishment of communication sessions with the Non-Access Stratum (NAS) and maintains continuous communication with the user equipment as it moves. The LTE S1-CP interface is responsible for the delivery of signaling protocols between the base station and the MME. The S1-CP interface comprises the Stream Control Transmission Protocol (SCTP) over IP and supports multiple UEs through a single SCTP association. It also provides guaranteed data delivery. The application signaling protocol is the S1-AP (Application) protocol. The LTE S1-CP is responsible for the Evolved Packet System (EPS) bearer setup / release procedures, handover signaling procedures, paging procedures and NAS transport procedures.

[0023] The MME also has control plane interfaces with other MMEs over an S10 interface, an S-GW over an S11 interface, and an HSS over an S6a interface.

[0024] The S11 interface between MME and S-GW is usually a many-to-many interface. This means that a single MME can handle multiple S-GWs, each with its own S11 interface. These connections can be used to coordinate the establishment of SAE bearers in the EPC. SAE bearer setup can be initiated by the MME (default SAE bearer) or by the P-GW. Using the S11 interface, MME nodes can create or delete IP sessions, create or delete default bearers, create or delete dedicated bearers, add rules to create or modify / update dedicated bearers, perform UE handovers, perform X2 based UE handover with S-GW relocation, and perform S1 based UE handover with S-GW relocation. [Serving Gateway (S-GW)]

[0025] The E-UTRAN interfaces with the EPC via a user plane with the S-GW called the S1-UP interface. The S1-UP interface provides non-guaranteed 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 carries the user plane PDUs between the base station and the S-GW. A GTP tunnel per radio bearer carries the user traffic. The S1-UP interface is responsible for the delivery of 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 connects with the P-GW via the S5 or S8 interface to provide IP routing services for packets between the UE and the core network using the GPR Tunneling Protocol (GTP). In principle, S5 and S8 are the same interface, except that the S5 interface is used inside a single (home) network, while the S8 interface is used when roaming between different operators. In the non-roaming case, the functions of the S-GW and the P-GW may be performed 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 Serving GW relocation due to UE mobility and when the Serving GW needs to connect to a non-collocated PDN GW for required PDN connectivity. The S5 interface is an inter-PLMN reference point that provides the user and control plane between the Serving GW in the VPLMN and the PDN GW in the HPLMN. S8 is an inter-PLMN variant of S5. [Packet Data Network Gateway (P-GW)]

[0028] The P-GW is the node that terminates the SGi interface towards the PDN. If the UE is accessing multiple PDNs, there may be more than one P-GW for the UE. The P-GW provides the UE with a connection to external packet data networks by being the egress and ingress point for the UE's traffic. The UE may have simultaneous connections with more than one P-GW to access multiple PDNs. The P-GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening. This reference point provides the connection 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 serving networks. [Cellular Network Database]

[0029] LTE networks may manage a set of databases used for authentication, billing, policy management, etc., as well as for operational queries to manage UE mobility. The HSS is home to the HLR, a database that contains administrative level information about each subscriber that can use the network. The HLR also contains a field that tracks the last known location of the subscriber in the network. This information may be for locating the device when calls, messages, or data need to be routed. When users switch mobile phones or mobile devices, or when they move to a different Location Area Code (LAC) in the network, or perhaps over some regular period, mobile devices may update their location so that the HLR keeps up to date with their location. Typically, the location of a device is kept in the context of the network (e.g., which base station the device is camped on), rather than the actual latitude / longitude location of the device. Typically, there is only one master HLR in any network. However, copies of it may be distributed across various core network nodes for improved operational efficiency.

[0030] The HSS is a concatenation of the HLR and the AuC, two functions already present in pre-IMS 2G / GSM and 3G / UMTS networks. The HLR part of the HSS is responsible for storing and updating, if necessary, a database containing user subscription information (the enumeration is non-exhaustive), including user identification and addressing (which corresponds to the IMSI (International Mobile Subscriber Identity) and MSISDN (Mobile Subscriber ISDN Number) or mobile phone number) and user profile information (which includes service subscription status and user subscribed quality of service information, such as maximum allowed bit rate or maximum allowed traffic class).

[0031] The AuC portion of the HSS is responsible for generating security information from the user identity key. This security information is provided to the HLR and further communicated to other entities in the network. The security information may be used for network-terminal mutual authentication and for encryption and integrity protection of the radio path to ensure that data and signaling transmitted between the network and terminal are not eavesdropped or altered.

[0032] The VLR is a smaller, temporary version of the HLR in some aspects and contains selection information from the HLR. Any "visitor" or UE roaming on a base station controlled by the EPC that is not part of the home network is placed on the VLR of the visited network. A UE can typically only be in one VLR at a time. This can be very important 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 through the base station. The VLR is used to inform the HLR of the subscriber's updated location home HSS so that traffic routing can be completed between separate networks. A user is typically removed from the VLR precisely when the subscriber becomes inactive for a set period of time (which can be configured / set for each network), when the UE roams to a new VLR domain location area, or when the user transitions onto the home network.

[0033] The VLR may contain a portion of the field value of each IMSI, including the TMSI, which effectively serves as a temporary subscriber identity during roaming operations outside the home network.

[0034] The EIR is a database that holds information about specific handsets or mobile equipment or devices that may be connected to a network or that may attempt to connect to a network. The database uses the IMEI to determine whether a device has authority to access the network. Typically, if a phone is reported stolen, the IMEI of the device is placed on a list in the EIR that associates it as a stolen device. That way, if the device attempts to register with the network, the network can deny it access to prevent improper use by a potential phone thief.

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

[0036] Although the above described components of the terrestrial cellular network operate autonomously, typically some level of human interaction is also implemented. The Network Operations Center, or NOC (sometimes also known as Operations Management Center, or OMC) is a component of the network that allows for 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 a connection 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 a connection to each base station, MME node, S-GW node, P-GW node in the LTE network. [A. Example of network procedure]

[0037] A network may implement a long list of procedures, but certain specific procedures may be used most often and important for network functionality, such as mobility management, spectrum usage, etc. [A.1 Authentication Procedure]

[0038] Authentication procedures in LTE networks are used to both authenticate users' identities (e.g., verify their subscriber numbers) and allow or deny access to the network. Authentication utilizes a unique key stored in the HSS and performs procedures on the UE and MME sides of the network to calculate values ​​and compare the results to 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 in an LTE network. The process involves a UE 402, a base station 404, an MME 406 and an HSS 408. The UE sends a request to the MME to attach to the network 410. In the request, the UE sends the IMSI and other information about the UE handset capabilities that the network may need 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 needs for a response. The HSS provides a response to the MME 414 along with what is called an authentication vector.

[0040] Each authentication vector contains AUTN, XRE, KSAME and RAND values ​​that relate to the output resulting from the execution of an algorithm called the EPS AKA algorithm. The MME passes the RAND and AUTN values ​​to the UE via the base station 416. The UE uses this information to execute the EPS AKA algorithm and then provides a response to the MME 418, including a RES value. The RES value should be equal to the XRE value calculated by the HSS and provided to the MME. The MME checks 420 that this is the case and, if so, the UE is authenticated to the network.

[0041] The MME and UE may then perform further procedural steps 422 to achieve ciphering and encryption of the AS (RF Interface) and NAS (Network Control Interface) sessions between the UE and the network. These procedures are similar in nature to authentication in that the UE node and / or base station node may run algorithms to calculate unique keys that are checked and verified before being used to encrypt traffic between the nodes. After these procedures are completed, the MME may accept the original attach request from the UE 424 and may be officially attached to the network and able to run traffic.

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

[0043] In a classical mobile network, the location of each device may be tracked so that the network knows how to contact the UE to which it needs to deliver or receive information. 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. If the location of the UE changes, it is reflected in the HSS. If the UE is attached to a network that is not its own home network, the location of the UE is tracked by both the HSS and the VLR. The VLR temporarily stores the subscriber authentication information and the location of the UE within its network. If the location of the UE changes, the VLR may make a location update request to the HSS so that the HSS can manage the location change for the UE.

[0044] Under certain roaming conditions, the physical location of the MME and VLR where the subscriber is located may be far away from the HSS that holds the important management information required by the device for authentication. If queries can be routed through SS7 or another medium that interfaces the various terrestrial networks, authentication can take place over several minutes. These inter-network interactions can slow down, especially for network procedures, when the traffic load is high and the databases are located far away. As a result, initial access to an external network can be delayed. However, once access is provided, typical speeds typically associated with cellular service resume.

[0045] Examples of triggers when the UE may initiate a location update procedure are listed in Table 1. [Table 1]

[0046] FIG. 5 illustrates a typical location update or tracking area update procedure. The nodes involved shown are a UE 502, a base station 504, a new MME (e.g., new tracking area) 506, an old MME (e.g., old tracking area) 508, an S-GW 510, and an HSS 512. After an RRC connection setup occurs 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 to use to perform authentication / security procedures with the UE (518). The old MME may respond (520) to the new MME with the information it requested. The new MME then authenticates the UE (522). After successful authentication, the new MME may acknowledge the requested context from the old MME (524). The new MME may then request bearer modification from the S-GW (526). The modify bearer request from the new MME is responded to (528) and the new MME immediately requests (530) a location update from the HSS. The HSS cancels (532) the current location maintained on the old MME. After the cancellation is acknowledged (534) by the old MME, the HSS acknowledges (536) the location update request from the new MME. The new MME then accepts the UE's TAU request 538 and the UE acknowledges (540) the completion of the location update procedure. [A.3 Handover Procedure]

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

[0048] FIG. 6 shows how handover may conventionally take place between an eNB and an S-GW. In the handover procedure, the elements involved are a UE 602, a source eNB 604, a target eNB 606, an MME 608, a source S-GW 610, a target S-GW 612, and a P-GW 614. The handover may take place after an IP session has already been established between the UE and the P-GW through the source eNB and the source S-GW (616). A measurement control message from the UE to the source eNB may trigger handover preparation between it and the target eNB (618). The target eNB and the source eNB may perform the handover over the X2 interface (620). The source eNB begins forwarding data to the target eNB (622) so that the data can be downlinked to the UE (624). At this point, the uplink data passes through the target eNB, through the source S-GW, and back to the P-GW (626). The downlink is provided through the same S-GW, but through the source eNB to the target eNB (through the X2 interface) before reaching the UE. The target eNB makes a reroute request to the MME to reroute the IP packets to the target S-GW (628).

[0049] The MME makes a create session request to the target S-GW (630). The target S-GW requests that the P-GW modify the bearers for the UE (632). The P-GW provides a modify bearer response and modifies the bearers to the target S-GW (634). The target S-GW responds to the MME with a create session response to indicate that it is ready to carry IP traffic from the UE through the target eNB (646). The MME acknowledges the original path switch request from the target eNB (638) and uplink and downlink data flows from the UE to the target eNB to the target S-GW to the P-GW (640). The link over which the downlink data is forwarded from the source eNB is released (642) as this indicates the completion of the S-GW handover. 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 the S-GW handover, the UE may need to update its tracking area and does so together with the MME (648). [A.4 Master Information Block (MIB) and System Information Block (SIB) Transmission Procedures]

[0050] The MIB, or Master Information Block, is a message or information that is broadcast by an LTE base station whether or not any users are present. The MIB is the first among other System Information Blocks or SIBs that are also broadcast by the base station.

[0051] The MIB is transmitted using a physical layer channel called PBCH, or Physical Broadcast Channel, on the downlink. The MIB is a 24-bit value that is encoded as shown in Table 2. [Table 2]

[0052] Apart from the information in the payload, the MIB CRC also conveys the number of transmit antennas used by the base station. The MIB CRC is scrambled or XORed with 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. As an example, the SIB1 block may contain one or more of the variables listed in Table 3. [Table 3] [B. IP Address Allocation in LTE]

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

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

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

[0057] In the case of dynamic IP allocation, the network (e.g., P-GW) automatically selects an IP address for the UE. The network operator has a pre-provisioned IP pool in 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. Thus, a new dynamic IP address is typically assigned to the same UE every time the UE first attaches to the network.

[0058] For static IP allocation, the network operator assigns a permanent IP address to each UE when it joins the network. The operator has the assigned static IP address provisioned for the UE in 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, every 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 may therefore implement different types of geographical areas and addresses to function properly when a UE attaches to and detaches from base stations in networks managed by different network EPC nodes. [C.1 Geographic Area]

[0060] An MME Pool Area is a geographical area controlled or served by a particular MME or set of MMEs. An MME Area is a physical region in which a mobile device can operate before the MME serving it can be changed. An S-GW Tracking Area is a geographical area controlled or served by a particular S-GW or set of S-GWs. Within this geographical area, a UE can operate without changing the serving S-GW.

[0061] A tracking area refers to the smallest geographical area used by a network. MME pool areas contain S-GW tracking areas. S-GW tracking areas themselves contain these smaller tracking areas. A tracking area may be as small as a particular cell tower cell or group of cell tower cells (perhaps a geographical area strictly represented by a circle of some radius ranging from a few km radius up to a 100 km radius). These tracking areas are similar to Location Area Codes (LACs) used in GSM or 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] Thus, an LTE network includes many MME areas, even more S-GW tracking areas and even more tracking areas. [C.2 Network Identification]

[0063] Networks also manage a host of numeric identifiers that are used as network level addresses. The network ID is used to define the network itself. Networks are 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). The MCC is a three digit code and the MNC is a two or three digit code, so when the two are concatenated the PLMN becomes a five or six digit code.

[0064] Each MME in the network is provided with a unique identifier known as the MME Code, or MMEC. This identifier identifies the specific MME in each of the network MME pools. MMEs that are grouped in the same MME Tracking Area are given a group level code called the MME Group Identity, or MMEGI. For each MME in the network, another identifier is used that concatenates the MMEC and MMEGI to generate the MME Identifier, or MMEI. This identifier identifies the specific MME in the entire network. Finally, the PLMN and MMEI are concatenated to generate the Globally Unique MME Identifier, or GUMMEI. This identifier identifies the specific MME anywhere in the world.

[0065] Tracking areas are also identified by a code in a similar manner. The Tracking Area Code, or TAC, is used to identify a specific tracking area within a particular network. This number is concatenated with the PLMN to create a globally unique Tracking Area Identity, or TAI, which uniquely identifies a tracking area across the entire globe.

[0066] Also, each cell in the network is provided with a Cell ID so that the specific tower that needs to communicate with the UE is known and tracked. This Cell ID is often referred to as the E-UTRAN Cell Identifier, or ECI. This value uniquely identifies a cell in a particular network. There is also an E-UTRAN Cell Global Identifier, or ECGI, which identifies a unique cell anywhere on the planet. There is also a tower physical Cell ID, which is typically a number between 0 and 503, and is used to distinguish itself from neighboring cells in a nearby area.

[0067] There is a Mobile Equipment Identifier to track a particular UE hardware as it operates on the network. As mentioned before, each UE has two unique identifiers, one for the hardware and one for the SIM. The International Mobile Equipment Identity (i.e., IMEI) is used to identify the unique handset hardware. The International Mobile Subscriber Identity (i.e., IMSI) is used to identify a unique subscriber (e.g., SIM) on the network. There is also an M-type Temporary Mobile Subscriber Identity (i.e., M-TMSI) that is used to identify a particular UE to a serving MME. By concatenating the M-TMSI code with the MMEC, the network generates an S-type Temporary Mobile Subscriber Identity (i.e., S-TMSI) that is used to identify a particular UE to a serving MME pool tracking area. Finally, by concatenating the PLMN, MMEGI, and S-TMSI, a Globally Unique Temporary Identity (GUTI) is generated. The GUTI identifies a unique UE and its temporary address anywhere on the planet. [D. Wireless Protocol Architecture]

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

[0069] The user plane is where the actual data or telecommunication 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 and user planes, information or signaling packets are processed by the Packet Data Convergence Protocol, i.e. PDCP, the Radio Link Control Protocol, i.e. RLC, and the Medium Access Control Protocol, i.e. MAC, before finally being passed to the physical layer, i.e. RF layer, for over-the-air transmission to UEs connected to the network.

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

[0071] The PHY 716 carries information from the MAC transport channel over the air interface and handles link adaptation AMC, power control, cell search for initial synchronization and handover purposes, and other measurements within the LTE system and between systems for the RRC layer.

[0072] The MAC 714 layer is responsible for mapping between logical channels and transport channels, multiplexing MAC SDUs from one or different logical channels onto a transport block TB delivered to the physical layer on the transport channel, demultiplexing MAC SDUs from one or different logical channels from the transport block TB delivered from the physical layer on the transport channel, scheduling of information reports, error correction through HARQ, prioritization between UEs by dynamic scheduling, prioritization between logical channels of one UE, and prioritization of logical channels.

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

[0074] The PDCP 710 layer is responsible for header compression and decompression of IP data, forwarding of data (user plane or control plane), maintaining the PDCP sequence number SN, in-sequence delivery of upper layer PDUs upon lower layer re-establishment, de-duplication of lower layer SDUs upon lower layer re-establishment for radio bearers mapped with RLC AM, ciphering and decryption of user and control plane data, integrity protection and integrity verification of control plane data, timer based discard, duplicate discard. PDCP is used for SRBs and DRBs mapped on DCCH and DTCH type logical channels.

[0075] The Radio Resource Control Function (RRC) 708 sub-layer services and functions include broadcasting of system information related to non-access stratum NAS, broadcasting of system information related to access stratum AS, paging, establishment, maintenance and release of RRC connections between the UE and the E-UTRAN, and security functions including management, establishment, configuration, maintenance and release of keys for point-to-point radio bearers.

[0076] The Non-Access Stratum (NAS) protocols used by the MME 704 and the UE form the control plane layer between the user equipment (UE) and the MME. The NAS protocols support 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 PDCP, RLC, MAC and PHY layers. In the user plane, packets are packaged in the core network in a specific EPC protocol and tunneled between the P-GW and the UE through the S-GW and the base station. This protocol may be, for example, an IP protocol. [D.2 Control Plane]

[0078] The control plane includes each of the layers in the user plane in addition to the radio resource control (or RRC) layer. The RRC layer is responsible for the configuration and control of the lower layers of the protocol (PDCP, RLC and MAC layers). Unlike the user plane, the control plane handles the air interface specific functions between the UE and the RAN in a cellular network. The base station typically uses scheduler algorithms that drive the RRC and how the base station allocates RBs, time slots, MCS, etc. for each UE under its control. Typically, these scheduler algorithms are only informed by control traffic feedback from the PDCP layer to the RRC. These algorithms typically attempt to optimize the 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 particular mode: idle mode or connected mode.

[0080] Idle mode is when the UE is told to "camp" on a cell. After selecting a cell, the UE can camp on that cell. The UE selects a cell based on many factors including radio link quality, cell status, and radio access technology. While camping on a cell in idle mode, the UE may monitor paging or control channels to detect incoming calls and to obtain important system information. In this mode, the control plane protocol includes cell selection and reselection procedures.

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

[0082] FIG. 8 illustrates a typical cell search procedure that may be used when a mobile device is operating on and between networks. [D.3 Cell synchronization and selection procedures]

[0083] Cell synchronization is the very first step if a UE wants to camp on any cell. From this, the UE acquires the Physical Cell ID (PCI), timeslot and frame synchronization. This may enable the UE to read the system information blocks from a particular network.

[0084] A UE may tune its radio 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 in the last OFDM symbol of the first time slot of the first subframe (subframe 0) of the radio frame. This allows the UE to be synchronized at a subframe level. The PSS is repeated in subframe 5, which means that the UE is synchronized on a 5 ms basis, since each subframe is 1 ms. From the PSS, the UE can also derive the physical layer identity (0 to 2).

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

[0086] By using the physical layer identity and the cell identity group number, the UE knows the PCI of its cell. In LTE 504, physical layer cell identities (PCIs) are allowed and divided into 168 unique cell layer identity groups. Each group contains three physical layer identities. As mentioned before, the UE finds the physical layer identity from the PSS and the physical layer cell identity group from the SSS. Assuming that the physical layer identity=1 and the cell identity group=2, the PCI of a given cell is PCI=3×(physical layer cell identity group)+physical layer identity=3×2+1=7.

[0087] Once the UE knows the PCI of a given cell, it also knows the location of the cell's reference signals, which are used in channel estimation, cell selection / reselection and handover procedures.

[0088] As a result of PCI, the UE can distinguish the target base station from other base stations using the same spectrum block deployment. This allows for 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 on the downlink control channel. This information block contains information required for the UE to properly access the network over the air interface. [E. Cellular Network Radio Access Technology PHY]

[0089] As described, a cellular network uses a RAN to implement an air or RF interface to connect UEs on the network to the Internet or other networks. Assuming that the air interface link requirements are met and that the membership requirements are met, e.g., the UE has identified itself to the network in such a way that the network, or the services it uses, determines that the UE is a member of an authorized group or is otherwise authorized to use the services provided by the network, 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. The air interface typically implements a specific protocol, often referred to as a specific Radio Access Technology (RAT).

[0090] Some exemplary RAT protocols include the GSM protocol, sometimes referred to as a 2G or "second generation" network protocol. Other examples include the GPR (General Packet Radio Service) protocol, the EDGE (Enhanced Data Rates for GSM Evolution or EGPRS) protocol, the 3G (the third generation 3G UMTS standard developed by the 3GPP organization) protocol, or the fourth generation (4G) LTE Advanced protocol.

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

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

[0093] Each MCS provides a certain data rate over the air interface, but MCSs that allow higher data rates have different requirements for the quality of the RF signal being received over the air interface. A waveform articulated over the air interface using a given modulation and coding scheme may have different bit error rates as a function of the signal-to-interference-and-noise ratio, or SINR, of the signal of interest. SINR is a measure, expressed in dB, of the difference between the energy of the signal of interest and the combined energy of 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 provides 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 bits per symbol, however this drives the requirement for more precise signal demodulation, resulting in increased signal energy required for sufficient demodulation at a particular bit error rate.

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

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

[0097] Base stations are often not deployed in rural and remote areas of the world, where population density is reduced and therefore potential revenue density for mobile network operators. To profitably serve these remote and rural areas, spectrum needs to be spread across a sufficient population. Base stations can be deployed on high altitude platforms operating in the sky. However, these solutions are technically challenging and often subject to harsh atmospheric conditions that make the platforms difficult to control, resulting in inefficient and inconsistent operation. Additionally, high altitude platforms are still unable to provide a truly global coverage solution themselves, because they too would be prohibitively expensive for that amount of coverage. Summary of the Invention

[0098] A method of operating a mobile network having orbital base stations that may be deployed for use in a terrestrial manner as a mobile or cellular network is described. A typical terrestrial RAN and core network may comprise software, radio waves, modems, computers, racks, cables, servers, etc., deployed on top of or within terrestrial infrastructure such as buildings and towers. In a mobile network variant, RAN and core network equipment / software is deployed on satellites in orbit, supported by terrestrial equipment to interface to existing terrestrial RAN and core network counterparts as well as the Internet. The placement of certain network elements in LEO, MEO or GEO orbits may facilitate proper networking links and placement across strategic locations on the Earth where certain terrestrial infrastructure such as UE, G-MSC, P-GW, etc. may operate from home to either a space network or other classical terrestrial networks.

[0099] Space networks may implement a series of extensions to the typical LTE architecture. Both the EPC and E-UTRAN are extended with functions used by the base station stack, the MME stack, the P-GW stack and the HSS stack, etc. The LTE, EPC and E-UTRAN extensions may enable continuous functioning of the standard LTE-Uu interface, such that a standard UE handset will be compatible with both terrestrial and space networks.

[0100] Additionally, embodiments may facilitate more optimal use of space-based cellular networks, especially in phases where coverage is intermittent and not continuous, by implementing UE stack extensions. These UE extensions may take root in an application layer of the user plane on the UE stack or in a non-access stratum layer of the control plane on the UE stack.

[0101] In addition to EPC and E-UTRAN extensions, further databases may be included to support extensions in the core network. These databases may be stored one or more times on the ground or on orbit or both and may support MME extensions (in terms of position, velocity, attitude, IP connectivity, coverage area, etc.) that allow prediction of the future state of the network. This future state space prediction function may be a function of known physics and characteristics of the network hardware and its operational constraints to determine a future inertial state vector of the orbiting network infrastructure. The inertial state vector may be position, velocity, acceleration, attitude and attitude rate. Other state vectors or matrices / tensors may be included, such as thermal, power, inertia or mass. Calculation of such vectors may be performed by the network management computer system and the results may be distributed to the base stations and UEs.

[0102] The network management computer system may use attitude and orbit control law assumptions for the orbiting infrastructure to calculate future state space predictions of the network. This information may be stored in a database and may be spacecraft specific depending on the capabilities of each orbiting satellite and the actuators it hosts on-board and its intended on-orbit operation. Thus, there may be different spacecraft in the same network with different actuators, capabilities, designs, etc. Using gravity models, atmospheric models and numerical integration schemes, the network management computer system may make predictions of satellite trajectories in LEO quite accurately many hours, days or even weeks into the future. The orbiting network infrastructure may use that data to gain insight into future inertial state vectors to future network connection states, may predict future optimal network operation and may coordinate in advance with terrestrial network deployment. This may include radio resource control (RRC) functions for things like handovers, non-access stratum (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 orbiting network, various network node connections may be possible. Each orbiting satellite may have a finite number of beams to assign for communication with UEs on the ground, other satellites in the network, or ground station gateways on the ground. Depending on the number of beams available and the relative positions, velocities, and attitudes of the nodes in the network, a set of connection scenarios for each distinct time may be generated. A set of operating rules, constraints, and / or service requirements may be imposed as a filter to evaluate the set of connection scenarios to derive the most ideal one or more, thus generating an ideal concept of operation for network connections. This concept of operation may include not only orbital maneuvering / maintenance journeys, but also a timeline of a network map showing node connections predicted to exist for some time in the future and what the characteristics of those connections (e.g., latency, data rate, frequency, modulation scheme, coding, etc.) may be. A network processor may generate predictive routing tables based on the network map predictions and the network node connections, and distribute the predictive routing tables as data structures to some or all of the nodes in the network. Given a stored database of their locations and velocities, operations at the MAC or PHY layers can be predicted based on the expected number of overpasses of the UE.

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

[0105] Because future link budget characteristics can be predicted at these various points, optimal network routes and paths can also be predicted to serve these points, and specifically which satellites may do so at what time, and when handovers, if any, will be scheduled between two satellites exchanging control of serving a particular location on the earth. This will enable anticipation of core network signaling requirements and routing to optimize traffic flows.

[0106] The state space prediction function may be embedded in space or terrestrial hardware / software, e.g. as an extension of classical functions that typical terrestrial cellular infrastructure such as MME, S-GW, P-GW, HSS, PCRF, etc. populate. The results of the state space prediction function may be used to generate intelligence about the future state of the network. This intelligence may be distributed to each node in the network to inform future requirements for radio resource management, mobility management, tracking area management, load balancing between S-GWs, etc., which may be used to optimize the usage of the user plane and control planes used in the mobile network.

[0107] Space networks may implement RF interfaces similar to those specified by 3GPP standards for mobile protocols, such as GSM, LTE, EDGE, CDMA, etc., as described in Speidel I, which details methods for handling Doppler shifts and propagation delays 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 may solve connectivity challenges around the planet in remote and regional areas of the world where it is too costly to build infrastructure for mobile communications networks or there is simply no profitable incentive to build such infrastructure.

[0108] The following detailed description taken in conjunction with the accompanying drawings will provide a better understanding of the nature and advantages of the present invention. [Brief description of the drawings]

[0109] Various embodiments according to the present disclosure may be described with reference to the figures.

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

[0111] [Diagram 2]1 illustrates user plane interfaces between network elements of the LTE architecture.

[0112] [Diagram 3] 1 illustrates control plane interfaces between network elements of the LTE architecture.

[0113] [Figure 4] An authentication procedure for a UE on an LTE network is described.

[0114] [Diagram 5] A tracking area update (TAU) procedure for a UE on an LTE network is described.

[0115] [Figure 6] A handover procedure for a UE on an LTE network is described when a base station handover is required and when an S-GW handover is required.

[0116] [Figure 7] 1 illustrates a base station protocol stack architecture for an existing base station.

[0117] [Figure 8] 4 illustrates a process used by a UE when searching for and selecting a cell to camp on.

[0118] [Figure 9] 1 illustrates an enhanced LTE network architecture that may be used with embodiments of the present disclosure.

[0119] [Figure 10] It shows how space-based LTE network architecture nodes can present themselves to satellites and ground stations and interconnect through Inter-Satellite Links (ISLs) and Ground Station Links (GSLs) operating as IP tunnels.

[0120] [Figure 11]FIG. 1 shows components that are added to the MME to enhance the MME and to enable the MME to manage mobility between the described M coverage areas on Earth (and corresponding UE subscribers on the ground).

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

[0122] [Figure 13] We show how a network of nodes can manage an infrastructure of different state space configurations resulting in unique position, velocity, acceleration and orientation state vectors.

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

[0124] [Figure 15] 1 illustrates how a spacecraft body coordinate system having beams for inter-satellite links, ground station links, and base station links can be managed and stored.

[0125] [Figure 16] Indicates the constellation location register.

[0126] [Figure 17] 1 illustrates mesh points and polygons that may be used by the network state space predictor.

[0127] [Figure 18] Shown are satellites in orbit providing coverage to static and dynamic base station polygons separate from the terrestrial base station polygon.

[0128] [Figure 19] 1 shows a constellation policy database.

[0129] [Figure 20] 1 illustrates a network state space prediction engine.

[0130] [Figure 21] 1 illustrates how link budget geometries between ground stations, satellites, other satellites, and UEs may be established.

[0131] [Figure 22] 1 illustrates a procedure that may be used to determine the coverage provided by beamforming base station satellites in a network.

[0132] [Figure 23] 1 illustrates a procedure that may be used to determine the coverage provided by a non-beamforming base station satellite (and any remaining beamforming base station satellites) in a space-based network.

[0133] [Figure 24] 1 illustrates a simplified portion of a link state space matrix that may be generated to estimate link budgets from a transmitting satellite across an Earth mesh.

[0134] [Diagram 25] We show how spectrum slicing between satellites and ground base station cells in a space network can be done dynamically during satellite operation.

[0135] [Figure 26] 1 shows how the network can determine which ISLs and GSLs to activate at each point in time.

[0136] [Figure 27] A simplified portion of the link state space matrix that describes the nature of the link budgets between links (including ISLs and GSLs) in the network and a hypothetical scenario of how the network may generate links is shown.

[0137] [Figure 28] 27 shows how the network described by the link state space matrices in FIG. 27 may appear in inertial space.

[0138] [Figure 29] 1 illustrates a network state space database that includes itineraries that are distributed to network nodes for storage and to inform future actions.

[0139] [Diagram 30] 1 illustrates an inter-satellite handover for a base station having a beamforming antenna;

[0140] [Diagram 31] 1 illustrates an inter-satellite handover of a base station with a beamforming antenna to a base station with a non-beamforming antenna and back to a base station with a beamforming antenna.

[0141] [Diagram 32] 1 illustrates how satellite base stations may implement transmission power variations to avoid cross-border interference of spot beams based on regulatory requirements.

[0142] [Diagram 33] 1 shows an enhanced base station. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0143] In the embodiments described herein, a 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 to enable proper authentication and handoff of mobile devices between the space mobile RAN and the terrestrial mobile RAN.

[0144] In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the described embodiments.

[0145] Base stations are often not deployed in rural and remote areas of the world, where population density is reduced and therefore potential revenue density for mobile network operators is reduced. Space-based mobile communication platforms can be a solution to eliminate the need for specialized client equipment by closing links to standard UE devices over large terrestrial swaths. A standard Uu interface for space-based LTE networks can be used with the disclosures described in Speidel I, which describes how base stations can be enhanced to accommodate the Doppler shift and propagation delay of the orbital link between the base station and the UE over the LTE-Uu interface by manipulating the base station, particularly the eNB. 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 space-based mobile networks of base stations and other classically terrestrial mobile network infrastructures. These challenges stem primarily from the need to use low Earth orbit for the base station air interface links in the network. One of the challenges is closing the link between the transmitter and receiver. Closing the link involves transmitting a signal from the transmitter with sufficient power to traverse the distance between the transmitter and receiver and reach the receiver some distance away 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, there may be a certain signal-to-noise ratio requirement. The uplink budget may be primarily driven by the transmit power of the terrestrial UE. For the LTE protocol, this may be 200 mW (23 dBm) and for the GSM protocol, this may be 2 W (33 dBm).

[0148] To close the link budget with 200mW devices on the Earth's surface and to avoid overloading one satellite cell / satellite beam, satellites with base station transmitters / receivers can operate in low Earth orbit using directional antenna technology. Large antenna technology allows the altitude of orbital base stations to reach 1000km or the like. The use of sub-1GHz cellular spectrum can be advantageous for propagation characteristics and can be used in more advantageous embodiments. However, smaller antenna arrays can place some satellites as little as 300km away (if the orbit can be maintained by thruster systems on board the spacecraft hosting the base station), reducing network costs.

[0149] Due to the need for low Earth orbit, achieving ubiquitous coverage of the planet with orbital base stations may involve thousands of satellites, which is still less than the number of terrestrial base stations required for similar coverage. Nevertheless, it may take some time to fully deploy thousands of satellites, and in some embodiments envisioned herein, the satellite constellation operator may use an early-stage network design that can begin to generate revenue and provide meaningful terrestrial services including a smaller constellation of satellites that may not provide continuous coverage of the entire planet, but may provide intermittent base station overpasses across the planet. It may be advantageous to be able to create a first constellation of satellites with a simpler design so that they can be developed cheaply and deployed more quickly. For example, antenna selection may be an immediate design consideration for the satellite. One consideration may be a single antenna that has a limited range and 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 so that the beam can be pointed in any direction independent of the spacecraft attitude. If simpler antenna technology is utilized, each base station may have the opportunity for a quick overpass / session (e.g., a 2 minute connection every 30-60 minutes) depending on the elevation angle of the link budget.

[0150] In addition to antenna considerations, there may also be mass and power considerations. The initial use cases and markets may be purposefully selected to reduce power requirements for the initial satellite constellation. As an example, intermittent cellular service for remote IoT / M2M devices and simple SMS messaging applications among mobile phones in a select number of countries around the world may provide mitigated spacecraft technical requirements. As an example, if the initial intermittent service is provided in the countries of Australia, New Zealand, and the Philippines, this may only require the satellites to transmit beams 5-10% of the time on orbit. As a result, the highest power mode for the spacecraft operation may be duty cycled at 5-10%. By serving low data rate applications (e.g., SMS for relatively sparse users (compared to dense urban areas for telecommunication services)), the orbiting base station only needs to transmit over a single LTE resource block for data traffic, or even over a single 200 kHz wide GSM carrier. The transmit power of each carrier need only be 20 to 30 W. Power amplifiers for the payload may drive the spacecraft power budget. Using readily available class A or AB power amplifiers, efficiencies of 40-50% at P1dB (the power output at which the linearity of the amplifier drops by 1 dB) may be possible. As a result, the power dissipation from the amplifier may be 75W peak power or less. Thus, the spacecraft "payload" may have a peak power dissipation of 100-125W (after power is included for radio, computer processing, etc.) and an orbit average power of 10-12.5W or less. This range of orbit average power is well sized for a nanosatellite class bus, which may have a form factor of tens of centimeters in length, width and depth (e.g., a 6U nanosatellite would be about 20cm x 30cm x 10cm). A satellite of this size is well able to generate 50-60W of orbit average power from the deployed solar arrays and store that energy in batteries that can be discharged while the high power mode is required.

[0151] As additional use cases and coverage areas are added to the service set / product line for the orbiting constellation of base stations, extended spacecraft may be placed in place with larger size, power and capabilities to serve more spectrum, more users, higher data rates and more applications, etc. These extended spacecraft may coexist with the initial more limited spacecraft population that may remain commercially viable. In some embodiments, the constellation of base stations may comprise different spacecraft. The different capabilities and services they can accommodate (and perhaps for what amount of time or which specific countries) may simply be sized to provide coverage for a limited amount of time, taking into account operational constraints.

[0152] Another consequence of operating in low Earth orbit is that the cells are small relative to the Earth (and therefore require many satellites), but rather large relative to terrestrial cellular networks. A typical terrestrial cell may have a radius of 20-30 km or less, while an orbiting satellite may have a beam radius of over 300 km. As a result, there may be hundreds of base station cells on the ground that may operate simultaneously with the orbiting base station. In a scenario where spectrum is allocated only to the space network, this may not present any challenges, since the different frequency bands between the space network and the terrestrial network prevent interference. However, there may be some embodiments in which the space network acts as an extension of an existing terrestrial network and uses similar or the same spectrum. This may be preferable in some instances where there are financial and business difficulties in acquiring dedicated spectrum for telecommunication services. The use of sublicenses of spectrum owned and operated by existing terrestrial network operators may be simpler. This embodiment may use some spectrum management techniques in addition to those used by existing cellular networks to eliminate potential inter-cell interference.

[0153] However, there may be alternative embodiments of sharing spectrum between space and terrestrial base stations that do not involve dynamic modification of the existing terrestrial network, and that do not use extensions of the existing MNO network infrastructure. As the satellites move relative to the terrestrial network, this management technique may involve a time feature where the deployment of spectrum is dynamically managed over time.

[0154] In the case of satellites providing coverage to UEs moving in low Earth orbit, they move much faster (~7-7.8km / s) than terrestrial UEs. As a result, the network infrastructure is effectively mobile, and terrestrial UEs can be considered static (even though they are moving slowly). From the perspective of a space network, the movement of the UE in a given minute, hour, or even day is relatively inconsequential with respect to when and what coverage a satellite may be providing at a given time if it does not already have coverage from terrestrial cells. This feature can be advantageously used in some networking solutions.

[0155] This disclosure describes embodiments for managing a set of orbiting infrastructure hosting base station, S-GW, MME and / or P-GW functions. The dynamic movement of the orbiting constellation makes mobility management more complex, but with more unique requirements, the predictability of orbital dynamics can be leveraged to inform the network of future state space, and as a result, control plane behavior can be informed / anticipated for many functions. At the network level, understanding latency, routing and ideal coverage patterns / behavior is a much more complex calculation, since these things are typically static or constant in terrestrial mobile network deployments. Network IP traffic routing may be dynamic and may connect and disconnect intermittently as the orbiting and terrestrial infrastructures move relative to each other.

[0156] In addition to mobility management challenges, base stations also present challenges for RAN deployment. Aside from the typical challenges faced by terrestrial RAN deployments, the movement of satellites essentially means that each satellite may be covering every point on the Earth at any given time. As a result, base stations may operate as extensions of different terrestrial networks at different points in orbit. Specific frequencies may be licensed differently around the Earth, MCCs, MNCs, Master Information Blocks and System Information Blocks may change, and the specific technology used (2G, 4G, etc.) may change. As a result, there may also be a record of these requirements and a controller to dynamically reconfigure the base station settings to correspond to the particular location the base station is serving.

[0157] Other challenges of networking signaling latency arise for space-based telecommunications networks because any given satellite or available radio interface may be available to a user only minutes before it departs 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 time frame shorter than the satellite overpass time. Otherwise, the device may never be able to authenticate to the network. Typically, authentication on a roaming network or on a network that operates far away from the home network authentication database (such as a network in space) can take an amount of time that can exceed the amount of time of a satellite overpass. Networks can be designed to increase the overpass time, but when considering networks of orbiting telecommunications infrastructure, it becomes important to enable rapid authentication procedures or to address 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 fly every few minutes, the network may need to manage how to transmit the tracking area code of each of the satellites, because the UE may automatically update its location every time it undergoes a TAC change or is served by a different VLR / MME. This may require HSS updates in the home network and may result in substantial network overhead if all users need to update their location every few minutes and the number of users on a global network represents a typical total number of telecommunication subscribers across most regions of the world (hundreds of millions or even billions of subscribers).

[0160] Finally, handover of telecommunication traffic can be complicated in space-based telecommunication networks. Since each satellite may only have an overpass over a given area for a few minutes to 10 minutes, depending on the orbit and antenna deployed, permanent handover signaling may need to occur within the satellite network for each satellite to accommodate changes in coverage. In addition to handovers between UEs, there may be challenges with changing satellite location conditions and therefore varying network latency conditions as well as handovers within inter-satellite links based on routes from the orbiting infrastructure and terrestrial infrastructure that serves as a gateway to terrestrial mobile networks, the Internet, etc. These may be addressed using the methods and apparatus described herein. [Network design considerations / concepts]

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

[0162] A satellite-based mobile network may be configured / designed to work in conjunction with an underlying terrestrial mobile network and thus deploy only enough spectrum to fill the gaps of the terrestrial mobile network described herein. In this configuration, a small sliver of spectrum may be allocated to the space network for coverage of low population density areas that still have no coverage, but the majority may be allocated to the terrestrial network (where the ground cells are smaller) to more tightly reuse the spectrum for coverage in high population density regions. Such a configuration may be adopted for services for remote cellular-based IoT devices (e.g., GSM-based or LTE-based) that can be purchased cheaply. For IoT use cases, the lower signal level requirements allow for a lower EIRP at the satellite end of the link to close the downlink at the desired data rate. The lower EIRP allows for some reduction in the tradeoff between satellite Tx power requirements and antenna size. The size of the antenna may drive other design factors in the network, such as antenna directivity and beam width, and hence 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, to achieve ubiquitous and continuous coverage of the planet. Each satellite equipped with multiple spot beams provides coverage for the total area of ​​the Earth bounded by the spot beams, referred to as the coverage area or coverage footprint. [A.1 Determining the optimal number of satellites]

[0163] A satellite network may be designed with multiple satellites, each with some coverage footprint, and multiple potential spot beams for each satellite. If the number of satellites is limited, the coverage footprints do not overlap and terrestrial service may be intermittent. This may be useful for certain use cases in remote areas of the world where terrestrial coverage does not exist. Depending on the satellite orbit and footprint size (as well as how the beams within the footprint are operated), there may be anywhere from 1 to 15 minutes of coverage time from a given satellite in the network. Depending on the number of satellites and the number of orbits they are in, this level of connection may occur once every 12 hours, 6 hours, hour, 30 minutes, 10 minutes, minute, etc. As more satellites are added to the network, the connection may become less intermittent.

[0164] As an example, Table 5 below may illustrate how the number of overpasses, connection minutes, and time between overpasses may be estimated as a function of the number of satellites. In this particular example, a satellite in a 503 km circular orbit around the Earth, inclined at 51.6 degrees relative to the equator, is analyzed. The satellites would be equally spaced around the Earth in three unique repeating ground tracks. In this analysis, the satellite base stations are assumed to have a minimum elevation angle of approximately 45 degrees, which represents the satellite footprint. The range of values ​​in each row and column in Table 5 may correspond to variations in service at the equator and above (or at lower latitudes). Specifically, in this case, the better service numbers (more overpasses, longer connection times, and shorter intermittent intervals) correspond to all longitudes at approximately 51.6 degrees north or south latitude. The worse two numbers correspond to all longitudes relative to the equator. [Table 5] [A.2 Orbit configuration]

[0165] The space-based infrastructure may be located in a variety of different orbits, possibly GEO, MEO or LEO. GEO orbits may be circular in shape and may operate at an altitude of about 35,786 km above the Earth's surface. GEO orbits may be equatorial or inclined depending on the desired coverage dynamics of the Earth or other orbiting spacecraft below. MEO orbits may also be circular and inclined to some degree relative to the equator at altitudes between the upper edge of LEO (at about 2,000 km altitude) and the upper edge of GEO (at about 35,000 km altitude). LEO orbits may also be inclined depending on coverage requirements and may operate at altitudes between about 250 km and 2000 km. Below an altitude of 450 km, atmospheric drag is a significant driver of spacecraft propulsion requirements.

[0166] In general, the inclination angle corresponds to the desired latitudinal 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 an inclination of 51.6 degrees (the inclination of the International Space Station), 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 the Earth angle of the coverage footprint in degrees north and south latitude.

[0167] Highly eccentric orbits may be used to provide repetitive but extended coverage of specific regions or lower orbits within a network. Highly eccentric orbits provide slower travel speeds in the higher altitude portions of the orbit (providing extended or more protracted coverage) and faster travel speeds in the lower altitude portions of the orbit. The location of the higher altitude portions of the Earth in an eccentric orbit may move relative to the Earth or the desired coverage area. Highly eccentric orbits are affected by precession of the argument of perigee. However, when inclined by 63.4 degrees to the equator, this secular precession is eliminated. Such orbits may be known as Molniya orbits and may be used to fix orbital residence times over specific regions on the Earth or in lower orbits (such as LEO).

[0168] Different orbits may be used in constellations where GEO, MEO and LEO or some combination thereof host different network elements through ISLs and ground stations for the space network that serve the same UE subscriber pool and communicate with the terrestrial network while providing mobility management. [A.3 Space network deployment phase / style]

[0169] A space-based RAN can be deployed as its own network with its own spectrum assets, making deployment of its RAN frequency licenses relatively simple, especially with a small number of satellites.

[0170] Alternatively, a space-based RAN may be deployed as a global shared roaming network where, in agreement with the MNO, there is a sublicense for the use of existing terrestrial MNO spectrum. In this case, when the space component is not strictly assigned spectrum, the deployment of spectrum may require dynamic coordination with the terrestrial MNO network. This may not be desirable 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 terrestrial network may have spectrum available that would otherwise operate while above orbit. As a result, it may be desirable to know when a particular satellite is in and can provide overlapping coverage with existing terrestrial cells in the network below.

[0172] In addition to the advances in phasing the constellation of base stations described herein, novel methods may be used to calculate ideal operating procedures / courses for satellite networks 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 terrestrial regulations and to avoid interference with each other and other terrestrial cells. Additionally, each satellite in a constellation (or perhaps even a selected "population" or "production run" of satellites) may have different technical capabilities. Examples may include maximum power consumption requirements, orbit average power intake, battery capacity, spectrum bandwidth it can deploy, payload / base station duty cycle requirements, thrust, attitude control, memory, processing power, etc.

[0173] Variations in technical capabilities among spacecraft in a shared communications network can be handled using these techniques. This can be useful when the constellation is in the construction phase. It can take years to launch a constellation of thousands of satellites, during which developing a small group of satellites to provide the first services for a specific use case can be a revenue generating venture. A particular example can be an IoT / M2M use case that can benefit from connectivity in remote areas in an intermittent and inconsistent manner. There can also be other use cases for intermittent services, such as store and forward SMS messaging from a handset.

[0174] For early use cases, fewer and less capable satellites may be desirable because it may reduce capital investment costs. Such an example may be a beamforming array, which may take time and money to develop successfully. As a result, an initial constellation consisting of 12 or 24 non-beamforming satellites may be deployed into LEO for initial service. Over time, new satellites may be developed and launched, but older designs may continue to operate. Design considerations may be incorporated to ensure software compatibility (or upgradability) of the first new satellites so that their software can operate symbiotically together.

[0175] Over time, as new satellites are phased in and out, their capabilities can be individually recorded in a database utilized by this disclosure and described below. As this information is added and updated, the calculations performed as described herein can accommodate changes in operation. [A.4 Network Architecture Examples]

[0176] Space networks may have a similar structure to terrestrial LTE networks, but with some extensions and using an architecture with further elements mainly internal to the EPC and E-UTRAN. The extensions allow optimal functioning of the space-based cellular networks, but they maintain the ability to communicate with standard terrestrial networks on Earth without necessarily requiring any modifications. However, there may be embodiments, as examples, in which the terrestrial mobile networks are also extended to be compatible with more sophisticated spectrum sharing technologies, as with the space-based networks. Furthermore, there may be enhanced UEs in another embodiment in which the end user handsets are modified with the extension of the space-based cellular networks in mind. As examples, they may be provided through the EPC (either terrestrial or space). With the control plane or user plane (e.g., handset application), predictable overpass opportunities by the space network. This may be advantageous to optimize the network scanning procedure to facilitate connection to the space network when the UE knows that it may be available.

[0177] The network architecture extension in one embodiment may involve MME, base station, HSS, and possibly UE. Additional elements may be added to the space network architecture in this embodiment that directly affect or are affected by the operation of the network nodes in the space-based infrastructure. These additional elements may include a network database (NetDB), network telemetry, tracking, control, command and data handling (TTCC&DH) functions, and spacecraft flight software systems. Additional elements in the space network may be interfaced to the extended MME. This interfacing may be done in software.

[0178] A space network may operate as a set of distributed infrastructure components on satellites and ground stations around the Earth. Each spacecraft may host a flight computer or a set of computers that may interface to a network switch that can access the inter-satellite link radios on the satellites and ground station radios when they are available. Each flight computer may be assigned to a specific network node function (e.g., enhanced MME, S-GW, P-GW, etc.), or a single flight computer may use those functions in one package as a "network in a box." A single computer may be able to run a hypothetical instance of a base station (possibly multiple base stations), enhanced MME, enhanced HSS, S-GW, P-GW, etc. Another computer may host TTCC&DH software and flight software for functions such as guidance, navigation and control (GNC), etc.

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

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

[0181] Each ISL and each GSL tunnel may actually comprise multiple bearers, one or some of which may be dedicated to network control plane traffic, network user plane traffic, flight computer telemetry, tracking, command, etc. Bearers may be established in a weighted manner based on priority and given available bandwidth any data rate link may be established for the air interface. As the satellite orbits around the Earth, moving relative to ground stations and other satellites in the network, tunnels may be handed over between re-established nodes and bearers. Each spacecraft may have some memory buffer to accommodate incomplete handovers with gaps in complete tunnel connectivity to a serving access point name (APN) for the Internet, as an example.

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

[0183] FIG. 10 shows the space network architecture in terms of hardware. The hardware may be hosting the space network architecture. There may be satellites 1012 and 1014 in the network and ground stations 1016 in the network. The satellites may be connected to each other through ISL 1002, which may be an IPv6 bearer tunnel in one embodiment. These tunnels may be assigned a specific bandwidth that is divided across bearers for different functions. There may be bearers in each inter-satellite link tunnel for each interface that may otherwise be handled in prior art ground networks. In particular, there may be bearers for the network control plane 1006 (with X2-CP, S11, S10, S6a, S5, further control interfaces, etc.), the network user plane 1008 (with X2-UP, S1-UP, S5, further control interfaces, etc.), and the TTCC&DH plane 1010 (with one or more network interfaces). The satellites may be connected to the ground stations through GSL 1004.

[0184] These GSLs may be IPv6 bearer tunnels or may be divided by bearers for specific network planes. To create connections and establish these tunnels, each satellite is equipped with radio and other equipment. ISL radio 1018 and GSL radio 1044 are used to communicate with other satellites and ground stations, respectively, and to implement PHY or L1 protocols for ISL and GSL. Each satellite may include other computers, such as a network computer 1022 or a flight computer 1038, which run software implementing specific functions. For example, the network computer may implement a state space database 1024, an enhanced HSS database 1026, an enhanced S-GW and P-GW 1028, an enhanced MME 1030, and an enhanced base station 1032. The enhanced base station 1032 will implement a PHY for the LTE-Uu interface link 1034 and control a radio compatible with existing standard UE 1036. The flight computers 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 functionality and in some cases do not host the entire flight software package hosted on the spacecraft. In some embodiments, the ground stations may implement the flight software. [A.5 Satellite platforms hosting mobile network infrastructure]

[0185] A spacecraft in orbit providing the infrastructure for the described mobile network may comprise several structures housing electronics such as computers, radios, processors, memory, wires, cables, actuators, etc. The spacecraft may use an on-board 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 (to implement the RAN and / or core network) that controls the radio interface connected to the computer. The operating system may also host software that simultaneously controls the command and data processing system on the spacecraft that collects telemetry and data from sensors or calculated in software, and processes commands that are executed 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 (reaction wheels, magnetic torques, etc.) that manage its attitude and actuators (e.g. thrusters) that manage its speed / trajectory on orbit. Actuators may also be used to extend or retract deployable structures on the spacecraft.

[0186] The spacecraft may have solar panels that collect solar power to charge batteries and distribute the necessary energy to various components within the spacecraft that the spacecraft requires 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 include position, velocity, acceleration, orientation, battery capacity, power from arrays, mass, mass of fuel, inertial matrices, component health / telemetry readings, etc.

[0187] A spacecraft may host an on-board GPS receiver for tracking and calculating its velocity, position and acceleration. If GPS is not available (e.g., when the satellite is over GEO or, in some cases, too high over MEO), other techniques may be implemented, such as signal ranging and Doppler measurements at known ground stations in specific locations, to provide the spacecraft's position and velocity data to its internal computer. On-board sensors, such as star trackers, IMUs, cameras, horizon sensors, gyroscopes, etc., may be used to calculate the spacecraft's orientation in a specific coordinate system, such as geocentric inertia. Additionally, these on-board sensors may be able to calculate the angular velocity of the spacecraft as it rotates in inertial space.

[0188] A spacecraft may be equipped with a control system that may be programmed to perform specific tasks related to pointing, such as, for example, rotation, inertial preservation (e.g., maintaining a constant orientation in inertial space), nadir / zenith pointing preservation, etc. Additionally, the control system may implement orbit position and preservation control, possibly based on the output of a state space prediction engine to determine optimal maneuvers during flight. The control system may implement a Kalman filter to improve state measurements and may perform specific maneuvers for specific time periods based on a control law, such as one implemented by a PID controller.

[0189] The spacecraft is assigned its pointing vector in the spacecraft's body coordinate system.

number

number

[0190] A spacecraft platform may have numerous systems for which an 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 harvest, power consumption, operational modes, software application status, etc. Telemetry from the spacecraft may be processed to determine the functionality of the satellite and any operational constraints as a result of failures. In particular, the satellite or ground system may use telemetry intelligence to eliminate or impede the ability of the spacecraft to create connections with other satellites, terrestrial gateways, or UEs. This may be used to generate logic to automatically toggle on and off node connection opportunities in a network state prediction engine based on telemetry downlinks from the satellite. [B. Enhanced Mobility Management Entity (MME)]

[0191] In a cellular network, a coverage area where a UE may expect to connect to the cellular network infrastructure may be a coverage area that is divided into cells, with some cells overlapping with other cells and coverage areas, and possibly surrounding some areas that do not have any cell coverage. Typically, a cell within a coverage area may be considered static, such as when the coverage of the cell comes from the presence of a fixed tower or fixed transceiver with a fixed location and fixed capabilities. Such transceivers are typically deployed where coverage is expected and / or where it is cost-effective given that a large number of UEs are expected to be present in those cells.

[0192] In wireless networks served by orbital stations, the coverage areas can be expected to change over short periods of time as satellites closer to the Earth's surface than GEO move relative to the Earth's surface. The different characteristics of terrestrial-based cellular network nodes and orbital-based cellular network nodes need not be a concern if they use distinct protocols and communication standards in that the two networks can coexist by avoiding interference overlap using different frequency bands, different coding, etc. However, if the terrestrial and orbital network nodes use the same protocols and communication standards to allow a UE to seamlessly close a link with the orbital network node using the same protocols and communication standards that the UE uses to close a link with the terrestrial network node, coordination and coexistence becomes more complex in part due to the movement of the orbital network node's orbit. As described herein, this can be resolved with coordination between the network nodes.

[0193] A coverage area for an air network, providing radio coverage for UEs residing within the coverage area, may be logically represented by a number of polygons. Although reference is made to polygons, it should be understood that the methods and apparatus described herein would work equally well with closed shapes that are not strictly polygonal, such as ellipses, circles, and irregular shapes having some curved 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 expected use, jurisdiction applicable to a particular polygon (e.g., a polygon covering part of a particular country, a polygon covering the open ocean with no legal jurisdiction itself, etc.), and / or feasibility of coverage.

[0194] In some embodiments, the coverage area is first characterized by a set of mesh points, which are aggregated into polygons, while in other embodiments, polygons are defined without necessarily referring to mesh points. In a database representing a set of polygons, a polygon-based record may include details regarding the polygon's boundaries, legal jurisdictions applicable within the polygon, protocols and standards to be used when establishing wireless links within the polygon, and other information about the polygon. The mesh may comprise a grid or some other manner of virtually representing, such as a finite element model of the Earth or a set of polygons. The coverage database may comprise mesh points and polygon coverage areas. Polygonal coverage areas are referenced in the coverage database for each base station, including at least some static coverage terrestrial base stations, at least some static coverage orbital base stations that use beamforming, and at least some dynamic coverage orbital base stations that use dynamic beams that move across the coverage area as at least some of the dynamic coverage orbital base stations move on their respective orbits.

[0195] If a coverage area is supported by both terrestrial and orbital network nodes, these nodes may be coordinated. In an example, the terrestrial network node is a transceiver that is part of a cellular network broadcast tower, and the orbital network node is a transceiver that is part of a satellite. The tower may support multiple nodes, and the satellite may support multiple nodes. The coordination may be done by a mobility management entity. The mobility management entity may be in the form of a computer system that runs software and has communication channels that allow the mobility management entity to get information from the nodes and send information to the nodes. In one approach, the mobility management entity (MME) calculates a set of polygons for the coverage area over a particular period of time, and can do this in advance of that period. This allows enough time for the details of the set of polygons to be propagated to nodes that will use the information before they need it.

[0196] The set of polygons may be calculated according to processes described elsewhere herein, but may take into account the predicted conditions of the nodes on the satellite (e.g., location, power, orientation, whether the nodes can maintain constant beams in the coverage area as the nodes themselves move through space, etc.). As described herein, as the nodes move, the set of polygons may change, and the nodes assigned to cover link needs within a particular polygon may also change. If a first node is assigned to cover link needs within a polygon and a second node is not, 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 in which the first node is assigned to cover those link needs.

[0197] A node may be scheduled not to operate during certain periods within a time division multiplexing frame, on certain frequency channels, in certain time slots, etc. taking into account a set of polygons and other data available to the MME. If a node is an orbital node (and perhaps this applies to terrestrial nodes as well), the node may be scheduled to be inactive for a particular time based on the power or lack thereof available to the node, heating at the node, and other considerations taking into account the operating conditions of the node available for the coverage area.

[0198] Some orbital nodes may have beamforming antennas that allow the beam to remain over an area of ​​the Earth's surface for a period of time, while other orbital nodes 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 an area of ​​the surface. When an orbital node's beam is covering or approaching the coverage of a particular polygon, the orbital node may be assigned to handle the link needs of UEs in that particular polygon, while terrestrial 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 done 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 completely destructively.

[0199] By having the MME obtain state information, calculate allocations, and communicate those allocations in advance, the cellular network can operate efficiently even when some of the nodes of the network are in orbit, moving rapidly with respect to and overlapping with terrestrial nodes, some of which may be much closer to the UE than the orbital nodes. In some cases, there may be some moving terrestrial nodes, e.g., drones, balloons, etc., but they may be treated as stationary with respect to the orbital nodes.

[0200] More specific extensions of the MME are described here.

[0201] To generate actionable intelligence about 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, satellite navigation, guidance and control, payload operations, RF link budgets between distinct network nodes, etc. This actionable intelligence can be inferred from the simulations and packaged into time-based stored command-like events that initiate or trigger network signaling events in the MME, base station, or even the UE. This can optimize network routing, network node connectivity, network infrastructure power consumption, spectrum resource allocation, base station operation, spacecraft operation, etc. The desired optimization algorithms can be stored as a database. This database can be readable and writeable so that it can change over time and can be accessed and reconfigured (e.g., by the NOC) in response to external changes / influences such as emergencies / disasters.

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

[0203] The Historical Network State Space (HNSS) database may contain historical data including satellite positions, velocities, attitudes, attitude rates, network operations / status, and network log files. The HNSS database is notified by the TTCC&DH system when satellites have downlinked their telemetry data or when satellite telemetry data has been collected.

[0204] The Network Model (NM) database may contain data that characterizes the environment that needs to be simulated and the operational capabilities / operational characteristics of each of the satellites in the network. As satellites are added to the network, and as satellites malfunction or fail, the status of each spacecraft's operational characteristics may change due to anomaly telemetry from the NOC or TTCC&DH systems.

[0205] The Constellation Location Register (CLR) database is a space-based correspondence with HLR features and stores location information for UEs and network related points of interest. UE location information can be updated with 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 relevant points of interest for network operations.

[0206] The Constellation Policy and Rules (CPR) database stores information about flight operating rules for the network space hardware, as well as policies and QoS requirements for the associated virtual points of interest for the network. The CPR can be updated by the NOC.

[0207] These four databases contain information used by the network state space prediction engine, which uses orbit dynamics processes, spacecraft attitude dynamics / control processes, and link budget / RF system processes to accurately simulate and predict the state of the space-based network in future time periods. The network state space prediction engine may utilize several optimization processes that optimize the network operation based on policies, rules, etc. in the databases.

[0208] The network state space prediction engine may generate a series of itineraries for various elements in the space network. In one embodiment, there may be three separate sets of itineraries. One may be spacecraft itineraries that may be for use by flight software in the space network. Another may be core network itineraries that may be for distribution to an enhanced MME function in each satellite. Finally, there may be RAN itineraries that may be for use by base stations in the satellite network. Since each spacecraft hosts an EPC and / or base station, these itineraries may be packaged into a common database called a state space (SS) database. This database may be distributed throughout the network for use by each of the spacecraft.

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

[0210] 12 is an illustration of a historical network state space database 1202. The database 1202 may include recorded positions 1204 of the network satellites, recorded velocities 1206 of the network satellites, recorded attitudes / orientations 1208 of the network satellites, recorded attitude rates 1210 of the network satellites, recorded network state space data 1212, and recorded network log files 1214. [B2. Base Station, UE and GS location and velocity database]

[0211] FIG. 13 illustrates scenarios of various platforms in 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 utilizing a communication system (e.g., antenna and RF front end) that may close a communication link to a standard UE 1330 utilizing a certain 3GPP protocol such as GSM, EDGE, CDMA, LTE, etc. The orbiting base station may maintain a connection to the ground via a ground station IP switch 1328 for access to the Internet and other MNO provider networks. The orbiting base station may provide a location

number

number

number

number

[0212] The network computer or orbiting base station may maintain a representation of the position of the orbiting object in inertial space, perhaps represented as a vector of size 3×1 to represent the position of the satellite in a three-dimensional coordinate system, as shown in Equation 1.

number

[0213] The network computer or orbiting base station may maintain a representation 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 may store representations of position, velocity, acceleration, etc. One storage method 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 in a 3×1 vector representing rotation in degrees about three axes represented in a rotating or fixed reference frame. One representation uses roll, pitch, and yaw to represent the axial rotation of the rotating body about the z-axis in the vehicle frame, then the y-axis in the vehicle frame, and finally the x-axis in the vehicle frame (often shown as z-y'-x'' rotation). Another representation uses nutation, precession, and spin to represent the axial rotation about the z-axis, then the x-axis, and then again the z-axis (zxz) in a fixed frame. Yet another representation stores the orientation or attitude information as a quaternion, which is a 4×1 vector representing the rotation axis and angle. An orientation vector of an orbiting body stored as Euler angles may take the form shown in Equation 4.

number

[0215] An orbiting object typically hosts an Attitude Determination and Control System (ADCS) that can determine and then control (using actuators to provide torques to the spacecraft rigid body) its orientation in three-dimensional space. Using this system, attitude reorientation maneuvers can be planned, and the angular velocity of the base station can be controlled.

number

[0216] An orbiting base station may provide coverage to UEs within a certain coverage footprint 1326 on the ground. This coverage footprint may include single or multiple spot beams utilizing multiple apertures, phased arrays, etc. techniques to provide sufficient RF coverage.

[0217] Below the orbiting base stations there may be drones 1308, balloons 1306 or other base stations operating on towers 1304 that also have a position, velocity, acceleration and orientation in inertial space or possibly in an Earth fixed coordinate system. Like the orbiting base stations, they will also have a coverage footprint possibly including a coverage area generated by multiple antennas or arrays. In addition to base stations there may also be UEs 1330 that also have a position, velocity, acceleration and orientation in a coordinate system.

[0218] Since the position and velocity of each base station is known, calculations can be made for vectors that define the position and velocity of each base station in the network relative to each other. Similarly, the position and velocity of each UE is known, allowing calculations for vectors that represent the relative position and velocity of the UE with respect to the orbiting base station. For example, these vectors that represent the relationship between the orbiting eNB and the UE can be the relative position 1318, relative velocity 1320, and relative acceleration 1322.

[0219] In current cellular architectures, the GPS location of transmitter towers is often recorded and stored so that relative location via triangulation can produce a specific location result based on a known coordinate system. The UE's location is tracked at some network level, but with less precision than a network location code and network location ID that identify a specific serving tower or serving transmitter or serving base station. Tracking may be limited to only the serving MME, in which case only a specific region or area covered by any of the base stations under control by that MME may be specified. As a result, a typical terrestrial network has no knowledge of the UE's location and velocity over the RF air interface and control plane. Some applications may log GPS locations and allow back-end tracking via a server. However, in these scenarios, a user can only be tracked if they have connectivity to an appropriate IP server that is tracking GPS readings for the device.

[0220] As described in Speidel I, the proposed orbiting mobile network can implement air interface measurements based on RF signals from the UE on the RACH (e.g., handset GPS is not required) to measure position and velocity accurately enough to store and maintain a database of these state vectors that can be used for mobility management, as described in more detail herein.

[0221] The proposed architecture using orbiting base stations presents the challenge of having to manage network communications and traffic routing with a network infrastructure that is constantly and very rapidly moving. However, with sufficient modeling combined with orbital mechanics and telemetry measurements, accurate prediction of the future state vector for the entire orbiting base station constellation can be possible.

[0222] The database of network element locations and velocities may also include the locations and addresses of the many ground stations that serve the satellite network. The database may even store the orientation of the gateway in a coordinate system that relates the direction the antenna is pointing to the coordinate system in which the satellites are tracked. [C. Description of the Network Model (NM) Database]

[0223] 14 shows a network model database 1402. The database may include a model of the Earth's gravity 1404, a model of the Earth's atmospheric density 1406, a model of the Earth's magnetic field 1408, a model 1410 of the spacecraft bus system, a model 1412 of the spacecraft actuators, e.g., thrusters, attitude control, etc., a model 1414 of each antenna in the network on each spacecraft, mainly the antenna radiation patterns of the link budgets, and a model 1416 of the solar system, including the positions of the Sun, Moon, planets, etc. [C.1 Earth's Gravity Model]

[0224] A database of Earth gravity field models may be utilized such that the force from the Earth's gravity on the satellite may be based on the presence and future position of the satellite. The Earth gravity model may take a variety of forms, some of which offer a trade-off between accuracy and timeliness of calculation. For example, a simple spherical gravity model of the Earth may be implemented, a WGS-84 elliptical gravity model of the Earth may be implemented, or an n-th order summation of terms with coefficients that describe the Earth's band harmonic gravity field may be implemented (e.g., harmonics through J4 may be sufficiently accurate). Various options offer different fidelity and timeliness of calculation of acceleration. Many models may be stored such that a function may 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 gravity gradient force on the satellite may be equal to the cross product of gravity acting on the satellite and a vector representing the location of the satellite's center of mass relative to the satellite's center of gravity. As in Equation 5, gravity acts through the satellite's center of gravity and the satellite rotates about its center of mass.

number

[0226] Atmospheric models of the Earth may also be stored to aid in the calculation of orbital and attitude perturbations due to drag. There may be one or many atmospheric models implemented, e.g., NRLMSISE-00, Jacchia, JB2008, etc. The outputs of these models to aid in state space predictions may be density and temperature. These are the atmospheric properties that drive the atmospheric drag forces on the satellite. In addition to atmospheric density, the satellite's ballistic coefficient also drives the calculation of atmospheric drag.

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

number

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

number

[0229] The Earth's magnetic field may also be modeled. This model may be useful when magnetism is used on a spacecraft for attitude determination and control. This is particularly useful in LEO orbits, where the Earth's magnetic field is an absolute value that is easy to both measure and impose using on-board magnetic torques. Magnetic field models can take a variety of forms, as can models of the Earth's gravity. This model allows the satellite's position to be determined by the magnetic field.

number

number

[0230] As in Equation 9, the torque resulting from the magnetic force on the satellite may be equivalent to the cross product of the spacecraft's magnetic dipole (induced intentionally by magnetic actuators, but also unintentionally by electronics on board the satellite, etc.) multiplied by the magnetic field around the satellite at that time.

number

[0231] The spacecraft bus model may include data regarding the specifications of the spacecraft subsystems. The amount of data that may be stored about the technical characteristics and performance of the spacecraft is enormous, but the following describes a list of some data that may be useful in applicable embodiments. The spacecraft bus model will be informed by the TTCC&DH system because telemetry is obtained from the spacecraft during operation. However, at the start of the service life, the model may be established based on the initial performance after ground testing, as an example.

[0232] There may be structural / mass information about the spacecraft in the database. The spacecraft bus model may store the spacecraft 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 inertial state matrix may be improved with on-board measurements on the spacecraft, since it measures attitude rate values ​​from known torques applied to the bus. As maneuvers are performed, errors may be measured in the modeled changes in the satellite's angular rotation rate (which may be used to measure disturbance torques) and / or changes in the inertial state matrix. In addition to mass values, the spacecraft's inertia tensor may also be stored. This may be a 3×3 array representing the spacecraft's moment of inertia. There may also be structural information about the spacecraft's thickness and structural size and its attachments. If the power and thermal simulations in the extended MME were to utilize Parasolid in finite element analysis simulations, even a Parasolid model of each spacecraft may be stored.

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

number

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

[0235] The database may also store thermal information about the spacecraft. This may be quite simply vectors for each surface of the spacecraft holding the absorptivity and emissivity values ​​for each surface. There may also be other vectors representing thermal conductive paths throughout the spacecraft.

[0236] The power system may also be modeled, where the spacecraft's power consumption is quantified when operating in a particular mode or as a function of which components are receiving power distribution. The batteries may also be modeled, where test charge and discharge rates and curves are recorded (and updated from telemetry after on-orbit operation). This information may be used in the power simulation to ensure that the network state space predictor does not command the satellite to operate outside of its limits on power consumption and storage capacity. [C.5 Spacecraft actuator model]

[0237] A database storing actuator models can quantify thruster performance, actuator attitude control, etc. There may also be data stored about actuators for the deployment of other systems such as antennas and solar arrays.

[0238] For a propulsion system, the database may include mechanical information about the vector actuation provided by the thrusters. This may be a vector in the spacecraft's body coordinate system. The propulsion system may also have performance, e.g., thrust, Isp, mass flow, etc., possibly as a function of operating regime (e.g., pressure, temperature, power input, etc.). Fuel quantities will be monitored during flight to inform / update the model based on measured changes in thrust, power, etc. from actuation performance.

[0239] For an attitude control system, the database may be a set of vectors that describe the mechanical layout of the attitude control system. For reaction wheels, these vectors may be normal vectors to the wheels in the spacecraft's body coordinate system. For torque coils, this may be the plane of the coil. Other information about the system may be stored, such as the torque that can be applied as a function of the operating regime (e.g., current applied to the actuator, etc.). [C.6 Network antenna orientation database]

[0240] A spacecraft used for a space network may host a set of antennas for communication between terrestrial base stations and UEs, between an orbital base station and other base stations (or possibly an orbital MME) via an ISL (ISL), and / or between an orbital base station / MME and further MMEs, terrestrial gateway antennas acting as P-GWs or S-GWs. When the spacecraft is designed, the selection of the locations of these antennas is typically known and documented and may be stored in a database where individual spacecraft design characteristics may be stored.

[0241] Antennas on spacecraft may be of various types or of one type. Analog antenna technology allows antennas to be physically pointed in a particular direction to generate an RF radiation pattern that represents directivity or gain as a function of the orientation / angle (typically its direction / pointing) relative to the antenna's boresight. Antennas that behave in this way may be parabolic, horn, helix, quadrifilar or patch antennas. Digitally steered antenna arrays may also be used. Digitally steered antennas, or phased arrays, may comprise multiple analog elements such as helixes, patches, dipoles, etc., arranged in an array. This allows spacing to accommodate specific gain requirements for a particular bandwidth of use. Phased arrays may have a mechanically fixed orientation that defines the boresight, but the beam may be digitally steered off from that boresight vector by offsetting the phase of the signal transmitted through each element in the phased array. Thus, phased arrays are a single, well-known, and widely used, technology.

number

number

number

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

number

number

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

[0244] FIG. 15 illustrates how a spacecraft 1502 may host various antenna beams for use in generating an ISL connection, a GSL connection, or a connection to a UE. The spacecraft's body reference frame 1506 may be oriented with respect to some other reference frame 1504, such as a geocentric frame, an Earth-fixed (ECEF) frame, etc. Antennas supporting various communication paths may have physical orientations on the body of the spacecraft. When these antennas are in a particular orientation, as an example,

number

number

number

number

number

number

[0245] The relationship of the beam vector to the antenna pointing vector can be defined as a rotation matrix that corresponds to certain axes and angles with respect to the spacecraft body coordinate system. It will also correspond to a certain phase shift of the RF network behind the antenna. This allows for beamforming. The relationship between the phase shift and the beam offset from the antenna aperture vector can be stored in a database.

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

number

number

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

[0248] For a phased array antenna, the radiation pattern may be stored as a three-dimensional matrix of dB values ​​represented by rows, columns, and lanes, where the rows and columns indicate angular offsets in the E and H fields relative to the direction of the beam being formed by the array, and the lanes indicate the radiation pattern at a given phase offset for beamforming at a particular angle from the boresight.

[0249] As in Equation 11, the gain provided by a beam in a particular direction, e.g., towards a UE, can be modeled by the three-dimensional matrix described previously, such that the function can be called using vectors representing the satellite orientation, antenna orientation, beam orientation, and the UE's position relative to the antenna.

number

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

number

[0251] The constellation location register is a database that holds much of the information needed by the state space prediction engine to analyze the coverage dynamics of a network base station transmitter. This database may be implemented as a list of locations relative to the surface of the earth that the network covers.

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

[0253] The space-based network components 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 so generated randomly, perhaps once or repeatedly. Alternatively, this mesh may represent a structured grid around the Earth. For example, a mesh of 1 million evenly spaced points around the Earth may provide the geospatial fidelity of about a 500 km square grid (about 22 km by 22 km square).

[0254] In certain embodiments, the mesh may be weighted based on population density where cells are smaller and more tightly packed, and the mesh may be created for specific refinements in analysis of network performance in particular geographic locations, and thus the mesh is densified in certain areas.

[0255] In another embodiment, many meshes may be created and filtered based on type (eg, only shipping routes, only specific countries, only specific states, 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 have zero rules, or many rules, such as what frequencies may be used there, or how much signal energy may be radiated to that point in the mesh over a particular 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 terrestrial cells described by center points representing terrestrial base station cell edges. 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 coverage protocol (e.g. GSM, LTE), frequency, antenna gain, RSSI from the cell and neighboring cells at each point inside / top of the polygon.

[0258] Additional polygons may be stored in this database that represent target coverage cells for the space network (e.g., specific geographic regions that the network provider has agreed upon to be deployed in because no other towers have spectrum deployed there). These coverage cells may be static on the Earth's surface and may correspond in diameter to the size that a set of antennas on an orbiting base station can cover at that frequency (e.g., orbital height, gain, and beamwidth). These polygons may be stored with center and edge points with specific latitude, longitude, and altitude coordinates, as well as a series of additional data points. For each of these data points, there may be what frequencies can be licensed for use by the space network at that location, the 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, adjacent cells, RSSI of adjacent cells, MCC, MNC, LAC, etc. Specific polygons may be created in the database to indicate coverage areas, which may be geographic areas of common coverage requirements (e.g., frequency, etc.). Each polygon may be described by a center point and an edge point to define which points it covers or contains within the mesh. The data stored for the center point may be different from the data stored for points at the edge of the polygon (e.g., RSSI at the center may be different from RSSI at the edge).

[0259] FIG. 17 shows how a mesh database of points may be implemented. Shown is a set of points that may be points in a mesh. Each point may be stored as a vector with three values ​​that indicate a position vector in the ECEF coordinate system. There may be some satellites 1722 in orbit that have beam steering capabilities. There may also be other satellites 1724 that do not have beam steering capabilities. The beam steering array may point to a static polygonal terrestrial base station cell 1710 that may be described as a set of points of a mesh that are contained inside the polygon 1712 and on the edge 1708. The array without beam steering may use spot beams relative to the moving earth. These may be described in the database as dynamic polygonal base station cells. Similarly, the static cells may have points of a mesh that are contained inside the dynamic cell 1714 and some on the edge of the cell 1716. The terrestrial base station polygons may be stored 1706 and they may also have mesh points inside them 1704 and on the edge 1702. In some embodiments, the location of the UE 1720 may also be included within 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 Polygon position and velocity database]

[0260] An orbiting mobile network may utilize a database that contains information about specific polygons or service areas on the Earth's surface that are of some importance. As an example, a static polygon on the Earth's surface may represent a license region for a particular frequency used by an orbiting satellite network. Alternatively, there may be polygons that define a particular service area that requires a particular level of service (e.g., data rate, data rate per square kilometer, etc.) from an orbiting transmitter to meaningfully serve that region. Some polygons in the database may be in motion, and thus the location and velocity are changing over time. This may be, as an example, another satellite coverage footprint. [D.4 Static cell coverage zones]

[0261] The coverage areas for the satellites may be predefined as specific latitude and longitude polygons on the surface of the Earth. These polygons may be large or small based on several requirements based on the available spectrum from the satellite and the population density of the desired coverage area. Ideally, the polygons would be a shape based on some known radiation patterns of the aperture at various attitudes while on orbit so that the beams can be well-fitted against the polygons defined on the ground. The polygons may or may not overlap. If the interference mitigation control of neighboring cells is sufficient, a slight error of about 1 dB or 2 dB in the signal energy radiation to the surface of the Earth should not indicate a problem for the network. Alternatively, the apertures may utilize a phased array, which would allow the spot beams to be clearly articulated off boresight by an angle relative to the antenna's normal vector. These polygons may also be driven by regulatory requirements, wireless transmission license boundaries, service area requirements and / or satellite constellation design. The polygon may be as small as an individual spot beam with certain characteristics (e.g., a peak signal, then falls off to the cell edge), or as small as the border of a country, or even as large areas / swaths across the planet where the signal requirements from the space network are constant (wide spread) and minimal (low signal energy).

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

[0263] Since the coverage zones are defined in the database as specific shapes with specific center points, this can be used on the satellite end of the link to inform how coverage should be optimized. Each coverage zone can receive a defined level of service (e.g., what signal level is desired at least in that cell for service by the satellite). Due to the defined service level and coverage area defined by the polygon, each satellite in the network may not be equipped to provide coverage to the polygon, and will ignore the polygon and provide coverage to other areas that it is intended (and designed) to provide coverage to. Satellites that can provide coverage to the polygon may be documented in the database, as well as perhaps the configuration that the satellite needs to provide the minimum coverage requirements desired (e.g., number of beams required for coverage). In particular, the exact locations where the spot beams would need to be centered may be specified in the database (e.g., to cover polygon Y, a first spot beam may be directed to certain coordinates and a second spot beam may be directed to other coordinates).

[0264] If an attitude determination system is used to rotate and orient an antenna at a particular location on the Earth, the angle of rotation 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 the Earth, the coverage may correspond to this expansion and thus possibly take the form of an ellipse on the Earth's surface. [D.5 Dynamic Cell Coverage Zones]

[0265] A satellite without beamforming capabilities may not be able to easily point a beam at a static polygon on the Earth's surface. Instead, the satellite may transmit a beam from an aperture that always points in the same direction relative to the spacecraft's body coordinate system. In a scenario where the satellite is controlled to point its antenna toward the nadir, this would result in a spot beam that traverses the Earth's surface in a passing motion. Thus, over time, the position of the polygon covered by the satellite transmitter is dynamic with respect to the mesh representing the Earth, and the edges and center of the polygon may be at different mesh locations in the database at different times.

[0266] As dynamic cells move relative to the Earth, dynamic polygons will be moving over mesh points on the Earth's surface with varying policy requirements and so on. As an example, there may be large mesh swaths that define the total area between the middle of the Atlantic Ocean and the middle of the Pacific Ocean, and mesh points within those polygons may have the same policy requirements for one sliver of spectrum that dynamic cells may use as they pass through the large swath of the Earth. In other words, network spectrum allocations may be distributed with looser rules over a wide swath to accommodate dynamic cells passing through the Earth, and to more strictly allocate more spectrum to static polygons. If a static polygon cannot be served, the mesh that contains it can still be served with the dynamic cells that happen to be passing through it at a particular time.

[0267] An orbiting base station may be configured as a spacecraft with software defined radio capabilities such that it can transmit on any LTE band within a range that the selected antenna can adequately accommodate for the link budget requirements defined by the satellite coverage area. In this manner, the orbiting base station may be treated by the UE as being functionally equivalent to a terrestrial base station.

[0268] If the coverage cells may be passing through the Earth, the database containing the propagation data may be used to predict when cellular coverage from the satellite may be available at a given location. As such, the locations of terrestrial cells proximate to the network that need to coordinate spectrum usage in cooperation with the space network may be stored in the database, as well as static cell coverage zones.

[0269] Using the tower's location, the incident signal energy devolving on that tower's cell can be calculated. A specific time can be calculated to determine when the tower signals between the ground cell and the satellite may conflict and cause interference if the towers share the same spectrum channel for communication with the UE. At this point, the network may be programmed to automatically release control of a particular frequency band, channel, etc., used by the satellite during space network overhead that happens to be infringing on airspace at that time. In doing so, the spectrum may be shared in time and used more effectively assuming optimized coverage conditions. Thus, control or priority over a given channel may change over time based on where the orbital base station is located.

[0270] Some polygons may be added to a database that contains service indicators such as which ones have priority, and these may be added dynamically in case of emergency where communication is mostly needed by those geographical areas. Priority may even be set as a function of time. Thus, the network may prepare in advance for an approaching emergency. If priority exists in the future, the network may reserve power to allocate more spectrum usage to polygons in need / polygons affected by weather or other emergency that may result in increased network usage. In some embodiments, polygons are not strictly polygons and may have some curved boundaries, but in general may be treated as closed shapes with some finite area.

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

[0272] Another satellite with a beamforming antenna S2 is shown in this figure at an initial time t0 1808 and at a later time t1 1810. S2 may provide coverage to a static polygon 1816 at an initial time t0, and after moving in orbit, S2 may continue to provide coverage to the Earth and may provide coverage to the same static polygon 1816 at time t1. As shown, a beamforming satellite may provide coverage to multiple static polygons.

[0273] Other static polygons 1818 may exist in the database and may sometimes not get coverage. This may depend on the timing and results of the state space prediction engine in the enhanced MME. Not shown in this figure to maintain visibility is a fine mesh that may be shown over the surface of the Earth. Each polygon may cover several mesh points, some specific mesh points being the center and edges of the depicted polygon. There may be other polygons 1814 that are also static but are coverage polygons from existing terrestrial base stations. [E. Constellation Policy and Rules (CPR) Database]

[0274] As mentioned above, a CPR may include a set of data describing rules, regulations, policies, etc. for operating a space-based cellular network transmitter over a location or polygon to which these rules are mapped. These rules for the mesh that represents a location of interest for the network may be regulatory related (e.g., frequencies, power levels, etc.) and quality of service related (e.g., data rates, technology requirements, etc.).

[0275] Additionally, the CPR may maintain a database of information regarding what orbital, attitude, thermal and power constraints there are for operating each of the individual spacecraft on orbit.

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

[0277] The attitude and orbit control flight rules may be stored in the database in a variety of forms, as described herein.

[0278] To support the prediction engine using the force model and spacecraft characteristics, there may be a database that stores planned future thruster maneuvers as either thrust strokes or delta-V strokes. These planned maneuvers may be stored as vectors. Each vector element represents a thrust state in time. The vector may even be in terms of voltage or current values, indicating which control level is used for the possible actuators of the thrusters. Future thrust and delta-V calculations may be predicted based on the satellite's trajectory and the corrections required to keep the satellite operating in a particular orbit or within an on-orbit control box. As an example, this control box may be dynamic and change based on commands by the network control NOC. This may result in a recalculation of delta-V maneuvers to achieve the correct orbit position per NOC command. At that point, the database for flight maneuvers will be updated.

[0279] Similar to delta-V maneuvers, there may be CONOP requirements for utilizing the spacecraft attitude control system. The spacecraft may store in a database vectors that represent torque vectors that need to be performed, or pointing vectors for future alignment in inertial space over the satellite's trajectory. An example may be that a satellite is required to point a particular face of its body toward the Earth, another face toward the satellite in front of it, and another face perpendicular to those two vectors. Just as delta-V requirements may be predicted into the future, attitude control methods may also be predicted. This may be done using rigid body dynamics simulations, which may be performed iteratively to correct the results as telemetry is reported for the spacecraft attitude and control system.

[0280] Attitude dynamics simulations are typically much more difficult to simulate over long time scales than orbital mechanics, and as a result can become a bottleneck for state space predictors. Techniques can be implemented to simply assume an attitude based on a qualifying "attitude mode" (e.g., nadir pointing, zenith pointing, etc.). In this way, future attitudes can be inferred without requiring calculations (or numerical integration), and the spacecraft's state space position (e.g., position, velocity, orbital angle momentum vector, etc.) from the orbital mechanics simulations can be used to infer a pointing vector for the spacecraft body. [E.2 Thermal requirements database]

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

[0282] There may be additional thermal management requirements that may be stored in this database and used to inform the state space prediction engine. [E.3 Power Management Requirements Database]

[0283] Similar to thermal requirements, power management requirements may appear as a list of thresholds for particular battery capacity thresholds, perhaps to keep the power system healthy on orbit, and these thresholds may be assigned to particular modes (possibly each multiple modes) that indicate which operating modes are acceptable for the spacecraft when its batteries are operating at a particular capacity.

[0284] There may be additional power management requirements that may be stored in this database and used to inform the state space prediction engine. [E.4 Mesh / Polygon Rules Database]

[0285] As previously explained, there may be a database of meshes or polygons that define virtual locations and regions on the earth's surface for determining coverage statistics for areas or locations of interest.

[0286] These polygons and locations may of course exist around the Earth and may have different regulatory requirements. As an example, only certain polygons may be served using certain bands. This may be stored as a list of resource blocks, ARFCNs, etc., that may be assigned to the space network (and perhaps also stored which spectrum is assigned to the terrestrial network only). In addition to frequency requirements, there may be transmit power requirements. Each point in the mesh may have transmit power requirements (e.g., RSSI, power flux density, power spectral density, etc.) for both resource blocks that the space network is allowed to use to provide its services and resource blocks that the space network is not allowed to provide services. In this way, 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 regulatory requirements for adjacent polygons / meshes.

[0287] In addition to transmission power and frequency requirements, there may also be other priority requirements for certain polygons. As an example, some polygons stored in the database may be existing terrestrial base station polygons. In case of a disaster or when a disaster is predicted (e.g., in case of a hurricane), polygons associated with towers that have fallen or are expected to fall may be provided with an indication that allows the space network to know in advance or in real time that it needs to support the coverage of these polygons during the required time. As these coverage areas may be small relative to the satellite beams, they may be aggregated into larger polygons, so that if all of them fall, the satellites cover the polygons that define all of their total coverage areas. The regulatory database may include the specific first responder IMSIs that should be given priority at such times, and how much spectrum the satellite may need to use during its cell coverage.

[0288] During times of need, such as a disaster, power and thermal limit / constraint requirements may be updated or relaxed, allowing satellite operations to be extended for the short periods of time they are needed to provide coverage to needed areas.

[0289] There may be further rules / requirements that can be stored in this database and used to inform the state space prediction engine. [E.5 Mesh / Polygon QoS Rules Database]

[0290] There may be QoS requirements as well as regulatory requirements for each mesh / polygon. These requirements may be driven by market demand in a particular region, population density within a particular polygon, may vary by time of day, etc. As a result, each mesh / polygon may contain a "census" like data indicating population or subscriber, density within a particular region of the globe. Revenue density for each polygon may also be calculated based on countries and possibly pricing data for those countries.

[0291] Quality of service requirements may include the amount of bandwidth needed for the deployment, the required net throughput (possibly on the uplink and downlink), the required minimum MCS in the cell, the required latency to a terrestrial PDN or APN, and what type of radio access technology (e.g., GSM, LTE, etc.) may be used to serve the cell and, if more than one, which is preferred.

[0292] From a commercial perspective, each polygon may also have a priority rating. This may be used within the state space prediction engine to reconcile conflicts, for example, when a beam steering satellite is fully capable of providing coverage for more than one polygon, but only one, and may choose which one. This may be done when the satellite constellation is partially filled and providing intermittent coverage. In the case of a link due to a priority rating, the link may be broken by an internal link breaker within the network to select the polygon that will be served for that overpass (e.g., whichever polygon is best served). This database may include values ​​indicating the amount of coverage a polygon has received in the last 24, 48, 72 hours, etc. This database may also have a value indicating the time since the last overpass, which may be useful information for evaluating link breakers in determining network coverage. Commercial drivers such as revenue density may be used in the algorithm to determine coverage.

[0293] There may be additional QoS requirements that may be stored in this database and used to inform the state space prediction engine. [E.6 Spectral analysis / interference data database]

[0294] The base station stack extension may use a spectrum analysis function, the implementation of which may be described in more detail elsewhere herein. The output of this spectrum analysis function may be a matrix or vector of signal analysis processing results of raw data collected from the extended base station stack. The spectrum analyzer may listen to specific RF bands while on 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. may be more interference prone as a function of on-orbit location. This information may be useful in predicting interference margin requirements in projected link budgets for future base stations.

[0295] The interference database may vary in complexity for different embodiments of the present disclosure. In some cases, a static, occasionally updated interference level may be stored for each mesh or polygon based on the orbital position of the serving satellite. In more complex embodiments, interference information may be stored as a function of space, frequency and time (e.g., this allows link budget performance variations and interference to be predicted over days and even weeks). The interference environment may be stored as a value of db above the expected noise floor.

[0296] There may be additional RF signal intelligence, processing, etc. data stored in this database and used to inform the 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 executes a series of steps to calculate orbital dynamics simulations of future satellites. These simulations are the trustworthy part because they are quite often predicated on the spacecraft's position, velocity and mass (e.g. ballistic coefficients) that are relatively consistent throughout the entire flight. After the orbital dynamics is solved, this can be complemented with attitude dynamics and control simulations. Based on some predefined set of constraints for attitude maintenance of each satellite, the orientation over time can be calculated.

[0298] Based on the location, speed, orientation, and some assumptions about the operation of the transceivers / antennas, the link budget between the 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 can involve checking the power and thermal requirements or constraints in the CPR database for each satellite so that if a selection is made to use a satellite that exceeds the operating temperature or power limit, feedback can be provided and the analysis can be performed again. The output of the network state space prediction engine is a network state space prediction table that can be represented by a matrix of selected air interfaces that can be implemented between the satellites, the earth stations, and the UEs (e.g., which base stations are active, which ISLs are active, and which GSLs are active).

[0299] FIG. 20 illustrates components of a network state space prediction engine 2002 in one embodiment. First, the network state space prediction engine may implement an orbit propagator 2004 that may use information from the databases described above to accurately predict the motion (and relative motion) of satellites in the network. Next, an attitude propagator 2006 may be performed that may also use information from the supporting databases described above to calculate the attitude and attitude rate of each satellite in the constellation over time. This function may be computationally intensive and in some embodiments may be simplified using an "assumed" attitude CONOP (based on results from an example orbit propagator). This may allow for reduced computational intensity and maintaining model accuracy.

[0300] After propagating the orbit and attitude of the space network, a network link budget prediction function 2008 may be implemented. This function may take the results of the orbit and attitude simulation to generate an analysis of possible ISL, GSL and base station transmission links that may be available to the network at all times. The results of the link budget prediction may be passed to a network state space prediction function 2010. The network state space prediction function 2010 may utilize an algorithm or algorithms to select which links (for base stations, ISLs and GSLs) should be created in the network. These algorithms may utilize data stored in the databases described above for rules, policies, constraints, etc., and for meshes, polygons, satellites, etc. The results of these processes may provide a network state space prediction matrix 2012 that may be used to organize decisions about which links are created and which are not. This state space prediction matrix may be used to generate a state space prediction database of journeys that are used to inform network operation. [F.1 Orbital Propagator: Propagation of Position and Velocity]

[0301] Each spacecraft is equipped to know its own position and velocity and may use this information on its internal computers and / or report it to a ground network for tracking, history logs or use by computers on the ground.

[0302] Given the position, velocity and orientation of the spacecraft at a given time, this can be used to accurately predict the future position of the spacecraft. Orbital mechanics control the motion of the spacecraft in orbit, and given initial position and velocity, acceleration can be calculated, and numerical integration methods can make it possible to propagate future positions and velocities over a time span. The databases described above can be used to generate more accurate state space predictions of 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 the mass of the object. Equation 13 can accurately describe the acceleration of an orbiting object at a particular position and velocity at a particular time.

number

[0304] Since the database stores information on gravity models, atmospheric models, planetary models, and spacecraft drag characteristics, Equation 13 can be numerically integrated using techniques such as Runge-Kutta or symplectic integrators to obtain spacecraft position and velocity calculated over time. This element of the state-space predictor can accurately predict spacecraft position and velocity over hours, days, or weeks with a significant level of accuracy, depending on the fidelity of the models utilized.

[0305] If the spacecraft provides thrust, there may also be an imparted torque as a result of that thrust. This torque may be valuable to model in the attitude propagator. For a given thrust, the torque imparted to the spacecraft may be the cross product of the thrust and a vector representing the position of the spacecraft's center of mass (e.g., the position of the thrust nozzle itself) relative to the point where the thrust vector impinges on the spacecraft. This is explained in Equation 14.

number

[0306] Since fuel is used from the thrusters, this means

number

number

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

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

number

[0309] It may be more appropriate to calculate the desired vector in terms of the torque law terms in Equation 15.

number

number

number

number

[0310] In one embodiment, attitude dynamics can be modeled more quickly if they assume that the spacecraft's body coordinate system is oriented in a particular direction relative to its orbit and the Earth. For example, a satellite can be assumed to fly with one body axis pointing downward toward the nadir, or another body axis pointing at some known angle offset nadir, perhaps in its velocity direction (e.g., 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 spacecraft position and the ground station position]

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

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

number

number

[0313] In Equations 16 and 17, EIRP refers to the antenna gain and transmit power of the signal in decibels. For a base station, this may be a function of the frequency used in the link and the transmit power of that particular base station space platform. For a UE, this may be true as well, but in one embodiment, this may again be modeled accurately enough as an assumed constant for a particular device for a particular protocol (e.g., GSM limits MS uplink power to 2W per 200 kHz bandwidth, and LTE limits UE uplink power to 200 mW per 180 kHz bandwidth). In Equations 16 and 17, G is the gain of the receive antenna at the end of the link. This may also be a function of frequency or a constant.

[0314] The remaining terms are losses, noise and interference in the link. Pointing Loss

number

[0315]

number

number

number

number

number

number

[0316] Atmospheric Loss

number

number

number

number

[0317] The remaining terms in Equation 16 and Equation 17 are the thermal noise floor, the receiver noise figure, and the interference in the link. The thermal noise floor may be estimated based on the bandwidth of the link and the temperature of what the receiving antenna "sees". In one embodiment, this value may be assumed to be constant, somewhere between 290-300K. The receiver noise figure may vary from frequency to frequency or may be expressed as a constant. A typical specification for a UE device requires a noise figure of 7dB at worst. A well-designed satellite receiver in the sub-1GHz band may have a noise figure of 2dB. The interference in the link may be a function of the link frequency and the receiver position and orientation. This value may be more significant in the uplink calculations and may be informed by spectrum analysis data provided by the enhanced base station. On the downlink, the 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 terrestrial eNBs (in cases where satellite and terrestrial coverage cells overlap). In either case, the interference may be modeled as a constant or not modeled at all. The interference in this formula will be a number of decibels representing the number of decibels above the thermal noise floor that the interference adds to the link.

[0318] Equation 16 and Equation 17 may be used to calculate the SINR of a given link. Additional link budget parameters may 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 of the bits may also be calculated correspondingly. Additional physical layer qualities such as Doppler shift and propagation delay may be predicted and utilized to inform the PHY layer control.

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

[0320] FIG. 21 shows a possible base station link 2122, GSL 2116 and ISL 2104 link budget geometry. The base station link 2122 is evaluated based on the base station satellite 2114 and the UE 2138. The satellite base station antenna boresight 2120 may differ from the antenna beam direction 2118 by an angle 2124 off the boresight. The link geometry may generate a pointing offset 2112 that may be used to calculate the antenna gain and EIRP of the corresponding point or UE of interest. The UE may also have a beam direction 2128 based on its orientation. The base station link may be evaluated over a ground mesh resulting in the contour of a spot beam 2130 that can be calculated, and other mesh points outside that beam 2134. Several ground towers 2132 may be within the beam energy and interference may be evaluated in a mesh 2136 that represents a ground base station polygon.

[0321] An inter-satellite link 2104 may be evaluated between two base station satellites 2114 and 2108. Using the beam directions of the ISL antennas 2106 and 2102 (which may also be oriented off-boresight as in the base station array, but for simplicity are not shown here), a GSL 2116 may be evaluated between the base station satellite 2108 and a ground station 2140 with vectors 2126 and 2110 representing the orientations of those antenna beams for communication over that link.

[0322] Although not shown in FIG. 21, loss within the link may be calculated based on frequency, path loss, pointing offset, polarization offset, line loss, body loss, etc. based on the geometry as previously described in this disclosure. [F.4 Link Budget Predictor and Network State Space Predictor Procedures]

[0323] The link budget engine is used to predict both RAN (e.g., base station) coverage deployments and core network tunneling connections. To do this, the link budget engine may calculate possible (reasonable) link budgets for various possible satellite beams at various points within each polygon of interest and at each point within the global mesh. In one embodiment, the entire mesh or multiple meshes may be the polygon of interest (e.g., link budgets are calculated over the stored points). Additionally, 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 may 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 only serve one polygon at a time) and that may be evaluated by software. [F.5 Network state space prediction for beamforming satellites and static polygons]

[0324] The link budget predictor and state space predictor may be implemented in succession in an iterative phase performed by the network components in some embodiments. In the described embodiment, the procedure may have an initial iterative stage that evaluates scenarios for base station coverage of a static coverage area by beamforming satellites. Link budgets may be calculated for each beam at each time step in the orbit / attitude simulation for each polygon within the range of the beam transmitter. Possible beam directions for each beam may be made to provide optimized coverage for the static polygon under evaluation. This procedure may be vectorized so that it may be calculated rapidly. Once the base station link budgets are calculated for the beamforming satellites at various time steps for the static polygon within range, a specific polygon is selected at each time point for which each beam in the satellite set may provide coverage.

[0325] 22 shows a procedure that may be implemented by the described first iteration stage in the disclosed embodiment. The procedure may be implemented as software, and the procedure flow is described in that context. The procedure includes a for loop and iteration of the calculation. However, the software may be compiled, for example, into a program that executes instructions in a vectorized manner to perform the calculation quickly on a hardware deployment.

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

[0327] Step 2 2204 may be the beginning of a for loop for the available beams on the satellite being looped through.

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

[0329] Step four 2208 may be the beginning of a for loop to step through the simulation of the orbital and attitude dynamics of the satellite.

[0330] Stage 5 2210 may be a check in the software to ensure that the selected beam and the selected static polygon at the selected time are within a distance from each other that allows for a reasonable link budget. 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 go to the next time step.

[0331] Stage six 2212 may be to determine the beam direction of the beam to correspond to the static polygon at that time step, which may be a vector in inertial space or in the spacecraft body frame to inform commands on how the beam may be directed.

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

[0333] Stage eight 2216 may determine the signal power across the mesh in the CLR database that is within the distance threshold of the satellite at that time step by calculating link budgets in the uplink and downlink directions (e.g., after assuming beam directions, the link budget may be calculated across the entire mesh, not just the polygon). The link budget may calculate various variables including SINR, SNR, EbN0, Doppler shift, latency / delay, etc. Many of these variables may be used in assessing the performance of the base station as well as its potential interference in areas of the mesh that should not be interfered with. To calculate the link budget, some assumptions may need to be made about the transmit power of the satellite. Each satellite may have a default transmit power.

[0334] Stage 9 2218 may take the link budget results and check or analyze them against the rules in the policy database. If the analysis suggests that a particular policy has been violated, the transmission scheme may be corrected by re-evaluating the link budget with a lower EIRP on the downlink channel. This may reduce footprint bleed-over and 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 repeated.

[0335] Stage ten 2220 may obtain a link budget result that passes regulatory requirements and checks against quality of service requirements for the polygon.

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

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

[0338] Stage 17 2234 runs a static polygon coverage optimizer. The static polygon coverage optimizer may be a software function that is a state space predictor for static polygons and beamforming base stations and uses the results of stages 1 through 16 to determine which beams from a beamforming satellite can provide coverage for that static polygon. This software function may incrementally step through each time step and check whether the number of beams available for any static polygon at each time step is greater than one. If so, this software function may select one of these beams that can cover the polygon that meets some optimal condition (e.g., each cell provides the longest coverage going forward with the satellite and provides coverage until it can no longer do so). If there was no beam for a polygon for a given time step, the polygon will not receive coverage. There may be policy considerations that prioritize certain polygons over others. Policy considerations may also vary in time based on traffic estimates for the polygon, or perhaps the polygon has recently been added for service by a space network because a ground tower has fallen on the ground and needs a satellite to back up its service while it tries to get back up. Stepping through time identifies which satellites can provide coverage for which polygons and indicates multiple backup satellites (in case a satellite fails between now and the future). This may also allow for an understanding of a handover satellite that may eventually resume serving the static polygon if other satellites are beyond their capacity to provide adequate service. In some cases, static polygons and beams may not be assigned to each other during certain time steps. These time steps may be noted for the next iteration 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 and non-beamforming satellites and remaining mesh / dynamic polygons]

[0339] In the second iteration stage, the network state space predictor may evaluate scenarios for remaining base station coverage, both for remaining static coverage areas (for static coverage areas not assigned service at a particular time in the iteration described previously) and for dynamic coverage areas. Satellite beams that are beamforming and not previously assigned, as well as non-beamforming, are evaluated for coverage in this iteration. The second iteration is similar to the first in that it iterates satellite beams diachronically. However, in this case, the beams are not guided by a known static polygon (static polygons that may be covered by beamforming satellites at each time step are considered in the previous iteration). As a result, the beams are assumed to have a certain pointing direction. This may be driven by the satellite's attitude or by some other driving factor, such as population density in the remote area in the case of remaining beamforming beams.

[0340] After the assumed beam directions are made, the link budget may be calculated, and a similar check on policy and QoS requirements is performed before iterating over the link configuration (in this case, perhaps the beam direction, when possible), and then the link budget is either saved or not saved. At the end of the iteration loop, the remaining beams that may transmit are determined for each time step. After it is determined that a beam is transmitting at a particular time, it may be necessary to harmonize the spectrum being utilized. A function may be used to determine which frequency bands or resource blocks within the same frequency band are assigned to each base station. Once this is established, further base station operational requirements for each base station at each time step may be determined, such as which MIBs, SIBs, TACs, etc. they may need to implement as base station control.

[0341] 23 shows a procedure that may be implemented by the described second iteration stage 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 a for loop and iteration of calculations. However, the software may be compiled into a program that executes instructions in a vectorized manner to perform calculations quickly on a hardware deployment.

[0342] Step 1 2302 may be the beginning of a for loop for all satellites in the network that have base stations with no beamforming beams, as well as satellites in the network that each have base stations with beamforming beams that have not been assigned or have not yet been assigned.

[0343] Step 2 2304 may be the beginning of a for loop for the beams available on the satellite being looped through.

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

[0345] Stage four 2308 may implement a software function that determines the direction of the beam being evaluated. If it is for a beam steering beam, this may evaluate the direction based on the nearest portion of a static polygon, or perhaps a remote mesh point with a high population density of subscribers not connected by a terrestrial base station. If the beam is not steering, the direction may simply be derived from the attitude of the spacecraft at that time.

[0346] Stage five 2310 may begin a for loop to step through the mesh available resource blocks that are in view of the satellite at that time step.

[0347] Stage 6 2312 may determine the signal power across the mesh in the CLR database that is within the distance threshold of the satellite at that time step by calculating link budgets in the uplink and downlink directions (e.g., after assuming beam directions, the link budget may be calculated across the entire mesh, not just the polygon). Calculating the link budget may include calculating various variables including SINR, SNR, EbN0, Doppler shift, latency / delay, etc. Many of these variables may be used in assessing the performance of the base station as well as its potential interference in areas of the mesh that should not be interfered with. To calculate the link budget, some assumptions may need to be made about the transmit power of the satellite. Each satellite may have a default transmit power.

[0348] Stage 7 2314 may take the link budget results and check or analyze them against the rules in the policy database. If the analysis suggests that a particular policy has been violated, the transmission scheme may be corrected by re-evaluating the link budget with a lower EIRP on the downlink channel. This may reduce footprint bleed-over and resolve possible regulatory violations from the previous link transmission scheme. If reducing the transmission power does not satisfy the rules, the software may iterate over the beam direction (if possible) and repeat the process for the link budget calculation. If this still fails, the loop may be exited and the next resource block may be iterated. The iterations over the beam direction may be limited to save calculation time.

[0349] Stage 8 2316 may obtain a link budget result that passes regulatory requirements and checks against quality of service requirements for the terrestrial mesh points below. This stage may be skipped and the QoS requirements for non-beamforming arrays may be reduced.

[0350] In step nine 2318, if the QoS is met, the transmissions are saved. If they are not met and the QoS requirements are not robust (e.g., no coverage is better than the others), they may be saved anyway as well. In scenarios where the QoS requirements are strict, the link budget may be discarded if it cannot provide the desired data rate (which is a function of SNR, SINR, EbN0, etc.), MCS, etc. If the link budget is saved, the transmission results may be used to determine the edge of the coverage polygon (which may differ for each frequency). This may be used to calculate the edge of the dynamic polygon coverage area. In one embodiment, this may be the signal level used for the terrestrial cell edge for each technology, i.e., GSM (e.g., -105 dBm at 200 kHz) and LTE (e.g., -115 dBm at 180 kHz). Points in the mesh that are at the cell edge or cell center may be indicated at each time step.

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

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

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

[0354] Now that it is known when the signal level from the satellite may be too high and exactly in which RB this may occur, the space network can communicate this to the MME in the ground network with the ground cells that may be affected. Based on this, the ground cells may temporarily increase their transmission power or temporarily eliminate the use of some of their spectrum allocations. 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 assigned to which transmitters. Based on the allocation table and the RB rules for transmission in each base station beam, a suitable RB division can be implemented. This can be optimized by population density coverage, known remote UE coverage, expected traffic models, etc. to allocate the appropriate ratio of RBs to each transmitting base station in the satellite network. Technically, the satellite downlink 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 adequate for sharing the resource blocks. Technically, a terrestrial base station would need to be able to generate a downlink signal with a SINR greater than 0 dB for the satellite downlink in its coverage cell, which would allow at least the lowest order LTE MCS table setting, MCS-1, using QPSK with a 0.33 coding rate.

[0355] Step 13 2332. The final step in the procedure may conclude the base station control requirements for the satellite. Once the frequency domain for each transmitter is known, each future projected base station may also be provided with a set of information on how to configure itself (e.g., which MCC, MNC, TAC, etc.) that it should transmit on its information resource blocks (e.g., MIB, SIB, etc.) for area-based network characteristics, if they are required.

[0356] FIG. 24 illustrates a data structure 2428. The data structure 2428 may be a matrix, a cell array of matrices, or a matrix of matrices that represent the link budget predictor and selection procedure for which the satellite base station is instructed to transmit at each time point. The mesh 2402 is broken down into individual mesh points 2414. Each mesh point may represent a three-axis coordinate on the Earth. A polygon may comprise multiple mesh points, and the polygon may represent base station coverage from a terrestrial static base station 2408, a space static base station 2406, or a space dynamic base station 2404. The link budget is calculated based on the mesh points as well as the base station beamforming beams 2410 (e.g., b1, 2412) and base station non-beamforming beams 2424 (e.g., b1, 2414). 10 , 2422). The link budget may be evaluated at discrete 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 may be evaluated over resource blocks 2432 for the desired list of performance variables 2430. As a result of these calculations, the network state space predictor may determine which beamforming satellites are providing coverage to the space-based static base station at each time step 2418 as well as which non-beamforming satellites are providing coverage to the space-based dynamic base station 2420.

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

[0358] When operating a space-based LTE communications system, it may be inconvenient to allocate entire blocks of 10 MHz, 5 MHz or even 1.4 MHz to the space network. Most telecommunications traffic may pass through terrestrial base stations on the ground. As a result, the amount of spectrum allocated to the space network should be proportional to the traffic it expects to carry.

[0359] The terrestrial and space networks can decide on an implementation where only the space network utilizes certain resource blocks within the LTE carrier band. For example, a terrestrial cellular tower may use a 5 MHz LTE carrier band, but knows that it should not assign uplink resource blocks (RBs) within that carrier bandwidth, e.g., 1, 2 or 3, to any of its mobile devices, because the complementary space network will want to utilize those resource blocks. These RBs can be dynamically assigned to the space network in frequency, quantity and time. Over certain areas of the world, there may be more resource blocks (RBs) at the disposal of the space network. Also, there may only be certain time slots over those resource blocks reserved for the space network.

[0360] This implementation can be done in software as a "spectrum table" that is software defined so that the ground network blocks allocation of specific resource blocks or time slots in specific locations based on telecommunications traffic models (or perhaps others). The space network using ephemeris from its orbital trajectory can reconfigure the software defined radio and flight computers to manage the communications traffic over the RBs or time slots that it knows it has access to for any particular part of the world. This can be stored in memory as an internal map onboard the satellite. This map would be designed to be updateable and reconfigurable, since terrestrial telecommunications traffic decays and flows over either days, months, years or decades, etc.

[0361] FIG. 25 shows how the scenario described in FIG. 24 may manifest itself in a real coordinate system, and how resource blocks may be dynamically assigned to the space network for that time step, in a manner in which LTE blocks are "sliced" to allow specific spectrum slices to specific base stations, perhaps at specific times (or permanently in another embodiment). In FIG. 25, each base station coverage polygon may be indicated as "eNB", but in the following description will simply be referred to as "base station" (e.g., base station 5 is eNB5). Each satellite 2502 may be equipped with one beam 2518. Not only are base stations 5 to 8 covered in space shown transmitting to each other, but also base stations 1 to 4 covered on the ground. Each base station coverage polygon is provided with coverage by a 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 a corresponding mesh point (e.g., the coverage polygon of base station 1 includes mesh points m1 and m2, the coverage polygon of base station 5 includes mesh point m10 ~m 13 and m 28 ~m 39 2510). The block of spectrum 2510 may require partitioned allocation of non-interfering traffic channels within a 5 MHz LTE block over time (for example, but the block may be as wide as LTE allows). The orbiting and terrestrial base stations may share the central 6 resource blocks for the control channel and may use dynamic allocation of PCI codes for distinct use of the downlink control channel. Dynamic allocation of the number of PRACH preambles between the space network and the terrestrial network may be done. Allocated between the space network and the terrestrial network are used resource blocks 2512, control resource blocks 2514, and unused resource blocks 2516. These resource blocks may be allocated in various ways, but may be done so that there are no overlapping resource blocks between base stations with overlapping coverage zones, beams, etc. Frequency resources may even be allocated as a function of time, where a specific resource block and time slot is assigned somewhere. The space network may be implemented using GPS and thus synchronized to understand when 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 the satellites. [F.7 Network state space prediction for ISL and GSL]

[0363] The network state space prediction function may evaluate link budgets for ISLs and GSLs. Based on the link budget results for ISLs and GSLs, the network can determine which connection is best to perform at each time step. Some satellites may be designed to support multiple links over ISLs or even GSs. Depending on which network has priority, the network connection may be selected based on various criteria (e.g., longest possible link data rate, latency, etc.). Perhaps the network link is selected to reduce the root mean square of the network latency for each UE predicted to be connected to the network at each time point. Once the most ideal link and link alternatives are determined for a time point, the network can determine which tunneling / routing links are available to drive IP signaling and network control signaling. Additionally, the network can use this to predict when a tunneling route needs to be handed over to avoid disconnecting IP traffic connections in the network.

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

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

[0366] Phase 2 2604 may be the beginning of a for loop for other satellites in the network that were not looped through or looped through in phase 1, as well as ground stations in the network.

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

[0368] Stage four 2608 may implement distance checks to ensure that multiple satellites or a satellite and a ground station are within a reasonable enough distance to merit the link budget calculation.

[0369] Step 5 2610. If the link distance is deemed worthy of calculation, the beam direction of the satellite or satellites and ground stations may be determined. The ground stations may use dish or phased array beam steering techniques. The satellites may use beam steering arrays, mechanically steered apertures or static mechanically attached antenna apertures for ISL.

[0370] Stage six 2612 may calculate link budgets in the uplink and downlink directions for ISLs and GSLs. Given link budget geometries and transmit powers, link budgets may be evaluated in both directions at many satellites and ground stations in the network. Links may be evaluated over individual frequency channels assigned to each link. This may be similar to how base station link budgets are evaluated over resource blocks. This information may be used to determine what level of interference may be present in a particular ISL. This may trigger a reduction in transmit power, appropriate dynamic allocation of bandwidth / spectrum division or outright refusal to use the link where there is interference.

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

[0372] Step eight 2616 stores the link budget into a link state space, similar to that shown in FIG.

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

[0374] Stage 12 2624 uses the link state space matrix results to determine which links should be used based on a network routing optimization algorithm. The network may, as an example, want to minimize the root mean square time / latency to move a packet from a remote UE to a ground station. For each selected link, a given frequency bandwidth should be determined based on its proximity to other links using similar or nearby frequencies. A spectrum strategy may be implemented in the database that describes the frequency capabilities of each satellite and which frequencies it will use with other satellites. Or, the frequencies sharing plane may be inherent in the satellite constellation design (e.g., every other ISL repeats the use of the frequencies).

[0375] Stage 13 2626 may determine what bandwidth allocation exists for each tunnel for IP bearers moving control traffic, user traffic, and TTCC & DH traffic between nodes in the network, which may be fixed or dynamic based on projected load.

[0376] FIG. 27 illustrates a graphical embodiment of a link state space matrix for the determination of base stations and ISL and GS links. In this figure, each base station coverage polygon may be denoted as an "eNB", but in the following description will simply be referred to as a "base station" (e.g., base station 5 is eNB5). As mentioned above, the mesh 2704 may comprise points 2718 constituting static base stations 2770 and dynamic base stations 2706 (simplified in FIG. 27 to either terrestrial or space-based base stations for brevity). The mesh may also comprise points 2720 representing the location on the earth of a particular UE that is a subscriber of the network 2712. As with the mesh of points on the earth, there may be a set of network nodes 2702 with other points 2716 representing the location of earth stations 2708 and points 2714 representing the location of satellites 2710. This state space would represent a link budget scenario between satellites 2744, which may be divided into two groups: beamforming satellites 2742 and non-beamforming satellites 2756. In this particular embodiment, to maintain simplicity of explanation 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 the Earth. As shown, satellite S4 is providing coverage to base station 3, which may be a static coverage polygon. Also, a non-beamforming satellite is selected to provide coverage 2748 to a dynamic base station. As shown, satellite S5 is selected at time step t0 2740 to serve base station 5. Similarly, each ground station may communicate with the satellites and their links 2754 may be selected. As shown, S9 is in communication with both GS1 and GS3 at time step t0. Similarly, an ISL may be selected (2752) for each time slot. UEs provided with coverage to 2750 may also be calculated in the link state space matrix. In Figure 27, for example, UE1 and UE2 are provided with coverage by S1, a beamforming satellite within base station 1, which is a static polygon.The link budget prediction for each base station for each mesh 2758 is from resource block RB1 2760 to RB. n 2768. Similarly, the ISL and GS link budget 2762 may span any possible frequency for each link 2764 through 2766. The ISL, GSL and base station links may be evaluated for SINR, RSSI, data rate, latency, Doppler shift, etc.

[0377] FIG. 28 shows how the link state space matrix of FIG. 27 may appear in a space network in the Earth's coordinate system. In this figure, each base station coverage polygon may be denoted as an "eNB", but in the following description, it will simply be referred to as a "base station" (e.g., base station 5 is eNB5). 10 2804 may be in a GEO orbit 2802 and S9 2814 may be in a MEO orbit 2806. The base stations providing coverage to the UEs may be in a LEO orbit 2822. S1 2816 may be a beamforming satellite providing coverage to the Big Island of Hawaii via base station 1 serving UE1 2818 and UE2. S5 2808 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 between LEO, MEO and GEO and GS 2824. As a result, traffic may travel from UE1 to S1 to S2 to S3 to S4 to S5 to S6 in this scenario. 10 to GS2, then over the Internet to GS1, then to S9, then to S8, and then to UE5. [G. State Space Database]

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

[0379] Another cell array of matrices / vectors can be generated that defines the commands or action steps that each individual satellite can take in time to appropriately initiate the simulations and optimizations to achieve the desired network state space generated by the network state space prediction engine, and that are stored on a time basis. This new three-dimensional cell array can be stored as a state space database.

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

[0381] The state space database can be distributed throughout the network via inter-satellite link tunnels and ground station link tunnels on a specific bearer for network distribution of the state space database. This bearer can be part of the TTCC&DH tunnel bearer. As an IPv6 network, each static IP address assigned to a satellite can be used to send a unique packet containing the necessary information from the state space database. This can be just its own state space database sliver and the state space database sliver of the satellite intended to link with it in the future or backed up (possibly even a backup of a backup) for future links in case of anomaly or failure of the network satellite between the prediction time and the occurrence time. Telemetry monitoring of spacecraft health and operability is implemented in the TTCC&DH system to provide automatic feedback for the state space prediction engine. New information about the satellite's position, velocity, attitude comes in, as well as other vital system capability information (e.g. thrusters, batteries, transmitters, computers, etc.) comes down from the space network to the ground nodes that are doing the bulk of the calculations. The predictor can update the future network state space and send out new state space vectors.

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

[0383] 29 shows a network state space database that may include three sets of legs. Spacecraft legs 2902 may include spacecraft beam operations 2904, thruster utilization / operations 2906, attitude CONOP and control 2908, and operational power modes 2910. There may also be a core leg 2912. The core legs may include network dynamic IP routing tables 2914, spot beams, satellites, terrestrial gateways, and UE handover 2916. Additionally, there may be a radio access network leg 2918. These may include base station front end / 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 journeys 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 the network state space prediction (e.g., in terms of position, velocity, attitude and attitude rate), which is more precise as more accurate force models (e.g., gravity, atmosphere, magnetic, etc.) are used in the simulation. Low Earth orbit trajectories may be a limiter, but can still be accurately predicted 1 hour, 12 hours, 24 hours, days, or even potentially even a week into the future. This means that the network state space can also be predicted this far into the future.

[0385] In a world where rapid, low-cost launch and access to space is the norm, there may be uses for implementing controllers that analyze rocket launch opportunities and subsequent weeks based on network state space prediction results, as an example, when additional space assets may be required to be launched into orbit to support growing demand. [H. Network Handover]

[0386] The network state space prediction engine may generate handover journeys for each of the orbiting vehicles in the network. These handover journeys may be triggered by timers to signal the transfer of ownership of both ISL and GS tunnels and base station coverage polygons. The timing of the handovers may be determined by a link state space predictor in the enhanced MME. Handovers may be specified at specific times and may be accompanied by journeys to slowly build up or slowly reduce the transmit power of the beams.

[0387] The network may implement some handovers in a somewhat conventional manner. This may be of particular use when individual satellites act as a set of base stations, thus providing coverage to the same UE internally, allowing for rapid and seamless handovers between beams shared on the same satellite. These handovers may be done within software on the same computer, or between two computers within the same satellite running base station software. However, between satellites, handovers may be more complicated. If satellites without beamforming arrays have overlapping beams, they may use the overlap as the area to which the UE is handed over. This may be done with typical UE signal measurement reports back to the base station, or it may be done automatically based on known network movements over time and the known location of the UE in GPS coordinates at the time of handover.

[0388] FIG. 30 illustrates how a network may hand over coverage of a static base station polygon represented by a mesh in a CLR. A first satellite 3004 may be providing coverage to UE1, UE2, and UE3 (3010, 3012, and 3014). The coverage is possibly provided by a beam covering the static base station polygon 3016. There may be a second trailing or nearby satellite 3002 orbiting towards the static base station polygon. After some time, the first satellite may need to hand over a cell to the second satellite. Perhaps through an ISL or some other network tunnel route (e.g., through GS), the second satellite may start transmitting through the static cell covered by the first satellite. This second satellite may generate a beam 3006, while the first satellite starts reducing the transmit 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 FIG. 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 UEs to the second satellite in a manner that may result in a smoother transition / handover that potentially reduces network signaling traffic challenges. There may be a third satellite 3018 following the second satellite that may prepare for another handover of the static base station cell. Eventually, the second satellite may no longer have a coverage beam and resumes control of the static base station coverage cell 3024. The second satellite similarly prepares to make a handover.

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

[0390] FIG. 31 illustrates how handovers can occur between satellites with and without beamforming base station antenna technology. This technique will be beneficial because space networks will be progressively upgraded from satellites with non-beamforming satellites to those with beamforming arrays. As a result, both will exist. A first beamforming satellite 3104 may provide coverage to UE1, UE2, and UE3 (3110, 3112, 3114) with a beam 3108. A second non-beamforming satellite 3102 may be following the first satellite and moving towards its static base station coverage polygon transmitting a beam 3106. After a certain time, the second satellite beam 3116 may begin to overlap with the static base station coverage polygon 3120. The first satellite can know this from the ISL connection or from the state space predictor and reduces its transmit power and shifts its beam 3118 to the front edge away from the second satellite beam (which it would have knowledge of due to the state space database). When the first satellite remains above the static base station polygon 3128, it slowly reduces its beam power 3126 and hands over the UE to the second satellite beam 3124. In this figure, UE3 is handed over first. As the beam is reduced, it can continue to shift progressively to maintain coverage for the UE that needs it until the handover occurs.

[0391] Additionally, there may be a third satellite 3122 (beamforming type) behind the second satellite. Eventually, the beam of the first beamforming satellite runs out and the second satellite has almost complete coverage of the static polygon 3132 with a dynamic beam 3134. However, the third satellite may start transmitting a beam 3130. The transmission is scheduled to start at the back end of the second satellite beam and slowly increase into the static base station polygon coverage zone and take over control of the UE coverage.

[0392] FIG. 32 illustrates how a network may transition spectrum usage in a given licensed area. These non-beamforming satellites 3202 may generate beams 3204 that cover a dynamic polygon. There may be an approaching boundary 3206 where the satellite cannot transmit over certain frequencies. Eventually, the satellite spot beam reaches the boundary 3208. As the satellite continues to move, it reduces the transmit power of beam 3212 to ensure that it does not radiate interfering energy across the boundary. If it is radiating normal power, the beam may provide coverage beyond the boundary 3210. As the satellite approaches the boundary further, the spot beam 3214 is further reduced until the proximity of the boundary prevents the satellite from transmitting altogether.

[0393] In another embodiment, the satellite may rotate its attitude to return and continue to provide coverage on the correct side of the boundary. Any embodiment in which a spot beam is modified to accommodate a boundary edge via attitude or transmit power or some other method is relevant to this invention. [I. Enhanced Base Station]

[0394] Enhanced base stations may offer several improvements over standard base stations that enable more optimal operation in space as part of a space network.

[0395] FIG. 33 illustrates an embodiment of an enhanced base station 3306. The enhanced MME 3304 may interface with the base station through a standard S1-CP interface. However, the base station may operate an additional function called a base station state space controller 3308. The state space controller may receive instructions and process operations from the enhanced MME to operate the base station stack appropriately. 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 allow enhanced MAC control 3322 and enhanced 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 enhanced base station stack may include an enhanced PHY 3318 for receiving enhanced commands, an enhanced MAC 3316, a radio link control layer 3314, a packet data convergence control layer 3312, and a user plane connection to the standard S-GW 3302. The base station state space controller may be programmed to dynamically control 3330 the RF front end / beamformer 3320. This may involve steering the beam during overpass and / or switching to various filter banks, LNA stages and amplifier stages to transmit and receive in the desired frequency bands in which the base station is operating over its location in the world.

[0396] The base station state space controller may also control the DSP functions (3326). The enhanced MME base station may include a receiver-only front end 3332 to assist with spectrum analysis functions. There may also be a layer 1 signal processing block 3328 used to filter or sample the desired RF. The result of the sampling may generate I and Q from the RF samples and be passed to the DSP block 3310. The DSP block may be controlled by the base station state space controller and the results of the analysis may be passed back to it from the DSP block. This information may be passed back to the enhanced MME for network mobility management functions (such as tracking of UEs based on Doppler shift and delay measurements). The base station state space controller may act as a stand-in scheduler for the base station, effectively implementing the dynamic control required for the amount of spectrum slicing and spectrum sharing for satellites and terrestrial cells based on the output of the state space prediction engine. [I.1 Extended MAC and Extended PHY]

[0397] The extended MAC layer and extended PHY layer modifying the typical 3GPP base station protocol may be as described in Speidel I. The extensions described therein may be general to the operation of a satellite platform, but may have configuration differences depending on which part of the satellite's field of view is provided with coverage. Dynamic changes of frequency (and thus Doppler cell contours that vary depending on the operating area) and beamforming antennas (and thus dynamic ranging between the nearest and furthest targets as well as absolute Doppler shifts across spot beams) may be implemented for the MAC and PHY control extensions.

[0398] Based on the state space prediction and itinerary arising from the enhanced MME, the base station may undergo dynamic control as described in Speidel I. This dynamic configuration may be controlled by the base station state space controller, which effectively acts as a base station scheduler.

[0399] As defined in Speidel I, the Doppler shift of the signal from the UE to the orbiting base station can be monitored for Doppler shift and propagation delay without specific implementation of the UE functionality. The Doppler shift and propagation delay can be measured in the PHY and returned to the base station state space controller. This allows the satellite to place the UE inside one of two small grids inside the entire satellite footprint. The location of these grids can be symmetrical to each other around a vector that defines the satellite's velocity vector. As the measurements of Doppler shift and propagation delay become more and more accurate, the size of this grid can converge to two single points. If the satellite footprint includes more than one spot beam, the spot beam used to communicate with the device can be used as information to break the connection where the UE is approximately at its GPS location. This can be calculated because the GPS location of the orbiting base station can be known and a vector that represents the user's location relative to the satellite velocity vector is known. With this information, the GPS location of the device can be calculated. This GPS position may be stored as a further element in the VLR or HSS for use by the MME in the space-based network.

[0400] If the satellite footprint includes one spot beam, then a precise position may 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 spectrum analysis function on the enhanced base station includes further elements DSP 3310, layer 1 signal processing 3328 and receiver front end 3332. Together these elements may be configured to generate a data set that can be returned to the enhanced MME through the base station state space controller to inform the interference table 1914 for link budget calculation. The receiver front end may be configurable to focus on a particular band of interest 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 the signal across several resource blocks of interest. Layer 1 signal processing may perform A / D conversion and digital filtering of the signal. This may involve an FPGA that can be reprogrammed or reconfigured by the base station state space controller.

[0402] The digitally filtered signals may be I and Q from the RF samples resulting from layer 1 signal processing and may be returned to the DSP block for further processing. If a spectrum analyzer front end is used to digitally sample I and Q from a spectrum amounting to a 20 MHz block of spectrum at 16-bit resolution, the spectrum analyzer front end may need to sample at at least twice the bandwidth or a higher rate (e.g., 40 MHz). When performing spectrum analysis, the sampling rate may be reduced in some embodiments since the data does not necessarily need to be demodulated at a certain bit rate. At this rate, a 10 ms sample of a 20 MHz LTE uplink block (e.g., one LTE radio time slot) would generate 1.6 Megabytes (MB) before any packet overhead or packet compression procedures. If left to sample continuously, the spectrum analyzer may 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 the data can be sampled and recorded 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 desirable or even necessary to manage the size of the spectral analysis data, which is the reason for the DSP block.

[0403] This block may implement algorithms to reduce the size of the collected data by performing calculations or processing that generate some smaller size numerical data set that is used as executable intelligence in the state space prediction engine. For example, the DSP block may perform an FFT over a time slot for a particular resource block and evaluate the interference margin (expressed in dB) above the expected noise floor in a 180 kHz resource block. The interference may be evaluated over a time window and resource block and time tagged so that it can be returned as a matrix of numbers that represents the interference environment on a particular frequency channel at a particular time.

[0404] The spectrum analysis function may also be used as a support function for the placement of UEs on the network. During operation of the state space prediction engine, there may be iterations generated for a base station that requires steering a beam and acting as a receiver only for static polygons that are covered by another base station (either beamforming or non-beamforming).

[0405] The first base station may be scheduled to provide coverage to the static polygon. During this coverage, the first base station will communicate with the UE over the LTE-Uu interface as a normal orbiting base station capability. The second base station may be scheduled to perform receive-only operation to the static polygon. The first base station and the second receive-only base station may operate in different orbits, or possibly behind each other in the same orbital plane. These two base stations may have a connection to each other through an ISL or through a GSL. These links may be used by the first base station to convey framing / timing information to the second base station so that the second base station knows where to scan frequencies and when to receive control or traffic channels, signals from the UE intended for the first base station. If there is no inter-satellite or ground station link, the second receive-only base station may have a route. The process involves receiving RF spectrum over a time window and recording the raw I and Q timestamps so that they can be post-processed later once the timestamp of the uplink signal from the UE at the first base station is known (e.g., from a log file stored in a historical network state space database). Based on the RF from the UE received at both satellites, the Doppler shift, propagation delay (or the spread between them) and the GPS position of each base station at each measurement time can be used to calculate the UE's position in GPS coordinates. [I.3 Base Station State Space Controller]

[0406] The base station state space controller is the central orchestrator for base station enhancements. The base station state space controller receives information about the RAN journey from the enhanced MME and uses this information to coordinate operations between base stations 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 journey data, the base station state space controller also reports back to the enhanced MME data on Doppler shift, propagation delay measurements of the UE so that the position can be calculated. The base station state space controller also reports back on the results of the DSP analysis to inform 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 the synchronization signals transmitted by the base station on 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 5 ms within a frequency band (1.08 MHz) 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 (one with zero subcarrier at DC) known to the UE. At only one time, the UE cell searcher / synchronization signal correlator indicates that the cyclically shifted sequence is correctly synchronized with the PSS timing reference signal. The SSS is generated from a pair of known m sequence offsets according to cell group ID [0,...,167] and sector ID [0,1,2], which together form the logical and normally physical cell ID. As a result, there can be a total of 168x3=504 unique cell IDs. These synchronization signals also help the UE to identify a cell among other cells sharing the central 6 RBs in the frequency band. In 4G LTE terminology, a 9-bit cell ID identifies a cell in the wireless network and is encoded in the code sequence that forms the synchronization signal.

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

[0409] One or more UEs transmit a preamble on a physical random access channel (PRACH) after synchronizing with the downlink channel. The PRACH procedure includes a contention resolution procedure in case there is a collision between transmissions of the same preamble by UEs in the same timeslot.

[0410] Share spectrum with terrestrial networks, but use the same core 6 RBs or 1.08 MHz frequency as terrestrial eNB tower cells. The space base station may have pre-existing knowledge of which resource blocks are treated as control blocks and which other resource blocks may not be used as control blocks. Furthermore, since there are 504 cell ID options in the network, the space network may be assigned only some 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 may be assigned to the space network. These cell IDs may possibly be dynamic over time on orbit, a process that would be implemented by a state space controller in the base station.

[0411] Additionally, the network will only allocate certain resource blocks due to spectrum slicing between the satellite and terrestrial networks. Thus, satellite base stations will be assigned certain resource blocks, time slots, or swaths of resource blocks and time slots, and terrestrial ground towers will be programmed / controlled to share those resource blocks or swaths of resource blocks if a space base station is operating within a distance that would prevent the use of those resource blocks or swaths of resource blocks or cause interference with the terrestrial eNBs.

[0412] The space-based communication system described in this disclosure may be best implemented as an extension of an existing mobile terrestrial network, where the core elements and examples of RAN elements are hosted on a space-based infrastructure to extend their terrestrial coverage, but using the same spectrum as their terrestrial coverage for the same devices, allowing it to behave appropriately with the existing terrestrial spectrum / waveform deployment. 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 dynamically adjusted. The MNO can digitally inform the space network NOC about changes in policy, QoS, etc. requirements for polygons that may be part of the mesh. As a result, this will be implemented in an enhanced MME for future state space prediction and itinerary generation. And accordingly, the base station will communicate over the air interface using a state space controller in the base station. [I.3.b Tracking Area Code]

[0413] One of the most important elements of the RAN process is the downlink control channel configuration, since this can be used to trigger specific behaviors in the UE that the network may want to control in a particular way. A particular example of an important downlink control channel configuration is the Tracking Area Code.

[0414] In space based networks, base stations may operate on LEO and may undergo rapid overpass windows between satellites and UEs. Typically in cellular networks, the location of the UE is tracked based on a tracking area logged in the HSS. Typically, the location logged in the HSS is the address of a particular tracking area, with coverage provided by a particular base station or set of base stations. Thus, the cellular network only tracks the particular cell in which the user is located and does not have an exact location when operating in the network (the user may be anywhere within a large 35km cell or group of 35km cells). The cellular network may not be able to locate the user within better fidelity than a state or county.

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

[0416] As a result, the satellite may need to maintain a consistent appearance of network integrity to the ground: since the user on the ground is not moving, the space network will tell the user that it is not changing its position so that update requests are not made if they are redundant.

[0417] When the base station transmits on the downlink control channel, it transmits the tracking area code in SIB1 which the UE receives and uses to know if its tracking area has changed and if a tracking area update needs to be done. There are other triggers mentioned before that trigger the tracking area update procedure on the network. This can be used to spoof the UE into thinking that it has not changed its tracking area on the network every time a new satellite flies by to serve the UE, even though it is communicating with a new MME.

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

[0419] In one embodiment, every single satellite may transmit the same 16-bit tracking area code for the SIB-1 block on the downlink control channel along with the base stations in the satellite constellation network. Each satellite base station may have a different cell ID and other downlink control information, but in this way the UE will not sense a change in location with every satellite overpass and will not use spectrum (either on the ground or on the satellite or on some satellite) on the uplink to access the network and do a tracking area update with the HSS. From the perspective of the terrestrial HSS, and possibly even from the perspective of the UE home network, the device's location can be sensed as "on the space network" so that when it needs to reach the UE, it does not need to manage which satellite to send traffic to. Instead, it just knows that the UE is on an MME that it senses as "space network" and the traffic will be routed to the MME in the space network that corresponds to the central / home earth station. At this node there will be an enhanced HSS and an enhanced MME. Together they can predict, manage and store the actual location of the UE in the network (e.g., which satellite is going to provide it with coverage) both now and in the future. As a result, the space network can intelligently determine which satellite base stations would be suitable satellites to deliver traffic to and exactly which route would be the best path for the traffic to get there (e.g., the fastest route around the network, the most balanced traffic load, etc.). [I.3.c Mobile country codes and mobile network codes]

[0420] A space network may be implemented to broadcast the mobile country codes or mobile network codes of partnered operators, or alternatively, the space network may be assigned its own unique mobile country codes and mobile network codes for use across the globe. [J. Extended HSS]

[0421] Database management procedures and functions in a space network can be particularly important when the network is configured to operate on orbit. For example, the HSS is used for locating users, authenticating users, billing users, providing services to users, etc., and is classically located away from the BTS and BSC functions in the terrestrial network. Often, the presence of the HLR is limited to only a few locations in the network because the validity of its "state" is very important for proper network function. While service provision and billing can be completed on orbit, these functions are not necessarily required and may remain on the ground in classical implementations. However, because the space network may comprise LEO satellites, the interaction time between a mobile device and the particular base station with which it is communicating in the space network may be limited to a very short window (perhaps a few minutes or less than a minute depending on the satellite's orbital configuration, link budget and coverage footprint design, the UE is included in a spot beam, 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 beam of exactly which satellite is 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 it can be queried of course. However, there may be a separate function that checks the clock and the latest state space database for the network and updates fields in the HSS for each IMSI under its provision. This HSS database may be internal to the space network and may not be treated as a master, but simply as a "check" for the example if the network needs to access that UE specifically. A master HSS for the UE may be kept on the ground and may be treated as the master HSS to which each query for that UE is initially directed. Once it is determined that the "space network" is serving the UE or was last serving it, traffic may be routed to a ground node in the "space network". It can then determine which satellites to route network traffic to based on this internal private network mapping of tracking area codes over time. [J.1 Authentication Strategy]

[0423] If the authentication and network access permission procedures are performed over the ISL and then can be returned to the ground to bounce queries to the HSS on the terrestrial home network, the process can extend beyond any single overpass time. If the constellation is designed for ubiquitous coverage, the response procedure can return to the user on the ground through the next satellite that overpasses it. If the authentication takes longer than the overpass period, the network can calculate which satellite in the network may be the next available satellite to complete the authentication procedure. This can allow handover during authentication to manage the authentication procedure with the device while it moves from connection session to connection session with different satellites 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 population of distributed cellular nodes, the following techniques may be used. [J.1.a(i) GEO repeater, MEO repeater and LEO repeater as P-GW extensions]

[0425] Orbital repeaters can be used as "always unidirectional" inter-satellite links from satellites on LEO (or provide an air interface to UEs on the ground) to a P-GW in the terrestrial network. The orbital repeater P-GW (or may simply be a bent pipe or repeater to a terrestrial P-GW) communicates with each satellite "network-in-box". In this case, the P-GW can operate in higher orbits, perhaps LEO, MEO or GEO or further away. With more satellite repeaters, more ground visibility is possible and fewer ground stations may be required for repeater global coverage. With this technology, all satellites in the LEO network would have access to a ground station gateway and from there to the terrestrial cellular network via a maximum latency communication link of 250 ms (250 ms is the mild latency speed from LEO satellite to GEO satellite and down to the ground station).

[0426] The one-way 200-300 ms voice latency requirement may be compromised for this relay link because this calculation does not include the processing time or latency through the terrestrial network after hitting the ground station and before being transmitted to the terrestrial core network on the ground. However, these latency requirements are more than sufficient for messaging and data services.

[0427] For continuous connectivity to ground using GEO, the orbital repeater may use four P-GW nodes, i.e., P-GW repeaters, on the GEO orbit. [J.1.a(ii) Repeater as MME / S-GW for the network]

[0428] Alternatively, the orbital repeater may house the entire core network and act as the MME / S-GW node (holding the VLR and HSS) for the entire LEO system, which would then comprise the base station satellite. This can reduce the complexity of many satellites in LEO, and shift the heavier core network functions to fewer, more capable, and longer-life satellites in higher orbits.

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

[0430] The following is general for the orbital configuration. In other words, this implementation can be used over a sole LEO network or in a network with additional relay satellites. Space-based cellular networks with on-orbit HSS and / or VLR may be involved.

[0431] A typical roaming authentication involves the visited network querying the home network HSS to gather the necessary authentication information each time the UE can authenticate. Typically, this is done each time a visiting subscriber roams onto a network that is not its own. In theory, the visited network may cache the results of the query in the home HSS and store the authentication information for that IMSI in a database. Since the authentication information is cached, after the first successful authentication procedure against the home network HSS, authentication may then occur on-orbit via the stored satellite HSS. In this way, handover techniques may be used first to obtain the IMSI through an initial authentication procedure via ground. A second attempt thereafter may rely on the on-orbit database for rapid authentication.

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

[0433] When avoiding terrestrial connection sessions altogether, the network may also spoof the authentication process. In other words, many users attempting to authenticate to the network will complete the authentication procedure with the base station. However, the space network may use calculated 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 authentication of the device to the network, and the network only knows to enable authentication of the user based on the IMSI. [J.1.d On-orbit certification]

[0434] The space network may use a complete HSS database for users provisioned to use its services onboard each satellite. In this configuration, the space network may actually be the home network and may actually store the UE keys. In this way, 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 simply queries in the on-orbit database to gather the necessary authentication vectors (from the AuC) and can complete the authentication in a rapid manner (seconds or less) and within a given overpass time for the user. [K. Satellite-mounted application server / IMS core]

[0435] A description of operating an example application server onboard a satellite to act as rapid IP bearer generation for storing and forwarding IP packets between two instances of the application layer in a PDN server.

[0436] In some phases of the constellation configuration described above, there may be intermittent connections, where a remote UE has access to communicate with a satellite base station, but the satellite base station does not yet have access to a terrestrial network where an application server or IMS server can be accessed. As a result, it may be difficult or impossible to move IP traffic between the application server and the mobile device, eliminating the possibility of using applications that require Internet access or back-end support. Even in scenarios where the satellite does not have terrestrial access, it may require latency between the UE and the PDN server, which may be momentary or not sufficient for useful transmission of data between the UE and the target PDN server.

[0437] A solution to this problem would be satellites in a constellation network that host light versions of server-side code so that communications can be processed while the UE is temporarily well enough to load the application, and data can be requested from the server without timeouts or failures to load the application. The satellite constellation could host computers and memory to use virtualized copies, caches or mirrors of "popular" servers that users access on the Internet. The computers and memory could even be dedicated to this function and sold or rented to companies that manage websites or applications and want to promote the use or access of their services or websites to users around the world. As an example, a popular website that runs a server in one country sees increased demand in other countries. So much so that more local instances of the server are needed to alleviate network bottlenecks and ease DNS traffic on the home server. By placing those cached copies in orbit, their physical propagation around the world allows more readily available access to data needed by remote users far from the original server. These cached or mirror copies of the origin server may act as "slave" copies, with the origin server acting as the "master" and pushing updates to its "slave" copies. As a result, the on-orbit server may be slightly "lagging" or have out-of-date data.

[0438] Additionally, a lite version of an application or website server may be used on orbit that can handle accepting IP packets from the device (e.g., as a WhatsApp message from a remote UE). The IP packets may be stored and forwarded to the appropriate ground application server where the data packets are received and the message is unpacked for the intended recipient. Once the message reaches the server, it may be routed to the appropriate recipient UE just as it would be in a normal ground scenario. By running a lite version of the server, it may be virtualized on hardware as small and low powered (compared to the actual server hosting the "master" copy) as a single board computer with a relatively simple processor and a small amount of memory.

[0439] Similar technology could be used with the IMS core to enable IMS-based services such as RCS to operate in an enhanced lite fashion at the state of the art. [L. Enhanced User Equipment (UE)] [L.1 Enhanced Network Overpath Prediction]

[0440] To support functions in space-based cellular networks, user equipment may benefit from slight enhancements. The UE may possibly be a point in a mesh of link state space computed by the enhanced MME. As a result, a journey of the handset on the network may also be generated.

[0441] Based primarily on the GPS position alone, the UE can be programmed to use its own state space prediction engine to calculate the next set of overpasses from the satellite. Similarly, the spacecraft, radio access and core network itinerary developed by the terrestrial enhanced MME can define a set of coverages for which the UE will calculate coverage examples for the current UE GPS position. The state space database for the space network (or parts of it based on the device's location) can be pushed to the UE so that it can be stored and used when outside of Internet / server connectivity and access. The UE can also perform calculations at the edge, hosting the network state space propagation function on the handset. When outside of typical terrestrial cell coverage, the UE can modify its cell search criteria and only know that the overpassing satellite may have passed it and provide it coverage for the next 5 seconds, 10 minutes, 30 minutes, etc.

[0442] Satellite overpass prediction can be implemented at the application layer on the user interface side (e.g., smartphone app). This can enable the application to predict satellite overpasses and facilitate the storage and forwarding of data / messages / SMS sent between phones in a messaging application. The application will know to attempt to send that message at a particular time, and the software application can command the phone to do so. Additionally, the software application can toggle airplane mode on the smartphone, which will cause the phone to immediately go into scanning mode (e.g., effectively powering the device on and off) to find available networks.

[0443] A prediction of a satellite overpass may be provided by a process that similarly informs the control plane between the UE and the network. As an example, a typical search procedure for a mobile device UE may be modified to include a timer that checks the time for a provided process for an overpass. Based on the timer, the UE may implement a procedure for scanning PLMN codes and / or cell ID codes from orbiting base stations for a particular LTE ARFCN bandwidth, for example, if no other terrestrial or orbiting base stations are available at that time. This may facilitate saving battery power on the device, typically outside of terrestrial coverage, since it knows exactly when to start scanning for a newly available network access from an orbiting base station. Furthermore, there may be existing knowledge of how long the UE can use the satellite after connecting to an orbiting base station. Based on this period, the UE may determine which bidirectional communication is feasible and possibly which priority to give for a given overpass. Additionally, by this point the journey may include information about the service levels for a given overpass with respect to radio access technology (e.g., GSM or LTE), data rate expectations, etc. This information may drive the device's decisions about which applications / data to request / move to / from the network (e.g., on GSM the device may favor SMS / low data rate traffic that it desires to move, but on LTE applications with higher data rate requirements, etc.).

[0444] The itinerary provided by the enhanced MME may include a specific timestamp for when the UE should request access to the space base station network if the UE needs to perform an attachment session with the network or backend server / PDN server. The timing described above may be provided to the UE such that the UE's scheduled network access request signals are time duplexed apart from each other, thus ameliorating potential issues of instantaneous PRACH activity and contention between UEs. The itinerary may include which PRACH channels are available to a particular UE or even a set of UEs. Further control channel signaling may be predicted or automated for UE and tracking area updates, authentication, etc. [L.2 Extended transmission power]

[0445] The UE may also be enhanced to include increased transmit power for the uplink to the base station. A benefit of the present disclosure may be that the UE may use standard transmit power at typical terrestrial cell locations, but in remote areas without interfering towers, may uplink to satellites at powers higher than 200mW for LTE (and 2W for GSM).

[0446] The transmit power on the uplink may be triggered to be higher based on certain criteria such as the MCC and MNC codes of the network (e.g., to allow higher transmit power to support uplink closure if the network is a space-based network). SIB and MIB blocks are often used to indicate to the UE what maximum transmit power is allowed for the cell. Space network base stations may be allowed to transmit higher values ​​than terrestrial cells, which may be extended for the UE to understand and accommodate.

[0447] Existing UEs may be compatible with GSM and LTE protocols, and as such, there may be existing configurations that can take advantage of the 2W peak transmit power allowed in GSM to be used in LTE communications.

[0448] This may allow for closing the link in high attenuation environments, and there may be a need for this in the protocol during disasters when a device may want to temporarily surge power and support closing the link to an upward satellite. [L.3 Antenna extension]

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

[0450] The addition of a circularly polarized antenna feature may work even though circularly polarized signals may be degraded by multipath effects, since the signal bounce may result in a single reflection that no longer results in the same polarization as the receiving antenna. As a result, communications may become a significant link inhibitor since a single reflection cannot be easily received and line of sight is lacking. Multipath in terrestrial communications may rely on linearly polarized signals, possibly at multiple linearization angles, to support off-angle polarized reception of one of these signals.

[0451] Classically in terrestrial systems, line of sight is not available to the link due to the horizontal geometry of the link relative to the tower, and therefore the link may be modeled as a link with Rayleigh fading (where the bouncing signal dominates the link). In satellite communications, line of sight may often dominate the link, and circularly polarized antennas may be particularly useful. In one embodiment, a circularly polarized antenna in the UE may be enabled for communications with the satellite and disabled otherwise. However, this antenna may be able to receive linear signals. [L.4 UE-base station air interface protocol extensions]

[0452] There may be further enhancements to UEs used on cellular networks where more advantageous link budget protocols may be used to support increased coverage of communications between UEs on the Earth's surface and satellite base stations in orbit. This may also be done to support communications between satellites and UEs inside buildings or under roofs, in metal containers, etc. This may also be used to increase the distance of communications with ground towers. At the heart of these protocols will be enhanced or modified waveforms used between the UE and satellite base station to increase the power spectral density of the signal on the uplink, or to exploit some element of transmit diversity (e.g., frequency diversity or code diversity), or perhaps to exploit some additional signal processing gain to get the signals from the UE and base station out of the noise floor.

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

[0454] There may be embodiments in which the NB-IoT protocol is used only on the satellite network, or alternatively, there may be embodiments 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 to communicate on the downlink (and sufficiently more power is used on the downlink to close the link in that direction only).

[0455] Further embodiments may exist in which the UE is augmented with a protocol that utilizes either the existing cellular bands, WiFi bands (2.4 GHz) or ISM bands (902-928 MHz) to communicate using some coded or frequency hopped signals to spread a low data rate signal over a bandwidth to provide a mechanism for communicating with UEs that are under a fairly limited communication link (e.g., underground, inside a building, in an area with significant RF interference). [M. Alternative Expansion Description]

[0456] There may be an embodiment for an extension of the network described above, in which the UE is equipped to communicate at the higher frequencies allocated in the Ka or Ku bands for the 5G NR air interface. At these frequencies, especially with orbit-to-ground satellite communications, the antennas may be very small, but the path loss may be too large.

[0457] In such a scenario, with limited transmit power and reduced antenna gain on the device, the UE may not be able to close the link on the uplink. However, the satellite may be sized sufficiently to be able to communicate in the Ku or Ka bands down from orbit to the UE, but not in the other direction (without equipping the UE with substantially more transmit power, and possibly beamforming capabilities).

[0458] In this example, the communication network in this disclosure may implement frequency asynchronous communication operation. A low frequency cellular band allows a low data rate uplink for approaching the UE directly to the orbiting eNB. On the uplink, the device may request access to a high data rate downlink service (such as seamless movie streaming or large data sets downloaded from the Internet). The eNB in ​​the satellite network may be able to communicate bidirectionally with the UE in the low frequency cellular band, but may also be extended to allocate a set of downlink resource blocks, carriers, time slots, etc. in an orthogonal frequency band (such as Ka-band or Ku-band) with the ability to provide high power and possibly beamform the downlink signal to the UE to provide the high data rate requirements required by the service.

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

[0460] There may be embodiments for cellular space networks deployed for use cases where thin uplink channels are needed to enable large downlink channels. As an example, there may be devices that can receive high throughput satellite downlink data (for entertainment) from GEO on vehicles such as cars. However, the vehicle may not have the aspects to communicate backup to GEO satellites to control the downlink. A cellular modem may be used to connect the car to the thin uplink and send commands to perform a specific high throughput downlink from GEO.

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

[0462] Unless otherwise stated herein or unless otherwise clearly contradicted by 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 are collectively executed on one or more processors by hardware or a combination thereof. The code may be stored in a computer-readable storage medium, for example, in the form of a computer program that includes a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0463] Unless otherwise indicated or unless the context clearly contradicts otherwise, transitional language such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" are understood in their commonly used context to indicate that an item, term, etc. may be A or B or C, or any non-empty subset of the set of A, B, and C. For example, in the illustration of a set having three members, the transitional 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 transitional language is generally not intended to imply a particular embodiment that requires the presence of each of at least one of A, at least one of B, and at least one of C.

[0464] The use of any examples or exemplary language (e.g., "etc.") provided herein is intended merely to better elucidate embodiments of the invention and does not pose limitations on the scope of the invention unless otherwise asserted. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0465] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Accordingly, the specification and drawings should be regarded in an illustrative rather than a limiting sense. The sole and exclusive indication of the scope of the invention, and what the applicant intends to be the scope of the invention, is the literal and equivalent scope of the set of claims issuing from this application, in the particular form in which such claims arise, including any subsequent amendments.

[0466] Further embodiments may be envisioned by those skilled in the art after reading this disclosure. In other embodiments, combinations or subcombinations of the inventions disclosed above may be advantageously made. It is to be understood that the exemplary arrangements of components are shown for illustrative purposes, and that combinations, additions, rearrangements, and the like are envisioned in alternative embodiments of the invention. Thus, while the invention has been described with reference to 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. Accordingly, the specification and drawings should be regarded in an illustrative and not a restrictive sense. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims, and the invention is intended to encompass all modifications and equivalents within the scope of the following claims. [Example items]

[0468] Embodiments of the present disclosure may be described in view of the following items.

[0469] [Item 1] a first database table of first node records, the first node record representing a terrestrial base station, the first node record including operational details of the terrestrial base station; a second database table of second node records, the second node record representing an orbital base station, the second node record including operational details of the orbital base station; a state space prediction computer that calculates link budgets for connections to a base station represented in the first database table and a base station 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 a state space record of the plurality of state space records indicates, for a plurality of mesh points within a coverage area, which active base stations are providing link service within the coverage area and which deferred base stations have suspended their use of a shared protocol and a shared frequency band shared by the active base stations.

[0470] [Item 2] 2. The cellular network management system of claim 1, wherein the deferred base stations suspend their use of the shared protocol based on an allocation of network resources, the allocation of network resources excluding the allocated network resources that were allocated to the orbit base stations, thereby causing the deferred base stations to suspend their use without the need to program the deferred base stations to recognize the suspension request.

[0471] [Item 3] 3. The cellular network management system of claim 1, wherein the active base stations include at least one active orbit base station, and the deferred base stations include at least one passive terrestrial base station, and the at least one passive terrestrial base station is in a passive state based on the network usage dataset if the at least one active orbit base station is predicted to provide coverage for the coverage area.

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

[0473] [Item 5] 5. The cellular network management system according to any of items 1 to 4, further comprising a coverage database having mesh points and polygon coverage areas referenced in said coverage database for each base station, the respective base stations including at least some static coverage terrestrial base stations, at least some static coverage orbital base stations using beamforming, and at least some dynamic coverage orbital base stations using dynamic beams that move across the coverage area as the at least some dynamic coverage orbital base stations move on their respective orbits.

[0474] [Item 6] 6. The cellular network management system of any of items 1 to 5, wherein the state space database takes into account coverage dynamics including emergency situations where coverage by an orbital base station would change based on the emergency situation.

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

[0476] [Item 8] 7. The cellular network management system of claim 6, wherein the emergency situation includes a predicted natural disaster and the coverage dynamics includes an increase in capacity within an area based on input data provided by a first responder.

[0477] [Item 9] 9. The cellular network management system of any of items 1 to 8, further comprising handover logic for signaling to user equipment of an impending handover of the link from the first orbital base station to the second orbital base station using signaling consistent with a terrestrial network handover protocol.

[0478] [Item 10] 10. The cellular network management system of any of claims 1 to 9, further comprising handover logic for maintaining a tunneled data link between a user equipment and a computer system remote from a cellular network managed by the cellular network management system by signaling to the user equipment of an impending handover of a connection to the tunneled 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] 11. The cellular network management system of any of claims 1 to 10, further comprising authentication logic for authenticating a user equipment (UE) device to a cellular network using signaling consistent with a terrestrial network handover protocol and maintaining authentication of the UE device across a handover of a link from a first orbital base station to a second orbital base station.

[0480] [Item 12] Item 12. The cellular network management system of item 11, wherein the authentication logic is implemented in an authentication orbit base station and the authentication is cached for use in the first orbit base station and / or the second orbit base station.

[0481] [Item 13] 1. A itinerary generator for use in a cellular network having a plurality of base stations, at least one of which is a terrestrial base station and at least one of which is an orbital base station, comprising: a first generator for generating a spacecraft itinerary; a second generator for generating a satellite function itinerary; a state space database storing said spacecraft itinerary and said satellite function itinerary; a network planner computer for storing static positions of base stations and outputting a coverage indication indicating which orbital base stations are providing coverage for which regions within a coverage area based on said state space database; and a database distributor for distributing a copy of said state space database to each of a plurality of spacecraft network nodes.

[0482] [Item 14] Item 14. The itinerary generator of item 13, further comprising a command and control system in communication with the network planner computer, the command and control system having logic for managing the state of an orbit base station, the command and control system operable to adjust the state space database in response to changes in state.

[0483] [Item 15] Item 15. The itinerary generator of item 14, wherein the conditions of the orbital base station include one or more of temperature, power level, fuel level, processor health and / or radio health, and the itinerary is adjusted based on the conditions.

[0484] [Item 16] 16. A journey generator as described in any of items 13 to 15, wherein the state space database has at least one back-up journey for use when state conditions preclude the use of a previously generated satellite function journey.

[0485] [Item 17] 17. A journey generator according to any of items 13 to 16, wherein the state space database has an optimized journey based on one or more of a set of rules or quality of service requirements.

[0486] [Item 18] 18. A journey generator according to any of items 13 to 17, wherein the state space database has calculated journeys for ground stations or orbital elements in the network.

[0487] [Item 19] 1. A method of determining coverage for a cellular network, comprising: storing a database of a plurality of mesh points, each mesh point having a location within a coverage area and metadata about services at that mesh point; storing a database of a plurality of coverage regions, each having a finite area and at least some having polygonal boundaries; assigning the plurality of mesh points to coverage regions for an assigned time, the coverage regions varying over time based on an orbit of an orbiting base station; and controlling a base station to provide coverage to the assigned coverage region for the assigned assigned time.

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

[0489] [Item 21] 1. A method for managing a plurality of orbital base stations in communication with a user equipment (UE) device of a cellular network, comprising: determining a first coverage area for a first orbital base station of the plurality of orbital base stations; determining a second coverage area for a second orbital base station of the plurality of orbital base stations; and determining a modification of a signal from the second orbital base station for when the first coverage area and the second coverage area overlap, the modification including a change in the signal that a UE device is programmed to interpret as a loss of signal strength between fixed base stations, thereby triggering a request for a handoff to the first orbital base station.

[0490] [Item 22] 22. The method of claim 21, further comprising: generating a plurality of mesh points, each of which represents a position within an entire coverage area; generating a plurality of polygons covering the plurality of mesh points; determining a link budget for a given mesh point of the plurality of mesh points; determining a set of applicable wireless communication constraints for the given mesh point; and for each of a plurality of base station beams that coincide with a particular polygon having coverage of the given mesh point, determining beam parameters based on the set of applicable wireless communication constraints for the given mesh point within the particular polygon.

[0491] [Item 23] A user equipment (UE) device capable of computing and mobile wireless communications, the memory for storing an operating system, application program code, and a node availability table indicating nodes of a wireless network that are predicted to be available for a future pre-calculated time period determined at least in part based on orbital dynamics for nodes implemented on an orbital platform; a UE device comprising: a processor for executing the application program code and for timing communication processing of the application program code to coincide with node availability indicated by the node availability table; and communications circuitry usable for receiving at least an indication of the node availability table and for communicating with the wireless network.

[0492] [Item 24] 24. The user equipment (UE) device of claim 23, wherein the node availability table indicates nodes of the wireless network that are predicted to be available in the future pre-calculated time period, which is further determined by link budget calculations for nodes implemented on the orbital platform.

Claims

1. 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 terrestrial base station and at least one of which is an orbital base station, the network management computer system comprising: a journey generator for generating a plurality of steps to be used between the cellular network, the steps of the plurality of steps reflecting information regarding operations performed over a period of time and / or conditions of the network over the period of time, the steps being one or more of: a spacecraft journey associated with a spacecraft having the orbital base station thereon, a network journey associated with the operation of the cellular network, and / or an orbital base station journey associated with the operation and / or conditions of the orbital base station; A state space database storing the plurality of processes; a network planner computer that stores base station locations and outputs a coverage indication indicating which orbital base stations are providing coverage to which regions within a coverage area based on the state space database; a database distributor for distributing copies of the state space database to a plurality of spacecraft network nodes; A network management computer system comprising:

2. 2. The network management computer system of claim 1, wherein the locations of base stations include orbital base station locations and / or terrestrial base station locations.

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

4. 4. The network management computer system of claim 3, wherein the static locations of the base stations indicate which orbital base stations are providing coverage to which regions within a coverage area based on the state space database.

5. The spacecraft journey includes operation of a spacecraft beam, including thruster utilization / operation, attitude CONOP and control operations, and / or operating power modes; the network journey comprises a network dynamic IP routing table and / or handover data representative of one or more of a spot beam handover, a satellite handover, a terrestrial gateway handover, and a UE handover; The orbit base station process represents one or more of 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. 6. The network management computer system of claim 1, further comprising a command and control system in communication with said network planner computer, said command and control system including logic for managing the state of an orbital base station operable to adjust said state space database in response to changing conditions.

7. 7. The network management computer system of claim 1, wherein the condition of the orbital base station includes one or more of temperature, power level, fuel level, processor health and / or radio health, and the itinerary is adjusted based on said condition.

8. The plurality of base stations comprises a plurality of orbital base stations, and the network management computer system comprises: determining a first coverage area for a first orbital base station of the plurality of orbital base stations; determining a second coverage area for a second orbital base station of the plurality of orbital base stations; determining a modification of a signal from the second orbital base station for an overlap between the first coverage area and the second coverage area; 8. The network management computer system of claim 1, wherein the modification includes a change in the signal, and wherein a user equipment (UE) device is programmed to interpret the change in the signal as a loss of signal strength between stationary base stations and thereby trigger a request for handoff to the first orbital base station.

9. 9. The network management computer system of claim 8, wherein the network management computer system is further configured to issue instructions to the second orbital base station to modify its signaling and use the modified signal.

10. The network management computer system includes: generating a plurality of mesh points, each mesh point representing a location throughout the coverage area; generating a plurality of polygons covering said plurality of mesh points; determining a link budget for a given mesh point of the plurality of mesh points; determining a set of applicable wireless communication constraints for the given mesh point; For each of a plurality of base station beams coinciding with a particular polygon having coverage for the given mesh point, determining beam parameters based on the set of applicable wireless communication constraints for the given mesh point within the particular polygon.

10. A network management computer system according to claim 8 or claim 9, further configured to:

11. The network management computer system includes: performing physical simulations of orbital mechanics, attitude dynamics, and link budgets to derive a set of future link states for a network managed by said network management computer system; determining at least some of the steps based on the set of future link states; 11. A network management computer system according to any preceding claim, configured to:

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

13. 13. A network management computer system as claimed in any one of claims 1 to 12, wherein the state space database includes at least one back-up path for use when state conditions preclude the use of a previously generated satellite function path.

14. 14. A network management computer system according to any preceding claim, wherein the state space database comprises optimized journeys based on one or more of a set of rules or quality of service requirements.

15. 15. A network management computer system as claimed in any preceding claim, wherein the state space database includes processes that account for orbital operations and satellite maintenance.

16. 16. The network management computer system of claim 1, wherein the state space database includes a process that takes into account whether an orbital base station includes a beamforming antenna capable of providing a relatively stationary coverage footprint.

17. 1. A method for managing a plurality of orbital base stations in communication with user equipment (UE) devices of a cellular network using a network management computer system, the method comprising: determining a first coverage area for a first orbital base station of the plurality of orbital base stations; determining a second coverage area for a second orbital base station of the plurality of orbital base stations; determining a modification of a signal from the second orbiting base station for an overlap between the first and second coverage areas, the modification including a change in the signal that a UE device is programmed to interpret as a loss of signal strength between stationary base stations, thereby triggering a request for a handoff to the first orbiting base station; A method comprising:

18. generating a plurality of mesh points, each mesh point representing a location within the overall coverage area; generating a plurality of polygons covering the plurality of mesh points; determining a link budget for a given mesh point of the plurality of mesh points; determining a set of applicable wireless communication constraints for the given mesh point; determining beam parameters for each of a plurality of base station beams that coincide with a particular polygon having coverage for the given mesh point based on the set of applicable wireless communication constraints for the given mesh point within the particular polygon; The method of claim 17 further comprising:

19. A method for managing a mobility management entity, comprising: performing physical simulations of orbital mechanics, attitude dynamics and link budgets to derive a set of future link states for a network managed by said mobility management entity; determining procedures for spacecraft operation, radio access network operation, and core network operation based on the set of future link conditions; A method comprising:

Images