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