ii)
`
`If the unit does require the diversion address then:
`-
`if it has received no previous response to its Include R95,
`and has not sent the maximum number of transmissions of
`
`the RQS (see 11.2.1), it shall ignore the ACKT message;
`- otherwise it shall wait for a repeat ACKT, re-enabling
`user transmission if a time T3 elapses (in which case.
`it may indicate the failure to the user).
`
`the unit shall re-enable user transmission
`If ACK(QUAL=0) is received.
`and may indicate to the user that the called party is being directed to the
`traffic channel.
`
`the unit shall
`After receiving ACKX, ACKV or ACK for its Include call,
`not request on the traffic channel another transaction of any type to the
`same called ident (or gateway) for at least a time TB. After receiving
`ACKT for its Include call, the unit shall not request on the traffic
`channel another transaction of any type for at least a time T8.
`
`11.2.5 Time-out after waitin for Include call
`
`A radio unit waiting for further signalling for an Include call shall
`re-enable user transmission if a time TI has elapsed since the last message
`it sent for the transaction, viz.
`
`requesting the Include call (see 11.2.1)
`RQS,
`SAMIS, providing extended address information for the call (see 11.3.1)
`or
`or ACK(QUAL=0), sent.
`in response to an Al-IY message with bit POINT = 1
`and IDENT1 as the called ident or gateway (see 9.2.3.2).
`
`It may also indicate to the user that the outcome of the transaction is
`unknown.
`
`11 . 2 . 6 Cancelling Include
`
`A radio unit may cancel an Include request (after sending an RQS and
`while still waiting to receive ACKX, ACKV, ACKT or Acx) by transmitting a
`cancellation request RQX (see 5.5.3.1.3) on the traffic channel.
`The unit
`shall then wait for a response from the TSC;
`for timing, see 6.2.2.2. The
`unit shall repeat its cancellation request, each time waiting for a
`response from the TSC, until one of the following occurs:
`
`a.
`
`b.
`
`It receives ACK(QUAL=1), with the same prefix and idents as the RQX,
`confirming cancellation of the Include call.
`
`for the
`It receives ACKX, ACKV, ACKT(QUAL=D] or ACl((QUAL=O)
`Include call it is attempting to cancel.
`See also 11.2.4.
`
`c.
`
`It has sent the maximum number of transmissions NI.
`
`In this case,
`
`it shall return to waiting for signalling for the Include call
`(see 11.2.4 and 11.2.5).
`
`In cases a. and b.,
`
`the unit shall re-enable user transmission.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 181
`
`Page 11-?
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 181
`
`

`
`
`
`11.2.? Other procedures
`
`a.
`
`b.
`
`c.
`
`d.
`
`e.
`
`A radio unit shall not attempt an Include call if user transmission
`has been inhibited (by the GTC message or by a MAINT(OPER='1ll')
`message; see 9.2.2.5, 9.2.3.3 and 9.2.3.4).
`
`If a radio unit requesting or attempting to cancel an Include call,
`or waiting for further signalling, receives a MAINT(0PER='lll')
`message inhibiting user transmission (see 9.2.3.3),
`then it shall
`continue with the Include call but shall not re—enable user
`transmission at the end of the transaction.
`
`If a radio unit requesting or attempting to cancel an Include call,
`or waiting for further signalling, receives a GTC message allocating
`a replacement traffic channel, it shall perform actions i) and ii) as
`specified in section 9.2.3.4 and shall then continue with the Include
`call. At the end of the transaction,
`the unit shall re-enable user
`transmission only if permitted by action iii) of 9.2.3.4.
`
`If a radio unit's user goes on-hook (or equivalent) while it is
`requesting or attempting to cancel an Include call, or waiting
`for further signalling,
`then the unit shall abandon the Include
`call and shall obey the procedures specified in section 9.2.3.5.
`
`(If the user goes on-hook (or equivalent) after an Include call,
`then the unit shall obey the procedures specified in section 9.2.3.5.
`However, see also section 11.1.9.)
`
`If a radio unit requesting or attempting to cancel an Include call,
`or waiting for further signalling, receives a MAINT(OPER='1l0')
`or CLEAR message terminating the call in progress,
`than it shall
`abandon the Include call and shall obey the procedures specified
`in sections 9.2.3.7 and 9.2.3.8 respectively.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 182
`
`Page ll-B
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 182
`
`

`
`11.3
`
`Procedures for All Radio Units on an Allocated Traffic Channel
`
`11.3.1
`
`Instruction to send extended address information
`
`This procedure shall be obeyed by all radio units that are equipped to
`request extended addressing Include calls.
`
`If a radio unit on a traffic channel receives an AHYC message with
`PFIX/IDENT2 matching its individual address then it shall either send
`address information or transmit ACI<X(QUAL=0), as indicated below.
`For
`timing, see section 6.2.2.2.
`
`If
`
`the unit has sent an extended addressing Include RQS
`IDENT1 matches IDENT1 from the Include RQS
`
`and
`
`(see S.5.3.2.8)
`is appropriate to IDEN'I'l
`and DESC
`corresponds to the Include RQS
`and
`SLOTS
`if IDEN’l‘1=PSTNGI and FLAG1=l then SLO'I'S=‘lO' else
`(i.e.
`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 AHYC.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 183
`
`Page 11-9
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 183
`
`

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

`
`12. L DIVERSION PROCEDURBS
`
`This section defines the procedures for requesting and cancelling call
`diversion. Requests may apply to speech calls, data calls or both.
`
`Two types of call diversion are provided:
`
`i) Se1f—initiated diversion.
`A radio unit may request that future call addressed to it be
`redirected to a specified alternative destination.
`
`ii) Third-party diversion.
`A radio unit may request that future calls addressed to another
`subscriber unit
`(or group) be redirected to a pecified alternative
`destination.
`For example, a despatcher unit may request diversion
`on behalf of a radio unit in its fleet.
`
`In general, radio unit A (the requesting unit) may divert call for address
`3 (the blocked address) to alternative destination C (the diversion
`address); for self—initiated diversion, B = A.
`The procedures permit
`blocked address B to be a radio unit,
`line unit or group address.
`Destination C may be a. radio unit,
`line unit or group address. a PABX
`extension or a PSTN number (short-form or general).
`
`Three types of call diversion cancellation are provided:
`
`i) Self-initiated cancellation.
`A radio unit may request that its calls are no longer diverted.
`
`ii) Third-party cancellation.
`A radio unit may request that another subscriber unit's (or group's)
`call are no longer diverted.
`
`iii) General cancellation by recipient.
`A radio unit may request that any existing diversions to it be
`cancelled.
`(This is a general cancellation by the recipient of
`diversions; specific cancellation of diversions by the recipient
`is covered by third—party cancellation.)
`
`It is reconunended that requests for third-party diversion or third-
`party cancellation are accepted only from authorised units.
`
`Call diversion is requested or cancelled using the Request Call
`Diversion Message RQT (see 5.S.3.1.4).
`In this message:
`
`-
`
`-
`
`PFIX/IDENT2 is the address of the requesting radio unit.
`
`IDENT1 is the diversion ident C
`For diversion requests,
`(or IPFIXI, PABXI or PSTNGI for an interprefix address,
`any PABX extension or a general PSTN number respectively).
`
`For "self" or "third—party" cancellation of call diversion,
`IDENT1 specifies the unit or group whose calls should be returned
`(or IPFIXI for an interprefix address).
`
`For general cancellation by a recipient,
`
`IDENT1 is set to DIVERTI.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 185
`
`Page 12-1
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 185
`
`

`
`— Bit DIV indicates call diversion or cancellation.
`
`~ For call diversion, FLAG2 indicates "self" or "third-party" diversion.
`
`— Field SD specifies the types of call (i.e. speech, data or both)
`to which the diversion or cancellation refers.
`
`For diversion purposes, "speech" calls are defined as calls requested
`using RQS(D'I‘=O), RQE(D=0), RQQ(STA'I'US='00O0O') or RQQ(STATUS='11lll‘).
`"Data" calls are defined as calls requested using RQS(DT=l), RQE(D=1),
`RQQ{'0OO0l'
`to '1ll10'), RQC or RQD.
`
`two
`For self-initiated diversion requests or any cancellation,
`addresses {plus the other parameters) specify the requirement. However,
`for third—party diversion requests, address B (the blocked address) must be
`supplied.
`
`The TSC uses the AHYC message to demand:
`
`a.
`b.
`
`extended address information for IDENTl
`blocked address B
`
`the TSC obtains the full
`If both a. and b. are needed,
`as appropriate.
`information in two steps, each step using the AHYC message.
`The AHYCs are
`distinguished by the setting of IDENT1 (to IPFIXI, PABXI or PSTNGI for a.,
`or to DIVERTI for b.), and so the order in which they are sent is not
`prescribed.
`
`In the procedures, a request for call diversion or cancellation is
`defined as an extended addressing request if IDENT1 is set to IPFIXI, PABXI
`or PSTNGI.
`A request is defined as "complex" if it requires extended
`addressing or if three addresses must be provided; otherwise it is
`"simple".
`
`Note that extended addressing procedures are used for requesting
`diversion to any PABX extension (with either a "long" or "short" extension
`number).
`The radio unit sets IDENT1 in the RQT message to PABXI, and then
`sends the PABX address information in response to an AHYC message with
`IDENT1 set to PAEXI and DESC set to ‘O10’.
`The unit sets bit SP in the
`
`SAMIS message to indicate whether it is sending BCD digits or a 13-bit
`extension number
`(plus 2—bit exchange number).
`See 5.5.3.2.8 and
`5.6.1.2.2.
`
`If the TSC accepts a diversion request and then a call to the blocked
`address is requested by a radio unit,
`the TSC indicates the diversion
`address to the calling radio unit using the ACKT(QUAL=D) acknowledgement.
`The unit then either retries on the diversion address or returns to the
`
`idle state.
`
`For example, see sections 9.1.1.4 and 9.2.1.4.
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 186
`
`Page 12-2
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 186
`
`

`
`12.1
`
`TSC Procedures for Call Diversion pests
`
`12.1.1 Res nses to a a
`
`le diversion r
`
`est
`
`A radio unit requests simple call diversion by generating an RQT
`message (with FLAG2 = O and IDENT1 set to a valid called party ident or to
`DIVERTIJ , complying with the random access protocol.
`on receiving a simple
`RQT message,
`the TSC shall send one of the following responses, with the
`same prefix and idents as the RQT:
`
`ACKI (QUAL=1) , ACKX, ACKV(QUAL=O) or hCK(QUAL=0) .
`
`For acceptable delay, see 7.2.4.
`
`See also 12.1.5.
`
`12.1.2 Responses to a complex diversion reggest
`
`A radio unit requests complex call diversion by generating an RQT
`message (with FLAG2 = 1 and/or IDEN'I'l = IPFIXI, PABXI or PSTNGI), complying
`with the random access protocol.
`on receiving a complex RQT message,
`the
`TSC shall send one of the following responses:
`
`a.
`
`b.
`
`c.
`
`an acknowledgement ACKI(QUAL=l), ACKX or P.CKV(QUAL=0), with the same
`prefix and idents as the RQT.
`
`For an extended addressing RQT:
`An AI-IYC message instructing the unit to send the full address
`information for IDENT1.
`
`For a request for 3—address diversion (i.e. RQT with FLAG2=l):
`An AHYC message instructing the unit to send the blocked address.
`
`For acceptable delay, see 7.2.4.
`
`see also 12.1.3 to 12.1.5.
`
`12.1.3
`
`Instruction to send extended address information
`
`the TSC may demand
`After receiving an extended addressing RQT message,
`the full address information for IDENT1 by sending the AHYC message, with:
`
`—
`
`the same prefix and idents as the RQT
`(i.e.
`IDEN'l'l set to IPFIXI, PABKI or PSTNGI as appropriate, and
`PFIX/IDENT2 set to the requesting unit's address)
`«— DESC set to indicate the appropriate gateway (see 5.5.3.2.B)
`—
`SLOTS set to correspond to the RQT
`(i.e. if IDENT1=PSTNGI and FLAG1=l then SLOTS='10' else
`SLOTS='0l'}.
`
`The AHYC message instructs the requesting radio unit to send the full
`address information for IDENT1 in the following SLOTS sJ.ot(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 .
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 187
`
`Page 12-3
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 187
`
`

`
`12.1.4
`
`Instruction to send the blocked address
`
`After receiving a request for 3-address diversion (i.e. FLAG2=1).
`TSC may demand the blocked address by sending the AHYC message, with:
`
`the
`
`-
`
`IDENT1 set to DIVERTI
`
`PFIX/IDENT2 set to the requesting unit's address
`—
`— DESC set to ‘O00’
`-
`SLOTS set to '01’.
`
`The AHYC message instructs the requesting radio unit to send the blocked
`address in the following slot
`(gee 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.
`
`12.1.5 Acknowledgements sent to indicate progress of RQT transaction
`
`The TSC may send the following acknowledgement messages, with the same
`prefix and idents as the RQT,
`to indicate to a radio unit the progress of
`its diversion transaction.
`(For a complex diversion request, ACK{QUAL=O)
`is not appropriate until the full diversion information has been obtained.)
`
`ACKI
`
`(QUAL=l)
`
`ACKX (QUAL=O)
`
`~
`
`—
`
`Intermediate acknowledgement; more signalling to
`follow.
`
`Invalid call e.g. unauthorised diversion request, or
`TSC does not provide call diversion.
`
`ACKX (QUAL=l)
`ACKV (QUAL=O)
`ACK
`(QUAL=O)
`
`System overload; request rejected.
`-
`— Transaction abandoned.
`- Call diversion or cancellation has been accepted.
`
`For maximum acceptable delay of repeats of acknowledgements ACKX, ACKV and
`ACE, see time-out TB in 12.2.4.
`
`12.1.6 Aborting the transaction
`
`A radio unit may abort its diversion transaction by generating an RQX
`message (see 5.S.3.l.3), complying with the random access protocol. On
`receiving an RQX message aborting a diversion transaction,
`the TSC shall
`send a response: ACK(QUAL=l) with the same prefix and idents as the RQX.
`
`12.1.7
`
`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'
`(and the same prefix and
`idents as the RQT); see 9.1.1.7 and 9.2.2.3.
`If a time TJ, minus the
`tolerance on the radio unit's timer, elapses since the last message it
`received for a diversion transaction,
`the TSC shall not send any further
`signalling for the transaction.
`See also 12.2.5.
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 188
`
`Page 12-4
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 188
`
`

`
`12.2
`
`Procedures for Radio Units gggesting call Diversion
`
`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-
`of-transaction) acknowledgement to a diversion request,
`the unit shall not
`request another non-emergency call of any type (unless the user first
`aborts the original transaction).
`
`12 . 2 . 1 Diversion reg-:__.1est
`
`A radio unit requests or cancels call diversion by transmitting an RQT
`message on a control channel, complying with the random access protocol
`(see 7.3).
`The fields in the RQT message shall be set appropriately (see
`5.5.3.1.-1); however, note particularly that:
`
`a.
`
`b.
`
`c.
`
`Bit DIV specifies whether the unit is requesting call diversion
`or cancellation of call diversion.
`
`Bit FLAG2 specifies whether or not three addresses must be provided.
`
`An extended addressing diversion request is indicated by setting
`IDENTI
`in the RQT message to the appropriate gateway ident viz.
`IPFIXI, PABXI or PSTNGI.
`(Note that extended addressing
`procedures are used for requesting diversion to a PABX extension
`with either a "short" or "long" extension number.)
`
`The unit shall attempt access until it receives a valid response (see
`12.2.2/3), or until its user aborts the transaction (see 12.2.6), 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.B)).
`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 12.2.4 and 12.2.5.
`
`12.2.2 Responses to simple diversion request
`
`the radio unit shall accept the
`For a simple diversion request,
`following messages (with the same prefix and idents as the RQT) as a valid
`respone to its RQT and send no more requests:
`
`nc1<:(QUn1.=1), ACKX, ACKV(QUAL=0) or P.CK(QUAL=0).
`
`For other actions on receiving these messages, see section 12.2.4.
`
`12.2.3 Resgnses to complex diversion reguest
`
`the radio unit shall accept the
`For a complex diversion request,
`following messages as a valid response to its RQT and send no more
`requests:
`
`a.
`
`b.
`
`ACKI(QUAL=l), ncxx or 1|.CKV(QUM..=O}, with the same prefix and idents as
`the RQT.
`
`For an extended addressing RQT:
`M-WC, with the same prefix and idents as the RQT.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 189
`
`Page 12-5
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 189
`
`

`
`c.
`
`For a request for 3-address diversion (i.e. RQT with FLAG2=1):
`AHYC, with PFIX/IDENT2 as its individual address and IDENTI as
`DIVERTI.
`
`For other actions on receiving these messages, see 12.2.4 and 9.2.2.1.
`
`12.2.4 Acknowledgement received
`
`If a radio unit attempting access or waiting for further signalling
`for a diversion transaction receives an appropriate acknowledgement (with
`the same prefix and idents as the RQT)
`then it shall take action as
`indicated below.
`For a complex diversion request, ACK(QUAL=O)
`is not
`appropriate until the full diversion information has been sent.
`
`ACKI
`
`(QUAL=1)
`
`-
`
`Intermediate acknowledgement; more signalling to
`follow.
`
`ACKX (QUAL=0)
`ACKX (QUAL=1)
`ACKV (QUAL=0)
`ACK
`(QUAL=O)
`
`Invalid call; request rejected.
`—
`- System overload; request rejected.
`— Transaction abandoned.
`— Call diversion or cancellation has been accepted.
`
`is received,
`If ACKI(QUAL=l)
`signalling for the transaction.
`
`the unit shall wait for further
`
`the unit shall return to the idle
`is received,
`If ACKX or ACKV(QUAL=0)
`state and may indicate to the user that the transaction has failed.
`
`the unit shall return to the idle state
`is received,
`If ACK(QUAL=O)
`and may indicate to the user that the request for call diversion or
`cancellation has been accepted.
`
`the unit
`After receiving ACKX, ACKV or ACK for its diversion request,
`shall not request another non-emergency call of any type to the same called
`ident
`(or gateway)
`for at
`least a time TB.
`
`12.2.5 Time-out after waiting
`
`A radio unit waiting for further signalling for a diversion
`transaction shall return to the idle state if a time TJ has elapsed since
`the last message it sent for the transaction, viz.
`
`requesting the transaction (see 12.2.1)
`RQT,
`SAMIS, providing address information for the call (see 9.2.2.1)
`or
`or ACK{QUAL=O), sent in response to an AHY message with bit POINT = 1
`and the same prefix and idents as the RQT (see 9.2.2.3).
`
`It may also indicate to the user that the outcome of the transaction is
`unknown.
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 190
`
`Page 12-6
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 190
`
`

`
`13 .
`
`STATUS HBSSBGE
`
`UR33
`
`This section defines the procedures for status messages. Status
`messages may be sent to the TSC or to a radio or line unit.
`
`A radio unit sends tatus information using message RQQ - see
`5.5.3.l.'l. The status field in an RQQ message consists of 5 bits, allowing
`32 different status values.
`Two of these values have been predefined.
`
`a)
`
`For status sent to the TSC:
`
`'OOO00'
`
`indicates that the unit is ready to receive a call
`(i.e. it indicates “off-hook" or equivalent).
`
`'00OO1' to '1l110' are system—defined status values.
`
`'111l1'
`
`indicates that the unit is no longer ready to
`receive a call (i.e. it indicates "on-hook" or
`equivalent) .
`
`RQQ( 'OO000') and RQQ('11111') are used for the "Called Party Answer“
`mechanism - see section 9.2.2.2.
`If a radio unit receives
`
`P.HY(CI-lECK=l) alerting it for an incoming call and respond with
`ACKI(QUAL=0), it may attempt random access with RQQ('O000O') when its
`user] data equipment is ready to receive the call.
`Then,
`if the user
`no longer wishes to receive the call,
`the unit may inform the TSC
`using RQQ( '11111' ) .
`
`The other 30 status values may be used to send status information,
`as previously arranged with the ystem.
`
`b)
`
`For status sent to a radio unit or line unit:
`
`‘D0000’
`
`requests that the addressed unit call back
`with a speech call.
`
`’OOO0l'
`
`to 'll110' are user-defined status values.
`
`'1l1l1‘
`
`cancels a previous speech call request.
`
`For example, RQQ( '0UOD0') may be used to request a "despat<:her—gueued
`call".
`In this type of call, a radio unit sends RQQ('O0OOO')
`to
`request that the addressed despatcher be informed that the unit's user
`wishes the despatcher to call him (for a speech call).
`The TSC routes
`the information to the despatcher unit, which keeps a list of
`requested calls.
`The despatcher may then request each call at his
`convenience in the usual way; for example, if his unit is a radio
`unit, it sends a Simple call. request RQS (see 5.S.3.1.1 and 9.2.1).
`
`RQQ( 'll1l1') is used to withdraw a previously requested call from the
`addressed unit's call queue. This may be used for cancellation
`either:
`
`i)
`ii)
`
`after the called unit has accepted an RQQ('00D0O') message, or
`after the called unit in an RQS or RQE call has accepted the
`call for call-back (by sending ACKB(QUAL=0)
`in response to the
`availability check); see 9.2.1.4 and 9.2.2.2.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 191
`
`Page 13-1
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 191
`
`

`
`The other 30 status values may be used to send status information,
`as previously agreed between the requesting user and the called user.
`
`The TSC informs a called radio unit of status information using
`message AHYQ — see 5.5.3.2.7.
`The status message may have originated from
`the TSC itself,
`from another radio unit (using RQQ etc.) or from a line
`unit.
`
`The procedures for status messages addressed to the TSC are similar to
`a subset of the procedures for status messages addressed to radio units or
`line units. However, for clarity,
`they are specified separately:
`
`— Section 13.1 specifies the procedures for status messages
`addressed to the TSC.
`
`- Section 13.2 specifies the procedures for status messages
`addressed to radio units or line units.
`
`A typical message sequence for a radio unit sending a status message
`to another radio unit
`(with the same prefix) is illustrated in the example
`below.
`
`TSC to RUS
`
`RUs to TSC
`
`1
`
`ALB
`(1)
`
`
`
`3
`
`AHYQ
`
`AL}-1
`(1)
`
`2
`
`RQQ
`
`ALH
`(1)
`
`4
`
`ACK
`
`1 slot
`<———>
`
`5
`
`ACK
`(1)
`
`ACK
`(1)
`
`
`
`I
`/ \
`\
`frame frame
`
`I
`\
`/
`/ \
`\
`frame frame frame
`
`Example
`
`A message sequence on a control channel for a radio unit sending
`a status message to a radio unit with the same prefix.
`
`1.
`
`ALH
`
`: General Aloha invitation (single—slot frame).
`
`2.
`
`RQQ
`
`: Random access request that status information
`be relayed to the called unit.
`
`3.
`
`AHYQ : Status Ahoy message
`—
`acknowledges the RQQ message
`-
`relays the information to the called
`radio unit and demands a response.
`
`4.
`
`ACK
`
`from the called
`: Acknowledgement ACK(QUAL=O)
`radio unit - information accepted.
`
`5.
`
`ACK
`
`: Acknowledgement ACK(QUAL=O) sent to the calling unit
`to indicate that the called unit has accepted the
`information.
`In this example the TSC immediately
`repeats the ACK message, for added reliability.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 192
`
`Page 13-2
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 192
`
`

`
`OOIOOOOOOOOOOOOOOOOO‘CO
`
`
`
`Procedures for13. tatus Hesse es Addressed to the rec
`
`
`
`
`
`
`
`.13. C Procedures for Status He sa es Addressed to It
`
`13.
`
`.l.1 Res nses to an R messa
`
`addressed to the TSC
`
`A radio unit sends status information to the TSC by generating an RQQ
`message (with IDENT1 = TSCI). complying with the random access protocol.
`on receiving an RQQ message addressed to it, the TSC shall send one of the
`following responses:
`
`a.
`
`ACI((QUA.L=O), ACKI(QUAL=1) or ACKX, with the same prefix
`as the RQQ.
`
`and idents
`
`b.
`
`For STATUS = 'OOOOO' or STATUS = '1llll':
`
`-
`
`-
`
`an M-IYX message with the same prefix and idents as
`the "alerting AHY"
`a. GTC message for the original call (i.e. GTC with the
`same prefix,
`idents and bit D as the alerting AHY).
`
`For acceptable delay, see 7.2.4.
`
`See also 13.1.1.2, 9.1.1.8 and 9.1.1.12.
`
`13.1.1.2 Acknowledgements sent to indicate progress of Rgg transaction
`
`The TSC may send the following acknowledgement messages (with the same
`prefix and idents as the RQQ)
`to indicate to a radio unit the progress of
`its status transaction:
`
`ACKI
`
`(QUAL=l)
`
`-
`
`Intermediate acknowledgement; more signalling to
`follow.
`
`ACKX (QUAL=0)
`ACKX (QUAL=l)
`ACK
`(QUAL=0)
`
`Invalid call; message rejected.
`—
`System overload; message rejected.
`-
`- Transaction has been successfully completed
`i..e.
`the TSC has accepted the status information.
`
`For maximum acceptable delay of repeats of acknowledgements ACKX and lick,
`ee time—out TB in 13.1.2.4.
`
`13 . 1 . 1 . 3
`
`aborting the transaction
`
`A radio unit may abort its status 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 status transaction.
`the TSC shall send
`a response: ACK(QUAL=l) with the same prefix and idents as the RQX.
`
`13. 1. l .4
`
`TSC time-out
`
`The TSC may instruct a radio unit to restart its waiting timer TJ, by
`sending the AH!’ message with bit POINT set to '1', PFIX/IDENT2 set to the
`unit's individual address and IDENT1 set to TSCI; see 9.1.1.7 and 9.2.2.3.
`If a time TJ (minus the tolerance on the radio unit's timer) elapses since
`the last message it received for the status transaction,
`the TSC shall not
`send any further signalling for the transaction.
`See also 13.1.2.5.
`
`See also sections 9.1.1.5, 13.1.2.7 and 13.1.2.8.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 193
`
`Page 13-3
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 193
`
`

`
`
`
`
`
`
`
`13.1.2 Procedures for Radio Units Sendin Status Messa es to the TSC
`
`A radio unit shall make only one call attempt at a time (except in
`emergency); while attempting access or waiting for a terminating (i.e. end-
`of-transaction) acknowledgement to a status message addressed to the TSC,
`the unit shall not request another non-emergency call of any type (unless
`the user first aborts the original transaction)-
`
`13.1.2.1 Criteria for sending "off-hook" or “on—hook" message
`
`If a radio unit on a control channel has been alerted for an incoming
`traffic channel call
`(see 9.2.2.2A), it may initiate the Called Party
`Answer mechanism, i.e. attempt
`random access with RQQ(STATUS='OOOO0‘)
`addressed to the TSC, if:
`
`-
`
`-
`
`-
`
`Its response to the last alerting AHY was ACKI(QUAL=D), and
`
`Its user] data equipment
`
`is now ready to receive the call, and
`
`the call has not
`It is still waiting for the incoming call, i.e.
`taken place or been cancelled (by AHYX or by an AH! for a
`different call) and not more than a time TA has elapsed since
`receipt of the last AHY for the call; see 9.2.2.2A and 9.2.2.4.
`
`If a radio unit has been alerted for an incoming traffic channel call
`and its user then indicates that he no longer wishes to receive the call
`(e.g. he wishes to initiate a call of his own),
`the unit may attempt to
`reject the call as follows:
`
`a.
`
`b.
`
`If it is currently attempting access or waiting for signalling for
`an "off-hook" RQQ, it attempts to send RQX (see 13.1.2.6).
`
`Otherwise, if the unit is still waiting for the incoming call, it
`attempts random access with RQQ(sTATUS='111l1') addressed to the TSC.
`
`the unit responds to AH! messages and
`(Throughout these procedures,
`obey GTCs as specified in section 9.2.2.
`See also sections 13.1.2.7 and
`13.1.2.8.)
`
`13.1.2.2 Request for a status transaction to the TSC
`
`A radio unit requests a status transaction by sending an RQQ message
`on a control channel. complying with the random access protocol
`(see 7.3).
`The fields in the RQQ message shall be set appropriately (see S.5.3.1.7).
`
`The unit shall attempt access until it receives a valid response (see
`13.1.2.3), or until its user aborts the transaction (see 13.1.2.6), 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 13.1.2.4, 13.1.2.5 and 13.1.2.7.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 194
`
`Page 13—4
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 194
`
`

`
`13.1.2.3 Valid resgnses to an RQQ addressed to the TSC
`
`A radio unit shall accept the following messages as a response to its
`R99 to the TSC, and send no more requests:
`
`a.
`
`Pm acknowledgement ACK(QUAL=0), ACKI(QUAI.=l) or ACKX, with the same
`prefix and idents as the RQQ.
`
`b.
`
`For STATUS = ‘D0000’ or STATUS = '11111H
`
`-
`
`-
`
`an AHYX message with the same prefix and idents as the
`"alerting AHY", or
`a GTC message with the same prefix,
`the alerting AI-IY.
`
`idents and bit D as
`
`For other actions on receiving these messages, see sections 13.1.2.4 and
`13.1.2.7.
`See also section 13.1.2.8.
`
`13 . 1 . 2 . 4 Acknowledgement received
`
`If a radio unit attempting access or waiting for further signalling
`for a status transaction to the TSC receives one of the following
`acknowledgements (with the same prefix and idents as the RQQ),
`then it
`shall take action as indicated below.
`
`AC1-CI
`
`(QUAL=1)
`
`—
`
`Intermediate acknowledgement; more signalling to
`follow.
`
`ACKX (QUAL=O)
`ACKX (QUAL=1)
`ACK
`(QlJAL=0)
`
`Invalid call; message rejected.
`-
`system overload; message rejected.
`—
`- Transaction has been successfully completed
`i.e.
`the TSC has accepted the status information.
`
`is received,
`If ACKI(QUAL=l)
`signalling for the transaction.
`
`the unit shall wait for further
`
`the unit shall return to the idle state and may
`If ACKX is received,
`indicate to the user that the transaction has failed.
`
`the unit shall consider the transaction
`is received,
`If ACK(QUAL=O)
`successfully completed and may indicate this to the user.
`
`the unit shall not
`After receiving ACKX or ACK for the transaction,
`request another non-emergency call of any type to the TSC for at least a
`time T8.
`
`13.1.2.5 Time-out after waiting
`
`A radio unit waiting for further signalling for a status transaction
`to the TSC shall return to the idle state if a time TJ has elapsed since
`the last message it sent for the transaction, viz.
`
`requesting the transaction (see 13.1.2.2)
`RQQ:
`or ACK(QUAL=0) , sent in response to an Al-ll’ message with bit POINT = 1
`and IDENTI set to TSCI
`(see 9.2.2.3).
`
`It may also indicate to the user that the outcome of the transaction is
`unknown.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 195
`
`Page 13-5
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 195
`
`

`
`13.1.2.6 Aborting the transaction
`
`If the user wishes to abort the transaction after the unit has sent an
`
`RQQ and while it is still waiting for a terminating acknowledgement,
`unit shall attempt to send 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:
`
`the
`
`a.
`
`b.
`
`It receives ACK(QUAL=l) with the same prefix and idents as the RQX.
`
`It receives ACK(QUAL=0) or ACKX for the transaction it is attempting
`to abort.
`See also 13.1.2.4.
`
`c.
`
`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).
`case, it shall return to waiting for signalling for the status
`transaction (see l3.l.2.4, 13.1.2.5 and 13.1.2.7).
`
`In this
`
`d.
`
`The conditions specified in 13.1.2.7 or 13.1.2.8 occur (applicable
`only for STATUS = '0OOO0' and '11l1l').
`
`In cases a. and b.,
`
`the unit shall return to the idle state.
`
`13.1.2.7 Receiving AHYX or GTC for the incoming call
`
`If a radio unit:
`
`a.
`
`attempting access or waiting for a terminating acknowledgement to an
`"off-hook" or "on-hook" RQQ message (STATUS = 'OOO0O‘ or ‘1lll1'), or
`
`b.
`
`attempting to abort an "off-hook" or "on-hook" RQQ transaction
`
`receives AHYX with the same prefix and idents as the alerting AHY, it shall
`respond with ACK(QUAL=l), stop its alerting signal (if appropriate) and
`retur