In Figure 3-5, we illustrated the components that made up our local and remote device protocol stack. In the illustration, you may have noticed that an SDP Client and SDP Server are depicted. In this context, they interact with each other, where the client requests and the server responds; we illustrate this concept in Figure 3-7.

Figure 3-7. In this example, the client (notebook) and the server (printer) use the response-request paradigm to exchange information about the one service being offered.

In the example, the client requests the services from the remote device, where it informs the client that it has one service available. Devices are capable of supporting many services and, as such, we can see in Figure 3-8 that the client requests information about the services that the remote device can support and the SDP server provides a response with multiple services attached.

Figure 3-8. In this example, the client (notebook) and the server (mobile phone) use the response-request paradigm to exchange information about the many services being offered.

The SDP client and the local device communicate with the SDP server of the remote device. Accompanying the SDP server, a Service Discovery Database (SDDB) is used to store information about the services that the remote device is capable of providing. The database is made up of a series of Service Records, which we will discuss in more detail later on. These service records contain detailed information, which enables the local device to know how to use the service on offer. Supplementing this core capability, the owner of the remote device may select how the client should use a service.

In Figure 3-9, the user is capable of configuring the service to use authentication or encryption. When a local device then uses this particular service, as in the example provided, we can see the user being prompted to select changes for the File Transfer service. The user will have to undertake authentication and encryption procedures before using that particular service.

Figure 3-9. Service Records are created for the services that a device is capable of providing. Supplementing these core capabilities, information relating to the requirements of Authorisation, Authentication and Encryption are also stored.

Service Attributes are used to describe the characteristics of a service that should be sufficient for a local device to use. They essentially comprise two units: an AttributeID and an AttributeValue, as we can see in Figure 3-10. The AttributeID is a 16-bit unsigned integer, which is used to uniquely identify the service attribute. In Table 3-2, we provide a list of common service attributes and their associated AttributeID values that are commonly used throughout this book. The AttributeValue is a variable length parameter, where its contents are dependent upon the AttributeID.

Figure 3-10. The structure of a service attribute.

The AttributeValue is constructed using data elements. The SDP interprets the AttributeValue to determine its content, where its structure is made up of a header and a data field. In Figure 3-11, we can also see that the Header is further divided into two sections, containing information, which relates to the Type and Size descriptors. The Type descriptor is made up of 5-bits and is placed at the most significant section of the Header byte where it is used to help identify the structure of the following data elements; for example, with an AttributeID of ServiceClassIDList, what follows is a Universally Unique Identifier (UUID). However, with an AttributeID of ServiceName, a Text string would follow. In Table 3-3, we can see the number of available types that can be used.

Figure 3-11. The header is divided into two sections.

In Table 3-4, we identify the Size descriptor, which occupies the remaining 3-bits of the Header byte; this descriptor is contained in the least-significant section. It is used to describe the size of the data represented by the Type descriptor.

Let us pause for a moment and summarise what has been previously outlined. A service is constructed with a series of ServiceAttributes. These attributes are capable of uniquely identifying to a local device what service is being supported by the remote device. In its construction, a series of data elements are used to describe the format of the ServiceAttribute, where an AttributeID and AttributeValue are used. In Table 3-2, we identified a list of common attributes that are often referred to in this book. The AttributeValue is further used to describe the format contained within the data element. In Figure 3-12, we illustrate the encoding of the ServiceClassIDList for Cordless Telephony.

Figure 3-12. The encoding of the ServiceClassIDList for the Cordless Telephony service.

In the illustration, we can see that the AttributeID contains the ServiceClassIDList reference of 0x0001, see Table 3-2. The AttributeValue is constructed to contain two UUID values, which represent Cordless Telephony (0x1109) and Generic Telephony (0x1204). With this type of encoding, the construction becomes twofold: in the first instance, we describe that a data sequence follows, by using the Type descriptor 6, see Table 3-3.

Secondly, our Size descriptor indicates 5; see Table 3-4, which illustrates that the following 1-byte contains the size of the entire data sequence. In the illustration, we also note that our Length is 6-bytes. The encoding of the remaining data sequence now indicates a Type descriptor of 3, which denotes UUID and the Size descriptor indicates that the next 2-bytes contain the actual UUID value.

With a collection of ServiceAttributes, a Service Record is constructed; this record essentially conveys to a local device all the information it needs to know about using the service. Figure 3-13 provides a conceptual structure of a service record. In the following section, we discuss in some more detail the use of service records and how service browsing is achieved.

Figure 3-13. A service record is used to describe the variable collection of ServiceAttributes. This is sufficient information for a local device to understand the remote device capabilities.

In our earlier introduction we provided an illustration, which demonstrated that a device was capable of supporting multiple services, see Figure 3-2. A service record is maintained for each service the device is capable of supporting and, as such, a Service Record Handle is created to uniquely identify a service record.

A minimum of two attributes are required to make a service record, these are ServiceRecordHandle and ServiceClassIDList, where the latter attribute must contain at least one UUID; Table 3-5 provides a list of AttributeIDs, which ultimately would identify the service for the Cordless Telephony Profile.

The ServiceRecordHandle is a 32-bit unsigned integer and is stored on the remote device SDP server. You may recall from Figure 3-5 and our earlier discussion on the client-server model where the local device maintains an SDP client and the remote device manages the SDP server. The SDP server communicates with the Service Record Database, as to the available services it can offer the local device.

When performing a service discovery of a remote device, the client undertakes a series of procedures to learn of the services it supports. Browsing is used to refer to the mechanism that is employed when you seek an unknown or general service is sought. In our earlier discussion, we provided several AttributeIDsthat are used to construct a service record. A generic AttributeID, which is common to all services is the BrowseGroupList attribute, this has a unique value of 0x0005. As with any AttributeID, the associated AttributeValue can be constructed with a data sequence. In this particular instance, the AttributeValue relates to the group to which the service belongs.

ServiceClassIDList 
  ServiceClass0 
  ServiceClass1 

ProtocolDescriptorList 
  Protocol0 
  Protocol1 

BluetoothProfile
DescriptorList 
  Profile0 
  ParameterFor0 

With the intent to search for services on a remote device, the local device constructs a Search Pattern, which is a list of UUIDs. UUIDs are 128-bit values, which have been shortened for use within Bluetooth applications. The shortcut has been provided by first establishing a Bluetooth Base UUID, which is shown in Table 3-6.

The UUIDs that have been presented so far are aliases and take the form of what is referred to as a 16- or 32-bit UUID; 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 a search pattern to be successful, it needs to be converted to the 128-bit notation, since all searches will be compared at this range. In Table 3-7, we illustrate the arithmetic operation, which performs the conversion from the 16-bit and 32-bit representation into the full 128-bit notation.

Earlier, we touched upon the fact that a set of function primitives is established to realise true functionality within SDAP. In an attempt to expand our understanding of the companionship of the profile and protocol, we will begin by looking more closely at how the Service Discovery Protocol is used. Furthermore, we will explore the underlying mechanism that is exposed to the Service Discovery Application Profile, which in turn provides it with its primitive functionality.

A set of abstractions is used to provide and forms the basis of the core functionality. The SDP employs the use of a series of PDUs. The local device retrieves specific information with regards to the services available on the remote device, using a combination request and response PDU.

The profile relies upon the protocol for the request and response functionality and, in turn, the protocol then further relies on its underlying transport mechanism to facilitate the transport of the PDUs. To achieve this, the protocol makes use of the services provided by L2CAP, where the connection-orientated transport service is made available. The L2CAP component then subsequently uses an Asynchronus-Connectionless (ACL) link to take the PDUs over the air.

In Table 3-8, the combination request and response PDUs that are available within the protocol are illustrated, although you must bear in mind that the illustration provided does not represent an Application Programming Interface (API). Higher-level functionality or a user application would be employed to extract the relevant data from the PDU, where it would interpret the data and formulate the appropriate response. As such, the local and remote devices, which form the communicating parties, each have their own user application to fulfill their respective functional expectations.

The SDAP is conceptually positioned above the SDP in a user application on the local device, where it is referred to as the SrvDscApp (or Service Discovery Application). Here, it not only relies upon the protocol, it also embraces the use of a client (SDP client) and a management component; elsewhere in this book, this is commonly referred to as a Management Entity ^[2] (ME) for consistency. This component forms the basis on which discovery effort is coordinated, providing instructions for some certain operational modes, such as an inquiry or a paging state. The placement and existence of such a module remains implementation-specific. The remote device coordinates requests from the local device with the use of an SDP server and a service record database, which contains service records relevant to the services available.

In essence, the profile allows you as a developer to realise an API, which utilises the inherent protocol. The SDAP is therefore capable of providing this primitive functionality through the use of the SDP. We discuss the application perspective in more detail in Section 3.3.1.2, SDP in the Service Discovery Application Profile.

This itself is the minimum functionality you would expect from the profile, but should not be seen as an inadequacy, since it does not restrict the growth of other implementation-specific APIs. Coincidentally, in Part III, The New Profiles, the ESDP: An Overview, Chapter 18, we discuss the Extended Service Discovery Profile (ESDP) and how it fits within the SDAP context.

The SDP PDUs are used to instruct the server to undertake browsing procedures and to retrieve service record information about its services. As we previously discussed, the client and server operate a request and response paradigm. The SDAP will construct PDUs containing information relating to the AttributeID and AttributeValues in turn instructing the server to carry out its operation. Each PDU has a unique value, which are shown in Table 3-9.

In Figure 3-14, we illustrate the structure of a SDP PDU; this is applicable to all SDP_ErrorResponse PDUs. However, a Continuation State parameter is added to the remaining PDUs, since an SDP PDU response may be too large to fit into a single response. The server indicates that the client has only received a partial response and the client re-issues the original request with the ContinuationState copied into the new request to retrieve the remainder of the response.

Figure 3-14. The structure of the SDP PDU.

The ContinuationState is of a variable length and is constructed of two further parameters. The Info Length parameter is the first byte used to indicate the size of Continuation Information parameter. When the request is re-issued, the server is first informed of the size of the ContinuationInformation, which instructs it where it had segmented the original response. The InfoLength parameter is set to zero to indicate that the response was completed in one transaction. We can see the structure of the PDU with the ContinuationState parameter as shown in Figure 3-15. You will also notice from our illustrations that a TransactionID parameter and a ParameterLength are also shown. The former parameter is a 16-bit unsigned integer used to identify the request PDU and is selected at random by the client, but it must be different to any other pending request. The TransactionID in the response PDU will be used to match the associated request. The ParameterLength is a 16-bit unsigned integer and is used to accurately describe the entire length of the PDU.

Figure 3-15. The structure of the SDP PDU with the ContinuationState parameter.

During normal operation the client and server exchange information with a request-response operation. However, if an incorrectly formatted request is sent to the server, it will respond with SDP_ErrorResponse. In Table 3-10, we can see the PDU format with its set of parameters.

The ErrorInfo parameter is implementation-specific, whereas the ErrorCode parameter attempts to provide a reason for the failure. In Table 3-11, we can see the list of errors that are used to describe the reason for failure.

In Table 3-19, we have identified that Connection-orientated Channels are mandatory, whereas Connectionless Channels are excluded; this type of channel is aimed at broadcasting, where all devices may be targeted. L2CAP uses PDUs to transport connection, signalling and configuration options, which will be discussed 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 3-20.

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 3-21 identifies these values and the corresponding protocol they represent. The value of 0x0001 (SDP) 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 3-22 illustrates the range of Channel Identifies (CIDs) that are used to identify the channel type. As we can see in Table 3-19, 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 a 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 SDAP.

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 3-19, we have identified that the MTU and Flush Timeout parameters are mandatory, whereas the QoS is optional.

The default MTU setting for the signalling channel is 48 bytes, whereas other channels may be capable of transferring larger payloads; essentially the MTU determines the size of payloads that are capable of being exchanged between two devices. 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 SDAP uses the default value of 0xFFFF.

As we have already mentioned, the QoS configuration is optional, but if it is used during an L2CA_ConfigReq request, then the best effort service is established as a default; the available services that are supported for an L2CAP channel are shown in Table 3-23. However, if the QoS service is set at Guaranteed, then parameters such as 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 3-24 summarises the broad capabilities that are expected from the LM and in the table you will notice procedures are marked with M (Mandatory), O (Optional), X (Excluded), C (Conditional) and N/A (Not Applicable); 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.

Authentication and encryption in this profile is not necessarily mandated. However, if the remote device imposes such restrictions on the local device, it is expected that both devices will provide support. If a device does not support such a procedure, then the error behaviour as previously outlined must be adhered.

Table 3-27 summarises the broad capabilities that are expected from the LC and in the table you will notice features are marked appropriately; this will determine what is expected from the features at the LC.