Subject: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

From: Arashmid Akhavain <[email-masked]>
Date: Tue, 22 Feb 2022 15:27:14 -0500

Hi Meiling and all,

Thank you for the new version of the draft and capturing some of the issues
surrounding the use of LEO/VLEO constellations for internet connectivity.

I agree that existing IP routing protocols can face convergence issues when
it comes to satellite networks. IP and existing routing protocols rely on
hierarchy to minimise the impact of link events. Establishing hierarchy in
satellite networks can be very complex due to various movements especially
when it comes to massive constellations.

In polar constellations, the movement at the poles, and the seam plane will
be problematic for existing routing protocols. The issue of course gets
exacerbated in the Walker Delta constellation as the seam effect exists
between every other orbit.

A new method of routing might be required to address this issue. What are
your plans w.r.t to this draft? Have you discussed some of these issues
with any of the working groups?

Best regards,
Arashmid

---

From: Lloyd W <[email-masked]>
Date: Wed, 23 Feb 2022 14:01:15 +1100

That statement is not accurate.

My masters and PhD work explored this very thing extensively - a quarter of a century ago...

http://lloydwood.users.sourceforge.net/Personal/L.Wood/satellite-constellations/double-surface-coverage/

Lloyd Wood
[email-masked]

> On 23 Feb 2022, at 07:27, Arashmid Akhavain <[email-masked]> wrote:
> 
> The issue of course gets exacerbated in the Walker Delta constellation as the seam effect exists between every other orbit.

---

From: Raymond Burkholder <[email-masked]>
Date: Tue, 22 Feb 2022 20:07:22 -0700

On 2022-02-22 1:27 p.m., Arashmid Akhavain wrote:
> I agree that existing IP routing protocols can face convergence issues 
> when it comes to satellite networks. IP and existing routing protocols 
> rely on hierarchy to minimise the impact of link events. 
> Establishing hierarchy in satellite networks can be very complex due 
> to various movements especially when it comes to massive constellations.
>
> In polar constellations, the movement at the poles, and the seam plane 
> will be problematic for existing routing protocols. The issue of 
> course gets exacerbated in the Walker Delta constellation as the 
> seam effect exists between every other orbit.
>
> A new method of routing might be required to address this issue. What 
> are your plans w.r.t to this draft? Have you discussed some of these 
> issues with any of the working groups?
Using standard routing protocols are problematic as they are reactive.  
And due to inter-satellite delays, can take time to re-converge.  I was 
working with a company to come up with an SDN solution where we used TLE 
(Two Line Elements) to compute satellite nearness and then pre-populate 
neighbor entries for installation at pre-arranged times.

In addition, to do this properly, these neighbor entries and routing 
table entries need to be populated based upon distributed path 
computation capabilities (due to the fact that the same ground stations 
are not always in view, and paths need to be adjusted as necessary).

>
> Best regards,
> Arashmid
>
>
> _______________________________________________
> EToSat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/etosat

---

From: <[email-masked]>
Date: Wed, 23 Feb 2022 09:33:17 +0000

If of any interest or support to the discussion on routing for LEO, colleagues of mine at DLR published the following paper last year:

Roth, M, Brandt, H, Bischl, H. Implementation of a geographical routing scheme for low Earth orbiting satellite constellations using intersatellite links. Int J Satell Commun Network. 2021; 39: 92– 107. https://doi.org/10.1002/sat.1361

Then we are now working on SDN in space as enabler for new concepts of routing and network management, as part of an ESA-funded project.

Best Regards,

Tomaso de Cola

————————————————————————
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked]<mailto:[email-masked]>
http://www.dlr.de/kn/institut/abteilungen/san

From: EToSat <[email-masked]> On Behalf Of Raymond Burkholder
Sent: Mittwoch, 23. Februar 2022 04:07
To: [email-masked]
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

I agree that existing IP routing protocols can face convergence issues when it comes to satellite networks. IP and existing routing protocols rely on hierarchy to minimise the impact of link events. Establishing hierarchy in satellite networks can be very complex due to various movements especially when it comes to massive constellations.

In polar constellations, the movement at the poles, and the seam plane will be problematic for existing routing protocols. The issue of course gets exacerbated in the Walker Delta constellation as the seam effect exists between every other orbit.

A new method of routing might be required to address this issue. What are your plans w.r.t to this draft? Have you discussed some of these issues with any of the working groups?
Using standard routing protocols are problematic as they are reactive.  And due to inter-satellite delays, can take time to re-converge.  I was working with a company to come up with an SDN solution where we used TLE (Two Line Elements) to compute satellite nearness and then pre-populate neighbor entries for installation at pre-arranged times.

In addition, to do this properly, these neighbor entries and routing table entries need to be populated based upon distributed path computation capabilities (due to the fact that the same ground stations are not always in view, and paths need to be adjusted as necessary).

Best regards,
Arashmid

EToSat mailing list

[email-masked]<mailto:[email-masked]>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 23 Feb 2022 05:56:13 -0500

I will have a look at tit. Seems similar to what we did in Teledesic in the
good old days :)

Marie-José Montpetit, Ph.D.
[email-masked]

From: [email-masked] <[email-masked]> <[email-masked]>
Reply: [email-masked] <[email-masked]> <[email-masked]>
Date: February 23, 2022 at 4:33:33 AM
To: [email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>
Subject:  Re: [EToSat] New Version Notification for
draft-lhan-problems-requirements-satellite-net-02.txt

If of any interest or support to the discussion on routing for LEO,
colleagues of mine at DLR published the following paper last year:

Roth, M, Brandt, H, Bischl, H. Implementation of a geographical routing
scheme for low Earth orbiting satellite constellations using intersatellite
links. *Int J Satell Commun Network*. 2021; 39: 92– 107.
https://doi.org/10.1002/sat.1361

Then we are now working on SDN in space as enabler for new concepts of
routing and network management, as part of an ESA-funded project.

Best Regards,

Tomaso de Cola

————————————————————————

*Deutsches Zentrum für Luft- und Raumfahrt* (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks |
Oberpfaffenhofen | 82234 Wessling | Germany

*Tomaso de Cola, Ph.D.*
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked]
<[email-masked]>
http://www.dlr.de/kn/institut/abteilungen/san

*From:* EToSat <[email-masked]> *On Behalf Of *Raymond Burkholder
*Sent:* Mittwoch, 23. Februar 2022 04:07
*To:* [email-masked]
*Subject:* Re: [EToSat] New Version Notification for
draft-lhan-problems-requirements-satellite-net-02.txt

Using standard routing protocols are problematic as they are reactive.  And
due to inter-satellite delays, can take time to re-converge.  I was working
with a company to come up with an SDN solution where we used TLE (Two Line
Elements) to compute satellite nearness and then pre-populate neighbor
entries for installation at pre-arranged times.

In addition, to do this properly, these neighbor entries and routing table
entries need to be populated based upon distributed path computation
capabilities (due to the fact that the same ground stations are not always
in view, and paths need to be adjusted as necessary).

Best regards,

Arashmid

EToSat mailing list

[email-masked]

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 23 Feb 2022 10:21:29 -0500

Thank you for the link Lloyd. I was referring to the case where there is
connectivity between the two layers moving in different directions. i.e.
satellites with the 5th ISL.
If there is no need to connect the layers then there won't be a seam like
issue. But traffic might have to take a longer path to destinations.

Taking the case of the Polar constellation with no connectivity across the
seam as an example, traffic will have to move toward the poles and then
wrap around to get to the other side. Which is perfectly fine from the
routing point of view if delay is not a concern.

On Tue, Feb 22, 2022 at 10:01 PM Lloyd W <[email-masked]> wrote:

> The issue of course gets exacerbated in the Walker Delta constellation as
> the seam effect exists between every other orbit.
>
>

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 23 Feb 2022 10:38:59 -0500

This sounds like an interesting approach. The routing system has to deal
with both predictable (majority) and unpredictable link events. Traditional
SDN systems might not be able to perform as the number of nodes goes up
drastically. Is this work public, or proprietary?

On Tue, Feb 22, 2022 at 10:07 PM Raymond Burkholder <[email-masked]>
wrote:

> when it comes to satellite networks. IP and existing routing protocols rely
> on hierarchy to minimise the impact of link events. Establishing hierarchy
> in satellite networks can be very complex due to various movements
> especially when it comes to massive constellations.
>
> will be problematic for existing routing protocols. The issue of course
> gets exacerbated in the Walker Delta constellation as the seam effect
> exists between every other orbit.
>
> EToSat mailing [email-masked]://www.ietf.org/mailman/listinfo/etosat
>
>

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 23 Feb 2022 10:45:57 -0500

Thank you Tomaso,
I will have a look. Pure geographical routing works well when there is no
link down, but it faces issues when the link to the next closer node goes
down. I am interested to see whether the paper you mentioned addresses
those issues.

Best regards,
Arashmid

On Wed, Feb 23, 2022 at 4:33 AM <[email-masked]> wrote:

> Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 |
> [email-masked] <[email-masked]>

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 23 Feb 2022 10:48:44 -0500

On 2/23/2022 10:38 AM, Arashmid Akhavain wrote:
> This sounds like an interesting approach. The routing system has to 
> deal with both predictable (majority) and unpredictable link events. 
> Traditional SDN systems might not be able to perform as the number of 
> nodes goes up drastically. Is this work public, or proprietary?

As one data point, the Minkowski SDN controller that operated Loon's 
stratospheric balloon network and was designed to work for satellite 
constellations as well is described in:

https://storage.googleapis.com/x-prod.appspot.com/files/The%20Loon%20Library.pdf

---

From: Raymond Burkholder <[email-masked]>
Date: Wed, 23 Feb 2022 09:16:57 -0700

> nodes goes up drastically. Is this work public, or proprietary?

Their implementation is proprietary, but many of the concepts are common 
knowledge:

  * based upon TLE information, ground stations can compute satellite
    feasible neighbors
  * using network flow algorithms, feasible paths can be computed
  * there is now enough satellite-local compute available such that
    multiple ground stations can compute these paths and advertise
    upwards, and satellites pick the 'best' suggestion for paths to
    ground (based upon local awareness of rf and link capability/capacity)
  * the flow calculations take in to consideration the sum of path
    latencies on the ground, earth-sky, and satellite-satellite
  * multiple ground stations perform the computation as not all are
    connected upwards at all times

Is there a 'forum' where some of this could be developed in public?

>
> On Tue, Feb 22, 2022 at 10:07 PM Raymond Burkholder 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     I agree that existing IP routing protocols can face convergence
>>     issues when it comes to satellite networks. IP and existing
>>     routing protocols rely on hierarchy to minimise the impact of
>>     link events. Establishing hierarchy in satellite networks can be
>>     very complex due to various movements especially when it comes to
>>     massive constellations.
>>
>>     In polar constellations, the movement at the poles, and the seam
>>     plane will be problematic for existing routing protocols. The
>>     issue of course gets exacerbated in the Walker Delta
>>     constellation as the seam effect exists between every other orbit.
>>
>>     A new method of routing might be required to address this issue.
>>     What are your plans w.r.t to this draft? Have you discussed some
>>     of these issues with any of the working groups?
>     Using standard routing protocols are problematic as they are
>     reactive.  And due to inter-satellite delays, can take time to
>     re-converge.  I was working with a company to come up with an SDN
>     solution where we used TLE (Two Line Elements) to compute
>     satellite nearness and then pre-populate neighbor entries for
>     installation at pre-arranged times.
>
>     In addition, to do this properly, these neighbor entries and
>     routing table entries need to be populated based upon distributed
>     path computation capabilities (due to the fact that the same
>     ground stations are not always in view, and paths need to be
>     adjusted as necessary).
>
>>
>>     Best regards,
>>     Arashmid
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/etosat  <https://www.ietf.org/mailman/listinfo/etosat>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/etosat>
>

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 23 Feb 2022 13:08:04 -0500

Do you mean as an open source initiative? Or more like a formal discussion
in an IETF WG?
I have been looking into LEO/vLEO networks from two point of views:
1- General internet connectivity
2- Integration with mobile networks.

Ad-Hoc networking might be a relevant forum in IETF. We might want to talk
to Alvaro or Erik Kline at some point and seek their opinions when we have
more concrete proposals. IETF Hackathon might be a good venue from a
prototyping point of view.

As for integration with mobile networks, 3GPP started some ongoing work in
this area at the end of its release 16 (I don't quite remember, it could be
release 17) . They do have a long way to go though; as in some of the
proposals they are planning to place a gNB in the satellite. The more
immediate scenario which is also simpler to tackle is RAN to mobile core
connectivity via the LEO network.

Best regards,
Arashmid

On Wed, Feb 23, 2022 at 11:17 AM Raymond Burkholder <[email-masked]>
wrote:

>    - based upon TLE information, ground stations can compute satellite
>    feasible neighbors
>    - using network flow algorithms, feasible paths can be computed
>    - there is now enough satellite-local compute available such that
>    multiple ground stations can compute these paths and advertise upwards, and
>    satellites pick the 'best' suggestion for paths to ground (based upon local
>    awareness of rf and link capability/capacity)
>    - the flow calculations take in to consideration the sum of path
>    - multiple ground stations perform the computation as not all are
>> table entries need to be populated based upon distributed path computation

---

From: Nicolas Kuhn <[email-masked]>
Date: Wed, 23 Feb 2022 21:12:22 +0100

Thanks Tomaso for the interesting pointer.

This kind of work is very useful when it comes to design routing strategies
for mega constellation systems.
If there are any public outputs of the SDN approach, I would be very
interested in having a look.

What I think would be also very interesting to discuss in terms of IETF
perspective is to assess whether existing routing mechanisms (OSPF,
SegmentRouting) require specific changes for the use case.

Nico

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 23 Feb 2022 12:20:36 -0800

In Teledesic (750 then 288 satellites) we were doing some onboard “tag
switching” (ancestor of MPLS but Teledesic for me was 1996-2000). It was of
course not SDN but the tags could be dynamic.

mjm

From: Nicolas Kuhn <[email-masked]>
<[email-masked]>
Reply: Nicolas Kuhn <[email-masked]>
<[email-masked]>
Date: February 23, 2022 at 3:12:46 PM
To: [email-masked] <[email-masked]> <[email-masked]>
Cc: [email-masked] <[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>
Subject:  Re: [EToSat] New Version Notification for
draft-lhan-problems-requirements-satellite-net-02.txt

Nico

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 23 Feb 2022 15:36:22 -0500

That could be another alternative.
The question that I have been struggling with is whether and how satellite
networks can benefit from standardisations. These networks are proprietary
(at least for the time being). It is difficult to imagine satellites in a
multi-vendor ecosystem.

That's why I asked what the authors of this draft intended to do.

Arashmid

On Wed, Feb 23, 2022 at 3:12 PM Nicolas Kuhn <[email-masked]>
wrote:

> This kind of work is very useful when it comes to design routing
> strategies for mega constellation systems.

---

From: Raymond Burkholder <[email-masked]>
Date: Wed, 23 Feb 2022 13:44:09 -0700

On 2022-02-23 1:36 p.m., Arashmid Akhavain wrote:
> The question that I have been struggling with is whether and how 
> satellite networks can benefit from standardisations. These networks 
> are proprietary (at least for the time being). It is difficult to 
> imagine satellites in a multi-vendor ecosystem.

In the not too distant future (as in, it is being worked on right now), 
some operators will be carrying the traffic of other operators.  ie, 
backbone operators in the sky will have a good foot print of ground 
stations, and will be providing backbone operations to satellite 
operators who don't have a large ground footprint (this is the sky to 
sky to ground scenario, vs the broadband up-down scenario).

There then needs to be some sort of interoperability of the carrier vs 
the end-user in terms of how to get a endnode-satellite's data 
encapsulated across a carrier's satellite network down to the ground and 
then over to the subscriber's site in a real-time fashion.

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 23 Feb 2022 16:16:36 -0500

Interesting scenario! Thank you for pointing it out Raymond.

---

From: Lin Han <[email-masked]>
Date: Wed, 23 Feb 2022 22:14:45 +0000

Good question. Actually this has been studied by 3gpp. 3gpp has proposed the Satellite-based NG-RAN architectures in TR38.821. In this architecture, satellite network is an infrastructure for 5G. In its proposed “Regenerative payload” mode, satellite network (with ISL) should provide the IP connectivity for wireless access and NTN integration. Different SP is able to use satellite as wireless access network. From this expectation, satellite network will be access and backhaul network for wireless, the standardized protocol/methods are expected.
I will have a slide in the next IETF meeting to explain more details about the problems.

Regards

Lin

From: Arashmid Akhavain <[email-masked]>
Sent: Wednesday, February 23, 2022 12:36 PM
To: Nicolas Kuhn <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

That could be another alternative.
The question that I have been struggling with is whether and how satellite networks can benefit from standardisations. These networks are proprietary (at least for the time being). It is difficult to imagine satellites in a multi-vendor ecosystem.

Arashmid

On Wed, Feb 23, 2022 at 3:12 PM Nicolas Kuhn <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Tomaso for the interesting pointer.

This kind of work is very useful when it comes to design routing strategies for mega constellation systems.
If there are any public outputs of the SDN approach, I would be very interested in having a look.

What I think would be also very interesting to discuss in terms of IETF perspective is to assess whether existing routing mechanisms (OSPF, SegmentRouting) require specific changes for the use case.

Nico

On Wed, Feb 23, 2022 at 10:33 AM <[email-masked]<mailto:[email-masked]>> wrote:
If of any interest or support to the discussion on routing for LEO, colleagues of mine at DLR published the following paper last year:

Best Regards,

Tomaso de Cola

————————————————————————

From: EToSat <[email-masked]<mailto:[email-masked]>> On Behalf Of Raymond Burkholder
Sent: Mittwoch, 23. Februar 2022 04:07
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Best regards,
Arashmid

EToSat mailing list

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 23 Feb 2022 17:41:35 -0800

Where do you intend to present at 113?

From: Lin Han <[email-masked]> <[email-masked]>
Reply: Lin Han <[email-masked]> <[email-masked]>
Date: February 23, 2022 at 5:15:16 PM
To: Arashmid Akhavain <[email-masked]>
<[email-masked]>, Nicolas Kuhn <[email-masked]>
<[email-masked]>
Cc: [email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>
Subject:  Re: [EToSat] New Version Notification for
draft-lhan-problems-requirements-satellite-net-02.txt

Good question. Actually this has been studied by 3gpp. 3gpp has proposed
the Satellite-based NG-RAN architectures in TR38.821. In this architecture,
satellite network is an infrastructure for 5G. In its proposed
“Regenerative payload” mode, satellite network (with ISL) should provide
the IP connectivity for wireless access and NTN integration. Different SP
is able to use satellite as wireless access network. From this expectation,
satellite network will be access and backhaul network for wireless, the
standardized protocol/methods are expected.

I will have a slide in the next IETF meeting to explain more details about
the problems.

Regards

Lin

*From:* Arashmid Akhavain <[email-masked]>
*Sent:* Wednesday, February 23, 2022 12:36 PM
*To:* Nicolas Kuhn <[email-masked]>
*Cc:* [email-masked]; [email-masked]; [email-masked]
*Subject:* Re: [EToSat] New Version Notification for
draft-lhan-problems-requirements-satellite-net-02.txt

Arashmid

Nico

Best Regards,

Tomaso de Cola

————————————————————————

*Tomaso de Cola, Ph.D.*

Best regards,

Arashmid

EToSat mailing list

[email-masked]

---

From: Lin Han <[email-masked]>
Date: Thu, 24 Feb 2022 02:28:40 +0000

Hi, Marie,
I have requested session in RTGWG, INTAREA. Probably in DMM as well.
Since there is no dedicated WG for the satellite networking work in IETF now, the potential solutions may be crossing different WGs.
Welcome all who are interested in this area for future Internet to attend and comment.

Thanks

Lin

From: Marie-Jose Montpetit <[email-masked]>
Sent: Wednesday, February 23, 2022 5:42 PM
To: Nicolas Kuhn <[email-masked]>; Lin Han <[email-masked]>; Arashmid Akhavain <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Marie-José Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>

From: Lin Han <[email-masked]><mailto:[email-masked]>
Reply: Lin Han <[email-masked]><mailto:[email-masked]>
Date: February 23, 2022 at 5:15:16 PM
To: Arashmid Akhavain <[email-masked]><mailto:[email-masked]>, Nicolas Kuhn <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Good question. Actually this has been studied by 3gpp. 3gpp has proposed the Satellite-based NG-RAN architectures in TR38.821. In this architecture, satellite network is an infrastructure for 5G. In its proposed "Regenerative payload" mode, satellite network (with ISL) should provide the IP connectivity for wireless access and NTN integration. Different SP is able to use satellite as wireless access network. From this expectation, satellite network will be access and backhaul network for wireless, the standardized protocol/methods are expected.
I will have a slide in the next IETF meeting to explain more details about the problems.

Regards

Lin

From: Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 23, 2022 12:36 PM
To: Nicolas Kuhn <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Arashmid

Nico

Roth, M, Brandt, H, Bischl, H. Implementation of a geographical routing scheme for low Earth orbiting satellite constellations using intersatellite links. Int J Satell Commun Network. 2021; 39: 92- 107. https://doi.org/10.1002/sat.1361<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1002%2Fsat.1361&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mtxCKvZudy4AEZuIJMpanXAtsKkbiXEbfswqnOp%2F%2Bqs%3D&reserved=0>

Best Regards,

Tomaso de Cola

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked]<mailto:[email-masked]>
http://www.dlr.de/kn/institut/abteilungen/san<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dlr.de%2Fkn%2Finstitut%2Fabteilungen%2Fsan&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=v0TeFXoH1quZuSYzUebtSd0XVMcqzpbqRsXmS1qcK5I%3D&reserved=0>

Best regards,
Arashmid

EToSat mailing list

https://www.ietf.org/mailman/listinfo/etosat<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>

_______________________________________________
EToSat mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/etosat<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>
_______________________________________________
EToSat mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/etosat<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>
_______________________________________________
EToSat mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/etosat<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>

---

From: "Meiling Chen" <[email-masked]>
Date: Fri, 25 Feb 2022 11:05:12 +0800

Hi all,
Indeed, there are still many issues to be discussed in satellite networks and the issues involved will also span multiple working groups.
No matter which layer of the protocol, the existing protocols may have some problems that are not applicable to satellite networks.
Although 3GPP is studying how to integrate satellite networks with terrestrial networks, there is no definite architecture yet.
The technology and background related to satellite networks are very professional. Why not consider setting up a special working group to do research or standardization.

Best,
Meiling

From: Lin Han
Date: 2022-02-24 10:28
To: Marie-Jose Montpetit; Nicolas Kuhn; Arashmid Akhavain
CC: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
Hi, Marie,
I have requested session in RTGWG, INTAREA. Probably in DMM as well.
Since there is no dedicated WG for the satellite networking work in IETF now, the potential solutions may be crossing different WGs.
Welcome all who are interested in this area for future Internet to attend and comment.
 
Thanks
 
Lin

 

From: Lin Han <[email-masked]>
Reply: Lin Han <[email-masked]>
Date: February 23, 2022 at 5:15:16 PM
To: Arashmid Akhavain <[email-masked]>, Nicolas Kuhn <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject:  Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt 

Regards
 
Lin

 
 
Arashmid
 
On Wed, Feb 23, 2022 at 3:12 PM Nicolas Kuhn <[email-masked]> wrote:
Thanks Tomaso for the interesting pointer. 

 
Nico

 
 
Best Regards,
 
Tomaso de Cola

———————————————————————— 

 

 
Best regards,
Arashmid

_______________________________________________EToSat mailing [email-masked]://www.ietf.org/mailman/listinfo/etosat

---

From: Arashmid Akhavain <[email-masked]>
Date: Fri, 25 Feb 2022 10:06:17 -0500

As I mentioned earlier, 3GPP's immediate concern (at least in release 18)
is RAN to mobile core connectivity via satellite networks. In this
scenario, 3GPP considers the satellite network to be a transport network.
They will run their protocols (N2 and N3 interface in their SBA) over the
satellite network with IP connections at both RAN and the core side of the
mobile network. There are a lot of issues that need to be addressed at 3GPP
level of course to support this. But since in this scenario, the satellite
network is treated as transport , 3GPP assumes that connectivity and
routing  will be given and fully supported by the underlay transport.

If there is interest, we can perhaps ask IETF to provide us with a
conference port during IETF 113 to discuss some of the issues and talk
about the next step.

Best regards,
Arashmid

On Thu, Feb 24, 2022 at 10:05 PM Meiling Chen <[email-masked]>
wrote:

> Hi all,
> Indeed, there are still many issues to be discussed in satellite networks
> and the issues involved will also span multiple working groups.
> No matter which layer of the protocol, the existing protocols may have
> some problems that are not applicable to satellite networks.
> Although 3GPP is studying how to integrate satellite networks with
> terrestrial networks, there is no definite architecture yet.
> The technology and background related to satellite networks are very
> professional. Why not consider setting up a special working group to do
> research or standardization.
>
> Best,
> Meiling
>
> *From:* Lin Han <[email-masked]>
> *Date:* 2022-02-24 10:28
> *To:* Marie-Jose Montpetit <[email-masked]>; Nicolas Kuhn
> <[email-masked]>; Arashmid Akhavain
> <[email-masked]>
> *CC:* [email-masked]; [email-masked] <[email-masked]>;
> [email-masked]
> Since there is no dedicated WG for the satellite networking work in IETF
> now, the potential solutions may be crossing different WGs.
>
> *From:* Marie-Jose Montpetit <[email-masked]>
> *Sent:* Wednesday, February 23, 2022 5:42 PM
> *To:* Nicolas Kuhn <[email-masked]>; Lin Han <
> [email-masked]>; Arashmid Akhavain <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1002%2Fsat.1361&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mtxCKvZudy4AEZuIJMpanXAtsKkbiXEbfswqnOp%2F%2Bqs%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dlr.de%2Fkn%2Finstitut%2Fabteilungen%2Fsan&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=v0TeFXoH1quZuSYzUebtSd0XVMcqzpbqRsXmS1qcK5I%3D&reserved=0>
>
>
>
>
>
>
>
> https://www.ietf.org/mailman/listinfo/etosat <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fetosat&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4HHvaFqoJH3RYDRQnWubfzqeKQLrUKaaFpgFxgX9V9k%3D&reserved=0>
>
>

---

From: Lin Han <[email-masked]>
Date: Fri, 25 Feb 2022 18:26:24 +0000

>>> But since in this scenario, the satellite network is treated as transport , 3GPP assumes that connectivity and routing  will be given and fully supported by the underlay transport.

Right, the basic IP connectivity for satellite network is not there yet even 3GPP assumes it in the architecture for satellite-based NG-RAN. Without IP connectivity, all 3GPP interfaces NG/Xn/F1/F2 will not work.
The issue is not that simple as few people assumed. We cannot use current routing or SDN solution to massive satellite constellation directly. Lots challenges and reworks are expected. The mobility of satellite network is unprecedented compared with the mobile scenarios in MIP, PMIP, DMM, etc. Basically, the difference is “infrastructure moving” vs “end device moving”.
So, IETF should work to provide technologies and solutions.

Regards

Lin

From: Arashmid Akhavain <[email-masked]>
Sent: Friday, February 25, 2022 7:06 AM
To: Meiling Chen <[email-masked]>
Cc: Lin Han <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; Nicolas Kuhn <[email-masked]>; EToSat <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

As I mentioned earlier, 3GPP's immediate concern (at least in release 18) is RAN to mobile core connectivity via satellite networks. In this scenario, 3GPP considers the satellite network to be a transport network. They will run their protocols (N2 and N3 interface in their SBA) over the satellite network with IP connections at both RAN and the core side of the mobile network. There are a lot of issues that need to be addressed at 3GPP level of course to support this. But since in this scenario, the satellite network is treated as transport , 3GPP assumes that connectivity and routing  will be given and fully supported by the underlay transport.

If there is interest, we can perhaps ask IETF to provide us with a conference port during IETF 113 to discuss some of the issues and talk about the next step.

Best regards,
Arashmid

On Thu, Feb 24, 2022 at 10:05 PM Meiling Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best,
Meiling

From: Lin Han<mailto:[email-masked]>
Date: 2022-02-24 10:28
To: Marie-Jose Montpetit<mailto:[email-masked]>; Nicolas Kuhn<mailto:[email-masked]>; Arashmid Akhavain<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
Hi, Marie,
I have requested session in RTGWG, INTAREA. Probably in DMM as well.
Since there is no dedicated WG for the satellite networking work in IETF now, the potential solutions may be crossing different WGs.
Welcome all who are interested in this area for future Internet to attend and comment.

Thanks

Lin

From: Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 23, 2022 5:42 PM
To: Nicolas Kuhn <[email-masked]<mailto:[email-masked]>>; Lin Han <[email-masked]<mailto:[email-masked]>>; Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Regards

Lin

Arashmid

Nico

Roth, M, Brandt, H, Bischl, H. Implementation of a geographical routing scheme for low Earth orbiting satellite constellations using intersatellite links. Int J Satell Commun Network. 2021; 39: 92– 107. https://doi.org/10.1002/sat.1361<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1002%2Fsat.1361&data=04%7C01%7Clin.han%40futurewei.com%7C354956d8750d41b3bdaf08d9f736cc1a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637812637013196648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mtxCKvZudy4AEZuIJMpanXAtsKkbiXEbfswqnOp%2F%2Bqs%3D&reserved=0>

Best Regards,

Tomaso de Cola

————————————————————————

Best regards,
Arashmid

EToSat mailing list

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 25 Feb 2022 14:04:39 -0500

On 2/25/2022 1:26 PM, Lin Han wrote:
>
> >>> But since in this scenario, the satellite network is treated as 
> transport , 3GPP assumes that connectivity and routing  will be given 
> and fully supported by the underlay transport.
>
> Right, the basic IP connectivity for satellite network is not there 
> yet even 3GPP assumes it in the architecture for satellite-based 
> NG-RAN. Without IP connectivity, all 3GPP interfaces NG/Xn/F1/F2 will 
> not work.
>
> The issue is not that simple as few people assumed. We cannot use 
> current routing or SDN solution to massive satellite constellation 
> directly. Lots challenges and reworks are expected. The mobility of 
> satellite network is unprecedented compared with the mobile scenarios 
> in MIP, PMIP, DMM, etc. Basically, the difference is “infrastructure 
> moving” vs “end device moving”.
>

Unless constellation operators or vendors are asking for some new 
standard or interoperability spec for this, then I don't think this is 
valuable to pursue.  Who exactly wants it?

IMHO, the things you mention are understood and designed around already.

---

From: "Meiling Chen" <[email-masked]>
Date: Sat, 26 Feb 2022 08:23:12 +0800

Hi Wesley,

3GPP has regarded satellite network as 5G NG-RAN infrastructure, Network Operators need and want to be able to use satellite networks to provide services, the owner of satellite network should use the technology provided by IETF instead of private technology which is used currently. To develop, we need to change the stateof privatization. From the perspective of economy, satellite networks will be shared in the future. It is impossible for each Service Provider to send a large satellite network, sure you know that.  Therefore, the technology of satellite network should be dominated by IETF and 3GPP like the current Internet and wireless technology.

Best,
Meiling
 
From: Wesley Eddy
Date: 2022-02-26 03:04
To: etosat

Unless constellation operators or vendors are asking for some new standard or interoperability spec for this, then I don't think this is valuable to pursue.  Who exactly wants it?
IMHO, the things you mention are understood and designed around already.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 25 Feb 2022 17:49:04 -0800

On 2/25/2022 4:23 PM, Meiling Chen wrote:

> 3GPP has regarded satellite network as 5G NG-RAN infrastructure, Network Operators need and want to be able to use satellite networks to provide services, the owner of satellite network should use the technology provided by IETF instead of private technology which is used currently.

3GPP solves a specific problem: standardize the communication between 
mobile phone and wireless network so phones can work and roam on 
multiple networks. I don't think we are close to the point were 
satellite phones can be designed to work on multiple satellite networks. 
Of course if multiple satellite network operators and device make to the 
IETF and asked to develop such standards, the IETF would most probably 
hear them. But the satellite operators are certainly not doing that now.

EToSat has been addressing a different but related problem: make sure 
that end-to-end protocols like TCP, TLS, HTTP or QUIC work well on paths 
that include satellite links or satellite networks. Up to date, that 
work has mostly addressed the geostationary satellite, dealing with long 
latency. Constellations of low orbit satellites do not suffer too much 
from the long latency problem, but may introduce other issues such as 
maybe variable bit rate or variable latency -- I say maybe because this 
is just a guess. If there are such issues, we may need to improve 
transport protocols or their implementation. But I have not heard of 
specific requests to address that so far.

>   To develop, we need to change the stateof privatization. From the perspective of economy, satellite networks will be shared in the future. It is impossible for each Service Provider to send a large satellite network, sure you know that.  Therefore, the technology of satellite network should be dominated by IETF and 3GPP like the current Internet and wireless technology.

On the contrary, each existing provider is using their own set of 
satellites, be it Inmarsat, Iridium, Globalstar, SpaceX or their future 
competitors. The IETF is not in a position to regulate the industry and 
change that practice.

-- Christian Huitema

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 26 Feb 2022 07:48:26 -0500

Snip/snip

-- Christian Huitema

Exactly.

---

From: Arashmid Akhavain <[email-masked]>
Date: Mon, 28 Feb 2022 11:16:05 -0500

In addition to standardising the communications between the UEs and the
mobile network, 3GPP defines every single aspect of the overlay network
from its required NFs to the specifications of all the protocols and
interfaces. Communications between RAN and mobile core is handled through a
specific set of 3GPP defined protocols which up to now assumed a stable and
reliable transport underlay. The data plane for example uses GPRS (GTP is
carried in UDP) to connect user plane functions (UPFs). I do believe that
there are routing and forwarding challenges when it comes to mega
constellations.

Having said that however, as per my comment earlier, I share Christian's
point of view. Satellite networks, at least for now, are close ecosystems.
Existing satellite providers employ their own proprietary mechanisms to
connect their satellites to one another. There is no
interoperability requirement between satellite operators so far. Well...at
least I haven't seen one yet. Without such requirements, there won't be any
need for standardisation.

Now, when I raised this concern earlier, our colleague, Raymond Burkholder
in his reply wrote

*"In the not too distant future (as in, it is being worked on right
now),some operators will be carrying the traffic of other operators.
ie,backbone operators in the sky will have a good foot print of
groundstations, and will be providing backbone operations to
satelliteoperators who don't have a large ground footprint (this is the sky
tosky to ground scenario, vs the broadband up-down scenario).There then
needs to be some sort of interoperability of the carrier vsthe end-user in
terms of how to get a endnode-satellite's dataencapsulated across a
carrier's satellite network down to the ground andthen over to the
subscriber's site in a real-time fashion."*

This operation/business model is interesting from the standardisation point
of view and something we should perhaps find out more about.

@ Raymond Burkholder: Do you have any pointers you can share?

Best regards,
Arashmid

On Fri, Feb 25, 2022 at 8:57 PM Christian Huitema <[email-masked]>
wrote:

> > 3GPP has regarded satellite network as 5G NG-RAN infrastructure, Network
> Operators need and want to be able to use satellite networks to provide
> services, the owner of satellite network should use the technology provided
> by IETF instead of private technology which is used currently.
>
> >   To develop, we need to change the stateof privatization. From the
> perspective of economy, satellite networks will be shared in the future. It
> is impossible for each Service Provider to send a large satellite network,
> sure you know that.  Therefore, the technology of satellite network should
> be dominated by IETF and 3GPP like the current Internet and wireless
> technology.
>