Method and apparatus for testing wireless communication channels

[0002] This application claims the benefit of provisional U.S. application Ser. No. 60/175,463, entitled “IS-2000 TEST DATA SERVICE OPTION,” filed Jan. 10, 2000, which is incorporated herein by reference in its entirety for all purposes.

[0003] I. Field of the Invention

[0004] The present invention relates to data communication. More particularly, the present invention relates to novel and improved method and apparatus for testing wireless communication channels.

[0005] II. Description of the Related Art

[0006] Wireless communication systems such as code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, and others are widely used to provide various types of communication such as voice, data, and so on. For these wireless systems, it is highly desirable to utilize the available resources (i.e., bandwidth and transmit power) as efficiently as possible. This typically entails transmitting as much data to as many users within as short a time period as supported by the conditions of the communication links.

[0007] To achieve the above goal, the communication links between a transmitting source (e.g., a base station) and the receiving devices (e.g., “connected” remote terminals) within the system may be characterized. Based on the characterized link conditions for the remote terminals, the system may be better able to select a particular set of remote terminals to serve, allocate a portion of the available resources (e.g., transmit power) to each selected remote terminal, and transmit to each remote terminal at a data rate supported by the allocated transmit power and characterized link conditions.

[0008] Conventionally, a communication link is characterized by transmitting (e.g., from a base station) a known data pattern (e.g., generated by a defined pseudo-random number generator), receiving the transmitted data pattern, comparing the received data pattern with a locally generated data pattern to determine transmission errors, and reporting the results back to the transmitting source. This “loop-back” testing is typically performed continuously for a number of frames over the desired test interval. The test results are reflective of the performance of the communication link over that test interval.

[0009] Many newer generation wireless communication systems are capable of flexible operation. For example, data may be transmitted in bursts and over one or more traffic channels (or physical channels), the data rate may be allowed to vary from frame to frame, the processing of the data may also vary (e.g., from frame to frame and/or from channel to channel), and so on. The conventional loop-back test technique typically characterizes the communication link (e.g., one traffic channel) based on a defined set of test parameters, and may not provide an accurate assessment of the performance of the communication link when the system operates in this flexible manner.

[0010] As can be seen, techniques that can be used to characterize a communication link under various flexible operating conditions supported by a wireless communication system are highly desirable.

[0011] The present invention provides various techniques to test a wireless communication link. In one aspect, the testing of a traffic channel is performed via a test data service option (TDSO), which is a service that may be negotiated and connected using the available service configuration and negotiation procedures defined by a particular (CDMA) system and used for other services (e.g., a voice call, a data call). Values for test parameters may be proposed by an entity (e.g., a remote terminal), accepted or rejected by the other entity (e.g., a base station), and alternative values for rejected values may also be provided by the other entity. The negotiation may be performed for each traffic channel to be tested.

[0012] In another aspect, to test a traffic channel, test data is generated based on a defined data pattern or a pseudo-random number generator. Sufficient test data may be generated for a test interval (e.g., 10.24 seconds) based on values from the pseudo-random number generator, and the generated test data may be stored to a (circular) buffer. Test data may thereafter be retrieved, as necessary, from a particular section of the buffer to form one or more data blocks for each “active” frame in the test interval in which test data is to be transmitted. The particular section of the buffer from which to retrieve the test data may be identified by a particular “offset” from a current buffer pointer location, and this offset may be determined based on a number from the pseudo-random number generator. Each data block may be appropriately identified by a header to enable concurrent testing of multiple traffic channels and for testing frames having multiple data blocks per frame. In an embodiment, one pseudo-random number generator and one buffer are provided (at the transmission source and also at the receiving device) for each traffic channel, either on the forward or reverse link, to be tested.

[0013] A traffic channel may be tested using discontinuous transmission. In this case, a two-state first-order Markov chain may be used to determine whether or not to transmit test data for each frame in the test interval. By selecting the proper probabilities of transitioning between an ON state (signifying transmission of test data) and an OFF state (signifying no transmission of test data) of the Markov chain, the average frame activity and average burst length (two parameters that define a discontinuous transmission) may be defined. The Markov chain may be driven by a second pseudo-random number generator, which may be different than the one used to generate the test data.

[0014] At a receiving device, the transmitted test data is received, processed in a complementary manner, and provided to a controller. The controller further directs local generation of the test data based on a pseudo-random number generator, which is synchronized to the generator at the transmitting source. The locally generated test data is stored in a buffer and thereafter retrieved from the buffer (as necessary) and compared against the received test data. Various performance and statistical data may be collected at the remote terminal based on the results of the comparison between the received and generated test data.

[0015] The testing of the reverse link may be achieved in similar manner as that for the forward link. Multiple traffic channels on the forward and reverse links may be tested concurrently. Independent testing of the traffic channels is possible by testing each traffic channel based on a respective set of test parameter values. Thus, the forward link traffic channels and reverse link traffic channels may be tested based on symmetric or asymmetric test parameter values. The traffic channels under test may have different frame lengths.

[0016] The invention further provides other methods and system elements that implement various aspects, embodiments, and features of the invention, as described in further detail below.

[0017] The features, nature, and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout and wherein:

[0018] FIG. 1 is a diagram of a spread spectrum communication system that supports a number of users;

[0019] FIGS. 2A and 2B are block diagrams of an embodiment of a base station and a remote terminal, respectively, capable of implementing various aspects and embodiments of the invention;

[0020] FIG. 3 is a flow diagram of a process for generating test data using a pseudo-random number generator, in accordance with a specific embodiment of the invention;

[0021] FIG. 4 is a block diagram of the buffers and pseudo-random number generators used for generating pseudorandom test data for two traffic channels;

[0022] FIG. 5 is a diagram that illustrates the reshuffling of a pseudo-random number to generate a number for the test data;

[0023] FIG. 6 is a diagram that illustrates test data transmission for a discontinuous transmission (DTX) scheme based on a deterministic frame activity;

[0024] FIG. 7 is a diagram of a two-state first-order Markov chain that may be used to model the ON/OFF states for a DTX scheme based on pseudo-random frame activity;

[0025] FIG. 8 is a flow diagram of an embodiment of a process for transitioning between the ON and OFF states of the Markov chain for a traffic channel; and

[0026] FIG. 9 is a diagram of an embodiment of a test data block.

[0027] FIG. 1 is a diagram of a spread spectrum communication system 100 that supports a number of users. System 100 provides communication for a number of cells, with each cell being serviced by a corresponding base station 104. Various remote terminals 106 are dispersed throughout the system. Each remote terminal 106 may communicate with one or more base stations 104 on the forward and reverse links at any particular moment, depending on whether or not the remote terminal is active and whether or not it is in soft handoff. As shown in FIG. 1, base station 104acommunicates with remote terminals 106a, 106b, 106c, and 106dand base station 104bcommunicates with remote terminals 106d, 106e, and 106f.

[0028] A system controller 102 couples to base stations 104 and may further couple to a public switched telephone network (PSTN). System controller 102 provides coordination and control for the base stations coupled to it. System controller 102 further controls the routing of telephone calls among remote terminals 106, and between remote terminals 106 and the users coupled to PSTN (e.g., conventional telephones), via base stations 104. For a CDMA system, system controller 102 is also referred to as a base station controller (BSC).

[0029] System 100 may be designed to support one or more CDMA standards such as the “TIA/EIA-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System” (the IS95 standard), the “TIA/EIA-98D Recommended Minimum Standard for Dual-Mode Wideband Spread Spectrum Cellular Mobile Station” (the IS98 standard), the “TIA/EIA/IS2000.2-A Physical Layer Standard for cdma2000 Spread Spectrum Systems”, the “TIA/EIA/IS2000.5-A Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems”, the standard offered by a consortium named “3rd Generation Partnership Project” (3GPP) and embodied in a set of documents including Document Nos. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214 (the W-CDMA standard), the standard offered by a consortium named “3rd Generation Partnership Project 2” (3GPP2) and embodied in a set of documents including Document Nos. C.S0002-A, C.S0005-A, C.S0010-A, C.S0011-A and C.S0026 (the cdma2 000 standard), or some other standards. These standards are incorporated herein by reference.

[0030] Some newer generation CDMA systems are capable of concurrently supporting voice and data transmissions, and may further be able to transmit to a particular remote terminal via a number of forward traffic channels. For example, in the cdma2000 system, a fundamental channel may be assigned for voice and certain types of data, and one or more supplemental channels may be assigned for high-speed packet data.

[0031] FIG. 2A is a block diagram of an embodiment of base station 104, which is capable of implementing various aspects and embodiments of the invention. For simplicity, FIG. 2A shows the processing at the base station for a communication with one remote terminal. On the forward link, voice and packet data (collectively referred to herein as “traffic” data) from a transmit (TX) data source 210 and test data from a forward link (FL) test data buffer 212 are provided to a multiplexer (MUX) 214, FL test data buff 212 and RL test data buffer 242 are supplied with test data un TX data generator 240. Multiplexer 214 selects and provides the traffic data to a TX data processor 216 when operating in a normal mode, and provides the test data when operating in a test mode. TX data processor 216 receives and processes (e.g., formats, encodes, and interleaves) the received data, which is then further processed (e.g., covered, spread, and scrambled) by a modulator (MOD) 218. The modulated data is then provided to an RF TX unit 222 and conditioned (e.g., converted to one or more analog signals, amplified, filtered, and quadrature modulated) to generate a forward link signal. The forward link signal is routed through a duplexer (D) 224 and transmitted via an antenna 226 to a remote terminal.

[0032] Although not shown in FIG. 2A for simplicity, base station 104 is capable of processing and transmitting data on one or more forward traffic channels to a particular remote terminal. For a cdma2000 system, the forward traffic channels include the fundamental channel (FCH), dedicated control channel (DCCH), supplemental channel (SCH), and supplemental code channel (SCCH). The processing (e.g., encoding, interleaving, covering, and so on) for each forward traffic channel may be different from that of other forward traffic channels.

[0033] FIG. 2B is a block diagram of an embodiment of remote terminal 106. The forward link signal is received by an antenna 252, routed through a duplexer 254, and provided to an RF receiver unit 256. RF receiver unit 256 conditions (e.g., filters, amplifies, downconverts, and digitizes) the received signal and provides signal samples to demodulator (DEMOD) 258. Demodulator (DEMOD) 258 processes (e.g., despreads, decovers, and pilot demodulates) the demodulated signal samples to provide recovered demodulated symbols to RX data processor 260. Demodulator 258 may implement a rake receiver capable of processing multiple instances of the received signal and generating combined recovered symbols. Receive (RX) data processor 260 decodes the recovered symbols, checks the received frames, and provides decoded traffic data to demultiplexer (DEMUX) 262, which demultiplexes the data decode traffic data to a RX data sink 264 and decoded test data to a controller 270. Demodulator 258 and receive data processor 260 may be operated to process multiple transmissions received via multiple forward traffic channels.

[0034] On the reverse link, a multiplexer (MUX) 284 receives results of the forward traffic channel testing from controller 270, test data for testing of the reverse link from a reverse link (RL) test data buffer 278, and traffic data from a TX data source 282. Depending on the operating mode of remote terminal 106, multiplexer 284 provides the proper combination of data and/or results to a TX data processor 286. The data and results are then processed (e.g., formatted, encoded, and interleaved) by TX data processor 286, further processed (e.g., covered, spread) by a modulator (MOD) 288, and conditioned (e.g., converted to analog signals, amplified, filtered, and quadrature modulated) by an RF TX unit 290 to generate a reverse link signal, which is then routed through duplexer 254 and transmitted via antenna 252 to one or more base stations 104.

[0035] Referring back to FIG. 2A, the reverse link signal is received by antenna 226, routed through duplexer 224, and provided to an RF receiver unit 228. The reverse link signal is conditioned (e.g., downconverted, filtered, and amplified) by RF receiver unit 228, and further processed by a demodulator 232 and an RX data processor 234 in a complementary manner to recover the transmitted data and test results. The reverse link traffic data is provided to a RX data sink 238, and the forward link test results and reverse link test data are provided to a controller 220 for evaluation by multiplexer (MUX) 236.

[0036] As noted above, for efficient utilization of the available system resources, the communication link between the base station and remote terminal may be characterized. The link characterization information may then be used to schedule data transmission, allocate transmit power, determine data rate, and so on, for the remote terminal.

[0037] The invention provides various techniques to test a wireless communication link. In an aspect, to test a forward traffic channel, test data is generated at the base station by a test data generator 240 and provided to FL test data buffer 212. The generated test data is thereafter retrieved from buffer 212 (as necessary), processed, and transmitted from the base station to the remote terminal. At the terminal, the transmitted forward link test data is received, processed in a complementary manner, and provided to controller 270. Controller 270 further directs a test data generator 280 to locally generate the test data, which is stored in a FL test data buffer 268. The locally generated test data is thereafter retrieved from buffer 268 (as necessary) and compared against the received test data. Various performance and statistical data may be collected at the remote terminal based on the results of the comparison between the received and generated test data, as described in further detail below. The testing of the reverse link may be achieved in similar manner as that for the forward link.

[0038] For clarity, various aspects of the invention are described for a specific implementation for a cdma2000 system.

[0039] Channel and Frame Structure

[0040] In some CDMA systems, data may be transmitted on one or more traffic channels over the forward and reverse links. (A traffic channel may be akin to a physical channel for some CDMA systems, e.g., a W-CDMA system.) For example, in a cdma2000 system, voice data is typically transmitted over a fundamental channel (FCH), traffic data is typically transmitted over a supplemental channel (SCH), and signaling may be transmitted over a dedicated control channel (DCCH). The FCH, DCCH, and SCH are different types of traffic channel. To receive a high-speed data transmission on the SCH, a remote terminal is also typically assigned a FCH or DCCH. In the cdma2000 system, each assigned traffic channel is associated with a particular radio configuration (RC) that defines the channel's transmission formats, which may be characterized by various physical layer parameters such as the transmission rates, modulation characteristics, spreading rate, and so on.

[0041] For many CDMA systems, data is also transmitted in “frames”, with each frame covering a particular time interval. For the cdma2000 system, data may be transmitted in frame lengths of 5 msec, 20 msec, 40 msec, or 80 msec on the fundamental and supplemental channels. For each frame of each connected traffic channel, one or more data blocks may be transmitted, depending on the radio configuration of the traffic channel.

[0042] In certain embodiments of the invention, the forward and reverse traffic channels are each subdivided into independent “test intervals” (which may also be referred to as “segments”). Each test interval has a duration of 10.24 seconds, which corresponds to 2048 frames for traffic channels (FCH, DCCH) with 5 msec frame length, 512 frames for traffic channels (FCH, DCCH, and SCH) with 20 msec frame length, 256 frames for traffic channels (SCH) with 40 msec frame length, and 128 frames for traffic channels (SCH) with 80 msec frame length. The first frame in the test interval is referred to as a synchronization frame. In an embodiment, the synchronization frame for each of the forward and reverse traffic channels (FCH, DCCH, SCHO, and SCHI) is selected based on (1) a 32-bit public long code mask (PLCM) assigned to the remote terminal and (2) the system frame number (SFN) of the traffic channel's frames, as described in further detail below. Thus, each traffic channel may be associated with synchronization frames that are different (time-wise) from those of other traffic channels.

[0043] In an aspect, the CDMA system is designed to support a test data service option (TDSO), which is akin to an operating mode in which the performance of the forward and/or reverse traffic channels for a remote terminal may be tested and/or verified. The initiation and negotiation of the parameters for the TDSO are described in further detail below. While operating in this mode, test data may be transmitted over the forward and/or reverse links and over one or more traffic channels on each link. This allows for independent testing of various traffic channels and further allows for independent testing of the forward and reverse links.

[0044] Test Data Generation

[0045] In accordance with an aspect of the invention, various types of test data may be used to test a traffic channel. These test data types may include defined data sequences, pseudo-random data, and others. The test data type may be selected via a parameter in the test data service option.

[0046] In one test configuration, one or more defined data sequences are used to test a traffic channel. Various schemes may be used to generate these data sequences. In one scheme, a single byte pattern is used to fill up each data block. This byte pattern may be an all ones pattern (“11111111”) or some other byte pattern. If a data block includes more than a whole number of octets (e.g., 171 bits), each whole octet may be represented by the byte pattern and the remaining bits may be filled with zeros (“0”). The use of a defined data sequence may simplify the test data generation at the transmission source and receiving device.

[0047] In another test configuration, pseudo-random data is used to test a traffic channel. This data may be generated using one or more pseudo-random number generators, as described in further detail below.

[0048] FIG. 3 is a flow diagram of a process for generating test data using a pseudo-random number generator, in accordance with a specific embodiment of the invention. FIG. 3 presents an overall view of the test data generation process, which is described in greater detail below. Prior to the start of each test interval for a particular traffic channel to be tested, the pseudo-random number generators used at the transmitting source and receiving device to generate the pseudo-random test data for this traffic channel are synchronized at step 312 and initialized, at step 314.

[0049] The pseudo-random number generator at the transmitting source is then operated to generate a sufficient number of test data bits for N frames (where N is two or greater), at step 316. These test data bits are stored to a (circular) buffer, which is subsequently used as the data source for bits to be packed into one or more data blocks for each “active” frame period in the test interval. The receiving device similarly generates the test data bits for N frames, which are stored to a corresponding buffer at the receiving device and thereafter retrieved as necessary to verify whether or not the transmitted test data bits are received error free.

[0050] In accordance with an aspect of the invention and as described below, the traffic channel may be tested using discontinuous transmission. In this case, for each frame in the test interval, a TDSO state for the current frame is updated, at step 318. A determination is then made whether or not test data is to be transmitted for the current frame based on the updated TDSO state, at step 320. If test data is to be transmitted, one or more blocks of test data are retrieved from a particular section of the circular buffer, at step 322. These steps are described in further detail below.

[0051] FIG. 4 is a block diagram of the buffers and pseudo-random number generators used for generating pseudo-random test data for a forward and a reverse traffic channel, in accordance with an embodiment of the invention. In this embodiment, one pseudo-random number generator is associated with each traffic channel to be tested on each of the forward and reverse links. For example, if the TDSO is configured to transmit data over the FCH in the forward and reverse links and over the SCHO only in the forward link, then three pseudo-random number generators are used at the base station and three pseudo-random number generators are used at the remote terminal (only two generators are shown on each side in FIG. 4).

[0052] In the embodiment shown in FIG. 4, base station 104 includes pseudo-random number generators 440aand 440bused to generate pseudo-random data for a traffic channel on the forward and reverse links, respectively. The generated test data from generators 440aand 440bis provided to test data buffers 412aand 412b,respectively. Similarly, remote terminal 106 includes pseudo-random number generators 480aand 480bused to generate pseudo-random data for the traffic channel on the forward and reverse links, respectively, which is provided to test data buffers 482aand 482b, respectively. Additional pseudo-random number generators are used for additional traffic channels to be tested. In an embodiment, pseudo-random number generators 440a, 440b, 480a, and 480bare initialized and synchronized at each synchronization frame (i.e., once every test interval), as described in further detail below.

[0053] In an embodiment, each pseudo-random number generator exhibits the following linear congruent relationship:

[0054] x_x=(a·x_n−1) mod m.  Eq(1)

[0055] In an embodiment, a=7⁵=16807, m=2³¹−1=2,147,483,647, and x_n−1and x_nare successive outputs of the pseudo-random number generator and are 31-bit integers. Other values may also be used for a and m.

[0056] In an embodiment, each pseudo-random number generator is initialized prior to each synchronization frame on the traffic channel associate with the generator. The initialization may be achieved as follows:

[0057] In the above pseudo-code, PRNGx denotes the content of the x^thpseudo-random number generator. The seed for the pseudo-random number generator may be selected as the system time, in frames, of the synchronization frame (e.g., the system frame number of the synchronization frame may be used as the seed for the pseudo-random generator). TOGGLE is a value used to toggle some of the bits of the seed, and may be selected as 0×2AAAAAAA for a generator used for the forward link and 0×55555555 for a generator used for the reverse link. As used herein, the notation “0×. . . ” denotes a hexadecimal number.

[0058] Once initiated, the pseudo-random number generator is iterated a number of times to generate the pseudo-random test data to be used for the upcoming test interval. The number of test data bits to be generated is dependent on various factors such as (1) the traffic channel type (i.e., FCH, DCCH, or SCH) (2) the connected radio configuration of the remote terminal, (3) the maximum number of bits to be passed by a multiplex sublayer to the physical layer for each frame period, (4) the size of the available buffer, and (5) possibly other factors. The multiplex sublayer is a protocol layer between a physical layer and a higher layer, and which multiplexes traffic data, test data, signaling, and other types of data received from the TDSO to the assigned traffic channel(s).

[0059] In an embodiment, test data bits are generated for N frames at the maximum bit rate possible for the connected radio configuration, as described in further detail below. A default value of two, for example, may be set for N, unless another value for N is negotiated between the base station and remote terminal. A larger value for N may provide test data having better randomness properties but requires a larger-sized buffer.

[0060] After initialization, the pseudo-random number generator is used to generate test data bits for N frames. During the test data generation, whenever a pseudo-random number is needed, the current value of the variable PRNGx is retrieved and used, and the variable PRNGx is then updated (i.e., iterated) once as shown in equation (1). In an embodiment, only the most significant 24 bits of the 31-bit number for PRNGx are used because of better randomness properties and ease of usage, and the least significant 7 bits are discarded. Thus, each iteration of the pseudo-random number generator provides a 24-bit pseudo-random number, y_n(k), used to provide three bytes of test data. P(n) iterations are performed to generate the required test data for N frames.

[0061] FIG. 5 is a diagram that illustrates a reshuffling of each pseudo-random number to generate 24 bits of test data. Using the 31-bit number from the pseudo-random number generator to generate test data is inefficient, from an implementation point of view, because the number is not octet aligned. It is easier to build a frame with a number that is octet aligned. The least significant bits of the 31-bit number are “less random” than the most significant bits, and are thus shuffled to the right. In an embodiment, each 24-bit pseudo-random number y_n(k) from the pseudo-random number generator, where 1≦k≦P(n), is reshuffled and stored in “little-endian” order. The reshuffling is achieved by swapping the least significant byte in the 24-bit number y_n(k) with the most significant byte to generate the reshuffled number y_n^LE(k) .

[0062] To generate test data for a new test interval for a particular rate R(n), the TDSO generates P(n) pseudo-random numbers corresponding to an actual buffer size B(n), where B(n)≧N•R(n). As an example, to generate 344 test data bits, the pseudo-random number generator is iterated 15 times (15•24=360, which is the first integer number of iterations that yield at least 344 bits). The buffer is then filled with the following number sequence:

[0063] y_n^LE(1), y_n^LE(2), y_n^LE(3), . . . , y_n^LE(15).

[0064] The buffer is filled with test data at the start of each test interval and prior to the synchronization frame. Thereafter, for each “active” frame in the test interval in which test data is to be transmitted, test data bits may be retrieved from the buffer to generate one or more data blocks for the frame. For a particular traffic channel, the bits from the buffer are packed serially into one or more data blocks (e.g., corresponding to the available MUX PDU (Protocol Data Unit), as determined by the connected multiplex option, where each MUX PDU represents encapsulated data communicated between peer layers at the base station and remote terminal).

[0065] In an embodiment, the test data buffer is operated as a circular buffer and test data for each frame is retrieved from a particular section of the circular buffer (i.e., starting from a particular location in the circular buffer). Initially, after filling the circular buffer (e.g., with at least two frames of test data), a buffer pointer is set to the first location in the buffer (e.g., address zero). In an embodiment, at the start of each frame, the pseudo-random number generator is iterated once and a 24-bit number is obtained as described above. The least significant 6 bits of this 24-bit number, O_n, is then used to determine an offset for the buffer pointer. The buffer pointer is advanced from its current location by [O_nmod B(n)] byte positions to the new starting location for the current frame. Bytes of test data are then retrieved from the circular buffer, starting from this starting location, to fill whole octets in a data block. For example, if a data block includes 171 bits, then 21 bytes (i.e., 168 bits) of test data are retrieved from the circular buffer and the remaining three bits in the data block are filled with zeros (“0”).

[0066] For the next frame, the pseudo-random number generator is iterated once more, the least significant 6 bits of the 24-bit number, O_n+1, from the generator is used to determine the buffer pointer offset for this frame. The buffer pointer is advanced by [O_n+1mod B(n)] byte positions from the current location (which is one byte position over from the last test data byte retrieved for the prior frame). This process for generating data blocks is repeated for each active frame in the test interval in which test data is to be transmitted. An example of the test data generation is provided below.

[0067] Frame and Buffer Sizes

[0068] As noted above, the pseudo-random number generator for a particular traffic channel and (forward or reverse) link to be tested is iterated a number of times (i.e., as often as necessary) to generate the test data to be used for a test interval. The number of test data bits to be generated for each test interval is based on the channel type and radio configuration. Table 1 lists the maximum number of bits for each (5 msec, 20 msec, 40 msec, or 80 msec) frame and the buffer size for the FCH and DCCH for various radio configurations defined by the cdma2000 standard.

[0069] Table 2 lists the maximum number of bits per frame and the buffer size for a forward supplemental channel (F-SCH0 or F-SCH1) for various radio configurations defined by the cdma2000 standard.

[0070] Table 3 lists the maximum number of bits per frame and the buffer size for a reverse supplemental channel (R-SCH0 or R-SCH1) for various radio configurations defined by the cdma2000 standard.

[0071] Discontinuous Transmission Testing

[0072] In accordance with an aspect of the invention, the testing of a traffic channel may be performed in a manner to model discontinuous transmission (DTX) supported by some newer generation CDMA systems (e.g., the cdma2000 and W-CDMA systems). This DTX testing may be achieved by transmitting test data on the traffic channel in accordance with a particular ON/OFF frame activity. For each frame period (e.g., each 20 msec, 40 msec, or 80 msec) for the traffic channel, the TDSO may choose to provide to the multiplex sublayer either one or more data blocks corresponding to a full-rate frame on that channel or one or more blank data blocks. Various DTX schemes may be used to provide data to the multiplex sublayer to achieve a particular desired frame activity. Some of these DTX schemes are described in further detail below.

[0073] In a first DTX scheme, test data is provided based on a deterministic frame activity. For this DTX scheme, test data is transmitted on the traffic channel for a particular ON duration, followed by blank data transmission for a particular OFF duration, followed by test data transmission for another ON duration, and so on. The ON and OFF durations may be selectable or negotiated between the base station and remote terminal. Also, the ON/OFF cycles may be periodic or non-periodic.

[0074] FIG. 6 is a diagram that illustrates test data transmission for an embodiment of the first DTX scheme. As shown in FIG. 6, the TDSO sends to the multiplex sublayer test data blocks for a traffic channel for a particular ON duration, and then sends blank data blocks for a particular OFF duration. The ON/OFF cycle may be designated to start at the beginning of a synchronization frame on the traffic channel being tested. The ON and OFF durations may be selected such that (1) each test interval includes one ON/OFF cycle, (2) a test interval includes multiple ON/OFF cycles, or (3) an ON/OFF cycle spans multiple test intervals.

[0075] In an embodiment, the ON duration for transmitting test data and the OFF duration for transmitting blank data may be specified by two parameters (e.g., TX_ON_PERIOD and TX_OFF_PERIOD) in a message (e.g., a Service Option Control Messagein the cdma2000 system) sent or received by the transmitting source.

[0076] In a second DTX scheme, test data is provided in a pseudo-random manner based on a particular average frame activity and burst length. This DTX scheme may be used to achieve a particular (desired or selected) long-term average of frame activity (D) and a particular average burst length (B) for a traffic channel. The average frame activity D refers to the average number of frames in each ON duration versus the average number of frames in each ON/OFF cycle. And the average burst length B refers to the average number of frames in each ON duration.

[0077] FIG. 7 is a diagram of a two-state first-order Markov chain that may be used to model the ON/OFF states for the TDSO for the second DTX scheme. In an embodiment, one Markov chain is maintained for each traffic channel being tested. At the start of each frame, the TDSO is either in the ON state or the OFF state. The Markov chain is characterized by a probability p of transitioning from the ON state to the OFF state, and a probability q of transitioning from the OFF state to the ON state. The values of p and q may be specified by two parameters (e.g., ON_TO_OFF_PROB and OFF_TO_ON_PROB) in a message (e.g., a Service Option Control Message) sent by the transmitting source (e.g., the base station).

[0078] The long-term average frame activity D may be defined as: $\begin{array}{cc}D=\frac{q}{p+q}.& \mathrm{Eq}\left(2\right)\end{array}$

[0079] And the average burst length B may be defined as: $\begin{array}{cc}B=\frac{1}{p}.& \mathrm{Eq}\left(3\right)\end{array}$

[0080] For some testing, it may be desirable to select the average frame activity D and the average burst length B, and then determine the corresponding values for p and q based on the desired D and B. Combining and rearranging equations (2) and (3), the following are obtained: $\begin{array}{cc}D=\frac{\mathrm{Bq}}{1+\mathrm{Bq}}.& \mathrm{Eq}\left(4\right)\\ B=\frac{D}{\left(1-D\right)q}.& \mathrm{Eq}\left(5\right)\end{array}$

[0081] Equation (4) indicates that for a given value of B, D varies from 0 to B(1+B) when q varies from 0 to 1, respectively. Similarly, equation (5) indicates that for a given value of D, B varies from D/(1-D) to infinity when q varies from 0 to 1, respectively. For example, when B is selected as 2, D should be smaller than ⅔, which indicates that the average frame activity D cannot be set higher than ⅔ when B is set to 2. As another example, if D is set to {fraction (7/10)}, then B is set greater than {fraction (7/3)}.

[0082] In an embodiment, a (e.g., 24-bit) pseudo-random number is used to drive the transition between the ON and OFF states for each frame period (each 5 msec, 20 msec, 40 msec, or 80 msec). In an embodiment, one pseudorandom number generator is used for all traffic channels having the same frame length. For example, one pseudo-random number generator is used for all traffic channels having 20 msec frame lengths. A second pseudo-random number generator is used for supplemental channels configured for 40 msec or 80 msec frame length, and this generator is updated every 40 msec or 80 msec corresponding to the channel frame length. In an embodiment, the pseudo-random number generator(s) used to drive the TDSO states are different than the ones used to generate the test data.

[0083] In an embodiment, the pseudo-random number generator(s) used to drive the transitions between TDSO states are initialized at the start of the first synchronization frame after the TDSO is initialized. Upon initialization, the Markov chain for each traffic channel is set to a particular state (e.g., OFF). The pseudo-random number generator(s) are thereafter maintained throughout the duration of the call, without reinitialization at subsequent synchronization frames. These generators may be reinitialized upon completion of a CDMA-CDMA hard handoff.

[0084] FIG. 8 is a flow diagram of an embodiment of a process for transitioning between the ON and OFF states of the Markov chain for a traffic channel. Initially, the pseudo-random number generator used to drive the TDSO states for the traffic channel is initialized, at step 812. This initialization may be achieved, for example, by obtaining a seed for the generator, XORing the seed with the value 0×2AAAAAAA, ANDing the result with the value 0×7FFFFFFF, and iterating the generator four times with the modified seed, as described in the above pseudo-code.

[0085] In an embodiment, a 24-bit pseudo-random number from the pseudo-random number generator is used to determine whether or not to transition from one state to another. Thus, 24-bit ON and OFF threshold values are computed, at step 814. These thresholds may be computed as:

[0086] ON_THRESHOLD=ROUND (16,777,215•q), and

[0087] OFF_THRESHOLD=ROUND (16,777,215•p).

[0088] As shown in FIG. 7, the TDSO for the traffic channel transitions from the ON state to the OFF state with a probability of p, and from the OFF state to the ON state with a probability of q. Based on a pseudo-randomly generated 24-bit number, the TDSO transitions from the ON state to the OFF state if this number is less than the OFF_THRESHOLD, and from the OFF state to the ON state if this number is less than the ON_THRESHOLD. Steps 812 and 814 are typically performed once, prior to the first synchronization frame after the TDSO has been initialized.

[0089] The steps within box 820 are thereafter performed for each frame period. Initially, a 24-bit pseudo-random number is generated from the current 31-bit state of the pseudo-random number generator, at step 822. A determination is next made whether or not the current TDSO state for the traffic channel is OFF, at step 824.

[0090] If the current TDSO state is OFF, a determination is made whether the 24-bit number is greater than or equal to the ON_THRESHOLD, at step 826. If the answer is yes, the TDSO remains in the OFF state, at step 828. Otherwise, the TDSO transitions to the ON state, at step 832. In either case, the process then proceeds to step 834.

[0091] If the current TDSO state is ON (determined back at step 824), a determination is then made whether the 24bit number is greater than or equal to the OFF_THRESHOLD, at step 830. If the answer is yes, the TDSO remains in the ON state, at step 832. Otherwise, the TDSO transitions to the OFF state, at step 828.

[0092] At step 834, the pseudo-random number generator is iterated once, as shown in equation (1), to update the state of the generator for the next frame.

[0093] Data Block Header and Format

[0094] In accordance with an aspect of the invention, each test data block is appropriately identified to enable concurrent testing of multiple traffic channels and for frames with multiple data blocks per frame. In an embodiment, the identification is achieved via a header provided in each data block supplied to the multiplex sublayer for each frame.

[0095] FIG. 9 is a diagram of an embodiment of a test data block 900, which includes a channel ID field 912, a PDU (data block) sequence number field 914, and a test data field 916. Channel ID field 912 identifies the particular traffic channel used to send this data block. PDU sequence number field 914 identifies the sequence number of this data block within the frame (e.g., within a physical layer service data unit (SDU)). For a FCH or DCCH carrying one data block per frame, this field is set to ‘0’. And for an SCH capable of carrying multiple data blocks per frame, this field is set to ‘0’ for the first data block in the SCH frame, ‘1’ for the second data block in the SCH frame, and so on. Test data field 916 includes the (defined or pseudo-random) test data generated as described above.

[0096] Table 4 lists the fields and their lengths and definitions for an embodiment of test data block 900.

[0097] Table 5 shows a specific definition of the Channel ID field for various traffic channel types in the cdma2000 system.

[0098] Example of Test Data Generation

[0099] For clarity, the test data generation is now described for a specific example. In this example, the following parameters are used:

[0100] The TDSO is configured to transmit primary traffic over the FCH.

[0101] The base station and remote terminal are configured to support radio configuration 3, and the frame length is 172 bits.

[0102] Multiplex option 0×01 is selected for the FCH, and one data block is passed to the multiplex sublayer for each active (20 msec) frame.

[0103] The average frame activity D and average burst length B are based on the probabilities p=0.7 and q=0.3. Thus, D=q/(p+q)=0.3, B=1/p≈1.4, ON_THRESHOLD=ROUND (16,777,215•p)=11,744,051, and OFF_THRESHOLD=ROUND (16,777,215•q)=5,033,164.

[0104] The least significant 32 bits of the remote terminal's Public Long Code Mask (PLCM) is equal to 0×9F000307.

[0105] A first pseudo-random number generator used to determine the transitions between the ON/OFF states of the Markov chain for this traffic channel has a current value of 0×682DFFOC.

[0106] For this example, the TDSO is about to transmit frame number 0×AB89EFAD on the forward FCH (F-FCH) to the remote terminal. The frame number is XORed with the value 0×2AAAAAAA, and the least significant 9 bits of the XOR result is equal to 0×107, which is equal to the least significant 9 bits of the remote terminal's PLCM. This frame is thus the synchronization frame for the F-FCH, and the test data generation process is resynchronized.

[0107] As part of the resynchronization, a second pseudo-random number generator used to generate test data for the F-FCH is reinitialized by (1) seeding it with the frame number 0×AB89EFAD, (2) performing an XOR of the seed with the value 0×2AAAAAAA to generate the value 0×01234507, and (3) iterating the pseudo-random number generator four times, as described in the above pseudo-code.

[0108] After reinitialization, the state of the second pseudo-random number generator is 0×3B7E3E68, the most significant 24 bits of this state is 0×76FC7C, and the least significant 6 bits of this 24-bit number is 0×3C. This 6-bit number, O_n, is later used to determine the offset for the circular buffer.

[0109] The second pseudo-random number generator is then iterated 15 times to generate 360 test data bits for two frames of test data (15 is the smallest number of iterations that will provide at least 344 bits included in two frames for radio configuration 3). The actual buffer size is thus B(n)=45 (i.e., 360 bits=45 bytes).

[0110] The generation of the test data proceeds as follows. Prior to each iteration, the current state of the second generator is obtained and the most significant 24 bits are used to form a 24-bit number. The following sequence of 24-bit numbers are generated by the second pseudo-random number generator:

[0111] Each 24-bit number y,,(k) is then stored to a circular buffer for the F-FCH in little-endian fashion, as described above. For example, the first 24-bit number 0×76FC7C is stored as 0×7CFC76, where the most and least significant bytes of the number y_n(k) are swapped to generate the reshuffled number y_n^LE(k). The circular buffer used to generate the data blocks for the F-FCH for the next 512 frames in the test interval includes the following byte sequence:

[0112] The first pseudo-random number generator used to determine the ON/OFF state is then updated, and a new 24bit number having a value of 0×478744 (4,687,684) is generated. The first pseudo-random generator is updated at the end of the first iteration of the loop and after the 24bit number is calculated, it is tested against the ON_THRESHOLD during the second iteration around the loop. Since this value is less than the ON_THRESHOLD value of 11,744,051, the TDSO transitions from the OFF state to the ON state, and a data block is provided to the multiplex sublayer for the current frame.

[0113] To generate this data block for the first frame in the test interval, the offset for the buffer pointer is computed as O_nmod B(n) (i.e., 0×3C mod 45=60 mod 45=15). The buffer pointer (which is initialized to zero upon reinitialization) is thus advanced by 15 byte positions, from 0×7C to 0×6B. The 171 bits for the data block are then formed with 21 bytes (168 bits) retrieved from the circular buffer, starting at the buffer location identified by the advanced buffer pointer. The remaining three bits in the data block are filled with zeros. The data block includes the following byte sequence:

[0114] 6B 4A 4C 3D 78 BE AF ED C7 B3 BD C58D 4229 FE 5B D0448747 ‘000’

[0115] Since this frame is to be sent over the F-FCH, the first 5 bits of the octet are replaced by ‘00000’ corresponding to the channel ID of ‘00’ and the PDU sequence number of ‘000’. The final test data block is as follows:

[0116] 03 A44C 3D 78 BE AF ED C7 B3 BD C58D 4229 FE 5B D0448747 ‘000’

[0117] For the next TDSO frame, a new 24-bit number having a value of 107,486 is generated by the first pseudo-random number generator. Since this value is less than the ON threshold, the TDSO remains in the ON state and a new data block is generated for the multiplex sublayer.

[0118] For the second frame in the test interval, the second pseudo-random number generator is iterated, and a 24-bit number having a value of 0×02F3FD is generated. The 6-bit number 0_nfor the buffer offset has a value of 0×3D. The buffer offset is then computed as O_nmod B(n) (i.e., 0×3D mod 15=61 mod 45=16). The buffer pointer (which was pointing one byte location over from the last retrieved byte value of 0×47 for the last data block) is thus advanced by 16 byte positions from 0×DE to 0×6F. The 171 bits for the data block are then formed with 21 bytes from the circular buffer, starting at the new buffer location. The remaining three bits in the data block are filled with zeros. The data block includes the following byte sequence:

[0119] 7F 9D A77912 EF E8 F06B A44C 3D 78 BE AF ED C7 B3 BD C58D ‘000’

[0120] After replacing the first 5 bits with ‘00000’ corresponding to the data block header for the F-FCH, the data block provided to the multiplex sublayer is as follows:

[0121] 079D A77912 EF E8 F06B A44C 3D 78 BE AF ED C7 B3 BD C58D ‘000’

[0122] The buffer pointer now points to the next byte position (0×42) for the next frame.

[0123] TDSO Frame Transmission and Reception

[0124] To test a particular traffic channel, the data block(s) for each “active” frame are generated based on a defined data pattern or a pseudo-random number generator, as described above. The transmitting source and receiving device are synchronized so that the receiving device is able to properly generate the transmitted frames, such that the received frames may be compared with the locally generated frames. Each data block in each frame is appropriately identified to indicate (1) the particular traffic channel used to send the data block and (2) the data block number within the frame. The TDSO is able to compare the received and locally generated frames, count the errors, determine the bit error rate (BER), PDU or data block error rate (PER), and frame error rate (FER), and compute other measures of performance.

[0125] The testing thus includes processing performed at the transmitting source to transmit a test frame and processing performed at the receiving device to receive a test frame.

[0126] The transmit frame processing includes:

[0127] Generating one or more data blocks for each active frame.

[0128] Supplying the generated data block(s) to the multiplex sublayer for transmission.

[0129] Incrementing the appropriate counters.

[0130] For a test of the FCH or DCCH that operates on 20 msec frames, the TDSO provides one data block to the multiplex sublayer for each active frame interval in which the TDSO state for the traffic channel is ON. For a test of the SCH, the TDSO provides N_Bdata blocks to the multiplex sublayer for each active frame interval (20 msec, 40 msec, or 80 msec), where NB is the maximum number of data blocks in a physical layer SDU for the connected service option. Each data block may be generated as described above, and includes the header and test data.

[0131] The receive frame processing includes:

[0132] Generating one or more data blocks for each active frame.

[0133] Receiving data block(s) from the multiplex sublayer.

[0134] Comparing the rates and contents of the received and generated data block(s).

[0135] Incrementing the appropriate counters.

[0136] At the receiving device, the multiplex sublayer categorizes each received data block (e.g., as either test data or blank) and the frame. The multiplex sublayer then supplies the data block type and received test data bits, if any, to the TDSO.

[0137] Various counters may be maintained at the transmitting source and receiving device to support TDSO. For each traffic channel to be tested, a set of counters may be maintained at the transmitting source to keep track of the number of frames (of various types) and data blocks transmitted to the receiving device. At the receiving device, another set of counters may be maintained to keep track of the number of frames, data blocks, and data bits received from the transmitting source, the number of frame errors, block errors, and bit errors, and so on. These counter values may be stored in a buffer. This buffer is typically implemented separate from the data buffer, and is used to store various counters over a period of time. The counter values may thereafter be used to determine the FER, PER, and/or BER, and other statistics such as the average frame activity, average burst length, and so on. The test results and statistical information may be reported from the remote terminal to the base station via one or more messages.

[0138] Test Data Service Option

[0139] In accordance with an aspect of the invention, the test data service option (TDSO) is a service that may be negotiated and connected using the available service configuration and negotiation procedures defined by a particular CDMA system and used for other services (e.g., a voice call, a data call). The remote terminal may be able to propose and/or accept a service configuration having attributes that are consistent with valid attributes for that configuration. The remote terminal may also be able to indicate the preferred radio configurations for the forward and reverse links.

[0140] In an embodiment, the remote terminal is able to propose or invoke service-option-specific functions for a TDSO call by sending a message (e.g., a. Service Option Control Messagein the cdma2000 system) to the base station. This message may be sent such that an acknowledgement is requested or required from the base station. Via the message, the remote terminal may propose values for various test parameters to be used during the test period.

[0141] The base station receives the message and may accept or reject the remote terminal's proposed test parameter settings. If all the fields in the remote terminal's directive are within acceptable ranges for the base station, the base station may issue a directive that accepts the remote terminal's proposal. This directive may be sent to the remote terminal via a response message (e.g., a Service Option Control Message) that includes the same values, as proposed by the remote terminal, for the various fields.

[0142] Alternatively, if the remote terminal proposes a particular test setting not supported by or acceptable to the base station, the base station may issue a directive that may include alternative values (i.e., counter-proposals) to the remote terminal's proposed values. This directive may be sent to the remote terminal via a response message that includes the proposed values in the fields supported and accepted by the base station, and counter-proposed values in the fields not supported or accepted by the base station. For example, if the remote terminal requests a particular number of circular buffer frames N that is not supported by the base station, the base station may response with a value indicating the maximum number of frames for the buffer supported by the base station.

[0143] Thus, via messaging and negotiation, the base station is able to accept the remote terminal's proposal, or reject the proposal and provide alternative values for test parameters.

[0144] Upon receiving the response message from the base station, the remote terminal may accept the counter-proposed values or select new values that conform to the counter-proposed values. The remote terminal may then send to the base station another message proposing these new values.

[0145] Table 6 lists the valid service configuration for TDSO for a specific implementation in the cdma2000 system.

[0146] As noted above, a number of traffic channels may be concurrently tested on each of the forward and reverse links. For each traffic channel to be tested, the test parameters for the channel may be negotiated via the signaling and negotiation described above. Thus, traffic channels of various types on the forward and reverse links may be tested independently based on their respective sets of test parameter values.

[0147] In FIGS. 2A, 2B, and 4, the elements in the base station and remote terminal may be implemented by various means. For example, the pseudo-random number generators may be implemented with hardware, software, or a combination thereof. For a hardware implementation, pseudo-random number generators, controllers, and other processing units may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.

[0148] For a software implementation, these processing units may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. For example, the pseudo-random number generators may be implemented with software code stored in a memory unit and executed by a processor (e.g., controller 220 or 270).

[0149] The circular buffers for the test data for the traffic channels may be implemented with one or more buffers, which may be implemented using RAM, DRAM, Flash memory, or some other memory technology. Also, the pseudo-random number generators may be operated to generate test data for the traffic channels as the data is needed, without having to store the test data in buffers. In that case, the states of the pseudorandom number generators are appropriately maintained and updated such that the generators are able to generate the proper sequence of test data for each active frame.

[0150] Although various aspects, embodiments, and features of the test data generation and traffic channel testing of the invention have been described for the cdma2000 system, these techniques may be advantageously applied for the other wireless communication systems and other CDMA systems (e.g., the W-CDMA system).

[0151] A specific implementation of various aspects of the invention for a cdma2000 system is described in the following Exhibit A.

[0152] The foregoing description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of the inventive faculty. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.