integration of ieee 802.16 and carrier ethernet · 2013. 3. 18. · integration of ieee 802.16 and...

Integration of IEEE 802.16 and Carrier Ethernet

Document Number: IEEE 802.16-13-0049-02-000r

Date Submitted: 2013-03-18

Source: Roger B. Marks Voice: +1 619 393 1913 EthAirNet Associates* E-mail: [email protected] 4040 Montview Blvd Denver CO 80207 USA *<http://standards.ieee.org/faqs/affiliationFAQ.html>

Re: Call for Contributions IEEE 802.16-13-0032-01-Gdoc

Base Contribution: If this presentation accompanies a base 802.16 contribution, cite its document number.

Purpose: To provide a tutorial on Carrier Ethernet as applicable to the P802.16r project and to stimulate and support discussion within the P802.16r project regarding Carrier Ethernet requirements.

Notice: This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.

Copyright Policy: The contributor is familiar with the IEEE-SA Copyright Policy <http://standards.ieee.org/IPR/copyrightpolicy.html>.

Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures:

<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>. Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >.

Integration of IEEE 802.16and Carrier Ethernet

• contribution IEEE 802.16-13-0010 (“Carrier Ethernet 2.0 Requirements for P802.16r”) said:– An understanding of the deployment architecture is

relevant to the understanding of the Carrier Ethernet 2.0 Requirements and may be relevant to establish other general aspects of the required functionality to be specified in the P802.16r project.

• This contribution is a followup.• Carrier Ethernet tutorial information is included.

2

Overview

• IEEE 802.16 can be enhanced to provide services to SS-side Carrier Ethernet users

• IEEE 802.16 can be enhanced to leverage BS-side Carrier Ethernet networks

• Can support independent 802.16 operators• Can support Carrier Ethernet network

operators who want to add wireless

3

Copyright © 2013 Consensii LLC

CEN

UNI

EVC

Customer-EdgeHost

1

2

3

Ethernet Virtual Connection

• CEN interconnects customer-edge Ethernet networks via Ethernet Virtual Connection (EVC)

• Customer-edge networks attach at a User-Network Interface (UNI)• Attributes of UNI, EVC, Services, etc. are specified by Metro Ethernet Forum

Carrier Ethernet Network (CEN)


CEN

UNI

EVCE-LineEPL

• Service Type: E-Line (point-to-point)• Service Basis: port-based

Ethernet Private Line (EPL) Service

5


CEN

UNI

EVC

E-LANEP-LAN

• Service Type: E-LAN (multipoint-to-multipoint)• Service Basis: port-based• Acts as a bridge

Ethernet Private LAN (EP-LAN) Service

6


CEN

UNI

EVC

E-TreeEP-Tree

Leaf Port

• Service Type: E-Tree (point-to-multipoint)• Service Basis: port-based• Acts as a bridge (but leaves forward only to roots)

Ethernet Private Tree (EP-Tree) Service

7


CEN

UNI

EVC

EVC 1EVPL

EVC2EVPL 2X,Y, no tag

1A,BEVCCE-VLAN

1A,BEVCCE-VLAN

2X,Y, no tagEVCCE-VLAN

• Service Type: E-Line (point-to-point)• Service Basis: VLAN-based• Service Multiplexing by CE-VLAN Tag (C-TAG) [CE: Customer-Edge]• V-LAN Coordination• Not transparent to customer VLAN

Ethernet Virtual Private Line (EVPL)

8


CEN

UNI

EVC

EVC2EVP-LAN

EVC1EVPL

2X,Y1A,BEVCCE-VLAN

2X,Y1A,BEVCCE-VLAN

2X,YEVCCE-VLAN

• Service Type: E-Tree (point-to-multipoint)• Service Basis: VLAN-based• Service Multiplexing by CE-VLAN Tag• V-LAN Coordination• Not transparent to customer VLAN• Acts as a bridge

Ethernet Virtual Private LAN (EVP-LAN) Service

9


CEN

UNI

EVC

EVC2EVP-Tree

EVC1EVPL

2X,Y1A,BEVCCE-VLAN

2X,Y1A,BEVCCE-VLAN

2X,YEVCCE-VLAN

Leaf Port

• Service Type: E-LAN (multipoint-to-multipoint)• Service Basis: VLAN-based• Service Multiplexing by CE-VLAN Tag• V-LAN Coordination• Not transparent to customer VLAN• Acts as a bridge (but leaves forward only to roots)

Ethernet Virtual Private Tree (EVP-Tree) Service

10


CEN

UNI

EVC

ENNI

OVC

OVC

• Interconnection between to Operator CENs• Supports EVCs with ports in multiple CENs• Assembled from Operator Virtual Connections (OVCs)

External Network-Network Interface (ENNI)

11


CEN

UNI

EVC

ENNI

OVC

OVC

EVC 1-4E-Line

OVC 3-4

OVC 1-2

1

23

4

From CE-VLAN

X

Map To

OVC 1-21

From Read S-Tag

N

Map To

OVC 3-43

From Add S-Tag

N2

From CE-VLAN

X4

coordinated

Point to Point OVCs

12


CEN

UNI

EVC

ENNI

OVC

OVC

EVC 1-4-5E-LAN

OVC 1-2

1

2

4

From CE-VLAN

X

Map To

OVC 1-21

Switched To

Endpoint4 or 5

(switched by MAC

address)

From Strip S-Tag

N

Map To

OVC 3-4-53

From Add S-Tag

N2From CE-VLAN

X4

35

OVC 3-4-5

From CE-VLAN

X5

coordinated

Point to Multipoint OVCs

13


CEN

UNI

EVC

ENNI

OVC

OVCBS

SSport

802.16ASN

SSport

SSport

802.16ASN

802.16 Access Network

14


CEN

UNI

EVC

ENNI

OVC

OVC

SLA difficult

noneCertification

Independent 802.16 OperatorOperator

Ethernet beyond the UNIFunction

Ethernet (not UNI-qualified)Ports

UNI with Service MultiplexingConnection to CEN

802.16

802.16ASN

Ethernet Port

BS

802.16 Use Case 1: Ethernet Bridge

15


CEN

UNI

EVC

ENNI

OVC

OVC

UNI-like

SLA difficult

self (initially)Certification


UNI-equivalent beyond the wired CENFunction

UNI-equivalentPorts

UNI with Service MultiplexingConnection to CEN

BS

SSport

802.16

SSport

SSport

802.16ASN

802.16 Use Case 1+: UNI-Like Ethernet Bridge

16


CEN

UNI

EVC

ENNI

OVC

OVC

SLA MEF-specified

MEF, as part of CENCertification

CEN OperatorOperator

UNI beyond the wired CENFunction

UNIPorts

arbitraryConnection to CEN

BS

SSport

802.16

SSport

SSport

ExpandedCEN

802.16ASN

802.16 Use Case 2: CEN Expansion


CEN

UNI

EVC

ENNI

OVC

OVC

SLA MEF-specified

MEFCertification


EVC beyond the wired CENService

UNIPorts

ENNIConnection to CEN

802.16

802.16ASNBS

802.16 Use Case 2+: Standalone CEN

18


CEN

UNI

EVC

ENNI

OVC

OVC

802.16 Control(AAA, etc.)

andData

DataData

ControlandData

802.16ASN

802.16 Network Backhaul Architecture - Merged Control and Data Path

19


CEN

UNI

EVC

ENNI

OVC

OVC


Data

Data

Control

802.16ASN

802.16 Network Backhaul Architecture - Separate Control and Data Path

20


CEN

UNI

EVC

ENNI

OVC

OVC


Core

Core

Ethernet Port

802.16SS

b

a

SS1

SS2

a

b

Network Architecturewith Typical Scenario

802.16ASN

21


• Bridging is not explicit in the 802.16 architectural model

• 802.16 does not specify bridge operation⁃ ISS support specified in 802.16k (amendment 802.1D)

⁃ does not directly specify bridging⁃ RFC 5692 specifies bridging (details below)⁃ 802.1Q and VLAN-aware bridging not addressed

Bridging in 802.16

22


Figure 1-1—IEEE 802.16 protocol layering, showing SAPs

Service Specific

Convergence Sublayer

(CS)

MAC Common

Part Sublayer

(MAC CPS)

Physical Layer

(PHY)

MA

CP

HY

Data Plane Management/Control Plane

Management Plane

Ne

twork

Contr

ol an

d M

an

ag

em

ent S

yste

m

Security Sublayer

Scope of 802.16 standard

MAC_SAP

PHY_SAP

CS_SAP

CX Management Part

Distributed Radio

Resource Management

Distributed Coexistence

Information Database

Coexistence Protocol

(CXP)

Management

Information Base (MIB)

C_

SA

PM

_S

AP

802.16 Entity

IEEE 802.16-2012 Architecture


• bridging forwards frames to bridge ports⁃ 802.16 MAC transports data on connections⁃ connections are currently identified by SS, not by end port⁃ connection should connect bridge port to SS port

• possible solutions:(1) forward frames from BS to a single port per SS

⁃specified in RFC 5692⁃unnecessary and duplicative bridging burden in SS⁃add'l bridging management over the air

(2) insert a tag (such as S-Tag)(3) bridge-centric architecture using port identification

Bridging Issues

24


RFC 5692 ("Transmission of IP over Ethernet over IEEE 802.16 Networks") says:

• "The BS MUST forward all the service flows belonging to one SS to one port of the network-side bridging function."

• "If the Ethernet over IEEE 802.16 is extended to multiple end stations behind the SS…, then the SS SHOULD support bridging according to [802.1D] and its amendment [802.16k], a.k.a. subscriber-side bridge, between all its subscriber-side ports and the IEEE 802.16 air link."

Notes:• In RFC 5692, bridge may serve multiple BSs; here only one • RFC 5692 is not referenced in IEEE 802.16-2012

Bridge Solution (1): single port per SS

25


• An additional port identification field could be inserted into the frame

for example, as an S-Tag• This extra over-the-air multiplexing overhead is unnecessary,

since the connection methodology already provides path separation.

Bridge Solution (2): insert a tag

26


multiple Connections per SS Portone SS Port per Connection

Connections labeled by SS Port

802.1QBridge

SS bSS a

BS in

multiple SS Ports per SSone SS per SS Port

MAC CPS

PHY

unidirectionalConnections

One CS instance per SSPort-aware CS

BS Port

SS Port 1

SS Port 2

SS Port 3

SS Port 1

SS Port 2

SS Port 3


BridgeSolution (3)

all Connections linked via PHY[several examples highlighted]

Bridge-Centric Architecture

27


multiple Connections per SS Portone SS Port per Connection

Connections labeled by SS Port

802.1QBridge

SS bSS a

BS in

multiple SS Ports per SSone SS per SS Port

MAC CPS

PHY

unidirectionalConnections

One CS instance per SSPort-aware CS

BS Port

SS Port 1

SS Port 2

SS Port 3

SS Port 1

SS Port 2

SS Port 3


BridgeSolution (3)

all Connections linked via PHY[several examples highlighted]

multiplex ↓

demultiplex ↓MAC SAP MAC SAP MAC SAP

multiplex ↑

demultiplex ↑

demultiplex ↓ multiplex ↑

multiplex ↓ demultiplex ↑

Bridge-Centric Architecture

27a

MAC Service indication ( destination_address, source_address, mac_service_data_unit, priority, drop_eligible, frame_check_sequence, service_access_point_identifier connection_identifier)

request ( destination_address, source_address, mac_service_data_unit, priority, drop_eligible, frame_check_sequence, service_access_point_identifier connection_identifier)

• Looks like 802.1Q ISS • service_access_point_identifier is the port identifier • But how to specify it in a 802.1Q protocol?

27b


UNI-N

UNI-C

VLAN C-Tag Demultiplexing

Bridging

Connection Mapping

PHSApply

MAC CPS

PHY

SS1 SS2SS1

Port a SS1

Port bSS2

Port a SS2

Port b UNI-N

UNI-C

VLAN C-Tag Multiplexing

PHSRestore

MAC CPS

PHYDownlink, Use Case 1+


BSPort

Bridgingper

VLAN

Connections

Forward to bridge based

on C-Tag, using

configured EVC table.

Note: Need not be processed in sequence shown

28


UNI-N

UNI-C

VLAN Multiplexing

Bridging

PHSRestore

MAC CPS

PHY

UNI-N

UNI-C

VLAN Demultiplexing

Connection Mapping

PHSApply

MAC CPS

PHY

BSPort

CS

Uplink, Use Case 1+

CS

SS1 SS2SS1

Port a SS1

Port bSS2

Port a SS2

Port b

Bridgingper

VLAN

29


UNI-N

UNI-C

VLAN C-Tag Demux/Strip

Bridging

Connection Mapping

PHSApply

MAC CPS

PHY

SS1 SS2SS1

Port a SS1

Port bSS2

Port a SS2

Port b UNI-N

UNI-C


Add VLANC-Tag

PHSRestore

MAC CPS

PHYDownlink, Use Case 1+, VLAN C-Tag Stripping


BSPort

30


UNI-N

UNI-C

VLAN Multiplexing

Bridging

PHSRestore

MAC CPS

PHY

UNI-N

UNI-C

VLAN Demultiplexing

Connection Mapping

PHSApply

MAC CPS

PHY

BSPort

CS

SS1 SS2SS2

Port a SS2

Port bSS1

Port a SS1

Port b

Uplink, Use Case 1+, VLAN C-Tag Stripping

CS

31


UNI-N

UNI-C

InitialClassification

Bridging

Connection Mapping

PHSApply

MAC CPS

PHY

SS1 SS2SS2

Port a SS2

Port b UNI-N

UNI-C


Add VLANC-Tag

PHSRestore

MAC CPS

PHYDownlink, Use Case 1+, Pre-Classification


BSPort

SS1Port a

SS1Port b

32


UNI-N

UNI-C

VLAN Multiplexing

Bridging

Connection Mapping

PHSApply

MAC CPS

PHY

SS1 SS2SS1

Port aSS1

Port bSS2

Port a SS2

Port b UNI-N

UNI-C

InitialClassification

Connection Mapping

PHSApply

MAC CPS

PHY

BSPort

Uplink, Use Case 1+, Pre-Classification

CS CS

33


ENNI-N

ENNI-N

S-Tag strip and forward

Bridging

Connection Mapping

PHSApply

MAC CPS

PHY

SS1 SS2SS1

Port a SS1

Port bSS2

Port a SS2

Port b ENNI-N

ENNI-N

Add egress S-Tag

PHSRestore

MAC CPS

PHYDownlink, Use Case 2+, ENNI to ENNI


BSPort

Add egress S-Tag using configured OVC table.

Strip ingress S-Tag.


on S-Tag, using

configured OVC table.


34


S-Tagging & Multiplexing

Bridging

PHSRestore

MAC CPS

PHY

S-Tag Demultiplexing

S-Tag Stripping

Connection Mapping

PHSApply

MAC CPS

PHY

BSPort

CS

Uplink, Use Case 1+

CS

SS1 SS2SS1

Port a SS1

Port bSS2

Port a SS2

Port bENNI-N

ENNI-N

ENNI-N

ENNI-N

35


ENNI-N

ENNI-N

S-Tag strip and forward

Bridging

Connection Mapping

PHSApply

MAC CPS

PHY

SS1 SS2SS1

Port a SS1

Port bSS2

Port a SS2

Port b UNI-N

UNI-C

PHSRestore

MAC CPS

PHYDownlink, Use Case 2+, ENNI to UNI


BSPort

Strip ingress S-Tag.


on S-Tag, using

configured OVC table.


36


CEN

UNI

EVC

ENNI

OVC

OVC

Dual-Mode Cell

802.16ASN

802.16 Control(AAA, synch etc.)

EPC

EPC

802.16 BS Ports

a

bSS1

SS2

a

b

X2

802.16SS Ports

Small-CellBackhaulExample

Dual-Mode Cell

LTE

LTE

Wi-Fi


Upper Layer Entity (e.g., bridge, router, host)

DLClassification

CID 1

SAP

IEEE 802.16 MAC CPS

SAP

IEEE 802.16 MAC CPS

Upper Layer Entity (e.g., bridge, router, host)

BS SS

{SDU, CID...} {SDU, CID, ..}

SDU SDU

Reconstitution(e.g., undo PHS)

SAP SAP

Figure 5-5—Classification and CID mapping (BS to SS)

Rule

CID 2

...

CID n

Classification (IEEE Std 802.16-2012):Properties of a Connection include:

Connection ID (CID)SS IDQoS parametersClassification rules (with priorities)

During classification, Convergence Sublayer (CS) does:parse frameidentify table of all applicable rules

all rules are eligiblecompares frame elements to rules, in priority orderassigns frame to first CID that satisfies a rule

Classification (proposed enhancement):Properties of a Connection include:

Connection ID (CID)SS ID & global Port ID [could be SS ID & SS-Local Port ID]QoS parametersClassification rules (with priorities)

During classification, Convergence Sublayer (CS) does:parse frameidentify table of all applicable rules

include only rules that map to the egress portcompares frame elements to rules, in priority orderassigns frame to first CID that satisfies a rule

Matching Connections and Ports

38

Needed IEEE 802.16 Enhancement: Bridging

• Specify bridging at BS port– Currently, IEEE Std 802.16k (amendment to 802.1D)

specifies the means for 802.1D bridging service to operate with the IEEE 802.16 Packet Convergence Sublayer

– Need to introduce bridging explicitly into the 802.16 architecture

– Need to also specify operation of VLAN-aware Bridge supporting the 802.1Q ISS & EISS service• Consider use of service_access_point_identifier and

connection_identifier service primitive parameters– Avoid additional bridging at the SS.

39

Needed IEEE 802.16 Enhancement:Port ID per Service Flow

• Add Port ID parameter to “Service flow encodings” (Table 11-53) to identify SS Port– Multiple service flows can service each Port

• based on, for example, QoS or PHS issues– Need a globally-unique Port ID parameter

• Could be SS ID plus unique SS-Local Port ID.– Associate Service Flow with global Port ID.– Bridge identifies incoming SS frames by source Port,

and assigns outgoing SS frames to destination Port.– Any Connection associated with the correct global Port

ID will deliver the frame to the right Port.

40

Needed IEEE 802.16 Enhancement:Bridge-Aware Packet CS

• Enhance “IEEE 802.3/Ethernet-specific part” of Packet Convergence Sublayer

• Ensure that the CS is aware of (a) the Bridge Port of the frame and (b) the Port ID of each connection– CS will identify Port to bridge at bridge ingress– CS empowered to assign MAC-bound PDUs only to

connections associated with designated Bridge Port– Incoming CS data at SS will be forwarded to the

correct port based on Port ID– Dedicate an SS port for SS management.

41

Applicability of GPCS

• IEEE Std 802.16 offers an alternative CS: General Packet Convergence Sublayer (GPCS)

• Detailed GPCS functionality is declared out of scope.– Specification of CS functionality is critical to meeting

Carrier Ethernet QoS requirements.• GPCS multiprotocol feature is not relevant to

Carrier Ethernet.• Carrier Ethernet demands a specific CS, not a

generic one.

42

Support of Ethernet Hostsbeyond the SS Port

• For multiple hosts beyond the SS Port, bridging beyond the SS Port is needed– Not part of the IEEE 802.16 SS

• The architecture supports the external bridge• The architecture allows for some efficiency

optimization– For example: For a frequently-addressed 802.3 MAC

destination outside the SS, a Connection can be initiated for that destination alone in order to make use of payload header suppression, suppressing the destination address

43

Metro Ethernet Forum (MEF) functionality and attributes needed

• Carrier Ethernet requirements go well beyond the architecture.

• The Metro Ethernet Forum specifies many functionalities and attributes

• Many Carrier Ethernet 2.0 requirements are in:– Carrier Ethernet 2.0 Certification Blueprint– see also IEEE 802.16-13-0010

• First Carrier Ethernet 2.0 certifications: Jan 2013– All 4 service types: E-Line, E-LAN, E-Tree, E-Access

44

http://metroethernetforum.org/ce20/Materials/Carrier_Ethernet_2.0_Certification_Blueprint_-_VERSION_1_1.pdf










http://doc.wirelessman.org/16-13-0010




Carrier Ethernet 2.0 Summary(1) Key UNI Service Attributes

• Port-Based (EPL, EP-LAN, EP-Tree):– No Service Multiplexing: one service per port– All to One Bundling (all VLANs forwarded to service)– No ingress or egress bandwidth profile (BWP) per UNI

• VLAN-Based (EVPL, EVP-LAN, EVP-Tree):– Service Multiplexing allowed: multiple services per port– Bundling of VLANs onto a service allowed

• Requires VLAN preservation

45

Carrier Ethernet 2.0 Summary(2) Key EVC Service Attributes

• At least one CoS is required– values/objectives for each performance attribute with

objectives and parameters defined in MEF 23.1– See slides below beginning with “Carrier Ethernet QoS”

• Port-Based (EPL, EP-LAN, EP-Tree):– CE-VLAN ID Preservation– CE-VLAN CoS Preservation

• VLAN-Based (EVPL, EVP-LAN, EVP-Tree):– CE-VLAN ID Preservation: optional– CE-VLAN CoS Preservation: optional

46

Carrier Ethernet 2.0 Summary(3) Key EVC per UNI Service Attributes

• Port-Based (EPL, EP-LAN, EP-Tree):– All Service Frames at the UNI must map to one EVC

• VLAN-Based (EVPL, EVP-LAN, EVP-Tree):– Specify mapping table of CE-VLAN IDs to EVC ID

47

Carrier Ethernet 2.0 Summary(4) Service OAM Frames

• Operations, Administration, and Maintenance• Various Connectivity, Linktrace, and Loopback

message handling requirements• “Carrier Ethernet 2.0 Service OAM enables the subscriber

and the service provider to check continuity of a given EVC across the entire service, to trace the path of a service or ping a target MEP (Maintenance association End Point) or configured MIP (Maintenance domain Intermediate Point), for subscriber and test MEG (Maintenance Entity Group) levels defined in MEF 30 ‘Service OAM FM Implementation Agreement’.”

48

Carrier Ethernet 2.0 Summary(5) E-Access Services

• E-Access: Point to Point OVC (ENNI/UNI)– Other OVC configurations not currently certifiable

• Many Attributes– UNI Service Attributes– ENNI Service Attributes– OVC per UNI Service Attributes– OVC Endpoint per ENNI Service Attributes– OVC Service Attributes– Service OAM Frames Handling

49

Carrier Ethernet 2.0 Backhaul

• MEF Carrier Ethernet for Mobile Backhaul Initiative is based on Carrier Ethernet 2.0 but introduces additional requirements specifically for backhaul purposes.– “New Mobile Backhaul Initiative to Resolve 4G/LTE Backhaul’s Most

Costly Challenge” calls out:– MEF 22.1 (“Mobile Backhaul Phase 2”)

• Indicates importance of network-based synchronization support, providing guidance through the paper “Packet Synchronization over Carrier Ethernet Networks for Mobile Backhaul – A Formula for Deploying IEEE 1588v2 and Synchronous Ethernet: Investigate – Test – Deploy.”

• specifies requirements on Service OAM, Ethernet OAM, and synchronization, along with other issues

– MEF 23.1 (“Carrier Ethernet Class of Service – Phase 2”)• See also MEF 23.1 overview slides

50

http://metroethernetforum.org/page_loader.php?p_id=2031


http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_22.1.pdf

http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_22.1.pdf

http://www.metroethernetforum.org/PDF_Documents/technical-specifications//MEF_23.1.pdf




http://www.metroethernetforum.org/PPT_Documents/Reference-Presentations/Overview-of-MEF_23_Phase_II-Mar-12-2012.ppt

http://www.metroethernetforum.org/PPT_Documents/Reference-Presentations/Overview-of-MEF_23_Phase_II-Mar-12-2012.ppt

Carrier Ethernet QoS

• QoS is a core and complex facet of MEF specs• Key concepts:

– Bandwidth profile (BWP)– Information Rate– Burst Size– Committed vs Excess– Color– PCP– CoS– Performance Service Attributes– CoS Performance Objectives (CPOs)

51

Carrier Ethernet BWP Process

• Committed Information Rate (CIR), Committed Burst Size (CBS), Excess Information Rate (EIR), and Excess Burst Size (EBS) agreed by provider and subscriber (in SLA)

• Service Frames are observed– at ingress and/or egress– at UNI and/or EVC, or per CoS

• 8-level CoS can by identified by 3-bit PCP field in C-Tag or S-Tag

• Service Frames are marked– Up to CIR/CBS: Green; delivered per performance objectives– Beyond CIR/CBS but up to EIR/EBS: Yellow; delivered as best effort– Beyond EIR/EBS: Red; discarded

52

Performance Service Attributes

• Performance Service Attributes:– QoS description, per CoS

• MEF 23.1 specifies 3 CoS Labels: H, M, L• CoS Performance Objectives (CPOs)

– Frame Delay, Mean Frame Delay, Inter-Frame Delay Variation, Frame Delay Range, Frame Loss Ratio

– Specified in 4 “Performance Tiers” for each CoS Label• Some content in MEF 23.1 remains TBD

53

Conclusions

•  Improvements to the IEEE 802.16-2012 air interface are required for Carrier Ethernet 2.0 support

•  With a few improvements, IEEE 802.16 can be fully integrated into a Carrier Ethernet 2.0 network and provide Wireless Carrier Ethernet 2.0.

54

The Way Forward

•  Update IEEE 802.16 Ethernet Packet CS to recognize Etherport ports and explicitly support 802.1Q bridging

•  Map CE 2.0 CoS and QoS parameters to IEEE 802.16 QoS

•  Provide for management and configuration control

55

References

• IEEE Std 802.16-2012• IEEE Std 802.1D, amended by IEEE 802.16k-2007• IEEE Std 802.1Q• Contribution IEEE 802.16-13-0010• RFC 5692 (“Transmission of IP over Ethernet over IEEE 802.16

Networks”)• MEF Technical Specifications • MEF Carrier Ethernet 2.0 Certification Blueprint• MEF: New Mobile Backhaul Initiative to Resolve 4G/LTE Backhaul’s

Most Costly Challenge• MEF: Packet Synchronization over Carrier Ethernet Networks for

Mobile Backhaul – A Formula for Deploying IEEE 1588v2 and Synchronous Ethernet: Investigate – Test – Deploy

56

http://standards.ieee.org/about/get/802/802.16.html










http://standards.ieee.org/getieee802/download/802.16k-2007.pdf

http://standards.ieee.org/getieee802/download/802.16k-2007.pdf











http://datatracker.ietf.org/doc/rfc5692/

http://datatracker.ietf.org/doc/rfc5692/









http://metroethernetforum.org/PPT_Documents/MEF-for-Mobile/MEF_MBH_Analyst_deck_final-1.pptx










http://metroethernetforum.org/PDF_Documents/MEF-for-Mobile/Packet%2520Synchronization%2520over%2520Carrier%2520Ethernet%2520Networks%2520for%2520MBH%25202012021.pdf




