Transcript 21-04-0169-02-0000-Nokia_MIH_Proposal.ppt

•
•
•
•
•
•
•
•
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
1
•
•
•
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>
21-04-0169-02-0000
2
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
3
MIH Architectural Framework:
Terminal View (logical)
Applications
TCP/RTP
Policy
Manager
IP/Mobile IP/
IPSec
Bearer Manager
802.21 MIH Function
WLAN
Cellular
802.16
BT
DEVICE DRIVERS
Architectural Framework depicted here for sake of discussion and introduction of proposal
21-04-0169-02-0000
4
MIH Architectural Framework:
Terminal View (Protocol Stack)
MIHF: not a protocol layer!
Policy Management
Apps
SIP
Bearer
Manager
TCP/UDP
802.21
MIH
Function
Management Plane
….
IP
(Mobile IP, IPsec, etc.)
802.11
MAC/PHY
802.16
MAC/PHY
…
802.16
MAC/PHY
Architectural Framework depicted here for sake of discussion and introduction of proposal
21-04-0169-02-0000
5
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
6
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
7
MIH Architectural Framework:
MIH Function (2)
• 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
8
MIH Architectural Framework:
MIH Function (3)
• 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
9
MIH Architectural Framework:
MIH Function (4)
• 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
10
MIH Architectural Framework:
Example Interactions in Terminal
APPLICATIONS
TCP/RTP
Policy
Manager
Application
requirements (e.g.
QoS, security, etc.)
Application events
IP/
Mobile IP/
IPSec
Link/connection events (e.g.
events related to link
quality, etc. for TCP/RTP
optimizations)
Bearer Manager
Event/triggers, e.g. report link
availability and status
Link/connection events filtered
based on policy decisions (e.g.
link availability, link up)
Subscribes to 802.21
event/triggers
Primitives toward
802.21 MIH function
802.21 MIH Function
Event/triggers, e.g. report link
availability and status
Report data from
802.21 information services with L2
transport
Link/connection events filtered
based on policy decisions (e.g.
link availability, link up)
for connection selection when
no mobility protocols are in use
Request data from 802.21
information services
WLAN
Cellular
802.16
BT
DEVICE DRIVERS
21-04-0169-02-0000
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
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
20
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
21
Internal Event/Triggers Description
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_Availa
ble
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
22
Internal Event/Triggers Description
Connection_Down
MIH => Upper
layers
used to indicate that a specific connection is no
longer available
Connection_Chang
e {[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
23
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
24
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
25
Information Services
• Access to Information Services
• Discovery of 802.21 services
• Types of Information
21-04-0169-02-0000
26
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
27
Access to 802.21 Information Service (2)
How • 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
How • 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
21-04-0169-02-0000
28
Access to 802.21 Information Service (3)
How • 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 • 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)
21-04-0169-02-0000
29
Access to 802.21 Information Service (4)
When • 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
21-04-0169-02-0000
30
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
31
Types of Information
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
interface capability
(e.g. available
bandwidth) for
potential links
Link layer
Available for current
status (e.g.
powered down, in
sleep mode, etc.)
Cost
Advertised for potential
link/connection
Both
Available for current
Advertised for potential
link/connection
QoS
Power
levels of QoS
supported
levels of QoS
supported
Both
Power levels in use
e.g. power levels
available for a
specific interface
Link Layer
21-04-0169-02-0000
Available for current
Advertised/queried for
potential link/connection
Available for current
Advertised for potential
link/connection
32
Types of Information
Information
Type
Current
Link/Connection
Potential Link/
Connection
Link
layer/interface
or network
layer
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.)
Both
Available for current
21-04-0169-02-0000
Advertised/queried for
potential link/connection
33
Types of Information
Information
Type
Current
Link/Connection
Potential Link/
Connection
Link
layer/interface
or network
layer
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?)
Both
Available for current
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
Queried for potential
link/connection
Queried for potential
link/connection
Queried for potential
link/connection
34
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
35
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
36
Remote Transport and Architecture
Model for MIH Function
Upper Layers/IP
IP
Access/MAC
Centric Model
=> L2 transport
802.21 MIH
Function
802.21 MIH
Function
MAC/PHY
MAC/PHY
Terminal
AP/Base
Station
Upper Layers/IP
IP
SemiAccess/MAC
Transparent
Model => L2
transport
21-04-0169-02-0000
802.21 MIH
Function
MAC/PHY
Terminal
802.21 MIH
Function
802.21 MIH L2
Transport
MAC/PHY
AP/Base
Station
Can be distributed
function (e.g.
through broker for
inter-domain
scenarios)
Access
Controller
/802.21
Server
37
Remote Transport and Architecture
Model for MIH Function
Upper Layers/IP
IP
Access/MAC
Transparent
Model => L3
transport
21-04-0169-02-0000
802.21 MIH
Function
Logical view
MAC/PHY
Terminal
MAC/PHY
AP/Base
Transport
Station
view
802.21 MIH
Function
Access
Controller
/802.21
“Server”
Can be distributed
function (e.g.
through broker for
inter-domain
scenarios)
38
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
39
L2 Remote Transport for 802.21
Information Service
• 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
40
L2 Remote Transport for 802.21 Information
Service
External I/F to 802.21
functionality
(1)
External
Network
(e.g.
cellular,
other 802
network)
External I/F to 802.21
functionality
Enterprise Network
(3)
(4)
(1)
WLAN (2)
SubDomain
AP(i)1
WLAN
SubDomain
2
AP (ii)
802.21
(3) (4)
Scenario: Intra-802 and Inter-802 Same Domain/ Network
Technology 802.21 Information Service
•
1.
Different possible implementations
i.
ii.
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)
802.21 functionality internal to AP, interacting with other 802.21 functionality in network (APs or servers)
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
3.
4.
•
Terminal subscribes to 802.21 services based on preferences
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)
•
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
21-04-0169-02-0000
41
L3 Remote Transport for 802.21 Information
Service
• 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
42
L3 Remote Transport for 802.21 Information
Service
Internet
(2)
(1)
Cellular
Network
RAN
External I/F to 802.21
functionality
WLAN
Access
Network
AP
802.21-enabled
VPN GW
Enterprise
WLAN
Network
AP
Scenario: Remote Access to 802.21 Information Service
1.
2.
3.
•
•
Terminal subscribes to 802.21 services based on preferences
Information are broadcasted/multicasted (not over media) to other 802.21 function on network
side that subscribed
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)
21-04-0169-02-0000
43
L3 Remote Transport for 802.21 Information
Service
(1) (3)
(1)
(3)
(4) Internet
External I/F to 802.21 External I/F to 802.21 (4)
functionality
functionality
(4)
(2)
(3)
Cellular
Network
RAN
WLAN
Access
Network
AP
802.21-enabled
VPN GW
Enterprise
WLAN
Network
AP
Scenario: Distributed Access to 802.21 Information Service
1.
2.
3.
4.
•
•
802.21 “server” subscribes to 802.21 information services thanks to distributed 802.21
advertisement/discovery
Terminal subscribes to 802.21 services through local server based on preferences
Information are broadcasted/multicasted (not over media) to other 802.21 function on network side that
subscribed
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)
21-04-0169-02-0000
44
L3 Remote Transport for 802.21 Information
Service
External I/F to 802.21
functionality
(2)
External
Network
(e.g.
cellular,
other 802
network)
External I/F to 802.21
functionality
Enterprise Network
(3)
(4)
WLAN
SubDomain
AP1
(1)
(1)
(1)
WLAN
SubDomain
AP2
Other 802
SubDomain
Scenario: Intra-802 and Inter-802 Same Domain/ Network
Technology 802.21 Information Service
1.
2.
3.
4.
•
•
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)
Information are broadcasted/multicasted (not over media) to other 802.21 function on network side that
subscribed
Terminal subscribes to 802.21 services through local server based on preferences
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)
21-04-0169-02-0000
45
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
46
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.21enabled, 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
47
802.21 Triggers and Information Service
vs. Type of Handoff
Type of Handoff
Terminal controlled
Network Controlled (terminal supported)
802.21
Service
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 networkcontrolled 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
Information generated in terminal reported to
network MIHF (upon subscription or specific
request)
Can be part of trigger (e.g. a better access
becomes available based on information
service
21-04-0169-02-0000
48
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
21-04-0169-02-0000
49