Compliance with IEEE Standards Policies and Procedures

Transcription

1 Compliance with IEEE Standards Policies and Procedures Subclause of the IEEE-SA Standards Board Bylaws states, "While participating in IEEE standards development activities, all participants...shall act in accordance with all applicable laws (nation-based and international), the IEEE Code of Ethics, and with IEEE Standards policies and procedures." The contributor acknowledges and accepts that this contribution is subject to The IEEE Standards copyright policy as stated in the IEEE-SA Standards Board Bylaws, section 7, and the IEEE- SA Standards Board Operations Manual, section 6.1, The IEEE Standards patent policy as stated in the IEEE-SA Standards Board Bylaws, section 6, and the IEEE-SA Standards Board Operations Manual, section 6.3, 1

2 Way forward for RoE in xran March 218 -Milan Richard Maiden Intel Khalid Al-Mufti Commscope Lujing Cai AT&T Wessam Afifi - Mavenir Kevin Bross Intel Remus Tan - Cienna Alex Sun - Intel

3 Background - Standard / industry bodies Type IEEE CPRI xran Global standards body Small closed industry body Growing open industry body Participation No restrictions 5 companies Paid up members Access All participants 5 companies and upon release Voting rights Individuals based on participation Paid up members and upon release 5 companies Participating, paid up members/companies Patent and copyright Difficult to summarize. See relevant website The way forward for RoE in xran March Milan 3

4 Introduction xran white paper calls out IEEE for transport. xran White Paper October 217, Stage 1 Agreements The Ethernet framing and timing synchronization would leverage IEEE and IEEE 82.1cm for developing Ethernet transport solutions ecpri is also mentioned. It is difficult to see how ecpri or RoE would change their common headers. This contribution shows how equal or equivalent ecpri header information can be mapped/encapsulated into RoE. Since xran contributions are limited to xran members, information here is limited to publicly available information (ecpri) Payload contents are not discussed here. The way forward for RoE in xran 4

5 Comparing RoE and ecpri Headers

6 Focus Focus here is on the header information and the most important types (Frequency domain) IQ data Control Value ecpri message type IQ Data 1 Bit sequence 2 Real time control data 3 Generic data transfer 4 Remote memory access 5 Delay measurement 6 Remote reset 7 Event indication Value RoE subtype Control 2 Structure Agnostic 3 Structure Aware 4 Slow C&M 16 Native Time 17 Native Frequency IQ 18 PRACH Experimental The way forward for RoE in xran 6

7 ecpri vs. RoE common header ecpri Common Header Version Rsv d C Message Type Payload Size plus ID bytes (used in IQ data / control) Version Rsv d C Message Type Payload Size PC_ID / RTC_ID SEQ_ID RoE common header subtype flowid length orderinfo The way forward for RoE in xran 7

8 ecpri version Version Rsv d C Message Type Payload Size PC_ID / RTC_ID SEQ_ID subtype flowid length orderinfo Not included in RoE header. RoE considered version exchange as out-of-band negotiation. Can be accommodated in xran payload or out-of-band negotiation. 8

9 ecpri C - Concatenation Version Rsv d C Message Type Payload Size PC_ID / RTC_ID SEQ_ID subtype flowid length orderinfo Not considered in RoE Can be accommodated in xran payload or out-of-band negotiation. 9

10 ecpri Message Type Version Rsv d C Message Type Payload Size PC_ID / RTC_ID SEQ_ID subtype flowid length orderinfo Equivalent to RoE subtype Could be mapped easily Value RoE subtype Control 2 Structure Agnostic 3 Structure Aware 4 Slow C&M 16 Native Time 17 Native Frequency IQ 18 PRACH xran subtypes Experimental 1

11 ecpri Payload Size Version Rsv d C Message Type Payload Size PC_ID / RTC_ID SEQ_ID subtype flowid length orderinfo Equivalent to RoE length field. Tiny delta on start position (RoE includes orderinfo as common header, ecpri considers this payload) 11

12 ecpri PC_ID/RTC_ID & SEQ_ID Version Rsv d C Message Type Payload Size PC_ID / RTC_ID SEQ_ID subtype flowid length orderinfo ecpri is not clear (vendor specific) on how these fields are used text on next slide. PC_ID is similar to flowid SEQ_ID is similar to orderinfo (as seqnum) RoE includes details on how to parametrize counters in the seqnum, ecpri leaves this vendor specific. 12

13 ecpri vendor specific series identifiers PC_ID: (IQ Data messages) An identifier of a series of IQ Data Transfer messages. For example, identifier of a physical channel, a user, a layer, an antenna port, etc. which has a common property for PHY processing. How to allocate values to PC_ID is vendor specific. RTC_ID: (Control messages) An identifier of a series of Real-Time Control Data messages. For example, identifier for message structures of specific control / configuration / status /measurement and request / response / indication types. How to allocate values to RTC_ID is vendor specific. SEQ_ID: (IQ data and Control messages) An identifier of each message in a series of IQ Data Transfer messages. For example, identifier of an OFDM symbol, a block of sub-carriers, etc. How to allocate values to SEQ_ID is vendor specific 13

14 Summary Version Rsv d C Message Type Payload Size PC_ID / RTC_ID SEQ_ID subtype flowid length orderinfo 14

15 Way forward for RoE in xran Richard Maiden Intel Khalid Al-Mufti Commscope Lujing Cai AT&T Wessam Afifi - Mavenir Kevin Bross Intel Alex Sun - Intel

16 The way forwards There is no compelling technical reason to select one header format over another. As shown here, both headers fundamentally carry the same information in different positions. IEEE1914 have already discussed reserving subtype values for xran and have had liaisons with xran. IEEE1914 and xran share 5-1 common active participants and are already working together. Because of the type of institution, the majority of these shared participants prefer to use IEEE common header as the foundation of the fronthaul interface. 16

17 Action points 1. IEEE to reserve subtypes for xran a) 16 or 32? 2. IEEE to demonstrate & describe this suggested way forwards to xran 3. Few details to be closed a) Version byte (xran to include in payload or out-of-band) b) Concatenation feature required? c) Length starting point (payload includes orderinfo) d) seqnum usage (vendor specific in ecpri) Longer term: Jointly work on payload for new subtypes e.g. IQ compression, rbmap, Control and split 7.2 extensions Continue to fill in gaps The way forward for RoE in xran 17