DE60211136T2 - Verfahren und vorrichtung zur ausser-band-übetragung von rundfunkdienst-optionen in einem drahtlosen kommunikationssystem - Google Patents

Verfahren und vorrichtung zur ausser-band-übetragung von rundfunkdienst-optionen in einem drahtlosen kommunikationssystem Download PDF

Info

Publication number
DE60211136T2
DE60211136T2 DE60211136T DE60211136T DE60211136T2 DE 60211136 T2 DE60211136 T2 DE 60211136T2 DE 60211136 T DE60211136 T DE 60211136T DE 60211136 T DE60211136 T DE 60211136T DE 60211136 T2 DE60211136 T2 DE 60211136T2
Authority
DE
Germany
Prior art keywords
broadcast
information
service
channel
overhead
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.)
Expired - Lifetime
Application number
DE60211136T
Other languages
English (en)
Other versions
DE60211136D1 (de
Inventor
K. Nikolai Takoma Park LEUNG
T. Raymond San Diego HSU
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.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of DE60211136D1 publication Critical patent/DE60211136D1/de
Application granted granted Critical
Publication of DE60211136T2 publication Critical patent/DE60211136T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H04N21/43637—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wireless protocol, e.g. Bluetooth, RF or wireless LAN [IEEE 802.11]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Reduction Or Emphasis Of Bandwidth Of Signals (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Transmitters (AREA)

Description

  • HINTERGRUND
  • Beanspruchung der Priorität unter 35 U.S.C. § 120
  • Die vorliegende Anwendung für ein Patent beansprucht die Priorität der U.S. Provisional Application Nr. 60/279,970 eingereicht am 28. März 2001, dem Rechtsnachfolger der vorliegenden Erfindung hiermit zugeordnet und hiermit hierin ausdrücklich durch Bezugnahme inkorporiert.
  • Bezugnahme auf die ebenfalls anhängigen Patentanmeldungen
  • Die vorliegende Erfindung bezieht sich auf die folgenden Patentanmeldungen in dem U.S. Patent & Trademark Office:
    "Method and Apparatus for Security in a Data Processing System" von Philip Hawkes et al., mit der Anwaltsanmeldenummer Nr. 010497, eingereicht gleichzeitig hiermit und dem Rechtsnachfolger hiervon zugeordnet, und welches hierin durch Bezugnahme inkorporiert wird;
    "Method and Apparatus for Overhead Messaging in a Wireless Communication System" von Nikolai Leung, mit der Anwaltsanmeldenummer Nr. 010439, eingereicht gleichzeitig hiermit und dem Rechtsnachfolger hiervon zugeordnet, und welches hierin durch Bezugnahme inkorporiert wird;
    "Method and Apparatus for Broadcast Signaling in a Wireless Communication System" von Nikolai Leung, mit der Anwaltsanmeldenummer Nr. 010438, eingereicht gleichzeitig hiermit und dem Rechtsnachfolger hiervon zugeordnet, und welches hierin durch Bezugnahme inkorporiert wird;
    "Method and Apparatus for Transmission Framing in a Wireless Communication System" von Raymond Hsu, mit der Anwaltsanmeldenummer Nr. 010498, eingereicht gleichzeitig hiermit und dem Rechtsnachfolger hiervon zugeordnet, und welches hierin durch Bezugnahme inkorporiert wird; und
    "Method and Apparatus for Data Transport in a Wireless Communication System" von Raymond Hsu, mit der Anwaltsanmeldenummer Nr. 010499, eingereicht gleichzeitig hiermit und dem Rechtsnachfolger hiervon zugeordnet, und welches hierin durch Bezugnahme inkorporiert wird; und
    "Method and Apparatus for Header Compression in a Wireless Communication System" von Raymond Hsu, mit der Anwaltsanmeldenummer Nr. 010500, eingereicht gleichzeitig hiermit und dem Rechtsnachfolger hiervon zugeordnet, und welches hierin durch Bezugnahme ausdrücklich inkorporiert wird.
  • Gebiet
  • Die vorliegende Erfindung bezieht sich auf Drahtloskommunikationssysteme, und zwar generell und speziell auf Verfahren und auf eine Vorrichtung für die Nachrichtenkomprimierung in Vorbereitung auf die Sendung in einem Drahtloskommunikationssystem.
  • Hintergrund
  • Es gibt eine erhöhte Nachfrage für paketisierte Datendienste über Drahtloskommunikationssysteme. Ein Netzwerkverbundenes (drahtgebundenes) Computersystem ist offenbart im US 6,108,706 , in dem Computerdaten und anderer Inhalt von Multi-Inhaltservern zu Multi-Clients über das Computernetzwerk überliefert werden kann, wo anstehende Ausstrahlungen bzw. Broadcasts beim Client angemeldet werden und die Clients-Instruktionen empfangen werden, wie sie die Ausstrahlungsinformation empfangen können.
  • Da traditionelle Drahtloskommunikationssysteme für Sprachkommunikationen entwickelt wurden, führt die Erweiterung, Datendienste zu unterstützen viele Herausforderungen ein. Im speziellen hat die Versorgung von unidirektionalen Diensten, wie zum Beispiel Ausstrahldienst bzw. Broadcastdienst, wo Video- und Audioinformationen zu einem Teilnehmer gestreamt bzw. befördert werden, einen einzigartigen Satz von Anforderungen und Zielen. Solche Dienste können große Bandbreitenanforderungen haben, wobei Systementwickler versuchen bzw. das Ziel haben, das Senden von Overhead-Information zu minimieren. Im EP 1 024 661 A2 ist ein Drahtlosausstrahlsystem offenbart, das ein piktographisches Hilfsprogramm anzeigt, um die Benutzer in der Leitung und dem Auswählen der Fernsehanschauoptionen und darauf bezogene Dienste zu unterstützen, wobei die Protokollstapel und -optionen etc., beim Fernsehempfänger und Sender vorbestimmt sind. Dies ist ein Weg bzw. Mittel zum Minimieren der Sendung von Overheadinformation.
  • Zusätzlich benötigt der Teilnehmer spezifische Informationen, um auf die Ausstrahlungsinformationen, wie zum Beispiel Verarbeitungsparameter und -protokolle zugreifen zu können. Beim Senden der ausstrahlungs-spezifischen Informationen existiert ein Problem, während zugleich die Verwendung von verfügbarer Bandbreite optimiert wird.
  • Deswegen gibt es einen Bedarf für ein effizientes und akkurates Verfahren zum Senden von Daten in einem Drahtloskommunikationssystem. Weiterhin gibt es einen Bedarf für ein effizientes und akkurates Verfahren zum Vorsehen von dienstspezifischen Informationen für einen Benutzer.
  • ZUSAMMENFASSUNG
  • Die Probleme, die oben angemerkt wurden, werden von der vorliegenden Erfindung gelöst, die auf Verfahren, wie in den unabhängigen Ansprüchen 1 und 6, und auf zellulare Drahtlosvorrichtungen, wie in den unabhängigen Ansprüchen 11 und 15, gerichtet ist.
  • Ausführungsbeispiele, die hierin offenbart sind, adressieren die oben genannten Bedürfnisse durch Vorsehen eines Verfahrens für die Sicherheit in einem Datenverarbeitungssystem.
  • In einem Aspekt beinhaltet in einem zellularen Drahtloskommunikationssystem, das einen Ausstrahlungsdienst unterstützt, ein Verfahren das Senden von Ausstrahlungsoverheadinformationen entsprechend einer Ausstrahlungssitzung auf einem Overheadsendungskanal von einem ersten Gerät, wobei die Ausstrahlungsoverheadinformationen Optionen in einem Protokollstapel unterstützen und Informationen, um den Ausstrahlungsdienst einzurichten und zu synchronisieren. Das Verfahren beinhaltet weiterhin das Scannen von Aus strahlungsoverheadinformationen entsprechend der Ausstrahlungssitzung auf dem Overheadsendungskanal unter Verwendung eines zweiten Geräts, das Empfangen der Ausstrahlungsoverheadinformationen auf dem zweiten Gerät, das Einstellen bzw. Tunen des zweiten Geräts durch Verwendung der empfangenen Ausstrahlungsoverheadinformationen und das Empfangen der Ausstrahlungssitzung auf einem Ausstrahlungssendungskanal auf dem zweiten Gerät.
  • Der Broadcast- bzw. Ausstrahlungsdienst wird von einem Content- bzw. Inhalteserver gesendet. Der Ausstrahlungsdienst hat einen entsprechenden Protokollstapel mit einer Anwendungsebene und einer Transportebene, wobei der Inhalteserver unabhängig die Anwendungsebenen- und die Transportebenenprotokolle steuert.
  • In einem anderen Aspekt beinhaltet ein Verfahren in einem zellularen Drahtloskommunikationssystem, das einen Ausstrahlungsdienst unterstützt, das Empfangen von Ausstrahloverheadinformationen entsprechend der Ausstrahlungssitzung auf einem Overheadsendungskanal, wobei die Ausstrahlungsoverheadinformationen Optionen in einem Protokollstapel unterstützt und Informationen, um einen Ausstrahlungsdienst einzustellen bzw. einzurichten und zu synchronisieren und das Zugreifen der Ausstrahlungssitzung auf einen Ausstrahlungssendungskanal, und die Verwendung der Ausstrahlungsoverheadinformationen, um Ausstrahlungsinhalte der Ausstrahlungssitzung zu verarbeiten.
  • In einem weiteren Aspekt, wird eine zellulare Drahtlosvorrichtung in einem Drahtloskommunikationssystem vorgesehen, einschließlich Mittel zum Empfangen von Ausstrahlungsoverheadinformationen entsprechend einer Ausstrahlungssitzung auf einem Overheadsendungskanal, wobei die Ausstrahlungsoverheadinformationen Optionen in einem Protokollstapel und Informationen unterstützen, um einen Ausstrahlungsdienst einzurichten und zu synchronisieren.
  • Die zellulare Drahtlosvorrichtung besitzt Mittel zum Zugreifen auf die Ausstrahlungssitzung auf einem Ausstrahlungssendungskanal und Mittel zur Verwendung der Ausstrahlungsoverheadinformationen, um Ausstrahlungsinhalt der Ausstrahlungssitzung zu empfangen.
  • In einem anderen Aspekt, wird eine zellulare Drahtlosvorrichtung vorgesehen einschließlich Mitteln zum Senden von Ausstrahlungsoverheadinformationen entsprechend einer Ausstrahlungssitzung auf einem Overheadsendungskanal, wobei die Ausstrahlungsoverheadinformationen Optionen in einem Protokollstapel und Informationen unterstützen, um einen Ausstrahlungsdienst einzurichten und zu synchronisieren, wobei die zellulare Drahtlosvorrichtung weiterhin Mittel beinhaltet, und zwar zum Senden der Ausstrahlungsoverheadinformationen zu einem zweiten Gerät, Mittel zum Vorsehen des zweiten Geräts mit Zugriff auf die Ausstrahlungssitzung auf dem Ausstrahlungssendungskanal, und Mittel zum Senden des Ausstrahlungsinhalts der Ausstrahlungssitzung zu dem zweiten Gerät.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Diagramm eines Spreizspektrumkommunikationssystems, das eine Anzahl von Benutzern unterstützt.
  • 2 ist ein Blockdiagramm des Kommunikationssystems, das Ausstrahlungssendungen unterstützt.
  • 3 ist ein Modell des Protokollstapels entsprechend einer Ausstrahlungsdienstoption in einem Drahtloskommunikationssystem.
  • 4 ist eine Tabelle von Protokollen angewandt auf Ebenen eines Protokollstapels, der eine Ausstrahlungsdienstoption in einem Drahtloskommunikationssystem unterstützt.
  • 5 ist ein Flussdiagramm zum Zugreifen auf einen Ausstrahlungsdienst in einer Drahtloskommunikationssystemstopologie.
  • 6 ist ein Ausstrahlungsstrom bzw. -stream in einem Drahtloskommunikationssystem.
  • 7 ist eine Headerkomprimierungsabbildung in einem Drahtloskommunikationssystem.
  • 8 ist eine periodische Ausstrahlung der Headerkomprimierungsinformation.
  • 9 ist ein Headerkomprimierungsprotokoll.
  • 10 ist ein Headerkomprimierungsprotokoll für einen Ausstrahlungsdienst in einem Drahtloskommunikationssystem.
  • 11 ist ein Flussdiagramm der Headerkomprimierung für einen Ausstrahlungsdienst in einem Drahtloskommunikationssystem.
  • 12 ist ein Flussdiagramm der Headerdekomprimierung für einen Ausstrahlungsdienst in einem Drahtloskommunikationssystem.
  • 13 und 14 stellen Datentransport in einem Drahtloskommunikationssystem dar.
  • 15 ist ein Zeitdiagramm von einem Nachrichtenfluss in einem Drahtloskommunikationssystem.
  • 16 ist eine Systemoverheadparameternachrichtenkonfiguration.
  • 17 ist ein Block von einer Bitssystemoverheadparameternachrichtenkonfiguration.
  • 18 ist ein Flussdiagramm zum Vorsehen von Ausstrahlungsprotokollen und Parameter in einem Drahtloskommunikationssystem.
  • 19 ist eine Abbildung der Dienstoptionszahlen auf Parametersätze.
  • 20 stellt eine Parameterdefinition in einem Drahtloskommunikationssystem dar.
  • 21 ist ein Blockdiagramm von Kanälen, die für ein Drahtloskommunikationssystem, das Ausstrahlungsdienste unterstützt, benutzt wird.
  • 22 ist ein Ausstrahlungsstream mit Overheadinformationen verschachtelt mit Ausstrahlungsinhalt.
  • 23 ist ein Verfahren zum Zugreifen auf einen Ausstrahlungsdienst in einem Drahtloskommunikationssystem.
  • 24 ist ein Speicherelement zum Speichern von Ausstrahlungsoverheadinformationen.
  • DETAILLIERTE BESCHREIBUNG
  • Das Wort "beispielhaft" wird hierin ausschließlich dafür benutzt, um auf "ein Beispiel, Version oder Darstellung" hinzudeuten. Jedes Ausführungsbeispiel, das hierin als "beispielhaft" beschrieben wird, soll nicht notwendigerweise als bevorzugt oder vorteilhaft gegenüber anderen Ausführungsbeispiele interpretiert werden. Während die mannigfaltigen Aspekte der vorliegenden Erfindung in Zeichnungen präsentiert sind, sind die Zeichnungen nicht notwendigerweise maßstabsgerecht gezeichnet, außer wenn es speziell angezeigt ist bzw. darauf hingewiesen wurde.
  • Ein beispielhaftes Ausführungsbeispiel eines Drahtloskommunikationssystems verwendet ein Verfahren der Headerkomprimierung, das die Größe jedes Headers reduziert, während den Genauigkeits- und Sendeanforderungen des Systems genüge getan wird. Das beispielhafte Ausführungsbeispiel unterstützt einen unidirektionalen Ausstrahlungsdienst. Der Ausstrahlungsdienst sieht Video- und/oder Audioströme für mehrere Benutzer vor. Teilnehmer des Ausstrahlungsdienst "wählen sich in" einen designierten Kanal ein, um auf die Ausstrahlungssendung bzw. -übertragung zuzugreifen. Da die Bandbreitenanforderung für Hochgeschwindigkeitssendung von Videoausstrahlungen groß ist, ist es wünschenswert die Größe jeglichen Overheads assoziiert mit einer solchen Ausstrahlungssendung zu reduzieren.
  • Die folgende Diskussion entwickelt das beispielhafte Ausführungsbeispiel zuerst durch generelles Präsentieren eines Spreizspektrumdrahtloskommunikationssystems. Als nächstes wird der Ausstrahlungsdienst eingeführt, wobei der Dienst als High Speed Broadcast Service (HSBS) bezeichnet wird und die Diskussion beinhaltet Kanalzuweisungen des beispielhaften Ausführungsbeispiels. Ein Subskriptionsmodell wird anschließend präsentiert, und zwar einschließlich bezahlte Subskriptionen, freie Subskriptionen und hybride Subskriptionspläne, ähnlich zu denen die momentan für Fernsehsendungen verfügbar sind. Die speziellen Dinge für das Zugreifen auf den Ausstrahlungsdienst werden anschließend detailliert dargestellt, wobei sie die Verwendung einer Dienstoption präsentieren, um die speziellen Dinge einer vorhandenen Sendung zu definieren. Der Nachrichtenfluss in dem Ausstrahlungssystem wird bezüglich der Topologie des Systems, d.h., die Infrastrukturelemente, diskutiert. Zuletzt wird die Headerkomprimierung, die in dem beispielhaften Ausführungsbeispiel benutzt wird, diskutiert.
  • Es sei angemerkt, dass das beispielhafte Ausführungsbeispiel als ein Beispiel durchgehend in dieser Diskussion vorgesehen ist, jedoch, alternative Ausführungsbeispiele können mannigfaltige Aspekte einbauen bzw. inkorporieren ohne von dem Schutzumfang der vorliegenden Erfindung abzuweichen. Speziell ist die vorliegende Erfindung anwendbar auf ein Datenverarbeitungssys tem, ein Drahtloskommunikationssystem, ein unidirektionales Ausstrahlungssystem und jegliche andere Systeme, die effiziente Sendung von Informationen wünschen.
  • Drahtloskommunikationssystem
  • Das beispielhafte Ausführungsbeispiel wendet ein Spreizspektrumdrahtloskommunikationssystem an, das einen Ausstrahlungsdienst unterstützt. Drahtloskommunikationssysteme sind weit verbreitet, um mannigfaltige Typen von Kommunikation, wie zum Beispiel Sprache, Daten usw. vorzusehen. Diese Systeme können auf Codemultiplex-Vielfachzugriff (CDMA = Code Division Multiple Access), Zeitmultiplex-Vielfachzugriff (TDMA = Time Division Multiple Access) oder auf einigen anderen Modulationstechniken basieren. Ein CDMA-System sieht gewisse Vorteile gegenüber andere Typen von System vor, einschließlich der erhöhten Systemkapazität.
  • Ein System kann entwickelt werden, um einen oder mehrere Standards zu unterstützten, wie zum Beispiel der "TIA/EIA/IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" hierin bezeichnet als IS-95-Standard, der Standard, der von einem Konsortium mit dem Namen "3rd Generation Partnership Project" hierin bezeichnet als 3GPP angeboten wird und ausgeführt in einem Satz von Dokumenten einschließlich der Dokumentnummern 3G TS 25.211, 3G TS 25.212, 3G TS 25.213 und 3G TS 25.214, 3G TS 25.302, bezeichnet hierin als der W-CDMA-Standard, der Standard der von einem Konsortium mit dem Namen "3rd Generation Partnership Project 2" hierin bezeichnet als 3GPP2 angeboten wird und TR-45.5 hierin bezeichnet als der Cdma2000-Standard, wobei dieser früher IS-2000 MC genannt wurde. Diese Standards, die vorangehend hierin zitiert wurden, werden hiermit ausdrücklich hierin durch Bezugnahme aufgenommen.
  • Jeder Standard definiert speziell die Verarbeitung von Daten für die Sendung von der Basisstation zum Handy bzw. Mobiltelefon und anders rum. Als ein beispielhaftes Ausführungsbeispiel betrachtet die folgende Diskussion ein Spreizspektrumkommunikationssystem, das mit dem Cdma2000-Standardprotokollen konsistent ist. Alternative Ausführungsbeispiele können andere Standards einbauen. Dennoch können andere Ausführungsbeispiele die Komprimierungsverfahren, die hierin offenbart werden, auf andere Typen von Datenverarbeitungssystemen anwenden.
  • 1 dient als ein Beispiel eines Kommunikationssystems 100, das eine Anzahl von Benutzern unterstützt und in der Lage ist zum Implementieren von wenigstens einigen Aspekten und Ausführungsbeispielen der Erfindung. Jegliche von einer Vielzahl von Algorithmen und Verfahren können benutzt werden, um Sendungen im System 100 zu planen bzw. einzuteilen. System 100 sieht Kommunikation für eine Anzahl von Zellen 102A bis 102G vor, wobei jedes von diesen von einer entsprechenden Basisstation 104A bzw. 104G bedient wird. In den beispielhaften Ausführungsbeispielen haben einige der Basisstationen 104 mehrere Empfangsantennen und andere haben nur eine Empfangsantenne. Auf ähnliche Weise haben einige der Basisstationen 104 mehrere Sendeantennen und andere haben einzelne Sendeantennen. Es gibt keine Restriktionen für die Kombinationen der Sendeantennen und Empfangsantennen. Deswegen ist es möglich für eine Basisstation 104 mehrere Sendeantennen und eine einzelne Empfangsantenne zu haben, oder mehrere Empfangsantennen und eine einzelne Sendeantenne zu haben, oder beides, eine einzelne oder mehrere Sende- und Empfangsantennen.
  • Endgeräte 106 in dem Abdeckungsbereich können fixiert sein (d.h. stationär) oder mobil. Wie in 1 gezeigt, sind mannigfaltige Endgeräte 106 über das System verteilt. Jedes Endgerät 106 kommuniziert mit wenigstens einer und möglicherweise mehr Basisstationen 104 auf dem Downlink und Uplink zu jederzeit abhängig von zum Beispiel ob Softhandoff angewendet wird oder ob das Endgerät entwickelt wurde und operiert (gleichzeitig oder sequentiell), um mehrere Sendungen von mehreren Basisstationen zu empfangen. Softhandoff ist in CDMA-Kommunikationssystemen auf dem Fachgebiet bekannt und wird im Detail im U.S. Patent Nr. 5,101,501 mit dem Titel "Method and System for providing a Soft Handoff in a CDMA Cellular Telephone System" beschrieben, das dem Rechtsnachfolger der vorliegenden Erfindung zugeordnet ist.
  • Der Downlink bzw. die Abwärtsverbindung bezieht sich auf die Sendung von der Basisstation zum Endgerät und der Uplink bzw. die Aufwärtsverbindung bezieht sich auf die Sendung vom Endgerät zur Basisstation. In dem beispielhaften Ausführungsbeispiel haben einige der Endgeräte 106 mehrere Empfangsantennen und andere haben nur eine Empfangsantenne. In 1 sendet die Basisstation 104A Daten zu den Endgeräten 106A und 106J, und zwar auf dem Downlink, die Basisstation 104B sendet Daten zu den Endgeräten 106B und 106J, die Basisstation 104C sendet Daten zum Endgerät 106C, usw.
  • Erhöhter Bedarf von Drahtlosdatensendung und die Ausweitung von Diensten verfügbar über Drahtloskommunikationstechnologie haben zur Entwicklung von spezifischen Datendiensten geführt. Ein solcher Dienst wird als High Data Rate bzw. Hochdatenrate (HDR) bezeichnet. Ein beispielhafter HDR-Dienst ist im "EIA/TIA-IS856 Cdma2000 High Rate Packet Data Air Interface Specification" vorgeschlagen, der als "die HDR-Spezifikation" bezeichnet wird. HDR-Dienst ist generell eine Überlagerung auf ein Sprachkommunikationssystem, das ein effizientes Verfahren zum Senden von Datenpaketen in einem Drahtloskommunikationssystem vorsieht. Da die Menge der Daten, die gesendet werden, und die Anzahl der Sendungen sich erhöhen, wird die begrenzte Bandbreite, die für Funksendungen verfügbar ist, eine kritische Ressource. Deswegen gibt es einen Bedarf für ein effizientes und faires Verfahren zum Planen von Sendungen in einem Kommunikationssystem, das die Verwendung von verfügbarer Bandbreite optimiert. In dem beispielhaften Ausführungsbeispiel, ist das System 100, das in 1 dargestellt ist, konsistent mit einem CDMA-Typsystem mit einem HDR-Dienst.
  • Hochgeschwindigkeitsausstrahlungssystem (HSBS = high speed broadcast system)
  • Ein Drahtloskommunikationssystem 200 ist in 2 dargestellt, wobei Video- und Audioinformationen zum paketisierten Datendienstnetzwerk (PDSN = Packetized Data Service Network) 202 geliefert wird. Die Video- und Audio informationen können von einer im Fernsehen gezeigten Programmierung oder einer Funksendung sein. Die Informationen werden als paketisierte Daten, wie zum Beispiel als IP-Pakete geliefert. Das PDSN 202 verarbeitet die IP-Pakete zur Verteilung innerhalb eines Zugriffsnetzwerks (AN = Access Network). Wie dargestellt, wird das AN als die Teile des Systems einschließlich einer BS 204 in Kommunikation mit mehreren MS 206 definiert. Das PDSN 202 ist an die BAS 204 gekoppelt. Für HSBS-Dienst empfängt die BS 204 den Strom von Informationen von dem PDSN 202 und liefert die Informationen auf einem designierten Kanal zu den Teilnehmern innerhalb des Systems 200.
  • In einem gegebenen bzw. vorhandenen Sektor gibt es einige Wege, auf den der HSBS-Ausstrahlungsdienst angewendet werden kann. Die Faktoren, die bei der Entwicklung eines Systems involviert sind, beinhalten, sind aber nicht begrenzt darauf, die unterstützte Anzahl von HSBS-Sitzungen, die Anzahl von Frequenzzuweisungen und die Anzahl von unterstützten physikalischen Ausstrahlungskanälen.
  • Das HSBS ist ein Strom von Informationen vorgesehen über ein Luftinterface in einem Drahtloskommunikationssystem. Der "HSBS-Kanal" bezieht sich auf eine einzelne logische HSBS-Ausstrahlungssitzung, wie durch den Ausstrahlungsinhalt definiert. Es sei angemerkt, dass der Inhalt eines gegebenen bzw. vorhandenen HSBS-Kanals sich mit der Zeit ändern kann, zum Beispiel, 7 Uhr-Nachrichten, 8 Uhr-Wetter, 9 Uhr-Spielfilme, etc. Die zeitbasierte Planung ist analog zu einem Einzelnen TV-Kanal. Der "Ausstrahlungskanal" bezieht sich auf einen einzelnen physikalischen Vorwärtsverbindungskanal, d.h., einem gegebenen Walsh-Code, der Ausstrahlungsverkehr trägt. Der Ausstrahlungskanal, BCH bzw. broadcast channel, entspricht einem einzelnen CDM-Kanal.
  • Ein einzelner Ausstrahlungskanal kann einen oder mehrere HSBS-Kanäle tragen. In diesem Fall werden die HSBS-Kanäle nach Art eines Zeitmultiplex-Vielfach (TDM = Time Division Multiplex), in dem einzelnen Ausstrahlungskanal gemultiplext. In einem Ausführungsbeispiel ist ein einzelner HSBS-Kanal auf mehr als einen Ausstrahlungskanal in einem Sektor vorgesehen. In einem anderen Ausführungsbeispiel ist ein einzelner HSBS-Kanal auf verschiedenen Frequenzen vorgesehen, um Teilnehmer in diesen Frequenzen zu bedienen.
  • Gemäß einem beispielhaften Ausführungsbeispiel unterstützt das System 100, das in 1 dargestellt ist, einen Hochgeschwindigkeitsmultimediaausstrahlungsdienst, der als Hochgeschwindigkeitsausstrahlungsdienst (HSBS = High Speed Broadcast Service) bezeichnet wird. Die Ausstrahlungsfähigkeiten des Dienstes sind dazu gedacht, um Programmierung bei einer Datenrate, die hoch genug ist, um Video- und Audiokommunikationen zu unterstützen, vorzusehen. Als ein Beispiel können Anwendungen des HSBS-Videostreaming von Filmen, Sportereignissen, etc. beinhalten. Der HSBS-Dienst ist ein Paketdatendienst basierend auf dem Internetprotokoll (IP).
  • Gemäß dem beispielhaften Ausführungsbeispiel wird ein Dienstanbieter als ein Inhalteserver (CS = Content Server) bezeichnet, wobei der CS, die Verfügbarkeit von solchem Hochgeschwindigkeitsausstrahlungsdienst bei den Systembenutzern bewirbt. Jeglicher Benutzer, der es wünscht, den HSBS-Dienst zu empfangen, kann sich bei dem CS anmelden. Der Teilnehmer ist anschließend dazu in der Lage die Ausstrahlungsdienstplanung auf eine Vielfalt von Wegen, die von dem CS vorgesehen werden können, zu scannen. Der Ausstrahlungsinhalt kann zum Beispiel über Werbungen, Kurzmanagementsystemnachrichten (SMS), Drahtlosanwendungsprotokoll (WAP = Wireless Application Protocoll) und/oder einige andere Mittel, die generell konsistent mit und sinnvoll für Mobildrahtloskommunikationen, kommuniziert werden. Mobilbenutzer werden als Mobilstationen (MSs = Mobil Stations) bezeichnet. Basisstationen (BSs) senden HSBS-bezogene Parameter in Overheadnachrichten, wie zum Beispiel solche, die auf Kanälen und/oder Frequenzen, die für die Steuerung und Information zugewiesen wurden, d.h., Nicht-Nutzlastnachrichten, gesendet werden. Nutzlast bezieht sich auf den Informationsinhalt der Sendung, wobei eine Ausstrahlungssitzung die Nutzlast der Ausstrahlungsinhalte, d.h., das Videoprogramm, etc., ist. Wenn ein Ausstrahlungsdienstteilnehmer wünscht, eine Ausstrahlungssitzung, d.h., ein bestimm tes geplantes Ausstrahlungsprogramm zu empfangen, liest die MS die Overheadnachrichten und lernt die passenden bzw. geeigneten Konfigurationen. Die MS tuned bzw. stellt sich anschließend auf die Frequenz, die den HSBS-Kanal enthält, ein und empfängt den Ausstrahlungsdienstinhalt.
  • Die Kanalstruktur des beispielhaften Ausführungsbeispiels ist konsistent mit dem Cdma2000-Standard, wobei der Vorwärtszusatzkanal (F-SCH = Forward Supplemental Channel) Datensendungen unterstützt. Ein Ausführungsbeispiel bündelt eine große Anzahl von Vorwärtsfundamentalkanälen (F-FCHs = Forward Fundamental Channels) oder die Vorwärts dedizierten Steuerkanäle (F-DCCHs = Forward Dedicated Control Channels), um höhere Datenratenanforderungen von Datendiensten zu erreichen. Das beispielhafte Ausführungsbeispiel verwendet einen F-SCH als Basis für den F-BSCH, um eine Nutzlast von 64-kbps (ausschließlich RTP-Overhead) zu unterstützen. Der F-BSCH kann ebenso modifiziert werden, um andere Nutzlastraten zu unterstützen, zum Beispiel, durch Unterteilen der 64-kpbs-Nutzlastrate in Unterströme mit niedrigeren Raten.
  • Ein Ausführungsbeispiel unterstützt ebenso Gruppenanrufe auf mehrere verschiedene Wege. Zum Beispiel, durch Verwenden von existierenden Unicast-Kanälen, d.h., einen Vorwärtsverbindungskanal pro MS, der nicht geteilt wird, von F-FCH (oder der F-DCCH) auf beiden, Vorwärts- und Rückwärtsverbindungen. In einem anderen Beispiel werden der F-SCH (geteilt von den Gruppenmitgliedern in dem gleichen Sektor) und dem F-DCCH (keine Rahmen, aber der Vorwärtsleistungssteuersubkanal fast zur ganzen Zeit) auf der Vorwärtsverbindung und der R-DCCH auf der Rückwärtsverbindung angewendet. In noch einem anderen Beispiel wird der hochratige F-BSCH auf der Vorwärtsverbindung und der Zugriffskanal (oder der erweiterte Zugriffskanal/Rückwärtsgemeinsamkeitssteuerkanalkombination) auf der Rückwärtsverbindung verwendet.
  • Mit einer hohen Datenrate kann der F-BSCH des beispielhaften Ausführungsbeispiels einen sehr großen Teil der Vorwärtsverbindungsleistung einer Ba sisstation benutzen, um adäquate Abdeckung vorzusehen. Die physikalische Ebenenentwicklung des HSBC ist somit fokussiert auf effiziente Verbesserungen in einer Ausstrahlungsumgebung.
  • Um adäquate Unterstützung für Videodienste vorzusehen, betrachtet die Systementwicklung die benötigte Basisstationsleistung für verschiedene Wege, um den Kanal, wie auch die entsprechende Videoqualität zu senden. Ein Aspekt der Entwicklung ist ein subjektiver Tradeoff bzw. Abstimmung zwischen der wahrgenommenen Videoqualität an der Grenze des Abdeckungsbereichs und die nahe zum Zellstandort. Indem die Nutzlastrate reduziert wird, wird die effektive Fehlerkorrekturcoderate erhöht, ein gegebener Pegel einer Basisstationssendeleistung würde besseren Abdeckungsbereich an der Grenze der Zelle vorsehen. Für Mobilstationen, die näher zu den Basisstationen platziert sind, bleibt der Empfang des Kanals fehlerfrei und die Videoqualität würde gesenkt werden wegen der gesenkten Quellenrate. Die gleiche Abstimmung betrifft ebenso andere, nicht Videoanwendungen, die den F-BSCH unterstützen können. Das Senken der Nutzlastrate, die von dem Kanal unterstützt wird, erhöht den Abdeckungsbereich mit dem Nachteil der verminderten Downloadgeschwindigkeit für diese Anwendungen. Die Balance der relativen Wichtigkeit zwischen Videoqualität und Datendurchsatz gegenüber Abdeckungsbereich ist objektiv. Die gewählte Konfiguration sucht eine anwendungsspezifische optimierte Konfiguration und einen guten Kompromiss unter allen Möglichkeiten.
  • Die Nutzlastrate für den F-BSCH ist ein wichtiger Entwicklungsparameter. Die folgenden Annahmen können beim Entwickeln eines Systems, das Ausstrahlungssendungen gemäß dem beispielhaften Ausführungsbeispiel unterstützt, benutzt werden: (1) die Zielnutzlastrate ist 64 kbps, (2) für das Streaming von Videodiensten wird angenommen, dass die Nutzlastrate 12 8-bitbytes pro Paketoverhead der RTP-Pakete beinhaltet; (3) der durchschnittliche Overhead für alle Ebenen zwischen RTP und der physikalischen Ebene ist näherungsweise 64, 8-bit bytes pro Paket plus 8 bits pro F-SCH-Rahmenoverhead, der vom MUXPDU-Header benutzt wird.
  • In dem beispielhaften Ausführungsbeispiel ist die maximale unterstützte Rate für Nichtvideoausstrahlungsdienste 64 kbps. Viele andere mögliche Nutzlastraten unter 64 kbps sind jedoch ebenso erreichbar.
  • Subskriptionsmodell
  • Es gibt mehrere mögliche Subskriptions-/Einnahmemodelle für den HSBS-Dienst, einschließlich freier Zugriff, gesteuerter Zugriff und teilweise gesteuerter Zugriff. Für freien Zugriff ist keine Subskription notwendig, um den Dienst zu empfangen. Die BS strahlt den Inhalt ohne Verschlüsselung aus und interessierte Handys bzw. Mobilfunkgeräte können den Inhalt empfangen. Das Einkommen für den Dienstanbieter kann über Werbungen generiert werden, die ebenso in dem Ausstrahlungskanal gesendet werden können. Anstehende Filmclips können zum Beispiel gesendet werden, wobei die Filmgesellschaften hierfür den Dienstanbieter bezahlen werden.
  • Für gesteuerten Zugriff melden sich die MS-Benutzer beim Dienst an und zahlen die entsprechende Gebühr, um den Ausstrahlungsdienst zu empfangen. Nicht angemeldete Benutzer sind nicht in der Lage, den HSBS-Dienst zu empfangen. Gesteuerter Zugriff kann erreicht werden durch das Verschlüsseln der HSBS-Sendung/-Inhalt, sodass nur der angemeldete Benutzer den Inhalt entschlüsseln kann. Dies kann Über-die-Luftverschlüsselungsschlüsselausstauschprozeduren benutzen. Dieses Schema sieht eine große Sicherheit vor und vermeidet Diebstahl-des-Dienstes (theft-of-service).
  • Ein hybrides Zugriffschema, das als teilweise gesteuerter Zugriff bezeichnet wird, liefert den HSBS-Dienst als einen Subskriptionsbasierten Dienst, der mit dazwischen liegenden unentschlüsselten Werbesendungen verschlüsselt ist. Diese Werbungen können dazu gedacht sein, zu Subskriptionen zum Verschlüsselten HSBS-Dienst anzuregen. Planung dieser unverschlüsselten Segmente könnte der MS bekannt sein, und zwar über externe Mittel.
  • HSBS-Dienstoption
  • Die HSBS-Dienstoption ist definiert durch: (1) einem Protokollstapel; (2) Optionen in dem Protokollstapel; und (3) Prozeduren zum Einstellen und Synchronsieren des Dienstes. Der Protokollstapel gemäß dem beispielhaften Ausführungsbeispiel ist in den 3 und 4 gezeigt. Wie in 3 gezeigt, ist der Protokollstapel spezifisch für das Infrastrukturelement, d.h., MS, BS, PDSN und CS in dem beispielhaften Ausführungsbeispiel.
  • Weiter mit 3, spezifiziert das Protokoll für die Anwendungsebene der MS, den Audiocodec, den optischen Codec, wie auch jegliche optische Profile. Zusätzlich spezifiziert das Protokoll die Funktransportprotokollnutzlasttypen (RTP = Radio Transport Protocol), wenn RTP benutzt wird. Für die Transportebene des MS spezifiziert das Protokoll einen Benutzerdatagrammprotokollport (UDP = User Datagram Protocol), der benutzt werden soll, um die RTP-Pakete zu tragen. Die Sicherheitsebene der MS ist spezifiziert durch das Protokoll, wobei die Sicherheitsparameter über bandexterne Kanäle vorgesehen werden, wenn die Sicherheitszuweisung ursprünglich von dem CS aufgebaut wurde. Die Verbindungsebene spezifiziert die IP-Headerkomprimierungsparameter.
  • Um den Mobilstationen zu ermöglichen, die Ausstrahlungskanäle erfolgreich aufzuspüren und zu hören, werden verschiedene ausstrahlungsdienstbezogene Parameter über das Luftinterface gesendet. Der Ausstrahlungsdienst ist entwickelt, um verschiedene Protokolloptionen in dem Protokollstapel zu unterstützen. Das benötigt, dass der Empfänger des Ausstrahlungsdiensts von den Protokolloptionen, die gewählt wurden, informiert wird, um richtiges Dekodieren und Verarbeiten der Ausstrahlung zu vereinfachen. In einem Ausführungsbeispiel liefert der CS diese Information zum Empfänger als eine Overhead-Systemparameternachricht, die konsistent ist mit dem Cdma2000-Standard. Der Vorteil für den Empfänger ist die Fähigkeit, die Information sofort von der Overheadnachricht zu empfangen. Auf diesem Weg kann der Empfänger sofort bestimmen, ob der Empfänger genügend Ressourcen hat, um die Ausstrahlungssitzung zu empfangen. Der Empfänger überwacht die Overhead-Systemparameternachrichten. Das System kann eine Dienstoptionsnummer entsprechend einem Satz von Parametern und Protokollen implementieren, wobei die Dienstoptionsnummer in der Overheadnachricht vorgesehen ist. Als Alternative kann das System einen Satz von Bits oder Flags vorsehen, um die gewählten verschiedenen Protokolloptionen anzuzeigen. Der Empfänger bestimmt anschließend die Protokolloptionen für das richtige Dekodieren der Ausstrahlungssitzung.
  • Der Ausstrahlungskanal ist ein physikalischer Kanal, der definiert ist, Ausstrahlungsverkehr zu tragen. Es gibt mehrere mögliche physikalische Ebenenformate, die für einen vorhandenen Ausstrahlungskanal benutzt werden können, und deswegen benötigen die Mobilstationsempfänger Informationen über diese Parameter, um die physikalische Sendung des Ausstrahlungskanals erfolgreich zu decodieren. Speziell jeder Ausstrahlungskanal, HSBS-Kanal hat einen einzigartigen Identifikator in dem System. Zusätzlich weist die BS jedem HSBS-Kanal einen Ausstrahlungsdienstpräferenzidentifikator zu, wobei die Basisstation das Feld entsprechend der aktuellen Ausstrahlungsdienstsitzung setzt. Der Ausstrahlungsdienst wird anschließend Informationen für jeden HSBS-Kanal senden, und zwar einschließlich: dem Ausstrahlungskanalidentifikator und dem Ausstrahlungsdienstreferenzidentifikator.
  • Weiterhin kann der Ausstrahlungskanal verschiedene Kombinationen von höheren Ebenenprotokollen inkorporieren bzw. einbauen, und zwar basierend auf dem Typ des Inhalts, der geliefert werden wird. Der mobile Empfänger benötigt ebenso Informationen bezogen auf diese Protokolle der höheren Ebene zur Interpretation der Ausstrahlungssendungen. Gemäß einem Ausführungsbeispiel wird der Protokollstapel über bandexterne bzw. out-of-band Verfahren kommuniziert, wobei das bandexterne Verfahren die Sendung von Informationen über einen separaten Kanal unterschiedlich zu dem Ausstrahlungskanal anzeigt. Mit diesem Ansatz wird die Beschreibung des Protokollstapels der höheren Ebene nicht über den Ausstrahlungskanal oder Overheadsystemparameterkanal gesendet.
  • Wie hierin oben diskutiert, definiert die Dienstoption den Protokollstapel und die Prozeduren, die für das Operieren des Ausstrahlungsdiensts benutzt werden. Konsistent mit einem unidirektionalen Dienst ist der Ausstrahlungsdienst charakterisiert durch Protokolloptionen, die unter mehreren Ausstrahlungsempfängern gemeinsam ist. In dem beispielhaften Ausführungsbeispiel werden die Protokolloptionen für den Ausstrahlungsdienst nicht zwischen der Mobilstation und dem Netzwerk ausgehandelt. Die Optionen sind vorbestimmt vom Netzwerk und werden zur Mobilstation geliefert. Da der Ausstrahlungsdienst ein unidirektionaler Dienst ist, unterstützt der Ausstrahlungsdienst keine Anfragen von der Mobilstation. Das Konzept des Ausstrahlungsdiensts ist eher ähnlich zu einer Fernsehsendung, wobei die Empfänger sich in den Ausstrahlungskanal einwählen und auf die Ausstrahlungssendung unter Verwendung der Parameter spezifiziert durch den CS zugreifen.
  • Um zu vermeiden, Koordination zu benötigen, und zwar zwischen dem Drahtlosnetzwerk und dem CS, kann der Dienst bandexterne Kanäle zum Senden der Information zur Mobilstation mit Bezug auf die Protokolloptionen über der IP-Netzwerkebene benutzen. 15 stellt einen Ausstrahlungsfluss dar, und zwar gemäß einem Ausführungsbeispiel. Die horizontale Achse stellt die Topologie des Systems, d.h. die Infrastrukturelemente dar. Die vertikale Achse stellt die Zeitlinie dar. Zur Zeit t1 greift die MS auf den bandexternen Kanal über die BS zu. Es sei angemerkt, dass die MS auf das Netzwerk durch Auswählen einer Paketdatendienstoption, wie zum Beispiel durch Verwenden eines dedizierten Paketdatendienstoptionskanals zugewiesen als SO 33 zugreifen kann. Auf effektive Weise wählt die MS eine Paketdatendienstoption, um eine Realzeit-Streamingprotokollsitzung (RTSP = Real Time Streaming Protocol) mit dem CS aufzubauen. Die MS fordert eine Beschreibung der Anwendung und der Transportprotokolle, die für den Ausstrahlungsstream bzw. – strom des CS zur Zeit t3 benutzt wird, an. Es sei angemerkt, dass zusätzlich zu der Verwendung von RTSP, ebenso das Sitzungsinitiierungsprotokoll (SIP = Session Initiation Protocol) benutzt werden kann, um die Beschreibung der Anwendung und der Transportprotokolle anzufordern. Die Beschreibung wird über das Sitzungsbeschreibungsprotokoll (SDP = Session Description Protocol) zur Zeit t4 übertragen bzw. getragen. Die Sendung des Protokolls kann durchgeführt werden, und zwar während der Benutzer auf den Ausstrahlungsdienst zugreift. Es sei angemerkt, dass RTSP und STP standardisierte Ansätze zum Aufbauen eines unidirektionalen Streamingdienstes im IETF und in 3GPP2 sind. Die Mobilstation wird ebenso einem Paketdatendienst benutzen, um die PDSN anzufordern, um das Ausstrahlungsdienstheaderkomprimierungsprotokoll zu identifizieren und um jegliche Komprimierungsinitialisierungsinformation zur Mobilstation zur Zeit t2 weiterzuleiten. In einem Ausführungsbeispiel wird das Internetprotokollsteuerungsprotokoll IPCP benutzt, um die Headerkomprimierungsinformationen mit der Mobilstation auszutauschen. Auf ähnliche Weise kann dieser gleiche Mechanismus ausgebaut werden, um Informationen für den Ausstrahlungsstrom bzw. -stream vorzusehen. Wenn die Ausstrahlungsdienstprotokolloptionen sich ändern, benötigt die Mobilstation einen Hinweis. Ein Ausführungsbeispiel wendet einen Sicherheitsparameterindex (SPI = Security Parameters Index) an, um anzuzeigen, wenn sich Protokolloptionen geändert haben können. Wenn sich die Protokolloptionen als ein Resultat der Verwendung eines unterschiedlichen CS für das System ändern, oder die Mobilstation sich in ein unterschiedliches System bewegt, wird sich der SPI automatisch ändern, weil sich die Quellen-IP-Adresse des CS ändert. Weiterhin, wenn der CS sich nicht ändert und der gleiche mit verschiedenen Protokolloptionen benutzt wird, wird der CS benötigt werden, den SPI zu ändern, um anzuzeigen, dass die Parameter sich geändert haben. Wenn die Mobilstation den neuen SPI detektiert, wird es die neue Protokollbeschreibung durch Einrichten eines Paketdatendienstanrufs und Kontaktieren des PDSN und CS, deren IP-Adresse in dem SPI enthalten ist, erlangen.
  • In einem Ausführungsbeispiel wendet der SPI-Ansatz mehrere Kriterien an. Erstens, ein einzelner CS benutzt die gleichen Protokolloptionen für nachfolgende bzw. aufeinander folgende Streamingsitzungen, sonst modifiziert der CS den SPI, wenn sich die Protokolloptionen ändern. Zweitens, das PDSN ändert den Headerkomprimierungsalgorithmus oder die Parameter nicht zwischen den Streamingsitzungen mit dem gleichen SPI.
  • Die Änderung der Protokolloptionen in einem gegebenen System löst bei mehreren Mobilstationen aus, einen Paketdatendienstanruf einzustellen, um die aktualisierten Protokollbeschreibungen abzurufen. Zufallsartige Anrufseinstellungsverzögerungen sollten eingeführt werden, um zu vermeiden, dass das System von diesen Anrufursprüngen überladen wird. Inhalteserver können einiges an Verzögerung zwischen der Zeit, bei der der SPI geändert wird und der Zeit, bei der der Inhaltestrom beginnt, einführen, um allen Benutzern zu erlauben, die Protokolloptionen abzufragen.
  • Im Gegensatz dazu können die Ausstrahlungskanalprotokolle und -parameter zur Mobilstation gesendet werden. In einem alternativen Ausführungsbeispiel wird eine Serviceoptionsnummer (SO = Service Option) für jeden Satz von Ausstrahlungsprotokollen und -parametern zugewiesen, wobei die SO-Nummer zu mehreren Empfängern gesendet wird. In einer Abwandlung davon wird die Parameterinformation direkt zu den vielfachen Empfängern als eine Vielzahl von kodierten Feldern gesendet. Das vorherige Verfahren zum Identifizieren von Ausstrahlungsprotokollen und -parametern durch die SO-Nummer, inkorporiert eine Ausstrahlungsdienstparameternachricht (BSPM = Broadcast Service Parameters Message). Diese BSPM ist eine Overheadnachricht spezifisch für den Ausstrahlungsdienst. Diese Mobilstationen, die wünschen, den HSBS-Dienst zu empfangen, würden die BSPM überwachen. Die BSPM ist kontinuierlich; periodisch gesendet von jedem Sektor, der einen oder mehrere Ausstrahlungskanäle konfiguriert hat.
  • Das Format der BSPM des beispielhaften Ausführungsbeispiels ist in 16 dargestellt. Die verschiedenen Parameter angezeigt in der Nachricht sind gelistet mit der Anzahl von Bits in der Nachricht für jeden zugeordnet. Der Pilot-Sequenzversatzindex ist als PILOT_PN identifiziert. Die BS setzt das PILOT_PN-Feld auf den Pilot-Sequenzversatz für die entsprechende Basisstation in Einheiten von 64-PN-Chips. Die BSPM_MSG_SEQ bezieht sich auf eine Ausstrahlungsdienstparameternachrichtsequenznummer. Wenn eine der Parameter, die in einer aktuellen BSPM identifiziert sind, sich seit der letzten Sendung der BSPM geändert hat, inkrementiert die BSSPM_CONFIG_SEQ. Die HSBS_REG_USED ist ein für eine Ausstrahlungsdienstregistrierung benutzter Anzeiger. Dieses Feld zeigt die Frequenzen, die für das Paging eines MS-Teilnehmers zum Ausstrahlungsdienst benutzt wird. Die HSBS_REG_TIME ist ein Ausstrahlungsdienstregistrierungszeitwert. Wenn das Feld HSBS_REG_USED auf '0' gesetzt wird, wird die Basisstation dieses Feld auslassen. Ansonsten beinhaltet die Basisstation dieses Feld, wobei diesen folgende Bedeutung zukommt: die BS setzt dieses Feld auf die Länge der Registrierungsdauer für die Ausstrahlungsdienstkanäle; oder die Basisstation setzt dieses Feld auf '00000', wenn die MS benötigt wird, um den HSBS-Kanal jedes Mal, wenn es startet, um einen HSBS-Kanal zu überwachen, zu registrieren.
  • Weiter mit 16, ist der NUM_FBSCH die Anzahl der Vorwärtsausstrahlungszusatzkanäle. Die BS setzt dieses Feld auf die Anzahl der Vorwärtsausstrahlungszusatzkanäle gesendet von der entsprechenden BS. Die NUM_HSBS_SESSION ist eine Anzahl der Ausstrahlungsdienstsitzungen. Die BS setzt dieses Feld auf die Anzahl der Ausstrahlungsdienstsitzungen, die von der entsprechenden BS gesendet werden. Die NUM_LPM_ENTRIES sind die Anzahl von logischen-zu-physikalischen Abbildungseinträgen. Die BS setzt dieses Feld auf die Anzahl der logischen, d.h. Ausstrahlungsdienstsitzungen, zu physikalischen, d.h. Vorwärtsausstrahlungszusatzkanal, Abbildungseinträge, die in der Nachricht getragen bzw. übertragen werden. Die BS setzt einen Vorwärtsausstrahlungszusatzkanalidentifikator (Forward broadcast supplemental channels), FBSCH_ID, entsprechend dem Vorwärtsausstrahlungszusatzkanal. Wenn das CDMA_FREQ-Feld in diesem Datensatz enthalten ist, soll die Basisstation den in der Frequenz enthaltenden Anzeiger setzen, FREQ_INCL, und zwar dieses Bit auf '1'; andererseits wird die Basisstation dieses Bit auf '0' setzen.
  • FBSCH_CDMA_FREQ ist die Frequenzzuordnung des Vorwärtsausstrahlungszusatzkanals. Wenn das FREQ_INCL-Bit auf '0' gesetzt ist, soll die Basisstation dieses Feld auslassen; andererseits setzt die Basisstation dieses Feld folgendermaßen: die Basisstation soll dieses Feld auf die CDMA-Kanalanzahl entsprechend der CDMA-Frequenzzuordnung des CDMA-Kanals, das den Vorwärtsausstrahlungszusatzkanal enthält, setzen.
  • Der FBSCH_CODE_CHAN ist ein Codekanalindex des Vorwärtsausstrahlungszusatzkanals, wobei die Basisstation dieses Feld auf den Codekanalindex, der die Mobilstation ist, um auf dem Vorwärtsausstrahlungszusatzkanal zu benutzen, setzt. Die FBSCH_RC ist eine Funkkonfiguration des Vorwärtsausstrahlungszusatzkanals, wobei die Basisstation dieses Feld auf die Funkkonfiguration setzt, die von der Mobilstation auf dem Vorwärtsausstrahlungszusatzkanal benutzt wird.
  • Die FBSCH_RATE ist die Datenrate des Vorwärtsausstrahlungszusatzkanals, wobei die Basisstation dieses Feld auf die Datenrate setzt, die auf dem Vorwärtsausstrahlungszusatzkanal benutzt wird. Die FBSCH_FRAME_SIZE ist die Rahmengröße des Vorwärtsausstrahlungszusatzkanals, wobei die Basisstation dieses Feld auf die Rahmengröße auf dem Vorwärtsausstrahlungszusatzkanal setzt. Die FBSCH_FRAME_REPEAT_IND ist der Vorwärtsausstrahlungszusatzkanalrahmenwiederholungsindikator, wobei, wenn Rahmenwiederholung auf dem Vorwärtsausstrahlungszusatzkanal benutzt wird, die Basisstation dieses Feld auf '1' setzt; andererseits setzt die Basisstation dieses Feld auf '0'.
  • Die FBSCH_SHO_SUPPORTED ist der Vorwärtsausstrahlungszusatzkanal-Softhandoff-Unterstützungsindikator, wobei, wenn die Basisstation Softhandoff auf dem Vorwärtsausstrahlungszusatzkanal mit einem oder mehreren seiner Nachbarn unterstützt, setzt die Basisstation dieses Feld auf '1'; anderenfalls, setzt die Basisstation dieses Feld auf '0'.
  • Die NUM_NGHBR ist die Anzahl der Nachbarn, die Vorwärtsausstrahlungszusatzkanal-Softhandoff unterstützen. Wenn das Feld FBSCH_SHO_SUPPORTED auf '1' gesetzt ist, dann wird die Basisstation dieses Feld auf die Anzahl der Nachbarn, die Softhandoff auf diesem Vor wärtsausstrahlungszusatzkanal unterstützten, setzen. Die NGHBR_PN ist der Nachbarpilot-PN-Sequenzversatzindex. Die Basisstation setzt dieses Feld auf den Pilot-PN-Sequenzversatz für diesen Nachbarn, und zwar in Einheiten von 64 PN-Chips. Der NGHBR_FBSCH_CODE_CHAN_INCL ist der Nachbarpilotvorwärtsausstrahlungszusatzkanalkodekanalindexbeinhaltungsanzeiger.
  • Wenn der Nachbarpilot-Vorwärtsausstrahlungs-zusatzkanalcodekanalindex in dieser Nachricht beinhaltet ist, setzt die Basisstation dieses Feld auf '1'; anderenfalls setzt die Basisstation dieses Feld auf '0'. Der NGHBR_FBSCH_CODE_CHAN ist der Nachbarpilot-Vorwärtsausstrahlungszusatzkanalcodekanalindex. Wenn das NGHBR_FBSCH_CODE_CHAN_INCL-Feld auf '0' gesetzt ist, lässt die Basisstation dieses Feld aus; andererseits beinhaltet die Basisstation dieses Feld und die Basisstation setzt dieses Feld auf den Codekanalindex, der die Mobilstation ist, um auf dem Vorwärtsausstrahlungszusatzkanal für diesem Nachbarn zu benutzen.
  • Die HSBS_ID ist ein Ausstrahlungsdienstsitzungsidentifikator, wobei die Basisstation dieses Feld auf den Identifikator entsprechend dieser Ausstrahlungsdienstsitzung setzen soll. Die BSR_ID ist ein Ausstrahlungsdienstreferenzidentifikator, wobei die Basisstation dieses Feld auf den Ausstrahlungsdienstreferenzidentifikator entsprechend dieser Ausstrahlungsdienstsitzung setzen soll. Der HSBS_ID ist der Ausstrahlungsdienstsitzungsidentifikator, wobei die BS dieses Feld auf den Identifikator entsprechend der Ausstrahlungsdienstsitzung setzen soll.
  • Die FBSCH_ID ist der Vorwärtsausstrahlungszusatzkanalidentifikator, wobei die Basisstation dieses Feld auf den Identifikator entsprechend dem Vorwärtsausstrahlungszusatzkanal auf dem die oben genannte Ausstrahlungsdienstsitzung getragen wird, setzen soll.
  • Die Protokolloptionen, die das Aushandeln zwischen dem Sender und dem Empfänger benötigen würden, werden gewählt und definiert in der Dienstoptionsbeschreibung. Die MS benützt die SO-Nummer gesendet in der BSPM, um die Protokolloptionen des Ausstrahlungsdienstes zu finden. Im Gegensatz zu einem unidirektionalen Paketdatendienst, wobei die SO die Protokolle über der IP-Netzwerkebene spezifiziert, spezifiziert der Ausstrahlungsdienst Protokolle bis zu der Anwendungsebene. Die Sicherheitsebene benutzt die Verschlüsselung und die Authentifizierungsalgorithmen, die während dem Aufbau einer Sicherheitszuweisung, zum Beispiel über bandexterne Mittel, kommuniziert werden.
  • In dem beispielhaften Ausführungsbeispiel ist die Transportebene in dem SO als das angewandte Transportprotokoll, wie zum Beispiel RTP, spezifiziert, kann nicht leicht identifiziert werden als die Nutzlast der UDP-Pakete. Der SO wird ebenso eine UDP-Portnummer für die RTP-Nutzlast spezifizieren, um diese von anderen Typen von UDP-Verkehr, die über den Ausstrahlungskanal gesendet werden können, zu unterscheiden.
  • Die Anwendungsebene wird ebenso in dem SO spezifiziert, da viele Audio- und Videocodecs (zum Beispiel MPEG-4 und EVRC) keine statische RTP-Nutzlasttypen haben, die von der Mobilstation leicht identifiziert werden. In einer unidirektionalen Ausstrahlungsanwendung sollen die RTP-Nutzlasttypen für diese Codecs über Anrufseinstellungsverhandlung bzw. Aushandlung (unter Verwendung von SIP, RTSP, etc.) dynamisch zugeordnet werden. Da der Ausstrahlungsdienst wünscht solche Aushandlungen zu vermeiden, werden die Mediendecoder von dem SO vorausgewählt. Da die Audio und visuellen Daten weiterhin in separaten RTP-Paketen getragen werden können, ist es erwünscht, dass die RTP-Nutzlasttypen spezifiziert werden, um von jedem Medienstrom benutzt zu werden.
  • In dem beispielhaften Ausführungsbeispiel spezifiziert die logisch-zu-physikalische Abbildung den HSBS-Kanal (HSBS_ID/BSR_ID), der in einem entsprechenden F-BSCH (FESCH-ID) getragen wird. Der Satz {HSBS_ID, BSR_ID, FBSCH_ID} spezifiziert vollständig (für die MS), wo ein vorhandener Ausstrahlungsdienst zu finden ist und zu hören ist. Als solches wird die logische-zu-physikalische Abbildungsinformation über die Luft zu den MSs ge sendet, sodass eine MS, die wünscht, auf einen vorhandenen HSBS-Kanal zuzugreifen, bestimmen kann, den F-BSCH-Kanal zu überwachen. Deswegen wird die folgende Information zu der Mobilstation über das Luftinterface gesendet: physikalische Ausstrahlungskanalparameter; logische Ausstrahlungskanalparameter; logisch-zu-physikalische Abbildung; und eine Option diese Ausstrahlungsdienstparameter zu signalisieren, ist die Definition einer neuen Overheadnachricht in Cdma2000, die für den Ausstrahlungsdienst spezifisch ist.
  • Ein alternatives Ausführungsbeispiel wendet die BSPM an, wobei die individuellen Parameter in einem Block von Bits gesendet werden, bezeichnet als BLOB, die wählbare Programmoptionen enthält. Anders als die Verwendung einer SO-Nummer, um einen Satz von Parametern zu identifizieren, wobei die Protokolloptionen bei der Anwendungsebene sich oft ändern, somit erneute Definition benötigen, erlaubt die Verwendung des BLOB Änderungen bei der Anwendungsebene ohne erneute Definition des gesamten Satzes von Parametern. Speziell erlaubt der BLOB die erneute Definition eines einzelnen Parameters ohne die Änderung des gesamten Satzes von Parametern. Wenn der Ausstrahlungsdienst viele verschiedene Protokolloptionen unterstützen soll, kann das Problem des Definierens von mehreren Dienstoptionen in der vorangegangenen Sektion gemildert werden, und zwar durch Definieren eines Ausstrahlungsdienst-BLOBs. Dieser BLOB wird als Teil der BSPM gesendet und identifiziert die Protokolloptionen, die für den Ausstrahlungsdienst benutzt werden. 17 stellt den Protokollstapel und die Anwendung des BLOB dar. Die Bereitstellung des BLOB sieht den Vorteil vor, das die Mobilstation die BSPM benutzt, um den Protokollstapel zu identifizieren, und deswegen werden andere bandexterne Kanäle für die Sendung dieser Informationen nicht benötigt. Zusätzlich kann die Mobilstation sofort die Fähigkeit bestimmen, um auf den Ausstrahlungsstream ohne für den Dienst sich registrieren zu müssen, zuzugreifen, um zu decodieren.
  • Ein Nachteil der Verwendung der SO und/oder der BLOB-Beschreibung ist die Verwendung der Drahtlosinfrastruktur, um die verwendeten Protokolle über die IP-Netzwerkebene zu koordinieren. Die Protokolle, die von dem CS und dem PDSN benutzt werden, müssen zu denen, die in dem BLOB definiert sind und von der Basisstation gesendet werden, übereinstimmen sein.
  • Ein Mittel zum Vorsehen von Koordination ist einen Client in der drahtlosen Infrastruktur (zum Beispiel BSC) zu haben, der die Protokolloptionsinformationen von dem CS und dem PDSN anfordert. Der BSC übersetzt anschließend diese Informationen in den entsprechenden Ausstrahlungsdienst-BLOB, der in der BSPM gesendet wird. Die Protokolle, die zwischen dem BSC-Client und dem Contentserver bzw. Inhalteserver und PDSN benutzt werden, werden auf den Standardprotokollen basieren, wie zum Beispiel die spezifiziert in Cdma2000. Der Client in dem BSC benutzt RTSP, um eine Beschreibung der Anwendung und der Transportebenen von dem CS unter Verwendung von SDP anzufordern. Der Client benutzt ebenso IPCP, um die Headerkomprimirungsinformationen von dem PDSN anzufordern. Um die Anzahl der Protokolle, die die Mobilstation unterstützen muss, zu begrenzen, sollten empfohlene und optionale Protokolloptionen für den Ausstrahlungsdienst definiert werden.
  • 18 stellt ein Verfahren 2000 zum Vorsehen von einem Ausstrahlungsdienstparameter und Protokollinformationen unter Verwendung einer BSPM dar. Im Schritt 2002 empfängt die MS die BSPM von dem CS. Die BSPM ist so, wie hierin oben beschrieben. Die MS extrahiert die SO-Nummer von der BSPM im Schritt 2004. Die SO-Nummer ist abgebildet auf einen Satz von Parametern und Protokollen ausreichend für die MS, um die gewünschte Ausstrahlung zu empfangen. Die MS initiiert anschließend den Protokollstapel entsprechend der ausgewählten SO-Nummer im Schritt 2008. Wenn der Protokollstapel initiiert wurde, ist die MS dazu in der Lage, Informationen, die auf dem Ausstrahlungskanal empfangen werden, im Schritt 2010 zu empfangen und zu decodieren. Es sei angemerkt, dass die BSPM auf einem separaten Walsh-Kanal, der den Teilnehmern bekannt ist, gesendet wird.
  • 19 stellt eine 2020 von jeder der SO-Nummern auf einen Satz von Parametern und Protokollen dar. Wenn der CS anfangs eine Ausstrahlung plant, wie zum Beispiel ein Fußballspiel an einem gegebenen Tag, bestimmt der CS die Parameter und Protokolle, die für die Sendung der Ausstrahlung von einem Satz von vorhergehenden standardisierten Optionen benutzt werden sollen.
  • In einem Ausführungsbeispiel entspricht die SO-Nummer einem festen Satz von Protokollen und Parametern, wobei die Abbildung beim CS und bei der MS bekannt ist. Das A-Priori-Wissen der Abbildung vermeidet den Bedarf die Information zu senden, und reduziert somit den Sendungsoverhead, d.h., bewahrt Bandbreite. Die Abbildungen werden in der MS gespeichert, und werden deswegen nicht gleich geändert oder aktualisiert. Wenn der CS eine Kombination von Parametern benutzen soll, die noch nicht zuletzt als eine SO-Nummer standardisiert worden sind, muss die Standardorganisation ein neues Profil der Parameter definieren, bevor diese Kombination von Parametern für die Ausstrahlung benutzt werden kann.
  • Die Verwendung von einem BLOB von Informationen ist in 20 dargestellt, wobei eine Ausstrahlungssitzung einem Satz von Parametern zugeordnet ist. Jeder Parameter kann eine von mehreren Optionen sein. Die Sendung von Parametern sieht einen Level von Flexibilität im Vergleich zu der Verwendung von festen Sätzen von Parametern, die mit einer SO-Nummer assoziiert sind, vor. Der CS kann jede der verfügbaren Optionen auswählen und die Informationen zur MS senden. Wie dargestellt, kann das FELD 2 des BLOB als jede der Optionen spezifiziert werden: OPTION 1 bis OPTION K, wobei jedes Feld des BLOBs eine unterschiedliche Anzahl von verfügbaren Optionen haben kann.
  • Ein alternatives Ausführungsbeispiel sieht Ausstrahlungsprotokolle und -parameter über bandexterne Signalisierung in dem Ausstrahlungsstrom vor. In der vorliegenden Diskussion zeigt bandextern einen separaten Kanal an, der für die Kommunikation der Overheadinformationen benutzt wird. Der separate Kanal kann eine unterschiedliche Frequenz oder ein Spreizspektrumkanal sein, wie zum Beispiel ein Kanal, der durch einen unterschiedlichen Walsh- Code definiert wird. Das System sieht den Ausstrahlungsparameter und Protokollinformation für den Teilnehmer vor, wenn der Teilnehmer einen Paketdatenanruf initiiert. Der Teilnehmer oder MS fordert zuerst Headerkomprimierungsinformationen von dem PDSN an. Unter Verwendung der Informationen, die von dem PDSN empfangen wurden, ist die MS in der Lage, die Ausstrahlungsoverheadinformationen zu empfangen. Die MS kontaktiert den CS über IP-Typprotokolle, zum Beispiel RTSP oder SIP, um eine Beschreibung des Transports und der Anwendungsebenen zu empfangen. Die MS benutzt diese Informationen, um eine Ausstrahlungssitzung zu empfangen, zu decodieren und zu verarbeiten.
  • 21 stellt verschiedene Kanäle dar, die für die Sendung der verschiedenen Informationen in einem Ausstrahlungssystem verwendet werden. Wie dargestellt, beinhaltet das System 3000 einen CS 3002 und eine MS 3004, die über einen Ausstrahlungskanal 3010, einem Overheadkanal 3012 und einen Verkehrskanal 3014 kommunizieren. Ausstrahlungsinhalt einer gegebenen Ausstrahlungssitzung wird auf dem Ausstrahlungskanal 3010 gesendet, der eine einzigartige zugeordnete Frequenz oder einen einzigartigen zugeordneten Walsh-Kanal haben kann. Sendung einer BSPM-Nachricht wird auf dem Overheadkanal 3012 vorgesehen. Der Verkehrskanal 3014 wird für die Sendung der bandexternen Signalisierung benutzt, wie zum Beispiel Kommunikation zwischen CS und MS und Kommunikationen zwischen PDSN (nicht gezeigt) und MS.
  • Die MS ist dazu in der Lage, den CS und das PDSN direkt unter Verwendung der bandexternen Signalisierung über eine Paketdatendienstoption zu kontaktieren. Die bandexterne Kommunikation erlaubt dem CS die Informationen ohne Senden über die BS zu aktualisieren, da die bandexterne Kommunikation direkt zwischen der MS und dem PDSN oder der MS und dem CS stattfindet. Es sei angemerkt, dass, wenn der Paketdatendienst als bandexterne Mittel verwendet wird, die Kommunikationen zwischen der MS und dem CS immer noch durch die BS geleitet wird. Jedoch benötigt die BS kein Wissen der Nutzlast, macht es somit unnötig, den CS und die BS-Protokolle zu koordinieren.
  • Um die Nachteile der bandexternen Verfahren des Sendens der Protokolle und Parameter zum Empfänger zu vermeiden, kann die SDP-Beschreibung von dem CS in den Ausstrahlungsstrom gemultiplext werden. Dies erlaubt der Mobilstation die Protokolloptionen, die von dem CS ohne Einstellung eines Paketdatenanrufs, zu bestimmen.
  • Die SDP-Beschreibung wird genauso häufig wie ein kurzfristiger Verschlüsselungsschlüssel (SK = short-term encryption key) in dem Ausstrahlungsstrom gesendet. Die Rate des Sendens dieser Aktualisierungen wird durch die Menge der Bandbreite, die für solche Aktualisierungen verfügbar ist, begrenzt. Wenn zum Beispiel die SDP-Beschreibung 300 Bytes groß ist und alle drei Sekunden gesendet wird, ist die benötigte Bandbreite 800 bps. Es sei angemerkt, dass, da die SDP-Beschreibung ihren Ursprung beim Inhalteserver hat, der Inhalteserver die Medienqualität durch Multiplexen der SDP-Nachricht in den Ausstrahlungsstrom verbessern kann, wenn die Medienbandbreite niedrig genug ist, um sie aufzunehmen. Auf effektive Art und Weise kann die SDP Information adaptiv auf den Bandbreitenbedingungen basieren. Deswegen kann die Frequenz der SDP-Sendung sich ebenso ändern, wenn die Kanalbedingung und/oder Stresssituationen auf der Bandbreite des Systems sich ändern. Auf ähnliche Weise kann es möglich sein, die Größe des SDP durch Anpassen der Information, die darin spezifisch für ein gegebenes System vorhanden ist, zu ändern.
  • Die SDP-Beschreibung wird typischerweise in RTSP-, SAP-, oder SIP-Nachrichten transportiert. Um den Overhead solcher Protokolle zu vermeiden, ist es ratsam, dass die SDP-Beschreibung direkt über UDP durch Identifizieren bei einer bekannten UDP-Portnummer transportiert wird, um die SDP-Nachricht zu tragen. Diese Portnummer muss nicht benutzt werden, um RTP oder andere Typen von UDP-Verkehr, der über den Ausstrahlungskanal ge sendet wird, zu tragen. Die UDP-Prüfsumme wird Fehlerdetektion für die SDP-Nutzlast vorsehen.
  • Gemäß einem Ausführungsbeispiel, das in 22 dargestellt ist, sieht das System die Ausstrahlungsprotokolle und Parameter über bandinterne Signalisierung in dem Ausstrahlungsstrom vor. Der Ausstrahlungsstrom 4000 enthält den Ausstrahlungsinhalt und wird auf dem Ausstrahlungskanal gesendet, wie zum Beispiel Ausstrahlungskanal 3010 der 21. Der Ausstrahlungsstrom 4000 ist durchgängig durchsetzt mit SDP 4002.
  • 23 stellt ein Verfahren 5000 zum Vorsehen eines Ausstrahlungsdienstparameters und Protokollinformationen unter Verwendung eines bandinternen Verfahrens dar, wobei die Overheadtypinformation mit dem Ausstrahlungsinhalt auf dem Ausstrahlungskanal vorgesehen ist. Der Ausdruck bandintern ist dazu gedacht, um anzuzeigen, dass die Overheadtypinformation auf dem gleichen Kanal wie der Ausstrahlungsinhalt vorgesehen ist, und somit keinen separaten Sendungsmechanismus, d.h. Kanal, benötigt. Das Verfahren 5000 greift zuerst auf die BPSM im Schritt 5002 zu. Die MS extrahiert die Ausstrahlungskanalinformation, die physikalische Ebeneninformation und die MAC-ebenen Information von der BSPM. Die Headerkomprimierungsinformation wird direkt von dem PDSN im Schritt 5004 empfangen. Dies kann realisiert werden entweder durch direktes Kontaktieren der MS mit dem PDSN über eine Paketdatendienstoption (bandextern) oder durch das Einfügen der PDSN von Headerkomprimierungskonfigurationsinformationen in den Ausstrahlungsstrom für die MS. Im Schritt 5006 greift die MS auf den Ausstrahlungsinhalt (BC = Broadcast Content) zu. Ansprechend auf den Empfang der Headerkomprimierungsinformation ist die MS dazu in der Lage, das SDP, das auf dem Ausstrahlungskanal mit dem Ausstrahlungsinhalt gesendet wird, im Schritt 5008 zu empfangen. Das SDP enthält Parameter und Protokolle zum Empfangen der assoziierten Ausstrahlungssitzung. Die MS wendet die Information, die in dem SDP enthalten ist, an, um den Ausstrahlungsinhalt, der auf dem Ausstrahlungskanal empfangen wird, zu empfangen, zu dekodieren und zu verarbeiten.
  • Wenn ein Teilnehmer des Ausstrahlungsdienstes wünscht, zu einer anderen Ausstrahlungssitzung zu wechseln, kann die Einstellung und/oder Initiierung der neuen Ausstrahlungssitzung nicht akzeptierbare Verzögerungen für den Teilnehmer einführen. Ein Ausführungsbeispiel sieht eine Speichereinheit beim Empfänger vor, wobei wenigstens ein Teil der Informationen beim Empfänger gespeichert werden und benutzt werden können, um schnell von einer Ausstrahlungssitzung, d.h. Programm, zu einer anderen zu wechseln, oder kann alternativ benutzt werden, um eine zuletzt zugegriffene Ausstrahlungssitzung wieder aufzurufen. 23 stellt eine Speichereinheit 6000 dar, die die SPI und den SDP entsprechend jeder Ausstrahlungssitzung, auf die zugegriffen wurde, speichert. Die Overheadinformation entsprechend einer aktuellen Ausstrahlungssitzung wird im Speicher 6000 gespeichert, wobei die gespeicherte Information die letzte empfangene Information ist. In einem Ausführungsbeispiel ist die Speichereinheit 6000 eine First In First Out (FIFO) Speichereinheit. In einem alternativen Ausführungsbeispiel wird ein Cache-Speicher benutzt. In noch einem anderen Ausführungsbeispiel speichert eine Nachschlagetabelle (LUT = Look Up Table) Informationen bezogen auf die zugegriffenen Ausstrahlungssitzungen.
  • In Ausführungsbeispielen, die Mechanismen verwenden, wie zum Beispiel Cache-Speicher und/oder LUT benutzt die MS einen einfachen Zeitstempelalgorithmus, um nur eine Kopie der letzten SPI-SDP-Konfigurationen im Speicher Aufrecht zu erhalten. Für jedes SPI-SDP-Paar, hält die MS einen Zeitstempel von wann die MS die letzte Beschreibung empfangen hat, aufrecht. Wenn die MS eine SPI detektiert, die in seinem Speicher schon existiert, benutzt es die gespeicherte Konfiguration und aktualisiert den Zeitstempel auf die aktuelle Zeit. Wenn die detektierte SPI nicht in dem Speicher der MS ist, tauscht die MS den ältesten SPI-SDP-Eintrag in ihren Speicher mit dem neu detektierten SPI-SDP-Paar aus. Die MS benutzt nun diese neue Konfiguration, um den Ausstrahlungsstrom zu dekodieren.
  • Nachrichtenfluss
  • 5 stellt den Anrufsfluss zum Zugreifen auf eine Ausstrahlungssitzung in dem beispielhaften Ausführungsbeispiel für eine gegebene Systemtopologie dar. Das System beinhaltet eine MS, BS, PDSN und CS, wie aufgelistet an der horizontalen Achse. Die vertikale Achse repräsentiert die Zeit. Der Benutzer oder die MS ist ein Teilnehmer des HSBS-Dienstes. Zur Zeit t1 verhandelt die MS und CS die Subskriptionssicherheit für den Ausstrahlungsdienst. Die Verhandlung involviert den Austausch und die Pflege von Verschlüsselungsschlüssel, etc., die für den Empfang des Ausstrahlungsinhalts auf dem Ausstrahlungskanal benutzt werden. Der Benutzer baut eine Sicherheitsassoziation mit dem CS beim Empfang der Verschlüsselungsinformation auf. Die Verschlüsselungsinformation kann einen Ausstrahlungszugriffsschlüssel (BAK = Broadcast Access Key) oder eine Schlüsselkombination, etc., vom CS enthalten. Gemäß dem beispielhaften Ausführungsbeispiel sieht der CS die Verschlüsselungsinformation über einen dedizierten Kanal während einer Paketdatensitzung, wie zum Beispiel über PPP, WAP oder andere bandexterne Verfahren vor.
  • Zur Zeit t2 stellt die MS den Ausstrahlungskanal ein und startet das Empfangen der Pakete. Zu diesem Zeitpunkt wird der MS ermöglicht, die empfangenen Pakete zu verarbeiten, weil der IP/ESP-Header über ROHC komprimiert wird, und der Dekomprimierer der MS noch nicht initialisiert wurde. Das PDSN sieht Headerkomprimierungsinformation (nachstehend detaillierter beschrieben) zum Zeitpunkt t3 vor. Von dem ROHC-Paket-Header detektiert die MS und erlangt ein ROHC-Intitialisierungs- & Refresh-(IR = Initialization & Refresh)Paket, das periodisch von dem PDSN auf dem Ausstrahlungskanal gesendet wird. Das ROHC-IR-Paket wird benutzt, um den Status des Dekomprimierers in der MS zu initialisieren, das es erlaubt, den IP/ESP-Header der empfangenen Pakete zu dekomprimieren. Die MS ist anschließend in der Lage die IP/ESP-Header der empfangenen Pakete zu verarbeiten, jedoch benötigt die MS weitere Informationen, um die ESP-Nutzlast zu verarbeiten, da die Nutzlast mit einem vorläufigen Schlüssel (SK = Short Term Key) bei dem CS verschlüsselt ist. Der SK agiert in Koordination mit dem BAK, wobei der SK beim Empfänger unter Verwendung des BAK entschlüsselt wird. Der CS sieht weitere Verschlüsselungsinformationen vor, wie zum Beispiel aktualisierte Schlüsselinformationen oder einen aktuellen SK zur Zeit t4. Es sei angemerkt, dass der CS diese Informationen periodisch an die MS vorsieht, um die laufende Sicherheit der Ausstrahlung zu gewährleisten. Zur Zeit t5 empfängt die MS den Ausstrahlungsinhalt vom CS. Es sei angemerkt, dass alternative Ausführungsbeispiele, alternative Komprimierung und Dekomprimierungsverfahren eingebaut werden können, die effiziente Sendung der Headerinformationen vorsehen. Zusätzlich können alternative Ausführungsbeispiele eine Vielfalt von Sicherheitsschematas implementieren, um den Ausstrahlungsinhalt zu schützen. Noch andere Ausführungsbeispiele können einen nicht sicheren Ausstrahlungsdienst vorsehen. Die MS benutzt Verschlüsselungsinformation, wie zum Beispiel den SK, um den Ausstrahlungsinhalt zu entschlüsseln und anzuzeigen.
  • Komprimierung
  • Gemäß dem beispielhaften Ausführungsbeispiel wird der Ausstrahlungsinhalt auf einen dedizierten Ausstrahlungskanal gesendet. Die Transportebene sieht Verschlüsselungsoverhead für das Befördern des Ausstrahlungsinhalts in den IP-Paketen vor. Das System unterstützt Datenkomprimierung und speziell Headerkomprimierung. Die Entscheidung, die Daten zu komprimieren, hängt von dem benötigten Durchsschnittsdurchsatz (einschließlich Transport-/Verschlüsselungsoverhead, Datenverbindungsebenenoverhead und physikalischer Ebenenoverhead) ab und von der Benutzerwahrnehmung der Ausstrahlungsqualität. Das Befördern von mehr Ausstrahlungsinhalt in jedem IP-Paket reduziert den Overhead und somit reduziert es die Ausstrahlungskanalbandbreite. Im Gegensatz dazu erhöht die Komprimierung die Paketfehlerrate (PER = Packet Error Rate), die die Benutzerwahrnehmung beeinflusst. Dies ist wegen der Sendung von jedem langen IP-Paket, das mehrere physikalische Ebenenrahmen aufspannt und somit mit Erhöhungen in der Rahmenfehlerrate (FER = Frame Error Rate) assoziiert wird. Wenn ein Träger entscheidet, kleine IP-Pakete zu benutzen, um die Ausstrahlungsqualität zu verbes sern, kann der Träger Headerkomprimierung wählen, um den Transport- und Verschlüsselungsoverhead des IP-Pakets zu reduzieren.
  • Die RTP/UDP/IP-Protokolle werden benutzt, um den Ausstrahlungsinhalt von dem CS zur MS zu transportieren, und der Inhalt ist geschützt durch den ESP im Transportmodus. Der Transportoverhead ist der RTP/UDP/IP-Header und ist 40 Bytes pro IP-Paketdaten. Der Verschlüsselungsoverhead ist in der Form des ESP-Headers, Intialisierungsvektors (IV = Initialization Vector) und ESP-Trailer. Der ESP-Header und IV wird zwischen dem IP-Header und dem UDP-Header eingefügt. Der ESP-Header besteht aus dem SPI (4 Bytes) und der Sequenznummer (4 Bytes). Die Länge des IV ist spezifisch für den benutzten Verschlüsselungsalgorithmus. Für den AES Cipher Algorithmus ist die Länge des IV 16 Byte. Der ESP-Trailer wird an dem Ende des UDP-Datagramms angehängt und besteht aus dem Padding bzw. Auffüllung, dem nächsten Header (1 Byte) und der Padding- bzw. Auffüllungslänge (1 Byte). Da die Cipherblockgröße des AES Algorithmus 16 Bytes ist, geht die Padding-Größe von 0 bis 15 Bytes. Nimmt man die Ceiling-Funktion des Durchschnitts, ergibt die Padding-Größe 8 Bytes. Für ein IP-Paket geht der gesamte Overhead wegen dem Transport und der Verschlüsselung von 66 bis 81 Bytes mit dem Durchschnitt von 74 Bytes ausschließlich des Datenverbindungsebenenoverheads von dem PDSN zur MS.
  • Headerkomprimierung, wie zum Beispiel die robuste Headerkomprimierung (ROHC = Robust Header Compression) kann benutzt werden, um den IP-Header und das SPI-Feld des ESP-Headers von 24 Bytes auf 2 Bytes zu reduzieren. Die Sequenznummer des ESP-Headers wird nicht komprimiert, weil es benutzt wird, um die komprimierten Pakete zu entschlüsseln. Der IV wird nicht komprimiert, weil er bei jedem Paket sich zufällig ändert. Der UDP/RTP-Header und ESP-Trailer kann nicht komprimiert werden, weil sie verschlüsselt sind. Wenn deswegen ROHC benutzt wird, um den IP/ESP-Header zu komprimieren, ist der durchschnittliche Overhead wegen dem Transport und der Verschlüsselung von 74 Bytes auf 52 Bytes pro IP-Paket reduziert.
  • Gemäß dem beispielhaften Ausführungsbeispiel wird Headerkomprimierung, wie zum Beispiel die robuste Headerkomprimierung (ROHC), angewandt, um so propagierende Dekomprimierungsfehler zu vermeiden. Wie in 7 dargestellt, wird die Headerinformation von 24 Bytes runter auf 2 Bytes komprimiert. Der Header 500 beinhaltet einen IP-Header 502 und einen SPI-Teil 504. Der Komprimierungsalgorithmus resultiert nach der Komprimierung in einem 2-Byte-Resultat. Im Gegenteil zur konventionellen Headerkomprimierung, wobei einige Typen der Verhandlung zwischen der MS und PDSN oder einem anderen Infrastrukturelement benötigt wird, sieht das beispielhafte Ausführungsbeispiel eine unidirektionale Sendung der Komprimierungsinformation vor. Die MS muss Komprimierungsinformation anfordern, d.h. Headerkomprimierungsparameter ausreichend für die Dekomprimierung der empfangenen Information bei der MS. Im Gegensatz dazu sieht das PDSN die Komprimierungsinformation periodisch vor, wie in 8 dargestellt. Das PDSN sieht Komprimierungsinformation auf dem Ausstrahlungskanal durchsetzt mit dem Ausstrahlungsinhalt vor. Die Versorgung mit Steuerinformation in einem Datenstrom wird als "bandintern" bezeichnet, da ein separater Kanal nicht benötigt wird. Wie dargestellt beinhaltet der Ausstrahlungsstrom 600 Ausstrahlungsinhaltteile 604 und Dekomprimierungsinformation, d.h. Komprimierungsinformation 602. Die Dekomprimierungsinformation wird mit einer Periode von TDECOMPRESSION vorgesehen. Alternative Ausführungsbeispiele können die Dekomprimierungsinformation beim Auftreten eines vorbestimmten Events bzw. Ereignisses anstatt dies periodisch vorzusehen. Da die MS keine Dekomprimierungsinformation benötigt, versorgt das PDSN die Information mit einer Frequenz, die Verzögerungen beim Zugreifen auf den Ausstrahlungsinhalt meidet. Mit anderen Worten sollte das PDSN die Information oft vorsehen, sodass eine MS auf die Ausstrahlung zu jeder Zeit ohne auf die Dekomprimierungsinformation warten zu müssen, zugreifen kann.
  • Es sei angemerkt, dass die ROHC in einem unidirektionalen Modus betrieben werden kann, wobei Pakete nur in einer Richtung gesendet werden: von Komprimierer zu Dekomprimierer. In diesem Modus macht es deswegen ROHC benutzbar über Verbindungen, wobei ein Rückpfad vom Dekomprimie rer zum Komprimierer nicht verfügbar oder nicht wünschenswert ist. Bevor die MS, die Pakete, die von dem Ausstrahlungskanal empfangen wurden, dekomprimieren kann, wird der Zustand des Dekomprimierers initialisiert. Das Initialisierungs- & Refresh(IR)-Paket wird für diesen Zweck benutzt. Es gibt zwei Alternativen für die ROHC-Initialisierung.
  • Der Teilnehmer "stellt" den Ausstrahlungskanal ein und wartet auf die ROHC-IR-Pakete, die periodisch von dem ROHC-Komprimierer in dem PDSN gesendet werden. Häufige ROHC-IR-Pakete können zu viel Bandbreite in dem Ausstrahlungskanal benutzen. Ein IR-Paket ist ungefähr 30 Bytes für das IP/ESP-Komprimierungsprofil. Wenn ein IR-Paket alle 250 Millisekunden gesendet wird, verbraucht die Verarbeitung ungefähr 1 kbps in dem Ausstrahlungskanal. Das Verlieren von IR-Paketen über die Luft würde die MS weiter verzögern, die ROHC-Initialisierung zu erlangen.
  • Wenn die Dekomprimierung nicht mehr synchron ist, wegen Paketverlust oder Restwertfehler in dem empfangenen komprimierten Header, oder Fehler, etc., kann der resultierende Dekomprimierungsfehler sich propagieren, bis die Dekomprimierung wieder synchronisiert oder reinitialisiert wird. Ein ROHC komprimierter Header enthält einen zyklischen Redundanzcheck (CRC = Cyclic Redundant Check), der über den gesamten Header vor der Komprimierung berechnet wird. Dieser CRC erlaubt der Dekomprimierung, eine lokale Kontextreparatur durchzuführen, die den Kontext synchronisiert (bei den Ereignissen von Paketverlust und Restwertfehler). Wenn die Dekomprimierung sich von einem Fehler erholt, reinitialisieren periodische IR-Pakete effektiv die Komprimierungsverarbeitung.
  • Transportebene
  • Das Datenverbindungsebenenrahmenprotokoll oder Transportebenenprotokoll wird zwischen dem PDSN und der MS angewandt, um Pakete, die vom Ausstrahlungskanal empfangen wurden, abzugrenzen. Mit Bezug auf 3 wird Information in der Transportebene, identifiziert als LINK LAYER bzw. Verbin dungsebene, zwischen dem PDSN und der MS vorgesehen. Die Rahmeninformation wird beim PDSN erzeugt und wird der MS über die BS vorgesehen. Das PDSN empfängt IP-Ströme von dem CS und rahmt die IP-Ströme gemäß einem vorbestimmten Rahmenprotokoll ein. Wie in dem beispielhaften Ausführungsbeispiel dargestellt, wendet das PDSN eine Rahmenprotokollversion der Hochleveldatenverbindungssteuerung (HDLC = High-Level Data Link Control) an. Die HDLC, die in dem ISO-Standard spezifiziert ist, entspricht der Ebene 2 des International Standards Organization (ISO) 7-ebenenartigen Architektur, wobei die Ebene 2 als Datenverbindungsebene bezeichnet wird. Das HDLC-Protokoll versucht, fehlerfreie Bewegung der Daten zwischen Netzwerkpunkten vorzusehen. Zu diesem Ende ist die HDLC-Ebene entwickelt, um die Integrität der Daten, die zu einer nächsten Ebene weitergereicht werden, zu versichern. Mit anderen Worten sucht das Rahmenprotokoll die Daten, die genau wie die Daten, die ursprünglich gesendet wurden, empfangen werden, zu reproduzieren, und zwar ohne Fehler, um den Verlust von Information und in der korrekten Reihenfolge.
  • Das beispielhafte Ausführungsbeispiel wendet eine Version der HDLC-Einrahmung an, welches einen Subsatz von HDLC definierten Parametern anwendet. 9 stellt ein Ausführungsbeispiel der HDLC-Einrahmung dar, wobei der Rahmen 700 eine Vielzahl von Feldern beinhaltet, wie durch das HDLC-Protokoll, das im RFC 1662 umrissen wurde, definiert ist. Das Feld 702 definiert ein FLAG oder eine Anzeige eines Starts des Rahmens. Das FLAG hat eine zugeordnete Bitlänge und ist durch ein vorbestimmtes Muster von Bits definiert. Die HDLC ist einfach bzw. angenehm anzuwenden, da die HDLC ein üblich verfügbares standardisiertes Protokoll ist. Ein Nachteil des vollen HDLC-Rahmenprotokolls ist die Verarbeitungszeit, die benötigt wird, um Rahmen beim Sender zu erzeugen und Rahmen beim Empfänger wiederzuerlangen.
  • Im speziellen wird das HDLC-Protokoll als Prozessor intensiv betrachtet, da weitere Verarbeitung benutzt wird, um abzusichern, dass die Nutzlast nicht die gleiche Sequenz von Bits wie das FLAG beinhaltet. Beim Sender, wenn eine FLAG-Sequenz von Bits in der Nutzlast detektiert wird, wird ein Escape-Zeichen in die Nutzlast eingefügt, um das FLAG als Teil der Nutzlast zu identifizieren und nicht einen Start des Rahmens anzeigt. Die Verarbeitung des Addierens bzw. Hinzufügens eines Escape-Zeichens wird als "escaping" von Hexadezimalmustern von 0 × 7E und 0 × 7D in dem Nutzlastrahmen bezeichnet. Ein alternatives Verfahren, das als Efficient Framing Protocol bzw. effizientes Rahmenprotokoll bezeichnet wird, das weniger prozessorintensiv als die HDLC-ähnliche Einrahmung ist, ist nachstehend beschrieben. 9 stellt die Optionen der Verwendung der HDLC-Einrahmung dar, um PPP-Rahmen zu transportieren. Für die HSPS-Operation kann der HDLC-ähnliche Rahmen-Overhead reduziert werden, und zwar durch Eliminieren des Felds, das nicht benötigt wird, oder nicht all zu große Bedeutung und/oder wenig Information vorsehen, für eine unidirektionale Ausstrahlung. Wie oben beschrieben ist das FLAG eine vorbestimmte Sequenz von Bits als Anzeige für den Anfang eines HDLC-Rahmens. Das beispielhafte Ausführungsbeispiel inkorporiert ein FLAG oder einen anderen Start der Rahmenanzeige 802, wie in dem Format 800 der 10 dargestellt. Im Gegensatz zu dem Format der 9 wird das Ende eines Rahmens nicht mit Overheadinformation in dem beispielhaften Ausführungsbeispiel angezeigt. Da die Adresse und die Steuerfelder des Formats 700 statische Werte haben, sind diese nicht in dem Format 800 beinhaltet.
  • Weiter mit 10, da der Zweck des Protokollfelds 708 (9) es ist, den Nutzlasttyp zu identifizieren, wie zum Beispiel LCP-Steuerpaket, ROHC-Paket, IP-Paket, etc., wird dieser Diskriminator für die Ausstrahlungsoperation nicht benötigt, da alle Pakete in dem Ausstrahlungskanal zum selben Typ gehören. Wenn zum Beispiel die ROHC-Komprimierung für Paketsendung benutzt wird, werden alle Pakete in dem Ausstrahlungskanal als ROHC-Pakete verarbeitet. Die Typen der ROHC-Pakete, wie zum Beispiel IR-Paket, komprimiertes Paket, etc., werden durch das Pakettypfeld in dem ROHC-Paketheader unterschieden. Deswegen ist das Protokollfeld im Format 800 nicht beinhaltet. Weiterhin beinhaltet das Format 800 ein Fehlerkontrollfeld 806 nach der Nutzlast 804. Das Fehlerkontrollfeld 806 liefert Informationen an den Empfänger, um dem Empfänger zu ermöglichen, nach Fehlern in der empfangenen Nutzlast zu prüfen. Das beispielhafte Ausführungsbeispiel inkorporiert eine Rahmenprüfsumme (FCS = Frame Check Sum), die als Null, 16 Bits oder 32 Bits spezifiziert werden kann. Da ein HDLC-Rahmen mehrere physikalische Ebenenrahmen in dem Ausstrahlungskanal überspannen kann, wird vorgeschlagen, einen 16-Bit FCS zu benutzen.
  • Die Prozedur des Octet-Ausstaffierens bzw. Stuffings definiert im RFC 1662 wird ebenso auf das beispielhafte Ausführungsbeispiel angewandt, wobei nach der FCS-Berechnung, der HDLC-Sender in dem PDSN jedes Byte in dem HDLC-Rahmen (ausschließlich des Flags) nach Mustern von 0 × 7E und 0 × 7D untersucht. Das Muster 0 × 7E wird als 0 × 7D und 0 × 5E codiert und das Muster 0 × 7D wird als 0 × 7D und 0 × 5D codiert. Der HDLC-Sender wird nicht andere Muster codieren. Das impliziert, dass die Async-Steuerzeichenabbildung (ACCM = Async-Control-Character-Map), wie definiert im RFC 1662, auf Nur-Nullen gesetzt werden. Der HDLC-Rahmenoverhead ist 3 Bytes plus dem Octet-Stuffingoverhead groß. Angenommen das Bytemuster ist gleichmäßig verteilt, dann ist der Durchschnittsoctet-Stuffingoverhead ein Byte pro 128 Byte HDLC-Rahmen groß. Wenn zum Beispiel die Nutzlast 256 Bytes sind, ist der HDLC-Rahmenoverhead im Durchschnitt 5 Bytes groß.
  • 11 ist ein Flussdiagramm eines Rahmungsverfahrens 900 durchgeführt beim Sender. Der Sender bildet den Ausstrahlungsrahmen im Schritt 902 durch bestimmen eines Nutzlastteils der paketisierten Daten und durch Erzeugen eines Start des Flags bzw. Start of Flag (SOF). Der Sender checkt anschließend den Rahmen nach jeglichen SOF-Sequenzen, die in der Nutzlast 904 enthalten sind. Wenn eine SOF-Sequenz in der Nutzlast gefunden wird, addiert der Sender ein Escape-Zeichen im Schritt 912. Andernfalls bringt der Sender das SOF an die Nutzlast im Schritt 906 an und sieht einen Fehlerkontrollmechanismus im Schritt 908 vor. Der Rahmen wird im Schritt 910 gesendet. Der gesendete Rahmen hat das Format 800 der 10. Alternative Ausführungsbeispiele können andere Felder in dem Rahmenformat implemen tieren und können jede Form eines Klassifizierers inkorporieren, um eine SOF-Sequenz in der Nutzlast zu orten.
  • 12 ist ein Flussdiagramm eines Entrahmungsverfahrens 920 durchgeführt beim Empfänger. Die Verarbeitung startet beim Empfang eines Ausstrahlungsrahmens im Schritt 922. Der Empfänger identifiziert ein SOF im Schritt 924 und checkt bzw. sucht nach Escape-Zeichen in der Nutzlast bei der Entscheidungsraute 926. Wenn ein Escape-Zeichen, oder anderer SOF-Sequenzidentifizierer in der Nutzlast gefunden wird, nimmt der Emfänger das Escape-Zeichen 932 heraus. Andernfalls führt der Empfänger einen Fehler-Check bzw. -Kontrolle im Schritt 928 durch und verarbeitet den Rahmen im Schritt 930.
  • Der Fachmann wird verstehen, dass Informationen und Signale unter Verwendung von jeder einer Vielzahl von verschiedenen Technologien und Techniken dargestellt werden können. Zum Beispiel können Daten, Instruktionen, Befehle, Informationen, Signale, Bits, Symbole und Chips, auf die durchgehend durch die ganze obige Beschreibung Bezug genommen wurde, dargestellt werden können als Spannungen, Ströme, elektromagnetische Wellen, magnetische Felder oder Partikel, optische Felder oder Partikel oder jegliche Kombination davon.
  • Weiterhin sei angemerkt, dass die verschiedenen darstellenden logischen Blöcke, Module, Schaltungen und Algorithmusschritte, die in Verbindung mit den Ausführungsbeispielen beschrieben wurden und hierin offenbart sind, als elektronische Hardware, Computersoftware oder Kombinationen von beidem, implementiert werden. Um klar diese Austauschbarkeit von Hardware und Software darzustellen, wurden verschiedene darstellende Komponenten, Blöcke, Module, Schaltungen und Schritte oben beschrieben, und zwar generell mit Ausdrücken von deren Funktionalität. Ob solche Funktionalität als Hardware oder Software implementiert wird, hängt von der speziellen Anwendung und Designrandbedingungen, die dem gesamten System auferlegt sind, ab. Der Fachmann kann die beschriebene Funktionalität auf verschiedene Wege für jede spezielle Anwendung implementieren, aber solche Implementationsentscheidungen sollten nicht interpretiert werden als Verursachen einer Abweichung von dem Schutzumfang der vorliegenden Erfindung.
  • Die verschiedenen darstellenden logischen Blöcke, Module und Schaltungen, die in Verbindung mit den Ausführungsbeispielen, die hierin offenbart sind, beschrieben wurden, können implementiert werden oder mit einem Allzweckprozessor, einem digitalen Signalprozessor (DSP = digital signal processor), einer anwendungsspezifischen integrierten Schaltung (ASIC = application specific integrated circuit), ein feldprogrammierbares Gate-Array (FPGA = field programmable gate array) oder ein anderes programmierbares logisches Gerät, diskrete Gatter oder Transistorlogik, diskrete Hardwarekomponenten oder jegliche Kombination davon, die entwickelt werden, um die Funktionen, die hierin beschrieben werden, durchzuführen, durchgeführt werden. Ein Allzweckprozessor kann ein Mikroprozessor sein, aber als Alternative kann der Prozessor jeder konventionelle Prozessor, Kontroller, Mikrokontroller oder Zustandsmaschine sein. Ein Prozessor kann ebenso implementiert werden als eine Kombination von Berechnungsgeräten, zum Beispiel, eine Kombination von einem DSP und einem Mikroprozessor, eine Vielzahl von Mikroprozessoren, ein oder mehrere Mikroprozessoren in Verbindung mit einem DSP-Kern oder jede andere einer solchen Konfiguration.
  • Die Schritte eines Verfahrens oder Algorithmus, das in Verbindung mit den Ausführungsbeispielen, die hierin offenbart sind, beschrieben wurden, können direkt in Hardware, in einem Softwaremodul ausgeführt durch einen Prozessor oder in einer Kombination von diesen beiden eingebaut werden. Ein Softwaremodul kann in einem Speicher, Flash-Speicher, ROM-Speicher, EPROM-Speicher, EEPROM-Speicher, Registern, Festplatte, entfernbare Diskette, eine CD-ROM oder jede andere Form von Speichermedium, das auf dem Fachgebiet bekannt ist, enthalten sein. Ein beispielhaftes Speichermedium ist gekoppelt an dem Prozessor, sodass der Prozessor Informationen von dem Speichermedium lesen und darauf schreiben kann. Als Alternative kann das Speichermedium in dem Prozessor integriert sein. Der Prozessor und das Speichermedium können in einem ASIC enthalten sein. Der ASIC kann in einem Benutzerendgerät enthalten sein. Als Alternative können der Prozessor und das Speichermedium als diskrete Komponenten in einem Benutzerendgerät enthalten sein.
  • Die vorliegende Beschreibung der offenbarten Ausführungsbeispiele ist vorgesehen, um jedem Fachmann zu ermöglichen die vorliegende Erfindung zu produzieren oder zu verwenden. Verschiedene Modifikationen dieser Ausführungsbeispiele werden leicht für den Fachmann ersichtlich sein und die ursprünglichen Prinzipien, die hierin definiert sind, können auf andere Ausführungsbeispiele ohne Verlassen des Schutzumfangs der Erfindung angewendet werden. Somit ist es nicht beabsichtigt die vorliegende Erfindung auf die Ausführungsbeispiele, die hierin gezeigt sind, zu begrenzen, sondern ihnen den größtmöglichen Schutzumfang zu gewähren, und zwar konsistent mit den Prinzipien und neuen Merkmalen, die hierin offenbart sind.

Claims (15)

  1. Ein Verfahren zum Unterstützen eines Ausstrahlungs- bzw. Broadcast-Dienstes in einem zellularen drahtlosen Kommunikationssystem, wobei Folgendes vorgesehen ist: Senden der Ausstrahlungsoverheadinformation entsprechend einer Ausstrahlungssitzung auf einem Overheadsendekanal (3012) von einer ersten Vorrichtung (3002), wobei die Ausstrahlungsoverheadinformation Optionen in einem Protokollstapel enthält, und Information zum Einrichten und zum Synchronisieren des Ausstrahlungsdienst; Abtasten oder Scannen hinsichtlich einer Ausstrahlungsoverheadinformation (5002) entsprechend der Ausstrahlungssitzung auf einem Overheadinformationssendekanal (3012) unter Verwendung einer zweiten Vorrichtung (3004); Empfang (2002) der Ausstrahlungsoverheadinformation auf der zweiten Vorrichtung (3002); Abstimmen bzw. Einstellen (2004, 2008) der zweiten Vorrichtung (3002) unter Verwendung der empfangenen Ausstrahlungsoverheadinformation; Empfangen der Ausstrahlungssitzung (2010) auf einem Ausstrahlungssendekanal (3010) an der zweiten Vorrichtung (3002).
  2. Verfahren nach Anspruch 1, wobei: der Ausstrahlungsdienst durch einen Content- oder Inhaltserver (3002) übertragen bzw. gesendet wird; der Ausstrahlungsdienst einen entsprechenden Protokollstapel (3, 17) besitzt und eine Anwendungsschicht und eine Transportschicht; und der Content- oder Inhaltserver (3002) die Anwendungsschicht- und die Transportschichtprotokolle unabhängig steuert.
  3. Verfahren nach Anspruch 1, wobei der der Ausstrahlungsdienst als Internetprotokoll-Datenpakete (Internet Protocol data packets) gesendet wird.
  4. Verfahren nach Anspruch 1, wobei ferner Folgendes vorgesehen ist: während einer Ausstrahlungssendung aktualisieren eines Teils der Ausstrahlungsoverheadinformation; und Senden der Ausstrahlungsoverheadinformation mit dem aktualisierten Teil.
  5. Verfahren nach Anspruch 1, wobei das System ferner ein paketisiertes Datendienstnetzwerk aufweist, und wobei das Verfahren ferner Folgendes aufweist: das paketisierte Datendienstnetzwerk aktualisiert die Headerkomprimierungsinformation; und das paketisierte Datendienstnetzwerk sendet die aktualisierte Headerkomprimierungsinformation über den Overheadsendekanal (3012).
  6. Verfahren zum Unterstützen eines Ausstrahlungsdienst in einem zellularen drahtlosen Kommunikationsempfänger, wobei Folgendes vorgesehen ist: Empfang (2002) von Ausstrahlungsoverheadinformation entsprechend der Ausstrahlungssitzung auf einem Overheadsendekanal (3012), wobei die Ausstrahlungsoverheadinformation Optionen in einem Protokollstapel und Information zum Einrichten und zur Synchronisierung des Ausstrahlungsdienstes unterstützt; Zugriff (5006) der Ausstrahlungssitzung auf einen Ausstrahlungssendekanal (3010); und Verwendung der Ausstrahlungsoverheadinformation (2008) zum Empfang des Ausstrahlungsinhalts (broadcast content) (2010, 5010) der Ausstrahlungssitzung.
  7. Verfahren nach Anspruch 1, wobei Folgendes vorgesehen ist: der Ausstrahlungsdienst wird durch einen Inhalt- oder Contentserver (3002) gesendet; der Ausstrahlungsdienst besitzt einen entsprechenden Protokollstapel (3, 17) mit einer Anwendungsschicht und einer Transportschicht; und der Content- bzw. Inhaltserver (3002) steuert unabhängig die Anwendungsschicht und die Transportschichtprotokolle.
  8. Verfahren nach Anspruch 6, wobei der Ausstrahlungsdienst als Internetprotokoll-Datenpakete gesendet wird.
  9. Verfahren nach Anspruch 6, wobei ferner Folgendes vorgesehen ist: Empfang – während einer Ausstrahlungssendung – von aktualisierter Ausstrahlungsoverheadinformation auf dem Overheadsendekanal (3012); und Verarbeitung des Ausstrahlungsinhalts, empfangen auf dem Ausstrahlungssendekanal (3010), unter Verwendung der aktualisierten Ausstrahlungsoverheadinformation.
  10. Verfahren nach Anspruch 6, wobei das System ferner ein paketisiertes Datendienstnetzwerk aufweist, wobei das Verfahren ferner Folgendes aufweist: Empfangen (5004) der aktualisierten Headerkomprimierungsinformation von dem paketisierten Datendienstnetzwerk auf dem Overheadsendekanal (3012); und Verwenden der aktualisierten Headerkomprimierungsinformation zum Empfang des Ausstrahlungsinhalts (5010).
  11. Eine zellulare drahtlose Vorrichtung, die Folgendes aufweist: Mittel zum Empfang von Ausstrahlungsoverheadinformation entsprechend einer Ausstrahlungssitzung auf einem Overheadsendekanal (3012), wobei die Ausstrahlungsoverheadinformation Optionen in einem Protokollstapel und Information zur Einrichtung und Synchronisierung eines Ausstrahlungsdienstes unterstützt; Mittel zum Zugriff auf die Ausstrahlungssitzung auf einem Ausstrahlungssendekanal (3010); und Mittel zur Verwendung der Ausstrahlungsoverheadinformation (2008) zum Empfang des Ausstrahlungsinhalts der Ausstrahlungssitzung.
  12. Vorrichtung nach Anspruch 11, wobei Folgendes vorgesehen ist: der Ausstrahlungsdienst wird durch einen Inhaltserver (3002) gesendet; der Ausstrahlungsdienst besitzt einen entsprechenden Protokollstapel (3, 17) mit einer Anwendungsschicht und einer Transportschicht; und der Inhaltserver (3002) steuert unabhängig die Anwendungsschicht- und die Transportschichtprotokolle.
  13. Vorrichtung nach Anspruch 11, wobei der Ausstrahlungsdienst als Internetprotokoll-Datenpakete übertragen wird.
  14. Vorrichtung nach Anspruch 11, wobei das System ferner Folgendes aufweist: ein paketisiertes Datendienstnetzwerk, wobei das Verfahren Folgendes vorsieht: Mittel zum Empfang (5004) von aktualisierter Headerkomprimierungsinformation von dem paketisierten Datendienstnetzwerk auf dem Overheadsendekanal (3012); und Mittel zur Verwendung der aktualisierten Headerkomprimierungsinformation zum Empfang des Ausstrahlungsinhalts (5010).
  15. Eine zellulare drahtlose Vorrichtung, die Folgendes aufweist: Mittel zum Senden von Ausstrahlungsoverheadinformation entsprechend einer Ausstrahlungssitzung auf einem Overheadsendekanal (3012), wobei die Ausstrahlungsoverheadinformation Optionen in einem Protokollstapel enthält oder unterstützt, und ferner Information zum Aufbau und zum Synchronisieren eines Ausstrahlungsdienstes; Mittel zum Senden der Ausstrahlungsoverheadinformation zu einer zweiten Vorrichtung (3004); Mittel zum Vorsehen der zweiten Vorrichtung mit Zugriff zu der Ausstrahlungssitzung auf dem Ausstrahlungssendekanal (3010); und Mittel zum Senden des Rundfunkinhalts (2010, 5010) der Ausstrahlungssitzung zu der zweiten Vorrichtung (3004).
DE60211136T 2001-03-28 2002-03-28 Verfahren und vorrichtung zur ausser-band-übetragung von rundfunkdienst-optionen in einem drahtlosen kommunikationssystem Expired - Lifetime DE60211136T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US27997001P 2001-03-28 2001-03-28
US279970P 2001-03-28
US09/934,021 US6909702B2 (en) 2001-03-28 2001-08-20 Method and apparatus for out-of-band transmission of broadcast service option in a wireless communication system
US934021 2001-08-20
PCT/US2002/009826 WO2002080588A2 (en) 2001-03-28 2002-03-28 Method and apparatus for out-of-band transmission of broadcast service option in a wireless communication system

Publications (2)

Publication Number Publication Date
DE60211136D1 DE60211136D1 (de) 2006-06-08
DE60211136T2 true DE60211136T2 (de) 2007-02-22

Family

ID=26959995

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60211136T Expired - Lifetime DE60211136T2 (de) 2001-03-28 2002-03-28 Verfahren und vorrichtung zur ausser-band-übetragung von rundfunkdienst-optionen in einem drahtlosen kommunikationssystem

Country Status (14)

Country Link
US (1) US6909702B2 (de)
EP (1) EP1374506B1 (de)
JP (1) JP4615828B2 (de)
KR (1) KR100891882B1 (de)
CN (1) CN100474836C (de)
AT (1) ATE325487T1 (de)
AU (1) AU2002306978A1 (de)
BR (1) BRPI0208735B1 (de)
CA (1) CA2442650C (de)
DE (1) DE60211136T2 (de)
HK (1) HK1075152A1 (de)
MX (1) MXPA03008877A (de)
TW (1) TW577204B (de)
WO (1) WO2002080588A2 (de)

Families Citing this family (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6646195B1 (en) * 2000-04-12 2003-11-11 Microsoft Corporation Kernel-mode audio processing modules
US6961631B1 (en) * 2000-04-12 2005-11-01 Microsoft Corporation Extensible kernel-mode audio processing architecture
US9100457B2 (en) 2001-03-28 2015-08-04 Qualcomm Incorporated Method and apparatus for transmission framing in a wireless communication system
US7352868B2 (en) 2001-10-09 2008-04-01 Philip Hawkes Method and apparatus for security in a data processing system
US7649829B2 (en) * 2001-10-12 2010-01-19 Qualcomm Incorporated Method and system for reduction of decoding complexity in a communication system
US8218768B2 (en) * 2002-01-14 2012-07-10 Qualcomm Incorporated Cryptosync design for a wireless communication system
US7299349B2 (en) * 2002-01-31 2007-11-20 Microsoft Corporation Secure end-to-end notification
US7400733B1 (en) * 2002-02-27 2008-07-15 Atheros Communications, Inc. Key refresh at the MAC layer
US7177658B2 (en) 2002-05-06 2007-02-13 Qualcomm, Incorporated Multi-media broadcast and multicast service (MBMS) in a wireless communications system
KR100847521B1 (ko) * 2002-06-10 2008-07-22 엘지전자 주식회사 고속 데이터 전송 시스템의 브로드캐스트 서비스 데이터전송 방법
US7016327B2 (en) * 2002-08-21 2006-03-21 Qualcomm Incorporated Method and system for communicating content on a broadcast services communication system
US7020109B2 (en) * 2002-08-21 2006-03-28 Qualcomm Incorporated Method and system for communicating content on a broadcast services communication system
US20040059835A1 (en) * 2002-09-25 2004-03-25 Zhigang Liu Method and system for in-band signaling between network nodes using state announcement or header field mechanisms
US7325038B1 (en) * 2002-09-27 2008-01-29 Ricoh Company, Ltd. Mechanism for transferring data between applications running on multiple networked computers
US7283782B2 (en) 2002-10-22 2007-10-16 Qualcomm Incorporated Method and apparatus for switching between shared and individual channels to provide broadcast content services in a wireless telephone network
US7277694B2 (en) 2002-10-22 2007-10-02 Qualcomm Incorporated Method and apparatus for commencing shared or individual transmission of broadcast content in a wireless telephone network
US7386723B2 (en) * 2002-11-22 2008-06-10 Intel Corporation Method, apparatus and system for compressing IPSec-protected IP packets
US7599655B2 (en) 2003-01-02 2009-10-06 Qualcomm Incorporated Method and apparatus for broadcast services in a communication system
US7869399B2 (en) * 2003-01-06 2011-01-11 Interdigital Technology Corporation Method and apparatus for controlling the distribution of multimedia broadcast services
US7096024B2 (en) * 2003-01-31 2006-08-22 Qualcomm, Incorporated Method and apparatus to initiate point-to-point call during shared-channel delivery of broadcast content in a wireless telephone network
WO2004072765A2 (en) * 2003-02-13 2004-08-26 Nokia Corporation Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming
US7062272B2 (en) * 2003-02-18 2006-06-13 Qualcomm Incorporated Method and apparatus to track count of broadcast content recipients in a wireless telephone network
US20040168081A1 (en) * 2003-02-20 2004-08-26 Microsoft Corporation Apparatus and method simplifying an encrypted network
GB0307266D0 (en) * 2003-03-28 2003-05-07 Nokia Corp Wireless data communications
WO2004093404A1 (ja) * 2003-04-17 2004-10-28 Sharp Kabushiki Kaisha 送信機、受信機、ワイヤレスシステム、制御方法、制御プログラムおよびそれを記録したコンピュータ読み取り可能な記録媒体
US8718279B2 (en) 2003-07-08 2014-05-06 Qualcomm Incorporated Apparatus and method for a secure broadcast system
KR100880999B1 (ko) * 2003-08-07 2009-02-03 삼성전자주식회사 멀티미디어 브로드캐스트/멀티캐스트 서비스를 송수신하는 방법
US7822067B2 (en) * 2003-08-08 2010-10-26 Qualcomm Incorporated Header compression enhancement for broadcast/multicast services
US7318187B2 (en) 2003-08-21 2008-01-08 Qualcomm Incorporated Outer coding methods for broadcast/multicast content and related apparatus
US8694869B2 (en) 2003-08-21 2014-04-08 QUALCIMM Incorporated Methods for forward error correction coding above a radio link control layer and related apparatus
US8804761B2 (en) * 2003-08-21 2014-08-12 Qualcomm Incorporated Methods for seamless delivery of broadcast and multicast content across cell borders and/or between different transmission schemes and related apparatus
US8724803B2 (en) 2003-09-02 2014-05-13 Qualcomm Incorporated Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system
JP4303245B2 (ja) 2003-09-16 2009-07-29 サムスン エレクトロニクス カンパニー リミテッド 移動通信システムにおけるブロードキャスト／マルチキャストサービスのための状態情報を提供する方法及びシステム
US20050163076A1 (en) * 2004-01-13 2005-07-28 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for broadcasting on a shared packet data channel in a wireless communication network
JP4288368B2 (ja) * 2004-04-09 2009-07-01 Ｏｋｉセミコンダクタ株式会社 受信制御方法および無線ｌａｎ装置
US8588203B2 (en) 2004-06-04 2013-11-19 Qualcomm Incorporated Wireless communication system with improved broadcast coverage
US8966551B2 (en) 2007-11-01 2015-02-24 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US9197857B2 (en) * 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US7636328B2 (en) * 2004-10-20 2009-12-22 Qualcomm Incorporated Efficient transmission of signaling using channel constraints
KR100588623B1 (ko) * 2004-11-12 2006-06-14 주식회사 케이티프리텔 숫자 및 문자열의 동시 입력을 통한 선택 서비스 제공방법 및 시스템
US8280368B2 (en) * 2005-04-07 2012-10-02 Qualcomm Incorporated Method and system for re-acquiring signals of a wireless broadcast network
WO2007024918A2 (en) * 2005-08-23 2007-03-01 Matsushita Electric Industrial Co., Ltd. System and method for service discovery in a computer network using dynamic proxy and data dissemination
TWI398148B (zh) * 2005-09-21 2013-06-01 Innovative Sonic Ltd 無線通訊系統重建接收邊處理計時器的方法及裝置
US20070264989A1 (en) * 2005-10-03 2007-11-15 Rajesh Palakkal Rendezvous calling systems and methods therefor
US7907600B2 (en) * 2005-12-23 2011-03-15 Qualcomm Incorporated System and method for optimizing robust header compression (ROHC) in high delay variance environment
EP1808995A1 (de) * 2006-01-13 2007-07-18 Thomson Licensing S.A. Verfahren zur Übertragung von Datenpaketen in einem verteilten Netzwerk, Vorrichtung zum Komprimieren und Vorrichtung zum Dekomprimieren von Datenpaketen
US8929870B2 (en) * 2006-02-27 2015-01-06 Qualcomm Incorporated Methods, apparatus, and system for venue-cast
US7886146B2 (en) * 2006-03-15 2011-02-08 Koolspan, Inc. Network cryptography system and method
US20080317241A1 (en) * 2006-06-14 2008-12-25 Derek Wang Code-based echo cancellation
US7565159B2 (en) * 2006-06-14 2009-07-21 Divitas Networks, Inc. Methods and arrangement for implementing an active call handover by employing a switching component
US20090016333A1 (en) * 2006-06-14 2009-01-15 Derek Wang Content-based adaptive jitter handling
US7480500B1 (en) 2006-06-14 2009-01-20 Divitas Networks, Inc. Divitas protocol proxy and methods therefor
US20080140767A1 (en) * 2006-06-14 2008-06-12 Prasad Rao Divitas description protocol and methods therefor
CN101512989B (zh) * 2006-07-25 2013-08-14 汤姆森特许公司 利用交错播放和交叉分组前向纠错在基于因特网协议的无线网络中恢复突发分组丢失
US20080144490A1 (en) * 2006-12-19 2008-06-19 Innovative Sonic Limited Method and apparatus for providing voice communication service in a wireless communications system
US7916666B2 (en) * 2007-04-03 2011-03-29 Itt Manufacturing Enterprises, Inc. Reliable broadcast protocol and apparatus for sensor networks
US7936695B2 (en) * 2007-05-14 2011-05-03 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US8023419B2 (en) 2007-05-14 2011-09-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
US7835406B2 (en) * 2007-06-18 2010-11-16 Cisco Technology, Inc. Surrogate stream for monitoring realtime media
US7817546B2 (en) 2007-07-06 2010-10-19 Cisco Technology, Inc. Quasi RTP metrics for non-RTP media flows
CN101849400A (zh) * 2007-11-06 2010-09-29 阿尔卡特朗讯公司 移动通信***中媒体流服务的递送方法
US8490124B2 (en) * 2008-05-29 2013-07-16 Qualcomm Incorporated Method and apparatus for improving performance and user experience of a mobile broadcast receiver
US20100222053A1 (en) * 2009-02-27 2010-09-02 Girisrinivasarao Athulurutirumala Arrangement and methods for establishing a telecommunication connection based on a heuristic model
US9106414B2 (en) * 2009-09-09 2015-08-11 Edward W. Laves Method and apparatus for wirelessly transmitting high volume content to an electronic device
US8301982B2 (en) * 2009-11-18 2012-10-30 Cisco Technology, Inc. RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
EP2388963B1 (de) * 2010-05-20 2012-10-03 NTT DoCoMo, Inc. Verfahren und Gerät für die Ablaufkoordination von Paketen
CN102647665B (zh) * 2011-02-21 2015-02-04 华为技术有限公司 群组消息处理方法、设备及***
US9391671B2 (en) * 2011-05-06 2016-07-12 Samsung Electronics Co., Ltd. Wireless power transmission and charging system and method thereof
US20150264599A1 (en) * 2014-03-12 2015-09-17 Cinet Inc. Non-intrusive method of sending the transmission configuration information from the transmitter to the receiver
CN106686358B (zh) * 2017-01-26 2019-05-03 江苏长天智远交通科技有限公司 基于rtsp协议的设备控制及通道限制方法、装置及***
US11895200B2 (en) * 2017-03-24 2024-02-06 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Access to an operator panel over an out-of-band local network domain
JP6853897B2 (ja) 2017-03-31 2021-03-31 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 無人航空機から送信される無線フレームにおけるジオロケーション情報のブロードキャスト
CN110266415B (zh) * 2019-06-24 2022-04-01 南京邮电大学 一种基于认知无线网络的鲁棒主动监听***的建立方法
US11385676B2 (en) * 2019-12-17 2022-07-12 Qualcomm Incorporated Single-counter, multi-trigger systems and methods in communication systems

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5101501A (en) 1989-11-07 1992-03-31 Qualcomm Incorporated Method and system for providing a soft handoff in communications in a cdma cellular telephone system
US5353332A (en) * 1992-09-16 1994-10-04 Ericsson Ge Mobile Communications Inc. Method and apparatus for communication control in a radiotelephone system
US5768276A (en) * 1992-10-05 1998-06-16 Telefonaktiebolaget Lm Ericsson Digital control channels having logical channels supporting broadcast SMS
US5448568A (en) * 1994-04-28 1995-09-05 Thomson Consumer Electronics, Inc. System of transmitting an interactive TV signal
US5473609A (en) * 1994-05-26 1995-12-05 Thomson Consumer Electronics, Inc. Method and apparatus for processing a conditional access program guide as for a satellite TV service
US5990928A (en) * 1997-05-30 1999-11-23 Rockwell International Corporation Method and apparatus for receiving broadcast entertainment transmissions at a moving receiver station
US6081907A (en) 1997-06-09 2000-06-27 Microsoft Corporation Data delivery system and method for delivering data and redundant information over a unidirectional network
US6108706A (en) 1997-06-09 2000-08-22 Microsoft Corporation Transmission announcement system and method for announcing upcoming data transmissions over a broadcast network
US6032197A (en) 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
US6665718B1 (en) * 1997-10-14 2003-12-16 Lucent Technologies Inc. Mobility management system
US6510515B1 (en) 1998-06-15 2003-01-21 Telefonaktlebolaget Lm Ericsson Broadcast service access control
EP1024661A3 (de) 1999-01-27 2002-07-17 Hughes Electronics Corporation Elektronische Programmführung mit Bild und Graphik
US6614804B1 (en) * 1999-03-22 2003-09-02 Webtv Networks, Inc. Method and apparatus for remote update of clients by a server via broadcast satellite
WO2000079734A1 (en) 1999-06-18 2000-12-28 The Trustees Of Columbia University In The City Of New York System and method for receiving over a network a broadcast from a broadcast source

Also Published As

Publication number Publication date
EP1374506A2 (de) 2004-01-02
CN100474836C (zh) 2009-04-01
BRPI0208735B1 (pt) 2016-06-07
WO2002080588A2 (en) 2002-10-10
CN1611036A (zh) 2005-04-27
DE60211136D1 (de) 2006-06-08
KR20030088048A (ko) 2003-11-15
JP2004533746A (ja) 2004-11-04
BR0208735A (pt) 2004-07-13
MXPA03008877A (es) 2004-12-06
HK1075152A1 (en) 2005-12-02
KR100891882B1 (ko) 2009-04-03
CA2442650C (en) 2011-05-24
CA2442650A1 (en) 2002-10-10
EP1374506B1 (de) 2006-05-03
US6909702B2 (en) 2005-06-21
WO2002080588A3 (en) 2003-03-13
JP4615828B2 (ja) 2011-01-19
ATE325487T1 (de) 2006-06-15
TW577204B (en) 2004-02-21
US20020141447A1 (en) 2002-10-03
AU2002306978A1 (en) 2002-10-15

Similar Documents

Publication Publication Date Title
DE60211136T2 (de) Verfahren und vorrichtung zur ausser-band-übetragung von rundfunkdienst-optionen in einem drahtlosen kommunikationssystem
EP1374483B1 (de) Verfahren und vorrichtung zur mehrfachsendung in einem funkkommunikationssystem
US7693508B2 (en) Method and apparatus for broadcast signaling in a wireless communication system
US8077679B2 (en) Method and apparatus for providing protocol options in a wireless communication system
US7031666B2 (en) Method and apparatus for header compression in a wireless communication system
US6707801B2 (en) Method and apparatus for data transport in a wireless communication system
US7184789B2 (en) Method and apparatus for data packet transport in a wireless communication system using an internet protocol
EP2037623B1 (de) Auswählen eines Paketdatenzugangsknotens für Multicast- bzw. Broadcastdienste
US20020141371A1 (en) Method and apparatus for transmission framing in a wireless communication system
AU2002254445A1 (en) Method and apparatus for broadcasting signaling in a wireless communication system

Legal Events

Date Code Title Description
8364 No opposition during term of opposition