Author Topic: Starlink : General Discussion - Thread 1  (Read 1217247 times)

Offline go4mars

  • Senior Member
  • *****
  • Posts: 3748
  • Earth
  • Liked: 158
  • Likes Given: 3463
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #340 on: 01/21/2015 05:28 pm »
I wonder what portion was Fidelity, and what portion was Google.  Is Larry mainly giving Google's name to provide brand equity while Fidelity puts in $950 million for example?

Also, I suspect this is just opening the door to get things where they are a lot more investible as a subsidiary later.  Annnnnd... It's Elon.  3 years from now, he could provide a low interest corporate bond for $10+ billion.  If he buys a pile of them himself, people will shrug and figure it's probably safe - assuming the Gigafactory(s) and Tesla are doing well, and the satellite biz and BFR are a lot further along. 
Elasmotherium; hurlyburly Doggerlandic Jentilak steeds insouciantly gallop in viridescent taiga, eluding deluginal Burckle's abyssal excavation.

Offline nadreck

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #341 on: 01/21/2015 05:46 pm »
I wonder what portion was Fidelity, and what portion was Google.  Is Larry mainly giving Google's name to provide brand equity while Fidelity puts in $950 million for example?

Also, I suspect this is just opening the door to get things where they are a lot more investible as a subsidiary later.  Annnnnd... It's Elon.  3 years from now, he could provide a low interest corporate bond for $10+ billion.  If he buys a pile of them himself, people will shrug and figure it's probably safe - assuming the Gigafactory(s) and Tesla are doing well, and the satellite biz and BFR are a lot further along.

I am curious about the apportionment as well, I was more thinking it was the other way around. Fidelity is what lends credibility both to SpaceX and Elon who may be a household name but not necessarily taken seriously in the investment world. Google has a big war chest (60G$) and they have a history of making big investments in technology that is tangential to their existing operations.  Fidelity on the other hand does not get named like this in 'exotic' ventures usually. They are investors in a wide variety of things, and often seen as astute investors (I take notice when Fidelity, Berkshire Hatheway,  Ontario Teachers Pension Plan, GE and a few other large institutional investors who seem to use similar investing logic as me) suddenly invest in something I already pay attention to.
It is all well and good to quote those things that made it past your confirmation bias that other people wrote, but this is a discussion board damnit! Let us know what you think! And why!

Offline macpacheco

  • Full Member
  • ****
  • Posts: 891
  • Vitoria-ES-Brazil
  • Liked: 368
  • Likes Given: 3041
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #342 on: 01/21/2015 05:56 pm »
And the global routing table will have to be updated every few seconds. This is a hard problem.
This is BGP's hard problem though, no? It doesn't seem like SpaceX has to solve it.

There is also only limited and bounded queuing at internal nodes, the small tag and limited queuing means that the switching can be performed all in hardware, with software only used to update the tag to route map(s).
That describes most routers handling large scale traffic on the internet, no? Software can't do line rate forwarding with 100 gigabit so there is no choice. The way things are scaling seems to push things farther in that direction over time, these days large datacenters are doing L3 (iBGP etc) to the top of rack.

This means that when a packet is tagged at the network it is guaranteed to reach the far end (with quality of service guarantees).
Unless otherwise indicated ElonSat seems like a "best effort" system.
Much easier to just use an ethernet+vlan transport system. The ground system establish routing protocols, find other routers, when the ground sends a packet, it tells the sat system which router this is intended to (MAC address of the router). Then the whole satellite cloud would just need to function as a huge ethernet switch, implementing an rSTP protocol (wayyy simpler than BGP). VLAN is used to separate one dedicated customer from another. The whole forwarding plane must be implemented as FPGA or ASIC in order to handle a hundred Gbps of aggregate bandwidth per sat. Many large Cisco routers are implemented as FPGA, allows lower clock speeds with orders of magnitude more forwarding speed than pure software solutions.
PS: I'm a performance guy, that tends to do everything KISS. SpaceX might have more complex ideas.
Looking for companies doing great things for much more than money

Online MikeAtkinson

  • Full Member
  • ****
  • Posts: 1980
  • Bracknell, England
  • Liked: 784
  • Likes Given: 120
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #343 on: 01/21/2015 06:13 pm »
The satellites will have to know the global routing table and know which satellites are near which ground stations.

And the global routing table will have to be updated every few seconds. This is a hard problem.


Nowadays there are several proposal/techniques for handle this and others issues. See for example https://tools.ietf.org/html/rfc5177.

IMO, what is (slightly) more concerning, is the depletion of IPv4 address space, but, who knows, maybe this could be the 'killer application' for a real deployement of IPv6.

What I was trying to describe was MPLS switching (e.g. http://www.rfc-editor.org/rfc/rfc3031.txt) and its application to ATM (e.g. http://www.rfc-editor.org/rfc/rfc3035.txt). What we did fed through into those and similar MPLS standards before 2002, when Nortel gave this up (most of the team was made redundant in 2000).

So the satellite could be something like a Label Switch Router, where every satellite is both an ingress/egress node and a transit node, where the logical transit node handles the inter-satellite links (and one link to the logical ingress/egress node). The label tables need to be updated every few seconds, but they can be precomputed in advance by the network control centre. I'm 15 years out of date (since then I've worked on speech recognition, mapping software, mobile phone software and am currently working on a IDE for an analytic database) so I'm pretty rusty on this now, but I don't think BGP is a particularly good match for a dynamic satellite network.

Online MikeAtkinson

  • Full Member
  • ****
  • Posts: 1980
  • Bracknell, England
  • Liked: 784
  • Likes Given: 120
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #344 on: 01/21/2015 06:55 pm »

Much easier to just use an ethernet+vlan transport system. The ground system establish routing protocols, find other routers, when the ground sends a packet, it tells the sat system which router this is intended to (MAC address of the router).

The problem with this is how does it know the MAC address of the router it is intended for. That is at the other end of the satellite network. So you need to distribute these MAC addresses. You also need to distribute the IP to router information.

An ethernet like system does not work well on a shared bandwidth uplink where none of the transmitters can hear the others. The only way they will know about collisions is when the far end sends a TCP retransmission request.

The way we solved this for WISDOM is to have a fixed frame for the uplink consisting of a large number of cells. Each ground station first requests some bandwidth on shared cells (a collision means that they don't get the bandwidth and have to request it again after some random timeout). The satellite allocates some of the uplink cells to each ground station that has requested it, they can ask for more, or relinquish it depending on their past data traffic uplink profile. These changes of bandwidth come in the cells allocated to the ground station, so there are no further collisions. We used ATM cells with a simple propriety routing protocol, there were lots of beams and few intra-satellite links, almost all the time data would flow from one of the beams to another on the same satellite. Some of the beams were dedicated to links to network interconnect ground stations which had full use of the entire beam. The satellites were basically an ATM switch, with very little software, both the ATM switching and uplink bandwidth allocation could be done entirely in hardware.


Offline Space Ghost 1962

  • Senior Member
  • *****
  • Posts: 2780
  • Whatcha gonna do when the Ghost zaps you?
  • Liked: 2925
  • Likes Given: 2247
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #345 on: 01/21/2015 07:01 pm »
Google has long had significant space ambitions for years. This is an adequate vehicle for them to exploit.

Back in the late 90's with the emergence of the "dot.com's", bandwidth was priced by providers as a proportion of the "site to user" revenue chain. This hobbled Google and others in its infancy for communicating distributed updates, which were done between coasts then on a weekly basis to reduce cost. Microsoft's Jim Gray told me at the time that Microsoft mailed boxes of tapes and hard drives by parcel at that time because it was cheaper.

Then Google started a process of buying up "dark fiber", which was then extremely scarce because telco's wanted to hold-off more ISPs that were killing the ILEC/CLEC scene. They used the peerage as a secondary revenue channel to pay off the acquisitions, and started doing distributed updates much more frequently. The excess bandwidth allowed them to acquire YouTube and undercut everyone on video bandwidth pricing, using the prior mentioned bandwidth pricing model to slay competition, including those in Hollywood/media like Sony et al.

Google Earth is a GIS that can convey sensor data in real time. They can connect bandwidth and information to a wide variety of channels/consumers/needs worldwide. It's a high growth move for them, like dark fiber was.

So look at the comparison. Boeing and Lockheed have a deep pocket in the US govt for significant sat tech on orbit, with SC/LV operations for that flow. Its the primary point of ULA.

Google is the deep pocket for SpaceX next gen SC/LV operations for much larger operations than Boeing/Lockheed/ULA - by a factor of 6x! It has the potential of being the largest space business on the planet, all vertically integrated. IF it plays out.

So its does not matter if ULA holds on to US govt SC business. In other words, commercial SC business just got disrupted like LV business is being.

And in like way, if the economics for commercial launch severely undercut govt/institutional launch, the govts/institutions costs radically increase until unaffordable. Both LV's, and the SC's that make use of them!

This is a big deal! In effect that 1B is "seed" investment for a trillion dollar market bet. And Google sees it as a "no brainer".

Offline macpacheco

  • Full Member
  • ****
  • Posts: 891
  • Vitoria-ES-Brazil
  • Liked: 368
  • Likes Given: 3041
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #346 on: 01/21/2015 07:02 pm »

Much easier to just use an ethernet+vlan transport system. The ground system establish routing protocols, find other routers, when the ground sends a packet, it tells the sat system which router this is intended to (MAC address of the router).

The problem with this is how does it know the MAC address of the router it is intended for. That is at the other end of the satellite network. So you need to distribute these MAC addresses. You also need to distribute the IP to router information.

An ethernet like system does not work well on a shared bandwidth uplink where none of the transmitters can hear the others. The only way they will know about collisions is when the far end sends a TCP retransmission request.

The way we solved this for WISDOM is to have a fixed frame for the uplink consisting of a large number of cells. Each ground station first requests some bandwidth on shared cells (a collision means that they don't get the bandwidth and have to request it again after some random timeout). The satellite allocates some of the uplink cells to each ground station that has requested it, they can ask for more, or relinquish it depending on their past data traffic uplink profile. These changes of bandwidth come in the cells allocated to the ground station, so there are no further collisions. We used ATM cells with a simple propriety routing protocol, there were lots of beams and few intra-satellite links, almost all the time data would flow from one of the beams to another on the same satellite. Some of the beams were dedicated to links to network interconnect ground stations which had full use of the entire beam. The satellites were basically an ATM switch, with very little software, both the ATM switching and uplink bandwidth allocation could be done entirely in hardware.
MAC learning is a basic function performed by every ethernet switch. Every ethernet packet has a source MAC address, the MAC address is saved with the incoming port as the return path. The downside of this method is that when packets are sent to a unlearned/offline MAC address, it must be handled as a broadcast (sent to all nodes). But using VLAN means each VLAN has its own MAC learning space and only ports authorized for that VLAN get broadcasts.

ATM is an obsolete protocol in land based networks. The trend is everything ethernet. In many cases packets have their ethernet headers anyways, while ATM is a totally extra layer. Today most routing is already done using gigabit/10 gig/40 gig/100 gig pure ethernet links, typically running on top of WDM/DWDM optical multiplexing systems.
« Last Edit: 01/21/2015 09:53 pm by macpacheco »
Looking for companies doing great things for much more than money

Offline nadreck

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #347 on: 01/21/2015 09:44 pm »
RE Fidelity Investment in SpaceX

http://money.cnn.com/2015/01/21/investing/spacex-fidelity-elon-musk/

Ignore the video (at least as far as finding out Fidelity's involvement), read the article, Fidelity will disclose which of its mutual funds bought how much of SpaceX when they publish their month or quarter end reports.
It is all well and good to quote those things that made it past your confirmation bias that other people wrote, but this is a discussion board damnit! Let us know what you think! And why!

Offline ArbitraryConstant

  • Senior Member
  • *****
  • Posts: 2014
  • Liked: 628
  • Likes Given: 311
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #348 on: 01/21/2015 09:55 pm »
Much easier to just use an ethernet+vlan transport system.
Disagree, I think an ethernet type scheme would be untenable at this scale. The reliance on broadcast and the size of the forwarding tables would be deal breakers.

The whole forwarding plane must be implemented as FPGA or ASIC in order to handle a hundred Gbps of aggregate bandwidth per sat. Many large Cisco routers are implemented as FPGA, allows lower clock speeds with orders of magnitude more forwarding speed than pure software solutions.
PS: I'm a performance guy, that tends to do everything KISS. SpaceX might have more complex ideas.
Due to Moore's Law the winning trades are constantly shifting. The reason L3 schemes have pulled ahead in the last few years is due to this. The software to implement BGP is not trivial, however the hardware required to host the software is. Your phone would be overkill unless you exercise really exceptional asceticism.

The way you get the insane forwarding rates with BGP or another L3 scheme is having BGP build the forwarding tables and program them into TCAMs. The bigger you want the TCAM, the slower it is. This is why datacenters are going to L3 to the top of rack, the decision is driven by performance. I believe eg Facebook has published notes on this. The TCAM required to hold the MAC tables for the datacenter is slower than the TCAM required to hold the routing tables for the datacenter.

I think similar considerations would apply for the satellite network.

I'm pretty rusty on this now, but I don't think BGP is a particularly good match for a dynamic satellite network.
I agree with the reasoning behind this, but still think the satellites will need full global routing tables which are only defined in terms of BGP. This implies a two layer scheme.

On ingress of ground traffic the packets would be encapsulated in some scheme that's internal to the satellite network. I'm not sure any existing scheme that I know of is a good match for this, so let's say for the sake of argument that this is part of the engineering work to be done for the system. Either way the encapsulation has to be done with some knowledge of where the egress has to happen, even if that's a network not directly connected to the satellite network. This is why global routing tables are needed. Once it's in though, the packet is forwarded satellite to satellite using the internal scheme, and only decapsulated when it reaches the egress point.

So there'd be a forwarding plane that only deals with the internal satellite routing protocol, and there'd be the ingress/egress plane that knows the global routing table.

One trade I thought about would be customer equipment having the full global routing table and doing the encapsulation itself, but that's probably untenable to keep updated (and you can't trust the customer equipment in any case).

Offline MP99

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #349 on: 01/21/2015 10:08 pm »
There's no latency advantage if you just terminate the connection at a local ISP.

It seems to me that the satellite network will be the ISP.

The satellites will have to know the global routing table and know which satellites are near which ground stations.

And the global routing table will have to be updated every few seconds. This is a hard problem.

In 2000 I worked on an internet routing project for Nortel (part of a team of 7), I did the UI and control software for the demo system. The idea is that at the edge of the network the IP packets are inspected and tagged with a series of tags and sent off to internal nodes. At the internal nodes the first tag are used to do the routing and popped (or swapped for another tag). The routes between nodes are set up by a global entity that manages bandwidth so that there is always enough bandwidth for these routes through the network. This means that when a packet is tagged at the network it is guaranteed to reach the far end (with quality of service guarantees). There is also only limited and bounded queuing at internal nodes, the small tag and limited queuing means that the switching can be performed all in hardware, with software only used to update the tag to route map(s).  The difficult bit is then the global ('god') system that allocates bandwidth to paths through the network and tells the edge nodes how to tag packets due to their destinations. This is naively a O(n^3) problem, so doesn't scale well without tricks, for this network n=4025 so scaling is not a problem, just whether it is tractable at a size of 4025. It is easy to see how such an idea can be applied to a satellite network.

The variable size of IP packets is a problem, so on a lower level we transported them within ATM cells, and developed a cleaver way of mapping the tags onto the ATM VPI and VCI routing. Some such scheme (perhaps not using ATM but a larger cell) would be ideal for the satellite network.

[Before working on this project I worked on WISDOM which was an EU funded project to develop a broadband satellite network with Matra-Marconi Space (now Astrium part of EADS) and various universities and consultancies. We mainly looked at MEO satellites, but also LEO and GEO sats. Nortels interest was in the ground segment, I worked on the general system design, uplink and downlink protocols and network control centre. Another part of Nortel worked on demonstration ground systems (breadboard level) while Astrium did the satellite breadboard. About 1998, Nortel decided not to continue with the project, partly because to take it further would require significant investment, partly because they reckoned that they could make more money by just being a ground network supplier to all the satellite networks that were being proposed at the time. - So it is easy to see my interest in these large satellite systems.]

Is this such a hard problem? It seems to be more geometry than computer science.

Most of the ground stations will be static, or nearly so (a car doesn't move far vs orbital speeds). If you want to talk to an IP address, this can be translated to a lat/long, then calculate the best routing to the least busy sat that's visible to that location. The system needs to maintain a table of IP vs lat/long, but most of these won't change very rapidly.

If 4,000 sats each have a direct link to 25 other sats that's 100,000 links. ISTM this state info could be broadcast across the network quite easily - 1mbps reserved on each link would propagate the info in seconds to every other node, I'd think.

For faster moving objects, like a jetliner, the network could route to the last known lat/long. If the destination is not in range, that node could then forward the request to each of its neighbouring nodes, several of which should have the plane in range. The nodes which can see the target could coordinate their info to derive a new lat/long, then propagate that to correct the routing tables.

But, this assumes dumb ground stations. A jetliner could report its GPS location, heading, and even any future course changes programmed into the autopilot. Once this info is propagated once, it might not need any updates for hours unless the plane deviates for something like bad weather.

Each sat has a good idea of the location of any ground stations in range due to the phased array. Several sats together could pinpoint something even more accurately, using a sort of GPS-in-reverse.  Any station spoofing its GPS location could be rejected from the network.

cheers, Martin

Offline MP99

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #350 on: 01/21/2015 10:28 pm »
Do not count any revenue from NASA on this. Maybe if they manage to snag something for the Mars part that NASA has a request out for.

ISS has a 300mbps down / 25mbps up appetite for bandwidth today, that is currently accommodated via ku-band to TDRS sats in GEO. (On general principles, it will probably need another speed boost eventually):-
http://www.nasaspaceflight.com/2013/04/iss-communications-overhaul-boost-scientific-output/

ISS is well below this constellation, and ISTM it could utilise it as long as the sats can accommodate a "ground" station moving that quickly. (See my previous post about fast-moving objects providing position and velocity state to the network.) Perhaps the comms module could even be a peer on the network, IE just another sat in the constellation.

I don't know if other LEO sats might find it useful to just buy a commodity comms module which interfaces into the constellation. If they currently use ground stations for comms, that would avoid that requirement. It might be one way that this reduces the design and operations costs for many sats in the future.

ISTM that a constellation of near-real-time ground-observation sats would have huge appetite for bandwidth. Unless these sats themselves might also include Earth observation - Google might find a use for that.

cheers, Martin

Offline CuddlyRocket

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #351 on: 01/21/2015 10:50 pm »
I wonder what portion was Fidelity, and what portion was Google.  Is Larry mainly giving Google's name to provide brand equity while Fidelity puts in $950 million for example?

Google has a 7.5% share in SpaceX (source), with Fidelity presumably therefore having 2.5%.

Fidelity at least will want an ultimate exit from the company, but that can easily be accomplished by (as suggested) establishing the satellite operation as a publicly-listed subsidiary.

Offline MP99

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #352 on: 01/21/2015 10:51 pm »
There's no latency advantage if you just terminate the connection at a local ISP.

It seems to me that the satellite network will be the ISP.

The satellites will have to know the global routing table and know which satellites are near which ground stations.

And the global routing table will have to be updated every few seconds. This is a hard problem.

In 2000 I worked on an internet routing project for Nortel (part of a team of 7), I did the UI and control software for the demo system. The idea is that at the edge of the network the IP packets are inspected and tagged with a series of tags and sent off to internal nodes. At the internal nodes the first tag are used to do the routing and popped (or swapped for another tag). The routes between nodes are set up by a global entity that manages bandwidth so that there is always enough bandwidth for these routes through the network. This means that when a packet is tagged at the network it is guaranteed to reach the far end (with quality of service guarantees). There is also only limited and bounded queuing at internal nodes, the small tag and limited queuing means that the switching can be performed all in hardware, with software only used to update the tag to route map(s).  The difficult bit is then the global ('god') system that allocates bandwidth to paths through the network and tells the edge nodes how to tag packets due to their destinations. This is naively a O(n^3) problem, so doesn't scale well without tricks, for this network n=4025 so scaling is not a problem, just whether it is tractable at a size of 4025. It is easy to see how such an idea can be applied to a satellite network.

The variable size of IP packets is a problem, so on a lower level we transported them within ATM cells, and developed a cleaver way of mapping the tags onto the ATM VPI and VCI routing. Some such scheme (perhaps not using ATM but a larger cell) would be ideal for the satellite network.

[Before working on this project I worked on WISDOM which was an EU funded project to develop a broadband satellite network with Matra-Marconi Space (now Astrium part of EADS) and various universities and consultancies. We mainly looked at MEO satellites, but also LEO and GEO sats. Nortels interest was in the ground segment, I worked on the general system design, uplink and downlink protocols and network control centre. Another part of Nortel worked on demonstration ground systems (breadboard level) while Astrium did the satellite breadboard. About 1998, Nortel decided not to continue with the project, partly because to take it further would require significant investment, partly because they reckoned that they could make more money by just being a ground network supplier to all the satellite networks that were being proposed at the time. - So it is easy to see my interest in these large satellite systems.]

Is this such a hard problem? It seems to be more geometry than computer science.

Most of the ground stations will be static, or nearly so (a car doesn't move far vs orbital speeds). If you want to talk to an IP address, this can be translated to a lat/long, then calculate the best routing to the least busy sat that's visible to that location. The system needs to maintain a table of IP vs lat/long, but most of these won't change very rapidly.

If 4,000 sats each have a direct link to 25 other sats that's 100,000 links. ISTM this state info could be broadcast across the network quite easily - 1mbps reserved on each link would propagate the info in seconds to every other node, I'd think.

For faster moving objects, like a jetliner, the network could route to the last known lat/long. If the destination is not in range, that node could then forward the request to each of its neighbouring nodes, several of which should have the plane in range. The nodes which can see the target could coordinate their info to derive a new lat/long, then propagate that to correct the routing tables.

But, this assumes dumb ground stations. A jetliner could report its GPS location, heading, and even any future course changes programmed into the autopilot. Once this info is propagated once, it might not need any updates for hours unless the plane deviates for something like bad weather.

Each sat has a good idea of the location of any ground stations in range due to the phased array. Several sats together could pinpoint something even more accurately, using a sort of GPS-in-reverse.  Any station spoofing its GPS location could be rejected from the network.

cheers, Martin

Thinking about this some more, each sat has a bunch of active ground stations that it's talking to. It will have to do a handoff to another sat as it gets near the station's horizon, but I wonder how often it can just hand over to the following sat in the same plane? That could make the coordination somewhat simpler.

As the earth rotates under the constellation, there will come a point where the ground station has to be handed off to the adjacent plane of sats to the East.

There may be reasons for a ground station to switch "randomly" between any of the sats that it sees in its sky, but maybe just "next in plane", "hop Eastwards", and "hop Westwards" (for load balancing) is all that is needed?

cheers, Martin

Offline MP99

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #353 on: 01/21/2015 10:57 pm »
[...]
For lack of any other information, I am assuming 64 planes x 64 satellites, and about 500 kg per each.
[...]
[...]splitting 4025 into multipliers gives the following viable solution: 81x25... 81 satellites in 25 planes, perhaps 1 is spare[...]

Yes, of course, that was just to get a quick idea, starting with polar...
Everything else stays....

I was just about to ask why not 115 x 35, or 161 x 25, or 175 x 23. (Musk did say this number was probably overprecise.)

IIUC, each different plane has to operate at a different altitude since they cross each other, so that might be a reason to keep the number of planes down.

Twice as many planes may reduce the inter-plane distance to half, which makes it that much easier for one sat to stray up or down and cause a nasty collision.

cheers, Martin

Offline meekGee

  • Senior Member
  • *****
  • Posts: 14158
  • N. California
  • Liked: 14046
  • Likes Given: 1392
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #354 on: 01/21/2015 11:01 pm »
There's no latency advantage if you just terminate the connection at a local ISP.

It seems to me that the satellite network will be the ISP.

The satellites will have to know the global routing table and know which satellites are near which ground stations.

And the global routing table will have to be updated every few seconds. This is a hard problem.

In 2000 I worked on an internet routing project for Nortel (part of a team of 7), I did the UI and control software for the demo system. The idea is that at the edge of the network the IP packets are inspected and tagged with a series of tags and sent off to internal nodes. At the internal nodes the first tag are used to do the routing and popped (or swapped for another tag). The routes between nodes are set up by a global entity that manages bandwidth so that there is always enough bandwidth for these routes through the network. This means that when a packet is tagged at the network it is guaranteed to reach the far end (with quality of service guarantees). There is also only limited and bounded queuing at internal nodes, the small tag and limited queuing means that the switching can be performed all in hardware, with software only used to update the tag to route map(s).  The difficult bit is then the global ('god') system that allocates bandwidth to paths through the network and tells the edge nodes how to tag packets due to their destinations. This is naively a O(n^3) problem, so doesn't scale well without tricks, for this network n=4025 so scaling is not a problem, just whether it is tractable at a size of 4025. It is easy to see how such an idea can be applied to a satellite network.

The variable size of IP packets is a problem, so on a lower level we transported them within ATM cells, and developed a cleaver way of mapping the tags onto the ATM VPI and VCI routing. Some such scheme (perhaps not using ATM but a larger cell) would be ideal for the satellite network.

[Before working on this project I worked on WISDOM which was an EU funded project to develop a broadband satellite network with Matra-Marconi Space (now Astrium part of EADS) and various universities and consultancies. We mainly looked at MEO satellites, but also LEO and GEO sats. Nortels interest was in the ground segment, I worked on the general system design, uplink and downlink protocols and network control centre. Another part of Nortel worked on demonstration ground systems (breadboard level) while Astrium did the satellite breadboard. About 1998, Nortel decided not to continue with the project, partly because to take it further would require significant investment, partly because they reckoned that they could make more money by just being a ground network supplier to all the satellite networks that were being proposed at the time. - So it is easy to see my interest in these large satellite systems.]

Is this such a hard problem? It seems to be more geometry than computer science.

Most of the ground stations will be static, or nearly so (a car doesn't move far vs orbital speeds). If you want to talk to an IP address, this can be translated to a lat/long, then calculate the best routing to the least busy sat that's visible to that location. The system needs to maintain a table of IP vs lat/long, but most of these won't change very rapidly.

If 4,000 sats each have a direct link to 25 other sats that's 100,000 links. ISTM this state info could be broadcast across the network quite easily - 1mbps reserved on each link would propagate the info in seconds to every other node, I'd think.

For faster moving objects, like a jetliner, the network could route to the last known lat/long. If the destination is not in range, that node could then forward the request to each of its neighbouring nodes, several of which should have the plane in range. The nodes which can see the target could coordinate their info to derive a new lat/long, then propagate that to correct the routing tables.

But, this assumes dumb ground stations. A jetliner could report its GPS location, heading, and even any future course changes programmed into the autopilot. Once this info is propagated once, it might not need any updates for hours unless the plane deviates for something like bad weather.

Each sat has a good idea of the location of any ground stations in range due to the phased array. Several sats together could pinpoint something even more accurately, using a sort of GPS-in-reverse.  Any station spoofing its GPS location could be rejected from the network.

cheers, Martin

Thinking about this some more, each sat has a bunch of active ground stations that it's talking to. It will have to do a handoff to another sat as it gets near the station's horizon, but I wonder how often it can just hand over to the following sat in the same plane? That could make the coordination somewhat simpler.

As the earth rotates under the constellation, there will come a point where the ground station has to be handed off to the adjacent plane of sats to the East.

There may be reasons for a ground station to switch "randomly" between any of the sats that it sees in its sky, but maybe just "next in plane", "hop Eastwards", and "hop Westwards" (for load balancing) is all that is needed?

cheers, Martin

Such schemes are easier for a human to wrap their brain around, since they are "intuitive", but for a computer, it's all the same.

All that matters is that under central control, at some time T0, everyone switches to a new switching table, which was distributed in advance, and clearly anticipates any geometry changes.  All packets that enter the system at time T>T0 use the new tables.  I expect changes to occur about once every 30 seconds or so.  (Just looking at 5400 seconds orbital period, 80 sats per plane (as has been proposed upthread) and doing it every half-interval). 

The updates can also occur every single second and still be glacially slow compared with the rate at which data packets are handled.

This is very different than a bunch of independently managed routers that try to reach a routing solution in a distributed manner.

ABCD - Always Be Counting Down

Offline ArbitraryConstant

  • Senior Member
  • *****
  • Posts: 2014
  • Liked: 628
  • Likes Given: 311
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #355 on: 01/22/2015 05:10 am »
All that matters is that under central control, at some time T0, everyone switches to a new switching table, which was distributed in advance, and clearly anticipates any geometry changes.  All packets that enter the system at time T>T0 use the new tables.  I expect changes to occur about once every 30 seconds or so.  (Just looking at 5400 seconds orbital period, 80 sats per plane (as has been proposed upthread) and doing it every half-interval).
I think that probably doesn't work as different people will have different weather blowing through and have different obstructions to deal with.

Most of the ground stations will be static, or nearly so (a car doesn't move far vs orbital speeds). If you want to talk to an IP address, this can be translated to a lat/long, then calculate the best routing to the least busy sat that's visible to that location. The system needs to maintain a table of IP vs lat/long, but most of these won't change very rapidly.
I think this also probably doesn't work as lat/long won't allow you to infer a priori which satellite can reach someone, for similar reasons.

If 4,000 sats each have a direct link to 25 other sats that's 100,000 links. ISTM this state info could be broadcast across the network quite easily - 1mbps reserved on each link would propagate the info in seconds to every other node, I'd think.
The volume of data seems quite large though - probably hundreds of millions of stations changing every few seconds. That gets untenable fast. And updates would still have a race where they would be behind some of the packets.

All this state information seems like something you'd want to keep localized to a few satellites, the ones that would be the possible handoff candidates. They can forward the traffic if they receive it erroneously and send a redirect message to the source satellite (like an ICMP redirect).

Can probably also parcel up the Earth into IPv6 prefixes well enough to let you generate a set of possible satellites for a given address. IPv4 can be supported via RFC6877 (meaning ignored entirely in the satellites).

This scheme wouldn't directly handle mobile stations, but that can be separately handled a number of ways. A special set of prefixes could be set aside for stations known to be mobile and SpaceX could market that at a premium and actually do the work to track them (along with the global routing tables). A few hundred thousand of those would probably work. A few hundred million, probably not. Another option would be a VPN type system to allow the wifi on the plane to not have to renumber every few minutes by tunneling somewhere else.
« Last Edit: 01/22/2015 05:18 am by ArbitraryConstant »

Offline meekGee

  • Senior Member
  • *****
  • Posts: 14158
  • N. California
  • Liked: 14046
  • Likes Given: 1392
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #356 on: 01/22/2015 06:41 am »
All that matters is that under central control, at some time T0, everyone switches to a new switching table, which was distributed in advance, and clearly anticipates any geometry changes.  All packets that enter the system at time T>T0 use the new tables.  I expect changes to occur about once every 30 seconds or so.  (Just looking at 5400 seconds orbital period, 80 sats per plane (as has been proposed upthread) and doing it every half-interval).
I think that probably doesn't work as different people will have different weather blowing through and have different obstructions to deal with.

Most of the ground stations will be static, or nearly so (a car doesn't move far vs orbital speeds). If you want to talk to an IP address, this can be translated to a lat/long, then calculate the best routing to the least busy sat that's visible to that location. The system needs to maintain a table of IP vs lat/long, but most of these won't change very rapidly.
I think this also probably doesn't work as lat/long won't allow you to infer a priori which satellite can reach someone, for similar reasons.

If 4,000 sats each have a direct link to 25 other sats that's 100,000 links. ISTM this state info could be broadcast across the network quite easily - 1mbps reserved on each link would propagate the info in seconds to every other node, I'd think.
The volume of data seems quite large though - probably hundreds of millions of stations changing every few seconds. That gets untenable fast. And updates would still have a race where they would be behind some of the packets.

All this state information seems like something you'd want to keep localized to a few satellites, the ones that would be the possible handoff candidates. They can forward the traffic if they receive it erroneously and send a redirect message to the source satellite (like an ICMP redirect).

Can probably also parcel up the Earth into IPv6 prefixes well enough to let you generate a set of possible satellites for a given address. IPv4 can be supported via RFC6877 (meaning ignored entirely in the satellites).

This scheme wouldn't directly handle mobile stations, but that can be separately handled a number of ways. A special set of prefixes could be set aside for stations known to be mobile and SpaceX could market that at a premium and actually do the work to track them (along with the global routing tables). A few hundred thousand of those would probably work. A few hundred million, probably not. Another option would be a VPN type system to allow the wifi on the plane to not have to renumber every few minutes by tunneling somewhere else.

Yes, there's that too.   

The predictable situation I described holds only for sat-to-sat orbital traffic.  You still have to choose the best end nodes, and the selection process involves the ground nodes, and so yes, it gets complicated.

I didn't mean to imply this is simple, just to imply that figuring out the sat-to-sat route, even though the geometries change very rapidly, is actually IMO the simpler of the issues they face.
ABCD - Always Be Counting Down

Offline MP99

Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #357 on: 01/22/2015 12:19 pm »


Most of the ground stations will be static, or nearly so (a car doesn't move far vs orbital speeds). If you want to talk to an IP address, this can be translated to a lat/long, then calculate the best routing to the least busy sat that's visible to that location. The system needs to maintain a table of IP vs lat/long, but most of these won't change very rapidly.
I think this also probably doesn't work as lat/long won't allow you to infer a priori which satellite can reach someone, for similar reasons.

I take your point re dynamically changing obstructions (eg urban canyons). Areas with a lot of tall buildings may be untenable for this service, but then it should be able to fall back to 4G / 5G.

However, lat/long will still identify the set of sats which are above the horizon for a ground station. Assuming each sat has a direct link to its near neighbours, they could coordinate, moment-to-moment which one has the baton, and forward any packets to that sat.

The long-range routing might well then become "get this packet to any sat that's above the horizon for this lat/long", and then that sat can forward to the one with the baton.


If 4,000 sats each have a direct link to 25 other sats that's 100,000 links. ISTM this state info could be broadcast across the network quite easily - 1mbps reserved on each link would propagate the info in seconds to every other node, I'd think.
The volume of data seems quite large though - probably hundreds of millions of stations changing every few seconds. That gets untenable fast. And updates would still have a race where they would be behind some of the packets.

No, this is a fundamental difference between terrestial networks and this sat network.

Terrestrial networks have machines at arbitrary locations, with very complex networks of routers also at arbitrary locations.

A fixed ground station never needs to have its lat/long updated, the sats just need to figure out between themselves which is the best route to get to that place, given the known location of every intermediate hop. That's a lot of data to remember, but it's essentially static, at least for the fixed ground stations.

The route will change continuously, but everything except traffic loads on the sat-to-sat links can just be calculated from "static" data.

"Static" in quotes, because the ephemeris / almanac ( http://en.m.wikipedia.org/wiki/GPS_signals ) will need occasional updates.

Cheers, Martin


Offline MechE31

  • Full Member
  • *
  • Posts: 156
  • MELBOURNE, FL
  • Liked: 284
  • Likes Given: 1

Offline watermod

  • Full Member
  • ****
  • Posts: 519
  • Liked: 177
  • Likes Given: 153
Re: SpaceX - now a satellite manufacturer (Starlink)
« Reply #359 on: 01/22/2015 03:07 pm »
As somebody who was there for the birth of digital cellular, then CDMA through 3-4G I really hate it when folks conflate apples and oranges.   Thinking multiple protocol stacks and within the RF one multiple stacks is the best way to look at it.   The IP packets don't need to know anything about the various space packets.

Some of this comes from the primitive hard handoff concepts that early protocols like GSM had.
Perhaps CDMA with its connections to multiple bases(s) or more accurately Base-Carrier-Sector-WalshCodes is a more appropriate to this multitude of satellites in view for a short period.     

Think of the end user having spider-legs running from it to the various satellites and it slowly walks its legs from sat to sat one careful leg at a time always keeping several on the various sats.   

In the first phase of the rollout you could have a CBSC style controller that covers areas of the sky.    In following rollouts the more complex options for work and such with  individual packets and the site registrations just like was done in Cellular.    This speaking as an inventor of one of those low level entry to a call protocols.   

If you want to consider it as an ISO-Layer because you have to - consider all this taking place at the MAC layer or (Zeroth) layer.   (think MAC hardware electric and collision layer on your physical LAN Ethernet)

Again the IP layer does NOT need to know anything about the radio layers.

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1