21-04-0169-02-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-04-0169-02-0000 Title: Nokia MIH Proposal Date Submitted: January, 10, 2004 Presented

21-04-0169-02-0000 1

• IEEE 802.21 MEDIA INDEPENDENT HANDOVER

• DCN: 21-04-0169-02-0000

• Title: Nokia MIH Proposal

• Date Submitted: January, 10, 2004

• Presented at IEEE 802.21 session #06 in Monterey (CA)

• Authors or Source(s):

• Stefano M. Faccin, Michael Williams

• Abstract: This presentation outlines a proposal for the 802.21 Media Independent Handover, covering event/triggers, MIH model and information service.

21-04-0169-02-0000 2

IEEE 802.21 presentation release statements

• This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

• The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21.

• The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>

http://standards.ieee.org/guides/opman/sect6.html#6.3

http://standards.ieee.org/board/pat/guide.html



21-04-0169-02-0000 3

Contents

• A revised version based on comments received

• Architectural framework for 802.21 MIH

• Model for MIH Functionality

• Triggers/Events model

• Information Service

• Transport Solutions for 802.21 services

• Conclusion

21-04-0169-02-0000 4

DEVICE DRIVERS

MIH Architectural Framework: Terminal View (logical)

IP/Mobile IP/IPSec

ApplicationsTCP/RTP

Bearer Manager

802.21 MIH Function

PolicyManager

WLAN Cellular 802.16 BT

Architectural Framework depicted here for sake of discussion and introduction of proposal

21-04-0169-02-0000 5

MIH Architectural Framework: Terminal View (Protocol Stack)

Management Plane

TCP/UDP

IP(Mobile IP, IPsec, etc.)

802.11 MAC/PHY

802.16 MAC/PHY

802.16 MAC/PHY

…

802.21 MIH

Function

Apps

….SIP

Bearer Manager

Policy Management

Architectural Framework depicted here for sake of discussion and introduction of proposal

MIHF: not a protocol layer!

21-04-0169-02-0000 6

MIH Functional Framework

• Framework depicts two main functions• Bearer Manager• MIH function

• Bearer Manager• represents an abstraction of connection management on terminal side• introduced in framework discussion to better identify functionality of

MIH function wrt connection management• not specified in 802.21• indicates functionality that is in charge of connectivity decisions and

handles L3 aspects

21-04-0169-02-0000 7

MIH Architectural Framework: MIH Function (1)

• Collects information and relies event to Bearer Manager and other protocol layers or functions that subscribed to them

• MIHF maps requests and requirements from Bearer Manager and other functions/protocols to link layers

• Converts different link layer parameters to enable connection decision (e.g. mapping between different QoS characterizations)

• Does not make connection or handoff decisions:

• Bearer Manager (not specified in 802.21) makes decisions based on:

• information available through 802.21 information service and from Layer 2 drivers

• 802.21 events• application requirements and policies (user, equipment

owner, operator, etc.)

21-04-0169-02-0000 8


• MIHF maintains state information• Currently available accesses, and corresponding discovered features/requirements (e.g.

authentication/security requirements, cost, domain, etc.)• Current connections and respective status• Configuration information obtained by subscribing functions/protocols

• Triggers to upper layers delivered upon subscription but based on Bearer Manager decisions, e.g.

• Mobile IP not informed of a “link up” if the link is not suitable based on application requirements and policies (e.g. level of security)

• Bearer Manager initiates setup of VPN/IPSec secure tunnels based on need to setup connection over a specific access and information discovered regarding the access requirements

• MIHF may masks link layer details: • e.g. 802.11 signal strength not reported to Bearer Manager

• For predictive handoff MIHF may implement two-thresholds mechanism based on strength reports from driver it triggers: when signal goes below first threshold, MIHF provides “Current link may go down” trigger to Bearer Manager, so that it can begin setting up an alternative connection. When signal goes below second threshold, MIHF provides “Current link down” trigger to Bearer Manager to trigger the actual handoff

• e.g. Data throughput and QoS are reported based on events and information subscription and on requests

• details of this should not be standardized, only triggers, trigger subscription (and MIHF “configuration” by other functions/protocols) and information service

21-04-0169-02-0000 9


• What MIHF does not do?• Connection/handoff decision or any type of policing: MIHF supports such

actions with triggers and information service• A must to be independent of specific implementation and OS

• Admission control: MIHF supports decisions providing information service (e.g. terminal know up front if required QoS will be available on new access)

• Security (e.g. authentication, VPN setup, etc.): • performed through access specific or L3 mechanisms• E.g. if VPN tunnel needed over access after handoff, bearer managers sets up tunnel

before (preferred) or after handoff

• Backward compatibility• since 802.21 will be introduced gradually, backward compatibility must be

ensured• impact on terminals: for accesses with no 802.21 information service and

triggers, assumption is that handoff can be performed based on current unreliable solutions (i.e. basic information, e.g. “link up” with no additional details is provided)

• impact on network: if a terminal is not 802.21-enabled, networks implementing NW-controlled handoff must discover this

• 802.21 discovery is suggested in this proposal (in transport section)

21-04-0169-02-0000 10


• Location of handoff “control” versus MIHF• 802 technologies with loose coupling:

• control is in terminal, MIHF in terminal plays key role to support decision• MIHF in network mainly for information service

• 802 technologies with tight coupling:• Control can be in network, depending on network implementation

• 802 and non-802 technologies (e.g. .11 and cellular)• Control can be both in network and terminal, depending on deployment scenario• Even when control is in terminal (e.g. on when to handoff), network can exercise

control by providing specific information through MIH services

21-04-0169-02-0000 11

MIH Architectural Framework: Example Interactions in Terminal

DEVICE DRIVERS

IP/Mobile IP/

IPSec

APPLICATIONSTCP/RTP

Bearer Manager

Event/triggers, e.g. report link availability and status

Report data from 802.21 information services with L2

transport

Request data from 802.21 information services

Event/triggers, e.g. report link availability and status

Application requirements (e.g.

QoS, security, etc.)

Subscribes to 802.21 event/triggers

Primitives toward 802.21 MIH function

Application events

802.21 MIH Function

WLAN Cellular 802.16 BT

Link/connection events (e.g. events related to link quality, etc. for TCP/RTP optimizations)

Link/connection events filtered based on policy decisions (e.g. link availability, link up)

Link/connection events filtered based on policy decisions (e.g. link availability, link up)for connection selection when no mobility protocols are in use

PolicyManager

21-04-0169-02-0000 12

MIH Functionality Primitives (1)

• A non exhaustive list is provided here• Triggers are generic (independent on protocol/function

subscribing for events)• Primitives parameters depend on subscribing protocol/function• Specific parameters may be required by subscribing different

protocol/function• Subscribing protocol/function will indicate when and under which

conditions event shall be reported

21-04-0169-02-0000 13

MIH Functionality Primitives (1)

• Event Discovery Request / Response {[Event_Type]}• Used to discover the events available• The response contains a list of the events available

• Event Registration Request {[Event_Type, Event_Features]} / Response {[Result_Code]}

• Upon discovery of events available, this is used by the requesting function/protocol to register for a particular set of event. The request indicates:

• the type of event (Event_Type, representing the identity of the event)• the features for the specific type of event (different events have different

features, to be specified separately). Features include:• Thresholds, used e.g. to specify a minimum or maximum threshold

value beyond which a Event must be sent by the destination interface. This request may be generated after MIHL has initialised depending on configuration. It may also be generated upon receiving requests from upper layers.

• Frequency: how often the event should be sent• Parameters: to describe what parameters should be reported in the

event (e.g. to provide link-layer parameters to upper layers for RTP/TCP optimizations)

21-04-0169-02-0000 14

MIH Functionality Primitives• Event Registration Request is also used to modify previous registrations:

• Register for a new event: if the request contains the Event_Type of an event the requesting function/protocol has not subscribed before, the MIF function registers the function/protocol for such event

• Modify previous registration: if the request contains the Event_Type of an event the requesting function/protocol has subscribed before, the MIF function registers the function/protocol for such event with the new features provided (e.g. difference Frequency)

21-04-0169-02-0000 15

MIH Functionality Primitives• Event De-Registration Request {[Event_Type]} / Response

{[Result_Code]}• This request is used to cancel existing registration for the requesting

function/protocol. Only the event indicated by the Event_Type list are deregistered (Event_Type = “all” is permitted to de-register all events).

• An Event Registration Response is sent to the requesting function/protocol containing either indication of success or an error code

• Upon receiving the request, the MIH function registers the requesting function/protocol for the events. An Event Registration Response is sent to the requesting function/protocol if successful, or an error message is sent otherwise.

21-04-0169-02-0000 16

MIH Functionality Primitives• Interface Status Request {[Interface_ID, [Interface_Feature]]} /

Response {[Interface_ID, [Interface_Feature/Result_Code]]}• The request is used to obtain information regarding a certain interface that upper

layers know to be available (e.g. thanks to 802.21 information services and events), e.g. when the terminal is exploring a potential new connection

• Request are made on a specific interface (Interface_ID)• By specifying which Interface_Feature the requesting function/protocol is

interested in, it can enquire about specific information relevant to carry out a decision:

• Cost• QoS (theoretical QoS level)• Security mechanism supported/required by the interface• Etc. (see information services for type of information available)

• The response contains the specific features or an error code in Result_Code in case the requested features are not available or the interface is not available

21-04-0169-02-0000 17

MIH Functionality Primitives• Interface Configuration Request {Interface_ID, [Interface_Feature]} / Response

{Interface_ID, [Result_Code]}• used to configure the features of a specific interface

• Connection Setup Request {Interface_ID, Connection ID, [Interface_Parameter]} / Response {Interface_ID, Connection ID, [Result_Code]}

• used to request a specific interface to setup a connection. The MIHF maps a request incoming from Bearer Manager with this primitive into a request to the interface driver to perform the sequence of actions required to setup the connection

• MIHF involve in connectivity setup to allow MIHF to have updated and complete picture of terminal connectivity• Interface_Parameter is used to provide the necessary parameters for the connection

(including e.g. the AP, the domain to connect to, etc.) • The Connection Setup Response is sent upon successful establishment of the connection or

with an error code• Connection_ID will be used between the requesting protocol/function and the MIH

function to identify the connection for future operations

• Connection Tear-Down Request {Connection ID} / Response {Connection ID, [Result_Code]}

• Used to request tear-down of a specific connection

21-04-0169-02-0000 18

MIH Functionality Primitives• Connection Status Request {[Interface_ID, Connection ID,

[Connection_Feature]]} / Response {[Interface_ID, Connection ID, [Connection_Feature/Result_Code]]}

• The request is used to obtain information regarding a certain current connection (i.e. the terminal may be using actively such connection or exploring a potential connection)

• Request are made on a specific connection basis (Connection ID) for specific interfaces (Interface_ID)

• By specifying which Connection_Feature the requesting function/protocol is interested in, it can enquire about:

• Cost• QoS (theoretical QoS level)• Data throughput (actual data throughput)• Security mechanism in use• Etc.

• The response contains the specific features or an error code in Result_Code in case the requested features are not available or the connection does not exist

21-04-0169-02-0000 19

MIH Functionality Primitives

• Handover Request {} / Response {}• used to request a handover between interfaces• Whether all connections are handed over or a subset of the connection only

(indicated by the requesting function/protocol) is handed over is TBD

21-04-0169-02-0000 20

MIH Event/Triggers

• Two types of event/triggers:• Internal event/triggers

• When lower layers send triggers to MIH function, triggers are propagated to upper layers based on subscription

• Across an interface => 802.21 event signaling

21-04-0169-02-0000 21

Internal Event/Triggers Description

Link_Available Lower layers => MIH

used to indicate availability of a new link. Generated from lower layers (PHY or MAC), propagated by MIH based on subscription. MIH function may use 802.21 information services upon receiving trigger to discover additional features of the link before reporting to upper layers.

Link_Going_Up Lower layers => MIH

used to indicate that a specific link is being connected (it may provide the estimated delay to link up)

Link_Up Lower layers => MIH

used to indicate that a specific link has been connected

Link_Down Lower layers => MIH

used to indicate that a specific link is no longer available

21-04-0169-02-0000 22


Link_Change {[Features]}

Lower layers => MIH

used to inform the upper layers that specific features of the link have changed (e.g. QoS, data throughput, etc.). All the features that have changed are reported (according to event subscription)

Connection_Available

MIH => Upper layers

used to indicate availability of a new connection. Generated from lower layers (PHY or MAC), propagated by MIH based on subscription. MIH function may use 802.21 information services upon receiving trigger to discover additional features of the link before reporting to upper layers.

Connection_Going_Up

MIH => Upper layers

used to indicate that a specific connection is being connected (it may provide the estimated delay to link up)

Connection_Up MIH => Upper layers

used to indicate that a specific connection has been connected

21-04-0169-02-0000 23


Connection_Down MIH => Upper layers

used to indicate that a specific connection is no longer available

Connection_Change {[Features]}

MIH => Upper layers

used to inform the upper layers that specific features of the connection have changed (e.g. QoS, data throughput, etc.). All the features that have changed are reported (according to event subscription)

Event_Discovery MIH => Upper layers

Used to inform upper layers new event types are available (provide periodic updates)

21-04-0169-02-0000 24

Additional Details on Events/Triggers

• Subscribers (example list)• Bearer manager• Mobile IP• Applications

• E.g. for multi-access support by applications that do not use Mobile IP

• Interdependency of triggers:• Detailed definition of triggers includes detailed interdependency• Not all triggers treated sequentially (e.g. different levels of trigger

priority are introduced)• E.g. MIH function my act different upon a Link_Available whether current

link is stable or Link_Going_Down is received for current link, or on Link_Going_Down when an handover command is received from the network

• Details in detailed text proposal

21-04-0169-02-0000 25

802.21 Event Signaling

• Based on MIH Functionality Primitives:• Event Discovery Request/Response• Event Registration Request/Response• Event De-Registration Request /Response• Interface Status Request/Response• Interface Configuration Request/Response• Connection Setup Request/Response• Connection Tear-Down Request/Response• Connection Status Request/Response• Handover Request/Response

21-04-0169-02-0000 26

Information Services

• Access to Information Services

• Discovery of 802.21 services

• Types of Information

21-04-0169-02-0000 27

Access to 802.21 Information Service (1)

• Characteristics:• Accessible from any network• Primarily “static” information• Possible to access information about networks available on one interface

type from a different interface (e.g. learn about .11 AP’s from the cellular link)

• Different dimensions specified in the solution:• How the information is carried (e.g. broadcasting versus probe/response)• “Where” to get such information

• E.g. in proximity/p2p networking scenarios (e.g. getting such information from neighbors to avoid unnecessary traffic over currently used access, e.g. cellular)

• What information is carried• When the information is obtained• The scope/type of transport (L2 or L3)• Security

• How the information is carried: proposal enables• information to be broadcasted• query/response access to information

• Transport: solution is defined to be transport independent

21-04-0169-02-0000 28


• Two types of access• Distribution (advertisement)

• This means information are distributed e.g. in a “broadcast” fashion (e.g. part of link layer beacon)

• Query/response• In several cases, plain distribution (e.g. broadcast) on Information Services data

is not practical (too much information) => a query/response mechanism is proposed to enable access to such information

• Query/response needed for link layers that do not support any form of broadcasting/advertisement of information

• Two models are possible (not mutually exclusive)• Direct access: terminals access directly the information services

provided by 802.21 functionality of a given network• Distributed access: networks have 802.21 network functions that

talk to each other to:• Advertise information availability: allows other 802.21 network functions and

terminals to be aware of what information a given 802.21 network functions can provide, used to inform 802.21 network functions and terminal 802.21 function of what they may be interested in subscribing to

• Publish the information to subscribers

How

How

21-04-0169-02-0000 29


• Two relevant aspects for the access:• Advertisement/publishing of information

• More information in detailed text submission• Semantic:

• E.g. how query is performed, what type of information is provided• based on more or less precise queries, 802.21 network function can decide if it

has info cached locally or needs to retrieve them (e.g. from the 802.21 network function that advertised the availability of such information)

• current slide set does not contain such details: semantics to be presented at next level of detail in discussion

• Where is Information Service accessed from:• Current access:

• Data for new link/network is obtained through current access• New access:

• Data for new link/network is obtained through current access• Closely related to transport of information services (see transport

section)

How

Where

21-04-0169-02-0000 30


• Access of information:• Pro-actively:

• e.g. through broadcasting, before handoff/connectivity decision must be taken• Corresponds to “bootstrapping” scenario

• Reactively: • just before handoff/connectivity decision must be taken (e.g. upon specific

request to MIHF from protocol/functions)• Based on specific remote query/responses

• 802.21 does not rely on any single one of these two options

When

21-04-0169-02-0000 31

Types of Information

• Include:• Information available to MIH function on current links/connections• Information on potential links/connections• Constitutes dynamic information set to perform connectivity/handover

decisions

• List is not exhaustive, provided as initial draft

21-04-0169-02-0000 32


Information Type

Current Link/Connection

Potential Link/ Connection

Link layer/interface or network layer

Available or type of discovery required

Link Features parameters used by current link

status (e.g. powered down, in sleep mode, etc.)

interface capability (e.g. available bandwidth) for potential links

Link layer Available for current

Advertised for potential link/connection

Cost Both Available for current


QoS levels of QoS supported

levels of QoS supported

Both Available for current

Advertised/queried for potential link/connection

Power Power levels in use e.g. power levels available for a specific interface

Link Layer Available for current


21-04-0169-02-0000 33


Information Type




Available or discovery required

Security security level, authentication method/algorithm, encryption algorithm in use and available

security level, authentication method/algorithm, encryption algorithm available and/or required (indicate what the terminal needs to do to gain secure access, e.g. open authentication + VPN establishment, , 802.11i security establishment at WLAN only, 802.11i security + VPN establishment, 802.11i security + authentication with a FA, etc.)


Advertised/queried for potential link/connection

21-04-0169-02-0000 34

Types of InformationInformation Type




Available or discovery required

Roaming/ Security Domain

Security domains accessible (e.g. for authentication credentials)

Security domains accessible (e.g. for authentication credentials). Terminal queries about accessibility to specific domains (can I use my credentials here?)


Queried for potential link/connection

Accessible core networks

Core networks reachable (e.g. based on roaming agreements and broker interconnections)

Core networks reachable (e.g. based on roaming agreements and broker interconnections): can I get to a given PLMN core network from here?

Connection layer

Available for current


Accessible Services

Services accessible (e.g. 3GPP IMS)

Services accessible (e.g. 3GPP IMS): can I get this service here?

Connection layer

Available for current


21-04-0169-02-0000 35

Transport Aspects

• Transport for:• Event/triggers• Information Services

• Local transport (i.e. inside terminal): • MIH-link layer:

• use generic SAP at MIH side, media specific SAP at link layer side• MIH-upper layers:

• use generic SAP both at MIH side and upper layer (e.g. bearer manager)• use generic SAP at MIH side, protocol specific SAP at upper layer

21-04-0169-02-0000 36

Remote Transport Aspects for 802.21 Triggers and Information Service

• Assumptions: • 802.21 does not define specific transports (L2 or L3)• Event notification/trigger service and information service defined to be

transport independent 802.21 defines a set of IE and the logic on how they are exchanged (when and why)

• IE are carried in different transports (L2 and L3)• The needed transport/encapsulation of 802.21 payload in L2 will be

defined by each 802 family member, and added to their standard• L3 transport is defined in IETF• 802.21 defines a set of recommendations (e.g. requirements to be

satisfied), and influences other groups (.11, .16, IETF, 3GPP, 3GPP2) through liaison and by submitting recommendations

21-04-0169-02-0000 37

Access Controller/802.21Server

Remote Transport and Architecture Model for MIH Function

MAC/PHY

802.21 MIH Function

MAC/PHY

802.21 MIH Function

Terminal AP/BaseStation

MAC/PHY

802.21 MIH Function

IP

MAC/PHY

802.21 MIH L2 Transport

Terminal AP/BaseStation

802.21 MIH Function

Access/MAC Centric Model=> L2 transport

Semi-Access/MAC

Transparent Model => L2

transport

Can be distributed function (e.g. through broker for inter-domain scenarios)

Upper Layers/IP

IP

Upper Layers/IP

21-04-0169-02-0000 38

Access/MAC Transparent

Model => L3 transport

Remote Transport and Architecture Model for MIH Function

Access Controller/802.21“Server”

MAC/PHY MAC/PHYTerminal AP/Base

Station

802.21 MIH Function

802.21 MIH Function

IP

Upper Layers/IP

Logical view

Transport view

Can be distributed function (e.g. through broker for inter-domain scenarios)

21-04-0169-02-0000 39

L2 Remote Transport for 802.21 Information Service

• E.g. over 802.11 MAC with extensions to MAC to enable transport of new Information Elements

• L2 transport can amount to potentially:• extending beacon (for broadcasting of Information Service data)• extending the current .11k probe request/response mechanism to enable

carrying• as data traffic (to avoid slowness of management frames) at highest

priority (11e assumed)• other solutions (e.g. new MAC specific signaling with high priority) to

be studied in 802.11/.16/etc., however 802.21 must consider feasibility and should provide requirements and recommendations

• Bridged network with direct 802.21 communications between APs supported

21-04-0169-02-0000 40

• Where is the information accessed from:• Current access:

• Very useful e.g. when accessing over cellular and not wanting to have to “scan” for all other technologies available

• Useful when new access deploys an 802.21 “server” in network without upgrading “APs” to support 802.21: in such way terminals can still benefit of 802.21 to speed up handoff to new access

• New access:• In most cases possible only with L2 transport (L3 would require actually

accessing the media, thus requiring authentication, etc.)• Availability of 802.21 service over beacon should be provided

• An important aspects is how the terminal chooses when service is available both through current and new access. E.g. when two accesses are in different (security) domains, it is more probable than more information are available through new access (i.e. two domains may not interchange 802.21 information). However, terminal does not know whether new access is in new domain or not without first receiving 802.21 information e.g. access 802.21 information through new access by default when available


21-04-0169-02-0000 41

• Different possible implementationsi. 802.21 functionality external to AP, AP with enhanced MAC to carry 802.21 information (for existing APs, AP requires

only firmware upgrade to support new signaling, no additional function required)ii. 802.21 functionality internal to AP, interacting with other 802.21 functionality in network (APs or servers)

1. Information are broadcasted/multicasted (not over media) to other 802.21 function on network side that subscribed for distribution of 802.21 information

• 802.21 server that acts as interface to external networks filters/consolidates the information to be provided to external networks

2. AP interfaces with external 802.21 functionality• Information elements generated at external 802.21 server, AP carries signaling to/from STA, forwards query from STA to

server, receives information (e.g. for broadcast) from 802.21 server. I/F between AP and 802.21 external functionality is outside the scope of 802.21

3. Terminal subscribes to 802.21 services based on preferences4. Alternatively, no subscription but query/request by the terminal based on terminal policies (on when and what)• Access is over L2: Potentially extension of 802.11k (beacon for broadcast part, probe request/response for

response/request)

Enterprise Network

WLAN Sub-

Domain 1

WLAN Sub-

Domain 2AP (ii)AP(i)

(1)

External I/F to 802.21functionality

(3)(4)

(1)

(2)

Scenario: Intra-802 and Inter-802 Same Domain/ Network Technology 802.21 Information Service

ExternalNetwork

(e.g. cellular,

other 802 network)


802.21

(3) (4)


21-04-0169-02-0000 42

• This in reality is transport of L2-specific information over L3• L2 information comprises:

• Connectivity information• Security information

• e.g. similarly to what L2TP does for different purposes

• Both broadcast and request/response model can be supported

• A protocol must be specified to carry the IEs defined by 802.21• Could be specifying as an existing protocol can carry such information,

or a new protocol• In both cases, a close liaison with IETF is needed since 802.21 does not

specify L3 solutions

• For information services on cellular side, L3 seems to be only viable solution on short term

• L2 requires changing L2 cellular protocols to enable carrying the new information


21-04-0169-02-0000 43

1. Terminal subscribes to 802.21 services based on preferences2. Information are broadcasted/multicasted (not over media) to other 802.21 function on network

side that subscribed 3. Alternatively, no subscription but query/request by the terminal based on terminal policies (on

when and what)• Access is over IP (protocol TBD, re-use of existing protocols would be favorable)• How does terminal know where to send subscription request and queries:

• based on 802.21 advertisement where available• based on information stored in the terminal (e.g. list of URLs or names translated through

DNS to locate the source of 802.21 information for given networks) => requires pre-configuration of terminal by operator and/or owner (e.g. enterprise)

Internet

Cellular Network

WLAN Access

NetworkRAN AP

Enterprise

WLAN NetworkAP

802.21-enabledVPN GW


Scenario: Remote Access to 802.21 Information Service

(1)(2)


21-04-0169-02-0000 44

1. 802.21 “server” subscribes to 802.21 information services thanks to distributed 802.21 advertisement/discovery

2. Terminal subscribes to 802.21 services through local server based on preferences3. Information are broadcasted/multicasted (not over media) to other 802.21 function on network side that

subscribed 4. Alternatively, no subscription by terminal, but query/request by the terminal based on terminal policies (on

when and what)• Access is over IP (protocol TBD, re-use of existing protocols would be favorable)• How does terminal know where to send subscription request and queries:

• based on 802.21 advertisement where available• based on information stored in the terminal (e.g. list of URLs or names translated through DNS to locate the source of

802.21 information for given networks) => requires pre-configuration of terminal by operator and/or owner (e.g. enterprise)

Internet


Cellular Network

WLAN Access

NetworkRAN AP

Enterprise

WLAN NetworkAP

802.21-enabledVPN GW


Scenario: Distributed Access to 802.21 Information Service

(2)


(1) (1)

(3)

(3)(3)

(4)

(4)(4)

21-04-0169-02-0000 45

1. 802.21 functionality can be centralized (e.g. in an AC) or distributed (in APs), various architecture shall be enabled by 802.21 mechanisms. 802.21 functionality is configured based on specific network mechanisms (manual, automatic, etc., not in scope of 802.21, more of a management issue)

2. Information are broadcasted/multicasted (not over media) to other 802.21 function on network side that subscribed

3. Terminal subscribes to 802.21 services through local server based on preferences4. Alternatively, no subscription by terminal, but query/request by the terminal based on terminal policies

(on when and what)• Beside L2 transport described before, access can be also over IP (protocol TBD, re-use of existing

protocols would be favorable)• How does terminal know where to send subscription request and queries:

• based on 802.21 advertisement where available (e.g. over MAC, e.g. 802.11 beacon indicating availability of 802.21 service)• based on information stored in the terminal (e.g. list of URLs or names translated through DNS to locate the source of 802.21 information

for given networks) => requires pre-configuration of terminal by operator and/or owner (e.g. enterprise)


Enterprise Network

WLAN Sub-

Domain 1

WLAN Sub-

Domain 2APAP

(2)


(3)(4) (1)

(1)

Scenario: Intra-802 and Inter-802 Same Domain/ Network Technology 802.21 Information Service

Other 802 Sub-Domain

(1)ExternalNetwork

(e.g. cellular,

other 802 network)


21-04-0169-02-0000 46

Access to 802.21 Information Service: Reliability and Security

• Reliability• Remote trigger delivery: essential for e.g. network controlled handoff • Information service: reliability important when service used to find out

information in a reactive mode (e.g. just before handoff) • Reliability in terms of:

• Ensure delivery• Timely delivery/response

• How is reliability supported?• 802.21 does not specify transport• Specific L2 instantiations and L3 solution in charge of supporting reliability (depending on

discussion in relevant groups/fora)• Assumption in this proposal:

• Reliability is considered as possible when 802.21 is implemented (both L2 and L3)• Reliability delivered by specific instantiation (i.e. mapping to specific link)• 802.21 scenarios that need reliability defined as valid only when transport reliability can be

provide reliability not required for every 802.21 service, but scenarios based on transport reliability developed in 802.21 (i.e. not discarded just because reliability may not be achieved in every instantiation of 802.21)

• Security:• 802.21 information service and remote triggers must be protected at least for data

integrity, possibly for authentication of source• Corrupted data may lead to wrong decisions

• E.g. 802.11 hotspot advertised as free to lure terminals away from other access or hotspot• Security not defined in 802.21• Recommendations/requirements defined to ensure different instantiations

(e.g. .11, .16. Etc.) support security

21-04-0169-02-0000 47

Discovery of 802.21 services

• To enable 802.21 operations, discovery of 802.21 availability is required

• E.g. terminal must know whether a certain access supports 802.21

• Terminal discovery• L2 is 802.21 enabled: discovery can happen through new access or

current access

• L2 support for discovery

• Backward compatibility• 802.21 must work out scenarios (e.g. “terminal is 802.21-enabled, old

access is not enabled, new access is enabled” versus “terminal is 802.21-enabled, old access is enabled, new access is not”)

• define behavior/expectations of terminal and network in such scenarios to ensure interoperability

• create recommendations for L2 and L3 solutions

21-04-0169-02-0000 48

802.21 Triggers and Information Service vs. Type of Handoff

Type of Handoff

Terminal controlled Network Controlled (terminal supported)

Triggers Actual reason to begin handoff on terminal side

Network must know terminal can indeed move, plus terminal requirements to enable this scenario, network MIHF must be aware of connection requirements and features (not only after one handoff, but from beginning of connection) since network MIHF is currently not involved in connectivity setup, nor it is expected to be, MIHF in terminal must report connectivity setup event to MIHF in network when network required network-controlled handoff (this must be discovered by terminal, or explicitly requested by 802.21 MIHF function)

Information service

Collected by MIHF in terminal locally and from network to enable decision of “where” to handoff

Can be part of trigger (e.g. a better access becomes available based on information service

Information generated in terminal reported to network MIHF (upon subscription or specific request)

802.21 Service

21-04-0169-02-0000 49

Conclusion

• A proposal covering the various aspects of 802.21

• High level of detail to allow for introductory discussion

• Next level of details to be provided in draft text at January meeting

Documents

21-04-0169-02-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-04-0169-02-0000 Title: Nokia MIH Proposal Date Submitted: January, 10, 2004 Presented