throbber
••
`••
`••
`••
`
`••
`
`••••• •
`
`• •••
`
`••
`•
`
`it may give an indication to the user, and shall revert to the idle
`If so,
`state at the end of the call.
`
`9.2.1.6 Time-out after waiting
`
`A calling radio unit waiting for further signalling for a Simple call
`shall return to the idle state if a time TW has elapsed since the last
`message it sent for the call, viz.
`
`or
`
`(see 9.2.1.1)
`requesting the Simple call
`RQS,
`SAMIS, providing extended address information for the call
`9.2.2.1)
`in response to an AHY message with bit POINT = 1
`or ACK(QUAL=O), sent
`and IDENTl as the called ident or gateway (see 9.2.2.3).
`
`(see
`
`It may also indicate the failure to the user.
`
`If the user tries to initiate another non-emergency call of any type
`(without first cancelling it) while his unit
`or re-initiate the same call
`is waiting for signalling for the call,
`the unit shall
`ignore the command.
`
`9.2.1.7 Call cancellation
`
`If the user wishes to cancel his Simple call and the unit has not yet
`sent an RQS,
`then it shall return immediately to the idle state.
`Otherwise, if the unit has sent an RQS,
`it shall attempt to send a call
`cancellation request RQX (see 5.5.3.1.3), complying with the random access
`protocol
`(see 7.3).
`It shall attempt access until one of the following
`occurs:
`
`a.
`
`b.
`
`c.
`
`d.
`
`e.
`
`It receives ACK(QUAL=l) or AHYX, with the same prefix and idents
`as the RQX, confirming cancellation of the call.
`
`It receives
`to cancel.
`
`ACKX, ACKV or ACKT(QUAL=O)
`See also 9.2.1.4.
`
`for the call it is attempting
`
`for the call it is attempting to cancel;
`It receives ACKB(QUAL=O)
`in this case,
`it may indicate to the user that the call has been
`accepted for call-back and that the cancellation was unsuccessful.
`(Withdrawal of the request may then be attempted using an RQQ
`message with STATUS='lllll', addressed to the called unit; see
`section 13.)
`
`It receives a GTC message for the call it is attempting to cancel;
`in this case,
`it shall proceed to the designated traffic channel
`(see 9.2.2.5) and then revert to the idle state at
`the end of the
`call.
`
`It has sent the maximum number of transmissions NR and received no
`response, or its access time-out TC has expired (see 7.3.8).
`In this
`it shall return to waiting tor signalling for the Simple call
`case,
`(see 9.2.1.4 to 9.2.1.6).
`
`In cases a., b. and c.,
`
`the unit shall return to the idle state.
`
`If the user tries to "cancel" a call when his unit is not attempting
`access or waiting for signalling for a call,
`the unit shall
`ignore the
`conunand.
`
`Page 9-16
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 156 of 294
`
`

`
`9.2.2
`
`Basic Procedures for All Radio Units on a Control Channel
`
`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.
`Registration procedures.
`13.2.3
`Receiving status message (AMYQ).
`14.3
`Receiving short data message (HEAD).
`15.2
`Data interrogation procedures.
`
`9.2.2.1
`
`Instruction to send address information or data message
`
`This procedure shall be obeyed by all radio units that are equipped to
`request extended addressing calls, complex diversion or RQe 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=D), as indicated below.
`For timing, see 6.2.1.3.
`
`If
`
`the unit has sent an extended addressing non-emergency request,
`or has received ACKE or AHY(E=l)
`for an extended addressing RQE
`IDENTl matches IDENTl
`from the request
`DESC
`is appropriate to IDENTl
`(see 5.5.3.2.8)
`SLOTS
`corresponds to the request
`(i.e.
`if IDENT1=PSTNGI and FLAG1=1 then SLOTS=·lO' else SLOTS='Ol')
`
`and
`and
`and
`
`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, FLAG2=1)
`IDENTl is set to DIVERTI
`DESC
`is set to '000'
`SLOTS
`is set to '01'
`
`and
`and
`and
`
`then it shall transmit the "blocked address", conforming to the interprefix
`codeword format defined in section 5.6.1.2.2 (SAMIS, Mode 1, OESC=·OOO·).
`
`•
`
`•••••
`•••••
`
`•• •• ••
`
`•
`• then it shall transmit the full address information for IDENT1, conforming
`••
`••
`
`otherwise
`If
`
`the unit has sent an RQC message
`IDENTl is set to SOMI
`DESC
`is set to '000'
`SLOTS matches SLOTS from the RQC
`
`and
`and
`and
`
`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 9-17
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 157 of 294
`
`

`
`9.2.2.2 Availability check on called radio unit
`
`If a radio unit on a control channel receives an AHY message with
`PFIX/IDENTI matching its individual address and bit POINT set to '0'
`then
`it shall respond with the appropriate acknowledgement
`(see below), with the
`If bit AD = 0 in the AHY message,
`same prefix and idents as the AHY.
`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, Bee 6.2.1.3.
`
`A)
`
`(1 to 8100),
`Incoming traffic channel call: IDENT2 = Ident
`Ident
`(8121 to 81801,
`INCI,
`IPFIXI, PSTNGI or PABXI
`
`If bit AD = 1 in the AHY message but the appended data codeword was
`not decodeable and the unit requires the calling address for its
`then it may request a retransmission by sending
`operation,
`ACKB(QUAL=l):
`
`ACKB (QUAL=l)
`
`The unit requires the message to be retransmitted.
`
`Otherwise
`
`The unit may reject the incoming call by sending ACKX(QUAL=O)
`or ACKV(QUAL=l):
`
`ACKX (QUAL=O)
`
`ACKV (QUAL=l)
`
`Otherwise
`
`The unit cannot accept the call
`e.g. 0 = 0 in the AHY message and the unit
`has no speech equipment, or
`o = 1 in the AHY 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 0 = 0 in the AHY 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=O):
`
`then the unit shall
`
`ACK
`
`(QUAL=O)
`
`Unit is available for the call.
`
`then the unit shall send
`ii) If bit CHECK = 1 in the AHY 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=O)
`
`ACK
`
`(QUAL~O)
`
`Unit alerting but user/ data equipment not ready
`e.g. 0 = 0 in the AHY message and the
`unit's RFCC is not currently active, or
`o = 1 in the AHY message and the
`unit's data equipment is not ready.
`User/ data equipment is available for the call.
`
`Page 9-18
`
`•••••
`•
`•••
`•
`•••
`••••••
`••••
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 158 of 294
`
`

`
`•••••
`••••
`••••
`••
`••
`••••••
`
`The unit may indicate the caller (by reference to PFIX/IDENT2 from the AHY
`message or PFIX2/IDENT2 from the data codeword), and may indicate whether
`the incoming call is an emergency call
`(by reference to bit E from the
`AHY) •
`
`After receiving an AHY message for an incoming traffic channel call
`and responding with ACK(QUAL=O) or ACKI(QUAL=O),
`the unit shall
`ignore
`group call GTC messages as specified in section 9.2.2.5 rule 2 or 3, until
`either:
`
`a.
`
`b.
`
`it receives channel allocation signalling for the incoming call (i.e.
`a GTe message with the same prefix,
`idents and bit 0 as the AHY), or
`it assumes that the call will not take place; see 9.2.2.4.
`
`If a radio unit receives AHY(CHECK=l) alerting it for an incoming call
`and responds with ACKI(QUAL=O), it may attempt to send RQQ(STATUS='OOOOO')
`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
`in
`RQQ(STATUS='1111l') if the user no longer wishes to receive the call;
`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 ARY,
`it shall send the appropriate acknowledgement and
`for
`continue with any "off-hook" or "on-hook" signalling in progress; also,
`ACK(QUAL=O) or ACKI(QUAL=O), it shall restart its timer TA (see 9.2.2.4).
`If the unit receives an AHY 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.
`
`B)
`
`Availability check for short data message :
`
`IDENT2 = SDMI
`
`The unit may reject the short data message by sending ACKX(QUAL=O) or
`ACKV(QUAL=ll. Otherwise it shall send ACK(QUAL=O).
`
`ACKX (QUAL=O l
`
`ACKV (QUAL=l l
`
`ACK
`
`(QUAL=O)
`
`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.
`
`C)
`
`"No-call" test availability check :
`
`IDENT2 = DUMMYI
`
`The unit may indicate that it is not suitably equipped by sending
`ACKX(QUAL=O). Otherwise it shall send ACK(QUAL=O).
`
`ACKX (QUAL=O)
`
`ACK
`
`(QUAL=O)
`
`The unit could not accept a call of this type
`e.g. 0 = 0 in the AHY message and the unit
`has no speech equipment, or
`o = 1 in the AHY message and the unit
`has no data equipment.
`Unit is in radio contact and is Buitably equipped.
`
`Dl
`
`Invalid availability check:
`IDENT2=Ident(8l2l to 81801,
`DUMMYI
`
`IDENT2 I Ident
`(1 to 81001,
`INCl,
`IPFIXI, PSTNGI, PABXI, SDMI or
`
`The unit shall send ACKX(QUAL=O),
`
`to reject the availability check.
`
`Page 9-19
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 159 of 294
`
`

`
`9.2.2.3 Availability check on requesting 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
`If bit AD = 0 in the AHY message,
`same prefix and idents as the AHY.
`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 IDENTl and bit E i.e.
`a.
`IDENTl is the called ident or gateway
`(or REGI for a registration request)
`E is 'I'
`for an emergency call, otherwise '0';
`see section 5.5.3.2.1.
`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.
`
`b.
`
`ACKX (QUAL=O)
`
`The unit is not waiting for signalling for a call
`or transaction appropriate to IDENTl and bit E.
`
`9.2.2.4 Cancelling alert/waiting 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=O), 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 AHY 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
`In case c.,
`applies.
`the unit shall obey the procedures in 9.2.2.2A for
`the new call.
`
`Page 9-20
`
`••
`
`••••••••••
`•••••••
`••••
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 160 of 294
`
`

`
`••••••
`•••••
`••••••••
`
`•
`•••
`
`9.2.2.5 Traffic channel allocation
`
`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/IDENT1 matches any of its designated addresses for this system
`ID ENT1 is the system-wide all-call ident ALLI.
`
`or
`or
`
`If the GTC message is addressed to it, the unit shall use the appropriate
`rule below to decide whether to obey the command:
`
`If the unit is making an emergency (RQE) call and has not received
`ACKE(QUAL=O) 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 AHY(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/IDENTl or PFIX/IDENT2).
`
`Otherwise
`(see 9.2.2.2A),
`If the unit is waiting for an incoming emergency call
`it shall obey the GTC message if and only if it is individually
`addressed by the GTC.
`
`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 IDENTl is set to ALLI.
`
`otherwise
`If 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:
`
`2.
`
`3.
`
`4.
`
`or
`or
`
`it is individually addressed by the GTC message,
`IDENTl is set to ALL!,
`PFIX/IDENTl 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 0 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.
`
`if not waiting for any call or transaction)
`Otherwise (i.e.
`The unit shall obey the GTC message if:
`
`or
`or
`
`it is individually addressed by the GTC message,
`IDENT1 is set to ALLI,
`PFIX/IDENTl is one of the unit's group addresses
`and the user wishes to receive group calls.
`
`Page 9-21
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 161 of 294
`
`

`
`If the unit is required to obey the GTC command,
`following actions:
`
`it shall perform the
`
`a.
`
`It shall tune to the designated forward traffic channel, obeying
`the following timings:
`
`the unit shall be able to receive on the
`IPFIXI,
`If IDENT2 /
`traffic channel within 35 ms after the end of the GTC message.
`
`If LDENT2 = IPFIXI,
`the unit shall be able to receive on the
`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 times lot after receiving
`GTC, to extract the caller's address if the next message is
`a GTC for the calling unit).
`
`b.
`
`c.
`
`d.
`
`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).
`
`then the unit shall unmute
`If bit D from the GTC message is '0',
`If bit D is 'I',
`the unit
`the audio (for speech communication).
`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
`If IDENTl
`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.
`
`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 AHY 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 (or. 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 BCAST, SYSDEF='00010'
`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
`if so,
`items and,
`the maximum interval (in seconds) between the start
`
`Page 9-22
`
`•••••••••••••
`••••
`••••••
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 162 of 294
`
`

`
`•••••••••••••••••••••••
`
`of the item and the first periodic message, and then between
`subsequent periodic messages;
`
`c.
`
`in MAINT
`whether a called unit in a group shall set PFIX!IDENTl
`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, SYSDEF=·OOOlO· message,
`the unit shall:
`
`send Pressel On messages
`send periodic messages with a maximum interval TP
`set PFIX!IDENTl to the group address
`(when it is a called unit in a group).
`
`Page 9-23
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 163 of 294
`
`

`
`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
`(except when exempted by emergency call procedures agreed
`traffic channel
`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
`
`a radio unit shall
`(see 9.2.2.5 and 9.2.3.4),
`During a speech call
`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='OOO') 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='OI0') 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 (MAINT,
`OPER='OOl') 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.
`
`in MAINT messages sent by a radio unit is the unit's individual
`PFIX/IDENTI
`address if it was individually addressed by the GTC message; otherwise
`(i.e.
`for a called unit
`in a group), PFIX/IDENTl shall be set to either the
`unit's individual address or to the group address (PFIX/IDENTl)
`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:
`
`0
`PFIX/IDENTl matching its individual address and POINT
`PFIX/IDENT2 matching its individual address and POINT = 1
`
`or
`
`(see below),
`then it shall respond with the appropriate acknowledgement
`with the same prefix and idents as the AHY.
`If bit AD = 0 in the AHY
`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 9-24
`
`•••
`•••
`••
`•••••
`•••
`•••••
`
`•
`
`•
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 164 of 294
`
`

`
`a.
`
`If POINT = 0,
`
`the unit shall send ACK(QUAL=O).
`
`ACK (QUAL=O)
`
`The unit is in radio contact.
`
`b.
`
`If POINT = I,
`
`the unit shall send ACK(QUAL=O) or ACKX(QUAL=O):
`
`ACK
`
`(QUAL=O)
`
`ACKX (QUAL=O)
`
`The unit is waiting for signalling for an Include
`call appropriate to IDENT1 (i.e.
`IDENT1 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 IDENT1.
`
`9.2.3.3 Disabling user transmission
`
`If a radio unit on a traffic channel receives a call maintenance
`message MAINT, OPER='lll' with channel number
`(CHAN) equal to the number of
`the traffic channel and an applicable address,
`then it shall inhibit user
`transmission while it is tuned to this traffic channel (i.e. it shall
`disable the presgel for a speech call or inhibit user data for a data
`call) •
`
`The address (PFIX/IDENTl)
`
`from the MAINT message is applicable if:
`
`a.
`b.
`
`c.
`
`PFIX/IDENTl matches the unit's individual address, or
`PFIX/IDENT1 is equal to PFIX/IDENTl
`from the GTC message and the unit
`is not the calling party, or
`IDENT1 is equal to ALLI.
`
`9.2.3.4 Replacement of traffic channel
`
`If a radio unit on a traffic channel receives a GTC message with:
`
`PFIX/IDENT2 from the GTC message matching its individual address
`PFIX/IDENT1 matching any of its designated addresses for this system
`IDENT1 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.
`
`then the unit shall unmute
`ii) If bit 0 from the GTC message is '0',
`If bit D is '1',
`the unit
`the audio (for speech communication).
`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).
`
`Hi)
`
`If IDENT1 from the
`GTC message is not
`user transmission.
`(See also 11.2.7c.)
`
`GTC message is ALLI and PFIX/IDENT2 from the
`inhibit
`its individual address,
`then the unit shall
`Otherwise it shall enable user transmission.
`
`When the unit has tuned to the designated traffic channel, it may continue
`communication.
`
`IDENTl 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).
`
`Page 9-25
`
`•
`••
`
`••• •••• •
`
`•
`
`•••• ••••
`
`•••
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 165 of 294
`
`

`
`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
`indicates that a data call has ended) while it is tuned to the
`equipment
`traffic channel, and if its individual address is either PFIX/IDENTl or
`PFIX/IDENT2 from the GTC message,
`then the unit shall send a number of
`Disconnect messages (MAINT, OPER='Oll') on the traffic channel.
`It shall
`send NOl Disconnect messages if its individual address is PFIX/IOENTl
`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 ie 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.
`
`for a
`If the unit detects no activity on the forward traffic channel
`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)
`
`send NPON Pressel Off messages (for a speech item);
`send NOl or N02 Disconnect messages if its individual address is
`PFIX/IDENT1 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: MAINT with OPER-' 110'
`
`If a radio unit on a traffic channel receives a call maintenance
`message MAINT, OPER='ll0' with:
`
`channel number (CHAN) equal to the number of the traffic channel
`PFIX/IDENT1 not equal
`to PFIX/IDENT1 from the GTC message
`PFIX/IDENT1 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 9-26
`
`•••••••••••••••••••••••
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 166 of 294
`
`

`
`•••••••••••••••••••••••
`
`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 '101010101010'
`
`and
`
`then it shall Lmmediately 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 '0000000000',
`then the channel movement is system-dependent.
`
`Page 9-27
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 167 of 294
`
`

`
`•••••••••••••••••••••••
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 168 of 294
`
`

`
`•••
`
`••••••••••••••••••••
`
`10.
`
`EKBRGBNCY CALL PROCBDURES
`
`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 RQE (see 5.5.3.1.5). Bit 0 in the RQE message specifies
`whether the unit is requesting speeCh or data communication.
`An extended
`addressing request is indicated by setting IDENTI
`in the RQE 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 AHY(E=I) are responses unique to RQE calls; they
`indicate positively that the TSC has received the RQE and that any further
`signalling sent to the unit is for the emergency call. Until it receives
`ACKE(QUAL=O) or AHY(E=I),
`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.
`
`in the RQE message (i.e. if the RQE is not
`If bit EXT is set to '0'
`for a short addressing PABX call) then FLAG2 may be set to 'I'
`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 IDENTI, 0 and FLAG1 in the RQE message may be
`redefined. For example, EXT=0/FLAG2=1 could indicate that field IDENTI
`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 10-1
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 169 of 294
`
`

`
`••
`••
`••
`
`• •••
`
`•
`
`10.1
`
`Standard Emergency 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
`stand.lrd 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=0/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=O), where both ACKE and ACKX contain the same
`PFIX,
`IDENT1 and IDENT2 as the RQE message.
`
`10.1.1 Responses to a short addressing standard emergency request
`
`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=O); see 5.5.2.1 and 10.2.2.
`
`An availability check for the call
`see 9.1.1.5, 9.1.1.7 and 10.2.2.
`
`(AHY with bit E set to 'I');
`
`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 10.1.6.)
`
`is sent only as a response to an RQE message; it is an
`ACKE(QUAL=O)
`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 request
`
`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=O) 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 inforlo a
`called radio unit that the call will not
`take place).
`
`••••
`•••
`•••
`Page 10-2 ••
`
`ARRIS GROUP, INC.
`IPR2015-00635, p. 170 of 294
`
`

`
`••••••••••••••
`•••••••••
`
`10.1.4 Obtaining extended address information
`
`After receiving an extended addressing RQE message and responding with
`ACKE(QUAL=O),
`the TSC may demand the full called address information from
`the calling radio unit by sending the AHYC message (as in section 9.1.1.3),
`
`10.1.5 Acknowledgements sent to indicate progress o

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket