Apple Inc. v. Samsung Electronics Co. Ltd. et al

Filing 661

EXHIBITS re #660 Administrative Motion to File Under Seal Apple Inc.'s Notice of Motion and Motion for Partial Summary Judgment Exhibits to Mueller Declaration ISO Apple's Motion for Partial Summary Judgment [660-9] filed byApple Inc.(a California corporation). (Attachments: #1 Exhibit Mueller Decl Exhibit 2, #2 Exhibit Mueller Decl Exhibit 3, #3 Exhibit Mueller Decl Exhibit 4, #4 Exhibit Mueller Decl Exhibit 5, #5 Exhibit Mueller Decl Exhibit 6, #6 Exhibit Mueller Decl Exhibit 7, #7 Exhibit Mueller Decl Exhibit 8, #8 Exhibit Mueller Decl Exhibit 9, #9 Exhibit Mueller Decl Exhibit 10, #10 Exhibit Mueller Decl Exhibit 11, #11 Exhibit Mueller Decl Exhibit 12, #12 Exhibit Mueller Decl Exhibit 13, #13 Exhibit Mueller Decl Exhibit 14, #14 Exhibit Mueller Decl Exhibit 15, #15 Exhibit Mueller Decl Exhibit 16, #16 Exhibit Mueller Decl Exhibit 17, #17 Exhibit Mueller Decl Exhibit 18, #18 Exhibit Mueller Decl Exhibit 19, #19 Exhibit Mueller Decl Exhibit 20, #20 Exhibit Mueller Decl Exhibit 21, #21 Exhibit Mueller Decl Exhibit 22, #22 Exhibit Mueller Decl Exhibit 23, #23 Exhibit Mueller Decl Exhibit 24)(Related document(s) #660 ) (Selwyn, Mark) (Filed on 1/25/2012)

Mueller Exhibit 6

3GPP_TSG_RAN_WG1 Archives--June 1999 (#379)

View:

Next in topic I Previous in topic
Next by same author I Previous by same author
Previous page (June 1999), I Back to main 3GPP TSG RAN WG1 page
Join or leave 3GPP TSG RAN WG1
~1 Post a new message
Search

Options:

Page 1 of 2

Chronologically I Most recent first
Proportional font I Non-proportional font

Date:
Reply-To:
Sender:
From:
Organization:
Subject:
Comments: T©:
Content-Type:

Tue, 29 Jun 1999 16:20:24 +0200
[log in to unmask]
"3GPP TSG RAN WGI: TSG RAN Working Group 1"
<Ilog in To unmask]>
Per Narvinger <Iloq in to unmask]>
Ericsson Radio Systems
Re: (’SA~) Re: AH04: Hissing
multiplexing rules
Ilog in to unmask]
text/plain; charset=us-ascii

Dear Beongjo,
I agree that it would be possible to define the rate matching in such a
way that the resulting number of bits always is a multiple of the number
of radio frames in the transmission time interval. However, this might
be rather complicated.
As an example consider a transport channel with 80 ms transmission time
interval and 2 transport formats.
In the first format, 640 coded bits are delivered to the rate matching
unit. Higher layers have signalled that 6.25% repetition should be
applied in order to balance the TrCH with some other TrCH. The resulting
number of bits per frame then is 1.0625"640/8 85.
In the second format 320 coded bits are delivered to the rate matching
unit and since the rate matching attribute is semi-static it is
unchanged. That means that we now have 1.0625"320/8=42.5 bits per frame.
Consequently, if we want to make sure that the we have the same number
of bits in each frame we must change the repetition to (for example)
7.5% so that we get 1.075"320/8 43 bits per frame. However, if we change
the repetition on one TrCH, the balancing with other TrCHs of course is
affected. Consequently, we would need to add repetition on the other
TrCHs as well. However, if the same amount of repetition is added on the
other TrCHs, there is no guarantee the resulting number of bits on those
TrCHs are a multiple of the number of radio frames that they are going
to be sent on.
A solution would of course be to just disregard from the fact that the
balancing has been slightly modified. However, since we anyway have to
handle different number of bits in different radio frames in the uplink,
I would propose that we do the same in the downlink.

Best regards,
Per Narvinger

Beongjo Kim wrote:
>
> Hello everyone,
>
> Thanks for the responses and valuable comments.
>
> Considering Per Narvinger’s point,
> we think Li/Ti is not necessarily integer for uplink.
> So, we will incorporate the point into updated proposal, with
> correcting some notational errors.

http://~ist.etsi.~rg/scfipts/wa.exe?A2=ind99~6&L=3GPP-TSG-RAN-WG~&P=R329486&I... 9/1/2011
APLNDC-WH-A 0000009991

3GPP_TSG_RAN_WG1 Archives -- June 1999 (#379)

Page 2 of 2

>
> For downlink, however, we think that rate matching will take care of the problem.
> In other words, after rate matching, the frame size including dtx bits
> will fit exactly to some of the physical channel data rates.
>
> We expect comments on this issue.
>
> Now, I am preparing text proposal for missing sections in 25.212.
> We are open to comments from anybody.
>
> Regards,
>
> Beongjo Kim
> Telecommunication R&D center,
> Samsung Electronics Co., Ltd.
>
> >Dear Beongjo,
>
> >I have one comment on the radio frame segmentation part of your
> >contribution. In general I do not think that Li/Ti need to be an
> >integer. In paragraph 4.2.4 of 25.212 it is described how the 1st
> >interleaver is pruned. This means that in the general case, the last row
> >of the 1st interleaver does not need to be completely filled. Hence,
> >some of the radio frames will contain one bit less than the others. If
> >you could incorporate this into your text proposal, I think the radio
> >frame segmentation is clearly defined.
>
> >Best regards,
> >Per Narvinger

Per Narvinger
Radio Access Research
Ericsson Radio Systems AB
164 80 STOCKHOLM, SWEDEN
Ilog in to unmaskl

Tel:
[phone]
Fax: [phone]

Back to: Top of message I Previous page I Main 3GPP TSG RAN WG1 page

http ://list.etsi.org/scripts/wa.exe?A2=ind9906&L=3 GPP_T SG_RAN_WG1 &P=R329486&I... 9/1/2011
APLNDC-WH-A 0000009992