ieee standards - draft standard template · web viewthis is an unapproved ieee standards draft,...

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

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 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

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

13

14

15

161718

19

202122232425


([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


12

345


Abstract: <Select this text and type or paste Abstract—contents of the Scope may be used>Keywords: <Select 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.


123

4

56789

1011

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 document specifies optimizations to reduce the latency during single radio handovers between heterogeneous access networks.

Contents

viiCopyright © 2012 IEEE. All rights reserved.


1

23

456

7


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

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

3. Definitions ....................................................................................................................................................3

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 Information Repository .......................................................................................6

5.5 MIHF reference models for link-layer technologies .............................................................................65.5.1 ............................................................................................................................65.5.2 General MIHF reference model and SAPs .........................................................6

6. MIH Services ................................................................................................................................................66.1 ................................................................................................................................................................66.2 ................................................................................................................................................................66.3 ................................................................................................................................................................66.4 ................................................................................................................................................................66.5 Media independent information service ................................................................................................6

viiiCopyright © 2012 IEEE. All rights reserved.


12345

6

7

8

91011121314151617181920212223242526272829303132333435363738

394041424344


6.5.1 ............................................................................................................................66.5.2 ............................................................................................................................66.5.3 ............................................................................................................................66.5.4 Information Elements .........................................................................................6

7. Service Access Point (SAP) and primitives .................................................................................................77.1 ................................................................................................................................................................77.2 ................................................................................................................................................................77.3 MIH_LINK_SAP primitives .................................................................................................................7

7.3.1 ............................................................................................................................77.3.2 ............................................................................................................................77.3.3 ............................................................................................................................77.3.4 ............................................................................................................................77.3.5 ............................................................................................................................77.3.6 ............................................................................................................................77.3.7 ............................................................................................................................77.3.8 ............................................................................................................................77.3.9 ............................................................................................................................77.3.10 ..........................................................................................................................77.3.11 ..........................................................................................................................77.3.12 ..........................................................................................................................77.3.13 ..........................................................................................................................77.3.14 ..........................................................................................................................77.3.15 Link_IF_PreReg_Ready ...................................................................................7

7.4 MIH_SAP primitives .............................................................................................................................87.4.1 ............................................................................................................................87.4.2 ............................................................................................................................87.4.3 ............................................................................................................................87.4.4 ............................................................................................................................87.4.5 ............................................................................................................................87.4.6 ............................................................................................................................87.4.7 ............................................................................................................................87.4.8 ............................................................................................................................87.4.9 ............................................................................................................................87.4.10 ..........................................................................................................................87.4.11 ..........................................................................................................................87.4.12 ..........................................................................................................................87.4.13 ..........................................................................................................................87.4.14 ..........................................................................................................................87.4.15 ..........................................................................................................................87.4.16 ..........................................................................................................................87.4.17 ..........................................................................................................................87.4.18 ..........................................................................................................................87.4.19 ..........................................................................................................................87.4.20 ..........................................................................................................................87.4.21 ..........................................................................................................................87.4.22 ..........................................................................................................................8

ixCopyright © 2012 IEEE. All rights reserved.


1234

56789

10111213141516171819202122232425262728293031323334353637383940414243444546


7.4.23 ..........................................................................................................................87.4.24 ..........................................................................................................................87.4.25 ..........................................................................................................................87.4.26 ..........................................................................................................................87.4.27 ..........................................................................................................................87.4.28 ..........................................................................................................................87.4.29 MIH_LL_Transfer ............................................................................................87.4.30 MIH_N2N_LL_Transfer ................................................................................127.4.31 MIH_IF_PreReg_Ready .................................................................................167.4.32 MIH_TNMN_SA_Estab .................................................................................187.4.33 MIH_N2N_MNTN_SA_Estab .......................................................................22

7.5 ..............................................................................................................................................................267.6 ..............................................................................................................................................................26

8. Media independent handover protocols ......................................................................................................268.1 ..............................................................................................................................................................268.2 ..............................................................................................................................................................268.3 ..............................................................................................................................................................268.4 MIH protocol frame format .................................................................................................................26

8.4.1 General frame format ........................................................................................268.5 ..............................................................................................................................................................268.6 MIH protocol messages .......................................................................................................................26

8.6.1 ..........................................................................................................................268.6.2 ..........................................................................................................................268.6.3 MIH messages for command service ................................................................268.6.4 MIH messages for gateway service ..................................................................30

9. MIH protocol protection .............................................................................................................................319.1 ..............................................................................................................................................................319.2 Key establishment through an MIH service access authentication .....................................................31

9.2.1 ..........................................................................................................................319.2.2 Key derivation and key hierarchy .....................................................................31

10. Proactive Authentication ..........................................................................................................................3210.1 Media specific proactive authentication ............................................................................................3210.2 ...........................................................................................................................................................3410.3 Establishing Security Association roaming partners for MIH ...........................................................34

10.3.1 Key distribution by SPoS ................................................................................3510.3.2 TPoS selection by SPoS ..................................................................................36

11. Single Radio Handover .............................................................................................................................3711.1 Introduction (keep in reduced version) ..............................................................................................37

11.1.1 Proxy Gateway ................................................................................................3711.1.2 Media Independent Control Function <exhibit as evolution of figure 4, section 5.5.2> .............................................................................................................3811.1.3 Single Radio handover Control Function <fold into MICF / MIHF, perhaps SR-MIHF> .................................................................................................................3811.1.4 Transport of L2 network entry PDU of the target radio <redundant to fig. 4, section 5> ...................................................................................................................39

xCopyright © 2012 IEEE. All rights reserved.


123456789

10111213

141516171819202122232425

2627282930

313233343536

373839404142434445


11.1.5 Communication between the MN and the target PoA <…? Similarly depends on proxy discussion; move GW figures to GW section??> .......................................40

11.2 Single radio handover overall processes <keep, revise according to TG discussion> ......................42

12. Gateway Service .......................................................................................................................................4412.1 Introduction .......................................................................................................................................4412.2 L2 Message Transfer (SID=5, AID=1) .............................................................................................4512.3 Interworking Protocol Delivery (SID=5, AID>1) .............................................................................45

12.3.1 Examples of Interworking Protocol Delivery: ANQP Delivery .....................46

Annex A ..........................................................................................................................................................48

Bibliography ...................................................................................................................................................48

Annex B ..........................................................................................................................................................49

Annex C ..........................................................................................................................................................49

Annex D ..........................................................................................................................................................49

Annex E ..........................................................................................................................................................49

Annex F ..........................................................................................................................................................49F.1 .............................................................................................................................................................49F.2 .............................................................................................................................................................49F.3 Derived data types ...............................................................................................................................49

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

Annex G ..........................................................................................................................................................51

Annex H ..........................................................................................................................................................52

Annex I ...........................................................................................................................................................52

Annex J ...........................................................................................................................................................52

xiCopyright © 2012 IEEE. All rights reserved.


123

45678

9

10

11

12

13

14

1516171819202122232425262728293031323334

35

36

37

38


Annex K ..........................................................................................................................................................52

Annex L ..........................................................................................................................................................52

Annex M .........................................................................................................................................................53

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

Annex O ..........................................................................................................................................................58

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

Annex Q Network discovery for single radio handover .................................................................................59Q.1 Listening to the target link ..................................................................................................................59Q.2 Using location information .................................................................................................................60Q.3 Using user schedule information ........................................................................................................60

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

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

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

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

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

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

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

1. Overview ......................................................................................................................................................2

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

3. Definitions ..................................................................................................................................................32

xiiCopyright © 2012 IEEE. All rights reserved.


1

2

3

456789

1011

12

13

14151617

181920212223242526272829303132333435

36373839

40

41

42


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

5. General architecture ....................................................................................................................................43

6. MIH Services ..............................................................................................................................................436.1 ..............................................................................................................................................................636.2 ..............................................................................................................................................................636.3 ..............................................................................................................................................................636.4 ..............................................................................................................................................................636.5 Media independent information service ..............................................................................................63

6.5.1 Information Element .........................................................................................636.5.2 IE Containers ....................................................................................................74

7. Service Access Point (SAP) and primitives ...............................................................................................747.1 ..............................................................................................................................................................747.2 ..............................................................................................................................................................747.3 MIH_LINK_SAP primitives ...............................................................................................................74

7.3.1 ..........................................................................................................................747.3.2 ..........................................................................................................................747.3.3 ..........................................................................................................................747.3.4 ..........................................................................................................................747.3.5 ..........................................................................................................................747.3.6 ..........................................................................................................................747.3.7 ..........................................................................................................................747.3.8 ..........................................................................................................................747.3.9 ..........................................................................................................................747.3.10 ........................................................................................................................747.3.11 ........................................................................................................................747.3.12 ........................................................................................................................747.3.13 ........................................................................................................................747.3.14 ........................................................................................................................747.3.15 Link_IF_PreReg_Ready .................................................................................74

7.4 MIH_SAP primitives ...........................................................................................................................967.4.1 ..........................................................................................................................967.4.2 ..........................................................................................................................967.4.3 ..........................................................................................................................967.4.4 ..........................................................................................................................967.4.5 ..........................................................................................................................967.4.6 ..........................................................................................................................967.4.7 ..........................................................................................................................967.4.8 ..........................................................................................................................967.4.9 ..........................................................................................................................967.4.10 ........................................................................................................................967.4.11 ........................................................................................................................967.4.12 ........................................................................................................................967.4.13 ........................................................................................................................967.4.14 ........................................................................................................................967.4.15 ........................................................................................................................967.4.16 ........................................................................................................................96

xiiiCopyright © 2012 IEEE. All rights reserved.


1

2

3456789

10

111213141516171819202122232425262728293031323334353637383940414243444546


7.4.17 ........................................................................................................................967.4.18 ........................................................................................................................967.4.19 ........................................................................................................................967.4.20 ........................................................................................................................967.4.21 ........................................................................................................................967.4.22 ........................................................................................................................967.4.23 ........................................................................................................................967.4.24 ........................................................................................................................967.4.25 ........................................................................................................................967.4.26 ........................................................................................................................967.4.27 ........................................................................................................................967.4.28 ........................................................................................................................967.4.29 MIH_LL_Transfer ..........................................................................................967.4.30 MIH_N2N_LL_Transfer ..............................................................................1297.4.31 _IF_PreReg_Ready .....................................................................................17147.4.32 MIH_TNMN_SA_Estab .............................................................................18157.4.33 MIH_N2N_MNTN_SA_Estab ...................................................................2219

7.5 ..........................................................................................................................................................26237.6 ..........................................................................................................................................................2623

8. Media independent handover protocols ..................................................................................................26238.1 ..........................................................................................................................................................26238.2 ..........................................................................................................................................................26238.3 ..........................................................................................................................................................26238.4 MIH protocol frame format .............................................................................................................2623

8.4.1 General frame format ....................................................................................26238.5 ..........................................................................................................................................................26238.6 MIH protocol messages ...................................................................................................................2623

8.6.1 ......................................................................................................................26238.6.2 ......................................................................................................................26238.6.3 MIH messages for command service ............................................................26238.6.4 MIH messages for gateway service ..............................................................3027

9. MIH protocol protection .........................................................................................................................31289.1 ..........................................................................................................................................................31289.2 Key establishment through an MIH service access authentication .................................................3128

9.2.1 ......................................................................................................................31289.2.2 Key derivation and key hierarchy .................................................................3128

10. Proactive Authentication ......................................................................................................................322910.1 Media specific proactive authentication ........................................................................................3229

11. Single Radio Handover .........................................................................................................................373111.1 Introduction ...................................................................................................................................3731

11.1.1 Need for single radio handover ...................................................................443111.1.2 Relationship to other network standards .....................................................443111.1.3 Single radio versus dual radio handover .....................................................443111.1.4 Media independent single radio handover ..................................................4532

11.2 Requirements of Single Radio Handover ......................................................................................453211.3 Assumptions of Single Radio Handover .......................................................................................4633

xivCopyright © 2012 IEEE. All rights reserved.


123456789

10111213141516171819

202122232425262728293031

3233343536

3738

3940414243444546


11.4 SRHO Reference Model ................................................................................................................473411.4.1 Link configurations .....................................................................................473411.4.2 Information Repository ...............................................................................483511.4.3 Proxy Gateway ............................................................................................493611.4.4 Media Independent Control Function .........................................................513811.4.5 Single Radio handover Control Function ...................................................513811.4.6 Transport of L2 network entry PDU of the target radio .............................523911.4.7 Communication between the MN and the target network ..........................534011.4.8 Communication between the MN and the target PoA ................................5340

11.5 Single radio handover overall processes .......................................................................................564311.6 Securing Single-Radio messages using PoS ..................................................................................5744

11.6.1 Overview .....................................................................................................574411.6.2 Protecting communications between serving PoS and target PoS ..............6148

12. Gateway Service ...................................................................................................................................614812.1 Introduction ...................................................................................................................................614812.2 L2 Message Transfer (SID=5, AID=1) .........................................................................................624812.3 Interworking Protocol Delivery (SID=5, AID>1) .........................................................................6249

12.3.1 Examples of Interworking Protocol Delivery: ANQP Delivery .................6350

Annex A ......................................................................................................................................................6552

Bibliography ...............................................................................................................................................6552

Annex B ......................................................................................................................................................6652

Annex C ......................................................................................................................................................6652

Annex D ......................................................................................................................................................6652

Annex E ......................................................................................................................................................6652

Annex F ......................................................................................................................................................6652F.1 .........................................................................................................................................................6652F.2 .........................................................................................................................................................6652F.3 Derived data types ...........................................................................................................................6652

F.3.1 ......................................................................................................................6652F.3.2 ......................................................................................................................6652F.3.3 ......................................................................................................................6652F.3.4 Data types for link identification and manipulation .....................................6652F.3.5 ......................................................................................................................6754F.3.6 ......................................................................................................................6754F.3.7 ......................................................................................................................6754F.3.8 Data types for information elements ............................................................6754F.3.9 .......................................................................................................................6754F.3.10 .....................................................................................................................6754F.3.11 .....................................................................................................................6754F.3.12 .....................................................................................................................6754F.3.13 ....................................................................................................................6854F.3.14 ....................................................................................................................6854

xvCopyright © 2012 IEEE. All rights reserved.


123456789

10111213

1415161718

19

20

21

22

23

24

252627282930313233343536373839404142


F.3.15 ....................................................................................................................6854F.3.16 Data type for security .................................................................................6854

Annex G ......................................................................................................................................................6855

Annex H ......................................................................................................................................................6955

Annex I .......................................................................................................................................................6955

Annex J .......................................................................................................................................................6955

Annex K ......................................................................................................................................................6955

Annex L ......................................................................................................................................................6955

Annex M .....................................................................................................................................................7056

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

Annex O ......................................................................................................................................................7561

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

Annex Q Network discovery for single radio handover .............................................................................7662

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

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

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

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

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

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

xviCopyright © 2012 IEEE. All rights reserved.


12

3

4

5

6

7

8

9

1011121314151617

18

19

20

2122232425262728293031323334353637383940


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

xviiCopyright © 2012 IEEE. All rights reserved.


12345


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.4 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. 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.

2. Normative references

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.

2

12

3456789

10

11

15

16

17

18

192021

2223

2425

2627

282930313233

34

35

3637

383940


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

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

Proxy Gateway (GW): A gateway to bridge the mobility signaling between a mobile node (MN) and a target network 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-registration and proactive authentication of the MN.

Single radio handover (SRHO): A handover among 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 Service Access Point (MICSAP) so that it may exchange SRC frames with remote SRCF entities through IP transport. The exchanged SRC frames are processed by the SRCF which has the assigned transport layer protocol’s port number. SRCF also interfaces with the link-layer (L2) through the Media independent Control Link-layer Service Access Point (MICLSAP) so that it may provide transport of L2 frames of a deactivated target radio to and from a remote SRCF entity.

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

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

4. Abbreviations and acronyms

ANDSF Access Network network Discovery discovery Selection selection Functionsfunctions

MICF Media media Independent independent Control control Functionfunction

MICSAP Media media Independent independent Control control Service service Access access Pointpoint

MICLSAP Media media independent Control control Linklink-layer Service service Access access Pointpoint

3

12

3

4

5

6

7

89

10111213

1415

161718192021222324

2526

2728

29

30

31

32

3334

3536


PoS Point point of Serviceservice

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

SRHO Single single Radio radio Handoverhandover

SPoS Serving serving PoS

TPoS Target target PoS

5. General architecture

5.1 Introduction

5.1.10 Media independent single radio handover

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 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, as much of the handover signaling (including security establishment) needs to be accomplished before the handover actually occurs; this preparatory signaling is called preregistration. 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. 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

4

1

2

3

4

5

6

7

17

18192021222324

2526272829303132333435

36373839404142

434445464748


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.

5.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.

5.1.12

5.2 General design principles

5.2.3 Single Radio Handover MIHF (SR-MIHF) Design Principles

The following assumptions apply during the single radio handover: (*** are the assumptions moved to Clause 1.4?***)

a) While the source radio is transmitting, the target radio cannot transmit; the mobile device can transmit on only one radio at a time. Some single-radio devices may have the capability to receive on multiple radios at the same time, but that capability is not used in the 802.21 media-independent design.

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

The following requirements facilitate single radio handover between different radio access technology networks.

Functional Requirements for SR-MIHF:

a) tunneling mechanism to deliver the pre-registration messages

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

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

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

2) Supported target network capabilities

3) Any required layer-2 parameters

5

12345

6

789

1011121314151617

18

19

22

2324

25262728

2930

3132

33

34

35

36

37

38

39


5.3 MIHF service overview5.3.4 Media independent information service

5.4 Media independent handover reference framework5.4.4 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) or may be implemented as the Access Network Discovery and Selection Function (ANDSF) defined in 3GPP standard [3GPP TS23.402].

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.4.5 General MIHF reference model and SAPs / Single Radio handover Control Function <was 11.1.2 -- fold into 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 4 (above in this section 5.5.2) the Single Radio handover Control Function (SRCF) in a multiple interface node is implemented using the media independent control function (MIHF) in the control plane.

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 MIHF (SR-MIHF) of a multiple interface mobile.

The SR-MIHF uses MICSAP (same as MIH-SAP) for communication via TCP/IP or UDP/IP. The SRCF similarly interfaces with the link-layer (L2) MICLSAP (same as MIH_LINK_SAP) as before. An L2 frame

6

15

61011121314

15161718192021

2223242526

2728293031323334

3536

373839

4041


of a deactivated link (e.g., interface 2) may therefore be encapsulated with a MIHF header which can then be exchanged via MICSAP and/or MIH_NET_SAP.

5.4.6 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.

5.5 MIHF reference models for link-layer technologies

5.5.1

General MIHF reference model and SAPs

7

12

3

45

6789

10

11

12

13

14


6. MIH Services

6.1[5.2]

6.2[5.3]

6.3[5.4]

6.4[5.5]

6.5[5.6] Media independent information service

6.5.1[5.6.1]

6.5.2

6.5.3

6.5.4 Information ElementsThe 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).

Insert information elements in Table 10 as follows:

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

Table 10 — Information ElementName 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

8

1

2

3

4

5

6

7

8

9

1011121314

1516

17

18

19

20

21

22

23

24

25

26

27

28


[5.6.2] 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

9

1234

5

6

7

8


7.[6.] Service Access Point (SAP) and primitives

7.1[6.1]

7.2[6.2]

7.3[6.3] MIH_LINK_SAP primitives

7.3.1[6.3.1]

7.3.2[6.3.2]

7.3.3[6.3.3]

7.3.4[6.3.4]

7.3.5[6.3.5]

7.3.6[6.3.6]

7.3.7[6.3.7]

7.3.8[6.3.8]

7.3.9[6.3.9]

7.3.10[6.3.10]

7.3.11[6.3.11]

7.3.12[6.3.12]

7.3.13[6.3.13]

7.3.14[6.3.14]

7.3.15[6.3.15] Link_IF_PreReg_Ready

7.3.15.1[6.3.15.1] Link_IF_PreReg_Ready.request

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

7.3.15.1.2[6.3.15.1.2] Semantics of service primitiveLink_IF_PreReg_Ready.request (

ExecutionDelay

)

Parameters:

10

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

2122

2324

25

26

27


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.

7.3.15.1.3[6.3.15.1.3] When generatedThis primitive is generated by the SRCF to prepare pre-registration of the target link.

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

7.3.15.2[6.3.15.2] Link_IF_PreReg_Ready.confirm

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

7.3.15.2.2[6.3.15.2.2] Semantics of service primitiveLink_IF_PreReg_Ready.confirm (

Status

)

Parameters:

Name Data type DescriptionStatus STATUS Status of the operation.

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

7.3.15.2.4[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-registration

11

1

23

4567

8

91011

1213

14

15

16

17

1819

202122

23


7.4[6.4] MIH_SAP primitives

7.4.1[6.4.1]

7.4.2[6.4.2]

7.4.3[6.4.3]

7.4.4[6.4.4]

7.4.5[6.4.5]

7.4.6[6.4.6]

7.4.7[6.4.7]

7.4.8[6.4.8]

7.4.9[6.4.9]

7.4.10[6.4.10]

7.4.11[6.4.11]

7.4.12[6.4.12]

7.4.13[6.4.13]

7.4.14[6.4.14]

7.4.15[6.4.15]

7.4.16[6.4.16]

7.4.17[6.4.17]

7.4.18[6.4.18]

7.4.19[6.4.19]

7.4.20[6.4.20]

7.4.21[6.4.21]

7.4.22[6.4.22]

7.4.23[6.4.23]

7.4.24[6.4.24]

7.4.25[6.4.25]

7.4.26[6.4.26]

7.4.27[6.4.27]

12

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


7.4.28[6.4.28]

7.4.29[6.4.29] MIH_LL_Transfer

7.4.29.1[6.4.29.1] MIH_LL_Transfer.request

7.4.29.1.1[6.4.29.1.1] FunctionThis primitive carries link-layer frames between the MN and a MIHF at the MN’s local PoS.

7.4.29.1.2[6.4.29.1.2] Semantics of service primitive MIH_LL_Transfer.request (

DestinationIdentifier,

TargetLinkIdentifier,

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

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)

7.4.29.1.3[6.4.29.1.3] When generatedThis primitive is generated by an MIH user to send a link-layer frame for pre-registration to the target PoSstart an authentication and association process based on link-layer frames.

7.4.29.1.4[6.4.29.1.4] Effect on receiptAfter reception of this primitive, the MIHF must generate an MIH_LL_Transfer request message towards the MIHF of the serving PoS, which must relay the link-layer frames transported in this message to the target PoS.

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

13

1

2

3

45

67

8

9

10

11

12

13

14

15

16

171819

20212223

1


7.4.29.2[6.4.29.2] MIH_LL_Transfer.indication

7.4.29.2.1[6.4.29.2.1] FunctionThis primitive is used by the remote MIHF to notify the corresponding MIH user about the reception of an MIH_LL_Transfer request message.

7.4.29.2.2[6.4.29.2.2] Semantics of service primitiveMIH_LL_Transfer.indication (

SourceIdentifier,


LLInformation,

TPoSIdentifier,

CandidateLinkList

)

Parameters:

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

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 This carries link layer frames. This attribute shall be included if the target link is known.

TPoSIdentifier TPoSMIHF_ID (Optional) This identifies the target PoSCandidateLinkList 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.

7.4.29.2.3[6.4.29.2.3] When generatedThis primitive is generated by a remote MIHF after receiving an MIH_LL_Transfer request message.

7.4.29.2.4[6.4.29.2.4] Effect on receiptThe MIH user must generate an MIH_LL_Transfer.response primitive or 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.

7.4.29.3[6.4.29.3] MIH_LL_Transfer.response

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

7.4.29.3.2[6.4.29.3.2] Semantics of service primitiveMIH_LL_Transfer.response (



14

1

234

56

7

8

9

10

11

12

13

14

1516

17181920

21

2223

2425

26

1



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_Transfer.indication contained LLInformation.

MNnetworkaccessid NAI (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 PoSStatus STATUS Status of the operation.

7.4.29.3.3[6.4.29.3.3] When generatedThis primitive is generated after receiving an MIH_LL_Transfer.indication primitive and possibly after receiving an MIH_N2N_LL_Transfer.confirm primitive from the local MIHF.

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

7.4.29.4[6.4.29.4] MIH_LL_Transfer.confirm

7.4.29.4.1[6.4.29.4.1] FunctionThis primitive is used to notify the corresponding MIH user about the reception of an MIH_LL_Transfer response message.

7.4.29.4.2[6.4.29.4.2] Semantics of service primitiveMIH_LL_Transfer.confirm (

SourceIdentifier,


LLInformation,

MNnetworkaccessid,

TPoSIdentifier,

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

15

1

2

3

4

5

6

7

89

10

111213

14

151617

1819

20

21

22

23

24

25

1


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_Transfer.request contained LLInformation.

MNnetworkaccessid NAI(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 PoSStatus STATUS Status of the operation.

7.4.29.4.3[6.4.29.4.3] When generatedThis primitive is generated by the local MIHF after receiving an MIH_LL_Transfer response message.

7.4.29.4.4[6.4.29.4.4] Effect on receiptThe MIH user on the MN may generate an MIH_LL_Transfer.request primitive unless the authentication or association processes are completed.

7.4.30[6.4.30] MIH_N2N_LL_TransferThe primitives defined are to transport media link-layer frames for the target link over the MIH protocol between the serving PoS and the target PoS. The media specific authentication is conducted with the media specific authenticator deployed in the target PoA Pre-registration is conducted between the MN and the traget PoA. As part of pre-registration, media specific authentication may be conducted with the media specific authenticator deployed in the target PoA..

7.4.30.1[6.4.30.1] MIH_N2N_LL_Transfer.request

7.4.30.1.1[6.4.30.1.1] FunctionThis primitive is used to transport link layer frames between the serving PoS and the target PoS.

7.4.30.1.2[6.4.30.1.2] Semantics of Service PrimitiveMIH_N2N_LL_Transfer.request (



LLInformation,

MNID,

CandidateLinkList

)

Parameters:


16

1

2

34

567

89

10111213

14

1516

1718

19

20

21

22

23

24

25

1



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.

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.

7.4.30.1.3[6.4.30.1.3] When generatedThis primitive is generated by the serving PoS to relay link layer frames to the target PoS when the serving PoS receives an MIH_LL_Transfer request message.

7.4.30.1.4[6.4.30.1.4] Effect on receiptThe local MIHF shall generate an MIH_N2N_LL_Transfer request message to the remote MIHF.

7.4.30.2[6.4.30.2] MIH_N2N_LL_Transfer.indication

7.4.30.2.1[6.4.30.2.1] FunctionThis primitive is used by the local MIHF to notify the corresponding MIH user of the reception of an MIH_N2N_LL_Transfer request message.

7.4.30.2.2[6.4.30.2.2] Semantics of service primitiveMIH_N2N_LL_Transfer.indication (

SourceIdentifier,


LLInformation,

CandidateLinkList,

MNmsrk

)

Parameters:


17

1

234

56

7

89

10

1112

13

14

15

16

17

18

19

1



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.

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 PoS. This parameter can be used only if the PoA supports EAP or ERP for media-specific access authentication.

7.4.30.2.3[6.4.30.2.3] When generatedThis primitive is generated by the local MIHF after receiving an MIH_N2N_LL_Transfer request message.

7.4.30.2.4[6.4.30.2.4] Effect on receiptThe MIH user must generate an MIH_N2N_LL_Transfer.response primitive.

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.

7.4.30.3[6.4.30.3] MIH_N2N_LL_Transfer.response

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

7.4.30.3.2[6.4.30.3.2] Semantics of service primitiveMIH_N2N_LL_Transfer.response (



LLInformation,

MNnetworkaccessid,

Status

)


18

1

23

45

678

9

10

1112

1314

15

16

17

18

19

20

1


Parameters:




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

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

Status STATUS Status of the operation.

7.4.30.3.3[6.4.30.3.3] When generatedThis primitive is generated after receiving an MIH_N2N_LL_Transfer.indication primitive.

7.4.30.3.4[6.4.30.3.4] Effect on receiptThe local MIHF must generate an MIH_N2N_LL_Transfer response message in order to provide the required information until the authentication is finished.

7.4.30.4[6.4.30.4] MIH_N2N_LL_Transfer.confirm

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

7.4.30.4.2[6.4.30.4.2] Semantics of service primitiveMIH_N2N_LL_Transfer.confirm (

SourceIdentifier,


LLInformation,

MNnetworkaccessid,

Status

)

Parameters:


19

1

2

34

567

8

91011

1213

14

15

16

17

18

19

20

1




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_Transfer.request

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


7.4.30.4.3[6.4.30.4.3] When generatedThis primitive is generated by the remote MIHF after receiving an MIH_N2N_LL_Transfer response message.

7.4.30.4.4[6.4.30.4.4] Effect on receiptThe MIH user invokes an MIH_LL_Transfer.response primitive with the information obtained from this primitive.

7.4.31[6.4.31] MIH_IF_PreReg_Ready

7.4.31.1[6.4.31.1] MIH_IF_PreReg_Ready.request

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

7.4.31.1.2[6.4.31.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.


20

1

234

567

8

9

101112

1314

15

16

17

18

19

1


7.4.31.1.3[6.4.31.1.3] When generatedThis primitive is generated by the SRCF SR-MIHF user to prepare pre-registration of the target link.

7.4.31.1.4[6.4.31.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).

7.4.31.2[6.4.31.2] MIH_IF_PreReg_Ready.confirm

7.4.31.2.1[6.4.31.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.

7.4.31.2.2[6.4.31.2.2] Semantics of service primitiveMIH_IF_PreReg_Ready.confirm (

SourceIdentifier,

Status

)

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.


7.4.31.2.3[6.4.31.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.

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

7.4.32[6.4.32] 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.

7.4.32.1[6.4.32.1] MIH_TNMN_SA_Estab.request

7.4.32.1.1[6.4.32.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.

21

12

3456

7

89

10

1112

13

14

15

16

17

181920

21222324

2526272829

30

31323334


7.4.32.1.2[6.4.32.1.2] Semantics of Service PrimitiveMIH_TNMN_SA_Estab.request (

TargetLinkIdentifier (optional),

TargetLinkInfoList (optional),

TPoSIdentifier (optional),

LLInformation (optional),

)

Parameters:


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.

7.4.32.1.3[6.4.32.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.

7.4.32.1.4[6.4.32.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.

7.4.32.2[6.4.32.2] MIH_TNMN_SA_Estab.indication

7.4.32.2.1[6.4.32.2.1] FunctionThis 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.

7.4.32.2.2[6.4.32.2.2] Semantics of service primitiveMIH_TNMN_SA_Estab.indication (

MNID,

TargetLinkIdentifier (optional),


22

12

3

4

5

6

7

8

9

10111213141516

1718192021222324

25

262728

2930

31

32

1


TargetLinkInfoList (optional),

TPoSIdentifier (optional),

TargetLocationData (optional),

)

Parameters:

Name Data type Description 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.

7.4.32.2.3[6.4.32.2.3] When generatedThis primitive is generated by the local SPoS MIHF after receiving an MIH_TNMN_SA_Estab request message from the MN.

7.4.32.2.4[6.4.32.2.4] Effect on receiptThe 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.


7.4.32.3[6.4.32.3] MIH_TNMN_SA_Estab.response

7.4.32.3.1[6.4.32.3.1] FunctionThis primitive is used by MIH user application at the SPoS to Security Association establishment information to the SPoS MIHF for transmission to the MN.

7.4.32.3.2[6.4.32.3.2] Semantics of service primitiveMIH_ TNMN_SA_Estab.response (



LLInformation,

MNnetworkaccessid,

MIRK,

MNmsrk,

Nonce,

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

23

1

2

3

4

5

6

789

1011121314

15

16

171819

2021

22

23

24

25

26

27

28

29

1


SA_Status_Code

)

24

1

2


Parameters:




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


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 AssociationSA_Status_Code Octet Status of the security establishment with TPoS

0. Success1. TPoS is identical to SPoS, use Kspos2. Failure

7.4.32.3.3[6.4.32.3.3] When generated by the SPoSThis 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.

7.4.32.3.4[6.4.32.3.4] on receipt at the MNThe local MIHF must generate an MIH_TNMN_SA_Estab response message in order to provide the required information until the authentication is finished.

7.4.32.4[6.4.32.4] MIH_TNMN_SA_Estab.confirm

7.4.32.4.1[6.4.32.4.1] FunctionThis primitive is used to notify the corresponding MIH user about the reception of an MIH_TNMN_SA_Estab response message.

7.4.32.4.2[6.4.32.4.2] Semantics of service primitiveMIH_TNMN_SA_Estab.confirm (

SourceIdentifier,


LLInformation,

MNnetworkaccessid,

SA_Status_Code

)

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

25

1

2

345678

91011

12

131415

1617

18

19

20

21

22

23

24

1




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

SA_Status_Code Octet Status of the security establishment with TPoS0. Success1. TPoS is identical to SPoS, use Kspos2. Failure

7.4.32.4.3[6.4.32.4.3] When generatedThis primitive is generated by the remote MIHF after receiving an MIH_TNMN_SA_Estab response message.

7.4.32.4.4[6.4.32.4.4] Effect on receiptThe MIH user invokes an MIH_LL_Transfer.response primitive with the information obtained from this primitive.

7.4.33[6.4.33] MIH_N2N_MNTN_SA_EstabThe 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.

7.4.33.1[6.4.33.1] MIH_N2N_MNTN_SA_Estab.request

7.4.33.1.1[6.4.33.1.1] FunctionThis primitive is used to transport link layer frames between the serving PoS and the target PoS.

7.4.33.1.2[6.4.33.1.2] Semantics of Service PrimitiveMIH_N2N_MNTN_SA_Estab.request (

MNID,

Nonce,

Encrypted Key,

LLInformation

)

Parameters:


MNID MN_ID ID 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.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.


26

1

234

567

89

101112

13

1415

1617

18

19

20

21

22

23

24

1


7.4.33.1.3[6.4.33.1.3] When generatedThis 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.

7.4.33.1.4[6.4.33.1.4] Effect on receiptThe local MIHF shall generate an MIH_N2N_MNTN_SA_Estab request message to the remote TPoS MIHF.

7.4.33.2[6.4.33.2] MIH_N2N_MNTN_SA_Estab.indication

7.4.33.2.1[6.4.33.2.1] FunctionThis 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.

7.4.33.2.2[6.4.33.2.2] Semantics of service primitiveMIH_N2N_MNTN_SA_Estab.indication (

MNID,

Nonce,

Encrypted Key,

LLInformation

)

Parameters:


MNID MN_ID ID 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.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.

7.4.33.2.3[6.4.33.2.3] When generatedThis primitive is generated by the local TPoS MIHF after receiving an MIH_N2N_MNTN_SA_Estab request message from SPoS MIHF.

7.4.33.2.4[6.4.33.2.4] Effect on receiptThe 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.

27

1234

567

8

91011

1213

14

15

16

17

18

19

20

212223

2425262728

2930

3132

333435



7.4.33.3[6.4.33.3] MIH_N2N_MNTN_SA_Estab.response

7.4.33.3.1[6.4.33.3.1] FunctionThis primitive is used by a TPoS MIH application to respond to SPoS MIH application.

7.4.33.3.2[6.4.33.3.2] Semantics of service primitiveMIH_N2N_MNTN_SA.response (


LLInformation (optional),

MNnetworkaccessid,

SALifeTime (optional),

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.

7.4.33.3.3[6.4.33.3.3] When generatedThis primitive is generated after receiving an MIH_N2N_MNTN_SA_Estab.indication primitive.

7.4.33.3.4[6.4.33.3.4] Effect on receiptThe 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.

7.4.33.4[6.4.33.4] MIH_N2N_MNTN_SA_Estab.confirm

7.4.33.4.1[6.4.33.4.1] FunctionThis primitive is used to notify the corresponding MIH user about the reception of an MIH_N2N_MNTN_SA_Estab response message.

7.4.33.4.2[6.4.33.4.2] Semantics of service primitiveMIH_N2N_MNTN_SA_Estab.confirm (


LLInformation,

MNnetworkaccessid,

Status

)

28

1

2

34

56

7

8

9

10

11

12

13

14

1516

171819

20

212223

2425

26

27

28

29

30


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.

7.4.33.4.3[6.4.33.4.3] When generatedThis primitive is generated by the SPoS MIHF after receiving an MIH_N2N_MNTN_SA_Estab response message.

7.4.33.4.4[6.4.33.4.4] Effect on receiptThe 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.

7.5[6.5]

7.6[6.6]

8.[7.] Media independent handover protocols

8.1[7.1]

8.2[7.2]

8.3[7.3]

8.4[7.4] MIH protocol frame format

8.4.1[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

29

1

2

345

6789

10

11

12

13

14

15

16

17

1819

20

21


8.5[7.5]

8.6[7.6] MIH protocol messages

8.6.1[7.6.1]

8.6.2[7.6.2]

8.6.3[7.6.3] MIH messages for command service

8.6.3.1[7.6.3.1]

8.6.3.2[7.6.3.2]

8.6.3.3[7.6.3.3]

8.6.3.4[7.6.3.4]

8.6.3.5[7.6.3.5]

8.6.3.6[7.6.3.6]

8.6.3.7[7.6.3.7]

8.6.3.8[7.6.3.8]

8.6.3.9[7.6.3.9]

8.6.3.10[7.6.3.10]

8.6.3.11[7.6.3.11]

8.6.3.12[7.6.3.12]

8.6.3.13[7.6.3.13]

8.6.3.14[7.6.3.14]

8.6.3.15[7.6.3.15]

8.6.3.16[7.6.3.16]

8.6.3.17[7.6.3.17]

8.6.3.18[7.6.3.18]

8.6.3.19[7.6.3.19]

8.6.3.20[7.6.3.20]

8.6.3.21[7.6.3.21]

8.6.3.22[7.6.3.22]

30

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


8.6.3.23[7.6.3.23]

8.6.3.24[7.6.3.24] MIH_LL_Transfer requestThis message is used by an MIHF to carry link layer frames to conduct 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 PoS.

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)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.)

8.6.3.25[7.6.3.25] MIH_LL_Transfer responseThis message is used for an MIHF to 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.




(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)SALifeTime (optional)

(Lifetime TLV)Status

(Status TLV)

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

31

1

2345

6

7

89

10111213

14

15


[7.6.3.26] MIH_N2N_LL_TransferAuth 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)SALifeTime (optional) (Lifetime TLV)

[7.6.3.27] MIH_N2N_LL_TransferAuth responseThis message is used for an MIHF to carry link layer frames to conduct an authentication. The corresponding primitive is defined in Section 7.4.30.3

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)

Status(Status TLV)

8.6.3.26[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-registration.

32

1

23456789

10

11

12

13

141516

17

1819

20




(Destination MIHF ID TLV)ExecutionDelay

(Link Identifier TLV)

8.6.3.27[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)

8.6.3.28[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.


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


(Link Identifier TLV)TargetLinkInfoList (optional)

(TargetLinkInfolist TLV)TPoSIdentifier (optional)

(PoS MIHF ID TLV)LLInformation (optional)

(Link Layer Information TLV)

8.6.3.29[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.

33

1

23

4

5

6789

10

11

12131415


MIH Header Fields (SID=1, Opcode=3, AID=13)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

8.6.3.30[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=14)Source Identifier = sending SPoS ID

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


(Link Identifier TLV)TargetLinkInfoList (optional)

(TargetLinkInfolist TLV)LLInformation (optional)

(Link Layer Information TLV)Nonce (Nonce TLV)

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

8.6.3.31[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=14)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)

8.6.4[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

34

1

234

5

6789

10

11

121314


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.

* 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.

8.6.4.1[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

8.6.4.2[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

9.[8.] MIH protocol protection

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

9.1[8.1]

9.2[8.2] Key establishment through an MIH service access authentication

9.2.1[8.2.1]

9.2.2[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

35

12

34

56

78

910

111213

14

1516

17

18

19

20

21

22

232425


distribution process, a Target PoS can obtain a 64-octet MIRK (Media-Independent Root Key) from a Serving 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) 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 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 PoS independently of the MIH SA established between the MN and Serving 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.

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

9.2.2.2[8.2.2.2] EAP-based MIRKDuring an optimized pull key distribution process that involves the MN, the serving PoS and a target PoS, the serving 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.

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

36

12345

6789

1011

12

1314151617

1819202122

23

242526

27

2829

3031

3233

34

35

36

37

38

39


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 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 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.

10.[9.] Proactive Authentication

10.1[9.1] Media specific proactive authentication

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

ADD NEW FIGURE

37

1

2

3

4

5

6

7

8

9

10

1112131415

16

17

18

19

2021

22

23


Figure 47—Protocol Stack for MIH Supported optimized pull key distribution with two PoSes

ADD 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.

Insert new Clause 11

10.2

10.3 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 SPoS and TPoS.

38

12

34

5

6

789

101112

13

14

15

161718192021222324

25

26


Figure 10.2.1: MN handover signaling for preregistration using SPoS

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).

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_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

39

1

23

4

56789

10111213

141516171819

2021222324252627

2829


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.

10.3.1 Key distribution by SPoSThis section specifies one algorithm to allow SPoS 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.

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.

40

12

3456

789

10

1112131415

16

17

181920212223

242526

2728293031323334


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)]

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.

10.3.2 TPoS selection by SPoSIt 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.

11.[10.] Single Radio Handover

11.1[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

41

12

3

45

67

8

910

11121314151617

1819

20

2122232425262728293031

32

33

34353637383940


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.

11.1.1 Proxy Gateway

Source network

GW


Target network

GW Home network

GW



[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

42

1234567

8

910

11121314

1516171819

20212223

24252627

282930


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 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)

43

12

3456789

10

111213

14151617

18192021222324252627

2829303132333435

36


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.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

44

1

23

4

56789

1011121314151617

181920212223


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)

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.

45

12

345678

9

10

1112

131415

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


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)

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)

46

12

3

45

6789

1011121314

15

16

1718


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] Single radio handover overall processes <was 11.2 -- 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.

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.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

47

1

234

5

67

89

1011

1214

1516171819


radio measurements. Alternatively, the MN may request that the Source Network PoS identify one or more candidate target networks.

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. 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-registration process may occur before the network selection process as in the case of WiMAX target networks.

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 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.

48

12

3

4

5

6

78

910111213

141516171819

20212223

24

25262728293031

3233

3435363738394041


[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 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.

49

12345

6789

10111213

14151617

18192021222324

25262728

29303132333435

363738

3940

414243444546


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.

[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.

50

123

456

789

101112

1314151617

18

19

2021

22

232425

2627

2829

30

3132

33

3435

3637


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.)

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.

51

12

34

56

7

8

9

10

11

12

13

14

15

161718

1920

2122

2324

252627282930

31

32333435


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:

52

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

53

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.

54

12345

6789

10

1112131415161718192021222324

2526

2728

2930

3132

33343536

373839404142


Source network

GW


Target network

GW Home network

GW



[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.

55

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)

56

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.

57

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


MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

(b)

58

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

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

MN GW Target PoA




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

59

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.


(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


MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)




TCP or UDP / IP

TCP or UDP / IP

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

MN GW Target PoA


[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.

60

12

34567

8

9

1011

12

131415

16

17

18192021


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.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

61

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

62

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

63

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)]

64

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.

Insert new Clause 12

12.[11.] Gateway Service

12.1[11.1] 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

65

12

3456789

1011

12131415161718192021

2223242526

27282930

313233

34

35

36

37383940414243


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.

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.

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.

66

123456

78

910

1112

1314

15161718

192021222324

2526272829

3031

32333435

363738

394041

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

L3 + L4


MN Target PoA

L2(2) MICF

L2PHY

TargetMICF

L3 + L4 L3 + L4


12.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 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 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 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


MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

MIC

LSAP

MIC

SAP

(b)



67

1

234567

89

10111213

14

15

1617

181920

2122

23

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

L3 + L4


MN Target PoA

L2(2) MIHF

L2PHY

Proxy GW for Target PoA

L3 + L4 L3 + L4



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


(a)

68

Figure A-1XX: Proxy GW function for Target PoA

1

2

3

4

5

6

7

89

10111213

1415161718

19


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


MIC

LSAP

MIC

SAP

MIC

SAP

MIC

SAP

(b)




TCP or UDP / IP

TCP or UDP / IP

L2(1) L2 L2 L2

PHY(1) PHY PHY PHY

MN GW Target PoA


12.3[11.2] 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).

12.4[11.3] 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

69

1

23

4

567

8

9

10

1112

1314151617

18

192021


encapsulated messages to communicate with the target network entity. The PoA only encapsulates 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

70

123

45

6789

1011

12

13

1415

16


12.4.1[11.3.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).

71

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

[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.

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

72

12

3

45

6

7

8

9

10

11

1213

141516

1718

19

20

21

22

23


Annex B

Annex C

Annex D

Annex E

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 in this document.

MODIFY FOLLOWING DATA TYPE TO TABLE F.4

Data type nameDerived formDescriptionLINK_PARAM_GENUNSIGNED_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)

73

1

2

3

4

5

6

7

8

9

10

11

12

13

1415

16

17

18

19

20212223242526272829


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

ADD FOLLOWING DATA TYPE TO TABLE F.5

Action nameDescriptionLink_RX_ONTurn on only the receiver of the radio

74

1

2

3

45678

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26


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

Table F.13 – Data types for information elements

Data type nameDerived fromDefinition

75

1

2

3

4

5

6

7

8

9

10

11

121314


NET_CAPSBITMAP(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 11–31: (Reserved)IP_ADDRTRANSPORT_ADDR Indicates the IP address family, either 1 (for IPv4) or 2 (for IPv6).IP_TUNN_MGTBITMAP(16)Indicates the supported tunnel management protocol on PoS.Bitmap Values: Bit 0: IPSec Bit 1–15: (Reserved)FQDN

OCTET_STRINGThe 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 FOLLOWING DATA TYPE TO TABLE F.24

Data

76

123456789

10111213141516171819202122232425262728293031323334353637

38

39

40

41

42

43

44

45

46


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

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 0x10000207 IE_PoS_FQDN 0x10000208 IE_CONTAINER_PoS 0x10000303

Annex H

Annex I

Annex J

Annex K

Annex L

(normative)

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

MIH messagesAID

77

123456789

10

11

12

13

14

15

16

17

18

19

20

21

22

2324


MIH messages for Service ManagementMIH_LL_Transfer10MIH_N2N_LL_Transfer11MIH messages for Command ServiceMIH_IF_PreReg_Ready12MIH_TNMN_SA_Estab13MIH_MNTN_SA_Estab14MIH messages for Gateway Service

MIH_L2Message_Delivery1MIH_ANQP_Delivery2Reserved for other interworking protocolsFrom 3 to 500Reserved for vendor specific areaFrom 501 to 1023

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

TLV type NameTLV type valueData typeMedia Independent Root Key 78KEYMedia Specific Root Key 79KEYNetwork Access Identifier 80NAITPoS Identifier TLV 81TPoS_ID

Annex M

Annex N

(informative)

78

123456789

101112131415161718192021222324

25

26

27282930313233343536373839404142

43

44

45


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

N.65 Termination Phase

Insert N.6 after N.5

N.1

N.2

N.3

N.4

N.5

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

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.

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.

79

1

2

3

4

5

6

7

8

910

11121314

123


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

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

2. MIH_TNMN_SA_Estab Request: MN’s MIHF transmits request to Serving PoS (SPoS)

3. MIH_TNMN_SA_Estab.indication: SPoS presents MN’s Request to SPoS MIH user application.

4. MIH_N2N_MNTN_SA_Estab.request: issued by SPoS MIH user containing information to enable TPoS to compute MIRK (i.e., Ktpos)

5. MIH_N2N_MNTN_SA_Estab Request: relayed by SPoS to TPoS, possibly encapsulated with IPSec

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

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

80

1

23

4

56

7

8

910

1112

1314

15


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_Estab.response: TPoS MIH user initiates message for SPoS MIH user containing MNnetworkaccessid.

10. MIH_N2N_MNTN_SA_Estab Response: TPoS relays message to SPoS containing MNnetworkaccessid.

11. MIH_N2N_MNTN_SA_Estab.confirm: SPoS presents message to SPoS MIH user containing MNnetworkaccessid.

12. MIH_TNMN_SA_Estab.response: SPoS MIH user initiates message to MN user application via SPoS containing MNnetworkaccessid, MIRK.

13. MIH_TNMN_SA_Estab Response: SPoS relays message to MIHF at MN containing MNnetworkaccessid, MIRK.

14. MIH_TNMN_SA_Estab. confirm: MIHFat MN relays message to MN user application containing MNnetworkaccessid, MIRK.

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

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.

81

12

34

56

78

910

1112

1314

1516

17181920


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:

82

12

34


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

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

2. MIH_TNMN_SA_Estab Request: MN’s MIHF relays request to Serving PoS (SPoS)

3. MIH_TNMN_SA_Estab.indication: SPoS presents MN’s request to SPoS MIH user application.

4. SPoS MIH user provides MIRK to AAA for future authentication purposes at TPoA

5. SPoS 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_Estab.response: SPoS MIH user initiates message to MN user application via SPoS containing MNnetworkaccessid, MIRK. The response message informs MN that TPoS is the same as SPoS.

7. MIH_TNMN_SA_Estab Response: SPoS relays message to MIHF at MN containing MNnetworkaccessid, MIRK.

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

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

83

12

3

45

6

7

8

910

111213

1415

1617

1819

20


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:

Annex O

Add new Annex P

Annex P MN’s Network Access Identifier Format

(informative)

Insert

An MNnetworkaccessid attribute (of type NAI), which is optionally contained in MIH_LL_Transfer.response, MIH_LL_Transfer.confirm, MIH_N2N_LL_Transfer.response, and MIH_N2N_LL_Transfer.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 NAI carried in this attribute

84

12

3

4

5

6

7

8

9

10

1112131415


may contain the identifier of the MSRK used between the MN and the target PoS, and the realm part of the NAI may contain a Fully Qualified Domain Name of the target PoS.

Add 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 Listening 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.3.

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), SRCF 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

85

12

3

4

5

6

789

10

11

12131415

16

1718

1920212223


Q.2 Using 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 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 SRCF sends the location information (QUERIER_LOC) of the MN through MIH_Get_Information request message. In (2), the IR SRCF responds with network access information elements, such as IE_NETWORK_TYPE and IE_NET_FREQUENCY_BANDS.

Q.3 Using 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 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.

86

1

23456789

10

11

1213

14151617

18

19

2021222324252627282930

313233


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 SRCF sends the scheduled location information (QUERIER_LOC) of the MN through MIH_Get_Information request message. In (2), the IR SRCF responds with network access information elements, such as IE_NETWORK_TYPE and IE_NET_FREQUENCY_BANDS.

Add new Annex R

[Annex R] Examples of SRHO

(Informative)

Insert

Q.4[R.1] 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.

87

1234

5

67

89

1011

12

13

14

15

16

1718


WiMAXCSN

WiMAX ASN

MN before handover

MN during handover


Source PoA


ASN-GW

WIFSFF

BS

Rx

AP

GW

InformationRepository

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.

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].

88

12

3

4

5

678

910

11121314

15

16

1718

1920

21

2223

2425


Q.4.1[R.1.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)

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)

89

1

23456789

10

11

12

13

14

15

16

17

1819

20


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.

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.

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.

90

1234

56789

10

111213

14151617

181920

2122

23242526272829

30313233


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)

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)

91

12345678

9101112131415161718

19

20

21

22

23

24

25

26

27

2829


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


MN SFF/ ASN-GW WiMAXBS

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.

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 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.

92

1234

56789

10111213141516171819

20

212223

24252627


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.

Q.4.2[R.1.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 MN and the target network performs proactive authentication via the source network. The exchange of handshake messages for authentication is communicated as follows:

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 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:

93

12

3

4

5

6789

101112

131415

1617

1819202122

2324

2526272829

303132333435

3637

3839

40


(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:

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.3.

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: 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.5[R.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 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.


94

12

3

45

6

78

91011

121314

15161718

19

2021

22

2324

25

26


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].

Q.5.1[R.2.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 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

95

123

456

789

10

11

12

13

1415

1617

18

19

202122232425262728

29

3031


(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.

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.

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.

96

1

2345

6789

1011

121314

15161718

192021

2223

24252627282930

3132


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.

(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)

97

12

3456789

10

1112131415161718192021

22

23

24

25

26

27

2829


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


MN SFF/ ASN-GW WiMAXBS

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.

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

PHY(1) PHY PHY PHYMN SFF / ASN-GW WiMAX BS

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.

98

1234

56789

10111213141516171819

202122

23242526

2728


Both R9+ and R6+ are both outside the scope of this standard.

Q.5.2[R.2.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 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.




99

1

2

3456789

101112

131415

1617

18192021222324

2526272829

303132333435

3637

3839

40

4142


(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.

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: 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.6[R.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.

WLAN ANWiMAX ASN

MN before handover

MN during handover


Source PoA


ASN-GW

RyBS

WiMAXCSN

InformationRepository

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.

100

1

23

4

56

789

101112

13141516

17

1819

20

2122

23

242526


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].

R6 interface between the WiMAX Proxy GW and ASN GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

Q.6.1[R.3.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)

101

123

456789

10

11

1213

1415

1617

18

1920

2122

23

2425262728293031

32


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.

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

102

12

3456

789

101112

131415

16171819

202122

2324

252627


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.

(a)

103

1234

567

89

101112131415

16171819202122232425

26

27

28

29

30

31

32


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 WLAN AP. The co-located Proxy GW/WIF/AR proxies between the MN and the target WLAN AP using

104

12

3

4567

89

1011

1213141516171819


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.

Q.6.2[R.3.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.



105

12

3

456

789

1011

12

13

14151617

18192021

22

2324

25

2627

282930



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.

Q.7[R.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.

106

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].

107

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].

Q.7.1[R.4.1] Transport of 3GPP L2 control frames between MN and the 3GPP network

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

108

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.

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.

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.

109

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)

110

123

456789

1011

12131415161718192021

22

2324

25

26

27

28

29


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 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.

111

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.

Q.7.2[R.4.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.

112

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.

Q.8[R.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.

113

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].

114

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].

Q.8.1[R.5.1] Transport of 3GPP L2 control frames between MN and the 3GPP network

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

115

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.

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.

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

116

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

MI CF MICF S1-MME+ S1-MME+

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.

117

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.

Q.8.2[R.5.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

118

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.

119

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.

Add new Annex S

Annex R[Annex S] 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.

R.1[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

120

123

4567

8

9

10

11

121314

15

16

1718

19

202122


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.

R.2[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.

121

1234

5

6

78

9101112


R.3[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 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.

122

1

2

34

56789

10

11