| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Sungcheol: You skipped a couple of e-mails. I placed the missed comments in Topic A and Topic B so we can have one single-threaded e-mail. From: Chang, Sungcheol [mailto:scchang@etri.re.kr] Hi Ming-Tuo, Please see my comments regarding Forwarding in topic A. Best regards, Sungcheol Chang, Ph.D. Mobile Access Technology Research Team, ETRI Regarding use cases: <<<<<<<<<<<<<<<<<< Topic A Sungcheol: Agrees with 1) Infrastructure nodes are absent and 2) One HR-MS is associated with an infrastructure node and one or more other HR-MSs are out of coverage of an infrastructure node. Does not agree with: The use case of both two HR-MS under an infrastructure node - 802.16n is for reliability enhancements, questions if this use case is for that. Anh Tuan: The direct link, in certain cases, provides higher rates etc. Eldad: I would agree with Anh Tuan. Stated differently, if 2 HR-MS are at the edge of the cell than their supportable data rate with the BS can be too low. For voice this isn't an issue as the voice data rate is similar to the data rate of the associated signaling for MS control. On the other hand if the mission requires e.g. video than these 2 HR-MS may not be able to maintain video link with the HR-BS - but can with each other. Then it is a reliability issue. I also agree that MS-MS communications under a BS is simpler than HR-MS forwarding. Sungcheol: If just communication is needed between two HR-MSs, then we can use multi-mode operation of HR-MS as relay function instead of defining new specification. My preference is the reuse and modification of existing specification. If one HR-MS changes its role as relay and the HR-MS relays or terminates packets with the other HR-MS, it's nature is direct communication. I don't object the motivation of communication between HR-MS under coverage, but updating existing 16 specifications has a priority to defining new specification. Is it impossible to achieve two HR-MS communication under BS coverage with HR-MS multi-mode operation as relay? Anh Tuan: From your reply, I think we have already agreed on two important points: - There is no objection for direct/forwarding communications between HR-MSs under coverage (and one of the purposes is to enhance reliability at cell edge, as explained by Eldad). - For 16n, reusing/updating of current 16e/m features should take priority over introducing totally new specifications. With the above two agreeable points, we can proceed to evaluate different approaches and probably get more consensus. Let us remember that we are discussing the use cases here, and not the solutions. So we should first agree on the usefulness, then move on to discuss the solutions (e.g., frame structure). Eldad: That HR-MS direct and forwarding communications (with and without infrastructure) is required has been discussed extensively during the SRD phase which we have all agreed to. In the SRD it exists as a distinct requirement from HR-MS role change to e.g. HR-BS. This has also been discussed extensively. The reason for it appearing as a separate requirement is that, as we decided, when HR-MS changes its role to HR-RS it is an HR-RS with all the HR-RS functionality (although possibly with reduced capability). We didn’t feel that a forwarding HR-MS, for example, need ALL the functionality of an HR-RS (although of course it needs some). Having said that I agree with the principle that 16e/16n baselines should be reused as much as possible. Sungcheol: We need to clarify scope of e-mail discussion. Under 16n SRD document, we discuss the use case of direct communication between HR-MSs (not 16n use case). If a forwarding MS has a subset of HR-RS functions like 16j transparent-mode relay, is it classified into use case of direct communication? It seems that the forwarding MS should be classified into enhancement or modification of HR-RS because 16j specification describes already that kind of relay function. I’d like to differentiate direct communication with modification of HR-RS. In principle direct communication is a peer-to-peer communication. Using this peer-to-peer communication, a forwarding function can be an additional function on it (my view). If we want to add 16j-like transparent mode relaying function as a forwarding function, it should come from modification of relay specifications, 16j or 16m relay definitions. I think that two approaches are on different basis technologies: one is on peer-to-peer communication and the other is on relay function. How can we clarify this? Eldad: If we agree that 802.16 baseline should be reused as much as possible then it follows that HR-MS Forwarding re-uses e.g. 802.16m relay designs. That doesn’t, in my opinion, mean that we make a forwarding HR-MS into an HR-RS, would you agree? Sungcheol: I can’t agree easily that a forwarding HR-MS, but its nature is a transparent mode relay like 16j relay, is categorized into an HR-MS of peer-to-peer direct communication. If we call it as a forwarding HR-MS, then 16 specification family has two names for one transparent relay operation. One is a transparent mode relay and the other is a forwarding HR-MS. So I think that an HR-MS having a modified function of transparent mode relay is classified into a set of relay. It keeps consistency. Anh Tuan: Sungcheol and Eldad, I myself do not agree to link HR-MS forwarding (when both HR-MSs are within coverage) to a 16j transparent-relay mode. There are fundamental configurations/restrictions applied to a transparent relay that a forwarding HR-MS may not need to follow, such as handling of network entry of subordinate MSs, relative positions of relay/access zones, no source/sink of data... I would rather implement HR-MS forwarding through modifications to the existing DL/UL control signaling (like A-MAP) of the current 16e/m specs. Ming-Tuo: Sungcheol, please note in 16j transparent relay mode, the relays do not transmit frame header information. However, in HR-MS forwarding, the in-coverage HR-MS may need to transmit frame header information to a HR-MS out-of-coverage since the later cannot hear HR-BS directly. In this sense, HR-MS forwarding differs 16j transparent relay mode in nature. I agree with Eldad that forwarding needs some functions but NOT all of relay. Sungcheol: Conceptually I understand the difference between transparent mode 16j relay and your forwarding HR-MS. But we need more detail technical operation to forward frame header information only. As you know, there are several content types of DL/UL control structure (described in 16.3.5 and 16.3.8) between infrastructure node and MS including advanced preambles, supreframe header, advanced MAP, E-MBS MAP, DL power control, UL control channel (Fast feedback, HARQ feedback, ranging channel, bandwidth request channel), UL power control, etc. You tell me that the forwarding HR-MS just forward frame header information out of control contents of DL/UL control structure. Please explain more detail operation scenario of your approach on forwarding function. In 16j specification, there are two types of relay stations: one is transparent mode operation in which relay station relays data and UL controls(?), and the other is non-transparent mode operation in which relay station terminates access zone operation and is a peer entity to HR-MSs. Your approach is that forwarding HR-MS does not have all of relay functionalities. Is it possible? If the forwarding HR-MS does not relay all the DL/UL control contents, its performance of the forwarding HR-MS is degraded dramatically, which is similar to the performance of my proposal on direct communication. I think that if a forwarding HR-MS relays(forwards) frame header information (one of DL control contents), the forwarding HR-MS has one more additional function than transparent mode relay station because the functionalities of transparent mode relay stations is a minimum set of technical functions for relay(forward) operation. Frankly I don’t quietly understand the technical difference between relay and forwarding functions from your proposals. In addition to the contents types, there is an issue of timing that when a forwarding HR-MS transmits DL contents, all the HR-MSs and HR-BS shall transmit DL control contents at a time. To do this we need to find a solution to the timing issues. I’d like to clarify my position. I just point out the technical similarity between BS controlled peer-to-peer DC and transparent mode 16j relay station. I do not in favor of 16j transparent mode operation. DJ: Added comments from skipped e-mails. DJ: I agree that we should not mix 16j/m relay functionalities with 16n mobile forwarding. As people indicated that 16j/m relays are designed for a different purpose. The 16j/m relays are typically viewed as a small base station with reduced features. It is hard to imagine that 16n would force all HR-MSs to have 16j/m relay functionalities. To me, the procedures required to implement HR-MS need to be as simple as possible to reduce the complexity (which drives down the cost and battery consumption for a mobile). >>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<< Topic B Eldad: * Modes for HR-MS direct communication - Both HR-MSs are associated with an infrastructure node. - Infrastructure nodes are absent. * Modes for HR-MS local forwarding - One HR-MS is associated with an infrastructure node and one or more other HR-MSs are out of coverage of an infrastructure node. Anh Tuan: 1) We can have an HR-MS that is outside-of-coverage but can still be associated with an infrastructure node (through the help of a forwarding HR-MS). So for the 1st mode of HR-MS direct communications, When we say "Both HR-MSs are associated with an infrastructure node.", do we mean "association" or "coverage"? 2) For HR-MS forwarding to network (we should not use "HR-MS local forwarding" as 16n SRD uses "local forwarding" to refer to a different scenario), I would like to add the 3rd mode of "Both HR-MSs are within the coverage of an infrastructure node". This can be beneficial when HR-MSs are power-limited Eldad (Answer): - Agree with the terminology "forwarding to network" - I agree to add to HR-MS Forwarding the case where both HR-MS are in coverage (point 2). Actually this is the same argument I used for MS-MS communications as a reliability enhancement. - For MS-MS direct communications (point 1) I'm not so sure it is needed. HR-MS that are of coverage of the HR-BS will likely be at cell edge. They will have few neighbor HR-MS. They will have even fewer HR-MS they will need peer to peer connection to. Therefore I think this isn't an important case. Therefore I would disagree with this case. Anh Tuan: I am not quite clear about your last point, can you please elaborate? Eldad: I’ll try. The difference between forwarding and peer to peer communications is that the former is non-specific, the latter is specific. HR-MS forwarding is mostly needed for an HR-MS that is in a coverage hole (indoors, basement, etc.). It will have very few other HR-MS within range, any of those could potentially help to forward its data. On the other hand if we assume that peers are spread through the cell then the chances that one of those would also be a peer (to directly communicate with) are smaller. Sungcheol: Refer to the third answer to Topic A. Sungcheol: I’d like to point out MS mobility. A HR-MS can be moved into under BS coverage because HR-MS can move freely. So if we define two modes depending on location it will give participants misunderstanding of this modes. So I’d like to classify them into three modes: 1) Transparent mode (with/under BS control) - Both HR-MSs are associated with HR-BS and HR-BS controls communication between HR-MSs including resource allocation. Its nature is on centralized control scheme. - This category contains one use cases that we described in the previous discussion. * When both HR-MSs are within the coverage of an infrastructure node 2) Forwarding mode (with/under BS control) - One HR-MS within the coverage is associated with HR-BS and forwards data and control packets into the other MS. The other MS may be within the coverage or out of the coverage. - This category contains two use cases that we described in the previous discussion. * When both HR-MSs are within the coverage of an infrastructure node * When only one HR-MS is within the coverage 3) Independent mode (without BS control) - Communication between HR-MSs occurs independent of BS control. Resource allocation is done in distributed way. (But it still keeps minimum synchronization to infrastructure frame if possible) - This category contains three use cases that we described in the previous discussion. * When both HR-MSs are within the coverage of an infrastructure node * When only one HR-MS is within the coverage * When both HR-MSs are in absent of infrastructure node. I thinks that all the proposals in previous discussion are covered by this categorization. And practically it’s hard to switch resource control methods when a MS change its resource allocation algorithm according to detection of their radio environments. When we consider that HR-MS moves across the boundary of BS coverage freely, it’s not proper that three modes are dependent on MS’s location. With this mode definition we can develop more practical direct communication operation. For forwarding mode, there are two implementations. One is an extension of transparent mode. The other is an extension of independent mode. I found that Anh Tuan and Eldad prefer the extension of transparent mode. But my preference is the extension of independent mode. If we accept two approaches we can step next. But if we select one of two approaches, we need selection procedure. Eldad: I would agree with modes 1 & 2 although I would like to rename “transparent mode” à “BS controlled peer to peer mode” and “forwarding mode” à “ BS controlled forwarding mode”. I have serious concerns with mode 3 “independent mode” within coverage of BS. This type of uncontrolled operation would cause serious interference issues with legacy (non-HR) BS. As I see it, if an HR-MS is within coverage of an HR-BS, HR-RS or another HR-MS that is within coverage of one and can act as forwarding HR-MS, it must attach itself to it. This is required for the following reasons: - Backward compatibility is an agreed SRD requirement. - Licensed spectrum is owned by operators who always require to maintain tight control of it. This is the only way in which they can guarantee service. - In some regulatory environments mobile units aren’t allowed to transmit unless authorized by a fixed controller (e.g. TVWS) - In normal cellular operation an MS always tries to attach itself to the best BS it can find which as we know leads to optimal operation. The recent introduction of closed groups for Femto cells is known to create interference problems, not all of them have been solved by 802.16m. Now imagine same issues but with many more interference sources All of the above tells me that independent mode within coverage of a BS cannot be the only mode for 802.16n. It can perhaps be allowed in specific spectrum. Whether or not it is worth developing as a secondary mode is a matter we should discuss. Because of the above, forwarding mode under BS cannot be an extension of independent mode. Haiguang Wang : First of all, I agreed with Eldad that serious interference may be caused in the "independent mode" within coverage of BS. And also, in licensed band, such behavior usually is not allowed by spectrum owner. Second, distributed scheduling may cause significant overhead due to long symbol duration. In my view, it is quite complex to define a distributed scheduling mechanism under the current 802.16 framework. Significant PHY change may be required. Sungcheol: I understand what Eldad and Haiguang worry about. My answers to the comments follows: - For backward compatibility. Direct communication is defined on 16n specification between HR-MS and HR-BS. HR-MS is attached to 16m BS as 16m MS. I don’t understand why you say about backward compatibility. - For Licensed spectrum. I partially agree with you. As you know, we are trying to adapt 16n system as a candidate for Korea PPDR system. It’s hard to get frequency bandwidth allocations for PPDR application from government agency. Furthermore, there is no possibility to get additional frequency allocations for direct communication. Under this consideration, it’s a only way that direct communication is operated within PPDR frequency allocation. Direct communication is an essential functionality of PPDR system. If 16n specification allows only direct communication in a frequency band different from infrastructure frequency band, 16n system is not applicable to Korea PPDR system. It’s our motivation to propose that direct communication is within infrastructure frequency band. I believe that when we developed 16n SRD document I have presented several materials about this. - For authorization and licensing. If a frequency band is allocated to PPDR application and 16n specification is adapted, there is no issue on these. But it’s important that infrastructure communication and direct communication work within a frequency bandwidth. - For interference and Femto. I agree that Eldad and Haiguang point out about possibility of interference. It’s why I propose the DC specific dedicated resource for direct communication. In principle, DC specific dedicated resources and infrastructure resources are mutually exclusive. We propose an interference avoidance approach (mutually exclusive resource usages) to minimize interference each other. Also we provided a material about this interference and please refer to C80216n-11_0051r2. - For distributed scheduling. I understand that centralized control mechanism is efficient. But it requires a central controller like HR-BS. When we consider that HR-MSs are within or out of the coverage, it’s hard to insist that centrally control mechanism is only a solution for resource scheduling. I highlight Forwarding mode. In my view, a forwarding MS is mapped to gateway which relay packets between two interfaces, direct communication and infrastructure communication for PPDR system. Two interfaces work independently and packets are relayed as gateway function. It’s different from 16j or 16m relay operation which is based on relay and access zones in single frame structure. This difference comes from different applications, for example Smart Grid and PPDR. Under this consideration, is it necessary to find a solution for two applications? I believe that Forwarding mode is an extension of direct communication for PPDR application and is a modification of transparent mode relay for Smart Grid application. I could not find one solution applicable to two applications. I don’t agree that a modification of transparent mode relay is a solution for PPDR. Ming-Tuo: In case that two HR-MSs are within coverage of a HR-BS/RS, what's the difference between: 1) a HR-MS relays data/control message of another HR-MS to HR-BS/RS; 2) a HR-MS forwards data/control message of another HR-MS to HR-BS/RS. Anh Tuan: Like Eldad, I prefer to use the terms "BS conrolled peer to peer mode" and "BS cotrolled forwarding mode". I also believe that we should avoid using the term "transparent" and regarding "BS controlled forwarding mode" as a modification of "16j transparent relay mode". We can support 16n HR-MS forwarding without specifying relay/access zones. Sungcheol: The relay/access zones are used for Tx and Rx separation of a station. Though we need to consider these terminologies and their concepts, Tx and Rx separation per HR-MS is necessary for peer-to-peer communication. Haiguang: Please correct me if I am wrong. May I know that a specific PHY and MAC has been defined for PPDR in Korea or other countries? In my view, the PPDR is just an application. It just requires MAC and PHY to find a way to delivery the voice data packet generated by PPDR application to the peer. I do not see the need of a dedicated channel for the communication. Sungcheol: Haiguang, You are right. I highlight that just delivering voice packets is meaningless to PPDR usages. With HR-MS’s power emission limitation, it’s important that the coverage of direct communication is extended at the basement environment. If just delivering voice packets over the coverage is a purpose, I myself will reuse relay station that we have already specifications about and I don’t find any motivation to introduce wideband direct communication for this. As you know, infrastructure communication are based on wideband transmissions of preamble and SFH. For example, Femto cell coverage is known as hundred meters and if Femto cell is deployed at the basement can you imagine its coverage of HR-BS (like Femto cell) with limited power emission? Practical scenario of fireman is that as fireman goes down from ground the need of direct communication increases. In that scenario it’s important that HR-MS maintains communicate with other HR-MSs in the basement. If we design direct communication with wideband frequency resource usages, its coverage will be smaller than one of Femto cell because there are several number of obstacles between floors and walls between rooms in the basement. It’s related to fireman survivability. That is a scenario of direct communication for PPDR application. Eldad: HR-MS forwarding is also meant to and can solve the coverage hole issues as well and can do a much better job of it than simply using narrowband signaling. Suppose we reduce the allocation size to one third (1/3) of its minimum today. That buys you 5dB. A coverage hole could easily be much deeper than 5dB in which case narrowband signaling alone isn't sufficient. On the other hand, a link through another HR-MS acting to forwarding MS can easily bridge the gap using low power transmission and therefore creating low interference. Sungcheol: I understand that there is a limitation to increase the coverage of direct communication. I want to get a maximum gain from the narrowband resource allocation. I point out two problems: 1) Wideband transmission of preamble 2) In 16m, 4 PRUs is a minimum allocation for traffic allocation. The bandwidth of DC in TETRA system is 25 kHz per channel. I believe that we can get more gain 5dB if the resource size is smaller than 1/3. PRU’s frequency banwdith is 5MHz/24= 208KHz. If we allocate 1/8 PRU for voice transmission, we can get 32(4*8)=15dB for voice traffic transmission. To achieve 15dB, the resources for transmitting preamble shall be reduced to 1/32 theoretically. But 1/32 of 5MHz (<1PRU) is too small for dedicated resources so that 1 ~ 4 PRUs are considered for dedicated resource of direct communication and they may be candidates of bandwidth of synchronization channel. In addition to narrowband transmission, implemented HR-MS will have more high power emission for PPDR allocation because high power emission is allowed in the PPDR frequency allocation. These two factors of narrowband transmission and high power emission are key features of coverage extension for direct communication. DJ: Added comments from skipped e-mails. Ming-Tuo: For use case, as commented in C80216n-rg-11/0051.xls, I’d like to propose: Use case 1: (a) Two HR-MSs are in coverage of one infrastructure station (i) Two HR-MSs are in coverage of a HR-BS (ii) Two HR-MSs are in coverage of a HR-RS (b) Two HR-MSs are in coverage of different infrastructure stations of a same cell (i) One HR-MS is in coverage of a HR-BS, the other HR-MS is in coverage of a HR-RS (ii) One HR-MS is in coverage of a HR-RS, the other HR-MS is in coverage of another HR-RS Use case 2: One HR-MS is in coverage of an infrastructure station, while the other HR-MS is out of coverage of any infrastructure stations (i) One HR-MS is in coverage of a HR-BS, the other HR-MS is out of coverage of any infrastructure stations (ii) One HR-MS is in coverage of a HR-RS, the other HR-MS is out of coverage of any infrastructure stations Use case 3: Two HR-MS is out of coverage of any infrastructure stations Basically, I do NOT see there is a need to define DC/forwarding mode such as “peer-to-peer mode”, “forwarding mode”, and “independent mode”. I do agree that HR stations are mobile, but to define DC/forwarding modes is not a solution of issue associated with mobility. Meanwhile, it is some confusing to say “peer-to-peer mode” and “forwarding mode” – there is a case that a HR-MS needs to transfer from “forwarding mode” to “peer-to-peer” mode? HR-MS direct communication and HR-MS forwarding are two different kinds of communication scenarios, and the two types of communication scenarios cannot transfer each other. I suggest we keep the original term from 16n SRD: HR-MS direct communication and HR-MS forwarding to network. For HR-MS direct communication, we can say there are two modes: centralized HR-MS DC mode and distributed HR-MS DC mode. If we do not agree to support distributed HR-MS DC mode, then we just use HR-MS direct communication while define it in a way to say that HR-MS DC must be under control of a HR-BS/RS or a coordinator. I also think it is necessary to define “HR-MS forwarding to network” to minimize confusion. >>>>>>>>>>>>>>>>> Regarding frame structure: <<<<<<<<<<<<<<<<<< Topic C Question-1) Are 2 HR-MS in the same cell allowed to transmit on the same resources (assuming that they are far enough)? Anh Tuan: This resource reuse should be encouraged, as long as mechanisms are provided to mitigate interference among HR-MS direct/forwarding transmissions. For such interference-mitigating mechanisms to work, we need neighbor discovery schemes to determine the distances between pairs of nodes. Sungcheol: I think we don't allow that. If it is guaranteed that two HR-MSs are far enough, two HR-MSs may transmit on the same resources. However, how can it be guaranteed? Interference mitigation has been a challenging research topic. But I don't agree that 16n specification adapts interference management approaches because its complexity. (Do we consider direct communication among HR-MSs in the same cell? I am negative) Anh Tuan: For the spatial reuse of resource allocated to HR-MS direct transmissions, I am open to the possibility. However, as mentioned in previous email, I share Sungcheol's concern of interference mitigation. In fact, Eldad has also previously discussed this interference concern. To me, even without reusing allocated resource, controlling interference between HR-MSs direct communications and legacy transmissions (between HR-BS and HR-MS) is tough enough. Having said that, I do not see how reserving a fixed resource for HR-MS direct transmissions would better minimize interference, compared to the approach when BS allocates resource dynamically, but without two transmissions sharing (re-using) the same logical resource units. Eldad I think that allowing the HR-BS to allocate MS-MS resources dynamically, in combination with good HR-MS discovery and spatial separation, should allow the HR-BS to determine the correct resources. We do not specify that the HR-BS must share resources but on the other hand we do not prevent it from doing so. In my opinion, MS-MS connections that aren't allowed to share resources will not be very efficient. Question-2): Is the HR-BS allowed to re-use the same resources for its own DL transmissions or the UL transmissions of one of its HR-MS (assuming that the HR-MS is close enough to the HR-BS)? Anh Tuan: Similar to answer to question 1 with the note that interference mitigation will depend on whether HR-MS direct/forwarding transmissions are scheduled in DL or UL area of each frame. Sungcheol: Generally I think that resource used for infrastructure communication is exclusive to resource for direct communication. From this agreement, we can extend resource usages if its algorithm is simple. Exclusive resource allocation guarantees that interference each other may be controlled easily. Eldad: I think the answer is very similar to question-1. While the specific interference mechanism depends if transmission takes place in UL or DL or both, good interference control mechanisms as indicated above should solve both. Question-3): Are these resources fixed for all cells? Anh Tuan: I believe that HR-MS direct communications and forwarding to network are opportunistic in nature. Therefore, resources should be dynamically allocated across space (cells), time/frequency (frames). Sungcheol: We need fixed resources of direct communications for all cells if HR-MS may be at several radio environment cases including under infrastructure node, in absent of infrastructure not, and in the middle of infra-structure nodes. It is recommended that this fixed resource shall be as small as possible because the resource is not be used by infrastructure node for interference avoidance. Eldad: I would support Anh Tuan. Sungcheol: We need to separate DC specific resources into two. One is for the usage case of direct communication that two HR-BSs are under the coverage of infrastructure node. Dynamic resource allocation can be acceptable for this use case only. The other is for two usage cases that 1) one HR-MS under infrastructure node coverage and the other HR-MS in absent of infrastructure node 2) two HR-MSs in absent of infrastructure node. When we consider HR-MS in absent of HR-BS, dynamic resources allocation information is carried on the fixed resource of direct communication. It's why I propose two-step resource allocation. Anh Tuan: I would like to promote the following general approach for allocating resource dynamically to HR-MS direct/forwarding transmissions: - When both HR-MSs are within the coverage of an infrastructure node, say HR-BS, HR-BS can dynamically schedule resource using A-MAP and/or other DL control messages. - When only one HR-MS is within the coverage, the resource can still be scheduled by HR-BS through A-MAP and control messages, and the inside-of-coverage HR-MS shall relay the scheduling information to the out-of-coverage HR-MS. - When there is no infrastructure node, one HR-MS shall be elected as network coordinator to fulfill the scheduling tasks of an infrastructure node. The above approach, I believe, preserves the basic resource-allocating principles of 16e/m. Eldad: I also would like to partition the use cases for resource allocations but I think that both HR-MS under HR-BS is similar to forwarding HR-MS (only one under HR-BS). The case of no HR-BS is different. Because of that, I tend to agree with Anh Tuan that resource allocation for HR-MS forwarding and HR-MS DC under HR-BS is dynamic (e.g. using A-MAP although we can decide that later). For no infrastructure case I agree that one of the HR-MS takes control. I’m not sure yet what is the nature of an coordinator. It looks to me very similar to an HR-BS. Sungcheol: My approach is a distributed way. If we find a distributed solution of coordination among the HR-MS, there is no coordinator similar to an HR-BS. As you know, 802.11 terminals are synchronized in a distributed approach. We can make the modification of the distributed synchronization algorithm. Eldad: I wouldn’t want to use 802.11 as a model. Sungcheol: Please refer to the third answer to Topic B. Question-4): Can they change over time? Anh Tuan: Similar to answer to question-3. Sungcheol: It depends on design. The fixed resource of direct communication is static and limits resources for infrastructure communications. To solve this problem, the fixed resource is reserved at minimum and additional resource information can broadcast on the fixed resource. Its additional resource may be quasi-static and cell specific if possible. How about two step resource of direct communication? Eldad: I would support Anh Tuan. I'm not sure what a two-step resource allocation means but does it lengthens latency? Sungcheol: No. It does not length latency. Control information including resource allocation shall be carried on common dedicated resource. It's all. Common or dynamic resource can be used for carrying data packets among HR-MSs because the HR-MSs have exchanged resource allocation information each other using control packets on the common dedicated resource.. Eldad: Thanks, Sungcheol, now I think I understand you. It seems we all agree to dynamic resource allocation. So if, for example, we use A-MAP to carry the assignment, then the only question that remains is that whether A-MAP location, length etc. are A) fixed for all cells and for all times or B) can vary cell to cell and time to time and are SOMEHOW signaled (broadcast or unicast) to HR-MS. Is that correct? Sungcheol: Generally yes. In my approach, common resource is a fixed resource independent of cells while dynamic resources can be allocated cell by cell. We need more discussion about the form of control information. But, Please refer to my second answer to Topic B at first. >>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<< Topic D Sungcheol: For frame structure of direct communication, we need discuss types of DC specific resources, TDM and FDM separations. TDM means that its bandwidth of DC specific resources is wideband. FDM means that narrowband resources can be reserved for DC specific resources. I prefer that the DC resources shall be allocated as narrowband because of its coverage enhancement. So I have a preference to FDM for DC specific resource separation. Is there any reason that DC specific resource shall be FDM in 16n specification based on 16m specification? (I understand that TDM is a way of DC specific resource allocation for 16e specification because diversity zone and AMC zone are exclusive in time domain) Anh Tuan: Regarding TDM vs FDM, current approach in 16m is based on FDM (within each subframe). So FDM to me is a natural approach. However, I propose that we stick to the 16m subframe boundaries when doing resource allocation for HR-MS direct comm/forwarding. Do we have a strong reason/motivation for allocating a narrow band resource spanning several subframes for a HR-MS direct transmissions? Eldad: - If you meant FDM per sub-frame I would agree with you, we go FDM. Otherwise it's usually called TDM/FDM. - If you accept the premise that resources are allocated by the BS then we don't have to decide here whether it's broadband or narrowband. - 802.16m already has a long-TTI mechanism for added robustness. I'm not sure we need another one. Sungcheol: We need to separate discussions into two like my answer to Question-3). For the use case that two HR-BSs are under the coverage of infrastructure node, we need to follows 16m or 16e frame structure as similar as possible. For the other use case, we need to define DC specific frame structure because HR-MSs in absent of HR-BS are not aware of infrastructure frame structure. Anh Tuan: I just want to clarify: -When at least one HR-MS is within the coverage, the frame configuration (and resource allocation) can be forwarded to the other HR-MS. -In absent of HR-BS, a network coordinator can be elected to distribute a common understanding of frame configuration among a cluster of HR-MSs. Eldad: Please see my comments for previous question. Regarding narrowband operation for 802.16n, I have indicated above that 802.16m already has long-TTI operation. The combination of long TTI with the narrowest allocation allowed today under 802.16m should provide sufficient coverage. I don’t see any reason to design new waveforms, pilot placement, etc. to accommodate even narrower bandwidth. Sungcheol: There are two reasons that usage of DC specific resource is different from one of infrastructure frame. 1) Two additional channels are introduced for synchronization and initial packet transmission. For synchronization channel, I don’t believe that its resource unit is similar to one for traffic transmission. For contention channel, An initial packet is designed as small as possible. When we put large number of contention slots, we reduce contention probability. 2) Coverage limitation. My preference is extending signal coverage for direct communication. When we decide to use the same resource unit, it means that the coverage of direct communication is limited because MS-to-MS channel characteristics are different to BS-to-MS channel ones. But we are now developing resource unit for direct communication with performance evaluation. Currently I don’t propose the size of resource unit. Eldad: Please let me understand - for 1): The channels for synchronization and initial packet transmission – are they new waveforms? If I understand correctly you prefer smaller frequency domain allocations for random access? Is this for the CDMA code or for the OFDM packet? Sungcheol: It’s kind of OFDMA packets, not the CDMA code because of its complexity. Yes, I prefer smaller frequency domain allocations for all the OFDMA packet of direct communication. It’s for coverage extension. We consider smaller frequency domain allocation of dedicated resources for direct communication. Packets for synchronization and contention has the same frequency domain allocation (or may be smaller than). We are under design. The result come from performance comparision. ________________________________ |