Common ISDN Access Profile
The Common ISDN Access Profile defines provision of
ISDN services over Bluetooth in a way that allows application interfaces
to be implemented without loss of backward compatibility to existing
(legacy) ISDN applications based on the Common-ISDN-Application
Programming Interface (CAPI).
For more details : Download the CIP Profile from the Bluetooth.org
website.
The purpose of the Common ISDN Access Profile (CIP)
is:
- to define how applications shall access ISDN over Bluetooth;
- to allow wherever possible unrestricted access to services, data or
signaling provided by ISDN;
- to ensure that legacy ISDN applications do continue to work
without any modification inside that application itself;
- to define how the ISDN access co-exists with Bluetooth
Specifications and Profiles that possibly access ISDN in one way or
other;
- to show how ISDN over Bluetooth can co-exist with existing
ISDN in one application.
The Common ISDN Access Profile is dependent
only upon the Generic Access Profile
(GAP). The terminology, user interface and security aspects, modes
and procedures as defined in the GAP are applicable to this profile,
Image reprinted from Bluetooth CIP Profile, Figure
2.1 , page 13
This profile defines the requirements for each of
the layers in the protocol model above for the Common ISDN Access Profile.
The Baseband, LMP and L2CAP are the lower layer
Bluetooth protocols [1,2,3]. SDP is the Bluetooth Service Discovery
Protocol.
CMTP is the CAPI Message Transport Protocol, while
CAPI stands for Common ISDN Application Programming Interface. This is
publicly available from the CAPI Association e.V. under http://www.capi.org
This profile refers especially to Common ISDN Application Programming
Interface Part II, and PART IV Section 9.2.3.
- The CAPI Message Gateway (CMG) is an optional, functional
entity. Its presentation here only depicts the routing of the CAPI
Messages between the Bluetooth protocol stack and the ISDN protocol
stack with the OSI layer 1 to 3 for the ISDN B- and D-Channels. The
CMG is a manufacturer dependent piece of software and out of scope in
this profile.
- The CAPI Message Client (CMC) is an optional, functional
entity that routes CAPI Messages between the client CAPI Interface and
the Bluetooth protocol stack. The CMC is manufacturer dependent and
out of the scope of this profile.
The following roles are defined in this profile:
): The AP acts as a terminal endpoint from the
external network point of view and handles all interworking towards that
network. The AP is the central point with respect to external calls,
which means that it handles the D-Channel Protocol on the ISDN and
routes the signaling requests and indications via CAPI Messages to the
ISDN client. The AP shall accept more than one IC in parallel.
ISDN Client (IC): The IC is the client that accesses the AP
wireless and may offer CAPI to the user. The IC can for example be a
laptop, PC, handheld, cordless phone or otherwise.
A device may implement both roles if suitable for
its design.
Only one scenario has to be defined:
- Connecting to the AP so that CAPI Messages can be routed from and to
the IC.
This enables the IC to use all ISDN features defined
in Common ISDN Application Programming Interface like for instance:
telephony, HDLC (internet), X.75, facsimile, supplementary services.
The AP may be the master of the piconet in the
Common ISDN Access Profile. If the IC is not connected to an AP and wishes
to establish a connection it shall attempt to page a local AP.
An AP should devote as much of its free capacity as
possible (considering power limitations and ongoing signaling) to page
scanning in order to allow roaming ICs that enter the range of the AP to
find it as quickly as possible. This scheme minimizes radio traffic and
gives reasonable access time when the IC comes into range of the AP.
When an IC has successfully paged an AP, the AP may
request a master-slave switch. A connection-oriented L2CAP channel shall
be established and is used for all data transfer. Note: The
AP may defer a master slave switch request. As an example, in a single IC
environment this allows the IC to stay as master, so the IC can continue
to drive other Bluetooth devices.
For security purposes, mutual authentication of ICs
and AP shall be performed, and all data shall be encrypted.
The following text, together with the associated
sub-clauses, defines the feature requirements with regard to this profile.
Image reprinted from Bluetooth CIP Profile, Table
3.1 , page 16
As stated above, this profile requires compliance to
the Generic Access Profile. Section 4 of the actual Common ISDN Access
Profile defines the support requirements with regards to procedures and
capabilities defined in the Generic Access Profile. This shows
- the support status for modes within the support status for modes
within this profile
- the support status for security aspects within this profile.
- the support status for idle mode procedures within this profile.
Note: Bonding, The IC shall support
initiation of bonding, and the AP shall accept bonding.
See Section 5 of the actual Common ISDN Access
Profile for a table of all entries in the SDP database of the AP defined
by this profile.
In this profile, only connection-oriented channels
shall be used.
This section describes the usage of
configuration options in the Common ISDN Access Profile..
Maximum Transmission Unit (MTU)
- The maximum transmission unit (MTU) a L2CAP implementation uses for
this profile shall support at least 152 octets.
Flush Time-out
- The flush timeout value used for both the AP and the IC shall be the
default value of 0xFFFF.
Quality of Service
- CMTP does not rely on a guaranteed quality of service (QoS),
therefore the client shall set-up the connection with default QoS
values.
Due to the nature of the ISDN Client applications the optimum
bandwidth can be determined by the Access Point while connected. To
achieve optimal bandwidth usage, the Access Point should reconfigure
the QoS parameters of each connection dynamically, if necessary.
In this section, the LMP layer is discussed. Table
7.1 on the Common ISDN Access Profile , shows which LMP features are
mandatory to support with respect to this profile, which are optional and
which are excluded. The reason for excluding features is that they may
degrade operation of devices in this profile. Therefore, a unit active in
this profile shall never activate these features.
The AP may be the master of the piconet. The AP may
request a master-slave switch when an IC connects. If the IC rejects the
request, the AP shall detach it.
Consequently, an IC shall accept master-slave switch
requests of the AP, however, the AP may refuse a connection.
Only Combination keys shall be used for
authentication This also yields for the mutual authentication during the
pairing procedure or any change of the connection link key.
The encryption key size should be negotiated to 16
bytes (128 bits). If restricted by any regulation, a smaller key size
shall be accepted. The AP shall initiate encryption immediately after
successful authentication.
A device, which is active in the AP role of the Common
ISDN Access Profile may, in the Class of Device field:
- Indicate the value for ‘Phone’ as Major Device Class
- Indicate the value for ‘Common ISDN Access’ as Minor Device
Class
The device shall set the ‘Networking’ and
‘Telephony’ bits in the Service Class field. This may be used by an
inquiring device to filter the inquiry responses.
Inter-piconet capability is the
capability, as master, to keep the synchronization of a piconet while page
scanning in free slots and allowing for new members to join the piconet.
While a new unit is joining the piconet (until the master-slave switch has
been performed), operation may temporarily be degraded for the other
members.
The AP should be able to accept requests from other
clients and such may need limited inter-piconet capabilities. The case
that a piconet is full shall be handled by the application.
The CAPI Message Transport Protocol (CMTP) is used
to transfer Common ISDN Application Interface messages. The data is
transferred via L2CAP. The CAPI Messages itself are specified in the Common
ISDN Application Interface, which is publicly available from
the CAPI Association e.V. under http://www.capi.org
To achieve the use of maximum Bluetooth bandwidth it
is reasonable to concatenate several messages in one (L2CAP) data block.
For data delay reason it is sensible to transport the data as quickly as
possible. Therefore data should be sent immediately after reception from
the ISDN line. In case of a receive error the partly transferred blocks
can be discarded by setting an error value in the last part of the
message.
Besides concatenation of CAPI Messages as stated
above, CAPI Messages may be split over several CMTP messages. CMTP
messages shall not be split over multiple L2CAP packets.
Parts of different CAPI Messages may be interleaved
by using different CMTP Block IDs.
Image reprinted from Bluetooth CIP Profile, Figure
9.1 & 9.2 , page 24
A single CMTP message shall consist of at least a
message header, which shall be followed by the length field and the
payload body (see Figure below) as indicated in the header. The payload
shall transport the CAPI Message. For coding of the payload length Little
Endian format is used. The payload length shall be in the range of zero to
216 -1 Bytes (0..65535 Bytes). If there is no length field then
the payload length is 0.
As indicated in the table below. the CAPI Block ID
shall be used to identify the segmented parts of CAPI Messages if CAPI
Messages are interleaved. Adjacent, non interleaved CAPI Messages may use
the same CAPI block ID. Up to 16 segmented not yet completed CAPI Messages
may be outstanding.
Image reprinted from Bluetooth CIP Profile, Figure
9.3 , page 25
Note , the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth
Specification.
|
