Hi all,
During the September 17 TGbq F2F session, I presented [26/1603r2] and ran SP1 (below). There were several good questions at the mic and offline on why the indicated information is useful, so I would like to continue the discussion here and summarize the motivation,
before bringing the SP back in a future session.
SP1:
Do you support to include the following in the 11bq SFD?
- To negotiate an on-demand SP for an IMMW link, that is not dedicated for beam establishment, information such as one or more TIDs and/or a delay bound of the traffic to be served by the on-demand SP may
be considered.
- How to convey the information is TBD.
Q1: What is the gain? Why is this information useful to the responder?
Today, the responder of an ODSP request knows the STAs’ availability (Motion 65) and the requested SP duration (Motion 80), but not what the SP will be used for or how urgent the traffic is. The TID and/or delay bound provides that per-request
context, so the responder can accept, reject, or counter with a different start time.
- This is useful both for a single ODSP request and for multiple requests at the same time. With multiple requests, the TID and/or delay bound allows the responder to choose which to accept. With a single
request, it helps the responder decide based on its own operating state (e.g., upcoming scheduled SPs, observed traffic patterns, power constraints).
- Urgent traffic gets served in time. Periodic SPs are planned around known traffic; on-demand is today the only mode where the responder schedules blind. With the delay bound, the responder can schedule the
SP so the deadline is met, or prioritize the request that has one.
- A power constrained responder can choose to accept the ODSP request or wake the mmWave radio only for high-priority traffic. That decision is only possible if it knows what the request is for.
Q2: If the responder rejects a request based on the TID and no other request arrives, doesn’t the IMMW link stay idle? Is this restricting TIDs per SP?
A responder can already reject an ODSP request for implementation reasons; the indication does not add a new reason to reject, it gives better information for the decision. It does not limit the traffic exchanged during the SP, and a responder
with an idle link can simply accept, same as today. So the worst case is the current behavior.
Q3: Isn’t this already covered by SCS/TTLM, which define QoS requirements per TID and the TID-to-link mapping?
They are complementary, but operate at a different timescale and resolution. SCS describes a stream for its lifetime, and in P2P there may be no SCS at all. A TTLM can include multiple TIDs across priority levels, so it cannot tell the
responder which of them a specific request is for. Achieving the same per-request context with these mechanisms would require extra frames on sub-7 to renegotiate per change.
Q4: Is the information explicitly indicated in the ODSP request/response frames, or earlier?
The sub-bullet intentionally leaves this open: it can be signaled during the ODSP negotiation or earlier (e.g., pre-negotiated during ML setup), so the SP does not preclude either direction.
Comments and suggestions welcome. I plan to bring this back at an upcoming session.
Regards,
Pavan
To unsubscribe from the STDS-802-11-TGBQ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBQ&A=1