| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 링크드인 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 인터넷자료실 | 자유게시판    한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

2023

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (128)   5G 특화망 4가지 구축모델   산업계 5G 응용   산업분야별 5G 특화망 활용사례  [5G 특화망 벤더Samsung | HFR | Nokia | more
 

해외

  국가별 사설5G 주파수 [국가별 구축현황] 일본 | 독일 | 미국 | 프랑스 | 영국  [사설5G 사업자] Verizon | AT&T | DT | Telefonica | AWS | Microsoft | NTT동일본 | NTT Com    
 

국내

  5G 특화망 뉴스 | 국내 5G 특화망 구축 현황 | 국내 5G 특화망사업자 현황 (19개사) | 국내 자가구축사례 일람 | 국내 특화망 실증사업사례 일람 | 5G 특화망 정책
 
 

[5G 특화망 구축 사례] 한국식품산업클러스터 | 반월시화산단 삼성서울병원 | 롯데월드 | 한국수력원자력 | 해군본부 | 한국전력공사 | more  [이통사] KT

 
 
스폰서채널 |

 HFR의 5G 특화망 솔루션 (my5G)  Updated   | HFR 5G 특화망 뉴스HFR my5G 자료

  스폰서채널 서비스란?
LTE 기반 Mobile IPTV 네트워크 구조
End-to-end LTE Mobile IPTV Architecture
September 06, 2012 | By Netmanias (tech@netmanias.com)
코멘트 (9)
14

 

 

Kumar 2013-03-02 03:50:09
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 ?
넷매니아즈 2013-03-08 23:39:00
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)
정성용 2013-04-29 07:40:55
유익한 자료 너무 감사드립니다..
Andres 2013-05-25 08:23:44
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
넷매니아즈 2013-05-27 22:35:11
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
Andres 2013-05-29 01:27:04
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
넷매니아즈 2013-05-29 10:53:58
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.
J 2016-10-11 16:01:11

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

 

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

Netmanias 2016-10-11 17:08:33

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

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

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호