WO1998028873A2

WO1998028873A2 - Update of network elements in a telecommunications network

Info

Publication number: WO1998028873A2
Application number: PCT/FI1997/000764
Authority: WO
Inventors: Jukka Kainulainen; Mika LINDGRÉN; Erkki Vedenkannas
Original assignee: Nokia Telecommunications Oy
Current assignee: Nokia Oyj
Priority date: 1996-12-13
Filing date: 1997-12-08
Publication date: 1998-07-02
Anticipated expiration: 1999-06-13
Also published as: FI102443B; FI102443B1; FI964998L; FI964998A0; AU5190798A; WO1998028873A3

Abstract

The invention is related to a method for updating network elements in a telecommunications network which comprises several network elements (N1, N2) which are connected to each other by means of data transmission links and which each have a unique address in the network. The data to be downloaded to the network elements is transmitted via the telecommunications network. In order to reduce the time required for the updates, an address message (SDA) is sent to all of the network elements for which the same data is to be downloaded before transmitting the data to be downloaded, the address message stating to the network element that it should use another network address in addition to its own address, this other address being the same for all of the network elements in question, and the data to be downloaded is transmitted simultaneously to all of the network elements in question by using the other network address for the transmission.

Description

Update of network elements in a telecommunications network

Field of the invention

The invention is related to updating data stored in network elements of a telecommunications network, especially to remote updating of software in the network elements via the telecommunications network. Below the network elements are also referred to as nodes.

Background of the invention In a telecommunications network there are often many similar devices which comprise similar hardware and software. The devices differ from each other only as regards the user-defined parameters. The number of such similar devices in one network may vary from a few devices to several hundreds, even thousands. When the software of these devices needs to be updated, the new software is the same for all of the devices. So, it is more practical for the operator to download the new software via the telecommunications network than to go to each station to update the software for individual devices. Downloading can be done, for example, from the network management system or the node management program or by using a separate download program.

In practice, the network management system may, for example, look like the system illustrated in Figure 1. Network operators located in the operating center OC use network management workstations WS connected to their own workstation network WSN which can be, for example, an Ethernet network. The management system is typically distributed to several computers in the workstation network. Some of these computers contain a database DB which contains the data required for managing the network. The management system is connected, for example, via an interface defined in the international standards, to the telecommunications network to be managed MN. Connection to the network to be managed is created via a telecommunications network DCN. Logically, there are two networks: (a) a network used for offering services to the customers and (b) a network for maintaining the network used for offering services, even though both the (payload) signals of the network to be managed and the management signals can be transferred physically in the same lines and transfer frames. Previous solutions for updating software in the network elements are based on remote downloading in which the software is downloaded separately for each device via the telecommunications network. As this method is slow, it has been made faster by packing the data to be transferred. This gives shorter transfer times. However, the remote downloading or updating of software is relatively slow, especially in large networks which have a large number of similar devices.

Summary of the invention The objective of this invention is to solve the above-mentioned problem and create a solution which can considerably speed up the remote downloading via a telecommunications network.

This objective can be achieved by using the solution defined in the independent patent claims. The idea of this invention is to send the data to be downloaded into the network only once using a separately defined address which is common to the nodes of the network (the network elements), so that all of the nodes to be updated receive the software at the same time.

In addition to faster software updates, the solution in accordance with the invention has the advantage of decreasing the load on the management bus as large amounts of data are not transferred in the network several times. (Software updates take place via the management bus.)

Brief description of the drawings In the following, the invention and its preferred embodiments are described in more detail with reference to the examples in accordance with the accompanying drawings 2-11 , in which

Figure 1 illustrates a network management system, which is used, for exam- pie, for updating software in the network elements,

Figure 2 illustrates the message transfer between the management system and two nodes during the downloading,

Figures 3...8 illustrate the structure of the messages in Figure 2,

Figure 9 illustrates the different states of the network element during the various stages of the downloading, Figure 10 illustrates the implementation of the management bus on the network level, and Figure 11 illustrates the parts of a node which are essential for the downloading.

Detailed description of the invention

In the following, the progress of the method in accordance with the invention is illustrated with reference to Figure 2 which illustrates the message transfer between the downloading system (network management system) and the nodes, and to Figures 3...8 which illustrate the fields used in different messages. Figure 2 shows two network nodes which are referred to as N1 and N2. The example assumes that the address of node N1 in the network is 5 and the address of node N2 is 8.

Before sending messages, the user defines the nodes and the board units of the nodes into which the new software is to be downloaded (that is, the user defines the addresses of the nodes for the downloading). Additionally, the user defines a common (node) address which is used for the downloading. The user can also define the address of the node which acknowledges the messages on behalf of all nodes during the downloading. However, this feature is not mandatory.

After this, the system performing the downloading informs the nodes for which the downloading is to be done of the common download address by sending each node a separate SDA (Set Download Address) message. Figure 3 illustrates one possible structure of the SDA message. The message comprises seven consecutive fields F1...F7 as follows: field F1 contains the node address (the management system is one node), field F2 the message identifier, field F3 the message length, field F4 the aforementioned common address, field F5 information about the node selected as the an- swering node, field F6 the password for downloading, and field F7 the length of time-out in minutes. Fields F1... F3 can be found in all download messages, which are described later. Field F2 contains the message identifier which is used for identifying the message, in this case the SDA message. Field F4 contains the node address which has been selected as the common address. In the example in Figure 2, the common address is 250 (F4=250). Field F5 is a Boolean variable which has the value "true" in the message sent for the node selected as the answering node and the value "false" in other messages.

The SDA message also cancels a previous unfinished download process if there is one. If the (node-specific) password in the F6 field is correct, the node answers by sending an acceptance message "READY", but if the password in incorrect, the node sends the management system a "MISSING RIGHTS" message which informs the management system that it has no right to update the node. In Figure 2, the first password sent to node N1 is incorrect and the management system sends an SDA message containing the new password after it has received a "MISSING RIGHTS" message from the node. The first password sent to node N2 is correct. If the node does not receive any other download messages within a pre-defined time period after the SDA message, the downloading is canceled and the node returns to the normal state. The length of this time period is defined in field F7. The same time-out is also used for canceling the downloading after other downloading messages, which are described below.

After this, the management system sends an RFD (Ready for Downloading) message separately for each node. This message initializes the node for download by clearing and checking its memory for receiving new program code. The node answers this message by sending a similar message which states whether the node is ready to receive program packets.

Figure 4 illustrates the fields used in the RFD messages. The messages may contain 4 different fields as follows: field F1 contains the node address, field F2 the message identifier which identifies the message as an RFD message, field F3 the length of the message and field F4 the current state of the node. The management system sends a message, which has fields F1...F3, and the node returns a message, which has fields F1...F4.

The answer field F4 may have three different values: "READY", "BUSY" or "FAULTY". The node returns the value "READY" to the manage- ment system when it has finished the above-mentioned initialization. As long as the initialization is unfinished, the node answers the management system by returning the value "BUSY" in the RFD message. The node returns the value "FAULTY", if it cannot receive new software, for example, due to a faulty board unit. When all nodes have returned either the value "READY" or the value "FAULTY", the downloading of the software begins. This is done in such a way that the management system sends data messages (DP, Download Packet) to the nodes. Field F1 of a data message states the common node address which was given to the nodes by using the SDA message.

Figure 5 illustrates the structure of a data message (DP). The mes- sage comprises seven consecutive fields F1...F7 as follows: field F1 contains the address, field F2 the message identifier, field F3 the message length, field F4 the offset value stating the packet number, field F5 the length of the unpacked data packet, field F6 the check sum and field F7 the actual data (program code). The data is sent packed in the data field of message DP. The packing (compressing) of the data to be sent is done by using some known algorithm and after that a CRC check sum is calculated for the data field and placed in field F6. Field F5 states the length of the unpacked data field.

After receiving a data packet, the node calculates the checksum using field F7 and compares the checksum to the contents of field F6. If the comparison shows that there is an error, the node does not unpack the packet, but saves the values of fields F4 and F5 in order to ask for a resending of the packet later. If the node does not find any errors, it unpacks the packet. Only the node selected as the answering node (node N1 in the example in Figure 2) acknowledges the reception of the package by sending an answering message (message ACK).

Finally, when all data packets have been sent, the success of the downloading is checked separately from each node. The management system sends the Program Downloading Acceptance (PDA) messages separately to each node. Figure 6 illustrates the fields used in the acceptance messages PDA. The messages comprise seven different fields F1...F7 as follows: fields F1...F3 contain the address, identifier and message length, respectively, field F4 the length of the unpacked program, field F5 the acceptance data, field F6 the offset value and field F7 the length of the packet. In addition to fields F1...F3, only field F4 is used when the management system queries the node about the success of the download. This field is used for transferring the length of the unpacked program, so that the node can use it to check whether the download was successful.

The node returns the information concerning the success of the download in a PDA message, whose F5 field has three possible values: "false" means an unrecoverable error, "true" means that the download has succeeded and "resend packet" is used for requesting the management system to send the packet again. The requested packet is identified by stating the offset value of the packet in field F6 and the length of the packet in field F7. If the downloaded program has been received without errors, the PDA message returned by the node includes fields F1... F5 in which the value of field F5 is "true". If the downloaded program has been received otherwise correctly, but some packet must be sent again, the PDA message returned by the node includes fields F1...F7 in which the value of the F5 field is "resend packet". If the downloading was done so poorly that the node cannot even determine which packet should be sent again, the PDA message returned by the node includes fields F1...F5 in which the value of field F5 is "false".

When the management system has resent the requested packet (and when the node has answered, if it is the answering node), the management system again sends a PDA message to query the success of the down- load. The node again answers by sending one of the above-mentioned replies. This process is continued for each node until all packets have been transferred correctly to the node (or until the node states that an unrecoverable error has occurred).

When all packets have been transferred correctly, the management system uses the common address to send a Program Identification Code (PIC) message which gives the identifier of the downloaded program for the nodes. Figure 7 illustrates the structure of the program identification code message. The message comprises seven consecutive fields F1... F7 as follows: fields F1...F3 contain the address, identifier and message length, respectively, field F4 the program version number, field F5 the user identifier for the program and field F6 the date. Field F7 is reserved for comments. The node saves the program identification information after it has accepted the download. The node acting as the answering node answers the PIC message by sending the message "DONE " to the management system. After this, the management system uses the common address to send a Program Change-Over (PCO) command to all of the nodes. Figure 8 illustrates the structure of the program change-over command. The message contains only the fields F1... F3 described above.

As a result of this, all nodes make the program change-over, but only the answering node sends information about the successful change-over. After this, the node does not receive any messages sent by using the common address until it receives the next SDA message stating the common address.

As the description above states, all of the nodes listen to the messages sent by the management system, but in the normal state each node receives only the messages which are sent to its own address. During the downloading the nodes are further assigned a common address which is used only for the downloading. The preferred value of this address is such that none of the nodes use it for any other purpose.

Figure 9 shows a state machine which illustrates the downloading process described above as regards an individual node. At first, the node is in the normal state NS. When the node receives an SDA message, it stays in the normal state, but enters a sub-state to wait for download messages. The node changes state only when it receives an RFD message stating that the download is about to begin. Now the node changes into the download state DL and waits for downloading and the program code packets. After receiving the RFD message the node begins to receive messages which have the common address.

From the download state the device changes into a download verification state only after it has received a PDA message which is used to query for the success of the download. The device remains in this download verifica- tion state until it has received all packets correctly, that is, the whole program is in the device. The device enters the normal state when it has received the identification information for the new program (the PIC message).

The commissioning of the new program takes place in the normal state after the nodes have received a command to change the software (a PCO message) from the management program. If an incorrect download message is received at some point or the time limit for the waiting is exceeded, the downloading is canceled and the node returns to the normal state.

It should be noted that the states illustrated in Figure 9 are states related only to the downloading. The node operates normally during the downloading, and inside the device the other functions have their own states which are not necessarily dependent on the states of the downloading nor is the downloading dependent on their states.

The transmission links coming to the node can be, for example, SDH connections in accordance with ITU-T recommendations G.708 and G.709 or 2048 kbit/s signals in accordance with the G.703 and G.704 recom- mendations, one frame containing 32 time slots (TS0...TS31) and a multiframe containing 16 frames.

In the event of an SDH signal, the management information is transferred in the header bytes reserved for the management channels. In the frame structure of the 2048 kbit/s signal in accordance with the G.703 and G.704 recommendations, the management information can be transmitted, for example, in such a way that the management channel reserves from the frame structure, for example, 3 bits from the bits of the TSO time slot. Every other frame has a frame alignment signal in the TSO time slot, but in other frames the bits 4-8 are available for national use, which means that they can be used for transferring network management information. These bits are used for implementing an asynchronic management connection. A sample is taken from the management channel at a certain sampling frequency and, in accordance with this, either a logical "0" or "1" is sent to the channel in order to create an adapted asynchronic connection in a synchronic communication channel. The nodes have summing points in which data coming from different directions can be summed up and transmitted to different directions. Only one transmitter transmits at a time, so there is no risk of collision. In the summing point of the node the channels coming from different directions are combined. Data coming from a certain direction is connected (transmitted) to all other directions.

In principle, the summing device is very simple. It makes a simple logical AND operation for the management channels connected to it. If even one of the signals has a zero state, the result is zero. In practice, this means that the idle state of the channel is "1". In other words, if the device does not transmit anything, it remains in state "1". The channel coming from the node control block to the summing device is in state "1" when the node has nothing to transmit, which means that it does not affect other channels in any way. The traffic is in serial form as regards the summing device and the communication blocks of the devices connected to the management channel. At some stage the data can be in parallel form, but when it comes to the summing device, it must be converted to serial form.

At the network level the implementation of this kind of a management bus can be seen in such a way that the network management system is connected to the management bus in one network node via which it can access other nodes of the network by using the management bus. This is illus- trated in Figure 10, which shows a network having a master node M and eight nodes 1...8. The network management system NM connects to node 2. Dotted lines show the normal data connections between nodes and the thick continuous line shows the management bus MB. In reality the management bus is formed by normal data connections (it operates within the normal data connections), but logically it is a network separate from the normal data connections.

As the invention is not related to the implementation of the management bus and because the management bus can be implemented in a known way, the implementation of the management bus is not described in more detail here. What is essential for the invention is that each transmitted packet goes to each requested node of the network or sub-network and that each of the said nodes can receive packets which have either the node address or the common address. The following describes in more detail, with reference to Figure 11 , those parts of a node, which are essential for the downloading. A node typically has a control unit (CU) and additional board units, which are referred to as B^ and BU_n .

The management messages MM coming from the network are re- ceived by the message handling part MH of the node. The messages are received either via the board units acting as node interfaces and via the node's internal bus system (IBUS) to the message handling part or, if the interfaces are in the control unit, within the control unit directly to the message handling part. The node control unit can also have a separate management interface into which the management system is connected directly.

The message handling part checks the address of each message to determine whether the message is intended for the node in question. The message handling part distributes the messages transmitted to the node further to the different control units of the node, for example, the messages con- cerning downloading of a program to the program download control unit PDU. These separate control units process the actual contents of the messages. If the interfaces of the node are on a different board unit than the control unit, it is preferable, in order to avoid unnecessary internal traffic, that the interface units also have local message handling parts which transmit to the centralized message handling part MH only those messages which are meant for the node. The node's own network address is stored in the memory (memory area MA1) connected to the message handling part. When the program download control unit PDU receives an SDA message, which is used for setting a common download address, it stores the download address in the mem- ory (memory area MA2). When the ready for download message RFD is received, the program download control unit commands the message handling part MH or the local message handling parts, if those are used, to also receive the messages which have this common download address as the recipient address. When actual program packets are received, the program download control unit stores them to memory (memory area MA4). At the same time it monitors the received packets for missing packets or packets received erroneously. The program download control unit maintains a list of these packets in memory area MA3. When the success of the download is queried, the program download control unit requests the resending of these packets and the node sends one or several PDA messages to the management system as described above.

The method described above is the basic implementation of remote downloading and it can be varied in many ways. Possible variations are de- scribed in the following.

As one node often consists of several board units, the program download control unit can also be distributed. In this case the node control unit, which receives the management messages, contains the central unit (PDU) which handles the download messages and relays the contents of the program packets via the internal bus system of the node to board unit(s) for which the program update is to be done. The board units to be updated can have their own local program download control units LDU, which receive internal messages, or, alternatively, the centralized program download control unit PDU can write the new program directly to the memory (LM) of the board unit to be updated.

The operation of the node can also be modified so that it can continue an interrupted download even though the time limits have been exceeded or a wrong download message has been received.

The node operation can also be divided in different ways between the message handling part and the program download control unit. The latter may, for example, handle only the program packets while the message han- dling part takes care of listing the missing packets and communicating with the management system.

The network may also contain a node that has been configured specifically for the download and which acknowledges the program packets on behalf of all of the nodes. On the other hand, as was mentioned before, the acknowledgments may be omitted entirely.

Even though the invention has been described above by referring to examples according to the attached drawings, it is clear that the invention is not limited to this example, but it can be varied within the boundaries of the concept of the invention described in the attached claims. For example, it is possible to configure the common download address to the nodes permanently so that it is not necessary to state its value in connection with the download. Further, the method is not necessarily bound to program updates but can also be used for other updating of data.

Claims

1. A method for updating network elements in a telecommunications network, which comprises several network elements (NE) which are connected to each other by means of data transmission links and which each have a unique address in the network, in accordance with which method the data to be downloaded to each network element is transmitted via the telecommunications network, characterized in that,

- before transmitting the data to be downloaded an address message (SDA) is sent to all of the network elements for which the same data is to be downloaded, the address message stating to the network element that it should use another network address in addition to its own address, this other address being the same for all of the network elements in question, and

- the data to be downloaded is transmitted simultaneously to all of the network elements in question by giving the other network address to the data to be transmitted.

2. A method according to claim ^characterized in that the other network address is transmitted to the network elements in an address message (SDA).

3. A method according to claim \, characterized in that after the transmitting of the address message and before transmitting the data, an initialization message (RFD) is transmitted and, in response to that, the network element initializes the memory and changes into a state in which it can also receive messages which have the other network address.

4. A method according to claim ^characterized in that the success of data download is checked separately from each network element.

5. A method according to claim ^characterized in that after all of the network elements have accepted the data download, a data changeover (PCO) message is sent to the network elements using the other address.

6. A method according to claim ^characterized in that the address message (SDA) also states whether a network element should acknowledge the reception of data.

7. A method according to claim ^characterized in that the address message (SDA) also gives a password, whereby the network element only starts the reception of data if the password is correct.

8. A method according to claim 7, characterized in that the password is specific to the network element.