Hi There,

Why PGW is omitted from the eMBMS delivery ?
Can MBMS-GW bypass SGW and deliver the RTP directly to UE ? Then how the SGW Funtionality is compensated in case of a S1-Based HO ?

Kumar!
[Q1] Why PGW is omitted from the eMBMS delivery ?
-->
[A] The figure is the case that eMBMS packets are delivered to UEs using IP multicast over a MBMS bearer. If the packets are delivered using IP unicast, then EPS bearers are used and P-GW will be involved in the delivery.

[Q2] Can MBMS-GW bypass SGW and deliver the RTP directly to UE ? Then how the SGW Funtionality is compensated in case of a S1-Based HO ?
-->
[A] For EPS, there are only MBMS bearer contexts and no MBMS UE context in MBMS-GW.
Therefore, for UEs using MBMS bearer (RPs: LTE-Uu(MTCH)

유익한 자료 너무 감사드립니다..

Hi,

I have a doubt about the protocol stack for the data plane for the Live TV feed case (orange flows)
please confirm me if I am correct with my guesses, which i write down below.

Lets say that the service announcement function from the BM-SC sends an announcement to the users with the SDP that includes the next parameters: [c=IN IP4 IPmcast1] and the [a=mbms-mode:broadcast tmgi-for-Live-TV-service]

1. The BM-SC receives: Stream-data/RTP/UDP/IPmcast/L2/L1.

2. then The BM-SC can either relay (keeping same IPmcast) or change (using IPmcast1) the IPmcast and send to the MBMS-GW: Stream-data/RTP/UDP/IPmcast1/SYNC/L4/IPmbms-gw/L2/L1.

3. then the MBMS-GW sends the data to the eNB using IPmcast2: Stream-data/RTP/UDP/IPmcast1/SYNC/GTP-U/IPmcast2/L2/L1

4. eNB sends the information to the user using a PtM radiobearer: Stream-data/RTP/UDP/IPmcast1/RLC/MAC/PHY

5. The user, finally, receives the data over the IPmcast1, which is the IP multicast that the BM-SC had announced to the user for the Live-TV-service.

BR

Andres

Hi Andres,

For delivering RTP stream from BM-SC to the middleware on the device, SDP describes below parameters:
1) c=IN IP4 (or IP6) <IPmcast1>: Destination IP address which shall be multicast IP address
2) m=video (or audio) <Port>: UDP Destination Port number
3) a=source-filter: incl IN IP4 (or IP6) * <IPsrc>: Source IP address which will be BM-SC IP address
4) a=mbms-mode:broadcast <TMGI>: TMGI which will be broadcasted by eNB in radio interface (MCCH)

1. BM-SC can retrieve RTP stream using Multicast or Unicast

2. BM-SC can use either Multicast or Unicast to deliver RTP stream to MBMS-GW, and protocol stack is as follows:
Stream-data/RTP/UDP/IPmcast1/SYNC/UDP/IP(Muticast or Unicast)/L2/L1

3. Protocol stack from MBMS GW to eNB is as follows:
Stream-data/RTP/UDP/IPmcast1/SYNC/GTP-U/UDP/IP(IPmcast2)/L2/L1
Note that IPmcast2 is defined by MBMS GW and notify to eNB via MBMS Session Start Request message

4. OK

5. When user selects Live TV channel, middleware on the device activates TMGI corresponding to this channel & opens multicast socket. Finally middleware receives streams over the IPmcast1.

And one more comment! In our understanding, mobile operator what they want to provide eMBMS service willing to use DASH over FLUTE instead of RTP for Live TV service.

If you have any question, please let us know.

Thanks,
Netmanias

Thanks for the answer.
I have a doubt about the first point in the last answer:
1) c=IN IP4 (or IP6) <IPmcast1>: Destination IP address which shall be multicast IP address

So, it means that the user always has to know and listen to an IP mcast address <IPmcast1> to receive the service. How does the user join such IP multicast? What is the role of the IGMP in this case?.
Also, does the BM-SC always have to send the RTP stream to that IPmcast <IPmcast1> even when it retrieves the stream data info using unicast, right?.
BR
Andres

SDP (Session Description) parameters such as IPmcast1, Port, IPsrc, TMGI are included in the Service Announcement Metadata (TS26.346 chapter 5.2.2) and this information is broadcasted to the device (UE) through the Service Announcement bearer.
According to the 3GPP standard, eMBMS (After Rel-9) service does not support Multicast Join procedure on the device any more, which means that device does not need to send IGMP Join message. eNB is broadcasting RTP streams with IPmcast1 to radio interface and device can receive RTP stream when it activates TMGI & opens multicast socket with IPmcast1 (without sending IGMP Join message).

Yes, you're right.
There're 2 IP headers in the eMBMS data packet.
1. First IP header (IPmcast1) is created by BM-SC and delivered to the device. Intermediate node such as MBMS GW, eNB do not take care of this address
2. Seconder IP header is used to deliver RTP stream from BM-SC to the eNB via IP transport network. That IP address can be Unicast or Multicast between BM-SC and Streamer (or CDN Edge), and BM-SC and MBMS GW. However, it should be Multicast between MBMS GW and eNB.

좋은 정보와 글 감사합니다.

 

궁금한 점이 있습니다. 그림에서 아래쪽 regional center eNB에 붙어있는 UE는 multicast를 수신하고 있지 않은 것으로 이해하였습니다. UE가 IGMP를 사용하지 않고 다른 어떤 수단으로 자신은 multicast를 수신을 원하지 않는다고 signaling 하는 것인지 궁금합니다. 바로 위의 댓글에서 'TMGI & opens multicast socket'를 사용한다고 답을 주셨는데, 그렇다면 해당 eNB에 multicast 수신을 원하는 UE가 존재하지 않더라도 eNB는 무조건 multicast를 하는 것인가요?

radio network(from eNB to UEs)에서 방송채널(MBMS session)을 구분짓는 인자는 TMGI이며, packet은 broadacsting됩니다 (multicasting 아님).

방송 수신을 원하는 UE는 해당 TMGI를 activation하여 packet stream을 수신하는 것이고, 관심없는 UE는 TMGI activation을 안했으므로 해당 packet stream이 수신되지 않는 것입니다.