This high-level form of defining a Bluetooth device identifies where in the Service Class field the Cordless Telephony Profile resides; see Table 4-6, which shows the category of service. In this instance, the category of service falls within Telephony.

This high-level form of defining a Bluetooth device identifies where in the Major Device Class the Cordless Telephony Profile resides; see Table 4-7, which shows 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 4-8. Here, the bit may be set appropriately for Cordless to denote the type of device available to the user.

In this section, we consider the operation of devices that interact using the TCS protocol and also examine how the various Bluetooth protocol layers interact. In our earlier discussion, we introduced the various usage models available to a user and, as such, the operation of these devices follow simple procedures.

TCS has both a single- and multiple-point available. In the former configuration, a single-point method is used to direct a call to a specific Bluetooth-enabled device whilst our latter configuration supports a multiple-point method to direct a potential call to numerous devices. The single-point configuration is mapped to a connection-orientated L2CAP channel, whereas a multiple-point method is mapped to a connectionless L2CAP channel.

In Figure 4-10 and Figure 4-11 we provide a conceptual representation of Bluetooth-enabled devices interoperating using the TCS protocol. Figure 4-10 illustrates the single-point method, where a call request is used to notify the mobile phone of an incoming call and subsequently, the phone establishes the speech or data channel. In Figure 4-11, we illustrate the multiple-point method where in this particular instance, all devices are notified of the call request. We show that Cordless Handset B accepts the incoming call, where by a single-point signalling channel is created; both devices then establish a speech or data channel.

Figure 4-10. A Bluetooth-enabled gateway notifies the mobile phone of the call request, where a speech or data channel is subsequently created.

Figure 4-11. A Bluetooth-enabled gateway notifies the cordless handsets that are in radio range of the call request. Cordless Handset B, accepts the incoming call and creates a single-point signalling channel, then it creates a speech or data channel.

With the ability to manage single- and multiple-point communication between Bluetooth-enabled devices, a TCS architecture must reflect the capability to inherently coordinate simultaneous communication between peer devices. Each instantiation of a TCS component would be uniquely identified through the Channel Identifier (CID) of an L2CAP connection. This would allow communication to be directed accordingly for connected devices.

In Figure 4-12, we illustrate the conceptual architecture that is proposed for a TCS implementation. In it you will notice the entities that characterise the TCS component. The Call Control (CC), Group Management (GM), Connectionless (CL) and Protocol Discrimination entities have their own responsibilities in providing a telephony service; these are now identified in Table 4-15.

Figure 4-12. A conceptual illustration identifying the structure of the TCS component.

In our earlier discussion, we touched upon the fact that the Cordless Telephony and Intercom Profiles rely upon TCS to provide a telephony service. Our focus here is to describe the processes used to provide such a service and to establish how the underlying Bluetooth transport is facilitated in achieving this. In doing so, the reader will come to understand how the various types of scenarios are supported.

TCS has been designed to sit above the L2CAP component of the Bluetooth protocol stack. In our first look at understanding this protocol, we will examine how the TCS protocol is used to transport data between peer devices.

In Figure 4-13 we illustrate what is referred to as a TCS signalling message. In other protocols to be introduced in later chapters, varying terms are used to refer to the packet ^[6] used to transport a payload. ^[7] The signalling message has been adapted from the International Telecommunications Union (ITU) Telecommunications division, Q.391 Digital Subscriber Signalling System No. 1 (DSS 1) and ISDN User Network Interface Layer 3 Specification for Basic Call Control.

Figure 4-13. The structure of the signalling messaging as used within the Cordless Telephony Profile.

The structure of the message packet is constructed using two octets, which comprise a Message Type, Protocol Discriminator and an Information field. The Message Type field is used to describe the function or purpose of the message. It occupies the first 5-bits of the first octet. In our earlier discussion, we identified three core entities that are used to manage the various functions within TCS. As such, the Message Type values are depicted in accordance with the respective entity in Table 4-16 for Call Control, Table 4-17 for Group Management and finally Table 4-18 for Connectionless.

The various Message Type groups, that is CC, GM and CL, are identified with the Protocol Discriminator field, which is illustrated in Table 4-19. This is used to convey the local device’s intention to the remote peer device.

The final field of the signalling message is the Information field; it contains data relevant to the type of function, which is specific to the Message Type field. The Information field is further categorised into three informational elements, which are constructed using 1-byte, 2-byte or of a variable length field. In Figure 4-14, we illustrate the construction of a 1-byte Information field, whereas Figure 4-15 illustrates a 2-byte construction.

Figure 4-14. A 1-byte Information field used in the Signalling Message.

Figure 4-15. A 2-byte Information field used in the Signalling Message.

In Figure 4-16, we can see the construction of a variable Information field, where the Length field indicates the total length of the data to follow in the Contents field. In all our illustrations of the Information field, a Flag field is used to denote the category of information being carried. If the Flag field is set to 1, then this would indicate that a fixed 1- or 2-byte Information field follows, whereas a Flag field set to 0, would indicate that a variable Information field follows.

Figure 4-16. A variable length Information field used in the Signalling Message.

Table 4-20 illustrates the various information element codings available for the Identifier field. Recall that the Flag field denotes 1-byte, 2-byte or a variable length, which are also indicated in the table.

The Contents field transports data relevant to the current activity, as indicated in Table 4-20. In the following sections, we provide two examples of how coding is achieved in the Information field. Our first example, Figure 4-17 illustrates the structure of the Call Class coding.

Figure 4-17. A 2-byte Information field, which in this example contains data relevant to the call class.

For the call class structure, the Flag field would be set to 1, indicating that it is a 1-or 2-byte Information field. The Identifier field would be set to the value, as indicated in Table 4-20. The values available to the Contents field, which constitutes the call class specific data, would have the values identified in Table 4-21 available to it.

In our second example, the Destination CID coding is used to locate the established L2CAP channel with the remote peer device. You may recall that a Bluetooth-enabled device may communicate and connect to a number of devices. As such, the CID of the L2CAP channel is used to uniquely identify and route the traffic accordingly.

For the destination CID structure, the Flag field would be set to 0, indicating that it is a variable length Information field. The Identifier field would be set to the value as indicated in Table 4-20 and the destination CID specific data, would contain the destination CID of the active connection. In Figure 4-18, the Length field would be set to 2, since the destination CID is constructed using 2-bytes.

Figure 4-18. A variable-length Information field, which in this example contains data relevant to the destination CID.

During the exchange of signalling messaging, a message will be ignored if a Protocol Discriminator field is present or if the message is too short or unrecognised. When a message is delivered unexpectedly, the TCS component will not be in an appropriate state to receive such a message then this too will be ignored.

In Table 4-15 we identified the responsibilities of the CC entity. Its primary responsibility is to coordinate the connection and disconnection of speech and data calls between the TL and GW. In Table 4-22, we illustrate the set of Call Control procedures that are required to achieve a compliant Cordless Telephony Profile.

In Table 4-23, we illustrate the set of Supplementary Services that can be made available internally or externally.

In Table 4-15 we identified the responsibilities of the GM entity. Its primary responsibility is to manage group effort between the TL and GW and to coordinate effort for WUGs. In Table 4-24, we illustrate the set of Group Management procedures that are required to achieve a compliant Cordless Telephony Profile.

In Table 4-25, we identify that both the Connection-orientated and Connectionless Channels are mandatory; the connectionless channel is aimed at broadcasting, where only the GW will support this feature. L2CAP uses PDUs to transport connection, signalling and configuration options, which will be discussed shortly. 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. 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 4-26.

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 4-27 identifies these values and the corresponding protocol they represent. The value of 0x0007 (TCS-BIN-CORDLESS) 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 4-28 illustrates the range of that are used to identify the channel type. As we can see in Table 4-25, 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 Cordless Telephony 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 the suggested Maximum Transmission Unit (MTU) is too large. In Table 4-25, we identify 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 Cordless Telephony Profile requires that a minimum MTU of 171-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 (or in other words 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 Cordless Telephony Profile uses the default value of 0xFFFF.

As we have already mentioned, the QoS configuration is optional. 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 for an L2CAP channel are shown in Table 4-29. 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.

Table 4-30 summarises the broad capabilities that are expected from the LM. In the table, you will notice procedures are marked accordingly; this will determine what is expected from the procedures at the LM. What has been included in the table is a set of deviations that the profile requires, which is above the common set of procedures expected at LM.

Encryption is mandatory for this profile and, as such, a summary of the activities that occur during this process is now provided; more detailed information can be found in the Generic Access Profile, Chapter 2. Once both devices have agreed to undertake encryption, which occurs after the authentication process, DeviceA (or master) takes the initiative and needs to determine whether to include encryption for point-to-point or broadcast communication. If DeviceB (or slave) is agreeable to the parameters offered by the master, the master proceeds to communicate further detailed information about the encryption parameters.

As previously mentioned, the actual process is invoked when the two parties agree to use encryption, where subsequent L2CAP communication terminates. The master then sends the LMP_encryption_mode_req command. If this is acceptable to the slave, it too terminates all L2CAP communication and responds with the LMP_ accepted command. The next step in this process actually determines the size of the encryption key and it is the master that sends the LMP_encryption_key_size_req command, where it offers an initial recommendation of the key size to use. For this profile to be compliant, the initial recommendation offered is five octets. The slave, in turn, then offers its own recommendation, where it informs the master what it thinks it might be capable of—nevertheless, the minimum recommended size must be initially offered. Both master and slave will repeat this process until they reach an agreement; however, if neither party reaches a decision, then the LMP_not_accepted command is sent, offering the reason as unsupported parameter value (0x20), see Appendix A.

Upon accepting the key size, the LMP_accepted command is issued and the encryption procedure then takes place by issuing the LMP_start_encryption_req command with a random number, which is used to calculate the encryption key. Table 4-31 summarises the available commands for the encryption process.

The master-slave switch operation is required ^[9] when the GW is configured for multi-terminal ^[10] support. The failure of a TL to perform this operation prohibits the successful connection to a GW. Figure 4-19 provides an illustration of the events that occur when the TL successfully performs the master-slave switch request ^[11].

Figure 4-19. The events that take place during a master-slave switch.

Table 4-32 provides the HCI command and event combination that are used to perform the master-slave switch operation between the TL and GW. This table represents one such method of performing a switch, where other HCI commands, such as the HCI_Create_Connection command, specify the same request as part of their parameter set-up. In this instance, the Allow_Role_Switch parameter is used during the connection establishment to determine if a switch can be performed by the local device, that is, the device initiating the connection (DeviceA). The remote device (DeviceB) is duly notified with its corresponding HCI command, Accept_Connection_Request of whether it can be supported.

Table 4-33 provides the two LMP general response messages, which are mandatory for this profile. During an LMP_accepted operation, the response contains the OpCode of the operation that was successful; whereas the response from the LMP_not_ accepted provides the OpCode of the operation that was not successful. Accompanying this OpCode, a reason or error code is provided to help to determine why the operation failed; a full list of LMP reasons can be found in Appendix A.

There general response messages are used in combination with the following LMP role-switch specific messages, which are shown in Table 4-34. We will now explore the behaviour of both these devices when performing the master-slave switch operation. You may remember from our earlier discussion that both the TL and GW are capable of initiating a connection.

When DeviceB (or slave) initiates a master-slave switch, it terminates the final ACL packet and stops any further L2CAP transmissions. It then sends LMP_slot_offset command immediately followed by the LMP_switch_req command. Similarly, if the master accepts the master-slave switch, it terminates all L2CAP transmissions and then issues an LMP_accepted command, if the transaction is a success. However, if the operation is rejected, then an LMP_not_accepted command is provided as the response, with a specific reason for its failure. Furthermore, when the operation has been completed, despite its success or failure, L2CAP communication is resumed.

When DeviceA (or master) initiates a master-slave switch, it terminates the final ACL packet and stops any further L2CAP transmissions before sending an LMP_ switch_req. Similarly, if the slave accepts the master-slave switch, it terminates all L2CAP transmissions and then issues an LMP_slot_offset command immediately followed by an LMP_accepted command. However, if the operation is rejected, then an LMP_not_accepted is provided as the response, with a specific reason for its failure. Furthermore, when the operation has been completed, despite its success or failure, L2CAP communication is resumed.

The recommended power saving mode for this profile is Park Mode and is indicated as mandatory in the summary of capabilities as shown in Table 4-30. When a device participates in this mode, it will relinquish its Active Member Address (AM_ADDR) and then is assigned two new addresses, as shown in Table 4-35.

In its effort to reduce power consumption, the device will no longer participate in a piconet or be addressed by the master. During periodical intervals, the device will listen for broadcasts to allow it to become an active member of the piconet again. In Table 4-36, we identify the HCI commands that are used to place a device into this mode. Placing a device into park mode will modify the behaviour of the LM, where the Connection_ Handle parameter of an ACL link identifies the specific connection that has to be placed into this mode. The Beacon_Min_Interval and Beacon_Max_Interval parameters inform the device when to periodically listen for broadcasts. It is noted that no active SCO connections are permitted during the operation of park mode; if one exists then an error Command Disallowed will be returned by the Command_Status event, see Appendix B for a list of HCI errors and reasons.

When a device wishes to exit park mode, then the HCI command, as identified in Table 4-37, is used to bring the device back into active mode. The Connection_ Handle parameter of an ACL connection is used to identify the specific connection that wishes to be returned to active mode.

General response messages, as previously illustrated, are used in combination with the following LMP park mode specific messages; these are summarised in Table 4-33.

During the operation of park mode, the master may request that the slave enter the low-power saving mode. All communication at the L2CAP level is finalised and the LM then issues the LMP_park_req PDU. Similarly, the slave finalises its communication at L2CAP and responds with the LMP_accepted PDU. When both devices have agreed to engage park mode, the slave relinquishes its AM_ADDR. However, if the slave rejects park mode, it will respond with LMP_not_accepted and communication will recommence. The slave may also request that it enter park mode, where similar actions are carried out during this procedure.

A SCO link is set-up using the HCI_Add_SCO_ Connection command (see Table 4-39), 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 4-40.

It assumed that the partying devices have an existing ACL communications link, where pairing, authentication and encryption 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 4-41, 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.

Table 4-42 summarises the broad capabilities that are expected from the LC and in the table you will notice features are marked with M (Mandatory), O (Optional), X (Excluded), C (Conditional) and N/A (Not Applicable); this will determine what is expected from the features at the LC.