WO2006079586A1 - Paketfilter für datenpakete in uplink-richtung - Google Patents

Paketfilter für datenpakete in uplink-richtung Download PDF

Info

Publication number
WO2006079586A1
WO2006079586A1 PCT/EP2006/050159 EP2006050159W WO2006079586A1 WO 2006079586 A1 WO2006079586 A1 WO 2006079586A1 EP 2006050159 W EP2006050159 W EP 2006050159W WO 2006079586 A1 WO2006079586 A1 WO 2006079586A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet filter
terminal
packet
data
ggsn
Prior art date
Application number
PCT/EP2006/050159
Other languages
English (en)
French (fr)
Inventor
Thomas Belling
Peter Braun
Dorothea Lampe
Mirko Schramm
Original Assignee
Nokia Siemens Networks Gmbh & Co. Kg
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Gmbh & Co. Kg filed Critical Nokia Siemens Networks Gmbh & Co. Kg
Publication of WO2006079586A1 publication Critical patent/WO2006079586A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/12—Flow control between communication endpoints using signalling between network elements

Definitions

  • the invention relates to a method and a terminal for transmitting packet filter data representing at least one packet filter for data packets in the uplink direction between a terminal, a first network unit and a further network unit via a communication network.
  • GPRS General Packet Radio Service
  • 3GPP TS 23.060 for the packet-oriented connection of mobile terminals to a packet-switched communication network (for example an IP network)
  • PDP Packet Data Protocol
  • UE User Equipment
  • GGSN gateway GPRS support node
  • TFTs Traffic Flow Templates
  • U.N- ter a data stream is to be understood here a sequence of data packets with the same sender and recipient address, as well as the same type of user data transported therein.
  • IP / UDP or IP / TCP transport the IP data streams should additionally be controlled by the same UDP or IP address.
  • TCP port numbers should be characterized by sender and receiver.
  • a TFT contains packet filter data representing one or more packet filters.
  • a packet filter enables the identification of one or more data streams and can be defined by the following information: receiver and sender address, receiver and sender port number or range of port numbers, as well as further information on the type of transported user data.
  • TFTs only contain packet filters for data streams in the so-called “downlink” direction, ie from the IP core network to the terminal
  • Packet filters for data streams in the so-called "uplink” direction ie from the terminal to the IP core network, are on the other hand not included because the GGSN does not need it for distributing downlink data streams to PDP contexts.
  • Flow Based Charging standardized in the 3GPP in TS 23.125, TS 29.210 and TS 29.211
  • FBC Fibre Channel Control Protocol
  • SBLP Service Based Local Policy
  • SBLP enables service-dependent authorization of the establishment of PDP contexts via the GPRS mobile network.
  • the set-up initiated by the terminal and the modification of PDP contexts is authorized at the GGSN via the so-called Go interface by the so-called "Policy Decision Function” (PDF) resource decision function, which knows the service currently used by the terminal PDF is being used Informs about these services by a so-called “Application Function” (AF) application function, which exchanges signaling with the terminal for negotiating the service, for example the session initiation used in the so-called "Internet Protocol Multimedia Subsystem” (IMS) of the 3GPP Protocol "(SIP), IETF RFC 3261.
  • the authorization specifies the QoS allowed for the PDP context and the permitted IP data streams.
  • the PDF knows which IP data streams belong to a service.To authorize a PDP context, the PDF must know which one IP data streams are transported in it.
  • the charging rules describe IP data streams, as well as rules for charging them.
  • the CRF selects the charging rules, taking into account the services currently being used by the terminal, from which they are used by
  • AF is informed via the so-called Rx interface.
  • the GGSN signals to the CRF via the Gx interface, passing on the TFT information as already standardized.
  • the solution for SBLP standardized so far in the specification 3GPP TS 29.207, which enables the PDF to detect which IP data streams are transported in PDP contexts, uses the so-called "authorization token” .
  • This token is used for a service session of the PDF is generated on request of the AF and signaled by the AF to the terminal.
  • the terminal uses the token, as well as so-called "Flow Identification”.
  • the flow identifiers are additional indices indicating IP data streams within the service
  • authorization tokens and Flow Identifiers are collectively referred to as Binding Information.
  • the GGSN passes the binding information from the PDP context signaling via the Go interface to the PDF.
  • the use of the authorization token has a number of disadvantages.
  • the signaling between AF and the terminal must support the transport of the token, which is currently the case only for SIP.
  • the terminal For GPRS, there is the restriction that the first PDP context established by the terminal does not support binding information, and the terminal therefore further PDP upon receipt of a token
  • the object of the present invention is to provide a simple and efficient possibility for signaling packet filter data representing packet filters in the uplink direction.
  • a core of the invention is to be seen in that a terminal transmits at least one packet filter for data packets in the uplink direction packet filter data in at least one TFT to a first network unit, for example the GGSN, wherein the terminal one or more values that in data streams in downlink direction can not occur for one or more existing parameters of the packet filter to indicate that the packet filter refers to one or more data packets in the uplink direction, and the GGSN need not understand the new use of the packet filter itself, but only the parameters of the packet filter to a further network unit, for example a control node SK, for example in the case of SBLP to the PDF and in the case of FBC to the CRF, which understands the new use of the parameters and thus recognizes packet filters for data packets in the uplink direction.
  • a control node SK for example in the case of SBLP to the PDF
  • FBC to the CRF
  • CRF and PDF are examples of a control node (SK) that communicates with the GGSN to affect the handling of PDP contexts and / or the handling of received payload data in the GGSN.
  • the further network unit (SK) knows which IP data streams are to be expected from and to a terminal, for example because it has received information corresponding to an AF. However, the further network unit initially does not know how the terminal distributes the uplink data streams via its PDP contexts. However, the further network unit needs this information in order to fulfill its tasks.
  • the present invention allows the terminal to tell the other network entity how it distributes the uplink data streams it sends over PDP contexts.
  • the invention is particularly advantageous because no change in the hitherto standardized format of the TFT is required, and thus the GPRS can remain completely unchanged.
  • An unchanged GGSN will attempt to allocate data streams in the downlink direction to PDP contexts in the TFT with the packet filter used according to the invention for the description of data packets in the uplink direction.
  • one or more values which are used for data streams in downlink Direction can not occur, uses for one or more existing parameters of the packet filter, it is excluded that the GGSN receives a data stream corresponding to the packet filter in the downlink direction.
  • the distribution of the data packets in the download direction to PDP contexts is not affected by this packet filter.
  • the terminal signals according to the invention a packet filter for data packets in the uplink direction in the TFT, in which the terminal indicates by specifying its own IP address as the sender address in this packet filter that the packet filter is not standardized as before on downlink data streams ( Data packets in the download direction), but refers to uplink data streams (data packets in the upload direction). Since the IP address of the terminal is unique, the GGSN will never receive IP packets with this sender address from the core IP network.
  • the TFT packet filter can contain further information, as already standardized for TFT packet filters, for example the port number of the receiver and information on the user data.
  • the terminal now describes uplink data streams in the same way as previously standardized for downlink data streams. For example, the sender port number now refers to the terminal. The terminal should select this information in such a way that it is possible for the further network unit to uniquely assign the uplink data streams to PDP contexts, for example by specifying a sender port number.
  • the terminal signals with a reserved (previously defined) value, for example the value "0" in a port number in a packet filter in the TFT, for example the receiver port number, that the packet ketfilter does not refer to downlink data streams standardized as before, but refers to uplink data streams.
  • a reserved (previously defined) value for example the value "0" in a port number in a packet filter in the TFT, for example the receiver port number
  • SDP session description protocol
  • the use of the receiver port number is particularly advantageous since the terminal itself determines the use of its own port numbers and thus never gives a certain value for receiving
  • the TFT packet filter can contain further information, as already standardized for TFT packet filters.
  • the terminal now describes uplink data streams in the same way as previously standardized for downlink data streams. The terminal should select this information in such a way that it is possible for the further network unit to uniquely assign the uplink data streams to PDP contexts.
  • a parameter for specifying the IP address of the receiver is still missing in the TFT packet filter. This information is an important indication for the assignment of uplink data streams to PDP contexts in the further network unit.
  • the terminal uses the parameter "sender address" in the TFT packet filter, deviating from the previous standard for specifying the recipient address, if an appropriate value in another parameter in the packet filter, such as receiver port number 0, indicates that the packet filter is referring to uplink data streams, if indicated by a special value in the parameter "receiver port number"
  • the terminal also uses the parameter "sender port number" in the TFT packet filter, deviating from the previous standard for specifying the receiver port number because the application function (AF) may not know sender address and port number, for example because SDP (Connection Description Protocol) does not support their signaling.
  • AF application function
  • the terminal can use several TFT packet filters for uplink data streams.
  • the terminal is to determine via priorities already standardized for TFT packet filters, in which order these filters are to be used when assigning uplink data streams to PDP contexts.
  • the GGSN recognizes in the encoding of a packet filter according to the invention that the packet filter relates to one or more uplink data streams, and does not apply the packet filter in the distribution of downlink data streams to PDP contexts. This allows the GGSN to save processing load since it has to compare each data packet in the downlink direction with the TFT packet filters. This behavior can, for example, be implemented in a GGSN that is newly inserted into the network, while existing GGSNs in the network can continue to be used unchanged.
  • the terminal at the GGSN avoids unnecessary processing burden by using the already standardized priorities for TFT packet filters to packet filters for uplink data streams assign a lower priority than packet filters for downlink data streams.
  • the terminal receives its IPv4 address or GGSN during the construction of the PDP context. assigned its IPv6 address prefix. Because of this, the terminal can not yet specify packet filters for data packets in the uplink direction when signaling for setting up the PDP context. Instead, the terminal uses an "Update PDP Context Request" to specify the packet filters for uplink data streams as soon as its IP address is assigned, before the terminal starts transmitting uplink data streams.
  • the GGSN When setting up or changing a PDP context, the GGSN indicates the TFT information received from the terminal, as well as the IPv4 address assigned to the PDP context or the IPv6 address prefix of the terminal to the further network unit, for example to the SK, to the PDF, or the CRF, further.
  • the GGSN passes the TFT information received from the terminal to the PDF and possibly also signals in the same message of the PDF the IPv4 address assigned to the PDP context or the IPv6 address prefix of the terminal if the GGSN stores the PDF around the Authorization of a new or modified PDP context requested for which the terminal has not informed him Binding information.
  • the further network unit can recognize from the encoding of a packet filter according to the invention that the packet filter relates to one or more uplink data streams.
  • the further network unit stores According to the received packet filter of the uplink data streams and the associated PDP contexts.
  • the further network unit determines according to the invention for all uplink data streams which it expects known services, for example because they were reported to it by an AF, the corresponding PDP context network unit with each IP data stream known to it, with any newly received or stored uplink
  • the further network unit compares each data stream with the packet filters for data packets in the uplink direction in the order of priorities assigned to the packet filters by the terminal until a packet filter matching the IP data stream is found, ie a positive comparison result is present. It may happen that uplink data streams already assigned to a PDP context are assigned to another PDP context by the new packet filters.
  • the present invention allows the PDF to recognize which uplink data streams are being transported in which PDP context.
  • the PDF can also use this information to inform the AF of events concerning the PDP context used to transport the corresponding IP data connections, for example the removal of the user connection.
  • the CRF can obtain the information which uplink data streams are transported in which PDP context from the packet filters for uplink data packets described in the TFT according to the invention. On the one hand, the CRF can use this information to calculate the charging rules. distribute according to PDP contexts. In addition, the CRF may use the information to similarly inform the AF about events relating to the PDP context used to transport the corresponding IP data connections, similar to the PDF. Previously, the standard only provided that the CRF informs the AF when all PDP contexts to a terminal have ended. Thus, the AF can not be sure to be informed when the PDP contexts used for its service are terminated, since PDP contexts still used by other services can be preserved. Also, it is not yet possible for the CRF to give the AF the information which data streams are transported in which PDP contexts. The AF could store this information for the purposes of statistics or billing, which can be better correlated with data collected in the GGSN.
  • a major advantage of the invention is that the invention enables the signaling of packet filters for uplink data streams by the GPRS without a change being necessary in the GPRS.
  • the invention allows SBLP for uplink data streams without the use of an authorization token and the associated described disadvantages.
  • SBLP is enabled for services that do not use SIP as a signaling protocol without introducing the authorization token for other signaling protocols.
  • the monitoring of the first PDP context is facilitated by SBLP and the changes to the existing standard are kept as small as possible.
  • the invention allows improved functionality of FBC compared to the current standard. In this way, charging rules can be better distributed over PDP contexts, thus avoiding load on the GGSN.
  • the CRF can provide the AF with improved notification of events involving PDP contexts used by the corresponding service.
  • the CRF is also enabled to give the AF the information which data streams are transported in which PDP contexts. The AF could use this information, for example, in the context of statistics or billing.
  • FIG. 1 shows a typical network configuration
  • Figure 2 shows the inventive method in the context of SBLP
  • Figure 3 shows the inventive method in the context of FBC
  • Figure 4 shows an inventive terminal
  • Figure 1 shows a typical network configuration. Shown are a terminal UE, for example a mobile terminal, a mobile computer, a computer, a mobile organizer, etc. an application function AF, and another network entity (control node) SK, for example in the case of SBLP a Policy Decision Function PDF and in the case of FBC a Charging Rules Function CRF.
  • the terminal in this example uses two PDP contexts A and B as connections to the GGSN through the mobile access network GPRS.
  • FIG. 2 shows the method according to the invention in the context of SBLP.
  • the signaling according to the invention transmission of the packet filter
  • a terminal advises UE an application function AF
  • a policy decision function (resource decision function) PDF and a gateway GPRS support node GGSN is exchanged.
  • These network elements are in the configuration shown in FIG.
  • the signaling sequence is as follows:
  • the terminal UE and the application function AF act by signaling a service, for example, with uplink data stream a and b.
  • the AF application function informs a resource decision function PDF that a service should be started with the terminal.
  • the IP address of the terminal is specified and the data streams a and b are described.
  • the terminal decides to separate PDP contexts A and b for data streams a and b. B to use. It sends for PDP context A a so-called PDP Context Activation Request to the gateway GPRS support node GGSN to request the establishment of the PDP context A.
  • the terminal UE in the signaling describes the use of the PDP context for the data packets in uplink direction a, in which it uses a TFT packet filter according to the invention in such a way that it does not standardize one or more downlink data streams as hitherto but uplink data streams describes .
  • the terminal UE uses a TFT packet filter with its own IP address as the sender address.
  • the terminal UE with the value "0" as the receiver port number signals that the packet filter relates to uplink data streams If the packet filter together with the receiver port number 0 indicates the parameters port number and / or IP Contains address of the sender, encoded the terminal UE according to the invention in information about the port number and / or IP address of the recipient.
  • the GGSN uses the received TFT packet filters to determine for received IP data streams in the downlink direction the PDP context to be used for handover. It is not necessary for the gateway GPRS support node GGSN to recognize from the encoding used by the terminal UE that a packet filter actually refers to uplink data streams.
  • the gateway GPRS support node GGSN requests the resource decision function PDF responsible for the terminal UE via the go interface for authorization of the PDP context A.
  • the already standardized corresponding command is changed in accordance with the invention so that on the one hand no binding information is specified on the other hand, the TFT packet filter as well as the IPv4 address or the IPv6 address prefix of the UE is specified.
  • the resource decision function PDF recognizes from the encoding used by the terminal UE that a received packet filter relates to an uplink data stream. If the sender address of the terminal UE is selected as the encoding variant, then the resource decision function PDF for IP version 4 compares the sender IPv4 address in the packet filter with the address of the terminal UE. In the case of IP
  • Version 6 compares the resource decision function PDF with the address prefix contained in the sender's IPv4 address in the packet filter with the IPv6 address prefix of the terminal UE.
  • the resource decision function PDF stores the received packet filters of the uplink data streams and the associated PDP contexts and determines the corresponding PDP context for the uplink data streams a and b reported by the application function AF. by comparing the data streams with packet filter a. For example, because data stream a matches packet filter a, PDF maps data stream a to context A to the PDP. The PDF can not assign data stream b to any PDP context yet. The PDF stores the assignment of data stream a to PDP context A.
  • the PDF now knows that data stream a is being transported in PDP Context A and uses this information and the algorithm already standardized in TS 29.208 to determine the authorized QoS A for this PDP context.
  • PDF signals to GGSN that for PDP context A is the authorized QoS A.
  • the PDF also installs a packet filter for data stream a called PDP in PDP context a an already standardized command will be used unaltered
  • the GGSN only passes data streams corresponding to the installed gate.
  • GGSN sends to UE a so-called PDP context Activate Response to complete the establishment of PDP Context A.
  • PDP context B is constructed and authorized, wherein the UE uses the TFT packet filter b according to the invention to describe the transported in PDP context B uplink data stream b.
  • the PDF compares both uplink data streams a and b reported by the application function AF with uplink packet filters a and b, since the new packet filter b may also assign data stream a to a new PDP context.
  • the terminal UE decides to terminate PDP Context A and signals this to gateway GPRS support node GGSN.
  • the gateway GPRS support node GGSN notifies the resource decision function PDF by means of an already standardized command that PDP context A will be terminated.
  • the resource decision function PDF uses the information already received and stored under step 4 in accordance with the invention in order to notify the application function AF that a PDP context has been ended which transported data stream a.
  • FIG. 3 describes the method according to the invention in the context of FBC.
  • a signaling is shown, which is exchanged between a terminal UE, an application function AF, a charging rules function CRF (charging control function) and a gateway GPRS support node GGSN.
  • CRF charging control function
  • the signaling sequence is as follows:
  • the terminal UE and the application function AF act by signaling a service, for example with
  • the application function AF informs the charging control function CRF that a service is to be started with the terminal UE.
  • the IP address of the terminal UE is specified and the data streams a and b are described.
  • the gateway GPRS support node GGSN requests the charging control function CRF responsible for UE via the Gx interface by charging rules for the PDP context A.
  • the already standardized corresponding command provides that the TFT Packet filter as well as the IPv4 address or the IPv6 address prefix of the UE device.
  • the charging control function CRF recognizes, based on the encoding used by the terminal UE, that the received packet filter has a value of
  • the uplink data streams a and b determine the corresponding PDP context for the uplink data streams a and b reported by the application function AF and store information, the charge control function CRF proceeding in the same way as for the resource decision function PDF described in step 4 in Figure 2.
  • the billing control function CRF now knows that data stream a is being carried in PDP context A and therefore only sets up a charging rule for data stream a in PDP context A. For this purpose, an already standardized command can be used unchanged.
  • the gateway GPRS support node GGSN sends to the
  • PDP context Activation Response to complete the construction of PDP context A.
  • PDP context B is set up, whereby the terminal UE uses the TFT packet filter b according to the invention to describe the uplink data stream b transported in PDP context B.
  • the charging control function CRF compares both of the application cation function AF reported uplink data streams a and b with uplink packet filters a and b, since the new packet filter b and data stream a may be assigned to a new PDP context.
  • the terminal UE decides to terminate the PDP context A and signals this to the gateway GPRS support node GGSN.
  • the gateway GPRS support node GGSN notifies the trust control function CRF by means of an already standardized command that PDP context A will be terminated.
  • the charging control function CRF uses the information already received and stored under step 4 according to the invention in order to notify the application function AF that a PDP context has been completed which transported data stream a.
  • FIG. 4 shows a terminal according to the invention with a transmitting unit S and a processing unit V for carrying out the method according to FIG. 2 and FIG. 3.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung beschreibt ein Verfahren, Vorrichtungen und ein Endgerät zum Übertragen von mindestens einen Paketfilter für Datenpakete in Uplink-Richtung repräsentierende Paketfilterdaten zwischen einem Endgerät (UE), einer ersten Netzeinheit (GGSN) und einer weiteren Netzeinheit (PDF,SK, CRF) über ein Kommunikationsnetz. Erfindungsgemäß sendet das Endgerät (UE) an die erste Netzeinheit (GGSN) mindestens einen Paketfilter repräsentierende Paketfilterdaten und darin mit mindestens einem Wert mindestens eines enthaltenen Parameters, der auf Datenpakete in Uplink- oder Downlink-Richtung anwendbar ist, angibt, dass der Paketfilter sich auf die Bearbeitung von Datenpaketen in Uplink-Richtung bezieht. Die erste Netzeinheit (GGSN) leitet die mindestens einen Paketfilter repräsentierenden Paketfilterdaten vom Endgerät an die weitere Netzeinheit (PDF, SK, CRF) weiter.

Description

Beschreibung
Paketfilter für Datenpakete in Uplink-Richtung
Die Erfindung betrifft ein Verfahren und ein Endgerät zum Ü- bertragen von mindestens einem Paketfilter für Datenpakete in Uplink-Richtung repräsentierende Paketfilterdaten zwischen einem Endgerät, einer ersten Netzeinheit und einer weiteren Netzeinheit über ein Kommunikationsnetz .
In der 3GPP-Standardisierung ist das so genannte „General Packet Radio Service" (GPRS) Mobilfunknetz in der Spezifikation 3GPP TS 23.060 zur paketorientierten Anbindung von mobilen Endgeräten an ein paketvermittelndes Kommunikationsnetz (zum Beispiel ein IP Netz ) standardisiert . Die GPRS Nutzverbindungen werden auch als „Packet Data Protocol" (PDP) Kontexte bezeichnet und verbinden ein Endgerät, das so genannte „User Equipment" (UE) , mit dem so genannten „Gateway GPRS Support Node" (GGSN) = Gateway-GPRS-Unterstützungsknoten, der IP Pa- ket-Nutzdaten zwischen PDP-Kontexten und dem Kern-IP-Paket- Netz weiterreicht . Es ist möglich, dass ein Endgerät mehrere PDP-Kontexte bzw . Punkt-zu-Punkt-Verbindungen zum GGSN aufbaut und gleichzeitig nutzt, beispielsweise Verbindungen mit unterschiedlicher so genannter „Quality of Service" (QoS) = Qualität des Dienstes , also zum Beispiel Bandbreite und mittels der so genannten QoS Klasse definierte erlaubte Verzögerung der Pakete . Der Aufbau oder die Modifikation eines PDP Kontextes wird vom Endgerät mittels in der Spezifikation 3GPP TS 24.008 standardisierter Signalisierung angestoßenen . Hier- bei teilt das Endgerät dem GGSN mittels so genannter „Traffic Flow Templates" (TFTs ) = Verkehrs-Fluss-Vorlagen mit, wie vom IP-Kernnetz empfangene IP Datenströme zwecks Weitertransport zum Endgerät hin auf PDP Kontexte verteilt werden sollen . Un- ter einem Datenstrom soll hier eine Folge von Datenpaketen mit derselben Absender- und Empfänger Adresse, sowie derselben Art von darin transportierten Nutzdaten verstanden werden . Im Falle von IP/UDP oder IP/TCP Transport sollen die IP Datenströme zusätzlich durch dieselben UDP bzw . TCP Portnummern von Sender und Empfänger charakterisiert sein . Ein TFT enthält einen oder mehrere Paketfilter repräsentierende Paketfilterdaten . Ein Paketfilter ermöglicht die Identifikation eines oder mehrerer Datenströme und kann durch folgende Anga- ben definiert sein : Empfänger und Absender-Adresse, Empfänger- und Sender-Portnummer oder Bereich von Portnummern, sowie weitere Angaben zur Art der transportierten Nutzdaten . Bisher sind in TFTs nur Paketfilter für Datenströme in so genannter „Downlink"-Richtung enthalten, also vom IP-Kernnetz hin zum Endgerät . Paketfilter für Datenströme in so genannter „Uplink"-Richtung, also vom Endgerät hin zum IP-Kernnetz , sind dagegen nicht enthalten, da sie der GGSN nicht zum Verteilen von Downlink-Datenströmen auf PDP Kontexte benötigt . Im Rahmen des in der 3GPP in TS 23.125, TS 29.210 und TS 29.211 standardisierte so genannte „Flow Based Charging"
(FBC) , sowie der in TS 23.207 , sowie TS 29.207 und TS 29.208 standardisierten so genannten „Service Based Local Policy" (SBLP) wäre es j edoch vorteilhaft, wenn das Endgerät dem GGSN auch Informationen über Uplink-Datenströme signalisieren könnte .
SBLP ermöglicht die dienstabhängige Autorisierung des Aufbaus von PDP-Kontexten über das GPRS Mobilfunknetz . Der vom Endgerät angestoßene Aufbau und die Modifikation von PDP- Kontexten wird am GGSN über die so genannte Go-Schnittstelle von der so genannten „Policy Decision Function" (PDF) Ressourcen-Entscheidungsfunktion autorisiert, die die von dem Endgerät gegenwärtig genützten Dienst kennt . Die PDF wird ü- ber diese Dienste von einer so genannten „Application Function" (AF) Applikationsfunktion informiert, die mit dem Endgerät zur Aushandlung des Dienstes Signalisierung austauscht, beispielsweise das im so genannten „Internet Protocol Multi- media Subsystem" (IMS) der 3GPP genützte „Session Initiation Protocol" (SIP) , IETF RFC 3261. Die Autorisierung legt die für den PDP Kontext erlaubte QoS und die erlaubten IP Datenströme fest . Die PDF weiß, welche IP Datenströme zu einem Dienst gehören . Zur Autorisierung eines PDP Kontextes muss die PDF wissen, welche IP Datenströme darin transportiert werden .
Bei FBC werden so genannte „Charging Rules" Vergebührungs- Regeln von der so genannten „Charging Rules Function" (CRF) Vergebührungs-Regelungs-Funktion über die so genannte Gx-
Schnittstelle am GGSN für bestimmte PDP-Kontext (e) dynamisch installiert . Die Charging Rules beschreiben IP Datenströme, sowie für sie anzuwendende Regeln zur Vergebührung . Die CRF wählt die Charging Rules unter Berücksichtigung von gegenwär- tig vom Endgerät genutzten Diensten aus , über die sie von
AF (s ) über die so genannte Rx-Schnittstelle informiert wird. Wenn ein PDP Kontext aktiviert oder modifiziert wird, signalisiert das der GGSN an die CRF über die Gx-Schnittstelle und reicht dabei die TFT Information weiter, wie bereits standar- disiert .
Die bisher in der Spezifikation 3GPP TS 29.207 standardisierte Lösung für SBLP, die der PDF ermöglicht zu erkennen, welche IP Datenströme in PDP Kontexten transportiert werden, verwendet das so genannte „Autorisierungs-Token" . Dieses To- ken wird für eine Dienst-Sitzung von der PDF auf Anforderung der AF generiert und vom AF zum Endgerät signalisiert . Das Endgerät nutzt das Token, sowie so genannte „Flow Identi- fier" , um beim Aufbau und der Veränderung eines PDP Kontextes in der entsprechenden Signalisierung anzugeben, für welche IP Datenströme der PDP Kontext verwendet werden soll . Die Flow Identifier sind zusätzliche Indizes , die IP Datenströme in- nerhalb des Dienstes angeben . Autorisierungs-Token und Flow Identifier werden zusammen als „Binding Information" bezeichnet . Der GGSN reicht die Binding Information aus der PDP Kontext Signalisierung über die Go-Schnittstelle zur PDF weiter . Die Benutzung des Autorisierungs-Tokens hat allerdings eine Reihe von Nachteilen zur Folge . So muss die Signalisierung zwischen AF und dem Endgerät den Transport des Tokens unterstützen, was gegenwärtig nur für SIP der Fall ist . Für GPRS gibt es die Einschränkung, dass der erste vom Endgerät aufgebaute PDP Kontext keine Binding Information unterstützt, und das Endgerät deswegen beim Erhalt eines Tokens weitere PDP
Kontext (e) aufbauen muss . Deswegen kann der zuerst aufgebaute PDP Kontext nicht über SBLP überwacht werden .
Die Aufgabe der vorliegenden Erfindung ist darin zu sehen, dass eine einfache und effiziente Möglichkeit für eine Signalisierung von Paketfilter repräsentierenden Paketfilterdaten für Datenpakete in Uplink-Richtung vorgeschlagen wird.
Die Aufgabe wird erfindungsgemäß j eweils durch die Gegenstän- de der unabhängigen Patentansprüche gelöst . Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben .
Ein Kern der Erfindung ist darin zu sehen, dass ein Endgerät mindestens einen Paketfilter für Datenpakete in Uplink- Richtung repräsentierende Paketfilterdaten in mindestens einen TFT zu einer ersten Netzeinheit, zum Beispiel dem GGSN, überträgt, wobei das Endgerät einen oder mehrere Werte, die bei Datenströmen in Downlink-Richtung nicht auftreten können, für einen oder mehrere bestehende Parameter des Paketfilters nutzt, um anzuzeigen, dass der Paketfilter sich auf einen o- der mehrere Datenpakete in Uplink-Richtung bezieht, und wobei der GGSN die neue Verwendung des Paketfilters nicht selbst verstehen muss , sondern die Parameter des Paketfilters nur an eine weitere Netzeinheit, zum Beispiel einen Steuerungsknoten SK, weiterreichen, beispielsweise im Falle von SBLP an die PDF und im Falle von FBC an die CRF, der die neue Verwendung der Parameter versteht und damit Paketfilter für Datenpakete in Uplink-Richtung erkennt .
CRF und PDF sind Beispiele eines Steuerungsknotens (SK) , die mit dem GGSN Daten austauschen um die Behandlung von PDP Kontexten und/oder die Behandlung von empfangenen Nutzdaten im GGSN zu beeinflussen . Die weitere Netzeinheit (SK) weiß, welche IP Datenströme von und zu einem Endgerät zu erwarten sind, beispielsweise weil er von einer AF entsprechende Informationen erhalten hat . Die weitere Netzeinheit weiß aber zunächst nicht, wie das Endgerät die Uplink-Datenströme über seine PDP Kontexte verteilt . Die weitere Netzeinheit benötigt diese Information j edoch, um seine Aufgaben zu erfüllen . Die vorliegende Erfindung ermöglicht es dem Endgerät der weiteren Netzeinheit mitzuteilen, wie es die von ihm gesendeten Uplink-Datenströme über PDP Kontexte verteilt .
Die Erfindung ist besonders vorteilhaft, da keine Veränderung des bisher standardisierten Formats des TFT erforderlich ist, und somit das GPRS völlig unverändert bleiben kann . Ein unveränderter GGSN wird versuchen, mit dem erfindungsgemäß zur Beschreibung von Datenpaketen in Uplink-Richtung verwendeten Paketfilter im TFT Datenströme in Downlink-Richtung PDP Kontexten zuzuordnen . Da j edoch das Endgerät erfindungsgemäß einen oder mehrere Werte, die bei Datenströmen in Downlink- Richtung nicht auftreten können, für einen oder mehrere bestehende Parameter des Paketfilters nutzt, ist ausgeschlossen, dass der GGSN einen dem Paketfilter entsprechenden Datenstrom in Downlink-Richtung empfängt . Somit wird die Ver- teilung der Datenpakete in Download-Richtung auf PDP Kontexte durch diesen Paketfilter nicht beeinflusst .
In einer Ausführungsform signalisiert das Endgerät erfindungsgemäß einen Paketfilter für Datenpakete in Uplink- Richtung im TFT, in dem das Endgerät durch Angabe seiner eigenen IP Adresse als Absender-Adresse in diesem Paketfilter anzeigt, dass der Paketfilter sich nicht wie bisher standardisiert auf Downlink-Datenströme (Datenpakete in Download- Richtung) , sondern auf Uplink-Datenströme (Datenpakete in Up- load-Richtung) bezieht . Da die IP Adresse des Endgerätes eindeutig ist, wird der GGSN niemals IP Pakete mit dieser Absenderadresse aus dem IP Kernnetz erhalten . Neben der Absender- Adresse kann der TFT Paketfilter weitere Angaben enthalten, wie bereits für TFT Paketfilter standardisiert, zum Beispiel die Port-Nummer des Empfängers und Angaben zu den Nutzdaten . In diesen Angaben beschreibt das Endgerät nunmehr Uplink- Datenströme in derselben Weise, wie bisher für Downlink- Datenströme standardisiert . Beispielsweise bezieht sich die Absender Portnummer nun auf das Endgerät . Das Endgerät soll diese Angaben so wählen, dass der weiteren Netzeinheit eine eindeutige Zuordnung der Uplink-Datenströme zu PDP Kontexten möglich ist, beispielsweise durch die Angabe einer Absender- Portnummer .
In einer weiteren Ausführungsform signalisiert das Endgerät mit einem reservierten (vorher definierten) Wert, beispielsweise dem Wert „0" in einer Portnummer in einem Paketfilter im TFT, beispielsweise der Empfänger-Portnummer, dass der Pa- ketfilter sich nicht wie bisher standardisiert auf Downlink- Datenströme, sondern auf Uplink-Datenströme bezieht . Die Verwendung des Wertes 0 ist besonders vorteilhaft, da in aller Regel die Port-Nummer 0 nicht zum Senden oder Empfangen von Datenströmen verwendet wird, da sie in dem weit verbreiteten so genannten „Session Description Protocol" (SDP) eine besondere Bedeutung zugewiesen bekommen hat . Die Verwendung der Empfänger-Portnummer ist besonders vorteilhaft, da das Endgerät die Verwendung der eigenen Portnummern selbst bestimmt und somit einen bestimmten Wert niemals zum Empfangen von
Downlink-Datenströmen auswählen kann . Neben der Port-Nummer mit reserviertem Wert kann der TFT Paketfilter weitere Angaben enthalten, wie bereits für TFT Paketfilter standardisiert . In diesen Angaben beschreibt das Endgerät nunmehr Uplink-Datenströme in derselben Weise, wie bisher für Down- link-Datenströme standardisiert . Das Endgerät soll diese Angaben so wählen, dass der weiteren Netzeinheit eine eindeutige Zuordnung der Uplink-Datenströme zu PDP Kontexten möglich ist .
Allerdings fehlt im TFT Paketfilter bisher ein Parameter zur Angabe der IP Adresse des Empfängers . Diese Angabe ist für die Zuordnung von Uplink-Datenströmen zu PDP Kontexten in der weiteren Netzeinheit eine wichtige Angabe . Um auch die Signa- lisierung der IP Adresse des Empfängers eines oder mehrerer Uplink-Datenströme zu ermöglichen, ist es vorteilhaft, wenn das Endgerät den Parameter „Absender-Adresse" im TFT Paketfilter, abweichend vom bisherigen Standard zur Angabe der Empfänger-Adresse verwendet, wenn durch einen geeigneten Wert in einem anderen Parameter im Paketfilter, beispielsweise durch Empfänger-Portnummer 0 , angezeigt wird, dass der Paketfilter sich auf Uplink-Datenströme bezieht . Wenn durch einen besonderen Wert im Parameter „Empfänger-Portnummer" angezeigt wird, dass der Paketfilter sich auf Uplink-Datenströme bezieht, ist es darüber hinaus vorteilhaft, wenn das Endgerät auch den Parameter „Absender-Portnummer" im TFT Paketfilter, abweichend vom bisherigen Standard zur Angabe der Empfänger- Portnummer verwendet . Diese Ausführungsform ist besonders vorteilhaft, da die Applikationsfunktion (AF) Absender- Adresse und Portnummer möglicherweise nicht kennt, beispielsweise weil SDP (Verbindungs-Beschreibungs-Protokoll) ihre Signalisierung nicht unterstützt .
Das Endgerät kann mehrere TFT Paketfilter für Uplink- Datenströme verwenden . In diesem Fall soll das Endgerät über bereits für TFT Paketfilter standardisierte Prioritäten festlegen, in welcher Reihenfolge diese Filter bei der Zuordnung von Uplink-Datenströmen auf PDP Kontexte anzuwenden sind.
In einer weiteren vorteilhaften Ausführungsform erkennt der GGSN an der erfindungsgemäßen Enkodierung eines Paketfilters , dass der Paketfilter sich auf einen oder mehrere Uplink- Datenströme bezieht, und wendet den Paketfilter entsprechend nicht bei der Verteilung von Downlink-Datenströme auf PDP Kontexte an . Dadurch kann der GGSN Prozessierungslast sparen, da er j edes Datenpaket in Downlink-Richtung mit den TFT Paketfiltern vergleichen muss . Dieses Verhalten kann beispiels- weise in einem GGSN implementiert werden, der neu ins Netz eingefügt wird, während bestehende GGSNs im Netz unverändert weiter verwendet werden können .
In noch einer weiteren vorteilhaften Ausführungsform vermei- det das Endgerät am GGSN dadurch unnötige Prozessierungslast, dass es die bereits standardisierten Prioritäten für TFT Paketfilter dazu nutzt, um Paketfiltern für Uplink-Datenströmen eine niedrigere Priorität zuzuweisen als Paketfiltern für Downlink-Datenströme .
Beim Aufbau des ersten PDP Kontextes bekommt das Endgerät während des Aufbaus des PDP Kontextes vom GGSN seine IPv4 Adresse bzw . seinen IPvβ Adress-Präfix zugewiesen . Deswegen kann das Endgerät bei der Signalisierung zum Aufbau des PDP Kontextes noch keine Paketfilter für Datenpakete in Uplink- Richtung angeben . Stattdessen benutzt das Endgerät einen ,,Up- date PDP Kontext Request" , um die Paketfiltern für Uplink- Datenströme anzugeben, sobald seine IP Adresse zugewiesen ist . Erst danach beginnt das Endgerät das Senden von Uplink- Datenströmen .
Der GGSN gibt beim Aufbau oder der Veränderung eines PDP Kontextes die vom Endgerät erhaltene TFT Information, sowie die dem PDP Kontext zugeordnete IPv4 Adresse beziehungsweise den IPvβ Adress-Präfix des Endgerätes an die weitere Netzeinheit, beispielsweise an den SK, an die PDF, oder an die CRF, wei- ter . Im Fall von SBLP reicht der GGSN erfindungsgemäß die vom Endgerät erhaltene TFT Information an die PDF weiter und signalisiert in derselben Nachricht der PDF möglicherweise auch die dem PDP Kontext zugeordnete IPv4 Adresse oder den IPvβ Adress-Präfix des Endgerätes , wenn der GGSN die PDF um die Autorisierung eines neuen oder modifizierten PDP Kontextes ersucht, für den das Endgerät ihm keine Binding Information mitgeteilt hat .
Weiterhin kann erfindungsgemäß die weitere Netzeinheit an der erfindungsgemäßen Enkodierung eines Paketfilters erkennen, dass das Paketfilter sich auf einen oder mehrere Uplink- Datenströme bezieht . Die weitere Netzeinheit speichert erfin- dungsgemäß die empfangenen Paketfilter der Uplink-Datenströme und die zugehörigen PDP Kontexte ab .
Falls die weitere Netzeinheit neue Paketfilter von Uplink- Datenströmen vom GGSN enthält, ermittelt die weitere Netzeinheit erfindungsgemäß für alle Uplink-Datenströme, die er für ihm bekannte Dienste erwartet, beispielsweise weil sie ihm von einer AF gemeldet wurden, den entsprechenden PDP Kontext, wobei die weitere Netzeinheit j eden ihm bekannten IP Daten- ström mit j edem neu empfangenen oder gespeicherten Uplink-
Datenstrom vergleicht . Die weitere Netzeinheit vergleicht j eden Datenstrom mit den Paketfiltern für Datenpakete in Uplink-Richtung in der Reihenfolge der den Paketfiltern vom Endgerät zugeordneten Prioritäten, bis ein zum IP Datenstrom passender Paketfilter gefunden ist, also ein positives Vergleichsergebnis vorliegt . Es kann vorkommen, dass durch die neuen Paketfilter bereits einem PDP Kontext zugeordnete Uplink-Datenströme einem anderen PDP Kontext zugewiesen werden .
Die vorliegende Erfindung ermöglicht der PDF damit zu erkennen, welche Uplink-Datenströme in welchem PDP Kontext transportiert werden . Neben der Autorisierung kann die PDF diese Information auch dazu nutzen, die AF über Ereignisse zu in- formieren, die den zum Transport der entsprechenden IP Datenverbindungen genutzten PDP Kontext betreffen, beispielsweise den Abbau der Nutzverbindung .
Die CRF kann die Information, welche Uplink-Datenströme in welchem PDP Kontext transportiert werden, aus den erfindungsgemäß im TFT beschriebenen Paketfiltern für Datenpakete in Uplink-Richtung erhalten . Die CRF kann diese Information einerseits nutzen, um die Charging Rules (Vergebührungs-Regeln) entsprechend über PDP Kontexte zu verteilen . Daneben kann die CRF die Information nutzen, um in ähnlicher Weise wie die PDF die AF über Ereignisse zu informieren, die den zum Transport der entsprechenden IP Datenverbindungen genützten PDP Kontext betreffen . Bisher sah der Standard nur vor, dass die CRF den AF informiert, wenn alle PDP Kontexte zu einem Endgerät beendet sind. Damit kann der AF nicht sicher sein, darüber informiert zu werden, wenn die für seinen Dienst genützten PDP Kontexte beendet werden, da noch von anderen Diensten genutz- te PDP Kontexte erhalten bleiben können . Auch ist es der CRF bisher nicht möglich, der AF die Information zu geben, welche Datenströme in welchen PDP Kontexten transportiert werden . Die AF könnte diese Information zum Zwecke von Statistiken oder der Vergebührung gesammelten Daten abspeichern, die da- durch besser mit im GGSN gesammelten Daten korreliert werden können .
Ein großer Vorteil der Erfindung besteht darin, dass die Erfindung die Signalisierung von Paketfiltern für Uplink- Datenströme durch das GPRS ermöglicht, ohne dass im GPRS dafür eine Veränderung nötig ist .
Weiterhin ermöglicht die Erfindung SBLP für Uplink-Daten- ströme ohne Verwendung eines Autorisierungs-Tokens und der damit verbundenen beschriebenen Nachteile . So wird SBLP für Dienste ermöglicht, die nicht SIP als Signalisierungsproto- koll nutzen ohne für andere Signalisierungsprotokolle das Authorisierungstoken einzuführen . Außerdem wird die Überwachung des ersten PDP Kontextes durch SBLP ermöglicht und da- bei werden die Veränderungen gegenüber dem bestehenden Standard werden so klein wie möglich gehalten . Daneben ermöglicht die Erfindung eine verbesserte Funktionalität von FBC im Vergleich zum gegenwärtigen Standard. So können Charging Rules besser über PDP Kontexte verteilt und damit Last am GGSN vermieden werden . Darüber hinaus kann die CRF dem AF eine verbesserte Benachrichtigung über Ereignisse bieten, die PDP Kontexte betreffen, die vom entsprechenden Dienst genutzt werden . Zudem wird es der CRF auch ermöglicht, der AF die Information zu geben, welche Datenströme in welchen PDP Kontexten transportiert werden . Die AF könnte diese Information beispielsweise im Rahmen von Statistiken oder der Vergebührung nutzen .
Die Erfindung wird anhand eines in einer Figur dargestellten Ausführungsbeispiels näher erläutert . Dabei zeigen
Figur 1 eine typische Netz-Konfiguration,
Figur 2 das erfindungsgemäße Verfahren im Rahmen von SBLP, Figur 3 das erfindungsgemäße Verfahren im Rahmen von FBC, Figur 4 ein erfindungsgemäßes Endgerät
Figur 1 zeigt eine typische Netz-Konfiguration . Dargestellt sind ein Endgerät UE, das beispielsweise ein Mobilfunkendge- rät, ein mobiler Computer, ein Computer, ein mobiler Organizer etc . sein kann, eine Applikationsfunktion AF, und eine weitere Netzeinheit (Steuerungsknoten) SK, beispielsweise im Falle von SBLP eine Policy Decision Function PDF und im Falle von FBC eine Charging Rules Function CRF . Das Endgerät nutzt in diesem Beispiel zwei PDP Kontexte A und B als Verbindungen zum GGSN durch das mobile Zugangsnetz GPRS .
Figur 2 zeigt das erfindungsgemäße Verfahren im Rahmen von SBLP . Es wird die erfindungsgemäße Signalisierung (Übertragung des Paketfilters ) dargestellt, die zwischen einem Endge- rät UE, einer Applikationsfunktion AF, einer Policy Decision Function (Ressourcen-Entscheidungsfunktion) PDF und einem Gateway GPRS Support Node GGSN ausgetauscht wird. Diese Netzwerkelemente befinden sich in der in Figur 1 dargestellten Konfiguration . Der Signalisierungsablauf ist im Einzelnen wie folgt :
1. Das Endgerät UE und die Applikationsfunktion AF handeln mittels Signalisierung einen Dienst beispielsweise mit Uplink-Datenstrom a und b aus .
2. Die AF Applikationsfunktion informiert eine Ressourcen- Entscheidungsfunktion PDF, dass ein Dienst mit dem Endgerät gestartet werden soll . Die IP Adresse des Endgerätes wird an- gegeben und die Datenströme a und b werden beschrieben .
3. Das Endgerät beschließt, für Datenströme a und b getrennte PDP Kontexte A bzw . B zu verwenden . Es sendet für PDP Kontext A einen so genannten PDP Context Activation Request (Kontext- Aktivierungsanfrage) zum Gateway-GPRS-Unterstützungsknoten GGSN, um den Aufbau des PDP Kontextes A anzufordern . Erfindungsgemäß beschreibt das Endgerät UE in der Signalisierung die Verwendung des PDP Kontextes für den Datenpakete in Uplink-Richtung a, in dem es eine TFT Paketfilter erfindungs- gemäß so verwendet, dass er nicht wie bisher standardisiert einen oder mehrere Downlink-Datenströme sondern Uplink- Datenströme beschreibt . In einer Variante verwendet das Endgerät UE dazu einen TFT Paketfilter mit seiner eigenen IP Adresse als Absenderadresse . In einer alternativen Ausführungs- form signalisiert das Endgerät UE mit dem Wert „0" als Empfänger-Portnummer, dass der Paketfilter sich auf Uplink- Datenströme bezieht . Wenn der Paketfilter zusammen mit der Empfänger-Portnummer 0 die Parameter Port-Nummer und/oder IP Adresse des Absenders enthält, enkodiert das Endgerät UE erfindungsgemäß darin Angaben zu Port-Nummer und/oder IP Adresse des Empfängers . Der GGSN nutzt die empfangenen TFT Paketfilter, um für empfangene IP Datenströme in Downlink-Richtung den zum Weiterreich zu verwendenden PDP Kontext zu ermitteln . Es ist dabei nicht erforderlich, dass der Gateway-GPRS- Unterstützungsknoten GGSN an der vom Endgerät UE verwendeten Enkodierung erkennt, dass ein Paketfilter sich tatsächlich auf Uplink-Datenströme bezieht .
4. Der Gateway-GPRS-Unterstützungsknoten GGSN ersucht die für das Endgerät UE zuständige Ressourcen-Entscheidungsfunktion PDF über die Go-Schnittstelle um Autorisierung des PDP Kontextes A. Das bereits standardisierte entsprechende Kommando wird erfindungsgemäß so verändert, dass einerseits keine Bin- ding Information angegeben wird und andererseits die TFT Paketfilter sowie die IPv4 Adresse oder der IPvβ Adress-Präfix des Endgerätes UE angegeben wird. Die Ressourcen- Entscheidungsfunktion PDF erkennt erfindungsgemäß an der vom Endgerät UE verwendeten Enkodierung, dass ein empfangener Paketfilter sich auf einen Uplink-Datenstrom bezieht . Falls als Enkodierungsvariante die Absender-Adresse des Endgerätes UE gewählt ist, vergleicht die Ressourcen-Entscheidungsfunktion PDF für IP Version 4 dazu die Absender IPv4 Adresse im Paket- filter mit der Adresse des Endgerätes UE . Im Falle von IP
Version 6 vergleicht die Ressourcen-Entscheidungsfunktion PDF den in der Absender IPv4 Adresse im Paketfilter enthaltenen Adress-Präfix mit dem IPvβ Adress-Präfix des Endgerätes UE . Die Ressourcen-Entscheidungsfunktion PDF speichert erfin- dungsgemäß die empfangenen Paketfilter der Uplink-Datenströme und die zugehörigen PDP Kontexte ab und ermittelt erfindungsgemäß für die ihr von der Applikationsfunktion AF gemeldeten Uplink-Datenströme a und b den entsprechenden PDP Kontext, indem sie die Datenströme mit Paketfilter a vergleicht . Da beispielsweise Datenstrom a zu Paketfilter a passt, ordnet die PDF Datenstrom a dem PDP Kontext A zu . Die PDF kann Datenstrom b noch keinem PDP Kontext zuordnen . Die PDF spei- chert die Zuordnung von Datenstrom a zu PDP Kontext A.
5. Die PDF weiß nun, dass Datenstrom a in PDP Kontext A befördert wird und ermittelt mit Hilfe dieser Information und dem in TS 29.208 bereits standardisierten Algorithmus die au- torisierte QoS A für diesen PDP Kontext . PDF signalisiert an GGSN, dass für PDP Kontext A die autorisierte QoS A. Um sicherzustellen, dass PDP Kontext A nur für Datenstrom a verwendet wird, installiert die PDF auch einen als „Gate" bezeichneten Paketfilter für Datenstrom a in PDP Kontext a . Dazu kann ein bereits standardisiertes Kommando unverändert verwendet werden . Gemäß dem existierenden Standard für SBLP lässt der GGSN nur den installierten Gate entsprechende Datenströme passieren .
6. GGSN sendet an UE einen so genannten PDP Kontext Activati- on Response (Kontext Aktivierungsantwort) , um den Aufbau von PDP Kontext A abzuschließen .
7. - 10. Analog zu den Schritten 3. bis 6. wird PDP Kontext B aufgebaut und autorisiert, wobei das Endgerät UE den TFT Paketfilter b erfindungsgemäß verwendet, um den in PDP Kontext B transportierten Uplink-Datenstrom b zu beschreiben . In Schritt 9 vergleicht die PDF beide von der Applikationsfunktion AF gemeldete Uplink-Datenströme a und b mit Uplink- Paketfiltern a und b, da durch den neuen Paketfilter b auch Datenstrom a möglicherweise einem neuen PDP Kontext zugewiesen wird. 11. Nach einiger Zeit beschließt das Endgerät UE, PDP Kontext A zu beenden, und signalisiert das an Gateway-GPRS- Unterstützungsknoten GGSN .
12. Der Gateway-GPRS-Unterstützungsknoten GGSN teilt der Ressourcen-Entscheidungsfunktion PDF mittels eines bereits standardisierten Kommandos mit, dass PDP Kontext A beendet wird.
13. Die Ressourcen-Entscheidungsfunktion PDF nutzt die be- reits erfindungsgemäß unter Schritt 4 empfangene und abgespeicherte Information, um die Applikationsfunktion AF zu benachrichtigen, dass ein PDP Kontext beendet wurde, der Datenstrom a transportierte .
Figur 3 beschreibt das erfindungsgemäße Verfahren im Rahmen von FBC . Es wird eine Signalisierung dargestellt, die zwischen einem Endgerät UE, einer Applikationsfunktion AF, einer Charging Rules Function CRF (Vergebührungs-Regelungs- Funktion) und einem Gateway GPRS Support Node GGSN ausge- tauscht wird.
Der Signalisierungsablauf ist im Einzelnen wie folgt :
1. Das Endgerät UE und die Applikationsfunktion AF handeln mittels Signalisierung einen Dienst beispielsweise mit
Uplink-Datenstrom a und b aus .
2. Die Applikationsfunktion AF informiert die Vergebührungs- Regelungs-Funktion CRF, dass ein Dienst mit dem Endgerät UE gestartet werden soll . Die IP Adresse des Endgerätes UE wird angegeben und die Datenströme a und b werden beschrieben .
3. wie Schritt 3 in Figur 2. 4. Der Gateway-GPRS-Unterstützungsknoten GGSN ersucht die für UE zuständige Vergebührungs-Regelungs-Funktion CRF über die Gx-Schnittstelle um Charging Rules (Vergebührungs-Regelung) für den PDP Kontext A. Das bereits standardisierte entsprechende Kommando sieht vor, dass die TFT Paketfilter sowie die IPv4 Adresse oder der IPvβ Adress-Präfix des Endgerätes UE angegeben wird. Die Vergebührungs-Regelungs-Funktion CRF erkennt erfindungsgemäß an der vom Endgerät UE verwendeten En- kodierung, dass der empfangener Paketfilter sich auf einen
Uplink-Datenstrom bezieht, ermittelt erfindungsgemäß für die ihr von der Applikationsfunktion AF gemeldeten Uplink- Datenströme a und b den entsprechenden PDP Kontext und speichert Information ab, wobei die Vergebührungs-Regelungs- Funktion CRF in der selben Weise vorgeht, wie für die Ressourcen-Entscheidungsfunktion PDF unter Schritt 4 in Figur 2 beschrieben .
5. Die Vergebührungs-Regelungs-Funktion CRF weiß nun, dass Datenstrom a in PDP Kontext A befördert wird und richtet deswegen nur eine Charging RuIe (Vergebührungsregel) für Datenstrom a in PDP Kontext A ein . Dazu kann ein bereits standardisiertes Kommando unverändert verwendet werden .
6. Der Gateway-GPRS-Unterstützungsknoten GGSN sendet an das
Endgerät UE einen so genannten PDP Kontext Activation Response, um den Aufbau von PDP Kontext A abzuschließen .
7. - 10. Analog Schritten 3. bis 6. wird PDP Kontext B aufge- baut, wobei das Endgerät UE den TFT Paketfilter b erfindungsgemäß verwendet, um den in PDP Kontext B transportierten Uplink-Datenstrom b zu beschreiben . In Schritt 9 vergleicht die Vergebührungs-Regelungs-Funktion CRF beide von der Appli- kationsfunktion AF gemeldete Uplink-Datenströme a und b mit Uplink-Paketfiltern a und b, da durch den neuen Paketfilter b auch Datenstrom a möglicherweise einem neuen PDP Kontext zugewiesen wird.
11. Nach einiger Zeit beschließt das Endgerät UE den PDP Kontext A zu beenden und signalisiert das an den Gateway-GPRS- Unterstützungsknoten GGSN .
12. Der Gateway-GPRS-Unterstützungsknoten GGSN teilt der Ver- gebührungs-Regelungs-Funktion CRF mittels eines bereits standardisierten Kommandos mit, dass PDP Kontext A beendet wird.
13. Die Vergebührungs-Regelungs-Funktion CRF nutzt die be- reits erfindungsgemäß unter Schritt 4 empfangene und abgespeicherte Information, um der Applikationsfunktion AF zu benachrichtigen, dass ein PDP Kontext beendet wurde, der Datenstrom a transportierte .
Figur 4 zeigt ein erfindungsgemäßes Endgerät mit einer Sendeeinheit S und einer Verarbeitungseinheit V zum Durchführen des Verfahrens gemäß Figur 2 und Figur 3.

Claims

Patentansprüche
1. Verfahren zum Übertragen von mindestens einem Paketfilter für Datenpakete in Uplink-Richtung repräsentierende Paketfilterdaten zwischen einem Endgerät (UE) , einer ersten Netzeinheit (GGSN) und einer weiteren Netzeinheit (PDF, SK, CRF) über ein Kommunikationsnetz ,
dadurch gekennzeichnet,
dass das Endgerät (UE) an die erste Netzeinheit (GGSN) mindestens einen Paketfilter repräsentierende Paketfilterdaten sendet und darin mit mindestens einem Wert mindestens eines enthaltenen Parameters , der auf Datenpakete in Uplink- oder Downlink-Richtung anwendbar ist, angibt, dass der Paketfilter sich auf die Bearbeitung von Datenpaketen in Uplink-Richtung bezieht, und dass die erste Netzeinheit (GGSN) die mindestens einen Paketfilter repräsentierenden Paketfilterdaten vom Endgerät an die weitere Netzeinheit (PDF, SK, CRF) weiterleitet .
2. Verfahren nach Anspruch 1 ,
dadurch gekennzeichnet,
dass der mindestens eine Wert nur bei Datenpaketen in Uplink- Richtung verwendet wird.
3. Verfahren nach Anspruch 1 ,
dadurch gekennzeichnet, dass der mindestens eine Wert bei keinem Datenpaket verwendet wird.
4. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass der mindestens eine Wert als Wert eines eine Portnummer repräsentierenden Parameters der Paketfilterdaten verwendet wird.
5. Verfahren nach Anspruch 4 ,
dadurch gekennzeichnet,
dass der mindestens eine Wert den Wert 0 hat .
6. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass der mindestens eine Wert als Wert eines eine Empfänger- Portnummer repräsentierenden Parameters der Paketfilterdaten verwendet wird.
7. Verfahren nach Anspruch 2 ,
dadurch gekennzeichnet,
dass die IP-Adresse des Endgerätes (UE) als Wert eines die Adresse des Absenders repräsentierenden Parameters der Paketfilterdaten verwendet wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
dass die IP-Adresse des Empfängers der Datenpakete in Uplink- Richtung in einem bei Anwendung auf Datenpakete in Downlink- Richtung die Absender-Adresse repräsentierenden Parameter der Paketfilterdaten in mindestens einen Paketfilter eingetragen wird, bei dem durch die Verwendung mindestens eines Wertes in mindestens einem anderen Parameter angegeben wird, dass der Paketfilter sich auf die Bearbeitung von Datenpaketen in Uplink-Richtung bezieht .
9. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die Portnummer des Empfängers der Datenpakete in Uplink- Richtung in einem bei Anwendung auf Datenpakete in Downlink- Richtung die Absender-Portnummer repräsentierenden Parameter der Paketfilterdaten in mindestens einen Paketfilter eingetragen wird, bei dem durch die Verwendung mindestens eines Wertes in mindestens einem anderen Parameter angegeben wird, dass der Paketfilter sich auf die Bearbeitung von Datenpaketen in Uplink-Richtung bezieht .
10. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die erste Netzeinheit (GGSN) mindestens einen Paketfilter für Datenpakete in Uplink-Richtung repräsentierende Paketfilterdaten auf Datenpakete in Downlink-Richtung anwendet .
11. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die erste Netzeinheit (GGSN) anhand der Enkodierung der einen Paketfilter repräsentierenden Paketfilterdaten erkennt, dass es sich bei den Paketfilter repräsentierenden Paketfilterdaten um Paketfilterdaten für Datenpakete in Uplink- Richtung handelt .
12. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass vom Endgerät (UE) Paketfilter repräsentierende Paketfilterdaten für Datenpakete in Uplink-Richtung eine niedrigere Priorität als Paketfilter repräsentierenden Paketfilterdaten für Datenpakete in Downlink-Richtung zugewiesen wird.
13. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die erste Netzeinheit (GGSN) Paketfilter repräsentieren- de Paketfilterdaten und entweder die IP-Adresse oder den Adressen-Präfix der IP-Adresse des Endgerätes an die weitere Netzeinheit (PDF, SK, CRF) sendet .
14. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass die erste Netzeinheit (GGSN) Paketfilter repräsentierende Paketfilterdaten und eine Angabe der den Paketfilterdaten zugeordneten Punkt-zu-Punkt-Verbindung zwischen dem Endgerät (UE) und der ersten Netzeinheit (GGSN) an die weitere Netz- einheit (PDF, SK, CRF) sendet .
15. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die weitere Netzeinheit (PDF, SK, CRF) anhand der Enko- dierung der Paketfilter repräsentierenden Paketfilterdaten erkennt, dass es sich bei den Paketfilter repräsentierenden Paketfilterdaten um Paketfilterdaten für Datenpakete in Uplink-Richtung handelt .
16. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass von der weiteren Netzeinheit (PDF, SK, CRF) die Paketfilter repräsentierenden Paketfilterdaten für Datenpakete in Uplink-Richtung und mindestens eine dazugehörige Punkt-zuPunkt-Verbindung zwischen der ersten Netzeinheit (GGSN) und dem Endgerät (UE) gespeichert werden .
17. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die weitere Netzeinheit (PDF, SK, CRF) mindestens einen IP-Datenstrom mit Datenpaketen in Uplink-Richtung mit den er- haltenen Paketfilter repräsentierenden Paketfilterdaten für Datenpakete in Uplink-Richtung vergleicht und dass bei einem positiven Vergleichsergebnis die den Paketfilterdaten zugeordneten Punkt-zu-Punkt-Verbindungen zwischen der ersten Netzeinheit (GGSN) und dem Endgerät (UE) zugeordnet werden .
18. Verfahren nach Anspruch 17 ,
dadurch gekennzeichnet,
dass der Vergleich in der Reihenfolge der den Paketfiltern repräsentierenden Paketfilterdaten vom Endgerät (UE) zugeordneten Prioritäten erfolgt .
19. Verfahren nach Anspruch 17 ,
dadurch gekennzeichnet,
dass der Vergleich für alle von der ersten Netzeinheit (GGSN) übertragenen Paketfilterdaten und den bereits gespeicherten Paketfilterdaten durchgeführt wird.
20. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass die Paketfilterdaten in mindestens einem Traffic-Flow- Template übertragen werden .
21.Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass als Kommunikationsnetz ein zellulares Mobilfunknetz und/oder ein paketvermittelndes Kommunikationsnetz verwendet wird.
22. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass als erste Netzeinheit (GGSN) ein Gateway-GPRS- Unterstützungsknoten (GGSN) verwendet wird.
23. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass als Punkt-zu-Punkt-Verbindung zwischen der ersten Netzeinheit (GGSN) und dem Endgerät (UE) ein PDP-Kontext verwendet wird.
24. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass als weitere Netzeinheit (PDF, SK, CRF) eine Ressourcen- Entscheidungsfunktion (PDF) , ein Steuerungsknoten (SK) und/oder eine Vergebührungs-Regelungs-Funktion (CRF) verwendet wird.
25. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass als Endgerät (UE) ein Mobilfunkendgerät, ein mobiler Computer, ein mobiler Organizer und/oder ein Computer verwendet wird.
26. Endgerät (UE) zum Übertragen von mindestens einen Paketfilter für Datenpakete in Uplink-Richtung repräsentierenden Paketfilterdaten vom Endgerät (UE) an eine erste Netzeinheit (GGSN) über ein Kommunikationsnetz ,
- mit einer Sendeeinheit (S) zur Kommunikation mit der ersten Netzeinheit,
- mit einer Verarbeitungseinheit (V) zum Erstellen von Paketfilter repräsentierende Paketfilterdaten mit mindestens einem enthaltenen Parameter, der angibt, dass der Paketfilter sich auf die Bearbeitung von Datenpaketen in Uplink-Richtung bezieht, in mindestens einem Traffic- Flow-Template und zum Senden von den Paketfilter repräsentierenden Paketfilterdaten an die erste Netzeinheit (GGSN) .
27. Endgerät nach Anspruch 26,
dadurch gekennzeichnet,
dass als Endgerät (UE) ein Mobilfunkendgerät, ein mobiler
Computer, ein Computer und/oder ein mobiler Organizer vorgesehen ist .
28. Vorrichtung in einer ersten Netzeinheit (GGSN) zum Ver- arbeiten von mindestens einen Paketfilter für Datenpakete in Uplink-Richtung repräsentierenden Paketfilterdaten, die von einem Endgerät (UE) über ein Kommunikationsnetz empfangen wurden, - mit einer Sendeeinheit und einer Empfangseinheit zur Kommunikation mit einem Endgerät (UE) und einer weiteren Netzeinheit (PDF, SK, CRF) , - mit einer Verarbeitungseinheit zum Erkennen anhand der Enkodierung der einen empfangenen Paketfilter repräsentierenden Paketfilterdaten, dass es sich bei den Paketfilter repräsentierenden Paketfilterdaten um Paketfilterdaten für Datenpakete in Uplink-Richtung handelt .
29. Vorrichtung in einer weiteren Netzeinheit (PDF, SK, CRF) zum Verarbeiten von mindestens einen Paketfilter für Datenpakete in Uplink-Richtung repräsentierenden Paketfilterdaten, die von einer ersten Netzeinheit (GGSN) über ein Kommunikationsnetz empfangen wurden,
- mit einer Sendeeinheit und einer Empfangseinheit zur Kommunikation mit einem Endgerät und einer weiteren Netzeinheit, - mit einer Verarbeitungseinheit zum Vergleichen mindestens eines IP-Datenstromes mit Datenpaketen in Uplink- Richtung mit den erhaltenen Paketfilter repräsentierenden Paketfilterdaten für Datenpakete in Uplink-Richtung und bei einem positiven Vergleichsergebnis zum Zuordnen die den Paketfilterdaten zugeordneten Punkt-zu-Punkt-
Verbindungen zwischen der ersten Netzeinheit (GGSN) und dem Endgerät (UE) .
PCT/EP2006/050159 2005-01-28 2006-01-11 Paketfilter für datenpakete in uplink-richtung WO2006079586A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005004153A DE102005004153A1 (de) 2005-01-28 2005-01-28 Paketfilter für Datenpakete in Uplink-Richtung
DE102005004153.1 2005-01-28

Publications (1)

Publication Number Publication Date
WO2006079586A1 true WO2006079586A1 (de) 2006-08-03

Family

ID=36095690

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/050159 WO2006079586A1 (de) 2005-01-28 2006-01-11 Paketfilter für datenpakete in uplink-richtung

Country Status (2)

Country Link
DE (1) DE102005004153A1 (de)
WO (1) WO2006079586A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030039259A1 (en) * 2001-07-10 2003-02-27 Lila Madour Traffic flow template for managing packet data flows
US20040028234A1 (en) * 2000-12-26 2004-02-12 Stmicroelectronics Sa Logic circuit with variable internal polarities

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2403097A (en) * 2003-06-16 2004-12-22 Orange Personal Comm Serv Ltd Communicating internet packets having care-of-address as destination address to a mobile node

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040028234A1 (en) * 2000-12-26 2004-02-12 Stmicroelectronics Sa Logic circuit with variable internal polarities
US20030039259A1 (en) * 2001-07-10 2003-02-27 Lila Madour Traffic flow template for managing packet data flows

Also Published As

Publication number Publication date
DE102005004153A1 (de) 2006-08-10

Similar Documents

Publication Publication Date Title
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE102006022046B4 (de) Verfahren zum Ermöglichen einer Steuerung der Dienstqualität und/oder der Dienstvergebührung bei Telekommunikationsdiensten
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60225278T2 (de) Technik zur verbesserung von ansagen in anrufen mit mobilursprung
DE60130114T2 (de) Anwendungsbeeinflusste richtlinie
DE60008735T2 (de) Steuerung von pdp-kontexten in mobilstationen
DE60125422T2 (de) Abbildung von paketen auf pdp-kontexte bei vielfach-verbindungen
DE20212587U1 (de) Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotkolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
EP1887740A1 (de) Festlegung des Veranlassers für eine Konfiguration oder einen Aufbau einer Zugangsnetzverbindung
EP1994714B1 (de) Verfahren zur zuordnung von zumindest einer nutzdatenverbindung zu zumindest einer multiplexverbindung
DE60130498T2 (de) Verfahren und vorrichtung zur trägerberechtigung in einem drahtlosen kommunikationsnetzwerk
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
DE102005035237A1 (de) Verfahren zur Steuerung von Ressourcen in Netzelementen eines Telekommunikationsnetzes
DE102005006174A1 (de) Signalisierung eines Wechsels von einem ersten Dienst zu einem zweiten Dienst während einer Gesprächsverbindung
DE60101571T2 (de) Datenträger in einem kommunikationssystem
DE60022913T2 (de) Lösen einer verbindung in einem zwei schichten netzwerk
EP1985144B1 (de) Verfahren zur gewährleistung von dienstgüte in paketvermittelnden mobilfunknetzen
EP1887738A1 (de) Festlegung des Veranlassers für eine Konfiguration oder einen Aufbau einer Zugangsnetzverbindung
DE102005014852A1 (de) Entscheidung zur Zuordnung und Ressourcenvergabe für mindestens einem Datenstrom und mindestens eine Nutzverbindung
WO2006079586A1 (de) Paketfilter für datenpakete in uplink-richtung
EP1708435B1 (de) Durchsetzung geeigneter Richtlinien für Datenverkehr in einem Funk-Kommunikationssystem
DE102005013905B4 (de) Ermittlung der Zuordnung von Datenströmen zu Nutzverbindungen durch Benachrichtigung bei detektierten Daten mindestens eines Datenstroms an einen Steuerungsknoten
DE102004032714B4 (de) Kommunikationssystem, Verfahren zum Steuern eines Kommunikationssystems, Signalisierungseinrichtung, Steuereinrichtung und Verfahren zum Zuteilen von Funkressourcen in einem Kommunikationssystem
DE102004036732A1 (de) Verfahren zur Überwachung eines Nachrichtenverkehrs, sowie eine erste und zweite Netzwerkeinheit zu dessen Druchführung
WO2008003720A2 (de) Anordnung, verfahren und steuereinrichtung zur vergebührung eines paketorientierten datenflusses sowie netzknoten und kommunikationsendgerät

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase

Ref document number: 06701171

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 6701171

Country of ref document: EP