WO2009121403A1

WO2009121403A1 - Method and apparatus for distinguishing ip flows

Info

Publication number: WO2009121403A1
Application number: PCT/EP2008/053889
Authority: WO
Inventors: Hubert Przybysz; Alf Heidermark
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2008-04-01
Filing date: 2008-04-01
Publication date: 2009-10-08

Abstract

A method is provided for use by a first node (UE-A) of an IP network as part of an offer/answer (SDP) negotiation relating to an IP connection to be established by the first node (UE-A) to a second node (UE-B) of the network. The method comprises providing to the second node (UE-B) and/or an intermediate node (NW-A, NW-B) information relating to an IP port (port-A) from which the first node (UE-A) intends to establish the IP connection. The information enables the second node (UE-B) and/or the intermediate node (NW-A, NW-B) subsequently to distinguish different IP flows between the first and second nodes (UE-A, UE-B).

Description

METHOD AND APPARATUS FOR DISTINGUISHING IP FLOWS

Technical field

The present invention relates to a method and apparatus for use in a communications network, for example a Universal Mobile Telecommunications System having an IP Multimedia Subsystem.

Background

IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.

The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). UMTS is standardised by the 3rd Generation Partnership Project (3GPP). The 3GPP is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.

The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP

TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329

Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.

The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.

Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.229 V8.2.0 (2007-12).

Figure 1 of the accompanying drawings illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.

A user registers with the IMS using the specified SIP REGISTER method. During the registration process, it is the responsibility of the I-CSCF to select a S-CSCF if a S- CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality.

3GPP has specified policy control architecture and functions to allow applications like IMS to control packet flows passing through the access network. In 3GPP Release 7 this is specified mainly in TS 23.203 and TS 29.213. See also TS 23.207. There are services specified and deployed in IMS which use the Transmission Control

Protocol (TCP) transport protocol to exchange media (e.g. images, chat messages, whiteboard controls, game controls, etc). SIP and SDP protocols are used to establish the service session and to negotiate media related details. RFC 4975 for Message

Session Relay Protocol (MSRP) and RFC 4145 for Connection-Oriented Media are typically used to set up TCP-transported media flows. This is also specified in 3GPP

TS 24.229. For instance, usage of TCP-transported media is specified for Multimedia

Telephony, Combinational Services, Push-to-talk Over Cellular, and Multimedia Communication Suite.

The overall Policy and Charging Control (PCC) architecture is shown in Figure 2 of the accompanying drawings (which is derived from TS 23.203). IMS is an Application Function (AF) from the PCC perspective. Specifically, it is the P-CSCF function of the IMS system that interfaces with the Policy and Charging Rules Function (PCRF) over the Rx reference point.

The following issue with the current architecture has been identified by the present applicant.

The media transport address information exchanged today in the SIP/SDP signalling for a TCP-transported media flow concerns only the IP address and port to which the user agents want to have the TCP connection established. There is no information carried in the signalling between the user agents about the IP address and port from which the TCP connection will be established.

This can be a problem for the Policy and Charging Control and IMS, which uses the SDP offer/answer information signalled between the user agents to set IP packet flow descriptors in the PCC rules, which are then downloaded to the Internet Protocol - Core Access Network Gateway (IP-CAN GW) and control which IP flows are allowed and that they are charged correctly while other IP flows may be blocked or charged differently (typically at higher rates).

Figure 3 of the accompanying drawings schematically illustrates an example that highlights the problem. UE-A and UE-B negotiate between themselves session description information in SDP offer/answer signalling according to RFC 4145. Networks NW-A and NW-B, respectively serving UE-A and UE-B, and each including its P-CSCF, PCRF and IP- CAN GW, derive flow description information for downlink (DL) and uplink (UL) IP flows from the SDP offer/answer in order to create and install a corresponding PCC rule.

Due to the fact that the negotiated session description does not include any information about the IP port from which UE-A will establish the TCP connection, these parts of the flow descriptors in the PCC rules are wild-carded, meaning that any port may be used. In this respect, according to RFC 4145, having the number 9 as the port number in SDP means that this information is irrelevant - it is a so-called "discard port".

It is desirable to address this issue.

Summary

According to a first aspect of the present invention there is provided a method for use by a first node of an IP network as part of an offer/answer negotiation relating to an IP connection to be established by the first node to a second node of the network, the method comprising providing to the second node and/or an intermediate node information relating to an IP port from which the first node intends to establish the IP connection, the information enabling the second node and/or the intermediate node subsequently to distinguish different IP flows between the first and second nodes.

The first node is designated as the 'active' node in establishing the connection, such that for example it is the first node that initiates the establishing of the connection, with the second node cooperating with the first node in the establishing of the connection.

The method may comprise including the port information in an offer message sent from the first node to the second node as part of the offer/answer negotiation.

The method may comprise including the port information in an answer message sent from the first node to the second node as part of the offer/answer negotiation.

According to a second aspect of the present invention there is provided a method for use in an IP network in which an offer/answer negotiation is performed relating to an IP connection to be established by a first node of the network to a second node of the network, the method comprising receiving from the first node, as part of the negotiation, information relating to an IP port from which the first node intends to establish the IP connection, and using the information subsequently to distinguish different IP flows between the first and second nodes.

The method may be performed at a node intermediate the first and second nodes.

The intermediate node may be located in an access network serving the first or second node.

The method may comprise applying different policies to the different respective IP flows so distinguished.

The method may comprise applying different traffic control policies to the different respective IP flows so distinguished.

The method may comprise applying different quality of service policies to the different respective IP flows so distinguished.

The method may comprise applying different charging policies to the different respective IP flows so distinguished.

The method may comprise using the port information to derive or update a plurality of filters, each filter being associated with at least one policy to be applied to an IP flow matching the filter.

The method may comprise determining which port of the first node is associated with the IP flow, and selecting as a match at least one of the filters in dependence upon the determination.

Each of the filters may specify an IP port of the first node, an IP port of the second node, and respective IP addresses of the first and second nodes.

The method may comprise setting up a plurality of bearers, for carrying the IP flows, in dependence upon the port information. Each filter may be associated with a respective one of the bearers.

The network may be a Universal Mobile Telecommunications System network, and the port information may be used by a Policy and Charging Control function of the network to distinguish the different IP flows.

The filters may comprise Policy and Charging Control rules.

The offer/answer negotiation may be a negotiation of media components for the connection, with the port for which information is provided being associated with a respective one of the negotiated media components.

Each of the IP flows may be associated with a respective one of the negotiated media components.

The offer/answer negotiation may be performed according to the Session Description Protocol, SDP.

The port information may be carried in an SDP attribute of an offer or answer message.

The port information may be carried in the m line of the SDP and an indication that the port information in the m line is valid is carried in an SDP attribute of an offer or answer message.

The connection may comprise a Transmission Control Protocol, TCP, connection.

According to a third aspect of the present invention there is provided an apparatus for use as or in a first node of an IP network, comprising means for performing an offer/answer negotiation relating to an IP connection to be established by the first node to a second node of the network, as a part of which negotiation information is provided to the second node and/or an intermediate node relating to an IP port from which the first node intends to establish the IP connection, the information enabling the second node and/or the intermediate node subsequently to distinguish different IP flows between the first and second nodes. According to a fourth aspect of the present invention there is provided an apparatus for use in an IP network in which an offer/answer negotiation is performed relating to an IP connection to be established by a first node of the network to a second node of the network, the apparatus comprising means for receiving from the first node, as part of the negotiation, information relating to an IP port from which the first node intends to establish the IP connection, and means for using the information subsequently to distinguish different IP flows between the first and second nodes.

According to a fifth aspect of the present invention there is provided a program for controlling an apparatus to perform a method according to the first or second aspect of the present invention or which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the third or fourth aspect of the present invention. The program may be carried on a carrier medium. The carrier medium may be a storage medium. The carrier medium may be a transmission medium.

According to a sixth aspect of the present invention there is provided an apparatus programmed by a program according to the fifth aspect of the present invention.

According to a seventh aspect of the present invention there is provided a storage medium containing a program according to the fifth aspect of the present invention.

According to another aspect of the present invention, there is provided a method of supporting multiple media components relating to a session established between first and second nodes of a communications network, the first and second nodes being served respectively by first and second access networks, establishment of the session involving an offer/answer negotiation of media components between the nodes, and the method comprising, as part of the negotiation, providing to at least one of the first and second access networks information relating to a plurality of ports of the first node to be associated with the different respective media components negotiated for the session, or, subsequent to the negotiation, using the ports information received at the at least one access network to distinguish between different media components carried in traffic relating to the session. The first and second access networks could be the same.

An embodiment of the present invention addresses an issue mentioned above. Brief description of the drawings

Figure 1 , discussed hereinbefore, illustrates schematically the integration of an IP Multimedia Subsystem into a 3G mobile communications system;

Figure 2, also discussed hereinbefore, illustrates the Policy and Charging Control architecture in IMS;

Figure 3, also discussed hereinbefore, is a message exchange diagram that schematically illustrates a problem with a previously-considered solution, as identified and appreciated by the present applicant;

Figure 4 is a message exchange diagram that schematically illustrates how operation of an embodiment of the present invention differs from the previously-considered solution depicted in Figure 3; and

Figures 5A to 5C contain a message exchange diagram that illustrates in more detail operation of an embodiment of the present invention.

Detailed description

As mentioned above, a problem with the existing solution stems from the fact that parts of the IP flow descriptions included in the installed PCC rules are wild-carded, which means that the descriptors are not unique, and may therefore describe IP flows other than the intended ones.

This problem exhibits itself when multiple IP flows match the wild-carded descriptors in a PCC rule, or when multiple PCC rules are generated (due to multiple media flows being authorised) with exactly the same IP flow descriptors due to wild-carding.

For instance, the problem occurs when:

multiple concurrent TCP connections (from the same TCP client IP address) to the same TCP server IP address and port are to run over different bearer connections (e.g. different PDP contexts in GPRS) possibly with different quality of service provided by the bearer; or when multiple concurrent TCP connections (from the same TCP client IP address) to the same TCP server IP address and port are to be charged differently for bearer usage.

Consider, for instance, the following example scenario where QoS differentiation is desired but not fulfilled. Assume that the UE uses GPRS access and uses the UE- initiated bearer control mode, and wishes to use different QoS for different TCP media flows. The UE acts as a TCP client and runs more than one TCP media flow concurrently to the same TCP server port. The UE is either communicating with the same peer (which uses the same IP address but different TCP client ports for these different flows) or through a "box in the middle" which maps the addresses of these different flows (in such a way the same IP address but different TCP client ports for these different flows are used). Note also that these different TCP flows may, but need not, belong to the same service or application session.

With the current solutions, in the above scenario some of the TCP media flows may be forwarded to the UE over incorrect bearer with QoS different from the requested QoS. Under certain circumstances, if the network applies policies on the bandwidth allowed on a bearer some of the TCP packets may be dropped. Under certain circumstances, bearer establishment may fail.

An example of such QoS problem scenario is when a mobile user, connected over GPRS, sets up a multimedia telephony session to another user, also connected over GPRS, with MSRP/TCP based chat (messaging) media flow and a TCP based gaming media flow carrying game controls (MSRP is Message Session Relay Protocol). The chat media flow is to be transported over a best effort bearer while the gaming media flow is to use an interactive bearer. However, as a consequence of the aforementioned problems, both of these media flows will be transported in the direction from the network to the UE over one of the two bearers, i.e. either over the best effort bearer or over the interactive bearer.

Another example scenario to consider is where the charging differentiation is desired but not fulfilled. Assume that the UE uses GPRS access and uses the UE-initiated bearer control mode, and wishes to use the same best effort bearer for TCP media flows. The UE acts as a TCP client and runs more than one TCP media flow concurrently with the same TCP server port. The UE is either communicating with the same peer (which uses the same IP address and the same TCP server port for these different flows) or through a "box in the middle" which maps the addresses of these different flows (in such a way the same IP address and TCP server port for these different flows are used). Note also that these different TCP flows may, but need not, belong to the same service or application session. In this scenario the operator wants to differentiate bearer charges for the usage of these concurrent TCP media flows e.g. depending on the service.

With the current solutions, in the above scenario some of the TCP media flows may be charged incorrectly.

An example of such a charging problem scenario is when a mobile user, connected over GPRS, sets up a multimedia telephony session to another user, with MSRP/TCP based chat (messaging) media flow, where the operator wishes not to charge for the usage of the bearer in the context of multimedia telephony. Then the user sets up another TCP connection to the other user using the same bearer and the same TCP server port, but this time in the context of another application e.g. gaming, and a TCP based gaming media flow carrying game controls. The operator normally allows direct non-service specific TCP connections over a best effort bearer but applies volume charges for such TCP flows, but in this case the second TCP connection is zero charged.

Other problem scenarios also exist, but are not mentioned further here for brevity, where media packets are dropped.

An embodiment of the present invention aims to enhance the session description protocol with additional information about the TCP client source port from which the UE will establish the TCP connection. This new piece of information complements the information exchanged in the existing SDP offer/answer procedure where the endpoints agree on how to establish a TCP connection for use by a media flow. The new information concerning the TCP client source port can be used by the network(s) and the Ues, and will allow them to disambiguate any multiple TCP media flows. In one embodiment, each negotiated TCP flow is identifiable by its full IP 5-tuple <IP source address, source port, IP destination address, destination port, and protocols This, in turn, will allow the UE and the network unequivocally to allocate and bind each flow separately to a bearer.

The additional information in an embodiment of the present invention, and its effect on the PCC rules installed in the IP-CAN, is illustrated schematically in Figure 4. The scheme as illustrated in Figure 4 can be compared with the previously-considered scheme as described above with reference to Figure 3.

There are a number of possible ways of implementing this idea in the SDP. For example:

a new SDP attribute can be defined to carry the TCP client port number for the media; or a new SDP attribute can be defined to indicate that the port number in the media (m=) line is the correct TCP client port for the media;

Other implementations are possible and are not excluded here.

To cater for UEs that wish to set up a TCP connection from another IP address than their own, an additional piece of information can be added to the SDP concerning the TCP client IP address.

The message exchange sequence depicted in Figures 5A to 5C is an example detailing how signalling the TCP client port between the UEs and across the networks is carried out in an embodiment of the present invention.

In this embodiment, user A (who is using UE-A) decides to initiate a multimedia session with user B (who is using UE-B). User A wants to play a game with user B and chat at the same time. UE-A initiates therefore a SIP session addressed to user B (typically a SIP INVITE message is sent from UE-A, though this is not shown in the sequence illustrated in Figures 5A to 5C). SDP negotiation is part of the SIP session establishment.

In this example, UE-A sends an SDP offer which includes two media components: one for the chat media (for which the media type is 'message') and the other for game control signals (for which the media type is 'control'). While the chat media does not require higher quality of service than best effort, the game controls media do require high quality of service to provide real-time characteristics.

In the SDP offer, UE-A includes (among other things) transport connection details for each of the media components as follows:

For the chat (message) media, UE-A wants to use MSRP protocol over TCP transport protocol ('msrp/tcp'), wants to initiate the TCP connection itself (i.e. it offers to be 'active' in establishing the connection), and provides the IP address and port from which it will establish the TCP connection (shown as IP-

A and port-A1 in the sequence). Including the port-A1 information in the SDP has not been previously proposed;

For the game controls (control) media, UE-A wants to use TCP transport protocol ('tcp'), wants to initiate the TCP connection itself (i.e. it offers to be 'active' in establishing the connection), and provides the IP address and port from which it will establish the TCP connection (shown as IP-A and port-A2 in the sequence). Including the port-A2 information in the SDP has not been previously proposed.

Network NW-A is the network serving User A. NW-A can e.g. be a GPRS access network with policy and charging control architecture including (among others) such nodes as GGSN, PCRF, and P-CSCF (being the node acting as an application function) as per Figure 2. NW-A may, however, be any other network that has functionality dependent on SDP negotiated media components. Such functionality may be to police/restrict usage of network resources, to deliver applicable quality of service, or to charge.

Upon receipt of the SDP offer, NW-A stores it for further processing.

Network NW-B is the network serving User B. NW-B can e.g. be a GPRS access network with policy and charging control architecture including (among others) such nodes as GGSN, PCRF, and P-CSCF (being the node acting as an application function) as per Figure 2. Just as for NW-A, the NW-B may be any other network that has functionality dependent on SDP negotiated media components. The SDP offer is sent from NW-A to NW-B over a signalling network that is not shown in the sequence for simplicity (as the details are not important in respect of the present invention, and are widely known). The IMS network, including its l-CSCFs and S- CSCFs, is one such signalling network.

Upon receipt of the SDP offer, NW-B stores it for further processing.

UE-B receives the SDP offer and accepts it. UE-B returns an SDP answer with relevant information including (among other things) transport connection details for each of the media components as follows:

For the chat (message) media, UE-B accepts to use MSRP protocol over TCP transport protocol ('msrp/tcp'), accepts that UE-A will establish the

TCP connection (i.e. it accepts to be 'passive' in establishing the connection), and provides the IP address and port to which to establish the TCP connection

(shown as IP-B and port-B in the sequence);

For the game controls (control) media UE-B accepts to use TCP transport protocol ('tcp'), accepts that UE-A will establish the TCP connection (i.e. it accepts to be 'passive' in establishing the connection), and provides the

IP address and port to which to establish the TCP connection (shown as IP-B and port-B in the sequence). Note that it is the same IP address and port as for the chat media.

In the above description, port-A1 and port-A2 are the ports from which the TCP connections will be established, when viewed from UE-A, which is designated as the active node in establishing the TCP connection. Port-A1 and port-A2 are referred to herein as TCP client ports. On the other hand, port-B is the port to which the TCP connections will be established - again, when viewed from UE-A, which is designated as the active node in establishing each of the TCP connections. UE-B is designated as the passive node in this respect, since it cooperates with UE-A to establish the TCP connection, but does not itself 'establish the TCP connection' in that it does not actively initiate establishment of the TCP connection. Port-B is referred to herein as a TCP server port. It will be appreciated that, in contrast with the above description, it could be that the SDP answerer is designated as the one to establish the TCP connection (as the 'active' node), in which case the information about the port address from which the endpoint which will establish a TCP connection is provided in the SDP answer. Details about this type of negotiation are documented in RFC 4145 and are not repeated here. The idea to provide valid TCP client port information in the SDP applies to all the possible negotiation scenarios.

The SDP answer traverses back through the networks NW-B and NW-A to UE-A. These networks use the information in the SDP answer to create (among other things)

IP filter information to match the media components negotiated between the UEs.

These IP filters are installed in the respective network to be able to later identify the IP packets (used to transport the media flows) to belong to a particular media component.

In this example it is chosen to show these networks to include Policy and Charging Control function as according to 3GPP specifications. PCC is used for policing

(allowing/blocking), charging, and assuring quality of service for the IP flows.

When NW-B has both the SDP offer and answer information it is able to create the IP filter information for each media component. An IP filter is an IP 5-tuple including: <source IP address, source port, destination IP address, destination port, protocols Since TCP is by definition bidirectional each TCP connection is represented by two IP filters, one for each direction. The information is derived from the transport information for each media component as follows:

• For the chat (message) media

In the downlink (DL, i.e. to the UE-B) direction:

Source IP address is set to IP-A

Source port is set to the newly signalled port-A1

Destination IP address is set to IP-B • Destination port is set to port-B

Protocol is set to TCP In the uplink (UL, i.e. from the UE-B) direction:

Source IP address is set to IP-B

Source port is set to port-B • Destination IP address is set to IP-A

Destination port is set to the newly signalled port-A1 Protocol is set to TCP For the game controls (control) media

In the downlink (DL, i.e. to the UE-B) direction:

Source IP address is set to IP-A • Source port is set to the newly signalled port-A2

Destination IP address is set to IP-B Destination port is set to port-B Protocol is set to TCP

In the uplink (UL, i.e. from the UE-B) direction: • Source IP address is set to IP-B

Source port is set to port-B Destination IP address is set to IP-A Destination port is set to the newly signalled port-A2 Protocol is set to TCP

Similarly, when NW-A has both the SDP offer and answer information it is able to create the IP filter information for each media component. The information is derived from the transport information for each media component as follows:

• For the chat (message) media

In the downlink (DL, i.e. to the UE-A) direction: Source IP address is set to IP-B Source port is set to port-B Destination IP address is set to IP-A • Destination port is set to the newly signalled port-A1

Protocol is set to TCP

In the uplink (UL, i.e. from the UE-B) direction: Source IP address is set to IP-A Source port is set to the newly signalled port-A1 • Destination IP address is set to IP-B

Destination port is set to port-B Protocol is set to TCP For the game controls (control) media

In the downlink (DL, i.e. to the UE-B) direction: • Source IP address is set to IP-B

In the uplink (UL, i.e. from the UE-B) direction: • Source IP address is set to IP-A

Source port is set to the newly signalled port-A2 Destination IP address is set to IP-B Destination port is set to port-B Protocol is set to TCP

The act of using by the network (NW-A and NW-B) the newly signalled TCP client port information as part of creating the IP filters is novel. This is illustrated in Figure 5A.

In case of a network with 3GPP PCC, these IP filters are part of PCC rules. The PCC rules consist of additional information to support PCC functionality such as gating (allowing/blocking an IP flow), charging, quality of service authorization etc. Making the IP filter fully specified with a complete IP 5-tuple (and not wild-carding part of it as is the case now) allows the network to unequivocally identify the IP flow correctly and thus to apply the intended PCC behaviours.

The sequence shows an example where both networks NW-A and NW-B are 3GPP packet access networks. 3GPP packet access networks use specific procedures to set up packet switched bearers between the UE and the NW. These procedures are described in detail in 3GPP TS 24.008 specification and are not repeated here. In this type of access, the UE and the network may have more than one bearer established concurrently. The different bearers allow for different quality of service properties. The bearer setup may be initiated either by the UE or by the network depending on the selected/supported bearer control mode between the network and the UE. The role of PCC for 3GPP access networks is to bind PCC rules to authorize the usage of these bearers (i.e. authorize quality of service) and bind PCC rules to the bearers correctly to ensure that the authorized IP flows are transported in the correct bearer. However, embodiments of the present invention are applicable also to other access networks which do not use multiple bearers or explicit bearer set up signalling procedures.

Depending on the bearer control mode, either UE-B or NW-B initiates the setup of the bearer or bearers required to transport the IP flows of the negotiated media components. The IP filters are also used in the bearer control signalling in the Traffic Flow Templates (TFTs). The sequence shows an example where separate bearers are established for the two negotiated media components.

UE-B and NW-B establish a bearer of best effort quality of service for the chat media. A TFT with complete IP 5-tuple information for an IP flow is now exchanged between the UE and the network (only downlink TFT is shown in the figure but an uplink TFT can also be used). Since the IP filter information in the TFT for can now be fully specified, including the TCP client source port port-A1 , the two (and only these two particular) IP flows carrying the chat media are unequivocally allocated to this bearer. The PCC rule B1 created for the chat media component is also bound to the bearer at NW-B. Since the complete filter information is used there can now be no confusion which PCC rule should be bound to which bearer.

Similarly, UE-B and NW-B establish also a bearer of high, real time quality of service for the game controls media. Also here the fully specified IP filters can be used in the TFT, but this time including the TCP client source port port-A2. PCC rule B2 is bound to this bearer.

Similarly, two bearers are setup between UE-A and NW-A and correct IP flows are allocated to the bearers and correct PCC rules are bound to the bearers.

The act of using by the newly signalled TCP client port information as part of bearer setup procedures is novel. This is illustrated in Figure 5B.

When UE-A then wants to send a TCP packet to UE-B for the chat media, which is an IP packet with IP 5-tuple <source IP address of IP-A, source port port-A1 , destination IP address of IP-B, destination port port-B, and protocol TCP>, the packet will internally match the IP filter the UE has allocated to the best effort bearer. The packet will be sent out in that bearer. When the packet is received at NW-A in that bearer it will match the PCC rule A1 which is bound to the bearer, so that correct policing and charging can be applied by the network according to the rule for the chat media component. When the packet arrives from NW-A in NW-B, the packet will match the PCC rule B1 and because this rule's binding to the best effort bearer, the packet will be sent to UE-B over that bearer. NW-B is also able to perform correct policing and charging according to its PCC rule B1 for the chat media. Similarly, when UE-B sends a TCP packet to UE-A for the chat media, the packet is routed over correct bearers and correct PCC rules are matched in NW-B and NW-A so that correct policing and charging can be achieved.

The same applies for packets exchanged between the UEs for the game controls media. This is illustrated in Figure 5C.

It will be appreciated that operation of one or more of the above-described components can be controlled by a program operating on the device or apparatus. Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website. The appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.

Claims

CLAIMS:

1. A method for use by a first node of an IP network as part of an offer/answer negotiation relating to an IP connection to be established by the first node to a second node of the network, the method comprising providing to the second node and/or an intermediate node information relating to an IP port from which the first node intends to establish the IP connection, the information enabling the second node and/or the intermediate node subsequently to distinguish different IP flows between the first and second nodes.

2. A method as claimed in claim 1 , comprising including the port information in an offer message sent from the first node to the second node as part of the offer/answer negotiation.

3. A method as claimed in claim 1 , comprising including the port information in an answer message sent from the first node to the second node as part of the offer/answer negotiation.

4. A method for use in an IP network in which an offer/answer negotiation is performed relating to an IP connection to be established by a first node of the network to a second node of the network, the method comprising receiving from the first node, as part of the negotiation, information relating to an IP port from which the first node intends to establish the IP connection, and using the information subsequently to distinguish different IP flows between the first and second nodes.

5. A method as claimed in claim 4, wherein the method is performed at a node intermediate the first and second nodes.

6. A method as claimed in any preceding claim, wherein the intermediate node is located in an access network serving the first or second node.

7. A method as claimed in claim 4, 5 or 6, comprising applying different policies to the different respective IP flows so distinguished.

8. A method as claimed in claim 7, comprising applying different traffic control policies to the different respective IP flows so distinguished.

9. A method as claimed in claim 7 or 8, comprising applying different quality of service policies to the different respective IP flows so distinguished.

10. A method as claimed in claim 7, 8 or 9, comprising applying different charging policies to the different respective IP flows so distinguished.

1 1. A method as claimed in any one of claims 4 to 10, comprising using the port information to derive or update a plurality of filters, each filter being associated with at least one policy to be applied to an IP flow matching the filter.

12. A method as claimed in claim 1 1 , comprising determining which port of the first node is associated with the IP flow, and selecting as a match at least one of the filters in dependence upon the determination.

13. A method as claimed in claim 11 or 12, wherein each of the filters specifies an IP port of the first node, an IP port of the second node, and respective IP addresses of the first and second nodes.

14. A method as claimed in any one of claims 4 to 13, comprising setting up a plurality of bearers, for carrying the IP flows, in dependence upon the port information.

15. A method as claimed in claim 14, when dependent on claim 1 1 , wherein each filter is associated with a respective one of the bearers.

16. A method as claimed in any preceding claim, wherein the network is a Universal Mobile Telecommunications System network, and wherein the port information is used by a Policy and Charging Control function of the network to distinguish the different IP flows.

17. A method as claimed in claim 16, when dependent on claim 11 , wherein the filters comprise Policy and Charging Control rules.

18. A method as claimed in any preceding claim, wherein the offer/answer negotiation is a negotiation of media components for the connection, with the port for which information is provided being associated with a respective one of the negotiated media components.

19. A method as claimed in claim 18, wherein each of the IP flows is associated with one of the negotiated media components, and hence also with one of the ports of the first node.

20. A method as claimed in any preceding claim, wherein the offer/answer negotiation is performed according to the Session Description Protocol, SDP.

21. A method as claimed in claim 20, wherein the port information is carried in an SDP attribute of an offer or answer message.

22. A method as claimed in claim 19, wherein the port information is carried in the m line of the SDP and an indication that the port information in the m line is valid is carried in an SDP attribute of an offer or answer message.

23. A method as claimed in any preceding claim, wherein the connection comprises a Transmission Control Protocol, TCP, connection.

24. An apparatus for use as or in a first node of an IP network, comprising means for performing an offer/answer negotiation relating to an IP connection to be established by the first node to a second node of the network, as a part of which negotiation information is provided to the second node and/or an intermediate node relating to an IP port from which the first node intends to establish the IP connection, the information enabling the second node and/or the intermediate node subsequently to distinguish different IP flows between the first and second nodes.

25. An apparatus for use in an IP network in which an offer/answer negotiation is performed relating to an IP connection to be established by a first node of the network to a second node of the network, the apparatus comprising means for receiving from the first node, as part of the negotiation, information relating to an IP port from which the first node intends to establish the IP connection, and means for using the information subsequently to distinguish different IP flows between the first and second nodes.

26. A program for controlling an apparatus to perform a method as claimed in any one of claims 1 to 23.

27. A storage medium containing a program as claimed in claim 26.