In a continuation from the Cordless Telephony Profile, Chapter 4, the The Intercom Profile provides the usage model, where two terminals (TLs) may communicate with one another, fulfilling a direct communication link. This new usage model accommodates general wireless telephony, enabling Bluetooth solutions within the home or office environment. Bluetooth-enabled cordless handsets and multimedia PCs are all capable of supporting intercom functionality. This also extends the functionality already offered within a mobile phone, where short-range communication can be supported, allowing the mobile phone to access another mobile phone or cordless handset; Figure 5-1 and Figure 5-2 illustrate the usage models supported by this profile.
Figure 5-1. A one-to-one intercom connection is sustained by two cordless handsets in this illustration.
Figure 5-2. A one-to-one intercom connection is also sustained by a cordless handset and a mobile phone that supports the Intercom Profile.
The Intercom Profile is supported by devices that form part of the 3-in-1 usage model, as described in the Cordless Telephony Profile. Essentially, where a direct speech link is required, the Intercom profile is used to establish that direct one-to-one connection. This profile, as with the Cordless Telephony Profile, is dependent upon the TCS implementation. The Bluetooth Telephone Control Protocol Specification or the TCSBinary (TCS-BIN), further shortened to TCS, is discussed in detail in our previous chapter.
This section considers our existing usage model through scenarios that may be typical for the Intercom Profile. The scenario provided in Figure 5-1 and Figure 5-2 represent our existing usage model. In the illustrations, a mobile phone or cordless handset is shown. The role of the cordless handset is to establish a one-to-one communications link with another cordless handset. With this capability inherent in a cordless handset, it falls within the category described as the 3-in-1 usage scenario, which we introduced in the Cordless Telephony Profile. The Intercom usage model prescribes short-range communication typically found in a small office environment and can equally be mapped onto other similar environments, where such examples include a door entry system and an intercom system for the care of patients in a hospital.
The Intercom Profile does not necessarily define any new roles, although participating devices that support this profile are generally described as a Terminal (TL), where such devices may be a cordless handset, mobile phone or a multimedia PC. In Figure 5-3, we can see how the Intercom components are integrated within the existing Bluetooth protocol stack.
Figure 5-3. The core components of the Bluetooth protocol stack are shown, illustrating how the components of the Intercom Profile are integrated.
The profile defines a set of protocols and procedures that are required to realise the profile implementation. Several feature definitions are provided that enable Call Information, Intercom Call and On Hook capabilities. We will discuss these and other features later.
There are no fixed master-slave roles. This allows either device free to initiate and/or terminate a connection. The user may determine whether authentication and/or encryption should be used between the two devices; however, if it is used, then the procedures as described for authentication and encryption in the Generic Access Profile, Chapter 2 must be adhered to.
In Table 5-1, clarification is provided with regard to the roles used within the context of this profile. In general, DeviceA represents the initiating party and DeviceB represents the accepting party. The terms are often used interchangeably when describing specific operations in various contexts and are provided here for reference.
The Intercom Profile is dependent upon the underlying profiles, where Connection Establishment procedures are applicable and are illustrated in the Generic Access Profile, Chapter 2. The connection establishment procedures encompass the availability of an initialised and configured L2CAP connection. If the device is in park mode, then it is unparked prior to any creation of a Synchronous Connection-Orientated (SCO) connection; if no previous session exists, then one is created and the device may request parked status. Therefore, it is assumed that the TL devices have previously performed an inquiry, discovery and any authentication and/or encryption.
Table 5-1. The list of behavioural characteristics that are typical for this profile.
|
CONFIGURATION |
ROLE |
DESCRIPTION |
|---|---|---|
|
DeviceA |
TL |
A device acting as a terminal, which may take the form of a mobile phone or cordless handset. In this particular context, the device is described as initiating the connection with the accepting device. |
|
Initiator |
This configuration describes the device that instigates the original connection or the device that wishes to initiate communication over an existing link. | |
|
DeviceB |
TL |
A device acting as a terminal, which may take the form of a mobile phone or cordless handset. In this particular context, the device is described as accepting the connection with the initiating device. |
|
Acceptor |
This configuration describes the process of the device accepting the initiated communication from DeviceA. |
An incoming call from another TL will generate an audible alert, notifying the user of an incoming connection; Calling Line Identification Presentation (CLIP) may be used to identify the incoming caller if the TL supports it. The user may now accept or reject the call by operating the buttons available on the cordless handset. With a multimedia PC, specific software for the intercom application may be used to accept or reject the caller by operating a menu-driven user interface.
A user may initiate an outgoing call by operating the buttons available on the cordless handset. If a TL loses the connection with its peer, as a result of moving out of radio range, then the TL will attempt to re-establish the original connection by regularly paging the TL device.
Now that we have explored various aspects of existing usage models and their respective user expectations, let’s take an opportunity to explore in greater depth the dependencies that make up this profile. In Figure 5-5, we provide a conceptual illustration representing the dependencies that make up the Intercom Profile; the areas that are shaded are relevant to this profile. As you can see, the profile depends upon the basic functionality offered to us by the Generic Access Profile, Chapter 2, the Service Discovery Application Profile, Chapter 3 and the Telephony Control Protocol. We will now discuss, in turn, the basic requirements of these dependent components and any deviations that may occur from the basic functionality originally offered to us.
Figure 5-5. The dependent components of the Bluetooth protocol stack that make up the Intercom Profile. The areas that are shaded are relevant to this profile.
The Intercom Profile is one of the profiles that relies upon the capabilities provided by the Generic Access Profile, Chapter 2. You may recall that a level of basic functionality is achieved through establishing a set of rules and procedures. These specifically relate to a device’s connectivity, discoverability and common characteristics at the user interface level, with some additional emphasis provided for security. Furthermore, it is these rules and procedures that are used to establish commonality between products, which will ultimately achieve a cohesive user experience.
In Table 5-2, the basic set of procedures is illustrated identifying functional expectations, which in turn govern its operation. These procedures help determine the context that the device would operate in; for example, a device may wish to be discoverable for a period of time or it may require a level of security that differs from one device to another depending upon the services its capable of offering.
Table 5-2. The core set of procedures as required by most profiles.
|
PROCEDURES |
DESCRIPTION |
|---|---|
|
Discoverability Mode |
This mode prescribes the overall discoverability of a device, allowing it to be placed into a non-discoverable, limited or general discoverable mode. The mode would allow devices to become generally available to other users or it can be restricted to personal use. |
|
Connectability Mode |
When determining a baseband connectable state, this mode is used to place a device into a connectable or non-connectable mode. |
|
Pairing |
Pairable and non-pairable modes are used to realise the security aspects when operating or intending to use a device. A device may require authentication and, as such, the user would be required to enter a Bluetooth Passkey. The pairing procedure starts the link key generation process, which in turn allows authentication to take place. |
In Table 5-3, we consider the specific set of operations that are required for this profile. In the table, features are marked with M (Mandatory), O (Optional), X (Excluded), C (Conditional) and N/A (Not Applicable); these determine what is expected from the features of the Generic Access Profile. The Intercom Profile requires mandatory support for pairable mode if bonding is supported; bonding is initially offered as optional, see Table 5-5.
Table 5-4 identifies the security requirements for this profile. You may remember from the Generic Access Profile, Chapter 2, that Security Mode 1, is a non-secure mode where Bluetooth-enabled devices will never initiate any security procedures; whereas, Security Modes 2 and 3, initiate different levels of security procedures at various stages of connection establishment. In this instance, if authentication is provided, then support should be provided for at least Security Modes 2 or 3.
In our final consideration of the basic rules and procedures that are required from the Generic Access Profile, the idle mode procedures outline behavioural characteristics when DeviceA chooses to initiate them against DeviceB. The procedures that are listed in Table 5-5 provide a clear indication of how a device should operate when performing such an activity.
What we realise here is that there are a specific set of events associated with a procedure and in the Generic Access Profile, Chapter 2, we provide an exhaustive presentation and examine how each procedure is conducted.
The mechanism for providing device discoverability is the provision of a well-structured FHS packet, which is shown in Figure 5-6. This packet is used to identify the remote device, where information such as Bluetooth Device Address (BD_ADDR) and clock offsets is determined. You may also notice from this packet that the Class of Device (CoD) field is also provided. This information is relayed to the user interface, which in turn provides common characteristics about discovered devices. The CoD is used during the discovery mechanism to learn more about the type of device and what it may be capable of providing. This structure of information is depicted in Figure 5-7 and is made up of 3-bytes (or 24-bits as shown). The following sections consider the Intercom attributes, which will ultimately make use of the Service, Major and Minor Device Class fields.
Figure 5-6. The structure of the FHS packet used only for reference to illustrate the position of the Class of Device structure.
Figure 5-7. The structure of the class of device, illustrating the Minor Device, Major Device and Service Class fields and their respective lengths.
Table 5-3. The illustration shows specific modes of operation that this profile depends upon to realise its compliant implementation.
|
MODES |
TL |
|---|---|
|
Non-discoverable |
M |
|
Limited Discoverable |
O |
|
General Discoverable |
M |
|
Non-connectable |
N/A |
|
Connectable |
M |
|
Non-pairable |
O |
|
Pairable |
C |
Table 5-4. The illustration shows specific security procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
TL |
|---|---|
|
Authentication |
C |
|
Security Mode 1 |
O |
|
Security Mode 2 |
C |
|
Security Mode 3 |
C |
Table 5-5. The illustration shows specific behavioural procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
TL |
|---|---|
|
General Inquiry |
M |
|
Limited Inquiry |
O |
|
Name Discovery |
O |
|
Device Discovery |
O |
|
Bonding |
O |
This high-level form of defining a Bluetooth device identifies where in the Service Class field the Intercom Profile resides; see Table 5-6, which in turn determines the category of service; here, the category of service falls within Telephony.
This high-level form of defining a Bluetooth device identifies where in the Major Device Class the Intercom Profile resides; see Table 5-7, which in turn determines the major class grouping. Here, the category falls within phone, since a cordless handset or mobile phone may be used.
The Minor Device Class in this profile is used to convey further context for the setting within the major class grouping, see Table 5-8. Here the bit may be set appropriately for Cordless to denote the type of service available to the user.
In the Service Discovery Application Profile, Chapter 3, we introduced the characteristics of the mechanisms used to retrieve service information from a remote device. Typically, a client will initiate inquiry and discovery procedures, as outlined in our previous section, to learn of the devices in radio range. A client will then make use of an application, which embodies the functionality of the underlying Service Discovery Protocol (SDP). The Service Discovery Application (SrvDscApp) uses an SDP Client to instigate a request to the remote device where the SDP Server will respond; as such, both TLs must employ the use of an SDP client and server, as illustrated in Table 5-9.
Table 5-6. The Service Class categorisation for the Intercom Profile.
|
SERVICE CLASS | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
23 |
22 |
21 |
20 |
19 |
18 |
17 |
16 |
15 |
14 |
13 |
Bit # of CoD |
|
0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Telephony |
Table 5-7. The Major Device Class for the Intercom Profile.
|
MAJOR DEVICE CLASS | |||||
|---|---|---|---|---|---|
|
12 |
11 |
10 |
9 |
8 |
Bit # of CoD |
|
0 |
0 |
0 |
1 |
0 |
Phone |
Table 5-8. The Minor Device Class for the Intercom Profile.
|
MINOR DEVICE CLASS | ||||||
|---|---|---|---|---|---|---|
|
7 |
6 |
5 |
4 |
3 |
2 |
Bit # of CoD |
|
0 |
0 |
0 |
0 |
1 |
0 |
Cordless |
Table 5-9. As a minimum, the local device must support the use of a client application and the remote device must support the use of a server.
|
FEATURE |
TL |
TL |
|---|---|---|
|
SDP Client |
M |
X |
|
SDP Server |
X |
M |
Table 5-10. The list of PDUs that are required for the operation of the Intercom Profile.
|
PDU |
TL |
TL |
|---|---|---|
|
|
X |
M |
|
|
M |
X |
|
|
X |
M |
|
|
M |
X |
|
|
X |
M |
|
|
O |
X |
|
|
X |
O |
Protocol Data Units (PDUs) are used to instruct the SDP server to undertake browsing procedures and to retrieve service record information about its services; you may recall that these PDUs carry payloads about requests containing AttributeIDs and AttributeValues describing what exactly is being sought. As we previously discussed, the client and server operate a request and response paradigm. SDAP will construct PDUs containing information relating to the AttributeID and AttributeValues, in turn instructing the server to carry out its operation. The various request and response PDUs that are required are shown Table 5-10.
A service record is maintained for each service a device is capable of supporting and, as such, a Service Record Handle is created to uniquely identify this. The ServiceRecordHandle is a 32-bit unsigned integer and is stored on the SDP server. The service record shown in Table 5-11 identifies a TL device and provides a list of AttributeIDs, which ultimately would identify the service for the Intercom Profile. A minimum of two AttributeIDs are required to make a service record; these are ServiceRecordHandle and ServiceClassIDList, where it must contain at least one UUID.
When browsing for services on the remote device, a local device constructs a search pattern using a Universally Unique Identifier (UUID). A UUID is a 128-bit value, which has been shortened for use within Bluetooth applications. The shortcut has been provided by first establishing a Bluetooth Base UUID, which we discussed in the Service Discovery Application Profile, Chapter 3.
The UUIDs that have been presented so far are aliases and take the form of what is referred to as a 16-bit UUID or a 32-bit UUID—but, in turn, they all should refer to the 128-bit notation. These UUIDs have been assigned and can be referenced in the Bluetooth Special Interest Group, Bluetooth Assigned Numbers, v1.1, February 2001. For the search pattern to be successful, they all need to be converted to the 128-bit notation, since they will all be compared at this range. An arithmetic conversion algorithm is used to construct the 128-bit value.
Table 5-11. The list of mandatory and configurable items that make up this profile’s service discovery record.
|
ATTRIBUTE |
DESCRIPTION |
|---|---|
|
|
With an |
ServiceClassIDList ServiceClass0 ServiceClass1 |
With an |
ProtocolDescriptorList Protocol0 Protocol1 |
With an |
BluetoothProfile
DescriptorList
Profile0
ParameterFor0 |
With an |
|
|
With a base |
Table 5-12 summarises the service class UUIDs used to identify the particular profile in use; this also correlates with the identification of the device during a device discovery procedure as previously outlined in Section 5.5.1.1, Generic Access.
As part of the service record, the dependent underlying protocols are also identified. The local device retrieves this information, where it can fully understand the exact requirements needed to fulfil the service. The Intercom Profile is dependent on the protocols as shown in Table 5-13, which shows their associated UUID values.
In the Cordless Telephony Profile, Chapter 4 we leaned about how signalling messages are created and subsequently constructed to provide us with a telephony service. The extent of the services are governed by the Call Control entity and in the following section, we consider its objectives and expectations in the profile.
Table 5-12. The list of service classes that match a corresponding profile. This correlates with our previous Generic Access section.
|
CLASSES |
UUID |
|---|---|
|
|
|
|
|
|
The primary responsibility of the CC entity is to coordinate the connection and disconnection of speech and data calls between two participating TLs. In Table 5-14, we illustrate the set of Call Control procedures that are required to achieve a compliant Intercom Profile.
The L2CAP layer provides transparency for the upper layers of the stack from the layers typically found within the host controller. L2CAP payloads are passed to the Host Controller Interface [1] (HCI), which is then subsequently passed onto the Link Manager Protocol (LMP). The range of upper layers, which include RFCOMM, Service Discovery Protocol (SDP) and TCS all make use of the capabilities offered to us by L2CAP. Its primary role is to provide protocol multiplexing, allowing numerous simultaneous connections to be made, and to also provide the ability for segmentation and reassembly. This refers to the ability to manage large payloads in the application, which may need to be fragmented into smaller payloads for the lower layers to manage; these are then transmitted over the air-interface. Finally, the L2CAP layer exchanges Quality of Service (QoS) information, ensuring that sufficient resources are available and that both Bluetooth devices are attaining the best service.
In Table 5-15, we summarise the broad capabilities that are expected from L2CAP. In the table, you will notice features are marked appropriately and will determine what is expected from the L2CAP layer.
Table 5-13. The list of protocols that are used in this profile; their associated UUID values are also shown.
|
PROTOCOL |
UUID |
|---|---|
|
|
|
|
|
|
Table 5-14. The illustration shows specific Call Control procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
TL |
|---|---|
|
Call Request |
M |
|
Call Confirmation |
M |
|
Call Connection |
M |
|
Failure of Call Establishment |
M |
|
Call Clearing |
M |
|
Call Information |
M |
In Table 5-15, we have identified that Connection-orientated Channels are mandatory, whereas Connectionless Channels are excluded; this type of channel is aimed at broadcasting, where all devices may be targeted. L2CAP uses PDUs to transport connection, signalling and configuration options, which will be discussed below. The higher layers of the Bluetooth protocol stack will instigate a connection with L2CAP using the L2CA_ConnectReq request packet, where the corresponding result is contained within the L2CA_ConnectRsp response packet.
Table 5-15. The illustration shows specific procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
TL |
|---|---|
|
Connection-orientated Channel |
M |
|
Connectionless Channel |
X |
|
Connection Establishment |
M |
|
Configuration |
M |
|
Connection Termination |
M |
|
Echo |
M |
|
Command Rejection |
M |
|
Maximum Transmission Unit |
M |
|
Flush Timeout |
M |
|
Quality of Service |
O |
Table 5-16. The range of prototypes used to illustrate how L2CAP is architected and how interaction between higher and lower layers is achieved. For this discussion, our concern here is with the higher-layer.
|
PROTOTYPE |
DESCRIPTION |
|---|---|
|
|
This prefix prototype is used to denote the higher-layer interaction, typically used by RFCOMM, SDP and TCS |
|
|
This prefix is used to denote peer-to-peer signalling interaction of L2CAP entities. |
|
|
Finally, this prefix denotes lower-layer interaction, where L2CAP interfaces with the LMP layer. |
An L2CA_ConnectRspNeg negative response packet is used to denote a response, where the connection with the remote device was unsuccessful. Since our profile resides above L2CAP and employs its services, we are only concerned with the upper protocol layer of L2CAP. This higher functionality is offered to us through a series of L2CAP events and is denoted through the prefix L2CA_; see Table 5-16.
When creating an L2CAP connection between two devices, a Protocol/Service Multiplexor (PSM) value is used to denote the higher-layer protocol that is using the connection; Table 5-17 identifies these values and the corresponding protocols they represent. The value of 0x0005 (TCS-BIN) is used for this profile.
When establishing communication with a remote device, a signalling channel is created and reserved for use during connection, disconnection and configuration of subsequent L2CAP connections. A channel is used to describe the communication and data flow that exists between L2CAP entities and Table 5-18 illustrates the range of Channel Identifies (CIDs) that are used to identify the channel type. As we can see in Table 5-15, Connection Establishment and Termination is mandatory in the local device, although the remote device may be capable of initiating and terminating a connection to the local device. The L2CA_DisconnectReq request packet is used to terminate the connection with the remote device and an L2CA_DisconnectRsp response packet is used to ascertain the result of the termination—although all disconnection requests must be completed successfully. The support of Configuration is shown as mandatory and we will discuss these specific options in more detail in the following section. Finally, Echo and Command Rejection are both mandatory for a compliant Intercom Profile.
In establishing a connection with the remote device, the channel is subject to configuration and the higher-layer prototype L2CA_ ConfigReq request packet is used to carry configuration requests. Its associated response is contained within the L2CA_ConfigRsp packet; an L2CA_ConfigRspNeg packet is used to denote a negative response during configuration, where for example the suggested Maximum Transmission Unit (MTU) is too large. In Table 5-15, we have identified that the MTU and Flush Timeout parameters are mandatory, whereas the QoS is optional.
The default MTU setting for the signalling channel is 48 bytes, whereas other channels may be capable of transferring larger payloads; essentially, the MTU determines the size of payloads that are capable of being exchanged between two devices. The Intercom Profile requires that a minimum MTU of 3 bytes should be established to allow support for multiple TLs. During configuration, the local device will inform the remote device that it is potentially capable of accepting larger payloads. If the remote device is unwilling to accept a larger MTU, then the local device is informed with the response contained within the L2CA_ConfigRspNeg packet.
When L2CA_ request and response packets are being exchanged, the Flush Timeout parameter is used to determine how long the local device is prepared to continue to transmit an L2CAP fragment before it gives up; the packet is subsequently flushed (that is, discarded). The suggested Flush Timeout value is sent during the L2CA_ConfigReq request packet. However, if no value is set, then the default value is used. The Intercom Profile uses the default value of 0xFFFF.
As we have already mentioned, the QoS configuration is optional, but if it is used during an L2CA_ConfigReq request, then the best effort service is established as a default; the available services that are supported by an L2CAP channel are shown in Table 5-19. However, if the QoS service is set at Guaranteed, then parameters such Token Rate, Token Bucket, Peak Bandwidth, Latency and Delay Variation, are used to determine an acceptable guaranteed service, where the L2CA_ConnectRspNeg will indicate that these values are unacceptable. These parameters are then subject to further negotiation.
The Link Manager (LM) layer sits between the HCI and the Link Controller (LC), although on a hostless system the LM will have direct interaction with L2CAP. It accepts commands from HCI and translates them into operations for the LC, where Asynchronous Connectionless (ACL) and SCO links are created and established. It is during this stage of ACL and SCO establishment that a master-slave switch would be performed as governed by the requirements of this profile. The LM is also responsible for placing the device into a low-power mode, which includes hold, sniff and park.
In providing general error management, devices that operate mandatory procedures during interoperability must either acknowledge their support or provide a reason for procedure failure. The LMP_Detach PDU is used to inform the device of the error that occurred; typically, unsupported LMP feature (0x1A) is reported when an error occurs (see Appendix A).
Next, we take an opportunity to explore the dependencies that make up the Intercom Profile, and we will provide a narrative of the capabilities that are expected at this level. In Table 5-20, we identify the capabilities that are required from this layer and in the following subsections discuss the specific procedures in more detail.
Table 5-19. The range of service definitions that are used during QoS.
|
SERVICE |
DESCRIPTION |
|---|---|
|
No Traffic |
This indicates that the channel will not be sending any traffic and, as such, any parameters can be ignored. |
|
Best Effort |
This default value attempts to achieve a minimum service with the local remote device, where no guarantees are offered. |
|
Guaranteed |
With this service definition, we indicate that we wish to achieve the maximum bandwidth permitted. This is, of course, subject to the nature of a wireless environment. |
Table 5-20. The mandatory requirements that are required for a compliant Intercom Profile.
|
PROCEDURES |
SUPPORT |
|---|---|
|
SCO Links |
M |
Table 5-20 summarises the broad capabilities that are expected from the LM. These will determine what is expected from the procedures at the LM. Included in the table are a set of deviations that the profile includes, which is above the common set of procedures expected at LM.
A SCO link is set-up using the HCI_Add_SCO_ Connection command (see Table 5-21), where a series of Voice_Setting parameters are used to denote the type of SCO channel and the audio coding schemes. The Voice_Setting parameters are written using the HCI_Write_Voice_Setting command and are shown in Table 5-22.
Table 5-21. The command and events that are used in combination to create a SCO connection. The Host Controller first sends the Command_Status event, but when the connection has been established the Connection_Complete event is generated on both devices.
|
COMMAND |
PARAMETERS |
|---|---|
|
|
|
|
EVENT |
PARAMETERS |
|---|---|
|
|
|
|
|
|
Table 5-22. The command and events that are used in combination to write the voice setting parameters for a SCO link.
|
COMMAND |
PARAMETERS |
|---|---|
|
|
|
|
EVENT |
PARAMETERS |
|---|---|
|
|
|
It assumed that the partying devices have an existing ACL communications link, where pairing, authentication and encryption (if required) have already taken place. The ACL Connection_Handle parameter is used, in part, to then create our SCO connection using the HCI_Add_SCO_Connection command. Although, the host controller generates a Command_Status event, it does not indicate that the SCO connection has been created. The host controller for both devices uses the Connection_Complete event to notify both hosts whether the SCO connection has been successful or not, where the new Connection_Handle and Link_Type identify the new connection. You may also wish to note that the Packet_Type parameter is used to specify the type of high-quality voice transmission, where HV1, HV2 or HV3 can be requested over the SCO link.
The Voice_Setting parameters are shown in more detail in Table 5-23. The parameter makes use of two bytes, but only the first ten bits are useful. The HCI_Write_ Voice_Setting command also returns a Status of whether the command succeeded or not. The Voice_Setting parameters define the behaviour of all SCO connections that are active between partying devices.
The LC layer is the lowest layer depicted in the dependencies of this profile and it is responsible for a large number of core capabilities. It manages air-to-interface transactions and determines the fundamental timing of ACL and SCO data packet transmission and reception, as well as coordinating the effort at its upper-edge with the LM. It also encompasses the management of the various packet types and the various inquiry and paging procedures that are available. In turn, the following subsections provide clarity regarding the capabilities that are a requirement at the LC level for the Intercom Profile. In our understanding of the dependencies, we begin by examining in more detail the supported capabilities and a small discussion is offered for each. If you are a developer providing profile-specific applications, then it is unlikely that you will engage in a large part of this component, although in some audio-related applications direct access may be required, where a faster transport mechanism can be supported. Nevertheless, many manufacturers have architected an audio-specific API for intelligible access to this component.
Table 5-23. The Voice_Setting parameters that are used to define the behaviour of all active SCO connections.
|
PARAMETERS | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Bit # of Voice Setting Parameters |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Linear |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
µ-Law Baseband Coding |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
A-Law Baseband Coding |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1’s Complement |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
2’s Complement |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
Sign-magnitude |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
8-bit Input for Linear PCM |
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
16-bit Input for Linear PCM |
|
0 |
0 |
x |
x |
x |
0 |
0 |
0 |
0 |
0 |
Used for denoting the PCM Bit Offset |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
CVSD air-coding format |
|
0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
µ-Law air-coding format |
|
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
A-Law air coding format |
Table 5-24 summarises the broad capabilities that are expected from the LC. In the table, you will notice features are marked appropriately and these will determine what is expected from the LC.
An inquiry procedure is used to learn of the other devices in radio range, where the BD_ADDR and clock offsets are obtained; it is DeviceA that will enter an inquiry substate to perform this procedure. A device that wishes to be discovered (DeviceB) will enter an inquiry scan substate, where the device will respond with an inquiry response. In this state, DeviceB is waiting to receive an Inquiry Access Code (IAC). From an application perspective, these modes of operation are discussed in more detail in the Generic Access Profile, Chapter 2. It is here that specific rules are determined with regard the behaviour of such devices and how long these devices can operate in such modes. When devices have been discovered, this information is passed over to the Service Discovery Application Profile, Chapter 3, which manages the specific attributes that make up that device. What is being established here, as a dependency, is that the Bluetooth protocol stack must encompass and support such behavioural procedures for this profile to be considered compliant.
The inquiry substate and inquiry scan substate procedures are the initial method used to learn of other devices in radio range; to this extent, the device has discovered sufficient information to gain a connection with the remote device. This is achieved when DeviceA has the intent to create a connection with DeviceB; DeviceA is now placed into a paging substate, where it will periodically transmit the Device Access Code (DAC). The DAC is used to target the device directly and the clock offset is used to gain an idea of the clock cycle of DeviceB. These parameters were originally obtained during our inquiry procedures. If DeviceB wishes to be connected, then it will enter a page scan substate and will respond accordingly to DeviceA. An inquiry procedure may be avoided if the BD_ADDR is already known, although a connection may take a little longer as the clock offset is not known.
Inter-piconet capabilities describe the process that allows the master to manage multiple connections from slave devices. During a connection, other users may temporarily witness degradation in the service that is being provided, but the master must be capable of accepting new participants into the piconet.
There are numerous packets types available and Table 5-25 identifies those most frequently used for profile support. There are also a number of common packet types that are used for general purpose transport; for example, the ID packet is used for inquiry procedures and a POLL packet would be sent by DeviceA to determine if a slave is active on a channel.
The DM1 packet type is used to transmit control data over any connection, but may be used to transport a genuine payload. HV1, HV2 and HV3 are various SCO packet types to carry audio-specific data, where a DV packet can combine ACL and SCO specific data; their support in this profile is reflected in Table 5-26. Various ACL packet types are also available. Seven types, including the DM1 type, are attributed to carrying user-specific data.These include DH1, DM3, DH3, DM5, DH5, and AUX1; similarly, Table 5-25 summarises their support in this profile.
Table 5-26 summarises voice codec support in this profile. Voice coding schemes are used to provide compression and to overcome potential errors in the data transmission.
Continuous Variable Slope Delta (CVSD) provides the second scheme, which is particularly efficient for voice communication; it also tolerates potential errors in the audio data. The Pulse Code Modulation (PCM) has two types of logarithmic compression; these are A-law and µ-law, where either compression technique can be applied on the voice channels over the air-interface.
The Intercom Profile falls into the category of the 3-in-1 usage model that is supported by the Cordless Telephony Profile.
The profile supports terminal-to-terminal direct communication.
Other usage models may be extended to door intercom and hospital paging schemes.
The Intercom Profile is built upon the TCS.
The profile does not mandate a strict master-slave operation and, as such, either terminal may initiate a connection.