Patent Application
20050233760
The present invention relates in general to Multimedia Broadcast/Multicast Services (MBMS) in mobile communication systems.
In the third generation telecommunication systems, higher bit-rates are offered as well as better possibilities for transmitting variable bit rate traffic. For instance, services utilizing different quality requirements are possible to multiplex. Such possibilities open up for new types of services. One of these services that is going to be included in the 3GPP (3rd Generation Partnership Project) standard is a Multimedia Broadcast/Multicast Service (MBMS).
The intention with MBMS is that different users can subscribe to broadcasting and/or multicasting of multimedia information of different kinds. An information provider thus transmits the same multimedia information to a number of users. Since multimedia information typically requires high transfer capabilities, a simultaneous broadcasting/multi-casting of such information will occupy a number of times as large transfer capabilities compared with a single transmission. Furthermore, if a large number of the recipients are located in the vicinity of each other, being connected to the same Node B (or base station) or at least the same MSC/VLR (Mobile Services Switching Centre/Visitor Location Register) and/or SGSN (Serving General packet radio service Support Node), the local communication resources may be severely limited. The introduction of MBMS thus potentially gives rise to a capacity problem. Furthermore, there are problems if the multitude of MBMS information is substantially unsynchronized.
An object of the present invention is to provide methods and devices allowing for reduction of potential capacity problems operating MBMS. Another object of the present invention is to provide synchronized MBMS data to users of one and the same MBMS group. A further object of the present invention is to provide reliable and efficient mechanisms for attaching and removing users to a MBMS session.
The above objects are achieved by methods and devices according to the enclosed patent claims. In general words, the control and user planes for MBMS are allowed to be separated. At least two user equipments belonging to the same multicast group receives MBMS data over a common user plane over the Iu interface. In cases where user equipment is controlled by a Radio Network Controller (RNC) different from the Controlling RNC (CRNC), the Radio Network Sub-system Application Part (RNSAP) is extended by procedures communicating MBMS information from the Serving RNC (SRNC) to the CRNC. New signaling over the Iu interface could range from simple requests to establish a user plane to more complicated signaling supporting configuration/reconfiguration of session parameters. The control plane of such user equipment can thus have a separate path compared with a common user plane. Preferably, the user plane is arranged directly over the Iu interface between a serving support node and the CRNC, while control planes may have a path over the Iur interface.
One of the advantages with the present invention is that since Iu MBMS user planes are established where needed and in case of common resources being allocated for several members of a multicast group receiving data in the same cell, the presence of multiple unsynchronized flows for the same MBMS session is avoided. Furthermore, enhanced procedures of the RNSAP protocol enables users controlled by a RNC different from the CRNC to participate in a MBMS multicast session. The present invention also evolves the current Universal mobile Telecommunication system Radio Access Network (UTRAN) architecture in a backward compatible way and maintains the current handling in case of dedicated resources. Moreover, signaling of MBMS information feedback between two RNCs connected via an Iur interface is enabled by the introduction of a new MBMS information transfer procedure.
The invention, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:
a is a block scheme of an embodiment of a mobile communication system supporting MBMS via dedicated links;
b is a block scheme of an embodiment of a mobile communication system supporting MBMS via common links according to the present invention;
a is a block scheme of another embodiment of a mobile communication system supporting MBMS via dedicated links;
b is a block scheme of another embodiment of a mobile communication system supporting MBMS via common links according to the present invention;
The present invention comes into use mainly in the third generation mobile communication systems. A typical example of such a mobile communication system 1 is illustrated in
In the illustrated RNCs 22A, 22B are controlling two base stations 30A-D each by connections 25 over an Iub interface 24. (In the present embodiment, the RNC 22C does not directly control any base stations.) The base stations 30A-D are also commonly known as “Node Bs” in the 3GPP specifications. Each base station 30A-D operates the radio access within a certain geographical area—cell 40A-D. User equipment 50A-D moves within the coverage of the cells 40A-D and can communicate by radio communication 35 via an Uu interface 34 with at least one of the base stations 30A-D. The base stations 30A-D thereby comprises means for communication over the radio interface Uu 34 according to prior art within this field. Similarly, the user equipments 50A-D comprises means for communication over the radio interface Uu 34 according to prior art within this field. The details of these devices and methods are not essential for the understanding of the present invention and are furthermore easily available in standard literature. The User Equipment UE 50A-D typically comprises a mobile equipment 51, e.g. a mobile phone or a portable computer, and a user SIM (Subscriber Identity Module) card 52.
The internal communication of a mobile communication system 1 according to
The core network 10 comprises in this embodiment a GMSC (Gateway Mobile Switching Centre) 18, which is a switch at the point where all circuit switched connections to and from external networks pass. A MSC/VLR (Mobile Services Switching Centre/Visitor Location Register) 11, connected to the GMSC 18, is a switch and database that serves the UE for circuit switched services when the UE is within the range of a RNC 22 of the UTRAN connected to the core network 10. The MSC function is used to switch the circuit switched calls. The VLR function holds track e.g. of the visiting user's service profile. The MSC/VLR 11 and the GMSC 18 are also connected to a HLR (Home Location Register) 13, which is a database located in the user's home system comprising a master copy of the user's service profile. The service profile comprises e.g. information about allowed services, supplementary service information and will in the case of MBMS also comprise information about such services. The HLR 13 stores the UE 50 location on the level of MSC/VLR and/or SGSN.
The core network 10 also comprises nodes connected to GPRS (General Packet Radio Service). A GGSN (Gateway GPRS Support Node) 19 is a switch at the point where all data packet traffic to and from external networks pass. The GGSN 19 is connected to a SGSN (Serving GPRS Support Node) 12. The functionality of the SGSN 12 is similar as for the MSC/VLR 11, but for packet switched services. The SGSN 12 and the GGSN 19 are also connected to the HLR 13. There might also be an optional interface between the MSC/VLR 11 and the SGSN 12.
The core network 10 communicates via the Iu interface 17 with the UTRAN 20. In this embodiment, the UTRAN 20 is illustrated to comprise two RNCs 22, interconnected by the Iur interface 14. Each RNC 22 has as in
The RNC 22 is the network element responsible for the control of the radio resources of UTRAN 20. It interfaces the CN 10 and also terminates a Radio Resource Control (RRC) protocol that defines the messages and procedures between the mobile 50 and the UTRAN 20. Within the UTRAN 20, a RNC 22 can take up different roles, e.g. as a Serving RNC (SRNC), a Drift RNC (DRNC) or a Controlling RNC (CRNC).
A CRNC is always directly associated with one or more Node Bs 30. The CRNC is responsible for the load and congestion control of its own cells and executes the admission control and code allocation for new radio links to be established in those cells. The CRNC thus terminates the Iub interface 24 towards the Node B 30.
In the 3GPP standard, a UE can use resources for the UE-to-UTRAN connection from more than one RNS. The RNCs available in the UTRAN will then play different roles with respect of that particular UE. A SRNC for a particular mobile is a RNC that terminates both the Iu link for the transport of user data and the corresponding signaling to and from the core network related to radio access. The SRNC terminates further radio resource control signaling between the UE and the UTRAN. The SRNC may be a CRNC, but not necessarily. However, a specific UE has one and only one SRNC.
A DRNC is any other RNC that controls cells used by the UE. A DRNC of a UE is consequently always different from the SRNC of that specific UE. The DRNC routes data between the Iub and Iur interfaces. A certain UE may therefore have zero, one or more DRNCs.
One physical RNC normally contains all the CRNC, SRNC and DRNC functionalities. Furthermore, a SRNC associated with a certain UE may simultaneously be a DRNC for another UE.
A general protocol model for UTRAN terrestrial interfaces is illustrated in
The control plane 105 is used for all UMTS control signaling. It includes an application protocol 111 and a signaling bearer 113 for transporting application protocol messages. The application protocol 111 is typically used for setting up bearers to the UE, e.g. radio access bearer in the Iu interface and radio links in the Iur and Iub interfaces.
The user plane 107 is instead responsible for the transmission of all actual information to the user, e.g. in the form of coded voice or general data packets. The user plane 107 includes data streams 115 and data bearers 117 for the data streams 115. Each data stream 115 is characterized by at least one protocol specified for that particular interface.
The transport network control plane 106 is used for all control signaling within the transport layer and acts therefore between the control plane 105 and the user plane 107.
The MBMS is a service offered by a content provider to subscribers of such a service that comprises synchronized broadcasting and/or multicasting of multimedia information to a number of users. A typical embodiment of a procedure of a MBMS multicast service is illustrated in
In step 204, a service announcement is performed. This mechanism provides the user with information about the service, parameters required for service activation and/or other parameters related to the service. The service start time is typically an important parameter. The way in which the announcement information is distributed may vary from system to system, from service operator to service operator and even from user to user within the same system. If a subscriber decides to activate the MBMS, the subscriber joins a multicast group, in step 206. This is an MBMS multicast activation by the user. The user indicates to the network that he is prepared to receive data of a specific MBMS.
Session start, step 208, is the step by which the broadcast-multicast service center starts to send data. The start occurs typically independently of activation of the service by the user. The session start may therefore occur after the joining step 206 as well as before the joining step 206, depending on the user actions. However, the session start is the trigger for network resources establishment for the MBMS data transfer. Step 210 is a MBMS notification, which informs the UEs about forthcoming and/or ongoing multicast data transfer. MBMS data is transferred to the UEs of a multicast group in step 212. The arrival of a first packet at the GGSN may coincide with the session start 208.
In step 214, the broadcast/multicast service center determines that there will be no more data to send for some period of time and stops the session. The period is long enough to justify a release of allocated network resources. In step 216, the user leaves the multicast group and is thereby no longer prepared to receive any MBMS data of that specific service. The procedure ends in step 218.
The steps of subscription 202, joining 206 and leaving 216 are performed individually per user. The other steps are performed on a service provider level, i.e. that all users involved are related to the steps. The steps may be repeated depending on the particular needs and requirements. Furthermore, the different steps may come in a different order or may be performed in parallel. Particular the steps of subscription 202, joining 206, leaving 216, service announcement 204 and MBMS notification 210 run typically in parallel with other steps.
The present invention does not relate to data transfer in the core network as such. Therefore the provision of the MBMS data from a content provider to a suitable SGSN is performed according to any suitable prior-art solutions and are not described more in detail. In the following description, it is therefore assumed that at least one SGSN has the requested MBMS data from the particular broadcast/multicast service center available in one way or the other, e.g. via an GGSN as an entry point. The role of the SGSN is in this context to perform user individual network control functions and to provide MBMS transmissions to the radio access network.
Consider a first MBMS scenario, illustrated in
If the multicast group 60 has enough members, there will be a wish to use point-to-multipoint links for data distribution, in order to save resources. The UTRAN may, on a per cell basis, select whether to use a point-to-point or a point-to multipoint distribution of MBMS data. For, instance, if more than a predetermined number of users are members of the multicast group 60 and using point-to-point distribution, a switch to point-to-multipoint distribution can be selected. Similarly, if less than a predetermined number of users are member of a multicast group 60 using point-to-multipoint distribution, a switch to point-to-point distribution can be performed. The decision is preferably made by the CRNC of the cell in question.
In
The RNC 22 in
In the above case, where only one SGSN and one RNC are involved, the strategy may seem quite simple. However, in scenarios having the Iur interface the situation becomes more intricate. References are now made to
Three connections 61A-C are established between the SGSN 12 and each of the UEs 50A-C. The connections 61A and 61B goes directly from the SGSN 12 to the RNC 22A, while the connection 61C goes via the RNC 22B. Each of these connections 61A-C comprises a user plane 107 and a signaling plane 105. Dedicated resources are thus used to provide the MBMS to the group members.
In
The data stream to be sent to the different group members is identical, and individual resources are therefore not necessary. In order to save resources within the UTRAN, a single user plane 107′ is also here used between the SGSN and the RNC 22A as a common user plane for all members of the multicast group. The MBMS RAB will thus possibly logically be associated with a user plane, which may be established towards another RNC. Here, a common resource for the data stream is used all the way to the different UEs 50A-C.
So far, the situation seems to be very similar to the one of
Therefore, according to a preferred embodiment of the present invention, the Iur interface 14 between the RNC 22A and the RNC 22B is arranged for supporting communication of MBMS information related to the UE 50C from the RNC 22B to the RNC 22A. The RNC 22A, which in this embodiment is the CRNC of the cell in which the multicast group is present, will initiate the establishment of the user plane carrying MBMS data over the Iu interface 17 when there are sufficient users for that MBMS multicast session in its cells. In other words, the RNC 22A comprises means, preferably as software routines, for achieving the use of a common user plane between the SGSN, e.g. a serving support node, and the RNC 22A for the requested multimedia broadcast/multicast data to the UEs. This functionality associates the control signaling arriving at the individual control planes to the RNC 22A with the data arriving at the common user plane.
With this embodiment of the invention, the CRNC will initiate the establishment of the Iu user plane carrying common MBMS data when there are sufficient users for that MBMS multicast session in cells under its control. Mechanisms over the Iur interface have to be provided in order to enable the UE 50C that is controlled by the RNC 22B to join a certain session. There is a need to transfer MBMS RAB (Radio Access Bearer) information coming from the core network to the DRNC 22A, so that the DRNC 22A can attach such an UE 50C to the MBMS session. The DRNC should preferably return to the SRNC the information on the actual resources allocated to the UE. This information may also be transferred at a later occasion. If these resources are common ones, the DRNC would already have or has to establish an Iu user plane for MBMS and there should be an indication that no MBMS content needs to be delivered to the SRNC.
If the necessary information is not provided over the Iur, it could be directly requested by the RNC from the CN via new Iu signaling.
In
At this point, the decision of using dedicated or common resources is not necessarily made yet. In the MULTICAST ATTACH REQUEST 120 message, the SRNC will both relay information related to RAB establishment coming from the core network and information similar to what typically is included in a Radio Link Setup/Addition Request message in case dedicated resources are to be established for this UE. The SRNC is not yet aware if this is going to happen, since it is a DRNC decision. It could also be possible to include in this message a flag where the SRNC indicates its willingness to move the UE to common resources when the DRNC becomes aware that a common resource is more appropriate for this MBMS session.
Once the DRNC receives this information, it can decide what measures to take. A successful outcome message is then sent back from the DRNC (22A in
In another embodiment of the RNSAP according to the present invention, the attach response message always comprise information reflecting the current resource situation, i.e. information about the common resource is included in the response message if a common resource presently is used, and information about a dedicated resource is included if dedicated resources presently are used. Any decision about whether the addition of the new UE will change the earlier communication preferences may then be taken afterwards and a change will then be initiated for all UEs participating in the multicast group, including the new UE.
If the procedure of adding the new UE to the MBMS session was not successful, the DRNC preferably creates a MULTICAST ATTACH FAILURE message and delivers it to the SRNC. Relevant information such as cause values etc. are then preferably included.
In order to enable the SRNC to remove the UE from the session, a corresponding multicast detach procedure can be used. A MULTICAST DETACH REQUEST message 130 is sent from the SRNC to the DRNC. This signaling is initiated when a user indicates that he wants to leave an ongoing MBMS session. The detach request preferably contains the cell ID of the used multicast cell, the MBMS service ID and the U-RNTI of the UE. The DRNC performs the necessary releases of resources and returns a MULTICAST DETACH RESPONSE message 132 confirming the end of the MBMS for that particular user.
A detach request from a UE may in analogy with the attach situation change the favorable resource utilization for the multicast group. If a common resource was used, the detach of a UE may make a transition into dedicated resources more favorable. There are preferably some RNSAP procedures provided, supporting a change forth and back between common resources and dedicated resources, i.e. channel switching procedures.
When channel switching from dedicated to common resources is to be performed, e.g. upon the entry of an additional UE, the CRNC for the cell in which the multicast group is present can initiate a change. The UEs to which the CRNC is a SRNC are easy to control since the CRNC has all information available. However, for UEs having the CRNC as a DRNC, RNSAP procedures are preferably utilized. The DRNC can then indicate, preferably knowing that the UE can be moved to common resources, the need for a switch. This is sent to the SRNC in an appropriate MBMS INFORMATION TRANSFER INDICATION message 140. Such a message 140 could also be used to relay other MBMS related control information needed at the SRNC. The message 140 comprises the information that a switch to point-to-multipoint transmission is performed, and necessary information about the common resource and the Iu user plane. When the SRNC receives such a message, it performs all changes necessary. For instance, it is preferred if the SRNC releases the Iu user plane corresponding to the dedicated resource previously used. Preferably, the SRNC also returns a response message 142 for confirming that the necessary changes has been performed.
If a MBMS multicast group uses a common resource and the number of members is reduced so that a use of dedicated resources would be favorable, a similar RNSAP signaling can be performed. A MBMS INFORMATION TRANSFER INDICATION message 140 is again transferred from the DRNC to the SRNC. Now the message contains information that a switch to point-to-point transmission is going to take place. Necessary information about dedicated resources to be used is enclosed. The SRNC performs actions necessary to enable such a MBMS session, e.g. allocates necessary Iu and fur user planes. Preferably, the SRNC also returns a response message 142 for confirming that the necessary changes has been performed.
As anyone skilled in the art understands, the actual names of the messages are not essential for the invention. It is rather the function and content of messages that are important. Similarly, the messages can be configured in different ways. A MULTICAST ATTACH REQUEST can e.g. be divided into more than one actual message. A first message may e.g. contain the MBMS service ID and the actual request and a following message can comprise the remaining information necessary. The information content of such messages could even be transferred by means of extensions of already existing messages.
In a similar manner, more specified messages can be used instead of a general message comprising specifying data. For instance, the MBMS INFORMATION TRANSFER INDICATION message 140 could be exchanged for a MBMS p-t-m TRANSMISSION INITIATION message and a MBMS p-t-p TRANSMISSION INITIATION message, respectively, that are uniquely referring to one respective of the two possible transmission change directions. The response message 142 can in a similar manner be a MBMS p-t-m TRANSMISSION INITIATION RESPONSE message and a MBMS p-t-p TRANSMISSION INITIATION RESPONSE message, respectively.
If several UEs are controlled by a SRNC different from the CRNC of the multicast cell, MBMS information transfer indications have to be transferred regarding all UEs. The possibility of performing the multicast attach and MBMS information transfer per pools of UEs controlled by the same SRNC to reduce signaling over Iur is a possible and preferable option.
In the above embodiment of
When deciding to go to common resources, different schemes can be used. The most straightforward is to always let the user plane go directly on the Iu interface between the SGSN 12 and the CRNC 22A, which has been described above. However, if no UEs having the CRNC 22A as a SRNC participates in the multicasting group 60, all control planes will be separated from the user plane. It may then be interesting to set up the user plane over the Iur interface instead. When more UEs are joining, such a configuration may be kept even if the new UEs have the CRNC 22A as their SRNC, in order to reduce the signaling upon changing user plane.
Anyone skilled in the art realizes that there might be several different approaches in selecting the path of the user plane. The most probable is to always select the user plane over the direct Iu interface. One may, however, instead select the user plane according to the control plane of the first UE joining the multicast group 60. One may also determine to keep the user plane regardless of the mobility of the UEs, or one may intermittently update to the most favorable user plane path. All such variations are intended to be understood from the enclosed claims.
In
In the above embodiments, the actual configuration of the radio air interface between the Node B and the UE has only been mentioned in general terms. Common or dedicated radio channels can be selected according to prior-art methods and devices, when appropriate. If the Iur interface is used for control channels, but not for the data, a common channel over the air interface has to be used. If a common data channel over Iu is used, either a common or dedicated data channels can be used over the air interface.
In the embodiments above, a multicasting service is assumed. However, broadcasting procedures of MBMS use similar principles and applicable parts of the invention can thus be used also for broadcasting services.
It will be understood by those skilled in the art that various modifications and changes may be made to the present invention without departure from the scope thereof, which is defined by the appended claims. In particular, different part embodiments of different embodiments shown above may freely be combined without falling outside the scope of the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0201949-5 | Jun 2002 | SE | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SE03/01066 | 6/19/2003 | WO | 6/3/2005 |
