Both the Basic Printing and Imaging Profiles depend upon the functionality offered to us by the underlying Generic Object Exchange Profile (GOEP). You may recall that the GOEP establishes a level of basic functionality, abstracted from the Object Exchange Protocol (OBEX). These basic set of features and procedures establish the functionality already offered to us in the Object Push, Chapter 12, File Transfer, Chapter 13 and Synchronisation Profiles, Chapter 14.
The Basic Printing and Imaging Profiles use the inherent push and pull capabilities that are provided in the GOEP. Using the basics of this functionality, we can then realise simple, but effective usage models, which we will discuss later in this chapter.
In Figure 19-1, we illustrate the components that make up the OBEX functionality. At the upper-edge of the OBEX component, implementers will establish function primitives in the form of an Application Programming Interface (API); you may recall from the Generic Object Exchange Profile, Chapter 11, we had a very similar discussion. In the same way, other OBEX-related usage models would utilise an API, so too will the Basic Printing and Imaging Profiles.
Figure 19-1. The various protocols that form the building blocks of the Object Exchange specific usage models. It is at the upper-edge of the OBEX component that function primitives are created which, in turn, will be used by the higher-applications to realise the usage models.
You will find that generic procedures are established for all devices during interoperability. Furthermore, the behaviour of such devices is governed with simple rules that relate to the methods of sending and retrieving data, initialisation and certain characteristics with regard to their discoverability. It is these features and procedures that are used to establish commonality between products, which will ultimately achieve a cohesive user experience.
Bluetooth enables the ad-hoc nature of connecting to devices with ease and transparency. The Basic Printing Profile adds yet another usage model to its already incredible portfolio. This profile allows a user to create an ad-hoc connection to a Bluetooth-enabled printer which, in turn, enables all types of devices, such as notebooks, Personal Digital Assistants (PDAs) and mobile phones to send a variety of documents to a printer.
In Figure 19-2 and Figure 19-3, we illustrate the scenarios that are available to the Basic Printing models. In the illustrations, we demonstrate that a notebook, PDA and mobile phone are all capable of communicating to a Bluetooth-enabled printer. In Figure 19-4, we show a printer server product, which in turn connects the printer to a network.
Figure 19-2. The new Basic Printing Profile enables notebook users to interoperate their devices with a Bluetooth-enabled printer.
Figure 19-3. The new Basic Printing Profile also enables mobile phone and PDA users to interoperate their devices with a Bluetooth-enabled Printer.
This section considers our existing usage model through scenarios that may be typical for the Basic Printing Profile. We begin by exploring the existing model where a notebook, mobile phone, PDA or similar device communicates and establishes a connection with a Bluetooth-enabled printer.
Figure 19-2 and Figure 19-3 illustrate our existing usage models. The role of the notebook acting as a sender initiates a one-to-one communications link with the Bluetooth enabled printer device. The Basic Printing Profile usage model prescribes short-range and ad-hoc communication typically found in an environment where individuals wish to quickly and transparently print documentation.
The printer may be capable of supporting a variety of formats, which include emails, plain or formatted text, structured information, such as vCard and vCalendar, and a variety of downloadable information from an intranet or from the Internet.
The Basic Printing Profile provides two new roles: a Sender and a Printer. The Sender device is capable of pushing data objects to the Printer, whereas the Printer provides the facility to allow the Sender device to push the data objects. In this context, a data object refers to a document type, which we will discuss in more detail later.
In our introduction, we touched upon the notion that a set of features and procedures exist to help govern the operation of Bluetooth-enabled printer devices. At the heart of this profile, the GOEP establishes core capabilities that are realised in the Basic Printing Profile. A task such as object push takes place between the sender and the printer, where documents can then be printed.
There are no fixed master-slave roles. This allows either device the freedom to initiate and terminate a connection, although typically the sender will initiate the primary connection, where inquiry and device discovery procedures are undertaken. Participating devices in this profile must be required to perform bonding, pairing authentication and encryption when requested to do so. Their use within this profile is optional. Printers should not engage OBEX authentication if the sender device does not have a user interface. In general, OBEX authentication should not be supported. In Figure 19-5, we illustrate the specific Bluetooth protocol stack components that are dependent upon a compliant profile.
Figure 19-5. The components of the Bluetooth protocol stack are shown illustrating the newer components of the Basic Printing Profile.
In Table 19-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 Figure 19-6, we provide a conceptual illustration representing the dependencies that make up the Basic Printing Profile; the areas that are shaded are relevant to this profile. As you can see the 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.
A printer device is capable of supporting four modes of operation, which are illustrated in Table 19-2. You will also notice that these modes are depicted as Optional (O) or Mandatory (M). An administrator who wishes to restrict or provide open access to the printer services may configure these modes of operation. In Table 19-3, we illustrate the types of printing services that are available.
Table 19-1. The list of behavioural characteristics that are typical for this profile.
|
CONFIGURATION |
ROLE |
DESCRIPTION |
|---|---|---|
|
DeviceA |
Sender |
This device is capable of pushing data objects to the Printer. The sender establishes a relationship with the server before data objects can be sent; the sender will typically initiate the connection. |
|
Initiator |
This configuration describes the device that instigates the original connection or the device that wishes to initiate communication over an existing link. | |
|
DeviceB |
Printer |
A printer provides object exchange capability, which in turn allows sender devices to push data objects to the printer. This type of device would typically accept connections from the sender. |
|
Acceptor |
This configuration describes the process of the device accepting the initiated communication from DeviceA. |
The Basic Printing Profile provides an optional configuration capability to allow users to control and select printing features. Using a Reflected User Interface (RUI) for Bluetooth-enabled printers, documents and other objects can be controlled or their current printing status can be tracked. This method applies to both direct and reference printing services.
Similarly, administrators may use the RUI to place the printer into one of the modes as illustrated in Table 19-2. In Figure 19-7, we illustrate a sample interface, where in this instance a user has control over the object he or she is about to print.
Figure 19-7. The screen shot shows the typical options that are available to a user when he or she wishes to print a document.
Table 19-2. The list of modes that a printer device is capable of supporting.
|
MODE |
SUPPORT |
DESCRIPTION |
|---|---|---|
|
Offline |
O |
This mode may describe the printer as non-discoverable or in a state where it cannot be accessed. |
|
Private Online |
O |
A printer device operating in this mode would restrict general users from making use of the services. For a user to be able to connect to the device, he or she must know the Bluetooth Device Address. |
|
Public Online |
M |
This mode allows all users to discover and connect to the device using a general or limited inquiry. |
|
Bonding |
M |
This mode denotes that the printer is ready to pair with the sender. |
A user wishing to make use of a printer will undertake inquiry and device discovery procedures to learn of the devices that are in radio range. The service discovery procedure will allow the user to determine if the printer is capable of supporting a Simple Push Transfer. When a user wishes to print a document, he or she will use existing procedures inherent within any word-processing application. The sender device will create a connection with the printer, where pairing and authentication may be required.
Objects are pushed to the printer using the Simple Push Transfer Model. This particular model provides the basic printing capability that any Bluetooth-enabled printer should support, although a printer may also support more complex print operations, as we will learn in the following section.
You may recall from the Generic Object Exchange Profile, Chapter 11, that an OBEX Put operation is used to instigate a push procedure from one device to another. When the sender device wishes to print an object, it will use the Put operation to send the object to the printer. In Figure 19-8, we illustrate the sequence of events that occur for a direct service; in this instance, the sender pushes the entire object to the printer. In a reference service, the sender will indicate to the printer where it can find it. The printer will then locate the object and then print it.
Figure 19-8. The sequence of events that occur when the sender wishes to use the direct service which, in turn, prints a single object.
Table 19-3. The list of modes that a printer device is capable of supporting.
|
SERVICE |
DESCRIPTION |
|---|---|
|
Direct |
The object to be printed is located on the sender device. |
|
Reference |
In this service, the object to be printed is located in another area, such as a network, but the sender device is capable of providing a reference to it. |
A user wishing to make use of a printer will undertake inquiry and device discovery procedures to learn of the devices that are in radio range. The service discovery procedure will allow the user to determine if the printer is capable of supporting a Job-Based Transfer. When a user wishes to print a document, he or she will use existing procedures inherent within any word-processing application. The sender device will create a connection with the printer, where pairing and authentication may be required.
The nature of a Job-Based Transfer is to enable more complex print operations. The sender and printer exchange instructions using the Simple Object Access Protocol (SOAP), which is encoded within an OBEX operation. The mechanisms underlying a Job-Based Transfer Model differ from the Simple Push Transfer Model. The Job-Based Transfer Model is capable of supporting direct and reference printing, but manages more complex object types, as well as providing the sender with control and status capabilities. The activities that ensure a print activity also differ from the Simple Push Transfer Model. Our simple transfer involved an OBEX Put operation, where either the document was handed-over or a reference to the document location was passed onto the printer device. In our Job-Based transfer, a session is first created with the printer device. Once establishing a session with the printer, the sender device can then perform a series of activities using commands which, in turn, instruct the printer.
A session with the printer has to be first established with an encoded SOAP operation within the OBEX Get request. The CreateJob command is used to establish a session with the printer, where the encoded OBEX Get response contains a JobID. In establishing this session, a document can then be sent for printing. This is done using the OBEX Put operation with an encoded SendDocument command. In Figure 19-9, we illustrate the sequence of events that occur for this particular service.
The diversity of Bluetooth-enabled devices that are continually becoming available is accelerating at an amazing rate. With the introduction of many Bluetooth-enabled Printer kits already appearing on the market, we will surely see the emergence of imaging-related products. One such manufacturer has released Bluetooth-enabled digital still and moving cameras. The Basic Imaging Profile also adds another usage model to an incredible portfolio. This profile allows a user to create an ad-hoc connection to a Bluetooth-enabled imaging device which, in turn, enables all types of devices, such as notebooks, PDAs and mobile phones to send and retrieve a variety of image formats.
In Figure 19-10 and Figure 19-11, we illustrate the scenarios that are available to the Basic Imaging models. In the illustrations, we demonstrate that a notebook, PDA and mobile phone are all capable of communicating to a Bluetooth-enabled imaging device.
Figure 19-10. The new Basic Imaging Profile enables notebook users to interoperate their devices with a Bluetooth-enabled imaging device.
Figure 19-11. The new Basic Imaging Profile also enables mobile phone and PDA users to interoperate their devices with a Bluetooth-enabled imaging device.
This section considers our existing usage model through scenarios that may be typical for the Basic Imaging Profile. We begin by exploring the existing model where a notebook, mobile phone, PDA or similar device communicates and establishes a connection with a Bluetooth-enabled imaging device.
Figure 19-10 and Figure 19-11 represent our existing usage models. The notebook acting as an imaging initiator, initiates a one-to-one communications link with the Bluetooth-enabled imaging device. The Basic Imaging Profile usage model prescribes short-range and ad-hoc communication typically found in an environment where individuals wish to quickly and transparently exchange images between Bluetooth-enabled devices.
The usage models extend beyond those illustrated in our earlier figures. A mobile phone is capable of retrieving images from an imaging device, where the image can then be used as a background image or forwarded onto a colleague or friend. In similar scenarios, a notebook device is capable of sensing a digital camera in radio range and automatically retrieves the images that it has stored. Furthermore, a notebook at a conference can be used to pass images to a Bluetooth-enabled projector.
The Basic Imaging Profile provides two new roles: an Imaging Initiator and an Imaging Responder. The Initiator device is capable of initiating an image feature, whereas the Responder provides the capability to respond and support such imaging features.
In our introduction, we touched upon the notion that a set of features and procedures exist to help govern the operation of Bluetooth-enabled imaging devices, which support the Basic Imaging Profile. At the heart of this profile, the GOEP establishes core capabilities that are realised in the Basic Imaging Profile. A task such as object pull and push takes place between the initiator and the responder, where various types of images can be exchanged.
There are no fixed master-slave roles. This allows either device free to initiate and terminate a connection, although typically the initiator device will initiate the primary connection, where inquiry and device discovery procedures are undertaken. Participating devices in this profile must be required to perform bonding, pairing authentication and encryption when requested to do so, but their use within this profile is optional. Imaging devices should not engage OBEX authentication if the initiator device does not have a user interface. In general, OBEX authentication should not be supported. In Figure 19-12, we illustrate the specific Bluetooth protocol stack components that are dependent upon a compliant profile.
Figure 19-12. The components of the Bluetooth protocol stack are shown illustrating the newer components of the Basic Imaging Profile.
In Table 19-4, 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 Figure 19-13, we provide a conceptual illustration representing the dependencies that make up the Basic Printing Profile; the areas that are shaded are relevant to this profile. As you can see, the 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.
An imaging responder device is capable of supporting several modes of operation, which include the ability to be non-discoverable, limited discoverable or general discoverable; each mode is user configured. Furthermore, an imaging device may also be configured to operate with a certain capability; these are shown in Table 19-5. You will also notice that these capabilities are depicted as Optional (O) or Mandatory (M).
Table 19-4. The list of behavioural characteristics that are typical for this profile.
|
CONFIGURATION |
ROLE |
DESCRIPTION |
|---|---|---|
|
DeviceA |
Imaging Initiator |
This device is capable of pulling and pushing image objects to the imaging device. The initiator establishes a relationship with the responder before image objects can be sent; the initiator will typically initiate the connection. |
|
Initiator |
This configuration describes the device that instigates the original connection or the device that wishes to initiate communication over an existing link. | |
|
DeviceB |
Imaging Responder |
A responder provides image object exchange capability which, in turn, allows an initiator device to push image objects to the responder. This type of device would typically accept connections from the initiator. |
|
Acceptor |
This configuration describes the process of the device accepting the initiated communication from DeviceA. |
The Basic Imaging Profiles supports several imaging features. As indicated in Table 19-5, the generic imaging capability should be supported as a minimum, where the support of other capabilities is considered optional. These features are now discussed in the following sections.
An imaging initiator device is capable of pushing an image object to an imaging responder using four commands. These commands form part of the OBEX push procedure using the Put operation. Conversely, an OBEX pull procedure is accomplished through the use of a Get operation.
Table 19-5. The list of modes that a imaging device is capable of supporting.
|
CAPABILITY |
SUPPORT |
DESCRIPTION |
|---|---|---|
|
Imaging |
M |
As a minimum, a device should support generic imaging capabilities, where an image can be pushed or pulled. |
|
Capturing |
O |
The ability to capture an image through a Bluetooth wireless optical interface. |
|
Printing |
O |
A device that is capable of printing images through a Bluetooth wireless interface. |
|
Display |
O |
Using a Bluetooth-enabled projector device as an example, we can create the ability to transfer image objects to this device, where they are subsequently displayed. |
The image push feature places an image onto the image responder, where a PutImage command is encoded within an OBEX Put operation. In this instance, the only possible outcome is for the responder to print the image. However, the imaging initiator should determine if these capabilities are supported using a GetCapabilities command encoded within the OBEX Get operation; this is illustrated in Figure 19-14.
Figure 19-14. The sequence of events that occur when the initiator wishes to determine the capabilities of the responder.
In a typical scenario, an imaging responder will be a Bluetooth-enabled digital still or moving camera, where the imaging initiator has already determined its capabilities using the GetCapabilities command. With a series of images available on the responder, a GetImage command is used to retrieve the image from the responder and is shown in Figure 19-15. When an image is no longer required, the image initiator device may choose to delete an image using the DeleteImage command encoded within an OBEX operation.
The Advanced Imaging features prescribe specifically how an image should be printed. Parameters during a typical push operation, such as the number of copies or how an image should be laid out on a page, are not provided. In the first instance, an imaging initiator would determine if the responder is capable of these advanced features using the GetCapabilities command. To commence the printing process, the OBEX Put operation is encoded with the StartPrint command.
An additional function is also provided to allow the printing of images where in some cases the image may be too large and the buffering capabilities of the responder device may not be sufficient to accommodate it in its entirety. As such, the GetPartialImage command, which is encoded in an OBEX operation, is used to retrieve the image in sections. In Figure 19-16, we illustrate the sequence of events that occur during the operation of sending a large image to an imaging responder device.
We have discussed many features of the Basic Imaging Profile; to complement this, an Automatic Archiving process is used by the imaging responder to automatically retrieve images. In a typical scenario, a digital camera would instigate a connection, where all the images that it has stored can be downloaded onto a notebook.
As usual, the GetCapabilities command is used to determine if the device supports the feature, where further commands, such as GetImageList, GetImage, DeleteImage and StartArchive are also used. In Figure 19-17, we demonstrate the events that occur during this process.
With the ability to already connect and determine the capabilities of an imaging responder, the initiator may undertake control of the responder device. The Remote Camera feature allows the initiator to control the monitoring of an image and then to subsequently control the triggering of the shutter.
The feature provides further commands to enable the remote control capability. Through the use of GetMonitoringImage, GetImageProperties and GetImage, images can be previewed before they are actually captured and transferred. In Figure 19-18, we demonstrate the events that occur during this process.
In our final examination of the features available within the Basic Imaging Profile, we look at the capabilities provided to us through the Remote Display. An imaging initiator has the inherent core functionality to push images to an imaging responder which, in turn, the imaging responder has the capability to display the images that it receives.
The sequence, as illustrated in Figure 19-19, shows that an image is transferred to the responder using the PutImage command, encoded within an OBEX Put operation. In the sequence, the GetCapabilities is used to determine if the responder supports the display feature and then issues the PutImage command. In the next event, the RemoteDisplay command is then issued to actually instruct the responder to display the image.
The Basic Printing and Imaging Profiles provide seamless and transparent connections to Bluetooth-enabled printers and imaging responders, respectively.
Both profiles are dependent upon the capabilities provided in the GOEP.
Both profiles form part of the new set of profiles that are currently being drafted for adoption into the specification.
Authentication and encryption is optional for both the printing and imaging.
There are no strict master-slave roles operated by these profiles.
When operating the printing profile, a number of Bluetooth-enabled devices can connect and make use of the services provided, where two new roles are created: sender and printer.
Similarly, a range of Bluetooth-enabled devices can connect to and make use of the imaging responder features. Two new roles are also created: an imaging initiator and an imaging responder.
The printing profile operates four modes of operation: offline, private online, public online and bonding.
A Bluetooth-enabled printer may operate direct or reference printing.
During the operation of the direct printing feature, the sender device pushes the object directly to the printer.
The reference printing feature offers the printer a reference for it to locate the intended object for printing.
A Bluetooth-enabled printer is capable of managing single and multiple object types and can be configured for more complex operations.
The imaging profile provides four core capabilities: imaging, capturing, printing and display.
The imaging feature is the basic functionality offered to us as a minimum by any device supporting the Basic Imaging Profile.
Capturing allows an imaging initiator to retrieve images dynamically.
Using the printer capability allows the initiator to send images directly to a printer, where segmentation is offered if the image is too large.
Using the display feature allows an initiator to send images to a responder that has display capabilities.