REVd Sponsor Ballot Comment Addendum

Robert Nelson

Description

2004-03-13 IEEE C802.16d-04/42Project IEEE 802.16 Broadband Wireless Access Working Group Title REVd Sponsor Ballot Comment AddendumDate Submitted 2004-03-13Source(s) Robert Nelson Voice: 972-239-9224MacPhy Technologies Fax: [phone] Pittsburgh Landing [e-mail], TX 75080Re: Sponsor ballot on document IEEE P802.16REVd/D3-2004Abstract Collection of comment suggested remedies too long to include in Commentary format.Purpose Suggested remedies to be considered during REVd sponsor ballot comment resolution.This document has been prepared to assist IEEE 802.16. It is offered as a basis for discussion and is not Noticebinding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this Releasecontribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16 ...

Informations

• Publié par: Idwa
• Nombre de lectures: 24
• Langue: English

Extrait

2004-03-13

IEEE C802.16d-04/42

Project

IEEE 802.16 Broadband Wireless Access Working Group <

http://ieee802.org/16

>

Title

REVd Sponsor Ballot Comment Addendum

Date Submitted

2004-03-13

Source(s)

Robert Nelson

Voice: 972-239-9224

MacPhy Technologies

Fax: [phone]

1104 Pittsburgh Landing

[e-mail]

Richardson, TX 75080

Re:

Sponsor ballot on document

IEEE P802.16REVd/D3-2004

Abstract

Collection of comment suggested remedies too long to include in Commentary format.

Purpose

Suggested remedies to be considered during REVd sponsor ballot comment resolution.

Notice

This document has been prepared to assist IEEE 802.16. It is offered as a basis for discussion and is not

binding on the contributing individual(s) or organization(s). The material in this document is subject to

change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or

withdraw material contained herein.

Release

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this

contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in

the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution;

and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE

Standards publication. The contributor also acknowledges and accepts that this contribution may be made

public by IEEE 802.16.

Patent Policy

and Procedures

The contributor is familiar with the IEEE 802.16 Patent Policy and Procedures <

http://ieee802.org/16/ipr/

patents/policy.html

>, including the statement "IEEE standards may include the known use of patent(s),

including patent applications, provided the IEEE receives assurance from the patent holder or applicant with

respect to patents essential for compliance with both mandatory and optional portions of the standard." Early

disclosure to the Working Group of patent information that might be relevant to the standard is essential to

reduce the possibility for delays in the development process and increase the likelihood that the draft

publication will be approved for publication. Please notify the Chair <

mailto:[e-mail]

> as

early as possible, in written or electronic form, if patented technology (or technology under patent

application) might be incorporated into a draft standard being developed within the IEEE 802.16 Working

Group. The Chair will disclose this notification via the IEEE 802.16 web site <

http://ieee802.org/16/ipr/

patents/notices

>.

2004-03-13

IEEE C802.16d-04_42r0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

1

REVd/D3 Sponsor Ballot Comment Addendum

Bob Nelson

MacPhy Technologies

==========================================================================

The current document text is inconsistent regarding system scheduling. Although the parameters defined in

clause 11 are specified as being equally applicable to uplink and downlink, the only discussion of scheduling

in clause 6.4.5 specifically addresses only uplink operation. Similarly, the reference to 6.4.5 on page 35, line

6 implies that 6.4.5 describes scheduling options for all connections.

Current specification of rtPS service for uplink is incomplete in that there is no way for the scheduler to

know the interval at which it should issue unicast grant request IEs for the rtPS service flow.

To remedy these issues, the following text is proposed as replacement for the current contents of clause 6.4.5.

6.4.5 Scheduling services

Scheduling services represent the data handling mechanisms supported by the MAC scheduler for data

transport on a connection. Each connection is associated with a single data service. Each data service is asso-

ciated with a set of QoS parameters which quantify aspects of its behavior. These parameters are managed

using the DSA and DSC message dialogs. Four services (11.13.13) are supported: Unsolicited Grant Service

(UGS), Real-time Polling Service (rtPS), Non-real-time Polling Service (nrtPS), and Best Effort (BE). The

following text provides a brief description of each of the supported scheduling services, including the man-

datory QoS parameters that shall be included in the service flow definition when the scheduling service is

enabled for a service flow. A detailed description of each QoS parameter is provided in 11.13.

The UGS is designed to support real-time data streams consisting of fixed-size data packet transmitted at

periodic intervals, such as T1/E1 and Voice over IP without silence suppression. The mandatory QoS service

flow parameters for this scheduling service are Minimum Reserved Traffic Rate (11.13.10), Maximum Sus-

tained Traffic Rate (11.13.8), Maximum Latency (11.13.16), SDU Size (11.13.18), Tolerated Jitter

(11.13.15), and Request/Transmission Policy (11.13.14).

The rtPS is designed to support data streams consisting of variable-sized data packets that are transmitted at

fixed intervals, such as moving pictures experts group (MPEG) video. The mandatory QoS service flow

parameters for this scheduling service are Minimum Reserved Traffic Rate (11.13.10), Maximum Sustained

Traffic Rate (11.13.8), Maximum Latency (11.13.16), Tolerated Jitter (11.13.15), and Request/Transmission

Policy (11.13.14).

The nrtPS is designed to support delay-tolerant data streams consisting of variable-sized data packets for

which a minimum data rate is required, such as FTP. The mandatory QoS service flow parameters for this

scheduling service are Minimum Reserved Traffic Rate (11.13.10), Maximum Sustained Traffic Rate

(11.13.8), Traffic Priority (11.13.7), and Request/Transmission Policy (11.13.14).

The BE service is designed to support data streams for which no minimum service level is required and

therefore may be handled on an a space-available basis. The mandatory QoS service flow parameters for this

scheduling service are Maximum Sustained Traffic Rate (11.13.8), Traffic Priority (11.13.7), and Request/

Transmission Policy (11.13.14).