<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!--
  XML2RFC offers an include feature described in the XML2RFC README
  file.  That syntax, however, contradicts the DTD requirements to
  have <reference> elements within the <references> element, so an 
  XML parser is likely to find your XML file invalid.  It may be
  possible that XML2RFC will change their DTD so that the XML file
  remains valid when their style of include is used.

  In the meantime therefore, we use an alternative valid-XML approach
  to includes, which unfortunately require that define your includes
  at the beginning of the file. Since the biggest benefit of includes
  is for references, this requires that your references be defined in
  ENTITY clauses here before being "included" and cited elsewhere in
  the file.
-->
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<!--
  This template is for authors of IETF specifications containing MIB
  modules.  This template can be used as a starting point to produce
  specifications that comply with the Operations &amp; Management Area
  guidelines for MIB module documents.
-->
<!--
  Throughout this template, the marker "[TODO]" is used to indicate an
  element or text that requires replacement or removal.
-->
<!-- Intellectual Property section -->
<!--
  The Intellectual Property section will be generated automatically by
  XML2RFC, based on the ipr attribute in the rfc element.
-->
<!-- 
  [TODO] specify the name of the output document. This is optional;
the default is to use the base portion of the XML filename. 
[TODO]For Internet-drafts, indicate which intellectual property notice 
to use per the rules of RFC3978.
Specify this in the ipr attribute.  The value can be:
    full3978 -
    noModification3978 -
    noDerivatives3978 -
[TODO] Specify the category attribute per RFC2026 
options are info, std, bcp, or exp.
[TODO] if this document updates an RFC, specify the RFC in the 
"updates" attribute
-->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-lhan-problems-requirements-satellite-net-03" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.9.0 -->
  <front>
    <!--
  Throughout this template, the marker "[TODO]" is used to indicate an
  element or text that requires replacement or removal.
-->

    <!--
[TODO] Enter the full document title and an abbreviated version
  to use in the page header.
-->

    <title abbrev="Problems, Requirements for Satellite Net">
	Problems and Requirements of Satellite Constellation for Internet</title>
    <seriesInfo name="Internet-Draft" value="draft-lhan-problems-requirements-satellite-net-03"/>
    <!-- [TODO] copy the author block as many times as needed, one for each author.-->

    <!-- If the author is acting as editor, use the <role=editor> attribute-->

    <!-- see RFC2223 for guidelines regarding author names -->

    <author fullname="Lin Han" initials="L" role="editor" surname="Han">
      <organization>Futurewei Technologies, Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <city>Santa Clara, CA 95050</city>
          <country>USA</country>
        </postal>
        <email>lhan@futurewei.com</email>
      </address>
    </author>
    <author fullname="Richard Li" initials="R" surname="Li">
      <organization>Futurewei Technologies, Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <city>Santa Clara, CA 95050</city>
          <country>USA</country>
        </postal>
        <email>rli@futurewei.com</email>
      </address>
    </author>
    <author fullname="Alvaro Retana" initials="A" surname="Retana">
      <organization>Futurewei Technologies, Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <city>Santa Clara, CA 95050</city>
          <country>USA</country>
        </postal>
        <email>alvaro.retana@futurewei.com</email>
      </address>
    </author>
    <author fullname="Meiling Chen" initials="M" surname="Chen">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>32, Xuanwumen West</street>
          <city>BeiJing 100053</city>
          <country>China</country>
        </postal>
        <email>chenmeiling@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Li Su" initials="L" surname="Su">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>32, Xuanwumen West</street>
          <city>BeiJing 100053</city>
          <country>China</country>
        </postal>
        <email>suli@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Tianji Jiang" initials="Tianji" surname="Jiang">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>1525 McCathy Blvd.</street>
          <city>Milpitas, CA 95035</city>
          <country>USA</country>
        </postal>
        <email>tianjijiang@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Ning Wang" initials="N" surname="Wang">
      <organization>University of Surrey</organization>
      <address>
        <postal>
          <street>Guildford</street>
          <city>Surrey, GU2 7XH</city>
          <country>UK</country>
        </postal>
        <email>n.wang@surrey.ac.uk</email>
      </address>
    </author>
    <!-- [TODO]: month and day will be generated automatically by XML2RFC; 
be sure the year is current.-->

    <date year="2022"/>
    <!--[TODO] IETF area is optional -->


    <area>Internet Area</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>Satellite</keyword>
    <keyword>Internet</keyword>
    <keyword>Constellation</keyword>
    <keyword>Relay</keyword>
    <!--[TODO] add additional keywords here for IETF website search engine -->

    <abstract>
      <t>This document presents the detailed analysis about the problems and requirements of satellite constellation used for Internet.
	  It starts from the satellite orbit basics, coverage calculation, then it
	  estimates the time constraints for the communications between satellite and ground-station, also between satellites.
	  How to use satellite constellation for Internet is discussed in detail including the satellite relay and satellite networking. 
	  The problems and requirements of using traditional network technology for satellite network integrating with Internet are finally outlined.</t>
      <!--Remember, don't put any citations in the abstract, and expand your acronyms. -->
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>Satellite constellation for Internet is emerging. 
	Even there is no constellation network established completely yet at the time of the publishing of the draft (June 2021), 
	some basic internet service has been provided and has demonstrated competitive quality
	to traditional broadband service. </t>
      <t>This memo will analyze the challenges for satellite network used in Internet by traditional routing and switching technologies. 
	It is based on the analysis of the dynamic characters of both ground-station-to-satellite and inter-satellite
	communications and its impact to satellite constellation networking. </t>
      <t>The memo also provides visions for the future solution, such as in routing and forwarding.</t>
      <t>The memo focuses on the topics about how the satellite network can work with Internet. It does not focus on physical layer technologies 
	(wireless, spectrum, laser, mobility, etc.) for satellite communication.</t>
      <t>
      </t>
    </section>
    <section anchor="Terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <!-- 2, line 143-->
  <dl newline="false" spacing="normal" indent="18">
        <dt>LEO</dt>
        <dd>Low Earth Orbit with the altitude from 180 km to 2000 km.</dd>
        <dt>VLEO</dt>
        <dd>Very Low Earth Orbit with the altitude below 450 km</dd>
        <dt>MEO</dt>
        <dd>Medium Earth Orbit with the altitude from 2000 km to 35786 km</dd>
        <dt>GEO</dt>
        <dd>Geosynchronous orbit with the altitude 35786 km</dd>
        <dt>GSO</dt>
        <dd>Geosynchronous satellite on GEO</dd>
        <dt>ISL</dt>
        <dd>Inter Satellite Link</dd>
        <dt>ISLL</dt>
        <dd>Inter Satellite Laser Link</dd>
        <dt>EIRP</dt>
        <dd>Effective isotropic radiated power</dd>
        <dt>P2MP</dt>
        <dd>Point to Multiple Points</dd>
        <dt>GS</dt>
        <dd>Ground Station, a device on ground connecting the satellite. In the document, GS will hypothetically 
	provide L2 and/or L3 functionality in addition to process/send/receive radio wave. It might be different as the reality that
	the device to process/send/receive radio wave and the device to provide L2 and/or L3 functionality could be separated.</dd>
        <dt>SGS</dt>
        <dd>Source ground station. For a specified flow, a ground station that will send data to a satellite through its uplink.</dd>
        <dt>DGS</dt>
        <dd>Destination ground station. For a specified flow, a ground station that is connected to a local network or Internet, 
	it will receive data from a satellite through its downlink and then forward to a local network or Internet.</dd>
        <dt>PGW</dt>
        <dd>Packet Gateway</dd>
        <dt>UPF</dt>
        <dd>User Packet Function</dd>
        <dt>PE router</dt>
        <dd>Provider Edge router</dd>
        <dt>CE router</dt>
        <dd>Customer Edge router</dd>
        <dt>P router</dt>
        <dd>Provider router</dd>
        <dt>LSA</dt>
        <dd>Link-state advertisement</dd>
        <dt>LSP</dt>
        <dd>Link-State PDUs</dd>
        <dt>L1</dt>
        <dd>Layer 1, or Physical Layer in OSI model <xref target="OSI-Model" format="default"/></dd>
        <dt>L2</dt>
        <dd>Layer 2, or Data Link Layer in OSI model <xref target="OSI-Model" format="default"/></dd>
        <dt>L3</dt>
        <dd>Layer 3, or Network Layer in OSI model <xref target="OSI-Model" format="default"/>, it is also called IP layer in TCP/IP model</dd>
        <dt>BGP</dt>
        <dd>Border Gateway Protocol <xref target="RFC4271" format="default"/></dd>
        <dt>eBGP</dt>
        <dd>External Border Gateway Protocol, two BGP peers have different Autonomous Number</dd>
        <dt>iBGP</dt>
        <dd>Internal Border Gateway Protocol, two BGP peers have same Autonomous Number</dd>
        <dt>IGP</dt>
        <dd>Interior gateway protocol, examples of IGPs include 
	Open Shortest Path First (OSPF <xref target="RFC2328" format="default"/>), Routing Information Protocol (RIP <xref target="RFC2453" format="default"/>), 
	Intermediate System to Intermediate System (IS-IS <xref target="RFC7142" format="default"/>) and Enhanced Interior Gateway Routing Protocol (EIGRP <xref target="RFC7868" format="default"/>).</dd>
      </dl>
    </section>
    <section anchor="Overview" numbered="true" toc="default">
      <name>Overview</name>
      <t>The traditional satellite communication system is composed of few GSO and ground stations.
For this system, each GSO  can cover 42% Earth's surface <xref target="GEO-Coverage" format="default"/>, so as few as three GSO can provide the global 
coverage theoretically. With so huge coverage, GSO only needs to amplify signals received from uplink of one ground station and relay to
the downlink of another ground station. There is no inter-satellite communications needed.
Also, since the GSO is stationary to the ground station, there is no mobility issue involved.</t>
      <t>Recently, more and more LEO and VLEO satellites have been launched, they attract attentions due to their advantages over GSO and MEO 
in terms of higher bandwidth, lower cost in satellite, launching, ground station, etc.
Some organizations <xref target="ITU-6G" format="default"/><xref target="Surrey-6G" format="default"/><xref target="Nttdocomo-6G" format="default"/>  
have proposed the non-terrestrial network using LEO, VLEO as important parts for 6G to extend the coverage of Internet.
SpaceX has started to build the satellite constellation called StarLink that will deploy over 10 thousand LEO and 
VLEO satellites finally <xref target="StarLink" format="default"/>. 
China also started to request the spectrum from ITU to establish a constellation that has 12992 satellites <xref target="China-constellation" format="default"/>.
European Space Agency (ESA) has proposed "Fiber in the sky" initiative to connect satellites with fiber network on Earth <xref target="ESA-HydRON" format="default"/>.</t>
      <t>When satellites on MEO, LEO and VLEO are deployed, the communication problem becomes more complicated than for GSO.
This is because the altitude of MEO/LEO/VLEO satellites are much lower. As a result, the coverage of each satellite is 
much smaller than for GSO, and the satellite is not relatively stationary to the ground. This will lead to:</t>
      <ol spacing="normal" type="1"><li>More satellites than GSO are needed to provide the global coverage. <xref target="DynamicCoverage" format="default"/> will analyze the 
	coverage area, and the minimum number of satellites required to cover the earth surface.</li>
        <li>The point-to-point communication between satellite and ground station will not be static. Mobility issue has to be considered.
Detailed analysis will be done in <xref target="StationSatelliteCommunication" format="default"/>.</li>
        <li>The inter-satellite communication is needed, and all satellites need to form a network. details are described in 
 <xref target="InterSatelliteCommunication" format="default"/>. </li>
      </ol>
      <t>In addition to above context, <xref target="ProblemsSatelliteConstellationForInternet" format="default"/> will address the problem and requirements
when satellite constellation is joining Internet.</t>
      <t>As the 1st satellite constellation company in history, the SpaceX/StarLink will be inevitably mentioned in the draft. 
But it must be noted that all information about SpaceX/StarLink in the draft are from public. Authors of the draft have no relationship 
or relevant inside knowledge of SpaceX/Starlink. </t>
    </section>
    <section anchor="Basics" numbered="true" toc="default">
      <name>Basics of Satellite Constellation</name>
      <t>This section will introduce some basics for satellite such as orbit parameters, coverage estimation, 
minimum number of satellite and orbit plane required, real deployments.</t>
      <section anchor="Orbit" numbered="true" toc="default">
        <name>Satellite Orbit</name>
        <t>The orbit of a satellite can be either circular or ecliptic, it can be described by following Keplerian elements <xref target="KeplerianElement" format="default"/>: </t>
        <ol spacing="normal" type="1">
		  <li>Inclination (i) </li>
          <li>Longitude of the ascending node (Omega)</li>
          <li>Eccentricity (e)</li>
          <li>Semimajor axis (a)</li>
          <li>Argument of periapsis (omega)</li>
          <li>True anomaly (nu)</li>
        </ol>
        <t>For a circular orbit, two parameters, Inclination and Longitude of the ascending node, will be enough to describe the orbit.</t>
      </section>
      <section anchor="DynamicCoverage" numbered="true" toc="default">
        <name>Coverage of LEO and VLEO Satellites and Minimum Number Required</name>
        <t>The coverage of a satellite is determined by many physical factors, such as spectrum, transmitter power, the antenna size, 
the altitude of satellite, the air condition, the sensitivity of receiver, etc. EIRP could be used to measure the real power 
distribution for coverage. It is not deterministic due to too many variants in a real environment.
The alternative method is to use the minimum elevation angle from user terminals or gateways to a satellite. This is easier and 
more deterministic. <xref target="SpaceX-Non-GEO" format="default"/> has suggested originally the minimum elevation angle of 35 degrees and deduced the radius 
of the coverage area is about 435km and 1230km for VLEO (altitude 335.9km) and LEO (altitude 1150km) respectively. 
The details about how the coverage is calculated from the satellite elevation angle can be found in <xref target="Satellite-coverage" format="default"/>.</t>
        <t>Using this method to estimate the coverage, we can also estimate the minimum number of satellites required to cover the earth surface.</t>
        <t>It must be noted, SpaceX has recently reduced the required minimum elevation angle from 35 degrees to 25 degrees. The following analysis 
still use 35 degrees.</t>
        <t>Assume there is multiple orbit planes with the equal angular interval across the earth surface 
   (The Longitude of the ascending node for sequential orbit plane is increasing with a same angular interval).
   Each orbit plane will have:</t>
        <ol spacing="normal" type="1"><li>The same altitude.</li>
          <li>The same inclination of 90 degree.</li>
          <li>The same number of satellites.</li>
        </ol>
        <t>With such deployment, all orbit planes will meet at north and south pole. The density of satellite is not equal. Satellite is more
dense in the space above the polar area than in the space above the equator area. Below estimations are made in the worst covered area, 
or the area of equator where the satellite density is the minimum.</t>
        <t><xref target="Fig-Satellite-coverage"/> illustrates the coverage area on equator area, and each satellite will cover one hexagon area.
The figure is based on plane geometry instead of spherical geometry for simplification, so, the orbit is parallel approximately.</t>
        <t><xref target="Fig-Satellite-coverage-estimation"/> shows how to calculate the radius (Rc) of coverage area  from the satellite altitude (As)
and the elevation angle (b).</t>
        <figure anchor="Fig-Satellite-coverage">
		<name>Satellite coverage on ground</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
                       x
            |          |
            |          |
            x      *********
            |     *    |    *
            |    *     |     *
        *********      x      *
       *    |    *     |     *
      *     |     *    |    *
     *      x      *********
      *     |     *    |
       *    |    *     |
        *********      x
            |          |
            |       orbit 2          ^ north
            x                        |
            |                        |
            |                        |
          orbit 1                    +-------> east

]]></artwork>

        </figure>

        <figure anchor="Fig-Satellite-coverage-estimation">
		<name>Satellite coverage estimation</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[

        |<---  2*Rc --->|
                
                + Satellite
               /|
              / |
             /  |
            / b |
           /-\  +
          /   * |     __Earth surface
         /  *   |    /
        / *_----+----__
        +               +
         *             * 
          *           *
           *   2*a   *
            *  ___  *
             *-   -*
              *   *
               * *  
                * Earth center
]]></artwork>

        </figure>


        <dl newline="false" spacing="normal" indent="4">
          <dt>x</dt>
          <dd>The vertical projection of satellite to Earth</dd>
          <dt>Re</dt>
          <dd>The radius of the Earth, Re=6378(km)</dd>
          <dt>As</dt>
          <dd>The altitude of a satellite</dd>
          <dt>Rc</dt>
          <dd>The radius (arc length) of the coverage, or, the arc length of hexagon center to its 6 vertices. 
    Rc=Re*(a*pi)/180</dd>
          <dt>a</dt>
          <dd>The cap angle for the coverage area (the RC arc).
    a = arccos((Re/(Re+As))*cos(b))-b.</dd>
          <dt>b</dt>
          <dd>The least elevation angle that a ground station or a  
	terminal can communicate with a satellite, b = 35 degree.</dd>
          <dt>Ns</dt>
          <dd>The minimum number of satellites on one orbit plane, it is equal to the  
    number of the satellite's vertical projection on Earth, so, Ns = 180/(a*cos(30))</dd>
          <dt>No</dt>
          <dd>The minimum number of orbit (with same inclination), 
    it is equal to the number of the satellite orbit's vertical projection, so, No = 360/(a*(1+sin(30)))</dd>
        </dl>
        <t>For a example of two type of satellite LEO and VEO, the coverages are calculated as in <xref target="Table-Satellite-coverage" format="default"/>:</t>
        <table anchor="Table-Satellite-coverage" align="center">
          <name>Satellite coverage estimation for LEO and VLEO examples</name>
          <thead>
            <tr>
              <th align="center">Parameters</th>
              <th align="center">VLEO1</th>
              <th align="center">VLEO2</th>
              <th align="center">LEO1</th>
              <th align="center">LEO2</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">As(km)</td>
              <td align="center">335.9</td>
              <td align="center">450</td>
              <td align="center">1100</td>
              <td align="center">1150</td>
            </tr>
            <tr>
              <td align="center">a(degree)</td>
              <td align="center">3.907</td>
              <td align="center">5.078</td>
              <td align="center">10.681</td>
              <td align="center">11.051</td>
            </tr>
            <tr>
              <td align="center">Rc(km)</td>
              <td align="center">435</td>
              <td align="center">565</td>
              <td align="center">1189</td>
              <td align="center">1230</td>
            </tr>
            <tr>
              <td align="center">Ns</td>
              <td align="center">54</td>
              <td align="center">41</td>
              <td align="center">20</td>
              <td align="center">19</td>
            </tr>
            <tr>
              <td align="center">No</td>
              <td align="center">62</td>
              <td align="center">48</td>
              <td align="center">23</td>
              <td align="center">22</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="Deployment" numbered="true" toc="default">
        <name>Real Deployment of LEO and VLEO for Satellite Network</name>
        <t>Obviously, the above orbit parameter setup is not optimal since the sky in the polar areas will have the highest density of satellite.</t>
        <t>In the real deployment, to provide better coverage for the areas with denser population, to get redundance and better signal quality, 
and to make the satellite distance within the range of inter-satellite communication (2000km <xref target="Laser-communication-range" format="default"/>), 
more than the minimum number of satellites are launched. For example, 
different orbit planes with different inclination/altitude are used.</t>
        <t>Normally, all satellites are grouped by orbit planes, each group has a number of orbit planes and each orbit plane has the same orbit
parameters, so, each orbit in the same group will have:</t>
        <ol spacing="normal" type="1"><li>The same altitude</li>
          <li>The same inclination, but the inclination is less than 90 degrees. This will result in the empty coverage for polar areas and
	better coverage in other areas. See the orbit picture for phrase 1 for <xref target="StarLink" format="default"/>. </li>
          <li>The same number of satellites</li>
          <li>The same moving direction for all satellites</li>
        </ol>
        <t>The proposed deployment of SpaceX can be seen in <xref target="SpaceX-Non-GEO" format="default"/> for StarLink.</t>
        <t>The China constellation deployment and orbit parameters can be seen in <xref target="China-constellation" format="default"/>.</t>
      </section>
    </section>
    <section anchor="CommForSatelliteConstellation" numbered="true" toc="default">
      <name>Communications for Satellite Constellation</name>
      <t>Unlike the communication on ground, the communication for satellite constellation is much more complicated.
There are two mobility aspects, one is between ground-station and satellite, another is between satellites.</t>
      <t>In the traditional mobility communication system, only terminal is moving, the mobile core network including base station, front haul and back haul
are static, thus an anchor point, i.e., PGW in 4G or UPF in 5G, can be selected for the control of mobility session. Unfortunately, when satellite constellation joins the static
network system of Internet on ground, there is no such anchor point can be selected since the whole satellite constellation network is moving.</t>
      <t>Another special aspect that can impact the communication is that the fast moving speed of satellite will cause frequent changes of
communication peers and link states, this will make big challenges to the network side for the packet routing and delivery, session control and management, etc.</t>
      <section anchor="StationSatelliteCommunication" numbered="true" toc="default">
        <name>Dynamic Ground-station-Satellite Communication</name>
        <t>All satellites are moving and will lead to the communication between ground station and satellite can only last a certain period of time.
This will greatly impact the technologies for the satellite networking.
Below illustrates the approximate speed and the time for a satellite to pass through its covered area.</t>
        <t>In <xref target="Table-Time-Satellite-Station-Com" format="default"/>, VLEO1 and LEO3 have the lowest and highest altitude 
respectively, VLEO2 is for the highest altitude for VLEO. We can see that longest communication time of ground-station-satellite is 
less than 400 seconds, the longest communication time for VLEO ground-station-satellite is less than 140 seconds.</t>
<t>The "longest communication time" is for the scenario that the satellite will fly over the receiver ground
station exactly above the head, or the ground station will be on the diameter line of satellite 
coverage circular area, see <xref target="Fig-Satellite-coverage"/>.</t>

        <dl newline="false" spacing="normal" indent="4">
          <dt>Re</dt>
          <dd>The radius of the Earth, Re=6378(km)</dd>
          <dt>As</dt>
          <dd>The altitude of a satellite</dd>
          <dt>AL</dt>
          <dd>The arc length(in km) of two neighbor satellite on the same orbit plane, AL=2*cos(30)*(Re+As)*(a*pi)/180</dd>
          <dt>SD</dt>
          <dd>The space distance(in km) of two neighbor satellite on the same orbir plane, SD=2*(Re+As)*sin(AL/(2*(Re+As))).</dd>
          <dt>V</dt>
          <dd>the velocity (in m/s) of satellite, V=sqrt(G*M/(Re+As))</dd>
          <dt>G</dt>
          <dd>Gravitational constant, G=6.674*10^(-11)(m^3/(kg*s^2))</dd>
          <dt>M</dt>
          <dd>Mass of Earth, M=5.965*10^24 (kg)</dd>
          <dt>T</dt>
          <dd>The time (in second) for a satellite to pass through its cover area, or, 
	the time for the station-satellite communication. T= ALs/V</dd>
        </dl>
        <table anchor="Table-Time-Satellite-Station-Com" align="center">
          <name>The time for the ground-station-satellite communication</name>
          <thead>
            <tr>
              <th align="center">Parameters</th>
              <th align="center">VLEO1</th>
              <th align="center">VLEO2</th>
              <th align="center">LEO1</th>
              <th align="center">LEO2</th>
              <th align="center">LEO3</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">As(km)</td>
              <td align="center">335.9</td>
              <td align="center">450</td>
              <td align="center">1100</td>
              <td align="center">1150</td>
              <td align="center">1325</td>
            </tr>
            <tr>
              <td align="center">a(degree)</td>
              <td align="center">3.907</td>
              <td align="center">5.078</td>
              <td align="center">10.681</td>
              <td align="center">11.051</td>
              <td align="center">12.293</td>
            </tr>
            <tr>
              <td align="center">AL(km)</td>
              <td align="center">793</td>
              <td align="center">1048</td>
              <td align="center">2415</td>
              <td align="center">2515</td>
              <td align="center">2863</td>
            </tr>
            <tr>
              <td align="center">SD(km)</td>
              <td align="center">792.5</td>
              <td align="center">1047.2</td>
              <td align="center">2404</td>
              <td align="center">2503.2</td>
              <td align="center">2846.1</td>
            </tr>
            <tr>
              <td align="center">V(km/s)</td>
              <td align="center">7.7</td>
              <td align="center">7.636</td>
              <td align="center">7.296</td>
              <td align="center">7.272</td>
              <td align="center">7.189</td>
            </tr>
            <tr>
              <td align="center">T(s)</td>
              <td align="center">103</td>
              <td align="center">137</td>
              <td align="center">331</td>
              <td align="center">346</td>
              <td align="center">398</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="InterSatelliteCommunication" numbered="true" toc="default">
        <name>Dynamic Inter-satellite Communication</name>
      <section anchor="InterSatelliteCommunicationOverview" numbered="true" toc="default">
        <name>Inter-satellite Communication Overview</name>
        <t>In order to form a network by satellites, there must be an inter-satellite communication.
Traditionally, inter-satellite communication uses the microwave technology, but it has following disadvantages:</t>
        <ol spacing="normal" type="1">
		  <li>Bandwidth is limited and only up to 600M bps <xref target="Microwave-vs-Laser-communication" format="default"/>.</li>
          <li>Security is a concern since the microwave beam is relatively wide and it is easy for 3rd party to sniff or attack.</li>
          <li>Big antenna size.</li>
          <li>Power consumption is high.</li>
          <li>High cost per bps.</li>
        </ol>
        <t>Recently, laser is used for the inter-satellite communication, it has following advantages, and will be the future for
inter-satellite communication.</t>
        <ol spacing="normal" type="1"><li>Higher bandwidth and can be up to 10G bps <xref target="Microwave-vs-Laser-communication" format="default"/>.</li>
          <li>Better security since the laser beam size is much narrower than microwave, it is harder for sniffing.</li>
          <li>The size of optical lens for laser is much smaller than microwave's antenna size.</li>
          <li>Power saving compared with microwave.</li>
          <li>Lower cost per bps.</li>
        </ol>
        <t>The range for satellite-to-satellite communications has been estimated to be approximately 2,000 km currently <xref target="Laser-communication-range" format="default"/>.</t>
        <t>From <xref target="Table-Time-Satellite-Station-Com" format="default"/>, we can see the Space Distance (SD) for some LEO (altitude over 1100km) 
are exceeding the celling of the range of laser communication, 
so, the satellite and orbit density for LEO need to be higher than the estimation values in the <xref target="Table-Satellite-coverage" format="default"/>.</t>
        <t>Assume the laser communication is used for inter-satellite communication, then we can analyze the lifetime of inter-satellite communication
when satellites are moving.
The <xref target="Fig-Satellite-moving" format="default"/> illustrates the movement and relative position of satellites on three orbits.
The inclination of orbit planes is 90 degrees.</t>
        <figure anchor="Fig-Satellite-moving">
		<name>Satellite movement</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
                       + North pole
                      /|\
                     | s |
                    s  |  s
                   /   s   \
                   s   |   s
                   |   s1  |   
                   s4  |   s6
                   |   s2  |   -------- Equator
                   s5  |   s7 
                   |   s3  |
                   s   |   s
                   \   s   /
                    s  |  s
                     | s |
                      \|/      
                       +  South pole        
]]></artwork>
        </figure>


        <t>There are four scenarios:</t>
		
        <dl newline="true" spacing="normal" indent="4">
          <dt>1. For satellites within the same orbit</dt>
          <dd>
		  The satellites in the same orbit will move to the same direction with the same speed, 
		  thus the interval between satellites is relatively steady.
		  Each satellite can communicate with its front and back neighbor 
		  satellite as long as satellite's orbit is maintained in its life cycle.
		  For example, in <xref target="Fig-Satellite-moving" format="default"/>, 
		  s2 can communication with s1 and s3.</dd>
          <dt>2. For satellites between neighbor orbits in the same group at non-polar areas</dt>
          <dd>
		  The orbits for the same group will share the same orbit altitude and inclination. 
		  So, the satellite speed in different orbit are also
		  same, but the moving direction may be same or different. 
		  <xref target="Fig-Satellite-Same-Altitude-Move-in-Opposite-Direction"/> 
		  illustrates this scenario.
          When the moving direction is the same, it is similar to the scenario 1, the relative 
		  position of satellites in different orbit are relatively 
          steady as long as satellite's orbit is maintained in its life cycle. 
          When the moving direction is different, the relative position of satellites in different orbit 
          are un-steady, this scenario will be analyzed in more details 
          in <xref target="AdjacentOrbitWithSameAltitude" format="default"/>.
          </dd>
		  <dt>3. For satellites between neighbor orbits in the same group at polar areas</dt>
          <dd>For satellites between neighbor orbits with the same speed and moving direction,
		  the relative position is steady as described in #2 above, 
		  but the steady position is only valid at areas other than polar area.
		  When satellites meet in the polar area, the relative position will change dramatically.
		  <xref target="Fig-Satellite-at-Polar-Area"/> shows two satellites meet in polar area
		  and their ISL facing will be swapped. So, if the range of laser pointing angle 
		  is 360 degrees and tracking technology supports, the ISL will not be flipping 
          after passing polar area; Otherwise, the link will be flipping and inter-satellite
		  communication will be interrupted.</dd>
          <dt>4. For satellites between different orbits in the different group</dt>
          <dd>
		  The orbits for the different group will have different orbit altitude, inclination and speed. So, the relative position of satellite
is not static. The inter-satellite communication can only last for a while when the distance between two satellite is within the limit
of inter-satellite communication, that is 2000km for laser <xref target="Laser-communication-range" format="default"/>,
this scenario will be analyzed in more details in <xref target="AdjacentOrbitWithDifferentAltitude" format="default"/></dd>
		
		</dl>

		<figure anchor="Fig-Satellite-Same-Altitude-Move-in-Opposite-Direction">
		<name>Two satellites with same altitude and inclination (i) move in the same or opposite direction</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
            i+N/2         i+1+N/2       i+2+N/2
          / \           / \           / \
         /   \         /   \         /   \
        S1    \       S2    \       S3    \
       /       S4    /      S5     /      S6
      /         \   /         \   /         \
     /           \ /           \ /           \
     i-1           i             i+1

* The total number of orbit planes are N
* The number (i-1, i, i+1,...) represents the Orbit index
* The bottom numbers (i-1, i, i+1) are for orbit planes on 
  which satellites (S1, S2, S3) are moving from bottom to up.
* The top numbers (i+N/2, i+1+N/2, i+2+N/2) are for orbit 
  planes on which satellites (S4, S5, S6) are moving from up 
  to bottom.

]]></artwork>
        </figure>

        <figure anchor="Fig-Satellite-at-Polar-Area">
		<name>Two satellites meeting in the polar area will change its facing of ISL</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
             \      /
              P3   P4
               \  /
                \/
                /\
               /  \
              P1   P2
             /      \

* Two satellites S1 and S2 are at position P1 and P2 at time T1 
* S1's right facing ISL connected to S2's left facing ISL
* S1 and S2 move to the position P4 and P3 at time T2
* S1's left facing ISL connected to S2's right facing ISL 
]]></artwork>
        </figure>
		
      </section>
	    <section anchor="AdjacentOrbitWithSameAltitude" numbered="true" toc="default">
        <name>Satellites on Adjacent Orbit Planes with Same Altitude</name>
		<t> For satellites on different orbit planes with same altitude, 
		the estimation of the lifetime when two satellite can communicate are as follows.</t>
        <t><xref target="Fig-Satellite-Intersection-Same-Altitude" format="default"/> illustrates 
		a general case that two satellites move and intersect with an angle A.</t>
        <figure anchor="Fig-Satellite-Intersection-Same-Altitude">
		<name>Two satellites (speed vector V1 and V2) intersect with angle A</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
		  
                  ^ V2
                 /
                / 
               +-
              /  \ A
-------------+----+----> V1
            /
           /
          
]]></artwork>
        </figure>

<t>More specifically, for orbit planes with the inclination angle i, 
<xref target="Fig-Satellite-Intersection-With-Inclination" format="default"/> illustrates 
		two satellites move in the opposite direction and intersect with an angle 2*i.</t>
        <figure anchor="Fig-Satellite-Intersection-With-Inclination">
		<name>Two satellites with same altitude and inclination (i) intersect with angle A=2*i</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
                     ^ move from south to north
             \      /
              \    /
               \  /\  
                \/  | A = 2*i
                /\  |
               /  \/
              /    \
             /      V move from north to south
]]></artwork>
        </figure>

<t>Follows are the math to calculate the lifetime of communication. 
<xref target="Table-Intersects-Same-Alt"/> are the results using the math for two satellites 
with different altitudes and different inclination angles.</t>       
        <dl newline="false" spacing="normal" indent="4">
          <dt>Dl</dt>
          <dd>The laser communication limit, Dl=2000km <xref target="Laser-communication-range" format="default"/></dd>
          <dt>A</dt>
          <dd>The angle between two orbit's vertical projection on Earth. A=2*i</dd>
          <dt>V1</dt>
          <dd>The speed vector of satellite on orbit1</dd>
          <dt>V2</dt>
          <dd>The speed vector of satellite on orbit2</dd>
          <dt>|V|</dt>
          <dd>the magnitude of the difference of two speed vector V1 and V2, |V|=|V1-V2|=sqrt((V1-V2*cos(A))^2+(V2*sin(A))^2).
		  For satellites with the same altitude and inclination angle i, V1=V2, so, |V|=V1*sqrt(2-2*cos(2*i))=2V1*sin(i)</dd>
          <dt>T</dt>
          <dd>The lifetime two satellites can communicate, or the time of two satellites' distance is within the range of communication, 
	T = 2*Dl/|V|. </dd>
        </dl>

        <table anchor="Table-Intersects-Same-Alt" align="center">
          <name>The lifetime of communication for two LEOs (with two altitudes and three inclination angles)</name>
          <thead>
            <tr>
              <th align="center">i (degree)</th>
              <th align="center">80</th>
              <th align="center">80</th>
              <th align="center">65</th>
              <th align="center">65</th>
              <th align="center">50</th>
              <th align="center">50</th>
            </tr>
            <tr>
              <th align="center">Alt (km)</th>
              <th align="center">500</th>
              <th align="center">800</th>
              <th align="center">500</th>
              <th align="center">800</th>
              <th align="center">500</th>
              <th align="center">800</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">|V| (km/s)</td>
              <td align="center">14.98</td>
              <td align="center">14.67</td>
              <td align="center">13.79</td>
              <td align="center">13.5</td>
              <td align="center">11.66</td>
              <td align="center">11.41</td>
            </tr>
            <tr>
              <td align="center">T(s)</td>
              <td align="center">267</td>
              <td align="center">273</td>
              <td align="center">290</td>
              <td align="center">296</td>
              <td align="center">343</td>
              <td align="center">350</td>
            </tr>
          </tbody>
        </table>
		
	    </section>
	    <section anchor="AdjacentOrbitWithDifferentAltitude" numbered="true" toc="default">
        <name>Satellites on Adjacent Orbit Planes with Different Altitude</name>
        
		<t> For satellites on different orbit planes with different altitude, 
		the estimation of the lifetime when two satellite can communicate are as follows.</t>
        <t><xref target="Fig-Satellite-Intersection" format="default"/> illustrates 
		two satellites (with the altitude difference Da) move and intersect with an angle A.</t>
        <figure anchor="Fig-Satellite-Intersection">
		<name>Satellite (speed vector V1 and V2, Altitude difference Da) intersects with Angle A</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
                ^ V2
               /
              /  
      -------+  / 
      Da    /| +-
           / |/  \ A
----------/--+----+----> V1
         /  /
           /
          /
         /
]]></artwork>
        </figure>

<t>Follows are the math to calculate the lifetime of communication</t>
        <dl newline="false" spacing="normal" indent="4">
          <dt>Dl</dt>
          <dd>The laser communication limit, Dl=2000km <xref target="Laser-communication-range" format="default"/></dd>
          <dt>Da</dt>
          <dd>Altitude difference (in km) for two orbit planes</dd>
          <dt>A</dt>
          <dd>The angle between two orbit's vertical projection on Earth</dd>
          <dt>Vl</dt>
          <dd>The speed vector of satellite on orbit 1</dd>
          <dt>V2</dt>
          <dd>The speed vector of satellite on orbit 2</dd>
          <dt>|V|</dt>
          <dd>the magnitude of the difference of two speed vector V1 and V2, |v|=|V1-V2|=sqrt((V1-V2*cos(A))^2+(V2*sin(A))^2)</dd>
          <dt>T</dt>
          <dd>The lifetime two satellites can communicate, or the time of two satellites' distance is within the range of communication, 
	T = 2*sqrt(Dl^2-Da^2)/|V|</dd>
        </dl>
        <t>Using formulas above, below is the estimation for the life of communication of two satellites when they intersect.
  <xref target="Table-Two-VLEO" format="default"/> and <xref target="Table-Two-VLEO-Intersects" format="default"/> are for two VLEOs with the difference of 114.1km for altitude.
  (VLEO1 and VLEO2 on <xref target="Table-Time-Satellite-Station-Com" format="default"/>).
  <xref target="Table-Two-LEO" format="default"/> and <xref target="Table-Two-LEO-Intersects" format="default"/> are for two LEOs with the difference of 175km for altitude
  (LEO2 and LEO3 on <xref target="Table-Time-Satellite-Station-Com" format="default"/>). </t>

        <table anchor="Table-Two-VLEO" align="center">
          <name>Two VLEO with different altitude and speed</name>
          <thead>
            <tr>
              <th align="center">Parameters</th>
              <th align="center">VLEO1</th>
              <th align="center">VLEO2</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">As(km)</td>
              <td align="center">335.9</td>
              <td align="center">450</td>
            </tr>
            <tr>
              <td align="center">V (km/s)</td>
              <td align="center">7.7</td>
              <td align="center">7.636</td>
            </tr>
          </tbody>
        </table>
        <table anchor="Table-Two-VLEO-Intersects" align="center">
          <name>Two VLEO intersects with different angle and the life of communication</name>
          <thead>
            <tr>
              <th align="center">A (degree)</th>
              <th align="center">0</th>
              <th align="center">10</th>
              <th align="center">45</th>
              <th align="center">90</th>
              <th align="center">135</th>
              <th align="center">180</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">|V| (km/s)</td>
              <td align="center">0.065</td>
              <td align="center">1.338</td>
              <td align="center">5.869</td>
              <td align="center">10.844</td>
              <td align="center">14.169</td>
              <td align="center">15.336</td>
            </tr>
            <tr>
              <td align="center">T(s)</td>
              <td align="center">61810</td>
              <td align="center">2984</td>
              <td align="center">680</td>
              <td align="center">368</td>
              <td align="center">282</td>
              <td align="center">260</td>
            </tr>
          </tbody>
        </table>
        <table anchor="Table-Two-LEO" align="center">
          <name>Two LEO with different altitude and speed</name>
          <thead>
            <tr>
              <th align="center">Parameters</th>
              <th align="center">LEO1</th>
              <th align="center">LEO2</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">As(km)</td>
              <td align="center">1150</td>
              <td align="center">1325</td>
            </tr>
            <tr>
              <td align="center">V (km/s)</td>
              <td align="center">7.272</td>
              <td align="center">7.189</td>
            </tr>
          </tbody>
        </table>
        <table anchor="Table-Two-LEO-Intersects" align="center">
          <name>Two LEO intersects with different angle and the life of communication</name>
          <thead>
            <tr>
              <th align="center">A (degree)</th>
              <th align="center">0</th>
              <th align="center">10</th>
              <th align="center">45</th>
              <th align="center">90</th>
              <th align="center">135</th>
              <th align="center">180</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">|V| (km/s)</td>
              <td align="center">0.083</td>
              <td align="center">1.263</td>
              <td align="center">5.535</td>
              <td align="center">10.226</td>
              <td align="center">13.360</td>
              <td align="center">14.461</td>
            </tr>
            <tr>
              <td align="center">T(s)</td>
              <td align="center">47961</td>
              <td align="center">3155</td>
              <td align="center">720</td>
              <td align="center">390</td>
              <td align="center">298</td>
              <td align="center">276</td>
            </tr>
          </tbody>
        </table>		
	    </section>

	  </section>
    </section>
    <section anchor="UseSatelliteNetworkForInternet" numbered="true" toc="default">
      <name>Use Satellite Network for Internet Integration</name>
      <t>Since there is no complete satellite network established yet, all following analysis is based on the 
predictions from the traditional GEO communication. The analysis also learnt how other type of network has been used in Internet, 
such as Broadband access network, Mobile access network, Enterprise network and Service Provider network. </t>
      <t>As a criteria to be part of Internet, any device connected to any satellite should be able to communicate with any public IP4 or IPv6 
address in Internet. 
There could be three types of methods to deliver IP packet from source to destination by satellite:</t>
      <dl newline="true" spacing="normal" indent="4">
        <dt>1. Data packet is relayed between ground station and satellite.</dt>
        <dd>
		  For this method, there is no inter-satellite communication and networking. Data packet is bounced once or couple times between 
		  ground stations and satellites until the packet arrives at the destination in Internet.</dd>
        <dt>2. Data packet is delivered by inter-satellite networking.</dt>
        <dd>
		  For this method, the data packet traverses with multiple satellites connected by ISL and inter-satellite networking is used to deliver the packet 
		  to the destination in Internet.</dd>
        <dt>3. Both satellite relay and inter-satellite networking are used.</dt>
        <dd>
		  For this method, the data packet is relayed in some segments and traverse with multiple satellites in other segments. 
		  It is a combination of the method 1 and method 2.</dd>
      </dl>
<t>Using the above methods for IP packet delivery via satellite network, we will have two typical use cases for satellite network.
One is for the general broadband access (see <xref target="UseSatelliteNetworkForInternet-BroadbandAccess" format="default"/>), 
another is for the integration with 3GPP wireless network including 4G and 5G (see <xref target="UseSatelliteNetworkForInternet-wireless-access" format="default"/>
and <xref target="UseSatelliteNetworkForInternet-3GPP-recent" format="default"/>).</t>

		<section anchor="UseSatelliteNetworkForInternet-BroadbandAccess" numbered="true" toc="default">
			<name>Use Satellite Network for Broadband Access</name>     
	<t>For this use case, the end user terminal or local network is connected to a ground station, and another ground station is connected to Internet.
	Two ground stations will have IP connectibity via a satellite network. The satellite network could be by satellite relays or by inter-satellite network.</t>
	<t>Follows are typical deployment scenarios that a Satellite network is used for broadband access of Internet.</t>	  
      <dl newline="true" spacing="normal" indent="4">
        <dt>1. The end user terminal access Internet through satellite relay</dt>
        <dd> 
		  (<xref target="Fig-Terminal-Access-Internet-Satellite-Relay" format="default"/> for one satellite relay, 
		  <xref target="Fig-Terminal-Access-Internet-Multi-Satellite-Relay" format="default"/> for multiple satellite relay).</dd>
        <dt>2. The end user terminal access Internet through inter-satellite-networking</dt>
        <dd>
		  (<xref target="Fig-Terminal-Access-Internet-Inter-Satellite" format="default"/>).</dd>
        <dt>3. The local network access Internet through satellite relay</dt>
        <dd>
		  (<xref target="Fig-LocalNet-Access-Internet-Satellite-Relay" format="default"/> for one satellite relay, 
		  <xref target="Fig-LocalNet-Access-Internet-Multi-Satellite-Relay" format="default"/> for multiple satellite relay).</dd>
        <dt>4. The local network access Internet through inter-satellite-networking</dt>
        <dd>
		  (<xref target="Fig-LocalNet-Access-Internet-Inter-Satellite" format="default"/>).</dd>
      </dl>

      <figure anchor="Fig-Terminal-Access-Internet-Satellite-Relay">
	  <name>End user terminal access Internet through one satellite relay</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
           S1----\            /-----------\
          /       \          /             \    
 T---GW--GS1--S2--GS2-------PE   Internet   +
          \       /          \             /
           \---S3/            \-----------/        
]]></artwork>
      </figure>


      <figure anchor="Fig-Terminal-Access-Internet-Multi-Satellite-Relay">
	  <name>End user terminal access Internet through multiple satellite relay</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
           S1----\    S4----\       /-----------\
          /       \  /       \     /             \    
 T---GW--GS1--S2--GS2---S5--GS3---PE   Internet   +
          \       /  \       /     \             /
           \---S3/    \---S6/       \-----------/        
]]></artwork>
      </figure>


      <figure anchor="Fig-Terminal-Access-Internet-Inter-Satellite">
	  <name>End user terminal access Internet through inter-satellite-networking</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
           S1-----S2-----S3--\            /----------\
          /                   \          /            \    
 T---GW--GS1--S4----S5---S6---GS2-------PE  Internet   +
          \                   /          \            /
           \---S7----S8----S9/            \----------/       
]]></artwork>
      </figure>


      <figure anchor="Fig-LocalNet-Access-Internet-Satellite-Relay">
	  <name>Local network access Internet through one satellite relay</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
   /-----------\           S1----\           /-------\
  /             \         /       \         /         \    
 + Local network CE------GS1--S4--GS2-------PE Internet +
  \             /         \       /         \         /
   \-----------/           \---S7/           \-------/      
]]></artwork>
      </figure>


      <figure anchor="Fig-LocalNet-Access-Internet-Multi-Satellite-Relay">
	  <name>Local network access Internet through multiple satellite relay</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
   /-----------\         S1----\   S4----\       /-------\
  /             \       /       \  /      \     /         \    
 + Local network CE----GS1--S2--GS2--S5--GS3---PE Internet +
  \             /       \       / \       /     \         /
   \-----------/         \---S3/   \---S6/       \-------/      
]]></artwork>
      </figure>


      <figure anchor="Fig-LocalNet-Access-Internet-Inter-Satellite">
	  <name>Local network access Internet through inter-satellite-networking</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
  /-----------\          S1-----S2-----S3---\            /------\
 /             \         /                   \          /        \    
+ Local network CE------GS1--S4----S5---S6---GS2-------PE Internet+
 \             /         \                   /          \        /
  \-----------/           \---S7----S8----S9/            \------/
      
]]></artwork>
      </figure>


      <t>In above <xref target="Fig-Terminal-Access-Internet-Satellite-Relay" format="default"/> to 
	  <xref target="Fig-LocalNet-Access-Internet-Inter-Satellite" format="default"/>, the meaning of symbols are as follows:</t>
      <dl newline="false" spacing="normal" indent="16">
        <dt>T</dt>
        <dd>The end user terminal</dd>
        <dt>GW</dt>
        <dd>Gateway router</dd>
        <dt>GS1, GS2, GS3</dt>
        <dd>Ground station with L2/L3 routing/switch functionality.</dd>
        <dt>S1 to S9</dt>
        <dd>Satellites</dd>
        <dt>PE</dt>
        <dd>Provider Edge Router</dd>
        <dt>CE</dt>
        <dd>Customer Edge Router</dd>
      </dl>
	  
	  </section>
	 
	    <section anchor="UseSatelliteNetworkForInternet-wireless-access" numbered="true" toc="default">
	    <name>Use Satellite Network with 3GPP Wireless Access Network</name>
	<t>For this use case, the wireless access network (4G, 5G) defined in 3GPP is used with satellite network. By such integration,
		a user terminal or local network can access Internet via 3GPP wireless network and satellite network. 
	The End user terminal or local network access Internet through satellite network and Mobile Access Network. There are two cases:
	1) From mobile access network to satellite network or 2) From satellite network to mobile access network, Satellite 
	network includes inter satellite network and relay network.
    See <xref target="Fig-Access-Internet-Mobile-Satellite" format="default"/> for mobile access network to 
	satellite network, and <xref target="Fig-Access-Internet-Satellite-Mobile" format="default"/> for satellite network to mobile access network.</t>

       <figure anchor="Fig-Access-Internet-Mobile-Satellite">
      	<name>End user terminal or local network access Internet through Mobile Access Network and Satellite Network</name>
      		<artwork align="center" name="" type="" alt=""><![CDATA[
+--------------+    +-------------+    +---------+    +--------+
|    T or      |    |Mobile Access|    |Satellite|    |Internet|
| Local network+----+  Network    +----+ Network +----+        |
+--------------+    +-------------+    +---------+    +--------+
      		]]></artwork>
      </figure>
<figure anchor="Fig-Access-Internet-Satellite-Mobile">	
      	<name>End user terminal or local network access Internet through Satellite Network and Mobile Access Network</name>
      		<artwork align="center" name="" type="" alt=""><![CDATA[
+--------------+   +---------+   +-------------+   +--------+
|    T or      |   |Satellite|   |Mobile Access|   |Internet|
| Local network+---+ Network +---+  Network    +---+        |
+--------------+   +---------+   +-------------+   +--------+
]]></artwork>
      </figure>
		</section>
	    <section anchor="UseSatelliteNetworkForInternet-3GPP-recent" numbered="true" toc="default">
	    <name>Recent Development and Study in 3GPP for Satellite Network</name>
<t>3GPP SA Working Groups (WG) feature a couple of satellite-related projects (or
SIDs). The SA2 WG is currently studying the adoption of satellite 
communication to provide 5G backhaul service <xref target="TR-23.700-27" format="default"/>. </t>

<t>One key aspect is to investigate the potential 
architecture requirements and enhancements to deploy UPFs on satellites
(LEO/MEO/GEO) with gNBs on the ground. Specifically, it targets at enhancing 
the local-switching capability for UE-to-UE data communication when UEs are 
served by UPFs on-board satellite(s). Similarly, the SA1 WG proposed a new 
satellite-based SID in which the service end points (could also be called 
UEs in a broader sense) may continuously move in a fast way. The UEs can be 
ships, boats, and cars, etc., which are located in remote regions 
that need the connection to LEO's for achieving communication.</t>

<t>In all the SIDs, satellite based backhaul is important for mission critical
scenarios in remote areas. Here, we want to clarify that while 3GPP documents 
TS 23.501 <xref target="TS-23.501" format="default"/> and 23.502 <xref target="TS-23.502" format="default"/> specify that a ground base station, i.e., gNB, may have 
multiple types of satellite backhauls (BH), e.g., GEO BH, LEO BH and 
LEO-BH with ISL, this use case focuses specifically 
on the LEO-BH with ISL. ISL stands for inter-satellite link. </t>

<t>Clearly, when a satellite backhaul involves multi-hop ISL path connected via 
different satellites, the capabilities provided by the satellite path would be 
changed and adjusted dynamically. For example, in the LEO case, the peering 
relationship between two neighboring satellites changes roughly every 5 minutes 
thanks to the orbital movement (see <xref target="Table-Time-Satellite-Station-Com" format="default"/>). This will definitely impair the 
networking performance and stability, and, in worst case, may cause the
loss of connectivity. Even if some overlay tunneling mechanisms could be used to 
address the multi-hop ISL issue, the extra delay and potentially
less bandwidth as introduced naturally by the ever-changing backhaul path 
would still impact the traffic engineering over the links. </t>

<t>The following diagram <xref target="Fig-3GPP-SAT-B" format="default"/> demonstrate the dynamic characteristics of 
satellite backhaul between two UEs. In the figure, 
UEs are connected, via gNBs, to UPFs on-board satellites. 
Both UPFs are connected via multi-hop ISLs to the 
5G core (5GC) on the ground. There are two different multi-hop ISL paths:

 o A UE has to rely on a multi-hop ISL path to connect to 5GC on the ground.
 o When two UEs intend to communicate via the local data switching on satellite(s),
   some new ISL-based peering has to be established which would bring in
   the multi-hop ISL scenario. For example, the ISL between the Sat#1 and Sat#2
   helps form a multi-hop path (marked N19 in the diagram) between the two UEs.

Note that if the UPF-based local data switching involves only one UPF, then it
is designated as intra-UPF local switching and relatively simpler. This is compared 
to the case of inter-UPF local switching as shown in the diagram. </t>

      <figure anchor="Fig-3GPP-SAT-B">
	  <name>Use Satellite network as back haul for 5G</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[

    Sat#: Satellite                    GS:  Ground Station
    UPF:  User Plane Function (5G)     gNB: Next Generation NodeB

                     Sat#1
                +----------+       +--------+      
                |  UPF#1   | (ISL) | Sat#.. |
   UE#1--gNB#1--|(on-board)|- - - -|        |-----+
                +----------+       +--------+     |          
                     :                            |      --------   
                     :(N19)                       v     /        \
                     :(ISL)                      GS ---+ 5G Core +
                     :                            ^     \        /
                +----------+       +--------+     |      --------  
                |  UPF#2   | (ISL) | Sat#.. |     |   
   UE#2--gNB#2--|(on-board)|- - - -|        |-----+      
                +----------+       +--------+      
                   Sat#2      
]]></artwork>
      </figure>

<t>In this diagram, both UEs are served by different satellite backhauls. If 
the local data switching via LEO UPFs on-board could be established (via the
N19 ISL forwarding), then the system efficiency and QoE improvement would be
achieved. Here, since UEs are served by different satellites, a multi-hop ISL 
scenario must be supported. But, this scenario posts challenges due to the 
dynamic satellite network topology and distinguished transmission capabilities 
from different satellites. </t>

<t>For example, if the UE-to-UE session has to maintain a service over longer 
time (> 5 minutes) such that the Sat#1 and Sat#2 move apart, then a new ISL 
path with potentially a new N19-ISL might be established. 
In worst case, if newly-involved satellites in the path 
happen to be polar-orbit ones and they do not support cross-seam ISLs, 
the communication latency may change dramatically 
when cross-seam transits or leaves. In another example, if both UEs belong to 
the same entity and need to form a 5G-VN group, then the 5G LAN-type service 
with PSA UPF-based local-switching must be applied among them.</t>

<t>Regardless, more efficient satellite communication mechanisms must be adopted, 
e.g., running efficient satellite-based routing protocols, establishing 
tunnels between LEO UPFs on-board, etc., for better local-data switching.</t>

<t>Further, 5GS may collaborate with satellite networks to improve QoS. 
One 5GC NF (i.e., SMF) can initiate UP path monitoring, and accordingly 
receive UP path monitoring results indicating observed delay. After that, 
the SMF takes corresponding actions like further verifying network statistics, 
updating sessions, etc. The coordination with the satellite networks would 
improve the process, which suggests satellites networks respond better to 
the (monitor-based) polling from 5GS.</t>

<t>One more thing we want to point out is that, while the propagation delay of 
satellite backhaul paths may change dramatically with the movement of satellite, 
this kind of change normally be periodic and can be well predicated based on 
the operation information of satellite constellation. Thus, making use of 
these information would also help for better services.</t>
	  
			</section>

    </section>
    <section anchor="ProblemsSatelliteConstellationForInternet" numbered="true" toc="default">
      <name>Problems and Requirements for Satellite Constellation for Internet</name>
      <t>As described in <xref target="UseSatelliteNetworkForInternet" format="default"/>, satellites in a satellite constellation can either relay internet
traffic or multiple satellites can form a network to deliver internet traffic. More detailed analysis are in following sub sections. 
There might have multiple solutions for each method described in <xref target="UseSatelliteNetworkForInternet" format="default"/>, following contexts 
only discuss the most plausible solution from networking perspectives.</t>
      <t><xref target="CommonProbReq" format="default"/> will list the common problems and requirements for both satellite relay and satellite networking.</t>
      <t><xref target="SatelliteRelay" format="default"/> and <xref target="SatelliteNetworking" format="default"/> will describe key problems, requirement and 
potential solution from the networking perspective for these two cases respectively.</t>
      <t/>
      <section anchor="CommonProbReq" numbered="true" toc="default">
        <name>Common Problems and Requirements</name>
        <t>For both satellite relay and satellite networking, satellite-ground-station must be used, so, the problems and requirements for 
the satellite-ground-station communication is common and will apply for both methods.</t>
        <t>When one satellite is communicating with ground station, the satellite only needs to receive data from uplink of one ground station, 
process it and then send to the downlink of another ground station. <xref target="Fig-Terminal-Access-Internet-Satellite-Relay" format="default"/> 
illustrates this case. Normally microwave is used for both links. </t>
        <t>Additionally, from the coverage analysis in <xref target="DynamicCoverage" format="default"/> and real deployment in <xref target="Deployment" format="default"/>, 
we can see one ground station may communicate with multiple satellites. Similarly, one satellite may communicate with multiple ground 
stations. The characters for satellite-ground-station communication are:</t>
        <dl newline="true" spacing="normal" indent="4">
          <dt>1. Satellite-ground-station communication is P2MP.</dt>
          <dd>
		  Since microwave physically is the carrier of broadcast communication, one satellite can send data while multiple ground stations 
		  can receive it. Similarly, one ground station can send data and multiple satellites can receive it. </dd>
          <dt>2. Satellite-ground-station communication is in open space and not secure.</dt>
          <dd>
		  Since electromagnetic fields for microwave physically are propagating in open space. The satellite-ground-station communication 
		  is also in open space. It is not secure naturally.</dd>
          <dt>3. Satellite-ground-station communication is not steady.</dt>
          <dd>
		  Since the satellite is moving with high speed, from <xref target="StationSatelliteCommunication" format="default"/>, the satellite-ground-station 
		  communication can only last a certain period of time. The communication peers will keep changing.</dd>
          <dt>4. Satellite-to-Satellite communication is not steady.</dt>
          <dd>
		  For some satellites, even they are in the same altitude and move in the same speed, but
		  they move in the opposite direction, from <xref target="AdjacentOrbitWithSameAltitude" format="default"/>, the satellite-to-satellite 
		  communication can only last a certain period of time. The communication peers will keep changing.</dd>
          <dt>5. Satellite-to-Satellite distance is not steady.</dt>
          <dd>For satellites with the same altitude and same moving direction, even their relative position is steady, but the distance between
		  satellites are not steady. This will lead to the inter-satellite-communication's bandwidth and
		  latency keep changing. </dd>	  
		  <dt>6. Satellite physical resource is limited.</dt>
          <dd>
		  Due to the weight, complexity and cost constraint, the physical resource on a satellite, such as power supply, memory, 
		  link speed, are limited. It cannot be compared with the similar device on ground. The design and technology used should 
		  consider these factors and take the appropriate approach if possible.</dd>
        </dl>
        <t>The requirements of satellite-ground-station communication are:</t>
        <dl newline="true" spacing="normal" indent="4">
          <dt>R1. The bi-directional communication capability</dt>
          <dd>
		  Both satellites and ground stations have the bi-directional communication capability</dd>
          <dt>R2. The identifier for satellites and ground stations</dt>
          <dd>
		  Satellites and ground stations should have Ethernet and/or IP address configured for the device and each link. 
		  More detailed address configuration can be seen in each solution.</dd>
          <dt>R3. The capability to decide where the IP packet is forwarded to.</dt>
          <dd>
		  In order to send Internet traffic or IP date to destination correctly, satellites and ground station must have Ethernet 
		  hub or switching or IP routing capability. More detailed capability can be seen in each solution.</dd>
          <dt>R4. The protocol to establish the satellite-ground-station communication.</dt>
          <dd>
		  For security and management purpose, the satellite-ground-station communication is only allowed after both sides agree through a protocol.
		  The protocol should be able to establish a secured channel for the communication when a new communication peer comes up. 
		  Each ground station should be able to establish multiple channels to communicate with multiple satellites. 
		  Similarly, each satellite should be able to establish multiple channels to communicate to multiple ground stations.</dd>
          <dt>R5. The protocol to discover the state of communication peer.</dt>
          <dd>
		  The discover protocol is needed to detect the state of communication peer such as peer's identity, the state of the peer and other info of the peer. The 
		  protocol must be running securely without leaking the discovered info.</dd>
          <dt>R6. The internet data packet is forwarded securely.</dt>
          <dd>
		  When satellite or ground station is sending the IP packet to its peer, the packet must be relayed securely without leaking the user data.</dd>
          <dt>R7. The internet data packet is processed efficiently on satellite</dt>
          <dd>
		  Due to the resource constraint on a satellite, the packet may need more efficient mechanism to be processed on satellite. The process on satellite 
		  should be very minimal and offloaded to ground as much as possible.</dd>
        </dl>
      </section>
      <section anchor="SatelliteRelay" numbered="true" toc="default">
        <name>Satellite Relay</name>
        <t>One of the reasons to use satellite constellation for internet access is it can 
		provide shorter latency than using the fiber underground.
But using ISL for inter-satellite communication is the premise for such benefit in latency. 
Since the ISL is still not mature and adopted commercially, satellite relay is a only choice currently for satellite constellation used for internet access.
In <xref target="UCL-Mark-Handley" format="default"/>, detailed simulations have demonstrated better latency than fiber network by satellite relay even the ISL is not present.</t>
        <section anchor="OneSatelliteRelay" numbered="true" toc="default">
          <name>One Satellite Relay</name>
          <t>One satellite relay is the simplest method for satellite constellation to provide Internet service.
By this method, IP traffic will be relayed by one satellite to reach the DGS and go to Internet.</t>
          <t>The solution option and associated requirements are:</t>
          <t>S1. The satellite only does L1 relay or the physical signal process. </t>
          <t>For this solution, a satellite only receives physical signal, amplify it and broadcast to ground stations. 
It has no further process for packet, such as L2 packet compositing and processing, etc. All packet level work is done only at ground station. 
The requirements for the solution are:</t>
          <dl newline="true" spacing="normal" indent="3">
            <dt>   R1-1. SGS and BGS are configured as IP routing node. Routing protocol is running in SGS and BGS</dt>
            <dd>
	SGS and BGS is a IP peer for a routing protocol (IGP or BGP). SGS will send internet traffic to DGS as next hop through satellite uplink and downlink.</dd>
            <dt>   R1-2. DGS must be connected with Internet.</dt>
            <dd>
	DGS can process received packet from satellite and forward the packet to the destination in Internet.</dd>
          </dl>
          <t>In addition to the above requirements, following problem should be solved:</t>
          <dl newline="true" spacing="normal" indent="3">
            <dt>   P1-1. IP continuity between two ground stations</dt>
            <dd>
	This problem is that two ground stations are connected by one satellite relay. Since the satellite is moving, the IP continuity between ground stations 
	is interrupted by satellite changing periodically. Even though this is not killing problem from the view point that IP service traditionally is 
	only a best effort service, it will benefit the service if the problem can be solved. Different approaches may exist, such as
	using hands off protocols, multipath solutions, etc.</dd>
          </dl>
          <t>S2. The satellite does the L2 relay or L2 packet process.</t>
          <t>For this solution, IP packet is passing through individual satellite as an L2 capable device. Unlike in the solution S1, 
satellite knows which ground station it should send based on packet's destination MAC address after L2 processing. The advantage of this solution over S1 is it can use narrower
beam to communicate with DGS and get higher bandwidth and better security. The requirements for the solution are:</t>
          <dl newline="true" spacing="normal" indent="3">
            <dt>   R2-1. Satellite must have L2 bridge or switch capability</dt>
            <dd>
	In order to forward packet to properly, satellite should run some L2 process such as MAC learning, MAC switching. 
	The protocol running on satellite must consider the fast movement of satellite and its impact to protocol convergence, 
	timer configuration, table refreshment, etc. </dd>
            <dt>   R2-2. same as R1-1 in S1</dt>
            <dd/>
            <dt>   R2-3. same as R1-2 in S1</dt>
            <dd/>
          </dl>
          <t>In addition to the above requirements, the problem P1-1 for S1 should also apply.</t>
        </section>
        <section anchor="MultipleSatelliteRelay" numbered="true" toc="default">
          <name>Multiple Satellite Relay</name>
          <t>For this method, packet from SGS will be relayed through multiple intermediate satellites and ground station until reaching a DGS.</t>
          <t>This is more complicated than one satellite relay described in <xref target="OneSatelliteRelay" format="default"/>.</t>
          <t>One general solution is to configure both satellites and ground-stations as IP routing nodes, proper routing protocols are running
in this network. The routing protocol will dynamically determine forwarding path.
The obvious challenge for this solution is that all links between satellite and ground station are not static, according to the analysis
in <xref target="StationSatelliteCommunication" format="default"/>, the lifetime of each link may last only couple of minutes. This will result in very
quick and constant topology changes in both link state and IP adjacency, it will cause the distributed routing algorithms may never 
converge. So this solution is not feasible.</t>
          <t>Another plausible solution is to specify path statically. The path is composed of a serials of intermediate ground stations plus
SGS and DGS. This idea will make ground stations static and leave the satellites dynamic. It will reduce the fluctuation of network path, 
thus provide more steady service.
One variant for the solution is whether the intermediate ground stations are connected to Internet. Separated discussion is as below:</t>
          <t>S1. Manual configuring routing path and table</t>
          <t>For this solution, the intermediate ground stations and DGS are specified and configured manually during the stage of network planning and provisioning. 
Following requirements apply:</t>
          <dl newline="true" spacing="normal" indent="3">
            <dt>   R1-1. Specify a path from SGS to DGS via a list of intermediate ground stations. </dt>
            <dd>
	The specified DGS must be connected with internet. Other specified intermediate ground stations does not have to</dd>
            <dt>   R1-2. All Ground stations are configured as IP routing node.</dt>
            <dd>
	Static routing table on all ground stations must be pre-configured, the next hop of routes to Internet destination in any ground station is 
	configured to going through uplink of satellite to the next ground station until reaching the DGS.</dd>
            <dt>   R1-3. All Satellites are configured as either L1 relay or L2 relay. </dt>
            <dd>
	The Satellite can be configured as L1 relay or L2 relay described in S1 and S2 respectively in <xref target="OneSatelliteRelay" format="default"/></dd>
          </dl>
          <t>In addition to the above requirements, the problem P1-1 in <xref target="OneSatelliteRelay" format="default"/> should also apply.</t>
          <t>S2. Automatic decision by routing protocol.</t>
          <t>This solution is only feasible after the IP continuity problem (P1-1 in <xref target="OneSatelliteRelay" format="default"/>) is solved. Following requirements apply:</t>
          <dl newline="true" spacing="normal" indent="3">
            <dt>   R2-1. All Ground stations are configured as IP routing node. Proper routing protocols are configured as well.</dt>
            <dd>
	The satellite link cost is configured to be lower than the ground link. In such a way, 
	the next hop of routes for the IP forwarding to Internet destination in any ground station will be always going through the uplink of satellite 
	to the next ground station until reaching the DGS.</dd>
            <dt>   R2-2. All Satellites are configured as either L1 relay or L2 relay. </dt>
            <dd>
	The Satellite can be configured as L1 relay or L2 relay described in S1 and S2 respectively in <xref target="OneSatelliteRelay" format="default"/></dd>
          </dl>
          <t>In addition to the above requirements, the problem P1-1 in <xref target="OneSatelliteRelay" format="default"/> should also apply.</t>
        </section>
      </section>
      <section anchor="SatelliteNetworking" numbered="true" toc="default">
        <name>Satellite Networking</name>
        <t>In the draft, satellite Network is defined as a network that satellites 
		are inter-connected by inter-satellite links (ISL).
One of the major difference of satellite network with the other type of network on ground 
(telephone, fiber, etc.) is its topology and links are not stationary, 
some new issues have to be considered and solved. Follows are the factors that impact the satellite networking.</t>
        <section anchor="L2orL3Network" numbered="true" toc="default">
          <name>L2 or L3 network</name>
          <t>The 1st question to answer is should the satellite network be configured as L2 or L3 network? 
As analyzed in <xref target="DynamicCoverage" format="default"/> and <xref target="Deployment" format="default"/>, 
since there are couple of hundred or over ten 
thousand satellites in a network, L2 network is not a good choice, 
instead, L3 or IP network is more appropriate for such scale of network.</t>
        </section>
        <section anchor="LinkLifeTime" numbered="true" toc="default">
          <name>Inter-satellite-Link Lifetime</name>
          <t>If we assume the orbit is circular and ignore other trivial factors, the satellite speed is approximately determined by 
the orbit altitude as described in the <xref target="StationSatelliteCommunication" format="default"/>. 
The satellite orbit can determine if the dynamic position of two satellites is within the range of the inter-satellite 
communication. That is 2000km for laser communication <xref target="Laser-communication-range" format="default"/> by Inter Satellite Laser Link (ISLL).</t>
          <t>When two satellites' orbit planes belong to the same group, or two orbit planes share the 
		  same altitude and inclination, and when the satellites move in the same direction, the
relative positions of two satellites are relatively stationary, and the inter-satellite communication is steady.
But when the satellites move in the opposite direction, the
relative positions of two satellites are not stationary, the communication lifetime is couple of minutes.
The <xref target = "AdjacentOrbitWithSameAltitude"/> has analyzed the scenario.</t>

          <t>When two satellites' orbit planes belong to the different group, or two orbit planes have different altitude, the
relative position of two satellite are unstable, and the inter-satellite communication is not steady. 
As described in <xref target="InterSatelliteCommunication" format="default"/>, The life of communication for two satellites depends
on the following parameters of two satellites:</t>
          <ol spacing="normal" type="1"><li>The speed vectors.</li>
            <li>The altitude difference</li>
            <li>The intersection angle</li>
          </ol>
          <t>From the examples shown in <xref target="Table-Two-VLEO" format="default"/> to <xref target="Table-Two-LEO-Intersects" format="default"/>, 
we can see that the lifetime of inter-satellite communication for the different group of orbit planes are from couple of 
hundred seconds to about 18 hours.
This fact will impact the routing technologies used for satellite network and will be discussed in <xref target="ProblemForTraditionalTech" format="default"/>.</t>
        </section>
        <section anchor="ProblemForTraditionalTech" numbered="true" toc="default">
          <name>Problems for Traditional Routing Technologies</name>
          <t>When the satellite network is integrated with Internet by traditional routing technologies, 
following provisioning and configuration (see <xref target="Fig-ProblemForTraditionalTech" format="default"/>) will apply:</t>
          <ol spacing="normal" type="1"><li>The ground stations connected to local network and internet are treated as PE router for satellite network 
	(called PE_GS1 and PE_GS2 in the following context), and all satellites are treated as P router.</li>
            <li>All satellites in the network and ground stations are configured to run IGP.</li>
            <li>The eBGP is configured between PE_GS and its peered network's PE or CE.</li>
          </ol>
          <t>The work on PE_GS1 are: </t>
          <ul spacing="normal">
            <li>The local network routes are received at PE_GS1 from CE by eBGP. The routes are redistributed to IGP and then IGP flood them to all satellites.
		(Other more efficient methods, such as iBGP or BGP reflectors are hard to be used, since the satellite is moving and there is no easy way to configure 
	a full meshed iBGP session for all satellites, or configure one satellite as BGP reflector in satellite network.)</li>
            <li>The internet routes are redistributed from IGP to eBGP running on PE_GS1, and eBGP will advertise them to CE.</li>
          </ul>
          <t>The work on PE_GS2 are: </t>
          <ul spacing="normal">
            <li>The Internet routes are received at PE_GS2 from PE by eBGP. The routes are redistributed to IGP and then IGP flood them to all satellites. 
		(Similar as in PE_GS1, Other more efficient methods, such as iBGP or BGP reflector cannot be used.)</li>
            <li>The local network routes are redistributed from IGP to eBGP running on PE_GS2, and eBGP will advertise them to Internet.</li>
          </ul>
          <figure anchor="Fig-ProblemForTraditionalTech">
		  <name>Local access Internet through inter-satellite-networking</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
  /--------\             S1---S2----S3----\               /------\
 /          \            /    IGP domain   \             /        \
+ Local net CE--eBGP--PE_GS1---S4---S5---PE_GS2--eBGP--PE Internet +
 \          /            \                 /             \        /
  \--------/              \---S6---S7---S8/               \------/
]]></artwork>
          </figure>
          <t keepWithPrevious="true">Local access Internet through inter-satellite-networking</t>
          <t>On PE-GS1, due to the fact that IGP link between PE_GS1 and satellite is not steady; this will lead to following routing activity:</t>
          <ol spacing="normal" type="1"><li>When one satellite is connecting with PE_GS1, the satellite and PE_GS1 form a IGP adjacency. IGP starts to exchange the link state update.</li>
            <li>The local network routes received by eBGP in PE_GS1 from CE are redistributed to IGP, and IGP starts to flood link state update to all satellites.</li>
            <li>Meanwhile, the Internet routes learnt from IGP in PE_GS1 will be redistributed to eBGP. eBGP starts to advertise to CE.</li>
            <li>Every satellite will update its routing table (RIB) and forwarding table (FIB) after IGP finishes the SPF algorithm.</li>
            <li>When the satellite is disconnecting with PE-GS1, the IGP adjacency between satellite and PE_GS1 is gone. IGP starts to exchange the link state update.</li>
            <li>The routes of local network and satellite network that were redistributed to IGP in step 2 will be withdrawn, and IGP starts to flood link state update to all satellites.</li>
            <li>Meanwhile, the Internet routes previously redistributed to eBGP in step 3 will also be withdrawn. eBGP starts to advertise route withdraw to CE.</li>
            <li>Every satellite will update its routing table (RIB) and forwarding table (FIB) after the SPF algorithm.</li>
          </ol>
          <t>Similarly on PE_GS2, due to the fact that IGP link between PE_GS2 and satellite is not steady; this will lead to following routing activity:</t>
          <ol spacing="normal" type="1"><li>When one satellite is connecting with PE_GS2, the satellite and PE_GS2 form a IGP adjacency. IGP starts to exchange the link state update.</li>
            <li>The Internet routes previously received by eBGP in PE_GS2 from PE are redistributed to IGP, IGP starts to flood the new link state update to all satellites.</li>
            <li>Meanwhile, the routes of local network and satellite network learnt from IGP in PE_GS2 will be redistributed to eBGP. eBGP starts to advertise to Internet peer PE.</li>
            <li>Every satellite will update its routing table (RIB) and forwarding table (FIB) after IGP finishes the SPF algorithm.</li>
            <li>When the satellite is disconnecting with PE-GS2, the IGP adjacency between satellite and PE_GS2 is gone. IGP starts to exchange the link state update.</li>
            <li>The internet routes previously redistributed to IGP in step 2 will be withdrawn, and IGP starts to flood link state update to all satellites</li>
            <li>Meanwhile, the routes of local network and satellite network previously redistributed to eBGP in step 3 will also be withdrawn. eBGP starts to advertise route withdraw to PE.</li>
            <li>Every satellite will update its routing table (RIB) and forwarding table (FIB) after the SPF algorithm.</li>
          </ol>
          <t>For the analysis of detailed events above, the estimated time interval between 
event 1 and 5 for PE_GS1 and PE_GS2 
can use the analysis in <xref target="StationSatelliteCommunication" format="default"/>. 
For example, it is about 398s for LEO and 103s for VLEO. Within this time interval, 
the satellite network including all satellites and two ground stations must finish 
the works from 1 to 4 for PE_GS1 and PE_GS2. 
The normal internet IPv6 and IPv4 BGP routes size are about 850k v4 routes + 100K v6 routes <xref target="BGP-Table-Size" format="default"/>. 
There are couple critical problems associated with the events:</t>
          <dl newline="true" spacing="normal" indent="3">
		    <dt>   P1. Frequent IGP update for its link cost</dt>
			<dd>Even for satellites in different orbit with the steady relative positions, the distance between
			satellites is keep changing. If the distance is used as the link cost, it means the IGP
			has to update the link cost frequently. This will make IGP keep running and update its
			routing table.</dd>
            <dt>   P2. Frequent IGP flooding for the internet routes</dt>
            <dd>
	Whenever the IGP adjacency changes (step 1 and 5 for PE_GS2), it will trigger 
	the massive IGP flooding for the link state update for massive internet routes learnt from eBGP.
	This will result in the IGP re-convergency, RIB and FIP update.</dd>
            <dt>   P3. Frequent BGP advertisement for the internet routes</dt>
            <dd>
	Whenever the IGP adjacency changes (step 3 and 7 for PE_GS1), it will trigger the massive BGP advertisement for the internet routes learnt from IGP.
	This will result in the BGP re-convergency, RIB and FIB update. 
	BGP convergency time is longer than IGP. The document <xref target="BGP-Converge-Time1" format="default"/> has shown 
	that the BGP convergence time varies from 50sec to couple of hundred seconds. The analysis <xref target="BGP-Converge-Time2" format="default"/> indicated that per entry 
	update takes about 150us, and it takes o(75s) for 500k routes, or o(150s) for 1M routes.</dd>
            <dt>   P4. More frequent IGP flooding and BGP update in whole satellite network</dt>
            <dd>
	To provide the global coverage, a satellite constellation will have many ground stations deployed. 
	For example, StarLink has applied for the license 
	for up to one million ground stations <xref target="StarLink-Ground-Station-Fcc" format="default"/>, 
	in which, more than 50 gateway ground stations (equivalent to the PE_GS2) 
	have been registered <xref target="SpaceX-Ground-Station-Fcc" format="default"/> and deployed in U.S. <xref target="StarLink-GW-GS-map" format="default"/>. 
	It is expected that the gateway ground station will grow quickly to couple of thousands <xref target="Tech-Comparison-LEOs" format="default"/>. 
	This means almost each satellite in the satellite network would have a ground station connected. , 
	Due to the fact that all satellites are moving, many IGP adjacency changes may occur in a shorter period of time 
	described in <xref target="StationSatelliteCommunication" format="default"/> and result in the problem P1 and P2 constantly occur.</dd>
            <dt>   P5. Service is not steady</dt>
            <dd>
	Due to the problems P1 to P3, the service provider of satellite constellation is hard to provide a steady service for broadband service
	by using inter-satellite network and traditional routing technologies. </dd>
          </dl>
          <t>As a summary, the traditional routing technology is problematic for large scale inter-satellite networking for Internet.
Enhancements on traditional technologies, or new technologies are expected to solve the specific issues associated with satellite networking.</t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>
    <!-- The Author's Addresses section will be generated automatically by XML2RFC from the front information -->

    <section numbered="true" toc="default">
      <name>Contributors</name>
      <t><!--[TODO] Change this section to mention contributors to your MIB module document.-->
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Acknowledgements</name>
    </section>
  </middle>
  <back>
    <!-- References Section -->

    <!-- Section 4.7f of [RFC2223bis] specifies the requirements for the
   references sections.  In particular, there MUST be separate lists of
   normative and informative references, each in a separate section.
   The style SHOULD follow that of recently published RFCs.

   The standard MIB boilerplate available at
   http://www.ops.ietf.org/mib-boilerplate.html includes lists of
   normative and informative references that MUST appear in all IETF
   specifications that contain MIB modules.  If items from other MIB
   modules appear in an IMPORTS statement in the Definitions section,
   then the specifications containing those MIB modules MUST be included
   in the list of normative references.  When items are imported from an
   IANA-maintained MIB module the corresponding normative reference
   SHALL point to the on-line version of that MIB module.  It is the
   policy of the RFC Editor that all references must be cited in the
   text;  such citations MUST appear in the overview section where
   documents containing imported definitions (other those already
   mentioned in the MIB boilerplate) are required to be mentioned (cf.
   Section 3.2).

In general, each normative reference SHOULD point to the most recent
version of the specification in question.
-->

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7142.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2453.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7868.xml"/>
        <!--  <t>[TODO]: Add your own normative references.</t>-->
    </references>
      <references>
        <name>Informative References</name>
        <!-- <t>[TODO] RFC3410 is required to support the boilerplate text.</t>-->



<reference anchor="KeplerianElement" target="https://en.wikipedia.org/wiki/Orbital_elements">
          <front>
            <title>Keplerian elements</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="GEO-Coverage" target="https://www.planetary.org/space-images/coverage-of-a-geostationary">
          <front>
            <title>Coverage of a geostationary satellite at Earth</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="Nttdocomo-6G" target="https://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/whitepaper_6g/DOCOMO_6G_White_PaperEN_20200124.pdf">
          <front>
            <title>NTTDPCOM 6G White Paper</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="ITU-6G" target="https://www.itu.int/dms_pub/itu-s/opb/itujnl/S-ITUJNL-JFETF.V1I1-2020-P09-PDF-E.pdf">
          <front>
            <title>ITU 6G vision</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="Surrey-6G" target="https://www.surrey.ac.uk/sites/default/files/2020-11/6g-wireless-a-new-strategic-vision-paper.pdf">
          <front>
            <title>Surrey 6G vision</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="OSI-Model" target="https://en.wikipedia.org/wiki/OSI_model">
          <front>
            <title>OSI Model</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="StarLink" target="https://en.wikipedia.org/wiki/Starlink">
          <front>
            <title>Star Link</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="China-constellation" target="https://www.itu.int/ITU-R/space/asreceived/Publication/DisplayPublication/23706">
          <front>
            <title>China Constellation</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="ESA-HydRON" target="https://www.esa.int/ESA_Multimedia/Videos/2021/04/HydRON_Fibre_in_the_sky">
          <front>
            <title>HydRON: Fiber in the sky</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="SpaceX-Non-GEO" target="https://fcc.report/IBFS/SAT-LOA-20170301-00027/1190019.pdf">
          <front>
            <title>FCC report: SPACEX V-BAND NON-GEOSTATIONARY SATELLITE SYSTEM</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="Satellite-coverage" target="https://faculty.nps.edu/awashburn/Files/Notes/EARTHCOV.pdf">
          <front>
            <title>Earth Coverage by Satellites in Circular Orbit</title>
            <author>
              <organization>Alan R.Washburn, Department of Operations Research, Naval Postgraduate School</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Microwave-vs-Laser-communication" target="https://www.ijraset.com/fileserve.php?FID=7815">
          <front>
            <title>Comparison of Microwave and Optical Wireless Inter-Satellite Links</title>
            <author>
              <organization>International Journal for Research in Applied Science and Engineering Technology (IJRASET)</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Laser-communication-range" target="https://www.laserfocusworld.com/optics/article/16551652/interferometry-quantum-entanglement-physics-secures-spacetospace-interferometric-communications">
          <front>
            <title>Interferometric optical communications can potentially lead to robust, secure, and naturally encrypted long-distance laser communications in space by taking advantage of the underlying physics of quantum entanglement.</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="BGP-Table-Size" target="https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/">
          <front>
            <title>BGP in 2020 - BGP table</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="BGP-Converge-Time1" target="https://labs.apnic.net/?p=1397">
          <front>
            <title>BGP in 2020 - BGP Update Churn</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="BGP-Converge-Time2" target="https://www.cs.princeton.edu/courses/archive/fall14/cos561/docs/SDX.pdf">
          <front>
            <title>Bringing SDN to the Internet, one exchange point at the time</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="StarLink-Ground-Station-Fcc" target=" https://fcc.report/IBFS/SES-LIC-INTR2019-00217/1616678">
          <front>
            <title>APPLICATION FOR BLANKET LICENSED EARTH STATIONS</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="SpaceX-Ground-Station-Fcc" target="https://fcc.report/IBFS/Company/Space-Exploration-Technologies-Corp-SpaceX">
          <front>
            <title>List of SpaceX applications for ground stations</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="Tech-Comparison-LEOs" target="http://www.mit.edu/~portillo/files/Comparison-LEO-IAC-2018-slides.pdf">
          <front>
            <title>A Technical Comparison of Three Low Earth Orbit Satellite Constellation Systems to Provide Global Broadband</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="StarLink-GW-GS-map" target="https://www.google.com/maps/d/u/0/viewer?mid=1H1x8jZs8vfjy60TvKgpbYs_grargieVw">
          <front>
            <title>StarLink gateway ground station map</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="UCL-Mark-Handley" target="https://discovery.ucl.ac.uk/id/eprint/10090242/1/hotnets-ucl.pdf">
          <front>
            <title>Using ground relays for low-latency wide-area routing in megaconstellations</title>
            <author/>
            <date/>
          </front>
        </reference>

        <reference anchor="TR-23.700-27">
          <front>
            <title>Study on support of satellite backhauling in 5GS</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2022" month="May"/>
          </front>
        </reference>
		
        <reference anchor="TS-23.501">
          <front>
            <title>System architecture for the 5G System (5GS)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2021" month="December"/>
          </front>
        </reference>

        <reference anchor="TS-23.502">
          <front>
            <title>Procedures for the 5G System (5GS)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2021" month="December"/>
          </front>
        </reference>
		
        <!-- <t>[TODO] Add your own informative references</t>-->
    </references>
    </references>
    <!--
<section anchor="appendix" title="Appendix A">
	<t>You can add appendices just as regular sections, the only
difference is that they go under "back" element, and get letters 
instead of numbers</t>
</section>
-->

    <section numbered="true" toc="default">
      <name>Change Log</name>
      <ul spacing="normal">
        <li>Initial version, 07/03/2021</li>
		<li>01 version, 10/20/2021</li>
		<li>02 version, 2/13/2022</li>
		<li>03 version, 7/5/2022</li>
      </ul>
    </section>
    <!--
$Log: draft-harrington-text-mib-doc-template.xml,v $
Revision 1.2  2007/03/16 02:46:57  H73653
*** empty log message ***

Revision 1.1  2006/10/31 14:13:50  H73653
*** empty log message ***

Revision 1.10  2006/06/15 13:11:34  H73653
-00- internet-draft
made it a mib-doc-template rather than a mib-template

Revision 1.9  2006/06/14 17:32:11  H73653
saved from XXE, and reflects XXE automatic changes to formatting.

Revision 1.8  2006/04/24 23:37:55  H73653
changed from cvs header to cvs id to eliminate directory differences

Revision 1.7  2006/04/24 15:52:16  H73653
started -02- revision

Revision 1.6  2006/04/01 04:14:49  dbh
misc fixes

Revision 1.5  2005/12/24 05:35:21  dbh
pretty printed the XML

Revision 1.4  2005/12/20 00:09:39  dbh
submitted to mreview for Last Call. Runs cleanly through Bill's validator, and the production and dev versions of xml2rfc. Also aubmitted the output file produced by the web service from this source file. Note that the rfcedstyle is disabled because the directive is only available in the "bleeding edge" version.

	place for source control log here
  -->
  </back>
</rfc>
