Patent Application
20110249561
The application relates generally to mobile networks and more particularly to systems and methods for sending and receiving acknowledgement information.
In mobile communications a basic transmit time interval (BTTI) block consists of a slot allocated over four consecutive frames. For example, frame 1 slot 1, frame 2 slot 1, frame 3 slot 1 and frame 4 slot 1 make up a BTTI block. In some implementations, a frame is approximately 5 milliseconds (ms) in duration, such that a BTTI block will span over four frames, or a 20 ms interval. A BTTI temporary block flow (TBF) is a TBF that uses BTTI blocks.
A reduced transmit time interval (RTTI) (part of global system for mobile communication (GSM) enhanced data rates for GSM evolution (EDGE) radio access network (GERAN) latency reduction feature) block uses the same frame structure described above, but an RTTI block consists of a pair of slots during a first frame, and a pair of slots during the next frame such that an RTTI block will span over two frames or a 10 ms interval. An RTTI TBF is a TBF which uses RTTI blocks. The transmission interval for an RTTI block is one-half the transmission interval of a BTTI block.
To perform uplink BTTI allocation, the network transmits an uplink state flag (USF) during a downlink BTTI block in a downlink slot of a preceding block period. The mobile station is thereby allocated a timeslot for uplink transmission of an uplink BTTI block that has the same number as that of the downlink slot used to transmit the USF.
The transmissions from a base station transceiver station (BTS) during a given radio block period may contain zero, one, or more than one blocks for a given mobile station, each block having a respective block sequence number.
To perform RTTI allocation, the network transmits USF signalling during the previous radio block period on a pair of timeslots. The mobile station is allocated a pair of uplink timeslots for transmission of an uplink RTTI block, these slots being defined as the “corresponding slot pair” or “corresponding PDCH (packet data channel)-pair” to the downlink pair used to transmit the USF. The corresponding uplink slots may or may not be the same as the downlink slots used to transmit USFs.
There is also a hybrid version of RTTI allocation where two BTTI USFs are used to allocate two RTTI blocks. Specifically, a first BTTI USF is used to allocate an RTTI radio block in the first two frames of the four frames that follow the two BTTI USFs, and a second BTTI USF is used to allocate an RTTI block in the second two frames of the four frames the follow the two BTTI USFs.
The feature “Latency Reductions” was added to enhanced general packet radio service (EGPRS) in 3GPP Release 7. One aspect of this feature is so-called “Fast Ack/Nack Reporting” (FANR).
Without FANR, all radio link control (RLC) acknowledgements (that is, indications by the receiver of RLC data blocks whether it had correctly received RLC data blocks sent by the transmitter) were done by means of “Packet Ack/Nack” messages, such as EGPRS Packet Downlink ACK/NACK messages, or Packet Uplink ACK/NACK messages. These messages are RLC/MAC control messages and did not contain any RLC data (though they may contain other RLC/MAC control information besides acknowledgement information).
The disadvantage of this approach is that it is quite inefficient, particularly when acknowledgement information needs to be sent quickly (e.g. in order to allow fast retransmissions of erroneously received blocks) or when the status of very few blocks needs to be indicated (e.g. in low bandwidth transmissions). In either scenario, the amount of acknowledgement information that is actually useful is very small compared to the capacity of an RLC/MAC control block.
The FANR feature allows piggy-backing of a small amount of acknowledgement information together with one or more RLC data blocks. In this case, the acknowledgement information is referred to as a PAN (piggy-backed Ack/Nack) field.
An example of an exchange between a network and a mobile station involving the PAN field is depicted in
Note that polls that request an uplink transmission in a given radio block period are sent much earlier than USFs which allocate resources in the same radio block period. It is possible that a poll and a USF may refer to the same uplink transmission opportunity (this is well-known and taken into account by the network when performing scheduling).
In the case of a PACCH block or a PAN field, the mobile station is allowed a minimum of 4 time division multiple access (TDMA) frames periods (approx. 20 ms) to encode the PACCH block or PAN field (for reference see table 10.4.4b in 3GPP TS 44.060, which states that the shortest delay between the start of the poll transmission and the start of the response is 6 TDMA frames. Because the end of the poll is received 2 TDMA frame periods after the start of the transmission of the poll, this leaves 4 TDMA frame periods for constructing and encoding the response.
In addition to sending a PAN in response to a poll, a mobile station may be required to send PANs ‘pro-actively’ based on the status of the data blocks it has received. This is referred to as Event-based FANR. If Event-based FANR is enabled, the mobile station is expected to report, by means of a PAN sent at the earliest opportunity, missing blocks.
In order to specify this behavior, data blocks which are known to be missing are classified as either REPORTED, or UNREPORTED. On initial detection of a missing block, the status of that block is set to UNREPORTED. When the status of that block is indicated by means of any acknowledgement information (e.g., Ack/Nack information) (need not necessarily be a PAN), the state is set to REPORTED. If Event-based FANR is active, mobile stations are required to insert PANs into uplink (UL) data blocks for as long as there exists blocks (e.g., downlink blocks) with the status UNREPORTED.
A “missing” data block may be detected either by out-of-sequence reception (e.g. receiving block 4 before block 3 has been received would indicate that block 3 is missing) or by decoding the block header (which includes the block sequence number) but failing to decode the data portion correctly.
The current 3GPP specifications indicate that:
The reaction times referred to above ignore ‘idle’ or ‘search’ TDMA frames which may be used for neighbor cell measurements, etc.
A PAN sent in response to the poll includes a bitmap; the bitmap is a sequence of 1's and 0's corresponding to a consecutive sequence of block sequence numbers (BSNs) plus (optionally) some padding. Each bit indicates an ACK or NACK for the block having the block sequence number. The PAN also includes information from which the BSN of the first (lowest) BSN being reported can be determined. In some cases, a bitmap is generated which is not full, because the bitmap has a fixed size and there are fewer blocks to acknowledge than allowed for by the fixed size of the bitmap. In this case, the bitmap includes a bit for each of the blocks to acknowledge, and is then padded, for example with 0's, to complete the bitmap. The transmission of blocks is not necessarily in numerical order, for example because of retransmissions. Thus, correspondingly, the mapping of bits in the PAN bitmap is not necessarily in accordance with the order in which the blocks were transmitted.
In an example of a possible constraint on bitmap generation, for polled PANs, 3GPP TS 44.060 v.7.17.0, sub-clause 9.1.8.2.3, it is stated:
Note that 3GPP TS 44.060 does not include similar corresponding text for event-based PANs.
Methods and apparatus described herein facilitate acknowledgement information (e.g., such as ACK/NACK information contained within a piggy-backed ACK/NACK (PAN), EGPRS packet downlink ACK/NACK, etc.) communication between a mobile station (MS) and a network to avoid confusion in decoding the acknowledgement (e.g., ACK/NACK) information. According to an example method, the mobile station provides an indication to the network to indicate the period for which ACK/NACK reporting is provided. The MS may indicate that a PAN message includes reporting for block periods after a poll or event has caused a PAN to be sent and before the PAN is sent.
As indicated in the background, due to the “implementation option” allotted to the MS, the MS may consider RLC data blocks that are received in the following block periods (the block periods following the block period within which the poll was received), taking into account all the RLC data blocks received in those periods.
By providing timely ACK/NACK information to the network, it may be possible to avoid unnecessary retransmission of blocks that the mobile station has successfully received, and to trigger retransmissions of blocks that the mobile station has not yet received correctly. While the implementation option described above allows for the mobile station to include timely information, this option may result in ambiguity in the interpretation of a PAN field, negating the benefits of the timely reporting.
The network does not know a priori to what extent (if any) the mobile station is making use of this implementation option. More specifically, the network may not be able to determine whether the mobile station is generating a PAN taking account of RLC data blocks that are received in radio block periods following the poll, taking into account all RLC data blocks received in those radio block periods, as allowed by, but not mandated by 3GPP TS 44.060 v.7.17.0, sub-clause 9.1.8.2.3.
This leads to two possibilities for ambiguity or confusion. The first possibility for confusion stems from the lack of distinction between padding bits and ACK/NACK bits. For example, in 3GPP TS 44.060 v.7.17.0, padding bits and NACK indications both use a ‘0’ indication. As such, the network may not be able to tell if a particular bit in a bitmap is a padding bit as opposed to a NACK if the bit position corresponds with a block transmitted during a questionable radio block period. This is illustrated in examples 1-4 described below.
The second possibility confusion stems from not knowing whether the generation of a particular ACK/NACK bit has taken into account a particular transmission of a block. In some cases, the network may be able to determine that the status of a particular block (which may be identified by its sequence number) is reported within the bitmap. However, if multiple instances of that block have been transmitted, the network may not be able to determine which instances the ACK/NACK information relates to, and in particular whether the ACK/NACK information takes account of the most recent transmissions of that block. This second possibility for confusion arises where the status of a block is reported in the bitmap, but the network had transmitted multiple instances of the block, including one or more instances transmitted before or during the last radio block period for which the status of the received block must be taken into account by a mobile station when constructing a PAN, and one or more instances transmitted during subsequent radio block periods (but before the PAN is transmitted). The network may not be able to determine whether or not the mobile station report has taken into account the latter transmission(s). This is illustrated in Example 3.
This second possibility for confusion arises not only in PAN bitmaps, but also in other bitmap-based ACK/NACK information where each bit corresponds to a particular block (and does not explicitly distinguish the status of multiple individual transmissions of the same block) and where the mobile station has some flexibility in determining the instant in time at which the status of received blocks is reported. For example, this applies in the case of EGPRS PACKET DOWNLINK ACK/NACK messages and EGPRS PACKET DOWNLINK ACK/NACK TYPE 2 messages sent by mobile stations operating using a downlink dual carrier configuration, using the EGPRS2 feature, or running in RLC non-persistent mode (see 3GPP TS 44.060 v.7.17.0). This second type of confusion arises even when there is no padding or where the end of the bitmap is explicitly indicated, hence the example implementations below apply in this case as well.
These two possibilities for confusion will now be described in detail by way of example. Examples 1, 2, 3 and 4 are provided below to illustrate this problem.
Considering RTTI, the timeline for a poll and response is as shown in
With reference to
Since the network cannot determine which of the above is the case, it does not know whether the mobile station took account of block n+1 when building the PAN, and hence it cannot determine whether or not the mobile station has received block x correctly.
With reference to
Note that the above examples are based on the current specifications, whereby ‘padding’ bits are set to ‘0’, which is the same as used for NACKs. If padding bits are set to ‘1’ and all ‘1’ bits are ignored (similarly to how PANs received by the mobile station are interpreted), a similar problem arises as shown by way of example in
Another example will be described with reference to
Disadvantageously, there is no specification as to which blocks shall/may be reported by means of event-based PANs (in terms of block periods during which those blocks were received).
Furthermore, the mobile station keeps track of which missing blocks it has reported to the network (see Event-based FANR in Background section). Under event-based FANR rules, mobile stations will stop sending Event-based PANs if they have no UNREPORTED blocks. However, due to the confusion as to which radio block periods the mobile station has taken into account, the following may arise:
As a result, the efficiency of the event-based FANR breaks down, because the mobile station believes that it has informed the network of some missing blocks, but the network misinterprets the indication and does not act on these NACKs.
For poll-based PAN transmissions, in what follows, a “questionable radio block period” is a radio block period that is subsequent to a radio block period within which a poll was sent, and prior to the radio block period within which the PAN is transmitted. For RTTI, there are two such radio block periods, referred to as radio block periods n+1 and n+2, where the poll was transmitted during radio block period n. For BTTI, there is one such radio block period, referred to as radio block period n+1, where the poll was transmitted during radio block period n. The number of questionable radio block periods can be different (greater than or less than) from what is set out above if the reaction time of the mobile station is changed, for example as described for some of the examples below in which the number of questionable radio block periods is reduced.
Similarly, for event-based PAN transmissions, in what follows, a “questionable radio block period” is a radio block period that is subsequent to a radio block period within which the mobile station determines that there is a block missing, and prior to the radio block period within which the event-based PAN is transmitted. For RTTI, there are two such radio block periods, and for BTTI, there is one such radio block period.
Network Ignores Information Relating to Questionable Radio Block Periods
In some embodiments, the network is configured to ignore information relating to “questionable” radio block periods. In the event the mobile station did send an ACK or NACK in respect of a block transmitted during a questionable radio block period, the network will not process this, and will likely re-send the block. For RTTI, the network will ignore the portion(s) of the bitmap that would correspond to blocks transmitted during radio block periods n+1, n+2, while for BTTI, the network will ignore the portion(s) of the bitmap that would correspond to block(s) transmitted during period n. The portions that are ignored may or may not be contiguous and may or may not come at the end of the bitmap. In some cases, there may be higher BSNs which are unambiguously reported, while the status of some lower number BSNs are questionable.
Configure the Mobile Station to not Report on Blocks Received During the Radio Block Period Immediately Preceding the Transmission of the PAN
With this embodiment, the mobile station is configured to not report on blocks received during the radio block period immediately preceding the transmission of the PAN. Recall that for RTTI, assuming a response time of 3, the questionable radio block periods may include radio block periods n+1 and n+2. Radio block period n+2 is immediately before the transmission of the PAN in radio block period n+3, and as such with this approach, the mobile station is configured to not send PAN in respect of any blocks received during radio block period n+2. In other words, radio block period n+2 is no longer a questionable radio block period.
Recall that for BTTI, assuming a response time of one, the questionable radio block periods include radio block period block n+1. Radio block period n+1 is immediately before the transmission of the PAN in radio block period n+2, and as such with this approach, the mobile station is configured to not send PAN in respect of radio block period n+1. In other words, radio block period n+1 is no longer a questionable radio block period. In effect, there are no questionable radio block periods for BTTI.
The defined response time for RTTI or BTTI may be changed (from 3 and 2 respectively). In this case, the number of questionable radio block periods for this method would change accordingly. For example, if the response time was 3 for BTTI, then the mobile station would not report on blocks in radio block period n+2, but may report on blocks in radio block period n+1 so there is one questionable block period.
In some embodiments, this approach is combined with the above described embodiment in which the network ignores information relating to questionable radio block periods. In this case, ignoring information corresponding to the questionable radio block period(s) has a smaller effect on the efficiency of the FANR algorithm than currently (because there are fewer questionable radio block periods).
A flowchart of a method for implementation in a network, for example by one or more components of the network will now be described with reference to
The corresponding method for implementation by a mobile station will now be described with reference to
Validate Information Relating to Questionable Radio Block Periods.
Under the existing coding, padding and NACKs may be indistinguishable and/or it may be impossible to determine if a transmission of a block during a questionable radio block period (that had been previously transmitted) has been considered in constructing the bitmap. However, if an ACK (bit=1), and it can be validated that the ACK bit is in respect of a block which was transmitted during a questionable radio block period (so that the network could be sure that the ACK corresponded to that transmission, and not an earlier transmission of the same block) then the network deduces that the mobile station had taken into account that questionable radio block period (and any earlier questionable radio block periods). The network can then make use of any ACK/NACK information in respect of radio blocks transmitted during the questionable block period(s) thus validated knowing that the mobile station had taken into account transmissions received during that questionable block period(s).
The validation of a questionable radio block period (QBP) may, for example, depend on the fact that:
a bit sent corresponding to a block (with BSN=b) received in the QBP is not the same as a padding bit
*and* the network is sure that the bit corresponds to the reception of block b during the QBP, and not some earlier reception of block b.
For example, if the padding bits are 0s (also used for NACKs), it requires that
a bit sent corresponding to block b sent in the QBP is set to 1 (=ACK)
and, either:
this is the first possible reception of block b (because it was the first transmission by the network)
or, the most recent previous reception failed and was NACKed. (If this condition is not met, the network does not know whether i) the mobile station is treating blocks in the QBP and block b in that period was received correctly, or ii) the mobile station is not treating blocks in the QBP and the mobile station is reporting the state of the earlier transmission of block b).
If it is not possible to validate this questionable radio block period, then the network assumes that the mobile station is not taking into account those transmissions.
A similar approach can be implemented if the coding is reversed (so that padding uses ‘1’ bits, rather than ‘0’ bits). In this case, validation requires a NACK/0 bit to correspond to a transmission during the questionable radio block period.
However, if the mobile station had previously (unambiguously) NACK'ed the first transmission of block 6 so that the network is aware that the transmission of block 6 in period n−1 was unsuccessful, then the ACK in the PAN must correspond to the transmission in period n+1 and other indications for that block period can be validated.
A method for execution in a network, for example by one or more network components, will now be described with reference to
Determine Mobile Station Capability Based on Validation
In this solution, the mobile station is mandated to apply the same behavior consistently over a period of time (e.g. throughout a TBF, or from the receipt of one assignment message that modified assigned resources to the next assignment message that modifies assigned resources). Initially, the network assumes that the mobile station is not taking into account those transmissions received during the questionable radio block period(s).
If any questionable radio block period is validated (for example as described above under the heading “Validate” information relating to questionable radio block periods”, then the network stores that information and considers all corresponding future questionable blocks to have been validated.
For example, the network may determine as a result of receiving a particular PAN that the mobile station takes into account blocks received during radio block period n+1; then all subsequent block periods “n+1” are considered to be taken into account by the mobile station; i.e. on an ongoing basis, the PAN takes account of blocks received during the radio block period within with the poll was transmitted, and the following radio block period.
A method for execution by a network, for example by one or more network devices, will now be described with reference to
A corresponding method for execution by a mobile device will now be described with reference to
Reduce the Permitted “Questionable” Blocks in Event-Based PAN.
In some embodiments, for event-based PANs the mobile station is configured to take into account all radio block periods up to and including radio block period m−2 where the PAN is sent in radio block period m.
A method for execution in a network, for example for one or more network components, will now be described with reference to
A corresponding method for execution by a mobile device will now be described with reference to
Signal Mobile Station Capability
In some embodiments, rather than have the network make a determination, for example based on the ‘validation’ solutions described above, the mobile station signals its capability (in terms of reaction time and/or which block periods it considers when reporting PANs). Although this would require additional signalling, it would simplify network implementation and avoid any ambiguity. The network then takes the signalling into account, and processes received PAN information accordingly.
Signaling could be by means of the MS Radio Access Capabilities IE (see 3GPP TS 24.008), or within RLC/MAC control blocks, such as the EGPRS Packet Downlink ACK/NACK control message. This may, for example, be sent in various messages. Specific examples include an ATTACH REQUEST message, ROUTING AREA UPDATE message, etc.—these messages are defined in 24.008.
A method for execution by a network, for example by one or more network components, will now be described with reference to
A corresponding method for execution by a mobile device will now be described with reference to
Signal Network Capability or Expectation
In some embodiments, to further minimize any misinterpretation of ACK/NACK information, the network signals to the mobile station how the mobile station is expected to report ACK/NACK information. In some embodiments, the network indicates that the mobile station shall behave in a specific manner, or that the mobile shall behave according to whatever capability the mobile signals to the network.
Explicit signaling may be, for example, by means of broadcast system information blocks (e.g. in the GPRS Cell Options IE see 3GPP TS 44.060) or in assignment messages (e.g. PACKET DOWNLINK ASSIGNMENT message, see 3GPP TS 44.060).
In some embodiments, the absence of any explicit signalling indicates that a mobile is to behave in a particular manner, for example, to not take into account any blocks received during questionable radio block periods
Transmit ACKs for Blocks Received During Questionable Radio Block Periods
In some embodiments, a mobile station which is otherwise not taking into account a particular radio block period (or at least, not required to take into account a particular radio block period), nevertheless takes into account a block correctly received during that radio block period if a previous transmission of that block was unsuccessfully received, and thereby, instead of reporting a NACK (corresponding to the earlier transmission(s)) reports an ACK for that block. Since the network is expecting a report for that block (because of the earlier transmission(s)) then it would process a NACK (and not, for example, consider a ‘0’ bit as padding) and may retransmit the block. However, by replacing the NACK indication by an ACK indication, the network knows that no further transmission is necessary. For the functioning of the RLC protocol in general, it is not necessary that the mobile station identify which transmission(s) of a given block were correctly received and hence there is no problem in this case that the mobile station is reporting an ACK based on the reception of a block which the network would not have expected the mobile station to have taken into account when constructing the bitmap.
In some embodiments, this solution is applied regardless of any signalling received from the network indicating how the mobile should construct ACK/NACK bitmaps.
This solution has the benefit of minimizing unnecessary transmissions of blocks, including in particular pre-emptive retransmissions.
A flowchart of a method for execution by a mobile station will now be described with reference to
Using Bits in PAN to Indicate Reporting Period
In an example implementation, a MS (e.g., the MS 3000 described below in conjunction with
The PAN according to the example implementation includes a bit to indicate whether or not the PAN includes reporting for RLC blocks received in the QBP(s). An indication, which may be included in any type of communication, may indicate that data blocks are accounted for in acknowledgment information, will be accounted for in acknowledgement information, were previously accounted for in acknowledgment information, etc. For example, the last bit of the PAN bitmap may be a zero to indicate that the PAN does not include reporting for the QBP and a one to indicate that the PAN includes reporting for the QBP.
While the example implementation utilizes the final bit of the PAN to indicate whether or not the PAN includes reporting for the QBP, in the example of
Table 1 illustrates an example format for a PAN that includes a REP_BLKS field in an RTTI configuration. Table 2 illustrates an example format for the REP_BLKS field of a PAN in RTTI configuration. In the example implementation, m is the block period during which the PAN is sent.
Table 3 illustrates an example format for a PAN that includes a REP_BLKS field in a BTTI configuration. Table 4 illustrates an example format for the REP_BLKS field of a PAN in RTTI configuration. In the example implementation, m is the block period during which the PAN is sent.
In other implementations, the REP_BLKS field may be sent in an EGPRS PACKET DOWNLINK ACK/NACK or any other communication that is not a PAN. For example, a REP_BLKS_PDAN field may be included in a communication. The REP_BLKS_PDAN field indicates which radio block periods have been taken into account when constructing a bitmap for a communication. An example format for the REP_BLKS_PDAN field is shown in Table 5.1. If it is specified that the bitmap is to be sent due to both the reception of a poll and the event-based FANR rules, the coding for event-based FANR applies. If not present, the receiver shall assume that the bitmap has been constructed taking into account the minimum radio block periods permitted (e.g., according to sub-clause 9.1.8.2.3 of 3GPP TS 44.060). Table 5.2 illustrates an example layout of an EGPRS PACKET DOWNLINK ACK/NACK TYPE 2 information element.
When the MS 3000 will not report the status of blocks received during the QBP (block 2004), the MS 3000 sets the last bit of the PAN to 0 to indicate that the PAN will not include reporting for blocks in the QBP (block 2010). The MS 3000 then sends ACK/NACK information for blocks received prior to the QBP (e.g., through block n). The process of
When the final bit of the PAN is set to zero (block 2104), the serving transceiver 3021 extracts ACK/NACK information up to the questionable block period (e.g., n+1 in BTTI and n in RTTI) (block 2108). In other words, the serving transceiver 3021 recognizes that the MS 3000 is not reporting information for RLC blocks that were received during the QBP. The serving transceiver 3021 can recognize that bits that would correspond to RLC blocks received during the QBP do not indicate whether such blocks were received. For example, the serving transceiver 3021 may recognize the bits as padding. The process of
While the foregoing description ends with the extraction of the ACK/NACK information in blocks 2106 and 2108, additional processes may be performed to process the received information. For example, the serving transceiver 3021 may compare the received information with information about radio blocks that were sent to the MS 3000 by the serving transceiver 3021. The comparison may indicate which, if any, blocks may need to be retransmitted. For example, the serving transceiver 3021 may retransmit blocks that were indicated to have not been successfully received by a NACK response from the MS 3000. Because the serving transceiver 3021 will know whether a bit in the PAN that is a zero is indicative of a NACK or is a padding bit, the serving transceiver 3021 will know when a block must be retransmitted because it wasn't received and when a block does not need to be retransmitted because, for example, the MS 3000 was not reporting on the period during which the block was received and padding bits were included.
While not illustrated in
Using UL TFI in PAN to Indicate Reporting Period
In an example implementation, a MS (e.g., the MS 3000 described in conjunction with
According to 3GPP TS 44.060§10.3a.5, when starting sequence number (SSN)-based encoding is used (see 3GPP TS 44.060§9.1.14.1), the PAN field consists of a beginning of window (BOW), a short starting sequence number (ShortSSN), a reported bitmap (RB) and a temporary flow identifier (TFI) fields. In the downlink direction, the TFI field shall always include a valid value. In the uplink direction, the TFI field shall include a valid value only if multiple TBF (MTBF) procedures are supported by both the network and the mobile station; in all other cases, the bits of the TFI field shall be set to ‘0’. The length of the PAN field is 25 bits. The size of the ShortSSN field varies between 7 and 11 bits as defined in 3GPP TS 44.060§10.4.23.
Table 6 illustrates an example format for a PAN field according to 3GPP TS 44.060.
In an example implementation, the TFI fields of the example PAN field shown in Table 6 are used to indicate the reporting period and provide additional reporting information as shown in Table 7.
In the example implementation, bit 1 of octet 4 is set to zero by the MS 3000 to indicate that reporting for block(s) in the QBP is not included in the PAN and is set to one to indicate that reporting for block(s) in the QBP is included in the PAN. In addition, according to the illustrated example, bits 5, 6, 7, and 8 of octet 3 are be used to reporting addition ACK/NACK information for radio blocks. However, any implementation may be use combination of the QBP bit and additional radio block bits. For example, only the QBP bit may be added to the TFI bits, only the additional radio block bits may be added to the TFI bits, two QBP bits and three radio block bits may be included, or any other combination may be used. Of course, any other agreed-upon bits may be selected for reporting.
The foregoing example may be used any time the MS 3000 does not use the TFI fields. For example, the MS 3000 may not use the TFI field when the MS 3000 does not support multiple TBF procedures. The serving transceiver 3021 may be informed of the MS 3000 support for MTBF from the MS Radio Access Capabilities message. In another example, the PAN of table 7 may be used when the MS 3000 does not use EMST. The serving transceiver 3021 may be informed of the MS 3000 support for EMST from the MS Radio Access Capabilities message.
When the MS 3000 will not report the status of blocks received during the QBP (block 2206), the MS 3000 sets the last TFI bit to zero to indicate that the PAN will not include reporting for bits during the QBP (block 2214). The MS 3000 sends the PAN and includes four additional ACK/NACK reporting bits in the remaining four TFI bits (e.g., bits 5, 6, 7, and 8 of octet 3) (block 2216). The process of
When the MS 3000 supports MTBF and/or EMST (block 2204), the MS 3000 uses any other available PAN transmission technique (block 2212). For example, the MS 3000 may use the PAN format illustrated in table 6 or any other PAN transmission technique described herein or otherwise known. The process of
When the last TFI bit of the PAN is not set to zero (e.g., is set to one) (block 2308), the serving transceiver 3021 extracts the ACK/NACK information and decodes it on the basis that it reports the status of blocks received by the MS 3000 through the block period before the PAN was sent (e.g., including the QBP) (block 2312). The process of
When the MS 3000 and/or the communication network support MTBF and/or EMST (block 2304), the serving transceiver 3021 uses any other PAN reception technique available and agreed upon with the mobile station (block 2314). For example, the serving transceiver 3021 may receive a PAN formatted according to table 6 and/or any other PAN format described herein or otherwise known. The process of
While the foregoing description ends with the extraction of the ACK/NACK information in blocks 2310 and 2314, additional processes may be performed to process the received information. For example, the serving transceiver 3021 may compare the received information with information about radio blocks that were sent to the MS 3000 by the serving transceiver 3021. The comparison may indicate which, if any, blocks may need to be retransmitted. For example, the serving transceiver 3021 may retransmit blocks that were indicated to have not been successfully received by a NACK response from the MS 3000. Because the serving transceiver 3021 will know whether a bit in the PAN that is a zero is indicative of a NACK or is a padding bit, the serving transceiver 3021 will know when a block must be retransmitted because it wasn't received and when a block does not need to be retransmitted because, for example, the MS 3000 was not reporting on the period during which the block was received and padding bits were included.
In another example implementation, when a MS 3000 and/or a communication network support MTBF and/or EMST (e.g., block 2204 of
When the MS 3000 will not report the status of blocks received in the QBP (block 2406), the MS 3000 sets the last bit of the TFI to zero (block 2414). The MS 3000 then sends a PAN report including ACK/NACK information in the remaining TFI bits (e.g., the four bits illustrated in table 7) (block 2416). The process of
When the MS 3000 and/or the communication network support MTBF/EMST and/or more than one TFI is in use (block 2404), the MS 3000 determines if more than 4 TFIs are assigned (block 2418). When four or fewer TFIs are assigned, the MS 3000 sends the PAN report using three of the TFI bits for the QBP and the radio block reporting (block 2420). For example, the MS 3000 may use the format of table 8 and provide a QBP bit indicating whether or not reporting for the QBP is included (e.g., as described in conjunction with blocks 2406-2416) and include two additional radio block reporting bits. The process of
When more than four TFIs are assigned (block 2418), the MS 3000 sends the PAN report using two of the TFI bits for the QBP and the radio block reporting (block 2420). For example, the MS 3000 may use the format of table 9 and provide a QBP bit indicating whether or not reporting for the QBP is included (e.g., as described in conjunction with blocks 2406-2416) and include one additional radio block reporting bit. The process of
When the last TFI bit is not set to zero (e.g., the last TFI bit is set to one) (block 2508), the serving transceiver 3021 extracts the ACK/NACK information and decodes it on the basis that it reports the status of blocks received by the MS 3000 until the end of the QBP (block 2514). The process of
When the MS 3000 and/or the communication network support MTBF and/or EMST and/or more than on TFI is in use (block 2504), the serving transceiver 3021 determines if more than 4 TFIs are assigned to the MS 3000 (block 2516). When four or fewer TFIs are assigned, the serving transceiver 3021 extracts QBP information and ACK/NACK information including ACK/NACK information in two of the TFI bits (block 2518). For example, the serving transceiver 3021 may extract the information according to the format of table 8 to extract a QBP bit indicating whether or not reporting for the QBP is included (e.g., as described in conjunction with blocks 2508-2514) and two additional radio block reporting bits. The process of
When more than four TFIs are assigned (block 2516), the serving transceiver 3021 extracts the QBP information and ACK/NACK information including ACK/NACK information in one of the TFI bits (block 2520). For example, the serving transceiver 3021 may extract the information in accordance with the format of table 9 to extract a QBP bit indicating whether or not reporting for the QBP is included (e.g., as described in conjunction with blocks 2508-2514) and to extract one additional radio block reporting bit. The process of
While the foregoing description ends with the extraction of the ACK/NACK information in blocks 2510, 2514, 2518, and 2520, additional processes may be performed to process the received information. For example, the serving transceiver 3021 may compare the received information with information about radio blocks that were sent to the MS 3000 by the serving transceiver 3021. The comparison may indicate which, if any, blocks may need to be retransmitted. For example, the serving transceiver 3021 may retransmit blocks that were indicated to have not been successfully received by a NACK response from the MS 3000. Because the serving transceiver 3021 will know whether a bit in the PAN that is a zero is indicative of a NACK or is a padding bit, the serving transceiver 3021 will know when a block must be retransmitted because it wasn't received and when a block does not need to be retransmitted because, for example, the MS 3000 was not reporting on the period during which the block was received and padding bits were included.
While not illustrated in
While the example implementations described in conjunction with
Referring to
The mobile station 3000 is configured, through inclusion of the PAN generator 3010 which may be implemented in suitable hardware, firmware, and/or or software stored in device memory 3008, to perform any of the methods described above.
The network 3020 is shown to include a serving transceiver 3021 having at least one antenna 3022. At the instant depicted, the mobile station 3000 is obtaining wireless communications services via transceiver 3021. Also shown are two neighbour transceivers 3024, 3026 with associated antennas 3025, 3027. Transceivers 3021, 3025, 3026 may, for example for part of respective base stations. The network 3020 has a PAN processor 3028 responsible for implementing any of the network side methods described herein. The functionality of the PAN processor may reside in the serving transceiver 3021 or elsewhere in the network.
In the illustrated example, the PAN processor is implemented as software and executed on processors forming part of the network 3020. However, more generally, the PAN processor may be implemented as software running on appropriate tangible processing platform, hardware, firmware, or any appropriate combination thereof.
Furthermore, it is to be understood that the network 3020 would have any appropriate components suitable for a network providing wireless communications services. Note that the network 3020 may include wires that interconnect network components in addition to components for providing wireless communication with mobile stations. The components of the network 3020 are implementation specific and may depend on the type of wireless network. There are many possibilities for the wireless network. The wireless network might for example be a GSM network.
In operation, the mobile station 3000 communicates with the wireless network 3020 over a wireless connection 3040 between the mobile station 3000 and the serving transceiver 3021. The PAN generator 3010 of the mobile station 3000 and the PAN processor of the network 3020 participates in the generation and processing of PAN information, in accordance with one or more of the methods described above.
Referring now to
A processing device (a microprocessor 3128) is shown schematically as coupled between a keyboard 3114 and a display 3126. The microprocessor 3128 controls operation of the display 3126, as well as overall operation of the mobile station 3100, in response to actuation of keys on the keyboard 3114 by a user.
The mobile station 3100 has a housing that may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures). The keyboard 3114 may include a mode selection key, or other hardware or software for switching between text entry and telephony entry.
In addition to the microprocessor 3128, other parts of the mobile station 3100 are shown schematically. These include: a communications subsystem 3170; a short-range communications subsystem 3102; the keyboard 3114 and the display 3126, along with other input/output devices including a set of LEDS 3104, a set of auxiliary I/O devices 3106, a serial port 3108, a speaker 3111 and a microphone 3112; as well as memory devices including a flash memory 3116 and a Random Access Memory (RAM) 3118; SIM 3200, and various other device subsystems 3120. The mobile station 3100 may have a battery 3121 to power the active elements of the mobile station 3100. The mobile station 3100 is in some embodiments a two-way radio frequency (RF) communication device having voice and data communication capabilities. In addition, the mobile station 3100 in some embodiments has the capability to communicate with other computer systems via the Internet.
Operating system software executed by the microprocessor 3128 is in some embodiments stored in a persistent store, such as the flash memory 3116, but may be stored in other types of memory devices, such as a read only memory (ROM) or similar storage element. In addition, system software, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as the RAM 3118. Communication signals received by the mobile station 3100 may also be stored to the RAM 3118.
The microprocessor 3128, in addition to its operating system functions, enables execution of software applications on the mobile station 3100. A predetermined set of software applications that control basic device operations, such as a voice communications module 3130A and a data communications module 3130B, may be installed on the mobile station 3100 during manufacture. In addition, a personal information manager (PIM) application module 3130C may also be installed on the mobile station 3100 during manufacture. The PIM application is in some embodiments capable of organizing and managing data items, such as e-mail, calendar events, voice mails, appointments, and task items. The PIM application is also in some embodiments capable of sending and receiving data items via a wireless network 3110. In some embodiments, the data items managed by the PIM application are seamlessly integrated, synchronized and updated via the wireless network 3110 with the device user's corresponding data items stored or associated with a host computer system. As well, additional software modules, illustrated as other software module 3130N, may be installed during manufacture. In addition, the microprocessor 3128 executes SRI updating and SRI reading functions.
Communication functions, including data and voice communications, are performed through the communication subsystem 3170, and possibly through the short-range communications subsystem 3102. The communication subsystem 3170 includes a receiver 3150, a transmitter 3152 and one or more antennas, illustrated as a receive antenna 3154 and a transmit antenna 3156. In addition, the communication subsystem 3170 also includes a processing module, such as a digital signal processor (DSP) 3158, and local oscillators (LOs) 3160. The specific design and implementation of the communication subsystem 3170 is dependent upon the communication network in which the mobile station 3100 is intended to operate. For example, the communication subsystem 3170 of the mobile station 3100 may be designed to operate with the Mobitex™ DataTAC™ or General Packet Radio Service (GPRS) mobile station data communication networks and also designed to operate with any of a variety of voice communication networks, such as Advanced Mobile station Phone Service (AMPS), Time Division Multiple Access (TDMA), Code Division Multiple Access CDMA, Personal Communications Service (PCS), Global System for Mobile station Communications (GSM), etc. Other types of data and voice networks, both separate and integrated, may also be utilized with the mobile station 3100.
Network access may vary depending upon the type of communication system. For example, in the Mobitex™ and DataTAC™ networks, mobile stations are registered on the network using a unique Personal Identification Number (PIN) associated with each device. In GPRS networks, however, network access is typically associated with a subscriber or user of a device. A GPRS device therefore typically has a subscriber identity module, commonly referred to as a Subscriber Identity Module (SIM) card, in order to operate on a GPRS network.
When network registration or activation procedures have been completed, the mobile station 3100 may send and receive communication signals over the communication network 3110. Signals received from the communication network 3110 by the receive antenna 3154 are routed to the receiver 3150, which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog-to-digital conversion of the received signal allows the DSP 3158 to perform more complex communication functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to the network 3110 are processed (e.g., modulated and encoded) by the DSP 3158 and are then provided to the transmitter 3152 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the communication network 3110 (or networks) via the transmit antenna 3156.
In addition to processing communication signals, the DSP 3158 provides for control of the receiver 3150 and the transmitter 3152. For example, gains applied to communication signals in the receiver 3150 and the transmitter 3152 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 3158.
In a data communication mode, a received signal, such as a text message or web page download, is processed by the communication subsystem 3170 and is input to the microprocessor 3128. The received signal is then further processed by the microprocessor 3128 for an output to the display 3126, or alternatively to some other auxiliary I/O devices 3106. A device user may also compose data items, such as e-mail messages, using the keyboard 3114 and/or some other auxiliary I/O device 3106, such as a touchpad, a rocker switch, a thumb-wheel, or some other type of input device. The composed data items may then be transmitted over the communication network 3110 via the communication subsystem 3170.
In a voice communication mode, overall operation of the device is substantially similar to the data communication mode, except that received signals are output to a speaker 3111, and signals for transmission are generated by a microphone 3112. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the mobile station 3100. In addition, the display 3116 may also be utilized in voice communication mode, for example, to display the identity of a calling party, the duration of a voice call, or other voice call related information.
The short-range communications subsystem 3102 enables communication between the mobile station 3100 and other proximate systems or devices, which need not necessarily be similar devices. For example, the short-range communications subsystem may include an infrared device and associated circuits and components, or a Bluetooth™ communication module to provide for communication with similarly-enabled systems and devices.
Numerous implementations have been described for RTTI and BTTI. It is to be understood that each implementation may be applied to one or both or RTTI and BTTI. In some implementations, a first implementation is applied for RTTI, and a second different implementation applied for BTTI.
Implementations have been described with respect to polled PANs and event-based pans. However, any implementations may be used with for or both PAN types. For example, some implementations may be implemented for polled PANs while other implementations may be implemented for event-based PANs.
Similarly, numerous implementations have been provided that have focussed on PANs sent in response to a poll. These solutions can also be applied to event-based PAN. In some implementations, a first implementations (or pair of implementations) is used for PANs sent in response to a poll, and a second implementation (or pair of implementations) is used for event-based PAN.
Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that the disclosure may be practiced otherwise than as specifically described herein.
In these examples, the processes represented by each flowchart may be implemented by one or more programs comprising machine readable instructions for execution by: (a) a processor, such as the microprocessor 3128 shown in the example mobile station 3100 discussed below in connection with
Further, although the example processes are described with reference to the flowcharts, including
This patent claims the benefit of U.S. Provisional Patent Application Ser. No. 61/251,649, filed on Oct. 14, 2009, and entitled “SYSTEMS AND METHODS FOR SENDING AND RECEIVING PIGGY-BACKED ACK/NACK INFORMATION TO AVOID DECODING CONFUSION.” The disclosure of U.S. Provisional Patent Application Ser. No. 61/251,649 is hereby incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61251649 | Oct 2009 | US |
