FTS For L163035 ENB Availability v01.01

FTS for L163035 eNB availability

Document number: LTE/SYS/APR/038224
Document issue: V01.01 / EN
Document status: Draft
Date: 12/AUG/2012
Features Feature ID PPM ID Feature Title

L157661 157661 eNB reliability – DECP dependency
L163035 163035 eNB availability
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25 UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write
26 protected”; it may be altered only by authorized persons. While copies may be printed, it is not
27 recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies
28 taken must be regarded as uncontrolled copies.
29
Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know - Proprietary - Use only pursuant to Company
instruction
LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 1/34

1 PUBLICATION HISTORY
2 12/AUG/2012
3 Issue 01.01 / EN, [Draft]
4 Review Record :
5 Creation
instruction

1 CONTENTS
2 1 INTRODUCTION...................................................................................................................................5
3 1.1 FEATURE CONTACTS (NON CUSTOMER VIEWABLE).............................................................................5
4 1.2 SCOPE (CUSTOMER VIEWABLE) ........................................................................................................5
5 1.3 FEATURE EXECUTIVE SUMMARY (CUSTOMER VIEWABLE) ...................................................................5
6 1.4 FEATURE BENEFIT (CUSTOMER VIEWABLE)........................................................................................6
7 1.5 FEATURE BENEFIT TO ALU (NON CUSTOMER VIEWABLE) ....................................................................6
8 2 FEATURE DESCRIPTION....................................................................................................................7
9 2.1 GENERALITIES (NON CUSTOMER VIEWABLE)..................................................................................7
10 2.2 W ORKING ASSUMPTIONS (NON CUSTOMER VIEWABLE) ....................................................................10
11 2.3 HIGH LEVEL DESCRIPTION (NON CUSTOMER VIEWABLE) ..................................................................17
12 2.4 FEATURE INTERACTIONS AND DEPENDENCIES .................................................................................17
13 2.5 NETWORK ARCHITECTURE .............................................................................................................18
14 2.6 FEATURE SCENARIOS (CUSTOMER VIEWABLE) .................................................................................18
15 2.7 STANDARDS COMPLIANCE (CUSTOMER VIEWABLE) ..........................................................................18
16 2.8 OPERATIONAL INFORMATION (CUSTOMER VIEWABLE)......................................................................19
17 3 IMPLEMENTATION IMPACTS (NON CUSTOMER VIEWABLE) .....................................................19

18 3.1 ENB IMPACTS (NON CUSTOMER VIEWABLE).....................................................................................19
19 3.2 OTHER PRODUCT UNIT NETWORK ELEMENT IMPACTS (NON CUSTOMER VIEWABLE)...........................21
20 3.3 NETWORK INTERFACES (NON CUSTOMER VIEWABLE) .......................................................................21
21 3.4 OPERATION AND MAINTENANCE (NON CUSTOMER VIEWABLE) ...........................................................21
22 4 REQUIREMENTS (NON CUSTOMER VIEWABLE) ..........................................................................23

23 4.1 ENB REQUIREMENTS (NON CUSTOMER VIEWABLE) ..........................................................................23
24 4.2 OTHER PRODUCT UNIT NETWORK ELEMENT REQUIREMENTS (NON CUSTOMER VIEWABLE)................26
25 5 FEATURE IMPACTS ..........................................................................................................................26

26 5.1 ENGINEERING IMPACTS (CUSTOMER VIEWABLE)...............................................................................26
27 5.2 PERFORMANCE & SYSTEM DIMENSIONING (NON CUSTOMER VIEWABLE)............................................26
28 5.3 INTEGRATION AND TEST CONSIDERATIONS (NON CUSTOMER VIEWABLE) ...........................................27
29 5.4 IMPACTED ENB SPECIFICATION DOCUMENTS (NON CUSTOMER VIEWABLE) .......................................27
30 6 FEATURE COMPLIANCE (NON CUSTOMER VIEWABLE) .............................................................28

31 6.1 COMPLIANCE TABLE FOR FEATURE L163035 (NON CUSTOMER VIEWABLE) .......................................28
instruction

1 7 RISKS AND OPEN POINTS (NON CUSTOMER VIEWABLE)..........................................................32
2 8 REFERENCES (NON CUSTOMER VIEWABLE)...............................................................................32
3 9 ABBREVIATIONS (NON CUSTOMER VIEWABLE) .........................................................................32
instruction

1 1 INTRODUCTION
2 1.1 FEATURE CONTACTS (NON CUSTOMER VIEWABLE)
Domain Name
Document Owner Marius Lazar
Document Author(s) Marius Lazar, Francis Hargoa
PLM Prime Fred Davant, Jean Jacques Genet
CallP Prime Claudiu MIHAILESCU
OAM Prime Frank Mueller
SAM Prime Raphael Horn
3 1.2 SCOPE (CUSTOMER VIEWABLE)

4 This FTS for software feature impact analysis is mainly intended for an ALU
5 technical experts audience, however, material in sections marked as Customer
6 Viewable can be shared with customers.
7 It is intended to be used by:

8 • Product Line Management (PLM) to ensure compliancy to the market
9 requirements
10 • Systems Engineering (SE) to update the impacted System
11 Specification and Interface Definition documents
12 • R&D with SE to generate a DR0 estimate (H/M/L per domain)
13 • SE to generate a statement of work for other Product Units
14 • NLT/SV/ENB Test for test strategy / test plans
15 • Customer Documentation to create customer documentation. Only
16 information in sections marked Customer Viewable shall be used for
17 this purpose.
18 1.3 FEATURE EXECUTIVE SUMMARY (CUSTOMER VIEWABLE)

19 This feature provides the eNB Reliability target for LA7/TLA7:
20 • eNB Software Upgrade Outage (Reboot Time): < 2 min (with GPS & 1588
21 & SyncE)
22 • Warm Reset (Without SW activation): < 1 min 30s (with GPS & 1588 &
23 SyncE)
24 • Number of eNB SW upgrades: 2 per year
25 • eNB availability (Partial and full outage with 2 SW Upgrades) = 99.996%
instruction

1 • eNB availability (Partial and full outage without SW Upgrade) = 99.997%
2 This feature includes also the dependency in DECP program for eNB reliability
3 (FID: 128255). It covers reduction in duration of both warm resets and SW
4 upgrades of the eNB.
5 The FTS will focus in Warm Reset treatment following a Controller Board Failure,
6 the only that produces an eNB full outage.
7 The target proposed is a predictable outage time elapsed, independent of

8 synchronization method (GPS, SyncE or 1588) and the number of Modems and
9 RRHs/TRDUs in the configuration.
10 Based on the requirements for Warm Reset optimization some scenarios will be
11 available also in case of Software Upgrade Outage.
12 This FTS will also describe the eNB availability targets for the whole eNB (i.e.
13 eNB = LTE Base Band Unit + Radio) for the releases L13.3 (as Radio unit could be
14 RRH2 or TRDU, reliability requirements are given for the worst case).
15
16 1.4 FEATURE BENEFIT (CUSTOMER VIEWABLE)

17 The target proposed is predictable outage duration, independent of
18 synchronization method (GPS, SyncE or 1588), the number of Modems and
19 RRHs/TRDUs in the configuration.
20 1.5 FEATURE BENEFIT TO ALU (NON CUSTOMER VIEWABLE)

21 With the proposed approach, the start-up duration in case of Warm Reset will be
22 one of the best on the market, the target being less than 30s. It is known, this
23 duration is one of most visible KPI for the costumers.
24 The modular approach proposed will make also room for Software Upgrade
25 Outage duration improvement.
instruction

1 2 FEATURE DESCRIPTION
2 2.1 GENERALITIES (NON CUSTOMER VIEWABLE)
3 2.1.1 Basic definitions
4
5 Full outage:
6 A full outage will be taken into account (from reliability point of view) if the eNB
7 has lost all traffic voice and data for more than 15 seconds (TL9000 Release 4.0).
9 Partial outage:
10 A "partial" outage is a loss of only a part of the traffic, loss of greater than 10% of
11 the provisioned eNB capacity for originations and/or terminations (for combined
12 voice and data traffic) for a period greater than 15 seconds.
13 For each instance of "partial" outage, the impact can be weighted based on the %
14 of eNB capacity in outage.
15 Example 1/ Loss of one sector on a eNB configured with a total of 3 sectors

16 counts as “33%” for Coverage.
17
18 Daily traffic profile:
19 Some unplanned partial outages could be discounted according to the daily

20 traffic profile shown in Figure below (blue curve)
21 As the lower traffic rate (during night) is not < 10% of eNB capacity (here 30%),
22 no discount can be done in this particular case of daily traffic profile.
23 Hour Measured Data Model
0 52,5% 70,0%
1 36,3% 30,0% Daily Traffic Profile
24 2 25,3% 30,0%
3 20,2% 30,0% 100% 100%
25 4 18,5% 30,0%
Percentage of Peak Busy Hour Traffic
Measured data
5 20,3% 30,0%
26 6 28,2% 30,0% 80%
7 40,9% 30,0% 70%
8 49,5% 70,0%
27 9 59,3% 70,0% 60%
10 70,3% 70,0%
28 11 80,9% 70,0%
12 87,9% 100,0% 40%
13 89,6% 100,0% Model
29 14 92,2% 100,0%
30%
20%
15 95,3% 100,0%
30 16 98,1% 100,0%
17 100,0% 100,0% 0%
18 96,1% 100,0%
31 19 92,5% 100,0%
0 4 8 12
Hour of the Day
16 20
20 91,6% 100,0%
32 21 89,5% 100,0% The measure data is taken from Philadelphia RNC02 (from May 1, 2009 to July 31, 2009)
22 80,6% 70,0% and Philadelphia RNC01 (from June 19, 2009 to July 31, 2009), representing voice & data.
23 65,4% 70,0%
instruction

1 Part of traffic recovered by neighbour cells :
2 Partial and full unplanned outages can be discounted according to percentage of

3 traffic recovered (handshake) by the neighbour cells.
4 • Failure of a single-cell --> 6 neighbours per hexagonal cell --> 66% of traffic
5 recovered (this percentage is an arbitrary assumption shared with other
6 ALU Wireless products).
7 • Failure of the 3 cells of the eNB --> 9 neighbours cells per 3-cells-eNB (so 3
8 "healthy" neighbours per cell in outage) --> 33% of traffic recovered (twice
9 less than in a single-cell, because twice less neighbours per cell in outage).
10 2.1.2 Start-up duration
11 eNB start-up duration (and especially SW Warm Reset) was one of the constant
12 requested topics from our main costumers.
13 In the following table it is presented the evolution of reset duration at eNB and
14 RFM levels from former to future releases planned by PPM.
15
Requirements L101811 L112790 L112790 L115231 Light

Updated Sep/2011 LA3 LA4 LA5 LA6 Radio
eNB full reset (mm:ss) 5:00 2:30 2:30 2:30 2:00
eNB warm reset (mm:ss) 3:40 2:30 2:30 1:30 1:00
RFM full reset (mm:ss) 2:00 2:00 2:00 2:00 1:45
RFM session reset (mm:ss) N/A N/A N/A 1:00 tbd
16 Till now the used method was based on the shortening of activation duration,
17 optimizing the synchronization between launched threads (increase the number
18 of threads started in parallel and optimizing the restart of Modems and
19 RRHs/TRDUs by adding increased supervising activity (hearth bit based).
20 Another step forward was realized by reducing the number of BISTs (Built In Self
21 Test) and their complexity for the standard start-up case.
22 The following points must be retained at this phase:
23 1. There are different categories of uses-cases that imply a start-up:
24 a. Programmed reset from NEM/SAM due to Class A or even certain

25 Class B parameters change
26 b. Programmed reset from NEM/SAM due to HW update
27 c. eNB SW upgrade
28 i. Application upgrade related to Controller board only
29 ii. Major SW upgrades, FPGA’s SW, etc.
30 d. Unexpected/Unplanned reset.
instruction

1 These categories of use-cases need a WARM RESET start-up.
2 2. Actually a Controller board reset implies Modems and RRHs/TRDUs reset

3 also. In the proposed solution for WARM RESET only the Controller board
4 will be reset, Modems and RRHs/TRDUs will be only “reinitialized”.
5 3. The system has a unique reset mode, it is not able to make the
6 difference between a Full Reset and a Warm Reset
7 4. The Start-up duration is depending of synchronization source (1588 with

8 bad IP traffic conditions could lead at very important start-up durations)
9 and the complexity of HW configuration (number of Modems and
10 RRHs/TRDUs especially).
11 2.1.3 eNB availability
12 Reliability is not a functional feature, but a part of eNB effectiveness, which

13 quantifies:
14 1. The ability to handle commercial traffic in field with the less possible
15 downtimes, and
16 2. To recover from an outage as quick as possible (start-up duration, outage

17 duration following SW fault).
18 The following schema tries to show the main parameters involved in reliability
19 calculation. Some are considered as fixed inputs (as HW MTBF/MTTR, SW upgrade
20 rate, manual detection delay), others (in red) are under the responsibility of our SW
21 development and have to be strongly tested.
22
23 Key Inputs : % of traffic not recovered by neighbors % of eNB capacity

Total / Partial *
24 HW failure rate /yr Outage
(= 1 / MTBF) Total or
25 HW unavailability
partial *
HW MTTR = 120mn x 66% (total outage)
26 x 33% (partial outage) unavailability
27
SW upgrade rate 2/yr ? (in min./yr)
outage durations
28 (OK 2' automatic planned SW unavail. either
/ NOK 60mn manual) Availability
29 x 100% (no discount) x 100% (total)*
=1-
99.9% upg. success or
30 tot.unavail. -
SW failure rates : x 33% (partial) part.unavail.
31 - total < 2.5/yr unplanned SW unav. > 99.996%
- partial < 1.5/yr
x 66% (total outage)
32 (LA6 target)
outage durations : x 33% (partial outage)
33 1'30" automatic restart
/ 60mn manual delay
34 (*) Same method for total & partial unavailabilities
95% automatic detect. (to be computed separately, then added)
35
Note : input parameters (in red) are under the responsibility of our SW devel opment and have to be strongly tested
instruction

2 To measure eNB availability was retained five parameters:

3 1. Recovering delay from an outage (HW MTTR, reboot or restart delay,
4 automatic or human detection)
5 2. SW failure rates (unexpected failures happening during normal

6 operation, not planned operations)
7 3. SW upgrade rate (planned operations)
8 4. Success ratio (in %) of maintenance operations (fault diagnostics and

9 recovery, SW upgrade)
10 5. Global system availability (99.99..%) or unavailability (min./year) which

11 is a consequence of all the requirements listed above (as shown by the
12 figure above).
13 As unavailability (or down-time per year) is calculated separately for total

14 outages and partial outages, in the FRS the word “global” is used for the sum of
15 total + partial unavailability. Global availability (measured in 99.99… %) is the
16 main reliability KPI monitored and checked by operators (NPO/NUART helps for
17 monitoring).
18 A special incidence in global system availability has the SW failures. In this
19 category we could make the distinction between SW failures that implies an
20 outage of more than 15 seconds and these that could be limited for a delay of
21 less than 15 seconds. It was agreed that an outage that last less than 15 seconds
22 is not taken into account for determining the Global system availability.
23 For the aspects related to this approach (limit the numbers of outages and the
24 outage delay) the following specific FRS was produced:
25 • 162958 Reset Eradication - DECP
26 • 163182 eNB Reset Eradication - CallP domain
27 • 163339 Transport Reset Eradication
28 • 163420 OAM Reset Eradication
29 2.2 WORKING ASSUMPTIONS (NON CUSTOMER VIEWABLE)

30 The presented requirements will focus mainly in the reducing of start-up duration
31 because:
32 • This is one of the main KPI required by the Client
33 • This parameter has one of the most important impacts on the Global
34 system availability.
35 To reach the proposed goal, a totally new approach is proposed, the method used
36 till now (contract the start-up phase delay) reaching at its technical limit.
instruction

1 This new approach is based on the following implementation requirements:
2 2.2.1 FULL – WARM Reset Management
3 2.2.1.1 Introduction
4 For better comprehension the startup phase will be divided between:

5 o uBoot program and
6 o Platform Startup Application part that includes:
instruction

2 1. Linux OS and processes start-up (1).

3 2. Set up and organize SNMP Data Base (2) & (5).
4 3. HW discovery of CB and DBU – eNB creation, check DBU’s SN (3) & (4).
5 4. Migration and organization of XML data (6) & (8).

6 5. Compatibility checks for SW version and SNMP & XML DB (9)
7 6. Start CallP initialization (10)
8 7. HW discovery for RFM, BB, AMR, EAM (11) & (14)

9 8. OAM-IP Configuration, WAL-G Initialization, SCTP Access & IPSec
10 Configuration (12) & (13)
11 9. Enable SNMP & Netconf interfaces (16)
12 10. Check Timing RO created (synchronization acquired)
13 11. Enable Cell
14 The notified cases must be replaced in case of WARM Reset and some specific
15 cases of FULL Reset.
16 The two phases, uBoot and Platform Startup Application will be considered the
17 main elements that need to be modified and correlated to reach the required
18 target.
19 A clear distinction must be done between a FULL Reset that in fact corresponds
20 to the actual reset procedure and a WARM Reset that has to be developed
21 answering to the requirements presented by this document.
22 It is also mentioned here that for FULL Reset we must take into account the
23 requirements specified by the FRS 162481 – Best DAC Support for Cold Reset that
24 will allow the independency of start-up duration with respect to synchronization
25 source: GPS, SyncE or 1588 PTP. Also SW update process could (in some specific
26 cases) use the mechanisms required by WARM Reset to improve the start-up
27 duration (bypass HW discovery steps – 3 and 7).
28 2.2.1.2 BOOTFlag
29 It is proposed the utilization of a parameter named BOOTFlag stored in the

30 nonvolatile memory. The value of this parameter notifies:
31 a. 0x01 – WARM RESET – implies a start-up following a reset of type a, c-i

32 ou d. After start, uBoot process will change the value of BOOTFlag to
33 0x02 (WARM RESET_A) to indicate the startup mode to be executed by
34 the Platform Startup Application and to prevent the reexecution of a
35 WARM RESET in case if failing pending uBoot process.
36 b. 0x02 – WARM RESET_A – notifies to Platform Startup Application that
37 it will execute a WARM RESET. At the end of Platform Startup
instruction

1 Application phase the BOOTFlag value will be changed to 0x00 (IDLE)

2 and also a timer CheckTimer (recommended to be between 30min &
3 60min) will be armed. When it will fire, if the value of BOOTFlag is still
4 0X00 (IDLE), a specific DB containing the current HW configuration, RIT
5 Table, Inventories will be saved into non volatile memory and after the
6 BOOTFlag value is changed to 0x01 (WARM RESET) to notify that the
7 system is stable and if an uncontrolled reset take place, it will be a
8 WARM RESET.
9 c. 0x00 – IDLE – this value indicates that the eNB is under observation. It
10 must be notified here that the adding of a new Modem or RRH in the
11 configuration will imply also an update of BOOTFlag value that will be
12 set to 0x00 (IDLE) and arm the corresponding CheckTimer timer.
13 d. 0xFF – FULL RESET – this value is set in case of a SW update or HW alarm

14 to force the next reset to FULL. This value will be changed to 0x00 (IDLE)
15 by the Platform Startup Application. It must be notified that for this
16 value Platform Startup Application will perform a normal startup
17 corresponding to actual implementation.
18
19 2.2.1.3 sibFPGA
20 Actually sibFPGA drive the Global Reset where the FPGA’s OIP, sBBLINK and the
21 Ethernet Switch are HW reset. We have 6 causes of global reset => they put
22 under reset all the components on the board:
23 Power-on reset or boot FPGA update,

24 Push button reset,
25 SW suicide,
26 Watchdog reset,
27 Power failure,
28 Reset from mate.
29
30 A new version is requested where the FPGA’s OIP and sBBLINK and the internal
31 Ethernet switch must not be reset in case of:
32 SW suicide,
33 Watchdog reset,
34 Also it is required that at sibFPGA’s BIST level the Global Reset must be
35 executed, like this a FULL RESET will execute this step every time.
36 2.2.1.4 HW DB
37 A HW DB (Hardware Database) must be defined and managed. This HW DB must

38 contain all the elements retrieved by HW discovery processing. This includes RIT
39 table, Serial Numbers, Inventories, IP addresses, etc. This HW DB must be
40 organized around the following resources managed by HRAL:
instruction

1 o DBU RO – Digital Baseband Unit - shelf
2 o CB RO – Controller Board (contains also Timing Unit for

3 synchronization, IQXC – IQ CrossConnect, etc.)
4 o BB RO – Baseband – Modem board (contains also C-HSIQ for HSIQ

5 management)
6 o AMR RO – Alarm Module Radio cabinet
7 o FAU RO – Fan Assembly Unit
8 o RFM RO – Radio Frequency Module – RRH, TRDU

9 o EAM RO – External Alarm Module
10 o ALD RO – Antenna Line Device
11 o PP RO – Physical Port
12 o SFP RO – Small Form-factor Pluggable
13 o Tbc.
14 All these resources are already managed at HRAL level. Even if it is not the goal
15 of a FTS document it is proposed here to add for all concerned (HW related)
16 resources managed by HRAL two methods on the interface for all concerned
17 objects:
18 o SaveSnapshotData – for saving necessary configuration data to

19 nonvolatile memory
20 o RetrieveSnapshotData – for retrieving necessary configuration

21 data from nonvolatile memory
22 The HW DB must have a format that will stay unchanged over different SW
23 versions allowing like this to bypass HW discovery step in case of SW update.
24 OAM-C has to maintain this HW DB with respect to
25 o BOOTFlag value
26 o CheckTimer
27 o HW RU insertion/removing event
28 o HW RU administrative state changes
29 Effectively when the CheckTimer fires and BOOTFlag value is IDLE (0x00) the
30 HW DB is saved into non volatile memory and BOOTFlag is passed to WARM
31 RESET (0x001).
32 Any change into HW DB (RU insertion/removing or administrative state change)

33 will be treated with respect to BOOTFlag value:
34 o 0x00 – IDLE – the CheckTimer is rearmed
35 o 0x01 – WARM RESET – the BOOTFlag is passed to IDLE (0x00)

36 and the CheckTimer is rearmed.
instruction

1 o 0x02 – WARM RESET_A –not allowed, the BOOTFlag is passed

2 to FULL RESET (0xFF)
3 o 0xFF – FULL RESET – no action
4 2.2.1.5 uBoot
5 At uBoot level some minor changes are necessary.

6 uBoot has to be able to manage BOOTFlag.
7 The only procedure to be implemented requires that in case when the BOOTFlag
8 has the value x01 – WARM RESET the following actions must be realized:
9 o The BOOTFlag value must be updated to 0x02 – WARM RESET_A to
10 avoid loop on this sequence.
11 o No BIST, HW check or HW configuration allowed – The BIST information

12 from the previous boot stay in place.
13 o A multicast Ethernet frame (Slow Protocol) must be sent to Modem

14 boards. This Ethernet frame will be treated by Modems like a signal of
15 Controller Board failure.
16 For any other value the BOOTFlag must be set to 0x02 – FULL RESET and the
17 actual boot sequence maintained, but the BIST concerning sibFPGA must be able
18 to bring on a Global Reset.
19 2.2.1.6 Controller Board
20 The main effort concerning Warm reset enhancement must be done at Platform
21 Startup Application level.
22 The following main points must be implemented:
23 BOOTFLAG – 0X02 WARM RESET_A
24 HW discovery phase must be bypassed and replaced by retrieving all

25 necessary elements from HW DB in the nonvolatile memory.
26 All checks concerning SW version or compatibility must be bypassed.

27 sibFPGA – the SYNCHRONIZATION process will be maintained pending
28 SOFTWARE reset; the driver and software application that drives this
29 FPGA must take into account the reset indication (WARM or FULL) and to
30 proceed consequently. For FULL version the actual behavior is
31 maintained, but for WARM version the driver/application must manage
32 the FPGA “on the fly” , discovering actual configuration and status
33 without perturbing the normal service.
34 OIP – the CPRI link must be maintained pending WARM reset. This implies
35 for driver/application concerned by OIP to act in the same way like for
36 sibFPGA.
instruction

1 sBBLINK must maintain HSIQ links and SFN numbering pending WARM
2 reset. This implies for driver/application concerned by sBBLINK to act in
3 the same way like for sibFPGA.
4 The SYNCHRONIZATION process will continue normally from HOLDOVER

5 status.
6 All HW resources that support administrative state (BB RO, RFM RO, etc.)
7 must be considered like Locked at the end of start-up initialization
8 phase. They must be unlocked – reconfigured.
9 Finally BOOTFlag must be set to IDLE – 0X00 and CheckTimer armed
10 Once this sequence ended the normal process could continue like in current
11 implementation (Enable Cell…).
12 If pending this phase HW RU insertion/removing events are produced, the
13 BOOTFlag must be set to FULL RESET – 0XFF and Controller Board restarted.
14 BOOTFlag – 0X00 IDLE
15 The events taken into account are:
16 CheckTimer fires. In this case the BOOTFlag is set to WARM RESET –

17 0x01.
18 HW insertion/removing FRU or administrative state changes FRU – this
19 will imply rearming of CheckTimer.
20 Major SW upgrade - the BOOTFlag is set to FULL RESET – 0xFF.

21 Minor SW upgrades (see c-i 2.1), Class A parameters changes; BOOTFlag
22 is set to WARM RESET – 0x01 followed by reset.
23 BOOTFlag – 0X01 WARM RESET

24 The events taken into account are:
25 HW insertion/removing FRU or administrative state changes FRU – this

26 will imply BOOTFlag set to IDLE – 0X00 and CheckTimer armed
27 Major SW upgrade - the BOOTFlag is set to FULL RESET – 0xFF.
28 BOOTFlag – 0XFF FULL RESET
29 This value could not be changed.
30 2.2.1.7 Modem Board
31 For supporting WARM RESET it is required that at Modem level to be

32 implemented a specialized thread WarmBootListener that will perform the
33 following functions:
34 Receive from controller the list of all RFM RO (RRHs and/or TRDUs) with
35 their IP addresses. This list could be updated in case of adding/removing
36 RFMs.
instruction

1 In case of receiving from Controller’s uBoot the Ethernet frame (Slow

2 protocol), notifying the WARM RESET the following actions must be
3 executed:
4 o Stop Tx/Rx for all RRHs/TRDUs in the eNB configuration. This

5 will imply opening a TCP/IP connection with every RRH/TRDU in
6 configuration. This will be possible because OIP FPGA and the
7 Ethernet Switch are still working in case of WARM RESET.
8 o Cell Delete for all configured cells (equivalent with Locked

9 state).
10 Open Point: In case of Dual or Tri Carrier when the cells will be enabled, every
11 Modem board must be reconfigured with the same carrier and bandwidth. This
12 could be solved by extending the HW DB defined for controller with carrier and
13 bandwidth per Modem information.
14 2.3 HIGH LEVEL DESCRIPTION (NON CUSTOMER VIEWABLE)
15 2.4 FEATURE INTERACTIONS AND DEPENDENCIES
16 2.4.1 eNodeB Interactions and Dependencies (Customer Viewable)
17 N/A
18 2.4.2 eNodeB Implementation Interactions and Dependencies (Non Customer

19 Viewable)
20 This feature has major impacts at Controller Platform Level, uBoot and minor at
21 bCEM Modem board level. In case of eCEM Modem board the Cell Delete
22 functionality must be implemented for replacing the actual Modem Board Reset.
23
Feature
Feature Title Nature of Dependency
Number
Make start-up duration in case of FULL
L162481 Best DAC Support for Cold Reset Reset shorter and independent of the
nature of synchronization source.
Increase the Global eNB availability by
L162958 Reset Eradication - DECP
reducing the number of SW outages
eNB Reset Eradication – CallP Increase the Global eNB availability by
L163182
domain reducing the number of SW outages
L163339 Transport Reset Eradication
L163420 OAM Reset Eradication
instruction

2 2.4.3 Other NE Dependencies (Customer Viewable)
3 N/A
4 2.4.4 Required UE Functionality (Customer Viewable)
5 N/A
6 2.5 NETWORK ARCHITECTURE
7 2.5.1 Proposed Network Architecture (Customer Viewable)
8 N/A
9 2.5.2 Architectural Alternatives (Non Customer Viewable)
10 N/A
11 2.6 FEATURE SCENARIOS (CUSTOMER VIEWABLE)

12 N/A
13 2.7 STANDARDS COMPLIANCE (CUSTOMER VIEWABLE)

14 N/A
instruction

1 2.8 OPERATIONAL INFORMATION (CUSTOMER VIEWABLE)

2 Feature type: Base
3 Feature activation flag: “none”
4 Activated by default: yes

5
6 3 IMPLEMENTATION IMPACTS (NON CUSTOMER VIEWABLE)
7 3.1 ENB IMPACTS (NON CUSTOMER VIEWABLE)
8 3.1.1 uBoot Subsystem (Non Customer Viewable)
9 The following functionalities must be offered:
10 A boot parameter situated in the nonvolatile memory and shared with

11 Controller board Application has to be managed to determine what kind
12 of reset must be performed: WARM RESET or FULL RESET.
13 Once the kind of reset determined, the boot parameter must be updated
14 for the next step which could be:
15 o WARM RESET_A for Controller Application in case when the

16 current value is WARM RESET,
17 o FULL RESET in all other cases.

18 In case of WARM RESET the Modem Boards must be notified via an
19 Ethernet Slow Protocol frame.
20 In case of WARM RESET the BISTs and Global Reset are avoided. Also
21 any HW configuration or check must be disabled.
22 3.1.2 Platform Subsystem (Non Customer Viewable)
23 The following functionalities must be offered:
24 sibFPGA has to avoid Global Reset in case of WARM RESET maintaining

25 OIP, sBBLINK (CPRI and HSIQ links) and Ethernet Switch actives.
26 A HW Data Base containing all the HW ROs discovered and managed by
27 HRAL in the phase HW Discovery and the characteristics of every resource
28 must be managed and stored in the non volatile memory.
instruction

1 The boot parameter must be managed to notify in case of boot the reset
2 type and in the start-up phase what kind of reset is or must be
3 effectuated (WARM RESET_A or FULL RESET).
4 In case of WARM RESET_A the HW Data Base mentioned previously must

5 be used in place of standard HW Discovery procedure in the start-up
6 phase.
7 In case of WARM RESET_A SYNCHRONIZATION process will start from

8 HOLDOVER state.
9 Send to Modems the list of all RRHs/TRDUs in configuration with their IP
10 addresses and also the updates following RRHs/TRDUs add/remove
11 operations.
12 The drivers and applications managing sibFPGA, OIP, sBBLINK and
13 Ethernet Switch must be able to proceed differently in case of WARM
14 RESET_A; no need of initialization, but working “in the fly”.
15 3.1.3 OAM Subsystem (Non Customer Viewable)
16 The OAM system has to verify if the Modem boards in the configuration are all
17 bCEMs. If the answer is negative, the BOOTFlag value must be set to 0XFF –
18 FULL RESET.
19 This action must be executed also in case of adding a new Modem board of type
20 different of bCEM.
21 In case of WARM RESET_A the SW version check must be bypassed.
22 3.1.4 Modem Subsystem (Non Customer Viewable)
23 The following functionalities must be offered by a specialized service:
24 Receive and keep updated from Controller board messages the list of
25 RRHs/TRDUs with their IP addresses.
26 Wait for WARM RESET notification via Ethernet Slow Protocol frame and
27 in case of receiving:
28 o Stop Tx/Rx for all RRHs/TRDUs in the eNB configuration.
29 o Cell Delete - delete all cells (configured in this Modem
instruction

1 3.2 OTHER PRODUCT UNIT NETWORK ELEMENT IMPACTS (NON

2 CUSTOMER VIEWABLE)
3 N/A
4 3.3 NETWORK INTERFACES (NON CUSTOMER VIEWABLE)

5 N/A
6 3.4 OPERATION AND MAINTENANCE (NON CUSTOMER VIEWABLE)
7 3.4.1 Configuration Management (Non Customer Viewable)
8 3.4.1.1 O&M Parameters (Non Customer Viewable)
9 Information in the MIB, MIM spreadsheet file and SRS Migration Rules takes
10 precedence once available. Refer to section 2.7 Operational Impacts for a list of
11 objects and parameters applicable to this feature.
12 N/A
13 3.4.1.2 WPS/SAM Constraints (Non Customer Viewable)
14 Information in the Webtool and SRS for WPS/SAM Constraints takes precedence
15 once available.
16 N/A
17 3.4.2 Fault Management (Non Customer Viewable)
18 Information in the SRS FM takes precedence once available; only the names of
19 relevant alarms are maintained here.
20 N/A
instruction

1 3.4.3 Performance Management (Non Customer Viewable)
2 3.4.3.1 PM Counters (Non Customer Viewable)
3 Information in the SRS PM takes precedence once available; only counter names
4 are maintained in this document.
5 N/A
6 3.4.3.2 Per Call Measurement Data (Non Customer Viewable)
7 Information in the SRS PCMD takes precedence once available; only PCMD
8 parameter names are maintained here.
9 N/A
10 3.4.3.3 Call Trace (Non Customer Viewable)
11 Information in the SRS Call Trace takes precedence once available; only message
12 names are maintained here.
13 N/A
instruction

1 4 REQUIREMENTS (NON CUSTOMER VIEWABLE)
2 4.1 ENB REQUIREMENTS (NON CUSTOMER VIEWABLE)

3 <Start: FTS-038224-10, Requirement>
4 The eNB must support two distinct reset operations at the controller board level:
5 1. FULL RESET – equivalent with actual Global Reset having like causes:
6 a. Power-on reset or boot FPGA update
7 b. Push button reset
8 c. SW suicide (for major SW upgrade only)
9 d. Power failure
10 2. WARM RESET – fast boot reset having like causes
11 a. Watchdog reset
12 b. SW suicide (for other cause than major SW upgrade)
13 c. Reset from mate (redundancy)
14 FRS Requirement: FR-163035-Req.1, FR-163035-Req.2, FR-163035-Req.3
15 Affected DPM Area: eNB-OAM, Platform, HW
16 Release: Common
17 Network Element: ENB
18 <End: FTS-038224-10>
19
21 The eNB FULL RESET duration must be less than 2 min.
22 The duration will be measured between the start of uBoot and the moment when all
23 configured cells are activated.
24 FRS Requirement: FR-163035-Req.2
25 Affected DPM Area: eNB-OAM, Platform, HW, Test
26 Release: Common
28 <End: FTS-038224-20>
29
31 The eNB WARM RESET duration must be less than 1 min 30 sec.
32 The duration will be measured between the start of uBoot and the moment when all
33 configured cells are activated.
35 Affected DPM Area: eNB-OAM, Platform, HW, Test
36 Release: Common
38 <End: FTS-038224-30>
39
41 System availability must respect the values presented in the following table:
42
Configuration System Availability
Controller = eCCM/eCCM2; Modems = 3 eCEMs 99,997%
Controller = eCCM/eCCM2; Modems = 1 bCEM 99,996%
Controller = eCCM/eCCM2; Modems = 2 bCEMs 99,996%
43
44 The downtime is defined considering 0 SW upgrades per year and including product-
45 attributable unplanned outages.
instruction

1 Unplanned outages consist of total eNB outages (no traffic can be carried) plus partial eNB
2 outages (loss of greater than 10% of the demanded traffic for more than 15 seconds)
3 weighted to their real impact for the traffic.
4 FRS Requirement: FR-163035-Req.4, FR-163035-Req.5, FR-163035-Req.6,
5 FR-163035-Req.7, FR-163035-Req.8
6 Affected DPM Area: Test
7 Release: Common
9 <End: FTS-038224-40>
10
12 Fault coverage:
13 • Automatic detection and reporting at 95%. Reporting delay to the external entity
14 controlling eNB must be less than 15 seconds.
15 • Manual detection - up to 60 min whenever automatic detection fails.
18 Release: Common
20 <End: FTS-038224-50>
21
23 The SW upgrade success rate must be at least 99.9%.
24 If OMC controlled SW upgrade fails, the duration of a manual SW upgrade must be less
25 than 60 min.
28 Release: Common
30 <End: FTS-038224-60>
31
33 The SW failures implying total outage must be less than 3 per year.
34 The SW failures implying partial outage must be less than 2 per year and per cell.
35 FRS Requirement: FR-163035-Req.11, FR-163035-Req.12
37 Release: Common
39 <End: FTS-038224-70>
40
42 The WARM RESET will be allowed only on BBU configurations based on bCEM Modems only.
44 Affected DPM Area: eNB-OAM
45 Release: Common
47 <End: FTS-038224-80>
48
50 A boot parameter situated in the nonvolatile memory must be used by uBoot and
51 Controller’s Platform application program to manage specific actions related to reset
52 type: WARM RESET or FULL RESET.
54 Affected DPM Area: eNB-OAM, Platform, HW
55 Release: Common
instruction

1 <End: FTS-038224-90>
2
4 It is in charge of uBoot program to notify the Modems boards in case of Controller’s WARM
5 RESET start-up.
7 Affected DPM Area: Platform, HW
8 Release: Common
10 <End: FTS-038224-100>
11
13 By default, sibFPGA must avoid the reset of OIP-FPGA, sBBLINK-FPGA and internal
14 Ethernet Switch. The reset of these components must be possible only on request.
17 Release: Common
19 <End: FTS-038224-110>
20
22 A BBU configured HW resources Data Base must be defined. This Data Base stored in the
23 nonvolatile memory will be:
24 • Populated pending HW discovery phase following a FULL RESET start-up and
25 insertion/removing FRUs events.
26 • Used in place of HW Discovery process following a WARM RESET start-up.
28 Affected DPM Area: Platform
29 Release: Common
31 <End: FTS-038224-120>
32
34 The drivers and Platform applications that manage the following components:
35 1. sibFPGA
36 2. OIP-FPGA
37 3. sBBLINK-FPGA
38 4. internal Ethernet Switch
39 must be able to take into account the WARM RESET start-up. In this case the initialization
40 and configuration phase has to be bypassed (they are already configured and running) and
41 the management of concerned HW components must be done “on the fly”.
44 Release: Common
46 <End: FTS-038224-130>
47
49 The OAM-C must communicate to all Modems the list of all RRHs/TRDUs in configuration
50 with their corresponding IP addresses. The application communication protocol has to
51 allow upgrading of this list.
53 Affected DPM Area: eNB-OAM, Modem
54 Release: Common
instruction

1 <End: FTS-038224-140>
2
4 In case of WARM RESET start-up, the SYNCHRONIZATION process has to start from
5 HOLDOVER state.
7 Affected DPM Area: Platform, eNB-OAM
8 Release: Common
10 <End: FTS-038224-150>
11
13 At Modem level a specialized service has to offer the following functionalities:
14 • Manage the list of RRHs/TRDUs in configuration following the messages received
15 from Controller
16 • Able to receive uBoot notification on Controller start-up and on receiving of this
17 information
18 • Sop Tx/Rx for all RRHs/TRDUs
19 • Delete all cells configured in this Modem
21 Affected DPM Area: Modem
22 Release: Common
24 <End: FTS-038224-160>
25 4.2 OTHER PRODUCT UNIT NETWORK ELEMENT REQUIREMENTS

26 (NON CUSTOMER VIEWABLE)
27 N/A
28 5 FEATURE IMPACTS
29 5.1 ENGINEERING IMPACTS (CUSTOMER VIEWABLE)

30 N/A
31 5.2 PERFORMANCE & SYSTEM DIMENSIONING (NON CUSTOMER

32 VIEWABLE)
33 5.2.1 Traffic model (Non Customer Viewable)
34 N/A
35 5.2.2 Performance (Non Customer Viewable)
36 N/A
instruction

1 5.2.3 Load constraints (Non Customer Viewable)
2 N/A
3 5.3 INTEGRATION AND TEST CONSIDERATIONS (NON CUSTOMER

4 VIEWABLE)
5 N/A
6 5.4 IMPACTED ENB SPECIFICATION DOCUMENTS (NON CUSTOMER

7 VIEWABLE)
Type Domain Document ID Document Name
SRS Telecom SYS/LTE/DD/030078 eNodeB Platform
OAM LTE/BTS/DD/035627 LA4.0 eNB OAM Equipment Management Scenario
Specification
8
instruction

1 6 FEATURE COMPLIANCE (NON CUSTOMER VIEWABLE)
2 6.1 COMPLIANCE TABLE FOR FEATURE L163035 (NON CUSTOMER

3 VIEWABLE)
4 Extracted from PPM on 12/AUG/2012
5
FRS Requirements Compliance Table
FDD-TDD Comply Comments/FTS Impacted
Req No. Description
Release Yes/No/Partial References Areas
FTS-038224-10,
FTS-038224-90,
This FRS is applicable to all eNBs FTS-038224-110, eNB-OAM,
FR-
(All BBUs, all RRHs, all TRDUs all FTS-038224-120, Platform,
163035- Common Yes
Cabinets) planned to be supported FTS-038224-130, HW,
Req.1
by this release. FTS-038224-140, Modem
FTS-038224-150,
FTS-038224-160
eNB full reset (Reboot Time): < 2
mn This eNB full reset will occur
for the following use cases:
1/ When the Warm reset is not
enough efficient to solve the issue
2/ For SW upgrade
3/ For any HW intervention or
replacement T(initial): At the OAM
level we perform the Activate of
eNB-OAM,
FR- the new load and new parameters FTS-038224-10,
Platform,
163035- (SW download and installation Common Yes FTS-038224-20,
HW,
Req.2 already done in background) FTS-038224-100
Test
T(final): The eNB is ready to
accept some calls (meaning the S1
& X2 are up, The SIB are
transmitted, all cells of the eNB
are ready to accept calls â€¦)
Action: Upgrade the SW of the
eNB. Post condition: The new
software is executing properly on
the eNB.
Warm Reset (Without SW
activation): Time to complete a
software reboot shall be 1 minutes
30 seconds after software failure.
This duration shall be reached for eNB-OAM,
FR-
95% of the warm reset occurrences. FTS-038224-10, Platform,
163035- Common Yes
This duration is applicable to any FTS-038224-30 HW,
Req.3
synchronization method used by Test
the eNB (GPS, SyncE, 1588).
Classical way Initial state: the eNB
is able to support calls and one
Telecom process has a failure, then
instruction

the OAM-c process will detect the

failure and trigs the warm reset.
End state: all cells of the eNB are
ready to accept calls (This is linked
with the KPI OAM_KPI_1)
System Availability for eNB with 1

eCCM(2) and 3 eCEM (0 SW
Upgrade, HW MTTR = 2h): The
standard configuration shall have a
minimum total system availability
of 99.997%. This downtime is
defined to include product-
attributable unplanned outages.
FR-
Unplanned outages consist of total
163035- Common Yes FTS-038224-40 Test
eNB outages (no traffic can be
Req.4
carried) plus partial eNB outages
weighted to their real impact to
the traffic (loss of greater than 10%
of the demanded traffic for more
than 15 seconds). This value is
applicable with 0 SW upgrade per
year

eCCM(2) and 1 bCEM (0 SW
of 99.996%. This downtime is
defined to include product-
attributable unplanned outages.
FR-
163035- Common Yes FTS-038224-40 Test
Req.5
year

eCCM(2) and 2 bCEM (0 SW
FR- of 99.996%. This downtime is
163035- defined to include product- Common Yes FTS-038224-40 Test
Req.6 attributable unplanned outages and
required software upgrades.
instruction


year

eCCM and 1 bCEM (0 SW Upgrade,
HW MTTR = 2h): The standard
configuration shall have a minimum
total system availability of
99.996%. This downtime is defined
to include product-attributable
FR- unplanned outages. Unplanned
163035- outages consist of total eNB Common Yes FTS-038224-40 Test
Req.7 outages (no traffic can be carried)
plus partial eNB outages weighted
to their real impact to the traffic
(loss of greater than 10% of the
demanded traffic for more than 15
seconds). This value is applicable
with 0 SW upgrade per year

eCCM and 2 bCEM (0 SW Upgrade,
HW MTTR = 2h): The standard
configuration shall have a minimum
total system availability of
99.996%. This downtime is defined
to include product-attributable
FR- unplanned outages. Unplanned
163035- outages consist of total eNB Common Yes FTS-038224-40 Test
Req.8 outages (no traffic can be carried)
plus partial eNB outages weighted
to their real impact to the traffic
(loss of greater than 10% of the
demanded traffic for more than 15
seconds). This value is applicable
with 0 SW upgrade per year
ReqA6- Fault Coverage: A minimum

of 95% of internal eNB failures that
can result in total or partial
outages shall be automatically
detected and reported to the
external entity controlling the base
FR- station within 15 seconds. In case
163035- of external link failure, this Common Yes FTS-038224-50 Test
Req.9 detection delay can be exceeded
due to specific protocol delays. A
fixed set of failures or faults, as
determined by the test team in
partner with hardware and
software development, can be
injected into the system to show
instruction

that 95% or more can be detected

and reported. Use an average 60
minute manual detection time
when auto detection is
unsuccessful, in the verification of
Requirement ReqA03, unless cases
are determined during
development and test that support
another manual detection time
estimate.
eNB Software upgrade success
ratio: 99,9% T(initial): At the OMC
level we perform the SW upgrade
action T(final): The eNB is ready to
accept some calls (meaning the S1
& X2 are up, The SIB are
FR- transmitted, the first cell is ready
163035- to accept calls â€¦) Action: Common Yes FTS-038224-60 Test
Req.10 Upgrade the SW of the eNB. Post
Condition: The new software is
executing properly on the eNB.
Note: In case of Unsuccessful
upgrade: Use an average of 60
minute of total outage in order to
retry a manual upgrade.
FR- SW Failure rate with Total Outage
163035- (eNB): The eNB shall fail no more Common Yes FTS-038224-70 Test
Req.11 than 2 SW failures per year.
FR- SW Failure rate with Partial Outage
163035- (one cell): Each Cell shall fail no Common Yes FTS-038224-70 Test
Req.12 more than 1 SW failure per year.
This feature tracks DECP program FTS-038224-90,
(platform & modem development) FTS-038224-100,
dependency for requirements of FTS-038224-110, eNB-OAM,
FR-
eNB reliability feature (128255) FTS-038224-120, Platform,
163035- Common Yes
requesting reduction of durations FTS-038224-130, HW,
Req.13
of warm resets, resets, and of SW FTS-038224-140, Modem
upgrades (please refer to 128255 FTS-038224-150,
feature for target durations). FTS-038224-160
These enhancements apply to all
BBU configurations (bCEM based),
including 1 bCEM, 2 bCEM and 3
bCEM configurations (both eCCM
FR-
and eCCM2 based) -therefore
163035- Common Yes FTS-038224-80 eNB-OAM
including multi-carrier
Req.14
configurations and CA
configurations. No improvement is
requested on eCEM based
configurations.
1
instruction

2 7 RISKS AND OPEN POINTS (NON CUSTOMER VIEWABLE)

3 N/A
4 8 REFERENCES (NON CUSTOMER VIEWABLE)

5 N/A
6 9 ABBREVIATIONS (NON CUSTOMER VIEWABLE)

7
8 3GPP 3rd Generation Partnership Project
9 ALU Alcatel-Lucent
10 ANR Automatic Neighbor Relation
11 BBU Base Band Unit

12 BTS Base Transceiver Station
13 CCITT Consultative Committee for International

14 Telegraphy and Telephony
15 CDMA Code Division Multiple Access
16 CGI Cell Global Identifier
17 CM Configuration Management
18 CPDR Common Project Data Repository
19 CPF Configuration Parameter File
20 DPM Development Project Manager

21 EMS Element Management System
22 eNB evolved NodeB BTS for LTE
23 ETSI European Telecommunications Standards

24 Institute
25 FPSA Feature Product Software Architecture
26 FRS Feature Requirements Specification
27 FTS Feature Technical Specification
28 GSM Global System for Mobile Communications
29 HW Hardware
30 HWref Hardware reference
31 ITU International Telecommunications Union
32 IP Internet Protocol
instruction

1 LTE Long Term Evolution
2 MIB Management Information Base

3 MIM Management Information Model
4 MME Mobility Management Entity
5 NA Not Applicable
6 NE Network Element
7 NEM Network Element Manager
8 NETCONF Network Configuration Protocol

9 NLT Network Level Test
10 OAM Operations, Administration and Maintenance
11 PCMD Per Call Measurement Data
12 PLM Product Line Management
13 PSA Product Software Architecture
14 R&D Research and Development

15 RAN Radio Access Network
16 RF Radio Frequency
17 RFC Request For Comment
18 RFM RF Module
19 SAE Systems Architecture and Engineering
20 SAM Service Aware Manager

21 SDE Software Development Environment
22 SEF Software Executable File
23 SEFid SEF identifier

24 SID System Interface Definition
25 SNAP Smart Network Antenna Panel
26 SNMP Simple Network Management Protocol

27 SRS System Requirements Specification
28 SV System Verification
29 SW Software
30 TBD To Be Determined
31 TMN Telecommunication Management Network
32 UMTS Universal Mobile Telecommunication System

33 URL Uniform Resource Locator
instruction

1 VLAN Virtual Local Area Network
2 WCDMA Wideband CDMA

3 WPS Wireless Provisioning System
4 XML eXtensible Mark-up Language

5
6 END OF DOCUMENT 
instruction

FTS For L163035 ENB Availability v01.01

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

FTS For L163035 ENB Availability v01.01

Загружено:

Авторское право:

Доступные форматы

FTS for L163035 eNB availability

FTS for L163035 eNB availability

Features Feature ID PPM ID Feature Title

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 1/34

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 2/34

17 3 IMPLEMENTATION IMPACTS (NON CUSTOMER VIEWABLE) .....................................................19

22 4 REQUIREMENTS (NON CUSTOMER VIEWABLE) ..........................................................................23

25 5 FEATURE IMPACTS ..........................................................................................................................26

30 6 FEATURE COMPLIANCE (NON CUSTOMER VIEWABLE) .............................................................28

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 3/34

1 7 RISKS AND OPEN POINTS (NON CUSTOMER VIEWABLE)..........................................................32

2 8 REFERENCES (NON CUSTOMER VIEWABLE)...............................................................................32

3 9 ABBREVIATIONS (NON CUSTOMER VIEWABLE) .........................................................................32

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 4/34

2 1.1 FEATURE CONTACTS (NON CUSTOMER VIEWABLE)

Document Owner Marius Lazar

Document Author(s) Marius Lazar, Francis Hargoa

PLM Prime Fred Davant, Jean Jacques Genet

CallP Prime Claudiu MIHAILESCU

OAM Prime Frank Mueller

SAM Prime Raphael Horn

3 1.2 SCOPE (CUSTOMER VIEWABLE)

7 It is intended to be used by:

18 1.3 FEATURE EXECUTIVE SUMMARY (CUSTOMER VIEWABLE)

24 • Number of eNB SW upgrades: 2 per year

25 • eNB availability (Partial and full outage with 2 SW Upgrades) = 99.996%

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 5/34

1 • eNB availability (Partial and full outage without SW Upgrade) = 99.997%

7 The target proposed is a predictable outage time elapsed, independent of

16 1.4 FEATURE BENEFIT (CUSTOMER VIEWABLE)

20 1.5 FEATURE BENEFIT TO ALU (NON CUSTOMER VIEWABLE)

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 6/34

2 2.1 GENERALITIES (NON CUSTOMER VIEWABLE)

3 2.1.1 Basic definitions

15 Example 1/ Loss of one sector on a eNB configured with a total of 3 sectors

19 Some unplanned partial outages could be discounted according to the daily

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 7/34

1 Part of traffic recovered by neighbour cells :

2 Partial and full unplanned outages can be discounted according to percentage of

10 2.1.2 Start-up duration

Requirements L101811 L112790 L112790 L115231 Light

eNB full reset (mm:ss) 5:00 2:30 2:30 2:30 2:00

eNB warm reset (mm:ss) 3:40 2:30 2:30 1:30 1:00

RFM full reset (mm:ss) 2:00 2:00 2:00 2:00 1:45

RFM session reset (mm:ss) N/A N/A N/A 1:00 tbd

23 1. There are different categories of uses-cases that imply a start-up:

24 a. Programmed reset from NEM/SAM due to Class A or even certain

26 b. Programmed reset from NEM/SAM due to HW update

29 ii. Major SW upgrades, FPGA’s SW, etc.

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 8/34

1 These categories of use-cases need a WARM RESET start-up.

2 2. Actually a Controller board reset implies Modems and RRHs/TRDUs reset

7 4. The Start-up duration is depending of synchronization source (1588 with

11 2.1.3 eNB availability

12 Reliability is not a functional feature, but a part of eNB effectiveness, which

16 2. To recover from an outage as quick as possible (start-up duration, outage

23 Key Inputs : % of traffic not recovered by neighbors % of eNB capacity

LTE/SYS/APR/038224 V01.01 / EN Draft 19/JUN/2012 Page 9/34

2 To measure eNB availability was retained five parameters:

5 2. SW failure rates (unexpected failures happening during normal

7 3. SW upgrade rate (planned operations)

8 4. Success ratio (in %) of maintenance operations (fault diagnostics and