DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0039] The present invention is now described by way of reference to a particular non-limiting example, and in particular by way of reference to a universal mobile telecommunication services (UMTS) network connected to an Internet protocol (IP) network. However the choice of communication system is for illustrative purposes only. The invention is applicable to any packet switched communication network which has connections with external servers, and in which there is established a service level between a user and a packet switched network.

[0040] Referring to FIG. 1 , there are illustrated schematically a packet switched mobile communication system in which a preferred embodiment of the present invention may be implemented.

[0041] Referring to FIG. 1 , there is illustrated three cells 8 a , 8 b , 8 c of a cellular structure. Each cell is defined by a radio coverage of a respective base transceiver station (BTS) 2 a , 2 b , 2 c . Each base transceiver station is associated with a respective antenna 4 a , 4 b , 4 c . A roaming mobile station (MS) 6 , more generally referred to as user equipment (UE), is shown in cell 8 c . In practice, many roaming mobile stations will be present throughout a cellular structure.

[0042] The base transceiver stations 2 a , 2 b , 2 c are connected into the network infrastructure of the UMTS system via respective connections 10 a , 10 b , 10 c of base station controller (BSC) 12 .

[0043] The structure and implementation of a packet switched UMTS system are well-known in the art, and are not discussed in detail herein. FIG. 1 shows the main elements of a UMTS system 30 necessary for an understanding of the present invention. The base station controller (BSC) 12 is connected to a serving GPRS support node (SGSN) 16 via communication link 14 . The SGSN 16 is connected to a gateway GPRS support node (GGSN) 20 via a communication link 18 . The GGSN 20 is connected to an IP network 24 via a communication link 22 . In practice, GGSN 20 may be connected to more than one IP network. The IP network 24 is preferably a network independent of the UMTS network, but which is controlled by the operator of the UMTS system.

[0044] In embodiments, the invention requires, as will be described further hereinbelow, that either the GGSN or an associated external policy server (discussed below) is aware of the service location specification (SLS) QoS and its mapping to a particular IP flow. In an embodiment there is an assumption that if there is an SLS between a third party service provider and the IP network provider, then the GGSN (or the policy server) may not be aware of the SLS QoS unless the IP network is under the administration of the UMTS network provider. However, it is not essential that the UMTS network and the IP service provider are under the same administration The only requirement is that the SLS QoS information is available in the GGSN (or the policy server). However it is outside the scope of the present invention as to how this information is made available.

[0045] Further referring to FIG. 1 , the IP network 24 is further connected to various service providers. In FIG. 1 , the IP network 24 is shown as connected to three service providers 28 a , 28 b , 28 c via communication links 26 a , 26 b , 26 c . Various service providers provide services to users of the UMTS system, i.e. users associated with user equipment such as mobile station 6 .

[0046] The UMTS network, the infrastructure of which is generally designated by reference numeral 30 in FIG. 1 , may establish a service level agreement (SLA) and a service level specification (SLS) with the IP network 24 . Several such agreements and specifications may be established between the UMTS system and the IP network 24 . More specifically, in a preferred embodiment the UMTS network and the IP network may agree different service level specifications to be associated with different data packet flows. Thus the UMTS network and the IP network may agree a service level specification for each particular type of packet flow. However it is not always possible to make flow based SLSs; they may be sometimes only aggregate based.

[0047] In addition, the UMTS network may similarly agree service level agreements and service level specifications with various service providers 28 a - 28 c . Such service level specifications, in a preferred embodiment of the present invention, are similarly related to the type of packet flow in a communication session.

[0048] It should also be noted that UMTS network 30 may be associated with more than one IP network, and service level agreements and service level specifications may be established with more than one IP network. Similarly service level agreements and service level specifications may be associated with service providers associated with other IP networks.

[0049] A preferred embodiment of the present invention is now described further with reference to FIGS. 2 - 5 .

[0050] Referring to FIG. 2, a normal PDP context activation in accordance with known standards is illustrated. An end user, which is the user associated with mobile station 6 in FIG. 1 , initiates a 3G service. The MS 6 activates a PDP context request 60 to the SGSN 16 . The SGSN 16 checks its own internal resources and the Iu interface between the radio access network (RAN) and the SGSN to ensure that the desired quality-of-service for the PDP context can be supported. Responsive thereto, the SGSN sends a create PDP context request to the GGSN 20 .

[0051] The PDP context request received by the GGSN 20 includes an identification of the quality of service profile requested by the MS 6 . The GGSN 20 determines if there are sufficient resources in the-UMTS network to support this QoS, by checking its own internal resources and the interface between the SGSN and the GGSN. This involves ensuring there is sufficient resources associated with the SGSN 16 , the GGSN 20 , and the radio interface. The GGSN 20 then returns a create PDP context response 64 to the SGSN 16 . The SGSN 16 then returns an activate PDP context accept 66 to the MS 6 . This establishment of the PDP context is in accordance with current standard procedures.

[0052] Once the PDP context is established in accordance with current standards ( _— 3GGP 23.060), the standards specified in the GGSN 20 can initiate a modification procedure of the PDP context. Modification of the PDP context in accordance with the preferred embodiments of the present invention is now described.

[0053] In a preferred embodiment, as mentioned hereinabove, the service level specification agreed between the UMTS network and the IP network or associated service providers is based upon the packet flow of the session. Certain service level specifications are defined to be associated with certain types of packet flow.

[0054] The GGSN 20 may identify the flow related to a particular service level specification that it receives in the create PDP context message 62 from the SGSN 16 during the normal PDP context activation procedure as shown in FIG. 2 .

[0055] A preferred embodiment of the present invention identifies the flow of the communication session during the secondary PDP context activation. During the secondary PDP context activation procedure, user equipment sends to the GGSN 20 a traffic flow template (TFT) information. The TFT is a set of filters, specified in 23.060 (3GPP technical specification 23.060: General Packet Radio Service (GPRS); Service description; Stage 2, 3GPP TSG SA, v.x.x.x, 2002), as follows

[0056] Each valid packet filter contains a unique identifier within a given TFT, an evaluation precedence index that is unique within all TFTs for one PDP address, and at least one of the following attributes:

[0057] Source Address and Subnet Mask.

[0058] Protocol Number (IPv4)/Next Header (IPv6).

[0059] Destination Port Range.

[0060] Source Port Range.

[0061] IPSec Security Parameter Index (SPI).

[0062] Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask.

[0063] Flow Label (IPv6).

[0064] The principle of the preferred embodiment of the present invention is to use the information set in the TFT in order to identify the flow within the service level specification agreed. The flow identification in a service level specification may be performed using the following information:

[0065] DSCP value

[0066] Source information (Source address, set of source address, source prefix, set of source prefix)

[0067] Destination information (Destination address, set of destination address, destination prefix, set of destination prefix)

[0068] Application information (protocol number, protocol number and source port/destination port).

[0069] Thus it is possible, using the information set in the TFT, to identify a flow and therefore map it to a certain service level specification.

[0070] The information that relates to service level specifications agreed between the different parties, i.e. the flow identifiers and the associated quality of service profiles, may or may not reside in the GGSN 20 The specific implementation of where this information is held is outside the scope of the present invention. However, referring to FIG. 3 , there are described two possible implementations.

[0071] In one possible implementation, the service level specification information is stored in the GGSN 20 itself. Referring to FIG. 3 , there is illustrated a case where the service level specification is stored outside of the GGSN 20 , for example in a policy server 70 . The TFT information received by the GGSN is provided on a line 72 to the policy server 70 , and the policy server 70 responsive thereto returns the service level specification quality of service associated with the TFT information to the GGSN 20 In either scenario, the service level specification and quality of service information are only available if the TFT information is identified, i.e. the packet flow is mapped to a service level specification

[0072] In accordance with the present invention, if a service level specification agreed quality of service profile is in contradiction with the UMTS quality of service profile agreed between the UMTS network and the mobile station, then the GGSN 20 proposes a new UMTS quality of service profile.

[0073] A more detailed implementation of this embodiment of the present invention will now be described with reference to FIGS. 4 and 5 .

[0074] Referring to step 90 of FIG. 5 , in the first step the GGSN 20 accepts the PDP context requested by the user equipment, responsive to the signal 62 in FIG. 2 . At this stage the GGSN does not consider any modification of the PDP context based on service level specifications. In step 92 , the GGSN creates a PDP context request and sends this to the SGSN 16 , as represented by message 64 in FIG. 2 . In step 94 , GGSN 20 identifies the flow of the packet session associated with the PDP context. As discussed in relation to FIG. 3 above, this is carried out internally within the GGSN or by the GGSN accessing information from an external block.

[0075] In step 96 , the GGSN compares the quality of service profile associated with the service level specification related to the flow, and determines whether it is consistent with the quality of service specification agreed between the UMTS network and the mobile station during the initial PDP context establishment

[0076] If, in a step 100 , it is determined that the flow quality of service is consistent with the service level specification quality of service, and there is no requirement to consider modification of the PDP context, then the PDP context is determined to be okay (step 98 ).

[0077] If the quality of service of the service level specification is not consistent with that agreed between the UMTS network and the mobile station, step 100 , then the GGSN modifies the already agreed PDP context.

[0078] Thus, in a step 102 , some short time after establishment of the PDP context the GGSN sends an update PDP context request to the SGSN, as represented by message 80 in FIG. 4 . This request is sent in order to modify the already activated PDP context This message So contains the new quality of service profile that results from the decision made in step 100 .

[0079] The SGSN 16 generates a modified PDP context request message 82 to the mobile station 6 responsive to receipt of the message 80 . This update procedure follows the update procedure specified in GSM 23.060 (see above for full reference). The SGSN may restrict the quality of service, based on its capabilities, current load, or the subscribed quality of service profile. That is, the SGSN may further restrict the quality of service identified by the GGSN 20 in relation to the resources available between the UMTS network and the mobile station. Only then does the SGSN 16 send the modified PDP context request message 82 Mobile station 6 then must make a decision, in accordance with standardized procedures, as to whether to accept the updated PDP context or reject it. In the event that the mobile station 6 determines to accept the modified PDP context, the modified PDP context accept message 84 is transmitted to the SGSN 16 . Then, the SGS 116 transits an update PDP context response message 86 to the GGSN 20 . If the user equipment does not accept the new quality of service profile proposed by the GGSN 20 , then the mobile station 6 must deactivate the PDP context.

[0080] Thus, in the preferred embodiment a new quality of service profile is proposed by the GGSN 20 only in cases where it is clear that the user equipment should not be allowed to use the UMTS quality of service profile which it has requested, because of a contradiction with the service level specification.

[0081] Given this embodiment, if the flow of the packet session cannot be identified, or if there is no service level specification quality of service associated with identified flow, then the GGSN 20 takes no action to check or modify the established PDP context, and the procedure continues as normal. Thus the invention advantageously provides the use of an extra service level specification to determine the quality of service level profile.

[0082] In an example, the user equipment may ask for a streaming UMTS quality of service profile, although it is using a service treated as background traffic in the external IP network once the flow is identified by the CGSN 20 , and mapped to a specific service level specification, it is identified that according to the service level specification, this flow should be treated as background and not streaming. After the requested PDP context has been successfully set up, the GGSN 20 sends an update PDP context request to the SGSN 16 , which in turn sends a modified PDP context request to the user equipment. User equipment then accepts or rejects the proposed quality of service. If the user equipment rejects the proposed profile, it deactivates the PDP context.

[0083] The GGSN 20 accepts the PDP context request in step 90 of FIG. 5 , before considering any modification to the PDP context. However alternative implementations may be possible.

[0084] In an alternative, GGSN 20 may identify the flow and perform the comparison of steps 94 to 100 prior to accepting the initial PDP request. If the GGSN 20 operated in this way, and if the flow was not consistent with the service level specification, it would be necessary to reject the PDP request, thus canceling the PDP context activation procedure GGSN 20 would then itself activate a new PDP context with the correct quality of service profile. Such a network initiated PDP context activation procedure is only specified for primary PDP context. It is therefore not suitable for the preferred embodiment of the invention where secondary PDP contexts are utilized.

[0085] In a second alternative, the PDP request could be accepted in a modified quality of service profile. However, the SGSN 16 would then need to check if the modified quality of service profile is acceptable according to the user subscription definition. Such a step may require modification to the standardized procedures, and would therefore not be an ideal proposal.

[0086] Although the present invention has been described in relation to a preferred embodiment where TFT in secondary PDP contexts are used in order to identify the flow, the invention is not limited to such a specific arrangement in its general applicability. Any technique may be used which enables the packet session to be identified and correlated with agreed service level specifications.

[0087] Further, although in preferred embodiments an identification of the flow is preferably made in the secondary PDP contexts, in an alternative, where for example it is not possible to identify the flow (i.e. map it to a certain SLS) during secondary PDP context activation, in a further embodiment of the present invention it may be identified later when the first downlink packet is received by the GGSN.

[0088] The general principles of this embodiment of the present invention, based on a first downlink packet, are described hereinafter with reference to FIG. 6 , followed by a specific example.

[0089] Referring to FIG. 6 , it is assumed that a PDP context has been established, and an IP packet is received at the GGSN in a step 110 . In a step 112 , the GGSN then checks to ensure that the IP header of the received IP packet is consistent with existing policy filters. Specifically, the GGSN is configured in accordance with the established PDP context to support an agreed quality of service. On receiving the IP packet, the GGSN utilizes information in the IP header which identifies the type of packet. The GGSN uses this identity of the packet to determine if the quality of service agreed in establishing the PDP context is consistent with the quality of service agreed for this type of packet with the external service provider.

[0090] If the GGSN determines that the quality of service is consistent, and the IP packet header parameters match the configured policy filters set in the GGSN, then in a step 124 the policy is executed for the transmission of the packets. The transmission continues until in a step 126 the packet transmission ends.

[0091] However, if in step 112 the GGSN determines that the IP packet headers are not consistent with the existing GGSN policy filters, in a step 114 the GGSN requests a policy from the policy server. The GGSN then waits to be advised of an appropriate policy (in step 116 ), and enters a wait cycle in step 118 . Once a policy is obtained in step 120 , the obtained policy is executed. The filters and policy information are then updated in the GGSN. This may involve initiating a PDP context modification. Thereafter, the transmission continues until in a step 126 the packet transmission ends.

[0092] This embodiment of the invention therefore provides a technique in which an element of the mobile network, such as the GGSN, detects activation of a new IP service and associated traffic, and if necessary requests quality of service authorization for the service/traffic. As such, the network is able to detect that the service has been created and traffic is entering the network, and modify, and/or activate, PDP contexts as needed.

[0093] The use of a downlink packet to identify the flow and ensure consistent quality of service is now described by way of an example. It should be noted that this technique may be used where it is not possible to ensure consistency of quality of service requests during PDP context activations, for example where a flow cannot be identified as mentioned hereinabove. However, it is also applicable generally as a technique for ensuring consistency of quality of service levels requested. The technique may be advantageously used to identify IP flows added to an existing PDP context.

[0094] For the purposes of this example it is assumed that a PDP context has first been established between the user equipment and the GGSN 20 .

[0095] It is assumed, for this example, that an operator has a service level agreement (SLA) with one content service provider that the HTTP traffic for that content service provider should be handled as AF2 traffic (interactive class with traffic handling priority 2 ), and FTP traffic should be handled as best-effort (background), unless a user specifically selects THP 2 in their subscription. This policy applies to all users using the sites of the content service provider. For the purposes of this example it is assumed that there is provided a policy server, such as policy server 70 in FIG. 3 . Within the service level specification (SLS), the policy server and the content service provider agree on a classification policy, including the classification filter parameters for HTTP and FTP, herein denoted as filter A and filter B.

[0096] The PDP context created by the UE is for HTTP traffic. As a result, filter A and a corresponding QoS policy is installed at the GGSN when a GTP tunnel is created for the PDP context, following PDP context activation.

[0097] Thereafter, the UE may activate access to a server of the content provider with a FTP request. The traffic comes into the GGSN, and the GGSN detects a mismatch, since the existing filter A is for HTTP traffic only. Responsive to detection of this mismatch, a policy request is triggered by the GGSN 20 to the policy control server 70 . The GGSN 20 does not forward any packets pending a response to the policy request, so that the flow will not progress. This is necessary, as the GGSN has no means to buffer large amounts of user traffic.

[0098] The policy control server 70 receives the policy request with the relevant flow identification information, in this embodiment based on Diffserv classification filter parameters. The policy server 70 then makes a new policy decision based on this information, and provides said new decision to the GGSN. The new policy decision includes the QoS treatment for the particular flow, which in this embodiment includes marking the DSCP as 0 (best effort) and applying filter B.

[0099] It is assumed that the GGSN has already been configured by a policy manager such that it knows the rules of how to map a QoS treatment to an associated QoS profile. The GGSN will participate in a PDP context re-negotiation, taking as the associated QoS profile for the modified PDP context the authorised profile for the PDP context that will carry the IP flow. In this specific example, the PDP context is downgraded to background class. Alternatively, the GGSN may request a second PDP context setup from the UE.

[0100] A similar approach may be taken in implementing SLAs with a streaming server, where the GGSN will be provided with a policy that the UDP traffic of a given port range from a given IP address should be mapped as AF4. In this way, if the on-going PDP context associates with, for example, interactive or background class, then the GGSN will detect the mismatch in policy when it cannot find a matching filter for the streaming traffic. This then triggers a policy request from the policy control entity, i.e. the policy server.

[0101] Although the above examples are given in relation to triggering a policy request in the downlink direction, the same principles can also work for uplink direction policy control.

[0102] The embodiments of the present invention generally ensure that the PDP context activation as well as quality of service profile negotiation result are in line with the service level objectives agreed with the customer beforehand. This is achieved, in embodiments, by classifying IP traffic according to policy when the IP service is created.

[0103] Furthermore the present invention has been described herein with specific reference to an arrangement where the quality of service level is modified The invention may equally apply to modification of other service characteristics which are agreed between the communications network and the user, and between the communication network and external networks.

[0104] Modifications and adaptations to the embodiments of the present invention described herein will be apparent to one skilled in the art. The present invention is more generally applicable than that given herein with relation to the preferred embodiments. The scope of the present invention is defined by the appended claims.