Patent Application
20250240087
Wireless connectivity continues to evolve to meet demands for ubiquity, convenience, reliability, speed, responsiveness, and the like. For example, each new generation of cellular communication standards, such as the move from 4G/LTE (fourth generation long-term evolution) networks to 5G (fifth generation) networks, has provided a huge leap in capabilities along with new and increasing demands on the infrastructures that enable those networks to operate. For example, 5G supports innovations, such as millimeter-wave frequencies, massive MIMO (Multiple Input Multiple Output), and network slicing, which enhance connectivity for unprecedented numbers of devices and data-intensive applications.
More recently, innovations in 5G networking (and its successors) have expanded from terrestrial-based communication infrastructures to so-called non-terrestrial network (NTN) infrastructures. NTN infrastructures leverage satellites and high-altitude platforms to extend 5G coverage and capabilities, such as to serve remote and otherwise underserved areas. Effective deployment of NTN solutions can help support connectivity and applications for rural users, emergency responders, global Internet-of-Things (IoT) deployments, etc.
However, non-terrestrial communications carry complexities and design concerns that are not present in terrestrial-based communications, which can add significant technical hurdles to NTN deployments. For example, effective ground-to-satellite communications involves accounting for orbital dynamics, handovers and/or other transitions between satellites, path loss, propagation delay, atmospheric conditions, inter-satellite and/or inter-beam interference, spectrum and regulatory considerations, and other considerations. New approaches continue to be developed to find technical solutions for overcoming, or at least mitigating, these and other technical hurdles.
Systems and methods are described herein for implementing beam hopping (BH) in an integrated terrestrial-non-terrestrial network (iTNTN). The iTNTN can include a satellite radio access network (SRAN) in communication with a multi-beam satellite communication system (e.g., including one or more non-geostationary orbit (NGSO) satellites and/or one or more geosynchronous Earth orbit (GEO) satellites). The SRAN can utilize cellular (e.g., 5G) standards and protocols. Embodiments generate a macro-level BH configuration generated, based on present network data and on a projected demand for satellite resources, that defines at least traffic and acquisition cycle durations and traffic and acquisition dwell resolutions for traffic channel and acquisition channel BH cycles. The cycles can be generated so that each acquisition time slot has a duration that is a multiple of that of the traffic time slots. The macro-level BH configuration can further define a PNT channel BH cycle with its own time slots and duration.
Embodiments can use the macro-level BH configuration and present network data to further generate corresponding micro-level BH configurations that defines, for each beam of the multi-beam satellite communication system, a first set of dwell time slots to use for cell acquisition by the beam and a second set of dwell time slots to use for traffic and control (TnC) communications. The second set of dwell time slots forms traffic channel BH cycles and can be allocated to cells supported by the beam in proportion to the traffic demands of those cells. Embodiments use the generated cycles to implement concurrent beam hopping of multiple TnC beams and a single PNT beam, thereby efficiently multiplexing traffic, control, and PNT communications.
A further understanding of the nature and advantages of various embodiments may be realized by reference to the following figures. In the appended figures, similar components or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
For the sake of providing context for embodiments described herein,
The network architecture 100 may include one or more user terminals in designated cells 102 illuminated by a satellite network 104 including a plurality of satellites (104-1, 104-2, 104-3 . . . 104-N) communicatively coupled with a ground network. The ground network includes a satellite radio access network (RAN, SRAN) and a core network (CN) in communication via an anchor node 112 (also referred to herein as an anchor processor, AxP). The SRAN can include one or more satellite network nodes (SNNs) 106 (also referred to as SNN sites herein), such as SNN-A 106-1 and SNN-B 106-2; a global network operations center (GNOC) 108; and a global resource manager (GRM) 110. The CN can include an access and mobility function (AMF) module 114, one or more user plane function (UPF) modules 116, a session management function (SMF) 120, and a multicast gateway (MCG) 122. For example, a first UPF 116-1 is in a first country, and a second UPF 116-2 is in a second country.
The illustrated SNNs 106 can be implemented by Ground System Node-Bs (GSNBs), or any suitable network component for facilitating communications and data exchange between the satellites of the satellite network 104 and the ground network infrastructure. For example, the SNNs implement functions relating to relaying data between the satellite network 104 and the ground network, including managing uplink and downlink communications. The SNNs 106 can also help to ensure compatibility between satellite communication protocols and terrestrial network protocols.
User terminals in the cells 102 communicate with the ground network through the satellite network 104. At any given instant of time, the user terminals may communicate on a Ku user link of a satellite and the ground network/node may communicate on Ka/V/Q feeder link of a satellite in the satellite network 104. Other implementations can use any feasible spectrum bands for communications.
As illustrated, the satellites of the satellite network 104 can be implemented as a constellation of satellites. The satellite (for example, SAT3 104-3) with which the ground network/node communicates may be different from the satellite (for example, SAT1 104-1) with which the user terminal (controlled by that ground node) may be communicating. For example, the user terminals are communicating with the SAT1 104-1 to reach the ground node (for example, SNN-A 106-1 or SNN-B 106-2) that is communicating with the SAT3 104-3. Inter-satellite links (ISLs) may be used to establish connectivity between the satellites (104-1, 104-2, 104-3 . . . 104-N) in the satellite network 104. In an example, a lightweight software defined satellite networking concept may be used to find the best route between two satellites in the satellite network 104.
The SNN-A 106-1 and the SNN-B 106-2 may communicate with the SAT3 104-3 through active feeder links, such as the two active feeder links shown in
A person of ordinary skill in the art will understand that there may be any number of user terminals, satellites, or other components in the network architecture 100. As used herein, the user terminal may refer to a wireless device and/or a user equipment (UE). The terms “computing device,” “wireless device,” “user device,” and “user equipment (UE)” may be used interchangeably throughout the disclosure. A user device or the UE may include, but not be limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, etc.
In an example, the user devices may communicate with the satellite network 104 and/or the ground network and/or the core network via a set of executable instructions residing on any operating system. In an example, the user devices may include, but are not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the user device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen, etc. A person of ordinary skill in the art will appreciate that the user devices may not be restricted to the mentioned devices and various other devices may be used.
The satellite network 104 may be communicatively coupled to the user devices in the cell 102 via a network. The satellite network 104 may communicate with the user devices in a secure manner via the network. The network may include, by way of example, but not limited to, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, some combination thereof, or so forth. The network may also include, by way of example, but not limited to, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiberoptic network, or some combination thereof. In particular, the network may be any network over which the user devices communicate with the satellite network 104.
Although
For added context,
In some implementations, the RAN is architected according to open radio access network (O-RAN) principles and protocols. O-RAN is an architecture that seeks to standardize interfaces between RAN components to allow network operators to mix and match products from different vendors. O-RAN deployments tend to leverage disaggregation, artificial intelligence (AI), machine learning (ML), and/or other technologies for network optimization. For example, embodiments can implement the RU, DU, and CU functions as virtualized network functions (VNFs) with standardized network interfaces. Integration of O-RAN principles into iTNTN deployments can increase flexibility, scalability, and efficiency of the network architecture.
Although 5G NR specifications and technologies discuss many aspects of NTN integration, they do not specify or address satellite beam hopping features. In conventional fixed-beam satellites, one or more coverage areas is statically illuminated by one or more beams, and the resources (e.g., bandwidth and power) of the satellite are allocated to those beams, often uniformly. Thus, it can be difficult or impossible for such fixed-beam satellites to adapt to changing demand for those resources over time and/or over geographic space (e.g., in different regions).
Beam hopping is a technique used in satellite communications to optimize the allocation of those satellite resources across different geographic coverage areas by hopping the beams to different coverage areas (e.g., cells) at different times, thereby providing for dynamic adjustment to resource allocations in time and space. The “hopping” refers to selectively activating beams at different times and locations to direct the satellite resources as desired. Beam hopping involves time-division multiplexing (e.g., time-division multiple access, TDMA) and power allocation to enhance efficiency and flexibility. By concentrating a satellite's power and bandwidth on specific areas at specific times, beam hopping can effectively increase the overall system capacity and quality of service. For example, the ability to dynamically focus resources can increase resource efficiency by directing more resources to higher demand regions as needed, can improve service flexibility by dynamically refocusing resources to adapt to changing demand patterns (e.g., peak usage times in certain regions, emergencies, etc.), can increase system capacity by using dynamic allocation of resources to effectively support more users at higher data rates, can increase energy efficiency (and accordingly increase satellite lifespan and reduce operational costs) by concentrating power on active beams to reduce overall energy consumption, and can provide other features.
The sequence progresses in accordance with arrow 315. According to nomenclature adopted herein, the sequence includes repeating a “beam hopping cycle” that is divided into “dwell time slots.” The beam hopping cycle has a total duration referred to as its “revisit time,” which equals some number of dwell time slots. Each beam 310 in the system can be active at certain dwell time slots in the cycle time and inactive at other dwell time slots in the cycle time, according to a beam hopping schedule. Thus, a single dwell time slot is the shortest possible beam dwell duration, and the revisit time is the longest possible time period between activating a particular beam 310 (i.e., which is also the longest time period before revisiting any particular terminal). If a beam 310 is active for multiple dwell time slots sequentially, the sequence of slots in which the beam 310 is active can be referred to as a “beam dwell duration.” In some embodiments, for each beam hopping cycle, a beam 310 is active for a number of dwell time slots corresponding to the number of UTs supported in the corresponding cell 102. In cases where a particular beam can be active for multiple, non-sequential dwell time slots in a single cycle time, the number of slots in which the beam is active over the cycle time can be referred to as a “beam slot count.”
In the illustrated example, a first cell 102-1 has 1 UT, a second cell 102-2 has 3 UTs, and a third cell 102-3 has 2 UTs. A beam hopping cycle is illustrated as having a revisit time 325 equivalent to 6 dwell time slots 320 (corresponding to the 6 total UTs). For example, the UT in the first cell 102-1 is illuminated once every six dwell time slots 320. A beam hopping cycle is illustrated as beginning at time, t0. The first beam 310-1 is active for a single dwell time slot 320, which is also the minimum beam dwell duration 330. The second beam 310-2 is active for three dwell time slots 320 beginning at time, t1; and the beam 310-2 remains active for a beam dwell duration 330 of three dwell time slots 320. The third beam 310-3 is active for two dwell time slots 320 beginning at time, t4; and the beam 310-3 remains active for a beam dwell duration 330 of two dwell time slots 320. At time, t6 (6 dwell time slots 320 after the beginning of the first beam hopping cycle), the beam hopping cycle repeats.
As noted above, the iTNTN architectures described herein can include one or more non-geostationary orbit (NGSO) satellites and/or one or more geosynchronous Earth orbit (GEO) satellites, integrated with terrestrial radio access and core network infrastructures based on cellular standards (e.g., 5G). For example, the architecture of
In GEO systems, the satellite maintains a fixed position relative to the Earth, which can allow for a consistent overall coverage area of the satellite and/or a static correspondence between a satellite's beams and particular coverage areas where those beams are focused. Beam hopping can be used in GEO systems to dynamically activate and/or point selected beams at selective geographical regions in a manner that adapts to temporal changes in demand. For example, beam hopping can be used to adapt to predictably varying internet traffic throughout a day, to high-viewership events, etc.
To date, beam hopping has not been implemented in the context of iTNTN architectures. Indeed, doing so involves overcoming several technical hurdles. One such hurdle is that implementing beam hopping involves designing sophisticated scheduling algorithms to determine when and where to allocate resources and designing system components to apply those scheduling algorithms in a highly dynamic, but also highly reliable manner. This can be particularly challenging in the context of NGSO systems, as designing such algorithms further involves accounting for satellite movement, constellation dynamics, and/or other technical concerns. Another such hurdle is that dynamically changing beam patterns can lead to interference concerns, and implementing reliable beam hopping can involve designing and implementing techniques for advanced coordination, beamforming, and/or other types of interference mitigation. Another such hurdle is that implementing effective beam hopping can involve accurately forecasting demand to inform beam hopping decisions, including designing in flexibility to respond to incorrect forecasts and/or other changes. Another such hurdle is that implementing beam hopping can involve designing satellites with flexible payload systems capable of rapid reconfiguration and designing ground stations (e.g., gateways) that can manage complex beam hopping communications protocols, schedules, etc.
Embodiments described herein apply beam hopping to the air interface of an iTNTN system, such as a system based around a 5G NR core network. Beam hopping approaches described herein seek to address several technical considerations, such as supporting a large number of cells with a small number of beams with low latency, low synchronization error, high adaptability, and high compatibility with both the NTN air interface and the underlying terrestrial core network. As such, embodiments of beam hopping approaches include features, such as low cycle times, low synchronization error, high granularity with short dwell time slots, and separate treatment of different air interface signal types (including traffic and control signals, acquisition signals, and positioning, navigation, and timing (PNT) signals).
For example, in the forward link, the 5G NR air interface can include several signals. PDSCH (Physical Downlink Shared Channel) is a channel that carries user data and some control information on the forward downlink. PDCCH (Physical Downlink Control Channel) is a channel that carries downlink control information (DCI) (e.g., resource allocation and scheduling decisions) to the UE. PBCH (Physical Broadcast Channel) is a channel that transmits system information necessary for the UE to access and demodulate further information from the network. Each of these channels can carry corresponding DM-RS (Demodulation Reference Signals) that provide channel estimation information to aid in demodulation of the transmitted data on the channel. A PSS (Primary Synchronization Signal) can be used by the UE to achieve frequency synchronization with its cell and to identify a portion of the cell's physical cell identifier. A SSS (Secondary Synchronization Signal) can aid the UE in completing the cell synchronization, including frame synchronization, by providing the remaining portion of the physical cell identifier. PT-RS (Phase Tracking Reference Signals) and/or CSI-RS (Channel State Information-Reference Signals) can also be included. PT-RS can be used to correct and compensate for phase noise in the signal and facilitate accurate phase demodulation, and CSI-RS can be used by the UE to measure the channel quality and facilitate network optimization of transmission parameters. PRS (Positioning Reference Signals) can be used by the UEs to estimate their geographical positions with high accuracy and otherwise to communicate position reference symbols used for the PNT (position, navigation and timing) system. The following table shows the described forward-link signals along with corresponding modulation scheme, forward error correction scheme, and signal type.
In the return link, the 5G NR air interface can include additional signals. PUSCH (Physical Uplink Shared Channel) is a channel that can be used for uplink data transmissions from the UE to the network and can carry user data as well as control information. The PUCCH (Physical Uplink Control Channel) is a channel that can transmit control information from the UE to the network, such as scheduling requests, hybrid automatic repeat request (HARQ) acknowledgments, and channel state information (CSI). Both channels can carry DM-RS for channel estimation and for demodulating the received signals at the base station. The PUSCH can also carry PT-RS (Phase Tracking Reference Signals) which can help compensate for phase noise in the uplink transmission. PRACH (Physical Random Access Channel) is a channel used for initial access attempts from the UE to the network (e.g., when a device needs to establish a connection with the network, such as when it first powers on or moves out of an idle state). The PRACH can carry a PRACH preamble, which is a specific signal pattern sent to initiate the access procedure so that the network can identify the presence of a UE trying to connect and can assist in timing and power level estimation for subsequent communications with the UE. SRS (Sounding Reference Signals) are uplink reference signals used for measuring channel quality (e.g., uplink channel conditions) to facilitate optimizing uplink transmissions (e.g., modulation and coding schemes, power control, scheduling decisions, etc.). There is no PNT in the return direction. The following table shows the described return-link signals along with corresponding subcarrier modulation scheme, forward error correction scheme, and signal type.
In addition to the traffic beam hopping cycles, the illustrated sequence 400 also includes acquisition beam hopping cycles. Each acquisition beam hopping cycle is divided into cell acquisition time slots 420. Each cell acquisition time slot 420 can be a time period allocated for ground terminals (e.g., UTs) to detect, synchronize with, and possibly initiate communication with the satellite. For example, during cell acquisition time slots 420 ground terminals can scan for signals from the satellite to identify the presence of a transmission beam, can synchronize timing and frequency with satellite transmissions, can receive system information from the satellite (e.g., satellite identification, beam scheduling information, access parameters, etc.), can establish user links, etc.
In some embodiments, each cell acquisition time slot 420 is a longer duration than that of the dwell time slots 320. For example, each cell acquisition time slot 420 can be 1 ms, so that each revisit time 325 of the traffic beam hopping cycle corresponds to five cell acquisition time slots 420. In such a case, with 7 cells to acquire, the acquisition can consume 1.4 traffic beam hopping cycles. The total acquisition cycle duration 410 of each acquisition beam hopping cycle can include acquisition of all 329 cells. For embodiments with a 1-ms cell acquisition time slot 420, the acquisition cycle duration 410 is 329 ms. In the illustrated sequence 400, for each beam, the cell acquisition time slots 420 consume 7:329 of the acquisition cycle duration 410, such that the acquisition channel overhead is only around 2.1 percent.
In the illustrated sequence 600, cell acquisition time slots 420 for each beam are staggered over the acquisition beam hopping cycle. For example, the cell acquisition time slots 420 for Beam 2 can begin upon the conclusion of the last cell acquisition time slot 420 for Beam 1, at a first offset time 610-1 after the start of the acquisition beam hopping cycle; and the cell acquisition time slots 420 for Beam N can begin upon the conclusion of the last cell acquisition time slot 420 for Beam N-1, at an (N-1)th offset time 610-(n-1) after the start of the acquisition beam hopping cycle. In such implementations, while any one beam is supporting communications over acquisition channels for cell acquisition, the other N-1 beams are supporting communications over traffic and control channels. Such staggering can reduce concurrent signal power concentration at the satellite's high-power amplifier (HPA) for forward-direction communications. In the return direction, such staggering can reduce RACH hardware resource usage by reducing concurrent RACH access. For example, embodiments can share a single RACH hardware set across all beams (because their use is staggered), rather than having 47 RACH hardware sets (i.e., a dedicated one per beam). Such implementations can thus reduce RACH power and hardware by a factor of 47.
In some embodiments, the MEA of the PNT beam is lower than that of the traffic and control beams. To reliably communicate traffic and control signals, UTs can typically establish a link with only a single satellite at a time. This can allow for a more focused beam design, where beams from different satellites can overlap, and each satellite can manage fewer beams. For example, since each satellite handles fewer beams, the system can use more directed, higher-gain antennas for those beams, which can improve the efficiency and quality of the communication links.
Because of the different operational requirements of PNT beams as compared to traffic and control beams, the same geographic area can be covered by a different number of cells from the perspective of the different types of beams. From the perspective of traffic and control beams, cells are defined by the coverage area of a satellite beam where direct communication is established between the satellite and ground terminals, which can be a geographic area where user terminals can successfully communicate with a single satellite at a time. Such cells can be larger and can overlap, allowing for redundancy and ensuring continuous service as satellites move relative to the Earth's surface. From the perspective of the PNT beam, cells may be defined by geographic areas from which UTs can have simultaneous line-of-sight to multiple satellites. Thus, such cells can be smaller and more granular, and what may be considered a single cell for traffic and control purposes may be subdivided into numerous smaller cells for PNT purposes.
For example, different cell sizes can be used for traffic/control communications and for PNT communications. Embodiments are configured so that the satellite covers more Earth surface area for PNT with lower MEA, as compared to traffic/control. This can allow a UT in a given cell to see multiple satellites at the same time. Accurate position and timing determination can involve the UT receiving signals from least three or four satellite. Use of lower MEA (for a larger satellite coverage) can increase the number of cells (e.g., 2000 cells) that each satellite addresses for PNT purposes, as compared to the number of cells (e.g., 329 cells) that the satellite address for traffic/control purposes. In essence, the satellite footprint for PNT can be larger than that of traffic/control. Challenges in PNT reception at a lower MEA (e.g., a lower SNR and possibly non-line of sight) can be mitigated by allocating higher satellite power for PNT signals and by the use of advanced signal processing at UT receivers.
Some embodiments described herein assume that approximately the geographic area covered by 329 cells for traffic and control purposes is subdivided into 2,000 cells for PNT purposes. This is illustrated in
Combining the sequence of
The exemplary parameter summary table reflects parameter values for some embodiments described herein. Alternative embodiments are possible by reconfiguring the parameter values to account for trade-offs between latency, overhead, and complexity. Some alternative embodiments seek to minimize access delays while keeping overhead ratios the same. Such embodiments can keep the same communication channel beam hopping parameters as in the exemplary parameter summary table but can use shorter acquisition time slots and acquisition cycle durations. One such embodiment uses acquisition time slots of 500 μs and an acquisition cycle duration of 160 μs. Another such embodiment uses acquisition time slots of 250 μs and an acquisition cycle duration of 80 μs. In both of these alternative embodiments, the acquisition overhead remains at approximately 2.1 percent. Other alternative embodiments seek to minimize access delays in exchange for a higher overhead ratio. Such embodiments can keep the same communication channel beam hopping parameters as in the exemplary parameter summary table with the same acquisition time slots, but can use shorter acquisition cycle durations. One such embodiment uses acquisition time slots of 1 ms and an acquisition cycle duration of 160 μs. Another such embodiment uses acquisition time slots of 1 ms and an acquisition cycle duration of 80 μs. These alternative embodiments yield acquisition overheads of approximately 4.2 percent and 8.4 percent, respectively. In other alternative embodiments, longer acquisition time slots can be used to increase the robustness of the acquisition channel by allowing repetition or with more parity bits.
In 5G NR, communications use frame structures that are divided into slots, each occupying a slot duration in the frame structure (i.e., slots re the fundamental unit of time in the frame structure). For example,
The slot and CP durations can vary depending on the numerology (e.g., subcarrier spacing, SCS) used in the network configuration. An example terrestrial core network has a radio frame duration of 10 ms and a sub-frame duration of 1 ms. As the SCS increases, the slot duration and CP duration tend to decrease. For example, an SCS of 15 KHz has a slot duration of 1 ms and a CP duration of 4.7 microseconds (μs), an SCS of 30 KHz has a slot duration of 0.5 ms and a CP duration of 2.3 μs, an SCS of 60 KHz has a slot duration of 250 μs and a CP duration of 1.2 μs, an SCS of 120 KHz has a slot duration of 125 μs and a CP duration of 0.6 μs, and an SCS of 240 KHz has a slot duration of 62.5 μs and a CP duration of 0.3 μs. Because of these different durations, each numerology effectively has a different number of slots in each subframe and a different useful symbol duration. For example, an SCS of 30 KHz has 2 slots per subframe (i.e., two 0.5-ms slots can fit in the 1-ms subframe); and with 14 symbols per slot, each symbol has a useful symbol duration of approximately 33.3 μs (i.e., each can use 1/14 of the 0.5-ms slot less the CP duration). In such an example terrestrial core network (e.g., in 5G NR), user scheduling is performed at a slot granularity (or mini-slot granularity, corresponding to a multiple of symbols). This multiple “numerology” of 5G NR allows the network to flexibly and efficiently support a wide range of services and deployment scenarios.
In some embodiments, dwell time slots are defined to fit with one or more corresponding 5G NR numerologies. One embodiment is configured to be compatible with a 5G NR numerology using a forward-link SCS of 120 KHz and a return-link SCS of 60 KHz, so that there is common slot boundary at 250 μs. In such an embodiment, each dwell time slot is 250 μs, thereby consuming two 5G NR slots in the forward direction and one 5G NR slot in the return direction. Each cycle time can be 5 ms, so that each beam hopping cycle is a pattern of 20 dwell time slots (i.e., 5 ms/250 μs=20), each assigned to a beam.
As noted above, systems can use OFDM, which splits a data signal across multiple closely spaced subcarriers to send bits in parallel, thereby increasing efficiency of wideband digital communications particularly in environments prone to multipath interference. For example, in a satellite communication system, Doppler shifts, signal propagation delays, and other factors can lead to timing offsets, phase errors, and other concerns, which can result in inter-symbol interference (ISI). OFDM schemes can avoid (or mitigate) ISI by inserting a cyclic prefix (CP), which is typically a copy of the end of an OFDM symbol appended to the beginning of that symbol. The CP has a duration longer than the expected maximum delay spread of the channel (i.e., the time difference between the arrival of the fastest and slowest multipath components), such that the CP duration effectively provides a buffer period between symbols. Even if symbols arrive at different times, the information-bearing part of the symbols can be demodulated and decoded correctly at the receiver because the CP duration avoids ISI from adjacent symbols.
The system (e.g. GNOC) can define one or more CP durations. Embodiments of the satellite communication system can be designed to ensure that synchronization-based timing misalignments stay within a minimum CP duration used by the core network, so that receivers can correctly align OFDM symbols for demodulation, avoid data loss, and reduce the impact of ISI. For example, 5G NR specifications define different CP durations for different numerologies. As described above, some embodiments assume a return-link SCS of 60 KHz, which can correspond to a CP duration of approximately 1.2 microseconds. In such embodiments, the system can be designed to keep the synchronization error below one microsecond.
Referring back to
To date, 5G NR specifications support the following three operating frequency ranges (e.g., as defined in Technical Specification 38.104, version 18.50):
The following three tables show transmission channel bandwidths for FR1, FR2-1, and FR2-2, respectively, as supported by present 5G NR specifications (channel bandwidths are shown in MHz, and SCSs are shown in kHz):
The above tables demonstrates that the present 5G NR specification does not presently include the frequency range between 7.125 GHz and 24.25 GHz. Further, the above tables demonstrate that the 5G NR specification presently supports limited transmission channel bandwidths. For example, some satellite communication systems are configured to operate in the Ku-band, which is approximately 10 GHz-14 GHz, and to operate with a channel bandwidth of 250 MHz. Neither is directly supported. Indeed, one approach is to support 250 MHz channel bandwidth using carrier aggregation of supported 200 MHz and 50 MHz channel bandwidths (e.g., in FR2-1). However, such carrier aggregation tends to complicate implementation as well as operation and still does not support operation in Ku-band.
In such an approach, transceivers (i.e., the satellite transmitters and receivers) can be configured as if the channel bandwidth is 400 MHz, but the channel can nonetheless operate with a bandwidth of 250 MHz. For example, a 400 MHz channel with an SCS of 120 kHz can use a 4K IFFT/FFT (inverse fast-Fourier transform/fast-Fourier transform) for OFDM signal generation and reception. Embodiments modify the configuration to produce the 250 MHz pseudo-bandwidth by using only a subset of the 4K IFFT inputs and 4K FFT outputs. At the transmitter side, zeros can be assigned for unused frequency bins corresponding to unused ones of the 4K IFFT inputs. At the receiver side, either unused frequency bins from the 4K FFT outputs can be discarded, or unused frequency bins from the 4K FFT outputs can be used for adjacent channel interference cancellation schemes.
The beam hopping features described above can be performed using any feasible iTNTN architecture, such as those described above with reference to
Embodiments of the resource manager 1015 in the GNOC 1010 can generally be responsible for macro-level and non-real-time features supporting beam hopping approaches described herein. For example, the resource manager 1015 can allocate frequency resources and macro-level beam hopping configuration parameters to satellites, beams, and/or cells. The macro-level beam hopping configuration parameters include beam hopping cycle durations, dwell resolutions, and other such parameters. As illustrated, decisions on resource allocations and macro beam hopping configuration parameters can be based on projected traffic based on historical data, current traffic usage, and traffic utilization feedback from the DUs 1020. In some implementations, AI or ML algorithm can be used to estimate projected traffic.
Embodiments of the scheduler 1025 in each DU 1020 can generally be responsible for micro-level and real-time features supporting beam hopping approaches described herein. For example, embodiments can dynamically determine dwell durations for cells depending, in each hopping cycle, on instantaneous traffic demand and channel conditions and on available frequency resources. For users in cells, embodiments can allocate slots or mini-slots with an appropriate number of RBs, selected MCS (modulation and coding scheme), power level, etc. These and/or other decisions can be made jointly using channel quality and backlog (buffer status) reports from users, HARQ retransmission status, and/or other suitable information. The scheduler 1025 can also account for QoS attributes (e.g., guaranteed bit rate (GBR) versus non-GBR) of user radio bearers. As noted above, the scheduler 1025 can also provide feedback (e.g., congestion, traffic utilization, etc.) to the resource manager 1015 of the GNOC 1010.
Components of the communication systems, such as components of the SRAN and the SOC/GNOC 1010 can be implemented by computational systems. For example, each of the resource manager 1015 and the scheduler 1025 can be implemented by a corresponding computational system and/or by corresponding resources of a computational environment. As illustrated, each computational environment can include one or more processors 1012 and non-transitory, processor-readable memory 1014. Though not explicitly shown, the computational environments can further include any additional computational hardware, such as one or more input/output (I/O) devices, a communications subsystem, etc. The various hardware elements can be electrically coupled by a bus and/or via any other suitable connection. The processors 1012 can include, without limitation, one or more general-purpose processors and/or special-purpose processors. The memory 1014 can include any feasible non-transitory storage devices, such as local and/or network accessible storage, disk drives, drive arrays, optical storage devices, solid-state storage devices, etc. The memory 1014 can additionally include other storage devices, such as transitory storage devices.
The non-transitory, processor-readable memory 1014 can include a working memory, an operating system, device drivers, executable libraries, and/or other code and/or other components to support storing and executing processor-readable instructions. The non-transitory, processor-readable memory 1014 can be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed herein can be implemented as code and/or instructions executable by a computer (and/or a processor within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general-purpose computer (or other device) to perform one or more operations in accordance with the described methods. In some embodiments, the operating system and working memory are used in conjunction with the one or more processors 1012-2 of the DU 1020 to implement the scheduler 1025; and/or the operating system and working memory are used in conjunction with the one or more processors 1012-1 of the SOC/GNOC 1010 to implement the resource manager 1015.
A set of these instructions and/or codes can be stored on a non-transitory computer-readable storage medium (i.e., memory 1014) and can take the form of executable code, which is executable by the processor(s) 1012. Alternatively, the instructions are stored as source and/or installable code, which, upon compilation and/or installation on the computational system (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.), then take the form of executable code. Execution of the instructions causes the one or more processors 1012 to perform steps in accordance with various embodiments of the invention. For example, some or all of the procedures of methods described herein are performed by the processor(s) 1012 executing one or more sequences of one or more instructions contained in the memory 1014.
The traffic dwell resolution defines a quantity X of traffic time slots of duration T in each traffic channel BH cycle. The acquisition dwell resolution defines a quantity Y of acquisition time slots of duration S in each acquisition channel BH cycle. The acquisition time slot duration is a positive multiple of the traffic time slot duration (i.e., S=T*R). R, X, and Y are all positive integers, and S and T are positive numbers that may or may not be integers. In some embodiments, X=20, T=250 μs, Y=329, S=1 ms, and R=4.
In some embodiments, the method 1100 begins prior to stage 1104, at stage 1102, by communicating, by the SRAN to the operations center, the present network data for communication cells of the multi-beam satellite communication system. As described herein, the present network data indicates present network resource supply and demand. In such embodiments, the receiving at stage 1104 can be based at least in part on the communicating.
In some embodiments, the SRAN is configured to communicate according to terrestrial (e.g., 5G) waveform numerologies that define supported subcarrier spacings and associated supported time slot durations. In such embodiments, the macro-level beam hopping (BH) configuration can be generated in connection with stage 1104 so that T is a multiple of one of the supported time slot durations. For example, the traffic dwell resolution of the macro-level BH configuration is generated to define the quantity X of traffic time slots of duration T in each traffic channel BH cycle so that T is a multiple of one of the supported time slot durations. In some such embodiments, the terrestrial waveform numerologies further associate a nominal cyclic prefix (CP) duration for each supported time slot duration, and the multi-beam satellite communication system is configured to operate within a timing synchronization error including a beam switching time. In such embodiments, the macro-level beam hopping (BH) configuration can be generated in connection with stage 1104 so that T is a positive multiple of one of the supported time slot durations associated with a nominal CP duration that is larger than the timing synchronization error. For example, for a 0.5-μs timing synchronization error, the nominal CP duration can be approximately 0.6 μs, 1.2 μs, etc. (corresponding in 5G NR numerologies to SCSs of 120 kHz and 60 kHz, respectively).
At stage 1108, embodiments can generate (e.g., by the SRAN), for each beam of the multi-beam satellite communication system, a corresponding micro-level BH configuration having at least Y*R dwell time slots of duration T. The generating at stage 1108 can include stages 1112-1120. At stage 1112, embodiments can determine a corresponding C communication cells as serviced by the beam (C is a positive integer). For example, each beam can service 7 cells (C=7). As noted above, in some embodiments, the allocation of cells to beams is uniform (e.g., C=7 for all beams); while the allocation of cells to beams is non-uniform in other embodiments (e.g., C=7 on average for all beams, but not necessarily for any one beam). For example, for N beams, the number of cells for beam j can be denoted as C(j), so that Σj=1NCj=Y.
At stage 1116, embodiments can assign, based on the macro-level BH configuration, C*R of the dwell time slots as a portion of the acquisition time slots for the beam and (Y-C)*R of the dwell time slots (i.e., the remaining dwell time slots) to use as the traffic time slots for the beam, thereby yielding (Y-C)*R/X traffic channel BH cycles for the beam. For example, using the quantities in the preceding paragraph and C=7, there would be 329*4=1,316 dwell time slots in each cycle of the micro-level BH configuration, including 7*4=28 dwell time slots assigned for cell acquisition signals and a remaining portion of the dwell time slots assigned for traffic and control signals. In this example, the remaining portion is at least (329-7)*4=1,288, which yields 64.4 (i.e., 1,288/20) traffic channel BH cycles. Some embodiments can expand the micro-level BH configuration to a total number of dwell time slots that yields an even number of traffic channel BH cycles. At stage 1120, embodiments can determine a corresponding dwell duration for each of the C communication cells in each of the traffic channel BH cycles for the beam based on the present network data. For example, cells with higher present traffic can be assigned a longer dwell duration corresponding to a larger portion of the dwell time slots assigned for traffic and control signals in each traffic channel BH cycles.
In some implementations, a given beam can be dedicated for use as either an acquisition beam or a traffic/control beam. In other implementations, acquisition and traffic/control channels can be multiplexed onto a same beam (i.e., the beam is shared by both types of traffic). In one implementation, a beam can carry both acquisition and traffic/control channels simultaneously using different frequencies (e.g., different RB locations without overlap), thereby using the beam to address both acquisition and traffic/control for a given cell. For example, in such an implementation, the number of traffic/control beam hopping cycles can still be 65.8 (1316/20).
In some embodiments, at stage 1124, the method 1100 can direct (e.g., by the SRAN) the multi-beam satellite communication system to sequentially activate beams to communicate traffic channel signals and acquisition channel signals according to the micro-level BH configurations for the beams (e.g., and thereby also according to the macro-level BH configurations).
As described herein, embodiments of the multi-beam satellite communication system can produce the “beams” referenced in stages of the method 1100 as N traffic and control (TnC) beams (N is a positive integer). The multi-beam satellite communication system can further support one positioning, navigation, and timing (PNT) beam. In some embodiments, the multi-beam satellite communication system has a geographic coverage area corresponding to Y communication cells and P PNT cells, wherein P is an integer greater than Y. For example, a geographic coverage area of 329 cells is defined for TnC, and a wider geographic area of 2000 cells is defined for PNT (i.e., Y=329 and P=2,000). In some such embodiments, generating the macro-level BH configuration in connection with stage 1104 can further include defining a PNT channel BH cycle for the PNT beam as having P PNT time slots distributed over a PNT cycle duration. The PNT cycle duration can be different from the acquisition cycle duration. For example, each PNT time slot can be 500 μs, such that 2,000 PNT time slots form a 1-second PNT channel BH cycle. As described herein, the overlaid traffic channel, acquisition channel, and PNT channel BH cycles enables efficient multiplexing of those signals.
In some embodiments, the N TnC beams service Y communication cells, such that Y/N=C. For example, each of the Y acquisition time slots is used to acquire a respective one of the Y communication cells serviced by the N TnC beams. In some such embodiments, the assigning of the C*R of the dwell time slots as the acquisition time slots (as part of stage 1116) includes staggering assigning the dwell times slots for each TnC beam to avoid overlapping with the acquisition time slots for any other of the TnC beams. In such embodiments, a single instance of acquisition (e.g., RACH) hardware can be shared by all beams. Alternatively, the acquisition time slots can be partially staggered, so that there is some overlap. For example, pairs of beams (e.g., or three at a time, four at a time, etc.) can concurrently perform acquisition by using overlapping acquisition time slots, which can reduce the acquisition cycle duration at the expense of increased acquisition resources (e.g., more instances of acquisition hardware using more power, etc.).
In some embodiments, the SRAN is configured to communicate according to terrestrial waveform numerologies that define supported channel bandwidths, each having an associated supported subcarrier spacing. In some such embodiments, at stage 1122, the method 1100 can configure transceivers of the multi-beam satellite communication system to communicate in a satellite channel bandwidth that is not one of the supported channel bandwidths. Such configuration can involve: identifying one of the supported channel bandwidths as the lowest of the supported channel bandwidths that is greater than or equal to the satellite channel bandwidth; identifying the supported subcarrier spacing associated with the identified one of the supported channel bandwidths; computing a largest resource block (RB) quantity, such that a product of the RB quantity, a predefined number of subcarriers per RB, and the identified supported subcarrier spacing yields a channel pseudo-bandwidth that is closest to the satellite channel bandwidth without exceeding the satellite channel bandwidth; and reserving any remainder between the satellite channel bandwidth and the channel pseudo-bandwidth as a guard band.
Having described several example configurations, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may be components of a larger system, wherein other rules may take precedence over or otherwise modify the application of the invention. Also, a number of steps may be undertaken before, during, or after the above elements are considered.
| Number | Date | Country | |
|---|---|---|---|
| 63622752 | Jan 2024 | US |
