Summary

  • Paratus plans a regional introduction of Layer 2 connectivity over low-Earth-orbit satellite; related capability was already described in Rwanda in August.
  • Buyers need a service specification for the private-network connection, not performance or handoff terms borrowed from other satellite packages.

For a branch office, getting online and joining the company's network are different jobs. Paratus is bringing that distinction into its East African satellite offer. In its September 8 announcement, the operator said it would introduce a Layer 2 service over low-Earth-orbit satellites at ITW Africa, connecting offices, branches, data centres and remote sites within a private network.

The announcement sets out a commercial proposition, not a detailed service definition. It does not disclose a price, a general-availability date or a service-level agreement. Its significance is the way satellite access is packaged for enterprise integration, rather than a claim that Paratus has invented a new form of satellite networking.

An established capability gets a regional pitch

There is a useful check on the word “new”. An August 18 release issued by Paratus already described its Rwanda operation as providing Starlink-powered services that included Layer 2 connectivity. September's East African introduction should therefore not be reported as the first such capability anywhere in the group.

Nor should the constellation behind the regional offer be inferred solely from neighbouring references to Starlink. Paratus sells more than one satellite service. The group's current catalogue separates its On-Net teleport, OneWeb and Starlink offers. Its Teraco Layer 2 handoff, with a customer-arranged cross-connection, appears under the KU/C-band teleport service. That does not establish where the new East African LEO service hands traffic over. Advertised OneWeb performance figures likewise belong to that offer, not automatically to this one.

The product ends at an interface

For buyers, the useful change is the prospect of obtaining a defined private-network connection instead of assembling every part around an internet-access subscription. That could reduce integration work—but only if the handoff, supported traffic and division of responsibilities are clear.

A network label does not supply those details. The L2VPN requirements framework in RFC 4665 distinguishes traffic separation and service behaviour from additional security services such as packet encryption and authentication. It also addresses security requirements for particular deployment conditions. The framework is a guide to the questions, not a certificate for Paratus's implementation.

“Private” consequently does not, by itself, identify encryption endpoints or who controls keys. Asking for those boundaries is not an allegation that the service is insecure. It prevents a purchasing team from mistaking an architectural description for a complete security specification.

A remote site can have a functioning satellite link while its business-network connection still needs configuration or support. Acceptance should therefore examine the service delivered to the customer's equipment, not stop at terminal connectivity. That is the commercial test Paratus's regional pitch brings into focus; the public announcement has yet to supply the parameters needed to perform it.