4.4.2 Multicast Mode timeline

23.2463GPPArchitecture and functional descriptionMultimedia Broadcast/Multicast Service (MBMS)Release 17TS

4.4.2.1 Period between Service Announcement and Session Start

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

Service Subscription can be done anytime before or after Service announcement.

4.4.2.3 Period between Service Announcement and Joining

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

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

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

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

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.