Transcript 21-05-0373-01-0000-MIH_Capability_Discovery

• IEEE 802.21 MEDIA INDEPENDENT HANDOVER
• DCN: IEEE802.21-05-0373-01-0000
• Title: Proposed modification of the MIH Capability Discovery
• Date Submitted: September 13, 2005
• Presented at IEEE 802.21 in Garden Grove, CA
• Authors or Source(s): Eunah Kim, Junghoon Jee, Jong-Hwa Yi
ETRI
• Abstract: This contribution proposes amendments related to the MIH
Capability Discovery. First, we define a new value, “Capability Discovery”, in
MIH Service ID. Second, we suggest the MIH_Capability_Discover.request
to contain the MIH message data. Third, we specify the transport way for
discovering the MIH capability on each different media types. Finally, we
define new SupportedTransportProtocol in MIH message data.
21-05-0373-01-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-05-0373-01-0000
2
MIH General Packet Format
• The MIH Service ID defines three
services ;
•
•
•
1 : Event Service
2 : Command Service
3 : Information Service
• All MIH Messages should be classified
into the above three services
•
•
MIH Capability Discover Messages
don’t belong to any of them, resulting
in problems with their
encoding/decoding
A New value for the MIH Service ID
should be added for Capability
Discovery
• 4 : Capability Discovery
21-05-0373-01-0000
MIH
Message
Header
octet 1
octet 2
octet 3
octet 4
Protocol Ver
MIH Service ID
MIH Opcode
Transaction ID
Message Length
F
Fragment No
Reserved
MIH Function Identifier Length
MIH Function Destination Identifier
MIH Function Source Identifier
MIH Identifier
MIH
Message
Payload
MIH Message Data
3
MIH Capability Discovery(1/4)
•
MIH Capability Discovery is described in Section 8.3 as follows
1. MIHF in mobile terminal or MIHF in the network discovers which entity supports
MIHF
2. Thereafter The peer MIHFs negotiate/discover an optimum transport for
communication
3. The MIHF entities also discover list of supported events and commands
4. The MIHF can also query the information schema for list of supported information
elements
•
Section 8.5 Protocol Flow says
•
MIH Capability Discovery can be done through media specific broadcast messages or
through on-demand MIH capability discovery messages
•
The discovery through media specific broadcast messages performs only the first function
described above in a limited way. For other three functions, we still need on-demand MIH
capability discovery => is it necessary to have the media specific discovery method?
21-05-0373-01-0000
4
MIH Capability Discovery(2/4)
1.
MIHF in mobile terminal or MIHF in the network discovers which entity
supports MIHF
•
According to the Protocol Flow in Section 8.5
•
•
Through media specific broadcast messages
–
e.g. beacon in 802.11 and DL-MAP in 802.16
–
network to mobile terminal direction only
On-demand MIH Capability Discovery
–
Capability discovery handshake and Capability advertisement
–
Problem : How could the peer MIHFs communicate each other?
»
21-05-0373-01-0000
They don’t know which transport they have to use for MIH Capability
Discover Messages delivery
5
MIH Capability Discovery(3/4)
2.
Thereafter The peer MIHFs negotiate/discover an optimum transport for
communication
•
3.
Not defined in the baseline draft P802.21/D00.02
The MIHF entities also discover list of supported events and commands
•
Can be done through on-demand MIH Capability Discovery
•
Two capability discovery handshake or capability advertisement procedures are
required
•
MIH_Capability_Discover.request message doesn’t contain the MIH message data
•
MIH_Capability_Discover.response message may contain “SupportedEventList” and
“SupportedCommandList” in the MIH message data
•
If MIH_Capability_Discover.request message also can have the MIH message data
including “SupportedEventList” and “SupportedCommandList”, these procedures will be
shortened.
21-05-0373-01-0000
6
MIH Capability Discovery(4/4)
4.
The MIHF can also query the information schema for list of supported
information elements
•
Could be done through information service?
21-05-0373-01-0000
7
Proposal (1/2)
•
To support on-demand MIH capability discovery, a transport for communication should
be defined and fixed.
•
We propose to add a new column, “Transport for MIH Capability Discovery”, in Table 11.
Transport options in Section 8.2.
No
Media Type
Transport for MIH Capability Discovery
Preferred
Transport
L2 Transport
L3 Transport
1
Ethernet
L2 (Data Plane)
L2
Data Frames
IP based
2
802.11
L2 (Management Plane)
L2
Data Frames, Management Frames
IP based
3
802.16
L2 (Management Plane)
L2
Data Frames, Management Frames
IP based
4
3GPP
L3 (will be defined in IETF?)
L3
Requires protocol stack changes
IP based
5
3GPP2
L3 (will be defined in IETF?)
L3
Requires protocol stack changes
IP based
21-05-0373-01-0000
8
Proposal (2/2)
•
We propose the MIH data for
MIH_Capability_Discover messages
•
It will be contained in both request and
response type of messages.
•
It will shorten for peer MIHF entities to
discover list of supported events and
commands
•
A new defined “SupportedTransportList”
will support for peer MIHF entities to
negotiate/discover an optimum transport
for each service
Name
Length
Value
Octet 1 specifies the transport for event service.
For each Bit location, a value of ‘1’ indicates the transport is supported
Bit #0 : L2, Data plane
Bit #1 : L2, Management plane
Bit #2 : L3, IP protocol
Bit #3 : L3, TCP protocol
Bit #4 : L3, UDP protocol
Bit #7 - Bit #5 : Reserved
SupportedTransportList
4
Octet 2 specifies the transport for command service.
For each Bit location, a value of ‘1’ indicates the transport is supported
Bit #0 : L2, Data plane
Bit #1 : L2, Management plane
Bit #2 : L3, IP protocol
Bit #3 : L3, TCP protocol
Bit #4 : L3, UDP protocol
Bit #7 - Bit #5 : Reserved
Octet 3 specifies the transport for information service.
For each Bit location, a value of ‘1’ indicates the transport is supported
Bit #0 : L2, Data plane
Bit #1 : L2, Management plane
Bit #2 : L3, IP protocol
Bit #3 : L3, TCP protocol
Bit #4 : L3, UDP protocol
Bit #7 - Bit #5 : Reserved
Octet 4 is reserved
21-05-0373-01-0000
SupportedEventList
4
refer to section 8.4.1.2, page 97
SupportedCommandList
4
refer to section 8.4.1.2, page 97
9