<恕删> : : : 问题一 : : : : 小弟念到spec中 6.3.6 Bandwidth allocation and request mechanisms : : : 对polling的功用有个疑问，spec中这样定义 : : : Polling is the process by which the BS allocates to the SSs bandwidth : : : specifically for the purpose of making bandwidth requests : : : 问题来的~ : : : SS得到BS的polling後，BS会在uplink时安排一段时间给该SS上传， : : : 而这段时间SS只能上传bandwidth request的讯息吗? : : 是的 : : : 或是该这样问 : : : : BS poll SS 的用意只是让SS可以回传Bandwidth REQ 吗(根据上文spec)? : : : BS有可能利用polling的方式， : : : 让SS有机会送别的管理讯息上来吗(例如 : DSA/C/D_REQ)? 照spec 6.3.6.3的最後一句话所说. BW is always requested on a ... on an SS basis. 说明了SS在提BW的request是以CID为basis, 也就是for除了UGS之外的每一条connection 在想要送东西之前, 必须以6.3.6.1所写之stand-alone的BW request header或者是用 piggyback的方式来为自己这一条connection提下一次的BW要求. (这些除了UGS的 connection, 当然也包括了那三条Management Connection) 另一方面, BS在收集了这麽多connection的要求之後(不一定是同一个SS), 会以SS为basis 给一个SS总total的grant (BS的implement issue, 不一定每个request BS都要给足 所有connection的要求, 在经计算之後, 将每一个SS的每一个connection的要求做加总, 填於下一个frame的UL_MAP中), 而SS在下一个frame的UL_MAP里就会看到这次BS所给 这个SS的所有可用时间长度, 而因为BS不一定会满足每一条connection, 所以有可能SS 收到的grant与所要求的不同, SS也一样依implement issue来自行决定, 这次拿到的时间 该如何来做分配. 所以举个简单的例子来说, 若BS可满足所有的connection的要求, SS就会发现他可以传送 所有他上次所要求的资料量, 此外, 还会有多出来的BW, 这多出来的是? 请看6.3.6.3.1 第一句 no explicit message is transmitted to poll the SS. Rather, the SS is allocated, in the UL_MAP, BW sufficient to respend with a BW Request. 也就是BS在加总SS的要求量之後, 还会再多加一点点BW给SS, 这一点点就是给SS做BW request用. : : 待SS送出BW request後自然就有bandwidth来收送其他的MAC message了 : : 基本上不应该一直用polling来grant bandwidth : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : 这个地方 有点不太了解您的意思 能再帮我解释清楚一点吗? : 在SPEC中不是规定了，除了UGS连线外，其他三类若需要频宽 都是需要经过 : BS polling SS => polled SS回 BW Req => BS在Uplink Grant时间给该SS ?? : : 一个延伸的问题 : : BS poll SS(指unicast poll)的频率多寡 在SPEC中有定吗(小弟我还没找到)? : 是一个frame只能有一个unicast poll吗? : (也就是说一个frame只去单问一台SS) : : 还有这个unicast poll大概都是 分配多少大小 的资源出去?? : 一个Bandwidth Request 的 Message 大小都是多少?? : : 这些地方我很没概念??? : 不知道有没有人也遇到类似的问题?? : 希望可以有新进 能给我一个整体的观念 ~ : : 十分感谢 ~ : : : : 因为在那时只有SS自己知道需要多少BW : : : 问题二 : : : : SS完成进入网路的的程序後 : : : 会与BS端建立起三条Management Connection : : : 分别是 : : : : Basic management connection : 传送 DBPC_REG/RSP, RNG_REQ/RSP ... : : : Primary management connection : 传送 DSX_REG/RSP , REG_REQ/RSP ... : : : Secondary management connection : 传送 DHCP, TFTP, SNMP 管理讯息 : : : 像这类的讯息也要参加contention吗?或是可以用polling的方式? : : 不用 透过BW request要到bandwidth後自然可以传送这些message : : : SS要用什麽样的方式得到 frame中的时间 送出这些讯息?? : : : 此外 ... : : : 之後，若SS想再建立一条Transport Connection(例如传送VoIP data)， : : : 小弟知道 需要由SS端initial送出DSA_REQ : : : But~ 这个DSA_REQ是要用竞争的方式来发送吗? : : : 还是BS会poll所有SS? 或是 ..... : : : SS可以用哪些方式来传送DSA/C/D这类的讯息?? : : : 恳请赐教~ : : 这个不太确定 : : 但照理讲是不应该透过contention channel来送MAC message的 : : 个人意见仅供参考~ : : -- :

※ 发信站: 批踢踢实业坊(ptt.cc) : ◆ From: 140.124.181.238 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.92.62.163