MXPA01006861A - TRANSPORTING QoS MAPPING INFORMATION IN A PACKET RADIO NETWORK - Google Patents

Abstract

A method and a GGSN support node for sending data packets to a mobile station (MS) in a mobile communications system (13) from an external communication system (11, 12). The GGSN receives data packets from the external communication system (11, 12) in a first plurality of data flows which it maps to a second plurality of data flows in the mobile communications system (13). It establishes at least one filter (FI) for controlling the mapping and associates the filter (FI) with the mobile station. It also maps at least one of the data flows on the basis of the filter (FI) and configures the filter (FI) on the basis of information (6-1, 7-1) which preferably originates from the mobile station (MS).

Description

TRANSPORTATION OF PE INFORMATION CORRELATION OF QOS IN A PACKAGE RADIOTRANSMISSION NETWORK BACKGROUND OF THE INVENTION The invention relates to methods and equipment for controlling Quality of Service (QoS) in mobile communication systems that have a data transmission capacity per packet. Specifically, the invention relates to sending data packets based on the QoS correlation information and transport of the QoS correlation information between several nodes in a mobile communication system. For Phase 2 of GPRS (General Packet Radio Service) and UMTS (Universal Mobile Telecommunications System) systems, a much broader QoS support is required. For that purpose, the information related to QoS must be maintained in the network limit elements, such as in a mobile station (MS) and a GGSN (GPRS Support Node of access path). It is currently not possible to transform the information necessary to carry out the translation and correlation functions of QoS between the mechanisms of external network QoS and the mobile network specific QoS mechanisms. This means that only the static QoS translation can be carried out via the mobile network boundary nodes. To provide different QoS values for different applications (such as real-time multimedia and non real time, file transmission, non-priority email transfer, etc.), means are needed to maintain constant information in the mobile station and the nodes of GGSN. There are no known solutions for this problem for GPRS / UMTS networks. For the Internet, there are mechanisms available that can be used to transport QoS or specific flow information. However, this information is interpreted by each node along the end-to-end transmission path and not only by endpoints (the MS and the GGSN).

BRIEF DESCRIPTION OF THE INVENTION An object of the invention is to provide a mechanism to allow more dynamic QoS provisioning for individual applications. This object is achieved with a method and equipment that are characterized by what is described in the appended independent claims. Preferred embodiments of the invention are described in the appended dependent claims. The invention is based on a vision that the QoS correlation information must be transferred between the limits of the GPRS / UMTS network. In other words, the invention provides a mechanism to correlate a multiple downlink (terminated mobile station) IP streams (IP stream 1, ... IP stream n) with different QoS needs for GPRS streams (or UMTS) ). The previous flows are defined by contexts of PDP (Data Protocol per Package) (PDP1 ... PDPm) or QoS profiles (QoSp1 .... QoSm) within a profile covering the needs. The basic idea of the invention is that for at least some data streams (such as real-time applications), the correlation that is made at the boundary node (ie the GGSN) is based on a filter which is configured (by selection or modification) from a user and / or terminal. Said filter can be implemented as a set of predetermined parameters and / or conditions that are used to identify packets or data flows. A filter for a mobile station must comprise at least the IP address of the mobile station in question. The IP address of the mobile station of the PDP context record is known, and does not have to be transmitted in the filter specification between the MS and the GGSN. (In exceptional cases a mobile station may have more than one IP address). In addition, the filter can comprise any data that can be used to identify data packets that require a certain QoS and which should therefore be multiplexed over certain PDP contexts, such as an origin address, an RSVP flow identifier, a port number (for example, the TCP or UDP port number used), a higher layer protocol (for example, UDP, RTP, etc.), a type of service (IPv4), a type of connection (IPv6) and / or a traffic class field (IPv6). This filter may also comprise the IP address space to provide the packets coming from a corporate network (eg, an intranet) with a higher QoS than the packets coming from the common Internet. The filter according to the invention is used to define the characteristics of the IP flows that are to be correlated to the GPRS or UMTS flow in question. The terminal can control the filter by identifying the filter parameters in an information element that can be included for example in a PDP context activation or a PDP context-modification message. The filter can also be defined and / or redefined together with the modification or activation of the QoS profile. According to the preferred embodiment of the present invention, an implicit QoS class is defined. Data flows that do not conform to any defined filter are mapped to this implicit QoS class. The problem solved by the invention is relevant in phase 2 of GPRS and its future evolution, such as UMTS. According to one modality, the QoS information for the context / profile is included in the QoS profile information elements as in phase 1 of GPRS. The information on filtering and correlation can be transferred in the information element in the "protocol configuration options", the vendor-specific options, or in a new information element introduced and intended for this purpose. This information can include destination or source IP addresses, TCP and UDP port numbers used, information about the upper layer protocol, probably the Index of Security Parameters (if IPSEC is used), differentiated service parameters, and RSVP filters. and flow specifications or some other identifier or parameter in the packets. A different quality of service (QoS) profile may be required for each PDP address. For example, some PDP addresses can be associated with email that can tolerate long response times. Other applications, such as interactive applications, can not tolerate delay, and demand a very high level of performance. These different requirements are reflected in the QoS profile. If a QoS requirement is beyond the capabilities of the PLMN (Public Mobile Network Installed on Earth), the PLMN negotiates the QoS profile as closely as possible to the required QoS profile. The MS accepts the negotiated QoS profile or disables the PDP context. An advantage of the invention is that the network elements (such as the SGSN nodes and the base station subsystem) of a packet radio transmission network do not have to interpret all the QoS mechanisms of the external networks (IP, X). .25 etc.). In contrast, the mapping can be configured at one end of the mobile station, and this configuration is transported to another limit node (i.e. the GGSN) of the packet radio transmission network. In this way, the entire packet radio transmission network does not have to be updated to support all the new QoS mechanisms.

The mechanism according to the invention is very generic. In other words, it is applicable to a wide variety of situations and configurations. This allows flexible access, configuration and use of the filter information in the GGSN database. The use of the filter according to the invention is completely specific for a case and an operator. The MS subscriber is provided with the means to indicate to the access node at the limit of the fixed / mobile network how the different applications, connections, flows, or other attributes should be treated and which QoS should be used within the network of GPRS / UMTS to transport the associated packages. Preferably, the GGSN must also maintain the specific information on flow / QoS / application. Even another advantage is that the flow / QoS specification transferred according to the invention (i.e. in the QoS profile setting procedure or in PDP context activation or a dedicated message) is very flexible. You can include destination and source IP addresses, TCP and UDP port numbers used, information about the upper layer protocol, possibly use an index of security parameters in the case of IPSEC, differentiated service parameters, and filters. RSVP and flow specifications, all of these used to identify external applications, uses and flows that must be correlated for particular internal QoS contexts or classes. One advantage of the flexibility is that a new application does not necessarily retain a new flow in the packet radio transmission network. On the contrary, the invention allows a flexible reuse of existing flows in an efficient manner. Alternatively, the information can be configured in a more static manner, in which case the dynamic change of the attributes is not possible. In this case, the operator configures the static conditions and the translation of an external QoS to an internal QoS, for example, based on the TCP / UDP port numbers used. Even another option is not to provide any end-to-end QoS and QoS correlation function.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will be described in more detail by means of the preferred embodiments with reference to the accompanying drawings in which: Figure 1 shows the design of a known GPRS network; Figure 2 shows a known GPRS transmission plane; Figure 3 shows the interconnection of the different network elements; Figure 4 shows a GGSN comprising the filter according to the invention; Figure 5 shows the use of the filter according to the invention; Figures 6 and 7 show the filter information that is conveyed in a context modification or activation procedure, respectively; and Figures 8 and 9 show two different modalities for configuring filter information in dedicated messages.

DETAILED DESCRIPTION OF THE INVENTION As shown in Figures 1 and 2, the present invention can be used with any mobile communication system having a data transmission capacity per packet. The term "packet data protocol" (PDP) or "PDP context" as used herein should be understood as referring generally to any state in a mobile station and in at least one network element or functionality, whose state it provides a data packet transmission path or a tunnel with a specific group of parameters through the mobile communications network. The term "node" as used herein should be understood as referring generally to any element or network functionality that handles the data packets transferred through the PDP channel. The invention can preferably be used especially to provide a general service of radio transmission of GPRS packets in the Paneuropeo GSM mobile digital communication system or in corresponding mobile communication systems, such as DCS1800 (also known as GSM 1800) and PCS (Personal Communication System). In the following, the preferred embodiments of the invention will be described by means of a GPRS packet radio network formed by the GPRS service and the GSM system without limiting the invention to this packet radio transmission system. The invention is equally applicable to third generation mobile networks, such as UMTS. In this case, the GSM radio transmission interface will be replaced with a UMTS radio transmission interface, as shown in Figure 2. Figure 3 illustrates the interconnection of the different elements of the network. After these modifications, a parameter-level mapping between differentiated services and RSVP can be provided on the Internet and in a GPRS as shown below, for example: Priority information on the Internet correlates to a service priority in the GPRS. An indication of the real-time requirements against non-real time on the Internet is correlated to a class of delay and / or reliability information in the GPRS: at least two types of delay are needed, but it is also possible to correlate traffic types more precisely to several delay classes. Reliability information can be used to indicate the reliability requirements of each application in the form of one of at least two reliability classes. If reliable transmission is needed (retransmissions, checksums and / or TCP), the profile related to the data packets indicates the reliability class 1. If a reliable delivery is needed at the radio transmission interface, but the UDP at the GPRS main network is sufficient, the profile related to the data packets indicates reliability class 2. Depending on the requirements, the profile related to the data packets can alternatively indicate reliability class 3, 4 or 5. The reliability classes 4 and 5 are used for real-time traffic. An additional optional feature of the present invention is a correlation of the QoS parameters used in the mobile communication network to those used in a user application in the mobile packet data terminal or those used in the external communication system, and vice versa . The MS, knowing the requirements of the applications, determines the values of the corresponding QoS profile, establishes a new PDP context for these packets and indicates to the GGSN how to recognize the packets belonging to this context. Next, two examples of the correlation will be given. Example 1 (given as an example of how the MS can decide which GPRS parameter values it chooses for the context). The Simple Integrated Media Access (SIMA) is a new simple approach presented as a draft of the Internet by K. Kilkki, Nokia Research Center, in June 1997. The drafts of the Internet are working documents of the Internet Engineering Task Force (Internet Engineering Works Force) (IETF), its areas and working groups. The SIMA is used as an example of an Internet QoS scheme since it is able to provide a uniform service concept for different needs of file transfer applications using the TCP / IP protocol with a broad delay and loss requirements. packages to real-time applications with strict quality and availability requirements. According to the SIMA concept, each user defines only two themes before the connection: a nominal bit rate (NBR) and a selection between real-time and non-real-time service classes. The NBR can have eight values from 0 to 7. The mapping of parameters from SIMA to GPRS and vice versa can be as shown below, for example: Real time bit / non real time: if this bit indicates real time requirements, correlates with class 1 GPRS delay, or otherwise correlated with delay class 4. However, delay class 3 can be used for non-real time services in case there is a special way to indicate better effort traffic, for example this bit does not always need to be present, or a more precise definition is used to differentiate Real-time traffic, not real time and better effort. A lower reliability class value than that assigned to non-real time traffic in a GPRS can be assigned to real-time traffic. Generally, reliability classes 1, 2 and 3 are commonly used for non-real time traffic and classes 3, 4 and 5 for real-time traffic in a GPRS. For non-real time traffic, the higher the NBR, the lower the reliability class value appropriate for the transmission.

Different names can be chosen, such as priority or Nominal Speed of Bit Transfer and traffic type for the parameters. The QoS profile can include all existing parameters (service priority, reliability class, delay class, average bit rate and peak bit rate). Alternatively, only some of the parameters may be included, such as the average and peak bit rate. The QoS profile can also include parameters of a maximum burst size to facilitate the buffer placement procedure. The programming of QoS in GPRS network elements (for example, in an SGSN and a GGSN) is based on the delay class. This may require at least 2 buffers: one for real-time packets (this buffer must be much smaller) and another for non-real-time packets. Real-time traffic should always be sent before non-real time traffic. The service priority defines the order in which packets can be released in case of network congestion. Example 2 (describes how to choose QoS values and establish a special profile to maintain a given point of code of differentiated services to provide the appropriate QoS profile values and a differentiated services code point value as filter information to configure the filter). Correlating a service type byte (ToS) in the headers of the IP packet (Package Data Units) PDUs to the GPRS attributes. The ToS octet in an IP header is not currently used much. Its original purpose was to include traffic type information and specify what type of service is required in the delivery of packages. Since the ToS octet is not currently in use, it is possible to redefine the bits in that octet for purposes of the present invention. A definition of the ToS octet is given in RFC 791. ToS 0 to 2 bits are preferred, bits of 3 to 5 give the ToS required by the packet (for example, the level of delay, performance, and reliability required). ), and bits 6 through 7 are reserved for future use. The RFC 1349 document extends to the ToS field by a bit (taken from the "reserved for the future" bits). In this way, 4 bits can be used to indicate a ToS. The correlation between the priority bits (from 0 to 2 in ToS) and the GPRS service priority can be as shown below: There are three different ways to perform the correlation between the traffic type information (ie, the ToS field in the ToS octet) and the GPRS delay class: If only bit 3 in the ToS field is used to indicate the delay requirements in the IP header: the value 0 of bit 2 correlates with the delay class of GPRS 1 or 2, the value 1 of bit 2 correlates with delay class 4 (best effort). If the entire ToS field in ToS is used to indicate the delay requirements, ie 4 bits (bits 3 to 6) are available for this purpose, a correlation could be: bit value 1000 correlated with delay class 1 of GPRS (that is to the value of bit 000), bit value 0100 to delay class 2 (ie to the value 001), the values of ToS 0010 and 0001 to delay class 3 of GPRS (ie to the value 010) and the value ToS 0000 to delay class 4 of GPRS (ie, to the value 011). Another way of correlating the IP ToS bits to the GPRS delay classes would be: 11x to delay class 1, 10x to the delay class 2, 01 x to delay class 3 and OOx to delay class 4. In this case, x means that there may be one or more additional bits used for ToS, but it has no impact on the procedure of selecting the delay class of GPRS. If more delay classes are defined for the GPRS later, the correlation can also take into account those additional bits. Currently there is also a bit in the IP ToS field specifying the desired level of reliability. If this bit is still available in the futureFor example, if the first choice is taken, this bit could carry reliability information and could be correlated with the GPRS reliability class in the following way: a value 0 in bit 5 within the ToS octet is correlated with the class of 000 reliability (signed reliability class) and a value of 1 correlates with reliability class 001 (defining the most reliable service). However, the use of that bit can be very vague since the GPRS also defines many other levels of reliability and this can not be expressed using only one bit. In accordance with a preferred embodiment of the invention, an implicit QoS class is defined, and the data flows that do not belong to any of the correlation criteria defined by the filter or filters correlates with the implicit QoS class. The correlation described in example 2 can be applied in a more or less similar way to IPv6. The name of the appropriate field is traffic class instead of ToS. Figure 3 illustrates the operation of a GPRS mobile station and the GPRS network elements, as well as the integration of external network QoS concepts. The MS or the software in the TE terminal equipment (for example in a laptop computer) provides the correlation of the external network QoS requirements to the GPRS QoS mechanisms. The TE could, for example, provide QoS management functions through an application programming interface (API). The application-level software can insert QoS information or a profile tag into the data packets, for example within the IP header itself, or it can indicate the correct flow to which the packet belongs to use other suitable means. RSVP can also be used to transport the necessary information by means of the appropriate correlation layers to smaller layers. The software of the MS can, alternatively, decide the QoS profile based for example on the I P addresses of origin and destination used, or on the port numbers of origin and destination or in other information configured to the MS. For Mobile Originated Data (MO), the programming data packets of the MS based on the QoS information received from the application or GPRS protocol sequence in the terminal equipment. The MS programs the MO packets according to their delay class. In the SNDC layer, the MS selects the appropriate SAP (Service Access Points) from LLC indicated by the SGSN during the activation or modification of the PDP context. Figure 4 illustrates a GGSN comprising the filter according to the invention. The GGSN receives data packets terminated by the multi-source MS that are collectively referred to as SP service providers. Figure 4 shows three typical service providers: an ISP Internet service provider to provide access to the Internet; a CNS Corporate Network Server to provide access to closed areas of the Internet, commonly called intranets and strangers; and CP Content Providers to provide access to various entertainment and news services, such as demand video, etc. The GGSN comprises an ST programmer / translator. As its name implies, it programs the transmission of packets on a network load basis, packet priority, arrival time, etc. The programming part of the ST is well known to the person skilled in the art. The translator part of the ST uses the filter Fl according to the invention. Correlates data packets of the IP networks (parts 11 and 12 in figure 1) to the packet radio transmission network (part 13 in figure 1). The invention provides a solution for a situation in which several applications and data streams share an IP address but require different values of QoS. Figure 5 illustrates the use of a filter Fl according to the invention in the GGSN. In steps 5 to 1 the GGSN receives a data packet addressed to a certain mobile station MS. The GGSN reads the IP address of the MS from the corresponding protocol header and uses the filter Fl to determine the context of the corresponding PDP or QoS profile. The IMSI of the MS can be determined with the I P addresses of the packets destinations. In steps 5 to 2 the GGSN obtains the corresponding Tunnel Identifier TID. Next in steps 5 to 3, the GGSN sends the data packet through the SGSN to the MS through that particular context that is associated with a QoS suitable for this packet.

Figure 6 shows how a mobile station can configure the correlation of QoS and interconnection actions by means of a context activation procedure according to the invention. In steps 6 to 1, the MS sends to the SGSN an active PDP context request comprising an NSAPI, a PDP type, a PDP address, an Access Point Name, the required QoS, a filter specification and PDP configuration options. (To understand the present invention, the important parameters are the filter and the QoS information). The MS may use the PDP address to indicate whether it requires the use of a static or dynamic PDP address. In the latter case, the MS may leave the PDP address empty. The MS may use the Access Point Name to select a reference point to a certain external network. The Access Point Name is a logical name that refers to the external packet data network to which the subscriber wishes to connect. The required QoS indicates the desired QoS profile. The filter specification indicates which external data packets are associated with a particular PDP context. The packets indicated by the filter conditions of this filter can be considered as belonging to this particular PDP context. The PDP Configuration Options can be used to request the optional PDP parameters from the GGSN (see GSM 09.60 combination). The PDP Configuration Options are sent transparently through the SGSN. Using a dynamic configuration and dynamic PDP addresses involves the problem of how to ensure that the activation of the context affects the correct GGSN, and how the GGSN knows whether to activate a new context with the same IP address or a different address. Three solutions can be found for this problem: 1. Use an Access Point Name that points to a certain GGSN node and indicates that another context is needed, and use the same IP address. 2. Add an indication (such as a new information element) to the context activation request, indicating to the GGSN (and the SGSN) that another context is needed. This context has the same IP address as the previous one. In this case the SGSN selects the same GGSN as the previous context of that type of PDP. 3. Add the desired IP and PDP addresses for context to the context activation request message. This PDP / IP address can be given to other previous contexts, that is, to a dynamic address. In this case, the SGSN selects the GGSN that is driving that particular address. The security functions can be carried out in steps 6 to 2, although they are not relevant to understanding the invention. In steps 6 to 3, the SGSN validates the 6 to 1 request. The SGSN creates a TID Tunnel Identifier for the required PDP context by combining the IMSI stored in the MM context with the NSAPI received from the MS. The SGSN can restrict the QoS attributes required by considering its capabilities, the current load, and the subscribed QoS profile.

Then, in steps 6 to 3 the SGSN sends the message "create PDP context request" (comprising a PDP type, a PDP address, an Access Point Name, negotiated QoS profiles, desired filter, the TID , and PDP configuration options) to the GGSN. The GGSN can also restrict the attributes of QoS required considering its capabilities, and the current load. If the MS requires a dynamic address, then the SGSN allows a GGSN to assign the dynamic address. The SGSN can restrict the QoS attributes required given its capabilities, the current load, and the subscribed QoS profile. The SGSN sends the message "create the PDP context request" (PDP type, PDP address, Access Point Name, negotiated QoS, filter specification, TID, selection mode, PDP configuration options) to the GGSN affected. The Access Point Name is the APN Network Identifier of the selected APN. The PDP address should be emptied if a dynamic address is required. The GGSN can use the Access Point Name to find an external network. The selection mode indicates whether a subscribed APN was selected, or if an unsubscribed APN sent by the MS or a non-subscribed APN chosen by SGSN was selected. The GGSN can use the selection mode when it decides to accept or reject the activation of the PDP context. For example, if an APN requires subscription, then the GGSN is configured to accept only PDP context activation that requires a subscribed APN as indicated by the SGSN with the selection mode. The GGSN creates a new entry in its PDP context table and generates a load Id.

The new entry allows the GGSN to route the PDP PDUs between the SGSN and the external PDP network, and start loading. The GGSN can also restrict the negotiated QoS considering its capabilities and the current load. The GGSN will maintain information for QoS correlation and multiplexed input information packets from the external network over the active PDP contexts according to the filtering conditions defined in the GGSN. For outbound packets, a certain external QoS may be associated with the packets of a particular PDP context. The GGSN then returns to the "create PDP context response" message (TID, PDP address, BB protocol, Redistribution Required, PDP Configuration Options, negotiated QoS, load Id, cause) to the SGSN. The PDP address is included if the GGSN was placed in one. The BB protocol indicates whether the TCP or UPD should be used to transport user data in the main network between the SGSN and the GGSN. The Required Redistribution indicates whether the SGSN should redistribute the N-PDUs before delivering the N-PDUs to the MS. The PDP configuration options contain optional PDP parameters that the GGSN can transfer to the MS. These optional PDP parameters may be required by the MS in the active PDP context request message, or may be sent without being requested by the GGSN. The PDP configuration options are sent transparently through the SGSN. The messages "create PDP context" are sent in the main GPRS network. If the negotiated QoS that is received from the SGSN is not compatible with the PDP context that is activated (for example, the reliability class is insufficient to support the type of PDP), then the GGSN rejects the message "create context request of PDP ". Supported QoS profiles can be configured using the GGSN operator. In steps 6 through 4, the GGSN sends the response to the "create PDP context response" message (comprising a TDl, a PDP address, the negotiated QoS profiles, and the PDP Configuration Options) to the SGSN. The SGSN inserts the NSAPI with the address of GGSN in the context of PDP. If the MS has requested a dynamic address, the PDP address received from the GGSN is inserted in the PDP context. The SGSN selects a radio transmission priority based on the negotiated QoS, and returns the message "activate PDP context acceptance" (type of PDP, PDP address, IT, negotiated QoS, radio priority, PDP configuration options) to the MS. The SGSN is now able to route the PDP PDUs between the GGSN and the MS, and start loading. Then, in steps 6 to 5, the SGSN selects a radio transmission priority level that is based on each negotiated QoS profile, and returns the message "activate the PDP context acceptance" (comprising a PDP type, an address of PDP, an NSAPI, the negotiated QoS profiles, a radio transmission priority level, and an SAPI for each QoS profile, the filter and PDP configuration options) to the MS. Now the SGSN is capable of routing the PDP PDUs between the GGSN and the MS. The SAPI indicates that the QoS profile uses each SAPI.

Figure 7 shows a context modification procedure, in steps 7 to 1 the MS sends the message "encode PDP context request" to the SGSN. In steps 7 to 3 the SGSN sends a PDP context request to the GGSN. Both requests comprise the filter with modified parameters. The filter indicates which external data packets are associated with a particular PDP context. The packages indicated by the filtering conditions should be interpreted as belonging to this particular PDP context and should be provided with the QoS negotiated by the context. The message "update PDP context request" is used to add, modify or cancel a QoS profile from a PDP context. If the GGSN receives a negotiated QoS from the SGSN that is compatible with the PDP context to be modified (for example, the reliability class is insufficient to support the PDP type), the GGSN rejects the request. The compatible QoS profiles are configured by the GGSN operator. The GGSN can again restrict the QoS attributes required considering its capabilities, and the current load. The GGSN stores the negotiated QoS values. The GGSN reviews the QoS correlation information to conform to the new filter specification and the negotiated QoS profile (included in the request message). In steps 7 to 4 and 7 to 5 a positive response is returned to the MS. The basic versions of the message 7 to 1 to 7 to 5 are known from phase 2 of the GPRS. According to the invention, the messages 7 to 1 and 7 to 3 are modified to send the desired filtering parameters (and messages 7). to 4 and 7 to 5 are modified to return an appropriate confirmation). According to another embodiment of the invention, the filter function in a first direction (e.g., downlink) can be modified using information included in the packets sent in the second address (e.g., uplink). This modality does not require extra signaling. According to this modality by way of example, the following traffic classes are defined (RT = Real Time, NRT = Non-Real Time): Sliding and conversational classes are traffic classes oriented to the real time for which resources are reserved. Interactive and non-priority classes are the best effort classes, which do not have resources reserved. For these classes, the allocation of the GPRS type resource can be used, that is, the MS sends the request requests for the radio transmission of demand. For the real-time classes, ie the sliding and conversational classes, the method presented above is very efficient, ie the filter formation is carried in PDP context operations to the GGSN so that the GGSN can correlate packets of IP input to the correct QoS class. However, with non-priority and interactive classes a large amount of signaling is involved, which in some cases may not be accepted. An example of such a situation is a request sent to DNS Domain Name Server (not shown), in the case where the network flow may consist of only two packets. In this example, the interactive class is selected as the implicit QoS class. This means that if there is no information about the QoS requirement of an input stream, or the flow information does not match any of the filter conditions, the interactive class will be selected. In addition, flows belonging to the non-priority class can be identified through the GGSN "on the fly". This means that when the GGSN obtains an MS packet in the non-priority class, it will take note of the flow identification information, and modify the filter characteristics associated with the non-priority class, to correlate the downlink flow corresponding to the flow in question to the non-priority class. When a packet goes in the downlink direction the GGSN checks the information about flow identification associated with the non-priority class. If the flow filter information associated with the non-priority class matches the header information of the received IP packet, then the packet is directed to a non-priority class. The flow information related to the non-priority class can be handled as follows. The MS has knowledge about the flows that must be carried out using the non-priority class. The user can configure this flow correlation to the non-priority class. For example, the user can configure the file transfer to use the non-priority class by using a suitable configuration application. Alternatively, the information can be obtained for example from some external information about QoS (for example information about Internet QoS). In other words, the MS has filter criteria for flows that are to be correlated towards the non-priority class. An essential feature of this mode is that the MS has knowledge about which flows should be directed towards the non-priority class, and sends these packets to the corresponding connection. When the GGSN receives packets from the MS, it knows that the class of QoS packets are associated. When the GGSN obtains a packet in the non-priority class it verifies if it already obtained an entry for that flow in a list (not shown) which contains information about the flow of all the flows belonging to the non-priority class. If there is no entry for the flow in the list, the GGSN modifies the filter used when the downstream connection flows are correlated to the non-priority class since the downlink flow corresponds to the uplink flow the received packet belonging to will correlate towards the non-priority class. This can be done by including the information on uplink packet flow identification in the list of flow information in which the downlink packets in the non-priority class are mapped. A) Yes, the flows belonging to the non-priority class are identified in the GGSN "on the fly". When the GGSN receives a packet from the Internet or from any external network, it verifies the information about the filter associated with the conversational, sliding and non-priority classes. If the GGSN finds that the characteristics of the packet are adjusted to the relevant filter conditions, it advances the packet to the corresponding QoS class. If there is no entry for the particular flow, then the packet is advanced to the interactive class, which is the implicit class. This modality dramatically decreases the need for signaling because the interactive class will be used very frequently by the QoS class. There are many cases in which I P packets do not really form a flow, although there is only one or a few IP packets that are in uplink and few packets that go down as a response. A DNS claim is a good example of this type of behavior. The signaling of PDP context modification in these cases would cause a relatively high amount of signaling that can be avoided using this mode. Instead, only the activation of the initial PDP context is necessary to obtain an IP address for the MS. A residual problem in the approach shown in Figures 6 and 7 is that it is not very clear how to add filter information in addition to the filter for the PDP context or modify the existing filters without first removing all existing filters and then returning to send all information about filter, including changes. In other words, if PDP context activation and modification procedure are always being used, all filtering information has to be included in the message even if only a single parameter value has to be changed. Adding a new filter requires sending all the filters at the same time. Therefore, Figures 8 and 9 illustrate a preferred embodiment of the invention that helps solve this residual problem. It is proposed that at least there should be a dedicated message to configure the filter information. In this context, "dedicated" means that the message does not carry information about the PDP context. A filter identification number must be defined to identify a certain filter of a certain PDP context. This filter identification number may consist of a TID tunnel identifier, which indicates the user and PDP context, and an FN filter number. The latter may be a sequence number selected by the MS when a filter is created. In summary, filters can be configured using the following procedure: 1.- One or more filters associated with the PDP context activation procedure can be created (see figure 6). In this case one or more filter information elements are included in the PDP context activation messages, each filter element is identified by a different filter number (1, 2, 3 etc.). 2.- The filters associated with the PDP context modification procedure can be modified (see figure 7). In this case, one or more filter parameters of one or more filters can be modified by adding filter information elements in the PDP context modification request. Independent filters are identified by a filter number. You can also create new filters using this procedure. In this case a new filter information element (for example a new filter number previously used) is included in the modification request message. 3.- New filter operations (one or more dedicated messages). Three operations between the MS and the GGSN are proposed to configure the filters: 3.1 Create a filter: This message carries information about TID, as well as the new filter element and a new filter number. The GGSN creates a new filter according to the content of the message. 3.2 Modify a filter: This message carries information about TID as well as a new filter element replaces the old one and a filter number identifies the particular filter that is to be replaced. The GGSN replaces the filter attributes of the indicated filter with the new one. 3.3 Delete a filter: This message carries information about TID, as well as the filter number of the filter to be deleted. The GGSN eliminates that particular filter. It should be noted that operations 3.1 to 3.3 can be combined to use only one or two different message types, although three different messages can also be defined (one for each operation). The defined messages can be GTP messages in which case the new GTP messages must be defined (in other words, new message identifiers in GTP). In this case, the TID information is automatically included in the GTP packet headers and this does not have to be a separate information element in the message. Alternatively, a new protocol can be defined for filter operations between the MS and the GGSN, in which case the SGSN could be completely transparent for these messages. Figure 8 shows a first mode of the new operations of filter 3.1 to 3.3. In steps 8 to 0 a PDP context is activated for the MS. The details of this operation have been underlined together with the previous figures. In steps 8 to 1 the MS sends the message "create filter" to the SGSN. This message has as parameters the TID tunnel identifier (which specifies the PDP context) and an FN filter number (which specifies a certain filter within the PDP context). Naturally, the message "create filter" must also include the characteristics of the filter. In steps 8 to 2 the message is retransmitted from the SGSN to the GGSN. Steps 8 to 3 and 8 to 4 are the corresponding confirmations. In steps 8 to 5 the data transmission takes place from / to the MS. Steps 8 to 6 to 8 to 9 correspond to steps 8 to 1 to 8 to 4, except that in the last steps the MS (or an application that is running) modifies an existing filter by sending a message "" modify filter "In steps 8 to 11 to 8 to 14 a filter, which will no longer be needed, is deleted by sending a message" delete filter. "The modality shown in Figure 8 is based on the existing protocols. MS and SGSN can for example be session management messages and messages between the SGSN and the GGSN can be for example GTP messages As can be seen, negotiating a filter between an MS and a GGSN is unnecessarily complex because it does not There are predefined protocols between the MS and the GGSN For clarity questions, the messages 8 to 1, 8 to 6 and 8 to 11 have been shown as three separate messages, alternatively, all these operations can use only one message, for example "configure filter", which includes a meter such as 1 = create, 2 = modify, 3 = delete. Figure 9 shows an alternative mode where there is a protocol layer between the MS and the GGSN, and SGSN is a transparent node that does not interpret the message in any way. The modality of the different modalities shown in figures 8 and 9 provide a very flexible scheme in which independent filters can be added (for example specific applications) and also modify dynamically using special filter operations. A special filter identification number is used to identify the independent filters. The description illustrates only the preferred embodiments of the invention. However, the invention is not limited to these examples although it may vary within the scope of the appended claims. For example, it is not necessary for the receiving terminal to be a mobile station although it can be any network element. Likewise, it is not necessary for the MT data packets to originate from the IP network. In contrast, the invention is applicable for example in a call from MS to MS via a GGSN node. In this case the branch of an MS to a GGSN is a first communication subsystem and the branch of the GGSN to the other MS is a second communication subsystem.

Claims (18)

NOVELTY OF THE INVENTION CLAIMS

1. - A method for sending data packets (DP) of a first communication subsystem (11, 12) by a first network element (GGSN) to a second network element (MS) in a second communication subsystem (13); the method consists of the steps: sending the data packet (DP) in a first plurality of data flow in said first communication subsystem (11, 12); correlating said first plurality of data streams to a second plurality of data stream in said second communication subsystem (13); further characterized in that: at least one filter (Fl) is established to control said correlation; at least one filter (Fl) is associated with a data stream within said second plurality; and at least one data stream is correlated on the bases of said filter (Fl).

2 - The method according to claim 1, further characterized in that said filter (Fl) is configured from said second network element (MS).

3. The method according to claim 2, further characterized in that said filter (Fl) is configured in a modification or activation message of the packet data protocol context (6 to 1, 7 to 1).

4. - The method according to claim 3, further characterized in that at least two filters (Fl) are configured in a context modification or activation message in packet data protocols and each filter is identified with a different identifier.

5. The method according to claim 2, further characterized in that it is configured by at least one filter (Fl) in a dedicated message (8 to 1, 8 to 6, 8 to 11, 9 to 1, 9 to 4). , 9 to 7).

6. The method according to claim 2, further characterized in that said filter (Fl) is configured in a message that is transparent to at least some nodes (SGSN) between the first and second network elements (GGSN, MS) .

7. The method according to any of the preceding claims, further characterized in that the first communication system (11, 12) is an Internet protocol network, or an IP re, and the method comprises the assignment of an address of IP that is shared in all data streams within said second plurality.

8. The method according to any of claims 1 to 6, further characterized in that the first communication subsystem (11, 12) is an Internet protocol network, or an IP network, and the method comprises placing an address of IP separately for each data flow within said second plurality.

9. The method according to any of the preceding claims, further characterized in that said second communication subsystem (13) is a packet radio transmission network employing a packet radio transmission protocol, or a PDP protocol, and the step to configure is to send a PDP context activation message (6 to 1, 6 to 3) or a PDP context modification message (7 to 1, 7 to 3).

10. The method according to any of the preceding claims, further characterized in that said association is based on the second address of the network elements (MS), preferably IP subaddress, in said first communication subsystem (11, 12). ).

11. The method according to any of the preceding claims, further characterized in that said association is based on the second identifier of the elements of the network (MS), preferably IMSI or tunnel identifier, in said second communication subsystem (13). ).

12. The method according to any of the preceding claims, further characterized in that the correlation is performed based on said filter (Fl) for the data flows that are sent to the information in real time; and implicit parameters are established for correlation of the remaining data flows.

13. The method according to any of the preceding claims, further characterized by defining a data stream within a second plurality as an implicit data stream, for which all data streams of the first plurality are correlated that do not conform to at least one filter (Fl).

14. The method according to any of the preceding claims, further characterized in that at least one of the data streams is bidirectional having a first address of a first plurality to a second plurality and a second address that is inverse to the first address, and at least one filter (Fl) is modified based on the data packet of the user sent in the second address.

15. The method according to claim 14, characterized in that the access path element (GGSN) that correlates the data streams: receives a data packet (DP) in the second direction of a first data stream within the second plurality; forward the data packet to a second data stream within the first plurality; and modifies at least one filter (Fl) to correlate the second data stream to the first data stream.

16. The method according to any of the preceding claims, further characterized in that at least one data stream within the first plurality opens a tunnel on a data stream within the second plurality, and at least two data flows within of the second plurality have different quality of service characteristics from each other.

17. - The method according to any of the preceding claims, further characterized in that the second network element (MS) is a mobile station.

18. A first network element, preferably a gateway GPRS support node (GGSN), for routing data packets (DP) from a first communication subsystem (11, 12) to a second network element (MS) in a second communication system (13); said first radio transmission element (GGSN) is adapted to: receive the data packets (DP) of said first communication subsystem (11, 12) in a first plurality of data streams; correlating the first plurality of data flows to a second plurality of data streams in said second communication subsystem (13); further characterized in that the first network element (GGSN) is adapted to: establish at least one filter (Fl) to control said correlation; associating at least one filter (Fl) with a data stream within said second plurality; and correlating at least one data stream on the bases of the first filter (Fl). 19.- A digital configuration signal to create (6 to 1, 6 to 3, 8 to 1, 9 to 1) or modify (7 to 1, 7 to 3, 8 to 6, 9 to 4) a protocol context of packet data in a support node (GGSN) for interconnecting a first communication subsystem (11, 12) with a second communication subsystem (13); further characterized in that the configuration signal comprises information that at least partially defines a filter (Fl) to control the data flow correlation of said first communication subsystem to said second communication subsystem (13) via said support node (GGSN) ). 20.- A mobile station for a packet radio transmission network (13), operable to send a digital configuration signal to create (6 to 1, 6 to 3, 8 to 1, 9 to 1) or modify (7 to 1) , 7 to 3, 8 to 6, 9 to 4) a packet data protocol context in a support node (GGSN) for interconnecting an external communication subsystem (11, 12) with said packet radio transmission network (13 ); further characterized in that the configuration signal comprises information that at least partially defines a filter (Fl) to control the correlation of the data flow from the external communication subsystem to the packet radio transmission network (13) via said support node (GGSN) ).