throbber
11.9.1.l.2
`
`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

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