mentor.ieee.org€¦ · web viewcommittee participants to reproduce this document for purposes of...

IEEE P802.21c/D02, November 2012

IEEE P802.21c™/D02Draft Standard for

Local and Metropolitan Area Networks- Part 21: Media Independent Handover ServicesAmendment 3: Optimized Single Radio Handovers

Sponsor

LAN/MAN Standards Committeeof theIEEE Computer Society

NOTE: This amendment is to be applied to the result of original 802.21-2008, 802.21a-2012, and 802.21b-2012.

Approved <XX MONTH 20XX>

IEEE-SA Standards Board

Copyright © 2012 by The Institute of Electrical and Electronics Engineers, Inc.Three Park AvenueNew York, New York 10016-5997, USA

All rights reserved.

This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards

Copyright © 2012 IEEE. All rights reserved.This is an unapproved IEEE Standards Draft, subject to change.

1

2

3

4

5

6

7

8

9

101112

1314

15

16

17

181920

21

222324


Committee participants to reproduce this document for purposes of international standardization consideration. Prior to adoption of this document, in whole or in part, by another standards development organization, permission must first be obtained from the IEEE Standards Association Department ([email protected]). Other entities seeking permission to reproduce this document, in whole or in part, must also obtain permission from the IEEE Standards Association Department.

IEEE Standards Association Department445 Hoes LanePiscataway, NJ 08854, USA


12345

678


Abstract: This standard specifies additional IEEE 802® media access independent mechanisms that optimize handovers between possibly heterogeneous IEEE 802 systems and between IEEE 802 systems and cellular systems, to enable improved handover performance for single-radio devices.

<Select this text and type or paste Abstract—contents of the Scope may be used>Keywords: <management, media independent handover, mobile node, mobility, seamless, point of attachment, point of service, single-radio, preregistration, preauthenticationSelect this text and type or paste keywords>

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus development process, approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.

The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 20XX by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published <XX MONTH 20XX>. Printed in the United States of America.

IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Incorporated.

PDF: ISBN 978-0-XXXX-XXXX-X STDXXXXXPrint: ISBN 978-0-XXXX-XXXX-X STDPDXXXXX

IEEE prohibits discrimination, harassment and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.


123456789

10

11

12131415161718

123456789

1011121314

http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html


Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document.

The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.”

The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation, or every ten years for stabilization. When a document is more than five years old and has not been reaffirmed, or more than ten years old and has not been stabilized, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.

In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon his or her independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to be, nor be relied upon as, a formal interpretation of the IEEE. At lectures, symposia, seminars, or educational courses, individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position, explanation, or interpretation of the IEEE.

Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Recommendations to change the status of a stabilized standard should include a rationale as to why a revision or withdrawal is required. Comments and recommendations on standards, and requests for interpretations should be addressed to:

Secretary, IEEE-SA Standards Board445 Hoes LanePiscataway, NJ 08854USA

Authorization to photocopy portions of any individual standard for internal or personal use is granted by The Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.


123

4567

89

101112131415

1617181920

2122232425262728293031

3233343536

37383940

4142434445


Notice to users

Laws and regulations

Users of these documents should consult all applicable laws and regulations. Compliance with the provisions of this standard does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so.

Copyrights

This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document.

Updating of IEEE documents

Users of IEEE standards should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE Standards Association web site at http://ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.

For more information about the IEEE Standards Association or the IEEE standards development process, visit the IEEE-SA web site at http://standards.ieee.org.

Errata

Errata, if any, for this and all other standards can be accessed at the following URL: http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically.

Patents

Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-SA website http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses.

ivCopyright © 2012 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.

1

2

34567

8

910111213

14

15161718192021

2223

24

252627

28

2930313233343536

http://standards.ieee.org/about/sasb/patcom/patents.html

http://standards.ieee.org/findstds/errata/index.html

http://standards.ieee.org/

http://ieeexplore.ieee.org/xpl/standards.jsp


Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association.

Participants

vCopyright © 2012 IEEE. All rights reserved.


1234567

8


At the time this draft Standard was submitted to the IEEE-SA Standards Board for approval, the IEEE802.21 Working Group had the following membership:

<Chair Name>, Chair<Vice-chair Name>, Vice Chair

Participant1Participant2Participant3



The following members of the <individual/entity> balloting committee voted on this Standard. Balloters may have voted for approval, disapproval, or abstention.

(to be supplied by IEEE)

Balloter1Balloter2Balloter3



When the IEEE-SA Standards Board approved this Standard on <XX MONTH 20XX>, it had the following membership:

(to be supplied by IEEE)<Name>, Chair

<Name>, Vice Chair<Name>, Past Chair<Name>, Secretary

SBMember1SBMember2SBMember3



*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons:

<Name>, DOE Representative<Name>, NRC Representative

<Name>IEEE Standards Program Manager, Document Development

<Name>IEEE Standards Program Manager, Technical Program Development

Introduction

This introduction is not part of IEEE P802.21c/D02, Draft Standard for

viCopyright © 2012 IEEE. All rights reserved.


12

345678

91011

121314

15161718192021222324

252627

282930

31323334

353637383940414243

444546

474849

50

515253

54555657585960616263646566

67

68


Local and Metropolitan Area Networks- Part 21: Media Independent Handover ServicesAmendment 3: OptimizedSingle Radio Handovers.

This standard extends the media access independent mechanisms that enable the optimization of handoversbetween possibly heterogeneous IEEE 802 systems and may facilitate handovers between IEEE 802 systems and cellular systems. The extensions enable mobile devices with single-radio designs to improve handover latencies and avoid packet loss.This document specifies optimizations to reduce the latency during single radio handovers between heterogeneous access networks.

Contents

viiCopyright © 2012 IEEE. All rights reserved.


1

23

456789

10

11


1. Overview ......................................................................................................................................................21.1 ................................................................................................................................................................21.2 ................................................................................................................................................................21.3 ................................................................................................................................................................21.4 Assumptions ..........................................................................................................................................2

2. Normative references ....................................................................................................................................2

3. Definitions ....................................................................................................................................................2

4. Abbreviations and acronyms ........................................................................................................................3

5. General architecture ......................................................................................................................................45.1 Introduction ...........................................................................................................................................4

5.1.1 ............................................................................................................................45.1.2 ............................................................................................................................45.1.3 ............................................................................................................................45.1.4 ............................................................................................................................45.1.5 ............................................................................................................................45.1.6 ............................................................................................................................45.1.7 ............................................................................................................................45.1.8 ............................................................................................................................45.1.9 ............................................................................................................................45.1.10 Media independent single radio handover ........................................................45.1.11 Securing Single-Radio messages using PoS .....................................................55.1.12 ...........................................................................................................................5

5.2 General design principles ......................................................................................................................55.2.1 ............................................................................................................................55.2.2 ............................................................................................................................55.2.3 Single Radio Handover MIHF (SR-MIHF) Design Principles ...........................5

5.3 MIHF service overview .........................................................................................................................65.3.1 ............................................................................................................................65.3.2 ............................................................................................................................65.3.3 ............................................................................................................................65.3.4 Media independent information service .............................................................6

5.4 Media independent handover reference framework ..............................................................................65.4.1 ............................................................................................................................65.4.2 ............................................................................................................................65.4.3 ............................................................................................................................65.4.4 Information Repository .......................................................................................65.4.5 General MIHF reference model and SAPs / Single Radio handover Control Function <was 11.1.2 -- fold into MIHF, perhaps SR-MIHF> ...................................65.4.6 SR-Gateway services at Home Network, Source Network, and Target Network .....................................................................................................................................7

5.5 MIHF reference models for link-layer technologies .............................................................................75.5.1 ............................................................................................................................7

6. MIH Services ................................................................................................................................................76.1 ................................................................................................................................................................7

viiiCopyright © 2012 IEEE. All rights reserved.


12345

6

7

8

9101112131415161718192021222324252627282930313233343536373839404142

4344


6.2 ................................................................................................................................................................76.3 ................................................................................................................................................................76.4 ................................................................................................................................................................76.5 Media independent information service ................................................................................................7

6.5.1 ............................................................................................................................76.5.2 ............................................................................................................................76.5.3 ............................................................................................................................76.5.4 Information Elements .........................................................................................7

7. Service Access Point (SAP) and primitives .................................................................................................87.1 ................................................................................................................................................................87.2 ................................................................................................................................................................87.3 MIH_LINK_SAP primitives .................................................................................................................8

7.3.1 ............................................................................................................................87.3.2 ............................................................................................................................87.3.3 ............................................................................................................................87.3.4 ............................................................................................................................87.3.5 ............................................................................................................................87.3.6 ............................................................................................................................87.3.7 ............................................................................................................................87.3.8 ............................................................................................................................87.3.9 ............................................................................................................................87.3.10 ..........................................................................................................................87.3.11 ..........................................................................................................................87.3.12 ..........................................................................................................................87.3.13 ..........................................................................................................................87.3.14 ..........................................................................................................................87.3.15 Link_IF_PreReg_Ready ...................................................................................8

7.4 MIH_SAP primitives .............................................................................................................................97.4.1 ............................................................................................................................97.4.2 ............................................................................................................................97.4.3 ............................................................................................................................97.4.4 ............................................................................................................................97.4.5 ............................................................................................................................97.4.6 ............................................................................................................................97.4.7 ............................................................................................................................97.4.8 ............................................................................................................................97.4.9 ............................................................................................................................97.4.10 ..........................................................................................................................97.4.11 ..........................................................................................................................97.4.12 ..........................................................................................................................97.4.13 ..........................................................................................................................97.4.14 ..........................................................................................................................97.4.15 ..........................................................................................................................97.4.16 ..........................................................................................................................97.4.17 ..........................................................................................................................97.4.18 ..........................................................................................................................97.4.19 ..........................................................................................................................9

ixCopyright © 2012 IEEE. All rights reserved.


12345678

91011121314151617181920212223242526272829303132333435363738394041424344454647


7.4.20 ..........................................................................................................................97.4.21 ..........................................................................................................................97.4.22 ..........................................................................................................................97.4.23 ..........................................................................................................................97.4.24 ..........................................................................................................................97.4.25 ..........................................................................................................................97.4.26 ..........................................................................................................................97.4.27 ..........................................................................................................................97.4.28 ..........................................................................................................................97.4.29 ..........................................................................................................................97.4.30 MIH_Prereg_Xfer .............................................................................................97.4.31 MIH_N2N_Prereg_Xfer .................................................................................137.4.32 MIH_IF_PreReg_Ready .................................................................................177.4.33 MIH_Prereg_Xfer ...........................................................................................197.4.34 MIH_N2N_Prereg_Xfer .................................................................................23

7.5 ..............................................................................................................................................................277.6 ..............................................................................................................................................................27

8. Media independent handover protocols ......................................................................................................278.1 ..............................................................................................................................................................278.2 ..............................................................................................................................................................278.3 ..............................................................................................................................................................278.4 MIH protocol frame format .................................................................................................................27

8.4.1 General frame format ........................................................................................278.5 ..............................................................................................................................................................278.6 MIH protocol messages .......................................................................................................................27

8.6.1 ..........................................................................................................................278.6.2 ..........................................................................................................................278.6.3 MIH messages for command service ................................................................278.6.4 MIH messages for gateway service ..................................................................31

9. MIH protocol protection .............................................................................................................................329.1 ..............................................................................................................................................................329.2 Key establishment through an MIH service access authentication .....................................................32

9.2.1 ..........................................................................................................................329.2.2 Key derivation and key hierarchy .....................................................................32

10. Proactive Authentication ..........................................................................................................................3310.1 Media specific proactive authentication ............................................................................................3310.2 ...........................................................................................................................................................3510.3 Establishing Security Association roaming partners for MIH ...........................................................35

10.3.1 Key distribution by OPoS ...............................................................................3610.3.2 TPoS selection by OPoS .................................................................................38

11. Single Radio Handover .............................................................................................................................3811.1 Introduction (keep in reduced version) ..............................................................................................3811.2 Major single radio handover processes .............................................................................................38

12. Gateway Service .......................................................................................................................................4012.1 Introduction .......................................................................................................................................4012.2 Communication between the MN and the target PoA < Was 11.1.4> ..............................................41

xCopyright © 2012 IEEE. All rights reserved.


123456789

1011121314151617

181920212223242526272829

3031323334

353637383940

414243

444546


12.3 L2 Message Transfer (SID=5, AID=1) .............................................................................................4312.4 Interworking Protocol Delivery (SID=5, AID>1) .............................................................................43

12.4.1 Examples of Interworking Protocol Delivery: ANQP Delivery .....................44

Annex A ..........................................................................................................................................................46

Bibliography ...................................................................................................................................................46

Annex B ..........................................................................................................................................................46

Annex C ..........................................................................................................................................................46

Annex D ..........................................................................................................................................................46

Annex E ..........................................................................................................................................................46

Annex F ..........................................................................................................................................................46F.1 .............................................................................................................................................................47F.2 .............................................................................................................................................................47F.3 Derived data types ...............................................................................................................................47

F.3.1 ..........................................................................................................................47F.3.2 ..........................................................................................................................47F.3.3 ..........................................................................................................................47F.3.4 Data types for link identification and manipulation .........................................47F.3.5 ..........................................................................................................................48F.3.6 ..........................................................................................................................48F.3.7 ..........................................................................................................................48F.3.8 Data types for information elements ................................................................48F.3.9 ...........................................................................................................................48F.3.10 .........................................................................................................................48F.3.11 .........................................................................................................................48F.3.12 .........................................................................................................................48F.3.13 ........................................................................................................................48F.3.14 ........................................................................................................................48F.3.15 ........................................................................................................................48F.3.16 Data type for security .....................................................................................48

Annex G ..........................................................................................................................................................49

Annex H ..........................................................................................................................................................49

Annex I ...........................................................................................................................................................49

Annex J ...........................................................................................................................................................49

Annex K ..........................................................................................................................................................49

Annex L ..........................................................................................................................................................49

Annex M .........................................................................................................................................................50

Annex N ..........................................................................................................................................................50

xiCopyright © 2012 IEEE. All rights reserved.


123

4

5

6

7

8

9

1011121314151617181920212223242526272829

30

31

32

33

34

35

36

37


N.1 .............................................................................................................................................................50N.2 .............................................................................................................................................................50N.3 .............................................................................................................................................................50N.4 .............................................................................................................................................................50N.5 .............................................................................................................................................................50N.6 Use of MIH_Prereg_Xfer and MIH SA_Estab messages for the exchange of L2 frames, including Optimized SA Establishment .....................................................................................................................50

Annex O ..........................................................................................................................................................55

Annex P MN’s Network Access Identifier Format ........................................................................................55

Annex Q Network discovery for single radio handover .................................................................................56Q.1 Network discovery: listening to the target link ...................................................................................56Q.2 Network discovery: using location information .................................................................................56Q.3 Network discovery: using user schedule information ........................................................................57

Annex R Examples of SRHO .........................................................................................................................58R.1 WLAN to WiMAX single radio handover ..........................................................................................85

R.1.1 Transport of WiMAX L2 control frames between MN and the WiMAX ASN ...................................................................................................................................85R.1.2 WLAN to WiMAX Single Radio Handover processes ...................................85

R.2 3GPP to WiMAX single radio handover ............................................................................................85R.2.1 Transport of WiMAX L2 control frames between MN and the WiMAX ASN ...................................................................................................................................85R.2.2 3GPP to WiMAX Single Radio Handover processes ......................................85

R.3 WiMAX to WLAN single radio handover ..........................................................................................85R.3.1 Transport of WLAN L2 control frames between MN and the WLAN AN .....85R.3.2 WiMAX to WLAN Single Radio Handover processes ...................................85

R.4 WiMAX to 3GPP single radio handover ............................................................................................85R.4.1 Transport of 3GPP L2 control frames between MN and the 3GPP network ...85R.4.2 WiMAX to 3GPP Single Radio Handover processes ......................................85

R.5 WLAN to 3GPP single radio handover ..............................................................................................85R.5.1 Transport of 3GPP L2 control frames between MN and the 3GPP network ...85R.5.2 Non-trusted WLAN AN to 3GPP Single Radio Handover processes .............85

Annex S Handover Decision ..........................................................................................................................85S.1 Weak SINR of the source link .............................................................................................................86S.2 QoS and/or cost check .........................................................................................................................86S.3 Power consumption comparison of the link interfaces .......................................................................87

xiiCopyright © 2012 IEEE. All rights reserved.


1234567

8

9

10111213

141516171819202122232425262728293031

3233343536


Draft Standard for

Local and Metropolitan Area Networks- Part 21: Media Independent Handover ServicesAmendment 3: Optimized Single Radio Handovers

IMPORTANT NOTICE: This standard is not intended to ensure safety, security, health, or environmental protection. Implementers of the standard are responsible for determining appropriate safety, security, environmental, and health practices or regulatory requirements.

This IEEE document is made available for use subject to important notices and legal disclaimers. These notices and disclaimers appear in all publications containing this document and may be found under the heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.

1

1

2

3

4

5

6

7

89

10

1112131415

16

http://standards.ieee.org/IPR/disclaimers.html


NOTE—The editing instructions contained in this <amendment/corrigendum> define how to merge the material contained therein into the existing base standard and its amendments to form the comprehensive standard.

The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace. Change is used to make corrections in existing text or tables. The editing instruction specifies the location of the change and describes what is being changed by using strikethrough (to remove old material) and underscore (to add new material). Delete removes existing material. Insert adds new material without disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is used to make changes in figures or equations by removing the existing figure or equation and replacing it with a new one. Editing instructions, change markings, and this NOTE will not be carried over into future editions because the changes will be incorporated into the base standard.

1. Overview

1.1 Assumptions

Insert at end of Clause 1.4

The following assumptions apply during the single radio handover:

1. While the source radio is transmitting, the target radio cannot transmit.

The mobile device can transmit on only one radio at a time. Prior to handover completion, the source radio link is used to support data transfer so that the priority to transmit is given to the source radio.

2. It shall be possible that while the source radio is receiving, the target radio shall not transmit at a frequency close to the frequency of the source radio receiver.If sufficiently sharp signal filtering is lacking, then while the source radio is receiving, the target radio shall not transmit at a frequency close to the frequency of the source radio receiver.

3. It shall be possible that while the source radio is receiving, the target radio shall not receive at a frequency close to the frequency of the source radio receiver.If sufficiently sharp signal filtering is lacking, then while the source radio is transmitting, the target radio shall not receive at a frequency close to the frequency of the source radio transmitter.

4. The mobile node (MN) and the target network may communicate with each other via the source network using the source link.

It is possible that the source point of attachment and the target point of attachment may: (a) belong to the same access network, (b) belong to different access networks connecting to the same backhaul network, or (c) belong to different access networks connecting to different backhaul networks. In (a) and (b), the capability to communicate between the source radio and the target network usually does not utilize internetwork interfaces. In (c), the two networks may require internetwork addresses in order to be able to communicate with each other.

2. Normative references

Insert reference in appropriate order

IETF RFC 5677 (2009-12) IEEE 802.21 Mobility Services Framework Design (MSFD)

2

12

3456789

10

11

15

16

17

18

192021

22232425

26272829

3031

323334353637

38

39

40

41


IEEE P802/D1.4, (2012-06), “IEEE Draft Standard for Local and metropolitan Area Networks: Overview and Architecture.

3GPP, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access,” TS23.401.

3GPP, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses,” TS23.402

WiMAX Forum Network Architecture: Stage 3 Detailed Protocols and Procedures T33-001-R015

WiMAX Forum, “Single radio interworking,” WMF-T37-011-R016v01.

WiMAX Forum, “WiFi-WiMAX Interworking,” WMF-T37-010-R016v01.

3GPP2, “WiMAX-HRPD Interworking: Core network aspects,” X.S0058.

[3.] Definitions

Insert these definitions in appropriate order

OriginatServing network PoS: Tthe Point of Service in the domain network of the Mobile Node’s current Point of Attachment

Preregistration: preparatory handover signaling (including security establishment) which is accomplished before the handover actually occurs.

Proxy Gateway (GW): A gateway to bridge the mobility signaling between a mobile node (MN) and a target network point of attachment via the source network. To the MN, the Proxy GW acts like a virtual point of attachment (PoA) to the target network. It enables such functions as pre-registrationpreregistration and proactive authentication of the MN.

Single radio handover (SRHO): A handover among (possibly possibly heterogeneous) radio access technologies during which a mobile node can transmit on only one radio at a time.

Single Radio handover MIHFControl Function (SRCFSR-MIHF): A media independent control function to enable MN and Target PoA to exchange the network entry link-layer PDUs without depending on the existence of the target radio’s physical channel. It uses the available radio’s IP transport to deliver the deactivated target radio’s network entry L2 PDUs. It interfaces with the transport layer (e.g., UDP) through the Media Independent Control Handover Service Access Point (MICSAPMIH_SAP) so that it may exchange SRC frames with remote SRCFSR-MIHF entities through IP transport. The exchanged SRC frames are processed by the SRCFSR-MIHF which has the assigned transport layer protocol’s port number [RFC 5677]. SRCFSR-MIHF also interfaces with the link-layer (L2) through the Media Iindependent Control Handover Link-layer Service Access Point (MICLSAPMIH_LINK_SAP) so that it may provide transport of L2 frames of a deactivated target radio to and from a remote SRCFSR-MIHF entity.

Single radio handover controlMIHF frame: A packet which contains the target radio’s network entry link-layer PDUs in its payload.

SRHO-capable device: A network node that implements one or more commands from this specification document. For instance, a mobile node MN is SRHO-capable if it implements at least MIH_Prereg_Xfer commands.

3

12

345

67

8

9

10

11

12

13

1415

1617

18192021

2223

24252627282930313233

3435

363738


Target network PoS: Aa Point of Service in the target domainnetwork of the target Point of Attachment, to which a Mobile Node will be attached after a handover has been completed

3.[4.] Abbreviations and Acronymns

Note to editor: iInsert these definitions in appropriate order

ANDSF Access Network network Discovery discovery Selection selection Functionsfunctions

MIHCF Media media Independent independent Control controlhandover Functionfunction

MICSAPMIH_SAP Media media Independent independent Control control handover Service service Access access Pointpoint

MICLSAPMIH_LINK_SAP Media media independent Control controlhandover Linklink-layer Service service Access access Pointpoint

PoS Point point of Serviceservice

SRCFSR-MIHF Single Radio radio handover Control- media independent handover Functionfunction

SRC single radio handover control

SRHO Single single Radio radio Handoverhandover

OSPoS Serving servingoriginating PoS

TPoS Target target PoS

4.[5.] General architecture

4.1[5.1] Introduction

4.1.10[5.1.9] Media independent single radio handover

Insert new sub-clauses 5.1.10 and 5.1.11

The concept of media independence applies to single radio handover just as it does to the dual-radio handover. A media independent handover may be accomplished in a media independent way, but the signaling messages for a single radio handover may differ from that for a dual-radio handover.However, the MIHF is extended with the definitions of MICSAP and MICLSAP defined in the draft Std IEEE P802/D1.4 on architecture and are described in Clause 11.5.4 . With these extensions, the MIHF can be now described as a parallel control plane and is called media independent control function (MICF) in the draft Std IEEE P802/D1.4.

Security is indispensable to mobility management (see section 10.2), but it has been typically quite time consuming because of reliance on distant authentication agents. Improving the security model and reducing authentication delay enables crucial improvements in handover performance. For the single radio handover design using media independent messages, the same transport possibilities as MIHF may apply. For single-radio performance improvement, it is important to accomplish as much of the handover signaling (including security establishment) needs to be

4

12

3

4

5

6

78

910

11

12

13

14

15

16

17

18

37

38

39404142434445

464748495051


accomplished before the handover actually occurs; this preparatory signaling is called preregistration. The exact signaling steps included in the pre-registrationpreregistration process naturally depend on the requirements of the target network, and can be quite independent of the nature of the network (as above, the "source network") providing the current point of attachment for the MN. As a general rule, preregistration typically involves the following steps:

pre-authentication -- that is, authenticating the MN before it arrives in the target network, address allocation -- one or more IP addresses to be used by the MN after it arrives in the

target network. data path setup -- establishing tunnels and forwarding entries for the MN in the target

network, and context establishment -- building all necessary state information such as QoS parameters

and access permissions within target core network entities.

Each of these operations can be time-consuming, and if they had to be carried out after the MN had returned to the target network radio access, smooth handover might be impossible because of the dead time before packets could start flowing again (break-before-make). Moreover, each of the operations must be carried out securely to prevent hijacking attempts or mismanagement of target network resources. As long as handovers occur only between access points within the same operator network, it is often possible to guarantee that signaling packets are never exposed to attack. On the other hand, for access networks belonging to different operators, the data path between neighboring access points of originating and target access networks are more likely to traverse the Internet, potentially exposing preregistration signaling to attack. See section 5.1.11.

4.1.11 Securing Single-Radio messages using PoS

Enabling movement between the network domains of roaming partners for single-radio smartphones and Internet enabled wireless devices can be facilitated by enabling preregistration via the Point of Service (PoS) and making use of certain functions as developed in the WiMAX Forum, 3GPP2, and 3GPP <insert xrefs>. Using the PoS along with some signaling to transmit security information between roaming partners enables a low-latency, optimized handover for even the single-radio devices. Since communication between the source and target networks may traverse the Internet, these communications must be secured; but this can be quite time consuming because of reliance on distant authentication agents A method is defined to establish a secure communication channel between source and target networks as part of handover preregistration procedures (see section <insert xref here>). Improving the security model and reducing authentication delay enables crucial improvements in handover performance.

4.2 General design principles

4.2.3[5.1.11] Single Radio Handover MIHF (SR-MIHF) Design PrinciplesThe following requirements facilitate single radio handover between different radio access technology networks.

Functional Requirements for SR-MIHF:

tunneling mechanism to deliver the pre-registrationpreregistration messages

control for pre-registered states and delivery for pre-registered contexts.

5

12345

6789

101112

1314151617181920212223

24

2526272829303132333435

36

414243

44

45

46


capabilities exchange between mobile station and SR-MIHF at the network.

o Supported radio access technology (RAT) types (3GPP, WiMAX, WiFi, 3GPP2, etc.)

o Supported target network capabilities

o Any required layer-2 parameters

4.3 MIHF service overview

4.3.4[5.1.14] Media independent information service

4.4 Media independent handover reference framework

[5.1.17] Information Repository The network service information and the location information, such as the availability of candidate target network etc., are needed to make handover decisions. For example, the Information Repository may be implemented as part of a media independent information server (MIIS). Alternatively, as another example, IR or may be implemented asin conjunction with the Access Network Discovery and Selection Function (ANDSF) defined in 3GPP standard [3GPP TS23.402], using methods outside the scope of this document.

The type of information needed in the mobility management protocol depends on the mobility management protocol being used. For example, when mobile IP is used for the inter-network management protocol, the location of the MN in the network is the care-of-address (CoA) and the identity of the MN is the home address in the home network of the MN. The location management information for mobile IP may then be the binding of the home address to the care-of-address. Furthermore, in accordance with existing procedures for subscriber management, mobility management may also require access to policy information controlling the allowable behavior of the mobile devices.

The distributed database of the Information Repository allows flexibility for different owners to manage their data separately. An example is for each network to host the master copy of the data that is most convenient to be managed by that network. The servers in the different networks constitute a distributed database of the Information Repository, organized so that each server knows which data belongs to which component of the Repository.

[5.1.18] General MIHF reference model and SAPs / Single Radio handover Control Function To prepare for handover, the MN’s target radio exchanges link-layer network entry PDUs with the target PoA at the target network. These network entry PDUs can be the same PDUs that would be exchanged if the target link were active. There is no guarantee that the target link is available during a single radio handover. A single radio handover control function (SR-MIHF) is used here to enable the MN and the target PoA to exchange the network entry link-layer PDUs without depending on the existence of the target radio’s physical channel but with the help of the active source radio.

In figure 4 (above in this section 5.5.2) the Single Radio MIHF (SR-MIHF) in a multiple interface node is implemented using the media independent control function (MIHF) in the control plane.

The SR-MIHF use MIH-SAP for communication via TCP/IP or UDP/IP. The SR-MIHF similarly interfaces with the link-layer (L2) MIH_LINK_SAP as before. During a single radio hadover, an L2 frame of a deactivated link is encapsulated in an MIH message to constitute a SRC frame, which is then exchanged via an active link between the SR-MIHFs of a local and a remote node using MIH protocol over L3 transport (TCP or UDP).

6

1

2

3

4

5

12

13

202122232425

26272829303132

3334353637

38394041424344

4546

4748495051


4.4.4[5.1.19] SR-Gateway services at Home Network, Source Network, and Target Network

Source network

GW

A distributed database of Information Repositories

Target network

GW Home network

GW

MN MNFigure 11.2 An architecture of distributed mobility management.

This distributed mobility management architecture also works for single radio management. Because the logical functions for distributed mobility management must already reside in some physical network elements, new physical network elements are not necessarily needed with this single radio handover reference model.

4.5 MIHF reference models for link-layer technologies

1.3.18

4.5.1

4.5.2

4.5.3

4.5.4

4.5.5

4.5.6

4.5.7

4.5.8 Single radio handover reference model and signaling flowInsert new sub-clause 5.5.8

The reference model for single radio handover is shown in Figure 10a.

7

1

23

4567

8

9

10

11

12

13

14

15

16

17

1819

20

21


General MIHF reference model and SAPs

Originating network Target network

MN

TPoS/Proxy

Target PoAOriginating PoA

OPoS/Proxy

A distributed database of Information Repositories, e.g., MIIS

Figure 10a Single radio handover reference model.

The functions in originating network are: OPoS and the proxy function. The functions in target network are: TPoS and the proxy function.

The proxy functions enable signaling between the MN and the target PoA: MN signals with target PoA via OPoS/proxy function, which in turn signals with target PoA via TPoS/proxy function. Target PoA signals with MN via TPoS proxy function, which in turn signals with MN via OPoS proxy function.

The signal flow for single radio handover is shown in Figure 10b and are described in the following.

8

1

2

3

45

678

9

10


InformationRepository

HO request

Query for candidate target networks

Candidate target networks

Send HO request to TPoS

(Choose target networkwith TPoS address)

OPoS/Proxy TPoS/Proxy

(Choose TPoA with addressIs TPoA MIH-capable?If yes, relay the HO requestIf no, convert hdr to handshake)

HO request signaling

HO accept/fail

(Proactive authenticationPreregistration)

Figure 10b Signaling flow for Single radio handover via proxy functions

a) MN sends a message to the OPoS with a payload of a target network L2 handover frame.

b) Upon receiving this message from MN,

1) OPoS proxy function helps to discover a suitable target network if not already known.

2) OPoS proxy function signals with the MN via the TPoS proxy function, that is, OPoS proxy function sends the message to TPoS.

c) Upon receiving this message from MN (either directly or via the OPoS, if the message is received directly from the MN, the via through the OPoS is bypassed), TPoS proxy function helps to discover a suitable PoA if not already known.

1) TPoS proxy function signals with this target PoA using 21c message if the target PoA supports 21c.

2) TPoS proxy function signals with this target PoA using other message if the target PoA does not support 21c. It will reply to MN via the OPoS proxy function whether the L2 handover frame is successful with an indication that it signals with the target PoA using other message(s).

9

1

2

3

4

5

67

8

91011

1213

141516

17

18


5. MIH Services

1.4[1.2]

1.5[1.3]

1.6[1.4]

1.7[1.5]

5.1[5.2]

5.2[5.3]

5.3[5.4]

5.4[5.5]

5.5[5.6] Media independent information service

1.7.1[1.5.1]

1.7.2

1.7.3

5.5.1

5.5.2[5.6.1]

5.5.3[5.6.2]

5.5.4[5.6.3] Information ElementsInsert ordered list element as follows, and relabel current item (c) as item (d):

c. The Information Server provides the Point of Service (PoS) information, the Mobile Node (MN) information and the capability for supporting SRHO for each of the available access networks. The PoS information includes PoS addressing information and tunnel management protocol information. The MN information includes location information of the MN.

Insert following description before Table 10

The Information Server provides the Point of Service (PoS) information, the Mobile Node (MN) information and the capability for supporting SRHO for each of the available access networks. The PoS information includes PoS addressing information and tunnel management protocol information. The MN information includes location information of the MN.

Table 10 represents the list of Information Elements and their semantics defined for SRHO. Each Information Element has an abstract data type (see Annex A Annex A for detailed definitions).

10

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

1718

19202122

23

24252627

2829


Insert information elements in Table 10 as follows:

Table 1Table 2Table 3Table 4Table 5Table 6Table 7Table 8Table 9

Table 10 — Information ElementsName of information element Description Data type

802.21 Point of Service information elementsIE_PoS_IP_ADDR IP address of PoS IP_ADDRIE_PoS_TUNN_MGMT_PRTO Type of tunnel management protocol supported. IP_TUNN_MGMTIE_PoS_FQDN FQDN of PoS. FQDN

[5.6.4] IE ContainersIn the binary representation method, the Information Element Containers are defined. The containers are used in the type-length-value (TLV) based query method. A new Information Element, namely the IE_CONTAINER_PoS, is defined for SRHO.

IE_CONTAINER_PoS – contains all the information depicting a PoS as shown in Table 11.

Table 11 will use a new Table Number after Table 10

[Table 11] —IE_CONTAINER_PoS definitionInformation element ID = (see Table B.1) Length = variable IE_PoS_IP_ADDR IE_PoS_TUNN_MGMT_PRTO IE_PoS_FQDN

11

1

2

3

4

5

6

7

8

9

10

11

12

13141516

17

18

19

20


6. Service Access Point (SAP) and primitives

1.8[1.6]

1.9[1.7]

6.1

6.2

6.3 MIH_LINK_SAP primitives

1.9.1[1.7.1]

1.9.2[1.7.2]

1.9.3[1.7.3]

1.9.4[1.7.4]

1.9.5[1.7.5]

1.9.6[1.7.6]

1.9.7[1.7.7]

1.9.8[1.7.8]

1.9.9[1.7.9]

1.9.10[1.7.10]

1.9.11[1.7.11]

1.9.12[1.7.12]

1.9.13[1.7.13]

1.9.14[1.7.14]

Insert following clause 7.3.15

12

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21


6.3.1

6.3.2

6.3.3

6.3.4

6.3.5

6.3.6

6.3.7

6.3.8

6.3.9

6.3.10

6.3.11

6.3.12

6.3.13

6.3.14

6.3.15 Link_IF_PreReg_Ready

6.3.15.1 Link_IF_PreReg_Ready.request

6.3.15.1.1 FunctionThis primitive is used by the SRCF MIHF to request pre-registrationpreregistration on a target link interface of MN.

6.3.15.1.2 Semantics of service primitiveLink_IF_PreReg_Ready.request (

ExecutionDelay

)

Parameters:

Name Data type DescriptionExecutionDelay UNSIGNED_INT(2) Time (in ms) to elapse before the action needs to be taken. A value

of 0 indicates that the action is taken immediately. Time elapsed is calculated from the instance the request arrives until the time when the execution of the action is carried out.

6.3.15.1.3 When generatedThis primitive is generated by the SRCFSR-MIHF to prepare pre-registrationpreregistration of the target link.

13

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

171819

2021

22

23

24

25

262728


6.3.15.1.4 Effect on receiptUpon receipt of this primitive, the target link interface prepares pre-registrationpreregistration at the time specified by the ExecutionDelay parameter. The L2 messages for pre-registrationpreregistration are transmitted to the SRCFSR-MIHF on behalf of PHY of the target link.

6.3.15.2 Link_IF_PreReg_Ready.confirm

6.3.15.2.1 FunctionThis primitive is used by link-layer technologies to provide an indication of the result of the pre-registrationpreregistration preparation on the target link layer.

6.3.15.2.2 Semantics of service primitiveLink_IF_PreReg_Ready.confirm (

Status

)

Parameters:

Name Data type DescriptionStatus STATUS Status of the operation. Code 3 (Authorization Failure) is not

applicable.Status of the operation.

6.3.15.2.3 When generatedThis primitive is generated in response to Link_IF_PreReg_Ready.request operation.

6.3.15.2.4 Effect on receiptUpon receipt of this primitive, the SRCF can know success of pre-registration preparation on the target link.Upon reception of this primitive, the SR-MIHF can know the status of the pre-registrationpreregistration on the target link.

6.4 MIH_SAP primitives

Insert following clauses 7.4.30 – 7.4.33

14

1234

5

678

910

11

12

13

14

1516

17181920

21

22

23

80


6.4.1

6.4.2

6.4.3

6.4.4

6.4.5

6.4.6

6.4.7

6.4.8

6.4.9

6.4.10

6.4.11

6.4.12

6.4.13

6.4.14

6.4.15

6.4.16

6.4.17

6.4.18

6.4.19

6.4.20

6.4.21

6.4.22

6.4.23

6.4.24

6.4.25

6.4.26

6.4.27

6.4.28

15

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28


6.4.29

[6.4.30] MIH_LL_TransferMIH_Prereg_Xfer

[6.4.30.1] MIH_LL_TransferMIH_Prereg_Xfer.request

6.4.29.1.1[6.4.30.1.1] FunctionThis primitive is used to transport parameters and link layer frames between the MN and a MIHF at the MN’s local PoS (i.e., OPoS) for the purpose of establishing a secure tunnel between the MN and the TPoS in an appropriate target networkcarries link-layer frames between the MN and a MIHF at the MN’s local PoS.

6.4.29.1.2[6.4.30.1.2] Semantics of service primitive MIH_LL_TransferMIH_Prereg_Xfer.request (

DestinationIdentifier,

TargetLinkIdentifier,

TargetLinkInfoList,

LLInformation,

TPoSIdentifier,

CandidateLinkList,

Nonce

)

Parameters:

Name Data type DescriptionDestinationIdentifier MIHF_ID Identifies a remote MIHF as the destination of this

request.TargetLinkIdentifier LINK_TUPLE_ID (Optional: included if the target link is known)

Identifies the remote PoA as the corresponding peer of the L2 exchange.0

TargetLinkInfoList LIST (LINK_PoA_LIST) (Optional) Information that the MN can provide to the OPoS for selection of the proper TPoS. This can include values and IEs from tables F.10, F.11, F.14, and G.1.

LLInformation LL_FRAMES (Optional: included if the target link is known) Carries link layer frames.

TPoSIdentifier TPoSMIHF_ID (Optional) This identifies the target PoS (TPoS) that will be the destination of the link-layer frames.

CandidateLinkList LIST (LINK_PoA_LIST) (Optional) A list of PoAs, identifying candidate networks to which handover needs to be initiated. The list is sorted from most preferred first to least preferred last. This attribute shall not be included if the target link is known.

Nonce NONCE (Optional) Nonce (Nonce TLV)

0 Note that LINK_TUPLE_ID includes the LINK_ID of both sides of the link, the MN and the PoA.

16

1

2

3

45678

910

11

12

13

14

15

16

17

18

19

20

1


6.4.29.1.3[6.4.30.1.3] When generatedThis primitive is generated by an MIH user to send a link-layer frame for pre-registrationpreregistration to the target PoSstart an authentication and association process based on link-layer frames. The MN can send this primitive to instruct its OPoS to generate a Security Association with an appropriate TPoS, for instance so that the MN and the TPoS are able to carry out additional preregistration commands before handover to TPoA. The MN can include whatever information it has available about any suitable TPoA for use by OPoS to identify the proper TPoS. If the MN has sufficient information about TPoA to include layer 2 frames, those frames can also be supplied for secure delivery to TPoA. In this way, the number of round trips for preregistration may be minimized.

6.4.29.1.4[6.4.30.1.4] Effect on receiptAfter If the TargetLinkIdentifier is not included, the OPoS shall use the TargetLinkInfoList (if included) to identify the appropriate TPoS that can initiate pre-registration activities with an appropriate TPoA. In the absence of other information, the OPoS can use available link-type information and location information for the MN to identify an appropriate TPoS. Some location information about the MN may be available by associating geographical coordinates with the MN’s current Point of Attachment (i.e., SPoA). rAfter reception of this primitive, OPoS the MIHF must generate an MIH_LL_TransferMIH_Prereg_Xfer request message towards the MIHF of the serving PoSoriginating PoS, which must relay the link-layer frames transported in this message to the target PoS.

[6.4.30.2] MIH_LL_TransferMIH_Prereg_Xfer.indication

6.4.29.1.5[6.4.30.2.1] FunctionThis primitive is used by the remote local MIHF (i.e., OPoS) to notify the corresponding MIH user about the reception of an MIH_LL_TransferMIH_Prereg_Xfer request message.

6.4.29.1.6[6.4.30.2.2] Semantics of service primitiveMIH_LL_TransferMIH_Prereg_Xfer.indication (

SourceIdentifier,


LLInformation,

TPoSIdentifier,

TargetLinkInfoList,

CandidateLinkList

)

Parameters:

17

123456789

10

111213141516171819

20

212223

2425

26

27

28

29

30

31

32

33

34

35


Name Data type DescriptionSourceIdentifier MIHF_ID Identifies the invoker, typically f a remote MIHFMN in the

same network as OPoS.TargetLinkIdentifier LINK_TUPLE_ID (Optional)This identifies the remote PoA that is the

corresponding peer of the L2 exchange0. This attribute shall be included if the target link is known.

LLInformation LL_FRAMES (Optional) This carries link layer frames. This attribute shall may be included if the target link is known.

TPoSIdentifier TPoSMIHF_ID (Optional) This identifies the target PoSTargetLinkInfoList LIST (LINK_PoA_LIST) (Optional) Information that the MN can provide to the OPoS

for selection of the proper TPoS. This can include values and IEs from tables F.10, F.11, F.14, and G.1.

CandidateLinkList LIST(LINK_PoA_LIST) (Optional) A list of PoAs, identifying candidate networks to which handover needs to be initiated. The list is sorted from most preferred first to least preferred last. This attribute shall not be included if the target link is known.

6.4.29.1.7[6.4.30.2.3] When generatedThis primitive is generated by a remote MIHF after receiving an MIH_LL_TransferMIH_Prereg_Xfer request message.

6.4.29.1.8[6.4.30.2.4] Effect on receiptIf TPoSIdentifier is not provided, the MIH user application on the OPoS uses the information provided by the MN to identify an appropriate target PoS (TPos). If the TPoS is hosted remotely (e.g., in a separate target network), the MIH user application on the OPoS must generate an MIH_N2N_Prereg_Xfer.request primitive for TPoS. Otherwise, or upon receipt of corresponding MIH_N2N_Prereg_Xfer.response, tThe MIH user must generate an MIH_LL_TransferMIH_Prereg_Xfer.response primitive and transmit that response to the MIHF specified by the SourceIdentifieror invoke an MIH_N2N_LL_Transfer.request primitive to send an MIH_N2N_LL_Transfer request message to the MIHF on the target PoS before invoking the MIH_LL_Transfer.response primitive.

[6.4.30.3] MIH_LL_TransferMIH_Prereg_Xfer.response

6.4.29.1.9[6.4.30.3.1] FunctionThis primitive is used by an MIH user to provide the link-layer frames to the local MIHF.

6.4.29.1.10[6.4.30.3.2] Semantics of service primitiveMIHMIH_Prereg_Xfer.response (



LLInformation,

MNnetworkaccessid,

TPoSIdentifier,

MIRK,

MNmsrk,

Nonce,

SALifeTime,


18

1

234

56789

10111213

14

1516

1718

19

20

21

22

23

24

25

26

27

1


Status _LL_Transfer.response (



LLInformation,

MNnetworkaccessid,

TPoSIdentifier,

Status )

Parameters:

Name Data type Description

DestinationIdentifier MIHF_ID This identifies a remote MIHF that will be the destination of this response.

TargetLinkIdentifier LINK_TUPLE_IDThis identifies the remote PoA that is the corresponding peer of the L2 exchange. 0

LLInformation LL_FRAMES(Optional) Carries link layer frames; included if and only if the corresponding MIH_LL_TransferMIH_Prereg_Xfer.indication contained LLInformation.

MNnetworkaccessid NAIMIHF_ID (Optional) Carries the MN’s Network Access Identifier in the case optimized pull key distribution is used.

TPoSIdentifier TPoSMIHF_ID (Optional) This identifies the target PoS

MIRK ENCR_BLOCK (optional) A shared key, Ktpos, encrypted to be recoverable by MNMNmsrk ENCR_BLOCK (optional) Media Specific root key (for use with EAP methods)Nonce NONCE_VALUE (optional) Nonce SALifeTime LifeTime (optional) Lifetime of the Security Association

Status STATUS

Status of the preregistration transfer with TPoS0. Success1. TPoS is identical to OPoS, use Kopos2. Failure3. Code 3 (Authorization Failure) is not applicable.Status of the

operation.

6.4.29.1.11[6.4.30.3.3] When generatedThis primitive is generated after receiving an MIH_LL_TransferMIH_Prereg_Xfer.indication primitive and possibly after receiving an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.confirm primitive from the local MIHF. This primitive is generated after receiving an MIH_N2N_Prereg_Xfer.confirm primitive. After the OPoS has received the confirmation that the TPoS has accepted the Security Association, the OPoS MIHF issues this primitive so that the MN can complete the establishment of the secure tunnel. For this purpose, the OPoS has to supply the MIRK, MNmsrk, Nonce, and SALifeTime to the MN according to the formula specified in section 16.1

6.4.29.1.12[6.4.30.3.4] Effect on receiptThe local MIHF may generate an MIH_LL_TransferMIH_Prereg_Xfer response message in order to provide the required information until the authentication or association process is finished.


19

1

2

3

4

5

6

7

8

9

1011121314151617

181920

1


[6.4.30.4] MIH_LL_TransferMIH_Prereg_Xfer.confirm

6.4.29.1.13[6.4.30.4.1] FunctionThis primitive is used to notify the corresponding MIH user about the reception of an MIH_LL_TransferMIH_Prereg_Xfer response message.

6.4.29.1.14[6.4.30.4.2] Semantics of service primitiveMIH_LL_TransferMIH_Prereg_Xfer.confirm (

SourceIdentifier,


LLInformation,

MNnetworkaccessid,

TPoSIdentifier,

MIRK,

MNmsrk,

Nonce,

SALifeTime,

Status)

Parameters:

Name Data type DescriptionSourceIdentifier MIHF_ID This identifies the invoker, which is a remote MIHF.


LLInformation LL_FRAMES (Optional)This carries link layer frames. This attribute is included if and only if the corresponding MIH_LL_TransferMIH_Prereg_Xfer.request contained LLInformation.

MNnetworkaccessid NAIMIHF_ID (Optional) This carries the MN’s Network Access Identifier in the case optimized pull key distribution is used

TPoSIdentifier TPoSMIHF_ID (Optional) This identifies the target PoS

MIRK ENCR_BLOCK (optional) A shared key, Ktpos, encrypted to be recoverable by MN

MNmsrk ENCR_BLOCK (optional) Media Specific root key (for use with EAP methods)Nonce NONCE_VALUE (optional) Nonce SALifeTime LifeTime (optional) Lifetime of the Security AssociationStatus STATUS Status of the preregistration transfer with TPoS

0. Success1. TPoS is identical to OPoS, use Kopos2. Failure3. (Authorization Failure) is not applicable.Status of the

operation.


20

1

234

56

7

8

9

10

11

12

13

14

15

16

17

18

1


6.4.29.1.15[6.4.30.4.3] When generatedThis primitive is generated by the local MIHF after receiving an MIH_LL_TransferMIH_Prereg_Xfer response message.

6.4.29.1.16[6.4.30.4.4] Effect on receiptThe MIH user on the MN may generate an MIH_LL_TransferMIH_Prereg_Xfer.request primitive unless the authentication or association processes are completed.

[6.4.31] MIH_N2N_LL_TransferMIH_N2N_Prereg_XferThe primitives defined are to transport media link-layer frames for the target link over the MIH protocol between the serving PoSoriginating PoS and the target PoS. The media specific authentication is conducted with the media specific authenticator deployed in the target PoA Pre-registrationPreregistration is conducted between the MN and the tarraget PoA. As part of pre-registrationpreregistration, media specific authentication may be conducted with the media specific authenticator deployed in the target PoA..

[6.4.31.1] MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.request

6.4.29.1.17[6.4.31.1.1] FunctionThis primitive is used to transport link layer frames between the serving PoSoriginating PoS and the target PoS.

6.4.29.1.18[6.4.31.1.2] Semantics of Service PrimitiveMIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.request (



LLInformation,

MNID,

Nonce,

MIRK,

CandidateLinkList

)

Parameters:

21

123

456

789

101112

13

141516

1718

19

20

21

22

23

24

25

26

27



DestinationIdentifier MIHF_ID This identifies a remote MIHF that will be the destination of this request.

TargetLinkIdentifier LINK_TUPLE_ID(Optional) Identifies the remote PoA as the corresponding peer of the L2 exchange; 0 shall be included if the target link is known.

LLInformation LL_FRAMES (Optional) Carries link layer frames; shall be included if the target link is known.

MNID MIHF_ID (Optional) MIHF_ID of the MN to identify the MN’s Media Independent Root Key to be transferred to the target PoS.

MNmsrk KEY

(Optional) MN’s Media Specific Root Key that has been transferred from the originating PoS. This parameter can be used only if the PoA supports EAP or ERP for media-specific access authentication.

Nonce NONCE_VALUE A random number.MIRK ENCR_BLOCK A shared key, Ktpos, encrypted in a way recoverable by TPoSCandidateLinkList LIST (LINK_PoA_LIST) (Optional) A list of PoAs, identifying candidate networks to

which handover needs to be initiated. The list is sorted from most preferred first to least preferred last. This attribute shall not be included if the target link is known.

6.4.29.1.19[6.4.31.1.3] When generatedThis primitive is generated when the originating PoS receives an MIH_Prereg_Xfer request message by, the serving PoS to relay preregistration signaling link layer frames to the target PoS, possibly to relay link layer frames as well as possibly S to establish a security association based on shared key Ktpos,when the serving PoS receives an MIH_LL_Transfer request message.

6.4.29.1.20[6.4.31.1.4] Effect on receiptThe local MIHF shall generate an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer request message to the remote MIHF.

[6.4.31.2] MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.indication

6.4.29.1.21[6.4.31.2.1] FunctionThis primitive is used by the local target MIHF to notify the corresponding MIH user of the reception of an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer request message.

6.4.29.1.22[6.4.31.2.2] Semantics of service primitiveMIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.indication (

SourceIdentifier,


MNID,

Nonce,

MIRK,

LLInformation,

CandidateLinkList,

MNmsrk


22

1

23456

789

10

111213

1415

16

17

18

19

20

21

22

23

1


)

Parameters:


SourceIdentifier MIHF_ID This identifies the invoker, which is a remote MIHF.

TargetLinkIdentifier LINK_TUPLE_ID

(Optional)This identifies the remote PoA that is the corresponding peer of the L2 exchange. 0 This attribute shall be included if the target link is known.

MNID MN_IDID of the MN, used to index and compute the MN’s Media Independent Root Key to be established the target PoS

Nonce NONCE_VALUE A random number.

MIRK ENCR_BLOCK A shared key, Ktpos, encrypted in a way recoverable by TPoS

LLInformation LL_FRAMES(Optional)This carries link layer frames. This attribute shall be included if and only the target link is known.

CandidateLinkList LIST(LINK_PoA_LIST) (Optional) A list of PoAs, identifying candidate networks to which handover needs to be initiated. The list is sorted from most preferred first to least preferred last. This attribute shall not be included if the target link is known.

MNmsrk KEY

(Optional) MN’s Media Specific Root Key that has been transferred from the serving PoSoriginating PoS. This parameter can be used only if the PoA supports EAP or ERP for media-specific access authentication.

6.4.29.1.23[6.4.31.2.3] When generatedThis primitive is generated by the local target MIHF after receiving an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer request message.

6.4.29.1.24[6.4.31.2.4] Effect on receiptThe MIH user must generate an MIH_N2N_LL_Transfer.response primitive.The TPoS MIH user must recover the Ktpos according to the formula in Section 16.1 and install it as necessary in the target AAA function. The TPoS also must generate appropriate messages to the TPoA to install a MSPMK which will be used by MN as necessary when MN connects to the target network.

The MIH user must generate a MNnetworkAccessID associated with the MNID provided.

The MIH user must subsequently generate an MIH_N2N_Prereg_Xfer.response primitive and include MNnetworkAccessID.

Ktpos or MNmsrk will be further used to derive a key called a media-specific pair-wise master key (MSPMK) defined in 10.2.1.2. The MSPMK will be distributed to the target PoA using media-specific key distribution described in 10.2.2.


23

1

2

3

456

789

1011

12

1314

151617

18

1


MNmsrk will be further used to derive a key called a media-specific pair-wise master key (MSPMK) defined in 10.2.1.2. The MSPMK will be distributed to the target PoA using media-specific key distribution described in 10.2.2.

Note to editor: Clauses 10.2.1.2 and 10.2.2 are defined in IEEE 802.21a-2012.

[6.4.31.3] MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.response

6.4.29.1.25[6.4.31.3.1] FunctionThis primitive is used by an MIH user to provide the link-layer frames to the local MIHF.

6.4.29.1.26[6.4.31.3.2] Semantics of service primitiveMIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.response (



LLInformation,

MNnetworkaccessid,

SALifeTime,

Status

)

Parameters:




LLInformation LL_FRAMES

(Optional) Carries link layer frames; included if and only if the corresponding MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.indication contained LLInformation.

MNnetworkaccessid NAIMIHF_ID (Optional) Carries the MN’s Network Access Identifier when optimized pull key distribution is used.

SALifeTime LifeTime (Optional) Lifetime of the Security Association

Status STATUS

Status of the preregistration transfer with TPoS1. Success2. ( TPoS is identical to OPoS), is not applicable.3. Failure4. (Authorization Failure) is not applicable.Status of the

operation.

6.4.29.1.27[6.4.31.3.3] When generatedThis primitive is generated after receiving an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.indication primitive.


24

123

4

5

67

89

10

11

12

13

14

15

16

17

18

192021

1


6.4.29.1.28[6.4.31.3.4] Effect on receiptThe local target MIHF (TPoS) must generate an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer response message in order to provide the required information until the authentication is finished.

[6.4.31.4] MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.confirm

6.4.29.1.29[6.4.31.4.1] FunctionThis primitive is used to notify the corresponding MIH user about the reception of an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer response message.

6.4.29.1.30[6.4.31.4.2] Semantics of service primitiveMIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.confirm (

SourceIdentifier,


LLInformation,

MNnetworkaccessid,

Status

)

Parameters:



LLInformation LL_FRAMES(Optional) This carries link layer frames. This attribute is included if and only if LLInformation was contained in the corresponding MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.request

MNnetworkaccessid NAIMIHF_ID (Optional) This carries the MN’s Network Access Identifier when optimized pull key distribution is used

Status STATUS

Status of the preregistration transfer with TPoS1. Success2. (TPoS is identical to OPoS), is not applicable.3. Failure4. (Authorization Failure) is not applicable.Status of the operation.

6.4.29.1.31[6.4.31.4.3] When generatedThis primitive is generated by the remote MIHF after receiving an MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer response message.

6.4.29.1.32[6.4.31.4.4] Effect on receiptThe MIH user invokes an MIH_LL_Transfer.response primitive with the information obtained from this primitive.The OPoS MIH user generates an MIH_Prereg_Xfer.response primitive with the information obtained from this primitive. The OPoS also retrieves its stored value for Ktpos which had previously been sent to TPoS, encrypts it, and makes it available for the MIH_ LL_Transfer.response.


25

123

4

567

89

10

11

12

13

14

15

16

17

181920

2122232425

1


6.4.30[6.4.32] MIH_IF_PreReg_Ready

6.4.30.1[6.4.32.1] MIH_IF_PreReg_Ready.request

6.4.30.1.1[6.4.32.1.1] FunctionThis primitive is used by the SRCF SR-MIHF user to request pre-registrationpreregistration on a target link interface of the MN.

6.4.30.1.2[6.4.32.1.2] Semantics of service primitiveMIH_IF_PreReg_Ready.request (


ExecutionDelay

)

Parameters:

Name Data type DescriptionDestinationIdentifier MIHF_ID This identifies the local MIHF or a remote MIHF that will be the

destination of this request.

ExecutionDelay UNSIGNED_INT(2) Time (in ms) to elapse before the action needs to be taken. A value of 0 indicates that the action is taken immediately. Time elapsed is calculated from the instance the request arrives until the time when the execution of the action is carried out.

6.4.30.1.3[6.4.32.1.3] When generatedThis primitive is generated by the SRCF SR-MIHF user to prepare pre-registrationpreregistration of the target link.

6.4.30.1.4[6.4.32.1.4] Effect on receiptUpon receipt of this primitive, the local SRCFSR-MIHF generates and sends an MIH_IF_PreReg_Ready request message to the remote SRCFSR-MIHF identified by the Destination Identifer. The remote SRCFSR-MIHF issues Link_IF_PreReg_Ready.request(s) to the specified lower layer link(s).

6.4.30.2[6.4.32.2] MIH_IF_PreReg_Ready.confirm

6.4.30.2.1[6.4.32.2.1] FunctionThis primitive is used by the SRCFSR-MIHF to confirm that MIH_IF_PreReg_Ready response message was received from a peer SRCFSR-MIHF.

6.4.30.2.2[6.4.32.2.2] Semantics of service primitiveMIH_IF_PreReg_Ready.confirm (

SourceIdentifier,

Status

26

1

2

3

456

78

9

10

11

12

13

141516

17181920

21

222324

2526

27

28


)

Parameters:

Name Data type DescriptionSourceIdentifier MIHF_ID This identifies the invoker of this primitive, which can be either the

local MIHF or a remote MIHF.

Status STATUS Status of the operation. Code 3 (Authorization Failure) is not applicable.Status of the operation.

6.4.30.2.3[6.4.32.2.3] When generatedThis primitive is generated by the SRCFSR-MIHF on receiving an MIH_IF_PreReg_Ready response message form a peer SRCFSR-MIHF.

6.4.30.2.4[6.4.32.2.4] Effect on receiptUpon receipt of this primitive, the SRCFSR-MIHF user can know success of pre-registrationpreregistration preparation on the target link. However, if Status does not indicate “Success,” the recipient performs appropriate error handling.

[6.4.33] MIH_TNMN_SA_EstabThe primitives are defined to transport between the mobile node MN and the servingsource PoS via MIH. The servingsource PoS (SPoS) uses the information provided to identify a target PoS (TPoS) as necessary, and establishes a security association between MN and TPoS by distributing a key to TPoS which will later be also shared with the MN.

[6.4.33.1] MIH_TNMN_SA_Estab.request

[6.4.33.1.1] FunctionThis primitive is used to transport parameters and link layer frames between the MN and the SPoS for the purpose of establishing a secure tunnel between the MN and the TPoS in an appropriate target network.

[6.4.33.1.2] Semantics of Service PrimitiveMIH_TNMN_SA_Estab.request (

TargetLinkIdentifier (optional),

TargetLinkInfoList (optional),

TPoSIdentifier (optional),

LLInformation (optional),

)

Parameters:

Name

Data type Description

27

1

2

3

456

789

10

1112131415

16

171819

2021

22

23

24

25

26

27


TargetLinkIdentifier LINK_TUPLE_ID (Optional) This identifies the remote PoA that is the corresponding peer of the L2 exchange. 0

TargetLinkInfoList LIST (LINK_PoA_LIST) (Optional) Information that the MN can provide to the SPoS for selection of the proper TPoS. This can include values and IEs from tables F.10, F.11, F.14, and G.1.

TPoSIdentifier TPOSMIHF_ID TPoSIdentifier (optional)

LLInformation LL_FRAMES (Optional) Carries link layer frames. This attribute shall not be included unless the TargetLinkIdentifier is included by the MN.

[6.4.33.1.3] When generatedThis primitive is generated by the MN to instruct its SPoS to generate a Security Association with an appropriate TPoS, for instance so that the MN and the TPoS are able to carry out preregistration commands before handover to TPoA. The MN can include whatever information it has available about any suitable TPoA for use by SPoS to identify the proper TPoS. If the MN has sufficient information about TPoA to include layer 2 frames, those frames can also be supplied for secure delivery to TPoA. In this way, the number of round trips for preregistration may be minimized.

[6.4.33.1.4] Effect on receiptIf the TargetLinkIdentifier is not included, the SPoS shall use the TargetLinkInfoList (if included) to identify the appropriate TPoS that can initiate pre-registration activities with an appropriate TPoA. In the absence of other information, the SPoS can use available link-type information and location information for the MN to identify an appropriate TPoS. Some location information about the MN may be available by associating geographical coordinates with the MN’s current Point of Attachment (i.e., SPoA). The SPoS MIHF shall generate an MIH_N2N_MNTN_SA_Estab request message to the remote TPoS MIHF.


28

1

2345678

9101112131415

1


MIH_TNMN_SA_Estab.indication

Function

This primitive is used by the local MIHF (SPoS) to notify the corresponding MIH user of the reception of an MIH_TNMN_SA_Estab request message.

Semantics of service primitive

MIH_TNMN_SA_Estab.indication (

MNID,

TargetLinkIdentifier (optional),

TargetLinkInfoList (optional),

TPoSIdentifier (optional),

TargetLocationData (optional),

)

Parameters:


MNID MN_ID Identity of the requesting mobile node MN

TargetLinkIdentifier LINK_TUPLE_ID (Optional) This identifies the remote PoA that is the corresponding peer of the L2 exchange. 0

TargetLinkInfoList LIST (LINK_PoA_LIST) (Optional) Information that the MN can provide to the SPoS for selection of the proper TPoS. This can include values and IEs from tables F.10, F.11, F.14, and G.1.

TPoSIdentifier TPOSMIHF_ID TPoSIdentifier (optional)

LLInformation LL_FRAMES(Optional) Carries link layer frames. This attribute shall not be included unless the TargetLinkIdentifier is included by the MN.


29

1

2

34

5

6

7

8

9

10

11

12

13

1


When generated

This primitive is generated by the local SPoS MIHF after receiving an MIH_TNMN_SA_Estab request message from the MN.

Effect on receipt

The MIH user application on the SPoS uses the information provided by the MN to identify an appropriate target PoS (TPos). If the TPoS is hosted remotely (e.g., in a separate target network), the MIH user application on the SPoS must generate an MIH_N2N_MNTN_SA_Estab.request primitive for TPoS.


MIH_TNMN_SA_Estab.response

Function

This primitive is used by MIH user application at the SPoS to Security Association establishment information to the SPoS MIHF for transmission to the MN.


MIH_ TNMN_SA_Estab.response (



LLInformation,

MNnetworkaccessid,

MIRK,

MNmsrk,

Nonce,

SALifeTime,

SA_Status_Code

)

30

1

2

34

5

6789

10

11

12

1314

15

16

17

18

19

20

21

22

23

24

25

26


Parameters:


DestinationIdentifier MIHF_ID This identifies a remote MIHF that will be the

destination of this response.

TargetLinkIdentifier LINK_TUPLE_ID This identifies the remote PoA that is the corresponding peer of the L2 exchange. 0

LLInformation LL_FRAMES(Optional) Carries link layer frames; included if and only if the corresponding MIH_TNMN_SA_Estab.indication contained LLInformation.

MNnetworkaccessidNAI

(Optional) Carries the MN’s Network Access Identifier when optimized pull key distribution is used.

MIRK ENCR_BLOCK (optional) A shared key, Ktpos, encrypted to be recoverable by MN

MNmsrk ENCR_BLOCK (optional) Media Specific root key (for use with EAP methods)

Nonce NONCE_VALUE (optional) Nonce

SALifeTime LifeTime (optional) Lifetime of the Security Association

SA_Status_Code Octet Status of the security establishment with TPoS

Success

TPoS is identical to SPoS, use Kspos

Failure


31

1

1


When generated by the SPoS

This primitive is generated after receiving an MIH_N2N_MNTN_SA_Estab.confirm primitive. After the SPoS has received the confirmation that the TPoS has accepted the Security Association, the SPoS MIHF issues this primitive so that the MN can complete the establishment of the secure tunnel. For this purpose, the SPoS has to supply the MIRK, MNmsrk, Nonce, and SALifeTime to the MN according to the formula specified in section 16.1.

on receipt at the MN

The local MIHF must generate an MIH_TNMN_SA_Estab response message in order to provide the required information until the authentication is finished.

MIH_TNMN_SA_Estab.confirm

Function

This primitive is used to notify the corresponding MIH user about the reception of an MIH_TNMN_SA_Estab response message.


MIH_TNMN_SA_Estab.confirm (

SourceIdentifier,


LLInformation,

MNnetworkaccessid,

SA_Status_Code

)

Parameters:

32

1

2

345678

9

1011

12

13

1415

16

17

18

19

20

21

22

23

24



SourceIdentifier MIHF_ID This identifies the invoker, which is a remote MIHF.

TargetLinkIdentifier LINK_TUPLE_ID This identifies the remote PoA that is the corresponding peer of the L2 exchange. 0

LLInformation LL_FRAMES(Optional) This carries link layer frames. This attribute is included if and only if LLInformation was contained in the corresponding MIH_TNMN_SA_Estab.request

MNnetworkaccessid NAI (Optional) This carries the MN’s Network Access Identifier when optimized pull key distribution is used


33

1


SA_Status_Code Octet Status of the security establishment with TPoS

Success

TPoS is identical to SPoS, use Kspos

Failure

34


When generated

This primitive is generated by the remote MIHF after receiving an MIH_TNMN_SA_Estab response message.

Effect on receipt

The MIH user invokes an MIH_LL_Transfer.response primitive with the information obtained from this primitive.

MIH_N2N_MNTN_SA_Estab

The primitives defined are to transport a shared key over MIH between the mobile node MN and the servingsource PoS. The servingsource PoS (SPoS) uses the information provided to identify a target PoS (TPoS) as necessary, and establishes a security association between MN and TPoS by distributing a key to TPoS which will later be shared with the MN.

MIH_N2N_MNTN_SA_Estab.request

Function

This primitive is used to transport link layer frames between the serving PoS and the target PoS.

Semantics of Service Primitive

MIH_N2N_MNTN_SA_Estab.request (

MNID,

Nonce,

Encrypted Key,

LLInformation

)

Parameters:

35

1

1

23

4

56

7

89

101112

13

14

1516

17

18

19

20

21

22

23

24





Encrypted Key ENCR_BLOCK A shared key, Ktpos, encrypted in a way recoverable by TPoS

LLInformation LL_FRAMES(Optional) Carries link layer frames. This attribute shall not be included unless the target link is known by the MN.

36


When generated

This primitive is generated by the serving PoS to establish a security association based on shared key Ktpos, as well as possibly link layer frames, to the target PoS when the serving PoS receives an MIH_TNMN_SA_Estab request message.

Effect on receipt

The local MIHF shall generate an MIH_N2N_MNTN_SA_Estab request message to the remote TPoS MIHF.

MIH_N2N_MNTN_SA_Estab.indication

Function

This primitive is used by the target TPoS MIHF to notify the corresponding MIH user of the reception of an MIH_N2N_MNTN_SA_Estab request message.


MIH_N2N_MNTN_SA_Estab.indication (

MNID,

Nonce,

Encrypted Key,

LLInformation

)

Parameters:




Encrypted Key ENCR_BLOCK A shared key, Ktpos, encrypted in a way recoverable by TPoS

LLInformation LL_FRAMES(Optional) Carries link layer frames. This attribute shall not be included unless the target link is known by the MN.

37

1

2

345

6

78

9

10

1112

13

14

15

16

17

18

19

20


When generated

This primitive is generated by the local TPoS MIHF after receiving an MIH_N2N_MNTN_SA_Estab request message from SPoS MIHF.

Effect on receipt

The TPoS MIH user must recover the Ktpos according to the formula in Section 16.1 and install it as necessary in the target AAA function. The TPoS also must generate appropriate messages to the TPoA to install a MSPMK which will be used by MN as necessary when MN connects to the target network.

The MIH user must, if necessary, derive generate a MNnetworkAccessID from associated with the MNID provided.

The MIH user must subsequently generate an MIH_N2N_MNTN_SA_Estab.response primitive and include MNnetworkAccessID.

Ktpos will be further used to derive a key called a media-specific pair-wise master key (MSPMK) defined in 10.2.1.2. The MSPMK will be distributed to the target PoA using media-specific key distribution described in 10.2.2.


MIH_N2N_MNTN_SA_Estab.response

Function

This primitive is used by a TPoS MIH application to respond to SPoS MIH application.


MIH_N2N_MNTN_SA.response (


LLInformation (optional),

MNnetworkaccessid,

SALifeTime (optional),

Status

)

Parameters:

38

1

2

34

5

6789

1011

1213

141516

17

18

19

20

21

22

23

24

25

26

27

28

29



DestinationIdentifier MIHF_ID This identifies the SPoS MIHF that will be the

destination of this response.

LLInformation LL_FRAMES(Optional) Carries link layer frames; not included unless the corresponding MIH_N2N_MNTN_SA_Estab.indication contained LLInformation.



Status BOOLEANSTATUS Status of the operation.

39


When generated

This primitive is generated after receiving an MIH_N2N_MNTN_SA_Estab.indication primitive.

Effect on receipt

The target TPoS MIHF must generate an MIH_N2N_MNTN_SA_Estab response message in order to provide the required information to SPoS for delivery to MN.

MIH_N2N_MNTN_SA_Estab.confirm

Function

This primitive is used to notify the corresponding MIH user about the reception of an MIH_N2N_MNTN_SA_Estab response message.


MIH_N2N_MNTN_SA_Estab.confirm (


LLInformation,

MNnetworkaccessid,

Status

)

Parameters:


DestinationIdentifier MIHF_ID This identifies the SPoS MIHF that will be the destination of this response.

LLInformation LL_FRAMES(Optional) Carries link layer frames; not included unless the corresponding MIH_N2N_MNTN_SA_Estab.indication contained LLInformation.



Status BOOLEANSTATUS Status of the operation.

40

1

2

34

5

67

8

9

1011

12

13

14

15

16

17

18

19


When generated

This primitive is generated by the SPoS MIHF after receiving an MIH_N2N_MNTN_SA_Estab response message.

Effect on receipt

The SPoS MIH user invokes an MIH_MNTN_SA_Estab.response primitive with the information obtained from this primitive. The SPoS also retrieves its stored value for Ktpos which had previously been sent to TPoS, encrypts it, and makes it available for the MIH_MNTN_SA_Estab.response.

6.4.31 MIH_CTRL_Transfer

6.4.31.1 MIH_CTRL_Transfer.request

6.4.31.1.1 FunctionThis primitive delivers control messages encapsulated by MIH header. The control messages are messages to control networks. Therefore, the control messages are not only network specific control messages but also messages, such as ANQP and ANDSF messages, for interworking heterogenous networks.

6.4.31.1.2 Semantics of service primitiveMIH_CTRL_Transfer.request (


CTRLInformation,

)

Parameters:

Name Data type DescriptionDestinationIdentifier MIHF_ID Identifies a remote MIHF as the destination of this

request.CTRLInformation CTRL_PRTC_MSGS Delivers control messages.

6.4.31.1.3 When generatedThis primitive is generated by an MIH user to deliver control messages such as ANQP and ANDSF messages.

41

1

2

34

5

6789

1011

12

13

14

15161718

19

20

2122

23

24

25

26

27

282930


6.4.31.1.4 Effect on receiptAfter reception of this primitive, the MIHF must generate an MIH_CTRL_Transfer request message towards the remote MIHF.

6.4.31.2 MIH_CTRL_Transfer.indication

6.4.31.2.1 FunctionThis primitive is used by the remote MIHF to notify the corresponding MIH user about the reception of an MIH_CTRL_Transfer request message.

6.4.31.2.2 Semantics of service primitiveMIH_CTRL_Transfer.indication (

SourceIdentifier,

CTRLInformation,

)

Parameters:

Name Data type DescriptionSourceIdentifier MIHF_ID Identifies the invoker, typically a remote MIHF.

CTRLInformation CTRL_PRTC_MSGS This delivers control messages.

6.4.31.2.3 When generatedThis primitive is generated by a remote MIHF after receiving an MIH_CTRL_Transfer request message.

6.4.31.2.4 Effect on receipt The MIH user must generate an MIH_CTRL_Transfer.response primitive.

6.4.31.3 MIH_CTRL_Transfer.response

6.4.31.3.1 FunctionThis primitive is used by an MIH user to provide control messages to the local MIHF.

6.4.31.3.2 Semantics of service primitiveMIH_CTRL_Transfer.response (


CTRLInformation,

Status

)

Parameters:

42

123

4

567

89

10

11

12

13

14

1516

1718

19

2021

2223

24

25

26

27

28




CTRLInformation CTRL_PRTC_MSGS Delivers control messages.

Status STATUS Status of the operation. Code 3 (Authorization Failure) is not applicable.

6.4.31.3.3 When generatedThis primitive is generated by the local MIHF after receiving an MIH_CTRL_Transfer.indication primitive.

6.4.31.3.4 Effect on receiptThe local MIHF may generate an MIH_CTRL_Transfer response messag.

6.4.31.4 MIH_CTRL_Transfer.confirm

6.4.31.4.1 FunctionThis primitive is used to notify the corresponding MIH user about the reception of an MIH_CTRL_Transfer response message.

6.4.31.4.2 Semantics of service primitiveMIH_CTRL_Transfer.confirm (

SourceIdentifier,

CTRLInformation,

Status

)

Parameters:


CTRLInformation CTRL_PRTC_MSGS Delivers control messages.Status STATUS Status of the operation. Code 3 (Authorization Failure)

is not applicable.

6.4.31.4.3 When generatedThis primitive is generated by the local MIHF after receiving an MIH_CTRL_Transfer response message.

6.4.31.4.4 Effect on receiptThe MIH user on the MN may generate an MIH_CTRL_Transfer.request primitive.

43

1

234

56

7

89

10

1112

13

14

15

16

17

18

1920

2122

23


1.10[1.8]

7. Media independent handover protocols

1.11[1.9]

1.12[1.10]

1.13[1.11]

7.1

7.2

7.3

7.4 MIH protocol frame format

7.4.1 General frame formatNote to editor: Insert new description for the new SID value, 5, into Table L.1.

Field name Size (bits) DescriptionMIH message ID (MID)-- Service identifier (SID)

4 5: Gateway Service

44

1

2

3

4

5

6

7

8

9

1011

12

13


1.14[1.12]

7.5

7.6 MIH protocol messages

1.14.1[1.12.1]

1.14.2[1.12.2]

7.6.1

7.6.2

7.6.3 MIH messages for command service

1.14.2.1[1.12.2.1]

1.14.2.2[1.12.2.2]

1.14.2.3[1.12.2.3]

1.14.2.4[1.12.2.4]

1.14.2.5[1.12.2.5]

1.14.2.6[1.12.2.6]

1.14.2.7[1.12.2.7]

1.14.2.8[1.12.2.8]

1.14.2.9[1.12.2.9]

1.14.2.10[1.12.2.10]

1.14.2.11[1.12.2.11]

1.14.2.12[1.12.2.12]

1.14.2.13[1.12.2.13]

1.14.2.14[1.12.2.14]

1.14.2.15[1.12.2.15]

1.14.2.16[1.12.2.16]

1.14.2.17[1.12.2.17]

1.14.2.18[1.12.2.18]

1.14.2.19[1.12.2.19]

45

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27


1.14.2.20[1.12.2.20]

1.14.2.21[1.12.2.21]

1.14.2.22[1.12.2.22]

1.14.2.23[1.12.2.23]

7.6.3.1

7.6.3.2

7.6.3.3

7.6.3.4

7.6.3.5

7.6.3.6

7.6.3.7

7.6.3.8

7.6.3.9

7.6.3.10

7.6.3.11

7.6.3.12

7.6.3.13

7.6.3.14

7.6.3.15

7.6.3.16

7.6.3.17

7.6.3.18

7.6.3.19

7.6.3.20

7.6.3.21

7.6.3.22

7.6.3.23

[7.6.3.24] MIH_LL_TransferMIH_Prereg_Xfer request

46

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28


This message is used by an MIHF to request its OPoS initiate the establishment of a security association with an appropriate TPoS, and possibly to carry link layer frames to conduct expedite an authentication. The corresponding primitive is defined in Section 7.4.29.1. A Nonce is included if and only if MN uses non-EAP-based MIRK and an MIRK has not been received from the serving PoSoriginating PoS. TargetLinkInfoList is included if MN has information available about the desired target link.

MIH Header Fields (SID=1, Opcode=1, AID=109)Source Identifier = sending MIHF ID

(Source MIHF ID TLV)Destination Identifier = receiving MIHF ID

(Destination MIHF ID TLV)TargetLinkIdentifier (optional)

(Link Identifier TLV)TargetLinkInfoList (optional)

(TargetLinkInfolist TLV)LLInformation (optional)

(Link Layer Information TLV)TPoSIdentifier (optional)

(TPoS Identifier TLV)CandidateLinkList (optional)

(Link identifier list TLV)Nonce (optional)

(Nonce TLV)

(Note to editor: Nonce TLV is defined in IEEE 802.21a-2012.)

[7.6.3.25] MIH_LL_TransferMIH_Prereg_Xfer responseThis message is used for an MIHF to complete the establishment of a security association between an MN and an appropriate TPoSto carry link layer frames to conduct an authentication. The corresponding primitive is defined in Section 7.4.29.3. A Nonce is carried if and only if MN uses non-EAP-based MIRK and the Nonce has not been sent to the target PoS. An MIRK contains an encrypted Ktpos. An MIRK and a SALifetime are carried if and only if non-EAP-based MIRK is used and the encrypted Ktpos has not been distributed to the MN.

47

12345

6

7

89

1011121314





(Link Identifier TLV)LLInformation (optional)

(Link Layer Information TLV)MNnetworkaccessid (optional)

(Network Access Identifier TLV)CandidateLinkList (optional)

(Link identifier list TLV)TPoSIdentifier (optional)

(TPoS Identifier TLV)MIRK (optional)

(Media Independent root key TLV)MNmsrk (optional) (Media Specific root key TLV)

Nonce (optional) (Nonce TLV)SALifeTime (optional)

(Lifetime TLV)Status

(Status TLV)

(Note to editor: Lifetime TLV is defined in IEEE 802.21a-2012.)

[7.6.3.26] MIH_N2N_LL_TransferMIH_N2N_Prereg_XferAuth requestThis message is used for an MIHF to carry link layer frames to conduct an authentication. The corresponding primitive is defined in Section (must be “section”) 7.4.30.1. An MIRK may be carried either if non-EAP-based MIRK is used and an MNID is carried or if non-EAP-based MIRK is used and a Nonce and SALifetime are carried. When non-EAP-based MIRK is used, the MIRK contains an encrypted Ktpos. -. See 9.2.2 for detailed usage of MNID and MIRK. An MNmsrk may also be carried when the PoA identified by the LinkIdentifier supports EAP or ERP for media-specific access authentication. A Nonce and a SALifetime are included if and only if non-EAP-based MIRK is used and the encrypted Ktpos has not been distributed to the MN.

Note to editor: Clauses 9.2.2 is defined in IEEE 802.21a-2012.

MIH Header Fields (SID=1, Opcode=1, AID=119)Source Identifier = sending MIHF ID (Source MIHF ID TLV)

Destination Identifier = receiving MIHF ID (Destination MIHF ID TLV)TargetLinkIdentifier (optional) (Link Identifier TLV)

LLInformation (optional) (Link Layer Information TLV)MNID (optional) (Mobile node MIHF ID TLV)

MIRK (optional) (Media Independent root key TLV)MNmsrk (optional) (Media Specific root key TLV)

Nonce (optional) (Nonce TLV)MIRK (ENCR_BLOCK TLV)

SALifeTime (optional) (Lifetime TLV)

48

1

2

3

456789

101112

13

14


[7.6.3.27] MIH_N2N_LL_TransferMIH_N2N_Prereg_XferAuth responseThis message is used for an MIHF to complete the establishment of a security association between itself and the incoming MNto carry link layer frames to conduct an authentication. The corresponding primitive is defined in Section 7.4.30.3. The SALifeTime may be included if specified by the TPoS for the requested security association.

MIH Header Fields (SID=1, Opcode=2, AID=119)Source Identifier = sending MIHF ID (Source MIHF ID TLV)

Destination Identifier = receiving MIHF ID (Destination MIHF ID TLV)TargetLinkIdentifier(Link Identifier TLV)

LLInformation (optional)(Link Layer Information TLV)

MNnetworkaccessid(Network Access Identifier TLV)(optional)

SALifeTime (optional) (Lifetime TLV)Status

(Status TLV)

7.6.3.24[7.6.3.28] MIH_IF_PreReg_Ready requestThe corresponding MIH primitive of this message is defined in 7.4.31.1.

This message is transmitted to the remote MIHF to perform preparation of pre-registrationpreregistration.



(Destination MIHF ID TLV)ExecutionDelay

(Link Identifier TLV)

7.6.3.25[7.6.3.29] MIH_IF_PreReg_Ready responseThe corresponding MIH primitive of this message is defined in 7.4.31.2.

This message returns the result of an MIH_IF_PreReg_Ready request.



(Destination MIHF ID TLV)Status

(Link Identifier TLV)

[7.6.3.30] MIH_TNMN_SA_Estab requestThis message is used by an MN MIHF to request its SPoS initiate the establishment of a security association with an appropriate TPoS. The corresponding primitive is defined in Section 7.4.32.1. TargetLinkInfoList is included if MN has information available about the desired target link.

49

1

23456

7

89

10

11

1213

14

15

16171819



(Source MIHF ID TLV)Destination Identifier = SPoS MIHF ID



(TargetLinkInfolist TLV)TPoSIdentifier (optional)

(PoS MIHF ID TLV)LLInformation (optional)

(Link Layer Information TLV)

[7.6.3.31] MIH_TNMN_SA_Estab responseThis message is used by a SPoS MIHF to complete the establishment of a security association between an MN and an appropriate TPoS. The corresponding primitive is defined in Section 7.4.32.3. TargetLinkInfoList is included if MN has information available about the desired target link.

MIH Header Fields (SID=1, Opcode=3, AID=1314)Source Identifier = SPoS MIHF ID

(Source MIHF ID TLV)Destination Identifier = MN MIHF ID

(Destination MIHF ID TLV)TargetLinkIdentifier (optional) (Link Identifier TLV)

LLInformation (optional)(Link Layer Information TLV)

MNnetworkaccessid(Network Access Identifier TLV)(optional)

MIRK (optional) (Media Independent root key TLV)MNmsrk (optional) (Media Specific root key TLV)

Nonce (optional) (Nonce TLV)SALifeTime (optional) (Lifetime TLV)

SA_Status_Code

[7.6.3.32] MIH_N2N_MNTN_SA_Estab RequestThis message enables a SPoS MIHF to request that a TPoS MIHF initiate the establishment of a security association with an incoming MN. The corresponding primitive is defined in Section 7.4.33.1.

MIH Header Fields (SID=1, Opcode=1, AID=1415)Source Identifier = sending SPoS ID

(Source MIHF ID TLV)Destination Identifier = TPoS MIHF ID



(TargetLinkInfolist TLV)LLInformation (optional)

(Link Layer Information TLV)Nonce (Nonce TLV)

MNID (Mobile node MIHF ID TLV)Encrypted Key (ENCR_BLOCK TLV)

50

1

2

3456

7

89

10

11


[7.6.3.33] MIH_N2N_MNTN_SA_Estab responseThis message is used by a TPoS MIHF to complete the establishment of a security association between itself and the incoming MN. The corresponding primitive is defined in Section 7.4.33.3. The SALifeTime may be included if specified by the TPoS for the requested security association.

MIH Header Fields (SID=1, Opcode=3, AID=1415)Source Identifier = TPoS MIHF ID

(Source MIHF ID TLV)Destination Identifier = SPoS MIHF ID

(Destination MIHF ID TLV)MNnetworkaccessid

(Network Access Identifier TLV)(optional)SALifeTime (optional) (Lifetime TLV)

7.6.3.26[7.6.3.34] MIH_CTRL_Transfer requestThis message is used to deliver control messages such as ANQP and ANDSF message. The delivery of control messages is described in Section 12.3.



(Destination MIHF ID TLV)CTRLInformation

(Control Information TLV)

7.6.3.27 MIH_CTRL_Transfer responseThis message is used to respond to MIH_CTRL_Transfer request message. Moverover, this message can deliver control messages such as ANQP and ANDSF message. The delivery of control messages is described in Section 12.3.



(Destination MIHF ID TLV)CTRLInformation

(Control Information TLV) (optional)

[7.6.4] MIH messages for gateway serviceMIH gateway service is the service to deliver layer 2 or other interworking messages using SID, “5”. For theise kinds of delivery services, the MIH message is used as a kind of container of the layer 2 or other interworking messages. The delivered messages can be identified by AID, as shown in Table L.1.Messages in Table L.1 can be explained as follows.

* MIH_L2Message_Delivery: The MIH message for gateway service is used to deliver the layer 2 message.

* MIH_ANQP_Delivery: The MIH message for gateway service is used to deliver the ANQP message for the IEEE 802.11 network.

51

1234

5

678

9

10111213

14

15

1617181920

2122

2324


* Reserved for other interworking protocols: Reserved These AID values which isare reserved for supporting further interworking protocols.

* Reserved for vendor specific area: Reserved These AID values which isare reserved for supporting vendor specific messages.

[7.6.4.1] Request message for gateway serviceGateway service message is delivered after MIH header encapsulation. Thus, the message format of gateway service is the same as follows.

MIH Header Fields (SID=5, Opcode=1, AID)Source Identifier = sending MIHF ID


(Destination MIHF ID TLV)L2 message or other interworking message depending on the AID

value

[7.6.4.2] Response message for gateway serviceThis message returns the result of Request message for gateway service.

MIH Header Fields (SID=5, Opcode=2, AID)Source Identifier = sending MIHF ID


(Destination MIHF ID TLV)L2 message or other interworking message depending on the AID

value

8. MIH protocol protection

Note to editor: Modify section 9.2.2 (defined in IEEE 802.21a) as follows:

[1.13]

8.1

8.2 Key establishment through an MIH service access authentication

Modify clause 9.2.2 (defined in IEEE 802.21a) as follows:

1.14.3[1.13.1]

8.2.1

8.2.2 Key derivation and key hierarchyUpon a successful MIH service access authentication, the authenticator (i.e., PoS) obtains a master session key (MSK) or a re-authentication master session key (rMSK). Alternatively, via an optimized pull key distribution process, a Target PoS can obtain a 64-octet MIRK (Media-Independent Root Key) from a Serving PoSOriginating PoS (see clause 9.2.2.2). The MIRK and the MIHF identifier of the MN that holds the MIRK are used as the symmetric key credentials for a symmetric key based method (e.g., EAP-GPSK)

52

12

34

567

8

910

11

12

13

14

15

16

17

18

19

202122232425


to perform MIH service access authentication between the MN and the target PoS without necessarily communicating with the authentication server located in the MN’s home network.

There are two options to generate an MIRK. In the first option (i.e., EAP-based MIRK), an MIRK is derived from a master session key (MSK) or re-authentication MSK (rMSK) established between the MN and the Serving PoSOriginating PoS via MIH service access authentication using EAP. In the second option (i.e., non-EAP-based MIRK), an MIRK is generated by the Serving PoSOriginating PoS independently of the MIH SA established between the MN and Serving PoSOriginating PoS and distributed to the MN as well as the Target PoS. The first option is described in 9.2.2.2. The second option is described in 11.7.1.

[8.2.2.1] Derivation of media independent session keys (MISKs)

[8.2.2.2] EAP-basedOPoS-brokered MN—TPoS security association, and derivation of MIRKDerivation of media independent session keys (MISKs)

[8.2.2.3] During an optimized pull key distribution process that involves the MN, the serving PoSoriginating PoS and a target PoS, the serving PoSoriginating PoS derives a MIRK for a specific target PoS. Strings used in the computation (e.g., MN_MIHF_ID, “MIRK”) are never zero terminated. For MIRK derivation, the following notations and parameters are used:

K - key derivation key. The length of K is determined by the pseudorandom function (PRF) used to calculate a master session key (MSK) or re-authentication MSK (rMSK). If HMAC-SHA-1 or HMAC-SHA-256 is used as a PRF, then the full MSK or rMSK is used as the key derivation key, K. If CMAC-AES is used as a PRF, then the first 128 bits of MSK or rMSK are used as the key derivation key, K.

L - The binary length of derived keying material MIRK. L=512 bits for the MIRK.

h - The output binary length of PRF used in the key derivation. That is, h is the length of the block of the keying material derived by one PRF execution. Specifically, for HMAC-SHA-1, h = 160 bits; for HMAC-SHA-256, h =256 bits; for CMAC-AES, h = 128 bits.

n - The number of iterations of PRF in order to generate L-bits of keying material.

Nonce-T and Nonce-N - The nonces exchanged during the execution of service access authentication.

c - The ciphersuite code is a one octet string specified for each ciphersuite. The codes are specified in section 9.2.3.

v - The length of the binary representation of n (the counter) and L (the length of keying material). The default value for v is 32 (i.e., n and L are 32 bit variables).

[a]2 - Binary representation of integer a with a given length.

MN_MIHF_ID – Mobile node’s MIHF identity.

PoS_MIHF_ID – Target PoS’s MIHF identity.

“MIRK” - 0x4D49524B, i.e., the ASCII code in hex for string “MIRK”.

Fixed input values: h and v, L=512 bits.

53

12

3456789

10

1112

1314151617

1819202122

23

242526

27

2829

3031

3233

34

35

36

37

38


Input: K, Nonce-T, Nonce-N, and ciphersuite code c.

Process:

a) n := ⌈L/h⌉; /* ⌈x⌉ is the ceiling function, returning the least integer n >= x */

b) If n > 2v -1, then indicate an error and stop.

c) Result (0) := empty string.

d) For i := 1 to n, do

i) K(i) := PRF (K, “MIRK” || [i]2 || Nonce-T || Nonce-N ||

MN_MIHF_ID || PoS_MIHF_ID || c || [L]2).

ii) Result(i) := Result (i-1) || K(i).

e) Return Result (n) ; MISK is the leftmost L bits of Result (n).

Output: MIRK

It is important to note that the key distribution of a MIRK from the Serving PoSOriginating PoS to the target PoS may produce a security weakness so-called “domino effect” [IETF RFC 4962]. This weakness implies that the compromise of the serving PoSoriginating PoS will also compromise the security association between the MN and the target PoS, since an attacker can know and derive the MIRK that is delivered to the target PoS. Reducing the latency of proactive authentication based on transferring a MIRK is at the cost of taking such a risk.

All other keys are derived from MIRK in the same manner as specified in section 10.2, illustrated in Figure 48 (formerly Figure 47 prior to this revision).

9. Proactive Authentication

9.1 Media specific proactive authentication

Modify Figure 46 (defined in IEEE 802.21a) as follows:Change first paragraph of 10.1 (defined in IEEE 802.21a) as follows:

In a media access proactive authentication, a Target PoS (TPoS) passes authentication messages between the mobile node and a media specific authenticator (MSA). The protocol stacks in each interface are illustrated in Figure 43 Figure 46 and Figure 47 . In scenarios where MSA/Target PoA is reachable via same media as MN and TPoS, EAP messages received at TPoS are directly forwarded to the target PoA. In an optimized pull key distribution, a n Originating PoS (OPoS) passes authentication messages between the mobile node, the target PoS and a media specific authenticator (MSA).

Replace Figure 46 (defined in IEEE 802.21a) as follows:

54

1

2

3

4

5

6

7

8

9

10

11

121314151617

1819

20

21

2223

24252627282930

31

32


ADD Insert new figure, renumber existing figure 47NEW FIGURE

Figure 47—Protocol Stack for MIH Supported optimized pull key distribution with two two Points of Service (PoS)PoSes

ADD

Insert second paragraph of 10.1 below Figure 47 as follows:

Figure 47 illustrates the protocol stacks and message passing when the Originating PoS (OPoS) (called Serving PoS in Figure 47) is in a different network than the TPoS. THE FOLLOWING EXPLANATION

In a media access proactive authentication, a PoS passes authentication messages between the mobile node and a media specific authenticator (MSA). The protocol stacks in each interface are illustrated in Figure 43. In scenarios where MSA/Target PoA is reachable via same media as MN and PoS, EAP messages received at PoS are directly forwarded to the target PoA. In an optimized pull key distribution, a PoS passes authentication messages between the mobile node, the target PoS and a media specific authenticator (MSA). The protocol stacks in each interface are illustrated in Figure 47.

55

12

3

4

56

78

9

10

11

121314

151617181920


Insert following new Clause 11 10.3

1.15

9.2

9.3[9.2] Establishing Security Association roaming partners for MIH

The PoS is a convenient and natural place to locate security functions, and roaming partners have in place agreements that can be used to beneficially establish the needed security agreements between different PoSes in partner networks. It is expected that in many cases the PoS functions in partner networks must communicate by data paths that traverse the external Internet; in such cases, a secure communication channel must exist or must be established between the partners. It is out of scope for this document to specify exactly how the secure communication channel should be established, but this can be done by configuration when the partners enter into their roaming agreement. It can also be done on demand by using IKEv2 [IETF RFC 5996]. The following overview describes in more detail the circumstances enabling dynamic establishment of security association between SPoSOPoS and TPoS.

Figure 10.2.149: MN handover signaling for preregistration using SPoSOPoS

Except for the initial network attach, by the time a MN enters a network, it can also have a security relationship with the PoS in that network by using the protocol in this document. For each visited network, this security relationship can be created on demand, enabled by signaling from another PoS. The PoS creating the visited security relationship can either be the MN's home PoS (HPoS, a PoS in MN's home

56

1

2

3

4

56789

10111213

14

15

16

1718

19

20212223


network), or the PoS in the network previously visited by the MN. When the MN first attaches to one of the partner networks of the roaming partners, it is either the MN's home network, or a visited network. If the first attachment is to the MN's home network, then the MN is expected to already have a security association with HPoS; otherwise, the MN can bootstrap this security association using IKEv2 or standard AAA mechanisms or other proprietary means.

After initial attachment, there is signaling defined so that at all times the MN has a security association with the PoS in the network at its current point of attachment (PoA); the current network is termed the "source" network, and the PoS in the originating network is abbreviated as the SPoSOPoS. As the MN moves from one partner network to the next (i.e., to a new "target network"), the MN establishes or renews a security association with the PoS in the target network (i.e., the "TPoS"). When handover is completed, the TPoS naturally becomes the local PoS (SPoSOPoS).

In order to enable wider application of high-performance handovers and in particular preregistration signaling, security must be guaranteed for the control traffic. From above, we see that this signaling traffic is mediated by the PoS in each target network, which may be unknown to the MN until the need for handover has been determined. In such cases, for secure signaling, the MN needs to establish a security association with the target PoS. The process of establishing such a security association can be quite time consuming and often expensive in processor cycles as well. This clause specifies a much faster and easier method for providing security associations as needed between the MN and the target PoS in any target network within the networks covered by the roaming partners.

MIH_MNTN_SA_EstabPrereg_Xfer and MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer messages exchanged between the serving PoSoriginating PoS and the target PoS may require security protection. Furthermore, the target PoS may reject these messages from an unauthorized serving PoSoriginating PoS. To protect the link between the serving PoSoriginating PoS and the target PoS several approaches are possible.

An MIH SA (Security Association) defined in IEEE 802.21a can be used for protecting the communications between the serving PoSoriginating PoS and the target PoS. In this case, the serving PoSoriginating PoS acts as the initiating end-point of an MIH SA and the target PoS as the other end-point of the MIH SA. As specified in IEEE 802.21a, the MIH SA can be established using (D)TLS over MIH or EAP over MIH.

Other mechanisms such as IPSec and TLS over TCP can also be used for protecting the communications between the serving PoSoriginating PoS and the target PoS. Details on such mechanisms are outside the scope of this standard.

9.3.1 Key distribution by SPoSOPoSThis section specifies one algorithm to allow SPoSOPoS to distribute a shared key to the MN and to its desired TPoS. The shared key is then used as the basis for a secure communications channel between the MN and the TPoS, enabling further secure preregistration activities. The notation for PoS-based handover keys is listed in Table X.

57

12345

6789

1011

1213141516171819

2021222324

2526272829

303132

33

3435363738


Table X—Key notation for PoS-based handover

Khgw key between MN and HGW

Ksposopos key between MN and SPoSOPoS

Ktpos key between MN and TPoS; Ktpos is also referred to as the Media Independent Root Key (MIRK).

Khsposopos key between HPoS and SPoSOPoS

Khtpos key between HPoS and TPoS

Kstpos key between SPoSOPoS and TPoS

PNGsposopos pseudo-random number generator between MN and SPoSOPoS

PNGhsposopos pseudo-random number generator between HPoS and SPoSOPoS

PNGstpos pseudo-random number generator between SPoSOPoS and TPoS

As mentioned in the foregoing discussion, when the MN has determined that a handover is needed to a new network, we may assume that the MN has a security association with a service in its home network, here called the Home Gateway (HGW), based on a key Khgw . Interactions between the MN and its Home Gateway are out of scope for this protocol specification document. We also assume that, because of previous protocol operations, the MN has a current security association with the PoS in the originating network (SPoSOPoS). This security association is bidirectional and based on a share key Ksposopos.

Suppose the MN determines to move to a new network, the target network. Then the MN needs to preregister, and thus needs to use the PoS in target network (TPoS). Before it can do this, it needs to discover the address of TPoS and establish a security association with TPoS using Ktpos.

UE can make use of its existing security association with SPoSOPoS, because SPoSOPoS either already has, or can readily establish, a security association with TPoS. Suppose SPoSOPoS already has the required security association with TPoS. Then, when MN begins forwarding preregistration traffic to TPoS via SPoSOPoS, SPoSOPoS will provide MN and TPoS with a shared key, Ktpos, for use to protect the remainder of the MN's signaling traffic with TPoS. According to this proposal, the SPoSOPoS would thus forward the initial traffic to TPoS on behalf of the MN; the SPoSOPoS uses its own security relationship with TPoS to protect this initial preregistration signaling, and it also supplies the value of Ktpos to TPoS by adding a new extension to the preregistration traffic.

To send Ktpos to TPoS, SPoSOPoS provides the following payload within the TLVs of MIH_MNTN_SA_EstabPrereg_Xfer Request, a new 802.21(c) message:

Payload = MNnetworkaccessid, Nonce, [Ktpos PNG⊕ stpos (MNnetworkaccessid, Nonce)]

Upon receiving this payload, TPoS calculates PNGstpos (MNnetworkaccessid, Nonce) and XORs the result to the third parameter of the payload to recover Ktpos.

Similarly, to send Ktpos to MN, SPoSOPoS provides the following payload within the TLVs of MIH_TNMN_SA_EstabPrereg_Xfer Response, a new 802.21(c) message:

Payload = TPoSIdentifier, Nonce, [Ktpos PNG⊕ sposopos (TPoSIdentifier, Nonce)]

Upon receiving the payload, MN calculates PNGsposopos (TPoSaddr, nonce) and XORs the result to the third parameter of the payload to recover Ktpos.

Alternatively, for both of these messages, the entire contents could be encrypted by SPoSOPoS using the keys it has available with TPoS and MN respectively. MN is allowed to send more signaling information to

58

1

2

345678

91011

1213141516171819

2021

22

2324

2526

27

2829

3031


TPoS via SPoSOPoS even after SPoSOPoS distributes the keys; SPoSOPoS continues to forward traffic back and forth between MN and TPoS as needed until both endpoints have used Ktpos to establish the required security association. For best performance and least likelihood of congestion at SPoSOPoS, MN and TPoS should begin to use direct signaling as soon as possible and thus bypass SPoSOPoS. Other structures for the message payloads are also possible, depending on requirements.

Once the handover is completed, TPoS "becomes" SPoSOPoS and the handover cycle can begin anew whenever MN determines the need for the next handover.

9.3.2 TPoS selection by SPoSOPoSIt is possible for SPoSOPoS to take a more active role to promote smooth handover. When the UE determines the need for handover, but does not already know the address of the TPoS for the intended target network, the MN can start the preregistration sequence by sending all the known information to the SPoSOPoS. Subsequently, the SPoSOPoS will provide the address of the TPoS to the MN along with Ktpos, just as described above. The exact nature of the information about TPoS provided by the MN is dependent on the radio access technology type (RAT) of the target network, and may be specified in detail in later revisions of this document. Other alternatives for identifying the target network access point are also envisioned. For MNs configured with ANDSF software, detailed information about TPoS, and the other entities within the target network can easily be made available. Note, however, that discovery and secure communication with TPoS may be easier than discovery and secure communication with ANDSF.

10. Single Radio Handover

Insert new clause 11

10.1 Introduction (keep in reduced version)

In a single radio handover, a mobile node can transmit on only one radio at a time. This enables design simplifications that contribute to lower cost and longer battery life for the mobile device, appealing especially to the consumer market. Designing for single radio operation requires that one radio transmitter must be disabled before another radio interface can begin transmitting packets; this leads to a mode of operation commonly referred to as “break-before-make”. Multi-transmitter designs allow for simper designs for smooth handovers because the handover signaling has access to both origin and target networks at the same time. For single radio, the handover must be designed to accomplish as many handover functions as possible in the origin network before breaking communication and re-tuning to the target network. This typically includes preregistration in the target network, so that link establishment and device authentication can be accomplished as quickly as possible when the radio is re-tuned. Only after link establishment and authentication are complete can the mobile device continue running its desired applications. There is inevitably some short time during which communication is impossible, and it is the objective of this standard to minimize the disruption so that it does not adversely affect the applications or the user experience.

10.1.1 Proxy Gateway

Figure 11.2 An architecture of distributed mobility management.


59

12345

67

8

910111213141516171819

20

21

22

2324252627282930313233343536

37

3839

40414243


[10.1.1] Media Independent Control Function <exhibit as evolution of figure 4, section 5.5.2>A media independent control function (MICF) is shown in the control plane in Figure 11.3. It is a parallel control plane that provides control function for the MAC, PHY, and higher layer and has a service access point to each of these layers.

The Media Independent Service Access Point (MICSAP) interfaces between MICF and the higher layer. A TCP or UDP over IP packet can be encapsulated as a payload of an MIC frame. Conversely, an MIC frame can be encapsulated as a payload of a TCP or UDP over IP packet. The latter enables a MIC frame to be transported in a TCP or UDP over IP both within a network and across different networks.

The Media Independent Service Access Point (MICLSAP) interfaces between MICF and the MAC layer. A link-layer frame can be encapsulated as a payload of an MIC frame. Conversely, an MIC frame can be encapsulated as a payload of a MAC frame. The latter enables a MIC frame to be transported in a link-layer frame within a network.

The logical connection between the MICF in one network element to that in another network element in the same or different network is accomplished through the transport using TCP/UDP over IP. The media independent control function therefore supports cross-layer encapsulation to enable signaling between any layer in one network element and any layer in another network element. This capability will be used in the following to enable the link-layer frames in target radio to communicate with the target network.

[10.1.2] Single Radio handover Control Function <fold into MICF / MIHF, perhaps SR-MIHF>To prepare for handover, the MN’s target radio exchanges link-layer network entry PDUs with the target PoA at the target network. These network entry PDUs can be the same PDUs that would be exchanged if the target link were active. There is no guarantee that the target link is available during a single radio handover. A single radio handover control function (SRCF) is used here to enable the MN and the target PoA to exchange the network entry link-layer PDUs without depending on the existence of the target radio’s physical channel but with the help of the active source radio.

In figure 11.3 the Single Radio handover Control Function (SRCF) in a multiple interface node is implemented using the media independent control function (MICF) in the control plane, which is defined in the 802-2012 architecture [IEEE P802-D1.4].

MICFTCP or UDP/IP

L2(2) L2(1)

PHY(2) PHY(1)MN’s

interface 2MN’s

interface 1

MIC

LSAP

MIC

SAP

MIC

LSAP

Figure 11.3. Single Radio handover Control Function (SRCF) of a multiple interface mobile node within the Media Independent Control Function (MICF).

The SRCF interfaces with the TCP or UDP / IP layer through the Media Independent Control Service Access Point (MICSAP), and the SRCF uses an assigned transport layer protocol’s port number. Therefore, the SRCF in this local node may exchange single radio handover control (SRC) frames with the SRCF of a remote node as long as there is TCP or UDP / IP connection between these two nodes. The SRC frames are processed by the SRCF in the destination of the TCP or UDP / IP packets carrying the SRC frames. The

60

12345

6789

10111213

1415161718

19202122232425

262728

29303132

3334353637


SRCF also interfaces with the link-layer (L2) through the media independent control link-layer service access point (MICLSAP). An L2 frame of a deactivated link (e.g., interface 2) may therefore be encapsulated with a SRCF header to constitute a SRC frame, which is then exchanged via an active link between the SRCF’s of a local and a remote node using the TCP or UDP / IP connection between the two nodes.

[10.1.3] Transport of L2 network entry PDU of the target radio <redundant to fig. 4, section 5>The transport of L2 network entry PDUs of the target radio between the MN and the Proxy GW in the target network is enabled by the MICLSAP to the SRCF. The communication between the SRCF in the MN and the SRCF in the Proxy GW. Figure 11.4 shows the transport of L2 frame of target interface using the communication between the SRCF in the MN and the SRCF in the GW. (a) shows the transport through using MICLSAP and MICSAP in control-plane representation. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s..

(a)

MICFTCP or

UDP/ IPTCP or

UDP/ IP

MICF

L2(2) L2(1) L2 L2

PHY(2) PHY(1) PHY PHY

MN’s target interface

MN’s source interface

GWM

ICLSA

P

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2)

MICF MICFTCP or UDP / IP TCP or UDP / IP

L2(1) L2PHY(1) PHY

MN GW

Figure 11.4. Transport of L2 frame of target interface using the logical connection between the MICF in the MN and that in the GW, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

61

12345

6789

10111213

14

15

1617

18

19202122


Lacking physical connection between the MN’s target radio and the target network during a single radio handover, a L2 network entry PDU of the target radio requires service from SRCF. Passing to the SRCF via the MICLSAP, the L2 PDU becomes the payload of an SRC frame in the media independent control function of the MN. Only the source radio is fully capable of transmitting and receiving TCP or UDP / IP packets to/from the source access network, which has IP connection to the target network through the Internet. There is therefore TCP or UDP / IP transport between the source radio and the Proxy GW of the target network via the source interface. Building on the TCP or UDP / IP layer through the MICSAP, the SRCF at the MN may therefore communicate with the SRCF at the Proxy GW.

[10.1.4] Communication between the MN and the target PoA <…? Similarly depends on proxy discussion; move GW figures to GW section??>The MN needs to communicate eventually with the target PoA to prepare for handover by performing network access procedure with the target access network. The first part of this communication is the transport of TCP or UDP / IP packets to the Proxy GW, and the MN may query the Information Repository to find the IP address of the Proxy GW in order to use this TCP or UDP / IP transport. The second part of this communication depends on whether the target PoA supports MICF in the 802-architecture or whether it is a legacy PoA lacking such support.

If the target PoA supports MICF, the network entry L2 frame is encapsulated into SRC frames to forward to the target radio. Figure 11.5 shows the transport of the target radio L2 control frame as a payload of a media independent control frame between the MN and the Proxy GW via the source radio interface, in the absence of the target link. The Proxy GW bridges between the MN source link and the target PoA. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

MICF MICF MICF

TCP or UDP/ IP

TCP or UDP / IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP / IP

L2(2) frame L2(1)

Sourcelink

L2(1) L2 L2 L2 L2 L2(2) frame

No target link

L2(2) frame

PHY(2) PHY(1) PHY(1) PHY PHY PHY PHY PHY(2) PHY(2)

MN’s target radio

MN’s source radio

Source PoA GW Target PoA MN’s target radio

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

(b)

62

1

23456789

1011121314151617

181920212223

24

25

2627

L2(2) L2(2) L2(2) L2(2)MIF

L2(1) L2PHY(2) PHY(1) PHY PHY(2)

MN Target PoA

L2(2) MIF

L2PHY


L2(2) L2(2) L2(2) L2(2) L2(2)

MICF MICF MICF

TCP or UDP / IP

TCP or UDP / IP TCP or UDP/ IP

L2(1) L2 L2 L2

PHY(2) PHY(1) PHY PHY PHY PHY(2)

MN GW Target PoA

Figure 11.5 Transport of L2 frame of target interface via the GW using the logical connection at the MICF, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

The MN will need to acquire information of the candidate target PoA, e.g. by querying the Information Repository.

If MN knows the IP address of the target PoA, SRC frames may be exchanged between the SRCF in the MN and the SRCF in the target PoA using TCP or UDP / IP transport.

If MN does not know the IP address of the target PoA, it will need to have some means, such as the link-layer identification, of the target PoA in order to perform network entry procedure. The SRC frame is first sent as the payload of a TCP or UDP / IP packet destined to the Proxy GW as described in Clause 11.4.3. The SRC frame contains information for the target network to identify the target PoA. The Proxy GW will

Figure 11.6 shows the transport of the target radio L2 control frame as a payload of a media independent control frame between the MN and the Proxy GW via the source radio in the absence the target link. The GW communicates with the target PoA using other control messages in order to proxy between the MN and the target PoA. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

63

123

45

6

78

9101112

1314151617

18


Crtl msg Crtl msg

MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1)

Srclink

L2(1) L2 L2 L2 L2 L2(2) frame

No target link

L2(2) frame


MN’s target radio

MN’s source radio

Source PoA GW PoA MN’s target radio

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2) L2(2) Control Control

MI CF MICF message message

TCP or UDP / IP TCP or UDP / IP

TCP or UDP / IP

TCP or UDP / IP

L2(1) L2 L2 L2

PHY(1) PHY PHY PHY

MN GW Target PoA

Figure 11.6 Transport of L2 frame of target interface to the GW which proxy between the MN and the target PoA, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

[10.2] Major sSingle radio handover overall processes <keep, revise according to TG discussion>

A single radio handover following the above reference model in Section 5.4 may consists of different handover processes and involve different information elements (ClauseSection 711.8) and messages (ClauseSection 811.9). Examples of handover are described in Clause 11.6Annex N. Figure 11.7 shows the single radio handover procedures consisting of 5 processes as described below.

64

1

23

4

567

8

910

11121314


65

Originating network

CandidateTarget Network

CandidateTarget Network

1

2

MN Source network

Information repository Candidate target network 1 Candidate target network n

Source radio GW 1 Candidate PoA GW n Candidate

PoA

1. Network discovery

2. Handover decision

Target networkTarget radio GW Target PoA

3. Proactive authentication, pre-registration

4. Target link preparation

5. SRHO execution


Figure 11.750 – Overall SSingle Rradio Hhandover Pprocedures.

d) 1: Network discovery: determine whether or not there is a candidate target network available for handover.? In network discovery, the MN queries the Information Repository to discover candidate networks and their handover policies. Such information includes whether candidate networks and MN support SRHO or not, and the presence of Proxy GW on the candidate network. Network discovery also allows the MN to acquire the corresponding system information blocks of candidate PoAs to perform the radio measurements. Alternatively, the MN may request that the Source Network PoS identify one or more candidate target networks.

e) 2 : The handover decision may involve the following

1) i. A handover trigger.

66

MN Source network



PoA






5. SRHO execution

1

23

456789

10

11

12


2) ii. Target network selection

3) iii. Proxy gateway discovery.

4) iv. Evaluating the handover benefit: the evaluation can be made by the MN or the network, e.g., based on parameters such as signal strength, cost, and operator policy.

f) 3: Pre-registrationPreregistration includes pro-active authentication and establishing context (user identity, security, resource information) at the target network. WPossibly with the help of Proxy GW, the MN can perform network entry procedures towards the target network while still retaining its data connection with the source network. Optionally, the pre-registrationpreregistration process may occur before the network selection process as in the case of WiMAX target networks.

g) 4: Target link preparation: the MN and target network prepare the establishment of the target link. This process ascertains whether the target network has enough resources to accommodate the new link and may include performing resource reservation or admission control as well as confirming that the signal conditions are favorable enough to establish the target link. The MN’s target radio may perform limited signaling if possible within the constraints of peak power and signaling interface defined for single radio handover in this standard.

h) 5: SRHO execution process. Here, the source link is disconnected, the target radio is activated, and the target link is established. The association of the network layer address to the link layer address will change from the source link layer address to the target link layer address for IP-based mobility management protocol, and future incoming packets are then routed to the target radio.

[10.2.1] Need for single radio handover In a single radio handover, a mobile node can transmit on only one radio at a time. The needed peak transmission power capability for the mobile node is therefore smaller than if the mobile node were to transmit on both the source radio and the target radio simultaneously. In addition, the design of signal filter at the radio receiver is simpler if one radio is not transmitting when another radio is receiving. The lower peak power transmission and the simpler filter design for the mobile device both contribute to lower cost and longer battery life for the mobile device.

Such a lower cost design is appealing especially to the consumer market which is experiencing a proliferation of multiple radio interface devices using different network technologies.

[10.2.2] Relationship to other network standards Network standards organizations such as WiMAX Forum and 3GPP have considered single radio handover from/to their networks. With heterogeneous networks involved in a single radio handover, a media independent single radio handover standard can avoid duplicating the technology for the different networks and achieve higher volume production using the same technology. The resulting economy of scale can benefit both network service providers and vendors. This standard provides such a media independent single radio handover optimization and explains how the individual network standards may tailor it to the needs of their specific networks.

[10.2.3] Single radio versus dual radio handover A mobile device switches its link to the network during a handover process. The link is between a radio interface of the device and a point of attachment in a network. In the handover process, the radio interface may or may not change, whereas the point of attachment in the network also may or may not change to a different network technology.

If the radio interface remains the same, the handover is from one point of attachment to another point of attachment in the same network technology. This type of handover is sometimes called a horizontal

67

1

2

34

56789

101112131415

16171819

20

21222324252627

2829

3031323334353637

3839404142

4344


handover. While the source and target networks are of the same type of network technology, the source and target points of attachment may belong to the same or to different access networks, and different access networks may themselves connect through the same or different networks to the Internet. An example of the handover involving only one radio interface is the handover with one WiMAX interface from one WiMAX base station to another WiMAX base station. A single interface device can only perform a single radio handover, whereas a multiple-interface device has more options.

A multiple-interface device connecting with one interface to a network may change the connection using an interface to another network of a different network technology. This type of handover is a heterogeneous network handover, with which the multiple-interface device is able to exploit the availability of the different networks to enjoy more opportunities and choices of network connectivity.

When the multiple-interface device performs handover from a source radio interface to a target radio interface, it is possible to perform a dual-radio handover which has an overlap period utilizing both radios simultaneously. Such a make-before-break handover, in which there is an overlap period during which both radios are fully on, has the advantage of avoiding handover delay and packet loss. Yet the device must then possess the functional capability for both radios to operate simultaneously during the dual-radio handover. The resulting requirements to the device are higher peak power consumption and more demanding filtering of receiver signals.

An alternative is to perform a single radio handover, in which the mobile device is allowed to transmit on only one radio at any time. Because the power consumption of the transmitter is high compared with that of the rest of the radio, limiting to only one radio transmission at a time will reduce the peak power consumption of the device.

A dual-radio handover also typically requires a sharper receiver signal filter. When a radio is transmitting, the receiver of the same radio may or may not be receiving signals. If the receiver is not receiving signal (e.g., when time division duplex is used) there is no interference between the transmitter signal and the receiver signal. If the receiver is receiving signal (e.g., when frequency division duplex is used) the frequency bands for transmission for reception in the same network technology must not be too close to each other. Yet with two different network technologies, there is generally no coordination to sufficiently separate the transmission frequency of one technology from the receiver frequency of another technology.

An additional requirement may therefore be imposed on single radio handover, to disallow one radio from transmitting when another radio is receiving. This restriction will result in simpler filter design and therefore further reduction in the cost of the device.

Other than the above requirements, a single radio handover does not exclude both radios to be receiving simultaneously when no radio is transmitting.

With the restrictions on the single radio handover, certain operations that are possible in the dual-radio handover will not be possible. New functions and therefore new functional requirements (Clause 11.2) are needed in single radio handover. The single radio handover therefore differs from the dual-radio handover in that the device follows a different signaling procedure (Clause 11.5 and 11.6) whereas the network provides the needed network support with the different network configuration (Clause 11.3) to optimize the handover performance.

As with a dual-radio handover, a single radio handover among different access technologies also includes a L2 handover and a L3 handover. At the link layer, a handover involves a change of the layer 2 network link.

The L2 handover related signaling messages, which terminate at the L2 endpoints of the radio link, involve L2 interfaces in the different network technologies. It is also possible to use IP packets to deliver signaling messages, which are then independent of the network medium.

68

123456

789

10

11121314151617

18192021

22232425262728

293031

3233

343536373839

404142

434445


[10.2.4] Media independent single radio handover The concept of media independence applies to the single radio handover as it does to the dual-radio handover: Although the network technologies involving the two different L2 radio interfaces differ, it is possible to define generic signaling messages which are the same for different radio interfaces. A media independent handover may be accomplished in a media independent way, but the signaling messages for a single radio handover may differ from that for a dual-radio handover.

In a single radio handover using the media independent messages, the same transport possibilities as MIHF may apply. However, the MIHF is extended with the definitions of MICSAP and MICLSAP defined in the draft Std IEEE P802/D1.4 on architecture and are described in Clause 11.5.4 . With these extensions, the MIHF can be now described as a parallel control plane and is called media independent control function (MICF) in the draft Std IEEE P802/D1.4 .

The requirements for single radio handover are described next in Clause 11.2.

[10.3] Requirements of Single Radio Handover

The following are the lists of requirements to assist and facilitate the single radio handover among different radio access technology networks.

General Requirements:

The defined mechanisms shall be applicable to the single radio mobile station whether the station activates the dual receivers for both access networks or only a single receiver for the current access network.

The defined mechanisms shall be applicable to various interworking scenarios (e.g., WiMAX-3GPP, WiMAX-WiFi, 3GPP-WiFi, etc.)

The impact on existing access network architectures (3GPP, 3GPP2, WiMAX, WiFi) shall be minimized

Functional Requirements:

The mechanism shall enable delivery of radio measurement configuration and report information within a media-independent container for a single radio mobile station.

The mechanism shall define a tunneling mechanism to deliver the pre-registration messages.

The defined mechanism shall provide a way to control pre-registered states and deliver pre-registered contexts to enable single-radio operation.

The mechanism shall assist the mobile station to detect the presence of single radio enabling entity at the network before attaching to the target access network.

The mechanism shall assist the mobile station to select an appropriate target network and to obtain the corresponding required information from the access network.

The following capabilities shall be communicated between mobile station and single radio enabling entity at the network.

Supported radio access technologies (RATs) types on mobile station (3GPP, WiMAX, WiFi, 3GPP2, etc.)

69

123456

789

1011

12

13

1415

16

171819

2021

2223

24

2526

27

2829

3031

3233

3435

3637


Whether it supports single radio handover or dual radio handover

Applicable frequencies bands per access technology

Transmit Configuration (Single/Dual)

Receive Configuration (Single/Dual)

Measurement Gaps (UL/DL)

Whether the networks is allowing pre-registration

[10.4] Assumptions of Single Radio Handover

The following assumptions apply during the single radio handover:

[1.] While the source radio is transmitting, the target radio cannot transmit.

The mobile device can transmit on only one radio at a time. Prior to handover completion, the source radio link is used to support data transfer so that the priority to transmit is given to the source radio.

[2.] If sufficiently sharp signal filtering is lacking, then while the source radio is receiving, the target radio shall not transmit at a frequency close to the frequency of the source radio receiver.

[3.] If sufficiently sharp signal filtering is lacking, then while the source radio is transmitting, the target radio shall not receive at a frequency close to the frequency of the source radio transmitter.

[4.] The mobile node (MN) and the target network may communicate with each other via the source network using the source link.

It is possible that the source point of attachment and the target point of attachment may: (a) belong to the same access network, (b) belong to different access networks connecting to the same backhaul network, or (c) belong to different access networks connecting to different backhaul networks. In (a) and (b), the capability to communicate between the source radio and the target network usually does not utilize internetwork interfaces. In (c), the two networks may require internetwork addresses in order to be able to communicate with each other.

[10.5] SRHO Reference Model

The reference model for single radio handover from a source network to a target network is shown in Figure 11.1. Before handover, the MN uses its source interface to attach to the source point of attachment (PoA) in the source network through a source link. After handover, the MN will use its target interface to attach to the target PoA in the target network through a target link.

70

1

2

3

4

5

6

7

8

9

101112

1314

1516

1718

192021222324

25

26272829


Source network Target network

MN before handover

MN during handover

MN after handoverSource radio interface Target radio interface

Source link Target linkControl function

GW

Target PoASource PoA

GW


a distributed database with

Location management function

and network service information

Figure 11.1. Reference model for SRHO from a source network to a target network.

[10.5.1] Link configurationsLink configuration before handover:

[1.] Between the MN and source network: The source (radio) interface is connected to a source PoA in a source (access) network through a source link. This source link can exchange both data and signaling.

[2.] Between the MN and target network: Not specified.

Link configuration after handover:

[1.] Between the MN and source network: Not specified.

[2.] Between the MN and target network: The target (radio) interface is connected to a target PoA in a target (access) network through a target link. This target link can exchange both data and signal.

Link configuration during handover:

[1.] Between the MN and source network: The source (radio) interface remains connected to the source PoA in the source network. This source link can exchange both data and signal.

The control plane function in the MN and in the source network may use this source link to transport control messages.

[2.] Between the MN and target network: The link between the MN and the target network has a lower priority than the source link and communication may happen subject to meeting the constraints given in section 11.3.

The MN’s target radio can only transmit during the time when both the following conditions are met:

71

12

3

45

678

9

10

11

1213

14

1516

1718

192021

2223


[a.] the source radio is not transmitting

[b.] its transmission will not interfere with the source radio receiver such as by selecting frequencies sufficiently far from the frequencies at which the source radio is receiving or when sufficient signaling filter is available.

The MN’s target radio can expect to receive valid signals from the target PoA under any one of the following conditions:

[c.] the source radio is not transmitting, or

[d.] there is sufficient filtering from the source radio transmitter, or

[e.] the MN can select frequencies to avoid interference from its source transmitter.

The control plane function in the MN and in the target network may use this link to transport control messages only under the above conditions.

The source network and the target network may communicate with each other. For example, shortly after handover, packets delivered to the source network may be forwarded or tunneled to the target network.

[10.5.2] Information RepositoryThe Information Repository comprises a distributed database with location management and network service information. It must therefore be accessible from both the source and target networks with appropriate authorization. This authorization may, for roaming partners, require additional authentication and secure communication channels.

Location management requires location information for the networks and the MN. The location information for networks at a geographic location could be included as a list of the access networks or base stations that are within range at that geographic location. The location of the MN in the network would include the network location to which the MN is currently attached. That enables the network to estimate the geographic location of the MN when its exact location is not known. In addition to this location there may be an identity or a network address of the MN, which enables global reachability.

The network service information indicates the availability of candidate target networks and may be based on network operator service policy, roaming agreement between network service operators, the existing load versus capacity of the network, etc.

The network service information and the location information, such as the availability of candidate target network etc., are needed to make handover decisions. For example, the Information Repository may be implemented as part of a media independent information server (MIIS) or may be implemented as the Access Network Discovery and Selection Function (ANDSF) defined in 3GPP standard [3GPP TS23.402]. The distributed components of the Information Repository may be further organized to include localized database caches for improved performance. These localized caches may include information originally obtained from the Information Repository components of several roaming partners, or any other local information acquired by other means.

While location information and network service information are needed to enable handover decisions, some location information may also be needed in a mobility management protocol. It is then convenient to co-locate the location information for the mobility management protocol with the information needed for handover decision in the same database referred to as the distributed database of Information Repository in this reference model.

The type of information needed in the mobility management protocol depends on the mobility management protocol being used. For example, when mobile IP is used for the inter-network management protocol, the

72

1

234

56

7

8

9

1011

1213

1415161718

192021222324

252627

2829303132333435

3637383940

4142


location of the MN in the network is the care-of-address (CoA) and the identity of the MN is the home address in the home network of the MN. The location management information for mobile IP may then be the binding of the home address to the care-of-address. Furthermore, in accordance with existing procedures for subscriber management, mobility management may also require access to policy information controlling the allowable behavior of the mobile devices.

The distributed database of the Information Repository allows flexibility for different owners to manage their data separately. An example is for each network to host the master copy of the data that is most convenient to be managed by that network. The servers in the different networks constitute a distributed database of the Information Repository, organized so that each server knows which data belongs to which component of the Repository.

[10.5.3] Proxy GatewayThe Proxy function at the Gateway bridges the signaling between the MN and the target network via the source network. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may respond by signaling to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA. The control frames from the MN tunneled via the source network to the target network are consumed at the Proxy GW, which processes these control frames. Before replying to the control frames, the Proxy GW may communicate with the appropriate network entities in the target network to enable conducting any needed functions requested in the control frame. This gateway in the control plane may therefore proxy any control functions in general, including but not limited to pre-registration and proactive authentication of the MN. Such proxy function in the control plane resides in the gateway as shown in Figure 11.2, and its single radio handover control functions may be implemented using a part of the media independent point of service (PoS), as defined in this Clause. The Proxy GW often needs some location management and network service information to perform its function. It may cache the needed information.

The Proxy functions may be located at gateway router of the destination network. In the WiMAX network, these functions may make use of the Signal Forwarding Function (SFF).

In a target WiMAX network, the Proxy functions may be implemented in as an extension of the Signal Forwarding Function (SFF) and may reside at the ASN-GW.

In a target 3GPP network, the Proxy functions may be implemented as an extension of the Mobility Management Entity (MME).

In a target 3GPP2 network, the Proxy functions may be implemented in the HRPD-SFF and the existing functions of the Packet Control Function (PCF).

Control signals between the MN and the GW should be provided in a media independent manner. Such signaling may take advantage of the Media Independent messages defined in this specification. If a new message is to be used that is not defined here, it can be encapsulated with a media independent control frame header.

In a distributed mobility management design, each network has a mobility routing function. The mobility routing function enables a router to forward packets towards a mobile node according to the new location of a mobile node. The logical functions of mobility routing and of the Proxy may be co-located. The distributed mobility management architecture is then shown in Figure 11.2 in which the Information Repository contains the logical function of location management information only and the GW contains the logical function of mobility routing only.

73

12345

6789

10

1112131415161718192021222324

2526

2728

2930

3132

33343536

373839404142


Source network

GW


Target network

GW Home network

GW

MN MNFigure 11.2 An architecture of distributed mobility management.


[10.5.4] Media Independent Control FunctionA media independent control function (MICF) is shown in the control plane in Figure 11.3. It is a parallel control plane that provides control function for the MAC, PHY, and higher layer and has a service access point to each of these layers.

The Media Independent Service Access Point (MICSAP) interfaces between MICF and the higher layer. A TCP or UDP over IP packet can be encapsulated as a payload of an MIC frame. Conversely, an MIC frame can be encapsulated as a payload of a TCP or UDP over IP packet. The latter enables a MIC frame to be transported in a TCP or UDP over IP both within a network and across different networks.

The Media Independent Service Access Point (MICLSAP) interfaces between MICF and the MAC layer. A link-layer frame can be encapsulated as a payload of an MIC frame. Conversely, an MIC frame can be encapsulated as a payload of a MAC frame. The latter enables a MIC frame to be transported in a link-layer frame within a network.

The logical connection between the MICF in one network element to that in another network element in the same or different network is accomplished through the transport using TCP/UDP over IP. The media independent control function therefore supports cross-layer encapsulation to enable signaling between any layer in one network element and any layer in another network element. This capability will be used in the following to enable the link-layer frames in target radio to communicate with the target network.

[10.5.5] Single Radio handover Control FunctionTo prepare for handover, the MN’s target radio exchanges link-layer network entry PDUs with the target PoA at the target network. These network entry PDUs can be the same PDUs that would be exchanged if the target link were active. There is no guarantee that the target link is available during a single radio handover. A single radio handover control function (SRCF) is used here to enable the MN and the target PoA to exchange the network entry link-layer PDUs without depending on the existence of the target radio’s physical channel but with the help of the active source radio.

74

12

3

4567

89

1011

12131415

16171819

2021222324

25262728293031


In figure 11.3 the Single Radio handover Control Function (SRCF) in a multiple interface node is implemented using the media independent control function (MICF) in the control plane, which is defined in the 802-2012 architecture [IEEE P802-D1.4].

MICFTCP or UDP/IP

L2(2) L2(1)

PHY(2) PHY(1)MN’s

interface 2MN’s

interface 1

MIC

LSAP

MIC

SAP

MIC

LSAP

Figure 11.3. Single Radio handover Control Function (SRCF) of a multiple interface mobile node within the Media Independent Control Function (MICF).

The SRCF interfaces with the TCP or UDP / IP layer through the Media Independent Control Service Access Point (MICSAP), and the SRCF uses an assigned transport layer protocol’s port number. Therefore, the SRCF in this local node may exchange single radio handover control (SRC) frames with the SRCF of a remote node as long as there is TCP or UDP / IP connection between these two nodes. The SRC frames are processed by the SRCF in the destination of the TCP or UDP / IP packets carrying the SRC frames. The SRCF also interfaces with the link-layer (L2) through the media independent control link-layer service access point (MICLSAP). An L2 frame of a deactivated link (e.g., interface 2) may therefore be encapsulated with a SRCF header to constitute a SRC frame, which is then exchanged via an active link between the SRCF’s of a local and a remote node using the TCP or UDP / IP connection between the two nodes.

[10.5.6] Transport of L2 network entry PDU of the target radioThe transport of L2 network entry PDUs of the target radio between the MN and the Proxy GW in the target network is enabled by the MICLSAP to the SRCF. The communication between the SRCF in the MN and the SRCF in the Proxy GW. Figure 11.4 shows the transport of L2 frame of target interface using the communication between the SRCF in the MN and the SRCF in the GW. (a) shows the transport through using MICLSAP and MICSAP in control-plane representation. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s..

(a)

75

123

4567

89

1011121314151617

18192021222324

25


MICFTCP or

UDP/ IPTCP or

UDP/ IP

MICF

L2(2) L2(1) L2 L2

PHY(2) PHY(1) PHY PHY

MN’s target interface

MN’s source interface

GW

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2)

MICF MICFTCP or UDP / IP TCP or UDP / IP

L2(1) L2PHY(1) PHY

MN GW

Figure 11.4. Transport of L2 frame of target interface using the logical connection between the MICF in the MN and that in the GW, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

Lacking physical connection between the MN’s target radio and the target network during a single radio handover, a L2 network entry PDU of the target radio requires service from SRCF. Passing to the SRCF via the MICLSAP, the L2 PDU becomes the payload of an SRC frame in the media independent control function of the MN. Only the source radio is fully capable of transmitting and receiving TCP or UDP / IP packets to/from the source access network, which has IP connection to the target network through the Internet. There is therefore TCP or UDP / IP transport between the source radio and the Proxy GW of the target network via the source interface. Building on the TCP or UDP / IP layer through the MICSAP, the SRCF at the MN may therefore communicate with the SRCF at the Proxy GW.

[10.5.7] Communication between the MN and the target networkThe MN may only communicate with the target PoA subject to restrictions explained in Session 11.4.1 above. When it is not possible to use the target radio link, the source link can be used to provide (via SRCF) a reliable means of communication with the target network.

76

1

23

4

56789

1011121314151617

18192021


(1) The MN may signal directly with the target network Proxy GW if the MN knows the IP address of the target Proxy GW and does not need the help of the source network Proxy GW. In particular, the target network Proxy GW may proxy between the MN and the target PoA.

(2) The MN may signal first with the source network Proxy GW, which will assist the MN to communicate with the target network Proxy GW. In particular, the source network Proxy GW may proxy between the MN and the target Proxy GW.

[10.5.8] Communication between the MN and the target PoAThe MN needs to communicate eventually with the target PoA to prepare for handover by performing network access procedure with the target access network. The first part of this communication is the transport of TCP or UDP / IP packets to the Proxy GW, and the MN may query the Information Repository to find the IP address of the Proxy GW in order to use this TCP or UDP / IP transport. The second part of this communication depends on whether the target PoA supports MICF in the 802-architecture or whether it is a legacy PoA lacking such support.

If the target PoA supports MICF, the network entry L2 frame is encapsulated into SRC frames to forward to the target radio. Figure 11.5 shows the transport of the target radio L2 control frame as a payload of a media independent control frame between the MN and the Proxy GW via the source radio interface, in the absence of the target link. The Proxy GW bridges between the MN source link and the target PoA. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

MICF MICF MICF

TCP or UDP/ IP

TCP or UDP / IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP / IP

L2(2) frame L2(1)

Sourcelink

L2(1) L2 L2 L2 L2 L2(2) frame

No target link

L2(2) frame


MN’s target radio

MN’s source radio

Source PoA GW Target PoA MN’s target radio

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

(b)

77

123

456

789

10111213

141516171819

20

21

2223


L2(2) L2(2) L2(2) L2(2) L2(2)

MICF MICF MICF

TCP or UDP / IP


L2(1) L2 L2 L2


MN GW Target PoA

Figure 11.5 Transport of L2 frame of target interface via the GW using the logical connection at the MICF, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

The MN will need to acquire information of the candidate target PoA, e.g. by querying the Information Repository.

If MN knows the IP address of the target PoA, SRC frames may be exchanged between the SRCF in the MN and the SRCF in the target PoA using TCP or UDP / IP transport.

If MN does not know the IP address of the target PoA, it will need to have some means, such as the link-layer identification, of the target PoA in order to perform network entry procedure. The SRC frame is first sent as the payload of a TCP or UDP / IP packet destined to the Proxy GW as described in Clause 11.4.3. The SRC frame contains information for the target network to identify the target PoA. The Proxy GW will find out the IP address of the target PoA and use this address as the destination address of a TCP or UDP / IP packet containing the SRC frame as payload to forward to the target PoA. In other words, the Proxy GW can function like a proxy for the MN to send the target radio L2 network entry packets to the target PoA.

The reply by the target PoA is transported in a similar manner. If the target link were available, the target PoA will send a L2 message back to the target radio of the MN. Lacking this target link, this L2 message is passed through the MICLSAP to become the payload of an SRC frame.

If the target PoA had received the SRC frame from the MN, this reply SRC frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target PoA had received the SRC frame from the Proxy GW, the reply SRC frame will first use TCP or UDP / IP transport with an IP address destined to the Proxy GW. At the Proxy GW, the TCP or UDP / IP header is extracted at the MICSAP at the input interface of the Proxy GW to retrieve the SRC frame. The SRCF function will pass the SRC frame through the MICSAP at the output interface of the Proxy GW to form a new TCP or UDP / IP packet with an IP address destined to the MN.

If the target PoA’s are legacy PoA’s lacking MICF support, the Proxy GW will need other communication mechanism in order to proxy between the MN and the target PoA.

Figure 11.6 shows the transport of target radio L2 frames between the MN and the target network when the MN, the Proxy GW support single radio handover control function (SRCF), which is a media independent control function (MICF) in the IEEE 802-2012?? Architecture, but the target PoA are legacy PoA’s lacking MICF support.

Lacking MICF support in the target PoA, the Proxy GW and the target PoA will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network and is outside the scope of this standard.

The Proxy GW may then proxy between the MN and the target PoA using SRCF to communicate with MN and using some other control messages to communicate with the target network. These control messages

78

123

45

67

89

1011121314

151617

18192021222324

2526

27282930

31323334

3536


need to be comprehensive enough so that the Proxy GW may map the message contents exchanged with the MN with that exchanged with the target PoA in performing the proxy function.

Figure 11.6 shows the transport of the target radio L2 control frame as a payload of a media independent control frame between the MN and the Proxy GW via the source radio in the absence the target link. The GW communicates with the target PoA using other control messages in order to proxy between the MN and the target PoA. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

Crtl msg Crtl msg

MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1)

Srclink

L2(1) L2 L2 L2 L2 L2(2) frame

No target link

L2(2) frame


MN’s target radio

MN’s source radio

Source PoA GW PoA MN’s target radio

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2) L2(2) Control Control

MI CF MICF message message


TCP or UDP / IP

TCP or UDP / IP

L2(1) L2 L2 L2PHY(1) PHY PHY PHY

MN GW Target PoA

Figure 11.6 Transport of L2 frame of target interface to the GW which proxy between the MN and the target PoA, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

[10.6] Single radio handover overall processes

A single radio handover following the above reference model may consists of different handover processes and involve different information elements (Clause 11.8) and messages (Clause 11.9). Examples of handover are described in Clause 11.6. Figure 11.7 shows the single radio handover procedures consisting of 5 processes as described below.

79

12

34567

8

9

1011

12

131415

16

17

18192021


MN Source network



PoA






5. SRHO execution

Figure 11.7 – Overall Single Radio Handover Procedures.

1: Network discovery: determine whether or not there is a candidate target network available for handover? In network discovery, the MN queries the Information Repository to discover candidate networks and their handover policies. Such information includes whether candidate networks and MN support SRHO or not, and the presence of Proxy GW on the candidate network. Network discovery also allows the MN to acquire the corresponding system information blocks of candidate PoAs to perform the radio measurements.

2: The handover decision may involve the following

i. A handover trigger.

ii. Target network selection

iii. Proxy gateway discovery.

iv. Evaluating the handover benefit: the evaluation can be made by the MN or the network, e.g., based on parameters such as signal strength, cost, and operator policy.

3: Pre-registration includes pro-active authentication and establishing context (user identity, security, resource information) at the target network. With the help of Proxy GW, the MN can perform network entry procedures towards the target network while still retaining its data connection with the source network. Optionally, the pre-registration process may occur before the network selection process as in the case of WiMAX network.

4: Target link preparation: the MN and target network prepare the establishment of the target link. This process ascertains whether the target network has enough resources to accommodate the new link and may include performing resource reservation or admission control as well as confirming that the signal conditions are favorable enough to establish the target link. The MN’s target radio may perform limited signaling if possible within the constraints of peak power and signaling interface defined for single radio handover in this standard.

5: SRHO execution process. Here, the source link is disconnected, the target radio is activated, and the target link is established. The association of the network layer address to the link layer address will change

80

13

45678

9

10

11

12

1314

1516171819

202122232425

2627


from the source link layer address to the target link layer address for IP-based mobility management protocol, and future incoming packets are then routed to the target radio.

Insert new Clause 11.6

[10.7] Securing Single-Radio messages using PoS

There is a need for a simplified yet secure method for enabling movement between the network domains of roaming partners for single-radio smartphones and Internet enabled wireless devices. The proposal outlined in this document makes effective use of the Point of Service (PoS) as defined in numerous recent documents developed in the WiMAX Forum, 3GPP2, and IEEE. Using the PoS along with some signaling to transmit security information between roaming partners enables a low-latency, optimized handover for even the single-radio devices of interest in 802.21c.

[10.7.1] OverviewSecurity is indispensable to mobility management, but it is also typically quite time consuming because of reliance on distant authentication agents. Improving the security model and reducing authentication delay enables crucial improvements in handover performance. The PoS is a convenient and natural place to locate security functions, and roaming partners have in place agreements that can be used to beneficially establish the needed security agreements between different PoSes in partner networks. It is expected that in many cases the PoSes in partner networks must communicate by data paths that traverse the external Internet; in such cases, a secure communication channel must exist or must be established between the partner PoSes. It is out of scope for this document to specify exactly how the partner PoSes should establish secure communications, but this can be done by configuration when the partners enter into their roaming agreement. It can also be done on demand by using IKEv2 [IETF RFC 5996].

Figure 11.8: MN handover signaling for preregistration using SPoS

81

12

3

4

56789

10

1112131415161718192021

22

23

24

2526


Except for the initial network attach, by the time a MN enters a network, it can also have a security relationship with the PoS in that network by using the protocol in this document. For each visited network, this security relationship can be created on demand, enabled by signaling from another PoS. The PoS creating the visited security relationship can either be the MN's home PoS (HPoS, a PoS in MN's home network), or the PoS in the network previously visited by the MN. When the MN first attaches to one of the partner networks of the roaming partners, it is either the MN's home network, or a visited network. If the first attachment is to the MN's home network, then the MN is expected to already have a security association with HPoS; otherwise, the MN can bootstrap this security association using IKEv2 or standard AAA mechanisms or other proprietary means.

After initial attachment, there is signaling defined so that at all times the MN has a security association with the PoS in the network at its current point of attachment (PoA); the current network is termed the "source" network, and the PoS in the originating network is abbreviated as the SPoS. As the MN moves from one partner network to the next (i.e., to a new "target network"), the MN establishes or renews a security association with the PoS in the target network (i.e., the "TPoS"). When handover is completed, the TPoS naturally becomes the local PoS (SPoS).

For optimized handovers, a single-radio MN must perform as many protocol steps as possible for attachment to the target network, before actually tuning its radio to the access point of the target network. The entire reason for the existence of the PoS is to mediate signaling between the MN and a new target network while the MN is still radio contact with its current access network (i.e., to mediate "pre-registration"). The exact signaling steps included in the pre-registration process naturally depend on the requirements of the target network, and can be quite independent of the nature of the network (as above, the "source network") providing the current point of attachment for the MN.

Preregistration typically involves the following steps:

pre-authentication -- that is, authenticating the MN before it arrives in the target network,

address allocation -- one or more IP addresses to be used by the MN after it arrives in the target network.

data path setup -- establishing tunnels and forwarding entries for the MN in the target network, and

context establishment -- building all necessary state information such as QoS parameters and access permissions within target core network entities.

Each of these operations can be time-consuming, and if they had to be carried out after the MN had returned to the target network radio access, smooth handover might be impossible because of the dead time before packets could start flowing again (break-before-make). Moreover, each of the operations must be carried out securely to prevent hijacking attempts or mismanagement of target network resources. As long as handovers occur only between access points within the same operator network, it is often possible to guarantee that signaling packets are never exposed to attack. On the other hand, for access networks belonging to different operators, the data path between neighboring access points of originating and target access networks are more likely to traverse the Internet, potentially exposing preregistration signaling to attack.

In order to enable wider application of high-performance handovers and in particular preregistration signaling, security must be guaranteed for the control traffic. From above, we see that this signaling traffic is mediated by the PoS in each target network, which may be unknown to the MN until the need for handover has been determined. In such cases, for secure signaling, the MN needs to establish a security association with the target PoS. The process of establishing such a security association can be quite time

82

1

23456789

10

111213141516

17181920212223

24

25

2627

2829

3031

323334353637383940

4142434445


consuming and often expensive in processor cycles as well. This clause specifies a much faster and easier method for providing security associations as needed between the MN and the target PoS in any target network within the networks covered by the roaming partners.

The notation for PoS-based handover keys is listed in Table X.

Table X—Key notation for PoS-based handover

Khgw key between MN and HGW

Kspos key between MN and SPoS

Ktpos key between MN and TPoS; Ktpos is also referred to as the Media Independent Root Key (MIRK).

Khspos key between HPoS and SPoS

Khtpos key between HPoS and TPoS

Kstpos key between SPoS and TPoS

PNGspos pseudo-random number generator between MN and SPoS

PNGhspos pseudo-random number generator between HPoS and SPoS

PNGstpos pseudo-random number generator between SPoS and TPoS

As mentioned in the foregoing discussion, when the MN has determined that a handover is needed to a new network, we may assume that the MN has a security association with a service in its home network, here called the Home Gateway (HGW), based on a key Khgw . Interactions between the MN and its Home Gateway are out of scope for this protocol specification document. We also assume that, because of previous protocol operations, the MN has a current security association with the PoS in the originating network (SPoS). This security association is bidirectional and based on a share key Kspos.

Suppose the MN determines to move to a new network, the target network. Then the MN needs to preregister, and thus needs to use the PoS in target network (TPoS). Before it can do this, it needs to discover the address of TPoS and establish a security association with TPoS using Ktpos.

UE can make use of its existing security association with SPoS, because SPoS either already has, or can readily establish, a security association with TPoS. Suppose SPoS already has the required security association with TPoS. Then, when MN begins forwarding preregistration traffic to TPoS via SPoS, SPoS will provide MN and TPoS with a shared key, Ktpos, for use to protect the remainder of the MN's signaling traffic with TPoS. According to this proposal, the SPoS would thus forward the initial traffic to TPoS on behalf of the MN; the SPoS uses its own security relationship with TPoS to protect this initial preregistration signaling, and it also supplies the value of Ktpos to TPoS by adding a new extension to the preregistration traffic.

To send Ktpos to TPoS, SPoS provides the following payload within the TLVs of MIH_MNTN_SA_Estab Request, a new 802.21(c) message:

Payload = MNnetworkaccessid, Nonce, [Ktpos PNG⊕ stpos (MNnetworkaccessid, Nonce)]

Upon receiving this payload, TPoS calculates PNGstpos (MNnetworkaccessid, Nonce) and XORs the result to the third parameter of the payload to recover Ktpos.

Similarly, to send Ktpos to MN, SPoS provides the following payload within the TLVs of MIH_TNMN_SA_Estab Response, a new 802.21(c) message:

Payload = TPoSIdentifier, Nonce, [Ktpos PNG⊕ spos (TPoSIdentifier, Nonce)]

83

123

4

5

6

789

101112

131415

1617181920212223

2425

26

2728

2930

31


Upon receiving the payload, MN calculates PNGspos (TPoSaddr, nonce) and XORs the result to the third parameter of the payload to recover Ktpos.

Alternatively, for both of these messages, the entire contents could be encrypted by SPoS using the keys it has available with TPoS and MN respectively. MN is allowed to send more signaling information to TPoS via SPoS even after SPoS distributes the keys; SPoS continues to forward traffic back and forth between MN and TPoS as needed until both endpoints have used Ktpos to establish the required security association. For best performance and least likelihood of congestion at SPoS, MN and TPoS should begin to use direct signaling as soon as possible and thus bypass SPoS. Other structures for the message payloads are also possible, depending on requirements.

Once the handover is completed, TPoS "becomes" SPoS and the handover cycle can begin anew whenever MN determines the need for the next handover.

It is possible for SPoS to take a more active role to promote smooth handover. When the UE determines the need for handover, but does not already know the address of the TPoS for the intended target network, the MN can start the preregistration sequence by sending all the known information to the SPoS. Subsequently, the SPoS will provide the address of the TPoS to the MN along with Ktpos, just as described above. The exact nature of the information about TPoS provided by the MN is dependent on the radio access technology type (RAT) of the target network, and may be specified in detail in later revisions of this document. Other alternatives for identifying the target network access point are also envisioned. For MNs configured with ANDSF software, detailed information about TPoS, and the other entities within the target network can easily be made available. Note, however, that discovery and secure communication with TPoS may be easier than discovery and secure communication with ANDSF.

[10.7.2] Protecting communications between serving PoS and target PoSMIH_MNTN_SA_Estab and MIH_N2N_LL_Transfer messages exchanged between the serving PoS and the target PoS may require security protection. Furthermore, the target PoS may reject these messages from an unauthorized serving PoS. To protect the link between the serving PoS and the target PoS several approaches are possible.

An MIH SA (Security Association) defined in IEEE 802.21a can be used for protecting the communications between the serving PoS and the target PoS. In this case, the serving PoS acts as the initiating end-point of an MIH SA and the target PoS as the other end-point of the MIH SA. As specified in IEEE 802.21a, the MIH SA can be established using (D)TLS over MIH or EAP over MIH.

Other mechanisms such as IPSec and TLS over TCP can also be used for protecting the communications between the serving PoS and the target PoS. Details on such mechanisms are outside the scope of this standard.

11. Proxy Function

Insert new Clause 12

11.1 Introduction

The Gatewayproxy function bridges the signaling between the MN and the target network via the sourceoriginating network. In single radio handover, When the MN may signals to the Proxy GWproxy function as if signaling to the target a point of attachment (PoA), and the target PoA may respond by signaling to the Proxy GW which acts like a virtualas if signaling to the MN.

The Proxy GWfunction may also behave like a virtual PoA to signal with the target PoA. The control frames from the MN tunneled via the source network to the target network are consumed at the Proxy

84

12

3456789

1011

12131415161718192021

2223242526

27282930

313233

34

35

36

37383940

4142


GWfunction, which processes these control frames. Before replying to the control frames, the Proxy GWfunction may communicate with the appropriate network entities in the target network to enable conducting any needed functions requested in the control frame. This gatewayproxy in the control plane may therefore proxy any control functions in general, including but not limited to preregistration and proactive authentication of the MN.

Such proxy function in the control plane resides in the gateway as shown in Figure 11.2, and its single radio handover control functions may be implemented by the media independent point of service (PoS), as defined in this Clause. The Proxy GW often needs some location management and network service information to perform its function. It may cache the needed information.

The Pproxy functions may be located at gateway router of the destination network. In the WiMAX network, these functions may make use of the Signal Forwarding Function (SFF).




Control signals between the MN and the GWproxy function are providedimplemented in a media independent manner using the functions of, respectively, the originating network PoS and target PoS . Suchand the signaling uses MIH messages defined in this specification.

In a distributed mobility management design, each network has a mobility routing function. The mobility routing function enables a router to forward packets towards a mobile node according to the new location of a mobile node. The logical functions of mobility routing and of the Proxy may be co-located. The distributed mobility management architecture is then shown in Figure 11.210a in which the Information Repository contains the logical function of location management information only and the GWproxy contains the logical function of mobility routing only.

The Proxy GW works as a gateway to bridge the mobility signaling between a MN and a target network via the source network. The Proxy GW can transfer L2 messages to the target network via the source network, as shown in Figure 52 (b). Moreover, the Proxy GW can convert the L2 messages to other control messages for the target network as a proxy between the MN and the target PoA, as shown in Figure 53 (b).

If the Proxy GWfunction canmay transfer or convert interworking protocol messages such as ANQP or ANDSF messagesin the example described in Annex T, the Proxy GW can enhance cooperation with the network using other interworking protocols.

For the transfer function of the interworking protocol message, the “Gateway Service” means only encapsulation of interworking protocol messages into MIHF header on top of the TCP or UDP/IP layer. The transfer function of the interworking protocol message is simple, and thus can be implemented in the PoA without full function of MIH. Use of the transfer function can reduce complexity of the PoA.

For the conversion function of the interworking protocol messages to the other control messages, the Proxy GW can convert encapsulated interworking messages such as ANQP messages to the other control messages. The conversion function can enhance bridging of mobility signaling for the Proxy GW.

For transfer and conversion of the L2 messages or other interworking protocols, the SID for “Gateway Service” is defined as “5.” The “Gateway Service” reduces system complexity and increases compatibility to the other networks.

85

12345

6789

1011

1213

1415

1617

181920

212223242526

27282930

313233

34353637

383940

414243


[11.2] Communication between the MN and the target PoA < Was 11.1.4>

The MN needs to communicate eventually with the target PoA to prepare for handover by performing network access procedure with the target access network. The first part of this communication is the transport of TCP or UDP / IP packets to a target PoS (TPoS) in the target networkthe proxy function. ; the MN may (for example) query the Information Repository to find the IP address of the TPoS in order to use this TCP or UDP / IP transport. The second part of this communication depends on whether the target PoA supports MIHF in the 802-architecture or whether it is a legacy PoA lacking such support.

If the target PoA supports MIHF, the network entry L2 frame is encapsulated into an MIH frame to forward to the target radio. Figure 11.551 shows the transport of the target radio L2 control frame as a payload of a media independent control frame between the MN and the Proxy GWfunction via the source radio interface, in the absence of the target link. The Proxy GW bridges between the MN source link and the target PoA. Fig 12.2 shows the protocol stack resulting from the cross-layer encapsulation after passing through these two MIHFs.

L2(2) L2(2) L2(2) L2(2) L2(2)

MIH MIH MIH

TCP or UDP / IP


L2(1) L2 L2 L2


MN Proxy Target PoA

Figure 51: Transport of L2 frame of target interface via MIH using the logical connection at the Target PoS to MIH-capable target PoA, showing the resulting protocol stack.

If MN cannot send L2 frames to the target PoA, it will rely on a Proxy function of the MIHF in order to perform network entry procedure. As before, the SRC frame is sent as the payload of a TCP or UDP / IP packet destined to the Proxy GW as described above. The SRC frame contains information for the target network to identify the target PoA. The Proxy GW will handle target-side communications with the target PoA.

Figure 152.3 shows the transport of the target radio L2 control frame as a payload of a media independent control frame between the MN and the Proxy GW via the source radio in the absence the target link. The GW communicates with the target PoA using other control messages in order to proxy between the MN and the target PoA. The figure shows the protocol stack resulting from the cross-layer encapsulation after passing through the Proxy GW.

86

1

234567

89

10111213

14

151617

1819202122

2324252627


L2(2) control frame

L2(2) control frame

Control message

Control message

MI H MIHTCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP


MN Proxy function WiMAXBS

Figure 152.3 Transport of L2 frame of target interface to the GW which proxies between the MN and the target PoA, showing the resulting protocol stack.

11.2 Transfer of Control Message

As extension of L2 message transfer in Figure 51, the transfer of control message, as shown in Figure 573, can be considered. If the corresponding network entity supports “Proxy Function,” the PoA can only encapsulate control messages with the MIHF header using MIH_CTRL_Transfer messages. The PoA uses the encapsulated messages to communicate with the corresponding network entity. The PoA only encapsulates control messages but does not need full function of the MIH. It means the implementation of the PoA can be simplified. Use cases and extension of the Proxy Function is included in Annex T.

Figure 573. Proxy Function for Control Message Transfer

87

1

234

5

6

789

101112

13

1415


12. Gateway Service

[11.3] Introduction

The Gateway bridges the signaling between the MN and the target network via the source network. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may respond by signaling to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA. The control frames from the MN tunneled via the source network to the target network are consumed at the Proxy GW, which processes these control frames. Before replying to the control frames, the Proxy GW may communicate with the appropriate network entities in the target network to enable conducting any needed functions requested in the control frame. This gateway in the control plane may therefore proxy any control functions in general, including but not limited to pre-registration and proactive authentication of the MN. Such proxy function in the control plane resides in the gateway as shown in Figure 11.2, and its single radio handover control functions may be implemented using a part of the media independent point of service (PoS), as defined in this Clause. The Proxy GW often needs some location management and network service information to perform its function. It may cache the needed information.

The Proxy functions may be located at gateway router of the destination network. In the WiMAX network, these functions may make use of the Signal Forwarding Function (SFF).




Control signals between the MN and the GW should be provided in a media independent manner. Such signaling may take advantage of the Media Independent messages defined in this specification. If a new message is to be used that is not defined here, it can be encapsulated with a media independent control frame header.

In a distributed mobility management design, each network has a mobility routing function. The mobility routing function enables a router to forward packets towards a mobile node according to the new location of a mobile node. The logical functions of mobility routing and of the Proxy may be co-located. The distributed mobility management architecture is then shown in Figure 11.2 in which the Information Repository contains the logical function of location management information only and the GW contains the logical function of mobility routing only.

The Proxy GW works as a gateway to bridge the mobility signaling between a MN and a target network via the source network. The Proxy GW can transfer L2 messages to the target network via the source network, as shown in Figure 11.552 (b). Moreover, the Proxy GW can convert the L2 messages to other control messages for the target network as a proxy between the MN and the target PoA, as shown in Figure 11.653 (b).

If the Proxy GW can transfer or convert interworking protocol messages such as ANQP or ANDSF messages, the Proxy GW can enhance cooperation with the network using other interworking protocols.

88

1

2

3

456789

10111213141516

1718

1920

2122

2324

25262728

293031323334

3536373839

4041

L2(2) L2(2) L2(2) L2(2)MIH

L3 + L4

L2(1) L2PHY(2) PHY(1) PHY PHY(2)

MN Target PoA

L2(2) MIH

L2PHY

for Target PoA

L3 + L4 L3 + L4

MIH

L2(2) L2(2) Control ControlMI MIF message message


TCP or UDP / IP

TCP or UDP / IP


MN GW Target PoA


For the transfer function of the interworking protocol message, the “Gateway Service” means only encapsulation of interworking protocol messages into MICF header on top of the TCP or UDP/IP layer. The transfer function of the interworking protocol message is simple, and thus can be implemented in the PoA without full function of MIH. Use of the transfer function can reduce complexity of the PoA.

For the conversion function of the interworking protocol messages to the other control messages, the Proxy GW can convert encapsulated interworking messages such as ANQP messages to the other control messages. The conversion function can enhance bridging of mobility signaling for the Proxy GW.

For transfer and conversion of the L2 messages or other interworking protocols, the SID for “Gateway Service” is defined as “5.” The “Gateway Service” reduces system complexity and increases compatibility to the other networks.

[11.4] L2 Message Transfer (SID=5, AID=1)

As shown in Table L.1, if AID is equal to one, the L2 messages are exchanged between the MN and the target PoA through the source network.

If the target PoA supports MICF and MN does not know the IP address of the target PoA, the Proxy GW functions like a proxy for the MN to send the target radio L2 network entry packets to the target PoA, as shown in Figure 11.552 (b). If the target PoA does not support MICF, the Proxy GW communicates with the target PoA using other control messages in order to proxy between the MN and the target PoA, as shown in Figure 11.653 (b).

[11.5] Interworking Protocol Delivery (SID=5, AID>1)

As extension of L2 message transfer, the transfer of interworking protocol message, as shown in Figure 12.157, can be considered. If the target network entity supports “Gateway Service,” the PoA can only encapsulate interworking protocol messages with the MICF header using the SID, “5.” The PoA uses the encapsulated messages to communicate with the target network entity. The PoA only encapsulates

89

1234

567

89

10

11

12

13

1415

1617181920

21

22232425


interworking protocol messages without full function of the MIH. It means the implementation of the PoA can be simplified.

Interworking ProtocolMessage


MICF hdr(SID=5,AID>1)

TCP or UDP/ IP hdr

TCP or UDP/ IP hdr

L2 hdr L2 hdr

PHY hdr PHY hdr

Interworking Protocol Message


TCP or UDP/ IP hdr

L2 hdr

PHY hdr

MN Target Network

Entity


TCP or UDP/ IP hdr

L2 hdr

PHY hdr

PoA

Figure 12.157: . Gateway Service for Interworking Protocol Message Transfer

As extension of L2 message conversion, the interworking protocol message conversion as shown in Figure 12.258, can be considered. If the other network entity does not support “Gateway Service,” the Proxy GW converts the interworking protocol message into the control message for the other network entity. The control message can be a different interworking protocol message. The Proxy GW functions as a proxy with other interworking protocols to communicate with other interworking network entity, and thus enhances mobility signaling.


Control Message


TCP or UDP/ IP hdr

TCP or UDP/ IP hdr

L2 hdr L2 hdr

PHY hdr PHY hdr

Control Message

TCP or UDP/ IP hdr

L2 hdr

PHY hdr

MN GW Target Network

Entity




TCP or UDP/ IP hdr

TCP or UDP/ IP hdr

L2 hdr L2 hdr

PHY hdr PHY hdr


TCP or UDP/ IP hdr

L2 hdr

PHY hdr

PoA

Figure 12.258.: Gateway Service for Interworking Protocol Message Conversion

90

12

34

56789

10

11

12

1314

15


[11.5.1] Examples of Interworking Protocol Delivery: ANQP DeliveryIf the MN wants to receive ANQP messages of access network information from the Media Independent Information Server, the WLAN AP (Access Point) can perform as a proxy between the MN and information server as shown in Figure 12.359 (a). The WLAN AP only encapsulates or decapsulates messages from the MN or the information server as shown in Figure 12.359 (b). The WLAN AP does not need to have all functions of the MIH. It means the WLAN AP as a proxy of MN can be implemented with simple MIH function with SID, “5.”

MN Media Independent Information Server

IEEE 802.11u

GAS (ANQP)

IEEE 802.21c

(SID=5, AID=2)

WLAN AP (as a proxy of MN )

(a) ANQP Transfer using the WLAN AP as a Proxy

GAS (ANQP) Message

ANQP Message

MICF hdr(SID=5, AID=2)

TCP or UDP/ IP hdr

L2 hdr

IEEE 802.11PHY PHY hdr

ANQP Message

MICF hdr(SID=5, AID>=1)

TCP or UDP/ IP hdr

L2 hdr

PHY hdr

GAS (ANQP) Message

IEEE 802.11PHY

MN WLAN AP (as a proxy of MN )

Media Independent Information Server

(b) Protocol Stacks for ANQP Transfer

Figure 12.359.: ANQP Transfer from Media Independent Information Server

If the information server does not support MIH functions, the WLAN AP cannot communicate with the information server using the MIH protocol messages. In this case, the Proxy GW is needed as a proxy between the WLAN AP and the information server. As shown in Figure 12.460 (a), the WLAN AP only encapsulates or decapsulates messages from the MN, and Proxy GW converts the messages from the WLAN AP to the other interworking protocol messages, such as ANDSF messages. Hence, the information server can communicate with the WLAN AP via the Proxy GW. To explain the ANQP conversion, the protocol stacks for MN, WLAN AP, Proxy GW, and information server are shown in Figure 12.460 (b).

91

1234567

8

9

1011

12

13

1415

16

17

18

19202122232425


MN WLAN AP (as a proxy of MN)

GWOther Information

Server

IEEE 802.11u

GAS (ANQP)

IEEE 802.21c

(SID=5, AID=2)

Other Interworking Protocol

(E.g. ANDSF message)

(a) ANQP Conversion using the Proxy GW

ANQP Message OtherInterworking Message


TCP or UDP/ IP hdr

TCP or UDP/ IP hdr

L2 hdr L2 hdr

PHY hdr PHY hdr

OtherInterworking Message

TCP or UDP/ IP hdr

L2 hdr

PHY hdr

GAS (ANQP) Message

ANQP Message


TCP or UDP/ IP hdr

L2 hdr

IEEE 802.11PHY PHY hdr

GAS (ANQP) Message

IEEE 802.11PHY

MNWLAN AP

(as a proxy of MN) GWOther Information

Server

(b) Protocol Stacks for ANQP Conversion

Figure 12.460.: ANQP Conversion from Media Independent Information Server

Annex A

(informative)

Bibliography

Note to editor: iInsert these normative references in appropriate order.

[B1] IEEE 802 standard, “IEEE Draft Standard for Local and metropolitan Area Networks: overview and Architecture, P802-D1.4, June 2012.

[B2] 3GPP, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access,” TS23.401.

[B3] 3GPP, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses,” TS23.402

[B4] WiMAX Forum Network Architecture: Stage 3 Detailed Protocols and Procedures T33-001-R015

[B5] WiMAX Forum, “Single radio interworking,” WMF-T37-011-R016v01.

[B6] WiMAX Forum, “WiFi-WiMAX Interworking,” WMF-T37-010-R016v01.

92

12

3

45

6

7

8

9

10

11

12

13

1415

161718

1920

21

22

23


[B7] 3GPP2, “WiMAX-HRPD Interworking: Core network aspects,” X.S0058.

[B8] IETF RFC 6153 (2011-02), DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery

Annex B

Annex C

Annex D

Annex E

Insert following Data Type to Table E.1.MIH_LINK_SAP_primitive IEEE Std 802.16 C_SAP IEEE Std 802.16 M_SAPLink_Action Link_RX_ON N/A N/A

Annex F

(normative)

F.1

F.2

F.3 Derived data types

F.3.1

F.3.2

F.3.3

F.3.4 Data types for link identification and manipulation

Note to the editor: Table F.4 is presented in the 802.21 document and the number “5” of LINK_PARAM_GEN is added inserted in this document.Insert number 5 in the description of LINK_PARAM_GEN in Table F.4

MODIFY FOLLOWING DATA TYPE TO TABLE F.4

Data type name Derived form Description

93

1

23

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

202122

23

24


LINK_PARAM_GEN UNSIGNED_INT(1) 5: Average power consumption in active state- the parameter value is represented as an UNSIGNED_INT(2). its measure is mW.Value Range: 0 – 216-1 mW6-255: (Reserved)

Insert Following Data Type to Table F.5

Note to the editor: Table F.5 is presented in the 802.21 document

ADD FOLLOWING DATA TYPE TO TABLE F.5

Action name DescriptionLink_RX_ON Turn on only the receiver of the radio

94

1

2

3

4

5


F.3.5

F.3.6

F.3.7

F.3.8 Data types for information elements

F.3.9

F.3.10

F.3.11

F.3.12

Change Table F.13 as follows:

Table F.13 – Data types for information elements

Data type name Derived from Definition

95

123456789

101112131415161718

19

20

21

22

23

24

25

26

27

28


NET_CAPS BITMAP(32) These bits provide high level capabilities supported on a network.Bitmap Values: Bit 0: Security – Indicates that some level of security is supported when set. Bit 1: QoS Class 0 – Indicates that QoS for class 0 is supported when set Bit 2: QoS Class 1 – Indicates that QoS for class 1 is supported when set Bit 3: QoS Class 2 – Indicates that QoS for class 2 is supported when set; Otherwise, no QoS for class 2 support is available. Bit 4: QoS Class 3 – Indicates that QoS for class 3 is supported when set; Otherwise, no QoS for class 3 support is available. Bit 5: QoS Class 4 – Indicates that QoS for class 4 is supported when set; Otherwise, no QoS for class 4 support is available. Bit 6: QoS Class 5 – Indicates that QoS for class 5 is supported when set; Otherwise, no QoS for class 5 support is available. Bit 7: Internet Access – Indicates that Internet access is supported when set; Otherwise, no Internet access support is available. Bit 8: Emergency Services – Indicates that some level of emergency services is supported when set; Otherwise, no emergency service support is available. Bit 9: MIH Capability – Indicates that MIH is supported when set; Otherwise, no MIH support is available. Bit 10: SRHO Capability – Indicates that SRHO is supported when set; Otherwise, no SRHO support is available. Bit 10 11–31: (Reserved)

IP_ADDR TRANSPORT_ADDR Indicates the IP address family, either 1 (for IPv4) or 2 (for IPv6).IP_TUNN_MGMT BITMAP(16) Indicates the supported tunnel management protocol on PoS.

Bitmap Values: Bit 0: IPSec Bit 1–15: (Reserved)

FQDN OCTET_STRING The fully qualified domain name of a host as described in IETF RFC 2181.

F.3.13

F.3.14

F.3.15

F.3.16 Data type for security

Note to the editor: Table F.24 is presented in 802.21a document

ADD Insert Following Data Types into Table FOLLOWING DATA TYPE TO TABLE F.24

Data Derived from DefinitionLL_FRAMES OCTET_STRING One or more link-layer frame(s).

(Note: LL_FRAMES is defined in 802.21a-2012, but its Description needs to be overridden to cover both 802.21a and 802.21c use cases.

NAI OCTET_STRING Represents a Network Access Identifier as in IETF RFC 4282 TPoS_ID CHOICE(IP_ADDR, MIHF_ID) Represents the identifier of the target PoS

96

1

2

3

4

5

6

7

8


F.3.17 Data types for delivery of control messages

Table F.25- Data types for delivery of control messages

Data type name Derived form Definition

CTRL_PRTC_MSGSSEQUENCE(

CTRL_TYPE,CTRL_MSGS

)

Represent which control messages are delivered. CTRL_TYPE represents a type of control messages. CTRL_MSGS represents control messages to be delivered.

CTRL_TYPE UNSIGNED_INT(1) A type to represent control messages.

0: ANQP

1~122: Reserved for other controls

123~255: Reserved for vendor specific uses

CTRL_MSGS OCTET_STRING Represents control messages to be delivered.

Annex G

(normative)

Insert following Information element identifiers values into Table G.1

Table G.1—Information element identifier values

Name of information element or container IE Identifier

IE_PoS_IP_ADDR 0x10000206 IE_PoS_TUNN_MGMT_PRTO 0x1000020907 IE_PoS_FQDN 0x1000020A8 IE_CONTAINER_PoS 0x10000303

IE_PoS_IP_ADDR is already defined in IEEE 802.21a-2012.

97

1

2

3

4

5

6

7

8

9

10


Annex H

Annex I

Annex J

Annex K

Annex L

(normative)

Note to Editor: Insert the following rows to Table L.1

MIH messages AIDMIH messages for Service Management

MIH_LL_TransferMIH_Prereg_Xfer 10MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer 11

MIH messages for Command ServiceMIH_IF_PreReg_Ready 132MIH_TNMN_SA_Estab 13MIH_MNTN_SA_Estab 14

MIH messages for Gateway ServiceMIH_CTRL_TransferMIH_L2Message_Delivery 1MIH_ANQP_Delivery 2Reserved for other interworking protocols From 23 to 500Reserved for vendor specific area From 501 to 1023

Note to editor: Insert the following TLVs to Table L.2

TLV type Name TLV type value Data typeMedia Independent Root Key 78 KEY

Media Specific Root Key 79 KEY

Network Access Identifier 80 NAI

TPoS Identifier TLV 801 TPoS_ID

Annex M

Annex N

(informative)

98

1

2

3

4

5

6

7

89

10

11

12

13


Change the number N.6 in 802.21a to N.5

N.65 Termination Phase

Insert N.6 after N.5

99

1

2

3


N.1

N.2

N.3

N.4

N.5

[N.6] Use of MIH_LL_TransferMIH_Prereg_Xfer and MIH SA_Estab messages for the exchange of L2 frames, including Optimized SA Establishment

N.5.1 OPoS Distributing MIRK to TPoS and MN

[N.6.1] This first call flow shows how the identity is bootstrapped by TPoS, how the MIRK0 is sent by the SPoS to the TPoS and how the MSPMK0 is installed into the TPoS (AAA). Notice that the SPoA does not conceptually play any role in the signal handling, even though signals exchanged between the MN and the SPoS are transmitted through the SPoA.

[N.6.2]

0 Note to the editor, this footnote should not appear in the final version. MIRK stands for MN´s media independent root key.

0 Note to editor, this footnote should not appear in the final version. MSPMK stands for MN´s media specific root key.

100

1

2

3

4

5

67

8

910111213

14

123


Figure N-1 -- OPoS Distributing MIRK to TPoS and MN

101

12


The signaling diagram illustrated in Figure N.6 1 shows the following steps

[1.] MIH_TNMN_SA_EstabPrereg_Xfer.request: the MN user application asks to initiate preregistration to a suitable target PoA (TPoA)

[2.] MIH_TNMN_SA_EstabPrereg_Xfer Request: MN’s MIHF transmits request to Serving PoSOriginating PoS (SPoSOPoS)

[3.] MIH_TNMN_SA_EstabPrereg_Xfer.indication: SPoSOPoS presents MN’s Request to SPoSOPoS MIH user application.

[4.] MIH_N2N_MNTN_SA_EstabPrereg_Xfer.request: issued by SPoSOPoS MIH user containing information to enable TPoS to compute MIRK (i.e., Ktpos)

[5.] MIH_N2N_MNTN_SA_EstabPrereg_Xfer Request: relayed by SPoSOPoS to TPoS, possibly encapsulated with IPSec

[6.] MIH_ N2N_MNTN_SA_EstabPrereg_Xfer.indication: presented to TPoS MIH user for extraction of Ktpos and computation of MNmsrk

1.[7.] TPoS MIH application provides MIRK to AAA for future authentication purposes

102

12

3

45

67

89

1011

1213

1415

16


2.[8.] TPoS MIH user computes MNmsrk from MIRK and sends appropriate LL frames to TPoA for key distribution and any other preregistration tasks.

[9.] MIH_N2N_MNTN_SA_EstabPrereg_Xfer.response: TPoS MIH user initiates message for SPoSOPoS MIH user containing MNnetworkaccessid.

[10.] MIH_N2N_MNTN_SA_EstabPrereg_Xfer Response: TPoS relays message to SPoSOPoS containing MNnetworkaccessid.

[11.] MIH_N2N_MNTN_SA_EstabPrereg_Xfer.confirm: SPoSOPoS presents message to SPoSOPoS MIH user containing MNnetworkaccessid.

[12.] MIH_TNMN_SA_EstabPrereg_Xfer.response: SPoSOPoS MIH user initiates message to MN user application via SPoSOPoS containing MNnetworkaccessid, MIRK.

[13.] MIH_TNMN_SA_EstabPrereg_Xfer Response: SPoSOPoS relays message to MIHF at MN containing MNnetworkaccessid, MIRK.

[14.] MIH_TNMN_SA_EstabPrereg_Xfer. confirm: MIHF at MN relays message to MN user application containing MNnetworkaccessid, MIRK.

3.[15.] MN user application extracts MIRK, computes MNmsrk, continues any necessary preregistration activities

4. MN continues with additional preregistration signaling

The call flow illustrated in Figure N-1 shows how the identity is bootstrapped by TPoS, how the MIRK is sent by the OPoS to the TPoS and how the MSPMK is installed into the TPoS (AAA). Notice that the SPoA does not conceptually play any role in the signal handling, even though signals exchanged between the MN and the OPoS are transmitted through the SPoA.

N.5.2 OPoS relays addtional PreRegistration signaling

In the second one, the authentication between the MN and the TPoA is depicted. MNmsrk is installed on the TPoS in the bootstrap process in the first figure. After that, TPoS holds the MNmsrk and uses it for media-specific authentication in the next figure. Therefore, another MNmsrk transfer is not needed in the next figure.

103

12

34

56

78

910

1112

1314

1516

17

18192021

22

23242526


Figure N-2 -- OPoS relays addtional PreRegistration signaling

The signaling diagram illustrated in Figure N.6 1 shows the following steps

1. MIH_Prereg_Xfer.request: the MN user application asks to continue preregistration to a suitable target PoA (TPoA)

2. MIH_Prereg_Xfer Request: MN’s MIHF transmits request to Originating PoS (OPoS)

3. MIH_Prereg_Xfer.indication: OPoS presents MN’s Request to OPoS MIH user application.

4. MIH_N2N_Prereg_Xfer.request: issued by OPoS MIH user relaying MN additional preregistration signaling to TPoS

5. MIH_N2N_Prereg_Xfer Request: relayed by OPoS to TPoS, possibly encapsulated with IPSec

6. MIH_ N2N_Prereg_Xfer.indication: presented to TPoS MIH user for continuation of preregistration signaling

7. TPoS relays preregistration signaling to TPoA

8. TPoA contacts AAA for authentication

9. TPoA responds with additional preregistration signaling for MN

104

12

3

4

56

7

8

910

11

1213

14

15

16


10. TPoS MIH user relays preregistration signaling from TPoA, possibly including LL frames, to be transmitted to OPoS.

11. MIH_N2N_Prereg_Xfer.response: TPoS MIH user transmits message for OPoS MIH user.

12. MIH_N2N_Prereg_Xfer.confirm: OPoS presents message to OPoS MIH user.

13. MIH_Prereg_Xfer.response: OPoS MIH user transmits message to MN user application.

14. MIH_Prereg_Xfer Response: OPoS relays message to MIHF at MN.

15. MIH_Prereg_Xfer. confirm: MIHF at MN relays message to MN user application.

16. MN user application continues any necessary preregistration activities based on signaling received from TPoA.

In the second oneFigure N-2, the authentication between the MN and the TPoA is depicted. MNmsrk is as previously is installed on the TPoS, shown in the bootstrap process in the first figure; . After that, TPoAS holds the MNmsrk and uses it for media-specific authentication in the next figure. Therefore, another MNmsrk transfer is not needed in the next figure.

105

12

3

4

5

6

7

89

10111213

14

15


N.5.3[N.6.3] OPoS key distribution when OPoS is same as TPoS

In the case the MN can directly contact the TPoS (this case is the same as when SPoS and TPoS are the same entity) the following example diagram applies for authentication at the TPoA:

106

1

23


Figure N-3 OPoS key distribution when OPoS is same as TPoS

The signaling diagram illustrated in Figure N.6 3 shows the following steps.

107

1

23

4

5


[1.] MIH_TNMN_SA_EstabPrereg_Xfer.request: the MN user application asks to initiate preregistration to a suitable target PoA (TPoA)

[2.] MIH_TNMN_SA_EstabPrereg_Xfer Request: MN’s MIHF relays request to Serving PoSOriginating PoS (SPoSOPoS)

[3.] MIH_TNMN_SA_EstabPrereg_Xfer.indication: SPoSOPoS presents MN’s request to SPoSOPoS MIH user application.

[4.] SPoSOPoS MIH user provides MIRK to AAA for future authentication purposes at TPoA

[5.] SPoSOPoS MIH user computes MNmsrk from MIRK and sends appropriate LL frames to TPoA for key distribution and any other preregistration tasks.

[6.] MIH_TNMN_SA_EstabPrereg_Xfer.response: SPoSOPoS MIH user initiates message to MN user application via SPoSOPoS containing MNnetworkaccessid, MIRK. The response message informs MN that TPoS is the same as SPoSOPoS.

[7.] MIH_TNMN_SA_EstabPrereg_Xfer Response: SPoSOPoS relays message to MIHF at MN containing MNnetworkaccessid, MIRK.

[8.] MIH_TNMN_SA_EstabPrereg_Xfer. confirm: MIHF at MN relays message to MN user application containing MNnetworkaccessid, MIRK.

1.[9.] MN user application extracts MIRK, computes MNmsrk, continues any necessary preregistration activities

When the MN can directly contact the TPoS (this case is the same as when OPoS and TPoS are the same entity) , the diagram shown in Figure N-3 and the numbered steps apply for authentication at the TPoA:

N.5.4 OPoS relay preregistration when OPoS is same as TPoS

Finally when the SPoS and TPoS are the same entity and the MIH_LL_Transfer is used to exchange L2 frames (no authentication related), the following example diagram can be applied:

108

12

34

56

7

89

101112

1314

1516

1718

192021

22

2324


Figure N-4 OPoS relay preregistration when OPoS is same as TPoSFinally when the OPoS and TPoS are the same entity and the MIH_Prereg_Xfer is used to exchange L2 frames (no authentication related), the diagram shown in Figure N-4 can be applied:

109

1

2

3

45

6


Annex O

Add Insert new Annex P

Annex P MN’s Network Access Identifier Format

(i(Informative)

Insert

An MNnetworkaccessid attribute (of type NAIMIHF_ID), which is optionally contained in MIH_LL_TransferMIH_Prereg_Xfer.response, MIH_LL_TransferMIH_Prereg_Xfer.confirm, MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.response, and MIH_N2N_LL_TransferMIH_N2N_Prereg_Xfer.confirm primitives, is assigned by the target PoS to the MN such that the MN can use the value of this attribute as the EAP peer identity for subsequent reactive pull key distribution or optimized pull key distribution from the target PoS. The username part of the NAIMIHF_ID carried in this attribute may contain the identifier of the MSRK used between the MN and the target PoS, and the realm part of the NAIMIHF_ID may contain a Fully Qualified Domain Name of the target PoS.

Add Insert new Annex Q

Annex Q Network discovery for single radio handover

(Informative)

Insert

The single radio handover has limitation in network discovery because of interference and power consumption problem of the network interfaces. This means that a mobile node is not free to use the target radio when the source radio is operating. Considering the problem, there are possible network discovery methods as follows. Three methods are described in the following:

[Q.1] Network discovery: listening to the target linkListening to the target link

The first method is listening to the target link. When the mobile node can listen to the target link and signal strength of the source link decrease, the mobile node can scan candidate links and then can find the target link. Moreover, periodic scanning for the target link can support network discovery. This method serves the accurate detection of the target links, but the mobile node shall may follow the assumptions in Section 11.31.4.

110

1

2

3

4

5

6

789

101112131415

16

17

18

19

20212223

24

2526272829


SRCF

Candidate Link

Source Link

(3) Link_Detected.indication: Detect a new link

Candidate PoA

(2) Network Detection Related Message(e.g. Beacon in WLAN)

MN Side

(1) Link_Action.confirm

Figure Q.1- Network discovery listening to the target link

Figure Q.1 shows the case for network discovery listening to the target link with extended Link_Action. In (0) and (1), SRCFSR-MIHF turns on only the receiver of the candidate radio using Link_Action message with newly defined action name which is LINK_RX_ON. In (2), the candidate link listens to network detection related messages, such as beacon of IEEE 802.11 network. In (3), candidate link informs detection of a new link using Link_Detected message. This method serves the accurate detection of the target links, but the mobile node may follow the assumptions in Section 1.4.

[Q.2] Network discovery: uUsing location information

The second method is network discovery based on the location information of the mobile node. This mechanism finds the target network using GPS (Global Positioning System) location information and interacting with the IR (Information Repository) explained in Section 11.4.2. This mechanism will avoid

111

1

23

456789

10

111213


the interference explained above. Although location information from global positioning system (GPS) can enhance network detection, the GPS also dissipates power in the mobile node which is often limited by the power capability of its battery. Also, the GPS systems performance is often degraded with the weak signals in an indoor environment. In the event of GPS signal loss, such as when entering a building, the last known location could be used. Moreover, it can be a huge load to the network to invoke a network information repository to support network discovery for the mobile nodes which are equipped with the GPS.

IR SRCFMN SRCF

(1) MIH_Get_Information request: Send the location information (QUERIER_LOC) of the MN

(2) MIH_Get_Information response : Respond with network access information (IE_NETWORK_TYPE, IE_NET_FREQUENCY_BANDS, etc.)

Figure Q.2- Network discovery using location information

Figure Q.2 shows the case for network discovery using location information of the MN with QUERIER_LOC. In (1), the MN SRCFSR-MIHF sends the location information (QUERIER_LOC) of the MN through MIH_Get_Information request message. In (2), the IR SRCFSR-MIHF responds with network access information elements, such as IE_NETWORK_TYPE and IE_NET_FREQUENCY_BANDS.

[Q.3] Network discovery: usingUsing user schedule information

The third method is user schedule based network discovery. The multi-radio MN can possess a lightweight software that includes schedule program, e.g., Google calendar, and many users are already managing their schedule through the use of a schedule program such as Google calendar. The schedule program usually shows the user’s location at the dedicated time. Based on user’s location information, the multi-radio MN

112

123456

7

8

910

11121314

15

16

17181920


can determine its available networks and the target radio. For example, if Mr. Sam is scheduled to stay meeting room from 9AM to 11AM, the Mr. Sam’s multi-radio MN can discover a WLAN AP at the meeting room. In order to enhance this network discovery mechanism, the scheduled information can include the network information including information about link type, link identifier, link availability, link quality as defined in this standard. Using the network information, the mobile node can perform network discovery. If the MN knows the network information, it can try to connect to the network using that information.

This method can be supplemented by an information repository that is populated with location and network information. The network discovery is then achieved through use of the information repository combined with schedule of time and location from the MN, which may or may not have GPS information.

In addition, records of user’s network access can enhance network discovery with or without the Information Repository. For example, if Mr. Sam had visited “Room #1” and accessed WLAN at some time. When Mr. Sam is scheduled to visit “Room #1” again, the recorded network information will show that Mr. Sam’s MN can connect the WLAN using the recorded WLAN access information.

IR SRCFMN SRCF

(1) MIH_Get_Information request: Send the scheduled location information (QUERIER_LOC) of the MN

(2) MIH_Get_Information response : Respond with network access information (IE_NETWORK_TYPE, IE_NET_FREQUENCY_BANDS, etc.)

Figure Q.3- Network discovery using user schedule information

Figure Q.3 shows the case for network discovery using location information of the MN with QUERIER_LOC. In (1), the MN SRCFSR-MIHF sends the scheduled location information (QUERIER_LOC) of the MN through MIH_Get_Information request message. In (2), the IR SRCFSR-MIHF responds with network access information elements, such as IE_NETWORK_TYPE and IE_NET_FREQUENCY_BANDS.

113

1234567

89

10

11121314

15

1617

1819202122


Add new Annex R

[Annex R] Examples of SRHO

(Informative)

Insert

Q.1 WLAN to WiMAX single radio handover

Q.1.1 Reference model

The general reference model as it applies to WLAN to WiMAX single radio handover is illustrated in Figure R.1.

WiMAXCSN

WiMAX ASN

MN during handoverOriginating radio interface

Originating PoA

Originating link

ASN-GW

WIF SFF

BS

Rx

AP

Proxy


W3

R3

R3+

AAA

DHCP

R6

Target PoA

Figure R.1 WLAN to WiMAX single radio handover reference model.

Q.1.1.1 Functional entities:

a) The Information Repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification, or in another information repository defined elsewhere, such as the ANDSF.

b) The WiMAX Signal Forwarding Function (SFF) is defined in a WiMAX Forum standard. It may be co-located at the ASN-GW. Otherwise, SFF may communicate with the ASN-GW using the R6 interface.

c) The Proxy GW function is implemented in the combined functions of ASN-GW and WiMAX SFF, in the WiMAX network. When the MN signals to the Proxy as if signaling to a point of attachment (PoA), the target PoA may correspondingly signal to that Proxy acting in the role of a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA.

114

1

2

3

4

5

6

78

910

11

12

13

141516

171819

20212223


d) The WiFi Interworking Function (WIF) is defined in WiMAX Forum.

Q.1.1.2 Reference Points:

a) W3 interface between the WLAN AP and the WIF is defined in WiMAX Forum [WMF-T37-010-R016v01].

b) Rx interface between the MS and the WiMAX SFF/Proxy is defined in WiMAX Forum [WMF-T37-010-R016v01].

c) R3 interface between the WiMAX CSN and ASN is defined in WiMAX Forum [WMF-T37-010-R016v01].

d) R3+ interface between the WIF and AAA and also DHCP in the WiMAX CSN is defined in WiMAX Forum [WMF-T37-010-R016v01].

e) R6 interface between the WiMAX SFF/Proxy and ASN GW is defined in WiMAX Forum [T33-001-R015].

Q.1.2 Transport of WiMAX L2 control frames between MN and the WiMAX ASN

The single radio handover signal is similar to that of the generalized case described in Clause 5.5. The transport of the WiMAX L2 frame is described below.

Q.1.2.1 T ransport with MIH-capable devices

Figure R.2 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the co-located Proxy GW/ASN-GW and the target WiMAX BS all support single radio handover in. The WiMAX radio L2 control frame is transported as a payload of a MIH frame between the MN and the WiMAX network via the source WLAN link at the left. The Proxy /ASN-GW combination bridges between the MN and the target WiMAX BS.

115

1

2

34

56

78

910

1112

13

1415

16

1718192021

22

23

24

25

26

27

2829


L2(2) L2(2) L2(2) L2(2) L2(2)MIH MIH MIH

TCP or UDP / IP


L2(1) L2 L2 L2PHY(2) PHY(1) PHY PHY PHY PHY(2)

MN SFF / ASN-GW WiMAX BS

Figure R.2. Transport of WiMAX L2 frame of target interface via the SFF/ASN-GW combination using the logical connection at the MIH.

The MIHF interfaces with the TCP or UDP / IP layer through the Media Independent Handover Service Access Point (MIH_SAP). The source WLAN link enables the TCP or UDP / IP connection between the MN and the WLAN network, which may then connect to the WiMAX ASN through the Internet or the WiMAX CSN. Therefore media independent handover (MIH) frames may be exchanged between the MIHF in the MN and the MIHF in the Proxy /ASN-GW and/or the WiMAX BS in the WiMAX network using TCP or UDP / IP transport.

An L2 frame is encapsulated with a MIHF header to constitute a MIH frame, which is exchanged between the MN and the target WiMAX BS or the Proxy /ASN-GW.

The MN will query the Information Repository to find the candidate target WiMAX BS. Based on the information from the Information Repository, the MN will then have some means to identify the target WiMAX BS, such as the link-layer address in order to perform network entry procedure to the WiMAX network using L2 packets.

The Information Repository needs to know the IP address of the Proxy /ASN-GW, so that the MN and the Proxy /ASN-GW can exchange MIH frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target WiMAX BS.

If the MN knows the IP address of the target WiMAX BS, it will send the MIH frame to the MIHF in the target WiMAX BS using TCP or UDP / IP transport.

If the MN does not know the IP address of the target WiMAX BS, it will need another identifier, such as the link-layer address, to identify the target WiMAX BS. The MIH frame is first sent as the payload of a TCP or UDP / IP packet destined to the Proxy /ASN-GW as described in Section 12. The SRC frame contains information for the target WiMAX network to identify the target WiMAX BS. The Proxy /ASN-GW will find out the IP address of the target WiMAX BS and use this address as the destination address of a TCP or UDP / IP packet containing the MIH frame as payload to forward to the target WiMAX BS.

The reply sent by the target WiMAX BS is transported in a similar manner. If the target WiMAX link were available, the target WiMAX BS would send a L2 message back to the MN using this WiMAX link. Lacking this target link, this L2 message is passed as the payload of an MIH frame.

If the target PoA had received the MIH frame from the MN, the reply MIH frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target WiMAX BS had received the MIH frame from the Proxy /ASN-GW, the reply SRC frame will first use TCP or UDP / IP transport with an IP address destined to the Proxy. At the Proxy /ASN-GW, the TCP or UDP / IP header is extracted at the MIH_SAP at the input interface of the Proxy /ASN-GW to retrieve the MIH frame. The MIHF will pass the MIH frame through the MIH_SAP at the output interface of the Proxy /ASN-GW to form a new TCP or UDP / IP packet with an IP address destined to the MN.

116

134

56789

10

1112

13141516

171819

2021

222324252627

282930

31323334353637


Q.1.2.2 Transport without MIH-capable target WiMAX BS

Figure R.3 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the Proxy /ASN-GW support single radio handover. Yet the target WiMAX BS are legacy WiMAX BS’s lacking such support. The target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WiMAX network via the source WLAN link at the left. The SFF/ASN-GW proxies between the MN and the target WiMAX BS using MIH to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS.

L2(2) control frame

L2(2) control frame

Control message

Control message

MI H MIH R6+ R6+TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP


MN SFF/ ASN-GW WiMAXBS

Figure R.3. Transport of WiMAX L2 frame of target interface to the SFF/ASN-GW which proxies between the MN and the target PoA.

Lacking the single radio handover support in the WiMAX BS, the Proxy /ASN-GW and the target WiMAX BS will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (R6+) of the R6 interface and is outside the scope of this standard.

The Proxy /ASN-GW may then proxy between the MN and the target WiMAX BS using MIH to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the Proxy /ASN-GW may map the message contents exchanged with the MN with that exchanged with the target WiMAX BS in performing proxy function.

117

1

234567

8

9

10

11

12

13

14

15

16

171819

2021222324

2526272829


Q.1.2.3 Transport without MIH-capable devices

Figure R.4 shows the packet used in the transport of WiMAX L2 frames between the MN and legacy WiMAX ASN where the single radio handover is supported neither between the MN and the Proxy /ASN-GW nor between the Proxy /ASN-GW and the target WiMAX BS. The Proxy /ASN-GW proxies between the MN and the target WiMAX BS using an extension of Rx interface to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS.

L2(2) control frame

L2(2) control frame

Control message

Control message

Rx+ Rx+ Rx+ R6+ R6+ R6+TCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPL2(1) L2 L2 L2

PHY(1) PHY PHY PHYMN SFF / ASN-GW WiMAX BS

Figure R.4. Protocol stack showing the transport of WiMAX L2 frame of target interface to the SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the co-located Proxy GW/ASN-GW will need certain mechanism to communicate with each other, such as an extension (Rx+) of the Rx interface. The Proxy /ASN-GW and the target WiMAX BS will also need certain mechanism to communicate with each other, such as an extension (R6+) of the R6 interface.

The co-located Proxy GW/ASN-GW may then proxy between the MN and the target WiMAX BS using the Rx+ to communicate with MN and using the R6+ to communicate with the target WiMAX BS.

Both Rx+ and R6+ are outside the scope of this standard.

Q.1.3 WLAN to WiMAX Single Radio Handover processes

The single radio handover processes are: network discovery, preregistration, handover decision, WiMAX link preparation, and these processes are described in the following:

1) 1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. These query and reply messages may use the IP connectivity of the source link.

The Information Repository provides the MN with information about available networks and handover policy. It will also inform the MN whether the WiMAX ASN available in the neighborhood supports SRHO, and system information blocks of candidate PoAs to perform radio measurements.

2) 2: Preregistration includes proactive authentication and establishing context (user identity, security, resource information) at the target network. With the help of the Proxy, the MN can perform network entry procedures towards the target network while retaining its data connection with the source network.

118

1

23456

7

89

10

11121314

1516

17

18

19

2021

2223242526

27282930

31323334


The MN and the target network performs proactive authentication via the source network. The exchange of handshake messages for authentication is communicated as follows:

a) The authentication messages are exchanged between the MN and the ASN-GW, which is the authenticator. These messages are L2 control frame messages in the target (WiMAX) network, which could have been exchanged via the target (WiMAX) link if the target link were available. When the target link is not available, the transport of the L2 control frame between the MN and the Proxy GW/ASN-GW is through the source (WiFi) network as described in Clause 11.2.

b) The ASN-GW/Proxy GW processes the SRC frame containing the L2 authentication message and may consult the AAA in the WiMAX CSN through the R3 interface.

c) The ASN-GW maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the Proxy /ASN-GW, the preregistration is performed for the ASN network, which may have multiple PoA’s. When the MN attaches to a different target BS, it will use the existing registration context if the Proxy /ASN-GW already has this registration context.

d) The ASN-GW/Proxy combination also constructs control messages to communicate with the target WiMAX BS. In terms of exchange of these control messages, the ASN-GW/Proxy behaves like a virtual WiMAX BS located in the WiMAX network to communicate with the MN. Such control messages are equivalent to those in the handover from one BS to another BS within the same network. Therefore control messages may reuse those messages between the originating PoA and target PoA within the same network to prepare the handover of a MN within the same network.

e) For messages from the ASN-GW/Proxy GW to the MN, they are tunneled to the MN via the WiFi network. To the target WiMAX BS, the ASN-GW/Proxy acts like a virtual WiMAX radio interface.

f) The MN may pre-register with the WiMAX network, using the same interface and transport mechanism as that in proactive authentication.

3) 3: Handover Decision process:

a) (1) The handover may be triggered by a need such as degradation of source link quality or cost considerations.

b) (2) A WiMAX network is selected.

c) (3) A determination is made on whether there is benefit to handover. The decision can be taken by the MN or the network and may be based on the parameters such as signal strength, cost, and operator policy.

4) 4: WiMAX link preparation:

Before L3 handover occurs, the target link may perform preparation processes at L2, such as signal strength measurement and power level adjustment.

A target BS is selected. The MN may use the target interface to check the broadcast messages from the target BS to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.31.4.

119

12

345678

910

1112131415

16171819202122

232425

2627

28

2930

31

323334

35

3637

383940


The WiMAX will check with the target BS and target ASN-GW to reserve the radio channels needed for MN to attach to the WiMAX network. The channels needed for MN to operate in active or idle mode are assigned depending on whether the source radio was in the active or idle mode.

5) 5: SRHO execution process. In this process, the WiFi link is disconnected, the WiMAX radio is activated, and the WiMAX link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WiFi link layer address to the WiMAX link layer address, and future incoming packets are then routed to the WiMAX radio.

Q.2 3GPP to WiMAX single radio handover


The general reference model as it applies to 3GPP to WiMAX single radio handover is illustrated in Figure R.5.

3GPP network WiMAX ASN

MN during handover

MIIS orANDSF

Source radio interface

Source PoATarget PoA

Source link

PDN-GW

BS

R9

eNB

S2a

S14

ASN-GWSFF

Proxy

R6

Figure R.5 3GPP to WiMAX single radio handover reference model.


a) The Information repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification but may also be other information repository defined elsewhere, such as the ANDSF.

b) The WiMAX Signal Forwarding Function (Proxy GW) is defined in WiMAX Forum standard. It may co-locate at the ASN-GW. Yet in the event that it is not co-located there, it may communicate with the ASN-GW using the R6 interface defined in the WiMAX Forum standard.

c) The Proxy GW function is implemented in the combined functions of ASN-GW and WiMAX Proxy GW, which are defined in the WiMAX network. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA.

d) The PDN Gateway (P-GW) is defined in 3GPP [3GPP TS23.401].

120

1234

5678

9

10

1112

1314

15

16

171819

202122

2324252627

28



a) S2a reference point between the P-GW and the ASN GW is defined in 3GPP [3GPP TS23.402].

b) R9 interface between the MS and the WiMAX Proxy GW is defined in WiMAX Forum [WMF-T37-011-R016v01].

c) R6 interface between the WiMAX Proxy GW and ASN GW is defined in WiMAX Forum [T33-001-R015].

d) S14 reference point between the MS and the ANDSF is defined in 3GPP [3GPP TS23.402].

Q.2.2 Transport of WiMAX L2 control frames between MN and the WiMAX ASN with MIH-capable devices

The single radio handover signal is similar to that of the generalized case described in Clause 5.5. The transport of the WiMAX L2 frame is described below.

Q.2.2.1 Transport with MIH-capable devices

Figure R.6 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the co-located Proxy GW/ASN-GW and the target WiMAX BS all support single radio handover. The WiMAX radio L2 control frame is transported as a payload of a MIH frame between the MN and the WiMAX network via the source 3GPP link at the left. The Proxy /ASN-GW combination bridges between the MN and the target WiMAX BS.

L2(2) L2(2) L2(2) L2(2) L2(2)

MIH MIH MIH

TCP or UDP / IP


L2(1) L2 L2 L2


MN SFF / ASN-GW WiMAX BS

Figure R.6. Transport of WiMAX L2 frame of target interface via the SFF/ASN-GW using the logical connection at the MIH.

The MIHF interfaces with the TCP or UDP / IP layer through the Media Independent Handover Service Access Point (MIH_SAP). The source 3GPP link enables the TCP or UDP / IP connection between the MN and the 3GPP network, which may then connect to the WiMAX ASN through the Internet or the WiMAX CSN. Therefore media independent handover control (MIH) frames may be exchanged between the SR-MIHF in the MN and the MIHF in the Proxy /ASN-GW and/or the WiMAX BS in the WiMAX network using TCP or UDP / IP transport.

An L2 frame is encapsulated with a SR-MIHF header to constitute a MIH frame, which is exchanged between the MN and the target WiMAX BS or the Proxy GW/ASN-GW.


121

1

2

34

56

7

89

1011

12

1314151617

1819

202122

232425262728

2930

31323334


The Information Repository need to know the IP address of the Proxy /ASN-GW, so that the MN and the Proxy /ASN-GW can exchange MIH frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target WiMAX BS.

If the MN knows the IP address of the target WiMAX BS, it will send the MIH frame to the MIHF in the target WiMAX BS using TCP or UDP / IP transport.

If the MN does not know the IP address of the target WiMAX BS, it will need at least somethinganother identifier, such as the link-layer address, to identify the target WiMAX BS. The MIHMIH frame is first sent as the payload of a TCP or UDP / IP packet destined to the Proxy /ASN-GW as described in Section 12. The MIH frame contains information for the target WiMAX network to identify the target WiMAX BS. The Proxy /ASN-GW will find out the IP address of the target WiMAX BS and use this address as the destination address of a TCP or UDP / IP packet containing the MIH frame as payload to forward to the target WiMAX BS.

The reply by the targetThe reply sent by the target WiMAX BS is transported in a similar manner. If the target WiMAX link were available, the target WiMAX BS would send a L2 message back to the MN using this WiMAX link. Lacking this target link, this L2 message is passed as the payload of an MIH frame.

If the target PoA had received the MIH frame from the MN, the reply MIH frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target WiMAX BS had received the MIH frame from the Proxy /ASN-GW, the reply MIH frame will first use TCP or UDP / IP transport with an IP address destined to the Proxy /ASN-GW. At the Proxy /ASN-GW, the TCP or UDP / IP header is extracted at the MIH_SAP at the input interface of the Proxy /ASN-GW to retrieve the MIHrame. The MIHF function will pass the MIH frame through the MIH_SAP at the output interface of the co-located Proxy GW/ASN-GW to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Q.2.2.2 Transport without MIH-capable target WiMAX BS

Figure R.7 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the Proxy /ASN-GW support single radio handover. Yet the target WiMAX BS are legacy WiMAX BS’s lacking such support. The WiMAX target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WiMAX network via the source 3GPP link at the left. The Proxy GW/ASN-GW proxies between the MN and the target WiMAX BS using MIH to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS.

122

123

45

6789

101112

131415

16171819202122

23

24252627282930

31

32

33

34

35


L2(2) control frame

L2(2) control frame

Control message

Control message

MI H MIH R6+ R6+TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP



Figure R.7. Transport of WiMAX L2 frame of target interface to the SFF/ASN-GW which proxies between the MN and the target PoA.

Lacking the single radio handover support in the WiMAX BS, the Proxy GW/ASN-GW and the target WiMAX BS will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (R6+) of the R6 interface and is outside the scope of this standard.

The Proxy/ASN-GW may then proxy between the MN and the target WiMAX BS using MIHF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the Proxy/ASN-GW may map the message contents exchanged with the MN with that exchanged with the target WiMAX BS in performing proxy function.


Figure R.8 shows the transport of WiMAX L2 frames between the MN and legacy WiMAX ASN where the single radio handover is supported neither between the MN and the Proxy/ASN-GW nor between the Proxy/ASN-GW and the target WiMAX BS. The Proxy/ASN-GW proxies between the MN and the target WiMAX BS using an extension of R9 interface to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS.

L2(2) control frame

L2(2) control frame

Control message

Control message

R9+ R9+ R9+ R6+ R6+ R6+TCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPL2(1) L2 L2 L2


Figure R.8. Protocol stack showing the transport of WiMAX L2 frame of target interface to the SFF/ASN-GW which proxy between the MN and the target PoA.

123

1

234

56789

1011121314

15

1617181920

212223


The MN and the Proxy/ASN-GW will need certain mechanism to communicate with each other, such as an extension (R9+) of the R9 interface. The Proxy/ASN-GW and the target WiMAX BS will also need certain mechanism to communicate with each other, such as an extension (R6+) of the R6 interface.

The Proxy/ASN-GW may then proxy between the MN and the target WiMAX BS using the R9+ to communicate with MN and using the R6+ to communicate with the target WiMAX BS.

Both R9+ and R6+ are both outside the scope of this standard.

Q.2.3 3GPP to WiMAX Single Radio Handover processes

The single radio handover processes are: network discovery, preregistration, handover decision, WiMAX link preparation, and these processes are described in the following:

1) 1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. These query and reply messages may use the IP connectivity of the source link. The message exchange between the MN and the ANDSF may use the S14 reference point between the MN and the ANDSF as defined in 3GPP. These messages are carried in IP packets and may therefore use the IP connectivity at the source link.

The ANDSF provides the MN with information about available networks and handover policy. It will also inform the MN whether the WiMAX ASN network available in the neighborhood supports SRHO, the presence of Proxy, and system information blocks of candidate PoAs to perform radio measurements.



a) The authentication messages are exchanged between the MN and the ASN-GW, which is the authenticator. These messages are L2 control frame messages in the target (WiMAX) network, which could have been exchanged via the target (WiMAX) link if the target link were available. When the target link is not available, the transport of the L2 control frame between the MN and the Proxy/ASN-GW is through the source (3GPP) network as described in Clause 11.6.2.1.The ASN-GW/Proxy processes the frame containing the L2 authentication message and may consult the AAA in the WiMAX CSN through the R3 interface.

b) The ASN-GW maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the Proxy/ASN-GW, the preregistration is performed for the ASN network, which may have multiple PoA’s. When the MN attaches to a different target BS, it will use the existing registration context if the Proxy/ASN-GW already has this registration context.

c) The ASN-GW/Proxy combination also constructs control messages to communicate with the target WiMAX BS. In terms of exchange of these control messages, the ASN-GW/Proxy behaves like a virtual WiMAX BS located in the WiMAX network to communicate with the MN. Such control messages are equivalent to those in the handover from one BS to another BS within the same network. Therefore control messages may reuse those between the source PoA and target PoA within the same network to prepare the handover of a MN within the same network.

124

123

45

6

7

89

10111213141516

17181920

21222324

2526

27282930313233

3435363738

394041424344


d) For messages from the ASN-GW/Proxy to the MN, they are tunneled to the MN via the 3GPP network. To the target WiMAX BS, the ASN-GW/Proxy acts like a virtual WiMAX radio interface.

e) The MN may pre-register with the WiMAX network, using the same interface and transport mechanism as that in proactive authentication.



b) (2) A WiMAX ASN network is selected.


4) 4: WiMAX link preparation:


A target BS is selected. The MN may use the target interface to check the broadcast messages from the target BS to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.31.4.


5) 5: SRHO execution process. In this process, the WiFi link is disconnected, the WiMAX radio is activated, and the WiMAX link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the 3GPP link layer address to the WiMAX link layer address, and future incoming packets are then routed to the WiMAX radio.

Q.3 WiMAX to WLAN single radio handover


The general reference model as it applies to WiMAX to WLAN single radio handover is illustrated in Figure R.9.

125

123

45

6

78

9

101112

13

1415

161718

192021

22232425

26

27

2829


WLAN ANWiMAX ASN

MN during handoverOriginating radio interface

Originating PoA

Originating link

ASN-GW

RyBS

WiMAXCSN


R3

AAA

DHCP

AP

proxy

Target PoA

R6

R3

AR

WiFi-SFF

WIF

Rz

W3

W1

Figure R.9 WiMAX to WLAN single radio handover reference model.


a) The Information repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification but may also be other information repository defined elsewhere, such as the ANDSF.

b) The WiFi Interworking Function (WIF) is defined in WiMAX Forum. It may co-locate at the access router (AR). In the event that it is not co-located there, the WIF communicates with the AR through the W3 interface.

c) The Proxy function is implemented in the combined functions of WiFi Interworking Function (WIF) and WiFi Proxy, which are defined in the WiMAX network. When the MN signals to the Proxy as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy which acts like a virtual MN. The Proxy may also behave like a virtual PoA to signal with the target PoA. The WiFi Signal Forwarding Function (Proxy) is defined in WiMAX Forum standard. It may co-locate at the access router (AR). In the event that it is not there, the WiFi-Proxy communicates with the AR through the W1 interface.

Q.3.1.2 Interfaces:

a) W1 interface between the WLAN AR and the WiFi Proxy is defined in WiMAX Forum [WMF-T37-010-R016v01].

b) W3 interface between the WLAN AR and the WIF is defined in WiMAX Forum [WMF-T37-010-R016v01].

c) Ry interface between the MS and the WiFi Proxy is defined in WiMAX Forum [WMF-T37-010-R016v01].

d) R3 interface between the WiMAX CSN and ASN is defined in WiMAX Forum [WMF-T37-010-R016v01].

126

1

23

4

567

89

10

11121314151617

18

1920

2122

2324

2526


e) R3+ interface between the WIF and AAA and also DHCP in the WiMAX CSN are defined in WiMAX Forum [WMF-T37-010-R016v01].

f) R6 interface between the WiMAX Proxy and ASN GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

Q.3.2 Transport of WLAN L2 control frames between MN and the WLAN AN

The single radio handover signal is similar to that of the generalized case described in Clause 5.5. The transport of the WLAN L2 frame is described below.


Figure R.10 shows the transport of WLAN L2 frames between the MN and the WLAN AN when the MN, the Proxy/WIF/AR and the target WLAN AP all support single radio handover. The WLAN radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WLAN network via the source WiMAX link at the left. The Proxy/WIF/AR bridges between the MN and the target WLAN AP.

L2(2) L2(2) L2(2) L2(2) L2(2)

MIH MIH MIH

TCP or UDP / IP


L2(1) L2 L2 L2


MN SFF / WIF / AR WiFi AP

Figure R.10. Transport of WLAN L2 frame of target interface via the SFF/WIF/AR using the logical connection at the MIH.

The SR-MIHF interfaces with the TCP or UDP / IP layer through the Media Independent Handover Service Access Point (MIH_SAP). The source WiMAX link enables the TCP or UDP / IP connection between the MN and the WiMAX network, which may then connect to the WLAN AN through the Internet or the WiMAX CSN. Therefore media independent handover control (MIH) frames may be exchanged between the MIHF in the MN and the MIHF in the Proxy/WIF/AR and/or the WLAN AP in the WLAN network using TCP or UDP / IP transport.

An L2 frame is encapsulated with a SR-MIHF header to constitute a MIH frame, which is exchanged between the MN and the target WLAN AP or the Proxy/WIF/AR.

The MN will query the Information Repository to find the candidate target WLAN AP. Based on the information from the Information Repository, the MN will then have some means to identify the target WLAN AP, such as the link-layer address in order to perform network entry procedure to the WLAN network using L2 packets.

The Information Repository need to know the IP address of the Proxy/WIF/AR, so that the MN and the Proxy/WIF/AR can exchange MIH frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target WLAN AP.

If the MN knows the IP address of the target WLAN AP, it will send the MIH frame to the SR-MIHF in the target WLAN AP using TCP or UDP / IP transport.

127

12

34

5

67

8

910111213

14

151617

181920212223

2425

26272829

303132

3334


If the MN does not know the IP address of the target WLAN AP, it will need at least somethinganother identifier, such as the link-layer address, to identify the target WLAN AP. The MIH frame is first sent as the payload of a TCP or UDP / IP packet destined to the Proxy/WIF/AR as described in Section 12. The MIH frame contains information for the target WLAN network to identify the target WLAN AP. The Proxy/WIF/AR will find out the IP address of the target WLAN AP and use this address as the destination address of a TCP or UDP / IP packet containing the MIH frame as payload to forward to the target WLAN AP.

The reply by the targetThe reply sent by the target WLAN AP is transported in a similar manner. If the target WLAN link were available, the target WLAN AP would send a L2 message back to the MN using this WLAN link. Lacking this target link, this L2 message is passed as the payload of an MIH frame.

If the target PoA had received the MIH frame from the MN, the reply MIH frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target WLAN AP had received the MIH frame from the Proxy/WIF/AR, the reply MIH frame will first use TCP or UDP / IP transport with an IP address destined to the Proxy/WIF/AR. At the Proxy/WIF/AR, the TCP or UDP / IP header is extracted at the MIH_SAP at the input interface of the Proxy/WIF/AR to retrieve the MIH frame. The SR-MIHF function will pass the MIH frame through the MIH_SAP at the output interface of the Proxy/WIF/AR to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Q.3.2.2 Transport without MIH-capable target WLAN AP

Figure R.11 shows the transport of WLAN L2 frames between the MN and the WLAN AN when the MN, the Proxy/WIF/AR support single radio handover. Yet the target WLAN AP are legacy WLAN AP’s lacking such support. The WLAN target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WLAN network via the source WiMAX link at the left. The Proxy/WIF/AR proxies between the MN and the target WLAN AP using MICF to communicate with the MN and using an extension of R6 interface to communicate with the target WLAN AP.

128

1234567

89

10

11121314151617

18

192021222324

25

26

27

28

29

3031


L2(2) control frame

L2(2) control frame

Control message

Control message

MI CF MICF R6+ R6+TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

L2(1) L2 L2 L2PHY(1) PHY hdr PHY hdr PHY

MN SFF/ WIF –AR WLAN AP

Figure R.11. Transport of WLAN L2 frame of target interface to the SFF/WIF-AR which proxy between the MN and the target PoA.

Lacking single radio handover support in the WLAN AP, the Proxy/WIF/AR and the target WLAN AP will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network and is outside the scope of this standard.

The Proxy/WIF/AR may then proxy between the MN and the target WLAN AP using SR-MIHF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the Proxy/WIF/AR may map the message contents exchanged with the MN with that exchanged with the target WLAN AP in performing proxy function.


Figure R.12 shows the transport of WLAN L2 frames between the MN and legacy WLAN AN where the single radio handover is supported neither between the MN and the Proxy/WIF/AR nor between the Proxy/WIF/AR and the target WLAN AP. The Proxy/WIF/AR proxies between the MN and the target WLAN AP using an extension of R9 interface to communicate with the MN and using an extension of R6 interface to communicate with the target WLAN AP.

L2(2) control frame

L2(2) control frame

Control message

Control message

Ry+ Ry+ Ry+TCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPL2(1) L2 L2 L2

PHY(1) PHY PHY PHYMN SFF / WIF / AR WLAN AP

Figure R.12. Protocol stack showing the transport of WLAN L2 frame of target interface to the SFF/ASN-GW which proxy between the MN and the target PoA.

129

123

4567

89

101112

13

1415161718

192021


The MN and the Proxy/WIF/AR will need certain mechanism to communicate with each other, such as an extension (Ry+) of the Ry interface. The Proxy/WIF/AR and the target WLAN AP will also need certain mechanism to communicate with each other.

The Proxy/WIF/AR may then proxy between the MN and the target WLAN AP using the Ry+ to communicate with MN and using some mechanism to communicate with the target WLAN AP.

Ry+ is outside the scope of this standard.

Q.3.3 WiMAX to WLAN Single Radio Handover processes

The single radio handover processes are: network discovery, handover decision, preregistration, WLAN link preparation, and these processes are described in the following:

1) 1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. These query and reply messages may use the IP connectivity of the source link.

The Information Repository provides the MN with information about available networks and handover policy. It will also inform the MN whether the WiFi access network (AN) available in the neighborhood supports SRHO, and channel and frequency information of the candidate APs to perform radio measurements.



b) (2) A WLAN network is selected.




a) The authentication messages are exchanged between the MN and the WLAN AP, which is the authenticator. These messages are L2 control frame messages in the target (WLAN) network, which could have been exchanged via the target (WLAN) link if the target link were available. When the target link is not available, the transport of the L2 control frame is through the source (WiMAX) network as described in Clause 11.2.

b) The Proxy (WIF/AR/WiFi-Proxy) processes the MIH frame containing the L2 authentication message and may consult the AAA in the WiMAX CSN through the R3 interface.

c) The Proxy (WIF/AR/WiFi-Proxy) maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the Proxy, the preregistration is performed for the WiFi access network, which may have multiple

130

123

45

6

7

89

10111213

14151617

18

1920

21

222324

25262728

2930

3132333435

3637

383940


AP’s. When the MN attaches to a different target AP, it will use the existing registration context if the Proxy already has this registration context.

d) The Proxy (WIF/AR/WiFi-Proxy combination) also constructs control messages to communicate with the target WLAN AP. In terms of exchange of these control messages, the WIF/AR/WiFi-Proxy behaves like a virtual WiFi AP located in the WiFi network to communicate with the MN. Such control messages are equivalent to those in the handover from one AP to another AP within the same network. Therefore control messages may reuse those between the source PoA and target PoA within the same network to prepare the handover of a MN within the same network.

e) For messages from the WIF/AR/WiFi-Proxy to the MN, they are tunneled to the MN via the WiMAX network. To the target WiFi AP, the WIF/AR/WiFi-Proxy acts like a virtual WLAN radio interface.

f) The MN may pre-register with the WiMAX network, using the same interface and transport mechanism as that in proactive authentication.

4) 4: WLAN link preparation:

Before L3 handover occurs, the target link may perform preparation processes at L2, such as signal strength measurement and power management.

A target AP is selected. The MN may use the target interface to check the beacon messages from the target AP to confirm that there is sufficient signal strength.

5) 5: SRHO execution process. In this process, the WiMAX link is disconnected, the WLAN radio is activated, and the WLAN link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WiMAX link layer address to the WLAN link layer address, and future incoming packets are then routed to the WLAN radio.

Q.4 WiMAX to 3GPP single radio handover


The general reference model as it applies to WiMAX to 3GPP single radio handover is illustrated in Figure R.13.

131

12

345678

91011

1213

14

1516

1718

19202122

23

24

2526


WiMAX ASN 3GPP network

MN during handover

MIIS orANDSF

Originating radio interface

Originating PoA Target PoA

Originating link

ASN-GW

S-GW

eNBBS

S2aS5/8

S11S1-U

S1-MME

S14

PCRFGxaGxcGx

AAA

HSSSWx

S6a

S6b

STa

GW R6

P-GW

MME

3GPP-SFF

X200

X202

Figure R.13 WiMAX to 3GPP single radio handover reference model.


a) The Information repository function is implemented in the ANDSF in the 3GPP network.The Information Repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification, or in another information repository defined elsewhere, such as the ANDSF.

b) The Proxy function is implemented in the 3GPP-Proxy and the existing functions of Mobility Management Entity (MME) in the 3GPP EPS network. The 3GPP-Proxy and MME may co-locate. In the event that they are not co-located, they communicate with each other using interface X202. When the MN signals to the Proxy as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy which acts like a virtual MN. The Proxy may also behave like a virtual PoA to signal with the target PoA.


a) S2a reference point between P-GW in the 3GPP EPS network and ASN GW in the WiMAX network is defined in the 3GPP network [3GPP TS23.402].

b) S14 reference points between UE and ANDSF is defined in the 3GPP network [3GPP TS23.402].

c) S5/8 reference point between P-GW and S-GW is defined in the 3GPP network [3GPP TS23.401].

d) S11 reference point between S-GW and MME is defined in the 3GPP network [3GPP TS23.401].

e) S1-U reference point between UE and S-GW is defined in the 3GPP network [3GPP TS23.401].

f) S1-MME reference point between UE and MME is defined in the 3GPP network [3GPP TS23.401].

132

1

23

4

5

6789

101112131415

16

1718

19

20

21

22

2324


g) S6a reference point between P-GW and AAA is defined in the 3GPP network [3GPP TS23.401].

h) S6b reference point between MME and HSS is defined in the 3GPP network [3GPP TS23.401].

i) SWx reference point between HSS and AAA is defined in the 3GPP network [3GPP TS23.401].

j) STa reference point between WiMAX ASN and AAA is defined in the 3GPP network [3GPP TS23.402].

k) Gx reference point between P-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

l) Gxa reference point between WiMAX ASN and PCRF is defined in the 3GPP network [3GPP TS23.402].

m) Gxc reference point between S-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

n) R6 interface between the WiMAX Proxy and ASN GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

o) X200 interface between MN and 3GPP-Proxy is defined in WiMAX Forum [WMF-T37-011-R016v01].

p) X202 interface between MME and 3GPP-Proxy is defined in WiMAX Forum [WMF-T37-011-R016v01].

Q.4.2 Transport of 3GPP L2 control frames between MN and the 3GPP network with MIH-capable devices

The single radio handover signal is similar to that of the generalized case described in Clause 5.5. The transport of the 3GPP L2 frame is described below.


Figure R.14 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the 3GPP-Proxy/MME and the target 3GPP eNB all support single radio handover. The 3GPP radio L2 control frame is transported as a payload of a media independent control frame between the MN and the 3GPP network via the source WiMAX link at the left. The 3GPP-Proxy/MME bridges between the MN and the target 3GPP eNB.

L2(2) L2(2) L2(2) L2(2) L2(2)

MIH MIH MIH

TCP or UDP / IP


L2(1) L2 L2 L2


MN 3GPP - SFF MME WiFi AP

Figure R.14. Transport of 3GPP L2 frame of target interface via the 3GPP-SFF/MME using the logical connection at the MIH.

133

1

2

3

45

6

78

9

1011

1213

1415

1617

1819

20

2122232425

262728

29


The SR-MIHF interfaces with the TCP or UDP / IP layer through the Media Independent Handover Service Access Point (MIH_SAP). The source WiMAX link enables the TCP or UDP / IP connection between the MN and the WiMAX network, which may then connect to the 3GPP network through the Internet or the WiMAX CSN. Therefore media independent handover (MIH) frames may be exchanged between the MIHF in the MN and the MIHF in the 3GPP-Proxy/MME and/or the 3GPP eNB in the 3GPP network using TCP or UDP / IP transport.

An L2 frame is encapsulated with a SR-MIHF header to constitute a MIH frame, which is exchanged between the MN and the target 3GPP eNB or the 3GPP-Proxy/MME.

The MN will query the Information Repository to find the candidate target 3GPP eNB. Based on the information from the Information Repository, the MN will then have some means to identify the target 3GPP eNB, such as the link-layer address in order to perform network entry procedure to the 3GPP network using L2 packets.

The Information Repository need to know the IP address of the 3GPP-Proxy/MME, so that the MN and the 3GPP-Proxy/MME can exchange MIH frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target 3GPP eNB.

If the MN knows the IP address of the target 3GPP eNB, it will send the MIH frame to the SR-MIHF in the target 3GPP eNB using TCP or UDP / IP transport.

If the MN does not know the IP address of the target 3GPP eNB, it will need at least somethinganother identifier, such as the link-layer address, to identify the target 3GPP eNB. The MIH frame is first sent as the payload of a TCP or UDP / IP packet destined to the 3GPP-Proxy/MME as described in Section 12. The MIH frame contains information for the target 3GPP network to identify the target 3GPP eNB. The 3GPP-Proxy/MME will find out the IP address of the target 3GPP eNB and use this address as the destination address of a TCP or UDP / IP packet containing the MIH frame as payload to forward to the target 3GPP eNB.

The reply by the targetThe reply sent by the target 3GPP eNB is transported in a similar manner. If the target 3GPP link were available, the target 3GPP eNB would send a L2 message back to the MN using this 3GPP link. Lacking this target link, this L2 message is passed as the payload of an MIH frame.

If the target PoA had received the MIH frame from the MN, the reply MIH frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target 3GPP eNB had received the MIH frame from the 3GPP-Proxy/MME, the reply MIH frame will first use TCP or UDP / IP transport with an IP address destined to the 3GPP-Proxy/MME. At the 3GPP-Proxy/MME, the TCP or UDP / IP header is extracted at the MIH_SAP at the input interface of the 3GPP-Proxy/MME to retrieve the MIH frame. The SR-MIHF function will pass the MIH frame through the MIH_SAP at the output interface of the 3GPP-Proxy/MME to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Q.4.2.2 Transport without MIH-capable target 3GPP eNB

Figure R.15 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the 3GPP-Proxy/MME support single radio handover. Yet the target 3GPP eNB are legacy 3GPP eNB’s lacking such support. The 3GPP target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the 3GPP network via the source WiMAX link at the left. The 3GPP-Proxy/MME proxies between the MN and the target 3GPP eNB using MIH to communicate with the MN and using an extension of R6 interface to communicate with the target 3GPP eNB.

134

123456

78

9101112

131415

1617

18192021222324

252627

28293031323334

35

363738394041


L2(2) control frame

L2(2) control frame

Control message

Control message

MI CF MICF S1-MME+ S1-MME+

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP


MN 3GPP-SFF MME 3GPP eNB

Figure R.15. Transport of 3GPP L2 frame of target interface to the 3GPP-SFF/MME which proxy between the MN and the target PoA, showing (a) the MIH_LINK_SAP and MIH_SAP, and (b) the resulting protocol stack.

Lacking the single radio handover support in the 3GPP eNB, the 3GPP-Proxy/MME and the target 3GPP eNB will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (S1-MME+) of the S1-MME reference point and is outside the scope of this standard.

The 3GPP-Proxy/MME may then proxy between the MN and the target 3GPP eNB using SR-MIHF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the 3GPP-Proxy/MME may map the message contents exchanged with the MN with that exchanged with the target 3GPP eNB in performing proxy function.


Figure R.16 shows the transport of 3GPP L2 frames between the MN and legacy 3GPP network where the single radio handover is supported neither between the MN and the 3GPP-Proxy/MME nor between the 3GPP-Proxy/MME and the target 3GPP eNB. The 3GPP-Proxy/MME proxies between the MN and the target 3GPP eNB using an extension of R9 interface to communicate with the MN and using an extension of R6 interface to communicate with the target 3GPP eNB.

135

1234

56789

1011121314

15

1617181920


L2(2) control frame

L2(2) control frame

Control message

Control message

X200+ X200 X200+ S1-MME+ S1-MME+

S1-MME+ hdr

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP



Figure R.16. Protocol stack showing the transport of 3GPP L2 frame of target interface to the SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the 3GPP-Proxy/MME will need certain mechanism to communicate with each other, such as an extension (X200+) of the X200 interface. The 3GPP-Proxy/MME and the target 3GPP eNB will also need certain mechanism to communicate with each other.

The 3GPP-Proxy/MME may then proxy between the MN and the target 3GPP eNB using the X200+ to communicate with MN and using S1-MME+ to communicate with the target 3GPP eNB.

Both X200+ and S1-MME+ are outside the scope of this standard.

Q.4.3 WiMAX to 3GPP Single Radio Handover processes

The single radio handover processes are: network discovery, handover decision, preregistration, 3GPP link preparation, and these processes are described in the following:

1) 1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. The message exchange between the MN and the ANDSF may use the S14 reference point between the MN and the ANDSF as defined in 3GPP. These messages are carried in IP packets and may therefore use the IP connectivity at the source link.

The ANDSF provides the MN with information about available networks and handover policy. It will also inform the MN whether the 3GPP EPS network available in the neighborhood supports SRHO, the presence of P-GW, and system information blocks of candidate PoAs to perform radio measurements.

While ANDSF may be present in the 3GPP network, the WiMAX network may also have ANDSF in its CSN.



b) (2) A 3GPP EPS network is selected.


136

123

456

78

9

10

1112

131415161718

192021

2223

24

2526

27

282930


3) 3: Preregistration includes proactive authentication and establishing context (user identity, security, resource information) at the target network. With the help of the ProxyProxy, the MN can perform network entry procedures towards the target network while retaining its data connection with the source network.


a) The authentication messages are exchanged between the MN and the MME, which is the authenticator. These messages are L2 control frame messages in the target (3GPP) network, which could have been exchanged via the target (3GPP) link if the target link were available. When the target link is not available, the transport of the L2 control frame between the MN and the 3GPP-ProxyProxy/MME combination is through the source (WiMAX) network as described in Clause

11.6.4.1.

b) The 3GPP-ProxyProxy/MME processes the MIH frame containing the L2 authentication message. The MME may consult the HSS in the 3GPP EPS network through the S6a reference point.

c) The MME maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the MME, the preregistration is performed for the 3GPP access network, which may have multiple eNB’s. When the MN attaches to a different target eNB, it will use the existing registration context if the MME already has this registration context.

d) The 3GPP-ProxyProxy/MME combination also constructs control messages to communicate with the target 3GPP eNB. In terms of exchange of these control messages, the 3GPP-Proxy/MME behaves like a virtual 3GPP eNB located in the 3GPP network to communicate with the MN. Such control messages are equivalent to those in the handover from one eNB to another eNB within the same network. Therefore control messages may reuse those between the originating PoA and target PoA within the same network to prepare the handover of a MN within the same network.

e) For messages from the 3GPP-Proxy/MME to the MN, they are tunneled to the MN via the WiMAX network. To the target 3GPP eNB, the 3GPP-Proxy/MME acts like a virtual 3GPP radio interface.

f) The MN may pre-register with the 3GPP network, using the same interface and transport mechanism as that in proactive authentication.

4) 4: Target 3GPP link preparation:


A target eNB is selected. The MN may use the target interface to check the broadcast messages from the target eNB to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.31.4.

The 3GPP will check with the target eNB to reserve the radio channels needed for MN to attach to the 3GPP network. The channels needed for MN to operate in active or idle mode are assigned depending on whether the source radio was in the active or idle mode.

5) 5: SRHO execution process. In this process, the WiMAX link is disconnected, the 3GPP radio is activated, and the 3GPP link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WiMAX link layer address to the 3GPP link layer address, and future incoming packets are then routed to the 3GPP radio.

137

1234

56

789

101112

1314

1516171819

202122232425

262728

2930

31

3233

343536

373839

40414243


Q.5 WLAN to 3GPP single radio handover


The general reference model as it applies to Non-trusted WLAN to 3GPP single radio handover is illustrated in Figure R.17.

WLAN AN 3GPP network

MN during handover

MIIS orANDSF

Originating radio interface

Originating PoA Target PoA

Originating link

S-GW

eNBAP

S5/8

S11S1-U

S1-MME

S14

PCRFGxaGxcGx

AAA

HSSSWx

S6a

S6b

Proxy

P-GW

MME

3GPP-SFF

RPmi

X202

AR

SWa

SWmePDG S2bSWn

Figure R.17 Non-trusted WLAN AN to 3GPP single radio handover reference model.


a) The Information repository function is implemented in the ANDSF in the 3GPP network. The Information Repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification, or in another information repository defined elsewhere, such as the ANDSF.

b) The Proxy function is implemented in the 3GPP-Proxy and the existing functions of Mobility Management Entity (MME) in the 3GPP EPS network. The 3GPP-Proxy and MME may co-locate. In the event that they are not co-located, they communicate with each other using interface X202. When the MN signals to the Proxy as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy which acts like a virtual MN. The Proxy may also behave like a virtual PoA to signal with the target PoA.

Q.5.1.2 Reference points:

a) S2c reference point between MN and the P-GW is defined in the 3GPP EPS network [3GPP TS23.402].

b) S2b reference point between ePDG and the P-GW is defined in the 3GPP EPS network [3GPP TS23.402].

c) S14 reference point between UE and ANDSF is defined in the 3GPP network [3GPP TS23.402].

138

1

2

34

5

67

8

9

10111213

141516171819

20

2122

2324

25


d) S5/8 reference point between P-GW and S-GW is defined in the 3GPP network [3GPP TS23.401].

e) S11 reference point between S-GW and MME is defined in the 3GPP network [3GPP TS23.401].

f) S1-U reference point between UE and S-GW is defined in the 3GPP network [3GPP TS23.401].

g) S1-MME reference point between UE and MME is defined in the 3GPP network [3GPP TS23.401].

h) S6a reference point between P-GW and AAA is defined in the 3GPP network [3GPP TS23.401].

i) S6b reference point between MME and HSS is defined in the 3GPP network [3GPP TS23.401].

j) SWa reference point between the non-trusted WLAN AN and AAA is defined in the 3GPP network [3GPP TS23.402].

k) SWn reference point between the non-trusted WLAN AN and ePDG is defined in the 3GPP network [3GPP TS23.402].

l) SWm reference point between ePDG and P-GW is defined in the 3GPP network [3GPP TS23.402].

m) SWx reference point between HSS and AAA is defined in the 3GPP network [3GPP TS23.401].

n) Gx reference point between P-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

o) Gxb reference point between ePDG and PCRF is defined in the 3GPP network [3GPP TS23.401].

p) Gxc reference point between S-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

q) RPmi interface between MN and 3GPP-Proxy.

r) X202 interface between MME and 3GPP-Proxy is defined in WiMAX Forum [WMF-T37-010-R016v01].

[R.1.1] Transport of 3GPP L2 control frames between MN and the 3GPP network

The single radio handover signal is similar to that of the generalized case described in Clause 5.5. The transport of the 3GPP L2 frame is described below.


Figure R.18 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the 3GPP-Proxy/MME and the target 3GPP eNB all support single radio handover. The 3GPP radio L2 control frame is transported as a payload of a MIH frame between the MN and the 3GPP network via the source WLAN link at the left. The 3GPP-Proxy/MME bridges between the MN and the target 3GPP eNB.

139

1

2

3

45

6

7

89

1011

1213

14

15

16

17

18

1920

21

22

2324

25

26272829


L2(2) L2(2) L2(2) L2(2) L2(2)MIH MIH MIH

TCP or UDP / IP


L2(1) L2 L2 L2


MN 3GPP - SFF / MME 3GPP eNB

Figure R.18. Transport of 3GPP L2 frame of target interface via the 3GPP-SFF/MME using the logical connection at the MIH.

The SR-MIHF interfaces with the TCP or UDP / IP layer through the Media Independent Handover Service Access Point (MIH_SAP). The source WLAN link enables the TCP or UDP / IP connection between the MN and the WLAN network, which may then connect to the 3GPP network through the Internet or the 3GPP EPC. Therefore media independent handover control (MIH) frames may be exchanged between the SR-MIHF in the MN and the SR-MIHF in the 3GPP-Proxy/MME and/or the 3GPP eNB in the 3GPP network using TCP or UDP / IP transport.

An L2 frame is encapsulated with a SR-MIHF header to constitute a MIH frame, which is exchanged between the MN and the target 3GPP eNB or the 3GPP-Proxy/MME.


The Information Repository need to know the IP address of the 3GPP-Proxy/MME, so that the MN and the 3GPP-Proxy/MME can exchange MIH frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target 3GPP eNB.

If the MN knows the IP address of the target 3GPP eNB, it will send the MIH frame to the SR-MIHF in the target 3GPP eNB using TCP or UDP / IP transport.

If the MN does not know the IP address of the target 3GPP eNB, it will need at least somethinganother identifier, such as the link-layer address, to identify the target 3GPP eNB. The MIH frame is first sent as the payload of a TCP or UDP / IP packet destined to the 3GPP-Proxy/MME as described in Section 12. The MIH frame contains information for the target 3GPP network to identify the target 3GPP eNB. The 3GPP-Proxy/MME will find out the IP address of the target 3GPP eNB and use this address as the destination address of a TCP or UDP / IP packet containing the MIH frame as payload to forward to the target 3GPP eNB.

The reply by the targetThe reply sent by the target 3GPP eNB is transported in a similar manner. If the target 3GPP link were available, the target 3GPP eNB would send a L2 message back to the MN using this 3GPP link. Lacking this target link, this L2 message is passed as the payload of an MIH frame.

If the target PoA had received the MIH frame from the MN, the reply MIH frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target 3GPP eNB had received the MIH frame from the 3GPP-Proxy/MME, the reply MIH frame will first use TCP or UDP / IP transport with an IP address destined to the 3GPP-Proxy/MME. At the 3GPP-Proxy/MME, the TCP or UDP / IP header is extracted at the MIH_SAP at the input interface of the 3GPP-Proxy/MME to retrieve the MIH frame. The SR-MIHF function will pass the MIH frame through the MIH_SAP at the output interface of the 3GPP-Proxy/MME to form a new TCP or UDP / IP packet with an IP address destined to the MN.

140

123

456789

1011

12131415

161718

1920

21222324252627

282930

31323334353637


Q.5.1.4 Transport without MIH-capable target 3GPP eNB

Figure R.19 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the 3GPP-Proxy/MME support single radio handover. Yet the target 3GPP eNB are legacy 3GPP eNB’s lacking MICF support. The 3GPP target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the 3GPP network via the source WLAN link at the left. The 3GPP-Proxy/MME proxies between the MN and the target 3GPP eNB using MICF to communicate with the MN and using an extension of R6 interface to communicate with the target 3GPP eNB.

L2(2) control frame

L2(2) ctrl frame

Control message

Control message


TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(1) L2 L2 L2

PHY(1) PHY PHY PHY

MN 3GPP-SFF MME eNB

Figure R.19. Transport of 3GPP L2 frame of target interface to the 3GPP-SFF/MME which proxies between the MN and the target PoA.

Lacking the single radio handover support in the 3GPP eNB, the 3GPP-Proxy/MME and the target 3GPP eNB will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (S1-MME+) of the S1-MME reference point and is outside the scope of this standard.

The 3GPP-Proxy/MME may then proxy between the MN and the target 3GPP eNB using SR-MIHF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the 3GPP-Proxy/MME may map the message contents exchanged with the MN with that exchanged with the target 3GPP eNB in performing proxy function.


Figure R.20 shows the transport of 3GPP L2 frames between the MN and legacy 3GPP network where the single radio handover is supported neither between the MN and the 3GPP-Proxy/MME nor between the 3GPP-Proxy/MME and the target 3GPP eNB. The 3GPP-Proxy/MME proxies between the MN and the target 3GPP eNB using an extension of RPmi interface to communicate with the MN and using an extension of S1-MME reference point to communicate with the target 3GPP eNB.

141

1

234567

89

10

1112131415

1617181920

21

2223242526


L2(2) control frame

L2(2) control frame

Control message

Control message

Rpmi+ RPmi+ Rpmi+ S1-MME+ hdr S1-MME+

S1-MME+ hdr

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP



Figure R.20. Protocol stack showing the transport of 3GPP L2 frame of target interface to the SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the 3GPP-Proxy/MME will need certain mechanism to communicate with each other, such as an extension (RPmi+) of the RPmi interface. The 3GPP-Proxy/MME and the target 3GPP eNB will also need certain mechanism to communicate with each other.

The 3GPP-Proxy/MME may then proxy between the MN and the target 3GPP eNB using the RPmi+ to communicate with MN and using S1-MME+ to communicate with the target 3GPP eNB.

Both RPmi+ and S1-MME+ are outside the scope of this standard.

Q.5.2 Non-trusted WLAN AN to 3GPP Single Radio Handover processes

The single radio handover processes are: network discovery, handover decision, preregistration, 3GPP link preparation, and these processes are described in the following:

1. 1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. The message exchange between the MN and the ANDSF may use the S14 reference point between the MN and the ANDSF as defined in 3GPP. These messages are carried in IP packets and may therefore use the IP connectivity at the source link.

The MIIS or ANDSF provides the MN with information about available networks and handover policy. It will also inform the MN whether the 3GPP EPS network available in the neighborhood supports SRHO, the presence of ePDG, P-GW, and system information blocks of candidate PoAs to perform radio measurements.

2. 2: Handover Decision process:

a. (1) The handover may be triggered by a need such as degradation of source link quality or cost considerations.

b. (2) A 3GPP EPS network is selected.

c. (3) A determination is made on whether there is benefit to handover. The decision can be taken by the MN or the network and may be based on the parameters such as signal strength, cost, and operator policy.

3. 3: Preregistration includes proactive authentication and establishing context (user identity, security, resource information) at the target network. With the help of the Proxy, the MN can

142

123

456

78

9

10

1112

131415161718

19202122

23

2425

26

272829

3031


perform network entry procedures towards the target network while retaining its data connection with the source network.


a. The authentication messages are exchanged between the MN and the MME, which is the authenticator. These messages are L2 control frame messages in the target (3GPP) network, which could have been exchanged via the target (3GPP) link if the target link were available. When the target link is not available, the transport of the L2 control frame is through the sourceoriginating (WLAN) network as described in Clause 11.6.5.12.

b. The 3GPP-Proxy/MME processes the frame containing the L2 authentication message. The MME may consult the HSS in the 3GPP EPS network through the S6a reference point.

c. The MME maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the MME, the preregistration is performed for the 3GPP access network, which may have multiple eNB’s. When the MN attaches to a different target eNB, it will use the existing registration context if the MME already has this registration context.

d. The 3GPP-Proxy/MME combination also constructs control messages to communicate with the target 3GPP eNB. In terms of exchange of these control messages, the 3GPP-Proxy/MME behaves like a virtual 3GPP eNB located in the 3GPP network to communicate with the MN. Such control messages are equivalent to those in the handover from one eNB to another eNB within the same network. Therefore control messages may reuse those between the sourceoriginating PoA and target PoA within the same network to prepare the handover of a MN within the same network.

e. For messages from the 3GPP-Proxy/MME to the MN, they are tunneled to the MN via the WiMAX network. To the target 3GPP eNB, the 3GPP-Proxy/MME acts like a virtual 3GPP radio interface.

f. The MN may pre-register with the 3GPP network, using the same interface and transport mechanism as that in proactive authentication.

4. 4: Target 3GPP link preparation:


A target eNB is selected. The MN may use the target interface to check the broadcast messages from the target eNB to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.31.4.

The 3GPP will check with the target eNB and target 3GPP-Proxy/MME to reserve the radio channels needed for MN to attach to the 3GPP network. The channels needed for MN to operate in active or idle mode are assigned depending on whether the source radio was in the active or idle mode.

5. SRHO execution process. In this process, the WLAN link is disconnected, the 3GPP radio is activated, and the 3GPP link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WLAN link layer address to the 3GPP link layer address, and future incoming packets are then routed to the 3GPP radio.

143

12

34

56789

101112

1314151617

18192021222324

252627

2829

30

3132

333435

36373839

40414243


1. 5: SRHO execution process. In this process, the WLAN link is disconnected, the 3GPP radio is activated, and the 3GPP link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WLAN link layer address to the 3GPP link layer address, and future incoming packets are then routed to the 3GPP radio. (Informative)

Insert

[R.2] WLAN to WiMAX single radio handover

The general reference model as it applies to WLAN to WiMAX single radio handover is illustrated in Figure R.1.

WiMAXCSN

WiMAX ASN

MN before handover

MN during handover


Source PoA


ASN-GW

WIFSFF

BS

Rx

AP

GW


W3

R3

R1

R3+

AAA

DHCP

R6

Target PoA

Figure R.1 WLAN to WiMAX single radio handover reference model.

Functional entities:

The Information Repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification, or in another information repository defined elsewhere, such as the ANDSF.

The WiMAX Signal Forwarding Function (SFF) is defined in a WiMAX Forum standard. It may be co-located at the ASN-GW. Otherwise, SFF may communicate with the ASN-GW using the R6 interface.

The Proxy GW function is implemented in the combined functions of ASN-GW and WiMAX SFF, in the WiMAX network. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may correspondingly signal to that Proxy GW acting in the role of a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA.

The WiFi Interworking Function (WIF) is defined in WiMAX Forum.

144

12345

6

7

8

910

1112

13

14

15

161718

1920

21222324

25


Reference Points:

W3 interface between the WLAN AP and the WIF is defined in WiMAX Forum [WMF-T37-010-R016v01].

Rx interface between the MS and the WiMAX SFF/GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

R3 interface between the WiMAX CSN and ASN is defined in WiMAX Forum [WMF-T37-010-R016v01].

R3+ interface between the WIF and AAA and also DHCP in the WiMAX CSN is defined in WiMAX Forum [WMF-T37-010-R016v01].

R6 interface between the WiMAX SFF/Proxy GW and ASN GW is defined in WiMAX Forum [T33-001-R015].

[R.2.1] Transport of WiMAX L2 control frames between MN and the WiMAX ASN

Figure R.2 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the co-located Proxy GW/ASN-GW and the target WiMAX BS all support single radio handover control function (SRCF), which is a media independent control function (MICF) in the 802-2012 architecture [IEEE P802-D1.4]. The WiMAX radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WiMAX network via the source WLAN link at the left and in the absence of the target WiMAX link at the right. The co-located Proxy GW/ASN-GW bridges between the MN and the target WiMAX BS. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

145

1

23

45

6

78

910

11

121314151617181920

21

22

23

24

25

26

27


MICF MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1)

WLANLink

L2(1) L2 L2 L2 L2 L2(2) frame

No WiMAX

linkL2(2) frame

PHY(2) PHY(1) PHY(1) PHY PHY PHY PHY PHY(2) PHY(2)MN’s

WiMAXinterface

MN’s WLAN

interface

WLAN AP SFF / ASN -GW WiMAX BS MN’s WiMAXinterface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

(b)

L2(2) L2(2) L2(2)MICF MICF MICFTCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

L2(1) L2 L2 L2(1)PHY(1) PHY PHY PHY(1)

MN SFF /ASN-GW WiMAXBS

Figure R.2. Transport of WiMAX L2 frame of target interface via the co-located SFF/ASN-GW using the logical connection at the MICF, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

The SRCF interfaces with the TCP or UDP / IP layer through the Media Independent Control Service Access Point (MICSAP). The source WLAN link enables the TCP or UDP / IP connection between the MN and the WLAN network, which may then connect to the WiMAX ASN through the Internet or the WiMAX CSN. Therefore single radio handover control (SRC) frames may be exchanged between the SRCF in the MN and the SRCF in the Proxy GW/ASN-GW and/or the WiMAX BS in the WiMAX network using TCP or UDP / IP transport.

The SRCF also interfaces with the link-layer (L2) through the media independent control link-layer service access point (MICLSAP). An L2 frame is encapsulated with a SRCF header to constitute a SRC frame, which is exchanged between the MN and the target WiMAX BS or the co-located Proxy GW/ASN-GW.


It is required that the Information Repository need to know the IP address of the Proxy GW/ASN-GW, so that the MN and the Proxy GW/ASN-GW can exchange SRC frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target WiMAX BS.

146

12

3

4567

89

10111213

141516

17181920

212223


If the MN knows the IP address of the target WiMAX BS, it will send the SRC frame to the SRCF in the target WiMAX BS using TCP or UDP / IP transport.

If the MN does not know the IP address of the target WiMAX BS, it will need at least something, such as the link-layer address, to identify the target WiMAX BS. The SRC frame is first sent as the payload of a TCP or UDP / IP packet destined to the collocated Proxy GW/ASN-GW as described in Clause 11.4.3. The SRC frame contains information for the target WiMAX network to identify the target WiMAX BS. The co-located Proxy GW/ASN-GW will find out the IP address of the target WiMAX BS and use this address as the destination address of a TCP or UDP / IP packet containing the SRC frame as payload to forward to the target WiMAX BS.

The reply by the target WiMAX BS is transported in a similar manner. If the target WiMAX link were available, the target WiMAX BS would send a L2 message back to the MN using this WiMAX link. Lacking this target link, this L2 message is passed through the MICLSAP to become the payload of an SRC frame.

If the target PoA had received the SRC frame from the MN, the reply SRC frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target WiMAX BS had received the SRC frame from the co-located Proxy GW/ASN-GW, the reply SRC frame will first use TCP or UDP / IP transport with an IP address destined to the Proxy GW. At the co-located Proxy GW/ASN-GW, the TCP or UDP / IP header is extracted at the MICSAP at the input interface of the co-located Proxy GW/ASN-GW to retrieve the SRC frame. The SRCF function will pass the SRC frame through the MICSAP at the output interface of the co-located Proxy GW/ASN-GW to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Figure R.3 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the co-located Proxy GW/ASN-GW support single radio handover control function (SRCF), which is a media independent control function (MICF) in the IEEE P802/D4.0 architecture. Yet the target WiMAX BS are legacy WiMAX BS’s lacking MICF support. The target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WiMAX network via the source WLAN link at the left and in the absence of the target WiMAX link at the right. The co-located SFF/ASN-GW proxies between the MN and the target WiMAX BS using MICF to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS. (a) shows the transport between MN and the co-located Proxy GW/ASN-GW through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

147

12

3456789

10111213

1415161718192021

22232425262728293031

32

33

34

35

36

37

38

39

40


Crtlmsg

Crtl msg

R6+ R6+

MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2)L2(1) WLAN

link L2(1) L2 L2 L2 L2 L2(2)No

WiMAXlink

L2(2) frame


WiMAXinterface

MN’s WLAN

interface

WLAN AP SFF/ ASN- GW WiMAX BS MN’s WiMAXinterface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2) control frame

L2(2) control frame

Control message

Control message


TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP



Figure R.3. Transport of WiMAX L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

Lacking MICF support in the WiMAX BS, the co-located Proxy GW/ASN-GW and the target WiMAX BS will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (R6+) of the R6 interface and is outside the scope of this standard.

The co-located Proxy GW/ASN-GW may then proxy between the MN and the target WiMAX BS using SRCF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the co-located Proxy GW/ASN-GW may map the message contents exchanged with the MN with that exchanged with the target WiMAX BS in performing proxy function. Figure R.4 shows the packet used in the transport of WiMAX L2 frames between the MN and legacy WiMAX ASN where the single radio handover control function (SRCF) is supported neither between the MN and the Proxy GW/ASN-GW nor between the Proxy GW/ASN-GW and the target WiMAX BS. The co-located Proxy GW/ASN-GW proxies between the MN and the target WiMAX BS using an extension of Rx interface to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS.

148

12

3456

789

1011

12131415161718192021

22


L2(2) control frame

L2(2) control frame

Control message

Control message

Rx+ Rx+ Rx+ R6+ R6+ R6+TCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPL2(1) L2 L2 L2


Figure R.4. Protocol stack showing the transport of WiMAX L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the co-located Proxy GW/ASN-GW will need certain mechanism to communicate with each other, such as an extension (Rx+) of the Rx interface. The Proxy GW/ASN-GW and the target WiMAX BS will also need certain mechanism to communicate with each other, such as an extension (R6+) of the R6 interface.

The co-located Proxy GW/ASN-GW may then proxy between the MN and the target WiMAX BS using the Rx+ to communicate with MN and using the R6+ to communicate with the target WiMAX BS.

Both Rx+ and R6+ are both outside the scope of this standard.

[R.2.2] WLAN to WiMAX Single Radio Handover processes

1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. These query and reply messages may use the IP connectivity of the source link.

The Information Repository provides the MN with information about available networks and handover policy. It will also inform the MN whether the WiMAX ASN available in the neighborhood supports SRHO, and system information blocks of candidate PoAs to perform radio measurements.

2: Pre-registration includes proactive authentication and establishing context (user identity, security, resource information) at the target network. With the help of the Proxy GW, the MN can perform network entry procedures towards the target network while retaining its data connection with the source network.


The authentication messages are exchanged between the MN and the ASN-GW, which is the authenticator. These messages are L2 control frame messages in the target (WiMAX) network, which could have been exchanged via the target (WiMAX) link if the target link were available. When the target link is not available, the transport of the L2 control frame between the MN and the Proxy GW/ASN-GW is through the source (WiFi) network as described in Clause 11.6.1.1.

The ASN-GW/Proxy GW processes the SRC frame containing the L2 authentication message and may consult the AAA in the WiMAX CSN through the R3 interface.

The ASN-GW maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the Proxy GW/ASN-GW, the pre-registration is

149

123

4567

89

10

11

12

13141516

171819

202122

2324

2526272829

3031

3233


performed for the ASN network, which may have multiple PoA’s. When the MN attaches to a different target BS, it will use the existing registration context if the Proxy GW/ASN-GW already has this registration context.

The ASN-GW/Proxy GW combination also constructs control messages to communicate with the target WiMAX BS. In terms of exchange of these control messages, the ASN-GW/Proxy GW behaves like a virtual WiMAX BS located in the WiMAX network to communicate with the MN. Such control messages are equivalent to those in the handover from one BS to another BS within the same network. Therefore control messages may reuse those messages between the source PoA and target PoA within the same network to prepare the handover of a MN within the same network.

For messages from the ASN-GW/Proxy GW to the MN, they are tunneled to the MN via the WiFi network. To the target WiMAX BS, the ASN-GW/Proxy GW acts like a virtual WiMAX radio interface.

The MN may pre-register with the WiMAX network, using the same interface and transport mechanism as that in proactive authentication.

3: Handover Decision process:

(1) The handover may be triggered by a need such as degradation of source link quality or cost considerations.

(2) A WiMAX network is selected.

(3) A determination is made on whether there is benefit to handover. The decision can be taken by the MN or the network and may be based on the parameters such as signal strength, cost, and operator policy.

4: WiMAX link preparation:


A target BS is selected. The MN may use the target interface to check the broadcast messages from the target BS to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.3.


5: SRHO execution process. In this process, the WiFi link is disconnected, the WiMAX radio is activated, and the WiMAX link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WiFi link layer address to the WiMAX link layer address, and future incoming packets are then routed to the WiMAX radio.

[R.3] 3GPP to WiMAX single radio handover

The general reference model as it applies to 3GPP to WiMAX single radio handover is illustrated in Figure R.5.

150

123

456789

1011

1213

14

1516

17

1819

20

2122

232425

262728

29303132

33

3435


3GPP network WiMAX ASN

MN before handover

MN during handover

MN after handover

MIIS orANDSF

Source radio interface Target radio interface

Source PoATarget PoA


PDN-GW

BS

R9

eNB

S2a

S14

ASN-GWSFF

GW

R6

Figure R.5 3GPP to WiMAX single radio handover reference model.


The Information repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification but may also be other information repository defined elsewhere, such as the ANDSF.

The WiMAX Signal Forwarding Function (Proxy GW) is defined in WiMAX Forum standard. It may co-locate at the ASN-GW. Yet in the event that it is not co-located there, it may communicate with the ASN-GW using the R6 interface defined in the WiMAX Forum standard.

The Proxy GW function is implemented in the combined functions of ASN-GW and WiMAX Proxy GW, which are defined in the WiMAX network. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA.

The PDN Gateway (P-GW) is defined in 3GPP [3GPP TS23.401].

Reference Points:

S2a reference point between the P-GW and the ASN GW is defined in 3GPP [3GPP TS23.402].

R9 interface between the MS and the WiMAX Proxy GW is defined in WiMAX Forum [WMF-T37-011-R016v01].

R6 interface between the WiMAX Proxy GW and ASN GW is defined in WiMAX Forum [T33-001-R015].

S14 reference point between the MS and the ANDSF is defined in 3GPP [3GPP TS23.402].

[R.3.1] Transport of WiMAX L2 control frames between MN and the WiMAX ASN

Figure R.6 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the co-located Proxy GW/ASN-GW and the target WiMAX BS all support single radio handover control function (SRCF), which is a media independent control function (MICF) in the 802-2010 architecture [IEEE P802-D1.4]. The WiMAX radio L2 control frame is transported as a payload of a media

151

1

23

4

5

678

91011

12131415

16

17

18

1920

2122

23

24

25262728


independent control frame between the MN and the WiMAX network via the source 3GPP link at the left and in the absence of the target WiMAX link at the right. The co-located Proxy GW/ASN-GW bridges between the MN and the target WiMAX BS. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

MICF MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1)

3GPPLink

L2(1) L2 L2 L2 L2 L2(2) frame

No WiMAX

linkL2(2) frame


WiMAXinterface

MN’s 3GPP

interface

3GPP eND SFF / ASN -GW WiMAX BS MN’s WiMAXinterface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

(b)

L2(2) control frame

L2(2) control frame

L2(2) control frame

MICF MICF MICFTCP or UDP/ IP

TCP or UDP /IP TCP or UDP/ IP


MN SFF /ASN-GW WiMAXBS

Figure R.6. Transport of WiMAX L2 frame of target interface via the co-located SFF/ASN-GW using the logical connection at the MICF, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

The SRCF interfaces with the TCP or UDP / IP layer through the Media Independent Control Service Access Point (MICSAP). The source 3GPP link enables the TCP or UDP / IP connection between the MN and the 3GPP network, which may then connect to the WiMAX ASN through the Internet or the WiMAX CSN. Therefore single radio handover control (SRC) frames may be exchanged between the SRCF in the MN and the SRCF in the Proxy GW/ASN-GW and/or the WiMAX BS in the WiMAX network using TCP or UDP / IP transport.

The SRCF also interfaces with the link-layer (L2) through the media independent control link-layer service access point (MICLSAP). An L2 frame is encapsulated with a SRCF header to constitute a SRC frame, which is exchanged between the MN and the target WiMAX BS or the co-located Proxy GW/ASN-GW.

152

12345

6

78

9

10111213

141516171819

202122



It is required that the Information Repository need to know the IP address of the Proxy GW/ASN-GW, so that the MN and the Proxy GW/ASN-GW can exchange SRC frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target WiMAX BS.

If the MN knows the IP address of the target WiMAX BS, it will send the SRC frame to the SRCF in the target WiMAX BS using TCP or UDP / IP transport.

If the MN does not know the IP address of the target WiMAX BS, it will need at least something, such as the link-layer address, to identify the target WiMAX BS. The SRC frame is first sent as the payload of a TCP or UDP / IP packet destined to the collocated Proxy GW/ASN-GW as described in Clause 11.4.3. The SRC frame contains information for the target WiMAX network to identify the target WiMAX BS. The co-located Proxy GW/ASN-GW will find out the IP address of the target WiMAX BS and use this address as the destination address of a TCP or UDP / IP packet containing the SRC frame as payload to forward to the target WiMAX BS.

The reply by the target WiMAX BS is transported in a similar manner. If the target WiMAX link were available, the target WiMAX BS would send a L2 message back to the MN using this WiMAX link. Lacking this target link, this L2 message is passed through the MICLSAP to become the payload of an SRC frame.

If the target PoA had received the SRC frame from the MN, the reply SRC frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target WiMAX BS had received the SRC frame from the co-located Proxy GW/ASN-GW, the reply SRC frame will first use TCP or UDP / IP transport with an IP address destined to the Proxy GW/ASN-GW. At the co-located Proxy GW/ASN-GW, the TCP or UDP / IP header is extracted at the MICSAP at the input interface of the co-located Proxy GW/ASN-GW to retrieve the SRC frame. The SRCF function will pass the SRC frame through the MICSAP at the output interface of the co-located Proxy GW/ASN-GW to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Figure R.7 shows the transport of WiMAX L2 frames between the MN and the WiMAX ASN when the MN, the co-located Proxy GW/ASN-GW support single radio handover control function (SRCF), which is a media independent control function (MICF) in the IEEE P802-D1.4 architecture. Yet the target WiMAX BS are legacy WiMAX BS’s lacking MICF support. The WiMAX target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WiMAX network via the source 3GPP link at the left and in the absence of the target WiMAX link at the right. The co-located Proxy GW/ASN-GW proxies between the MN and the target WiMAX BS using MICF to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS. (a) shows the transport between MN and the co-located Proxy GW/ASN-GW through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

153

1234

567

89

10111213141516

17181920

2122232425262728

2930313233343536373839

40

41

42

43

44


(a)

Crtlmsg

Crtl msg

R6+ R6+

MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1) 3GPP

link L2(1) L2 L2 L2 L2 L2(2) frame

No WiMAX

linkL2(2) frame


WiMAXinterface

MN’s 3GPP

interface

3GPP eNB SFF/ ASN- GW WiMAX BS MN’s WiMAXinterface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2) control frame

L2(2) control frame

Control message

Control message


TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP



Figure R.7. Transport of WiMAX L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

Lacking MICF support in the WiMAX BS, the co-located Proxy GW/ASN-GW and the target WiMAX BS will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (R6+) of the R6 interface and is outside the scope of this standard.

The co-located Proxy GW/ASN-GW may then proxy between the MN and the target WiMAX BS using SRCF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the co-located Proxy GW/ASN-GW may map the message contents exchanged with the MN with that exchanged with the target WiMAX BS in performing proxy function. Figure R.8 shows the transport of WiMAX L2 frames between the MN and legacy WiMAX ASN where the single radio handover control function (SRCF) is supported neither between the MN and the Proxy GW/ASN-GW nor between the Proxy GW/ASN-GW and the target WiMAX BS. The co-located Proxy GW/ASN-GW proxies between the MN and the target WiMAX BS using an extension of R9 interface to communicate with the MN and using an extension of R6 interface to communicate with the target WiMAX BS.

154

1

23

4567

89

101112

13141516171819202122


L2(2) control frame

L2(2) control frame

Control message

Control message

R9+ R9+ R9+ R6+ R6+ R6+TCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPL2(1) L2 L2 L2


Figure R.8. Protocol stack showing the transport of WiMAX L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the co-located Proxy GW/ASN-GW will need certain mechanism to communicate with each other, such as an extension (R9+) of the R9 interface. The Proxy GW/ASN-GW and the target WiMAX BS will also need certain mechanism to communicate with each other, such as an extension (R6+) of the R6 interface.

The co-located Proxy GW/ASN-GW may then proxy between the MN and the target WiMAX BS using the R9+ to communicate with MN and using the R6+ to communicate with the target WiMAX BS.

Both R9+ and R6+ are both outside the scope of this standard.

[R.3.2] 3GPP to WiMAX Single Radio Handover processes

1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. These query and reply messages may use the IP connectivity of the source link. The message exchange between the MN and the ANDSF may use the S14 reference point between the MN and the ANDSF as defined in 3GPP. These messages are carried in IP packets and may therefore use the IP connectivity at the source link.

The ANDSF provides the MN with information about available networks and handover policy. It will also inform the MN whether the WiMAX ASN network available in the neighborhood supports SRHO, the presence of Proxy GW, and system information blocks of candidate PoAs to perform radio measurements.



The authentication messages are exchanged between the MN and the ASN-GW, which is the authenticator. These messages are L2 control frame messages in the target (WiMAX) network, which could have been exchanged via the target (WiMAX) link if the target link were available. When the target link is not available, the transport of the L2 control frame between the MN and the Proxy GW/ASN-GW is through the source (3GPP) network as described in Clause 11.6.2.1.The ASN-GW/Proxy GW processes the frame containing the L2 authentication message and may consult the AAA in the WiMAX CSN through the R3 interface.

The ASN-GW maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the Proxy GW/ASN-GW, the pre-registration is performed for the ASN network, which may have multiple PoA’s. When the MN attaches to a different

155

123

4567

89

10

11

12131415161718

192021

222324

2526

27282930313233

343536


target BS, it will use the existing registration context if the Proxy GW/ASN-GW already has this registration context.

The ASN-GW/Proxy GW combination also constructs control messages to communicate with the target WiMAX BS. In terms of exchange of these control messages, the ASN-GW/Proxy GW behaves like a virtual WiMAX BS located in the WiMAX network to communicate with the MN. Such control messages are equivalent to those in the handover from one BS to another BS within the same network. Therefore control messages may reuse those between the source PoA and target PoA within the same network to prepare the handover of a MN within the same network.

For messages from the ASN-GW/Proxy GW to the MN, they are tunneled to the MN via the 3GPP network. To the target WiMAX BS, the ASN-GW/Proxy GW acts like a virtual WiMAX radio interface.




(2) A WiMAX ASN network is selected.


4: WiMAX link preparation:


A target BS is selected. The MN may use the target interface to check the broadcast messages from the target BS to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.3.


5: SRHO execution process. In this process, the WiFi link is disconnected, the WiMAX radio is activated, and the WiMAX link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the 3GPP link layer address to the WiMAX link layer address, and future incoming packets are then routed to the WiMAX radio.

[R.4] WiMAX to WLAN single radio handover

The general reference model as it applies to WiMAX to WLAN single radio handover is illustrated in Figure R.9.

156

12

345678

910

1112

13

1415

16

1718

19

2021

222324

252627

28293031

32

3334


WLAN ANWiMAX ASN

MN before handover

MN during handover


Source PoA


ASN-GW

RyBS

WiMAXCSN


R3

AAA

DHCP

AP

GW

Target PoA

R6

R3

ARWiFi-SFF

WIF

Rz

W3

W1

Figure R.9 WiMAX to WLAN single radio handover reference model.


The Information repository function may be implemented in a Media Independent Information Server (MIIS) defined in this specification but may also be other information repository defined elsewhere, such as the ANDSF.

The WiFi Interworking Function (WIF) is defined in WiMAX Forum. It may co-locate at the access router (AR). In the event that it is not co-located there, the WIF communicates with the AR through the W3 interface.

The Proxy GW function is implemented in the combined functions of WiFi Interworking Function (WIF) and WiFi Proxy GW, which are defined in the WiMAX network. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA. The WiFi Signal Forwarding Function (Proxy GW) is defined in WiMAX Forum standard. It may co-locate at the access router (AR). In the event that it is not co-located there, the WiFi-Proxy GW communicates with the AR through the W1 interface.

Interfaces:

W1 interface between the WLAN AR and the WiFi Proxy GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

W3 interface between the WLAN AR and the WIF is defined in WiMAX Forum [WMF-T37-010-R016v01].

Ry interface between the MS and the WiFi Proxy GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

R3 interface between the WiMAX CSN and ASN is defined in WiMAX Forum [WMF-T37-010-R016v01].

R3+ interface between the WIF and AAA and also DHCP in the WiMAX CSN are defined in WiMAX Forum [WMF-T37-010-R016v01].

157

1

23

4

567

89

10

11121314151617

18

1920

2122

2324

25

2627


R6 interface between the WiMAX Proxy GW and ASN GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

[R.4.1] Transport of WLAN L2 control frames between MN and the WLAN AN

Figure R.10 shows the transport of WLAN L2 frames between the MN and the WLAN AN when the MN, the co-located Proxy GW/WIF/AR and the target WLAN AP all support single radio handover control function (SRCF), which is a media independent control function (MICF) in the IEEE 802-2010 architecture [IEEE P802-D1.4]. The WLAN radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WLAN network via the source WiMAX link at the left and in the absence of the target WLAN link at the right. The co-located Proxy GW/WIF/AR bridges between the MN and the target WLAN AP. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

MICF MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1)

WiMAXLink

L2(1) L2 L2 L2 L2 L2(2) frame

No WLAN

linkL2(2) frame


WLAN interface

MN’s WiMAXinterface

WiMAX BS SFF / WIF / AR WiFi AP MN’s WLAN

interface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

(b)

L2(2) control frame

L2(2) control frame

L2(2) control frame

MICF MICF MICFTCP or UDP/ IP



MN SFF /WIF / AR WiFi AP

Figure R.10. Transport of WLAN L2 frame of target interface via the co-located SFF/WIF/AR using the logical connection at the MICF, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

The SRCF interfaces with the TCP or UDP / IP layer through the Media Independent Control Service Access Point (MICSAP). The source WiMAX link enables the TCP or UDP / IP connection between the MN and the WiMAX network, which may then connect to the WLAN AN through the Internet or the WiMAX CSN. Therefore single radio handover control (SRC) frames may be exchanged between the SRCF in the MN and the SRCF in the Proxy GW/WIF/AR and/or the WLAN AP in the WLAN network using TCP or UDP / IP transport.

The SRCF also interfaces with the link-layer (L2) through the media independent control link-layer service access point (MICLSAP). An L2 frame is encapsulated with a SRCF header to constitute a SRC frame, which is exchanged between the MN and the target WLAN AP or the co-located Proxy GW/WIF/AR.

158

12

3

456789

1011

12

1314

15161718

192021222324

252627


The MN will query the Information Repository to find the candidate target WLAN AP. Based on the information from the Information Repository, the MN will then have some means to identify the target WLAN AP, such as the link-layer address in order to perform network entry procedure to the WLAN network using L2 packets.

It is required that the Information Repository need to know the IP address of the Proxy GW/WIF/AR, so that the MN and the Proxy GW/WIF/AR can exchange SRC frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target WLAN AP.

If the MN knows the IP address of the target WLAN AP, it will send the SRC frame to the SRCF in the target WLAN AP using TCP or UDP / IP transport.

If the MN does not know the IP address of the target WLAN AP, it will need at least something, such as the link-layer address, to identify the target WLAN AP. The SRC frame is first sent as the payload of a TCP or UDP / IP packet destined to the collocated Proxy GW/WIF/AR as described in Clause 11.4.3. The SRC frame contains information for the target WLAN network to identify the target WLAN AP. The co-located Proxy GW/WIF/AR will find out the IP address of the target WLAN AP and use this address as the destination address of a TCP or UDP / IP packet containing the SRC frame as payload to forward to the target WLAN AP.

The reply by the target WLAN AP is transported in a similar manner. If the target WLAN link were available, the target WLAN AP would send a L2 message back to the MN using this WLAN link. Lacking this target link, this L2 message is passed through the MICLSAP to become the payload of an SRC frame.

If the target PoA had received the SRC frame from the MN, the reply SRC frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target WLAN AP had received the SRC frame from the co-located Proxy GW/WIF/AR, the reply SRC frame will first use TCP or UDP / IP transport with an IP address destined to the Proxy GW/WIF/AR. At the co-located Proxy GW/WIF/AR, the TCP or UDP / IP header is extracted at the MICSAP at the input interface of the co-located Proxy GW/WIF/AR to retrieve the SRC frame. The SRCF function will pass the SRC frame through the MICSAP at the output interface of the co-located Proxy GW/WIF/AR to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Figure R.11 shows the transport of WLAN L2 frames between the MN and the WLAN AN when the MN, the co-located Proxy GW/WIF/AR support single radio handover control function (SRCF), which is a media independent control function (MICF) in the IEEE 802-2012?? architecture. Yet the target WLAN AP are legacy WLAN AP’s lacking MICF support. The WLAN target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the WLAN network via the source WiMAX link at the left and in the absence of the target WLAN link at the right. The co-located Proxy GW/WIF/AR proxies between the MN and the target WLAN AP using MICF to communicate with the MN and using an extension of R6 interface to communicate with the target WLAN AP. (a) shows the transport between MN and the co-located Proxy GW/WIF/AR through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

159

1234

567

89

10111213141516

171819

2021222324252627

28293031323334353637

38

39

40

41

42

43


(a)

Crtlmsg

Crtl msg

R6+ R6+

MICF MICF

SRCFTCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

SRCFTCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1) WiMAX


No WLAN

linkL2(2) frame


WLAN interface


WiMAX BS SFF/ WIF - AR WLAN AP MN’s WLAN

interface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2) control frame

L2(2) control frame

Control message

Control message

MI CF MICF h R6+ R6+TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

TCP or UDP/ IP

L2(1) L2 L2 L2PHY(1) PHY hdr PHY hdr PHY

MN SFF/ WIF –AR WLAN AP

Figure R.11. Transport of WLAN L2 frame of target interface to the co-located SFF/WIF-AR which proxy between the MN and the target PoA, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

Lacking MICF support in the WLAN AP, the co-located Proxy GW/WIF/AR and the target WLAN AP will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network and is outside the scope of this standard.

The co-located Proxy GW/WIF/AR may then proxy between the MN and the target WLAN AP using SRCF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the co-located Proxy GW/WIF/AR may map the message contents exchanged with the MN with that exchanged with the target WLAN AP in performing proxy function. Figure R.12 shows the transport of WLAN L2 frames between the MN and legacy WLAN AN where the single radio handover control function (SRCF) is supported neither between the MN and the Proxy GW/WIF/AR nor between the Proxy GW/WIF/AR and the target

160

1

23

4

5678

9101112

13141516171819


WLAN AP. The co-located Proxy GW/WIF/AR proxies between the MN and the target WLAN AP using an extension of R9 interface to communicate with the MN and using an extension of R6 interface to communicate with the target WLAN AP.

L2(2) control frame

L2(2) control frame

Control message

Control message

Ry+ Ry+ Ry+TCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPTCP or UDP

/ IPL2(1) L2 L2 L2

PHY(1) PHY PHY PHYMN SFF / WIF / AR WLAN AP

Figure R.12. Protocol stack showing the transport of WLAN L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the co-located Proxy GW/WIF/AR will need certain mechanism to communicate with each other, such as an extension (Ry+) of the Ry interface. The Proxy GW/WIF/AR and the target WLAN AP will also need certain mechanism to communicate with each other.

The co-located Proxy GW/WIF/AR may then proxy between the MN and the target WLAN AP using the Ry+ to communicate with MN and using some mechanism to communicate with the target WLAN AP.

Ry+ is outside the scope of this standard.

[R.4.2] WiMAX to WLAN Single Radio Handover processes

1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. These query and reply messages may use the IP connectivity of the source link.

The Information Repository provides the MN with information about available networks and handover policy. It will also inform the MN whether the WiFi access network (AN) available in the neighborhood supports SRHO, and channel and frequency information of the candidate APs to perform radio measurements.



(2) A WLAN network is selected.



161

123

4

567

89

10

1112

13

14

15161718

19202122

23

2425

26

2728

293031



The authentication messages are exchanged between the MN and the WLAN AP, which is the authenticator. These messages are L2 control frame messages in the target (WLAN) network, which could have been exchanged via the target (WLAN) link if the target link were available. When the target link is not available, the transport of the L2 control frame is through the source (WiMAX) network as described in Clause 11.6.3.1.

The Proxy GW (WIF/AR/WiFi-Proxy GW) processes the SRC frame containing the L2 authentication message and may consult the AAA in the WiMAX CSN through the R3 interface.

The Proxy GW (WIF/AR/WiFi-Proxy GW) maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the Proxy GW, the pre-registration is performed for the WiFi access network, which may have multiple AP’s. When the MN attaches to a different target AP, it will use the existing registration context if the Proxy GW already has this registration context.

The Proxy GW (WIF/AR/WiFi-Proxy GW combination) also constructs control messages to communicate with the target WLAN AP. In terms of exchange of these control messages, the WIF/AR/WiFi-Proxy GW behaves like a virtual WiFi AP located in the WiFi network to communicate with the MN. Such control messages are equivalent to those in the handover from one AP to another AP within the same network. Therefore control messages may reuse those between the source PoA and target PoA within the same network to prepare the handover of a MN within the same network.

For messages from the WIF/AR/WiFi-Proxy GW to the MN, they are tunneled to the MN via the WiMAX network. To the target WiFi AP, the WIF/AR/WiFi-Proxy GW acts like a virtual WLAN radio interface.


4: WLAN link preparation:

Before L3 handover occurs, the target link may perform preparation processes at L2, such as signal strength measurement and power management.

A target AP is selected. The MN may use the target interface to check the beacon messages from the target AP to confirm that there is sufficient signal strength.

5: SRHO execution process. In this process, the WiMAX link is disconnected, the WLAN radio is activated, and the WLAN link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WiMAX link layer address to the WLAN link layer address, and future incoming packets are then routed to the WLAN radio.

[R.5] WiMAX to 3GPP single radio handover

The general reference model as it applies to WiMAX to 3GPP single radio handover is illustrated in Figure R.13.

162

12

34567

89

1011121314

151617181920

2122

2324

25

2627

2829

30313233

34

3536


WiMAX ASN 3GPP network

MN before handover

MN during handover

MN after handover

MIIS orANDSF


Source PoA Target PoA


ASN-GW

S-GW

eNBBS

S2aS5/8

S11S1-U

S1-MME

S14

PCRFGxaGxcGx

AAA

HSSSWx

S6a

S6b

STa

GW R6

P-GW

MME

3GPP-SFF

X200

X202

Figure R.13 WiMAX to 3GPP single radio handover reference model.


The Information repository function is implemented in the ANDSF in the 3GPP network.

The Proxy GW function is implemented in the 3GPP-Proxy GW and the existing functions of Mobility Management Entity (MME) in the 3GPP EPS network. The 3GPP-Proxy GW and MME may co-locate. In the event that they are not co-located, they communicate with each other using interface X202. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA.

Reference Points:

S2a reference point between P-GW in the 3GPP EPS network and ASN GW in the WiMAX network is defined in the 3GPP network [3GPP TS23.402].

S14 reference points between UE and ANDSF is defined in the 3GPP network [3GPP TS23.402].

S5/8 reference point between P-GW and S-GW is defined in the 3GPP network [3GPP TS23.401].

S11 reference point between S-GW and MME is defined in the 3GPP network [3GPP TS23.401].

S1-U reference point between UE and S-GW is defined in the 3GPP network [3GPP TS23.401].

S1-MME reference point between UE and MME is defined in the 3GPP network [3GPP TS23.401].

S6a reference point between P-GW and AAA is defined in the 3GPP network [3GPP TS23.401].

S6b reference point between MME and HSS is defined in the 3GPP network [3GPP TS23.401].

163

1

23

4

5

6

789

101112

13

1415

16

17

18

19

20

21

22


SWx reference point between HSS and AAA is defined in the 3GPP network [3GPP TS23.401].

STa reference point between WiMAX ASN and AAA is defined in the 3GPP network [3GPP TS23.402].

Gx reference point between P-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

Gxa reference point between WiMAX ASN and PCRF is defined in the 3GPP network [3GPP TS23.402].

Gxc reference point between S-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

R6 interface between the WiMAX Proxy GW and ASN GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

X200 interface between MN and 3GPP-Proxy GW is defined in WiMAX Forum [WMF-T37-011-R016v01].

X202 interface between MME and 3GPP-Proxy GW is defined in WiMAX Forum [WMF-T37-011-R016v01].


Figure R.14 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the co-located 3GPP-Proxy GW/MME and the target 3GPP eNB all support single radio handover control function (SRCF), which is a media independent control function (MICF) in the 802-2010 architecture [IEEE P802-D1.4]. The 3GPP radio L2 control frame is transported as a payload of a media independent control frame between the MN and the 3GPP network via the source WiMAX link at the left and in the absence of the target 3GPP link at the right. The co-located 3GPP-Proxy GW/MME bridges between the MN and the target 3GPP eNB. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

MICF MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1)

WiMAXLink

L2(1) L2 L2 L2 L2 L2(2) frame

No 3GPP link

L2(2) frame

PHY(2) PHY(1) PHY(1) PHY PHY PHY PHY PHY(2) PHY(2)MN’s 3GPP

interface


WiMAX BS 3GPP -SFF MME 3GPP eNB MN’s 3GPP

interface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

164

1

2

3

4

5

67

89

1011

12

1314151617181920

21

2223

24

25

26

27


(b)

L2(2) control frame

L2(2) control frame

L2(2) control frame

MICF MICF MICFTCP or UDP/IP

TCP or UDP / IP TCP or UDP/IP


MN 3GPP - SFF MME 3GPP eNB

Figure R.14. Transport of 3GPP L2 frame of target interface via the co-located 3GPP-SFF/MME using the logical connection at the MICF, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

The SRCF interfaces with the TCP or UDP / IP layer through the Media Independent Control Service Access Point (MICSAP). The source WiMAX link enables the TCP or UDP / IP connection between the MN and the WiMAX network, which may then connect to the 3GPP network through the Internet or the WiMAX CSN. Therefore single radio handover control (SRC) frames may be exchanged between the SRCF in the MN and the SRCF in the 3GPP-Proxy GW/MME and/or the 3GPP eNB in the 3GPP network using TCP or UDP / IP transport.

The SRCF also interfaces with the link-layer (L2) through the media independent control link-layer service access point (MICLSAP). An L2 frame is encapsulated with a SRCF header to constitute a SRC frame, which is exchanged between the MN and the target 3GPP eNB or the co-located 3GPP-Proxy GW/MME.


It is required that the Information Repository need to know the IP address of the 3GPP-Proxy GW/MME, so that the MN and the 3GPP-Proxy GW/MME can exchange SRC frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target 3GPP eNB.

If the MN knows the IP address of the target 3GPP eNB, it will send the SRC frame to the SRCF in the target 3GPP eNB using TCP or UDP / IP transport.

If the MN does not know the IP address of the target 3GPP eNB, it will need at least something, such as the link-layer address, to identify the target 3GPP eNB. The SRC frame is first sent as the payload of a TCP or UDP / IP packet destined to the collocated 3GPP-Proxy GW/MME as described in Clause 11.4.3. The SRC frame contains information for the target 3GPP network to identify the target 3GPP eNB. The co-located 3GPP-Proxy GW/MME will find out the IP address of the target 3GPP eNB and use this address as the destination address of a TCP or UDP / IP packet containing the SRC frame as payload to forward to the target 3GPP eNB.

165

1

2345

6

789

101112

131415

16171819

202122

2324

25262728293031


The reply by the target 3GPP eNB is transported in a similar manner. If the target 3GPP link were available, the target 3GPP eNB would send a L2 message back to the MN using this 3GPP link. Lacking this target link, this L2 message is passed through the MICLSAP to become the payload of an SRC frame.

If the target PoA had received the SRC frame from the MN, the reply SRC frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target 3GPP eNB had received the SRC frame from the co-located 3GPP-Proxy GW/MME, the reply SRC frame will first use TCP or UDP / IP transport with an IP address destined to the 3GPP-Proxy GW/MME. At the co-located 3GPP-Proxy GW/MME, the TCP or UDP / IP header is extracted at the MICSAP at the input interface of the co-located 3GPP-Proxy GW/MME to retrieve the SRC frame. The SRCF function will pass the SRC frame through the MICSAP at the output interface of the co-located 3GPP-Proxy GW/MME to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Figure R.15 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the co-located 3GPP-Proxy GW/MME support single radio handover control function (SRCF), which is a media independent control function (MICF) in the IEEE 802-2012 architecture. Yet the target 3GPP eNB are legacy 3GPP eNB’s lacking MICF support. The 3GPP target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the 3GPP network via the source WiMAX link at the left and in the absence of the target 3GPP link at the right. The co-located 3GPP-Proxy GW/MME proxies between the MN and the target 3GPP eNB using MICF to communicate with the MN and using an extension of R6 interface to communicate with the target 3GPP eNB. (a) shows the transport between MN and the co-located 3GPP-Proxy GW/MME through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

Crtlmsg

Crtl msg

S1-MME+

S1-MME

MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1) WiMAX


No 3GPP link

L2(2) frame

PHY(2) PHY(1) PHY(1) PHY PHY PHY PHY PHY(2) PHY(2)MN’s 3GPP

interface


WiMAX BS 3GPP - SFF MME 3GPP eNB MN’s 3GPP

interface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

166

123

456789

1011

12131415161718192021

22

2324

25

26

27

28

29


L2(2) control frame

L2(2) control frame

Control message

Control message


TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP



Figure R.15. Transport of 3GPP L2 frame of target interface to the co-located 3GPP-SFF/MME which proxy between the MN and the target PoA, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

Lacking MICF support in the 3GPP eNB, the co-located 3GPP-Proxy GW/MME and the target 3GPP eNB will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (S1-MME+) of the S1-MME reference point and is outside the scope of this standard.

The co-located 3GPP-Proxy GW/MME may then proxy between the MN and the target 3GPP eNB using SRCF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the co-located 3GPP-Proxy GW/MME may map the message contents exchanged with the MN with that exchanged with the target 3GPP eNB in performing proxy function. Figure R.16 shows the transport of 3GPP L2 frames between the MN and legacy 3GPP network where the single radio handover control function (SRCF) is supported neither between the MN and the 3GPP-Proxy GW/MME nor between the 3GPP-Proxy GW/MME and the target 3GPP eNB. The co-located 3GPP-Proxy GW/MME proxies between the MN and the target 3GPP eNB using an extension of R9 interface to communicate with the MN and using an extension of R6 interface to communicate with the target 3GPP eNB.

L2(2) control frame

L2(2) control frame

Control message

Control message

X200+ X200 X200+ S1-MME+ S1-MME+

S1-MME+ hdr

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP



Figure R.16. Protocol stack showing the transport of 3GPP L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA.

167

1234

56789

10111213141516171819

20

212223


The MN and the co-located 3GPP-Proxy GW/MME will need certain mechanism to communicate with each other, such as an extension (X200+) of the X200 interface. The 3GPP-Proxy GW/MME and the target 3GPP eNB will also need certain mechanism to communicate with each other.

The co-located 3GPP-Proxy GW/MME may then proxy between the MN and the target 3GPP eNB using the X200+ to communicate with MN and using S1-MME+ to communicate with the target 3GPP eNB.

Both X200+ and S1-MME+ are outside the scope of this standard.

[R.5.2] WiMAX to 3GPP Single Radio Handover processes

1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. The message exchange between the MN and the ANDSF may use the S14 reference point between the MN and the ANDSF as defined in 3GPP. These messages are carried in IP packets and may therefore use the IP connectivity at the source link.

The ANDSF provides the MN with information about available networks and handover policy. It will also inform the MN whether the 3GPP EPS network available in the neighborhood supports SRHO, the presence of P-GW, and system information blocks of candidate PoAs to perform radio measurements.

While ANDSF may be present in the 3GPP network, the WiMAX network may also have ANDSF in its CSN.



(2) A 3GPP EPS network is selected.




The authentication messages are exchanged between the MN and the MME, which is the authenticator. These messages are L2 control frame messages in the target (3GPP) network, which could have been exchanged via the target (3GPP) link if the target link were available. When the target link is not available, the transport of the L2 control frame between the MN and the 3GPP-Proxy GW/MME combination is through the source (WiMAX) network as described in Clause 11.6.4.1.

The 3GPP-Proxy GW/MME processes the SRC frame containing the L2 authentication message. The MME may consult the HSS in the 3GPP EPS network through the S6a reference point.

The MME maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the MME, the pre-registration is performed for the 3GPP access network, which may have multiple eNB’s. When the MN attaches to a different target eNB, it will use the existing registration context if the MME already has this registration context.

168

123

45

6

7

89

10111213

141516

1718

19

2021

22

2324

252627

2829

3031323334

3536

37383940


The 3GPP-Proxy GW/MME combination also constructs control messages to communicate with the target 3GPP eNB. In terms of exchange of these control messages, the 3GPP-Proxy GW/MME behaves like a virtual 3GPP eNB located in the 3GPP network to communicate with the MN. Such control messages are equivalent to those in the handover from one eNB to another eNB within the same network. Therefore control messages may reuse those between the source PoA and target PoA within the same network to prepare the handover of a MN within the same network.

For messages from the 3GPP-Proxy GW/MME to the MN, they are tunneled to the MN via the WiMAX network. To the target 3GPP eNB, the 3GPP-Proxy GW/MME acts like a virtual 3GPP radio interface.

The MN may pre-register with the 3GPP network, using the same interface and transport mechanism as that in proactive authentication.

4: Target 3GPP link preparation:


A target eNB is selected. The MN may use the target interface to check the broadcast messages from the target eNB to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.3.

The 3GPP will check with the target eNB to reserve the radio channels needed for MN to attach to the 3GPP network. The channels needed for MN to operate in active or idle mode are assigned depending on whether the source radio was in the active or idle mode.

5: SRHO execution process. In this process, the WiMAX link is disconnected, the 3GPP radio is activated, and the 3GPP link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WiMAX link layer address to the 3GPP link layer address, and future incoming packets are then routed to the 3GPP radio.

[R.6] WLAN to 3GPP single radio handover

The general reference model as it applies to Non-trusted WLAN to 3GPP single radio handover is illustrated in Figure R.17.

169

123456

78

910

11

1213

141516

171819

20212223

24

2526


WLAN AN 3GPP network

MN before handover

MN during handover

MN after handover

MIIS orANDSF


Source PoA Target PoA


S-GW

eNBAP

S5/8

S11S1-U

S1-MME

S14

PCRFGxaGxcGx

AAA

HSSSWx

S6a

S6b

GW

P-GW

MME3GPP-SFF

RPmi

X202

AR

SWa

SWmePDG S2bSWn

Figure R.17 Non-trusted WLAN AN to 3GPP single radio handover reference model.


The Information repository function is implemented in the ANDSF in the 3GPP network.

The Proxy GW function is implemented in the 3GPP-Proxy GW and the existing functions of Mobility Management Entity (MME) in the 3GPP EPS network. The 3GPP-Proxy GW and MME may co-locate. In the event that they are not co-located, they communicate with each other using interface X202. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA.

Reference points:

S2c reference point between MN and the P-GW is defined in the 3GPP EPS network [3GPP TS23.402].

S2b reference point between ePDG and the P-GW is defined in the 3GPP EPS network [3GPP TS23.402].

S14 reference point between UE and ANDSF is defined in the 3GPP network [3GPP TS23.402].

S5/8 reference point between P-GW and S-GW is defined in the 3GPP network [3GPP TS23.401].

S11 reference point between S-GW and MME is defined in the 3GPP network [3GPP TS23.401].

S1-U reference point between UE and S-GW is defined in the 3GPP network [3GPP TS23.401].

S1-MME reference point between UE and MME is defined in the 3GPP network [3GPP TS23.401].

S6a reference point between P-GW and AAA is defined in the 3GPP network [3GPP TS23.401].

S6b reference point between MME and HSS is defined in the 3GPP network [3GPP TS23.401].

170

1

23

4

5

6

789

101112

13

14

15

16

17

18

19

20

21

22


SWa reference point between the non-trusted WLAN AN and AAA is defined in the 3GPP network [3GPP TS23.402].

SWn reference point between the non-trusted WLAN AN and ePDG is defined in the 3GPP network [3GPP TS23.402].

SWm reference point between ePDG and P-GW is defined in the 3GPP network [3GPP TS23.402].

SWx reference point between HSS and AAA is defined in the 3GPP network [3GPP TS23.401].

Gx reference point between P-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

Gxb reference point between ePDG and PCRF is defined in the 3GPP network [3GPP TS23.401].

Gxc reference point between S-GW and PCRF is defined in the 3GPP network [3GPP TS23.401].

RPmi interface between MN and 3GPP-Proxy GW.

X202 interface between MME and 3GPP-Proxy GW is defined in WiMAX Forum [WMF-T37-010-R016v01].


Figure R.18 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the co-located 3GPP-Proxy GW/MME and the target 3GPP eNB all support single radio handover control function (SRCF), which is a media independent control function (MICF) in the 802-2010 architecture [IEEE P802-D1.4]. The 3GPP radio L2 control frame is transported as a payload of a media independent control frame between the MN and the 3GPP network via the source WLAN link at the left and in the absence of the target 3GPP link at the right. The co-located 3GPP-Proxy GW/MME bridges between the MN and the target 3GPP eNB. (a) shows the transport through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

MICF MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1)

WLANLink

L2(1) L2 L2 L2 L2 L2(2) frame

No 3GPP link

L2(2) frame


MN’s 3GPP

interface

MN’s WLAN

interface

WLAN AP 3GPP -SFF MME 3GPP eNB MN’s 3GPP

interface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

171

12

34

5

6

7

8

9

10

1112

13

14

1516171819202122

23

2425

26


(b)

L2(2) control frame

L2(2) control frame

L2(2) control frame

MICF MICF hdr MICF hdr

TCP or UDP/IP

TCP or UDP / IP TCP or UDP/IP

L2(1) L2 L2 L2(1)

PHY(1) PHY PHY PHY(1)

MN 3GPP - SFF MME 3GPP eNB

Figure R.18. Transport of 3GPP L2 frame of target interface via the co-located 3GPP-SFF/MME using the logical connection at the MICF, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

The SRCF interfaces with the TCP or UDP / IP layer through the Media Independent Control Service Access Point (MICSAP). The source WLAN link enables the TCP or UDP / IP connection between the MN and the WLAN network, which may then connect to the 3GPP network through the Internet or the 3GPP EPC. Therefore single radio handover control (SRC) frames may be exchanged between the SRCF in the MN and the SRCF in the 3GPP-Proxy GW/MME and/or the 3GPP eNB in the 3GPP network using TCP or UDP / IP transport.

The SRCF also interfaces with the link-layer (L2) through the media independent control link-layer service access point (MICLSAP). An L2 frame is encapsulated with a SRCF header to constitute a SRC frame, which is exchanged between the MN and the target 3GPP eNB or the co-located 3GPP-Proxy GW/MME.


It is required that the Information Repository need to know the IP address of the 3GPP-Proxy GW/MME, so that the MN and the 3GPP-Proxy GW/MME can exchange SRC frames using TCP or UDP / IP transport. However, it may or may not be practical for MN to know the IP address of the target 3GPP eNB.

If the MN knows the IP address of the target 3GPP eNB, it will send the SRC frame to the SRCF in the target 3GPP eNB using TCP or UDP / IP transport.

If the MN does not know the IP address of the target 3GPP eNB, it will need at least something, such as the link-layer address, to identify the target 3GPP eNB. The SRC frame is first sent as the payload of a TCP or UDP / IP packet destined to the collocated 3GPP-Proxy GW/MME as described in Clause 11.4.3. The SRC frame contains information for the target 3GPP network to identify the target 3GPP eNB. The co-located 3GPP-Proxy GW/MME will find out the IP address of the target 3GPP eNB and use this address as the destination address of a TCP or UDP / IP packet containing the SRC frame as payload to forward to the target 3GPP eNB.

The reply by the target 3GPP eNB is transported in a similar manner. If the target 3GPP link were available, the target 3GPP eNB would send a L2 message back to the MN using this 3GPP link. Lacking this target link, this L2 message is passed through the MICLSAP to become the payload of an SRC frame.

If the target PoA had received the SRC frame from the MN, the reply SRC frame uses TCP or UDP / IP transport with an IP address destined to the MN. Yet if the target 3GPP eNB had received the SRC frame

172

1

2345

6789

1011

121314

15161718

192021

2223

24252627282930

313233

3435


from the co-located 3GPP-Proxy GW/MME, the reply SRC frame will first use TCP or UDP / IP transport with an IP address destined to the 3GPP-Proxy GW/MME. At the co-located 3GPP-Proxy GW/MME, the TCP or UDP / IP header is extracted at the MICSAP at the input interface of the co-located 3GPP-Proxy GW/MME to retrieve the SRC frame. The SRCF function will pass the SRC frame through the MICSAP at the output interface of the co-located 3GPP-Proxy GW/MME to form a new TCP or UDP / IP packet with an IP address destined to the MN.

Figure R.19 shows the transport of 3GPP L2 frames between the MN and the 3GPP network when the MN, the co-located 3GPP-Proxy GW/MME support single radio handover control function (SRCF), which is a media independent control function (MICF) in the IEEE 802-2012?? architecture. Yet the target 3GPP eNB are legacy 3GPP eNB’s lacking MICF support. The 3GPP target radio L2 control frame is transported as a payload of a media independent control frame between the MN and the 3GPP network via the source WLAN link at the left and in the absence of the target 3GPP link at the right. The co-located 3GPP-Proxy GW/MME proxies between the MN and the target 3GPP eNB using MICF to communicate with the MN and using an extension of R6 interface to communicate with the target 3GPP eNB. (a) shows the transport between MN and the co-located 3GPP-Proxy GW/MME through using MICLSAP and MICSAP. (b) shows the protocol stack resulting from the cross-layer encapsulation after passing through these two SAP’s.

(a)

Crtl msg Crtl msg

S1-MME+ S1-MME

MICF MICF

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(2) frame L2(1) WLAN


No 3GPP link

L2(2) frame


MN’s 3GPP

interface

MN’s WLAN

interface

WLAN AP 3GPP - SFF MME 3GPP eNB MN’s 3GPP

interface

MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)

L2(2) control frame

L2(2) ctrl frame

Control message

Control message


TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

L2(1) L2 L2 L2

PHY(1) PHY PHY PHY

MN 3GPP-SFF MME eNB

Figure R.19. Transport of 3GPP L2 frame of target interface to the co-located 3GPP-SFF/MME which proxy between the MN and the target PoA, showing (a) the MICLSAP and MICSAP, and (b) the resulting protocol stack.

173

123456

789

10111213141516

17

1819

20

21222324


Lacking MICF support in the 3GPP eNB, the co-located 3GPP-Proxy GW/MME and the target 3GPP eNB will need mechanism to communicate with each other. Certain control messages may already exist in the target network for network management purposes. The specific control messages needed may be defined in the specific target network such as an extension (S1-MME+) of the S1-MME reference point and is outside the scope of this standard.

The co-located 3GPP-Proxy GW/MME may then proxy between the MN and the target 3GPP eNB using SRCF to communicate with MN and using some other control messages to communicate with the target network. These control messages need to be comprehensive enough so that the co-located 3GPP-Proxy GW/MME may map the message contents exchanged with the MN with that exchanged with the target 3GPP eNB in performing proxy function. Figure R.20 shows the transport of 3GPP L2 frames between the MN and legacy 3GPP network where the single radio handover control function (SRCF) is supported neither between the MN and the 3GPP-Proxy GW/MME nor between the 3GPP-Proxy GW/MME and the target 3GPP eNB. The co-located 3GPP-Proxy GW/MME proxies between the MN and the target 3GPP eNB using an extension of RPmi interface to communicate with the MN and using an extension of S1-MME reference point to communicate with the target 3GPP eNB.

L2(2) control frame

L2(2) control frame

Control message

Control message

Rpmi+ RPmi+ Rpmi+ S1-MME+ hdr S1-MME+

S1-MME+ hdr

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP

TCP or UDP/IP



Figure R.20. Protocol stack showing the transport of 3GPP L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the co-located 3GPP-Proxy GW/MME will need certain mechanism to communicate with each other, such as an extension (RPmi+) of the RPmi interface. The 3GPP-Proxy GW/MME and the target 3GPP eNB will also need certain mechanism to communicate with each other.

The co-located 3GPP-Proxy GW/MME may then proxy between the MN and the target 3GPP eNB using the RPmi+ to communicate with MN and using S1-MME+ to communicate with the target 3GPP eNB.

Both RPmi+ and S1-MME+ are outside the scope of this standard.

[R.6.2] Non-trusted WLAN AN to 3GPP Single Radio Handover processes

1: Network discovery: The MN queries the Information Repository function, which may be the MIIS. Alternatively, other implementations of the Information Repository function such as the ANDSF may also be used. Then the discovery of ANDSF may be through DHCP according to procedures defined in IETF RFC 6153. The message exchange between the MN and the ANDSF may use the S14 reference point between the MN and the ANDSF as defined in 3GPP. These messages are carried in IP packets and may therefore use the IP connectivity at the source link.

The MIIS or ANDSF provides the MN with information about available networks and handover policy. It will also inform the MN whether the 3GPP EPS network available in the neighborhood supports SRHO, the

174

12345

6789

101112131415

16

171819

202122

2324

25

26

272829303132

3334


presence of ePDG, P-GW, and system information blocks of candidate PoAs to perform radio measurements.



(2) A 3GPP EPS network is selected.




The authentication messages are exchanged between the MN and the MME, which is the authenticator. These messages are L2 control frame messages in the target (3GPP) network, which could have been exchanged via the target (3GPP) link if the target link were available. When the target link is not available, the transport of the L2 control frame is through the source (WLAN) network as described in Clause 11.6.5.1.

The 3GPP-Proxy GW/MME processes the frame containing the L2 authentication message. The MME may consult the HSS in the 3GPP EPS network through the S6a reference point.

The MME maintains the higher layer registration context including the security keys and the data path information to maintain the IP session. By registering with the MME, the pre-registration is performed for the 3GPP access network, which may have multiple eNB’s. When the MN attaches to a different target eNB, it will use the existing registration context if the MME already has this registration context.

The 3GPP-Proxy GW/MME combination also constructs control messages to communicate with the target 3GPP eNB. In terms of exchange of these control messages, the 3GPP-Proxy GW/MME behaves like a virtual 3GPP eNB located in the 3GPP network to communicate with the MN. Such control messages are equivalent to those in the handover from one eNB to another eNB within the same network. Therefore control messages may reuse those between the source PoA and target PoA within the same network to prepare the handover of a MN within the same network.

For messages from the 3GPP-Proxy GW/MME to the MN, they are tunneled to the MN via the WiMAX network. To the target 3GPP eNB, the 3GPP-Proxy GW/MME acts like a virtual 3GPP radio interface.

The MN may pre-register with the 3GPP network, using the same interface and transport mechanism as that in proactive authentication.

4: Target 3GPP link preparation:


A target eNB is selected. The MN may use the target interface to check the broadcast messages from the target eNB to confirm that there is sufficient signal strength. In addition, limited message exchanges can be made using the target interface subjecting to the assumptions in Clause 11.3.

175

12

3

45

6

78

91011

1213

1415161718

1920

21222324

252627282930

3132

3334

35

3637

383940


The 3GPP will check with the target eNB and target 3GPP-Proxy GW/MME to reserve the radio channels needed for MN to attach to the 3GPP network. The channels needed for MN to operate in active or idle mode are assigned depending on whether the source radio was in the active or idle mode.

5: SRHO execution process. In this process, the WLAN link is disconnected, the 3GPP radio is activated, and the 3GPP link is established to complete the L3 handover. The association of the network layer address to the link layer address will change from the WLAN link layer address to the 3GPP link layer address, and future incoming packets are then routed to the 3GPP radio.

InsertAdd new Annex S

Annex R[Annex S] Handover Decision

(Informative)

To decide handover, three representative criteria are considerable for handover decision. Criteria to decide handover can be weak SINR (Signal to Interference plus Noise Ratio), QoS and/or cost, and the power consumption of the source link.

R.1 Weak SINR of the source link

Figure S.1- HO decision caused by weak SINR of the source link

Figure S.1 shows the case for weak SINR of the source link. Through Link_Going_Down.indication, the source link interface reports its weak SINR. Afterwards, the SR-MIHF orders the target link interface to initiate preregistration through Link_IF_PreReg_Ready.req. Link_IF_PreReg_Ready is needed, because preregistration is different from regular registration. While the L2 messages for regular registration are transmitted through the target link, the L2 messages for preregistration are transmitted through higher layer (TCP or UDP/IP) and the source link. After the target link interface prepares preregistration, the target link interface responds with Link_IF_PreReg_Ready.confirm.

176

123

4567

8

9

10

111213

14

1516

17

18192021222324


R.2 QoS and/or cost check

Figure S.2- HO decision caused by QoS and/or cost

Figure S.2 shows the case of QoS and/or cost check for HO decision. The source Proxy GW consults the QoS and/or cost with target Proxy GW through MIH_Get_Information. After source Proxy GW recommends the MN to perform handover, the source Proxy GW transmits MIH_IF_PreReg_Ready request message. The SR-MIHF of the MN orders the target link to pre-register through Link_IF_PregReg_Ready.

R.3 Power consumption comparison of the link interfaces

Figure S.3- HO decision caused by power consumption comparison

Figure S.3 shows the HO decision to reduce power consumption of the MN. The SR-MIHF of the MN ask power consumption of each link interface through Link_Get_Parameters.request with new LINK_PARAM_GEN value, which is 5, and thus the source link interface and the target link interface answers its average power consumption through Link_Get_Parameters.confirm. Afterwards, the SR-MIHF

177

1

23

4567

8

910

11121314


of the MN decides to perform handover through Link_IF_PreReg_Ready.request, and then the target link interface responds with Link_IF_PreReg_Ready.confirm.

Annex S

Insert new Annex T

(Informative)

Practical Uses of Proxy Function

When the MN wants to receive ANQP messages of access network information from the information server, the WLAN AP (Access Point) can perform as a proxy between the MN and information server as shown in Figure T.1 (a). As explained in Figure 57, if the information server supports Proxy Function and ANQP, the PoA can only encapsulate control messages with the MIHF header using MIH_CTRL_Transfer messages. This information server can be called as ANQP Proxy Server. The WLAN AP only encapsulates ANQP messages of the MN into MIH_CTRL_Transfer messasges and decapsulates MIH_CTRL_Transfer message of ANQP Proxy Server, as shown in Figure T.1 (b). The WLAN AP does not need to have all functions of the MIH. It means the WLAN AP as a proxy of the MN can be implemented by using Proxy Function.

(a) ANQP Transfer using the WLAN AP as a Proxy

(b) Protocol Stacks for ANQP Transfer

Figure T. 1 ANQP Transfer from ANQP Proxy Server

178

12

3

4

5

6

789

101112131415

16

17

18

19

20

2122

23

24

25


As extension of L2 message conversion in Figure 52, the control message conversion, as shown in Figure T.2, can be considered. If the corresponding network entity does not support Proxy Function, the Proxy converts the control message (Control Message A) into other control message (Control Message B) for the corresponding network entity. The Proxy operates as a proxy with other control message to communicate with other control network entity, and thus enhances mobility signaling.

Figure T.2 Proxy Function for Control Message Conversion

179

12345

6

78

9


If the information server does not support Proxy Function, the WLAN AP cannot communicate with the information server using the MIH_CTRL_Transfer messages. In this case, the Proxy bridges between the WLAN AP and the information server. The WLAN AP only encapsulates ANQP messages of the MN into MIH_CTRL_Transfer messasges and decapsulates MIH_CTRL_Transfer message of information server, as shown in Figure T.3 (a). Proxy converts the ANQP messages from the WLAN AP to the other control messages such as ANDSF messages and vice versa. Hence, the information server can communicate with the WLAN AP via the Proxy. To explain the ANQP conversion, the protocol stacks for MN, WLAN AP, Proxy, and information server are shown in Figure T.3 (b).

(a) ANQP Conversion using the Proxy

(b) Protocol Stacks for ANQP Conversion

Figure T.3 ANQP Conversion using Proxy

Annex T Handover Decision

(Informative)

Add

To decide handover, three representative criteria are considerable for handover decision. Criteria to decide handover can be weak SINR (Signal to Interference plus Noise Ratio), QoS and/or cost, and the power consumption of the source link.

180

1

23456789

1011

12

1314

15

16

17

18

192021


[S.1] Weak SINR of the source link

SRCF

Target Link Source Link

(1) Link_Going_Down.indication: Weak SINR is reported

(2) Link_IF_PreReg_Ready.request:Prepare pre-registration

MN Side

(3) Link_IF_PreReg_Ready.confirm: Respond to preparation of pre-registration

Figure S.1- HO decision caused by weak SINR of the source link

Figure S.1 shows the case for weak SINR of the source link. Through Link_Going_Down.indication, the source link interface reports its weak SINR. Afterwards, the SRCF orders the target link interface to prepare pre-registration through Link_IF_PreReg_Ready.req. Link_IF_PreReg_Ready is needed, because pre-registration is different from regular registration. While the L2 messages for regular registration are transmitted through the target link, the L2 messages for pre-registration are transmitted through higher layer (TCP or UDP/IP) and the source link. After the target link interface prepares pre-registration, the target link interface responds with Link_IF_PreReg_Ready.confirm.

181

1

2

34

5

6789

101112


[S.2] QoS and/or cost check

Source GW

SRCFSRCF

(3) MIH_IF_PreReg_Ready request: Prepare pre-registration of the

target network interface

Target GW

SRCF

(1) MIH_Get_Information request: Request monitored QoS and/or Cost of target network

(IE_COST, IE_NETWORK_QOS, etc.)

Target Link

(5) Link_IF_PreReg_Ready.confirm: Respond to preparation of pre-registration

(2) MIH_Get_Information response: Request monitored QoS and/or Cost of target network

(IE_COST, IE_NETWORK_QOS, etc.)(4) Link_IF_PreReg_Ready.request: Prepare pre-registration of the

target network interface

MN

Figure S.2- HO decision caused by QoS and/or cost

Figure S.2 shows the case of QoS and/or cost check for HO decision. The source Proxy GW consults the QoS and/or cost with target Proxy GW through MIH_Get_Information. After source Proxy GW recommends the MN to perform handover, the source Proxy GW transmits MIH_IF_PreReg_Ready request message. The SRCF of the MN orders the target link to pre-register through Link_IF_PregReg_Ready.

[S.3] Power consumption comparison of the link interfaces

MN SRCF

Target Link Source Link

(1) Link_Get_Parameters.request:Ask average power consumption in active state (LINK_PARAM_GEN=5)

(3) LINK_IF_PreReg_Ready.request

MN Side

(4) LINK_IF_PreReg_Ready.confirm

(2) Link_Get_Parameters.confirm: Respond with average power consumption

in active state(LINK_PARAM_GEN=5)

(1) Link_Get_Parameters.request:Ask average power consumption in active state (LINK_PARAM_GEN=5)

(2) Link_Get_Parameters.confirm: Respond with average power consumption

in active state(LINK_PARAM_GEN=5)

Figure S.3- HO decision caused by power consumption comparison

Figure S.3 shows the HO decision to reduce power consumption of the MN. The SRCF of the MN ask power consumption of each link interface through Link_Get_Parameters.request with new

182

1

2

34

5678

9

10

1112

1314


LINK_PARAM_GEN value, which is 5, and thus the source link interface and the target link interface answers its average power consumption through Link_Get_Parameters.confirm. Afterwards, the SRCF of the MN decides to perform handover through Link_IF_PreReg_Ready.request, and then the target link interface responds with Link_IF_PreReg_Ready.confirm.

183

1234

5