Patent Application
20050021833
The present application relates to a network entity arranged to be connected to a communication network, and to a control method for such an entity.
As an example of a communication network,
As an example of a-communication,
This communication between terminals 101 and 25 is controlled on the basis of a control entity 211 in the control network 21 on the side of the mobile communication network, and a control entity 231 in the control network 23 on the side of telephone network 24. Control signalling is exchanged between these entities 211 and 231, and entity 211 exchanges control signalling with gateway support node 201 and gateway 22, whereas control entity 231 exchanges control signalling with gateway 241 and gateway support 242.
It should be understood that the illustration in
An example of a network having the architecture shown in
In the nomenclature of 3GPP, the first network part 20 for providing access could be the so-called Access Network, and the support nodes 201, 202 could be GGSNs(Gateway GPRS Support Nodes). Furthermore, the second network part 21 that provides control functions could be embodied by the so-called Core Network, and the entities 211, 212 could be one or more CSCFs (Call State Control Functions). The mobile stations 101, 102, 103 could then e.g. be mobile stations operating according to the Universal Mobile Telephone communication System (UMTS).
The object of the invention is to improve the capabilities of a communication network by providing an improved network entity.
This object is solved by a network entity having the features of claim 1, and by a control method described in claim 17. Advantageous embodiments are described in the dependent claims.
According to the present invention, a network entity for communication networks is provided, where said network entity is arranged to
control the receipt and generation of multicast transmissions in the communication network, a multicast transmission being a transmission that carries transmission content and a multicast group identifier, said multicast group identifier being an identifier for a group of destinations associated with the multicast transmission,
conduct a first procedure for determining destinations for a multicast transmission on the basis of a multicast group identifier, and
conduct a second procedure for handling a multicast transmission on the basis of the outcome of the first procedure, where the second procedure comprises routines for routing and/or processing and/or terminating and/or originating multicast transmissions.
The network entity therefore is a multicast management entity that may have the function of
a multicast router, such as multicast group management for the routing as such and multicast data processing, and/or
a multicast server, such as the originating capability of being a potential multicast source (for example in the case of multicast services in which a multicast transmission is received and stored, in order to be forwarded later, or a unicast transmission is received and changed into a multicast transmission since the multicast management entity decides or was ordered to send the transmission to multiple users), or the processing capabilities of generating, manipulating and/or mixing multicast content, and/or
a multicast proxy, such as the terminating and processing capabilities of e.g. adapting multicast content to radio interface characteristics (in the case of a mobile communication-network) and capabilities and end-user (equipment) capabilities and preferences.
Preferable, the network entity of the present invention is applied to a mobile communication network, but it should be noted that it can be applied to any type of communication network, i.e. wireless, wire-bound, fixed, satellite, etc..
Consequently, according to the present application, multicast capabilities may be added to a communication network, such that the network operator can participate in the providing and managing of multicast services and specific sessions for each service, which means that e.g. group specific admission control and group specific charging can be implemented, and the overall transmission efficiency in the communication network can be greatly increased, as the multicast managing and processing facilities enable the network operator to be aware of multicast services and multicast sessions, in order to better allocate and exploit network resources.
Further advantages of the present invention shall become evident from the study of the following detailed description of preferred embodiments of the invention, with reference to the enclosed figures, in which:
In the following, preferred embodiments of the present invention shall be described in the context of a network entity applied in a mobile communication network. However, it should be understood that the network entity of the present invention can be applied in the context of any type of communication network, and that the application in a mobile communication network is only a preferred example.
The basic call control entity 11 and the multicast management entity 13 both belong to the general control part of the mobile communication network, e.g. network part 21 shown in
The multicast management entity 13 is arranged to control the receipt of multicast transmissions from an appropriate source. As shown in
The multicast management entity 13 is furthermore arranged to also generate and/or originate multicast transmissions. The generation can be based upon a processing of received (multicast and/or unicast) transmissions, or the multicast management entity 13 can also be an original server that itself may originate its own multicast transmissions or e.g. change a unicast transmission into a multicast transmission based on additional information.
The multicast management entity 13 is arranged to conduct a procedure for determining destinations for a multicast transmission on the basis of a multicast group identifier. An example of a multicast group identifier is the multicast address known from the Internet Group Management Protocol (IGMP) of RfC 112. Generally speaking, a multicast group identifier is any indicator suitable for identifying a group of destinations.
The multicast management entity 13 is furthermore arranged to conduct a procedure for handling a multicast transmission on the basis of the outcome of the destination determination procedure, i.e. on the basis of the determined destinations. The handling of a multicast transmission can consist in a simple routing of a received transmission 151, 152, in the processing of a received multicast transmission, in the terminating of a received multicast transmission, or in the originating of a new multicast transmission. This is exemplified by arrow 153 in
It may be noted that the control signalling connections 171-175 shown in
Preferably, the multicast management entity 13 manages a multicast service record that associates identifiers of destinations with multicast group identifiers, and is arranged to receive and terminate service registration requests for a multicast service from potential destinations inside and outside of the mobile communication network. The multicast service record can be kept together with the multicast management entity 13, or can be stored anywhere else in the mobile communication network. The destination identifiers can be of any desirable or suitable type compatible with the mobile communication network and the other networks in which the potential destinations may be located. For example the destination identifiers can be Internet Protocol (IP) addresses, and the multicast group identifiers can be dedicated IPv4 (version 4 of IP) or IPv6 (version 6 of IP) multicast addresses.
The potential destinations may register for a multicast service in the multicast management entity 13 by means of appropriate signalling such as IGMP or Multicast Listener Discovery (MLD) signalling, or by means of dedicated signalling procedures belonging to the mobile communication network. Such signalling messages are terminated in the multicast management entity and group management information is stored thereby, such as the clients (destinations) registered for a specific multicast group. As an example, a general “football interest” group might be defined, and clients register for that group, in order to receive any multicast service transmissions about football associated with said group.
The multicast management entity 13 is furthermore preferably arranged to receive and terminate session registration requests for a multicast session from entities inside and outside of said mobile communication network that act as multicast destinations. In other words, the multicast management entity 13 receives a dedicated session registration message from a potential destination in order to then let that destination participate in a session for the corresponding multicast group. For example, the multicast management entity 13 keeps a record of all destinations currently registered for a specific multicast service (such as the above mentioned “football interest” group), and if the multicast management entity receives a multicast transmission carrying the multicast group identifier identifying said specific group, then the transmission can be forwarded to all of the destinations registered for the session. Especially, the multicast management entity can act as a type of multicast router, in order to propagate the received multicast content to all of the registered clients in the domain of the mobile communication network. The multicast management entity also enables the mobile network to become part of the multicast delivery tree by propagating group management information towards the multicast delivery tree external to the mobile network. Multicast routing protocols are used for this purpose. By propagating this information the mobile network becomes part of the multicast delivery tree just like any other Local Area Network.
Preferably, the multicast management entity 13 can also modify service registration requests, e.g. in response to mobility management.
Preferably, the multicast management entity 13 comprises a control part 131 and a processing part 132, as shown in
As already noted above, the structure of
In the case of using a control part and a processor part, one of the advantages of the present invention consists in the fact that the control part 131 can select the processing part 132 based on the client (destination) distribution e.g. can select one or more appropriate processing parts in such a way that the replication of the multicast content is done as close as possible to the destination locations. Generally speaking, the control part 131 can optimise the replication of multicast content on the basis of the destination distribution, in order to reduce the burden on resources. For example, this can be done by reducing the amount of replication to the necessary minimum, said necessary minimum being determined by the destination distribution on the one hand and the (dynamic) network state and (static) network architecture on the other hand. The selection of the processing part can also be based on the required and/or available resources or load sharing mechanisms can be applied. Also, processing costs can be used as an alternative or additional selection criterion.
In the case of using a control part and a processor part, the clients (destinations) may register with the control part 131, the control part 131 can select the optimal processing part 132 and transfers the information about the registered clients to that processing part 132. In case the clients register directly with the processing part 132, the processing part 132 provides the information about the registered clients to the control part 131 for charging, analysis, statistical, etc. purposes. A dedicated new multicast protocol between the control part 131 and processing part 132 could be used, or e.g. additional messages and parameters in H.248 could be used for both cases.
In case the clients register with the control part 131, the control part 131 in turn can register with the processing part 132, i.e. all multicast traffic will pass the control part 131 on its way to the destinations. This will enable the control part 131 to collect charging and statistics related information. The control part 131 in that case extends the multicast deliver path from the registered clients via the control part 131 itself to the processing part 132 and eventually to the multicast source (if that is not the processing part 132 itself). It is also possible to not have the control part 131 register with the processing part 132, in the case where the clients register to the control part 131. The control part 131 will then, however, either request the corresponding support nodes 12 of the clients to connect to the processing part 132 (e.g. by means of multicast routing protocols) or the control part 131 requests the processing part 132 to order the support nodes 12 to do this. The support nodes 12 then become part of the multicast delivery tree. It should be noted that also unicast (possibly multiplexed) connections between the processing part 132 and the support nodes 12 may be used to transmit the multicast traffic. In the case where the mobile communication network has a circuit switched access network, gateways or internet access servers for the circuit switched domain can be used in place of the above mentioned support nodes 12. This enables multicast service provisioning to the circuit switched domain.
The multicast management entity 13 is preferably also arranged to receive and terminate session invitation requests for a multicast session from entities inside and outside of the mobile communication network that act as multicast sources, e.g. from the server 14 or the mobile station 10 shown in
When the registration is done via the control part 131, the control part 131 of the multicast management entity 13 then selects the optimum processing part 132 and reserves the required resources in the network and registers with the processing part 132 to extend the multicast delivery path. Furthermore, it stores all this information in a database, said database preferably being integrated with the multicast management control part 131. The multicast management control part 131 also informs the multicast source (e.g. 10 or 14 in the example of
The multicast management entity 13 (the control part 131 and/or the processing part 132) have information about the multicast capabilities of the destinations (e.g. stored in a database) and can decide on whether a further multicast transmission (i.e. a single transmission containing a multicast group identifier) or whether a replication and the provisioning of several multicast transmissions and/or unicast transmissions have to be implemented. In the latter case, the processing part 132 terminates the data streams of the multicast routing protocol (e.g. Protocol Independent Multicast PIM), replicates the content and uses a plurality of unicast transmissions in the access network. The corresponding addresses for the destinations (clients) are provided by the control part 131, or the processing part 132 already has the addresses, when clients register to the processing part directly.
The multicast management entity 13 may also initiate multicast transmissions on its own, for example after having received a list of multicast sessions (identifying a multicast group identifier and a multicast source) from a central data base. Then instead of waiting for incoming requests, the multicast management entity 13 itself selects a processing part 132, contacts the listed multicast sources and stores information about the multicast stream, multicast source, processing part 132, etc. in its database. Multicast services initiated by the multicast management entity 13 may also be used when store and forward mechanisms are applied to the multicast services. A store and forward service is a service in which the multicast management entity 13 stores received multicast content and forwards it with a delay. The multicast service may be downloaded by the multicast management entity 13 and the forwarding/sending can be triggered by an external event, e.g. the receipt of a trigger message or the fulfilment of a predetermined timing condition, upon which the multicast management entity 13 starts the service delivery. As another option, the multicast content does not necessarily need to be delivered to all clients simultaneously. If certain clients are not available, they may get the content later (when they are available). In that case the multicast management entity will keep track of which clients have received the information, i.e. mainly which clients where available when the multicast content was delivered to the group. Multicast management entity initiated/ordered de-registration of clients that have received the content may be used to ensure that all clients receive the content only once.
Preferably, the multicast management entity 13 is arranged in such a way, that the procedure for handling a multicast transmission comprises a routine for processing the multicast content by changing one or more parameters of the multicast content and/or changing the content itself before sending the multicast content to destinations, such as mobile stations accessing the mobile communication network. As an example, the changing of a parameter can consist in adapting a multicast stream to air interface characteristics. For example, the transmission rate of a stream can be adapted to the available bandwidth on the air interface. An example of changing the content can consist in adding specific logos for the network operator, adding commercials or filtering out specific (undesirable) content.
Furthermore, it is preferable that the multicast management entity 13 is arranged such that the procedure for handling a multicast transmission comprises a routine for processing the multicast content by merging and/or combining the multicast content of one multicast transmission with the multicast content of another multicast transmission, before sending the multicast content to its destinations, for example mobile stations accessing the mobile communication network. This is similar to the merging/combining of multiple unicast streams.
Charging information for all of the entities involved in a multicast session may be collected in the multicast management entity 13 and forwarded to corresponding billing nodes in the mobile communication networks, and to billing nodes in other networks, if necessary or desired.
Preferably, the multicast management entity 13 is arranged to perform group specific admission control and/or group specific charging and/or group specific statistics collection and/or group specific statistics evaluation for multicast groups. Group specific admission control for example means that the multicast management entity 13 controls the maximum or minimum number of simultaneous members (registered destinations for a session). Specific charging means that the tariff charged to individual destinations (subscribers) can be changed on the basis of group related conditions, e.g. a lower tariff in case more clients (destinations) receive the multicast service simultaneously. A different example is the case when a predetermined minimum number of destinations is set in order that a session be conducted, such that if the number of clients is too low, the multicast management control part 131 rejects a session invitation request from a multicast source, or does not initiate a session of its own when acting as a multicast source itself.
The multicast management entity 13 may also perform authentication and authorization and charging of the sources of the multicast transmission.
According to the present application, the multicast management entity 13 (and in particular the processing part 132) can preferably act as a source or remote source of a multicast delivery structure in case of source based multicast routing structures, or it can act as the core (also called rendezvous point) in case of core based routing structures. These two types of multicast routing structures are e.g. described in: “IP Telephony: Packet-based multimedia communications systems”, by O. Hersent, D. Gurle, D. Petit, Addison-Wesley, Harlow, 2000, such that a further description is not necessary here.
Preferably, the multicast management entity 13 is arranged in such a way that it can specifically deal with multicast transmission content that comprises separable parts. Examples of multicast transmission content that contain separable parts are streams of different media type, such as video, audio and data, or different layers of scalably coded data, such as base and enhancement layers known e.g. from MPEG-4. In this case it is preferable that the procedure for determining destinations on the basis of a multicast group identifier comprises the determining of sub-groups of destinations, where each sub-group is associated with the receipt of one or more of the separable parts, and the procedure for handling a multicast transmission comprises a routine for controlling the separation of the multicast transmission content and the forwarding of respective separated parts in accordance with the determined sub-groups.
It may be noted that the definition of the sub-groups can be performed in any suitable or desirable way. For example, the sub-groups may be predefined by the network operator, and the potential destinations simply register for one of the predefined sub-groups. For example, for a predetermined number of (main) multicast groups containing an audio and a video stream, audio sub-groups can be predefined for each respective main group, such that a destination that registers for the audio sub-group only receives the audio stream, whereas a destination that registers for the main group receives the audio and the video steam. Alternatively, the multicast management entity may control the definition of sub-groups, e.g. on the basis of user request. As an example, if a destination (client) registers for a specific multicast group, e.g. the above mentioned football interest group, which for the purpose of the present example will be assumed to provide a video and an audio stream, and the destination at the same time indicates that it only wishes to receive the audio stream, then the multicast management entity can (dynamically) define an audio sub-group. Such a definition can also be coupled to a predetermined condition, e.g. that a predetermined minimum number of requests for the audio-only service is present.
The procedures for registering to a sub-group can be like the above described procedures for registering to a group in the general case. Each sub-group will have its own multicast sub-group identifier and thereby otherwise be like any other multicast group.
In other words, it is preferable that the multicast management entity 13 is capable of handling multicast services for heterogeneous clients (destinations) Heterogeneous clients e.g. have differing quality of service requirements, capabilities and preferences. For example, some mobile stations may only be equipped to receive audio, or only audio and data. Also, the heterogeneous destinations can be due to different access networks e.g. one access network for packet switching based mobile terminals and one access network for circuit switched mobile terminals, where e.g. the circuit switched mobile terminals may only receive audio information.
In accordance with the present invention, it is possible to let the multicast management entity 13 separate a received multicast content into a plurality of streams, where the separation and forwarding is done on the basis of separate multicast sub-groups. For example, a destination can select which media streams to receive, which in turn can also be coupled to specific billing (e.g. only receiving an audio stream is less expensive than receiving an audio and a video stream).
Equally, if the multicast content contains layered scalable coding with base and enhancement layers, the enhancement layer for example increasing the frame rate or spatial resolution, then multicast sub-groups can be assigned per layer.
The function of separating multicast transmission content can be implemented in many different ways, depending on individual desires, requirements and constraints. For example, it is possible that the multicast management entity is arranged to simply split the content belonging to a predetermined multicast group (“main” group) into parts and/or combinations of parts, each part or combination of parts being associated with its own sub-group (e.g. predefined by the network operator) and therefore its own multicast sub-group identifier, and then forward the respective sub-group transmissions using the corresponding multicast sub-group identifier, without having any knowledge of the clients registered for the sub-groups. In other words, the clients do not register with the multicast management entity, but rather with an entity further down along the multicast tree.
On the other hand, the multicast management entity may also be arranged to keep a record of the clients (destinations), in order to directly determine which clients are registered for which sub-group. This is e.g. necessary in case the multicast management entity replicates the content and forward it as unicast transmissions to the individual destinations. In case the multicast management entity is actively involved in the registration management, it may have to use additional multicast addresses and group management routines for the different subgroups. This may imply that it has to inform the clients about the multicast subgroup addresses and content in order for these clients to know what to register for.
An example is shown in
For example, multiple RTP (real-time transport protocol RfC1889) streams can be used in case of multiple media or layered coding, each RTP stream being based on a dedicated multicast group. Clients (destinations) register for the multicast sub-groups of the streams that they are interested in, or that they are able to receive a process. The multicast source does not know and does not care which layers or media the different clients receive or wish to receive, since it sends all the streams and media in the general group, and the multicast management entity provides the processing according to sub-groups.
With the presently described embodiment of the invention, the multicast management entity 13 can preferably itself apply layered coding or handle multiple media streams (possibly after splitting a multiplexed media stream). The multicast management entity 13 is arranged to split combined media streams or combined coding into separate media streams or separate codec layers. Possibly this is done after a transcoding of the streams. Alternatively, the multicast management entity 13 instructs the multicast source to send media streams in a required or desired format, either within an existing multicast session or by establishing a new multicast session. As an option, the multicast management entity 13 performs a capability request to the multicast source, in order to check and request whether the multicast source can provide the stream (generally the multicast content) in the required format. The multicast management entity then allocates multicast sub-group identifiers for the different media streams and/or different codecs, and informs the clients (destinations) about the purpose of the different multicast sub-groups, and the corresponding data (coding) inside each of the sub-groups. This may be done by a general multicast distribution channel for interested parties, to a dedicated multicast group, via a web page or any kind of default configuration mechanism. Clients can then subscribe/register to the multicast sub-group that they are able to handle and/or that they are interested in and/or they are simply willing to pay for.
This simplifies the processing in the multicast management entity, and is actually an embedded negotiation procedure between the multicast management entity and the clients.
According to a preferred embodiment, the multicast management entity 13 is a part of a multimedia handling system of the mobile communication network, where the basic call handling entity 11 for handling communications to and from individual mobile stations accessing said mobile communication network also is a part of said multi media handling system. More preferably; the present invention is applied to a mobile communication system arranged in accordance with the technical specifications of the 3rd Generation Partnership Project (3GPP) as specified by 3G TS 23.002, e.g. V5.30 of June 2001, 3G TS 23.228, e.g. V5.1.0 of June 2001, and 3G TS 23.060, e.g. V3.6.0 of January 2001, which are herewith all incorporated by reference.
In the context of a 3GPP architecture, the above mentioned multimedia handling system can be the Internet Protocol Multimedia Subsystem (IMS), the call handling entity 11 can comprise one or more Call State Control Functions (CSCF; i.e. one or more of a proxy CSCF, interrogating CSCF and serving CSCF), and said multicast management entity 13 can be a Multimedia Resource Function (MRF), where the control part 131 can be a Multimedia Resource Function Controller (MRFC), and the processing part 132 can be a Multimedia Resource Function Processor (MRFP). The support node 12 can then be a Gateway GPRS (General Packet Radio Service) Support Node (GGSN).
The location register function in the GGSN stores subscription and routing information (needed to tunnel packet data traffic destined for a GPRS mobile station to the GGSN where the mobile station is registered) for each subscriber for which the GGSN has at least one PDP (Packet Data Protocol) context active.
As already mentioned, the MRF is preferably split into a Multimedia Resource Function Controller (MRFC) and Multimedia Resource Function Processor (MRFP). The functions of the MRFC and MRFP are preferably as follows: the MRFC controls the media stream resources in the MRFP, and/or interprets information coming from an application server and a serving CSCF (e.g. session identifier) and controls the MRFP accordingly, and/or generates CDRs (Call Detail Records), whereas the MRFP performs bearer control on the Gi-interface (a Gi interface is a reference point between GPRS and an external packet data network), and/or provides resources to be controlled by the MRFC, and/or mixes incoming media streams (e.g. for multiple parties), and/or acts as a media stream source (for multimedia announcements), and/or performs media stream-processing (e.g. audio transcoding, media analysis).
Additionally, an Application Server may be provided (see e.g. servers 261, 262 in
The protocols used for control signalling and content transmission can be chosen as is suitable or desirable. As an example, these communication can be conducted in accordance with
SIP, Session Initiation Protocol (RFC 2543); control of multimedia sessions, and/or
SDP, Session Description Protocol (RFC 227); description of multimedia sessions, and/or
SAP, Session Announcement Protocol (draft); advertisement of multimedia sessions via multicasting, and/or
RT(C)P, Real-Time Transport (Control) Protocol (RFC 1889); transport of real-time data and provision of quality of service (QoS) feedback, and/or
RTSP, Real-Time Streaming Protocol (RFC 2326); streaming media delivery control.
The Session Initiation Protocol is an application-layer control (signalling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.
The Session Description Protocol (SDP) is used to describe multimedia sessions for the purpose of session announcement, session invitation, and other forms of multimedia session initiation. SDP is purely a format for session description, i.e. a well-defined format for conveying sufficient information to discover and participate in a multimedia session. SDP uses different transport protocols as appropriate, including SAP, SIP, and the Real-time Streaming Protocol (RTSP).
An SDP session description includes information such as: the type of media (video, audio, etc.), the transport protocol (RTP/UDP/IP, H.320, etc.), the format of the media (H.261 video, MPEG video, etc.).
A session description consists of a session-level description (details that apply to the whole session and all media streams) and optionally several media-level descriptions (details that apply to a single media stream)
The Session Announcement Protocol (SAP) is used to announce multicast multimedia conferences and other multicast sessions. SAP periodically multicasts packets containing a description of the session (SDP), to a well known multicast address and port. Potential remote participants can use the session description to start the tools required to participate in the session. The SAP announcer is not aware of the presence or absence of any SAP listeners. SAP is intended to announce the existence of long-lived wide-area multicast sessions.
The Real-time Transport Protocol (RTP) provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. The functions provided by RTP include payload type identification, sequence numbering, timestamping, and delivery monitoring. RTP is also suitable as a protocol for real-time transmission of audio and video over UDP and IP multicast.
The data transport is augmented by a control protocol (RTCP), which is used to monitor the QoS and to convey information about the participants in an ongoing session. Each media stream in a conference is transmitted as a separate RTP session (with a separate RTCP stream). RTCP reports provide statistics about the data received from a particular source, such as the number of packets lost since the previous report, the cumulative number of packets lost, the inter-arrival jitter, etc.
After session establishment (possibly after a distribution), the QoS can be monitored by RTCP. In case the required QoS can not be fulfilled any longer, a new distribution decision could be made.
Both RTP and RTCP have been engineered for multicast.
The Real-Time Streaming Protocol (RTSP) provides a standard way to remote control a multimedia server. While primarily aimed at web-based media-on-demand services, RTSP is also well suited to provide VCR-like controls for audio and video streams, and to provide playback and record functionality of RTP data streams. A client can specify that an RTSP server plays a recorded multimedia session into an existing multicast-based conference, or can specify that the server should join the conference and record it.
The above described embodiments, either individually or in combination with one another, can provide the following advantages:
point-to-multipoint or multicast services in a UMTS network,
network operator controlled group management, group admission control and group charging capabilities for multicast services,
the integration of a multicast media manipulation unit and a local multicast router (in the multicast management entity) provides efficient stream handling and additional capabilities,
the basic call handling entity (e.g. a S-CSCF) allocates the multicast management control part (e.g. a MRFC), and the multicast management control part allocates the multicast management processing part (e.g. a MRFP) as close as possible to the destinations, when the multicast management processing part must already take care of the replication of the multicast stream,
support for heterogeneous clients by using dedicated multicast groups for layered coding and multiple media streams,
same stream manipulation components (in the multicast management entity) as specified for unicast services are used for multicast services (after terminating or analyzing the content of the multicast routing protocols),
store and forward multicast service provisioning (e.g. remote multicast service resource pool for third party multicast service providers). This can also be viewed as a caching of multicast services closer to the destinations.
proxy function for multicast (or more general point-to-multipoint) service streams.
The network entity of the of present invention can be embodied by hardware or any suitable combination of software and hardware, and the control method of the present invention may be embodied by software. Consequently, the present invention may also be embodied by a data carrier or data storage device carrying such software.
The term “entity” refers to a distinguishable network part that is logically identifiable, which has one or more specific functionalities, and which may be located in one physical unit, but which can also be spread out over several physical units.
Although the present invention has been described on the basis of preferred embodiments, the described details only serve to provide the skilled person with a complete understanding, but the detailed embodiments are not intended to restrict the scope of the invention. Much rather, the scope of the invention is defined by the appended claims, in which reference numerals only serve to increase understanding but also do not restrict the scope.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP01/09952 | 8/29/2001 | WO |
