MAC Protocol Proposal for Fixed BWA Networks Based on DOCSIS. Re: Medium Access Control Task Group Call for Contributions Session #4

Similar documents
Media Access Control Protocol Based on DOCSIS 1.1

Proposed Amendments to mc-00/01 for MAC Layer to Include a Bandwidth-On-Demand MAC/PHY Sublayer

BreezeCOM Voice: Atidim Building 1 Fax: Tel Aviv, Israel

Preliminary Performance Evaluation of QoS in DOCSIS 1.1

Initial PHY Layer System Proposal for Sub 11 GHz BWA

rtions of this document are reprinted with permission from Cable Television Laboratories, Inc.

IEEE Broadband Wireless Access Working Group < Evaluation Procedure for MAC Protocols

Page 1 of 1 16-Jan-01

Document Number: IEEE mp-00/01 Title: Media Access Control Protocol Based on DOCSIS 1.1 Date Submitted: Source: Glen Sater Voice:

IEEE Broadband Wireless Access Working Group < Increasing Link Robustness in TG3 Systems

Nokia Fax:

IEEE C /08

Modeling a MAC Scheduler: Experiences with a DOCSIS Cable

IEEE Broadband Wireless Access Working Group < Proposal for MAC protocol modification for

IEEE c-00/11. IEEE Broadband Wireless Access Working Group <

Cover Page. Performance Evaluation of the DOCSIS 1.1 MAC Protocol According to the Structure of a MAP Message

IEEE C /26. IEEE Working Group on Mobile Broadband Wireless Access <

MAC Overview NCHU CSE WMAN - 1

Relay Support for Distributed Scheduling and its Bandwidth Request/Allocation Mechanism

IEEE sub10-00/03r1. IEEE Broadband Wireless Access Working Group

Evaluation Procedure for MAC Protocols

Institute of Electrical and Electronics Engineers (IEEE)

IEEE Broadband Wireless Access Working Group < The document contains ARQ Proposal for /4 MAC

IEEE /15. IEEE Broadband Wireless Access Working Group < Title Interpretation of IEEE Standard 802.

IEEE C802.16e-05/192r1. IEEE Broadband Wireless Access Working Group <

IEEE abc-01/18r1. IEEE Broadband Wireless Access Working Group <

IEEE C802.16maint-05/091r1. IEEE Broadband Wireless Access Working Group <

IEEE 802 Executive Committee Study Group on Mobile Broadband Wireless Access < Implication of End-user.

MAC layer: structure and QoS support. PhD student: Le Minh Duong

IEEE C802.16e-05/196r1. IEEE Broadband Wireless Access Working Group <

Distributed Queue Dual Bus

Data Integrity in MAC IEEE Presentation Submission Template (Rev. 8)

IEEE Broadband Wireless Access Working Group <

MMR network data forwarding and QoS schema

DQDB. Distributed Queue Dual Bus (DQDB) DQDB is a MAN. Unlike FDDI, DQDB is an IEEE standard: 802.6

Round Trip Delay Optimization

IEEE Broadband Wireless Access Working Group < Performance enhancement with efficient mapping of outer-coded MBS streams

ACLASS of users that has drawn much attention over the

IEEE Broadband Wireless Access Working Group < Changes in Definition of Data Delivery Services

Performance Evaluation of Scheduling Mechanisms for Broadband Networks

Lecture 22 Overview. Last Lecture. This Lecture. Next Lecture. Internet Applications. ADSL, ATM Source: chapter 14

IEEE Broadband Wireless Access Working Group <

Functional Requirements 10/20/2003. IEEE Working Group on Mobile Broadband Wireless Access <

IEEE Broadband Wireless Access Working Group <

IEEE Broadband Wireless Access Working Group < Detailed ARQ Proposal for a and b MAC

PON Functional Requirements: Services and Performance

ETSI Project BRAN Hiperlan Type 2 for IEEE 1394 Applications System Overview

L2VPN Support on Cable

IEEE Broadband Wireless Access Working Group <

IEEE C802.16maint-05/091. IEEE Broadband Wireless Access Working Group <

Relationship Between MIB Objects and CLI Show Commands

BROADBAND AND HIGH SPEED NETWORKS

IEEE Broadband Wireless Access Working Group < Procedures for inter-system communication over the air

IEEE Broadband Wireless Access Working Group <

A Flexible Architecture for EPON

IEEE MAC/CC Overview

IEEE C802.16e-04/67r1. IEEE Broadband Wireless Access Working Group <

Connection-Oriented Software-Defined Networking

IEEE Broadband Wireless Access Working Group <

Chapter 3.1 Acknowledgment:

IEEE Broadband Wireless Access Working Group < Early transmission of higher layer packets in the idle mode

100BASE-Cu Dual Mode Proposal

IEEE C802.16maint-08/064r3

Bandwidth-on-Demand up to very high speeds. Variety of physical layers using optical fibre, copper, wireless. 3BA33 D.Lewis

Relationship Between MIB Objects and CLI Show Commands

IEEE Broadband Wireless Access Working Group <

IEEE abc-01/19. IEEE Broadband Wireless Access Working Group <

IEEE Broadband Wireless Access Working Group < MSS s buffer capability negotiation for DL H-ARQ operation

Part 5: Link Layer Technologies. CSE 3461: Introduction to Computer Networking Reading: Chapter 5, Kurose and Ross

Abstract of the Book

IEEE C802.16d-03/45. IEEE Broadband Wireless Access Working Group <

IEEE C802.16e-05/242r1. IEEE Broadband Wireless Access Working Group <

Understanding Modern Cable Systems using DOCSIS

IEEE C802.16e-318. IEEE Broadband Wireless Access Working Group <

IEEE C802.16maint-08/064r4

IEEE C802.16e-04/195r1. IEEE Broadband Wireless Access Working Group <

Mobile Communications Chapter 7: Wireless LANs

ATM. Asynchronous Transfer Mode. these slides are based on USP ATM slides from Tereza Carvalho. ATM Networks Outline

Master Course Computer Networks IN2097

Performance Evaluation of WiFiRe using OPNET

Wireless Communication. IEEE Wireless Metropolitan Area Network (wman)

QoS in a SOHO Virtual Private Network for IP Telephony

IEEE C802.16a-02/14

IEEE C802.16e-05/401r2

IEEE C802.16h-07/017. IEEE Broadband Wireless Access Working Group <

Technical Committee. E1 Physical Interface Specification. af-phy

EL Wireless and Mobile Networking Spring 2002 Mid-Term Exam Solution - March 6, 2002

CCNA Exploration1 Chapter 7: OSI Data Link Layer

I Voice Trunking Format over MPLS Implementation Agreement. MPLS /Frame Relay Alliance 5.0.0

How DOCSIS Protocol Solves Asymmetric Bandwidth Issue in Cable Network

IEEE C802.16e-05/401r3

IEEE Broadband Wireless Access Working Group < Huawei LB26b, Working Group Letter Ballot on P802.

Message definition to support MS network entry in centralized allocation model

IEEE C802.16e-04/201. Project. IEEE Broadband Wireless Access Working Group <

Switched Multimegabit Data Service (SMDS)

Protocol Independent PHY Specific Sub-layer (PSS) for PON

ENGINEERING COMMITTEE Data Standards Subcommittee ANSI/SCTE R2007

Performance of UMTS Radio Link Control

Switched Multimegabit Data Service

IEEE Broadband Wireless Access Working Group <

Transcription:

Project Title Date Submitted IEEE 802.16 Broadband Wireless Access Working Group MAC Protocol Proposal for Fixed BWA Networks Based on DOCSIS 1999-10-29 Source Phil Guillemette SpaceBridge Networks Corporation 115 Champlain St. Hull, Quebec, J8X 3R1 Voice: +1-819-776-2848 Fax: +1-819-776-4179 E-mail: pguillemette@spacebridge.com Re: 802.16 Medium Access Control Task Group Call for Contributions Session #4 Abstract Purpose Notice The proposed MAC protocol is based on DOCSIS 1.1 with modifications to make it more suitable to wireless environment. The MAC protocol is designed to support the transport of multiple protocols both in point-to-point and point-to-multipoint system configurations. The authors desire that the proposed MAC protocol be accepted in whole or partially as the MAC protocol standard for IEEE 802.16. This document has been prepared to assist the 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 acknowledges and accepts that this contribution may be made public by 802.16. IEEE Patent Policy The contributor is familiar with the IEEE Patent Policy, which is set forth in the IEEE-SA Standards Board Bylaws < http://standards.ieee.org/guides/bylaws> and includes the statement: IEEE standards may include the known use of patent(s), including patent applications, if there is technical justification in the opinion of the standards-developing committee and provided the IEEE receives assurance from the patent holder that it will license applicants under reasonable terms and conditions for the purpose of implementing the standard. 0

MAC Protocol Proposal for Fixed BWA Networks Based on DOCSIS 1. Introduction P. Guillemette, E. Wibowo SpaceBridge Networks Corporation This document presents an overview of a MAC layer protocol recommended for adoption by the 802.16 Work Group for BWA networks. This MAC protocol is designed to support the transport of multiple protocols, such as IP and ATM, in both point-to-point and point-to-multipoint system configurations. The MAC protocol proposed is based on DOCSIS 1.1 [1] with modifications to make it more suitable to wireless environment. 1.1. Overview This section highlights features of the proposed MAC protocol, which include:! Bandwidth allocation controlled by BWA BTS.! A stream of mini-slots in the upstream.! Dynamic mix of contention- and reservation-based upstream transmit opportunities.! Bandwidth efficiency through customized support of fixed-size and variable-size PDU as well as bandwidthefficient MAC messaging.! Support for transport of multiple protocols.! Support for QoS, including:! Support for bandwidth, latency and bit-error-rate guarantees.! Dynamic Service Establishment.! Optimized for point-to-multipoint as well as point-to-point BWA systems.! Optional security at the data link layer.! Support for a wide range of data rates. 1.2. Acronyms ATM BWA BTS DOCSIS EH FEC IE IP Asynchronous Transfer Mode Broadband Wireless Access Base Station Data-Over-Cable Service Interface Specifications Extended Header Forward Error Correction Information Element Internet Protocol MAC PDU Media Access Control Protocol Data Unit 1

PHY Physical (Layer) PMD Physical Medium Dependent QoS Quality-of-Service SFID Service Flow Identifier SID Service Identifier SNMP Simple Network Management Protocol STS Stations SYNC Synchronization 1.3. Definitions MAC Layer Domain A MAC layer domain is a collection of upstream and downstream channels for which a single MAC allocation and management protocol operates. Its attachments include one BWA BTS and one or more BWA STS. The BWA BTS services all of the upstream and downstream channels. Each BWA STS may access one or more upstream and downstream channels. Service Flow The concept of service flows is central to the operation of the MAC protocol. Service flows provide a mechanism for upstream and downstream QoS management. In particular, they are integral to bandwidth allocation. A SFID defines a particular unidirectional mapping between a BWA STS and the BWA BTS. Active SFIDs also have associated SIDs. Upstream bandwidth is allocated to SIDs, and hence to BWA STS, by the BWA BTS. SIDs provide the mechanism by which upstream Quality-of-Service is implemented. The BWA BTS may assign one or more SFIDs to each BWA STS, corresponding to the service flows required by the BWA STS. This mapping can be negotiated between the BWA BTS and the BWA STS during registration or via dynamic service establishment. It is necessary to be able to send certain upstream packets needed for MAC management, SNMP management, key management, etc. For the network to function properly, all BWA BTSs must support at least one upstream and one downstream service flow. These service flows are referred to as the upstream and downstream primary service flows. The SID assigned to the upstream primary service flow is referred to as the primary SID. The primary SID must always be assigned to the first provisioned upstream service flow during the registration process. The primary service flow must be immediately activated at registration time. The primary SID must always be used for station maintenance after registration. The primary service flows may be used for traffic. All SFIDs are unique within a single MAC layer domain. The length of the SFID is 32 bits. The length of the SID is 16 bits. A service flow is differentiated by, among other things, the type of protocol data unit being transported (e.g., IP, ATM). Upstream Intervals and Mini-Slots The upstream transmission time-line is divided into intervals by the upstream bandwidth allocation mechanism. Each interval is an integral number of mini-slots. A mini-slot is the unit of granularity for upstream transmission opportunities. There is no implication that any PDU can actually be transmitted in a single mini-slot. Each interval is labeled with a usage code, which defines both the type of traffic that can be transmitted during that interval and the physical-layer modulation encoding. Frame 2

A frame is a unit of data exchanged between two or more entities at the Data Link layer. A MAC frame consists of a MAC header and a variable-size PDU. 1.4. References 1. Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification, SP-RFIv1.1-I01-990311. 2. Media Access Control Specifications 2.1. MAC Reference Model The proposed MAC layer lies between the optional Security layer and the PHY layer as seen in Figure 1. The MAC layer functionality is invisible to higher layers. Higher Layer Protocols (HLP) - TCP/IP HLP - ATM 802.2 LLC ATM Adaptation Layer Other types of payloads ATM Layer Security MAC Transmission Convergence Sublayer Physical Medium Dependent Sublayer Figure 1. MAC Reference Model 2.2. MAC Frame Format 2.2.1. Generic MAC Frame Format A MAC frame is the basic unit of transfer between the MAC layer at the BWA STS and the BWA BTS. The same basic structure is used in both the upstream and downstream directions. MAC frames are variable in length. Generic format of MAC frames is shown in Figure 2. The MAC header uniquely identifies the contents of the MAC frame. The size of the MAC header can be 1 or 4 bytes, depending on whether the header is a base header or an extended header. MAC Header (1 or 4 bytes) Payload (variable length) 3

Figure 2. Generic MAC Frame 2.2.2. Base MAC Header The base MAC header is 1 byte long, and is used to indicate that the MAC frame contains a fixed-size PDU (e.g., an ATM cell). The format of the base MAC header is shown in Figure 3. Payload Type (2 bits) EH (1 bit) Checksum (2 bits) Figure 3. Base MAC Header Format The 3-bit field indicates the type of PDUs carried within the MAC frame. The encoding of the field is shown in Table 1. Encoding Protocol Data Unit 000 IP 001 ATM 010-111 Reserved Table 1. Field Encoding The 2-bit Payload Type field indicates the content of the payload section of the MAC frame. The encoding of the Payload Type field is shown in Table 2. Payload Type Encoding Payload Content 00 Higher-Layer Data 01 MAC Management and Control Data 10 MAC Management and Control Data, and Higher-Layer Data 11 Request Table 2. Payload Type Field Encoding The 1-bit EH field indicates whether the length of the MAC header is 1 byte (base header, EH = 0) or 4 bytes (extended header, EH = 1). Finally, the 2-bit Checksum field is used to protect the MAC header. 2.2.3. Extended MAC Header The extended MAC header is used to indicate that the MAC frame contains a variable size PDU (e.g., MAC management / control messages, IP packets, ATM cells, etc.). The format of the extended MAC header is shown in Figure 4. Payload Type (2 bits) EH = 1 Checksum = 00 Length Ext. Checksum 4

Figure 4. Extended MAC Header Format The 16-bit Length field indicates the length of the MAC frame (in bytes), whereas the 8-bit Extended Checksum field is used to protect the overall MAC header. Note that the 2-bit Checksum field is set to 00 for an extended MAC header. 2.2.4. MAC Management and Control Frame MAC Management and Control Frames are used to exchange MAC management and control data between the BWA BTS and BWA STSs. The format of the MAC Management and Control Frame is shown in Figure 5. Payload Type = 01 EH = 1 Checksum = 00 Length Ext. Checksum MAC Management and Control Data (variable length) Figure 5. MAC Management and Control Frame Upstream and downstream MAC management and control messages are composed of one or more IEs. The general format of information elements is shown in Figure 6. IE Type IE Length (8 or 24 bits) Payload (variable length) Figure 6. Information Element General Format The IE Type field specifies the purpose of the information element. The IE Length field specifies the length of IE data (in bytes). All information elements are an integral number of octets in length. When the payload field is less than 255 octets long, the IE Length field shall be an 8-bit unsigned integer. When the payload field is 255 octets long or larger, the IE Length field shall be a 24 bits long; in this case, the first byte of the IE Length field shall be set to 255 and the remaining two bytes shall be taken as a 16-bit unsigned integer. Both the BWA STS and the BWA BTS shall be able to correctly receive both the 8-bit and 24- bit codings of the IE Length field. 2.2.5. MAC Management / Control and Higher-Layer PDU Frame MAC Management / Control and Higher-Layer PDU Frames are used to transport both MAC management / control messages and higher-layer PDUs between the BWA BTS and the BWA STS. For example, MAC Management / Control and Higher-Layer PDU Frames can used to piggyback request for bandwidth in the data PDU or to transport concatenated / fragmented data PDUs. The format of the MAC Management / Control and Higher-Layer PDU Frame is shown in Figure 7. Payload Type = 10 EH = 1 Checksum = 00 Length Ext. Checksum MAC Management / Control IEs and Higher-Layer PDU (variable length) Figure 7. MAC Management / Control and Higher-Layer PDU Frame 2.2.6. Request MAC Frame Note in Table 2 that a specific Frame Type encoding (Frame Type = 11) is used to indicate that that the content of the payload is a request. Request MAC frames are used to transport bandwidth requests for SIDs to the BWA 5

BTS during unicast or contention request opportunities. The format of the Request MAC frame is shown in Figure 8. Payload Type = 11 EH = 1 Checksum = 00 SID Request Ext. Checksum Figure 8. Request MAC Frame The 16-bit SID field indicates the SID for which bandwidth is requested. The 16-bit Request field indicates the amount of bandwidth requested for the SID (in mini-slots). The 8-bit Extended Checksum field is used to protect the Request MAC frame. 2.3. Upstream Bandwidth Allocation The upstream channel is modeled as a stream of mini-slots. The BWA BTS must generate the time reference for identifying these slots. It must also control access to these slots by the BWA STSs. For example, it may grant some number of contiguous slots to a BWA STS for it to transmit a PDU. The BWA STS must time its transmission so that the BWA BTS receives it in the time reference specified. The basic mechanism for assigning bandwidth management is the allocation map. The allocation map is a variablelength MAC management message transmitted by the BWA BTS on the downstream channel, which describes, for some interval, the uses to which the upstream mini-slots must be put. A given map may describe some slots as grants for particular stations to transmit data in, other slots as available for contention transmission, and other slots as an opportunity for new stations to join the link. Many different scheduling algorithms may be implemented in the BWA BTS by different vendors. This specification does not mandate a particular algorithm. The bandwidth allocation must include the following basic elements:! Each BWA STS has one or more short (16-bit) SIDs as well as a 48-bit address.! Upstream bandwidth is divided into a stream of mini-slots. Each mini-slot is numbered relative to a master reference maintained by the BWA BTS. The clocking information is distributed to the BWA STSs by means of SYNC packets.! BWA STSs may issue requests to the BWA BTSs for upstream bandwidth. The BWA BTS must transmit allocation map PDUs on the downstream channel defining the allowed usage of each mini-slot. 2.3.1. Requests Requests refer to the mechanism that BWA STSs use to indicate to the BWA BTS that it needs upstream bandwidth allocation. A request may come as a stand-alone request frame transmission in a contention or unicast request opportunity, or it may come as a piggyback request in another frame transmission. The request must include:! The SID making the request.! The amount of bandwidth requested (in mini-slots). 6

2.3.2. Request Acknowledgement Request Acknowledgement IEs acknowledge requests that have been received by the BWA BTS. A Request Acknowledgement IE is preceded by the Acknowledgement Time, which is the latest time (in mini-slots), from BWA BTS initialization, processed in the upstream. Request Acknowledgement IE contains the list of SIDs whose requests have been received by the BWA BTS up to the Acknowledgement Time, and after the Acknowledgement Time of the previous Request Acknowledgement IE. 2.3.3. Data Acknowledgement Data Acknowledgement IEs acknowledge data PDUs that have been received by the BWA BTS. The BWA STS must have requested this acknowledgement within the data PDU. A Data Acknowledgement IE is preceded by the Acknowledgement Time, which is the latest time (in mini-slots), from BWA BTS initialization, processed in the upstream. Data Acknowledgement IE contains the list of SIDs whose data have been received by the BWA BTS up to the Acknowledgement Time, and after the Acknowledgement Time of the previous Data Acknowledgement IE. 2.3.4. Map Transmission and Timing The allocation map must be transmitted in time to propagate across the wireless link and be received and handled by the receiving BWA STS. As such, it may be transmitted considerably earlier than its effective time. The components of the delay are:! Worst-case round-trip propagation delay.! Queueing delays within the BWA BTS implementation-specific.! Processing delays within the BWA STS must allow a minimum processing time by each BWA STS.! PMD-layer FEC interleaving. 2.3.5. BWA STS Bandwidth Utilization The following rules govern the response a BWA STS makes when processing maps.! A BWA STS must first use any grants assigned to it. Next, the BWA STS must use any unicast request opportunity for it. Finally, the BWA STS must use the next available broadcast/multicast request opportunity for which it is eligible. 2.4. Service Classes Any service flow may have its QoS parameter set specified in any of three ways:! By explicitly including all traffic parameters.! By indirectly referring to a set of traffic parameters by specifying a service class name.! By specifying a service class name along with modifying parameters. A service class name is a string, which the BWA BTS associates with a QoS parameter set. The service class serves the following purposes:! It allows operators, who so wish, to move the burden of configuring service flows from the provisioning server to the BWA BTS. 7

! It allows BWA BTS vendors to provide class-based queueing if they choose to, where service flows compete within their class and classes compete with each other for bandwidth.! It allows higher-layer protocols to create a service flow by its service class name.! It allows packet classification policies to be defined, which refer to a desired service class, without having to refer to a particular service flow instance of that class. 2.4.1. Quality-of-Service Parameters QoS parameters supported by this specification are listed in [1], Appendix C. Additional QoS parameters supported by this specification are Maximum Traffic Rate, Upstream Maximum Traffic Rate, Downstream Maximum Traffic Rate, Maximum Bit Error Rate, Upstream Maximum Bit Error Rate and Downstream Maximum Bit Error Rate. 2.5. Benefits and Drawbacks of the Proposed MAC Protocol Benefits of the proposed MAC protocol are as follows:! Bandwidth efficiency achieved due to:! Small MAC header overhead for fixed-size PDUs, such as ATM cells.! Support for variable-size PDUs, such as IP packets.! Bandwidth-efficient MAC messages.! Support for transport of multiple protocols.! Support for QoS, including bandwidth, latency and bit-error-rate guarantees. Drawbacks of the proposed MAC protocol are as follows:! Support for two MAC header size adds to implementation complexity. 8