21-07-0322-00-0000 1

IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-07-0322-00-0000

Title: Marian Rudolf Comment Resolutions

Date Submitted: October 30, 2007

Presented at IEEE 802.21 session #23 in Atlanta

Authors or Source(s): Juan Carlos Zuniga

Abstract: This presentation captures suggested resolutions to comments received from Marian Rudolf.

21-07-0322-00-0000 2

IEEE 802.21 presentation release statements

• This document has been prepared to assist the IEEE 802.21 Working Group. 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.

• This is a contribution by the National Institute of Standards and Technology and is not subject to copyright in the US. The contributors do not have the authority to override the NIST policy in favor of the IEEE 802.21 policy.

• The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

Comment #475

Decision: Accept-Modified

Resolution:

• Modify the LINK_TYPE Definition as follows:

• 0: Reserved• 1: Wireless - GSM/GPRS• 2: Wireless - EDGE• 3-14: Reserved• 15: Ethernet• 18: Wireless - Other• 19: Wireless - IEEE 802.11• 22: Wireless - CDMA2000• 23: Wireless - W-CDMA FDD• 24: Wireless - cdma2000-HRPD• 27: Wireless - IEEE 802.16• 28: Wireless - IEEE 802.20• 29: Wireless - IEEE 802.22

3

Comment #476 (1/2)

Decision: Accept-Modified

Resolution:

• The LINK_PARAM_UMTS list does not represent the most important measurements required from the MN as specified in 3GPP 25.215

• Rename the list as “LINK_PARAM_WCDMA_FDD” and replace the Description list by the following elements:

• Bit 0: CPICH RSCP• Bit 1: PCCPCH RSCP• Bit 2: UTRA carrier RSSI• Bit 3: GSM carrier RSSI• Bit 4: CPICH Ec/No• Bit 5: Transport channel BLER• Bit 6: UE transmitted power• Bit 7-255: reserved

4

Comment #476 (2/2)

Decision: Accept-Modified (continued)

Resolution:

• Similarly, the LINK_PARAM_GSM list does not represent the most important measurements required from the MN as specified in 3GPP 25.008

• Merge the LINK_PARAM_GSM and LINK_PARAM_GPRS lists into a single one (e.g. LINK_PARAM_GSM_GPRS) and replace the list by the following elements:

• Bit 0: RxQual• Bit 1: RxLev• Bit 2: Mean BEP• Bit 3: StDev BEP• Bit 4-255: reserved

• Acronyms could require definition in section 45

Comment #477

Decision: Accept-Modified

Resolution:

• Increase the length to UNSIGNED_INT(2)

• Modify the Definition as follows:

• “Channel identifier as defined in the specific link technology (e.g. SDO)”

6

Comment #478

Decision: Accept-Modified

Resolution:

• “PDCP context active” and “Link layer connectivity” mean different things for different technologies. Modify the LINK_POWER_UP Definition as follows:

• “Power up the link and establish the required connections to allow L3 data connectivity (e.g. IP connectivity)”

7

Comment #479 (1/2)

Decision: Accept-Modified

Resolution:

• The table combines versions and features and does not provide the flexibility to indicate all existing combinations, as defined in 3GPP 25.306.

• Modify the Wireless UMTS Network Description as follows:

• (See next slide)

8

Comment #479 (2/2)• Network: Wireless – W-CDMA FDD • Link Type: 23 • Revision:

• (Revision)• Bit 0: Rel-99/Rel-4• Bit 1: Rel-5 • Bit 2: Rel-6 • Bit 3: Rel-7• Bit 4: Rel-8• Bit 5-19: (Reserved)

• (Features)• Bit 20: HSDPS• Bit 21: HSUPS• Bit 22: MIMO DL• Bit 23: MIMO• Bit 24: MBMS• Bit 25: DL HOM (64QAM)• Bit 26: UL HOM (16QAM)• Bit 27: CPC• Bit 28-63: (Reserved)

• Acronyms could require definition in section 4

9

Comment #482

Decision: Accept-Modified

Resolution:

• The specification should contain all the required text and references to group’s contributions should be avoided

• Remove references to contributions 21-05/350 and 21-05/335, and include the list of the 802.21-specific amendments suggested by the 802.11u and 802.16g amendments to specifications IEEE 802.11 and IEEE 802.16

10

Comment #507

Decision: Accept-Modified

Resolution:

• Modify the text as follows:5.7.2 Transport Considerations

The selection of the transport mechanism for MIH messages is dependent on the access technology that connects the MN to the network and the location of the MIH PoS.

There are two kinds of transport mechanisms: the first one is the lower layer transport (L2) and the second one is the higher layer transport (L3). Within the lower layer (L2) there may be alternate means (e.g., L2 management frames or L2 data frames) for transporting MIH messages. For example, wireless networks such as IEEE 802.11 and IEEE 802.16 have a management plane and support management frames which could be enhanced for carrying the MIH messages. Alternately, the wired Ethernet network does not have a management plane and may carry the MIH messages only in data frames.

— Transport of MIHF messages over IEEE 802.3 links is accomplished by encapsulating the MIH messages

in data frames.

— Transport of MIH messages over IEEE 802.11 and IEEE 802.16 links is recommended through extensions of media-specific management frames in state 1, and through management or data frames in state 3.

— No assumptions are made in this standard regarding the transport of MIH messages over 3GPP and 3GPP2 access links at L2.

If the MN cannot reach the MIH PoS via the lower layer (i.e. L2) transport mechanisms, then higher layer (i.e. L3) transport mechanisms shall be used.

11