LEO L16 Network.

[ORAC]

Raises a lot of questions. Going back over 25 years there has been the issue of interference between L16 and TACAN/DME and now other systems. Which is why we were limited to a single net with large horizontal separation between different nets.

What are the im0lications of a constellation of LEO L16 satellites presumably linking/operating multiple nets? Hell of a job for the DLM as well…

https://www.c4isrnet.com/battlefield-tech/space/2021/06/01/viasat-to-add-military-grade-encryption-to-experimental-link-16-satellite/

Viasat to add military-grade encryption to experimental Link 16 satellite

WASHINGTON — A new Link 16-capable satellite being developed by Viasat will feature military-grade encryption, the company announced June 1.

Link 16 is the U.S. military’s primary tactical data exchange network, allowing joint war fighters to share information on the location of friendly and enemy forces to build a common operating picture of the battlefield.

But while Link 16 is of critical importance to the military in understanding the modern battlefield, it is technically limited to communications to other terminals within line of sight. In other words, it can’t be used to incorporate data from sensors and war fighters that are too far away.

The Air Force Research Laboratory wanted to change that. In 2019, the lab issued a $10 million contract (https://www.c4isrnet.com/c2-comms/satellites/2019/05/29/air-force-wants-to-expand-tactical-data-network-to-space/) to Viasat through the Space Enterprise Consortium to build a Link 16-capable satellite.

By directly tying into the Link 16 tactical network from low Earth orbit, the satellite could provide a connection node with beyond-line-of-sight forces. This space vehicle would use the vantage of orbit to connect — via Link 16 — systems that would otherwise be limited to line-of-sight communications…..

The experimental Viasat satellite will help reduce risk for the ambitious plans of the Space Development Agency (https://www.c4isrnet.com/battlefield-tech/space/2021/02/11/sda-to-launch-several-demonstration-satellites-in-2021/), which is working to launch a new proliferated constellation made up of hundreds of satellites mostly in low Earth orbit (https://www.c4isrnet.com/battlefield-tech/space/2020/01/21/one-military-space-agencys-plan-for-1000-new-satellites-by-2026/).

That constellation will create a mesh network on orbit with optical intersatellite links (OISL) (https://www.c4isrnet.com/battlefield-tech/c2-comms/2020/01/16/the-pentagon-wants-help-for-its-satellites-to-talk-to-each-other/) that can transport data from satellite to satellite all over the globe.

Just like with the AFRL satellite, SDA plans to outfit some of its satellites with Link 16 terminals, essentially enabling the U.S. military to push data to war fighters all over the world via the tactical network. Six of the agency’s first satellites — set to begin launching in 2022 — will be outfitted with Link 16 terminals.

Viasat initially anticipated launching the experimental satellite in summer 2020 but has pushed back the launch to fall 2021.

[BEagle]

But while Link 16 is of critical importance to the military in understanding the modern battlefield, it is technically limited to communications to other terminals within line of sight. In other words, it can’t be used to incorporate data from sensors and war fighters that are too far away.

Huh? From my SOFC L16 course a million years ago, I clearly recall that L16 has a number of relay options available, so most certainly isn't limited to LOS provided that the originator and relay terminal are in LOS, as must be the recipient and relay terminals. The original plan for VC10K / TriStar was that they would only carry L16 for use in a relay mode, as well as providing high quality stable time and position quality. We weren't happy with that, so a display was ultimately provided, which even in austere form worked just fine during OP ENGADINE. Whilst taxying out at Brize for the first trial, we were seeing the SRAP quite happily - although the trials officer really shouldn't have enabled active synch at that point, due to the CAA/MoD Frequency Clearance Agreement....

In early JTIDS trials, data from a training area in somewhere like New Mexico was double bounced to the Pentagon, giving real-time intelligence to a General's desk. All with reliable 3-level encryption!

The L16 TACAN/DME issue has now been solved, I gather, because later generation chip sets do not include TACAN/DME frequency capability for L16 terminals.

[ORAC]

Huh? From my SOFC L16 course a million years ago, I clearly recall that L16 has a number of relay options available, so most certainly isn't limited to LOS provided that the originator and relay terminal are in LOS, as must be the recipient and relay terminals.
The packets have a lifetime and time out if relayed over any substantial distance, which bouncing into orbit, around the world then back down will certainly exceed - unless someone has changed the protocol.

[Wensleydale]

There has always been a theoretical interference during the life of JTIDS, and that theoretical has governed the risk accepted by the CAA. JTIDS is a communications piece of equipment operating in the air navigation band, and so the priority and (over?) regulation has always been the case for JTIDS operation. I am fairly confident therefore that although "CAA say no" has been the usual response to additional use, full use of JTIDS has probably not been authorised (at least up 'til 10 years ago when I retired). The problem with L16 however has always been an oversubscription of operators demanding more and more timeslots, and this has given many problems in the past. Different platform software designations often (nay usually) give conflicts of track ID between platforms, and the requirements of remote IDs differ. So, for example, the Ground Environment requires Friendly, Faker, Joker etc whereas a fighter demands Bandit/Bogie/hostile which are not compatible IDs within the air picture and translate to incorrect IDs in their system. At the same time, the Navy ships use their own ID criteria and computer systems systems. This leaves major JTIDS players such as AWACS having to handle a multitude of JTIDS conflict alerts between the users as everyone tries to add their own data in their own language leading to a multitude of ID conflicts for a single object. The result is often a compromise with some units having to maintain their data in house. As more and more different nations with different aircraft types and computer systems become involved then the picture only gets worse. I can only imagine the impossible task of a data link manager in trying to make sense of all this without increasing capacity to add more players.