Allow multiple physical infrastructure providers per span and node.

[lgs85]

See also:

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

  Talking to operators has made it clear that both networkProvider and physicalInfrastructureProvider will need to allow for a one-to-many relationship with spans and nodes. This may also require some tweaks to the primer and reference pages.

[duncandewhurst]

From https://github.com/Open-Telecoms-Data/open-fibre-data-standard/issues/192#issuecomment-1323107813:

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.

Do you have a concrete example of this? My understanding is that joint ventures are typically incorporated as an independent entity (https://en.wikipedia.org/wiki/Joint_venture#Company_incorporation) so it should in theory be one organisation that is the physical infrastructure provider, which may have several shareholders.

[lgs85]

Do you have a concrete example of this?

Only anecdotal, and that it might be quite hard in some cases to identify these joint ventures without data on the shareholders. That being said, I think these will be edge cases so don't particularly mind if we'd rather deal with the problem if and when it arises.

[lgs85]

Following further conversations we now have some concrete examples of multiple physical infrastructure providers. One fairly common scenario involves local governments installing ducts, and multiple companies blowing cables through the same ducts. I think that raises a couple of issues that we need to clarify:

• should this constitute one span or several?
• should the loval gov be considered a physical infrastructure provider? (based on the present definition I think the answer to this would be yes)

We can address this either by tweaking definitions, or by changing cardinalities.

[stevesong]

An example from South Africa is the National Long Distance (NLD) consortium. https://techcentral.co.za/nld-fibre-route-finally-live/187337/ Four companies, 3 commercial, 1 state-owned. Each operator got 2 cables. It is not clear to me, however, whether the NLD itself is an independent entity in any way. Will find out more.

[duncandewhurst]

From a quick Google, it does indeed seem like NLD is a consortium rather than an independent entity like a joint venture.

There's some information on NLD in the country case studies from the World Bank's Cross-Sector Infrastructure Sharing Toolkit. It sounds similar to the scenario that @lgs85 described: the consortium invested jointly in the trench, but then each member laid their own fibre:

Edit: It would be really helpful to actually see the co-build agreement referenced above. @stevesong would there be any chance of getting sight of that via your network?

should this constitute one span or several?

With the current 1:1 cardinality of Span.physicalInfrastructureProvider, the only way to represent this would be one span per provider. That seems OK to me, especially as the other properties of Span might be differ by provider, e.g. darkFibre, fibreType and fibreCount. If we made Span.physicalInfrastructureProvider 1:n, then what would you set darkFibre to if one provider offers dark fibre and another doesn't?

It's also in-line with the ITU's Brazil data, which looks to have one span per provider, albeit represented somewhat schematically, as discussed in #193:

should the loval gov be considered a physical infrastructure provider? (based on the present definition I think the answer to this would be yes)

I'm inclined to think that we should narrow the semantics of physical infrastructure provider to cover only providers of fibre, not of trenches alone since many properties of span don't make sense in the context of a trench alone. If there is a use case for data on trenches, we'd need to think more about how to model them.

[lgs85]

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 standard 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]

I've renamed this issue to be about multiple physical infrastructure providers per span and node and created a new issue about multiple network providers per span and node: https://github.com/Open-Telecoms-Data/open-fibre-data-standard/issues/210

[duncandewhurst]

Reopening based on the discussion from https://github.com/Open-Telecoms-Data/open-fibre-data-standard/issues/192#issuecomment-2072338573 onwards (I don't remember why the issue was closed).