Re: [Raw] Montréal and Chartering

["Cavalcanti, Dave" <[e-mail]>]

Hi Pascal,

Thanks for the clarifications and please see my responses in line.


Best,
Dave

From: Raw [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, May 07, 2019 8:37 AM
To: Cavalcanti, Dave <[e-mail]>; Grossman, Ethan A. <[e-mail]>; Xavi Vilajosana Guillen <[e-mail]>
Cc: [e-mail]; Lou Berger ([e-mail]) <[e-mail]>
Subject: Re: [Raw] Montréal and Chartering

Hello Dave:

Please see below:


According to the current scope, the RAW layer is to enable establishment and management of time-sensitive flows (data flows with certain QoS needs) over wireless networks. This process may include several steps:
1)      The RAW layer will provide the QoS requirements of a RAW flow (e.g. in some form of time constraints metrics, reliability/redundancy metrics, etc …) to the radio layer, which will be used as input to some form of admission control.


Ø    I’m not sure it is a layer per se. More of a management interface. A RAW-capable controller manages an end-to-end flow that traverses a particular wireless hop.

Ø    The controller must talk to the intelligence that drives the abstract AP to allocate  a periodic resource for the flow. Compared to DetNet/CCAMP, RAW would provide additional control parameters like “up to 5 retries, max latency all retries included is blah, please provide frequency diversity for the retries”.

[DC] One option is for the RAW controller to configure some of the radio parameters that will impact QoS (e.g. retries, max latency, etc). It would be good to have a way to describe diversity/reliability requirements from the RAW side that is independent of the radio layer implementation. The RAW controller may not have enough information to decide that frequency diversity is the best option to be used. The AP has better knowledge of the network and it can decide what type of diversity it can provide to a certain flow in order to meet the target requirement. If the AP can provide the required reliability with link adaptation or time diversity, for instance, it should be able to make the best choice.  There are different ways to get diversity (frequency, time, space), and it would be good to abstract that at the RAW layer, and let the radio decide what option to use.


Ø    It gets more hairy when doing replication. The controller might say “send a replicated frame to STA 1 and STA 2”. Might turn out that STA 1 and STA 2 are on the same or different APs – hopefully they do not roam, when that happens is next problem. How do we model that? Should there be a DetNet between AP1 and AP2 and AP1 does replication? Or should the previous switch called SW replicate? In which case APs do not do any DetNet service layer?

[DC] I assume that packet replication will be done at a layer above the radio (MAC/PHY). Is it part of RAW or another higher layer? With this assumption, the radio layer (AP) would get two packets from the higher layer addressed to two STAs (STA 1 and STA 2) and it would just try to deliver the packets while meeting the RAW diversity requirements.



Ø    Another case is STA1 sends to AP1 and AP2, AP2 being a promiscuous listener? So a single transmission is already a natural replication. This model exists in ISA100.11a, could we have it in other technologies? If so we could model it in our management interface?


2)      Assuming that the radio layer can admit the flow, it will use QoS requirements to schedule resources in space/frequency/time to serve the RAW flow as agreed. The scheduling the decision is implementation specific, and the specific diversity mechanisms used at the MAC/PHY layer is technology specific. The RAW layer doesn’t need to be involved in the radio specific aspects of providing diversity.


Ø    Well RAW may know how a particular technology schedules its resources in details, that was the discussion in this Thread. i.e., RAW may not control the allocation of resource blocks / subchannels. But maybe it can still ask for something more specific than a meaningless QoS of 5. The abstraction might be half specific like 5 tries or more abstract like 99.99 reliability, either way with a deadline in time. We have to define that based on what APIs the technologies are willing to  open. We need you in the room for that!

[DC] It is not very clear what you mean by knowing how a particular technology schedules its resources in details. For instance, RAW may know that an 802.11ax network operates with a certain channel bandwidth, OFDMA mode, available RU sizes, etc. Similar information for a 5G network, e.g. URLLC mode is enabled. But the resource allocation strategies will be a black box (implementation specific). We can look into opening additional information, such as bounded latency, packet error rates, etc.


3)      The RAW layer needs to monitor the performance of the RAW flow and it may adapt its QoS requirements. This will require an interface with the radio layer to update the RAQ flow parameters.


Ø    Absolutely


I understand there is a lot more to be defined, but these seem basic steps required.

Is my understanding of the RAW scope and basic capabilities correct?


Ø    Looks like it is so; depends if you liked my answer or not : )


All the best,

Pascal