| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear 802.16n fans, I would like to share my intention on the multicast issue by issue as follows: n overall description including addressing o whether multicast group zone is required or not § In 802.16m, multicast operation is described only for the connected state. Thus, it is severe power conservation because any MS should all A-MAP IE to recognize whether multicast traffic is transmitted or not. o how to indicate multicast traffic [multicast group ID + FID] § similar to addressing of 16m, multicast group ID + FID can be an address for multicast. However, the combination is unique in a multicast group zone to avoid frequent updating of addressing when an MS crosses the cell boundary. n multicast establishment o capacity exchange including registration o how to establish/change/delete multicast service § similar to (or same as) capacity exchange and establish/change/delete operation should be performed in 802.16n, but some additional information may be included during those procedure. o how to allocate/receive multicast [Note: it will be discussed on downlink control for multicast in detail] § Because multicast indicated by broadcast assignment A-MAP IE is poor at power consumption as well as security, new A-MAP needs to be designed. n multicast operation in connected state as well as idle state o operation in connected state [including sleep mode] § same as the operation described in 802.16m, but only difference is updating when an MS crosses the boundary of multicast group zone. o operation in idle state § in addition to the connected state, some information (e.g., allocation period, lifetime) needs to support idle mode to avoid receiving all A-MAP IE to recognize whether multicast traffic is transmitted or not. n downlink control for multicast [i.e., MAP related to multicast] o how to indicate/allocate/recognize multicast data § It’s up to design a multicast related MAP. n advanced features such as multicast security and local forwarding o deferring until basic operation is defined If there is any comment or anything I missed, please let me know. Thanks and BRs, Eunkyung Kim Electronics & Telecommunications Research Institute (ETRI) From: Eunkyung Kim [mailto:ekkim@ETRI.RE.KR] Dear 16n participants, I would like to initiate an email discussion on the multicast issues which are summarized as follows: - overall description including addressing o whether multicast group zone is required or not o how to indicate multicast traffic [multicast group ID + FID] - multicast establishment o capacity exchange including registration o how to establish/change/delete multicast service o how to allocate/receive multicast [Note: it will be discussed on downlink control for multicast in detail] - multicast operation in connected state as well as idle state o operation in connected state [including sleep mode] o operation in idle state - downlink control for multicast [i.e., MAP related to multicast] o how to indicate/allocate/recognize multicast data - advanced features such as multicast security and local forwarding o deferring until basic operation is defined Any comment and any other topic are appreciated to discuss on the multicast issue. [Note: HTML email format is strongly recommended.] Thank you and Best Regards, Eunkyung Kim Senior Engineer Mobile Access Technology Research Team Dept. of Wireless System Research, Internet Research Lab. Electronics & Telecommunications Research Institute (ETRI) 161 Gajeong-dong(218 Gajeongno), Yuseong-gu, Daejeon, 305-350, KOREA TEL: +82 42 860 5415 FAX: +82 42 861 1966 |