Enable users to determine the difference between multiple operators using the same fibre vs multiple operators with different lengths of fibre in the ground.

[duncandewhurst]

From https://github.com/Open-Telecoms-Data/cove-ofds/issues/51#issuecomment-1319875206:

A key need for users of the data will be to be able to determine the difference between multiple operators using the same fibre vs multiple operators with different lengths of fibre in the ground. I think the current data model and visualiser should mostly deal with this ok, though we might want to consider what to do for truly overlapping spans.

[lgs85]

Thanks for flagging this @duncandewhurst. I'm going to expand on this here, based on conversations with operators, regulators and government. Apologies for the rambling.

Context

There are a range of ways in which OFDS data might be shared and published by operators, regulators, governments and other organisations. Almost every process will begin with operators sharing information about the networks on which they own or use fibre. Operators may publish this as open data themselves, or this might be collated by a regulator or other organisation and published as a single network. There are a couple of important considerations about what this might look like:

• Many operators are likely to function as physical infrastructure providers, network providers and service providers on different parts of their network. They will therefore report on fibre that they own and use, fibre that they own and lease to other providers, and fibre owned by other operators that they lease, either as dark fibre or lit capacity.
• It is likely that in many cases operators will not want to publicly disclose who they are leasing from and to, as this may constitute commercially sensitive information. As a result, the data from each provider will constitute a partial view of the network for a given area.

As a result, and depending on the publication model, either publishers or users will need to be able to piece together statements from individual operators to gain a full understanding of the network business model. And this is very important, because without doing this, basic questions such as 'how much fibre is in the ground in area X' can't be addressed.

Current OFDS approach

• For each node and span, publishers can specify (one or more) networkProvider and physicalInfrastructureProvider objects. In cases where the publisher is a regulator or other agency in which a data sharing agreement exists with operators, it may be possible for the publisher to identify the roles on each node and span, and publish this accordingly. However in cases where operators publish their own data, only one role may be described for each node/span (that of the publishing organisation) and users will be required to piece together data from multiple operators. Publishers may provide more details about their role using the freetext roleDetails field for the relevant organisation.
  • In the absence of a universal span/node ID, users will need to use geographic data reconcile likely overlapping nodes and spans. This can be combined with presence/absence information about organisations in each role type to infer potential business models. So if two organisations publish data about a span with an overlapping route, and organisation A declares that they are (only) a physical infrastructure provider and organisation B declares that they are (only) a network provider, then users may infer that this is the same fibre. This isn't an ideal approach as it is reliant on inferring relationships based on absent information.

Potential changes

(these are very much just initial thoughts rather than proposals)

• We may wish to consider enabling operators to be able to more clearly set out their roles and relationships with regards to a given span in a more detailed and structured way. In particular, it may be useful to be able to state more explicitly whether an organisation is leasing or being leased dark fibre/lit capacity on a a given span.
• We may wish to consider how to enable publishers to represent the above relationships without revealing commercially sensitive information.
• We may wish to consider authoring guidance to publishers and users on how to reconcile data from overlapping nodes/spans.

[lgs85]

Adding the Schema tag as I think we should at least consider whether the above requires changes to the data model.

[duncandewhurst]

Thanks for the comprehensive update :-) the potential changes sound like good areas to explore.

• We may wish to consider authoring guidance to publishers and users on how to reconcile data from overlapping nodes/spans.

Noting a related issue:

• https://github.com/Open-Telecoms-Data/open-fibre-data-standard/issues/130

• For each node and span, publishers can specify (one or more) networkProvider and physicalInfrastructureProvider objects.

To be clear, in the OFDS schema, there is only one networkProvider and one physicalInfrastructureProvider per span, and the same for nodes. However, we can revisit the cardinality of those fields if need be.

[lgs85]

To be clear, in the OFDS schema, there is only one networkProvider and one physicalInfrastructureProvider per span, and the same for nodes. However, we can revisit the cardinality of those fields if need be.

Oh yes of course. I haven't seen any evidence yet of more than one physicalInfrasctureProvider but pretty sure that multiple operators lease dark fibre on a single span so we will need to change the cardinality of networkProvider.

[lgs85]

Actually we will also need to make physicalInfrastructureProvider a one-to-many cardinality, as multiple companies can have shares in a span. I'll create a separate issue.

[lgs85]

I think that the likely first phase of this work is going to be authoring guidance, with practical examples, for 'secondary' publishers (e.g. governments, regulators, industry associations) on how to combine datasets from multiple providers.

[lgs85]

I've edited the title of this issue because I think it might be more than authoring guidance. As noted by @duncandewhurst in #199, simply changing cardinality of providers introduces additional issues and doesn't necessarily solve the problems described above. From 199:

I think it's helpful here to consider the following user stories, which I think are a fair reflection of many of the issues raised in our pilot discussions:

As an operator, I want to be able to lease capacity on an independent route between two points of presence, so that I can build resilience into my network and avoid disruption

As a government official/regulator, I want to be able to estimate the length of my network in terms of kilometres covered, that doesn't duplicate cables/fibres following the same route.

I think that the Brazil data highlights how the standard doesn't, at present, address these user needs. We can't tell if these spans are following the same route, similar routes, or independent routes. Multiple cables in the same trench is one example of this, but we might also see multiple cables in the same duct. As far as I can see we can't consider these cables as independent from the perspective of physical disruption to the network.

If we made Span.physicalInfrastructureProvider 1:n, then what would you set darkFibre to if one provider offers dark fibre and another doesn't?

This is a good point, and I think highlights that simply changing cardinalities is insufficient to address the primary issue here. Rather, I think that the schema needs some restructuring, so that users can represent multiple fibre cables following the same route. I don't think it's sufficient to rely on users to infer this from the geospatial data as this may often be inaccurate, of insufficient resolution, or absent.

There are multiple ways that we could represent this, which might involve revisiting the concept of a span, and/or adding higher or lower level hierarchies to spans. @duncandewhurst I think that this is probably best closed here and moved to a separate issue. We should also talk this through together in a dedicated modelling call. I'll look to put something in.

[duncandewhurst]

One option could be to create a Cable class and add an array of .cables to Span. We could then move some properties from Span to Cable:

• .physicalInfrastructureProvider
• .darkFibre
• .fibreType
• .fibreTypeDetails
• .fibreCount
• .fibreLength

I don't know whether the properties relating to the active layer would be better on Span or Cable:

• .networkProvider
• .technologies
• .capacity
• .capacityDetails

I do have some concerns about introducing this level of complexity, though.

We should also talk this through together in a dedicated modelling call. I'll look to put something in.

:+1:

[stevesong]

As a little more grist for the mill, I came across this post earlier in the week https://www.stl.tech/blog/understanding-the-basics-of-physical-infrastructure-access-pia/ which talks about three different kinds of deployments:

• Direct deployment into the ground – A ducted access network contains a feeder network segment between the mainframe distribution (MDF) and a street cabinet/PCP. It is responsible for hosting a distribution frame, which allows the access line to be connected or patched.
• Aerially (on poles) – The aerial deployment also follows the same concept; the only difference is using boxes at the top of poles instead of manholes or handholes.
• Installed ducts – The underground cables are accessible via manholes or handholes, which act as a host for branching sleeves. These sleeves can be buried directly. The cable segment present between the last branching sleeve and the end-customer premise is also called building access cable. It is eventually terminated by the building distribution box (BDB.) The in-house cabling is patched to the outdoor access network cables in the case of BDB. As per a Wik Consult report, France, Spain, and Portugal have most effectively used the duct access.

[stevesong]

Some examples of joint fibre builds.

Zambia: Meta and Paratus jointly invest in fibre in Zambia

Uganda: Airtel and BCS, with support from Facebook, to build shared fiber backhaul connectivity in Uganda

[duncandewhurst]

Regarding the joint fibre builds, in both cases, I think that Facebook is a funder rather than a physical infrastructure provider (owner/maintainer). Edit: OFDS already provides for the disclosure of funders for phases/networks.

Some examples of joint fibre builds.

Zambia: Meta and Paratus jointly invest in fibre in Zambia

The article states that "Paratus Zambia will own, build, and operate the network"

Uganda: Airtel and BCS, with support from Facebook, to build shared fiber backhaul connectivity in Uganda

I found a report that describes Facebook's role in this project (see page 17), and in similar projects in Nigeria and South Africa as "to co-fund deployments, with local operator partners having ownership of the infrastructure deployed."

[stevesong]

Perhaps the National Long Distance (NLD) network in South Africa is a better example, a consortium comprising MTN, Vodacom, Neotel (now Liquid), and Sanral.

the three telecoms companies involved insisted on three “completely different specifications, literally down to the manholes”.

They demanded that their separate ducts had to be a certain space apart. “We had to get special combs, made to comb the duct to do this.”

There are manholes every kilometre on the 680km route. There are eight cables in all. Each operator has two and Sanral has two in some areas, Earley explains. “They have different fibre in them and some of them even have different duct configurations.”

[duncandewhurst]

Thanks! The various news articles' loose use of terminology around fibres, cores, cables, ducts, trenches, partners and investors certainly makes this a tricky issue to unpick.

That said, I think the Uganda example above is quite interesting, as it features a few funding and ownership scenarios that we should consider if/how we want to model in OFDS:

• During construction: co-ownership between Facebook, BCS and Airtel (per the Facebook report linked above)
• Post construction: co-ownership between BCS and Airtel. Per Airtel's IPO prospectus this was a "co-build agreement", which BCS's partnerships models page describes as

• BCS and the client mutually fund CAPEX for fiber construction. • Each party owns a percentage of the fiber cores and share, in proportion, the cost of fiber maintenance. • The client owns fiber infrastructure at a fraction of the capex that would be required to build their full fiber infrastructure.

• Post management buyout: full ownership by BCS. Per BCS's our journey page:

It still isn't clear to me whether there existed a consortia as a separate legal entity from the individual partners. The mention of returning all shareholding to BCS sounds like there was, but the description of a co-build sounds like the individual fibres are owned by the separate partners.

We might also want to take a step back and think about how important this level of specificity is in the context of OFDS.