the
`- For a radio unit transmission with one or two data codewords,
`radio unit shall be capable of decoding an address codeword in the
`second forward channel slot following the start of the radio unit
`transmission.
`
`the
`- For a radio unit transmission with three or four data codewords,
`radio unit shall be capable of decoding an address codeword in the
`third forward channel slot following the start of the radio unit
`transmission.
`
`(MOVE, GTC; see
`If a radio unit receives a command to change channel
`7.4.2 and 9.2.2.5), it shall be capable of receiving on the new channel
`within 35 ms after the end of the TSC message, unless the unit is a called
`unit
`in an interprefix call,
`in which case it may delay the channel change
`by one slot and shall be capable of receiving on the new channel within
`142 ms after the end of the TSC message (see 9.2.2.5).
`
`6.2.2
`
`Traffic channel discipline for Radio Units
`
`6 . 2 . 2 . 1 Monitoring
`
`the radio unit shall
`Whilst receiving on the forward traffic channel,
`monitor the channel continuously for messages from the TSC and shall take
`appropriate action; See section 3 for the TSC signalling formats and
`sections 9.2.3.2, 9.2.3.3, 9.2.3.4, 9.2.3.7, 9.2.3.8, 11.3.1 and 15.2 for
`procedures.
`If the radio unit is required to transmit a response to a
`message received from the TSC, its response shall conform to the timings
`specified in section 6.2.2.2.
`
`If a radio unit receives a command to change channel (see 9.2.3.4 and
`9.2.3.8), it shall be capable of receiving on the new channel within 35 ms
`after the end of the TSC message.
`
`The radio unit shall not give to its user any information which is not
`pertinent to that radio unit.
`
`6.2. 2.2 Signal timing
`
`The format for standardised messages transmitted on a traffic channel
`by the radio unit is defined in section 3.
`In particular, unless the unit
`i already transmitting, each transmission shall be introduced by at least
`12 bit periods (10 ms) of link establishment time.
`If the radio unit sends
`unsolicited messages (e.g. an Include request, a Pressel On message or
`Disconnect messages),
`the link establishment time shall not exceed 24 bit
`periods (20 ms).
`The preamble duration shall be 16 bits. and messages
`shall commence with the traffic channel codeword synchronisation sequence.
`After the final
`("hang—over") bit of a standardised transmission, unless
`the radio unit is required to continue transmitting for user communication,
`it shall cease transmission so that power is reduced by at least 60 dB
`within 6 bit periods (5 ms).
`
`The transmission of standardised messages on a traffic channel shall
`conform to the timings specified in sections 6.2.2.2.1 and 6.2.2.2.2.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 121
`
`Page 6-5
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 121
`
`

`
`6.2.2.2.l Radio unit response
`
`when the radio unit sends a response (e.g. an acknowledgement to an
`Ahoy message from the TSC), its transmission shall conform to the following
`timings, which are measured in bit periods, numbered from the end of the
`last codeword in the received message.
`
`The radio unit shall not commence r.f. transmission before the start
`
`of bit 21, nor shall it reach 90% of its maximum power later than the start
`of bit 37;
`the 16-bit preamble shall not begin before the start of bit 36
`nor later than the start of bit 49; after sending the "hangaover" bit and
`reducing power,
`the radio unit shall retune to the forward channel
`in time
`to be capable of decoding another message whose codeword synchronisation
`sequence may begin at the start of bit 183 + (64 x number of data codewords
`transmitted by the radio unit].
`
`6.2.2.2.2 Unsolicited transmission that reguires a response
`
`when a radio unit sends an unsolicited standardised message that
`requires a response (e.g. an Include request), it shall conform to the
`following timings, which are measured in bit periods, numbered from the end
`of the last codeword of its transmission.
`
`the radio unit shall
`After transmitting the unsolicited message,
`retune to the forward traffic channel
`in time to be capable of decoding a
`message which may begin (i.e. first bit of codeword synchronisation
`sequence) at the start of bit 52.
`
`If the radio unit has not received a codeword synchronisation sequence
`by the start of bit NT+16, it shall either abandon its unsolicited access
`attempt or make another unsolicited transmission,
`timing the next message
`to begin (i.e. first bit of codeword synchronisation sequence) no earlier
`than the start of bit NT+l44.
`
`the
`If, while waiting to transmit an unsolicited standardised message,
`radio unit receives a codeword synchronisation sequence SYNT, it shall wait
`to determine whether there is a message relevant to it before making its
`transmission.
`
`6.2.3
`
`Data channel discipline for radio units
`
`6.2.3.1 Monitoring
`
`the radio unit shall monitor the
`Whilst receiving on the forward channel,
`channel to take appropriate actions for all relevant received messages.
`
`(see 17.2.6.2),
`If a radio unit receives a command to change data channel
`it shall be capable of receiving on the new channel within 35 ms of the end
`of the TSC message.
`
`6.2.3.2 Signal Timing
`
`At the standard transmission rate, when the radio unit transmits a message
`the timing shall conform to 6.2.1.3 (but using SENT instead of SYNC).
`
`Details of transmission timing at a customised rate must be specified
`elsewhere.
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 €a1g§1gg_i22
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 122
`
`

`
`v- -:—-ii ——--
`
`1 slot -l
`
`system codeword
`1 CCS
`| PR]!
`
`SE5
`
`SYNC
`
`Address codeword
`
`
`
`$25
`
`system codeword
`|
`CBS I
`PRE I SYNC
`
`address
`codeword
`
`
`
`I
`
`I
`|
`|
`
`I
`I
`
`I
`I
`I
`
`I
`
`Pigugg 5-;
`Cogtgo], ghgnggj gfimtgg fig;
`
`'*"
`
`"’
`
`1
`T1
`I
`
`I
`32
`
`64
`
`,
`
`96
`
`-4
`
`I
`
`TSC
`transmission
`
`limits On RU
`TI-I power up
`
`earliest RU
`message
`
`latent RU
`message
`
`1
`9'
`(O
`'°
`“I
`
`I ~
`
`[-
`
`I
`
`|
`
`l
`l
`,
`
`.
`
`-
`I
`'
`
`I
`
`Address Cuduaword
`
`--
`
`SYNC
`._ _
`
`Address codeword
`
`,
`"hang—ovar' bit
`
`SYNC
`_
`-_ __
`' min LET
`
`I
`1 PR2
`l‘
`._#.___
`I
`I
`J
`
`‘
`
`I
`I
`I
`I
`I
`
`.
`
`I
`l FRE
`.
`I
`I
`l
`
`I
`I
`0
`
`0
`
`T
`
`I
`T1 T2
`I
`
`I
`32
`
`I
`
`I
`
`I
`I
`I
`T3 T4 T5
`I
`_ I
`
`T0
`I
`128
`D
`time {bit periods relative to start of slot}
`
`.I.,
`64
`
`..
`96
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 123
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 123
`
`

`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 124
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 124
`
`

`
`7.
`
`ll ACCESS PROTOCOL
`
`This section defines the random access protocol, which is based on
`slotted Aloha with a superimposed framing structure that can be used to:
`
`control clashing of messages from different radio units,
`-
`- minimise access delays.
`-
`ensure stability, and
`- maintain peak throughput under heavy traffic loads.
`
`The slotting structure of the control channel and timing constraints
`for the transmission of messages are defined in sections 3 and 6.
`
`7 . 1
`
`The Principle
`
`The basic principle of the access protocol is described with reference
`to the example below, which illustrates signalling on a control channel.
`
`The TSC transmits a synchronisation message (indicated by ALH in the
`example)
`to establish slot timing and to invite radio units to send random
`access messages.
`The AL!-I message contains a parameter
`(N) which indicates
`the number of following timeslots, constituting a frame,
`that are available
`for access.
`If a frame is already in progress when a call is initiated,
`the radio unit may send its random access message in the next
`immediate
`slot. Otherwise the unit waits for a frame to be started and then chooses a
`
`A unit wishing to send a
`random slot from the frame for its message.
`repeat transmission after an unsuccessful message (corrupted by fading or
`clashing) must wait for a new frame before choosing another slot.
`
`The TSC can monitor activity on the control channel and can optimise
`the system performance by varying the framelength to Prevent excessive
`clashing and to minimise the access delays.
`System designers should choose
`a control algorithm appropriate to the type of system.
`
`1 slot
`<--->
`
`TSC to
`
`radio units
`
`ALH
`
`(4)
`
`ALI-E
`
`(3)
`
`Radio units
`to TSC
`
`\
`
`frame
`
`/
`
`\
`
`frame
`
`I
`
`Example
`
`Two random access frames, each marked by an ALH message.
`(Random access frames can be marked by Aloha, Acknowledgement
`and Go To Channel messages.)
`Contiguous frames are shown in the example;
`Frames need not be contiguous.
`
`frames may overlap.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 125
`
`Page 7—1
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 125
`
`

`
`
`
`7.2
`
`TSC Random Access Facilities
`
`7.2.1 Marking random access frames
`
`The TSC shall designate sections of a return control channel as random
`access frames, each containing a whole number of timeslots. Aloha messages
`(see 5.5.1) sent on the forward control channel contain an Aloha number,
`and can be used to mark random access frames.
`The Acknowledgements and Go
`To Channel message also contain an Aloha number and may substitute for an
`Aloha message.
`For example, ACK(4) acknowledges a message from a radio
`unit and also marks a four-slot frame.
`
`is a special value indicating "this is not
`(N=O)
`The zero Aloha number
`the beginning of a frame". Thus, for example, AcK(O) can be sent within a
`frame to acknowledge a message.
`
`All other Aloha numbers mark the beginning of a frame.
`
`Aloha and Acknowledgement messages contain a four-bit Aloha number and
`the Go To Channel message contains a two—bit Aloha number.
`The Aloha
`number is coded, so that longer frames can be achieved than a pure binary
`representation would permit; the explicit numbers of slots in a frame
`indicated by the four— and two—bit Aloha numbers are given in Table 7-1
`(see 7.3.3).
`If the required framelength is too long to be designated by a
`GTC message then an Aloha message or Acknowledgement must be used.
`
`7.2.2 subdividing the radio unit population
`
`The TSC may divide the radio unit population into subsets, where each
`subset can be permitted random access in turn.
`The division is performed
`by using the address qualifier (M)
`in Aloha messages. This parameter
`instructs a radio unit to compare the M least significant bits of its
`individual address (prefix/ident) with the M least significant bits of the
`address (PFIX/IDENT1)
`from the Aloha message when choosing a slot.
`the unit
`is allowed to transmit non-emergency random access messages only if the M
`bits match (see 7.3.1) when the slot is chosen.
`The subdivision is applied
`to subsequent frames marked by non~Aloha messages, until changed by the
`next Aloha message.
`(However, note that radio units which have recently
`acquired the control channel or have missed Aloha messages may be unaware
`of the subdivision and that the latest Aloha message received by the unit
`is applied by the unit when chosing a slot.)
`
`In this way,
`2“ subsets:
`
`the radio unit population is effectively divided into
`
`-
`
`—
`
`-
`
`so there is no
`If H = 0 then no address bits are compared.
`subdivision.
`(Under normal traffic loading. this will usually be the
`case.)
`
`If M = 1 then only units whose least significant address bit matches
`the Aloha address may send non-emergency random access messages.
`Thus the radio unit population has been divided into two subsets.
`
`This process continues up to M = 19.
`
`?age 7-2
`Petitioner Cisco Systems - Exhibit 1005 - Page 126
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 126
`
`

`
`If M = 20 then all twenty bits of the address must be compared. and
`this indicates that the Aloha message is applicable to only one unit
`or a specified group of units. Note that H = 20 is a special case in
`which the radio unit compares the Aloha address with each of its
`designated addresses, not just its individual address;
`in this way a
`group of units may be invited to send random access messages. Note
`also that an Aloha message with H = 20 and the Aloha address set to an
`individual address demands a response from that unit, rather than just
`inviting a random access message (see 7.4.1).
`If the TSC ends an
`individually addressed Aloha message, it shall set the Aloha number
`(N)
`to 1.
`
`7.2.3
`
`Inviting specific types of random access message
`
`The TSC may limit random access to particular types of message by
`means of specific Aloha messages: ALE-1, ALHS, AL!-ID, ALI-IE, ALI-IR, ALI-IX, ALI-IF
`{see 5.5.1 and 7.3.2); for example, ALHR invites registration or emergency
`requests only.
`The limitation is applied to subsequent
`frames until
`changed by a different Aloha message.
`(However, note that radio units
`which have recently acquired the control channel will assume an Aloha
`function of ALI-ix. While those that have missed Aloha messages may be
`unaware of the current function and will apply the limitations of the last
`received Aloha function. Once a slot is chosen the radio unit applies that
`Aloha function throughout the frame for the purpose of random access.)
`
`7 . 2 . 4
`
`TSC responses
`
`the TSC shall send a
`After receiving a random access message,
`response; 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 WT
`field in the Aloha messages,
`the time (in slots) a radio unit must wait
`before deciding to retransmit and choosing another slot from a new frame
`(see Table 7-2 in section 7.3.7).
`
`7.2.5 Withdrawing slots from frames
`
`the TSC may transmit messages that demand a response
`During a frame,
`from a specified radio unit;
`the response is sent
`in the slotts) following
`the last codeword of the TSC's message.
`
`The TSC‘s message inhibits random access in the first following return
`slot (see 7.3.6}, and so reserves that slot for the response.
`For a multi-
`codeword response,
`the TSC shall take appropriate action to reserve the
`subsequent return slot(s) if they are still within the frame (e.g. by
`sending the AHY message with both idents set to DUMHYI). Note that:
`
`a.
`
`All TSC address codewords that do not contain an Aloha number,
`except M-lY(AD=1), AHYQ(IDENT2=IPFIXI), MARK, MOVE, BCAST and HEAD,
`inhibit random access in the following slot.
`
`An Aloha message with M = 20 inhibits access by radio units that
`are not explicitly addressed.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 127
`
`Page 7-3
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 127
`
`

`
`All data codewords transmitted by the TSC in the second half of a slot
`preceding a designated random access slot contain a Return Slot Access
`flag RSA (bit number 2), which shall be set to indicate whether the
`following slot is reserved for a response; for example, see section
`5.6.2. Note that, for TSC messages containing an odd number of data
`codewords (e.g. AHY(AD=1) and AHYQ(IDENT2=IPFIXI)), a "filler" data
`codeword is appended to the message (see 3.3.3.2);
`if the message
`demands a response from a radio unit,
`the RSA flag in the filler
`codeword shall be set to '0',
`to inhibit random access.
`
`
`
`Page 7-4
`Petitioner Cisco Systems - Exhibit 1005 - Page 128
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 128
`
`

`
`7.3
`
`Radio Unit Random Access Protocol
`
`These procedures shall be obeyed by all radio units that are required
`to attempt random access.
`
`7.3.1 Checking subsets of the radio unit pgpulation
`
`A radio unit shall note the population subdivision contained in each
`Aloha message that it receives. when attempting random access the radio
`unit shall check if the population subdivision is applicable to it. This
`is done using the 5-bit addres qualifier (H) and the address (PFIX/IDENTI)
`from the Aloha message.
`For H = 0 to 19,
`the message is applicable to the
`unit if the M least significant bits of the Aloha address match the M least
`significant bits of its individual address (prefix/ident).
`For H = 20,
`the
`message is applicable to the unit if the Aloha address matches any of its
`designated addresses for this system (including its group addresses).
`
`The unit shall not choose a slot for random access in the frame
`
`designated by the Aloha message, or frames designated by subsequent
`Acknowledgement or Go To Channel messages, unless:
`
`or
`
`the Aloha message is applicable to it, for non-emergency messages,
`the Aloha message is applicable to it or M < 20, for emergency
`requests (ie RQE or RQD (E = 1).
`
`Note that slots are chosen either immediately for the first try option (see
`7.3.4} or on receipt of a frame marker when the limit needs to make a
`random access attempt
`(see 7.3.5).
`
`including when
`when a radio unit becomes active on a control channel,
`returning from a traffic channel, it shall either assume that the
`population is not subdivided (i.e.
`that the last Aloha message was
`applicable to all radio units) or wait for an Aloha message before
`attempting random access.
`
`7.3.2 Checking the Aloha function
`
`from each Aloha message it
`A radio unit shall note the function (FUNC)
`receives.
`The requests invited by each Aloha function are as follows:
`
`ALE-I
`ALI-ZS
`ALHD
`ALI-IE
`ALHR
`RLHX
`ALHF
`
`aqs, RQD{E=0}, RQD(E=1), RQX, RQT, RQE, RQR, RQQ, ago
`Invites
`RQS,
`RQX, RQT, RQE, RQR, RQQ, RQC
`Invites
`RQD(E=0), RQD(E=l), RQX, RQT, RQE, RQR, RQQ, RQC
`Invites
`RQD ( E=l) ,
`RQE
`Invites
`RQD(E=1| ,
`RQE, RQR
`Invites
`RQS, RQD(E=D) , RQD(E=1), RQX, RQT, RQE,
`Invites
`Fall-back mode; messages invited only from radio units
`which know the fall—back method used by this system.
`(The rules defining the Aloha functions appropriate to customised random
`access messages are system-dependent.)
`
`RQQ, RQC
`
`The unit is not required to recognise the meaning of all these
`functions. However, it shall not choose a slot for random access message
`in the frame designated by the Aloha message, or frames designated by
`subsequent Acknowledgement or Go To Channel messages, unless it recognised
`the Aloha function and its random access message is of a type invited by
`the Aloha message.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 129
`
`Page 7-5
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 129
`
`

`
`including when
`when a radio unit becomes active on a control channel,
`returning from a traffic channel, it shall assume an Aloha function of
`ALHX.
`
`7.3.3 Frames defined bv Aloha numbers
`
`A radio unit shall use Table 7-1 to derive the explicit number of
`slots in a frame indicated by the four-bit Aloha number within the Aloha
`and Acknowledgement messages and the two—bit Aloha number within the Go To
`Channel message.
`(The zero Aloha number indicates that the message does
`not mark a frame.)
`
`Four~bit Aloha number:
`
`Aloha Number
`
`Framelength
`
`Aloha Number
`
`Framelength
`
`8
`9
`10
`ll
`12
`13
`14
`15
`
`8
`9
`10
`12
`15
`19
`25
`32
`
`0
`1
`2
`3
`4
`5
`6
`7
`
`Not a frame marker
`1
`2
`3
`4
`5
`6
`7
`
`Two-bit Aloha number:
`
`Aloha Number
`
`Framelength
`
`0
`1
`2
`3
`
`Not a frame marker
`1
`3
`6
`
`Table 7-1
`
`Number of slots in a frame indicated by Aloha numbers
`
`The radio unit shall monitor the forward control channel and shall note
`
`which sections of the return control channel are designated as random
`access frames (using the framing Aloha numbers contained in Aloha,
`Acknowledgement and Go To Channel messages).
`The first access slot in a
`frame starts at the end of the forward control channel codeword containing
`the framing Aloha number and respective coincidence is maintained for
`subsequent slots.
`
`7.3.4 First try ogtion
`
`it is
`when a radio unit is required to transmit a new message.
`permitted to transmit
`in the next
`immediate slot, provided that:
`
`a.
`
`b.
`
`the slot is within a frame and the most recently received
`Aloha message does not
`inhibit access.
`(see 7.3.1, 7.3.2, 7.3.3),
`the slot is not withdrawn (see 7.3.6).
`
`and
`
`
`
`Page 7-6
`Petitioner Cisco Systems - Exhibit 1005 - Page 130
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 130
`
`

`
`if it does not wish to use this option or if the slot is not
`However,
`within a suitable frame or if the slot is withdrawn,
`then the unit shall
`choose a slot from a new frame (see 7.3.5).
`
`7.3.5 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 (see 7.3.1 and
`7.3.2); it shall then choose a slot randomly from the specified
`framelength, using a uniform distribution.
`The most recently received
`Aloha message parameters are enforced at the moment of slot choice.
`The
`unit shall transmit its message in the chosen slot, provided that the slot
`is not withdrawn (see 7.3.6); for access timing, see 6.2.1.3.
`
`A radio unit shall not choose more than one slot from a frame.
`
`Therefore, if it has to repeat the selection of a slot (either because a
`chosen slot was withdrawn or to make a repeat transmission), it shall count
`to the last slot of the previous frame before using another Aloha number.
`For example,
`if the last selection was from a frame with 8 slots,
`designated by an ALH message,
`the unit shall not use frame marker messages
`received in the '7 slots after the ALI-I message to choose its next slot.
`(Counting slots is required to allow for multi-ite systems with time
`division of a single control channel,
`in which radio units may receive
`messages from several sites and frames designated by different sites may
`overlap in time.)
`
`7. 3.6 Check for withdrawn slot
`
`Before transmitting its random access message in a chosen slot,
`radio unit shall check whether the slot is still available for random
`
`as
`
`access by attempting to decode the second codeword on the forward channel
`in the slot immediately preceding the chosen slot.
`If any of the following
`is received then random access is permitted:
`
`a.
`
`Any address codeword containing an Aloha number, except an Aloha
`message with M = 20 and the Aloha address (PFIX/IDENT1) not applicable
`to the unit (see 7.3.1).
`
`b.
`
`The following address codewords:
`
`—
`
`AH‘! with AD = 1
`
`--
`
`(unless the AHY is addressed to the unit)
`AHYQ with IDENT2 = IPFIXI
`(unless the AHYQ is addressed to the unit)
`— MARK
`
`-
`-
`
`a MOVE message not applicable to the unit (see 7.4.2)
`BCAST
`
`HEAD (unless the HEAD is addressed to the unit).
`—
`A data codeword with the Return Slot Access flag RSA (bit number 2)
`set to '1' ,
`(unless the codeword is part of a message addressed to
`the unit).
`
`If permitted by the type of system, a codeword that is not decodeable
`(or no signal is received).
`
`c.
`
`d.
`
`Otherwise the unit shall refrain from transmitting and shall choose again
`from a new frame.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 131
`
`Page 7-7
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 131
`
`

`
`(Future enhancements of the standard protocol, and customised
`messages, may result in additional messages that permit access for those
`radio units which can recognise these additional messages.)
`
`7.3.7 Noting the response delay
`
`A radio unit shall note the delay parameter WT from each Aloha message
`it receives and shall use Table 7-2 to derive from it the number of slots,
`WAIT, by which the TSC's response to a random access message may be
`delayed.
`(WAIT = 0 means that the response should be received in the slot
`following the random access message.) At the start of a session, until it
`receives an Aloha message,
`the unit shall assume a value of WAIT = NW (see
`Appendix 1).
`
`_$
`O
`1
`2
`3
`
`WAIT
`O
`1
`2
`3
`
`Ex
`4
`5
`6
`7
`
`WAIT
`4
`S
`10
`15
`
`Table 7-2
`
`Response delays indicated by the delay parameter WT
`
`7.3.8 Retry decision and time-outs
`
`After sending a random access message, a radio unit shall wait to
`receive a response from the TSC. Various messages shall be accepted as a
`valid response (as specified in the sections detailing the call
`procedures).
`
`If the radio unit does not receive a response within the WAIT+l slots
`after its message, it shall assume that the message was unsuccessful. Then
`it shall either:
`
`a.
`
`b.
`
`abandon its access attempt
`
`(see below), or
`
`from a new frame (using a frame marker message
`choose another slot,
`received in or after the WAIT+l th slot after the unsuccessful
`
`if the unit receives a valid response before
`however,
`message);
`sending a repeat message,
`it shall accept the response and not
`retransmit.
`
`the
`The radio unit shall abandon its access attempt if it has sent
`maximum permitted number of transmissions and received no valid response.
`This number depends on the function of the message:
`— For requests RQS, RQD(E=O), RQX, RQT, RQR, RQQ and RQC, it is NR.
`- For emergency requests RQE and RQD(E=1), it is NE.
`The unit shall also operate a time-out TC 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 fails,
`
`then:
`
`i)
`
`the unit
`If the message was a cancellation/abortion request RQX,
`shall return to waiting for signalling for the original transaction
`(for example, see sections 9.2.1.7 and 9.2.1.6).
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 fa 2ig;_i332
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 132
`
`

`
`
`
`ii)
`
`For access attempts for other messages:
`
`—
`
`-
`
`if the unit has not sent a message, 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 (until the relevant time—out Tw or ‘N has expired -
`for example,
`see sections 9.2.1.1 and 9.2.1.6).
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 133
`
`Page 7-9
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 133
`
`

`
`7.4
`
`Related Procedures for All Radio Units on a Control Channel
`
`7.4.1 Individually addressed Aloha message
`
`If a radio unit on a control channel receives an Aloha message with M
`20 and Aloha address (PFIX/IDENTI) matching its individual address for
`this system,
`then it shall send a message in the next slot:
`
`a.
`
`b.
`
`c.
`
`If the unit recognises the Aloha function and is currently
`attempting random access with a message of a type invited by the
`Aloha message, it shall transmit its message and then continue to obey
`the procedures in section 7.3 (regarding the transmission as if it
`were a random access).
`
`if the Aloha message is ALHR and the unit has the
`Otherwise,
`ability to register, it shall send a registration request RQR and then
`wait until it receives a response or for WAIT+1 slots. While waiting
`for a response,
`the unit shall not seek to transmit messages by random
`access.
`See also section 8.3.2.
`
`the unit shall send an acknowledgement ACKX(QUAL=O) with
`Otherwise,
`PFIX/IDENT2 set to its individual address and IDENTI set to TSCI.
`(It will not be sent a response to this message.)
`
`7.4.2 MOVE message
`
`If a radio unit on a control channel receives a MOVE message that is
`applicable to it (see below),
`then it shall move to the specified forward
`control Channel and shall be able to receive within 35 ms after the end of
`
`the MOVE address codeword; after becoming active on the specified control
`channel,
`the unit shall retain the same state as on the old control channel
`except that,
`if currently attempting random access, it shall choose a slot
`from a new frame, using a frame marker message received on the new control
`channel
`(see 7.3.5).
`
`The unit uses the address qualifier (M) and the address (PFIX/IDENT1)
`from the MOVE message to decide whether the message is applicable to it.
`For M = O to 19,
`the message is applicable to the unit if the H least
`significant bits of the MOVE address match the M least significant bits of
`its individual address.
`For M = 20,
`the message is applicable to the unit
`if the MOVE address matches any of its designated addresses for this system
`(including its group addresses).
`
`Note:
`
`If field CONT in an applicable MOVE message is equal to
`'OOO0OOO0OO',
`then the channel movement
`is system—dependent.
`
`
`
`Page 7-10
`Petitioner Cisco Systems - Exhibit 1005 - Page 134
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 134
`
`

`
`
`
`RBGI STRATION PROCEDURES
`
`8 .
`
`Registration enables a radio unit to inform a system that it is within
`a session on that system. This section defines signalling procedures for
`radio units and Tscs that are required to Employ registration.
`
`Additional specifications will be needed for a specific system
`implementation, for example,
`to define:
`
`—
`—
`
`the criteria for when a radio unit should initiate registration
`the radio unit action after a registration denial or failure.
`
`These specifications are likely to be system-dependent and therefore are
`not
`included in this standard.
`
`8 . 1
`
`Rgistration Facilities
`
`The registration procedures in this standard provide the following
`facilities for the TSC:
`
`a.
`
`The TSC shall indicate, by the value of field FUNC in Aloha messages,
`whether random access registration request messages are invited from
`radio units.
`(See also sections 7.2.3 and 7.3.2.)
`
`i)
`ii)
`iii)
`
`ALH, ALHS, ALHD and ALI-IR invite registration requests.
`AL!-IE and ALI-IX do not invite registration requests.
`The function of ALHF will be determined by the customised
`fall-back mode.
`
`b.
`
`The TSC may vary the value of the address qualifier (M)
`messages to invite registration requests from:
`
`in Aloha
`
`the whole radio unit population (M = 0),
`-
`a section of the radio unit population (0 < M < 20), or
`—
`- members of a selected group only
`(M = 20 and PFIX/IDENTI set to a group address).
`
`See also sections 7.2.2 and 7.3.1.
`
`The TSC may demand registration from a specific radio unit by
`transmitting the ALI-IR message, with PFIX/IDENT1 set to the
`individual address of the wanted radio unit and M set to 20.
`
`The TSC may reject individual registration requests.
`
`to
`The TSC may transmit the BCAST message with SYSDE.'F='ODO1l',
`broadcast registration parameters to radio units.
`See 5.S.4.5d.
`
`C.
`
`d.
`
`e.
`
`The procedures for registration by random access and registration on demand
`are specified in sections 8.2 and 8.3 respectively.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 135
`
`Page 8-1
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 135
`
`

`
`8.2
`
`Procedures for Registration by Random Access
`
`8.2.1
`
`TSC Procedures
`
`The TSC shall use the random access protocol to control the generation
`of registration requests by the radio unit population, as described in
`section 8.1 above.
`If the TSC indicates,
`in the manner described therein,
`that registration requests are invited then it shall be prepared to receive
`RQR messages from radio units.
`
`8.2.1.1 Responses to a random access RQR message
`
`A radio unit requests to register by generating an RQR message,
`complying with the random access protocol.
`On receiving an RQR message,
`the TSC shall send a response - ACKI(QUAL=1), ACKX or ACK(QUAL=O) - with
`PFIX/IDENT2 as the unit's individual address and IDENT1 set to REGI. For
`acceptable delay, see 7.2.4.
`See also 8.2.1.2.
`
`8.2.1.2 Acknowledgements sent to indicate Qrogress of registration
`
`The TSC may send the following acknowledgement messages (with
`PFIX/IDENT2 as the unit's individual address and IDENT1 set to REGI)
`indicate to a radio unit the progress of its registration:
`
`to
`
`ACKI
`
`(QUAL=l)
`
`ACKX (QUAL=O)
`ACKX (QUAL=1)
`ACK
`(QUAL=O)
`
`—
`
`the decision to accept
`Intermediate acknowledgement;
`or reject the registration has been postponed;
`more signalling to follow.
`Invalid request; registration denied.
`—
`system overload; registration failed.
`—
`- Registration accepted.
`
`8.2.1.3 TSC time—out
`
`The TSC may instruct a radio unit to restart its waiting timer TJ, by
`sending the AHY message with bit POINT set to '1', PFIX/IDENT2 set to the
`unit's individual address and IDENT1 set to REGI; see 9.1.1.7 and 9.2.2.3.
`If a time TJ (minus the tolerance on the radio unit's timer) Qlapses since
`the last message it received for the registration,
`the TSC shall not send
`any further signalling for the registration.
`See also 8.2.2.4.
`
`
`
`Page 8-2
`Petitioner Cisco Systems - Exhibit 1005 - Page 136
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 136
`
`

`
`
`
`8.2.2
`
`Radio Unit Procedures for Registration by Random Access
`
`8. 2 . 2 . 1 Cr iteria for rgistration
`
`At the start of a session, a radio unit shall decide (by examination
`of the system identity code in codewords received on the forward control
`channel) whether it should seek to register with the system.
`The process
`by which the unit decides whether to seek to register is system-dependent
`and is not
`included in this standard.
`
`A radio unit seeking to register with a system may attempt to make
`calls prior to registration (but shall be prepared to register on demand
`before being accepted for traffic; see 7.4.1 and 3.3.2.1).
`
`8.2 .2 .2 Registration regs-st and valid respgnses
`
`A radio unit requests to register by sending the RQR message on a
`control channel, complying with the random access protocol (see 7.3). The
`fields in the RQR message shall be set appropriately (see 5.5.11.6);
`however, note particularly that PFIX/IDENTI is set to the radio unit's
`individual address agreed for the system, and field INFO may contain
`additional
`(customised) information.
`
`The unit shall attempt access until it receives a valid response (see
`below) or until the access attempt fails (i.e.
`the unit has sent the
`maximum number of transmissions NR and received no response, or its acc