IP TRANSPORT ARCHITECTURE

Next, we present the architectural details for the IP transport link between the BS and the GW. Presence of multiple service classes with different QoS requirements running on a native IP link with constrained capacity necessitates prioritization and scheduling among the arriving packets. Internet Engineering Task Force (IETF) has standardized the differentiated services architecture (DiffServ) for large-scale deployment of IP networks with QoS support. They have provided three types of service to packets: expedited forwarding (EF), assured forwarding (AF), and best effort. The applications requiring absolute delay bound are mapped to EF class. For providing the average delay bound, we use the AF class. We propose to use the proportional delay differentiation (PDD) model of Dovrolis et al. for providing different delays to the subclasses within the AF class. The PDD-based approach is unique in its simplicity and tractability. Recently, many real-time applications have been successfully mapped to delay and loss differentiation parameters of the PDD subclasses.

Next, we discuss the architectural details of a forwarding interface of the BS. For this purpose and toward discussions in later sections, consider multiple sources which want to send their traffic from BS (A) to GW (B) connected by a direct link ℓ.

Consider now the BS (A) and GW (B) routers. Assume that the concerned forwarding interface on BS A to GW B has been configured for n EF subclasses and m AF subclasses. At the interface, each source is mapped to EF or AF class based on whether the class requires absolute or average delay. The mapping to subclass (such as i) within the class (EF or AF) is based on the source application running at the source (voice, video, etc.). The IP link (A-B) has to support a set of sources . In Figure 1, we present the architecture of the forwarding interface of BS A, supporting DiffServ. Let the capacity of the direct link connecting BS (A) to GW (B) be c. We assume that the bandwidth is distributed among the n EF subclasses, AF class and BE class using a weighted fair queuing scheduler (WFQ) where the vector h determines the weights used in scheduling. This ensures that each EF subclass on the link gets no less bandwidth than , where

(17.1a)

 
Figure 1: Forwarding interface of BS A.

Here,  is the minimum bandwidth required for subclass i to provide the target delay  to the sources belonging to the class. Similarly, h^AF captures the weight for the AF class which translates into minimal bandwidth of

(17.1b)

c^AF is the total bandwidth available to the AF class such that can be shared between the m subclasses. The bandwidth c^BE available to the BE class can be computed as

(17.1c)

Multiple sources belonging to the same subclass (EF or AF) at the BS A are placed in the queue for the subclass on a first-come-first-serve basis. Let the set of sources belonging to the ith EF subclass be , then every source  has a absolute delay requirement . Similarly, for the ith AF subclass, sources  have an average delay requirement such that . Source s belonging to AF or EF class has an average arrival rate of r_s. When generated by an on–off source model, it has a peak rate of R_s and the on period of average length I_s. Such a source can be effectively shaped by an LB filter of parameter (σ_s, ρ_s), where ρ_s is the average arrival rate and σ_sis the maximum allowed burst length of the LB filter. To ensure low losses, it is advisable to have ρ_s > 1.1r_s and high value of σ_s.

Observe that sometimes the bandwidth allocated to the AF class needs to be shared between the m subclasses such that each subclass meets its target delay requirement. This is done by using PDD scheduling between the subclasses where the value of parameter  determines the extent of differentiation. Furthermore, each AF subclass can have an end-to-end delay requirement for the concerned hop. Providing hop-by-hop delay allows greater flexibility and options of better mapping the sources to subclasses.