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)

Download PDF
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: +46 8 585 319 83 Fax: +46 8 585 314 80 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

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.


Why Is My Information Online?