Re: [STDS-802-16] DLFP and HFDD
Baraa and All,
I believe, Baraa's primary interest os OFDM PHY.
In 8.3.4.1
"In TDD and H-FDD systems, subscriber station allowances must be made by a
transmit-receive turnaround gap SSTTG and by a receive-transmit turnaround
gap SSRTG. The BS shall not transmit downlink information
to a station later than (SSRTG+RTD) before its scheduled uplink allocation,
and shall not transmit downlink information to it earlier than (SSTTG-RTD)
after the end of scheduled uplink allocation, where
RTD denotes Round-Trip Delay. The parameters SSRTG and SSTTG are
capabilities provided by the SS to BS upon request during network entry (see
11.8.3.1)."
One may find sentence "The BS shall not transmit downlink information" not
precise. My understanding is the following.
Let's put forward the following definition
DL burst is addressed to the SS if one of the following is true:
1. the burst is specified in DLFP [thus actually a PHY broadcast]
2. the burst is specified in DL-MAP with CID = broadcast
3. the burst is specified in DL-MAP with CID = Basic CID of the SS
My interpretation:
BS adds SSRTG+RTD to the end of the last OFDM symbol of those containing MAC
messages addressed to the SS [unicast or broadcast], and this is the lower
limit for UL allocation.
In the case DL burst addressed to the SS overlaps in time with UL
allocation to the SS, the SS has no choice but to interrupt reception of DL
burst (SSRTG + RTD before start of UL allocation), complete the processing
and start switching to Tx. Such procedure in OFDM PHY implementation seems
quite feasible.
The BS is aware of all MAC PDUs in the DL transmissions, so there is no
problem in planning UL Tx correspondingly [as described above]. The SS must
to trust BS in this prospect and intterupt DL processing if needed.
Vladimir
-----Original Message-----
From: Itzik Kitroser
To: STDS-802-16@LISTSERV.IEEE.ORG
Sent: 5/15/2004 2:36 PM
Subject: Re: [STDS-802-16] DLFP and HFDD
Barra,
Here is a quote from the new draft (D5), page 513, line 32 (OFDM DL_MAP
IE format section)
"Connection Identifier (CID)
Represents the assignment of the IE to a broadcast, multicast or unicast
address.
If the broadcast or multicast CID is used then it is possible to
concatenate unicast MAC PDUs (with different CIDs) into a single DL
burst. During a broadcast or multicast DL burst it is the responsibility
of the BS to ensure that any MAC PDUs sent to an HFDD SS do not overlap
(in time; taking TTG and RTG into account) any UL allocations for that
SS. An HFDD SS for which a DL MAP IE and UL MAP IE overlap in time shall
use the UL allocation and discard DL traffic during the overlapping
period. "
The description is general about time period and not just about PDUs --
correction to my previous note.
Following the SS UL transmission period, if the SS has the ability to
synchronize to the next burst (may be possible in the OFDM/OFDMA PHYs,
with the fact the DL MAP is known to the SS), then he can continue to
receive DL data (randomizer is initialized for every burst). Therefore I
don't believe that the situation is bad as described in Raja's mail.
As a general approach, I believe we should keep any details about
scheduler implementation out of the scope of our standard; therefore the
above language about scheduler behavior is enough.
Regards,
Itzik.
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Al Dabagh,
Baraa
Sent: Saturday, May 15, 2004 12:20 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] DLFP and HFDD
Itzik,
I understand that there need not be any PDU overlap, but how about
bursts overlap? The SS can have a PDU in a DL broadcast burst that is
not overlapping (the PDU that is) with an UL burst but the UL and DL
burst are.
|<------------------ Broadcast DL BURST ------------------>|
|<--- DL PDU for SS0 --->|<----- No DL data for SS0 ------>|
|<- UL Burst for SS0 ->|
Of course the gap between the DL PDU and the uplink burst have to meet
the SS's capabilities.
There is no clear text (that I have seen) that prohibts the above
condition (in HFDD) yet it imposes an interoperability concern, unless
this was the intention.
Baraa Al-Dabagh
BWD
Intel Corporation
baraa.al.dabagh@intel.com
Phone: 408-545-6078
> -----Original Message-----
> From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-
> 16@LISTSERV.IEEE.ORG] On Behalf Of Itzik Kitroser
> Sent: Friday, May 14, 2004 8:53 AM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16] DLFP and HFDD
>
> Baraa,
>
> If I remember correctly (and now all the details of standard are a big
> mess in my head), then we had a comment that clarified this issue.
> Anyway, the BS should avoid giving UL allocations to a specific SS,
> which overlaps with DL PDUs to same SS.
> Therefore, an SS receiving an UL allocation may assume that there is
no
> awaiting DL PDU during the same time period.
>
> Regards,
> Itzik.
> -----Original Message-----
> From: owner-stds-802-16@listserv.ieee.org
> [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Al Dabagh,
> Baraa
> Sent: Friday, May 14, 2004 4:39 PM
> To: STDS-802-16@listserv.ieee.org
> Subject: [STDS-802-16] DLFP and HFDD
>
> Folks,
>
> I have a question regarding the DLFP and DL/UL allocations (OFDM
256)
> in an HFDD based system:
>
> It seems to be possible that an UL allocation can be in conflict with
> one of the DL allocation specified in the FCH (or the DLFP0 for a
> particular SS. In the case were there is a conflict, should the SS
> assume that there is no allocation for it in the DL burst specified by
> the FCH (or the DLFP) and attempt not to decode it, or should the MAC
on
> the BS be smart enough to allocate on a per PDU level (rather than a
> burst level)?
>
> If the answer is the second option, then this assumes the SS will
decode
> a DL burst, extract the PDUs that belong to it from the burst, and if
> there is an allocation on the UL overlapping then it should terminate
> the DL burst decoding, and start transmitting data!! The same thing
> applies for a broadcast or multicast CID specified in the DL MAP that
> overlaps with an UL allocation.
>
> Thanks
>
> Baraa Al-Dabagh
> BWD
> Intel Corporation
> baraa.al.dabagh@intel.com
> Phone: 408-545-6078
This mail passed through mail.alvarion.com
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************
This mail was sent via mail.alvarion.com
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************