throbber

`
`Performance 245
`
`
`
` bps/Hz/cell
`
`
`
`HSPA R6 HSPA R6 + HSPA R7 HSPA R8/R9
`
`LTE R8
`
`UE equalizer MIMO
`
`DC-HSDPA
`
`Figure 9.25
`
`Spectral efficiency of HSPA and LTE
`
`applications are, for example, voice, real time gaming and other interactive applications. The
`latency can be measured by the time it takes for a small IP packet to travel from the terminal
`through the network to the internet server. and back. That measure is called round trip time
`and is illustrated in Figure 9.26.
`The end—to—end delay budget is calculated in Table 9.21 and illustrated in Figure 9.27. The
`l-ms frame size allows a very low transmission time. On average, the packet needs to wait for
`0.5 ms for the start of the next frame. The retransmissions take 8ms at best and the assumed
`
`retransmission probability is 10%. The average delay for sending the scheduling request is
`
`UE
`
`eNodeB
`
`SAE GW
`
`Server
`
`Figure 9.26 Round trip time measurement
`
`Table 9.21 Latency components
`
`Delay component
`
`Delay value
`
`Transmission time uplink + downlink
`Buffering time (0.5 x transmission time)
`Retransmissions 10%
`
`2 ms
`2 x 0.5 x 1 ms = 1 ms
`2 x 0.1 x 8 ms = 1.6 ms
`
`Uplink scheduling request
`Uplink scheduling grant
`UE delay estimated
`eNodeB delay estimated
`Core network
`
`0.5 x 5 ms = 2.5 ms
`4 ms
`4 ms
`4ms
`1 ms
`
`Total delay with pre-allocated resources
`Total delay with scheduling
`
`13.6 ms
`20.1 ms
`
`Samsung Ex. 1010
`378 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 387
`
`

`

`246
`
`LTE for UMTS — OFDMA and SC—FDMA Based Radio Access
`
`
`
`U Core
`I BTS
`
`Transmission time
`
`I Uplink scheduling grant
`El Uplink scheduling request
`El Retransmissions
`
`I Buffering time
`
`LTE round trip time
`
`Figure 9.27 End-to-end round trip time including scheduling latency
`
`2.5 ms and the scheduling grant 4ms. We further assume a UE processing delay of 4ms, an
`eNodeB processing delay of 4ms and a core network delay of 1 ms.
`The average round trip including retransmission can be clearly below 15ms if there are
`pre—allocated resources. If the scheduling delay is included, the delay round trip time will be
`approximately 20 ms. These round trip time values are low enough even for applications with
`very tough delay requirements. The practical round trip time in the field may be higher if the
`transport delay is longer, or if the server is far away from the core network. Often the end-to-
`end round trip time can be dominated by non-radio delays, e.g. by the distance and by the other
`elements in the intemet. The propagation time of 5000 km is more than 20 ms.
`
`9.8 LTE Refarming to GSM Spectrum
`
`LTE will be deployed in the existing GSM spectrum like 900MHz or 1800Ml-Iz. The flex-
`ible LTE bandwidth makes refarming easier than with WCDMA because LTE can start with
`1.4MHz or 3.0 MHZ bandwidths and then grow later when the GSM traffic has decreased. The
`required separation of the LTE carrier to the closest GSM carrier is shown in Table 9.22. The
`required total spectrum for LTE can be calculated based on the can’ier spacing. The coordinated
`
`Table 9.22 Spectrum requirements for LTE refarming
`
`5MHz LTE (25 RBs)
`3MHz LTE (125 RBs)
`1.4 MHz LTE (6 RES)
`
`LTE total spectrum requirement
`LTE—GSM carrier spacing
`Coordinated
`Uncoordinated Coordinated
`Uncoordinated
`2.5 MHz
`2.7 MHz
`4.8 MHz
`5.2 MHz
`1.6MHz
`1.7 MHz
`3.0MHz
`3.2 MHz
`0.8 MHz
`0.9 MHz
`1.4MHz
`1.6MHz
`
`Samsung Ex. 1010
`379 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 388
`
`

`

`Performance
`
`247
`
`LTE-GSM carrier
`spacing 2.5 MHz
`
`LTE total spectrum requirement
`4.8 MHz
`
`
`
`Figure 9.28 LTE 5-MHz refarming example
`
`10 MHz
`
`LTE 1.4 MHz
`
`LTE 3.0
`MHz
`
`LTE 5.0 MHz
`
`GSM
`frequencies
`
`LTE
`bandwidth
`
`49
`
`42
`
`34
`
`25
`
`0
`
`1.4 MHz
`
`3.0 MHz
`
`5.0 MHz
`
`
`
`Figure 9.29 LTE refarming to GSM spectrum
`
`case assumes that LTE and GSM use the same sites while the uncoordinated case assumes that
`different sites are used for LTE and GSM. The uncoordinated case causes larger power differ-
`ences between the systems and leads to a larger guard band requirement. The coordinated case
`values are based on the GSM UE emissions and the uncoordinated values on LTE UE block-
`ing requirements. It may be possible to push the LTE spectrum requirements down further for
`coordinated deployment depending on the GSM UE power levels and the allowed LTE uplink
`interference levels. The limiting factor is the maximum allowed interference to the PUCCH
`RBs that are located at the edge of the carrier.
`The carrier spacing defi nition is illustrated in Figure 9.28. Figure 9.29 shows the expansion
`of the LTE carrier bandwidth when the GSM traffi c decreases. Only seven GSM carriers need
`to be removed to make room for LTE 1.4 MHz and 15 GSM carriers for LTE 3.0 MHz.
`
`9.9 Dimensioning
`This section presents examples on how to convert the cell throughput values to the maximum
`number of broadband subscribers. Figure 9.30 shows two methods: a traffi c volume based
`approach and a data rate based approach. The traffi c volume based approach estimates the
`maximum traffi c volume in gigabytes that can be carried by LTE 20 MHz 1 + 1 + 1 confi gura-
`tion. The spectral effi ciency is assumed to be 1.74 bps/Hz/cell using 2 × 2 MIMO. The busy
`
`IPR2022-00457
`Apple EX1010 Page 389
`
`

`

`248
`
`LTE for UMTS – OFDMA and SC-FDMA Based Radio Access
`
`Traffic volume based dimensioning
`20 MHz x 1.74
`bps/Hz/cell
`/ 8192
`
`Convert Mbps to GBytes
`
`Cell capacity 35 Mbps
`
`3600 seconds per hour
`
`x 3600
`
`Busy hour average loading
`50%
`Busy hour carries 15% of
`daily traffic
`
`30 days per month
`
`3 sectors per site
`
`5 GB traffic per user
`
`x 50%
`
`/ 15%
`
`x 30
`
`x 3
`⇒ 4600 GB/site/month
`/ 5 GB
`
`Total
`
`920 subs/site
`
`Data rate based dimensioning
`
`Cell capacity 35 Mbps
`
`From simulations
`
`Busy hour average loading
`50%
`
`x 50%
`
`Required user data rate
`
`/1 Mbps
`
`Overbooking factor
`
`/20
`
`Average busy hour data
`rate per sub
`
`= 50 kbps
`
`3 sectors per site
`
`x 3
`
`Total
`
`1050 subs/site
`
`Figure 9.30 LTE dimensioning example for 1 + 1 + 1 at 20 MHz
`
`hour is assumed to carry 15% of the daily traffi c according to Figure 9.30 and the busy hour
`average loading is 50%. The loading depends on the targeted data rates during the busy hour:
`the higher the loading, the lower are the data rates. The maximum loading also depends on the
`applied QoS differentiation strategy: QoS differentiation pushes the loading closer to 100%
`while still maintaining the data rates for more important connections.
`The calculation shows that the total site throughput per month is 4600 GB. To offer 5 GB
`data for every subscriber per month, the number of subscribers per site will be 920.
`Another approach assumes a target of 1 Mbps per subscriber. Since only some of the sub-
`scribers are downloading data simultaneously, we can apply an overbooking factor, for example
`20. This essentially means that the average busy hour data rate is 50 kbps per subscriber. The
`number of subscribers per site using this approach is 1050.
`The calculation illustrates that LTE has the capability to support a large number of broad-
`band data subscribers.
`Figure 9.31 illustrates the technology and spectrum limits for the traffi c growth assuming
`that HSPA and LTE use the existing GSM sites. The starting point is voice only traffi c in a GSM
`network with 12 + 12 + 12 confi guration, which corresponds to a high capacity GSM site found
`in busy urban areas. This corresponds to 12 × 8 × 0.016 = 1.5 Mbps sector throughput assuming
`that each time slot carries 16 kbps voice rate. The voice traffi c was the dominant part of the
`network traffi c before fl at rate HSDPA was launched. The data traffi c has already exceeded
`the voice traffi c in many networks in data volume. The second scenario assumes that the total
`traffi c has increased 10 times compared to the voice only case. The sector throughput would
`then be 15 Mbps, which can be carried with three HSPA carriers using a 15 MHz spectrum.
`The last scenario assumes 50 times more traffi c compared to voice only, which leads to
`75 Mbps and can be carried with two LTE carriers each of 20 MHz with a total 40 MHz of
`spectrum. The site throughput will be beyond 200 Mbps, setting corresponding requirements
`for the transport network capacity also.
`
`IPR2022-00457
`Apple EX1010 Page 390
`
`

`

`Performance
`
`249
`
`Starting point
`voice only
`
`10x scenario
`
`50x scenario
`
`Sector throughput
`
`Required spectrum
`
`Site throughput
`(3 sectors)
`
`BTS configuration
`
`4.5 Mbps
`
`Figure 9.31 Traffic growth scenarios with 10 times and 50 times more traffic
`
`LTE ZOMI-Iz
`
`HSPA ISMI-Iz
`
`LTE ZOMI-Iz
`
`GSM5MHz+HSPA5MHz
`
`[E LTE lOMHz
`
`Figure 9.32 Example of a European operator with good spectrum resources
`
`An example of the availability of the spectrum resources by a European operator within a
`few years is illustrated in Figure 9.32: GSM with 5MHz, HSPA with 201Vle and LTE with
`SOMHZ. Such an amount of spectrum would allow the traffic to increase more than 50 times
`compared to the voice only scenario. There are many operators in Asia and Latin America
`with less spectrum resources, which makes it more difficult to provide the high broadband
`wireless capacities.
`
`9.10 Capacity Management Examples from HSPA Networks
`
`In this section some of the HSDPA traffic analysis in RNC and at the cell level is shown and the
`implications discussed. It is expected that the analysis from broadband HSDPA networks will
`also be useful for the dimensioning of broadband LTE networks. All the analysis is based on the
`statistics of a single RNC and up to 200 NodeBs. The NodeBs were equipped with a 5—code round
`robin type shared HSDPA scheduler where five codes of HSDPA are shared among three cells
`and the transport solution was 2*E1 per NodeB. The maximum power for HSDPA was limited
`to 6W. This area was selected to be analyzed as in this RNC the RF capability and transport
`capability are in line with each other, i.e. the transport solution can deliver the same throughput
`as the shared 5-code HSDPA scheduler. First it is necessary to evaluate the cell level data volume
`
`Samsung Ex. 1010
`382 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 391
`
`

`

`
`
`250 LTE for UMTS — OFDMA and SC—FDMA Based Radio Access
`
`fluctuations and contributions to RNC level total data volume so that the RNC throughput capacity
`can be checked. Then the cell level data volume and throughput limits are evaluated for when
`the new throughput improving features (proportional fair scheduler, cell dedicated scheduler,
`more codes, code multiplexing and so on) for the radio interface are introduced.
`
`9.10.] Data Volume Analysis
`
`Figure 9.33 shows the data volume distribution over 24 h for the RNC on a typical working day.
`It can be seen that the single hour data volume share is a maximum of 6% from the total daily
`traffic volume and the fluctuation is just 3% to 6%. Also the hourly data volume share from
`the busy hour data volume share is 50% during the early moming hours and steadily increases
`towards the busiest hours from 8 pm to 1 am. The 3 hours from 9 pm to midnight are the busi-
`est hours during the day. The usage increases heavily after about 6 pm, which indicates that as
`the working day ends then is the time for internet usage.
`Looking into the individual cell contribution to the total RNC level data volume in Figure
`9.34, it can be seen that during the night when the data volume is low and mobility is low, the
`traffic is also heavily concentrated on certain areas (cells) and during the day the share of cells
`contributing to the total data volume also increases.
`As can be seen from Figure 9.34 during the early morning hours, 10% of the cells con-
`tribute 70—85% of the total RNC level data volume whereas during the busiest hours the
`same 70—85% data volume is contributed by 19—25% of the cells. During the early moming
`hours the data volume is very concentrated on just a couple of cells, which means that cells
`covering the residential areas should have very high data volume during the night time and
`early morning and due to low mobility the channel reservation times should be extremely
`long. This is shown in Figure 9.35, which indicates that during the early morning hours the
`
`
`
`
`
`DataVolumePerHourFromMax
`
`|
`
`100%
`95%
`90%
`85%
`80%
`75%
`70%
`65%
`60%
`55%
`50%
`45%
`40%
`35%
`30%
`25%
`20%
`15%
`10%
`5%
`0%
`
`I
`
`10%
`
`9%
`
`5%
`
`4%
`
`3%
`
`2%
`
`1%
`
`0%
`
`8888888888888888838888 .
`OFNNVIO‘DFQUJOFNQVIDIDFQUJ
`a
`
`Figure 9.33 Daily RNC level hourly data volume deviation
`
`
`
`DataVolumeShara%FromDayTrafficVqumo
`
`
`
`
`
`Samsung Ex. 1010
`383 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 392
`
`

`

`251
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Performance
`
`1 00%
`
`95%
`
`%%%%%%%%5050505088776655
`
`3.8
`
`
`
`hoanEu38.xanSana—.2502m.53.oScam
`
`.$m
`
`$0
`
`$5
`
`$9
`
`$3
`
`o\aNN
`
`Qanw
`
`o\..5
`
`38
`
`$8
`$3
`o\oov
`.xbv
`$3.
`Amount of Cells
`
`"Kano
`
`{one
`
`.x.I.
`
`icon
`
`$om
`
`£33
`
`£60
`
`..\omm
`
`o\oma
`
`Figure 9.34 Cells’ data volume contribution to total RNC data volume
`
`
`
`100%
`
`95%
`
`90%
`
`
`75% 70%
`
` 0:00*0"50
`
`80%
`
`mvxvo
`
`mvavow
`
`ouvxvou
`
`8&98
`
`nvvxvov
`
`mmvxvon
`
`mavxvow
`
`mhvaON
`
`mwvxvom
`
`mavxvom
`
`ONwvxvoov
`
`8va03
`
`Swvxvowp
`
`OVNVXVONN
`
`8~vxvocu
`
`oumvxvoom
`
`convxvovn
`
`8vvxvown
`
`ovvvxvoNv
`
`omvvxvomv
`
`Sovxvoom
`
`8wvxvoou
`
`Suwnx
`
`Sowvxvooa
`
`HS-DSCH Allocation Duration per HS-DSCH Allocation [s]
`
`Figure 9.35 Average HS
`
`DSCH allocation duration CDF of cells
`
`Samsung Ex. 1010
`384 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 393
`
`

`

`252
`
`LTE for UMTS – OFDMA and SC-FDMA Based Radio Access
`
`average HS-DSCH allocation duration under the cell is a lot longer than during the highest
`usage. The lack of mobility and potentially some fi le sharing dominating usage during night
`time means that certain cells have extremely high data volumes at certain hours only and some
`cells have a fairly high usage and low data volume variation throughout the whole day. This
`makes effi cient cell dimensioning a challenging task as if capacity is given to a cell according
`to the busy hour needs, then some cells are totally empty during most times of the day.
`In Figure 9.36, the data volume fl uctuation per hour is shown as the cumulative distribution
`of cells having a certain percentage of data volume from the highest data volume during the
`specifi c hour. From the graphs it can be seen that during the early morning and low data volume
`times there is also the highest number of cells having the lowest data volume. This indicates a
`very high fl uctuation of data volume between all the cells.
`Figure 9.37 shows the busy hour share of the total daily traffi c on the cell level. The cells
`are sorted according to the data volume: the cells on the left have the highest traffi c volume.
`The busy hour carries 10–20% of the daily traffi c in busy cells. Figure 9.38 shows the dis-
`tribution of the cells depending on the percentage of the data carried by the busy hour. The
`most typical values are 10–15% and 15–20%. We need to note that the busy hour share on
`the RNC level was only 6%. The difference between the cell and RNC level traffi c distribu-
`tion is explained by the trunking gain provided by RNC since the traffi c is averaged over
`hundreds of cell.
`
`9.10.2 Cell Performance Analysis
`The cell performance analysis is carried out using the key indicators below:
`
` Active HS-DSCH Throughput – typically given in this analysis as kbps, it is the throughput
`under a cell when data have been sent in TTIs. Put simply it is the amount of data (kbit)/
`number of active TTIs (s) averaged over a 1 h measurement period.
` HSDPA Data Volume – typically given in this analysis as Mbyte, kbit or Mbit, it is the
`amount of data sent per cell during the 1 h measurement period.
` Average number of simultaneous HSDPA users, during HSDPA usage – the amount of
`simultaneous users during the active TTIs, i.e. how many users are being scheduled during
`active TTIs per cell (the maximum amount depends on operator purchased feature set).
`When taking the used application into account, the average number of simultaneous users
`during HSDPA usage needs to be replaced by the number of active users who have data in
`the NodeB buffers. Averaged over the 1 h measurement period.
` Allocated TTI share – the average number of active TTIs during the measurement period
`(i.e. when there are data to send, the TTI is active) over all the possible TTIs during the 1 h
`measurement period.
` Average Throughput per User – typically given as kbps, it is the Active HS-DSCH Throughput/
`Average number of simultaneous HSDPA users adjusted by the allocated TTI share; it is the
`average throughput that one single user experiences under a certain cell. When taking into
`account the used application, the Active HS-DSCH throughput needs to be divided by the
`number of active users who have data in the NodeB buffer. Averaged over the 1 h measure-
`ment period.
` Average reported Channel Quality Indicator (CQI) – every UE with HS-DSCH allocated
`measures and reports the CQI value back to the BTS. The average reported CQI is the
`
`(cid:129)
`(cid:129)
`(cid:129)
`(cid:129)
`(cid:129)
`(cid:129)
`IPR2022-00457
`Apple EX1010 Page 394
`
`

`

`
`
`Performance 253
`
`' ' ' 3:00 #4:“! —.—5:00 —I—6:00 —I—7fl0
`1:00 — ' 2:00
`
`
`9:00
`10:00
`11:00
`12:00
`I II 13:00
`14:!”
`I 0- 15:00
`
`
`
`
`22:00 +230020:00
`- t - 17:00
`
`
`
`*
`!.-:‘:*:-—.--
`-
`- ‘
`
`
`
`
`
`
`
` CDFofCells
`
`
`
`60%
`
`55%
`
`'
`
`X
`if
`6
`
`a?
`A
`9
`76
`g
`
`a?
`A
`0
`1’6

`
`A

`16
`a?
`9
`
`A
`5
`76
`a?
`m
`
`3'3
`32
`a?
`a?
`a?
`A
`A
`A
`A
`A
`A
`A
`A
`A
`A
`0

`0

`12

`0
`E
`0

`1’6
`1’6
`76
`)6
`1’6
`16
`1’6
`)6
`1’6
`1’6
`a?
`a?
`a?
`a?
`3?
`g
`3

`3

`2

`0

`0
`% Data Volume from Highest Data Volume Cell
`
`a?
`A
`:13
`1’6

`
`A
`5
`1’6
`a?
`2
`
`A

`76
`a?
`0
`
`a?
`A
`:5;
`1’6

`
`3‘3
`F
`8
`{2
`A

`
`Figure 9.36 Percentage data volume per cell from highest data volume cell per hour
`
`
`— Daily Data Volume per Cell
`—BH Share
`
`100%
`
`90%
`
`80%
`
`E
`70% if

`>
`60% q
`3
`z-
`
`50% g
`E
`40% g
`g
`30% g
`20%
`
`10%
`
`0%
`
`Samsung Ex. 1010
`386 of 1365
`
`Cells
`
`Figure 9.37 Busy hour share of cell level data volume
`
`100%
`95%
`90%
`35%
`30%
`
`g 75%
`._
`E
`70%
`3 65%
`‘5
`
`g 60%(I)
`i 55%
`o
`
`i 50%
`g
`45%
`7’,
`40%
`35%
`3‘
`30%
`g 25%20%
`15%
`
`> g
`
`10% ,
`5%
`0%
`
`IPR2022-00457
`Apple EX1010 Page 395
`
`

`

`254
`
`24%
`
`22%
`
`20%
`18%
`
`16%
`
`g14%
`312%
`§10%
`
`8%
`
`6%4%
`
`2%
`
`LTE for UMTS — OFDMA and SC—FDMA Based Radio Access
`
`
`
`I
`I
`I
`
`I
`I
`as
`at
`as
`at
`as
`a?
`as
`as
`a?
`at
`g§2§a§3§9§3§8§3§8§8§
`gA
`a
`g.
`9‘
`3
`a
`g.
`a
`g,
`Q
`g
`s:
`a:
`g:
`a:
`g
`g
`9,
`g
`g
`§§2§§§§§9§2§3§n§8§§
`BusyHourShamofCells
`
`Figure 9.38 CDF and PDF of data volume busy hour share
`
`100%
`
`90%
`
`80%
`
`70%
`
`60%%
`50%§
`40%8
`
`30%
`
`20%
`
`10%
`
`CQI value reported by all the UEs under the cell averaged over the 1 h measurement
`period.
`
`The end user throughput depends then on the average active HS-DSCH throughput and the
`average number of simultaneous HSDPA users. Figure 9.39 shows the average throughput as a
`function of the average number of simultaneous users. The average active HS—DSCH through-
`put is approximately 1.2 Mbps. When the allocated TTI share is low, the end user throughput
`approaches the HS-DSCH throughput. When the allocated TTI share increases, the end user
`throughput is reduced. This calculation is, however, pessimistic since it assumes that all users
`are downloading all the time.
`When the used application activity is taken into account, i.e. the active HS-DSCH throughput
`is divided by the number of users who have data in the NodeB buffer, the average throughput
`per user is quite different from the formula used above. Figure 9.40 shows the comparison of
`the two different average throughput per user formulas and the Active HS—DSCH throughput.
`It should be noted that Figure 9.39 and Figure 9.40 are not from exactly the same time. The
`end user throughput is 400—800 kbps when only those users are considered that have data
`in the buffer. This can be explained when analyzing the difference between the number of
`simultaneous users and the number of simultaneous users who have data in the NodeB buffer
`
`as shown in Figure 9.41.
`Figure 9.4] shows that the used application plays a significant role in the end user throughput
`evaluation and it should not be ignored. Therefore, the average user throughput may be low
`because the application simply does not need a high average data rate. The network performance
`analysis needs to separate the data rate limitations caused by the radio network and the actual
`used application data rate.
`
`Samsung Ex. 1010
`387 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 396
`
`

`

`Performance
`
`255
`
`+Active HS—DSCH throughput [kbps]
`
`Average Throughput per User [kbps] - .- Allocated TTI Share'100
`
`1400
`
`1300
`
`
`
`
`
`AverageThroughputperHSDPAUser
`
`
`
`[kbps],AverageActiveHS-DSCH
`
`
`
`
`
`1200
`
`1100
`
`1000
`
`97h010'1Non888888§
`
`
`
`Throughput[kbps]
`
`an088
`
`14
`
`13
`
`12
`
`11
`
`10
`
`9
`
`8
`
`7
`
`6
`
`5
`
`4
`
`3
`
`
`
`
`
`AllocatedTTIShare'100
`
`Average Number of Simultaneous HSDPA Users
`
`Figure 9.39 Average throughput per user
`
`
`- o - Average Throughput per User [kbps]
`Average Throughput per User (users with data in BTS buffer) [kbps]
`—~—Active HS-DSCH Throughput [kbps]
`
`
`
`
`
`
`
`§§§§
`
`O
`
`Figure 9.40 Average throughput per user, comparisons of different formulas
`
`Time [hour]
`
`Samsung Ex. 1010
`388 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 397
`
`

`

`256
`
`LTE for UMTS – OFDMA and SC-FDMA Based Radio Access
`
`Number of Simultaneous Users
`
`Number of Simultaneous Users, Data in BTS buffer
`
`22
`
`20
`
`18
`
`16
`
`14
`
`12
`
`10
`
`02468
`
`Number of Simultaneous Users
`
`Figure 9.41 Number of simultaneous users with and without taking the used application into account
`
`Time [hour]
`
`9.11 Summary
`3GPP LTE Release 8 enables a peak bit rate of 150 Mbps in downlink and 50 Mbps in uplink
`with 2 × 2 MIMO antenna confi guration in downlink and 16QAM modulation in uplink. The
`bit rates can be pushed to 300 Mbps in downlink with 4 × 4 MIMO and 75 Mbps in uplink with
`64QAM. It is expected that the fi rst LTE deployments will provide bit rates up to 150 Mbps.
`The LTE link level performance can be modeled with the theoretical Shannon limit when
`suitable correction factors are included. LTE link level performance was shown to be robust
`with high mobile speeds, and the uplink LTE performance can be optimized by using adaptive
`transmission bandwidth. The link level simulations are used in the link budget calculations,
`which indicate that the LTE link budget is similar to the HSPA link budget with the same data
`rate and same spectrum.
`The LTE system performance is optimized by orthogonal transmission schemes, by MIMO
`transmission and by frequency domain scheduling. The spectral effi ciency can be further
`enhanced with multi-antenna transmission and higher order sectorization. The high effi ciency
`can be maintained for different LTE bandwidths between 5 and 20 MHz, while the spectral
`effi ciency is slightly lower with the narrowband LTE carriers 1.4 and 3.0 MHz. It was shown
`that LTE provides higher spectral effi ciency compared to HSPA and HSPA evolution especially
`due to the frequency domain packet scheduling.
`The user plane latency in LTE can be as low as 10–20 ms. The low latency is relevant for
`improving the end user performance since many applications and protocols benefi t from low
`latency. The low latency is enabled by the short sub-frame size of 1 ms.
`
`IPR2022-00457
`Apple EX1010 Page 398
`
`

`

`Performance
`
`257
`
`The fl exible refarming of LTE to the GSM spectrum is enabled by the narrowband options:
`the refarming can be started with 1.4 or 3.0 MHz and later expanded when the GSM traffi c has
`decreased. All UEs need to support all bandwidths between 1.4 and 20 MHz.
`The dimensioning of the broadband wireless networks is different from voice networks.
`The examples from HSPA networks illustrate that the traffi c distribution over the day, over the
`geographical area and the user mobility need to be considered.
`
`References
` [1] 3GPP Technical Specifi cation 36.213 ‘Physical layer procedures’, v. 8.3.0.
` [2] 3GPP Technical Specifi cation 36.306 v8.2.0: ‘User Equipment (UE) radio access capabilities’, August 2008.
` [3] P. Mogensen et al. ‘LTE Capacity compared to the Shannon Bound’, IEEE Proc. Vehicular Technology Conference,
`pp. 699–703, April 2007.
` [4] 3GPP Technical Specifi cation 25.942 ‘Radio Frequency (RF) system scenarios’, v. 7.0.0.
` [5] 3GPP Technical Report 25.996 ‘Spatial channel model for Multiple Input Multiple Output (MIMO) simulations’,
`V.7.0.0.
` [6] I.Z. Kovács et al , ‘Effects of Non-Ideal Channel Feedback on Dual-Stream MIMO OFDMA System Performance’,
`IEEE Proc. Veh. Technol. Conf., Oct. 2007
` [7] I.Z. Kovács et al., ‘Performance of MIMO Aware RRM in Downlink OFDMA’, IEEE Proc. Veh. Technol. Conf.,
`pp. 1171–1175, May 2008.
` [8] S. Kumar, et al., ‘Performance Evaluation of 6-Sector-Site Deployment for Downlink UTRAN Long Term
`Evolution’, IEEE Proc. Vehicular Technology Conference, September 2008.
` [9] B. Hagerman, D. Imbeni, J. Barta, A. Pollard, R. Wohlmuth, P. Cosimini, ‘WCDMA 6 Sector Deployment-Case
`study of a real installed UMTS-FDD Network’, Vehicular Technology Conference, Vol. 2, pp. 703–707, Spring
`2006.
`[10] K.I. Pedersen, P.E. Mogensen, B. Fleury, ‘Spatial Channel Characteristics in Outdoor Environments and Their
`Impact on BS Antenna System Performance’, IEEE Proc. Vehicular Technology Conference, pp. 719–723, May
`1998.
`[11] 3GPP TSG RAN R1-072444 ‘Summary of Downlink Performance Evaluation’, May 2007.
`[12] 3GPP TSG RAN R1-072261 ‘LTE Performance Evaluation – Uplink Summary’, May 2007.
`
`IPR2022-00457
`Apple EX1010 Page 399
`
`

`

`10
`Voice over IP (VoIP)
`
`Harri Holma, Juha Kallio, Markku Kuusela, Petteri Lundén, Esa Malkamäki,
`Jussi Ojala and Haiming Wang
`
`10.1 Introduction
`While the data traffi c and the data revenues are increasing, the voice service still makes the
`majority of operators’ revenue. Therefore, LTE is designed to support not only data services
`effi ciently, but also good quality voice service with high effi ciency. As LTE radio only supports
`packet services, the voice service will also be Voice over IP (VoIP), not Circuit Switched (CS)
`voice. This chapter presents the LTE voice solution including voice delay, system performance,
`coverage and inter-working with the CS networks. First, the general requirements for voice and
`the typical voice codecs are introduced. The LTE voice delay budget calculation is presented.
`The packet scheduling options are presented and the resulting system capacities are discussed.
`The voice uplink coverage challenges and solutions are also presented. Finally, the LTE VoIP
`inter-working with the existing CS networks is presented.
`
`10.2 VoIP Codecs
`GSM networks started with Full rate (FR) speech codec and evolved to Enhanced Full Rate
`(EFR). The Adaptive Multi-Rate (AMR) codec was added to 3GPP Release 98 for GSM to
`enable codec rate adaptation to the radio conditions. AMR data rates range from 4.75 kbps to
`12.2 kbps. The highest AMR rate is equal to the EFR. AMR uses a sampling rate of 8 kHz,
`which provides 300–3400 Hz audio bandwidth. The same AMR codec was included also for
`WCDMA in Release 99 and is also used for running the voice service on top of HSPA. The
`AMR codec can also be used in LTE.
`The AMR-Wideband (AMR-WB) codec was added to 3GPP Release 5. AMR-WB uses a
`sampling rate of 16 kHz, which provides 50–7000 Hz audio bandwidth and substantially better
`voice quality and mean opinion score (MOS). As the sampling rate of AMR-WB is double the
`sampling rate of AMR, AMR is often referred to as AMR-NB (narrowband). AMR-WB data
`rates range from 6.6 kbps to 23.85 kbps. The typical rate is 12.65 kbps, which is similar to the
`
`LTE for UMTS: OFDMA and SC-FDMA Based Radio Access Edited by Harri Holma and Antti Toskala
`© 2009 John Wiley & Sons, Ltd. ISBN: 978-0-470-99401-6
`
`IPR2022-00457
`Apple EX1010 Page 400
`
`

`

`260
`
`LTE for UMTS - OFDMA and SC-FDMA Based Radio Access
`
`normal AMR of 12.2 kbps. AMR-WB offers clearly better voice quality than AMR-NB with the
`same data rate and can be called wideband audio with narrowband radio transmission. The radio
`
`bandwidth is illustrated in Figure 10.1 and the audio bandwidth in Figure 10.2. The smallest bit
`rates, 1.8 and 1.75 kbps, are used for the transmission of Silence Indicator Frames (SID).
`This chapter considers AMR codec rates of 12.2, 7.95 and 5.9 kbps. The resulting capacity
`of 12.2kbps would also be approximately valid for AMR—WB 12.65 kbps.
`When calling outside mobile networks, voice transcoding is typically required to 64 kbps
`Pulse Code Modulation (PCM) in links using ITU G.711 coding. For UE-to-UE calls, the
`transcoding can be omitted with transcoder free or tandem free operation [1]. Transcoding
`generally degrades the voice quality and is not desirable within the network.
`
`AMR—NB
`
`AMR-\VB
`
`23.35 kbps
`
`19.85 kbps
`
`
`Figure 10.1 Adaptive Multirate (AMR) Voice Codec radio bandwidth
`
`Human ear
`20-20000 Hz
`
`
`Wideband AIvIR
`50—7000 Hz
`
`
`
`
`Narrowband
`
`AMR
`300-3400 Hz
`
`Figure 10.2 Adaptive Multirate (AMR) Voice Codec audio bandwidth
`
`Samsung Ex. 1010
`392 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 401
`
`

`

`Voice over IP (VoIP)
`
`261
`
`There are also a number of other voice codecs that are generally used for VoIP. A few
`examples are G.729, using an 8kbps coding rate, and Internet Low Bit Rate Codec (iLBC),
`using 13 kbps which is used, for example, in Skype and in Googletalk.
`
`10.3 VoIP Requirements
`
`There is a high requirement set for the radio network to provide a reliable and good quality
`voice service. Some of the main requirements are considered below.
`The impact of the mouth—to-ear latency on user satisfaction is illustrated in Figure 10.3. The
`delay preferably should be below 200 ms, which is similar to the delay in GSM or WCDMA
`voice calls. The maximum allowed delay for a satisfactory voice service is 280 ms.
`1P Multimedia Subsystem (IMS) can be deployed to control VoIP. IMS is described in Chapter
`3. IMS provides the information about the required Quality of Service (QoS) to the radio network
`by using 3GPP standardized Policy and Charging Control (PCC) [3]. The radio network must
`be able to have the algorithms to offer the required QoS better than Best Effort. QoS includes
`mainly delay, error rate and bandwidth requirements. Q08 in LTE is described in Chapter 8.
`The voice call drop rates are very low in the optimized GSM/WCDMA networks today — in
`the best case below 0.3%. VoIP in LTE must offer similar retainability including smooth inter—
`working between GSM/WCDMA circuit switched (CS) voice calls. The handover functionality
`from VoIP in LTE to GSM/WCDMA CS voice is called Single radio Voice Call Continuity
`(SR-VCC) and described in detail in section 10.10.
`The AMR 12.2kbps packet size is 31 bytes while the [P header is 40—60 bytes. [P header
`compression is a mandatory requirement for an efficient VoIP solution. IP header compres—
`
`
`
`
`
`
`
`
`
`
`
`||
`
`
`
`||||||||||||||||
`
`
`
`\
`
`:5 ¢///¢W%¢W/%a
`W//////<<%//////m
`
`
`
`
`
`
`Ln;
`
`3:21.233?
`
`“$7
`
`LIIO
`
`\\
`///// /// ////////
`\
`.— OO
`
`N8
`
`300

`Mouth to ear delay (ms)
`

`
`
`
`$5?
`
` Nearly all
`
`/ users
`///
`A
`
`
`
`
`
`A
`G.l l4_F01
`
`Figure 10.3 Voice mouth-to-ear delay requirements [2]
`
`Samsung Ex. 1010
`393 of 1365
`
`IPR2022-00457
`Apple EX1010 Page 402
`
`

`

`262
`
`LTE for UMTS – OFDMA and SC-FDMA Based Radio Access
`
`sion is required both in UE and in eNodeB. All the VoIP simulations in this chapter assume
`IP header compression.
`The IP connectivity requires keep alive messages when the UE does not have a phone call run-
`ning. The frequency of the keep alive messages depends on the VoIP solution: operator IMS VoIP
`can use fairly infrequent keep alive messages since IMS is within the operator’s own network and
`no fi rewalls or Network Address Tables (NAT) are required in between. The internet VoIP requires
`very frequent keep alive message to keep the connectivity open through fi rewalls and NATs. The
`frequent keep alive message can affect UE power consumption and network effi ciency.
`VoIP roaming cases need further attention especially if there are some LTE networks designed
`for VoIP and data, while some networks are designed for data only transmission without the
`required voice features. VoIP roaming also requires IMS and GPRS roaming agreements and the
`use of visited GGSN/MME model. One option is to use circuit switched (CS) calls whenever
`roaming with CS Fallback for LTE procedures. Similarly CS calls can also be used for emer-
`gency calls since 3GPP Release 8 LTE specifi cations do not provide the priority information
`from the radio to the core network nor a specifi c emergency bearer.
`
`10.4 Delay Budget
`The end-to-end delay budget for LTE VoIP is considered here. The delay should preferably be
`below 200 ms, which is the value typically achieved in the CS network today. We use the fol-
`lowing assumptions in the delay budget calculations. The voice encoding delay is assumed to
`be 30 ms including a 20 ms frame size, 5 ms look-ahead and 5 ms processing time. The receiv-
`ing end assumes a 5 ms processing time for the decoding. The capacity simulations assume a

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket