DE102007044715A1 - Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz und Kontrolleinrichtung - Google Patents

Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz und Kontrolleinrichtung Download PDF

Info

Publication number
DE102007044715A1
DE102007044715A1 DE102007044715A DE102007044715A DE102007044715A1 DE 102007044715 A1 DE102007044715 A1 DE 102007044715A1 DE 102007044715 A DE102007044715 A DE 102007044715A DE 102007044715 A DE102007044715 A DE 102007044715A DE 102007044715 A1 DE102007044715 A1 DE 102007044715A1
Authority
DE
Germany
Prior art keywords
data
communication network
type
header
data frame
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
DE102007044715A
Other languages
English (en)
Inventor
Peter Hagl
Markus Moser
Alfred Dr. Pohl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE102007044715A priority Critical patent/DE102007044715A1/de
Publication of DE102007044715A1 publication Critical patent/DE102007044715A1/de
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q9/00Arrangements in telecontrol or telemetry systems for selectively calling a substation from a main station, in which substation desired apparatus is selected for applying a control signal thereto or for obtaining measured values therefrom
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2209/00Arrangements in telecontrol or telemetry systems
    • H04Q2209/40Arrangements in telecontrol or telemetry systems using a wireless architecture
    • H04Q2209/47Arrangements in telecontrol or telemetry systems using a wireless architecture using RFID associated with sensors

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz werden in einen Header eines Datenrahmens, in dem aus einem RFID-Tag mit zugeordneter Speichereinheit mittels eines Lesegeräts ausgelesene Informationen zusammengefaßt sind, eine Kennzeichnung für aus einem RFID-Tag ausgelesene Informationen und eine Angabe über einen Datentyp der ausgelesenen Informationen eingefügt. Anhand der Kennzeichnung und der Angabe über den Datentyp erfolgt eine typspezifische Filterung des Datenrahmens bei einer Weiterleitung durch das Kommunikationsnetz und/oder bei einer Verarbeitung durch eine Datenverarbeitungsanlage.

Description

  • Auslesbare Funkmarken, insbesondere RFID-Tags, sind wichtige Bestandteile einer automatisierten Erkennung von Gütern und eröffnen zahlreiche Anwendungsmöglichkeiten im Bereich der Logistik. Beispiele für derartige Anwendungsmöglichkeiten sind automatisierte Logistikprozesse von der Herstellung von Waren bis zu deren Entsorgung oder von der Reservierung einer Unterhaltungsveranstaltung bis zur Platzeinweisung.
  • Aufgrund der zahlreichen Anwendungsmöglichkeiten von RFID-Tags und der damit verbundenen Menge zu verarbeitender ausgelesener Informationen ist eine starke Zunahme der Auslastung von Kommunikationsnetzen, über welche die Informationen übermittelt werden, zu erwarten. Bei der Übermittlung der Informationen bestehen einerseits im Hinblick auf Datendurchsatz, Datenverlustraten, Fehlerraten oder Antwortzeiten hohe Anforderungen seitens der jeweiligen Anwendungen an eine Gewährleistung einer hinreichenden, möglichst konstanten Dienstgüte (Quality of Service – QoS). Andererseits bestehen Sicherheitsrisiken, wenn aus RFID-Tags ausgelesene Daten inhaltlich unkontrolliert im Kommunikationsnetz weitergeleitet oder verarbeitet werden, da RFID-Tags im allgemeinen nicht mit Sicherheitsmechanismen versehen sind, die eine Speicherung beispielsweise von schädlichem Programmcode im RFID-Tag verhindern.
  • Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz anzugeben, das eine effiziente Abwendung von Gefahren durch aus einem RFID-Tag ausgelesenen Schad-Code ermöglicht, sowie eine geeignete Implementierung des Verfahrens zu schaffen.
  • Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit den in Anspruch 1 angegebenen Merkmalen und durch eine Kontrolleinrichtung mit den in Anspruch 8 angegebenen Merkmalen gelöst. Vorteilhafte Weiterbildungen der vorliegenden Erfindung sind in den abhängigen Ansprüchen angegeben.
  • Ein wesentlicher Aspekt der vorliegenden Erfindung liegt darin, daß zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz in einen Header eines Datenrahmens, in dem aus einem RFID-Tag mit zugeordneter Speichereinheit mittels eines Lesegeräts ausgelesene Informationen zusammengefaßt sind, eine Kennzeichnung für aus einem RFID-Tag ausgelesene Informationen und eine Angabe über einen Datentyp der ausgelesenen Informationen eingefügt werden. Anhand der Kennzeichnung und der Angabe über den Datentyp erfolgt eine typspezifische Filterung des Datenrahmens bei einer Weiterleitung durch das Kommunikationsnetz und/oder bei einer Verarbeitung durch eine Datenverarbeitungsanlage.
  • Die Kennung läßt Rückschlüsse auf eine möglicherweise unsichere bzw. ungeprüfte Datenquelle zu, wobei die Angabe über den Datentyp zur Plausibilisierung herangezogen werden kann. Auf diese Weise kann eine Firewall für Datenverkehr mit aus RFID-Tags ausgelesenen Informationen realisiert werden, so daß eine Verbreitung von in RFID-Tags gespeichertem Schad-Code wirksam unterbunden werden kann. Dies ist insbesondere deswegen von Bedeutung, da RFID-Tags üblicherweise nicht über hinreichend viel Rechenleistung zum Ablauf von entsprechender Sicherheits-Software verfügen.
  • Entsprechend einer bevorzugten Weiterbildung der vorliegenden Erfindung werden Netzwerkressourcen für eine Weiterleitung des Datenrahmens durch das Kommunikationsnetz zu einem Empfänger aufgrund der Kennzeichnung priorisiert verfügbar gemacht. Damit ist auch eine priorisierte Behandlung von diskreten Datenpaketen möglich, die keine kontinuierlichen Datenströme bilden und aufgrund dessen konventionellen QoS-Ansätzen nicht zugänglich sind.
  • Für die Weiterleitung des Datenrahmens werden bevorzugt kurzzeitig verfügbare Netzwerkressourcen priorisiert bereitgestellt. Damit kann einerseits auf schnell verfügbare Ressourcen zurückgegriffen werden. Andererseits wird eine optimierte Ressourcenauslastung erzielt, insbesondere im Hinblick auf andernfalls ungenutzte Ressourcen. Vorzugsweise wird der Datenrahmen für die Weiterleitung zum Empfänger als nichtkontinuierlicher Datenstrom behandelt. Der Datenrahmen kann beispielsweise hinsichtlich Latenzzeit, Datendurchsatz und/oder Verlustrate priorisiert zum Empfänger weitergeleitet werden. Die Kennzeichnung wird vorzugsweise im Protocol-Feld eines IPv4-Headers oder im Next-Header-Feld eines IPv6-Headers eingefügt.
  • Die vorliegende Erfindung wird nachfolgend an einem Ausführungsbeispiel anhand der Zeichnung näher erläutert. Es zeigt
  • 1 Anwendungsumfeld der vorliegenden Erfindung mit einem Kommunikationsnetz, einem Server, einem RFID- Tag, einem RFID-Lesegerät und mehreren Kontrolleinrichtungen für RFID-Datenverkehr,
  • 2 einen modifizierten IPv4-Header zur Übermittlung von RFID-Datenpaketen,
  • 3 einen modifizierten IPv6-Header zur Übermittlung von RFID-Datenpaketen.
  • Das in 1 dargestellte Anwendungsumfeld der vorliegenden Erfindung umfaßt ein RFID-Tag 101, ein RFID-Lesegerät 102, eine Sende-/Empfangsstation 103 eines Mobilfunknetzes, mehrere Netzknoten 104 eines Kommunikationsnetzes und einem Server 105. Das RFID-Tag 101 ist an einem zugeordneten Gegenstand 112 befestigt und enthält beispielsweise Informationen über eine Identifikationsnummer des Gegenstand 112.
  • Das RFID-Lesegerät 102 weist eine Funkeinheit zum Aufbau einer Mobilfunkverbindung mit der Sende-/Empfangsstation 103 auf, die wiederum über die Netzknoten 104 mit dem Server 105 verbunden ist. Die Netzknoten sind 104 im vorliegenden Ausführungsbeispiel Router, welche Vermittlungsfunktionen im Kommunikationsnetz wahrnehmen.
  • Mit dem RFID-Lesegerät 102 im RFID-Tag 101 gespeicherte Informationen ausgelesen, die zu Datenpaketen 111 zusammengefaßt werden. Die Datenpakete 111 werden senderseitig mit einem Header versehen, in den eine spezielle Kennzeichnung für aus einem RFID-Tag ausgelesene Informationen und eine Angabe über einen Datentyp der ausgelesenen Informationen eingefügt werden. Durch den Datentyp wird beispielsweise gekennzeichnet, ob es sich bei den ausgelesenen Informationen um Pro duktcodes, Programmierbefehle oder Daten für Object Naming Services handelt.
  • Ein Datenpaket 111 mit aus einem RFID-Tag ausgelesenen Informationen wird vom RFID-Lesegerät 102 an die Sende-/Empfangsstation 103 übermittelt und von dort über die Netzknoten 104 des Kommunikationsnetzes zur Verarbeitung an den Server 105 übermittelt.
  • Einige der Netzknoten 104 und der Server 105 sind mit Kontrolleinrichtungen 141, 151 für RFID-Datenverkehr versehen. Die Kontrolleinrichtungen weisen jeweils ein Filterelement zur typspezifischen Filterung eines Datenpakets 111 auf. Anhand der Kennzeichnung und der Angabe über den Datentyp im Header eines Datenpakets 111 erfolgt die typspezifische Filterung bei einer Weiterleitung des Datenpakets 111 über die Netzknoten 104 oder bei einer Verarbeitung des Datenpakets 111 im Server 105. Beispielsweise wird hierdurch eine Ausführung von ungeprüftem Programmcode blockiert, während Produktcodes weitergeleitet bzw. verarbeitet werden. Die Kontrolleinrichtung 141, 151 können sowohl durch Hardware als auch durch Software implementiert sein, beispielsweise als Firewall.
  • Bei einer Konzeption einer Firewall sind zwei konkurrierende Forderungen zu vereinen. Einerseits soll sich ein Hohes Maß an Sicherheit erreicht werden, andererseits sollen Datenverkehr bzw. Datenverarbeitung möglichst wenig behindert werden. Eine Firewall kann für Paketfilterung, Circuit Relay oder Application Gateway konfiguriert sein. Es können auch mehrere Konfigurationsarten gleichzeitig aktiviert sein.
  • Bei der Paketfilterung werden die ein- und ausgehenden Datenpakete auf der Sicherungsschicht, der Netzwerkschicht und der Transportschicht anhand einer vorhandenen Tabelle analysiert und kontrolliert. Ein Filter interpretiert den Inhalt der Datenpakete und verifiziert, ob die Daten in den entsprechenden Headern der Kommunikationssteuerungsschicht den definierten Regeln entsprechen.
  • Circuit-Relay basiert auf einer Verwendung eines Subnetzes und zweier Router sowie eines Hosts als Verbindungspartner. Dadurch sind von außen keine Rückschlüsse auf Netzstrukturen möglich. Ein Rechner, der eine Verbindung aufbauen will, muß sich beim Host anmelden und eine Zugangsberechtigung nachweisen. Übertragene Daten werden dann nicht mehr überwacht.
  • Ist eine Firewall als Application Gateway konfiguriert, werden Teilnetze sowohl logisch als auch physikalisch entkoppelt. Außerdem wird von jedem Benutzer eine vorherige Identifikation und Authentifikation erwartet. Bei einer derartigen anwendungsspezifischen Filterung werden die Datenpakete auf einem Proxy-Server empfangen. Eine spezielle Software (Proxy) überträgt dann das Datenpaket von einer Netzwerkseite auf die andere. Dabei kommt keine direkte Verbindung zwischen Zielrechner und Besucher zustande. Grundsätzlich kann für jeden angebotenen Dienst, wie Telnet, E-Mail oder http, ein anwendungsspezifischer Gateway bereitgestellt werden. Eine Beschränkung eines Application Gateways auf einen ausgewählten Dienst eröffnet zudem zusätzliche Sicherungs- und Protokollierungsmöglichkeiten.
  • Aufgrund der Kennzeichnung eines Datenpakets 111 als RFID-Datenpaket werden im vorliegenden Ausführungsbeispiel Netz- Werkressourcen für die Weiterleitung des Datenpakets 111 über die Netzknoten 104 zum jeweiligem einem Empfänger priorisiert verfügbar gemacht. Insbesondere werden für die Weiterleitung eines solchen Datenpakets kurzzeitig verfügbare Netzwerkressourcen priorisiert bereitgestellt, wobei das Datenpaket als nichtkontinuierlicher Datenstrom behandelt wird.
  • Entsprechend einer bevorzugten Ausgestaltung der vorliegenden Erfindung wird die Kennzeichnung im Protokoll-Feld 209 eines in 2 dargestellten IPv4-Headers (Internet Protocol Version 4) eingefügt. IPv4 ist in RFC 791 definiert und benutzt 32-Bit-Adressen. Eine IP-Adresse ist in einen Netzwerkteil und einen Hostadressenteil gegliedert.
  • Ein IP-Datenpaket besteht aus einem Header (Kopf) und einem Bereich mit Nutzdaten befinden. Der Header ist den Nutzdaten vorangestellt. Der Header ist in jeweils 32-Bit-Blöcke unterteilt. Dort sind Angaben zu Servicetypen, Paketlänge, Sender- und Empfängeradresse abgelegt. Ein IP-Datenpaket enthält mindestens einen 20 Byte großen Header und 8 Byte Nutzdaten bzw. Nutz- und Fülldaten. Die Gesamtlänge eines IP-Datenpakets ist kleiner oder gleich 65.535 Byte. Je nach Datenmenge und Übertragungsverfahren auf der Bitübertragungsschicht werden die Nutzdaten üblicherweise in mehrere IP-Datenpakete aufgeteilt. Bei aus einem RFID-Tag ausgelesenen Informationen ist dies jedoch in der Regel aufgrund der geringen Datenmenge nicht erforderlich. Durch Vermittlungseinrichtungen des Kommunikationsnetzes kann ein Datenpaket mit aus einem RFID-Tag ausgelesenen Informationen bei einer Weiterleitung zum Empfänger als nichtkontinuierlicher Datenstrom behandelt und hinsichtlich Latenzzeit, Datendurchsatz bzw. Verlustrate priorisiert zum Empfänger weitergeleitet werden.
  • Im Version-Feld 201 des IPv4-Headers ist die Version des IP-Protokolls abgelegt, nach der das IP-Datenpaket erstellt ist. Das IHL-Feld 202 (Internet Header Length) gibt dagegen die Länge des IP-Headers als Vielfaches von 32 Bit an. Im ToS-Feld 203 (Type of Service) wird die Qualität des jeweils angeforderten Dienstes festgelegt. Das Paketlänge-Feld 204 (Total Length) enthält die Gesamtlänge des IP-Datenpakets. Vermindert im die im IHL-Feld 202 angegebenen Länge ergibt sich die Länge der reinen Nutzdaten. Im Kennung-Feld 205 (Identification) wird der Wert wird zur Numerierung der Datenpakete verwendet. Die Kennung ist eindeutig und fortlaufend.
  • Da die Nutzdaten in der Regel nicht in ein IP-Datenpaket hineinpassen, werden die Daten zerlegt und in mehrere IP-Datenpakete verpackt und versendet. Das Flags-Feld 206 ist zur Behandlung von fragmentierten Daten vorgesehen. Das erste Bit des Flags-Felds 206 ist immer auf 0 gesetzt. Durch das zweite Bit des Flags-Felds 206 kann eine Fragmentierung eines Datenpakets unterbunden werden. Das dritte Bit des Flags-Felds 206 enthält Informationen über weitere Datenpaket-Fragmente. Enthalt ein IP-Datenpaket fragmentierte Nutzdaten, steht im Fragment-Offset-Feld 207 die Position der Nutzdaten im ursprünglichen IP-Datenpaket.
  • Durch das TTL-Feld 208 (Time to Live) bezeichnet der Sender eines Datenpakets die Lebensdauer des Datenpakets. Jede Station, die ein IP-Datenpaket weiterleitet, vermindert den im TTL-Feld 208 angegebenen Wert um 1. Hat Wert 0 erreicht, wird das IP-Datenpaket verworfen. Hierdurch wird verhindert, daß Datenpakete fortwährend weitergeleitet werden, wenn sie faktisch nicht zustellbar sind.
  • Durch die im Header-Checksummen-Feld 210 (Header Checksum) angegebene Checksumme wird die Korrektheit des Headers sichergestellt. Für die Nutzdaten übernimmt ein übergeordnetes Protokoll die Fehlerkorrektur. Da sich bei einer Weiterleitung eines Datenpaket vom Start bis zum Ziel Felder des Headers ändern, prüft jede Vermittlungseinrichtung auf dem Weg zum Ziel die Checksumme und berechnet diese wieder neu. Um die Verzögerung durch eine Prüfsummenvalidierung gering zu halten wird lediglich der Header eines Datenpakets geprüft.
  • Im Quell-IP-Adresse-Feld 211 (Source IP-Address) ist IP-Adresse der Kommunikationseinrichtung angegeben, die eine Datenpaket versendet hat. In entsprechender Weise ist im Ziel-IP-Adresse-Feld 212 (Destination IP-Address) die IP-Adresse der Kommunikationseinrichtung angegeben, für die das Datenpaket bestimmt ist. Soll ein Datenpaket an mehrere Stationen zugestellt werden, wird im Ziel-IP-Adresse-Feld 212 eine Multicast-Adresse angegeben.
  • Das Optionen/Füllbits-Feld 213 (Options/Padding) des Headers enthält Informationen zu Routing-, Debugging-, Statistik- und Sicherheitsfunktionen und ist optional und kann zu Diagnosezwecken verwendet werden.
  • An die Felder 201213 des Headers schließt sich bei einem IPv4-Datenpaket ein Feld 214 mit Nutzdaten (Payload) an.
  • Entsprechend einer anderen vorteilhaften Weiterbildung der vorliegenden Erfindung wird die Kennzeichnung im Next-Header-Feld 305 eines in 3 dargestellten IPv6-Headers (Internet Protocol Version 6) eingefügt.
  • Der Kopfdatenbereich eines IPv6-Datenpakets setzt sich aus folgenden Feldern zusammen:
    • – Version 301 mit der Versionsnummer des verwendeten Protokolls,
    • – Traffic Class/Priority 302 zur QoS-Spezifikation,
    • – Flow Label 303 zur Spezifikation von Dienstgüte oder Echtzeitanwendungen,
    • – Payload Length 304 zur Angabe der Länge eines IPv6-Paketinhalts ohne Kopfdatenbereich aber inklusive Extension Header (Erweiterungskopfdaten),
    • – Next Header 305 zur Identifizierung des nächsten Extension Headers,
    • – Hop Limit/TTL (Time to Live) 306 für eine Festlegung einer maximalen Anzahl von Zwischenstationen über Router,
    • – Source Address 307 für die Adresse des Senders,
    • – Destination Address 308 für die Adresse des Empfängers.
  • Bei einer Datenübermittlung per ATM (Asynchronous Transfer Mode) erfolgt eine Kennzeichnung für aus einem RFID-Tag ausgelesene Informationen anhand einer Assigned Number im Header einer ATM-Zelle.
  • Die Anwendung der vorliegenden Erfindung ist nicht auf das hier beschriebene Ausführungsbeispiel beschränkt.

Claims (8)

  1. Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz, bei dem – in einen Header eines Datenrahmens, in dem aus einem RFID-Tag mit zugeordneter Speichereinheit mittels eines Lesegeräts ausgelesene Informationen zusammengefaßt sind, eine Kennzeichnung für aus einem RFID-Tag ausgelesene Informationen und eine Angabe über einen Datentyp der ausgelesenen Informationen eingefügt werden, – anhand der Kennzeichnung und der Angabe über den Datentyp eine typspezifische Filterung des Datenrahmens bei einer Weiterleitung durch das Kommunikationsnetz und/oder bei einer Verarbeitung durch eine Datenverarbeitungsanlage erfolgt.
  2. Verfahren nach Anspruch 1, bei dem Netzwerkressourcen für die Weiterleitung des Datenrahmens durch das Kommunikationsnetz zu einem Empfänger aufgrund der Kennzeichnung priorisiert verfügbar gemacht werden.
  3. Verfahren nach einem der Ansprüche 1 oder 2, bei dem für die Weiterleitung des Datenrahmens kurzzeitig verfügbare Netzwerkressourcen aufgrund der Kennzeichnung priorisiert bereitgestellt werden.
  4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem der Datenrahmen für die Weiterleitung zu einem Empfänger aufgrund der Kennzeichnung als nichtkontinuierlicher Datenstrom behandelt wird.
  5. Verfahren nach einem der Ansprüche 3 oder 4, bei dem der Datenrahmen hinsichtlich Latenzzeit, Datendurchsatz und/oder Verlustrate priorisiert zum Empfänger weitergeleitet wird.
  6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem die Kennzeichnung im Protocol-Feld eines IPv4-Headers eingefügt wird.
  7. Verfahren nach einem der Ansprüche 1 bis 5, bei dem die Kennzeichnung im Next-Header-Feld eines IPv6-Headers eingefügt wird.
  8. Kontrolleinrichtung zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz mit einem Filterelement zur typspezifischen Filterung eines Datenrahmens, in dem aus einem RFID-Tag mit zugeordneter Speichereinheit mittels eines Lesegeräts ausgelesene Informationen zusammengefaßt sind, mit einem Datenrahmen-Header, in den eine Kennzeichnung für aus einem RFID-Tag ausgelesene Informationen und eine Angabe über einen Datentyp der ausgelesenen Informationen eingefügt sind, anhand der Kennzeichnung und der Angabe über den Datentyp bei einer Weiterleitung des Datenrahmens durch das Kommunikationsnetz und/oder bei einer Verarbeitung des Datenrahmens durch eine Datenverarbeitungsanlage.
DE102007044715A 2007-09-18 2007-09-18 Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz und Kontrolleinrichtung Ceased DE102007044715A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102007044715A DE102007044715A1 (de) 2007-09-18 2007-09-18 Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz und Kontrolleinrichtung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102007044715A DE102007044715A1 (de) 2007-09-18 2007-09-18 Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz und Kontrolleinrichtung

Publications (1)

Publication Number Publication Date
DE102007044715A1 true DE102007044715A1 (de) 2009-03-19

Family

ID=40348665

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007044715A Ceased DE102007044715A1 (de) 2007-09-18 2007-09-18 Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz und Kontrolleinrichtung

Country Status (1)

Country Link
DE (1) DE102007044715A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005001745A2 (en) * 2003-06-30 2005-01-06 Nokia Corporation Rfid system with packetized data storage in a mobile environment
US6853294B1 (en) * 2000-07-26 2005-02-08 Intermec Ip Corp. Networking applications for automated data collection

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6853294B1 (en) * 2000-07-26 2005-02-08 Intermec Ip Corp. Networking applications for automated data collection
WO2005001745A2 (en) * 2003-06-30 2005-01-06 Nokia Corporation Rfid system with packetized data storage in a mobile environment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DARPA (Hrsg.): Internet Protocol. RFC791, Protocol Specification, September 1981, S.1-45
DARPA (Hrsg.): Internet-Protocol. RFC791, Protocol Specification, September 1981, S. 1-45 *

Similar Documents

Publication Publication Date Title
EP1298880B1 (de) Verfahren zur Übermittlung komprimierter Daten in paketvermittelnden Netzwerken
DE60008735T2 (de) Steuerung von pdp-kontexten in mobilstationen
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE60115967T2 (de) Eine methode für handhabung von meldungen zwischen einem terminal und einem datennetz
DE69928812T2 (de) Vorrichtung und verfahren zur zuverlässigen paketübertragung mit niedriger verzögerung
EP1994677B1 (de) Verfahren zur übertragung der identität einer multicast-nachricht, verfahren und vorrichtung zur übertragung einer multicast-nachricht sowie vorrichtung zum empfangen einer multicast-nachricht
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60031163T2 (de) Verfahren und vorrichtungen zum bereitstellen einer wohldefinierten servicequalität in einem paketvermittelten kommunikationsnetz
DE60117229T2 (de) Verfahren zum Betreiben eines mobilen Telekommunikationsnetzes
EP1405422B1 (de) Verfahren zur optimierten nutzung von sctp (stream control transmission protocol) in mpls (multi protocol label switching) netzen
EP1438829B1 (de) Verfahren und vorrichtung zur abbildung von netzwerk-headern auf mpls-header in bearer-architekturen
WO2007068613A1 (de) Verfahren zur übertragung von auf dem ethernet-übertragungsprotokoll basierenden datenpaketen zwischen zumindest einer mobilen kommunikationseinheit und einem kommunikationssystems
EP1761081A1 (de) Kommunikationssystem, Vermittlungsknoten-Rechner und Verfahren zur Bestimmung eines Kontrollknotens
DE60006821T2 (de) Zugangskontrolle in einem gateway-server
DE10147755A1 (de) Verfahren und Vorrichtungen zur Header-Kompression in paketorientierten Netzwerken
DE60219263T2 (de) Überwachung und Übertragung von QOS-Daten in einem Telekommunikationsnetzwerk
DE102007044715A1 (de) Verfahren zur Verarbeitung von RFID-Datenverkehr in einem Kommunikationsnetz und Kontrolleinrichtung
EP1771993B1 (de) Verfahren zur überwachung eines nachrichtenverkehrs, sowie eine erste und zweite netzwerkeinheit zu dessen durchführung
DE69931132T2 (de) Funkstrecke mit dynamischer Anpassung
DE102007044714A1 (de) Verfahren zur Übermittlung von in einem Funk-Etikett gespeicherten Informationen in einem Kommunikationsnetz
DE60128807T2 (de) Verfahren und anordnung für kommunikationssysteme
DE10124706A1 (de) Verfahren zur Weiterleitung von Datenpaketen in Routern von Kommunikationsnetzen
US20060221929A1 (en) Description of packet in a packet communication network
DE102005014852A1 (de) Entscheidung zur Zuordnung und Ressourcenvergabe für mindestens einem Datenstrom und mindestens eine Nutzverbindung
EP1500249B1 (de) Verfahren und vorrichtung zum übertragen von datenpaketen in einem kommunikationssystem bei verwendung pep und eines ran

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8131 Rejection