REVd Sponsor Ballot Recirc #1 - Resolution to issues regarding comment 150

Robert Nelson

Description

2004-04-15 IEEE C802.16d-04/60Project IEEE 802.16 Broadband Wireless Access Working Group Title REVd Sponsor Ballot Recirc #1 - Resolution to issues regarding comment 150Date Submitted 2004-04-15Source(s) Robert Nelson Voice: 972-239-9224MacPhy Technologies Fax: [phone] Pittsburgh Landing [e-mail], TX 75080Re: Sponsor ballot recirc #1 on document IEEE P802.16REVd/D4-2004Abstract Suggested text to resolve issues with changes implemented for comment 150 in D4 6.3.5. IEEE C802.16d-04_42r1 with the alterations specified by the accepted The text is based on resolutions for comments 150 and 151. Differences from 42r1 (other than section references) are highlighted.Purpose Suggested remedy for issues raised regarding implementation of comment 150.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 ...

Informations

• Publié par: Itti
• Nombre de lectures: 20
• Langue: English

Extrait

2004-04-15

IEEE C802.16d-04/60

Project

IEEE 802.16 Broadband Wireless Access Working Group <

http://ieee802.org/16

>

Title

REVd Sponsor Ballot Recirc #1 - Resolution to issues regarding comment 150

Date Submitted

2004-04-15

Source(s)

Robert Nelson

Voice: 972-239-9224

MacPhy Technologies

Fax: [phone]

1104 Pittsburgh Landing

[e-mail]

Richardson, TX 75080

Re:

Sponsor ballot recirc #1 on document

IEEE P802.16REVd/D4-2004

Abstract

Suggested text to resolve issues with changes implemented for comment 150 in D4 6.3.5.

The text is based on

IEEE C802.16d-04_42r1

with the alterations specified by the accepted

resolutions for comments 150 and 151. Differences from 42r1 (other than section

references) are highlighted.

Purpose

Suggested remedy for issues raised regarding implementation of comment 150.

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-04-15

IEEE C802.16d-04_60r0

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

Replace the contents of RevD/D4 section 6.3.5 with the following:

6.3.5

Uplink scheduling service

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.12) 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.12.

The UGS is designed to support real-time data streams consisting of fixed-size data packets

transmitted

issued

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 Sustained Traffic Rate (11.13.7), Maximum Latency (11.13.15)

, SDU Size (11.13.18)

, Tolerated

Jitter (11.13.14), and Request/Transmission Policy (11.13.13).

If present, the Minimum Reserved Traffic

Rate parameter (11.13.9) shall have the same value as the Maximum Sustained Traffic Rate parameter

.

The rtPS is designed to support

real-time

data streams consisting of variable-sized data packets that are

transmitted

issued

at

fixed

periodic

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.9), Maximum Sustained Traffic Rate (11.13.7), Maximum Latency (11.13.7),

Tolerated Jitter

(11.13.15),

and Request/Transmission Policy (11.13.13).

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.9), Maximum Sustained Traffic Rate

(11.13.7), Traffic Priority (11.13.6), and Request/Transmission Policy (11.13.13).

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.7), Traffic Priority (11.13.6), and Request/

Transmission Policy (11.13.13).

6.3.5.1 Outbound transmission scheduling

Outbound transmission scheduling selects the data for transmission in a particular frame/bandwidth alloca-

tion and is performed by the BS for downlink, and SS for uplink. In addition to whatever other factors the

scheduler may deem pertinent, the following items are taken into account for each active service flow:

— The scheduling service specified for the service flow.

— The values assigned to the service flow’s QoS parameters.

— The availability of data for transmission.

— The capacity of the granted bandwidth.

6.3.5.2 Uplink request/grant scheduling

Uplink request/grant scheduling is performed by the BS with the intent of providing each subordinate SS

with bandwidth for uplink transmissions or opportunities to request bandwidth. By specifying a scheduling

service and its associated QoS parameters, the BS scheduler can anticipate the throughput and latency needs

of the uplink traffic and provide polls and/or grants at the appropriate times.