ETSI TS V1.3.1 ( ) Technical Specification

Transcription

1 TS V1.3.1 ( ) Technical Specification Electromagnetic compatibility and Radio spectrum Matters (ERM); Peer-to-Peer Digital Private Mobile Radio; Part 3: Requirements catalogue

2 2 TS V1.3.1 ( ) Reference RTS/ERM-TGDMR Keywords digital, mobile, private, radio 650 Route des Lucioles F Sophia Antipolis Cedex - FRANCE Tel.: Fax: Siret N NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on printers of the PDF version kept on a specific network drive within Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other documents is available at If you find errors in the present document, please send your comment to one of the following services: Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute All rights reserved. DECT TM, PLUGTESTS TM, UMTS TM, TIPHON TM, the TIPHON logo and the logo are Trade Marks of registered for the benefit of its Members. 3GPP TM is a Trade Mark of registered for the benefit of its Members and of the 3GPP Organizational Partners. LTE is a Trade Mark of currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association.

3 3 TS V1.3.1 ( ) Contents Intellectual Property Rights... 4 Foreword Scope References Normative references Informative references Definitions and abbreviations Definitions Abbreviations Requirements catalogue dpmr common requirements All Call Channel Access Framing End Frame Header Frames Call Information Field Packet Data Frame Superframe Type 1 Data Type 2 Data Voice Late Entry Powersave Talking Party Identification Configured Services and Facilities Radios Broadcast Call Dialling Plan Individual Short Data ISDM Free Text Message ISDM Precoded Message ISDM Short File Transfer ISDM Status Message Off Air Call Set-up Short Appended Data Slow User Data Type 3 Data Initial Services and Facilities Radios History... 86

4 4 TS V1.3.1 ( ) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. The information pertaining to these essential IPRs, if any, is publicly available for members and non-members, and can be found in SR : "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to in respect of standards", which is available from the Secretariat. Latest updates are available on the Web server ( Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. No guarantee can be given as to the existence of other IPRs not referenced in SR (or the updates on the Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by Technical Committee Electromagnetic compatibility and Radio spectrum Matters (ERM). The present document is part 3 of a multi-part deliverable covering the Electromagnetic compatibility and Radio spectrum Matters (ERM); Peer-to-Peer Digital Private Mobile Radio, as identified below: Part 1: Part 2: Part 3: Part 4: Part 5: Part 6: "Conformance testing; Protocol Implementation Conformance Statement (PICS) proforma"; "Conformance testing; Test Suite Structure and Test Purposes (TSS&TP) specification"; "Requirements catalogue"; "Conformance testing; Abstract Test Suite (ATS)"; "Interoperability testing; Interoperability Test Suite Structure and Test Purposes (TSS&TP) specification"; "Interoperability testing; Test Descriptions (TD)".

5 5 TS V1.3.1 ( ) 1 Scope The present document is to provide a catalogue of requirements extracted from Specifications. The catalogues has been written based on the test specification framework defined in TS [2]. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at NOTE: While any hyperlinks included in this clause were valid at the time of publication cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are necessary for the application of the present document. [1] TS (V1.6.1): "Electromagnetic compatibility and Radio spectrum Matters (ERM); Peer-to-Peer Digital Private Mobile Radio using FDMA with a channel spacing of 6,25 khz with e.r.p. of up to 500 mw". [2] TS (V2.1.1): "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT); IPv6 Testing: Methodology and Framework". 2.2 Informative references The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. [i.1] ETS : "Radio Equipment and Systems (RES); Land mobile service; Binary Interchange of Information and Signalling (BIIS) at bit/s (BIIS 1 200)". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: conditionally mandatory: requirement that shall be supported by a standard conformant equipment if and only if the condition(s) stated within its requirement text are met NOTE: If one of these conditions is not met the requirement is considered to be not applicable. EXAMPLE: Such a condition may be the support of an optional higher level requirement by the equipment. conditionally optional: requirement that may be supported by a standard conformant equipment if and only if the condition(s) stated within its requirement text are met NOTE: If one of these conditions is not met the requirement is considered to be not applicable. mandatory: requirement that shall be supported by a standard conformant equipment

6 6 TS V1.3.1 ( ) not applicable: requirement that does not have to be met by a standard conformant equipment optional: requirement that may be supported by a standard conformant equipment 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ACK AI ARQ CC CCH CI Cont CRC CSF Di-bit DP ET FDMA FEC FN HI HT ID ISF MFID MS NACK OACSU PAR PDF RF RSSI SLD SYNC TCH ACKnowledgment Air Interface Automatic Retransmission request Colour Code Control CHannel Call Information Continuation flag Cyclic Redundancy Checksum for data error detection Configured Services and Facilities 2 bits grouped together to represent a 4-level symbol Data Position End Type Frequency Division Multiple Access Forward Error Correction Frame Numbering Header Information Header Type IDentifier Initial Services and Facilities Manufacturer's FID Mobile Station Negative ACKnowledgment Off Air Call Set Up PARameter data Packet Data Format Radio Frequency Received Signal Strength Indication SLow Data SYNChronization Traffic CHannel

7 7 TS V1.3.1 ( ) 4 Requirements catalogue 4.1 dpmr common requirements All Call RQ_001_0824 All Call TS [1] Clause: Type: Mandatory Applies to: ISF Requirement: A dpmr radio shall support voice group "All call" supplementary service. Specification Text: {{All radios will decode an All call (common ID = 255) irrespective of the common ID selected by the user}}. However, radios that have 255 selected as the common ID will only respond to calls addressed to a common ID of 255. TP_PMR_0824_01 (Interoperability), TP_PMR_0824_02 (Interoperability), TP_PMR_0824_03 (Interoperability), TP_PMR_0824_01 (Conformance), TP_PMR_0824_02 (Conformance), TP_PMR_0824_03 (Conformance) RQ_001_0858 All Call TS [1] Clause: Type: Conditionally Mandatory Applies to: ISF Requirement: IF an ISF radio Common ID is set to 255 THEN the radio shall only respond to call addressed to Common ID of 255. Specification Text: All radios will decode an All call (common ID = 255) irrespective of the common ID selected by the user. {{However, radios that have 255 selected as the common ID will only respond to calls addressed to a common ID of 255}}. TP_PMR_0858_02 (Interoperability), TP_PMR_0858_01 (Interoperability), TP_PMR_0858_01 (Conformance), TP_PMR_0858_02 (Conformance)

8 8 TS V1.3.1 ( ) RQ_001_1317 All Call TS [1] Clause: A Type: Conditionally Mandatory Requirement: For a CSF radio complying with the Standard User Interface the All Call dialled strings shall be dialled and encoded as follows: The All Call dialled string "n******" (All Call within a prefix) User dialled string Air Interface ID Remark "0******" 18 CC 3E All Talkgroup ID0 "1******" 2F All Talkgroup ID1 etc. etc. etc. "9******" E1 DC 82 All Talkgroup ID9 The All Call dialled string: "******" is mapped to the All Talkgroup ID15 and addresses all MSs irrespective of their prefix. User dialled string Air Interface ID Remark "*******" F8 33 A6 All Talkgroup ID15 Specification Text: {{The All Call dialled string "n******" (All Call within a prefix) is mapped as shown in table A.3. Table A : Mapping of prefixed All Call to the AI User dialled string Air Interface ID Remark "0******" 18 CC 3E All Talkgroup ID0 "1******" 2F All Talkgroup ID1 etc. etc. etc. "9******" E1 DC 82 All Talkgroup ID9 The All Call dialled string: "******" is mapped to the All Talkgroup ID15 and addresses all MSs irrespective of their prefix. Table A : Mapping of all prefix call to the AI User dialled string Air Interface ID Remark "*******" F8 33 A6 All Talkgroup ID15}} RQ_001_1317, RQ_001_1410, RQ_001_1411 TP_PMR_1317_01 (Conformance), TP_PMR_1317_02 (Conformance), TP_PMR_1317_03 (Conformance), TP_PMR_1317_04 (Conformance) Channel Access RQ_001_1001 TS [1] Applies to: Requirement: Channel Access Clause: Type: Mandatory ISF, CSF A caller radio shall listen before transmit. When the received signal level has not exceeded -105 dbm for the duration of the T_ch_chk timer then the radio shall assume the channel to be free. Specification Text: When determining whether activity is present on a channel, the radio shall monitor the RSSI level. {{If after a maximum period of time (T_ch_chk) the RSSI level has not exceeded a configurable (within a predefined range) threshold RSSI_LO, then the radio shall assume that activity is not present on the channel.}} RSSI_LO shall be set to -105 dbm ± 3 db.

9 9 TS V1.3.1 ( ) RQ_001_1002 Channel Access TS [1] Clause: Type: Conditionally Mandatory Requirement: A radio shall listen before transmitting. IF the received signal level is equal or above -105 dbm AND the radio can synchronize on the channel. THEN the radio shall assume that there is dpmr activity on the channel. Specification Text: If however the RSSI level does exceed this threshold, then the radio shall assume that activity is present on the channel and it shall attempt to become frame synchronized to the activity. {{If the radio is successful in becoming frame synchronized to the activity, then the radio shall assume that 6,25 khz FDMA activity is present on the channel. }} RQ_001_1003 Channel Access TS [1] Clause: Type: Conditionally Mandatory Requirement: A radio shall listen before transmitting. IF the received signal level is above -105 dbm AND the radio can not synchronize to the channel for the duration of the T_ch_free timer THEN it shall assume the activity is not dpmr. Specification Text: If however the RSSI level does exceed this threshold, then the radio shall assume that activity is present on the channel and it shall attempt to become frame synchronized to the activity. {{If however after a maximum period of time (T_ch_free), the radio has not become frame synchronized to the activity, then the radio shall assume that the activity is non-6,25 khz FDMA activity.}} RQ_001_1004 Channel Access TS [1] Clause: Type: Mandatory Requirement: A radio shall listen before transmitting. When the received signal level is above -105 dbm and the radio manages to synchronize to the channel but the color code is incorrect then it shall assume the activity is interference. Specification Text: If the radio is successful in becoming frame synchronized to the activity, then the radio shall assume that 6,25 khz FDMA activity is present on the channel. {{If the Colour Code is different then the radio shall assume that the activity is interference.}} TP_PMR_1004_01 (Conformance)

10 10 TS V1.3.1 ( ) RQ_001_1005 Channel Access TS [1] Clause: Type: Mandatory Requirement: IF a transmitting radio announces a non zero Tx WAIT time then other radios shall not commence any PTT activated transmissions during this Tx WAIT period. Specification Text: {{When a transmitting radio announces a non zero Tx WAIT time then PTT activated transmissions shall not be permitted to start during this Tx WAIT time irrespective of any polite or impolite criteria employed.}} TP_PMR_1005_01 (Conformance) RQ_001_1006 Channel Access TS [1] Clause: 10.3 Type: Mandatory Requirement: A transmission shall be automatically terminated if it exceeds 180 seconds. The transmission may only be resumed by rekeying the transmitter. Specification Text: dpmr HSs shall have a transmit TimeOut timer which limits the time of a single transmission item. This timer shall be set to the value of 180 seconds whenever the PTT key is pressed and counts down to zero. {{If the transmit TimeOut timer expires, then all HSs will stop transmitting immediately and may not re-transmit until PTT has been released and pressed again.}} TP_PMR_1006_01 (Interoperability), TP_PMR_1006_02 (Interoperability), TP_PMR_1006_03 (Interoperability), TP_PMR_1006_04 (Interoperability) RQ_001_1007 Channel Access TS [1] Clause: Type: Optional Requirement: When an acknowledgement is required in response to a received call the callee may transmit this acknowledgement irrespective of whether the RF channel is busy during a defined period after the call has been received. Specification Text: {{Where a radio has been solicited to transmit a response, it may transmit the response within response time [T_ack] irrespective of whether the channel is "Idle" or "Busy". }} TP_PMR_1007_01 (Conformance), TP_PMR_1007_02 (Conformance), TP_PMR_1007_03 (Conformance) RQ_001_1008 Channel Access TS [1] Clause: , Type: Optional Requirement: When a radio is involved in a voice call it may transmit even if another party to the same call is transmitting on the RF channel. Specification Text: Additionally, {{while a radio is partied to a voice call, it may transmit irrespective of whether the channel is "Idle" or "Busy" with 6,25 khz FDMA activity pertaining to the same voice call}} but may not transmit if a Tx WAIT time has been invoked. TP_PMR_1008_01 (Interoperability), TP_PMR_1008_02 (Interoperability), TP_PMR_1008_01 (Conformance)

11 11 TS V1.3.1 ( ) RQ_001_1009 Channel Access TS [1] Clause: Type: Conditionally Mandatory Applies to: ISF Requirement: IF a ISF radio has polite to own Colour Code enabled THEN the radio shall not transmit when the RF channel is occupied by a transmission using the same Colour Code. Specification Text: {{Polite to own Colour Code: The radio shall refrain from transmitting on a channel while the channel is "Busy" with other 6,25 khz FDMA activity from radios using the same Colour Code.}} TP_PMR_1009_01 (Interoperability), TP_PMR_1009_01 (Conformance) RQ_001_1010 Channel Access TS [1] Clause: Type: Conditionally Optional Applies to: ISF Requirement: IF an ISF radio has impolite channel access enabled THEN it may transmit if the RF channel is occupied by any other signal. Specification Text: {{Impolite: The radio shall transmit on a channel regardless of any other activity (either 6,25 khz FDMA or otherwise) already present on the channel.}} TP_PMR_1010_01 (Interoperability), TP_PMR_1010_01 (Conformance) RQ_001_1011 Channel Access TS [1] Clause: Type: Conditionally Mandatory Requirement: IF a CSF radio has polite to own Group or Talkgroup enabled THEN the radio shall not transmit while the RF channel is occupied by transmissions by members of its own group or talkgroup. Specification Text: Polite to own Group or Talkgroup: {{The radio shall refrain from transmitting on a channel while the channel is "Busy" with other 6,25 khz FDMA activity from radios within its own group or talkgroup. }}For all other types of activity already present on the channel, the radio shall transmit regardless. TP_PMR_1011_01 (Interoperability), TP_PMR_1011_01 (Conformance)

12 12 TS V1.3.1 ( ) RQ_001_1012 Channel Access TS [1] Clause: 10.5, Type: Conditionally Mandatory Requirement: Certain received calls require acknowledgement responses. When these acknowledgements are lost because of interference etc they may be repeated. IF these acknowledgements are repeated THEN they shall be limited to a maximum number of 4 times with ms time intervals between each repeat. Specification Text: Certain transmissions solicit responses and where these responses are not received (e.g. due to collisions, interference etc.) the transmitting entity may repeat the original transmission a number of times either until the response is received or the transmitting entity gives up. The waiting times for re-transmission and the maximum number of retries are defined in clause {{Automatic repeats are permitted for acknowledgement (and nack) signalling. A maximum of four such transmissions are permitted. The time between any such repeated signalling shall be in the range 300 ms to 500 ms.}} TP_PMR_1012_01 (Interoperability), TP_PMR_1012_01 (Conformance), TP_PMR_1012_02 (Conformance), TP_PMR_1012_03 (Conformance) RQ_001_1013 Channel Access TS [1] Clause: Type: Conditionally Mandatory Requirement: IF a CSF radio has Polite to own Colour Code enabled THEN the radio shall not transmit while the RF channel is occupied by transmissions using the same Colour Code. Specification Text: Polite to own Colour Code: {{The radio shall refrain from transmitting on a channel while the channel is "Busy" with other 6,25 khz FDMA activity from radios using the same Colour Code. }}For all other types of activity already present on the channel, the radio shall transmit regardless. TP_PMR_1013_01 (Interoperability) RQ_001_1014 Channel Access TS [1] Clause: Type: Conditionally Mandatory Requirement: IF a CSF radio has impolite channel access enabled THEN it may transmit if the RF channel is occupied by any other signal. Specification Text: {{Impolite: The radio shall transmit on a channel regardless of any other activity (either 6,25 khz FDMA or otherwise) already present on the channel}}. TP_PMR_1014_01 (Interoperability) RQ_001_1017 Channel Access TS [1] Clause: Type: Mandatory Requirement: Before transmitting, radios shall observe certain minimum times in assessing whether an RF channel is busy (T_ch_chk : 100 ms). Specification Text: {{T_ch_chk: Channel check timer: 100 ms.}}

13 13 TS V1.3.1 ( ) RQ_001_1020 Channel Access TS [1] Clause: Type: Mandatory Requirement: Before transmitting, radios shall observe certain minimum times for trying to synchronize to any activity found on the channel (T_ch_free : 200 ms). Specification Text: {{T_ch_free: Unsynchronizable activity timer: 200 ms.}} RQ_001_1021 Channel Access TS [1] Clause: Type: Conditionally Optional Requirement: Where a radio has been solicited to transmit a response, it may transmit the response within the T_ack response time irrespective of whether the channel is "Idle" or "Busy". Specification Text: {{Where a radio has been solicited to transmit a response, it may transmit the response within response time [T_ack] irrespective of whether the channel is "Idle" or "Busy".}} RQ_001_1022 Channel Access TS [1] Clause: Type: Conditionally Optional Requirement: Where a radio has been solicited to transmit a response it may always disregard any polite channel access enabled for the duration of the T_ack timer of 3 seconds. Specification Text: {{T_ack: Acknowledgement timer : 3 s}}

14 14 TS V1.3.1 ( ) Framing RQ_001_0401 Framing TS [1] Clause: Type: Mandatory Requirement: All transmissions are made up from 80 ms (384 bits) frames. Normal frames (not packet data) are the concatenation of: 24 bits of either FrameSync or ColourCode 72 bits of Control Channel data Followed by 4 blocks of 72 bits of payload. Specification Text: {{The FDMA transmission is made up of 80 ms payload frames, each comprising 384 bits. Payload frame: a b c d e f a: 24 bits FrameSync2 (FS2) or ColourCode (CC) bits b: 72 bits Control Channel (CCH) data c: 72 bits Traffic channel (TCH) d: 72 bits TCH e: 72 bits TCH f: 72 bits TCH }} TP_PMR_0401_01 (Conformance), TP_PMR_0401_02 (Conformance), TP_PMR_0401_03 (Conformance) RQ_001_0402 Framing TS [1] Clause: Type: Mandatory Requirement: All normal (non packet data) transmissions are made up from an integral number of superframes. Specification Text: These transmissions are always started with a Header frame containing a preamble (for bit synchronization) and a frame synch (for frame synchronization). The Header is followed by a series of Superframes that contain both the payload (voice or data) and the information about the call such that receiving stations can implement late entry. {{A call always consists of an integral number of superframes }}and is terminated by an End frame. RQ_001_0403 Framing TS [1] Clause: Type: Mandatory Requirement: Each superframe is the concatenation of four 80 ms frames. Specification Text: {{Four 80 ms frames are concatenated to form a superframe of 320 ms.}} TP_PMR_0403_01 (Conformance), TP_PMR_0403_03 (Conformance), TP_PMR_0403_02 (Conformance)

15 15 TS V1.3.1 ( ) RQ_001_0404 Framing TS [1] Clause: Type: Mandatory Requirement: Normal calls with voice or data continuous transmission generated by the radio will start with a Header frame, an integral number of superframes and then terminated by an End frame. Specification Text: {{Voice or data payload continuous transmission: These transmissions are always started with a Header frame containing a preamble (for bit synchronization) and a frame synch (for frame synchronization). The Header is followed by a series of Superframes that contain both the payload (voice or data) and the information about the call such that receiving stations can implement late entry. A call always consists of an integral number of superframes and is terminated by an End frame.}} TP_PMR_0404_01 (Conformance), TP_PMR_0404_02 (Conformance), TP_PMR_0404_03 (Conformance) RQ_001_0405 Framing TS [1] Clause: Type: Mandatory Requirement: Calls generated by the radio for the purposes of call set-up or service request etc will be that of a concatenated Header frame and an End frame. Specification Text: {{Call set up, service request, etc: These transmissions are simply a concatenation of a Header frame and an End frame. Their purpose is to inform the receiving station of the call, type of call or information required. }} TP_PMR_0405_01 (Conformance), TP_PMR_0405_02 (Conformance) RQ_001_0406 Framing TS [1] Clause: Type: Conditionally Mandatory Requirement: Calls generated by the radio for the purposes of acknowledgements will be simply a Header frame. Specification Text: {{Acknowledgement: Acknowledgements are a type of Header that contains information such as confirmation of received data, errors in received data etc. Only applicable to CSF radios. }} TP_PMR_0406_01 (Conformance), TP_PMR_0406_02 (Conformance), TP_PMR_0406_03 (Conformance), TP_PMR_0406_04 (Conformance)

16 16 TS V1.3.1 ( ) RQ_001_0407 Framing TS [1] Clause: Type: Conditionally Mandatory Requirement: IF the radio supports disconnection request THEN calls generated by the radio for the purposes of confirming the end of the series of exchanges of a call shall be the concatenation of a Header frame and End frame repeated once. Specification Text: {{Disconnection: Sending stations can signal that all exchanges of a call have been completed by transmitting a disconnection request. This is a Header + End frame pair that is repeated. }} TP_PMR_0407_01 (Conformance), TP_PMR_0407_02 (Conformance), TP_PMR_0407_03 (Conformance), TP_PMR_0407_04 (Conformance) RQ_001_0408 Framing TS [1] Clause: Type: Conditionally Mandatory Requirement: Calls generated by the radio for the purposes of status request responses will be a Header frame and End frame. Specification Text: {{Status request acknowledgements: As the status information is contained within the End frame then the response of a receiving station to a status request call will be a Header + End frame pair. Only applicable to CSF radios.}} TP_PMR_0408_01 (Conformance) RQ_001_0811 Framing TS [1] Clause: Type: Mandatory Requirement: A CSF radio shall use only Group B Colour Codes as defined in the table Group Channel Frequency Colour Code (Bit) Colour Code (Hex) B 446, F , F77D57 446, F7D , F7FF55 446, F55F5D 446, F5755D 446, F5DD5F 446, F5F75F 446, FF5D7F 446, FF777F 446, FFDF7D 446, FFF57D 446, FD , FD7F75 446, FDD , FDFD77 Specification Text: {{Radios shall use only the Group B CC}}. TP_PMR_0811_01 (Conformance), TP_PMR_0811_02 (Conformance), TP_PMR_0811_03 (Conformance), TP_PMR_0811_04 (Conformance), TP_PMR_0811_05 (Conformance), TP_PMR_0811_06 (Conformance), TP_PMR_0811_07 (Conformance), TP_PMR_0811_08 (Conformance), TP_PMR_0811_09 (Conformance), TP_PMR_0811_10 (Conformance), TP_PMR_0811_12 (Conformance), TP_PMR_0811_13 (Conformance), TP_PMR_0811_14 (Conformance), TP_PMR_0811_15 (Conformance), TP_PMR_0811_16 (Conformance), TP_PMR_0811_11 (Conformance)

17 17 TS V1.3.1 ( ) RQ_001_0812 Framing TS [1] Clause: Type: Mandatory Applies to: ISF Requirement: A ISF radio shall use only the Group A Colour Codes as defined in the table: Group Channel Frequency Colour Code (Bit) Colour Code (Hex) A 446, , DD75 446, F , D 446, D7D 446, D57F 446, FF7F 446, F555F 446, F7F5F 446, FD75D 446, FFD5D 446, D5D55 446, D , DDF57 446, DF , DD7 Specification Text: {{Radios shall use only the Group A CC}} End Frame TP_PMR_0812_02 (Conformance), TP_PMR_0812_03 (Conformance), TP_PMR_0812_04 (Conformance), TP_PMR_0812_05 (Conformance), TP_PMR_0812_06 (Conformance), TP_PMR_0812_07 (Conformance), TP_PMR_0812_08 (Conformance), TP_PMR_0812_09 (Conformance), TP_PMR_0812_10 (Conformance), TP_PMR_0812_11 (Conformance), TP_PMR_0812_12 (Conformance), TP_PMR_0812_13 (Conformance), TP_PMR_0812_14 (Conformance), TP_PMR_0812_15 (Conformance), TP_PMR_0812_16 (Conformance), TP_PMR_0812_01 (Conformance) RQ_001_0984 End frame TS [1] Clause: Type: Mandatory Requirement: Each End frame shall start with a Frame synchronization sequence 3, 24 bits long. Frame synchronization sequence 3 is made by following 3 bytes: 7D DF F5 (all in HEX). Specification Text: {{Finally the 24 bit FS3 synchronization sequence is prefixed to these end data bits.}} {{Clause FS3}} The Frame sync 3 sequence contained in the End frame is a 24 bit sequence that shall have the following value: Binary: Hex: 7D DF F5.

18 18 TS V1.3.1 ( ) RQ_001_0985 End frame TS [1] Clause: Type: Mandatory Requirement: Each End frame shall have a two bits long End Type (ET) field using the values : 00 Normal end frame 01 End frame with status message 10 Reserved 11 Reserved Specification Text: {{The end data starts with the End Type (ET) which is either 00 (normal end frame) or 01 (end frame with status message).}} {{Clause 5.12 End type}} Frame used END Frame. Data length 2 bits. Definition: {{Table 5.12}}: End type RQ_001_0986 End frame TS [1] Clause: Type: Mandatory Requirement: Each End frame shall have a two bits long acknowledgement request (ARQ) field using the values : 00 No ACK request to called station 01 ACK request to called station 10 Reserved 11 Reserved Specification Text: {{The next 2 bit are the acknowledgement request (ARQ). }}00 signifies that no acknowledgement is requested and 01 requires an acknowledgement. {{Clause 5.13 ARQ}} Frame used END Frame. Data length 2 bits. Definition: Table 5.13: ARQ

19 19 TS V1.3.1 ( ) RQ_001_0987 End frame TS [1] Clause: Type: Mandatory Requirement: Each End frame shall have a four bits long Tx wait time (WAIT) field using the values: 0000 No specified time ms (half a frame) ms (one frame) ms (two frames) ms (one superframe) Other Reserved Specification Text: {{The next 4 bits define any Tx wait time (WAIT) }} using the values given in clause {{clause 5.14 Tx Wait}} Frame used END. Data length 4 bits. Definition: The Tx wait time will be implemented by the called station(s) such that other radios who have a break-in request pre-keyed by the user may transmit during the specified time. Table 5.14: Tx wait time RQ_001_0988 End frame TS [1] Clause: Type: Mandatory Requirement: Each End frame shall have a five bits long status message field using the values 0 to 31. When End Type (ET) field value has been set to 00 (binary) these bits shall be considered as dummy data. Specification Text: 5 bit of status message will then follow if ET has been set to 01 (or 5 bits of dummy data if ET = 00). {{Clause 5.15 Status}} Frame used END Frame. Data length 5 bits. Definition: 0 to 31 Status message RQ_001_0989 End frame TS [1] Clause: Type: Mandatory Requirement: Each frame shall have a four bits long reserved field and shall always contain a 0. Specification Text: {{Finally the 4 reserved bits are set to 0000.}}

20 20 TS V1.3.1 ( ) RQ_001_0990 End frame TS [1] Clause: 9.6 7, 8 Type: Mandatory Requirement: In each End frame the End Information (EI0) field shall be used to calculate a 7 bit checksum, generated by the X^7 + X^3 + 1 polynomial. The checksum shall be appended, giving a 24 bits field referred as END0 DATA) Specification Text: {{The 7 bit CRC checksum is added using the polynomial given in clause 7.2 giving a total of 24 bits.}} {{These 24 bits are now separated into 3 bytes. Each byte is now coded by a shortened 12,8 Hamming Code (clause 7.3) giving 3 x 12 bit blocks. These 36 bits are now repeated and the total 72 bits are scrambled using the polynomial given in clause 7.4.}} Clause 7.2 CRC addition Use CRC Polynomial Frame (CCH) CRC7 X^7 + X^3 + 1 See figure 10. RQ_001_0991 End frame TS [1] Clause: 9.6 7, 8 Type: Mandatory Requirement: In each End frame the END0 DATA field shall be separated into 3 bytes. Each of these bytes shall be coded by shortened 12,8 Hamming code X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit) C3,C2,C1,C0 is parity bit (4 bit) The Generator matrix is as follows: X7 X6 X5 X4 X3 X2 X1 1 C3 C2 C1 C The Shortened Hamming code (12,8) Polynomial is X^4 + X + 1. This gives the Shortened Hamming END0 DATA. See Figure 10. Specification Text: {{These 24 bits are now separated into 3 bytes. Each byte is now coded by a shortened 12,8 Hamming Code (clause 7.3) giving 3 x 12 bit blocks.}} These 36 bits are now repeated and the total 72 bits are scrambled using the polynomial given in clause 7.5. Clause 7.3 Hamming code A shortened Hamming code (12,8) is employed and the generator matrix is shown below: X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit). Shortened Hamming code (12,8) Polynomial: X^4 + X + 1.

21 21 TS V1.3.1 ( ) RQ_001_0992 End frame TS [1] Clause: 9.6 7, 8 Type: Mandatory Requirement: In each End frame the End Information (EI1) field shall be used to calculate a 7 bit checksum, generated by the X^7 + X^3 + 1 polynomial. The checksum shall be appended, giving a 24 bits field referred as END1 DATA) Specification Text: {{The 7 bit CRC checksum is added using the polynomial given in clause 7.2 giving a total of 24 bits.}} See figure 10. RQ_001_0993 End frame TS [1] Clause: 9.6 7, 8 Type: Mandatory Requirement: In each End frame the END1 DATA field shall be separated into 3 bytes. Each of these bytes shall be coded by shortened 12,8 Hamming code, as shown in clause 7.3 X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is parity bit (4 bit). The Generator matrix is as follows: X7 X6 X5 X4 X3 X2 X1 1 C3 C2 C1 C The Shortened Hamming code (12,8) Polynomial is X^4 + X + 1. This gives the Shortened Hamming END1 DATA. Specification Text: These 24 bits are now separated into 3 bytes. {{Each byte is now coded by a shortened 12,8 Hamming Code (clause 7.3) giving 3 x 12 bit blocks.}} These 36 bits are now repeated and the total 72 bits are scrambled using the polynomial given in clause 7.5. Clause 7.3 Hamming code A shortened Hamming code (12,8) is employed and the generator matrix is shown below: X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit). Table 7.3: Generator matrix Shortened Hamming code (12,8) Polynomial: X^4 + X + 1. See Figure 10.

22 22 TS V1.3.1 ( ) RQ_001_0994 End frame TS [1] Clause: Type: Mandatory Requirement: In each End frame the Shortened Hamming END0 DATA and Shortened Hamming END1 DATA shall each be scrambled using the polynomial X^9 + X^5 + 1 re-initialised with the value of all "1"s for each block. Specification Text: These 24 bits are now separated into 3 bytes. Each byte is now coded by a shortened 12,8 Hamming Code (clause 7.3) giving 3 x 12 bit blocks. {{These 36 bits are now repeated and each block of 36 bits is scrambled using the polynomial given in clause 7.4.}} Clause 7.4 Scrambling The scrambling polynomial is X^9 + X^5 + 1 with an initial preset value of all "1"s. See Figure 10. TP_PMR_0994_01 (Conformance) Header Frames RQ_001_0816 Header frames TS [1] Clause: Type: Conditionally Mandatory Requirement: If the transmission is a type 3 data THEN A CSF radio shall use frame sync 4 (FS4) in the header. Specification Text: {{Packet data uses a different format to the normal communications frame format. The use of frame sync 4 (FS4) indicates that the frames following will be in PDF format}}. TP_PMR_0816_01 (Conformance) RQ_001_0959 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header frame shall start with a preamble field, at least 72 bits long, composed by a repetition of a byte containing the value 5F (HEX). If more than 72 bits are sent then the same 5F (HEX) data shall be used. Specification Text: {{The header is completed by prefixing with the 48 bit FS1 synchronization sequence (see note 2) and then prefixing the synchronization sequence with a minimum of 72 bits of preamble}}.

23 23 TS V1.3.1 ( ) RQ_001_0960 Header frames TS [1] Clause: Type: Conditionally Mandatory Requirement: If the Header frame is not a Packet data header THEN the Frame synchronization sequence field shall be made by following 6 bytes: 57 FF 5F 75 D5 77 (all in HEX). This is referred as Frame synchronization sequence 1. Specification Text: {{The header is completed by prefixing with the 48 bit FS1 synchronization sequence and then prefixing FS1 with a minimum of 72 bits of preamble}} {{Clause FS1}} The Frame sync 1 sequence contained in the non packet data Header frame (Header 1) is a 48 bit sequence that shall have the following value: Binary: Hex: 57 FF 5F 75 D5 77. RQ_001_0961 Header frames TS [1] Clause: Type: Conditionally Mandatory Requirement: If the Header frame is a Packet data header THEN the Frame synchronization sequence field shall be made by following 6 bytes: FD 55 F5 DF 7F DD (all in HEX). This is referred as Frame synchronization sequence 4. Specification Text: NOTE 2: {{In the case where this is a Packet Data Header, the 48 bit FS4 synchronization sequence shall be used.}} Clause FS4 The Frame sync 4 sequence contained in the Packet Data Header frame (Header 2) is a 48 bit sequence that shall have the following value: Binary: Hex: FD 55 F5 DF 7F DD.

24 24 TS V1.3.1 ( ) RQ_001_0962 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header shall be identified by the Header Type (HT) field. This shall have a length of four bits and it's value shall be as follows: 0000 Communication start Header (a superframe follows) 0001 Connection request Header (an END frame follows) 0010 Unconnect request Header (an END frame follows) 0011 ACK (this a single frame, ACK or NACK is differentiated by the CI bits setting) 0100 System request Header (an END frame follows) 0101 ACK Header reply to a system request (a superframe follows) 0110 System delivery Header (a superframe follows) 0111 Status response Header 1000 Status request Header Other Reserved Specification Text: {{First there are 4 bits allocated to Header Type (HT) which is selected according to clause 5.11.}} {{Clause 5.11 Header type}} Frame used Header Frame/Packet Data Header Frame. Data length 4 bits. Table 5.11: Header type RQ_001_0963 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header shall have a 24 bit long field containing the called station ID. Specification Text: {{HT is followed by the 24 bits of the called station ID.}} To this the 24 bits of the own ID is added. RQ_001_0964 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header shall have a 24 bit long field containing the own ID. Specification Text: HT is followed by the 24 bits of the called station ID. {{To this the 24 bits of the own ID is added.}}

25 25 TS V1.3.1 ( ) RQ_001_0965 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header shall state the type of the call through a three bits long communications mode field, as follows: 000 Voice communication (no user data in SLD field) 001 Voice + slow data (user data in SLD field) 010 Data communication type 1 (Payload is user data without FEC) 011 Data communication type 2 (Payload is user data with FEC) 100 Data communication type 3 (Packet data, ARQ method) 101 Voice and appended data (Type 2) Other Reserved Specification Text: {{The communications mode value is added according to the table in clause 5.7.}} RQ_001_0966 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header shall have a four bits long Communication format field (F). This shall be as follows: Values shall be as follows: 0000 Call ALL 0001 Peer-to-peer communication Other Reserved Specification Text: {{The communications format bits are now added according to clause 5.8. Generally these will be set to 0001(peer-to-peer call). Occasionally they may be set to 0000 (all call) but this is a special case, similar to a broadcast.}} {{Table 5.8}} RQ_001_0967 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header shall have a two bits long Reserved field (RES). The two bits shall be always se to 0. Specification Text: {{The next 2 bits are set to 00 (reserved bits).}}

26 26 TS V1.3.1 ( ) RQ_001_0974 Header frames TS [1] Clause: Type: Mandatory Requirement: The Header information field (HI0) shall be used to calculate an 8 bit checksum, generated by the X^8 + X^2 + X^1 + 1 polynomial. This 8 bits are added, giving a total of 80 bits. Specification Text: {{The 8 bit CRC checksum is added using the polynomial given in clause 7.2 giving a total of 80 bits.}} {{Clause 7.2 CRC addition}} Use CRC Polynomial Header (HI) CRC8 X^8 + X^2 + X^1 + 1 See{{ figure 1}}0. RQ_001_0975 Header frames TS [1] Clause: Type: Mandatory Requirement: This 80 bits shall be separated into 10 bytes. Each of these bytes shall be coded by shortened 12,8 Hamming code: X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit) C3,C2,C1,C0 is parity bit (4 bit) The Generator matrix is as follows: X7 X6 X5 X4 X3 X2 X1 1 C3 C2 C1 C The Shortened Hamming code (12,8) Polynomial is X^4 + X + 1. This will generate a 12x10 bit blocks. Specification Text: {{These 80 bits are now separated into 10 bytes. Each byte is now coded by a shortened 12,8 Hamming Code (clause 7.3) giving 10 x 12 bit blocks.}} {{7.3 Hamming code}} A shortened Hamming code (12,8) is employed and the generator matrix is shown below: X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit). {{Table 7.1}}: Generator matrix Shortened Hamming code (12,8) Polynomial: X^4 + X + 1. See figure 10.

27 27 TS V1.3.1 ( ) RQ_001_0976 Header frames TS [1] Clause: Type: Mandatory Requirement: The 12x10 bit blocks shall be interleaved using the following 12x10 interleaving matrix: This gives the interleaved HI0 data. Specification Text: {{To protect against burst interference, these 10 x 12 bit blocks are now interleaved using the 12 x 10 HI interleaving matrix given in clause 7.5.}} {{7.5 Interleaving}} There are two interleaving matrices, one for the TCH and one for the HI field. {{Table 7.3}}: HI field Interleaving matrix NOTE: Applied in the Header HI0/HI1. See {{figure 10}}. RQ_001_0977 Header frames TS [1] Clause: 9.5 9, 10, 11, 12 Type: Mandatory Requirement: The interleaved HI0 data shall be scrambled using the polynomial X^9 + X^5 + 1 with an initial preset value of all "1"s. This scrambled data shall be referred as HI0 data. Specification Text: {{Then the interleaved HI data is scrambled using the polynomial given in clause 7.4.}} {{Clause 7.4 Scrambling}} The scrambling polynomial is X^9 + X^5 + 1 with an initial preset value of all "1"s.

28 28 TS V1.3.1 ( ) RQ_001_0978 Header frames TS [1] Clause: 9.5 Type: Mandatory Requirement: The Header information field (HI1) shall be used to calculate an 8 bit checksum, generated by the X^8 + X^2 + X^1 + 1 polynomial. This 8 bits are added, giving a total of 80 bits. Specification Text: The 24 bit Colour Code is appended to the HI data and {{then the HI data is repeated after the CC}}. {{The 8 bit CRC checksum is added using the polynomial given in clause 7.2 giving a total of 80 bits.}} {{Clause 7.2 CRC addition}} Use CRC Polynomial Header (HI) CRC8 X^8 + X^2 + X^1 + 1 See {{figure 10}}. RQ_001_0979 Header frames TS [1] Clause: 9.5 9, 10, 11, 12 Type: Mandatory Requirement: This 80 bits shall be separated into 10 bytes. Each of these bytes shall be coded by shortened 12,8 Hamming code: X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit) C3,C2,C1,C0 is parity bit (4 bit). X7 X6 X5 X4 X3 X2 X1 1 C3 C2 C1 C The Shortened Hamming code (12,8) Polynomial is X^4 + X + 1. This will generate a 12x10 bit blocks. Specification Text: {{These 80 bits are now separated into 10 bytes. Each byte is now coded by a shortened 12,8 Hamming Code (clause 7.3) giving 10 x 12 bit blocks.}} {{7.3 Hamming code}} A shortened Hamming code (12,8) is employed and the generator matrix is shown below: X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit). Table 7.1: Generator matrix Shortened Hamming code (12,8) Polynomial: X^4 + X + 1. See {{figure 10}}.

29 29 TS V1.3.1 ( ) RQ_001_0980 Header frames TS [1] Clause: 9.5 9, 10, 11, 12 Type: Mandatory Requirement: The generated a 12x10 bit blocks, that shall be interleaved using the following 12x10 interleaving matrix: This gives the interleaved HI1 data. Specification Text: {{To protect against burst interference, these 10 x 12 bit blocks are now interleaved using the 12 x 10 HI interleaving matrix given in clause 7.5.}} {{7.5 Interleaving}} There are two interleaving matrices, one for the TCH and one for the HI field. Table 7.3: HI field Interleaving matrix NOTE: Applied in the Header HI0/HI1. See figure 10. RQ_001_0981 Header frames TS [1] Clause: 9.5 9, 10, 11, 12 Type: Mandatory Requirement: The interleaved HI1 data shall be scrambled using the polynomial X^9 + X^5 + 1 with an initial preset value of all "1"s. This scrambled data shall be referred as HI1 data. Specification Text: {{Then the interleaved HI data is scrambled using the polynomial given in clause 7.4.}} {{Clause 7.4 Scrambling}} The scrambling polynomial is X^9 + X^5 + 1 with an initial preset value of all "1"s. See figure 10.

30 30 TS V1.3.1 ( ) RQ_001_0982 Header frames TS [1] Clause: Type: Mandatory Requirement: The Header shall have a Colour Code (CC) field appended after the HI0 data field. The Colour Code depend on the operation frequency. In case of a ISF Radio the CC is Group Channel Frequency Colour Code (Bit) Colour Code (Hex) A 446, , DD75 446, F , D 446, D7D 446, D57F 446, FF7F 446, F555F 446, F7F5F 446, FD75D 446, FFD5D 446, D5D55 446, D , DDF57 446, DF , DD7 In Case of a CSF Radio the CC is Group Channel Frequency Colour Code (Bit) Colour Code (Hex) B 446, F , F77D57 446, F7D , F7FF55 446, F55F5D 446, F5755D 446, F5DD5F 446, F5F75F 446, FF5D7F 446, FF777F 446, FFDF7D 446, FFF57D 446, FD , FD7F75 446, FDD , FDFD77 Specification Text: {{The 24 bit Colour Code is appended to the HI data and then the HI data is repeated after the CC.}} {{6.1.5 Colour code}} The Colour Code is a 12 bit code that is di-bit encoded into a 24 bit sequence. Colour Code are attributed directly to the RF operating channel and are not freely selectable. Radios employing Initial Services and Facilities shall use the Group A colour codes. Radios employing Configured Services and Facilities shall use the Group B colour codes. {{Table 6.1 Colour code by RF channel}} RQ_001_0983 Header frames TS [1] Clause: Type: Mandatory Requirement: Each Header shall be made up of the concatenation of Preamble, Frame Sync, HI0 data, Colour Code data and HI1 data. Specification Text: {{The 24 bit Colour Code is appended to the HI data and then the HI data is repeated after the CC.}}See figure 10.