US7948879B2 Claim 1 vs 3GPP TS 36.322: Sample Claim Chart

Bibliographic data

Patent number

US7948879B2

Title

Method and arrangement in a wireless communication network

Inventors

Johan Torsner, Michael Meyer, Janne Peisa

Priority date

2008-01-08

Filing date

2009-01-08

Assignee

Unwired Planet LLC

Standard assessed

E-UTRA Radio Link Control (RLC) acknowledged mode polling (TS 36.322 §5.2.2.1) — Any Rel-8 compliant E-UTRA device implementing RLC acknowledged mode (UE or eNB)

Target release

Rel-8 (TS 36.322 v8.8.0, TS 36.331 v8.21.0)

Claim 1 (independent)

Method in a first node for requesting a status report from a second node, the first node and the second node both being comprised within a wireless communication network, the status report comprising at least one of positive and negative acknowledgement of data sent from the first node to be received by the second node, wherein the method comprises the steps of: transmitting a sequence of data units or data unit segments to be received by the second node, incrementing a first counter based on a number of data units transmitted, incrementing a second counter based on a number of bytes of data transmitted, comparing a count of the first counter to a first predefined value, comparing a count of the second counter to a second predefined value, and in response to determining that either the count of the first counter exceeds the first predefined value or the count of the second counter exceeds the second predefined value: requesting a status report from the second node, and resetting both the first counter and the second counter.

Standard under assessment

Rel-8 · TS 36.322 v8.8.0 · TS 36.331 v8.21.0

Primary target: the polling procedure of E-UTRA acknowledged-mode Radio Link Control, Rel-8. The core clause is TS 36.322 v8.8.0 §5.2.2.1, which holds the two counters, the two threshold tests, the poll and the reset in one list of actions. The counters themselves are defined in §7.1, the two configured thresholds in §7.4, the poll indication in §6.2.2.11, and the report the poll asks for in §5.2.3. The thresholds reach the RLC entity through the RLC-Config information element of TS 36.331 v8.21.0 §6.3.2, which a bearer establishment or reconfiguration applies under §5.3.10.3.

Rel-8 is assessed because it is the release in which the claimed function entered the standard: the change history of TS 36.322 records that the two counter-based polling triggers were added by change request CR0001 (RP-080196, RAN#39, March 2008) in version 8.1.0, and the specification itself does not exist in any earlier release. Every extract and screenshot below is taken from the Rel-8 version of the specification concerned.

The wording relied on here also stands in the current versions of both specifications, with one difference: from Rel-13 onward the counter increment and the two counter reset lines of §5.2.2.1 carve out NB-IoT. An assessment aimed at a later release would need to take that carve-out into account; it does not affect the Rel-8 text assessed here.

Claim chart

Matching colors mark corresponding elements between the claim and the standard. An underline in a screenshot marks the text the mapping rests on.

#Claim 1 — US7948879B2Rel-8 · TS 36.322 v8.8.0 · TS 36.331 v8.21.0

P

Method in a first node for requesting a status report from a second node, the first node and the second node both being comprised within a wireless communication network, the status report comprising at least one of positive and negative acknowledgement of data sent from the first node to be received by the second node, wherein the method comprises the steps of:

The claimed pair of nodes is the two ends of one acknowledged-mode RLC link: the transmitting side of an AM RLC entity, which is the side that asks for a report, and its peer AM RLC entity, which is the side that returns one. The report itself is the STATUS PDU, and the standard states its purpose as providing positive and/or negative acknowledgement of the RLC PDUs the peer received — the two kinds of acknowledgement the preamble recites, either of which suffices.

L1

transmitting a sequence of data units or data unit segments to be received by the second node,

An acknowledged-mode entity delivers exactly the two kinds of unit the step recites, and the standard lists them as two separate RLC data PDUs: the AMD PDU and the AMD PDU segment. What leaves the sender is a sequence rather than a set, because each new AMD PDU is given the send-state sequence number when it is delivered to lower layer. The side that receives them, and that returns the acknowledgement for them, is the peer AM RLC entity.

L2

incrementing a first counter based on a number of data units transmitted,

On assembly of each new AMD PDU the transmitting side increments PDU_WITHOUT_POLL by one. The state-variable clause defines that counter as the number of AMD PDUs sent since the most recent poll — a running total kept over transmitted units, which is what this step requires.

L3

incrementing a second counter based on a number of bytes of data transmitted,

In the same list of actions the transmitting side increments BYTE_WITHOUT_POLL by every new byte of Data field element that it maps into the data field of the RLC data PDU, and the state-variable clause defines that counter as the number of data bytes sent since the most recent poll. It is a second running total, kept over volume rather than over units.

L4

comparing a count of the first counter to a first predefined value,

Immediately after the increments, the same clause tests PDU_WITHOUT_POLL against pollPDU. The parameter clause states what that value is for: it makes the transmitting side trigger a poll for every pollPDU PDUs. The value is fixed before the comparison, not derived from it — it is signalled in the RLC configuration information element and taken into use when a bearer is established or reconfigured.

L5

comparing a count of the second counter to a second predefined value, and

The second test sits on the next line of the same list: BYTE_WITHOUT_POLL against pollByte, the parameter that makes the transmitting side trigger a poll for every pollByte bytes. It travels with pollPDU in the same RLC configuration information element and is applied by the same bearer procedure, so both thresholds are in place before either comparison is made.

L6

in response to determining that either the count of the first counter exceeds the first predefined value or the count of the second counter exceeds the second predefined value:

The standard writes the two tests as one disjunctive condition, on consecutive lines under the same "shall": if PDU_WITHOUT_POLL has reached or passed pollPDU, or if BYTE_WITHOUT_POLL has reached or passed pollByte, a poll is included — one satisfied branch is enough, exactly as the claim's "either … or". The condition covers the case the claim recites, a count standing above the value: BYTE_WITHOUT_POLL advances by the whole byte count of a data field element, so it ordinarily passes pollByte rather than landing on it. This branch of the procedure operates where the network sets a finite threshold; both parameters also carry an infinite value in their range, which switches the counter-based trigger off.

L7

requesting a status report from the second node, and

The request is the poll. Including one means setting the P field of the RLC data PDU, and the field clause states in terms what that means: the transmitting side is requesting a STATUS PDU from its peer AM RLC entity, value 1 being "Status report is requested". The request is carried in-band to the peer AM RLC entity, which on receiving a data PDU with the P field set to 1 triggers the report and delivers a STATUS PDU at its next transmission opportunity.

L8

resetting both the first counter and the second counter.

The same list that sets the P field also sets PDU_WITHOUT_POLL to 0 and BYTE_WITHOUT_POLL to 0. Both counters are cleared together, whichever of the two thresholds fired, which is what "both" requires; that is also why each counter measures only what has been sent since the most recent poll.

Overall assessment

L1–L8 map to the acknowledged-mode RLC polling procedure of TS 36.322 v8.8.0: both counters, both thresholds, the disjunctive trigger, the poll and the counter reset are written as one sequence in §5.2.2.1, with the parameters and the report defined in §7.1, §7.4, §6.2.2.11 and §5.2.3.

References

• TS 36.322 — Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification
• TS 36.331 — Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification
• US7948879B2 — Method and arrangement in a wireless communication network (Google Patents)

this document is a technical essentiality assessment prepared for reference, comparing published patent documents against 3GPP standard specifications. It is not a legal determination or legal advice on the essentiality, validity or infringement of the patent. Before any material decision such as licensing or litigation, obtain a review by a qualified patent attorney or attorney at law.