Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Band & Carrier Aggregation #2

Open
JonasAhl opened this issue Apr 21, 2022 · 33 comments
Open

Band & Carrier Aggregation #2

JonasAhl opened this issue Apr 21, 2022 · 33 comments
Labels
proposed solution

Comments

@JonasAhl
Copy link
Collaborator

JonasAhl commented Apr 21, 2022 •
edited
Loading

Consider including support for BCA in the update.
Check previous discussion on this. See issue #1.
@leonida-macciotta
Copy link

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

image

ETSI definition of BCA

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

@JonasAhl
Copy link
Collaborator Author

JonasAhl commented May 6, 2022

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
Copy link

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).

image

@leonida-macciotta
Copy link

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

image

  • 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
Copy link
Collaborator Author

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
Copy link
Owner

samans commented Jun 15, 2023

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
Copy link
Collaborator

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

AnalysisProposalBondingBCA.pptx

@niloda
Copy link
Collaborator

niloda commented Jul 4, 2023

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

IETF-MW-MODEL.pdf

@samans
Copy link
Owner

samans commented Sep 7, 2023 •
edited
Loading

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
Copy link

tkall commented Sep 8, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link

tkall commented Sep 11, 2023

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
Copy link
Collaborator Author

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
Copy link
Collaborator

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
Copy link

leonida-macciotta commented Apr 23, 2024 •
edited
Loading

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
Copy link
Collaborator Author

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
Copy link

tkall commented May 29, 2024 via email

@JonasAhl
Copy link
Collaborator Author

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

@JonasAhl
Copy link
Collaborator Author

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

@samans
Copy link
Owner

samans commented Nov 14, 2024

Diagram including questions from discussion on 2024-11-14.
bca-model-questions-2024-11-14.pptx

@DanielaSpreafico
Copy link
Collaborator

I add a new proposal to discuss
BCA.Proposal.for.ccamp.v02.pptx

@DanielaSpreafico
Copy link
Collaborator

Trying to answer to the question on bca-model-questions-2024-11-14.pptx:

Question-1: Are RLT-B1 and RLT_C1 needed?
Answer:
Some advantages of modelling RLT-B1 and RLT-C1:

  1. They simplify the management of nodes B1 and C1 expecially when they are flexible and allow the configuration of packet services or remote carriers
  2. The parent-cc attribute with the RLT can be used to associate CC-B1 with CT-B1 and CC-C1 with CT-C1

The definition of this RLT could be seen as a bit "stretched" but it could be seen as "an interface providing packet capacity and/or TDM capacity to the associated packet and/or TDM interfaces in a node and is used for setting up a a remote carrier transport service over a microwave/millimeter wave link"

Question 2: Are CC interfaces needed?
Answer:
It seems that the model would work well without a new CC interface

Slides updated (see BCA.Proposal.for.ccamp.v02.pptx) and the following attributes can be renamed:

  • parent-cc --> parent-remote-carrier

  • carrier-connectors* -> remote-carrier-terminations

@tkall
Copy link

tkall commented Nov 21, 2024 via email

@italobusi
Copy link
Collaborator

Hello Daniela, Scott and all Daniela just a question. Should the +--rw parent-remote-carrier? if:interface-ref be a leaf-list? I.e. Is there a case with more than one parent-remote-carriers? Best regards Theodoros Kallimanis Στις Τετ 20 Νοε 2024 στις 6:55 μ.μ., ο/η DanielaSpreafico < @.> έγραψε:
…
Trying to answer to the question on bca-model-questions-2024-11-14.pptx https://github.com/user-attachments/files/17747911/bca-model-questions-2024-11-14.pptx : Question-1: Are RLT-B1 and RLT_C1 needed? Answer: Some advantages of modelling RLT-B1 and RLT-C1: 1. They simplify the management of nodes B1 and C1 expecially when they are flexible and allow the configuration of packet services or remote carriers 2. The parent-cc attribute with the RLT can be used to associate CC-B1 with CT-B1 and CC-C1 with CT-C1 The definition of this RLT could be seen as a bit "stretched" but it could be seen as "an interface providing packet capacity and/or TDM capacity to the associated packet and/or TDM interfaces in a node and is used for setting up a a remote carrier transport service over a microwave/millimeter wave link" Question 2: Are CC interfaces needed? Answer: It seems that the model would work well without a new CC interface Slides updated (see BCA.Proposal.for.ccamp.v02.pptx https://github.com/user-attachments/files/17834000/BCA.Proposal.for.ccamp.v02.pptx) and the following attributes can be renamed: - parent-cc --> parent-remote-carrier - carrier-connectors -> remote-carrier-terminations — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS3DVLLXD7GT7455HS2QXL2BS5I7AVCNFSM5T62TEK2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBYHEYTAOJQGM3A . You are receiving this because you commented.Message ID: @.*>

From the functional description of the use cases I have seen so far, there is always a single remote carrier interface associated with the RLT in the remote nodes (nodes B and C)

I do not know what could be the semantics of multiple parent remote carriers ...

Do you have any scenario or use cases where there could be more than one?

@italobusi
Copy link
Collaborator

Slides updated based on the discussion last week (November 21, 2024): BCA.Proposal.for.ccamp.v03.pptx

I am not sure which scenario 3 should be added so I have added two alternatives (3A and 3B) for further discussion in the next call

I have also added a slides with the open issues that still need to be investigated/discussed

@tkall
Copy link

tkall commented Dec 5, 2024 via email

@tkall
Copy link

tkall commented Dec 5, 2024 via email

@italobusi
Copy link
Collaborator

  • Radio Link Terminal: an interface providing Ethernet capacity and/or Time Division Multiplexing (TDM) capacity to the associated Ethernet and/or TDM interfaces in a node. It is used for setting up a transport service over a microwave radio link.

It would be worthwhile having some discussion in one of the next calls

Since the interface between RLT-A1 and RLT-A2 can be TDM or Ethernet, we may consider the definition still valid with some "stretches"

Alternatively, we may consider generalizing the definition to something like:

  *  Radio Link Terminal: an interface providing packet capacity
     and/or Time Division Multiplexing (TDM) capacity to the
     associated client interfaces (e.g., Ethernet or TDM) in a node.  It is
     used for setting up a transport service over a microwave radio
     link.

Just my 2 cents to trigger further thoughts/discussion

@JonasAhl
Copy link
Collaborator Author

JonasAhl commented Dec 12, 2024 •
edited
Loading

I have some questions related to the model supporting the latest BCA-proposal.

  • I might have misunderstood, but it looks like there are references to model instances in other nodes/interfaces. Node A has an interface supporting e.g. the updated BCA module, but node A has no knowledge about any model entity exposed via interfaces in nodes B & C. What do then remote-carrier-termination, radio-link-termination and parent-remote-carrier refer to, since they cannot refer to interface-instances in other nodes/interfaces? Or are they references to IF-A3, IF-A4, IF-B5 and IF-C6?
  • Is the bonding function different depending on if the traffic stream comes from an internal CT, RLT or remote CT?
  • Is there any other info than what is supported by the basic interface-model that needs to be known about remote CT & RLTs?

@tkall
Copy link

tkall commented Dec 12, 2024 via email

@italobusi
Copy link
Collaborator

The slides updated during the call today: BCA.Proposal.for.ccamp.v04.pptx

@tkall
Copy link

tkall commented Dec 19, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
proposed solution
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@tkall @samans @demx8as6 @italobusi @niloda @JonasAhl @DanielaSpreafico @leonida-macciotta