WO2023022920A1 - Système de communication par satellite meo-leo intégré - Google Patents

Système de communication par satellite meo-leo intégré Download PDF

Info

Publication number
WO2023022920A1
WO2023022920A1 PCT/US2022/040098 US2022040098W WO2023022920A1 WO 2023022920 A1 WO2023022920 A1 WO 2023022920A1 US 2022040098 W US2022040098 W US 2022040098W WO 2023022920 A1 WO2023022920 A1 WO 2023022920A1
Authority
WO
WIPO (PCT)
Prior art keywords
satellite
leo
meo
user terminal
constellation
Prior art date
Application number
PCT/US2022/040098
Other languages
English (en)
Inventor
Channasandra Ravishankar
Xiaoling Huang
III John E. CORRIGAN
Original Assignee
Hughes Network Systems, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/535,823 external-priority patent/US11916654B2/en
Application filed by Hughes Network Systems, Llc filed Critical Hughes Network Systems, Llc
Priority to CA3227920A priority Critical patent/CA3227920A1/fr
Priority to EP22765312.8A priority patent/EP4388677A1/fr
Publication of WO2023022920A1 publication Critical patent/WO2023022920A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/18521—Systems of inter linked satellites, i.e. inter satellite service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/11—Arrangements specific to free-space transmission, i.e. transmission through air or vacuum
    • H04B10/118—Arrangements specific to free-space transmission, i.e. transmission through air or vacuum specially adapted for satellite communication

Definitions

  • Satellite systems can provide global high-speed coverage and may reach areas unserved or underserved. Thus, there is a significant need for new and improved mechanisms for providing satellite-based communication systems coverage.
  • Satellites which provide satellite-based broadband communication may be located at different altitudes above the earth. Satellites in a Low Earth Orbit (LEO) are typically about 2000 km and below. A Geostationary Orbit (GEO) satellite is 35,786 km above the earth. A Medium Earth Orbit (MEO) is greater in altitude than that of the LEO and less than that of the GEO, or about 2000 km to 35,786 km. As used herein, a constellation is a group of satellites at a given altitude.
  • LEO Low Earth Orbit
  • GEO Geostationary Orbit
  • MEO Medium Earth Orbit
  • a constellation is a group of satellites at a given altitude.
  • the instant disclosure describes a technical solution to the problem of providing global coverage for satellite communication systems that combines the benefits of Medium Earth Orbit (MEO) and Low Earth Orbit (LEO) satellite systems into an integrated MEO- LEO satellite communication system.
  • the MEO-LEO communication system described herein includes an LEO constellation combined with a MEO constellation where the LEO constellation may provide global coverage with broad average capacity and may support ‘hot spot’ coverage where desired.
  • the MEO constellation may provide unique advantages including backhaul to ground in remote areas (such as but not limited to deep ocean areas), higher traffic density for key locations, and a secure global backhaul for key customers.
  • SDN Software Defined Networking
  • MEO-LEO backhaul and ground access
  • LEO - LEO upstream & downstream
  • MEO - MEO crosslinks & downlinks
  • implementations described herein include secure user terminal (UT) to UT IP routing in the constellation for direct UT to UT communication.
  • the LEO and MEO constellation satellites may form a mega constellation comprising many satellites orbiting the Earth. Such a mega constellation may include hundreds or even thousands of satellites. Communications are facilitated using intraconstellation and inter-constellation cross links as described herein.
  • Technical benefits of a MEO-LEO satellite system include global consumer and enterprise Internet Protocol (IP) data, and the ability to provide secure IP data services between users and/or enterprises without traversing gateways and associated terrestrial links.
  • IP Internet Protocol
  • SDN routing capabilities that provide complete functionality at any stage of deployment. Routes are determined by a central ground controller, and routing tables are uplinked to satellites.
  • Space-based Phased Array antenna support multiple modes to provide support for hot-spots and high- density areas, uniform density coverage, and “earth fixed” operation and “satellite fixed” operation narrowband operations with improved link margins.
  • An example of disclosed systems herein can include a Medium Earth Orbit (MEO) satellite constellation with a plurality of MEO satellites; a Low Earth Orbit (LEO) satellite constellation with a plurality of LEO satellites; and wherein the plurality of MEO satellites and the plurality of LEO satellites are configured to support a MEO-LEO satellite link that allows communication between a MEO satellite in the MEO constellation and a LEO satellite in the LEO constellation.
  • MEO Medium Earth Orbit
  • LEO Low Earth Orbit
  • An example of disclosed systems herein can include a Medium Earth Orbit (MEO) satellite constellation with a plurality of MEO satellites; a Low Earth Orbit (LEO) satellite constellation with a plurality of LEO satellites; wherein the plurality of MEO satellites and the plurality of LEO satellites are configured to support a MEO-LEO satellite link that allows communication between a MEO satellite in the MEO constellation and a LEO satellite in the LEO constellation; a first user terminal communicating with a first LEO satellite and a second LEO satellite communicating with a second user terminal located at a geographical location remote from that of the first user terminal; a direct user terminal to user terminal security association that supports sending encrypted data directly from the first user terminal to the second user terminal with a private key; wherein: the plurality of MEO satellites and the LEO satellite further comprise an MEO-LEO link for communicating with a satellite in another constellation; and the satellite communication system provides a nonterrestrial communication path directly from the first user terminal to the second user terminal by communications between the
  • An example of disclosed systems herein can include a Medium Earth Orbit (MEO) satellite constellation with a plurality of MEO satellites; a Low Earth Orbit (LEO) satellite constellation with a plurality of LEO satellites; and wherein the plurality of MEO satellites and the plurality of LEO satellites are configured to support a MEO-LEO satellite link that allows communication between a MEO satellite in the MEO constellation and a LEO satellite in the LEO constellation, wherein the plurality of MEO satellites and the LEO satellite further comprise an optical inter-satellite link for communicating with a satellite in another constellation; a first user terminal communicating with a first LEO satellite and a second LEO satellite communicating with a second user terminal located at a geographical location remote from that of the first user terminal; a direct user terminal to user terminal security association that supports sending encrypted data directly from the first user terminal to the second user terminal with a private key; a direct user terminal to user terminal control plane communication between a first radio resource control user (RRC-U) block in
  • FIG. 1 is a diagram showing an example implementation of the MEO-LEO system according to the instant disclosure.
  • FIG. 2 shows LEO constellation parameters for an example constellation with 864 satellites.
  • FIG. 3 shows LEO constellation parameters for an example constellation with 432 satellites.
  • FIG. 4 shows an example of a LEO satellite that may be used with the techniques of the instant application.
  • FIG. 5 is a diagram showing the LEO Gateway Link Antenna Pattern Using Bessel Function (ES Elev. 25 degrees).
  • FIG. 6 shows MEO constellation parameters for an example constellation satellite.
  • FIG. 7 shows an example of a MEO satellite that may be used with the techniques of the instant application.
  • FIG. 8 illustrates a satellite communication system according to the prior art.
  • FIG. 9 is a diagram showing a first scenario for UT-UT connectivity.
  • FIG. 10 is a diagram showing a second scenario for UT-UT connectivity.
  • FIG. 11 illustrates an implementation of IP routing in a satellite system for secure UT to UT communication.
  • FIG. 12 is a data flow diagram for secure direct UT to UT communication in a satellite system.
  • FIG. 13A illustrates an implementation of IP routing in a satellite system for secure UT to UT communication.
  • FIG. 13B illustrates a first example of direct communication between a first user terminal and a second user terminal.
  • FIG. 13C illustrates a second example of direct communication between a first user terminal and a second user terminal.
  • FIG. 14 is a block diagram showing an example software architecture, various portions of which may be used in conjunction with various hardware architectures herein described, which may implement any of the features described herein.
  • FIG. 15 is a block diagram showing components of an example machine configured to read instructions from a machine-readable medium and perform any of the features described herein.
  • FIG. 1 is a diagram showing an example implementation of the MEO-LEO system 100 according to the instant disclosure.
  • the specific implementation shown in FIG. 1 is just one possible implementation of a MEO-LEO system according to the instant disclosure.
  • the example implementation of the MEO-LEO system 100 shown in FIG. 1 includes a MEO constellation 110 and a LEO constellation 112.
  • the MEO constellation 110 has a number of MEO satellites 114.
  • the MEO satellites 114 may be interconnected by MEO links 116 between the satellites as described further below.
  • the LEO constellation 112 has a number of LEO satellites 118 interconnected by LEO links 120 between the LEO satellites 118.
  • the MEO links 116 and the LEO links 120 may be optical links or RF links.
  • the MEO constellation 110 and the LEO constellation 112 may have any number of satellites as described further below.
  • the MEO-LEO system 100 further includes a number of user terminals (UT) that communicate with the MEO satellites 114 and the LEO satellites 118.
  • a first user terminal 124 communicates over a single beam 126, on a single Ka band, to the MEO satellites 114.
  • a second user terminal 128 communicates with two beams 130, 132 to the satellites.
  • the first beam 130 is on the Ka band and communicates with the MEO satellites 114.
  • the second beam 132 is on the Ku band and communicates with the LEO satellites 118.
  • a third user terminal 134 communicates over a single beam 136 with a single, Ku band, to the LEO satellites 118.
  • the MEO-LEO system 100 may include a number of satellite gateways that also communicate with the satellites.
  • LEO satellite gateways 138 may communicate with LEO satellites 118 over one or more beams and one or more bands.
  • the LEO gateways 138 communicate with the LEO satellites 118 over a combination of Ka and Q/V bands 140.
  • the LEO satellite gateways 138 communicate over an internet protocol (IP) core network 142 with one or more servers 144.
  • the servers 144 may include subscription, security, management and application servers.
  • the IP core network 142 may also include a border gateway 146 for connecting to external IP networks 148.
  • MEO satellite gateways 150 may communicate with MEO satellites 114 over one or more beams and one or more bands.
  • the MEO gateways 150 communicate with the MEO satellites 114 over a combination of Ka, Q/V, and E bands 152.
  • the MEO-LEO system 100 may further include a software defined network (SDN) controller 152.
  • the SDN controller 152 in the example MEO-LEO system 100 shown in FIG. 1 is located on the IP core network 142.
  • the SDN controller 152 may be located within the satellite gateways 138, 150. Since power on a satellite is limited, it is desirable to put the SDN controller function on the ground where power is more readily available. Placing the complex SDN controller function on the ground also allows for a simplified router on the satellite where the satellite router simply routes the data according to instructions received from the SDN controller 152.
  • the SDN controller 152 receives information about conditions of the various links in the MEO-LEO system 100 and calculates a route for data through the system based on the condition of the links. Examples of the MEO-LEO links and routing through these links are described further below.
  • the satellite system 100 may further include a satellite communication table 154 connected to a server 144 for storing user terminal connection data as described further below.
  • the satellites 114, 118 may also include a routing table 156 as described below.
  • the MEO-LEO system 100 may provide hot spot coverage.
  • hot spot coverage means that there are certain regions in the coverage area where there is a significantly higher demand compared to other regions and the system provides the capability to allocate commensurate satellite resources (frequency and power) to satisfy the demand.
  • FIG. 2 shows LEO constellation parameters for an example constellation with 864 LEO satellites.
  • the LEO satellites 118 have a satellite elevation 212 of 1150 km.
  • This satellite elevation 212 provides a satellite coverage footprint 214 of 1785 km on the earth’s surface.
  • the constellation Height is 1150 km with 36 planes and 24 satellites per plane.
  • the minimum UT Elevation is 45.7 degrees.
  • the satellites 118 include a Ku user link and one or more Ka and V/Q Gateway links.
  • the user link uses a phased array antenna.
  • Each satellite 118 includes optical inter-satellite links as described further below. Both left hand circular polarization (LHCP) and right hand circular polarization (RHCP) may be used in user links and Gateway Links.
  • the satellites 118 have 16 GHz user spectrum per satellite providing 32 Gbps per satellite.
  • the user data rate in the forward link is 1 Gbps per 500 MHz channel.
  • a plane is a specific orbit in which one or more satellites revolve around the earth. A plane is typically identified by altitude, inclination, longitude of ascending node etc. [0035] Table 1 summarizes some representative LEO system parameters for the example LEO constellation 112 shown in FIG. 1.
  • FIG. 3 shows representative LEO constellation parameters for an example constellation with 432 LEO satellites.
  • the LEO satellites 118 have a satellite elevation 312 of 1150 km. This satellite elevation 312 provides a satellite coverage footprint 314 of 2292 km on the earth’s surface.
  • the constellation Height is 1150 km with 18 planes and 24 satellites per plane.
  • the minimum UT Elevation is 37.4 degrees.
  • the satellites 118 include a Ku user link and one or more Ka and V/Q Gateway links.
  • the user link uses a phased array antenna.
  • Each satellite 118 includes optical inter-satellite links as described further below. Both LHCP and RHCP in user links and Gateway Links.
  • the satellites 118 have 16 GHz user spectrum per satellite providing 32 Gbps per satellite.
  • the user data rate in the forward link is 1 Gbps per 500 MHz channel.
  • Table 2 summarizes some representative MEO system parameters for the example MEO constellation 110 shown in FIG. 3.
  • Ground System deployment may be incremental based on user traffic demand. Gateways may be placed in areas where coverage is required. Inter-satellite links may be used for the backhaul. Another technical benefit of the MEO-LEO satellite system is that MEO requires fewer gateways. For example, 6-8 gateways may be sufficient for global coverage.
  • FIG. 4 shows an example of the LEO satellite 118 described above in the LEO constellation 112.
  • the LEO satellite 118 in this example is configured with link hardware to support five Inter- Satellite Links (ISLs) to adjacent LEO satellites.
  • the ISLs are preferably optical links.
  • the ISLs include a MEO-LEO optical link 410 that connects the LEO satellite 118 to a MEO satellite 114 in the MEO constellation 110 as shown in FIG. 1.
  • the MEO- LEO optical link 410 is preferably a high bandwidth to provide backhaul to LEO satellites.
  • backhaul refers to a network connection transmitting a signal from a remote site or network to another site or network.
  • the LEO satellite 118 includes east and west optical links (ISL-East 414, ISL-West 412) that connect the satellite 118 to adjacent satellites in adjacent planes to the east and west respectively.
  • the LEO satellite 118 further includes north and south optical links (ISL-North 416, ISL-South 418) that connect to adjacent satellites in the same plane to the north and south.
  • the LEO satellite 118 further includes a user link 420 and gateway links 422.
  • the user link 420 includes a Ku-band phased array user link antenna.
  • the gateway links include two Ka-band and a Q/V band gateway links for backhaul.
  • the Ku antenna can also link backhaul traffic to a gateway if needed.
  • FIG. 5 is a diagram showing the LEO gateway link antenna pattern using Bessel Function (ES Elev. 25 degrees).
  • the gateway link antenna provides beam steering to 49.710 degrees.
  • FIG. 6 shows MEO constellation parameters for an example MEO constellation with 64 MEO satellites 114.
  • the MEO satellites 114 have a satellite elevation 612 of 8000 km. This satellite elevation 612 provides a satellite coverage footprint 614 of 6523 km on the earth’s surface.
  • the constellation has 8 planes with 8 satellites per plane. The minimum UT Elevation is 41.2 degrees.
  • the MEO satellite 114 can use satellite steering to cover further north to Alaska.
  • the satellites 118 include a Ka band user link and one or more Ka, V/Q and E gateway links.
  • the user link uses a phased array antenna.
  • Each satellite 114 includes optical inter-satellite links as described further below. Both LHCP and RHCP are used in the user links and gateway links.
  • the satellites 114 have 48 GHz user spectrum per satellite providing about 100 Gbps per satellite.
  • FIG. 7 shows an example of the MEO satellite 114 described above in the MEO constellation 110.
  • the MEO satellite 114 in this example includes six ISLs to adjacent LEO satellites.
  • the ISLs include a MEO-LEO optical link 710 that connects the satellite 114 to an LEO satellite 118 in the LEO constellation 112 as shown in FIG. 1.
  • the MEO-LEO optical link 710 is preferably a high bandwidth to provide backhaul to LEO satellites.
  • the MEO satellite 114 includes east and west optical links (ISL-East 712, ISL-West 714) that connect the satellite 114 to adjacent satellites in adjacent planes to the east and west respectively.
  • the MEO satellite 114 further includes north and south optical links (ISL-North 716, ISL-South 718) that connect to adjacent satellites in the same plane to the north and south.
  • the MEO satellite 114 further includes a user link 720 and gateway links 722.
  • the user link 720 includes a Ka-band user link with a phased array antenna.
  • the gateway links include four Ka-band and a Q/V band gateway links for backhaul.
  • the Ka antenna can also link backhaul traffic to a gateway if needed.
  • the MEO satellite 114 may further include a MEO-GEO link 724 to a geosynchronous satellite.
  • the MEO-GEO link 724 may be an optical link similar to the MEO-LEO optical link 710 disposed on the satellite facing geosynchronous satellite located above the MEO satellite 114.
  • FIG. 8 shows a satellite communication system 800 which illustrates prior art communication in a satellite system.
  • a first user terminal (UT-1) 810 connects to and communicates with a second user terminal 812 through the satellite system 800 and terrestrial network.
  • the satellite system may have one or more satellites shown here as satellite 816A and 816B and collectively referred to as satellites 816.
  • the first user terminal 810 connects via a user link 814 to a first satellite 816A.
  • the first satellite 816A communicates with a first satellite gateway 820 over a link 818.
  • the first satellite gateway 820 sends data through a terrestrial network to a second satellite gateway 826.
  • the first satellite gateway 820 communicates with a 5G core network 822 to the internet 824.
  • Data is sent over the internet 824 through the 5G core network 822 to the second satellite gateway 826.
  • the second satellite gateway 826 send the data over a second link 828 to satellite 816B.
  • the second satellite 816B then sends the data to the second user terminal (UT-2) 812 over a user link 832.
  • the user links 832, 814 may be similar to user links 132, 136 as described above with reference to FIG. 1.
  • the satellites 816A, 816B may be the same satellite or different satellites in either an LEO or MEO constellation but not both.
  • packets originating from a first user terminal (UT-1) under one satellite are brought down to a corresponding gateway on the ground and routed on terrestrial links to a second gateway under a satellite (the same satellite or a different satellite in the same or a different constellation) that is connected to a second user terminal (UT-2).
  • Traditional non-geostationary constellations are either at LEO or MEO.
  • LEO and MEO constellations can have intra-constellation optical or RF cross-links.
  • the described implementations herein provide interconnected LEO and MEO satellites with cross-links not just within a constellation but also between LEO and MEO constellations. LEO and MEO constellations can advantageously be using different frequency bands in user links.
  • Ku band for LEO and Ka band for MEO For example, Ku band for LEO and Ka band for MEO.
  • a given user terminal may be capable of Ku only, Ka only or both Ku and Ka.
  • two user terminals may directly communicate with each other regardless of their band capabilities. Direct communication between two user terminals without touching the ground has the significant advantage of providing the highest security.
  • packets originating from a first UT under one constellation can be routed to a second UT under a different constellation entirely in the constellation without being routed on any terrestrial networks.
  • FIGs. 9 and 10 illustrate two examples for data connectivity between user terminals without traversing terrestrial links.
  • Many entities such as governments, businesses, or other enterprises may benefit from a point-to-point secure data link.
  • a data link that does not traverse terrestrial data links reduces exposure to security risks of terrestrial links that are not controlled by the entity.
  • FIG. 9 presents a first example of point-to-point connectivity between user terminals without traversing terrestrial links.
  • a first user terminal (UT-1) 910 connects to and communicates with a second user terminal (UT-2) 912 through the MEO-LEO system 100.
  • the user terminals 910, 912 may be physically located at virtually any point on the surface of the Earth.
  • the first user terminal 910 connects via a user link 914 to a LEO satellite 916.
  • the user link 914 may be similar to user links 132, 136 as described above with reference to FIG. 1.
  • the LEO satellite 916 is a satellite in the LEO constellation 112.
  • the LEO satellite 916 communicates over a MEO-LEO link 918 with a MEO satellite 920 in the MEO constellation 110.
  • the MEO satellite 920 communicates over a MEO link 922 to a second MEO satellite 924.
  • the second MEO satellite 924 communicates over another MEO-LEO link 926 to a LEO satellite 928.
  • the LEO satellite 928 the communicates over a user link 930 with the second user terminal 912.
  • the first MEO satellite 920 may communicate directly with the LEO satellite 928, thus not needing the MEO link 922.
  • FIG. 10 is a diagram showing a second scenario for connectivity between user terminals.
  • a first user terminal (UT-1) 1010 connects to and communicates with a second user terminal (UT-2) 1012 through the MEO-LEO system 100.
  • the user terminals 1010, 1012 may be physically located at virtually any point on the surface of the Earth.
  • the first user terminal 1010 connects via a user link 1014 to a LEO satellite 1016.
  • the user link may be user links 132, 136 as described with reference to FIG. 1.
  • the LEO satellite 1016 is a satellite in the LEO constellation 112.
  • the LEO satellite 1016 communicates over a MEO- LEO link 1018 with a MEO satellite 1020 in the MEO constellation 110.
  • the MEO satellite 1020 communicates over a MEO link 1022 to a second MEO satellite 1024.
  • the second MEO satellite 1024 communicates over a user link 1026 with the second user terminal 1012.
  • the MEO-LEO system architecture lends itself to providing high availability and secure communication between two points on the earth without traversing terrestrial links.
  • Software Defined Networking (SDN) based routing will allow appropriate routing via the MEO-LEO constellation to reach the intended destination. It is noted that the data path between two user devices does not go through a gateway link and therefore does not traverse any terrestrial link or facility.
  • SDN Software Defined Networking
  • the illustration shows communication between two entities that are both Ku-band terminals, it is also possible for this type of secure connectivity between a Ku-band and Ka-band terminal. In such a case, the Ka link will be with MEO and Ku link will be with LEO.
  • a route determination algorithm can determine the most optimal route via intra- and/or inter-constellation links.
  • FIG. 11 illustrates an implementation of IP routing in a satellite system for secure UT to UT communication.
  • FIG. 11 shows the data plane routing of the UT-UT communication.
  • a first user terminal UT-1 1110 is connected to a second user terminal UT-2 1112 via a LEO-MEO constellation 1114 comprising an LEO satellite 1116 and an MEO satellite 1118.
  • the first user terminal UT-1 1110 includes a representation of the user plane protocol stack.
  • the user plane protocol stack includes from top to bottom, an application block 1120, a transmission control protocol/user datagram protocol (TCP/UDP) block 1122, an internet protocol (IP) block 1124, a service data adaption protocol/packet data convergence protocol block (SDAP/PDCP) block 1126, a radio link control (RLC) block 1128, a medium access control (MAC) block 1130 and a physical layer (PHY) block 1132.
  • the second user terminal 1112 includes the same user plane protocol stack with these same blocks. Each of these blocks may function as known in the prior art.
  • the LEO satellite 1116 also includes a representation of the user plane protocol stack.
  • the user plane protocol stack in the LEO satellite 1116 includes an internet protocol (IP) block 1134, a radio link control (RLC) block 1136, a medium access control (MAC) block 1138 and a physical layer (PHY) block 1140, a layer 2 (L2) block 1142 and a second physical layer (PHY) block 1144.
  • IP internet protocol
  • RLC radio link control
  • MAC medium access control
  • PHY physical layer
  • L2 layer 2
  • PHY second physical layer
  • the IP routing of UT to UT communication includes various links between the user terminals and the satellites.
  • the PHY layer 1132 of the first user terminal 1110 is connected to the PHY layer 1140 of the LEO satellite 1116 via a user link 1146.
  • the user link 1146 is a Ku band link.
  • the PHY layer 1144 of the LEO satellite 1116 is connected to the PHY layer 1148 of the MEO satellite 1118 via a LEO/MEO optical link 1150 as described above.
  • the PHY layer 1152 of the MEO satellite 1118 is connected to the PHY layer 1154 of the second user terminal 1112 via a second user link 1156.
  • the user link 1156 is a Ka band link.
  • FIG. 12 is a data flow diagram for secure direct UT to UT communication in a satellite system.
  • FIG. 12 illustrates data flow from a first user terminal UT-1 to a second user terminal UT-2.
  • Data passes from UT1 through the network entities as follows: UT-1 - LEO satellite - LEO Gateway - 5G Core Network - Internet - 5G Core Network - MEO gateway - MEO satellite - UT-2.
  • the top portion 1210 of the data flow diagram represents data flow in a satellite system as shown in FIG. 8.
  • encrypted data 1212 flowing from UT1 to UT2 undergoes encryption and decryption at each segment of the data path as shown.
  • the bottom portion 1214 of the data flow diagram represents direct UT-UT secure data flow in a satellite system as shown in FIGs. 9 and 10.
  • encrypted data 1216 flowing from UT-1 to UT-2 undergoes encryption at UT-1 and decryption at UT-2.
  • the encrypted data 1216 flowing from UT-1 to UT-2 is secured using a private key which protects the data throughout the entire data route.
  • FIG. 13A illustrates an implementation of IP routing in a satellite system for secure UT to UT communication.
  • FIG. 13 shows the control plane routing of the UT-UT communication for a system similar to that of FIG. 11.
  • a first user terminal UT-1 1110 is connected to a second user terminal UT-2 1112 via a LEO-MEO constellation 1114 comprising an LEO satellite 1116 and an MEO satellite 1118.
  • the first user terminal 1110 includes a representation of the control plane protocol stack.
  • the control plane protocol stack includes from top to bottom, an NAS-MM block 1310, an NAS-MM block 1312, a radio resource control gateway (RRC-G) block 1314, a radio resource control user-user (RRC-UU) block 1316, a radio link control (RLC) block 1318, a medium access control (MAC) block 1320 and a physical layer (PHY) block 1322.
  • the second user terminal 1112 includes the same control plane protocol stack with these same blocks. Each of these blocks, with the exception of RRC-UU 1316, may function as known in the prior art.
  • the LEO satellite 1116 also includes a representation of the control plane protocol stack.
  • the control plane protocol stack in the LEO satellite 1116 includes a relay block 1324, a radio link control (RLC) block 1326, a medium access control (MAC) block 1328 and a physical layer (PHY) block 1330, a L2 block 1332 and a second physical layer (PHY) 1334.
  • the MEO satellite 1118 has the same blocks in its user plane protocol stack.
  • the RRC-UU block 316 allows direct UT-UT control plane communication 1336 between the two user terminals as described further below.
  • An advantage of some implementations herein is direct communication between user terminals as introduced above.
  • a direct connection can be achieved between a first user terminal that can communicate with an LEO satellite and a second user terminal that can communicate with MEO satellite, or other routes through a satellite constellation as described above.
  • a user terminal can initiate direct communication by knowing the IP address of another user terminal.
  • IP packets transmitted by the first user terminal are received by the first satellite, for example an LEO-SAT.
  • the RLC layer in the first user satellite may implement Layer-2 automatic repeat (ARQ) protocols to ensure error free reception of IP packets at the LEO-SAT.
  • Layer-2 ARQ may be selectively applied based on traffic flow characteristics. For example, TCP based traffic flows undergo Layer-2 ARQ.
  • UDP based traffic flows such as conversational voice may not undergo Layer-2 ARQ.
  • the satellite may inspect the destination IP address in a received IP header and consults its routing table to determine the next-hop for this packet. Routing table in each satellite is updated based on link state information in the constellation topology. Traditional method would be for user terminals to advertise its reachability based on the satellite the user terminal is communicating with.
  • a satellite system where the satellites are moving i.e. a satellite constellation with non-geosynchronous satellites such as LEO and MEO satellites
  • user terminals need to update reachability information every time there is a satellite handover at the user terminal. Every time there is a reachability update of the user terminal to a new satellite, all other routers in constellation should update their routing tables to maintain reachability. Updating reachability information upon each handover can add significant signaling overhead in the system. In implementations described below, this signaling overhead can be completely removed where the satellites autonomously update their routing tables without explicit reachability update information.
  • the user terminals can take advantage of satellite handover signaling protocols to piggy-back reachability information to the satellite. However, this method requires updating routing tables in each satellite.
  • Using piggy-back protocols can put a significant demand on system resources due to the size of the routing table in each satellite. As an example, if there are hundreds of thousands of user terminals that wish to be engaged in direct sessions, the size of the routing tables will need to be quite large. In addition to memory requirements, the large routing table creates a demand for quick search over large routing tables.
  • satellite routers don’t have to store and search routing tables that are the size of the user terminal population. Instead, the routing table size is limited to the size of the constellation, namely the number of satellites in the constellation.
  • the first user terminal may be provided with the satellite ID that second user terminal is communicating with at the beginning of the communication session. This can be provided by the gateways.
  • the LEO and MEO gateways are constantly aware of the geo-locations of the individual user terminals that having active communications.
  • a designated server on the ground is aware of the LEO or MEO satellite that the second user terminal is in communication with.
  • the designated server may be one of servers 144 with the data of user terminals which are communicating with a satellite stored in a satellite communication table 154 as shown in FIG. 1.
  • This designated server provides the satellite ID that the second user terminal is communicating with at the beginning of the direct session - for the purposes of this discussion we call this as the egress satellite to reach the second satellite.
  • FIG. 13B illustrates a first example of direct communication between a first user terminal and a second user terminal.
  • the system uses extension IP headers to reduce the complexity and memory load required when using full routing tables as discussed above.
  • Each IP data packet includes an extension IP header that contains the egress satellite’s ID.
  • Each entity in the system routes the data packet to the next entity based on the extension header of the data packet.
  • Data may be sent through a combination of satellites and gateways to the destination user terminal. For example, data may use the point-to-point connectivity between user terminals without traversing terrestrial links as described with reference to FIG. 8 and FIG. 9.
  • data may flow between user terminals using extension IP headers by passing through a combination of satellites and ground based gateways as shown in FIG. 13B.
  • a first user terminal UT-1 sends an IP packet destined to a second user terminal UT-2.
  • UT-1 may inform UT-2 that it intends to communicate with UT-2 during security establishment handshake (not shown).
  • the data communication using extension IP headers is illustrated as a data flow 1350 from UT-1 to UT-2.
  • Data from UT-1 is first sent to SAT-1 with extension IP headers.
  • SAT-1 receives the data IP packets from UT-1 with an extension header, and simply inspects the egress satellite ID to make a determination where to send the data on the next-hop to reach egress satellite ID.
  • the data flow 1350 continues in this example by SAT-1 sending the data through gateway GW1 to SAT-2.
  • the data flow 1350 continues through SAT-3, SAT-4 and SAT-5 to user terminal UT-2.
  • the data may flow 1350 through other gateways and a software defined (SDN) controller as shown.
  • SDN software defined
  • UT-2 When a user terminal is no longer able to be serviced by a non-stationary satellite, a handover to another satellite takes place as described above.
  • UT-2 when a handover of UT-2 to a different satellite takes place, UT-2 directly informs UT-1 of the new satellite ID which is now handing data traffic of UT-2.
  • UT-1 informs UT-2 about its satellite handover.
  • the extension header is appropriately updated. In this way, the satellites do not need to maintain a large table with IP addresses, they only need to maintain a table to reach a particular satellite in the constellation.
  • FIG. 13B A brief description of a handover is shown in FIG. 13B.
  • the handover may be accomplished with a sequence of handshake signals 1354.
  • a satellite handover 1352 is executed.
  • the handover handshake signals 1354 may end with handover complete signals as shown.
  • the UT-2 sends a handover update to inform UT-1 of the new satellite ID it is communicating with.
  • the handover update is accomplished using RRC-G signaling 1356 to gateway GW2.
  • Router signaling 1360, 1362 can then be used to send the handover update to the next gateway GW1 via the SDN controller.
  • RRC-G signaling 1358 can then be used to forward the handover update from GW1 to UT-1.
  • UT-1 now having new satellite information about UT-2, updates the extension headers in data packets appropriately and again sends data 1364 to UT-2 as described above.
  • This method of direct communication between user terminals eliminates the need for large routing tables. However, this method does require complex signaling via ground elements for the handover updates.
  • FIG. 13C illustrates a second example of direct communication between a first user terminal and a second user terminal.
  • the system uses the RRC-UU 1316 introduced above for direct UT-UT control plane communication 1336 between the two user terminals.
  • data flows 1350 from UT-1 to UT-2, and a handover is handled 1354 as described above.
  • UT-2 communicates with UT-1 using RRC-UU layer protocol signaling 1366 to send UT-1 the new egress satellite ID used by UT-2.
  • the RRC-UU layer protocol signaling 1366 uses the RRC- UU 1316 in the protocol stack of the user terminals as described above.
  • UT-1 then uses the received information to update the egress router ID in the extension header for subsequent data sent 1364 to UT-2.
  • Data is sent 1364 as described above where all satellites in the constellation only need to inspect the destination IP address in the extension header to route the packets to the correct egress router. Therefore, there is no need for routers to update their routing tables when a UT executes a satellite handover since it is the responsibility of UT to update the extension header. Further, since it is the user terminal’s responsibility to populate the correct egress satellite ID in extension headers, the other satellites need not store information about individual user terminals.
  • the egress satellite must still determine the beam within the satellite where the user terminal can be reached.
  • Each satellite maintains a list of active user terminals in each beam as part of normal radio resource function. Therefore, when a packet is received at the egress satellite, the satellite is aware of which beam the UT is located.
  • Previous discussions were centered around constellation routing based on satellites inspecting destination IP address and extension headers. This implies that satellites have to implement IP layer and corresponding header checksum etc. This complexity can be eliminated taking advantage of the extension IP header concept discussed under IP Routing.
  • the user terminal inserts an extension L2-header or a label that contains the egress satellite information rather than extension IP header.
  • the first L2 frame of a given IP packet contains the extension L2 header.
  • the satellite does not need to implement IP layer.
  • the RLC layer completes the re-assembly, it simply inspects the extension L2 -header of the first frame to route to egress satellite. This leads to a reduced complexity satellite implementation.
  • Implementations described above provide efficient techniques to establish direct UT-UT connection via LEO-LEO or LEO-MEO links.
  • the packets originate in one user terminal and reaches the destination UT without traversing through a ground network.
  • it may be required to know the volume of data (not the actual data itself) transferred during the direct UT-UT connection. For example, billing may require a determination of the volume of data sent. Another reason may be for traffic engineering.
  • this volume is easily determined by the 5G Core Network elements since all packets pass through the 5G Core.
  • packets may not pass through the 5G core network elements.
  • the ingress satellite may simply replicate IP packets (or altered IP packets) towards the ground (and hence 5G core network); but destroy the content of the IP packet so that it makes no sense to a listener on the ground infrastructure.
  • the 5G core network would simply compute volume based on these modified IP packets.
  • this method consumes resources on the satellite as well as bandwidth.
  • the ingress satellite does the volume accounting and simply sends one message to an accounting server on ground when a UT hands over to a different satellite. This method does require an application layer implementation in the satellite, but it does not consume as much satellite resources or spectrum.
  • references to displaying or presenting an item include issuing instructions, commands, and/or signals causing, or reasonably expected to cause, a device or system to display or present the item.
  • various features described in FIGS. 1-13 are implemented in respective modules, which may also be referred to as, and/or include, logic, components, units, and/or mechanisms. Modules may constitute either software modules (for example, code embodied on a machine-readable medium) or hardware modules.
  • a hardware module may be implemented mechanically, electronically, or with any suitable combination thereof.
  • a hardware module may include dedicated circuitry or logic that is configured to perform certain operations.
  • a hardware module may include a special-purpose processor, such as a field- programmable gate array (FPGA) or an Application Specific Integrated Circuit (ASIC).
  • a hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations and may include a portion of machine- readable medium data and/or instructions for such configuration.
  • a hardware module may include software encompassed within a programmable processor configured to execute a set of software instructions. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (for example, configured by software) may be driven by cost, time, support, and engineering considerations.
  • hardware module should be understood to encompass a tangible entity capable of performing certain operations and may be configured or arranged in a certain physical manner, be that an entity that is physically constructed, permanently configured (for example, hardwired), and/or temporarily configured (for example, programmed) to operate in a certain manner or to perform certain operations described herein.
  • “hardware-implemented module” refers to a hardware module. Considering examples in which hardware modules are temporarily configured (for example, programmed), each of the hardware modules need not be configured or instantiated at any one instance in time.
  • a hardware module includes a programmable processor configured by software to become a special-purpose processor
  • the programmable processor may be configured as respectively different special-purpose processors (for example, including different hardware modules) at different times.
  • Software may accordingly configure a processor or processors, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
  • a hardware module implemented using one or more processors may be referred to as being “processor implemented” or “computer implemented.”
  • Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled.
  • communications may be achieved through signal transmission (for example, over appropriate circuits and buses) between or among two or more of the hardware modules.
  • communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory devices to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output in a memory device, and another hardware module may then access the memory device to retrieve and process the stored output.
  • At least some of the operations of a method may be performed by one or more processors or processor-implemented modules.
  • the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS).
  • SaaS software as a service
  • at least some of the operations may be performed by, and/or among, multiple computers (as examples of machines including processors), with these operations being accessible via a network (for example, the Internet) and/or via one or more software interfaces (for example, an application program interface (API)).
  • the performance of certain of the operations may be distributed among the processors, not only residing within a single machine, but deployed across several machines.
  • Processors or processor-implemented modules may be in a single geographic location (for example, within a home or office environment, or a server farm), or may be distributed across multiple geographic locations.
  • FIG. 14 is a block diagram 1400 illustrating an example software architecture 1402, various portions of which may be used in conjunction with various hardware architectures herein described, which may implement any of the above-described features.
  • FIG. 14 is a non-limiting example of a software architecture and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein.
  • the software architecture 1402 may execute on hardware such as a machine 1500 of FIG. 15 that includes, among other things, processors 1510, memory 1530, and input/output (I/O) components 1550.
  • a representative hardware layer 1404 is illustrated and can represent, for example, the machine 1500 of FIG. 15.
  • the representative hardware layer 1404 includes a processing unit 1406 and associated executable instructions 1408.
  • the executable instructions 1408 represent executable instructions of the software architecture 1402, including implementation of the methods, modules and so forth described herein.
  • the hardware layer 1404 also includes a memory /storage 1410, which also includes the executable instructions 1408 and accompanying data.
  • the hardware layer 1404 may also include other hardware modules 1412. Instructions 1408 held by processing unit 1408 may be portions of instructions 1408 held by the memory/storage 1410.
  • the example software architecture 1402 may be conceptualized as layers, each providing various functionality.
  • the software architecture 1402 may include layers and components such as an operating system (OS) 1414, libraries 1416, frameworks 1418, applications 1420, and a presentation layer 1444.
  • OS operating system
  • the applications 1420 and/or other components within the layers may invoke API calls 1424 to other layers and receive corresponding results 1426.
  • the layers illustrated are representative in nature and other software architectures may include additional or different layers. For example, some mobile or special purpose operating systems may not provide the frameworks/middleware 1418.
  • the OS 1414 may manage hardware resources and provide common services.
  • the OS 1414 may include, for example, a kernel 1428, services 1430, and drivers 1432.
  • the kernel 1428 may act as an abstraction layer between the hardware layer 1404 and other software layers.
  • the kernel 1428 may be responsible for memory management, processor management (for example, scheduling), component management, networking, security settings, and so on.
  • the services 1430 may provide other common services for the other software layers.
  • the drivers 1432 may be responsible for controlling or interfacing with the underlying hardware layer 1404.
  • the drivers 1432 may include display drivers, camera drivers, memory/storage drivers, peripheral device drivers (for example, via Universal Serial Bus (USB)), network and/or wireless communication drivers, audio drivers, and so forth depending on the hardware and/or software configuration.
  • USB Universal Serial Bus
  • the libraries 1416 may provide a common infrastructure that may be used by the applications 1420 and/or other components and/or layers.
  • the libraries 1416 typically provide functionality for use by other software modules to perform tasks, rather than rather than interacting directly with the OS 1414.
  • the libraries 1416 may include system libraries 1434 (for example, C standard library) that may provide functions such as memory allocation, string manipulation, file operations.
  • the libraries 1416 may include API libraries 1436 such as media libraries (for example, supporting presentation and manipulation of image, sound, and/or video data formats), graphics libraries (for example, an OpenGL library for rendering 2D and 3D graphics on a display), database libraries (for example, SQLite or other relational database functions), and web libraries (for example, WebKit that may provide web browsing functionality).
  • the libraries 1416 may also include a wide variety of other libraries 1438 to provide many functions for applications 1420 and other software modules.
  • the frameworks 1418 provide a higher-level common infrastructure that may be used by the applications 1420 and/or other software modules.
  • the frameworks 1418 may provide various graphic user interface (GUI) functions, high-level resource management, or high-level location services.
  • GUI graphic user interface
  • the frameworks 1418 may provide a broad spectrum of other APIs for applications 1420 and/or other software modules.
  • the applications 1420 include built-in applications 1440 and/or third-party applications 1442.
  • built-in applications 1440 may include, but are not limited to, a contacts application, a browser application, a location application, a media application, a messaging application, and/or a game application.
  • Third-party applications 1442 may include any applications developed by an entity other than the vendor of the particular platform.
  • the applications 1420 may use functions available via OS 1414, libraries 1416, frameworks 1418, and presentation layer 1444 to create user interfaces to interact with users.
  • Some software architectures use virtual machines, as illustrated by a virtual machine 1448.
  • the virtual machine 1448 provides an execution environment where applications/modules can execute as if they were executing on a hardware machine (such as the machine 1500 of FIG. 15, for example).
  • the virtual machine 1448 may be hosted by a host OS (for example, OS 1414) or hypervisor, and may have a virtual machine monitor 1446 which manages operation of the virtual machine 1448 and interoperation with the host operating system.
  • a software architecture which may be different from software architecture 1402 outside of the virtual machine, executes within the virtual machine 1448 such as an OS 1414, libraries 1472, frameworks 1454, applications 1456, and/or a presentation layer 1458. [0075] FIG.
  • FIG. 15 is a block diagram illustrating components of an example machine 1500 configured to read instructions from a machine-readable medium (for example, a machine- readable storage medium) and perform any of the features described herein.
  • the example machine 1500 is in a form of a computer system, within which instructions 1516 (for example, in the form of software components) for causing the machine 1500 to perform any of the features described herein may be executed.
  • the instructions 1516 may be used to implement modules or components described herein.
  • the instructions 1516 cause unprogrammed and/or unconfigured machine 1500 to operate as a particular machine configured to carry out the described features.
  • the machine 1500 may be configured to operate as a standalone device or may be coupled (for example, networked) to other machines.
  • the machine 1500 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment.
  • Machine 1500 may be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and/or entertainment system, a smart phone, a mobile device, a wearable device (for example, a smart watch), and an Internet of Things (loT) device.
  • PC personal computer
  • STB set-top box
  • STB set-top box
  • STB set-top box
  • smart phone smart phone
  • mobile device for example, a smart watch
  • wearable device for example, a smart watch
  • an Internet of Things (loT) device an Internet of Things
  • the machine 1500 may include processors 1510, memory 1530, and I/O components 1550, which may be communicatively coupled via, for example, a bus 1502.
  • the bus 1502 may include multiple buses coupling various elements of machine 1500 via various bus technologies and protocols.
  • the processors 1510 including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereol
  • the processors 1510 may include one or more processors 1512a to 1512n that may execute the instructions 1516 and process data.
  • one or more processors 1510 may execute instructions provided or identified by one or more other processors 1510.
  • processor includes a multi-core processor including cores that may execute instructions contemporaneously.
  • FIG. 15 shows multiple processors, the machine 1500 may include a single processor with a single core, a single processor with multiple cores (for example, a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof.
  • the machine 1500 may include multiple processors distributed among multiple machines.
  • the memory /storage 1530 may include a main memory 1532, a static memory 1534, or other memory, and a storage unit 1536, both accessible to the processors 1510 such as via the bus 1502.
  • the storage unit 1536 and memory 1532, 1534 store instructions 1516 embodying any one or more of the functions described herein.
  • the memory/storage 1530 may also store temporary, intermediate, and/or long-term data for processors 1510.
  • the instructions 1516 may also reside, completely or partially, within the memory 1532, 1534, within the storage unit 1536, within at least one of the processors 1510 (for example, within a command buffer or cache memory), within memory at least one of I/O components 1550, or any suitable combination thereof, during execution thereof. Accordingly, the memory 1532, 1534, the storage unit 1536, memory in processors 1510, and memory in I/O components 1550 are examples of machine-readable media.
  • machine-readable medium refers to a device able to temporarily or permanently store instructions and data that cause machine 1500 to operate in a specific fashion, and may include, but is not limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical storage media, magnetic storage media and devices, cache memory, network-accessible or cloud storage, other types of storage and/or any suitable combination thereof.
  • RAM random-access memory
  • ROM read-only memory
  • buffer memory flash memory
  • optical storage media magnetic storage media and devices
  • cache memory network-accessible or cloud storage
  • machine-readable medium refers to a single medium, or combination of multiple media, used to store instructions (for example, instructions 1516) for execution by a machine 1500 such that the instructions, when executed by one or more processors 1510 of the machine 1500, cause the machine 1500 to perform and one or more of the features described herein.
  • a “machine-readable medium” may refer to a single storage device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices.
  • the I/O components 1550 may include a wide variety of hardware components adapted to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on.
  • the specific I/O components 1550 included in a particular machine will depend on the type and/or function of the machine. For example, mobile devices such as mobile phones may include a touch input device, whereas a headless server or loT device may not include such a touch input device.
  • the particular examples of I/O components illustrated in FIG. 15 are in no way limiting, and other types of components may be included in machine 1500.
  • the grouping of I/O components 1550 are merely for simplifying this discussion, and the grouping is in no way limiting.
  • the I/O components 1550 may include user output components 1552 and user input components 1554.
  • User output components 1552 may include, for example, display components for displaying information (for example, a liquid crystal display (LCD) or a projector), acoustic components (for example, speakers), haptic components (for example, a vibratory motor or force-feedback device), and/or other signal generators.
  • display components for displaying information for example, a liquid crystal display (LCD) or a projector
  • acoustic components for example, speakers
  • haptic components for example, a vibratory motor or force-feedback device
  • User input components 1554 may include, for example, alphanumeric input components (for example, a keyboard or a touch screen), pointing components (for example, a mouse device, a touchpad, or another pointing instrument), and/or tactile input components (for example, a physical button or a touch screen that provides location and/or force of touches or touch gestures) configured for receiving various user inputs, such as user commands and/or selections.
  • alphanumeric input components for example, a keyboard or a touch screen
  • pointing components for example, a mouse device, a touchpad, or another pointing instrument
  • tactile input components for example, a physical button or a touch screen that provides location and/or force of touches or touch gestures
  • the I/O components 1550 may include biometric components 1556, motion components 1558, environmental components 1560, and/or position components 1562, among a wide array of other physical sensor components.
  • the biometric components 1556 may include, for example, components to detect body expressions (for example, facial expressions, vocal expressions, hand or body gestures, or eye tracking), measure biosignals (for example, heart rate or brain waves), and identify a person (for example, via voice-, retina-, fingerprint-, and/or facial-based identification).
  • the motion components 1558 may include, for example, acceleration sensors (for example, an accelerometer) and rotation sensors (for example, a gyroscope).
  • the environmental components 1560 may include, for example, illumination sensors, temperature sensors, humidity sensors, pressure sensors (for example, a barometer), acoustic sensors (for example, a microphone used to detect ambient noise), proximity sensors (for example, infrared sensing of nearby objects), and/or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment.
  • the position components 1562 may include, for example, location sensors (for example, a Global Position System (GPS) receiver), altitude sensors (for example, an air pressure sensor from which altitude may be derived), and/or orientation sensors (for example, magnetometers).
  • GPS Global Position System
  • the I/O components 1550 may include communication components 1564, implementing a wide variety of technologies operable to couple the machine 1500 to network(s) 1570 and/or device(s) 1580 via respective communicative couplings 1572 and 1582.
  • the communication components 1564 may include one or more network interface components or other suitable devices to interface with the network(s) 1570.
  • the communication components 1564 may include, for example, components adapted to provide wired communication, wireless communication, cellular communication, Near Field Communication (NFC), Bluetooth communication, Wi-Fi, and/or communication via other modalities.
  • the device(s) 1580 may include other machines or various peripheral devices (for example, coupled via USB).
  • the communication components 1564 may detect identifiers or include components adapted to detect identifiers.
  • the communication components 1564 may include Radio Frequency Identification (RFID) tag readers, NFC detectors, optical sensors (for example, one- or multi-dimensional bar codes, or other optical codes), and/or acoustic detectors (for example, microphones to identify tagged audio signals).
  • RFID Radio Frequency Identification
  • NFC detectors for example, one- or multi-dimensional bar codes, or other optical codes
  • acoustic detectors for example, microphones to identify tagged audio signals.
  • location information may be determined based on information from the communication components 1562, such as, but not limited to, geo-location via Internet Protocol (IP) address, location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and/or signal triangulation.
  • IP Internet Protocol

Landscapes

  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Electromagnetism (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Radio Relay Systems (AREA)

Abstract

L'invention concerne un système de communication par satellite qui combine les avantages d'un système satellite en orbite terrestre moyenne (MEO) et en orbite terrestre basse (LEO) dans un système satellite MEO-LEO. Le système MEO-LEO comprend une constellation LEO combinée à une constellation MEO où la constellation LEO peut fournir une couverture globale avec une large capacité moyenne et peut prendre en charge une couverture de "zone sensible" selon les besoins. La constellation MEO peut fournir des avantages uniques comprenant la liaison terrestre au sol dans des zones distantes, une densité de trafic supérieure pour des emplacements clés, et une liaison terrestre mondiale sécurisée pour des clients clés. Des données peuvent être acheminées sur des liaisons inter-satellites optiques à l'aide de concepts de mise en réseau définis par logiciel pour fournir un accès MEO-LEO (liaison terrestre et accès au sol), LEO-LEO (en amont et en aval) ; et (3) MEO-MEO (interliaisons et liaisons descendantes). En outre, des modes de réalisation de la présente invention comprennent un terminal utilisateur (UT) sécurisé à un routage IP UT dans la constellation pour une communication UT à UT directe.
PCT/US2022/040098 2021-08-16 2022-08-11 Système de communication par satellite meo-leo intégré WO2023022920A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA3227920A CA3227920A1 (fr) 2021-08-16 2022-08-11 Systeme de communication par satellite meo-leo integre
EP22765312.8A EP4388677A1 (fr) 2021-08-16 2022-08-11 Système de communication par satellite meo-leo intégré

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202163233738P 2021-08-16 2021-08-16
US63/233,738 2021-08-16
US17/535,823 2021-11-26
US17/535,823 US11916654B2 (en) 2021-08-16 2021-11-26 Integrated MEO-LEO satellite communication system

Publications (1)

Publication Number Publication Date
WO2023022920A1 true WO2023022920A1 (fr) 2023-02-23

Family

ID=83193282

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/040098 WO2023022920A1 (fr) 2021-08-16 2022-08-11 Système de communication par satellite meo-leo intégré

Country Status (1)

Country Link
WO (1) WO2023022920A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210092640A1 (en) * 2019-09-23 2021-03-25 Hughes Network Systems, Llc Next generation global satellite system with mega-constellations

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210092640A1 (en) * 2019-09-23 2021-03-25 Hughes Network Systems, Llc Next generation global satellite system with mega-constellations

Similar Documents

Publication Publication Date Title
US11677461B2 (en) Resource allocation for application deployment to satellite-linked communication nodes
US20230075345A1 (en) Interference mitigation across multiple constellations in a satellite communication system
MXPA06006441A (es) Integracion de una red celular inalambrica aerea con redes celulares inalambricas terrestres y la red de telefonia conmutada publica.
US10948603B2 (en) Real-time communication between satellites and mobile devices
US11271638B2 (en) Satellite system including backhaul connection of data centers to gateways
US10797785B1 (en) Real-time communication between satellites and mobile devices
US11799543B2 (en) Community broadband LTE access over satellite
US11916654B2 (en) Integrated MEO-LEO satellite communication system
WO2023022920A1 (fr) Système de communication par satellite meo-leo intégré
US12021602B2 (en) Satellite communication system with software defined network orchestration
US20240250899A1 (en) Software defined networking with differentiated quality of service in a satellite communication system
WO2023022921A1 (fr) Système de communication par satellite comportant une orchestration de réseau définie par logiciel
EP4388676A1 (fr) Amélioration de couche mac pour interface radio dans un système de communication par satellite
US11963059B2 (en) Non-geostationary orbit (NGSO) and geostationary orbit (GEO) hybrid network for uninterrupted communications
US20230052001A1 (en) Smooth transitioning between generations of systems and devices in a satellite system
US20240223269A1 (en) Space communication protocols
US12126429B2 (en) Wireless communication link management for applications deployed to communication nodes
US20230344764A1 (en) Cost-effective control of multiple transports of an sd-wan gateway
US20240048470A1 (en) Network Performance Monitoring Devices
WO2023022929A1 (fr) Transition douce entre des générations de systèmes et de dispositifs dans un système satellite
US20240049012A1 (en) Systems and Methods for Network Performance Monitoring
CN111628813A (zh) 移动卫星通信网关和用于建立卫星通信连接的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22765312

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 3227920

Country of ref document: CA

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112024002875

Country of ref document: BR

WWE Wipo information: entry into national phase

Ref document number: 2022765312

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022765312

Country of ref document: EP

Effective date: 20240318

ENP Entry into the national phase

Ref document number: 112024002875

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20240214