`
`Res
`
`nses to
`
`Extend Addressin R SMe
`
`e,
`
`Informative.
`
`11.9. 1.1.3
`
`Instructions to Send Extended Address Information
`
`Informative.
`
`I1.9.1.l.4
`
`Agkngwledgemgnts Sent to 3 Calling Unit to Indigte Progress of Q fiimple
`£3_a.ll
`
`Informative.
`
`11.9.1.1.5
`
`Availability Check on Called Radio Unit
`
`Informative.
`
`11.9.l.l.6
`
`Availability Qhgk for Calls to PABX Extensions and PSTN Destinations
`
`Informative.
`
`11.9.1.l.7
`
`Availability Qheck on Requesting Radio Unit
`
`Informative.
`
`I1.9.1.1.8
`
`C 1
`
`ll
`
`ti n
`
`Informative.
`
`11.9. 1.1.9
`
`Call Amalgamation
`
`Informative.
`
`11.9. 1.1.10 Queue Management and Queue Time-out
`
`Informative.
`
`11.9.1.1.1l Resolving gall Conflicts
`
`Informative.
`
`11.9.1.1.I2
`
`Tr_a_ff1c Channgl Allocation
`
`Informative.
`
`11.9.1.2
`
`Bgsig TSC Prgggures for Mgintengce and Clg;-Down of Calls
`
`Informative.
`
`ll-24
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 160
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 160
`
`
`
`
`
`11.9.l.2.l
`
`IM'
`
`11
`
`'n
`
`Informative.
`
`11.9. I .2.2
`
`Informative.
`
`Avfllability Qhgk Qn Traffic Channel
`
`11.9. 1 .2.3
`
`Digbling Llser Transmission
`
`Informative.
`
`1l.9.1.2.4
`
`Allfitjgg Rgplaggmgnt Tgffic Chgngl
`
`Informative.
`
`ll.9.1.2.5
`
`I
`
`'n D wn
`
`nw
`
`Radio Unit Durin a
`
`11
`
`Informative.
`
`11.9. 1.2.6
`
`Call Cleardown
`
`Informative.
`
`11.9.2
`
`Basic Call Procedure; fgr Radio units
`
`Mandatory where specified.
`
`It is a mandatory for the radio unit to be fitted with a "ready for communication control“
`(RFCC).
`
`
`
`11.9.2.1
`
`Prgggures for Radio units Making Simple Calls
`
`Mandatory where specified.
`
`It is a standard option for a radio unit to make calls to a PABX or PSTN destination.
`
`ll.9.2.1.1
`
`Rmggst for a Simple gall
`
`Mandatory as specified.
`
`It shall be mandatory for the radio unit to be able to make simple calls to common prefix and
`interprefix destinations.
`
`It is a standard option for a radio unit to make data calls.
`
`l1.9.2.1.2
`
`idRs n
`
`t
`
`h
`
`A resinR
`
`ll-25
`
`
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 161
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 161
`
`
`
`Mandatory as specified.
`
`l1.9.2.1.3
`
`Valid Res
`
`n
`
`to Extended Addressin R S
`
`Mandatory as specified.
`
`1 l .9.2. 1.4
`
`Acknowledgement Received
`
`Mandatory as specified.
`
`Requirements for confidence indications are given in section 8.1. The radio unit shall make
`an indication to the user following receipt of ACKB (QUAL=‘0’).
`
`The facility to cancel a call accepted for call back by use of an RQQ message
`(STATUS = ’l1l11') is a standard option.
`
`Diversion requests (RQT) and use of diversion information are a standard option. Automatic
`re-dial to the diversion IDENT is optional.
`
`11.9.2.I.5
`
`Availability Check and Channel Allocation for Own Cali
`
`Mandatory as specified.
`
`l1.9.2.1.6
`
`Time-out after Waiting
`
`Mandatory as specified.
`section 8.1.
`
`The requirements for confidence indications are given in
`
`11.9.2. 1 .7
`
`Call Cancellation
`
`It shall be possible for the user to cancel
`Mandatory.
`confidence indications are given in section 8.1.
`
`the call. The requirements for
`
`11.9.2.2
`
`Qgig figures for All ggdig units on a Control Channel
`
`Informative.
`
`1l.9.2.2.l
`
`Instruction
`
`end A 1'
`
`Information or D Messa e
`
`Mandatory for the following function:
`
`Interprefix calls.
`
`Standard option for the other transaction types listed.
`
`1l.9.2.2.2
`
`Availability Check on Qalled Radio unit
`
`Mandatory where specified.
`
`It is optional whether the radio unit indicates the
`
`of the
`
`11-26
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 162
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 162
`
`
`
`
`
`caller to the user.
`emergency call.
`
`It is optional whether the radio unit makes a distinct indication for an
`
`lf, while waiting for an incoming traffic channel call, a radio unit receives a repeat AHY,
`and the user has already activated the RFCC, the unit shall not re-alert the user.
`
`.
`
`in the event of an incoming traffic channel call (IDENT2 = Ident( 1-8100), INCI, IPFIXI,
`PSTNGI or
`PABXI)
`the
`unit
`shall
`respond with one of ACK(QUAL='0‘),
`ACKI(QUAL='0'), ACKB(QUAL='0‘). ACKB(QUAL=‘1'), ACKV(QUAL=’1') or
`ACKX(QUAL='0') in accordance with MP1‘ 1327.
`In addition. the radio unit shall only
`respond with ACKX(QUAL='0') if one of the following conditions is met:
`
`i.
`
`ii.
`
`Bit D of the received AHY message is '0' and the unit is not accepting speech calls.
`
`Bit D of the received Al-IY message is 'l’ and the unit is not accepting or not ready
`for data calls (see section 12).
`
`The radio unit shall not accept a call for call back (using ACI(B(QUAL=‘O‘)) unless it has
`facilities for making the return call.
`
`It is mandatory for the radio unit to send RQQ off-hook/on-hook signalling.
`As a standard option, the radio unit may respond to AHY, bit CHECK=‘1‘, with ACK
`(QUAL—‘0’). This option shall only be "enabled" by network personalisation and the default
`‘ state shall be "disabled".
`
`ll.9.2.2.3
`
`Availability gghgk QII Rgiuesting l_l_adiQ [Jnit
`
`Mandatory as specified.
`
`ll.9.2.2.4
`
`ggancelling Alert §tat§ of Qalled Unit
`
`*—~5'-—=-"='r=.
`
`Mandatory where specified.
`
`The requirements for confidence indications are given in section 3.].
`
`11.9.2.2.5
`
`Tgaffic ghannel Allmatign
`
`Mandatory as specified. User indication of calling IDENT is optional. For definition of the
`retuning time limits, see ll.6.2.l.3.
`
`lI.9.2.2.6
`
`orin CallM 'ntenan
`
`P
`
`rs
`
`Mandatory
`
`specified.
`
`It is an option for radio units to store the value of TSCLIM from the last decodable BCAST,
`SYSDEF=’000l0’ message received in read/write memory (see ll.5.5.4.5 c).
`
`ll-27
`
`
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 163
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 163
`
`
`
`11.9.2.3
`
`Pr
`
`u sfr lRadio
`
`nitson
`
`All
`
`T ffi
`
`h nl
`
`Mandatory as specified.
`
`11.9.2.3.l
`
`Call Maintenance Messages
`
`For values of NPON=l and NPOFF=1 : mandatory as specified.
`
`For values of NPON> 1 or NPOFF> 1 : standard option.
`
`11.9.2.3-2
`
`Availa ili Check on Traffic
`
`hannel
`
`Mandatory as specified.
`
`1l.9.2.3.3
`
`Digbling User Transmission
`
`See also 11.5.5.4.2.
`
`If the radio unit on a traffic channel receives a MAINT (OPER = '1 1 1‘) message with the
`STI flag equal to zero then:
`
`i.
`
`ii.
`
`the SIL3 field = RSVD and has no meaning;
`
`the radio unit shall understand and take any mandatory action required.
`
`If the radio unit on a traffic channel receives a MAINT (OPER ='1ll‘) message with the
`
`STI flag NOT equal to zero, then:
`
`i.
`
`the user transmission shall only be inhibited if the SIL3 field matches the three least
`significant bits of the verified SIL code.
`
`1l.9.2.3.4
`
`Re lacement
`
`fTraffic
`
`h
`
`nel
`
`Mandatory where specified.
`
`For definition of the retuning time limits, see l1.6.2.l.3.
`
`The radio unit shall meet the requirements of any prearrangement made as regards the
`sending of periodic messages during data calls (refer to section 6).
`
`1I.9.2.3.5
`
`in
`
`" n-h
`
`k"
`
`n T ffi
`
`ham 1
`
`Mandatory as specified.
`
`ll.9.2.3.6
`
`Time-Qgts on Traffic Channel
`
`For values of NPON=1 and NPOFF=1: mandatory where specified.
`
`11-28
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 164
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 164
`
`
`
`
`
`For values of NPON>l or NT-‘0FF> 1: standard option.
`
`The requirements for confidence indications are given in section 8.1.
`
`The definition of inactivity that shall be used in this section of MPT 1327 is that a radio unit
`is considered inactive on a traffic channel when it is not transmitting and the received audio
`is muted because the receiver quieting is insufficient.
`
`It is an option for radio units to incorporate a maximum call duration timer. This timer shall
`be initialised immediately that the radio unit has tuned to a designated forward traffic channel
`following receipt of a GTC message in accordance with !!9.2.2.5!! (unless inhibited by the
`latest received value of TSCLIM, see below). The timer shall remain in operation for as long
`as the radio unit remains tuned to either the forward or return channel of the designated
`traffic channel or any other traffic channel
`to which the radio unit may be directed by
`subsequent GTC messages in accordance with !l9.2.3.4!! but shall be cancelled when the
`radio unit tunes to a control channel in accordance with !!9.2.3.5!!, !l9.2.3.6ll. !!9.2.3.7!!
`or !!9.2.3.8!l.
`
`Upon expiry of the maximum call duration timer the radio unit shall:
`
`i)
`
`ii)
`
`Mute the audio.
`
`If the radio unit is transmitting it shall send one or more Pressel Off messages to
`indicate the end of the item in accordance with !!9.2_3.l!!.
`
`
`
`iii)
`
`Send NDI or ND2 Disconnect messages if its individual address is PFIX/IDENTI
`or PFIX/IDENT2 from the GTC (as in section !!9.2.3.5!!).
`
`iv)
`
`Cease transmission on the traffic channel, indicate the end of the call to the user in
`accordance with 8.1.3.8 and enter the control channel acquisition procedures (see
`section 9).
`
`The radio unit may also use the call duration timer to indicate to the user that the above
`action is imminent, at some time prior to the action being carried out.
`
`The call duration timer shall expire after a period as determined below:
`
`-
`
`—
`
`-
`
`a BCAST
`until
`and
`channel
`new control
`a
`acquiring
`Upon
`(SYSDEF=‘00010‘) message has been received, the period shall be CLIM.
`
`least one decodable BCAST (SYSDEF=’0O0l0‘) message has been
`If at
`received by the radio unit since the start of the session or since acquiring a
`new control channel, the period shall be as indicated by the value of TSCLIM
`received in the last decodable BCAST (SYSDEF='000l0') message (see
`ll.5.5.4.5c) unless that value of TSCLIM is '00000000‘ when the period shall
`be CLIM or is 'lI11llll' when the maximum call duration timer shall be
`inhibited.
`
`11-29
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 165
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 165
`
`
`
`—
`
`If the radio unit has tuned to the traffic channel as a result of receiving a GTC
`message whilst waiting for signalling for an emergency call following the
`receipt of an AHY message with bit 13 set to '1‘ or following the transmission
`of RQE, the period shall be CLIME.
`
`11.9.2.3.7
`
`"Selective" ClearrDown Messa e: MAINT with OPER=‘1l
`
`‘
`
`See also 11.5.5.4.2.
`
`The requirements for confidence indications are given in section 8.1.
`
`If a radio unit on a traffic channel receives a MAINT (OPER =’1l0') with the STI flag
`equal to zero then:
`
`i.
`
`the SIL3 field = RSVD and has no meaning;
`
`ii.
`
`the radio unit shall understand and take any mandatory action required.
`
`If the radio unit on a traffic channel receives a MAINT (OPER =’1ll’) message with the
`STI flag NOT equal to zero. then:
`
`i.
`
`the radio unit shall clear down only if the SIL3 field matches the three least
`significant bits of the verified SIL code.
`
`l1.9.2.3.8
`
`CLEAR Message
`
`If a radio unit on a traffic channel receives a clear-down message CLEAR with the STI flag
`equal to zero
`
`and
`
`i.
`
`channel number (CHAN) equal to the number of the traffic channel
`
`and
`
`ii.
`
`field REVS equal to 'l0101010l010',
`
`then it shall immediately mute the audio and move to the forward control channel
`indicated by the 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.
`
`If a radio unit on a traffic channel receives a clear-down message CLEAR with the STI flag
`NOT equal to zero
`
`and
`
`11-30
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 166
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 166
`
`
`
`channel number (CHAN) equal to the number of the traffic channel
`
`and
`
`field REVS equal to ‘10lOl0l010l0’
`
`and
`
`iii.
`
`the SIL3 field matches the three least significant bits of the verified SIL sub-field,
`
`then it shall immediately mute the audio and move to the forward control channel indicated
`by the 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.
`
`If the field CONT is set to ’O0OO00OO0O’ then the radio unit shall either return to the last
`
`active control channel , or remain on the nominated fall-back channel if in fall-back mode.
`
`The requirements for confidence indications are given in section 8.1.
`
`11.10
`
`Emergency Call Procedures
`
`Standard option.
`
`Other modes of customised emergency service are not precluded.
`
`I1.10.l
`
`Standard Emergency Call Procedures for TSC
`
`Entire subsection: informative.
`
`l1.10.2
`
`Standard Emergency Call Procedures for Radio Units
`
`Entire subsection: standard option.
`
`Standard emergency call procedures on a traffic channel are defined in MP1" 1327
`section 9.2.3.
`
`11.11
`
`Incl de Call Pr
`
`ures
`
`Standard option.
`
`ll.11.1
`
`TSC Procedures for Include Calls
`
`Entire subsection: informative.
`
`11.11.32
`
`Pr
`
`r s for Radio
`
`nits R uestin In lud
`
`Entire subsection: standard option.
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 167
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 167
`
`
`
`11.l1.3
`
`Prgpgurgs for All Radio Unig on an Allgitfi Traffic Channel
`
`11. 1 1.3.1
`
`Instruction to Send Extended Address Information
`
`Standard option.
`
`11.12
`
`Call Diversion Procedures
`
`Standard option.
`
`l1.12.l
`
`T§C Prggedures for gall Diversion Rgguests
`
`Entire subsection: informative.
`
`1l.l2.2
`
`Pr
`
`ures for Ra io
`
`nits R
`
`ti
`
`all Div rsion
`
`Entire subsection: standard option.
`
`11.13
`
`Status Message Procedures
`
`_
`
`'
`
`Entire section: procedures involving RFCC signalling are mandatory.
`It is mandatory that the radio unit is able to recognise and respond to the AI-IYQ message
`(refer to MP1‘ 1327 section 13.2.3).
`Otherwise: standard option.
`
`11.14
`
`Short Data Mesgge Procedures
`
`Entire section: standard option.
`
`1 I .15
`
`Data Interrogation Procedures
`
`Informative.
`
`11.15.1
`
`Data Interrogation Procedures for TSQ
`
`11.15 . 1.1
`
`Datalnterrogation on a Control Channel
`
`.
`
`Informative.
`
`ll.15.1.2
`
`Dag Interrogation QB a Tmffig Channel
`
`Informative.
`
`ll.l5.2
`
`Primes for All Radio units
`
`It is a mandatory requirement that radio units shall recognise Mode 2 AHYC messages and
`respond with the serial number transmission as specified below.
`
`11-32
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 168
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 168
`
`
`
`ll.15.2.l
`
`D
`
`Interr
`
`ati M
`
`Y M
`
`2 na
`
`n
`
`l
`
`h nl
`
`The radio unit shall be equipped to transmit its serial number on interrogation using the
`SAMIS message. The form of the serial number transmitted is defined in section 7.
`
`l 1.15.2.2
`
`Data Interrogation Message (AHYC. Mode 2) on an Allocated Traffic Channel
`
`‘
`
`The radio unit shall be equipped to transmit its serial number on interrogation using the
`SAMIS message. The form of the serial number transmitted is defined in section 7.
`
`ll.l6
`
`This paragraph is not used.
`
`I l .17
`
`Standard Data Procedures
`
`Entire section: standard option.
`
`l
`
`ll-33
`
`
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 169
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 169
`
`
`
`
`
`12.
`
`NON STANDARD DATA INTERFACE PROVISION
`
`The provision of a non standard data facility on a radio unit is a standard option.
`
`Within the procedures RQS and RQE with DT=l. provision may be made for connection
`of external data equipment to radio units for transmission over transparent signalling paths.
`The quality of the paths will be determined by individual networks.
`
`12.1
`
`Mgting
`
`The equipment shall be constructed so that the data path shall never be disturbed by the
`squelch for speech reception. Receiver audio shall be muted during data reception.
`
`12.2
`
`Maladjustmgnt
`
`increase the interference potential of the
`Those controls which if maladjusted might
`transceiver shall not be easily accessible to the user.
`
`12.3
`
`Standard Signalling
`
`Whilst in a data call and receiving signals from the TSC the Radio unit shall monitor the
`channel continuously for messages from the TSC and shall take appropriate action.
`
`The radio unit shall not send call maintenance messages except disconnect messages.
`
`12.4
`
`Da
`
`1 Han lin
`
`incorporate a Data Call Duration Timer TU, and an associated
`The radio unit shall
`suppression flag as part of its network personalisation.
`
`
`
`12.4. 1
`
`Call Establishment
`
`Calls are established by the unit receiving a GTC (D=l). Timer TU shall be started upon
`first tuning to the traffic channel.
`
`12.4.2
`
`gall Cleaflce
`
`The radio unit shall send disconnect messages as specified in MPT 1327 section 9.2.3.5,
`
`either:
`
`on expiry of the Data Call Duration Timer,
`
`or:
`
`at end of the data transaction when detected by the radio unit (whereupon TU is de-
`activated), whichever is earlier.
`
`
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 170
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 170
`
`
`
`12.5
`
`Facilities
`
`Equipment that does not integrate the keyboard and display or other means of data entry or
`retrieval into the transceiver shall provide a suitable interface covering at least:
`
`RX Audio
`
`TX Audio
`
`Keyline
`
`—
`
`-
`
`-
`
`shall not be affected by the radio unit volume control setting
`
`at levels that shall not affect the overall deviation requirements.
`
`form unspecified; the keyline shall be inhibited until at least TR has
`elapsed from the receipt of GTC (D= 1) or on completion of a
`standard data transaction on the traffic channel which starts within TR
`and over-runs TR.
`
`In addition the following faculties may be made available:
`
`Data Channel
`
`Ready
`
`Data Equipment
`Available
`
`NOTE
`
`This signal is generated by the RU shall become active after a period
`of at least TR has elapsed from the receipt of GTC (D=1) or on
`completion of a standard data transaction on the traffic channel which
`starts within TR and over-runs TR. This signal does not guarantee
`that an end to end communication path has been established.
`
`This signal is generated by the external data equipment and shall only
`be active when the data equipment is ready to receive or transmit data.
`This signal enables the RU to provide the appropriate control channel
`signalling for call set-up and rejection for RQS (DT=1), data calls.
`AHY (D=1) or GTC (D= 1).
`If during a data call
`the Data
`Equipment Available signal
`is de-activated,
`this shall initiate a call
`clear down.
`
`It is recommended that manufacturers of external data equipment should list those Radio
`Units for which the equipment combination complies with MPT 1323.
`
`12-2
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 171
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 171
`
`
`
`
`
`13.
`
`13. 1
`
`FALL—BACK MODE
`
`lntrguctign
`
`The fall—back mode enables a reduced service to be offered to radio units when there has
`been a partial equipment failure in the network, for example if the network loses the ability
`to trunk channels.
`Implementation of the fall-back mode is a standard option for radio units,
`and also for systems.
`
`.
`
`The general method of fall-back operation is as follows. Each radio unit will relapse to a
`pre-programmed channel
`(all members of a fleet would be programmed with the same
`channel number). The network may operate each of these channels independently, as a set
`of single channel systems; each channel will alternate between being a control channel (using
`the Aloha protocol to control random access) and a traffic channel.
`
`This section defines the additional requirements for radio units which implement the fall-back
`option. Radio units which implement
`the fall—back option shall also conform to the
`requirements of all other sections of this specification, except where stated otherwise in this
`section. The requirements for radio units which do not implement the fall-back option are
`covered in sections 9 and 11 of this specification.
`
`13.2
`
`Storage Requirement;
`
`The radio unit shall be programmable with the following parameters appropriate to the
`selected network. The parameters shall be stored in read-only memory.
`
`The number of the channel on which the radio unit will receive the fall—back
`a)
`service.
`
`the radio unit shall be inhibited from
`If programmed with channel number zero,
`operating the fall-back mode.
`In this case the radio unit shall conform to the
`requirements for a radio unit which is not equipped for fall-back operation.
`
`The system identity code conveyed on the channel on which the radio unit will
`b)
`receive the fall-back service. Only the NDD field (section 9.3.4.22) needs to be
`programmable explicitly; the other fields in the fall-back system identity code may
`be assumed to match the system identity code personalisation data for the normal
`operation mode.
`
`The specification is written for a radio unit which is equipped to operate on only one fall-
`back channel. Operation on more than one fall—baclt channel, for example different channels
`in separate parts of a network,
`is not prohibited. but is not explicitly supported by this
`specification.
`
`13.3
`
`finflng Fallfiack Mgie
`
`The radio unit shall enter the fall-back mode if, while active on a control channel and in the
`normal operation mode,
`it receives an applicable ALI-IF message (see section 7.3.1 of
`
`13-1
`
`
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 172
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 172
`
`
`
`MPT 1327) containing a correct CHAN4. The radio unit shall abandon any call set-up or
`transaction in progress. The radio unit shall then attempt to find and confirm an alternative
`control channel which is in the normal operation mode, commencing with the preferential
`hunt sequence. An additional requirement for confirming that a control channel is in the
`normal operation mode is the receipt of a nomial operation mode Aloha message (i.e. ALH,
`ALI-IS, ALHD, ALHE, ALI-[R or ALHX).
`'
`
`If the radio unit fails to find and confirm :1 normal operation mode control channel (all
`prescribed hunt stages shall be completed),
`it shall tune to its pre-programmed fall—back
`channel. and attempt to confirm the fall-back channel. The condition for becoming active
`and confirming the fall-back channel is the receipt of a CCSC containing the radio unit's pre-
`prograrnmed fall-back system identity code (the confirmation conditions specified in
`section 9.3.4 are not applicable).
`
`Until the radio unit has confirmed the fall-back channel, it shall not transmit on that channel
`or obey any messages received. After the radio unit has confirmed the fall-back channel it
`shall conform to the faI1~back procedures defined in section 13.4.
`
`Upon entering the fal1—back mode the radio unit shall maintain existing registration records
`and continue to operate the registration timers.
`
`13.4
`
`Procfiures in Fall-Back Mge
`
`The requirements in this section augment, and in some cases modify, the requirements of
`other sections of this specification which apply to normal operation mode.
`
`13.4.1
`
`Call Procedures
`
`ALHF invites the following types of call request: RQS, RQX, RQT, RQE,
`a)
`RQQ and RQC.
`
`The radio unit shall not attempt to register by random access, and shall not
`b)
`make use of control channel messages to implicitly register; the radio unit is free to
`initiate and receive calls even if the unit does not hold a registration record for the
`verified AREA code of the fall-back system identity code.
`
`c)
`
`The radio unit shall not initiate calls to a PABX or PSTN.
`
`The timeout TC shall have a value TX (see,
`d)
`section 8.1.3.5. and in !!7.3.8!!).
`
`for example, TC ifi
`
`13.4.2
`
`Channel Digipline
`
`v The radio unit shall not apply the error checking criterion specified in
`a)
`section 9.4.1 item a) for leaving the fall—baclc control channel.
`
`When the radio unit hunts according to the criteria specified in sections 9.4.1
`b)
`and 9.4.2, if it fails to find and confirm a normal operation mode control channel (all
`
`13-2
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 173
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 173
`
`
`
`
`
`prescribed hunt stages shall be completed), it shall re-tune to its fall—back channel and
`attempt to confirm the fall-back channel.
`
`The unit shall suspend activity if a system identity code different from its fall-
`c)
`back system identity code is received on its fall-back channel. as specified in section
`6.2.1.2 of MPT 1327. See also section 9.4.l item b).
`
`.
`
`The time out TS shall have a value TF while the radio unit is operating on the
`d)
`fall—back channel during the fall-back mode.
`
`e)
`traffic.
`
`As normal, the radio unit shall mute the received audio while not assigned for
`
`If a GTC message which allocates the fall-back channel for traffic is received
`f)
`on the fall-back channel,
`then if the radio unit is not required to obey the GTC
`message it shall remain tuned to the fall-back channel.
`
`The condition for becoming active and confirming the fall-back channel is the
`g)
`receipt of a CCSC containing the radio unit's pre-programmed fall-back system
`identify code (the confirmation conditions specified in section 9.3.4 are not
`applicable).
`
`13.5
`
`Leaving Fall-Back Mode
`
`Under any of the following conditions the radio unit shall exit from fall-back mode, abandon
`any call set-up or transaction in progress, and enter the control channel acquisition
`procedures:
`
`An applicable MOVE message is received (the radio unit shall ignore any
`(a)
`MOVE message that is not applicable to it).
`
`A CLEAR message (with correct CHAN field) is received in which CONT is
`(b)
`not set to zero or to the radio unit‘s fall-back channel. The radio unit shall perform
`a single channel hunt (if CONT=0, or is set to the radio unit's fall-back channel, the
`radio unit shall remain in the fall-back mode on the fall-back channel).
`
`A nonnal operation mode Aloha message (ie ALH, ALHS, ALHD, ALHE,
`(c)
`ALHR or ALHX) is received while active on any channel. The radio unit shall
`perform the final checks according to the requirements of section 9.3.4.4 before
`leaving the fall-back mode,
`ie normal operation of the channel shall be confirmed
`before leaving the fall—back mode.
`
`(d)
`
`A user-initiated change of selected network. See also section 13.6.
`
`When the network terminates the fall—back service. the radio unit may receive on the fall-
`back channel either a MOVE command (if another channel becomes the normal operation
`mode control channel), or a CLEAR message (as specified above), or a normal operation
`mode Aloha message.
`
`13-3
`
`
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 174
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 174
`
`
`
`However, in case the radio unit does not receive the signalling which terminates the fall-back
`mode on the fall-back channel, and to provide an opportunity to exit from the fa11—back mode
`if the fall-back channel quality degrades, the hunting requirement specified in section 9.4.1
`c) provides an alternative route for returning to normal operation mode.
`
`While in the fall-back mode on the fall-back channel, the radio unit may come within range
`of a normal operation mode control channel on which it could obtain a better service.
`Therefore, it is recommended that, when not in traffic or waiting for signalling, the radio
`unit hunts occasionally for a normal operation mode control channel, regardless of the quality
`of the channel and whether or not the radio unit is active.
`
`While in the fall-back mode and examining channels other than the fall-back channel, the
`radio unit shall operate the normal rules for control channel acquisition (section 9). but
`receipt of a normal operation mode Aloha message is an additional
`requirement
`for
`confirming the control channel. As defined above, receipt of a normal operation mode Aloha
`message shall terminate the fall—back mode, whereas the radio unit shall resume hunting if
`it receives ALI-IF (note that the radio unit shall not dwell indefinitely on a control channel
`while active and waiting for an Aloha message to confirm the channel). Upon leaving the
`fall-back mode the radio unit shall attempt to register if required to by sections 10.2.3 and
`10.2.7 (or 10.3.3 and 10.3.7 if the radio unit supports multiple registration).
`
`13.6
`
`Llgr Initiated Qhange of Network
`
`If the user initiates a change of network while the radio unit is in the fall-back mode, then
`if the network which was operating the fall-back service is re-selected (when fall-back service
`may or may not have terminated in the network) the radio unit shall re—enter the network in
`the fall-back mode as if it had received an applicable ALHF message, as defined in
`section 13.5.
`If the radio unit fails to find and confirm a normal operation mode control
`channel (all prescribed hunt stages shall be completed), it shall tune to its pre-programmed
`fall-back channel, and attempt to confirm the fall-back channel.
`
`
`
`13-4
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 175
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 175
`
`
`
`
`
`
`
`14.
`
`14-1
`
`SHORT DATA ON THE CONTROL CHANNEL USING RQC
`
`lntrsalnclinn
`
`This section describes the air interface requirements necessary to support signalling between
`radio units and TSCs during the transfer of short data messages on the control channel. The
`implementation of the procedures defined in this section is a standard option.
`
`The transfer of short data messages conforms with the basic procedure defined in MPTl327
`section 14. This allows transmission of HEAD messages containing free format data on the
`control channel.
`Implementation of the short data standard option defined in this document
`requires some of these bits to cany control information. The protocol allows the use of only
`MPTl32'7 procedures, or the procedures as described in this section.
`
`A calling radio unit requests to transmit a short data message by sending an RQC random
`access request message addressed to the called unit or service. For extended addressing
`PSTN and PABX calls (and optionally for interprefix calls), the TSC will solicit the full
`called party address infonnation using the MPT 1327 extended addressing procedures at an
`appropriate point in call set-up. The TSC may check the availability of a called radio unit
`using the General Availability Check Message AHY, before requesting the caller to send a
`HEAD message by means of the Short Data Invitation Message AHYC (refer to sections
`!!5.5.3.2.1!! and !!5.5.3.2.8!!). The calling party sends a Short Data Message Header
`HEAD and up to four appended data codewords to the TSC. The TSC then forwards the
`data by re-transmitting the I-[E-LAD message to the called party which is required to respond
`with an acknowledgement in accordance with the procedures outlined in section 14 of
`MPTl327. The TSC sends an acknowledgement to the calling party to advise the receipt of
`the HEAD message (or otherwise) by the called party. Where the called party is a group and
`not an individual address, no acknowledgement by radio units in that group to a HEAD
`message is permitted (see section !!l4.3.l.2!!) and,
`in this case,
`the TSC sends an
`acknowledgement
`to the calling party to advise whether the HEAD message has been
`received by the TSC and transmitted to the group.
`
`Note: The term "HEAD message", where used in this section, shall be talcen to mean
`"HEAD address codeword and appended data codewords" collectively.
`
`The procedures defined in E! 14!! support the transmission of a single segment of free-format
`data. (A "segment" is that amount of free-format data which can be accommodated in a
`single HEAD message; see section 3.1). This specification extends the scope of the above
`referenced procedures to allow up to four segments to be associated with a single request
`(RQC). For convenience a short data transaction for which the T—message (see section 3.1)
`is confined to a single segment is referred to as a Single Segment Transaction (SST) in this
`specification. A short data transaction for which the T-message comprises more than one
`segment is referred to as a Multiple Segment Transaction (MST).
`
`14.1.1
`
` mm
`
`A radio unit requests to transmit short data HEAD messages in accordance with the
`procedures of !!l4!! by sending an RQC message on a control channel. The TSC then
`
`14-]
`
`
`
`
`
`
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 176
`
`Petitioner Cisco Systems - Exhibit 1006 - Page 176
`
`
`
`
`
`In the
`solicits the transmission of a HEAD message using the address codeword AHYC.
`case of a Multiple Segment Transaction, each HEAD message of the transaction is
`individually solicited by the TSC using an AHYC message. The TSC need not support
`Multiple Segment Transactions, in which case this will be indicated in the AI-IYC message.
`In these circumstances a radio unit wishing to send a T-message comprising more than one
`segment is required instead to generate an RQC for each segment treating each as an SST.’
`
`In the case of an MST, the TSC is responsible for requesting each segment from the radio-
`unit and forwarding it to the called party. The TSC either will assemble the complete
`T-message before forwarding it or will forward each segment by means of a HEAD message
`as soon as it has been received correctly.
`
`SSTs and MS'I‘s may be addressed to individual units, to groups or to a TSC gateway.
`
`A simple message repeat error correction protocol is incorporated into this specification. If
`an