Page 156 of 233
`
`PETITIONER'S EXHIBIT 1005
`
`Ex. 1005
` (Part II)
`
`

`
`.2.2
`
`Ba ic Procedures for
`
`ll R
`
`‘
`
`U '
`
`on a Co trol
`
`1
`
`These procedures shall be obeyed by all radio units on a control
`channel (including units making calls or requesting transactions).
`For
`other procedures for all radio units on a control channel, see sections:
`6.2.1
`Control channel discipline.
`7.4
`Individually addressed Aloha message and MOVE message.
`8 .
`Registrat ion procedures .
`13 . 2 . 3
`Receiving status message (AHYQ) .
`14 . 3
`Receiving short data message (HEAD) .
`15. 2
`Data interrogation procedures.
`
`9.
`
`.
`
`.
`
`I
`
`tuc ‘o
`
`t
`
`s
`
`d
`
`n
`
`t‘on or data
`
`ssa
`
`This procedure shall be obeyed by all radio units that are equipped to
`request extended addressing calls, complex diversion or RQC transactions.
`
`If a radio unit on a control channel receives an AHYC message with
`PFIX/IDENT2 matching its individual address then it shall either send
`address information or a data message in the following SLOTS slot(s), or
`transmit ACKx(QUAL=O), as indicated below.
`For timing, see 6.2.1.3.
`
`If
`
`Q
`
`.
`
`.
`
`the unit has sent an extended addressing non-emergency request,
`or has received ACRE or A!iY(B=1) for an extended addressing RQE
`IDENT1 matches IDENTI
`and
`from the request
`and DESC
`is appropriate to IDENT1 (see 5.5.3.2.8)
`and
`SLOTS
`corresponds to the request
`(i.e. if IDEN'I‘l=PSTNGI and FLAGl=l then SLO’l‘S='lO' else SLOTS='0l')
`
`then it shall transmit the full address information for ID!-INTI, conforming
`to the codeword formats defined in section 5.6.1.2.2 (SAMIS, Mode 1).
`
`Otherwise
`If
`
`the unit has sent a request for 3-address diversion (RQT, PLAG2=l)
`IDENT1 is set to DIVERTI
`and
`and misc
`is set to ‘G00’
`and
`SLOTS
`is set to '01‘
`
`then it shall transmit the "blocked address", conforming to the interprefix
`codeword format defined in section 5.6.l.2.2 (SAHIS, Mode l, D!-:SC='OO0').
`
`otherwise
`If
`
`the unit has sent an RQC message
`IDENT1 is set to SDMI
`and
`and DESC
`is set to ‘O00’
`and
`SLOTS matches SLOTS from the RQC
`
`then it shall transmit its short data message, conforming to the codeword
`formats defined in section 5.6.2 (HEAD).
`
`Otherwise
`
`The unit shall transmit ACKX(QUAL=O), with the same prefix and idents as
`the AHYC.
`
`Page 157 of 233
`
`PETITIONER'S EXHIBIT 1005
`
`Page 9-17
`
`

`
`9.2.2.2 Availability check on called radio unit
`
`If a radio unit on a control channel receives an AHY message with
`PFIX/IDENT1 matching its individual address and bit POINT set to '0'
`then
`it shall respond with the appropriate acknowledgement (see below), with the
`same prefix and idents as the AHY.
`If bit AD = O in the AHY message,
`the
`unit shall respond in the slot following the AHY; if bit AD = 1, a data
`codeword is appended (containing the calling address) and the unit shall
`respond in the slot following the data codeword.
`For timing, see 6.2.1.3.
`
`A)
`
`1 to 8 O0
`NT2 = Ident
`:
`traffic channel call
`ncom n
`Ident
`(8121 to 8180),
`INCI,
`IPFIXI, ESTNGI or PABX;
`
`If bit AD = 1 in the AH! message but the appended data codeword was
`not decodeable and the unit requires the calling address for its
`operation,
`then it may request a retransmission by sending
`ACKB(QUAL=1):
`
`ACRE (QUAL=1)
`
`- The unit requires the message to be retransmitted.
`
`Otherwise
`
`The unit may reject the incoming call by sending ACKX(QUAL=O)
`or ACXV(QUAL=l):
`
`ACKX (QUAL=O)
`
`ACKV (QUAL=1)
`
`Otherwise
`
`— The unit cannot accept the call
`e.g. D = O in the AHY message and the unit
`has no speech equipment, or
`D = 1 in the AH! message and the unit
`has no data equipment.
`- The user has indicated that he does not wish to
`receive this call (e.g. using the “Busy control”).
`
`If bit D = O in the AH! message and IDENT2 is not set to INCI,
`unit may accept the call for call-back by sending ACKB(QUAL=O):
`
`the
`
`ACKB (QUAL=O)
`
`— The unit has accepted the call for call-back.
`
`Otherwise
`
`i) If bit CHECK = 0 in the AHY message,
`send ACK(QUAL=0):
`
`then the unit shall
`
`ACK
`
`(QUAL=0)
`
`- Unit is available for the call.
`
`then the unit shall send
`ii) If bit CHECK = 1 in the AH! message,
`to indicate its state of
`either ACKI(QUAL=O) or ACK(QUAL=O),
`readiness so far as it is able.
`For ACKI(QUAL=O),
`the unit shall
`alert the user or take action to prepare the data equipment.
`
`ACKI
`
`(QUAL=0)
`
`ACK
`
`(QUAL=0)
`
`- Unit alerting but user] data equipment not ready
`e.g. D = O in the AHY message and the
`unit's RFCC is not currently active, or
`D = 1
`in the AH! message and the
`unit's data equipment
`is not ready.
`- User] data equipment is available for the call.
`
`Page 9-18
`
`OCCOOOCOOOOOOOOOOCOOOOI]
`
`Page 158 of 233
`
`PETITIONER‘S EXHIBIT 1005
`
`

`
` The unit may indicate the calls: (by reference to PFIX/IDENT2 from the AH’!
`
`message or P1-‘IX2/IDENT2 from the data codeword), and may indicate whether
`the incoming call is an emergency call (by reference to bit it from the
`AHY).
`
`After receiving an M-[Y message for an incoming traffic channel call
`and responding with 1\CK(QUAL=0) or AC1-II(QUAL=0),
`the unit shall ignore
`group call GTC messages as specified in ection 9.2.2.5 rule 2 or 3, until
`either:
`
`
`
`
`
`
`
`
`
` a.
`
`
`
`it receives channel allocation signalling for the incoming call (Le.
`a GTC message with the same prefix,
`idents and bit D as the AHY), or
`it assumes that the call will not take place; see 9.2.2.4.
`
`b.
`
`
`
`
`
`
`
`
` If a radio unit receives AHY(CHBCK=1) alerting it for an incoming call
`and responds with ACKI(QUAL=O), it may attempt to send RQQ(STATUS='0O0OO’)
`to the TSC when its user/ data equipment is ready to receive the call.
`After responding with AcKI(QUAL=O) or ACK{QUAL=O), it may send
`RQQ(S'l‘ATUS='1lll1') if the user no longer wishes to receive the call; in
`this case, it shall respond to any further AHY messages with ACKV(QUAL=l).
`See also 13.1.2.1.
`
`
`
`
`
`If, while waiting for an incoming traffic channel call, a radio unit
`receives a repeat AHY, it shall send the appropriate acknowledgement and
`for
`continue with any "off-hook" or "on-hook“ signalling in progress; also,
`ACK(QUAL=0) or ACKI(QUAL=O), it shall restart its timer TA (see 9.2.2.4).
`If the unit receives an AI-IY for a different incoming traffic channel call,
`it shall abandon any signalling for the old call and obey the new AHY; see
`also 9.2.2.4 and 13.1.2.8.
`
`3) Availability check for short data message :
`
`IDENT2 = SDHI
`
`ACKV(QUAL=l).
`
`otherwise it shall send ACK(QUAL=O).
`
`
`
`
`
`
`
`
`
`
`
`
` The unit may reject the short data message by sending ACKX(QUAL=0) or
`
`
`
`
`
`
`
`
`
`
`
`ACKX (QUAL=G)
`
`ACKV (QUAL=l)
`
`-
`
`-
`
`The unit cannot accept the short data message
`e.g. it has no data equipment.
`The user has indicated that he does not
`wish to receive short data messages.
`- Unit is available to receive a short data message.
`
`
`
`
`
`
`
`
`
`
`
`
`ACK
`
`(QUAI.=O)
`
`C)
`
`"No-call" test availability check :
`
`IDENT2 = DUHHYI
`
`
`
`
`
`The unit may indicate that it is not suitably equipped by sending
`ACKX(QUAI..=0). Otherwise it shall send ACK(QUAL=O).
`
`
`
`
`
`ACKX (QU1-\L=O)
`
`- The unit could not accept a call of this type
`e.g. D = O in the AH! message and the unit
`has no speech equipment, or
`D = l in the Am! message and the unit
`has no data equipment.
`— Unit is in radio contact and is suitably equipped.
`
`
`
`
`
`ACK
`
`(QUAL=0)
`
`D)
`
`check :
`Invalid availabilit
`1 to 8100
`Ident
`IDENT2
`
`
`IDENT2=Ident(8l21 to 8180],
`INCI.
`IPFIXI. PSTNGI. PABXI, SDMI or
`
`
`DUMMYI
`
` The unit shall send AC1-(x(QUAL=O),
`to reject the availability check.
`
`
`
`
`Page 9-19
`
`PETITIONER'S EXHIBIT 1005
`Page 159 of 233
` PETITIONER'S EXHIBIT 1005
`
`

`
`9.2.2.3 Availability check on regpesting radio unit
`
`If a radio unit on a control channel receives an AHY message with
`PFIX/IDENT2 matching its individual address and bit POINT set to '1'
`then
`it shall respond with the appropriate acknowledgement
`(see below), with the
`same prefix and idents as the AH!.
`If bit AD = 0 in the AHY message,
`the
`unit shall respond in the slot following the AHY; if bit AD = 1, a data
`codeword is appended and the unit shall respond in the slot following the
`data codeword.
`For timing, see 6.2.1.3.
`
`ACK
`
`(QUAL=O)
`
`— The unit is waiting for signalling for a call or
`transaction appropriate to IDENT1 and bit E i.e.
`a.
`IDENTI is the called ident or gateway
`(or REGI for a registration request)
`E is '1'
`for an emergency call, otherwise ‘O’;
`see section 5.5.3.2.1.
`
`b.
`
`See also sections 8.2.2.4, 9.2.1.6, 10.2.7, 12.2.5,
`13.1.2.5, 13.2.2.5 and 14.2.6.
`
`ACKX (QUAL=0}
`
`- The unit is not waiting for signalling for a call
`or transaction appropriate to IDENT1 and bit E.
`
`9.2.2.4 Cancelling alertgwaiting state of called unit
`
`If a radio unit on a control 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 unit that has received an AHY message for an incoming traffic
`channel call
`(see 9.2.2.2A), and responded with ACK(QUAL=O) or
`ACKI(QUAL=0), shall assume that the call will not take place if one of the
`following occurs:
`
`a.
`
`b.
`
`c.
`
`It has not received channel allocation signalling for the call at a
`time TA after the last ACK(QUAL=O) or ACKI(QUAL=O) it sent in response
`to an RH! for the call.
`
`It receives an AHYX message with the same prefix and idents as
`the AHY.
`In this case,
`if currently attempting an "off—hook" or
`"on~hook" RQQ transaction for the incoming call, it shall return
`to the idle state - see 13.1.2.7.
`
`It receives an AHY message checking its availability for a
`different incoming traffic channel call (i.e. bit D and/or bit E
`and/or the calling address is different from the original AHY).
`In this case, if currently attempting an "off—hook" or "on-hook"
`RQQ transaction for the original call, it shall abandon the
`transaction — see 13.1.2.8.
`
`the unit shall stop the alerting signal (if
`In cases a. and b.,
`appropriate) and may indicate to the user/ data equipment that the call
`will not take place; it shall also note that rule 2 or 3 of section 9.2.2.5
`(requiring it to ignore GTC messages for incoming group calls) no longer
`applies.
`In case c.,
`the unit shall obey the procedures in 9.2.2.2A for
`the new call.
`
`PETITIONER'S EXHIBIT 1005
`Page 160 of 233
`PETITIONER'S EXHIBIT 1005
`
`Page 9~2O
`
`

`
`
`
`9-2-2-§ Igafiig ghggnel gllocatigg
`
`A radio unit on a control channel shall check all GTC messages it
`receives to see whether the message is addressed to it, that is, whether:
`
`PFIX/IDENT2 from the GTC message matches its individual address
`PFIX/IDBN'l'l matches any of its designated addresses for this system
`IDENTI i the system-wide all-call ident ALLI.
`
`or
`or
`
`If the G'l'C message is addressed to it, the unit shall use the appropriate
`rule below to decide whether to obey the cotunand:
`
`1.
`
`If the unit is making an emergency (RQE) call and has not received
`ACKB(QUAL-0) or AHY(E=l)
`for its call, it shall obey the GTC message
`if and only if its emergency call is a short addressing non-PABX call
`and the GTC message is for the requested call (see 10.2.2 and 10.2.6).
`
`If the unit is waiting for further signalling for its emergency call,
`after receiving ACKE(QUAL=O) or A!-lY(E=l) for the call, it shall obey
`the GTC message if and only if it is individually addressed by the GTC
`(i.e. its individual address is PFIX/IDEN'rl or PFIX/IDBNT2).
`
`2.
`
`Otherwise
`
`If the unit is waiting for an incoming emergency call (see 9.2.2.25),
`it shall obey the GTC message if and only if it is individually
`addressed by the GTC.
`
`.
`
`.
`
`3.
`
`4.
`
`otherwise
`If the unit is waiting for an incoming non-emergency traffic channel
`call (see 9.2.2.2A), it shall obey the GTC message if and only if
`
`it is individually addressed by the GTC or IDENTI is set to ALLI.
`
`Otherwise
`
`It the unit is attempting access or waiting for further signalling for
`a non-emergency call or transaction, it shall obey the GTC message if
`and only if:
`
`or
`or
`
`it is individually addressed by the GTC message,
`IDENTl is set to ALLI,
`Pl-‘IX/IDEN'rl is one of the unit's group addresses, and
`the unit is attempting to call that group, and
`the user wishes to receive group calls, and
`the unit knows that it is not the calling unit (see below).
`
`if making an interprefix group call, a radio unit shall ignore
`(Thus,
`GTC messages containing the requested group address and the requested
`bit D unless it receives a GTC message for the calling unit in the
`next slot
`(see a. below) and finds that it is not the calling unit.
`If it is the calling unit, it obeys the individually addressed GTC
`message. )
`
`5.
`
`Otherwise (i.e. if not waiting for any call or transaction)
`The unit shall obey the GTC message if:
`
`or
`or
`
`it is individually addressed by the OTC message,
`IDENT1 is set to ALLI,
`PFIX/IDENTI is one of the unit's group addresses
`and the user wishes to receive group calls.
`
`Page 9-21
`
`Pa e 161 of 233
`
`
`
`PETITIONER'S EXHIBIT 1005
`
`

`
`If the unit is required to obey the GTC command, it shall perform the
`following actions:
`
`a.
`
`It shall tune to the designated forward traffic channel, obeying
`the following timings:
`
`-
`
`-
`
`the unit shall be able to receive on the
`If IDENT2 / IPFIXI,
`traffic channel within 35 ms after the end of the GTC message.
`
`the unit shall be able to receive on the
`If LDENT2 = IPFIXI,
`traffic channel within 142 ms after the end of the GTC message;
`(this allows a called radio unit in an interprefix call to
`remain on the control channel for one timeslot after receiving
`GTC,
`to extract the caller's address if the next message is
`a GTC for the calling unit).
`
`IDENTl and IDENT2 from the GTC message and also
`It shall note PFIX,
`the channel number of the control channel (for use in obeying the
`procedures in sections 9.2.3.1, 9.2.3.3, 9.2.3.5, 9.2.3.6 and
`9.2.3.7).
`
`If bit D from the GTC message is '0', then the unit shall unmute
`the audio (for speech communication).
`If bit D is '1‘,
`the unit
`shall mute the audio (for data communication) and shall note that
`it need not send call maintenance messages within items (unless
`required by the system by prearrangement).
`
`If IDENTI from the GTC message is ALLI and PFIX/IDENT2 from the
`GTC message is not its individual address,
`then the unit shall
`inhibit user transmission on the traffic channel. Otherwise it
`shall enable user transmission on the traffic channel.
`
`b.
`
`c.
`
`d.
`
`It may also give an indication to the user. This may include an indication
`of the caller on the called party's unit. Such an indication should be
`derived from any availability check performed for the call. However if the
`contents of IDENT2 of the GTC message differ from the contents of IDENT2 in
`the AH! availability check and are not DUMMYI,
`the indication should be
`derived from IDENT2 of the GTC message.
`
`If the unit does not obey a GTC message (orb for IDENT2 = IPFIXI, a
`GTC message in the next slot), and the designated traffic channel
`is the
`control channel on which the message was received,
`then the unit shall
`return to the control channel acquisition procedures (see 6.2.1.1).
`
`9.2.2.6 Storing call maintenance parameters
`
`A radio unit shall store the call maintenance parameters specified by
`the most recent broadcast message ECAST,
`sYSDEF='OO010‘
`it has received
`referring to the system it is currently using. These parameters indicate:
`
`a.
`
`b.
`
`whether the system requires that a radio unit on an allocated traffic
`channel shall send Pressel On messages at the start of each speech
`item it transmits (the number of messages is specified in 9.2.3.1];
`
`whether radio units shall send messages periodically within speech
`items and,
`if so,
`the maximum interval (in seconds} between the start
`
`Page 9-22
`Page 162 of 233
`PETITIONER'S EXHIBIT 1005
`PETITIONER'S EXHIBIT 1005 Page 1
`
`
`
`

`
`
`
`of the item and the first periodic message. and then between
`subsequent periodic messages,-
`
`c.
`
`whether a called unit in a group shall set PFIX/IDENT1 in HAINT
`messages it sends to its individual address or to the group address
`from the GTC message.
`
`See also 5.5.4.2, 5.5.4.5c and 9.2.3.1. At the start of a session, until
`it receives a BCAST, SYSDEJ-‘='0O010' message,
`the unit shall:
`
`-
`
`-
`—
`
`send Pressel on messages
`
`send periodic messages with a maximum interval '1‘?
`set PFIX/IDENT1 to the group address
`(when it is a. called unit in a group).
`
`Page 163 of 233
`PETITIONER'S EXHIBIT 1005
` PETITIONER'S EXHIBIT 1005
`Page 163 0
`
`Page 9-23
`
`

`
`9.2.3
`
`Procedures for All Radio Units on an Allocated Traffic Channel
`
`These procedures shall be obeyed by all radio units on an allocated
`traffic channel (except when exempted by emergency call procedures agreed
`with the system — see 10.2.8).
`For other procedures for all radio units on
`a traffic channel, see sections:
`
`6.2.2
`11.3
`
`15.2
`
`Traffic channel discipline.
`Instruction to send extended address information.
`
`Data interrogation procedures.
`
`9.2.3.1 Call maintenance messages
`
`During a speech call (see 9.2.2.5 and 9.2.3.4), a radio unit shall
`send the following call maintenance messages within speech items:
`
`a.
`
`b.
`
`c.
`
`the radio unit
`If required by the system (see 9.2.2.5 and 9.2.3.4),
`shall send a minimum of one Pressel on message (MAINT, oPER='0OO') at
`the start of each speech item it transmits.
`If defined by the system
`the radio unit may send NPON messages. when NPON is not defined it
`shall default to the value 1. Where more than one message is sent the
`form of transmission specified in 3.3.2 shall be used.
`
`the radio unit shall send periodic
`If required by the system,
`messages (MAINT, OPER='OlO') within each speech item it transmits.
`See 9.2.2.6 for the maximum interval between periodic messages.
`
`The radio unit shall send a minimum of one Pressel off message (HAINT,
`0PER=’OO1') at the end of each speech item it transmits, as the last
`signal before retuning to the forward traffic channel.
`If defined by
`the system the radio unit may send NPOFF messages. Where NPOFF is not
`defined it shall default to the value 1. Where more than one message
`is sent the form of transmission specified in 3.3.2 shall be used.
`
`PFIX/IDENT1 in HAINT messages sent by a radio unit is the unit's individual
`address if it was individually addressed by the GTC message; otherwise
`(i.e. for a called unit in a group), PFIX/IDENTI shall be set to either the
`unit's individual address or to the group address (PFIX/IDENT1)
`from the
`GTC message, as required by the system — see 9.2.2.5 and 9.2.2.6.
`
`(During a data call, a radio unit need not send the above messages,
`unless required by the system by prearrangement.)
`
`9.2.3.2 Availability check on a traffic channel
`
`If a radio unit on a traffic channel receives an AHY message with:
`
`O 1
`
`PFIX/IDENTI matching its individual address and POINT
`PFIX/IDENT2 matching its individual address and POINT
`
`or
`
`then it shall respond with the appropriate acknowledgement (see below),
`with the same prefix and idents as the AHY.
`If bit AD = 0 in the AH!
`message,
`the unit shall time its response from the end of the AHY address
`codeword; if bit AD = 1, a data codeword is appended and the unit shall
`time its response from the end of the data codeword.
`For timing, see
`6.2.2.2.
`
`Page 164 of 233
`
`Page 9-24
`
`PETITIONER‘S EXHIBIT 1005
`
`

`
`a.
`
`b.
`
`If POINT - 0,
`
`the unit shall send ACMQUAL-0).
`
`ACK (QOAL=0)
`
`- The unit is in radio contact.
`
`If POINT - 1,
`
`the unit shall send ACMQUAI.-0) or Acxx(QUAL-O):
`
`AC!
`
`(QUALIO)
`
`acxx (QUAI.-0)
`
`- The unit is waiting for signalling for an Include
`call appropriate to IDlll'l'l (i.e.
`IDBNTI is the
`called ident or gateway).
`see also section 11.2.5.
`- The unit is not waiting for signalling for an
`Include call appropriate to IDBNT1.
`
`...
`
`i
`
`i st
`
`If a radio unit on a traffic channel receives a call maintenance
`
`(CHAN) equal to the number of
`message HAINT, OPBR=-'11l' with channel number
`then it shall inhibit user
`the traffic channel and an applicable address,
`transmission while it is tuned to this traffic channel (i.e. it shall
`
`disable the pressel for a speech call or inhibit user data for a data
`call).
`
`The address (PFIX/ID3N'rl)
`
`from the HAINT message is applicable if:
`
`a.
`b.
`
`c.
`
`PPIX/IDENT1 matches the unit's individual address, or
`PPIX/IDENT1 is equal to PFIX/IDENTI from the GTC message and the unit
`is not the calling party, or
`IDENT1 is equal to ALLI.
`
`9......
`
`.. ...... . .. . .
`
`.
`
`......
`
`If a radio unit on a traffic channel receives a GTC message with:
`
`PFIX/IDBNT2 from the GTC message matching its individual address
`PFIX/IDENTI matching any of its designated addresses for this system
`IDENTI set to the system-wide all-call ident ALLI
`
`or
`or
`
`then it shall perform the following actions:
`
`i) It shall tune to the designated forward traffic channel and shall
`be able to receive within 35 ms after the end of the GTC message.
`
`ii) If bit D from the GTC message is '0', then the unit shall unmute
`the audio (for speech communication).
`If bit D is '1’,
`the unit
`shall mute the audio (for data communication) and shall note that
`it need not send call maintenance messages within items (unless
`required by the system by prearrangement).
`
`from the GTC message is ALLI and PFIX/IDENT2 from the
`iii) If IDENTI
`GTC message is not its individual address,
`then the unit shall inhibit
`user transmission. Otherwise it shall enable user transmission.
`(See also l1.2.7c.)
`
`when the unit has tuned to the designated traffic channel, it may continue
`conmunication.
`
`IDENTI and IDENT2 from the
`(Note that the unit continues to use PFIX,
`original GTC message (see 9.2.2.5) in obeying the procedures in sections
`9.2.3.1, 9.2.3.3, 9.2.3.5, 9.2.3.6 and 9.2.3.7).
`
`I O O C O O O O I O O .
`
`O O C C I O O O O I O P
`
`
`
`age 165 of 233
`
`Page 9-25
`
`PETITIONER'S EXHIBIT 1005
`
`

`
`9.2.3.5 Going "on-hook" on traffic channel
`
`(or if its data
`If a radio unit's user goes on-hook or equivalent
`equipment indicates that a data call has ended) while it is tuned to the
`traffic channel, and if its individual address is either PFIX/IDENT1 or
`PFIX/IDENT2 from the GTC message,
`then the unit shall send a number of
`Disconnect messages (HAINT, OPER='O1l') on the traffic channel.
`It shall
`send NDl Disconnect messages if its individual address is PFIX/IDENTI from
`the GTC, or ND2 if its individual address is PFIX/IDENT2 from the GTC. The
`unit shall send the messages continuously (see 3.3.2 and 6.2.2.2) and mute
`the audio, and shall then return to the control channel acquisition
`procedures (see 6.2.1.1).
`
`A radio unit whose individual address is neither PFIX/IDENTl nor
`PFIX/IDENT2 from the GTC message (i.e. a called unit in a group call) may
`leave the call at any time when the user goes on—hook or equivalent; it
`shall mute the audio and return to the control channel acquisition
`procedures (without signalling). However,
`the calling unit sends ND2
`Disconnect messages for a group call
`(see above), and so the caller should
`be advised to remain with a group call until its completion.
`
`9.2.3.6 Time-outs on traffic channel
`
`A radio unit on a traffic channel shall time the length of a period
`during which it detects no activity (e.g. fails to receive adequate signal
`strength) and shall also time the length of each item it transmits.
`
`If the unit detects no activity on the forward traffic channel for a
`time TN then it shall assume that the call is terminated: it shall mute the
`
`audio and return to the control channel acquisition procedures (without
`signalling), and may indicate to the user that the call has ended.
`
`If the unit transmits an item that reaches the maximum permitted
`duration TT then it shall mute the audio and shall:
`
`i)
`ii)
`
`ressel Off messages (for a speech item);
`send NPON
`send NDl or ND2 Disconnect messages if its individual address is
`PFIX/IDENTI or PFIX/IDENT2 from the GTC (as in section 9.2.3.5).
`
`It shall then cease transmission on the traffic channel and return to the
`
`control channel acquisition procedures, and may indicate to the user that
`the call has ended.
`
`9.2.3.7 "Selective" clear-down message : HAINT with 0PER='llO'
`
`If a radio unit on a traffic channel receives a call maintenance
`
`message MAINT, 0PER='llO' with:
`
`(CHAN) equal to the number of the traffic channel
`channel number
`PFIX/IDENTl not equal
`to PFIX/IDENT1 from the GTC message
`PFIX/IDENTI not equal to PFIX/IDENT2 from the GTC message
`
`and
`and
`
`then immediately it shall mute the audio and return to the control channel
`acquisition procedures, and may indicate to the user that the call has
`ended.
`
`Page 166 of 233
` Page 1
`
`Page 9~26
`
`PETITIONER'S EXHIBIT 1005
`PETITIONER'S EXHIBIT 1005
`
`

`
`9 . 2 . 3 . 8
`
`CLEAR message
`
`If a radio unit on a traffic channel receives a clear-down message
`CLEAR with :
`
`(CHAN) equal to the number of the traffic channel
`channel number
`field REVS equal to '10101010lO1D'
`
`and
`
`then it shall immediately mute the audio and move to the forward control
`channel
`indicated by field CONT in the CLEAR message (to be capable of
`receiving within 35 ms after the end of the CLEAR address codeword), and
`may indicate to the user that the call has ended.
`
`Note:
`
`If field CONT in the CLEAR message is equal to '0OOOOO0O0O',
`then the channel movement is syatern—dependent.
`
`C O O O O O O O O O O O O O O O O O O O O O 9
`
`Page 167 of 233
`
`Page 9-27
`
`PETITIONER'S EXHIBIT 1005
`
`PETITIONER'S EXHIBIT 1005
`
`

`
`Page 168 of 233
`
`PETITIONER'S EXHIBIT 1005
`
`

`
`
`
`This section defines standardised procedures for emergency calls.
`(Note that systems may have alternative emergency procedures employing
`customised messages, and radio units which have suitable arrangements with
`the system may use these.)
`
`standard emergency calls from radio units may be requested to:
`
`line unit or group
`a radio unit,
`-
`- all units in the system
`—
`a PABX extension (short or extended addressing)
`-
`a PSTN destination (prearranged or general).
`
`Emergency calls from radio units are requested using the Emergency Call
`Request Message R93 (see 5.5.3.1.5). Bit D in the RQE message specifies
`whether the unit is requesting speech or data communication. An extended
`addressing request is indicated by setting IDENT1 in the R93 message to the
`appropriate gateway ident.
`A radio unit may interrupt a non—emergency call attempt to request an
`emergency call; in this case it abandons the previous call attempt.
`Messages AcKE(QUAL=O) and I-m¥(E=1) are responses unique to R9}: calls; they
`indicate positively that the 'l‘sC has received the RQE and that any further
`signalling sent to the unit is for the emergency call. Until it receives
`AcKE(QUAL-0) or AHY(E-1),
`the unit ignores other acknowledgements and
`rejects Mode 1 AHYC messages.
`
`Usually emergency calls will take precedence over all other calls.
`Emergency calls may be pre-emptive, that is, another call may be terminated
`prematurely to free a channel for an emergency call.
`
`if the RQE is not
`in the R9}: message (i.e.
`If bit EXT is set to '0'
`for a short addressing PABX call) then 1-‘LAG2 may be set to '1'
`to indicate
`that the calling radio unit is requesting a special mode of emergency
`service previously arranged with the system;
`the TSC determines the
`required action by reference to the calling unit's address, and the TSC and
`radio unit follow appropriate (non-standardised) procedures.
`In this case,
`the meanings of fields IDENT1, D and Fuel in the R03 message may be
`redefined. For example, EX'1'=0/P'LAG2=1 could indicate that field IDENT1
`contains a special 13-bit message to be acted upon by the TSC; these
`special messages could have any prearranged meaning (such as the nature of
`the emergency,
`the required service or the unit's geographical position).
`see also the introductions to sections 10.1 and 10.2.
`
`.
`
`.
`
`.
`
`Page 169 of 233
`
`PETITIONER'S EXHIBIT 1005
`
`Page 10-)
`
`

`
`10.1
`
`standard Energengy call Procedures for TSC
`
`If the TSC offers an emergency service then it shall be prepared to
`accept an RQE message in any random access slot.
`
`The TSC procedures detailed in the following subsections are for
`standxrd emergency calls.
`If, owing to incorrect operation of a radio
`unit,
`the TSC receives an RQE message requesting a special mode of service
`(i.e. EXT=O/FLAG2=1)
`from a radio unit with which it has no previous
`arrangements then it may reject the request by responding with ACKE(QUAL=O)
`and then sending ACKX(QUAL=0), where both ACRE and ACKX contain the same
`PFIX,
`IDENT1 and IDENT2 as the RQE message.
`
`10.1.1 Respgnses to a short addressing standard emergegcy reggest
`
`A radio unit requests an emergency call by generating an RQE message,
`complying with the random access protocol (unless it has other arrangements
`with the system).
`On receiving a short addressing RQE message,
`the TSC
`shall send a response as soon as possible; for maximum permissible delay,
`see 7.2.4. Valid responses are:
`
`a.
`
`b.
`
`c.
`
`ACKE(QUAL=0); see 5.5.2.1 and 10.2.2.
`
`An availability check for the call (AH! with bit E set to '1');
`see 9.1.1.5, 9.1.1.7 and 10.2.2.
`
`For a non-PABX call (i.e. EXT=O in the RQE message):
`-
`A Go To Channel message GTC for the call; see 9.1.1.12 and 10.2.2.
`(This is the recommended response if the TSC does not make any
`availability checks for the call - see l0.l.6.)
`
`is sent only as a response to an RQE message; it is an
`ACKE(QUAL=0)
`intermediate acknowledgement,
`indicating that further signalling will
`to
`follow.
`The TSC may then send other acknowledgements (e.g. ACKI, ACKX)
`the waiting calling unit at appropriate times to indicate the progress of
`the call set-up; see section 10.1.5.
`
`10.1.2 Response to an extended addressing standard emergency reggest
`
`A radio unit requests an emergency call by generating an RQE message,
`complying with the random access protocol
`(unless it has other arrangements
`with the system).
`on receiving an extended addressing RQE message,
`the TSC
`shall send a response: ACKE(QUAL=0) with the same prefix and idents as the
`RQE.
`For maximum permissible delay, see 7.2.4.
`
`10.1.3 Signalling for previous call
`
`the TSC shall not send any further
`After receiving an RQE message,
`signalling messages to the calling unit for any previous call requested by
`that unit
`(though, for a traffic channel call, it may send AHYX to inform a
`called radio unit that the call will not take place).
`
`Page 170 of 233
`
`PETITIONER'S EXHIBIT 1005
`
`Page 10-2
`
`

`
`10.1.4 Obtaining extended address information
`
`After receiving an extended addressing RQE message and responding with
`AcKE(QUAL=O),
`the me may demand the full called address information from
`the calling radio unit by sending the M-IYC message (as in section 9.1.1.3).
`
`10.1.5 Acknowledgements sent to indicate grogress of emergency call
`
`After sending ACKE(QUAL=0) or an availability check AI-[Y with E=1 as a.
`response to an emergency call request,
`the TSC may send acknowledgements
`ACKI, ncxq, ACKX, acxv, ncxs{QuAL=o) or hCKT(QUAI.=O)
`to the calling unit to
`indicate the progress of the call {as in section 9.1.1.4).
`
`10.1.6 Availabilitg checks before allocating traffic channel
`
`For emergency calls. the mandatory availability check detailed in
`section 9.1.1.5 may be dispensed with.
`(For emergency calls, availability
`checks on radio units are made using the AH‘! message with bit E set to
`' 1' . )
`
`10.1.7 TSC time—out
`
`The TSC may instruct the calling unit to restart its waiting timer TW,
`by sending the AH! message with bit POINT set to '1'
`(and bit E set to
`'1'): see 9.1.1.7 and 9.2.2.3.
`If a time Tw, minus the tolerance on the
`radio unit's timer, elapses ince the last message it received for an
`emergency call
`(from the calling unit),
`the TSC shall not send any further
`signalling for the call, except that it may send AI-IYX to inform a called
`radio unit that the call will not take place.
`see also 10.2.7.
`
`10.1.8 Other Qrocedures
`
`a.
`
`b.
`
`A calling radio unit may send an RQX message to cancel its emergency
`call.
`The TSC procedures are as defined in 9.1.1.8 for Simple calls.
`
`It is recommended that the TSC does not amalgamate an emergency
`call with any other call in its queues.
`
`c.
`
`If all traffic channels are in use then the TSC may terminate another
`
`call prematurely (with or without warning to the correspondents using
`it), in order to free the channel for an emergency call.
`
`cl.
`
`The procedures for traffic channel allocation and call maintenance
`and clear-down are as detailed in 9.1.1.12 and 9.1.2.
`
`Page 171 of 233
` “U
`age 171 0
`
`PETITIONER'S EXHIBIT 1005
`
`PETITIONER'S EXHIBIT 1005
`
`Page 10-3
`
`

`
`10.2
`
`standard Bmergengy Call Procedures for Radio Units
`
`A radio unit shall make only one emergency call attempt at a time.
`While attempting access or waiting for further signalling for an emergency
`request,
`the unit shall not request another call of any type (unless the
`user first cancels the original call).
`It may make an emergency call at
`any other time.
`For example, it may interrupt a non-emergency call attempt
`to request an emergency call;
`in this case it shall abandon the previous
`call attempt (without sending RQX).
`
`The ra