U.S. patent application number 15/186417 was filed with the patent office on 2018-11-01 for approaches for high speed global packet data services for leo/meo satellite systems.
The applicant listed for this patent is Hughes Network Systems, LLC. Invention is credited to Nassir BENAMMAR, John CORRIGAN, Rajeev GOPAL, Xiaoling HUANG, James JONG, Anthony NOERPEL, Harish RAMCHANDRAN, Channasandra RAVISHANKAR, Yash VASAVADA, Gaguk ZAKARIA.
Application Number | 20180316414 15/186417 |
Document ID | / |
Family ID | 60659872 |
Filed Date | 2018-11-01 |
United States Patent
Application |
20180316414 |
Kind Code |
A9 |
RAVISHANKAR; Channasandra ;
et al. |
November 1, 2018 |
APPROACHES FOR HIGH SPEED GLOBAL PACKET DATA SERVICES FOR LEO/MEO
SATELLITE SYSTEMS
Abstract
A satellite system comprises LEO satellites and MEO satellites,
and a control plane protocol architecture. The PHY, MAC, MAC/RLC
and RRC layers are optimized for satellite environment. When the
satellites are not processing satellites, eNB functions are
implemented in a satellite gateway, and, when the satellites are
processing satellites, protocol architecture in the control plane
differ from LTE, as follows: PHY layer is moved to the
communicating LEO/MEO satellite on the user link, MAC/RLC, RRC and
PDCP are be located in satellite or gateway depending on satellite
complexity, and the need to have mesh connectivity between UTs.
When the RRC is implemented in the satellite, the RRC is divided
into RRC-Lower and RRC-Upper layers. The RRC-L is satellite-based,
and handles UT handover. The RRC-U is eNB-based, and handles
resource management functions. The RRC-U communicates with the PDCP
layer in the eNB to configure security, header and data
compression.
Inventors: |
RAVISHANKAR; Channasandra;
(Clarksburg, MD) ; CORRIGAN; John; (Chevy Chase,
MD) ; GOPAL; Rajeev; (North Potomac, MD) ;
VASAVADA; Yash; (Gaithersburg, MD) ; JONG; James;
(North Potomac, MD) ; BENAMMAR; Nassir;
(Rockville, MD) ; ZAKARIA; Gaguk; (College Park,
MD) ; NOERPEL; Anthony; (Lovettsville, VA) ;
RAMCHANDRAN; Harish; (Germantown, MD) ; HUANG;
Xiaoling; (Boyds, MD) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Hughes Network Systems, LLC |
Germantown |
MD |
US |
|
|
Prior
Publication: |
|
Document Identifier |
Publication Date |
|
US 20170366251 A1 |
December 21, 2017 |
|
|
Family ID: |
60659872 |
Appl. No.: |
15/186417 |
Filed: |
June 17, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62181062 |
Jun 17, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04B 7/18584 20130101;
H04B 7/18541 20130101; H04B 7/18513 20130101; H04W 84/06
20130101 |
International
Class: |
H04B 7/185 20060101
H04B007/185 |
Claims
1. A satellite communications system comprising: one or more low
earth orbit (LEO) satellites; one or more medium earth orbit (MEO)
satellites; a control plane protocol architecture where physical
(PHY), media access control (MAC), MAC radio link control (MAC/RLC)
and radio resource control (RRC) layers are optimized for a
satellite environment, wherein, when the satellites are not
processing satellites, e-node-B (eNB) functions are implemented in
a satellite gateway, and, when the satellites are processing
satellites, protocol architecture in the control plane for the
satellite system have the following differences from LTE: PHY layer
is moved to the communicating LEO/MEO satellite on the user link,
MAC/RLC, RRC and packet data control plane (PDCP) may be located in
satellite or gateway depending on complexity of the satellite, and
the need to have mesh connectivity between user terminals, when the
RRC is implemented in satellite, the RRC is divided into RRC-Lower
(RRC-L) and RRC-Upper (RRC-U) layers, wherein the RRC-L is located
in the satellite and is responsible for handover signaling with
user terminals, and the RRC-U is located in the eNB' and is
responsible for resource management functions including admission
control, and the RRC-U communicates with the PDCP layer in the eNB'
to configure security, header compression and data compression
schemes.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit of the earlier filing
date under 35 U.S.C. .sctn.119(e) from U.S. Provisional Application
Ser. No. 61/181,062 (filed Jun. 17, 2015), which is incorporated
herein by reference herein in its entirety.
BACKGROUND
[0002] Terrestrial communication systems continue to provide higher
and higher speed multimedia (e.g., voice, data, video, images,
etc.) services to end-users. Such services (e.g., Third Generation
(3G) and Fourth Generation Long Term Evolution (4G LTE) systems and
services) can also accommodate differentiated quality of service
(QoS) across various applications. To facilitate this, terrestrial
architectures are moving towards an end-to-end all-Internet
Protocol (IP) architecture that unifies all services, including
voice, over the IP bearer. In parallel, mobile satellite systems
are being designed to complement and/or coexist with terrestrial
coverage depending on spectrum sharing rules and operator choice.
With the advances in processing power of portable computers, mobile
phones and other highly portable devices, the average user has
grown accustomed to sophisticated applications (e.g., streaming
video, radio broadcasts, video games, etc.), which place tremendous
strain on network resources. Further, such users have grown to
expect ubiquitous global coverage. The Web as well as other
Internet services rely on protocols and networking architectures
that offer great flexibility and robustness; however, such
infrastructure may be inefficient in transporting Web traffic,
which can result in large user response time, particularly if the
traffic has to traverse an intermediary network with a relatively
large latency (e.g., a satellite network). Such high mobility,
enhanced processing power of devices, and growth of low-latency
applications, however, puts an immense strain on current
terrestrial and satellite communications systems.
[0003] What is needed, therefore, is an approach for a low earth
orbit (LEO)/medium earth orbit (MEO) multi-satellite communications
system for efficiently providing high speed and high quality packet
data services.
SOME EXAMPLE EMBODIMENTS
[0004] Embodiments of the present invention advantageously address
the foregoing requirements and needs, as well as others, by
providing an approach for providing high speed and high quality
packet data services via a LEO/MEO satellite system. The LEO/MEO
satellites may be processing satellites. When LEO/MEO satellites
are processing satellites, IP packets and Layer 2 frames
transmitted by user terminals are recovered at the satellite and
transmitted on the gateway links and/or inter-satellite links.
Similarly, in the direction from network to user terminal, IP
packets and Layer 2 frames transmitted by gateways are recovered at
the satellite and transmitted on the user links. The frequency and
format of transmission on gateway and user links may be different.
In addition, the transmission to and from user terminal on a user
link may be different. Similarly, the transmission to and from
gateway on a gateway link may be different. The architecture also
permits transmission from user terminal to another user terminal
directly without traversing through a gateway. Similarly, the
architecture permits direct gateway to gateway communication via
the satellite constellation. When LEO/MEO satellites are not
processing satellites (i.e., they are bent-pipe satellites),
communication is directly between user terminal and gateway with a
frequency translation between gateway links and user links.
[0005] In accordance with example embodiments, an overall network
architecture is shown in FIG. 1. The user terminal (UT) may be in
one of a multiplicity of beams in the user link. Satellites, and
therefore beams corresponding those satellites move (for
satellite-fixed beams) over the user terminal as the LEO/MEO
constellation moves even if the user terminal is not moving.
Accordingly, beam-to-beam and satellite-to-satellite handover are
required in this scenario. User terminals are typically equipped
with a tracking antenna that is preferably electronically steered.
However, the design does not preclude terminals using mechanical
steering. In another embodiment, the satellite attempts to steer
its antenna such that beams remain in the same place on the earth
surface (also called earth-fixed beams). In this case, there is no
need for beam-to-beam handover. The system also supports gateway to
gateway handover to cater to cases where a user terminal may be in
motion and it crosses from one gateway region to another. Gateway
to Gateway handover would also be necessary when a Gateway fails or
when the capacity of the gateway is such that it cannot accept any
additional sessions. As part of the above mentioned beam-to-beam,
satellite-to-satellite and gateway-to-gateway handovers, frequency
handovers occur in a multiple frequency reuse system. To this end,
the system design also supports frequency handover even when there
is no beam-to-beam, satellite-to-satellite and gateway-to-gateway
handovers; this will be the case when a frequency is deemed
unusable due to interference and/or when it is required to move a
terminal to a different frequency for resource usage efficiency
issues and for services such as IP multicast.
[0006] Certain system features are as follows: [0007] Powerful FEC
coding, near theoretical channel performance; [0008] Adaptive
Coding & Modulation (ACM) improves throughput every channel
condition; [0009] Power-conserving design reduces power to enable
battery/solar powered user terminal (sleep/wake paging cycle);
[0010] MAC layer design for efficient Bandwidth-on-Demand; [0011]
Support for Small and Large terminal types as well as fixed and
mobile terminal types including Aeronautical and Maritime
terminals; [0012] Quality-of-Service (QoS) support for multiple
service types; [0013] Simplified satellite design to minimize
technical and costs risks; [0014] Simplified routing/switching
function in the satellite using a centralized route determination
function in each gateway that determines optimal routes. This
removes the burden for satellite to be dynamically figuring out the
routes; [0015] Mobility Management functions enable beam,
satellite, gateway and frequency handovers; [0016] Scalable Gateway
architecture to cater to different throughputs and different number
of LEO/MEO satellites that it would need to communicate with;
[0017] Standard wireless and network protocols to utilize
commercial implementations and evolution;
[0018] Still other aspects, features, and advantages of the present
invention are readily apparent from the following detailed
description, simply by illustrating a number of particular
embodiments and implementations, including the best mode
contemplated for carrying out the present invention. The present
invention is also capable of other and different embodiments, and
its several details can be modified in various obvious respects,
all without departing from the spirit and scope of the present
invention. Accordingly, the drawing and description are to be
regarded as illustrative in nature, and not as restrictive.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] Embodiments of the present invention are illustrated by way
of example, and not by way of limitation, in the figures of the
accompanying drawings, in which like reference numerals refer to
similar elements, and in which:
[0020] FIG. 1 illustrates the high-level architecture of a low
earth orbit (LEO)/medium earth orbit (MEO) satellite system,
according to example embodiments;
[0021] FIG. 2A illustrates the user plane protocol architecture of
a 4G long-term evolution (LTE) terrestrial system;
[0022] FIG. 2B illustrates the user plane protocol architecture for
a LEO/MEO satellite system, according to example embodiments;
[0023] FIG. 3A illustrates the control plane protocol architecture
of a 4G long-term evolution (LTE) terrestrial system;
[0024] FIG. 3B illustrates the control plane protocol architecture
for a LEO/MEO satellite system, according to example
embodiments;
[0025] FIG. 4A illustrates a physical layer burst, according to
example embodiments;
[0026] FIG. 4B illustrates a return link RACH window, according to
example embodiments;
[0027] FIG. 4C illustrates an example of control messages (such as
RACH and traffic) multiplexed on the same narrowband carrier,
according to example embodiments;
[0028] FIG. 4D illustrates an example of synchronous HARQ
signaling, according to example embodiments;
[0029] FIG. 4E illustrates an example of hybrid HARQ signaling,
according to example embodiments;
[0030] FIG. 5A depicts a 3-D graph showing antenna gain in a
satellite system, according to example embodiments;
[0031] FIG. 5B depicts a graph showing system throughput with
adaptive coding and modulation in a satellite system, according to
example embodiments;
[0032] FIG. 6A illustrates modification of a DVB-S2 format to
achieve the establishment of frame markers reflecting system time
for a user terminal battery conservation technique, according to
example embodiments;
[0033] FIG. 6B illustrates a user terminal state behavior for
reduction in terminal battery usage, according to example
embodiments;
[0034] FIG. 6C illustrates satellite transmissions to a user
terminal for reduction in terminal battery usage, according to
example embodiments;
[0035] FIG. 7A illustrates example of carrier channels for access
and traffic channels of a flexible media access control (MAC) layer
bandwidth on demand design, according to example embodiments;
[0036] FIG. 7B illustrates an example MAC layer bandwidth on demand
unsolicited uplink grant (UUG), according to example
embodiments;
[0037] FIG. 8 illustrates the RLC MAC layer context of a satellite
system, according to example embodiments;
[0038] FIG. 9 illustrates an example MAC layer downlink burst and
public information (PUI), according to example embodiments;
[0039] FIG. 10 illustrates an example MAC layer block boundary
encoding, according to example embodiments;
[0040] FIG. 11A illustrates an example slot assignment, according
to example embodiments;
[0041] FIG. 11B illustrates an example terminal addressing,
according to example embodiments;
[0042] FIG. 12A illustrates the RRC control plane architecture of a
satellite system, according to example embodiments;
[0043] FIG. 12B illustrates an example RRC state diagram, according
to example embodiments;
[0044] FIG. 12C illustrates RRC user terminal identifiers for
identifying and tracking UT context, according to example
embodiments;
[0045] FIG. 12D depicts a signal flow diagram illustrating RRC
connection establishment, according to example embodiments;
[0046] FIG. 12E depicts a signal flow diagram illustrating an RRC
attach and bearer setup procedure, according to example
embodiments;
[0047] FIG. 12F depicts a signal flow diagram illustrating an RRC
transition to idle mode, according to example embodiments;
[0048] FIG. 12G depicts a signal flow diagram illustrating RRC EPC
originated paging, according to example embodiments;
[0049] FIG. 12H depicts a signal flow diagram illustrating an RRC
user terminal originated MAC activation, according to example
embodiments;
[0050] FIG. 12I depicts a signal flow diagram illustrating an RRC
SAN originated paging, according to example embodiments;
[0051] FIG. 13A depicts a signal flow diagram illustrating a route
management determination, according to example embodiments;
[0052] FIG. 13B illustrates an example end-to-end routing protocol
stack structure, according to example embodiments;
[0053] FIG. 13C illustrates an example APN IP network domain
structure, according to example embodiments;
[0054] FIG. 13D illustrates an example satellite interface domain
structure, according to example embodiments;
[0055] FIG. 13E illustrates an example gateway (GW) network domain
structure, according to example embodiments;
[0056] FIG. 14A depicts a signal flow diagram illustrating call
flow messaging for initial registration and subsequent data
transfer call phases, according to example embodiments;
[0057] FIGS. 14B and 14C illustrate a routing change (not a
handover) occurring in the satellite due to handover on the gateway
link, according to example embodiments;
[0058] FIG. 14D illustrates a user terminal mobility management
context structure, according to example embodiments;
[0059] FIG. 15A depicts a signal flow diagram illustrating a beam
to beam handover, according to example embodiments;
[0060] FIG. 15B depicts a signal flow diagram illustrating the
preparation phase of a satellite to satellite handover, according
to example embodiments;
[0061] FIG. 15C depicts a signal flow diagram illustrating the data
transfer phase of a satellite to satellite handover, according to
example embodiments;
[0062] FIG. 15D depicts a signal flow diagram illustrating the
preparation phase of a gateway to gateway handover, according to
example embodiments;
[0063] FIG. 15E depicts a signal flow diagram illustrating the data
transfer phase of a gateway to gateway handover, according to
example embodiments;
[0064] FIG. 15F illustrates a gateway to gateway handover, where
the user terminal is at one gateway, according to example
embodiments;
[0065] FIG. 15G illustrates a gateway to gateway handover, where
the user terminal moves to another gateway, according to example
embodiments;
[0066] FIG. 15H depicts a signal flow diagram illustrating the
preparation phase of a gateway to gateway handover with a satellite
change, according to example embodiments;
[0067] FIG. 15I depicts a signal flow diagram illustrating the data
transfer phase of a gateway to gateway handover with a satellite
change, according to example embodiments;
[0068] FIG. 16A illustrates a diagram of the return link timing and
frame numbering synchronization, according to example
embodiments;
[0069] FIG. 16B illustrates a switching time for user terminal
transition from receive to transmit, according to example
embodiments;
[0070] FIG. 16C illustrates synchronization for half duplex
operation where the satellite coverage area on the ground is
divided into multiple Half Duplex Divisioned (HDD) groups,
according to example embodiments;
[0071] FIG. 16D illustrates gateway timing synchronization,
according to example embodiments;
[0072] FIG. 16E illustrates a gateway frame numbering scheme for
synchronization, according to example embodiments;
[0073] FIG. 17A illustrates an example gateway architecture,
according to example embodiments; and
[0074] FIG. 17B illustrates interfaces to an e-node B function of a
gateway, according to example embodiments.
DETAILED DESCRIPTION
[0075] System architectures and associated processes for providing
high speed and high quality packet data services via a LEO/MEO
satellite system are described. In the following description, for
the purposes of explanation, numerous specific details are set
forth in order to provide a thorough understanding of the
invention. It is apparent, however, that the invention may be
practiced without these specific details or with an equivalent
arrangement. In other instances, well-known structures and devices
are shown in block diagram form in order to avoid unnecessarily
obscuring the invention.
[0076] As will be appreciated, a module or component (as referred
to herein) may be composed of software component(s), which are
stored in a memory or other computer-readable storage medium, and
executed by one or more processors or CPUs of the respective
devices. As will also be appreciated, however, a module may
alternatively be composed of hardware component(s) or firmware
component(s), or a combination of hardware, firmware and/or
software components. Further, with respect to the various example
embodiments described herein, while certain of the functions are
described as being performed by certain components or modules (or
combinations thereof), such descriptions are provided as examples
and are thus not intended to be limiting. Accordingly, any such
functions may be envisioned as being performed by other components
or modules (or combinations thereof), without departing from the
spirit and general scope of the present invention. Moreover, the
methods, processes and approaches described herein may be
processor-implemented using processing circuitry that may comprise
one or more microprocessors, application specific integrated
circuits (ASICs), field programmable gate arrays (FPGAs), or other
devices operable to be configured or programmed to implement the
systems and/or methods described herein. For implementation on such
devices that are operable to execute software instructions, the
flow diagrams and methods described herein may be implemented in
processor instructions stored in a computer-readable medium, such
as executable software stored in a computer memory store.
[0077] Further, terminology referring to computer-readable media or
computer media or the like as used herein refers to any medium that
participates in providing instructions to the processor of a
computer or processor module or component for execution. Such a
medium may take many forms, including but not limited to
non-transitory non-volatile media and volatile media. Non-volatile
media include, for example, optical disk media, magnetic disk media
or electrical disk media (e.g., solid state disk or SDD). Volatile
media include dynamic memory, such random access memory or RAM.
Common forms of computer-readable media include, for example,
floppy or flexible disk, hard disk, magnetic tape, any other
magnetic medium, CD ROM, CDRW, DVD, any other optical medium,
random access memory (RAM), programmable read only memory (PROM),
erasable PROM, flash EPROM, any other memory chip or cartridge, or
any other medium from which a computer can read data.
[0078] Various forms of computer-readable media may be involved in
providing instructions to a processor for execution. For example,
the instructions for carrying out at least part of the present
invention may initially be borne on a magnetic disk of a remote
computer. In such a scenario, the remote computer loads the
instructions into main memory and sends the instructions over a
telephone line using a modem. A modem of a local computer system
receives the data on the telephone line and uses an infrared
transmitter to convert the data to an infrared signal and transmit
the infrared signal to a portable computing device, such as a
personal digital assistance (PDA) and a laptop. An infrared
detector on the portable computing device receives the information
and instructions borne by the infrared signal and places the data
on a bus. The bus conveys the data to main memory, from which a
processor retrieves and executes the instructions. The instructions
received by main memory may optionally be stored on storage device
either before or after execution by processor.
Architecture
[0079] FIG. 1 illustrates the high-level architecture of a low
earth orbit (LEO)/medium earth orbit (MEO) satellite system,
according to example embodiments. As illustrated by FIG. 1, the Ku
band in user-link and V/Q band in Gateway link as examples. Other
frequencies that are mutually exclusive may also be used in Gateway
link and user links. As further shown in FIG. 1, Satellite Gateways
are connected via terrestrial links or via the existing LEO/MEO
satellite constellation or via a GEO satellite system. IP Core
network resembles that of a classical 4G-LTE network with the
Border Gateway playing the role of PDN-Gateway (PGW) of LTE core
network. Other elements that have a correspondence to 4G LTE core
network include Subscription server (equivalent to the Home
Subscription Server--HSS), Management Server (equivalent of MME)
and Security Server (equivalent to AuC). Although the Serving
Gateway (SGW) is not explicitly shown, it is expected to be part of
the Satellite Gateway and/or PGW.
[0080] FIG. 2A illustrates the user plane protocol architecture of
a 4G long-term evolution (LTE) terrestrial system, and FIG. 2B
illustrates the user plane protocol architecture for a LEO/MEO
satellite system, according to example embodiments. It is noted
from FIG. 2B that the interface from eNB' to SGW is a standard S1-U
interface. This feature permits the use of COTS core network
element. Similarly, all interfaces within the core network and
to/from core network are based on 4G LTE standards.
[0081] FIG. 3A illustrates the control plane protocol architecture
of a 4G long-term evolution (LTE) terrestrial system, and FIG. 3B
illustrates the control plane protocol architecture for a LEO/MEO
satellite system, according to example embodiments. Similar to
user-plane discussion above, this has resemblance to the control
plane 4G LTE protocol architecture (FIG. 3a) with the following
additional key differences. Satellite system protocol architecture
for Control Plane is similar to terrestrial 4G-LTE Control Plane
protocol architecture shown in FIG. 3A. The PHY, MAC/RLC and RRC
layers are optimized for satellite environment. When satellites
involved are not processing satellites, the eNB functions are
implemented in a satellite gateway. However, for systems that have
processing satellites, protocol architecture in Control Plane for
the satellite system have the following key differences. [0082] PHY
layer is moved to the communicating LEO/MEO satellite on the user
link. [0083] MAC/RLC, RRC and PDCP may be located in satellite or
gateway depending on permitted complexity of satellite, the need to
have mesh connectivity between user terminals. The entity in the
Gateway performing these functions is called herein as eNB'. [0084]
When RRC is implemented in satellite, RRC is divided into RRC-L
(RRC-Lower) and RRC-U (RRC-Upper) layers; RRC-L is located in the
satellite and is responsible for handover signaling with UT. RRC-U
is located in the eNB' and is responsible for resource management
functions including admission control. [0085] RRC-U communicates
with PDCP layer in eNB' to configure security, header compression
and data compression schemes. [0086] In FIG. 3B, although Ku band
is depicted for the user link, system design embodiments also
facilitate use of Ka band or L/S bands for improved
availability.
[0087] It is noted from FIG. 3B that the interface from eNB' to SGW
is a standard S1-U interface. Similarly, from FIG. 3B, the
interface from eNB' to MME is a standard S1-MME interface These
features permit the use of COTS core network element. Similarly,
all interfaces within the core network and to/from core network are
based on 4G LTE standards.
Physical Layer
[0088] On the user link, use of multi-carrier (each with its own
Power Amplifier) and single wideband carrier are considered for
this system. Single wideband carrier provides better resource usage
(multiplexing) efficiency, however will require a power amplifier
with higher output power. Use of multiple carrier with its own
power amplifier solves this problem, however, analog multiplexing
to an antenna port as well as resource multiplexing inefficiency
have to be managed. Physical layer is based on state-of-the-art
LDPC codes or turbo codes in both forward and return links. The
following are some attributes of forward link and return link
multiple access schemes. [0089] Forward Link [0090] FDMA/TDM [0091]
Control/traffic channels multiplexed in time [0092] Return Link
[0093] Traffic channels: MF-TDMA or terrestrial standard such as
SC-FDMA [0094] Control channels/narrow band data: Slotted Aloha,
spread spectrum with MUD etc.
[0095] Return Link Physical and Logical Channels are as follows:
[0096] Return Link Physical and Logical Channels are as follows:
[0097] Packet Data Channel (PDCH): Transport PDTCH (Packet Data
Traffic Channel) logical channel and Uplink Control Messages [0098]
Random Access Channel (RACH): Transport RACH channel
[0099] The following table provides a description of the logical
channels in return link
TABLE-US-00001 Physical Logical Channel Channel Description PDCH
PDTCH Packet data traffic channel. The channel is also used to
carry uplink control messages. MAC control messages are multiplexed
along with data on this channel. RACH RACH Random access channel
for sending Channel Request.
[0100] Forward Link Physical and Logical Channels are as follows:
[0101] Packet Data Channel (PDCH): Transport PDTCH (Packet Data
Traffic Channel) logical channel and Downlink Control Messages
[0102] Packet Control Channel (PCCH): Transport following logical
channels (Broadcast Channel, Paging Channel, Access Grant Channel,
Packet Data Control Channel)
[0103] The following table provides description of the logical
channels in forward link
TABLE-US-00002 Physical Logical Channel Channel Description PDCH
PDTCH Packet data traffic channel. The channel is also used to
carry downlink control messages. MAC control messages are
multiplexed along with data on this channel. PCCH BCCH System
information including system synchronizaton, satellite ephemeris,
access parameters PCH/AGCH Paging channel or Access Grant Channel
in response to RACH
[0104] Time slot and frame Definition Example: [0105] 1 ms frame
consists of 12 time slots [0106] A time slot is a minimum duration
that carries burst
[0107] FIG. 4A illustrates a physical layer burst, according to
example embodiments. [0108] The Burst consists of [0109] UW,
Control Header (PUI), Payload [0110] PUI is located at the front of
the burst: Contains MCS, ULMAP, DLMAP, Payload presence
information, ARQ related signaling, Power Control Command [0111] UW
symbols may be placed across burst
[0112] For PUI, an alternate embodiment is to use convolutional
codes instead of LDPC/Turbo Codes. [0113] A burst can carry either
PDTCH only or PCCH/PDTCH [0114] No difference in physical layer
processing [0115] The classification of PCCH/PDTCH is done in MAC
[0116] Burst contains PCCH/PDTCH is PI/2-BPSK modulated [0117] PCCH
can be scheduled every 10 ms [0118] UT may wake up every [10] ms to
read PUI and check for PAGE (The presence of payload is indicated
in PUI, minimizing Satellite and UT power consumption)
[0119] A given burst may carry blocks that have different
modulation and FEC schemes. If a burst were to contain blocks that
were BPSK and QPSK modulated, for a processing satellite it is
proposed to repeat the QPSK symbols instead of changing modulation
scheme to BPSK within a burst but perform appropriate repetition
for improved performance . This keeps satellite design simple. In
other words, if one of the payloads were to be carried using pi/2
BPSK and other payloads were to be carried using pi/4 QPSK, then
the BPSK symbols of the payload would be carried using repeated
QPSK symbols so that the entire burst would look like pi/4 QPSK.
The receiver then combined multiple pi/4 QPSK symbols for the BPSK
region of the burst.
[0120] Frame Hierarchy Example [0121] Time slot: 1/12 ms (burst
duration in multiple integer of TS) [0122] Frame: 1 ms (single or
multiple Uplink/downlink allocation signaling) [0123] Multi-frame:
10 ms (paging once every 10 ms) [0124] Super frame: 40 ms (BCCH
info update with class 1 information occurring every 10 ms) [0125]
Hyper frame: 1 second
[0126] Forward Link Transmission structure example [0127] Extremely
simple and efficient for signaling [0128] Efficient reference
signal design that serves multiple purposes [0129] Fast
acquisition, reliable synchronization, etc. [0130] Dedicated
control field with predefined number of bits available every 1/12
ms for any essential control signaling such as downlink, uplink
allocation, MCS, DRX, hybrid ARQ feedback, etc. [0131] Shared PDCH
available every 1/12 ms which could be periodically (every 10 ms)
used for providing control info simultaneously to many users (i.e.,
broadcasting system information)
RACH Design in Return Link
[0132] FIG. 4B illustrates a return link RACH window, according to
example embodiments. The RACH is carried on a narrowband carrier
with large RACH window to accommodate timing uncertainties within a
beam. In the single burst format for narrow band PDCH and RACH only
additional preamble is attached at the beginning and end of the
burst when RACH is transmitted, which allows uniform design of PDCH
and RACH design.
[0133] FIG. 4C illustrates an example of control messages (such as
RACH and traffic) multiplexed on the same narrowband carrier,
according to example embodiments.
[0134] Further control messages (such as RACH and traffic) can be
multiplexed on the same narrowband carrier. Traffic on narrowband
carrier allows for small packets such as TCP ACK to be transmitted
and at the same time off-loading the wider band traffic
carriers.
Hybrid ARQ
[0135] Given that the delays in LEO/MEO satellites are much shorter
than that of GEO satellites, concepts such as Hybrid ARQ (HARQ) are
applicable in this system. HARQ Parameters are derived based on the
following assumptions: [0136] Return Link: 20 Msym/sec. Burst
duration in return link is 0.5 ms [0137] Processing delay is 2
ms,Propagation delay between Terminal and Satellite 4 ms [0138]
Synchronous transmission [0139] ACK sent immediately on receiving
the packet (Stop and Wait) [0140] If only one burst is sent, next
opportunity to retransmit the burst is after 13 ms (26 return link
time units). Hence a total of 26 HARQ processes assumed using
return link HARQ framework similar to LTE.
Signaling for Synchronous HARQ
[0141] Additional control signaling from SAT to UT indicate
retransmission or new transmission. If synchronous transmission is
employed, then retransmissions are scheduled exactly HARQ_window
slots after the original transmission. If an allocation is made in
uplink slot k, then slot k is for original transmission, slot
k+HARQ_window is for retransmission 1, slot k+2*HARQ_window is for
retransmission 2. Only when ACK received can the same HARQ process
(and corresponding time slots) can be assigned to other
allocations.
[0142] FIG. 4D illustrates an example of synchronous HARQ
signaling, according to example embodiments. If too many
allocations are made in the HARQ_window then system might be unable
to accommodate new allocations. Therefore a threshold limit is set
on the number of new transmissions within a HARQ_window.
Asynchronous HARQ
[0143] Restrictions imposed by synchronous HARQ from scheduling
point of view [0144] Is it possible to use asynchronous HARQ [0145]
Explicit process ID needed [0146] Process ID width will be the
number of HARQ process supported [0147] Process ID is 3 bits for
LTE FDD [0148] How long to store packets in the buffer ? [0149]
Asynchronous new transmissions and asynchronous retransmissions
[0150] Buffer storage can be potentially huge [0151] Need limits on
maximum number of HARQ processes supported
Hybrid Hybrid ARQ (HHARQ)
[0152] FIG. 4E illustrates an example of hybrid HARQ signaling,
according to example embodiments. The hybrid Hybrid ARQ (HHARQ)
facilitates use of asynchronous transmissions for new transmissions
and scheduling retransmissions in a synchronous manner. The buffer
size depends on the time interval between the original transmission
and the retransmission. An explicit HARQ process ID is used to
achieve this
Bundling
[0153] When users are in disadvantaged location, instead of waiting
for ACK/NACK from satellite, bundle the new transmission and the
retransmissions. When retransmitted packet contents are similar to
original packet (Chase combining) then this is similar to
repetition. This may introduce time interval between original
transmission and retransmissions to take advantage of time
diversity.
Dynamic Link Adaptation
[0154] The satellite links will support dynamic link adaptation to
cater to different channel conditions that the user terminal
experiences as the satellite moves. The extent to which beam
pattern gains change as the satellite moves depends on the
satellite antenna shape, aperture size and frequency of operation.
Figure below indicates that the gain can decrease much as 8-10 dB
at the edge of the beam as compared to the center of the beam for
about a 20 cm antenna horn operating at 14.5 GHz frequency.
[0155] FIG. 5A depicts a 3-D graph showing antenna gain in a
satellite system, according to example embodiments.
[0156] In addition, environmental conditions (rain, clouds etc.)
also influence the attenuation that the signal undergoes. Finally,
the C/I that the links have are a function of the load and in the
return link the relative location and power of interfering users
compared to the user of interest. All these factors motivate the
need for dynamic link adaptation whereby the throughput is
maximized for a given channel condition by changing the modulation
and coding scheme based on channel condition. This is illustrated
in figure below.
[0157] FIG. 5B depicts a graph showing system throughput with
adaptive coding and modulation in a satellite system, according to
example embodiments.
[0158] To this end, the physical layer bearers are defined such
that they span the various modulation and coding schemes to give 10
to 15 dB of channel quality variation. The modulation schemes are
from repeated pi/2 BPSK to pi/4 QPSK to 3pi/4 8-PSK to 16-APSK.
Coding rates vary from Rate 1/5 code to Rate 9/10 code using LDPC
codes.
Battery Conservation Feature
[0159] Battery conservation is an important feature for both user
terminal as well as satellite. When a user terminal is battery or
solar powered, this feature becomes even more critically important.
Accordingly, a scheme is developed whereby a user terminal in idle
mode will only wake up for less than 0.5 ms every 10 ms, thereby
leading to a reduction in battery consumption by up to 95%. This is
facilitated by the satellite/network only paging the user terminal
at the wake up time of the terminal. Therefore, there is a need to
establish the concept of a system time. The system time is
established by the satellite based on the GPS receiver it has. It
uses the 1 pulse per second ticks to establish frame markers in the
satellite downlink. The user terminal is made aware of these ticks
by using a special sequence of unique words in the user link
downlink at the 1 PPS or an integer submultiple of 1 second. An
example scheme is illustrated in figure below wherein a DVB-S2
format is modified to achieve this establishment of frame markers.
This concept is also applicable to framework other than DVB-S2 such
as the one described earlier in the document for Physical
Layer.
[0160] FIG. 6A illustrates modification of a DVB-S2 format to
achieve the establishment of frame markers reflecting system time
for a user terminal battery conservation technique, according to
example embodiments. User terminals performs dual hypothesis to
determine the frame marker used by the satellite. An important
advantage of this scheme is that, since these markers are based on
GPS, these markers are aligned across all satellites--this helps
when there is a satellite to satellite handover, since there is no
need to re-establish these frame markers. User terminal states and
behavior is shown below that achieves about 95% reduction in
battery usage.
[0161] FIG. 6B illustrates a user terminal state behavior for
reduction in terminal battery usage, according to example
embodiments.
[0162] The air interface described herein further reduces battery
consumption in user terminal even in the Connected State. Here the
downlink burst in the front has information regarding the user(s)
to which the rest of the burst belongs. A user terminal first
demodulates and decodes the front part of the burst to determine if
the rest of the burst had data for it or not. If not, user terminal
powers down until the beginning of next burst thereby saving power.
As an example, when the front portion of the burst is 4
microseconds long and burst duration is about 80 microseconds, then
assuming that the terminal is consuming power for no more than 8
microseconds, the saving is 90% in connected mode when there is no
burst for it. If a terminal is active 20% of the time and 10% of
the downlink bursts are meant for the terminal, then total battery
consumption in connected mode is only is 7.8% leading to a power
saving of 92.2% for the baseband part of the user terminal.
[0163] A facility for further reduction in battery power
consumption in idle mode is also provided. Here the front part of
the burst also contains a bit to indicate whether the rest of the
burst contains a page message or not. User terminal therefore needs
to wake up for about 8 microseconds every 10 ms in idle mode
leading to a very negligible power consumption in idle mode.
[0164] In a LEO/MEO environment, the satellite orbits the earth in
less than 2hours and will therefore have very short visibility to
the sun for charging its battery in each orbit. Therefore, if there
are no active users at all in a beam, the satellite does not spend
any power for 10 ms. Every 10 ms satellite would transmit system
information for about 80 microseconds leading to a battery saving
of more than 99%. In other words, power overhead will be less than
1%.
[0165] FIG. 6C illustrates satellite transmissions to a user
terminal for reduction in terminal battery usage, according to
example embodiments. Based on extrapolation of timing and
frequency, user terminal will be able to go to complete sleep for
about 10 ms and wake up and still be able to demodulate and decode
the burst.
MAC Layer Attributes
[0166] A flexible and efficient MAC layer is provided for both
access as well as traffic. MAC layer design is based on Bandwidth
on Demand (BoD) and therefore the proposed method provides dynamic
allocation of resources based on demand. For access channels, a
narrowband (e.g., 1 MHz carriers) channels are used, and for
traffic, narrowband or wideband (e.g., 17.5 MHz) channels are used
in a dynamic way so as to use the available uplink resources in a
very efficient manner.
[0167] FIG. 7A illustrates example of carrier channels for access
and traffic channels of a flexible media access control (MAC) layer
bandwidth on demand design, according to example embodiments. Key
attributes include: [0168] Low bandwidth (1 MHz) access channel for
initial access [0169] Minimizes signaling overhead [0170] Keeps
satellite receiver simple [0171] Can be used to request access as
well as transfer data [0172] Frequent Uplink allocation signaling
to minimize delay (0.5 ms) [0173] Control and Data packet
multiplexing for improved spectral efficiency [0174] Unsolicited
uplink grants to further decrease delay of uplink allocation (see
figure below). Here the satellite provides an Unsolicited Uplink
Grant (UUG) to user terminal so that the terminal can transmit TCP
Acknowledgements using UUG on the traffic channel right away
without soliciting resources from the satellite. This provides
delay efficiency. It is noted that for half duplex terminals, the
terminal cannot receive while it is transmitting. Therefore,
satellite cannot transmit in downlink when user terminal has been
allocated an uplink resource, including UUG. The UUG scheme is thus
different for half-duplex terminals compared to full-duplex
terminals. For half-duplex terminals, the frequency of UUGs will be
less than that for full duplex terminals.
[0175] FIG. 7B illustrates an example MAC layer bandwidth on demand
unsolicited uplink grant (UUG), according to example
embodiments.
[0176] MAC layer signaling and scheduler design supports multiple
terminal types. The half-duplex and full duplex terminal types
mentioned above is one such example. It also supports fixed and
mobile terminals, wideband and ultra-wideband terminals. Further,
beam level signaling is employed instead of carrier level
signaling. In beam level signaling, a user terminal is not tied to
a particular carrier in uplink. Network may allocate resources on
any uplink carrier dynamically based on availability and honoring
the switching constraints of the user terminal to switch
frequencies.
RLC/MAC Context
[0177] FIG. 8 illustrates the RLC MAC layer context of a satellite
system, according to example embodiments.
Downlink Burst and Public Information (PUI)
[0178] FIG. 9 illustrates an example MAC layer downlink burst and
public information (PUI), according to example embodiments.
[0179] The PUI carries the following set of information: [0180]
Modulation and coding scheme of the FEC blocks in the Private
Information (PRI) [0181] User identifier of the data carried in the
FEC blocks [0182] Uplink allocation [0183] User identifier [0184]
Power control bits [0185] Carrier index [0186] Number of assigned
consecutive transmissions [0187] Indication if additional
information present in PRI [0188] Block Boundary
[0189] This feature provides flexibility and fewer RLC/MAC headers,
i.e., less overhead. It indicates how the MAC layer should
interpret the multiple FEC blocks in the PRI. It indicates whether
the MAC layer byte stream straddle the FEC blocks. The field
indicates how the multiple FEC blocks are grouped as shown in the
figure below.
[0190] FIG. 10 illustrates an example MAC layer block boundary
encoding, according to example embodiments.
Downlink User Addressing and Terminal Power Consumption
[0191] The addressing scheme tries to minimize terminal battery
usage and the processing of downlink data not destined to UT. It
improves channel efficiency by filling up downlink bursts and
sending to multiple terminals at the same time. It also provides
low latency when scheduling terminals
Slot Assignment and Terminal Addressing
[0192] FIG. 11A illustrates an example slot assignment, according
to example embodiments. [0193] User terminal is provided [0194]
Slot Id and periodicity. i.e., slot#5 every 2 frames [0195] Or a
bitmap on 000000 000011. i.e., last 2 slots of every frame [0196]
Decision factors [0197] Terminal type and battery status [0198]
User demand, specifically any guaranteed bit traffic flows [0199]
Number of active flows and aggregate user demand [0200] More
efficient to transmit to terminals with similar channel condition
in the same burst [0201] Terminal bitmap can be updated and sent to
UT based on above factors
Terminal Addressing
[0202] Embodiments provide for a mixture of the 2 operating points
balancing throughput efficiency, low latency and terminal power
efficiency [0203] Unicast Addressing: [0204] A user identifier per
FEC block (4*16 bit user identifier) [0205] a terminal only
processes the FEC block when the address matches [0206] Multi-user
Addressing [0207] When assigning a slot to a terminal, a terminal
is also provided an identifier x from (0-63), only valid in the
assigned slot. Terminal address is 2 x
[0208] FIG. 11B illustrates an example terminal addressing,
according to example embodiments. [0209] Use of a 64bit user
identifier bitmap to instruct UT to decode FEC blocks [0210] Only
terminals with bit set need to decode FEC blocks. i.e., if terminal
address is 2 x and bit x is set
[0211] Terminal addressing space is 64*Periodicity (slots)
Radio Resource Management Protocol
[0212] RRC is based on LTE procedures with modifications for the
satellite environment. Use standard interfaces to the Evolved
Packet Core(EPC) network (36.413-S1AP, 36.423-X2AP, 24.301-NAS)
[0213] FIG. 12A illustrates the RRC control plane architecture of a
satellite system, according to example embodiments. [0214] RRC
context [0215] Resides in GW (SAN-C subsystem) and UT [0216]
Implements connection, bearer, mobility, resource management
functions [0217] Uses acknowledged mode bearers (PDCP, RLC-AM, MAC,
PHY) [0218] Also uses Common Control Channels for some procedures
[0219] Ciphering, integrity protection provided by PDCP [0220]
Carries NAS MM/SM signaling transparently [0221] Interfaces at 51
interface to LTE core (MME)
RRC State Model
[0222] Addition of RRC_PCH state enables UT dynamic DRX feature and
reduces time to data transfer state
[0223] FIG. 12B illustrates an example RRC state diagram, according
to example embodiments.
[0224] The RRC states and sub states can be categorized as follows
[0225] RRC Idle [0226] UT control plane not established [0227] No
UT context in SAN [0228] UT context exists in EPC (MME) if
EMM-Registered [0229] UT monitors BCCH, PCH [0230] Connection
establishment can be triggered by UT or by paging from EPC [0231]
RRC Connected [0232] Control and data bearers context established
[0233] UT context exists in EPC and in SAN [0234] a) RRC_ACTIVE
[0235] Radio resources assigned [0236] UT monitors assigned slots
in DL traffic channel [0237] UL/DL transmission can happen [0238]
b) RRC_PCH [0239] No radio resources assigned [0240] UT monitors
BCCH, PCH [0241] MAC layer reactivation can be triggered by UT or
by paging from SAN
UT Identifiers
[0242] Multiple UT identifiers are needed to identify and track UT
context at different levels and in different states
[0243] FIG. 12C illustrates RRC user terminal identifiers for
identifying and tracking UT context, according to example
embodiments. [0244] SAN-assigned [0245] RRC: [0246] S-RNTI
(Satellite Radio Network Temporary Id) [0247] GWID (8b)+Logical
SAN-C Id [7b]+UT Id [17b]-TBC [0248] MAC: [0249] MAC User id (16
bits) [0250] FL slot# (1-12), period (1-4?) and Slot-specific UT id
(6 bits)
SI Broadcast and CCCH Usage
[0250] [0251] BCCH: System Information (SI) [0252] At any time, SI
in a beam is broadcast by a single GW [0253] This primary GW
assignment changes as the satellite moves over different GW's
[0254] RACH [0255] RACH capacity can be shared by multiple GWs
[0256] RACHs arriving in a beam may be destined to different GWs
[0257] Default (primary) GW decides correct destination based on UT
type and location [0258] UT remembers assigned GW [0259] See "GW
Redirection" message flow for details [0260] AGCH, PCH [0261] AGCH
and PCH capacity can be shared by multiple GWs [0262] Capacity is
divided between GWs based on configuration
RRC Functions and Procedures
TABLE-US-00003 [0263] Function Procedure Messages Direction Bearer
System Information System Information broadcast BCCH segments DL
SRB0 broadcast NAS Information DL Information Transfer DL
Information Transfer DL SRB2 transfer UL Information Transfer UL
Information Transfer UL SRB2 Piggybacking NAS messages on certain
RRC messages RRC Connection Paging Paging DL SRB0 Management, RRC
Connection Establishment RRC Connection Establishment UL SRB0
Bearer Request Management Immediate Assignment DL SRB0 Immediate
Assignment Reject DL SRB0 RRC Connection Setup DL SRB1 RRC
Connection Setup Complete UL SRB1 RRC Connection Release RRC
Connection Release DL SRB1 MAC Activation MAC Activation Request UL
SRB0 MAC Activation Confirm DL SRB1 RRC Security Mode Security Mode
Command DL SRB1 Security Mode Complete UL SRB1 Security Mode
Failure UL SRB1 RRC Connection Reconfiguration RRC Connection
Reconfiguration DL SRB1 RRC Connection Reconftguration UL SRB1
Complete Position and Position Verification Position Verification
Request UL SRB0 Battery Reporting Position Verification Notify DL
SRB0 RRC Position Report RRC Position Report UL SRB1 RRC Position
Report Confirm DL SRB1
RRC Connection Establishment
[0264] UT uses this procedure to attach to the network on
power-on
[0265] FIG. 12D depicts a signal flow diagram illustrating RRC
connection establishment, according to example embodiments. [0266]
UT performs satellite and beam selection and camps on the selected
beam. [0267] UT transmits RRC Connection Request on RACH. If the UT
already knows its GW label (SAN-RC), it adds it, else it adds an
empty destination label for the satellite to fill. The UT also
supplies its GPS coordinates and S-TMSI (if available). [0268]
Satellite receives the RACH and examines the GW ID in the label. If
null, it fills in the default GW label to be used for RACH (points
to the SAN-RC). The satellite also adds the source info identifying
the (satellite, beam, carrier, frame, slot) and forwards to the
SAN-RC (via ISL and the RFT). [0269] SAN-R processes the RACH. This
includes checking the UT coordinates in the RACH to
determine/confirm the home GW and determine the TA (using GWSA),
fetching the UT satellite/beam trajectory (using EDF), determining
the SAN-C instance responsible for this UT (load balancing). SAN-RC
then forwards the request with all this data to the SAN-C. [0270]
SAN-C performs connection admission and creates the UT context,
stores the position and trajectory, assigns the UT identifier
(S-RNTI). SAN-C sends the Immediate Assignment on AGCH to the UT
via the satellite. The Immediate Assignment contains the timing
correction, forward timeslot assignment and MAC id, GW labels for
RACH and traffic (SAN-R). [0271] SAN-C sends the RRC Connection
Setup message on SRB1 via RFT and satellite to the UT. This
contains the MAC layer parameters for the UT, and other parameters
needed in connected state. This includes information about upcoming
beam & satellite handovers. [0272] UT sends the RRC Connection
Setup Complete message on SRB1 with selected PLMN Id, GUMMEI, and a
piggybacked NAS message. SAN-C sends the NAS message to the MME.
[0273] SAN-C sends an S1 INITIAL-UE message containing the UT's
local S1 AP Id, NAS message, the selected PLMN Id, GUMMEI, TAI,
etc. [0274] The NAS procedure proceeds. See next chart.
Attach and Bearer Setup
[0275] UT completes attach and default bearer is established
[0276] FIG. 12E depicts a signal flow diagram illustrating an RRC
attach and bearer setup procedure, according to example
embodiments. [0277] SAN-C sends an S1 INITIAL-UE message containing
the UT's local S1 AP Id, NAS ATTACH message, the selected PLMN Id,
GUMMEI, TAI, etc. (see previous chart). [0278] MME performs the NAS
Security Mode procedure (mutual authentication and key exchange)
with the UT. This is carried transparently in NAS Downlink/Uplink
Transport messages over S1 and over SRB1 in RRC DL/UL Information
Transfer messages. [0279] MME gives SAN-C the UT context info in
the S1Initial Context Setup Request message. This includes UT
security keys and the details of default E-RAB to be set up. It
also includes the NAS ATTACH ACCEPT message for the UT [0280] SAN-C
computes the ciphering and integrity protection keys and configures
the user plane (SAN-U PDCP). It also performs AS security
activation using the RRC Security Mode procedure over SRB1. [0281]
SAN-C performs bearer admission, establishes the radio bearers for
the default E-RAB indicated by the MME and for SRB2. The RRC
Connection Reconfiguration procedure is used to set up RBs. The RRC
Connection Reconfiguration includes the return SAN-RU label to be
used for data traffic. [0282] SAN-C replies to the MME with the S1
Initial Context Setup Response, indicating which bearers were set
up successfully or failed. Local GTP transport addresses &
TEIDs for the successful bearers is also included. [0283] UT
replies to the MME with NAS ATTACH COMPLETE. This is carried
transparently over SRB2 in RRC UL Information Transfer and over S1
in S1 Uplink NAS Transport messages
Transition to Idle on Inactivity
[0284] When the UT is idle for a few seconds, it transitions to
RRC_PCH. When the UT is idle for many minutes, it transitions from
RRC_PCH to RRC IDLE
[0285] FIG. 12F depicts a signal flow diagram illustrating an RRC
transition to idle mode, according to example embodiments. [0286]
SAN-R detects TBF inactivity and signals to the UT that the TBFs
are being released through MAC signaling. [0287] When the TBF
Release has been acknowledged by the UT, the SAN-R removes the MAC
layer state for the UT and informs the SAN-U. The SAN-U removes its
references to the SAN-R for this UT and informs the SAN-C that the
MAC has become inactive. The RBs, RLC and PDCP contexts remain. The
SAN-C changes the RRC state to RRC_PCH. The SAN-RU reference is
cleared, but the rest of the UT context is retained. [0288] On
extended inactivity, the SAN indicates to the EPC (MME) that it
wishes to release the UE context by sending a UE Context Release
Request with cause "user inactivity". The MME sends a S1 UE Context
Release Command. [0289] The SAN triggers SAN originated paging.
[0290] When the UT responds, the SAN sends the UT an RRC Connection
Release. The UT transitions to RRC Idle and sets its DRX interval
to the default value. [0291] The SAN sends the MME a S1 UE Context
Release Complete. The SAN also stores the UT's S-TMSI and last
reported position in a database for use in idle mode paging.
Paging Scenarios
[0292] Paging principles [0293] Paging applies in RRC Idle and
RRC_PCH states [0294] UT reports its position to SAN if it moves
more than [50 km] [0295] SAN determines satellites and beams to be
used to page at UT's last known position
TABLE-US-00004 [0295] UT NAS States UT RRC State Paging Mechanism
Comment EMM Deregistered RRC Idle None No data bearers, hence no
ECM Idle paging needed EMM Deregistered RRC Connected None
Transient state while ECM Idle attaching EMM Registered RRC Idle
EPC triggers paging by SAN stores UT's last ECM Idle MME-assigned
id (S-TMSI). reported coordinates when SAN pages based on UT's in
RRC Idle state to last reported coordinates. facilitate accurate
paging. EMM Registered RRC Connected None Transient state while ECM
Idle connecting EMM Registered RRC Connected: SAN triggers paging
by SAN stores UT's last reported ECM Connected RRC_PCH SAN-assigned
id (S-RNTI). coordinates in UT context SAN pages based on UT's when
in RRC_PCH state. last reported coordinates. EMM Registered RRC
Connected: None Active radio resources, ECM Connected RRC_ACTIVE
hence no paging needed
EPC Originated Paging
[0296] When the EPC has data to send, it pages the UT to request
RRC connection establishment.
[0297] FIG. 12G depicts a signal flow diagram illustrating RRC EPC
originated paging, according to example embodiments. [0298] While
in ECM_IDLE, the EPC (SGW) receives DL data for the UT and triggers
the MME to initiate paging. The MME sends S1 PAGING to all the
SAN-C's responsible for the TA. The message includes the UT
temporary ID (S-TMSI) and TA list (TAL). [0299] Only one of the
paged SAN-C's will be selected to do the paging. The SAN-C looks up
the last known location of that S-TMSI in the database and
determines the satellites/beams which cover that location (by
querying EDF). [0300] The SAN-C sends paging requests to the SAN-R
for each target satellite/beam with the S-TMSI and default DRX
interval for the UT. [0301] SAN-R schedules paging messages on the
PCH slots for the target UT depending on the current DRX interval
and sends them to the UT via the RFT and satellite. [0302] The UT
is monitoring its paging opportunities based on the default DRX
interval. It receives the S-TMSI based page and responds with a RRC
Connection Establishment Request with cause "Paging Response". The
RRC Connection Establishment completes and the UT initial context
is set up. [0303] The NAS Service Request is conveyed to the MME
within the S1 Initial UE message at the conclusion of the RRC
Connection Establishment. [0304] The NAS Service Request procedure
takes place. This is similar to the Attach procedure in that the
NAS authentication and security procedures take place and the
bearers are established. [0305] When the E-RAB for the required EPC
bearer context is established, the EPC (SGW) sends the queued
downlink data that triggered paging.
UT Originated MC Activation
[0306] When the UT has data to send, it requests MAC activation and
transitions to RRC_ACTIVE
[0307] FIG. 12H depicts a signal flow diagram illustrating an RRC
user terminal originated MAC activation, according to example
embodiments. [0308] While in RRC_PCH, the UT needs to transmit
uplink traffic so triggers the MAC Activation Request procedure. It
transmits a MAC Activation Request on RACH with cause "UL data".
The UT already knows its GW label (SAN-RC), so it adds it to the
message. [0309] Satellite receives the RACH, adds the source info
(satellite, beam, carrier, frame, slot) and forwards to the SAN-RC
(via ISL and the RFT). [0310] SAN-RC processes the RACH, which
includes looking up the TAI and beam/satellite trajectory for the
current UT position. The S-RNTI in the message contains the logical
SAN-C id. SAN-RC forwards the request with all this data to this
SAN-C. SAN-C sends the Immediate Assignment on AGCH to the UT via
the satellite. The Immediate Assignment contains the timing
correction, forward timeslot assignment and MAC id, GW labels for
RACH and traffic (SAN-R). [0311] SAN-C Sends the MAC Activation
Confirm message on SRB2 via SAN-U, SAN-R, RFT and satellite to the
UT. This contains the MAC layer parameters for the UT, and other
parameters needed in connected state. This includes information
about upcoming beam & satellite handovers. [0312] UT starts
monitoring the downlink channel for its assigned slot. When it
receives an uplink allocation, it sends the uplink data.
SAN Originated Paging
[0313] When the SAN has data to send, it pages the UT to request
MAC activation
[0314] FIG. 12I depicts a signal flow diagram illustrating an RRC
SAN originated paging, according to example embodiments. [0315]
While in RRC_PCH, the GW receives DL data from the EPC (SGW). The
SAN-U queues the data and requests the SAN-C to trigger paging.
[0316] SAN-C determines the satellites/beams to be paged based on
the last known UT position (by querying EDF). It sends paging
requests to the SAN-R with the S-RNTI and current DRX interval for
the UT. [0317] SAN-R schedules paging messages on the PCH slots for
the target UT depending on the current DRX interval and sends them
to the UT via the RFT and satellite. [0318] The UT is monitoring
its paging opportunities based on its current DRX interval. It
receives the S-RNTI based page and responds with a MAC Activation
Request with cause "Paging Response". The UT already knows its GW
label (SAN-R), so it adds it to the message. [0319] Satellite
receives the RACH, adds the source info (satellite, beam, carrier,
frame, slot) and forwards to the SAN-R (via ISL and the RFT).
[0320] SAN-R processes the RACH, which includes looking up the TAI
and beam/satellite trajectory for the current UT position. The
S-RNTI in the message contains the logical SAN-C id. SAN-R forwards
the request with all this data to this SAN-C. SAN-C sends the
Immediate Assignment on AGCH to SAN-RC. SAN-RC forwards it to the
UT via the satellite. The Immediate Assignment contains the timing
correction, forward timeslot assignment and MAC id, GW labels for
RACH (SAN-RC) and traffic (SAN-RU). [0321] SAN-C Sends the MAC
Activation Confirm message on SRB2 via SAN-U, SAN-R, RFT and
satellite to the UT. This contains the MAC layer parameters for the
UT, and other parameters needed in connected state. This includes
information about upcoming beam & satellite handovers. [0322]
UT starts monitoring the downlink channel for its assigned slot.
The SAN-U sends the queued downlink data that triggered paging.
Differentiated Quality Of Service
[0323] System and Air Interface signaling supports multiple levels
of QoS. Traffic classes supported consistent with that defined in
4G LTE standards [0324] Conversational Class [0325] Streaming Class
[0326] Interactive Class [0327] Background Class
[0328] Weighted Fair Queuing (WFQ) based scheduling algorithms is
proposed for QoS differentiation. Consistent treatment needed for
good Quality of Experience (QoE) across the network. This includes
[0329] UT-SAT link QoS [0330] SAT-SAT QoS [0331] SAT-GW QoS [0332]
Backbone QoS
Route Management
[0333] Route management in the system is proposed to be based on a
Route Determination Function (RDF) in the gateway. The RDF
determines the route that a packet has to take through the
constellation so that it is transmitted in the appropriate user
link downlink that the user terminal is communicating on. The basic
principles of route management is as follows and shown in Figure
RM-1: [0334] UT provides its position to satellite [0335] Satellite
forwards to appropriate Gateway based on UT position and/or Traffic
Engineering rules [0336] UT position also provided to Gateway
[0337] Gateway has binding between UT ID, its IP address (S1-AP ID)
and its last reported position [0338] In forward link, Gateway RDF
determines the satellite that covers UT position
[0339] FIG. 13A depicts a signal flow diagram illustrating a route
management determination, according to example embodiments.
[0340] Route management is inherently tied to mobility management.
As user terminals handover from beam to beam and satellite to
satellite, the RDF has to update its routes. Mobility Management
and Handover are described next.
Route Management Protocol
[0341] Routing Protocols: [0342] All the
routing/switching/forwarding mechanisms used to get packets between
UT and PDN [0343] Includes layers 2 & 3
[0344] FIG. 13B illustrates an example end-to-end routing protocol
stack structure, according to example embodiments.
APN IP Domain
[0345] Refers to addressing used between UTs and servers in APN(s)
[0346] Private, public or combination [0347] Multiple APN domains
isolated from each other and from GW internal IP domain [0348] UT
can be connected to multiple APNs at once [0349] And simultaneously
have an IP address in each one [0350] NAT can be deployed in EPC
P-GW [0351] Interface to Internet/data center via BGP router [0352]
IPv4 or IPv6 [0353] UT IP address assigned by P-GW [0354] P-GW can
assign from a private pool and perform NAT [0355] Can assign pools
per APN [0356] Completely isolated from GW internal IP domain
[0357] User IP packets are tunneled over end-to-end EPC bearers
[0358] Endpoints are P-GW and UT
[0359] FIG. 13C illustrates an example APN IP network domain
structure, according to example embodiments.
GW IP Domain
[0360] Refers to addressing used for IP communication between GW
components [0361] Private IP address space, e.g. 10.x.x.x [0362]
Subdivided by site (GW, NOC, etc.) [0363] Further subdivided by
functional group (management, user data, signaling, etc.) [0364]
Isolated from end-user (APN) address domain(s) [0365] Firewalled
access possible for management, support, etc.
GW Ethernet Domain
[0365] [0366] Refers to Ethernet switching layer used to
interconnect GW components [0367] Subdivided into individual
collision domains: [0368] SIF (Satellite Interface) domain [0369]
Used to interface to satellite constellation via RFTs [0370]
Interconnects neighbor GWs by means of L2VPNs [0371] Traffic VLANs
[0372] VLANs used to segregate other types of traffic, e.g. [0373]
SAN-R to SAN-U traffic [0374] SAN-U to EPC traffic [0375] EPC to
APN traffic [0376] Management traffic
[0377] FIG. 13D illustrates an example satellite interface domain
structure, and FIG. 13E illustrates an example gateway (GW) network
domain structure, according to example embodiments.
Mobility Management
[0378] For mobility management, it is assumed that [0379] Every
given orbit has to be seen by two or more geographically diverse
gateways [0380] For normal operation, while one gateway suffices,
two gateways are required for situations where one of them fails or
in a deep rain fade zone
[0381] At power ON, [0382] if no prior constellation ephemeris
information is stored in UT, [0383] UT scans for best possible
signal quality within the [+/-57 degree elevation] [0384] UT picks
best satellite in view [0385] User terminal sends Channel Request
on access channel with GPS location to the selected satellite after
reading system information; it also sends measurement report of the
satellites in view [0386] SAT determines destination gateway based
on policy (location, regulatory, traffic engineering etc.) [0387]
If destination gateway not in the orbit, [0388] SAT sends it to
closest Gateway [0389] Gateway (call it radio gateway) determines
if there exists a satellite in the constellation that the UT can
reach the intended gateway (that also meets the signal quality
criterion) [0390] If so, [0391] Radio Gateway sends back a message
to User Terminal about re-attempting on a different satellite
(provides necessary parameters) that helps reach the intended
gateway (this implies that a given gateway has information
regarding the geographical coverage area of neighboring gateway)
[0392] UT performs this request through the new satellite and
registers via this gateway (call it registered gateway) [0393] If
not, [0394] Radio Gateway creates a tunnel to the intended Gateway
and forwards the RRC Connection Request to the intended Gateway
(this becomes the Registered Gateway) [0395] RRC layer in
Registered Gateway responds to UT via the Radio Gateway [0396]
Gateway ID provided to the UT is the registered gateway. UT is also
informed of the "Via" Gateway in this case [0397] Subsequent
transmissions from UT will contain Via and Registered Gateway.
[0398] If SAT can reach the Registered Gateway directly, then SAT
forwards it to the registered gateway
[0399] FIG. 14A depicts a signal flow diagram illustrating call
flow messaging for initial registration and subsequent data
transfer call phases, according to example embodiments.
[0400] FIGS. 14B and 14C illustrate a routing change (not a
handover) occurring in the satellite due to handover on the gateway
link, according to example embodiments. In this case no handover
occurs in the user link. The respective figures illustrate the
following points. [0401] A given satellite beam may be providing
service to two different gateways; [0402] Need for satellite to
take appropriate switching decisions [0403] For normal traffic,
this decision is aided by user terminal indicating the registered
gateway in data that it transmits to satellite [0404] For terminals
that are registering or re-registering, satellite determines the
intended gateway [0405] Terminal remains connected to the gateway
with which it has registered [0406] In general, a satellite may
communicate with two gateways simultaneously [0407] There may be
cases where a gateway is too low of an elevation angle; in that
case cross link gets used to reach the intended gateway [0408]
While a UT is in session, the satellite may move such that the
gateway it is communicating is no longer visible to the satellite;
[0409] In this case, there is no beam handover, no satellite
handover, but there is an impact to the switching logic [0410] To
accomplish this switch, satellites advertise reachability of
Gateways to other satellites [0411] In addition, Gateways upload
switching tables to satellite
UT States
[0411] [0412] UT states determine what services a UT can get:
[0413] UT states are defined in [0414] RRC Layer [0415] Non-Access
Stratum (NAS) Layer [0416] RRC-Layer State [0417]
RRC-IdleRRC-Active [0418] RRC-PCH [0419] NAS Layer State [0420]
Evolved Packet System (EPS) Mobility Management (EMM) state [0421]
EPS Connection Management (ECM) state [0422] EMM State [0423]
EMM-Deregistered [0424] EMM-Registered [0425] ECM State [0426]
ECM-Idle [0427] ECM-Connected
UT Mobility Management Context
[0427] [0428] UT coverage change due to constellation movement
[0429] Supported by Beam/Satellite HO [0430] Movement of UT within
and between service areas [0431] Supported by Position Reporting,
Tracking Area Update and GW-GW HO [0432] GW coverage change due to
constellation movement [0433] Not addressed by RRC procedures, but
by satellite network layer (SNL) routing
[0434] FIG. 14D illustrates a user terminal mobility management
context structure, according to example embodiments.
Handovers
[0435] Each Gateway knows the satellites trajectories [0436] Each
Terminal reports its location [0437] Based on the terminal
location, Gateway estimates at what time the HO should be executed
[0438] This can be done in advanced since Gateways knows the
terminal location and the satellite movements [0439] Gateways sends
Sat/beam HO trajectory to UT so that UT knows when the HO will
happen [0440] MME involves in Gateway-Gateway HO since this HO
requires path switch between EPC entities and the new Gateway
[0441] Gateway-gateway HO mostly happens for moving terminal such
as air plane
There are Several HO Scenarios Described Here
[0441] [0442] Beam to Beam handover [0443] Satellite to Satellite
Handover [0444] Gateway to Gateway Handover
[0445] Beam to Beam Handover: FIG. 15A depicts a signal flow
diagram illustrating a beam to beam handover, according to example
embodiments.
[0446] Satellite to Satellite Handover: FIG. 15B depicts a signal
flow diagram illustrating the preparation phase of a satellite to
satellite handover, and FIG. 15C depicts a signal flow diagram
illustrating the data transfer phase of a satellite to satellite
handover, according to example embodiments.
[0447] Gateway to Gateway Handover (In this case, the satellite is
the same, however gateway handover was necessary): FIG. 15D depicts
a signal flow diagram illustrating the preparation phase of a
gateway to gateway handover, and FIG. 15E depicts a signal flow
diagram illustrating the data transfer phase of a gateway to
gateway handover, according to example embodiments.
[0448] High-level Gateway to Gateway Handover (with satellite
change): FIG. 15F illustrates a gateway to gateway handover, where
the user terminal is at one gateway, and FIG. 15G illustrates a
gateway to gateway handover, where the user terminal moves to
another gateway, according to example embodiments.
[0449] Gateway to Gateway Handover (where the satellites also
change)--The following uses X2 procedures similar to 4G LTE.
Gateway to Gateway handovers involving S1 interface procedures may
also be invoked if X2 interface is not available: FIG. 15H depicts
a signal flow diagram illustrating the preparation phase of a
gateway to gateway handover with a satellite change, and FIG. 15I
depicts a signal flow diagram illustrating the data transfer phase
of a gateway to gateway handover with a satellite change, according
to example embodiments;
Traffic Shaping in Gateway to Manage Buffers in Satellite
[0450] UT position is known in Gateway [0451] For a fixed UT, the
antenna gain pattern changes as the satellite moves [0452] there
could be 6 to 10 dB of gain variation [0453] Depending on the gain
at a user location, Adaptive Coding and Modulation gets invoked in
the forward link to that user in Ku-band user link [0454] This
implies that the forward link throughout for a given user varies as
the satellite moves [0455] When the throughput is low, the
satellite would therefore need to buffer [0456] To minimize
buffering requirements at the satellite, Gateway "shapes" the
traffic to a given user based on user location [0457] Gateway
reduces the rate at which transmits data to a given UT if Gateway
determines that the user-link satellite antenna gain is low and
vice-versa [0458] This is possible since gateway knows UT location
and Gateway also knows the forward link beam gain of the user-link
satellite [0459] This will therefore minimize buffering requirement
at the user-link satellite
Flow Control Between Satellite and Gateway
[0459] [0460] Traffic shaping helps minimize buffering requirement
based on UT location and user-link satellite forward link gain.
[0461] However there will be cases where the user link throughput
has to be throttled depending on non-deterministic factors such as
rain [0462] In this case, the buffers would start to grow in the
satellite [0463] To better manage the depth of queues in the
satellite, the user-link satellite implements a simple flow-control
mechanism with the Gateway [0464] Here the user-link satellite will
transmit the soft equivalent of RNR to Gateway [0465] This can be
done on satellite basis, beam-by-beam basis or user-by-user basis
[0466] When soft-RNR is received by the Gateway, the Gateway
throttles the rate at which it injects data towards user-link
satellite
Synchronization
[0467] The speed of the LEO/MEO satellite as observed from a
location on the earth is high. This high speed of the satellite
results in a large satellite motion induced Doppler. The goal of
the proposed synchronization scheme is to compensate for the large
Doppler offset by exploiting the deterministic nature of the
Doppler component.
Synopsis of the Proposed Scheme:
[0468] Synchronization task at the GW is aided by the knowledge
available at the GW of the LEO/MEO satellite ephemeris, and the
positions of the GW and of the UT. [0469] Similarly, the UT is
equipped with the knowledge of the LEO/MEO satellite ephemeris and
its position as well. [0470] To achieve the latter, the LEO/MEO
satellite ephemeris is broadcast by the GW on the forward link
[0471] Compared to an alternate scheme in which the predictable and
deterministic nature of the LEO/MEO satellite Doppler component is
not taken advantage of, the proposed synch approach: [0472] incurs
a small increase in the broadcast message overhead (due to the
provision of broadcasting the LEO/MEO satellite ephemeris), [0473]
while providing an increased efficiency in [0474] the UT's forward
link signal acquisition and handover measurement processes, [0475]
the Paging messaging transmission from the GW and the reception at
the UT, and [0476] GW's return link signal acquisition and handover
measurement processes
[0477] These increased efficiencies translate to [0478] Faster
times at the UT and at the GW for signal acquisition and for
satellite-to-satellite handover, [0479] a quicker response by the
UT to the GW's Paging messages, [0480] an improvement in the UT's
battery life (e.g., since the UT in the idle mode can be in the
sleep mode in between the assigned paging frames, and also because
the satellite/cell search is more efficient) [0481] a reduction in
the satellite power and bandwidth consumed to send Paging messages
to the UTs, and [0482] a reduced complexity of the GW and the UT
acquisition and tracking receivers
[0483] User link may be in one of the following states: [0484] Cold
Start [0485] Limited availability of satellite ephemeris, resulting
in large uncertainties in Doppler and timing [0486] May require at
the transmitter either (i) dedicated pilot/FCCH channel, or (ii) a
large preamble followed by a small message packet (e.g., RACH).
Similarly a receiver design with large acquisition window is needed
[0487] Warm Start [0488] Satellite ephemeris is available but may
not have been recently updated [0489] Links in partially
synchronized state [0490] Steady State (Idle and Connected Mode
Handovers) [0491] Accurate ephemeris, and estimates of delay and
Doppler, is available on both the ends of the link [0492] Guard
bands and acquisition windows are smallest
[0493] User Link--Forward link synchronization [0494] Satellite and
the UT both have a GPS disciplined oscillator [0495] Frequency
reference is locked to GPS [0496] Frame markers derived based on
GPS 1 pps timing ticks [0497] UT continually estimates the downlink
delay and Doppler using the LEO/MEO satellite ephemeris data [0498]
Downlink Timing Acquisition at the UT [0499] By adding the
estimated downlink delay to its GPS based 1 pps ticks, the UT
derives an estimate of the downlink frame markers [0500] UT opens
an acquisition window for the downlink frame timing around this
estimated frame marker [0501] Acquisition window is largest at the
cold start (may be continuous), smaller in the warm start, and
smallest in steady-state. [0502] Downlink Frequency Acquisition at
the UT [0503] By adding the estimated downlink Doppler to its GPS
disciplined frequency reference, the UT derives an estimate of the
downlink frequency [0504] UT opens an acquisition window centered
at this estimated downlink frequency [0505] Acquisition window is
largest at the cold start (may be continuous), smaller in the warm
start, and smallest in steady-state [0506] After the initial
acquisition, the downlink timing and frequency are continually
tracked by the UT receiver
[0507] User Link--Return link synchronization [0508] UT adds
Transmit Receive Offset (TRO) to the downlink timing and frequency
to derive the uplink timing and frequency [0509] TRO is dependent
on the user link RTD (Round Trip Delay) and RTDop (Round Trip
Doppler) [0510] TRO is initially self-computed by the UT given the
knowledge of the satellite ephemeris and its GPS position [0511] A
Closed Loop Correction (CLC) feature, such as the one in GMR-1, is
necessary to prevent run-off conditions due to inaccuracies in the
self-computed TRO at UT [0512] If the UT receives a TRO correction
from the satellite in the CLC message, it extrapolates this last
received TRO using the ephemeris data [0513] Therefore, in the
steady state, the UT's return link transmissions are synchronized
at the satellite [0514] A medium acquisition window preamble and a
large acquisition window preamble would be useful to serve "corner
cases" (warm/cold starts) [0515] To serve these cases, satellite
transmits the beam center delay and Doppler
Frame Numbering and Synchronization
[0516] FIG. 16A illustrates a diagram of the return link timing and
frame numbering synchronization, according to example embodiments.
The UT continually adjusts the Transmit Receive Offset (TRO) as
shown.
Half Duplex Operation
[0517] Half duplex terminals cannot simultaneously transmit and
receive [0518] As shown below, a switching time
.DELTA..sub.RX.fwdarw.TX is required for the UT to transition from
the receive to transmit (and vice versa, .DELTA..sub.TX.fwdarw.RX
is needed to switch from transmit to receive) [0519] A scheme for
synchronization and resource allocation with the above constraint
for the half duplex terminals is proposed
[0520] FIG. 16B illustrates a switching time for user terminal
transition from receive to transmit, according to example
embodiments. The satellite coverage area on the ground is divided
into multiple Half Duplex Divisioned (HDD) groups: [0521] Size of
the HDD group is determined by the duration of the packets assigned
to the UTs on downlink [0522] Return uplink resource is assigned to
the terminals in a given HDD group such that [0523] Terminals at
the edge of the HDD group nearest to the satellite end their uplink
transmission .DELTA..sub.TX.fwdarw.RX seconds before the beginning
of the downlink packet (see UT B Tx Timeline in the figure below)
[0524] Terminals at the edge of the HDD group farthest to the
satellite begin their uplink transmission .DELTA..sub.RX.fwdarw.X
seconds after the end of the downlink packet (see UT A Tx Timeline
in the figure below)
[0525] FIG. 16C illustrates synchronization for half duplex
operation where the satellite coverage area on the ground is
divided into multiple Half Duplex Divisioned (HDD) groups,
according to example embodiments. It can be shown that, for any
given duration of the packet(s) assigned to the UT on the downlink,
the proposed scheme maximizes the Half Duplex Resource Allocation
Efficiency (HDRAE): [0526] HDRAE (0.ltoreq.HDRAE.ltoreq.1) is
defined as the ratio of the time that the terminal is active (in
either transmitting or receiving) over the interval of time that
covers the UT's Rx.fwdarw.Tx.fwdarw.Rx transitions [0527] In the
example on the previous slide, over the three units of time (0, 1
and 2) that cover UT's Rx.fwdarw.Tx.fwdarw.Rx transitions, the
terminal is active over 2 units. Therefore, the HDRAE is 0.666.
This is the maximum attainable HDRAE given that the downlink
resource in this example occupies one unit of time.
[0528] Further, the HDRAE can be improved (such that it approaches
the maximum value of unity) by increasing the duration of the
packet resource assigned to the UT either on the downlink or on the
uplink. Two alternative example implementations may be as follows:
[0529] In one approach, the HDD groups are mapped to the formed
beams on the ground [0530] Although this may lead to suboptimal HDD
groups (especially for the beams larger in geographic size compared
to the size of the HDD group), an advantage is that a common
resource allocation rule can be applied for all the terminals in a
given beam [0531] In an alternate approach, the HDD groups are
defined independent of the beam. This requires the use of a
"terminal-location-aware" scheduler at the Gateway [0532] The
benefit of this approach is the use of optimally-defined HDD
groups. A drawback is that this requires a more complex scheduler
design at the GW (e.g., scheduler has to perform handover of a
given terminal from one HDD group to the next as the satellite
traverses in its orbit)
Gateway Synchronization Scheme
[0532] [0533] On the forward link, the timing, frequency, and frame
numbering of the frames transmitted by the GW are aligned at the
satellite to a GPS-derived system reference [0534] GW continuously
adjusts transmit timing and frequency of all the forward uplink
transmissions to each LEO/MEO satellite to compensate for the
feederlink delay and Doppler. [0535] GW calculates the required
transmission offsets from the ephemeris data, and applies the
calculated offsets to a system-level GPS derived synchronization
reference signal
[0536] FIG. 16D illustrates gateway timing synchronization, and
FIG. 16E illustrates a gateway frame numbering scheme for
synchronization, according to example embodiments.
UT-UT Direct Sessions
[0537] There may be some sessions that require direct communication
between user terminals without passing through the gateway. In such
a case, the Reassembly function of the RLC layer is selectively
implemented in satellite for those sessions that require direct
terminal to terminal communication without involvement of the
Gateway. In this case, security contexts and keys have to be
exchanged directly between two user terminals.
Gateway Architecture
[0538] Gateway architecture is based on 4G LTE radio network and
core network architecture, modified for satellite environment. Here
a Gateway has visibility to a number of LEO/MEO satellites
depending on the location of gateway. Each Gateway has a number of
tracking antennas in the V/Q band. FIG. 17A illustrates an example
gateway architecture, according to example embodiments.
[0539] Tracking antennas have the necessary radio modulation and
demodulation functions so that the baseband from multiple tracking
antennas may be transported to eNB's via optical fiber link. This
architecture therefore permits gateway diversity to mitigate rain
propagation effects. A diverse set of tracking antennas may be
placed several tens of miles away and the digital baseband signal
can be hauled via fiber to the common eNB. SGW, PGW and MME are
standard 4G LTE core network elements. As discussed earlier, a key
component of the Gateway is the Route Determination Function (RDF)
that is responsible for generating the appropriate labels for IP
packets to be transmitted to user terminals communicating via the
LEO/MEO constellation. This provides the centralized architecture
providing clear separation between control and user plane
functions. Various interfaces to the eNB' function of a given
Gateway is shown in Figure below.
[0540] FIG. 17B illustrates interfaces to an e-node B function of a
gateway, according to example embodiments. The gateway tracking
antennas may be steerable antennas or phased array antennas. For
the case of phased array antennas, it is possible to have a single
large array of antenna elements that form multiple beams tracking
multiple satellites.
[0541] While example embodiments of the present invention may
provide for various implementations (e.g., including hardware,
firmware and/or software components), and, unless stated otherwise,
all functions are performed by a CPU or a processor executing
computer executable program code stored in a non-transitory memory
or computer-readable storage medium, the various components can be
implemented in different configurations of hardware, firmware,
software, and/or a combination thereof. Except as otherwise
disclosed herein, the various components shown in outline or in
block form in the figures are individually well known and their
internal construction and operation are not critical either to the
making or using of this invention or to a description of the best
mode thereof.
[0542] In the preceding specification, various embodiments have
been described with reference to the accompanying drawings. It
will, however, be evident that various modifications may be made
thereto, and additional embodiments may be implemented, without
departing from the broader scope of the invention as set forth in
the claims that follow. The specification and drawings are
accordingly to be regarded in an illustrative rather than
restrictive sense.
* * * * *