|
This profile defines the features and
procedures that are required for interoperability between different units
active in the ‘3-in-1 phone’ use case.The ‘3-in-1 phone’ is a
solution for providing an extra mode of operation to cellular phones,
using Bluetooth as a short-range bearer for accessing fixed network
telephony services via a base station.
However, the 3-in-1 phone use case can also be
applied generally for wireless telephony in a residential or small office
environment, for example for cordless-only telephony or cordless telephony
services in a PC – hence the profile name ‘Cordless Telephony’.
For more details : Download the K3
Specification from the SIG website, or visit the Documents
Page.
Two roles are defined for this profile:
Gateway (GW) – The GW acts as a terminal
endpoint from the external network point of view and handles all
interworking towards that network. The GW is the central point with
respect to external calls, which means that it handles all call set-up
requests to/from the external network. Examples of devices that can act as
a gateway include a PSTN home base station, an ISDN home base station, a
GSM gateway, a satellite gateway and an H.323 gateway.
Terminal (TL) – The TL is the wireless user
terminal, which may for example be a cordless telephone, a dual-mode
cellular/cordless phone or a PC. Note that the scope of this profile with
respect to a dual-mode cellular/cordless phone acting as TL is only the
cordless mode.
The Cordless Telephony profile supports a topology
of one gateway (GW) and a small number (.... 7) of terminals (TLs)
The following scenarios are covered by this profile:
- Connecting to the gateway so that incoming calls can be routed to
the TL and outgoing calls can be originated.
- Making a call from a TL to a user on the network that the gateway is
connected to.
- Receiving a call from the network that the gateway is connected to.
- Making direct calls between two terminals.
- Using supplementary services provided by the external network by
means of DTMF signalling and register recall (hook flash).
The GW is normally the master of the piconet in the
Cordless Telephony profile. As master, the GW will control the power mode
of the TLs and may broadcast information to the TLs.
A TL that is out of range of a GW searches for it by
periodically trying to page it. A GW shall devote as much of its free
capacity as possible (considering power limitations and ongoing
signalling) to page scanning in order to allow roaming TLs that enter the
range of the GW to find it as quickly as possible. This scheme minimises
‘air pollution’ and gives reasonable access time when coming into
range of the GW. When a TL has successfully paged a GW, a master-slave
switch shall be performed since the GW shall be the master. A
connection-oriented L2CAP channel and, possibly, a L2CAP connectionless
channel are established to be used for all TCS signalling during that
Cordless Telephony session.
A TL that is within range of a GW shall normally be
in park mode when it is not engaged in calls. This mode is
power-efficient, allows for reasonable call set-up times and allows
broadcasting to the attached TLs.
Upon arrival of an incoming call, or when a TL wants
to make an outgoing call, the GW shall be put in active mode. The L2CAP
channels (see above) are used for all TCS control signalling. Voice is
transported using SCO links.
For security purposes, authentication of TLs and GW
is used, and all user data is encrypted. To facilitate secure
communication between cordless units, the WUG concept (see TCS Binary,
Section 3) is used. The GW always acts as WUG master.
There are several definitions in this profile which
warrant further explanation
- Calling line identification presentation (CLIP) – The
ability to provide the calling party number to the called party before
accepting the call.
- Call information – The ability to provide additional
information during the active phase of a call.
- Connection Management – The ability to accept and (TLs
only) request connections for the purposes of TCS-Bin procedures.
- DTMF signalling – The ability, in external calls, to send a
DTMF signal over the external network to the other party.
- Incoming external call – A call originating from the
external network connected to the GW.
- Initialization – The infrequent process whereby a TL
receives access rights to a certain GW.
- Intercom call – A call originating from a TL towards
another TL.
- In the GW, the ability to handle multiple active terminals being
registered at the same time
- In the TL, the support for a Wireless User Group (WUG)
- On hook – The ability to indicate the action of going
on-hook (e.g. to terminate a call), and release of all radio resources
related to that call.
- Outgoing external call – A call originated by a TL towards
the external network connected to the GW.
- Post-dialling – The ability to send dialling information
after the outgoing call request set-up message is sent.
- Register recall – The ability of the TL to request ‘register
recall’, and of the GW to transmit the request to the local network.
Register recall means to seize a register (with dial tone) to permit
input of further digits or other actions. In some markets, this is
referred to as ‘hook flash’.
When conformance to this profile is claimed, all
capabilities indicated mandatory for this profile shall be supported in
the specified manner (process-mandatory). This also applies for all
optional and conditional capabilities for which support is indicated. All
mandatory capabilities and optional and conditional capabilities, for
which support is indicated, are subject to verification as part of the
Bluetooth certification program.
Note that the Intercom Profile
is used for intercom calls. This means that a TL claiming conformance to
the Cordless Telephony profile must conform to Intercom
Profile.
When describing TCS Binary procedures, this chapter
provides additional information concerning lower layer handling.
Connecting to a GW - When a TL connects to
the GW, the link is configured and the L2CAP connection that is used for
further signalling during that TCS-BIN session is set up and configured.
The TL which is connecting is responsible for setting up the
connection-oriented L2CAP channel. Only trusted TLs are allowed to connect
to the GW.
Connecting to another TL - In the case of an
intercom call, the TL which initiates the call establishes a direct link
to the other TL. See the Intercom Profile for a description of these
procedures.
If the TL has the capability to participate in two
piconets at the same time, the TL may remain a member of the GW piconet
and participate in signalling towards the GW during the intercom call. If
the TL does not have the capability to participate in two piconets at the
same time, it must detach from the GW while the intercom call is active.
After the intercom call is finished, the TL must re-establish the
connection to the GW.
Call control procedures are defined in Section 2.2 of TCS
Binary, except for the following which require some changes/additions
Sides - In an outgoing external call, the TL
is the outgoing side and the GW is the incoming side. In an incoming
external call, the TL which terminates the call is the incoming side and
the GW is the outgoing side.
Call Class - An external call is
a call between a TL and a third party connected via an external network
(PSTN, ISDN, GSM or other). The call class used in SETUP messages for
external calls (outgoing and incoming) is ‘external call’. An intercom
call is a call between two TLs, which may be setup with GW support
if the two TLs are members of the same WUG. .
Call Confirmation - If the call is an
incoming external call, and the SETUP message was delivered on a
connection-oriented channel, the incoming side must acknowledge the SETUP
message by performing the call confirmation procedure.
Call Connection - This procedure shall be
performed as defined in TCS Binary. The following text defines the
mandatory requirements with regard to this profile.
- If the bearer capability for this call is ‘Synchronous
Connection-Oriented’, the SCO link establishment sub-procedure shall
be initiated before sending a CONNECT.
- If the bearer capability for this call is ‘Synchronous
Connection-Oriented’, the audio path shall be connected to by a unit
when it receives a CONNECT or CONNECT ACKNOWLEDGE.
In-band Tones & Announcements - Only the
GW may provide in-band tones and announcements. The SCO link establishment
sub-procedure (see Link Manager Protocol, Section 3.21) is initiated
before sending a Progress Indicator information element #8, "In-band
information or appropriate pattern is now available".
Call Clearing - This section describes how
the lower layers are used to release circuit switched (SCO) connections.
- A unit shall release the SCO link by invoking the appropriate LMP
sub-procedure when a unit has received a RELEASE message.
- A unit shall release the SCO link (if not already released) by
invoking the appropriate LMP sub-procedure when it has received a
RELEASE COMPLETE message.
Supplementary services can be either internal
services within the WUG, or external services provided by the network the
GW is connected to. The exact set of external supplementary services is
not defined in this profile and is dependent on the network the GW is
connected to. This profile provides the means for accessing them.
DTMF Signalling - The capability to request
DTMF signalling towards the external network is mandatory for the TL. The
capability to accept DTMF signalling requests is mandatory for the GW.
Calling Line Identity - It is recommended
that all GWs that are connected to networks that provide calling line
identity have the capability to provide this information to the user.
Obtain Access Rights - A TL which wants to
become member of a WUG may initiate this procedure towards a GW. The GW
may accept or reject the request depending, for example, on configuration,
or if the user has physical access to the base. A GW which accepts the
access rights request shall add the TL to the WUG and initiate the
Configuration distribution procedure.
Configuration Distribution - Because of the
security implications of this procedure, a TL is not forced to store the
key information received during this procedure. In addition, GW may always
reject the ACCESS RIGHTS REQUEST from a TL because of
implementation-dependent reasons. For example, the user may be required to
press a button on the GW before being granted access to the group.
Note that for intercom calls, two TLs that are
members of the WUG do not need to perform the initialization procedure
described in the Intercom profile (see Intercom
Profile) if they use the keys distributed in the Configuration
distribution procedure.
A TL which stores link keys during the Configuration
Distribution procedure shall never overwrite existing link keys to other
WUG members. Only if there was previously no link key to a specific device
shall the key obtained during the Configuration Distribution procedure be
used.
Fast Inter-Member Access - The Fast
inter-member access procedure is used when two TLs that are members of the
same WUG need to establish a piconet of their own. This may be needed when
an intercom call shall be established. Refer to TCS Binary for a
definition of the procedure.
The TLT or TLI may detach from the GW after having sent the
LISTEN ACCEPT message by terminating the L2CAP channel to the GW and
sending a LMP_detach.
If a unit in a CC state other than Null detects
loss of link, it shall immediately go to the Null state. Call
clearing procedures shall in this case not be performed.
In this profile, both connection-oriented channels
and connectionless channels are used. Connectionless channels are used to
broadcast information from the GW to the TLs. Only the GW shall use
connectionless channels for sending.
In this profile, only the TL may initiate the
establishment of connection-oriented channels. When connecting to the GW,
the TL shall use the value 0x0007 (TCS-BIN-CORDLESS) in the PSM field of
the Connection Request packet.For PSM usage in intercom calls, see
Intercom Profile.
In this profile, only connection-oriented channels
are used. In the PSM field of the Connection Request packet, the default
value for TCS-BIN, 0x0005 shall be used.
- Maximum Transmission unit -The minimum MTU that a L2CAP
implementation used for this profile should support is 171 octets.This
means that the maximum number of TLs supported by this profile is 7.
- Flush timeout option - The flush timeout value used for both the GW
and the TL shall be the default value of 0xFFFF.
- Quality of Service - Negotiation of Quality of Service is optional.
A GW supporting feature 7, ‘Multi-terminal support’,
must always be the master of the piconet. Such a GW will request a
master-slave switch when a TL connects. If the TL rejects the request, the
GW may detach it. Thus, a TL which does not accept master-slave switch
requests can not be guaranteed service by all GWs.
The GW shall be as conservative as possible when
deciding what power mode to put the TLs in. This means that when a TL is
not engaged in signalling, the GW shall put it in a low-power mode. The
recommended low-power mode to use is the park mode.
If the GW can save power during a call, it may use
the sniff mode. A TL may request to be put in the sniff mode.
A device which is active in the GW role of the
Cordless Telephony profile shall, in the Class of Device field:
- Set the ‘Telephony’ bit in the Service Class field
- Indicate ‘Phone’ as Major Device class
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.
A GW which supports feature 7, ‘Multiple terminal
support’, shall have inter-piconet capabilities. The TL may have
inter-piconet capabilities.
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.
|
