RE: stds-802-16: forward request for help
Sorry, I managed to miss this one as it flew by on the reflector. I
might be able to add something here:
>>9) In the network of IEEE802.16 between the IP layer and CS sublayer
>>whether Ethernet sublayer can exist
>
><Ken S> Not certain I fully understand the question.
Put simply, yes.
As I understand it, you have three choices of stacking to support IP if
you adhere to the 802.16 CS definitions
1) IP | 802.1Q CS | MAC | PHY
2) IP | 802.3 CS | MAC | PHY
3) IP CS | MAC | PHY
If you adhere to the 802 model more strictly than most, you can support
802.2 rather than hacking in the snap header :
1) IP | LLC | 802.1Q CS | MAC | PHY
2) IP | LLC | 802.3 CS | MAC | PHY
3) IP CS | MAC | PHY
There is no explicit calling out in the standard of 802.1D or Q
interfaces (E.G. the ISS), rather the transport of frames is expressed
(802.1Q, .3 and IP). So if you want to structure your stack with the
ethernet/802.1 sublayers, you are free to do this, but the standard is
silent on the matter.
If you plan only to carry an IP service, then I suggest the IP CS might
be your most efficient option. If you want to provide more general
services (other non IP protocols), then you need the 802.1Q or 802.3 CS.
Your choice depends on whether you want to provide VLANs.
-----Original Message-----
From: owner-stds-802-16@majordomo.ieee.org
[mailto:owner-stds-802-16@majordomo.ieee.org] On Behalf Of Ken Stanwood
Sent: Tuesday, December 16, 2003 10:40 AM
To: 'Roger B. Marks'; stds-802-16@ieee.org
Cc: wang.ning1@zte.com.cn
Subject: RE: stds-802-16: forward request for help
See embedded comments.
Ken
-----Original Message-----
From: Roger B. Marks [mailto:r.b.marks@ieee.org]
Sent: Friday, December 12, 2003 7:30 AM
To: stds-802-16@ieee.org
Cc: wang.ning1@zte.com.cn
Subject: stds-802-16: forward request for help
I received some questions and, by permission of the submitter, am
forwarding them to the reflector for your consideration.
Regards,
Roger
>Roger Marks:
>
>hi,I have some questions about IEEE-802.16 and IEEE-802.16a Protocol,I
hoped to get your help.
>
>questions were depicted as below:
>
>1) whether management message service flow have their SFIDs when these
>CIDs
were allocated
<Ken S> The management connections are not considered services that
would need to be provisioned. As such they do not require SFIDs like
services associated with a service contract would.
>
>2) What the relationship between the priority of management message and
that of the Data such as UGS service if the management message with
basic CID has a higher priority than nrpts service flow?
<Ken S> The reason for dividing up the management into Basic, Primary,
and Secondary is that it was realized that there are really 3 classes of
management messages. The Basic Connection carries those that are short
and need a very fast response. Primary carries those that can be
longer, but don't need as quick a response time. The Secondary
Management connection carries standards based management traffic such as
SNMP. Since the standard does not specify scheduling algorithms, the
means of handling these management connections is left to the
implementer. Generally, it would be expected that the Basic connection
would be treated as a real-time polling connection. The Primary and
Secondary Management connections would be more likely to be treated as
non-real-time polling services, but with different traffic parameters.
>
>3) Since the Interval which was allocated for data transmiting can be
finished by UL-MAP How to allocate the bandwith for management messages
such as REG-REQ transmiting if the message such as DSx and SBC can be
sent in contention IE Initial ranging IE and Request IE
<Ken S> DSx and SBC messages, and all other management messages except
for RNG-REQ and bandwidth requests, cannot be sent in Initial ranging or
request IEs. They must be sent in Data IEs.
>
>4) In the P82 of the IEEE-802.16 there are depiction of "CRC shall be
calculated after encryption i.e. the CRC protects the Generic Header and
the ciphered Payload." but the figure 25 in P79 show that CRC appending
begin before MAC Header adding
>Whether the MAC Header should been considered in the CRC
<Ken S> You're right, these do contradict each other. I checked REVd/D1
of the standard and the contradiction is still there. We need to
correct this.
>
>5) whether the parameter of Initial ranging window is the same as that
>of
period ranging window
<Ken S> Unlike the Initial ranging window, periodic ranging is really
any opportunity to transmit data in the uplink. In the current version
of the standard, the station maintenance interval has been removed since
it is more efficient to just allocate a data grant to the terminal since
the BS can take necessary measurements off the data. So, periodic
ranging opportunities use the PHY mode currently being used for all
uplink data by the SS in question.
>
>6) Whether DSA message can add a active service flow directly when we
>want
to delete a service flow
>which step we should choose (a) we used DSD message to delete service
>flow
directly (b) we first used DSC to disactive the service flow then to
delete the admit service flow by DSD
<Ken S> Either is valid. Equipment receiving the DSx-REQ should be able
to handle either case. Equipment making the DSx-REQ can choose to do
either.
>
>7) Which type of service flow can be disactive by DSC
>which type of service flow should be delete by DSD completely who are
>responsible for recreating the service flow been deleted SS or
network management system
<Ken S> This is a network management question that is outside the scope
of the standard. The answer depends upon whether you have a network
with tight provisioning of services. In this case, regardless of
whether it's the SS or BS that adds or deletes a connection, it should
always be stimulated by network management over the Secondary Management
connection. In a less managed system the SS and BS may bring up and
tear down services as the need arises. It really depends upon the
service model of the network provider.
>
>8) For the OFDMA PHY layer because BS perform ranging by CDMA ranging
>code
BS don't kown the MAC address of SS when a SS power off how can BS
recognize certain SS's status and release its corresponding resource
such as SFID
<Ken S> The CDMA ranging is an advantageous first step in OFDM systems.
It doesn't eliminate the need to send a REG-REQ after the SS gets the
BS's attention. Someone who's more OFDM knowledgeable than I can correct
me if I'm wrong.
>
>9) In the network of IEEE802.16 between the IP layer and CS sublayer
whether Ethernet sublayer can exist
<Ken S> Not certain I fully understand the question.
>
>10) There is a Downlink Channel ID in the DCD while it not involved in
>the
DL-MAP whether DL-MAP has the one to one correspondence relationship
with Downlink Channel ID
<Ken S> The Downlink Channel ID, is only used in the unlicensed bands.
It appears to me to simply be verification of which channel is being
used. It is not in the DL-MAP because there is only one DL-MAP each
frame for the channel.
>
>11) IEEE802.16a and IEEE802.16REVd have so many difference in OFDMA PHY
>I
think it difficult to make them compatible whether the IEEE802.16a will
be discarded in future
<Ken S> REVd replaces 802.16, 802.16a, and 802.16c. When REVd is
approved, 802.16a will be obsolete.
>
>Best Regard,
>
>wangning
>
>wang.ning1@zte.com.cn