Phillip,
Section
6.3.2.3 states
“MAC management messages
that have a Type value specified in
Table 14 as
"reserved" or those not containing
all required parameters or containing erroneously
encoded
parameters shall be
silently discarded.”
In case you
will try to put traffic payload on those connections the type will be unknown
and the PDU will be discarded.
From:
owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Phillip Barber
Sent: Monday, September 06, 2004 4:47
PM
To:
STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] T16
Clarification
Your argument is uncompelling. The
language of D5, while not completely unambiguous, is clear
enough.
Your specific example is not
convincing. The paragraph only indicates where MAC management messages
are mapped. It DOES NOT say that ONLY MAC management messages are mapped to
the Basic and Primary CIDs. It simply says where MAC management messages map
to.
Also, Figure 95 is hardly
compelling either. It merely shows that CID must have a common QoS Parameter
Set, which makes sense since bandwidth requests are made based on CID, not
SFID.
The reality is that under the
language for the DSA & DSC MAC management messages and/or section 6.3.14
QoS, the document language would have to explicity state that data
service flows provisioned through the DSx mechanics cannot be mapped to the
Basic or Primary CIDs. It does not. In fact, 6.3.14.9.4 DSC, page 249, line
31, and 6.3.14.9.5 Connection release, page 260, line 4, specifically cover
the instance of when the service flow is cancelled and it is mapped to the
Basic, Primary, or Secondary management CID. Obviously this language would not
be present if SFIDs could not map to those special
CIDs.
Also, to support the other part of
your assertion, the language of DSA & DSC MAC management messages and/or
section 6.3.14 QoS would necessarily need to be very clear that a CID would
only be permitted to have a single SFID mapped to it. It does not. And this
despite many opportunities in the document for such clarity. This cannot
be perceived as some oversight since the document does make special effort to
identify the unique nature of SFID. So, in the absense of clear definition,
multiple SFID mapping to a single CID must be assumed as
permissable.
So I am afraid that I must
disagree with your interpretation of the current language in the IEEE
802.16-2004 document.
I draw your attention to the
following relevent sections of language:
3. Definitions
page 7, line
52
3.12
connection: A unidirectional mapping between base station (BS) and subscriber
station (SS) medium access control (MAC) peers for the purpose of transporting
a service flow’s traffic. Connections are identified by a connection
identifier (CID). All traffic is carried on a connection, even for service
flows that implement connectionless protocols, such as Internet Protocol (IP).
See also: connection identifier.
3.13 connection identifier (CID): A16-bit
value that identifies a connection to equivalent peers in the MAC of the base
station (BS) and subscriber station (SS). It maps to a service flow identifier
(SFID), which defines the Quality of Service (QoS) parameters of the service
flow associated with that connection. Security associations (SAs) also exist
between keying material and CIDs. See also: service flow
identifier.
6.3.1.1 PMP
page 33, line
16
Each SS shall
have a 48-bit universal MAC address, as defined in IEEE Std 802-2001. This
address uniquely defines the SS from within the set of all possible vendors
and equipment types. It is used during the initial ranging process to
establish the appropriate connections for an SS. It is also used as part of
the authentication process by which the BS and SS each verify the identity of
the other.
Connections are identified by a 16-bit CID. At SS
initialization, two pairs of management connections (uplink and downlink)
shall be established between the SS and the BS and a third pair of management
connections may be optionally generated. The three pairs of connections
reflect the fact that there are inherently three different levels of QoS for
management traffic between an SS and the BS. The basic connection is used by
the BS MAC and SS MAC to exchange short, time-urgent MAC management messages.
The primary management connection is used by the BS MAC and SS MAC to exchange
longer, more delay-tolerant MAC management messages. Table 14 specifies which
MAC Management messages are transferred on which of these two connections.
Finally, the Secondary Management Connection is used by the BS and SS to
transfer delay tolerant, standards-based [Dynamic Host Configuration Protocol
(DHCP), Trivial File Transfer Protocol (TFTP), SNMP, etc.] messages. These
messages are carried in IP datagrams, as specified in 5.2.6. Messages carried
on the Secondary Management Connection may be packed and/or fragmented. For
the SCa, OFDM, and OFDMA PHY layers, management messages shall have CRC. Use
of the secondary management connection is required only for managed
SS.
The CIDs for these connections shall be assigned in
the RNG-RSP and REG-RSP messages. The message dialogs provide three CID
values. The same CID value is assigned to both members (uplink and downlink)
of each connection pair.
For bearer services, the BS initiates the set-up of
connections based upon the provisioning information distributed to the BS. The
registration of an SS, or the modification of the services contracted at an
SS, stimulates the higher layers of the BS to initiate the setup of the
connections.
The CID can be considered a connection identifier even
for nominally connectionless traffic like IP, since it serves as a pointer to
destination and context information. The use of a 16-bit CID permits a total
of 64K connections within each downlink and uplink
channel.
Requests for transmission are based on these CIDs,
since the allowable bandwidth may differ for different connections, even
within the same service type. For example, an SS unit serving multiple tenants
in an office building would make requests on behalf of all of them, though the
contractual service limits and other connection parameters may be different
for each of them.
Many higher layer sessions may operate over the same
wireless CID. For example, many users within a company may be communicating
with Transmission Control Protocol (TCP)/IP to different destinations, but
since they all operate within the same overall service parameters, all of
their traffic is pooled for request/grant purposes. Since the original local
area network (LAN) source and destination addresses are encapsulated in the
payload portion of the transmission, there is no problem in identifying
different user sessions.
The type of service and other current parameters of a
service are implicit in the CID; they may be accessed by a lookup indexed by
the CID.
6.3.14.1 Theory of
operation
page 221, line 2
All service flows have a 32-bit SFID; admitted and
active service flows also have a 16-bit
CID.
6.3.14.2 Service flows
page
221, line 18
a)
Service Flow ID: An SFID is assigned to each existing service flow. The SFID
serves as the principal identifier for the service flow in the network. A
service flow has at least an SFID and an associated Direction.
b) CID:
Mapping to an SFID that exists only when the connection has an admitted or
active service flow.
6.3.14.3 Object model
page 223,
line 10
The
service flow is the central concept of the MAC protocol. It is uniquely
identified by a 32-bit (SFID). Service flows may be in either the uplink or
downlink direction. Admitted and active service flows are mapped to a 16-bit
CID.
Outgoing user data is submitted to the MAC SAP by a CS
process for transmission on the MAC interface. The information delivered to
the MAC SAP includes the CID identifying the connection across which the
information is delivered. The service flow for the connection is mapped to MAC
connection identified by the CID.
6.3.14.9.4 DSC
page 249, line
31
Any service
flow can be deactivated with a DSC command by sending a DSC-REQ message,
referencing the SFID, and including a null ActiveQoSParamSet. However, if a
Basic, Primary Management, or Secondary Management Connection of an SS is
deactivated, that SS is deregistered and shall re-register. Therefore, care
should be taken before deactivating such service flows. If a service flow that
was provisioned is deactivated, the provisioning information for that service
flow shall be maintained until the service flow is
reactivated.
6.3.14.9.5 Connection
release
page 260, line 4
Any service flow can be deleted with the DSD messages.
When a service flow is deleted, all resources associated with it are released.
If a service flow for a provisioned service is deleted, the ability to
re-establish the service flow for that service is network management
dependent. Therefore, care should be taken before deleting such service flows.
However, the deletion of a provisioned service flow shall not cause an SS to
reinitialize.
----- Original Message -----
Sent: Monday, September 06, 2004
2:52 AM
Subject: Re: [STDS-802-16] T16
Clarification
> Absolutley not!! SFIDs and
CIDs exist with a one-to-one mapping. Note
> that management messages
that create connections use SFIDs as the
> primary identifier to do so,
not CIDs. Also, note Figure 95 (in D5)
> which indicates that there is a
one-to-one mapping between SFID/CID when
> a connection (aka CID
exists).
>
> Also arbitrary traffic may not be assigned to the
Basic/Primary
> connections. This is explicitly stated in 6.3.1.1 of
D5:
>
> "The basic connection is used by the BS MAC and SS MAC to
exchange
> short, time-urgent MAC management messages. The primary
management
> connection is used by the BS MAC and SS MAC to exchange
longer, more
> delay-tolerant MAC management messages."
>
>
> -----Original Message-----
> From: owner-stds-802-16@LISTSERV.IEEE.ORG
>
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Phillip
Barber
> Sent: Sunday, September 05, 2004 8:48 PM
> To:
STDS-802-16@LISTSERV.IEEE.ORG
>
Subject: Re: [STDS-802-16] T16 Clarification
>
> Absolutely. The
standard is designed to allow function of mapping one or
> more SFIDs
(UL and/or DL agnostic) to any of the Active CIDs for the SS.
> That
includes the Basic and Primary CIDs. Typically, Service Flows with
>
attributes that require low latency would map to one of the higher
>
priority
> CIDs like Primary or even Basic. With less demanding Service
Flows, like
> Best Effort types, you would typically create a temporary
CID for the SS
> to
> map these Service Flows into, so as not to
place low priority traffic
> into
> high priority Primary and
Basic CIDs. This method of allocating multiple
> SFIDs to a limited
number of CIDs permits more effective conservation of
> the
>
scarce CID management/allocation space.
>
> Thanks,
>
Phil
>
> ----- Original Message -----
> From:
<mchion@ztesandiego.com>
> To:
<STDS-802-16@listserv.ieee.org>
> Sent: Sunday,
September 05, 2004 5:31 PM
> Subject: Re: [STDS-802-16] T16
Clarification
>
>
> > Phil,
> >
> >
Since we are on this subject, does the standard (in your opinion)
>
allows
> > multiple DL SFIDs or multiple UL SFIDs map to one CID at
one BS?
> >
> > Thanks.
> >
> >
Mary
> >
> >
> > Original Message:
> >
-----------------
> > From: Phillip Barber pbarber@BROADBANDMOBILETECH.COM
> >
Date: Sun, 5 Sep 2004 11:03:55 -0500
> > To: STDS-802-16@listserv.ieee.org
> >
Subject: Re: [STDS-802-16] T16 Clarification
> >
> >
>
> IEEE 802.16-2004, 6.3.14.2 Service flows, page 220, line 8 says
'a
> service
> > flow is a MAC transport service that provides
unidirectional transport
> of
> > packets either to uplink
packets transmitted by the SS or to downlink
> > packets transmitted
by the BS....' and line 18 says 'An SFID is
> assigned
>
to
> > each existing service flow. The SFID serves as the
principal
> identifier
> for
> > the service flow in the
network. A service flow has at least an SFID
> and
> an
>
> associated Direction.' So neither of these sentences say that
the
> SFID
> > must be unique and cannot be common between
multiple service flows,
> though
> > the language does indicate
that the SFID must be to either a UL or DL
> > service flow, not
both. However, section 3. Definitions, page 10, line
> 52,
> >
'3.52 service flow identifier (SFID): A 32 bit quantity that uniquely
>
> identifies a service flow to both the subscriber station and base
>
station
> > (BS)...' is very specific and requires that the SFID be
unique for
> that
> > specific service flow. So the answer to
your question is, NO, the SFID
> > cannot be used for both the DL and
UL of some similar service flows,
> though
> > they may share
the same CID.
> >
> > Thanks,
> > Phil
>
>
> > ----- Original Message -----
>
> From: Eyal Verbin
> > To:
STDS-802-16@listserv.ieee.org
>
> Sent: Sunday, September 05, 2004 6:53 AM
>
> Subject: Re: [STDS-802-16] T16 Clarification
>
>
> >
> > The standard allows a situation in
which a certain CID is used for a
> > certain DL SFID and the same
CID is used for another UL SFID. Does the
> same
> > approach
apply for the SFID, i.e. can a certain SFID be used for UL
> and
DL
> > connection and be distinguished by the TLV type
[145/146]
> >
> >
> >
> >
Eyal
> >
> >
> >
> >
--------------------------------------------------------------------
>
> mail2web - Check your email from the web at
> > http://mail2web.com/ .
>
>
>