RU2574603C2 - Back compatible approach to protocol level fields - Google Patents

Abstract

FIELD: radio engineering, communication.

SUBSTANCE: fields, for example serial numbers and indicators of protocol level length, are extended in expanded headings in order to become back compatible with the respective inherited headings. The existing fields of the inherited headings are not extended directly. Instead of it the existing fields are logically united with other fields of expanded heading. Whether the expanded fields or the inherited fields will be used, it can be defined dynamically on the basis of the current size of the transport block or semi-statically by means of top levels.

EFFECT: invention relates to communication system, in general to expansion of length fields and/or serial number in the structure of heading of communication level.

36 cl, 19 dwg

Description

RELATED APPLICATION

This application claims the priority and advantage of provisional application US No. 61/442492, entitled "BACKWARDS-COMPATIBLE APPROACH TO EXTEND LENGTH AND SEQUENCE NUMBER FIELDS", filed February 14, 2011, which is incorporated herein by reference in its entirety.

FIELD OF TECHNOLOGY

The technical field of the present disclosure relates generally to the extension of the length and / or serial number fields in the header structure of the communication layer, and in particular to the extension of the length and / or serial number fields in the header structure to ensure efficient data transmission.

BACKGROUND

Examples of LTE (Long Term Development Project) protocol stacks in 3GPP ( ^3rd Generation Partnership Project) for control and user planes are illustrated in FIG. 1. One or more of these layers are implemented in nodes in LTE. For example, in a typical UE (user equipment) all levels of protocol stacks of the control plane and the user are implemented. In a typical eNB (or, more generally, a network node), all user plane protocol layers and all control plane protocol layers, with the exception of the NAS layer, are implemented.

In accordance with 3GPP, new categories of UEs have recently been set in LTE Rel-10, so data rates of up to 3 and 1.5 Gbit / s can be achieved in the downlink and uplink, respectively. This is achieved by increasing the number of layers for spatial multiplexing and the number of carriers that can be configured for one UE. With these improvements, the maximum transport block (TB) size is increased to 299852 bits (37482 octets) in the physical layer (PHY), and the number of transport blocks that can be sent in one subframe is increased to 10.

However, user plane protocol formats defined for LTE Rel-8/9 do not fully support the high-speed data transmission offered by the advanced physical layer. This applies to all three sub-layers of the L2 (channel) layer, that is, the MAC (Media Access Control) layer, the RLC (Radio Control) layer and the PDCP (Packet Convergence Protocol) layer.

The size of the MAC SDU (Service Data Unit) enclosed in the MAC PDU (Protocol Data Unit) can be signaled in the MAC subtitle length (L) field, except when the MAC SDU is the last to be included in the MAC PDU (i.e. without any subsequent data , control or filling), for which the field L is not included. Examples of structures of an existing MAC subtitle are illustrated in FIG. 2A, 2B and 2C.

The MAC subtitle includes two reserved bits (R), a 1-bit extension field (E), and a 5-bit logical channel field (LCID). Field E is used to indicate whether there are more fields in the MAC subheading. When the E field is not set, the MAC subtitle includes the R / R / E / LCID fields, as illustrated in FIG. 2C. The last subtitle in the MAC PDU and the subtitles for fixed size MAC controls correspond to this structure.

For other MAC SDUs, that is, when the E field is specified, the corresponding MAC subheading also includes a 1-bit format (F) field and a 7- and 15-bit L field, as illustrated in FIG. 2A and 2B, respectively. That is, when the E field is specified, the MAC subheading includes the R / R / E / LCID / F / L fields. Field F indicates the size of field L. When field F is specified, the size of field L is 15 bits, as illustrated in FIG. 2B, and when the field F is not set, the size of the field L is 7 bits, as illustrated in FIG. 2A.

As illustrated in FIG. 3, the MAC PDU includes a MAC header, zero or more MAC controls, zero or more MAC SDUs, and optional padding. A MAC PDU header includes one or more MAC subheadings in which each MAC subhead corresponds to one of a MAC SDU, control, or pad. The entire MAC PDU — the header, controls, SDUs and padding — moves in the transport layer of the physical layer (L1).

Referring again to FIG. 2A-2C, note that the field L has a length of not more than 15 bits. Thus, the maximum supported MAC SDU size, including the L field, is 32767 octets. Field L is included in all MAC PDUs having more than one MAC subheading. For example, if the MAC PDU includes more than 2 octets of padding in addition to the data, then the size of the MAC SDU for the data must be indicated using the field L. According to the Rel-8/9 specification, each codeword L1 contains exactly one MAC PDU (transport block). Given the limitations of the L field, the MAC layer cannot populate the MAC PDU with one MAC SDU for data. On the other hand, multiple MAC SDUs are not allowed for new data per logical channel and per transport block. With these limitations, the consequence is that the MAC layer cannot use the large transport formats offered by the physical layer.

In some RLC-supporting systems, each of the RLC SDUs in the RLC PDU is associated with an 11-bit “LI” length indicator field. This limits the ability to merge when the RLC SDU or the remainder of the segmented RLC SDU exceeds 2047 octets. The last RLC SDU does not contain an LI field and therefore is limited only by the maximum size of the RLC PDUs. If combining the RLC SDUs is not possible, then the RLC layer may instead form multiple RLC PDUs. Unfortunately, this consumes more SN (sequence numbers) of the RLC.

This can be problematic because the RLC SN is a 10-bit field (1024 values), which limits the used window size to 511 RLC PDUs. That is, an RLC transmitter can generate and transmit up to 511 RLC PDUs before receiving a cumulative status message. As will be discussed later, this becomes especially limiting when combining the RLC SDU is not possible. In addition, the size of the RLC PDUs is limited by the SO fields (segmentation offset) of the RLC — SOstart and SOend — which each have 15 bits. Thus, the size of the RLC PDU is limited by the maximum size of the MAC SDU with field L.

PDCP supports PDCP SDUs up to 8188 octets in size, resulting in a maximum PDCP data PDU size of 8190 octets, including a header. Note that the PDCP SDU size can only be limited from above, but it is hardly possible to force a lower limit. Typical sizes of PDCP SDUs (such as IP packets) are around 1,500 octets. Additionally, it should be noted that PDCP PDUs exceeding 2047 octets require special processing at the RLC level, as described above.

SUMMARY OF THE INVENTION

A non-limiting aspect of the disclosed subject matter is directed to a method executed on a network node of a wireless network. A base station is an example of a network node. The method comprises determining whether to use the extended header for the protocol layer when wirelessly communicating with a mobile terminal. The protocol layer may be a layer above the physical (L1) layer. The method also comprises using an extended header for the protocol layer when transmitting and receiving a protocol level data unit (PDU) of the protocol layer when it is determined that the extended header is to be used. The extended header contains an inherited indicator field (L-I) with a predetermined number of indicator bits to use when specifying a PDU characteristic value. An inherited indicator threshold value associated with a characteristic may occur, the inherited indicator threshold value being the maximum characteristic value that may be indicated by the inherited indicator field L-I. The extended header contains an extended indicator field (E-I), which can be logically combined with the inherited indicator field L-I, so that the E-I / L-I combination contains enough bits to set the PDU characteristic value outside the inherited indicator threshold.

Another non-limiting aspect of the disclosed subject matter is directed to a method performed on a mobile terminal of a wireless network. User equipment is an example of a network node. The method comprises determining whether to use the extended header for the protocol layer when wirelessly communicating with a network node. The protocol layer may be a layer above the physical (L1) layer. The method also comprises using an extended header for the protocol layer when transmitting and receiving a protocol level data unit (PDU) of the protocol layer when it is determined that the extended header is to be used. The extended header contains an inherited indicator field (L-I) with a predetermined number of indicator bits to use when specifying a PDU characteristic value. An inherited indicator threshold value associated with a characteristic may occur, the inherited indicator threshold value being the maximum characteristic value that may be indicated by the inherited indicator field L-I. The extended header contains an extended indicator field (E-I), which can be logically combined with the inherited indicator field L-I, so that the E-I / L-I combination contains enough bits to set the PDU characteristic value outside the inherited indicator threshold.

Another non-limiting aspect of the disclosed subject matter is directed towards a network node, such as a wireless network base station. A network node comprises a plurality of protocol layer units structured to communicate with a mobile terminal. The plurality of protocol layer blocks comprises an RRC block structured to perform functions associated with the RRC layer, a PDCP block structured to perform functions associated with the PDCP layer, an RLC block structured to perform functions associated with the RLC layer, and a MAC block structured to performing functions associated with the MAC layer. At least one protocol layer unit is structured to determine whether to use an extended header for a protocol layer when wirelessly communicating with a mobile terminal, and to use an extended header for a protocol layer when transmitting and receiving a protocol level data unit (PDU). The protocol layer may be a layer above the physical (L1) layer. The extended header contains an inherited indicator field (L-I) with a predetermined number of indicator bits to use when specifying a PDU characteristic value. An inherited indicator threshold value associated with a characteristic may occur, the inherited indicator threshold value being the maximum characteristic value that may be indicated by the inherited indicator field L-I. The extended header contains an extended indicator field (E-I), which can be logically combined with the inherited indicator field L-I, so that the E-I / L-I combination contains enough bits to set the PDU characteristic value outside the inherited indicator threshold.

Another non-limiting aspect of the disclosed subject matter is focused on a mobile terminal, for example, user equipment in a wireless network. A mobile terminal comprises a plurality of protocol layer units structured to communicate with a network node. The plurality of protocol layer blocks comprises an RRC block structured to perform functions associated with the RRC layer, a PDCP block structured to perform functions associated with the PDCP layer, an RLC block structured to perform functions associated with the RLC layer, and a MAC block structured to performing functions associated with the MAC layer. At least one protocol layer unit is structured to determine whether to use an extended header for a protocol layer when wirelessly communicating with a network node, and to use an extended header for a protocol layer when transmitting and receiving a protocol level data unit (PDU). The protocol layer may be a layer above the physical (L1) layer. The extended header contains an inherited indicator field (L-I) with a predetermined number of indicator bits to use when specifying a PDU characteristic value. An inherited indicator threshold value associated with a characteristic may occur, the inherited indicator threshold value being the maximum characteristic value that may be indicated by the inherited indicator field L-I. The extended header contains an extended indicator field (E-I), which can be logically combined with the inherited indicator field L-I, so that the E-I / L-I combination contains enough bits to set the PDU characteristic value outside the inherited indicator threshold.

Another non-limiting aspect of the disclosed subject matter is directed to a time-invariant computer-readable medium storing programming instructions executed by a computing unit of a network node in a wireless network. Programming commands cause the network node to execute a method that runs on the network node or on behalf of the network node, as described above.

Another non-limiting aspect of the disclosed subject matter is directed to a time-invariant (non-temporary) machine-readable medium storing programming instructions executed by a computing unit of a mobile terminal in a wireless network. Programming commands cause the mobile terminal to execute a method performed on the mobile terminal or on behalf of the mobile terminal, as described above. In one or more of the aspects summarized above, determining whether to use extended headers can be performed dynamically or semi-statically.

DESCRIPTION OF DRAWINGS

The above and other objects, features, and advantages of the disclosed subject matter will become apparent from the following more specific description of preferred embodiments, which are illustrated in the accompanying drawings, in which reference numbers refer to like parts in different images. Drawings are not necessarily to scale.

FIG. 1 illustrates an exemplary LTE protocol stack for control and user planes;

FIG. 2A, 2B, and 2C illustrate respectively inherited MAC subheadings with a L field of 7 bits, 15 bits, and for fixed size MAC controls;

FIG. 3 illustrates an example of a legacy MAC PDU;

FIG. 4 illustrates an embodiment of transmitter and receiver nodes in a wireless network;

FIG. 5 illustrates an embodiment of a mobile terminal;

FIG. 6 illustrates an embodiment of a network node in a wireless network;

FIG. 7A and 7B illustrate examples of extended MAC subheadings;

FIG. 8 illustrates an example MAC PDU with an extended MAC header;

FIG. 9A and 9B illustrate further examples of extended MAC subheadings;

FIG. 10 illustrates an example method for managing a network node in a wireless network;

FIG. 11 illustrates an example process for determining whether to use an extended protocol layer header on a network node;

FIG. 12 illustrates another exemplary process for determining whether to use an extended protocol layer header on a network node;

FIG. 13 illustrates an example process for providing header format information in a handover of a mobile terminal between a source and a target cell;

FIG. 14 illustrates an example method for controlling a mobile terminal in a wireless network; and

FIG. 15 illustrates an example process for determining whether to use an extended protocol layer header on a mobile terminal.

DETAILED DESCRIPTION

For the purpose of explanation, and not limitation, specific details are set forth, for example, specific architectures, interfaces, techniques, and so on. However, it will be apparent to those skilled in the art that the technology described in this document may be practiced in other embodiments that depart from these characteristic details. That is, those skilled in the art will be able to develop various configurations that, although not explicitly described or shown in this document, embody the principles of the described technology.

In some cases, detailed descriptions of known devices, circuits, and methods are omitted so as not to clutter up the description with unnecessary details. All language in this document, listing principles, aspects, options for implementation, and examples, is intended to encompass both structural and functional equivalents. It is further understood that such equivalents include both currently known equivalents and equivalents developed in the future, i.e. any designed elements that perform the same function regardless of structure.

Thus, for example, it will be necessary to take into account that the flowcharts in this document may represent conceptual representations of explanatory diagrams embodying the principles of this technology. Similarly, it should be appreciated that any flowcharts, transition diagrams, pseudo-code, and the like represent various processes that can for the most part be represented on a computer-readable medium and can be executed by a computer or processor, regardless of whether such a computer is explicitly shown or CPU.

The functions of various elements, including functional blocks, designated or described as “processors” or “controllers”, can be provided through specialized hardware as well as hardware capable of running associated software. Once provided with a processor, functions may be provided by a single specialized processor, a single common processor, or a plurality of separate processors, some of which may be shared or distributed. Moreover, the explicit use of the term “processor” or “controller” should not be interpreted solely to refer to hardware capable of running software, and may include without limitation equipment with a digital signal processor (abbreviated “DSP”), read-only memory (abbreviated as "ROM") for storing software, random access memory (abbreviated as "RAM") and non-volatile memory.

In this disclosure, 3GPP is mainly used as examples for the purpose of explanation. However, the scope of this disclosure is not limited to the set of 3GPP wireless network systems, and may include many areas of wireless network systems. Also, a base station (e.g., RBS, Node B, eNB) will be used as an example of a node that includes one or more link layer units in which the described method can be performed to give preference to measurements. However, it should be noted that the disclosed subject matter is applicable to link layer units of any node in a network, such as a mobile terminal (e.g., a UE).

In this disclosure, the terms “inherited” and “enhanced” will be used. The context in which these terms are used is intended to clarify the meanings. Thus, FIG. 2A, 2B, and 2C may be described as showing examples of structures of the inherited MAC subheading.

As indicated earlier, the structures of the existing sub-heading of the channel layers, for example MAC, RLC, PDCP, may not be suitable for the large transport formats offered by the lower layers. This can cause problems at the MAC level. For example, if the size of the transport block provided by the physical layer is greater than 32767 octets, that is, if the physical layer provides advanced TB, then the inherited MAC layer cannot fill the advanced TB with one MAC SDU for one logical channel, which can lead to overfilling.

Problems can arise at the RLC level due to the inability of the legacy MAC layer to use advanced TB. For example, having multiple MAC SDUs per MAC PDU could equally well result in multiple RLC PDUs. But it is generally understood that the intention of the MAC / RLC protocols was to have only one new RLC PDU per logical channel per TB.

Having many RLC PDUs formed per TB and subframe can also lead to a lack of RLC sequence numbers. For example, suppose two new RLC PDUs are formed for each component carrier and for each TB, respectively, resulting in 20 RLC PDUs for each subframe (5 serving cells with two or more codewords (MIMO) in each). As a result, the RLC serial number space takes up 511 / 20≈25 milliseconds. This means that the RLC transmitter can send new data only for 3 RTT HARQ (Hybrid Automatic Repeat Request Receive-Transmit Periods) before the RLC sequence numbers are exhausted. If the RLC status report confirming the oldest RLC pending PDUs has not yet been received by then, the RLC protocol stops. This means that the RLC level cannot provide new data to the lower levels, which in turn causes underutilization of the assigned radio resources, and the maximum data rates set for advanced TB, for example, Rel-10 in LTE, will not be achieved.

At the PDCP level, you can run 2048 PDCP PDUs with the current PDCP sequence number space. With an IP packet size of 1,500 bytes, this corresponds to ~ 3 MB. With an estimated RTT PDCP of 25 ms, this limits theoretical throughput to approximately 980 Mbps (3 MB x 8 bits / byte / 0.025 s). This is well below the peak speed provided by the physical layer in LTE Rel-10. Note that it is impossible, or at least not recommended, to run more than 2048 PDCP PDUs in order to avoid ambiguity during a handover. If PDCP packets cannot be unambiguously identified during a handover, then data loss and HFN desynchronization (Hyper Frame Number) may occur, resulting in significant performance degradation.

In a non-limiting aspect of the present disclosure, the above and other problems associated with legacy systems are solved. Backward compatible method (s), block (s) and / or system (s) are provided for extending one or more protocol header fields. Examples of such fields include length and serial numbers. For each inherited field that needs to be expanded, expansion is not necessarily achieved by directly expanding the field in a bitwise-adjacent manner. That is, an existing inherited field designated for expansion does not necessarily expand by itself. Instead, the inherited field is logically combined with other fields in the header structure.

In another non-limiting aspect, the method (s), block (s) and / or system (s) are provided to provide efficient data transfer (low overhead) for scenarios where the TBs are small (e.g., low speed services or poor coverage), and to control whether the transmitter uses regular (non-extended) or extended fields. In some aspects, the use of header field extensions is selected dynamically, for example, based on the current transport block size of the physical (L1) layer. In some other aspects, usage is semi-statistically configured by higher layers, such as RRC. The described aspects ensure that the receiver at any time knows the format of the fields used by the transmitter, that is, the receiver would know if the fields are expanded or not.

FIG. 4 illustrates an embodiment of a transmitter 400-T and a receiver 400-R in a wireless network. Each of the 400-T transmitter and 400-R receiver includes an RRC (Radio Resource Control) block 420, a PDCP block 430, an RLC block 440, a MAC block 450, and a PHY block 460, each of which is structured to perform the functions of the RRC, PDCP, RLC, MAC, and PHY protocol, respectively. Additional details about these blocks will be provided in conjunction with descriptions of one or more ways to provide backward compatible approaches to protocol layer fields.

Note that FIG. 4 is a logical representation of a 400-T transmitter and a 400-R receiver. Thus, each of the RRC block 420, PDCP block 430, RLC block 440, MAC block 450, and PHY block 460 should not be physically separate from each of the other blocks. It is fully assumed that any combination of blocks can be combined into one physical device. In addition, each of the blocks can be implemented in several physical components that are functionally structured and connected to each other to perform the corresponding function of the block. In addition, in the part in which some of the blocks share common features, several blocks can share common components.

Although not shown explicitly, it is also contemplated that one or both of the 400-T transmitter and the 400-R receiver as a whole can be implemented as a combination of hardware and software components. For example, the 400-T transmitter and / or 400-R receiver may include one or more processors, which, as described above, may themselves be combinations of hardware and software structured to perform the functions associated with the units.

It should also be noted that the wireless network node can function as a 400-T transmitter as well as a 400-R receiver. For example, FIG. 5 illustrates an embodiment of a mobile terminal 500 (eg, a UE) that includes a processor 510 structured to control the overall process of the mobile terminal 500, a memory 520 structured to store and retrieve data and instructions, and a transceiver 530 for processing signals received one or more antennas 540, and for processing signals that need to be transmitted from one or more antennas 540. The mobile terminal 500 functions as a 400-T transmitter on the uplink and as ve receiver 400-R on the downlink.

Although not shown, the mobile terminal 500 may include one or more of an RRC block 420, a PDCP block 430, an RLC block 440, a MAC block 450, and a PHY block 460 illustrated in FIG. 4. One or more of the blocks of FIG. 4 can also be implemented through a combination of hardware and software. For example, processor 510 may execute programming instructions stored on a time-invariant (non-temporary) computer-readable medium, such as memory device 520, to perform block functions. Programming instructions may also be received in a time-invariant manner and stored on a time-invariant machine-readable medium accessible by the mobile terminal 500. For example, updates can be saved and received.

As another example of FIG. 6 illustrates an embodiment of a network node 600, for example, a base station (eg, eNB) in a wireless network. Network node 600 includes a processor 610, structured to control the overall process of network node 600, a memory 620, structured to store and retrieve data and instructions, a transceiver 630 for processing signals received by one or more antennas 640, and for processing signals that you need to transmit from one or more antennas 640, and a network interface 650, structured for interaction with nodes of the core network. During the downlink, the network node 600 functions as a 400-T transmitter, and during the uplink, the network node 600 functions as a 400-R receiver.

Although not shown, the network node 600 may include one or more of an RRC block 420, a PDCP block 430, an RLC block 440, a MAC block 450, and a PHY block 460 illustrated in FIG. 4. One or more of the blocks of FIG. 4 can also be implemented through a combination of hardware and software. For example, the processor 610 may execute programming instructions stored on a time-invariant computer-readable medium, such as a memory device 620, to perform the functions of the blocks. Programming instructions may also be received in an intermediate manner and stored on a non-volatile machine-readable medium accessible by the network node 600. For example, updates can be saved and received.

Referring again to FIG. 4, the 400-T transmitter and / or 400-R receiver units can perform a method that provides backward compatibility with protocol layers. When one or more bits are needed for a header field, such as length fields or serial number fields, the traditional approach is to add bits to an existing field. But if there are no unused (reserved) bits on either side of the header field or if the header field in question is not the last header field in the header, then adjacent header fields need to be shifted in the direction of the unused bit or added bits. The disadvantage of this approach is that the header fields that have been octet aligned (see the LCID field in FIGS. 2A, 2B, 2C) require that the content be bit-shifted during encoding and decoding of the header. In addition, this approach is not necessarily backward compatible if the receiver does not support the new format.

To address this and other drawbacks of the traditional expansion approach, a new approach is proposed in one aspect of the present disclosure. In this new approach, the inherited field that needs to be expanded is logically combined with the extension part, which can be located in another part of the header. Part of the extension can be attached at the front as the most significant bit (s) or attached at the end as the least significant bit (s) to the inherited field, depending on the implementation, to form an extended field. This preserves the positions of all other fields and minimizes the need for bit shifting during encoding and decoding of the header. This approach is also backward compatible, as will be explained below.

For example, in the MAC subtitle in accordance with the LTE Rel-8/9 illustrated in FIG. 2A, 2B, and 2C, there are two reserved (R) bits. However, in an aspect of the present disclosure, one or both of them can be used to expand a header field, for example a length field (L). If the field L is expanded directly using the traditional approach, then it would be necessary to shift all the fields in front of the field L. Instead, the preferred approach is to logically attach one or both bits of R to the bits of the legacy field L in front or behind to form an extended length field (EL) while maintaining the position of all existing fields.

FIG. 7A and 7B illustrate examples of extended MAC subheadings in which the L field is extended by one bit. Both subheadings have R / EL / E / LCID / F / L structures. In these figures, one of the two reserved bits (R-bits) is used as an extended length (EL) field bit. When extended headers are used, the legacy L field of 7 or 15 bits can be extended with the EL bit. Thus, an 8-bit (when the format field F is not specified, see FIG. 7A) or a 16-bit length indicator (when the format field F is specified, see FIG. 7B) is obtained. FIG. 8 illustrates a MAC PDU, together with an example of an extended MAC header, which includes the extended MAC subtitle structures illustrated in FIG. 7A and 7B.

Of course, it is recognized that any size indicated by the extended 8-bit length field L in FIG. 7A may also be indicated by the inherited 15-bit length field L in the structure of the inherited MAC subheading illustrated in FIG. 2B. However, the advantage of the patentable subheading structure illustrated in FIG. 7A, in front of the inherited structure illustrated in FIG. 2B, the structure in FIG. 7A requires one octet less.

If the EL field is used as the most significant bit for the L field, then the header formats of the UE Rel-8/9 and UE Rel-10 are exactly the same when the length of the MAC SDU does not exceed the size that can be indicated by the legacy header format containing 15 bits. The reason is that the R-bit in UE Rel-8/9 is always set to 0.

FIG. 9A and 9B illustrate alternative examples of extended MAC subheadings with EL / R / E / LCID / F / L structures in which the L field is extended by one bit. In these figures, the EL bit is placed in the leftmost bit of the first octet. This is convenient because it does not require a bit shift when combining the EL bit with field L.

Although not illustrated, an embodiment of the extended MAC subtitle may include the extended MAC subtitles of FIG. 9A and 9B. Although also not illustrated, a format (F) field can be expanded using R bits. An F field can be expanded instead of or in addition to the L.

Changing header formats and extending the current length and serial number fields for all Rel-10 UEs is optional. Since expanding the length or serial number fields in L2 usually implies increased overhead, it is desirable to support both the legacy format for legacy data rates and the extended format for new very high speeds. Legacy format support is also required for UEs on legacy Rel-8/9 networks.

FIG. 10 illustrates an example method 1000 for controlling a network node 600, such as a base station in a wireless network, to provide backward compatibility at protocol layers. At 1010, the network node 600 determines whether to use the extended header for the protocol layer when wirelessly communicating with the mobile terminal 500. Any protocol layer above L1 may make such a decision. More specifically, any of the RRC block 420, PDCP block 430, RLC block 440, and MAC block 450 of network node 600 may decide whether to use the extended header. For example, MAC block 450 may decide to use the extended MAC header, which is illustrated in FIG. 8.

For ease of reference, the phrase “protocol level block” will be used to refer generally to any block corresponding to protocol levels above level L1. Thus, at 1010, it can be said that the protocol layer block determines whether to use the extended header. As mentioned, any of the protocol layer units 420, 430, 440, 450, as well as the PHY unit 460 illustrated in FIG. 4 may be a combination of a processor 610 executing instructions stored in memory 620 of network node 600. When it is determined that an extended header will be used, the protocol layer unit in step 1020 uses the extended header for the protocol layer that will be used in transmitting and receiving protocol protocol layer data units to and from mobile terminal 500. When it is not determined that the extended header will be used, the protocol layer block in step 1030 uses the legacy header.

As an example illustration of the use of the extended header in step 1010, the MAC unit 450 may determine that the extended MAC header will be used to expand the L field of length of one of the MAC SDUs. Then, at 1020, the MAC unit 450 may use the extended length field EL corresponding to the SDU in the extended MAC header. As another exemplary illustration, at 1010, the RLC 440 may determine that the sequence number SN field should be expanded using the extended RLC header. Then, at 1020, the RLC unit 440 may use the E-SN (Extended Sequence Number) field in the extended RLC header.

Note that when an extended field is “used”, this does not necessarily imply that the extended field is set to a fixed value. The value of the bit or bit of the extended field will depend on the specific circumstances. When an extended field is used, it must be indicated that the field is not ignored when the extended header is written, and also not ignored when the extended header is read.

In one aspect, the extended header includes an inherited indicator field (L-I) with a predetermined number of indicator bits to use when specifying a PDU characteristic value. There is also an inherited threshold indicator value associated with the characteristic. The inherited threshold value of the indicator can be described by the maximum value of the characteristic, which can be indicated by the inherited field L-I of the indicator.

The extended header also contains the extended indicator field (E-I), which can logically be combined with the inherited indicator field L-I. The logical combination E-I / L-I includes a sufficient number of bits to set the value of the characteristic beyond the inherited threshold value of the indicator. Since the E-I / L-I combination is logically combined, the bits of the E-I field and the bits of the L-I field should not be bit-wise adjacent to each other. They may also occupy different octets of the extended header.

As an illustration, the L field in the MAC SDU subtitle is used. As illustrated in FIG. 2A and 2B and described above, the L field - which is an example of an inherited indicator field L-I - indicates the size of one of the MAC SDUs included in the MAC PDU. Since the inherited field L is either 7 or 15 bits long, there is some maximum SDU size beyond which the size cannot be specified using the inherited field L. In this case, the inherited threshold value with the inherited field L can be the inherited transport block size, i.e. the maximum TB size that may be indicated by the legacy field L.

But as illustrated in FIG. 7A, 7B, 9A, and 9B and also described above, the EL field — which is an example of the EI field — can logically be combined with the field L. The EL-L combination may indicate the size of the MAC SDU beyond the threshold that was possible with one legacy field L Note that the fields EL and L are bitwise non-adjacent. They also occupy different octets.

The following should also be noted. In FIG. 7A, 7B, 9A, and 9B, the bit position of the EL field in the extended MAC header corresponds to one of the bit positions of the reserved bits R of the inherited MAC header. Thus, from the point of view of legacy equipment such as UE Rel 8/9, the structure of the extended MAC header corresponds to the structure of the inherited MAC header. This enables backward compatibility, which is a significant advantage.

In general, it can be said that the extended E-I field of the indicator contains one or more bits, and the bit positions of the E-I field of the extended header correspond to the positions of the reserved bits of the inherited protocol level header. Thus, when the legacy equipment considers the extended header from the point of view of the legacy equipment, the structure of the extended header corresponds to the structure of the inherited header.

In one aspect of the proposed method, format selection is performed dynamically, where extended headers are used only when they are needed. For example, at the MAC level, dynamic selection of the L field size may be performed based on the size of the transport block or the size of the MAC SDU. This is possible because the L field depends only on the current TB size, and the transmitting and receiving entities — for example, the network node 600 and the mobile terminal 500 — know the TB sizes.

FIG. 11 illustrates an example process for implementing step 1010 to determine whether to use an extended header so that a format can be selected dynamically — that is, selected if necessary. As can be seen at step 1110, at the protocol level, for example, the MAC level, it is determined whether the transport block size exceeds the inherited threshold transport block size at the L1 (physical) level. Recall that the protocol layer is hierarchically located above the L1 level. MAC block 450 may perform this determination. Although the MAC block 450 is most likely, any of the RRC block 420, PDCP block 430, and RLC block 440 can also make this determination. For convenience, it is assumed that the protocol layer for the steps illustrated in FIG. 11 is a MAC layer.

Referring again to FIG. 10, method 1000 proceeds to use the extended header in step 1020 when it is determined that the extended header will be used (branch YES in FIG. 11). Thus, when the extended header is an extended MAC header, the step of using the extended MAC header 1020 can be described as using the extended EL field of the extended MAC header length, so that the EL / L logical combining includes enough bits to set the TB size more than the legacy threshold size TB. The EL field will be used. Whether each bit of the EL field is set to zero or one will depend on the size of the MAC SDU, but the field is not ignored. The logical combination may be such that the bits (bits) of the EL field are combined to become the most significant bit (bits) of the logical combination EL / L. Of course, EL bits (s) can also be combined to become the least significant bit (s).

Note that when the size TB indicated by the physical layer exceeds the size that may be indicated by the inherited field L, the length field may be extended by one or two reserved bits. Actual expansion can be performed using either the currently unused, i.e. reserved bit, or bits of the legacy header. As mentioned above, when the extension is performed using reserved bits, the extended header corresponds to the structure of the legacy header in terms of legacy equipment.

Extension can also be done using bits or bits in an optional octet, following the format of the inherited header. In this case, the size of the header depends on the size of the transport block (MAC PDU) indicated by the lower layer. Note that when additional octets are located at the end, the extended header still matches the structure of the inherited header up to the point where the additional octets begin.

One advantage (of which there may be several) of dynamically expandable header fields is that for lower category UEs that do not support the highest bit rates, for example UE Rel-8/9, the largest TB sizes are not provided. Therefore, there is no interoperability problem, because in practice UEs of the lower category should not implement extended headers. In addition, dynamically expanding header fields minimize header overhead for UEs that do not support very high data rates but operate under radio or load conditions that prevent the use of large transport blocks.

The use of extended headers can also be semi-statistically configured through upper layer signaling. RRC signaling is one non-limiting example of upper layer signaling. One or more top-level configurations may exist to indicate that many fields are expanding, including, for example, the L MAC field, SO RLC fields, SOstart and SOend fields, LI RLC and SN RLC fields, and finally the PDCP SN field.

In one embodiment, the network node 600 configures the mobile terminal 500 to use an extended header for protocol layers or layers. That is, for the mobile terminal 500, the use of advanced formats can be configured using upper layers. This may be true for both the uplink and the downlink. For example, a network node 600 (e.g., an eNB) can configure the use of extended headers in a mobile terminal 500 (e.g., a UE) by sending a configuration message in the form of RRC commands to the mobile terminal 500. The RRC layer in the mobile terminal 500 may configure the use of extended headers. An RRC message is one type of configuration message. Others include MAC controls, special PDNCH RNTIs, special allocation formats, and so on.

Network node 600 may semi-statically determine whether to use extended headers and configure the extended headers accordingly. FIG. 12 illustrates an example process performed on a network node 600 to implement step 1010 to semi-statically determine whether to use extended headers.

As can be seen, at 1210, it is determined whether the transmission using the extended header will lead to a sufficiently higher throughput than the transmission without using the extended header. For example, it can be determined whether transmission with field extension at the protocol level will result in a sufficiently large throughput than transmission without field extension. For convenience, this is called the first condition. For simple voice communications, there may be a slight difference or no difference in throughput, so the first condition may not be met. For large bandwidth applications, such as video streaming, the first condition can be met, that is, field extensions, if used, could lead to significantly greater bandwidth.

At step 1220, it is determined whether sufficient transmission resources are available for transmission using the extended header, for example, field extension transmission. This is called the second condition. Transmission resources may include the number of available carriers, the number of available resource blocks per UE on a carrier, whether the MIMO configuration (multiple inputs and multiple outputs) can be used, and so on. If the network node 600 currently serves many mobile terminals 500, then it may not have sufficient bandwidth available to provide, for example, the requested video streaming service.

At step 1230, a third condition is checked whether the transmission using the extended header, for example, the field extension transmission, will satisfy the minimum quality of service (QoS) associated with the transmission. By way of illustration, video streaming requires relatively high bandwidth, meaning that less reliable MCS (modulation and coding scheme) can be used. But with a less reliable MCS, the likelihood of errors also increases, for example, BER (error bit rate). When there is significant interference (for example, when the UE is at the cell boundary), the BER may be too high for video streaming — that is, the minimum QoS requirement may not be met for video streaming for the UE at the cell boundary. When the third condition is not fulfilled, that is, when it is unlikely to meet the minimum QoS requirement, it is determined that the use of the extended header for that protocol level will not be used.

In FIG. 12, when any one or more of the first, second, and third conditions is satisfied, it is determined that the extended header should be used for the protocol layer. The network node 600, having determined semi-statically that extended headers will be used for one or more protocol layers, configures the mobile terminal 500 in step 1240. The configuration can be performed by sending a configuration message in the form of an RRC message, MAC, RNTI controls on a PDCCH, and so on.

It should be noted that the first, second and third conditions are just some examples of conditions that can be checked to determine whether to use the extended header. No matter what conditions are checked, when it is decided to use extended headers, the network node 600 can configure the mobile terminal 500 in the configuration message.

A non-exhaustive list of fields that may be indicated for extension includes a MAC L field; SO RLC (segmentation offset), SOstart and SOend fields, LI RLC fields (length indicator) and RLC SN (serial number); and PDCP and FMS SN fields (first missing PDCP SN). Thus, in the extended headers corresponding to the data units (control / user SDU / PDU) of the protocol layers, any one or more of the following fields can be used by the corresponding protocol layer units 420, 430, 440, 450 in one implementation of block 1020 to configure the extended protocol level headers:

In the extended PDCP header of the PDCP data block:

Extended Sequence Number Field (ESN PDCP), which should be logically combined with the inherited Sequence Number Field (SN PDCP);

the extended field of the first missing PDCP SN (EFMS), which must be logically combined with the inherited field of the first missing SN PDCP (FMS);

In the extended RLC header of the RLC data block:

Advanced Segment Offset Field (ESO RLC), which should be logically combined with a legacy Segment Offset Field (SO RLC);

An extended segment offset start field (ESOstart RLC), which should be logically combined with a legacy segment offset start field (SOstart RLC);

An extended segment offset end field (ESOend RLC) that needs to be logically combined with a legacy segment offset end field (SOend RLC);

Extended Length Indicator Field (ELI RLC), which should be logically combined with the inherited Length Indicator Field (LI RLC);

Extended Sequence Number Field (ESN RLC), which must be logically combined with the inherited Sequence Number Field (SN RLC);

In the extended MAC header of the MAC data block:

Extended Length Field (EL MAC), which should be logically combined with the inherited Length Field (L MAC); and

An extended format field (EF MAC) that needs to be logically combined with a legacy format field (F MAC).

The configuration can exist for unidirectional data radio channels (DRB), for a specific RLC mode (with / without acknowledgment) or in the direction of DL (downlink) or UL (uplink). In some scenarios, it may be that TBs are larger in DL (or UL) than in UL (or DL), and an extended header field may be needed in one direction, but not in the other. For example, LTE Rel-10 in DL supports larger TBs than in UL.

In a handover situation, the target cell may need to know the header format currently used for communication between the terminal and the network. Thus, the use of semi-statistically configured extended header formats is preferably communicated between the source and target network nodes, for example eNB.

FIG. 13 illustrates an example process for providing header format information in a handover. Steps 1310, 1320 and 1330 are performed on the source cell, and steps 1340, 1350 and 1360 are performed on the target cell. Both cells may be network nodes. In other words, the network node 600 may be a source cell in one case and a target cell in another. At step 1310, the source cell determines whether a handover of the mobile terminal 500, such as a UE, to the target cell will occur. If so, then at step 1320, the source cell notifies the target cell of the header format used between the source cell and the mobile terminal, and the target cell at step 1340 receives this notification. This communication can be performed on the X2 interface between them.

Preferably, the mobile terminal 500 is informed about whether to use the extended header fields after handover to the target cell. Thus, in block 1350, the target cell determines whether to use the extended header format. The target cell may inform the source cell of this decision — yes or no — and the source cell, in turn, can notify the mobile terminal in step 1330. Alternatively, the target cell can directly notify the mobile terminal 500 of the decision in step 1360.

FIG. 14 illustrates an example methodology 1400 for controlling a mobile terminal 500, for example, user equipment, to provide backward compatibility at protocol layers. The illustrated steps are similar to the steps of method 1000 for managing a network node. This should come as little surprise since the mobile terminal 500 and the network node 600 must use the same header configurations when communicating with each other.

At step 1410, the mobile terminal 500 determines whether to use the extended header for the protocol layer for wireless communication with the network node 600. As with the network node 600, any protocol layer above the L1 level can make such a decision. As mentioned, any of the protocol layer units 420, 430, 440, 450, as well as the PHY unit 460 illustrated in FIG. 4 may be a combination of a processor 610 executing instructions stored in memory 620 of network node 600.

When it is determined that the extended header will be used, the protocol terminal unit of the mobile terminal in step 1420 uses the extended header for the protocol layer that will be used when transmitting and receiving protocol level protocol data units to and from the network node 600. An example is a MAC unit 450 determining that an extended MAC header will be used to extend the L field of length of one of the MAC SDUs, as described above. Again, the term “used” is used to indicate that the field is not ignored. The composition of the extended subtitles for the mobile terminal 500 is the same or similar to the composition of the extenders of the network node 600. Accordingly, a detailed description will be omitted here.

As indicated above, the use of the extended header can be determined dynamically - that is, used if necessary. At the MAC level, the dynamic selection of the size of the L field can be made based on the size of the transport block or the size of the MAC SDU, since the network node 600 and the mobile terminal 500 know the sizes of TB. Thus, FIG. 11 also represents an example process for implementing step 1410 to determine whether to use the extended header so that the format can be selected dynamically.

As also indicated above, the extended header can be used semi-statically, for example, by signaling the upper level. In one of the above embodiments, the network node 600 determines the use of extended headers in the mobile terminal 500 and configures the use of extended headers in the mobile terminal 500 in the configuration message, for example, see step 1240 of FIG. 12. The configuration message may be in the form of RRC messages, MAC control element, special PDNCH RNTI, special allocation format, and so on.

FIG. 15 illustrates an example process for implementing step 1410 to determine whether to use the extended protocol layer header. The mobile terminal 500 receives a configuration message (eg, an RRC message) from the network node 600 in step 1510. In step 1520, the protocol layer unit 420, 430, 440, 450 determines whether the configuration message indicates that an extended header for one or more layers will be used. protocol.

When the configuration message includes the configuration of the extended header, that is, the use of the extended header or headers is indicated, then the step 1420 for configuring the extended header may be performed by protocol layer units in accordance with the received configuration message. That is, in the extended headers corresponding to the data units (control / user SDU / PDU) of the protocol layers, any one or more of the following fields can be used by the corresponding protocol layer units 420, 430, 440, 450 when implementing step 1420 based on the received configuration message. The fields that can be expanded for each of the protocol layers are the same or similar to the network node 600, and accordingly will not be repeated.

Typically, the network and terminal should have a very good understanding of when exactly the extended header formats are used. In one or more embodiments, two communication entities (eg, UE and eNB) synchronously apply reconfiguration of header formats. This can be achieved using a synchronized procedure (for example, handoff based on random access in LTE). Alternatively, reconfiguration may be associated with activation time. The activation time can be an exact time reference or relative to the moment when a configuration command is received.

The disclosed subject matter has many advantages. Some (not necessarily exhaustive) benefits include the following. In some of the proposed aspects, the fields in the headers of the protocol layers are expanded, which can be useful when transport block sizes exceeding the inherited length fields are provided by the physical layer.

Although the above description contains many specifics, it should not be construed as limiting the scope of the disclosed subject matter of the invention, but solely as providing illustrations of some of the currently preferred embodiments. Therefore, it will be necessary to take into account that the scope of the disclosed subject matter fully includes other embodiments, and the scope should not be accordingly limited. All structural and functional equivalents of the elements of the above preferred embodiment that are known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by it. In addition, the device or method does not need to solve all the problems without exception that are described in this document or which are trying to solve using the present technology so that the device or method is covered by it.

Claims (36)

1. A method performed on a network node of a wireless network, the method comprising the steps of:
determining whether to use the extended header for the protocol layer when wirelessly communicating with the mobile terminal, the protocol layer being a layer above the physical (L1) layer; and
using the extended header for the protocol level when transmitting and / or receiving the protocol level data unit (PDU) of the protocol level when it is determined that the extended header is to be used,
use the inherited header for the protocol level when transmitting and / or receiving the protocol level data unit (PDU) of the protocol level when it is not determined that the extended header should be used,
wherein the extended header contains an inherited indicator field (LI) with a predetermined number of indicator bits for use when specifying a PDU characteristic value,
however, there is an inherited threshold value of the indicator associated with the mentioned characteristic, moreover, the inherited threshold value of the indicator is the maximum value of the characteristic that can be indicated by the inherited field LI of the indicator, and
wherein the extended header contains an extended indicator field (EI), logically combined with the inherited indicator field LI, so that the EI / LI combination contains enough bits to set the PDU characteristic value outside the inherited indicator threshold,
wherein the size of the extended header for the protocol level is not greater than the size of the inherited header for the same protocol level, and
wherein the step of determining whether to use the extended header for the protocol layer comprises a step in which it is determined that the extended header for the protocol layer is to be used when the size of the transport block (TV) of the L1 layer is larger than the inherited threshold size of the TV. 2. The method according to p. 1,
wherein the protocol layer is a medium access control (MAC) layer, and the extended header is an extended MAC header,
wherein the inherited indicator field LI is the inherited MAC extended header length field L for indicating the size of the corresponding MAC service data unit (SDU), wherein the inherited threshold TV size is the maximum size of the TV that may be indicated by the inherited length field L, and
wherein the step of using the protocol level PDUs comprises the step of using the extended length field EL of the extended header MAC, so that the logical combination EL / L of the extended length field EL and the legacy length field L contains enough bits to set the TV size to be larger than the inherited threshold TV size. 3. The method of claim 1, wherein the step of determining whether to use the extended header for the protocol layer comprises the step of sending a configuration message to the mobile terminal to use the extended header for the protocol layer. 4. The method according to p. 3, in which the configuration is based on a combination of any one or more of:
counting on unidirectional data radio channels (DRB),
Based on a specific RLC mode (with / without confirmation) and
calculated on the direction of DL (downlink) or UL (uplink). 5. The method of claim 3, wherein determining whether to use the extended header for the protocol layer further comprises any one or more of the steps in which:
determining the first condition whether the transmission using the extended header will lead to greater throughput than the transmission without using the extended header;
determining a second condition whether sufficient transmission resources are available for transmission using the extended header; and
determining a third condition whether the transmission using the extended header will fulfill the minimum quality of service (QoS) requirement associated with the transmission,
wherein the step of sending the configuration message to the mobile terminal to use the extended header for the protocol layer is performed when any one or more of the first, second, and third conditions is satisfied. 6. The method of claim 3, wherein the step of using a protocol level PDU comprises any one or more of the steps of:
use the extended sequence number field (ESN PDCP), which must be logically combined with the inherited sequence number field (SN PDCP) in the extended PDCP header of the PDCP data block;
using the extended first PDCP SN missing field (EFMS) field, which should be logically combined with the inherited first missing PDCP SN field (FMS) in the extended PDCP header of the PDCP data block;
using the extended segment offset field (ESO RLC), which must be logically combined with the inherited segment offset field (SO RLC) in the extended RLC header of the RLC data block;
using the extended segment offset field (ESO RLC), which must be logically combined with the inherited segment offset field (SO RLC) in the extended RLC header of the RLC data block;
use the extended segment offset start field (ESOstart RLC), which should be logically combined with the inherited segment offset start field (SOstart RLC) in the extended RLC header of the RLC data block;
using the extended segment offset end field (ESOend RLC), which should be logically combined with the inherited segment offset end field (SOend RLC) in the extended RLC header of the RLC data block;
use the extended length indicator field (ELI RLC), which should be logically combined with the inherited length indicator field (LI RLC) in the extended RLC header of the RLC data block;
use the extended sequence number field (ESN RLC), which must be logically combined with the inherited sequence number field (SN RLC) in the extended RLC header of the RLC data block;
using the extended length field (EL MAC), which must be logically combined with the inherited length field (L MAC) in the extended MAC header of the MAC data block; and
use the extended format field (EF MAC), which must be logically combined with the inherited format field (F MAC) in the extended MAC header of the MAC data block. 7. The method according to p. 1,
in which the extended field EI indicator of the extended header contains one or more bits, and
in which the bit position (bit positions) of the extended indicator EI field corresponds to the bit position (bits) of the reserved bit (s) of the inherited protocol level header, so that from the point of view of the legacy equipment, the structure of the extended header corresponds to the structure of the inherited header. 8. The method according to p. 1,
in which the extended field EI indicator of the extended header contains one or more bits, and
in which the bit position (bit positions) of the extended indicator EI field is not adjacent to any of the bit position (bit positions) of the inherited extended header indicator LI field. 9. The method of claim 1, further comprising informing the target cell of the handover of the extended header used to communicate with the mobile terminal. 10. The method according to p. 1, further comprising stages in which:
receiving an indication from the source cell about handover of the extended header used to communicate with the mobile terminal;
determining whether the extended header will be used after handover; and
notify the mobile terminal of the decision whether the extended header will be used after handover. 11. A method performed on a mobile terminal of a wireless network, the method comprising the steps of:
determining whether to use the extended header for the protocol layer when wirelessly communicating with a network node, the protocol layer being a layer above the physical (L1) layer;
using the extended header for the protocol level when transmitting and / or receiving the protocol level data unit (PDU) of the protocol level when it is determined that the extended header is to be used,
use the inherited header for the protocol level when transmitting and / or receiving the protocol level data unit (PDU) of the protocol level when it is not determined that the extended header should be used,
wherein the extended header contains an inherited indicator field (LI) with a predetermined number of indicator bits for use when specifying a PDU characteristic value,
however, there is an inherited threshold value of the indicator associated with the mentioned characteristic, and the inherited threshold value of the indicator is the maximum value of the mentioned characteristics, which can be indicated by the inherited field LI of the indicator, and
wherein the extended header contains an extended indicator field (EI), logically combined with the inherited indicator field LI, so that the EI / LI combination contains enough bits to set the value of said PDU characteristic outside the inherited indicator threshold value,
wherein the size of the extended header for the protocol level is not greater than the size of the inherited header for the same protocol level, and
wherein the step of determining whether to use the extended header for the protocol layer comprises a step in which it is determined that the extended header for the protocol layer is to be used when the size of the transport block (TV) of the L1 layer is larger than the inherited threshold size of the TV. 12. The method according to p. 11,
wherein the protocol layer is a medium access control (MAC) layer, and the extended header is an extended MAC header,
wherein the inherited indicator field LI is the inherited MAC extended header length field L for indicating the size of the corresponding MAC service data unit (SDU), wherein the inherited threshold TV size is the maximum size of the TV that may be indicated by the inherited length field L, and
in which the step of configuring the protocol level PDUs comprises the step of using the extended length field EL of the extended MAC header so that the logical combination EL / L of the extended length field EL and the legacy length field L contains a sufficient number of bits to set the TV size to be larger than the inherited threshold TV size. 13. The method according to p. 11,
wherein the step of determining whether to use the extended header for the protocol layer comprises the steps of:
receive a configuration message from the network node; and
determining that the received configuration message indicates that an extended header for the protocol layer will be used, and
wherein the step of using the protocol level PDU based on the received configuration message comprises any one or more of the steps in which:
use the extended sequence number field (ESN PDCP), which must be logically combined with the inherited sequence number field (SN PDCP) in the extended PDCP header of the PDCP data block;
using the extended first PDCP SN missing field (EFMS) field, which should be logically combined with the inherited first missing PDCP SN field (FMS) in the extended PDCP header of the PDCP data block;
using the extended segment offset field (ESO RLC), which must be logically combined with the inherited segment offset field (SO RLC) in the extended RLC header of the RLC data block;
using an extended segment offset field (ESO RLC), which must be logically combined with a legacy segment offset field (SO RLC) in said extended RLC header of an RLC data block;
use the extended segment offset start field (ESOstart RLC), which should be logically combined with the inherited segment offset start field (SOstart RLC) in the extended RLC header of the RLC data block;
using the extended segment offset end field (ESOend RLC), which should be logically combined with the inherited segment offset end field (SOend RLC) in the extended RLC header of the RLC data block;
use the extended length indicator field (ELI RLC), which should be logically combined with the inherited length indicator field (LI RLC) in the extended RLC header of the RLC data block;
use the extended sequence number field (ESN RLC), which must be logically combined with the inherited sequence number field (SN RLC) in the extended RLC header of the RLC data block;
using the extended length field (EL MAC), which must be logically combined with the inherited length field (L MAC) in the extended MAC header of the MAC data block; and
use the extended format field (EF MAC), which must be logically combined with the inherited format field (F MAC) in the extended MAC header of the MAC data block. 14. The method of claim 13, wherein the configuration is based on a combination of any one or more of:
counting on unidirectional data radio channels (DRB),
Based on a specific RLC mode (with / without confirmation) and
calculated on the direction of DL (downlink) or UL (uplink). 15. The method according to p. 11,
in which the extended field EI indicator of the extended header contains one or more bits, and
in which the position (s) of the bit (s) of the extended indicator EI field corresponds to the position (s) of the bit of the reserved bit (s) of the inherited protocol level header, so that from the point of view of the legacy equipment, the structure of the extended header corresponds to the structure of the inherited header. 16. The method according to p. 11,
in which the extended field EI indicator of the extended header contains one or more bits, and
in which the bit position (bit positions) of the extended indicator EI field is not adjacent to any of the bit position (bit positions) of the inherited extended header indicator LI field. 17. The method of claim 13, wherein the configuration message received from the network node is a radio resource control (RRC) message. 18. A network node in a wireless network comprising a plurality of protocol layer units structured for communication with a mobile terminal, wherein the plurality of protocol layer units comprises:
a radio resource control unit (RRC) structured to perform functions associated with the RRC layer;
a packet data convergence protocol (PDCP) unit, structured to perform functions associated with the PDCP layer;
a radio control unit (RLC) structured to perform functions associated with the RLC layer; and
a medium access control (MAC) unit structured to perform functions associated with the MAC layer,
wherein at least one protocol layer unit is structured to:
determining whether to use the extended header for the protocol layer when wirelessly communicating with the mobile terminal, the protocol layer being a layer above the physical (L1) layer, and
using the extended header for the protocol level when transmitting and / or receiving the protocol level data unit (PDU) of the protocol level when it is determined that the extended header is to be used,
using the inherited header for the protocol level when transmitting and / or receiving a protocol data unit (PDU) of the protocol level when it is not determined that an extended header is to be used,
wherein the extended header contains an inherited indicator field (LI) with a predetermined number of indicator bits for use when specifying a PDU characteristic value,
however, there is an inherited threshold value of the indicator associated with the mentioned characteristic, and the inherited threshold value of the indicator is the maximum value of the mentioned characteristics, which can be indicated by the inherited field LI of the indicator, and
wherein the extended header contains an extended indicator field (EI), logically combined with the inherited indicator field LI, so that the EI / LI combination contains enough bits to set the PDU characteristic value outside the inherited indicator threshold,
wherein the size of the extended header for the protocol level is not greater than the size of the inherited header for the same protocol level, and
wherein at least one protocol level block is structured to determine that the extended header for the protocol level needs to be used when the transport block (TB) size of L1 is larger than the inherited threshold TV size. 19. The network node according to claim 18,
wherein the protocol layer is a medium access control (MAC) layer, and the extended header is an extended MAC header, and at least one protocol layer block is a MAC block;
wherein the inherited indicator field LI is the inherited MAC extended header length field L for indicating the size of the corresponding MAC service data unit (SDU), wherein the inherited threshold TV size is the maximum size of the TV that may be indicated by the inherited length field L, and
in which the MAC block is structured to use the extended field EL of the length of the extended header MAC, so that the logical combination EL / L of the extended field EL of the length and the legacy field L of the length contains enough bits to set the TV size larger than the inherited threshold TV size. 20. The network node of claim 18, wherein the at least one protocol layer unit is structured to send a mobile terminal configuration message to use an extended header for the protocol layer. 21. The network node according to claim 18,
wherein at least one protocol layer unit is structured to define any one or more of:
the first condition is whether using the extended header will lead to more bandwidth than transferring without using the extended header,
the second condition is whether sufficient transmission resources are available for transmission using the extended header, and
the third condition, whether the transmission using the extended header will fulfill the minimum quality of service (QoS) requirement associated with the transmission, and
wherein at least one protocol layer unit is structured to send a mobile terminal configuration message to use the extended header for the protocol layer when it determines that any one or more of the first, second, and third conditions is satisfied. 22. The network node according to claim 18,
in which the PDCP block is structured to use any one or more of:
an extended serial number field (PDCP ESN), which should be logically combined with a legacy serial number field (SN PDCP) in the extended PDCP header of the PDCP data block, and
the extended field of the first missing PDCP SN (EFMS), which must be logically combined with the inherited field of the first missing SN PDCP (FMS) in the extended PDCP header of the PDCP data block,
wherein the RLC block is structured to use any one or more of:
the extended segment offset field (ESO RLC), which must be logically combined with the inherited segment offset field (SO RLC) in the extended RLC header of the RLC data block,
the extended segment offset field (ESO RLC), which must be logically combined with the inherited segment offset field (SO RLC) in the extended RLC header of the RLC data block,
an extended segment offset start field (ESOstart RLC), which should be logically combined with a legacy segment offset start field (SOstart RLC) in the extended RLC header of the RLC data block,
the extended segment offset end field (ESOend RLC), which should be logically combined with the inherited segment offset end field (SOend RLC) in the extended RLC header of the RLC data block,
an extended length indicator field (ELI RLC) to be logically combined with a legacy length indicator field (LI RLC) in the extended RLC header of the RLC data unit, and
an extended serial number field (RLC ESN) that needs to be logically combined with a legacy serial number field (RLC SN) in the extended RLC header of the RLC data block, and
in which the MAC block is structured to use any one or more of:
an extended length field (EL MAC) to be logically combined with a legacy length field (L MAC) in the extended MAC header of the MAC data block, and
an extended format field (EF MAC) that needs to be logically combined with a legacy format field (F MAC) in the extended MAC header of the MAC data block. 23. The network node according to claim 18,
in which the extended field EI indicator of the extended header contains one or more bits, and
in which the bit position (bit positions) of the extended indicator EI field corresponds to the bit position (bits) of the reserved bit (s) of the inherited protocol level header, so that from the point of view of the legacy equipment, the structure of the extended header corresponds to the structure of the inherited header. 24. The network node according to claim 18,
in which the extended field EI indicator of the extended header contains one or more bits, and
in which the bit position (bit positions) of the extended indicator EI field is not adjacent to any of the bit position (bit positions) of the inherited extended header indicator LI field. 25. The network node of claim 18, wherein the network node is structured to notify the target cell of the handover of the extended header used to communicate with the mobile terminal. 26. The network node of claim 18, wherein the network node is structured to:
receiving instructions from the source cell about the handover of the extended header used to communicate with the mobile terminal;
determining whether the extended header will be used after handover; and
notifying the mobile terminal of the decision whether the extended header will be used after the handover. 27. The network node of claim 18, wherein the configuration is based on a combination of any one or more of:
counting on unidirectional data radio channels (DRB),
Based on a specific RLC mode (with / without confirmation) and
calculated on the direction of DL (downlink) or UL (uplink). 28. A mobile terminal in a wireless network comprising a plurality of protocol layer units structured for communication with a mobile terminal, wherein the plurality of protocol layer units comprises:
a radio resource control unit (RRC) structured to perform functions associated with the RRC layer;
a packet data convergence protocol (PDCP) unit, structured to perform functions associated with the PDCP layer;
a radio control unit (RLC) structured to perform functions associated with the RLC layer; and
a medium access control (MAC) unit structured to perform functions associated with the MAC layer,
wherein at least one protocol layer unit is structured to:
determining whether to use the extended header for the protocol layer when wirelessly communicating with the mobile terminal, the protocol layer being a layer above the physical (L1) layer, and
using the extended header for the protocol level when transmitting and / or receiving the protocol level data unit (PDU) of the protocol level when it is determined that the extended header is to be used,
using the inherited header for the protocol level when transmitting and / or receiving a protocol data unit (PDU) of the protocol level when it is not determined that an extended header is to be used,
wherein the extended header contains an inherited indicator field (LI) with a predetermined number of indicator bits for use when specifying a PDU characteristic value,
in which there is an inherited threshold value of the indicator associated with the characteristic, wherein the inherited threshold value of the indicator is the maximum value of the characteristic that can be indicated by the inherited field LI of the indicator, and
in which the extended header contains an extended indicator field (EI), logically combined with the inherited indicator field LI, so that the EI / LI combination contains enough bits to set the PDU characteristic value outside the inherited indicator threshold,
wherein the size of the extended header for the protocol level is not greater than the size of the inherited header for the same protocol level, and
wherein at least one protocol level block is structured to determine that the extended header for the protocol level needs to be used when the transport block (TB) size of L1 is larger than the inherited threshold TV size. 29. The mobile terminal according to p. 28,
wherein the protocol layer is a medium access control (MAC) layer, and the extended header is an extended MAC header, and at least one protocol layer block is a MAC block;
wherein the inherited indicator field LI is the inherited MAC extended header length field L for indicating the size of the corresponding MAC service data unit (SDU), wherein the inherited threshold TV size is the maximum size of the TV that may be indicated by the inherited length field L, and
in which the MAC block is structured to use the extended field EL of the length of the extended header MAC, so that the logical combination EL / L of the extended field EL of the length and the legacy field L of the length contains enough bits to set the TV size larger than the inherited threshold TV size. 30. The mobile terminal according to p. 28,
wherein the mobile terminal is structured to receive a configuration message from a network node indicating that an extended header for the protocol layer will be used,
wherein the PDCP unit is structured for use based on the received configuration message of any one or more of:
an extended serial number field (PDCP ESN), which should be logically combined with a legacy serial number field (SN PDCP) in the extended PDCP header of the PDCP data block, and
the extended field of the first missing PDCP SN (EFMS), which must be logically combined with the inherited field of the first missing SN PDCP (FMS) in the extended PDCP header of the PDCP data block,
wherein the RLC unit is structured for use on the basis of the received configuration message of any one or more of:
the extended segment offset field (ESO RLC), which must be logically combined with the inherited segment offset field (SO RLC) in the extended RLC header of the RLC data block,
an extended segment offset field (ESO RLC), which needs to be logically combined with a legacy segment offset field (SO RLC) in said extended RLC header of an RLC data block,
an extended segment offset start field (ESOstart RLC), which should be logically combined with a legacy segment offset start field (SOstart RLC) in the extended RLC header of the RLC data block,
the extended segment offset end field (ESOend RLC), which should be logically combined with the inherited segment offset end field (SOend RLC) in the extended RLC header of the RLC data block,
an extended length indicator field (ELI RLC) to be logically combined with a legacy length indicator field (LI RLC) in the extended RLC header of the RLC data unit, and
an extended serial number field (RLC ESN) that needs to be logically combined with a legacy serial number field (RLC SN) in the extended RLC header of the RLC data block, and
wherein the MAC block is structured for use based on the received configuration message of any one or more of:
an extended length field (EL MAC) to be logically combined with a legacy length field (L MAC) in the extended MAC header of the MAC data block, and
an extended format field (EF MAC) that needs to be logically combined with a legacy format field (F MAC) in the extended MAC header of the MAC data block. 31. The mobile terminal according to p. 28,
in which the extended field EI indicator in the extended header contains one or more bits, and
in which the bit position (bit positions) of the extended indicator EI field corresponds to the bit position (bits) of the reserved bit (s) of the inherited protocol level header, so that from the point of view of the legacy equipment, the structure of the extended header corresponds to the structure of the inherited header. 32. The mobile terminal according to p. 28,
in which the extended field EI indicator of the extended header contains one or more bits, and
in which the bit position (bit positions) of the extended indicator EI field is not adjacent to any of the position (positions) of the bit of the inherited extended header indicator LI field. 33. The mobile terminal of claim 30, wherein the configuration message received from the network node is a Radio Resource Control (RRC) message. 34. The mobile terminal according to claim 30, wherein the configuration is based on a combination of any one or more of:
counting on unidirectional data radio channels (DRB),
Based on a specific RLC mode (with / without confirmation) and
calculated on the direction of DL (downlink) or UL (uplink). 35. A non-transitory computer-readable medium storing programming instructions executed by a computing unit of a network node of a wireless network, such that the computing unit performs the method of claim 1. 36. A non-transitory computer-readable medium storing programming instructions executed by a computing unit of a mobile terminal of a wireless network, so that the computing unit performs the method of claim 11.

Images