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 inhome 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:
a. Activate Policy mechanisms.
b. Activate authentication and authorization mechanism for AV side.
2. AV network detects BPL network:
a. Follow BPL derived Policy.
b. Activate BPL connectivity preparation (open channel).
c. 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 AVAccess-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.
Provider
Equipment
HE
NTU with several CPEs,
Each CPE
without AVLN
NTU
CPE
CPE
CPE
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.
Provider
Equipment
HE
CPE with several NTUs
NTU
NTU
CPE
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.
Provider
Equipment
HE
NTU
AV
STA
Gateway CPE with AVLN,
Neighbor AVLN
AV
STA
CPE
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.
Provider
Equipment
HE
NTU
AVLN with multiple CPEs
connected to NTU,
Neighbor AVLN
CPE
with CPE
CPE
CPE
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.
Provider
Equipment
HE
AV
STA
NTU
Gateway CPE with AVLN,
Neighbor AVLN
AV
STA
CPE
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.
Provider
Equipment
HE
NTU
AV
STA
Gateway CPE with AVLN,
Neighbor AVLN
AV
STA
CPE
CPE
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.
Provider
Equipment
HE
NTU
CPE
Gateway CPE with large
AVLN, hidden nodes
AV
STA
AV
STA
AV
STA
AV
STA
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