**3.1 Mesurement methodology**

Figure 8 shows xDSL and femto system installed in TELKOM RDC where ADSL2/ADSL2+ is used. The DSLAM node connected to metro-ethernet located in TELKOM OASIS building located in Bandung. The SecGW and FAP GW are connected to metro-ethernet (ME) backbone to reach SGSN in 3G core network (through Iu-PS interface). Iu-CS connection (FAP GW to MSC in other city, 200km away from OASIS testbed) is also available for CS voice call. The connection between xDSL and Femto System and between Femto System and SGSN are considered as controlled environment. Since GGSN is a commercial network, the network load may affect the femtocell performance, especially during busy hours. Another drawback, it is impossible to put measurement tool (such as end-point) in the GGSN side limiting the impact to commercial network performance. For this reason, the measurement tool or application server as end point is put in the internet cloud. In positive way, the femtocell trial performed in this activity, will reflect the real condition.

Fig. 8. xDSL as Femtocell Backhaul, A Reference Architecture

In order to derive bandwidth requirements (scenario 1) and femtocell performance (scenario 2), we define mix traffic composition which consists of HTTP, FTP, voice and video streaming. Individual content is defined according to the survey result conducted by TELKOM. There is several internet content accessed by subscribers of two major xDSL providers in Indonesia. As can be seen in Figure 9; facebook.com, detik.com, youtube.com, 4shared.com are among the most popular contents in Indonesia. Among top 10 internet content we choose detik.com or sometime facebook.com to represent HTTP traffic, youtube.com for streaming and 4shared.com to download files from internet. Traffic mix definition being used in the measurement is written in Table 3.

In order to capture bandwidth required by a single FAP, 4 simultaneous UEs are setup to access the FAP. This scenario will be used as a basis to observe minimum xDSL bandwidth requirement and also as a reference of configuring traffic models in STC for observing femtocell performance. Since our focus on backhaul bandwidth, we limit the impact of radio channel fluctuation due to interference and mobility. In this case, FUEs will access the FAPs in such away; the FAPs's signal quality is very good and stable.

148 Mobile Networks

Figure 8 shows xDSL and femto system installed in TELKOM RDC where ADSL2/ADSL2+ is used. The DSLAM node connected to metro-ethernet located in TELKOM OASIS building located in Bandung. The SecGW and FAP GW are connected to metro-ethernet (ME) backbone to reach SGSN in 3G core network (through Iu-PS interface). Iu-CS connection (FAP GW to MSC in other city, 200km away from OASIS testbed) is also available for CS voice call. The connection between xDSL and Femto System and between Femto System and SGSN are considered as controlled environment. Since GGSN is a commercial network, the network load may affect the femtocell performance, especially during busy hours. Another drawback, it is impossible to put measurement tool (such as end-point) in the GGSN side limiting the impact to commercial network performance. For this reason, the measurement tool or application server as end point is put in the internet cloud. In positive way, the

> **Metro Ethernet**

**TELKOM Backbone**

In order to derive bandwidth requirements (scenario 1) and femtocell performance (scenario 2), we define mix traffic composition which consists of HTTP, FTP, voice and video streaming. Individual content is defined according to the survey result conducted by TELKOM. There is several internet content accessed by subscribers of two major xDSL providers in Indonesia. As can be seen in Figure 9; facebook.com, detik.com, youtube.com, 4shared.com are among the most popular contents in Indonesia. Among top 10 internet content we choose detik.com or sometime facebook.com to represent HTTP traffic, youtube.com for streaming and 4shared.com to download files from internet. Traffic mix

In order to capture bandwidth required by a single FAP, 4 simultaneous UEs are setup to access the FAP. This scenario will be used as a basis to observe minimum xDSL bandwidth requirement and also as a reference of configuring traffic models in STC for observing femtocell performance. Since our focus on backhaul bandwidth, we limit the impact of radio channel fluctuation due to interference and mobility. In this case, FUEs will access the FAPs

GGSN

**Internet**

IuPS SGSN

**3G Core TELKOMSEL Jakarta**

IuCS-MSC

femtocell trial performed in this activity, will reflect the real condition.

SecGW

Fig. 8. xDSL as Femtocell Backhaul, A Reference Architecture

definition being used in the measurement is written in Table 3.

in such away; the FAPs's signal quality is very good and stable.

BRAS

**3.1 Mesurement methodology** 

**OASIS TestBed Bandung**

DSLAM

Modem

FAP

Fig. 9. Top 10 most visited internet content by subscriber of two ISPs in Indonesia


Table 3. Summary of traffic mix for femtocell performance using xDSL as the backhaul

The applications are accessed through various UE types including, smartphone and tablet PC. It is assumed that each user accesses only one service type. The traffic traversing through a FAP is recorded by Femto NMS. For this purpose, xDSL profile is set to maximum (20 Mbps), so that the original bandwidth required to send traffic will go smoothly without any congestion or queuing in the access network. Since we use commercial GGSN, the traffic will be affected by the GGSN load, however we anticipated by using 3G SIM Card with the highest priority QoS profile defined in HLR/GGSN. Furthermore the individual test is

Femtocell Performance Over Non-SLA xDSL Access Network 151

a) downlink b) uplink

In case of iPad being used as shown in Table 5, the downlink bandwidth consumption is about 857 kbps and the uplink is about 632 kbps. The uplink traffic for iPad is higher than smartphone because mix traffic mainly used by youtube. However as can be seen from Figure 11 peak throughput of 632 kbps is occurred only small portion compared to overall

> **Min (bps)**

Cs voice AMR 12,2 Kbps DL 84,800 8,480 77,372.7 466701399 Lognormal

Mix 4 CS call DL 339,200 8,480 298,168.5 8044648128 Lognormal

Mix All traffic DL 602,080 67,840 400,326.4 19280386460 Lognormal

So far we have derived the bandwidth requirement for femtocell by monitoring the

Table 4. Statistical properties of individual and mix traffic in smartphone case

BR for smartphone = 607 kbps (DL) and 175 kbps (UL)

BR for iPad = 857 kbps (DL) and 400 kbps (UL)

**Average (bps)** 

UL 84,800 8,480 77,372.7 466701399 Lognormal

DL 224,720 4,240 42,995.5 3116322837 Lognormal UL 106,000 0 29,400.4 886953056 Lognormal

DL 576,640 4,240 185,196.8 4640833694 Normal UL 42,400 0 16,178.7 43352265 Lognormal

DL 339,200 29,680 278,521.7 7042225332 Normal UL 71,016 8,480 27,326.68 148142570 Lognormal

UL 339,200 8,480 298,168.5 8044648128 Lognormal

UL 174,896 12,720 60,522.33 768972191 Lognormal

**Variance Distribution** 

Fig. 11. Femocell mix traffic bandwidth from 4 iPads, measured in xDSL (layer 2) and

**(bps)**

throughput shape, the rest of throughput is below 400 kbps.

**Traffic Content Strm Max** 

application (layer 7)

HTTP m.detik.com, first page

FTP www.4shared.com

Streaming m.youtube.com, "If

380 Kbps

throughput from Femtocell NMS.

5MB

"05.The Lazy Song",

you sleep in at my house, you are "Doom"ed", 41s, 240p,

repeated several times, i.e. 30 times effectively, but only the best 3 retries with similar statistical properties will be shown.

The measurement process was divided into two phases. Firstly, we captured individual bandwidth consumed by http, ftp, voice (AMR) and youtube streaming. The service was accessed from a smartphone connected to a FAP. Secondly, we observed the throughput for four simultaneous voice calls and mix traffic (HTTP, FTP, youtube, voice) from four different smartphone at the same time.

We repeated the similar observation for iPad. Since iPad is designed to access packet data only, hence voice AMR call cannot be tested. We replaced the voice call with facebook. We understood that most iPad users frequently download new applications, audio-video podcasts, mp3 music, ebooks from iTunes or Apple Store. For similarity with the observation in smartphone, we used ftp traffic from 4shared.com to download bigger file size compared to the one from smartphone. We also used the same page from detik.com. While from smartphone, mobile page version was displayed; in the iPad, full web page was displayed, hence the consumed bandwidth is different.
