Patent Application
20060156370
The present invention relates generally to telecommunication systems. In particular the invention concerns broadcast and multicast services in wireless systems such as mobile networks.
The terms “broadcast” and “multicast” refer to methods for transmitting data from a single sender to several recipients. In broadcast services basically all users connected to the system can in principle, if equipped with a terminal providing sufficient capabilities, receive the data if they have enabled the service reception on their UE (User Equipment) and are located in service range. In multicast services only the users who have subscribed to a certain multicast group can receive the data associated with said group.
Traditionally aforesaid point-to-multipoint services in fixed networks, e.g. multicast services on the Internet, have provided only minor benefits what comes to the resource saving aspects related to the amount of transferred data. Now, the advent of modern mobile networks has introduced considerable advantages for resource sharing resulting also better overall efficiency because the subscribers of a certain service can receive the same data on a common channel thus saving both network and radio resources such as time slots, carrier frequencies or hopping sequences. One essential difference between fixed and mobile networks is admittedly that efficient bandwidth usage is much more critical factor in mobile networks as radio frequencies seem to be the scarce resource, and transmission capacity of fixed networks can be increased more painlessly after all.
3GPP (3rd Generation Partnership Project) has recently published a specification for the 3GPP system comprising either UTRAN (UMTS Terrestrial Radio Access Network) or GERAN (GSM/EDGE Radio Access Network) as a radio access network. The specification defines a new broadcast/multicast service titled MBMS (Multimedia Broadcast/Multicast Service) [1].
MBMS basic architecture is illustrated in
The SGSN (Serving GPRS Support Node) 120 executes user individual service control functions, concentrates individual users of the same MBMS service into a single MBMS service and maintains a single connection with the source of the MBMS data. The GGSN (Gateway GPRS Support Node) 122 terminates the MBMS GTP (GPRS Tunneling Protocol) tunnels from the SGSN and links these tunnels via IP (Internet Protocol) multicast with the MBMS data source. The BM-SC (Broadcast/Multicast Service Center) 110 is a MBMS data source. MBMS data may be scheduled in the BM-SC 110 to be e.g. transmitted to the user every hour. It offers interfaces which can be utilized by the content provider 114 in requesting data delivery to users. The BM-SC 110 may authorise and charge content provider 114. The Gmb reference point between BM-SC 110 and GGSN 122 enables the BM-SC 110 to exchange MBMS service control information with the GGSN 122. The Gmb reference point exists in order to carry the MBMS Service information but it may not always be necessary to use the Gmb for each service. MBMS service can be delivered to user equipment (UE) 116, 128 such as a mobile terminal over GERAN 130 or UTRAN 118. The SGSN authenticates users and authorises the usage of services based on subscription data from HLR 106.
The architecture also accepts other MBMS broadcast/multicast data sources and internal data sources 104 may directly provide their data. Data delivery by external sources 126 is controlled by Border Gateways (BG) 124 which may allow for example data from single addresses and ports to pass into the PLMN (Public Land Mobile Network) for delivery by an MBMS service.
The architecture assumes the use of IP multicast at the reference point Gi. The MBMS data source has only one connection to the IP backbone. The reference point from the content provider to the BM-SC 110 is currently not standardized as it might become too complex or too restrictive for service creation. For example, this may be a reference point between the BM-SC 110 and an authoring system, or the authoring functionality may be distributed between both entities. The same architecture provides MBMS broadcast services mainly by using the transport functions. The user specific SGSN functions are not required. Instead each individual broadcast service is configured in the SGSN 120.
The SGSN 120 may use CAMEL (Customised Application for Mobile network Enhanced Logic) to handle pre-paid services, e.g. credit checking for on-line charging. The Cell Broadcast Centre (CBC) 102 may be used to announce MBMS services to the users. The BM-SC 110 may exploit OSA-SCS 112 to interact with third parties. For the terminal split, MBMS shall be able to interoperate with an IP multicast client software on the TE.
MBMS broadcast and multicast service provisions are described in
In MBMS multicast service provision subscription 212 establishes the relationship between the user and the service provider, which allows the user to receive the related MBMS multicast service. Service announcement 214 informs UEs about forthcoming services. Joining (MBMS multicast activation) 216 is the process by which a subscriber becomes a member of a multicast group, i.e. the user indicates to the network that he/she is willing to receive multicast mode data of a specific service. MBMS multicast mode bearer set up 218 establishes the network resources for MBMS data transfer in the multicast area. MBMS notification 220 informs the UEs about forthcoming (and potentially about ongoing) multicast data transfer. During data transfer phase 222 MBMS data is transferred to the UEs. MBMS multicast mode bearer release 224 releases the network resources for MBMS data transfer, e.g. when no more MBMS data has to be transferred. Leaving 226 (MBMS multicast deactivation) is the process by which a subscriber leaves (stops being a member) a multicast group, i.e. the user no longer wants to receive multicast data of a specific service. The phases subscription 212, joining 216 and leaving 226 are performed individually per user. The other phases are performed for a service provision, i.e. for all users associated with the related service.
MBMS service announcement/discovery mechanisms 202, 214 should allow users to request or be informed about the range of MBMS services available. This includes operator specific MBMS services as well as services from content providers outside of the PLMN. Operators/service providers may consider several service discovery mechanisms including standard mechanisms such as SMS, or depending on the capability of the terminal, applications that encourage user interrogation. The method chosen to inform users about MBMS services may have to account for the users location, (e.g. current cell, in the HPLMN or VPLMN). Users who have not already subscribed to a MBMS service should also be able to discover MBMS services. For example SMS-CB (Short Message Service—Cell Broadcast), MBMS Broadcast to advertise MBMS Multicast Service, PUSH mechanisms (WAP, SMS-PP) and Web URL (Universal Resource Locator) can be utilized in service discovery purposes.
More detailed information about MBMS service activation/release models, data transfer, functionalities of network elements, radio interface bearer set-up/release, QoS (Quality of Service), security issues etc. can be found in the references [1] and [2].
Current MBMS specifications don't address UE capability issues in any way. However, for example GSM (Global System for Mobile Communication), GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) terminals vary significantly what comes to their data reception and transmission capabilities. In GSM and GPRS systems mobile terminals have been actually divided into multislot classes that define the number of time slots a mobile belonging to a certain class can utilize in uplink and downlink directions [3]. Another distinctive factor in the near future will be EDGE (Enhanced Data rates for GSM Evolution) capability, essentially the availability of transmission means supporting 8-PSK (Phase Shift Keying) modulation and enhanced layer 2 retransmission mechanism. Accordingly, in WCDMA the low-end terminals may only support relatively low bit rates such as 128 kbit/s e.g. due to insufficient memory or processing power to receive and decode higher bit rate (e.g. 384 kbit/s or HSDPA, High Speed Downlink Packet Access) video applications etc.
When multimedia broadcast or multicast services are provided to a group of UEs like mobile terminals the data allocation must be done in a way that all terminals belonging to the target group can receive the media stream. See
An object of the present invention is to provide a feasible and reliable technique for indicating requirements for broadcast and multicast service reception. The object is achieved with a method and a device which either explicitly or implicitly provide that information to a receiving end a priori, before actual attempts by the receiving end to receive overly demanding or otherwise incompatible transmission. Thereby, most error cases can be avoided and average power consumption reduced, as the terminal does not need to monitor the broadcast blocks it cannot receive.
A method according to the invention for indicating one or more terminal capability requirements for point-to-multipoint MBMS service reception in a wireless system is characterized in that in that said method comprises the step of transmitting a broadcast or multicast message indicating said terminal capability requirements over the air interface to at least one terminal within the service range in order to allow the terminal to determine whether it is capable of receiving the service or not, said requirements being indicated in relation to at least one of the following: time slot configuration, modulation type, bit rate, capability class.
In another aspect of the invention, a method for indicating requirements for point-to-multipoint MBMS service reception in a wireless system to be performed by a terminal operable in said system, is characterized in that said method comprises the step informing the terminal's capabilities in relation to at least one of the following: time slot configuration, modulation type, bit rate, and capability class, to said system in order to enable the system to deduce on the basis of informed data whether the terminal is capable of receiving the service or not.
In a further aspect of the invention, a terminal operable in a wireless system, comprising processing means and memory means for processing and storing instructions and data, is characterized in that said terminal is arranged to receive a message indicating requirements for point-to-multipoint MBMS service reception and arranged to determine on the basis of said requirements whether it is capable of receiving the service or not, the requirements indicated in relation to at least one of the following: time slot configuration, modulation type, bit rate, and capability class.
In a further aspect of the invention, a terminal operable in a wireless system, comprising processing means and memory means for processing and storing instructions and data, is characterized in that it is arranged to inform its capabilities in relation to at least one of the following: time slot configuration, modulation type, bit rate, and capability class, to said system for the examination of fulfilment of point-to-multipoint MBMS service reception requirements.
In a further aspect of the invention, a network element operable in a wireless system, comprising processing means and memory means for processing and storing instructions and data, is characterized in that it is arranged to send a message indicating requirements in relation to at least one of the following: time slot configuration, modulation type, bit rate, and capability class, for point-to-multipoint MBMS service reception to be delivered to at least one wireless terminal within the service range in order to allow said wireless terminal to determine whether it is capable of receiving the service or not.
In a further aspect of the invention, a network element operable in a wireless system, comprising processing means and memory means for processing and storing instructions and data, is characterized in that it is arranged to receive a notification from a terminal in relation to at least one of the following: time slot configuration, modulation type, bit rate, and capability class, and deduce on the basis of said notification whether the terminal is capable of receiving a point-to-multipoint MBMS service or not.
A system according to the invention comprises a network element and at least one wireless terminal operable in said system, and the system is characterized in that said network element comprises means for sending a message indicating requirements for point-to-multipoint MBMS service reception in relation to at least one of the following: time slot configuration, modulation type, bit rate, and capability class, to be delivered to at least said wireless terminal within the service range and said terminal comprises means for receiving said broadcast message indicating requirements for point-to-multipoint service reception and means for determining on the basis of said indication whether it is capable of receiving the service or not.
In one embodiment of the invention a system already comprising CBS (Cell Broadcast Service) is supposed to support more versatile MBMS services as well and notify terminals in-range about the requirements for service reception in conjunction with sending a CBS schedule message disclosing data about MBMS services instead. In practise, the requirements are notified by informing the terminals about an applicable MBMS capability class. Three different capability classes define the minimum capabilities required for receiving available services.
In another embodiment of the invention a mobile terminal capable of receiving point-to-multipoint services informs the system it is connected to about its capabilities such as a maximum number of concurrently receivable downlink time slots for joining a certain MBMS multicast service. The system checks if necessary minimum requirements for the joining/service reception are met and if that is the case, accepts the joining request and if not, rejects it.
The accompanying dependent claims describe some embodiments of the invention.
In the following, the invention is described in more detail by reference to the attached drawings, wherein
Referring to
The procedure of indicating the MBMS service requirements and possibly other data in a schedule message may be repeated whenever needed, for example, cyclically. The temporal placement of service requirement indication in connection with MBMS service activation and RAB set-up can vary as well and above-proposed insertion between activation phases 404 and 410 is only a one possible option. Correspondingly, it is noted that the presented procedure as a whole can be considered as an example for clarifying the industrial applicability of the invention, and also other feasible methods exist e.g. for the MBMS service activation/release as presented in the reference [2].
The CBC 102 is responsible for the management of CBS messages. In UMTS the CBC 102 is integrated to as a node into the core network and in GSM it is an external node. The CBC 102 may be connected to several BSCs/RNCs. The CBC's 102 responsibilities include allocation of serial numbers, broadcast initiation, determination of destination cells, broadcast timing and broadcast repetition timing issues, determination of the cell broadcast channels etc. In GSM within a CBC-BSC interface, a CBS message is uniquely identified by the quartet (Message Identifier, Serial Number, Cell Identifier, Channel Indicator). In UMTS within the CBC-RNC interface, a CBS message is uniquely identified by the triplet (Message Identifier, Serial Number, Cell Identifier). See the references [4], [5] and [6] for further information on the technical realization of CBS.
The steps of requesting the indication 406, 408 can be carried out by sending first an indication request message 501, see
In this particular embodiment all available MBMS services have been divided into three different MBMS capability classes but in practise, the total number of classes can be selected as desired. Field 506 includes the class parameter of the current service under activation. Classes define the minimum capability required to receive the services properly. A possible scenario with three different classes meant especially for GPRS/EDGE capable terminals and GERAN as a radio access network is presented in
For each MBMS service that is broadcast over the air interface the system indicates 409 the class of the service i.e. the minimum capability requirements needed for reception. This indication is broadcast in a schedule message so that the receiving UE like a mobile terminal can in advance decide whether to monitor the blocks disclosing the service-related information. The rest of the time the terminal may stay in a low power consumption mode to save battery.
In CBS the system broadcasts schedule messages 701, see
In this embodiment, a CBS schedule message is exploited as well, but as slightly modified (regarding the field values) it indicates forthcoming, ongoing or both MBMS service transmissions with capability requirements instead of CBS message properties. For example, type 702 and spare 706 fields can be used to mark the message for this MBMS specific purpose. As in the case of the original CBS, schedule message contains as many (new) service descriptions 704 as there are 1-valued bits in the bitmap 702. Optional descriptions may still be used for providing whatever-desired extra information. Regarding MBMS services, in most cases it is not necessary to indicate the service requirements at every turn as what comes to a certain service, the capabilities it requires from the recipient do not probably change very often if at all. Hence, the modified schedule message may be broadcast as a result of changes relating to an activation/release of a new MBMS service, registration/arrival of new terminals in the system/service range, service requirements' change, timing changes etc. or if preferred, on a regular basis as in a normal CBS case. Anyhow, in this example the capability class information is enclosed implicitly as the receiving terminal knows how these MBMS service accouncements are divided in octects based on the capability class division. Therefore, the first two octets of the bitmap 710 provide now information about the upcoming new MBMS services belonging to the first capability class 724 (CL 1). Octets 3 and 4 (messages/services 17-32) are respectively used to indicate class 2 (CL 2) services and octets 5 and 6 (messages/services 33-48) class 3 services (CL3). Thus, the message slot positions 726 (1-48) do not imply the schedule of forthcoming transmissions as in a standard CBS schedule message described in the previous chapter. Message description part 712, 714 still includes IDs 720, 722, but not for occasional message but more like service identification purposes. ID 720, 722 can be e.g. IP multicast address or APN of the corresponding service taken from the indication request 501.
This scheme is simplified and in practise it is possible to give the indication in another way. The capability class can be indicated to terminals explicitly, e.g. by a parameter as 506 in the indication request message 501 by which also slot positions can be exploited for (limited) indication of service scheduling. It is possible to use some other mechanism than the schedule message to indicate the requirements/adequate capability class to the terminal, for example a dedicated message including data about specific or all MBMS services available. Accordingly, the network elements utilized in providing the requirements information for MBMS services do not have to be the ones presented in the examples above as the requirement indication procedure initiator and the following transmission chain components can be varied to better suit different system structures, e.g. depending on the available connections between elements and an availability of elements in general.
To clarify the actual core of the invention even more, a method according to the invention is presented in
In a variant of the embodiment the system informs the terminal about the actual service requirements such as the number of time slots needed for the reception (possibly also modulation: 8PSK, GMSK etc.) without defining any MBMS classes. Naturally this kind of explicit information can be also included in the indication as separate parameters in addition to the explicitly or implicitly defined service class. Recall that with WCDMA terminals and UTRAN radio access network the radio technology differs from the GSM and GERAN case. Thus, the requirements that must be met in order to be able to receive the MBMS service can be different. However, the basic invention works as suggested before, namely that minimum requirements are defined either as classes or explicit requirements (e.g. 128 kbit/s downlink, etc). The same applies for other systems supporting point-to-multipoint transmission like DVB (Digital Video Broadcasting) or WLANs (Wireless LAN).
One detail of the invention is that whenever the service requirements are defined and the system announces them it is also obligated to schedule and transmit the data in a way that the indicated requirements are truly met. For example, if the system has indicated two time slots as a requirement for receiving the service it cannot schedule the data on three time slots.
In the second embodiment of the invention, the overall scenario is much alike the one in the first embodiment. See
This invention has been done especially MBMS in mind. However, it could be applied to other cases as well, e.g. to PUSH services, where the network (whatever radio technology) broadcasts/multicasts any data to several terminals which decide whether to receive it or not. Ultimately, regardless of diverse details all services require some sort of properties from the receiving equipment and if a plurality of services exists in a common system, a need for indicating the service specific requirements arises.
Referring to
Referring to
The scope of the invention is disclosed in the following independent claims. However, utilized messages, network elements, system and service specifications etc. may vary depending on the current scenario, still converging to the basic ideas of the invention. Therefore, the invention is not strictly limited to the embodiments described above.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20021755 | Oct 2002 | FI | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/FI03/00718 | 10/2/2003 | WO | 10/12/2005 |
