The Fax Profile provides us with the same scenarios as introduced in the previous chapter Dial-up Networking, Chapter 8. In Figure 9-1 and Figure 9-2, we show that a fax service can be obtained from a notebook. The notebook behaves as a gateway (GW) and connects to a mobile phone or wireless modem, which represents our data terminal (DT).
Figure 9-1. The fax usage model allows the notebook to behave as our DT device, where it can create a wireless bridge with the mobile phone, which acts as a GW.
Figure 9-2. In this illustration, the fax usage model allows the notebook to behave as our DT device, where it can create a wireless bridge with the wireless modem, which acts as our GW.
You may recall that the introduction of a dial-up networking service was not a new idea. Nor indeed is the concept of a fax service. What has changed, however, is the introduction of a wireless bridge, which is used to remove the need to physically connect your mobile phone or modem to a notebook or Personal Digital Assistant (PDA). The Fax Profile provides the capability for a DT device to form a wireless bridge with a GW. Once the connection with the GW has been established, a fax service can then be obtained.
This section examines our existing usage models through scenarios that may be typical for the Fax Profile. We begin by exploring the existing models, where a notebook or PDA communicates with a mobile phone or wireless modem to obtain a fax service.
The scenarios provided in Figure 9-1 and Figure 9-2 represent our existing usage models. The role of a notebook (or PDA) acting as a DT initiates a one-to-one communications link with another Bluetooth-enabled device. This device, in turn, takes on the role of a GW. A wireless bridge is thereby created, which completes the connection. The formation of a wireless bridge between the notebook and PDA (or modem) demonstrates the fundamental Bluetooth philosophy: removing the need for cables. [1] A Fax application on the DT would be used to send a fax, where the Bluetooth device is used as the underlying transport. In the next section, we provide clarification on the notion of a wireless bridge and explain how it fits within the Fax Profile.
A wireless bridge is used to describe the nature of the cableless connection between the DT and GW; this is fundamental to and dominates the profile. Earlier in our introduction, we touched upon the need to connect a cable between a notebook and a mobile phone. This scenario allows the notebook (DT) to perform a dial-up connection through the mobile phone (GW) and then on to a remote service.
To support this profile, a two-piece Bluetooth protocol stack is required to complete the wireless bridge. In Figure 9-3, we can see what components of the stack are needed to form the DT and GW wireless relationship. Both the Dial-up Networking and Fax Profiles require the use of the AT Command component, which in turn controls the GW.
The Fax Profile provides two new roles: a DT device and a GW device. The GW provides the ability for a DT to connect and to provide the remote services; this is achieved by providing modem emulation, where the operation of AT commands is used to enable control and dialling. The modem emulation and driver are provided above RFCOMM, where RFCOMM provides serial port capabilities by emulating RS232 (see the Serial Port Profile, Chapter 6, for more detailed information). Figure 9-4 demonstrates the architecture of the components that make up the complete fax model.
Figure 9-4. The core components of the Bluetooth protocol stack are shown illustrating how the components of the Fax Profile are integrated.
In Table 9-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.
In this chapter, the DT is referred to as DeviceA or the initiator; and the GW is the acceptor and forms DeviceB. DeviceA will remain master, since the GW is permitted to accept only one connection, although there are no strict master-slave roles. A GW device is considered to be the Data Circuit Endpoint (DCE) and the DT takes the Data Terminal Equipment (DTE) role in this conventional mapping.
Table 9-1. The list of behavioural characteristics that are typical for this profile.
|
CONFIGURATION |
ROLE |
DESCRIPTION |
|---|---|---|
|
DeviceA |
DT |
A device acting as a data terminal, which may take the form of a notebook or PDA. 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 |
GW |
A device that behaves as a gateway, where it manages incoming and outgoing external communication through AT Command control signalling. It is also the party that accepts incoming connections from the data terminal. |
|
Acceptor |
This configuration describes the process of the device accepting the initiated communication from DeviceA. |
Today, we can openly purchase products that are capable of supporting the Fax Profile; these can be typically found within a PDA, notebook or mobile phone. If you recall from our earlier discussion, the Fax Profile is essentially a two-piece solution.
Bluetooth Profiles supports the philosophy of a rewarding user experience. It is therefore important to consider how the user would experience the connection and use of a GW. In later sections, we consider the specific experiences of connecting, terminating and losing connections and how the user may experience such operations.
We will consider the typical attributes that may make up a service discovery of a GW. The user experience in this particular example is a screen shot from the DT, which clearly shows that the mobile phone is capable of supporting the fax profile (see Figure 9-5).
Figure 9-5. The screen shot shows a typical set of attributes that may be seen when discovering GWs (in this instance, the 3Com Bluetooth Connection Manager has discovered the services available from a mobile phone).
The GW as a mobile phone should be initially enabled, where parameters such as limited discovery and range can be defined; this helps to limit unauthorised access to the GW. As a wireless modem, similar security features can be employed in addition to the passkey requirement.
In both instances, a passkey would be requested to enable authentication of the DT and GW. There may be other cases where the passkey may have to be provided, again possibly due to connection timeouts and/or the mobile phone being re-enabled for dial-up use. It may be recommended that a timeout occur after a defined period to, again, ensure and help with unauthorised access. In our earlier discussion, we touched upon the ability of the GW to only accept a connection from one DT at any time. This feature restricts use from intruders and, as a result, provides the user with a sense of security.
Once the user has the ability to connect to a device, he or she may now continue to make use of the services it provides. By using a double-click [2] or right-click operation, you can begin the process of connecting to the fax service as shown in Figure 9-6.
Figure 9-6. Right-clicking the devices icon causes a pop-up menu to appear, offering the ability to connect to the device. In this illustration we can see the user connecting to a service offering fax capabilities. (Courtesy of TDK Systems Europe.)
Prior to using the GW, a user may be required to enter a Bluetooth Passkey. In Figure 9-7, we show the user being prompted with a dialog box requesting the entry of a passkey.
Underlying this high-level user interaction is a sequence of events that lead up to the moment of connection. Figure 9-8 illustrates the message sequences that typically occur during a connection set-up. Other implementations may differ slightly, depending upon the user’s specific requirements. [3]
During connection establishment, the user may be informed of the dial-up in progress; in Figure 9-9, we show the user being informed of the progress of the connection. In Figure 9-10, we can see that the connection has made further progress and now the user is informed that the GW has commenced dialling.
Once a connection is established with a GW and its services are no longer required, the user may terminate the session. As shown in Figure 9-11, the user is able to right-click on the connected device’s icon and select disconnect from the pop-up menu to terminate the connection.
Figure 9-11. The user chooses to right-click the connected device icon and uses the pop-up menu to terminate the connection with the GW. (Courtesy of TDK systems Europe.)
Other forms of disconnection may occur if the quality-of-service can no longer be maintained by the remote service; one example of this would be if the GW connection to the facsimile is unexpectedly lost. It is important to remember that the appropriate information about the current connection must be conveyed to the user, as the DT may offer a reconnection at a later time.
One other such instance of a terminated connection may occur if a connection is lost due to the DT moving out of range from a GW. Section 9.4.1.3, Losing a connection with a GW, looks at the sequence of events surrounding this possibility and considers how the user should experience this event.
It is hard to imagine an instance where a connection would be lost with a GW. However, if the GW is taken out of radio range or the carrier is unexpectedly lost, then the DT must be able to appropriately manage the user interface aspects and, of course, the application should eventually allow the user to reconnect at a later stage.
In Figure 9-12, the device status is clearly shown when right-clicking the device icon to select its properties. As we saw in an earlier illustration, the device status is also shown alongside the icon (see Figure 9-6). A seamless reconnection can be achieved if both the DT and GW remember their previous respective sessions, whereby the reconnection time can be dramatically reduced.
The simplicity of a mobile phone as a GW enables the user to place it in an area where it does not need to be in direct line-of-sight with a PDA or notebook, although the GW should be within suitable radio range. One classic and most often referred to example is the briefcase trick. Here, the user can place the GW into a briefcase or a jacket pocket and make use of the available services discreetly; similarly, wireless modems can be fixed in any location.
The GW undertakes a series of events that enable a DT to successfully access its service; Figure 9-13 illustrates these events. When a DT wishes to connect to a GW, it initiates bonding, where the GW must accept this request; encryption may also be used on the link.
In our previous discussion, we covered aspects of existing usage models and their respective user expectations. Now we take an opportunity to explore, in greater depth, the dependencies of which this profile comprises.
In Figure 9-14, we illustrate the dependencies that make up the Fax Profile; the areas that are shaded are relevant to this profile. This 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 Serial Port Profile, Chapter 6. We will now discuss the basic requirements of these dependent components alongside any deviations that may occur from their basic functionality.
Figure 9-14. The dependent components of the Bluetooth protocol stack that make up the Fax Profile. The areas that are shaded are relevant to this profile.
The Fax Profile 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. It then becomes sufficient to realise that the behaviour of such devices is governed by simple rules that relate to their connectivity, discoverability and common characteristics at the user interface level, with some additional emphasis provided for security. It is these rules and procedures that are used to establish commonality between products, which will ultimately achieve a cohesive user experience. This section reflects upon the behavioural aspects of Bluetooth-enabled devices as outlined by the Generic Access Profile.
We have dixcussed how the Generic Access Profile mandates certain rules and procedures that help govern the overall connectability, discoverability and security aspects of Bluetooth-enabled devices.
Now, take a look at Table 9-2, the basic set of procedures is illustrated and the functional expectations that govern where operation are also identified. These procedures help to 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 it is capable of offering.
In Table 9-3, we consider the specific set of operations that are required for this profile. In the table, you will notice features are marked with M (Mandatory), O (Optional), X (Excluded), C (Conditional) and N/A (Not Applicable); these will determine what is expected from the features of the Generic Access Profile. Typically, a GW device will operate in a limited discovery mode, where authentication and encryption may be used.
Table 9-4 identifies the security requirements for this profile. Remember that Security Mode 1 is a non-secure mode where Bluetooth-enabled devices will never initiate any security procedures; Security Modes 2 and 3 initiate different levels of security procedures at various stages of connection establishment. In this instance, the profile mandates that support should be provided for at least Security Mode 2 or 3.
Table 9-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. |
Table 9-3. The illustration shows specific modes of operation that this profile depends upon to realise its compliant implementation.
|
MODES |
DT |
GW |
|---|---|---|
|
Non-discoverable |
N/A |
O |
|
Limited Discoverable |
N/A |
O |
|
General Discoverable |
N/A |
O |
|
Non-connectable |
N/A |
X |
|
Connectable |
N/A |
M |
|
Non-pairable |
M |
O |
|
Pairable |
O |
M |
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 9-5 provide a clear indication of how a device should operate when performing such an activity; let us take our bonding procedure as an example. The term bonding is very much associated with the pairing process; however, bonding occurs when the user has the intent to initiate a trusted relationship with DeviceB. With this intent, the user is prompted to enter a Bluetooth Passkey which, in turn, instigates the pairing process that is the generation of the link keys, where subsequent authentication can then occur. In summary, what we learn here is that there are a specific set of events associated with a procedure. In the Generic Access Profile, Chapter 2, we take a closer look at 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 9-15. 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 9-16 and is made up of 3-bytes (or 24-bits as shown). The following sections now consider the Fax attributes, which will ultimately make use of the Service, Major and Minor Device Class fields.
Figure 9-15. The structure of the FHS packet used only for reference to illustrate the position of the Class of Device structure.
Figure 9-16. The structure of the class of device, illustrating the Minor Device, Major Device and Service Class fields and their respective lengths.
Table 9-4. The illustration shows specific security procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
DT |
GW |
|---|---|---|
|
Authentication |
M |
M |
|
Security Mode 1 |
N/A |
X |
|
Security Mode 2 |
C |
C |
|
Security Mode 3 |
C |
C |
Table 9-5. The illustration shows specific behavioural procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
DT |
GW |
|---|---|---|
|
General Inquiry |
M |
N/A |
|
Limited Inquiry |
O |
N/A |
|
Name Discovery |
O |
N/A |
|
Device Discovery |
O |
N/A |
|
Bonding |
M |
M |
This high-level form of defining a Bluetooth device identifies where in the Service Class field the Fax Profile resides (see Table 9-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 Fax Profile resides (see Table 9-7) which, in turn, determines the major class grouping. Here, the category falls within phone, since a mobile phone providing modem emulation may be used.
The Minor Device Class in this profile is used to convey a further context for the setting within the major class grouping (see Table 9-8). Here, the bit may be set appropriately for Mobile Phone or Wireless Modem 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 an inquiry and discovery procedure as outlined in our previous section, to learn of the devices in radio range. A client can 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, the DT and GW must employ the use of an SDP client and server respectively, as illustrated in Table 9-9.
PDUs are used to instruct the SDP server to undertake browsing procedures and to retrieve service record information; you may recall that these PDUs carry payload requests containing AttributeIDs and AttributeValues, which describe 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, which in turn instruct the server to carry out its operation. The various request and response PDUs that are required are shown in Table 9-10, where features indicated are described as mandatory (M), optional (O) and excluded (X).
Table 9-6. The Service Class categorisation for the Fax 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 9-7. The Major Device Class for the Fax Profile.
|
MAJOR DEVICE CLASS | |||||
|---|---|---|---|---|---|
|
12 |
11 |
10 |
9 |
8 |
Bit # of CoD |
|
0 |
0 |
0 |
1 |
0 |
Phone |
Table 9-8. The Minor Device Class for the Fax Profile.
|
MINOR DEVICE CLASS | ||||||
|---|---|---|---|---|---|---|
|
7 |
6 |
5 |
4 |
3 |
2 |
Bit # of CoD |
|
0 |
0 |
0 |
0 |
0 |
1 |
Mobile Phone |
|
0 |
0 |
0 |
1 |
0 |
0 |
Wireless Modem |
Table 9-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 |
DT |
GW |
|---|---|---|
|
SDP Client |
M |
X |
|
SDP Server |
X |
M |
Table 9-10. The list of PDUs that are required for the operation of the Fax Profile.
|
PDU |
DT |
GW |
|---|---|---|
|
|
X |
M |
|
|
M |
X |
|
|
X |
M |
|
|
M |
X |
|
|
X |
M |
|
|
O |
X |
|
|
X |
O |
Table 9-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
ParameterFor1 |
With an |
BluetoothProfile
DescriptorList
Profile0
ParameterFor0 |
With an |
|
|
With a base |
|
|
With an |
|
|
With an |
|
|
With an |
|
|
With an |
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 9-11 identifies a GW device and provides a list of AttributeIDs, which ultimately would identify the service for the Fax Profile. A minimum of two AttributeIDs are required to make a service record; these are ServiceRecordHandle and a ServiceClassIDList, which 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. 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 in this chapter 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 should all 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 9-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 9.5.1.1, Generic Access.
Table 9-12. The list of service classes that match a corresponding profile. This correlates with our previous Generic Access section.
|
CLASSES |
UUID |
|---|---|
|
|
|
|
|
|
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 Fax Profile is dependent on the protocols as shown in Table 9-13, which also shows their associated UUID values.
In the Serial Port Profile, Chapter 6, we introduced the conceptual and functional nature of RFCOMM and discussed how it provides an emulated serial port presence. Several distinctions were made between the various types of applications. The purpose of making these distinctions was to enable clarification and understanding of RFCOMM’s composition. In this particular application context, the creation of an emulated serial port would be transparent to the user. The Fax Profile is dependent upon the operation of the Serial Port Profile and, as such, is required to establish an emulated serial port as part of its communication link with the remote device.
The term cable replacement application was introduced in our earlier chapter and distinguishes between the different scenarios available. It refers to specific Bluetooth applications that create implicit emulated serial ports, which remain transparent to the user to complete the creation of a communications link.
Specific detail has been provided to illustrate how data is communicated over an emulated serial port connection, whereby a Data Link Connection (DLC) is established between two peer devices, namely DT and GW. We have also looked at the fields that make up our service record for this profile. The ProtocolDescriptorList field is used to describe the set of protocols that the profile intends to use and, as such, the RFCOMM protocol identifier contains a parameter, which contains the Server Channel number.
The Server Channel is used in combination with a Data Link Connection Identifier (DLCI), which is then used to uniquely identify the active DLC. This connection is then mapped onto a connectionless orientated L2CAP Channel Identifier (CID).
Table 9-13. The list of protocols that are used in this profile; their associated UUID values are also shown.
|
PROTOCOL |
UUID |
|---|---|
|
|
|
|
|
|
In this section we highlight the specific features that are required to realise a compliant Fax Profile. Table 9-14 and Table 9-15 illustrate the features or capabilities that are expected from the Serial Port Profile.
The use of the RLS command is encouraged to keep peer devices informed of any state change. In one such instance, an emulated serial port may interface to a Type II application (physical serial port), where overruns or parity errors may occur. An application that makes use of RS232 port configuration parameters should expose these settings through an appropriate API function; this is of particular relevance when interfacing to Type II applications.
In Section 9.3, Profile Principles, we introduced an illustration that identifies the modem emulation and driver components created with the help of RFCOMM. It is above this that a fax application would reside, using the serial port emulation provided by RFCOMM. The DT and GW would be capable of supporting the commands and responses as defined in the International Telecommunication Union, Telecommunication Standardisation (ITU Recommendation T.31 and T.32) Sector Asynchronous Facsimile DCE Control, Service Classes 1 and 2. A GW must be capable of supporting at least one fax class, but it may also support all class types. The DT will interrogate the GW to determine the type of fax class support using the AT Command AT+FCLASS.
Table 9-14. The set of capabilities that are required from the initiating party, denoted here by the DT device.
|
PROCEDURE |
DT |
GW |
|---|---|---|
|
Initialise an RFCOMM Session |
M |
X |
|
Terminate an RFCOMM Session |
M |
M |
|
Establish a new DLC Connection |
M |
X |
|
Disconnect a DLC Connection |
M |
M |
|
Emulate RS232 Control Signals |
C |
C |
|
Transfer Data |
M |
M |
|
Test Command |
X |
X |
|
Flow Control |
C |
C |
|
RLS |
O |
O |
|
PN |
O |
O |
|
RPN |
O |
O |
Table 9-15. The set of capabilities that are required from the responder party, denoted here by the GW device.
|
PROCEDURE |
DT |
GW |
|---|---|---|
|
Initialise an RFCOMM Session |
X |
M |
|
Terminate an RFCOMM Session |
M |
M |
|
Establish a new DLC Connection |
X |
M |
|
Disconnect a DLC Connection |
M |
M |
|
Emulate RS232 Control Signals |
M |
M |
|
Transfer Data |
N/A |
N/A |
|
Test Command |
M |
M |
|
Flow Control |
M |
M |
|
RLS |
M |
M |
|
PN |
M |
M |
|
RPN |
M |
M |
In our earlier discussion, we introduced the capability of audio feedback, which may be provided during call progress and is subject to the capability of the GW and DT. If, during a connection establishment, the SCO link fails, the call and ACL establishment may still proceed regardless. Furthermore, the GW has the responsibility to manage and establish the SCO connection (see Section 9.5.1.5.2, SCO Links).
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 [4] (HCI), which is then subsequently passed onto the Link Manager Protocol (LMP). The range of upper layers, which include RFCOMM, SDP and the Telephony Control Protocol Specification (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 also providing 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.
Table 9-16. The illustration shows specific procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
DT |
GW |
|---|---|---|
|
Connection-orientated Channel |
M |
M |
|
Connectionless Channel |
X |
X |
|
Connection Establishment |
M |
M |
|
Configuration |
M |
M |
|
Connection Termination |
M |
M |
|
Echo |
M |
M |
|
Command Rejection |
M |
M |
|
Maximum Transmission Unit |
M |
M |
|
Flush Timeout |
M |
M |
|
Quality of Service |
O |
O |
In Table 9-16, we summarise the broad capabilities that are expected from L2CAP. In the table, you will notice features are marked with according to; these will determine what is expected from them at the L2CAP layer.
In Table 9-16, we 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 Protocol Data Units (PDUs) to transport connection, signalling and configuration options, which will be discussed in a moment. 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 9-17).
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 9-18 identifies these values and the corresponding protocols they represent. The value of 0x0003 (RFCOMM) is used for this profile.
Table 9-17. 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 higherlayer 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. |
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 9-19 illustrates the range of CIDs that are used to identify the channel type. As we can see in Table 9-16, 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. 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 Fax 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 9-16, we have identified that the MTU and Flush Timeout parameters are mandatory, whereas the QoS is optional.
Table 9-18. The PSM values that are used to identify the higher-layer protocol.
|
PSM |
DESCRIPTION |
|---|---|
|
|
SDP |
|
|
RFCOMM |
|
|
TCS-BIN |
|
|
TCS-BIN-CORDLESS |
Table 9-19. The CIDs that are used to represent the logical channel.
|
CID |
DESCRIPTION |
|---|---|
|
|
Null |
|
|
Signalling Channel |
|
|
Connectionless Reception Channel |
|
|
Reserved |
|
|
Dynamically Allocated |
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. 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 Fax 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 9-20. 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 the HCI and translates them into operations for the LC, where Asynchronous Connectionless (ACL) and Synchronous Connection-Orientated (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.
Table 9-20. 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. |
In providing general error management, devices that operate mandatory procedures during interoperability must either acknowledge their support or provide a suitable reason for failure. The LMP_Detach PDU is used to inform the device of the error that occurred; typically, the reason unsupported LMP feature (0x1A) is reported (see Appendix A).
In the following discussion, we take an opportunity to explore the dependencies that make up the Fax Profile, where we provide a narrative of the capabilities that are expected at this level. In Table 9-21, we identify the capabilities that are required from this layer and in the following subsections we discuss the specific procedures in more detail.
Table 9-20 summarises the broad capabilities that are expected from the LM. In the table, you will notice procedures are marked according to what is expected from the procedures at the LM. The table illustrates a set of deviations that the profile includes, which are above the common set of procedures expected at LM.
The provision of SCO links is based on the capabilities of the DT and GW. If these devices are capable of providing audio feedback, then support for SCO Links should also be provided.
A SCO link is set up using the HCI_Add_SCO_ Connection command (see Table 9-22), 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 9-23.
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 9-24. The parameters make 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 9-22. The command and events that are used in combination to create a SCO connection. The Host Controller first sends the Command_Status event. When the connection has been established, the Connection_Complete event is generated on both devices.
|
COMMAND |
PARAMETERS |
|---|---|
|
|
|
|
EVENT |
PARAMETERS |
|---|---|
|
|
|
|
|
|
Table 9-23. The command and event that are used in combination to write the voice setting parameters for a SCO link.
|
COMMAND |
PARAMETERS |
|---|---|
|
|
|
|
EVENT |
PARAMETERS |
|---|---|
|
|
|
Table 9-24. 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 |
The Link Controller (LC) layer is the lowest layer depicted in the dependencies of this profile. 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 sub-sections provide clarity with regard to the capabilities that are a requirement at the LC level for the Fax 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 the likelihood for you to engage in a large part of this component is unlikely, 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 an intelligible access to this component.
Table 9-25 summarises the broad capabilities that are expected from the LC. In the table, you will notice features are marked according to; these will determine what is expected from the features at 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. DeviceA 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 to device behaviour and duration of operation. When devices have been discovered, this information is passed over to the Service Discovery Application Profile, Chapter 3, which manages its specific attributes. 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.
There are numerous packet types available. Table 9-26 identifies the most often used packets 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 also 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 9-26. Various ACL packet types are also available; in fact, seven types including the DM1 type are attributed to carrying user-specific data. These include DH1, DM3, DH3, DM5, DH5 and AUX1. Similarly, Table 9-26 summarises their support in this profile.
Table 9-27 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 Fax Profile has many similarities to the Dial-up Networking Profile; both rely on the Generic Access Profile, the Serial Port Profile and use AT Commands to enable control and dialling.
The existing usage models allow a DT to make use of the service provided through a GW; these are the two roles that are defined by this profile.
The Fax Profile provides the ability for a DT and GW to create a wireless bridge, thus creating a two-piece Bluetooth protocol stack.
Bluetooth bonding is mandatory for this profile; failure to provide such support would result in a failed Bluetooth connection.
The DT is the initiator of the Bluetooth relationship.
There are no specific master or slave roles, although the DT will be the master as it initiated the connection.
The DT discovers available GWs in radio range by performing an inquiry.
A GW may restrict discoverability to further prevent unauthorised access.
The Bluetooth Passkey is used as part of the authentication and encryption process.
The service class record must depict the fax availability in the GW.
A service discovery record is generated detailing the parameters, which apply to that specific service.
Modem and driver emulation are provided above RFCOMM making use of the serial port emulation model.
The GW must support the use of dialling and control, where AT commands are issued to enable dialling and control.
A SCO link may be established if it is required and if the GW and DT support this capability.
A connection would be established regardless of the success of the SCO connection.
[1] The wireless bridge concept is not new, in as much as existing technologies, such as infra-red (IR), provide the ability to communicate with a GW in much the same way as Bluetooth enabled devices. The advantage of a Bluetooth-enabled device is that it does not have to be in line-of-site with the DT. A mobile phone, for example, may be placed in a pocket or kept in a briefcase.
[2] The double-click and right-click operations refer to a mouse that is connected to your client device (in this example, a PC or notebook computer running a Microsoft Windows operating system) and where both operations trigger the same method of access. It is noted that an operation may vary from device to device and, as such, the number of buttons may vary. Indeed, no mouse may be connected. The example just draws your attention to how it may be possible and acknowledges that implementations may differ.
[3] The flexibility of the Bluetooth protocol stack, in particular the various HCI and LMP commands available, allow various methods of creating a successful ACL connection. The text refers to one particular example of a connection set-up.
[4] L2CAP payloads are passed directly onto LMP when implemented on a hostless system.