No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>


To have a better experience, please upgrade your IE browser.


The PBU cannot be upgraded when BTS3512 software is upgraded

Publication Date:  2018-04-11 Views:  131 Downloads:  0
Issue Description
TRXs are upgraded to G3BTS32V302R005C08B013SP01 to expand the capacity for EDGE network application. During the upgrade, the PBUs for some sites cannot be activated. However, the maintenance console shows that the activation succeeds, and that the PBU board status is abnormal, which is normal for about 2s and then becomes faulty for 2s. The board software information cannot be obtained, and no alarm is reported. The PBU software version is rolled back onsite, but the rollback fails.

Version information

Handling Process
The PBU cannot be activated at a GSM-R site for the Datong-Qinhuangdao railway line. The CBUS2 messages generated during onsite board activation show that the PBU board reset process performed onsite is abnormal. A normal PBU board reset process is as follows:

The PBU board sends its reset reports to the TMU, the TMU sends an OPSTART message and power information to the PBU, and the PBU receives the OPSTART message. However, when the PBU board is activated onsite, the TMU does not deliver an OPSTART message.

PBU code shows that the PBU will send a reset report to the BTS every 5s if it does not receive any OPSTART message. Onsite BTS logs show that there is a large number of "PBU Statement is Normal" data pieces and that the PBU records information about a single board every 5s.

Based on the PBU activation process and BTS logs, it is suspected that the TMU incorrectly processes the reset report from the PBU and fails to send an OPSTART message to the PBU in compliance with the software code. However, the code analysis shows that all PBU board reset functions are processed properly. In this situation, the BTS logs of the live network are analyzed, and several global variables related to OPSTART message delivery are checked onsite. The results show that the global variable which specifies whether to send an OPSTART message to a TRX is set to 1 and that the number of times this message is sent to the TRX is also 1. The two values indicate that the OPSTART message to be sent is available in the OPSTART send queue and that this message is sent only once, without any retransmissions. In normal situations, this message will be retransmitted if the previous delivery fails. If this message fails to be retransmitted three times, global variables related to this message will be modified, and this message will be removed from the send queue. However, onsite conditions indicate that the OPSTART send queue is suspended, and no retransmissions are performed.

The onsite OPSTART send queue is displayed based on user-defined messages. The displayed information shows that the number of OPSTART messages in the OPSTART send queue has exceeded the maximum value. In addition, BTS logs indicate that the TMU has never retransmitted an OPSTART message before PBU software is loaded.

Check whether OPSTART-related operations have been performed during the period when the TMU sends the last two OPSTART messages. Based on the result, it is suspected that this problem is caused by the OPSTART message sent to TRX 4.

Establish a mirror environment and modify the TRX channel type to trigger the BTS to deliver an OPSTART message. Then, query the content of the OPSTART send queue. The content shows that an OPSTART message is added to the OPSTART send queue each time the channel type is modified. This symptom indicates that the problem has been reproduced because an OPSTART send queue in normal situations will be cleared once messages in this queue are sent.

Analyze the process of sending an OPSTART message upon a channel type change. The analysis result indicates that channel-level OPSTART messages are unexpectedly processed by the SendOpstartToTrx function. To ensure that channel-level OPSTART messages are promptly responded during dynamic data configurations, for channel-level OPSTART messages, an OPSTART ACK message is simulated, which requires no further processing; for other types of OPSTART messages, the SendToTrx function helps send OPSTART messages to TRXs and start a timer which waits for the TRXs to return OPSTART response messages to the TMU.

When the TMU processes the OPSTART ACK function, it preferentially checks whether the timer value is empty. If it is, it returns a blank value and does not perform any processing. When the OPSTART messages are sent, the specified values of global variables will not be initialized. This way, subsequent OPSTART messages cannot be sent because they regard that previous OPSTART messages are still being sent. During this period, OPSTART response messages are returned for OPSTART messages in the queue head, and involved global variables cannot be initialized. As a result, OPSTART messages in the OPSTART queue remain congested and cannot be released.

The OPSTART messages sent by the TMU to TRXs have two functions.

When the TMU processes the OPSTART ACK function, it checks whether a TRX connecting to a cavity has reported an activation request. If it has not, the power amplifier is turned off.

The TMU sends OPSTART messages to specified TRXs to obtain the service capabilities supported by the TRXs.
channel-level OPSTART messages. The simulated message ensures that channel-level OPSTART messages are promptly responded during dynamic data configuration. However, the time for sending the simulated message is incorrect, and this message is sent before an OPSTART message. Consequently, the timer specifying the time for sending an OPSTART message is not started, but OPSTART ACK messages are directly responded. In addition, the global variables corresponding to the OPSTART send queue are not initialized. In this situation, the channel-level OPSTART message will be always waiting in the OPSTART send queue and cannot be sent. As a result, all subsequent OPSTART messages will be congested in the OPSTART send queue.

When the PBU is activated, the PBU preferentially sends a reset report to the TMU. When the TMU software receives the reset report, it sends an OPSTAR message to the PBU. However, this OPSTART message is congested in the OPSTART send queue and cannot be sent to the PBU. Consequently, the PBU sends a reset report every 5 minutes. As a result, the OPSTART send queue is full.

When the BTS G3BTS32V302R005C08B013SP01 is upgraded, upgrade the PBU based on the original TMU software version and then upgrade TMU and TRX board software.