Proposal
The following figure shows the transaction from 2 containers via 2 air-interfaces (MWPS) to a link bundle.
+
In order to gain better reach some Containers must not be combined with others in a link bundle.
It is assumed that TDM will never be combined in a link bundle.
In order to express, that a container must not be part of a link bundle, a new attribute “containerType” - :== {standalone, combinable}; default: standalone - shall be introduced..
A “commit” request is only successful, when “standalone” Containers has max one server/client relationship. The SDN Controller has all information to check in advance, whether this is the case.
Overview
Content Tools
Activity
6 Comments
Michael Binder
Shouldn't we explicitly model a LAG or link bundle group? That is, shouldn't we introduce an own object (class) for such a group?
There might other ways of how link bundles are handled. E.g. you can think of one sitting "below" a structure object ("MWS").
Martin Skorupski
Such object class was called "MWS-X" - and was not modeled (see may answer to other comment below.
Currently there is no need for such MWS-X (and also not for an MWPS-X) object class. If we see the need for configuration, fault, PM, .... for potential object classes between conatner and stuecture and between structure and airInterface, then we should create a new "issue".
>> no change on the proposal.
Michael Binder
I am not sure about the statement on TDM. Although I haven't seen TDM channels (like E1) being spread over Air Interface objects I have seen cases where TDM was not assigned to a specific air interface (MWPS) or structure (MWS) but to the link group instead.
Martin Skorupski
As long as we do not have configuration, alarms, performance on a protential object classs between '"container" (MW client) and "structure" (MWS) the server client realations are sufficient. Such potential object class was called "MWS-X" (or MWS-CTP) - it was not modeled in UML so far, because we figured out during the PoC#2 that the server client relations are sufficient. Currently there is not need for an object MWS-X because there is not "content" (capability, config, status, fault, pm). If we need it, There should be another "issue" for this topic. TCM container transported by more than one airInterface can be handled the same way as Ethernet Container.
>> no change on the proposal.
Giorgio Cazzaniga
In the meeting of 18/4 it has been decided to move the deadline for decision to 25/4; please check back the implementations from all vendors
Giorgio Cazzaniga
In the meeting of 2/5 it has been clarified that the content of the 'background' is old and needs to be removed