|
Phil,
See my comments.
-----Original Message-----
From: Phillip
Barber [mailto:pbarber@broadbandmobiletech.com]
Sent: Friday,
September 17, 2004 7:44 PM
To:
STDS-802-16@listserv.ieee.org
Cc: Radu Selea
Subject: Re:
[STDS-802-16] Service flow mapping
Radu,
The Section you cite, Annex C, is informative,
not normative. Undermining its value, it is not even listed as a Recommended
Practice.
[Radu Selea] If you look into the informative and normative as
well ,you can see this paragraph on page 849:
" This annex describes the services between the MAC and the
CSs. This is a logical interface. As such, the primitives described are
informative. Their purpose is to describe the information that must
necessarily be exchanged between the MAC and the CSs to enable each to
perform its requirements as specified in the remainder of this document. This
subclause does not impose message formats or state machines for the use of
these primitives. "
The
section is informative because does not impose a certain format for the use of
the primitives ,but the information is still valid.
And where it conflicts with language in the
normative document, specifically the normative language says that CID is only
assigned to Admitted or Active Service Flows, not just Provisioned or
Authorized Service Flows, then the normative language prevails.
[Radu Selea] It is logical
that the normative should prevail but I still do not see any
conflict. Also, the primitive and trigger mechanism you
identify is intended for Service Flow provisioning and does not cover CID
provisioning events for management CIDs.
[Radu Selea] I do not
understand the last part of the sentence at all , but the first
part is in contradiction with the text.
The text is on page 850 : "This primitive is
issued by a CS entity in a BS or SS unit to request the dynamic addition of a
connection."
Then the
primitives and trigger mechanism I have identified it is not about service
flow provisioning at all. It is about connection creation or better
said about service flow admission or
activation. A connection creation can be
triggered only by an active or admitted Service
Flow.
I do not advocate the value of the
text, either normative or informative, but I would suggest not to rush
into verdicts based on personal interpretation. Anyway this is a good exercise as we can
identify potential corrigenda material.
Thanks,
----- Original Message -----
Sent: Friday, September 17, 2004 5:30
PM
Subject: Re: [STDS-802-16] Service flow
mapping
Raja,
See my comments bellow.
Radu,
Some of the functionality issues of using the same
CID for both UL and DL are:
1. The CIDs are assigned by the MAC while the SFID is assigned
maybe in the CS layer. The CS would have to somehow inform the MAC that it
is making a traffic connection for a DL traffic and the SFID of the UL
traffic is 'SFID_UL' such that the MAC can assign the same CID for both
the connections.
[Radu Selea] The CID's are assigned by means of the
primitive:
"MAC_CREATE_SERVICE
FLOW.response
{
Connection ID, response code, response message, sequence number, ARQ
parameters}
This primitive is generated by the non-initiating CS entity
when it has received a MAC_CREATE_SERVICE FLOW.indication. "
That means CID's are assigned by the
CS.
2. It implies that the DL and the UL have the same encryption
key and SAID. Currently the DL and the UL can have different
SAIDs.
[Radu Selea] This is valid but we are still into the same
situation ; if you want to use the same CID ,you can use the same
SAID.
3. The generic MAC header only includes the CID. The
MAC messages are therefore not uniquely defined by CID, but defined
by CID and direction.
[Radu
Selea] This is not a valid point as
management connection have same CID and are quite OK.
4. This understanding is in conflict with IEEE
802.16d/D5 specification.
[Radu
Selea] I can agree on that with the reserve that
on IEEE 802.16d/D5 are a lot of things in conflict, as for instance page 852
and 853 where the same primitive is generated first by MAC and
on the next page by CS ....
:)
Also I don't see a problem why two
different sectors can't use the same traffic CID. Further if the CID
assignment is done per BS and not done at the sector level there is still
64K CID space available.
[Radu
Selea] I do not see either,
but only for the case, you have all CS/MAC/PHY combo
card targeted to one
sector....
Was I able to convince you to change your mind
?
[Radu Selea] I am almost convinced, we should specify the direction
of a Service Flow. I do not quite see the parameter on which CS
or/and MAC decides if this is DL or UL service flow. Anyway I am not
supporting one way or the other but we need somehow clarification and
I think defining 2 separate ranges does not bring us too
much.
Regards,
-Raja
Raja,
I would tend to agree with Itzik
and Ken approach:
- they could be the same but they
not have to.
Probably instead
of introducing additional restrictions to the CID range we
should see if the possibility of using the same range of values on
DL and UL can introduce ambiguity.
The number of CID's used on UL and
DL do not necessarily pair. We can find out that for services like VoIP
we would need a bunch of CID's to assign (voice
lines & signaling). Aside that, taking in
account oversubscribing we can find out, that a significant part of
service flows can stay in an admitted state for some time. 64.000
it is not as much as it seems, especially for a multi-sector
BS.
We should not add other
restrictions if we do not have to....
In case that we determine
functionality issues because of the 'overlap' ,then I agree with
you.
Anyway we have to clarify the
issue one way or the other.
Cheers,
Radu.
Itzik,
Your statement is inconsistent with the standard. The standard
clearly says in section 6.3.14.2 Service Flow, that Service Flow is
unidirectional. Further Figure 95 (6.3.14.3) explicitly shows the
relationship between Service Flow to Connection is 1:0 or 1:1 and not
2:0 or 2:1 which would be required if two different service flows
could have the same connection ID.
I would therefore like the standard to clarify and state
that the same connection ID cannot be used for both uplink and
downlink traffic connections which the standard implicitly
implies.
Regards,
-Raja
Raja,
I think that your claim that same CID
cannot be used for both uplink and downlink is
wrong.
According to my understanding, since a SF
is a uni-directional entity, than we have in practice two CID
domains, one for downlink and one for uplink.
From that perspective, as Ken said, you may
have same CID value for both directions but not have
to.
Regarding the maintenance work, I agree
that if there is an ambiguity then it should be cleared, but please
be careful of putting artificial
restrictions.
Best Regards,
Itzik.
Ambroise,
I would like to see
that the
same connection ID cannot be used for both uplink and downlink
traffic connections. Basic, primary and secondary connections can
use the same CID for UL and DL though. If your contribution matches
my understanding I would also like to join the joint
contribution.
Regards,
-Raja
This is why a clarification
is needed!
Based on the initial
discussion flow, we are preparing a joint contribution to
maintenance task group with several people having participated to
the discussion.
Please let me know
if you would like to join the initiative.
Ambroise
The original intention of the
standard was that there was the ability to have separate,
overlapping CID spaces for the UL and DL. Typically a
service would have both a UL and a DL component. Typically
these would both have the same CID, but were not required
to. Over time, wordings have been changed and this concept
have become more ambiguous.
Ken
We had some discussion some time back regarding using the
same connection ID for both uplink and downlink traffic. I was not
sure what the conclusion was.
Can the same connection ID be used for both uplink
and downlink traffic connections ?
I believe no because
In section 3.12 connection: A unidirectional mapping between
base station (BS) and subscriber station (SS).
- section 6.1 PMP: Line 57, "A
connection defines both the mapping between peer convergence
processes that utilize the MAC and a service flow". The key word
here is "a service flow".
- 6.3.14.2 Service Flow.
This section explicitly specifies that Service Flow is
unidirectional. Figure 95 (6.3.14.3) explicitly shows the
relationship between Service Flow to Conneciton is 1:0 or 1:1. So
by the methode of deduction, if a Service Flow is unidirectional,
so must a Connection be, otherwise, the relationship would not be
a 1:1.
Therefore I belive that the same connection ID cannot be
used for both uplink and downlink connections.
Regards,
-Raja
At the next opportunity, I am going
to put a comment into the Maintenance TG to clarify this
matter. I believe the standard mechanics assume that a single
SFID shall map to a single CID, and that SFIDs shall map to
Transport CIDs only, never to Basic or Primary CID.
Unfortunately, the document is not clear on this matter,
something for which it should be crystal clear. I am going
to recommend clarifying language at the relevant locations to
illuminate the matter and remove any doubt.
Thanks,
Phil
----- Original Message -----
Sent: Monday, September
06, 2004 11:12 AM
Subject: Re:
[STDS-802-16] Service flow mapping
Regarding Transport Connections:
Uplink SFs obviously require a unique CID as
otherwise the BS can't control the SF's QoS
guarantees/limits. For downlink SFs, things
would break in many cases if a many-to-one SF-->CID scheme
were employed. For starters:
* SFs
couldn't use the same CID if they used different Traffic
Encryption keys (ie. different
SAIDs)
* SFs couldn't use
the same CID if one of the SFs has a PHS rule defined
and the other one does not (since PDUs include
a possibly-zero PHSI field only on
PHS-able CIDs ).
* As a
consequence of the above, DSC-REQ could not be used to add a
PHS rule to an existing SF, as it could render
a SF--->CID mapping
invalid.
* Mobility would complicate
things still further, as the absence of a CID in CID_Update is
interpreted as a command to
take down a Service Flow
There are other
places in the 802.16-2004 text that assume a 1-to-1 mapping
between Service Flows and connections eg.
5.2.2
"Classification is the process by which a MAC SDU
is mapped onto a particular connection for
transmission
between MAC peers. The mapping process
associates a MAC SDU with a connection, which also creates
an
association with the service flow characteristics of
that connection."
If the text isn't explicit enough
about the 1-to-1 mapping currently, we should fix it in the
corrigenda.
BR,
- Jeff
Eyal
Verbin wrote:
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 I
P 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.
Thanks,
Phil
----- Original Message -----
From: "Bob Nelson" <bob_nelson@IEEE.ORG <mailto:bob_nelson@IEEE.ORG> >
To: <STDS-802-16@listserv.ieee.org <mailto:STDS-802-16@listserv.ieee.org> >
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>
[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 <mailto: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 <mailto:mchion@ztesandiego.com> >
To: <STDS-802-16@listserv.ieee.org <mailto: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 <mailto:pbarber@BROADBANDMOBILETECH.COM>
Date: Sun, 5 Sep 2004 11:03:55 -0500
To: STDS-802-16@listserv.ieee.org <mailto: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 <mailto: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/ <http://mail2web.com/> .
IMPORTANT NOTICE: This message is intended only
for the use of the individual or entity to which it is addressed. The
message may contain information that is privileged, confidential and
exempt from disclosure under applicable law. If the reader of this
message is not the intended recipient, or the employee or agent
responsible for delivering the message to the intended recipient, you
are notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify Redline immediately by email at
postmaster@redlinecommunications.com.
Thank you.
|