IEEE 802.16m MAC Layer Protocols: Design Principles
Document Number: IEEE C80216m-08/409r1
Date Submitted: 05-05-2008
Source:
Muthu Venkatachalam
Sassan Ahmadi
Muthu.Venkatachalam@intel.com
Sassan.Ahmadi@intel.com
Intel Corporation
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
CS SAP
Radio
Convergence
Resource
Sub-Layer
Control
and
Management
Functions
Management Entity
Service Specific
Convergence Sub-Layer
MAC SAP
Medium Access
Control Functions
Security Sub-Layer
Management Layer
Common Part
Sub-Layer
Physical Layer
(PHY)
MAC Common-Part
Sub-Layer
External
Network
s
Security Sub-Layer
WiMAX NWG
RAN
Architecture
PHY SAP
IEEE 802.16m Data/Control Plane
RAN
Control
and
Transport
Functions
IEEE 802.16f/g NetMAN
Management Entity
Physical 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)
Control Plane
Data Plane
Radio Resource Management
Network Entry
Management
Relay Functions
Multi-Carrier Support
Mobility Management
Location Management
CS SAP
Idle Mode Management
Radio Resource
Control &
Management
Functions
Self-Organization
MBS
Convergence Sub-Layer
Security Management
System Configuration
Management
Data and Control Bearers
L2
QoS
Multi-Radio Coexistence
Sleep Mode Management
Data Forwarding
Control and Signaling
Scheduling & Resource
Multiplexing
ARQ
PHY Control
Ranging
Link Adaptation
Fragmentation/Packing
Interference
Management
Medium Access Control Functions
MAC PDU Formation
Security Sub-Layer
Physical Channels
L1
PHY Protocol (FEC Coding, Signal Mapping, Modulation, MIMO processing, etc.)
Physical Layer
MAC Common Part Sub-Layer
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.
ARQ
Retransmissions
at ARQ layer
ARQ
HARQ
Retransmissions
at HARQ layer
HARQ
sender
• 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
Situation in 16e
receiver
ARQ
ARQ
Retransmissions
from “coupled”
ARQ/HARQ
HARQ
HARQ
Desirable Situation
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.
•
IP traffic
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
ROHC (IETF)
PHS ROHC interworking function
MAC-CS
MAC-CPS
PHY
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)
–
•
Length
(a)
Value
(b)
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:
–
–
•
Type (8)
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 = 32
Non-info bits in TLV = 192
Total non-info bits = 192 + 32 = 224
Overhead = 224/(224+236) = 48 %
RNG-RSP with simple ASN Rule
Info bits = 236
Non-info bits in header = 32
Non-info bits in TLV = 96
Total non-info bits = 32 + 92 = 128
Overhead = 128/(128+236) = 35 %
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.
DL Burst K
DL MAP IE(k)
IID1
OID1 OID2 OID3 OID4
OID5 OID6 OID7 OID8
..
OIDn
IID2
IIDn
IID3
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
Packet bursts:
Connected mode
Inter-burst intervals:
Sleep mode
opportunities
Inter-session intervals:
Idle mode
opportunities
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.
Concept of Adaptive Sleep Area
Packet for MN1
Data Path Table
User
MN1
Packet for MN1
BS
Home
Agent
ASN Gateway/FA
BS 13
ASN IP Core
.
.
Internet
Packet for MN1
MOB-TRF-IND
5
4
8
TRF-IND
2
1
MN1
MN1
UAI
MN1
AI
UAI
7
6
3
MN1
AI
UAI
AI
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 Channel
FCH
DL MAP
UL MAP
Preamble
PSI
PSI: Paging Sleep Channel Indicator
Common paging/sleep
channel at a fixed location in
the DL sub-frame for
paging/traffic indication
No processing by MS to
locate paging and other
broadcast messages
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
A Packet
Packet Interarrival Time
OFF Time
ON Time
OFF Time
ON Time
ON 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
Delay Requirement > Tmax
Fixed Polling Interval
Tmin
Fixed Polling Interval
Adaptive Polling: Interval Changes
Tn
ON period
N
Tmax
Tmax
OFF period
ON period
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