Use cases for adding AV device to BPL network

Introduction

One of the HomePlug BPL group’s major directions is to allow HomePlug AV devices to interconnect with a BPL network, thus, eliminating the need of using in-home BPL gateways. In this scenario, the BPL Gateway (NTU) is installed on the pole (or elsewhere in the vicinity of the house) and acts as a gateway between one or more AV networks (AVLNs) and the BPL network.

In order to support this scenario, there is a need to create interfaces between HomePlug AV and HomePlug BPL, to allow smooth connectivity, security support, and IP layer connectivity between these two networks that have different structure, tasks, and behavior.

Before creating full support for this scheme, there is a need to map the different use cases in which AV device can be added to a BPL network.

This document is directed to answer Ocala F2F action item:

5(f) ACTION ITEM: MainNet(Shmulik)/Intellon(Haniph), with review/input from EarthLink/COMTek) -- write section in the BPL spec which describes the various use cases (and security management details at the IP layer) for adding an AV device to a BPL network – clear picture of user experience by Miami F2F.

[QUESTION 1: Is a BPL Gateway defined as a device that can talk both BPL and AV?]

We have some lack of "common" dictionary, so the terms are a bit confusing… We refer the NTU unit as a unit that supports and talks both BPL mode and AV mode. AV mode is being used to communicate, synchronized and policy dictation, BPL mode is being used for BPL related transmissions and receptions – toward and from the BPL HE.

[QUESTION 2: An NTU must be a BPL Gateway, but must a BPL Gateway be an NTU?]

Question of definition… I'm not sure I understand the difference… I think the two are the same.

[QUESTION 3: If a BPL Gateway is necessarily an NTU, then can a customer own one of these? See Ocala Meeting Minutes item A1 – Important Note: Change of NTU Role in BPL Architecture.]

I understand this phrase as a mandatory restriction to a user to handle and configure (and get access to) BPL related part of the NTU/BPL gateway unit. The BPL model may share some elements from the ADSL and Cable world, or from the Wireless Access world.

While working at the Wireless Access scheme – the BPL access device is a "public" entity, located on the pole and give service to authenticated end-customers which have AV connectivity toward it.

When the working mode is like ADSL/Cable – the customer own its BPL gateway and may configure its LAN/AV side parameters but does not have any control on the BPL related parameter which his certified unit contains.

The working scheme may combine these two schemes together – the NTU located at the pole may act as a BPL Repeater to home BPL gateways, and as a "public" BPL gateway to other neighbors that have only AV device as a CPE.

I think we may use this F2F meeting to finally define the BPL related terminology in order that all our documents will use the same terms.

AV and BPL connectivity

The HomePlug AV Spec. Section 4.4.1.3 defines an “Access field” in the MPDU Frame Control Block. This field will be used for distinguishing between in-home AV network and BPL network. In addition, detection of this field value can be used for notifying one network type that its counterpart exists in the vicinity, which will invoke the following mechanisms:

1.  BPL network detects AV network:

  1. Activate Policy mechanisms.
  2. Activate authentication and authorization mechanism for AV side.

2.  AV network detects BPL network:

  1. Follow BPL derived Policy.
  2. Activate BPL connectivity preparation (open channel).
  3. Open (if required) IP connectivity with BPL.

The policy mechanism is determined according to HE-configured policy. Its intention is to create a clear differentiation between AV and BPL in terms of contention and fairness. Generic policy rules are set by the HE, and each BPL gateway is responsible for implementing these rules locally for its neighbor AV network/s. HE information will be used in order to synchronize AV network contention and contention-free slots for maintaining synchronized BPL and AV time slots throughout the entire BPL network.

Since in general BPL Service is not a free service, users will need to authenticate in order to get access to the Internet or other services offered by the service provider. In order to open a BPL channel (which should be a well-defined service oriented channel – TBD), the user will need to register himself, and to log in using standard protocols, such as PPP, 802.1X, L2TP, etc.

In order to allow such service, the BPL Gateway will maintain an "open channel" scheme, in which only those AV devices that have passed authorization, and whose streams match the service rules will be allowed to pass information through the BPL network. Each such authorized AV device constitutes a channel. Other AV devices that belong to the same AVLN as a connected AV device will not have direct connection to the BPL unless they perform the same registration method.

(From this point, it is a matter of operator policy: will they allow more than one active channel per customer? If not, there might be a market for AV-BPL in-home gateways, which will become the AV network "gateway" to the BPL – all other AVLN members will use it for accessing the BPL.)

Since a single Ethernet port cannot act (automatically) as a member of more than one IP network, IP connectivity should be maintained either on PC level or by an AV-Access-ready unit. At the PC level, this may be done by an opened PPP channel, which creates two "networks." The first is in the IP range of the AVLN, and the second activates IP gateway rules via the BPL gateway toward the backbone.

Alternatively a AV-Access-ready unit – which acts as a BPL-in-home gateway – may function as a DHCP server and IP (+NAT) manager to the AVLN members (and their subscribers). In this second scenario, the BPL-in-home-gateway will implement AV protocols; it will be the single access point toward the NTU that all other AV units will use toward the backbone.

VLAN implementation on the AV side is quite problematic in these IP based scenarios.

Use case 1: Single AV device connecting to "public" BPL

[External BPL device (NTU that talks AV), perhaps servicing multiple customers; customer with single AV device that does not talk BPL connected to NTU. AV device may “see” neighbor AV devices, but does not have an AVLN.]

When a single AV device is connected and identifies a nearby BPL device, it tries to join the AVLN, placing the BPL gateway as its AV CCO. The Link between AV units is trivial. However, in order to pass information beyond the AV side of the BPL gateway toward the BPL world, an authorized channel should be opened.

In order to establish such a channel, the PC that is connected to the AV device will need to use a standard protocol and will invoke a point-to-point link between it and the internet gateway.

The basic model in this use case is quite similar to the ADSL model – a single user "dial-up connection" that opens the gateway to the outside world.

From the BPL to AV perspective, the AV connectivity mechanisms will do the trick. In order to limit the upstream bandwidth of the end-customer, the BPL will use the CSPEC as the upper bandwidth boundary it will allow the AV device to use.

The BPL Gateway will be in charge of verifying the secure channel state. In case the client disconnects the channel, or it was rejected, aged out, etc., the BPL Gateway should close the door to the backbone until a new channel is created.

Sub Case 1.1: AV device switch between BPL gateways

[Two or more external BPL device (NTUs that talk AV), each perhaps servicing multiple customers; customer with single AV device (that does not talk BPL) connected to one NTU but capable of talking to another one. AV device may “see” neighbor AV devices, but does not have an AVLN.]

In case there is more than one BPL gateway in the region, there is a challenge to define the mechanisms that will handle it in terms of:

1.  Choosing the BPL gateway that will be "assigned" to the AVLN.

2.  Switching between BPL gateways in terms of AVLN members and CCo replacement.

3.  Switching between BPL gateways in terms of open channels (that need to be "moved" between BPL gateways in order that the new gateway will allow their transmissions toward and from the backbone.

TBD.

Use Case 2: Single AV device connecting to home BPL

[In-home, customer-owned BPL device (NTU that talks AV), servicing only that customer; customer has one or more AV device that does not talk BPL connected to customer-owned NTU. Customer-owned NTU and AV device(s) form an AVLN, and may “see” neighbor AV devices.]

Use Case 2 is similar to Use Case 1 in terms of the AV layer connectivity and BPL channel maintenance. The main difference is the location of the BPL device – it is not a public unit that is located outside of the customer's premises and serves more than one potential customer. This device should have its Security setting behavior adjusted as for a normal AV device (in order to prevent a neighbor's AV units from exploiting it as a BPL public gateway).

This device may be similar in its concept to an ADSL Router – a unit that is configured by the end customer himself, in order to make a BPL connection toward the backbone to behave an always-connected service without customer involvement.

Such device can also be used as a LAN manager (i.e., DHCP services, etc.) where more than a single AV/PC device is located. In this scheme, the "BPL Router" will communicate with the PC/s using NAT IP and toward the backbone using the IP it got from the backbone side.

The CPE in this figure is a BPL Gateway.

[QUESTION 4: Doesn’t this contradict operator ownership of BPL gateways?]

See my answer to QUESTION3.

Sub Case 2.1: BPL in-home gateways with overlapping

[Same customer has several in-home, customer-owned BPL devices servicing only that customer; customer may also have one or more AV device that does not talk BPL connected to customer-owned NTU. Customer-owned NTUs and AV device(s) form an AVLN, and may “see” neighbor AV devices.]

In case several BPL in-home gateways are located in the same premises, there is a need to differentiate between different neighbors and their associated BPL Router, since these units are managed entities by the customer, the NMK can be used in order to define the relevant AVLN.

The CPEs in this figure are BPL Gateways.

Use Case 3: AV network connecting to public BPL

[External BPL device (NTU that talks AV), perhaps servicing multiple customers; customer has several AV device that do not talk BPL, one of which is connected to the external NTU. Customer-owned AV devices form an AVLN, and may “see” neighbor AV devices.]

In case where the end customer is maintaining a HomePlug AV network in his home and wishes to join the BPL network, he will need to open a secure channel from one of his PCs (which is connected to an AV device) toward the backbone. After opening such a channel, it may define (if it is a Microsoft environment – simply by using bridge) this PC to become the gateway to the network. Each internet related transmission from other PCs in the AVLN will pass as a NAT transmission on the AV network toward the assigned gateway PC and from this point will be converted to a AV to AV/BPL "global" IP transmission toward the internet.

In terms of BPL to AV connectivity, the rest of the AV units will refer to the public BPL unit (in its AV side) as a member in their AVLN (even though transmissions toward it should not use the AVLN encryption key – the BPL public unit should not be aware of this private information!).

This suggestion has a major impact - in the fact that every transmission in the AVLN (which is not from the gateway) will cost twice in terms of system resources – since it is transmitted twice.

The CPE in this figure is not a BPL Gateway, but only an AV device.

Use Case 4: Several AV networks connecting to public BPL

This use case is an extension to Use Case 3; the change is in the fact that the public BPL should maintain several connections to several AV devices (one per network) and the separation between the neighbors will be done using the AVLN NMK.

The CPEs in this figure are not BPL Gateways, but only AV devices.

Use Case 5: Large AV network connecting to BPL (one or more hidden nodes)

TBD.

The CPE in this figure is not a BPL Gateway, but only an AV device.

Appendix A: IP configuration and off-the-shelf supportive packages

Appendix B: Operator Business Case oriented scenarios