Symbian OS Communications (779884), страница 17
Текст из файла (страница 17)
This is called ‘sniff mode’.Sniff mode is a very commonly used way to extend battery life. In sniffmode, a periodic arrangement of time slots can be specified as ‘anchor’points at which the master and slave commit to a transfer. There is moredetail to the arrangement that can allow for a missed transfer at the anchorpoint, but to summarize, sniff mode reduces the time spent listening on alink for traffic, and therefore the power consumed.
The downside can beincreased latency and a reduction in bandwidth. Typically a physical linkin sniff mode consumes less power than a device requires to listen fordevice discovery requests and incoming connections. So, for example,a human interface device such as a Bluetooth mouse, or a Bluetoothheadset, can connect to the remote device at power on, then place theresulting link into sniff mode. This is more battery efficient than the mouseor headset waiting for an inbound connection.The default mode of the physical link, which it is in after connection,is ‘active’ mode.
All of the time slots are used to exchange data betweenthe master and slaves in the piconet. In many situations this is wasteful;thus, when the link is required but no traffic is going to flow, the linkshould be placed into a mode other than active mode. In cases wherethere will be a lot of traffic flowing, or low latency is required, the linkshould be placed back into active mode. As an example, a turn-basedgame such as Battleships or Noughts and Crosses could operate perfectlywell in sniff mode.
A more interactive game, such as Snake, is likely torequire the lower latency of active mode.Hold mode can be used by Bluetooth hosts when managing morecomplex Bluetooth networks, particularly when the host wishes to discover and create a physical link to another Bluetooth device. Applicationswould not typically manipulate this directly, although an attempt by anservice to connect to given device may have the side effect of puttinganother link into hold mode.Park mode is rarely used but can, in theory, allow more than sevenslave devices to be connected to a single master. In addition the master72BLUETOOTHcan broadcast to all of the attached, parked, slaves. However, there aredifficulties in making this work in practice, and again is not something anservice would be expected to do.Security can be applied to a link at the service’s request.
In Symbian OS, the actual link security used is based on the highest securityrequirements given by any service. There are three aspects to linksecurity – authorization, authentication and encryption. Of these, authorization is independent of the other two, but to use encryption thenauthentication (i.e., the pairing process) must have taken place at leastonce between the devices. A more practical discussion on security takesplace in section 4.2.7.4.1.4 Logical TransportsThe two most important logical transports are the asynchronous connection oriented (ACL) and the synchronous connection oriented transports(SCO and eSCO). By far the most important to the application programmer is the ACL, as this forms the underlying transport for L2CAP, whichis now discussed.The asynchronous transportThe asynchronous transport (ACL4 ) carries the majority of data in Bluetooth. By default, it is reliable; although it can be configured to beunreliable if required to provide a latency-based isochronous service.There is a choice of packet types available to the ACL transport: thepackets can be chosen to optimize the performance of the service indifferent radio conditions.
Generally, due to the dynamic nature of thedifferent radio conditions it usually makes most sense for the Bluetoothhardware to make the decisions on which ACL packets to use.The ACL transport supports two types of ‘logical links’ – the ACL-U,and ACL-C; ‘U’ referring to the user-plane, and ‘C’ to the control-plane.The ACL-C logical link is used by the lower Bluetooth layers to conversewith each other, for example sending messages to disconnect links,change the transmit power and switch encryption on. The ACL-U isthe link over which all higher layer protocols in the Bluetooth stackcommunicate, including, therefore, all services running on Symbian OS.4A quick word about the name of the transport: ‘ACL’ was used in 1.1 and earlier versionsof the Bluetooth specification to mean ‘asynchronous connectionless’.
In those versions ofthe specification there was no documented concept of the physical link (which is connectionoriented). Therefore, the ACL appeared to be ‘connection oriented’ to most readers of thespecification. In 1.2 and later versions of the specification, the writers changed ‘ACL’ tomean ‘asynchronous connection-oriented link’; however, they also introduced, correctly,documentation of the physical link. It is the author’s view that, given the connection-orientedphysical link, it still makes sense to consider the ‘ACL’ as connectionless.BLUETOOTH TECHNOLOGY OVERVIEW73The synchronous transportsBluetooth’s synchronous transports are one of its key strengths whencompared with other wireless technologies: they allow the simple andreliable transportation of voice over a wireless link.
Synchronous links arealways used with Bluetooth headsets to place and receive phone calls. Asthe data for these synchronous links does not come through the SymbianOS Bluetooth stack, they are not discussed further here.4.1.5 L2CAPThe most important protocol in any Bluetooth host is L2CAP – the LogicalLink Control and Adaptation Protocol. This is the most common point atwhich services interface to the Bluetooth stack within Symbian OS.The name L2CAP implies that it controls and adapts a logical link.The ‘logical link’ in this case is the ACL-U, discussed earlier.
It is usefulto abstract away the characteristics of the data buffers in the controllerfrom the application in order to allow applications to be hardwareindependent. This is the ‘adaptation’ service of the ACL-U logical linkprovided by L2CAP.L2CAP provides a multiplexing, connection-oriented, sequencedpacket datalink service.Let’s quickly run through that – afterwards, if you want more detailon the generic concepts, have a look in Chapter 3.
The multiplexingservice simply provides many channels over the single underlying ACLU. The service is connection-oriented as we connect to a specific PSM(see section 4.1.8 for an explanation of what a PSM is) on the remotehost before transferring data – this is also useful as it reduces the packetheader overhead, as the connection is assigned a channel ID ratherthan needing to carry all the channel state information in the header inthe way that TCP does. And the link is presented in sequenced packetform – we get datagram boundaries that we can use for framing ourown application protocol if necessary, and guaranteed, in-order delivery(unless we request otherwise).The Bluetooth Core specification describes two forms of L2CAP –connection oriented and connectionless.
At present there are not manyuses for connectionless L2CAP, so it is not discussed here.Using L2CAP to send isochronous dataVersions of L2CAP prior to version 1.2 of the Bluetooth Core specificationare not particularly feature-rich for a multiplexing protocol. For example,there is no per-channel flow control, no per-channel error control,and no segmentation-and-reassembly (SAR). This causes a number ofproblems – especially with latency-sensitive services such as streamingaudio, and in cases where one service using an L2CAP link is receivingdata very slowly, and affecting the performance of that link for otherservices.74BLUETOOTHAs we have seen, by default the ACL transport is ‘reliable’ – in otherwords, when the hardware is asked to send L2CAP data, it will attempt tosend it, possibly forever, until it is acknowledged by the remote Bluetoothhardware.
Some services, especially streaming audio-video services donot require such a feature from the Bluetooth hardware, indeed data sentby such services only has a limited lifetime in which it is useful. In thesesituations an L2CAP entity may instruct the controller to ‘flush’ the datafrom its sending buffers for a particular ACL transport if it has not successfully sent the data within a specified period of time. This may seem to be auseful feature; however, other services running over the same ACL transport may expect a reliable transport (for example, the RFCOMM protocolexpects a reliable transport).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
