BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 81 of 1082
`
`Baseband Specification
`
`8 TRANSMITIRECEIVE ROUTINES
`
`This section describes the way to use the packets as defined in Ejection 4 in
`order to support the traffic on the ACL and SCO links. Both single-slave and
`multi-slave configurations are considered. In addition, the use of buffers for the
`TX and RX routines are described.
`
`The TX and RX routines described in sections 8.1 and 8.2 are of an informative
`
`character oniy. The finai implementation may be carried out differently.
`
`8.1 TX ROUTINE
`
`The TX routine is carried out separately for each ACL link and each SCO link.
`Figure 8.1 on oags 8‘: shows the ACL and SCO buffers as used in the TX rou-
`tine. In this figure, only a single TX ACL buffer and a single TX SCO buffer are
`shown. In the master, there is a separate TX ACL buffer for each slave. In addi-
`tion there may be one or more TX SCO buffers for each SCO slave (different
`SCO links may either reuse the same TX SCO buffer, or each have their own
`TX SCO bufier). Each TX buffer consists of two FIFO registers: one current
`register which can be accessed and read by the Bluetooth controller in order to
`compose the packets, and one next register that can be accessed by the Blue-
`tooth Link Manager to load new information. The positions of the switches S1
`and S2 determine which register is current and which register is next; the
`switches are controlled by the Bluetooth Link Controller. The switches at the
`input and the output of the FIFO registers can never be connected to the same
`register simultaneously.
`
`asynchronous
`ll‘0 pm
`
`513
`
`TX ACL buffer
`
`currentinext data FIFO
`
`nexticunent data FIFO
`
`TX 560 buffer
`
`currentfnext voice FIFO
`
`packet
`composer
`
`synchronous
`lI‘O port
`
`S2
`
`a
`0:5 nexticurrent voice FIFO
`
`Szb
`
`Figure 8.1: Funcrionai diagram of TX buffering.
`
`Of the packets common on the AOL and SCO links (ID. NULL. POLL. FHS.
`DM1) only the DM1 packet carries a payload that is exchanged between the
`Link Controller and the Link Manager; this common packet makes use of the
`
`TransmiIiReceive Routines
`
`29 November ‘I999
`
`AFFLT0293309
`
`Samsung Ex. 1119 p. 81
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 82 of
`
`Baseband Specification
`
`Bluetooth-
`
`ACL buffer. All ACL packets make use of the ACL buffer. All SCO packets
`make use of the SCO buffer except for the DV packet where the voice part is
`handled by the SCO buffer and the data part is handled by the ACL buffer. In
`the next sections, the operation for ACL traffic, SCO traffic, and combined
`data-voice traffic on the SCO link will be considered.
`
`8.1.1 ACL traffic
`
`In the case of pure (asynchronous) data, only the TX ACL buffer in Figtirs 83%
`on page 8? has to be considered. In this case, only packet types DM or DH are
`used, and these can have different lengths. The length is indicated in the pay-
`load header. The selection of high-rate data or medium-rate data shall depend
`on the quality of the link. When the quality is good, the FEC in the data payload
`can be omitted, resulting in a DH packet. Otherwise, DM packets must be
`used.
`
`The default TYPE in pure data traffic is NULL. This means that, if there is no
`data to be sent (the data traffic is asynchronous, and therefore pauses occur in
`which no data is available) or no slaves need to be polled, NULL packets are
`sent instead — in order to send link control information to the other Bluetooth
`
`unit (e.g. ACKISTOP information for received data). When no link control infor-
`mation is available either (no need to acknowledge andior no need to stop the
`RX flow) no packet is sent at all.
`
`The TX routine works as follows. The Bluetooth Link Manager loads new data
`information in the register to which the switch S1a points. Next, it gives a flush
`command to the Bluetooth Link Controller, which forces the switch S1 to
`change (both 81a and 81b switch in synchrony). When the payload needs to
`be sent, the packet composer reads the current register and, depending on the
`packet TYPE, builds a payload which is appended to the channel access code
`and the header and is Subsequently transmitted. In the response packet (which
`arrives in the following RX slot if it concerned a master transmission, or may be
`postponed until some later RX slot if it concerned a slave transmission), the
`result of the transmission is reported back. In case of an ACK, the switch S1
`changes position; if a NAK (explicit or implicit) is received instead, the switch
`81 will not change position. In that case, the same payload is retransmitted at
`the next TX occasion.
`
`As long as the Link Manager keeps loading the registers with new information,
`the Bluetooth Link Controller will automatically transmit the payload; in addi-
`tion, retransmissions are performed automatically in case of errors. The Link
`Controller will send NULL or nothing when no new data is loaded. If no new
`data has been loaded in the next register, during the last transmission, the
`packet composer will be pointing to an empty register after the last transmis-
`sion has been acknowledged and the next register becomes the current regis-
`ter. If new data is loaded in the next register, a flush command is required to
`switch the S1 switch to the proper register. As long as the Link Manager keeps
`loading the data and type registers before each TX slot, the data is automati-
`cally processed by the Link Controller since the 81 Switch is controlled by the
`
`82
`
`29 November ‘I999
`
`TransmitiRecsive Routines
`
`AFFLT0293310
`
`Samsung Ex. 1119 p. 82
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 83 of 1082
`
`Base-band Specification
`
`Bluetooth.
`
`ACK information received in response. However, if the traffic from the Link
`Manager is interrupted once and a default packet is sent instead, a flush com-
`mand is required to continue the flow in the Link Controller.
`
`The flush command can also be used in case of time-bounded (isochronous)
`data. In case ofa bad link, many retransmission are necessary. In certain appli-
`cations. the data is time-bounded: if a payload is retransmitted all the time
`because of link errors, it may become outdated, and the system might decide
`to continue with more recent data instead and skip the payload that does not
`come through. This is accomplished by the flush command as well. With the
`flush, the switch S1 is forced to change and the Link Controller is forced to
`consider the next data payload and overrules the ACK control.
`
`8.1.2 SCO traffic
`
`In case of an SCO link, we only use HV packet types. The synchronous port
`continuously loads the next register in the SCO buffer. The S2 switches are
`changed according to the T500 interval. This Tm, interval is negotiated between
`the master and the slave at the time the SCO link is established.
`
`For each new SCO slot, the packet composer reads the current register after
`which the S2 switch is changed. if the SCO slot has to be used to send control
`information with high priority concerning a control packet between the master
`and the considered SCO slave, or a controt packet between the master and
`any other slave, the packet composer will discard the SCO information and use
`the control information instead. This control information must be sent in a DM1
`
`packet. Data or link control information can also be exchanged between the
`master and the SCO slave by using the DV or DM1 packets. Any ACL type of
`packet can be used to sent data or link control information to any other ACL
`slave. This is discussed next.
`
`8.1.3 Mixed dataivoice traffic
`
`in Sec:tic:'t 4.4.2 on page 538, a DV packet has been defined that can support
`both data and voice simultaneously on a single SCO link. When the TYPE is
`DV, the Link Controller reads the data register to fill the data field and the voice
`register to fill the voice field. Thereafter, the switch S2 is changed. However,
`the position of S1 depends on the result of the transmission like on the ACL
`link: only if an ACK has been received will the S1 switch change its position. In
`each DV packet, the voice information is new, but the data information might be
`retransmitted if the previous transmission failed. If there is no data to be sent,
`the SCO link will automaticatly change from DV packet type to the current HV
`packet type used before the mixed dataivoice transmission. Note that a flush
`command is required when the data stream has been interrupted and new data
`has arrived.
`
`Combined data-voice transmission can also be accomplished by using sepa-
`rate ACL links in addition to the SCO link(s) if channel capacity permits this.
`
`TransmiUReceive Routines
`
`29 November 1999
`
`AFFLT029331 1
`
`Samsung Ex. 1119 p. 83
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Baseband Specification
`
`8.1.4 Default packet types
`
`page 84 of €882
`
`Bluetooth-
`
`On the ACL links, the default type is always NULL both for the master and the
`slave. This means that if no user information needs to be send, either a NULL
`
`packet is sent if there is ACK or STOP information, or no packet is sent at all.
`The NULL packet can be used by the master to allocate the next sEave-to-mas-
`ter slot to a certain slave (namely the one addressed). However, the slave is
`not forced to respond to the NULL packet from the master. if the master
`requires a response. it has to send a POLL packet.
`
`The SCO packet type is negotiated at the LM level when the SCO link is estab-
`lished. The agreed packet type is also the default packet type for the SCO
`slots.
`
`8.2 RX ROUTINE
`
`The RX routine is carried out separately for the ACL link and the SCO link.
`However, in contrast to the master TX ACL buffer, a single RX buffer is shared
`among all slaves. For the SCO buffer, it depends how the different SCO links
`are distinguished whether extra SCO buffers are required or not. Figs-rt-3 8.2 on
`page Set shows the AOL and SCO buffers as used in the RX routine. The RX
`ACL buffer consists of two FIFO registers: one register that can be accessed
`and loaded by the Bluetooth Link Controller with the payload of the latest RX
`packet, and one register that can be accessed by the Bluetooth Link Manager
`to read the previous payload. The RX SCO buffer also consists of two FIFO
`registers: one register which is filled with newly arrived voice information, and
`one register which can be read by the voice processing unit.
`
`RX ACL buffer
`
`currantinext data FIFO
`
`51a
`
`riexticurrent data FIFO
`
`31b
`
`asynchronous
`“O pan
`
`RX SCO buffer
`
`curren Unext voice FIFO
`
`0:!‘ nexticurrent voice FIFO
`
`synchronous
`IiO port
`
`
`
`packetde-composer
`
`Figure 8.2: Functional diagram ofRX buffering
`
`Since the TYPE indication in the header of the received packet indicates
`whether the payload contains data andior voice, the packet de-composer can
`automatically direct the traffic to the proper buffers. The switch 31 changes
`
`29 November 1999
`
`TraosmitiRecsive Routines
`
`AFFLT0293312
`
`Samsung Ex. 1119 p. 84
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 85 of 1082
`
`Base-band Specification
`
`every time the Link Manager has read the old register. If the next payload
`arrives before the RX register is emptied, a STOP indication must be included
`in the packet header of the next TX packet that is returned. The STOP indica-
`tion is removed again as soon as the RX register is emptied. The SEQN field is
`checked before a new ACL payload is stored into the ACL register (flush indi-
`cation in L_CH and broadcast messages influence the interpretation of the
`SEQN field see Sectéorr 5.3 on page 68).
`
`The S2 switch is changed every T300. |f— due to errors in the header — no new
`
`voice payload arrives, the switch still changes. The voice processing unit then
`has to process the voice signal to account for the missing speech parts.
`
`8.3 FLOW CONTROL
`
`Since the RX ACL buffer can be full while a new payload arrives, flow control is
`required. As was mentioned earlier, the header field FLOW in the return TX
`packet can use STOP or G0 in order to control the transmission of new data.
`
`8.3.1 Destination control
`
`As long as data cannot be received, a STOP indication is transmitted which is
`automatically inserted by the Link Controller into the header of the return
`packet. STOP is returned as long as the RX ACL buffer is not emptied by the
`Link Manager. When new data can be accepted again, the GO indication is
`returned. G0 is the default value. Note that all packet types not including data
`can still be received. Voice communication for example is not affected by the
`flow control. Also note that although a Bluetooth unit cannot receive new infor-
`mation, it can still continue to transmit information: the flow control is separate
`for each direction.
`
`8.3.2 Source control
`
`On the reception of a STOP signal, the Link Controller will automatically switch
`to the default packet type. The current TX ACL buffer status is frozen. Default
`packets are sent as long as the STOP indication is received. When no packet
`is received, G0 is assumed implicitly. Note that the default packets contain link
`control information (in the header) for the receive direction (which may still be
`open) and may contain voice (HV packets). When a G0 indication is received,
`the Link Controller resumes to transmit the data as is present in the TX ACL
`buffers.
`
`In a multi-slave configuration, only the transmission to the slave that issued the
`STOP signal is stalled. This means that the previously described routine imple-
`mented in the master only concerns the TX ACL buffer that corresponds to the
`slave that cannot accept data momentarily.
`
`TransmiUReceive Routines
`
`29 November 1999
`
`AFFLT0293313
`
`Samsung Ex. 1119 p. 85
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 86 of €882
`
`Baseband Specification
`
`3.4 BITSTREAM paocesses
`
`Bluetooth-
`
`Before the user information is sent over the air interface, several bit manipula-
`tions are performed in the transmitter to increase reliability and security. To the
`packet header, an HEC is added, the header bits are scrambled with a whiten-
`ing word, and FEC coding is applied. In the receiver, the inverse processes are
`carried out. Figure 8.3 an page SE3 shows the processes carried out for the
`packet header both at the transmit and the receive side. All header bit pro-
`cesses are mandatory.
`
`TX header
`
`(LSB first)
`
`HEC generation
`
`FEC encoding
`
`RF interface
`
`Figure 8.3: Header bit processes.
`
`For the payload, similar processes are performed. It depends on the packet
`type, which processes are carried out. i-"igure 8.4 can page
`shows the pro-
`cesses that may be carried out on the payload. In addition to the processes
`defined for the packet header, encryption can be applied on the payload. Only
`whitening and de-whitening, as explained in fie-::t§<3n ‘i or: page ‘F9, are manda-
`tory for every payload; all other processes are optional and depend on the
`packet type and the mode enabied. In Fég=..=re 8.4 an
`E36, optional pro-
`cesses are indicated by dashed blocks.
`
`I
`TX payIoad—:-‘CRO generation'—3-E encryption
`(1.53 firsl)
`'
`
`RF Interface
`
`5
`RX payIoad«u:—‘ CRC checking E-z—:
`
`1
`
`decryption
`._ .. .. . .. I
`
`1 1 — — 1 1
`:
`decoding
`.. _. .. ._ .. I
`
`Figure 8.4: Payload bit processes.
`
`29 November 1999
`
`Trar:smitiReceive Routines
`
`AFFLT0293314
`
`Samsung Ex. 1119 p. 86
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 87 of 1082
`
`Baseband Specification
`
`9 TRANSMITIRECEIVE TIMING
`
`The Bluetooth transceiver applies a time-division duplex (TDD) scheme. This
`means that it altemately transmits and receives in a synchronous manner. It
`depends on the mode of the Bluetooth unit what the exact timing of the TDD
`scheme is. In the normal connection mode, the master transmission shat! always
`start at even numbered time siots (master Ci_K1=0) and the stave transmission
`shaft always start at odd numbered time slots (master Ci_K1=1). Due to packet
`types that cover more than a single slot, master transmission may continue in odd
`numbered slots and slave transmission may oontinue in even numbered slots.
`
`All timing diagrams shown in this chapter are based on the signals as present at
`the antenna. The term "exact" when used to describe timing refers to an ideal
`transmission or reception and neglects timing jitter and clock frequency imperfec-
`tions.
`
`The average timing of master packet transmission must not drift faster than
`20 ppm relative to the ideal slot timing of 625 ps. The instantaneous timing
`must not deviate more than 1 ps from the average timing. Thus, the absolute
`
`packet transmission timing I‘. of slot boundary .r’( must fulfill the equation:
`A
`
`F‘. = [Z0 iu’,.}T__V Ijk i oITsct,
`
`i=l
`
`(l-ZQ I)
`
`where TN is the nominal slot length (625 ps). I‘. denotesjitter (|;‘,_,| 5 I ps) at
`
`slot boundary ii’, and, dk, denotes the drift (ldkl 5 20 ppm) within slot i(. The jit-
`ter and drift may vary arbitrarily within the given limits for every slot, while “off-
`set" is an arbitrary but fixed constant. For hold. park and sniff mode the drift
`and jitter parameters as described in Link Mae-tsger F*i‘(}tCs-::£3i Eisction 3.9 on
`page
`apply.
`
`9.1 MASTERISLAVE TIMING SYNCHRONIZATION
`
`The piconet is synchronized by the system clock of the master. The master never
`adjusts its system ctock during the existence of the piconet: it keeps an exact inter-
`val of Mx625 us (where M is an even. positive integer larger than 0) between con-
`secutive transmissions. The slaves adapt their native clocks with a timing offset in
`order to match the master clock. This offset is updated each time a packet is
`received from the master: by comparing the exact RX timing of the received packet
`with the estimated RX timing, the staves correct the offset for any timing misalign-
`ments. Note that the slave RX timing can be corrected with any packet sent in the
`master-to-slave slot, since only the channei access code is required to synchronize
`the slave.
`
`The slave TX timing shall be based on the most recent slave RX timing. The RX
`timing is based on the latest successful trigger during a master-to-slave slot. For
`ACL links. this trigger must have occurred in the master-to-slave siot directly pre-
`
`TransmitiReceive 1”iming
`
`29 November 1999
`
`8?
`
`AFFLT0293315
`
`Samsung Ex. 1119 p. 87
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 88 of
`
`Baseband Specification
`
`Bluetooth-
`
`ceding the current slave transmission; for SCO links, the trigger may have
`occurred several master-to-slave slots before since a slave is allowed to send an
`
`SCO packet even if no packet was received in the preceding master-to-slave slot.
`The slave shall be able to receive the packets and adjust the RX timing as long as
`the timing mismatch remains within the ill} us uncertainty window.
`
`The master TX timing is strictly related to the master c|ock.The master shall keep
`an exact interval of Mx1250 us (where M is a positive integer larger than 0)
`between the start of successive transmissions; the RX timing is based on this TX
`timing with a shift of exactly Nx625 us (where N is an odd. positive integer larger
`than 0). During the master RX cycle, the master will also use the $101.1 uncertainty
`window to allow for slave misalignments. The master will adjust the RX processing
`of the considered packet accordingly, but will not adjust its RXITX timing for the fol-
`lowing TX and RX cycles.
`
`Timing behaviour may differ slightly depending on the current state of the unit.
`The different states are described in the next sections.
`
`9.2 CONNECTION STATE
`
`In the connection mode, the Bluetooth transceiver transmits and receives alter-
`
`on page 89. In the figures,
`$3 er: page 88 and Fig_3:_ire
`nately, see
`only single-slot packets are shown as an example. Depending on the type and
`the payload length, the packet size can be up to 366 ps. Each RX and TX
`transmission is at a different hop frequency. For multi-slot packets. several
`slots are covered by the same packet, and the hop frequency used in the first
`slot will be used throughout the transmission.
`
`RX slat
`
`hop g{2m+‘l)
`
`TX slot
`
`hop g{2m+2)
`
`5
`
`E
`
`t‘lCl|.rs
`
`Figure 9.1.’ RX/TX cycle of Bluetooth master transceiver in normal mode for single-slot
`packets.
`
`29 November 1999
`
`TransmitiReceiva ‘liming
`
`AFFLT0293316
`
`Samsung Ex. 1119 p. 88
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Baseband Specification
`
`page 89 of 1082
`
`Bluetooth
`
`TX slut
`
`hop g[2m+'i)
`
`RX slot
`
`h op g(2m + 2}
`
`Figure 9.2: RX’/TX cycie of Biueroofh siave transceiver in nonnai mode for single-siof packets.
`
`The master TX/RX timing is shown in Figure 9.1 on page SE5. In figures 9.1
`through 9.6, f(k) is used for the frequencies of the page hopping sequence and
`f(k) denotes the corresponding page response sequence frequencies. The
`channel hopping frequencies are indicated by g(m). After transmission, a return
`packet is expected Nx625 ps after the start of the TX burst where N is an odd,
`positive integer. N depends on the type of the transmitted packet. To allow for
`some time slipping, an uncertainty window is defined around the exact receive
`timing. During normal operation, the window length is 20 ps, which allows the
`RX burst to arrive up to 10 1.15 too early or 10 ps too late. During the beginning
`of the RX cycle, the access correlator searches for the correct channel access
`code over the uncertainty window. If no trigger event occurs, the receiver goes
`to sleep until the next RX event. If in the course of the search, it becomes
`apparent that the correlation output will never exceed the final threshold, the
`receiver may go to sleep earlier. If a trigger event does occur, the receiver
`remains open to receive the rest of the packet.
`
`The current master transmission is based on the previous master transmission:
`it is scheduled |Vlx1250ps after the start of the previous master TX burst where
`M depends on the transmitted and received packet type. Note that the master
`TX timing is not affected by time drifts in the slave(s). If no transmission takes
`place during a number of consecutive slots, the master will take the TX timing
`of the latest TX burst as reference.
`
`The s|ave's transmission is scheduled Nx625ps after the start of the s|ave's RX
`burst. If the slaves RX timing drifts, so will its TX timing. If no reception takes
`place during a number of consecutive slots, the slave will take the RX timing of
`the latest RX burst as reference.
`
`TransmitiReceive 1”iming
`
`29 November 1999
`
`AFFLT0293317
`
`Samsung Ex. 1119 p. 89
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Baseband Specification
`
`9.3 RETURN FROM HOLD MODE
`
`page 90 of
`
`Bluetooth-
`
`In the connection state, the Bluetooth unit can be placed in a hold mode, see
`Section ‘$9.85 on page ‘H2. In the hold mode, a Bluetooth transceiver neither
`transmits nor receives information. When returning to the normal operation
`after a hold mode in a slave Bluetooth unit, the slave must listen for the master
`before it may send information. In that case, the search window in the slave
`unit may be increased from ill} us to a larger value X us as illustrated in §i‘ig-are
`on
`90. Note that only RX hop frequencies are used: the hop fre-
`quency used in the master-to—s|ave (RX) slot is also used in the uncertainty
`window extended into the preceding time interval normally used for the slave-
`to-master (TX) slot.
`
`If the search window exceeds 625 us, consecutive windows shall not be cen-
`tered at the start of RX hops g(2m), g(2m+2),
`g(2m+2i) (where ‘i’ is an inte-
`ger), but at g(2m), g(2m+4),
`g(2m+4i), or even at g(2m), g(2m+6],
`...g(2m+6i) etc. to avoid overlapping search windows. The RX hop frequencies
`used shall correspond to the RX slot numbers.
`
`It is recommended that single slot packets are used upon return from hold to
`minimize the synchronization time, especially after long hold periods that
`require search windows exceeding 625 us.
`
`Estimated start of master TX
`
`hop g[2m+2}
`
`Figure 9.3: RX timing of stave returning from hoid state.
`
`9.4 PARK MODE WAKE-UP
`
`The park mode is similar to the hold mode. A parked slave periodically wakes
`up to listen to beacons from the master and to re-synchronize its clock offset.
`As in the return from hold mode. a parked slave when waking up may increase
`the search window from ill) us to a larger value X us as illustrated in Figure
`3.24: on :3-age tit‘).
`
`29 November 1999
`
`TransmitiReceivs ‘firming
`
`AFFLT029331B
`
`Samsung Ex. 1119 p. 90
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 91 of 1082
`
`Baseband Specification
`
`9.5 PAGE STATE
`
`In the page state. the master transmits the device access code (ID packet) cor-
`responding to the stave to be connected, rapidly on a large number of different
`hop frequencies. Since the ID packet is a very short packet, the hop rate can
`be increased from 1600 hopsis to 3200 hopsis. In a single TX slot interval, the
`paging master transmits on two different hop frequencies. In a single RX slot
`interval, the paging transceiver listens on two different hop frequencies; see
`Figgtire
`on page at. During the TX slot, the paging unit sends an ID packet
`at the TX hop frequencies f(k) and iik-I-1). In the RX slot, it listens for a
`response on the corresponding RX hop frequencies f’(k) and f’(k+1). The lis-
`tening periods are exactly timed 625 ps after the corresponding paging pack-
`ets, and include a iii} ps uncertainty window.
`
`TX slot
`
`RX slot
`
`TX slot
`
`I I
`
`I
`hcip rm
`
`hop f{k+1)
`
`hop f‘(k+1]
`
`he
`
`EI
`I
`
`E6Bps
`
`E...............
`
`
`
`E'.'.'.'.'.‘ZZ'.'.'.‘2I'.'.'.'
`
`f(k+2)
`
`hop f(k+3}
`
`____;D_____
`
`Figure 9.4: RX/TX cycie of Biuetooth transceiver in PAGE mode.
`
`9.6 FHS PACKET
`
`At connection setup and during a master-slave switch, an FHS packet is trans-
`ferred from the master to the slave. This packet will establish the timing and
`frequency synchronization (see also Section -4.4.1.4 on page 58). After the
`slave unit has received the page message, it will return a response message
`which again consists of the ID packet and follows exactly 625 ps after the
`receipt of the page message. The master will send the FHS packet in the TX
`slot following the RX slot in which it received the slave response, according the
`RXJTX timing of the master. The time difference between the response and
`FHS message will depend on the timing of the page message the slave
`received. In Figure 54.5 an 5.:-age $32, the slave receives the paging message
`sent first in the master-to-slave slot. It will then respond with an ID packet in
`the first half of the slave-to-master slot. The timing of the FHS packet is based
`on the timing of the page message sent first in the preceding master-to-slave
`slot: there is an exact 1250 ps deiay between the first page message and the
`FHS packet. The packet is sent at the hop frequency f(k+1) which is the hop
`frequency foilowing the hop frequency f(ir) the page message was received in.
`In Ftgtire $3.8 on
`{$2, the slave receives the paging message sent sec-
`ondly in the master-to-slave slot. It will then respond with an ID packet in the
`
`TransmiUReceive 1”iming
`
`29 November ‘I999
`
`AFFLT0293319
`
`Samsung Ex. 1119 p. 91
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 92 of ‘I832
`
`Baseband Specification
`
`Bluetooth-
`
`second half of the slave-to-master slot exactly 625 as after the receipt of the
`page message. The timing of the FHS packet is still based on the timing of the
`page message sent first in the preceding master-to-slave slot: there is an
`exact 1250 3.13 delay between the firs’: page message and the FHS packet. The
`packet is sent at the hop frequency f(k+2) which is the hop frequency following
`the hop frequency f(i<+1) the page message was received in.
`
`mater-to-slave slot
`
`hop f[k+1}
`
`I
`I
`l
`
`mfp me)
`I
`
`I
`I
`I
`
`ho]: t‘{k}
`II
`
`slave-to-I11asler slat
`
`rnasIer—loalave slot
`
`hop 'f[k+1}
`
`Figure 9.5: Timing of FHS packet on successfui page in first haif sioi‘.
`
`master-to-slave slot
`
`I
`I
`I
`
`hclp ttk}
`I
`
`hop flk-I-1}:
`
`;I
`
`E68115
`
`I
`I
`I
`
`niup rm
`II
`
`slave-to-master slot
`
`master-to-slave slot
`
`hop f‘(K+1}
`
`hop rII<+2}
`
`_________E__.I______________3:1 ii
`
`Figure 9.6: Timing of FHS packet on successiui page in second haif sic.-t.
`
`29 November 1999
`
`TransmitiReceive '|'im‘Ing
`
`AFFLT0293320
`
`Samsung Ex. 1119 p. 92
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 93 of 1082
`
`Base-band Specification
`
`The stave will adjust its RXITX timing according to the reception of the FHS
`packet (and not according to the reception of the page message). That is, the
`second response message that acknowledges the reception ofthe FHS packet
`is transmitted 625 ps after the start of the FHS packet.
`
`9.7 MULTI-SLAVE OPERATION
`
`As was mentioned in the beginning of this chapter, the master always starts the
`transmission in the even-numbered slots whereas the slaves start their trans-
`
`mission in the odd-numbered slots. This means that the timing of the master
`and the s|ave(s) is shifted by one slot (625 us), see F5-gore
`on page 933.
`
`Only the slave that is addressed by its AM_ADDR can return a packet in the
`next slave-to-master slot. If no valid AM_ADDR is received, the slave may only
`respond if it concerns its reserved SCO slave-to-master slot. In case of a
`broadcast message, no slave is allowed to return a packet (an exception is
`found in the access window for access requests in the park mode, see é3e=:;i§o:'i
`t{}.E3.»'i- on page TE5).
`
`Figure 9. 7.’ RX/TX timing in muiti-stave configuration
`
`TransmiUReceive filming
`
`29 November 1999
`
`AFFLT0293321
`
`Samsung Ex. 1119 p. 93
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Baseband Specification
`
`29 November 1999
`
`Transmitmeceive '|'|ming
`
`AFFLT0293322
`
`Samsung Ex. 1119 p. 94
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 95 of 1082
`
`Base-band Specification
`
`10 CHAN N EL CONTROL
`
`10.1 SCOPE
`
`This section describes how the channel of a piconet is established and how
`units can be added to and released from the piconet. Several states of opera-
`tion of the Bluetooth units are defined to support these functions. In addition,
`the operation of severai piconets sharing the same area, the so-called scatter-
`net, is discussed. A special section is attributed to the Bluetooth clock which
`plays a major role in the FH synchronization.
`
`10.2 MASTER-SLAVE DEFINITION
`
`The channel in the pioonet is characterized entirely by the master of the picc-
`net. The Bluetooth device address (BD_ADDR) of the master determines the
`FH hopping sequence and the channel access code; the system clock of the
`master determines the phase in the hopping sequence and sets the timing. In
`addition, the master controls the traffic on the channel by a polling scheme.
`
`By definition, the master is represented by the Bluetooth unit that initiates the
`connection (to one or more slave units). Note that the names ‘master' and
`‘slave’ only refer to the protocol on the channel: the Bluetooth units themselves
`are identical; that is, any unit can become a master of a piconet. Once a picc-
`net has been established, master-slave roles can be exchanged. This is
`described in more detail in ffisctiort 13.9.3 on
`‘€23.
`
`10.3 BLUETOOTH CLOCK
`
`Every Bluetooth unit has an internal system clock which determines the timing
`and hopping of the transceiver. The Bluetooth clock is derived from a free run-
`ning native clock which is never adjusted and is never turned off. For synchro-
`nization with other units, only offsets are used that, added to the native clock,
`provide temporary Bluetooth clocks which are mutually synchronized. It should
`be noted that the Bluetooth clock has no relation to the time of day; it can there-
`fore be initialized at any value. The Bluetooth clock provides the heart beat of
`the Bluetooth transceiver. Its resolution is at least half the TX or RX slot length,
`or 312.5 us. The clock has a cycle of about a day. If the clock is implemented
`with a counter, a 28-bit counter is required that wraps around at 223-1. The LSB
`ticks in units of 312.5 us, giving a clock rate of 3.2 kHz.
`
`The timing and the frequency hopping on the channet of a piconet is deter-
`mined by the Bluetooth clock of the master. When the piconet is established,
`the master ciock is communicated to the slaves. Each slave adds an offset to
`
`its native clock to be synchronized to the master clock. Since the clocks are
`free-running, the offsets have to be updated reguiarly.
`
`Channel Control
`
`29 November 1999
`
`AFFLT0293323
`
`Samsung Ex. 1119 p. 95
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 96 of €882
`
`Baseband Specification
`
`Bluetooth-
`
`The clock determines critical periods and triggers the events in the Bluetooth
`receiver. Four periods are important in the Bluetooth system: 312.5 us, 625 ps,
`1.25 ms, and 1.28 s; these periods correspond to the timer bits CLK0, CLK1,
`
`CLK2, and CLK12, respectively, see
`
`‘t{3.‘i -on page 95. Master-to-slave
`
`transmission starts at the even-numbered slots when CLK0 and CLK1 are both
`zero.
`
`IEIEIEIEIIIHIIHEIIIEI
`
`Figure 10.1: Biuetooth ciock.
`
`In the different modes and states a Bluetooth unit can reside in, the clock has
`
`different appearances:
`
`- CLKN
`
`- CLKE
`
`native ctock
`
`estimated clock
`
`- CLK
`
`master clock
`
`CLKN is the