WO2012118591A1 - Method and apparatus for deconstructing and reconstructing messages with similar content - Google Patents

Abstract

A method and apparatus for group transmission of similar content messages are described, where common message fields are consolidated and broadcast. Furthermore, individual message fields are unicast to their intended recipients. The method and apparatus are appropriate for an application in any layer including a medium access control (MAC) layer and a transport layer. The method and apparatus may perform blind-detection of grouping information, estimation of grouping gain or extraction procedures.

Description

METHOD AND APPARATUS FOR DECONSTRUCTING AND RECONSTRUCTING MESSAGES WITH SIMILAR CONTENT

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application

No. 61/447,262 filed February 28, 2011, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Machine-to-machine (M2M) communication networks are now being developed to address a wide range of applications including, for example, smart grid, health monitoring, facilities security and others. These applications may require a large number of devices in any given deployment area, at a density that may exceed current cellular densities while using messages that sometimes contain small amounts of data. Therefore, these applications may generate large overhead and cause significant battery drain. On the other hand these messages may often tolerate higher latency than is common in most cellular systems.

[0003] Broadcast or multicast of common control messages may drastically reduce signaling overhead and, therefore, help reduce bandwidth and preserve battery. Many communication protocols and air interfaces already recognize the need to broadcast, (i.e., rather than unicast), common and repetitive access control information and may include a broadcast channel for this purpose. Group control of communication devices has been incorporated in a diverse range of radio access technologies (RATs). This is usually standardized into the protocol.

[0004] At this time, the majority of the mobile networks where video traffic is flowing are third generation (3G), (i.e., wideband code division multiple access

(WCDMA), high speed packet access (HSPA) or evolution- data optimized

(EVDO)), based. It is expected that most major operators will be evolving their networks to fourth generation (4G) technologies, such as long term evolution

(LTE) and IEEE 802.16 worldwide interoperability for microwave access (Wi-

Max). An improved air interface alone, (such as LTE-advanced), may not be enough to solve the increasingly consumer demand for video content. Obtaining access to additional spectrum will again be only a temporary solution to this problem. This new spectrum capacity may not be available in a timely fashion, and it may be expensive to acquire. Another traditional solution is cell splitting that, due to environmental concerns, may not be possible, especially in the highly populated areas that experience the problem the most.

[0005] It would therefore be desirable to be able to reduce signaling overhead for other data including user payload.

SUMMARY

[0006] A method and apparatus for group transmission of similar content messages are described, where common message fields are consolidated and broadcast. Furthermore, individual message fields are unicast to their intended recipients. The method and apparatus are appropriate for an application in several layers including the medium access control (MAC) layer and the transport layer. The method and apparatus may perform blind- detection of grouping information, estimation of grouping gain and extraction procedures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0008] Figure 1A shows an example communications system in which one or more described embodiments may be implemented;

[0009] Figure IB shows an example wireless transmit/receive unit (WTRU) that may be used within the communications system shown in Figure 1A;

[0010] Figure 2A shows an example of messages on which a deconstruction and reconstruction procedure may be performed.

[0011] Figures 2B and 2C show examples of a message deconstruction and reconstruction procedure that may be performed on the messages of Figure 2A.

[0012] Figure 3 shows an example of an implementation above transmission control protocol (TCP); [0013] Figure 4 shows an example of a network including an application server sending control messages, and an M2M gateway processing the control messages and performing message consolidation;

[0014] Figure 5 shows an example of a network including a utility company, an M2M gateway and smart meters;

[0015] Figure 6 shows a multimedia broadcast and multicast services

(MBMS) reference architecture;

[0016] Figure 7 shows a procedure for forming an MBMS broadcast group;

[0017] Figure 8 shows an MBMS group session flow; and

[0018] Figure 9 shows a procedure for forming an MBMS multicast group.

DETAILED DESCRIPTION

[0019] Figure 1A shows an example communications system 100 in which one or more described embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, multicast and the like, to multiple wireless users. The terminology "broadcast" and "multicast" may be used interchangeably. The communications system 100 may enable multiple wired or wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ 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.

[0020] As shown in Figure 1A, the communications system 100 may include wired or wireless subscriber communication units 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the described embodiments contemplate any number of subscriber communication units, base stations, networks, and/or network elements. Each of the subscriber communication units 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wired or wireless environment. By way of example, the subscriber communication units 102a, 102b, 102c, 102d may be configured to transmit and/or receive wired or wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a notebook, a personal computer, a tablet computer, a wireless sensor, consumer electronics, and the like.

[0021] The communications system 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to interface with at least one of the subscriber communication units 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an evolved Node-B (eNB), a Home Node-B (HNB), a Home eNB (HeNB), a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0022] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple -output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell. [0023] The base station 114b in Figure 1A may be a wireless router, HNB,

HeNB, or AP, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the subscriber communication units 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the subscriber communication units 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the subscriber communication units 102c, 102d may utilize a cellular-based RAT, (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, and the like), to establish a picocell or femtocell. As shown in Figure 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0024] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over Internet protocol (VoIP) services to one or more of the subscriber communication units 102a, 102b, 102c, 102d. For example, the CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, and the like, and/or perform high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be appreciated that the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0025] The CN 106 may also serve as a gateway for the subscriber communication units 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the Internet protocol (IP) in the TCP/IP suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0026] Some or all of the subscriber communication units 102a, 102b, 102c,

102d in the communications system 100 may include multi-mode capabilities, i.e., the subscriber communication units 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wired or wireless networks over different wired or wireless links. For example, the subscriber communication unit 102c shown in Figure 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology. Alternatively, one or more of the subscriber communication units 102 may be a laptop having a wired Ethernet connection plus a broadband wireless connection to provide multiple sub-flows,

[0027] Figure IB shows an example subscriber communication unit 102 that may be used within the communications system 100 shown in Figure 1A. As shown in Figure IB, the subscriber communication unit 102 may include a processor 118, a transceiver 120, a wired or wireless interface 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and peripherals 138. It will be appreciated that the subscriber communication unit 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0028] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a microprocessor, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, an integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the subscriber communication unit 102 to operate in a wired or wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the interface 122. While Figure IB depicts the processor 118 and the transceiver 120 as separate components, the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0029] The interface 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over an air interface 116. For example, in one embodiment, the interface 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the interface 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the interface 122 may be configured to transmit and receive both RF and light signals. The interface 122 may be configured to transmit and/or receive any combination of wired or wireless signals.

[0030] The processor 118 of the subscriber communication unit 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The nonremovable memory 130 may include random-access memory (RAM), read-only memory (ROM), a 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 subscriber communication unit 102, such as on a server or a home computer (not shown).

[0031] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0032] Some messages used in M2M applications may have a limited vocabulary. Each message may include vocabulary words and parameters. In addition, in M2M applications, machines that are controlled by the same application may be in the same geographical area and serviced by one or more Node-Bs in that area.

[0033] For example, in a smart grid application used to control a set of thermostats in a neighborhood, a load control server may send a "limited vocabulary" message to the thermostats to set their temperature. The "set temperature" word is common to all of the thermostats, whereas "specific temperature" and "time to activate" parameters that are included in the message may be different for each thermostat.

[0034] In an example of a non-M2M application, several users in the same geographical area may request the same video but with either the same or different supportable data rates. If the granularity for all streams is the same, then all of the messages may be common. If the mesage are not common, the video may be sent in several layers, with each layer providing progressively more details. The layers may be sent in the same message or in separate messages. The lowest layer, (coarsest granularity), may be considered as the common part. Another example of a non-M2M application is web browsing with some common elements, such as advertisements. [0035] The above examples lead to a definition of a message group and a session group. A message group is defined as a collection of messages that have a common element or elements, and its subscribers are in the same geographical area. A session group is defined as a collection of sessions that are each composed of a stream of messages, and there exists a time shift between the sessions such that messages that belong to different sessions contain common elements. The messages or sessions may be derived from a single source or from multiple sources.

[0036] The messages may contain one or more common fields and one or more individual fields. Savings in overhead may result by using a "broadcast- only" transmission procedure to consolidate all common fields and transmit them only once while the individual field are broadcast individually. Thus, for example, a broadcast channel that is accessible to all relevant subscribers, (e.g., in a certain geographical area), may be used to broadcast both the consolidated common fields and the individual fields. Further gain may be achieved by using a "broadcast-unicast" transmission procedure to broadcast only the common fields, and unicast the individual fields. These further gains may be the result of the inherent inefficiencies in a broadcast channel.

[0037] The embodiments described herein may be used in both wired and wireless communication networks. In wireless communication networks, a broadcast may refer to an over-the-air (OTA) broadcast from one or more Node- Bs or access points (APs). In wired networks, a broadcast may refer to an Internet protocol (IP) broadcast.

[0038] Similar messages from multiple sources may be consolidated before transmitting them to their destination. Consolidating the common fields may be performed in an application-agnostic manner through the implementation of a consolidation procedure, whereby it is assumed that the message format is not known. The consolidation procedure has several roles that depend on the transmission procedure that is used. For both the broadcast-only and broadcast- unicast transmission procedures, the consolidation procedure identifies the amount of commonality between any two messages or between a message and a group of already consolidated messages, if that information is not known apriori. For the broadcast-only transmission procedure, the common fields of similar messages may be consolidated with or without specifically extracting them. For the broadcast-unicast transmission procedure, the common fields of similar messages may be consolidated and extracted. While presented herein as distinct roles of the procedure, it should be understood that the procedure may perform all roles at the same time. It is important to understand that the extraction procedure does not need to be absolutely accurate, in the sense that it is not important that all common fields and individual fields always be recognized as such. Inaccuracies in the extraction procedure may reduce the gain from the procedure, but may not render the messages illegible.

[0039] For the broadcast-only transmission procedure, the consolidation procedure may utilize any of already known compression algorithms, such as a Lempel Ziv (LZ) algorithm, or an extraction procedure. For the broadcast-unicast transmission procedure, an extraction procedure may be used.

[0040] There are several layers in which an extraction procedure may take place. The extraction may be performed in an application layer, where the expertise on the requirements of the application exists. Therefore, it may be necessary to bring network parameters to the application layer on a regular basis. The extraction procedure may also be performed in the transmission control protocol (TCP)/IP layer, or in a medium access control (MAC) layer where the network expertise exists. Therefore, it may be necessary to make the TCP/IP layer or MAC layer aware of some application constraints, (i.e., by providing side information).

[0041] The following elements described herein are common to all layers where it may be implemented. While the procedure may be performed in any layer, (e.g., application down to the MAC layer), analysis described herein that computes transmission overhead shows that overhead may be minimized if performed at lower layers. Further, analysis of the efficiency of the consolidation itself is described herein. [0042] Depending on the messages and the number of recipients, the consolidation process may result in the waste, rather than the saving, of resources. Resource waste may result from compression inefficiencies or, in the case of wireless broadcast, from the inherent waste of a broadcast channel, if used. A test may be used to determine whether group consolidation may result in sufficient savings or whether an attempt to perform a group consolidation procedure should be aborted.

[0043] Messages meant for subscribers in the same geographical area may be buffered up to their allowed latency. If the messages are encrypted, then all messages may be encrypted with same key that is known to the splitting entity, or all keys may be different but known to the splitting entity and there is a multicast key also known to the splitting entity. Alternatively, if the messages are encrypted, at least all common fields in like messages may be encrypted using the same key. If there are several common fields in each message, and if their order is not the same, then either each field may be encrypted separately or the key may be known to the splitting entity. That key may be known to all recipients. Individual fields may be separately encoded from the common fields and may or may not be encrypted using a common key, (including the key used for the common part). Message attributes, if used, may not be encrypted. Message groups may or may not be known. After the splitting and consolidation, a common key such as a multicast key may be use to re-encrypt the common parts while the original individual fields may be re-encrypted with the original individual keys, if used.

[0044] Grouping information is any information inside or outside of the message that can inform the splitting entity which messages are similar or their amount of similarity. If grouping information is not available, the similarities may be blindly detected using an appropriate clustering algorithm. For example, a clustering algorithm may attempt to start a group with a first message. Subsequent messages may be tested for similarity using the consolidation procedure. If the similarity is high enough, each subsequent message may be considered to belong to the first group. A group similarity score is calculated at this point. Otherwise, a new group may be formed, (and its messages are completely removed from all other groups). This algorithm may be repeated until all messages have been processed. Depending on the procedure in use, common and individual fields of the messages may already be separated after this stage, and the next step may be skipped. For each group, the estimated group similarity may be used to decide whether to abort the rest of the procedure for the group.

[0045] If message groups are known, either from the previous step or from side information, then if an estimate of the group similarity exists, (e.g., from side information), it may be used to estimate the gain of the procedure. Otherwise an estimate of the group similarity is obtained using the consolidation procedure. The procedure is aborted if not justified by the gain. Depending on the transmission procedure used, the common fields may or may not be extracted.

[0046] If the broadcast-only transmission procedure is used, all messages may be sent in a joint message in a broadcast channel. To do so, the common and the individual field or fields may be inserted with an appropriate descriptor of their locations. If a compression algorithm is used, then that information may be built into the algorithm. If a broadcast-unicast transmission procedure is used, the individual fields may be sent separately in unicast messaging. Field location descriptors are also needed here. The original message may be reconstructed using common and individual fields with the help of the field location descriptors.

[0047] To facilitate a classification and consolidation operation, a cross layer attributes element that is independent of any protocol may be associated with messages to provide side information. The content of such a cross layer attributes element may vary at different layers and may be decoded by different layers. While this side information may be useful, the operation may be performed without it, although with the risk of possibly reducing efficiency and increasing computational complexity.

[0048] The cross layer attributes element may include a message type

(useful for grouping), an initiator identification (ID), (i.e., the ID of an application or a protocol which initiates the message, delay tolerance and/or loss tolerance parameters, and input from lower layers, (e.g., recipient cell association, a unicast/multicast request and/or network performance estimates for message loss probability, throughput, and the like).

[0049] The above information may not necessarily need to be specifically signaled, but may instead be derived from other information or implied by it.

[0050] Although described in terms of application layer messaging herein, there is no reason not to apply the messaging to MAC (upper MAC) or radio resource control (RRC) control signaling if the splitting is implemented at lower layers. In some cases, (e.g., for video streams), messages may belong to sessions with similar properties, and therefore may be applied to the sessions as described herein.

[0051] Figure 2 A shows an example of messages 205A and 205B on which a deconstruction (i.e., splitting) and reconstruction (i.e., consolidation) procedure may be performed. Each of the messages 205A and 205B may include attributes (i.e., side information) 210, common fields 215 and individual fields 220. The ordering of the common and individual fields may be arbitrary and the fields may or may not be contiguous, although such details may affect the efficiency of compression.

[0052] Figure 2B shows an example of a message deconstruction and reconstruction procedure 250 that may be performed on the messages 205A and 205B of Figure 2A. The original messages 205A and 205B may be deconstructed by extracting the common fields 215 and the individual fields 220 from the original messages 205A and 205B, and consolidating the common fields 215 (252). The consolidated common fields 215 and the individual fields 220 may be broadcast (254). Once the broadcast common fields 215 and individual fields 220 are received (266), the original messages 205A and 205B may be reconstructed (258).

[0053] Figure 2C shows another example of a message deconstruction and reconstruction procedure 280 that may be performed on the messages 205A and 205B of Figure 2A. The original messages 205A and 205B may be deconstructed by extracting the common fields 215 and the individual fields 220 from the original messages 205A and 205B, and consolidating the common fields 215 (282). The consolidated common fields 215 may be multicast (284) and the individual fields 220 may be unicast (286). Once the multicast common fields 215 and unicast individual fields 220 are received (288), the original messages 205A and 205B are reconstructed (290).

[0054] As an example, the following extraction procedure may be performed on two messages A and B, each containing at least one common field c and individual fields i. The fields may appear in any order and any size. The total message sizes are NA and N , respectively, and the combined length of the common fields is C.

[0055] The extraction procedure may begin with an empty output message

M and individual descriptor fields DA, DB. A pattern window of length p may be defined. If the smallest possible common field of interest is known, it may be used to determine the length p. Shifted versions SA of message A may be correlated with shifted versions SB of message B using the pattern window. If a matching is found, the length of the pattern window may be increased e.g. from p to p+1 and the larger window at this shift may be re-correlated to see if full matching still exists. This process is repeated until matching is lost, at which point the previously found window is used as final. A common field having a length p -1 may be retained to be used later. The common field just found may be added to M, and SA and SB may be placed in DA and DB, respectively. The common fields may then be removed from the original messages A and B. This procedure may be repeated until no matches can be found. The message is the common (joint) message. The data remaining in the original messages is composed of individual fields.

[0056] There are many possible similarity gauges between messages. An example of a similarity gauge S may be defined as:

c ^C

ΛΙ(^ΝΛΝ_Β ) . Equation (1)

[0057] An example procedure useful for successive processing of input messages is described herein, where the procedure is useful for adding an input message to a group of already consolidated and possibly similar messages. An output message M having a length Nwmay be seeded using the procedure for two input messages. When a new message Ai of length Ni is added, it may be only necessary to correlate parts of M with the new message. The correlation length is known from previous stages, (i.e., the lengths of the common fields in M).

[0058] Any common field found in the new message may be added as previously described. The individual fields may be retained in and the descriptors may be stored in D In this case, the per-message similarity gauge and an aggregate similarity gauge may be defined. Due to the potentially big difference in length between the input and combined messages, an example of a per-message gauge Si may be computed as:

c

^ '^) . Equation (2)

[0059] This per-message gauge Si may be used to determine whether to add the message to a group of messages. To define the aggregate similarity index, the total length of all residual fields and descriptors may be computed as:

I = Xlength(4.)+ length(D_i)

' , Equation (3) then the aggregate similarity gauge may be defined as:

^{M + L} . Equation (4)

[0060] Implementation of this procedure in a medium access control (MAC) layer is also described herein. Side information (e.g., cross layer information) may be provided to the MAC, which may include a destination field, a source field. The side information may include information of allowed latency and a time stamp, (or, alternatively, must-deliver-by time). The side information may be implicitly derived from the streams (flows) with different known or negotiated quality of service (QoS) characteristics in which the messages arrive. The side information may include a descriptor which may be used to find other similar messages, (i.e., that are generated for other users). This may be implemented by associating like type messages with like connection identifiers (IDs), flows, radio bearers, and the like. Connections may be established at initial network entry. QoS control framework with the mechanism to map different traffic flow to different QoS bearers, (e.g., connections, logical channels or flows), may be used.

[0061] An extension to a set of bearer types or an existing QoS class is described. The extension may be a simple addition of new bearer types or a QoS class, or it may also be in the form of a sub-bearer type or a sub-QoS class, such that similar messages or message types may be mapped to the same sub-bearer type within a given QoS bearer. The logical channels at the MAC may also be extended following the same rational with the addition of extra logical channel space or creation of sub-logical channels. There may be a one-to-one mapping between a logical channel and a bearer, or between a sub-logical channel and a sub-bearer. This alternative has the advantage of integrating the message grouping scheme into the system user plane make-up from an end-to-end perspective. Similar message grouping and compression may then be implemented into any network node (i.e., network element) which already support QoS mapping. It may also be implemented in any sub-layer with visibility into bearer discrimination in a user plane (e.g., a MAC, a packet data convergence protocol (PDCP), a radio link control (RLC), and the like). A packet filter may be updated to include a message type.

[0062] If relays or WTRU helpers are used, the relays or WTRU helpers may extract their own message and the target WTRU messages, relay the target WTRU messages, or extract their message but relay a joint compressed version as-is.

[0063] Implementation at an IP layer is also described herein. Message splitting and recombining are employed at the IP layer of an application server or an intermediate network node, and a target WTRU. Cross-layer information, as described herein, may be sent to the IP layer to help perform a message deconstruction and reconstruction procedure. Additionally, control information may be appended to the IP frame to allow frame reconstruction for the end-user.

[0064] In order to perform a deconstruction and reconstruction procedure in the IP layer such that the message is detected by intermediate nodes, including WTRU helpers and target WTRUs, it may be presumed that the message is handled at the intermediate node and the target WTRU, (i.e., the destination address of the IP frame may either be an end-user's unique IP address or an IP address of a multicast group that the end-user is subscribed to. For example, if a hypertext transfer protocol (HTTP) request for multiple users is consolidated into a joint message with a portion that is multicast and a portion that is unicast, the intermediate nodes performing the message deconstruction or the target end-user's IP stacks may be part of the multicast group in order to be able to receive the multiple messages, (e.g., using an IP multicast group with the intermediate node and the end user's part of the common multicast group). The IP multicast group may be triggered after the initial discovery of the possible helper WTRUs, whereby a multicast IP group of all of the helper WTRUs is formed and the joint messages are broadcast on this multicast IP group.

[0065] When message combining is used with helper WTRUs, all of the helper WTRUs may decode every multicast frame, even if the data is not destined for them. Implementation at transport layer, (e.g., TCP/user datagram protocol (UDP)), is described herein. Application layer information is provided having content similar to MAC implementation. A wireless network may provide locality information in terms of Node-B/sector and any relaying entities if used, and/or a network latency estimate or guarantee. For example, round trip time (RTT) is a common measurement at a TCP layer that may be used for this purpose. The common message may receive the appropriate flow identification for the group.

[0066] Implementation above transport layer is also described herein.

Implementation in this layer may require similar information exchange as an implementation at a transport layer.

[0067] Figure 3 shows an implementation above transmission control protocol (TCP). If implementation is performed above the TCP, data may flow to a plurality of devices 305i, 3052, 305N by using a common field and a set of individual fields. For example, in LTE, this may be implemented in at least one of a radio access network (RAN) 310 and a core network (CN) 315 by assigning different bearers with different QoS class identifier (QCI) values to transmit the common field and the individual fields. The common field may be transmitted in a common bearer 320. In some applications, the common bearer 320 may have a guaranteed bit rate (GBR), guaranteeing that the common information is transmitted intact through the CN 315. Assuming that the individual fields are not essential for message recovery, such as in the case of video transmission where individual fields will only enhance the video quality, the individual fields may be mapped into non-GBR bearers 325i, 3252, 325N.

[0068] Since the procedure is application agnostic, any protocols suitable for M2M communications may be used, such as HTTP or protocols similar to HTTP, (e.g., a constrained application protocol (CoAP) defined by the Internet Engineering Task Force (IETF)).

[0069] Figure 4 shows an example of a network 400 including an application server 405 sending control messages to set energy usage parameters, and an M2M gateway 410 processing the control messages and performing message consolidation to control M2M devices 415i - 415_n. The application server 405 sends load control message to the M2M gateway 410 to set different energy usage parameters (420). After the M2M gateway 410 processes the control messages and performs message consolidation (425), the M2M gateway 410 broadcasts or multicasts common fields of a "set temperature" request, (e.g., "set load"), to the M2M devices 415i - 415_n (430) and sends an individual field, (e.g., charge current), in unicast to each M2M device 415 (435 and 440). The M2M devices 415 may send a response back to the M2M gateway 410 (445 and 450), and the M2M gateway may send a response to the application server 405 (455).

[0070] Figure 5 shows an example of a network 500 including a utility company 505, an M2M gateway 510 and smart meters 515i - 515_n. The M2M gateway 510 controls the multiple smart meters 515i - 515_n within a designated geographical area. The smart meters 515i - 515_nsend reports 520 periodically to the utility company 505 via the M2M gateway 510. Assuming these reports are latency-tolerant, the M2M gateway 510 queues the reports 520 (525) and performs message consolidation (530). The M2M gateway 510 sends combined messages with individual fields and consolidated common fields to the utility company 505 (535), thus reducing the load on the backhaul link, which may be a wireless link.

[0071] Figure 6 shows a multimedia broadcast and multicast services

(MBMS) reference architecture 600 used for video transmission. The MBMS bearer service uses IP multicast addresses for the IP flows. The advantage of the MBMS bearer service, as compared to legacy universal mobile telecommunications system (UMTS) bearer services, (interactive, streaming, and the like), is that the transmission resources in the core and radio networks are shared. One MBMS packet flow may be replicated by a gateway general packet radio service (GPRS) support node (GGSN), (not shown), a serving GPRS support node (SGSN) 605 and radio network controllers (RNCs), (not shown). A broadcast multicast service center (BM-SC) 610 may provide a set of functions for MBMS user services. The MBMS reference architecture 600 may further include a packet data network (PDN) gateway (PGW) 615, a mobility management entity (MME) 620, and an MBMS gateway (GW) 625.

[0072] Unicast streaming sessions may be desirable due to the personalized nature of each session, as compared to the operator's objective of efficient use of radio and network resources. In order to optimize both, a tight integration of overall unicast and broadcast or multicast sessions that is invisible or at least acceptable to the user is desirable. In the following description, "groupcast" is used to describe broadcast or multicast.

[0073] Dynamic unicast to groupcast video traffic switch is described herein that uses a new dynamic traffic switch technique that offloads the unicast video traffic to broadcast or multicast sessions. The exact unicast traffic patterns within a cell are identified. The identification may be dynamic, (i.e., packet by packet, or per service flow). If the traffic is sufficiently common to many users in the cell/area, the common portion of the unicast video traffic session may be converted into a broadcast session. As a special case, all video traffic may be common to a group of users. A multicast group may be created that WTRUs with the exact unicast traffic may be placed into. [0074] Identification of unicast video traffic patterns is described herein.

While a unicast video streaming session is active, this traffic flows thru the SGSN 605 or the PGW 615 as shown in Figure 6, which routes and forwards these packets to the appropriate destination WTRU.

[0075] Each packet may include information for the downlink (DL) path traffic (or service data flow (SDF)), such as the WTRU context and IP traffic parameters. For LTE, the PGW 615 maintains a downlink traffic flow template (DL-TFT) which binds a service data flow to an evolved packet system (EPS) bearer in the downlink direction. The PGW 615 stores a mapping between a downlink packet filter and an S5/S8a bearer to create the binding between the SDF and an S5/S8a bearer in the downlink.

[0076] For streaming video traffic, whether the streaming protocol is HTTP or a real time streaming protocol (RTSP), identifying the source and destination, as well as the video content may be performed.

[0077] Determining the source and destination address and video clip may require different ways to extract the relevant data from different protocols. However, the basic principle may remain the same. Alternatively, it may be required to look underneath a moving picture experts group-2 (MPEG-2) transport stream to find out the details of the video stream from the metadata, or monitoring an RTSP session negotiation and examining the details of the SDP payload to understand the presentation descriptions of the streamed video clip, such as media (audio or video) format, may be required.

[0078] Examining the MPEG transport stream may also reveal the granularity level of the coding used for that unicast video stream such as the codec format, frame rate, and the like. Moreover, it may be necessary to extract the uniform resource locator (URL) of the video clip from an RTSP play command. The details of how to extract this relevant information, (e.g., source, destination, video clip URL and media format), are known for streaming protocols, such as RTSP, HTTP.

[0079] Therefore, the MBMS reference architecture 600 of Figure 6 may track active streaming sessions for WTRUs 630 that it is serving. Once it is determined that the same clip is served for a plurality of WTRUs by looking at the common information, a decision to form a broadcast/multicast group may be triggered.

[0080] If the mobile carrier deployment is based on IP multimedia subsystem (IMS) architecture, the decision or policy to have this feature may be programmed by a policy and charging rule function (PCRF). Thus, the dynamic video traffic switch capability may be selectively turned on or off by an operator based on the network conditions. Similarly, based on the congestion in the network, via the policy of the PCRF, an operator may choose to apply a certain mix of unicast and xcast sessions formed, as will be explained below.

[0081] Forming an MBMS broadcast session is described herein. Once the

MBMS reference architecture 600 of Figure 6 makes the decision that unicast sessions are about the same video streaming session, the process to create a broadcast session begins. Subsequently, the decision to start a broadcast MBMS session is communicated to the BM-SC 610. At this point, characteristics of the video session, such as the URL of the clip, as well as the bookmark location of the playback, are passed to the corresponding entity. Thus, an MBMS broadcast service may be initiated.

[0082] Figure 7 shows a procedure 700 for forming an MBMS broadcast group. Once the WTRU local service is announced (705) right before the session start (710), individual unicast sessions may be terminated. The BM-SC 610 may inform the PGW/SGSN 605 about the readiness status (715) so that each session may be disconnected. Media data may flow thru the MBMS-GW 625 instead of during the broadcast session (720). The assumption is that the video content is streamed from a single source that all WTRUs are in synch with. Once the live event concludes, the MBMS service is dissolved when the session stops (725) with the conclusion of the data transfer.

[0083] Figure 8 shows an MBMS group session flow in a network 800. The network 800 includes a video server 805, an MBMS-GW/BM-SC 810, an MME 815, an MCE 820, a PGW/BM-SC 825, an eNB 830 and WTRUs 835i - 835_n. The set of WTRUs 835 that desire to receive identical or similar message content are referred to as "interested WTRUs". Message content may refer to a real time streaming traffic, (e.g., videoconferencing or a video streaming session), or a non- real time traffic-like video-on-demand session. At initialization, a network element such as the PGW/BM-SC 825 may monitor the set of WTRUs 835 in a multi-media broadcast over a single frequency network (MBSFN) that request a subscription to a particular session/traffic, and receive a unicast video traffic flow. On a condition that the number of interested WTRUs 835 exceeds a certain threshold, (e.g., static or dynamic), the PGW/BM-SC 825 may initiate a procedure to provide common content video layer information, (e.g., video payload), to the WTRUs via a broadcast session, (MBMS or any other form of IP multicast session), and provide scalable video content layer information to the WTRUs via unicast radio bearers (RBs), to allow efficient sharing of core network resources (840). The procedure is initiated by the PGW/BM-SC 825 sending an MBMS session start request 845 to the MBMS-GW/BM-SC 810, which is then forwarded to the MME 815 and the MCE 820. The MCE 820 may then decide to start the MBMS session via a broadcast transmission and indicate it to the MME 815 by sending an MBMS session start response 850 to the MME 815, and sending an MBMS session start request 855 to the eNB 830 to set-up a unicast RB towards the interested WTRUs 835 for an additional unicast mode.

[0084] Once a decision is made that a certain set of unicast sessions are part of the same video streaming session, the process to create a multicast session begins. Not all of the WTRUs 835 in the MBSFN area may be tuned into the live video streaming session. In this case, the WTRUs 835 that have identical sessions may be identified, and a multicast session is initiated. At this point, characteristics of the video session, such as the URL of the clip as well as the bookmark location of the playback, may be used to initiate an MBMS multicast service.

[0085] Other users that may attempt to establish a video streaming session may be identified and added to the MBMS session following the same procedure. Once there are no users left in this MBMS group, or if the streaming session is terminated, (whichever happens earlier), the MBMS broadcast group is dissolved. [0086] Figure 9 shows a procedure 900 of forming an MBMS multicast group. The difference between forming a multicast group and forming a broadcast group is that WTRUs have to join the multicast group. That is, they have to subscribe (905) and, in response to a service announcement (910), be authorized to join the group (915). The group may be formed for specific WTRUs, which may join the group once the network is ready. For example, the group may be formed automatically by being triggered from the network side. Once a WTRU joins the IP multicast group successfully (920), this is communicated to an SGW (925) so that it may disconnect the individual unicast streaming session of the particular WTRU unicast session. Media data may flow thru the MBMS-GW instead during at least one multicast session (930). Moreover while the MBMS multicast group is active, the SGW may keep track of its existence and if other unicast video sessions are attempted for establishment, it repeats the process to join such WTRUs to the MBMS group. Once there are no users left in this MBMS group or if the streaming sessions is ended/concluded (whichever happens earlier), the MBMS multicast group is dissolved (935 and 940).

[0087] Application to different video coding and format standards is described herein. As previously described, the video clip may have the same characteristics for all WTRUs. However, there may be cases where the video may be coded in different standards as well as formats. In order to accommodate this variety, a multicast group may be formed in a way that the group will serve video to WTRUs in a specific format (e.g., H264). Thus, a BM-SC may be free to form more than one multicast group for each video codec format. In addition, the video may be coded in scalable video coding (SVC) format, which lends itself to rendering of different video profiles on WTRUs. In this case, it is possible that for different profiles of SVC, different multicast streams may be formed.

[0088] As explained above, the SGW may have to examine the different

SVC streams looking at the SDP payload to understand the relevant profile for each WTRU and pass that information to the BM-SC. Then, a specific service announcement for video coded in a SVC base profile may be made, and mobile handsets may join this group. Another multicast group for a video coded SVC main profile may be formed, and laptops with third generation (3G) cards may join that particular group as referred above.

[0089] If the video is coded in SVC or multi- description coding (MDC), base

(or many other common) profiles may be propagated using the broadcast or multicast group by the decision made via a PGW/SGSN. Extra layers may be transmitted using unicast streams. The receiver WTRUs may then tune into the xcast channels to receive the common base profile, and tune into the unicast stream to receive the remaining profiles. Via this process, over the air resources may be efficiently utilized by combining the common elements. Finally, the receiving WTRU may stitch the separate layers after decoding them.

[0090] An example of estimating the efficiency of lossless compression algorithms is described herein. If there are n messages sent to n WTRUs, each message may have m bytes, whereby c bytes out of the m bytes are common to all of the messages. The remaining bytes may be assumed to be both distinct, (unique to each message), and have no internal redundancy, (as is typically the case with coded numeric fields). An "ideal" extraction algorithm may separate the c common bits to transmit them once. While further compression is possible, it is not expected to yield much gain, (as it is assumed that individual fields have no redundancy).

[0091] Typically, nxm bytes are transmitted. In accordance with the embodiments described herein, the common part c is transmitted once, and n times the unique parts (m-c). Thus, c + n(m - c) bytes may be transmitted. The saving as a fraction /_Idealis therefore: r nm - c - n(m - c) n— l c _π , . _/r. ideal = = · Equation (5) nm n m

[0092] Thus, based on Equation (5), the amount of data n in the limit as n»l may be reduced by the fraction of the common part. Even small n savings may be significant as long as c/m is a significant fraction. [0093] Overhead, (MAC, IP or the like), related to the splitting of the transmission of the fields of the same message between broadcast or multicast, and unicast, tends to reduce the gain of the procedure. If it is assumed that unicast requires u overhead bytes while broadcast or multicast requires b overhead bytes, then the saving (for u«m) may be expressed as: n{m + u)- {c + b)- n(m -c + u) ^" n(m + u)

Equation (6)

[0094] As shown by Equation (6), unicast overhead may reduce the relative savings by the fraction (1-u/m), thus implying that lower layers are better, (fewer overhead bits after the messages are split). Multicast overhead may reduce the savings by (ignoring unicast overhead) the fraction b/nm which may be relatively small.

[0095] An example of performing compression overhead analysis is described herein where a single transmitter has M messages to send to M receivers. To do so, the transmitter may have access to M point-to-point (private) channels to each receiver and 1 common (broadcast) channel shared by all of the receivers. It may be assumed that all of the channels are noiseless, (i.e., transmissions over them are perfect).

[0096] Each of the M messages may be N bits long. Additionally, there may be L components, (i.e., sub-messages, fields), that are common to all of the messages. Each individual message may contain as many as L+l "private" (individual) components. Thus, each of the M messages may be partitioned into Cm components, m e{l, ..., M}, and (L+ 1) < c_m≤ (2L+1), (where it is assumed that each message contains at least one private component), and each message maybe partitioned into 2L+1 components, (i.e., a private component is always located between 2 common components, where some of the private components may have 0 length (be a NULL)). It is desired to provide an efficient method of transmitting the messages over the available channels, (i.e., to minimize the total number of bits sent over M+1 channels, (M point-to-point channels and 1 common channel).

[0097] Each original message may be denoted by w_m, m e{l, M}. As already noted above, w_m, is partitioned into (2L+1) components. For any string x, I x I is the length of the string in bits. Thus, | w_m I = N. The components common among all messages are denoted vi, 1 e{l, L}. By assumption, | vi | >0 and the private components of message m are denoted by u_m,k, k e{l, L+l}. By assumption | ui | >0. The operation | | denotes string concatenation. Baseline ordering on the common components vi, VLIS also assumed. For each message that is defined, a permutation πι on {1, L} specifies how the common components are arranged in the message, where: m m,\ II ^νπ_η(\) II **m,2 II ·" II **m,I II ^v _m(L) II **m,I+l

Equation (7)

[0098] The partition of w_m defines n(w_m) as the set of indexes that denote the start of its 2L+1 components (shared and private), and thus: n(wm) = (ni, II2L), Equation (8) where 1<ηι<···<η2ΐ<Ν. N_c denotes the length (in bits) of all the common parts as follows:

N_c = ^ \v,\. Equation (9)

[0099] A potential transmission strategy may be implemented by using a protocol PO to fully transmit each message to each receiver on the point-to-point channel using MN bits. The common channel is not used. If each receiver is informed of n(w_m) and n_m, then the transmitter may send [ _j || ··· || v_z] on the common channel, while sending [u_ml || ··· || «_mZ+1] on each of the private channels.

The total number of bits sent is N_C+M{N -N_C) = MN -{M -\)N_C, which is the lower bound on the minimal number of bits that may be sent, (referred to as the lower-bound protocol BO. Alternatively, a protocol (PI) may assume that the transmitter (but not the receiver) knows (n(w_m), Tim) for each m. PI may then operate whereby the transmitter follows BO as outlined above. However, the transmitter may additionally encode (n(w_m), 7-_m) for each m and transmit these as part of the private message to the receiver. To encode n(w_m), the transmitter may encode 2L indexes, each requiring logN bits. Thus, the total encoding requires 2L logN bits. Some efficiency may be gained if, because n(w_m) is an ordered set of 2L N-bit values, only the possible combinations need to be encoded, where:

( Ν λ

2L log N - 2L log L < < 2L log N - L log L . Equation (10)

2L)

[0100] Similarly, encoding _m (assuming no restrictions on the permutation) is known to take between ½LlogL and LlogL bits, (there are L! possible permutations and ½LlogL<log(L!)<LlogL), is a well known factorial bound.

[0101] Combining the two, it may be concluded that even a minimal encoding of (n(w_m), 7-_m) may take about 2LlogN bits. Under the very reasonable assumption that N»L, this may be a very accurate approximation. Thus, the total number of bits sent using PI may be approximately MN - (M - Y)N_C + 2L log N .

[0102] Consequently, as long as (M - 1)N_C > 2L log N , PI may improve on the straightforward protocol P0.

[0103] Embodiments

1. A method of processing messages having similar content, the method comprising:

extracting common fields and individual fields from the messages; consolidating the common fields; and

broadcasting the consolidated common fields and the individual fields.

2. The method of embodiment 1 further comprising:

receiving the broadcasted fields; and

reconstructing the messages.

3. The method as in any one of embodiments 1-2 wherein the consolidated common fields and the individual fields are broadcast via a wireless network.

4. The method as in any one of embodiments 1-2 wherein the consolidated common fields and the individual fields are broadcast via a wired network.

5. The method as in any one of embodiments 1-4 further comprising: determining an amount of commonality between any two messages or between a message and a group of consolidated messages.

6. The method as in any one of embodiments 1-5 wherein the fields are extracted in an application layer.

7. The method as in any one of embodiments 1-5 wherein the fields are extracted in a transmission control protocol (TCP) layer.

8. The method as in any one of embodiments 1-5 wherein the fields are extracted in a medium access control (MAC) layer.

9. The method of as in any one of embodiments 1-8 wherein the messages include side information indicating message groups.

10. A method of processing messages having similar content, the method comprising:

extracting common fields and individual fields from the messages;

consolidating the common fields;

broadcasting or multicasting the consolidated common fields; and unicasting the individual fields.

11. The method of embodiment 10 further comprising:

receiving the fields; and

reconstructing the messages. 12. The method as in any one of embodiments 10-11 wherein the consolidated common fields and the individual fields are broadcast via a wireless network.

13. The method as in any one of embodiments 10-12 wherein the consolidated common fields and the individual fields are broadcast via a wired network.

14. The method as in any one of embodiments 10-13 further comprising: determining an amount of commonality between any two messages or between a message and a group of consolidated messages.

15. The method as in any one of embodiments 10-14 wherein the fields are extracted in an application layer.

16. The method as in any one of embodiments 10-14 wherein the fields are extracted in a transmission control protocol (TCP) layer.

17. The method as in any one of embodiments 10-14 wherein the fields are extracted in a medium access control (MAC) layer.

18. The method as in any one of embodiments 10-17 wherein the messages include side information indicating message groups.

19. A network element for processing messages having similar content, the network element configured to:

extract common fields and individual fields from the messages;

consolidate the common fields; and

broadcast the consolidated common fields and the individual fields.

20. The network element of embodiment 19 wherein the network element comprises at least one of an application layer, a transmission control protocol (TCP) layer or a medium access control (MAC) layer configured to perform the extraction of the fields.

21. The network element of embodiment 1 wherein the network element monitors a set of wireless transmit/receive units (WTRUs) that each receive a unicast video traffic flow and, on a condition that the number of WTRUs exceeds a threshold, the network element initiates a procedure to provide common content video layer information to the WTRUs via a broadcast session, and provide scalable video content layer information to the WTRUs via unicast radio bearers (RBs).

22. A wireless transmit/receive unit (WTRU) for processing messages having similar content, the WTRU configured to:

extract common fields and individual fields from the messages;

consolidate the common fields; and

broadcast the consolidated common fields and the individual fields.

23. The WTRU of embodiment 22 wherein the WTRU comprises at least one of an application layer, a transmission control protocol (TCP) layer or a medium access control (MAC) layer configured to perform the extraction of the fields.

[0104] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in combination with any of the other features and elements. In addition, the embodiments described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals, (transmitted over wired or wireless connections), and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, a cache memory, a semiconductor memory device, a magnetic media, (e.g., an internal hard disc or a removable disc), a magneto-optical media, and an optical media such as a compact disc (CD) or a digital versatile disc (DVD). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, Node-B, eNB, HNB, HeNB, AP, RNC, wireless router or any host computer.

Claims

CLAIMS What is claimed

1. A method of processing messages having similar content, the method comprising:

extracting common fields and individual fields from the messages;

consolidating the common fields;

broadcasting the consolidated common fields and the individual fields; receiving the broadcasted fields; and

reconstructing the messages.

2. The method of claim 1 wherein the consolidated common fields and the individual fields are broadcast via a wireless network.

3. The method of claim 1 wherein the consolidated common fields and the individual fields are broadcast via a wired network.

4. The method of claim 1 further comprising:

determining an amount of commonality between any two messages or between a message and a group of consolidated messages.

5. The method of claim 1 wherein the fields are extracted in an application layer.

6. The method of claim 1 wherein the fields are extracted in a transmission control protocol (TCP) layer.

7. The method of claim 1 wherein the fields are extracted in a medium access control (MAC) layer.

8. The method of claim 1 wherein the messages include side information indicating message groups.

9. A method of processing messages having similar content, the method comprising:

extracting common fields and individual fields from the messages;

consolidating the common fields;

broadcasting or multicasting the consolidated common fields;

unicasting the individual fields;

receiving the fields; and

reconstructing the messages.

10. The method of claim 9 wherein the consolidated common fields and the individual fields are broadcast via a wireless network.

11. The method of claim 9 wherein the consolidated common fields and the individual fields are broadcast via a wired network.

12. The method of claim 9 further comprising:

determining an amount of commonality between any two messages or between a message and a group of consolidated messages.

13. The method of claim 9 wherein the fields are extracted in an application layer.

14. The method of claim 9 wherein the fields are extracted in a transmission control protocol (TCP) layer.

15. The method of claim 9 wherein the fields are extracted in a medium access control (MAC) layer.

16. The method of claim 9 wherein the messages include side information indicating message groups.

17. A network element for processing messages having similar content, the network element configured to:

extract common fields and individual fields from the messages;

consolidate the common fields; and

broadcast the consolidated common fields and the individual fields.

18. The network element of claim 17 wherein the network element comprises at least one of an application layer, a transmission control protocol (TCP) layer or a medium access control (MAC) layer configured to perform the extraction of the fields.

19. The network element of claim 17 wherein the network element monitors a set of wireless transmit/receive units (WTRUs) that each receive a unicast video traffic flow and, on a condition that the number of WTRUs exceeds a threshold, the network element initiates a procedure to provide common content video layer information to the WTRUs via a broadcast session, and provide scalable video content layer information to the WTRUs via unicast radio bearers (RBs).

20. A wireless transmit/receive unit (WTRU) for processing messages having similar content, the WTRU configured to:

extract common fields and individual fields from the messages;

consolidate the common fields; and

broadcast the consolidated common fields and the individual fields.

21. The WTRU of claim 20 wherein the WTRU comprises at least one of an application layer, a transmission control protocol (TCP) layer or a medium access control (MAC) layer configured to perform the extraction of the fields.