1. Spring 2006UCSC CMPE2571 CMPE 257: Wireless Networking SET MAC-2: Medium Access Control Protocols

2. Spring 2006UCSC CMPE2572 NAMA Improvements n Inefficient activation in certain scenarios. p For example, only one node, a, can be activated according NAMA, although several other opportunities exist. —— We want to activate g and d as well. a f g c d e h b 10 1 6 4 7 3 8 5

3. Spring 2006UCSC CMPE2573 Node + Link (Hybrid) Activation n Additional assumption p Radio transceiver is capable of code division channelization (DSSS —— direct sequence spread spectrum) p Code set is C. n Code assignment for each node is per time slot: i.code = i.prio mod |C |

4. Spring 2006UCSC CMPE2574 Hybrid Activation Multiple Access (HAMA) n Node state classification per time slot according to their priorities. p Receiver (Rx): intermediate prio among one- hop neighbors. p Drain (DRx): lowest prio amongst one-hop. p BTx: highest prio among two-hop. p UTx: highest prio among one-hop. p DTx: highest prio among the one-hop of a drain.

5. Spring 2006UCSC CMPE2575 HAMA (cont.) n Transmission schedules: p BTx —> all one-hop neighbors. p UTx —> selected one-hops, which are in Rx state, and the UTx has the highest prio among the one-hop neighbors of the receiver. p DTx —> Drains (DRx), and the DTx has the highest prio among the one-hops of the DRx.

6. Spring 2006UCSC CMPE2576 HAMA Operations n Suppose no conflict in code assignment. n Nodal states are denoted beside each node: p Node D converted from Rx to DTx. p Benefit: one-activation in NAMA to four possible activations in HAMA. a f g c d e h b 10-BTx 1-DRx 6-Rx 4-DRx 7-UTx 3-DRx 8-Rx 5-DTx

7. Spring 2006UCSC CMPE2577 Other Channel Access Protocols n Other protocols using omni-directional antennas: p LAMA: Link Activation Multiple Access p PAMA: Pair-wise Activation Multiple Access n Protocols that work when uni-directional links exist. p Node A can receive node B’ s transmission but B cannot receive A’ s. n Protocols using direct antenna systems.

8. Spring 2006UCSC CMPE2578 Comparison of Channel Access Probability

9. Spring 2006UCSC CMPE2579 Protocol Throughput Comparison

10. Spring 2006UCSC CMPE25710 Comments n Scheduled-access protocols are evaluated in static environments and what about their performance in mobile networks? n Neighbor protocol will also have impact on the performance of these protocols n Need comprehensive comparison of contention-based and scheduled access protocols.

11. Spring 2006UCSC CMPE25711 References n [R01] S. Ramanathan, A unified framework and algorithm for channel assignment in wireless networks, ACM Wireless Networks, Vol. 5, No. 2, March 1999. n [BG01] Lichun Bao and JJ, A New Approach to Channel Access Scheduling for Ad Hoc Networks, Proc. of The Seventh ACM Annual International Conference on Mobile Computing and networking (MOBICOM), July 16-21, 2001, Rome, Italy. n [BG02] Lichun Bao and JJ, Hybrid Channel Access Scheduling in Ad Hoc Networks, IEEE Tenth International Conference on Network Protocols (ICNP), Paris, France, November 12-15, 2002.

12. Spring 2006UCSC CMPE25712 References n [IEEE99] IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std 802.11-1999. n [TK84] H. Takagi and L. Kleinrock, Optimal Transmission Range for Randomly Distributed Packet Radio Terminals, IEEE Trans. on Comm., vol. 32, no. 3, pp. 246-57, 1984. n [WV99] L. Wu and P. Varshney, Performance Analysis of CSMA and BTMA Protocols in Multihop Networks (I). Single Channel Case, Information Sciences, Elsevier Sciences Inc., vol. 120, pp. 159-77, 1999. n [WG02] Yu Wang and JJ, Performance of Collision Avoidance Protocols in Single-Channel Ad Hoc Networks, IEEE Intl. Conf. on Network Protocols (ICNP ’02), Paris, France, Nov. 2002.

13. Spring 2006UCSC CMPE25713 MAC Protocols Using Directional Antennas n Basic protocols n Directional Virtual Carrier Sensing (DVCS) n Directional MAC (D-MAC) in UDAAN

14. Spring 2006UCSC CMPE25714 MAC Protocols Using Directional Antennas The MAC protocols so far assume that a node ’ s transmissions reach all of its neighbors. n With powerful antenna systems, it is possible to limit transmissions and receptions to desired directions only. n This can increase spatial reuse and reduce interferences to neighbors nodes. n Caveat: p Not all neighbor nodes defer access. p Directional receiving is not always desired.

15. Spring 2006UCSC CMPE25715 Omni-Directional and Directional Transmissions Node A Node B Node C Node A Node B Node C  Omni-directional transmissionDirectional transmission

16. Spring 2006UCSC CMPE25716 Directional Antenna Models n Antenna systems  Switched beam – fixed orientation  Adaptive beam forming – any direction n Simulation models: p Complete signal attenuation outside the directional transmission beamwidth (  )  ``Cone plus ball ’’ model n Directional transmissions have higher gains p Possible to use power control to reduce the gain n Various medium access control schemes have been proposed and/or investigated (see Refs).Refs

17. Spring 2006UCSC CMPE25717 Basic Scheme One n OTOR (omni-transmit, omni-receive) p The usual omni RTS/CTS based collision avoidance p All packets are transmitted and received omni-directionally. p IEEE 802.11 MAC protocol uses such scheme.

18. Spring 2006UCSC CMPE25718 Basic Scheme Two n DTOR (directional-transmit, omni-receive) p Packets are transmitted directionally. p Packets are received omni-directionally. p Increased spatial reuse (+) and collisions (-). Talks btw. A & B, C & D can go on concurrently; – More collisions may occur; + Spatial reuse is increased; + Nodes spend less time waiting.

19. Spring 2006UCSC CMPE25719 Basic Scheme Three n DTDR (directional-transmit, directional-receive) p All packets are transmitted and received directionally. p Aggressive spatial reuse Talks btw. A & B, C & D can go on concurrently; – More collisions may occur; – Channel status info. is incomplete; + Aggressive spatial reuse; + Nodes spend less time waiting.

20. Spring 2006UCSC CMPE25720 Basic Scheme Four n MTDR (mixed transmit, directional receive) p CTS packets are transmitted omni-directionally while other packets are transmitted directionally. p Tradeoff between spatial reuse and collision avoidance D sends RTS to C directionally; C replies with omni-CTS; + A and G defer their access and won’t cause collisions; – However, A cannot talk with B at the same time.

21. Spring 2006UCSC CMPE25721 Predictions from the Analysis [WG03] n The DTDR scheme performs the best among the schemes analyzed. p Increased spatial reuse and reduced interference through directional transmissions. p Directional receiving cancels much interferences from neighbors and hidden terminals. n Throughput of the DTDR scheme with narrow beamwidth θ has a slightly increase when N increases. p Spatial reuse effect is more conspicuous. p Scalability problem is mitigated.

22. Spring 2006UCSC CMPE25722 Simulation Results [WG03] n Higher-gain directional transmissions have negative effects on throughput and delay. p More nodes are affected. n Influence of side lobes can be almost canceled out if: p The level of side lobes is reasonably low through the advancement of antenna systems. p Carrier sensing threshold is raised such that nodes are less sensitive to channel activities.

23. Spring 2006UCSC CMPE25723 Advanced Schemes n Directional Virtual Carrier Sensing ([TMRB02]) p Angle-of-Arrival (AoA) information available p Nodes record direction information and defer only to non-free directions (directional NAV) n UDAAN ([RRSWP05]) p Switched beam antenna p Experimental system was built to test the effectiveness of directional antenna systems

24. Spring 2006UCSC CMPE25724 Details on Directional NAV n Physical carrier sensing still omni- directional Virtual carrier sensing be directional – directional NAV p When RTS/CTS received from a particular direction, record the direction of arrival and duration of proposed transfer r Channel assumed to be busy in the direction from which RTS/CTS received

25. Spring 2006UCSC CMPE25725 n Nodes overhearing RTS or CTS set up directional NAV (DNAV) for that Direction of Arrival (DoA) X D Y C CTS Directional NAV (DNAV)

26. Spring 2006UCSC CMPE25726 n Nodes overhearing RTS or CTS set up directional NAV (DNAV) for that Direction of Arrival (DoA) X Y Directional NAV (DNAV) D C DNAV

27. Spring 2006UCSC CMPE25727 Directional NAV (DNAV) A B C θ DNAV D n New transmission initiated only if direction of transmission does not overlap with DNAV, i.e., if (θ > 0) RTS

28. Spring 2006UCSC CMPE25728 D-MAC  Forced Idle is to avoid starvation  FI-Busy ``aggressive’’  Tight integration with power control

29. Spring 2006UCSC CMPE25729 Directional Neighbor Discovery n Three kinds of links (neighbors) p N-BF, without beam forming p T-BF, using only transmit-only beamforming p TR-BF, using transmit and receive beamforming n Two methods for discovery p Informed discovery p Blind discovery

30. Spring 2006UCSC CMPE25730 Directional Packet Transmission A B B’s omni receive range D-O transmission AB B’s directional receive beam D-D transmission

31. Spring 2006UCSC CMPE25731 Related topics n Neighbor protocol and topology management n Energy efficiency n Routing

32. Spring 2006UCSC CMPE25732 References  [KSV00] Ko et al., Medium Access Control Protocols Using Directional Antennas in Ad Hoc Networks, in IEEE INFOCOM 2000.  [NYH00] Nasipuri et al., A MAC Protocol for Mobile Ad Hoc Networks Using Directional Antennas, in IEEE WCNC 2000.  [R01] R. Ramanathan, On the Performance of Ad Hoc Networks with Beamforming Antennas, ACM MobiHoc '01, Oct. 2001.  [TMRB02] Takai et al., Directional Virtual Carrier Sensing for Directional Antennas in Mobile Ad Hoc Networks, ACM MobiHoc ’ 02, June 2002.  [CYRV02] Choudhury et al., Medium Access Control in Ad Hoc Networks Using Directional Antennas, ACM MobiCom '02, Sept. 2002.  [WG03] Yu Wang and JJ, Collision Avoidance in Single-Channel Ad Hoc Networks Using Directional Antennas, in IEEE ICDCS '03.  [RRSWP05] Ramanathan et al., Ad Hoc Networking With Directional Antennas: A Complete System Solution, IEEE JSAC 2005.

33. Spring 2006UCSC CMPE25733 Acknowledgments n Parts of the presentation are adapted from the following sources: p Prasant Mohapatra, UC Davis, http://www.cs.ucdavis.edu/~prasant/ECS257 /NOTES/Adhoc-Sensor.ppt http://www.cs.ucdavis.edu/~prasant/ECS257 /NOTES/Adhoc-Sensor.ppt

34. Spring 2006UCSC CMPE25734 MAC Protocols for Networks with Multiple Channels n Motivation and issues n Summary of approaches n Examples n Open research problems

35. Spring 2006UCSC CMPE25735 n Multiple orthogonal channels available in IEEE 802.11 p 3 channels in 802.11b p 12 channels in 802.11a n Multiple channels available in general n Utilizing multiple channels can improve throughput and reduce delays p Allow simultaneous transmissions in the same 2-hop neighborhood. Motivation for Using Multiple Channels 1 defer 1 2 Single channelMultiple Channels

36. Spring 2006UCSC CMPE25736 Issues with Multiple Channels n Senders and receivers need to “meet” in one of many channels n Hidden and exposed terminals are now problems involving more than one channel p Similar problems than with space division n Each node may have one or multiple radios n Half duplex nodes, even with multiple radios per node: p At best, a node can receive or transmit over one or multiple radios, but not both n Synchronization is hard to avoid w/o a dedicated control channel.

37. Spring 2006UCSC CMPE25737 Approaches* 1. Dedicated Control Channel  Dedicated control radio & channel for all control messages  DCA[Wu2000], DCA-PC[Tseng2001], DPC[Hung2002]. 2. Split Phase  Fixed periods divided into (i) channel negotiation phase on default channel & (ii) data transfer phase on negotiated channels  MMAC[J.So2003], MAP [Chen et al.] 3. Common Hopping  All non-busy nodes follow a common, well-known channel hopping sequence -- the control channel changes.  HRMA[Tang & JJ 98], CHMA, CHAT, RICH [Tzamaloukas & JJ] 4. Parallel Rendezvous  Each node publishes its own channel hopping schedule  SSCH [Bahl04], McMAC [So et al] * Mo, So and Walrand, “Comparison of Multi-Channel MAC Protocols,” MSWIM 05.

38. Spring 2006UCSC CMPE25738 Approach 1: Dedicated Control Channel Dedicated control radio and control channel DCA[Wu2000], DCA-PC[Tseng2001], DPC[Hung2002]. 1. [Control Chan]: S ---- RTS (Suggested Data Chan.) --> R 2. [Control Chan]: S <-- CTS (Agreed Data Chan.) ---- R 3. [Control Chan]: (optional) S --- Reservation (broadcast) ---> All 4. [Data Chan]: Sender --- Data Packet ---> Receiver

39. Spring 2006UCSC CMPE25739 Dedicated Control Channel Ch3 Ch2 Ch1 Time Channel Rts (2,3) Cts (2) Rsv (2) Rts (3) Cts (3) Rsv (3) Data... Ack Data Ack Rendezvous & contention occur on the control channel. Legend: Node 1 Node 2 Note 3 Node 4 Node 1+2

40. Spring 2006UCSC CMPE25740 Nasipuri’s Protocol n Assumes N transceivers per host p Capable of listening to all channels simultaneously n Sender searches for an idle channel and transmits on the channel [Nasipuri99WCNC] n Extensions: channel selection based on channel condition on the receiver side [Nasipuri00VTC] n Disadvantage: High hardware cost (today!)* * In the future (~5 to 10 years), having 4 radios per node will be affordable

41. Spring 2006UCSC CMPE25741 Approach 2: Split-Phase n Time is divided into (equal) periods. n Each period consists of 2 phases: control (channel negotiation), data transfer. n Examples ae: MMAC[J.So2003] (UIUC), MAP [Chen2003] n Channel negotiation happens on a default channel. Nodes negotiate the channels to use. n RTS/CTS/Data on the separate channels

42. Spring 2006UCSC CMPE25742 Split-Phase Ch2 Ch1 Ch0 Time Channel Hello (1,2,3) Ack (1) Rsv (1) Channel negotiation on a common channel DataAckRtsCts Control Phase Data Transfer Phase DataAckRtsCts Hello (2,3)... Legend: Node 1 Node 2 Note 3 Node 4

43. Spring 2006UCSC CMPE25743 MMAC (So and Vaidya) n Assumptions p Each node is equipped with a single transceiver p The transceiver is capable of switching channels p Channel switching delay is approximately 250us r Per-packet switching not recommended r Occasional channel switching not to expensive p Multi-hop synchronization is achieved by other means

44. Spring 2006UCSC CMPE25744 MMAC n Idea similar to IEEE 802.11 PSM p Divide time into beacon intervals p At the beginning of each beacon interval, all nodes must listen to a predefined common channel for a fixed duration of time (ATIM window) p Nodes negotiate channels using ATIM messages p Nodes switch to selected channels after ATIM window for the rest of the beacon interval

45. Spring 2006UCSC CMPE25745 Preferred Channel List (PCL) n Each node maintains PCL p Records usage of channels inside the transmission range p High preference (HIGH) r Already selected for the current beacon interval p Medium preference (MID) r No other vicinity node has selected this channel p Low preference (LOW) r This channel has been chosen by vicinity nodes r Count number of nodes that selected this channel to break ties

46. Spring 2006UCSC CMPE25746 Channel Negotiation n In ATIM window, sender transmits ATIM to the receiver n Sender includes its PCL in the ATIM packet n Receiver selects a channel based on sender’s PCL and its own PCL p Order of preference: HIGH > MID > LOW p Tie breaker: Receiver’s PCL has higher priority p For “LOW” channels: channels with smaller count have higher priority n Receiver sends ATIM-ACK to sender including the selected channel n Sender sends ATIM-RES to notify its neighbors of the selected channel

47. Spring 2006UCSC CMPE25747 Channel Negotiation A B C D Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

48. Spring 2006UCSC CMPE25748 Channel Negotiation A B C D ATIM ATIM- ACK(1) ATIM- RES(1) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

49. Spring 2006UCSC CMPE25749 Channel Negotiation A B C D ATIM ATIM- ACK(1) ATIM- RES(1) ATIM- ACK(2) ATIM ATIM- RES(2) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

50. Spring 2006UCSC CMPE25750 Channel Negotiation A B C D ATIM ATIM- ACK(1) ATIM- RES(1) ATIM- ACK(2) ATIM ATIM- RES(2) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon RTS CTS RTS CTS DATA ACK DATA Channel 1 Channel 2

51. Spring 2006UCSC CMPE25751 Simulation Model n ns-2 simulator n Transmission rate: 2Mbps n Transmission range: 250m n Traffic type: Constant Bit Rate (CBR) n Beacon interval: 100ms n Packet size: 512 bytes n ATIM window size: 20ms n Default number of channels: 3 channels n Compared protocols p 802.11: IEEE 802.11 single channel protocol p DCA: Wu’s protocol p MMAC: Proposed protocol

52. Spring 2006UCSC CMPE25752 Wireless LAN - Throughput 30 nodes64 nodes MMAC DCA 802.11 MMAC shows higher throughput than DCA and 802.11 802.11 DCA MMAC Packet arrival rate per flow (packets/sec) 1 10 100 1000 2500 2000 1500 1000 500 Aggregate Throughput (Kbps) 2500 2000 1500 1000 500

53. Spring 2006UCSC CMPE25753 Multi-hop Network – Throughput 3 channels4 channels MMAC DCA 802.11 DCA MMAC Packet arrival rate per flow (packets/sec) 1 10 100 1000 Packet arrival rate per flow (packets/sec) 1 10 100 1000 Aggregate Throughput (Kbps) 1500 1000 500 0 2000 1500 1000 500 0

54. Spring 2006UCSC CMPE25754 Throughput of DCA and MMAC (Wireless LAN) DCA MMAC 2 channels 802.11 MMAC shows higher throughput compared to DCA 6 channels 802.11 2 channels 6 channels Aggregate Throughput (Kbps) 4000 3000 2000 1000 0 4000 3000 2000 1000 0 Packet arrival rate per flow (packets/sec)

55. Spring 2006UCSC CMPE25755 Analysis of Results n DCA p Bandwidth of control channel significantly affects performance p Narrow control channel: High collision and congestion of control packets p Wide control channel: Waste of bandwidth p It is difficult to adapt control channel bandwidth dynamically n MMAC p ATIM window size significantly affects performance p ATIM/ATIM-ACK/ATIM-RES exchanged once per flow per beacon interval – reduced overhead r Compared to packet-by-packet control packet exchange in DCA p ATIM window size can be adapted to traffic load

56. Spring 2006UCSC CMPE25756 Further Work Needed n Dynamic adaptation of ATIM window size based on traffic load for MMAC n Efficient multi-hop clock synchronization n Better uses of data segment n Multipoint communication support

57. Spring 2006UCSC CMPE25757 Approach 3: Common Hopping All idle nodes follow the same channel hopping sequence E.g., HRMA[Tang98], CHMA[Tzamaloukas2000], CHAT[Tzamaloukas2000] 1. [Common Channel]: S ---- RTS ---> R 2. [Next Common Channel]: everyone else [Same Channel]: S <-- CTS ---- R 3. [Same Channel]: S ---- Data ---> R All return to “Current Common Channel” after sending/receiving

58. Spring 2006UCSC CMPE25758 3. Common Hopping Ch2 Ch1 Ch0 Time Channel Idle nodes hop together in “ common channel ” Ch3 1234567891011 Cts, Data, Ack Enough for one RTS RTS (c to d) Legend: Node a Node b Note c Node d RTS (b to a)

59. Spring 2006UCSC CMPE25759 Main Limitations n The time any dialogue can last must be shorter than the time it takes for the common hopping sequence to revisit the channel being used. n Approach is useful only if sufficiently large numbers of channels are available. n Time sync is needed.

60. Spring 2006UCSC CMPE25760 Approach 4: Parallel Rendezvous n Nodes choose their own hopping sequences. n Nodes publish the seeds of their hopping sequences so nodes can track each other. n Key: Parallel rendezvous on multiple channels n Examples: p SSCH [Bahl et al.]: senders transmits only when receivers are on the same channel. p McMAC [So & Walrand]: senders can deviate from their published schedule temporarily to transmit.

61. Spring 2006UCSC CMPE25761 McMAC n Every node has a its own random hopping sequence called the“home channel”. n Hopping freq. is a parameter. n To Tx, sender S leaves its home channel to meet its receiver R with some probability p_tx. n If R’s channel is busy or R is away from home, S tries again later. n Otherwise, S and R exchanges Data/Ack.

62. Spring 2006UCSC CMPE25762 McMAC (no hopping) t=123456... Ch 1 Ch 2 Ch 3 Ch 4 n Sender needs to know the home channel of the receiver, but time sync. is not needed. ??

63. Spring 2006UCSC CMPE25763 McMAC (with hopping) t=123456789 Ch1 Ch2 Original schedule

64. Spring 2006UCSC CMPE25764 McMAC (with hopping) t=123456789 Ch1 Ch2 1. Data arrives 4. Hopping resumes 3. Hopping stopped during data transfer 2. RTS/ CTS/ Data Original schedule

65. Spring 2006UCSC CMPE25765 Qualitative Comparison (True? Let’s Discuss!) Control Channel Split- Phase Common Hopping Parallel Rendez- vous # Radios 2111 Contention Bottleneck YYYN Time Sync. NLooseVery Tight Param. Track neighbors NNNY

66. Spring 2006UCSC CMPE25766 Simulation Parameters n N:# nodes n M: # channels n L:avg. packet length n T_sw:channel switch time n T_slot:slot time = RTS/CTS n S:link speed/channel (Mbps)

67. Spring 2006UCSC CMPE25767 Simulation Scenarios Scenario #1 Similar to 802.11b Scenario #2 Similar to 802.11a N: # nodes 2040 M: # chans 312 L: Avg Pkt Len 1024B /10240B (5/50 slots) 1024B /10240B (6.8/68 slots) T_sw: Switch Time 100us T_slot: Slot Time 810us200us S: Link Speed 2Mbps6Mbps

68. Spring 2006UCSC CMPE25768

69. Spring 2006UCSC CMPE25769 Dedicated Control Channel (short pkts) Time (slot) Channel

70. Spring 2006UCSC CMPE25770 Dedicated Control Channel (long pkts) Time (slot) Channel

71. Spring 2006UCSC CMPE25771 Time (slot) Channel Split Phase (30 control / 120 data slots)

72. Spring 2006UCSC CMPE25772 Time (slot) Channel Split Phase (12 control / 48 data slots)

73. Spring 2006UCSC CMPE25773 Time (slot) Channel Common Hopping (Short Pkts)

74. Spring 2006UCSC CMPE25774 Time (slot) Channel Common Hopping (Long Pkts)

75. Spring 2006UCSC CMPE25775 Time (slot) Channel McMAC hopping (Short Pkts)

76. Spring 2006UCSC CMPE25776 Time (slot) Channel McMAC hopping (Long Pkts)

77. Spring 2006UCSC CMPE25777

78. Spring 2006UCSC CMPE25778 Dedicated Control Channel (short pkts) Time (slot) Channel

79. Spring 2006UCSC CMPE25779 Common Hopping (short pkts) Time (slot) Channel

80. Spring 2006UCSC CMPE25780 McMAC hopping (short pkts) Time (slot) Channel

81. Spring 2006UCSC CMPE25781 Conclusions by Mo, So, and Walrand n Dedicated control channel: works surprisingly well esp. for long packets! n Split-phase: depends heavily on the control/data phase durations n Common-hopping: “fragmentation” problem n Parallel rendezvous: good potential, but synchronization is an issue.

82. Spring 2006UCSC CMPE25782 Research Opportunities n Few schemes based on contention have not addresses collision issues. n Efficient time sync is a requirement for multi-channel MACs, unless a dedicated control channel is used. n Can we map prior approaches for distributed code assignment for CDMA networks to multi-channel MACs by making a code to equal a hoping sequence? n Is topology-dependent scheduling inherently better than multiple rendezvous? p Impact of updating 2-hop neighborhood n What happens when radios become really cheap and a node can receive multiple concurrent transmissions? (Same if we have MUD with MIMO) p What scheduling advantages do we gain? p What MACs can we propose?