Software and database management

Software and database management is all about controlling the OSWP (Operation SoftWare Package) on the system. On the ISAM a set of software and database management features are available, that are both powerful and efficient from an operational point of view.

A Push-Button Migration tool (PBMT) is delivered together with the ISAM software. This tool provides all the required functionality to migrate and/or upgrade an ISAM to a new software load, automating all the different steps of the software upgrade and migration process.

The PBMT is expected to run on the same machine as the 5520 AMS, as the PBMT needs certain specific files for its proper execution.

The PBMT is supported on both a Sparc and x86 platform (Solaris OS), delivered as one installation package. At run tim, the correct libraries and executables will be selected. Support is only provided for migrations to the target release (that is, the release for which the PBMT is delivered).

OSWP and databases

The ISAM is capable of hosting an active (operational) and a non-active (stand-by) Operational SoftWare Package (OSWP). Each package consists of a software version and a set of system databases. Only one of the 2 OSWP packages can be active in the ISAM, but the operator can switch between packages, making the one operational, and the other stand-by.

4 — Management

Each package also consists of a set of system databases, more in particular the IHub database, the IACM database and the xVPS databases (one physical database per xVPS pair). From an operational point of view, if not mentioned otherwise explicitly, the actions (backup, restore, migrate…) will be executed on the set as a whole, not on an individual database of the set.

What, in case of GPON deployment, is not part of these packages however is the ONT software. All ONT software files are stored in a dedicated 1G partition on the compact flash (CF) of the NT. All ONT data, managed via the ISAM, is part of the IACM database: the ONT can have its own database as well, this however not being managed by/via the ISAM. The OLT software and database is part of the OSWP as described above. The link between the ONT type and/or a specific ONT instance and its (specific) ONT software is (persistently) stored in the ISAM MIB - the partition on the NT CF is only a storage for the ONT software files. Management of these software files (downloading to the ISAM, deleting, …) is done via an external manager, be it the 5520 AMS, the PBMT (Push-Button Migration Tool) or using CLI and/or TL1.

Software upgrade and migration

Of course there are rules on compatibility between software and databases: a package can only become active, when the software version and the system databases in the OSWP are compatible with one another. In this context, we make a distinction between:

• Software upgrade is the process to upgrade a network element to a higher software release not involving a migration of the system databases - there is no system database change

This procedure is typically to be used when upgrading to a release in the same software stream, for example, from R3.6.01 to R3.6.03c

• Migration is the process to upgrade a network element to a higher software release requiring a migration of the system databases

This procedure is normally to be used when upgrading to a release from a higher software stream, for example, from R3.6.01 to R4.0.02

A complete software upgrade/migration activity consists of a sequence of actions:

1 The operator demands the system to download a new OSWP. This demand is the trigger for the system to initiate a file transfer session with the external file server specified by the operator. So it is not the operator who puts the software on the system disk.

2 In case of GPON, new ONT software is placed on the NT CF by the 5520 AMS, PBMT and/or using CLI or TL1, potentially together with a clean-up of older software files.

3 The operator starts an off-line conversion of the database from the source release

4 — Management

4-28 November 2013 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 4 In case of GPON, the ONT software is pre-downloaded to the ONTs at operator

demand. The software is downloaded to the ONT via the OMCI channel, but is not activated yet on the ONT - also the ONT can have an active and a standby software load in parallel

5 When the new OSWP is downloaded, and, in case of GPON, the new ONT software is pre-downloaded to the ONTs, the operator activates this new OSWP.

The system will restart and come up with an upgraded software version. All persistent configuration data remains available. Due to the new ONT software description in the ISAM database, the OLT will trigger the ONTs to restart with the new ONT software.

6 Once the upgrade is successful, the operator can remove the former OSWP from the system in order to free space for the next upgrade.

Some remarks:

• The ONT software is pre-downloaded to the ONTs using the OMCI channel, prior to the activation of the new OSWP.

• The ONT software activation is triggered by the OLT, also using the OMCI channel.

• OLT and ONT software activation are not coupled: OLT and ONT software can be upgraded independently if required.

Note that migrations and software upgrades do not have to be between consecutive software releases/streams: the necessary functionality has been provided to be able to 'skip' intermediate upgrade/migration steps. While no point for software upgrades, this is less evident for migrations.

Also, in case of a failure to upgrade, the ISAM will automatically switch back to the OSWP and resume services. This also implies that the ONT will also re-start with the old, previous software, as the ONT software activation is triggered by the OLT, following the configuration settings done before. If the ONT itself fails to start with the new software load, the ONT will also re-start autonomously with the previous, old software load. The OLT software will NOT be restarted in that case. This implies that the ONT will not be able to support the services and features of the correct, new load, but, as the ONT becomes active again, a new load can be downloaded and the restart of the ONT retried.

Note — Due to the introduction of a new version of the IPD stack (SROS ed.08) in R4.3.01, a R4.3.01 (or higher) ISAM database is NOT backwards compatible with a R4.3 ISAM database!

The necessary functionality has been added to make sure the R4.3 OSWP, with related (R4.3) database, can still be activated again, even after a successful R4.3.01 upgrade. The changes done with R4.3.01 will of course be lost as the R4.3 OSWP can -not- work with a R4.3.01 (or higher) version of the database. R4.3.01 (or higher) can work with any R4.3.x database; in case R4.3.01 (or higher) starts with a R4.3 version of the ISAM database, the R4.3 database will be upgraded first.

4 — Management

Backup and restore

Next to a software upgrade and/or migration, database management also requires the regular creation of backups in order to minimize the configuration loss in case of a system crash. This can be done either manually or automatically. These ISAM backups can afterwards be restored on the ISAM if needed.

For IHub-based NT boards, only one type of backup can be taken, always containing all the ISAM configuration data and all the ISAM OAM data for remote management (such as the IP address, next-hop and so on).

Note that in case of automatic backup enabled, the TFTP protocol cannot be used, as the TFTP protocols implies the file name to be known already up front at the server side. Given the format of the generated backup file name, this is however not possible. Alternatively SFTP or FTP can be used.

The configuration data of the ISAM is autonomously saved to the ISAM database on the NT CF at different criteria:

• IACM: the database changes are cached in the system and autonomously saved to the CF

• Every 60 seconds, and/or

• Whenever the cache of 5K is full (corresponds to 22 database updates), and/or

• On request of an IACM application, for example to safeguard some critical data (software steered), and/or

• As part of an ISAM database backup request

• xVPS: the database changes are autonomously saved to CF

• Every 10 minutes if the xVPS configuration has changed indeed and the last xVPS configuration change is at least 1 minute ago, and/or

• As part of an ISAM database backup request

• IHub: the database changes are autonomously saved to CF

• Every 10 minutes if the IHub configuration change, and/or

• As part of an ISAM database backup request

The IHub configuration data can be saved to NT CF (database) at operator request as well, for example, at the end of a IHub configuration script. This is however not possible for the IACM data.

Note — Due to the introduction of a new version of the IPD stack (SROS ed.08) in R4.3.01, a R4.3.01 (or higher) ISAM database is NOT backwards compatible with a R4.3 ISAM database!

This implies that R4.3 can only work with a R4.3 version of the ISAM database and it is NOT possible to start R4.3 with a R4.3.01 (or higher) version of the database.

4 — Management

4-30 November 2013 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02

Active load

The release name of the current active ISAM software package (for example, R3.6.01) can be consulted via EMS, TL1 and CLI.

Voice service management

The behavior of POTS voice services on ONTs can be controlled by downloading a service configuration in XML format onto the ONT. This XML file can be sent to the ONT via the in-band communication channel, used to provide data service.

In some cases, operators may require that the XML is downloaded to the ONT via the Management VLAN, in order to provide a higher level of security. This approach includes the following steps:

1 The Element Manager generates the ONT service configuration in XML format and makes it available on an FTP server reachable by the ISAM

2 The ISAM NT downloads the XML file from the FTP server 3 The XML file is sent to ONT using an internal OMCI channel

This approach is supported on Alcatel-Lucent Single Family Unit (SFU) and Multi-Dwelling Unit (MDU) ONTs that do not use TR-069 for voice provisioning.