Re: [Raw] Montréal and Chartering

["Pascal Thubert (pthubert)" <[e-mail]>]

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

Ø    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?

Ø    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?



  1.  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!


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