| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Eunkyung & All, Please see my comment below. Best Regards, Shoukang From: Eunkyung Kim [mailto:ekkim@etri.re.kr] Hi Shoukang and all, Please see my comment below. Best Regards, Eunkyung Kim Electronics & Telecommunications Research Institute (ETRI) From: Zheng Shoukang [mailto:skzheng@I2R.A-STAR.EDU.SG] Hi Eunkyung, All [-----begin-----] HR-Network shall support local forwarding to allow HR-MSs to communicate with each other via infrastructure station (i.e., HR-RS or HR-BS) without going through the backhaul. To establish the local forwarding, some control signaling is exchanged through the backhaul connection between infrastructure station and network. if there is a backhaul connection (but how to exchange is out of scope of this specification), but signalling is not exchanged through backhaul connection for standalone network. [ekkim] control signalling is only available when the backhaul connection is available. I think only different operation between for local forwarding and for standalone network is whether the backhaul connection is available or not. [Shoukang] I think so. The difference is whether backhaul connection is available. Do we need to explain the standalone network in the local forwarding? I think the standalone network is in the scope of DC. Thus, I would like to defer this for the Canada meeting. [Shoukang] As local forwarding is defined for both cases, with and without backhaul connections, it is necessary to consider this. The details can be TBD or may be under the scope of DC.
[ekkim] What control signalling do we need? Some control signalling, if it is in the scope, should be described clearly. [Shoukang] As pointed out my earlier email, we need to consider two cases (1) when local forwarding is done via HR-RS, local forwarding allows HR-MSs to communicate with each other via HR-RS without going through HR-BS; (2) when local forwarding is done via HR-RS, local forwarding allows HR-MS to communicate with each other via HR-BS without going through the backhaul. In first case, the control signalling includes e.g. the notification from HR-RS to HR-BS if HR-RS detects the opportunity of local forwarding and/or request for permission to perform local forwarding during connection establishment or change. In second case, if HR-BS detects the opportunity of local forwarding for an HR-RS, it should send out the notification to that HR-RS and/or request it to arrange the connection establishment for local forwarding.
Connection establishment is initiated as per 802.16-2009/802.16m standard. Infrastructure station (HR-BS/HR-RS) should detect the possibility of local forwarding by examining the connection setup signaling, for example, the control message DSA_REQ. The infrastructure station that detects the opportunity of local forwarding should establish the downlink connection towards the destination. After the uplink connection (from the souce) and downlink connection (toward the destination) have been established, the infrastructure station should bind these uplink/downlink connections together. [ekkim] BS may establish the local forwarding as a result of detecting the possibility as you mentioned. However, how to detect the possibility of local forwarding is up to implementation but how to establish (notify to MS(s)) needs to be discussed. I am not sure how/what to bine uplink/downlink connection, yet it may one of possible operations. [Shoukang] The binding is basically two uplink and downlink connections/flows are associated with each other to be identified as local forwarding connections/flows without going through backhaul or HR-BS. In order to forward the source packets from the uplink connection/flow to the destination, the mapping of STID+FID between the uplink connection and downlink connection is required, especially for the case of local forwarding via HR-RS. In this case, HR-RS requires this binding to perform forwarding locally without going through classification (CS layer). I think the binding is just a general term in this case, not specific to any implementation.
[ekkim] what kind of handover do you consider? Anyway, I am still open but I believe those examples are not required in AWD text. [Shoukang] There are two cases: (1) when an HR-MS is going to leave current serving infrastructure station, the target infrastructure station and/or its super-ordinate infrastructure station discovers there is an opportunity of local forwarding; (2) when an HR-MS is going to handover to a target infrastructure station, this target infrastructure station and/or its super-ordinate infrastructure station discovers an opportunity to perform local forwarding. I think the local forwarding is not only found in the case of new connection establishment but also applied to connection change when handover occurs. [ekkim] Let me know the detail operation of binding at first. [-----end-----] Regards, From: Eunkyung Kim [mailto:ekkim@etri.re.kr] Hi all, Following is agreed text on the local forwarding during the MM RG second CC. [-----begin-----] HR-Network shall support local forwarding to allow HR-MSs to communicate with each other via infrastructure station (i.e., HR-RS or HR-BS) without going through the backhaul. To establish the local forwarding, some control signaling is exchanged through the backhaul connection between infrastructure station and network but how to exchange is out of scope of this specification. [How to establish/change/release local forwarding between infrastructure station and HR-MSs is FFD.] [-----end-----] In addition, please provide the detailed procedure. Otherwise, last sentence, “How to establish/change/release local forwarding between infrastructure station and HR-MSs is FFD,” will be removed from the RG output text. Anything is missed or wrong, please let us know. Best Regards, Eunkyung Kim Electronics & Telecommunications Research Institute (ETRI) From: ZHANG Xin [mailto:zhangxin@NICT.COM.SG] Dear all, I just uploaded a proposed harmonized text on relay and forwarding (C80216n-rg-11_0056.doc) and consolidated email discussion on relay and forwarding (C80216n-rg-11_0057.doc) to the Server. Please comment if possible. Best Regards, Xin Zhang From: Eunkyung Kim [mailto:ekkim@etri.re.kr] Dear 16n MM RG folks, As one of topics expected to discuss on the MM RG 2nd CC, multicast related document including email summary and recommended text as MM RG output has been uploaded in the 16n RG upload directory. Please find the document (Title: [MM] Recommended Text related to multicast for MM RG in IEEE 802.16n; C80216n-rg-11_0055.doc) in RG upload directory. Any comment is expected. Best Regards, Eunkyung Kim Electronics & Telecommunications Research Institute (ETRI) -----Original Message----- Hi all, Please be reminded of the coming 2nd Conference Call for MM RG. The details are: - Time: May 3 2011, 9AM Eastern US, 6AM Pacific, 10PM Japan/Korea - Duration: 1.5 hours - Dial in: +1-866-457-0015; pin 8109 - LiveMeeting: https://www.livemeeting.com/cc/epripremier/join?id=WMMKF7&role=attend&pw=8f%29K-mM%5Dr <https://www.livemeeting.com/cc/epripremier/join?id=WMMKF7&role=attend&pw=8f%29K-mM%5Dr> Meeting ID: WMMKF7 Attendee Entry Code: 8f)K-mM]r We would like to propose the following tentative agenda: 1. Taking attendance 2. Approving agenda 3. Reviewing email discussions on the 4 topics of: Multi-mode, Relay/forwarding, Path Management, Multicast by corresponding leaders (Alina Liru Lu, Zhang Xin, Hoang Vinh Dien, Eunkyung Kim). Each topic will be allocated 20 minutes with the aim of reaching some harmonized text or common understanding 4. Any other business 5. Closing To facilitate the discussion, we would like to ask the leaders of email discussion topics to prepare consolidated text in advance. Please comment. Best regards, Anh Tuan and Eunkyung 802.16n MM RG Co-chairs |