The GW as a mobile phone should be initially enabled, where parameters such as limited discovery and range can be defined; this would help 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 instances 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. Previously, we touched upon the ability of the GW to only accept a connection from one DT at any time. This feature restricts use from other intruders—suffice to say that if it is being used by you, then there is a strong possibility that it is not being used by anyone else.

Once the user has the ability to connect to a device, he or she may continue to make use of the services it provides. By using a double-click ^[3] or right-click, the user begins the process of connecting to the dial-up networking service. This is shown in Figure 8-7.

Figure 8-7. 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 which is offering dial-up networking capabilities. (Courtesy of TDK Systems Europe.)

Prior to using the GW, a user may be required to enter a Bluetooth Passkey. In Figure 8-8, we show the user being prompted with a dialog box requesting the entry of a passkey.

Figure 8-8. The user is requested to enter his or her passkey to authenticate with the GW device.

Underlying all of this high-level user interaction is a sequence of events, which lead up to the moment of connection. Figure 8-9 illustrates the message sequences that typically occur during a connection set-up. Other implementations may differ slightly, depending upon the user’s specific requirements. ^[4]

Figure 8-9. The events which takes place during a connection with a DT and a GW.

During connection establishment, the user may be informed of the dial-up as it progresses. In Figure 8-10, we show the user being informed of the progress of the dial-up connection. In Figure 8-11, we now illustrate that the user is being prompted to enter a username and password; this is to comply with PPP authentication.

Figure 8-10. The connection has successfully progressed to the next level; here, the user is now informed of the GW actually dialling the service. (Courtesy of TDK Systems Europe.)

Figure 8-11. The dial-up connection was successful, and now the user is prompted to enter their username and password. (Courtesy of TDK Systems Europe.)

In Figure 8-12, we now show that PPP authentication is being verified with the remote service; Figure 8-13 shows the registering of the connected computer onto the remote network.

Figure 8-12. The username and password for PPP authentication is being verified by the remote network. (Courtesy of TDK Systems Europe.)

Figure 8-13. PPP authentication was successful. The computer can now be registered with the remote network. (Courtesy of TDK Systems Europe.)

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 8-14, the user is able to double-click or right-click on the connected device’s icon and select disconnect from the pop-up menu to terminate the connection.

Figure 8-14. Right-clicking the device’s icon causes a pop-up menu to appear offering the ability to disconnect. In this illustration, we can see the user disconnecting from the dial-up service which, in turn, will disconnect the GW. (Courtesy of TDK Systems Europe.)

Other forms of disconnection may occur if the quality-of-service (QoS) can no longer be maintained by the remote service; an instance of this specific example may occur when the remote network to which the GW is connected is unexpectedly lost. It is important to remember in such a situation that the appropriate information about the current connection must be conveyed to the user, since the DT may offer a reconnection at a later time.

One other such instance of a terminated connection may occur when a connection is lost due to the DT moving out of range from a GW. Section 8.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 8-15, 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 8-7). A seamless reconnection can be achieved if both the DT and GW remember their previous respective sessions, where the reconnection time can be dramatically reduced.

Figure 8-15. The user has chosen to query the device status. (Courtesy of TDK Systems Europe.)

The GW undertakes a series of events that enable a DT to successfully access its service; Figure 8-16 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.

Figure 8-16. The events that place during an incoming connection from a DT.

The GW would refuse a connection from a DT in such an instance where the GW refuses to accept bonding, or when an incorrect passkey has been entered. A connection may also be refused if the PPP authentication was unsuccessful.

The Dial-up Networking Profile relies upon the capabilities provided by the Generic Access Profile, Chapter 2. In our earlier chapter we learned that a level of basic functionality is achieved through establishing a set of rules and procedures. These rules govern the behaviour of such devices and relate to their connectivity, discoverability and common characteristics at the user interface level, with some additional emphasis provided for security. Commonality is established between products through the use of these rules and procedures, resulting in a positive user experience.

Now let’s take a look at the behavioural aspects of Bluetooth-enabled devices as outlined by the Generic Access Profile, Chapter 2.

In Table 8-2, the basic set of procedures is illustrated identifying functional expectations which, in turn, govern its operation. These procedures help determine the context within which the device would operate.

In Table 8-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.

Security is an important aspect for Bluetooth-enabled devices. Table 8-4 identifies the security requirements for this profile. The Generic Access Profile, Chapter 2, taught us 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 at various stages of connection. In this instance, the profile mandates that support should be provided for at least Security Mode 2 or 3.

Finally, in our consideration of the basic rules and procedures that are required from the Generic Access Profile, we consider the idle mode procedures, which outline behavioural characteristics when DeviceA chooses to initiate them against DeviceB. The procedures that are listed in Table 8-5 provide a clearly indicates 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. This, in turn, instigates the pairing process, that is, the generation of the link keys, where subsequent authentication can then occur. In summary, there are a specific set of events associated with a procedure and, in the Generic Access Profile, Chapter 2, we further explore how each procedure is conducted.

The provision of a well structured FHS packet is the mechanism for device discoverability and this is shown in Figure 8-18. This packet is used to identify the remote device, where information such as 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. During the discovery mechanism the CoD is used to learn more about the type of device and what it may be capable of providing. This structure of information is depicted in Figure 8-19 and is made up of 3 bytes (or 24-bits as shown). The following sections now consider the Dial-up Networking attributes, which will ultimately make use of the Service, Major and Minor Device Classes fields.

Figure 8-18. The structure of the FHS packet used only for reference to illustrate the position of the Class of Device structure.

Figure 8-19. The structure of the class of device, illustrating the Minor Device, Major Device and Service Class fields and their respective lengths.

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 in order to learn of the devices in radio range. A client would then make use of an application, which would embody 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 8-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 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, which, in turn, instruct the server to carry out its operation. The various request and response PDUs required are shown in Table 8-10, where features indicated are described as mandatory (M), optional (O) and excluded (X).

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 8-11 identifies a GW device and provides a list of AttributeIDs, which ultimately identify the service for the Dial-up Networking Profile. A minimum of two attributes are required to make a service record; these are ServiceRecordHandle, and a 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 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 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 8-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 our earlier Section 8.5.1.1, Generic Access.

As part of the service record, the dependent underlying protocols are also identified. The local device retrieves this information in order to fully understand the exact requirements needed to fulfil the service. The Dial-up Networking Profile is dependent on the protocols as shown in Table 8-13, which also shows their associated UUID values.

The conceptual and functional nature of RFCOMM was introduced in the Serial Port Profile, Chapter 6. In it, we 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 Dial-up Networking 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.

ServiceClassIDList 
  ServiceClass0 
  ServiceClass1 

ProtocolDescriptorList 
  Protocol0 
  Protocol1 
    ParameterFor1 

BluetoothProfile
DescriptorList 
  Profile0 
    ParameterFor0 

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).

In this section we highlight the specific features that are required to realise a compliant Dial-up Networking Profile. Table 8-14 and Table 8-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.

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 ^[6] (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; it also provides 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 8-18, we summarise the broad capabilities that are expected from L2CAP. 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 at the L2CAP layer.

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 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.

In providing general error management, devices that operate mandatory procedures during interoperability must either acknowledge their support or provide the initiator with a reason for procedure failure. The LMP_Detach Protocol Data Unit (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 next section, we take an opportunity to explore the dependencies that make up the Dial-up Networking Profile, where we provide a narrative of the capabilities that are expected at this level. In Table 8-23, we identify the capabilities that are required from this layer and, in the following sub-sections, discuss the specific procedures in more detail.

The Link Controller (LC) layer is the lowest layer depicted in the profile dependencies and has responsibilityfor 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 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. The following subsections provide clarity with regard to the capabilities that are a requirement at the LC level for the Dial-up Networking Profile. In our understanding of the dependencies, we begin by examining the supported capabilities further. 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.

PPP is typically used for communication between two devices that use a serial interface; it is well described in RFC1661. In the Dial-up Networking context, PPP use is implied with the dial-up networking application. The two applications at either end of the connection will manage the communication and negotiations accordingly.