**3.1.4 MPLS**

16 Will-be-set-by-IN-TECH

them (rfc1633, 1994). In the absence of state aggregation, the amount of state on each node scales in proportion to the number of concurrent reservations, which can be potentially large on high-speed links. This model also requires application support for the RSVP signaling protocol. Differentiated service is a simple method by classifying services of different applications (rfc2475, 1998). Currently there are two standard per hop behaviour (PHBs)

• Expedited Forwarding (EF): Has a single codepoint (DiffServ value). Ef minimize delay and jitter and provides the highest level of aggregate quality of service. Any traffic that exceeds the traffic profile is discarded (**?**). EF class offers a low jitter, low delay service. UserâA˘ Zs traffic cannot exceed the agreed peak rate. Otherwise, the packets will be ´

• Assured Forwarding (AF): Has four classes and three drop-precedence within each class (a total of twelve codepoints). Excess AF traffic is not delivered with as high probability as the traffic "within profile", which means it may be demoted but not necessarily dropped (**?**). The AF class is suitable for delay-tolerant applications. The guarantee just implies that the better QoS class will give a better performance than the low-level QoS class. Network

DiffServ offers a simple QoS management method without signaling mechanism. The DiffServ architecture is shown in Figure 6. It includes classifier and traffic conditioner. A traffic conditioner contains the following elements: meter, maker, shaper/dropper. The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single DiffServ codepoint (DSCP). Within the core of the network, packets are forwarded according to the

When a traffic flow enters a DiffServ network, the flow is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner. A meter is used to measure the traffic flow agains a traffic profile. A meter is used (where appropriate) to measure the traffic stream against a traffic profile. The state of the meter with respect to a particular packet (e.g., whether it is in- or out-of-profile) may be used to affect a marking, dropping, or shaping action. When packets exit the traffic conditioner of a DS boundary node the DiffServ codepoint of each

define two traffic classes:

Fig. 6. DffServ architecture

operator can define their own per-hop behavior.

per-hop behavior associated with the DiffServ codepoint.

packet must be set to an appropriate value.

discarded.

MPLS is a key development in IETF that will add a number of essential capabilities to today's best effort IP networks, including


MPLS borrows the idea from ATM switching. It remains independent of the Layer-2 and Layer-3 protocols. Besides IP, other network protocols (such as IPX, ATM, PPP or Frame-Relay) also can work with MPLS. MPLS resides on routers. When a packet flow enters a edge router of the MPLS domain, all packets are marked to clarify priority with a fixed-length label (20 bits label). The label identifies the packets routing information in this MPLS network, also define the quality of service for the packets.

A MPLS domain includes label edge routers (LERs) and label switching routers (LSRs). The route taken by an MPLS-labeled packet is called the label switched path (LSP). LST is a high-speed router in the core of a MPLS network, which participates in the establishment of LSPs. LER is a router that operates at the edge of a MPLS network. It is used to assign and remove labels when packets enter or exit the MPLS network.

MPSL is similar to DiffServ because it also marks traffic at ingress of a MPLS network, and un-marks at egress gate. However, MPLS marking is used to decide the next hop router while DiffServ marking is used to determine priority in route itself.

#### **3.2 QoS management functions for end-to-end IP QoS**

This section describes how to provide Quality of Service in UMTS for the end-to-end services through the TE/MT local bear service, GPRS bearer service and external bearer service shown in the Fig. 1. To provide end-to-end IP QoS, it is necessary to manage the QoS within each domian. An IP BS Manager is used to control the external IP bearer service. Due to the different techiniques used within the IP network,this communicates to the UMTS BS manager through the Translation function.

At PDP context setup the user shall have access to one of the following alternatives, basic GPRS IP connectivity service or enhanced GPRS based services. To enable coordination between events in the application layer and resource management in the IP bearer layer, a logical element, the Policy and Charging Rules Function (PCRF), is used as a logical policy decision element which will be detailed in section 4. It is also possible to implement a policy decision element internal to the IP BS Manager in the GGSN. While interworking with the external network, the RSVP, DiffServ, MPLS will be used.

QoS management functions is shown in Fig. 7 which describes how to control the external IP bearer services and how they relate to the UMTS bearer service QoS management entity.

IP BS Manager uses standard IP mechanisms to manage the IP bearer services. These mechanisms may be different from mechanisms used within the UMTS, and may have different parameters controlling the service. When implemented, the IP BS Manager

**4. Policy based QoS management - IP QoS for IMS**

control QoS resources in the UMTS IMS.

**4.1.1 The need for policy based network**

service provider environment.

**4.1.2 What is policy?**

**4.1 Introduction to policy-based QoS network**

domain.

This section will provide an overview of policy based QoS management in UMTS IMS. Although the UMTS packet switched (PS) domain can support IP QoS enabled multimedia applications, there are many ways of establishing QoS guaranteed IP multimedia session through a signaling protocol before it can map and reserve the equivalent amount of QoS resources along the data path in the PS domain. In order to support interoperation among UMTS network providers, the IP multimedia Subsystem (IMS) is standardized by the 3GPP to serve Session Initiation Protocol (SIP) signaled IP multimedia services over the UMTS PS

End to End Quality of Service in UMTS Systems 117

The central problem of providing consistent end-to-end IP QoS services is the difficulty of configuring the network devices like routers and switches to handle packet flows in a manner that satisfies the requested QoS requirements. Policy-based QoS management is used to

There is a consistent effort to implement new IP multimedia services in UMTS. While the IP based network is well suited for packet data transfer, providing consistent end-to-end IP QoS services is the difficulty of configuring the network devices like routers and switches to handle packet flows in a manner that satisfies the requested QoS requirements. This problem is especially acute when the end-to-end data path of an IP QoS session crosses multiple administrative domains managed by different operators. Although the operators agree on the QoS requirements of a particular set of IP services, they may not configure their network devices in the same way to implement the services due to differences in the network topologies, QoS mechanisms available in the network devices and non-technical management requirements. Thus, there is a need to create a solution that permits network operators, including UMTS network operators, to easily configure their networks to implement

consistent IP QoS services without dealing with the complexity of their networks.

Policy-based Networking (PBN) is a novel approach to configure myriad network devices in an administrative domain to implement a set of IP QoS services. Policy-based network will allow the network operator to define, in a succinct and organized fashion, operator policies that automatically effect change on specific equipment in the network environment. The end result is that the end-to-end network performance will meet the general expectations of UMTS

A policy is a set of business rules that guide and determine how to manage network resources. The basic concept is that policy rule(s) describe how network to act when specific condition(s) happen. "Policy" can be defined from two perspectives: (POLICYTERM, 2001). - A definite goal, course or method of action to guide and determine present and future decisions. "Policies" are implemented or executed within a particular context (such as policies defined within a business unit). - Policies as a set of rules to administer, manage, and control access to network resources. [RFC3060] Note that these two views are not contradictory since

individual rules may be defined in support of business goals.

Fig. 7. QoS management functions for end-to-end QoS in UMTS

may include the support of DiffServ Edge Function and the RSVP function. The Translation/mapping function provides the inter-working between the mechanisms and parameters used within the UMTS bearer service and those used within the IP bearer service, and interacts with the IP BS Manager. In the GGSN, the IP QoS parameters are mapped into UMTS QoS parameters, where needed. In the UE, the QoS requirements determined from the application layer (e.g., SDP) are mapped to either the PDP context parameters or IP layer parameters (e.g., RSVP). If an IP BS Manager exists both in the UE and the Gateway node, it is possible that these IP BS Managers communicate directly with each other by using relevant signalling protocols. The required options in the table define the minimum functionality that shall be supported by the equipment in order to allow multiple network operators to provide interworking between their networks for end-to-end QoS. Use of the optional functions listed below, other mechanisms which are not listed (e.g. over-provisioning), or combinations of these mechanisms are not precluded from use between operators. The IP BS Managers in the UE and GGSN provide the set of capabilities for the IP bearer level as shown in table 2. Provision of the IP BS Manager is optional in the UE, and required in the GGSN.


Table 2. IP BS Manager capability in the UE and GGSN

18 Will-be-set-by-IN-TECH

may include the support of DiffServ Edge Function and the RSVP function. The Translation/mapping function provides the inter-working between the mechanisms and parameters used within the UMTS bearer service and those used within the IP bearer service, and interacts with the IP BS Manager. In the GGSN, the IP QoS parameters are mapped into UMTS QoS parameters, where needed. In the UE, the QoS requirements determined from the application layer (e.g., SDP) are mapped to either the PDP context parameters or IP layer parameters (e.g., RSVP). If an IP BS Manager exists both in the UE and the Gateway node, it is possible that these IP BS Managers communicate directly with each other by using relevant signalling protocols. The required options in the table define the minimum functionality that shall be supported by the equipment in order to allow multiple network operators to provide interworking between their networks for end-to-end QoS. Use of the optional functions listed below, other mechanisms which are not listed (e.g. over-provisioning), or combinations of these mechanisms are not precluded from use between operators. The IP BS Managers in the UE and GGSN provide the set of capabilities for the IP bearer level as shown in table 2.

Provision of the IP BS Manager is optional in the UE, and required in the GGSN.

Table 2. IP BS Manager capability in the UE and GGSN

Capability UE GGSN DiffServ Edge Function Optional Required RSVP/IntServ Optional Optional IP Policy Enforcement Point Optional Required

Fig. 7. QoS management functions for end-to-end QoS in UMTS

#### **4. Policy based QoS management - IP QoS for IMS**

This section will provide an overview of policy based QoS management in UMTS IMS. Although the UMTS packet switched (PS) domain can support IP QoS enabled multimedia applications, there are many ways of establishing QoS guaranteed IP multimedia session through a signaling protocol before it can map and reserve the equivalent amount of QoS resources along the data path in the PS domain. In order to support interoperation among UMTS network providers, the IP multimedia Subsystem (IMS) is standardized by the 3GPP to serve Session Initiation Protocol (SIP) signaled IP multimedia services over the UMTS PS domain.

The central problem of providing consistent end-to-end IP QoS services is the difficulty of configuring the network devices like routers and switches to handle packet flows in a manner that satisfies the requested QoS requirements. Policy-based QoS management is used to control QoS resources in the UMTS IMS.

#### **4.1 Introduction to policy-based QoS network**

#### **4.1.1 The need for policy based network**

There is a consistent effort to implement new IP multimedia services in UMTS. While the IP based network is well suited for packet data transfer, providing consistent end-to-end IP QoS services is the difficulty of configuring the network devices like routers and switches to handle packet flows in a manner that satisfies the requested QoS requirements. This problem is especially acute when the end-to-end data path of an IP QoS session crosses multiple administrative domains managed by different operators. Although the operators agree on the QoS requirements of a particular set of IP services, they may not configure their network devices in the same way to implement the services due to differences in the network topologies, QoS mechanisms available in the network devices and non-technical management requirements. Thus, there is a need to create a solution that permits network operators, including UMTS network operators, to easily configure their networks to implement consistent IP QoS services without dealing with the complexity of their networks.

Policy-based Networking (PBN) is a novel approach to configure myriad network devices in an administrative domain to implement a set of IP QoS services. Policy-based network will allow the network operator to define, in a succinct and organized fashion, operator policies that automatically effect change on specific equipment in the network environment. The end result is that the end-to-end network performance will meet the general expectations of UMTS service provider environment.

#### **4.1.2 What is policy?**

A policy is a set of business rules that guide and determine how to manage network resources. The basic concept is that policy rule(s) describe how network to act when specific condition(s) happen. "Policy" can be defined from two perspectives: (POLICYTERM, 2001). - A definite goal, course or method of action to guide and determine present and future decisions. "Policies" are implemented or executed within a particular context (such as policies defined within a business unit). - Policies as a set of rules to administer, manage, and control access to network resources. [RFC3060] Note that these two views are not contradictory since individual rules may be defined in support of business goals.

Fig. 8. A PBN architecture that is derived from the policy framework specified by the IETF

End to End Quality of Service in UMTS Systems 119

of account quota, or information from third party (non-PEP) signaling.

to access the policy repository.

It also sends policy elements the PEP.

Policy Enforcement Point (PEP)

Policy Decision Point (PDP)

and "pushes" configuration information to the PEP. This takes place as a result of external events (unrelated to the PEP) such as change of applicable policy, time of day, expiration

Both models employ policy servers as the PDP to control the network devices that enforce the policy (i.e. PEPs). PBN also offers a policy repository for storing policy information accessed by the PDPs in the system. To communicate policy information between PDPs and PEPs, the COPS policy protocol is engaged. Additionally, the LDAP protocol functions

The PDP is the PBN component that directly controls the network devices or policy enforcement points (see next section). Functionally, the PDP handles policy information that has been entered into the PBN management system. The policy data used by the PDP can either be obtained in real-time upon entry into the management console, or from the policy repository on an as-needed basis. The function of the PDP involves retrieving policy, interpreting policy, detect policy conflicts, receiving policy decision requests from PEPs, determining which policy is relevant, applying the policy and returning the results.

Network devices that receive and enforce the decisions from the PDP are referred to as PEPs. In both outsourcing and provisioning policy management models, PEPs receive policy decisions and enforce them at the packet level as data passes through the devices.

Policy can be represented at different levels, ranging from business goals to device-specific configuration parameters. Enforcement of policy ensures that business rules are always followed. Policy rule is a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed. [RFC3060] A condition is a set of expressions or objects used to determine whether a given policy rule's action should be performed. A condition answers the question, "when and where do we enforce a policy?" An action defines what to be done to enforce a policy rule, when the conditions of the rule are met. Policy actions may result in the execution of one or more operations to affect and/or configure network traffic and network resources. An action answers the question, "what must be done to enforce a policy?"

A policy also defines how the network's resources are to be allocated among its clients. Clients can be individual users, departments, host computers, or applications. Resources can be allocated based on time of day, client authorization priorities, availability of resources, and other factors. How resources are allocated can be static or dynamic (based on variations in traffic). Policies are created by network managers and stored in a repository. During network operation, the policies are retrieved and used by network management software to make decisions.

#### **4.1.3 Policy framework & architecture**

The network operators negotiate Service Level Agreements (SLAs) that describe the sets of IP QoS services that they have mutually contracted to provide. Individual operators will then transform the QoS requirements specified in the SLAs into sets of policy rules that will be applied to their network domains to implement the contracted IP QoS services. The IETF has defined a policy framework (RFC2753, 2001) as shown in Figure 8 to transform the sets of policy rules to network device configurations in an administrative domain. The sets of policy rules are stored in the Policy Repository through the Policy Management Tool. The Policy Decision Point (PDP) retrieves the appropriate policy rules from the Policy Repository in response to policy events that are triggered by the contracted IP QoS services, e.g., the reception of an RSVP message by the Policy Enforcement Point (PEP). It translates the acquired policy rules into a set of QoS mechanism configuration actions that is communicated to the PEP as policy decisions. The PEP then executes the actions spelt out in the supplied decisions to handle the triggering policy events in accordance with the requested IP QoS services. Alternatively, the retrieved policy rules may be returned to the PEP, which is capable of translating them into configuration actions. These policy rules can be cached in the PEP so that similar future triggering policy events can be serviced locally without further interactions with the PDP.

#### Outsourcing and Provision Model in PBN

There are two main models for policy management: outsourcing and provisioning. The outsourcing model assumes there is a signaled event in the Policy Enforcement Point (PEP) that must be resolved based on policy criteria. The PEP outsources the decision-making to an external policy decision point (PDP). This outsourcing model is sometimes referred to as "Pull" mode, or "reactive" mode, since the PEP pulls policy decisions from the PDP, while the PDP responds according to the PEP events.

The provisioning model is almost the mirror image of the outsourcing model. In this system, the PDP predicts future configuration needs, and proactively provisions resources accordingly. In other words, rather than responding to PEP events, the PDP prepares 20 Will-be-set-by-IN-TECH

Policy can be represented at different levels, ranging from business goals to device-specific configuration parameters. Enforcement of policy ensures that business rules are always followed. Policy rule is a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed. [RFC3060] A condition is a set of expressions or objects used to determine whether a given policy rule's action should be performed. A condition answers the question, "when and where do we enforce a policy?" An action defines what to be done to enforce a policy rule, when the conditions of the rule are met. Policy actions may result in the execution of one or more operations to affect and/or configure network traffic and network

resources. An action answers the question, "what must be done to enforce a policy?"

decisions.

with the PDP.

**4.1.3 Policy framework & architecture**

Outsourcing and Provision Model in PBN

while the PDP responds according to the PEP events.

A policy also defines how the network's resources are to be allocated among its clients. Clients can be individual users, departments, host computers, or applications. Resources can be allocated based on time of day, client authorization priorities, availability of resources, and other factors. How resources are allocated can be static or dynamic (based on variations in traffic). Policies are created by network managers and stored in a repository. During network operation, the policies are retrieved and used by network management software to make

The network operators negotiate Service Level Agreements (SLAs) that describe the sets of IP QoS services that they have mutually contracted to provide. Individual operators will then transform the QoS requirements specified in the SLAs into sets of policy rules that will be applied to their network domains to implement the contracted IP QoS services. The IETF has defined a policy framework (RFC2753, 2001) as shown in Figure 8 to transform the sets of policy rules to network device configurations in an administrative domain. The sets of policy rules are stored in the Policy Repository through the Policy Management Tool. The Policy Decision Point (PDP) retrieves the appropriate policy rules from the Policy Repository in response to policy events that are triggered by the contracted IP QoS services, e.g., the reception of an RSVP message by the Policy Enforcement Point (PEP). It translates the acquired policy rules into a set of QoS mechanism configuration actions that is communicated to the PEP as policy decisions. The PEP then executes the actions spelt out in the supplied decisions to handle the triggering policy events in accordance with the requested IP QoS services. Alternatively, the retrieved policy rules may be returned to the PEP, which is capable of translating them into configuration actions. These policy rules can be cached in the PEP so that similar future triggering policy events can be serviced locally without further interactions

There are two main models for policy management: outsourcing and provisioning. The outsourcing model assumes there is a signaled event in the Policy Enforcement Point (PEP) that must be resolved based on policy criteria. The PEP outsources the decision-making to an external policy decision point (PDP). This outsourcing model is sometimes referred to as "Pull" mode, or "reactive" mode, since the PEP pulls policy decisions from the PDP,

The provisioning model is almost the mirror image of the outsourcing model. In this system, the PDP predicts future configuration needs, and proactively provisions resources accordingly. In other words, rather than responding to PEP events, the PDP prepares

Fig. 8. A PBN architecture that is derived from the policy framework specified by the IETF

and "pushes" configuration information to the PEP. This takes place as a result of external events (unrelated to the PEP) such as change of applicable policy, time of day, expiration of account quota, or information from third party (non-PEP) signaling.

Both models employ policy servers as the PDP to control the network devices that enforce the policy (i.e. PEPs). PBN also offers a policy repository for storing policy information accessed by the PDPs in the system. To communicate policy information between PDPs and PEPs, the COPS policy protocol is engaged. Additionally, the LDAP protocol functions to access the policy repository.

Policy Decision Point (PDP)

The PDP is the PBN component that directly controls the network devices or policy enforcement points (see next section). Functionally, the PDP handles policy information that has been entered into the PBN management system. The policy data used by the PDP can either be obtained in real-time upon entry into the management console, or from the policy repository on an as-needed basis. The function of the PDP involves retrieving policy, interpreting policy, detect policy conflicts, receiving policy decision requests from PEPs, determining which policy is relevant, applying the policy and returning the results. It also sends policy elements the PEP.

Policy Enforcement Point (PEP)

Network devices that receive and enforce the decisions from the PDP are referred to as PEPs. In both outsourcing and provisioning policy management models, PEPs receive policy decisions and enforce them at the packet level as data passes through the devices.

The PCRF communicates with the PCEF via the Gx interface (3G29212, 2008). It allows two modes of operation. In the "push" mode, the PCRF initiates communication with the PCEF and sends the PCEF its decision. In the "pull" mode, the PCEF initiates communication with the PCRF to request a decision for a particular IP flow. The Gx interface and the protocol used

End to End Quality of Service in UMTS Systems 121

Figure 10 depicts the relationship between these entities. In the following subsections, each of

During the establishment of a SIP session, a P-CSCF is the first contact point in the IMS domain for a UE [3G23228]. Hence it is the natural place to authorize the usage of network resources such as the bandwidth requested by the UE. The QoS requirements of the UE are carried in the Session Description Protocol (SDP) description within a Session Initiation Protocol (SIP) message. Besides the QoS requirements in the SDP description, the PCRF also examines the source and destination IP addresses and port numbers in its decision-making. The PCRF refers to the policy rules, which are generally stored in a policy repository, governing the local domain. It then generates an authorization token that uniquely identifies the SIP session across multiple Packet Data Protocol (PDP) contexts terminated by a GGSN. This token is sent to the UE via SIP messages so that the UE can use it to identify the associated session flows to the PCEF in the GGSN in subsequent transmission of IP packets. This mechanism is consistent with the IETF specification on supporting media authorization in the SIP protocol [RFC3313]. The flow of events in

In the PS domain, a GGSN maintains connectivity to other packet switched external networks such as the Internet. From the service point of view, the GGSN controls which IP flows are permitted into the external IP network by policing the IP packets based on their source and destination IP addresses and port numbers [3G23228]. As such, it is logical to embed the PCEF in the GGSN. The role of the PCEF is to ensure that only authorized IP flows are allowed to use network resources that have been reserved and allocated to them. The policy enforcement function in the GGSN is called a "gate". A gate comprises a packet classifier, a traffic meter, and the relevant packet handling mechanisms for packets that have been matched by the packet classifier. When an IP flow is authorized by the PCRF to

for communication on the interface are described in the following.

these network elements will be described.

Fig. 10. Policy architecture in UMTS IMS

session set-up is described in Section 4.6. PCEF in Gateway GPRS Support Node (GGSN)

PCRF in Proxy-CSCF

#### **4.2 Policy framework in UMTS IMS**

To support IP based multimedia services, the IP Multimedia Subsystem (IMS) is introduced in the 3GPP Release 5 specifications. It provisions IP based multimedia services as an extension of the UMTS PS domain (Figure 9). The added IMS functionalities are control functionalities; the user data traffic is still carried by the PS domain. The main advantage of the IMS is that it offers operators a scalable service platform on which new services can be developed rapidly in a flexible way, without requiring any change to the PS domain.

Fig. 9. A simple UMTS network with IMS

Having put in place the functionalities to handle IP multimedia calls, the next big challenge is to ensure that sufficient QoS resources are provided to authorized users in the UMTS network. A policy-based QoS solution is adopted by the 3GPP for this purpose.

As mentioned in section 4.1.3, the reference model of a policy-based network consists of two main elements, the PDP and the PEP (RFC2753, 2001). PEPs often reside in policy aware network nodes that carry out actions stipulated by policy rules. The actions taken are based on the decisions of a PDP, which retrieves the policy rules from a repository. The PDP is the final authority, which the PEP needs to refer to for actions to be taken.

In the IMS, the Policy and Charging Rules Function (PCRF) (3G23203, 2008) plays the role of the PDP and online charging and offline charging functions, the Policy and Charging Enforcement Functions plays the role of the PEP. Policy charging and rules function (PCRF) is the node designated in real-time to determine policy rules in a multimedia network. As a policy tool, the PCRF plays a central role in WCDMA networks. Unlike earlier policy engines that were added on to an existing network to enforce policy, the PCRF is a software component that operates at the network core and efficiently accesses subscriber databases and other specialized functions, such as a charging systems, in a scalable, reliable, and centralized manner. The PCRF as the part of the network architecture that aggregates information to and from the network, operational support systems, and other sources (such as portals) in real time, supporting the creation of rules and then automatically making intelligent policy decisions for each subscriber active on the network. Such a network might offer multiple services, quality of service (QoS) levels, and charging rules. In this chapter, we will focus on policy based management functions.

22 Will-be-set-by-IN-TECH

To support IP based multimedia services, the IP Multimedia Subsystem (IMS) is introduced in the 3GPP Release 5 specifications. It provisions IP based multimedia services as an extension of the UMTS PS domain (Figure 9). The added IMS functionalities are control functionalities; the user data traffic is still carried by the PS domain. The main advantage of the IMS is that it offers operators a scalable service platform on which new services can be developed rapidly

Having put in place the functionalities to handle IP multimedia calls, the next big challenge is to ensure that sufficient QoS resources are provided to authorized users in the UMTS network.

As mentioned in section 4.1.3, the reference model of a policy-based network consists of two main elements, the PDP and the PEP (RFC2753, 2001). PEPs often reside in policy aware network nodes that carry out actions stipulated by policy rules. The actions taken are based on the decisions of a PDP, which retrieves the policy rules from a repository. The PDP is the

In the IMS, the Policy and Charging Rules Function (PCRF) (3G23203, 2008) plays the role of the PDP and online charging and offline charging functions, the Policy and Charging Enforcement Functions plays the role of the PEP. Policy charging and rules function (PCRF) is the node designated in real-time to determine policy rules in a multimedia network. As a policy tool, the PCRF plays a central role in WCDMA networks. Unlike earlier policy engines that were added on to an existing network to enforce policy, the PCRF is a software component that operates at the network core and efficiently accesses subscriber databases and other specialized functions, such as a charging systems, in a scalable, reliable, and centralized manner. The PCRF as the part of the network architecture that aggregates information to and from the network, operational support systems, and other sources (such as portals) in real time, supporting the creation of rules and then automatically making intelligent policy decisions for each subscriber active on the network. Such a network might offer multiple services, quality of service (QoS) levels, and charging rules. In this chapter, we will focus on

A policy-based QoS solution is adopted by the 3GPP for this purpose.

final authority, which the PEP needs to refer to for actions to be taken.

in a flexible way, without requiring any change to the PS domain.

**4.2 Policy framework in UMTS IMS**

Fig. 9. A simple UMTS network with IMS

policy based management functions.

The PCRF communicates with the PCEF via the Gx interface (3G29212, 2008). It allows two modes of operation. In the "push" mode, the PCRF initiates communication with the PCEF and sends the PCEF its decision. In the "pull" mode, the PCEF initiates communication with the PCRF to request a decision for a particular IP flow. The Gx interface and the protocol used for communication on the interface are described in the following.

Figure 10 depicts the relationship between these entities. In the following subsections, each of these network elements will be described.

Fig. 10. Policy architecture in UMTS IMS

#### PCRF in Proxy-CSCF

During the establishment of a SIP session, a P-CSCF is the first contact point in the IMS domain for a UE [3G23228]. Hence it is the natural place to authorize the usage of network resources such as the bandwidth requested by the UE. The QoS requirements of the UE are carried in the Session Description Protocol (SDP) description within a Session Initiation Protocol (SIP) message. Besides the QoS requirements in the SDP description, the PCRF also examines the source and destination IP addresses and port numbers in its decision-making. The PCRF refers to the policy rules, which are generally stored in a policy repository, governing the local domain. It then generates an authorization token that uniquely identifies the SIP session across multiple Packet Data Protocol (PDP) contexts terminated by a GGSN. This token is sent to the UE via SIP messages so that the UE can use it to identify the associated session flows to the PCEF in the GGSN in subsequent transmission of IP packets. This mechanism is consistent with the IETF specification on supporting media authorization in the SIP protocol [RFC3313]. The flow of events in session set-up is described in Section 4.6.

#### PCEF in Gateway GPRS Support Node (GGSN)

In the PS domain, a GGSN maintains connectivity to other packet switched external networks such as the Internet. From the service point of view, the GGSN controls which IP flows are permitted into the external IP network by policing the IP packets based on their source and destination IP addresses and port numbers [3G23228]. As such, it is logical to embed the PCEF in the GGSN. The role of the PCEF is to ensure that only authorized IP flows are allowed to use network resources that have been reserved and allocated to them. The policy enforcement function in the GGSN is called a "gate". A gate comprises a packet classifier, a traffic meter, and the relevant packet handling mechanisms for packets that have been matched by the packet classifier. When an IP flow is authorized by the PCRF to

on whether to grant or deny the required network resources to the session. As the signaling messages used to set up the session take a different path from that used for the data flow, an authorization token and a flow identifier are used to associate the session with its IP data flow (UMTSGO01, 2001). The GGSN, which is located on the data path, relies on this binding

End to End Quality of Service in UMTS Systems 123

Figure 11 depicts the sequence of events that take place during the establishment of an IP multimedia service session. Note that a number of signaling messages have been omitted for

Steps 1-5: The UE sends a session set-up request (i.e., SIP INVITE) to the P-CSCF indicating, among other things, the media streams to be used in the session. This message is routed to the called party via a number of other CSCFs (viz., the caller and callee S-CSCFs) along the signaling path. The S-CSCFs perform the appropriate session control services for the UEs. In particular, they maintain a session state that is needed by the network operator to

Steps 6-14: The called party responds with a provisional SIP 183 response message. This message is routed to the calling party via the same CSCFs along the (reversed) signaling path. When the callee P-CSCF receives this message, it examines the SDP description within the message to determine the QoS parameters requested for the session. The P-CSCF sends the necessary information in this SIP message (e.g., the bandwidth, IP addresses and ports, etc.) to the PCRF for authorization of the session request. If the policy permits, the PCRF responds with an authorization token that can be used to identify the authorized session and resources. The P-CSCF includes the token in the response (SIP 183 message) and forwards it to the callerâA˘ Zs UE. A similar process is carried out at the caller ´ P-CSCF when it receives the SIP 183 message. This process of authorization by the PCRF

Steps 15-22: In between steps 14 and 15, other message exchanges take place between the caller and the callee. However, these are not important in this particular example and are omitted for clarity. The caller's UE starts the resource reservation by sending a PDP Context Activation Request to the GGSN. The authorization token and the flow identifier(s) from the PCRF are included to identify the IP data flow(s) of the session. When the GGSN receives the PDP Context Activation Request, it sends a policy decision request to the PCRF to determine whether the resource reservation request should be accepted. The PCRF uses the token in the message to correlate the request for resources with the media authorization previously granted to the session. The PCRF then sends a decision to the GGSN. If the PCRF approves the resource reservation, the GGSN sends a PDP Context Activation Response to the UE indicating that the resource reservation has been completed.

Steps 23-31: In between steps 22 and 23, there are other events, e.g., 180 Ringing, that take place. These events are omitted to prevent cluttering Figure 3-22. When the callee answers the call, a SIP 200 OK message is sent towards the caller. When the SIP 200 OK reaches the P-CSCF, it will approve the QoS commitment by sending a decision to the GGSN. Upon receiving this message, the GGSN opens the gate, thereby effectively permitting the IP data flow to use the resources reserved previously. Once this is done, the GGSN responds to the PCRF with a report on the status of the session. A similar process takes place at the caller's end. When this entire process is completed, the proper resources on the data path have

information to enforce the policy rules on the IP data flows.

clarity. The events are described in the following paragraphs:

and the generation of a token is called "Authorize QoS Request".

A similar process takes place at the callee's end.

been reserved and committed to the session.

support the requested service.

use the specified network resources, the PCEF opens the "gate" for the flow and effectively commits the network resources to the flow by allowing it to pass through the packet handling mechanisms (i.e., policing or marking). On the other hand, if an IP flow is not permitted by the PCRF to use the requested resources, the PCEF closes the âAIJgateâ ˘ A˘ ˙ I and drops the IP packets of the flow. This process is called policy-based admission control. It ensures that an IP flow is only allowed to use resources that have been approved by the policy rules. The above process takes place at the IP bearer service (BS) level. The translation/mapping function within the GGSN will map this resource information into the format used by the admission control function at the UMTS BS level.

The PCEF may store decisions in a local policy decision point, thus allowing the GGSN to make the admission control decisions without additional interactions with the PCRF. This will reduce the traffic over the Gx interface and lessen the processing load on the PCRF.

#### **4.3 Policy-based QoS delivery: an example of policy based call control**

There are several reasons why a policy-based QoS framework is adopted for the UMTS. Policy-based QoS control allows network operators to configure their network devices easily. It provides a high level view of the network devices and allows the automated translation of business level policies to suitable information for configuring network devices.

UMTS requires a strict authorization of users so that the network resources are not abused. Once authorized and approved, the UMTS must guarantee that the resources are made available to the legitimate users. If these requirements are not met, these users may be denied the use of the resources, leading to dissatisfaction with the quality of service provided. To ensure that this is not the case, all IP multimedia calls must go through the following steps:


In all these steps, policy rules are used in approving the requests, and the PCRF is the sole approving authority. By changing the policy rules in the PCRF, a network operator can alter the IP multimedia services it offers to its subscribers without having to know the details of its network configuration and the types and mechanisms of the network devices.

To meet the above requirements, two procedures are needed for the establishment of an IP multimedia session in addition to the normal GPRS bearer establishment procedures. These procedures are Authorize QoS Resources and Approval of QoS Commit (3G29212, 2008). Similarly, the procedures, Removal of QoS Commit and Revoke Authorization of QoS Resources, are carried out to reverse the authorization and commitment of QoS resources when an IP multimedia session is terminated. The following provides an overview of the session set-up procedures, in particular, the emphasis is on the additional procedures introduced by the service-based local policy.

#### **4.4 Session establishment procedures**

The establishment of an IP multimedia service session with policy control differs from that without policy control in that additional steps are taken to check the policy rules for a decision 24 Will-be-set-by-IN-TECH

use the specified network resources, the PCEF opens the "gate" for the flow and effectively commits the network resources to the flow by allowing it to pass through the packet handling mechanisms (i.e., policing or marking). On the other hand, if an IP flow is not permitted by the PCRF to use the requested resources, the PCEF closes the âAIJgateâ ˘ A˘ ˙

and drops the IP packets of the flow. This process is called policy-based admission control. It ensures that an IP flow is only allowed to use resources that have been approved by the policy rules. The above process takes place at the IP bearer service (BS) level. The translation/mapping function within the GGSN will map this resource information into

The PCEF may store decisions in a local policy decision point, thus allowing the GGSN to make the admission control decisions without additional interactions with the PCRF. This will reduce the traffic over the Gx interface and lessen the processing load on the PCRF.

There are several reasons why a policy-based QoS framework is adopted for the UMTS. Policy-based QoS control allows network operators to configure their network devices easily. It provides a high level view of the network devices and allows the automated translation of

UMTS requires a strict authorization of users so that the network resources are not abused. Once authorized and approved, the UMTS must guarantee that the resources are made available to the legitimate users. If these requirements are not met, these users may be denied the use of the resources, leading to dissatisfaction with the quality of service provided. To ensure that this is not the case, all IP multimedia calls must go through the following steps:

2. Reservation of resources. This is to make sure that the resources are available when the

3. Once the called party picks up the "phone", the network resources reserved previously are

In all these steps, policy rules are used in approving the requests, and the PCRF is the sole approving authority. By changing the policy rules in the PCRF, a network operator can alter the IP multimedia services it offers to its subscribers without having to know the details of its

To meet the above requirements, two procedures are needed for the establishment of an IP multimedia session in addition to the normal GPRS bearer establishment procedures. These procedures are Authorize QoS Resources and Approval of QoS Commit (3G29212, 2008). Similarly, the procedures, Removal of QoS Commit and Revoke Authorization of QoS Resources, are carried out to reverse the authorization and commitment of QoS resources when an IP multimedia session is terminated. The following provides an overview of the session set-up procedures, in particular, the emphasis is on the additional procedures

The establishment of an IP multimedia service session with policy control differs from that without policy control in that additional steps are taken to check the policy rules for a decision

network configuration and the types and mechanisms of the network devices.

the format used by the admission control function at the UMTS BS level.

business level policies to suitable information for configuring network devices.

**4.3 Policy-based QoS delivery: an example of policy based call control**

1. Authorization of resources;

committed. The charging process is then triggered.

introduced by the service-based local policy.

**4.4 Session establishment procedures**

"phone" rings;

I

on whether to grant or deny the required network resources to the session. As the signaling messages used to set up the session take a different path from that used for the data flow, an authorization token and a flow identifier are used to associate the session with its IP data flow (UMTSGO01, 2001). The GGSN, which is located on the data path, relies on this binding information to enforce the policy rules on the IP data flows.

Figure 11 depicts the sequence of events that take place during the establishment of an IP multimedia service session. Note that a number of signaling messages have been omitted for clarity. The events are described in the following paragraphs:


S.Shenker, C.Partridge, R.Guerin (1997), Specification of Guaranteed Quality of Service,

End to End Quality of Service in UMTS Systems 125

J. Wroclawski (1997), Specification of the Controlled-Load Network Element Service, *RFC2211*,

S.Shenker, J.Wroclawski (1999), Network Element Service Specification Template, *RFC2216*,

R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview,

Braden, B., Ed., et. al., Resource Reservation Protocol (RSVP) - Version 1 Functional

S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An architecture for differentiated

B.Moore, E. Ellesson, J. Strassner and A. Westerinen, Policy Core Information Model – Version

M. Handley, et al., SIP: Session Initiation Protocol, *Internet draft (work in progress),*

3GPP TS 29.212 (version 8.3.0), Policy and Charging Control Over Gx Reference Point (Rel 8),

R.Yavatkar, D.Pendarakis, R.Guerin, A Framework for Policy-based Admission Control, *RFC*

K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith and R. Yavatkar, COPS Usage for Policy Provisioning, *RFC 3084*, Mar. 2001 L-N. Hamer, K. Chan, H. Syed, H. Shieh and R. Zwart, COPS-PR for outsourcing in UMTS:

B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, J. Strassner, A. Westerinen, R. Chadha, M. Brunner

J. Jason, L. Rafalow and E. Vyncke, IPsec Configuration Policy Model,

Y. Snir, Y. Ramberg, J. Strassner, R. Cohen and B. Moore, Policy QoS Information Model,

and R. Cohen, Policy Core Information Model Extensions, *draft-ietf-policy-pcim-ext-06*,

R. Atkinson, Security Architecture for the Internet Protocol, *RFC 2401*, IETF, Aug. 1995

T. Dierks and C. Allen, The TLS Protocol Version 1.0, *RFC 2246*, IETF, Jan. 1999

UMTS Go PIB, *draft-hamer-rap-cops-umts-go-00, IETF*, Nov. 2001

3GPP TS 23.228 (version 8.3.0), IP Multimedia Subsystem- Stage 2 (Rel 8), June 2008. 3GPP TS 23.203 (version8.3.0),Policy and Charging Control Architecture (Rel. 8), 2008. W. Marshall, et al., Private SIP Extensions for Media Authorization, *RFC 3313*, Nov. 2001 D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan and A. Sastry, The COPS (Common Open

V. Jacobson, K. Nichols, K. Poduri, An expedited forwarding PHB, *RFC 2598*, June, 1999. J. Heinanen, F. Baker, Weiss, J. Wroclawski, Assured forwarding PHB group, *RFC 2597*, June

White paper (1999), QoS Protocol & Architecture, *www.qosforum.com*, July, 1999.

*RFC2212*, Sept.1997.

*RFC 1633*, June 1994.

Specification, *RFC 2205*, September 1997.

White paper, Introduction to QoS Policies, *www.qosforum.com*, 1999

A. Westerinen, etc. Terminology for Policy-Based Management, *<draft-ietf-policy-terminology-04.txt>*, July, 2001.

1 Specification, *RFC 3060*, IETF, Feb. 2001.

*<draft-ietf-sip-rfc2543bis-09.txt>*, Feb. 2002

Policy Service) Protocol, *RFC 2748*, IETF, Jan. 2000.

*draft-ietf-ipsp-config-policy-model-03, IETF*, July 2001

*draft-ietf-policy-qos-info-model-04, IETF*, Nov. 2001

services, *RFC 2475*, Dec. 1998.

Survey on Policy-based networking, *INTAP*.

Sept. 1997.

Sept. 1999.

1999.

Dec. 2008.

Nov. 2001

*2753*, IETF, Jan. 2000.

Fig. 11. Session authorization mechanism in a UE-to-UE session establishment process

#### **5. References**


26 Will-be-set-by-IN-TECH

Fig. 11. Session authorization mechanism in a UE-to-UE session establishment process

Nortel White Paper (2002). Benefits of Quality of Service (QoS) in 3G Wireless Internet, Nortel

Sudhir Dixit, Yile Guo, Zoe Antoniou (2001). Resource management and quality of service

Sotiris I. Maniatis, Eugenia G. Nikolouzou, & Iakovos S. Venieris (2002). QoS issues in the

3GPP TS 23.107 (V9.2.0) (2011). Quality of Service(QoS) Concept and architecture (Release 9).

in third-generation wireless network, *IEEE Communication Magazine*, Feb. 2001,

converged 3G wireless and wired networks, *IEEE Communications Magazine*, Aug.

**5. References**

Networks.

pp.125-133.

2002, pp.44-53.


**Part 3** 

**Sensor Networks** 


**Part 3** 

**Sensor Networks** 

28 Will-be-set-by-IN-TECH

126 Telecommunications Networks – Current Status and Future Trends

S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss, An Architecture for

R. Braden, D. Clark and S. Shenker, Integrated Services in the Internet Architecture: an

R. Braden, Ed., L. Zhang, S. Berson, S. Herzog and S. Jamin, Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification, *RFC 2205, IETF*, Sept. 1997 B Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss and J. Halpern,

M. Wahl, T. Howes and S. Kille, Lightweight Directory Access Protocol (v3), *RFC 2251, IETF*,

G. Good, The LDAP Data Interchange Format (LDIF) - Technical Specification, *RFC 2849, IETF*,

Ebata, M. Takihiro, S. Miyake, et al., Interdomain QoS Provisioning and Accounting, *INET*

K. Nichols, V. Jacobson, L. Zhang, A Two-bit Differentiated Services Architecture for the

B. Teitelbaum, P. Chimento, "QBone Bandwidth Broker Architecture", work in progress,

Information Model for Describing Network Device QoS Datapath Mechanisms,

Differentiated Service, *RFC 2475, IETF*, Dec. 1998

*draft-ietf-policy-qos-device-info-model-06, IETF*, Nov. 2001

http://qbone.internet2.edu/bb/bboutline2.html.

Overview, *RFC 1633, IETF*, June 1994

*2000*, Yokohama, Japan, July 2000

Internet, *RFC 2638*, July 1999.

Dec. 1997

June 2000

**0**

**6**

*USA*

**Power Considerations for Sensor Networks**

Wireless sensor networks (WSNs) are networks composed of small, resource-constrained and collaborative devices. WSNs are used in a plethora of domains including environmental and agricultural monitoring, military operations, in the health care field and in building automation. The three main functions of wireless sensor nodes (also called motes) are to sense the environment, perform computations, store intermediate results and communicate

This chapter focuses on power considerations for all aspects of wireless sensor networks. It covers software, hardware and networking aspects of the motes. The main limitation of wireless sensor motes is that they operate on battery power. In many WSN applications, the motes are placed in remote areas and deployed for the lifetime of the network. During this time the only power resource the motes have access to is their battery. An example of such a deployment is the Mount St. Helens project developed to study volcanic activities on Mount St. Helens (were volcanic eruptions can occur at any time with very little warning). The sensors were placed on the mountain using helicopters and work at length to continually sense seismic activity and relay information to a data center. For such applications, the battery lifetime is the main factor that dictates the lifetime of the network. It is therefore imperative to develop wireless sensor mote platforms that minimize the power consumption and/or

Several works in the literature address one or two aspects of the mote's architecture and/or functionality but to the authors' knowledge, no work has combined all said aspects and addressed them as a homogeneous unit. This chapter studies and analyzes each hardware component of the mote's architecture, all the main protocols used in the mote's stack layer, discusses the work that has been done in terms of reducing the power consumption, increasing the battery lifetime and or increasing the lifetime of the entire network as a whole. The chapter is organized as follows: Section 2 gives an overview of wireless sensor networks, their applications and general architecture. Section 3 focuses on the hardware architecture of the motes (the CPU, communication infrastructure, memory and sensors). Section 4 introduces the layered protocol stack of the sensor motes (application, transport, network, link and physical layers). Section 5 summarizes the chapter and suggest paths forward.

**1. Introduction**

with other motes in the network.

maximize the lifetime of the network as a whole.

Khadija Stewart1 and James L. Stewart2

<sup>1</sup>*DePauw Universtity* <sup>2</sup>*Purdue University*
