Content for TS 23.246 Word version: 18.0.0
4.4 MBMS Service Provision
4.4.1 MULTICAST MODE
4.4.1.1 Subscription
4.4.1.2 Service announcement
4.4.1.3 Joining
4.4.1.4 Session Start
4.4.1.5 MBMS notification
4.4.1.6 Data transfer
4.4.1.7 Session Stop
4.4.1.8 Leaving
4.4.2 Multicast Mode timeline
...
...
4.4 MBMS Service Provision p. 12
4.4.1 MULTICAST MODE p. 12
Reception of an MBMS MULTICAST service is enabled by certain procedures that are illustrated in the Figure below.
The phases subscription, joining and leaving are performed individually per user. The other phases are performed for a service, i.e. for all users interested in the related service. The sequence of phases may repeat, e.g. depending on the need to transfer data. Also subscription, joining, leaving, service announcement as well as MBMS notification may run in parallel to other phases.
This is illustrated with the following example of timeline:
4.4.1.1 Subscription p. 14
Establishes the relationship between the user and the service provider, which allows the user to receive the related MBMS multicast service.
Service Subscription is the agreement of a user to receive service(s) offered by the operator. Subscription information is recorded in the BM-SC. Subscription information and other BM-SC functionality may be on separate entities, which is enabled by proxy capability of the Gmb interface.
4.4.1.2 Service announcement p. 14
MBMS user service announcement/discovery mechanisms shall allow users to request or be informed about the range of MBMS user services available. This includes operator specific MBMS user services as well as services from content providers outside of the PLMN. Service announcement is used to distribute to users information about the service, parameters required for service activation (e.g. IP multicast address(es)) and possibly other service related parameters (e.g. service start time).
Operators/service providers may consider several service discovery mechanisms. This could include 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 user services may have to account for the user' s location, (e.g. current cell, in the HPLMN or VPLMN). Users who have not already subscribed to a MBMS user service should also be able to discover MBMS user services.
The following could be considered useful for MBMS user service announcement mechanisms (not exhaustive):
- SMS Cell Broadcast to advertise MBMS Multicast and Broadcast user services;
- MBMS Broadcast mode to advertise MBMS Multicast and Broadcast user Services;
- MBMS Multicast mode to advertise MBMS Multicast user Services;
- PUSH mechanism (WAP, SMS-PP, MMS);
- URL (HTTP, FTP).
4.4.1.3 Joining p. 15
Joining (i.e. MBMS multicast activation by the user) is the process by which a subscriber joins (becomes a member of) a multicast group, i.e. the user indicates to the network that he/she wants to receive Multicast mode data of a specific MBMS bearer service. An MBMS user service may also be carried by more than one MBMS bearer service. In that case the MBMS user service part in the UE initiates the relevant MBMS bearer services to receive the service (see clause 8.2).
4.4.1.4 Session Start p. 15
Session Start is the point at which the BM-SC is ready to send data. This can be identified with the start of a "Multicast session" as defined in TS 22.146. Session Start occurs independently of activation of the service by the user - i.e. a given user may activate the service before or after Session Start. Session Start is the trigger for bearer resource establishment for MBMS data transfer. If an MBMS user service is carried by more than one MBMS bearer service, a Session Start message is sent for each MBMS bearer service. In that case the UE may need to initiate the reception of multiple relevant MBMS bearer services to receive the MBMS user service.
4.4.1.5 MBMS notification p. 15
Informs the UEs about forthcoming (and potentially about ongoing) MBMS multicast data transfer.
4.4.1.6 Data transfer p. 15
It is the phase when MBMS data are transferred to the UEs.
4.4.1.7 Session Stop p. 15
It is the point at which the BM-SC determines that there will be no more data to send for some period of time - this period being long enough to justify removal of bearer resources associated with the session. At Session Stop, the bearer resources are released.
4.4.1.8 Leaving p. 15
Leaving (i.e. MBMS multicast deactivation by the user) is the process by which a subscriber leaves (stops being a member of) a multicast group, i.e. the user no longer wants to receive Multicast mode data of a specific MBMS bearer service.
4.4.2 Multicast Mode timeline p. 15
4.4.2.1 Period between Service Announcement and Session Start p. 15
The service announcement may contain a schedule of Session Start times and may be sent some time before the service is due to start. So, this time period could be hours, days or even weeks.
4.4.2.2 Period between Service Announcement and Service Subscription p. 15
Service Subscription can be done anytime before or after Service announcement.
4.4.2.3 Period between Service Announcement and Joining p. 16
The Joining time is chosen by the user and/or UE possibly in response to a Service Announcement. Users will typically join at the time of their choosing so that the period between announcement and joining may be very long or very short. In order to avoid overload situations being caused by many users attempting to join in a short period of time, the UE shall be able to use parameters sent by the BM-SC in the service announcement to randomise the joining time.
4.4.2.4 Period between Joining and Session Start p. 16
Some MBMS bearer services may be 'always on'. In this case, Joining can take place immediately after Service Announcement and possibly many hours before, or after, Session Start.
In other cases, if a Session Start time is known, Joining may take place immediately before Session Start or after Session Start. For these services, the announcement may contain some indication of a time period which users and UEs should use to choose a time to Join the MBMS bearer service.
4.4.2.5 Period between Session Start and First Data Arrival p. 16
Session Start indicates that the transmission is about to start. The time delay between a Session Start indication and actual data should be long enough for the network actions required at Session Start to take place e.g. provision of service information to the UTRAN, establishment of the bearer plane.
Session Start may be triggered by an explicit notification from the BM-SC. In the case of bearer plane resources which are set-up after the start of session data transmission, the network is not required to buffer the session data and loss of data can be assumed.
4.4.2.6 Period between Session Start and Session Stop p. 16
When the BM-SC knows that there is no more data to be sent for a "long idle period", it should indicate Session Stop to the network, causing the release of bearer resources. However, if this idle period with no data is short, this may not be appropriate as it brings more signalling and processing.
The duration of this "long idle period" is implementation dependent. The order of magnitude should be defined to take into account network constraints (including UTRAN, GERAN, and CN).
If the BM-SC wants to use session repetition identification on the MBMS bearer service level, the BM-SC must stop the MBMS session before starting the next MBMS user service session for that TMGI.
4.4.2.7 Session Update p. 16
Session Update is used to update specific parameters of an ongoing MBMS Multicast session. The SGSN can use the procedure to update the list of RAs where MBMS multicast users are located for an ongoing MBMS Multicast service session.
