Band & Carrier Aggregation

[JonasAhl]

Consider including support for BCA in the update. Check previous discussion on this. See issue #1.

[leonida-macciotta]

Proposal discussed today

module: ietf-microwave-radio-link
  +--rw BCA-groups {BCA}?
     +--rw BCA-group* [name]
       +--rw name                string
       +--rw enabled?            boolean
       +--rw members*            if:interface-ref
       +--rw main-member?        if:interface-ref
augment /if:interfaces/if:interface:
  +--rw BCA-groups*              -> /BCA-groups/BCA-group/name
           {BCA}?

1. This representation misses some details present in the YANG
2. The main member is set optional, it’s commonly used in load balancing groups – TBD
3. This definition is agnostic about the physical composition of the MW Node by one or more NEs and their interconnection (if any)

Model reference

ETSI definition of BCA

https://www.etsi.org/deliver/etsi_gr/mWT/001_099/015/01.01.01_60/gr_mwt015v010101p.pdf

[JonasAhl]

The model for Microwave radio link supports aggregation/bonding of different carrier terminations that can be configured for different frequencies/bands, channel spacing, modulation, output power, etc, It also includes additional constructs to describe XPIC, MIMO and protection configurations used, if applicable. Based on the definition of BCA in ETSI GR mWT 015, my view is that the current YANG Data model for microwave radio link already supports BCA in full, providing a way to configure/represent the BCA concept "enabling an efficient use of the spectrum through a smart aggregation, over a single physical link, of multiple frequency channels (in the same or different frequency bands)".

[leonida-macciotta]

As a support for the discussion extension to the multi-NE BCA use cases, I upload the picture shown in the meeting. It is work in progress, by no means a modeling proposal (and may contain mistakes).

[leonida-macciotta]

After some thought, there may be a solution like shown below:

• no BCA-group
• use the hierarchy between RLT - CT and ETH interfaces to represent the connection to the external NE (see indent level in the picture above)
• there are two options for managing the "special nature" of the RLT in NE3 (and NE4):
  • the RLT is present, but the rule is that no ethernet service can be set up on it
  • the RLT is not present

[JonasAhl]

Hi all, I've thought about an alternative way of handling BCA over multiple nodes. It only adds a new type of interface and leaves the existing parts untouched which means that there will be no issue with backward compatibility. The new interface type is also only used when there is a need to model multi-node configurations, which also would simplify the compatibility with the existing model/implementations. See attached slide pack. The example is not making use of the new way of representing mode. So far, the new interface type only includes the relationships to other interfaces. If there is a need to add additional leafs, in additions to those available in the generic interface model, then that could be looked into as a second step Key Concepts - Bonding & BCA.pptx .

[samans]

Proposed Solution includes:

Adding a new augment to interface called "HRLT" (name to be discussed). Need to complete the discussion on attributes to add to HRLT, see slide 6 of the pptx from above.

[DanielaSpreafico]

I add few slides to use the new interface HRTL also in one single node scenarios.

AnalysisProposalBondingBCA.pptx

[niloda]

I add some additional radio link configurations in a single node (some configurations that require bandwidth aggregation):

IETF-MW-MODEL.pdf

[samans]

Here are some notes related to two options for the model.

Option 1: Using a new ianaift for hierarchical radio link terminal

  augment "/if:interfaces/if:interface" {
    when "derived-from-or-self(if:type,"
       + "'ianaift:microwaveRadioLinkTerminal')";
and
  augment "/if:interfaces/if:interface" {
    when "derived-from-or-self(if:type,"
       + "'ianaift:hierarchicalRadioLinkTerminal')";

The augment for hierarchicalRadioLinkTerminal would be in a different module providing a different name space (hrt).

module: ietf-interfaces
  +--rw interfaces
  |  +--rw interface* [name]
  ...
    |     +--ro higher-layer-if*                    interface-ref
    |     +--ro lower-layer-if*                     interface-ref
  ...   
    |     +--rw mrl:id?                                 string
    |     +--rw mrl:mode                            identityref
    |     +--rw mrl:carrier-terminations*    if:interface-ref
  ...
    |     +--rw hrl:bca-members*              if:interface-ref

New attributes needed for hrl would be in the hrl namespace and only needed if the interface is hierarchical.  The existing mrl namespace doesn't need to change.

Option 2: Using a new leaf in mrl to identify the role the interface plays

  augment "/if:interfaces/if:interface" {
    when "derived-from-or-self(if:type,"
       + "'ianaift:microwaveRadioLinkTerminal')";

module: ietf-interfaces
  +--rw interfaces
  |  +--rw interface* [name]
  ...
    |     +--ro higher-layer-if*                   interface-ref
    |     +--ro lower-layer-if*                    interface-ref
  ...   
    |     +--rw mrl:id?                                string
    |     +--rw mrl:mode                           identityref
    |     +--rw mrl:carrier-terminations*   if:interface-ref
  ...
    |     +--rw mrl:role                           identityref
  ...
    |     +--rw mrl:bca-members*             if:interface-ref
  ...

An identity ref could be created (or just an enumeration or even a boolean) that indicated if the mrl was "terminating" or "not-terminating". Other leafs for the "non-terminating" case would be in the same name space.

[tkall]

Just a question somehow relevant to mulitple-NE BCAs, i.e. Aggregations of Carrier Terminals at different Elements. Is it in the scope of this feature to support also XPIC-Pair with Carrier Terminals located at different Elements? Eg XPIC Pair with a Carrier Terminal at vertical polarization at Element A and with a second Carrier Terminal at horizontal polarization at Element B?

[DanielaSpreafico]

In priciple yes, it is possible but I think (I ned to check) not using and Ethernet cable between the 2 elements A and B.

[JonasAhl]

I think this is an important point to clarify in terms of the scope of the proposal. The proposal with a the new interface type hierarchical-RLT (HRLT), as described above, assumes that the two network elements are managed independently and that there is no control of the function in one network element from the other network element. This means that XPIC, MIMO, nor protection can be supported for the carriers across the two network elements. HRLT is just a function for aggregating traffic from multiple sources/interfaces, similar to LAG but smarter(?) without the limitations with hashing. If there is a need to support XPIC, MIMO and protection across two network elements, then there is a need for a tighter integration where also control information needs to be exchanged and where one network element typically would act as a master and in that role control the functionality in the second network element. My assumption has been that in such a case the master network element would need to model the carriers (CTs) in the other network element as if it was part of the master and thereby from a model point of view already be supported by the current model as is. A possible extension could be if there is a need to indicate that a carrier is located physically in another network element.

[tkall]

I may be wrong but I thought that even the Carriers Aggregation of Carrier Terminals at different systems, not only XPIC etc, need some common management otherwise how the load balancing of the aggregation can be administered for example?

Regarding to the statement:

"...one network element typically would act as a master and in that role control the functionality in the second network element. My assumption has been that in such a case the master network element would need to model the carriers (CTs) in the other network element as if it was part of the master and thereby from a model point of view already be supported by the current model as is. "

Does this imply then that we need to remove the CT interface of the Slave System and add it as CT interface of the Master system when that CT interface is going to be grouped in a way (eg XPIC, MIMO)? When this CT interface is intended to operate again out of the group, we will need then to reverse this modelling and return it back to the original system.

"A possible extension could be if there is a need to indicate that a carrier is located physically in another network element." If an interface is included in a system, is there a need to indicate its location from inventory point of view and for the need of troubleshooting?

[JonasAhl]

I guess carrier aggregation across multiple nodes could be implemented in various ways, but one is to rely on the far-end to near-end relationship between the two HRLBs, with e.g. ping in-between to check status. You probably also need some kind of rate signaling from the constituent RLTs/interfaces, but I'm not sure that it should be seen as control signaling. Once again, there are different ways in which you can implement a system where you support XPIC, MIMO & protection across multiple nodes. One is to view/implement it as one virtual node (one NE & one management interface) combining the two devices/nodes and another is have two separate NEs, but where one of them are in control over the other (active/stand-by). I think the manner in which this is set up is implementation specific. I.e. if you need to start up the node in a specific mode from the beginning or if you can re-configure it in run-time into a stand-alone node or into operating in combination with other nodes. As far as possible, I think we should strive for a standardized model which is independent upon the specific implementations and accept that vendors might need to add vendor specific extensions to cover whatever might be specific for their product.

[demx8as6]

I'd like to introduce the idea of incorporating a Microwave-Domain-Controller perspective into our discussion. Currently, microwave networks already implement Band & Carrier Aggregation through multiple nodes, carrying live traffic. The goal here is to propose a software update for all the involved nodes, supporting a new yang revision without disrupting Ethernet (ETH) services via the nodes. Failing to do so may result in these nodes not receiving the new software, and consequently missing out on the new features that come with the updated yang revision.

In my humble opinion, the current model already encompasses all the necessary attributes, relationships, and object classes. When considering what should be addressed by '...', my answer would be: no new attributes are truly mandatory.

However a "copy" for configuration on the "aggregation" (or "main" or master" or "infrastructure") node can be avoided by introducing an "microwaveCarrierConnection" interface type with just pointing to microwaveCarrierTermination or generic ietf-interfaces.

mw-bca-concept-model.pptx

[leonida-macciotta]

We have a new proposal for a BCA model, that would allow all current and (hopefully ate least most of the) future implementations to be modeled, including especially hierarchical (as we think the model by Jonas lends itself to, if we're not wrong), i.e. for example a 4+0 implemented as a cascade of a 3+0 and a 2+0), and non-hierarchical (to keep that example, a single 4+0 with remote members). We are also keeping with Martin's proposal of using a CC for remote carriers, that are implemented by one or more independent NEs (i.e. devices with their own IP address, managed independently). By the way the proposed model is built, it is also possible to deduce the actual architecture (e.g. in non-hierarchical implementations, distinguish between the "master" and the "slaves"), associate CCs to individual CTs etc. without need of specific attributes. The slides include an example JSON for a non-hierarchical 4+0 system, with 2 "low band" carriers and two independent full-outdoor e-band radios.

BCA Proposal for ccamp v01.pptx

[JonasAhl]

The attached presentation shows how the original proposal can model the configurations described in "BCA Proposal for ccamp v01.pptx" I think it is important to define the functionality to be supported by the proposed extensions. Is it more than a function for managing the distribution of traffic across multiple interfaces/RLTs or not?

Key Concepts - Bonding BCA v2.pptx

[tkall]

Hello Jonas. Hello all I may miss something but why the mode is 2+0 of the RLT-B1 and RLT-C1 at the First Scenario and of RLT-B1 and RLT-B2 at the second scenario (although they aggregate locally at their nodes only a unique CT?

Best Regards

Theodoros Kallimanis Principal Engineer (Systems & SW)

Department SSD

---

Intracom Telecom 19.7 km Markopoulou Ave., Peania, GR 19002

Building A3, 2nd floor t: +30 2106671961 f: +30 2106671446 m: +30 6941636679

@. @.> *www.intracom-telecom. com

Στις Τρί 28 Μαΐ 2024 στις 2:51 μ.μ., ο/η JonasAhl @.***> έγραψε:

The attached presentation shows how the original proposal can model the configurations described in "BCA Proposal for ccamp v01.pptx" I think it is important to define the functionality to be supported by the proposed extensions. Is it more than a function for managing the distribution of traffic across multiple interfaces/RLTs or not?

Key Concepts - Bonding BCA v2.pptx https://github.com/samans/draft-ybam-rfc8561bis/files/15469096/Key.Concepts.-.Bonding.BCA.v2.pptx

— Reply to this email directly, view it on GitHub https://github.com/samans/draft-ybam-rfc8561bis/issues/2#issuecomment-2135025221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS3DVNPKA5X42TNHZDDNFTZERVSNAVCNFSM5T62TEK2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGUYDENJSGIYQ . You are receiving this because you commented.Message ID: @.***>

[JonasAhl]

Thanks for identifying the typo. Corrected in this new version. Key.Concepts.-.Bonding.BCA.v3.pptx

[JonasAhl]

Hi all, I've added some more info in a version 4. See slides 7 and onwards. Key Concepts - Bonding BCA v4.pptx