Hardcopy Cable Replacement Profile
The Hardcopy Cable Replacement Profile defines the
requirements for the protocols and procedures that shall be used by
applications providing the Hardcopy Cable Replacement usage model. This
profile makes use of GAP to define the interoperability requirements
for the protocols needed by applications. The most common devices using
these usage models are mobile laptops and desktop computers, although
other devices are not excluded. The usage model includes, but is not
limited to, printing and scanning any type of document. The data is
rendered through the use of a driver on the client device.
For more details : Download the HCRP Profile from the Bluetooth.org
website.
The figure below shows the protocols and entities
used in this profile.
Image reprinted from Bluetooth HCRP Profile, Figure
2 , page 12
The Baseband, LMP, and L2CAP are the OSI layer 1 and
2 Bluetooth protocols. SDP is the Bluetooth Service Discovery Protocol.
HCRP is the Hardcopy Cable Replacement Profile (this profile).
Interoperability between devices using this profile depends on the
presence of peer applications running on top of the HCRP layer in both the
Client and the Server.
The following roles are defined for this profile:
- Server – This is the server device that offers the Hardcopy
Cable Replacement Profile as a service. It can receive binary data
from the client. Alternatively it may send binary data back to the
client as it is requested. Connections are generally made by the
client, but the server may be able to connect to a client to notify
the client of changes in the server if the client has registered for
notifications from the server.
- Client – This is the client device that connects to the
server to use a particular function of the server.
- Notifications - When a client connects to a server,
it may register for notifications, giving the server sufficient
information to allow it to connect back to the client. This is to
enable the server to connect to the client in an asynchronous manner
if the server needs to. The notification functionality specified by
this profile provides the framework for a host application and printer
to communicate event-driven information.
The scenarios covered by this profile are:
- Printing any type of document. The document would be rendered to the
relevant PDL on the server and sent in the appropriate format to the
printer.
- Scanning documents through the use of a driver on the client device.
Servicing multiple clients simultaneously for
printing and status is a potential user scenario but it is not a user
requirement. The server device may support multiple connections, but this
is not required. How the server services multiple jobs simultaneously is
implementation-specific and beyond the scope of this profile. If a server
cannot support any more clients connecting to it, it is required to either
make itself unavailable for service discovery or refuse connections.
- Link and channel establishments shall be done according to the
procedures defined in L2CAP unless otherwise stated in this
specification.
- Link-level authentication and encryption are mandatory to support
and optional to use.
- Bonding is mandatory to support and optional to use.
- There are no fixed master-slave roles for the execution of this
profile. The master-slave switch is optional to support and optional
to use.
- This profile does not require any low power mode to be used.
- The Bluetooth L2CAP connections are configured in such a way as to
guarantee reliable delivery of data.
The server device can be put into 4 different modes.
- Bluetooth Offline Mode - Device is not able
to receive data over Bluetooth. It is not possible to connect to the
device.
- Bonding Mode - Device is ready to be bonded with
client devices.
- Private Online Mode - Device can be connected to
and used over Bluetooth only from devices that know the device's
Bluetooth device address.
- Public Online Mode- Device can be connected to and
used over Bluetooth from devices that know the Printer's Bluetooth
device address.
In the following sections, the presented scenarios
work as examples and variations in the allowed implementations.
When a client wants to print a job
on a printer, the following scenario may be followed. In this case the
client already knows the Bluetooth device address of the printer.
In brief , the client connects to the server, selects a driver to talk
to the server, then renders the data using the driver and sends it to the
printer, where it is printed. See page 16 of the HCRP for more details.
When a client wants to print a job
on a printer, the following scenario may be followed. In this case the
client does not know the Bluetooth device address of the printer.
In brief ,the user selects what HCRP-compliant clients are available
and selects one. The client connects to the server, selects a driver to
talk to the server, then renders the data using the driver and sends it to
the printer, where it is printed. See page 17 of the HCRP for more
details.
If a client wants to receive rich status in the form
of notifications from a server device, the client needs to register for
notifications from the server device. This means that even if there is no
current connection between the client and server, the server can connect
to the client and pass rich status information asynchronously. A
notification is an asynchronous event from the server to the client
notifying the client of a change in state in the server.
An example of a printer notification is an
end-of-job notification. A job may be spooled to a printer’s hard drive
prior to being processed. This would mean that the data being sent to the
printer over the Bluetooth link would complete sending before the printer
has completed printing. To allow the sender not to have to maintain a
connection to receive an end-of-job notification from the printer, the
notification channel may be used.
An example of a scanner notification is a scanner
button press event. A user may walk up to a scanner and press the scan
button on the front panel. The scanner would then send a notification of
the scan button press to all registered clients. This allows clients to
not have to have an open connection at all times to receive this type of
event.
This section describes the service capabilities
which can be utilised by the application profiles using GOEP.
The hardcopy cable replacement application has the following features
- A "control" L2CAP channel is used to
transmit out-of-band control requests to the server device.
- A "data" L2CAP channel is used to
transmit and receive raw, device-specific data to and from a server
device. The contents of this channel are not specified by this
profile.
- The control channel may be used by the client to register for
notifications. This allows the server device to initiate a connection
to the client if it needs to notify the client that it has information
for the client.
- The "notification" channel is used by the
server to notify a registered client about asynchronous events.
- The control channel may be used to obtain the LPT status bits from
the server device.
- The control channel may be used to obtain the IEEE 1284 ID string
from the server device.
- The control channel may be used to "soft reset" the server
device.
- The control channel may be used to "hard reset" the server
device.
- The control channel is used to transmit flow control information for
the data channel.
The Hardcopy Cable Replacement Profile defines a
simple protocol for communicating with hardcopy devices as if they were
connected over a locally attached cable.The protocol uses two
connection-oriented L2CAP channels. These are the data and control
channels. The protocol uses an additional L2CAP channel for notifications.
The data and control channels are exposed by the
server. The notification channel is optionally exposed by the client.
- The "control" L2CAP channel is used to transmit
out-of-band control requests to the server device. All communications
on this channel will be initiated by the client device.
- The "data" L2CAP channel is used to transmit and receive
raw, device-specific data to and from a server device. The contents of
this channel are not specified by this profile.
- The optional "notification" L2CAP channel may be used by
the server to notify the client of asynchronous events.
The Hardcopy Cable Replacement
Protocol transfers bytes in the standard network order (big-endian), with
more significant (high-order) bytes being transferred before less
significant (low-order) bytes.
L2CAP in Bluetooth 1.1 lacks a flow control
mechanism. However, printing and scanning typically require flow control
due to the volume of data involved. Therefore the Hardcopy Cable
Replacement Protocol provides its own flow control mechanism. The
mechanism is simple, lightweight, and credit-based.
Before a device may transmit on the data channel,
the device shall first receive "credit" from the other device. A
credit grant transaction is a message from a client device to a server
device granting permission to transmit a specific number of bytes. A
credit request transaction is a message from a client device to a server
device requesting that the server grant credit to the client. The server
decides how many bytes of credit to grant the client device.
All credit grants or requests originate from the
client device and are transacted on the control channel. When a client
wishes to have credit to transmit on the data channel, it sends a credit
request to the server. When the client wishes to grant credit to the
server device, it sends a credit grant message. Client devices should
periodically grant and request credit to guarantee a continuous flow of
data. If a device is capable of accepting large amounts of data very
quickly, it will grant larger or more frequent credit grants to its peer.
If a device is not capable of processing data as quickly, it will grant
smaller or less frequent credit grants.
Credit grants are cumulative. When a device receives
credit, it increases the total credit available to the device. When a
device transmits bytes over the connection, it deducts the number of bytes
transmitted from its total available credit. When a device’s available
credit reaches zero, the device shall not transmit anything on the data
channel until additional credit has been received.
The control channel uses a request and reply method
to ensure flow control. Only one control PDU may be outstanding at a time.
- Data and Channel Control MTUs: For simplicity, the
client and the server device s hall each provide the ability to buffer
at least 128 bytes on the control channel. This implies that the L2CAP
MTU negotiated by each side of the control channel connection shall be
at least 128 bytes. The data channel L2CAP connection is negotiated
separately, and may be any size allowed by L2CAP.
- Initialisation: All traffic across the data channel
consumes credit. When a client connects to a server, the initial
credit granted on the data channel to both devices is zero. Because of
this, before any data may be sent on the data channel by either
device, credit transactions to grant and request credit are necessary.
- Channel Utilisation: Flow control is only provided
for the data channel. All control messages, including credit grants,
take place in the control channel. As a result, credit grants for the
data channel travel in the control channel. This ensures that there
can never be a credit deadlock.
L2CAP in Bluetooth 1.1 provides a relatively
reliable connection between the client and server. All data is guaranteed
to be delivered despite interference, up to the point where the entire
connection is dropped. If the connection is dropped or a specified
failure timeout is reached, the job should be aborted. Therefore, the
Hardcopy Cable Replacement Profile provides no transmission error
recovery. A recommended failure timeout is 5 minutes.
The control channel defines a
format for PDUs as well as several PDUs that are transferred on the
control channel.
- Protocol Data Unit Format : Each control channel transaction
consists of a request from a client and a reply from the server. Each
request takes the form of a request PDU, and every response takes the
form of a reply PDU.
- Request PDUs : Each request PDU contains a PDU ID, a
transaction ID, a parameter length field, and a variable number of
parameter values.
- Reply PDUs : Each reply PDU contains a PDU ID, a transaction
ID, a parameter length field, a status code, and a variable number of
parameter values. The transaction ID and PDU IDs are the same values
as those of the received request PDU.
The following table identifies which credit grant
and credit request PDUs are MANDATORY to implement on both clients and
servers. All other PDU transactions are OPTIONAL for both client and
server. See the HCRP spec for full details of what each PDU actually does.
Image reprinted from Bluetooth
HCRP Profile, Table 3 , page 26
Notification Channel Protocol : The
notification channel defines a format for PDUs as well as one PDU that may
be transferred on the notification channel. The following table
identifies which Notification PDUs are Mandatory/Optional to
implement on both clients and servers.
Image reprinted from Bluetooth HCRP Profile, page 46
The server shall provide a Service Discovery Record
describing its Control and Data Channels. The client shall provide a
Service Discovery Record if it will register for notifications. See
Section 7.1 & 7.2 of the HCRP spec for details of the Control, Data
and Notification service discovery records.
Link-level authentication and encryption are
mandatory to support and optional to use. If the server device initiates
authentication, it may do so by using a fixed PIN. The PIN could be
changed using some proprietary method in the server device.
Neither the client nor the server is required to be
able to initiate authentication, but all devices shall be able to respond
to an authentication request, however it is recommended that client
devices without user interfaces avoid initiating link-level
authentication.
Note, the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth
Specification.
|
