A Diffserv Transport Network to Bring 3G Access to Villages in the Amazon Forest

Case study is not yet available.

Javier Simó-Reigadas, Universidad Rey Juan Carlos.

Since  their  conception,  IP  networks  have  been  generally  used  under  the  best-effort paradigm. Then, several QoS-aware IP network architectures were proposed in the last two  decades  by  the  IETF  and  other  actors,  being  DiffServ  the  most  successful,  and modern network technologies covering layers 1 and 2 such as ATM, Ethernet, WiFi or WiMAX have included mechanisms for traffic differentiation and some support for QoS. However, it is still uncommon to find a scenario were a QoS-aware network architecture such as DiffServ is adopted and the entire implementation is simple enough to be fully understood by undergraduate students.

This case study helps the student to understand what problems arise in an IP network when several terminals that need QoS guarantees share an IP infrastructure, and how the DiffServ architecture helps to solve the problem. Moreover, a practical implementation of queuing disciplines in the network nodes will be proposed. The student will learn how a simple embedded computer with Linux may become a DiffServ router, and how this can be applied to propose an appropriate communications solution for rural deployments in developing regions. This case study is based in the TUCAN3G project, a FP7 research project  that  aims  to  propose  a  low-cost  solution  for  3G  coverage  in  rural  areas  of developing  countries  (TUCAN3G,  2013).  The  student  will  firstly  receive  a  theoretical session about the fundamentals. Then, students will have to work on a problem resolution activity in which the theoretical concepts must be applied to a well defined scenario.

This activity is not intended to provide the student with a deep understanding on DiffServ and queuing disciplines. Students must have a good understanding on IP networks prior to  this  case  study,  and  it  can  be  valuable  if  they  have  already  studied  DiffServ  and queuing disciplines from a theoretical perspective. The case study will help the students  to integrate all the information and to associate the functionality of those tools with the needs identified in a real case.

LEARNING OUTCOMES 

The student  will  learn  how  DiffServ  contributes  (qualitatively  and quantitatively) to make an IP network QoS-aware.

The student will learn how to identify QoS limitations in an IP network, and to propose appropriate actions to improve the overall performance.

The  student  will  learn  how  to  apply  well-known  queuing  disciplines  to implement the per-hop behaviour (PHB) desired for a particular case in a DiffServ domain.

The  student  will  learn  how  QoS-aware  IP  networks  based  on WiFi  and WiMAX  may  become  a  key  solution  for  the  deployment  of  low-cost communications infrastructures in rural areas at developing regions.

ACTIVITIES    

The following learning activities will be proposed:

  1. Theoretical  session:  2  hours  class  on  QoS  (Quality  of  Service),  the  DiffServ  architecture and the implementation of a basic DiffServ  solution. The case study  will be presented as a means to understand the detailed performance problems to be  tackled  in  an  IP  network  in  which  certain  traffic  classes  require  QoS guarantees. Prior to this session, the student will have to read basic materials on QoS, DiffServ (referenced below) and queuing disciplines, or to have received a basic training on those subjects. It is also advisable for the students to read the context of this case study in advance.
  2. Problem resolution activity: the students will be organized in working groups and will  be  presented  a  communications  problem  based  on  the  same  context explained in the theoretical session. Several basic communications elements and techniques will be proposed, and each group will have to discuss about the right way to solve the problem and define all the details for the implementation of the network. The outcome will be a technical report produced by each group.

Add comment


Security code
Refresh