The evolution of the DUNP (and its associated profile, the LAN access profile) is interesting. Originally there was a single Internet bridge profile, just as there is an Internet bridge usage model. As the marketing requirements document (MRD) was refined and additional thought was given to the topic of network access, two types of network access distinguished themselves. The MRD defined the concept of data access points and split these into two types: wide area network access, using modems, satellites, cellular networks and the like; and local area network access, using an access point to directly connect to an Ethernet, token-ring or similar LAN.

At first the Internet bridge profile attempted to cover both of these types of data network access. It later became clear that the two scenarios, while similar from an end-user perspective (and thus both considered to be part of the Internet bridge usage case), had different technical underpinnings and would probably require quite different implementations in devices. Thus the Internet bridge profile (like the three-in-one phone profile discussed in Chapter 13) was split into its two constituent parts: dial-up networking (now the DUNP) and LAN access (discussed below). The DUNP was developed by the telephony control task force within the SIG, since much of the profile dealt with telephone call control (recall that at this time a telephony control protocol called TCS-AT still existed—Chapter 10 discusses this topic further—and much of the DUNP deals with AT commands over RFCOMM to set up and manage the modem service). The LAN access profile, on the other hand, was developed by the SIG's networking task force, since telephony was not really relevant to that profile. Even though both of these profiles spring from a common usage model and they do have some technical similarities, they also have some differences at the implementation level.

The DUNP defines device roles for a gateway device and a data terminal device. The gateway is the device that offers a modem service to allow connection to the network that is being accessed; gateways typically are modems or mobile telephones. The data terminal is the device, usually a computer of some sort, that is using the modem service of the gateway device to access a data network. While dial-up networking is usually thought of from the viewpoint of the data terminal device accessing a network, the DUNP also notes that the reverse situation that allows the data terminal device to be dialed up via the modem device is also supported. Normally the data terminal device wishes to obtain access to a network, rather than to permit dial-up access to itself, although there are cases where the DUNP might be used for incoming connections. These gateway and data terminal device roles have no implications for the baseband master or slave roles.

Recall that while we consider the DUNP to be part of a networking group of profiles, it is a derivative of the serial port profile. The RFCOMM protocol is used to transport modem AT commands between the data terminal (computer) device and the gateway (phone or modem) device to establish and manage the connection to the network. The DUNP identifies a small subset of standard AT commands as defined in the ITU-T V.250 standard [ITU99] that are used to set up and manage the modem functions of the gateway device.

The DUNP addresses optional support for audio feedback. While its primary purpose is to support data calls, the audio capabilities of Bluetooth wireless communication permit a richer emulation of a wireline modem call by allowing for audio feedback. If audio feedback is supported, the modem tones associated with the call can be transmitted back to the data terminal device for playback through its audio output channel. Audio feedback can provide information to the end user about the call's progress, allowing the "squeaks and squawks" that many users have become accustomed to with dial-up networking also to be present, if desired, when using Bluetooth wireless links. The service record of the gateway's modem (dial-up networking) service indicates whether or not audio feedback is supported, so SDP can be used to determine whether or not this feature is available when the connection between the gateway and data terminal is established. Typical DUNP operation, including optional audio feedback, is depicted in Figure 15.1.

Figure 15.1. Typical dial-up networking profile operation. Note that the gateway device also could be a wireless modem access point connected to a wired telephone network.

Security in the DUNP is handled at several levels. Support for baseband pairing is mandatory, although it need not be used for every connection. However, since the most common case of dial-up networking with Bluetooth technology is likely to be a computer using a mobile phone to access the network, charges are likely to be incurred from the phone service provider for the wide-area cellular connection of the phone call. Thus pairing is advisable, since it can restrict use of the phone's modem service to known and trusted devices. A phone's owner may wish to make his phone's modem service available to his own computer(s) but probably not to anyone else's computer that happens to be in range. The DUNP also calls for the use of baseband authentication and encryption functions. At an application level, additional authentication such as a user identifier and password are likely to be required to access the network, once a connection to it is established.

The intent of the DUNP, like that of most other serial profile family members, is to enable legacy applications to take advantage of Bluetooth wireless links for existing functions. Dial-up networking is a common usage scenario, with many applications available for using modems to access networks. Through the use of RFCOMM serial port emulation and a minimal subset of well-known and standard AT commands, the DUNP provides dialer applications with a functional interface that is virtually identical to that which they use in the wired world. With the use of Bluetooth adaptation software, as described in Chapter 5, it should be possible for legacy applications to conform to the DUNP with little, if any, change.

Once dialing software has established the connection to the network, multitudes of applications that use standard networking protocols (like TCP/IP, HTTP, FTP and so on) can execute using the dial-up network link and the services available in the network. Hence the DUNP enables other applications such as browsers, e-mail and the like.

For more information about how the DUNP is used and how it relates to the LAN access profile, discussed below, see the following section "DUNP and LAP Compared."

As noted in the DUNP discussion, the LAP was originally part of a single Internet bridge profile. When that profile was split, the LAP was developed by the SIG's networking task force. Even though the LAP and the DUNP both describe a method of realizing the Internet bridge usage case, they have some technical differences, because dial-up networking is a bit different from direct LAN access using PPP.^[2]

The networking task force in the SIG was at one time called the TCP/IP task force, since its original mission was to define methods for traditional IP networking in Bluetooth environments. The group later decided that a more appropriate name for the task force was Bluetooth networking, since not all of the networking considerations were related to TCP/IP, although clearly IP networking is especially important. Unlike most other task forces, this group did not define any protocols in the stack but rather investigated ways to use traditional networking protocols, such as those defined by the IETF, over Bluetooth links. Thus there is no corresponding protocol stack layer in the core specification for the LAP. It is only this profile that defines LAN access with Bluetooth wireless communication, and it uses the RFCOMM protocol and the IETF's PPP. The LAP forms an important foundation for more robust future networking profiles, and it has always been considered to be an initial solution, but not an exclusive solution, for Bluetooth networking.

At first glance, it might appear that the solution developed by the networking group for LAN access is not as robust as might be expected, especially for peer-to-peer communication in LAN environments. However, the group's choice was not made lightly. This direction was chosen after long deliberations that considered the feasibility of other solutions, the time to market, and the time constraints for developing and publishing the version 1.0 specification. Peer-to-peer communication in purely ad hoc, wireless networks is an area that is not yet mature. While many industry and academic efforts are underway, there is no robust, fully tested, widely accepted method for achieving it, especially one that is suitable for resource-constrained devices like many of those used in Bluetooth wireless communication.

The SIG's networking group seriously contemplated IP networking issues like address assignment, name resolution, default router assignment, and so on. In an ad hoc network with no infrastructure services such as DNS and DHCP, these and other necessary network support operations present unique problems. It became apparent that a solution to these problems could have a scope larger than just Bluetooth piconets. Had the SIG attempted to develop a general solution, it very likely would not have aligned with other industry activities that are proceeding toward maturity; furthermore, any such solution would have required prohibitive time investments in development and testing. Thus, a general solution that addresses the difficult issues associated with ad hoc IP networking (and that would enable several aspects of the conference table usage case described in Chapter 3) was deferred until after version 1.0. Instead, the networking group focused on developing the PPP-based LAN access solution—for two reasons: (1) PPP is a widely used Internet standard that addresses host configuration and preparation for IP communications; and (2) many devices, including popular PDAs, today support IP communications over PPP for dial-up access to IP networks. Hence, a large number of computing devices can support the Bluetooth LAN access profile without modification to their installed networking stack—a consideration that should not be overlooked.

Support for more general ad hoc peer-to-peer networking is an issue revisited by the SIG, as discussed in Chapter 16.

The LAP defines device roles of a LAN access point and a data terminal. The LAN access point (which is just different terminology for a data access point; we use the latter term) is the device that exports PPP server function and is connected to a LAN, which might be Ethernet, token-ring or some other type of LAN.^[3]The data access point is typically envisioned as a small "wireless plug"^[4]connected to the wiring infrastructure of the LAN, and thus often mounted on a wall very much like a cabled data access point would be, perhaps in an office, a conference room, an auditorium or even in a home. The data terminal is the client of the data access point and thus contains PPP client function, which is used to establish the connection with the data access point that in turn permits access to the LAN. In the most general case, there is an association between these device roles and the baseband master and slave roles. Much as a cordless telephony gateway must be a piconet master (as described in Chapter10 and Chapter13), a data access point must also assume the master role if it supports more than one data terminal client. In the case of only one data terminal client (for example, when the data access point is dedicated to a single client or when the LAP is used for PPP networking between two computers), it does not matter which device assumes the master role, but in general the data access point is assumed to be the master in LAP applications.

The use of PPP is key to the LAP. PPP is ideally suited for the connection between the data access point and the data terminal. IP network traffic (as well as other network protocols) can flow over the PPP link. PPP is also designed for use over serial connections, and thus within the LAP, PPP operates over RFCOMM.

The LAP is essentially a procedure for establishing a PPP connection between the data access point and the data terminal. Once the PPP connection is established, conventional IP solutions can be employed for networking functions such as obtaining an IP address. Standard IETF protocols can then flow over the PPP connection to access services on the LAN, much as in dial-up networking. Unlike dial-up networking, though, the PPP connection in the LAP is established directly over a packet-oriented data link and thus does not require modem functions and associated AT commands to establish the connection. Typical LAP operation with a single data terminal is shown in Figure 15.2; note that there could be multiple data terminals if supported by the data access point (in this case, each has its own separate Bluetooth transport and PPP connection to the data access point, and the data access point must be the piconet master). Figure 15.3 shows the special case of the LAP between two individual computers.

Figure 15.2. Typical LAN access profile operation. Note that data access points optionally may support multiple data terminal clients.

Figure 15.3. LAN access profile operation for networking between two devices. Either device can assume either role (data terminal or data access point).

The LAP has an interesting attribute that merits discussion. The service record associated with the PPP/RFCOMM service makes use of the ServiceAvailability attribute defined by SDP. The LAP is the only version 1.0 profile that specifies use of this attribute, although as a universal service attribute, it could be used by any service. A data access point could support many data terminal clients, and the ServiceAvailability attribute is used to indicate the degree of utilization of the data access point (how "busy" it is with current clients). Thus in the case where multiple data access points exist for a given LAN (perhaps in an auditorium or large conference room), a data terminal can perform SDP transactions with each data access point to locate one that has capacity to handle additional clients. The SDP specification defines the ServiceAvailability attribute generically without specifying particular values to indicate degrees of utilization. The LAP specifically defines values for ServiceAvailability for data access points,^[5] with a percentage range that roughly corresponds to the number of possible active slaves in a piconet of which the data access point is master.

Security is a significant consideration of most networks; hence the LAP defines a high degree of security for the PPP connection that permits access to those networks. The LAP mandates authentication using device pairing, which can help to ensure that only authorized devices gain access to the network. This is important for corporate and other private networks; the network owner may not wish to grant network access to any device that happens to be within range of a data access point (that device might belong to a visitor who is not authorized to access the private network). PIN-based authentication is required to authenticate with a data access point, so network access could be granted by divulging the PIN to the prospective data access point client. For more public data access points where it may be desirable to allow almost anyone to use the LAN, the PIN could be publicized to all persons who ought to have access, or—as the LAP specifies—a default, zero-length PIN could be used, effectively permitting universal admission to the data access point and hence to the LAN. In this latter case, additional security measures could be necessary to restrict access to services on the LAN or to other networks that may be accessible from the LAN. The LAP also insists upon the use of encryption of all the traffic on the Bluetooth wireless link between the data terminal(s) and the data access point. In addition, other higher-layer security mechanisms, including various PPP authentication schemes mentioned in the LAP, may be used to authenticate and authorize users of network resources.

As with the DUNP, the motivation for the LAP is to access networks, primarily (but not exclusively) IP networks. So if middleware exists for PPP, along with a requisite IP stack, the same sorts of applications noted for the DUNP can execute over the LAP's PPP link: browsers, e-mail, FTP file transfers and so on. IP networking stacks and applications that use them are common in many devices, and these legacy applications are enabled for use with Bluetooth wireless communication via the PPP link defined by the LAP. Furthermore, other protocols can operate over the PPP link. Notable among these is WAP. The specification does not include a WAP profile; however, the use of a Bluetooth PPP/IP connection as a bearer for WAP traffic is described in volume 1 of the specification, and that part of the specification contains some information similar to that found in profiles. In particular, SDP service records are defined for WAP interoperability, and the PPP connection as defined by the LAP for IP traffic is exactly what is used for WAP network access.

In the next section we offer additional information on how the LAP is used as well as a comparison of the LAP usage versus that of the DUNP.

None of the published Bluetooth usage scenarios address fax function. The MRD^[8] makes only two passing references to fax usage cases. So rather than having an associated usage model with a catchy name, the FaxP simply tells how to do wireless faxing using Bluetooth links. While we treat the FaxP here as a networking profile, its heritage is in the telephony-based profiles. As already noted, the DUNP and LAP were originally parts of a single Internet bridge profile. When the DUNP was made into its own separate profile, it initially included fax scenarios as well as dial-up data networking (this is evident from the many similarities in the structure and content of the two profiles, as well as the references to fax calls that remain in the DUNP). Soon thereafter, the FaxP was also split into its own profile based upon the considerations above that make fax its own distinctive usage case.

At about the same time that the FaxP was split into a separate profile, there was significant debate about the fax classes that could and should be supported over Bluetooth links. We do not present a detailed discussion of fax technology here,^[9] but we do describe enough about fax classes to frame the issue regarding fax in Bluetooth wireless communication. In what is called Group 3 fax,^[10] there are three protocols of interest within the FaxP context: class 1, class 2.0 and class 2. The former two are ITU-T standards while the latter is an industry de facto standard, and indeed class 2 and class 2.0 are different (although similar, and much of the following discussion of class 2.0 generally applies to class 2 also). The debate about fax class support in Bluetooth environments centers around timing requirements of these fax classes. A difference between class 1 and class 2.0 fax is the functional split of two major components of fax transmission: call control and image processing. In the typical FaxP usage case, a computer works with a mobile phone to send and receive fax information, similar to the typical DUNP case. In this typical configuration, both image processing and call control functions are performed by the computer for class 1 fax; whereas for class 2.0 the phone manages call control with the computer handling image processing. There was some concern within the SIG that the Bluetooth link between the computer and the phone could cause delays sufficient to violate some fax timing requirements. These concerns are most pronounced with class 1, where the computer must manage the call control functions over the Bluetooth link in addition to the image-processing load (the division of function between devices in class 2.0 makes it somewhat less susceptible to these timing violations). There was a proposal within the SIG to make support for class 1 fax optional based upon these concerns. After much study and debate, the SIG finally chose to mandate support for at least one of the three classes (1, 2 or 2.0), without specifying any particular one as mandatory to support, and without directly addressing the issue of timing requirements with regard to these classes (these considerations are left to the implementer, with the guidance of the Bluetooth specification and fax standards).

It is not surprising, given the history of profile development, that the FaxP is quite similar to the DUNP. The examination of the FaxP here is abbreviated, since much of the DUNP discussion also applies to the FaxP. The FaxP defines the same device roles as the DUNP, namely a gateway device (typically a mobile phone or a fax modem) and a data terminal device (typically a computer). These device roles have no bearing on the baseband master and slave device roles. Like in the DUNP, both outgoing calls (fax send) and incoming calls (fax receive) are permitted.

Since the FaxP is a derivative of the serial port profile, AT commands are used over an RFCOMM link for call control. The AT command set used is dependent upon the fax class(es) supported. Audio call progress feedback is optional and is handled in the same manner as with the DUNP. Typical FaxP operation is shown in Figure 15.6; note that the gateway device also could be a modem.

Figure 15.6. Typical fax profile operation.

The FaxP SDP service record is used to determine whether or not the optional audio feedback support is present, as well as to determine the fax class(es) supported, although the latter also can be determined using AT commands.

Because fax transmissions are generally considered reasonably secure, the FaxP mandates a relatively high level of security. Authentication and encryption are required, as is support for bonding and at least one of security modes 2 or 3 (described in Chapter 12).

Clearly the FaxP is another example of a profile to enable existing usage scenarios to be accomplished by existing applications in a wireless fashion. Fax technology is quite mature and is widely used today. Through the use of modem and serial port emulation, the FaxP is designed to allow legacy fax applications to operate over Bluetooth links with little, if any, change.