METHODS AND DEVICES FOR CONTROLLING DATA TRANSMISSION POLICIES IN AT LEAST ONE TELECOMMUNICATIONS NETWORK
Beschreibung
The invention concerns methods and devices for controlling data transmission policies in at least one telecommunication network.
Quality of Service (QoS) support provides differentiation of traffic and the corresponding different treatments of the traffic. Resources are needed to provision QoS. In order to be sure that a QoS-related request can be actually met, some forms of admission control and resource planning are needed. Two criteria are relevant in admission control : one about the eligibility of the request and the other about the resource availability for the request. An eligibility check will decide which traffic types/flows are entitled to which services. That is, services should be regulated. It is apparent that the related management decisions and configurations should be conducted consistently and automatically. It is therefore desirable to deploy policy- based QoS management in the UMTS networks. By policy based management, networking activity is conducted according to a set of policy rules that specify the objectives to be achieved and the actions to be taken. It can lead to a system where the decisions and configurations are conducted consistently and automatically.
Specifically for the service based local policy (SBLP) control, there are related functions and protocols in 3GPP for the use of QoS control in the IP Multimedia Subsystem (IMS) of a UMTS network [3GPP TS 23.207: "End-to-end QoS Concept and Architecture" , V5.2.0, Jan. 2002.]. The main purpose of SBLP control is to enable coordination between events in the application layer and the resource management
in the IP bearer layer. It ensures that the resources allocated at the bearer layer will not exceed those authorized at the application layer. This concerns mostly the
Go interface [3GPP TS "29.207: "Policy Control over Go Interface", VO.6.0, Feb. 2002.].
The Go interface allows service-based local policy and QoS inter-working information to be pushed to or requested by the Policy Enforcement Point in the GGSN from a Policy Control Function (PCF) . This information is used by the GGSN in support of, e.g., control of DiffServ interworking, control of the service-based policy "gating" function in GGSN and other functions as defined in stage 2 specifications [3GPP TS 23.207: "End-to-end QoS Concept and Architecture", V5.2.0, Jan. 2002.] . The Go interface uses IP flow based policies.
The Go interface shall conform to the IETF Common Open Policy Service (COPS) protocol defined in [IETF RFC 2748] . The COPS protocol supports a client/server interface between the Policy Enforcement Point in the GGSN and the PCF. Furthermore, the Go interface shall conform to the IETF COPS-
PR protocol defined in [IETF RFC 3084] .
In short, the 3GPP SBLP and Go solutions are based on the IETF COPS model and protocol [IETF RFC2748, RFC2753] . In the COPS model, the two main architectural devices for policy control are the PEP (Policy Enforcement Point) and the PDP (Policy Decision Point) . The PEP represents a component that runs on a policy aware node. It is the point at which policy decisions are actually enforced. Policy decisions are made primarily at the PDP. The communication between the PDP and the PEP is conducted using the COPS protocol.
The abstract terms PDP and PEP correspond to Policy Server and Policy Client Device in a concrete network environment .
In the 3GPP IMS case, PDP corresponds to the PCF (as part of a P-CSCF) and. PEP corresponds to GGSN1 in the GPRS network.
There is one basic restriction in the IETF COPS model . In one network domain and for a certain client type, only one PDP is allowed to serve the PEPs of this client type. Which means, if several PDPs exist in the same domain then they must be of different client types.
The direct usage of the IETF COPS model • in 3GPP currently causes several problems :
As is identified in [3GPP S2-012754: "GGSN, P-CSCF and PCF Relationship", Oct. 2001.], there is the need to allow several PCFs to access the same GGSN. However, this will conflict with the COPS model which does not allow the access of several PDPs of the same client type to a PEP.
The IMS subsystem is access- independent . And each access system will normally have its own policy server (PDP) . In order to allow coordination of the PDPs, they should be assigned the same client type. Again, this is not consistent with the COPS model .
However there is a need to allow a more flexible architecture than the one allowed in the IETF COPS model. Several solutions for these problems have been suggested but none of them has proved to work adequately.
It is an object of the invention to improve control of data transmission policies in at. least one telecommunication network. The object is achieved by the invention defined in the independent claims .
To solve the problems fundamentally, the invention proposes to modify and extend the current COPS model by using the following innovative function and method:
A new functional entity called Policy Regulation Point (PRP) is introduced in a network domain. The main function of the
PRP is to coordinate and regulate the functionality of the
PDPs themselves. At the time of initialization, a PDP registers with the PRP to get its basic configuration and task assignment. The interaction between the PRP and the PDPs are active and dynamic. Which means that the PRP will regulate the functionality of the PDPs dynamically and the PRP will also react to the dynamic states of the PDPs, which in turn may cause the PRP to adjust the behavior of other PDPs. Through the PRP, the state consistency among PDPs is maintained.
The above function and method have the following advantages:
(1) Several PDPs of the same client type are allowed to exist and to access the same PEP since the PRP can now regulate the possible conflicts in their sub-areas of responsibility statically or dynamically.
(2) Several PDPs of the same client type are allowed to exist in one domain and the behavior of these PDPs can be coordinated by the PRP to achieve a consistent system effect.
(3) The current COPS model is enhanced in that the PDPs of different client types can now interact and coordinate with each other through the PRP .
(4) The coordination of the PRP can be static. It can also be dynamic to achieve the effect of dynamic adjustment, dynamic load balancing, dynamic activation and deactivation of policy rules, etc. (This is in contrast to
the coordination by a static entity like a passive database . )
(5) The suggested enhancement allows a more flexible policy control architecture. (This will serve as an input to further standardization in 3GPP Release 6. It can also serve as an input to the related IETF working groups . )
There are many possible realizations of the interaction between the PRP and the PDPs. One realization approach is to apply the COPS model again for the relationship between the PRP and the PDPs. That is, in COPS terms, the PRP serves the role of policy server (PDP) while the PDPs are its policy clients (PEPs) . The PRP can then control PDPs using the COPS protocol .
So according to the invention, a function entity called Policy Regulation Point (PRP) can be introduced in the policy architecture based on the COPS model as an active device to coordinate and regulate policy servers (PDPs) ; policy servers (PDPs) are configured by the PRP about the basic division of responsibility at the time of initialisation and active interaction is conducted between the PRP and the PDPs in response to changing network situations.
Additional features of the invention will be apparent from the detailed description of a preferred embodiment and from the drawings . Figure 1 shows the usage of a policy regulation device PRP ■ in an IP Multimedia Subsystem IMS with two access networks .
Figure 1 illustrates an example of the invention, where a dynamic adjustment of traffic regulation at macro-level is achieved. In the example, it is assumed that it is desired, to favor the traffic from, the GPRS access area over the traf ic from the WLAN access area, which will both pass through an
IMS network in the end.
In 'the example, an IMS system controls two access systems. One is a GPRS access system. The other is a wireless LAN . access system. Each access area is controlled by its own policy decision device (= policy decision point PDP), i.e. by PCF 18 and WLAN-GW 19 respectively. At the time of initialization (steps 1 and 2 in the figure), the PDPs 18, 19 are configured by the policy regulation device (= policy regulation point PRP 20) with their respective basic behavior rules. In normal operations, the PDPs 18, 19 then control their own Policy Enforcement Points (=PEPs= data transmission devices 12, 13, 14, 16, 17 etc) independently. Suppose GGSN3 (14) now reports a large traffic needs in its area to its policy decision device PCF 18 (PDPl) in step 3. The PCF 18 (policy decision device PDPl) in turn determines that the traffic volume in the GPRS access area 11 has reached a new level and it reports this situation to the PRP 20 in step 4. In view of this new situation, the policy regulation device (=Policy Regulation Point PRP 20) activates a meta-policy and instructs in step 5 the WLAN-GW (PDP2 =19) to regulate the traffic volume in its (19) area to a lower level. The WLAN-GW (PDP2= 19) in turn remakes some of its decisions about traffic regulations and communicates the decisions in steps 6, 7 as instructions to the base stations (data transmission devices BS1 (PEP4) , BS2 (PEP5) ) that are under its (19) control . The base stations (data transmission devices BS1 (PEP4) , BS2 (PEP5) ) now work according to the received
instructions, i.e. they e.g. regulate the traffic volume in their area to a lower level .