Transcript PPT Version

Media Independent Handover
Services and Interoperability
Ajay Rajkumar
Chair, IEEE 802.21 WG
August 2, 2005
IETF 63 – Paris, France
Scenarios considered by 802.21 WG
• Between 802.xx and 802.yy
• 802.3
• 802.11
• 802.15
• 802.16
• Between 802.xx and Cellular
• 3GPP standards
• 3GPP2 standards
• Between 802.11 ESS
August 2, 2005
IETF 63 – Paris, France
What does Heterogeneous Handover
Mean?
• Session Continuity at the IP layer
• Adaptation to new link at layer two
• Address continuity at layer three
• Service Continuity at the Application layer(s)
August 2, 2005
IETF 63 – Paris, France
802.21 Reference Model
August 2, 2005
IETF 63 – Paris, France
Information Service
• Link access parameters
• Security mechanisms
• Neighbor maps
• Location
• Provider and other Access information
• Cost of link
• Etc.
August 2, 2005
IETF 63 – Paris, France
IS Requirements
• Two types of requirements:
• Transport requirements
• Architectural/protocol requirements
• Terminology:
• Network MIHF Instance (NMI)
• Resides in MIH-enabled network element
• Network element must be Layer-4 capable
• Mobile MIHF Instance (MMI)
• Resides in Mobile Node
• Protocol vs. interfaces: two interfaces considered (separately) to
identify requirements
• MMI  NMI is here referred to as “access” MIIS I/F
• NMI  NMI is here referred to as “network” MIIS I/F
August 2, 2005
IETF 63 – Paris, France
Transport Requirements for MIIS
• “access” MIIS I/F:
•
Reliability:
• “network” MIIS I/F
•
Reliability:
August 2, 2005
IETF 63 – Paris, France
Architectural/Protocol Requirements
for MIIS (1)
• Generic requirement for “access” and “network” interface:
•
•
•
•
Protocol messages carry Information Elements specified in 802.21
Protocol defines message format and message payload
Protocol exchanges are query-based (request/response); scenarios where
“delayed” response is provided asynchronously based on an MMI/NMI
request are also considered
Protocol should be independent of any specific mobility protocol
August 2, 2005
IETF 63 – Paris, France
Architectural/Protocol Requirements
for MIIS (2)
• “access” MIIS I/F:
•
Discovery capability:
•
•
•
•
The MMI must be able to discover presence of NMI for accessing IS
service (discovered NMI could be the actual IS server) in either the serving
network or candidate network
The MMI must be able to discover address of NMI for accessing to IS
service in either the serving network or candidate network to exchange L3
or above traffic
It should be possible to drive discovery of NMI for accessing to IS service
though information provided by MMI (e.g. MMI indicates that NMI for
802.11 or 802.16 is needed, if there is one)
Security:
•
•
•
•
•
•
As part of discovery, the MMI must be able to discover whether a security
association can/shall be established with the NMI in either the serving
network or candidate network, and if yes which credentials can be used to
authenticate with NMI
Protocol allows for authentication of NMI by MMI
Protocol enables mutual authentication between MMI and NMI
Payload encryption is optional. On/off decision can be made during
discovery phase (e.g. mandated by MMI or NMI policies)
Integrity protection is supported and required for IS
Replay detection is optional for MIIS
August 2, 2005
IETF 63 – Paris, France
Architectural/Protocol Requirements
for MIIS (3)
• “network” MIIS I/F
•
Security:
•
•
•
•
Protocol enables mutual authentication between NMIs
Payload encryption is optional. On/off decision can be made e.g. based on
NMI policies
Integrity protection is supported and required for IS
Replay detection is optional
August 2, 2005
IETF 63 – Paris, France