Browse Prior Art Database

Method of Accurate Replay of GSM/GPRS Protocol Stack Execution

IP.com Disclosure Number: IPCOM000130508D
Publication Date: 2005-Oct-25
Document File: 3 page(s) / 31K

Publishing Venue

The IP.com Prior Art Database

Abstract

This invention is to enable accurate duplication or replay of the protocol stack execution for GSM/GPRS Mobile Stations. Although most mobile manufacturers have various protocol stack logging software to record and display information regarding the protocol stack execution for analysis, it is hard to identify the problem if complicated processing inside a single thread is involved or of the problem is due to a layer 1 interrupt handler because this kind of protocol stack logging normally just records message/primitive exchange between different threads, instead of inside a thread or between a thread and an interrupt handler. As a result, to identify the root cause under this situation, developers need to add debug information based on their judgment, make a test build, and then run the scenario again. This procedure may be repeated over and over. This procedure is inefficient and even impractical when the scenario is hard to repeat or the test is performed in a remote location. To address this issue, an effective solution is designed to record relevant information to the PC and replay the scenario as many times as wanted on different firmware builds and different mobile stations. Since recording of network downlink data is at the the boundary between L1 interrupt handler and the DSP, the execution sequence from layer 3 down to layer 1 (excluding DSP software) of the protocol stack can be replayed and debugged. The proposed solution consists of several functional modules. 1. PC-based data upload/download software - This is a PC application to download (from the mobile station to the PC) or upload (from the PC to the mobile station) the logged data. In addtion, it provides a command to switch the mobile station between the LOGGING mode and the REPLAY mode. 2. Switch between the LOGGING mode and the REPLAY mode - There are two operation modes. With a command sent from the PC logging software, the mobile station can be configured as either LOGGING mode or REPLAY mode. In LOGGING mode, the device saves the varying data sequentially into a block of dedicated memory; in REPLAY mode, the device loads the varying data sequentially when the they are referred to. The default mode upon switch-on is LOGGING mode so that data logging can start before the PC-based upload/download software is connected to the mobile station. This enables postmortem analysis. 3. Record relevant information in a compact way - To be able to replay the scenario accurately, we need to record all relevant variables. In light of the limited memory space and processor speed in a typical embedded device, we need to record variables only related to the protocol stack and in a compact way. There are multiple inputs to control the execution sequence of the protocol stack as a whole. Some are at the boundary of the protocol stack, such as the requests from the application layer above the protocol stack, SIM card data, flash memory data, and downlink data from the network. In addtion, there are a number of random variables evaluated arbitrarily inside the protocol stack, such as the interval between consecutive Access Bursts, the free-run reference frame/quarter-bit offset values, etc. To save these two categories of data in a compact way, we insert a special "SaveValue" function in the protocol stack software where these data are read. This "SaveValue" function only stores the data content (8-bit, 16-bit, 32-bit values or an array of values) sequentially into a block of dedicated memory; data types are not stored as they are redundant. The free-run reference frame/quarter-bit offset is only saved once when the protocol stack starts to execute in the LOGGING mode. This data recording process starts at the beginning of the protocol stack execution and if the operation mode is LOGGING. It stops in the end of the protocol stack execution or is terminated explicitly by the PC upload/download software. 4. Download the data from the mobile station to the PC - There are two cases where the data of sequentially saved values are downloaded from the mobile station to the PC. The PC upload/download software can send a DOWNLOAD command to the device to retrieve the data in the dedicated memory on the device and store them on the PC. In another case when the device meets an unexpected reset, if the PC upload/download software is connected to the mobile station, the reset handler on the mobile side pushes the data to the PC upload/download software, which then save the data on the PC; if the PC upload/download software is not connected, (this happens when the user uses the device in the normal mode), the dedicated memory block is kept intact after reset so that the stored data can be downloaded to the PC anytime later on. 5. Upload the data from the PC to the mobile station - The saved data file can be uploaded to a mobile station at any time before the protocol stack starts to run (that is, moving out of the NULL state by commands like "Turn on Radio". An typical usage is that the developer makes a new firmware build with additional debug information, burn the new firmware into the mobile station, and upload the previously saved data to the mobile station. Then, the mobile station is ready to replay the scenario. 6. Replay the scenario - Once the data is uploaded to the mobile station, the user can start to replay the scenario (typically by a "Turn on Radio" command from the mobile station's UI). Once the protocol stack starts to run, the free-run reference frame/quarter-bit offset values are updated to the values saved at switch-on when the device is in the LOGGING mode. For other varying data, they are loaded when and where they are referred to. Because the "LoadValue" function (to load the previously saved value) in the REPLAY mode is called in the same place where the "SaveValue" function is called in the LOGGING mode, there should be no change in the execution sequence of the protocol stack software and we can duplicate the scenario exactly. The existing protocol stack logging software can still be used as usual to record/display the message exchange and the embedded debug information during this scenario replay. Since recording of network downlink data is at the the boundary between L1 interrupt handler and the DSP, the execution sequence from layer 3 down to layer 1 (excluding DSP software) of the protocol stack can be replayed and debugged.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 46% of the total text.

PROTOCOL STACK EXECUTION

Method of Accurate Replay of GSM/GPRS Protocol Stack Execution

Disclosed Anonymously

This invention is to enable accurate duplication or replay of the protocol stack execution for GSM/GPRS Mobile Stations.

Although most mobile manufacturers have various protocol stack logging software to record and display information regarding the protocol stack execution for analysis, it is hard to identify the problem if complicated processing inside a single thread is involved or of the problem is due to a layer 1 interrupt handler because this kind of protocol stack logging normally just records message/primitive exchange between different threads, instead of inside a thread or between a thread and an interrupt handler. As a result, to identify the root cause under this situation, developers need to add debug information based on their judgment, make a test build, and then run the scenario again.  This procedure may be repeated over and over.  This procedure is inefficient and even impractical when the scenario is hard to repeat or the test is performed in a remote location. To address this issue, an effective solution is designed to record relevant information to the PC and replay the scenario as many times as wanted on different firmware builds and different mobile stations. Since recording of network downlink data is at the the boundary between L1 interrupt handler and the DSP, the execution sequence from layer 3 down to layer 1 (excluding DSP software) of the protocol stack can be replayed and debugged.

The proposed solution consists of several functional modules.

1. PC-based data upload/download software -

This is a PC application to download (from the mobile station to the PC) or upload (from the PC to the mobile station) the logged data. In addtion, it provides a command to switch the mobile station between the LOGGING mode and the REPLAY mode.

2. Switch between the LOGGING mode and the REPLAY mode -

There are two operation modes. With a command sent from the PC logging software, the mobile station can be configured as either LOGGING mode or REPLAY mode. In LOGGING mode, the device saves the varying data sequentially into a block of dedicated memory; in REPLAY mode, the device loads the varying data sequentially when the they are referred to.  The default mode upon switch-on is LOGGING mode so that data logging can start before the PC-based upload/download software is connected to the mobile station. This enables postmortem analysis.

3. Record relevant information in a compact way -

To be able to replay the scenario accurately, we need to record all relevant variables. In light of the limited memory space and processor speed in a typical embedded device, we need to record variables only related to the protocol stack and in a compact way. There are multiple inputs to control the execution sequence of the protocol stack as a whole. Some are at the boundary of the protocol stack, such as the requests from the application l...