3GPP Interworking and Multicast retransmission

Slides:



Advertisements
Similar presentations
CMDH Refinement Contribution: oneM2M-ARC-0397
Advertisements

Problem of non-Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.0 Agenda Item: TBD.
Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:
IGMP and MLD Optimizations in Wireless and Mobile Networks 1 draft-liu-multimob-igmp-mld-wireless-mobile-02 Liu Hui Mike McBride.
OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai, NEC,
Resource Announcement Procedures Group Name: WG2 Source: Rajesh Bhalla, Hao Wu - ZTE Meeting Date: Agenda Item: TBD.
Multi-Link Devices Group Name: WG1 Source: Kaonmedia, KETI Contact: Hwang Kwang Tae Yong-Suk Park
Jaringan Komputer Dasar OSI Transport Layer Aurelio Rahmadian.
Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:
Data Distribution Dynamic Data Distribution. Outline Introductory Comments Dynamic (Value based) Data Distribution: HLA Data Distribution Management –Routing.
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
3GPP Rel-13 Interworking discussions
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.
Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.
Technical questions on oneM2M certification Group Name: TST Source: JaeSeung Song KETI, TST WG Chair Meeting Date: Agenda.
OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,
M2M Service Subscription Profile Discussion Group Name: oneM2M TP #19.2 Source: LG Electronics Meeting Date: Agenda Item:
ARC R02 Modelling operations – problem statement and proposal Group Name: ARC#19.3 Source: Joerg Swetina, NEC,
App and Management End- to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm,
Access Procedure Enhancement for HRPD Rev C VIA Telecom grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text.
M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
A discussion on Release duration TP #14 Source: JaeSeung Song, KETI (TTA), Meeting Date: TP Discussion_on_Release_duration.
Understanding inFUSION User Roles. Super Administrator Administrator File Sender File Receiver Internal File Receiver inFUSION Roles When you start using.
Reliable Adaptive Lightweight Multicast Protocol Ken Tang, Scalable Network Technologies Katia Obraczka, UC Santa Cruz Sung-Ju Lee, Hewlett-Packard Laboratories.
Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0,
Network Layer 3 Application Presentation Session Transport Network Data Link Physical OSI Model.
Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.
3GPP Rel-13 Interworking discussions Group Name: TP #18 Source: Rejesh Bhalla, ZTE Corporation, Meeting Date: Agenda Item:
Emdeon Office Batch Management Services This document provides detailed information on Batch Import Services and other Batch features.
Background Data Transfer
3GPP R13 Small Data Delivery
Resource subscription using DDS in oneM2M
Project Management: Messages
3GPP MBMS protocol stack
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
Service Enabled AE (SAE)
SCEF northbound API Analysis
Group multicast fanOut Procedure
3GPP interworking in R3 Group Name: ARC
Possible options of using DDS in oneM2M
Issues of <locationPolicy> Discussion
Discussion about Use Case and Architecture in Developer Guide
NIDD Discussion Points
3GPP Rel-13 Interworking discussions
OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai,
What is the status from Ccavanue team
Reliability Gain of Network Coding - INFOCOM 08
Discussion to clarify online/offline behavior
Chapter 2: System Structures
Group multicast Group Name: ARC
Remote Storage Management
LWM2M Interworking with <mgmtObj> Resources
CMDH Refinement Contribution: oneM2M-ARC-0397R01
MinitorEvent(UE_Reachability)
CMDH Policies Contribution: ARC-2014-xxxx
Host Multicast: A Framework for Delivering Multicast to End Users
3GPP V2X Interworking Potential Impact
3GPP Interworking and use of <schedule> resource
Viet Nguyen Jianqing Liu Yaqin Tang
Staged Refresh Timers for RSVP
BlockAck Enhancement for Multicast Transmissions
GT Portal v. 2.0 Data Delivery
(CS Team Member) Location, Date Receipting for Property
Air Efficiency and Reliability Enhancements for Multicast
FINGER ACCESS DEVICE.
Notification Target Discussion
Presentation transcript:

3GPP Interworking and Multicast retransmission Group Name: ARC Source: KETI and Hyundai Motors – JaeSeung Song, Lewis Nkenyereye, Youngjin Ra, and Minbyeong Lee Meeting Date: 2018-12-03

Motivation and Background

Issues and Use Case oneM2M IN-CSE, Group Hosting CSE, should aware of MBMS status of a multicast message to be delivered so that it can provide an exact information which members were failed to get the multicast message. If such information is available at the Group Hosting CSE, Contents provider (AE) can perform retransmission of the message only to the members failed to receive the message Use Case for a periodic and/or planned file delivery to a large number of vehicles. Smart vehicles are moving various places. These smart vehicles are receiving many multicast services such as traffic condition, accident information, detour information. Based on growing amount of data, the system configuration is adjusted, requiring the delivery of small configuration updates to all vehicle devices. As vehicles move fast, there will be high chance not to get the delivered multicast message If some of these multicast delivery fails, the message should be retransmitted to users

Current Status What about some members didn’t receive the multicast msg properly?  Retransmission should be performed

How to support? Required enhancements for multicast retransmission oneM2M should support the reliable delivery of multicast message The <group> resource should know the detail information about the MBMS delivery status (i.e. delivery failure) The <localMulticastGroup> resource should also know the detail information about the MBMS delivery status oneM2M system should be able to retransmit multicast message to failure MBMS nodes Two available mechanisms Unicast to MBMS failure member nodes If the number of failure member nodes are low, this mechanism is good to be selected Multicast the same message to the MBMS failure member nodes If the number of failure member nodes are high, this mechanism is good to be selected Different multicast group (TMGI) for retransmission is needed

Retransmission using Unicast Member Hosting CSE 3GPP Group Hosting CSE AE 15. Response Retransmission using Unicast If there are failures of multicast delivery, <group> hosting CSE retransmit the message to failed nodes via unicast CSE sends unicast message delivery to the members in the memberNotDelivered attribute If unicast delivery is successful, CSE deletes the member from the memberNotDelivered. After the given number of retransmission, CSE considers the failure nodes are not available anymore and removes the member from the <group> resource 16. Update retransmission related attributes 17. Response 18. retransmit 19. Check failure members 20. Retransmit using Unicast 21. Response 22. Remove members that receive delivery successfully 23. Response 24. If there exist member CSEs that didn’t get the message successfully, AE can repeat again until the given maxRetransmission number

Retransmission using Multicast Member Hosting CSE 3GPP Group Hosting CSE AE Retransmission using <Retransmission> 16. Record failure member hosting CSEs 17. Response to AE 18. AE requests retransmission for the message (maxTime, maxNumber, etc), 19. Group Hosting CSE creates <retransmission> resources with other relevant attributes, incl. allocate a new TMGI for retransmission 20. CSE sends unicast message delivery to the members in the memberNotDelivered attribute 21. Response from member hosting CSE 22. Update <Retransmission> resource based on the If unicast delivery is successful, CSE deletes the member from the memberNotDelivered. Increase currentNrRetransmission. 23. Response to AE 24. After the given number of retransmission, CSE considers the failure nodes are not available anymore and removes the member from the <group> resource 15. Response 16. Local processing 17. Response 18. retransmit 19. Prepare retransmission 20. Retransmit using Unicast 21. Response 22. Update <retransmission> for example, remove members that receive delivery successfully 23. Response 24. If there exist member CSEs that didn’t get the message successfully, AE can repeat again until the given maxRetransmission number

Retransmission using Multicast Retransmission using <Retransmission> resource <Retransmission> resource can be introduced to support multicast retransmission If there are failures of multicast delivery, <retransmission> resource is created as a child resource of <group> CSE performs multicast to the members listed in <retransmission> group for the given number of times For each retransmission, if nodes receive the message properly, these members should be removed from the <retransmission> resource After performing multicast to the given number of times, the created <retransmission> resource is removed In this case, 3GPP MBMS TMGI and relevant information to perform 3GPP MBMS should be created and configured for the members specified in <retransmission> resource