<div dir="ltr"><div dir="ltr">One of the books I picked up at Information Theory and Applications Conference was Network and Protocol Architectures for Future Satellite Systems. <br><br>Ok that was a lot of Words! <br><br>The book is mainly about the changes already starting to happen for high-throughput satellites. Continued integration of the terrestrial support network and the increasing bandwidth of the satellites means that decisions need to be made and problems solved! Exciting stuff. <br><br>In some systems, the satellite network and the terrestrial network are pretty much separated. Things go through gateways and terrestrial uses all the old familiar protocols. <br><br>Current and future networks integrate the space and terrestrial links. The first problem you run into is that TCP views long latency links as congestion and does what it's good at and slows things down. Breaking up the long paths into smaller links is usually what's done, but at the expense of breaking some fundamental behavior and doing what's essentially a hack. It's either that or a special box at the boundary, which incurs other problems. <br><br>The second problem is one of rapidly increasing throughput requirements. For satellite paths affected by weather, the first line of defense to preserve the link is something we're implementing with Phase 4 Ground: adaptive coding and modulation. For big commercial networks this is necessary but insufficient. In addition to ACM, redundant flexible links are used. <br><br>In the mix to address these things is something called MPTCP, or multi-path TCP. This is already in your linux kernel, and is how Siri is able to answer you so quickly. MPTCP is an evolution of TCP with the following goals. Higher throughput than TCP while not costing too many resources. Do no harm to other TCP flows. Take as much load as possible off of congested paths. <br><br>Traffic is split up into sub-flows. Both ends have to have the extension. Why do all this? Because of all the stuff in your way at the transport layer. </div><div dir="ltr"><br></div><div dir="ltr">There is a load balancing algorithm called OLIA that is Pareto-optimal. This means that nothing can get better with the load balancing without making some aspect worse. It's as fair as it's going to get, nothing is left on the table. This is a pretty trick achievement!<br><br>Another innovation is network coding. In traditional systems (like ours) the data is source coded (created and compressed) and then a decision is made about how much channel coding is required for it to make it to receiving stations. This is nontrivial stuff (as we know) but the coding doesn't change along the way.<br><br>Network coding allows intermediate nodes (like in a mesh network) to re-encode packets to improve capacity - especially multicast capacity, reduce bandwidth requirements for data replication, and reduce file-downloading in peer-to-peer. <br><br>Network coding was originally proposed to specifically help multicast data delivery. It best works when there is a single source. This may not be a great match up for Phase 4 Ground, but one of the goals here is to open things up and break them down so that we as amateurs are awake, aware, and alert of what's going on in communications.<br><br>Another movement in the big satellite world (and networking in general) is something called Information Centric Networking (ICN). <div><br></div><div>Ok so check this out. <br><br>ICN decouples information from the source. Information is named, addressed, and matched independent of its location. It can be located anywhere on the network. <br><br>Information retrieval becomes receiver-driven. No data can be received unless it is explicitly requested by the receiver. <br><br>There is a publish/subscribe model here, but it's not the publish/subscribe of the application layer that we might be familiar with. We're more accustomed to thinking of publish/subscribe as publishing being the actual transmission of data, and subscribing indicating that we want to get something in the future. Getting previously published data may be optional, or impossible.<br><br>In ICN, the publish part is only announcing the availability of information to the network. Subscriptions by default only refer to information already available. Possibly future info as well. Publication and subscription are decoupled in both time and space. Publishers don't know about subscribers. Subscribers don't know about publishers. They just get their stuff from whatever cache has it. <br><br>This is super great for mobile radios. <br><br>There was a discussion about security and how ICN evades deep packet inspection and is more resilient to denial of service attacks.<br><br>So is there anything in here that we need to know about? Yes, because it helps us understand where we're going in the industry when we talk to people about rideshares and launches. <br><br>Yes, because the ICN approach may increase the number of simultaneous users in a Phase 4 Network. We want people to have watch lists and alerts when users are online that they want to communicate with. Does this style of networking help with that? Nothing needs to change in the DVB-S2/X frame, but could the publish/subscribe model be considered as a possible GSE function?<br><br>If you're interested in learning more about any of this, write me and I'll help however I can to find the best resources or maybe even a project related to P4G to work on. :+)</div><div><div><br></div><div>More soon!<br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">-Michelle W5NYV<br><br><div dir="ltr"><br></div></div></div></div></div></div></div></div></div></div></div></div></div>