IEEE C802.16m-10/1452
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Amendments for AAI-L2-XFER in IEEE 802.16m/D10
Date
Submitted
2010-12-19
Source(s)
Junghoon Jee, Jaesun Cha
E-mail: jhjee@etri.re.kr
ETRI
Peretz Feder, Suresh Nair, Ajay Rajkumar
ALU
Re:
Category: D10 / Area: Chapter 16.2.3.30, Annex R.2 (AAI-L2-XFER)
Abstract
This contribution proposes amendments for AAI-L2-XFER in the IEEE 802.16m/D10
Purpose
To be discussed and adopted by TGm
Notice
Release
Patent
Policy
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.
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.
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>.
1
IEEE C802.16m-10/1452
Amendments for AAI-L2-XFER in IEEE 802.16m/D10 (16.2.3.30, Annex R.2)
Junghoon Jee, Jaesun Cha
ETRI
Peretz Feder, Suresh Nair, Ajay Rajkumar
ALU
1. Reasons for Remedy
It should be first noted that there exists 'NO' WiMAX NWG specs which specify the use of ORAT MSG over
AAI-L2-XFER for Inter-RAT handover. Therefore, the statement of reject reason in the previous recirc #3,
“ORAT MSG, which is a bearer to carry other RAT's message, may be used in WiMAX NWG, instead of MIH
frame." is incorrect.
The detailed issues about this “ORAT L2-XFER” approach are like the followings:
First of all, this approach is unproven. Each RAT's native messages need to be used and sent over the air.
Therefore, each encapsulated RAT MAC type message is different and needs different MAC decoder.
Secondly, the major challenge when following this approach is "how to deliver the other RAT MAC messages
to the "16m" networks? One approach would be based on a very tight "coupling" between IEEE 802.16m
systems and other technologies (LTE, WiFi, CDMA2000, etc.). This apparently requires a well-defined interface
between an IEEE 802.16m core network entity (e.g. ASN-GW) and that of other RAT (e.g., MME) to deliver
the other RAT MAC messages to the AMS. (Example message path: eNB=>MME=>ASN-GW=>ABS=>AMS)
However, such interface does not exist and would be very challenging to accomplish. That's one of the reasons
why the current WiMAX NWG is primarily relying on the L3 tunneling between an (A)MS and SFF(Signaling
Forwarding Function) to enable the single radio handover with other RATs. This approach does not require
opening the interface between the different core network entities (e.g, between the ASN-GW and 3GPP MME).
Another issue is that the current IEEE 802.16m/D10 does not provide a detailed description how the ORAT type
could be utilized to enable Inter-RAT handover. More specifically, the IEEE 802.16m/D10 only defines a
couple of sub-type values for different technologies, GERAN, UTRAN, E-UTRAN, TDSCDMA, CDMA2000.
There's no detailed description on how those other RAT MAC messages can be utilized to enable Inter-RAT
handover of 802.16m AMS by transferring them over the IEEE 802.16m air links. This casts a serious doubt
whether the ORAT method can work. It should also be noted that there are no ORAT types defined for WiFi,
HRPD and etc.
The last issue is about overloading the IEEE 802.16 air interface by broadcasting other RAT frames (ORAT
MSG) natively over AAI-L2-XFER. There are MAC messages which are broadcast to help network discovery
and selection within a certain type of access technology network. Blindly delivering those broadcast frames over
the 802.16m air interface would create significant overhead for the 802.16m ABS.
2
IEEE C802.16m-10/1452
Moreover, it should be noted that the MIH frame which is standardized by IEEE 802 as “Std. IEEE 802.212008” can be delivered as the “Transfer-Type=7” of AAI-L2-XFER. The Std. IEEE 802.21-2008 is the
representative standard for supporting Inter-RAT handover in IEEE 802.
2. Proposed Text for IEEE P802.16m/D10
============================ Start of Proposed Text ==================================
[Editor’s Note: The following is the proposed change in the 802.16m/D10. Note that the new text is
marked with blue and underline; the deleted text are marked with red and strikethrough.
Suggested change #1: page 184, line 40 in 16.2.3.30
[Change text as follows:]
3
IEEE C802.16m-10/1452
Field
L2-Xfer Type
The
Size (bits)
8
Value/Description
Transfer-Type=1; GNSS assistance (DL)
Transfer-type=2 ; LBS measurement
[Terrestrial meas. and GNSS pseudo
ranges] (UL)
Transfer-Type=3; Device Bootstrap
(DL/UL)
Transfer-Type=4; WirelessMANOFDMA Advanced Air Interface System
network boundary indication (DL)
Transfer-Type=5; ORAT-MSG (DL)
Transfer-Type=65; SMS
Transfer-Type=76; MIH Frame
Transfer-Type=87; ASN control messages for Relay support (DL/UL)
Transfer-Type=98; Emergency Alert
Transfer-Type=109-127; reserved
Transfer-Type=128-255; Vendor specific types
If (Transfer-Type=5) {
L2-Xfer Sub Type
4
Sub-Type=1:GERAN(GSM/GPRS/
EGPRS)
Sub-Type=2: UTRAN
Sub-Type=3: E-UTRAN
Sub-Type=4: TDSCDMA
Sub-Type=5: CDMA2000
L2-Xfer payload
} else if (Transfer-Type=
65) {
L2-Xfer Sub Type
4
Sub-Type=1: SMS data
Sub-Type=2: SMS confirmation
L2-Xfer payload
} else if (Transfer-Type=
76) {
L2-Xfer Sub Type
4
Sub-Type=1: Service Management
Sub-Type=2: Event Service
Sub-Type=3: Command Service
Sub-Type=4: Information Service
Condition
L2-Xfer payload
} else {
L2-Xfer payload
}
enumeration of Transfer-Type is as follows:
a) Transfer-Type = 1; GNSS assistance (DL)
b) Transfer-Type = 2; LBS measurement [Terrestrial meas. and GNSS pseudo ranges] (UL)
c) Transfer-Type = 3; Device Bootstrap (DL/UL)
d) Transfer-Type = 4; WirelessMAN-OFDMA Advanced Air Interface System network boundary indication (DL)
e) Transfer-Type = 5; ORAT-MSG (DL)
i) Sub-Type = 1: GERAN (GSM/GPRS/EGPRS)
ii)
Sub-Type = 2: UTRAN
iii)
Sub-Type = 3: E-UTRAN
iv)
Sub-Type = 4: TDSCDMA
v)
Sub-Type = 5: CDMA2000
f) Transfer-Type = 65: SMS
i)
Sub-Type = SMS data
4
IEEE C802.16m-10/1452
ii)
Sub-Type = SMS confirmation
g) Transfer-Type = 76: MIH Frame
i)
Sub-Type =1 : Service Management
ii) Sub-Type =2 : Event Service
iii) Sub-Type = 3 : Command Service
iv) Sub-Type = 4 : Information Service
h)
Transfer-Type = 87; ASN control messages for Relay support (DL/UL)
i)
Transfer-Type = 98; Emergency Alert
j)
Transfer-Type = 109-127; reserved
k)
Transfer-Type = 128-255; Vendor specific types
Suggested change #2: page 1088, line 62 in Annex R.2
[Change text as follows:]
-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+AAI-L2-XFER ::= SEQUENCE {
transferType INTEGER {
gnssAssistance (1),
lbsMeasurement (2),
deviceBootstrap (3),
wirelessMAN (4),
oratMsg (5),
sms (65),
mihFrame (76),
relaySupport (87),
emergencyAlert (98)
--values 10 to 127 are reserved
--values 128 to 255 are for vendor-specific types
} (0..255),
--if transferType = 5, transferSubtype shall have one of the following values:
--1: GERAN (GPS, GPRS, EGPRS)
5
IEEE C802.16m-10/1452
--2: UTRAN
--3: E-UTRAN
--4: TD-SCDMA
--5: CDMA2000
--if transferType = 65, transferSubtype shall have one of the following values:
--1: SMS data
--2: SMS confirmation
--if transferType = 76, transferSubtype shall have one of the following values:
--1: service management
--2: event service
--3: command service
--4: information service
--otherwise, transferSubtype shall be absent
transferSubtype INTEGER (0..15) OPTIONAL,
payload OCTET STRING (SIZE(1..9999)) OPTIONAL, -- ??? upper bound?
...
}
-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
============================== End of Proposed Text ================================
References
[1] IEEE P802.16m/D9. DRAFT Amendment to IEEE Standard for Local and metropolitan area networks—
Part 16: Air Interface for Broadband Wireless Access Systems—Advanced Air Interface
[2] IEEE 802.16m-08/0034r2. IEEE 802.16m System Description Document, Sep 2009.
[3] IEEE 802.16m-07/002r9. IEEE 802.16m System Requirements Document, Sep 2009.
6