if IDENTl
`
`is not equal to PSTNGI
`
`then SLOTS = '01')
`
`then it shall transmit the full called address information,
`conforming to the codeword formats defined in section 5.6.1.2.2
`(SAMIS, Mode 1).
`
`Otherwise
`
`the unit shall transmit ACKX(QUAL=O), with the same prefix and idents
`as the AMYC.
`
`17.1.2.4.2 Data availability/rate check on individually
`called radio unit
`
`If a radio unit on a data channel receives an AHYD message with
`PFIX/IDENTl matching its individual address then it shall respond with the
`appropriate acknowledgement (see below), with the same prefix and idents as
`the AMYD.
`If bit AD = 0 in the AHYD message,
`the unit shall respond in the
`if bit AD = 1, a data codeword is
`slot following the AHYD address codeword;
`appended (containing the calling address) and the unit shall respond in the
`slot following the data codeword. For timing on a 1200 bit/s data channel,
`see 6.2.1.3.
`
`A)
`
`Incoming standard data call
`
`:
`
`IDENT2 not equal to DUMMYI
`
`The unit shall send one of the following acknowledgements:
`
`if it is not equipped to accept standard data calls
`ACKX (QUAL=O)
`from this calling party.
`
`if it cannot accept this standard data call at this
`ACKX (QUAL=l)
`it cannot process concurrent calls or its data store is
`time (e.g.
`full or interaction has been requested but is not
`immediately
`possible).
`
`if it does not support one or more of the requested
`ACKV (QUAL=l)
`facilities,
`i.e. does not support HADT or interaction or cannot
`accept the wanted PORT.
`
`if AD = 1 in the AHYD message but the appended data
`ACKB (QUAL=l)
`codeword was not decode able and the unit requires the message to be
`retransmitted.
`
`if it is available for a standard data call of this
`(QUAL=O)
`ACK
`i.e.
`it can support the particular parameter settings of the
`type;
`In this case,
`the unit shall set bit MODEM to the value
`AHYD.
`appropriate for that channel; see 5.5.2.2.
`
`The unit may indicate to its user the caller (by reference to
`PFIX/IDENT2 from the AHYD message or PFIX2/IDENT2 from the data codeword)
`and whether interaction is required, and whether the incoming call
`is an
`emergency call
`(by reference to bit E from the AHYD).
`
`After receiving an AHYD message for an incoming individual standard data
`call and responding with ACK(QUAL=O),
`the unit shall wait for a GTT message
`for the call (i.e.
`a GTT message with PFIX/IDENT as its individual address,
`
`Page 17-36
`
`••••••
`•••••••••••
`••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 254
`
`

`
`•••••
`••••
`•••
`••••••
`••
`•••
`
`bit O/R set to '0', an acceptable RATE and CHAN set to the number of this
`data channel), or until it assumes that the call will not take place (see
`17.1.2.4.4) .
`
`If, while waiting for an incoming individual standard data call, a
`radio unit receives a repeat AHYD then it shall send the appropriate
`it
`acknowledgement;
`also,
`for ACK(QUAL=O),
`shall
`restart its timer
`TA/TDA.
`
`B)
`
`"No-call" test availability check:
`
`lDENT2 = OUMMY!
`
`The unit may indicate that it is not suitably equipped by sending
`ACKX(QUAL=O). Otherwise it shall send ACK(QUAL=O).
`
`ACKX (QUAL=O)
`
`The unit could not at any time accept a standard
`data call with the parameter settings of the AHYD.
`
`ACK
`
`(QUAL=O)
`
`is in radio contact and could at times accept
`Unit
`a data call with the parameter settings of the
`AHYD.
`
`This availability check does not start or restart any timer.
`
`17.1.2.4.3 Cancelling waiting state of individually called radio unit
`
`If a radio unit on a data channel receives an AHYX message with
`PFIX/IDENTl matching its individual address then it shall respond in the
`next slot with ACK(QUAL=l), with the same prefix and idents as the AHYX.
`
`A radio unit that has received an AHYD message for an incoming
`individual standard data call
`(see l7.l.2.4.2A), and responded with
`ACK(QUAL=O), shall assume that the call will not take place if one of the
`following occurs:
`
`a.
`
`b.
`
`c.
`
`It has not received a GTT message for the call at a time TDA after
`the last ACK(QUAL=O) it sent
`in response to an AHYD for the call.
`
`It receives an AHYX message with the same prefix and idents as AHYD.
`
`It receives an AHYD message checking its availability for a different
`incoming individual standard data call (i.e. bit E and/or the calling
`address and/or the PORT is different
`from the original AHYD).
`
`The unit may indicate to the service user that the expected data call will
`not take place.
`In case c.,
`the unit shall obey the procedures in
`l7.l.2.4.2A for the new call.
`
`17.1.2.4.4 Receiving AHYD message addressed to a group or
`ALL!
`
`If a radio unit on a data channel receives an AHYD message with
`
`PFIX/IDENTl matching any of its group addresses for this system
`
`or
`
`IDENTl set to the system-wide all-call ident ALLI
`
`Page 17-37
`
`Petitioner Cox Communications - Exhibit 1005 Page 255
`
`

`
`then it may accept the call information contained in the AHYD codeword and
`indicate it, but shall transmit no response.
`The unit may then assume that
`the next GTT(O/R=O) message,
`for this group or ALLI address and with CHAN
`equal to the number of this data channel, received within the following
`time TDA corresponds to the:
`
`i)
`
`calling address
`(PFIX/IOENT2 or PFIX2/IDENT2 from an appended data codeword)
`
`ii)
`
`E bit
`
`iii)
`
`PORT
`
`announced by the AHYD message.
`
`If the unit has not received a GTT(OjR=O) message at a time TDA after
`the last received AHYD for the call, or if it receives an AHYD message for
`a different call to this address,
`then it may assume that the expected call
`will not take place.
`
`17.1.2.4.5 Receiving GTT message for same data channel
`
`If a radio unit on a data channel receives a GTT message with channel
`number CHAN equal to the number of the data channel
`then it shall obey the
`procedure in this section.
`The procedure if CHAN is not equal to the
`number of the data channel is specified in section 17.2.6.2 (In-call
`transfer).
`
`A radio unit on a data channel shall check all GTT messages it
`receives to see whether the channel number CHAN is equal to the number of
`this data channel and whether the message is addressed to it,
`that is,
`whether:
`
`PFIX/IDENT from the GTT message matches its individual address
`
`or PFIX/IDENT matches any of its group addresses for this system
`
`or IOENT is the system-wide all-call ident ALLI.
`
`If the GTT message is addressed to it, and TRANS >'0000000000', and
`it is able to receive on this data channel at the specified RATE,
`then the
`unit shall use the appropriate rule below to decide whether to accept the
`GTT:
`
`a.
`
`b.
`
`If the unit is currently waiting for a transaction number for this
`address and bit O/R, having received a GTT message on a control
`channel with TRANS = '0000000000'
`(see l7.l.2.3.4c.),
`then it shall
`accept
`the GTT message as applying to that call.
`
`to '1· and PFIX/IDENT from the GTT message matches
`If bit O/R is set
`its individual address,
`then:
`
`If the unit is making an emergency call RQD(E=l) and has not
`received ACKE(QUAL=O) or AHY(E=l),
`then it shall
`ignore the
`GTT.
`Otherwise, a unit making a data call RQD(E=O/l) shall accept
`the GTT message.
`
`Page 17-38
`
`•••••••••••••••••
`
`••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 256
`
`

`
`••••
`
`•••••••••••••••••••
`
`c.
`
`d.
`
`If bit O/R is set to '0' and PFIX/IDENT from the GTT message matches
`its individual address, and the unit is waiting for an incoming
`individual data call, having received an AHYD message and responded
`with ACK(QUAL=O),
`then it shall accept the GTT message.
`
`Otherwise,
`
`the unit may accept the GTT message.
`
`If the unit accepts the GTT message, it shall perform the following
`actions:
`
`It shall be prepared to receive signalling for this transaction
`i)
`number.
`
`the unit shall note
`If bit O/R from the GTT message is set to '1',
`ii)
`that it is the calling party. Otherwise it is a called party.
`
`If the unit is a called party and is waiting for an incoming standard
`data call for this address (see 17.1.2.4,3 and 17.1.2.4.5) then it may take
`the PORT and the calling address (if fully supplied)
`from the AHYD message.
`
`It may also give an indication to the service user.
`
`Page 17-39
`
`Petitioner Cox Communications - Exhibit 1005 Page 257
`
`

`
`17.2 Behaviour on the Data Channel
`
`17.2.0 General
`
`These procedures shall be obeyed by all stations on an allocated data
`channel. More than one data channel may be operated at a base station and
`radio units may be transferred between channels,
`for example to provide an
`even load sharing.
`
`17.2.0.1
`
`Signalling Formats
`
`The signalling format shall conform to Sections 3.1 and 3.2 (but see
`transmission rate below).
`
`The Data Channel codeword synchronisation sequence shall always be
`
`SYNT.
`
`In addition to the 1200 bit/s standard transmission rate a network may
`offer or a radio unit may be equipped for a customised rate.
`
`17.2.0.2 General behaviour of a TSC on a data channel
`
`Every message transmitted by a TSC shall start with SYNT. Except for
`the first message in a transmission, SYNT shall be contained in a DCSC
`codeword.
`
`The TSC shall monitor the return channel and shall be prepared to
`receive messages with timing according to 17.2.0.3 below.
`
`Many messages require or invite individual response transmissions from
`radio units with timing according to 17.2.0.3. The TSC shall not transmit
`any combination of messages which could result in any of these required
`responses coinciding to produce channel
`interference.
`
`It is not necessary to provide synchronisation between the Control
`Channel and the Data Channel.
`
`17.2.0.3 General behaviour of a radio unit on a data channel
`
`indicate to its user
`Whilst on a data channel a radio unit shall not
`or any attached equipment any information relating to the address or data
`codewords of any message except
`those pertinent to that radio unit.
`However,
`the radio unit itself may use the information in non-pertinent
`address codewords to enhance its performance, e.g.
`to save energy or
`optimise random access.
`
`A radio unit may support more than one concurrent standard data call.
`
`for an
`timer, TDX or TON,
`A radio unit shall start a system dependant
`individual or group call respectively,
`for the TRANS when it receives the
`GTT message. Timer TDX shall be restarted whenever
`the radio unit receives
`any message relevant to the TRANS except DAHYX. If timer TDX or TON expires
`the radio unit shall deem the TRANS to be closed.
`
`Page 17-40
`
`•••••
`
`•
`
`•••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 258
`
`

`
`•••••••••••••••••••••
`
`••
`
`If at any time a radio unit deems that it no longer has any open TRANS
`it shall leave the data channel and return to control channel acquisition
`procedures.
`
`A radio unit shall attempt to decode DCSC codewords whilst receLvLng
`on the forward data channel. If a time TDL elapses without being able to
`decode any DCSC codeword the radio unit shall assume that it is out of
`range and shall enter channel acquisition procedures.
`
`A radio unit shall not transmit on the return channel unless it is
`either to make random access within an appropriate random access frame in
`an unwithdrawn slot or is invited to transmit on an individual basis, which
`latter opportunity may be specified by either the radio unit's individual
`address or an individual TRANS (see below).
`
`Every message transmitted by a radio unit shall start with SYNT. Radio
`unit transmission timing shall conform either to the requirements of
`6.2.1.3 but with timing starting from the end of the last codeword of any
`invoking message from the TSC or to the timing rules specified for the
`particular customised transmission rate for that data call
`(see Appendix
`6) •
`
`17.2. 1 Random Access Protocol for the Data Channel
`
`A Random Access protocol is used on the data channel which is based on
`that found on the control channel but differing considerably in detail.
`
`Random access on a data channel is used by radio units to:
`
`a) query an unexpected delay in user data transfer, or
`
`b) send expedited data such as RESET, or
`
`c) close one or all of its TRANS, or
`
`d) attempt to Bet up a concurrent call.
`
`17.2.1.1
`
`TSC Random Access Facilities
`
`17.2.1.1.1 Marking Random Access Frames
`
`The TSC shall designate sections of a return data channel as random access
`frames, each containing a whole number of timeslots. Every frame is marked
`by a codeword which contains an Aloha Bubmessage and an ND parameter
`indicating the frame size.
`
`is a special value indicating "this is not the
`The zero aloha number (ND=O)
`beginning of a frame". Filler messages each consisting of a DCSC codeword
`and a codeword containing an aloha submessage with ND='O' may be used.
`
`Page 17-41
`
`Petitioner Cox Communications - Exhibit 1005 Page 259
`
`

`
`17.2.1.1.2 Addressing the radio unit population
`
`The TSC may invite random access responses from all radio units, or may
`restrict access to a specific individual or group of units using the TRANS
`parameter in the data-aloha codeword.
`
`i.e. all radio units may
`there is no restriction,
`For TRANS='OOOOOOOOOQ',
`attempt access subject to the other random access rules specified in this
`section. For all other values of TRANS, access is restricted to the one or
`more units corresponding to that TRANS. This will typically be used for a
`group TRANS'to restrict a frame for use by one particular group only. Note
`that unlike the control channel
`random access mechanism,
`a response is
`never demanded, even when an individual TRANS is specified.
`
`17.2.1.1.3
`
`Inviting specific types of random access message
`
`The TSC may limit random access to particular types of message by means of
`specific data-a1oha submessages: DAL, DALG, DALN (see 5.8.2.).
`
`17.2.1.1.4 TSC responses
`
`the TSC shall send a response;
`After receiving a random access message,
`valid responses are specified in the sections detailing the call
`procedures.
`The response may be sent
`in the slot following the random
`access message or it may be delayed.
`The TSC shall specify, using the WF
`field in the data-aloha submessage,
`the number of frames that a radio unit
`must wait for before attempting a further random access transmission of the
`message (see 17.2.1.2.6).
`
`17.2.1.1.5 Withdrawing slots from frames
`
`The TSC shall ensure that slot synchronism is maintained within any
`random access frame, e.g. at 1200 bitJs if an AHYD message within the frame
`contains an appended data codeword the T5C shall add an appropriate filler
`data codeword.
`
`The only invoking messages the TSC may transmit within the random
`access frames are:
`
`DAHYX, DAHYZ, DAHY, AHYD, and AHYC
`
`(Random access is inhibited in the first
`messages.)
`
`following return slot after the
`
`51TH (individual or group) such that the user data message extends at
`least to the end of the return channel
`random access frame.
`
`17.2.1.2 Radio Unit Random Access Protocol
`
`These procedures shall be obeyed by all radio units that are required
`to attempt
`random access on the data channel.
`
`The various criteria given below must all be satisfied before a random
`access transmission is made.
`
`Page 17-42
`
`•••••••••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 260
`
`

`
`•••••••••••••••••••••••
`
`17.2.1.2.1 Checking for TRANS restriction
`
`A radio unit is permitted to transmit a non-emergency random access
`message only if the related transaction is invited by the TSC, by means of
`the TRANS parameter in the data-aloha submessage. ThuB access is permitted
`by the radio unit if either
`
`RTRANS = '0000000000',
`
`or
`
`The specified RTRANS in the data-aloha submessage matches any
`of the radio unit1s currently active TRANS' to be transmitted.
`
`An emergency request, RQD(E=l), can be transmitted regardless of any
`TRANS restrictions.
`
`17.2.1.2.2 Checking the Aloha function
`
`A radio unit shall note the function from each data-aloha Bubmessage
`it receives. The requests invited (subject to other restrictions)" by each
`function are as follows:
`
`DAL
`
`invites DRQX, DRQZ, DRUGI, DRQG, RQD(E=l), RQD(E=O), RQX
`
`DALG invites
`
`DRQG, RQD(E=l)
`
`DALN invites DRQX, DRQZ, DRUGI,
`
`RQD(E=l), RQD(E=O), RQX
`
`17.2.1.2.3 Frames defined by Aloha numbers
`
`The number of slots in a frame is equal to the aloha number within the
`frame marking data-aloha submessage, and can take any value in the range
`1-31.
`
`The radio unit shall monitor the forward data channel and shall note which
`sections of the return data channel are designated as random access frames.
`The first access slot in a frame starts at the end of a codeword containing
`a data aloha submessage with a non-zero aloha number, and respective
`coincidence is maintained for subsequent slots.
`
`17.2.1.2.4 Choosing a slot from a new frame
`
`A radio unit that requires to select a slot from a new frame shall wait for
`a message marking a frame available for it to use; it shall then choose a
`slot randomly from the specified frame length, using a uniform
`distribution.
`The unit shall transmit its message in the chosen slot,
`provided that the slot
`is not withdrawn (see 17.2.1.2.5). For access timing see section 6.2.1.3 or
`as specified for the customised rate in use.
`
`A radio unit shall not chose more than one slot from a frame.
`
`Page 17-43
`
`Petitioner Cox Communications - Exhibit 1005 Page 261
`
`

`
`17.2.1.2.5 Check for withdrawn slot
`
`Before transmitting its random access message in a chosen slot, except for
`case (a) below, a radio unit shall check whether the slot is still
`available for random access by attempting to decode the final codeword in
`the slot immediately preceding the chosen slot. If any of the following is
`received then random access is permitted:
`
`al
`
`b)
`
`cl
`
`reception of a SITH address codeword as the last codeword in any slot
`of that frame before the chosen access slot, and
`
`any address codeword containing an Aloha number ON, and RTRANS =
`'0000000000' or any currently active TRANS for this RU, and
`
`the following address codewords:
`
`AHYD or AHYC, either only with AD = '1'
`(unless the AHYD or AHYC is addressed to the unit)
`
`GTT
`
`Note that, unless covered by rule (a), all received codewords which
`are spare, reserved or undecodeable do not permit random access in the next
`slot.
`
`17.2.1.2.6 Noting the response delay
`
`A radio unit shall note the delay parameter WF from each data-aloha
`submessage it receives.
`
`If a random access attempt has not been acknowledged (see 17.2.2 for
`listed acknowledgements) before WF frames have been received,
`then the
`random access attempt may be repeated if the time-out or allowable number
`of tries permits.
`
`17.2.1.2.7 Retry decision and time-outs
`
`After sending a random
`response from the TSC.
`response (as specified
`summarised in 17.2.2).
`
`access message, a radio unit shall wait to receive a
`Various messages shall be accepted as a valid
`in the sections detailing the call procedures and
`
`frames
`If the radio unit does not receive a response before WF subsequent
`have been received,
`it shall assume that the message was unsuccessful.
`
`Then it shall either:
`
`a.
`
`b.
`
`abandon its access attempt
`
`(see below), or
`
`attempt a further random access transmission. However, if the unit
`receives a valid response before sending a repeat message,
`it shall
`accept the response and not retransmit.
`
`The radio unit shall abandon its access attempt if it has sent the
`maximum permitted number of transmissions, NOR, and received no valid
`response.
`
`Page 17-44
`
`•••••••••
`••••••
`••••
`••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 262
`
`

`
`••••••
`••
`•••
`••••••••••••
`
`The unit shall also operate a time-out, TOe, on the maximum time it
`spends trying to achieve access, and abandon the attempt if this time-out'
`expires.
`
`If the unit's access attempt to close all its TRANS fails then it
`shall deem them all to be closed and shall relinquish the data channel and
`attempt to return to the control channel. If the unit's access attempt to
`progress or close one TRANS {see 17.2.1 (a, b, or C)} fails then it shall
`deem the TRANS to be closed. If the attempt to set up a concurrent call
`fails then it shall abandon the attempt.
`
`17.2.2. Messages, Submessages, and Responses on the data
`channel
`
`Data channel procedures are ranked from highest to lowest as:
`a) closure of all or one TRANS,
`b) transfer to another data channel,
`c} transfer of expedited data, and
`d} transfer of user data and call set-up.
`
`A current procedure of one rank may be interrupted or aborted by the
`TSC or radio unit at any opportunity by using an appropriate message to
`enter a procedure of a higher rank.
`
`This subsection lists all the various messages and submessages that
`can be transmitted on a data channel,
`together with the appropriate
`responses in their ranking order. Descriptions of the messages are found in
`section 5, and their uses follow from this. A Submessage is preceded by
`" (S) to •
`
`All random access attempts are subject to the time-outs and re-try
`limits given in 17.2.1.2.7. Additionally some random access attempts are
`prohibited before time-outs have expired; and these accesses are marked
`'f (L)"
`
`Page 17-45
`
`Petitioner Cox Communications - Exhibit 1005 Page 263
`
`

`
`All messages from the TSC are to individual radio units except those
`specifically indicated for groups.
`
`LIST OF MESSAGES, SUBMESSAGES AND RESPONSES
`
`Message
`
`Receiver
`
`Response(s)
`
`CLEAR
`
`RQD
`AHYD
`AHYC
`GTT
`
`RU
`
`TSC
`RU
`RU
`RU
`
`None, but deem all TRANS closed.
`
`See 17.1
`
`SAMIS Extended address message
`No transmitted response. See
`17.1 and 17.2.6
`
`DRUGI
`DRUGI
`
`(TNITEL < 63) TSC
`(RNITEL < 63) TSC
`
`DRUGI(T'L =R'L =
`DRQG
`DRQZ
`DRQX
`
`63)TSC
`TSC
`TSC
`TSC
`
`DAHY
`DAHYZ
`DAHYX (TRANS > 0)
`
`(S)DAL
`(S)DALG
`(S)DALN
`
`RU
`RU
`RU
`
`RU
`RU
`RU
`
`(S)GO
`
`DAHYX, DAHYZ,
`DAHYX, DAHYZ,
`DACKD(REASON='OOl'), SITH
`DAHYX, DAHYZ, None (await developments)
`Ignore, DAHYX (GROUP), SITH group
`DAHYX, DACKZ
`DACKD (REASON= '000)
`
`DRQX, DRQZ(REASON='OOO) , DRUGI
`DRQX, DACKZ
`DACKD(REASON = 'ODD')
`
`DRQX, DRQZ, RQD, DRQG, DRUG I , RLA (L)
`DRQX, DRQG, RQD(E='l')
`DRQX, DRQZ, RQD, DRUGI, RLA (L)
`
`(S)GO
`(S)GO
`(S)GO
`
`after (S)DACK
`(no (S)DACK)
`(+ (S) DACK)
`
`RU
`RU
`TSC
`
`DRQX, DRQZ, DACKD(REASON = 'DOl'), SITH
`DRQX, DRQZ, RLA
`DAHYX, DAHYZ, DACKD(REASON = 'DOl'), SITH
`
`SACK
`SACK (incomplete)
`RLA
`
`SITH
`
`Either
`Either
`Either
`
`Either
`
`DAHYX or DRQX, DAHYZ or DRQZ, SITH
`DAHYX or DRQX, DAHYZ or DRQZ, RLA
`DAHYX or DRQX, DAHYZ or DRQZ,
`(S)DACK(P/N) , and SACK
`DAHYX or DRQX, DAHYZ or DRQZ,
`(S)DACK(P/N) , and SACK
`
`Page 17-46
`
`•
`••
`••••
`••••
`
`••••••••••
`
`••
`
`Petitioner Cox Communications - Exhibit 1005 Page 264
`
`

`
`•••••••••••••••••••••••
`
`17.2.3 Transmission and correction of user's data
`
`In this sub-section there are major differences between the actions
`required of a station sending user data and one receiving it. These
`stations are referred to as data sending and data receiving stations (OSS
`and ORS) respectively_ There are only minor differences between the actions
`to be taken by TSCs and radio units. For this reason, except where noted
`the procedures described here apply to both TSCs and radio units, although
`each shall always conform to the appropriate transmission timing
`requirements.
`
`Due to the bidirectional facilities provided by this standard a data
`sending station may also be a data receiving station at the same time. Such
`a station shall conform to the appropriate procedures according to the
`particular direction of data transmission under immediate consideration at
`any instant.
`
`All the procedures specified here shall be understood to refer only to
`the one TRANS under consideration. Every message not bearing that TRANS in
`its appropriate field(s) shall be deemed irrelevant. Every TRANS being
`processed by any station shall be treated as a separate entity, and
`interleaving of messages relevant to various radio units and TRANS may take
`place. Such interleaving is not mentioned further in this section.
`
`17.2.3.1 Procedures for Data Sending Stations lOSS)
`
`17.2.3.1.0 Tmessages and dataitems
`
`User data consists of one or more Tmessages. A Tmessage consists of
`one or more dataitems. No dataitem shall contain data from more than one
`Tmessage. The last dataitem of one Tmessage may be adjacent to the first
`dataitem of a following Tmessage. See 17.2.3.1.4.1 for use of the MORE bit
`for marking the end of a Tmessage.
`
`17.2.3.1.1 Sending a User Data Message to a Group
`
`A group link may convey only one Tmessage in a single dataitem which
`may not include more user data (including any HADT checksum)
`than that
`which can be accommodated in the user data field of its address codeword
`plus NG data codewords, where NG = 1, 3, 7, 15, 31, 63, 127, or 255 as
`prearranged.
`
`Within the link the group data item may be repeated a prearranged
`number of times. It is permitted to transmit other messages between these
`data items providing the total time between the GTT message and the end of
`the last codeword of the final transmission of the dataitem does not exceed
`TON seconds. For example, a message with DALG Bubmessage bearing the group
`TRANS to mark a random access frame could be sent after transmission of a
`group message. Lack of any random access attempt
`in that frame might then
`be taken by the TSC to mean that no following repeat of the dataitem is
`required.
`
`Page 17-47
`
`Petitioner Cox Communications - Exhibit 1005 Page 265
`
`

`
`•••••••••••••••
`
`••
`
`••••••
`
`17.2.3.1.2 Maximum Length of a dataitem in an Individual Link
`
`link no dataitem may include more data than that
`For an individual
`which can be accommodated in the user data field of its address codeword
`plus 62 data codewords. The RNITEL field in the GO submessage indicates to
`a DSS how much data the data receiving station (DR5) can receive. A DSS
`shall not transmit any quantity of user data unless the DR5 has previously
`indicated that it can accept at least that quantity, but a lesser quantity
`may be sent.
`
`17.2.3.1.3 Responding to a GO Submessage in an individual
`
`link
`
`submessage followed by a
`(DACK)
`Upon receiving a data acknowledgement
`a 055 shall decide whether
`GO submessage (which may be in the same message)
`a higher ranking message (see 17.2.2) or an old or new dataitem should be
`sent, and if the last, what user data will compose the new dataitem (if
`any) which will be sent. Once a dataitem has been sent then all or parts of
`that data shall be repeated as required by the DRS but no other user data
`shall be sent until the ORS indicates by a positive submessage (PACK)
`that
`the dataitem has been completely received. If a DSS receives a data
`acknowledgement and GO submessage and the limit of response time is reached
`before it is able to send a dataitem it shall transmit a
`DACKD (REASON=' 001 , ) message.
`
`17.2.3.1.4 Sending Fragments in an individual
`
`link
`
`Transmission of each data item shall be achieved in one or more
`fragments. The first fragment shall
`include the entire dataitem. Other
`fragments shall only include those pares of the dataitem for which the ORS
`demands repetition. The DRS may demand that the entire dataitem be
`repeated.
`
`the DSS shall decide
`After receiving a SACK message or GO submessage,
`whether to send a fragment or a higher ranking message, see 17.2.2.
`
`17.2.3.1.4.1 Setting the fields in 51TH
`
`The control fields in the fragment address codeword, 51TH, shall be
`set as follows:
`
`ITENUM -
`
`MORE
`
`For each direction of user data transmission the first dataitem
`in a TRANS or after a reset operation shall have ITENUM = '0'.
`Any further dataitems in that TRANS shall have 1TENUM values
`which alternate '1' and '0'.
`
`for all dataitems except for the last
`shall have the value 'I'
`dataitem of each Tmessage, or TRANS if the user does not divide
`the data into Tmessages. MORE shall be set to '0'
`in a group
`dataitem.
`
`FRAGL
`
`shall be set to the number of data codewords,
`follow 51TH.
`
`if any, which
`
`Page 17-48
`
`Petitioner Cox Communications - Exhibit 1005 Page 266
`
`

`
`••••••••
`•••••••••••••••
`
`TNITEL -
`
`LASTBIT -
`
`shall be set to indicate the maximum number of data codewords
`proposed for the next dataitem. Its null value is '111111' and
`is used if no further dataitem is immediately proposed.
`
`shall be Bet to indicate the codeword bit number, see 17.0.2.5,
`of the last bit of user data in the data item unless modified by
`the HADT coding rules, see 17.2.3.1.4.2.
`
`the initial fragment) user data shall start in the
`In a dataitem (i.e.
`first bit of the USER DATA field and continue in bit order through this
`field and through any appended data codewords until all user data in the
`data item have been included. A further information bit following the last
`user data in the dataitem shall be a marker bit,
`'I'. The marker bit shall
`always be provided even if that requires addition of an extra data
`codeword. All remaining bits in the user data field of the last codeword
`shall be 'O's unless subsequently altered by HADT coding, see below.
`
`17.2.3.1.4.2 HADT Coding
`
`The 51TH codeword and the user data in it is not included in HADT
`coding_
`
`If HADT is invoked then the last 15 bits of appended data in each
`dataitem shall consist of a dataitem checksum of all the other user
`information bits in appended data codewords in the dataitem (see Figure
`17.2). The 15 bits of the checksum are calculated as follows:
`
`The information field of each appended data codeword containing user
`data or the end of data marker shall be considered to be the co-efficients
`of a polynomial having terms x61 down 'to x15 . This polynomial shall be
`divided modulo-2 by the generating polynomial;
`
`x 15 + x 14 + x"
`
`+ x 10 + x9 + x6 + x5 + x4 + x + 1.
`
`The co-eff icients of the terms x 14 down to xO found at the completion of the
`division are termed the HADT remainder.
`
`the HADT remainders for the dataitem shall be modulo-2 added to
`All
`form a IS-bit dataitem checksum. If bit positions 34-48 in the final user
`data codeword are all
`'O's then the dataitem checksum shall replace these
`'O's; otherwise a further data codeword shall be appended with bits 1-33 =
`'0' and the dataitem checksum shall occupy the bits 34-48 and 16 shall be
`added to the value of the LASTBIT field in 51TH. The value in the FRAGL
`field of SITH shall
`include the added codeword.
`
`FIG 17.2. 51TH plus 4 Additional Date Codewords (ADC)
`
`- - - Expanded ADC no.4 - -
`
`End of User data Marker
`
`Page 17-49
`
`Petitioner Cox Communications - Exhibit 1005 Page 267
`
`

`
`17.2.3.1.5 Actions after sending a Fragment or RLA Message
`
`Within subsection 17.2.3.1.5 and dependant subsections the specified
`actions only apply if the DSS decides not to close the TRANS or send
`expedited data.
`
`After sending a fragment or a "Repeat Last Acknowledgement"
`message,
`
`(RLA)
`
`immediately restart its timer TDH. If no
`a radio unit shall
`acknowledgement is received before timer TDH expires and a suitable
`random access frame occurs the radio unit may attempt random access
`with a RLA message.
`
`from the radio unit
`if a TSC receives a partial or no acknowledgement
`it shall either repeat the fragment or send an RLA message. The TSC
`shall only repeat that fragment to which it was expecting an
`acknowledgement.
`
`from the TSC but receives
`if a radio unit receives no acknowledgement
`a GO submessage it shall send an RLA message,
`
`if a radio unit receives a partial acknowledgement it shall send an
`RLA message.
`
`17.2.3.1.5.1 After sending an RLA message
`
`if the acknowledgement received is the same as the last complete
`-
`acknowledgement received then the 055 shall, at the next GO submessage,
`repeat the last fragment sent,
`
`if the acknowledgement received is appropriate to the last fragment sent
`-
`then the DSS shall act on that acknowledgement according to the rules
`specified below.
`
`17.2.3.1.5,2 After sending a fragment
`
`if a DSS receives a NACK submessage in acknowledgement it shall repeat
`-
`the whole dataitem when it receives an appropriate GO submessage.
`
`if the DSS receives a SACK message in acknowledgement it shall send a
`-
`fragment consisting of a SITH address codeword and ONLY the data codewords
`corresponding to the assigned EFLAGs set to '1'
`in the SACK message. This
`is irrespective of the setting of EFLAGs
`in any previous SACK message
`relevant
`to that dataitem.
`(If no assigned EFLAGs are set in a SACK message
`the DSS shall repeat the whole fragment or send an RLA message). Note that
`in a data item the user data in the 51TH is repeated in all fragments of
`that dataitem,
`
`it shall proceed to the next
`if the DSS receives a PACK submessage,
`-
`d, :aitem,
`if any. If it receives a relevant GO submessage before it has a
`complete Tmessage ready for transmission then it shall transmit a
`DACKD(REASON = '001') message.
`
`If a DSS sends a fragment with more than 22 included data codewords or
`an RLA message after having last sent such a fragment it shall prepare to
`receive an acknowledgement with appended codeword.
`
`Page 17-50
`
`•••••••••••••••••••••••
`
`Petitioner Cox Communications - Exhibit 1005 Page 268
`
`

`
`•••••••••••••••••••••••
`
`17.2.3.2 Procedures for Data Receiving Stations fDRS)
`
`17.2.3.2.1 Minimum Reception storage when Starting a Call
`
`A DRS shall indicate to the DSS how much data it can receive
`initially. Compliance with a GTT message is one method