Regression testing issues in network provision inference patterns

[mike1813]

The 5G construction sequence was overhauled recently to address multiple issues with network accessibility and network connectivity inference (#151, #152, #154, #155, #162, #163, #164, #165, #166, #171) and to address dependencies to facilitate refactoring into a separable sub-model package (#183).

The tests used addressed many scenarios in which the original sequence failed, but did not cover all such scenarios, nor all scenarios in which the original sequence did not fail.

Some tests in relation to #183 have shown that the sequence is now somewhat 'fragile' with respect to which assets and relationships have been included in the asserted system model. At present, a user can

Option 1: specify the presence of a cellular network, to which hosts are connected, but not where it is accessible. The accessibility of the cellular network is deduced to be:

• for public cellular networks: the inferred global public space (World) plus any space in which there is a connected host
• for private cellular networks: spaces in which there is a connected host that has no other location
• for all cellular networks: spaces from which any of its Radio Access Networks (RANs) are accessible
• for all cellular networks: spaces in which there is a Base Station providing a RAN

Because cellular networks are typically used to connect from mobile hosts, the accessibility of private cellular networks can rarely be found by inference. There will be at least one mobile device connected to it, and one cannot assume the connection will be available in all spaces between which the mobile device can move. For this reason, we also support

Option 2: specify in which spaces the (private) cellular network is accessible, in addition to those that can be deduced under Option 1.

The last two cases from Option 1 infer that a cellular network is accessible from a Space if the asserted model has

• a RAN that implementsCN the cellular network and is accessibleFrom a Space
• an L3 (IP) subnet that implementsCV the cellular network (acting as its backbone), to which is connected a Base Station located in a Space

However, the presence of a RAN and/or Base Station is also inferred to exist in Spaces from which the cellular network is accessible, where the relevant cellular network infrastructure does not exist.

This can lead to some scenarios not working correctly due to confusing (because somewhat arbitrary) assumptions about what the user has or has not included in the asserted system model. If you leave most of the implementing infrastructure out, you get something that works OK, but if you include some infrastructure, the rest may or may not end up being inferred.

What we need here is one or both of the following:

• further changes in the construction sequence so whatever the user includes in the asserted system model, if infrastructure elements can be inferred, they are inferred
• modelling error threats pointing out where the asserted system model lacks some information needed to fill in the cellular network infrastructure, prompting the user to add it.

[mike1813]

Started changing the construction sequence, addressing many of the previously unsupported combinations of asserted elements in cellular network infrastructure. After some iterations, further changes to the asserted CP dependencies started leading to loops in the construction sequence. To fix this required more changes to the package#Network patterns, which in turn led to further difficulties.

It seems the original construction sequence is just too 'interleaved', making it very difficult to maintain. It was only possible to make changes because it is a sequence (not a partial sequence), which eases the cognitive burden for developers when making small, local changes. However, the interleaving of subsequences embodies lots of unnecessary constraints, which go unnoticed until one tries to make more substantial changes to the overall structure. At that point, it is unclear which of the original constraints is important, and this leads to bugs especially when dealing with a package that depends on lots of others.

Unfortunately, all those unnecessary constraints became baked into the first set of CP dependencies when auto-generated from the old sequence numbering. With CP dependencies, distinct subsequences don't need to be 'interleaved' and it should be easier to make larger scale changes, and no harder to make small, local changes. However, the CP dependencies are at present still 'interleaved', and the benefits of changing from a single sequence are not realised.

What we really need here is a complete overhaul of the CP dependencies. It is easy to extract a list of dependencies between patterns where one of the patterns creates a type of asset or relationship that is matched by the other. In the current CP dependencies, it was assumed that the order in which the two patterns should be defined for every such dependency, and that this should be the same as the original sequence. What we should do is to start with an overall structure, comprising of a partial sequence in which the elements are themselves subsequences of patterns. Ideally, each of these elements should start and end with a 'boundary marker' pattern, and the overall structure should be encoded by creating dependencies between these boundary marker patterns. Then we should position each of the original patterns in the appropriate subsequence based on the old sequence numbering. With this approach, we keep the local, necessary dependencies (within each subsequence), but lose the unnecessary 'interleaving' dependencies.