IEEE P802.21c™/D01
Draft Standard for Local and metropolitan area networks- Part 21: Media Independent Handover Services
Amendment 3: Optimized Single Radio Handovers

Sponsor

LAN/MAN Standards Committee
of the
IEEE Computer Society

Approved <XX MONTH 20XX>

IEEE-SA Standards Board

Copyright © 2012 by The Institute of Electrical and Electronics Engineers, Inc.

Three Park Avenue

New 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 (stds.ipr@ieee.org). 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 Department

445 Hoes Lane

Piscataway, NJ 08854, USA

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.

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 Board

445 Hoes Lane

Piscataway, NJ 08854

USA

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.

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.

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

At the time this draft<opt_trial-use><gde./rec. prac./std.> was submitted to the IEEE-SA Standards Board for approval, the <Working Group Name> Working Group had the following membership:

<Chair Name>, Chair

<Vice-chair Name>, Vice Chair

Participant1

Participant2

Participant3

Participant4

Participant5

Participant6

Participant7

Participant8

Participant9

The following members of the <individual/entity> balloting committee voted on this<opt_trial-use><gde./rec. prac./std.>. Balloters may have voted for approval, disapproval, or abstention.

(to be supplied by IEEE)

Balloter1

Balloter2

Balloter3

Balloter4

Balloter5

Balloter6

Balloter7

Balloter8

Balloter9

When the IEEE-SA Standards Board approved this<opt_trial-use><gde./rec. prac./std.> on <XX MONTH 20XX>, it had the following membership:

(to be supplied by IEEE)

<Name>, Chair

<Name>, Vice Chair

<Name>, Past Chair

<Name>, Secretary

SBMember1

SBMember2

SBMember3

SBMember4

SBMember5

SBMember6

SBMember7

SBMember8

SBMember9

*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 P<designation>/D<draft_number>, Draft<opt_Trial-Use><Gde./Rec. Prac./Std.> for <Complete Title Matching PAR>.

This document specifies optimizations to reduce the latency during single radio handovers between heterogeneous access networks.

Contents

1. Overview	1

2. Normative references	1

3. Definitions	2

4. Abbreviations and acronyms	2

5. General architecture	3

6. MIH Services	3

6.1	3

6.2	3

6.3	3

6.4	3

6.5 Media independent information service	3

6.5.1 Information Element	3

6.5.2 IE Containers	3

7. Service Access Point (SAP) and primitives	4

7.1	4

7.2	4

7.3 MIH_LINK_SAP primitives	4

7.3.1	4

7.3.2	4

7.3.3	4

7.3.4	4

7.3.5	4

7.3.6	4

7.3.7	4

7.3.8	4

7.3.9	4

7.3.10	4

7.3.11	4

7.3.12	4

7.3.13	4

7.3.14	4

7.3.15 Link_IF_PreReg_Ready	4

7.4 MIH_SAP primitives	5

7.4.1	5

7.4.2	5

7.4.3	5

7.4.4	5

7.4.5	5

7.4.6	5

7.4.7	5

7.4.8	5

7.4.9	5

7.4.10	5

7.4.11	5

7.4.12	5

7.4.13	5

7.4.14	5

7.4.15	5

7.4.16	5

7.4.17	5

7.4.18	5

7.4.19	5

7.4.20	5

7.4.21	5

7.4.22	5

7.4.23	5

7.4.24	5

7.4.25	5

7.4.26	5

7.4.27	5

7.4.28	5

7.4.29 MIH_LL_Transfer	5

7.4.30 MIH_N2N_LL_Transfer	9

7.4.31 _IF_PreReg_Ready	13

7.4.32 MIH_TNMN_SA_Estab	15

7.4.33 MIH_N2N_MNTN_SA_Estab	19

7.5	23

7.6	23

8. Media independent handover protocols	23

8.1	23

8.2	23

8.3	23

8.4 MIH protocol frame format	23

8.4.1 General frame format	23

8.5	23

8.6 MIH protocol messages	23

8.6.1	23

8.6.2	23

8.6.3 MIH messages for command service	23

8.6.4 MIH messages for gateway service	27

9. MIH protocol protection	28

9.1	28

9.2 Key establishment through an MIH service access authentication	28

9.2.1	28

9.2.2 Key derivation and key hierarchy	28

10. Proactive Authentication	29

10.1 Media specific proactive authentication	29

11. Single Radio Handover	31

11.1 Introduction	31

11.1.1 Need for single radio handover	31

11.1.2 Relationship to other network standards	31

11.1.3 Single radio versus dual radio handover	31

11.1.4 Media independent single radio handover	32

11.2 Requirements of Single Radio Handover	32

11.3 Assumptions of Single Radio Handover	33

11.4 SRHO Reference Model	34

11.4.1 Link configurations	34

11.4.2 Information Repository	35

11.4.3 Proxy Gateway	36

11.4.4 Media Independent Control Function	38

11.4.5 Single Radio handover Control Function	38

11.4.6 Transport of L2 network entry PDU of the target radio	39

11.4.7 Communication between the MN and the target network	40

11.4.8 Communication between the MN and the target PoA	40

11.5 Single radio handover overall processes	43

11.6 Securing Single-Radio messages using PoS	44

11.6.1 Overview	44

11.6.2 Protecting communications between serving PoS and target PoS	48

12. Gateway Service	48

12.1 Introduction	48

12.2 L2 Message Transfer (SID=5, AID=1)	48

12.3 Interworking Protocol Delivery (SID=5, AID>1)	49

12.3.1 Examples of Interworking Protocol Delivery: ANQP Delivery	50

Annex A	52

Bibliography	52

Annex B	52

Annex C	52

Annex D	52

Annex E	52

Annex F	52

F.1	52

F.2	52

F.3 Derived data types	52

F.3.1	52

F.3.2	52

F.3.3	52

F.3.4 Data types for link identification and manipulation	52

F.3.5	53

F.3.6	53

F.3.7	53

F.3.8 Data types for information elements	53

F.3.9	53

F.3.10	53

F.3.11	53

F.3.12	53

F.3.13	54

F.3.14	54

F.3.15	54

F.3.16 Data type for security	54

Annex G	54

Annex H	55

Annex I	55

Annex J	55

Annex K	55

Annex L	55

Annex M	56

Annex N	56

N.1	56

N.2	56

N.3	56

N.4	56

N.5	56

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

Annex O	61

Annex P MN’s Network Access Identifier Format	61

Annex Q Network discovery for single radio handover	62

Annex R Examples of SRHO	64

R.1 WLAN to WiMAX single radio handover	64

R.1.1 Transport of WiMAX L2 control frames between MN and the WiMAX ASN	65

R.1.2 WLAN to WiMAX Single Radio Handover processes	69

R.2 3GPP to WiMAX single radio handover	70

R.2.1 Transport of WiMAX L2 control frames between MN and the WiMAX ASN	71

R.2.2 3GPP to WiMAX Single Radio Handover processes	75

R.3 WiMAX to WLAN single radio handover	76

R.3.1 Transport of WLAN L2 control frames between MN and the WLAN AN	77

R.3.2 WiMAX to WLAN Single Radio Handover processes	81

R.4 WiMAX to 3GPP single radio handover	82

R.4.1 Transport of 3GPP L2 control frames between MN and the 3GPP network	83

R.4.2 WiMAX to 3GPP Single Radio Handover processes	87

R.5 WLAN to 3GPP single radio handover	88

R.5.1 Transport of 3GPP L2 control frames between MN and the 3GPP network	90

R.5.2 Non-trusted WLAN AN to 3GPP Single Radio Handover processes	93

Annex S Handover Decision	95

S.1 Weak SINR of the source link	95

S.2 QoS and/or cost check	96

S.3 Power consumption comparison of the link interfaces	96

Draft Standard for Local and metropolitan area networks- Part 21: Media Independent Handover Services Amendment 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.

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.

Overview

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.

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.

Definitions

Serving PoS: the Point of Service in the domain 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 Control Function (SRCF): 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 control frame: A packet which contains the target radio’s network entry link-layer PDUs in its payload.

Target PoS: a 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

Abbreviations and acronyms

ANDSF	Access Network Discovery Selection Functions

MICF	Media Independent Control Function

MICSAP	Media Independent Control Service Access Point

MICLSAP	Media independent Control Link-layer Service Access Point

PoS	Point of Service

SRCF	Single Radio handover Control Function

SRHO	Single Radio Handover

SPoS	Serving PoS

TPoS	Target PoS

General architecture

MIH Services

Media independent information service

Information Element

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

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

Insert information elements in Table 10 as follows:

— Information Element

Name of information element	Description	Data type
802.21 Point of Service information elements
IE_PoS_IP_ADDR	IP address of PoS	IP_ADDR
IE_PoS_TUNN_MGMT_PRTO	Type of tunnel management protocol supported.	IP_TUNN_MGMT
IE_PoS_FQDN	FQDN of PoS.	FQDN

IE Containers

In 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

—IE_CONTAINER_PoS definition

Information element ID = (see Table B.1)	Length = variable
IE_PoS_IP_ADDR
IE_PoS_TUNN_MGMT_PRTO
IE_PoS_FQDN

Service Access Point (SAP) and primitives

MIH_LINK_SAP primitives

Link_IF_PreReg_Ready

Link_IF_PreReg_Ready.request

Function

This primitive is used by the SRCF to request pre-registration on a target link interface.

Semantics of service primitive

Link_IF_PreReg_Ready.request (

ExecutionDelay

)

Parameters:

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

When generated

This primitive is generated by the SRCF to prepare pre-registration of the target link.

Effect on receipt

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

Link_IF_PreReg_Ready.confirm

Function

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

Semantics of service primitive

Link_IF_PreReg_Ready.confirm (

Status

)

Parameters:

Name	Data type	Description
Status	STATUS	Status of the operation.

When generated

This primitive is generated in response to Link_IF_PreReg_Ready.request operation.

Effect on receipt

Upon receipt of this primitive, the SRCF can know success of pre-registration preparation on the target link.

MIH_SAP primitives

MIH_LL_Transfer

MIH_LL_Transfer.request

Function

This primitive carries link-layer frames between the MN and a MIHF at the MN’s local PoS.

Semantics of service primitive

MIH_LL_Transfer.request (

DestinationIdentifier,

TargetLinkIdentifier,

LLInformation,

TPoSIdentifier,

CandidateLinkList,

Nonce

)

Parameters:

Name	Data type	Description
DestinationIdentifier	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.
LLInformation	LL_FRAMES	(Optional: included if the target link is known) Carries link layer frames.
TPoSIdentifier	TPoS_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)

When generated

This primitive is generated by an MIH user to start an authentication and association process based on link-layer frames.

Effect on receipt

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

MIH_LL_Transfer.indication

Function

This primitive is used by the remote MIHF to notify the corresponding MIH user about the reception of an MIH_LL_Transfer request message.

Semantics of service primitive

MIH_LL_Transfer.indication (

SourceIdentifier,

TargetLinkIdentifier,

LLInformation,

TPoSIdentifier,

CandidateLinkList

)

Parameters:

Name	Data type	Description
SourceIdentifier	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 exchange. 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	TPoS_ID	(Optional) This identifies 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.

When generated

This primitive is generated by a remote MIHF after receiving an MIH_LL_Transfer request message.

Effect on receipt

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

MIH_LL_Transfer.response

Function

This primitive is used by an MIH user to provide the link-layer frames to the local MIHF.

Semantics of service primitive

MIH_LL_Transfer.response (

DestinationIdentifier,

TargetLinkIdentifier,

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_ID	This identifies the remote PoA that is the corresponding peer of the L2 exchange.
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	TPoS_ID	(Optional) This identifies the target PoS
Status	STATUS	Status of the operation.

When generated

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

Effect on receipt

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

MIH_LL_Transfer.confirm

Function

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

Semantics of service primitive

MIH_LL_Transfer.confirm (

SourceIdentifier,

TargetLinkIdentifier,

LLInformation,

MNnetworkaccessid,

TPoSIdentifier,

Status)

Parameters:

Name	Data type	Description
SourceIdentifier	MIHF_ID	This identifies the invoker, which is a remote MIHF.
TargetLinkIdentifier	LINK_TUPLE_ID	This identifies the remote PoA that is the corresponding peer of the L2 exchange.
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	TPoS_ID	(Optional) This identifies the target PoS
Status	STATUS	Status of the operation.

When generated

This primitive is generated by the local MIHF after receiving an MIH_LL_Transfer response message.

Effect on receipt

The MIH user on the MN may generate an MIH_LL_Transfer.request primitive unless the authentication or association processes are completed.

MIH_N2N_LL_Transfer

The primitives defined are to transport media link-layer frames over MIH between the serving PoS and the target PoS. The media specific authentication is conducted with the media specific authenticator deployed in the target PoA.

MIH_N2N_LL_Transfer.request

Function

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

Semantics of Service Primitive

MIH_N2N_LL_Transfer.request (

DestinationIdentifier,

TargetLinkIdentifier,

LLInformation,

MNID,

CandidateLinkList

)

Parameters:

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

When generated

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

Effect on receipt

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

MIH_N2N_LL_Transfer.indication

Function

This primitive is used by the local MIHF to notify the corresponding MIH user of the reception of an MIH_N2N_LL_Transfer request message.

Semantics of service primitive

MIH_N2N_LL_Transfer.indication (

SourceIdentifier,

TargetLinkIdentifier,

LLInformation,

CandidateLinkList,

MNmsrk

)

Parameters:

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

When generated

This primitive is generated by the local MIHF after receiving an MIH_N2N_LL_Transfer request message.

Effect on receipt

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

MIH_N2N_LL_Transfer.response

Function

This primitive is used by an MIH user to provide the link-layer frames to the local MIHF.

Semantics of service primitive

MIH_N2N_LL_Transfer.response (

DestinationIdentifier,

TargetLinkIdentifier,

LLInformation,

MNnetworkaccessid,

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_ID	This identifies the remote PoA that is the corresponding peer of the L2 exchange.
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.

When generated

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

Effect on receipt

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

MIH_N2N_LL_Transfer.confirm

Function

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

Semantics of service primitive

MIH_N2N_LL_Transfer.confirm (

SourceIdentifier,

TargetLinkIdentifier,

LLInformation,

MNnetworkaccessid,

Status

)

Parameters:

Name	Data type	Description
SourceIdentifier	MIHF_ID	This identifies the invoker, which is a remote MIHF.
TargetLinkIdentifier	LINK_TUPLE_ID	This identifies the remote PoA that is the corresponding peer of the L2 exchange.
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
Status	STATUS	Status of the operation.

When generated

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

Effect on receipt

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

_IF_PreReg_Ready

MIH_IF_PreReg_Ready.request

Function

This primitive is used by the SRCF user to request pre-registration on a target link interface.

Semantics of service primitive

MIH_IF_PreReg_Ready.request (

DestinationIdentifier,

ExecutionDelay

)

Parameters:

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

When generated

This primitive is generated by the SRCF user to prepare pre-registration of the target link.

Effect on receipt

Upon receipt of this primitive, the local SRCF generates and sends an MIH_IF_PreReg_Ready request message to the remote SRCF identified by the Destination Identifer. The remote SRCF issues Link_IF_PreReg_Ready.request(s) to the specified lower layer link(s).

MIH_IF_PreReg_Ready.confirm

Function

This primitive is used by the SRCF to confirm that MIH_IF_PreReg_Ready response message was received from a peer SRCF.

Semantics of service primitive

MIH_IF_PreReg_Ready.confirm (

SourceIdentifier,

Status

)

Parameters:

Name	Data type	Description
SourceIdentifier	MIHF_ID	This identifies the invoker of this primitive, which can be either the local MIHF or a remote MIHF.
Status	STATUS	Status of the operation.

When generated

This primitive is generated by the SRCF on receiving an MIH_IF_PreReg_Ready response message form a peer SRCF.

Effect on receipt

Upon receipt of this primitive, the SRCF 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.

MIH_TNMN_SA_Estab

The primitives are defined to transport between the mobile node MN and the source PoS via MIH. The source 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.

MIH_TNMN_SA_Estab.request

Function

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

Semantics of Service Primitive

MIH_TNMN_SA_Estab.request (

TargetLinkIdentifier (optional),

TargetLinkInfoList (optional),

TPoSIdentifier (optional),

LLInformation (optional),

)

Parameters:

Name	Data type	Description
TargetLinkIdentifier	LINK_TUPLE_ID	(Optional) This identifies the remote PoA that is the corresponding peer of the L2 exchange.
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	TPOS_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.

When generated

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

Effect on receipt

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

MIH_TNMN_SA_Estab.indication

Function

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

Semantics of service primitive

MIH_TNMN_SA_Estab.indication (

MNID,

TargetLinkIdentifier (optional),

TargetLinkInfoList (optional),

TPoSIdentifier (optional),

TargetLocationData (optional),

)

Parameters:

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

When generated

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

Effect on receipt

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

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

MIH_TNMN_SA_Estab.response

Function

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

Semantics of service primitive

MIH_ TNMN_SA_Estab.response (

DestinationIdentifier,

TargetLinkIdentifier,

LLInformation,

MNnetworkaccessid,

MIRK,

MNmsrk,

Nonce,

SALifeTime,

SA_Status_Code

)

Parameters:

Name	Data type	Description
DestinationIdentifier	MIHF_ID	This identifies a remote MIHF that will be the destination of this response.
TargetLinkIdentifier	LINK_TUPLE_ID	This identifies the remote PoA that is the corresponding peer of the L2 exchange.
LLInformation	LL_FRAMES	(Optional) Carries link layer frames; included if and only if the corresponding MIH_TNMN_SA_Estab.indication contained LLInformation.
MNnetworkaccessid	NAI	(Optional) Carries the MN’s Network Access Identifier when optimized pull key distribution is used.
MIRK	ENCR_BLOCK	(optional) A shared key, Ktpos, encrypted to be recoverable by MN
MNmsrk	ENCR_BLOCK	(optional) Media Specific root key (for use with EAP methods)
Nonce	NONCE_VALUE	(optional) Nonce
SALifeTime	LifeTime	(optional) Lifetime of the Security Association
SA_Status_Code	Octet	Status of the security establishment with TPoS Success TPoS is identical to SPoS, use Kspos Failure

When generated by the SPoS

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

on receipt at the MN

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

MIH_TNMN_SA_Estab.confirm

Function

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

Semantics of service primitive

MIH_TNMN_SA_Estab.confirm (

SourceIdentifier,

TargetLinkIdentifier,

LLInformation,

MNnetworkaccessid,

SA_Status_Code

)

Parameters:

Name	Data type	Description
SourceIdentifier	MIHF_ID	This identifies the invoker, which is a remote MIHF.
TargetLinkIdentifier	LINK_TUPLE_ID	This identifies the remote PoA that is the corresponding peer of the L2 exchange.
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 TPoS Success TPoS is identical to SPoS, use Kspos Failure

When generated

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

Effect on receipt

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

MIH_N2N_MNTN_SA_Estab

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

MIH_N2N_MNTN_SA_Estab.request

Function

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

Semantics of Service Primitive

MIH_N2N_MNTN_SA_Estab.request (

MNID,

Nonce,

Encrypted Key,

LLInformation

)

Parameters:

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

When generated

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

Effect on receipt

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

MIH_N2N_MNTN_SA_Estab.indication

Function

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

Semantics of service primitive

MIH_N2N_MNTN_SA_Estab.indication (

MNID,

Nonce,

Encrypted Key,

LLInformation

)

Parameters:

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

When generated

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

Effect on receipt

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

The MIH user must, if necessary, derive a MNnetworkAccessID from 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.

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

MIH_N2N_MNTN_SA_Estab.response

Function

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

Semantics of service primitive

MIH_N2N_MNTN_SA.response (

DestinationIdentifier,

LLInformation (optional),

MNnetworkaccessid,

SALifeTime (optional),

Status

)

Parameters:

Name	Data type	Description
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.
MNnetworkaccessid	NAI	(Optional) Carries the MN’s Network Access Identifier when optimized pull key distribution is used.
Status	BOOLEAN	Status of the operation.

When generated

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

Effect on receipt

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

MIH_N2N_MNTN_SA_Estab.confirm

Function

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

Semantics of service primitive

MIH_N2N_MNTN_SA_Estab.confirm (

DestinationIdentifier,

LLInformation,

MNnetworkaccessid,

Status

)

Parameters:

Name	Data type	Description
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.
MNnetworkaccessid	NAI	(Optional) Carries the MN’s Network Access Identifier when optimized pull key distribution is used.
Status	BOOLEAN	Status of the operation.

When generated

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

Effect on receipt

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

Media independent handover protocols

MIH protocol frame format

General frame format

Note to editor: Insert new description for the new SID value, 5, into Table L.1.

Field name	Size (bits)	Description
MIH message ID (MID) -- Service identifier (SID)	4	5: Gateway Service

MIH protocol messages

MIH messages for command service

MIH_LL_Transfer request

This 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=9)
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.)

MIH_LL_Transfer response

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

MIH Header Fields (SID=1, Opcode=2, AID=9)
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)
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.)

MIH_N2N_LL_Auth request

This 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=9)
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)

MIH_N2N_LL_Auth response

This 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=9)
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)

MIH_IF_PreReg_Ready request

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

MIH Header Fields (SID=3, Opcode=1, AID=12)
Source Identifier = sending MIHF ID (Source MIHF ID TLV)
Destination Identifier = receiving MIHF ID (Destination MIHF ID TLV)
ExecutionDelay (Link Identifier TLV)

MIH_IF_PreReg_Ready response

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

MIH Header Fields (SID=3, Opcode=2, AID=12)
Source Identifier = sending MIHF ID (Source MIHF ID TLV)
Destination Identifier = receiving MIHF ID (Destination MIHF ID TLV)
Status (Link Identifier TLV)

MIH_TNMN_SA_Estab request

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

MIH Header Fields (SID=1, Opcode=1, AID=13)
Source Identifier = sending MIHF ID (Source MIHF ID TLV)
Destination Identifier = SPoS MIHF ID (Destination MIHF ID TLV)
TargetLinkIdentifier (optional) (Link Identifier TLV)
TargetLinkInfoList (optional) (TargetLinkInfolist TLV)
TPoSIdentifier (optional) (PoS MIHF ID TLV)
LLInformation (optional) (Link Layer Information TLV)

MIH_TNMN_SA_Estab response

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

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

MIH_N2N_MNTN_SA_Estab Request

This 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 (Destination MIHF ID TLV)
TargetLinkIdentifier (optional) (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)

MIH_N2N_MNTN_SA_Estab response

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

MIH messages for gateway service

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

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

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

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

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

Request message for gateway service

Gateway 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 (Source MIHF ID TLV)
Destination Identifier = receiving MIHF ID (Destination MIHF ID TLV)
L2 message or other interworking message depending on the AID value

Response message for gateway service

This message returns the result of Request message for gateway service.

MIH Header Fields (SID=5, Opcode=2, AID)
Source Identifier = sending MIHF ID (Source MIHF ID TLV)
Destination Identifier = receiving MIHF ID (Destination MIHF ID TLV)
L2 message or other interworking message depending on the AID value

MIH protocol protection

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

Key establishment through an MIH service access authentication

Key derivation and key hierarchy

Upon a successful MIH service access authentication, the authenticator (i.e., PoS) obtains a master session key (MSK) or a re-authentication master session key (rMSK). Alternatively, via an optimized pull key distribution process, a Target PoS can obtain a 64-octet MIRK (Media-Independent Root Key) from a Serving 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.

Derivation of media independent session keys (MISKs)

EAP-based MIRK

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

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.

Proactive Authentication

Media specific proactive authentication

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

ADD NEW FIGURE

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

Single Radio Handover

Introduction

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

Relationship to other network standards <deleted – with citations, could go into an appendix>

Single radio versus dual radio handover <content folded into Introduction>

Media independent single radio handover <move to new section 5.1.9 in 802.21-2008-Updated spec>

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

Requirements of Single Radio Handover <reduce, move to section 5.2 in 802.21-2008-Updated>

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

General Requirements: <redundant, delete>

Functional Requirements for SR-MIHF:

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

tunneling mechanism to deliver the pre-registration messages <theoretically does not have to be tunneling>

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

detect the presence of single radio enabling entity at the network before attaching to the target access network.

Selection of an appropriate target network and to obtain the corresponding required information from the access network.

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

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

Whether the target network allows pre-registration

Whether it supports single radio handover < … what does this mean? Delete? …>

Any required layer-2 parameters

Assumptions of Single Radio Handover <shorten and move to section 5.2>

The following assumptions apply during the single radio handover:

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.

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.

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.

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.

SRHO Reference Model <exhibit as an evolution of figures 2, 3, and 4 in section 4>

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.

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

Link configurations

Link configuration before handover:

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.

Between the MN and target network: Not specified.

Link configuration after handover:

Between the MN and source network: Not specified.

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:

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.

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:

the source radio is not transmitting

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:

the source radio is not transmitting, or

there is sufficient filtering from the source radio transmitter, or

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.

Information Repository <exhibit as update to figure 3, a lot can be deleted>

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

Proxy Gateway <do not touch this until more discussion>

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

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

Media Independent Control Function <exhibit as evolution of figure 4, section 5.5.2>

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

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

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

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

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

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.

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)

(b)

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.

Communication between the MN and the target network <…? Depends on proxy discussion>

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

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

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

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

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

(a)

(b)

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

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

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

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

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

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

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

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

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

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

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

(a)

(b)

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.

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

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.

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

Securing Single-Radio messages using PoS <??? Exhibit as amendment to 802.11a ???> <Move to new reference model in section 5?>

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.

Overview

Security 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

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 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 ⊕ PNGstpos (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 ⊕ PNGspos (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.

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.

Protecting communications between serving PoS and target PoS

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

Gateway Service

Introduction

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

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.5 (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.6 (b).

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

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

Figure 12.1: Gateway Service for Interworking Protocol Message Transfer

As extension of L2 message conversion, the interworking protocol message conversion as shown in Figure 12.2, 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.

Figure 12.2: Gateway Service for Interworking Protocol Message Conversion

Examples of Interworking Protocol Delivery: ANQP Delivery

If 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.3 (a). The WLAN AP only encapsulates or decapsulates messages from the MN or the information server as shown in Figure 12.3 (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.”

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

(b) Protocol Stacks for ANQP Transfer

Figure 12.3: 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.4 (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.4 (b).

(a) ANQP Conversion using the Proxy GW

(b) Protocol Stacks for ANQP Conversion

Figure 12.4: ANQP Conversion from Media Independent Information Server

Bibliography

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

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

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

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

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

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

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

(normative)

Derived data types

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 name	Derived form	Description
LINK_PARAM_GEN	UNSIGNED_INT(1)	5: Average power consumption in active state- the parameter value is represented as an UNSIGNED_INT(2). its measure is mW. Value Range: 0 – 216-1 mW 6-255: (Reserved)

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

ADD FOLLOWING DATA TYPE TO TABLE F.5

Action name	Description
Link_RX_ON	Turn on only the receiver of the radio

Data types for information elements

Table F.13 – Data types for information elements

Data type name	Derived from	Definition
NET_CAPS	BITMAP(32)	These bits provide high level capabilities supported on a network. Bitmap Values: Bit 0: Security – Indicates that some level of security is supported when set. Bit 1: QoS Class 0 – Indicates that QoS for class 0 is supported when set Bit 2: QoS Class 1 – Indicates that QoS for class 1 is supported when set Bit 3: QoS Class 2 – Indicates that QoS for class 2 is supported when set; Otherwise, no QoS for class 2 support is available. Bit 4: QoS Class 3 – Indicates that QoS for class 3 is supported when set; Otherwise, no QoS for class 3 support is available. Bit 5: QoS Class 4 – Indicates that QoS for class 4 is supported when set; Otherwise, no QoS for class 4 support is available. Bit 6: QoS Class 5 – Indicates that QoS for class 5 is supported when set; Otherwise, no QoS for class 5 support is available. Bit 7: Internet Access – Indicates that Internet access is supported when set; Otherwise, no Internet access support is available. Bit 8: Emergency Services – Indicates that some level of emergency services is supported when set; Otherwise, no emergency service support is available. Bit 9: MIH Capability – Indicates that MIH is supported when set; Otherwise, no MIH support is available. Bit 10: SRHO Capability – Indicates that SRHO is supported when set; Otherwise, no SRHO support is available. Bit 11–31: (Reserved)
IP_ADDR	TRANSPORT_ADDR	Indicates the IP address family, either 1 (for IPv4) or 2 (for IPv6).
IP_TUNN_MGT	BITMAP(16)	Indicates the supported tunnel management protocol on PoS. Bitmap Values: Bit 0: IPSec Bit 1–15: (Reserved)
FQDN	OCTET_STRING	The fully qualified domain name of a host as described in IETF RFC 2181.

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	Derived from	Definition
NAI	OCTET_STRING	Represents a Network Access Identifier as in IETF RFC 4282
TPoS_ID	CHOICE(IP_ADDR, MIHF_ID)	Represents the identifier of the target PoS

(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

(normative)

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

MIH messages	AID
MIH messages for Service Management
MIH_LL_Transfer	10
MIH_N2N_LL_Transfer	11
MIH messages for Command Service
MIH_IF_PreReg_Ready	12
MIH_TNMN_SA_Estab	13
MIH_MNTN_SA_Estab	14
MIH messages for Gateway Service
MIH_L2Message_Delivery	1
MIH_ANQP_Delivery	2
Reserved for other interworking protocols	From 3 to 500
Reserved for vendor specific area	From 501 to 1023

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

TLV type Name	TLV type value	Data type
Media Independent Root Key	78	KEY
Media Specific Root Key	79	KEY
Network Access Identifier	80	NAI
TPoS Identifier TLV	81	TPoS_ID

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

N.65 Termination Phase

Insert N.6 after N.5

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 MIRK is sent by the SPoS to the TPoS and how the MSPMK is installed into the TPoS (AAA). Notice that the SPoA does not conceptually play any role in the signal handling, even though signals exchanged between the MN and the SPoS are transmitted through the SPoA.

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

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

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

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

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

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

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

TPoS MIH application provides MIRK to AAA for future authentication purposes

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

MIH_N2N_MNTN_SA_Estab.response: TPoS MIH user initiates message for SPoS MIH user containing MNnetworkaccessid.

MIH_N2N_MNTN_SA_Estab Response: TPoS relays message to SPoS containing MNnetworkaccessid.

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

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

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

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

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.

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:

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

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

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

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

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

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

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.

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

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

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

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:

Add new Annex P

MN’s Network Access Identifier Format

(informative)

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

Network discovery for single radio handover

(Informative)

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:

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 follow the assumptions in Section 11.3.

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

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.

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.

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.

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.

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

Examples of SRHO

(Informative)

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.

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

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)

(b)

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.

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)

(b)

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.

Figure R.4. Protocol stack showing the transport of WiMAX L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the co-located Proxy GW/ASN-GW will need certain mechanism to communicate with each other, such as an extension (Rx+) of the Rx interface. The Proxy GW/ASN-GW and the target WiMAX BS will also need certain mechanism to communicate with each other, such as an extension (R6+) of the R6 interface.

The co-located Proxy GW/ASN-GW may then proxy between the MN and the target WiMAX BS using the Rx+ to communicate with MN and using the R6+ to communicate with the target WiMAX BS.

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

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:

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

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.

Figure R.5 3GPP 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 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].

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)

(b)

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

(b)

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.

Figure R.8. Protocol stack showing the transport of WiMAX L2 frame of target interface to the co-located SFF/ASN-GW which proxy between the MN and the target PoA.

The MN and the co-located Proxy GW/ASN-GW will need certain mechanism to communicate with each other, such as an extension (R9+) of the R9 interface. The Proxy GW/ASN-GW and the target WiMAX BS will also need certain mechanism to communicate with each other, such as an extension (R6+) of the R6 interface.

The co-located Proxy GW/ASN-GW may then proxy between the MN and the target WiMAX BS using the R9+ to communicate with MN and using the R6+ to communicate with the target WiMAX BS.

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

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.

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

The MN may pre-register with the WiMAX network, using the same interface and transport mechanism as that in proactive authentication.

3: Handover Decision process:

(1) The handover may be triggered by a need such as degradation of source link quality or cost considerations.

(2) A WiMAX ASN 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 3GPP link layer address to the WiMAX link layer address, and future incoming packets are then routed to the WiMAX radio.

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.

Figure R.9 WiMAX to WLAN 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 but may also be other information repository defined elsewhere, such as the ANDSF.

The WiFi Interworking Function (WIF) is defined in WiMAX Forum. It may co-locate at the access router (AR). In the event that it is not co-located there, the WIF communicates with the AR through the W3 interface.

The Proxy GW function is implemented in the combined functions of WiFi Interworking Function (WIF) and WiFi Proxy GW, which are defined in the WiMAX network. When the MN signals to the Proxy GW as if signaling to a point of attachment (PoA), the target PoA may signal to the Proxy GW which acts like a virtual MN. The Proxy GW may also behave like a virtual PoA to signal with the target PoA. The WiFi Signal Forwarding Function (Proxy GW) is defined in WiMAX Forum standard. It may co-locate at the access router (AR). In the event that it is not co-located there, the WiFi-Proxy GW communicates with the AR through the W1 interface.

Interfaces:

W1 interface between the WLAN AR and the WiFi Proxy GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

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

Ry interface between the MS and the WiFi Proxy GW is defined in WiMAX Forum [WMF-T37-010-R016v01].

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

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

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

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)

(b)

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

(b)

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 an extension of R9 interface to communicate with the MN and using an extension of R6 interface to communicate with the target 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.

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: Handover Decision process:

(1) The handover may be triggered by a need such as degradation of source link quality or cost considerations.

(2) A WLAN 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.

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

The MN may pre-register with the WiMAX network, using the same interface and transport mechanism as that in proactive authentication.

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.

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.

Figure R.13 WiMAX to 3GPP single radio handover reference model.

Functional entities:

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

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

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)

(b)

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.

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)

(b)

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.

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.

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.

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: Handover Decision process:

(1) The handover may be triggered by a need such as degradation of source link quality or cost considerations.

(2) A 3GPP EPS 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.

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

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:

Before L3 handover occurs, the target link may perform preparation processes at L2, such as signal strength measurement and power level adjustment.

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.

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.

Figure R.17 Non-trusted WLAN AN to 3GPP single radio handover reference model.

Functional entities:

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

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

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)

(b)

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

(b)

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.

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.

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.

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 presence of ePDG, P-GW, and system information blocks of candidate PoAs to perform radio measurements.

2: Handover Decision process:

(1) The handover may be triggered by a need such as degradation of source link quality or cost considerations.

(2) A 3GPP EPS 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.

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

Before L3 handover occurs, the target link may perform preparation processes at L2, such as signal strength measurement and power level adjustment.

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

Handover Decision

(Informative)

To decide handover, three representative criteria are considerable for handover decision. Criteria to decide handover can be weak SINR (Signal to Interference plus Noise Ratio), QoS and/or cost, and the power consumption of the source link.

Weak SINR of the source link

Figure S.1- HO decision caused by weak SINR of the source link

Figure S.1 shows the case for weak SINR of the source link. Through Link_Going_Down.indication, the source link interface reports its weak SINR. Afterwards, the SRCF orders the target link interface to prepare pre-registration through Link_IF_PreReg_Ready.req. Link_IF_PreReg_Ready is needed, because pre-registration is different from regular registration. While the L2 messages for regular registration are transmitted through the target link, the L2 messages for pre-registration are transmitted through higher layer (TCP or UDP/IP) and the source link. After the target link interface prepares pre-registration, the target link interface responds with Link_IF_PreReg_Ready.confirm.

QoS and/or cost check

Figure S.2- HO decision caused by QoS and/or cost

Figure S.2 shows the case of QoS and/or cost check for HO decision. The source Proxy GW consults the QoS and/or cost with target Proxy GW through MIH_Get_Information. After source Proxy GW recommends the MN to perform handover, the source Proxy GW transmits MIH_IF_PreReg_Ready request message. The SRCF of the MN orders the target link to pre-register through Link_IF_PregReg_Ready.

Power consumption comparison of the link interfaces

Figure S.3- HO decision caused by power consumption comparison

Figure S.3 shows the HO decision to reduce power consumption of the MN. The 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.

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	STDXXXXX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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