TW201713095A - Content protection and modification detection in adaptive streaming and transport streams - Google Patents

Abstract

Systems, methods, and instrumentalities are disclosed for content protection and modification detection in adaptive streaming and transport streams. Content protection may be multi-level, e.g., payload signatures and interval signatures. Content protection may be multi-layered, e.g., overlapping signatures. Signatures may be carried inband, e.g., in transport segments. Content protection may be used for modification detection. Modification detection may be multi-level, e.g., container level detection and bitstream level detection. Types of modifications and sources may be detected and distinguished, e.g., detection of reordering, detection of benign and/or malicious modification of one or more types of content (e.g., bitstream, metadata) by insertion and/or removal of content.

Description

Content protection and modification detection in adaptive stream and transport stream

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of the benefit of the benefit of the benefit of the benefit of the benefit of the benefit of the benefit of the benefit of the benefit.

Adaptive streaming and transport streams are not supported by anti-modification techniques (eg, HTTPS, out-of-band segment integrity verification, and HLS). Anti-modification techniques have undesired effects. For example, anti-modification techniques may not allow "benign" modifications (eg, event insertion, PCR re-marking), re-multiplexing, and/or scaling. Anti-modification techniques may cause additional requests for each segment, create a single point of failure, and/or be incompatible with possible adaptive and transport streams.

However, there is a need for content protection and modification detection in adaptive streaming and transport streaming.

Systems, methods, and apparatus for verifying the reliability of content in adaptive streaming, including receiving a media presentation description (MPD) profile, receiving a key, requesting content based on the MPD, receiving including multiple packets, and in-band (inband) the content of the signature, determining the authenticity of the content (eg, by performing a key/signature confirmation check), and upon confirming the authenticity of the content, decoding at least one of the contents.

A system, method and apparatus for protecting content in adaptive streaming is disclosed, comprising receiving a request for content based on a Media Presentation Description (MPD) profile; and transmitting content based on the request, the content comprising a plurality of packets And an in-band signature, wherein the authenticity of the in-band signature is determined using a key to confirm that no unauthorized additions or removals have been performed for the content.

A system, method and apparatus for inserting an advertisement in an adaptive stream, comprising receiving content, the content comprising a plurality of packets; and inserting an advertisement and an in-band signature in the content, wherein authenticity of the in-band signature It is determined using a key to determine that the insertion of the advertisement into the content is authorized.

A detailed description of the exemplary embodiments will now be described with reference to the accompanying drawings. While this description provides a detailed example of possible implementations, it is to be understood that the details are intended to be illustrative, and in no way limit the scope of the application.

Systems, methods, and facilities for content protection and modification detection in adaptive streaming and transport streams are disclosed. Content protection can be multi-level, such as payload signatures and interval signatures. Content protection can be multi-layered, such as overlapping signatures. The signature can be carried in-band, for example, in a segment such as a Transport Stream (TS) segment. Content protection can be used to modify the detection. Modification detection can be multi-level, such as container level detection and bit stream level detection. The types of resources and modifications can be detected and distinguished, such as detection of reordering, benignity for one or more types of content (eg, bitstreams, data elements) by and/or removal of content and/or Or maliciously modified detection.

Content that has been maliciously modified is protected. Protection is desirable, for example, when the media is transmitted over an open or otherwise vulnerable network. The content can be protected, for example, by including a signature in the MPEG-2 TS. Signing protects content from unauthorized tampering. Content can be protected in whole or in part. Protection can be reverse compatible. Protection (for example by including a signature in the content) can be minimally intrusive. The signature can be added, for example, for one or more content component units. The content component unit can be, for example, a PES packet or a segment. The interval signature can be added to the signature data interval (eg, portion) of the transport stream. The signed data interval is applied to the data in the segment (eg, DASH content segmentation) or to the data in the continuous transmission stream. For example, the data interval can include a byte between two flags. The signed data interval may, for example, not allow for adding content and/or not allowing removal of content. Benign streaming modifications can be detectable. Content protection and detection of content modifications are applicable to, for example, MPEG DASH, SCTE ATS, 3GPP SA4 and SA3, and ETSI (HbbTV).

An "on the cloud" (OTT) stream can, for example, utilize the Internet as a delivery medium for video content. Video content can include high quality video content. Video-capable devices include, for example, mobile devices, Internet set-top boxes (STBs), and network TVs.

A "closed" network can be controlled by a multi-system operator (MSO). The Internet can be a "best effort" environment. The bandwidth and delay can vary. Network conditions can be variable, for example, in a mobile network. Dynamic adaptability to network changes can be used, for example, to provide a tolerable user experience.

Adaptability (eg, scalable, rate adaptive) streaming can be implemented, for example, by HTTP streaming or UDP streaming. Internet video streaming can take advantage of, for example, the advantages of the HTTP architecture, such as a content distribution network (CDN) and HTTP support on multiple platforms and devices. When HTTP traffic is allowed behind a firewall, the firewall can not allow UDP traffic. The HTTP adaptive stream of assets may be, for example, segmented (eg, virtually or physically) and disclosed to the CDN.

The client can obtain knowledge of the public alternative encoding (eg, representation) of the streaming asset. The client can construct or use a URL to, for example, download a segment from a given representation. As an example, an adaptive bit rate (ABR) client can observe network conditions. The ABR client may, for example, determine one or more parameters, such as bit rate, quality, and/or resolution, to provide a desired quality of experience on the client device at one or more time instances. When the client determines the best URL to use, the client can download the segment, for example, based on the URL selected to provide the desired quality to publish an HTTP GET request.

MPEG DASH can be established, for example, on top of an HTTP/TCP/IP stack. MPEG DASH can define a list format, such as a Media Presentation Description (MPD). MPEG DASH may, for example, define a segmentation format for ISO base media file formats and/or MPEG-2 transport streams. The transport stream (TS) may include an MPEG-2 transport stream. DASH can define quality metric groups at the network, client-side, and/or media presentation levels. One or more quality metrics may enable interoperable techniques to monitor quality of experience and quality of service.

DASH indicates an encoded version that can be defined as a subset of assets or all assets. The representation can be, for example, a complete asset or a subset of its components. An example of the representation may be, for example, an ISO-BMFF including an unmultiplexed 2.5 Mbps 720p AVC video and an ISO-BMFF representation of 96 Kbps MPEG-4 AAC audio for different languages. A TS including video, audio, and subtitles can be a representation of a single multiplex. Structures can be combined. For example, video and English audio can be a single multiplex representation, while Spanish and Chinese audio tracks can be a single unmultiplexed representation.

A segment (eg, a DASH segment) can be defined as an addressable unit of media material. In an example, the segmentation can be the least or smallest individual addressable unit. The segmentation can be, for example, an entity that can be downloaded using a URL via an MPD advertisement. An example of a media segmentation may be a 4 second portion of a live broadcast at play time 0:42:38 to 0:42:42, available in a 3 minute time window. An example of a media segmentation may be a full on-demand movie available during the movie's licensed period.

The MPD can include an XML file. MPD can advertise available media. The MPD can provide information that the client can use to, for example, select representations, make adaptive decisions, and/or retrieve segments from the network. The MPD can be independent of the segmentation. The MPD can communicate one or more attributes. One or more attributes are used to determine if the representation can be played. One or more attributes may be used to determine one or more functional attributes of the representation, such as whether the segmentation begins at a random access point. The MPD can use a hierarchical data model to, for example, describe the presentation.

Representation can be a conceptual level of the hierarchical data model (for example, low level). The MPD signal information may include, for example, bandwidth, codecs for presentation, and techniques for reconstructing URLs to access segments. Additional information can be provided at the conceptual level. Additional information may include, for example, starting from a trick mode, random access information, layer and view information for scaling and multi-view codecs, and/or a solution supported by the client that can play a given representation.

DASH provides flexible URL construction capabilities. DASH can provide a single-chip URL for each segment. DASH may allow for dynamic construction of URLs, for example by combining portions of URLs (eg, base URLs). The base URL can appear at different levels of the hierarchical data model. Multiple base URLs can be used. Segmentation can have multipath functionality. Segmentation can be requested from one or more locations, which can improve performance and reliability.

DASH may allow for the use of predefined variables (eg, segment number, segmentation time) and/or output style syntax, for example for on-the-fly construction of URLs. URLs can be constructed using templates. This can be helpful, for example, when there are additionally explicit URLs or byte ranges for many short segments in one or more representations.

As an example of a template representation, seg_$Index%05$.ts may represent one or more segments (eg, seg_00001.ts, seg_00002.ts, . . . seg_03600.ts). A segment can be represented, for example, whether it was acquired at the time the MPD was taken. Multi-segment representations can be used in templates.

Different representations of assets and/or components can be grouped into adaptive sets. Different representations in the adaptive set can render the same content. The client can switch between representations.

An example of an adaptive set may be a collection of 10 representations of video encoded at different bit rates and resolutions. When presenting content to, for example, an observer, the client may switch between representations at the segmentation or segmentation granularity, for example. Under, for example, segmentation level restrictions, the presentation can be seamless when switching between representations. One or more restrictions may be implemented, for example, in a DASH profile and/or as a subset of DASH employed by one or more SDOs. Segmentation restrictions can be applied, for example, to one or more representations in an adaptive set.

The period can be a subset of the time limit of the presentation. An adaptive set can be effective during the period. For example, in codecs, bit rate, etc., sets of adaptations that are short at different times may have the same, similar, and/or different representations. The MPD may have one or more periods of time for the duration of the asset. The period can be used, for example, for advertising production. A separate period can be dedicated to one or more portions of the asset and/or one or more advertisements.

The MPD can be an XML file that shows the hierarchy. A hierarchy may, for example, have global presentation level attributes (eg, timing) and/or epoch level attributes. A hierarchy can have one or more adaptive sets available for a period. Indicates that it can be the lowest level of the hierarchy.

DASH can use a version of XLink (eg, a simplified version) to, for example, allow portions of the MPD to be downloaded from a remote location (eg, a period). In an example related to ad insertion, for example, when the precise timing of the ad insertion is known in advance, portions of the MPD can be downloaded from the remote location. The ad server can instantly determine the ad.

Dynamic MPD can be changed. Dynamic MPD can be periodically reloaded by the client. Static MPD can be effective for all or part of the presentation. Static MPDs can be used, for example, for VoD applications. Dynamic MPDs can be used, for example, for on-site and/or PVR applications.

The media segment can be a time limited portion of the representation. The approximate segmentation duration can occur in the MPD. The segmentation duration may be the same or may be different for all segments. The segmentation duration allows the segment to have a tolerance limit, which can be expressed as a percentage (eg, a 25% tolerance limit).

The MPD may include information about media segments where the time of the MPD read by the UE is not available, for example, in a live broadcast scenario. As an example, one or more segments may be available in a defined availability time window. The time window can be calculated, for example, based on wall clock time and segment duration.

The segmentation type can be an index segmentation. The index segment can appear, for example, as a side profile or in a media segment. Index segments can include timing and/or random access information. The index can be used, for example, for random access, trick mode, and/or bit stream switching, which can render bit stream switching more efficiently. Indexes can be used for VoD and/or PVR type applications.

Segmentation level and presentation level attributes can be used, for example, to implement bit stream switching. DASH can indicate the functional requirements for attributes that can be represented in the MPD. Segmented format descriptions can have format level restrictions that correspond to functional requirements.

The media segment i representing R can be represented as S _R ( i ). The duration of the media segment can be expressed as D ( S _R ( i )). The media segment can have the earliest presentation time, which is represented as EPT ( S _R ( i )). The EPT may correspond to, for example, the earliest presentation time of the segment, or the time at which the segment can be played during random access.

The time alignment of the segments used for representation in the adaptive set can be used, for example, when supporting efficient handoffs. The relationship between the representation R _a and R _b and the segment i can be expressed, for example, according to Equation 1: (Equation 1)

For example, when the relationship provided in Equation 1 is satisfied and when the segment starts with a random access point, the handover occurs at the segmentation boundary without overlapping download and double decoding. For example, when an index is used, a sub-segment starts with a random access point and Equation 1 is satisfied, bit stream switching can occur at the sub-segment level.

Time alignment and random access point layout can be limited. For example, at a segmentation boundary and a closed GOP, the restriction can be translated into a code with a matching IDR frame.

The DASH client can conceptually include access to the client, media engine, and applications. The access client can be an HTTP client. The media engine can decode and display the media provided to it. The application can receive events from the accessing client. One or more interfaces can be defined, such as an online format for MPD and segmentation.

Figure 1 is a diagram of an example of a DASH system model. The timing behavior of the DASH client can be different, for example, from Apple HLS. In the example of Apple HLS, the segments mentioned in the list can be valid, and the client can poll the new list. The DASH MPD can reduce the rotation behavior, for example, by defining the MPD update frequency and/or allowing calculation of segment availability.

Static MPDs can be valid (eg, always valid). Dynamic MPD can be effective, for example, at the time it is taken by the client, or for a explicitly described renewed period. The MPD can be versioned, for example, by explicitly revealing its disclosure time.

The MPD can provide the available time of the earliest segment of the period, which can be represented as T _A (0). The media segment n may be available starting at, for example, the time provided by Equation 2: (Equation 2)

The relationship given by Equation 2 can be used, for example, at the duration of the time offset buffer T _t s , which can be explicitly described in the MPD. The available window size may have an impact on capturing TV functionality (eg, direct impact), which can be implemented in a DASH deployment. The segmentation available time can be trusted by the accessing user, for example, when it falls within the MPD validity period.

The MPD can be declared to represent the bandwidth B _{R of R.} The MPD can define a global minimum buffer time, which can be expressed as BT _min . The accessing client can, for example, pass the segment to the media engine after B _R × BT _min bits have been downloaded. For example, when a segment starts with a random access point, the time (eg, the earliest time) that segment n can be passed to the media engine can be given. It can represent the download time of segment n . The DASH client can start playing immediately to minimize latency. The MPD can suggest a presentation delay (eg, as an offset from the slave) to synchronize, for example, between different clients. Segmented HTTP GET requests can be synchronized.

MPD validity and/or segmentation validity can be calculated using absolute (eg, wall clock) time. Media time can be represented in segments. The offset can be developed between the encoder and the client clock, for example in the case of live broadcasts. The offset can be resolved at the container level, for example when MPEG-2 TS and ISO-BMFF provide synchronization functionality.

Events can be an extension of DASH. "Push" style events can be emulated, for example, using frequency rotation in no country and client driven HTTP. Upcoming commercial breaks may be signaled in advance (eg, 3 to 8 seconds before the start of the ad insertion practice of the cable/IPTV system).

Events can be "blobs", such as with explicit time and duration information and application-specific payloads. The in-band event can be a message box, which can occur, for example, at the beginning of a media segment. An MPD event can be a epoch-level list of time elements. DASH can define an MPD validity expiration event that identifies the oldest MPD version as valid after a given presentation event.

DASH can be used in conjunction with Digital Rights Management (DRM). DASH can support signaling DRM schemes and their attributes, for example, within the MPD. The DRM scheme can be communicated, for example, via a Content Protection descriptor. The opaque value can be passed in the content protection descriptor. The DRM scheme can be communicated, for example, with the definition of a unique identifier and opaque value for a given scheme. The DRM scheme can be communicated, for example, in a scheme specific namespace.

For example, content can be protected with public encryption (CENC) for ISO-BMFF or segmentation encryption and authentication. Encryption, for example, may indicate which portions of the sample are encrypted and/or how the encrypted relay material is being signaled in the track. The DRM module can deliver the key to the client, for example, while encrypting the relay material in the segment. Encryption can use, for example, AES-CTR or AES-CBC mode. The CENC framework can be, for example, extensible to use other encryption algorithms. Public encryption can be used with one or more DRM systems.

DASH Segment Encryption and Authentication (DASH-SEA) can be used in a segmented format. Encrypted relay data can be delivered via MPD. For example, the MPD may include information about which key was used for segmentation and/or how to obtain the key. The system may include, for example, HLS with AES-CBC encryption and HTTPS-based key transmission. MPEG-2 TS media segments can be compatible with encrypted HLS segments. The system can be scalable to allow for other encryption algorithms and more DRM systems.

DASH-SEA can provide a segmentation authenticity framework. The segmentation authenticity framework may, for example, confirm that the segment received by the client is a segment that the MPD initiator intends to receive at the client. The confirmation can be performed, for example, using a MAC or a digital algorithm. The segmentation authenticity framework prevents content modification in the network. Modifications can be, for example, replacements or changes to in-band events.

The TS can specify a container format for encapsulating the packetized base stream. The TS can have error correction and stream synchronization features.

A packet can represent a data unit in the TS. The packet can include a sync byte and a header. For example, when being addressed in an adaptive field, the packet may include one or more transmission fields. The packet can include a payload. The packet can have a fixed length, such as 188 bytes.

The TS can have a program concept. The program can be described by a Program Map Table (PMT). The PMT can have a unique identifier (PID). The elementary stream associated with the program may have a PID listed in the PMT. A TS used in a digital television may, for example, include three programs that can represent three television channels. In an example, the channel can include a video stream, one or more audio streams, and relay data. The recipient can decode the "channel" by, for example, decoding the payload of the PID associated with the program. The receiver can discard the contents of other PIDs. A TS having more than one program may be referred to as a Multi-Program Transport Stream (MPTS). A TS having one program may be referred to as a Single Program Transport Stream (SPTS).

The program can have program specific information (PSI). For example, there may be four PSI tables: Program Association Table (PAT), Program Map Table (PMT), Conditional Access Table (CAT), and Network Information Table (NIT).

The PAT can list one or more programs available in the transport stream. The program listed in the PAT can be identified, for example, by 16 bits, which is called program_number. The programs listed in the PAT may have associated values for the PID of the PMT.

The program number value 0x0000 can be reserved, for example, to specify a PID for finding a network information table (NIT). For example, when a PID is not specified, a preset PID value (for example, (0x0010)) can be used for the NIT. A TS packet including PAT information may have, for example, a PID value of 0x0000.

The PMT can include information about one or more programs. In an example, the program may have a one-to-one correspondence with the PMT. More than one PMT portion can be transmitted on the PID, for example, in MPEG-2. A single TS PID can include PMT information for more than one program. In an example, the PMT can be transmitted on a separate PID that is not used for other packets (eg, ATSC and SCTE). The PMT can provide information about the programs presented in the transport stream. The information may include, for example, a program number and a basic stream list for the MPEG-2 program being described.

There may be locations for one or more descriptors describing, for example, an MPEG-2 program (eg, all thereof) and/or one or more descriptors for one or more elementary streams. The base stream can be labeled with a stream type value.

The Program Clock Reference (PCR) can be transmitted, for example, in an adaptive field of the MPEG-2 TS packet. The PCR may cause the decoder to present synchronized content, such as an audio track that matches the associated video. The PCR can be transmitted periodically, for example every 100 ms. A PID having, for example, a PCR for an MPEG-2 program can be identified, for example, by a pcr_pid value in an associated PMT. The value of the PCR can be employed, for example, to generate a system_timing_clock in the decoder. The System Time Clock (STC) decoder provides an accurate time base to synchronize audio and video base streams. As an example, the timing in MPEG2 can refer to the STC. The Presentation Time Stamp (PTS) can be associated with PCR. The number of bits (eg, 33 bits) may be based on a PCR (eg, a 90 kHz clock). The number of bits (eg, the last 9 bits) may be based on the same or different PCR (eg, a 27 MHz clock). The PCR can have maximum jitter (eg +/- 500 ns).

The transmission scheme has a fixed bit rate for the transport stream. The multiplexer can insert one or more packets (e.g., empty packets) to, for example, maintain a fixed bit rate in the transport stream. Empty packets may not include data. The receiver can ignore the contents of the empty packet. The PID value (for example, 0x1FFF) can be reserved for empty packets.

The TS can deliver HTTP links, DASH MPDs, and/or HTML content. A framework for the delivery of timelines for external data (eg, TEMI defined in the MPEG-2 system) may, for example, allow for the transmission of HTTP links embedded in the TS. The DSM-CC (eg, in MPEG-2 TS) may, for example, carry an archive in the TS. The HTML band can be carried by, for example, HbbTV. Advanced television sets (eg, smart TVs) can, for example, render HTML, run JavaScript, and the like. The MPD can be carried in-band by DASH MPD update and MPD patching events. The DASH event can be carried, for example, in an MPEG-2 transport stream (e.g., on PID 0x004).

Adaptive Transport Streaming (ATS) can provide backward compatible virtual segments. The ATS can add restrictions to MPEG-2 TS streams to, for example, allow for conversion to one or more adaptive streaming technologies. A single program MPEG-2 TS stream can be playable in its normal context. Streaming can be adjusted into an adaptive streaming workflow. The ATS stream can be identified as MPEG-2 TS.

The ATS may have, for example, an encoder boundary point (EBP) structure, an EBP descriptor, and a resource description. The EBP structure can be a flag in the TS packet. The EBP descriptor can describe multiplex as part of the in-band system information. The resource description can be a list that defines the ATS collection. The ATS collection can be a collection of files and/or multiplexes associated with the content.

The EBP structure can be carried, for example, in an adaptive field of the TS packet. The EBP structure can be inserted, for example, during the transcoding phase. The EBP structure can provide information such as one or more of a stream-up indicator, a wall clock time indicator, information about upcoming segments, tags, and unique identifiers.

The stream indication indicator can indicate a segmentation point (eg, a virtual segment). The wall clock time indicator can be accompanied by a segmentation (eg, each segment). Information about upcoming segments may include, for example, a segment access point (SAP) type. Tags (eg, universal tags) can be provided in the EBP structure. The unique identification of the current segment can be, for example, a segment number.

The EBP descriptor in the PMT can describe one or more elements of the ATS set carried in the multiplex. The description may include information such as one or more locations of the EBP structure in one or more elementary streams, one or more random access features, and a desired segment size.

Media segments can be sent on an insecure link (eg, HTTP). For example, an insecure link can be used for performance reasons. Entities in the network can modify the content in the HTTP response. The masquerading transmitter can be used to generate modified content for broadcast delivery over the air.

Man-in-the-middle attacks, for example, may be dangerous in audition content, as there may be one or more weaknesses exploiting the development device to maliciously design parameters and/or replace provider-inserted advertisements. For example, when content causes recipient actions (for example, publishing HTTP GETs, parsing files, executing scripts, etc.), man-in-the-middle attacks can be dangerous. As an example, a computer (eg, HbbTV's Smart TV) may be tricked into running a malicious JavaScript script, or the conversation may be hijacked (eg, due to changes to embedded MPD or TEMI data may be changed or replaced). A serious man-in-the-middle attack has been reported against HbbTV.

DRM may not mitigate man-in-the-middle attacks. DRM technology protects media content from unauthorized browsing. DRM technology (possibly except for full segmentation encryption via Apple HLS) does not provide protection against media modifications.

Content changes may be benign. Examples of benign changes may be, for example, track additions, ad insertion tags, empty packet additions to fill the TS to a particular bit rate, single stream streaming from a multi-program transport stream, changing timestamps, changing PMT or PAT, etc. (for example, in MPEG-2 TS). Changes may result in invalid content, and it may be useful to detect such changes in order to isolate the workflow phase in which the violation first occurred.

Adaptive streaming cannot be well supported by data anti-modification techniques (eg, HTTPS, out-of-band segment integrity verification and HLS), for example because these techniques do not allow "benign" modifications (eg, event insertion, PCR re-marking (restamp) )), does not allow re-multiplexing and does not allow for scalability, triggers additional requests per segment, creates a single point of failure, and/or is incompatible with continuous streaming.

HTTPS for segmented downloads provides security but lacks scalability.

For example, when there is a single entity (or group of entities) with the same key and generating a bitwise equivalent segment, out-of-band segment integrity verification (eg, DASH Part 4 ISO/IEC 23009-4) can be used to block the attack. The segment is modified by modifying the segment or event (for example, by CDN or re-multiplexing). Out-of-band segment integrity verification can create a single point of failure and can trigger additional requests per segment (eg, HTTPS client requests for each individual request and fetched segment). Large live viewers (eg, viewers browsing broadcast sports events) can access the same server at the same time to create contention and failure points. Out-of-band segment integrity verification may not work for continuous streaming (for example, may not be supported).

HLS can define full segmentation encryption, which protects the media from being modified. The continuous delivery of MPEG-2 TS can make data protection techniques rely on discreet fully encrypted content segmentation or HTTPS unrelated use, such as when IP multicast can be used for this purpose. Fully encrypted content may not be MPEG-2 TS and is not possible, for example, without exiting the device for processing and/or changes such as ad tag insertion or re-multiplexing.

The signature can be carried in-band. As an example, the signature can be placed in a transport stream such as MPEG-2 TS. The signature can be carried by a TS segment (eg, a TS segment in MPEG DASH). The signature may be carried in a portion of a continuous stream (such as in one or more TSs) such as a broadcast TV (terrestrial, cable, satellite, etc.).

The signature may be a message authentication code (MAC), which may be carried in one or more (eg, each) segments, sub-segments, at intervals in consecutive streams, or in content components in a continuous stream .

Figure 2 is an illustration of an example of a payload signature in a TS packet. The "paid payload" signature can be used, for example, for partial (incomplete) packetized payloads of the basic stream in the TS, for the entire (complete) PES packet (e.g., with PES packets with timing) or for signature on the segment. The segments can be used, for example, for PSI (PAT/PMT) and/or SCTE 35. In the example description of FIG. 2, the payload signature for the complete PES packet is calculated and carried in the TS packet associated with one or more TS payloads carrying the PES packet material. The payload signature can be carried, for example, in an adaptive field of the TS packet. The payload signature may be carried in a first TS packet associated with the PES packet as described, for example, in FIG. The payload signature may be carried in the last TS packet associated with the PES packet or in any TS packet associated with the PES packet. Descriptors can be used to carry payload signatures.

The payload signature can improve or guarantee the integrity and/or authenticity of the content. The content may be, for example, one or more carrying portions of the content (eg, audio, video, text, material), such as content carried in a PES packet or section.

The synthesis of the stream (eg TS) and the payload signature can be modified. As an example, the links and MPDs in the stream can be signed by the content producer. The packager can create a new stream that includes content signed by the producer in addition to other content.

As an example, multiple content producers or content sources may sign on various portions of the content that they make or initiate. Packagers can combine content from different sources. For example, the packager may combine the first content signed by the first content producer, the second content signed by the second content producer, and the third content that may not be signed. The key (eg, the key used to verify the signature at the client) can be specified for different signatures by the messaging key ID.

Figure 3 is an exemplary diagram of a flag frame for interval signatures. The "interval" signature can be carried in the "flag" packet. The flag TS packet may be carried, for example, in a payload, in an adaptive field of the TS packet, or as part of a virtual segmentation structure (eg, EBP). The flag TS packet can be on the same PID as the media itself (e.g., video PID) or on a separate PID, e.g., using private or sector syntax. A flag packet or an interval signature may relate to a packet (eg, all packets) between "flag" packets. For example, the interval signature can be carried in a TS packet in MPEG-2. A "flag" packet may be, for example, any MPEG-2 TS packet carrying a slot signature. As an example, an EBP that can be used to indicate content having a virtual boundary point for segmentation (eg, a content archive or a content stream) can have an interval signature.

Figure 4 is an illustration of an example of an interval signature in a continuous TS packet stream. In Figure 4, the interval signature may be carried in-band in the TS (e.g., in the adaptive field of the flag TS packet), and the data interval in which the interval signature is calculated may be based on the location of the current and previous flag TS packets. . The flag TS packet may be any TS packet carrying a signature, an interval signature, or a descriptor identifying or carrying a signature for transmitting the stream. In one or more embodiments, the interval signature can be calculated over a data interval of all TS packets including the previous and current flag packets. In one or more embodiments (eg, as depicted in FIG. 4), the data interval in which the interval signature can be calculated can include portions of the flag packet itself.

Figure 5 is an exemplary diagram of a hierarchical interval signature for a continuous TS packet stream. In Figure 5, pairs of overlapping interval signatures (e.g., represented as "signatures" and "overlapping signatures" in Figure 5) are taken in the TS (e.g., in the adaptive field of the flag TS packet) Carry inside. As shown in FIG. 5, the "signature" may be an interval signature calculated over a data interval, which may include a TS packet between the previous and current flag packets, and may include the previous and/or current flag packets themselves. section. An "overlapping signature" may be an interval signature calculated over a data interval that overlaps, for example, with a data interval for "signature." As shown in FIG. 5, the data interval for "overlapping signatures" may include a previous flag packet. Although not shown in FIG. 5, the data interval for "overlapping signatures" may be extended to include additional material from TS packets before the previous flag packet or after the previous flag packet.

Figure 6 is an exemplary diagram of a hierarchical interval signature for a segmented TS packet. As shown in FIG. 6, the overlap signature scheme of FIG. 5 can be applied to a range of TS packets that span one or more segments (eg, one or more DASH segments). As shown in Figure 6, the signature interval can be set such that a set of signatures covers some or all of the segments. A single segment can be arbitrarily segmented using multiple flag packets, whereby any number of "signature" and "overlap signature" pairs can define overlapping signatures that are signed within a single segment (not shown). In any of Figures 4, 5, and 6, it should be understood that the illustrated modes can be extended from additional prior flag packets and extended to additional subsequent flag packets, each of which can carry an interval signature value. , such as "signature" and "overlapping signature." Moreover, any or all of the TS packets shown in these figures may additionally carry a payload signature, as discussed previously (eg, as depicted in FIG. 2).

Interval signatures can be applied to continuous (non-segmented) content (eg, continuous MPEG-2 TS) and/or to segmented content (eg, segmented MPEG-2 TS or MPEG DASH segments) One or more segments. Interval signatures can span multiple segments, which can be referred to as multi-segment intervals. Interval signatures can be mixed. For example, the interval signature for the segmentation may be carried in a different segment (eg, the previously segmented signature may be carried in the current segment, or the currently segmented signature may be carried in the previous segment).

Signatures can overlap. Different levels of signatures can be applied to the packet. As an example. The interval signature can be applied from the first byte of the previous flag packet to the last byte of the signature of the current flag packet. As an example, a payload signature can be carried that signs the data of the upcoming PES packet and the previous PES packet.

An external predictable identifier (eg, a segment number per MPD or per EBP structure) may be used (eg, individually pre-considered or transmitted) to, for example, support random access. The first overlap signature may be unverifiable, for example if it is in a random access operation (eg random access in MPEG-2 DASH, random access for continuous MPEG-2 TS, channel between streams) The first overlapping signature after the switch, file access, etc.). As an example, the segment number may be an identifier embedded in the EBP structure, which may be used in random access of consecutive streams.

Benign streaming modifications can rewrite content and avoid signatures. In an example scenario, the component may be complete (eg, the payload signature is accurate) and may have no unsigned elements, but there may be no interval signatures, or the provided interval signatures do not match the modifications (eg, benign modifications, Re-do or re-edit the content. This scenario can occur for a variety of reasons. Multiple multiplexes can happen. Empty packets can be added to, for example, cause the stream to have a fixed bit rate. PSI and SCTE 35 data can be moved. Different stages of processing can use the same key. The payload signature may be correct, but the interval signature may be erroneous (for example, it may not match its apparently calculated data interval). This kind of scene can be transferred. As an example, the signature of the previous and/or next TS packet (eg, a neighbor signature) may be carried, for example, at a location that may carry a "pay" signature.

The signature can be, for example, a symmetric HMAC or an AES-GMAC (Galois message verification code). HMAC can be based on SHA. The signature load can be relatively small. HMAC-MD5 can be 128 bits long. HMAC-SHA1 can be 160 bits. HMAC-SHA256 can be 256 bits in length. The GMAC load can be reduced, for example, by signaling the initialization vector.

The key used for one or more signatures may be identified, for example, in one or more packets. The key is not carried in-band (eg, in content or in an in-band MPD), for example for security reasons. There are more than one set of keys. Different keys are used to sign intervals, different content components, and PSI tables. The key exchange mechanism can be used. Examples include HTTPS GET for the key URL provided in the manifest (MPD or m3u8). The key can be provided in the body of the response to the HTTP GET (eg, to the media client).

The recipient may calculate the signature from the received content segment or the received content stream, for example, during the time between signature reception and content decoding. The recipient can compare the calculated signature with the signature received from the stream. Multiple keys can exist. Different keys may, for example, correspond to different entities in the network, or different stages in the content generation and/or distribution chain, such as encoders and wrappers. The signature timestamp can be transmitted with the key identifier, for example such that the signature on the entity and/or the signature time can be identifiable.

The recipient may detect the addition or removal of the component by detecting that one or more of the payload signatures are correct and detecting that one or more of the interval signatures are incorrect or missing. The recipient can discover the stage in which one or more changes are introduced. The encoder can generate audiovisual content in the stage, and another entity can insert the advertising content in another stage. An event can be added by another entity at another stage.

In an example, a layered signature can be applied to the MPEG-2 TS. In an example, a layered signature can be applied to ISO-BMFF. In an example, the "flag" can be an ISO-BMFF box. The signature can cover current and previous fragments and/or tracks within the segment.

The descriptor structure can, for example, carry signatures, signature types, and key ID information. The descriptor can be carried as the first descriptor in the table (eg, PAT or PMT). The signature can be applied to the key_id field, for example via the end of the table (eg, PAT or PMT). The descriptor can be carried in the TS Packet Adaptation field. The descriptor can have its signature applied to the payload unit (eg, a PES packet), and the descriptor appears in the payload unit.

Table 1 shows an example interval signature descriptor syntax for MPEG-2 TS. Table 1 - Example Interval Signature Descriptor Syntax for MPEG-2 TS

The signature_level may be a value indicating which component or components (e.g., on a defined data interval) are signed. A value of 0 may indicate that all TS packets in the multiplex are signed. A value of 1 may indicate that all TS packets in the multiplex except for those having a PID value of 0x1 FFF or an empty packet are signed. A value of 2 may indicate that TS packets (e.g., all TS packets) on the current PID are signed. A value of 3 indicates that the concatenated TS packet payload is signed on the current PID. A value of 4 may indicate that a PES packet payload (e.g., a full base stream) that is serialized on the PID is signed, such as a PID for carrying a PES packet.

The signature can be an "interval" signature. The interval signature may, for example, cover a byte from the beginning of the byte following the previous descriptor up to the end of the current key_id field of the descriptor (eg, all bytes that match the current signature level). For example, as defined above, the descriptor can be an instance of interval_signature_extension_descriptor().

The overlap_signature may be an "interval" signature calculated over a data interval that includes some or all of the previous "flag" packets. The overlap signature can be applied to a data interval that includes the entire previous "flag" packet, or to a data interval that includes the previous flag packet and additional material from the previous and/or subsequent TS packets. For example, additional material can be selected to match the current signature level. Overlapping signatures can be applied, for example, from the key_id field to the end of the (PAT or PMT) table.

The segment_number_signature may be the segment number of the signature or the earliest presentation time of the signature. The segment_number_signature can be obtained from the MPD or EBP structure.

The timestamp can be the absolute time at which the signature (one or more) is generated.

A TS packet can be used, for example, to divide the boundary between two intervals. Such TS packets may be referred to as "flag packets." The flag packet may, for example, have or include a descriptor structure that carries the signature. The descriptor structure can be carried in the payload or in the adaptive field. The descriptor structure carried in the packet payload may, for example, use a fragment or a private grammar.

Table 2 shows an example payload signature descriptor syntax for MPEG-2 TS. Table 2 - for example MPEG-2 TS payload signature descriptor grammar

The Signature_level can be a value indicating which component or components (eg, which payload component) are signed. A value of 0 indicates that the full payload unit is signed. The full payload unit may include, for example, a serial payload from the TS packet of the current PID between the "payload start" packet and the "pay end" packet. A value of 1 may indicate that the PES packet payload is signed, for example, when the PID uses the PES syntax.

The "payload start" packet may be the most recent prior TS packet having the same PID value as the current packet. The value of payload_unit_start_indicator (payload unit start indicator) may be 1 in this packet. For example, when the signature is carried in the "end of payload" packet, the payload start packet may be the current packet or the previous packet.

The "payload end" packet may be the last TS packet having the same PID value as the current packet. The value of payload_unit_start_indicator can be 0 in this packet. The payload_unit_start_indicator value of the TS packet carried by the first payload after the payload end packet may be 1.

The payload signature may cover a byte (eg, all bytes) in the sequential payload of the TS packet between the "start" and "end" packets. The payload signature can cover a byte group that is only associated with the reward component specified by the current signature level. The payload signature can exclude the PES header to, for example, follow the signature level.

The Previous_payload_signature (previous payload signature) may be the signature of the previous payload_signature_extension_descriptor() with the same PID and rank. The Previous_payload_signature can carry the signature field from the previous descriptor.

The Descriptor_signature may be the signature of a byte (eg, all bytes) from the signature type to the beginning of the descriptor field in the descriptor.

The PMT descriptor can provide information about the signature type and key. The signature may be carried in an adaptive field (eg, only in an adaptive field) to, for example, save the byte and/or provide optimization.

Key exchange mechanisms can be eliminated using public key encryption. The effectiveness of public encryption can be improved with longer intervals and/or higher bit rate streams. The certificate can be carried, for example, in the MPEG-2 system portion, in a PES packet, or using a proprietary syntax. For example, when the interval includes multiple packets (the plurality of packets contain portions of the certificate), the certificate may cover a subset of the TS packets in the interval.

FIG. 7A is a diagram of an example communication system 100 in which one or more of the disclosed embodiments may be implemented. Communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. Communication system 100 can enable multiple wireless users to access such content via shared system resources, including wireless bandwidth. For example, communication system 100 can use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA). Single carrier FDMA (SC-FDMA) and the like.

As shown in FIG. 7A, communication system 100 can include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (generally or collectively referred to as WTRU 102), radio access network (RAN) 103/104/ 105/105, core network 106/107/109, public switched telephone network (PSTN) 108, internet 110 and other networks 112, but it will be understood that the disclosed embodiments may encompass any number of WTRUs, bases Taiwan, network and/or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile user units, pagers, mobile phones, individuals Digital assistants (PDAs), smart phones, portable computers, portable Internet devices, personal computers, wireless sensors, consumer electronics, and more.

Communication system 100 can also include a base station 114a and a base station 114b. The base stations 114a, 114b may be configured to wirelessly interact with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (eg, core network 106/107/109, Any type of device of the Internet 110 and/or the network 112). For example, base stations 114a, 114b may be base station transceiver stations (BTS), node B, eNodeB, home node B, home eNodeB, website controller, access point (AP), wireless router, and the like. . Although base stations 114a, 114b are each depicted as a single component, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN 103/104/105, which may also include other base stations such as a website controller (BSC), a radio network controller (RNC), a relay node, and the like. And/or network elements (not shown). Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as cells (not shown). Cells can also be divided into cell sectors. For example, a cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, such as one transceiver for each sector of the cell. In another embodiment, base station 114a may use multiple input multiple output (MIMO) technology, and thus multiple transceivers for each sector of the cell may be used.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via the null intermediate plane 115/116/117, which may be any suitable wireless communication link. Road (for example, radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The null intermediaries 115/116/117 can be established using any suitable radio access technology (RAT).

More specifically, as previously discussed, communication system 100 can be a multiple access system and can utilize one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a and WTRUs 102a, 102b, 102c in RAN 103/104/105 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA ( WCDMA) to establish an empty intermediate plane 115/116/117. WCDMA may include, for example, High Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In another embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or Advanced LTE (LTE-A) to establish an empty intermediate plane 115/116/117.

In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement, for example, IEEE 802.16 (eg, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Temporary Standard 2000 (IS- 2000), Temporary Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN).

For example, the base station 114b in FIG. 7A may be, for example, a wireless router, a home Node B, a home eNodeB, or an access point, and any suitable RAT may be used for facilitating, for example, a business location, a residence, Wireless connection to local areas such as transportation and campus. In one embodiment, base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d may use a cellular based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocell cells and femtocells. (femtocell). As shown in FIG. 7A, the base station 114b can have a direct connection to the Internet 110. Thus, base station 114b may not have to access Internet 110 via core network 106/107/109.

The RAN 103/104/105 can communicate with a core network 106/107/109, which can be configured to voice, data, application, and/or Voice over Internet Protocol (VoIP). The service provides any type of network to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 can provide call control, billing services, mobile location based services, prepaid calling, internet connectivity, video distribution, etc. and/or perform high level security functions such as user authentication. Although not shown in FIG. 7A, it is to be understood that the RAN 103/104/105 and/or the core network 106/107/109 may communicate directly or indirectly with other RANs, which may be used with the RAN 103/ 104/105 the same RAT or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may employ E-UTRA radio technology, the core network 106/107/109 may also be in communication with other RANs (not shown) that use GSM radio technology.

The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include a circuit switched telephone network that provides Plain Old Telephone Service (POTS). Internet 110 may include a global system interconnecting computer networks and devices that use public communication protocols, such as TCP in a public communication protocol such as the Transmission Control Protocol (TCP)/Internet Protocol (IP) Internet Protocol Suite. , User Datagram Protocol (UDP) and IP. Network 112 may include a wireless or wired communication network that is owned and/or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may use the same RAT as RAN 103/104/105 or a different RAT.

One or more of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, ie, the WTRUs 102a, 102b, 102c, 102d may include different wireless networks for use via different wireless links Multiple transceivers for communication. For example, the WTRU 102c shown in FIG. 7A can be configured to communicate with a base station 114a that uses a cellular-based radio technology and with a base station 114b that uses an IEEE 802 radio technology.

FIG. 7B is a system diagram of an example WTRU 102. As shown in FIG. 7B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keyboard 126, a display/touchpad 128, a non-removable memory 130, and a removable Memory 132, power source 134, global positioning system (GPS) chipset 136, and other peripheral devices 138. It is to be understood that the WTRU 102 may include any sub-combination of the above-described elements while consistent with the above embodiments. Likewise, embodiments encompass that the nodes that base stations 114a and 114b and/or base stations 114a and 114b can represent may include one or more of the elements described in FIG. 7B, such as but not limited to a base transceiver station (BTS) , Node B, Website Controller, Access Point (AP), Home Node B, Evolved Node B (eNode B), Home Evolved Node B (HeNB), Home Evolved Node B Gateway and Proxy Node, etc. .

The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with the DSP core, a controller, a micro control , dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), state machine, etc. The processor 118 can perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to the transmit/receive element 122. Although processor 118 and transceiver 120 are depicted as separate components in FIG. 7B, it will be appreciated that processor 118 and transceiver 120 can be integrated together into an electronic package or wafer.

The transmit/receive element 122 can be configured to transmit signals to or from a base station (e.g., base station 114a) via the null planes 115/116/117. For example, in one embodiment, the transmit/receive element 122 can be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be a transmitter/detector configured to transmit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 can be configured to transmit and receive both RF signals and optical signals. It is to be understood that the transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals.

Moreover, although the transmit/receive element 122 is depicted as a single element in FIG. 7B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the null intermediaries 115/116/117.

The transceiver 120 can be configured to modulate a signal to be transmitted by the transmit/receive element 122 and configured to demodulate a signal received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keyboard 126, and/or a display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and User input data can be received from the above device. The processor 118 can also output user profiles to the speaker/microphone 124, the keyboard 126, and/or the display/trackpad 128. In addition, processor 118 can access information from any type of suitable memory and store the data to any type of suitable memory, such as non-removable memory 130 and/or removable memory 132. The non-removable memory 130 can include random access memory (RAM), readable memory (ROM), hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, for example, the memory may be located on a server or a home computer ( Not shown).

The processor 118 may receive power from the power source 134 and may be configured to allocate power to other elements in the WTRU 102 and/or to control power to other elements in the WTRU 102. Power source 134 may be any suitable device for powering up WTRU 102. For example, the power source 134 may include one or more dry cells (nickel cadmium (NiCd), nickel zinc (NiZn), nickel hydrogen (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to a GPS chipset 136 that may be configured to provide location information (eg, longitude and latitude) regarding the current location of the WTRU 102. Additionally or alternatively to the information from GPS chipset 136, WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via null intermediaries 115/116/117, and/or based on two or more The timing of the signals received by neighboring base stations to determine their position. It is to be understood that the WTRU 102 can obtain location information using any suitable location determination method while consistent with the embodiments.

The processor 118 can also be coupled to other peripheral devices 138, which can include one or more software and/or hardware modules that provide additional features, functionality, and/or wireless or wired connections. For example, peripheral device 138 may include an accelerometer, an electronic compass (e-compass), a satellite transceiver, a digital camera (for photo or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, and a hands-free Headphones, Bluetooth R modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, and more.

Figure 7C is a system diagram of RAN 103 and core network 106, in accordance with an embodiment. As described above, the RAN 103 can use UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c via the null plane 115. The RAN 103 can also communicate with the core network 106. As shown in FIG. 7C, the RAN 103 may include Node Bs 140a, 140b, 140c, wherein each of the Node Bs 140a, 140b, 140c may include one or more transceivers via an empty interfacing plane 115 to communicate with the WTRUs 102a, 102b, 102c. Each of the Node Bs 140a, 140b, 140c may be associated with a particular unit (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It should be understood that the RAN 103 may include any number of Node Bs and RNCs while remaining consistent with the embodiments.

As shown in Figure 7C, Node Bs 140a, 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, 140c can communicate with respective RNCs 142a, 142b via the Iub interface. The RNCs 142a, 142b can communicate with each other via the Iur interface. Each of the RNCs 142a, 142b can be configured to control a respective Node B 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b can be configured to implement or support other functions, such as outer loop power control, payload control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc. Wait.

The core network 106 shown in FIG. 7C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. . While each of the above elements is described as being part of the core network 106, it should be understood that any of these elements may be owned and/or operated by entities other than the core network operator.

The RNC 142a in the RAN 103 can be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 can be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to a circuit switched network (e.g., PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and the landline communication device.

The RNC 142a in the RAN 103 can also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to a packet switched network (e.g., the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and the IP enabled devices.

As noted above, the core network 106 can also be connected to other networks 112, where other networks 112 can include other wired or wireless networks that are owned and/or operated by other service providers.

Figure 7D is a system diagram of RAN 104 and core network 107 in accordance with another embodiment. As described above, the RAN 104 can communicate with the WTRUs 102a, 102b, 102c via the null plane 116 using E-UTRA radio technology. The RAN 104 can also communicate with the core network 107.

The RAN 104 may include eNodeBs 160a, 160b, and/or 160c, although it should be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each of the eNodeBs 160a, 160b, 160c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c via the null plane 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a.

Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to process radio resource management decisions, handover decisions, users in the uplink and/or downlink schedule. As shown in FIG. 7D, the eNodeBs 160a, 160b, 160c can communicate with each other via the X2 interface.

The core network 107 shown in FIG. 7D may include a mobility management gateway (MME) 162, a service gateway 164, and a packet data network (PDN) gateway 166. While each of the above elements is described as being part of core network 107, it should be understood that any of these elements may be owned and/or operated by entities other than the core network operator.

The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating the users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular service gateway during initial connection of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide control plane functionality to perform handover between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM or WCDMA.

Service gateway 164 may be connected to each of eNodeBs 160a, 160b, 160c in RAN 104 via an S1 interface. The service gateway 164 can typically route and forward user data packets to the WTRUs 102a, 102b, 102c, or route and forward user data packets from the WTRUs 102a, 102b, 102c. The service gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when the downlink information is available to the WTRUs 102a, 102b, 102c, managing and storing for the WTRUs 102a, 102b, 102c Context and more.

The service gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to a packet switched network (e.g., the Internet 110) to facilitate the WTRUs 102a, 102b, 102c and IP. Can communicate between devices.

The core network 107 can facilitate communication with other networks. For example, core network 107 may provide WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, core network 107 may include or be in communication with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), where the IP gateway acts as an interface between core network 107 and PSTN 108. In addition, core network 107 can provide WTRUs 102a, 102b, 102c with access to network 112, which can include other wired or wireless networks that are owned and/or operated by other service providers.

Figure 7E is a system diagram of RAN 105 and core network 109, in accordance with an embodiment. The RAN 105 may be an Access Service Network (ASN) that communicates with the WTRUs 102a, 102b, 102c via the null plane 117 using IEEE 802.16 radio technology. As will be discussed further below, the communication lines between the different functional entities of the WTRUs 102a, 102b, 102c, RAN 105, and core network 109 may be defined as reference points.

As shown in FIG. 7E, the RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182, although it should be understood that the RAN 105 may include any number of base stations and ASNs while remaining consistent with the embodiments. Gateway. Each of the base stations 180a, 180b, 180c may be associated with a particular cell (not shown) in the RAN 105 and may include one or more transceivers to communicate with the WTRUs 102a, 102b via the null intermediaries 117, 102c communication. In one embodiment, base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, base station 180a can use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a. Base stations 180a, 180b, 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 can act as a traffic aggregation point and can be responsible for paging, caching, routing to the core network 109, etc. of the user profile.

The null interfacing plane 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c can establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 can be defined as an R2 reference point that can be used for authentication, authorization, IP host configuration management, and/or mobility management.

The communication link between each of the base stations 180a, 180b, 180c may be defined to include an agreed R8 reference point for facilitating data transfer between the WTRU and the base station. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include an agreement for facilitating mobility management based on mobile events associated with each of the WTRUs 102a, 102b, 102c.

As shown in FIG. 7E, the RAN 105 can be connected to the core network 109. The communication link between the RAN 105 and the core network 109 can be defined, for example, as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, a Authentication, Authorization, Accounting (AAA) service 186, and a gateway 188. While each of the above elements is described as being part of core network 109, it should be understood that any of these elements may be owned and/or operated by entities other than the core network operator.

The MIP-HA 184 may be responsible for IP address management and may cause the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to a packet switched network (e.g., the Internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 can be responsible for user authentication and support for user services. Gateway 188 can facilitate interaction with other networks. For example, gateway 188 can provide WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices. In addition, gateway 188 can provide access to network 112 to WTRUs 102a, 102b, 102c, which can include other wired or wireless networks that are owned and/or operated by other service providers.

Although not shown in FIG. 7E, it should be understood that the RAN 105 can be connected to other ASNs and the core network 109 can be connected to other core networks. The communication link between the RAN 105 and other ASNs may be defined as an R4 reference point, which may include a protocol for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and other ASNs. The communication link between core network 109 and other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between the local core network and the visited core network.

Systems, methods, and facilities for content protection and modification detection in adaptive streaming and transport streams are disclosed. Content protection can be multi-level, such as payload signatures and interval signatures. Content protection can be multi-layered, such as overlapping signatures. For example, the signature can be carried in-band in the transmission segment. Content protection can be used to modify the detection. Modification detection can be multi-layered, such as container level detection and bit stream level detection. The types of resources and modifications can be detected and distinguished, such as detection of reordering, by content insertion and/or removal of benignity and/or removal of one or more types of content (eg, bitstreams, relayed material) and/or Detection of malignant modifications.

Although the features and elements are described above in a particular combination, those of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Moreover, the techniques described herein can be implemented in a computer program, software or firmware executed by a computer or processor, where the computer program, software or firmware is embodied in a computer readable storage medium. Examples of computer readable media include electrical signals (transmitted via wired or wireless connections) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read only memory (ROM), random access memory (RAM), scratchpad, cache memory, semiconductor storage devices, magnetic media (eg, internal hard and extraction) Disks, magneto-optical media, and optical media such as CD-ROMs and digital versatile discs (DVDs). The software related processor can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

100‧‧‧Communication system
102, 102a, 102b, 102c, 102d, WTRU ‧ ‧ wireless transmission / receiving unit
103, 104, 105, RAN‧‧‧ radio access network
106, 107, 109‧‧‧ core network
108. PSTN‧‧‧Public Switched Telephone Network
110‧‧‧Internet
112‧‧‧Other networks
114a, 114b‧‧‧ base station
115, 116, 117‧‧ ‧ empty mediation
118‧‧‧Processor
120‧‧‧ transceiver
122‧‧‧Transmission/receiving components
124‧‧‧Speaker/Microphone
126‧‧‧ keyboard
128‧‧‧Display/Touchpad
130‧‧‧Non-movable memory
132‧‧‧Removable memory
134‧‧‧Power supply
136‧‧‧GPS (Global Positioning System) chipset
138‧‧‧ peripheral devices
140a, 140b, 140c‧‧‧ Node B
142a, 142b, RNC‧‧‧ Radio Network Controller
144. MGW‧‧‧Media Gateway
146. MSC‧‧‧ Action Exchange Center
148, SGSN‧‧‧ service GPRS support node
150, GGSN‧‧‧ gateway GPRS support node
160a, 160b, 160c‧‧‧e Node B
162, MME‧‧‧ mobility management gateway
164‧‧‧ service gateway
166, PDN‧‧‧ Packet Information Network
180a, 180b, 180c‧‧‧ base station
182‧‧‧ASN gateway
184. MIP-HA‧‧‧Action IP Local Agent
186‧‧‧Verification, Authorization, and Accounting (AAA) Services
188‧‧ ‧ gateway
MPD‧‧‧Media Presentation
TS‧‧‧Transport Stream

Figure 1 is an example diagram of the DASH system model. Figure 2 is an illustration of a payload signature in a Transport Stream (TS) packet. Figure 3 is an exemplary diagram of a marker frame for interval signatures. Figure 4 is an exemplary diagram of an interval signature for a continuous TS packet. Figure 5 is an exemplary diagram of a hierarchical interval signature for a continuous TS packet. Figure 6 is an exemplary diagram of a hierarchical interval signature for a segmented TS packet. Figure 7A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented; Figure 7B is an example WTRU that may be used in a communication system as shown in Figure 7A (WTRU) System diagram. Figure 7C is a system diagram of an example radio access network and an example core network that can be used in a communication system as shown in Figure 7A. Figure 7D is a system diagram of another example radio access network and an example core network that can be used in a communication system as shown in Figure 7A. Figure 7E is a system diagram of another example radio access network and an example core network that can be used in a communication system as shown in Figure 7A.

Claims (15)

A method for confirming a reliability of a content in an adaptive stream, comprising: receiving a media presentation description (MPD) file; receiving a key; requesting a content based on the MPD; receiving comprising a plurality of packets and a band The content of the signature; determining the reliability of the content using the in-band signature and the key; and decoding at least one of the contents when the reliability of the content is confirmed. The method of claim 1, wherein the at least one packet comprises the in-band signature. The method of claim 2, wherein the adaptive field of the packet includes the in-band signature. The method of claim 1, further comprising determining the reliability of the in-band signature and an additional in-band signature using the key, wherein the content includes the additional in-band signature. The method of claim 4, further comprising decoding the plurality of packets of the in-band signature and the reliability of the additional in-band signature. The method of claim 5, wherein the plurality of packets of the content are between the in-band signature and the additional in-band signature. The method of claim 6, wherein the in-band signature and the additional in-band signature are carried in a separate MPEG-2 transport stream packet. The method of claim 6, wherein the in-band signature and the additional in-band signature are carried in an encoder boundary point packet to provide a virtual segmentation structure. The method of claim 8, wherein the encoder boundary point packet provides at least one virtual boundary point for segmentation. The method of claim 4, further comprising determining the addition or removal of the component of the content when the reliability of the in-band signature and the additional in-band signature is not confirmed. The method of claim 1, wherein the in-band signature is a symmetric keyed hash message authentication code (HMAC) or an advanced encryption standard, a Galleria message authentication code (AES-GMAC). The method of claim 1, wherein the key is received from the content out of band. The method of claim 1, wherein the key is an entity specific key. The method of claim 1, further comprising receiving an additional key and determining the reliability of an additional in-band signature using the additional key, wherein the content includes the additional in-band signature. An apparatus for performing the method of claim 1 or 4 of the patent application.