IN THE HIGH COURT OF JUSTICE
BUSINESS AND PROPERTY COURTS
INTELLECTUAL PROPERTY (ChD)
PATENTS COURT
Royal Courts of JusticeRolls Building, 7 Rolls BuildingsFetter LaneLondon EC4A 1NL
Before :
THE HON MR JUSTICE MELLOR
Between :
(1) MITSUBISHI ELECTRIC CORPORATION (2) SISVEL INTERNATIONAL SA | Claimants |
- and - | |
(1) ARCHOS SA (2) SUN CUPID TECHNOLOGY HK LTD (3) NUU MOBILE UK LIMITED (4) ONEPLUS TECHNOLOGY (SHENZHEN) CO., LTD (5) OPLUS MOBILETECH UK LIMITED (6) REFLECTION INVESTMENT B.V. (7) GUANGDONG OPPO MOBILE TELECOMMUNICATIONS CORP, LTD (8) OPPO MOBILE UK LTD | Defendants |
(9) XIAOMI COMMUNICATIONS CO LTD
(10) XIAOMI INC
(11) XIAOMI TECHNOLOGY FRANCE SAS
(12) XIAOMI TECHNOLOGY UK LIMITED
Adrian Speck QC and Michael Conway (instructed byBird & Bird LLP) for the Claimants Andrew Lykiardopoulos QC and Adam Gamsa (instructed by Taylor Wessing LLP) for the Fourth to Eighth Defendants Andrew Lykiardopoulos QC and Isabel Jamal (instructed by Kirkland & Ellis International LLP) for the Ninth to Twelfth Defendants
Hearing dates: 9th-12th, 16th-17th March 2021
Approved Judgment
I direct that pursuant to CPR PD 39A para 6.1 no official shorthand note shall be taken of this Judgment and that copies of this version as handed down may be treated as authentic.
.............................
THE HON MR JUSTICE MELLOR
Mr Justice Mellor :
This judgment is organised as follows:
Topic Page
Claim Scope – relevant legal principles 26
The characterisation of the invention 27
The problem underlying the invention 30
Claim scope – normal construction 31
The Claimants’ Application to Amend 37
Introduction
This is my judgment following the first technical trial in these proceedings in which the Claimants seek to persuade the two sets of Defendants who remain to take licences of a pool of patents (‘the MCP Pool’) administered by the Second Claimant which are alleged to be essential to one or more telecoms standards. Originally the first technical trial was due to take place in December 2020 involving a different patent but that trial was settled and, as I understand it, the patent in question will play no further part in this
action. This trial concerned EP 1,925,142 (EP142 or the Patent), of which the Second Claimant (Sisvel) is the registered proprietor. The First Claimant has no direct interest, although EP142 is part of the MCP Pool in which the First Claimant does have an interest.
EP142 is alleged to be essential to version 10.0.0 and all subsequent versions of TS36.322 of the 4th generation 3GPP Long-Term Evolution (“LTE’) standard.
Summary of the issues
This case is about the signalling of structure in a digital signal. The digital signals in question are those created and received in 3G and 4G mobile telephone networks in level 2 of the OSI 7 layer model. The case turns on the meaning and scope of the term ‘length indicator’ in claim 1 of EP142.
Although the preferred embodiments in EP142 are written in the context of UMTS/3G, it is Sisvel’s case, as mentioned above, that EP142 is essential to the LTE/4G standard. The Defendants deny essentiality, thereby denying infringement, but also run a series of squeeze arguments to the effect that if EP142 is essential to LTE, then EP142 is invalid on a variety of grounds.
Sisvel makes an unconditional application to amend by way of two requests – Request 1 and Request 2 – which Sisvel advances in the alternative. Sisvel says it makes the application to amend to forestall any argument that the claimed monopoly covers a regime that indicates only if a single SDU is a perfect fit, a point which I return to later.
EP142 is entitled ‘Radio Link Control Unacknowledged Mode Header Optimization’ and has a priority date of 23 August 2005. As is often the case, the key to this action lies in assessing the scope of the claim at the correct level of generality and in the correct context. As is usual in patent cases, this judgment needs to set out a good deal of information in order to define the correct context for the claimed RLC UM header optimization, in the course of which the reader will have to pick up the numerous acronyms which encrust this art.
Mr Adrian Speck QC led Mr Michael Conway for Sisvel and Mr Andrew
Lykiardopoulos QC led Mr Adam Gamsa for the Fourth to Eighth Defendants and Ms Isabel Jamal for the Ninth to Twelfth Defendants. I am grateful to Counsel and their solicitor teams for their assistance. The trial was heard as a fully remote trial on MS Teams, with electronic bundles on CaseLines, a convenient feature of which enables all participants to accept prompts to jump to a particular page, so that everyone looks at the correct passage in the bundle. The technology worked well.
The Expert Witnesses
Sisvel’s expert witness was Dr Alastair Brydon and Mr Claude Royer was the expert called on behalf of the Defendants. Mr Royer gave his evidence from Canada, so certain of the trial days were set later to accommodate his time zone. In closing, such criticisms as were levelled at the experts were slight, perhaps because each side had extracted what they perceived they needed in cross-examination. Both experts gave their evidence in a straightforward and direct manner. There were times when each of them had a tendency to stick to the party line, slightly more so in the case of Mr Royer.
However, none of this matters because of the nature of the issues in this case. I am very grateful to Dr Brydon and Mr Royer for their assistance. They were both good educators.
The Skilled Person or Team
The experts were agreed that the Patent would be of interest to a person or team working on the implementation of and/or development of telecommunications standards, with a focus on Layer 2 (the data link layer) including the RLC sub-layer. They also agreed that the person or team would be an engineer with typically a higher degree and/or several years’ experience in industry.
There was, however, a mini-dispute as to the size and breadth of expertise of the Skilled Person or team, in particular as to their knowledge and/or experience with other wireless communications standards than UMTS. This dispute was concerned, as I understand it, primarily with the WiMAX prior art. It is not necessary for me to resolve that dispute since it does not affect anything I have to decide.
Common General Knowledge
At the PTR, I ordered the parties to produce a document setting out the agreed CGK together with a list of any CGK points in dispute. This they did and I am grateful for the work done on both sides to produce a very useful document.
What follows in paragraphs 14-65 below is the CGK as agreed between the parties, with some slight editing of my own. It includes references to some developments after the Priority Date (which were obviously not CGK) in order to illustrate the position as at August 2005. I add some further points of CGK at the end of this section.
Layers in wireless architecture
The architecture of wireless communications networks, including UMTS, is typically described as a "stack" of protocol "layers". Each layer has a specific set of functions and each relies on other layers to perform its function.
The Open Systems Interconnection ("OSI") model was developed by the International Standards Organisation. It describes the following seven layers that are typically present in a communications network in some form.
Figure 1: the OSI model showing the seven layers typically present in a communications network
Generally, the higher layers (5, 6 and 7) are primarily concerned with interacting with the user and implementing the applications that run over the network. The lower layers (1, 2, 3 and 4) are primarily concerned with the formatting, encoding and transmission of data over the network.
Further details of the functionality of layers 1, 2 and 3 are described in the context of UMTS below.
Packet based systems
In packet switching, there is no dedicated communication path between the sending and receiving device. Instead, data is broken down into packets and transmitted between network links that are shared by multiple competing communication sessions. Each packet has information that specifies the packet’s destination and how the packet will be reassembled into a whole message when received at its destination. Packet switching is more efficient for communicating some types of data traffic because it allows many users to equally and flexibly share the same set of bandwidth resources. However, a drawback of packet switching is that when the network is busy packets can be delayed. This delay is termed "latency". Too much latency results in poor service quality for certain applications, particularly where real-time interaction is required, for example in voice or video calling.
In third generation ("3G") networks, the information to be transmitted is divided into a voice channel for voice calls and a data channel for other data to be transmitted over the network. The voice channel operates through circuit switching (i.e. a dedicated connection, like a traditional landline call), while the data channel utilises packet switching (in which no dedicated connection is established). The data channel can also be used to carry voice in the case of "voice over IP" or "VoIP".
UMTS overview
Universal Mobile Telecommunication System ("UMTS") is a "third generation" ("3G") cellular communication system based on Wideband Code Division Multiple Access ("WCDMA") radio technology. It was first specified in 3GPP Release 99, which was completed at the end of 1999, and commercial UMTS networks were launched from 2001 onwards.
The Release 99 UMTS system provided voice telephony and basic multimedia services, but significant improvements to the packet switched data service capabilities were enabled by High Speed Downlink Packet Access ("HSDPA") in 3GPP Release 5, completed in September 2002, and High Speed Uplink Packet Access ("HSUPA") in 3GPP Release 6, completed in September 2005. Among other developments, the increased data rates provided by these enhancements enabled the introduction of Voice over Internet Protocol ("VoIP") services.
UMTS network architecture
UMTS network architecture comprises a Core Network, the UMTS Terrestrial Radio Access Network ("UTRAN"), and User Equipment ("UEs") such as mobile telephones, as shown:
Figure 2: Simplified UTRAN architecture
The Core Network manages the switching and routing of calls and data services to their destinations; the UTRAN is responsible for the radio-related functions of the network and provides connectivity between the Core Network and UEs.
Within the UTRAN, the NodeBs are the radio base stations, each of which may support one or more radio cells. The Radio Network Controllers ("RNCs") are the main control nodes. They manage the resources of the NodeBs connected to them and implement
many of the UTRAN protocols, including Radio Link Control ("RLC") and Medium Access Control ("MAC"). The RNC is generally geographically remote from the base station.
UMTS Protocol architecture
A simplified diagram of the protocol architecture in UMTS is below.
Figure 3: Simplified UMTS radio interface protocol architecture
The Control Plane ("C-Plane") represents signalling information from higher layers. The User-Plane ("U-plane") represents user data.
The solid lines represent communication paths operating between the protocol layers. These can be considered as logical communication "pipes" offered by each layer to the layer below which is used to communicate information between peer entities within the network. A variety of these "pipes" is available at each level in the protocol stack, providing a range of communication characteristics suited to different service requirements. They are variously referred to as "radio bearers", "logical channels", "transport channels" and "physical channels" at different points in the stack, as shown.
Within UMTS, the following layers are involved in the interface between the UEs and the UTRAN:
Layer 1 is the physical layer (or "PHY"), responsible for the processing necessary to transmit and receive signals over the radio interface. Typical signal processing functions performed at the PHY include forward error correction ("FEC") and modulation functions.
Layer 2 is the data-link layer. It is the interface between the network and the PHY. Layer 2 contains the RLC and Medium Access Control ("MAC"), as well as Packet Data Convergence Protocol ("PDCP") and Broadcast and Multicast Control ("BMC").
PDCP is a U-plane protocol for packet switched data services. One of the main features of PDCP is header compression.
BMC is a U-plane protocol for handling point-to-multipoint message services.
RLC adapts the data packets of higher layer C-plane signalling and U-plane information into more appropriate sizes for radio transmission and provides a range of transport functions to suit different quality of service requirements. There are generally several instances of the RLC protocol running at any one time, each referred to as an RLC "entity", each configured to meet the needs of different C-plane signalling or U-plane information flows. Depending on the configuration, RLC functions may include segmentation and reassembly, concatenation, padding, data transfer, error correction, in-sequence delivery of data packets, duplicate detection, flow control, sequence numbering, protocol error detection, ciphering and suspend/resume functions. RLC is also responsible for managing retransmissions of data through a scheme called Automatic Repeat reQuest ("ARQ").
MAC is responsible for coordinating access to the Physical Layer for a combination of data flows by managing the timing of when users may send and receive data. It maps data between the Logical Channels above and Transport Channels below and prioritises the allocation of radio resources to different users and services, within parameters set by the Radio Resource Control (‘RRC’). MAC is responsible for selecting the transport format to be used by the Physical Layer in each Transmission Time Interval ("TTI") and informing RLC of the Protocol Data Unit (‘PDU’) sizes to use in each TTI. It can perform ciphering when this is not performed by RLC.
Layer 3 includes the RRC protocol, which is a C-Plane protocol responsible for establishing, modifying and releasing the radio connections needed to carry signalling messages and user data between the UE and the UTRAN. It provides mobility functions to support the movement of user terminals around the network. RRC has overall responsibility for the configuration and control of the other protocols in the architecture.
Control plane signalling and user information to be transmitted flows into Layer 2 from the higher layers before being processed ultimately for transmission over the radio interface at the PHY. Received signals are initially decoded and processed at the PHY before being passed upwards through the stack to the relevant higher layers.
On the network side, the MAC and RLC functions are implemented at the RNC. As the RNC is geographically remote from the base station, the MAC scheduling performed at the RNC cannot instantaneously adapt to changing radio channel conditions between
the base station and the UE when selecting the transport format to use in each TTI. A limited number of fixed transport block size/RLC PDU size choices is therefore adequate for practical operation. Because the RNC also manages the uplink usage, a limited set of transport block size/RLC PDU sizes is also used for transmission from the UE. A more limited set of transport block sizes and consequent RLC PDU sizes also simplifies implementation.
The Role of RLC in UMTS
At the transmitter, the RLC receives data packets known as RLC Service Data Units ("SDUs") and passes on data packets to the MAC, referred to as RLC PDUs. At the receiver, the opposite process takes place, as shown below:
Figure 4: Simple illustration of RLC SDUs and RLC PDUs
RLC PDU sizes
RLC is responsible for packaging variable sized data packets from higher layers (RLC SDUs) into RLC PDUs for onward transmission to the MAC.
The MAC is responsible for scheduling received RLC PDUs over transport channels to the PHY, at regular TTIs. To do so the MAC selects a transport block size (which determines the RLC PDU size) and an associated transport format. There is a limited set of different transport block sizes available to the MAC, depending on how the transport channel was semi-statically configured, and the combinations of concurrent transmissions scheduled in a time interval.
For each TTI the MAC layer indicates to each RLC transmitting entity how many PDUs to prepare and what size they may be, taking into account the amount of data waiting in the corresponding data buffer, its priority relative to other data, and the overall requirements on the radio interface in that TTI. The set of RLC PDU sizes is limited; by virtue of signalling restrictions, only N sizes are available for the MAC for a given bearer, which are semi statically defined during bearer configuration. Limiting scheduler complexity would also bring constraints in the size of the set of PDU sizes to consider at each TTI. For example, in UMTS Release 5 ("HSDPA") the maximum allowed set of PDU sizes is eight.
Segmentation, concatenation and padding
The RLC entity then applies segmentation, concatenation and padding to pack the SDUs it has received into RLC PDUs for onward transmission to the MAC.
Segmentationrefers to splitting an RLC SDU over two or more PDUs.
Concatenationrefers to transmitting two or more SDUs, or segments of SDUs, in the same PDU.
Paddingmay be used to fill spare capacity.
The way in which segmentation, concatenation and/or padding is used depends on the operating mode of the RLC entity in question (see below).
RLC Transport Modes
The RLC protocol defines three types of RLC entities characterised by their modes of operation: Transparent Mode ("TM"), Unacknowledged Mode ("UM"), and Acknowledged Mode ("AM").
TM is the simplest mode. No header information is added to RLC PDUs. TM mode can buffer data and perform simple segmentation and concatenation of SDUs, but only to a limited extent due to the lack of header information. TM incurs minimal overhead and delay, but the receiver cannot know if data packets have been received correctly. TM is suitable for circuit-switched voice telephony and can be used for transmission of short messages such as those sent over the Paging Control CHannel ("PCCH").
UM adds header information to each RLC PDU. This includes a sequence number and further information to enable correct reassembly of SDUs. This facilitates more flexible packaging of SDUs by segmentation, concatenation and padding (see below). In UM there is no acknowledgment of receipt of PDUs by the receiver. UM is suitable for services where there is some limited tolerance for data errors but a need for relatively low delay, such as conversational streaming media (including VoIP).
AM provides segmentation, concatenation and padding in broadly the same way as UM. However, it also provides an error correction mechanism, whereby an AM receiver can request retransmission of PDUs that have been received with errors or not received at all. This provides reliable data transfer, but retransmissions result in delay. AM is suitable for services such as email, file transfer, and web browsing.
In UM and AM modes, the RLC PDU header provides the receiver with information to extract segmented and/or concatenated SDUs from the received PDU.
RLC UM header structure in UMTS
The UM PDU is defined in TS 25.322 section 9.2.1.3. Figure 5 shows its structure.
Figure 5: UM PDU format in TS 25.322 v6.4.0
The length of a UM PDU is always a multiple of 8 bits (commonly referred to as an "octet" or "byte"). Figure 5 shows the series of octets in a PDU from the first octet, "Oct1", at the top to the "Last Octet" at the bottom.
In UMTS the first octet of the header is present in all PDUs. The first octet of the PDU contains a Sequence Number ("SN") and an Extension Bit ("E-bit"). This is followed by zero, one or more Length Indicators ("LI") each with a further E-bit, followed by Data, which may contain one or more SDUs or SDU segments. Padding ("PAD") may also be added. It is also possible that a PDU may contain only padding after the header. Headers contain 'overhead' data meaning that they provide information that facilitates the transmission of payload (user) data, but in doing so they use resources that could otherwise be allocated to payload data.
Sequence Number
The SN is a 7-bit number, which increments for each PDU to identify its position in the overall sequence of PDUs. This helps the receiver to reassemble the SDUs and is used in ciphering operation.
Extension Bit
In UM mode the E-bit can be configured to have one of two interpretations.
In the normal interpretation, introduced in Release 99, the E-bit is set to 0 to indicate that the next field is data, piggybacked STATUS PDU or padding (i.e. the header is not extended) or to 1 to indicate that the next field is an LI and E-bit (i.e. the header is extended).
An alternative interpretation was introduced in TS 25.322 v6.4.0 (June 2005). If the alternative interpretation is used, the E-bit in the first octet is still set to 1 to indicate that the next field is an LI and E-bit, but if the E-bit in the first octet is set to 0, it indicates that the next field is a complete SDU, which is not segmented, concatenated or padded.
The two definitions are summarised in TS 25.322 v6.4.0 as follows:
Which definition is used depends on the configuration set by higher layers.
The use of the alternative E-bit in a case where the PDU is exactly filled with a single complete SDU is shown below.
Figure 6: Use of the alternative E-bit where E=0 indicates that the PDU contains a single complete SDU
Length indicators
Section 9.2.2.8 of TS 25.322 v6.4.0 describes the use of Length Indicators as defined in the UMTS standard. The relevant section is set out in Annex 1, to which I have added certain annotations indicated in italics, which are explained below.
Data
The Data field may contain one or more RLC SDUs and/or segments of SDUs, which may be concatenated to avoid unnecessary padding. The lengths of RLC SDUs are always a multiple of 8 bits.
Padding (PAD)
Any unused space at the end of a PDU is referred to as padding. Padding may have any value and the receiver and sender disregard it. Padding is defined in TS 25.322 section 9.2.2.10.
VoIP
VoIP refers to various technologies used to carry voice telephony (and other media) over Internet Protocol (IP) networks, such as the Internet.
First generation cellular networks were designed and deployed to offer a reliable mobile voice service. The circuit-switched voice techniques used in the cellular network at the time guaranteed quality of service ("QoS") by virtue of radio resource reservation for the duration of the call. This circuit-switch paradigm endured in the design of thirdgeneration systems, which optimised voice capacity through coded channel resources, again allocated for the duration of the calls.
By August 2005, communication equipment vendors and standard development organisations were driving the industry towards packetised voice techniques that offered more flexibility and lower equipment costs than circuit-switched technology.
VoIP services are carried by packet-switched connections. Voice signals are encoded as a series of data packets (e.g. every 20ms), each of which is given its own IP header information and routed independently through a packet-switched network. In contrast to circuit-switched voice, the VoIP packets allow to flexibly intermix the voice information with other types of data traffic, such as internet traffic. By foregoing the paradigm of reserved specialised radio resources for the whole duration of calls, VoIP can help optimise the sharing of the radio spectrum with data services.
In the early 2000s, there was increasing interest in extending VoIP to mobile networks, in order to achieve similar benefits. However, the voice capacity (i.e. the number of active calls at a given time) of VoIP was often lower than the voice capacity of circuit switched ("CS") voice over the UMTS systems available in 2005. The limited capacity and significant latency (delay) of packet-switched data services in mobile networks were constraints. The carriers were hesitant to abandon circuit-switched technology, as mobile cellular data services were still commercially insignificant relative to voice services.
In UMTS, the improved capacity, data rate and latency of HSDPA (defined in 2002) and HSUPA (completed in September 2005) were significant steps towards making VoIP a realistic service in UMTS. Network operators were interested in launching VoIP services based on a service architecture known as IP Multimedia System (IMS). However, it would take many years to see wide commercial adoption of Wireless VoIP and the 3GPP IMS voice framework (aka "VoIMS") in particular and it was not widely deployed as at August 2005.
Encoding voice signals into IP packets produces speech frame packets of generally equal size at equal time intervals.
The IP protocol adds relatively large headers to the speech packets. The PDCP layer (see above) uses an algorithm called Robust Header Compression ("ROHC") to compress the packet headers. This results in data packets of variable size, and in turn a stream of RLC SDUs that can have different sizes. The possible sizes are limited to a known set of sizes each having a different frequency of occurrence. The Skilled Person would be aware of this, without necessarily being aware of the exact relative frequency of occurrence of different size SDUs.
VoIP services require low delay but they are tolerant to occasional errors in transmission. The most appropriate choice for VoIP transmission in UMTS is RLC UM.
LTE
The concept for developing a successor to UMTS (to be marketed as Long Term Evolution ("LTE")) emerged at the end of 2004, with plans to develop an improved radio protocol based on Orthogonal Frequency Division Multiplexing ("OFDM").
Preliminary study items had begun under Release 7 in 2005, but specification work had not yet begun. The Skilled Person would have been aware that early concepts for LTE had been discussed and would have been following its development, but would know that specification work had not begun and that the technical details were not yet defined.
Additional points of CGK
Although the following points were not set out as agreed CGK, I find that they also comprised part of the Skilled Team’s CGK:
First, the Skilled Team would be aware that, in GSM/GPRS, length indicators had 6 bit values. Since UMTS used length indicators of 7 or 15 bits, the expectation for the next generation (i.e. 4G or 3.9G, as mentioned in the Patent), which would involve greater quantities of data, was that the size of length indicators would be likely to increase.
Second, the Skilled Team would know that, in UMTS, the set of PDU sizes were set per session and typically a session would last for the duration of a voice call.
The Patent
In line with its title (set out above), the Patent defines the Field of the Invention in [0002] as relating to optimizing radio link control unacknowledged-mode protocol data unit headers, for example, to better support packet switched voice transmissions or transmission of other real time packet switched services over Wideband CDMA air interface.
In [0003] and Figure 1a, the Patent sets out the results of an experiment which measured the distribution of RLC SDU sizes for a 12.2 kbit/s adaptive multi rate (AMR) voice codec. It explains that the voice codec itself produces equal sized packets but a robust header compression (ROHC) produces variable size SDUs. Re-ordering the most significant sizes (i.e. all those above 1%) in Figure 1a gives the following exampledistribution which happens to reflect the eight PDU sizes which were permitted in UMTS Release 5:
RLC SDU size | Percentage of total SDUs |
35 | 76.18% |
10 | 4.48% |
38 | 4.32% |
13 | 3.99% |
14 | 3.73% |
39 | 2.93% |
36 | 2.46% |
37 | 1.09% |
[0003] suggests that to optimize the RLC overhead, the following RLC PDU sizes could be selected: 11, 15, 36, 40 and 98, with 36 and 11 being used for the most frequent RLC SDU sizes (the Skilled Person would understand this would entail the use of the alternative E-Bit), but it notes that there are quite significant amounts of RLC SDUs of 13 and 38 octets which are 2 octets smaller than the RLC PDU sizes of 15 and 40 octets. The Skilled Person would understand that this paragraph is talking about trying to match the RLC PDU sizes so they accommodate the variety of SDU sizes and relevant header information as efficiently as possible.
[0004] continues this focus on the ‘2 octets smaller’ situation:
For a RLC SDU which is two octets smaller than the RLC PDU, the beginning of the RLC SDU is indicated with special length indicator (LI), where LI=1111100 or LI=0000000 if the previous RLC SDU was also two octets smaller than the RLC PDU. Therefore, there is no room to indicate the end of the RLC SDU and that has to be indicated in the next RLC PDU with LI=0000000. As such, if the next PDU is lost, a receiver cannot be sure whether the RLC SDU was completely there or not.
Paragraphs [0005]-[0009] sit under the heading Summary of the Invention. It is only necessary to refer to paragraph [0005] which concerns the method. After correcting an error, paragraph 0005 reads as follows:
An embodiment of the present invention is directed to a method including inserting, in an unacknowledged mode entity of a radio link control, at least one service data unit to a protocol data unit of an appropriate size. The method also includes providing at least one indicator for defining boundaries between the at least one service data unit within the protocol data unit, the at least one indicator including a length indicator for indicating that a first data octet of the packet data unit is a first octet of a first service data unit and at least one other octet of the packet data unit is the last octet of another service data unit, the first service data unit being either the same or different from the other service data unit.
Both at the beginning (in [0011]) and the end (in [0053]) of the Detailed Description, the patentee is at pains to emphasise that, whilst the preferred embodiments are described in a WCDMA-type system (UMTS), the invention may be implemented in other systems ‘such as in 3.9G systems’. Thus, the patentee clearly signalled that the invention may be implemented in the forthcoming 4G system, depending on how it was configured.
Having made that point, the Detailed Description continues with a couple of paragraphs which set the scene, describing RLC, UM, AM and TM modes and their roles in transmissions between sender and receiver. I will quote [0014]-[0018] because they are important in understanding how the term ‘length indicator’ is used in EP142 (emphasis added):
[0014] In UM entity 104, unacknowledged mode data (UMD) PDU is used to convey sequentially numbered PDUs that include RLC service data units (SDU) data. UMD PDUs are used by the RLC when it is configured for unacknowledged data transfer. The transmitting UM entity 104 receives RLC SDU from upper layers through the UM Service Access Point. The transmitting UM entity 106 segments the RLC SDU into UMD PDUs of appropriate size, if the RLC SDU is larger than the length of available space in the UMD PDU. The UMD PDU may include segmented and/or concatenated RLC SDUs and may also include padding to ensure that it is of a valid length. Length indicatorsare used to define boundaries between the RLC SDUs within theUMD PDU, unless an extension bit already indicates that a UMDPDU includes exactly one complete SDU. The length indicatorsare also used to define whether padding is included in the UMDPDU. If ciphering is configured and started, an UMD PDU is ciphered, except for the UMD PDU header, before it is submitted to the lower layer. The transmitting UM entity 104b submits UMD PDUs to a lower layer.
[0015] The receiving UM entity 104a receives UMD PDUs through configured logical channels from the lower layer. If the receiving UM entity 104a is configured for out of sequence SDU delivery, it will reassemble SDUs and transfer them to the upper layers as soon as all PDUs that include the SDU have been received, even if the earlier PDU have not yet been received. UM entity 104 stores the PDUs pending the retransmission of the missing PDU by the transmitting UM entity 104a. PDUs are removed from storage after recovery of all of its associated SDUs, or by a sequence number window or a storage timer.
[0016] The RLC PDU is a bit string. Depending on the service provided, the RLC SDU is also a bit string with any non-null length or a bit string with a multiple of 8 bits in length. The RLC SDU is included into the RLC PDU from the first bit onward. When the RLC is operating in the unacknowledged mode, the UMD PDU is used to transfer user data. The length of the data in the unacknowledged mode will be a multiple of 8 bits. TheUMD PDU header includes a first octet which includes asequence number and all other octets that include lengthindicators. In addition to the sequence number, the first octet ofUMD PDU may also include an extension bit (E-bit) that haseither a normal E-bit interpretation or the alternative E-bitinterpretation, depending on higher layer configuration. The extension bit in all other octets of the UMD PDU always has the normal E-bit interpretation. The UMD PDU also includes aheader extension type that indicates if the next octet is data or alength indicator and E-bit.
[0017] Unless the extension bit indicates that a UMD PDUincludes a complete SDU which is not segmented, concatenatedor padded, the length indicator is used to indicate the last octetof each RLC SDU ending within the PDU. If the extension bit indicates that the UMD PDU includes a complete SDU which is not segmented, concatenated or padded, no length indicators are present in this UMD PDU.
[0018] The length indicator is set to the number of octetsbetween the end of the RLC header and up to and including thelast octet of the RLC SDU segment. The length indicator isincluded in the PDUs to which they refer and the size of thelength indicator may be either 7 bits or 15 bits. The length indicator size is determined independently for uplink and downlink. The length indicators which refer to the same PDU arenot to be reordered in case of retransmission and are to be in thesame order as the RLC SDUs to which they refer. Forunacknowledged mode uplink, if the largest uplink UMD PDUsize is 125 octets, 7-bit length indicators are to be used,otherwise, 15-bit length indicators are to be used. Forunacknowledged mode downlink, the length indicator sizeprovided in the "downlink RLC unacknowledged mode lengthindicator size" are to be used.
[0019] is a long paragraph which is difficult to follow because it contains long sentences with many sub-clauses. Furthermore, as the experts eventually agreed, in two places
‘not’ was missing, contributing to the difficulty. Although neither expert pointed this out, a number of paragraphs in the Patent are taken from the standard sometimes with slight editing. Thus [0017] reproduces the first paragraph of section 9.2.2.8 (see Annex 1) and [0018] essentially reproduces the next section. With this in mind, the odd structure of [0019] is explained – [0019] is based on (with some rearrangement) the part of section 9.2.2.8 indicated in Annex 1. Also as indicated in Annex 1, [0020][0023] and [0025] are also based on that section of the standard.
I will return to discuss [0024] a little later, due to the proposed amendments to the specification which seek to take the embodiments described in that paragraph outside the scope of the Patent.
[0026] and [0027] return to the ‘two octets smaller’ discussion and there is no dispute that these paragraphs describe embodiments of the invention.
[0026] In an embodiment of the present invention, the receiver knows in the case where the RLC SDU size is two octets smaller than the RLC PDU size, that the RLC SDU begins and ends in this RLC PDU and can deliver the SDU to higher layers, even if the next RLC PDU is missing. This is especially important in the case of real time packet switched services, like VoIP. All the RLC SDUS that fit into one RLC PDU, that is, they do not require segmentation, can immediately be forwarded to higher layer without the need to wait for the next RLC PDU which may further be delayed for instance due to scheduling. Thus, this can reduce the delay of the RLC SDU, for example, a VoIP packet.
[0027] According to an embodiment of the invention, in the case where the RLC SDU is two octets smaller than the RLC PDU and happens to be the last SDU in a sequence, an additional PDU can be avoided. In a first embodiment of the present invention, the meaning of the special length indicator value 1111100 is changed to indicate that the RLC SDU starts and ends in this RLC PDU. The special LI value of 0000000 is used to indicate for unacknowledged mode that new SDU starts at the beginning of the PDU. The details are shown in the following tables.
In discussing the ‘two octets smaller’ situation, [0026] highlights two advantages resulting from the fact that the receiver has all the information required so that it does not need to wait for the next PDU and can send the data payload immediately up to the next layer. The first advantage is that the payload of this PDU is not affected if the next PDU is lost. The second is that delay is reduced because the payload can be delivered immediately without having to wait for the next PDU to arrive. [0027] draws attention to a further advantage: if the last SDU in the PDU is the last in a sequence, the sending of an additional PDU is avoided. These three advantages are equally applicable whether the PDU contains a single SDU or multiple complete SDUs.
The tables which follow [0027] are based on the tables in the standard but to aid the Skilled Person, the amendments to the standard are shown in underline.
It becomes clear that the rest of the detailed description describes three embodiments of the invention which differ only in the particular special length indicator value that is used to indicate both the start and end of an RLC SDU:
Embodiment | Special Length Indicator to indicate start and end of an SDU | Paragraphs and Figures |
First | 1111110 | [0027]-[0029], [0037]-[0038] Figs 1-2 |
Second | 0000000 | [0030], [0039]-[0043] Figs 3-7 |
Third | 1111101 | [0031]-[0033] [0044]-[0048] Figs 8-12 |
It is not necessary to set out all the figures. In general, each of figures 1-12 contains a comparison. On the left, in Column A, PDUs and SDUs of particular sizes are shown in a system without the benefit of the invention. Column B, on the right, shows what happens in a system with the invention. Figure 1 is captioned ‘Sequence of RLC UM PDUs showing the usage of LI, RLC PDU size of 39 octets and RLC SDU sizes of 38 or 37 octets’ and, with the arrows enhanced by Dr Brydon, looks like this:
In the top row, both Column A and B illustrate the use of the alternative E-bit, where E=0 indicates that the PDU contains a single complete SDU which is not segmented, concatenated or padded. In the second row, Column B shows the special length indicator 1111100 of the Patent indicating that the first data octet of the PDU is the first data octet of an SDU and the last octet of the PDU is the last octet of the same SDU (this is an example of the single SDU embodiment). The same is shown in the bottom row, Column B. These contrast with column A where for PDU SN+1, the receiver has to wait to receive PDU SN+2 to receive the indication (LI=0000000) that the SDU in PDU SN+1 ended in that PDU. As Dr Brydon explained, the use of LI=0000000, in conjunction with the absence of any padding indicator in the next octet, implicitly indicates that the first data octet of PDU SN+2 is the first data octet of an SDU. Although not shown in figure 1, the end of the SDU in PDU SN+2 has to be indicated once again in PDU SN+3.
Figure 2, which I need not set out, shows what happens when RLC PDUs of 39 octets carry SDUs of 36, 35 or 34 octets. In those scenarios, Columns A and B are the same, showing that the invention has no application.
Figure 3 shows essentially the same as Figure 1 where the special length indicator of the invention is LI=0000000. Figure 4 again shows that the special length indicator is not used, in the same scenarios as in Figure 2. Figure 5 shows what happens if PDU SN carries the last but complete SDU of a data burst. With the benefit of the invention, Column B features only one PDU (of 39 octets) carrying the complete SDU of 37 octets with the header carrying the SN, E=1, LI=0000000 and E=0, whereas Column A has to include a complete second PDU which contains LI=0000000 to indicate that the last octet of PDU SN was the last octet of an SDU, and then LI=1111111 to indicate that the rest of PDU SN+1 is padding.
A comparison of Figures 5 and 6 shows that when the patent is discussing, for example, the second embodiment, it is not describing a single system. Rather in that embodiment it is illustrating how the value 0000000 can be repurposed in different ways. In Figure 5 that value indicates that the PDU is exactly filled with a single SDU which starts and ends in the PDU whereas in Figure 6 that value provides a different indication. As it says in [0042] ‘Here, the special length indicator=0000000 indicates that one SDU starts and another ends in this PDU…’ There has been no suggestion that a single value in a system would be able to convey two different indications.
In more detail, Figure 6 shows RLC PDUs of 74 octets carrying two RLC SDUs. In Column B, all the information required to unpack PDU SN is included, whereas in Column A, the end of the last SDU has to be indicated in PDU SN+1. Figure 7 shows what happens when the first SDU (of 40 octets) is segmented between PDUs (of size 39 octets), followed by SDUs of 34 and 37 octets. PDUs SN and SN+1 are the same in both Column A and B. The benefit of the invention comes in PDU SN+2, where the special length indicator of the invention (in this second embodiment LI=0000000) indicates explicitly that the last SDU of 37 octets is completely carried by PDU SN+2 without padding (and implicitly indicates that the last octet of PDU SN+1 was the last octet of the last SDU in that PDU). By contrast, in column A, although PDU SN+2 carries a complete SDU of 37 octets, the receiver will have to wait for PDU SN+3 before receiving an indication that the last octet of that SDU was the last octet of PDU SN+2.
For the third embodiment, Figure 8 is equivalent to 1 and 3, Figure 9 is equivalent to 2 and 4, Figure 10 is equivalent to Figure 5, 11 to 6, and 12 to 7.
Overall, the figures demonstrate the benefits of the invention in particular situations but also that it has no application in others.
The Claims
The claims divide into sets of method and apparatus claims, plus a ‘computer program’ claim. It suffices to deal only with the method claims.
Claim 1 as granted reads as follows:
A method comprising: inserting, in a radio link control, RLC, entity, at least one service data unit, SDU, to a protocol data unit, PDU, of an appropriate size; characterized in that it further comprises: providing at least one indicator including a length indicator for indicating that a first data octet of the protocol data unit , PDU, is a first octet of a first service data unit and at least one other octet of the protocol data unit, PDU, is the last octet of another service data unit, the first service data unit being either the same or different from the other service data unit, wherein the at least one other octet is the last octet of the protocol data unit, PDU.
Indications as to the possible breadth of claim 1 as granted are given by the additional limitations in subsidiary claims:
Claim 2 expressly limits the RLC entity to UM mode; ii) Claim 3 limits the length indicator to 7 or 15 bits;
Claims 4, 5 and 6 relate to the specific values cited in the three embodiments: 0000000, 1111100 and 1111101 respectively, however claims 4 and 5 specify that the first SDU is ‘the same or different from the other SDU’ (as in claim 1), whereas claim 6 relates only to the case where it is the same SDU (i.e. the RLC PDU contains a single complete SDU).
The remainder of the method claims are split between the single and multiple SDU embodiments.
The proposed amendments
The patentee applies unconditionally to amend EP142. In the specification, it is proposed to insert a new [0018A] ‘Paragraphs [0019] to [0021] and [0024] below describe embodiments not in accordance with the claimed invention.’ Consistently with that, the words ‘an embodiment of the invention’ are deleted from the start of [0024].
For the claims there are two proposed requests. I will set out Request 1 as broken down into integers by the Claimants, in which Integer R1(e) is the proposed addition:
Request 1 | |
R1[a] | A method comprising: inserting in a radio link control, RLC, entity, at least one service data unit, SDU, to a protocol data unit, PDU, of an appropriate size; |
R1[b] | characterized in that it further comprises: providing at least one indicator including a length indicator for indicating that a first data octet of the protocol data unit , PDU, is a first octet of a first service data unit and at least one other octet of the protocol data unit, PDU, is the last octet of another service data unit, |
R1[c] | the first service data unit being either the same or different from the other service data unit, |
R1[d] | wherein the at least one other octet is the last octet of the protocol data unit, PDU,. |
R1[e] | and wherein the last octet of the PDU can be the last octet of the same SDU which startsin the PDU or the last octet of a different SDU. |
In Request 2, the amendments proposed to claim 1 are more extensive:
A method comprising: inserting, in a radio link control, RLC, entity, at least one service data unit, SDU, to a protocol data unit, PDU, of an appropriate size; characterized in that it further comprises: providing at least one indicator including a length indicator for indicating, if the protocol data unit, PDU, includesonly one service data unit, that a first data octet of the protocol data unit, PDU, is a first octet of a first service data unit and at least one other octet of the protocol data unit, PDU, is the last octet of another service data unit, the first service data unit being either the same or-different-fromas the other service data unit, wherein the at least one other octet is the last octet of the protocol data unit, PDU,
and wherein, if the protocol data unit, PDU, includes severalservice data units, said length indicator indicates that a first dataoctet of the protocol data unit, PDU, is a first octet of a firstservice data unit and at least one other octet of the protocol dataunit, PDU, is the last octet of another service data unit, the firstservice data unit being different from the other service data unit,wherein the at least one other octet is the last octet of the protocoldata unit, PDU.
In both requests, original method claims 6, 7, 9, 10, 11, 12 are proposed to be deleted because, it is said, they cover ‘the single SDU embodiment’ i.e. where the indicator indicates that the first data octet of the PDU is the first octet of an SDU and the last octet of the PDU is the last octet of the same SDU. Corresponding changes are made to the apparatus claims. As far as I am aware, this is the only real explanation given for the proposed amendments: the patentee wishes to remove from the scope of the invention the so-called ‘single SDU embodiment’.
The Claimants submit that the combination of integers R1(b), (c) and (e) specify that the length indicator of the claim must be for indicating the case where the first data octet of the PDU is the first octet of an SDU and the last octet of the PDU is the last octet of an SDU for any number of SDUs in the PDU. Whether this submission is correct is a point I address later.
The alleged infringement
Although it is well established that the alleged infringement cannot be allowed to influence the interpretation of the claims in the Patent, in the circumstances of this case it is instructive to have the alleged infringement in mind in order to detect whether the alleged infringement is illegitimately influencing the arguments on claim scope.
The approach taken to RLC PDUs in LTE has a number of similarities but also some differences to the approach taken in UMTS. The most significant difference of all is that in LTE there is no constraint of a set of fixed PDU sizes for a given session. Instead, LTE uses fully flexible PDUs such that every PDU can be shrink fitted to the SDU payload.
With that point in mind, the other differences and similarities are best illustrated by reference to one of the basic structures of an RLC PDU in LTE in which a 5-bit sequence number is used. A 10-bit SN can also be configured, but the difference is not material.
The fixed part of the UMD PDU header is the first octet. It starts with the 2-bit Framing Indicator, FI field, followed by a single E-bit, and a 5-bit Sequence Number, SN. In the optional part of the header there then follows pairs of a single E-bit with a 11-bit Length Indicator LI. Because each LI is longer than 8 bits, each LI occupies more than one octet and if there are an odd number of LIs, 4 bits of padding must be included at
the end of the header, as illustrated. Thus, the only use of padding in LTE is at the end of the header. Padding is never needed at the end of the data payload, because the PDU is automatically fitted to the payload, which is always a whole number of octets.
The LTE specification defines the FI field as follows:
It is common ground and/or not disputed but in any event I find that:
the elements labelled LI above (length indicators) perform the same role in LTE as ordinary length indicators in UMTS; ii)there are no special length indicators in LTE as such;
the role of the special length indicators in UMTS has essentially been taken on by the various values of the FI field in LTE.
The E-bit field has reverted to something akin to its normal interpretation in UMTS – the precise meanings are different because the E-bit can be in the fixed or the extension part of the header and precedes the SN or LI, but what matters for present purposes is that there is no equivalent of the alternative E-bit interpretation in LTE.
The Claimants’ infringement case relies on the FI=00 value when inserted into the FI field. The Claimants allege that:
The FI=00 value is a length indicator on the proper construction of that term in claim 1 of the Patent. The case is advanced on the basis that the FI=00 value is an element in the PDU header that provides control information describing thepayload, which allows the receiving entity to separate the RLC SDUs contained in the data part of the PDU (my emphasis). Thus, the Claimants allege, it has all the characteristics of what a Skilled Person would understand by a ‘length indicator’ in claim 1.
In the alternative, if the FI=00 does not infringe on a normal interpretation, the Claimants allege that the Actavis questions must be answered: 1: yes; 2: yes; and 3: no, so the FI=00 value infringes on the basis of equivalents.
Claim Scope – relevant legal principles
I remind myself of the following principles:
Assessment of the scope of protection of a patent claim involves two separate steps – Actavis v Eli Lilly [2017] UKSC 48 at [54];
The overall process is best described as ascertaining claim scope, since it is only the first of the two steps that concerns claim construction – Fisher & Paykel Healthcare [2017] EWHC 2748 at [75], Richard Meade QC (as he then was).
As to the first step, the applicable principles for normal or purposive construction are those set out in Kirin-Amgen [2005] RPC 9 at [27]-[35], and Icescape Ltd v Ice World International BV [2018] EWCA Civ 2219 at [60].
As to the second step, in order to address whether there is infringement by equivalence, it is necessary to address the three Actavis questions:
Notwithstanding that it is not within the literal (that is to say, I interpolate, normal) meaning of the relevant claim(s) of the patent, does the variant achieve substantially the same result in substantially the same way as the invention, i.e. the inventive concept revealed by the patent?
Would it be obvious to the person skilled in the art, reading the patent at the priority date, but knowing that the variant achieves substantially the same result as the invention, that it does so in substantially the same way as the invention?
Would such a reader of the patent have concluded that the patentee nonetheless intended that strict compliance with the literal meaning of the relevant claim(s) of the patent was an essential requirement of the invention?
For the purposes of the Actavis questions, the court should focus on ‘the problem underlying the invention’, ‘the inventive core’ or ‘the inventive concept’ – Actavis at [60].
I also bear in mind the following two citations. First, the reminder by Floyd LJ in Icescape at [97]:
It should not be thought, however, that the claims do not continue to have an important function. It is variants from the claim which have to achieve substantially the same effect in substantially same way as the invention. The claims remain the starting point for the subsequent analysis of variants. Although we may have edged closer to it, the new approach does not transgress the second of the outlawed approaches in the Protocol, which treats the claim merely as a somewhat vague guideline.
Second, HHJ Hacon’s observation about the third question in Regen v Estar Medical Ltd [2019] EWHC 63 at [224]:
The third Improver question requires the court to consider whether the relevant integer, that corresponding to the alleged equivalent, would have been regarded by the skilled person as an essential part of the inventive concept. It is clear from Lord Neuberger's judgment that having done so, it is possible for the court to reach a view that even though the language of the claim does not on any sensible reading cover the variant, this is not of itself enough to justify answering yes to the third question.
Although consideration of the inventive concept or the problem underlying the invention is directly relevant when considering the first Actavis question, in the circumstances of this case, I consider it is sensible for me to review the parties’ contentions on these points before I embark on the process of assessment of claim scope.
The characterisation of the invention
In this case a great deal of effort was expended on each side on trying to formulate and support a characterisation of the invention with an eye on both normal interpretation and equivalents. In this context, the arguments were directed to the claims as proposed to be amended. For the purposes of analysis I will assume that claim 1 as amended is limited to the situation where the first octet of the data part of the PDU is the first octet of an SDU and the last octet of the PDU is the last octet of an SDU which may be the same as the first SDU or a different SDU. I will consider later whether the proposed amendments actually succeed in achieving that limitation. Reverting then to the arguments, they evolved, with the principal steps being as follows.
For their part the Defendants characterised the invention as solving the ‘N+1 problem’ where N is the number of SDUs in the PDU, but the total size of the combined SDUs is N+1 octets smaller than the PDU. This concept emerged in Dr Royer’s first expert report. It seems to me that this is just another way of describing the ‘two octets smaller’ situation specifically addressed by the Patent. In [0004] the ‘two octets smaller’ problem to which the Patent was addressing itself involved a single SDU so that N=1, but, say, the SDU was 37 octets long and the PDU was 39 octets long. As I have mentioned, [0026] describes the benefits of the invention in the ‘two octets smaller’ situation for both a single SDU and multiple complete SDUs in the PDU.
The Claimants responded in four ways:
First, in Dr Brydon’s reply report, with the notion that the Patent provides a more compact way of indicating ‘perfect packing’, irrespective of the number of complete SDUs in the PDU.
Second, in the course of the trial, the Claimants contended that the advantages of the invention were not limited to the ‘N+1 situation’ but extended more broadly. Hence they accused the Defendants of missing the point of the invention.
Third, and again in the course of the trial, the Claimants fastened on the ‘2 becomes 1’ argument – a shorthand for the invention only requiring 1 length indicator where otherwise 2 would be required, yielding a saving of one octet and greater efficiency.
Fourth, the Claimants put to Dr Royer, the Defendants’ expert, the following illustration in X1-1:
The final nuance came from the Defendants’ expert during his cross-examination on Day 4 when he characterised the invention as ‘the length indicator technique’. Although the Claimants poured scorn on this in their Closing Submissions, this was just another shorthand and, in my view, did not affect the arguments one way or the other.
It is convenient to deal with the X1-1 point first. Although I note that Dr Brydon did not give any evidence about X1-1, the illustration was put to Dr Royer. As I understand matters, the purpose of X1-1 was to counter the Defendants’ argument that a ‘length indicator’ (as that term is used in claim 1) could not be positioned in the header before the first E-bit i.e. in the fixed part of the header. The Defendants responded to X1-1 by contending it was artificial. It is not necessary for me to reach any concluded views about X1-1 because, as appears below, I have been able to form a view on interpretation which bypasses this particular dispute.
Leaving aside the X1-1 issue, all the other points seem to me to be different ways of characterising the same thing: that the benefits of the invention can be achieved in certain circumstances, depending on the available sizes of PDU.
I will say a little more about the Claimants’ first and second points.
‘perfect packing’
The phrase ‘perfect packing’ is more than a little dangerous as a shorthand for the invention. As an expression, it covers more than just the invention:
First, it embraces the solution provided by the alternative E-bit, as shown in the top rows of Figures 1 and 3 of the Patent:
Second, it embraces situations where the special length indicators of the Patent are not used at all. Take the N+2 scenario, where N is again the number of complete SDUs in the PDU. The PDU is always ‘perfectly packed’ but without using the special length indicator values in the patent. This is shown in the case of 2 SDUs (both 35 octets) in PDU SN+1 (of size 74 octets) with three LIs in the header at the bottom of Fig 6 Col B. The top row of Fig 4 Col B illustrates the point for the situation with one SDU:
‘more than just ‘N+1’’
The Claimants’ argument has validity in the sense that if you can adjust the sizes of the set of PDUs, there may be more opportunities to secure the ‘2 becomes 1’ saving and other benefits of the invention. This can be illustrated in two ways:
If one takes the distribution of PDU sizes in Figure 1a of the Patent, the Skilled Person would notice the cluster of SDU sizes of 35, 36, 37, 38 and 39 and then 10, 13, 14. If PDU sizes of 37, 38, 39, 40 and 41 plus 12, 15 and 16 were available in the relevant session, then the benefit of the invention could be achieved in a very high percentage of PDUs (perhaps approaching 99%) in that particular system operating in accordance with that sample.
The Claimants were keen on emphasising that in a system with flexible PDU sizes (such as LTE) the implementation of the invention would save an octet (and provide the other benefits) for every PDU and would give that benefit (and the other benefits) 100% of the time.
These two examples do not change the nature of the invention but they further illustrate how the invention applies in particular circumstances, a point made in the Patent itself. It remains to be seen how, if at all, this characterisation and these examples impact on the claim scope issues.
The problem underlying the invention
The specification makes it clear that the problem the Patent is addressing is the situation where the one or more complete SDUs are two octets smaller than the PDU. In a prior art UMTS type system, the RLC PDU UM header would contain two octets: the first being the SN and E-bit and the second being the ordinary length indicator 1111100 to indicate that the first data octet in this RLC PDU is the first octet of an RLC SDU. There would then be no room for the further ordinary length indicator to indicate that the last octet of the or the last SDU was the last octet of the PDU. So the current PDU would have to be followed by another PDU which would signal, using 0000000, that the last octet of the previous PDU was the last octet of an SDU.
The invention changes the meaning of the special length indicators to solve this problem. Taking the first embodiment as an example, the meaning of the special length indicator 1111100 is changed to indicate that the first data octet in this RLC PDU is the first octet of an RLC SDU and the last octet in this RLC PDU is the last octet of an RLC SDU (same or different SDU). The consequence is that all the information required by the receiver to unpack and process the data in the PDU is contained in that PDU. This has three advantages:
First, the receiver can send the data payload to the next layer immediately without having to wait for the next PDU to arrive, thereby reducing latency;
Second, if the next PDU is lost in transmission, the receiver does not have to deal with the situation where it does not know whether the or the last SDU in this PDU was complete or not;
Third, there is a saving of one octet because one length indicator does not need to be sent, giving an efficiency advantage.
The Skilled Person would notice immediately that this is a solution to a particular problem. It is only useful and can only be used when the ‘two octets smaller’ situation happens to arise. The figures in the Patent make this point very clearly because Figures 2, 4 and 9 show situations where the patented solution is not used. As another example, take the situation where the alternative E-bit is configured and set to indicate that the RLC PDU contains a complete SDU which is not segmented, concatenated or padded. No length indicators are required and the SDU is one octet smaller than its PDU. In that particular situation, the alternative E-bit produces the same set of advantages as the invention.
The inventive concept
The Claimants approach the Actavis questions on the basis of the following characterisation of the inventive concept of EP 142:
The inventive concept is the use of a single length indicator to indicate the condition where there is perfect packing in a PDU, for any number of SDUs in a PDU. It thus provides - by one length indicator - information about the start of the PDU and the end of the PDU.
The Claimants further point out that, although it was possible in the existing UMTS standard to convey information identifying the "perfect packing" condition using length indicators, to do so required at least two length indicators: one to identify that the beginning of the first SDU was at the beginning of the PDU, and a second to identify the end of the last SDU in the PDU. The invention thus provides a more compact, efficient way of telling the receiver that for a PDU which contains complete SDUs, those SDUs are complete and can be extracted for processing by a higher layer.
It will be noted that the Claimants’ formulation of the inventive concept uses the term
‘single length indicator’ to exclude the alternative E-bit situation, which otherwise provides information about the start and end of the SDU in the PDU, and also saves the inclusion of an octet.
The Defendants characterise the inventive concept very much in terms of the problem addressed by the Patent: how to indicate when the first octet of an SDU is the first data octet of a PDU and the last octet of the PDU is the last octet of an SDU when there is insufficient room for two ordinary length indicators to provide that information. They go on to submit that the inventive concept is bound up with using what they term the ‘length indicator technique’: this is the idea of using length indicators to indicate specific information, by which I think the Defendants mean ‘structure information’ and not the meaning of an ordinary length indicator.
Claim scope – normal construction
I do not set out the principles from Kirin-Amgen. Although I have them clearly in mind, to set them out would only unnecessarily lengthen this judgment.
The issues of normal interpretation all reside in this phrase in claim 1: ‘an indicator including a length indicator for indicating’. Before tackling the key issue which concerns ‘length indicator’, it is convenient to make a few preliminary observations. The first concerns the last two words ‘for indicating’. In the usual way, this means that the length indicator must be suitable for conveying the information specified in the claim. Second, neither side made any particular observations about the slightly clumsy phrase ‘an indicator including a length indicator’ aside from their main submissions as to the meaning of ‘length indicator’. However, it is clear (and I find) that the method of claim 1 requires a single length indicator. Third, it can be seen from the specification that the meanings of the special length indicators for AM PDUs does not change. This is consistent with the title of EP142, even though claim 1 is not explicitly limited to UM.
length indicator
Each side put forward their contentions on construction in terms of the functions that a length indicator performs. The rival contentions were as follows.
For their part, the Claimants contended that the Skilled Person would have understood length indicators to be those parts of the header that provide control information todescribe the payload (i.e. data) portion of the PDU (my emphasis), and the arrangement of the SDUs within it. They allow the receiving entity to separate the RLC-SDUs contained in the data part of the PDU. In some cases they do so by identifying the boundary of a specific SDU in the PDU and in other cases they provide some additional information about the structure of the payload.
In essence, the Defendants submit that the term ‘length indicator’ should be given the meaning it had in the CGK. As to precisely what that meaning was, as I understood the Defendants’ case, the primary function of a length indicator is to be used in the extension part of the header to indicate the size of each SDU (and so the boundaries between SDUs) in a PDU. To perform this function, length indicators included sufficient bits to be able to indicate the maximum length indicator value to be indicated in binary form. The Defendants go on to submit that it was also commonly known that certain predefined values in the length indicator field could be used for a secondary or ‘dual’ purpose of indicating other specific information when needed.
As can be seen, both contentions were quite elaborate – and to a certain extent each one reflected the arguments which the party in question wished to run on other aspects of the case.
Analysis
Bearing in mind the purpose of a PDU is to carry SDU payload (whether the SDUs contained within it are complete or segmented), when an RLC PDU arrives at the relevant level of the receiver, the receiver needs to know how the various SDUs or SDU segments are packed in the PDU or PDUs, so that it can separate out each SDU and send each one for further processing in the next layer.
For the purposes of analysis I will use the umbrella term ‘structure information’ to encompass all the different types of information the receiver uses to unpack SDUs from PDUs. In the context of the Patent, structure information was conveyed in the following ways:
First, there are the ordinary length indicators. These indicate the position in the PDU of the final octet of a particular SDU i.e. end information. A series of ordinary length indicators in the header of a PDU will indicate, serially, the positions in the PDU of each final octet of any SDU contained in that PDU.
Second, there are the special length indicators. Note that in a system which implemented the invention, taking the first embodiment by way of example, the system would retain the existing special length indicators in the prior art but change the meaning of some of them as indicated in the Patent. So:
0000000 conveyed the information that the first data octet in this PDU is the first octet of an SDU and the previous PDU was exactly filled with the last segment of an SDU if there is no length indicator that indicates the end of the SDU in the previous PDU (i.e. end information about the previous SDU/PDU);
1111100 indicated that the first data octet of this PDU is the first octet of an SDU and the last octet in this PDU is the last octet of an SDU (the same or different as the first SDU) (i.e. start and end information of either a single SDU or multiple complete SDUs).
1111110 indicated that the RLC PDU contains a segment of an SDU but neither the first nor the last octet of this SDU (segment information).
1111111 indicated in UM that the rest of the RLC PDU was padding (which can be zero). Accordingly, whilst the last octet of the last SDU in the PDU would be indicated by an ordinary length indicator, this value would indicate and/or confirm that there were no more or other SDUs or segments in the PDU.
As is apparent, generally the structural information conveyed by these special length indicators is more elaborate than the information conveyed by an ordinary length indicator.
Third, there is the information which can be conveyed by the alternative E-bit, which was introduced in June 2005. If that alternative interpretation is configured and the E-bit in the first octet is set to 0, it indicates that what follows is a complete SDU, not segmented, concatenated or padded, i.e. it exactly fills the remainder of the PDU. For this reason, the alternative E-bit conveyed both start and end information of an SDU. It also follows that if the alternative E-bit was set to 0, the PDU header contains no length indicators (either ordinary or special). Again, this structural information is more elaborate than the information conveyed by an ordinary length indicator.
As the Patent says, length indicators in UMTS were either 7 or 15 bits long. The Skilled Person would have known that length indicators in GSM/GPRS were 6 bits in length. With greater volumes of data being transmitted in each generation, the Skilled Person would also anticipate that in 3.9G/4G even the shortest length indicator might well be greater than 7 bits in length. Whilst noting that the length indicator of claim 1 does not have to be limited to any particular number of bits, it is nonetheless convenient to discuss the essential attributes of a length indicator by reference to the 7-bit entity.
A field of 7 bits allows for 128 values (0-127). In the patented system applied in UMTS, the values of 1-123 were available for use as ordinary length indicators i.e. to indicate the position in the PDU of the final octet of a particular SDU. The values of 0 (in binary 0000000), 124 (1111100), 126 (1111110) and 127 (1111111) were used as special length indicators, to which one can also add 125 (1111101), a reserved value but evidently available for some future special use. As the Patent illustrates, the meanings given to the special length indicators could be changed and/or re-arranged. In theory, the number of special length indicators could be increased. In UMTS, the number of special length indicators was constrained by the use of the last two bits of the 7-bit indicator but in theory one could use the last three bits to define a larger class of special length indicators but that would necessarily cut down the available class of ordinary length indicators, which could be dealt with by using the 15 bit versions.
The Defendants characterised the length indicators as having a ‘dual purpose’, but in fact the uses made of the 7 bit length indicators were mutually exclusive. In a system, any particular value was either an ordinary length indicator or a special length indicator but (for obvious reasons) it could not be both. Both types of length indicator conveyed information about the relationship between the PDU and one or more SDUs contained within it. So, in the class of ‘length indicator’ a value either indicated the position in the PDU of the last octet of a particular SDU or, as a special length indicator, it conveyed a somewhat more elaborate type of structural information, namely the relationship between a PDU and the SDUs which were either contained in that PDU or the preceding PDU.
In my judgment, it follows that in EP142 one of the essential attributes of a ‘length indicator’ was that it was capable of realistically performing the role of an ordinary length indicator, even if particular values could be repurposed to act as special length indicators. I add the qualification ‘realistically’ because the Skilled Person is a practical person. He or she would not see a 1 or 2-bit field as realistically capable of acting as an ordinary length indicator in any practical system.
Next I want to consider whether the term ‘length indicator’ has a limiting effect. Let me consider for the purposes of argument alternative terms such as ‘indicator’ or ‘structure indicator’.
The terms ‘indicator’ or even ‘structure indicator’ in the context of an RLC UM PDU header in UMTS would be sufficiently general to cover ordinary length indicators, the special length indicators and the alternative E-bit. This helps to show that the term ‘length indicator’ was used in claim 1 as granted to exclude the alternative E-bit, there being no other words in the claim which could perform that role. This is why the Defendants encouraged me to consider the claim as granted.
Accordingly, I find that to fall within the term ‘length indicator’ in the Patent, the field in question must be capable of specifying the position in the RLC PDU where an SDU ends, even if certain values are capable of being used to provide the sort of indications of the existing special length indicators. If the field in question is not so capable, then in my judgment, it is not a ‘length indicator’.
It will be noted that this interpretation:
includes no restriction on the number of bits which the length indicator must or can contain, provided there are sufficient bits to allow the normal function of a length indicator;
includes no restriction as to where the field in question is positioned in the header, whether in the fixed or optional portions. Whilst the Skilled Person might well expect a length indicator to appear only in the optional portion of the header, there does not seem to be any reason in principle why a length indicator might not be positioned in the fixed portion of the header, even if other length indicators appeared in the optional portion.
The absence of the restrictions I have just discussed releases the claim from the confines of the particular context in which the preferred embodiments are described, i.e. UMTS, and takes account of the explicit references to 3.9G.
In essence, the Claimants need the term ‘length indicator’ (which includes both (1) ordinary length indicators and (2) the special length indicators of the patent) to exclude (3) the single alternative E-bit but include (4) the 2-bit value FI=00. All four provide structure information about the SDU(s) in the PDU or, to use the Claimants’ phrase ‘control information about the payload’. The distinguishing feature of (3) and (4) is that they only provide structure information and are not capable of directly acting as
length indicators in the traditional sense of specifying the position in the PDU where an SDU ends. Hence, neither the alternative E-bit (when set to 0 in the first octet) nor the field FI=00 in LTE is a length indicator within the meaning of claim 1 of EP142.
Accordingly, my finding as to the proper interpretation of ‘length indicator’ resolves the allegation of infringement on a normal interpretation of claim 1 of EP142.
Claim Scope - Equivalents
Actavis Qn 1
Notwithstanding that it is not within the normal meaning of the relevant claim(s) of the patent, does the variant achieve substantially the same result in substantially the same way as the invention, i.e. the inventive concept revealed by the patent?
Naturally, the Claimants’ approach to this question depends heavily on their characterisation of the inventive concept which I have set out above. On that basis, the Claimants contend that the FI=00 value performs exactly the same role in the PDU as the new special length indicator of the Patent and conveys exactly the same control information about the payload as in the Patent. They go on to contend that the FI=00 is a single defined value to convey the fact that ‘perfect packing’ is present in the PDU, which also capitalises on the same efficient approach proposed in the Patent, using a single ‘token’ to do the job that previously required two. They also point out that the various values of the FI field as whole perform essentially the function of the special length indicators in UMTS.
The Defendants put forward a series of points as to why this question should be answered ‘No’. Although they were set out in considerable detail, they can be summarised conveniently as follows:
First, they contend LTE is a different environment, such that the ‘two octets smaller’ or N+1 problem does not arise;
Second, they contend that LTE uses a different approach – having a new field in every PDU for segmentation information;
Third, they contend that the LTE approach has different knock-on effects because it uses a different field which is always present but it is only 2 bits long and is freed from having to use the size of the length indicator in the system. Furthermore, they point out the FI field is an independent field which has the ability to indicate four different states of segmentation.
In response, the Claimants say that none of the differences which the Defendants identify matter to the invention.
Analysis
The variant is when the FI field is set to 00. This value conveys the information that the first data byte/octet of the PDU is the first byte/octet of a SDU and the last byte/octet of the PDU is the last byte/octet of an SDU. Thus this value applies whether the PDU contains a single complete SDU or multiple complete SDUs. The receiver therefore receives exactly the information which the amended claim purports to specify. It is therefore clear that the FI=00 value does exactly the same job as the single special length indicator that is the subject of claim 1 as proposed to be amended.
Does the variant do this in substantially the same way as the invention? On this point I need to examine the Claimants’ characterisations of the inventive concept and their argument that the essence of a ‘length indicator’ is that it conveys ‘control information about the payload’ which allows the receiver to separate out the SDUs contained in the data part of the PDU. As to these:
It is true that the FI=00 value indicates ‘perfect packing’, but for the reasons I explained in paragraph 114 above, the use of this concept views matters at too high a level of generality i.e. the wrong level at which to consider the way the job is done.
Similarly, to characterise the way the invention achieves the result is because it conveys ‘control information about the payload’ is again at the wrong level of generality.
Far from these concepts of ‘perfect packing’ and ‘control information about the payload’ being derived from consideration of the invention in the proposed amended claims of the Patent, it is abundantly clear and I find that they were derived specifically to embrace the alleged infringement.
The invention in the proposed amended claims achieves the result by using a length indicator. The FI=00 achieves the same result in a different way because it is not a length indicator.
Actavis Qn 2
The Skilled Person knows that the variant (FI=00) achieves the same result as is specified in the amended claims. Would it be obvious to the skilled person, reading the patent (as amended) at the priority date of September 2005, that the variant achieved the same result in substantially the same way as the invention? In my view it would not be obvious, because the Skilled Person would immediately understand that the variant is not a length indicator. The Skilled Person would also understand that the use of the FI=00 value is a different way of achieving the result.
Actavis Qn 3
Would such a reader of the patent have concluded that the patentee nonetheless intended that strict compliance with the literal meaning of the relevant claim(s) of the patent was an essential requirement of the invention?
In the circumstances of this case, the Skilled Person reading the Patent (as proposed to be amended) at the priority date would conclude that the patentee was using the term ‘a length indicator’ to exclude the alternative E-bit from the scope of the claim and therefore that what I found to be the normal interpretation of ‘a length indicator’ was an essential requirement of the invention. The reason is clear. Otherwise the claim would be invalid.
I am conscious that in the particular circumstances of this case that the answers to all three of the Actavis questions have depended on the normal interpretation of ‘length indicator’ and I have considered whether this itself indicates errors in my approach to the Actavis questions. I have concluded it does not. Even if I assume that Actavis questions 1 and 2 yielded positive answers, in the circumstances of this case, question 3 would still require the answer ‘Yes’.
Since I have found that the use of the FI=00 value in LTE does not infringe EP142 either on the basis of a normal interpretation or on the basis of equivalents, I can deal more briefly with the remaining points. On the basis of those findings, the Defendants do not allege the Patent is invalid.
What remains is the Claimants’ unconditional application to amend the Patent.
The Claimants’ Application to Amend
As I mentioned above, the purpose of the proposed amendments is to exclude the ‘single SDU embodiment’ from the scope of the claims. However, this application takes place against a backdrop where it is abundantly clear that in the Patent as granted, the single SDU embodiment was certainly within the scope of the claims and was certainly taught in the specification as being within the invention. There was very little focus on the motivation for the amendments. However, my understanding is that the reason for the amendments was to avoid the Samsung prior art. This proposed the alternative E-bit, which I have found to be CGK by the priority date.
The Claimants seek to exclude the ‘single SDU embodiment’ by proposing amendments which, they say, ‘specify that the length indicator of the claim must be for indicating the case where the first data octet of the PDU is the first octet of an SDU and the last octet of the PDU is the last octet of an SDU, for any number of SDUs in the PDU.’ The Defendants say that the proposed amendments fail to achieve this aim, since they say that either of the proposed amended claims 1 would be worked by an indicator which could only indicate the single SDU embodiment. The Claimants’ retort is that the Defendants have misunderstood the nature of the method which is claimed: they say the Defendants are muddling up the precise circumstances that may cause the indication to be inserted with the overall rule being applied; they also say that the fact that in an individual instance the SDU that started the PDU can be the same as the one that ends it does not mean the indicator is a single SDU only indicator.
In conceptual terms, what the Claimants are trying to do is clear enough. However, in my view, the proposed amendments do not achieve the aim. It will be recalled that the aim is to exclude the single SDU embodiment but include the indicator which is for indicating ‘perfect packing’ (to use the Claimants’ expression) whether that arises from a single SDU or multiple SDUs. However, in a working system, a single length indicator of a particular value (say 125) can only indicate one condition or the other. If 125 indicates the condition arising from a single SDU, and, say, 126 indicates the condition arising from multiple SDUs, the claim still embraces a length indicator which only indicates the single SDU condition. This arises from the language of the claims as proposed to be amended and I do not see how the amendments to the specification alter the conclusion. After all, the amendments to the specification define the concept which the amended claims are trying to claim but, as I have said, the claims fail in this endeavour. Far more wording would be required in the claims to achieve this.
The Defendants took a variety of other objections to the amendments and the UK IPO took the view that there was a lack of support under s.14(5)(c), but I do not think it is necessary to consider these points further. Many are founded in one way or another on the point in the previous paragraph.
Since the proposed amendments do not achieve the aim, the consequence is as follows. If I had found that the term ‘length indicator’ was broad enough on a normal construction to cover the FI=00 value in LTE, then EP142 would have been invalid over Samsung and the alternative E-bit. I am aware of the maxim of construction that indicates that a patentee does not normally phrase his claim so that it covers something in the CGK, but that is no more than a guideline. It is a guideline which is the more easily displaced when a patentee is attempting to force his claim to read onto an alleged infringement.
On the claims as granted, the reason why the alternative E-bit fell outside the claims was because it was not a ‘length indicator’. In this action, however, the Claimants wanted to establish that the use of the FI=00 value in LTE fell within claim 1 and for that purpose, the term ‘length indicator’ had to accommodate that type of 2-bit indicator. This was, of course, uncomfortably close to the single bit indicator of the alternative E-bit which applied in the scenario where a PDU contained a single SDU without segmentation, concatenation or padding. Accordingly, the Claimants needed to be able to distinguish the alternative E-bit in a different way.
The route the Claimants chose was to propose amendments which purported to exclude precisely the scenario of the alternative E-bit i.e. where an indicator could only indicate where a PDU contained a single SDU without segmentation, concatenation or padding, whilst retaining embodiments where a single indicator could indicate both that situation (i.e. start and end information of the same SDU) and the situation where it indicated the start of one SDU and the end of a different SDU) – this is the ‘same or different’ wording in [0009], [0028], [0032] and [0034].
If I had found that the scope of ‘length indicator’ was broad enough to cover the FI=00 value in LTE only by applying the Actavis questions, I incline to the view that EP142 would again be invalid due to the existence of the alternative E-bit but since this is hypothetical, it is not a necessary finding for me to make and the topic is controversial, I will say no more about it.
In any event, the claim for infringement of EP142 fails whether on the claims as proposed to be amended or on the claims as granted for the reasons set out above. Those reasons apply irrespective of the proposed amendments.
The Prior Art
The Defendants made it clear that Qualcomm and WiMAX were pleaded as squeezes against the Claimants’ infringement case, such that the prior art only became relevant if the scope of protection was not limited, as I have found, to indicators capable of acting as what I might call true ‘length indicators’. Since I have found that the scope of protection is so limited, it is not necessary for me to lengthen this judgment with an analysis of the Qualcomm and WiMAX prior art and the various arguments which arise.
Conclusion
Despite the elaboration and effort which the Claimants have devoted to the claim for infringement of EP142, in my view this case boils down to a simple issue: the term ‘length indicator’ was used in claim 1 as granted to exclude the alternative E-bit, amongst other reasons. Although the alleged infringement, the FI=00 value, is not identical to the alternative E-bit, it has considerable similarities. In particular neither is capable of acting as an ordinary length indicator. Accordingly, if ‘length indicator’ is construed so as to exclude the alternative E-bit, it must also exclude the FI=00 from the scope of the claim, whether on a normal interpretation or on the basis of equivalents.
For all the reasons set out in this Judgment, the claim for infringement of EP142 fails.
EP142 is not essential to LTE.
ANNEX 1This is the text of the relevant standard under the heading Length Indicator
9.2.2.8 Length Indicator (LI)
[0017] Unless the "Extension bit" indicates that a UMD PDU contains a complete SDU which is not segmented, concatenated or padded, a "Length Indicator" is used to indicate the last octet of each RLC SDU ending within the PDU. If the "Extension bit" indicates that the UMD PDU contains a complete SDU which is not segmented, concatenated or padded, no LIs are present in this UMD PDU.
[0018] for the predefined values reserved for special purposes and listed in the tables below, the "Length Indicator" shall:
be set to the number of octets between the end of the RLC header and up to and including the last octet of an RLC SDU segment;
be included in the PDUs that they refer to.
The size of the "Length Indicator" may be either 7 bits or 15 bits. The "Length Indicator" size is determined independently for uplink and downlink. The value of a "Length Indicator" shall not exceed the values specified in subclauses 11.2.4.2 and 11.3.4.5 respectively for UMD and AMD PDUs.
The "Length Indicators" which refer to the same PDU shall:
not be reordered in case of retransmission;
be in the same order as the RLC SDUs that they refer to.
For AM:
if the "AMD PDU size" is 126 octets:
7-bit "Length Indicators" shall be used.
else:
15-bit "Length Indicators" shall be used.
the size of the "Length Indicator" is always the same for all AMD PDUs, for one RLC entity.
For UM uplink:
if the "largest UL UMD PDU size" is 125 octets:
7-bit "Length Indicators" shall be used.
else:
15-bit "Length Indicators" shall be used.
For UM downlink:
the "Length Indicator" size provided in "DL RLC UM LI size" shall be used.
[0019] For UM:
between modifications of the "largest UMD PDU size", the size of the "Length Indicator" is the same for all UMD PDUs;
if the RLC SDU begins in the beginning of the RLC PDU; and
if the RLC PDU is transmitted in uplink; and
if the "Length Indicators" indicating that a RLC SDU ended exactly in the end or one octet short
(only when 15-bit "Length Indicators" is used) of the previous RLC PDU are not present; and
if the "Extension bit" does not indicate that the UMD PDU contains a complete SDU which is not segmented, concatenated or padded:
if 7-bit "Length Indicator" is used:
the "Length Indicator" with value "111 1100" shall be used.
if 15-bit "Length Indicator" is used:
the "Length Indicator" with value "111 1111 1111 1100" shall be used.
in downlink:
if 7-bit "Length Indicator" is used:
the Receiver shall be prepared to receive the "Length Indicator" with value "111 1100";
the Receiver shall follow the discard rules in subclause 11.2.3 both when the "Length Indicator" with value "111 1100" is present and when it is absent.
if 15-bit "Length Indicator" is used:
the Receiver shall be prepared to receive the "Length Indicator" with value "111 1111 1111 1100";
the Receiver shall follow the discard rules in subclause 11.2.3 both when the "Length Indicator" with value "111 1111 1111 1100" is present and when it is absent.
[0020] In the case where the end of the last segment of an RLC SDU exactly ends at the end of a PDU and there is no "Length Indicator" that indicates the end of the RLC SDU, and the "Extension bit" of the following PDU does not indicate that the UMD PDU contains a complete SDU which is not segmented, concatenated or padded:
if 7-bit "Length Indicator" is used:
a "Length Indicator" with value "000 0000" shall be placed as the first "Length Indicator" in the following PDU;
if 15-bit "Length Indicator" is used:
a "Length Indicator" with value "000 0000 0000 0000" shall be placed as the first "Length Indicator" in the following PDU.
[0021] In the case where a PDU contains a 15-bit "Length Indicator" indicating that an RLC SDU ends with one octet left in the PDU, the last octet of this PDU shall:
be padded by the Sender and ignored by the Receiver though there is no "Length Indicator" indicating the existence of Padding; and
not be filled with the first octet of the next RLC SDU data.
In the case where 15-bit "Length Indicators" are used in a PDU and the last segment of an RLC SDU is one octet short of exactly filling the PDU:
if a 15-bit "Length Indicator" is used for the following PDU:
the "Length Indicator" with value "111 1111 1111 1011" shall be placed as the first "Length Indicator" in the following PDU;
the remaining one octet in the current PDU shall be padded by the Sender and ignored at the Receiver though there is no "Length Indicator" indicating the existence of Padding;
if a 7-bit "Length Indicator" size is configured for the following PDU:
if RLC is configured for UM mode:
if the "Extension bit" of that PDU does not indicate that the UMD PDU contains a complete SDU which is not segmented, concatenated or padded:
the "Length Indicator" with value "000 0000" shall be placed as the first "Length indicator" in the following PDU;
the "Sequence Number" shall be incremented by 2 before it is transmitted.
[0022] For UM and AM RLC:
if a 7 bit "Length Indicator" is used in a RLC PDU and one or more padding octets are present in the RLC PDU after the end of the last RLC SDU:
indicate the presence of padding by including a "Length Indicator" with value "1111111" as the last "Length Indicator" in the PDU.
if a 15 bit "Length Indicator" is used in a RLC PDU and two or more padding octets are present in the RLC PDU after the end of the last RLC SDU:
indicate the presence of padding by including a "Length Indicator" with value "111 1111 1111 1111" as the last "Length Indicator" in the PDU.
NOTE: After the "Length Indicator" indicating the presence of padding has been included in the RLC PDU, the length of the padding may be zero.
[0023] In the case where the "alternative E-bit interpretation" is configured for UM RLC and an RLC PDU contains a segment of an SDU but neither the first octet nor the last octet of this SDU:
if a 7-bit "Length Indicator" is used:
the "Length Indicator" with value "111 1110" shall be used.
if a 15-bit "Length Indicator" is used:
the "Length Indicator" with value "111 1111 1111 1110" shall be used. [end of 0023]
[0025] If a "Length Indicator" is still awaiting transmission and there is no RLC SDU available, an RLC PDU consisting of this "Length Indicator", the appropriate padding "Length Indicator" and padding may be transmitted.
Predefined values of the "Length Indicator" are used to indicate padding. [end of 0025] The values that are reserved for special purposes are listed in the tables below depending on the size of the "Length Indicator". Only predefined "Length Indicator" values can refer to the padding space. These values shall only be placed after all other "Length Indicators" for a PDU.
STATUS PDUs can be piggybacked on the AMD PDU by using part or all of the padding space. A predefined "Length Indicator" shall be used to indicate the presence of a piggybacked STATUS PDU. This "Length Indicator" replaces the padding "Length Indicator". The piggybacked STATUS PDU shall be appended immediately following the PDU data. When only part of the padding space is used, the end of the piggybacked STATUS PDU is indicated by one of the SUFI fields NO_MORE or ACK. Thus no additional "Length Indicator" is required to show that there is still padding in the AMD PDU.
If "SDU discard with explicit signalling" is configured:
an AMD PDU can contain a maximum number of 15 "Length Indicators" indicating the end of 15 corresponding SDUs; and
the rest of the AMD PDU space shall be used as padding or as piggybacked STATUS PDU. Length: 7 bits
Bit | Description |
0000000 | The previous RLC PDU was exactly filled with the last segment of an RLC SDU and there is no "Length Indicator" that indicates the end of the RLC SDU in the previous RLC PDU. |
1111100 | UMD PDU: The first data octet in this RLC PDU is the first octet of an RLC SDU. AMD PDU: Reserved (PDUs with this coding will be discarded by this version of the protocol). |
1111101 | Reserved (PDUs with this coding will be discarded by this version of the protocol). |
1111110 | AMD PDU: The rest of the RLC PDU includes a piggybacked STATUS PDU. UMD PDU: The RLC PDU contains a segment of an SDU but neither the first octet nor the last octet of this SDU. |
1111111 | The rest of the RLC PDU is padding. The padding length can be zero. |
Length: 15bits
Bit | Description |
000000000000000 | The previous RLC PDU was exactly filled with the last segment of an RLC SDU and there is no "Length Indicator" that indicates the end of the RLC SDU in the previous RLC PDU. |
111111111111011 | The last segment of an RLC SDU was one octet short of exactly filling the previous RLC PDU and there is no "Length Indicator" that indicates the end of the RLC SDU in the previous RLC PDU. The remaining one octet in the previous RLC PDU is ignored. |
111111111111100 | UMD PDU: The first data octet in this RLC PDU is the first octet of an RLC SDU. AMD PDU: Reserved (PDUs with this coding will be discarded by this version of the protocol). |
111111111111101 | Reserved (PDUs with this coding will be discarded by this version of the protocol). |
111111111111110 | AMD PDU: The rest of the RLC PDU includes a piggybacked STATUS PDU. UMD PDU: The RLC PDU contains a segment of an SDU but neither the first octet nor the last octet of this SDU. |
111111111111111 | The rest of the RLC PDU is padding. The padding length can be zero. |