ICT STP TUCAN3G Wireless technologies for isolated rural communities in developing countries based on cellular 3G femtocell deployments

Transcription

1 ICT STP TUCAN3G Wreless technologes for solated rural communtes n developng countres based on cellular 3G femtocell deployments M43 Multple flows control management Contractual Date of Delvery to the CEC: 31 th December 2013 Actual Date of Delvery to the CEC: 31 st January 2013 Author(s): O. Muñoz, A. Pascual, J. F. Rubo (UPC), A. G. Marqués, C. Fguera (URJC), K. Klgour, A. Ratanov (IPA), O. Tupayach, A. Ueunten (TdP) Partcpant(s): UPC, URJC, IPA, TdP Workpackage: WP4 Est. person months: 5,4 Securty: Int Dssemnaton Level: CO Verson: f Total number of pages: 39 Abstract: Ths s an nternal ntermedate document towards D43 defnng the requrements and procedures for the control of flows, ncludng the sensng of backhaul relevant qualty parameters (needs to be nterfaced wth 5A2), offloadng archtectures and key performance ndcators. These actvtes wll feed WP6. Bascally two topcs wll be addressed: traffc offloadng and user schedulng. The nvestgaton of traffc offloadng technques wll allow reducng the congeston of the backhaul, a crucal aspect n TUCAN3G. On the other hand, wth user schedulng and admsson control we tackle the optmzaton of the access network n the short-term. Nevertheless, ths latter aspect should also consder the requred backhaul qualty and the general desgn should take nto account the proper nterface between the access network and the transport network should be consdered. Keyword lst: traffc offloadng, VSAT cache, schedulng, admsson control, backhaul montorng, energy consumpton

2 Document Revson Hstory DATE ISSUE AUTHOR SUMMARY OF MAIN CHANGES 24th Oct 2013 a UPC Proposal of a prelmnary ToC 16th Dec 2013 b UPC, URJC Integraton of prelmnary contrbutons 28th Dec 2013 c UPC, IPA Update of the contrbutons 15th Jan 2014 d UPC, URJC, IPA Revson of contrbutons 31st Jan e UPC, TdP Incorporaton of contrbutons from TdP, and defnton of a workplan for D43 17th Mar 2014 f URJC, UPC Revew and fnal verson Delverable D43 scheduled work plan DATE 3rd- 7th March th March th March st March rd- 19th Aprl th Aprl th May th May st June th June th June st June 2014 DESCRIPTION Phone Call for dscussng the current state of the work for D43 and refne the ToC usng M43 1st call for contrbutons to D43 Partners n charge ncorporate new contrbutons and send the updated document to UPC UPC generates the frst verson of the D43 Phone Call for dscussng the current state of the work for D43 2nd call for contrbutons to D43 Partners n charge ncorporate new contrbutons and send the updated document to UPC UPC generates the second verson of the D43 2rd call for contrbutons to D43 Partners n charge ncorporate new contrbutons and send the updated document to UPC UPC generates a fnal verson of the document and t s dstrbuted to the techncal coordnator Document s delvered to the EC 1

3 ICT STP Document number: M43 Ttle of delverable: Multple flows control management Executve Summary Ths s an ntermedate document towards the elaboraton of delverable D43 n whch the man objectve s to descrbe the technques defned and analysed n the actvty 4A3, tacklng optmzaton of the access network n the short-term and the reducton of the requred backhaul traffc. In ths regard, the followng topcs are gong to be nvestgated: Traffc offloadng Schedulng and admsson control Interactons between the access network and the backhaul In each case the scenaros, the technques to develop and the workng plan are sketched. The fnal document (D43) wll descrbe how 4A2 and 4A3 nterface and how the conclusons wll nfluence the actvtes n WP6. TUCAN3G_M43UPCf.doc 2

4 DISCLAIMER The work assocated wth ths report has been carred out n accordance wth the hghest techncal standards and the TUCAN3G partners have endeavoured to acheve the degree of accuracy and relablty approprate to the work n queston. However snce the partners have no control over the use to whch the nformaton contaned wthn the report s to be put by any other party, any other such party shall be deemed to have satsfed tself as to the sutablty and relablty of the nformaton n relaton to any partcular use, purpose or applcaton. Under no crcumstances wll any of the partners, ther servants, employees or agents accept any lablty whatsoever arsng out of any error or naccuracy contaned n ths report (or any further consoldaton, summary, publcaton or dssemnaton of the nformaton contaned wthn ths report) and/or the connected work and dsclam all lablty for any loss, damage, expenses, clams or nfrngement of thrd party rghts. 3

5 ICT STP Document number: M43 Ttle of delverable: Multple flows control management Table of Contents 1 INTRODUCTION OBJECTIVES ORGANIZATION TRAFFIC OFFLOADING NETWORK ARCHITECTURES AND BENEFITS OF TRAFFIC OFFLOADING IMPLEMENTATIONS IN 3GPP NETWORKS Offloadng mplementatons complyng wth the 3GPP standard Non-standard offloadng mplementatons: Data traffc cachng over satellte Internet cachng Internet cachng tests n Telefónca del Perú Concluson Regulatory ssues EXPECTED OUTPUTS ACTIVITY WORK PLAN SCHEDULING AND ADMISSION CONTROL CHANNEL STATE-AWARE PACKET SCHEDULING Sngle HNB technques DL schedulng UL schedulng Admsson control Multple HNB technques Expected outputs Effort dstrbuton INTERACTIONS BETWEEN THE ACCESS NETWORK AND THE BACKHAUL Overvew QoS preservaton n the BH BH state nformaton for AN algorthms desgn AN and BH jont optmzaton GPP background QoS requrements for AN traffc Requrements for Access Network procedures Informaton requrements Procedures requrements Methods for obtanng BH state and comments on algorthms executon Backhaul aware admsson control and packet schedulng Expected outputs Effort dstrbuton RECOMMENDATIONS TOWARDS OTHER WORK-PACKAGES TUCAN3G_M43UPCf.doc 4

6 References [Amegeras03] P. Amegeras, Packet schedulng and Qualty of Servce n HSDPA, PhD Thess, Dept. of Communcaton Technology, Aalborg Unversty, Denmark, Oct [Ellot02] R. C. Ellot, and W.A. Krzymen, Schedulng Algorthms for the cdma2000 packet data evoluton, n Proc.of the IEEE Vehcular Technology Conference (VTC), Vancouver, Canada, vol. 1, pp , September 2002 [Fernandez13] J. Fernandez-Bes, A. G. Marques, and J. Cd-Suero, Battery-aware selectve communcatons n energy-harvestng sensor networks: Optmal soluton and stochastc dual approxmaton, n Proc. of 10th Intl. Symposum on Wreless Commun. Systems, Aug [Gatss10] N. Gatss, A. G. Marques, and G. B. Gannaks, Power Control for Cooperatve Dynamc Spectrum Access Networks wth Dverse QoS Constrants, IEEE Trans. Commun., vol., pp., 2010 [Goldsmth05] A. Goldsmth, Wreless Communcatons, Cambrdge Unv. Press, [Holma06] H. Holma and A. Toskala, WCDMA for UMTS HSPA EVOLUTION AND LTE, 4th Edton, John Wley & Sons, Ltd. [Huang06] J. Huang, R. A. Berry, and M. L. Hong, Dstrbuted nterference compensaton for wreless networks, IEEE J. Select. Areas Commun., vol. 24, no. 5, pp , May 2006 [IETF-RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamn, ReSerVaton Protocol (RSVP) Verson 1 Functonal Specfcaton, RFC 2205, September [IETF-RFC2474] K. Nchols, S. Blake, F. Baker and D. Black, Defnton of the Dfferentated Servces Feld (DS Feld) n the IPv4 and IPv6 Headers, RFC 2474, December [IETF-RFC3031] E. Rosen, A. Vswanathan, R. Callon, Multprotocol Label Swtchng Archtecture, RFC 3031, January [IETF-RFC2638] K. Nchols, V. Jacobson and L. Zhang, A Two-bt Dfferentated Servces Archtecture for the Internet, RFC 2638, July [Khan11] Khan, M. F., Khan, M. I., & Raahemfar, K.; "Local IP Access (LIPA) enabled 3G and 4G femtocell archtectures". In Proceedngs of the 24th IEEE Canadan Conference on Electrcal and Computer Engneerng (CCECE), pp , May 2011 [Lee10] Lee, K., Lee, J., Y, Y., Rhee, I., & Chong, S.; "Moble data offloadng: how much can WF delver?". In Proceedngs of the 6th Internatonal COnference (p. 26). ACM, November 2010 [Ln10] Ln, Y. B., Gan, C. H., & Lang, C. F.; "Reducng call routng cost for femtocells". IEEE Transactons on Wreless Communcatons, pp , vol. 9, no. 7, July 2010 [Palomar06] D. Palomar and M. Chang, A tutoral on decomposton methods for network utlty maxmzaton, IEEE J. Select. Areas Comm., vol. 24, no. 8, pp , Aug

7 ICT STP Document number: M43 Ttle of delverable: Multple flows control management [Stanczak06] [SCF13] [TUCAN3G-D21] [TUCAN3G-D22] [TUCAN3G-D41] [TUCAN3G-M52] [TS ] [TS ] [TS ] [TS ] [TS ] [Wang07] [Zdarsky11] S. Stanczak, M. Wczanowsk, and H. Boche, Resource Allocaton n Wreless Networks: Theory and Algorthms. Berln, Germany: Sprnger, 2006 Small Cell Forum Release Two documents, avalable onlne at ICT STP TUCAN3G, Soco-economc scenaros, techncal specfcatons and archtecture for the proof of concept, delverable D21, May 2013, Avalable onlne: ICT STP TUCAN3G, Operatonal Techncal Handbook, delverable D22, May 2013, Avalable onlne: ICT STP TUCAN3G, UMTS/HSPA network dmensonng, delverable D41, November 2013, Avalable onlne: ICT STP TUCAN3G, Transport network archtecture and nterface to the access network, mlestone M52, January 2013, to be publshed on-lne. 3GPP Techncal Specfcaton TS Qualty of Servce (QoS) concept and archtecture 3GPP Techncal Specfcaton TS End-to-end Qualty of Servce (QoS) concept and archtecture 3GPP Techncal Specfcaton TS Local IP Access and Selected IP Traffc Offload (LIPA-SIPTO) - Release 10 3GPP Techncal Specfcaton TS Iuh Data Transport 3GPP Techncal Specfcaton TS UTRAN Archtecture for 3G Home Node B (HNB) X. Wang, G.B. Gannaks, and A.G. Marques, A Unfed Approach to QoS-Guaranteed schedulng for channel-adaptve wreless networks, n Proceedngs of the IEEE, vol. 95, no. 12, Dec Zdarsky, F. A., Maeder, A., Al-Sabea, S., & Schmd, S.; "Localzaton of data and control plane traffc n enterprse femtocell networks". In Proceedngs of the 73rd IEEE Conference on Vehcular Technology (VTC Sprng), pp. 1-5, May 2011 TUCAN3G_M43UPCf.doc 6

8 Lst of abbrevatons & symbols ABI AMC AN AP AWGN BH BLER CQI CS CDMA CPICH DffServ DSCP GGSN HMS HNB HNB-GW HSDPA IntServ LIPA MPLS PDP QoS RAB RSVP RTCP RTP RTT SDP SIP SIPTO UDP UMTS UE SF SNIR TDMA AN-BH nterface Adaptve Modulaton and Codng Access Network Access Pont Addtve Whte Gaussan Nose Backhaul Block Error Rate Channel Qualty Indcator Crcut Swtched Code Dvson Multple Access Common Plot Channel Dfferentated Servces Dfferentated Servces Code Pont Gateway GPRS Servce Node HNB Management System Home NodeB Home NodeB Gateway Hgh-Speed Downlnk Packet Access Integrated Servces Local IP Access Multprotocol Label Swtchng Packet Data Protocol Qualty of Servce Rado Access Bearer Resource Reservaton Protocol Real Tme Control Protocol Real Tme Protocol Round Trp Tme Sesson Descrpton Protocol Sesson Intaton Protocol Selected IP Traffc Offload User Datagram Protocol Unversal Moble Telecommuncatons System User Equpment (the moble termnal and SIM Card) Spreadng Factor Sgnal-to-Nose plus-interference Rato Tme Dvson Multple Access 7

9 ICT STP Document number: M43 Ttle of delverable: Multple flows control management 1 INTRODUCTION The present document descrbes the work to be carred out n actvty 4A3. The man objectve s the optmzaton of the access network (AN) n the short-term (schedulng perod), n contrast wth the work developed n actvty 4A1 of WP4 [TUCAN3G-D41], where the network plannng s exposed, and also n contract to the work carred out n actvty 4A2 of WP4 [TUCAN3G M42], where the access network s optmzed and montored n the long-term (multple schedulng perods). The short-term access network optmzaton deals wth topcs lke channel state-aware packet schedulng, congeston and admsson control. Nevertheless, all these topcs also depend on the qualty of the backhaul, demandng certan knd of coordnaton between transport network and the access network. Desgnng the backhaul s an aspect of paramount mportance n the project. The envsoned network archtecture depcted n Fgure 1 has been ntroduced n [TUCAN3G-D21]. It should be noted that lnear-lke archtecture of the transport network has hgher probablty to produce congeston n the lnks close to the backhaul GW especally when the traffc demand ncreases. In ths respect, there are several nvestgatons on dfferent technques amng at the reducton of the backhaul load by means of traffc offloadng and local cache for satellte lnks. Fgure 1. Network archtectures consdered n: left) Napo rver and rght) Balsapuerto 1.1 Objectves Evaluate dfferent possbltes for transport network offloadng. TUCAN3G_M43UPCf.doc 8

10 Propose procedures allowng effectve control of multple flows when the access network s connected to a varable qualty transport network. Defnton of the nterface between the access network (AN) and the backhaul (coordnaton wth work-package WP5) 1.2 Organzaton Ths document s organsed as follows. Secton 2 nvestgates dfferent traffc offloadng strateges wth the objectve of reducng the use of the backhaul. The nvestgated technques wll consder 3GPP and non-3gpp based solutons and wll take nto account the legal requrements of each soluton. Secton 3 addresses the schedulng and admsson control and t s dvded nto two man sub-sectons. In sub-secton 3.1 the channel state-aware packet schedulng s consderng when there s just one servng Home Node B (HNB) or when there are multple HNBs. Energy consumpton wll be an aspect to be consdered for the decsons. Admsson control procedures are also nvestgated n ths secton. On the other hand, f ths nterface s nvestgated n sub-secton 3.2 t appears to be part of the schedulng and admsson control, rather than offloadng. Fnally, secton 4 provdes a summary of the technques nvestgated and could be consdered for mplementaton. 9

11 ICT STP Document number: M43 Ttle of delverable: Multple flows control management 2 TRAFFIC OFFLOADING Femtocells or Home Node B were orgnally conceved to mprove 3G/4G ndoor coverage for home subscrbers. In that scenaro, HNBs relay the traffc towards the core network usng a prvate (typcally xdsl) backhaul network. In TUCAN3G, femtocells are used to provde outdoor coverage. On the other hand, whle classcal macrocells or NBs (Node B) are connected to the core network usng an optcal fber, HNBs n TUCAN3G are connected to the core usng a WF multhop network. In ths confguraton, the traffc load s expected to be hgher than n the ndoor confguraton due to hgher number of users, whle the capacty s severely constraned than the orgnal scenaro due to use of lmted WF. Ths problem s even more acute n deployments where the connecton wth the core network also ncludes a satellte segment. A soluton to reduce the load of the backhaul network and avod outages assocated to overloads s to mplement offloadng technques allowng smart routng of local traffc [Lee10]. Secton 2.1 wll consder dfferent alternatves to mplement offloadng mechansms and evaluate the benefts for the network performance. Secton 2.2 wll analyze how the offloadng mechansms can be mplemented n actual 3GPP networks as well as potental recommendatons of the standards. 2.1 Network archtectures and benefts of traffc offloadng In ths actvty several alternatves to mplement offloadng technques for the consdered scenaros wll be analyzed, whch wll take nto account the current standardzatons efforts (LIPA/SIPTO solutons, enterprse archtectures ) and wll consder both voce and data offloadng. The actvty wll conclude wth some recommendatons regardng the confguraton of offloadng schemes. The alternatves analyzed n ths document are (see Fgure 2): a) nstallng a gateway/proxy n the backhaul, b) local swtchng of users served by the same HNB, and c) shortest path. Fgure 2. Dfferent alternatves for local offloadng. UE 1 s connected to UE 2 and UE 3 s connected to UE 4. The purple route corresponds to alternatve a (nstallng a gateway/proxy n the backhaul); the yellow route corresponds to alternatve b (local swtchng of users served by the same HNB); and the green route corresponds to alternatve c (shortest path). Note that the yellow lne connectng UE3 and UE4 though the core network s the conventonal route we target to shorten for a better usage of the backhaul. TUCAN3G_M43UPCf.doc 10

12 Alternatve a) conssts n nstallng a gateway n the node that connects the backhaul to the core network [Ln10][Zdarsky11]. Ths avods sendng local traffc to the core network, whch s a good soluton for deployments where the connecton between the backhaul and the core s lmted or expensve (for example, when t s mplemented usng a satellte lnk). Alternatve b) conssts n connectng the users served drectly by the same HNB [Khan11]. Ths opton s approprate to access to local data and to voce calls between close-by users. Alternatve c) conssts n routng all local traffc through the backhaul network usng the route wth the shortest number of hops. Although t s dffcult to mplement n practce, ths soluton wll serve as a benchmark to assess the benefts of mplementng local swtchng. The performance wll be evaluated usng smulatons. The focus wll be placed frst on evaluatng the gans n terms of rate ncrease and congeston reducton. If the results are satsfactory, then the mpact on energy consumpton wll be evaluated too. Local offloadng on both voce and data traffc wll be consdered (frst each of them separately and then jontly). The key aspects of the smulatons wll be: 1) network topology; 2) lnk confguraton (termnals and effectve throughput); and 3) traffc models. If the smulatons suggest that traffc offloadng mechansms should be mplemented n practce, then more features such as channel varablty (due to fadng, weather condtons, ) and solar refll patterns wll be taken nto consderaton too. Each of the key aspects s descrbed n more detal next. 1) The topology of the backhaul network wll have a crtcal mpact on the performance gans assocated wth local offloadng. Clearly, long networks wth many hops wll beneft more from smart routng technques. The two scenaros consdered n TUCAN3G (Balsapuerto San Juan & San Gabrel- and Napo Santa Clotlde, Negro Urco & Tutapsco-) wll be analyzed. If convenent, topologes not explctly consdered n TUCAN3G but that may be relevant for rural deployments wll be analyzed too. 2) Some requrements of the dfferent technologes n the access and backhaul network wll be taken nto account n the smulatons to measure the key performance ndcators. Among those are: a) the actual technology mplemented (WLD, WMAX satellte lnk,..); b) HNB can serve a relatve small number of users; or c) IP encapsulaton of voce traffc n the uplnk s dfferent from that n the downlnk; just to name a few. 3) One of the most mportant aspects to evaluate the benefts s to estmate the amount of local traffc. Although some models exst for voce traffc, there s lttle nformaton about data traffc. To mtgate that problem, smulatons wll consder a broad range of scenaros rangng from low to very hgh local traffc. Regardng the total traffc consumed by the users, the smulatons wll consder the patterns of traffc along the day provded n [TUCAN3G-D41] (populaton, penetraton, tnerancy, traffc per user). 2.2 Implementatons n 3GPP networks The am of ths subtask s to analyse how the schemes studed n 2.1 can be mplemented n actual 3GPP networks and, n partcular, n the network deployed n TUCAN3G. Two types of solutons wll be analysed: solutons that comply wth the 3GPP standard (releases 10 and later) and solutons that do not (pre-standard or non-standard). Correspondng recommendatons, based on the fndngs n ths subtask, wll be provded to WP Offloadng mplementatons complyng wth the 3GPP standard 3GPP has standardsed Local IP Access (LIPA) and Selected IP Traffc Offload (SIPTO) mechansms snce 3GPP Release 10, gradually addng more functonalty. Recently, p.access has carred out work 11

13 ICT STP Document number: M43 Ttle of delverable: Multple flows control management wthn the Small Cell Forum to look at enterprse data and offload archtectures. Some of the results are avalable n the references [SCF13]. These nclude the ntroducton of ntermedate gateways for data and voce offloadng, and moblty wth reduced sgnallng towards the core network. LIPA was desgned as a servce to allow a rado bearer access through a specfc local IP address that s not publcly accessble e.g. t s not on the publc nternet. The orgnal use cases nclude access to enterprse ntranets, home meda storage, as well as prnters [TS ]. SIPTO s a smlar offloadng optmsaton allowng a rado bearer towards a publc address to be offloaded wthout traversng the operator core network, unlke LIPA. In the case of TUCAN3G deployment scenaros, the backhaul transporton to the Core Network s expected to have a hgh latency n addton to exstng lmted bandwdth problem whch probably causes multple congestons due to the deployment condtons. Consequently, t s hghly benefcal to use a technology to reduce the load (ether sgnallng or user data) on the backhaul. In the future, wth an expected growth of the populaton of the communtes wll ental a sgnfcant ncrease of the local traffc, ncludng voce (VoIP). The reference archtectures wll take advantage of ths. Such technques may also mprove the user experence. The delverable D43 wll descrbe the examned archtectures and, for each one, wll look at the potental benefts of the remote deployment scenaros for both publc and local data and wll seek to make use of analyss carred out n secton 2.1. In addton, the qualtatve gans to the user experence wll also be descrbed Non-standard offloadng mplementatons: Data traffc cachng over satellte In addton to the ones n 3GPP standards, there are pre-standard or non-standard mplementatons, ncludng some on the border of content delvery, that provde alternatve offload mechansms. When analysed n detal, t can be seen that some of the mechansms are smpler to mplement and adapt to the specfc scenaros consdered n TUCAN3G. Although such technques may provde consderable benefts to the user experence, some of the proposed mplementatons wll also have dsadvantages n terms of relablty, flexblty, modfcatons to exstng protocols, securty, and exposure of the nternal structure of the core network (e.g. IP addresses usage). Delverable D43 wll further analyse a number of these non-standardsed mplementatons dentfed n the lterature and descrbe ther benefts and dsadvantages. Specal emphass wll be placed on local cache technques for satellte lnks as they are one of the mportant and problematc part of TUCAN3G due to ther hgh cost and at the same tme, the only soluton to backhaul n certan solated areas. Internet content keeps expandng rapdly wth rcher contents and web stes whch nclude more and more vsual materals statc and moton based (e.g. Adobe Flash technology, java scrpts). Nowadays, typcal web pages are larger than ever (e.g. They can easly host more than 250 and be accessble through over 240 HTTP requests, whle ther contents are also very dynamc requrng preloadng. In addton, Web stes become very dynamc wth content preloadng every tme the user moves ther cursor over an object or lnk. On the other hand, home and busness networks have far more networkng devces than ever, wth laptops, tablets, Phones and many other devces connectng va 3G networks or WF. In Peru, consderng rural nformaton from Ftel s TdP BAS ( Wde Band for Isolated Localtes ) Project, the most vsted webpages are Google, Youtube, Wndows Update and Facebook. Ths exploson Internet of contents makes the access through VSAT really challengng. Throughout the past decade, VSAT equpment manufacturers were able to mprove web performance usng varous web acceleraton technologes: Content cache: Onboard cache memory for recently or frequently accessed documents, objects or scrpts and prefetch documents that are lkely to be accessed, DNS cachng. TUCAN3G_M43UPCf.doc 12

14 HTTP Compresson: Use of encodng methods. Code Optmzaton: Optmzng java or http code to send the less nformaton possble, ths feature ncludes Whte Space Removal and compressng mages Among the three, only the frst requres addtonal network elements and s relevant to the proposed TUCAN3G archtecture. Although tradtonal herarchcal web cache control technologes provde tremendous mprovement n web user experence, satellte-cache dstrbuton technologes could extremely mprove the results. Ths progress can be obtaned by utlzng a large on-board mult Ggabyte memory n the central cache. Ths way, a large amount of web content could be stored and by takng advantage of the nherent one-to-many satellte network topology, to dstrbute and populate content on the cache memory of all VSATs n a partcular network. Each object n a web page has a date of "expraton" whch s used by cache devces to understand f the object can be saved and how long. The use of cache devces reduces the number of requests by provdng memory local cache, prevously captured data and by mprovng the response tmes (n average) and the use of bandwdth Content cachng Cachng s not new to Internet technology. Cachng technology lke other acceleraton methods s desgned to reduce bandwdth and enhance the user experence. The man dea of content cachng s to store popular content whch s frequently accessed by the users. Whenever a user desres to access the requred content, the content s fetched mmedately from the local cache storage nstead of fetchng t from the remote web server. Today cache servers are deployed throughout the Internet at ether the core (carrers), the edge Internet Servce Provders (ISPs) or the end user locatons. Cachng s also avalable on web browsers. In low roundtrp delay networks, the combned use of cachng by the ISP and cachng at the browser wll provde enough performance mprovement to end users. However, when ISPs and end users are separated by ~600msec of round trp delay and an expensve transmsson path (space segment), the performance mprovement s dmnshed. Fgure 3. Web Cache-Archtecture 13

15 ICT STP Document number: M43 Ttle of delverable: Multple flows control management As shown n Fgure 3 cache servers at the hub locaton are typcally nstalled by satellte ISPs n order to reduce the terrestral backhaul usage and to brng content closer to the user. Nevertheless, the traffc stll needs to travel more than 72,000 km between the hub and the end user. The objectve of satellte cache technology s to brng the content wthn a shorter dstance (hence wth lower delays) to the end users based on Dstrbuted Cache archtecture located at every ste n the network. In ths archtecture each cache stores the content that has been accessed by local users and then common content s also shared wth all other cache elements n the network. As a result each cache devce contans all of the content that has been accessed by any user n the network. Ths archtecture s mostly sutable for VSAT networks because of the nherent one-to-many broadcast characterstcs of satellte. Content needs to be transmtted only once over the satellte to be receved and stored by each of the satellte network nodes Content cachng tests n Telefónca del Perú In February 2013, Telefonca Peru and GILAT satellte networks carred out a 5-days tests of nternet traffc download. Optmzaton was done usng web cachng features on VSAT modems. Durng the tests, Web Enhance VSAT (manufactured by GILAT) s used for dstrbuted cachng, and Skymon software s used to measure the traffc offloadng optmzaton. The man focus of the analyss was the satellte bandwdth optmzaton, as well as the mprovement of the user experence wth faster downloads. The tests were performed n two dfferent scenaros: Controlled envronment wth one VSAT Multple VSATs One VSAT workng n a controlled envronment The purpose of ths experment s to test VSAT cache capablty drectly and under controlled condtons. The smplfed archtecture of the test envronment s gven n Fgure 4, where there s one VSAT placed n the lab and two computers connected to the VSAT. Fgure 4. Smplfed archtecture for the experments wth one VSAT For the test, a bref lst of webpages s selected for the tests, then they opened n PC1. Snce the VSAT cache was empty at the begnnng, all the page detals had to be downloaded entrely through the outbound. These pages were opened from the PC1. Snce the VSAT cache was empty, all the pages were entrely transmtted through the Outbound. The next step conssted to access the same lst of pages, but ths tme from the PC2. In ths case, many of the objects of those pages were downloaded drectly from the VSAT cache. TUCAN3G_M43UPCf.doc 14

16 Fgure 5 depcts the Outbound kpbs graph assocated to the VSAT that was montored from the Skymon. Ths fgure ncludes both downloads, from the PC1 (all pages and tems are served entrely n the Outbound), and from the PC2. In the left sde of Fgure 5 we observe the outbound traffc durng the tme all pages are downloaded from the PC1, whle the rght sde of Fgure 5 shows the outbound traffc durng the download from the PC2 (usng the VSAT cache). As expected, the outbound traffc for the PC2 s relatvely lower and VSAT cachng succeeded to reduce n more than 20% the outbound usage. Fgure 5. Outbound graph assocated to the VSAT On the other hand, we evaluated the download tme for both stuatons as gven n Table 1. The frst column shows the selecton of the web pages used durng the tests, whle the second and the thrd column show download duratons for the attempts from PC1 and PC2 respectvely. Except for a couple of partcular cases, the second attempt has a lower download tme. Multple VSATs Table 1. Webste download tme comparson (n seconds) In the confguraton shown n Fgure 6, 9 operatonal VSAT are nstalled n Internet cafes. The objectve of ths second phase conssts of determnng the outbound savngs for a long term traffc by addng the cache capablty of representatve stes whle they work all day long. Ths wll gve a good ndcaton of quanttatve values assocated to total bandwdth savng on the outbound f t s assumed to have smlar traffc pattern and smlar number of computers n most of the VSAT locatons. 15

17 ICT STP Document number: M43 Ttle of delverable: Multple flows control management Fgure 6. Archtecture for the experments wth multple VSAT For the representaton of the results, unlke the phase 1 tests, outbound Kbps graphs are not gong to be used to be able to determne the cachng functonalty n a drect and precse way. Instead, specfc graphs are gong to be used to represent the Kbps f no cachng was used and the number of bps transmtted over the satellte when fnally cachng capablty s appled. Outbound Kbps graphs are not gong to be used for ths phase n the VSAT, as t was used n phase. Not only HTTP traffc wll be used. Wth the knd of representaton shown below, t s not possble to determne the HTTP traffc percentage that was saved because of the cachng functonalty n a drect and precse way. In contrast, specfc graphcs drectly assocated to the Web Enhance capabltes are used. These graphs represent the number of Kbps that would have been transmtted by the outbound (f there s no cache n the VSAT) versus the Kbps that are fnally transmtted over satellte (whch correspond to all the objects that have not been provded snce the VSAT to clent computers). Fgure 7 and Fgure 8 depcts the outbound HTTP traffc (n Kbps) related only to the VSATs cache capablty. In addton, any other traffc from VSATs wth no cachng capablty s dscarded. The blue lne corresponds to the results when no cachng n the VSAT was consdered, whle the orange lne denotes the results when cachng s avalable. From Fgure 7 and Fgure 8 we can remark the followng observatons: Cache-based soluton saves 15-20% of requred throughput In the busy hours, those savngs are up to 40%, whch corresponds to 1-2 Mbps for the 9 stes Concluson Based on the results of these tests, TdP consders that the approach of data traffc optmzaton for Internet servces over satellte provdes sgnfcant gans, whch are accumulatve to those approaches based on centralzed cachng or based on data compresson, n terms of backhaul capacty savngs and faster downloads. TdP recommends the use of ths approach for savng capacty n the satellte backhaul and mprovng the tme of downloads n TUCAN3G. TUCAN3G_M43UPCf.doc 16

18 Fgure 7. HTTP traffc n KBps durng averaged over a 4-day test Fgure 8. HTTP traffc n KBps durng 7-day test Regulatory ssues One mportant ssue appears on local voce offloadng; as standardzed methods, nether LIPA nor SIPTO offers voce offloadng through operator's core network by ther defnton. Therefore, n case an operator has a regulatory requrement whch requres to ntercept the user data (also known as Lawful Intercept [TS ]), alternatve mechansms to gather ths data are needed f the mplementaton s to be vable. Smlar ssues also occur n the related area of non-standard solutons 17

19 ICT STP Document number: M43 Ttle of delverable: Multple flows control management (content cachng and local swtchng n general). An understandng of these ssues s mportant for any operator consderng a remote deployment. In D43, a descrpton of types of Lawful Intercept requrement wll be gven and the range of mechansms (or none) to facltate these requrements for both standardsed and non-standardsed archtectures n rural scenaros. Suggestons wll be made on regulatory and operator approaches that may allow deployment of these archtectures. 2.3 Expected outputs The man outputs (documents) to be generated at the end of the actvty wll be the followng: Benefts of traffc offloadng. The dfferent offloadng solutons presented brefly n secton 2.1 wll be descrbed n detal. The benefts n terms of power consumpton and traffc congeston wll be analysed va smulatons. Dfferent scenaros wll be analysed (regardng network topology, local traffc patterns). The results wll be analysed and recommendatons for the other tasks/substasks wll be provded. Archtectures and solutons for local offloadng complyng wth the 3GGP standard. Dfferent archtectures wll be descrbed, ther strengths and weaknesses wll be dentfed, and ther convenence/compatblty to TUCAN3G deployment scenaros wll be dscussed. Archtectures and solutons for local offloadng sutable for TUCAN3G that do not comply wth the 3GPP standard. Dfferent archtectures sutable for TUCAN3G wll be descrbed, and ther strengths and weaknesses wll be dentfed. A methodology for the selecton of one or another wll be descrbed. The Lawful Intercept problem n voce and data traffc, so that offloadng schemes can be actually deployed. Recommendatons for WP Actvty work plan Accordng to [TUCAN3G-D22], all the actvtes to be developed n the framework of traffc offloadng wll be developed durng the perod from 1st June 2013 to 30th June 2014, wth correspondng detals provded n the followng table. Task Descrpton Input Output To PM Partner 4A3.1 Benefts of traffc offloadng Local traffc demand models and long haul traffc demand models (4A1) Evaluaton of backhaul congeston and recommendatons of perhop backhaul capacty needs as a functon of traffc evoluton WP4 1.5 URJC 4A3.2a Proposal of traffc offloadng technques and archtecture elements Procedures and evaluaton results of 4A3.1 Recommendatons for mplementaton and standardzaton WP6, WP7 0.5 IPA Table 2. Actvtes related to the elaboraton of D43 TUCAN3G_M43UPCf.doc 18

20 3 SCHEDULING AND ADMISSION CONTROL Ths secton nvestgates the optmzaton of the access network n the short-term. Frst, secton 3.1 addresses the optmzaton of rado resources by means of user schedulng and admsson control takng nto account the current state of the channel, the nterference level and the current state of the backhaul. In ths regard, secton 3.2 nvestgates mechansms to exchange control and state nformaton between the access network and the backhaul. 3.1 Channel state-aware packet schedulng Dynamc schemes that adapt the avalable resources (codes, power levels, user-hnb schedulng) to the nstantaneous (channel) state nformaton are a key element to mtgate fadng and guarantee QoS n wreless networks [Goldsmth05]. The desgn of such schemes has been a very actve research topc. As a result, most contemporary standards nclude advanced mechansms to mplement fast channel-aware resource allocaton. Orgnally, the schemes were typcally desgned n a heurstc manner, under reasonable assumptons. Nowadays, the schemes are typcally desgned as the (approxmate) soluton to judcously formulated optmzaton problems [Stanczak06], [Palomar06]. The selecton of the formulaton s ndeed crtcal. On the one hand, t must be sophstcated enough to ncorporate the operatng condtons of the network as well as the QoS requrements of the related applcatons. On the other hand, t must gve rse to smple solutons that can be easly mplemented n practcal systems (e.g., by entalng low computatonal complexty and beng amenable to dstrbuted mplementatons). In ths secton channel state-aware packet schedulng technques are consdered frstly for a sngle HNB and secondly for multple HNB. Whle n the frst case the nterference s consdered as fxed, n the second case the schemes to be desgned wll consder the nterference generated by other HNBs. In any case, the traffc and the classes of servces demanded by the actve users demand wll be taken nto account Sngle HNB technques Ths secton addresses channel state-aware packet schedulng technques for sngle HNB (UL and DL), whle consderng the nterference generated by other cells as fxed. Furthermore, the mpact of the schedulng on the other cells (.e. nterference generated) s not consdered DL schedulng Frstly, we wll consder downlnk schedulng. Gven a power budget for the HNB, the goal s to optmze the number of codes and the power allocated to each user to maxmze a utlty functon that depends on the user data throughputs, whle guaranteeng the voce servce to each user. To address the problem we wll consder a set of voce users, K v, and a set of data users, K d, already admtted n the system (admsson control wll be consdered n a dfferent secton). In case that a certan user has a data connecton and a voce connecton smultaneously, t wll be treated as two ndependent users, one for each connecton (even though the HNB lmtatons apply to ndvdual users, even f they bear two types of servce). If the HNB lmts the total number of users n the system, then the number of elements n both K v and K d,.e. K v and K d, wll be both less than ths maxmum number. In case that the HNB lmts the number of data connectons and voce connectons ndependently, we wll establsh a dfferent lmt for the number of elements n K and K. We wll consder that each data user may receve several channels wthn a pool of N d channels (n HSDPA the maxmum number of HS-DPSCH channels,.e., the physcal channels used for data transmsson, s less than or equal to 15). We wll consder that each voce user s assgned one 19 v d

21 ICT STP Document number: M43 Ttle of delverable: Multple flows control management dedcated physcal channel from a pool of N v voce channels (each one consderng, for nstance, a spreadng factor (SF) of 128), wth Nv Kv. If the data channels and the dedcated channels for voce use the same carrer, the power of the carrer and the code tree s shared between both types of channels. Ths mposes a common constrant over the total number of avalable data codes, n D. As the number of avalable codes wth greater spreadng factors depends on how many codes wth shorter spreadng factors are used, the total number of avalable channels for data, n D, wll be a functon of the number of voce channels n use,.e., nd K V. If the power of the carrer s shared among data and voce channels, there s a common constrant n the HNB power as well. Denotng p the power assgned to each of the codes gven to the -th user: The sum of the total power assgned to data channels, The total power assgned to voce channels, power avalable at the HNB, P T. KV np, KD p, must be less than or equal to the total All of the above may summarze mathematcally n the followng constrants: KD n n K D V np p PT KD KV (1) Let us defne vector r d as a vector contanng the users data rates, r for K D. Wthn ths secton we wll focus on maxmzng a utlty functon that ncreases wth the user data rates, u r d, whle guaranteeng the qualty of the voce calls. Such a problem may be formulated as follows: p, n, ptd maxmze u r d p s.t. 1: log L C r n 2 1 M, for K d 2 ( pj ptd p) jk V L p L C2 : MV SNIR0, for KV v 2 ( ptd pj ) jkv L D D j C3: np p PT KD KV C4 : n n K KD C5: n p p KD D V TD (2) TUCAN3G_M43UPCf.doc 20

22 In problem (2), M D and M V denote the code gan for data and voce users respectvely (t s dfferent as the SF of voce and data channels may be dfferent), d and v denote the orthogonalty factor for data and voce users respectvely (deally ths orthogonalty factor s zero, n practce t wll be a value 2 less than 1), L s the equvalent channel path-loss between HNB and the -th user, and represents the power of the nose-plus-ntercell nterference experenced by the -th user. The rate constrant (C1 n (2)) s a lmt for the rate of each data user (accordng to Shannon law), and the constrant C2 mposes a mnmum receved sgnal-to-nose plus-nterference rato (SNIR) for each voce user. Fnally, note that we have ntroduced an addtonal varable, p TD, that stands for the total power assgned to data users,.e. constrant C5. In problem (2), constrant C3 must be fulflled wth equalty. Notce that f we fnd a soluton for the prevous problem, where equalty C3 s acheved wth strct nequalty, we can always multply all powers p by a common factor greater than 1 untl equalty C3 s fulflled wth equalty. By dong ths, the SNIR for both data users (see C1 n problem (2)) and voce users (see C2 n problem (2)) mproves (the numerator ncreases more than the denomnator, as the nose power s not multpled by the common factor). Therefore, the SNIR constrant for voce users s stll fulflled and the rate for the data users may be ncreased whch n turns wll ncrease the cost functon. On the other hand, the SNIR constrant for voce users, see C2 n problem (2), must be also acheved wth equalty, as any other soluton that fulflls the SNIR constrant wth strct nequalty mples a power spendng hgher than necessary and, consequently, hgher levels of nterference to data users. As the constrant C2 and C3 n problem (2) must be acheved wth equalty, the problem (2) can be actually separated n two parts: p L P1: C2: MV SNR0 v 2 ( ptd pj ) j KV L (3) j C3: ptd p PT KV P2 : maxmze p, n, ptd u C4 : n n K KD C5: n p p KD d p L s.t. C1: r n log 1 M, for K 2 D D d 2 ( PT p) L r D V TD (4) The frst part, P1 stated n (3), defnes a set of lnear equatons system wth KV 1 equatons and K 1 unknowns. By solvng ths set of equatons, we may compute the power requred for each V voce user, p * for K 21 V, and the avalable power for data, p * TD, to guarantee the voce servce. The second part, P2 stated n (4), s an optmzaton problem that depends on the powers assgned to each code and number of codes assgned to each user.

23 ICT STP Document number: M43 Ttle of delverable: Multple flows control management To fnd a soluton that solves both problems smultaneously, the strategy wll be as follows: we * compute frst the power for each voce user to guarantee the voce servce, p for KD and the * remanng power s then left for the data users, p TD. Then, as a second step we dstrbute the number of codes and power avalable for data among the data users accordng to the chosen utlty functon, *.e., we wll solve P2 for ptd ptd Note that we can use a greater tme scale for the problem P1 than for the problem P2. Ths approach s actually close to a practcal mplementaton as HSDPA uses the remanng power of the carrer,.e., not used for dedcated channels. Furthermore, the resource allocaton for HDSPA channels may be faster (2 ms) than for voce users. To solve problem P2 we need to defne a certan utlty functon. As a prelmnary study we focus on maxmzng a utlty functon that depends on the rate of data users, krk. The weghts k can be kkd adjusted to mnmze average delay, maxmze farness, etc. The problem can then be wrtten as follows: P3: maxmze n log 2 1 M p, n KD D p L ( P p ) L d 2 T (5) s.t. n nd KV. KD wth K V the total number of voce users. Let us consder two smple schedulng strateges: TDMA and CDMA. a) The TDMA approach conssts n selectng n every schedulng perod (for nstance every 2 ms) one user and gvng all the avalable codes and avalable power for data transmsson. It can be proved that ths approach s the optmum soluton of the followng smplfed problem, where the cost functon s a lower bound of the prevous one P3 a: maxmze n log 2 1 M p, n KD s.t. n nd KV. KD D d PT L p L 2 (6) If the user selected to get all the resources durng the schedulng perod fulflls the nequalty * ptdk1 1k1 1, then the users are ordered (wthout loss of generalty) as follows: N k 2 2 TUCAN3G_M43UPCf.doc 22

24 k k k wth M D k P 2 L KD KD T d. b) CDMA: The CDMA approach conssts n dvdng all the power among the avalable data channels, and decdng how many codes are to be assgned to every user. Pb 3 : maxmze nlog 1 M n KD 2 D * ptd PT * ptd NL d ( ) N L s.t. n nd KV. KD The soluton for problem (7) s actually to gve all N codes to the user wth the hghest value for * p TD NL log 2 1 M D. * ptd d 2 ( PT ) N L 2 (7) In practce, the CDMA approach s closer to a practcal mplementaton. Wth HSDPA, varable SF and fast power control are dsabled and replaced by adaptve modulaton and codng (AMC) and extensve mult-code operaton. In HSDPA the CQI (channel qualty ndcator) defnes the codng and modulaton combnaton supported by the termnal for a BLER equal to or lower than 10%, accordng to the E c /I o measured n the CPICH channel. The dea n HSDPA s to enable a schedulng such that, f desred, most of the cell capacty may be allocated to one user for a very short tme, when channel condtons are favorable. The total number of channelsaton codes wth SF 16 s respectvely 16 (under the same scramblng code). In the code doman perspectve, the SF s fxed; t s always 16, and mult-code transmsson as well as code multplexng of dfferent users can take place. The maxmum number of codes that can be allocated s 15, but dependng on the termnal capablty, ndvdual termnals may receve a maxmum of 5, 10 or 15 codes. The Transmsson Tme Interval (TTI) or nterleavng perod has been defned to be 2 ms whch s shorter compared wth the 10, 20, 40 or 80 ms TTI szes supported n Release 99 [Holma06]. The assgnment of all the resources to a certan user must consder the channel condtons n order to acheve a good spectral effcency. However, buffer status, farness, etc. should play a sgnfcant role as well. Accordng to [Holma06], the scheduler n the Node B evaluates for dfferent users what are the channel condtons, how much data are pendng n the buffer for each user, how much tme has elapsed snce a partcular user was last served, for whch users retransmssons are pendng, and so forth. The exact crtera that have to be taken nto account n the scheduler s a vendor-specfc mplementaton ssue. Several publcatons lst dfferent HSDPA packet scheduler optons, ncludng [Ellot02],[Amegeras03]. In the fnal verson of the delverable, dfferent schedulng approaches wll be tested and compared. More specfcally, we plan to extend an algorthm derved at UPC to manage the queues wth the purpose of mnmzng the average delay experenced by each of the multple flows managed by the HNB, and compare wth other approaches that work wth a lnearzaton of the average delay ([Wang07]). 23

25 ICT STP Document number: M43 Ttle of delverable: Multple flows control management UL schedulng Smlarly to the work done for the DL, allocaton of codes and power to each actve user wll be consdered n ths secton. The man dfference s that now there s a power budget constrant per user, not per HNB. Followng the notaton used n the prevous subsecton for the DL case, let K V and K D denote the set of voce and data users, respectvely. Also, p represents the power allocated to each of the codes used by user. For the case of voce users, the SNR has to fulfll the followng condton: p L MV SNR0 K pj pj 2 n j j KD L j jkv L j j V (8) where we emphasze that the target SNR has to be acheved wth equalty (any other soluton that fulflls the SNR constrant wth strct nequalty mples a power spendng hgher than necessary and, consequently, hgher levels of nterference). The power of the nose plus nter-cell nterference 2 represented by s equal for all the users snce now the HNB plays the role of the recever and s the same for all the users and connectons. Note also that the orthogonalty factor does not appear n the prevous expresson snce n UL we assume that users are not synchronzed n tme. As n the DL case, the number of data codes has to fulfll the followng condton (followng the same notaton): n n (9) D Note that, dfferently from the DL case, n UL each user has an ndependent constrant related to the maxmum number of data codes to be used as each user s allocated a dfferent scramblng code. Let us defne the followng varable that takes nto account the nose plus nter-cell nterference n addton to the receved power correspondng to the data connectons: p j n j (10) jkd L j 2 2 nd Accordng to ths, the set of equatons presented n (8) can be wrtten n matrx form as follows (each row corresponds to each of the voce users that are assumed to be numbered wth the followng order: 1,2,..., KV, beng K V the total number of actve voce users): p1 L 1 M SNR SNR SNR 1 p V SNR0 MV SNR0 SNR 0 L nd SNR 0 SNR0 SNR0 SNR0 M V p 1 KV L KV (11) TUCAN3G_M43UPCf.doc 24

26 Note that all the prevous equatons are completely symmetrc wth respect to users. That means that all the users wll fulfll that the power allocated to the voce connecton s nversely proportonal to the path loss (or, n other words, the powers receved at the HNB from all the voce users wll be equal): p L K V 2 nd SNR0 M SNR K V 0 V 1 (12) As commented at the begnnng of ths secton, n the UL scenaro, the transmt power constrants are () () ndvdual,.e., on a per-user bass. That means that f p L PT for some voce user (where P T represents the maxmum transmsson power for the -th user), then the SNR constrants cannot be fulflled and some users should be dropped off from the system. Note that ths mples that SNR p SNR P M SNR K M SNR K L j KD 2 () nd T 0 j 2 0 n j mn 1 1 KV D L j () P MV SNR KV 1 V 0 V j K V 0 V p j T n j mn KV L j L SNR (13) f we want that all the voce users are served properly. It s nterestng to emphasze that the prevous condton s just a constrant over the maxmum total receved power at the HNB correspondng to the data connectons. Usng the prevous partal result concernng the voce users, we can now formulate the resource allocaton problem (n terms of number of codes and powers) for the data users. As n the DL case, the rate for the -th data user can be upper-bounded as (the followng expresson has been obtaned by combnng properly (10) and (12)): p L r n log2 1 M, K pj pj p 2 n j jkd L j jkv L j L D D nlog 1M 2 D 2 p j nd SNR0 KV p 2 n j jk 0 1 D L j M V SNR K V p L nlog2 1MD p j p 2 cv nj cv j KD Lj L SNR0 KV where cv s defned as cv 1 M SNR K p L L V 0 V 1 (14) Now, the fnal resource allocaton problem for the data users can be wrtten as follows (agan, we use the same formulaton as n the DL case unless stated otherwse): 25

27 ICT STP Document number: M43 Ttle of delverable: Multple flows control management maxmze p, n, K D u r d p L s.t. r n log 2 1 M, K p j p 2 cv nj cv j KD Lj L () p j P K T V 2 C1: nj mn KV j K 1 D L j L c V D D C2 : n n K C3: n p D D P K () T D (15) The prevous problem has to be solved resortng to numercal suboptmum solutons that nvolved a lnearzaton of the rate constrant for data users as ths constrant s not convex n general. Partcular utltes functons (ncludng the weghted sum-rate) and strateges to solve the problem for these specfc utlty functons wll be ncluded n the fnal verson of the delverable Admsson control In prevous sectons we have consdered a set of K V and K D users already admtted n the system, wth the only lmtaton mposed by the maxmum number of users (total or voce and data users). However, there are other lmtatons such as the power budget or QoS requrements. If the power budget s not enough to guarantee the voce servce, t means that the batteres are very close to run down. On the other hand, f the QoS for data traffc s below an acceptable qualty, some of the users should not be admtted n the system. Technques for user selecton are to be preempted wll be explaned n the fnal verson of the delverable. These technques wll consder the presence of a bandwdth lmted backhaul wth average transmsson rate constrants Multple HNB technques In ths subtask, the focus s on desgnng dynamc resource allocaton schemes (both uplnk and downlnk) that account for the topology of the access network. Ths mples that users of dfferent cells wll be jontly optmzed (n contrast wth the prevous subtask, where the optmzaton was carred out only for users wthn the same cell). The man modfcatons n the problem formulaton are: a) The objectve now needs to consder all users and HNBs jontly. Ths can be acheved by usng a multobjectve optmzaton approach or just by redefnng the objectve as weghted sum. b) Users must be allowed to be served by dfferent HNBs. Ths way one of the varables to desgn (optmze) are the schedulng varables that ndcate whch HNB s servng a specfc user. (Ths problem s somehow related to the classcal problem of assgnng a channel/frequency to a specfc user n orthogonal access networks [Goldsmth05].) It wll be shown that the decson of assgnng a specfc HNB to serve a specfc user does not depend only on the channel condtons of the user, but also on the nterference generated by the other users and the overall load of the HNB. c) Another mportant ssue s whether the soluton s gong to be found n a centralzed or n a dstrbuted manner. The approach n ths subtask wll be frst to solve the problem assumng that all nformaton s avalable and then to develop (sem-)dstrbuted solutons [Stanczak06], TUCAN3G_M43UPCf.doc 26

28 [Huang06], [Gatss10]. Key for ths wll be the mplementaton of dual approach to solve the optmzaton problem and the defnton of auxlary varables that wll facltate the separablty of the optmzaton problem n the dual doman (dual decomposton [Palomar06]). To ncorporate nto the optmzaton some of the partculartes of the networks n TUCAN3G, the problem wll account explctly for the battery levels and the power consumpton model. The dea s that f a HNB s short of battery, users should be served by other close-by HNBs. To do so, we wll follow the approach n [Fernandez13], whch deals wth energy-harvestng wreless sensor networks, and adapt t to the operatng condtons of our networks. Intally, only the power consumed by the HNBs servng the user wll be consdered, but later on, the power consumpton of the entre route from the femto to the core network wll be consdered too (ths clearly corresponds to desgn resource allocaton schemes for the access network that account for the state of the backhaul network, and wll be subject of research n the correspondng subtasks). The fact of femtos beng able to serve a relatvely small number of users smultaneously (see [TUCAN3G-D41]) wll also be accounted for n the formulaton. Ths mples that mechansms for admsson control have to be consdered too. As a frst step, users should be rejected only f the maxmum number of smultaneous actve connectons has been reached. However, one can also envson scenaros where HNBs that are severely lmted (e.g. when the energy stored n the battery s very low) reject connectons that have a low prorty (or that requre a very hgh power to be served) so that future hgh prorty requests can be served. Smplfed example: To llustrate better the approach to be followed n the task, we present a smplfed formulaton that would gve rse to a prelmnary desgn. Let p and γ denote the transmt-power and SNIR of user, u (γ ) a SINR utlty functon for user (the hgher the SNIR, the more satsfed the user), j (p ) a power cost functon for user I (the hgher the power, the hgher the cost/unsatsfacton of the user). The power consumed by the HNB l s P l, the assocated cost s J l (P l ). Moreover, let h,l denote the power channel gan between user and HNB l and w,l denote a Boolean varable whch s one f user s assgned to HNB l and zero otherwse. Wth t denotng the tme nstant, the optmal power and schedulng can then be found as the soluton to the followng problem maxmze T t1, l l, l, t st.. C1: w t 1 l C2: w t t l C3: wl, t u l, t j p t Jl Pl t mn l, l, p t h, l t p t h t l m, l m T T 1 1 C4: P t Enl t T l t1 T t1 C5: Pl t f w, l t p t (16) where En l (t) s the energy stored n the battery at HNB l and f( ) s a functon that relates how much power consumes the HNB to receve and forward the nformaton sent by the users. 27

29 ICT STP Document number: M43 Ttle of delverable: Multple flows control management The formulated problem s not convex and ts soluton s non-trval (see, e.g., for a related problem n a dfferent context [Gatss10]). However, t can be shown that the optmum schedulng follows a shortterm greedy strategy, a strategy that assgns the user to the HNB that maxmzes the short-term utlty of the system. Such an utlty not only accounts for the nstantaneous terms n the objectve, but also for the nterference generated to other users, the power consumed by the HNB and the correspondng battery level Expected outputs The man outputs to be generated at the end of the actvty wll be the followng: Development of channel state-aware packet schedulng technques for a sngle HNB, management of multple flows and admsson control, gven the power budget and the state of the battery of the HNB. Development of channel state-aware packet schedulng technques for multple HNBs, ncludng optmum assocaton of the users to one HNB. The nterference caused to other HNBs, the power consumpton and the battery level of the HNBs wll be consdered for desgnng the sutable procedures. Methods for QoS-preservng schedulng and admsson control wth backhaul-aware constrants wll be proposed for the 3G access network as a functon of the qualty and saturaton level of both the access network and the backhaul Effort dstrbuton Accordng to [TUCAN3G-D22], all the actvtes to be developed n the framework of channel stateaware schedulng wll be developed durng the perod from 1st June 2013 to 30th June 2014 wth the followng effort Task Descrpton Input Output To PM Partner 4A3.3 Sngle-HNB channel state-aware packet schedulng Local traffc demand, state of the network (short term) Procedures to be fed to task 4A3.4 and possbly to WP6 WP7 1 UPC 4A3.4a 4A3.4b Multple-HNB channel state-aware packet schedulng (emphass on schedulng and admsson solutons) Multple-HNB channel state-aware packet schedulng (emphass on on/off and coverage provson) Local traffc demand, state of the network (short term) Local traffc demand, state of the network (short term) Procedures to be fed to WP6, wth the comparson of those currently used n commercal HNB Procedures to be fed to WP6, wth the comparson of those currently used n commercal HNB WP7 1 URJC WP7 2 UPC 3.2 Interactons between the access network and the backhaul The mechansms descrbed n the prevous sectons requre the backhaul (BH) and the access network (AN) to exchange control and state nformaton. The Iuh standard was ntended to cope wth a relable BH wth relatvely lmted (by macro-cellular terms) capablty, such as a DSL lne, where only some jtter may be present. However, 3GPP protocols assume that the operator dmensons suffcent backhaul capacty to cope wth the antcpated traffc load and QoS needed, whlst recognzng that TUCAN3G_M43UPCf.doc 28

30 certan unspecfed congeston control mechansms may be used n the case of overload. Hence, no procedure for nteracton between both networks has been standardzed by the 3GPP, and the HNB s desgned to be backhaul-technology agnostc. Therefore, n the TUCAN3G scenaro an nterface between AN and BH shall be desgned and possbly mplemented. In the case of a remote deployment such as TUCAN3G, potental congeston s a serous problem for the overall user experence and affects servce dmensonng, and so acqures ncreased mportance at the desgn level. Some form of traffc shapng.e. prortzng dfferent classes of user traffc, sgnalng traffc and management traffc n order to keep the system operatonal as well as managng the user experence s lkely to be needed. Regardng the work dstrbuton n the TUCAN3G, WP4 s devoted to the AN, whle WP5 focuses on the BH. Therefore, the AN-BH nterface (ABI) needs a coordnaton of both workpackages (secton 5 of [TUCAN3G-M52]). Specfcally, ths secton s organsed as follows. Frst, secton provdes a bref summary of the contents of secton 5 n [TUCAN3G-M52]. Secton revews the 3GPP standard for dealng wth non-3gpp transport networks nsde a 3GPP network. Furthermore, n secton we dscuss the QoS requrements of the dfferent traffc classes supported by the AN and the correspondng nformaton that must be passed to the BH. The requrements for schedulng and admsson control procedures are revewed n Secton Secton analyses dfferent methods for obtanng the BH nformaton; and fnally secton descrbes how the BH state can be ncorporated n the optmzaton algorthms descrbed n secton Overvew The ABI shall enable nteractons n both BH to AN and AN to BH drectons. Not only the AN requres the state nformaton from the other sde, but also the BH needs to know not only the QoS requrements for each connecton establshed by the AN. Moreover, f a jont optmzaton approach s also consdered, control mechansms (messages from the scheduler to the BH) should also be provded by the nterface. At least three types of nteractons are needed n the ABI, whch are represented n Fgure 9. Sold thck arrows represent data or sgnallng exchange, whle slashed thn arrows represent logcal nteractons. These nteractons are descrbed next. Fgure 9. AN to BH nterface (ABI), wth man nteractons. 29