flexible first-layer configuration of radio interface for connecting radio to PLMN

A radio block and wireless communication device technology, applied in the first layer and its interaction with higher layers, can solve the problems of physical layer consumption, high cost, and complex memory

Inactive Publication Date: 2004-05-12
UNWIRED PLANET
0 Cites 1 Cited by

AI-Extracted Technical Summary

Problems solved by technology

[0033] Thus, the conventional approach of using a predetermined and fixed layer-1 transport channel scheme disadvantageously implies a...
View more

Abstract

Flexibly configurable layer one transport channels produce radio blocks in response to communication information and extract communication information from radio blocks. Each transport channel can include an encoder or a decoder coupled to and cooperable with a data puncturer or a data repeater. An information source can produce for each transport channel first configuration information and second configuration information, wherein the first configuration information is indicative of how the associated transport channel is to be configured if a first modulation type is used for a current radio block, and wherein the second configuration information is indicative of how the associated transport channel is to be configured if a second modulation type is used for the current radio block. The physical layer can include a description information source that provides description information from which various configurations of the transport channels can be determined. The description information source provides the description information in the physical layer in response to further information which the description information source receives from a higher layer and which is indicative of a service request initiated by a communication network. One of the transport channels can be enabled to extract its associated communication information from a radio block while another of the transport channels is maintained disabled. The one transport channel provides the extracted communication information to a decision maker in a higher layer. In response to the extracted communication information, the decision maker decides whether the other transport channel should be enabled, and provides to the physical layer an indication of its decision.

Application Domain

Network traffic/resource managementChannel coding adaptation +2

Technology Topic

Real-time computingRadio interface +5

Image

  • flexible first-layer configuration of radio interface for connecting radio to PLMN
  • flexible first-layer configuration of radio interface for connecting radio to PLMN
  • flexible first-layer configuration of radio interface for connecting radio to PLMN

Examples

  • Experimental program(1)

Example Embodiment

[0051] The present invention allows the configuration of a customized and/or optimized first layer transport channel while a given call is being established. These first layer transport channels can be configured, for example, in such a way as to best support the services related to the call.
[0052] Fig. 2 schematically shows relevant parts of an exemplary embodiment of a radio transceiver according to the present invention, such as a radio transceiver in a mobile station shown generally as 13 in Fig. 1, or in Fig. 1 The type of radio transceiver in a base transceiver station (BTS) shown on the general map. The transceiver part shown in FIG. 2 is usually located at the first layer (physical layer or PHY layer) of the transceiver. A plurality of first layer transport channels (L1TC) 12 transfer data bits bidirectionally at 201 and the second layer (L2). The first layer transport channel 12 also transfers radio blocks bidirectionally with the radio block interleaver/deinterleaver 25 in the radio block part 200. For two-way communication, the radio block interleaver/deinterleaver 25 is in turn coupled with a physical radio channel (for example, a GERAN physical sub-channel). Of course, the modulator/de-interleaver is inserted between the radio block interleaver/deinterleaver and the physical channel. This structure is well known in the art and is not necessary for understanding the present invention, so it is not clearly shown in FIG. 2.
[0053] The first layer transport channel is configured according to configuration information referred to herein as a transport format (TF). Each layer 1 transport channel is configured according to its own transport format. The set of transport formats that define the first layer transport channel for a given call is referred to herein as transport format combination (TFC). Multiple transport format combinations can be stored in the TFC storage device 14, and the selected transport format combination composition transport format is output from the storage device 14 at 26 in order to configure the transport for sending or receiving a given radio block at the radio block port 200 Channel 12. For radio block reception, the first layer transport channels 12 are configured by their respective transport formats to generate data bits 201 in response to the radio block received at 200, which are forwarded to the second layer. In the transmission operation, the first layer transport channels 12 are configured by their respective transport formats to generate outgoing radio blocks at 200 in response to the data bits received from the second layer at 201.
[0054] The transport format combination is generated by the transport format assembler 16 and stored at 14. The transport format assembler 16 assembles each individual transport format of each transport format combination in response to the information received from the decoder 18 and in response to the information module stored in the information module storage device 20. Each information module stored in 20 contains information that can be used to configure the first layer transport channel to perform desired functions (such as CRC encoding, error correction encoding, code puncturing, code repetition, and interleaving). In response to the control information received from the decoder 18, the transport format assembler 16 retrieves the selected information modules from the storage device 20, and assembles these modules together to generate the relevant first layer transport channel that will be used to configure 12's delivery format. For example, the transport format used for transmission may include information modules corresponding to CRC encoding, error correction encoding, and code puncturing, respectively. An exemplary transport format for reception may include information modules corresponding to de-interleaving, error correction decoding, and CRC decoding, respectively. The information module storage device 20 may include, for example, information modules respectively corresponding to a plurality of CRC encoding/decoding schemes, and information modules respectively corresponding to a plurality of different error correction encoding/decoding schemes.
[0055] Therefore, the transport format assembler 16 can assemble many different transport formats, which respectively correspond to different possible combinations of the information modules stored at 20. As described above, the assembler 16 also organizes the individual transport formats into the transport format combination stored in 14. Each transport format combination can be used to configure multiple first layer transport channels 12, and each transport channel is configured by a respective corresponding transport format of the transport format combination.
[0056]The decoder 18 provides control information to the transport format assembler 16 in response to the transport format combination set (TFCS) descriptor stored in 21. The TFCS descriptor is received from the control plane layer of the transceiver. The TFCS descriptors are provided on a per-call basis, so each TFCS descriptor is associated with a corresponding call identifier (call ID) that is also provided from the control plane layer 27. The TFCS descriptor for a given call contains all the information needed by the transport format assembler 16 to assemble a set of transport format combinations that will be available for use during the relevant call. The TFCS descriptor includes information required by the transport format assembler 16 to compose various transport formats into appropriate transport format combinations stored in 14. The transport format combination is applied to configure the first layer transport channel 12 on a per radio block basis. More specifically, for each incoming or outgoing radio block, a new transport format combination can be selected from the storage device 14 so as to appropriately configure the first layer transport channel. The first layer transport channel 12 then either generates the radio block at 200 based on the data bit at 201, or generates the data bit at 201 based on the radio block at 200.
[0057] The transport format combination storage device 14 may include transport format combination sets respectively corresponding to a plurality of different TFCS descriptors, and these TFCS descriptors respectively correspond to a plurality of different calls. The TFCS descriptor is provided along with the call identification information at 27 during call setup. The TFCS descriptor is stored at 21 (e.g. indexed by the associated call ID) and is available to the decoder 18. The decoder 18 decodes each TFCS descriptor and provides all the information required for assembling the transport format combination set related to the TFCS descriptor to the transport format assembler 16. The assembler 16 can be assigned a transport format combination indicator (TFCI), which uniquely identifies each transport format combination of the transport format combination set specified by a given TFCS descriptor. The transport format assembler 16 can use TFCI to index each transport format combination in the storage device 14, and the call ID can be used to index a desired transport format combination set in the device 14. The assembler 16 may assign TFCI values, for example, in the order in which it generates and stores the TFC of the TFCS. In some embodiments, the TFCI for a given TFCS may have a value from "1" to the total number of TFCs in the TFCS.
[0058] During transmission, the second layer provides TFCI to the first layer in order to specify which transport format combination is expected by the current radio block of the current call. The TX/RX signal 28 indicates whether a transmission operation or a reception operation is occurring, and it controls the selector 22 so that the TFCI is directly provided to the storage device 14 from the second layer during the transmission operation. The transport format combination storage device 14 also receives the call ID 27 and TX/RX signals. The call ID allows the storage device to determine which transport format combination stored in it is to be accessed, the TFCI indicates which transport format combination in the group is to be used, and the TX/RX signal indicates the received version using the selected transport format combination , Or use the delivery version of the selected delivery format combination. The receiving version configures the first layer transport channel 12 to receive the radio block at 200 and generates the data bits at 201 from this, while the transmission version of the transport format combination configures the transport channel 12 to receive the data bits at 201 and generates from it Radio blocks at 200.
[0059] In addition, during transmission, the TFCI received from the second layer is transmitted through the selector 23, and thus is input to the relevant one of the first layer transmission channels 12. The TFCI is processed by the relevant layer one transport channel to be included in the radio block at 200. Each TFCS descriptor includes information defining the transport format that will be used to configure the layer 1 transport channel for the TFCI in order to allow the TFCI to be sent to the receiving end in the radio block. The transport format corresponding to TFCI is provided at 26 to the relevant layer one transport channel. At 26, a transport format for one or more data channels corresponding to the data bits at 201 is also provided. Therefore, each outgoing radio block is generated by transmitting the data bits and TFCI at 201 through the appropriate layer 1 transport channel 12 to generate the radio block at 200.
[0060] During reception, the TFCI is received in the radio block 200, and is passed through its related first layer transport channel through the selector 22 (by means of the TX/RX signal indicating the receiving operation), and finally to the storage device 14. Therefore, the received TFCI can be applied to the storage device 14 in order to identify the transport format combination to be used to process the rest of the incoming radio block. The transport format of the selected transport format combination is then applied to the corresponding first layer transport channel 12, thereby allowing the rest of the first layer transport channel to process the rest of the radio block at 200 in order to produce the data bits at 201.
[0061] The receive (Rx) controller 24 can be utilized to control when the layer 1 transport channel is enabled during the receive operation. The receive (Rx) enable signal generated by the receive controller 24 ensures that only the first layer transport channel related to the TFCI is enabled first, and then the received TFCI is used to obtain the desired transport format combination from the storage device 14 After that, the receiving controller 24 enables the remaining part of the first layer transport channel.
[0062] Fig. 3 schematically shows the first layer transport channel of Fig. 2 in more detail. Figure 3 shows the first layer transport channels individually in their respective transport formats and reception enable signals. As shown in the figure, the first layer transport channel used for TFCI receives the corresponding TFCI transport format, which is denoted as TF(TFCI). The first layer transport channel used for TFCI is represented as L1TC (TFCI) in FIG. 3, and it also receives the corresponding reception enable signal from the reception controller 24. This receive enable signal is represented as EN (TFCI) in Figure 3. Figure 3 also shows an exemplary transport format combination, that is, the nth transport format combination, which is denoted as TFC(n). As shown in Figure 3, TFC(n) includes N n A transport format, represented as TF(1)...TF(N n ). In this way, the nth transport format combination includes N n Transport formats, which in turn are configured with N n The corresponding first layer transport channels are represented as L1TC(1)...L1TC(N n ). N n Each of the two channels also receives the corresponding receive enable signal, which is represented as EN(1)...EN(N n ). For an exemplary transport format combination set with M transport format combinations, the subscript n in FIG. 3 can take the value of 1, 2, ..., M. In addition, each of the M transport format combinations may include its own uniquely related number of transport formats, which is represented as N in FIG. 3 n.
[0063] During transmission, the first layer transport channels of FIGS. 2 and 3 collectively output the radio block at 200, and during reception, each first layer transport channel collectively receives the radio block at 200 as input. Fig. 4 shows an example of radio blocks that can be collectively output by the first layer transport channel or that can be collectively received by the first layer transport channel as an input. As shown in FIG. 4, the radio block includes a TFCI part (for example, a layer 1 header), which indicates the combination of transport formats that are used at the transmitter and should therefore also be used at the receiver. The rest of the radio block carries user data. The radio block shown in FIG. 4 corresponds to the value of n=M in FIG. 3, so that the radio block includes N in addition to the TFCI information part. M User data (corresponding to N M L1TC). The part denoted as the radio block 41 of the transport format 1 is the part of the radio block that has been generated by L1TC(1) (transmitting operation) or the part to be input to the radio block of L1TC(1) (receiving operation). Similarly, it is represented as transport format N M The part of the radio block 41 represents L1TC (N M ) Output (send operation) or to L1TC (N M ) Input (receive operation).
[0064] Because one or more layer 1 transport channels may be configured differently from all other layer 1 transport channels, and therefore may have, for example, different propagation delays than all other layer 1 transport channels, multiplexing equipment or Other suitable parallel cascaded equipment (not shown explicitly in Figures 2 and 3) can be coupled to one side of the radio block of the first layer transport channel in order to cascade the outputs of the various first layer transport channels together , So that the radio block is usually formatted as shown in Figure 4. The radio block formed in this way may then be input to the radio block interleaver 25. At the point where the radio block is input to the interleaver 25, the radio block may be subjected to usual conventional interleaving, modulation, and any other suitable conventional processing (not explicitly shown) before being transmitted on the physical radio channel.
[0065] As described above, when a call for a desired service is established, the 3G core network in a conventional PLMN sends an RAB request containing information about the service for which the call is established to the radio access network of the PLMN. In the example of the GERAN radio access network, the radio resource control (RRC or RR) layer of GERAN can be configured according to the present invention to transform the RAB request into the desired TFCS descriptor for the call (see also Figure 2). The RRC (or RR) layer can perform this transformation based on the above-mentioned information provided in the RAB request and other information traditionally available in the radio access network (for example, available radio resources, etc.). The RRC (or RR) layer can be designed according to the present invention to find the appropriate configuration of the first layer transport channel (specified by the TFCS descriptor) in order to meet the requirements in the RAB request, while saving resource utilization in the radio access network . The RRC (or RR) layer in GERAN (for example, the BTS of GERAN) can send the TFCS descriptor to the physical layer of GERAN, and can also send the TFCS descriptor to the RRC (or RR) layer of the mobile station. The RRC (or RR) layer of the mobile station can forward the TFCS descriptor to the first layer of the mobile station according to the present invention. The above exemplary processing of the RAB request is shown in FIG. 5. The example in Figure 5 uses the RRC layer. In Figure 5, the first layer of the BTS and the first layer of the mobile station are called the PHY layer.
[0066] Figure 6 shows an exemplary TFCS descriptor according to the present invention. As described above, the TFCS descriptor includes all the information required by the transport format assembler 16 to assemble all transport formats of each transport format combination from the information module stored at 20, and each transport format is for the call corresponding to the TFCS descriptor. Available. As shown in Figure 6, the TFCS descriptor includes a field that specifies the size of the radio block (see also 200 in Figure 2 and 41 in Figure 4), a field that specifies the number of TFCs available for use during a call, and a field specified in Figure 2 The field of the type of interleaving/deinterleaving performed by the radio block interleaver/deinterleaver 25. The TFCS descriptor of FIG. 6 also includes a TFCI descriptor 62. This TFCI descriptor includes a data structure 62A. The data structure 62A has the following fields: specify the number of bits to be output by L1TC (TCFI) during transmission (the number of input bits used for L1TC (TCFI) during transmission is obtained by knowing the number of TFCs) The fields that are implicitly known), the fields that specify the type of CRC encoding/decoding applied in L1TC (TCFI), the fields that specify the type of error correction encoding/decoding implemented in L1TC (TCFI), and the fields in the figure In the sixth embodiment, it indicates whether to use an interleaved 1-bit field in the L1TC (TCFI). During reception, the output bit field certainly specifies the number of bits that will be input to L1TC (TFCI). In some embodiments, L1TC(TFCI) is configured to provide a ratio of L1TC(1),...,L1TC(N M ) The most robust and better performance.
[0067]The TFCS descriptor of FIG. 6 also includes a transport format combination (TFC) descriptor 63, which specifies the number of TFCs available for the call, and it also includes a TFC descriptor data structure for each TFC related to the TFCS. An example of such a TFC descriptor data structure is shown as 63A.
[0068] Each TFC descriptor data structure includes the number of transport formats specified in the TFC, and also includes a transport format descriptor 64, which specifies the transport format descriptor data structure for each transport format of the TFC. An example of such a transport format descriptor data structure is shown as 64A. As shown in FIG. 6, the exemplary transport format descriptor data structure includes a plurality of fields, which include the transport format of FIG. 2 when assembled from the information module 20 and used to configure the transport format of the corresponding first layer transport channel 12. Information used by the assembler 16. The transport format descriptor data structure shown as 64A in FIG. 6 includes the following fields: an 11-bit field for specifying the number of bits to be input to the corresponding transport channel (for example, during transmission), Another 11-bit field of the number of bits output by the corresponding transport channel (again, for example during transmission), a 3-bit field for specifying the CRC encoding/decoding type to be used in the corresponding transport channel, Another 3-bit field that specifies the error correction coding/decoding type to be used in the corresponding transport channel, and in the embodiment of FIG. 6, is used to specify whether the corresponding transport channel will apply interleaving/deinterleaving. Bit field. If the "bit in" field and the "bit out" field are defined for the transmission operation, they can simply be exchanged for the reception operation.
[0069] The decoder 18 of FIG. 2 can extract all the information required by the transport format assembler 16 to generate the transport format combination stored at 14 from the TFCS descriptor (for example, the TFCS descriptor of FIG. 6). Figure 7 shows exemplary CRC encoding/decoding types that can be specified by the corresponding CRC field value in the TFCS descriptor in a table format. The information required to implement various displayed exemplary types of CRC encoding/decoding may be contained in the corresponding information module stored in 20 of FIG. 2. Similarly, FIG. 8 shows exemplary error correction encoding/decoding types that can be represented by the value of the corresponding field in the TFCS descriptor in a table format. All the information required to implement the various exemplary types of error correction encoding/decoding shown in FIG. 8 may also be included in the corresponding information modules stored in 20 of FIG. 2.
[0070] Fig. 9 shows various exemplary radio block sizes that can be specified by the radio block size field value of the TFCS descriptor in a table format. As shown in Figure 9, the different possible combinations of modulation and physical channel data rates have different radio block sizes associated with them.
[0071] Fig. 10 shows various exemplary radio block interleaving types that can be specified by the corresponding field value of the TFCS descriptor in a table format. Although strictly speaking the radio interleaving/deinterleaving 25 in Figure 2 is not part of the first layer transport channel 12 and is not defined by the transport format shown in Figure 2, in any case, this information provided in the TFCS can be translated The encoder 18 extracts and is provided to the interleaver/deinterleaver 25 (not shown obviously in FIG. 2), thereby controlling the operation of the interleaver/deinterleaver 25.
[0072] Regarding the use of code puncturing or code repetition, any of them may be required in the transport channel to ensure that the number of bits output by the transport channel (during transmission or reception) can be described by the transport format related to the transport channel The number of bits specified by the symbol data structure is consistent. If the number of output bits generated by the transport channel is greater than the number of bits specified by the transport format descriptor data structure, puncturing is required. If the number of bits output by the transport channel is less than the number of output bits specified by the transport format descriptor data structure, repeats are required . The need for perforation (or repetition) can be determined by the transport format assembler 16 when assembling the transport format combination for storage at 14. If puncturing or duplication is used in the transmission channel at the transmitting end, the corresponding de-puncturing or de-duplication is used in the corresponding transmission channel at the receiving end.
[0073] The puncturing (or repetition) pattern can be calculated algorithmically based on the number of bits before or after puncturing (or repetition). The number of bits before puncturing (or repetition) is implicitly known (code rate x (information bits + CRC bits)). The number of bits after puncturing (or repetition) is a parameter (for example, the "bit out" parameter of FIG. 6).
[0074] For example, drilling can be obtained as follows:
[0075] If a block of N bits is to be punctured to contain M bits, then in the following position
[0076] J=floor(I*N/(N-M))
[0077] Of bits are punched, where
[0078] I=0,..., N-M-1
[0079] And "floor" means to take the integer part.
[0080] On the other hand, if repetition is to be implemented, the repetition can be derived as follows:
[0081] If a block of N bits is repeated to contain 0 bits, then the following positions
[0082] J=floor(I*N/(O-N))
[0083] The bit at is repeated, where
[0084] I=0,..., 0-N-1
[0085] And "floor" means to take the integer part.
[0086] If error correction is required, a channel (ie, error correction) coding can be selected from a set of available channel coding types (for example, see FIG. 8). This group may include, for example, non-recursively terminated convolutional codes, recursively terminated convolutional codes, and tail-biting convolutional codes and block codes. The constraint length of the convolutional code is a parameter (for example, 5 or 7 shown in Fig. 8).
[0087] The ratio of error correction codes is implicitly defined by the number of incoming bits (information bits + CRC bits) and the number of out bits after puncturing; in some embodiments, the ratio is selected to take into account the need for ratio matching. The highest possible ratio of the number of output bits. If a coding rate lower than, for example, 1/4 is required, a ratio of 1/4 can be selected, and repetition can be used to reduce the coding rate. The constraint length and ratio implicitly define the polynomial (fixed polynomial set) of the error correction code. In an exemplary application of the present invention, the first layer may be configured to support AMR. Assuming a narrowband AMR, 8 channel codecs are traditionally available, and each channel codec has a different number of 1A category bits and 1B category bits in every 20ms speech frame. This example assumes that 4 of the 8 channel codecs are available, so 4 TFCs (one for each codec) are required. According to some embodiments of the present invention, 1A category bits, 1B category bits, and AMR signaling (in-band) bits can be transported through different Layer 1 transport channels, respectively. Therefore, each TFC specifies three transport formats: One for category 1A bits; one for category 1B bits; and one for in-band bits. A given TFC may correspond to a traditional coding scheme such as CS-1, O-TCH/AHS122, or O-TCH/AHS795, for example. Therefore, TFCS can be seen as supporting traditional link adaptation.
[0088] In addition to voice frames, call signaling (e.g., FACCH) and silence information descriptors (e.g., SID UPDATE) can be supported on physical subchannels. This results in a total of 6 TFCs specified in the TFCS descriptor, namely, 4 TFCs for the 4 available codecs, one TFC for call control signaling, and one TFC for the silence information descriptor.
[0089] Fig. 11 conceptually shows an exemplary operation according to the present invention during transmission. As shown in Figure 11, TFCI is transmitted through its corresponding first layer transport channel 110, and the data bits received from the second layer are transmitted through TFC(1), TFC(2),..., TFC(M) Select a first layer transport channel specified by TFC (see also Figures 3 and 4 and the following discussion). As shown in Figure 11, for n=1, 2, ..., each TFC(n) of M includes N n Transport formats, which in turn specify N n A first-tier transport channel. The output of the transport channel implemented by the selected transport format combination is cascaded together (for example, through related multiplexing), and the result is cascaded with the output of the TFCI layer 1 transport channel 110 at 115, thereby producing The radio block 118 (see also FIG. 2) is used for radio block interleaving at 119. Each layer 1 transport channel shown in the example of FIG. 11 includes CRC coding, error correction coding, puncturing (or repetition), and interleaving. The corresponding transport channel at the receiver may include corresponding CRC decoding, error correction decoding, de-puncturing (de-duplication), and de-interleaving.
[0090] In view of the fact that TFCI is not actually user data and can be sent as, for example, a layer 1 header as shown in Figures 4 and 11, all layer 1 processing of TFCI does not strictly constitute a transport channel for user data. However, because the operations performed on TFCI in the first layer are similar to the operations performed on user data in the first layer, the first layer processing of TFCI is also referred to herein as the first layer transport channel (see also Figure 3 L1TC(TFCI)).
[0091] The present invention also supports the use of GMSK modulation and 8-PSK modulation on the same physical subchannel. An exemplary embodiment defines a transport format combination and a corresponding transport format combination indicator for each type of modulation. Then, before decoding the TFCI information, based on the principle of each radio block, blind detection can be performed at the receiving end. In order to limit the complexity, such multi-modulation support may be allowed, for example, only for block interleaved data. Figure 6A shows a TFCS descriptor used for such a multi-modulation operation.
[0092] When a shared physical subchannel is used in the downlink (for example, from 11 to 17 in FIG. 1), all radio blocks on the channel are not necessarily intended for one MS. Instead, several MSs can listen to one physical subchannel. Based on the information in each receiving block, each MS decides whether it is the intended recipient of the block. This is the case, for example, in GPRS and EGPRS. Because the traditional first layer knows the content contained in each part of the block, the first layer of each MS can only decode those parts of the block that are required for deciding whether the block is reserved for the MS. In order to achieve flexibility, the received first layer according to some embodiments of the present invention does not know the contents of the radio block except for the L1 header (including the TFCI). In such an embodiment, the first layer only decodes the block and passes it to the second layer. This means that all blocks are completely decoded. This has the disadvantage that processing power and battery power will be wasted on blocks not reserved for the MS.
[0093] This situation is even more serious when the MS has no ongoing downlink data flow but only uplink flow. In traditional GPRS and EGPRS, for example, a special part called the uplink status flag (USF) in the downlink radio block tells the MS whether it is allowed to transmit on the uplink. If there is no ongoing downlink flow, only USF needs to be decoded. However, if all parts of the downlink block are decoded in the first layer and passed to a higher layer in the MS, and if the higher layer then only uses the USF, then this causes unnecessary power consumption.
[0094] When using traditional incremental redundancy, the physical layer (for example, in EGPRS) needs to know the RLC sequence number of the received block in order to perform the soft combination of the earlier transmission of the same block. Traditionally, the first layer extracts the RLC sequence number from the RLC/MAC header. This type of operation is problematic in embodiments of the invention where the first layer does not know the contents of the received radio block.
[0095] Therefore, some embodiments of the present invention delay the operation of the selected L1TC during reception. In this way, initially (after extracting TFCI), only a subset of L1TC is operated in order to pass information to higher layers. The higher layers then interpret the received information to decide which additional L1TC should be enabled for operation.
[0096] To support this, a Send Up bit is included in the transport format descriptor. The Send Up bit indicates whether L1TC should run and send its output to higher layers. Therefore, the Send Up bit of TFC indicates whether all L1TCs should run, or whether only a subset of all L1TCs should run initially, until there is a decoding command from a higher layer. The exemplary transport format descriptor structure of FIG. 12 includes such Send Up bits. In some embodiments, the Send Up bit can be stored in the TFC memory 14 by the assembler 16 (of FIG. 2) along with the corresponding transport format.
[0097] For example, if only the L1TC that processes the RLC/MAC header and USF is operated initially, a scheme similar to EGPRS can be realized. Based on this result, the higher layer can decide whether the remaining L1TC should be operated.
[0098] Figure 13 shows exemplary operations that can be performed in accordance with the present invention in response to the Send Up bit such as that shown in Figure 12. At 131, the received TFCI information is passed through its corresponding L1TC in order to determine which TFC is being used. Then check the active Send Up bit for all transmission formats of TFC. In the example of FIG. 13, the transport format related to the RLC/MAC header and USF includes active Send Up bits, so the RLC/MAC header and USF are transmitted through their corresponding L1TC to the higher layer. This is shown as 132 and 133 in Figure 13. According to the content of the RLC/MAC header (for example, the address therein, such as the temporary flow identifier TFI used in traditional GPRS/EGPRS), the RLC/MAC layer tells the first layer whether to enable the L1TC related to the RLC data block. In the example of FIG. 13, the L1TC for the RLC data block is enabled, as shown at 135, and the RLC information generated by the L1TC is forwarded to the RLC/MAC layer at 136. In addition, in FIG. 13, the RLC/MAC layer can determine from the USF information (forwarded at 132 and 333) whether to allow transmission in the next uplink block.
[0099] Figure 14 shows exemplary operations that can be performed in response to the Send Up bit when incremental redundancy is supported. At 141, L1TC (TFCI) is enabled so that the TFCI information can be checked to determine which TFC is being used. Also at 141, the Send Up bit of each transport format of the selected TFC is checked. In the example of Figure 14, the transport format related to the RLC/MAC header includes an active Send Up bit, so that the corresponding L1TC is enabled at 142 to allow the RLC/MAC header information to be forwarded to the RLC/MAC layer at 143 . At 144, the RLC/MAC layer provides the RLC sequence number to the first layer along with the instruction to enable the L1TC related to the RLC data block. At 145, the previously stored soft value of the previously received RLC data block with the same RLC sequence number is obtained, and at 146, the previously received RLC data block (from the received radio block) is applied to its L1TC. The L1TC used for the RLC data block uses the stored soft value retrieved at 145 and the current RLC data block (which also includes the soft value) to decode the current RLC data block. At 147, the new soft value generated by the operation of the L1TC (for example, due to incorrect CRC) is stored, and at 148, if the CRC is correct, the RLC data generated by the L1TC is forwarded to the RLC/MAC layer.
[0100] The soft value is a real number indicating the value (1 or 0) of the received bit and the probability of the bit being received correctly. The positive sign of the soft value indicates "0", and the negative value indicates "1". A large absolute value indicates a reliable bit, and a small absolute value indicates an unreliable bit.
[0101] Figure 15 schematically shows relevant parts of an exemplary transceiver embodiment supporting the operations shown in Figures 13 and 14. When the TX/RX signal (see also FIG. 2) indicates a receiving operation, the receiving controller 151 uses the received TFCI information to determine from the TFC memory 14 which transport format of the selected TFC includes the active Send Up bit. The receiving controller 151 then enables the L1TC corresponding to those transport formats including the active Send Up bit. Thereafter, the receiving controller 151 receives information 152 from the RLC/MAC layer, which indicates which (if any) additional L1TCs should be enabled so that information related to them can be forwarded to the RLC/MAC layer. In response to this information 152, the receiving controller 151 then enables the remaining L1TC. The operation of FIG. 14 can be supported by providing the soft value storage section 153. In response to the information received from the RLC/MAC layer at 152 (e.g., RLC sequence number). The receiving controller 151 may cause the soft value storage section 153 to exchange soft values ​​(as shown by the dotted line on FIG. 15) with the selected L1TC (for example, the L1TC related to the RLC data block of FIG. 14).
[0102] Referring again to FIG. 1, when GERAN is attached to a 2G core network, for example, a specific service request is traditionally used instead of a general RAB request. For example, enhanced full-rate voice can be requested in a traditional allocation request message from the 2G core network to GERAN. GERAN then traditionally selects the corresponding predetermined coding scheme for that particular service. Unlike RAB, the allocation request only signals one service and does not notify the parameters related to the service. Therefore, the allocation request cannot be translated into the TFCS descriptor shown in Figure 5.
[0103] Therefore, some embodiments store a pre-configuration for each service supported in the 2G core network. The pre-configuration includes all the information necessary for configuring the L1TC for the service (for example, broadband AMR) in terms of bit type (transport format), bit in/out, coding, etc. The pre-configuration table is stored in the MS and the radio access network. For example, in the BTS on the GERAN side, the pre-configuration table is used when the 2G core network sends an allocation request to establish a service. This advantageously allows the 2G core network to use its existing traditional signaling procedures.
[0104] Fig. 16 schematically shows relevant parts of an exemplary embodiment of a transceiver according to the present invention that can support service requests from a 2G core network. Initially pointed out that the radio access network can generally be received by the radio access network in the same way that the TFCS descriptor is distributed to the radio access network and the first layer of the mobile station (see also FIG. 5) by using, for example, the RRC or RR layer. The service requests (or appropriate information representing service requests) are distributed to the first layer of the radio access network and mobile stations. As shown in FIG. 16, in this example, the service request received from the RRC layer is applied to the pre-configuration table 161. The pre-configuration table 161 generates a TFCS descriptor in response to the service request. The TFCS descriptor has been pre-configured. It is selected for use by such a business request and has been stored in table 161. The table 161 may store therein a plurality of TFCS descriptors indexed with respect to corresponding service requests. The selected TFCS descriptor may be transferred to the storage device 21 of FIG. 2, and from that point onwards, the transceiver may, for example, generally operate as described above with reference to FIGS. 2-15.
[0105] Those skilled in the art will see that the embodiments of FIGS. 2-16 can be implemented in conventional radio access networks and mobile stations, for example, through appropriately modified software, hardware, or a combination of software and hardware.
[0106] Although the exemplary embodiments of the present invention are described in detail above, this does not limit the scope of the present invention, and the present invention can be implemented in various embodiments.

PUM

no PUM

Description & Claims & Application Information

We can also present the details of the Description, Claims and Application information to help users get a comprehensive understanding of the technical details of the patent, such as background art, summary of invention, brief description of drawings, description of embodiments, and other original content. On the other hand, users can also determine the specific scope of protection of the technology through the list of claims; as well as understand the changes in the life cycle of the technology with the presentation of the patent timeline. Login to view more.
Who we serve
  • R&D Engineer
  • R&D Manager
  • IP Professional
Why Eureka
  • Industry Leading Data Capabilities
  • Powerful AI technology
  • Patent DNA Extraction
Social media
Try Eureka
PatSnap group products