Sign In to Follow Application
View All Documents & Correspondence

Method And Apparatus For Packet Segmentation And Concatenation Signaling In A Communication System

Abstract: A data transmission method comprising: segmenting or concatenating, by one or more processors, radio layer control (RLC) service data units (SOUs) to RLC protocol data units (PO Us) that fit within a size of a total size of RLC POU(s) indicated by a lower protocol layer processor, each RLC PDU having a header and a data field; mapping, by 10 the one or more processors, a single two bit field including a first bit and a second bit to the header for each of the RLC POUs, wherein a number of bits included in the single two bit field is two regardless of a number of SDUs included in the data field; the first bit and the second bit indicating only (i) whether or not the data field of its corresponding RLC POU begins with a segment of an RLC SOU, and (ii) whether or not the data field 15 ends with a segment of an RLC SOU; transmitting, by a transmitter, a data packet including one or more of the RLC PDUs.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
31 July 2015
Publication Number
06/2016
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
mail@lexorbis.com
Parent Application

Applicants

PANASONIC CORPORATION
1006, OAZA KADOMA, KADOMA-SHI OSAKA 571-8501 JAPAN

Inventors

1. CHARPENTIER, FREDERIC
C/O PANASONIC R & D CENTER GERMANY GMBH, MONZASTRASSE 4C, 63225 LANGEN, GERMANY
2. LÖHR, JOACHIM
C/O PANASONIC R & D CENTER GERMANY GMBH, MONZASTRASSE 4C, 63225 LANGEN, GERMANY

Specification

Field of the Invention
The field of the invention is the mapping of high layer packets into lower layer frames in a
communication system, which can be either a wireless or fixed line network. In order to
adapt the packets delivered by the upper layer to the capabilities of the physical network
(e.g. maximum frame size), it is sometimes necessary to segment or fragment them into
several blocks that would be transmitted by separate frames. In the same way, it might
be also necessary to concatenate several packets into one frame in order to increase
transmission efficiency. The invention proposes a new and efficient way of indicating to
the receiving unit how segmentation and concatenation has been done at the transmitter
side.
Background of the Invention
The necessity of adapting higher layer packets to the characteristics of a physical
network is a classical issue for all type of communication systems, such as wireless
networks (GSM, UMTS, WiLAN, WiMax etc.) or fixed networks (IP, Frame relay, PPP,
ATM, etc).
General Overview of the OSI Layer
In this section, a brief introduction is given to the OSI model (see Figure 1) that will be
used to illustrate the explanations below.
The Open Systems Interconnection Reference Model (OSI Model or OSI Reference
Model for short) is a layered abstract description for communications and computer
network protocol design. The OSI model divides the functions of a system into a series of
layers. Each layer has the property that it only uses the functions of the layer below, and
only exports functionality to the layer above. A system that implements protocol behavior
consisting of a series of these layers is known as a 'protocol stack' or 'stack'. Its main
feature is in the junction between layers which dictates the specifications on how one
layer interacts with another. This means that, in principle, a layer written by one
manufacturer can operate with a layer from another. For our purpose, only the three first
layers will be described.

The main purpose of the physical layer, or layer 1 is the transfer of information (bit) over
a specific physical medium (e.g. coaxial cables, twisted pairs, optical fibers or the air). It
converts or modulates data into signals that are transmitted over a communication
channel.
The purpose of the data link layer, or layer 2 is to shape the information flow in a way
compatible with the specific physical layer by breaking up the input data into data frames
(Segmentation And Re-assembly or SAR functions). Furthermore it may detect and
correct potential transmission errors by requesting a retransmission of a lost frame. It
provides an addressing mechanism and may offer flow control algorithms in order to
align the data rate with the receiver capacity. Finally, when a shared medium is
concurrently used by multiple transmitter and receivers, it offers mechanisms to regulate
and control access to the physical medium. As the span of functions of the data link layer
is large, the data link layer is often subdivided in two sublayers (e.g. RLC and MAC
sublayers in UMTS). Typical examples of layer 2 protocols are PPP/HDLC, ATM, frame
relay for fixed line networks and RLC, LLC or MAC for wireless systems.
The network layer, or layer 3 provides the functional and procedural means for
transferring variable length packets from a source to a destination via one or more
networks while maintaining the quality of service requested by the transport layer. The
main purposes of the network layer are to perform network routing, network
fragmentation and congestion control functions. The main examples of network layer
protocols are the IP Internet Protocol or X.25.
More information on OSl layer model can be found in "Computer Networks", (Andrew S.
Tanenbaum, fourth edition, Prentice Hall International Edition, page 37-41, section 1.4.).
SDU and PDU Definition
In order to formally describe in a generic way the exchange of packets between layers in
the OSl model, SDU (Service Data Unit) and PDU (Protocol Data Unit) entities have
been defined. An SDU is a unit of information transmitted from a protocol at the layer
N+1 that requests a service to a protocol located at layer N via an SAP (Service Access
Point). A PDU is a unit of information exchanged between peer processes at the
transmitter and at the receiver of the same protocol located at the same layer N. A PDU
is generally formed by a payload part consisting of the processed version of the received
SDU and control information, e.g. a layer N specific header and possibly terminated by a

trailer. Since there is no direct physical connection (except for L1) between these peer
processes, a PDU is forwarded to the layer N-1 for processing. Therefore a layer N PDU
is from a layer N-1 point of view a SDU. This is illustrated in Figure 2.
Purpose of Fragmentation/Segmentation
Fragmentation, or equivalently segmentation, may be required for three different
reasons.
First of all, fragmentation may be required to transport datagrams or packets though
networks whose maximum allowed datagram size or maximum transfer unit (MTU) is
smaller than their size. Datagram fragmentation is typically implemented at the IP layer
and is specified as the IP Fragmentation in the IPv4 or IPv6 version of the standard.
Similarly segmentation is necessary when data is transported over an ATM network in
order to fit a payload size of 48 octets into the ATM cell. This is performed in the ATM
adaptation layers (AAL) between the ATM layer 2 and the transport layer (e.g. IP).
Secondly, fragmentation may be carried out in order to balance traffic load on parallel
links for instance on parallel ISDN links. The PPP multilink protocol (MP) ("The PPP
Multilink Protocol (MP)", RFC 1990, Sklower, K., Lloyd, B., McGregor, G., Carr, D. and
T.Coradetti, August 1996) based on PPP describes a method for splitting, recombining
and sequencing datagrams across multiple logical data links.
Finally, in wireless systems, packet segmentation potentially combined with
concatenation is often performed at the layer 2 (e.g in RLC sublayer in UMTS, 3GPP TS
25.322, v6.4.0, "Radio Link Control (RLC) protocol specification") in order to fit higher
layer packets into the resources offered by the lower layer. As resources are typcially
scarce in a wireless environment, concatenation of several higher layer packets is
recommended in order to enhance the overall system efficiency.
In order for the receiver unit to separate concatenated fragments and correctly
recombine the received fragments into the original packets, segmentation information
needs to be delivered to the receiving unit. This information, usually combined with a
numbering technique tagging each fragment, enables the layer 2 at the receiver to
deliver full and consistent packets to the next higher layer.
In the following sections, several existing methods to signal segmentation will be
presented which will help to understand the differences to the present invention.

SAR Signaling via Fragment Numbering
The first class of methods to indicate fragmentation regroups several similar techniques
that indicate the position of the fragments within the source packet. Two elements are
necessary: the first one is an index pointing to the position of the fragment within the
source packet. This index can either take the form of a fragmentation offset (IP
fragmentation, see "Computer Network", Andrew S. Tanenbaum, fourth edition, Prentice
Hall International Edition, page 37-41 section 1.4.) or equivalents a fragment sequence
number FSN (WiLAN, see 802.11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) specifications).
This index must be initialized to a known value (e.g. FSN=zero) for the first fragment of a
source packet. The receiver unit uses this index to reord fragments in the correct
sequence and detect lost fragments. Furthermore the last fragment of a packet is
indicated with a one-bit flag (LF). An un-fragmented packet is signaled to the receiver
side by setting the index to the initial position (e.g. FSN=zero) and simultaneously
indicating that this packet is a last fragment in the source packet. This technique is used
for instance in IP fragmentation protocol or in the ATM Adaptation Layer AAL-1. The
802.11 WiLAN MAC layer uses the same technique as well. WiLAN also appends a field
identifying the source packet to each fragment. This is necessary as 802.11 MAC may
be configured to re-order packets at the receiver side before delivery to the next higher
layer. This in-sequence delivery requirement does not exist at the IP layer, as reordering
is either not required or performed by a higher layer (e.g. TCP).
The principle of the SAR technique via fragment numbering in WiLAN is shown in Figure
3.
The signaling overhead is relatively significant since each fragment must carry at least
the last fragment flag LF and the fragment sequence number FSN and eventually the
sequence number SN of the source packet.
SAR Signaling via Beginning/End Flags
The second class of SAR methods is widely used in various protocols such as ATM
Adaptation layer AAL-3/4, Frame Relay Frame Relay Fragmentation Implementation
Agreement FRF.12, Frame Relay Forum Technical Committee, WiMax and PPP multilink
(MP) (The PPP Multilink Protocol (MP)", RFC 1990, Sklower, K., Lloyd, B., McGregor,
G., Carr, D. and T.Coradetti, August 1996). The main idea in this second class of SAR

techniques is to use two one-bit flags to indicate for each SAR PDU, whether the PDU is
the first, the last or a middle fragment of an SDU or whether it is a complete SAR SDU.
Both flags are part of the PDU header. In some implementations (Frame Relay and PPP
multilink), one distinguishes the function of the two flags as one indicating the beginning
of an SDU and the other one indicating its end. The beginning fragment bit B is set to 1
on the first fragment derived from an SAR SDU and set to 0 for all other fragments from
the same SDU. The ending fragment bit E is set to 1 on the last fragment and set to 0 for
all other fragments. A PDU may have boththebeginning-andending fragment bits set to
1. In this case, it indicates that no segmentation took place. A fragment sequence
numbering is further added in order to the receiver unit to detect fragment loss and
potentially to perform PDU reordering if the link does not preserve the PDU sequence.
After reordering, the receiver can easily check the B and E bits to identify which SAR
PDU need to be combined to re-build the original SDUs. Figure gives an illustration of
this technique.
SAR Signaling via Length Indicators
A third class consists in a set of techniques that are using length indicator fields as
pointers to indicate the boundaries of the SDUs. A good example is the RLC (Radio Link
Control) in UMTS R99. In RLC, an RLC PDU may carry segments of several SDUs or
padding bits. Indeed UMTS R99 operates with fixed size PDU which may not be aligned
with the length of the SDUs to be transmitted. As radio resources are scarce, it was seen
as necessary to allow concatenation of SDU at PDU level. In a generic way, a variable
number of length indicators (LI) are added to the PDU header. A length indicator is used
to indicate the last octet of each RLC SDU ending within the PDU. As usual, a sequence
numbering based on the PDU is added in the header in order to enable loss detection
and reordering. The receiver can therefore perform reordering, request the
retransmission of lost PDU and re-assemble the SDU. Furthermore an LI with a special
value indicates when padding is used to fill up the end of a PDU.
The main drawback of this technique is that the overhead depends on the number of
SDU segments in a PDU, and due to this the header also has a variable size. Moreover
the usage of special fields tends to raise the complexity of the RLC.
Finally, this technique is not very efficient when considering variable PDU size, which
would be more flexible and better adapted to a full packet oriented environment over a
wireless system. A generic example of this technique is shown in Figure 5.

Concatenation Function in Wireless System
Concatenation is a function that is particularly useful for wireless systems. The
combination of segmentation and concatenation enables the transmitter to adapt the
incoming, variable length SDUs better to the resources offered. In case of wireless
system, the number of bits that can be transmitted over a transmission time interval (TTI)
may significantly vary depending on the radio conditions, the code rate and the physical
resources dedicated to the transmission. For instance, a mobile station close to the
transmitter requires less channel encoding than a mobile station further away. With the
same allocated physical resources and the same transmission power, the first mobile
station will be able to receive much more data than the second mobile station. Moreover,
when packet services are considered, the data rate provided by the server may in
principle vary significantly over time.
In UMTS, SDU segmentation and concatenation of SDU segments into PDU are
performed at the RLC level without respect to the physical resources offered and with
fixed pre-defined PDU size. In order to emulate some kind of dynamic behavior, the
MAC layer, based on some indications from the physical layer, determines the number of
PDUs to be transmitted per TTI. In UMTS R99, the selected PDUs are transmitted in the
form of so-called transport channel blocks (TrCH Blk or TrBlk) to the physical layer which
concatenates them and forms a transport channel block set. In UMTS Rel-5 HSDPA, the
selected PDUs are directly concatenated in the MAC layer transport channel block
(TrCH Blk or TrBlk) which, thus, contains several PDUs as shown in Figure 6. Depending
on the radio conditions or other variables, the number of selected PDUs per TTI varies
as shown in Figure 7. Therefore the sequential use of SDU segmentation/concatenation
at the RLC layer with PDU concatenation at the MAC layer (UMTS Rel-5 HSDPA) or at
the physical layer (UMTS R99) enables the transmitter to dynamically adapt the
transmission to instantaneous variables (incoming data from upper layer and resources
offered by lower layers).
In UMTS, the receiver unit is informed of the number of PDUs transmitted per TTI either
via out-of-band signaling (Transport Format Combination Indicator or TFCI) or in-band in
a specific header (e.g. MAC-hs header in HSDPA). It should be noted that the PDU
concatenation step is generally performed independently of the structure of the PDUs,
thus it may happen that a SDU spans over several TTIs.
Efficient Overhead in Systems with Highly Variable Data Rate

The sequential use of SDU segmentation and PDU concatenation as presented above
works well when the range of the number of PDUs to be transmitted is not too large.
However in case of highly variable systems (highly variable physical resources and
highly variable data rate), which may become more common in future systems with high
bandwidth, the usage of a fixed size PDU tends to be suboptimum as the size of the
PDU may not be adapted to the full range of the data rate. Indeed in the case of packet
service the size of the SDU can in principle vary from 40 octets for TCP
acknowledgements-up-to-the-size-of the MTU (e:g around 1500 octets for Ethernet). On
the physical layer side, scheduled shared systems such as HSDPA in UMTS offer
physical resources per TTI that may vary from few kbps to the complete bandwidth (e.g.
14Mbps in HSDPA). It is expected that this trend will be confirmed by future wireless
system.
The problem comes from the fact that the small PDU size that would be optimal for the
lower part of the data rate span, becomes a burden when considering the higher part of
the data rate span. Indeed, the receiver will have more PDUs to treat per TTI and would
require more computation. Furthermore the sequence number range identifying the
PDUs may become too short, and a wrap around problem may occur. Finally the
overhead, which is equal to n*PDU header_size, increases more or less linearly with the
length of the transport channel block. Using a large PDU will force the transmitter to
either delay transmission in order to fill up the PDU or to heavily pad the unused space in
the PDU at low data rates. Increased jitter or extensive padding have a strong negative
influence on the efficiency of a radio system and should be avoided.
In general, the size of the PDU is a static parameter of the radio bearer used to carry the
considered service. This parameter cannot be changed without a heavy reconfiguration
procedure. Therefore it is difficult to efficiently adapt the link to the characteristics of the
incoming SDUs or to the resources offered by the lower layer without strong limitations
on either the data rate or the range of physical resources that can be allocated per TTI.
Error Propagation
The SAR signaling techniques with length indicators are sensitive to error propagation.
Indeed it may happen that the loss of a PDU forces the receiver to intentionally drop
correctly received SDUs due to SDU border uncertainty. As shown in Figure 8, the loss
of PDU i+2 forces the receiver to drop the correctly received PDU i+3, since it cannot

determine whether the fragment contained in PDU i+3 is a full SDU (alternative 1) or a
segment of SDU (alternative 2).
In UMTS Rel-6, some attempts have been made to limit this issue and to reduce the
overhead in some particular conditions where the SDU size matches the PDU size.
However in the general case, this problem comes from the fact that each PDU carries
information on its own structure and without respect to the inner structure of the adjacent
PDUs.
SAR signaling techniques with beginning/end flags or with fragment numbering are much
more robust in this as the receiver exactly knows when enough PDUs are received.
However, the overhead of these techniques increases linearly with the number of
concatenated PDUs.
As can be seen, several techniques exist to signal segmentation and concatenation.
However they tend to suffer either from high overhead, lack of flexibility or may lead to
increased complexity at the receiver side. Robustness towards error propagation is not
given, either.
Summary of the Invention
It is an object of the invention to provide efficient and feasible segmentation and
concatenation in packet communications.
The object is solved by the subject matter of the independent claims. Advantageous
embodiments of the invention are subject matters to the dependent claims.
Different embodiments of the invention provide a data packet structure, method,
apparatus, system and computer readable medium for conveying data of service data
units using protocol data units. The data packet comprises a packet payload comprising
at least one protocol data unit, wherein a protocol data unit comprises a service data unit
or a fragment of the service data unit and a data packet header comprising an indicator
indicating whether or not the data packet payload begins with a protocol data unit being a
fragment of a service data unit and whether or not the data packet payload ends with a
protocol data unit being a fragment of the service data unit.
According to an advantageous embodiment the indicator consist of two flags, wherein
the first flag indicates whether the data packet payload begins with the protocol data unit

being a fragment of a service data unit and the second flag indicates whether the data
packet payload ends with a protocol data unit being a fragment of the service data unit.
The advantage of this embodiment is that the flag, when set, indicates a protocol data
unit being a fragment of the service data unit.
According to another advantageous embodiment the data packet structure comprises a
sequence number indicator indicating the position of the data packet in a sequence of
data packets.
In a further advantageous embodiment the method for transmitting data packets
comprising service data units comprises the steps of forming at least one protocol data
unit comprising a service data unit or a fragment of a service data unit, forming a data
packet payload comprising at least one protocol data unit, forming a data packet header
comprising at least an indicator for indicating whether or not the data packet payload
begins with a protocol data unit being a fragment of a service data unit and whether or
not the data packet payload ends with a protocol data unit being a fragment of the
service data unit, forming a data packet comprising the data packet header and the data
packet payload, and transmitting the data packet over a channel.
According to another advantageous embodiment the data packet payload comprises a
plurality of protocol data units and the data packet begins with a first protocol data unit
and ends with a last protocol data unit.
In a further a advantageous embodiment the step of forming the data packet payload of a
predetermined size further comprises the following sub-steps a), b) and c). In a) it is
determined whether the size remaining in the data packet payload is sufficient to
transport a next service data unit or a fragment remaining from a previous service data
unit. If this is the case, in b) a next protocol data unit comprising the next service data
unit or a fragment of a previous service data unit is formed and the protocol data unit is
added to the data packet payload. Otherwise, a next service data unit or fragment
remaining from a previous service data unit is fragmented and a protocol data unit is
formed comprising a first fragment of the service data unit or fragment remaining from a
previous service data unit such that the size of the protocol data unit corresponds to the
remaining size of the data packet payload and the protocol data unit is added to the data
packet payload. Steps a) and b) are repeated until the data packet payload has an
insufficient size remaining to transport a next service data unit.

It is further advantageous that, upon having filled the data packet payload with protocol
data units, the indicators to indicate whether or not the data packet payload begins with
the protocol data unit being a fragment of the service data unit and whether or not the
data packet payload ends with a protocol data unit being a fragment of the service data
unit are set.
In another advantageous embodiment the data packet payload is dynamically fixed by a
resource allocation entity depending on reaio conditions and buffer occupancy.
In a further advantageous embodiment, a method for receiving data packets comprising
a data packet header and a data packet payload, wherein the data packet payload
comprises at least one protocol data unit comprising either a service data unit or a
fragment of a service data unit is described. The method comprises the steps of
receiving data packets over a channel, each data packet comprising a data packet
payload and a data packet header, the data packet header comprising a sequence
number indicator indicating the position of the data packet in a data packet sequence,
and an indicator wherein the indicator indicates whether or not the data packet payload
begins with the protocol data unit being a fragment of a service data unit and whether or
not the data packet ends with the packet payload being a fragment of the service data
unit, saving the protocol data units of the received data packet payload with previously
received protocol data units in a reception buffer in-sequence according to the sequence
number indicator, and marking whether a first protocol data unit of the received data
packet payload is to be combined with the previous in-sequence protocol data unit and
whether a last protocol data unit of the received data packet payload is to be combined
with a next in-sequence protocol data unit.
According to a further advantageous embodiment the reception buffer is analysed as to
whether the protocol data unit is marked and if it is the protocol data unit is combined
with the other marked protocol data unit to form a service data unit.
In another advantageous embodiment, an apparatus for transmitting data packets
comprising service data units is described. The apparatus comprises a protocol data unit
forming means adapted to form a protocol data unit comprising a service data unit or a
fragment service data unit, a data packet payload forming means adapted to form a data
packet payload comprising at least one protocol data unit, data packet header forming
means adapted to form a data packet header comprising an indicator for indicating
whether or not the data packet payload begins with a protocol data unit being a fragment

of a service data unit and whether or not the data packet payload ends with a protocol
data unit being a fragment of a service data unit, data packet forming means adapted to
form a data packet comprising the data packet header and the data packet payload, and
transmitting means adapted to transmit the data packets over a channel.
A further embodiment of this invention relates to an apparatus for receiving data packets
comprising a data packet header and a data packet payload, wherein a data packet
payload comprises at least one protocol data unit comprising either a service data unit or
a fragment of a service data unit. The apparatus comprises receiving means adapted to
receive data packets over a channel, each data packet comprising a data packet payload
and a data packet header, the data packet header comprising a sequence number
indicator indicating the position of the data packet in a data packet sequence, and an
indicator, wherein the indicator indicates whether or not the data packet payload begins
with a protocol data unit being a fragment of a service data unit and whether or not the
data packet ends with the protocol data unit being a fragment of the service data unit. It
further comprises a reception buffer adapted to save the protocol data units of the
received data packet payload with previously received protocol data units in-sequence
according to the sequence number indicator, and marking means adapted to mark
whether a first protocol data unit of the received data packet payload is to be combined
with the previous in-sequence protocol data unit and whether a last protocol data unit of
the received data packet payload is to be combined with a next in-sequence protocol
data unit.
Another embodiment of the invention relates to a computer readable medium storing
instructions that, when executed by a processor of a transmitting apparatus, cause the
transmitting apparatus to transmit data packets comprising service data unit. This is
done by forming at least one protocol data unit comprising a service data unit or a
fragment of a service data unit, forming a data packet payload comprising protocol data
units, forming a data packet header comprising at least an indicator for indicating
whether or not data packet payload begins with a protocol data unit being a fragment of
the service data unit and whether or not the data packet payload ends with a protocol dat
unit being a fragment of the service data unit, and transmitting the data packets over a
channel.
A further advantageous embodiment relates to a computer readable medium storing
instructions that, when executed by a processor of a receiving apparatus, cause the
receiving apparatus to receive data packets comprising a data packet header and a data

packet payload, wherein the data packet payload comprises at least one protocol data
unit comprising either a service data unit or a fragment of a service data unit is
described. The method comprises the steps of receiving data packets over a channel,
each data packet comprising a data packet payload and a data packet header, the data
packet header comprising a sequence number indicator indicating the position of the
data packet in a data packet sequence, and an indicator wherein the indicator indicates
whether or not the data packet payload begins with the protocol data unit being a
fragment of a service data unit and whether or riot the data packet ends with the packet
payload being a fragment of the service data unit, saving the protocol data units of the
received data packet payload with previously received protocol data units in a reception
buffer in-sequence according to the sequence number indicator, and marking whether a
first protocol data unit of the received data packet payload is to be combined with the
previous in-sequence protocol data unit and whether a last protocol data unit of the
received data packet payload is to be combined with a next in-sequence protocol data
unit.
Brief Description of the Drawings
In the following, the invention is described in more detail with reference to the attached
figures and drawings. Similar, our corresponding details and the figures are marked with
the same references.
Figure 1 - shows the OSI layer model;
Figure 2 - shows SDU and PDU in the OSI layer model;
Figure 3 - shows SAR signaling by fragment numbering;
Figure 4 - shows SAR signaling with Beginning and End flags;
Figure 5 - shows SAR signaling with length indicators;
Figure 6 - shows the SDU Segmentation and PDU concatenation Processes;
Figure 7 - shows Transport Channel Block generation;
Figure 8 - shows error propagation in UMTS R99;
Figure 9 - shows the SAR and concatenation processes of an embodiment of the present
invention;

Figure 10 - shows the SAR and concatenation flow with Fragmentation Flag of an
embodiment of the present invention;
Figure 11 - shows SAR signaling with Fragmentation Flags according to an embodiment
of the present invention; and
Figure 12 - is a flow diagram for the segmentation and concatenation process.
Detailed Description of the Invention
The present invention is applicable to any data packet communication system using
variable length transmission frames, for example, wireless networks such as GSM,
UMTS, WiLAN, WiMAX, etc. or fixed networks such as IP, frame relay, PPP, ATM etc.
The different embodiments of the invention are described based on the OSI layer model,
especially the exchange of packets between an SDU and PDU layer. Please see the
background section for a more detailed description of the relevant parts of the OSI layer
model as well as SDUs and PDUs. The background section also describes the reasons
for employing fragmentation and/or segmentation in communication networks.
In this invention, a method is proposed that enables an efficient Segmentation and
Concatenation procedure at the fixed signaling cost, which makes the overhead
decrease in percent with the length of the transmitted TrBlk.
SDU segmentation and PDU concatenation both depend on the physical resources that
are allocated for transmission for the next TTI. For instance the size of the payload of the
next transport channel block (Sizejnd) can be indicated to the SAR function as shown in
Figure 9.
Based on this indication, the SAR function selects n SDUs, the total size of which is just
above Sizejnd. If the sum of the length of the n SDUs is greater than sizejnd, the SAR
function segments the last SDU in two fragments. The sum of the n-1th SDUs and the
first fragment of the nth SDU is equal to Sizejnd. Each of them is transformed into a
PDU and receives a sequence number attributed sequentially. For the next transmission,
the second fragment will be considered first. This is shown in Figure 10, where the SDU3
is fragmented in 2 PDUs (PDU3 and PDU4).
Therefore by construction, all formed PDUs are full SDUs except the first and the last
ones in a transport block (TrBlk), which may be a fragment of an SDU. All the others are

full SDUs therefore it is sufficient to indicate to the receiver whether the first and the last
PDUs in a transport block are fragments of an SDU or a full SDU. This can be done
easily by 2 one-bit flags or fragmentation flags attached to the TrBlk header. The first
fragmentation flag, or FFF, indicates whether the first SAR PDU in the TrBlk is a
fragment of an SDU or not and the second fragmentation flag (SFF) indicates whether
the last SAR PDU in the TrBlk is a fragment of an SDU or not.
This process can be described in a generalized form along the lines of Figure 12. SDUs
or fragments of SDUs are taken from a buffer and it is then determined whether the SDU
or fragment of an SDU fits in the remaining size of the transport block, which might be
the whole of the transport block or only a part thereof. If the full SDU or fragment of the
SDU fits in the remaining size of the transport block, a PDU is created from this SDU.
This PDU is then inserted in the transport block.
The transport block is checked whether there is any size remaining. If there is, the
process starts over again, if there is not, the indicators are added and the transport block
is transmitted with the indicators.
If however, the SDU or fragment of the SDU does not fit in the remaining size of the
transport block, the SDU is fragmented and a PDU is created from a fragment of the
SDU to fit into the remaining size of the transport block. The second fragment of the SDU
is put in the buffer and the PDU is then inserted into the transport block and the
indicators added.
The first fragmentation flag (FFF) indicates whether the first PDU in the transport block is
a fragment of SDU or not and the second fragmentation flag (SFF) indicates whether the
last PDU in the transport block is a fragment of an SDU or not.
Finally, the transport block is transmitted with the indicators and the process can start
again.
When receiving a transport block n with the FFF set to 1, the receiver knows that the first
SAR PDU in the TrBlk must be combined with the last SAR PDU of the previous TrBlk n-
1. This TrBlk may have also indicated that the last SAR PDU in this TrBlk is a fragment
of an SDU by setting the SFF to 1.
In a lossless system, FFF and SFF provide redundant information and are not really
needed. However in a lossy system such as a wireless system, this is helpful to prevent

error propagation. Indeed, if the (n-1)th TrBlk in the previous example had been lost, the
receiver unit would have detected this loss thanks to the SAR PDU sequence numbering,
and the FFF in the nth TrBlk would have indicated that the first PDU can be discarded as
the corresponding SDU is incomplete. However the second and subsequent PDU in the
nth TrBlk will be kept and used in the re-assembly function.
If only one PDU is transmitted per SDU, FFF and SFF may still have different values.
FFF would indicate whether the PDU should be combined with Hie last PDU of the
previous TrCh Blk and SFF would indicated whether the PDU should be combined with
the first PDU of the next TrCh Blk.
One important aspect of the invention is to signal SAR information not at PDU level (i.e in
the PDU header) but rather in the TrBlk header. By using variable size PDU and simple
segmentation and concatenation rules, it is proposed to indicate SAR information with
only 2 bits per TrBlk header, which indicate the status (fragmented, not fragmented) of
the first and the last PDU that are concatenated in the TrBlk.
Compared to the prior art solution, the SAR information is only 2 bits per TrBlk, which
has to be compared to 2*n bits per TrBlk for the SAR signaling with beginning/end flags,
where n is the number of PDU in the TrBlk. This is a significant decrease when many
PDUs are concatenated in the same TrBlk.
As can be seen, it is assumed that the SAR PDU size is variable. For example, in the
current state of UMTS, the size of the PDU is fixed and is a static parameter of the
bearer used to carry the service. There is sometimes a need to inform the receiver where
the PDU boundaries can be found. Then it is required to indicate the length of each PDU
in the SAR PDU header with length indicators as shown in Figure 11. This is actually
equivalent to the length indicator fields that are used in the SAR signaling techniques
with length indicators to signaled SDU boundaries within each PDU.
Moreover it would be possible to further save space by signaling only one SAR PDU
sequence number per TrBlk. The sequence number of the first PDU or the last PDU in
the TrBlk can be used for this purpose. The receiver can count the number of length
indicators contained in the TrBlk to get the number of concatenated PDUs or a small field
N indicating this number can be added in the TrBlk header as shown as in Figure 11.
Another embodiment of the invention relates to the implementation of the above
described various embodiments using hardware and software. It is recognized that the

various above mentioned methods may be implemented or performed using computing
devices (processors) as for example general purpose processors, digital signal
processors (DSP), applications specific integrated circuits (ASIC), field programmable
gate arrays (FPGA) or other programmable logic devices etc. The various embodiments
of the invention may also be performed or embodied by a combination of these devices.
Further, the various embodiments of the invention may also be implemented by means of
software modules, which are executed by a processor or directly in hardware. Also, a
combination of software modules and a hardware implementation may be possible.
The software modules may be stored on any kind of computer-readable storage media,
for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM,
DVD etc.

We claim:
1. A data transmission method comprising:
segmenting or concatenating, by one or more processors, radio layer control
(RLC) service data units (SDUs) to RLC protocol data units (PDUs) that fit within a size
of a total size of RLC PDU(s) indicated by a lower protocol layer processor, each RLC
PDU having a header and a data field;
mapping, by the one or more processors, a single two bit field including a first bit
and a second bit to the header for each of the RLC PDUs, wherein a number of bits
included in the single two bit field is two regardless of a number of SDUs included in the
data field;
the first bit and the second bit indicating only (i) whether or not the data field of
its corresponding RLC PDU begins with a segment of an RLC SDU, and (ii) whether or
not the data field ends with a segment of an RLC SDU;
transmitting, by a transmitter, a data packet including one or more of the RLC
PDUs.
2. The method according to claim 1, further comprising mapping a sequence
number to the header for each of the RLC PDUs.
3. The method according to claim 1, further comprising mapping a length
indicator to the header for each of the RLC PDUs.
4. Data transmission apparatus comprising:
a processor configured to segment or concatenate radio layer control (RLC)
service data units (SDUs) to RLC protocol data units (PDUs) that fit within a size of a

total size of RLC PDU(s) indicated by a lower protocol layer processor, each RLC PDU
having a header and a data field;
the processor being further configured to map a single two bit field including a
first bit and a second bit to the header for each of the RLC PDUs, wherein a number of
bits included in the single two bit field is two regardless of a number of SDUs included in
the data field;
the first bit and the second bit indicate only (i) whether or not the data field of its
corresponding RLC PDU begins with a segment of an RLC SDU, and (ii) whether or not
the data field ends with a segment of an RLC SDU;
a transmitter configured to transmit a data packet including one or more of the
RLC PDUs.
5. The apparatus according to claim 4, wherein the processor is configured to map
a sequence number to the header for each of the RLC PDUs.
6. The apparatus according to claim 4, wherein the apparatus is a wireless
terminal in a communication system.
7. The apparatus according to claim 4, wherein the apparatus is a wireless base
station in a communication system.
8. A method for receiving data packets, the method comprising the steps of:
(a) receiving and processing data packets by a receiver;
(b) detecting, in at least some of the data packets, radio layer control (RLC)
protocol data units (PDUs), each RLC PDU having a header and a data field;

wherein the data field includes (i) a plurality of full service data units (SDUs), (ii)
a plurality of segments of SDUs, or (iii) at least one full SDU and at least one segment of
a SDU;
wherein the header includes a single two bit field with a first bit and a second bit,
wherein a number of bits included in the single two bit field is two regardless of a
number of SDUs included in the data field, and wherein the first bit and the second bit of
the single two bit field indicate only (i) whether or not the data field begins with a
segment of an SDU, and (ii) whether or not the data field ends with a segment of an
SDU; and
(b) reassembling the SDUs of the received data field based on the single two bit
field.
9. The method according to claim 8, wherein the method further comprises:
buffering the (i) plurality of full SDUs, (ii) plurality of segments of SDUs, or (iii)
at least one full SDU and at least one segment of an SDU of the received data field with
previously received at least one full or segment of an SDU in a reception buffer.
10. An apparatus for receiving data packets, the apparatus comprising:
a receiver configured to receive data packets;
one or more processors, coupled to the receiver, configured to detect, in at least
some of the data packets, radio layer control (RLC) protocol data units (PDUs), each
RLC PDU having a header and a data field;
wherein the data field includes (i) a plurality of full service data units (SDUs), (ii)
a plurality of segments of SDUs, or (iii) at least one full SDU and at least one segment of
a SDU;

wherein the header includes a single two bit field with a first bit and a second bit,
wherein a number of bits included in the single two bit field is two regardless of a
number of SDUs included in the data field, and wherein the first bit and the second bit of
the single two bit field indicate only (i) whether or not the data field begins with a
segment of an SDU, and (ii) whether or not the data field ends with a segment of an
SDU; and
wherein the one or more processors are configured to reassemble the SDUs of the
received data field based on the single two bit field.
11. The apparatus according to claim 10, wherein the apparatus further comprises
a reception buffer configured to buffer the (i) plurality of full SDUs, (ii) plurality of
segments of SDUs, or (iii) at least one full SDU and at least one segment of an SDU of
the received data field with previously received at least one full or segment of an SDU.
12. The apparatus according to claim 10, the apparatus is a wireless terminal in a
communication system.
13. The apparatus according to claim 10, the apparatus is a wireless base station in
a communication system.

Documents

Orders

Section Controller Decision Date

Application Documents

# Name Date
1 2512-KOLNP-2015-(31-07-2015)-SPECIFICATION.pdf 2015-07-31
1 2512-KOLNP-2015-Correspondence to notify the Controller [13-09-2023(online)].pdf 2023-09-13
2 2512-KOLNP-2015-(31-07-2015)-FORM-5.pdf 2015-07-31
2 2512-KOLNP-2015-US(14)-HearingNotice-(HearingDate-15-09-2023).pdf 2023-08-24
3 2512-KOLNP-2015-FORM 3 [07-02-2023(online)].pdf 2023-02-07
3 2512-KOLNP-2015-(31-07-2015)-FORM-3.pdf 2015-07-31
4 2512-KOLNP-2015-FORM 3 [19-08-2022(online)].pdf 2022-08-19
4 2512-KOLNP-2015-(31-07-2015)-FORM-2.pdf 2015-07-31
5 2512-KOLNP-2015-FORM 3 [20-11-2021(online)].pdf 2021-11-20
5 2512-KOLNP-2015-(31-07-2015)-FORM-1.pdf 2015-07-31
6 2512-KOLNP-2015-FORM 3 [29-04-2021(online)].pdf 2021-04-29
6 2512-KOLNP-2015-(31-07-2015)-DRAWINGS.pdf 2015-07-31
7 2512-KOLNP-2015-FORM 3 [14-10-2020(online)].pdf 2020-10-14
7 2512-KOLNP-2015-(31-07-2015)-DESCRIPTION (COMPLETE).pdf 2015-07-31
8 2512-KOLNP-2015-ABSTRACT [05-05-2020(online)].pdf 2020-05-05
8 2512-KOLNP-2015-(31-07-2015)-CORRESPONDENCE.pdf 2015-07-31
9 2512-KOLNP-2015-(31-07-2015)-CLAIMS.pdf 2015-07-31
9 2512-KOLNP-2015-CLAIMS [05-05-2020(online)].pdf 2020-05-05
10 2512-KOLNP-2015-(31-07-2015)-ABSTRACT.pdf 2015-07-31
10 2512-KOLNP-2015-COMPLETE SPECIFICATION [05-05-2020(online)].pdf 2020-05-05
11 2512-KOLNP-2015-(18-12-2015)-FORM-18.pdf 2015-12-18
11 2512-KOLNP-2015-FER_SER_REPLY [05-05-2020(online)].pdf 2020-05-05
12 2512-KOLNP-2015-(29-01-2016)-OTHERS.pdf 2016-01-29
12 2512-KOLNP-2015-OTHERS [05-05-2020(online)].pdf 2020-05-05
13 2512-KOLNP-2015-(29-01-2016)-CORRESPONDENCE.pdf 2016-01-29
13 2512-KOLNP-2015-PETITION UNDER RULE 137 [05-05-2020(online)].pdf 2020-05-05
14 2512-KOLNP-2015-(29-01-2016)-ASSIGNMENT.pdf 2016-01-29
14 2512-KOLNP-2015-FORM 3 [26-12-2019(online)].pdf 2019-12-26
15 2512-KOLNP-2015-(29-01-2016)-ANNEXURE TO FORM 3.pdf 2016-01-29
15 2512-KOLNP-2015-FER.pdf 2019-11-06
16 2512-KOLNP-2015-FORM 3 [25-07-2019(online)].pdf 2019-07-25
16 Power of Attorney [19-04-2017(online)].pdf 2017-04-19
17 Other Document [19-04-2017(online)].pdf 2017-04-19
17 2512-KOLNP-2015-FORM 3 [16-01-2019(online)].pdf 2019-01-16
18 2512-KOLNP-2015-FORM 3 [24-10-2018(online)].pdf 2018-10-24
18 Form 6 [19-04-2017(online)].pdf 2017-04-19
19 2512-KOLNP-2015-AMENDED DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
19 Form 3 [19-04-2017(online)].pdf 2017-04-19
20 2512-KOLNP-2015-Changing Name-Nationality-Address For Service [25-06-2018(online)].pdf 2018-06-25
20 Form 13 [19-04-2017(online)].pdf 2017-04-19
21 2512-KOLNP-2015-RELEVANT DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
21 Description(Complete) [19-04-2017(online)].pdf_86.pdf 2017-04-19
22 2512-KOLNP-2015-FORM 3 [02-06-2018(online)].pdf 2018-06-02
22 Description(Complete) [19-04-2017(online)].pdf 2017-04-19
23 2512-KOLNP-2015-FORM 3 [22-12-2017(online)].pdf 2017-12-22
23 Assignment [19-04-2017(online)].pdf 2017-04-19
24 2512-KOLNP-2015-FORM 3 [09-10-2017(online)].pdf 2017-10-09
25 Assignment [19-04-2017(online)].pdf 2017-04-19
25 2512-KOLNP-2015-FORM 3 [22-12-2017(online)].pdf 2017-12-22
26 2512-KOLNP-2015-FORM 3 [02-06-2018(online)].pdf 2018-06-02
26 Description(Complete) [19-04-2017(online)].pdf 2017-04-19
27 2512-KOLNP-2015-RELEVANT DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
27 Description(Complete) [19-04-2017(online)].pdf_86.pdf 2017-04-19
28 2512-KOLNP-2015-Changing Name-Nationality-Address For Service [25-06-2018(online)].pdf 2018-06-25
28 Form 13 [19-04-2017(online)].pdf 2017-04-19
29 2512-KOLNP-2015-AMENDED DOCUMENTS [25-06-2018(online)].pdf 2018-06-25
29 Form 3 [19-04-2017(online)].pdf 2017-04-19
30 2512-KOLNP-2015-FORM 3 [24-10-2018(online)].pdf 2018-10-24
30 Form 6 [19-04-2017(online)].pdf 2017-04-19
31 2512-KOLNP-2015-FORM 3 [16-01-2019(online)].pdf 2019-01-16
31 Other Document [19-04-2017(online)].pdf 2017-04-19
32 2512-KOLNP-2015-FORM 3 [25-07-2019(online)].pdf 2019-07-25
32 Power of Attorney [19-04-2017(online)].pdf 2017-04-19
33 2512-KOLNP-2015-(29-01-2016)-ANNEXURE TO FORM 3.pdf 2016-01-29
33 2512-KOLNP-2015-FER.pdf 2019-11-06
34 2512-KOLNP-2015-(29-01-2016)-ASSIGNMENT.pdf 2016-01-29
34 2512-KOLNP-2015-FORM 3 [26-12-2019(online)].pdf 2019-12-26
35 2512-KOLNP-2015-(29-01-2016)-CORRESPONDENCE.pdf 2016-01-29
35 2512-KOLNP-2015-PETITION UNDER RULE 137 [05-05-2020(online)].pdf 2020-05-05
36 2512-KOLNP-2015-OTHERS [05-05-2020(online)].pdf 2020-05-05
36 2512-KOLNP-2015-(29-01-2016)-OTHERS.pdf 2016-01-29
37 2512-KOLNP-2015-(18-12-2015)-FORM-18.pdf 2015-12-18
37 2512-KOLNP-2015-FER_SER_REPLY [05-05-2020(online)].pdf 2020-05-05
38 2512-KOLNP-2015-(31-07-2015)-ABSTRACT.pdf 2015-07-31
38 2512-KOLNP-2015-COMPLETE SPECIFICATION [05-05-2020(online)].pdf 2020-05-05
39 2512-KOLNP-2015-(31-07-2015)-CLAIMS.pdf 2015-07-31
39 2512-KOLNP-2015-CLAIMS [05-05-2020(online)].pdf 2020-05-05
40 2512-KOLNP-2015-(31-07-2015)-CORRESPONDENCE.pdf 2015-07-31
40 2512-KOLNP-2015-ABSTRACT [05-05-2020(online)].pdf 2020-05-05
41 2512-KOLNP-2015-(31-07-2015)-DESCRIPTION (COMPLETE).pdf 2015-07-31
41 2512-KOLNP-2015-FORM 3 [14-10-2020(online)].pdf 2020-10-14
42 2512-KOLNP-2015-FORM 3 [29-04-2021(online)].pdf 2021-04-29
42 2512-KOLNP-2015-(31-07-2015)-DRAWINGS.pdf 2015-07-31
43 2512-KOLNP-2015-FORM 3 [20-11-2021(online)].pdf 2021-11-20
43 2512-KOLNP-2015-(31-07-2015)-FORM-1.pdf 2015-07-31
44 2512-KOLNP-2015-FORM 3 [19-08-2022(online)].pdf 2022-08-19
44 2512-KOLNP-2015-(31-07-2015)-FORM-2.pdf 2015-07-31
45 2512-KOLNP-2015-FORM 3 [07-02-2023(online)].pdf 2023-02-07
45 2512-KOLNP-2015-(31-07-2015)-FORM-3.pdf 2015-07-31
46 2512-KOLNP-2015-US(14)-HearingNotice-(HearingDate-15-09-2023).pdf 2023-08-24
46 2512-KOLNP-2015-(31-07-2015)-FORM-5.pdf 2015-07-31
47 2512-KOLNP-2015-(31-07-2015)-SPECIFICATION.pdf 2015-07-31
47 2512-KOLNP-2015-Correspondence to notify the Controller [13-09-2023(online)].pdf 2023-09-13

Search Strategy

1 searchstreatgy_19-09-2019.pdf