Downloaddocument Annexures To ER
Downloaddocument Annexures To ER
Downloaddocument Annexures To ER
संo: टीईसी/एसडी/डीडी/टीसीपी-222/2.6/सितंबर2020
ANNEXURES TO ERs
No.:TEC/SD/DD/TCP-222/2.6/September2020
संस्करण-2.6
© टीईसी 2020
© TEC 2020
1. The RFC documents of IETF are subject to periodic revision. Hence, wherever RFCs are mentioned in the
ERs/ Annexures to ERs, the offered product shall meet either the referred RFC or its latest/ later version.
Wherever, a feature of the RFC is mentioned, product shall comply with the part of the RFC specifying the
feature.
2. Similarly, this applies to other standards of IEC, EN, CISPR, ETSI, ITU, IEEE, TEC etc.
DISCLAIMER
1. The Annexures and Appendices in this document are being reviewed and the updated version shall be
uploaded on MTCTE Portal www.mtcte.tec.gov.in from time to time.
2. Feedback for corrections, if any, may be sent on email to [email protected] with copy to
[email protected]
OR
EN/IEC 62368-1:2014
A1.2 Ingress Protection IEC 60529 Compliance to clauses As per offered product category
applicable to the EUT
Annexure-A3: Safety Requirement for Radio Communication Equipment (Other than CPE)
Parameter Group: SAFETY
S. No. Parameter Name Standard Limits/ Test Levels Applicability/ Remarks
A3.1 IT Equipment Safety for EN/IEC 60215:2016 Compliance to clauses Test reports as per IEC 60215: 1987 shall
Radio Products (Other applicable to the EUT be acceptable only till March 31, 2020
than CPE)
B.1 Conducted emission - Class CISPR22 (2008)/ EN 55022 AC/ DC Power input/ output Conducted Emission for Class A
A OR ports: equipment as per applicable clauses/
As per Table 7 of Annexure B1 ranges.
CISPR32 (2015)/EN 55032 for CISPR 22 and applicable
Table(s) in CISPR 32. Test reports as per CISPR 22 (2008)/
EN 55022 shall be acceptable only
Telecom Ports: till 31.03.2020.
As per Table 8B of Annexure
B1 and applicable Table(s) in
CISPR 32.
B.2 Radiated emission - Class A CISPR22 (2008)/ EN 55022 For CISPR 22: Radiated Emission for Class A
equipment as per applicable clauses/
OR i. For 10 m measuring ranges.
distance:
CISPR32 (2015)/EN 55032 As per Table 5a (Refer Annex Test reports as per CISPR 22 (2008)/
B1) for frequency range up to 1 EN 55022 shall be acceptable only
GHz. till 31.03.2020.
Note:
For 3m measuring distance,
EUT size should be as such it
fits in a cylindrical area of
diameter 1m.
Annexure to ERs – 2.6/ September2020 For other equipment, measuring Page 4 of 205
distance of 10m is applicable.
S. No. Parameter Name Standard Limits/ Test Levels Applicability/ Remarks
B.3 Conducted emission - Class CISPR22 (2008)/ EN 55022 AC/ DC Power input/ output Conducted Emission for Class B
B OR ports: equipment as per applicable clauses/
As per Table 6 of Annexure B1 ranges.
CISPR32 (2015)/EN 55032 for CISPR 22/EN 55022
Test reports as per CISPR 22 (2008)/
Telecom Ports: EN 55022 shall be acceptable only
As per Table 8A of Annexure till 31.03.2020.
B1 for CISPR 22/EN 55022 and
applicable Table(s) in CISPR
32/EN 55032
B.4 Radiated emission - Class B CISPR22 (2008)/ EN 55022 For CISPR 22: Radiated Emission for Class B
OR i. For 10 m measuring equipment as per applicable clauses/
distance: ranges.
CISPR32 (2015)/EN 55032 As per Table 4a for frequency
range up to 1 GHz. Test reports as per CISPR 22 (2008)/
EN 55022 shall be acceptable only
ii. For 3 m measuring till 31.03.2020.
distance:
As per Table 4a1 for frequency
range up to 1 GHz.
Note:
For 3m measuring distance,
EUT size should be as such it
fits in a cylindrical area of
diameter 1m.
B.5 Conducted and Radiated CISPR14-1 (2016) Conducted and Radiated Emission
Emission - Electrical applicable to Electricity Meter
Appliances
B.9 Immunity to Electrostatic EN/IEC 61000-4-2(2008) Level 4 {± 15 kV}; Applicable to Electricity Meter
Discharge- Level-4 Air Discharge Performance Criteria B
B.10 Immunity to radiated RF EN/IEC 61000-4-3(2010) i. Test level 2 {Test field Clauses applicable to Telecom
strength of 3 V/m} for Equipment or Telecom Terminal
80 MHz to 1 GHz; Equipment with voice interface.
Performance Criteria A.
ii. Test level 3 {Test field
strength of 10 V/m} for
800 MHz to 960 MHz &
1.4 to 6.0 GHz,;
Performance Criteria A
B.11 Immunity to radiated RF EN/IEC 61000-4-3(2010) 80 MHz to 6.0 GHz: Clauses applicable to Telecom
Test level 2 {Test field strength Terminal Equipment without voice
of 3 V/m}: Performance Criteria interface.
A
B.12 Immunity to fast transients EN/IEC 61000-4-4(2012) Test Level 2 (1.0 kV): Not applicable for devices having in-
(burst) AC/DC Power Lines Performance Criteria B built or replaceable battery
B.13 Immunity to fast transients EN/IEC 61000-4-4(2012) Test level 2 (0.5kV): Not applicable for mobile devices
(burst) Signal/Control/Data/Teleco Performance Criteria B having only radio interface
m Lines
B.14 Immunity to surges EN/IEC 61000-4-5(2014) 2kV: Performance Criteria B Not applicable for devices having in-
line to ground – power port built or replaceable battery
B.15 Immunity to surges EN/IEC 61000-4-5(2014) 1kV: Performance Criteria B Not applicable for devices having in-
line to line – power port built or replaceable battery
B.16 Immunity to surges EN/IEC 61000-4-5(2014) 2kV: Performance Criteria C Not applicable for mobile devices
Common mode – telecom having only radio interface
ports
B.17 Immunity to conducted EN/IEC 61000-4-6(2013): Test level 2 {3 V r.m.s.}: Not applicable for mobile devices
disturbance induced by Performance Criteria A having only radio interface
Radio frequency fields AC/DC lines & signal
control /telecom lines. 150 kHz to 80 MHz
B.18 Immunity to voltage dips & EN/IEC 61000-4-11(2004) Performance criteria B Applicable to AC power ports
short interruption: Voltage
dip corresponding to a
reduction of supply voltage
of 30% for 500ms (i.e. 70 %
supply voltage for 500ms)
B.19 Immunity to voltage dips & EN/IEC 61000-4-11(2004) Performance criteria C Applicable to AC power ports
short interruption: Voltage
dip corresponding to a
reduction of supply voltage
of 60% for 200ms; (i.e. 40%
supply voltage for 200ms).
B.20 Immunity to voltage dips & EN/IEC 61000-4-11(2004) Performance criteria C Applicable to AC power ports
short interruption: Voltage
interruption corresponding
to a reduction of supply
voltage of > 95% for 5s.
B.21 Immunity to voltage dips & EN/IEC 61000-4-11(2004) Performance criteria B Applicable to AC power ports.
short interruption: Voltage
interruption corresponding
to a reduction of supply
voltage of >95% for 10ms.
B.22 Immunity to voltage dips & EN/IEC 61000-4-29 Performance criteria B Applicable to DC power ports
short interruption: Voltage
Interruption with 0% of
supply for 10ms.
B.23 Immunity to voltage dips & EN/IEC 61000-4-29 Performance criteria C Applicable to DC power ports
short interruption: Voltage
Interruption with 0% of
supply for 30ms, 100ms,
300ms and 1000ms.
B.24 Immunity to voltage dips & EN/IEC 61000-4-29 Performance criteria B Applicable to DC power ports
short interruption: Voltage
dip corresponding to 40% &
70% of supply for 10ms, 30
ms.
B.25 Immunity to voltage dips & EN/IEC 61000-4-29 Performance criteria C Applicable to DC power ports
short interruption: Voltage
dip corresponding to 40% &
70% of supply for 100ms,
300ms and 1000 ms.
B.26 Immunity to voltage dips & EN/IEC 61000-4-29 Performance criteria B Applicable to DC power ports
short interruption: Voltage
variations corresponding to
80% and 120% of supply
for 100 ms to 10s as per
Table 1c of IEC 61000-4-29
Note: Minimum required information related to EMI/EMC parameters has been captured in Annex-B to facilitate the applicants.
However, for further details/clarity in this regard, TEC document for EMI/EMC standard – TEC/SD/DD/EMC-221/05/OCT-16 may
kindly be referred to.
Conducted and Radiated Emissions will be as per Class A for chasis based OLT equipment and Class B for residential OLT equipment
In case of any conflict, the TEC document for EMI/EMC standard shall prevail.
Table 4(a): Limits for unwanted radiated emission of “Class B” equipment at a measuring distance of 10m.
Table 5(a): Limits for unwanted radiated emission of “Class A” equipment (for Telecommunication Centres) at a measuring distance of
10m.
Frequency range Limits (quasi-peak)
30-230 MHz 40 dB (μV/m)
230- 1000 MHz 47 dB (μV/m)
Note: 1) The lower limit shall apply at the transition Frequency.
Note: 2) Additional provisions may be required forcases where interference occurs.
Table 4(a1): Limits for unwanted radiated emission of “Class B” Equipment at a measuring distance of 3 m.
Frequency range limits (quasi – peak)
30 – 230 MHz 40.5 dB (V/m)
230 – 1000 MHz 47.5 dB (V/m)
Notes:
1. The lower limits shall apply at transition frequency
2. Additional provisions may be required for cases where interference occurs.
Table 5 (a1): Limits for unwanted radiated emission of “Class A” Equipment at a measuring distance of 3 m.
Frequency range limits (quasi – peak)
30 – 230 MHz 50.5 dB (V/m)
230 – 1000 MHz 57.5 dB (V/m)
Notes:
1.The lower limits shall apply at transition frequency
2. Additional provisions may be required for cases where interference occurs.
Table 4(b): Limits for radiated disturbance of “Class B” Eqpt. at a measurement distance of 3 m.
Frequency range Average limit Peak limit
GHz dB (V/m) dB (V/m)
1 to 3 50 70
3 to 6 54 74
Table 5(b): Limits for radiated disturbance of “Class A” Eqpt. at a measurement distance of 3 m.
Table 8(B): Limits for conducted common mode (asymmetric mode) emissions from telecommunication ports of Class A equipment
(intended for use in telecommunication centers only).
Table 8(A): Limits for conducted common mode (asymmetric mode) emission from telecommunication ports for class B equipment.
0.5 to 30 74 64 30 20
Note 1: The limits decrease linearly with the logarithm of the frequency in the range 0.15 MHz to 0.5 MHz.
Note 2: The current and voltage disturbance limits are derived foruse with an impedance stabilization
network (ISN) which presents a common mode (asymmetric mode) impedance of 150 are
telecommunication port under test (conversion factor is 20 log10150/1= 44 dB).
Note: Frequency of operation requirements is as per the latest NFAP issued by WPC and the requirements in NFAP supersede the
requirements listed here.
Note: EIRP requirements i.e. Limits/Values shall be as per the latest NFAP and GSRs issued by WPC, DoT and the requirements in NFAP and GSRs supersede
the requirements listed here.
C3.2 MRTS Conformance to standards ETSI EN 300 390 Compliance Applicable for equipment meant for
Equipment for MRTS transmission of data and/or speech and
having integral antenna
C3.3 MRTS Conformance to standards ETSI EN 300 086 Compliance Applicable for equipment meant for
Equipment for MRTS analogue speech and having internal or
external RF connector
C3.4 MRTS Conformance to standards ETSI EN 300 296 Compliance Applicable for equipment meant for
Equipment for MRTS analogue speech and having integral
antenna
C3.5 MRTS Conformance to standards ETSI EN 300 219 Compliance Applicable for equipment meant to
Equipment for MRTS transmit signals to initiate specific
receiver response
C3.6 MRTS Conformance to standards ETSI EN 300 341 Compliance Applicable for equipment, using
Equipment for MRTS integral antenna, meant to transmit
signals to initiate specific receiver
response
C3.7 MRTS ETSI EN 301 166 Compliance Applicable for equipment meant for
Equipment Conformance to standards transmission of data and/or speech and
for MRTS operating on narrow band channels
(<10KHz) and having antenna
connector
C3.9 VHF/UHF Conformance to standards ETSI EN 300 113 Compliance Applicable for equipment meant for
Equipment for Equipment used in transmission of data and/or speech and
VHF/UHF Radio Systems having antenna connector
C3.10 VHF/UHF Conformance to standards ETSI EN 300 390 Compliance Applicable for equipment meant for
Equipment for Equipment used in transmission of data and/or speech and
VHF/UHF Radio Systems having integral antenna
C3.11 VHF/UHF Conformance to standards ETSI EN 300 086 Compliance Applicable for equipment meant for
Equipment for Equipment used in analog speech and having internal or
VHF/UHF Radio Systems external RF connector
C3.12 VHF/UHF Conformance to standards ETSI EN 300 296 Compliance Applicable for equipment meant for
Equipment for Equipment used in analog speech and having integral
VHF/UHF Radio Systems antenna
C3.13 VHF/UHF Conformance to standards ETSI EN 300 219 Compliance Applicable for equipment meant to
Equipment for Equipment used in transmit signals to initiate specific
VHF/UHF Radio Systems receiver response
C3.14 VHF/UHF Conformance to standards ETSI EN 300 341 Compliance Applicable for equipment, using
Equipment for Equipment used in integral antenna, meant to transmit
VHF/UHF Radio Systems signals to initiate specific receiver
response
C3.15 VHF/UHF Conformance to standards ETSI EN 300 783 Compliance Applicable for commercial amateur
Equipment for Equipment used in radio equipment.
VHF/UHF Radio Systems
C3.17 VHF/UHF Conformance to standards ETSI EN 301 925 Compliance Applicable for Radiotelephone
Equipment for Equipment used in transmitters and receivers for maritime
VHF/UHF Radio Systems mobile service operating in VHF band
C3.18 VHF/UHF Conformance to standards ETSI EN 301 178 Compliance Applicable for portable VHF
Equipment for Equipment used in radiotelephone equipment for the
VHF/UHF Radio Systems maritime mobile service (for non-
GMDSS applications only)
C3.19 VHF/UHF Conformance to standards ETSI EN 300 698 Compliance Applicable for Radio telephone
Equipment for Equipment used in transmitters and receivers for the
VHF/UHF Radio Systems maritime mobile service operating in
the VHF bands used on inland
waterway
C3.20 HF Equipment HF Radio Systems ETSI EN 300 433 Compliance Applicable to Citizen band (CB) Radio
equipment.
C3.21 HF Equipment HF Radio Systems ETSI EN 303 402 Compliance Applicable to maritime mobile
transmitters and receivers.
C3.22 HF Equipment HF Radio Systems ETSI EN 301 783 Compliance Applicable to commercially available
amateur radio equipment.
C3.23 PTP Microwave PTP Fixed Digital Radio ETSI EN 302 217-2 Compliance Applicable for full or split outdoor
Fixed Radio Conformance unit of Point to Point Microwave
Systems Fixed Radio Systems
C3.24 PMP PMP Fixed Digital Radio ETSI EN 302 326-2 Compliance Applicable for full or split outdoor
Microwave Conformance unit of Point to Multi-Point
Fixed Radio Microwave Fixed Radio Systems
Annexure-D4: Figures
18
Return Loss dB
50
46
LCL dB
14
40
30
20
10
0
300 500 2000 3400
300 600 3400
Frequency (Hz)
Frequency (Hz)
Fig. 1: Minimum Value of return Loss Fig. 2: Minimum Value of LCL
Annexure-F7: Radio Conformance Test for Cellular Wireless Repeaters using 3G/WCDMA ULTRA FDD Technology
Parameter Group: Cellular (CELLULAR)
S. No. Parameter Individual Parameter Name Standard Clause Applicability/
Name Remarks
F7.1 WCDMA Output Power Clause 6
3GPP TS 25.143
Repeater Station
F7.2 Parameters Out of band emission 3GPP TS 25.143 Clause 9.1
F7.3 Spurious emissions 3GPP TS 25.143 Clause 9.2
F7.4 Input intermodulation 3GPP TS 25.143 Clause 11
F7.5 Out of band gain 3GPP TS 25.143 Clause 8
F7.6 Adjacent Channel Rejection Ratio 3GPP TS 25.143 Clause 13
F7.8 Output intermodulation 3GPP TS 25.143 Clause 12
Annexure-F11: Radio Conformance Test for Devices having Cellular Wireless Interface using WCDMA/ HSPA Technology
Parameter Group: Cellular (CELLULAR)
S. No. Parameter Name Individual Parameter Name Standard Applicability/Remarks
F11.1 WCDMA Int Transmitter Maximum output power 3GPP TS EN 301 908-2 Test setup and test
Parameters 34.121-1 (UMTS) Clause procedure along with
Clause 5.2 4.2.2 the equipment required
to conduct test must be
included as available
for Test 39 otherwise
evaluation of
applications of Labs for
CAB/CB accreditation
not possible.
F11.2 Transmitter Spectrum emissions mask 3GPP TS EN 301 908-2 Same as above
34.121-1 (UMTS) Clause
Clause 5.9 4.2.3
Annexure-G2: Parameters for Radio Interfaces for equipment operating in delicensed frequency bands of 2.4 GHz and 5 GHz
Parameter Group: Radio Conformance (RADCONF)
S. No. Parameter Name Standard/ Limits/ Values Remarks
Parameter
G2.1 Maximum Transmit Power LoRa EN 300 220-1. <1W LoRa Interface
(As per WPC GSR 564(E))
G2.2 EIRP LoRa EN 300 220-1. <4W LoRa Interface
(As per WPC GSR 564(E))
G2.3 Maximum Transmit Power EN 300 220-1. <1W SigFox Interface
SigFox (As per WPC GSR
564(E))
G2.4 EIRP SigFox EN 300 220-1 <4W SigFox Interface
(As per WPC GSR 564(E))
G2.5 Carrier Bandwidth for RFID EN 300 220, LF- 50KHz to 200KHz: RFID Interface
Interface WPC GSR WPC GSR 90(E);
564(E)
HF-13.56 MHz band:
and/or
WPC GSR 884(E);
EN 300 330,
WPC GSR UHF- 865-867 MHz:
884(E), 90(E) WPC GSR 564(E)
G2.6 EIRP for RFID Interface EN 300 220, LF- 50KHz to 200 KHz: RFID Interface
G2.7 Maximum Transmit Power RFID EN 300 220, LF- 50KHz to 200 KHz: RFID Interface
WPC GSR WPC GSR 90(E);
564(E)
HF-13.56 MHz band:
and/or
WPC GSR 884(E);
EN 300 330,
WPC GSR UHF- 865-867 MHz:
884(E), 90(E) WPC GSR 564(E)
G2.9 EIRP for NFC Interface ETSI EN 300 330 As per WPC GSR 884(E) NFC Interface
G2.10 Maximum Transmit Power NFC ETSI EN 300 330 As per WPC GSR 884(E) NFC Interface
G2.11 Carrier Bandwidth for BLE ETSI EN 300 328 As per WPC GSR 45(E) Bluetooth Low Energy Interface
Interface
G2.12 EIRP for BLE Interface ETSI EN 300 328 As per WPCGSR 45(E) Bluetooth Low Energy Interface
G2.17 EIRP for RLAN/ WLAN Latest NFAP and As per WPC GSR 1048(E) Wifi Interface
equipment operating in 5 GHz GSRs issued by DoT Note: Testing as per EN 301893 or Appendix-
WPC EIRP requirements shall be as II Test-1
per the latest NFAP and GSRs
issued by WPC and the
requirements in NFAP and GSRs
supersede the requirements
listed here.
G2.18 EIRP for PTP/ PMP fixed Radio Latest NFAP and As per WPC GSR 1048(E) PTP/PMP Wireless Access Equipment
systems operating in 5 GHz GSRs issued by DoT Note: in 5 GHz
WPC EIRP requirements shall be as Testing as per EN 302 502 or Appendix-
per the latest NFAP and GSRs II Test-1
issued by WPC and the
requirements in NFAP and GSRs
supersede the requirements
listed here.
H.1 Gigabit Ethernet Link Speed and Auto IEEE 802.3 Appendix-II, Test4
Electrical or 10 100 1000 Negotiation GE
Base T Ethernet
H.2 Fast Ethernet Electrical Link Speed and Auto IEEE 802.3 Appendix-II, Test4
or 10/100 Base T Negotiation for GE
Ethernet
H.3 Gigabit Ethernet Optical Average Launch power for 1 GE IEEE 802.3z
Opt Cl. 38
J2.4 GPON Opt Output Power for G.984.2 -3.0 to +2.0dBm (A)
GPON Int at ONT -2.0 to +3.0 dBm (B)
+0.5 to +5.0 dBm (B+)
+2.0 to +7.0 dBm (C)
+0.5 to +5.0 dBm (C+)
+0.5 to +5.0 dBm (D)
A,B,B+,C,C+ and ‘D’ are classes of
optical link budget for PON
Measured at 1490nm at OLT ‘s PON port
i.e. Rx or D/L mode. Refer following
Tables of ITU-T G.984.2: (1) Table 2c &
Table 2f1 for Class A, Class B, Class C
(2) Table A.1 for Class B+ (3) Table V.1
for Class C+, (4) Table V.2 for Class D
J2.38 WDMPON Opt Output Power G.694.1 +2.0 to +7.0 dBm These are
WDMPON Int at OLT (G.989.2/p2p Refer TEC GR on WDM-PON(2017) proprietary
WDM) implementation
J2.39 WDMPON Opt Output Power G.694.1 -2.0 to +2.0 dBm These are
WDMPON Int at ONT (G.989.2/p2p Refer TEC GR on WDM-PON(2017) proprietary
implementation
J2.47 NGNPON2 Opt Output Power G.989.2 For 2.48832 Gbit/s downstream
NGPON2Int at OLT Direction
*Nominal bit rate for different technology is defined in respective Standard i.e. 1)GPON-G.984.2/cl8.2.1, (2)XGPON- G.987.2/Cl 9.2.1,(3)
NGPON2-G.989.2/Cl 11.1.1,(4) XGSPON- G.9807.1/Cl B.9.2.1, (5) EPON-IEEE 802.3ah
RFC 2684
ATM
ATM
Some
DSL Some 802.3
RG, DSL 802.3 Phy
xTU-R Phy
or
terminal xTU-R DSLAM BRAS
Figure 1-
Y Y To check if IPOE is established on the ADSL or
IPoE over ATM (U-interface): Figure 2 depicts the end-
VDSL system. Methodology is mentioned in
to-end protocol stacks associated with IPoE access
DSL forum technical report TR-045. Annexure-
method.
E: group 3.3_test 1 & Test 2 may be carried
IP IWF for
IWF for IPoE
IPoE IP IP out to cater this clause. It is tested through
(Section 4.9 & 4.11.1) protocol simulator.
Ethernet Ethernet 802.1Q, 802.1Q, Some
802.1ad 802.1ad media
RFC RFC 2684 Ethernet Ethernet
2684
ATM ATM
Note: Wherever RFC are referred, only ‘shall’ clauses given in the RFCs should be tested against the parameter referred in this ER.
K.10 STM-1 Optical Output Jitter for STM-1 Opt Int G.783 0.5k to 1.3 MHz -0.30(UI)
65 k to 1.3MHz –
0.10 (UI)
(1UI=6.43ns)
K.11 STM-1 Optical Receiver Overload for STM-1 G.957 I-1,S-1.1, S-1.2: -8dBm
Opt Int
L-1.1,L-1.2, L-1.3: -10 dBm
K.12 STM-1 Optical Receiver Sensitivity for STM-1 G.957 I-1: -23dBm
Opt Int
S-1.1, S-2.1: -28dBm
L-1.1, L-1.2, L-1.3: -34 dBm
K.13 STM-4 Optical Input Jitter Tolerance for STM- G.825 Fig. 3, clause-6.1.2.2
4 Opt
K.14 STM-4 Optical Mean Launched Power for G.957, G.691 I-4,S-4.1,S-4.2: -8 (max)& -
STM-4 Opt Int 15(min)(dBm)
L-4.1,L-4.2,L-4.3: +2(max)& -
3(min)(dBm)
K.15 STM-4 Optical Nominal Bit Rate with G.957 622 080Kbps
Tolerance STM-4 Opt Int
K.16 STM-4 Optical Operating Wavelength Rangefor G.957 I-4: 1260a)-1360
STM-4 Opt Int
S-4.1: 1293-1334/1274-1356
S-4.2: 1430-1580
M.4 Mobile Handset – Smart Mobile Emergency Support - GPS G.S.R. No. 1441 (E) dated 23-11-2017. Appendix-II, Test-33
Phone Location
M.5 Mobile Handset Mobile Emergency Support - Call DoT 16-04/2015-AS-III/NP/67/120 dt Appendix-II, Test-34
on 112 4.5.16, 3GPP2 C.S0023 for CDMA
2000, 3GPP TS 22.101 and TS 24.008
for GSM/ UMTS/ LTE.
M.6 Mobile Handset Mobile Device Indian Language IS 16333 (Part 3). Appendix-II, Test-37
Support
M.7 Mobile Handset SAR Display for Mobile Handset TEC/GR/SAR/001/01.MAR.09 or IEC Appendix-II, Test-
Standard 62209-1 35
M.8 Mobile Handset SAR Value for Mobile Handset IEC 62209-1:2005 62209-1: 2005 or
TEC/GR/SAR/001/01.MAR.09 later version
M.9 IoT Devices IoT Dev - Non-0 IMEI or MEID or GSMA official document Device manufacturer
Unique MAC IMEI Allocation & Approval Process shall mention the
(for IMEI / MEID) suitable procedure
for testing IMEI/
MEID/ MAC
address/ any other
unique ID by
connecting device to
P1.1 SIP Parameters Set-A SIP Header : Message Body Type RFC 3261 Clause 7.4.1 SIP Terminal, PABX
P1.2 SIP Parameters Set-A Generating SIP request RFC 3261 Clause 8.1.1, SIP Terminal, PABX
8.1.1.2 to 8.1.1.7
(To, R-URI, From, Call-ID,
CSeq, Max-Forwards, Via)
P1.3 SIP Parameters Set-A SIP Dialog and Transaction RFC 3261 Clause 12, 12.1.1, SIP Terminal, PABX
12.1.2
P1.4 SIP Parameters Set-A SIP Terminating a Session with a RFC 3261 Clause 15 SIP Terminal, PABX
BYE request.
P1.5 SIP Parameters Set-A SIP Creating the initial invite RFC 3261 Clause 13.2.1 SIP Terminal, PABX
P1.6 SIP Parameters Set-A User Authentication RFC 3261 Clause 21 SIP Terminal, PABX
P1.7 SIP Parameters Set-B SIP - Call Flow RFC 3261 Clause 4 LMGW
P1.8 SIP Parameters Set-B SIP Header : Message Body Type RFC 3261 Clause 7.4.1 LMGW
P1.9 SIP Parameters Set-B Generating SIP request (To, R- RFC 3261 Clause 8.1.1, LMGW
URI, From, Call-ID, CSeq, Max- 8.1.1.2 to 8.1.1.7
Forwards, Via)
P1.10 SIP Parameters Set-B SIP Dialog and Transaction RFC 3261 Clause 12, 12.1.1, LMGW
12.1.2
P1.11 SIP Parameters Set-B SIP Terminating a Session with a RFC 3261 Clause 15 LMGW
BYE request.
P1.12 SIP Parameters Set-B SIP Creating the initial invite RFC 3261 Clause 13.2.1 LMGW
P1.13 SIP Parameters Set-B User Authentication RFC 3261 Clause 21 LMGW
P1.14 SIP Parameters Set-C SIP - Max Forwards (Not for RFC 3261 Clause 8.1.1.6 SBC
SIPS URI)
P1.15 SIP Parameters Set-C SIP - Message Body length (Not RFC 3261 Clause 7.4.2 SBC
for SIPS URI)
P1.16 SIP Parameters Set-C SIP - Responses (Not for SIPS RFC 3261 Clause 7.2 SBC
URI)
P1.17 SIP Parameters Set-D SIP - Max Forwards (Not for RFC 3261 Clause 8.1.1.6 SOFT SWITCH
SIPS URI)
P1.18 SIP Parameters Set-D SIP - Message Body length (Not RFC 3261 Clause 7.4.2 SOFT SWITCH
for SIPS URI)
P1.19 SIP Parameters Set-D SIP - Responses (Not for SIPS RFC 3261 Clause 7.2 SOFT SWITCH
URI)
P1.20 SIP Parameters Set-D SIP - Cancelling a Request RFC 3261 Clause 9 SOFT SWITCH
P1.21 SIP Parameters Set-D SIP - Client Behaviour (Not for RFC 3261 Clause 9.1 SOFT SWITCH
SIPS URI)
P1.22 SIPI Parameters SIPI - Conventions for Q 1912.5 Clause 5.1 SOFT SWITCH
representation of ISUP PDU
P1.23 SIPI Parameters SIPI - Conventions for Q 1912.5 Clause 5.2 SOFT SWITCH
representation of SIP/SDP
information
P1.24 SIPI Parameters SIPI - IAM parameters Q 1912.5 Clause 6.1.3 SOFT SWITCH
P1.25 SIPI Parameters SIPI - INVITE received with an Q 1912.5 Clause 6.1.2 SOFT SWITCH
SDP offer
P1.26 SIPI Parameters SIPI - INVITE received without Q 1912.5 Clause 6.1.1 SOFT SWITCH
an SDP offer
P1.27 SIPI Parameters SIPI - ISUP encapsulation – Q 1912.5 Clause 5.4 SOFT SWITCH
detailed procedures
P1.28 SIPI Parameters SIPI - Sending of Initial Address Q 1912.5 Clause 6.1 SOFT SWITCH
Message (IAM)
P2.1 RTP Parameters Set-A RTP: Sender report RTCP packet RFC 3550 Clause 6.4.1 SIP Terminal, PABX
version
P2.2 RTP Parameters Set-A RTP: Sequence number RFC 3550 Clause 5.1 SIP Terminal, PABX
P2.3 RTP Parameters Set-A RTP: Version and Port RFC 3550 Clause 5.1 SIP Terminal, PABX
P2.4 RTP Parameters Set-A RTP: Payload Type RFC 3550 Clause 5.1 SIP Terminal, PABX
P2.5 RTP Parameters Set-A RTP: SSRC Identification RFC 3550 Clause 5.1 SIP Terminal, PABX
P2.6 RTP Parameters Set-B RTP: Sender report RTCP packet RFC 3550 Clause 6.4.1 LMGW, MGW
version
P2.7 RTP Parameters Set-B RTP: Sequence number RFC 3550 Clause 5.1 LMGW, MGW
P2.8 RTP Parameters Set-B RTP: Version and Port RFC 3550 Clause 5.1 LMGW, MGW
P2.9 RTP Parameters Set-B RTP: Payload Type RFC 3550 Clause 5.1 LMGW, MGW
P2.10 RTP Parameters Set-C RTP: Byte Order, Alignment, and RFC 3550 Clause 4 Session Border Controller
Time Format
P2.11 RTP Parameters Set-C RTP: Simple Multicast Audio RFC 3550 Clause 2.1 Session Border Controller
Conference
S. No. Parameter Name Individual Parameter Name IETF RFC Clause/ Applicability/ Remarks
Section
P3.1 RTCP Parameters Set-A RTCP: Port Assignment RFC 3551 Clause 8 SIP Terminal
P3.2 RTCP Parameters Set-A RTCP: Registering Additional RFC 3551 Clause 3 SIP Terminal
Encodings
P3.3 RTCP Parameters Set-A RTCP: GSM-EFR RFC 3551 Clause 4.5.9 SIP Terminal
P3.4 RTCP Parameters Set-A RTCP: Guidelines 1 for sample- RFC 3551 Clause 4.3 SIP Terminal
based audio encodings
P3.5 RTCP Parameters Set-A RTCP: Guidelines 2 for sample- RFC 3551 Clause 4.4 SIP Terminal
based audio encodings
P3.6 RTCP Parameters Set-B RTCP: Port Assignment RFC 3551 Clause 8 Session Border Controller
P3.7 RTCP Parameters Set-B RTCP: Registering Additional RFC 3551 Clause 3 Session Border Controller
Encodings
P4.1 TCP Parameters Header Format and Sequence RFC 793 Clause 3.1, 3.3 MGW, SIP Terminal,
Numbers PABX
Test terminology
as per clause 3.2
P5.1 UDP Parameters UDP Format RFC 768 MGW, LMGW, SBC, Soft
Switch, PABX
P5.2 UDP Parameters User Terminology RFC 768 MGW, LMGW, SBC, Soft
Switch, PABX
P5.3 UDP Parameters Sequence numbers RFC 768 MGW, LMGW, SBC, Soft
Switch, PABX
P5.4 MGCP Parameters Connection Model H.248 Clauses 6.1 & MGW, LMGW, Soft
6.2 Switch
P6.1 IPV4 Parameters Set-A Model of operation RFC 791 Clause 2.2 MGW, SGW, PABX, ONU, ONT
P6.2 IPV4 Parameters Set-A Internet Header Format RFC 791 Clause 3.1 MGW, SGW, PABX, ONU, ONT
P6.3 IPV4 Parameters Set-A Addressing RFC 791 Clause 3.2 MGW, SGW, PABX, ONU, ONT
P6.4 IPV4 Parameters Set-B Model of operation RFC 791 Clause 2.2 SBC
P6.5 IPV4 Parameters Set-B Gateways RFC 791 Clause 2.4 SBC
P6.6 IPV4 Parameters Set-B Interfaces RFC 791 Clause 3.3 SBC
P6.7 IPV4 Parameters Set-C Function Description RFC 791 Clause 2.3 SOFT SWITCH
P6.8 IPV4 Parameters Set-C Gateways RFC 791 Clause 2.4 SOFT SWITCH
P6.9 IPV4 Parameters Set-C Interfaces RFC 791 Clause 3.3 SOFT SWITCH
P6.10 Dual IP layer operation: Dual IP layer operation: Address RFC 4213 Clause 2.1 WiFi Access Point, WiFi CPE,
Address Configuration DSL NT Modem, ONU, ONT,
SBC, IP Terminal
Product should demostrate support
to all IPv6 services through
respective RFCs and clause
numbers.
All Product variants should
comply to either native IPv6 or
P6.11 Dual IP layer operation: Dual IP layer operation: DNS RFC 4213 Clause 2.2 SBC, IP Terminal, PON ONT
DNS
Product should demostrate support
to all IPv6 services through
respective RFCs and clause
numbers.
All Product variants should
comply to either native IPv6 or
Dual Stack test for PON devices.
P6.12 Dual IP layer operation: Dual IP layer operation: Tunnelling RFC 4213 Clause 3 WiFi Access Point, WiFi CPE,
Tunnelling DSL NT Modem, ONU, ONT,
OLT, MGW, LMGW, PABX,
SBC, Mobile Device, ONU, ONT,
CCN
Product should demostrate support
to all IPv6 services through
respective RFCs and clause
numbers.
All Product variants should
comply to either native IPv6 or
Dual Stack test for PON devices.
P7.1 IPV6 Header Parameters Header: Version Field RFC 2460 / Clause 3 SIP Terminal, SBC,
RFC 8200 Mobile Device, ONU,
ONT, CCN
P7.2 IPV6 Header Parameters Header: Traffic Class RFC 2460 / Clause 3 SIP Terminal, SBC,
RFC 8200 Mobile Device, ONU,
ONT, CCN
P7.3 IPV6 Header Parameters Header: Flow Label RFC 2460 / Clause 3 SIP Terminal, SBC,
RFC 8200 Mobile Device, ONU,
ONT, CCN
P7.4 IPV6 Header Parameters Header: Payload Length RFC 2460 / Clause 3 SIP Terminal, SBC,
RFC 8200 Mobile Device, ONU,
ONT, CCN
P7.5 IPV6 Header Parameters Header: No next header after RFC 2460 / Clause 3 SIP Terminal, SBC,
IPv6 Header RFC 8200 Mobile Device, ONU,
ONT, CCN
P7.6 IPV6 Header Parameters Header: Hop Limit RFC 2460 / Clause 3 SIP Terminal, SBC,
RFC 8200 Mobile Device, ONU,
ONT, CCN
P7.7 IPV6 Header Parameters Header: Source and RFC 2460 / Clause 3 SIP Terminal, SBC,
Destination Address RFC 8200 Mobile Device, ONU,
ONT, CCN
P7.8 IPV6 Extn. Header Parameters IPv6 Extension Header Order RFC 2460 / Clause 4.1 Mobile Device, ONU,
RFC 8200 ONT, CCN
P7.9 IPV6 Extn. Header Parameters IPv6 Extension Header Options RFC 2460 / Clause 4.2 Mobile Device, ONU,
RFC 8200 ONT, CCN
P7.10 IPV6 Extn. Header Parameters IPv6 Extension Header Hop by RFC 2460 / Clause 4.3 Mobile Device, ONU,
Hop Options RFC 8200 ONT, CCN
P7.11 IPV6 Extn. Header Parameters IPv6 Extension Header RFC 2460 / Clause 4.4 Mobile Device, ONU,
Routing RFC 8200 ONT, CCN
P8.1 DTMF Parameters Set-A RTP payload format for named RFC 4733 Clause 2 MGW,LMGW
telephones events
P8.2 DTMF Parameters Set-A Use of RTP header fields RFC 4733 Clause 2.2 MGW,LMGW
P8.3 DTMF Parameters Set-A Payload Format RFC 4733 Clause 2.3 MGW,LMGW
P8.4 DTMF Parameters Set-B DTMF: Applications RFC 4733 Clause 3.1 Soft Switch
P8.5 DTMF Parameters Set-B DTMF: Congestion RFC 4733 Clause 3.3 Soft Switch
Consideration
P8.6 DTMF Parameters Set-B DTMF: Events RFC 4733 Clause 3.2 Soft Switch
P8.7 DTMF Parameters Set-B DTMF: Payload Format RFC 4733 Clause 2.3 Soft Switch
P8.8 DTMF Parameters Set-B DTMF: RTP payload format for RFC 4733 Clause 2 Soft Switch
named telephones events
P8.9 DTMF Parameters Set-B DTMF: Specification of Events RFC 4733 Clause 3 Soft Switch
codes for DTMF events
P8.10 DTMF Parameters Set-B DTMF: Use of RTP header RFC 4733 Clause 2.2 Soft Switch
fields
P8.11 DTMF Parameters Set-C DTMF: Duration negotiation RFC 4733 Clause 2.3.5 PABX
P8.12 DTMF Parameters Set-C DTMF: Negotiation of Payload RFC 4733 Clause 2.5.1.1 PABX
P8.13 DTMF Parameters Set-C DTMF: Transmission of Event RFC 4733 Clause 2.5.1.2 PABX
Packet
P8.14 DTMF Parameters Set-C DTMF: Verification of RFC 4733 Clause 2.2.1 PABX
sequence no. and time stamp
P9.1 SCTP Parameters Set-A SCTP packet Format RFC 4960 Clause 3 MGW, LMGW, SGW
P9.2 SCTP Parameters Set-A SCTP common header field RFC 4960 Clause 3.1 MGW, LMGW, SGW
descriptions
P9.3 SCTP Parameters Set-A Chunk field descriptions RFC 4960 Clause 3.2 MGW, LMGW, SGW
P9.4 SCTP Parameters Set-A Optional/variable-length parameters RFC 4960 Clause 3.2.1 MGW, LMGW, SGW
format
P9.5 SCTP Parameters Set-A Reporting of unrecognized RFC 4960 Clause 3.2.2 MGW, LMGW, SGW
parameters
P9.6 SCTP Parameters Set-A SCTP association state diagram RFC 4960 Clause 4 MGW, LMGW, SGW
P9.7 SCTP Parameters Set-B User Data Fragmentation RFC 4960 Clause 1.5.3 SBC, Soft Switch
P9.8 SCTP Parameters Set-B Path Management RFC 4960 Clause 1.5.7 SBC, Soft Switch
P9.9 SCTP Parameters Set-B Transmission of DATA Chunks RFC 4960 Clause 6.1 SBC, Soft Switch
P9.10 SCTP Parameters Set-B Path Failure Detection RFC 4960 Clause 8.2 SBC, Soft Switch
P10.1 M3UA Parameters Procedures to Support the M3UA- RFC 3332 Clause 4.1 Soft Switch, SGW
User
P10.2 M3UA Parameters Establishment of Association and RFC 3332 Clause 5.1 Soft Switch, SGW
Traffic Between SGs and ASPs
P10.3 M3UA Parameters M3UA Port Number RFC 3332 Clause 7.2 Soft Switch, SGW
P10.4 M3UA Protocol M3UA Protocol Extensions RFC 3332 Clause 7.3 Soft Switch, SGW
Extensions Parameter
P10.5 Signalling Protocol Over Gateway Component Functions RFC2719 Clause 2.1 SGW
IP
P10.6 Signalling Protocol Over SS7 Interworking for Connection RFC2719 Clause 2.2 SGW
IP Control
P10.7 Signalling Protocol Over ISDN Interworking for RFC2719 Clause 2.3 SGW
IP Connection Control
P10.8 Signalling Protocol Over Architecture for Database Access RFC2719 Clause 2.4 SGW
IP
P11.1 IPV4 Parameters Set-D IPV4 Functional Tests RFC 791 Appendix-II, Test-5 LAN Switch, Router
P11.2 SNMPv2 Parameters SNMPv2 Functional Tests RFC 3416 Appendix-II, Test- LAN Switch, Router
38
P11.3 SNMPv3 Parameters SNMPv3 Functional Tests RFC 3410 Appendix-II, Test- LAN Switch, Router
39
P11.4 SNMPv2 or Qx Protocol SNMPv2 or Qx Protocol Appendix-II, Test-6 LAN Switch, Router
Parameters functional test
P11.5 SNMPv3 or Qx Protocol SNMPv3 or Qx Protocol Appendix-II, Test-7 LAN Switch, Router
Parameters functional test
P11.6 Dynamic Routing Dynamic Routing Functional Appendix-II, Test-8 Router, L3 switch
Tests
P11.7 Static Routing Static Routing Functional Tests Appendix-II, Test-9 Router, L3 switch
P11.8 TCP Parameters TCP Functional Tests RFC 793 Appendix-II, Test- Router
10
P11.9 Mac Learning & Pkt Fwdg Mac Learning and Packet Appendix-II, Test- LAN Switch
Forwarding 11
P11.10 Spanning Tree Protocol Test Spanning Tree Protocol Root IEEE 802.1d Appendix-II, Test- LAN Switch
Bridge Election Functional 12
Test
P11.11 Spanning Tree Protocol Test Spanning Tree Protocol Port IEEE 802.1d Appendix-II, Test- LAN Switch
Blocking Functional Test 13
P11.14 IPV6 Complete Suite RFC 2460 or 8200 RFC2460/82 Appendix-I, Table-3 Router, Security System
00
P11.15 IPV6 Complete Suite RFC 4861 RFC4862 Appendix-I, Table-4 Router, Security System
P11.16 IPV6 Complete Suite RFC 4862 RFC4862 Appendix-I, Table-5 Router, Security System
P11.17 IPV6 Complete Suite RFC 1981 RFC1981 Appendix-I, Table-6 Router, Security System
P11.18 IPV6 Complete Suite RFC 4443 RFC4443 Appendix-I, Table-7 Router, Security System
P11.19 BGP for IPv6 BGP for IPV6 RFC2545 Appendix-I, Table-8 MPLS, BNG/BRAS
Router
11
P11.23 IPSec Functional Test IPSec Functional Test Appendix-II, Test- IP Security System
16
P11.24 NAT Functional Test NAT Functional Test Appendix-II, Test- IP Security System
17, 18
P11.25 Policy Functional Test Policy Functional Test Appendix-II, Test- IP Security System
19
P11.26 IDS Functional Test IDS Functional Test Appendix-II, Test- IP Security System
20, 21
P11.27 IPS Functional Test IPS Functional Test Appendix-II, Test- IP Security System
22, 23
P11.28 UTM URL, Content & Anti- UTM URL, Content & Anti- Appendix-II, Test- IP Security System
Virus Filtering Functional Virus Filtering Functional Test 24, 25, 26
Test
P11.29 Profile for frequency Profile for frequency Appendix-II, Test- PTP GM
synchronisation synchronisation 27
P11.30 Profile for time and phase Profile for time and phase Appendix-II, Test- PTP GM
synchronisation with full synchronisation with full 28
timing support timing support
P11.31 Profile for time and phase Profile for time and phase Appendix-II, Test- PTP GM
synchronisation with partial synchronisation with partial 29
P11.32 PPPoE PPPoE Functional Test RFC2516 Appendix-II, Test- PON, Router
14
P11.38
Geometrical Mode Field Diameter at 1310 nm ITU-T G.652 and ITU-T G.650.1; 9.2 ± 0.4 µm
1
Characteristics IEC 60793-2-50 and IEC 60793-1-45
Cladding Diameter ITU-T G.652 and ITU-T G.650.1; 125 ± 0.7 µm
2
IEC 60793-2-50 and IEC 60793-1-20
Cladding Non-circularity ITU-T G.652 and ITU-T G.650.1; ≤ 0.8 %
3
IEC 60793-2-50 and IEC 60793-1-20
Core Clad concentricity error ITU-T G.652 and ITU-T G.650.1; ≤ 0.5 µm
4
IEC 60793-2-50 and IEC 60793-1-20
Coating diameter IEC 60793-2-50 and IEC 60793-1-21 242 ± 5 µm (uncolor);
5
252 ± 10µm (color)
6 Coating /Cladding concentricity IEC 60793-2-50 and IEC 60793-1-21 ≤ 12 µm
Transmission At 1310 nm ITU-T G.652 and ITU-T G.650.1; ≤ 0.34 dB/km
7
Characteristics IEC 60793-2-50 and IEC 60793-1-40
(Attenuation of At 1550 nm ITU-T G.652 and ITU-T G.650.1; ≤ 0.20 dB/km
8
uncabled fibre) IEC 60793-2-50 and IEC 60793-1-40
At 1490 nm ITU-T G.652 and ITU-T G.650.1; ≤ 0.24 dB/km
9
IEC 60793-2-50 and IEC 60793-1-40
At 1270 nm ITU-T G.652 and ITU-T G.650.1; ≤ 0.40 dB/km
10
IEC 60793-2-50 and IEC 60793-1-40
At 1625 nm ITU-T G.652 and ITU-T G.650.1; ≤ 0.23 dB/km
11
IEC 60793-2-50 and IEC 60793-1-40
12 Water peak attenuation at 1380 to ITU-T G.652 and ITU-T G.650.1; ≤ 0.34 dB/km
1390 nm IEC 60793-2-50 and IEC 60793-1-40
13 Sudden irregularity in attenuation Telcordia GR-20-CORE,2013 and ≤ 0.1 dB
IEC 60793-1-40
Change in attenuation when fiber ITU-T G.652 ,ITU-T G.650.1, IEC ≤ 0.05 dB at 1310 nm
25 is coiled with 100 turns on 50 ±0.5 60793-2-50 and IEC 60793-1-47
mm diameter mandrel
Mechanical Proof test for minimum strain level ITU-T G.652, G.650.1 and IEC 1%
26
Characteristics 60793-2-50, 60793-1-30
Dynamic Tensile Strength IEC 60793-2-50 and IEC 60793-1- ≥ 440 KPSI (3.00Gpa)
29
Aged (Damp heat aged) 31
Dynamic Fatigue IEC 60793-2-50 and IEC 60793-1-33 ≥ 20
30
(Unaged and Damp heat aged)
31 Fiber Curl IEC 60793-2-50, 60793-1-34 ≥ 4 Meter radius of curvature
Environmental Temperature Cycle Test: IEC 60793-2-50 and IEC 60793-1-52 ≤ 0.05 dB/Km
Characteristics Temperature Dependence of
32 of Fiber for Attenuation: Induced Attenuation at
both color and 1550 nm and 1625 nm at -60°C to
uncolor fibres +85°C
Temperature-Humidity Cycle Test: EIA/TIA 455-73 ≤ 0.05 dB/Km
Induced attenuation at 1550 nm and
33
1625 nm at -10C TO +85°C and
95% relative humidity
Water Immersion Test: Induced IEC 60793-2-50 and IEC 60793-1-53 ≤ 0.05dB/Km
attenuation at 1550 nm and 1625
34
nm due to water immersion at 23 ±
2°C
Accelerated Aging (Dry Heat) Test: IEC 60793-2-50 and IEC 60793-1-51 ≤ 0.05 dB/Km
Induced attenuation at 1550 nm and
35
1625 nm due to Temperature aging
at 85 ± 2° C
36 Retention of Coating Color:
Coated fibre aged for 30 days at
85℃ temperature with 95% IEC 60793-2-50 and IEC 60793-1-51 No change in colour of coated fibre
Humidity and then 20 days in 85℃
dry heat
12 Dispersion slope at 1550 nm ITU-T G.655, G.650.1 and ≤ 0.09 ps/(nm2 Km)
IEC 60793-2-50, 60793-1-42
30 Cable Material Compatibility test Telcordia GR-20-CORE,2013; Draft • Aged coating strip force:
for fibre : Fibre to be aged with IEC 60794-1-219 1.0 ≤ F ≤ 8.9 N (Peak)
filling compound for 30 days at 1.0 ≤ F ≤ 5.0 N (Average)
85℃ temperature and 85% Relative • Visual Inspection under 5X
Humidity magnification:
No fibre coatings cracking,
splitting, or delamination.
• For coloured fibres, colour to be
identifiable and no colour
transfers to the filling compound.
• MEK Rub Test as mentioned
34 Material Fiber Materials: RoHS 3 (EU 2015/863) Fibre material to be RoHS complied.
Properties : The substances of which the fibres
are made
Environmental Temperature Cycle Test: IEC 60793-2-50 and IEC ≤ 0.05 dB/Km
Characteristics Temperature Dependence of 60793-1-52
of Fiber for Attenuation : Induced Attenuation
32
both color and at 1550 nm and 1625 nm at -60°C
uncolor fibres to +85°C
Environmental Temperature Cycle Test: IEC 60793-2-50 and IEC 60793-1-52 ≤ 0.05 dB/Km
Characteristics Temperature Dependence of
33 of Fiber for Attenuation : Induced
both color and Attenuation at 1550 nm and
uncolor fibres 1625 nm at -60°C to +85°C
Temperature-Humidity Cycle EIA/TIA 455-73 ≤ 0.05 dB/Km
Test: Induced attenuation at
34 1550 nm and 1625 nm at -10° C
TO +85° C and 95% relative
humidity
Water Immersion Test: Induced IEC 60793-2-50 and IEC 60793-1-53 ≤ 0.05dB/Km
attenuation at 1550 nm and 1625
35
nm due to water immersion at 23
± 2°C
36 Accelerated Aging (Dry Heat) IEC 60793-2-50 and IEC 60793-1-51 ≤ 0.05 dB/Km
Test: Induced attenuation at
1550 nm and 1625 nm due to
Temperature aging at 85 ± 2° C
37 Retention of Coating Color:
Coated fibre aged for 30 days at
85℃ temperature with 95% IEC 60793-2-50 and IEC 60793-1-51 No change in colour of coated fibre
Humidity and then 20 days in
85℃ dry heat
38 High Temperature and High
IEC 60793-2-50 and IEC 60793-1-50 ≤ 0.05 dB/Km
Humidity (Damp Heat) Test:
Dynamic Tensile Strength IEC 60793-2-50 and IEC 60793-1-31 ≥ 550 KPSI (3.80Gpa)
19
(Un aged)
Dynamic Tensile Strength IEC 60793-2-50 and IEC 60793-1-31 ≥ 440 KPSI (3.00Gpa)
20
Aged (Damp heat aged)
Dynamic Fatigue IEC 60793-2-50 and IEC 60793-1-33 ≥ 20
21 (Unaged and Damp heat aged)
Water Immersion Test: Induced IEC 60793-2-50 and IEC 60793-1-53 ≤ 0.05dB/Km
attenuation at 1550 nm and 1625 nm
25
due to water immersion at 23 ± 2°C
Accelerated Aging (Dry Heat) Test: IEC 60793-2-50 and IEC 60793-1-51 ≤ 0.05 dB/Km
Induced attenuation at 1550 nm and
26 1625 nm due to Temperature aging
at 85 ± 2° C
29 Cable Material Compatibility test for Telcordia GR-20-CORE,2013; • Aged coating strip force:
fibre : Fibre to be aged with filling Draft IEC 60794-1-219 1.0 ≤ F ≤ 8.9 N (Peak)
compound for 30 days at 85℃ 1.0 ≤ F ≤ 5.0 N (Average)
temperature and 85% Relative • Visual Inspection under 5X
Humidity magnification:
No fibre coatings cracking,
splitting, or delamination.
• For coloured fibres, colour to be
identifiable and no colour
transfers to the filling
compound.
• MEK Rub Test as mentioned
Appendix-I
First, a Hello Packet may be received from a neighbour claiming to be itself the Backup Designated Router.
Alternatively, a Hello packet may be received from a neighbour claiming to be itself the Designated Router, and
9.2 indicating that there is no Backup Designated Router. In either case there must be bidirectional communication
with the neighbour, i.e., the router must also appear in the neighbour’s Hello Packet. This event signals an end to
the Waiting state.
In some cases (e.g., the state of the receiving interface is DR and the LSA was received from a router other than
13(5b)
the Backup DR) the LSA will be flooded back out the receiving interface
Circumstances:- LSA is more recent than database copy, but was not flooded back out receiving interface.
13.5 Backup:- Delayed acknowledgment sent if advertisement received from Designated Router, otherwise do nothing.
All other States:- Delayed acknowledgment sent.
If there is already a database copy, and if the database copy was received via flooding and installed less than
13(5a) MinLSArrival seconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any)
listed in the Link State Update packet.
The OSPF packet header is verified. The fields specified in the header must match those configured for the
8.1 & 8.2
receiving interface. If they do not, the packet should be discarded
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
3.1.3 The Interface ID that the neighbour advertises in its Hello Packets must be recorded in the neighbour structure.
The router will include the neighbour’s Interface ID in the router's router-LSA when either a) advertising a point-
to-point link to the neighbour or b) advertising a link to a network where the neighbour has become Designated
Router.
A.3.2 All routers connected to a common link must agree on certain parameters (HelloInterval and
RouterDeadInterval). These parameters are included in Hello packets, so that differences can inhibit the forming
of neighbour relationships. The Hello packet also contains fields used in Designated Router election (Designated
Router ID and Backup Designated Router ID), and fields used to detect bi-directionality (the Router IDs of all
neighbours whose Hellos have been recently received).
3.2.2 The receiving router must be an area border router, and the Router ID specified in the packet (the source router)
must be the other end of a configured virtual link. The receiving interface must also attach to the virtual link's
configured Transit area. If all of these checks succeed, the packet is accepted and is from now on associated with
the virtual link (and the backbone area).
3.2.2 The fields specified in the header must match those configured for the receiving interface. If they do not, the
packet should be discarded
3.4.3.1 Consider the router-LSA that router RT3 would originate for Area 1 in Figure 1. Only a single interface must be
described, namely that which connects to the transit network N3. It assumes that RT4 has been elected
Designated Router of Network N3
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times
4.1
in the same packet,
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that
must be taken if the processing IPv6 node does not recognize the Option Type:
4.2 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an
ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized
Option Type.
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that
4.2 must be taken if the processing IPv6 node does not recognize the Option Type:
01 - discard the packet.
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that
must be taken if the processing IPv6 node does not recognize the Option Type:
4.2 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast
address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the
unrecognized Option Type.
If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the
4.4
packet, whose type is identified by the Next Header field in the Routing header.
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
A router MUST silently discard any received Router Solicitation messages that do not satisfy all of the following
validity checks:
6.1.1
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a
router.
A node MUST silently discard any received Router Advertisementmessages that do not satisfy all of the
following validity checks:
6.1.2
- The IP Hop Limit field has a value of 255, i.e., the packetcould not possibly have been forwarded by a
router.
6.2.2 A router MUST NOT send Router Advertisements out any interface that is not an advertising interface.
A node MUST silently discard any received Neighbour Solicitation messages that do not satisfy all of the
following validity checks:
7.1.1
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a
router.
node MUST silently discard any received Neighbour Advertisementmessages that do not satisfy all of the
following validity checks:
7.1.2
- The IP Hop Limit field has a value of 255, i.e., the packetcould not possibly have been forwarded by a
router.
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
In order to improve the robustness of the Duplicate Address Detectionalgorithm, an interface MUST receive and
process datagrams sent tothe all-nodes multicast address or solicited-node multicast addressof the tentative
5.4.2
address during the delay period. This does notnecessarily conflict with the requirement that joining the multicast
group be delayed.
Duplicate Address Detection MUST NOT be performed on anycastaddresses (note that anycast addresses cannot
5.4
syntactically bedistinguished from unicast addresses).
A node MUST silently discard any received Neighbour Solicitationmessages that do not satisfy all of the
following validity checks:
7.1.1
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a
router.
The contents of the Reserved field, and of any unrecognized options,MUST be ignored. Future, backward-
7.1.1 compatible changes to the protocol may specify the contents of the Reserved field or add new options;backward-
incompatible changes may use different Code values.
A node MUST silently discard any received Neighbour Advertisementmessages that do not satisfy all of the
following validity checks:
7.1.2
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a
router.
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
A node may receive a Packet Too Big message reporting anext-hop MTU that is less than the IPv6 minimum link
4 MTU. In thatcase, the node is not required to reduce the size of subsequentpackets sent on the path to less than
the IPv6 minimum link MTU,
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
(a) If the message is a response to a message sent to one of thenode's unicast addresses, the Source Address of the
2.2
reply MUST bethat same address.
If the message is a response to a message sent to any otheraddress, such as
- a multicast group address,
- an anycast address implemented by the node, or
- a unicast address that does not belong to the node;
the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node
2.4 If an ICMPv6 informational message of unknown type is received,it MUST be silently discarded.
An ICMPv6 error message MUST NOT be originated as a result ofreceiving the following:
2.4
(e.3) A packet destined to an IPv6 multicast address.
An ICMPv6 error message MUST NOT be originated as a result ofreceiving the following:
2.4 (e.6) A packet whose source address does not uniquely identify asingle node -- e.g., the IPv6 Unspecified
Address, an IPv6multicast address, or an address known by the ICMP messageoriginator to be an IPv6
anycast address.
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common
subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field
3 and the peer the route is being advertised to In all other cases a BGP speaker shall advertise to its peer in the
Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address
of Next Hop field shall be set to 16)
The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common
subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field
3 and the peer the route is being advertised to In all other cases a BGP speaker shall advertise to its peer in the
Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address
of Next Hop field shall be set to 16)
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker SHALL
9.2
NOT re-distribute the routing information contained in that UPDATE message to other internal peers
if the Length field of the message header is less than 19 or greater than 4096,then the Error Subcode MUST be
6.1
set to Bad Message Length. The Data field MUST contain the erroneous Length field.
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected,
6.3 the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data
field MUST contain the attribute (type, length, and value)
If the Marker field of the message header is not as expected, then a synchronization error has occurred and the
6.1 Error Subcode MUST be set to Connection Not Synchronized, if the Length field of an OPEN message is less
than the minimum length of the OPEN message
Upon receipt of an OPEN message, the local system MUST examine all of its connections that are in the
6.8 OpenConfirm state
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
If a BGP speaker receives from a neighbour an Update message that contains the MP_REACH_NLRI or
MP_UNREACH_NLRI attribute, and the speaker determines that the attribute is incorrect, the speaker MUST
7
delete all the BGP routes received from that neighbour whose AFI/SAFI is the same as the one carried in the
incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute
If a BGP speaker receives from a neighbour an Update message that contains the MP_REACH_NLRI or
MP_UNREACH_NLRI attribute, and the speaker determines that the attribute is incorrect, the speaker MUST
7
delete all the BGP routes received from that neighbour whose AFI/SAFI is the same as the one carried in the
incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute
If a BGP speaker receives from a neighbour an Update message that contains the MP_REACH_NLRI or
MP_UNREACH_NLRI attribute, and the speaker determines that the attribute is incorrect, the speaker MUST
7
delete all the BGP routes received from that neighbour whose AFI/SAFI is the same as the one carried in the
incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute
An LDP Identifier is a six-octet quantity used to identify an LSR label space. The first four octets identify the
2.2.2
LSR and must be a globally unique value, such as a 32-bit router Id assigned to the LSR.
2.5.2 An LSR MUST advertise the same transport address in all Hellos that advertise the same label space
After an LDP session has been established, an LSR must arrange that its peer receive an LDP PDU from it at
2.5.6
least every KeepAlive timeperiod to ensure the peer restarts the session KeepAlive Timer
When the next hop for a prefix changes, the LSR must retrieve the label advertised by the new next hop from the
2.7
LIB for use in forwarding.
2.8.1 The Label Request message MUST include a Hop Count TLV.
Note: Wherever a particular IP test is implemented in a product through a RFC different from what is mentioned in ER, please obtain
confirmation from Helpdesk before submitting application.
Parameter Name Frequency and EIRP for Wi-Fi and Point to Point/ Point to Multipoint Radio Interface
Test Details Frequency of Operation and Peak Power Measurement Test Setup
Test instruments Spectrum Analyzer
required
Test Setup
EUT
PoE
Note: This is a representative setup and may be adapted as per the requirement of testing for the equipment.
Parameter Name Frequency of Operation and Transmit Power for Satellite Equipment
Test Details Typical setup of Frequency of Operation & Transmit Power measurement for Satellite System Equipment
Test instruments Signal Generator
required Spectrum Analyser
Attenuator
Power Meter
Power Supply
Test Setup
Power Meter
Power Supply
EUT
Signal Generator
Attenuator Spectrum Analyser
Test Procedure 1. For measurement of Transmit Power, Power Meter is to be connected to the Equipment Under Test(EUT).
2. For measurement of Frequency of Operation, Spectrum Analyser (with DC block if required) is to be connected
to the EUT.
Note: This is a representative setup and may be adapted as per the requirement of testing for the equipment.
Control
Port(s)
Control
Computer
EUT
Power Antenna
Ports Port(s)
Attenuator Power Meter
Power Supply
Test Procedure 1. For measurement of Transmit Power, Power Meter is to be connected to the Equipment Under Test (EUT).
Note: This is a representative setup and may be adapted as per the requirement of testing for the equipment.
Test No.4
Parameter Name Link Speed and Auto-negotiation FE, Link Speed and Auto-negotiation GE
Test Setup
EUT Ethernet Tester
Test Procedure 1. Connect the Ethernet Tester to the applicable/ supported Ethernet interface of the EUTas shown above.
2. Configure the EUT to use auto-negotiation on its selected Ethernet port.
3. Configure the Ethernet Tester to run at 100 mbps speed and see if it is able to connect to the EUT. The
Ethernet link between the Ethernet Tester and EUT should be active and report 100mbps link speed (if link
speed 100 mbps is supported by the EUT).
4. Configure the Ethernet Tester to run at 1000 mbps speed and see if it is able to connect to the EUT. The
Ethernet link between the Ethernet Tester and EUT should be active and report 1000mbps link speed. (if link
speed 1000 mbps is supported by the EUT).
Expected Results 1. The Ethernet link between the Ethernet Tester and EUT should be active and report 100 or 1000 mbps link
speed as per the link speed supported by the EUT
Test Setup
EUT
Subnet Subnet
a b
IP Testing Tool IP Testing Tool
Test Procedure 1. Connect the IP Testing Tool to the Ethernet interface of the router as shown above.
2. Configure the IP interfaces of the EUT and IP Testing Tool for back-to-back communication from/ to IP
Testing Tool.
3. Configure static/ dynamic routing on the EUT to reach local LAN subnets from the IP Testing Tool.
4. Perform IPv4 ping test from IP Testing Tool to IP Testing Tool and verify that it is successful and that there is
no packet drop.
5. Perform file transfer test from IP Testing Tool to IP Testing Tool and verify that it is successful.
Expected Results 1. IPv4 Ping test should be successful with zero packet loss.
2. File transfer test should be successful.
3. Enclose screenshots and IP Testing Tool traces of the IPV4 communication.
For Qx,
1) Configure the EUT to run Qx agent and NMS (PC) to run Qx manager application by using correct
parameters.
2) Testing of TRAP message: The NMS uses Qx to manage the Qx agent, and the agent automatically sends
Expected Results 1.) TRAP should be sent by EUT (Agent) to Testing Node (SNMP or Qx Manager).
2.) Set Request operation should be able to set SysName object in agent (EUT), or Write operation should be
able to set Name in Qx agent (EUT),
3.) GetRequest operation should be able to get SysName Object from agent(EUT)
Read operation should be able to get Name Object from Qx agent(EUT)
For Qx
• Configure the agent on EUT and Qx manager on PC/NMS to use Qx with security level setting to
AuthPriv. Set SSH between EUT and NMS to enable authentication and encryption.
• The NMS uses Qx to monitor and manage the agent
• The agent automatically sends notifications to report events to the NMS.
• The NMS and the agent perform authentication when they establish an Qx session based on SSH. The
NMS and the agent encrypt the packets by using SSH
Test Setup
EUT
Test Procedure 1. Connect the interface as the case may be, as shown in the setup diagram
2. Connect the Testing Tool to the Ethernet interface of the EUT as shown above.
3. Configure the IP interfaces of the EUT and Testing Tool for back-to-back communication between two ports
of Testing Tool.
4. Verify that no static or dynamic routing table entry exists on the EUT and that ping to the WAN port of
Testing Tool is not working through LAN Port of Testing Tool.
5. Configure Dynamic Routing (OSPFv2) on the EUT to reach each subnet from other subnet using dynamic
routing. Static routing should NOT be used in this case.
6. Perform back-to-back ping test from Testing Tool through EUT and verify that it is successful and that there
is no packet drop.
7. Verify the existence of dynamic routing table entry of remote LAN subnet on the EUT using dynamic routing.
Expected Results 1. There should be routing table entry of the remote LAN subnet on the EUT using dynamic routing protocol
(OSPF).
2. The ping test should be successful to the remote LAN subnet IP address.
Test Setup
EUT
Test Procedure 1. Connect the interface as the case may be, as shown in the setup diagram
2. Connect the Testing Tool to the Ethernet interface of the EUT as shown above.
3. Configure the IP interfaces of the EUT and Testing Tool for back-to-back communication between two ports
of Testing Tool.
4. Verify that no static or dynamic routing table entry exists on the EUT and that ping to the WAN port of
Testing Tool is not working through LAN Port of Testing Tool.
5. Configure static routing on the EUT to reach each subnet from other subnet.
6. Perform ping test from back-to-back ping test from Testing Tool through EUT and verify that it is successful
and that there is no packet drop.
7. Verify the existence of routing table entry of remote LAN subnet on the EUT using static routing.
Expected Results 1. There should be routing table entry of the remote LAN subnet on the EUT using static route.
2. The ping test should be successful to the remote LAN subnet IP address.
Test Setup
EUT
Test Procedure 1. Connect the Testing Tool to the Ethernet interface of the router as shown above.
2. Configure the Testing Tool and the EUT for back-to-back communication between two ports of Testing Tool.
3. Configure static/ dynamic routing on the EUT to reach each subnet from other subnet.
4. Install/ ensure availability of FTP server and FTP client on Testing Tool for performing file transfer test.
5. Perform file transfer test between the two ports of Testing Tool and verify that it is successful through EUT as
per the above-mentioned setup.
6. The EUT must also support TELNET functionality. Configure the EUT to support telnet on its local IP
address.
7. Connect to the EUT using telnet from Testing Tool to verify that telnet connection is established and EUT can
be configured remotely using telnet sessions.
8. Capture packets at various stages to verify functionality of Sequence Numbers and TCP Header Formats.
Expected Results 1. File transfer test should be successful.
2. Telnet connection to EUT from Testing Tool should be successful.
3. Enclose screenshots and Testing Tool traces of the communication, and indicate various Headers and
Sequence Numbers.
Test Setup
EUT
Test Procedure 1. Connect Interface-A of Testing Tool with EUT and ping EUT.
2. Ensure MAC address of Interface-A of Testing Tool is visible in EUT’s MAC address table and Interface-B
MAC address is not visible. (e.g. show mac-add).
3. Connect Interface-B of Testing Tool to EUT and ping Testing Tool through Interface-A. Ping should be
successful.
4. Check EUT’s MAC address table. MAC address of Interface-B of Testing Tool should be visible in table.
Expected Results 1. Ping from Interface-B to Interface-A should be successful, showing successful packet forwarding.
2. MAC address should be visible on EUT’s MAC table.
3. Enclose screenshot for successful test.
Parameter Name Spanning Tree Protocol Root Bridge Election Functional Test
Test Details Test for Spanning tree protocol (STP) – Root Bridge Election
Test Setup
192.168.1.1
wan link 192.168.1.3
wan link
Test Procedure 1. Enable STP (802.1d) at both EUT and other switch, keeping priority value the same.
2. Verify from C-BPDU from Testing Tool that it contains information about bridge id (Priority/ MAC
Address).
3. Depending on computed bridge id, Verify from C-BPDU messages that EUT either becomes the Root Bridge,
or allows the other switch to become Root Bridge.
Expected Results 1. The switch, which has the lowest root bridge ID, will be elected as the root bridge.
2. Attach screenshot and Testing Tool traces as artefacts.
Test Details Test for Spanning tree protocol (STP) – Port Blocking
Test Setup
Port 3
EUT Another Switch-B
Port 5
192.168.1.1
wan link 192.168.1.3
wan link
Test Steps 1. Start the PPPoE client emulation from test tool.
2. Verify that PADI was received on the box by using CLI
3. Check that authentication was successful by using CLI
4. Issue show PPPoE statistics again to see that DUT has sent PADO, received PADR and send PADS packet by using
CLI. (Note: since subscriber bring up happens very fast you might be able to see all the packet count in step 2 itself.)
5. Check on DUT to see that subscriber has come up by executing CLIs
6. Stop the PPPoE client emulation from test tool.
7. Check that PADT message was received on the DUT using CLI
8. Check that subscriber entry has been cleared from the DUT using CLI
Expected Results 1. For Step 2, CLI output contains correct PADI packet count.
2. For Step 3, Authentication is granted.
3. For Step 4, CLI output contains correct PADO, PADR and PADS packet count.
4. For Step 5, CLI contains correct subscriber count and state.
5. For Step 6, PADT is received on the DUT after PPPoE client emulation is stopped in the test tool.
6. For Step 8, CLI output returns subscriber count as 0
Pre-Test Setup
Linux 1 EUT Peer Linux 2
And
Test Setup 1. Configure IKE and IPsec under Security configuration options on both DUT and PEER devices.
2. To route the required traffic through the tunnel, add the configured VPN under the required policy on both DUT and
PEER devices
3. If DUT needs to be act as Initiator, then configure establish tunnel immediately only at the DUT side
4. If DUT needs to be act as responder, then configure establish tunnel immediately only at the PEER side
Test Case Steps 1. Send ping traffic from Linux1 to Linux2 or Linux2 to Linux1
2. Verify fields under security IPsec /IKE CLI
Expected Results 1. If Establish tunnel immediately is configured:
a. As soon as configuration gets committed verify P1 and P2 SA is up on both the devices.
b. role (initiator or responder) should be proper under ike cli based on the configuration on both the devices
c. There should not be any ping packet drop
d. packet statistics under ipsec cli should match with actual sent traffic.
e. configured Policy through which tunnel is formed should be visible in ipsec sa cli
2. If Establish tunnel on-traffic is configured (default configuration if nothing is configured)
a. There will be one ping packet drop and packet statistics should match accordingly under ipsec cli
b. P1 and P2 SA should be up on both the devices
c. role (initiator or responder) should be proper under ike cli based on traffic
d. configured Policy through which tunnel is formed should be visible in ipsec sa cli
Test No.17
Parameter Name Test Source NAT with PAT with multiple source ip addresses.
Pre-Test Setup
Linux Client EUT Linux Server
And
Test Setup 1. Install hping2 on Linux Client to initiate traffic from multiple source addresses
2. On Linux server, add route for nat-pool address used in nat configuration on DUT
3. Configure source nat pool on DUT with single IP address
4. Configure source nat rule-set on DUT with ‘from’ and ‘to’ and also match condition like ‘source-address’ and
‘destination-address’
Note:PAT is enabled by default
Test Case Steps 1. Start sending traffic with hping2 tool from Linux client with first IP to Linux server IP address
2. Again, Initiate hping2 by incrementing the source IP in ‘source-ip’ field
Expected Results 1. For Step 1, verify that cli output of flow session shows nat-translation. Test considered pass if the source address is
natted with the address from the pool specified.
2. Also, check source nat-translation hit count is incrementing in cli output
3. For step 2, Verify that port address translation is seen in cli output of security flow session
Pre-Test Setup
And
Linux Client Linux Server
Test Setup EUT
(IPv6 Host) (IPv4 Host)
1. To configure NAT64, you need to have a pool of single IPs which will be the IPv4 address of the server.
2. We need a destination NAT configuration to translate the IPv6 address into IPv4 address in the destination field of
the incoming packet.
3. The destination address is IPv4, but the source address is IPv6. Thus, we must apply the source NAT in order to
change the IPv6 address to IPv4 in the source field of the packet.
Test Case Steps 1. Initiate traffic from Linux client
2. Verify nat translation has worked by checking flow session on DUT
Expected Results 1. Check how the sessions are being established:
Parameter Name Verify Source Address any, destination specific, application any action = deny
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
Test Case Steps 1. Configure security zones and add interfaces to it.
2. (Ex: Configure a security zone “trust” and add the interface connected to one of the linux machines to it. Configure
another security zone “untrust” and add router’s other interface to it.)
3. Create address book entries to specify the source and destination address.
4. Create a policy (say p1) from zone trust to zone untrust and vice-versa, with source address any name, destination
address as address book name, application any.
5. Set a deny condition for the policy.
6. (For ex: set security policies from-zone trust to-zone untrust policy p1 then deny)
7. Commit the configuration.
8. Send traffic from H0 to H1.
Expected Results 1. Traffic should not be allowed due to the deny policy.
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
Parameter Name Close Client and Server Action for TCP in IPS Rule Base
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
Parameter Name Close Client Action for UDP in IPS Rule Base
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
1. Configure UTM custom objects for file extension list such as vbs, pl, tst
2. Configure the UTM content filtering feature profile with the block-extension for those file extension list
3. Configure notifications options as message and content for the message
4. Attach the profile to the fw policy.
5. Configure the security logging
Test Case Steps 1. Start the HTTP server and have the files with different extension
2. From client get vbs, pl, txt and html files using curl
Expected Results 1. Other than html file all are blocked
2. In the utm content filtering statistics, the extension blocked counter should increment accordingly
3. Verify the content filtering blocked message in the syslog
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
1. Configure UTM custom objects for filename extension list for com and exe
2. Configure the UTM content filtering feature profile with the block-extension for those filename extension list
3. Configure content filtering UTM policy for ftp upload and download
4. Configure notifications options as message and content for the message
5. Attach the profile to the fw policy.
6. Configure the security logging
Test Case Steps 1. Start the FTP server and have the files with different extension
2. From client, do ftp and get exe and com extension files
3. From client do ftp and put exe and com extension files
Expected Results 1. GET and PUT of exe and com files are blocked with proper error message
2. In the utm content filtering statistics, the Base on extension list counter should increment accordingly
3. Verify the content filtering blocked message in the syslog
Pre-Test Setup
And H0 H1
EUT
Test Setup (Linux) (Linux)
Internet
1. DUT should have internet access through one of the revenue interfaces
2. Sophos license should be installed
3. Sophos av is configured and the pattern is up to date
4. Configure Sophos anti-virus profile for http, ftp up/down, smtp, pop and imap
5. Attach the profile to the utm policy
6. Attach the utm policy to the fw policy
Test Case Steps 1. Send the following traffic with the virus file attached (HTTP GET/POST, FTP GET/PUT, SMTP, IMAP and POP3)
Expected Results 1. The virus file should be blocked with the proper error message
2. The virus file should be detected and the threat-found incremented in the anti-virus statistics
3. Verify the av virus detected message in the syslog
Test Details Support for PTP frequency profile: G.8265.1 & monitor
1) PTP messages exchanged between Master & Slave
2) Protocol statistics of GM for e.g. GM IP, GM Identity, GM clock class & value etc.
3) GM locking with auxiliary interfaces and observe relevant protocol statistics.
Test instruments Synch tester Splitter
required
GPS Antenna Connecting Cables
Laptop
Test Setup 2
3. After configuring PTP GM with correct Frequency profile setting (through CLI & GUI). Configure the Sync Tester
with same parameters & connect the Tester to the configured PTP port on GM.
4. Verify: if PTP GM has ping option & able to ping Tester’s IP. Also verify if VLAN tagging is possible on PTP
messages.
5. Verify: If GM is sharing all the relevant protocol information to the Tester for e.g.
i) GM IP
Parameter Name Profile for time and phase synchronisation with full timing support
PTPGM
G8275.1
Test Setup 2
Test Procedure 1. Connect GNSS signal to PTP GM and Tester. Wait for sufficient (approx. 1-2 hours) time so that GM and Tester are
locked to UTC.
2. Now, configure PTP GM as per the settings mentioned below:
3. After configuring PTP GM with correct Phase profile (full on-path) setting (through CLI & GUI). Configure the
Sync Tester with same parameters & connect the Tester to the configured PTP port on GM.
4. Verify: if VLAN tagging is possible on the PTP messages.
5. Verify: If GM is sharing all the relevant protocol information to the Tester for e.g.
i) GM MAC
ii) GM Identity
Parameter Name Profile for time and phase synchronisation with partial timing support
PTPGM
G8275.2
Test Setup 2
Test Procedure 1. Connect GNSS signal to PTP GM and Tester. Wait for sufficient (approx. 1-2 hours) time so that GM and Tester
are locked to UTC.
2. Now, configure PTP GM as per the settings mentioned below:
3. After configuring PTP GM with correct Phase profile (partial on-path) setting (through CLI & GUI). Configure the
Sync Tester with same parameters & connect the Tester to the configured PTP port on GM.
4. Verify: if PTP GM has ping option & able to ping Tester’s IP. Also verify if VLAN tagging is possible on the PTP
messages.
5. Verify: If GM is sharing all the relevant protocol information to the Tester for e.g.
i) GM IP
ii) GM Identity
Test Details Test for Identification of Equipment Identity for mobile device for GSM/ UMTS/ LTE/ CDMA
Test Procedure 1 1. Switch on the mobile so that the screen is lit. If there is a screen protector (wallpaper), invoke it. If there is a
screen lock, invoke it to lock the screen.
2. Switch off screen display.
3. Short Press power-on button thrice in quick succession.
4. Disconnect the call if invoked.
5. With screen protector and screen lock invoked and screen display switched on, repeat step 3 and 4.
Test Procedure 2 1. Switch on the mobile screen. If there is a screen protector (wallpaper), remove it. If there is a screen lock, invoke
it to lock the screen.
2. Check if a Soft emergency call button is visible even in screen lock mode.
3. Invoke emergency call by touching it.
4. Disconnect the call if invoked.
Test Procedure 3 1. Switch on the mobile screen. If there is a screen protector (wallpaper), invoke it. If there is a screen lock, invoke
it to lock the screen.
2. Switch off screen display.
3. Press panic (red) button for more than 3 seconds
4. Disconnect the call if invoked.
Expected Results 1. Wallpaper ON + Screen Lock ON + Screen Off + Short press power on button thrice => Emergency call
2. Wallpaper ON + Screen Lock ON + Screen Lit + Short press power on button thrice => Emergency call
3. Wallpaper Off + Screen Lock ON + Screen Lit + Softemergency call button touch => Emergency call
4. Wallpaper ON + Screen Lock ON + Screen Off + Long press panic (red) button once => Emergency call
Test Details Test for facility of identifying the location through satellite-based GPS in smart phone handsets.
Test Details Test for facility to dial 112 with Keypad lock, without SIM or without registration on PLMN.
Test Procedure 1 1. Switch on the mobile screen. If there is a screen protector (wallpaper), remove it. If there is a screen lock, invoke
it to lock the screen.
2. Check if either keypad, or an icon/ link to display the keypad is visible. In case of later, click icon/ link to
display keyboard.
3. Invoke emergency call by dialing 112.
4. Disconnect the call if invoked.
Test Procedure 2 1. Remove SIM from mobile. Switch on the mobile. If there is a screen protector (wallpaper), remove it. If there is
a screen lock, invoke it to lock the screen.
2. Repeat steps 2, 3 and 4 of Procedure 1.
Test Procedure 3 1. Insert test SIM and switch ON mobile.
2. Verify that mobile is trying to be registered to some available PLMN.
3. Repeat procedure 2 with test SIM.
Expected Results 1. It is possible to dial the emergency number 112 even if the key pad is locked, as verified through Procedure 1.
2. It is possible to dial the emergency number 112 without SIM, as verified through Procedure 2.
3. The mobile phone, which has not successfully registered shall nevertheless be able to make emergency call
attempts on an available PLMN, as verified through Procedure 3.
Expected Result Check that SAR Value is less than 1.6 W/Kg.
Test No.36
Test Instruments Base Station Emulator, Signal generator, spectrum analyser, required software
required
Test Setup Powered on EUT
Test Procedure 1. Check that the frequency of operation as per its data sheet/ information given by the vendor is as per the
Applicable National Frequency Allocation Plan
2. If the step 1 above is okay, then -
a. Put the Device Under Test (DUT) in Airplane or Switch Off mode.
b. Configure Base Station Emulator for required frequency and technology.
c. Switch on the DUT and initiate a call.
d. Check that the DUT is connected to the Base Station Emulator and that the call goes through.
Test Procedure 1 i) Input all the characters of English language one by one and check that the displayed character matches with the
character typed on keypad.
ii) Repeat above step i) for Hindi.
iii) Repeat above step i) for any other (at-least one) Indian Language as declared by the manufacturer.
Test Procedure 2 i) Input all the characters of English language to make a text in a computer/ Laptop and using Data Card/ Dongle
through SMS Application send it to the DUT.
ii) Read and compare the text character by character to see that the sent message and the received message are the
same.
iii) Repeat above step for Hindi and all (twenty-one) other Indian languages.
Expected Results The DUT should have in-built capability for inputting of the following languages:
for Message input a) English
capability b) Hindi and
c) Any other (at-least one) Indian Language
Expected Results The DUT should have the capability to display all the languages as follows:
for Message a) English
Readability b) Hindi and
c) All (twenty-one) other Indian Languages
Test Procedure 1. Configure the EUT to run SNMP agent and SNMP Test Tool (NMS) to run SNMP manager application by
using correct parameters.
2. Testing of TRAP message: The NMS uses SNMPv2 to manage the SNMP agent, and the agent automatically
sends notifications to report events to the NMS.
3. Configure the SNMP agent to send traps to the manager.
4. Use a wrong community name to get the value of a MIB node on the agent. You can see an authentication
failure trap on the SNMP manager.
5. Test “SetRequest” operation: SNMP Testing node (SNMP manager) sends SNMPv2c “SetRequest” to set
SysName to “EUT1”. Verify the SysName value on the EUT. It should match the value “EUT1” set using
‘SetRequest’ function from the SNMP manger.
6. Test SNMP GET Operation (single Object): Testing node (SNMP Manager) sends SNMPv2c “GetRequest”
scalar object to get sysName.0 1.3.6.1.2.1.1.5.0 in system group in MIB II, to Agent. The agent should
respond with “SysName value as “EUT1” as set in the previous step, verifying that the EUT support SNMP
GET function.
Expected Results 1. TRAP should be sent by EUT (Agent) to Testing Node (SNMP Manager).
2. SetRequest operation should be able to set SysName object in agent (EUT)
3. GetRequest operation should be able to get SysName Object from agent (EUT)
4. Attach screenshots for above successful operations.
Test Setup
Test Procedure 1. Configure the agent on EUT and SNMP manager on SNMP Test Tool to use SNMPv3 with security level
setting to AuthPriv. Set Authentication to SHA and Privacy (encryption) to DES.
2. The NMS uses SNMPv3 to monitor and manage the agent
3. The agent automatically sends notifications to report events to the NMS.
4. The NMS and the agent perform authentication when they establish an SNMP session. The authentication
algorithm is SHA and the authentication key is xxxxxx. The NMS and the agent also encrypt the SNMP
packets between them by using the DES algorithm and encryption key yyyyyy
Expected Results 1. Use correct authentication credentials to access the agent.
2. Attach traces for successful encrypted authentication with correct credentials
3. Use incorrect authentication credentials to access the agent
4. Attach traces for failed authentication with incorrect credentials
Test Details As per Department of Telecom No. 16-04/ 2015-AS-III/NP/67/120 dated 4th May 2016