IEEE 802.16m MAC Layer Protocols: Design Principles

Document Number: IEEE C80216m-08/409r1Date Submitted: 05-05-2008

Source:Muthu Venkatachalam Muthu.Venkatachalam@intel.com Intel CorporationSassan Ahmadi Sassan.Ahmadi@intel.com Intel Corporation

Venue: IEEE Session #55, Macau.Base Contributions: None

Purpose: To identify the focus areas in IEEE 802.16m U-MAC and to layout a framework for U-MAC design(For discussion)

Notice:This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who 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:The contributor is familiar with the IEEE-SA Patent Policy and Procedures:

<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>.Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >.

IEEE 802.16m Reference Model

IEEE 802.16m Data/Control Plane IEEE 802.16f/g NetMAN

Physical Layer(PHY)

PHY SAP

Security Sub-Layer

Medium Access Control

Functions

Radio ResourceControl

andManageme

nt Functions

MAC SAP

Convergence

Sub-Layer

CS SAP

Security Sub-Layer

Management Layer

Common PartSub-Layer

Management Entity

Physical Layer

Management EntityService Specific

Convergence Sub-Layer

RANControl

andTransportFunctions

WiMAX NWGRAN

Architecture

External

Networks

MAC Common-Part Sub-Layer

IEEE 802.16 MAC

• MAC functions can be basically divided into control and data path functions.

• The MAC layer functions also can be divided into:– MAC functions that enable/support the PHY operation (aka Lower MAC).

• E.g.: Hybrid ARQ; Random access channel, MAP etc.

– MAC functions that act as protocols and interface to the upper layers (aka upper MAC).• The primary goal of these functions is NOT to support the PHY operation.

• E.g.: Power management protocols (sleep/idle), L2 mobility management protocol, ARQ protocol, QoS control

Upper MAC Focus Areas

• Traditional functions:– Data path

• ARQ protocol evolution and HARQ interworking• CS design• MAC header and sub header optimization• Multicast broadcast services data path• Airlink security

– Control path• Network entry procedures• Power management protocols (Sleep and Idle modes)• Mobility management protocols (L2 handovers)• QoS framework• MAC connection management• Multicast broadcast services control path• LBS• Airlink security • Radio Resource management

• Newer functions:– Relay functions– Multi carrier support– Self organization

Upper MAC Functional Blocks (Marked in RED)

QoS

Convergence Sub-Layer

Physical Layer

PHY Protocol (FEC Coding, Signal Mapping, Modulation, MIMO processing, etc.)

Medium Access Control Functions

Data Forwarding

MAC PDU Formation

Radio ResourceControl &

ManagementFunctions

L2

L1

Idle Mode Management

Relay Functions

Mobility Management

Radio Resource Management

Network EntryManagement

Multi-Carrier Support

MBS

Data and Control Bearers

CS SAP

Multi-Radio Coexistence

Location Management

ARQControl and Signaling

Security Sub-Layer

MAC Common Part Sub-Layer

Physical Channels

Fragmentation/Packing

Ranging

Control Plane Data Plane

Self-Organization Security Management

System ConfigurationManagement

Link AdaptationInterferenceManagement

PHY Control

Sleep Mode Management

Scheduling & Resource

Multiplexing

Design Goals for U-MAC

• Backward compatibility for the traditional features• Cleaner organization of the MAC management/control messages

– Potential usage of logical channels.• Overall MAC efficiency of 80% or higher (for data) without

compromising performance.– Efficiency improvement on the data path from optimizing

• MAC headers, • MAC sub headers,• MAC PDU formats• MAPs• Resource block sizes.

– Efficiency improvement on the control path from• MAC management messages• MAC signaling and control “channels”.

ARQ Design and H-ARQ Interworking

• Two retransmission protocols in IEEE 802.16

• In IEEE 802.16e, HARQ is decoupled from ARQ. – Retransmissions “could”

simultaneously happen at both the layers.

• Reconsider ARQ’s usage models and benefits when combined with HARQ.

• Key issues– Ensure coupling/feedback between

ARQ and HARQ, so that retransmissions are optimized.

– Minimize latency for error recovery and purge. Successful packet transmission times should be < 10msec for MAC->MAC [SRD]

– Low protocol overhead of HARQ+ARQ and uncompromised E2E reliability

HARQ

ARQ

HARQ

ARQRetransmissionsat ARQ layer

Retransmissionsat HARQ layer

sender receiverSituation in 16e

Desirable Situation

HARQ

ARQ

HARQ

ARQ

Retransmissionsfrom “coupled”ARQ/HARQ

CS Design

• Need to efficiently enable:– Fat IP pipe model for bulk data traffic

with different protocol mixes in a single CID

– Powerful header compression/suppression.

• Header compression/suppression– RoHC vs. PHS– ROHC is an external (IETF)

specification and 802.16m will have minimal control over its enhancements/changes/adaptations to 802.16m

• Efficient Adaptation/Interworking between ROHC and MAC being enabled in 802.16rev2 and can be carried over to 802.16m

– PHS has a key advantage over ROHC in that it is natively present in the MAC CS

• Fully controllable dependencies• Backward compatibility to 16e

MAC-CPS

PHY

MAC-CSPHS

ROHC (IETF)

ROHC interworking function

IP traffic

Situation of ROHC and PHS wrt 802.16

Header Suppression

• What can we do to improve the performance of PHS without overly complicating it?

• May not make sense to do first order and higher order differential since ROHC already does it.

• Some possibilities:– Can we stop transmitting not only the bytes that are constant

across PDUs but also irrelevant for the application• For example: is TTL (Time to Live) really relevant for last hop VoIP?

– Can we also conditionally/dynamically suppress some of the fields?

MAC Headers, PDUs and Messages

• MAC headers, sub-headers and PDU formats– Take a second look at the header and sub header fields for overhead

reduction.– Do we always need 6B GMH + 2 or 4B CRC for all PDUs?

• MAC management messages– Can we do something more efficient than TLV encoding of the

messages?– For example: ASN encoding..

• Physical resource downsizing– 16e has a one size fits all policy.– Do we design two types of slots in 16m, one for regular data and

another for small management messages (e.g.: BW REQ etc)

Analysis of IEEE 802.16e TLV vs. ASN Formats

• TLV format:

• When the length of a particular type is fixed, non-essential overhead = a/(8+a+b) – as high as 33 % in 16e (all the cases where a = b = 8 bits)

– Example: MAC version encoding: 8:8:8, BW REQ opportunity size : 8:8:16, start of ranging code group: 8:8:8, and many more

• A simple ASN Rule: No length field when it is fixed. That is:– TLV format when L is variable– TV format when L is fixed – max 33 % savings in overhead (occurs in many cases)

• Example: RNG-RSP message when MS performing initial ranging– Info bits = 236

Non-info bits in header = 32Non-info bits in TLV = 192Total non-info bits = 192 + 32 = 224Overhead = 224/(224+236) = 48 %

– RNG-RSP with simple ASN Rule Info bits = 236 Non-info bits in header = 32

Non-info bits in TLV = 96Total non-info bits = 32 + 92 = 128Overhead = 128/(128+236) = 35 %

Type (8) Length(a)

Value(b)

MAC Connection Management

• MAC connection identification

– Today in 802.16 a CID identifies both the MS and the connection of the MS

– Can we decouple the identification of MS (outer ID) from the identification of a particular connection on the MS (inner ID)?

– Especially when this decoupling is efficient?

• Example shows a scenario for MAP related savings with such an approach.

OID1OID1 OID2OID2 OID3OID3 OID4OID4

OID5OID5 OID6OID6 OID7OID7 OID8OID8

.... OIDnOIDn

DL MAP IE(k)IID1IID1

IID2IID2

IID3IID3

IIDnIIDn

DL Burst K

MAC Power Management Requirements (Sleep/Idle/Paging)

• Improvement in the Idle duty cycle– How to improve the efficiency of idle mode for power saving, while

reducing the overhead?• Reduction of signaling overhead related to paging

– For example, can fixed location paging channels help here?• Reduction of paging latency for certain traffic types (e.g.: PTT)• Reduction of MS network re-entry time after successful paging (<

100 ms [SRD])• Improvement in the Sleep duty cycle.

– How to improve the efficiency of sleep mode?• Reduction of return to active mode time after sleep mode • Simplification of sleep operation

– Minimization of the number of sleep classes

Coexistence of Idle and Sleep Protocols

We need both Idle and Sleep protocols

Inter-burst intervals: Sleep mode opportunities

Inter-session intervals: Idle mode

opportunities

Packet bursts: Connected mode

Signaling in Sleep Mode

• Two important performance factors for MS operating in sleep mode– MS power consumption – aka duty cycle– Signaling load generated by MS in sleep mode

• traffic indications from the network

• Uncontrolled handovers from the MS: happens today when the MS crosses the cell boundary in sleep mode

• Worthy goal to minimize the uncontrolled handovers (UHO).– Higher MS speed generally higher UHO occurrences.– Uncontrolled handovers cost power for the MS.– Total UHO occurrences for all the sleep MSs can be minimized by

• expanding the sleep area to more than one BS

• adapting the sleep area (SA) size to the MS speed,

• while keeping tabs on the variable traffic indication load generated due to varying sleep area size per MS.

• Different SA assignment algorithms possible, however standard only needs to enable an interoperable framework for adapting the SA size to the MS speed.

Internet

ASN IP Core

Concept of Adaptive Sleep Area

ASN Gateway/FAHome Agent

Packet for MN1

AI AIAIUAI UAI UAI

MN1

Packet for MN1

MN1 MN1

User BS

MN1 BS

. .

Data Path Table

113

1 2 3

4 5

Packet for MN1

MN1

8

6 7TRF-IND

MOB-TRF-IND

Signaling in Idle Mode

• Two important performance factors for MS operating in idle mode– MS power consumption – aka duty cycle– Signaling load generated by MS in idle mode (paging from the network

and location updates from the MS)

• Size of the paging group, and speed of the MS largely determine the signaling load.– Higher MS speed higher location update (LU) load for the same PG

size– Different speed MSs generate different amount of location updates for

the same PG size.– Total LU occurrences for all the Idle MSs can be minimized by

• adapting the PG size to the MS speed, • while keeping tabs on the variable paging load generated due to varying MS

PG size.

• Different PG assignment algorithms possible, however standard only needs to enable an interoperable framework for adapting the PG size to the MS speed.

MS Power Consumption in Idle/Sleep

• MS Power consumption depends on the QoS requirements, however certain optimizations can be made independent of the QoS.

• For instance: – Adapting the sleep area to MS mobility requirements can minimize

the uncontrolled handovers, which in turn saves MS power.

– Likewise, adapting the PG size to minimize the LU by the MS leads to lower power usage by the idle MS (LU costs MS power!)

– During the listen interval of the idle (sleep) MS, if we can provide a mechanism for the MS to decisively identify and decode pages (traffic indications) for it in the first frame, then the MS can shut off during other frames of the listen interval thereby saving power.

• Can we fix the PAG-ADV/TRF-IND location in relation to the 16m frame and use it on an as needed basis?

Pre-defining the Location of Paging/Sleep ChannelP

ream

ble

UL

MA

PD

L M

AP

FCH Common paging/sleepchannel at a fixed location in the DL sub-frame for paging/traffic indication

PSI: Paging Sleep Channel Indicator

No processing by MS to locate paging and other

broadcast messages

PSI

Mobility Management (L2 Handovers) Requirements

• Reduction of handoff latency [SRD] – < 30 ms for intra-frequency

– < 100msec for inter frequency

• Reduction of handoff signaling overhead• Stationary/Pedestrian (<10 Km/hr) HO performance to be optimized

[SRD]– Graceful degradation for vehicular (10-120Km/hr) HO performance

– Maintain service continuity for up to 350Km/hr speeds

• Efficient interworking for handoff protocols operating from higher layers. e.g.: Mobile IP.

• Efficient Handover to/from 16e. • Native optimization and hooks for inter-system handoff for multimode

MS– Highest priority for TGm should be 802.11 based systems given that they are

part of the 802 umbrella

QoS Framework

• Revisit MAC QoS for better support of applications and enhanced E2E performance.

• What are the meaningful/useful classes today? – BE: FTP HTTP Email Text-messaging…– xRTPs: VoIP– Is there a real use case for classes like UGS?– What kind of QoS support do “newer” applications require..

• Multicast and broadcast (MBS)• Peer-to-peer (e.g.: PTT)• Real-time and Interactive gaming• Location based services

ON Time

OFF Time

ON Time ON Time

OFF Time

A Packet Packet Inter-arrival Time

Adapting to Generic Traffic Pattern

• Reasonably generic traffic pattern is irregular ON/OFF. – ON period: packets are highly bursty with varying packet inter-arrival

time, VBR and varying packet sizes. BW demand is difficult to estimate. Meanwhile, they require real-time delivery.

– OFF period: require fast on/off transition, in order to optimize efficiency without compromising QoS.

– We cannot make any assumptions on the statistical distributions of the ON time/OFF time/Inter-arrival time etc.

• A possible approach for the generic traffic pattern:– On-period polling: similar to the rtPS.

– Off-period transition: BS detects the traffic idle periods and adjusts the polling interval adaptively. The adaptive algorithm of polling interval can be optimized with different functions, either linear, exponential..

– This approach can potentially reduce the signaling overhead for polling, with marginal cost on increased delay.

Adapting the Polling Interval to Traffic Pattern

OFF periodON period ON period

Adaptive Polling: Interval Changes

Fixed Polling Interval

Fixed Polling IntervalminT

maxTmaxT

nT

Delay Requirement > maxT

NN

Security Issues

• Improved security– Currently there is no security for MAC management messages

• Need to reconsider this issue

– Security considerations for • Fast handover within 16m• Handover to/from 16e• Handover to/from inter-RAT esp. 802.11

• Performance considerations– Impact of security procedures on other procedures such as handoff

should be minimized

– Security for MBS needs to be reconsidered due to the inherent complexity of the problem.

Location Based Service

• Ensure efficient and meaningful metrics for triangulation• Enable GPS assistance

Multicast and Broadcast Service

• Minimize MBS control, signaling overhead• Minimize channel switch time [SRD]

– Intra frequency < 1 sec

– Inter frequency < 1.5 sec

• Maximize power efficiency for MBS in idle mode. • Improve capacity

– Outer code design (e.g.: Reed-Solomon?)

– Other techniques?

Other topics…

• Network entry– How can we minimize the network entry time

– Again, rough knowledge of the BS load upfront would help!

• Newer topics– Relay Routing

– Multi carrier support

– Self organization

Recommendations

• We need focus on the key areas outlined.– Upper MAC efficiency can be significantly improved without

completely overhauling the MAC– Backward compatibility is very important!

• The upper MAC has minimal coupling with PHY– Can run in parallel to PHY for most of the time– Create two subgroups one for PHY and one for upper MAC

• Upper MAC has a lot of topics for consideration– The upper MAC chair has to come up with a well thought

out plan to phase these topics for completion in a meaningful order.

– Flood gates when opened can be overwhelming• It would be unproductive for the team to have all the upper

MAC topics open at the same time