Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] CID in DL Map



Raja,
I believe that Vladimir's opinion is the correct one.
Please remember that the CID in the DL-MAP is relatively new addition to
the standard which was added without changing of the basic behavior.
Before adding the DL-CID, the DL regions were broadcast regions used to
profile potential receiving SS according to DIUC abilities. The CID used
to add additional dimension of narrowing down the potential relevant DL
regions using a CID.
From my perspective, a broadcast CID defines a fallback to the original
behavior.

Regards,
Itzik.

-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Raja Banerjea
Sent: Tuesday, May 04, 2004 12:17 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] CID in DL Map

Vladimir,
        I dont agree with your suggestion that the BS can transmit in
the DL
a DLMAP with the broadcast CID and concatenate MPDUs belonging to
different
traffic CID as you suggest in the email below.
        The burst addressed by a DLMAP using the broadcast CID should
have
MPDUs whose MAC header has the broadcast CID only.
        similarly
        The burst addressed by a DLMAP using the multicast CID should
have
MPDUs whose MAC header has the multicast CID only.
Regards,
-Raja


-----Original Message-----
From: Vladimir Yanover [mailto:vladimir.yanover@ALVARION.COM]
Sent: Sunday, May 02, 2004 11:04 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] CID in DL Map


Baraa,

First, "packing" is not related to DL-MAP IEs. Probably you mean
"concatenation" =
creating burst payload by merging several MAC PDUs.

CID in the DL-MAP IE has the following sense for SS. First SS must
identify
whether the DL connection identified by the CID belongs to the SS i.e.
was established by DSx procedure with the SS involved as a destination
[note
that
this covers also the case of multicast connection].

IF (the connection identified by the CID in DL-MAP IE belongs to the SS)
THEN
        the SS must decode the burst and extract all MAC PDUs.
Presumably,
all MAC PDUs are addressed to the SS
ELSE IF (CID = broadcast) THEN
        the SS must decode the burst, extract all MAC PDUs and decode
those
addressed to the SS [according to CID
        in Generic MAC Header]
ELSE
        SS may ignore the burst

Vladimir

-----Original Message-----
From: Al Dabagh, Baraa [mailto:baraa.al.dabagh@INTEL.COM]
Sent: Monday, May 03, 2004 1:08 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] CID in DL Map


I made a mistake. Please replace:

Reading this I would understand that packing of multiple CIDs (for the
same SS) on the DL is note allowed. Is this understanding consistent
with everyone's?

with

Reading this I would understand that concatenation of multiple CIDs (for
the
same SS) on the DL in one burst is note allowed. Is this understanding
consistent with everyone's understanding?

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 Al Dabagh, Baraa
> Sent: Sunday, May 02, 2004 11:10 AM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: [STDS-802-16] CID in DL Map
>
> Folks,
>
>    I have a question regarding the CID in the DL-MAP IEs. The standard
> indicates
>
> "
> Connection Identifier (CID)
> Represents the assignment of the IE to a broadcast, multicast or
unicast
> address.
> "
>
> Reading this I would understand that packing of multiple CIDs (for the
> same SS) on the DL is note allowed. Is this understanding consistent
> with everyone's?
>
> 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.
************************************************************************
****
********