- - - - - -
`
`- - - - - - - - - - - •
`
`TSC to RUs
`
`1
`
`ALH
`(3)
`
`ALH
`(0 )
`
`3
`
`AHYC
`
`ALH
`(0 )
`
`ALH
`(4 )
`
`5
`
`HEAD
`
`I 5
`data
`I
`
`ALH
`(0 )
`
`7
`
`ACK
`( 1 )
`
`ACK
`( 1)
`
`j
`
`1 slot
`<--->
`
`RUs to TS: I
`~I
`
`-
`
`1
`
`1
`\
`
`IRQ/I
`1
`
`1
`
`frame
`
`IHEAD4~1
`
`1
`
`1
`
`1
`
`1
`
`1
`
`1
`
`/
`
`1
`
`1
`\
`
`I !
`
`lAC/I
`I
`
`1
`
`1
`
`1
`
`1
`
`frame
`
`/
`
`\
`frame
`
`/
`
`1-
`
`I -
`
`I
`
`Example A message sequence on a control channel for sending a short data
`message from one radio unit to another radio unit on the same site.
`In this example,
`the data message comprises an address codeword and
`two appended data codewords.
`
`1.
`
`2.
`
`ALH
`
`RQC
`
`3.
`
`AHYC
`
`General Aloha invitation (three-slot frame).
`
`Random access request to transmit a short data message.
`(The request indicates the number of timeslots required
`for the data message:
`in this case,
`two slots.)
`
`Short data invitation message
`acknowledges the RQC message
`instructs the calling unit to send the data
`message in the next two slots
`inhibits random access in the next slot.
`
`4.
`
`HEAD + data
`
`The calling radio unit sends its short data
`message to the TSC.
`In this example the
`message comprises an address codeword (HEAD)
`and two appended data codewords.
`
`5.
`
`HEAD + data
`
`The TSC forwards the short data message to
`the called radio unit.
`
`The second data codeword contains a flag (RSA)
`which is set to '0'
`to inhibit random access
`in the following slot,
`thus reserving the slot
`for a response from the called unit.
`
`6.
`
`ACK
`
`7.
`
`ACK
`
`from the called radio
`Acknowledgement ACK(QUAL=O)
`unit - data message accepted.
`
`Acknowledgement ACK(QUAL=O) sent to the calling unit
`to indicate that the called unit has accepted the
`data message.
`In this example the TSC immediately
`repeats the ACK message,
`for added reliability.
`
`Page 14-2
`
`••••
`•••
`•••••••
`••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 204
`
`

`
`•••••
`•••
`•
`•••••
`•••••••••
`
`14.1
`
`TSC Procedures for Short Data Messages
`
`14.1.1 Responses to a short addressing Roe message
`
`A radio unit requests to send a short data message by generating an
`RQC message, complying with the random acceSB protocol. On receiving a
`short addressing RQC message (with EXT = 1, or with EXT
`0 and IDENT1 set
`to a valid called party ident),
`the TSC shall send one of the following
`responses:
`
`a.
`
`b.
`
`c.
`
`ACKI(QUAL=l), ACKQ(QUAL=l), ACKX or ACKV, with PFIX/IOENT2 as the
`calling unit's individual addresB and IDENTl as the called ident
`(or PABXI for a call to a PABX extension).
`
`ACKT(QUAL=D), with PFIX/IDENT2 as the calling unit's individual
`address.
`
`An AHYC message instructing the calling unit to send its data message.
`
`For acceptable delay, see 7.2.4.
`
`See also 14.1.4 and 14.1.5.
`
`14.1.2 Responses to an extended addressing Roe message
`
`A radio unit requests to send a short data message by generating an
`RQC message, complying with the random access protocol. On receiving an
`extended addressing RQC message (with EXT = 0 and IDENTl = IPFIXI, PSTNGI
`or PABXI),
`the TSC shall send one of the following responses:
`
`a.
`
`b.
`
`c.
`
`ACKI(QUAL=l), ACKX or ACKV(QUAL=O), with the same prefix and
`idents as the RQC.
`
`An AHYC message instructing the calling unit to send the full called
`address information.
`
`An AHYC message instructing the calling unit to send its data message.
`
`For acceptable delay, see 7.2.4.
`
`See also 14.1.3 to 14.1.5.
`
`14.1.3
`
`Instruction to send extended address information
`
`the TSC may demand
`After receiving an extended addressing RQC message,
`the full called address (if appropriate), by sending the AHYC message with:
`
`the same prefix and idents as the RQC
`(i.e.
`IDENT1 set to IPFIXI, PSTNGI or PABXI as appropriate, and
`PFIX/IDENT2 set to the calling unit's address)
`DESC set to indicate the appropriate gateway (see 5.5.3.2.8)
`SLOTS set to correspond to the RQC
`(i.e.
`if IDENT1=PSTNGI and FLAGl=l
`SLOTS='Ol').
`
`then SLOTS='lO' else
`
`The AHYC message instructs the calling unit to send the called party
`address information in the following SLOTS slot(s) (see 9.2.2.1).
`If the
`TSC does not successfully decode the address information,
`it may repeat the
`AHYC message or transmit ACKV(QUAL=O)
`to indicate failure of the
`transaction.
`
`Page 14-3
`
`Petitioner Cox Communications - Exhibit 1005 Page 205
`
`

`
`•
`•
`••
`
`••• ••••••••••••• ••
`
`•
`
`Note that, when the radio unit sends its short data message,
`it
`supplies the called address (prefixjident)
`in the data message header.
`Therefore,
`for an interprefix call,
`the TSC need not demand the called
`address separately unless it is required for operational convenience.
`
`•
`
`14.1.4
`
`Instruction to send the short data message
`
`the TSC may demand the short data
`After receiving an RQC message,
`message from the calling radio unit by sending the AHYC message, with:
`
`IDENT1 set to SDMI
`PFIXjIDENT2 set to the calling unit's address
`DESC set to '000'
`SLOTS equal to SLOTS from the RQC.
`
`The AHYC message instructs the calling unit to send its short data message
`in the following SLOTS slots (see 9.2.2.1).
`If the TSC does not
`successfully decode the short data message, it may repeat the AHYC message
`or transmit ACKV(QUAL=O)
`to indicate failure of the transaction.
`
`Note that AHYC bars random access only in the first following return
`slot. When demanding a short data message,
`the TSC shall take appropriate
`action to reserve the subsequent return slot(s) if they are within a frame
`(e.g. by sending the AHY message with both idents set to DUMMYI).
`
`14.1.5 Acknowledgements sent to indicate progress of ROC transaction
`
`The TSC may send acknowledgement messages to indicate to a calling
`radio unit the progress of its short data transaction -
`for idents, see
`5.5.2.1.
`(For an extended addressing call, acknowledgements ACKQ,
`ACKV(QUAL=l), ACKT(QUAL=O) and ACK(QUAL=O) are not appropriate until the
`called address has been obtained. Acknowledgements ACKQ(QUAL=O) and
`ACK(QUAL=O) are not appropriate until the short data message has been
`obtained.)
`
`ACKI
`
`(QUAL=l )
`
`ACKQ (QUAL=O)
`ACKQ (QUAL=l)
`ACKX (QUAL=O)
`
`ACKX (QUAL=l )
`ACKV (QUAL=O)
`
`ACKV (QUAL=l )
`
`ACKT (QUAL=D)
`ACK
`(QUAL=O)
`
`Intermediate acknowledgement; more signalling to
`follow.
`for further signalling.
`System is busy. Wait
`Called party engaged. Wait for further signalling.
`Invalid call e.g. TSC does not support short data
`messages, or called party is not
`equipped to accept the message.
`System or called unit overload; message rejected.
`Called unit not
`in radio contact or transaction
`abandoned.
`Called party engaged (and TSC will not hold the
`request) or called unit does not wish to accept the
`message.
`Called party's data calls have been diverted.
`Transaction has been successfully completed.
`
`For maximum acceptable delay of repeats of acknowledgements ACKX, ACKV,
`ACKT and ACK, see time-out TB in 14.2.4.
`
`Page 14-4
`
`Petitioner Cox Communications - Exhibit 1005 Page 206
`
`

`
`•••••••••••••••••••••••
`
`14.1.6 Availability check on called radio unit
`
`the TSC may
`Before transmitting a short data message to a radio unit,
`check that the unit is in radio contact
`(and suitably equipped).
`It uses
`the AMY message, with:
`
`bit POINT set to '0'
`bit CHECK set to '0'
`bit D set to '1'
`bit E set to '0'
`bit AD set to '0'
`PFIX/IDENTl as the called unit's address
`IDENT2 set to SDMI.
`
`The AHY message demands a response in the following slot from the called
`unit
`(see 9.2.2.26).
`
`The TSC may indicate the result of the availability check to a calling
`radio unit by sending appropriate acknowledgement(s)
`(see 14.1.5).
`
`14.1.7
`
`Informing called party
`
`The TSC transmits a short data message to a radio unit, a group or all
`units in the system by sending the HEAD message on a control channel (see
`5.6.2).
`The data message may have originated from the TSC itself, or from
`a radio unit (using RQC etc.), a line unit, a PABX extension or the PSTN.
`
`The HEAD address codeword indicates the number of appended data
`codewords (up to four),
`and contains two 20-bit addresses:
`the called
`address and calling address (or gateway).
`The user data is contained in
`the data codewords.
`For an individually addressed short data message sent
`within a
`frame,
`the TSC shall set the RSA flag in the last data codeword
`(or in the "filler" data codeword) to '0', to inhibit random access in the
`next slot.
`
`the HEAD message
`For an individually addressed short data message,
`If the response is
`demands a response from the called unit
`(see 14.3.1.1).
`ACK(QUAL=O), ACKX or ACKV(QUAL=l),
`the TSC may send appropriate
`acknowledgement(s)
`to a calling radio unit
`(see 14.1.5).
`If the TSC does
`not successfully decode a response, or if the response is ACKB(QUAL=1),
`it
`may repeat the HEAD message.
`If the called unit cannot be contacted,
`the
`TSC may indicate the failure to the calling unit by sending ACKV(QUAL=O).
`
`For a short data message addressed to a group (or system-wide),
`called units do not respond;
`the TSC may repeat the data message, to
`increase the probability of successful receipt. After transmitting the
`short data message,
`the TSC may send ACK(QUAL=O)
`to a calling radio unit.
`
`the
`
`14.1.8 Aborting the transaction
`
`A calling radio unit may abort its short data transaction by
`generating an RQX message (see 5.5.3.1.3), complying with the random access
`protocol. On receiving an RQX message aborting a short data transaction,
`the TSC shall send a response: ACK(QUAL=l) with the same prefix and idents
`as the RQX.
`
`Page 14-5
`
`Petitioner Cox Communications - Exhibit 1005 Page 207
`
`

`
`14.1.9
`
`TSC time-out
`
`The TSC may operate a time-out on the maximum time for which it holds
`a short data message (for example, waiting for the called party to be
`free).
`
`The TSC may instruct a calling radio unit to restart its waiting timer
`TJ or TW, by sending the AHY message with bit POINT set to '1'; see 9.1.1.7
`and 9.2.2.3.
`If a time TJ or TW, minus the tolerance on the radio unit's
`timer, elapses since the last message it received for a short data
`transaction (from the calling unit),
`the TSC shall not send any further
`signalling for the transaction.
`See also 14.2.6.
`
`Page 14-6
`
`•••••••••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 208
`
`

`
`••
`
`14.2
`
`Procedures for Radio units Sending Short Data Messages
`
`in
`A radio unit shall make only one call attempt at a time (except
`emergency); while attempting access or waiting for a terminating (i.e. end(cid:173)
`of-transaction) acknowledgement to a short data message request,
`the unit
`shall not request another non-emergency call of any type (unless the user
`first aborts the original transaction).
`
`14.2.1 Request for a short data transaction
`
`A radio ,unit requests to transmit a short data message by sending an
`RQC message on a control channel, complying with the random access protocol
`(see 7.3).
`The fields in the RQC message shall be set appropriately (see
`5.5.3.1.8); however, note particularly that:
`
`a.
`
`b.
`
`Field SLOTS specifies the number of timeslots required for the
`data message (minLmum two slots, maximum three slots).
`An extended addressing request is indicated by setting IOENT1 in the
`RQC message to the appropriate gateway (viz.
`IPFIXI, PSTNGI or PABXI).
`
`The unit shall attempt access until it receives a valid response (see
`14.2.2/3), or until its user aborts the transaction (see 14.2.7), or until
`the access attempt fails (i.e.
`the unit has sent the maximum number of
`transmissions NR and received no response, or its access time-out TC has
`expired (see 7.3.8».
`In the case of access failure,
`if the unit has not
`sent a request,
`it shall return to the idle state (and may indicate the
`failure to the user); otherwise, it shall wait for further signalling for
`the transaction - see 14.2.4 to 14.2.6.
`
`14.2.2 Valid responses to a short addressing RQC
`
`the calling unit shall accept the
`For a short addressing RQC,
`following messages as a response to its RQC and send no more requests:
`
`a.
`
`b.
`
`c.
`
`ACKI(QUAL=l), ACKQ(QUAL=l), ACKX or ACKV, with PFIX/IOENT2 as its
`individual address and IOENT1 as the called ident
`(or PABXI for a PABX
`call).
`
`ACKT(QUAL=O) with PFIX!IOENT2 as its individual address.
`
`AHYC, with PFIX/IOENT2 as its individual address and IOENT1 as SOMI.
`
`For other actions on receiving these messages, see 14.2.4 and 9.2.2.1.
`
`14.2.3 Valid responses to an extended addressing ROC
`
`the calling unit shall accept the
`For an extended addressing RQC,
`following messages as a response to its RQC and send no more requests:
`
`a.
`
`b.
`
`c.
`
`ACKI(QUAL=l), ACKX or ACKV(QUAL=O), with the same prefix and idents as
`the RQC.
`
`AHYC, with the same prefix and idents as the RQC.
`
`AHYC, with PFIX/IOENT2 as its individual address and IOENT1 as SOMI.
`
`For other actions on receiving these messages, Bee 14.2.4 and 9.2.2.1.
`
`Page 14-7
`
`•••••••••
`
`•••
`•
`••
`•••
`••
`
`•••
`
`Petitioner Cox Communications - Exhibit 1005 Page 209
`
`

`
`- - - - - - - - -
`
`14.2.4 Acknowledgement received
`
`If a radlo unit attempting access or waiting for further signalling
`for a short data transaction receives an appropriate acknowledgement then
`it shall take action as indicated below.
`(ACKQ, ACKV(QUAL=l), ACKT(QUAL=O)
`and ACK(QUAL=O) are not appropriate until the called address information
`has been sent -
`in the RQC, as extended address information or in the short
`data message.
`ACKQ(QUAL=O) and ACK(QUAL=O) are not appropriate until the
`short data message has been sent.)
`For idents, Bee 5.5.2.1.
`
`ACKI
`
`(QUAL=l)
`
`ACKQ (QUAL=O)
`ACKQ (QUAL=l)
`ACKX (QUAL=O)
`ACKX (QUAL=l)
`ACKV (QUAL=O)
`
`ACKV (QUAL=l)
`
`ACKT (QUAL=O)
`ACK
`(QUAL=O )
`
`Intermediate acknowledgement; more signalling to
`follow.
`System is busy. Wait for further signalling.
`Called party engaged. Wait for further signalling.
`Invalid call; message rejected.
`System or called unit overload; message rejected.
`Called unit not
`in radio contact or transaction
`abandoned.
`Called party engaged (and TSC will not hold the
`request) or called unit does not wish to accept the
`message.
`Called party's data calls have been diverted.
`Transaction has been successfully completed.
`
`the unit shall wait for further
`If ACKI(QUAL=l) or ACKQ is received,
`signalling and may indicate to the user the progress of the transaction.
`
`the unit shall return to the idle state
`If ACKX or ACKV is received,
`and may indicate to the user the reason for the failure of the transaction;
`it is recommended that receipt of ACKX(QUAL=O) be indicated in a distinct
`manner.
`
`If a complete ACKT(QUAL=O) message is received, the unit shall either:
`
`a.
`
`b.
`
`return to the idle state (and may indicate to the user that
`party's data calls have been diverted), or
`attempt a new short data transaction to the diversion address
`given in the ACKT message.
`
`the called
`
`If an incomplete ACKT(QUAL=O) message is received,
`
`then:
`
`i)
`
`ii)
`
`it shall
`If the unit does not require the diversion address,
`return to the idle state (and may give an indication to the user).
`If the unit does require the diversion address then:
`if still attempting access for the transaction,
`it shall
`ignore the message and continue to attempt access;
`otherwise it shall wait for a repeat ACKT, returning to the idle
`state if a time TB elapses (in which case,
`it may indicate the
`failure to the user).
`
`the unit shall return to the idle state
`is received,
`If ACK(QUAL=O)
`and may indicate to the user that the transaction has been successfully
`completed i.e.
`that:
`
`the called unit has accepted the short
`for an individual call,
`data message;
`(note that this does not imply user acceptance);
`
`Page 14-8
`
`••
`
`•
`
`••••••••
`••••
`••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 210
`
`

`
`••••••••••••••••
`
`•••••
`
`for a group (or system-wide) call,
`been sent to the group.
`
`the short data message has
`
`the unit shall
`After receiving ACKX, ACKV or ACK for the transaction,
`not request another non-emergency call of any type to the same called ident
`(or gateway)
`for at
`least a time TB. After receiving ACKT for the
`transaction,
`the unit shall not request another non-emergency call of any
`type for at least a
`time TB.
`
`14.2.5 Sending the short data message
`
`The calling unit shall transmit its short data message (a HEAD address
`codeword and appended data codeword(s)
`- see 5.6.2) on receipt of an
`appropriate AHYC from the TSC; see section 9.2.2.1.
`
`14.2.6 Time-out after waiting
`
`A calling radio unit waiting for further signalling for a short data
`transaction shall return to the idle state if a time TJ (for a data message
`addressed to the TSC) or TW (for other destinations) has elapsed since the
`last signalling message it sent for the transaction, viz.
`
`or
`
`requesting the transaction (see 14.2.1)
`RQC,
`SAMIS, providing extended address information for the call
`9.2.2.1)
`containing the short data message (see 14.2.5 and 9.2.2.1)
`or HEAD,
`or ACK(QUAL=O), sent
`in response to an AHY message with bit POINT = 1
`and IDENT1 as the called ident or gateway (see 9.2.2.3).
`
`(see
`
`It may also indicate to the user that the outcome of the transaction is
`unknown.
`
`14.2.7 Aborting the transaction
`
`A radio unit may abort a short data transaction (after sending an RQC
`and while still waiting to receive ACKX, ACKV, ACKT or ACK) by transmitting
`an abort transaction request RQX (see 5.5.3.1.3), complying with the random
`access protocol.
`It shall attempt access until one of the following
`occurs:
`
`a.
`
`b.
`
`c.
`
`It receives ACK(QUAL=l) with the same prefix and idents as the RQX.
`In this case,
`it may indicate to the user that the outcome of the
`transaction is unknown.
`
`for the
`It receives ACK(QUAL=O), ACKX, ACKV or ACKT(QUAL=O)
`transaction it is attempting to abort.
`See also 14.2.4.
`
`It has sent the maximum number of transmissions NR and received no
`response, or its access time-out TC has expired (see 7.3.8).
`In this
`case,
`it shall return to waiting for signalling for the short data
`transaction (see 14.2.4 to 14.2.6).
`
`In cases a. and b.,
`
`the unit shall return to the idle state.
`
`•
`I ~--------
`
`Page 14-9
`
`-----J
`
`Petitioner Cox Communications - Exhibit 1005 Page 211
`
`

`
`14.3
`
`Procedures for All Radio Units on a Control Channel
`
`The procedures in this section shall be obeyed by all radio units that
`are equipped to recognise a received HEAD address codeword.
`(The
`requirement to recognise HEAD will be system-dependent.)
`
`14.3.1
`
`Receiving short data message (HEAD)
`
`14.3.1.1
`
`Individually addressed HEAD message
`
`If a radio unit on a control channel receives a HEAD message with
`PFIX1/IDENTl matching its individual address then it shall respond with the
`appropriate acknowledgement (see below), with PFIX/IDENTl as its individual
`address and IDENT2 set to IDENT2 from the HEAD.
`The HEAD address codeword
`contains a field (LEN) which indicates the number of appended data
`codewords;
`the unit shall respond in the slot following the last data
`codeword.
`For timing, see 6.2.1.3.
`
`a.
`
`b.
`
`If the unit is not equipped to accept the data message then it shall
`send ACKX (QUAL=O).
`
`Otherwise, the unit shall send one of the following acknowledgements:
`
`ACKB (QUAL=l)
`
`if not all the appended data codewords were
`decode able and the unit requires the message
`to be retransmitted
`
`or
`
`ACKX (QUAL=l) if it cannot accept the message at this time
`(e.g.
`its data store is full)
`
`or
`
`ACKV (QUAL=l)
`
`if it does not wish to accept a data message
`from this calling party
`
`or
`
`ACK
`
`(QUAL=O)
`
`if it has accepted the data message.
`
`14.3.1.2 HEAD message addressed to a group
`
`If a radio unit on a control channel receives a HEAD message with
`PFIX2/IDENT2 not matching its individual address, and
`
`PFIX1/IDENTl matching one of its group addresses for this system
`
`or
`
`IDENTl set to the system-wide all-call ident ALLI,
`
`then it may accept the information contained in the HEAD address codeword
`and the appended data codewords, but shall transmit no response.
`
`Page 14-10
`
`•••••
`•••••••••
`••••••••
`
`•
`
`Petitioner Cox Communications - Exhibit 1005 Page 212
`
`

`
`•••••••••••••••••••••••
`
`15.
`
`DATA INTBRROGATION PROCBDURllS
`
`This section defines data interrogation procedures, which allow the
`TSC to demand that an addressed radio unit transmits a data message of a
`prescribed type. This demand is an interrogation by the TSC, not part of
`the signalling for a call requested by the radio unit.
`It may be sent on
`either a control channel or an allocated traffic channel.
`
`The TSC interrogates the radio unit by sending message AHYC, Mode 2
`(see 5.5.3.2.8).
`In this message, PFIX/IDENTl is set to the radio unit's
`individual address and IDENT2 is the ident of the interrogator (a non(cid:173)
`radio-unit ident).
`The type of data to be transmitted by the radio unit is
`indicated by the descriptor field DESC and the non-radio-unit ident.
`
`The TSC does not acknowledge receipt of the radio unit's data message
`(though it may take appropriate action as a result of the received data).
`
`for data interrogation, only one value of the data message
`Currently,
`descriptor field DESC has been assigned. This value is used for
`implementing serial number checks:
`the TSC may at any time, on a control
`channel or traffic channel,
`instruct a radio unit to send its 38-bit serial
`number. Comparison of the received serial number with the expected value
`(held in store at the TSC) will assist in the detection of fraudulent
`users.
`
`Page 15-1
`
`Petitioner Cox Communications - Exhibit 1005 Page 213
`
`

`
`15.1
`
`Data Interrogation Procedures for TSC
`
`15.1.1 Data interrogation on a control channel
`
`The TSC may demand that a radio unit on a control channel transmits a
`data message of a prescribed type, by sending the AHYC message with:
`
`PFIX/IPENTl set to the individual address of the radio unit
`
`IDENT2 set to the ident of the interrogator
`IDENT2 = TSCI)
`(for example,
`for a serial number check,
`
`DESC set to indicate the type of data message required; see 5.5.3.2.8
`for a serial number check, DESC = '000')
`(for example,
`
`SLOTS set appropriately; see 5.5.3.2.8
`for a serial number check, SLOTS = '01').
`(for example,
`
`The AHYC message instructs the addressed radio unit to transmit a data
`message in the following SLOTS slot(s)
`(see 15.2.1).
`If the TSC does not
`successfully decode a reply, it may repeat the AHYC message when
`convenient.
`(The TSC does not acknowledge receipt of the data message).
`
`Note that AHYC bars random access only in the first following return
`slot. When demanding a multi-codeword data message,
`the TSC shall take
`if they are
`appropriate action to reserve the subsequent return slates)
`within a frame (e.g. by sending the AHY message with both idents set to
`DUMMYI).
`
`15.1.2 Data interrogation on a traffic channel
`
`The TSC may demand that a radio unit on an allocated traffic channel
`transmits a data message of a prescr~bed type, by sending the AHYC message
`with:
`
`PFIX/IDENTl set to the individual address of the radio unit
`IDENT2 set to the ident of the interrogator
`DESC set to indicate the type of data message required; see 5.5.3.2.8
`SLOTS set appropriately; see 5.5.3.2.8.
`.
`
`The AHYC message instructs the addressed radio unit to transmit a data
`message (see 15.2.2).
`If the TSC does not successfully decode a reply,
`may repeat the AHYC message.
`
`it
`
`Page 15-2
`
`•••
`
`••••••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 214
`
`

`
`••••
`•••
`••
`••••••
`••••••
`
`••
`
`15.2
`
`Procedures for All Radio Units
`
`The procedures in this section shall be obeyed by all radio units that
`are equipped to recognise a received Mode 2 AHYC message.
`(The requirement
`to recognise AHYC, Mode 2 will be system-dependent.)
`
`15.2.1 Data interrogation message IAHYC, Mode 21
`on a control channel
`
`If a radio unit on a control channel receives an AHYC message with
`PFIX/IDENTl matching its individual address then it shall either send a
`data message in the following SLOTS slot(s), or transmit ACKX(QUAL=O), as
`indicated below.
`For timing , see section 6.2.1.3.
`
`If
`
`and
`and
`and
`
`IDENT2 is set to TSCI
`is set to '000'
`DESC
`SLOTS
`is set to '01'
`the unit is equipped to transmit its serial number on interrogation
`
`then it shall transmit its serial number, conforming to the codeword format
`defined in section 5.6.1.2.2 (SARIS, Mode 2, DESC='OOO').
`(The form of the
`serial number is system-dependent.)
`
`Otherwise
`The unit shall transmit ACKX(QUAL=O), with the same prefix and idents as
`the AHYC.
`
`15.2.2 Data interrogation message (AHYC, Mode 21
`on an allocated traffic channel
`
`If a radio unit on a traffic channel receives an AHYC message with
`a
`PFIX/IDENT1 matching its individual address then it shall either send
`data message or transmit ACKX(QUAL=O), as indicated below.
`For timing, see
`section 6.2.2.2.
`
`If
`
`and
`and
`and
`
`IDENT2 is set to TSCI
`is set to '000'
`DESC
`SLOTS
`is set to '01'
`the unit is equipped to transmit its serial number on interrogation
`
`then it shall transmit its serial number, conforming to the codeword format
`defined in section 5.6.1.2.2 (SAMIS, Mode 2, DESC='OOO').
`
`Otherwise
`The unit shall transmit ACKX(QUAL=O), with the same prefix and idents as
`the AHYC.
`
`Page 15-3
`
`Petitioner Cox Communications - Exhibit 1005 Page 215
`
`

`
`•••••••••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 216
`
`

`
`•••••••••••••••••••••••
`
`16.
`
`ADDITIONAL SHORT DATA PROCBDURIlS e.g. SAKs
`
`Additional short data procedures are not included in this issue.
`
`Page 16-1
`
`Petitioner Cox Communications - Exhibit 1005 Page 217
`
`

`
`- - - - - - - - - - - - - - - - - - -•••••••••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 218
`
`

`
`••••
`
`•••••••••••••••••••
`
`17
`
`STANDARD DATA PROCEDURES
`
`17.0
`
`Introduction
`
`This section defines the procedures for setting up data calls and then
`transmitting Tmessages (see 2)
`in a standard manner on a standard data
`traffic channel
`(the data channel). A base station may include several data
`channels.
`
`Data may be transferred between the following parties:
`
`line unit, radio unit or group
`radio unit ---> TSC,
`radio unit ---> all standard data equipped (SDE) units in system
`radio unit ---> PABX extension (short or long extension number)
`radio unit ---> PSTN destination (prearranged or general)
`radio unit ---> Public Data Network (PDN) subscriber
`---> radio unit, group or all SDE units in system
`TSC
`---> radio unit, group or all SDE units in system
`line unit
`PABX extn. ---> radio unit, group or all SDE units in system
`PSTN terminal-> radio unit, group or all SDE units in system
`---> radio unit, group or all SDE units in system
`PDN user
`
`Set-up of a new data call is initiated by the RQD request transmitted
`on either the control or data channel. For this and other purposes the data
`channel has random access frames interspersed with the user data being
`conveyed.
`
`The data channel provides a link between the TSC and radio unit for
`the purposes of a data call. For an individual
`link with the TSC, errors on
`the data channel are corrected as necessary by automatic request
`for
`repetition (ARQ) before the data is passed on to any other data link or
`equipment,
`i.e. operation is "store and forward". The TSC may limit the
`time for which it will store a call if it finds difficulty in forwarding
`it. For a call between radio units at least two links are necessary.
`
`One data channel at a base station may be shared at one time by up to
`1023 links, several of which may be concurrently active, although the mean
`data transfer rate experienced by each active radio unit is liable to
`reduce as the total activity increases. The TSC is the master station and
`controls all transmissions on the data channel so as to avoid any
`simultaneous transmissions (except random access ones)
`from radio units on
`the return channel.
`
`Page 17-1
`
`Petitioner Cox Communications - Exhibit 1005 Page 219
`
`

`
`17.0.1
`
`Facilities offered by the Standard Data Procedures
`
`Facilities offered by these procedures are:
`
`a)
`
`b)
`
`c)
`
`d)
`
`e)
`
`f)
`
`g)
`
`h)
`
`j )
`
`k)
`
`1 )
`
`m)
`
`n)
`
`p)
`
`radio units operate in a half-duplex mode with bidirectional Tmessage
`transmission facility,
`
`for group calls the data in the link from the TSC to the group is not
`corrected by automatic request
`for repetition but may be repeated up
`to a prearranged number of times to increase the probability of
`successful reception by all group members,
`
`a data call may be conducted with an individual radio unit or
`transmitted to a group of radio units, and in the latter case
`responses may be obtained either by separate polling of each radio
`unit in the group or by inviting random access from group members,
`
`the calling party may request that a call shall be directed to any
`one of B sub-addresses (PORTs), e.g. to call a particular receiving
`terminal configuration,
`
`an end-to-end high accuracy data transfer (HADT) mode may be invoked,
`
`a calling radio unit may request priority for resources for a data
`call,
`
`a calling radio unit may make a request for an interactive data
`exchange with the called party so that the TSC will test whether a
`suitable radio channel is available and the called party is ready to
`exchange data,
`
`urgent calls may be requested,
`
`a suitably equipped radio unit may engage in more than one data call
`concurrently,
`
`any called party can be informed of the identity of the calling
`party,
`
`the calling party is given a reason for any call set-up failure,
`
`a data call may consist of a single Tmessage (see NOTE 1), or may
`include a response or a number of data interchanges with pauses
`between the various Tmessages,
`
`each link provided via a data channel is bit-transparent (see NOTE
`2) ,
`
`the standard data signalling rate is 1200 bit/s, with provision for a
`customised rate (see NOTE 3), and
`
`Page 17-2
`
`••••••••••••••••
`
`•••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 220
`
`

`
`q)
`
`radio units may be transferred individually or in groups from one
`data channel to another so that relief data channels may be created
`and brought
`into use when a data traffic overload occurs and can be
`taken out of use when the overload subsides. Also a radio unit on a
`data channel may be transferred collectively to another data channel.
`
`NOTE 1.
`
`NOTE 2.
`
`NOTE 3.
`
`No specific "mail-box" facility is listed but all the
`ingredients necessary to provide that facility are available.
`
`Users concerned about unauthorised reception may wish to take
`advantage of this facility by encrypting their data.
`
`links of a call may transmit at different rates
`The individual
`because of the storage provided by the TSC. No customised rate
`is prescribed by this standard.
`
`page 17-3
`
`••
`
`•••
`
`•••••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 221
`
`

`
`17.0.2
`
`Guide to Some Key Protocol Aspects
`
`17.0.2.1 Data Channel Addressing
`
`On the data channel it would be wasteful of time always to use address
`codewords including the full
`identity of both the sender and recipient of a
`if two radio units are involved they each
`transmission dataitem. Moreover,
`have their own link with the TSC(s), and these links often act at different
`times because of the store and forward nature of the facility. Therefore on
`the data channel,
`instead of Prefixes and Identities, each radio unit uses
`a IQ-bit transaction number termed a "TRANS" which identifies that
`link
`during that call and is assigned by the TSC in a "Go-to-TRANS"
`(GTT)
`message sent during the call set-up phase. The TRANS validity ceases when
`the link closes, and the TRANS value may then be reused for a new link. A
`is reserved for use in messages whenever no
`dummy TRANS value '0000000000'
`allocated value is appropriate.
`
`the use of certain addresswords
`from the use of TRANS,
`Apart
`containing a PFIX and IDENT(s) also is valid on a data channel
`in
`appropriate circumstances.
`
`17.0.2.2 Data channel
`
`format
`
`All messages on the data channel conform to the traffic channel format
`described in section 3. On the forward channel preamble and SYNT are found
`in the last half of a Data Channel System Codeword (DCSC), equivalent to
`the CCSC of a control channel but with SYNC replaced by SYNT, see 5.1.
`
`The standard allows for two possible transmission rates, viz 1200
`bitls and a customised one. Only one rate is used on anyone channel. All
`stations must be able to utilize the 1200 bitls rate, but use of the
`customised one is optional. A calling or individually called radio unit
`states whether it could operate at the customised rate in its respective
`RQD or acknowledgement message. The TSC specifies the rate for each TRANS
`in the relevant GTT message, but must not specify the customised rate
`unless both TSC and radio unit can use it. At 1200 bitls the timing of a
`radio unit message relative to the TSC "invoking message" is as described
`in 6.2.1.3, but for any customised rate this timing is specified elsewhere.
`Some timing criteria are outlined in Appendix 6.
`
`in some ways,
`is similar to a control channel
`format
`The data channel
`consisting of random and non-random transactions with radio units. However,
`because the transactions are often lengthy, differences between data and
`control channel are:
`
`a)
`
`b)
`
`c)
`
`d)
`
`because of the long messages a TSC may transmit, on the forward
`channel DCSCs are infrequent compared to CCSCs,
`
`the concept of time-slots only applies