WO2009019201A2

WO2009019201A2 - System and method for control signaling in mbms networks

Info

Publication number: WO2009019201A2
Application number: PCT/EP2008/060108
Authority: WO
Inventors: Hans Bertil RÖNNEKE; Lars Gunnar Folke AHLSTRÖM; Thorsten Lohmar
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2007-08-07
Filing date: 2008-08-01
Publication date: 2009-02-12
Also published as: WO2009019201A3

Abstract

There is disclosed a manner of providing signaling resiliency in a broadcast communications network, such as an MBMS network, which sends control signals from a gateway node to multiple access nodes via an IP network. For each transmitted control signal message, at least one repetitive control signal message is transmitted, usually multiple times at predetermined intervals. The repetitive signal includes the same session control information as the original session control message, and may also include an indication that it is a repeat control message. It may also include a unique identifier to be read by the access nodes, enabling them discard the packet without further processing if the unique identifier indicates that it has received the same control information previously. In a preferred embodiment, several repeat session control messages are aggregated into a single group message and transmitted, and which may also be provided with a unique identifier to facilitate early discard if appropriate.

Description

SYSTEM AND METHOD FOR CONTROL SIGNALING IN MBMS NETWORKS

CROSS REFERENCE TO RELATED APPLICATION AND CLAIM OF PRIORITY

This application is related to, and claims the benefit of the filing date of U.S. Provisional Patent Application Ser. No. 60/954,486, which was filed on 07 August 2007, and which is incorporated herein, in its entirety, by reference.

TECHNICAL FIELD

The present invention is directed, in general, to mobile telecommunications networks and, more specifically, to the generation and transmission of reliable control signaling in a broadcast communication network.

BACKGROUND

Mobile telecommunications networks have advanced a great deal in recent years. The advances include technological improvements providing the networks with greater capacity, while at the same time improving efficiency and reliability. Coverage has also improved, providing service over a vast geographical area, as has interoperability, allowing different networks and even different technologies to work together. A combination of these factors and of the ability to deliver services at a more universally affordable price has led to a rapid increase in the number of subscribers. In addition, the number of available applications, or different types of services available, has also increased dramatically.

Mobile telecommunications has traditionally provided the same type of voice transmission as was available to wireline system customers, with the exceptions, of course, that the subscribers could access the service from wherever they were (within the coverage area), and could move about during a communication session. Mobile telecommunications systems, in general, typically employ a cellular architecture in which subscribers located within a small geographic area, or cell, communicate over a radio frequency channel with a nearby antenna. A service provider's coverage area includes a large number of such cells. Each antenna and its controlling components are connected to a switch of some kind, which is usually connected to a number of antennas. A number of switches are connected to a higher level network node. At some level in this hierarchy, certain nodes are dedicated to storing user profiles, for example containing identifying information about each subscriber and about their current location.

An example of one such system is shown in Figure 1. Figure 1 is a simplified block diagram illustrating selected components of a typical mobile telecommunication network 10. Network 10 includes nodeB 15, which communicates directly with a mobile station 12 via air interface 14. In essence, nodeB 15 provides an access point through which mobile station 12 may communicate with network 10. Though only a single nodeB is depicted in Figure 1 , there are normally a great many of them, each communicating with one or more mobile stations that are currently located in their cell, or sector. Each of these nodeBs is connected to a RNC (radio network controller); in the example of Figurei , nodeB 15 is connected to RNC 20. RNC 20 is in communication with SGSN (serving GPRS (genera! packet radio service) support node) 24, which is in turn connected to a GGSN (gateway GPRS support node) 26. GGSN 26 is, in this example, in communication with a BM- SC (broadcast multicast service center) 30. Note that the illustrated components of network 10 are useful for delivering to mobile station 15 a type of service other than conventional voice traffic, namely, broadcast media (or multimedia) content that can be transmitted from BM-SC 30. As its name implies, this broadcast media may be sent simultaneously to a number of different subscribers. One application for this type of transmission is what is sometimes referred to as MobileTV. Subscribers receiving the broadcasts may experience them using their mobile devices, and may continue to receive them with minimal interruption as they move from one geographic location to another. Note also that in the context of a mobile telecommunications network, the "broadcast" may in some cases more accurately be referred to as a point-to-multipoint transmission, or multicast. That is, it may not be a broadcast in the sense of traditional television broadcasts, where a transmitted signal may be picked up by any suitable device within range. The difference between the two terms, however, will not be considered relevant here unless a distinction is needed and specifically stated.

Typically, the mobile station 15 may be used for other purposes besides receiving MobileTV broadcasts, for example to communicate voice or data information to another device. For that purpose, other components not shown in Figure 1 may also be present in network 10. These components may reside the same or on different physical devices as those that are depicted.

These communications, whether for example multicast MobileTV, voice, or data, are communicated according to certain standard protocols. These standards are often developed and promulgated by standard-setting organizations and are frequently the collaborative effort of a number of manufacturers, service providers, and industry associations. Once such standard-setting body is known as the 3GPP (3^rd Generation Partnership Project). The architecture shown in Figure 1 is operational under a set of standards known collectively as 3GPP Release 7.

According to Release 7 (and earlier) protocols MBMS applications such as MobileTV used what might be referred to as bi-directional control signaling. Control signaling is used to prepare the components illustrated in Figure 1 for the broadcast process. For example, when a session START message is sent from BM-SC 30 to GGSN 26, and successfully received, an ACK (acknowledgement) message is returned. In this manner, of course, the BM- SC 30 would know that the message had been received and that it does not have to re-transmit the START message. A similar ACK is returned to the GGSN 26 from the SGSN 24 upon successful reception of the forwarded START message, and so on for the other nodes through the nodeB 15. If for some reason an upstream node does not receive an expected ACK message after the expiration of a predetermined timeout period, the original message may be resent. This bi-directional signaling ensures some level of signaling resilience where all intended downstream nodes receive (for example) the session START message. This signaling resilience helps to prevent, for example, the occurrence of "black cells" in the MobileTV network (cells where the broadcast is unavailable).

Several significant changes are being made, however, to system architecture and functionality in the 3GPP Release 8 family of protocols. The differences in this new architecture will be apparent from the Figures described below, but in general the number of network nodes participating in the signally procedure is being reduced. According to Release 8, a top-level MBMS GW (multimedia broadcast multimedia service gateway) may now communicate directly with enhanced access points, often referred to as eNodeBs. In a typical network, however, there may be thousands of eNodeBs, meaning that the practice of acknowledging a successfully received message with a returned ACK message to the immediate upstream node is not practical, at least if network-wide broadcast synchronization is desired.

One proposed manner of addressing this issue is to base control signaling on an IP multicast distribution model instead of Release 7's hierarchical scheme. IP multicast is more appropriate for the environment where a single top node must address a very large number of downstream nodes with good synchronization. IP multicast MBMS signaling is unidirectional, however, and there is no simple way for each node to provide an acknowledgement back to the originating top node. Even if such a practice was implemented, a large number of simultaneous ACKs might undesirably overload the top node.

Where simultaneous upstream acknowledgements are impractical, they could by design be done on a random basis within certain constraints that would likely spread them out over a workable time period. While this may avoid a one time peak load of the top node, there would still be a large number of ACKs to process, which may still impose an undesirable burden on the top node, at least at certain times, and there may be other complications as well. An intermediate node could be used to aggregate some or all of the anticipated acknowledgements, but while reducing the burden on the top node, this approach of course requires the addition of a node or functional entity to perform the acknowledgement-aggregation function. In other words, to date no satisfactory way to achieve the signaling resilience inherent in 3GPP Release 7 has been formulated for use with the architecture of Release 8.

SUMMARY

To address the above-discussed deficiencies of the prior art, it is a primary object of the present invention to provide a method and arrangement for providing signaling resiliency in a broadcast communications network, such as an MBMS network that sends control signals from a gateway node to multiple access nodes via an IP network.

In one aspect, the present invention is a method for unidirectional control signaling from a broadcast media gateway to at least one access node via an IP (internet protocol) network including the steps of transmitting a first IP/UDP (user datagram protocol) packet containing at least one session control message from the broadcast media gateway to the least one access node, and subsequently transmitting at least a second IP/UDP packet containing the at least one session control message from the broadcast media gateway to the least one access node. In a preferred embodiment, the network is a 3GPP Release 8 network and the session control messages are transmitted from a MBMS GW to a number of access nodes. The repeated session control messages are preferable transmitted continually at predetermined intervals. A number of repeat session control signals may be aggregated into a single packet to reduce the signaling burden imposed on the network. A unique Update ID value may be assigned to session control message packets so that a receiving node may quickly identify whether they are repetitive of messages that have been previously received, and thereby avoid unnecessary processing.

In another aspect the present invention is a network node, such an an eNodeB, for receiving and processing the repeated session control messages according to the method described above. The node includes a network interface arranged to receive IP packets containing session control messages, and a session control message processor arranged to examine a received session control message to determine if it has been previously received by the access node, and to discard the session control message if it is determined to have been previously received.

The foregoing has outlined rather broadly the features and technical advantages of the present invention so that those skilled in the art may better understand the detailed description of the invention that follows. Additional features and advantages of the invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art should appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the invention in its broadest form.

Before undertaking the DETAILED DESCRIPTION, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document: the terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation; the term "or," is inclusive, meaning and/or; the phrases "associated with" and "associated therewith," as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like; and the term "controller" means any device, system or part thereof that controls at least one operation, such a device may be implemented in hardware, firmware or software, or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely, in particular, a controller may comprise one or more data processors, and associated input/output devices and memory, that execute one or more application programs and/or an operating system program. Definitions for certain words and phrases are provided throughout this patent document, those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:

Figure 1 is a simplified block diagram illustrating selected components of a typical mobile telecommunication network;

Figure 2 is a simplified block diagram illustrating session-related signaling through selected components of a telecommunications network according to an embodiment of the present invention;

Figure 3 is an illustration representing a Group Session Control packet according to an embodiment of the present invention;

Figure 4 is a flow diagram illustrating a method of handling a received session control message according to an embodiment of the present invention; Figure 5 is a simplified block diagram illustrating selected components of a network node according to an embodiment of the present invention;

Figures 6a and 6b are simplified block diagrams illustrating one possible implementation of the present invention into an eUTRAN communication network; and Figure 7 is a table listing information elements in an MBMS Session

Control message according to an embodiment of the present invention.

DETAILED DESCRIPTION

FIGURES 2 through 7, discussed below, and the various embodiments used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the present invention may be impiemented in any suitably arranged broadcast/multicast telecommunications system.

The present invention is directed to a manner of increasing signaling resiliency in an MBMS (multimedia broadcast multicast service) network or similar environment. Implementation of the present invention will tend to increase signaling reliability, that is, the likelihood that each downstream node will receive a control message such as a session start or stop message. In addition, in preferred embodiments the present invention is implemented in such a manner as to mitigate any additional signaling burden imposed on the network.

Figure 2 is a simplified block diagram illustrating session-related signaling through selected components of a telecommunications network 100 according to an embodiment of the present invention. In the embodiment of Figure 2, a number of eNodeBs are depicted and referred to as 101 a through 101 n. As mentioned above, there may be a great many such nodes in the network, although any number of them may be used to implement the present invention. In addition, it is noted that the initial "e" (for example in "eNodeB") denotes that the component so designated represents an "evolution", that is an enhancement, usually of a previously specified component. This designation is often assigned to such components and their functionality as are proposed for the SAE/LTE (System Architecture Evolution/Long Term Evolution) of 3GPP Release 8. While the designation is also used herein to refer to these enhanced components, it should be understood that no specific component configuration or functionality (or enhancement) is required, except as necessary for operation according to a claimed embodiment and described herein.

In accordance with the embodiment of Figure 2, MBMS session-related signaling originates in eBM-SC 110. The eBM-SC 110 triggers the establishment of an MBMS user plane by generating a Session Start message and transmitting it to the MBMS GW (gateway) 120. The MBMS GW 120 then forms a Session Control message for transmission to the network eNodeBs. The Session Control message includes instructions for bearer context establishment and information related to the MBMS service area.

No particular format is required for the Session Control message unless specifically stated with respect to a particular embodiment. A preferred format is, however, to combine the Session Start and Session Update messages of 3GPP Release 7 into a Session Control message. An exemplary manner of transforming information elements specified in Release 7 is illustrated in Figure 7. Figure 7 is a table listing information elements in an MBMS Session Control message according to an embodiment of the present invention. The table of Figure 7 is adapted from Table 7.5A.2.5 of 3GPP TS29.060. As may be seen in the table of Figure 7, several Release 7 parameters have been stricken through to indicate that they are not required, and two new IP parameters have been added.

Whatever the precise message format, the use of repetitive Session Control messages increases the signaling resilience of the network 100 (shown in Figure 2). That is, it provides greater assurance that each of the eNodeBs 101 a through 101 n will receive each System Control message, if not when initially transmitted, then at least when the message is repeated.

In one embodiment, the Session Control message is repeated continually at predetermined intervals throughout an ongoing session. In other embodiments the interval may be adjusted based on criteria such as traffic level or the type of media being broadcast. In still other embodiments, a given Session Control message is repeated a number of times, where the number of repetitions may be either predetermined or adjustable based on predetermined criteria.

In some embodiments, the repetition scheme may vary according to the type of Session Control message being transmitted. in a preferred embodiment, a Session Stop message is repeated only once, or only a limited number of times. A Session Start message, on the other hand, may be repeated continually as long as the session is in progress. In this embodiment, an eNodeB that for some reason does not receive one of the few transmitted Session Stop messages may be configured to end the session after a certain time period has transpired without the receipt of an associated Session Control message. In addition, where the Session Start messages are repeated continually for the duration of the session, the lack of a Session Start message for a predetermined period may also cause the session to end. In any event, the repetitive Session Control messages will somewhat increase the load on the eNodeBs 101a through 101 n and the IP backbone 130. In most applications, however, this is not expected to amount to a peak load and may, in fact, be handled easily by the respective nodes with little or no adverse impact. In other applications, however, it will be deemed prudent to reduce the impact of repetitive signaling. The present invention provides mechanisms for doing so.

According to one embodiment of the present invention, repeat Session Control signals are employed to promote signaling resiliency. If there is only a single MBMS session ongoing in network 100, the additional signaling load is not expected to be very great. This will frequently not be the case, however; at any given time there may in fact be a number of sessions ongoing. According to the present invention, when this occurs, a number of Session Control messages may be aggregated into a single Group Session Control message. Control messages may be sent from the MBMS GW 120 to through the IP backbone 130 using IP/UDP packets. Each IP/UDP packet, of course, includes header information that bearing the destination address and other information useful in transmitting the packet to its destination and processing it upon arrival. By aggregating a plurality of Session Control messages together into a Group session Control message having one set of header information, the overall transmission and processing burden may be reduced.

Figure 3 is an illustration representing a Group Session Control packet 200 according to an embodiment of the present invention. In the embodiment of Figure 3, four session control messages have been aggregated. As is noted there, these four sessions are respectively numbered (for purposes of illustration) sessions 1 , 5, 6 an 13. The number of aggregated session control messages is exemplary, of course, in practice any number can be included up to the maximum IP/UDP packet size. Where only one session control message is available for sending at a given transmission time, it may be sent as a Session Control message, or formatted as a Repeat Session Control message, or as a Group Session Control message containing only a single session control message. Note, however, that in some implementations there may be little or no difference between these different types of messages. In another embodiment, if there is only one session control message to be sent, the MBMS GW delays sending the message, at least for a certain interval, until at least a second session control message is available to aggregate with the first. In other embodiments, more than two session control messages may be required. After expiration of the required interval, if one is established, the Group Session Control message may be generated and transmitted, aggregating whatever session control messages are available for transmission. The interval may be determined in advance, or may vary depending on network traffic levels or other factors. In some embodiments, the interval may vary according to the number session control messages that are available for aggregation.

Where there are available more session control messages than can be aggregated into a single Group Session Control message packet, they will of course have to be sent in a number of such messages. When this occurs, they may be randomly assigned to a first and a second Group Session Control message, or they may be assigned according to predetermined criteria. The predetermined criteria may, for example, include how long each session has been ongoing, or how many repeat session control messages related to it already been sent. In some embodiments, preference may be give to generating Group Session Control messages that are identical to one or more of those that have been sent before.

Returning to the illustration of Figure 3, each Group Session Control message also includes the IP/UDP header information necessary for sending the packet to the eNodeBs. Note that there is an economy to sending a number of session control messages using only one set of headers. Even more importantly, aggregating session control messages in this fashion generates fewer messages (packets) for transmission, which may reduce the cost of repeat messaging significantly.

The headers fields contain standard IP/UDP information, and may also identify the session control messages that are included in the packet. According to one embodiment of the present, they may also include an Update ID parameter. As will be explained in more detail below, the Update ID parameter enables more efficient processing in the recipient node, typically the eNodeB, by facilitating early disposal of unneeded packets.

For this purpose the value of the Update ID parameter contained in a session control message header must be unique. An integer of sufficient length may be used, for example. Although the integer would have a maximum length, and therefore maximum number of values, the integer would simply have to be long enough so that when a given integer value is eventually reused, there is no chance of confusing it with identical previous uses of the same value. This would of course, require that the recipient node clear out old integer values after a certain period of non-use. The Update ID could also be formed of a time-stamp, provided that the time-stamp resolution is sufficient to avoid giving the same time-stamp value to any two consecutive Update IDs.

Although Update ID values must be unique, it should be pointed out that any repeat session control message that is identical to a previously-sent message in other respects should have the same Update ID value as well. In this regard, it is also noted that a Session Control message is considered the first such message. That is, when a receiving node receives Session Control message it is the first time that it would have received the session control instructions it contains. A Repeat Session Control message is sent, as explained above, in an effort to ensure that every applicable node receives these session control instructions. For some nodes, the Repeat Session Control message may be the first reception of these instructions, for example if the Session Control message was lost en route. In networks where the Update ID parameter is used, it may or may not be included in the original Session Control message. Where it is used, however, it is preferably used in all Repeat Session Control messages. The same is true for Group Session Control messages, which may include either session control information sent for the first time or repeated session control information, or in some embodiments may contain both. Note, however, that in a preferred embodiment, the Group Session Control message includes an Update ID parameter and aggregates (one or more) session control messages that also bear their own Update ID information.

The handling of the session control messages in the eNodeB or other recipient node may now be addressed. Figure 4 is a flow diagram illustrating a method 300 of handling a received session control message according to an embodiment of the present invention. At START it is assumed that the network components necessary to perform method 300 are both available and operational. The method 300 then begins when the eNodeB receives (step 305) a session control message. In light of the discussion above, it is noted that this session control message may be a normal Session Control Message, a Repeat Session Control Message, or a Group Session Control message.

According to the embodiment of Figure 4, the eNodeB then examines the Update ID, if any, associated with the session control message to determine (step 310) whether it has a Group Update !D that matches any Update ID stored in an Update ID buffer of the eNodeB. If so, the message may be entirely discarded (step 315); a positive determination indicates that an identical message has been previously processed. In the case of a Group Session Control message, of course, this means that none of the individual aggregated session control messages will be examined. As should be apparent, this means that the Update ID value for a Group Session Control message uniquely identifies the entire aggregation, and if any of the individual session information is altered, a new Update !D value for the Group message must be used. Although each individual (aggregated) session control message preferably has its own Update ID value, if the Group Update ID value matches a value stored in the buffer, the values associated with each individual message are typically disregarded as the Group Session Control message is discarded. The process then continues to await the arrival of the next session control message. If, on the other hand, no Group Update ID value matches a value stored in the eNodeB Update ID buffer, then the Update ID value is stored in the buffer (step 320) and each of the messages in the session control message is processed. The update value of each of the received individual session control messages is examined to determine (step 325) whether the Update ID value in the individual session control message matches a value stored in the Update ID buffer of the eNodeB. If so, that particular (individual) message is discarded (step 316). If not, the Update ID value for the individual message is stored (step 330) in the buffer and processing continues. At this point it is noted that steps 310 and 320 are in this sense optional.

If a Group Session Control Update ID value is not examined, or no comparison with the buffer made, the method 300 simply examines each of the individual messages. In this sense, assigning an Update ID value to a Group message is also optional, though preferred in most embodiments. It is also noted here that if the Session Control messages and Repeat Session Control messages do not have a "group" Update ID value, the method would simply begin at step 325. if for some reason there are no Update ID values at all, then the method simply begins with step 335.

In step 335, the MBMS Service Area Information Element is examined to determine whether any of the service area codes indicated there are associated with the eNodeB. If not, indicating that the eNodeB is not part of the relevant MBMS service area, then the message is discarded (step 317). If, on the other hand, the eNodeB determines that it is a part of a relevant service area, it then determines (step 340) what action should be taken with respect to the identified MBMS session. In accordance with a preferred embodiment of the invention, the individual session control message will be either a Session Stop message or a Session Control (Start or Update) message.

The method 300 of Figure 4 proceeds to performing (step 345) the task indicated by the type of message. For example, it uses the TMGI (temporary mobile group identity) or other MBMS identifier present in the message to perform a lookup with respect to the MBMS bearer context. In the case of a Stop message, in one embodiment the eNodeB stops the session and forwards no more session content over the radio air interface. It also leaves the associated multicast group towards the IP backbone, and it removes the MBMS context associated with that session. These steps may vary between applications and are not separately shown in Figure 4. In some embodiments, the Session Stop messages are not used, and inactive sessions are simply allowed to time out. As mentioned above, old values in the Update ID buffer should be cleaned out from time to time (step also not shown). In the case of a Session Control message, in one embodiment the eNodeB simply continues the exiting session if a bearer context is found (that is, the Session Control message is in the nature of an Update message) or creates and stores a bearer context if one is not found (that is, the Session Control message acts as a Start message). The eNodeB then continues the broadcast session by forwarding content to mobile terminals or, more broadly, any designated UE (user equipment) devices in the relevant service area. Again, these steps may vary between appiications and are not separately shown in Figure 4.

It is noted, however, that if the session is perceived to be new not because it is, but because the original start message was lost, the procedure in the eNodeB remains the same. The Repeat Session Control Message (or Group Session Control message) has successfully repaired what would otherwise likely be a black cell. The same is true if the absence of an MBMS bearer context is do to an eNodeB failure and restart (or restart for another reason). Hanging sessions are similarly avoided, since Stop messages are also usually place in a Repeat Session Control Message or Group Session Control message. In the method of Figure 4, in addition to performing the indicated tasks, the eNodeB also determines (step 350) if there are any more session control messages that had been aggregated with the message or messages already processed. If so, the steps 325 through 350 are repeated until all of the aggregated messages have been processed. At that point the method continues, awaiting receipt of the next Session Control message.

Note that the sequence of operations presented in Figure 4 is exemplary, and in other embodiments the method steps may be performed in any logically-consistent order. In addition, other steps may be added, or in some cases removed, within the spirit of the present invention.

Figure 5 is a simplified block diagram illustrating selected components of a network node 400 according to an embodiment of the present invention. In the embodiment of Figure 5, network node 400 is an eNodeB and includes an IP network interface 405 arranged at least for receiving broadcast content and control messages. A session control message processor 410 is arranged to examine received control messages and determine whether they are provided with an Update ID value and, if so, whether that value has previously been stored in Update ID buffer 420. Session control message processor 410 is further arranged to store received Update ID values not found in the Update ID buffer 420 and to determine whether the received session control message is intended for a service area served by eNodeB 400.

A controller 450 is provided for controlling the operation of network interface 405 and session control message processor 410, and for executing instructions contained in the received session control messages as appropriate. A memory 415 is provided for storing program instructions and data, and for storing MBMS bearer contexts created by controller 430 if needed for a MBMS session. Radio frequency transceiver 450 also operates under the control of controller 430 to communicate over an air interface via antenna 455.

In this manner the present invention helps to ensure reliable IP multicast-related signaling in an MBMS or similar environment. The advantages of the present invention are of particular advantage in MBMS networks operating according to the 3GPP Release 8 SAE/LTE family of standards. When implemented in such an environment, the present invention helps to insure that MBMS session are appropriately started, maintained and stopped in each eNodeB, and helps to manage restarts and temporary failures as well. The risk of hanging sessions is reduced or eliminated.

The present invention also has the advantage of being amenable to advantageous implementation in existing networks. For example, the use of a multicast-based control plane with continually repeated session control messages makes it possible to introduce MBMS into an eUTRAN (evolved UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network) environment in basically two steps. First, as illustrated in Figure 6a, all eNodeBs are configured to listen to a particular multicast address for receiving session control messages from the same source, namely, the MBMS GW.

Second, as illustrated in Figure 6b, a MB-SFN (multimedia broadcast single frequency network) is introduced by data reconfiguration in the eNodeBs, which should form the area where the SFN is used for some or all broadcast sessions or for MobileTV. Those eNodeB's are then simply configured with another multicast address, which will be a new separate control "channel" which is only used by the MCE (multicast coordination entity) node for session control messages to eNodeBs in the SFN area. Additional control "channels" may be added if there are more than one MCE.

An alternative to use different multicast addresses for different control "channels", is to use Source Specific Multicasting (RFC 4607). All control "channels" can then use the same IP multicast address, but the !P address of the source (MCE#1 , MCE#2, MCE#3, etc and even the MBMS GW) is configured into eNodeB's in addition to the multicast address of the control "channel". Both are then used in the IGMP (Internet Group Management Protocol) joins, and by the IP backbone routers in their forwarding of packets for the control "channel".

Although the present invention has been described in detail, those skilled in the art should understand that they can make various changes, substitutions and alterations herein without departing from the spirit and scope of the invention in its broadest form.

Claims

CLAIMS:

1. For use in a communication network for sending media broadcast service transmissions to UE (user equipment) devices through an access node, a method for unidirectional control signaling from a broadcast media gateway to at least one access node via an IP (Internet protocol) network, the method characterized by the steps of: transmitting a first IP/UDP (user datagram protocol) packet containing at least one session control message from the broadcast media gateway to the least one access node; and subsequently transmitting a second !P/UDP packet containing the at least one session control message from the broadcast media gateway to the least one access node.

2. The method as set forth in Claim 1 further characterized by the step of including in the second IP/UDP packet an indication that the at least one session control message contained therein is repetitive of a previously- transmitted session control message.

3. The method as set forth in Claim 1 The method of claim 1 , wherein the second IP/UDP packet contains a field having a value uniquely identifying the at least one session control message.

4. The method as set forth in Claim 3 wherein the unique value is a selected integer value.

5. The method as set forth in Claim 3 wherein the unique value is a time stamp.

6. The method as set forth in Claim 1 wherein the second IP/UDP packet is sent at a random time subsequent to the sending of the first IP/UDP packet.

7. The method as set forth in Claim 1 wherein second iP/UDP packet is sent at a predetermined time interval subsequent to the sending of the first IP/UDP packet.

8. The method as set forth in Claim 7 wherein further characterized by the step of transmitting at least a third IP/UDP packet containing the at least one session control message from the broadcast media gateway to the least one access node at the predetermined time interval subsequent to the sending of the second IP/UDP packet.

9. The method as set forth in Claim 8 wherein the at least a third !P/UDP packet is a plurality of IP/UPD packets, with each subsequent packet sent at the predetermined time interval subsequent to the sending of the preceding IP/UDP packet.

10. The method as set forth in Claim 1 , wherein the at least one session control message is a plurality of session control messages.

1 1. The method as set forth in Claim 10, wherein the second IP/UDP packet contains a field having a value uniquely identifying the aggregated session control messages, and wherein each individual session control message is also associated with a value uniquely identifying the individual session control message.

12. The method as set forth in Claim 1 , wherein the communication network is an MBMS (multimedia broadcast multicast service) network.

13. The method as set forth in Claim 12, wherein the communication network is a eUTRAN network and the at least one access node is an eNodeB.

14. The method as set forth in Claim 13, wherein the eUTRAN and the eNodeB are operable according to the 3GPP Release 8 protocols.

15. The method as set forth in Claim 1 further characterized by the step of receiving the second IP/UDP packet in the at least one access node.

16. The method as set forth in Claim 15, further characterized by the step of determining whether the at least one session control message has previously been processed by the at least one access node and, if so, discarding the second IP/UDP packet without further processing.

17. The method as set forth in Claim 16, further characterized by the step of determining whether the at least one session control message is relevant to a service area served by the at least one access node.

18. The method as set forth in Claim 17, further characterized by the step of acting on instructions contained in the at least one session control message if it has not been previously processed by the at least one access node and is relevant to a service area served by the at least one access node.

19. For use in a communication network for sending media broadcast service transmissions to UE (user equipment) devices, an access node for receiving broadcast service media and forwarding the media content to the UE over an air interface, the access node characterized by: a network interface arranged to receive IP packets containing session control messages; and a session control message processor arranged to examine a received session control message to determine if it has been previously received by the access node and to discard the session control message if it is determined to have been previously received.

20 The access node as set forth in claim 19, further characterized by an Update ID buffer for storing Update ID values in packets containing session control messages. 21 The access node as set forth in claim 20, wherein the session control message processor is further arranged to determine if a received session control message has been previously received by comparing an Update ID value associated with it to values stored in the Update ID buffer.

22 The access node as set forth in claim 21 , wherein the access node is an eNodeB.