| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear Jeongki and all, Thank you for your good summary. I have a question about the concept in contribution #21/15. Do you propose to use PGID as multicast group ID or vice versa? As you mentioned paging group is designed based on geographical region by grouping base station(s) and it is a reason to avoid frequent idle mode handover by an idle mode MS. But about multicast group ID, I think it is an identification for multicast service. So, I wonder what the contribution #21/15 propose. Regards, Hyunjeong From: Jeongki Kim [mailto:jeongki.kim@LGE.COM] Dear Kaushik and all, Based on the 1st DEV CC and the related contributions my understanding about the group ID is as follows 1. Name: M2M multicast group ID (C80216p-rg-11_0006), M2M devices group ID (0012), M2M Group paging ID (0021) 2. What? Identify a M2M subscriber group (or M2M multicast group) which one or more M2M devices belongs to 3. The main usages 1) To transmit the multicast data in an M2M subscriber group (or M2M multicast group) - Group ID is included in multicat MAP or Group ID is masked with the CRC of multicast MAP 2) To wake up all devices in idle state in M2M subscriber (or multicast group) - Group ID is included in the paging message * Applications? M2M multicast data which need to be transmitted to all devices belonging to a group simultaneously (e.g., software update, application multicast management, etc.) 4. What's the difference between group ID for M2M and 16m Multicast group ID ? 1) Multicast group ID of 16m - Main purpose/applications: Cell multicasting at disaster/emergency events - i.e.) Cell specific: When the cell is changed, Multicast ID should be updated - Used by AMSs in only connected mode 2) Group ID for M2M multicast - Network common (0006, 0012) or geographical group common[Paging group/multicast Zone] (0021) - Used by M2M devices in connected mode & idle mode 3) Group ID for 16m GRA - ID to manage the AMSs in connected mode in order to increase the resource efficiency (i.e., DL control overhead reduction) - For not multicast service but unicast service Therefore I agree that the group id for M2M needs to be defined newly for M2M multicast transmission 5. Size of Group ID I assume the M2M multicast group is configured based on a M2M subscriber and an M2M subscriber may have one or more multicast connections. According to 16p TR (80216p-10_0005), there are several M2M applications such as Secured Access & Surveillance, Tracking, Tracing, and Recovery, Public Safety, Payment, Metering, etc. There will also be a lot of subscribers per each application. For example, in a country there are many taxicab companies, bus (including intercity bus & intra-city bus, etc.) companies, rent-car companies, etc. And most of subscribers for some M2M applications (e.g., companies for gas metering, intercity bus/taxi companies) exist in a geographical region. This is why I consider the group ID as geographical-region (paging group) common ID instead of network common ID. I think if the group ID is unique in the entire network, the size of group ID should be very long (??). Based on three contributions (0006, 0012, 0021(0015)) the summary of group ID is as follows: * Common points: 1. Need new Group ID for M2M multicast (M2M Group ID) 2. The M2M Group ID is also retained in idle mode. 3. Usage: 1) group paging 2) Multicast transmission * Further discussion points: 1. Shared region & size of M2M Group ID - Option 1: Unique in the entire network (0006, 0012) - Option 2: Unique in the geographical region (0015) 2. M2M group ID allocation - Option 1: By DSA procedure (006) - Option 2: During initial network entry (0012, 0015) It would be appreciated if you give me any comments. If I’m missing something, please let me know. Thanks, Jeongki From: Jang, Jaehyuk [mailto:jack.jang@SAMSUNG.COM] Dear Bin, Kaushik, Soojung, and All, Thanks for sharing your opinions. BTW, 802.16m draft already defines several IDs (e.g., DID (used in idle mode operation), CRID) which are not limited in a cell only. And, to support large number of devices for m2m application, it is inevitable to utilize idle mode operation (for power saving). Then, 802.16p needs to define network-level broadcast/multicast mechanism so that data transmission to MSs in idle mode is possible. Otherwise, thousands of MSs will perform network reentry to receive broadcast/multicast data. Hence, it is appropriate to define a new ID such as MGID for the operation, IMO. Regards, Jack From: Bin Chen [mailto:binchen@HUAWEI.COM] Hi, Kaushik, Soojung, and all, Thanks for sharing these. I think it is not suitable to allocate a group ID in MAC with network unique feature. MAC layer is limited in cell level, and if a MS move to other cells there is handover procedure to re-allocate a new ID. In a cell level, there is broadcast and multicast process and group resource allocation already. So, I would prefer to discuss it more sufficient in the group before we put it to the AWD text. BR/Bin From: Kaushik Josiam [mailto:kjosiam@STA.SAMSUNG.COM] Thanks Soojung for sharing your opinion on the need for a group ID. I request other members to input their comments on this issue. Dear 16p members, Since we didn’t hear any objections from members for having a group ID in the conference call, would it be reasonable for us to add the following text to the addressing section 16.2.1.2.9 M2M device Group Identifier (MGID)A [TBD] bit value that is used to identify an M2M group which an M2M device belong to. It is unique in the domain of the entire network. A MGID is assigned by the network during initial network entry. What we are proposing to do is to create a new subsection for group identifier and add this description there. We welcome member’s comments on the text above. You can add your comments to the text as a reponse to this email. If you are opposed to creating a group ID, please don’t hesitate to state your objection. Regards Kaushik & Ming-Hung Dev RG Chairs From: 정수정 [mailto:sjjung@etri.re.kr] Dear 16p members, ETRI's opinion about group ID is as follows; M2M devices for the same service application (e.g. metering, tracking ) can share one or more features in common. In other words, due to the nature of M2M application, the M2M device within the same service application may have the same traffic pattern. In order to provide the same service application, the same control messages or the data traffic may be required for the M2M devices at the same time. In this case, individual transmission of the same data to mass M2M devices can cause huge overhead. By grouping the M2M devices that have same features, the 16p system can support efficient management. And the group control(e.g. group paging) and traffic (e.g. multicast transmission) may be needed to M2M devices in idle state as well as in connected state. therefore. We think that a group ID is necessary. And a group ID is network specific ID and is associated with subscriber. A network specific group ID which is associated with subscriber has benefits as following . Regards, Soojung jung --------------------------------------------------- Soojung Jung Senior Member Mobile Telecommunications Research Division Electronics and Telecommunications Research Institute(ETRI) Tel: +82-42-860-5928 Fax: +82-42-861-1966 ---------------------------------------------------
Dear 16p members, Two contributions C0006 and C0012 defined the concept of a group ID addressing different applications. Please respond to this email thread to voice your thoughts. In particular, we are looking for your inputs on the following: 1. Is a Group ID necessary to be defined for M2M devices? 2. What applications would use a group ID? 3. What are the characteristics of a group ID? (For ex: is it a network specific ID?) 4. What is the size of the proposed group ID? If you have any other thoughts, proposals or questions, please respond to this thread. Regards Kaushik & Ming-Hung DEV RG Chairs |