Wireless địa phương vòng - lý thuyết và ứng dụng P12 pps

12.3Remote Upgrade of Fixed Subscriber Units12.3.1 Characteristics The key functional characteristics of the remote upgrade or down-line-load DLL mechanism are: Broadcast By the virtue o

Remote Management and

Upgrade in a Wireless Local Loop System

Thomas Jagodits and Hans Bhatia

12.1 Introduction

Wireless Local Loop (WLL) is projected to experience phenomenal growth over the next years The nature of WLL is such that terminals are not mobile and once installed the subscriber expects trouble-free operation without any service requirements Meanwhile, new functionality involving enhanced codecs and modems are being de-veloped and expected to be made available to the subscriber A major challenge facing WLL operators consists of upgrading WLL terminals that are already deployed at the customer site with new functionality [1,3] Another challenge is the ability to monitor terminal service parameters and events without obtaining physical access to the device

The main factor that enables scalable propagation of software images and tracking events at WLL terminals is the dissemination of FLASH-based devices The cost of FLASH memory has been decreasing, becoming the memory device of choice in many wireless devices

This chapter presents mechanisms that enable propagation of software images to wireless terminals and remote capture of events on the same terminals Both mechanisms have been implemented in a Wireless Local Loop system The remote upgrade mechanism was used to successfully propagate dozens of software releases in multiple markets The monitoring mechanism is being used daily to remotely monitor the operational status of thousands of WLL terminals

Section 12.2 provides a general overview of the WLL application, Section 12.3 details the remote upgrade mechanism including implementation at the wireless device, in this case a Subscriber Unit Section 12.4 describes the event logging mechanism used for remote management and the last section concludes this chapter

261

Copyright # 2001 John Wiley & Sons Ltd ISBNs: 0±471±49846±7 (Hardback); 0±470±84187±7 (Electronic)

12.2 Wireless Local Loop Application Overview

Wireless Local Loop (WLL) provides affordable local telephony access that can be deployed quickly Several companies provide WLL solutions, the most popular digital air-interface protocols being Time Division Multiple Access (TDMA) and Code Division Multiple Access (CDMA) Hughes Network Systems AIReach(tm) Local Loop TDMA system provides a flexible, high-capacity WLL platform based on digital TDMA access This system is currently deployed in 8 countries with over one million subscribers under contract worldwide

In order to propagate new features and software fixes to the installed base a mechanism that involves over the air propagation (remote upgrade) of software images was imple-mented in the Hughes Network Systems (HNS) platform To enable this mechanism, HNS expanded the air-interface protocol and implemented collateral modifications at both the Base Station Controller (BSC) and the Fixed Subscriber Units (FSUs) The FSU is a WLL terminal located at the subscriber premises, providing residential or commercial wireless access Figure 12.1 shows a typical WLL system

By definition FSUs cannot move into a better RF environment to alleviate signal fading Subscribers also expect them to operate reliably with little or no maintenance

In a commercial system with tens or hundreds of thousands of units the need to remotely gather operational information from each unit is critical FSUs in the HNS system continuously capture operational and link-based events These data are relayed on demand to the BSC where it is used to maintain overall system statistics and take corrective actions when necessary

FSU

FSU

FSU FSU

BTS

PC

Telephone

PSTN

Telephone Telephone

Figure 12.1 Typical WLL System

12.3Remote Upgrade of Fixed Subscriber Units

12.3.1 Characteristics

The key functional characteristics of the remote upgrade or down-line-load (DLL) mechanism are:

Broadcast By the virtue of the wireless transmission medium, broadcast is used for simultaneous download to all or selected subscriber units The transmission is secure to the extent that the receiving subscriber unit complies with the FE-TDMA (Fixed Enhanced TDMA) and down-line-load protocols to receive and decode messages Retransmission The subscriber units may also inform the BSC about missing records after each load module has been transmitted The reporting period is randomized among subscriber units to avoid collision on the same transmission medium, which rarely should happen due to the fact that missing records event itself occurs randomly among the FSUs The BSC collates the missed records and retransmits them as a bundle at the end for optimal throughput

Automated Download While network load is low, the BSC scans through the database of registered subscriber units and automatically downloads a configured release to units operating with older releases

Software Image Partitioning The whole software image to be down line loaded is labelled and partitioned into multiple load modules Each one of these load modules

is transmitted over the air in an order specified by the BSC.The remote upgrade (DLL) is initiated at the BSC via a graphical user interface (GUI) or command line interface (CLI) The minimum parameters required for a DLL are the label of the new software image and the specification of the cell in which the down-line-load is to be performed Optional parameters include Mobile Identification Numbers (MINs) and the specifying the label of the existing software to be upgraded or downgraded These last two parameters are exclusive

Each release consists of multiple load modules and three configuration files The load modules contain the data to be broadcast by the BSC The first configuration file lists the files to be transmitted by the BSC when a release is downloaded The second configur-ation file contains the checksum of the load modules, it is used by the BSC to verify the integrity of the load module files before transmitting them The third configuration file determines how to load an FSU with a release This file specifies how to upgrade an FSU

to a new release and how to downgrade an FSU to a previous release In some cases, it might be necessary to first load an intermediate release before loading the final release This configuration file informs the BSC of the upgrade path

When the BSC receives the download command from the Operator Console or as a part

of the automated download, the BSC filters out the list of subscriber units to be down-loaded Then it selects a list of free channel slots, allocates them for download and broadcasts this information through a Broadcast Forward Control (BFC) message to all the subscriber units to prepare the units to receive information conveyed over the down-load channels

After the BFC message, the Base Station Controller will send a DLL Header message

on all the download channels The subscriber units use this information to decide whether

to participate in the DLL (see Figure 12.2) Next the BSC proceeds to download each individual image file sequentially Subsequently the BSC checks if it can access the load module file stored on disk of the Operator console by mounting the corresponding file system via the backbone LAN The file is transferred through the standard File Transfer Protocol [2] to local memory If the transfer is successful, the transmission of load modules over the air is initiated on a channel

Missed records reported by subscriber units are assembled at the BSC At the end of the transmission of the load module, the BSC explicitly requests the subscriber units to inform about the missed records After collating all the responses, it retransmits those that were missed This process is repeated until no responses are received for the retransmission

DLL Header Message

DLL Trailer Message

LM Header Message

LM Record Messages

LM Trailer Message

LM Header Message

LM Trailer Message

LM Record Messages DLL Broadcast Message

Figure 12.2 Typical Remote Upgrade Message Flow

request, at which time the BSC sends Load Module Trailer message to the subscriber units for indication of the completion of load module and for checksum match

The process of load module transmission is repeated for all the load modules that are part of an image file At the end, the BSC sends the DLL complete trailer message to the subscriber units and deallocates the channels used for the DLL A remote upgrade may be performed to specific MINs, specific FSU models or to a whole cell It is initiated through the BFC message The messages that comprise the actual down-line-load are: DLL header message, DLL Trailer Message, Load Module Header Message, Load Module Record and Load Module Trailer Message

The contents of each message are as follows:

DLL Header MessageÐThis message is the very first message transmitted by the BSC when starting the DLL This message is transmitted on a channel selected for the down-line-load channel by the BSC It contains all the information necessary by the FSUs to decide if they will participate in the down-line-load process

DLL Trailer MessageÐThis message is the last message transmitted by the BSC, it contains the status of the DLL termination If the DLL is aborted at the BSC it will be indicated in this message This message can be send at any time during the down-line-load by the BSC

Load Module Header MessageÐThis message which is send by the BSC is the preamble for individual load modules It contains information on the overall load module size and the number of records in this load module

Load Module RecordÐComprises the actual image data In addition it also contains a sequence number so any message loss can be detected immediately Each Load Module typically consists of multiple load module records

Load Module Trailer MessageÐMessage send by the BSC indicating the end of transmission of a load module It contains a checksum that enables the immediate detection of any corruption in the load module It provides a second level of integrity

on the data, the modem provides the CRC check on individual messages, this check-sum provides the CRC check on the whole load module

Missing Record Request MessageÐMessage send by the BSC that can be used for retransmission of specific DLL records It contains data and sequence numbers of the records that are being retransmitted

Missing Record Response MessageÐthis is the message that optionally can be sent by FSUs to request missed records It contains a list of records that were not received by the FSU

12.3.2 Remote Upgrade Processing at the Fixed Subscriber Unit

A DLL is initiated at the BSC by transmitting the corresponding BFC message The Fixed Subscriber Unit processes the DLL notification by tuning to the first DLL stream

On receipt of a DLL Header message the Fixed Subscriber Unit will ensure that this is not a duplicate message and if the unit is in a state in which it can accept a down-line-load For small scale FSUs that typically are located in residential premises, this involves checking if any calls are up or if the unit is running on battery power The FSU will also verify if the unit should participate in the download, this is achieved by processing the image label and MIN fields If the header indicates that the down-line-load is targeted for

a different FSU model the unit will not participate in the DLL Similarly, if the unit already has the software image loaded or if it's MIN is not in the provided MIN list the unit will simply stop tuning to the DLL stream

On receipt of the first Load Module Header message the FSU will allocate memory to process the load module records After a complete load module is received, that is, all load module records have been received, the load module is stored in a pre-defined scratch area

in FLASH A load module is only moved to the actual target image location when all load modules and the appropriate DLL trailer message have been received In this manner the unit is not impacted if there is a power outage or if individual load modules are corrupted

If the FSU is participating of a DLL and receives the DLL Trailer message with an indication that the DLL has been completed successfully at the BSC it confirms that the load modules have been received properly by performing the checksum on all load modules If the checksum matches it will update the FLASH with the new image and restart the unit

A DLL is aborted if any of the following three conditions occur If the DLL Trailer message indicates that the DLL should be aborted the DLL is terminated And also if the subscriber originates or receives a call the DLL is terminated, this ensures transparency to the end user Depending on the model it is desirable to abort the download if the unit is operating on battery because writing to FLASH in very low power conditions could corrupt the memory

The option to selectively request missing records is not always exercised at the sub-scriber unit If too many subsub-scriber units would request missing records simultaneously it could impact the operation at the BSC Instead the software upgrade relies on the automated download capability to ensure that all terminals are upgraded

12.4 Event Logging for Remote Management

During operation the FSU captures link and operational events continuously These are selectively stored in RAMor FLASH memory and include forward channel based RF statistics, hardware failures if any, operational inconsistencies, power events, etc

The remote management is initiated periodically at the BSC through a screen or through a command line interface script when network traffic is low Optionally remote management can be started at the BSC for monitoring purposes or in response to specific customer complaints

The remote management implementation in the HNS system involves three distinct operations necessary to provide remote network management: link, terminal and poll Each of these operations consists of a query by the BSC and response by the FSU Remote Management Link Operation To provide link data the FSU continuously gathers forward RF information over time It maintains statistics on minimum and maximum RSSI values, BER, CRC errors and number of messages received per frequency Each message received from the BSC in the forward direction is an event and the corresponding information is stored in RAM The operation query is received through a MIN based FC message and the response is relayed through FACCH messages, the BSC will retry the operation if no response is received from the FSU

Remote Management Terminal Operation Information pertaining to this operation includes state of the FSU, reason and time of the last resets, forward signal quality indication, power status and status of the last down line load With the exception of the signal quality indication and power status all data is stored in FLASH each one as a distinct event with corresponding timestamp These event data are not lost between resets The operation query by the BSC is also received through a MIN based FC message and the response is relayed through FACCH messages, the BSC will retry the operation if no response is received from the FSU

Poll Operation This consists of a query with minimal overhead to verify if the FSU is operational and is similar to the IP based `ping' command This command consists of a

FC Poll query message and response; it requires minimal air bandwidth and typically is not retried at the BSC

Output of the operations is saved in files at the BSC for post processing or future reference This provides the ability for tracking the wireless system over time, comparing distinct WLL networks and identifying any performance issues Table 12.1 shows a sample output of a terminal operation for seven FSUs

Similarly the results of the link operation are MIN based Table 12.2 shows a sample output for a two FSUs in a cell with 12 frequencies The second unit sampled multiple messages with errors on several frequencies, it also sampled from both antennae

If in the future additional operational information has to be relayed from the FSU to the BSC this can be achieved by simply upgrading all the FSUs in the WLL network with a new release which provides the necessary data using the remote upgrade mechan-ism

Presently commands and responses exchanged between the BSC and the FSUs are packed to minimize bandwidth usage All network management commands, responses and user interfaces are crafted according to their specific purpose A future optimization, which is becoming a trend for embedded devices, consists in including web server cap-abilities at the FSUs In this manner no modifications would be required at the BSC when additional operational data are relayed by the FSUs

Table 12.1 Sample terminal output MIN Cell Sector Registration Date SW Upgrade Status

Good Message

Sync Errors

CRC Errors

CI Mn

CI Mx

CI Av

AntA Min

AntA Max

AntA Avg

AntB Min

AntB Max

AntB Avg

0907274

[1] J Mitola III `Technical Challenges in the Globalization of Software Radio,' IEEE Commun Mag., vol 37, no 2, pp 84±89, 1999

[2] J Postel, J Reynolds File Transfer Protocol, RFC 959, 1985

[3] J Ryan `Interfacing Converters and DSPs,' Communication Systems Design, vol 5, no 3, 18±27, 1999