MPT 1327
`
`A Signalling Standard
`
`for Trunked Private Land Mobile
`
`Radio Systems
`
`January 1988
`
`Revised and reprinted November 1991
`
`—*Pat‘t‘1-
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 1
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 1
`
`

`
`
`
`MPT 1327
`
`JANUARY 1988
`
`A SIGNALLING STANDARD FOR
`
`TRUNKED PRIVATE LAND MOBILE RADIO SYSTEMS
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 2
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 2
`
`

`
`
`
`(C)
`
`Crown Copyright 1983
`First published January 1988
`Reprinted and revised October 1990
`Reprinted and revised November 1991
`
`Amendments issued since publication
`
`Amendment
`
`Number
`
`| Date of issue
`
`1
`
`October 1990
`
`Text affected
`
`
`
`Incorporated in the version
`reprinted in October 1990.
`Amended text was highlighted
`by a bar in the margin.
`
`
`
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 3
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 3
`
`

`
`FOREWORD
`
`This standard defines the rules for communication between radio units and trunking
`system controllers operating in trunked private land mobile radio systems.
`
`Applications and test conditions for this standard, applicable to Band III, are contained in
`the following specifications prepared by the Department of Trade and Industry,
`Radiocommunications Agency.
`
`MPT 1343
`
`System interface specification for radio equipment to be used with
`commercial trunked networks operating in Band III, sub-bands 1
`and 2.
`
`MPT 1347
`
`Radio interface specification for commercial trunked networks
`operating in Band III, sub-bands 1 and 2.
`
`MPT 1352
`
`Test schedule for the approval of radio units to be used with
`commercial trunked networks operating in Band III, sub-bands 1 and
`2.
`
`Intellectual Promrty Rights
`
`Firms intending to manufacture equipment which complies with the standard should be
`aware that certain features of the standard are subject to IPR claims.
`
`All firms are therefore advised that they should make appropriate enquiries through
`their Patent Agents before proceeding.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 4
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 4
`
`

`
`
`
`1.
`
`INTRODUCTION
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`8.
`
`9.
`
`10.
`
`11.
`
`12.
`
`13.
`
`14.
`
`15.
`
`16.
`
`DEFINITIONS
`
`SIGNALLING FORMATS
`
`ADDRESSING
`
`CODEWORD STRUCTURES
`
`CHANNEL DISCIPLINE
`
`RANDOM ACCESS PROTOCOL
`
`REGISTRATION PROCEDURES
`
`BASIC CALL PROCEDURES
`
`EMERGENCY CALL PROCEDURES
`
`INCLUDE CALL PROCEDURES
`
`CALL DIVERSION PROCEDURES
`
`STATUS MESSAGE PROCEDURES
`
`SHORT DATA MESSAGE PROCEDURES
`
`DATA INTERROGATION PROCEDURES
`
`Section reserved for additional short data procedures
`e.g. Shfls.
`
`17.
`
`STANDARD DATA PROCEDURES
`
`APPENDIX 1.
`
`Suggested values for parameters.
`
`APPENDIX 2.
`
`The error control properties of the codewords.
`
`APPENDIX 3.
`
`An algorithm for determining the codeword completion
`sequence of a control channel system codeword.
`
`APPENDIX 4.
`
`An algorithm for generating fields A and B of
`the MARK codeword.
`
`APPENDIX 5.
`
`BCD Coding.
`
`APPENDIX 6.
`
`Reserved for Timing of responses for standard data at a
`customised rate.
`
`APPENDIX 7.
`
`Other ideas considered during the drafting of section 17
`(standard data).
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 5
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 5
`
`

`
`1 .
`
`IHTKJDUCIIOI
`
`MPT1327 is a signalling standard for trunked private land mobile radio
`systems.
`It defines the protocol rules for communication between a
`trunking ystem controller (TSC) and users’ radio units.
`
`from
`The standard can be used to implement a wide variety of systems,
`small system with only a few radio channels (even single-channel systems),
`through to large networks which may be formed by the interconnection of
`Tscs.
`
`The protocol offers a broad range of user facilities and system
`options. However, it is not necessary to implement all of the facilities
`available; an appropriate subset of the protocol could be implemented,
`according to the user requirements. Also, there is scope for customisation
`for special requirements, and provision has been made for further
`standardised facilities to be added to the protocol in the future.
`
`The standard defines only the over-air signalling and imposes only
`minimum constraints on system design. Additional specifications will be
`required for specific implementations, for example, to define:
`
`the facilities that must be implemented
`-—
`- parameter values
`—
`a channel plan
`-
`for a network, criteria for when a radio unit should register.
`
`Section 1.1 of this introduction describes the user facilities which
`
`(It does not describe additional
`are explicitly provided by the protocol.
`facilities which may be offered in a radio unit but which do not require
`any specific protocol.)
`
`Section 1.2 describes some protocol features,
`available to system designers.
`
`indicating the options
`
`Section 1.3 provides an introduction to the operation of the protocol.
`
`Subsequent sections of this document contain the protocol definition.
`In most of these sections,
`the protocol rules for the TSC and for radio
`units are specified separately, but with cross-referencing where
`convenient.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 6
`
`Page 1-1
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 6
`
`

`
`
`
`1.1
`
`User Facilities
`
`The facilities available to users are outlined below.
`definition of the facilities, see the sections indicated.
`
`For a full
`
`1.1.1 Types of call
`
`The standard protocol enables radio units to make the following types
`of call.
`
`6..
`
`Speech call.
`
`(See section 9.)
`
`For group
`speech calls may be requested with normal or high priority.
`calls, the calling party may opt for a conversational mode, where all
`parties are able to speak, or for an announcement mode where only the
`caller may speak.
`
`Data call, for the transmission of non-prescribed signalling.
`(See section 9.)
`
`Parameters are available to specify either normal or high priority
`and,
`for a group call, whether the called group members can reply.
`(Provision has been made for specifying a standard method of data
`communication in the future).
`
`Emergency call.
`
`(See section 10.)
`
`Parameters are available to specify either a speech or a data call
`and,
`for a group call, whether the called group members can reply.
`Also, a radio unit may request 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.
`
`Include call.
`
`(See section 11.)
`
`During a call, a unit may request that another party joins the call.
`This facility may be used to implement a Conference Call or Call
`Transfer.
`
`Status message.
`
`(See section 13.)
`
`Thirty—two different status messages may be conveyed between units.
`The meanings of two of these messages are prescribed as a "call—me-
`back request" and "cancel previous call-me-back request".
`The
`remaining thirty messages have user-defined meanings.
`(Status
`messages can also be sent between radio units and the TSC.)
`
`Short Data Message.
`
`(See section 14.)
`
`Messages of up to 184 bits of free format data can be sent between
`units, or between units and the TSC.
`
`
`
`Page 1-2
`Petitioner Cisco Systems - Exhibit 1005 - Page 7
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 7
`
`

`
`1. 1 . 2 Hakipg calls
`
`A radio unit may request a call to any of the following called parties
`(except for status messages, which cannot be addressed to PABX or PSTN
`destinations or to groups):
`
`-
`
`—
`-
`-
`
`an individual radio unit or line-connected unit
`
`a group, or all units in the system
`a PABX number, up to nine digits
`a PSTN number, up to 31 digits.
`
`In addition, status messages and short data messages may be sent to the
`TSC.
`
`the TSC may pass a wide variety of information to
`During call set—up,
`the caller, to indicate the progress of the call. For example, it may
`indicate the reason for any delays in call set-up or the reason for a call
`failure.
`
`A call request may be cancelled at any time.
`
`1.1.3 Receiving calls
`
`A radio unit may receive calls from a radio unit or line unit, or
`(except for status messages)
`from a PABX extension or the PSTN.
`In
`addition, status messages and short data messages may be received from the
`TSC.
`For a call from a radio unit, a line unit or the TSC,
`the calling
`address may be supplied to the called unit.
`For a call from a PABX
`extension or from the PSTN,
`the calling gateway is indicated as the source
`of the call but the caller's number is not conveyed to the called unit.
`
`Incoming calls may be addressed to the unit individually or to a group
`to which it belongs.
`A radio unit may be a member of an arbitrary number
`of groups; its group addresses can be chosen independently of its
`individual address.
`
`A radio unit may refuse to accept all incoming calls, for example by
`means of a "busy" or "out-of-vehicle" control, or incoming calls could be
`refused selectively, depending on the source of the call.
`If a user does
`not wish to proceed with an incoming call immediately. he can indicate that
`he will call back later.
`
`Systems may be configured to alert a called individual and require him
`to indicate that he is ready, before a traffic channel is allocated for a
`call.
`
`1 . 1.4 Diverting Calls
`
`If a radio unit does not wish to receive calls, it may request that
`future calls addressed to it be redirected to a specified alternative
`destination.
`A radio unit may also request redirection on behalf of a
`third party, for example, for a unit which is not equipped for call
`diversion. A radio unit calling a diverted party will be informed of the
`alternative destination to try; it may then re-make the call automatically,
`or it may give the user the option of deciding whether to call the
`alternative destination.
`See section 12 for the full diversion facilities.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 8
`
`Page 1-3
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 8
`
`

`
`1.2
`
`system Features and Facilities
`
`1.2.1 System dimensions
`
`The numbering range of the protocol accommodates:
`
`—
`-
`
`—
`
`1,036,800 addresses per system
`1024 channel numbers
`
`32768 system identity codes.
`
`1.2.2 System control
`
`The protocol uses signalling at 1200 bit/s with Fast Frequency Shift
`Keying (FFSK) subcarrier modulation.
`It is designed for use by two-
`frequency half-duplex radio units and a duplex TSC.
`
`The signalling for setting up calls is transmitted on a "control"
`channel.
`A TSC can be operated using either of two control channel
`strategies: dedicated or non-dedicated.
`A dedicated system has a control
`channel permanently available for signalling, whereas a non-dedicated
`system may assign the control channel for traffic (speech or data
`communication) if all the other channels are in use.
`The use of a
`dedicated control channel is appropriate for a TSC with many channels,
`whereas a non—dedicated control channel may be more appropriate for a TSC
`with only a few channels.
`The protocol allows the use of either strategy.
`
`Broadcast messages are available to inform radio units of system
`information, such as the channels which the system may use for control
`signalling.
`
`one of the problems of mobile radio signalling systems is the clashing
`of messages from different radio units transmitting at the same time.
`The
`problems of clashing are controlled by an access protocol which offers high
`efficiency, stability and flexibility.
`(See section 1.3.3 and section 7.)
`
`Protection against interference is provided by labelling the
`signalling with a system identity code and,
`in some messages,
`the channel
`number.
`If heavy interference is encountered, control can be changed to a
`different channel.
`
`To cope with system malfunction, a customised fall-back mode of
`operation may be defined by the system designer.
`
`1.2.3 Call handling
`
`The protocol is designed for use by systems which queue calls that
`cannot be set up immediately,
`for example, if no channel is currently
`available for traffic.
`
`Before a traffic channel is assigned for a call to an individual radio
`the TSC checks that the called unit is in radio contact,
`in order to
`unit,
`avoid wasted channel assignments.
`It may also check that the radio unit's
`operator is ready for the call,
`to avoid a traffic channel being assigned
`to an unmanned unit.
`
`
`
`Page 1-4
`Petitioner Cisco Systems - Exhibit 1005 - Page 9
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 9
`
`

`
` call maintenance signalling is defined for prompt release of traffic
`
`
`
`channels at the end of a conversation, or in case comunication is lost
`during a call.
`(See section 1.3.5 and section 9.)
`
`
`
`
`As a precaution against fraudulent use of a system by an unauthorised
`radio unit,
`the TSC may at any time instruct a radio unit to transmit its
`unique serial number; comparison of the received serial number with the
`expected value will assist in the detection of fraudulent users.
`{See
`section 15.)
`
`
`
`
`
`1.2.4 Hulti-site systems
`
`The standard leaves scope for various multi-site wide--area coverage
`techniques to be used, for example:
`
`
`
`
`
`-
`-
`-
`
`synchronous/quasi-synchronous operation
`a separate control channel at each site
`a single control channel shared by time division.
`
`includes a registration facility to assist the
`The protocol
`implementation of multi-site systems and networks of Tscs: a radio unit can
`inform the TSC of its location as it roams between sites or systems.
`(The
`system identity code distinguishes the signalling from different sites and
`systems).
`The standard defines signalling procedures for registration
`(section 8), but the criteria for registration will be system-dependent-
`
`A TSC can broadcast information to assist radio units hunting for a
`control channel when they roam; for example, it can announce the channels
`which may be used for control by itself or by Tscs on adjacent sites.
`
`
`
`
`
`
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 10
`
`Page 1-5
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 10
`
`

`
`
`
`1.3
`
`Guide to some Key Protocol Aspggts
`
`This section provides an introduction to the operation of the protocol
`which, because of its scope and flexibility,
`is necessarily complex.
`The
`section outlines the control channel structure,
`the random access protocol
`and some message exchange procedures for call set-up.
`
`This section is intended only as a guide: it should not be regarded as
`a protocol specification. Readers should refer to the main body of the
`standard for the complete and precise definition.
`
`1.3.1
`
`Control channel signalling structure
`
`The signalling for setting up calls is transmitted on a "control"
`channel.
`Time on the control channel is divided into slots of duration
`
`in each slot.
`(128 bits), and one signalling message can be sent
`106.7 ms
`The basic control channel signalling structure is illustrated in Figure
`1-1.
`
`Signalling on the forward channel (base station transmit frequency)
`nominally continuous, with each slot comprising two 64-bit codewords,
`usually:
`
`is
`
`i)
`
`ii)
`
`A Control Channel System codeword (CCSC).
`The CCSC identifies the system to radio units and provides
`synchronisation for the following "address" codeword.
`
`An "address" codeword.
`An address codeword is the first codeword of any message,
`and defines the nature of the message.
`
`Both the CCSC and address codewords are displaced when the Trunking System
`Controller (TSC)
`transmits longer messages, with "data" codewords appended
`to an address codeword.
`
`transmit
`A radio unit can receive a message from the TSC in one slot,
`in time
`a response in the next slot and then retune to the forward channel
`to decode the following message from the TSC.
`(In Figure 1-1,
`the response
`is shown aligned with the outbound message; however,
`there are tolerances
`on the timing.)
`
`TSC to radio units
`
`codeword
`
`address
`codeword
`
`address
`codeword
`
` radio unit
`
`response
`
`address
`
`codeword
`
`
`
`
`
`. 1-1Fi Control channel si nallin structure
`
`
`
`Page 1-6
`Petitioner Cisco Systems - Exhibit 1005 - Page 11
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 11
`
`

`
`
`
`1.3.2
`
`Control channel signalling messages
`
`The messages sent on a control channel may be classified as follow:
`
`Aloha messages
`
`Requests
`
`"Ahoy" messages
`
`- Sent by the T51: to invite and control
`random access.
`
`— sent by radio units to request
`calls/transactions.
`- Sent by the T56 to demand a response from an
`addressed radio unit.
`
`- Sent by the TSC and by radio units.
`Acknowledgements
`- sent by the TSC to allocate traffic channels.
`Go To Channel messages
`Single address messages - Currently sent only by radio units.
`Short data messages
`— sent by the TSC and by radio units.
`Miscellaneous messages
`— sent by the TSC for system control.
`
`some uses of these messages are illustrated in the following sections.
`
`1.3.3
`
`Random access protocol
`
`1. 3.3. 3. Principle of operation
`
`one of the problems of mobile radio signalling schemes is the clash of
`messages from different radio units transmitting at the same time.
`In this
`standard,
`the problems of clashing are controlled by a random access
`protocol which is based on slotted Aloha, with a superimposed framing
`structure.
`The access protocol can be used to minimise access delays,
`ensure stability and maintain peak throughput under heavy traffic loads.
`
`The basic principle of the access protocol is described with reference
`to Figure 1-2, which illustrates signalling on a control channel.
`The TSC
`transmits a synchronisation message (indicated by ALB in Figure 1-2) to
`invite radio units to send random access messages.
`The ALI-i message
`contains a parameter (N) which indicates the number of following timeslots,
`constituting a frame,
`that are available for access.
`If a frame is already
`in progress when a user initiates a call,
`the radio unit may send its
`random access message in the next slot.
`otherwise the unit waits for a
`frame to be started and then chooses a random slot from the frame for its
`
`message. A unit wishing to send a repeat transmission after an unsuccessful
`message (corrupted by fading or clashing) chooses again from a new frame.
`
`1 slot
`<---->
`
`ALH
`
`(4)
`
`ALH
`
`(3)
`
`TSC to
`
`radio units
`
`Radio units
`to TSC
`
`\
`
`frame
`
`I
`
`\
`
`/
`
`frame
`
`Fi
`
`.
`
`l-2
`
`Two random access frames
`
`each marked b
`
`an AL!-I messa e
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 12
`
`Page 1-?
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 12
`
`

`
`
`
`1.3.3.2 Features of the random access protocol
`
`The main features of the access protocol are as follows:
`
`The TSC can monitor activity on the control channel and can optimise
`the system performance by varying the framelength to prevent excessive
`clashing and to minimise access delays. Figure 1-3 illustrates an
`example of random access control.
`
`D)
`
`The signalling overhead for random access control is kept small by
`allowing acknowledgements and Go To Channel messages to contain the
`framelength parameter (N), so that frames can be marked without
`requiring an explicit Aloha message.
`For example, see Figure 1-3.
`
`the TSC may transmit messages that demand a
`During a frame,
`response from a specified radio unit. These outbound messages
`inhibit random access in the following slot, and so reserve the
`slot for the unit's reply.
`
`The TSC may reserve frames for:
`
`-
`
`specific types of call request, by means of specific Aloha messages
`(for instance,
`the Aloha message ALHE invites emergency calls
`only);
`
`-
`
`subsets of the radio unit population {subdivision by address).
`
`TSC to
`
`radio units
`
`(1)
`
`(1)
`
`(2)
`
`
`ALB
`ALH
`ALH
`
`ALH ACKQ ACKQ
`(0)
`(1)
`(1)
`
`Radio units
`to TSC
`
`
`
`RQS 1
`RQS2
`
`RQS 1
`
`RQS2
`
`
`
`I
`/ \
`\
`frame frame
`
`\
`
`frame
`
`/
`/ \
`/ \
`frame frame
`
`The TSC detects the clashing of requests RQSI and RQS2, and
`marks a longer frame (with message ALH(2))-
`The radio units
`repeat their requests and,
`in this example, choose different
`slots.
`Each request is acknowledged in the following slot.
`
`ALH(0) does not mark a frame.
`
`ACKQ(1) acknowledges a request and also marks a new frame.
`
`In the absence of clashing,
`
`the framelength may be reduced.
`
`Fig. 1-3
`
`Example of random access control
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 13
`
`Page 1-8
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 13
`
`

`
`
`
`1 . 3 . 4
`
`Addressing
`
`A unit address is a 20-bit number comprising gwo fields: a 1-bit
`prefix and a 13-bit ldent.
`(Normally, all members of a fleet will be
`allocatedthe same prefix.)
`The division into prefix and ident allows most
`mesages to accommodate two addresses,
`the calling and called party, by
`including the prefix only once.
`For instance, call requests and Go To
`channel messages contain two idents and only one prefix.
`
`For a call to a unit with the same prefix, a request message contains
`all the information necessary to make the call. However, for a call to a
`unit with a different prefix,
`the call details cannot be accommodated in a
`single address codeword; this type of call requires the use of "extended
`addressing" procedures (as do some PAH): and mot PSTN calls).
`
`1.3. 5
`
`Examples of signalling seggences
`
`The precise signalling required for a call depends on the type of call
`and on the design of the TSC;
`(the standard does not prescribe the TSC
`algorithms). This section contains some examples of message exchange
`sequences. Note that, although not shown in the examples, messages will be
`retransmitted in the case of corruption by propagation errors or collision.
`
`Examples of message exchange sequences for call set-up are presented
`in sections 1.3.5.1 to 1.3.5.3. These examples show control channel
`signalling, for:
`
`— call requests
`-
`instruction to send extended address information
`
`-
`—
`
`checking availability of radio units
`traffic channel allocation.
`
`signalling is also sent on an allocated traffic channel, for call
`maintenance and call clear—down.
`For instance:
`
`a)
`
`b)
`
`c)
`
`To assist call maintenance, a radio unit sends a "Pressel off"
`message at the end of each speech transmission.
`The system may
`also require the unit to start each speech transmission with a
`"Pressel On" message and to send call maintenance messages
`periodically within the transmission.
`
`The calling unit in a group call, or both units in an individual
`call, send "Disconnect" messages to indicate end-of-channel-use
`when the user goes on-hook or equivalent.
`
`The TSC sends CLEAR messages to clear down a call (after receiving
`a valid Disconnect message or if a time-out has expired).
`
`However,
`
`the examples do not cover traffic channel signalling.
`
`The final example (section 1.3.5.4) illustrates the transmission of a
`short data message. This type of transaction does not use a traffic
`channel: it requires control channel signalling only.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 14
`
`Page 1-9
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 14
`
`

`
`1.3.5.1
`
`Example: radio unit calls a group
`
`Figure 1-4 illustrates a message sequence on a control channel to set
`up a group call between radio units with the same prefix.
`
`The sequence includes call request and channel allocation signalling.
`(For group calls, an availability check on the called units is not
`performed.)
`In this example, all traffic channels are in use when the call
`is requested and so the call is queued.
`
`TSC to RUS
`
`ALH
`(1)
`
`(1)
`
`3
`
`ACKQ
`
`RUB to TSC
`
`2
`
`RQS
`
`\_/ \__/
`frame frame
`
`\_/ \_/'
`frame frame
`
`1
`
`ALH
`
`General Aloha invitation (one-slot frame).
`
`2.
`
`RQS
`
`: The calling radio unit transmits its request, complying
`with the random access protocol.
`
`3.
`
`ACKQ
`
`informing the
`The TSC acknowledges the RQS message,
`calling unit that the call has been queued.
`
`4.
`
`GTC
`
`the TSC sends the
`: when a traffic channel is available,
`Go To Channel command, addressed to the calling unit and
`called group; this message instructs the units to switch
`to the traffic channel for their conversation.
`In this
`
`example the GTC is repeated, for added reliability.
`
`Fig. 1-4
`
`Common—prefix group call
`
`for
`Alternative acknowledgements from the TSC are available if,
`instance,
`the call request is invalid or the system is overloaded.
`
`If a traffic channel is available when a group call is requested then
`the TSC may omit the ACKQ and send the GTC command immediately.
`
`In this example the GTC message is repeated immediately. However,
`repeat messages may be delayed for other signalling.
`
`
`
`Page 1-10
`Petitioner Cisco Systems - Exhibit 1005 - Page 15
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 15
`
`

`
` .
`
`uni
`
`w
`
`te
`
`refix
`
`.
`
`.2
`
`l
`
`:
`
`un't
`
`s
`
`Figure 1-5 illustrates a message sequence on a control channel to set
`up a call between two radio units with the same prefix.
`The sequence
`includes call requet, availability check and channel allocation
`signalling.
`
` TSC to RUB
`RUE to TSC
`
`\
`
`frame
`
`I \
`
`frame
`
`/
`
`I
`\
`frame
`
`1
`
`ALB : General Aloha invitation (three—slot frame).
`
`2.
`
`RQS : Random access call request.
`
`3.
`
`AH!
`
`: Availability check message
`-
`acknowledges the RQS message
`-
`demands a response from the called radio unit
`(thereby checking whether the called unit
`is in radio contact)
`inhibits random access in the next slot.
`
`—
`
`4.
`
`ACK : Acknowledgement from the called radio unit,
`sent in the reserved slot.
`
`5.
`
`GTC no
`
`Go To Channel message instructing both radio units to
`switch to the specified traffic channel for their call.
`In this example the GTC is repeated, for added reliability.
`
`Fig. 1-5
`
`Common-Qrefix individual call
`
`the called unit is in radio contact and therefore
`In this example,
`If the called unit cannot be contacted,
`the use may
`responds to the AHY.
`indicate the failure to the calling unit by sending acknowledgement ACKV.
`
`the TSC checks only that the
`In both this and the following example,
`called unit is in radio contact before allocating a traffic channel. The
`TSC may also check whether the called user is ready;
`if he is not,
`the unit
`responds with acknowledgement ACKI and takes action to alert him. Then,
`when the user is ready to receive the call,
`the unit may send a status
`message (RQQ) to inform the ‘ISO.
`
`in
`The ALI-1(0) message in these examples is used as a "dummy" message,
`slots carrying no signalling relevant to the example.
`In practice,
`these
`slots may be used for signalling for another call, or for broadcast
`messages (which contain information about system parameters).
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 16
`
`Page lull
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 16
`
`

`
`
`
`1.3.5.3
`
`Example: radio unit calls a unit with a different prefix
`
`Figure 1-6 illustrates a message sequence on a control channel to set
`up a call between two radio units with different prefixes.
`
`The sequence includes call request, availability check and channel
`allocation signalling (as in the previous example). However, this sequence
`has an extra phase: after receiving the R95 message,
`the TSC sends AHYC to
`invite the calling unit to transmit the full called address. Also,
`separate GTC messages instruct the two units, because GTC contains only one
`prefix.
`
`TSC to RUB
` 2
`
`4
`
`SAMIS
`
`RUE to TSC
`
`RQS
`
`\
`
`frame
`
`frame
`
`frame
`
`1.
`
`2.
`
`ALB
`
`: General Aloha invitation (fcur—slot frame).
`
`RQS
`
`: Random access request for an interprefix call.
`(The request contains the calling unit's address
`(prefix/ident), but the called ident is set to a
`special "gateway" ident to indicate that extended
`addressing procedures are needed.)
`
`3.
`
`AHYC
`
`: Short data invitation message
`—
`acknowledges the RQS message
`—
`instructs the calling unit to send the called address
`inhibits random access in the next slot.
`
`-
`
`4.
`
`SAMIS : single Address Message from the calling radio unit,
`containing the address (prefix/ident) of the called unit.
`
`5.
`
`AH!
`
`: Availability check message demanding a response from
`the called radio unit.
`
`the availability check is a
`In this example,
`single—codeword message i.e.
`the address of the
`calling unit is not supplied.
`
`6.
`
`ACK
`
`: Acknowledgement
`
`from the called radio unit.
`
`7.
`
`GTC
`
`: Go To Channel message instructing the called radio unit
`to switch to the specified traffic channel for the call.
`
`8.
`
`GTC
`
`: Go To Channel message instructing the calling radio unit
`to switch to the specified channel for the call.
`
`Fig. 1-6
`
`Interprefix individual call
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 17
`
`Page 1-12
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 17
`
`

`
`
`
`1.3.5.4
`
`Example: radio unit sends a short data message
`
`Figure 1-7 illustrates a message sequence on a control channel for
`sending a short data message from one radio unit to another radio unit.
`this example,
`the data message comprises an address codeword and two
`appended data codewords;
`(each of the data codewords contains 46 bits of
`free format data).
`
`In
`
`the TSC instructs
`the radio unit sends its request;
`In the sequence,
`the unit to send the data message,
`forwards the data message to the called
`unit and then indicates the success of the transaction to the calling unit.
`
`u f
`
`Short data invitation message
`-
`acknowledges the RQC message
`—
`instructs the calling unit to send the data
`message in the next two slots.
`
`The calling radio unit sends its short data
`message to the TSC.
`In this example the
`message comprises an address codeword (HEAD)
`and two appended data codewords.
`
`The TSC forwards the short data message to
`the called radio unit.
`
`Acknowledgement
`
`from the called unit — message accepted.
`
`Acknowledgement sent to the calling unit to indicate
`that the called unit has accepted the data message.
`In this example the TSC immediately repeats the
`ACK message.
`for added reliability.
`
`Fig. 1-7
`
`short data message
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 18
`
`Page 1~l3
`
`TSC to RUB
`
`RUs to TSC
`
`RQC
`
`AHYC
`
`--
`
`n
`
`rame frame
`
`frame frame
`
`General Aloha invitation (one-slot frame).
`
`Random access request to transmit a short data message.
`(The request
`indicates the number of timeslots required
`for the data message:
`in this case,
`two slots.)
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 18
`
`

`
`
`
`DEFINITIONS
`
`Note - Words appearing within asterisks within these definitions are
`defined terms.
`(eg *defined term*)
`
`Active on a Channel: A *radio unit* is *active on a channel* when, on
`that channel, it is enabled to respond to *messages* addressed
`to it, or is transmitting, or is in transition between these
`two states.
`
`Note - a *radio unit* becomes active on an assigned *traffic
`channel* as soon as it can receive on that channel, whereas, on
`a *control channel* it shall not become active until it has
`
`received a codeword containing an appropriate *system identity
`code*.
`
`Address: A 20-bit number by which ‘a unit or group of units is
`known within a *system*.
`The *address* comprises two *fields*;
`a 7-bit *prefix* and a 13-bit *ident*.
`
`Address Codeword: A 64-bit codeword, conforming to the requirements of
`this standard, where the first bit is set to '1‘.
`An *address
`codeword* is always the first codeword in any *message*, and
`defines the nature of the *message*.
`
`Base Station: The entirety of transmitters and receivers operated by a
`*trunking system controller* at any one site.
`
`Call: A complete information exchange between two or more *parties*
`which includes one or more *transactions* and may include
`direct user-to-user communication on a *traffic channel*.
`
`Called Unit (or Group): The unit, or group of units, which a *calling
`unit* identifies as the desired recipient(s) of a *call*.
`The
`*ca1led unit (or group)* retains this designation for the
`duration of a *call* and this convention is used in *messages*
`relating to that particular *call*,
`irrespective of the origin
`of such *messages*.
`
`Calling Unit: A *radio unit* or *line unit* which request a *call*.
`The *calling unit* retains this designation for the duration of
`a *call* and this convention is used in *messages* relating to
`that particular *call* irrespective of the origins of such
`*messages*.
`
`Common Prefix Call: A *call* where the values of the *prefixes* in the
`calling and called *addresses* are the same.
`*Common prefix
`ca1ls* use the *short addressing* procedures.
`
`Control Channel: A *forward channel* and *return channel* being used
`for the transmission of *messages* conforming to this standard
`with the primary purpose of enabling the *trunking system
`controller* to control radio units.
`
`Data Codeword: A 64-bit codeword, conforming to the requirements of
`this standard, where the first bit is set to '0'.
`*Data
`codewords* are concatenated to an *address codeword* and
`
`supplement the information in the *address* codeword*.
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 19
`
`Page 2-1
`
`Petitioner Cisco Systems - Exhibit 1005 - Page 19
`
`

`
`
`
`Dataitem: The whole, or a part of, a *Tmessage*. A dataitem may not
`include more than 62 data codewords.
`
`Decodeable: A transmitted codeword shall be considered *decodeable*
`
`if, after receipt, and after any error correction (if used) has
`been applied, a valid codeword from the code defined in
`section 3.2.3 of this standard is formed.
`
`request that future
`Diversion: A procedure whereby a *party* may
`*calls* to a particular called address be redirected to an
`alternative destination.
`