SP 030660

Technical Specification Group Services and System Aspects TSGS#22(03)0660
Meeting #22, Maui, Hawaii, USA, 15-18 December 2003
Source: TSG SA WG2

Title: CRs on 23.246 (MBMS Stage 2)
Agenda Item: 7.2.3
The following Change Requests (CRs) have been approved by TSG SA WG2 and are requested to be approved by TSG SA plenary #22.
Note: the source of all these CRs is now S2, even if the name of the originating company(ies) is still reflected on the cover page of all the attached CRs.
Tdoc # Title Spec CR # cat Versio REL WI S2 Clauses affected

n in meeting
S2-034382 Inclusion of GERAN attributes 23.246 001r5 C 6.0.0 6 MBMS S2-36 6.2, 6.3.1
and parameters in MBMS
S2-034315 Inclusion of GERAN 23.246 002r4 C 6.0.0 6 MBMS S2-36 8.1, 8.1.1 (new), 8.1.2 (new)
functionality in MBMS
Notification procedure and
session ID
S2-034316 Inclusion of GERAN 23.246 003r4 C 6.0.0 6 MBMS S2-36 8.2, 8.3, 8.5, 8.14
functionality in MBMS
procedures
S2-034378 Clarification of MBMS UE 23.246 007r4 C 6.0.0 6 MBMS S2-36 6.1
Context plus GERAN
functionality
S2-033969 Apply TMGI for Broadcast 23.246 008r1 C 6.0.0 6 MBMS S2-36 6.4
Service
S2-034312 MBMS point to point 23.246 015r3 B 6.0.0 6 MBMS S2-36 7
repair/charging/decrypt service
S2-033996 Optional provision of duration of 23.246 016r2 B 6.0.0 6 MBMS S2-36 8.3
the session
S2-034379 Corrections for TMGI, linked 23.246 020r2 F 6.0.0 6 MBMS S2-36 8.4
NSAPI and service ID
S2-033995 Removal of superfluous 23.246 021r1 F 6.0.0 6 MBMS S2-36 8.8, 8.9
procedures
S2-034310 Verification of UE bearer 23.246 022r2 B 6.0.0 6 MBMS S2-36 6.2, 8.2
capabilities
S2-033962 Various corrections and 23.246 023r1 F 6.0.0 6 MBMS S2-36 all
clarifications
S2-033998 Clarification on MBMS 23.246 026r2 F 6.0.0 6 MBMS S2-36 8.7
deactivation figure
S2-033997 MBMS Service Request 23.246 027r2 B 6.0.0 6 MBMS S2-36 6.1, new 8.15 and new 8.16
Procedure
S2-033984 Removal of BG from MBMS 23.246 028 F 6.0.0 6 MBMS S2-36 4.2
Architecture Figure
S2-034381 Removal of security information 23.246 030 F 6.0.0 6 MBMS S2-36 2,9
in TS 23.246
3GPP TSG-SA2 Meeting #36 Tdoc !S2-034382
New York, USA, 24th – 28th November 2003
CR-Form-v7
CHANGE REQUEST
! 23.246 CR 001 ! rev ! Current version: !
5 6.0.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the ! symbols.
Proposed change affects: UICC apps! ME X Radio Access Network X Core Network X
Title: ! Inclusion of GERAN attributes and parameters in MBMS
Source: ! Orange
Work item code: ! MBMS Date: ! 25/11/03
Category: ! C Release: ! Rel-6

Use one of the following categories: Use one of the following releases:
F (correction) 2 (GSM Phase 2)
A (corresponds to a correction in an earlier release) R96 (Release 1996)
B (addition of feature), R97 (Release 1997)
C (functional modification of feature) R98 (Release 1998)
D (editorial modification) R99 (Release 1999)
Detailed explanations of the above categories can Rel-4 (Release 4)
be found in 3GPP TR 21.900. Rel-5 (Release 5)
Rel-6 (Release 6)
Reason for change: ! TS 23.246 was approved at SA#21 without reference to GERAN in the multicast
and broadcast in the procedures, however it was stated that these would be
included for approval at SA#22. This CR introduces the appropriate changes.
Summary of change: ! The text on MBMS attributes and parameters is expanded to include reference to
GERAN as well as UTRAN
This also includes general editorial tidy-ups in accordance with CR23
Consequences if ! MBMS procedures will not address GERAN functionality.

not approved:
Clauses affected: ! 6.2, 6.3.1
Y N
Other specs ! X Other core specifications !
affected: X Test specifications
X O&M Specifications
Other comments: !
How to create CRs using this form:

Comprehensive information and tips about how to create CRs can be found at http://www.3gpp.org/specs/CR.htm.
Below is a brief summary:
1) Fill out the above form. The symbols above marked ! contain pop-up help information about the field that they are
closest to.
2) Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word
"revision marks" feature (also known as "track changes") when making the changes. All 3GPP specifications can be
CR page 1
downloaded from the 3GPP server under ftp://ftp.3gpp.org/specs/ For the latest version, look for the directory name
with the latest date e.g. 2001-03 contains the specifications resulting from the March 2001 TSG meetings.
3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front of
the clause containing the first piece of changed text. Delete those parts of the specification which are not relevant to
the change request.
CR page 2
3GPP TS 23.246 v6.0.0 (2003-09)
*******************First Change**********************
6.2 MBMS Bearer Context
The MBMS Bearer Context, which is referred to as MBMS Service Context in RAN, contains all information
describing a particular MBMS bearer of an MBMS service and is created in each node involved in the delivery of the
MBMS data.
An MBMS Bearer Context is created in the SGSN and GGSN when the first MBMS UE Context is created in the node
or when a downstream node requests it. The MBMS Bearer Context is statically configured in the BM-SC; how this is
done is out of the scope of this specification. The MBMS Bearer Context is created in the BSC/SRNC when a first
MBMS UE Context is created in BSC/SRNC. Session Start procedure may create MBMS Bearer Context in an
BSC/RNC which has no MBMS Bearer Context yet. Furthermore, it is FFS whether the state model described below is
applicable as such to the RAN or whether it needs to be extended to cover the case of the RAN properly.
An MBMS Bearer Context, once created, can be in one of two states reflecting the activity bearer plane resource status
of the corresponding MBMS bearer service.
*******************Second Change**********************
6.3.1 MBMS QoS distribution tree
MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many
BSCs/RNCs, and many SGSNs and one or more GGSNs. Furthermore some transport bearer resources may be shared
between many users accessing the same MBMS bearer service in order to save resources. As a result, each branch of a
MBMS distribution tree shall be established with the same QoS.
MBMS distribution tree shall have the same QoS for all its branches.
When a branch of the MBMS distribution tree has been created, it should is not be possible for construction of another
branch (e.g. due to arrival of a new UE (or change of location of a UE with removal of a branch and addition of a new
one) to impact the QoS of already established branches.
There is no QoS value negotiation between UMTS network elements is not required. This impliesy that some branches
may not be established if QoS requirement cannot be accepted by the concerned network node.
Also in RAN there is no QoS (re-)negotiation feature in for the RNC should not be allowed for MBMS bearer service.
3GPP
CR-Form-v7
CHANGE REQUEST
4 6.0.0
Title: ! Inclusion of GERAN functionality in MBMS Notification procedure and session ID
Source: ! Orange

Rel-6 (Release 6)
included for approval at SA#22. This CR introduces the appropriate changes.
Change “service Id” in 8.1 to “session identifier”.
Summary of change: ! This change describes the notification procedure for the Gb mode of
GERAN.Change of Service Id to session identifier
This also includes general editorial tidy-ups in accordance with CR23.
Consequences if ! MBMS Notification procedures will not address GERAN functionality.

not approved:
Clauses affected: ! 8.1, 8.1.1 (new), 8.1.2 (new)
Y N
Other comments: !

closest to.
CR page 1
the change request.
CR page 2
3GPP TS 23.246 v6.0.0 (2003-09)
8.1 MBMS Notification

8.1.1 Iu mode notification (UTRAN and GERAN)
When an MBMS Session starts, UEs interested in the MBMS bearer service (PMM-CONNECTED UEs and PMM-
IDLE UEs) shall be notified.
MBMS Session attributes such as Service Session Identifier and the Multicast MBMS service Area are made available
in all interested RNCs during the Session Start procedure. Other parameters are FFS.
For radio efficiency reasons, the UTRAN may select on per cell basis whether to establish point-to-point or point-to-
multipoint links for the distribution of MBMS data to the UEs.
In order to perform this selection, the UTRAN requests UEs to move to PMM-CONNECTED / RRC-CONNECTED
state by means of MBMS group notification sent in the Multicast MBMS service Area.
The fact that this group MBMS notification moves the UEs back to PMM-CONNECTED or to RRC-CONNECTED
state is FFS, subject to RAN decision.
The exact number of UEs moved to PMM-CONNECTED / RRC-CONNECTED state is a decision of RAN node. It is
not necessary for all UEs to move to PMM-CONNECTED/ RRC_CONNECTED in order for the RAN to decide to use
point-to-multipoint, other UEs may remain in IDLE state. This is a UTRAN choice (based on RRM criteria…), FFS in
RAN group.
Following the decision to set up point-to-point or point-to-multipoint links, the number of UEs that need to be
maintained in CONNECTED state or moved to IDLE state for MBMS data reception is also an decision of a RAN
node.
GERAN functionality is FFS.
8.1.2 A/Gb mode notification (GERAN)

When an MBMS Session starts, UEs interested in the MBMS bearer service (READY UEs and STANDBY) shall be
notified. The MBMS notification triggers detection or counting of UEs per cell for selection of the most appropriate
MBMS radio bearer.
MBMS Session attributes such as Session Identifier, MBMS Service Area, QoS are made available in all interested
BSCs that are connected to a registered SGSN by the Session Start procedure.
3GPP
CR-Form-v7
CHANGE REQUEST
4 6.0.0
Title: ! Inclusion of GERAN functionality in MBMS procedures
Source: ! Orange

Rel-6 (Release 6)
included for approval at SA#22. This CR introduces the appropriate changes/
Summary of change: ! The MBMS procedures and message flow charts are extended to reference BSC
as well as RNC, A/Gb mode as well as Iu mode and GERAN as well as UTRAN
This also includes general editorial tidy-ups in accordance with CR23
Consequences if ! MBMS procedures will not address GERAN functionality.

not approved:
Clauses affected: ! 8.2, 8.3, 8.5, 8.14
Y N
Other comments: !

closest to.
CR page 1
the change request.
CR page 2
3GPP TS 23.246 v6.0.0 (2003-09)
*******************First Change**********************
8.2 MBMS Multicast Service Activation
The MBMS multicast service activation procedure registers the user in the network to enable the reception of data from
a specific MBMS multicast MBMS bearer service. The activation is a signalling procedure between the UE and the
network. The procedure establishes MBMS UE contexts in UE, SGSN and GGSN and BSC/RNC for each activated
MBMS multicast MBMS bearer service comparable to regular PDP contexts.
*******************Second Change**********************
8.3 MBMS Session Start Procedure
The BM-SC initiates the MBMS Session Start procedure when it is ready to send data. This is a request to activate all
necessary bearer resources in the network for the transfer of MBMS data and to notify interested UEs of the imminent
start of the transmission.
Through this procedure, MBMS session attributes such as QoS, Multicast MBMS service Area (tracking/non-tracking
area are FFS) are provided to the GGSN(s) and SGSN(s) that have previously registered for the corresponding MBMS
bearer service and to all BSCs/RNCs that are connected to a registered SGSN. In addition the procedure allocates the
bearer plane to all registered GGSNs and all registered SGSNs and to BSCs/RNCs that respond to the session start
accordingly.
The overall Session Start procedure is presented in the following figure:
3GPP
3GPP TS 23.246 v6.0.0 (2003-09)
UE RNC SGSN GGSN BM-SC
1. Session Start Request
1. Session Start Response

2. MBMS Session Start Request
2. MBMS Session Start Response
4. RAN Resource Setup
UE BSC/RNC SGSN GGSN BM-SC

Figure 8 Session Start procedure
1. The BM-SC sends a Session Start Request message to indicate the impending start of the transmission and to
provide the session attributes (QoS, Multicast MBMS service Area…) to the GGSNs listed in the “list of
downstream nodes” parameter of the corresponding MBMS Bearer Context. The BM-SC sets the state attribute
of its MBMS Bearer Context to ‘Active’. The GGSN stores the session attributes in the MBMS Bearer Context,
sets the state attribute of its MBMS Bearer Context to ‘Active’ and sends a Session Start Response message to
the BM-SC..
2. The GGSN sends an MBMS Session Start Request message to the SGSNs listed in the “list of downstream
nodes” parameter of the corresponding MBMS Bearer Context. The SGSN stores the session attributes in the
MBMS Bearer Context, sets the state attribute of its MBMS Bearer Context to ‘Active’ and responds with an
MBMS Session Start Response message providing the TEID for bearer plane that the GGSN shall use for
forwarding the MBMS data.
3. The SGSN sends an MBMS Session Start Request message including the session attributes to each BSC/RNC
that is connected to this SGSN. The BSC/RNC responds with an MBMS Session Start Response to the SGSN. If
the BSC/RNC serves the MBMS Service Area it stores the session attributes in the MBMS Service Context, sets
the state attribute of its MBMS Service Context to ‘Active’ and responds with an MBMS Session Start Response
message and the RNC includes the TEID in the MBMS Session Start Response message for the Iu bearer plane
that the SGSN shall use for forwarding the MBMS data. An RNC receiving multiple MBMS Session Start
Request messages includes Iu bearer plane parameters only into one MBMS Session Start Response message to
establish only one Iu bearer plane to one SGSN.
4. The BSC/RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs.
3GPP
3GPP TS 23.246 v6.0.0 (2003-09)
Note: The upstream node normally provides the MBMS Session Start Request message once per MBMS
session to a downstream node. Due to “Intra Domain Connection of RAN Nodes to Multiple Core
Network Nodes” however, an RNC may receive the MBMS Session Start Request message from several
SGSNs.
*******************Third Change**********************
8.5 MBMS Session Stop Procedure
The BM-SC initiates the MBMS Session Stop procedure when it considers the MBMS session to be terminated. The
session is typically terminated when there is no more MBMS data expected to be transmitted for a sufficiently long
period of time to justify a release of user bearer plane resources in the network. The procedure is propagated to all
SGSNs and GGSNs that are registered for the corresponding MBMS bearer service and to BSCs/RNCs that have an
established Iu bearer plane with an SGSN..
The overall MBMS Session Stop procedure is presented in the following figure:
1. Session Stop Request
1. Session Stop Response

2. MBMS Session Stop Request
2. MBMS Session Stop Response
4. RAN Resource Release

Figure 10 MBMS Session Stop procedure
3GPP
3GPP TS 23.246 v6.0.0 (2003-09)
1. The BM-SC sends a Session Stop Request message to all GGSNs listed in the “list of downstream nodes”
parameter of the affected MBMS Bearer Context to indicate that the MBMS session is terminated and the bearer
plane resources can be released. The BM-SC sets the state attribute of its MBMS Bearer Context to ‘Standby’.
2. The GGSN sends an MBMS Session Stop Request message to all SGSNs listed in the “list of downstream
nodes” parameter of the affected MBMS Bearer Context, releases the corresponding bearer plane resources
towards these SGSNs and sets the state attribute of its MBMS Bearer Context to ‘Standby’.
3. The SGSN releases the TEID and bearer plane resources on which it was receiving MBMS data from the GGSN
for the affected MBMS bearer service and sends an MBMS Session Stop Request message to all BSCs/RNCs
that have a bearer plane established with the SGSN.
4. The RNC releases the affected radio and Iu resources; the BSC releases the affected radio resources.
*******************Fourth Change**********************
8.14 MBMS Broadcast Session Start Procedure
necessary bearer resources in the network for the transfer of MBMS data. It is FFS whether it is also used to notify
interested UEs of the start of the transmission.
Through this procedure, MBMS session attributes such as QoS, Broadcast MBMS service Area (tracking/non-tracking
area are FFS) are provided to all the GGSN(s), SGSN(s) and BSCs/RNCs. In addition the procedure allocates the bearer
plane to all GGSNs and all SGSNs and to BSCs/RNCs that respond to the MBMS session start accordingly.
The overall MBMS Broadcast Session Start procedure is presented in the following figure:
1. Session Start Response.

2. MBMS Session Start Response.

3GPP
3GPP TS 23.246 v6.0.0 (2003-09)


Figure 16 Session Start procedure for MBMS Broadcast MBMS Bearer Service
1) The BM-SC sends a Session Start Request message the impending start of the transmission and to provide
the MBMS session attributes (QoS, Broadcast MBMS service Area…) to a GGSNs GGSN of the PLMN.
The BM-SC sets the state attribute of its MBMS Bearer Context to ‘Active’. The GGSN creates a MBMS
Bearer Context, stores the session attributes, sets the state attribute of this MBMS Bearer Context to ‘Active’
and sends a Session Start Response message to the BM-SC.
2) The GGSN sends an MBMS Session Start Request message to all its SGSNs. The SGSN creates a MBMS
Bearer Context, stores the session attributes, sets the state attribute of this MBMS Bearer Context to ‘Active’
and responds with an MBMS Session Start Response message providing the TEID for bearer plane that the
GGSN shall use for forwarding the MBMS data.
3) The SGSN sends an MBMS Session Start Request message including the session attributes to each
BSC/RNCs that is connected to this SGSN. The BSC/RNC responds with an MBMS Session Start Response
message to the SGSN. If the BSC/RNC serves the MBMS Broadcast service Area, it creates a MBMS Bearer
Context, stores the session attributes in this MBMS Service Context, sets the state attribute of its MBMS
Service Context to ‘Active’ and responds with an MBMS Session Start Response message, and the RNC
includes the TEID in the MBMS Session Start Response message for the Iu bearer plane that the SGSN shall
use for forwarding the MBMS data. An RNC receiving multiple MBMS Session Start Request messages
from different SGSNs includes Iu bearer plane parameters only into one MBMS Session Start Response
message to establish only one Iu bearer plane to one SGSN.
4) The BSC/RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs.
Note: The upstream node normally provides the MBMS Session Start Request message once per MBMS
session to a downstream node. Due to “Intra Domain Connection of RAN Nodes to Multiple Core
Network Nodes” however, an RNC may receive the MBMS Session Start Request message from several
SGSNs.
3GPP
3GPP TSG-SA WG2#36 Tdoc !S2-034378
New York, USA, 24-28 November 2003 Revised S2-0334309
CR-Form-v7
CHANGE REQUEST
4 6.0.0
Title: ! Clarification of MBMS UE Context plus GERAN functionality
Source: ! Siemens, Huawei, Orange

Rel-6 (Release 6)
Reason for change: ! There is no need to store the linked NSAPI in any GGSN. Because of this, the
GGSN can not use the linked NSAPI. The linked NSAPI should be deleted from
MBMS UE context in GGSN.
In TS 23.246 v6.0.0, subclause 6.1 states “In the UE, SGSN and GGSN, the
MBMS UE Context is stored as part of the MM Context for the UE.” But, as
described in section 13 of TS 23.060 v6.2.0, the MM Context exists in the UE
and SGSN, but not in the GGSN. So, we can not store the MBMS UE Context as
part of the MM Context in the GGSN. Consequently, in the GGSN, the MBMS UE
Context should be stored separately and it needs a self indication.
The CR also adds GERAN functionality to the MBMS UE Context.
Summary of change: ! Removal of TMGI from MBMS UE context. Clarification that the MBMS UE
Context should be stored separately and needs IMSI as its self indication in the
GGSN. Addition of GERAN functionality to the MBMS UE Context.
Consequences if ! Redundant information in MBMS UE and bearer contexts. There is an incorrect

not approved: description of how the MBMS UE Context is stored in the GGSN, and it is
unclear how the GGSN differentiates between multiple MBMS UE Contexts.
There is no inclusion of GERAN for the MBMS UE Context.
Clauses affected: ! 6.1
Y N
CR page 1
Other comments: ! Changes for subclause 6.1 from S2-033959 (CR 20), S2-033980 (CR 7), S2-
033973 (CR 1).

closest to.
the change request.
CR page 2
3GPP TS aa.bbb vX.Y.Z (YYYY-MM) CR page 3
6.1 MBMS UE Context

The MBMS UE Context contains UE-specific information related to a particular MBMS bearer that the UE has joined.
An MBMS UE Context is created in the UE, SGSN and GGSN when the UE joins an MBMS bearer. In the SGSN, an
MBMS UE Context is also created as a result of an inter-SGSN routing area update after the transfer of the MBMS UE
Context from the old SGSN. It is FFS whether MBMS UE Contexts are created in the BM-SC.
All MBMS UE Contexts of a UE (referenced as “UE Link” in RNC) are provided via UE dedicated Iu procedure(s) to
the SRNC when the first PS RAB is established for the UE, or when the UE performs MBMS Multicast Service
Activation. MBMS UE Contexts are provided to the SRNC regardless whether MBMS Sessions are ongoing or not (i.e.
before, between and after Sessions).
The existence of the MBMS UE context for Gb mode in the BSC is for further study.
In the UE, and SGSN and GGSN, the MBMS UE Context is stored as part of the MM Context for the UE. The MBMS
UE Context is stored in the GGSN. There is one MBMS UE Context per MBMS bearer service that the UE has joined.
In the BSC/RNC, the MBMS UE Contexts are stored as part of the UE Context of the BSC/RNC.
The content of the MBMS UE Context is described in Table 1.
Table 1: MBMS UE Context
Parameter Description UE SGSN GGSN RNC BSC BM-SC

IP multicast address IP multicast address identifying an X X X X Iu - X
MBMS bearer that the UE has joined. Gb - FFS
APN Access Point Name on which this IP X X X X Iu - X
multicast address is defined. Gb - FFS
TMGI Temporary Mobile Group Identity X X FFS X FFS
allocated to the MBMS bearer.
Linked NSAPI NSAPI of the PDP context used by X X X
the UE to carry IGMP/MLD signalling.
IMSI IMSI identifying the user. (1) (1) X (2) FFS
FFS FFS
(1) In the UE and SGSN, the IMSI is available within the MM Context which contains the MBMS UE Context
(2) In the RNC, the IMSI is available within the UE Context which contains the MBMS UE Context.
CR page 3
3GPP TSG-SA WG2 Meeting #36 Tdoc !S2-033969
NYC, USA, November 24 – 28, 2003
CR-Form-v7
CHANGE REQUEST
1 6.0.0
Title: ! Apply TMGI for Broadcast Service
Source: ! Motorola
Category: ! C Release: ! REL-6

Rel-6 (Release 6)
Reason for change: ! TS 23.246 defines TMGI to be unique within a HPLMN for Multicast service, it
hasn’t define TMGI for Broadcast service. “Temporary Mobile Group Identity
(TMGI) is used for group notification purpose. The BM-SC will allocate a TMGI
per service that is unique within HPLMN. For Multicast Service the TMGI will be
transmitted to UE via service activation procedure.” To minimize system
modification, it is beneficial to reuse the same design principles for Multicast
Service in Broadcast Service. Therefore, correction is needed.
Summary of change: ! This paper proposes texts to support broadcast service to section 6.4 Temporary
Mobile Group Identity.
Consequences if ! Different procedures for Multicast Service and Broadcast Service.

not approved:
Y N
Other comments: !

closest to.
CR page 1
the change request.
CR page 2
3GPP TS 23.246 v6.0.0 (2003-09) CR page 3
6.4 Temporary Mobile Group Identity

Temporary Mobile Group Identity (TMGI) is used for group notification purpose. The BM-SC will allocate a TMGI per
service that is unique within HPLMN. For Multicast Service the TMGI will be transmitted to UE via service activation
procedure. For Broadcast Service the TMGI can be obtained via service announcement see “ Service Announcement”.
CR page 3
New York, USA, 24th – 28th October 2003 rev of S2-033994
CR-Form-v7
CHANGE REQUEST
3 6.0.0
Title: ! MBMS point to point repair/charging/decrypt service
Source: ! Vodafone UK
Category: ! B Release: ! Rel-6

Rel-6 (Release 6)
Reason for change: ! For the MBMS “file download” service, there are several use cases where it is
beneficial for the mobile to contact a network server after the download is
complete, eg, to permit errors in the file to be corrected; to permit the network to
accurately charge; to pass a decrypt key to the mobile; etc. Some of this
functionality might also be useful for streaming services.
When using these services, care is needed to ensure that the uplink traffic does
not overload the network (radio, RNC, BSC, SGSN, GGSN and especially
BMSC). One way for this load to be distributed is for the BMSC to allocate the
address of (one of many) repair servers to the mobile at activation time, along
with parameters that are used to generate a random time dispersion of the uplink
traffic.
Summary of change: ! The concept of point to point repair, etc is added to 23.246.
Consequences if ! Congested radio resources and overloaded network elements.

not approved:
Clauses affected: ! 7
Y N
Other specs ! X Other core specifications ! GERAN/UTRAN stage 3’s and SA 4’s
User Service.
Affected: X Test specifications
CR page 1
Other comments: ! 2-

closest to.
3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification
just in front of the clause containing the first piece of changed text. Delete those parts of the specification
which are not relevant to the change requ
CR page 2
7 Architectural Aspects of MBMS User Services
7.1 Application Adjunct Entity

For the MBMS “file download” service, there are several use cases where it may be beneficial for the UE to contact a
network entity (the Application Adjunct Entity (AAE)) after the download is complete in order, eg, to permit errors in
the file to be corrected; to permit the network to charge for a successful download; to pass a decrypt key to the UE; etc.
The AAE is logically part of the BM-SC.
Note: use of the AAE might also be beneficial for some MBMS Streaming services.
Care is needed to ensure that the uplink traffic does not overload the network (radio, RNC, BSC, SGSN, GGSN and
BM-SC). One way for this load to be distributed is for the BM-SC to allocate the address of (one of many) AAEs to the
UE at activation time, along with parameter(s) that are used to generate a random time dispersion of the uplink traffic.
3GPP
3GPP TSG-SA2 Meeting #36 S2-033996
New York, 24-28 November, 2003 revision of S2-033982
CR-Form-v7
CHANGE REQUEST
2 6.0.0
Proposed change affects: UICC apps! ME Radio Access Network X Core Network X
Title: ! Optional provision of duration of the session
Source: ! Nortel Networks

Rel-6 (Release 6)
Reason for change: ! In LS S2-033327 (R3-031240) RAN3 informs that there would be interest for
RNCs to know what would be the duration of a session. The BM-SC could
optionally provide the estimated duration of the data transfer of a session.
Summary of change: ! Update MBMS TS 23.246 to indicate this optionnal sending.
Consequences if ! If this is not done, some radio architecture optimization cannot be done.
not approved:
Y N
Other comments: ! .

closest to.
CR page 1
the change request.
CR page 2
Through this procedure, MBMS session attributes such as QoS, MBMS serviceMulticast Area (tracking/non-tracking
area are FFS), estimated session duration if available are provided to the GGSN(s) and SGSN(s) that have previously
registered for the corresponding MBMS bearer service and to all RNCs that are connected to a registered SGSN. In
addition the procedure allocates the bearer plane to all registered GGSNs and all registered SGSNs and to RNCs that
respond to the session start accordingly.

Figure 8: Session Start procedure
provide the session attributes (QoS, Multicast MBMS service Area, estimated session duration…) to the GGSNs
listed in the "list of downstream nodes" parameter of the corresponding MBMS Bearer Context. The BM-SC sets
the state attribute of its MBMS Bearer Context to 'Active'. The GGSN stores the session attributes in the MBMS
Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active' and sends a Session Start
Response message to the BM-SC.
CR page 3
CR-Form-v7
CHANGE REQUEST
2 6.0.0
Title: ! Corrections for TMGI, linked NSAPI and service ID
Source: ! Siemens
Category: ! F Release: ! Rel-6

Rel-6 (Release 6)
Reason for change: ! TS version 6.0.0 describes the TMGI as part of the MBMS UE context and as part of the
MBMS bearer context in almost every network entity. The TMGI is defined for the
MBMS bearer service and not per UE. Therefore in network entities it should be only part
of the MBMS bearer context to avoid redundant information. It has to remain part of the
MBMS UE context in the UE, as the UE has no MBMS bearer context.
The rudimentary registration procedure that is embedded into the activation procedure
transfers already the TMGI. But this information element is not transferred by the
registration procedure. It needs to be added.
There is no need to store the linked NSAPI in any GGSN. It should be noted that two
GGSNs may be involved in the MBMS activation procedure. Because of this the GGSN
can not use the linked NSAPI. The SGSN can manage any potential error handling. Linked
NSAPI should be deleted from MBMS UE context in GGSN.
Change “service Id” in 8.1 to “MBMS session identifier” introduced last meeting.
Summary of change: ! Removal of TMGI from MBMS UE context. Addition of TMGI element to registration
procedure. Clarifications for linked NSAPI and service ID.
Consequences if ! Redundant information in MBMS UE and bearer contexts. Missing signalling elements.
not approved:
Y N
CR page 1
Other comments: ! The changes for 6.1 and 8.1 are merged into CR#2 and CR#7 respectively
because of overlap. This CR takes into account changes on 8.4 from CR#21and
22.

1) Fill out the above form. The symbols above marked ! contain pop-up help information about the field that they
are closest to.
3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in
front of the clause containing the first piece of changed text. Delete those parts of the specification which are not
relevant to the change request.
CR page 2
8.4 MBMS Registration Procedure

The MBMS Registration is the procedure by which a downstream node informs an upstream node that it would like to
receive session attributes and data for a particular MBMS bearer service in order to distribute it further downstream.
This procedure builds up a distribution tree for the delivery of MBMS session attributes and data from the BM-SC to
the UEs interested in the service. This procedure results in the set-up of a corresponding MBMS Bearer Context in the
nodes along the distribution tree, but it does not result in the establishment of userbearer plane which will be established
by the Session Start procedure.
The MBMS Registration procedure is initiated:
- When the first MBMS UE Context for a particular MBMS bearer service is created in the SGSN or GGSN (see
subclause "MBMS UE Context") and the corresponding MBMS Bearer Context is not already established in the
node;
- When an MBMS Registration Request for a particular MBMS Service bearer service is received from a
downstream node but the corresponding MBMS Bearer Context is not established in the node; or
- When a DRNC detects that it hosts UEs interested in the MBMS bearer service (see subclause "RAN Resource
Setup).
NOTE: The terms 'downstream' and 'upstream' refer to the topological position of one node with respect to
another and relative to the direction of the MBMS data flow, i.e. from BM-SC to UE.
RNC SGSN GGSN BM-SC
1. MBMS Registration Request

4. MBMS Registration Response
4. MBMS Session Start Procedure


Figure 9: MBMS Registration procedure
1. When the DRNC detects that it hosts UEs interested in the MBMS Servicebearer service, the DRNC sends a
MBMS Registration Request message to its parent SGSN if not already done (see subclause "RAN Resource
Setup"). How the RNC determines its parent SGSN is a matter of implementation.
2. If the SGSN has no MBMS Bearer Context for an MBMS Servicebearer service and the SGSN receives an
MBMS Registration Request from an RNC for this MBMS bearer service, or if the first MBMS UE Context is
created in the SGSN for an MBMS Servicebearer service for which the SGSN has no corresponding MBMS
Bearer Context, the SGSN creates an MBMS Bearer Context (in "Standby" state) and sends an MBMS
Registration request (IP multicast address, APN,) message to the GGSN. How the SGSN selects a GGSN is a
matter of implementation; it may for instance be based on prior signalling related to a particular UE or via APN
resolution.
3. If the GGSN has no MBMS Bearer Context for an MBMS bearer service and the GGSN receives an MBMS
Registration from an SGSN for this MBMS bearer service, or when the first MBMS UE Context is created in the
GGSN for an MBMS bearer service for which the GGSN has no MBMS Bearer Context, the GGSN sends a
Registration Request (IP multicast address, APN) message to the BM-SC. The exact nature of the signalling
between GGSN and BM-SC is however FFS in general.
CR page 3
4. Upon reception of an MBMS Registration Request from a GGSN, the BM-SC adds the identifier of the GGSN to
the "list of downstream nodes" parameter in its MBMS Bearer Context and responds with a MBMS Registration
Response (TMGI, Required Bearer Capabilities) message. The exact nature of the signalling between GGSN and
BM-SC is however FFS in general. If the MBMS Bearer Context is in the 'Active' state, the BM-SC initiates the
Session Start procedure with the GGSN, as described in Section 8.3.clause “MBMS Session Start Procedure”.
5. If the GGSN receives a Registration Request from the SGSN in step 2, the GGSN:
- adds the identifier of the SGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context,
- responds with an MBMS Registration Response (TMGI, Required Bearer Capabilities) message, and
- if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the SGSN, as
described in Section 8.3.clause “MBMS Session Start Procedure”.
6. If the SGSN received MBMS Registration Request from the DRNC in step 1, the SGSN:
- adds the identifier of the RNC to the "list of downstream nodes" parameter in its MBMS Bearer Context,
- responds with an MBMS Registration Response message, and
- if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the DRNC, as
described in Section 8.3clause “MBMS Session Start Procedure”.
CR page 4
CR-Form-v7
CHANGE REQUEST
1 6.0.0
Title: ! Removal of superfluous procedures
Source: ! Siemens

Rel-6 (Release 6)
Reason for change: ! Currently TR 23.246 establishes Iu bearer with the session start procedure and the Iu
bearer is released with the session stop procedure. There are no mechanisms to add or
remove BSCs/RNCs during MBMS sessions to the disctribution tree, i.e. there is no need
to establish or release Iu bearers by other procedures. An explicit registration for all RNCs
was not accepted some time ago. But a standalone Iu release procedure would require
RNCs to ask during ongoing sessions to be added to the distribution tree. All this results in
additional signalling flows and error cases. The optimisation gain is low. Therefore the
current bearer service model and procedures should not be changed. The Iu bearer is
estblished from session start until session stop. There is no need for an Iu release
procedure. The procedure should be deleted.
Furthermore, RAN resource setup is still FFS but there seems no need for such a
procedure in the stage 2. The chapter and the two references should be deleted.
Summary of change: ! Deletion of Iu release and RAN resources setup procedures.
Consequences if ! A procedure that may remove RNCs from distribution tree. But, no mechanism for the
not approved: RNC to be added to the tree again.
Clauses affected: ! 8.8, 8.9
Y N
CR page 1
Other comments: ! Changes on 8.4 are merged into CR#20.

are closest to.
CR page 2
8.8 Void Iu Bearer Plane release procedure

A RNC triggers the Iu Bearer Plane release procedure if the RNC has no further use for the user plane (i.e. no UEs left
in the coverage area of the RNC or session stop) (hysterisis mechanisms can be used in the RNC to avoid continuous
Bearer plane establishments and releases).
8.9 Void RAN Resource Setup

Editor’s note: The content of this subclause is dependent on ongoing work in RAN groups. The main focus of this
section should be on the externally observable behaviour of the RAN (as seen from the Iu interface) and
aspects that have direct impact on CN procedures. This subclause should in particular describe which of
the SRNC, DRNC or CRNC is responsible for MBMS data distribution depending on whether ptp or ptm
distribution has been selected.]
CR page 3
New York, USA, 24th – 28th October 2003
CR-Form-v7
CHANGE REQUEST
2 6.0.0
Proposed change affects: UICC apps! ME X Radio Access Network Core Network X
Title: ! Verification of UE bearer capabilities
Source: ! Siemens

Rel-6 (Release 6)
Reason for change: ! Currently TS 23.246 does not take into account a verification of UE’s bearer capabilities.
QoS attribute values are obviously not fixed for all MBMS bearer services. And, when
MBMS bearer services are provided with differing QoS values then very likely not every
UE will be able to handle any possible MBMS bearer QoS, e.g. any possible bitrate. As a
result a user might activate MBMS services that the UE can not handle. Probably the user
would be charged for services that can not be used.
It is proposed to verify the UE’s bearer capabilities at MBMS multicast activation. As the
QoS values may change per session it is necessary to verify the UE capabilities with the
upper limit of QoS values used by the MBMS bearer service. The required MBMS bearer
capabilities are defined by the MBMS user service and these capabilities need to be added
to the MBMS bearer context to allow for verification at MBMS activation.
Currently the activation procedure allows accepting an activation before it is authorised by

GGSN/BMSC. As it makes such an authorisation verification obsolete this possibility
should be deleted.
Summary of change: ! Addition of UE MBMS bearer capability verification to MBMS activation procedure.
Consequences if ! The user might activate MBMS services that the UE can not handle.
not approved:
Clauses affected: ! 6.2, 8.2
Y N
CR page 1
Other comments: ! Changes on 8.4 are merged into CR#20.

are closest to.
CR page 2

MBMS data.
done is out of the scope of this specification. The MBMS Bearer Context is created in the SRNC when a first MBMS
UE Context is created in SRNC. Session Start procedure may create MBMS Bearer Context in an RNC which has no
MBMS Bearer Context yet. Furthermore, it is FFS whether the state model described below is applicable as such to the
RAN or whether it needs to be extended to cover the case of the RAN properly.
An MBMS Bearer Context, once created, can be in one of two states reflecting the activitybearer plane resource status
of the corresponding MBMS bearer. service.
No user plane resources required
Standby
Session Start Session Stop
Active
User plane resources required
No bearer plane resources required
Standby
Active
Bearer plane resources required
Figure 6: MBMS Bearer Context State Model
'Active' reflects the state of an MBMS Bearer Context in which userbearer plane resources are required in the network
for the transfer of MBMS data. This state is maintained as long as there is a corresponding MBMS session ongoing.
'Standby' reflects the state of an MBMS Bearer Context in which no userbearer plane resources are required in the
network for the transfer of MBMS data. This state is maintained as long as there is no corresponding MBMS session
ongoing.
The content of the MBMS Bearer Context is described in Table 2.
CR page 3
Table 2: MBMS Bearer Context
Parameter Description RAN SGSN GGSN BM-SC

IP multicast address IP multicast address identifying the MBMS bearer X X X X
described by this MBMS Bearer Context.
APN Access Point Name on which this IP multicast address X X X FFS
is defined.
TMGI Temporary Mobile Group Identity allocated to the X X X X
MBMS bearer. service.
State State of activitybearer plane resources of the MBMS FFS X X X
bearer ('standby' (‘standby’ or 'active')‘active’)
Required MBMS Minimum bearer capabilities the UE needs to support X X X
Bearer Capabilities
QoS Quality of Service required for the MBMS bearer. X X X X
service.
MBMS Service Area Area over which the MBMS bearer service has to be X X X X
distributed.
List of downstream List of downstream nodes that have requested the X X X
nodes MBMS bearer service and to which notifications and
MBMS data have to be forwarded.
1)
Number of UEs Number of UEs hosted by the node that have joined the FFS X X FFS
(FFS) multicast MBMS bearer service.
FFS FFS
Editor's note 1: Number of UEs may be used to determine when the last UE leaves the node and/or for content-
provider charging. The RAN knows how many UEs in RRC-CONNECTED mode are interested in a
multicast service, however it does not know how many UEs in RRC-IDLE mode are interested in the
service, hence the meaning and relevance of this parameter for the RAN are FFS.

network. The procedure establishes MBMS UE contexts in UE, SGSN and GGSN and RNC for each activated MBMS
multicast MBMS bearer service comparable to regular PDP contexts.
CR page 4
UE RAN SGSN GGSN BM-SC
1. PDP Context Activation

2. IGMP Join
3. MBMS Authorization Request
3. MBMS Authorization Response
4. MBMS Notification Request

5. Request MBMS Context Activation
6. Activate MBMS Context Request

7. MBMS Notification Response
8. Security Functions
GGSN
9. Create MBMS Context Request
11.MBMS Registration Request
11. MBMS Registration Respons
12. Create MBMS Context Response
14. Provision of MBMS UE

Context to RAN
15. Activate MBMS Context Accept
Figure 7: The activation of an MBMS multicast service
1. The UE activates a default, typically best-effort PDP context if not already established. This can be a PDP
context used for basic IP services like WAP or Internet access, or it might be the signalling PDP context used for
IMS access.
2. The UE sends an IGMP (IPv4) or MLD (IPv6) Join message over the default PDP context to signal its interest in
receiving a particular multicast MBMS bearer service identified by an IP multicast address.
3. The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive data.
The authorization decision is provided in the MBMS Authorization Response together with the APN to be used
for creation of the MBMS UE context. If the MBMS Authorization Response indicates that the UE is not
authorized to receive the MBMS data the process terminates with no additional message exchange.
4. The GGSN receives the IGMP/MLD Join request and sends an MBMS Notification Request (IP multicast
address, APN, Linked NSAPI) to the SGSN. Linked NSAPI is set equal to the NSAPI of the PDP context over
which the Join request was received. The IP multicast address is the one requested by the UE in the Join request.
The APN may be different from the APN to which the default PDP context has been activated. In any case, the
APN may resolve to a GGSN that is different from the GGSN receiving the IGMP/MLD Join request. The
CR page 5
GGSN starts a MBMS Activation Timer as GGSN may receive no response, e.g. in case SGSN or UE does not
support MBMS.
5. The SGSN sends a Request MBMS Context Activation (IP multicast address, APN, Linked NSAPI) to the UE to
request it to activate an MBMS context. Linked NSAPI allows the UE to associate the MBMS Context with the
PDP context over which it sent the IGMP/MLD Join message in step 2.
6. The UE creates an MBMS UE context and sends an Activate MBMS Context Request (IP multicast address,
APN, MBMS bearer capabilities) to the SGSN. The IP multicast address identifies the MBMS multicast service,
which the UE wants to join/activate. An APN may indicate a specific GGSN. The MBMS bearer capabilities
indicate the maximum QoS the UE can handle.
7. The SGSN sends a MBMS Notification Response (Cause) to the GGSN that sent the MBMS Notification
Request, where Cause shall indicate successful or unsuccessful MBMS context activation for the reason of
SGSN or UE (Cause is FFS). Upon reception of the response message with Cause indicating unsuccessful
operation or time-out of the MBMS Activation Timer in the GGSN, the GGSN may fallback to IP multicast
access as defined in 3GPP TS 29.061 [4].
8. Security Functions may be performed, e.g. to authenticate the UE.
9. It is FFS whether the SGSN performs a subscription check for the requested MBMS multicastbearer service
identified by the IP multicast address and APN or whether another network entity performs this check. The
SGSN creates an MBMS UE context and sends a Create MBMS Context Requests (IP multicast address, APN)
to the GGSN.
10. The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive
service data.. The authorization decision is provided in the MBMS Authorization Response.
11. If the GGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the GGSN
sends a MBMS Registration Request to the BM-SC. See subclause "MBMS Registration Procedure".
If no TMGI has been allocated for this MBMS bearer service, the BM-SC will allocate a new TMGI. This
TMGI will be passed to GGSN and SGSN via the MBMS Registration Response message and further to UE via
Activate MBMS Context Accept message.
The BM-SC responds with a MBMS Registration Response containing the MBMS Bearer Context
information for this MBMS bearer service and adds the identifier of the GGSN to the "list of downstream nodes"
parameter in its MBMS Bearer Context. See subclause "MBMS Registration Procedure".
12. The GGSN creates an MBMS UE context and sends a Create MBMS Context Response to the SGSN.
13. If the SGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the SGSN
sends a MBMS Registration Request to the GGSN. See subclause "MBMS Registration Procedure".
The GGSN responds with a MBMS Registration Response containing the MBMS Bearer Context information
for this MBMS bearer service and adds the identifier of the SGSN to the "list of downstream nodes" parameter in
its MBMS Bearer Context. See subclause "MBMS Registration Procedure".
14. The SGSN provides RAN with the MBMS UE Context(s) if at least one PS RAB is established for the UE.
15. The SGSN sends an Activate MBMS Context Accept (MBMS bearer capabilities) to the UE. The SGSN does
not need to wait for step 12 to be completed before sending this message. The MBMS bearer capabilities indicate
the maximum QoS that is used by this MBMS bearer service and the UE may take it into account when further
MBMS bearer services are activated. If the SGSN determines that the UE’s MBMS bearer capabilities are lower
than the Required MBMS Bearer Capabilities the SGSN rejects the request for activation of an MBMS context
indicating an appropriate cause and starts the deactivation of the already established MBMS UE contexts.
CR page 6
New York, USA, 24th – 28th November 2003 (==S2-033401)
CR-Form-v7
CHANGE REQUEST
1 6.0.0
Title: ! Various corrections and clarifications
Source: ! Siemens

Rel-6 (Release 6)
Reason for change: ! Version 6.0.0 does not differentiate between MBMS user and bearer service. Corrections
and clarifications in many places are required. Application replaced by MBMS user
service.
Mostly “bearer plane” is used. A few occurrences of the synonym “user plane” need to be
changed to “bearer plane”.
4.4.1.6 allows seesion start to coincide with sending of first packets. Contradicts to 4.4.2.5
and should be removed. 4.4.2.5 describes session start without Gmb signalling. Not in line
with 4.4.2.6 and session start procedere. Session start without Gmb signalling should be
removed.
5.5 QoS negotiation by GGSN contradicts to QoS clause.
Alignment of a number of different terms for “MBMS service area”.
6.3.1 rather hints that there are no QoS negotiation possibilities. It should be clearly
expressed that such negotiation is not possible.
8.2 MBMS multicast service activation: service data is not defined but also not needed
there.
Summary of change: ! Various corrections and clarifications.
Consequences if ! Inconsistencies and ambiguities that may cause problems and errors in stage 3 work.
not approved:
Clauses affected: ! all
CR page 1
Y N
Other comments: !

6. Fill out the above form. The symbols above marked ! contain pop-up help information about the field that
they are closest to.
6. Obtain the latest version for the release of the specification to which the change is proposed. Use the MS
Word “revision marks” feature (also known as “track changes”) when making the changes. All 3GPP
specifications can be downloaded from the 3GPP server under ftp://ftp.3gpp.org/specs/ For the latest version,
look for the directory name with the latest date e.g. 2001-03 contains the specifications resulting from the March
2001 TSG meetings.
6. With “track changes” disabled, paste the entire CR form (use CTRL-A to select it) into the specification just
in front of the clause containing the first piece of changed text. Delete those parts of the specification which are
not relevant to the change request.
CR page 2
3GPP TS 23.246 V.6.0.0 (2003-09)
Technical Specification
3rd Generation Partnership Project;

Technical Specification Group Services and System Aspects;
Multimedia Broadcast/Multicast Service (MBMS);
Architecture and functional description
(Release 6)
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 6 4 3GPP TS 23.246 V.6.0.0 (2003-09)
Keywords
3GPP, MBMS
3GPP
Postal address
3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org
Copyright Notification
No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.
© 2003, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC).
All rights reserved.
3GPP
Release 6 5 3GPP TS 23.246 V.6.0.0 (2003-09)
Contents
Foreword............................................................................................................................................................ 7
1 Scope ....................................................................................................................................................... 8
2 References ............................................................................................................................................... 8
3 Definitions and abbreviations.................................................................................................................. 8
3.1 Definitions................................................................................................................................................................8
3.2 Abbreviations ...........................................................................................................................................................8
4 MBMS Architecture ................................................................................................................................ 9
4.1 Overview ..................................................................................................................................................................9
4.2 Reference Architecture Model ...............................................................................................................................10
4.3 MBMS Specific Reference points..........................................................................................................................10
4.3.1 Gmb ..................................................................................................................................................................10
4.3 MBMS Service Provision.......................................................................................................................................11
4.4.1 MULTICAST MODE.......................................................................................................................................11
4.4.1.1 Subscription......................................................................................................................................................12
4.4.1.2 Service announcement ......................................................................................................................................12
4.4.1.3 Joining ..............................................................................................................................................................13
4.4.1.4 Session Start .....................................................................................................................................................13
4.4.1.5 MBMS notification...........................................................................................................................................13
4.4.1.6 Data transfer .....................................................................................................................................................13
4.4.1.7 Session Stop......................................................................................................................................................13
4.4.1.8 Leaving .............................................................................................................................................................13
4.4.2 Multicast Mode timeline...................................................................................................................................13
4.4.2.1 Period between Service Announcement and Session Start...............................................................................13
4.4.2.2 Period between Service Announcement and Service Subscription...................................................................13
4.4.2.3 Period between Service Announcement and Joining........................................................................................13
4.4.2.4 Period between Joining and Session Start ........................................................................................................14
4.4.2.5 Period between Session Start and First Data Arrival........................................................................................14
4.4.2.6 Period between Session Start and Session Stop................................................................................................14
4.4.3 BROADCAST MODE .....................................................................................................................................14
4.4.3.1 Service announcement ......................................................................................................................................16
4.4.3.2 Session Start .....................................................................................................................................................16
4.4.3.3 MBMS notification...........................................................................................................................................16
4.4.3.4 Data transfer .....................................................................................................................................................16
4.4.3.5 Session Stop......................................................................................................................................................16
4.4.4 Broadcast Mode timeline..................................................................................................................................17
4.4.4.1 Period between Service Announcement and Session Start..............................................................................17
4.4.4.2 Period between Session Start and First Data Arrival........................................................................................17
4.4.4.3 Period between Session Start and Session Stop................................................................................................17
5 Functional Entities To Support MBMS................................................................................................. 17
5.1 Broadcast-Multicast Service Centre (BM-SC) .......................................................................................................17
5.1.1 Content Provider Authentication, Authorization and Charging........................................................................17
5.1.2 MBMS Transport..............................................................................................................................................17
5.1.3 MBMS Transmissions ......................................................................................................................................17
5.1.4 Service Advertisement and Description ...........................................................................................................18
5.2 User Equipment......................................................................................................................................................18
5.3 UTRAN/GERAN ...................................................................................................................................................18
5.4 SGSN .....................................................................................................................................................................19
5.5 GGSN.....................................................................................................................................................................19
5.6 MBMS Data Sources and Content Provider...........................................................................................................19
5.7 Optional Functional Element .................................................................................................................................19
5.7.1 CSE...................................................................................................................................................................19
5.7.2 CBC ..................................................................................................................................................................19
5.7.3 OSA-SCS..........................................................................................................................................................19
3GPP
Release 6 6 3GPP TS 23.246 V.6.0.0 (2003-09)
6 MBMS attributes and Parameters.......................................................................................................... 20

6.1 MBMS UE Context................................................................................................................................................20
6.2 MBMS Bearer Context...........................................................................................................................................20
6.3 Quality-of-Service..................................................................................................................................................22
6.3.1 MBMS QoS distribution tree............................................................................................................................23
6.4 Temporary Mobile Group Identity .........................................................................................................................23
8 MBMS Procedures ................................................................................................................................ 23
8.1 MBMS Notification ...............................................................................................................................................23
8.2 MBMS Multicast Service Activation .....................................................................................................................23
8.3 MBMS Session Start Procedure .............................................................................................................................25
8.4 MBMS Registration Procedure ..............................................................................................................................26
8.5 MBMS Session Stop Procedure .............................................................................................................................28
8.6 MBMS De-Registration Procedure ........................................................................................................................28
8.6.1 BM-SC initiated MBMS De-Registration Procedure .......................................................................................30
8.7 MBMS Multicast Service Deactivation .................................................................................................................31
8.8 Iu Bearer Plane release procedure ..........................................................................................................................32
8.9 RAN Resource Setup .............................................................................................................................................33
8.10 Inter SGSN Routeing Area Update...................................................................................................................33
8.11 Inter SGSN Serving RNS Relocation Procedure ..............................................................................................35
8.12 MBMS Broadcast Service Activation ..............................................................................................................36
8.13 MBMS Broadcast service de-activation ...........................................................................................................36
8.14 MBMS Broadcast Session Start Procedure ......................................................................................................36
9 Security.................................................................................................................................................. 37
10 Charging requirement ............................................................................................................................ 37
Annex A (Informative): Information flows.......................................................................................... 38
A.1 General information flow ...................................................................................................................... 38
Annex B (Informative): Change history............................................................................................... 39
3GPP
Release 6 7 3GPP TS 23.246 V.6.0.0 (2003-09)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 6 8 3GPP TS 23.246 V.6.0.0 (2003-09)
1 Scope
The present document describes the stage 2 description (architectural solution and functionalities) for MBMS, which
includes the elements necessary to realise the stage 1 requirements in 3GPP TS 22.146 [2].
The present document includes information applicable to network operators, service providers and manufacturers.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1".
[3] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture".
[4] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting
packet based services and Packet Data Networks (PDN)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions defined in 3GPP TS 21.905 [1] and 3GPP TS
22.146 [2] and the following apply:
MBMS Service Announcement: Mechanism to allow users to be informed about the MBMS user services available.
MBMS Bearer Service: the service provided by the PS Domain to MBMS User Services to deliver IP multicast
datagrams to multiple receivers using minimum network and radio resources.
MBMS User Service: the MBMS service provided to the end user by means of the MBMS Bearer Service and possibly
other capabilities.
MBMS Service Area: The area in which a specific MBMS Bearer Service is available. It is defined individually per
MBMS Bearer Service.
3.2 Abbreviations
For the purposes of the present document, the abbreviations in 3GPP TS 21.905 [1] and 3GPP TS 22.141 [2] apply.
3GPP
Release 6 9 3GPP TS 23.246 V.6.0.0 (2003-09)
4 MBMS Architecture
4.1 Overview
MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients.
Transmitting the same data to multiple recipients allows network resources to be shared.
The MBMS bearer service offers two modes:
• Broadcast Mode
• Multicast Mode
MBMS architecture enables the efficient usage of radio-network and core-network resources, with an emphasis on radio
interface efficiency.
MBMS is realised by the addition of a number of new capabilities to existing functional entities of the 3GPP
architecture and by addition of a number of new functional entities.
The existing PS Domain functional entities (GGSN, SGSN, UTRAN, GERAN and UE) are enhanced to provide the
'MBMS Bearer Service'. In the user bearer plane, this service provides delivery of IP Multicast datagrams from the Gi
reference point to UEs with a specified Quality of Service. In the control plane, this service provides mechanisms for:
- managing the MBMS bearer service activation status of UEs (in the case of multicast) mode)
- outsourcing authorisation decisions to the MBMS User Service (i.e. to the BM-SC) (in the case of multicast)
mode)
- providing control of session initiation/termination by the MBMS User Service and managing bearer resources
for the distribution of MBMS data (in the case or multicast and broadcast modes)
A particular instance of the MBMS Bearer Service is identified by an IP Multicast Address and an APN Network
Identifier.
The boundary of the MBMS Bearer Service is the Gmb and Gi reference points as shown in Section 4.3 below. The
former provides access to the control plane functions and the latter the userbearer plane.
A functional entity, the Broadcast Multicast Service Centre (BM-SC) provides a set of functions for MBMS User
Services. BM-SC functions for different MBMS User Services may be supported from the same or different physical
network elements.
3GPP
Release 6 10 3GPP TS 23.246 V.6.0.0 (2003-09)
4.2 Reference Architecture Model
Content
CBC Provider
PDN
(e.g. Internet)
OSA
SCS
Content
HLR CSE BM-SC Provider
Gmb
Gr
Gi
Uu Iu Gn/Gp Gi Gi Multicast
UE UTRAN SGSN GGSN BG Broadcast
Source
Gi
Iu/Gb
Multicast
Um Broadcast
Source
UE GERAN
Note: dotted lines means functions / reference points that are FFS. Gp applies only when SGSN and GGSN are
in different PLMN.
Figure 1: Reference architecture to support MBMS
4.3 MBMS Specific Reference points

4.3.1 Gmb
Signalling between GGSN and BM-SC is exchanged at Gmb reference point. .This represents the network side
boundary of the MBMS Bearer Service from a control plane perspective. This includes user specific MBMS Gmb
signalling and MBMS bearer service specific signalling.
MBMS bearer service specific Gmb signalling:
- The GGSN establishes the MBMS bearer context and registers at BM-SC.
- The GGSN or the BM-SC releases the MBMS bearer context and de-register the GGSN from the BM-SC.
- The BM-SC indicates session start and stop to the GGSN including session attributes like QoS or
multicastMBMS service area.
User specific Gmb signalling:
- The BM-SC authorises the user specific MBMS multicast service activation (join) at the GGSN.
- The GGSN reports to the BM-SC the successful user specific MBMS multicast activation (join) to allow the
BM-SC to synchronise the BM-SC UE MBMS context and charging with the MBMS UE contexts in SGSN and
GGSN.
- The GGSN reports to the BM-SC when a user specific MBMS multicast service is released or deactivated (e.g.
when the radio contact is lost) to synchronise BM-SC UE MBMS contexts and charging with the MBMS UE
contexts in SGSN and GGSN.
3GPP
Release 6 11 3GPP TS 23.246 V.6.0.0 (2003-09)
The BM-SC initiates the deactivation of a user specific MBMS multicastbearer service when the MBMS user service is
terminated at application layer..
4.43 MBMS Service Provision

4.4.1 MULTICAST MODE
Reception of an MBMS MULTICAST service is enabled by certain procedures that are illustrated in the Figure below.
Subscription
Service announcement
Joining
Session start
MBMS notification
Data transfer
Session Stop
Leaving
Figure 2: Phases of MBMS Multicast service provision
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.
3GPP
Release 6 12 3GPP TS 23.246 V.6.0.0 (2003-09)
This is illustrated with the following example of timeline:
Subscription can be Service join by the

at any time user can be at any
time
UE1 time
events
subscription User service
to service1 service leave
join
subscription
UE2 to service1
events
Idle period Data Data Data

Service 1 of seconds transfer transfer transfer
events
Start Service 1 1st Session 1st session stop Stop Service 1
announcement start Service 1 Session 2 announcement
Service 1 session1
Transfer Announcement
of data
Data sent to Data sent to
Data sent UE1 and UE1 and Data sent
to UE1 UE2 UE2 to UE2
Figure 3: Timeline example
4.4.1.1 Subscription
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 appropriate database(s) in the operator'soperator’s network.
4.4.1.2 Service announcement

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) 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 usersuser’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): -
- CBS
- MBMS Broadcast mode to advertise MBMS Multicast and Broadcast user Services
- MBMS Multicast mode to advertise MBMS Multicast user Services
3GPP
Release 6 13 3GPP TS 23.246 V.6.0.0 (2003-09)
- PUSH mechanism (WAP, SMS-PP, MMS)
- URL (HTTP, FTP)
The details of the MBMS service announcement mechanisms are not specified, but MBMS shall allow the utilisation of
solutions using IETF protocols.
4.4.1.3 Joining
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 is willing to receive Multicast mode data of a specific
MBMS bearer service.
4.4.1.4 Session Start

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 the Stage 1. 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 network resourcesbearer
resource establishment for MBMS data transfer.
4.4.1.5 MBMS notification

Informs the UEs about forthcoming (and potentially about ongoing) MBMS multicast data transfer.
4.4.1.6 Data transfer

IsIt is the phase when MBMS data are transferred to the UEs. Arrival of the first packet at the GGSN may coincide with
Session Start.
4.4.1.7 Session Stop

IsIt 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 networkbearer resources associated with the session. At Session Stop,
the networkbearer resources are released.
4.4.1.8 Leaving
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
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 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.
3GPP
Release 6 14 3GPP TS 23.246 V.6.0.0 (2003-09)
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 starting 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 within which users
should 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 userbearer plane.
Session Start may be triggered by an explicit notification from the BM-SC or by first data arrival at the GGSN. In the
case of user-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 networkbearer resources. However, if this idle period with no data is short, this may
not be appropriate as it brings more signalling and processing.
There is no absolute value on the duration of this "long idle period". The order of magnitude (i.e. is it closer to 30
seconds or 30 minutes) is to be defined taking into account UTRAN constraints.
4.4.3 BROADCAST MODE

An example for the phases of MBMS broadcast service provision is described in the figure below:
3GPP
Release 6 15 3GPP TS 23.246 V.6.0.0 (2003-09)
Service announcement
Session Start
MBMS notification
Data transfer
Session Stop
Figure 4: Phases of MBMS broadcast service provision
The sequence of phases may repeat, e.g. depending on the need to transfer data. It is also possible that the service
announcement and MBMS notification phase may run in parallel with other phases, in order to inform UEs which have
not yet received the related service.
3GPP
Release 6 16 3GPP TS 23.246 V.6.0.0 (2003-09)
time
UE1
Local service de-
UE local activation
service
activation
UE2
Idle period Data Data Data

of seconds transfer transfer transfer
Broadcast session start Session stop

Start Broadcast Stop
Service announc
announcement ement
Service 1 session1
Service 1 Session 2
Broadcast service Announcement
Broadcast of Data, received by any UE

which is present
Figure 5: Broadcast service timeline
4.4.3.1 Service announcement

Informs UEs about forthcoming MBMS user services. Also see section on Multicast mode (4.4.1.2)
4.4.3.2 Session Start

Session Start is the point at which the BM-SC is ready to send data. This can be identified with the start of a "Broadcast
session" as defined in the Stage 1. Session Start occurs independently of Service Activation by the user – i.e. a given
user may activate the service before or after the start of the session. Session Start is the trigger for network
resourcesbearer resource establishment for MBMS data transfer.
4.4.3.3 MBMS notification

Informs the UEs about forthcoming (and potentially about ongoing) MBMS broadcast data transfer.
4.4.3.4 Data transfer

IsIt is the phase when MBMS data are transferred to the UEs.
4.4.3.5 Session Stop

IsIi is the point at which the MBMS applicationuser service determines that there will be no more data to send for some
period of time – this period being long enough to justify removal of networkbearer resources associated with the
service. At Session Stop, the networkbearer resources are released.
3GPP
Release 6 17 3GPP TS 23.246 V.6.0.0 (2003-09)
4.4.4 Broadcast Mode timeline
4.4.4.1 Period between Service Announcement and Session Start

Same as for Multicast mode.
4.4.4.2 Period between Session Start and First Data Arrival

4.4.4.3 Period between Session Start and Session Stop

5 Functional Entities To Support MBMS

To provide MBMS bearer services existing functional entities, GGSN, SGSN, RNC/BSC, perform several MBMS
related functions and procedures, some of which are specific to MBMS. An MBMS specific functional entity –
Broadcast Multicast Service Centre (BM-SC) supports various MBMS user service specific service provisioning and
delivery.
5.1 Broadcast-Multicast Service Centre (BM-SC)

The BM-SC provides functions for MBMS user service provisioning and delivery. It may serve as an entry point for
content provider MBMS transmissions, used to authorise and initiate MBMS Bearer Services within the PLMN and can
be used to schedule and deliver MBMS transmissions.
The BM-SC is a functional entity, which must exist for each MBMS User Service.
This section describes BM-SC functions, which are defined for the standardised MBMS User Services. Which of these
functions are provided as general purpose capabilities to be used by multiple MBMS User Services and which are
specific to a particular MBMS User Service is defined in conjunction with the definition of the standardised MBMS
User Services.
5.1.1 Content Provider Authentication, Authorization and Charging

The BM-SC shall be able to authenticate 3rd party content providers, providing content for MBMS transmissions.
3rd party content providers may wish to initiate an MBMS transmission. In such cases, the BM-SC shall be able to
authorize content providers to transmit data over MBMS bearer services depending on operator policy.
The BM-SC shall be able to verify the integrity of data received from content providers.
The BM-SC shall be able to generate charging records for content provider transmitted data.
5.1.2 MBMS Transport

The BM-SC shall be able to provide the GGSN with transport associated parameters such as quality-of-service and
multicast/broadcastMBMS service area.
The BM-SC shall be able to initiate and terminate MBMS transportbearer resources prior to and following transmission
of MBMS data.
5.1.3 MBMS Transmissions

The BM-SC should be able to accept content from external sources and transmit it using error resilient schemes (e.g.
specialized MBMS codecs).
3GPP
Release 6 18 3GPP TS 23.246 V.6.0.0 (2003-09)
Further, the BM-SC might be used to schedule MBMS session transmissions, retrieve content from external sources and
provide this content using MBMS transport resources.bearer services.
The BM-SC should be able to schedule MBMS session retransmissions, and label each MBMS session with an MBMS
Session Identifier to allow the UE to distinguish the MBMS session retransmissions. These retransmissions are
transparent to the RAN and MBMS user service.
5.1.4 Service Advertisement and Description

The BM-SC shall be able to provide service announcements for multicast and broadcast MBMS user services.
The BM-SC shall be able to provide the UE with media descriptions specifying the media to be delivered as part of an
MBMS user service (e.g. type of video and audio encodings).
The BM-SC shall be able to provide the UE with MBMS session descriptions specifying the MBMS sessions to be
delivered as part of an MBMS user service (e.g. multicast service identification, addressing, time of transmission, etc.)
The BM-SC shall be able to deliver media and session descriptions by means of service announcements using IETF
specified protocols over MBMS multicast and broadcast bearersbearer services.
5.2 User Equipment

The UE shall support functions for the activation/deactivation of the MBMS bearer service.
Once a particular MBMS bearer service is activated, no further explicit user request is required to receive MBMS data
although the user may be notified that data transfer is about to start.
The UE shall support security functions as appropriate for MBMS.
The UE should, depending on terminal capabilities, be able to receive MBMS user service announcements, paging
information (non MBMS specific) or support simultaneous services (For example the user can originate or receive a call
or send and receive messages whilst receiving MBMS video content). Reception of this paging or announcements may
however, create losses in the MBMS data reception. The MBMS applicationuser service should be able to cope with
such losses.
Some UE depending upon terminal capability, may be able to store MBMS data. (This may involve DRM but this is out
of scope of this specification) .
The MBMS Session Identifier contained in the notification to the UE shall enable the UE to decide whether it needs to
ignore the forthcoming transmission of MBMS session (e.g., because the UE has already received this MBMS session).
5.3 UTRAN/GERAN
UTRAN/GERAN are responsible for efficiently delivering MBMS data to the designated multicast or broadcastMBMS
service area.
Efficient delivery of MBMS data in multicast mode may require mechanisms in the UTRAN/GERAN. E.G. The, e.g.
the number of users within a cell prior to and during MBMS transmission could be used to choose an appropriate radio
bearer.
MBMS transmissions may be initiated and terminated intermittently. The UTRAN/GERAN shall support the initiation
and termination of MBMS transmissions by the core-network. Further, the UTRAN/GERAN shall be able to receive
MBMS data from the core-network over Iu bearers shared by many UEs.
The UTRAN/GERAN shall support intra-RNC/BSC, inter-RNC/BSC mobility of MBMS receivers. Mobility is
expected to cause limited data loss. Therefore, MBMS applications user services should be able to cope with potential
data loss caused by UE mobility.
The UTRAN/GERAN shall be able to transmit MBMS user service announcements, paging information (non MBMS
specific) and support other services in parallel with MBMS (Forfor example Dependingdepending on terminal
capabilities the user could originate or receive a call or send and receive messages whilst receiving MBMS video
content).
3GPP
Release 6 19 3GPP TS 23.246 V.6.0.0 (2003-09)
5.4 SGSN
The SGSN role within MBMS architecture is to perform user individual network MBMS bearer service control
functions and to provide MBMS transmissions to UTRAN/GERAN.
The SGSN shall provide support for intra-SGSN and inter-SGSN mobility procedures. Specifically this requires the
SGSN to store a user-specific MBMS UE context for each activated multicast MBMS bearer service and to pass these
contexts to the new SGSN during inter-SGSN mobility procedures.
The SGSN shall be able to generate charging data per multicast MBMS bearer service for each user. Further, the SGSN
may provide functions to support the charging of prepaid users.
The SGSN shall be able to establish Iu and Gn bearers shared by many users on demand when data has to be transferred
to the users. This shall be done upon notification from the GGSN. Likewise, when data is no longer available the SGSN
shall be able to tear down these bearers upon notification from the GGSN.
5.5 GGSN
The GGSN role within the MBMS architecture is to serve as an entry point for IP multicast traffic as MBMS data. Upon
notification from the BM-SC the GGSN shall be able to request the establishment of a user-bearer plane for a broadcast
or multicast MBMS transmission. Further, upon BM-SC notification the GGSN shall be able to tear down the
established userbearer plane. User-Bearer plane establishment for multicast services is carried out towards those SGSNs
that have requested to receive transmissions for the specific multicast MBMS bearer service.
The GGSN shall be able to receive IP multicast traffic (whether from BM-SC or other data sources) and to route this
data to the proper GTP tunnels set-up as part of the MBMS bearer service.
Other functions to note here that GGSN may provide in support of MBMS bearer service but not exclusive to MBMS
are:
- Message Screening (not needed if the MBMS sources are internal in the PLMN);
- Charging Data Collection;
- Service (QoS) negotiation.
5.6 MBMS Data Sources and Content Provider

The reference point from the content provider to the BM-SC is not standardised.
5.7 Optional Functional Element

NOTE: The following are FFS.
5.7.1 CSE
The SGSN may use CAMEL to handle pre-paid services, e.g. credit checking for on-line charging.
5.7.2 CBC
The Cell Broadcast Centre (CBC) may be used to announce MBMS user services to the users.
5.7.3 OSA-SCS
The BM-SC might use OSA-SCS to interact with third parties.
3GPP
Release 6 20 3GPP TS 23.246 V.6.0.0 (2003-09)
6 MBMS attributes and Parameters
6.1 MBMS UE Context

The MBMS UE Context contains UE-specific information related to a particular MBMS bearer service that the UE has
joined. An MBMS UE Context is created in the UE, SGSN and GGSN when the UE joins an MBMS bearer service. In
the SGSN, an MBMS UE Context is also created as a result of an inter-SGSN routing area update after the transfer of
the MBMS UE Context from the old SGSN. It is FFS whether MBMS UE Contexts are created in the BM-SC.
All MBMS UE Contexts of a UE (referenced as "UE Link" in RNC) are provided via UE dedicated Iu procedure(s) to
the SRNC when the first PS RAB is established for the UE, or when the UE performs MBMS Multicast Service
Activation. MBMS UE Contexts are provided to the SRNC regardless whether MBMS Sessions are ongoing or not (i.e.
before, between and after Sessions).
In the UE, SGSN and GGSN, the MBMS UE Context is stored as part of the MM Context for the UE. There is one
MBMS UE Context per MBMS bearer service that the UE has joined.
In the RNC, the MBMS UE Contexts are stored as part of the UE Context of the RNC.
The content of the MBMS UE Context is described in Table 1.
Table 1: MBMS UE Context
Parameter Description UE SGSN GGSN RNC BM-SC

IP multicast address IP multicast address identifying an MBMS bearer X X X X
that the UE has joined.
APN Access Point Name on which this IP multicast X X X X
address is defined.
TMGI Temporary Mobile Group Identity allocated to the X X FFS X FFS
MBMS bearer.
Linked NSAPI NSAPI of the PDP context used by the UE to carry X X X
IGMP/MLD signalling.
FFS FFS

MBMS data.
done is out of the scope of this specification. The MBMS Bearer Context is created in the SRNC when a first MBMS
UE Context is created in SRNC. Session Start procedure may create MBMS Bearer Context in an RNC which has no
MBMS Bearer Context yet. Furthermore, it is FFS whether the state model described below is applicable as such to the
RAN or whether it needs to be extended to cover the case of the RAN properly.
An MBMS Bearer Context, once created, can be in one of two states reflecting the activitybearer plane resource status
of the corresponding MBMS bearer. service.
3GPP
Release 6 21 3GPP TS 23.246 V.6.0.0 (2003-09)
No user plane resources required
Standby
Active
User plane resources required
No bearer plane resources required
Standby
Active
Bearer plane resources required
Figure 6: MBMS Bearer Context State Model
'Active' reflects the state of an MBMS Bearer Context in which userbearer plane resources are required in the network
for the transfer of MBMS data. This state is maintained as long as there is a corresponding MBMS session ongoing.
'Standby' reflects the state of an MBMS Bearer Context in which no userbearer plane resources are required in the
network for the transfer of MBMS data. This state is maintained as long as there is no corresponding MBMS session
ongoing.
The content of the MBMS Bearer Context is described in Table 2.
3GPP
Release 6 22 3GPP TS 23.246 V.6.0.0 (2003-09)
Table 2: MBMS Bearer Context
Parameter Description RAN SGSN GGSN BM-SC

IP multicast address IP multicast address identifying the MBMS bearer X X X X
described by this MBMS Bearer Context.
APN Access Point Name on which this IP multicast address X X X FFS
is defined.
TMGI Temporary Mobile Group Identity allocated to the X X X X
MBMS bearer. service.
State State of activitybearer plane resources of the MBMS FFS X X X
bearer ('standby' (‘standby’ or 'active')‘active’)
QoS Quality of Service required for the MBMS bearer. X X X X
service.
MBMS Service Area Area over which the MBMS bearer service has to be X X X X
distributed.
List of downstream List of downstream nodes that have requested the X X X
nodes MBMS bearer service and to which notifications and
MBMS data have to be forwarded.
1)
Number of UEs Number of UEs hosted by the node that have joined the FFS X X FFS
(FFS) multicast MBMS bearer service.
FFS FFS
Editor's note 1: Number of UEs may be used to determine when the last UE leaves the node and/or for content-
provider charging. The RAN knows how many UEs in RRC-CONNECTED mode are interested in a
multicast service, however it does not know how many UEs in RRC-IDLE mode are interested in the
service, hence the meaning and relevance of this parameter for the RAN are FFS.
6.3 Quality-of-Service
It shall be possible for the network to control quality-of-service parameters for sessions of multicast and broadcast
sessions.MBMS bearer services. All QoS attributes described in [3] are applicable to MBMS. bearer services.
Compared to point-to-point bearer services the following limitations exist:
- For traffic class, only the background and streaming classes shall be supported.
- For SDU error ratio, only higher values are supported, i.e. the values describing higher numbers of lost or
corrupted SDUs (actual values are FFS).
MBMS bearers bearer services of background class are best suited for the transport of MBMS user services such as
messaging or downloading. As for point-to-point bearersbearer services, the network should, as far as possible, avoid
dropping packets transported by a background class bearer. service. Instead, buffering and shaping schemes should be
applied to the traffic flow to adapt to the available resources and changing network conditions. The total transfer time is
not critical for background class bearersbearer services since the content must normally have been received in totality
and stored in the UE before the user can access it.
MBMS bearersbearer services of streaming class are best suited for the transport of MBMS user services such as
streaming. As for point-to-point bearersbearer services, the network should minimise the packet transfer delay of
streaming class bearersbearer services as far as possible. Packet dropping should be the preferred traffic conditioning
action applied to the traffic flow to adapt to the available resources.
MBMS user services that would normally use MBMS bearersbearer services of background class may however need to
use a streaming class MBMS bearer. service. This will allow to transfer each MBMS data unit at almost the same point
in time in all cells of the MBMS service area, as otherwise UEs moving between cells while an MBMS session is
ongoing may experience high packet loss due to possible time offsets of the data transmission between cells. The
amount of packet loss depends on this time offset, the cell change time and the bitrate in particular. Otherwise the
MBMS user service will have to provide sufficient redundancy within the data to be able to cope with the high packet
loss.
As the MBMS bearer service transfers data to many UEs in parallel and because of the lack of feedback channel on
radio level low SDU error ratios are difficult to achieve. When the resulting packet error ratio is not suitable for the
application MBMS user service or when prevention of data loss is required, an MBMS user service may perform
retransmission of MBMS data over point-to-point PDP bearer services on request from the receiver.
3GPP
Release 6 23 3GPP TS 23.246 V.6.0.0 (2003-09)
6.3.1 MBMS QoS distribution tree

MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many RNCs and
, many SGSNs. and one or more GGSNs. Furthermore some transportbearer resources may be shared between many
users accessing the same MBMS bearer service in order to save resources. As a result, each branch of a MBMS
distribution tree shall be established with the same QoS.
MBMS distribution tree shall have the same QoS for all its branches.
When a branch of the MBMS distribution tree has been created, it shouldis not be possible for construction of another
branch (e.g. due to arrival of a new UE (or change of location of a UE with removal of a branch and addition of a new
one) to impact the QoS of already established branches.
There is no QoS value negotiation between UMTS network elements is not required... This imply that some branches
may not be established if QoS requirement cannot be accepted by the concerned network node.
Also in RAN there is no QoS (re-)negotiation feature in for the RNC should not be allowed for MBMS bearer service.
6.4 Temporary Mobile Group Identity

Temporary Mobile Group Identity (TMGI) is used for groupMBMS notification purpose. The BM-SC will allocates a
TMGI per MBMS bearer service that is unique within HPLMN. For Multicast ServiceMBMS bearer services the TMGI
will be transmitted to UE via service activation procedure.
8 MBMS Procedures
8.1 MBMS Notification

When aan MBMS Session starts, UEs interested in the MBMS bearer service (PMM-CONNECTED UEs and PMM-
IDLE UEs) shall be notified.
MBMS Session attributes such as Service Id and the Multicast MBMS service Area are made available in all interested
RNCs during the Session Start procedure. Other parameters are FFS.
For radio efficiency reasons, the UTRAN may select on per cell basis whether to establish point-to-point or point-to-
multipoint links for the distribution of MBMS data to the UEs.
In order to perform this selection, the UTRAN requests UEs to move to PMM-CONNECTED / RRC-CONNECTED
state by means of MBMS group notification sent in the MulticastMBMS service Area.
The fact that this groupMBMS notification moves the UEs back to PMM-CONNECTED or to RRC-CONNECTED
state is FFS, subject to RAN decision.
The exact number of UEs moved to PMM-CONNECTED / RRC-CONNECTED state is a decision of RAN node. It is
not necessary for all UEs to move to PMM-CONNECTED/ RRC_CONNECTED in order for the RAN to decide to use
point-to-multipoint, other UEs may remain in IDLE state. This is a UTRAN choice (based on RRM criteria…), FFS in
RAN group.
Following the decision to set up point-to-point or point-to-multipoint links, the number of UEs that need to be
maintained in CONNECTED state or moved to IDLE state for MBMS data reception is also an decision of a RAN
node.
GERAN functionality is FFS.

3GPP
Release 6 24 3GPP TS 23.246 V.6.0.0 (2003-09)
network. The procedure establishes MBMS UE contexts in UE, SGSN and GGSN and RNC for each activated MBMS
multicast MBMS bearer service comparable to regular PDP contexts.
1. PDP Context Activation

2. IGMP Join
4. MBMS Notification Request

5. Request MBMS Context Activation
6. Activate MBMS Context Request

7. MBMS Notification Response
GGSN
9. Create MBMS Context Request
11.MBMS Registration Request
11. MBMS Registration Respons
12. Create MBMS Context Response
14. Provision of MBMS UE

Context to RAN
15. Activate MBMS Context Accept
Figure 7: The activation of an MBMS multicast service
1. The UE activates a default, typically best-effort PDP context if not already established. This can be a PDP
context used for basic IP services like WAP or Internet access, or it might be the signalling PDP context used for
IMS access.
2. The UE sends an IGMP (IPv4) or MLD (IPv6) Join message over the default PDP context to signal its interest in
receiving a particular multicast MBMS bearer service identified by an IP multicast address.
3. The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive data.
The authorization decision is provided in the MBMS Authorization Response together with the APN to be used
for creation of the MBMS UE context. If the MBMS Authorization Response indicates that the UE is not
authorized to receive the MBMS data the process terminates with no additional message exchange.
4. The GGSN receives the IGMP/MLD Join request and sends an MBMS Notification Request (IP multicast
address, APN, Linked NSAPI) to the SGSN. Linked NSAPI is set equal to the NSAPI of the PDP context over
which the Join request was received. The IP multicast address is the one requested by the UE in the Join request.
3GPP
Release 6 25 3GPP TS 23.246 V.6.0.0 (2003-09)
The APN may be different from the APN to which the default PDP context has been activated. In any case, the
APN may resolve to a GGSN that is different from the GGSN receiving the IGMP/MLD Join request. The
GGSN starts a MBMS Activation Timer as GGSN may receive no response, e.g. in case SGSN or UE does not
support MBMS.
5. The SGSN sends a Request MBMS Context Activation (IP multicast address, APN, Linked NSAPI) to the UE to
request it to activate an MBMS context. Linked NSAPI allows the UE to associate the MBMS Context with the
PDP context over which it sent the IGMP/MLD Join message in step 2.
6. The UE creates an MBMS UE context and sends an Activate MBMS Context Request (IP multicast address,
APN) to the SGSN. The IP multicast address identifies the MBMS multicast service, which the UE wants to
join/activate. An APN may indicate a specific GGSN.
7. The SGSN sends a MBMS Notification Response (Cause) to the GGSN that sent the MBMS Notification
Request, where Cause shall indicate successful or unsuccessful MBMS context activation for the reason of
SGSN or UE (Cause is FFS). Upon reception of the response message with Cause indicating unsuccessful
operation or time-out of the MBMS Activation Timer in the GGSN, the GGSN may fallback to IP multicast
access as defined in 3GPP TS 29.061 [4].
8. Security Functions may be performed, e.g. to authenticate the UE.
9. It is FFS whether the SGSN performs a subscription check for the requested MBMS multicastbearer service
identified by the IP multicast address and APN or whether another network entity performs this check. The
SGSN creates an MBMS UE context and sends a Create MBMS Context Requests (IP multicast address, APN)
to the GGSN.
10. The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive
service data.. The authorization decision is provided in the MBMS Authorization Response.
11. If the GGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the GGSN
sends a MBMS Registration Request to the BM-SC. See subclause "MBMS Registration Procedure".
If no TMGI has been allocated for this MBMS bearer service, the BM-SC will allocate a new TMGI. This
TMGI will be passed to GGSN and SGSN via the MBMS Registration Response message and further to UE via
Activate MBMS Context Accept message.
The BM-SC responds with a MBMS Registration Response containing the MBMS Bearer Context
information for this MBMS bearer service and adds the identifier of the GGSN to the "list of downstream nodes"
parameter in its MBMS Bearer Context. See subclause "MBMS Registration Procedure".
12. The GGSN creates an MBMS UE context and sends a Create MBMS Context Response to the SGSN.
13. If the SGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the SGSN
sends a MBMS Registration Request to the GGSN. See subclause "MBMS Registration Procedure".
The GGSN responds with a MBMS Registration Response containing the MBMS Bearer Context information
for this MBMS bearer service and adds the identifier of the SGSN to the "list of downstream nodes" parameter in
its MBMS Bearer Context. See subclause "MBMS Registration Procedure".
14. The SGSN provides RAN with the MBMS UE Context(s) if at least one PS RAB is established for the UE.
15. The SGSN sends an Activate MBMS Context Accept to the UE. The SGSN does not need to wait for step 12 to
be completed before sending this message.

Through this procedure, MBMS session attributes such as QoS, Multicast MBMS service Area (tracking/non-tracking
area are FFS) are provided to the GGSN(s) and SGSN(s) that have previously registered for the corresponding MBMS
bearer service and to all RNCs that are connected to a registered SGSN. In addition the procedure allocates the bearer
plane to all registered GGSNs and all registered SGSNs and to RNCs that respond to the session start accordingly.
3GPP
Release 6 26 3GPP TS 23.246 V.6.0.0 (2003-09)

Figure 8: Session Start procedure
provide the session attributes (QoS, MulticastMBMS service Area…) to the GGSNs listed in the "list of
downstream nodes" parameter of the corresponding MBMS Bearer Context. The BM-SC sets the state attribute
of its MBMS Bearer Context to 'Active'. The GGSN stores the session attributes in the MBMS Bearer Context,
sets the state attribute of its MBMS Bearer Context to 'Active' and sends a Session Start Response message to the
BM-SC.
2. The GGSN sends an MBMS Session Start Request message to the SGSNs listed in the "list of downstream
nodes" parameter of the corresponding MBMS Bearer Context. The SGSN stores the session attributes in the
MBMS Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active' and responds with an
MBMS Session Start Response message providing the TEID for bearer plane that the GGSN shall use for
forwarding the MBMS data.
3. The SGSN sends an MBMS Session Start Request message including the session attributes to each RNC that is
connected to this SGSN. The RNC responds with an MBMS Session Start Response to the SGSN. If the RNC
serves the MBMS Service Area it stores the session attributes in the MBMS Service Context, sets the state
attribute of its MBMS Service Context to 'Active' and responds with an MBMS Session Start Response message
and the RNC includes the TEID in the MBMS Session Start Response message for the Iu bearer plane that the
SGSN shall use for forwarding the MBMS data. An RNC receiving multiple MBMS Session Start Request
messages includes Iu bearer plane parameters only into one MBMS Session Start Response message to establish
only one Iu bearer plane to one SGSN.
4. The RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs.
NOTE: The upstream node normally provides the MBMS Session Start Request message once per MBMS
session to a downstream node. Due to "Intra Domain Connection of RAN Nodes to Multiple Core
Network Nodes" however, an RNC may receive the MBMS Session Start Request message from several
SGSNs.
8.4 MBMS Registration Procedure

The MBMS Registration is the procedure by which a downstream node informs an upstream node that it would like to
receive session attributes and data for a particular MBMS bearer service in order to distribute it further downstream.
This procedure builds up a distribution tree for the delivery of MBMS session attributes and data from the BM-SC to
the UEs interested in the service. This procedure results in the set-up of a corresponding MBMS Bearer Context in the
nodes along the distribution tree, but it does not result in the establishment of userbearer plane which will be established
by the Session Start procedure.
3GPP
Release 6 27 3GPP TS 23.246 V.6.0.0 (2003-09)
The MBMS Registration procedure is initiated:
- When the first MBMS UE Context for a particular MBMS bearer service is created in the SGSN or GGSN (see
subclause "MBMS UE Context") and the corresponding MBMS Bearer Context is not already established in the
node;
- When an MBMS Registration Request for a particular MBMS Service bearer service is received from a
downstream node but the corresponding MBMS Bearer Context is not established in the node; or
- When a DRNC detects that it hosts UEs interested in the MBMS bearer service (see subclause "RAN Resource
Setup).
NOTE: The terms 'downstream' and 'upstream' refer to the topological position of one node with respect to
another and relative to the direction of the MBMS data flow, i.e. from BM-SC to UE.
RNC SGSN GGSN BM-SC



Figure 9: MBMS Registration procedure
1. When the DRNC detects that it hosts UEs interested in the MBMS Servicebearer service, the DRNC sends a
MBMS Registration Request message to its parent SGSN if not already done (see subclause "RAN Resource
Setup"). How the RNC determines its parent SGSN is a matter of implementation.
2. If the SGSN has no MBMS Bearer Context for an MBMS Servicebearer service and the SGSN receives an
MBMS Registration Request from an RNC for this MBMS bearer service, or if the first MBMS UE Context is
created in the SGSN for an MBMS Servicebearer service for which the SGSN has no corresponding MBMS
Bearer Context, the SGSN creates an MBMS Bearer Context (in "Standby" state) and sends an MBMS
Registration request (IP multicast address, APN,) message to the GGSN. How the SGSN selects a GGSN is a
matter of implementation; it may for instance be based on prior signalling related to a particular UE or via APN
resolution.
3. If the GGSN has no MBMS Bearer Context for an MBMS bearer service and the GGSN receives an MBMS
Registration from an SGSN for this MBMS bearer service, or when the first MBMS UE Context is created in the
GGSN for an MBMS bearer service for which the GGSN has no MBMS Bearer Context, the GGSN sends a
Registration Request (IP multicast address, APN) message to the BM-SC. The exact nature of the signalling
4. Upon reception of an MBMS Registration Request from a GGSN, the BM-SC adds the identifier of the GGSN to
the "list of downstream nodes" parameter in its MBMS Bearer Context and responds with a MBMS Registration
Response message. The exact nature of the signalling between GGSN and BM-SC is however FFS in general. If
the MBMS Bearer Context is in the 'Active' state, the BM-SC initiates the Session Start procedure with the
GGSN, as described in Section 8.3.clause “MBMS Session Start Procedure”.
5. If the GGSN receives a Registration Request from the SGSN in step 2, the GGSN:
- adds the identifier of the SGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context,
3GPP
Release 6 28 3GPP TS 23.246 V.6.0.0 (2003-09)
- if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the SGSN, as
described in Section 8.3.clause “MBMS Session Start Procedure”.
6. If the SGSN received MBMS Registration Request from the DRNC in step 1, the SGSN:
- adds the identifier of the RNC to the "list of downstream nodes" parameter in its MBMS Bearer Context,
- if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the DRNC, as
described in Section 8.3clause “MBMS Session Start Procedure”.
8.5 MBMS Session Stop Procedure

The BM-SC initiates the MBMS Session Stop procedure when it considers the MBMS session to be terminated. The
session is typically terminated when there is no more MBMS data expected to be transmitted for a sufficiently long
period of time to justify a release of user bearer plane resources in the network. The procedure is propagated to all
SGSNs and GGSNs that are registered for the corresponding MBMS bearer service and to RNCs that have an
established Iu bearer plane with an SGSN.
The overall MBMS Session Stop procedure is presented in the following figure:

Figure 10: MBMS Session Stop procedure
1. The BM-SC sends a Session Stop Request message to all GGSNs listed in the "list of downstream nodes"
parameter of the affected MBMS Bearer Context to indicate that the MBMS session is terminated and the bearer
plane resources can be released. The BM-SC sets the state attribute of its MBMS Bearer Context to 'Standby'.
2. The GGSN sends an MBMS Session Stop Request message to all SGSNs listed in the "list of downstream
nodes" parameter of the affected MBMS Bearer Context, releases the corresponding bearer plane resources
towards these SGSNs and sets the state attribute of its MBMS Bearer Context to 'Standby'.
3. The SGSN releases the TEID and bearer plane resources on which it was receiving MBMS data from the GGSN
for the affected MBMS bearer service and sends an MBMS Session Stop Request message to all RNCs that have
a bearer plane established with the SGSN.
4. The RNC releases the affected radio and Iu resources.
8.6 MBMS De-Registration Procedure

The MBMS De-Registration is the procedure by which a downstream node informs an upstream node that it does not
need a to receive signalling, session attributes and data for a particular MBMS bearer service anymore and therefore
would like to be removed from the corresponding distribution tree.
3GPP
Release 6 29 3GPP TS 23.246 V.6.0.0 (2003-09)
The MBMS De-registration procedure is initiated:
- By the SGSN or GGSN when the last MBMS UE Context for a particular MBMS bearer service is deleted from
the node and the "list of downstream nodes" parameter in the corresponding MBMS Bearer Context is empty;
- By the SGSN or GGSN when the last node registered in the "list of downstream nodes" de-registers from an
MBMS bearer service for which there is no corresponding MBMS UE Context; or
- By the DRNC that registered at an SGSN when it deletes the associated MBMS Service Context.
RNC SGSN
A. MBMS Deregistration Request
A. MBMS Deregistration Response
SGSN GGSN
B. MBMS Deregistration Request
B. MBMS Deregistration Response
GGSN BM-SC
C. Deregistration Request
C. Deregistration Response
Figure 11: MBMS De-Registration Procedure
A. When the DRNC that is registered at an SGSN no longer hosts any UE interested in that MBMS bearer service,
the DRNC requests the de-registration from the MBMS bearer service to its parent SGSN. As an implementation
option, the RNC may decide not to de-register from the MBMS bearer service immediately when these
conditions are met, e.g. in order to avoid unnecessary signalling in the case where the RNC would again need the
same MBMS bearer service shortly after.
The SGSN removes the identifier of the RNC from the "list of downstream nodes" parameter of the affected
MBMS Bearer Context and confirms the operation by sending an MBMS De-Registration Response message to
the RNC. If an Iu bearer plane had been established between the RNC and the SGSN for this MBMS bearer
service, the Iu bearer plane is released.
B. When the "list of downstream nodes" of a particular MBMS Bearer Context in the SGSN becomes empty and
the SGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the SGSN sends an MBMS De-
Registration Request (IP multicast address, APN) message to its upstream GGSN.
The GGSN removes the identifier of the SGSN from the "list of downstream nodes" parameter of the affected
MBMS Bearer Context and confirms the operation by sending an MBMS De-Registration Response message to
the SGSN. . If a bearer plane had been established between the SGSN and the GGSN for this MBMS bearer
service, the bearer plane is released.
C. When the "list of downstream nodes" of a particular MBMS Bearer Context in the GGSN becomes empty and
the GGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the GGSN sends a De-Registration
Request (IP multicast address, APN) message to the BM-SC. The exact nature of the signalling between GGSN
and BM-SC is however FFS in general. If a bearer plane had been established over Gi for this MBMS bearer
service, the bearer plane is released.
3GPP
Release 6 30 3GPP TS 23.246 V.6.0.0 (2003-09)
The BM-SC removes the identifier of the GGSN from the "list of downstream nodes" parameter of the affected
MBMS Bearer Context and confirms the operation by sending a De-Registration Response message to the
GGSN.
8.6.1 BM-SC initiated MBMS De-Registration Procedure

This MBMS De-Registration Procedure is initiated by BM-SC when the specific MBMS bearer service is terminated.
This procedure tears down the distribution tree for the delivery of session attributes and MBMS data. This procedure
results in releasing of all MBMS Bearer Contexts and associated MBMS UE Contexts in the nodes along the
distribution tree.
1. Deregistration Request
1. Deregistration Response
2. MBMS Deregistration Request
2. MBMS Deregistration Response
Figure 12: BM-SC initiated MBMS De-Registration Procedure
1. The BM-SC sends a De-Registration Request message to all GGSNs contained in the "list of downstream nodes"
parameter of the corresponding MBMS Bearer Context to indicate the session is terminated and any related
MBMS bearer resources shall be released.
The GGSN returns a De-Registration Response message to the BM-SC. The BM-SC releases all MBMS UE
Contexts and removes the identifier of the GGSN from the "list of downstream nodes" parameter of the
corresponding MBMS Bearer context.
2. The GGSN sends an MBMS De-Registration Request message to all SGSNs contained in the "list of
downstream nodes" parameter. of the corresponding MBMS Bearer Context. The SGSN returns an MBMS De-
registration Response message to the GGSN. The GGSN releases all MBMS UE Contexts and the affected
MBMS Bearer Context. If a bearer plane had been established over Gi for this MBMS bearer service, the bearer
plane is released.
3. The SGSN sends an MBMS De-Registration Request message to all RNCs listed in the "list of downstream
nodes" parameter of the corresponding MBMS Bearer Context. The RNC returns an MBMS De-Registration
Response message to the SGSN. The SGSN releases all MBMS UE Contexts and the affected MBMS Bearer
Context. If a bearer plane had been established between the SGSN and the GGSN for this MBMS bearer service,
the bearer plane is released.
4. 4 If the state attribute of the MBMS Bearer Context is 'Active' the SGSN sends an MBMS Session Stop
Request message to all RNCs that have a bearer plane established with the SGSN. The RNC releases all bearer
resources and returns an MBMS Session Stop Response message to the SGSN.
3GPP
Release 6 31 3GPP TS 23.246 V.6.0.0 (2003-09)
5. The RNC releases the affected radio resources and the MBMS Service Context.. The detailed procedures are
FFS depending on ongoing work in RAN groups. RAN may notify the UEs that the MBMS Bearer service has
being terminated, so that the UE can locally deactivate its MBMS UE context, detailed procedures are FFS.
8.7 MBMS Multicast Service Deactivation

The multicast service deactivation is a signalling procedure between the UE and the network. The procedure removes
the MBMS UE Context from the UE, SGSN and GGSN for a particular MBMS multicast service. The multicast service
deactivation can be initiated by:
- The UE;
- The BM-SC; or
- The SGSN
All these cases are contained in the procedure illustrated in figure 13. The UE initiated Multicast Service Deactivation
starts with step 1), the BM-SC initiated Multicast Service Deactivation starts with step 3) and the SGSN initiated
Multicast Service Deactivation starts with step 5) or 8).
1. IGMP Leave
2. Leave Indication
3. UE Removal Request
4. MBMS UE Context Deactivation Request
4. MBMS UE Context Deactivation Response

5. Deactivate MBMS Context Request
6. Deactivate MBMS Context Accept
8. Delete MBMS Context Request

9. Deactivation Indication
9. Deactivation Confirmation
10. MBMS Deregistration Respons
11. Delete MBMS Context Response
Figure 13: MBMS Multicast Service Deactivation
1. The UE sends an IGMP (IPv4) or MLD (IPv6) Leave message over the default PDP context to leave a particular
multicast service identified by an IP multicast address.
3GPP
Release 6 32 3GPP TS 23.246 V.6.0.0 (2003-09)
2. The GGSN sends a Leave Indication (IP multicast address, IMSI) to the BM-SC, indicating that the UE is
requesting to leave the multicast service identified by the IP multicast address. The exact nature of the signalling
3. Upon reception of the Leave Indication, the BM-SC verifies that the IP multicast address corresponds to a valid
MBMS bearer service and sends a UE Removal Request (IP multicast address, APN, IMSI) to the GGSN that
originated the Leave Indication. The APN shall be the same that was provided during service activation (see
"MBMS Multicast Service Activation"). The exact nature of the signalling between GGSN and BM-SC is
however FFS in general. The BM-SC may also initiate the deactivation of an MBMS UE Context for service-
specific reasons (e.g. the service is terminated but the UE has not yet left the multicast group) by directly sending
a UE Removal Request message to the GGSN.
4. The GGSN sends an MBMS UE Context Deactivation Request (IP multicast address, APN, IMSI) to the SGSN.
The IP multicast address, APN and IMSI together identify the MBMS UE Context to be deleted by the SGSN.
The APN is the one received in step 3. The SGSN acknowledges reception of the MBMS UE Context
Deactivation Request by sending an MBMS UE Context Deactivation Response to the GGSN.
5. Upon reception of the MBMS UE Context Deactivation Request or for other reasons (e.g. due to a change in the
roaming restrictions for the user) the SGSN sends a Deactivate MBMS Context Request (TI) to the UE. The TI
identifies the MBMS UE Context to be deleted by the UE.
6. The UE deletes the MBMS UE Context and sends a Deactivate MBMS Context Accept (TI) to the SGSN.
7. If dedicated radio resources are currently assigned to the UE for the reception of the MBMS data, the RAN
releases these radio resources. If shared radio resources are currently assigned for the distribution of the MBMS
data, the RAN may decide to move the remaining UEs to dedicated resources. The detailed procedures and
conditions are FFS depending on ongoing work in RAN groups.
8. Upon reception of the Deactivate MBMS Context Accept or for other reasons (e.g. due to missing periodic
updates) the SGSN sends a Delete MBMS Context Request (NSAPI) to the GGSN that holds the MBMS UE
Context.
9. The GGSN deletes the MBMS UE Context and sends a Deactivation Indication to the BM-SC to confirm the
successful deactivation of the MBMS UE Context. The BM-SC, after receiving the Deactivation Indication,
deletes the MBMS UE Context and sends a confirmation to the GGSN. The exact nature of the signalling
10. If the GGSN does not have any more users interested in this MBMS multicastbearer service and the "list of
downstream nodes" in the corresponding MBSM Bearer Context is empty, the GGSN sends a MBMS De-
Registration Request to the BM-SC. The BM-SC responds with a MBMS De-Registration Response and
removes the identifier of the GGSN from the "list of downstream nodes" parameter in its MBMS Bearer
Context. See subclause "MBMS De-Registration Procedure".
11. The GGSN confirms the deactivation of the MBMS UE Context to the SGSN by sending a Delete MBMS
Context Response to the SGSN, which then deletes the MBMS UE Context.
12. If the SGSN does not have any more users interested in this MBMS multicastbearer service and the "list of
downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS De-
Registration Request to the GGSN. The GGSN responds with an MBMS De-Registration Response and removes
the identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context. See
subclause "MBMS De-Registration Procedure".
8.8 Iu Bearer Plane release procedure

A RNC triggers the Iu Bearer Plane release procedure if the RNC has no further use for the userbearer plane (i.e. no
UEs left in the coverage area of the RNC or session stop) (hysterisis mechanisms can be used in the RNC to avoid
continuous Bearer plane establishments and releases).
3GPP
Release 6 33 3GPP TS 23.246 V.6.0.0 (2003-09)
8.9 RAN Resource Setup

Editor's note: The content of this subclause is dependent on ongoing work in RAN groups. The main focus of this
section should be on the externally observable behaviour of the RAN (as seen from the Iu interface) and
aspects that have direct impact on CN procedures. This subclause should in particular describe which of
the SRNC, DRNC or CRNC is responsible for MBMS data distribution depending on whether ptp or ptm
distribution has been selected.]
8.10 Inter SGSN Routeing Area Update

This procedure is performed when a UE with active MBMS bearer service performs a Routeing Area Update and the
serving SGSN changes. It bases on the Inter SGSN Routeing Area Update procedure specified in TS 23.060. The
procedure is performed regardless whether MBMS sessions are ongoing or not. The handling of any PDP contexts
established by the UE is not changed compared to the procedure without MBMS. The procedure described below does
not show all details of the Routeing Area update procedure. Only for the MBMS specific additions the steps are
described.
3GPP
Release 6 34 3GPP TS 23.246 V.6.0.0 (2003-09)
UE RAN new SGSN old SGSN GGSN HLR
1. Routeing Area Update Request

2. SGSN Context Request
2. SGSN Context Response

4. SGSN Context Acknowledge
5. Forward Packets
6. Update PDP Context Request

6. Update PDP Context Response
7. Update MBMS UE Context Request
7. Update MBMS UE Context Response
8. Update Location
9. Cancel Location
9. Cancel Location Ack
10. Insert Subscriber Data
10. Insert Subscriber Data Ack
11. Update Location Ack
14. Routeing Area Update Accept
15. Routeing Area Update Complete
Figure 14: Inter SGSN Routeing Area Update
2) The context transfer in step 2 includes the transfer of the MBMS UE Context(s).
7) The new SGSN sends Update MBMS UE Context Request to the GGSNs concerned. The GGSNs update their
MBMS UE Context fields and return Update MBMS UE Context Response.
12) If the old SGSN does not have any more MBMS UE Contexts for the MBMS multicastbearer service(s) and the
"list of downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS
Deregistration Request to the GGSN. The GGSN responds with an MBMS Deregistration Response and removes
the identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context. See
subclause "MBMS Deregistration Procedure".
13) The new SGSN verifies for each MBMS UE Context received whether it has a corresponding MBMS Bearer
Context. For each MBMS Bearer Context the SGSN does not already have the SGSN creates an MBMS Bearer
Context (in "Standby" state) and sends an MBMS Registration Request to a GGSN. This registration is described
in subclause "MBMS Registration Procedure".
3GPP
Release 6 35 3GPP TS 23.246 V.6.0.0 (2003-09)
8.11 Inter SGSN Serving RNS Relocation Procedure

This procedure is performed when the SGSN changes due to SRNS relocation. It bases on the SRNS Relocation
procedure specified in TS 23.060. The procedure is performed regardless whether MBMS sessions are ongoing or not.
The handling of any PDP contexts established by the UE is not changed compared to the procedure without MBMS.
The procedure described below does not show all details of the SRNS relocation procedure. Only for the MBMS
specific additions the steps are described.
MS Source Target Old New GGSN

RNC RNC SGSN SGSN
1. Decision to perform
SRNS relocation
2. Relocation Required
3. Forward Relocation Request
4. Relocation Request
Establishment of Radio Access Bearers
4. Relocation Request Acknowledge
5. Forward Relocation Response
C1
6. Relocation Command
7. Forwarding of data
8. Relocation Commit
9. Relocation Detect
10. RAN Mobility Information
10. RAN Mobility Information Confirm
11. Relocation Complete

12. Forward Relocation Complete
12. Forward Relocation Complete Acknowledge
13. Update PDP Context Request

15. Iu Release Command
15. Iu Release Complete 13. Update PDP Context Response
17. Update MBMS UE Context Request
17. Update MBMS UE Context Response
18. Routing Area Update C2
C3
Figure 15: SRNS Relocation Procedure
3) The context transfer in step 3 includes the transfer of the MBMS UE Context(s).
3GPP
Release 6 36 3GPP TS 23.246 V.6.0.0 (2003-09)
14) The new SGSN verifies for each MBMS UE Context received whether it has a corresponding MBMS Bearer
Context. For each MBMS Bearer Context not yet existing in the SGSN the SGSN creates an MBMS Bearer
Context (in "Standby" state) and sends an MBMS Registration Request to a GGSN. This registration is described
in subclause "MBMS Registration Procedure".
16) If the old SGSN does not have any more MBMS UE Contexts for this MBMS multicastbearer service and the
"list of downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS
De-registration Request to the GGSN. The GGSN responds with an MBMS De-registration Response and
removes the identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context.
See subclause "MBMS De-registration Procedure".
17) The new SGSN sends Update MBMS UE Context Request to the GGSNs concerned. The GGSNs update their
MBMS UE Context fields and return Update MBMS UE Context Response.
8.12 MBMS Broadcast Service Activation

MBMS Broadcast service activation is the procedure by which a UE locally activates a broadcast MBMS bearer
service:
- The MBMS broadcast service activation procedure does not register the user in the network. There is no MBMS
bearer service specific signaling exchanged between the UE and the Network;
- The broadcast service activation procedure does not establish MBMS UE contexts in UE, SGSN and GGSN.
8.13 MBMS Broadcast service de-activation

The MBMS Broadcast service de-activation by the UE is local to the UE, i.e. without interaction with the Network.
8.14 MBMS Broadcast Session Start Procedure

necessary bearer resources in the network for the transfer of MBMS data. It is FFS whether it is also used to notify
interested UEs of the start of the transmission.
Through this procedure, MBMS session attributes such as QoS, BroadcastMBMS service Area (tracking/non-tracking
area are FFS) are provided to all the GGSN(s), SGSN(s) and RNCs. In addition the procedure allocates the bearer plane
to all GGSNs and all SGSNs and to RNCs that respond to the MBMS session start accordingly.
The overall MBMS Broadcast Session Start procedure is presented in the following figure:


Figure 16: Session Start procedure for MBMS Broadcast MBMS Bearer Service
3GPP
Release 6 37 3GPP TS 23.246 V.6.0.0 (2003-09)
1) The BM-SC sends a Session Start Request message the impending start of the transmission and to provide the
MBMS session attributes (QoS, BroadcastMBMS service Area…) to a GGSNs GGSN of the PLMN. The BM-
SC sets the state attribute of its MBMS Bearer Context to 'Active'. The GGSN creates a MBMS Bearer Context,
stores the session attributes, sets the state attribute of this MBMS Bearer Context to 'Active' and sends a Session
Start Response message to the BM-SC.
2) The GGSN sends an MBMS Session Start Request message to all its SGSNs. The SGSN creates a MBMS
Bearer Context, stores the session attributes, sets the state attribute of this MBMS Bearer Context to 'Active' and
responds with an MBMS Session Start Response message providing the TEID for bearer plane that the GGSN
shall use for forwarding the MBMS data.
3) The SGSN sends an MBMS Session Start Request message including the session attributes to each RNCs that is
connected to this SGSN. The RNC responds with an MBMS Session Start Response message to the SGSN. If the
RNC serves the MBMS Broadcastservice Area, it creates a MBMS Bearer Context, stores the session attributes
in this MBMS Service Context, sets the state attribute of its MBMS Service Context to 'Active' and responds
with an MBMS Session Start Response message, and the RNC includes the TEID in the MBMS Session Start
Response message for the Iu bearer plane that the SGSN shall use for forwarding the MBMS data. An RNC
receiving multiple MBMS Session Start Request messages from different SGSNs includes Iu bearer plane
parameters only into one MBMS Session Start Response message to establish only one Iu bearer plane to one
SGSN.
4) The RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs.
NOTE: The upstream node normally provides the MBMS Session Start Request message once per MBMS
session to a downstream node. Due to "Intra Domain Connection of RAN Nodes to Multiple Core
Network Nodes" however, an RNC may receive the MBMS Session Start Request message from several
SGSNs.
9 Security
- A SIM or USIM shall be present in the UE to receive MBMS multicast services.
- MBMS multicast data transmission to the UEs shall be secured.
- MBMS security shall be provided by encryption and integrity protection between the UE and the BM-SC.
- The BM-SC shall be able to authenticate and authorize each MBMS content provider.
- The integrity of MBMS data received from the content provider shall be guaranteed.
10 Charging requirement
MBMS architecture shall support on-line and off-line charging.
It shall be possible to collect charging information for the multicast mode. It shall also be possible to collect charging
information for MBMS services in visited networks.
MBMS shall collect charging information about the transmission of MBMS broadcast or multicast data that are
provided by content or service providers (e.g. 3rd parties). This shall enable billing of broadcast and multicast content or
service providers.
To enable billing of broadcast and multicast content providers, data shall be collected at the BM-SC.
NOTE: SGSN, GGSN and BM-SC generate charging data for the transmitted data, always under the assumption
that the UEs are within the MBMS service area. If the MulticastMBMS service area is less than the
PLMN, then there is the possibility that a UE will have moved outside the MulticastMBMS service area.
Charging data will still be generated for that UE causing an inaccuracy in the data. This inaccuracy
increases as the size of the MulticastMBMS service area is decreased.
3GPP
Release 6 38 3GPP TS 23.246 V.6.0.0 (2003-09)
Annex A (Informative):
Information flows
A.1 General information flow
3GPP
Release 6 39 3GPP TS 23.246 V.6.0.0 (2003-09)
Annex B (Informative):
Change history
Change history
Date TSG # TSG Doc. CR Rev Subject/Comment Old New
2002-06 First Version 0.0.0
2002-09 Output from SA2 #27, inclusion of S2-023072 0.1.0
2002-11 Output from SA2 #28, inclusion of S2-023591, S2-023592, S2- 0.1.0 0.2.0
023593, S2-023594, S2-023595, S2-023596 +S2-022967 From
SA2#17
2002-12 Addition of official TS number 0.2.0 0.2.1
2003-02 Output from SA2#29 and e-mail approval: S2-030382, S2-030284, 0.2.1 0.3.0
S2-030385rev4, S2-030386r1, S2-030387
2003-02 Output from SA#30, inclusion of S2-030626, S2-030647 an S2- 0.3.0 0.4.0
030651
2003-04 Output from SA2#31, inclusion of S2-031236, S2-031238, S2- 0.4.0 0.5.0
031237r2
Output from SA2#32, inclusion of S2-031843, S2-031844, S2- 0.5.0 0.6.0
031845, S2-031849, S2-031850, S2-032118, S2-032119
Presentation to SA for information 0.6.0 1.0.0
Output from SA2#33, inclusion of S2-031231, S2-032410, S2- 1.0.0 1.1.0
032412, S2-032417, S2-032419, S2-032425,S2-032426
2003-08 Output from SA2#34, inclusion of S2-032889, S2-032894, S2- 1.1.0 1.2.0
032896, S2-032898, S2-032904, S2-033143, S2-033144, S2-
033145, S2-033147, S2-033148, S2-033149, S2-033150
2003-08 Editorial correction (S2-033148 was incorrectly added) + Other 1.2.0 1.2.1
Minor editorials (change bars from V 1.2.0 still retained)
2003-09 Presentation to SA for Approval 1.2.1 2.0.0
2003-09 SA#21 SP-030390 Raised to v.6.0.0 after approval at SA#21 2.0.0 6.0.0
3GPP
CR-Form-v7
CHANGE REQUEST
2 6.0.0
Title: ! Clarification on MBMS deactivation figure
Source: ! Samsung, Huawei, Siemens

Rel-6 (Release 6)
Reason for change: ! It is agreed to calrify in section 8.7 that a GGSN holding an UE’s MBMS UE context may
be different than the GGSN holding the UE’s PDP context.
TS 23.246 also does not clarify the handling of a UE’s MBMS bearer services when a UE
detaches. This should be aligned with GPRS bearer handling. PDP contexts in SGSN and
GGSN are implicitly deactivated at PS detach.
“Linked NSAPI” was agreed to be removed in last Bangkok meeting, which impacts how
UE identies the MBMS UE Contexts that it wants to deactivate, therefore these should
also be clarified.
Summary of change: ! Figure 13 as well as step 8 is modified for clarification. Implicit deactivation of MBMS
bearers at UE detach.
Consequences if ! Misunderstanding of MBMS deactivation procedure and misalignment with MBMS

not approved: activation procedure.
Y N
Other comments: !
CR page 1
are closest to.
CR page 2
8.7 MBMS Multicast Service Deactivation
The multicast service deactivation is a signalling procedure between the UE and the network. The
procedure removes the MBMS UE Context from the UE, SGSN and GGSN for a particular MBMS
multicast service. The multicast service deactivation can be initiated by:
- The UE;
- The GGSN;
- The BM-SC; or
- The SGSN
All these cases are contained in the procedure illustrated in figure 13. The UE initiated Multicast
Service Deactivation starts with step 1), the BM-SC initiated Multicast Service Deactivation starts with
step 3), the GGSN initiated Multicast Service Deactivation starts with step 4), and the SGSN initiated
Multicast Service Deactivation starts with step 5) or 8).
At GPRS detach, all MBMS UE contexts of the UE are implicitly deactivated in the UE, SGSN and
GGSN, i.e. the SGSN performs the deactivation procedure starting with step 8).
CR page 3
1. IGMP Leave
2. Leave Indication


10. MBMS Deregistration Respons
CR page 4
1. IGMP Leave
2. Leave Indication

GGSN

Figure 13: MBMS Multicast Service Deactivation
1. The UE sends an IGMP (IPv4) or MLD (IPv6) Leave message over the default PDP context to
leave a particular multicast service identified by an IP multicast address.
2. The GGSN sends a Leave Indication (IP multicast address, IMSI) to the BM-SC, indicating that
the UE is requesting to leave the multicast service identified by the IP multicast address. The
exact nature of the signalling between GGSN and BM-SC is however FFS in general.
3. Upon reception of the Leave Indication, the BM-SC verifies that the IP multicast address
corresponds to a valid MBMS bearer service and sends a UE Removal Request (IP multicast
address, APN, IMSI) to the GGSN that originated the Leave Indication. The APN shall be the
same that was provided during service activation (see "MBMS Multicast Service Activation").
The exact nature of the signalling between GGSN and BM-SC is however FFS in general. The
BM-SC may also initiate the deactivation of an MBMS UE Context for service-specific reasons
(e.g. the service is terminated but the UE has not yet left the multicast group) by directly
sending a UE Removal Request message to the GGSN.
CR page 5
4. Upon reception of the UE Removal Request or for other reasons (e.g. Error cases), Tthe GGSN
sends an MBMS UE Context Deactivation Request (IP multicast address, APN, IMSI) to the
SGSN. The IP multicast address, APN and IMSI together identify the MBMS UE Context to be
deleted by the SGSN. The APN is the one received in step 3. The SGSN acknowledges
reception of the MBMS UE Context Deactivation Request by sending an MBMS UE Context
Deactivation Response to the GGSN.
5. Upon reception of the MBMS UE Context Deactivation Request or for other reasons (e.g. due to
a change in the roaming restrictions for the user) the SGSN sends a Deactivate MBMS Context
Request (TI) to the UE. The TI identifies the MBMS UE Context to be deleted by the UE.
6. The UE deletes the MBMS UE Context and sends a Deactivate MBMS Context Accept (TI) to
the SGSN.
7. If dedicated radio resources are currently assigned to the UE for the reception of the MBMS
data, the RAN releases these radio resources. If shared radio resources are currently assigned for
the distribution of the MBMS data, the RAN may decide to move the remaining UEs to
dedicated resources. The detailed procedures and conditions are FFS depending on ongoing
work in RAN groups.
8. Upon reception of the Deactivate MBMS Context Accept or for other reasons (e.g. due to
missing periodic updates) the SGSN sends a Delete MBMS Context Request (NSAPI) to the
GGSN that holds the MBMS UE Context. This GGSN may be different from the GGSN that
receives IGMP Leave request in step 1.
9. The GGSN deletes the MBMS UE Context and sends a Deactivation Indication to the BM-SC
to confirm the successful deactivation of the MBMS UE Context. The BM-SC, after receiving
the Deactivation Indication, deletes the MBMS UE Context and sends a confirmation to the
GGSN. The exact nature of the signalling between GGSN and BM-SC is however FFS in
general.
10. If the GGSN does not have any more users interested in this MBMS multicast bearer service
and the "list of downstream nodes" in the corresponding MBSM Bearer Context is empty, the
GGSN sends a MBMS De-Registration Request to the BM-SC. The BM-SC responds with a
MBMS De-Registration Response and removes the identifier of the GGSN from the "list of
downstream nodes" parameter in its MBMS Bearer Context. See subclause "MBMS De-
Registration Procedure".
11. The GGSN confirms the deactivation of the MBMS UE Context to the SGSN by sending a
Delete MBMS Context Response to the SGSN, which then deletes the MBMS UE Context.
12. If the SGSN does not have any more users interested in this MBMS multicastbearer service and
the "list of downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN
sends an MBMS De-Registration Request to the GGSN. The GGSN responds with an MBMS
De-Registration Response and removes the identifier of the SGSN from the "list of downstream
nodes" parameter in its MBMS Bearer Context. See subclause "MBMS De-Registration
Procedure".
CR page 6
CR page 7
New York, USA, 24-29 November 2003 rev of S2-033983, S2-033856
CR-Form-v7
CHANGE REQUEST
2 6.0.0
Title: ! MBMS Service Request Procedure
Source: ! Samsung, Nortel Networks, Alcatel

Rel-6 (Release 6)
Reason for change: ! RAN2 LS (S2-033325, R2-032282) indicates that “if the UTRAN wants to count
the number of users that are interested in a specific MBMS service present in a
cell, it will request some of the concerning UEs to transit to PMM-CONNECTED
state.”
Also CN1 LS S2-033904 (N1-031606) indicates that Service Request procedure
could be reused (with some changes under investigation) to allow the UE to
inform the CN that it needs to transmit to PMM-Connected state on request of the
UTRAN for MBMS counting purposes.
The current TS needs to be updated to show this use of Service Request
procedure.
Futhermore, in order to count the UEs, “MBMS UE Context” of PMM-

CONNECTED UEs (indicating the list of MBMS services) need to be known in
RNC. This is already described in the TS in section “6.1 MBMS UE Context” in UE
Link description, but one case highlighted in RAN3 LS (R2-032282) is missing. LS
S2-033327(R3-031240) informs that MBMS UE Context (UE Link) has also to be
provided to UTRAN when the UE moves to PMM CONNECTED state for the
purpose of MBMS when an MBMS session is active. The current TS needs to be
updated to add this case.
It is also proposed to add a new section to clarify the way “UE Linking” is done
instead of keeping just a slight description of it in section 6.1 which is dedicated to
“MBMS UE Context” element description.
Summary of change: ! A clarification of UE linking procedure is captured in 6.1 and a new section 8.15 is
added to fully describe the UE linking procedure. Also a new clause 8.16 is
introduced to incorporate a “Service Request Procedure” tailored to the MBMS
feature.
CR page 1
Consequences if ! PMM-IDLE state UEs will be unable to move to PMM-CONNECTED state for
not approved: MBMS purpose and will not be counted by the UTRAN.
Clauses affected: ! 6.1, new 8.15 and new 8.16
Y N
Other specs ! Other core specifications !
affected: Test specifications
O&M Specifications
Other comments: !

closest to.
the change request.
CR page 2
6.1 MBMS UE Context

The MBMS UE Context contains UE-specific information related to a particular MBMS bearer service that the UE has
joined. An MBMS UE Context is created in the UE, SGSN and GGSN when the UE joins an MBMS bearer service. In
the SGSN, an MBMS UE Context is also created as a result of an inter-SGSN routing area update after the transfer of
the MBMS UE Context from the old SGSN. It is FFS whether MBMS UE Contexts are created in the BM-SC.
In Iu mode, aAll MBMS UE Contexts of a UE (referenced as "UE Link" in RNC) are provided via MBMS UE
dedicated Iu procedure(s)Linking mechanism to the BSC/SRNC at least when the first PS RAB is established for the
UE, or when the UE performs MBMS Multicast Service Activation. MBMS UE Contexts are provided to the
BSC/SRNC regardless whether MBMS Sessions are ongoing or not (i.e. before, between and after Sessions). In
addition, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism when a UE, which has an
MBMS context active, moves to PMM-Connected state via the MBMS Service Request procedure for the purpose of
MBMS.
----------------------------------- Next changes --------------------------------------------------
8.15 MBMS UE Linking mechanism

UE Linking is the process by which UE MBMS context(s) is (are) provided to RAN.
MBMS UE linking procedure is performed when the UE is PMM-CONNECTED at least in the following cases.
- When a UE which has joined MBMS is moved to the PMM CONNECTED state and sets up a PS RAB. This
may happen at any point in time i.e. before, during and between Sessions.
- When a UE joins the service and is in the PMM CONNECTED state due to an existing PS RAB. This may
happen at any point in time i.e. before, during and between Sessions.
- When a UE is moved to the PMM CONNECTED state only for MBMS purpose via Service Request procedure.
This may happen at any point in time during a MBMS session.
The UE linking is performed to link a specific UE to an MBMS service. It provides the list of MBMS Service Ids
activated by the UE to the SRNC. If no MBMS service context related to the MBMS service Id exists then SRNC
creates an MBMS service context after this procedure.
8.16 MBMS Service Request Procedure

For MBMS, when UTRAN wants to count the number of users that are interested in a specific MBMS service present in
a cell, it will request a percentage of the interested UEs to transit to PMM-CONNECTED state. The MBMS Service
Request procedure is used by a UE in PMM-IDLE state to move to PMM-CONNECTED state.
CR page 3
UE RNC SGSN HLR

1. RRC Connection Request
1. RRC Connection Setup
2. Service Request
4. MBMS UE Linking Request
4. MBMS UE Linking Response
5. MBMS RAN Resource

Setup
Figure x: MBMS Service Request procedure
2) The UE sends a Service Request message to the SGSN if required to do so by the RAN after a MBMS Session
Starts.
3) The SGSN may perform the security functions.
4) The SGSN provides RAN with the MBMS UE context(s) via MBMS UE Linking procedure
5) The RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs.
CR page 4
3GPP TS 23.246 v6.0.0 (2003-09)
3GPP TSG-SA2 Meeting #36 Tdoc !S2- 033984

New-York, USA, 24 th – 28th November 2003
CR-Form-v7
CHANGE REQUEST
- 6.0.0
Proposed change affects: UICC apps! ME Radio Access Network Core Network X
Title: ! Removal of BG from MBMS Architecture Figure
Source: ! Bamboo MediaCasting Ltd.

Rel-6 (Release 6)
Reason for change: ! TS 23.246 has been approved with the MBMS architecture figure presenting an
entity named “BG” as being connected to the GGSN via a Gi interface. No
description as to the purpose and functions of the BG are found in the TS.
At present the BG does not seem to provide any additional benefit to the MBMS
architecture.
Summary of change: ! The BG entity is removed from the MBMS architectural figure in section 4.2.
Consequences if ! Architectural figure remains unclear with regards to the presence of an

not approved: undescribed entity.
Y N
Other comments: !

closest to.
CR page 1
3GPP TS 23.246 v6.0.0 (2003-09)
the change request.
CR page 2
3GPP TS 23.246 v6.0.0 (2003-09)
4.2 Reference Architecture Model
PDN
Content (e.g. Internet)
CBC Provider
HLR CSE
Gr OSA
SCS
Gmb Content
Uu Iu Gn/Gp Provider /
Multicast
UE UTRAN SGSN GGSN BM-SC Broadcast
Source
Gi
Iu/Gb
Multicast
Um Gi Broadcast
Source
UE GERAN
Content
CBC Provider
PDN
(e.g. Internet)
OSA
SCS
Content
HLR CSE BM-SC Provider
Gmb
Gr
Gi
Uu Iu Gn/Gp Gi Gi Multicast
UE UTRAN SGSN GGSN BG Broadcast
Source
Gi
Iu/Gb
Multicast
Um Broadcast
Source
UE GERAN
3GPP
3GPP TS 23.246 v6.0.0 (2003-09)
Note: dotted lines means functions / reference points that are FFS. Gp applies only when SGSN and GGSN are
in different PLMN.
Figure 1: Reference architecture to support MBMS
3GPP
3GPP TS 23.246 v6.0.0 (2003-09)

New York, US 24th – 28th November 2003
CR-Form-v7
CHANGE REQUEST
6.0.0
Proposed change affects: UICC apps! X ME X Radio Access Network X Core Network X
Title: ! Removal of security information in TS 23.246
Source: ! 3

Rel-6 (Release 6)
Reason for change: ! TS 23.246 was approved at SA#21 with the understanding that the security for
MBMS is described in 33.246. Hence security information in 23.246 should be
removed and a reference to 33.246 added.
Summary of change: ! New reference added, removal of security information and reference made to
33.246
Consequences if ! Current requirements in TS 23.246 contradict 33.246.

not approved:
Clauses affected: ! 2,9
Y N
Other comments: !

closest to.
CR page 1
3GPP TS 23.246 v6.0.0 (2003-09)
the change request.
CR page 2
3GPP TS 23.246 v6.0.0 (2003-09)
*******************First Change**********************
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1".
[3] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture".
[4] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting
packet based services and Packet Data Networks (PDN)".
[5] 3GPP TS 33.246: “Security of Multimedia Broadcast/Multicast Service”
*******************Second Change**********************
9 Security
- Security of MBMS is found in 3GPP TS 33.246 [5]
A SIM or USIM shall be present in the UE to receive MBMS multicast services.
- MBMS multicast data transmission to the UEs shall be secured.
- MBMS security shall be provided by encryption and integrity protection between the UE and the BM-SC.
-The BM-SC shall be able to authenticate and authorize each MBMS content provider.
-- The integrity of MBMS data received from the content provider shall be guaranteed.
3GPP

SP 030660

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SP 030660

Uploaded by

Copyright:

Available Formats

Technical Specification Group Services and System Aspects TSGS#22(03)0660

Meeting #22, Maui, Hawaii, USA, 15-18 December 2003

Source: TSG SA WG2

Tdoc # Title Spec CR # cat Versio REL WI S2 Clauses affected

Title: ! Inclusion of GERAN attributes and parameters in MBMS

Work item code: ! MBMS Date: ! 25/11/03

Category: ! C Release: ! Rel-6

Consequences if ! MBMS procedures will not address GERAN functionality.

Clauses affected: ! 6.2, 6.3.1

How to create CRs using this form:

Title: ! Inclusion of GERAN functionality in MBMS Notification procedure and session ID

Work item code: ! MBMS Date: ! 25/11/2003

Category: ! C Release: ! Rel-6

Consequences if ! MBMS Notification procedures will not address GERAN functionality.

Clauses affected: ! 8.1, 8.1.1 (new), 8.1.2 (new)

How to create CRs using this form:

8.1 MBMS Notification

GERAN functionality is FFS.

8.1.2 A/Gb mode notification (GERAN)

Title: ! Inclusion of GERAN functionality in MBMS procedures

Work item code: ! MBMS Date: ! 25/11/2003

Category: ! C Release: ! Rel-6

Consequences if ! MBMS procedures will not address GERAN functionality.

Clauses affected: ! 8.2, 8.3, 8.5, 8.14

How to create CRs using this form:

The overall Session Start procedure is presented in the following figure:

UE RNC SGSN GGSN BM-SC

1. Session Start Request

1. Session Start Response

2. MBMS Session Start Response

3. MBMS Session Start Request

3. MBMS Session Start Response

4. RAN Resource Setup

UE BSC/RNC SGSN GGSN BM-SC

1. Session Start Request

1. Session Start Response

2. MBMS Session Start Response

3. MBMS Session Start Request

3. MBMS Session Start Response

4. RAN Resource Setup

Figure 8 Session Start procedure

UE RNC SGSN GGSN BM-SC

1. Session Stop Request

1. Session Stop Response

2. MBMS Session Stop Response

3. MBMS Session Stop Request

3. MBMS Session Stop Response

4. RAN Resource Release

UE BSC/RNC SGSN GGSN BM-SC

1. Session Stop Request

1. Session Stop Response

2. MBMS Session Stop Response

3. MBMS Session Stop Request

3. MBMS Session Stop Response

4. RAN Resource Release

Figure 10 MBMS Session Stop procedure

UE RNC SGSN GGSN BM-SC

1. Session Start Request

1. Session Start Response.

2. MBMS Session Start Response.

3. MBMS Session Start Request

4. RAN Resource Setup

UE BSC/RNC SGSN GGSN BM-SC