Issues for Bluetooth (GIOP Tunneling over) Finalization Task Force
To comment on any of these issues, send email to bluetooth-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 5994: Include GIOP over Bluetooth into Wireless CORBA 1.1
Issue 5994: Include GIOP over Bluetooth into Wireless CORBA 1.1 (bluetooth-ftf)
Click here for this issue's archive.
Source: Nokia (Dr. Kimmo Raatikainen, )
Nature: Revision
Severity:
Summary:
Include GIOP over Bluetooth into Wireless CORBA 1.1
Resolution: see below
Revised Text: 3.1 Issue 5994
Include GIOP over Bluetooth into Wireless CORBA 1.1
3.2 Resoultion Outline for Initial Voting
The initial resolution proposal by the chair of wCORBA RTF and GIOP BT tunneling FTF was:
We take relevant parts of GIOP Over Bluetooth Tunneling into Wireless CORBA 1.1 specification but keep GTP and MIOP versions as 1.0 since the only change needed in the IDL is one additional constant.
In the Telecom Wireless CORBA we have also one editorial change: Move annex B to Chapter 9 and rename it as Conformance. This was already in the FTF report (dtc/2002-09-14) but was not implemented in formal/03-03-64.
Below is a summary of changes to formal/03-03-64 due to resolution proposal:
1. 1.2 Proof of Concept: include Section 1.2 of dtc/03-05-06
2. 1.3 References: include references 2, 3, and 4 of dtc/03-05-06
3. 2.1 Key concepts (last para on page 2-2): add Bluetooth to the list of concrete tunneling protocols
4. 3.5 Additional Type Definitions (page 3-6): add 'const octet L2CAP_TUNNELING = 3;'
5. 7 GIOP Tunneling (first para on page 7-2): add Bluetooth to the list of concrete tunneling protocols
6. Create new section 7.6 Bluetooth Tunneling from material in dtc/03-05-06:
- first para on page 1-2 and figure 1-2
- first two paras on page 1-3
- first two paras on page 2-1
- section 2.2 as section 7.6.1
- section 2.2.1 as section 7.6.2
7. A.1 MobileTerminal.idl (page A-2) add 'const octet L2CAP_TUNNELING = 3;'
8. B.1.2 Access Bridge: add Bluetooth to the list of concrete tunneling protocols
9. B.1.3 Terminal Bridge: add Bluetooth to the list of concrete tunneling protocols
3.3 Final Resolution
To create Telecom Wireless CORBA Specification version 1.1 by incorporating relevant parts of the GIOP Tunneling Over Bluetooth Specification (dtc/2003-05-06) into Telecom Wireless CORBA Specification 1.0 (formal/2003-03-64) as detailed below.
3.3.1 Title page and running footers
Change specification version to 1.1 (Note GTP and MIOR versions remain 1.0. Second note: There is a typo in section 3.2.1 (page 3-3): In explanation text below the IDL 'minor_version' should be 'mior_version')
3.3.2 Section 1.2 Proof of Concept
include Section 1.2 of dtc/03-05-06 in section 1.2 of formal/2003-03-64.
3.3.2.1 Text in dtc/03-05-06: Section 1.2 Proof of Concept
This specification has been implemented in the EC/ITEA project Vivian [3] as an
extension to Wireless CORBA implementation, called MIWCO [4], by University of
Helsinki.
3.3.2.2 Revised text for Telecom Wireless CORBA 1.1 Specification: Section 1.2 Proof of Concept
The design is heavily affected by experiences of the EC/ACTS project DOLMEN
(AC036) that implemented a prototype of CORBA extensions to support terminal
mobility. The DOLMEN solution is described, for example, in the OMG Document
telecom/98-08-08.
This specification has been implemented by University of Helsinki as an Open Source
extension to the MICO Open Source ORB, called MIWCO [MIWCO].
The GIOP over Bluetooth Tunneling Specification has been implemented in the EC/ITEA project Vivian [VIVAN] as an extension to MIWCO.
3.3.3 Section 1.3 References
include references 2, 3, and 4 of dtc/03-05-06
3.3.3.1 Text in dtc/03-05-06: Section 1.3 References
[1] Wireless Access and Terminal Mobility in CORBA Specification.
(OMG Document dtc/2001-06-02 and dtc/2002-09-14), October 2002.
[2] Bluetooth SIG, Specification of the Bluetooth System - Version 1.1,
Volume 1 & 2. February 2001, Available: http://www.blue-tooth.
com/developer/specification/specification.asp.
[3] VIVIAN Consortium, GIOP Tunneling over Bluetooth L2CAP. Avail-able:
http://www-nrc.nokia.com/Vivian/Public/Html/ltp.html.
[4] MIWCO - An Open Source Implementation of Wireless CORBA. Avail-able:
http://www.cs.helsinki.fi/u/kraatika/wCORBA.html.
3.3.3.2 Revised text for Telecom Wireless CORBA 1.1 Specification: 1.3 References
[BT-SIG] Bluetooth SIG, Specification of the Bluetooth System - Version 1.1, Volume 1 & 2. February 2001, Available: http://www.blue-tooth.com/developer/specification/specification.asp.
[GFD] WAP Forum. WAP General Formats Document. WAP Forum document WAP-188-
WAPGenFormats, Version 15-Aug-2000.
[MIWCO] MIWCO - An Open Source Implementation of Wireless CORBA. Available: http://www.cs.helsinki.fi/u/kraatika/wCORBA.html.
[VIVIAN] VIVIAN Consortium, GIOP Tunneling over Bluetooth L2CAP. Available: http://www-nrc.nokia.com/Vivian/Public/Html/ltp.html.
[WDP] WAP Forum. Wireless Datagram Protocol Specification. WAP Forum
Document WAP-201-WDP, Approved Version 19-February-2000.
3.3.4 Section 2.1 Key concepts (last para on page 2-2)
add Bluetooth to the list of concrete tunneling protocols
3.3.4.1 Revised text for Telecom Wireless CORBA 1.1 Specification: Section 2.1 Key concepts (last para on page 2-2)
The GIOP tunnel is the means to transmit GIOP messages between the Terminal
Bridge and the Access Bridge. The generic GIOP Tunneling Protocol defines how
GIOP messages are transmitted. The protocol also specifies necessary control
messages to establish, release, and re-establish a GIOP tunnel. The proposed GIOP
Tunneling Protocol (GTP) is an abstract, transport-independent protocol. This response
defines three four concrete tunneling protocols, that is the way how GTP messages are
transmitted over TCP, UDP, and WAP WDP, and Bluetooth L2CAP.
3.3.5 Section 3.5 Additional Type Definitions (page 3-6)
add 'const octet L2CAP_TUNNELING = 3;'
3.3.5.1 Revised text for Telecom Wireless CORBA 1.1 Specification: Section 3.5 Additional Type Definitions (page 3-6)
const octet TCP_TUNNELING = 0;
const octet UDP_TUNNELING = 1;
const octet WAP_TUNNELING = 2;
const octet L2CAP_TUNNELING = 3;
struct AccessBridgeTransportAddress {
3.3.6 Section 7 GIOP Tunneling (first para on page 7-2)
add Bluetooth to the list of concrete tunneling protocols
3.3.6.1 Revised text for Telecom Wireless CORBA 1.1 Specification: Section 7 GIOP Tunneling (first para on page 7-2)
Since the GIOP Tunneling Protocol is an abstract protocol, it needs to be mapped onto
one or more concrete protocols. This specification defines three four concrete tunneling
protocols: TCP Tunneling, UDP Tunneling, and WAP Tunneling, and Bluetooth Tunneling.
3.3.7 New Section 7.6
Create new section 7.6 Bluetooth Tunneling from material in dtc/03-05-06:
- first para on page 1-2 and figure 1-2
- first two paras on page 1-3
- first two paras on page 2-1
- section 2.2 as section 7.6.1
- section 2.2.1 as section 7.6.2
3.3.7.1 Text extracted from dtc/03-05-06
Because the purpose of tunneling is just to deliver GIOP messages over wireless links,
tunneling should be done as low as possible in the Bluetooth stack (Figure 1-2) to have
minimum overhead.
<figure>
Figure 1-2 Bluetooth Protocol Stack [2]
Any Bluetooth profile, or even the RFCOMM protocol, is not appropriate because they
have many additional features that are not needed for tunneling. The Baseband
protocol through the Host Controller Interface (HCI) is not sufficient because it does
not support protocol multiplexing and de-multiplexing for upper layers. Therefore,
L2CAP is the most suitable protocol in the Bluetooth stack to be used in GIOP
Tunneling.
Since L2CAP is right above HCI, it has a low overhead but still provides protocol
multiplexing and de-multiplexing for upper layers. L2CAP provides connection-oriented
data services, a reliable channel and ordered delivery of messages using the
mechanisms available at the Baseband layer. It also provides notification of disorderly
connection lost. However, L2CAP have limits for packet size, so GTP message
segmentation and reassembly MUST be implemented in order to provide a possibility
to send messages of any size.
In Bluetooth Tunneling the GTP messages are transmitted using L2CAP Tunneling
Protocol (LTP) in the payload of L2CAP packets.
The transport end-point is given as a string: <BD_ADDR>#<PSM>, where
<BD_ADDR> is a unique 48-bit Bluetooth device address given in coloned
hexadecimal notation (e.g., 7F:00:00:01:05:B3) and <PSM> is protocol/service
multiplexer given as an unsigned integer in range 0...65535 (two octets).
2.2 LTP Tunneling Protocol
The L2CAP Tunneling Protocol (LTP) provides the reliability and ordered delivery of
messages assumed by the GIOP Tunneling Protocol. LTP assumes that is does not get
corrupted data.
LTP defines encapsulation of GTP messages. It also supports segmentation and
reassembly of GTP messages.
A LTP message is the payload of a L2CAP packet. One LTP message contains either
one GTP message or a fragment of one GTP message. The structure of a LTP message
is FLV: flags-length-value. The network byte order (that is Big-Endian) is always used
to express numeric values.
o The Flags field is one octet. It is used to denote fragmentation (segmentation).
o The Length field is 2 octets telling the length of the Value field in the network byte
order (that is Big-Endian).
o The Value field contains the LTP payload, that is one GTP message or a fragment of
a GTP message.
2.2.1 Fragmentation
The two rightmost bits of the Flags field is used to denote fragmentation of the Value
field:
o 0x00: middle segment
o 0x01: first segment
o 0x02: last segment
o 0x03: unfragmented message
3.3.7.2 Revised text for Telecom Wireless CORBA 1.1 Specification: Section 7.6 Bluetooth Tunneling
7.6 Bluetooth Tunneling
Because the purpose of tunneling is just to deliver GIOP messages over wireless links, tunneling should be done as low as possible in the Bluetooth stack (Figure 7-2) to have minimum overhead.
<figure 1.2 in dtc/03-05-06>
Figure 7-2 Bluetooth Protocol Stack [BT-SIG]
Any Bluetooth profile, or even the RFCOMM protocol, is not appropriate because they have many additional features that are not needed for tunneling. The Baseband protocol through the Host Controller Interface (HCI) is not sufficient because it does not support protocol multiplexing and de-multiplexing for upper layers. Therefore, L2CAP is the most suitable protocol in the Bluetooth stack to be used in GIOP Tunneling.
Since L2CAP is right above HCI, it has a low overhead but still provides protocol multiplexing and de-multiplexing for upper layers. L2CAP provides connection-oriented data services, a reliable channel and ordered delivery of messages using the mechanisms available at the Baseband layer. It also provides notification of disorderly connection lost. However, L2CAP have limits for packet size, so GTP message segmentation and reassembly MUST be implemented in order to provide a possibility to send messages of any size.
In Bluetooth Tunneling the GTP messages are transmitted using L2CAP Tunneling Protocol (LTP) in the payload of L2CAP packets.
The transport end-point is given as a string: <BD_ADDR>#<PSM>, where <BD_ADDR> is a unique 48-bit Bluetooth device address given in coloned hexadecimal notation (e.g., 7F:00:00:01:05:B3) and <PSM> is protocol/service multiplexer given as an unsigned integer in range 0...65535 (two octets).
7.6.1 LTP Tunneling Protocol
The L2CAP Tunneling Protocol (LTP) provides the reliability and ordered delivery of messages assumed by the GIOP Tunneling Protocol. LTP assumes that is does not get corrupted data.
LTP defines encapsulation of GTP messages. It also supports segmentation and reassembly of GTP messages.
A LTP message is the payload of a L2CAP packet. One LTP message contains either one GTP message or a fragment of one GTP message. The structure of a LTP message is FLV: flags-length-value. The network byte order (that is Big-Endian) is always used to express numeric values.
o The Flags field is one octet. It is used to denote fragmentation (segmentation).
o The Length field is 2 octets telling the length of the Value field in the network byte order (that is Big-Endian).
o The Value field contains the LTP payload, that is one GTP message or a fragment of a GTP message.
7.6.2 Fragmentation
The two rightmost bits of the Flags field is used to denote fragmentation of the Value field:
o 0x00: middle segment
o 0x01: first segment
o 0x02: last segment
o 0x03: unfragmented message
3.3.8 Section A.1 MobileTerminal.idl (page A-2)
add 'const octet L2CAP_TUNNELING = 3;'
3.3.8.1 Revised text for Telecom Wireless CORBA 1.1 Specification: Section A.1 MobileTerminal.idl (page A-2)
const octet TCP_TUNNELING = 0;
const octet UDP_TUNNELING = 1;
const octet WAP_TUNNELING = 2;
const octet L2CAP_TUNNELING = 3;
struct GTPInfo {
3.3.9 Section B.1.2 Access Bridge
add Bluetooth to the list of concrete tunneling protocols
3.3.9.1 Revised text for Telecom Wireless CORBA 1.1 Specification: Section B.1.2 Access Bridge
A product compliant to this specification must implement GIOP Tunneling Protocol
version 1.0 Level 1 and TCP, UDP, and/or WAP and/or Bluetooth Tunneling as described in Chapter 7.
3.3.10 Section B.1.3 Terminal Bridge
add Bluetooth to the list of concrete tunneling protocols
3.3.10.1 Revised text for Telecom Wireless CORBA 1.1 Specification: Section B.1.3 Terminal Bridge
A product compliant to this specification must implement GIOP Tunneling Protocol
version 1.0 Level 1 and TCP, UDP, and/or WAP, and/or Bluetooth Tunneling as described in Chapter 7.
3.4 Editorial Change
In the Telecom Wireless CORBA we have also one editorial change: Move annex B to Chapter 9 and rename it as Conformance. This was already in the FTF report (dtc/2002-09-14) but was not implemented in formal/03-03-64.
3.4.1 Editing instructions(copied from dtc/2002-09-14)
Change the title of Annex B to 'Conformance'.
Delete section titles B.1 and B.2.
Add the paragraph in the beginning of the chapter:
This specification has five conformance points: One for Home Location Agent and two for both Access Bridge and Terminal Bridge. The two conformance points for bridges correspond the levels of the GIOP Tunneling Protocol. The GTP Level indicates whether (Level 2) or not (Level 1) handoff is supported.
Change section B.1.1 to B.1 and keep the content as it is.
Introduction new section B.2 entitled "Access Bridge". Take current section B.1.2 as B.2.1 entitled "Level 1" and current section B.2.2 as B.2.2 entitled "Level 2".
Introduction new section B.3 entitled "Terminal Bridge". Take current section B.1.3 as B.3.1 entitled "Level 1" and current section B.2.3 as B.3.2 entitled "Level 2".
3.4.2 Extected outcome of editing
Conformance 9
This specification has five conformance points: One for Home Location Agent and two for both Access Bridge and Terminal Bridge. The two conformance points for bridges correspond the levels of the GIOP Tunneling Protocol. The GTP Level indicates whether (Level 2) or not (Level 1) handoff is supported.
All products compliant to this specification must support the Mobile IOR as specified in Chapter 3.
9.1 Home Location Agent
A product compliant to this specification must implement all operations specified in the HomeLocationAgent interface (see Chapter 4):
o update_location
o deregister_terminal
o query_location
o list_initial_services
o resolve_initial_reference
9.2 Access Bridge
9.2.1 Level 1
A product compliant to this specification must implement GIOP Tunneling Protocol version 1.0 Level 1 and TCP, UDP, WAP and/or Bluetooth Tunneling as described in Chapter 7.
The product must also implement the following operations specified in the AccessBridge interface (see Chapter 5):
o list_initial_services
o resolve_initial_reference
o terminal_attached
o get_address_info
The product must also act as a relay between an ORB server and an ORB client fulfilling the message processing requirements of Section 5.3, "Message Processing," on page 5-2.
9.2.2 Level 2
An Access Bridge may provide notifications of mobility related events through the NetworkMobilityChannel (Section 5.3, "Message Processing," on page 5-2) and support handoff.
An Access Bridge implementation supporting handoff MUST implement the GIOP Tunneling Protocol version 1.0 Level 2 (Chapter 7) as well as the handoff and access recovery procedures and the mechanisms to GTP messaging forwarding and terminal tracking as described in Chapter 8 for an Access Bridge in any of its possible roles.
The HandoffCallback interface and the following operations specified in the AccessBridge interface (Chapter 8) must be implemented:
o start_handoff
o transport_address_request
o handoff_completed
o handoff_in_progress
o recovery_request
o gtp_to_terminal
o gtp_from_terminal
o gtp_acknowledge
o handoff_notice
o subscribe_handoff_notice
9.3 Terminal Bridge
9.3.1 Level 1
A product compliant to this specification must implement GIOP Tunneling Protocol version 1.0 Level 1 and TCP, UDP, WAP and/or Bluetooth Tunneling as described in Chapter 7.
9.3.2 Level 2
A Terminal Bridge may provide notifications of mobility related events through the TerminalMobilityChannel (Section 6.1, "Mobility Event Notifications," on page 6-1) and support handoff.
A Terminal Bridge implementation supporting handoff MUST implement the GIOP Tunneling Protocol version 1.0 Level 2 (Chapter 7) as well as the handoff and access recovery procedures as described in Chapter 8 for the Terminal Bridge.
Actions taken:
July 14, 2003: received issue
July 14, 2003: re-assigned to the Bluetooth FTF
March 10, 2004: closed issue